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

Hi Bob, Gory,

Thanks for writing this and for all your effort to make HbH deployable/useful!
A few comments:
1) If we summarize RFC8200 position on HbH, it basically says smth like:
'a node MAY process HbH or MAY not - depends on the configuration and
the default config is NOT to process'.
Your draft suggests to change it to:
-  MUST process in the fast path.
- MUST NOT process in the slow path.
I feel like the second MUST NOT ("If the IPv6 node can not process the
Hop-by-Hop Option header in the fast path it MUST skip over this
option and continue processing the header normally.") a bit too
restrictive. Is there reason not to use SHOULD here? What if my router
can not process a new HbH option in the fast path yet but I want to
apply a policier to it and get it processed in the control plane?

2) I'm a bit concerned about 'only and only one option per HbH header
only'. Aren't' we limiting the use cases drastically by doing this?
Wouldn't it mean that the first HbH option (let's say the MTU one)
which gets deployed would prevent any other options from being used?
I understand the problem with chaining multiple options and I have a
very dumb qiestion to people who understands the routers hw internals
better that I do: would it help if we have an 'Table of content'
option? Which would list codes for all options present in that header
so a single lookup would be enough to know if there are any options
here we are interested in or do not want to process at all. What if we
have such an option and always put it first? am I crazy?

On Fri, Dec 4, 2020 at 10:16 AM Bob Hinden <bob.hinden@gmail.com> wrote:
>
> 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: internet-drafts@ietf.org
> > 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" <bob.hinden@gmail.com>, "Godred Fairhurst" <gorry@erg.abdn.ac.uk>, "Robert Hinden" <bob.hinden@gmail.com>, "Gorry Fairhurst" <gorry@erg.abdn.ac.uk>
> >
> >
> > 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
> >
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
SY, Jen Linkova aka Furry