Subject: Extension Header processing rules

From: <[email-masked]>
Date: Thu, 5 Nov 2020 15:44:04 +0800 (CST)

Hi 6man experts,

RFC8200 mention that extension headers must be processed strictly in the order they appear in the packet, but there are not explicit description for that when an EH is finished processing it must continue to process the next EH. Is this an obvious behavior so that no necessary to describe explicitly, or a local behavior that can be controlled? 

For example, for the follow packet,

   IPv6 Header + DOH + Upper-layer

At the destination node, normal demultiplexing on the Next Header field of the IPv6 header invokes the module to process the DOH. When DOH is finished processing, should the upper-layer be processed ? or not be processed by local policy ? What is the standard behavior ?

In addition to DOH, same question is for HBH.

Regards,

PSF

---

From: Bob Hinden <[email-masked]>
Date: Thu, 5 Nov 2020 10:22:44 -0800

Hi,

> On Nov 4, 2020, at 11:44 PM, [email-masked] wrote:
> 
> 
> 
> Hi 6man experts,
> 
> RFC8200 mention that extension headers must be processed strictly in the order they appear in the packet, but there are

It doesn’t mention, it specifies.

> not explicit description for that when an EH is finished processing it must continue to process the next EH. Is this an obvious behavior so that no necessary to describe explicitly, or a local behavior that can be controlled?

It is an obvious behavior.   That is why the field is called the “Next Header”.  I think the relavant text from Section 4 is:

   At the destination node, normal demultiplexing on the Next Header
   field of the IPv6 header invokes the module to process the first
   extension header, or the upper-layer header if no extension header is
   present.  The contents and semantics of each extension header
   determine whether or not to proceed to the next header.  Therefore,
   extension headers must be processed strictly in the order they appear
   in the packet; a receiver must not, for example, scan through a
   packet looking for a particular kind of extension header and process
   that header prior to processing all preceding ones.

Note the last sentence where is says a receiver must not scan through a packet….

Bob

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: <[email-masked]>
Date: Fri, 6 Nov 2020 10:44:12 +0800 (CST)

Hi Bob,

Thanks for you reply.

I think that's the intuition of most people, even after more thinking about it.

Regards,

PSF

原始邮件

发件人：BobHinden
收件人：彭少富10053815;
抄送人：Bob Hinden;IPv6 List;
日 期 ：2020年11月06日 02:23
主 题 ：Re: Extension Header processing rules 

Hi,

Bob

---

From: <[email-masked]>
Date: Mon, 9 Nov 2020 17:32:38 +0800 (CST)

Hi Bob,

Excuse me, I have other doubts.

I don't know what principles IPv6 followed when designing IPv6 Extension Heads, maybe these principles determine the application scenarios of each Extension Head.

For example, why not use DOH to realize the function of RH, just like the loose source and record route (LSRR) option defined in RFC791 ?

Regards,

PSF

Bob

---

From: Tom Herbert <[email-masked]>
Date: Mon, 9 Nov 2020 07:56:25 -0800

> I don't know what principles IPv6 followed when designing IPv6 Extension Heads, maybe these principles determine the application scenarios of each Extension Head.
Right having different type extension of extensions facilitates
different use cases and efficient implementation. For instance,
there's separate Hop-by-Hop Options and Destination Options because
the former needs to be processed by all nodes in the path, and the
latter is just processed by the destination so an intermediate node
doesn't have to burn cycles processing options that are only of
consequence at the end nodes.

> For example, why not use DOH to realize the function of RH, just like the loose source and record route (LSRR) option defined in RFC791 ?
Conceivably that could be done, but having a separate extension header
devoted to just one purpose leads to more efficient implementation in
high speed devices (serially parsing a potentially long list of
options to find a routing header might be prohibitive in
implementation). Another thing to point out is that IPv4 options,
including LSRR, weren't exactly a success; the extension header model
of IPv6 attempts to correct some of the deficiencies in IPv4 options.

Tom

---

From: <[email-masked]>
Date: Tue, 10 Nov 2020 15:01:58 +0800 (CST)

Hi Tom, and Bob,

Thank you for sharing your opinion. I totally agree with that.

So, in general, we should discuss all kinds of Extension Header under the IPv6 specification, not simply equate them with IPv4 options. I think there are differences in semantics.

Now I am faced with the implementation of DOH related functions, and try to get a clear processing rule for DOH. According to your opinon the design of DOH has its specific purpose to provide optional information to end nodes. Therefore, when the packet arrives at the end node and all the options in the DOH are processed strictly in the order, the processing rule I'm trying to get is: the next header should be parsed. I think this processing rule is also Bob's answer to me. 

