Internet-Draft IPv6 Options Deployment March 2023
Peng, et al. Expires 14 September 2023 [Page]
Network Working Group
Intended Status:
S. Peng
Huawei Technologies
G. Fioccola
Huawei Technologies
J. Dong
Huawei Technologies

Deployment considerations of IPv6 packets with options


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.

Requirements Language

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.

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

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.

Table of Contents

1. Introduction

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.

2. Terminology

The terms used in this draft refer to the terminologies as defined in [RFC8200] and [RFC8754].

3. SRH TLV vs. DOH Options

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.

3.1. Usage scenarios

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.

3.2. Implementation

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.

3.3. Cost

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.

3.4. Deployment guidance

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.

4. Generic Option vs. Specific Option

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.

4.1. Implementation

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.

4.2. Extending the allocation space of Option Type

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.

4.2.1. Backwards compatibility

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.

5. Security Considerations

The security considerations can refer to [RFC8200], and [RFC8754].

6. IANA Considerations

This document does not include an IANA request.

7. Acknowledgements

The authors would like to acknowledge Stefano Previdi for his valuable review and comments.

8. References

8.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <>.
Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, , <>.
Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, G., and W. Liu, "Operational Implications of IPv6 Packets with Extension Headers", RFC 9098, DOI 10.17487/RFC9098, , <>.

8.2. Informative References

Herbert, T., "Limits on Sending and Processing IPv6 Extension Headers", Work in Progress, Internet-Draft, draft-ietf-6man-eh-limits-02, , <>.
Dong, J., Li, Z., Xie, C., Ma, C., and G. S. Mishra, "Carrying Virtual Transport Network (VTN) Information in IPv6 Extension Header", Work in Progress, Internet-Draft, draft-ietf-6man-enhanced-vpn-vtn-id-02, , <>.
Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options Processing Procedures", Work in Progress, Internet-Draft, draft-ietf-6man-hbh-processing-05, , <>.
Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-ipv6-options-10, , <>.
Iurman, J., "Carrying an Identifier in IPv6 packets", Work in Progress, Internet-Draft, draft-iurman-6man-carry-identifier-00, , <>.
Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, , <>.
Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. Pang, "IPv6 Application of the Alternate-Marking Method", RFC 9343, DOI 10.17487/RFC9343, , <>.

Authors' Addresses

Shuping Peng
Huawei Technologies
Giuseppe Fioccola
Huawei Technologies
Jie Dong
Huawei Technologies