The IPv6 VPN Service Destination Option
RFC 9837
Ron Bonica
Juniper Networks
Xing Li
CERNET Center/Tsinghua University
Adrian Farrel
Old Dog Consulting
Yuji Kamite
NTT DOCOMO BUSINESS
Luay Jalil
Verizon
2025-08
INT
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.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9837.
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. Conventions and Definitions
- 3. The VPN Service Option
- 4. Forwarding Plane Considerations
- 5. Control Plane Considerations
- 6. IANA Considerations
- 7. Security Considerations
- 8. Deployment Considerations
- 9. Experimental Results
- 10. References
  - 10.1. Normative References
  - 10.2. Informative References
- Acknowledgements
- Authors' Addresses
Introduction
Generic Packet Tunneling [RFC2473] allows a router in one network to encapsulate a packet in an IP header and send it to a 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 the Framework for VPN [RFC2764]. The IETF also standardized the following VPN technologies:
- IPsec VPN [RFC3884]
- Layer 3 VPN (L3VPN) [RFC4364]
- Virtual Private LAN Service (VPLS) [RFC4761][RFC4762]
- Layer 2 VPN (L2VPN) [RFC6624]
- Ethernet VPN (EVPN) [RFC7432]
- Pseudowires [RFC8077]
- Segment Routing over IPv6 (SRv6) [RFC8986]
- EVPN / Network Virtualization over Layer 3 (NVO3) [RFC9469]
IPsec VPNs cryptographically protect all traffic from customer endpoint to customer endpoint. All of the other 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.
The solution described in this document offers the following benefits:
- It does not require configuration on CE devices.
- It encodes service information in the IPv6 extension header. Therefore, it does not require any non-IPv6 headers (e.g., MPLS headers) to carry service information.
- It supports many VPNs on a single egress PE router.
- When a single egress PE router supports many VPNs, it does not require an IP address per VPN.
- It does not rely on any particular control plane.
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 7 of this document are sufficient to protect a VPN. 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 BCP 14 [RFC2119] [RFC8174] 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 according to rules defined in [RFC8200].
As described in Section 4.2 of [RFC8200], an 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 0x5E (RFC3692-style Experiment) [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.
- 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.
A single 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 "Destination Options and Hop-by-Hop Options" registry [V6MSG] 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 the following (all defined in [RFC8200]):
- Version - MUST be equal to 6.
- Traffic Class
- Flow Label
- Payload Length
- Next Header
- Hop Limit
- Source Address - Represents an interface on the ingress PE router. This address SHOULD be chosen according to guidance provided in [RFC6724].
- Destination Address - Represents an interface on the egress PE router. This address SHOULD be chosen according to guidance provided in [RFC6724].
The IPv6 Destination Options Extension Header contains the following (all defined in [RFC8200]):
- Next Header - MUST identify the protocol of the customer data.
- Hdr Ext Len
- Options - In this experiment, the Options field MUST contain exactly one VPN Service Option as defined in Section 3 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)
- A controller, using the Path Computation Element Communication Protocol (PCEP) [RFC5440] or the Network Configuration Protocol (NETCONF) [RFC6241]
- A routing protocol
Routing protocol extensions that support the VPN Service Option are beyond the scope of this document.
IANA Considerations
This document has no IANA actions.
Security Considerations
A VPN is characterized by the following security policy:
- Nodes outside of a VPN cannot inject traffic into the VPN.
- Nodes inside a VPN cannot send traffic outside of the VPN.
A set of PE routers cooperate to enforce this security policy. If a device outside of that set could impersonate a device inside of the set, it would be possible for that device to subvert security policy. Therefore, impersonation must not be possible. The following paragraphs describe procedures that prevent impersonation.
The VPN Service Option can be deployed:
- On the global Internet
- Inside of a limited domain
When the VPN Service Option is deployed on the global Internet, the tunnel that connects the ingress PE to the egress PE MUST be cryptographically protected by one of the following:
- The IPv6 Authentication Header (AH) [RFC4302]
- The IPv6 Encapsulating Security Payload (ESP) Header [RFC4303]
When the VPN Service Option is deployed in a limited domain, all nodes at the edge of limited domain MUST maintain Access Control Lists (ACLs). These ACLs MUST discard packets that satisfy the following criteria:
- Contain a VPN Service Option
- Contain an IPv6 Destination Address that represents an interface inside of the limited domain
The mitigation techniques mentioned above operate in fail-open mode. That is, they require explicit configuration in order to ensure that packets using the approach described in this document do not leak out of a domain. See [SAFE-LIM-DOMAINS] for a discussion of fail-open and fail-closed modes.
For further information on the security concerns related to IP tunnels and the recommended mitigation techniques, please see [RFC6169].
Deployment Considerations
The VPN Service Option is imposed by an ingress PE and processed by an egress PE. It is not processed by any other nodes along the delivery path between the ingress PE and egress PE.
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.
As with all experiments with IETF protocols, it is expected that 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 a 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 Operations, Administration, and Maintenance (OAM) mechanisms
  - Did PING work?
  - Did TRACEROUTE work?
  - Did Wireshark work?
  - Did TCPDUMP work?
References
Normative References
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC6169]

