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

["C. M. Heard" <[e-mail]>]

On Thu, Mar 18, 2021 at 3:53 PM Bob Hinden  wrote:

> On Mar 13, 2021, at 4:36 PM, C. M. Heard wrote:
>
>> 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.
>

Yes, that was the idea.

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

If I am not mistaken, the alignment requirements for the various HbH
options are:

RA: 2n+0
CALIPSO: 4n+2
SMF_DPD: 4n+2 (inferred)
IOAM: 4n
RPL: 2n
Quick-Start: none (inferred)
Minimum Path MTU: 2n or 4n+2 (inferred)

> MPL: 4n+2 (inferred)
Jumbo Payload: 4n+2
IP_DFF: 4n+2 (inferred)

Some of the specifications do not explicitly specify the alignment
requirements; in those cases I have inferred the alignment requirements
from the diagrams.

The HbH header is aligned to an 8-octet boundary and starts with two
one-octet fields (Next Header and Hdr Ext Len). An option with alignment
requirements none, 2n, 4n+2,  8n+2, or none can be placed immediately after
Next Header and Hdr Ext Len with no pads. Of the above options, the only
one that does not meet that requirement is IOAM. Note that I have inferred
an alignment requirement of "none" for Quick-Start since the same option
data format is used for IPv4 and IPv6; however, 4n would also be a
reasonable inference.


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

That is a possibility, since the spec is still unpublished; but how hard is
it to skip either two PAD1's or a PADn with n=0?

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 [you] 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.
>

What I had in mind was a minimum of one option with the ability to do more
via local configuration.

Mike