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

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 7 Dec 2020 17:32:00 +0000

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

Fred

> -----Original Message-----
> From: Templin (US), Fred L
> Sent: Monday, December 07, 2020 9:28 AM
> To: 'Tom Herbert' <[email-masked]>
> Cc: [email-masked]; Gorry Fairhurst <[email-masked]>; 6man WG <[email-masked]>; Bob Hinden
> <[email-masked]>; Fernando Gont <[email-masked]>
> Subject: Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed
> 
> Tom,
> 
> > -----Original Message-----
> > From: Tom Herbert [mailto:[email-masked]]
> > Sent: Monday, December 07, 2020 8:22 AM
> > To: Templin (US), Fred L <[email-masked]>
> > Cc: [email-masked]; Gorry Fairhurst <[email-masked]>; 6man WG <[email-masked]>; Bob Hinden
> > <[email-masked]>; Fernando Gont <[email-masked]>
> > 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
> > <[email-masked]> wrote:
> > >
> > > Ole,
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > Sent: Monday, December 07, 2020 6:40 AM
> > > > To: Templin (US), Fred L <[email-masked]>
> > > > Cc: Fernando Gont <[email-masked]>; Bob Hinden <[email-masked]>; 6man WG <[email-masked]>; Gorry
> Fairhurst
> > > > <[email-masked]>
> > > > 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
> > > [email-masked]
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Mon, 7 Dec 2020 11:06:35 -0700

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

> 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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 7 Dec 2020 18:33:15 +0000

Tom,

> Sent: Monday, December 07, 2020 10:07 AM

Sounds tempting, but what I want to do is a minimal encapsulation in the
spirit of RFC2004 except based on IPv6 and not IPv4, and I do not want to
get involved with instrumenting HbH headers. Instead, I want to hide any
HbH headers from an intermediate set of IPv6 routers in an alternate
network via encapsulation. Since the encapsulation constitutes a "tunnel",
the alternate network is seen as a single hop from the perspective of the
encapsulated network, and the routers in the alternate network should
therefore not process the encapsulated HbH header.

The minimal encaps is based on the "OMNI Routing Header (ORH)" which
is defined in draft-templin-intarea-6706bis. It is inserted at a tunnel ingress
and removed at the tunnel egress. It leverages the original IPv6 header by
rewriting the destination address to the address of the tunnel egress, and
it remembers the original destination by writing it into the ORH. The ORH
also has other important stuff that is meaningful only to the tunnel egress
and used in final-hop forwarding after the ORH is removed.

So yes, I do want to insert this in front of the HbH header, if present. And,
I don't want any of the IPv6 routers in the alternate network to get upset
about it, because the HbH header holds no interest for them.

Fred

---

From: Tom Herbert <[email-masked]>
Date: Mon, 7 Dec 2020 11:52:31 -0700

Fred,

So this is basically inserting and removing a routing header in the
transit network similar to the proposals for SRH? If that's the case,
then I don't immediately see how your use case is particularly
different than that already discussed for inserting SRH in 6man. It
should carry the same concerns and potential solutions for inserting a
routing header, or other EH, in a packet. Neither do I understand why
it would be critical for the routing header to precede HBH, if HBH
header is uninteresting intermediate nodes are allowed to ignore them
anyway per RFC8200. If your concern is that a big HBH EH could push
the routing header too deep in the packet to be processed, then could
be addressed by the HBH limits now under discussion.

Tom

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 7 Dec 2020 19:15:31 +0000

Tom, I am willing to be educated about what middleboxes do with HbH headers.
I have an original IPv6 source in a "blue" network, then a tunnel ingress that
encapsulates packets from the blue network and forwards them into an "orange"
network, then a set of orange network IPv6 routers that convey the encapsulated
packets to a tunnel egress, then the tunnel egress removes the encapsulation and
finally forwards the packets to a final IPv6 destination in the blue network.

What I am trying to effect is to hide any blue network HbH headers from orange
network IPv6 routers by inserting my routing headers in front of the HbH headers.
You are right that I could insert the routing headers immediately after the blue
HbH headers, which would amount to a slightly more painful insertion operation
but perhaps not the end of the world. But, what would happen if the orange
network routers were allowed to examine the blue network HbH headers? I
would be happy if they ignored them, but concerned otherwise.

Thanks - Fred

> Sent: Monday, December 07, 2020 10:53 AM
> Subject: Re: [EXTERNAL] Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed
> 
> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
> know that the content is safe.
> 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 7 Dec 2020 14:17:21 -0500

Heavily trimmed

On 12/7/2020 12:32 PM, Templin (US), Fred L wrote:
...
> If so, I don't think they should.

This sounds like the classic IP Header checksum case.
The practical answer was that while the standard said that an invalid 
IPv4 header checksum required dropping the packet, most routers did not 
bother checking.  They simply made sure that any changes they made to 
the checksum did not turn an invalid checksum valid.

There is a practical tension, in that it would be nice to drop bad 
packets (of whatever kind) as early as possible.  So it would be nice to 
drop a packet that the far end will silently reject early.
But doing extra work to drop packets is generally frowned on.
And if the rejection is not supposed to be silent, it is much better to 
let the far end entity do the work of responding.

None of which has much to do with the topic at hand, but is related to 
the concern you expressed.

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Mon, 7 Dec 2020 12:45:23 -0700

Fred,

IP-IP encapsulation would solve this problem, but I suppose you don't
like the forty-bytes of overhead (which is really twenty-four bytes
since the inner destination address would be the same as the address
in the OMNI routing header and hence could be removed from the routing
header). For draft-herbert-6man-eh-attrib-03 it's conceivable that we
could have a flag in the inserted attribution option that indicates
options following the inserted ones are to be ignored.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 8 Dec 2020 08:47:25 +1300

Not getting at this message in particular, but I've just about given up
on this thread because

>    3.5 Keep it simple. When in doubt during design, choose the simplest
>    solution.

It seems to me that we are way off in the weeds here in terms of
specifying things that are simple enough to (a) get right, (b) describe
precisely and (c) implement at line speed.

The draft meets those criteria. A lot of the discussion doesn't.

Regards
   Brian

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 7 Dec 2020 20:26:15 +0000

Joel, yes on my orange network the half-blue; half-orange IPv6 packets would
be carried with incorrect ULP checksums. I think it just means that the orange
network routers (which are under my control) need to avoid ULP checksum
integrity checking when forwarding the packet.

Thanks - Fred

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Monday, December 07, 2020 11:17 AM
> To: Templin (US), Fred L <[email-masked]>; Tom Herbert <[email-masked]>
> Cc: Gorry Fairhurst <[email-masked]>; Bob Hinden <[email-masked]>; 6man WG <[email-masked]>; Fernando Gont
> <[email-masked]>
> Subject: [EXTERNAL] Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed
>