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

[Tianran Zhou <[e-mail]>]

Hi Mike,

On the following words, I am still not clear. If the node is able or configured to examine and process the hbh header, we still do not know whether it can be processed in fast path.

   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.

I find one relevant draft, but it’s expired.
https://www.ietf.org/archive/id/draft-ietf-6man-hbh-header-handling-03.txt


Tianran

From: ipv6 [mailto:[e-mail]] On Behalf Of C. M. Heard
Sent: Wednesday, July 10, 2019 11:14 PM
To: Pengshuping (Peng Shuping) <[e-mail]>
Cc: 6man WG <[e-mail]>
Subject: Re: Comments on draft-li-6man-enhanced-extension-header Sec 2.1

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