Network Working Group S. Peng Internet-Draft G. Fioccola Intended status: Informational J. Dong Expires: 14 September 2023 Huawei Technologies 13 March 2023 Deployment considerations of IPv6 packets with options draft-peng-v6ops-eh-deployment-considerations-00 Abstract 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 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 Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Peng, et al. Expires 14 September 2023 [Page 1] Internet-Draft IPv6 Options Deployment March 2023 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. SRH TLV vs. DOH Options . . . . . . . . . . . . . . . . . . . 3 3.1. Usage scenarios . . . . . . . . . . . . . . . . . . . . . 3 3.2. Implementation . . . . . . . . . . . . . . . . . . . . . 4 3.3. Cost . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4. Deployment guidance . . . . . . . . . . . . . . . . . . . 4 4. Generic Option vs. Specific Option . . . . . . . . . . . . . 4 4.1. Implementation . . . . . . . . . . . . . . . . . . . . . 5 4.2. Extending the allocation space of Option Type . . . . . . 5 4.2.1. Backwards compatibility . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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. Peng, et al. Expires 14 September 2023 [Page 2] Internet-Draft IPv6 Options Deployment March 2023 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. Peng, et al. Expires 14 September 2023 [Page 3] Internet-Draft IPv6 Options Deployment March 2023 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. Peng, et al. Expires 14 September 2023 [Page 4] Internet-Draft IPv6 Options Deployment March 2023 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. Peng, et al. Expires 14 September 2023 [Page 5] Internet-Draft IPv6 Options Deployment March 2023 8. References 8.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, . [RFC8754] 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, March 2020, . [RFC9098] 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, September 2021, . 8.2. Informative References [I-D.ietf-6man-eh-limits] Herbert, T., "Limits on Sending and Processing IPv6 Extension Headers", Work in Progress, Internet-Draft, draft-ietf-6man-eh-limits-02, 28 February 2023, . [I-D.ietf-6man-enhanced-vpn-vtn-id] 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, 24 October 2022, . [I-D.ietf-6man-hbh-processing] Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options Processing Procedures", Work in Progress, Internet-Draft, Peng, et al. Expires 14 September 2023 [Page 6] Internet-Draft IPv6 Options Deployment March 2023 draft-ietf-6man-hbh-processing-05, 23 February 2023, . [I-D.ietf-ippm-ioam-ipv6-options] Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam- ipv6-options-10, 28 February 2023, . [I-D.iurman-6man-carry-identifier] Iurman, J., "Carrying an Identifier in IPv6 packets", Work in Progress, Internet-Draft, draft-iurman-6man-carry- identifier-00, 8 February 2023, . [RFC9268] Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop- by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August 2022, . [RFC9343] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. Pang, "IPv6 Application of the Alternate-Marking Method", RFC 9343, DOI 10.17487/RFC9343, December 2022, . Authors' Addresses Shuping Peng Huawei Technologies China Email: pengshuping@huawei.com Giuseppe Fioccola Huawei Technologies Germany Email: giuseppe.fioccola@huawei.com Jie Dong Huawei Technologies China Email: jie.dong@huawei.com Peng, et al. Expires 14 September 2023 [Page 7]