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

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.

(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
>> --------------------------------------------------------------------
>>
> 