Security Concerns with IP Tunneling
S. Krishnan
D. Thaler
J. Hoagland
April 2011
RFC 6169
DOI 10.17487/RFC6169
[RFC6724]

Default Address Selection for Internet Protocol Version 6 (IPv6)
D. Thaler, Ed.
R. Draves
A. Matsumoto
T. Chown
September 2012
RFC 6724
DOI 10.17487/RFC6724
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[RFC8200]

Internet Protocol, Version 6 (IPv6) Specification
S. Deering
R. Hinden
July 2017
STD 86
RFC 8200
DOI 10.17487/RFC8200
Informative References
[RFC1918]

Address Allocation for Private Internets
Y. Rekhter
B. Moskowitz
D. Karrenberg
G. J. de Groot
E. Lear
February 1996
BCP 5
RFC 1918
DOI 10.17487/RFC1918
[RFC2473]

Generic Packet Tunneling in IPv6 Specification
A. Conta
S. Deering
December 1998
RFC 2473
DOI 10.17487/RFC2473
[RFC2764]

A Framework for IP Based Virtual Private Networks
B. Gleeson
A. Lin
J. Heinanen
G. Armitage
A. Malis
February 2000
RFC 2764
DOI 10.17487/RFC2764
[RFC3884]

Use of IPsec Transport Mode for Dynamic Routing
J. Touch
L. Eggert
Y. Wang
September 2004
RFC 3884
DOI 10.17487/RFC3884
[RFC4193]

Unique Local IPv6 Unicast Addresses
R. Hinden
B. Haberman
October 2005
RFC 4193
DOI 10.17487/RFC4193
[RFC4302]

IP Authentication Header
S. Kent
December 2005
RFC 4302
DOI 10.17487/RFC4302
[RFC4303]

IP Encapsulating Security Payload (ESP)
S. Kent
December 2005
RFC 4303
DOI 10.17487/RFC4303
[RFC4364]

BGP/MPLS IP Virtual Private Networks (VPNs)
E. Rosen
Y. Rekhter
February 2006
RFC 4364
DOI 10.17487/RFC4364
[RFC4761]

Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
K. Kompella, Ed.
Y. Rekhter, Ed.
January 2007
RFC 4761
DOI 10.17487/RFC4761
[RFC4762]

Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling
M. Lasserre, Ed.
V. Kompella, Ed.
January 2007
RFC 4762
DOI 10.17487/RFC4762
[RFC5440]

Path Computation Element (PCE) Communication Protocol (PCEP)
JP. Vasseur, Ed.
JL. Le Roux, Ed.
March 2009
RFC 5440
DOI 10.17487/RFC5440
[RFC6241]

Network Configuration Protocol (NETCONF)
R. Enns, Ed.
M. Bjorklund, Ed.
J. Schoenwaelder, Ed.
A. Bierman, Ed.
June 2011
RFC 6241
DOI 10.17487/RFC6241
[RFC6624]

Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling
K. Kompella
B. Kothari
R. Cherukuri
May 2012
RFC 6624
DOI 10.17487/RFC6624
[RFC7432]

BGP MPLS-Based Ethernet VPN
A. Sajassi, Ed.
R. Aggarwal
N. Bitar
A. Isaac
J. Uttaro
J. Drake
W. Henderickx
February 2015
RFC 7432
DOI 10.17487/RFC7432
[RFC8077]

Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)
L. Martini, Ed.
G. Heron, Ed.
February 2017
STD 84
RFC 8077
DOI 10.17487/RFC8077
[RFC8986]

Segment Routing over IPv6 (SRv6) Network Programming
C. Filsfils, Ed.
P. Camarillo, Ed.
J. Leddy
D. Voyer
S. Matsushima
Z. Li
February 2021
RFC 8986
DOI 10.17487/RFC8986
[RFC9469]

Applicability of Ethernet Virtual Private Network (EVPN) to Network Virtualization over Layer 3 (NVO3) Networks
J. Rabadan, Ed.
M. Bocci
S. Boutros
A. Sajassi
September 2023
RFC 9469
DOI 10.17487/RFC9469
[I-D.wkumari-intarea-safe-limited-domains]

Safe(r) Limited Domains
Warren Kumari
Google, LLC
Andrew Alston
Alston Networks
Éric Vyncke
Cisco
Suresh Krishnan
Cisco
Donald E. Eastlake 3rd
Independent
3 March 2025
Internet-Draft draft-wkumari-intarea-safe-limited-domains-04
Work in Progress
[V6MSG]

Destination Options and Hop-by-Hop Options
Internet Assigned Numbers Authority
Acknowledgements
Thanks to Gorry Fairhurst, Antoine Fressancourt, Eliot Lear, and Mark Smith for their reviews and contributions to this document.
Authors' Addresses
Ron Bonica
Juniper Networks
Herndon
Virginia
United States of America
rbonica@juniper.net
Xing Li
CERNET Center/Tsinghua University
Beijing
China
xing@cernet.edu.cn
Adrian Farrel
Old Dog Consulting
United Kingdom
adrian@olddog.co.uk
Yuji Kamite
NTT DOCOMO BUSINESS
Chiyoda-ku, Tokyo
Japan
y.kamite@ntt.com
Luay Jalil
Verizon
Richardson
Texas
United States of America
luay.jalil@one.verizon.com