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

On Fri, Dec 4, 2020 at 2:34 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>
> I see lots of thoughts - all of which might help see us through towards
> some conclusions.
>
> Just on (1). Whether one HBH option si enough, might depend on the
> use-case.
>
Gorry,

If one option only is a MUST then that would force all use cases to conform.

> The HBH options do not need to be set on every packet.

Many network devices like uniformity in packets being sent on a flow.
For instance, packets may be routed differently based where there is a
HBH EH as opposed when they don't (for instance, some device does
parse over the EH to find the transport ports for ECMP) so this could
cause OOO or other performance issues. Per the transmit clause of
robustness principle, it's best to make all packets of a flow look
alike as much as possible.

> For instance,
> they might be sent on packet that carries a transport-layer control
> payload (with no "data") to solict some feedback from the path. This
> might have good deployment possibilities ...

That's pushing a lot of complexity to the host stack, especially if it
has to decide which among multiple options need to be sent at every
packet.

> because even if there is
> loss of such a packet because of its EH, this loss can be detected by
> the upper layer protocol, and it does not impact the data transmission.
>
> A node can send multiple control such packets with different HBH options
> to perform different actions. That means even with only one HBH option
> per packet, I could still envisage performing different actions,
> MTU-discovery, etc.

Having a HBH container option that could efficiently encode multiple
HBH options (not in TLVs!) is an interesting idea. The flag-fields
approach used by GRE and GUE allows efficient encoding of some number
of fixed length options that are well ordered and allow random access.
For instance, in thirty bit flags we could encode the presence of all
currently defined HBH options (those that are variable length could be
limited to a few lengths). The flags indicate presence of options and
hardware can process this in array or TCAM lookups, in particular the
serial processing needed for processing options in TLVs goes away.

>
> I do expect other use cases, and we should identify and evaluate these!
>
> On (2), I do think we can improve the wording. My own thoughts are that
> we need to find words that set the expectation correctly, to avoid
> people seeing this as just a significant DoS vector.
>
Please look ar section 5.3 of RFC8504 and that should probably be a
reference because it is addressing the same DoS vector.

Tom

> I hope we find support for something in the near future...
>
> Gorry
>
>
> On 04/12/2020 02:26, Haoyu Song wrote:
> > I share the same concerns. In my opinion, we should only enforce that routers will not drop packets with HbH options and allow the routers to be configured to process 0, 1, or more HbH options or do it in the best effort fashion. So it basically means, packet with HbH options are guaranteed to be forwarded but the processing of the option is optional.
> >
> > BR,
> > Haoyu
> >
> > -----Original Message-----
> > From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Tianran Zhou
> > Sent: Thursday, December 3, 2020 5:42 PM
> > To: Bob Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>
> > Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> > Subject: RE: Proposal for changing how IPv6 Hop-by-Hop Options are processed
> >
> > Hi Bob,
> >
> > " 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."
> >
> > I have two concerns:
> > 1. Only one option may restrict many future applications. I believe there are needs to do multiple actions with the hbh behavior. Moreover, the chip capability will improve year by year. We can predict the future the capability to deal with multiple options.
> >
> > 2. The HbH option "must" be processed in the fast path seems also too strict. That means HbH cannot be processed by slow path. I would like to say it "must be firstly processed in the fast path". That means this option should not be blindly sent to slow path. But it should firstly be considered in the fast path. Then several following options: fast path, slow path, by pass.
> >
> > Best,
> > Tianran
> >
> >
> > -----Original Message-----
> > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden
> > Sent: Friday, December 4, 2020 7:16 AM
> > To: IPv6 List <ipv6@ietf.org>
> > Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>; Bob Hinden <bob.hinden@gmail.com>
> > Subject: 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: 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-hinden-6man-hbh-processing-00.txt&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C2d02d0b86be0472a572208d897f5ee10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637426429867138791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=CUJFqmkmjLLcT0lFWZn2HVpX0Fp8BU0DN9yskwaeBas%3D&amp;reserved=0
> >> Status:         https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hinden-6man-hbh-processing%2F&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C2d02d0b86be0472a572208d897f5ee10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637426429867138791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=FD9nh8S1xvkoCCYAGuCXv%2FiH%2BdGNRX3IBig1BLz0QMk%3D&amp;reserved=0
> >> Html:           https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-hinden-6man-hbh-processing-00.html&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C2d02d0b86be0472a572208d897f5ee10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637426429867138791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=TvBfaQURQuZvIMUFT59VdI4wqP8gNdQF1uGo13CC6dY%3D&amp;reserved=0
> >> Htmlized:       https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-hinden-6man-hbh-processing-00&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C2d02d0b86be0472a572208d897f5ee10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637426429867138791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VBUOGO%2BkrnPCPP64l4CguOTU5SIQyduVSmT%2BLOMnyOU%3D&amp;reserved=0
> >>
> >>
> >> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C2d02d0b86be0472a572208d897f5ee10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637426429867138791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=tWTygpRYLt56POZasHaJY50BnUgtUmOQLQlem47lZSk%3D&amp;reserved=0
> > --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------