RFC 9837

The IPv6 VPN Service Destination Option

📅 published August 2025, from ietf

The IPv6 VPN Service Destination Option (RFC 9837) 🦋

okay bestie, let's get into RFC 9837! 💖 It's an Experimental RFC from August 2025, published in the IETF stream. It's written by Bonica (Juniper Networks), Li (CERNET Center/Tsinghua University), Farrel (Old Dog Consulting), Kamite (NTT DOCOMO BUSINESS), and Jalil (Verizon). The ISSN is 2070-1721. It doesn't list anything it obsoletes or updates, so it's a standalone experiment. ✨

Abstract

this doc is all about an experiment where VPN service info gets packed into an experimental IPv6 Destination Option 🎀 That option is called the VPN Service Option. 💅

the experiment has three goals: 🌸

  • show that the VPN Service Option can actually be deployed in a production network 🏭
  • prove that the security measures in this doc are strong enough to protect a VPN 🔐
  • encourage other people to replicate the experiment 🫶

Status of This Memo

not gonna lie, this part is a lot of legal-ish stuff, but here's the tea 🍵 This doc is not an Internet Standards Track spec. It's published so people can examine it, try it out in experimental implementations, and evaluate it. 🧪

It defines an Experimental Protocol for the Internet community. It's a product of the IETF, it reflects IETF community consensus, it got public review, and the IESG approved it for publication. Not every IESG-approved doc is up for any level of Internet Standard, though. See Section 2 of RFC 7841 for more on that. 📚

For the latest status, errata, and feedback info, check https://www.rfc-editor.org/info/rfc9837. 🔗

the copyright belongs to the IETF Trust and the document authors, and everything's reserved, so no sneaky copying 🙈 The doc is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood when it was published. Read those carefully, because they spell out your rights and restrictions. 📜

If you pull Code Components out of this doc, they need to include Revised BSD License text as laid out in Section 4.e of the Trust Legal Provisions. They come with no warranty, per 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

1. Introduction ✨

okay so, Generic Packet Tunneling [RFC2473] lets a router in one network wrap up a packet in an IP header and send it to a router in another network. 🎁 The receiving router peels off that outer IP header and forwards the original packet into its own network. This helps networks connect when they use private addressing plans [RFC1918] [RFC4193] but don't share a direct link. 🧚

the IETF leveled this up in the Framework for VPN [RFC2764]. It also standardized a bunch of VPN techs, and they're giving variety 💅

  • 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 one customer endpoint to another. 🔐 Every other VPN tech on that list shares these characteristics:

  • An ingress Provider Edge (PE) router wraps customer data in a tunnel header 🎀. That header carries service information, and the service info points at a Forwarding Information Base (FIB) entry on an egress PE router 🗺️.
  • The ingress PE sends the encapsulated packet over to the egress PE. 🚀
  • The egress PE receives that encapsulated packet. 📬
  • The egress PE searches its FIB for an entry matching the incoming service info. If it finds one, it removes the tunnel header and forwards the customer data to a Customer Edge (CE) device, following that FIB entry. If there's no matching FIB entry, it throws the packet away. 🗑️💀

this doc describes an experiment where VPN service info is encoded in an experimental IPv6 Destination Option [RFC8200]. That option is called the VPN Service Option. 💖

the solution here has some seriously good perks 😭

  • it doesn't need any configuration on CE devices 🙌
  • it puts the service info in the IPv6 extension header, so it doesn't need any non-IPv6 headers (like MPLS headers) to carry that info 🧠
  • it supports many VPNs on a single egress PE router 👑
  • when one egress PE router is handling lots of VPNs, it doesn't need an IP address per VPN 🪄
  • it doesn't depend on any particular control plane 🫶

the three experiment goals from the abstract show up here too: 🌸 check that the VPN Service Option works in a production network, prove that the security measures in Section 7 of this document are strong enough to protect a VPN, and encourage replication so operational issues can get discovered. 🔍

2. Conventions and Definitions 📖

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are the BCP 14 vibes 💅 They're interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, just like they do here. 🔠

3. The VPN Service Option 🎀

the VPN Service Option is an IPv6 Destination Option, encoded using the rules in [RFC8200]. 🧁

as Section 4.2 of [RFC8200] explains, an IPv6 Destination Option has three fields: Option Type, Opt Data Len, and Option Data. Here's how the VPN Service Option uses them 👀

  • Option Type: an 8-bit selector for the VPN Service Option. This field MUST be set to 0x5E (RFC3692-style Experiment) [V6MSG]. See the NOTE below. 🧪
  • Opt Data Len: an 8-bit unsigned integer giving the option length in bytes, not counting the Option Type and Option Length fields. This field MUST be set to 4. 🔢
  • Option Data: 32 bits of VPN service info that identifies a FIB entry on the egress PE. The FIB entry decides how the egress PE forwards customer data to a CE device. 🗺️

a single VPN Service Option MAY show up in a Destination Options header that sits right before an upper-layer header 📦 It MUST NOT show up in any other extension header 🚫 If a receiver spots the VPN Service Option in some 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 the NOTE below). ⚙️

