Re: Extension Header processing rules

[Bob Hinden <[e-mail]>]

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
> > --------------------------------------------------------------------
> 
>