Hi Robert,

"What … would happen … if there is no Routing Header at all and I still modify 
DA at each segment endpoint"
----Good question. I saw no less than 2 existing drafts and no less than 2 
potential proposals with this behavior, and IMO they are all reasonable.

Or reading the RFC8200 verbatim first DOH must be placed before RH hence to 
have more then one DOH in a packet RH is mandatory
----2nd good question. I saw no less than 2 RFCs that have 3 DOHs in it 
optionally.
----I believe there could be more than one DOH in a packet without mandatory of 
requiring DOH before RH,  per below [1] (a higher level observation of IPv6 
design IMO, not just the “recommended” text).

What exactly tells the router to process or not to process last 4 headers ? Is 
there a rule anywhere that unless RH is present and segments left = 0 
destination must not follow next header in RH ?
----3rd good question. A router does NOT check/assume/guarantee the “8200 
recommended order” at all IMO (would you do that?). Once a packet with the DA 
being the IPv6 address of a node is received, the node just “catch” it to its 
local-process.
----I believe below [2]  is another higher level observation of IPv6 design IMO 
about “EH order” from implementation view, not just the “recommended order” 
text.

In summary, I believe the “recommended order” of RFC8200 does not make a 
proposal superior than others at all.

Thanks
Jingrong


[1] RFC8200
   Defining new IPv6 extension headers is not recommended, unless there
   are no existing IPv6 extension headers that can be used by specifying
   a new option for that IPv6 extension header.  A proposal to specify a
   new IPv6 extension header must include a detailed technical
   explanation of why an existing IPv6 extension header can not be used
   for the desired new function.  See [RFC6564] for additional
   background information.

   Instead of defining new extension headers, it is recommended that the
   Destination Options header is used to carry optional information that
   must be examined only by a packet's destination node(s), because they
   provide better handling and backward compatibility.

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

   If and when other extension headers are defined, their ordering
   constraints relative to the above listed headers must be specified.

   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.



From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Monday, May 25, 2020 4:57 PM
To: Ron Bonica <rbon...@juniper.net>
Cc: spring@ietf.org; 6man <6...@ietf.org>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?

Hi Ron,

So what in your opinion would happen with the below if there is no Routing 
Header at all and I still modify DA at each segment endpoint ?

Can I still put two Destination options ?

Or reading the RFC8200 verbatim first DOH must be placed before RH hence to 
have more then one DOH in a packet RH is mandatory ?

If so can it contain only 4 octets and no type specific data (so called be a 
NULL RH) ?

What exactly tells the router to process or not to process last 4 headers ? Is 
there a rule anywhere that unless RH is present and segments left = 0 
destination must not follow next header in RH ?

Thank you,
R.


IPv6 extension header are ordered as follows:

- Headers processed at every node along the delivery path
        - Hop-by-hop
- Headers processed at every segment endpoint
        - Destination options
        - Routing header
- Headers processed at the ultimate destination only
        - Fragment header
        - Authentication header
        - ESP header
        - Destination Options header

Note that the Destination Options header is the only extension header that can 
appear twice in a packet. The Destination Options header must immediately 
precede the Routing header or the upper-0layer header.

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to