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

[Tom Herbert <[e-mail]>]

On Sat, Mar 13, 2021 at 5:37 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.
>
> It seems to me that the draft has chosen the most disruptive possible way to restrict the number of options in the HbH header. 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
>

Hi Mike,

I might suggest that this could be generalized as:

1. An intermediate node may process all HBH options (per RFC8200)
2. An intermediate node may ignore all HBH options (the relaxed
requirement in RFC8200)
3. An intermediate may process a subset of the HBH options. The subset
of options processed for some packet would be precisely the first N
consecutive non-padding options. The remaining options, those after
the first N options would be ignored.

N could be determined per device subject to limits such as the number
of HBH options a node is willing to process, or the byte length of the
EH or IP header chain. Coincident with these requirements should be
some SHOULDs to give guidance to the host creating HBH options: like
an intermediate device that processes HBH options SHOULD process at
least the first 8 non-padding options, and SHOULD process HBH options
that fit within the first 148 bytes of the packet (the value of 8 is
derived from the suggested limit in RFC8504, and the 148 bytes is
based on the assumption that parsing buffers in modern routers are
typically at least 256 bytes, so IPv6 header and 128 bytes of options
is 148 bytes and leaves 106 bytes following HBH EH for router to
parse. If a device fixes N to be one this degenerates to your
proposal. If N=0 that degenerates to #1, if N=inifinity that
degenerates to #2.

This model does imply that hosts should not create option lists that
creates a processing dependency from one option on a later option. The
sending host would need to assume that any number of consecutive
options might be processed, and trailing options ignored. I haven't
looked closely, but I don't think offhand there are any defined
options that would break things if this subset processing happened.
The host would also be motivated to order the options by the
importance that they are processed.

Tom

> 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. Alternative (b) would avoid even that, but it would also require a bit more work from a compliant node.
>
> 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 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
> --------------------------------------------------------------------