Hop-by-hop options in 2460bis

[Tom Herbert <[e-mail]>]

>From the draft:

"It should be noted that due to performance restrictions nodes may
ignore the Hop-by-Hop Option header, drop packets containing a
hop-by-hop option header, or assign packets containing a hop-by-hop
option header to a slow processing path.  Designers planning to use a
hop-by-hop option need to be aware of this likely behaviour."

This effectively makes deployment of Hop-by-Hop options a nonstarter.
For instance, if my packets go through ten routers to a destination,
and nine routers implement the my HBH option but the tenth drops it,
then HBH is unusable for that destination. Also, with this text we
cannot claim that the tenth router is out of compliance, and if the
tenth router throws HBH into a slow path instead that doesn't really
help us much either to deploy at scale.

If processing HBH is a performance issue then a node should ignore it.
I suggest this alternate text for the above paragraph.

"A intermediate node in the path of a packet MUST either process the
Hop-by-Hop Option header or ignore it. A node MUST NOT drop a packet
solely on the basis that the Hop-by-Hop Option header is present."


Also, I think there is also a potential ambiguity is this text:

"The Option Type identifiers are internally encoded such that their
highest-order two bits specify the action that must be taken if the
processing IPv6 node does not recognize the Option Type:"

Since intermediate nodes can process HBH options are they expected to
take this actions? I think the answer should be no, it seems like only
the receiver should be allowed to drop packets with unknown options.
Note that if intermediate nodes are allowed to ignore the HBH option
this might be in conflict with the rules about handling unrecognized
options-- all options in that case are implicitly skipped.

Tom