Re: [Errata Rejected] RFC6564 (4423)

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

On Sun, Oct 25, 2015 at 12:28 PM, Brian E Carpenter
<[e-mail]> wrote:
> 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.

Understood, but it seems to me that gives middle-box implementors an excuse
to unconditionally discard an IPv6 datagram with an unrecognised Next Header
value, on the grounds that it might identify an unrecognised
upper-layer protocol,
to which the requirements of RFC 7045, by explicit design, do not
apply.  I would
of course argue that such a strategy would not comply with RFC 7045, since the
unrecognized Next Header value could just as well identify unrecognised
extension header, but I'd like to see text that unambiguously rules out this
(broken) behavior.  That said, maybe I'm in the rough here, and the text in
RFC 7045 is sufficiently clear as it stands.

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

If there were to be an erratum, a better choice than the change I suggested --
given that the text reflects the authors' intent -- would be a note
explaining that
the indistinguishability of unrecognised extension headers and unrecognised
upper layer protocol headers implies that forwarding nodes complying with the
requirements 7045 must be configurable to pass unrecognised upper-layer
protocols.

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

I wasn't ware of that draft, though I had heard of such proposals.  Thanks for
the pointer.

//cmh