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

[Fernando Gont <[e-mail]>]

On 11/06/2017 04:35 PM, Brian E Carpenter 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 <[e-mail]> wrote:
[....]
>>>>> 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.

In that sense we probably did a bit worse: the merge of RFC6564 seems to
imply a "unified format" helps... but it doesn't.. because if the type
is unknown, you cannot infer the syntax of what's comming next.


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

mmm.. would this RFC8200 (jut curious...)



> I also agree that there are enough potential issues in unexpected
> IPv6-in-IPv6 that is deserves its own draft.

Agreed. Just curious: why is this "behaviour" nw found to be of
interest? -- I missed this bit (if it was actually mentioned).

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492