Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed

On Mon, Dec 7, 2020 at 10:32 AM Templin (US), Fred L
<Fred.L.Templin@boeing.com> wrote:
>
> Sorry; mailer glitch on my last message. To my response:
>
> > headers. Looking at the code, I suspect that if a Linux host receives
> > a packet with HBH EH not immediately following the IPv6 header, the
> > packet will be dropped as having an unrecognized next header.
>
> I am not concerned about a Linux host; I am concerned about IPv6 routers.

That might be your concern, but the protocol's and IETF's concern is
robust and interoperable operations across hosts and routers. As the
it stands today, HBH EH can only be created by a source host and must
be processed by the destination host, so packets having HBH EH not be
the first EH would most likely be dropped at the destination host and
hence your proposed changed wouldn't generally be useful without
changing host implementations and probably a lot of router
implementations.

> Do IPv6 routers look at extension headers beyond the first one trying to see
> if there is an out-of-place HbH header and then drop the packet if there is?
> If so, I don't think they should.

Per RFC8200 they shouldn't, however we know that many routers look
well beyond the HBH EH (for instance to find transport layer ports for
ECMP). The processing of an embedded HBH option is unspecified in that
case: maybe they'll skip over the EH, maybe they'll drop the packet,
maybe they'll try to process it as HBH options.

>From your description, I will extrapolate that you're planning have
routers insert an extension header and then other routers remove the
extension headers before they are received at the host, so this is a
case of extension header insertion/removal. If that is the case then
draft-herbert-6man-eh-attrib-03 might be of interest to you. It
preserves the requirements of HBH being first an only appearing once,
but would allow Hop-by-Hop options to be inserted. Maybe the extension
header you'd like before the HBH EH could be placed in a HBH
option?...

Tom

>
> Fred
>
> > -----Original Message-----
> > From: Templin (US), Fred L
> > Sent: Monday, December 07, 2020 9:28 AM
> > To: 'Tom Herbert' <tom@herbertland.com>
> > Cc: otroan@employees.org; Gorry Fairhurst <gorry@erg.abdn.ac.uk>; 6man WG <ipv6@ietf.org>; Bob Hinden
> > <bob.hinden@gmail.com>; Fernando Gont <fernando@gont.com.ar>
> > Subject: Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed
> >
> > Tom,
> >
> > > -----Original Message-----
> > > From: Tom Herbert [mailto:tom@herbertland.com]
> > > Sent: Monday, December 07, 2020 8:22 AM
> > > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > > Cc: otroan@employees.org; Gorry Fairhurst <gorry@erg.abdn.ac.uk>; 6man WG <ipv6@ietf.org>; Bob Hinden
> > > <bob.hinden@gmail.com>; Fernando Gont <fernando@gont.com.ar>
> > > Subject: Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed
> > >
> > > On Mon, Dec 7, 2020 at 7:57 AM Templin (US), Fred L
> > > <Fred.L.Templin@boeing.com> wrote:
> > > >
> > > > Ole,
> > > >
> > > > > -----Original Message-----
> > > > > From: otroan@employees.org [mailto:otroan@employees.org]
> > > > > Sent: Monday, December 07, 2020 6:40 AM
> > > > > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > > > > Cc: Fernando Gont <fernando@gont.com.ar>; Bob Hinden <bob.hinden@gmail.com>; 6man WG <ipv6@ietf.org>; Gorry
> > Fairhurst
> > > > > <gorry@erg.abdn.ac.uk>
> > > > > Subject: Re: [EXTERNAL] Proposal for changing how IPv6 Hop-by-Hop Options are processed
> > > > >
> > > > > >> Mind explaining what you are trying to achieve with that change?
> > > > > >
> > > > > > Other than text that is more consistent with the robustness principle?
> > > > > > Shouldn't that be good enough in itself?
> > > > >
> > > > > Not really.
> > > > > You will have more success gathering support for your ideas if you explain what problems they are meant to solve.
> > > > > Restricting the HBH header to appear only directly after the IPv6 header seems like quite a robust design.
> > > >
> > > > Restricting the HbH header to appear only directly after the IPv6 header is consistent
> > > > with "be conservative in what you send". Processing the HbH header  only if it follows
> > > > immediately after the IPv6 header (otherwise ignore) is consistent with "be liberal in
> > > > what you accept from others".
> > > >
> > > > The real strength of Postel's law is the second clause moreso than the first. Application
> > > > of the second clause per my proposed text will naturally guide application of the first
> > > > clause in cases where the sender actually does want the HbH option processed. In
> > > > other cases, the second clause ensures correct operation for the receiver.
> > > >
> > > Fred,
> > >
> > > The receive clause of the Robustness principle is only applicable
> > > within the bounds of the protocol requirements. RFC8200 is specific
> > > that HBH must be first and there can only be one HBH in a packet. A
> > > receive path may be implemented assuming these requirements such that
> > > they never have to consider the possibility of HBH appearing elsewhere
> > > in a packet. In fact, that is how Linux implemented HBH handling by
> > > making a special case different from all the other possible next
> > > headers. Looking at the code, I suspect that if a Linux host receives
> > > a packet with HBH EH not immediately following the IPv6 header, the
> > > packet will be dropped as having an unrecognized next header. I don't
> > > believe this behavior is non-conformant or is inconsistent with
> > > Postel's law.
> > >
> > > Tom
> > >
> > > > Thanks - Fred
> > > >
> > > > > Cheers,
> > > > > Ole
> > > >
> > > > --------------------------------------------------------------------
> > > > IETF IPv6 working group mailing list
> > > > ipv6@ietf.org
> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > --------------------------------------------------------------------