Re: [Errata Rejected] RFC6564 (4423)

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

On 26/10/2015 05:06, C. M. Heard wrote:
> On Fri, Oct 23, 2015 at 12:17 PM, Brian E Carpenter <brian.e.carpenter
> at gmail.com> wrote:
>> On 23/10/2015 21:41, Fernando Gont wrote:
>>> Question: If you're a middle-box meaning to find the upper-layer
>>> protocol (e.g. transport ports, etc), what would you do if you find an
>>> unknown protocol number? Infer RFC6564? Infer new transport protocol? --
>>> whatever option you choose, would be wrong.
>>
>> You have failed to find the upper layer protocol. There seem to be three
>> choices:
>>
>> 1. Crash. Probably a bad idea.
>> 2. Let the packet continue on its path. That's what RFC2460 requires anyway.
>> 3. Drop the packet.
>>
>> As it happens we already have IETF consensus about this. As RFC 7045 says,
>> the choice between #2 and #3 must be configurable:
>>
>>    Forwarding nodes MUST be configurable to allow packets containing
>>    unrecognised extension headers, but the default configuration MAY
>>    drop such packets.
> 
> I agree, but the wording in RC 7045 leaves room for ambiguity.
> Perhaps a clarification
> would be in order: s/unrecognised extension headers/unrecognised Next
> Header values/

The authors of 7045 were well aware of this issue, but we chose to word the
text exclusively for extension headers and to add the corresponding IANA
registry - in other words we didn't intend to cover the issue of unrecognised
protocol numbers at all. So this wasn't careless wording.

If you were suggesting this as an erratum on RFC 7045, I would recommend
it as 'hold for document update' since I think it needs explanatory text.

(There was a fix proposed that people didn't seem to like:
https://tools.ietf.org/html/draft-zhang-6man-offset-option-01)

    Brian