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

[Brian E Carpenter <[e-mail]>]

On 03/11/2017 10:30, C. M. Heard wrote:
> On Thu, Nov 2, 2017 at 12:33 PM, Brian E Carpenter <
> [e-mail]> wrote:
> 
>> On 03/11/2017 04:26, C. M. Heard wrote:
>>> On Thu, Nov 2, 2017, Michael Richardson <[e-mail]> wrote:
>>>
>>>>
>>>> C. M. Heard <[e-mail]> 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.
>>
> 
> Actually, it does, and the disposition is exactly the same as for an
> unrecognzed
> extension header. Both come under the heading of ICMP Code 1 ("unrecognized
> Next Header type encountered").  See the second paragraph on page 9. Indeed,
> it could hardly be done any other way, since it's not possible for a node
> to tell
> whether an unrecognized Next Header type represents an extension header
> or an upper-layer header.

Yes, that particular elephant stands politely and quietly in the corner
of the room. However, I'd just read the text you cite when I wrote my
message and I'll stick to what I said: we *specify* action for an
unrecognized extension header, but we ignore the elephant and *don't*
specify action for an unrecognized ULP. Consider it a drafting error,
or a design error. I agree with you about the practical effect: an
unexpected IPIP packet is likely to generate ICMP 1 today.

   Brian