| Internet-Draft | IPv6 Options Deployment | March 2023 |
| Peng, et al. | Expires 14 September 2023 | [Page] |
As more and more new services using IPv6 options have been proposed and start being deployed in a large-scale network environment, issues also start showing up in deployments. This document describes and analyzes the issues encountered, and aims to provide deployment guidance when the IPv6 options are used.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 14 September 2023.¶
Copyright (c) 2023 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 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.¶
More and more new services using IPv6 options, such as [I-D.ietf-ippm-ioam-ipv6-options], Alternate Marking Method [RFC9343], Minimum Path MTU Hop-by-Hop Option [RFC9268], and Virtual Transport Network (VTN) [I-D.ietf-6man-enhanced-vpn-vtn-id], have been proposed. They start being deployed in a large-scale network environment. However, since IPv6 especially with options has not been widely deployed, some issues start showing up in deployments [RFC9098]. It is important to analyze these issues, provide guidance on their reasonable usages, and help progress their deployments in large-scale networks [I-D.ietf-6man-eh-limits].¶
This document describes and analyzes the issues encountered, and aims to provide deployment guidance when the IPv6 options are used.¶
The terms used in this draft refer to the terminologies as defined in [RFC8200] and [RFC8754].¶
As specified in [RFC8200], the Destination Options header (DOH) is used to carry optional information that needs be examined only by a packet's destination node(s). When a Routing header (RH) exists, the DOH before RH is "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", while the one after RH is "for options to be processed only by the final destination of the packet".¶
As specified in [RFC8754], SR segment endpoint nodes process the local segment (SID) corresponding to the packet destination address (DA). Then, the DA is updated according to the segment list. The Segment Routing Header TLV (SRH TLV) provides metadata for segment processing, while processing the SID, if the node is locally configured to do so.¶
From the aspect of processing function, both the DOH before RH and SRH TLV are processed at the node being indicated in the DA field of the IPv6 header. Both can co-exist according to current specifications, which raises an issue of choice phobia in deployments.¶
The two options are analyzed in the following aspects to provide deployment guidance.¶
In an IPv6 network without SRv6 being supported, i.e., in an IPv6 header with a RH but not SRH, the DOH is required to carry the options to be processed by the first destination that appears in the IPv6 DA field plus subsequent destinations listed in the RH.¶
When SRv6 is supported, there are two places in the IPv6 header to carry the options that can be processed on each SRv6 nodes. DOH is designed for more general IPv6 usages, while SRH TLV is appended to SRH and designed for SRv6 usage only.¶
SRH TLV and DOH are generally two functional modules in the forwarding plane. Some devices may support the processing of SRH TLV but not DOH at the same time and vice versa.¶
SRH and SRH TLV are integrated modules, while DOH is a more independent general IPv6 functional module.¶
Supporting two modules (DOH and SRH TLV) at the same time consume more cost, so most of time only one module is supported for the same functional requirement.¶
When both modules are supported, since SRH TLV is appended to SRH and separated from other IPv6 options, the confliction with others is minimal.¶
The capabilities of devices in network should be evaluated before supporting any new services. Capability advertisement mechanisms can be utilized.¶
The holding place choice is up to network operators, depending on the service requirements and network device capabilities, etc.¶
When SRH TLV and DoH and other extension headers coexist, SRH TLV is recommended to carry SRv6 related information.¶
Duplication of the same option in different places should be avoided.¶
As more and more new services using IPv6 options being proposed, there is a concern that the allocation space for option types may quickly exhaust. Therefore, solution such as generic identifier option [I-D.iurman-6man-carry-identifier] has been proposed.¶
However, each of the newly proposed options is designed for a specific service. As specified in [RFC8200], "there has to be a very clear justification why any new hop-by-hop option is needed before it is standardized.". These services have already justified their needs before they are proposed and standardized.¶
As specified in [I-D.ietf-6man-hbh-processing], the new hop-by-hop options should be straight forward to process. That is, new Hop-by-Hop options SHOULD be designed to ensure the node can process the options at the full forwarding rate (e.g., on the router's Fast Path).¶
Such generic option raises the implementation and processing requirements, while specific option is designed for specific service usage which eases implementations and is straight forward to process.¶
As specified in [RFC8200], the option type is a 8-bit identifier of the type of option. The highest-order 2 bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type, and the third-highest-order bit of the Option Type specifies whether or not the Option Data of that option can change en route to the packet's final destination. The three high-order bits described above are to be treated as part of the Option Type, not independent of the Option Type. So the allocation space left for new options are actually left to 5 bits. The concern for quickly exhaustion makes sense.¶
The root cause for quick exhaustion is the allocation space of the option type itself is limited. As more and more new services being proposed and standardized, a way of holding more options need to be figured out.¶
The allocation space extension design should consider the backwards compatibility, that is, it should not affect the processing of the existing option types on devices.¶
The security considerations can refer to [RFC8200], and [RFC8754].¶
This document does not include an IANA request.¶
The authors would like to acknowledge Stefano Previdi for his valuable review and comments.¶