HBH Option Header Configuration (draft-hinden-6man-hbh-processing)

[Bob Hinden <[e-mail]>]

Gorry and I are going over the comments received on draft-hinden-6man-hbh-processing-01, thanks very much for your comments, it is very helpful.  We are working on respond to them.

One issue that is common to several questions is what does configuration mean regarding HBH Option headers.    Our draft and in hindsight RFC8200 is not clear what this means.   The note in Section 4 of RFC8200:

  NOTE: While [RFC2460] required that all nodes must examine and
  process the Hop-by-Hop Options header, it is now expected that nodes
  along a packet's delivery path only examine and process the
  Hop-by-Hop Options header if explicitly configured to do so.

This can be interpreted to mean a configuration flag allowing/disallowing processing of a HBH Option Header, or specific configuration for each HBH Option type.

draft-hinden-6man-hbh-processing-01 says:

  This document updates [RFC8200] that a
  node MUST process the first Option in the Hop-by-Hop Header in the
  Fast Path and MAY process additional Hop-by-Hop Options if configured
  to do so.

Several people asked if we are proposing to remove the ability to not process the HBH Option Header.

We have discussed this and conclude that yes, we are proposing to require all nodes to examine and process the first HBH Option in the Fast Path.   Not just drop packets with HBH Option Headers.  This change needs to be made clearer in the draft.

If it is allowed to not process any HBH Options, then we don’t see any purpose for this draft.   We do want to require that a router examine and process one HBH Option in the Fast Path.

We note that while RFC8200, and it’s predecessors, didn’t call it out specifically, if did infer that a node would have code and/or configuration for each possible HBH Option Type.   Otherwise, it wouldn’t say:

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

and there would be no reason for the two high order bits in the Option Type that describe the action.  The draft doesn’t change this.

We do note that per option configuration could be set to not support any options, that would be allowed, but it would require a router to follow the two high order bits in the Option type that control if the packet should be dropped or forwarded for at least the first option, and any other options that it was configured to support.

Comments?

Bob & Gorry