



Network Working Group                                         T. Herbert
Internet-Draft                                                    XDPnet
Updates: RFC8200 (if approved)                            7 January 2026
Intended status: Standards Track                                        
Expires: 11 July 2026


      Deprecate IPv6 Destination Options Before the Routing Header
              draft-herbert-deprecate-destops-before-rh-01

Abstract

   This document deprecates IPv6 Destination Options before the Routing
   header since there are no known deployments or uses for the
   Destination Options Header placed ahead in precedence of 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 11 July 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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



Herbert                   Expires 11 July 2026                  [Page 1]

Internet-Draft        Deprecate DestOpts Before RH          January 2026


   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.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     6.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
   header will be standardized in the foreseeable future.






Herbert                   Expires 11 July 2026                  [Page 2]

Internet-Draft        Deprecate DestOpts Before RH          January 2026


   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 11 July 2026                  [Page 3]

Internet-Draft        Deprecate DestOpts Before RH          January 2026


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 11 July 2026                  [Page 4]

Internet-Draft        Deprecate DestOpts Before RH          January 2026


   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 11 July 2026                  [Page 5]

Internet-Draft        Deprecate DestOpts Before RH          January 2026


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

   The author would like to thank Jeremy Duncan for their comments and
   suggestions that improved this document.

4.  IANA Considerations

   There are no actions required for IANA defined in this document.

5.  Security Considerations

   This document does not introduce any new security concerns.

6.  References

6.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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

6.2.  Informative References




Herbert                   Expires 11 July 2026                  [Page 6]

Internet-Draft        Deprecate DestOpts Before RH          January 2026


   [IANA-IPV6-PARAMS]
              "Assigned Internet Protocol Numbers",
              <//https://www.iana.org/assignments/ipv6-parameters/
              ipv6-parameters.xhtml>.

   [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, <https://www.rfc-editor.org/info/rfc8574>.

Author's Address

   Tom Herbert
   XDPnet
   Los Gatos, CA,
   United States of America
   Email: tom@herbertland.com


































Herbert                   Expires 11 July 2026                  [Page 7]
