Hi ! Let me jump to this topic, and tell a fact first: Most design examples of DOH in RFCs so far do NOT follow the “recommended order” of RFC1883/2460/8200.
EXAMPLE1: RFC3775/3776/4584/6275 requires DOH carrying a specific option is located after RH and before Fragmentation/AH/ESP (copied from RFC6275) ---- This does NOT follow the “recommended” order of 8200. The Home Address option is carried by the Destination Option extension header (Next Header value = 60). The Home Address option MUST be placed as follows: o After the routing header, if that header is present o Before the Fragment Header, if that header is present EXAMPLE2: 7837 requires DOH before Frag/AH/ESP! ---- This does NOT follow the “recommended” order of 8200. The CDO SHOULD be placed as the first option in the Destination Option header before the AH [RFC4302] and/or Encapsulating Security Payload (ESP) [RFC4303] (if present). Text about “EH order” from 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. There are some words for the 8200 recommended order: “recommended”, “strongly advised …. Adhere to the above recommended order” There are some other words for the other side: “their ordering constraints …. must be specified”, “IPv6 nodes must accept and attempt to process extension headers in any order”. My reading of this text (inheritance of RFC1883/2460): (1) It is the responsibility of those who want to design solution based on IPv6 EH to define the order of IPv6 EH, and to tell why the “ordering constraints” of the proposal is. (2) The “recommended order” of RFC8200 does not make a proposal superior than others IMO. Additional comments to “DOH will be examined at each segment endpoint hop if DOH is present.”: I agree and I’d like to add an additional note IMO to this: The DOH could be used alone (without a following RH) to be processed by a “segment endpoint”, as long as the DA of a packet is the IPv6 address of the “segment endpoint” node! The BIERv6 design is a case of this, use DOH alone (without a following RH) in common case, and requires DOH carrying a BIER option is located after RH if present and before Fragmentation/AH/ESP if present. https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06 Again please feel welcome to take this into discussion and consideration! Thanks Jingrong From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Robert Raszuk Sent: Monday, May 25, 2020 5:33 AM To: Tom Herbert <t...@herbertland.com> Cc: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org>; spring@ietf.org; 6man <6...@ietf.org> Subject: Re: [spring] How CRH support SFC/Segment Endpoint option? Hi Tom, Thank you ! That confirms my understanding ie that DOH will be examined at each segment endpoint hop if DOH is present. So just like PSSI or TPF suggest a build in filtering (for example by target ID) is required to avoid misuse. Kind regards, Robert. Robert, Look at Destination Options before the routing header in RFC8200. These are intended to be processed at every intermediate destination in the routing header and precede any fragment header. Tom
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
