6man R. Bonica Internet-Draft Juniper Networks Intended status: Experimental X. Li Expires: 6 November 2025 CERNET Center/Tsinghua University A. Farrel Old Dog Consulting Y. Kamite NTT Communications Corporation L. Jalil Verizon 5 May 2025 The IPv6 VPN Service Destination Option draft-ietf-6man-vpn-dest-opt-06 Abstract This document describes an experiment in which VPN service information is encoded in an experimental IPv6 Destination Option. The experimental IPv6 Destination Option is called the VPN Service Option. One purpose of this experiment is to demonstrate that the VPN Service Option can be deployed in a production network. Another purpose is to demonstrate that the security measures described in this document are sufficient to protect a VPN. 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 6 November 2025. Bonica, et al. Expires 6 November 2025 [Page 1] Internet-Draft Svc. Dest. Opt. May 2025 Copyright Notice Copyright (c) 2025 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. The VPN Service Option . . . . . . . . . . . . . . . . . . . 5 5. Forwarding Plane Considerations . . . . . . . . . . . . . . . 6 6. Control Plane Considerations . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 10. Experimental Results . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Generic Packet Tunneling [RFC2473] allows a router in one network to encapsulate a packet in an IP header and send it through the Internet to another router in another network. The receiving router removes the outer IP header and forwards the original packet into its own network. This facilitates connectivity between networks that share a private addressing [RFC1918] [RFC4193] plan but are not connected by a direct link. The IETF refined this concept in a Framework For Virtual Private Networks (VPN) [RFC2764]. It also standardized the following VPN technologies: * IPSec VPN [RFC3884]. Bonica, et al. Expires 6 November 2025 [Page 2] Internet-Draft Svc. Dest. Opt. May 2025 * Layer 3 VPN (L3VPN) [RFC4364]. * Virtual Private LAN Service (VPLS) [RFC4761][RFC4762]. * Layer 2 VPN (L2VPN) [RFC6624]. * Ethernet VPN (EVPN) [RFC7432]. * Pseudowires [RFC8077]. * SRv6 [RFC8986]. * EVPN / NVO3 [RFC9469]. The VPN technologies mentioned above share the following characteristics: * An ingress Provider Edge (PE) router encapsulates customer data in a tunnel header. The tunnel header includes service information. Service Information identifies a Forwarding Information Base (FIB) entry on an egress PE router. * The ingress PE router sends the encapsulated packet to the egress PE router. * The egress PE router receives the encapsulated packet. * The egress PE router searches its FIB for an entry that matches the incoming service information. If it finds one, it removes the tunnel header and forwards the customer data to a Customer Edge (CE) device, as per the FIB entry. If it does not find a matching FIB entry, it discards the packet. This document describes an experiment in which VPN service information is encoded in an experimental IPv6 Destination Option [RFC8200]. The experimental IPv6 Destination Option is called the VPN Service Option. One purpose of this experiment is to demonstrate that the VPN Service Option can be deployed in a production network. Another purpose is to demonstrate that the security measures described in Section 8 of this document are sufficient to protect a VPN. In particular, experimenters should report vulnerabilities that: * allow nodes outside of the VPN to exchange packets with nodes inside of the VPN * allow nodes outside of the VPN to inject packets into the VPN Bonica, et al. Expires 6 November 2025 [Page 3] Internet-Draft Svc. Dest. Opt. May 2025 * allow nodes outside of the VPN to attract VPN packets to themselves Finally, this document encourages replication of the experiment, so that operational issues can be discovered. 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. Motivation The following requirements are satisfied by networks that deploy the IPv6 VPN Service Destination Option: 1. Solution must not require configuration on CE devices 2. Solution must support many VPNs on a single egress PE router 3. Solution must not require the configuration of multiple IPv6 addresses to support different VPNs at the same PE 4. Solution does not require the use of a sub-IP data plane encapsulation to carry the VPN ID. Table 1 demonstrates that no other VPN technology satisfies all of the requirements mentioned above. Bonica, et al. Expires 6 November 2025 [Page 4] Internet-Draft Svc. Dest. Opt. May 2025 +=============================+========+========+========+========+ | VPN Type | Req. 1 | Req. 2 | Req. 3 | Req. 4 | +=============================+========+========+========+========+ | Generic Packet Tunneling | YES | NO | N/A | YES | | [RFC2473] | | | | | +-----------------------------+--------+--------+--------+--------+ | IPSec VPN [RFC3884] | NO | YES | YES | YES | +-----------------------------+--------+--------+--------+--------+ | Layer 3 VPN (L3VPN) | YES | YES | YES | NO | | [RFC4364] | | | | | +-----------------------------+--------+--------+--------+--------+ | Virtual Private LAN Service | YES | YES | YES | NO | | (VPLS) [RFC4761][RFC4762] | | | | | +-----------------------------+--------+--------+--------+--------+ | Layer 2 VPN (L2VPN) | YES | YES | YES | NO | | [RFC6624] | | | | | +-----------------------------+--------+--------+--------+--------+ | Ethernet VPN (EVPN) | YES | YES | YES | NO | | [RFC7432] | | | | | +-----------------------------+--------+--------+--------+--------+ | Pseudowires [RFC8077] | YES | YES | YES | NO | +-----------------------------+--------+--------+--------+--------+ | SRv6 [RFC8986] | YES | YES | NO | YES | +-----------------------------+--------+--------+--------+--------+ | EVPN / NVO3 [RFC9469] | YES | YES | YES | NO | +-----------------------------+--------+--------+--------+--------+ | VPN Service Destination | YES | YES | YES | YES | | Option | | | | | +-----------------------------+--------+--------+--------+--------+ Table 1: VPN Solutions 4. The VPN Service Option The VPN Service Option is an IPv6 Destination Option encoded according to rules defined in [RFC8200]. As described in section 4.2 of [RFC8200] a IPv6 Destination Option contains three fields: Option Type, Opt Data Len, and Option Data. In the VPN Service Option these fields are used as follows: * 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 bytes, excluding the Option Type and Option Length fields. This field MUST be set to 4. Bonica, et al. Expires 6 November 2025 [Page 5] Internet-Draft Svc. Dest. Opt. May 2025 * Option Data - 32 bits. VPN Service Information that identifies a FIB entry on the egress PE. The FIB entry determines how the egress PE will forward customer data to a CE device. The VPN Service Option MAY appear in a Destination Options header that immediately precedes an upper-layer header. It MUST NOT appear in any other extension header. If a receiver finds the VPN Service Option in any other extension header, it MUST NOT recognize the option. The packet MUST be processed according to the setting of the two highest order bits of the Option Type (see NOTE below). NOTE: For this experiment, the Option Type is set to '01011110', i.e., 0x5E. The highest-order two bits are set to 01 indicating that the required action by a destination node that does not recognize the option is to discard the packet. The third highest-order bit is set to 0 indicating that Option Data cannot be modified along the path between the packet's source and its destination. The remaining low- order bits are set to '11110' to indicate the single IPv6 Destination Option Type code point available in the registry for experimentation. 5. Forwarding Plane Considerations The ingress PE encapsulates the customer data in a tunnel header. The tunnel header MUST contain an IPv6 header and a Destination Options header that immediately precedes the customer data. It MAY also include any legal combination of IPv6 extension headers. 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]. * Hop Limit - Defined in [RFC8200]. * Source Address - Defined in [RFC8200]. Represents an interface on the ingress PE router. This address SHOULD be chosen according to guidance provided in [RFC6724]. * Destination Address - Defined in [RFC8200]. Represents an interface on the egress PE router. This address SHOULD be chosen according to guidance provided in [RFC6724]. Bonica, et al. Expires 6 November 2025 [Page 6] Internet-Draft Svc. Dest. Opt. May 2025 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]. * Options - Defined in [RFC8200]. In this experiment, the Options field MUST contain exactly one VPN Service Option as defined in Section 4 of this document. It MAY also contain any legal combination of other Destination Options. 6. 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 FIB entry exactly as it would if VPN service information were encoded in an MPLS service label. The leading 12 bits of the service information will be 0 and the next 20 bits will identify an MPLS FIB entry. 7. 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, and contain operational recommendations regarding a migration to a new code point. 8. 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: Bonica, et al. Expires 6 November 2025 [Page 7] Internet-Draft Svc. Dest. Opt. May 2025 * Authenticate the tunnel connecting the ingress PE to the egress PE using the IPv6 Authentication Header (AH) [RFC4302] or the IPv6 Encapsulating Security Payload (ESP) Header [RFC4303]. * 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 mitigation techniques mentioned above operate in fail-open mode. See Section 3 of [I-D.wkumari-intarea-safe-limited-domains] for a discussion of fail-open and fail-closed modes. The mitigation techniques mentioned above also address the tunneling concerns raised in [RFC6169]. 9. 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 impediment to deployment. 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. 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. Because the VPN Service Destination Option uses an experimental code point, processing of this option MUST be disabled by default. Explicit configuration is required to enable processing of the option. Bonica, et al. Expires 6 November 2025 [Page 8] Internet-Draft Svc. Dest. Opt. May 2025 10. 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 interoperable implementations? - Did you experience interoperability problems? * Effectiveness and sufficiency of OAM mechanisms - Did PING work? - Did TRACEROUTE work? - Did Wireshark work? - Did TCPDUMP work? 11. Acknowledgements Thanks to Gorry Fairhurst, Antoine Fressancourt, Eliot Lear and Mark Smith for their reviews and contributions to this document. Bonica, et al. Expires 6 November 2025 [Page 9] Internet-Draft Svc. Dest. Opt. May 2025 12. References 12.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, . [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, DOI 10.17487/RFC6169, April 2011, . [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, . [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, . 12.2. Informative References [I-D.wkumari-intarea-safe-limited-domains] Kumari, W., Alston, A., Vyncke, E., Krishnan, S., and D. E. Eastlake, "Safe(r) Limited Domains", Work in Progress, Internet-Draft, draft-wkumari-intarea-safe-limited- domains-04, 3 March 2025, . [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, . Bonica, et al. Expires 6 November 2025 [Page 10] Internet-Draft Svc. Dest. Opt. May 2025 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, . [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, . [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec Transport Mode for Dynamic Routing", RFC 3884, DOI 10.17487/RFC3884, September 2004, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, . [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, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [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, . Bonica, et al. Expires 6 November 2025 [Page 11] Internet-Draft Svc. Dest. Opt. May 2025 [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, . [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, . [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, . [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, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . [RFC9469] Rabadan, J., Ed., Bocci, M., Boutros, S., and A. Sajassi, "Applicability of Ethernet Virtual Private Network (EVPN) to Network Virtualization over Layer 3 (NVO3) Networks", RFC 9469, DOI 10.17487/RFC9469, September 2023, . [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. Bonica, et al. Expires 6 November 2025 [Page 12] Internet-Draft Svc. Dest. Opt. May 2025 Authors' Addresses Ron Bonica Juniper Networks Herndon, Virginia United States of America Email: rbonica@juniper.net Xing Li CERNET Center/Tsinghua University Beijing China 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 6 November 2025 [Page 13]