Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP

> On 7 Nov 2017, at 19:29, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 08/11/2017 00:20, Tim Chown wrote:
>> Hi,
>> 
>>> On 6 Nov 2017, at 19:35, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>> 
>>> Hi Fernando,
>>> 
>>> On 07/11/2017 07:02, Fernando Gont wrote:
>>>> On 11/02/2017 04:33 PM, Brian E Carpenter wrote:
>>>>> On 03/11/2017 04:26, C. M. Heard wrote:
>>>>>> On Thu, Nov 2, 2017, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> C. M. Heard <heard@pobox.com> wrote:
>>>>>>>> On Wed, 01 Nov 2017, Michael Richardson wrote:
>>>>>>>>> Yet we skip other extension headers in order to find the ULP.
>>>>>>> 
>>>>>>>> Not so. An end node that encounters an unrecognized extension header
>>>>>>> is
>>>>>>> 
>>>>>>> Both AH and IPIP are well known and recognized extension headers.
>>>>> 
>>>>> AH is an extension header. "IPIP" isn't. It's Protocol 41, and Protocol 41
>>>>> is otherwise known as IPv6. (That's why it's also called IPPROTO_IPV6).
>>>>> In RFC8200 terms that makes it an "upper-layer header". Strictly speaking,
>>>>> RFC8200 doesn't specify what to do with an unrecognized upper-layer header.
>>>> 
>>>> Based on the std, anything that is unknown is an EH. In the context of
>>>> RFC8200/FC2460, there's only:
>>>> 
>>>> * Known EHs
>>>> * Known ULP
>>>> * Unknown EHs
>>> 
>>> Yes, that's what the text says but I wish we'd fixed it in 8200 to
>>> acknowledge that there is a 4th case (Unknown ULP) and that it
>>> cannot be distinguished from the 3rd case. Acknowledging that is
>>> much better than ignoring it. I'm happy with Ole's suggestion that
>>> this (and the resulting ICMP 1 behaviour) should be mentioned in
>>> 6434bis - as a clarification, not a new invention.
>> 
>> This seems a reasonable approach to me.  Would you like to propose text, Brian?
> 
> After this:
> 
> 5.1.  Internet Protocol Version 6 - RFC 8200
> 
>   The Internet Protocol Version 6 is specified in [RFC8200].  This
>   specification MUST be supported.
> 
>   Any unrecognized extension headers or options MUST be processed as
>   described in RFC 8200.
> 
> insert something like:
> 
>   Note that it is impossible for a node to distinguish between an
>   unrecognized extension header and an unrecognized upper layer
>   protocol. Therefore, a node will behave in the same way for
>   either of these cases, in particular by returning an ICMP
>   Parameter Problem message with code 1 ("unrecognized Next Header
>   type encountered") even for an unrecognized upper layer protocol.

This is the text TimW will present in 6man; it seems fine to me, and hopefully we’ll have consensus.

Tim

> (Protocol 41 is not special in this regard.)
> 
> - Brian
> 
>> 
>>> I also agree that there are enough potential issues in unexpected
>>> IPv6-in-IPv6 that is deserves its own draft.
>> 
>> I’d agree. The same with header insertion for that matter. Focus on the issues and how/if they can be mitigated and in which contexts.
>> 
>> Tim
>> 
>>> 
>>> Regards
>>>  Brian
>>> 
>>>> with the last one being the default branch :-)
>>>> 
>>>> 
>>> 
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------