Re: Comments on draft-li-6man-enhanced-extension-header Sec 2.1

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

On Wed, Jul 10, 2019 at 6:38 AM Pengshuping (Peng Shuping) wrote:
> Take the IOAM as an example, the action needs to be performed hop by
> hop along the path. However, when some routers along the path enable
> the processing of the HBH but others just ignore it. Then the IOAM
> service fails. Therefore, the enforcement of the processing of the
> HBH according to the service requirements would be required in the
> procedure wise.

So what you want is a Hop-by-Hop Options header that all nodes along
the path must process. As Mark pointed out, we've been down that road
before: both RFC 2460 Section 4.3
<https://tools.ietf.org/html/rfc2460#section-4.3> and RFC 1883 Section 4.3
<https://tools.ietf.org/html/rfc1883#section-4.3> (its
predecessor) contained the following text.

   The Hop-by-Hop Options header is used to carry optional information
   that must be examined by every node along a packet's delivery path.


In the 2+ decades following the publication of RFC 1883 that idea never
caught on, That's why RFC 8200 Section 4 added the note

   NOTE: While [RFC2460 <https://tools.ietf.org/html/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.


and why RFC 8200 Section 4.3
<https://tools.ietf.org/html/rfc8200#section-4.3> now says

   The Hop-by-Hop Options header is used to carry optional information
   that may be examined and processed by every node along a packet's
   delivery path.


Based on the decades of  experience, it's fair to say that the true
hop-by-hop behavior as needed for IOAM to work cannot be expected in
the general Internet. Putting the Hop-by-Hop Options header in a
new Next Header type will not magically change that. It will, however,
cause backward compatibility problems in end systems, because they
will see an unknown Next Header type and drop the packet (see
RFC 8200 Section 4 <https://tools.ietf.org/html/rfc8200#section-4>):

   If, as a result of processing a header, the destination node is
   required to proceed to the next header but the Next Header value in
   the current header is unrecognized by the node, it should discard the
   packet and send an ICMP Parameter Problem message to the source of
   the packet, with an ICMP Code value of 1 ("unrecognized Next Header
   type encountered") and the ICMP Pointer field containing the offset
   of the unrecognized value within the original packet.  The same
   action should be taken if a node encounters a Next Header value of
   zero in any header other than an IPv6 header.


The best that can be expected is that true hop-by-hop behavior, as
required for IOAM to work as desired, can be made to work in a
controlled environment (aka limited domain) wherein every router is
able to process the Hop-by-Hop Options header at wire speed and has
been configured to do so. A new Next Header type is not needed to
accomplish that.

Mike Heard