Network Working Group T. Herbert Internet-Draft XDPnet Updates: RFC8200 (if approved) 29 December 2025 Intended status: Standards Track Expires: 2 July 2026 Deprecate IPv6 Destination Options Before the Routing Header draft-herbert-deprecate-destops-before-rh-00 Abstract This document deprecates Destination Options before the Routing header. It also requires that if a Routing header is present in a packet then it must immediately follow the IPv6 header or immediately follow the Hop-by-Hop Options header if an Hop-by-Hop Options header is also present in the packet. These requirements imply that at most one Routing header may be present in a packet. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 2 July 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Herbert Expires 2 July 2026 [Page 1] Internet-Draft Deprecate DestOpts Before RH December 2025 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Motivation to deprecate DestOpts before the Routing Header . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Motivation to restrict the Routing header to one ocurrence and follow IPv6 or Hop-by-Hop options . . . . . . . . . . 3 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Updates to RFC8200 . . . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 5.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This document deprecates IPv6 Destination Options before the Routing header since there are no known deployments or uses for it. A related requirement is that if a Routing header is present then it must immediately follow the IPv6 header or immediately follow the Hop-by-Hop Options header if a Hop-by-Hop Options header is also present. These requirements imply that a packet may contain at most one Routing header. 1.1. Motivation to deprecate DestOpts before the Routing Header Destination Options before the Routing are defined by [RFC8200] as a Destination Options header with options that are processed by each intermediate node in a Routing header and the final destination. Destination options before the Routing header have not proven useful and there is either very little or no deployment. None of the IANA registered Destination options [IANA-IPV6-PARAMS] are designed for use as Destination options before the Routing header. While it's conceivable that someone may be performing experiments with Destination options before the Routing header using RFC3692-style Experiment types, it does not seem likely that any Destination options intended to be in Destination Options before the Routing Herbert Expires 2 July 2026 [Page 2] Internet-Draft Deprecate DestOpts Before RH December 2025 header will be standardized in the foreseeable future. In lieu of using Destination Options before the Routing header to convey optional information to each intermediate node, the Routing header itself may contain its own options that are processed by each intermediate node. This is the case of Segment Routing (SRv6) [RFC8574] wherein TLVs as are defined as part of the SRv6 Routing header. Since the Routing header can have its own options, Destination options before the Routing header are redundant and unnecessary. There are a handful of other Routing headers defined, however they have limited deployment and even if they are deployed it's not likely that Destination options before the Routing header are also used. 1.2. Motivation to restrict the Routing header to one ocurrence and follow IPv6 or Hop-by-Hop options If Destination options before the Routing header are eliminated then the prescribed extension header ordering in [RFC8200] becomes IPv6 header, followed by Hop-by-Hop Options, followed by the Routing Header. The intermediate nodes in a routing header are much more closer to routers than hosts in implementation, and in fact nodes that process the routing header are effectively routers that are often implemented in a hardware forwarding plane. Performance is paramount so it's reasonable to require that the routing header be set as as one of the first headers in a packet to avoid requiring an implementation to fish through a stack of extension headers to find the Routing header (if the Routing header isn't easily accessible it's likely that an implementation would drop the packet). If a Routing header must follow the IPv6 header or Hop-by-Hop options header then that precludes the possibility of more than one Routing header being present in a packet. If it's desirable to route a packet with more than one Routing header then the packet can be tunneled in IPv6-IPv6 encapsulation where the outer header contains the first Routing header, and the inner header contains the second Routing header. 1.3. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Herbert Expires 2 July 2026 [Page 3] Internet-Draft Deprecate DestOpts Before RH December 2025 2. Updates to RFC8200 Both the requirements for deprecating Destination Options before the Routing header and requirements for the ordering of the Routing header relative to other extension headers can be specified as updates to [RFC8200]. The following text replaces the list and notes of Section 4.1 of [RFC8200]. OLD (RFC8200) | 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]. | | note 3: for options to be processed only by the final | destination of the packet. NEW: | IPv6 header | Hop-by-Hop Options header | Routing header | Fragment header | Authentication header (note 1) | Encapsulating Security Payload header (note 1) | Destination Options header | Upper-Layer header | | note 1: additional recommendations regarding the relative | order of the Authentication and Encapsulating Security | Payload headers are given in [RFC4303]. Herbert Expires 2 July 2026 [Page 4] Internet-Draft Deprecate DestOpts Before RH December 2025 The following text replaces the paragraph after the list and notes of Section 4.1 of [RFC8200]. OLD (RFC8200) | 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). NEW: | Each extension header should occur at most once. The following text replaces the fourth paragraph after the list and notes of Section 4.1 of [RFC8200]. OLD (RFC8200) | 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. NEW: | 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 and the Routing | header. Hop-by-Options is restricted to appear immediately | after an IPv6 header only, the Routing header is restricted to | appear immediately after an IPv6 header or immediately after a | Hop-by-Hop Options header. Nonetheless, it is strongly advised | that sources of IPv6 packets adhere to the above recommended | order until and unless subsequent specifications revise that | recommendation. The following text replaces the first paragraph of Section 4.4 of [RFC8200]. OLD (RFC8200) | The Routing header is used by an IPv6 source to list one or | more intermediate nodes to be "visited" on the way to a | packet's destination. This function is very similar to IPv4's Herbert Expires 2 July 2026 [Page 5] Internet-Draft Deprecate DestOpts Before RH December 2025 | Loose Source and Record Route option. The Routing header is | identified by a Next Header value of 43 in the immediately | preceding header and has the following format: NEW: | The Routing header is used by an IPv6 source to list one or | more intermediate nodes to be "visited" on the way to a | packet's destination. This function is very similar to IPv4's | Loose Source and Record Route option. The Routing header, when | present, must immediately follow an IPv6 header or immediately | follow a Hop-by-Hop Options header if it is also present. The | Routing header is identified by a Next Header value of 43 in | the immediately preceding header and has the following format: 3. IANA Considerations There are no actions required for IANA defined in this document. 4. Security Considerations This document does not introduce any new security concerns. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 5.2. Informative References [IANA-IPV6-PARAMS] "Assigned Internet Protocol Numbers", . Herbert Expires 2 July 2026 [Page 6] Internet-Draft Deprecate DestOpts Before RH December 2025 [RFC8574] Van de Sompel, H., Nelson, M., Bilder, G., Kunze, J., and S. Warner, "cite-as: A Link Relation to Convey a Preferred URI for Referencing", RFC 8574, DOI 10.17487/RFC8574, April 2019, . Author's Address Tom Herbert XDPnet Los Gatos, CA, United States of America Email: tom@herbertland.com Herbert Expires 2 July 2026 [Page 7]