6man R. Bonica Internet-Draft Juniper Networks Intended status: Experimental X. Li Expires: 13 February 2025 CERNET Center/Tsinghua University A. Farrel Old Dog Consulting Y. Kamite NTT Communications Corporation L. Jalil Verizon 12 August 2024 The IPv6 VPN Service Destination Option draft-bonica-6man-vpn-dest-opt-23 Abstract This document describes an experiment in which VPN service information is encoded in a new IPv6 Destination Option. The new IPv6 Destination Option is called the VPN Service Option. One purpose of this experiment is to demonstrate that the VPN Service Option can be implemented and deployed in a production network. Another purpose is to demonstrate that the security considerations, described in this document, have been sufficiently addressed. Finally, this document encourages replication of the experiment. 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 13 February 2025. Bonica, et al. Expires 13 February 2025 [Page 1] Internet-Draft Svc. Dest. Opt. August 2024 Copyright Notice Copyright (c) 2024 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. The VPN Service Option . . . . . . . . . . . . . . . . . . . 4 4. Forwarding Plane Considerations . . . . . . . . . . . . . . . 5 5. Control Plane Considerations . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 9. Experimental Results . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Generic Packet Tunneling [RFC2473] allows a router in one network to encapsulate a packet in an IP header and send that packet across the Internet to another router. The receiving router removes the outer IP header and forwards the original packet into its own network. One motivation for Generic Packet Tunneling is to provide connectivity between two networks that share a private addressing [RFC1918] plan but are not connected by direct links. In this case, all sites in the first network are accessible to all sites in the second network. Likewise, all sites in the second network are accessible to all sites in the first network. Virtual Private Networks (VPN) technologies provide additional functionality, allowing network providers to emulate private networks by using shared infrastructure. For example, assume that a red sites and blue sites connect to a provider network. The provider network Bonica, et al. Expires 13 February 2025 [Page 2] Internet-Draft Svc. Dest. Opt. August 2024 allows communication among red sites. It also allows communication among blue sites. However, it prevents communication between red sites and blue sites. The IETF has standardized many VPN technologies, including: * Layer 2 VPN (L2VPN) [RFC6624]. * Layer 3 VPN (L3VPN) [RFC4364]. * Virtual Private LAN Service (VPLS) [RFC4761][RFC4762]. * Ethernet VPN (EVPN) [RFC7432]. * Pseudowires [RFC8077]. The VPN technologies mentioned above share the following characteristics: * An ingress Provider Edge (PE) device tunnels customer data to an egress PE device. A popular tunnel technology for all of these VPN approaches is MPLS where the tunnel header includes an MPLS [RFC3032] service label. * The egress PE removes the tunnel header, exposing the customer data. It then queries its Forwarding Information Base (FIB) to identify the interface through which the customer data is to be forwarded. The service label, found in the tunnel header, identifies either the next-hop interface or a VPN-specific portion of the FIB that will be used to determine the next-hop interface. The mechanism described above requires both PE devices (ingress and egress) to support MPLS. It cannot be deployed where one or both of the PEs does not support MPLS. This document describes an experiment in which VPN service information is encoded in a new IPv6 Destination Option [RFC8200] called the VPN Service Option. One purpose of this experiment is to demonstrate that the VPN Service Option can be implemented and deployed in a production network. Another purpose is to demonstrate that the security considerations, described in this document, have been sufficiently addressed. Finally, this document encourages replication of the experiment, so that operational issues can be discovered. Bonica, et al. Expires 13 February 2025 [Page 3] Internet-Draft Svc. Dest. Opt. August 2024 2. Conventions and Definitions 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 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. The VPN Service Option The VPN Service Option is an IPv6 Destination Option encoded following the encoding rules defined in [RFC8200]. The VPN Service Option contains the following fields: * Option Type: 8-bit selector. VPN Service Option. This field MUST be set to RFC3692-style Experiment (0x5E)[V6MSG]. See Note below. * Opt Data Len - 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 4. * Option Data - 32-bits. VPN Service Information: - High-order 12 bits: A checksum. The checksum field is the 12 bit one's complement of the one's complement sum of all 16 bit words in the pseudo-header. Figure 1 depicts the VPN Service Option Pseudo-header. For purposes of computing the checksum, the value of the checksum is zero. - Low-order 20 bits: Identifies either the next-hop interface or a VPN-specific portion of the FIB that will be used to determine the next-hop interface. *---------------------------------------------------------------* | IPv6 Source Address |IPv6 Destination Address | Option Data | *---------------------------------------------------------------* Figure 1: Pseudo-header The VPN Service Option MAY appear in a Destination Options header that precedes an upper-layer header. It MUST NOT appear in any other extension header. If VPN Service option appears in appears in another extension header, the receiver MUST discard the packet. NOTE : A single IPv6 Destination Option Type code point is available in the registry for experimentation. The low order bits are set to '11110'. The highest-order two bits of the Option Type (i.e., the Bonica, et al. Expires 13 February 2025 [Page 4] Internet-Draft Svc. Dest. Opt. August 2024 "act" bits) specify the action taken by a destination node that does not recognize the option. For this experiment, these bits are set to 01 to indicate the required action is to discard the packet. The third highest-order bit of the Option Type (i.e., the "chg" bit) indicates whether the Option Data can be modified in transit. For this experiment the bit is set to 0 to indicate that Option Data cannot be modified along the path between the packet's source and its destination. Thus, the Option Type for this experiment is set to '01011110', i.e., 0x5E. 4. Forwarding Plane Considerations The ingress PE encapsulates customer payload in a tunnel header. The tunnel header contains: * An IPv6 header * An optional IPv6 Authentication Header (AH) [RFC4302] * An IPv6 Destination Options Extension Header * Customer data The IPv6 header contains: * Version - Defined in [RFC8200]. MUST be equal to 6. * Traffic Class - Defined in [RFC8200]. * Flow Label - Defined in [RFC8200]. * Payload Length - Defined in [RFC8200]. * Next Header - Defined in [RFC8200]. MUST be equal to either Authentication Header (51) or Destination Options (60). * Hop Limit - Defined in [RFC8200]. * Source Address - Defined in [RFC8200]. Represents an interface on the ingress PE device. * Destination Address - Defined in [RFC8200]. Represents an interface on the egress PE device. If the Authentication Header is present, it contains: * Next Header - Defined in [RFC4302]. MUST be equal to Destination Options (60). Bonica, et al. Expires 13 February 2025 [Page 5] Internet-Draft Svc. Dest. Opt. August 2024 * Payload Length - Defined in [RFC4302]. * Reserved - Defined in [RFC4302]. MUST be set to zero by the sender, and SHOULD be ignored by the recipient. * Security Parameters Index (SPI) - Defined in [RFC4302]. * Sequence Number - Defined in [RFC4302]. * Integrity Check Value (ICV) - Defined in [RFC4302]. The IPv6 Destination Options Extension Header contains: * Next Header - Defined in [RFC8200]. MUST identify the protocol of the customer data. * Hdr Ext Len - Defined in [RFC8200]. MUST be equal to 0. * Options - * Options - Defined in [RFC8200]. MUST contain exactly one VPN Service Option as defined in Section 3 of this document. 5. Control Plane Considerations The FIB can be populated: * By an operator, using a Command Line Interface (CLI). * By a controller, using the Path Computation Element (PCE) Communication Protocol (PCEP) [RFC5440] or the Network Configuration Protocol (NETCONF) [RFC6241]. * By the Border Gateway Protocol (BGP) [RFC4271] [RFC4760]. If the FIB is populated using BGP, BGP creates a Label-FIB (LFIB), exactly as it would if VPN service information were encoded in an MPLS service label. The egress PE queries the LFIB to resolve information contained by the VPN Service Option. 6. IANA Considerations This document does not make any IANA requests. However, if the experiment described herein succeeds, the authors will reissue this document, to be published on the Standards Track. The reissued document will request an IPv6 Destination Option number. Bonica, et al. Expires 13 February 2025 [Page 6] Internet-Draft Svc. Dest. Opt. August 2024 7. Security Considerations IETF VPN technologies assume that PE devices trust one another. If an egress PE processes a VPN Service Option from an untrusted device, VPN boundaries can be breached. The following are acceptable methods of risk mitigation: * Authenticate the packet option using the IPv6 Authentication Header (AH) [RFC4302] or the IPv6 Encapsulating Security Payload (ESP) Header [RFC4303]. If the ESP Header is used, it encapsulates the entire packet. * Maintain a limited domain. All nodes at the edge limited domain maintain Access Control Lists (ACLs) that discard packets that satisfy the following criteria: * Contain an IPv6 VPN Service option. * Contain an IPv6 Destination Address that represents an interface inside of the secure limited domain. The checksum in the VPN Service Option provides some protection against accidental modification of the fields that form the pseudo-header, but it does not provide any additional security for the mechanisms defined in this document. It does provide protection against accidental collisions between experiments as described in Section 8. 8. Deployment Considerations The VPN Service Option is imposed by an ingress PE and processed by an egress PE. It is not processed by any nodes along the delivery path between the ingress PE and egress PE. So, it is safe to deploy the VPN Service Option across the Internet. However, some networks discard packets that include IPv6 Destination Options. This is an imediment to deplyment. Because the VPN Service Option uses an experimental code point, there is a risk of collisions with other experiments. Specifically, the egress PE may process packets from another experiment that uses the same code point. This risk is mitigated by the VPN Service Option checksum. It is highly unlikely that a packet received from the other experiment will pass checksum validation. It is expected that, as with all experiments with IETF protocols, care is taken by the operator to ensure that all nodes participating in an experiment are carefully configured. Bonica, et al. Expires 13 February 2025 [Page 7] Internet-Draft Svc. Dest. Opt. August 2024 9. Experimental Results Parties participating in this experiment should publish experimental results within one year of the publication of this document. Experimental results should address the following: * Effort required to deploy - Was deployment incremental or network-wide? - Was there a need to synchronize configurations at each node or could nodes be configured independently - Did the deployment require hardware upgrade? * Effort required to secure - Performance impact - Effectiveness of risk mitigation with ACLs - Cost of risk mitigation with ACLs * Mechanism used to populate the FIB * Scale of deployment * Interoperability - Did you deploy two inter-operable implementations? - Did you experience interoperability problems? * Effectiveness and sufficiency of OAM mechanism - Did PING work? - Did TRACEROUTE work? - Did Wireshark work? - Did TCPDUMP work? 10. Acknowledgements TBD 11. References Bonica, et al. Expires 13 February 2025 [Page 8] Internet-Draft Svc. Dest. Opt. August 2024 11.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, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Bonica, et al. Expires 13 February 2025 [Page 9] Internet-Draft Svc. Dest. Opt. August 2024 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 11.2. Informative References [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, . [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, . [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, . [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, . Bonica, et al. Expires 13 February 2025 [Page 10] Internet-Draft Svc. Dest. Opt. August 2024 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, . [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, . [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019, . [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, December 2019, . [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, . [V6MSG] Internet Assigned Numbers Authority (IANA), "Internet Protocol Version 6 (IPv6) Parameters: Destination Options and Hop-by-Hop Options", Web https://www.iana.org/assignments/ipv6-parameters/ ipv6-parameters.xhtml#ipv6-parameters-2. Authors' Addresses Ron Bonica Juniper Networks Herndon, Virginia United States of America Email: rbonica@juniper.net Bonica, et al. Expires 13 February 2025 [Page 11] Internet-Draft Svc. Dest. Opt. August 2024 Xing Li CERNET Center/Tsinghua University Beijing Email: xing@cernet.edu.cn Adrian Farrel Old Dog Consulting United Kingdom Email: adrian@olddog.co.uk Yuji Kamite NTT Communications Corporation Minato-ku Japan Email: y.kamite@ntt.com Luay Jalil Verizon Richardson, Texas United States of America Email: luay.jalil@one.verizon.com Bonica, et al. Expires 13 February 2025 [Page 12]