6man R. Bonica
Internet-Draft Juniper Networks
Intended status: Experimental X. Li
Expires: 27 August 2025 CERNET Center/Tsinghua University
A. Farrel
Old Dog Consulting
Y. Kamite
NTT Communications Corporation
L. Jalil
Verizon
23 February 2025
The IPv6 VPN Service Destination Option
draft-ietf-6man-vpn-dest-opt-03
Abstract
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. The new IPv6 Destination Option is called
the VPN Service Option.
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. 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 27 August 2025.
Bonica, et al. Expires 27 August 2025 [Page 1]
Internet-Draft Svc. Dest. Opt. February 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. The VPN Service Option . . . . . . . . . . . . . . . . . . . 4
4. Forwarding Plane Considerations . . . . . . . . . . . . . . . 5
5. Control Plane Considerations . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
9. Experimental Results . . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Generic Packet Tunneling [RFC2473] 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 [RFC1918] [RFC4193] 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
Bonica, et al. Expires 27 August 2025 [Page 2]
Internet-Draft Svc. Dest. Opt. February 2025
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) [RFC6624].
* Layer 3 VPN (L3VPN) [RFC4364].
* Virtual Private LAN Service (VPLS) [RFC4761][RFC4762].
* Ethernet VPN (EVPN) [RFC7432].
* Pseudowires [RFC8077].
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
[RFC3032] service label.
* The egress PE removes the tunnel header, exposing the customer
data. It then queries its Forwarding Information Base (FIB) to
identify the interface through which the customer data is to be
forwarded. The service label, found in the tunnel header,
identifies either the outgoing interface or a VPN-specific portion
of the FIB that will be used to determine the outgoing interface.
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 [RFC8200] 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.
Bonica, et al. Expires 27 August 2025 [Page 3]
Internet-Draft Svc. Dest. Opt. February 2025
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. The VPN Service Option
The VPN Service Option is an IPv6 Destination Option encoded
following the encoding rules defined in [RFC8200].
As shown in section 4.2 of [RFC8200] 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)[V6MSG]. 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 either the outgoing interface or
a VPN-specific portion of the FIB that will be used to
determine the outgoing interface.
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 VPN Service option appears in another extension
header, the receiver MUST discard the packet.
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.
Bonica, et al. Expires 27 August 2025 [Page 4]
Internet-Draft Svc. Dest. Opt. February 2025
4. 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) [RFC4302]
* An IPv6 Destination Options Extension Header
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]. MUST be equal to either
Authentication Header (51) or Destination Options (60).
* Hop Limit - Defined in [RFC8200].
* Source Address - Defined in [RFC8200]. Represents an interface on
the ingress PE device.
* Destination Address - Defined in [RFC8200]. Represents an
interface on the egress PE device.
If the Authentication Header is present, it contains:
* Next Header - Defined in [RFC4302]. MUST be equal to Destination
Options (60) or Encapsulating Security Payload (ESP) (50).
* Payload Length - Defined in [RFC4302].
* Reserved - Defined in [RFC4302]. MUST be set to zero by the
sender, and SHOULD be ignored by the recipient.
* Security Parameters Index (SPI) - Defined in [RFC4302].
* Sequence Number - Defined in [RFC4302].
* Integrity Check Value (ICV) - Defined in [RFC4302].
Bonica, et al. Expires 27 August 2025 [Page 5]
Internet-Draft Svc. Dest. Opt. February 2025
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 [RFC8200]. MUST identify the protocol of
the customer data.
* Hdr Ext Len - Defined in [RFC8200]. MUST be equal to 0.
* Options - * Options - Defined in [RFC8200]. MUST contain exactly
one VPN Service Option as defined in Section 3 of this document.
5. 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 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.
6. 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.
7. 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 27 August 2025 [Page 6]
Internet-Draft Svc. Dest. Opt. February 2025
* Authenticate the packet option using the IPv6 Authentication
Header (AH) [RFC4302] or the IPv6 Encapsulating Security Payload
(ESP) Header [RFC4303]. 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 [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].
8. 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.
9. 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
Bonica, et al. Expires 27 August 2025 [Page 7]
Internet-Draft Svc. Dest. Opt. February 2025
- 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 mechanism
- Did PING work?
- Did TRACEROUTE work?
- Did Wireshark work?
- Did TCPDUMP work?
10. Acknowledgements
Thanks to Eliot Lear and Mark Smith for their reviews and
contributions to this document.
11. References
11.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/rfc/rfc2119>.
Bonica, et al. Expires 27 August 2025 [Page 8]
Internet-Draft Svc. Dest. Opt. February 2025
[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,
<https://www.rfc-editor.org/rfc/rfc4271>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/rfc/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/rfc/rfc4303>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/rfc/rfc4760>.
[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/rfc/rfc5440>.
[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/rfc/rfc6169>.
[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/rfc/rfc6241>.
[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/rfc/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/rfc/rfc8200>.
11.2. Informative References
[I-D.wkumari-intarea-safe-limited-domains]
Kumari, W. A., Alston, A., Vyncke, E., Krishnan, S., and
D. E. Eastlake, "Safe(r) Limited Domains", Work in
Progress, Internet-Draft, draft-wkumari-intarea-safe-
Bonica, et al. Expires 27 August 2025 [Page 9]
Internet-Draft Svc. Dest. Opt. February 2025
limited-domains-03, 20 January 2025,
<https://datatracker.ietf.org/doc/html/draft-wkumari-
intarea-safe-limited-domains-03>.
[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/rfc/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/rfc/rfc2473>.
[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,
<https://www.rfc-editor.org/rfc/rfc3032>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/rfc/rfc4193>.
[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/rfc/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/rfc/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/rfc/rfc4762>.
[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/rfc/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/rfc/rfc7432>.
Bonica, et al. Expires 27 August 2025 [Page 10]
Internet-Draft Svc. Dest. Opt. February 2025
[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/rfc/rfc8077>.
[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.
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 27 August 2025 [Page 11]