Re: [spring] How CRH support SFC/Segment Endpoint option?

["Xiejingrong (Jingrong)" <[e-mail]>]

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:[e-mail]] On Behalf Of Robert Raszuk
Sent: Monday, May 25, 2020 4:57 PM
To: Ron Bonica <[e-mail]>
Cc: [e-mail]; 6man <[e-mail]>
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.