Re: Extension Header processing rules

[Gyan Mishra <[e-mail]>]

Bob

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

Destination Options header (note 1)


Do you see any technical issues with this solution.


Kind Regards


Gyan


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

>
> 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 <[e-mail]> 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,
>>
>> > On Nov 9, 2020, at 11:01 PM, [e-mail] wrote:
>> >
>> >
>> >
>> > 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.
>>
>>
>> If I understand your question, the answer to your question is in the excerpt I sent earlier:
>>
>> >    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.
>>
>> Specifically:
>>
>>    The contents and semantics of each extension header
>>    determine whether or not to proceed to the next header.
>>
>> Bob
>>
>>
>> >
>> > What do you think ?
>> >
>> >
>> >
>> > Regards,
>> >
>> > PSF
>> >
>> >
>> >
>> >
>> > >
>> > >
>> > > 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.
>> > >
>> > 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
>> >
>> > >
>> > >
>> > > Regards,
>> > >
>> > > PSF
>> > >
>> > >
>> > >
>> > > > On Nov 4, 2020, at 11:44 PM, [e-mail] 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
>> > >
>> > >
>> > >
>> > > >
>> > > > 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
>> > > >
>> > > > --------------------------------------------------------------------
>> > > > IETF IPv6 working group mailing list
>> > > > [e-mail]
>> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > > > --------------------------------------------------------------------
>> > >
>> > >
>> > > --------------------------------------------------------------------
>> > > IETF IPv6 working group mailing list
>> > > [e-mail]
>> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > > --------------------------------------------------------------------
>> >
>> >
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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