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

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 3 Dec 2020 23:38:31 +0000

Bob and Gorry,

I would like it if some document that updates RFC8200 (such as yours) could
relax the restriction that the Hop-by-Hop option has to immediately follow
the IPv6 header. This comes up in two different places in RFC8200:

Section 4:
   "The Hop-by-Hop Options header, when present, must immediately follow
   the IPv6 header."

Section 4.1:
   "IPv6 nodes must accept and attempt to process extension headers in
   any order and occurring any number of times in the same packet,
   except for the Hop-by-Hop Options header, which is restricted to
   appear immediately after an IPv6 header only."

I would like to see this restriction softened somewhat (perhaps to a "should")
since I have a use case in mind where another extension header type might
appear before the Hop-by-Hop option, if only briefly. Any chance your doc
could accommodate?

Fred

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Thursday, December 03, 2020 3:16 PM
> To: IPv6 List <[email-masked]>
> Cc: Gorry Fairhurst <[email-masked]>; Bob Hinden <[email-masked]>
> Subject: [EXTERNAL] Proposal for changing how IPv6 Hop-by-Hop Options are processed
> 
> Hi,
> 
> Gorry and I put together a draft that proposes to change how IPv6 Hop-by-Hop Options are processed.  Links to the draft below.
> 
> Abstract:
> 
>   This document specifies procedures for how IPv6 Hop-by-Hop options
>   are processed.  It modifies the procedures specified in the IPv6
>   Protocol Specification (RFC8200) to make processing in routers more
>   practical with the goal of making IPv6 Hop-by-Hop options useful to
>   deploy in the Internet.  When published, this document updates
>   RFC8200.
> 
> A very short summary is that there can only be one Hop-by-Hop option in a Hop-by-Hop Option header, and that Hop-by-Hop Options
> must be process in the fast path.
> 
> Please read and comment on the draft (that is, not on just this email).   We think this might make Hop-by-Hop options practical to use
> in the Internet.
> 
> Bob & Gorry
> 
> 
> > Begin forwarded message:
> >
> > From: [email-masked]
> > Subject: New Version Notification for draft-hinden-6man-hbh-processing-00.txt
> > Date: December 3, 2020 at 3:04:46 PM PST
> > To: "Robert M. Hinden" <[email-masked]>, "Godred Fairhurst" <[email-masked]>, "Robert Hinden"
> <[email-masked]>, "Gorry Fairhurst" <[email-masked]>
> >
> >
> > A new version of I-D, draft-hinden-6man-hbh-processing-00.txt
> > has been successfully submitted by Robert M. Hinden and posted to the
> > IETF repository.
> >
> > Name:		draft-hinden-6man-hbh-processing
> > Revision:	00
> > Title:		IPv6 Hop-by-Hop Options Processing Procedures
> > Document date:	2020-12-03
> > Group:		Individual Submission
> > Pages:		11
> > URL:            https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-00.txt
> > Status:         https://datatracker.ietf.org/doc/draft-hinden-6man-hbh-processing/
> > Html:           https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-00.html
> > Htmlized:       https://tools.ietf.org/html/draft-hinden-6man-hbh-processing-00
> >
> >
> > Abstract:
> >   This document specifies procedures for how IPv6 Hop-by-Hop options
> >   are processed.  It modifies the procedures specified in the IPv6
> >   Protocol Specification (RFC8200) to make processing in routers more
> >   practical with the goal of making IPv6 Hop-by-Hop options useful to
> >   deploy in the Internet.  When published, this document updates
> >   RFC8200.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >

---

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

Bob and Gorry,

Regarding my previous message, here are my proposed updates to RFC8200.
Can these be added to your document?

Thanks - Fred

---

RFC8200, Section 4:
OLD:
         "The Hop-by-Hop Options header, when present, must immediately follow
         the IPv6 header."
NEW:
         "The Hop-by-Hop Options header, when present, is processed only if it
         immediately follows the IPv6 header (otherwise ignored)."

RFC8200, Section 4.1:
OLD:
         "IPv6 nodes must accept and attempt to process extension headers in
          any order and occurring any number of times in the same packet,
          except for the Hop-by-Hop Options header, which is restricted to
          appear immediately after an IPv6 header only."
NEW:
         "IPv6 nodes must accept and attempt to process extension headers in
          any order and occurring any number of times in the same packet,
          except for the Hop-by-Hop Options header, which is processed only
          if it appears immediately after an IPv6 header (otherwise ignored)."

> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Thursday, December 03, 2020 3:39 PM
> To: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
> Cc: Gorry Fairhurst <[email-masked]>
> Subject: RE: Proposal for changing how IPv6 Hop-by-Hop Options are processed
> 
> Bob and Gorry,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Fri, 4 Dec 2020 12:10:58 -0700

Fred,

Can you provide some detail on your use case and why you think this
change is needed?

Tom

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 4 Dec 2020 19:36:30 +0000

Hi Tom,

> From: Tom Herbert [mailto:[email-masked]]
> Sent: Friday, December 04, 2020 11:11 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>; Gorry Fairhurst <[email-masked]>
> Subject: Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed
> 
> Fred,
> 

Probably not without setting off a burst of passionate list activity. But,
I think the proposed changes are more consistent with Postel's law.

Thanks - Fred

---

From: Fernando Gont <[email-masked]>
Date: Sat, 5 Dec 2020 03:11:42 -0300

> appear before the Hop-by-Hop option, if only briefly. Any chance your doc

"right after the IPv6 header" since the only natural place where this 
option would belong. At the end of the day, the goal is that the option 
is processed by all nodes -- and if the option is elsewhere, then it 
would not, or would mean that a router would need to skip options e.g. 
destined to the destination in order to process options meant to be 
processed by all nodes.

Unless I'm missing something, I'd strongly argue against relaxing this.

In fact, if we want to have any hopes that things will improve, my 
feeling is that the way to do that would be via *tightening* requirements.

Thanks!

Regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

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

Fernando,

> Unless I'm missing something, I'd strongly argue against relaxing this.

You missed my follow-up message where I proposed specific text (see below).
The proposed text changes are consistent with Postel's law, and strengthen the
requirement that the HbH option is processed IFF it occurs immediately after
the IPv6 header.

Fred

---

RFC8200, Section 4:
OLD:

RFC8200, Section 4.1:
OLD:

---

From: [email-masked]
Date: Mon, 7 Dec 2020 15:05:11 +0100

Fred,

Mind explaining what you are trying to achieve with that change?

Best regards,
Ole

> On 7 Dec 2020, at 14:41, Templin (US), Fred L <[email-masked]> wrote:
> 
> Fernando,
>

---

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, December 07, 2020 6:05 AM
> Cc: Fernando Gont <[email-masked]>; Bob Hinden <[email-masked]>; 6man WG <[email-masked]>; Gorry Fairhurst
> <[email-masked]>

Other than text that is more consistent with the robustness principle?
Shouldn't that be good enough in itself?

Fred

---

From: [email-masked]
Date: Mon, 7 Dec 2020 15:39:30 +0100

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

Cheers,
Ole