NOTE: here's the bit-level tea ☕ For this experiment, the Option Type is set to 01011110, which is 0x5E. The two highest-order bits are 01, which means that if a destination node doesn't recognize the option, the required action is to discard the packet 🗑️ The third highest-order bit is 0, which means the Option Data can't be modified along the path between the packet's source and destination 🔒 The remaining low-order bits are 11110, which points at the single IPv6 Destination Option Type code point left in the "Destination Options and Hop-by-Hop Options" registry [V6MSG] for experimentation 🧪✨

4. Forwarding Plane Considerations 🚀

the ingress PE wraps the customer data in a tunnel header 🎁 The tunnel header MUST contain an IPv6 header and a Destination Options header that sits immediately before 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 the guidance in [RFC6724]. 📍
  • Destination Address: represents an interface on the egress PE router. This address SHOULD be chosen according to the guidance 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. 🧃

5. Control Plane Considerations 🎛️

the FIB can be populated in three ways 🪄

  • 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. 🙅‍♀️

6. IANA Considerations 🏛️

this doc has no IANA actions. ✅

7. Security Considerations 🔐✨

Okay bestie, security time, and it's SERIOUS, but I'm still gonna make it cute 💅. A VPN is basically defined by this 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 works together to enforce this policy 🫶. If a device outside of that set could impersonate a device inside of the set, that device could subvert the security policy, and that is NOT it. So impersonation must not be possible. The paragraphs that follow describe the procedures that stop 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]

Now the limited domain case 🏰. 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 means they need explicit configuration to make sure packets using the approach in this document do not leak out of a domain. Check out [SAFE-LIM-DOMAINS] for a discussion of fail-open and fail-closed modes 🤓.

For more on the security concerns around IP tunnels and the recommended mitigation techniques, see [RFC6169] 💜.

8. Deployment Considerations 🚀

The VPN Service Option is imposed by an ingress PE and processed by an egress PE. No other nodes along the delivery path between the ingress PE and egress PE process it, so it's a very exclusive little option 👑.

BUT, some networks discard packets that include IPv6 Destination Options 😭. That's an impediment to deployment, and it's kind of a mood-killer.

Because the VPN Service Option uses an experimental code point, there's a risk of collisions with other experiments 💀. Specifically, the egress PE may process packets from another experiment that uses the same code point. Oops.

As with all experiments with IETF protocols, the operator is expected to take care 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 🔒🌸.

9. Experimental Results 🧪

Okay, now the homework part 📝. Parties participating in this experiment should publish their experimental results within one year of the publication of this document. Your results should cover 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?

10. References 📚

10.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,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC6169]  Krishnan, S., Thaler, D., and J. Hoagland, "Security
           Concerns with IP Tunneling", RFC 6169,
           DOI 10.17487/RFC6169, April 2011,
           <https://www.rfc-editor.org/info/rfc6169>.

[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,
           <https://www.rfc-editor.org/info/rfc6724>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
           (IPv6) Specification", STD 86, RFC 8200,
           DOI 10.17487/RFC8200, July 2017,
           <https://www.rfc-editor.org/info/rfc8200>.

10.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, <https://www.rfc-editor.org/info/rfc1918>.

[RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
           IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
           December 1998, <https://www.rfc-editor.org/info/rfc2473>.

[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,
           <https://www.rfc-editor.org/info/rfc2764>.

[RFC3884]  Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
           Transport Mode for Dynamic Routing", RFC 3884,
           DOI 10.17487/RFC3884, September 2004,
           <https://www.rfc-editor.org/info/rfc3884>.

[RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
           Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
           <https://www.rfc-editor.org/info/rfc4193>.

[RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
           DOI 10.17487/RFC4302, December 2005,
           <https://www.rfc-editor.org/info/rfc4302>.

[RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
           RFC 4303, DOI 10.17487/RFC4303, December 2005,
           <https://www.rfc-editor.org/info/rfc4303>.

[RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
           Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
           2006, <https://www.rfc-editor.org/info/rfc4364>.

[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,
           <https://www.rfc-editor.org/info/rfc4761>.

[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,
           <https://www.rfc-editor.org/info/rfc4762>.

[RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
           Element (PCE) Communication Protocol (PCEP)", RFC 5440,
           DOI 10.17487/RFC5440, March 2009,
           <https://www.rfc-editor.org/info/rfc5440>.

[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,
           <https://www.rfc-editor.org/info/rfc6241>.

[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,
           <https://www.rfc-editor.org/info/rfc6624>.

[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, <https://www.rfc-editor.org/info/rfc7432>.

[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,
           <https://www.rfc-editor.org/info/rfc8077>.

[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,
           <https://www.rfc-editor.org/info/rfc8986>.

[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,
           <https://www.rfc-editor.org/info/rfc9469>.

[SAFE-LIM-DOMAINS]
           Kumari, W., Alston, A., Vyncke, É., Krishnan, S., and D.
           Eastlake, "Safe(r) Limited Domains", Work in Progress,
           Internet-Draft, draft-wkumari-intarea-safe-limited-
           domains-04, 3 March 2025,
           <https://datatracker.ietf.org/doc/html/draft-wkumari-
           intarea-safe-limited-domains-04>.

[V6MSG]    IANA, "Destination Options and Hop-by-Hop Options",
           <https://www.iana.org/assignments/ipv6-parameters>.

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
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 DOCOMO BUSINESS
Chiyoda-ku, Tokyo
Japan
Email: y.kamite@ntt.com


Luay Jalil
Verizon
Richardson, Texas
United States of America
Email: luay.jalil@one.verizon.com
📦 where this page comes from