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

["C. M. Heard" <[e-mail]>]

On Mon, Nov 13, 2017 at 8:15 AM, Tim Chown wrote:
> On 7 Nov 2017, at 19:29, Brian E Carpenter wrote:
>> On 08/11/2017 00:20, Tim Chown wrote:
>>> On 6 Nov 2017, at 19:35, Brian E Carpenter wrote:
>>>> On 07/11/2017 07:02, Fernando Gont wrote:
>>>>> On 11/02/2017 04:33 PM, Brian E Carpenter wrote:
[...]
>>>>>> 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/RFC2460, 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.

Actually, RFC 8200 is carefully worded, and the three cases it
discusses are:

* Known EHs
* Known ULP
* Unknown Next Header value

That last bullet includes both unknown EHs and unknown ULPs.
RFC 8200 says to process both in the same way.

That being said, this point is easily missed (witness this discussion
and earlier ones on the topic). So a clarification would be useful.

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

I am fine with this text.

Mike Heard