]> Juniper Networks

Herndon Virginia USA rbonica@juniper.net

CERNET Center/Tsinghua University

Beijing China xing@cernet.edu.cn

Old Dog Consulting

UK adrian@olddog.co.uk

NTT Communications Corporation

3-4-1 Shibaura Minato-ku Japan y.kamite@ntt.com

Verizon

Richardson Texas USA luay.jalil@one.verizon.com

Internet 6man IPv6, Destination Option, VPN 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.

Introduction Generic Packet Tunneling 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 plan but are not connected by a direct link. The IETF refined this concept in a Framework For Virtual Private Networks (VPN) . It also standardized the following VPN technologies:

• IPSec VPN .
• Layer 3 VPN (L3VPN) .
• Virtual Private LAN Service (VPLS) .
• Layer 2 VPN (L2VPN) .
• Ethernet VPN (EVPN) .
• Pseudowires .
• SRv6 .
• EVPN / NVO3 .

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 . 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 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
• 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.

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 when, and only when, they appear in all capitals, as shown here.

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.

demonstrates that no other VPN technology satisfies all of the requirements mentioned above. VPN Solutions

VPN Type	Req. 1	Req. 2	Req. 3	Req. 4
Generic Packet Tunneling	YES	NO	N/A	YES
IPSec VPN	NO	YES	YES	YES
Layer 3 VPN (L3VPN)	YES	YES	YES	NO
Virtual Private LAN Service (VPLS)	YES	YES	YES	NO
Layer 2 VPN (L2VPN)	YES	YES	YES	NO
Ethernet VPN (EVPN)	YES	YES	YES	NO
Pseudowires	YES	YES	YES	NO
SRv6	YES	YES	NO	YES
EVPN / NVO3	YES	YES	YES	NO
VPN Service Destination Option	YES	YES	YES	YES

The VPN Service Option The VPN Service Option is an IPv6 Destination Option encoded according to rules defined in . As described in section 4.2 of 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) . 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.
• 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.

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 . MUST be equal to 6.
• Traffic Class - Defined in .
• Flow Label - Defined in .
• Payload Length - Defined in .
• Next Header - Defined in .
• Hop Limit - Defined in .
• Source Address - Defined in . Represents an interface on the ingress PE router. This address SHOULD be chosen according to guidance provided in .
• Destination Address - Defined in . Represents an interface on the egress PE router. This address SHOULD be chosen according to guidance provided in .

The IPv6 Destination Options Extension Header contains:

• Next Header - Defined in . MUST identify the protocol of the customer data.
• Hdr Ext Len - Defined in .
• Options - Defined in . In this experiment, the Options field MUST contain exactly one VPN Service Option as defined in of this document. It MAY also contain any legal combination of other Destination Options.

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) or the Network Configuration Protocol (NETCONF) .
• By the Border Gateway Protocol (BGP) .

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.

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.

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 tunnel connecting the ingress PE to the egress PE using the IPv6 Authentication Header (AH) or the IPv6 Encapsulating Security Payload (ESP) Header .
• 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 for a discussion of fail-open and fail-closed modes. The mitigation techniques mentioned above also address the tunneling concerns raised in .

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.

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?

Acknowledgements Thanks to Gorry Fairhurst, Antoine Fressancourt, Eliot Lear and Mark Smith for their reviews and contributions to this document.

References Normative References A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK] This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa. Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK] This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. [STANDARDS-TRACK] This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. This memo provides information for the Internet community. This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK] IPsec can secure the links of a multihop network to protect communication between trusted components, e.g., for a secure virtual network (VN), overlay, or virtual private network (VPN). Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside VNs because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of the VN packet. IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database (SAD) match on the tunnel header. IIPtran supports dynamic routing inside the VN without changes to the current IPsec architecture. IIPtran demonstrates how to configure any compliant IPsec implementation to avoid the aforementioned conflicts. IIPtran is also compared to several alternative mechanisms for VN routing and their respective impact on IPsec, routing, policy enforcement, and interactions with the Internet Key Exchange (IKE). This memo provides information for the Internet community. This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK] This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). [STANDARDS-TRACK] This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK] This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK] This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK] Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature. This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. [STANDARDS-TRACK] This document describes a Virtual Private LAN Service (VPLS) solution using pseudowires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses and that is closed to a given set of users. Multiple VPLS services can be supported from a single Provider Edge (PE) node. This document describes the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP), extending RFC 4447. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing in particular on the learning of MAC addresses. The encapsulation of VPLS packets is described by RFC 4448. [STANDARDS-TRACK] This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional L2VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs, and the Internet, as well as a common provisioning methodology for all services. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)". Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents. This document is a rewrite of RFC 4447 for publication as an Internet Standard. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. An Ethernet Virtual Private Network (EVPN) provides a unified control plane that solves the issues of Network Virtualization Edge (NVE) auto-discovery, tenant Media Access Control (MAC) / IP dissemination, and advanced features in a scablable way as required by Network Virtualization over Layer 3 (NVO3) networks. EVPN is a scalable solution for NVO3 networks and keeps the independence of the underlay IP Fabric, i.e., there is no need to enable Protocol Independent Multicast (PIM) in the underlay network and maintain multicast states for tenant Broadcast Domains. This document describes the use of EVPN for NVO3 networks and discusses its applicability to basic Layer 2 and Layer 3 connectivity requirements and to advanced features such as MAC Mobility, MAC Protection and Loop Protection, multihoming, Data Center Interconnect (DCI), and much more. No new EVPN procedures are introduced. Internet Assigned Numbers Authority (IANA) Google, LLC Alston Networks Cisco Cisco Independent Documents describing protocols that are only intended to be used within "limited domains" often do not clearly define how the boundary of the limited domain is implemented and enforced, or require that operators of these limited domains perfectly filter at all of the boundary nodes of the domain to protect the rest of the global Internet from these protocols and vice-versa. This document discusses some design principles and offers mechanisms to allow protocols that are designed to operate in a limited domain "fail-closed" rather than "fail-open", thereby making these protocols safer to deploy on the Internet. These mechanism are not applicable to all protocols intended for use in a limited domain, but if implemented on certain classes of protocols, they can significantly reduce the risks.