Re: Comments on draft-hinden-6man-hbh-processing-00

[Tom Herbert <[e-mail]>]

On Thu, Mar 18, 2021 at 3:54 PM Bob Hinden <[e-mail]> wrote:
>
> Mike,
>
> > On Mar 13, 2021, at 4:36 PM, C. M. Heard <[e-mail]> wrote:
> >
> > Greetings authors and 6man,
> >
> > Following IETF 110, I read the draft and reviewed both the slides and the mailing list traffic in the first half of December 2020, and I am afraid that I must echo the following comments made by Tom Herbert on Fri, 04 December 2020 01:43 UTC:
> >
> > I understand the motivation for this draft, but I don't believe that
> > forcibly and retroactively restricting a feature in a well deployed
> > protocol is the right approach to fix the problem.
>
> Understood, but I don’t think anything will change regarding support for HBH options unless we do something.  I think there is a common quote about doing the same thing and expecting different results.
>
> >
> > It seems to me that the draft has chosen the most disruptive possible way to restrict the number of options in the HbH header.
>
> Yes as compared to what was in RFC2460, but I note that RFC8200 basically said that HBH only have to be supported if a node was configured to support them.   My thinking that supporting one option is much better than none.

Bob,

That's not entirely clear to me. The major problem with HBH options is
that some intermediate devices will summarily drop packets with the
HBH EH or relegate them to a slow path and in either case that makes
HBH with any number of options difficult to deploy. If intermediate
nodes followed the relaxed requirement of RFC8200 then that would be a
major step towards making them deployable (there's also the issue of
intermediate arbitrarily dropping packets because the "header chain"
is too big). Assuming that this issue is overcome, then it makes sense
to set some guidelines on how many HBH options should be processed,
the recommendation should be something between 1 and 500 (upper limit
based on a MTU sized packet filled with two byte options). Personally,
I believe eight is reasonable recommendation to support and can be
feasibly parsed by in hardware applying latest techniques and should
allow sufficient extensibility for the next 25 years.
>
>
> > It seems to me that the objective could be accomplished in a much less disruptive fashion in either of the following ways:
> >
> > (a) specify that nodes that process the HbH options header MAY ignore all options after the first;
> > (b) specify that  nodes that process the HbH options header MAY ignore all options after the first non-PAD option
>
> I think I would be OK with something like (a).    It’s possible to do this because the HBH header has the information that would enable a node can easily skip the rest.   I don’t think that (b) is that helpful, if a node can skip, it can skip PAD options too.

As I mentioned, the generalization of these rules is that a node can
process the partial list of consecutive options up to N of them.
Assuming that processing a partial list of HBH options is viable, then
the guidance would be for what N should default to (where one is a
possible value and eight is another as I stated above)

>
> The proposal would be something like a node SHOULD process the first HBH option in the “fast path”, if there is more than one HBH option, the node MAY process or skip the remaining options.
>
> I note, this change would eliminate the need for 8-octet alignment and would simplify the proposal.
>
I think that is only a simplification if the RFC8200 requirement was
changed to hosts MUST send at most one HBH option, otherwise padding
is still an issue and intermediate devices. The padding options
themselves could be constrained to help implementations, a requirement
could be set that the amount of padding between two non-padding
options could be less than eight octets in length and only one PADN or
PAD1 can be set between non-padding options.

> >
> > Alternative (a) is somewhat simpler, but would require re-specifying any option that requires padding in front if it stands alone inside the HbH header, As best I am able to determine from a review of the existing HbH option specifications, IOAM is the only one that is so affected.
>
> I wasn’t aware of that.  Please explain.
>
> > Alternative (b) would avoid even that, but it would also require a bit more work from a compliant node.
>
> Might be better to rework the IOAM option.
>
> > Either one of these alternatives  keeps the specification the same EXCEPT for relaxing the minimum a node is required to meet. Nodes that can process more options would be allowed to to do. That avoids disruption of systems that are already deployed and could be useful in limited domains. I do not see what is gained by requiring nodes to enforce a one-option limit.
>
> I think are suggesting the proposal be written as a minimum requirement.  A node could do more, but isn’t required to.
>
I think we also need guidance on minimum requirements of byte length
of options, EH, and header chains (lest intermediate nodes drop
packets with HBH for those reasons)

> I think the biggest issue with anything other than only process one HBH option or any number, is how does the node creating the packets know how many to include in a packet?    I don’t see much use for HBH if the sender puts in more than are likely be processed.

As I said, from a host POV I'm much less worried about whether all the
nodes process HBH; in fact, in some scenarios the HBH options might be
more or less targeted to some subset of intermediate nodes (for
instance the first upstream router that processes a FAST ticket, and
that might be intentionally not processed by other nodes in the path).
But, if even one node in the path drops the packet because it doesn't
like HBH then the whole mechanism is usable on that path.
>
> I suppose, we could create an IANA registry that defines a value for the minimum number of HBH options that SHOULD be processed by all nodes.   Over time if the capabilities of routers increased the number could be increased by an IETF specification.   This would be for Internet wide usage, limited domains could do more with local configuration.

Yes, that limit and limits on header lengths seem to be needed to move
HBH forward.

Tom

>
> Bob
>
>
>
>
> >
> > I note in passing that the proposal to extend RFC 8504 (IPv6 Node Requirements) to apply to intermediate systems would have the same general effect, but would put the simplicity vs capability tradeoff at a different point.
> >
> > Mike Heard
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------