Re: SRv6 Network Programming: ENH = 59

[Mark Smith <[e-mail]>]

On Thu, 9 May 2019 at 00:57, Tom Herbert <[e-mail]> wrote:
>
> On Wed, May 8, 2019 at 3:37 AM Ole Troan <[e-mail]> wrote:
> >
> > >> I am not sure that your use of this field is in accordance with Section 4.7 of RFC 8200.
> > >
> > > The language is quite subtle, in fact, so I'm not sure either. However, the doubt can easily be resolved by using protocol number 22, which appears to be intended exactly for this purpose.
> >
> > I spent some time yesterday digging into history and intent.
> > As far as I could find from the ipng mailing list, the idea was suggested in November 1994. The use case was to be able to signal end to end with extension headers, so the No next header value was a way of signalling termination of the chain.
> > There was a lot of support for using the value 0, but there was an argument made that comparing a the next header field against the constant 0 was faster than comparing it to another constant (really?). So that number went to HBH.
> >
> > The allocation was done by IANA in February 95 and the 4.7 text was included in the first draft published March 17:
> > https://tools.ietf.org/html/draft-ietf-ipngwg-ipv6-spec-01
> >
> > There is no discussion on the mailing list that I can find about additional data after the last header.
> > I vaguley recall having a discussion at some IETF about this, but I can't recall the conclusion.
> > Given the text on "must forward", I think it was intended as an extension mechanism / scratch space.
> >
> Ole,
>
> This situation sounds very similar to the "surplus space" in UDP where
> the IP length and UDP length differ such that there are bytes in the
> IP packet following the UDP headers. While RFC768 implicitly defined
> the surplus space, no use or requirements about what it contains were
> ever specified. Now there is an attempt to define these bytes in UDP
> (draft-ietf-tsvwg-udp-options).
>
> I believe a reasonable interpretation of "No next header" is that the
> trailing bytes contain something not describable by a standard
> protocol number, but the bytes should be allowed to contain data of
> interest to the receiver. So the bytes need to be interpreted by other
> means. This is in fact how we are using protocol number 59 in GUE when
> the GUE payload is a fragment or has been transformed, e.g. by
> encryption. The payload cannot simply be parsed as an IP protocol.
> Information in the GUE header indicates how the payload is
> interpreted, and we use No-next-header to ensure that intermediate
> devices don't try to parse the payload.
>
> So I think the use of No-next-header in segment routing would be
> consistent with this interpretation, however, in this case the data
> being carried in the payload is describable by an existing protocol
> number, namely ETHERIP (protocol 97), so using No-next-header seems
> like unnecessary complexity.
>

Here's what RFC8200 says:

"The value 59 in the Next Header field of an IPv6 header or any
   extension header indicates that there is nothing following that
   header."

The etymology of "nothing" is "no thing", so there is to be no thing
following the No Next Header EH.

It also says,

"If the Payload Length field of the IPv6 header indicates the
   presence of octets past the end of a header whose Next Header field
   contains 59, those octets must be ignored and passed on unchanged if
   the packet is forwarded."

Processing values in those bytes is obviously not ignoring them.

"passed on unchanged if the packet is forwarded." is really a
redundant statement, as IPv6 forwarding isn't looking at any EH other
than Hop-by-Hop. Passing on unchanged is implicit in IPv6 forwarding
being intentionally oblivious to packet payloads.

This second statement seems to really be text on how to treat an error
in the Payload Length field value when it points past the end of the
packet. There could be invalid bytes there because of Ethernet padding
of frames up to 64 octets.

Regards,
Mark.


> Tom
>
>
> > Cheers,
> > Ole
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------