The IPv6 VPN Service Destination Option

Introduction Generic Packet Tunneling allows a router in one network to encapsulate a packet in an IP header and send that packet across the Internet to another router, creating a virtual link. 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 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 red sites and blue sites connect to a provider network. The provider network 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) .
Layer 3 VPN (L3VPN) .
Virtual Private LAN Service (VPLS) .
Ethernet VPN (EVPN) .
Pseudowires .

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 service label. The service label identifies a Forwarding Information Base (FIB) entry on the egress PE.
The egress PE removes the tunnel header, exposing the customer data. It then searches its FIB for an entry that matches the incoming service label. If the egress PE finds this entry, it forwards the customer data to a Customer Edge (CE) device. If it does not find this entry, it discards the packet.

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 for both layer 2 and layer 3 VPNs is encoded in a new IPv6 Destination Option called the VPN Service Option. This option will allow VPNs to be deployed between Provider Edge routers that support IPv6 but do not support MPLS. 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, are sufficient to protect use of the VPN Service Option. Experimenters should report any security flaws that they discover. 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.

The VPN Service Option The VPN Service Option is an IPv6 Destination Option encoded following the encoding rules defined in . As shown in section 4.2 of the IPv6 Destination Option contains three fields: Option Type, Opt Data Len, Option Data. For the VPN Service Option the 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 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: Reserved. SHOULD be set to 0 by the sender and MUST be ignored by the receiver.
- Low-order 20 bits: 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 precedes an upper-layer header. It MUST NOT appear in any other extension header. If a receiver finds the VPN Service option in another extension header that it is processing, the option will be unrecognized, and 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 to indicate 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 to indicate 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 payload in a tunnel header. The tunnel header contains:

An IPv6 header
An optional IPv6 Authentication Header (AH)
An IPv6 Destination Options Extension Header

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 . MUST be equal to either Authentication Header (51) or Destination Options (60).
Hop Limit - Defined in .
Source Address - Defined in . Represents an interface on the ingress PE device.
Destination Address - Defined in . Represents an interface on the egress PE device.

If the Authentication Header is present, it contains:

Next Header - Defined in . MUST be equal to Destination Options (60) or Encapsulating Security Payload (ESP) (50).
Payload Length - Defined in .
Reserved - Defined in . MUST be set to zero by the sender, and SHOULD be ignored by the recipient.
Security Parameters Index (SPI) - Defined in .
Sequence Number - Defined in .
Integrity Check Value (ICV) - Defined in .

IPsec processing of the AH and ESP headers would occur before the VPN Service Option is available for processing by tunnel egress PE. The IPv6 Destination Options Extension Header contains:

Next Header - Defined in . MUST identify the protocol of the customer data.
Hdr Ext Len - Defined in . MUST be equal to 0.
Options - * Options - Defined in . MUST contain exactly one VPN Service Option as defined in of this document.

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

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 reguarding 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 packet option using the IPv6 Authentication Header (AH) or the IPv6 Encapsulating Security Payload (ESP) Header . 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 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.