However, I'm worried that the problem will go beyond design principles. If, I mean if, in DOH it also implements the function similar to RH, in this case when the source route entries in the related option have not been traversed, obviously the next header should not be parsed. This (i.e, whether to parse next header is decided by an option) brings confusion and complexity to the DOH's processing rules, because DOH can contain multiple options and the decisions for each option may be inconsistent. I don't think we should encourage DOH to do this under the IPv6 specification.

What do you think ?

Regards,

PSF

Tom

---

From: Bob Hinden <[email-masked]>
Date: Tue, 10 Nov 2020 11:50:40 -0800

Peng,

> On Nov 9, 2020, at 11:01 PM, [email-masked] wrote:
> 
> 
> 
> Hi Tom, and Bob,
> 
> 
> 

>    that header prior to processing all preceding ones.

Specifically:

   The contents and semantics of each extension header
   determine whether or not to proceed to the next header.

Bob

---

From: <[email-masked]>
Date: Wed, 11 Nov 2020 17:50:32 +0800 (CST)

Hi Bob,

I think the sentence "The contents and semantics of each extension header determine whether or not to proceed to the next header." is certainly true for any extension headers, but it's too general. In fact, the same sentence applies to IPv4 option.

I mean, since we have defined various specific extension headers with different purposes in IPv6, thus, is it necessary to define more specific individual processing rules for each extension header in separate documents, rather than an overview of the general statement ?

Regards,

PSF

Peng,

Specifically:

Bob

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 11 Nov 2020 22:43:06 -0500

In BIERv6 processing we encode the BIER header in DOH and we set flag for
en route hop by bop processing.  This does end up getting processed in the
slow path similar to hbh, however maybe newer hardware maybe able to
process in the fast path.

https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-00

RFC 8200

   When more than one extension header is used in the same packet, it is
   recommended that those headers appear in the following order:

      IPv6 header
      Hop-by-Hop Options header
      Destination Options header (note 1)
      Routing header
      Fragment header
      Authentication header (note 2)
      Encapsulating Security Payload header (note 2)
      Destination Options header (note 3)
      Upper-Layer header

      note 1: for options to be processed by the first destination that
              appears in the IPv6 Destination Address field plus
              subsequent destinations listed in the Routing header.

      note 2: additional recommendations regarding the relative order of
              the Authentication and Encapsulating Security Payload
              headers are given in [RFC4303
<https://tools.ietf.org/html/rfc4303>].

   Each extension header should occur at most once, except for the
   Destination Options header, which should occur at most twice (once
   before a Routing header and once before the upper-layer header).

   IPv6 nodes must accept and attempt to process extension headers in
   any order and occurring any number of times in the same packet,
   except for the Hop-by-Hop Options header, which is restricted to
   appear immediately after an IPv6 header only.  Nonetheless, it is
   strongly advised that sources of IPv6 packets adhere to the above
   recommended order until and unless subsequent specifications revise
   that recommendation.

4.2 <https://tools.ietf.org/html/rfc8200#section-4.2>.  Options

   Two of the currently defined extension headers specified in this
   document -- the Hop-by-Hop Options header and the Destination Options
   header -- carry a variable number of "options" that are type-length-
   value (TLV) encoded in the following format:

The third-highest-order bit of the Option Type specifies whether or
   not the Option Data of that option can change en route to the
   packet's final destination.

   The three high-order bits described above are to be treated as part
   of the Option Type, not independent of the Option Type.  That is, a
   particular option is identified by a full 8-bit Option Type, not just
   the low-order 5 bits of an Option Type.

value.

       0 - Option Data does not change en route

       1 - Option Data may change en route

So with BIER v6 we set the 3rd higher order options bit for en route hop by
hop bier header processing.

On Wed, Nov 11, 2020 at 4:51 AM <[email-masked]> wrote:

>
> Hi Bob,
>
>
> I think the sentence "
> The contents and semantics of each extension header determine whether or not to proceed to the next header."
> is certainly true for any extension headers, but it's too general. In
> fact, the same sentence applies to IPv4 option.
>
> I mean, since we have defined various specific extension headers with
> different purposes in IPv6, thus, is it necessary to define more specific
> individual processing rules for each extension header in separate
> documents, rather than an overview of the general statement ?
>
>
> Regards,
>
> PSF
>
>
>
>
> Peng,
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 11 Nov 2020 22:50:30 -0500

Bob

So in our use case we are using note 1 for doh en route hop by hop BIER
header processing.

Do you see any technical issues with this solution.

Kind Regards

Gyan

On Wed, Nov 11, 2020 at 10:43 PM Gyan Mishra <[email-masked]> wrote:

>               headers are given in [RFC4303 <https://tools.ietf.org/html/rfc4303>].
>
>
> So with BIER v6 we set the 3rd higher order options bit for en route hop
> by hop bier header processing.
>
>

*Gyan Mishra*