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

[Bob Hinden <[e-mail]>]

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.


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

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.

> 
> 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 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 liekly be processed.

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.

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