rfc9837.original   rfc9837.txt 
6man R. Bonica Internet Engineering Task Force (IETF) R. Bonica
Internet-Draft Juniper Networks Request for Comments: 9837 Juniper Networks
Intended status: Experimental X. Li Category: Experimental X. Li
Expires: 15 November 2025 CERNET Center/Tsinghua University ISSN: 2070-1721 CERNET Center/Tsinghua University
A. Farrel A. Farrel
Old Dog Consulting Old Dog Consulting
Y. Kamite Y. Kamite
NTT Communications Corporation NTT DOCOMO BUSINESS
L. Jalil L. Jalil
Verizon Verizon
14 May 2025 August 2025
The IPv6 VPN Service Destination Option The IPv6 VPN Service Destination Option
draft-ietf-6man-vpn-dest-opt-11
Abstract Abstract
This document describes an experiment in which VPN service This document describes an experiment in which VPN service
information is encoded in an experimental IPv6 Destination Option. information is encoded in an experimental IPv6 Destination Option.
The experimental IPv6 Destination Option is called the VPN Service The experimental IPv6 Destination Option is called the VPN Service
Option. Option.
One purpose of this experiment is to demonstrate that the VPN Service One purpose of this experiment is to demonstrate that the VPN Service
Option can be deployed in a production network. Another purpose is Option can be deployed in a production network. Another purpose is
to demonstrate that the security measures described in this document to demonstrate that the security measures described in this document
are sufficient to protect a VPN. Finally, this document encourages are sufficient to protect a VPN. Finally, this document encourages
replication of the experiment. replication of the experiment.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
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 This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 15 November 2025. 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 Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions
3. The VPN Service Option . . . . . . . . . . . . . . . . . . . 4 3. The VPN Service Option
4. Forwarding Plane Considerations . . . . . . . . . . . . . . . 5 4. Forwarding Plane Considerations
5. Control Plane Considerations . . . . . . . . . . . . . . . . 6 5. Control Plane Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 8. Deployment Considerations
9. Experimental Results . . . . . . . . . . . . . . . . . . . . 8 9. Experimental Results
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 10. References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References
11.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses
1. Introduction 1. Introduction
Generic Packet Tunneling [RFC2473] allows a router in one network to 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 encapsulate a packet in an IP header and send it to a router in
another network. The receiving router removes the outer IP header another network. The receiving router removes the outer IP header
and forwards the original packet into its own network. This and forwards the original packet into its own network. This
facilitates connectivity between networks that share a private facilitates connectivity between networks that share a private
addressing [RFC1918] [RFC4193] plan but are not connected by a direct addressing [RFC1918] [RFC4193] plan but are not connected by a direct
link. link.
The IETF refined this concept in a Framework For Virtual Private The IETF refined this concept in the Framework for VPN [RFC2764].
Networks (VPN) [RFC2764]. It also standardized the following VPN The IETF also standardized the following VPN technologies:
technologies:
* IPSec VPN [RFC3884]. * IPsec VPN [RFC3884]
* Layer 3 VPN (L3VPN) [RFC4364]. * Layer 3 VPN (L3VPN) [RFC4364]
* Virtual Private LAN Service (VPLS) [RFC4761][RFC4762]. * Virtual Private LAN Service (VPLS) [RFC4761][RFC4762]
* Layer 2 VPN (L2VPN) [RFC6624]. * Layer 2 VPN (L2VPN) [RFC6624]
* Ethernet VPN (EVPN) [RFC7432]. * Ethernet VPN (EVPN) [RFC7432]
* Pseudowires [RFC8077]. * Pseudowires [RFC8077]
* SRv6 [RFC8986]. * Segment Routing over IPv6 (SRv6) [RFC8986]
* EVPN / NVO3 [RFC9469]. * EVPN / Network Virtualization over Layer 3 (NVO3) [RFC9469]
IPSec VPNs cryptographically protect all traffic from customer IPsec VPNs cryptographically protect all traffic from customer
endpoint to customer endpoint. All of the other VPN technologies endpoint to customer endpoint. All of the other VPN technologies
mentioned above share the following characteristics: mentioned above share the following characteristics:
* An ingress Provider Edge (PE) router encapsulates customer data in * An ingress Provider Edge (PE) router encapsulates customer data in
a tunnel header. The tunnel header includes service information. a tunnel header. The tunnel header includes service information.
Service information identifies a Forwarding Information Base (FIB) Service information identifies a Forwarding Information Base (FIB)
entry on an egress PE router. entry on an egress PE router.
* The ingress PE router sends the encapsulated packet to the egress * The ingress PE router sends the encapsulated packet to the egress
PE router. PE router.
skipping to change at page 3, line 48 skipping to change at line 139
information is encoded in an experimental IPv6 Destination Option information is encoded in an experimental IPv6 Destination Option
[RFC8200]. The experimental IPv6 Destination Option is called the [RFC8200]. The experimental IPv6 Destination Option is called the
VPN Service Option. VPN Service Option.
The solution described in this document offers the following The solution described in this document offers the following
benefits: benefits:
* It does not require configuration on CE devices. * It does not require configuration on CE devices.
* It encodes service information in the IPv6 extension header. * It encodes service information in the IPv6 extension header.
Therefore, it does not require any non-IPv6 headers (e.g., MPLS) Therefore, it does not require any non-IPv6 headers (e.g., MPLS
to carry service information. headers) to carry service information.
* It supports many VPNs on a single egress PE router. * It supports many VPNs on a single egress PE router.
* When a single egress PE router supports many VPNs, it does not * When a single egress PE router supports many VPNs, it does not
require an IP address per VPN. require an IP address per VPN.
* It does not rely on any particular control plane. * It does not rely on any particular control plane.
One purpose of this experiment is to demonstrate that the VPN Service One purpose of this experiment is to demonstrate that the VPN Service
Option can be deployed in a production network. Another purpose is Option can be deployed in a production network. Another purpose is
to demonstrate that the security measures described in Section 7 of to demonstrate that the security measures described in Section 7 of
this document are sufficient to protect a VPN. Finally, this this document are sufficient to protect a VPN. Finally, this
document encourages replication of the experiment, so that document encourages replication of the experiment, so that
operational issues can be discovered. operational issues can be discovered.
2. Conventions and Definitions 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. The VPN Service Option 3. The VPN Service Option
The VPN Service Option is an IPv6 Destination Option encoded The VPN Service Option is an IPv6 Destination Option encoded
according to rules defined in [RFC8200]. according to rules defined in [RFC8200].
As described in section 4.2 of [RFC8200] a IPv6 Destination Option As described in Section 4.2 of [RFC8200], an IPv6 Destination Option
contains three fields: Option Type, Opt Data Len, and Option Data. contains three fields: Option Type, Opt Data Len, and Option Data.
In the VPN Service Option these fields are used as follows: In the VPN Service Option, these fields are used as follows:
* Option Type: 8-bit selector. VPN Service Option. This field MUST * Option Type: 8-bit selector. VPN Service Option. This field MUST
be set to RFC3692-style Experiment (0x5E) [V6MSG]. See Note be set to 0x5E (RFC3692-style Experiment) [V6MSG]. See NOTE
below. below.
* Opt Data Len - 8-bit unsigned integer. Length of the option, in * Opt Data Len: 8-bit unsigned integer. Length of the option, in
bytes, excluding the Option Type and Option Length fields. This bytes, excluding the Option Type and Option Length fields. This
field MUST be set to 4. field MUST be set to 4.
* Option Data - 32 bits. VPN Service Information that identifies a * Option Data: 32 bits. VPN service information that identifies a
FIB entry on the egress PE. The FIB entry determines how the FIB entry on the egress PE. The FIB entry determines how the
egress PE will forward customer data to a CE device. egress PE will forward customer data to a CE device.
A single VPN Service Option MAY appear in a Destination Options A single VPN Service Option MAY appear in a Destination Options
header that immediately precedes an upper-layer header. It MUST NOT header that immediately precedes an upper-layer header. It MUST NOT
appear in any other extension header. If a receiver finds the VPN appear in any other extension header. If a receiver finds the VPN
Service Option in any other extension header, it MUST NOT recognize Service Option in any other extension header, it MUST NOT recognize
the option. The packet MUST be processed according to the setting of the option. The packet MUST be processed according to the setting of
the two highest order bits of the Option Type (see NOTE below). the two highest-order bits of the Option Type (see NOTE below).
NOTE: For this experiment, the Option Type is set to '01011110', 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 i.e., 0x5E. The highest-order two bits are set to 01, indicating
the required action by a destination node that does not recognize the that the required action by a destination node that does not
option is to discard the packet. The third highest-order bit is set recognize the option is to discard the packet. The third highest-
to 0 indicating that Option Data cannot be modified along the path order bit is set to 0, indicating that Option Data cannot be modified
between the packet's source and its destination. The remaining low- along the path between the packet's source and its destination. The
order bits are set to '11110' to indicate the single IPv6 Destination remaining low-order bits are set to '11110' to indicate the single
Option Type code point available in the registry for experimentation. IPv6 Destination Option Type code point available in the "Destination
Options and Hop-by-Hop Options" registry [V6MSG] for experimentation.
4. Forwarding Plane Considerations 4. Forwarding Plane Considerations
The ingress PE encapsulates the customer data in a tunnel header. The ingress PE encapsulates the customer data in a tunnel header.
The tunnel header MUST contain an IPv6 header and a Destination The tunnel header MUST contain an IPv6 header and a Destination
Options header that immediately precedes the customer data. It MAY Options header that immediately precedes the customer data. It MAY
also include any legal combination of IPv6 extension headers. also include any legal combination of IPv6 extension headers.
The IPv6 header contains: The IPv6 Header contains the following (all defined in [RFC8200]):
* Version - Defined in [RFC8200]. MUST be equal to 6. * Version - MUST be equal to 6.
* Traffic Class - Defined in [RFC8200]. * Traffic Class
* Flow Label - Defined in [RFC8200]. * Flow Label
* Payload Length - Defined in [RFC8200]. * Payload Length
* Next Header - Defined in [RFC8200]. * Next Header
* Hop Limit - Defined in [RFC8200]. * Hop Limit
* Source Address - Defined in [RFC8200]. Represents an interface on * Source Address - Represents an interface on the ingress PE router.
the ingress PE router. This address SHOULD be chosen according to This address SHOULD be chosen according to guidance provided in
guidance provided in [RFC6724]. [RFC6724].
* Destination Address - Defined in [RFC8200]. Represents an * Destination Address - Represents an interface on the egress PE
interface on the egress PE router. This address SHOULD be chosen router. This address SHOULD be chosen according to guidance
according to guidance provided in [RFC6724]. provided in [RFC6724].
The IPv6 Destination Options Extension Header contains: The IPv6 Destination Options Extension Header contains the following
(all defined in [RFC8200]):
* Next Header - Defined in [RFC8200]. MUST identify the protocol of * Next Header - MUST identify the protocol of the customer data.
the customer data.
* Hdr Ext Len - Defined in [RFC8200]. * Hdr Ext Len
* Options - Defined in [RFC8200]. In this experiment, the Options * Options - In this experiment, the Options field MUST contain
field MUST contain exactly one VPN Service Option as defined in exactly one VPN Service Option as defined in Section 3 of this
Section 3 of this document. It MAY also contain any legal document. It MAY also contain any legal combination of other
combination of other Destination Options. Destination Options.
5. Control Plane Considerations 5. Control Plane Considerations
The FIB can be populated: The FIB can be populated by:
* By an operator, using a Command Line Interface (CLI). * An operator, using a Command-Line Interface (CLI)
* By a controller, using the Path Computation Element (PCE) * A controller, using the Path Computation Element Communication
Communication Protocol (PCEP) [RFC5440] or the Network Protocol (PCEP) [RFC5440] or the Network Configuration Protocol
Configuration Protocol (NETCONF) [RFC6241]. (NETCONF) [RFC6241]
* By a routing protocol. * A routing protocol
Routing protocol extensions that support the IPv6 VPN Service Routing protocol extensions that support the VPN Service Option are
Destination Option are beyond the scope of this document. beyond the scope of this document.
6. IANA Considerations 6. IANA Considerations
This document does not make any IANA requests. This document has no IANA actions.
7. Security Considerations 7. Security Considerations
A VPN is characterized by the following security policy: A VPN is characterized by the following security policy:
* Nodes outside of a VPN cannot inject traffic into the VPN. * Nodes outside of a VPN cannot inject traffic into the VPN.
* Nodes inside a VPN cannot send traffic outside of 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 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 device outside of that set could impersonate a device inside of the
set, it would be possible for that device to subvert security policy. set, it would be possible for that device to subvert security policy.
Therefore, impersonation must not be possible. The following Therefore, impersonation must not be possible. The following
paragraphs describe procedures that prevent impersonation. paragraphs describe procedures that prevent impersonation.
The IPv6 VPN Service Destination Option can be deployed: The VPN Service Option can be deployed:
* On the global Internet * On the global Internet
* Inside of a limited domain * Inside of a limited domain
When IPv6 VPN Service Destination Option is deployed on the global When the VPN Service Option is deployed on the global Internet, the
Internet, the tunnel that connects the ingress PE to the egress PE tunnel that connects the ingress PE to the egress PE MUST be
MUST be cryptographically protected by one of the following: cryptographically protected by one of the following:
* The IPv6 Authentication Header (AH) [RFC4302] * The IPv6 Authentication Header (AH) [RFC4302]
* The IPv6 Encapsulating Security Payload (ESP) Header [RFC4303]. * The IPv6 Encapsulating Security Payload (ESP) Header [RFC4303]
When IPv6 VPN Service Destination Option is deployed in a limited When the VPN Service Option is deployed in a limited domain, all
domain, all nodes at the edge of limited domain MUST maintain Access nodes at the edge of limited domain MUST maintain Access Control
Control Lists (ACLs). These ACL's MUST discard packets that satisfy Lists (ACLs). These ACLs MUST discard packets that satisfy the
the following criteria: following criteria:
* Contain an IPv6 VPN Service option. * Contain a VPN Service Option
* Contain an IPv6 Destination Address that represents an interface * Contain an IPv6 Destination Address that represents an interface
inside of the limited domain. inside of the limited domain
The mitigation techniques mentioned above operate in fail-open mode. The mitigation techniques mentioned above operate in fail-open mode.
That is, they require explicit configuration in order to ensure that That is, they require explicit configuration in order to ensure that
packets using the approach described in this document do not leak out packets using the approach described in this document do not leak out
of a domain. See [I-D.wkumari-intarea-safe-limited-domains] for a of a domain. See [SAFE-LIM-DOMAINS] for a discussion of fail-open
discussion of fail-open and fail-closed modes. and fail-closed modes.
For further information on the security concerns related to IP For further information on the security concerns related to IP
tunnels and the recommended mitigation techniques, please see tunnels and the recommended mitigation techniques, please see
[RFC6169]. [RFC6169].
8. Deployment Considerations 8. Deployment Considerations
The VPN Service Option is imposed by an ingress PE and processed by 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 an egress PE. It is not processed by any other nodes along the
delivery path between the ingress PE and egress PE. delivery path between the ingress PE and egress PE.
However, some networks discard packets that include IPv6 Destination However, some networks discard packets that include IPv6 Destination
Options. This is an impediment to deployment. Options. This is an impediment to deployment.
Because the VPN Service Option uses an experimental code point, there Because the VPN Service Option uses an experimental code point, there
is a risk of collisions with other experiments. Specifically, the is a risk of collisions with other experiments. Specifically, the
egress PE may process packets from another experiment that uses the egress PE may process packets from another experiment that uses the
same code point. same code point.
It is expected that, as with all experiments with IETF protocols, As with all experiments with IETF protocols, it is expected that care
care is taken by the operator to ensure that all nodes participating is taken by the operator to ensure that all nodes participating in an
in an experiment are carefully configured. experiment are carefully configured.
Because the VPN Service Destination Option uses an experimental code Because the VPN Service Destination Option uses an experimental code
point, processing of this option MUST be disabled by default. point, processing of this option MUST be disabled by default.
Explicit configuration is required to enable processing of the Explicit configuration is required to enable processing of the
option. option.
9. Experimental Results 9. Experimental Results
Parties participating in this experiment should publish experimental Parties participating in this experiment should publish experimental
results within one year of the publication of this document. results within one year of the publication of this document.
Experimental results should address the following: Experimental results should address the following:
* Effort required to deploy * Effort required to deploy
- Was deployment incremental or network-wide? - Was deployment incremental or network-wide?
- Was there a need to synchronize configurations at each node or - Was there a need to synchronize configurations at each node, or
could nodes be configured independently? could nodes be configured independently?
- Did the deployment require hardware upgrade? - Did the deployment require a hardware upgrade?
* Effort required to secure * Effort required to secure
- Performance impact - Performance impact
- Effectiveness of risk mitigation with ACLs - Effectiveness of risk mitigation with ACLs
- Cost of risk mitigation with ACLs - Cost of risk mitigation with ACLs
* Mechanism used to populate the FIB * Mechanism used to populate the FIB
* Scale of deployment * Scale of deployment
* Interoperability * Interoperability
- Did you deploy two interoperable implementations? - Did you deploy two interoperable implementations?
- Did you experience interoperability problems? - Did you experience interoperability problems?
* Effectiveness and sufficiency of OAM mechanisms * Effectiveness and sufficiency of Operations, Administration, and
Maintenance (OAM) mechanisms
- Did PING work? - Did PING work?
- Did TRACEROUTE work? - Did TRACEROUTE work?
- Did Wireshark work? - Did Wireshark work?
- Did TCPDUMP work? - Did TCPDUMP work?
10. Acknowledgements 10. References
Thanks to Gorry Fairhurst, Antoine Fressancourt, Eliot Lear and Mark
Smith for their reviews and contributions to this document.
11. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169, Concerns with IP Tunneling", RFC 6169,
DOI 10.17487/RFC6169, April 2011, DOI 10.17487/RFC6169, April 2011,
<https://www.rfc-editor.org/rfc/rfc6169>. <https://www.rfc-editor.org/info/rfc6169>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/rfc/rfc6724>. <https://www.rfc-editor.org/info/rfc6724>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
11.2. Informative References
[I-D.wkumari-intarea-safe-limited-domains] 10.2. Informative References
Kumari, W., Alston, A., Vyncke, E., Krishnan, S., and D.
E. 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>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/rfc/rfc1918>. February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/rfc/rfc2473>. December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
Malis, "A Framework for IP Based Virtual Private Malis, "A Framework for IP Based Virtual Private
Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000,
<https://www.rfc-editor.org/rfc/rfc2764>. <https://www.rfc-editor.org/info/rfc2764>.
[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
Transport Mode for Dynamic Routing", RFC 3884, Transport Mode for Dynamic Routing", RFC 3884,
DOI 10.17487/RFC3884, September 2004, DOI 10.17487/RFC3884, September 2004,
<https://www.rfc-editor.org/rfc/rfc3884>. <https://www.rfc-editor.org/info/rfc3884>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/rfc/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/rfc/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/rfc/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/rfc/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<https://www.rfc-editor.org/rfc/rfc4761>. <https://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP) LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/rfc/rfc4762>. <https://www.rfc-editor.org/info/rfc4762>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/rfc/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
Virtual Private Networks Using BGP for Auto-Discovery and Virtual Private Networks Using BGP for Auto-Discovery and
Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012,
<https://www.rfc-editor.org/rfc/rfc6624>. <https://www.rfc-editor.org/info/rfc6624>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/rfc/rfc7432>. 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and
Maintenance Using the Label Distribution Protocol (LDP)", Maintenance Using the Label Distribution Protocol (LDP)",
STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
<https://www.rfc-editor.org/rfc/rfc8077>. <https://www.rfc-editor.org/info/rfc8077>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986, (SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021, DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/rfc/rfc8986>. <https://www.rfc-editor.org/info/rfc8986>.
[RFC9469] Rabadan, J., Ed., Bocci, M., Boutros, S., and A. Sajassi, [RFC9469] Rabadan, J., Ed., Bocci, M., Boutros, S., and A. Sajassi,
"Applicability of Ethernet Virtual Private Network (EVPN) "Applicability of Ethernet Virtual Private Network (EVPN)
to Network Virtualization over Layer 3 (NVO3) Networks", to Network Virtualization over Layer 3 (NVO3) Networks",
RFC 9469, DOI 10.17487/RFC9469, September 2023, RFC 9469, DOI 10.17487/RFC9469, September 2023,
<https://www.rfc-editor.org/rfc/rfc9469>. <https://www.rfc-editor.org/info/rfc9469>.
[V6MSG] Internet Assigned Numbers Authority (IANA), "Internet [SAFE-LIM-DOMAINS]
Protocol Version 6 (IPv6) Parameters: Destination Options Kumari, W., Alston, A., Vyncke, É., Krishnan, S., and D.
and Hop-by-Hop Options", Web Eastlake, "Safe(r) Limited Domains", Work in Progress,
https://www.iana.org/assignments/ipv6-parameters/ Internet-Draft, draft-wkumari-intarea-safe-limited-
ipv6-parameters.xhtml#ipv6-parameters-2. 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 Authors' Addresses
Ron Bonica Ron Bonica
Juniper Networks Juniper Networks
Herndon, Virginia Herndon, Virginia
United States of America United States of America
Email: rbonica@juniper.net Email: rbonica@juniper.net
Xing Li Xing Li
skipping to change at page 12, line 4 skipping to change at line 518
Juniper Networks Juniper Networks
Herndon, Virginia Herndon, Virginia
United States of America United States of America
Email: rbonica@juniper.net Email: rbonica@juniper.net
Xing Li Xing Li
CERNET Center/Tsinghua University CERNET Center/Tsinghua University
Beijing Beijing
China China
Email: xing@cernet.edu.cn Email: xing@cernet.edu.cn
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
United Kingdom United Kingdom
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Yuji Kamite Yuji Kamite
NTT Communications Corporation NTT DOCOMO BUSINESS
Minato-ku Chiyoda-ku, Tokyo
Japan Japan
Email: y.kamite@ntt.com Email: y.kamite@ntt.com
Luay Jalil Luay Jalil
Verizon Verizon
Richardson, Texas Richardson, Texas
United States of America United States of America
Email: luay.jalil@one.verizon.com Email: luay.jalil@one.verizon.com
 End of changes. 86 change blocks. 
162 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.48.