<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="utf-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.2.3) -->
<?rfc tocompact="yes"?>
<?rfc tocindent="yes"?>
<?rfc compact="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-6man-vpn-dest-opt-11" number="9837" consensus="true" updates="" obsoletes="" xml:lang="en" category="exp" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.1 -->

<front>
    <title abbrev="Svc. Dest. Opt.">The abbrev="Service Destination Option">The IPv6 VPN Service Destination Option</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-6man-vpn-dest-opt-11"/> name="RFC" value="9837"/>
    <author initials="R." surname="Bonica" fullname="Ron Bonica">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <city>Herndon</city>
          <region>Virginia</region>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>rbonica@juniper.net</email>
      </address>
    </author>
    <author initials="X." surname="Li" fullname="Xing Li">
      <organization>CERNET Center/Tsinghua University</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>xing@cernet.edu.cn</email>
      </address>
    </author>
    <author initials="A." surname="Farrel" fullname="Adrian Farrel">
      <organization>Old Dog Consulting</organization>
      <address>
        <postal>
          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>adrian@olddog.co.uk</email>
      </address>
    </author>
    <author initials="Y." surname="Kamite" fullname="Yuji Kamite">
      <organization>NTT Communications Corporation</organization>
      <address>
        <postal>
          <city>3-4-1 Shibaura</city>
          <street>3-4-1 Shibaura</street>
          <region>Minato-ku</region>
          <country>Japan</country>
        </postal>
        <email>y.kamite@ntt.com</email>
      </address>
    </author>
    <author initials="L." surname="Jalil" fullname="Luay Jalil">
      <organization>Verizon</organization>
      <address>
        <postal>
          <city>Richardson</city>
          <region>Texas</region>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>luay.jalil@one.verizon.com</email>
      </address>
    </author>
    <date year="2025" month="May" day="14"/>
    <area>Internet</area> month="August"/>
    <area>INT</area>
    <workgroup>6man</workgroup>
    <keyword>IPv6, Destination Option, VPN</keyword>
    <keyword>IPv6</keyword>
    <keyword>Destination Option</keyword>
    <keyword>VPN</keyword>
    <abstract>
      <?line 93?>
<t>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.</t>
      <t>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.</t>
    </abstract>
  </front>
  <middle>
    <?line 99?>
<section anchor="introduction">
      <name>Introduction</name>
      <t>Generic Packet Tunneling <xref target="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 <xref target="RFC1918"/> <xref target="RFC4193"/> plan but are not connected by a direct link.</t>
      <t>The IETF refined this concept in a the Framework For Virtual Private Networks (VPN) for VPN <xref target="RFC2764"/>. It The IETF also standardized the following VPN technologies:</t>
      <ul spacing="normal">
        <li>
          <t>IPSec
          <t>IPsec VPN <xref target="RFC3884"/>.</t> target="RFC3884"/></t>
        </li>
        <li>
          <t>Layer 3 VPN (L3VPN) <xref target="RFC4364"/>.</t> target="RFC4364"/></t>
        </li>
        <li>
          <t>Virtual Private LAN Service (VPLS) <xref target="RFC4761"/><xref target="RFC4762"/>.</t> target="RFC4762"/></t>
        </li>
        <li>
          <t>Layer 2 VPN (L2VPN) <xref target="RFC6624"/>.</t> target="RFC6624"/></t>
        </li>
        <li>
          <t>Ethernet VPN (EVPN) <xref target="RFC7432"/>.</t> target="RFC7432"/></t>
        </li>
        <li>
          <t>Pseudowires <xref target="RFC8077"/>.</t> target="RFC8077"/></t>
        </li>
        <li>
          <t>SRv6
          <t>Segment Routing over IPv6 (SRv6) <xref target="RFC8986"/>.</t> target="RFC8986"/></t>
        </li>
        <li>
          <t>EVPN / NVO3 Network Virtualization over Layer 3 (NVO3)  <xref target="RFC9469"/>.</t> target="RFC9469"/></t>
        </li>
      </ul>
      <t>IPSec
      <t>IPsec VPNs cryptographically protect all traffic from customer endpoint to customer endpoint. All of the other VPN technologies mentioned above share the following characteristics:</t>
      <ul spacing="normal">
        <li>
          <t>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.</t>
        </li>
        <li>
          <t>The ingress PE router sends the encapsulated packet to the egress PE router.</t>
        </li>
        <li>
          <t>The egress PE router receives the encapsulated packet.</t>
        </li>
        <li>
          <t>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.</t>
        </li>
      </ul>
      <t>This document describes an experiment in which VPN service information is encoded in an experimental IPv6 Destination Option <xref target="RFC8200"/>. The experimental IPv6 Destination Option is called the VPN Service Option.</t>
      <t>The solution described in this document offers the following benefits:</t>
      <ul spacing="normal">
        <li>
          <t>It does not require configuration on CE devices.</t>
        </li>
        <li>
          <t>It encodes service information in the IPv6 extension header. Therefore, it does not require any non-IPv6 headers (e.g., MPLS) MPLS headers) to carry service information.</t>
        </li>
        <li>
          <t>It supports many VPNs on a single egress PE router.</t>
        </li>
        <li>
          <t>When a single egress PE router supports many VPNs, it does not require an IP address per VPN.</t>
        </li>
        <li>
          <t>It does not rely on any particular control plane.</t>
        </li>
      </ul>
      <t>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 <xref target="security"/> of this document are sufficient to protect a VPN. Finally, this document encourages replication of the experiment, so that operational issues can be discovered.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t>
      <?line -18?> here.
        </t>

    </section>
    <section anchor="option">
      <name>The VPN Service Option</name>
      <t>The VPN Service Option is an IPv6 Destination Option encoded according to rules defined in <xref target="RFC8200"/>.</t>
      <t>As described in section 4.2 of <xref target="RFC8200"/> a target="RFC8200" section="4.2"/>, an IPv6 Destination Option contains three fields: Option Type, Opt Data Len, and Option Data. In the VPN Service Option Option, these fields are used as follows:</t>
      <ul spacing="normal">
        <li>
          <t>Option Type: 8-bit selector.  VPN Service Option. This field <bcp14>MUST</bcp14> be set to RFC3692-style Experiment (0x5E) 0x5E (RFC3692-style Experiment) <xref target="V6MSG"/>.  See Note NOTE below.</t>
        </li>
        <li>
          <t>Opt Data Len - Len: 8-bit unsigned integer.  Length of the option, in
 bytes, excluding the Option Type and Option Length fields.  This
 field <bcp14>MUST</bcp14> be set to 4.</t>
        </li>
        <li>
          <t>Option Data - Data: 32 bits.  VPN Service Information 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.</t>
        </li>
      </ul>
      <t>A single VPN Service Option <bcp14>MAY</bcp14> appear in a Destination Options header
that immediately precedes an upper-layer header. It <bcp14>MUST NOT</bcp14> appear in any other
extension header.  If a receiver finds the VPN Service Option in any other
extension header, it <bcp14>MUST NOT</bcp14> recognize the option.
      The packet <bcp14>MUST</bcp14> be processed according to the setting of the two highest
order highest-order bits of the Option Type (see NOTE below).</t>
      <t>NOTE:

<!-- [rfced] Should the note in Section 3 of this document be in the <aside>
element? The <aside> element is defined as "a container for content that
is semantically less important or tangential to the content that
surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).

Original:
   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 registry for experimentation.
-->

<!-- [rfced] FYI - We updated this sentence as follows to clarify "in the
registry". We also moved "for experimentation" to earlier in the
sentence. Let us know any concerns.

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

Perhaps:
   The remaining low-order bits are set to '11110' to indicate the single
   IPv6 Destination Option Type code point available for experimentation
   in the "Destination Options and Hop-by-Hop Options" registry [V6MSG].
-->

      <t>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 for experimentation.</t> experimentation in the "Destination Options and Hop-by-Hop Options" registry <xref target="V6MSG"/>.</t>
    </section>
    <section anchor="forwarding-plane-considerations">
      <name>Forwarding Plane Considerations</name>
      <t>The ingress PE encapsulates the customer data in a tunnel header. The tunnel header <bcp14>MUST</bcp14> contain an IPv6 header and a Destination Options header that immediately precedes the customer data. It <bcp14>MAY</bcp14> also include any legal combination of IPv6 extension headers.</t>
      <t>The IPv6 header contains:</t>

<!-- [rfced] Would you like to update these list items to avoid repitition of
"Defined in"? Or do you prefer the current?

Original:
   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].

   *  Hop Limit - Defined in [RFC8200].

   *  Source Address - Defined in [RFC8200].  Represents an interface on
      the ingress PE router.  This address SHOULD be chosen according to
      guidance provided in [RFC6724].

   *  Destination Address - Defined in [RFC8200].  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:

   *  Next Header - Defined in [RFC8200].  MUST identify the protocol of
      the customer data.

   *  Hdr Ext Len - Defined in [RFC8200].

Perhaps (remove "Defined in"):
   The IPv6 header contains:

   *  Version [RFC8200].  MUST be equal to 6.

   *  Traffic Class [RFC8200]

   *  Flow Label [RFC8200]

   *  Payload Length [RFC8200]

   *  Next Header [RFC8200]

   *  Hop Limit [RFC8200]

   *  Source Address [RFC8200].  Represents an interface on
      the ingress PE router.  This address SHOULD be chosen according to
      guidance provided in [RFC6724].

   *  Destination Address [RFC8200].  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:

   *  Next Header [RFC8200]. MUST identify the protocol of
      the customer data.

   *  Hdr Ext Len [RFC8200]

Or (include [RFC8200] in introductory text):
   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
   (both defined in [RFC8200]):

   *  Next Header - MUST identify the protocol of
      the customer data.

   *  Hdr Ext Len
-->

      <ul spacing="normal">
        <li>
          <t>Version - Defined in <xref target="RFC8200"/>. <bcp14>MUST</bcp14> be equal to 6.</t>
        </li>
        <li>
          <t>Traffic Class - Defined in <xref target="RFC8200"/>.</t>
        </li>
        <li>
          <t>Flow Label - Defined in <xref target="RFC8200"/>.</t>
        </li>
        <li>
          <t>Payload Length - Defined in <xref target="RFC8200"/>.</t>
        </li>
        <li>
          <t>Next Header - Defined in <xref target="RFC8200"/>.</t>
        </li>
        <li>
          <t>Hop Limit - Defined in <xref target="RFC8200"/>.</t>
        </li>
        <li>
          <t>Source Address - Defined in <xref target="RFC8200"/>. Represents an interface on the ingress PE router. This address <bcp14>SHOULD</bcp14> be chosen according to guidance provided in <xref target="RFC6724"/>.</t>
        </li>
        <li>
          <t>Destination Address - Defined in <xref target="RFC8200"/>. Represents an interface on the egress PE router. This address <bcp14>SHOULD</bcp14> be chosen according to guidance provided in <xref target="RFC6724"/>.</t>
        </li>
      </ul>
      <t>The IPv6 Destination Options Extension Header contains:</t>
      <ul spacing="normal">
        <li>
          <t>Next Header - Defined in <xref target="RFC8200"/>. <bcp14>MUST</bcp14> identify the protocol of the customer data.</t>
        </li>
        <li>
          <t>Hdr Ext Len - Defined in <xref target="RFC8200"/>.</t>
        </li>
        <li>
          <t>Options - Defined in <xref target="RFC8200"/>.  In this experiment, the Options field <bcp14>MUST</bcp14> contain exactly one VPN Service Option as defined in <xref target="option"/> of this document. It <bcp14>MAY</bcp14> also contain any legal combination of other Destination Options.</t>
        </li>
      </ul>
    </section>
    <section anchor="control-plane-considerations">
      <name>Control Plane Considerations</name>
      <t>The FIB can be populated:</t> populated by:</t>
      <ul spacing="normal">
        <li>
          <t>By an
          <t>An operator, using a Command Line Command-Line Interface (CLI).</t> (CLI)</t>
        </li>
        <li>
          <t>By a
          <t>A controller, using the Path Computation Element (PCE)
Communication Protocol (PCEP) <xref target="RFC5440"/> or the Network
Configuration Protocol (NETCONF) <xref target="RFC6241"/>.</t> target="RFC6241"/></t>
        </li>
        <li>
          <t>By a
          <t>A routing protocol.</t> protocol</t>
        </li>
      </ul>
      <t>Routing protocol extensions that support the IPv6 VPN Service Destination Option are beyond the scope of this document.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document does not make any has no IANA requests.</t> actions.</t>
    </section>
    <section anchor="security">
      <name>Security Considerations</name>
      <t>A VPN is characterized by the following security policy:</t>
      <ul spacing="normal">
        <li>
          <t>Nodes outside of a VPN cannot inject traffic into the VPN.</t>
        </li>
        <li>
          <t>Nodes inside a VPN cannot send traffic outside of the VPN.</t>
        </li>
      </ul>
      <t>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.</t>
      <t>The IPv6 VPN Service Destination Option can be deployed:</t>
      <ul spacing="normal">
        <li>
          <t>On the global Internet</t>
        </li>
        <li>
          <t>Inside of a limited domain</t>
        </li>
      </ul>
      <t>When the IPv6 VPN Service Destination Option is deployed on the global Internet, the tunnel that connects the ingress PE to the egress PE <bcp14>MUST</bcp14> be cryptographically protected by one of the following:</t>
      <ul spacing="normal">
        <li>
          <t>The IPv6 Authentication Header (AH) <xref target="RFC4302"/></t>
        </li>
        <li>
          <t>The IPv6 Encapsulating Security Payload (ESP) Header <xref target="RFC4303"/>.</t> target="RFC4303"/></t>
        </li>
      </ul>
      <t>When the IPv6 VPN Service Destination Option is deployed in a limited domain, all nodes at the edge of limited domain <bcp14>MUST</bcp14> maintain Access Control Lists (ACLs).  These ACL's ACLs <bcp14>MUST</bcp14> discard packets that satisfy the following criteria:</t>
      <ul spacing="normal">
        <li>
          <t>Contain an IPv6 VPN Service option.</t> Option</t>
        </li>
        <li>
          <t>Contain an IPv6 Destination Address that represents an interface inside of the limited domain.</t> domain</t>
        </li>
      </ul>
      <t>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 <xref target="I-D.wkumari-intarea-safe-limited-domains"/> for a discussion of fail-open
and fail-closed modes.</t>
      <t>For further information on the security concerns related to IP tunnels and the
recommended mitigation techniques, please see <xref target="RFC6169"/>.</t>
    </section>
    <section anchor="deployment-considerations">
      <name>Deployment Considerations</name>
      <t>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.</t>
      <t>However, some networks discard packets that include IPv6 Destination Options.
This is an impediment to deployment.</t>
      <t>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.</t>
      <t>It is expected that, as
      <t>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.</t>
      <t>Because the VPN Service Destination Option uses an experimental code point,
processing of this option <bcp14>MUST</bcp14> be disabled by default. Explicit configuration
is required to enable processing of the option.</t>
    </section>
    <section anchor="experimental-results">
      <name>Experimental Results</name>
      <t>Parties participating in this experiment should publish experimental results within one year of the publication of this document. Experimental results should address the following:</t>
      <ul spacing="normal">
        <li>
          <t>Effort required to deploy
          </t>
          <ul spacing="normal">
            <li>
              <t>Was deployment incremental or network-wide?</t>
            </li>
            <li>
              <t>Was there a need to synchronize configurations at each node node, or could nodes be configured independently?</t>
            </li>
            <li>
              <t>Did the deployment require a hardware upgrade?</t>
            </li>
          </ul>
        </li>
        <li>
          <t>Effort required to secure
          </t>
          <ul spacing="normal">
            <li>
              <t>Performance impact</t>
            </li>
            <li>
              <t>Effectiveness of risk mitigation with ACLs</t>
            </li>
            <li>
              <t>Cost of risk mitigation with ACLs</t>
            </li>
          </ul>
        </li>
        <li>
          <t>Mechanism used to populate the FIB</t>
        </li>
        <li>
          <t>Scale of deployment</t>
        </li>
        <li>
          <t>Interoperability
          </t>
          <ul spacing="normal">
            <li>
              <t>Did you deploy two interoperable implementations?</t>
            </li>
            <li>
              <t>Did you experience interoperability problems?</t>
            </li>
          </ul>
        </li>
        <li>
          <t>Effectiveness and sufficiency of OAM Operations, Administration, and Maintenance (OAM)  mechanisms
          </t>
          <ul spacing="normal">
            <li>
              <t>Did PING work?</t>
            </li>
            <li>
              <t>Did TRACEROUTE work?</t>
            </li>
            <li>
              <t>Did Wireshark work?</t>
            </li>
            <li>
              <t>Did TCPDUMP work?</t>
            </li>
          </ul>
        </li>
      </ul>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>Thanks to Gorry Fairhurst, Antoine Fressancourt, Eliot Lear and Mark Smith for their reviews and contributions to this document.</t>
    </section>
  </middle>
  <back>
<displayreference target="I-D.wkumari-intarea-safe-limited-domains" to="SAFE-LIM-DOMAINS"/>

    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC6169">
          <front>
            <title>Security Concerns with IP Tunneling</title>
            <author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
            <author fullname="D. Thaler" initials="D." surname="Thaler"/>
            <author fullname="J. Hoagland" initials="J." surname="Hoagland"/>
            <date month="April" year="2011"/>
            <abstract>
              <t>A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6169"/>
          <seriesInfo name="DOI" value="10.17487/RFC6169"/>
        </reference>
        <reference anchor="RFC6724">
          <front>
            <title>Default Address Selection for Internet Protocol Version 6 (IPv6)</title>
            <author fullname="D. Thaler" initials="D." role="editor" surname="Thaler"/>
            <author fullname="R. Draves" initials="R." surname="Draves"/>
            <author fullname="A. Matsumoto" initials="A." surname="Matsumoto"/>
            <author fullname="T. Chown" initials="T." surname="Chown"/>
            <date month="September" year="2012"/>
            <abstract>
              <t>This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa.</t>
              <t>Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6724"/>
          <seriesInfo name="DOI" value="10.17487/RFC6724"/>
        </reference>
        <reference anchor="RFC8200">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <date month="July" year="2017"/>
            <abstract>
              <t>This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="86"/>
          <seriesInfo name="RFC" value="8200"/>
          <seriesInfo name="DOI" value="10.17487/RFC8200"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6169.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6724.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2473.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2764.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3884.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4193.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4761.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4762.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6624.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8077.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9469.xml"/>
        <reference anchor="RFC1918"> anchor="V6MSG" target="https://www.iana.org/assignments/ipv6-parameters">
          <front>
            <title>Address Allocation for Private Internets</title>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <author fullname="B. Moskowitz" initials="B." surname="Moskowitz"/>
            <author fullname="D. Karrenberg" initials="D." surname="Karrenberg"/>
            <author fullname="G. J. de Groot" initials="G. J." surname="de Groot"/>
            <author fullname="E. Lear" initials="E." surname="Lear"/>
            <date month="February" year="1996"/>
            <abstract>
              <t>This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion
            <title>Destination Options and suggestions for improvements.</t>
            </abstract> Hop-by-Hop Options</title>
            <author>
              <organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
            </author>
            <date/>
          </front>
          <seriesInfo name="BCP" value="5"/>
          <seriesInfo name="RFC" value="1918"/>
          <seriesInfo name="DOI" value="10.17487/RFC1918"/>
        </reference>
        <reference anchor="RFC2473">
          <front>
            <title>Generic Packet Tunneling in IPv6 Specification</title>
            <author fullname="A. Conta" initials="A." surname="Conta"/>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <date month="December" year="1998"/>
            <abstract>
              <t>This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such
<!-- [I-D.wkumari-intarea-safe-limited-domains]
draft-wkumari-intarea-safe-limited-domains-04
IESG State: I-D Exists as IPv6 and IPv4. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2473"/>
          <seriesInfo name="DOI" value="10.17487/RFC2473"/>
        </reference> of 06/25/25
Long Way - author initials
-->

<reference anchor="RFC2764"> anchor="I-D.wkumari-intarea-safe-limited-domains" target="https://datatracker.ietf.org/doc/html/draft-wkumari-intarea-safe-limited-domains-04">
<front>
            <title>A Framework for IP Based Virtual Private Networks</title>
<title>Safe(r) Limited Domains</title>
<author fullname="B. Gleeson" initials="B." surname="Gleeson"/> fullname="Warren Kumari" initials="W." surname="Kumari">
<organization>Google, LLC</organization>
</author>
<author fullname="A. Lin" fullname="Andrew Alston" initials="A." surname="Lin"/> surname="Alston">
<organization>Alston Networks</organization>
</author>
<author fullname="J. Heinanen" initials="J." surname="Heinanen"/> fullname="Éric Vyncke" initials="É." surname="Vyncke">
<organization>Cisco</organization>
</author>
<author fullname="G. Armitage" initials="G." surname="Armitage"/> fullname="Suresh Krishnan" initials="S." surname="Krishnan">
<organization>Cisco</organization>
</author>
<author fullname="A. Malis" initials="A." surname="Malis"/> fullname="Donald E. Eastlake 3rd" initials="D." surname="Eastlake">
<organization>Independent</organization>
</author>
<date month="February" year="2000"/>
            <abstract>
              <t>This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. This memo provides information for the Internet community.</t>
            </abstract> day="3" month="March" year="2025"/>
</front>
<seriesInfo name="RFC" value="2764"/>
          <seriesInfo name="DOI" value="10.17487/RFC2764"/> name="Internet-Draft" value="draft-wkumari-intarea-safe-limited-domains-04"/>
</reference>
        <reference anchor="RFC3884">
          <front>
            <title>Use of IPsec Transport Mode for Dynamic Routing</title>
            <author fullname="J. Touch" initials="J." surname="Touch"/>
            <author fullname="L. Eggert" initials="L." surname="Eggert"/>
            <author fullname="Y. Wang" initials="Y." surname="Wang"/>
            <date month="September" year="2004"/>
            <abstract>
              <t>IPsec can secure the links of a multihop network
      </references>
    </references>
    <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>Thanks to protect communication between trusted components, e.g., <contact fullname="Gorry Fairhurst"/>, <contact fullname="Antoine Fressancourt"/>, <contact fullname="Eliot Lear"/>, and <contact fullname="Mark Smith"/> for a secure virtual network (VN), overlay, or virtual private network (VPN). Virtual links established by IPsec tunnel mode can conflict with routing their reviews and forwarding inside VNs because IP routing depends on references contributions to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of the VN packet. IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database (SAD) match on the tunnel header. IIPtran supports dynamic routing inside the VN without changes to document.</t>
    </section>

  </back>

<!-- [rfced] Terminology

a) We see the current IPsec architecture. IIPtran demonstrates how to configure any compliant IPsec implementation to avoid following forms in the aforementioned conflicts. IIPtran document. Should these be consistent? If
so, please let us know which form is also compared to several alternative mechanisms for VN routing and their respective impact on IPsec, routing, policy enforcement, and interactions with the Internet Key Exchange (IKE). This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3884"/>
          <seriesInfo name="DOI" value="10.17487/RFC3884"/>
        </reference>
        <reference anchor="RFC4193">
          <front>
            <title>Unique Local preferred.

IPv6 Unicast Addresses</title>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <author fullname="B. Haberman" initials="B." surname="Haberman"/>
            <date month="October" year="2005"/>
            <abstract>
              <t>This document defines an VPN Service Option
VPN Service Option

Destination Options header
IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4193"/>
          <seriesInfo name="DOI" value="10.17487/RFC4193"/>
        </reference>
        <reference anchor="RFC4302">
          <front>
            <title>IP Authentication Header</title>
            <author fullname="S. Kent" initials="S." surname="Kent"/>
            <date month="December" year="2005"/>
            <abstract>
              <t>This document describes an updated version of the IP Authentication Destination Options Extension Header (AH), which is designed to provide authentication services

b) Please review "Destination Options" in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4302"/>
          <seriesInfo name="DOI" value="10.17487/RFC4302"/>
        </reference>
        <reference anchor="RFC4303">
          <front>
            <title>IP Encapsulating Security Payload (ESP)</title>
            <author fullname="S. Kent" initials="S." surname="Kent"/>
            <date month="December" year="2005"/>
            <abstract>
              <t>This document describes an this sentence. Is this correct, or
should this be updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix "Destination Options headers" or "IPv6 Destination
Options"?

Original:
   It MAY also contain any legal
   combination of security services other Destination Options.

c) We see the following forms in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4303"/>
          <seriesInfo name="DOI" value="10.17487/RFC4303"/>
        </reference>
        <reference anchor="RFC4364">
          <front>
            <title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="February" year="2006"/>
            <abstract>
              <t>This document describes a method by which a the document:

IPv6 VPN Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", Destination Option (5 instances, including in which the customers' edge routers (CE routers) send their routes to the document title)
VPN Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so Destination Option (1 instance)

The abstract notes that the core routers do not need to know "The experimental IPv6 Destination Option is called
the VPN routes. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4364"/>
          <seriesInfo name="DOI" value="10.17487/RFC4364"/>
        </reference>
        <reference anchor="RFC4761">
          <front>
            <title>Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling</title>
            <author fullname="K. Kompella" initials="K." role="editor" surname="Kompella"/>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <date month="January" year="2007"/>
            <abstract>
              <t>Virtual Private LAN Service (VPLS), also known as Transparent LAN Option." We see instances of "VPN Service Option" and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in "IPv6
Destination Option" throughout the case document.

Should instances of VPLS, the customers in the "IPv6 VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature.</t>
              <t>This document describes the functions required Service Destination Option" be updated to offer VPLS, a mechanism for signaling a VPLS, "VPN
Service Option"? Please review and rules let us know if any updates are needed for forwarding VPLS frames across a packet switched network. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4761"/>
          <seriesInfo name="DOI" value="10.17487/RFC4761"/>
        </reference>
        <reference anchor="RFC4762">
          <front>
            <title>Virtual Private LAN
clarity.

Original:
  IPv6 VPN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling</title>
            <author fullname="M. Lasserre" initials="M." role="editor" surname="Lasserre"/>
            <author fullname="V. Kompella" initials="V." role="editor" surname="Kompella"/>
            <date month="January" year="2007"/>
            <abstract>
              <t>This document describes a Virtual Private LAN Destination Option

Perhaps:
  VPN Service (VPLS) solution using pseudowires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses and that is closed to a given set of users. Multiple VPLS services can be supported from a single Provider Edge (PE) node.</t>
              <t>This document describes Option

d) We have updated the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP), extending RFC 4447. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing abbreviated title (appears in particular on the learning of MAC addresses. The encapsulation of VPLS packets is described by RFC 4448. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4762"/>
          <seriesInfo name="DOI" value="10.17487/RFC4762"/>
        </reference>
        <reference anchor="RFC5440">
          <front>
            <title>Path Computation Element (PCE) Communication Protocol (PCEP)</title>
            <author fullname="JP. Vasseur" initials="JP." role="editor" surname="Vasseur"/>
            <author fullname="JL. Le Roux" initials="JL." role="editor" surname="Le Roux"/>
            <date month="March" year="2009"/>
            <abstract>
              <t>This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to running header at the use
top of a PCE each page in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so pdf output) as to easily allow for the addition of further messages and objects, should follows. Let us know if any further requirements be expressed in the future. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5440"/>
          <seriesInfo name="DOI" value="10.17487/RFC5440"/>
        </reference>
        <reference anchor="RFC6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations
updates are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
        <reference anchor="RFC6624">
          <front>
            <title>Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling</title>
            <author fullname="K. Kompella" initials="K." surname="Kompella"/>
            <author fullname="B. Kothari" initials="B." surname="Kothari"/>
            <author fullname="R. Cherukuri" initials="R." surname="Cherukuri"/>
            <date month="May" year="2012"/>
            <abstract>
              <t>Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where needed per the L2VPN customer's experience is virtually identical to that offered by traditional L2VPNs, but such that a question above.

Original:
  Svc. Dest. Opt.

Updated:
  Service Provider can maintain a single network for L2VPNs, IP VPNs, and the Internet, as well as a common provisioning methodology for all services. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6624"/>
          <seriesInfo name="DOI" value="10.17487/RFC6624"/>
        </reference>
        <reference anchor="RFC7432">
          <front>
            <title>BGP MPLS-Based Ethernet VPN</title>
            <author fullname="A. Sajassi" initials="A." role="editor" surname="Sajassi"/>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="A. Isaac" initials="A." surname="Isaac"/>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <date month="February" year="2015"/>
            <abstract>
              <t>This document describes procedures Destination Option

Perhaps:
  VPN Service Option
-->

<!-- [rfced] FYI - We have added expansions for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in following abbreviations
per Section 3.6 of RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7432"/>
          <seriesInfo name="DOI" value="10.17487/RFC7432"/>
        </reference>
        <reference anchor="RFC8077">
          <front>
            <title>Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)</title>
            <author fullname="L. Martini" initials="L." role="editor" surname="Martini"/>
            <author fullname="G. Heron" initials="G." role="editor" surname="Heron"/>
            <date month="February" year="2017"/>
            <abstract>
              <t>Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating 7322 ("RFC Style Guide"). Please review each
expansion in the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions carefully to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents.</t>
              <t>This document is a rewrite of RFC 4447 for publication as an Internet Standard.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="84"/>
          <seriesInfo name="RFC" value="8077"/>
          <seriesInfo name="DOI" value="10.17487/RFC8077"/>
        </reference>
        <reference anchor="RFC8986">
          <front>
            <title>Segment Routing over IPv6 (SRv6) Network Programming</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="P. Camarillo" initials="P." role="editor" surname="Camarillo"/>
            <author fullname="J. Leddy" initials="J." surname="Leddy"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
            <author fullname="Z. Li" initials="Z." surname="Li"/>
            <date month="February" year="2021"/>
            <abstract>
              <t>The ensure correctness.

Segment Routing over IPv6 (SRv6)
Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.</t>
              <t>Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</t>
              <t>This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8986"/>
          <seriesInfo name="DOI" value="10.17487/RFC8986"/>
        </reference>
        <reference anchor="RFC9469">
          <front>
            <title>Applicability of Ethernet Virtual Private Network (EVPN) to Network Virtualization over Layer 3 (NVO3) Networks</title>
            <author fullname="J. Rabadan" initials="J." role="editor" surname="Rabadan"/>
            <author fullname="M. Bocci" initials="M." surname="Bocci"/>
            <author fullname="S. Boutros" initials="S." surname="Boutros"/>
            <author fullname="A. Sajassi" initials="A." surname="Sajassi"/>
            <date month="September" year="2023"/>
            <abstract>
              <t>An Ethernet Virtual Private Network (EVPN) provides a unified control plane that solves the issues of Network Virtualization Edge (NVE) auto-discovery, tenant Media Access Control (MAC) / IP dissemination, and advanced features in a scablable way as required by Network Virtualization over Layer 3 (NVO3) networks. EVPN is a scalable solution for NVO3 networks and keeps the independence of the underlay IP Fabric, i.e., there is no need to enable Protocol Independent Multicast (PIM) in the underlay network
Operations, Administration, and maintain multicast states for tenant Broadcast Domains. This document describes the use of EVPN for NVO3 networks and discusses its applicability to basic Layer 2 and Layer 3 connectivity requirements and to advanced features such as MAC Mobility, MAC Protection and Loop Protection, multihoming, Data Center Interconnect (DCI), and much more. No new EVPN procedures are introduced.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9469"/>
          <seriesInfo name="DOI" value="10.17487/RFC9469"/>
        </reference>
        <reference anchor="V6MSG">
          <front>
            <title>Internet Protocol Version 6 (IPv6) Parameters: Destination Options Maintenance (OAM)
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and Hop-by-Hop Options</title>
            <author>
              <organization>Internet Assigned Numbers Authority (IANA)</organization>
            </author>
            <date/>
          </front>
          <seriesInfo name="Web" value="https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2"/>
        </reference>
        <reference anchor="I-D.wkumari-intarea-safe-limited-domains">
          <front>
            <title>Safe(r) Limited Domains</title>
            <author fullname="Warren Kumari" initials="W." surname="Kumari">
              <organization>Google, LLC</organization>
            </author>
            <author fullname="Andrew Alston" initials="A." surname="Alston">
              <organization>Alston Networks</organization>
            </author>
            <author fullname="Eric Vyncke" initials="E." surname="Vyncke">
              <organization>Cisco</organization>
            </author>
            <author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
              <organization>Cisco</organization>
            </author>
            <author fullname="Donald E. Eastlake 3rd" initials="D. E." surname="Eastlake">
              <organization>Independent</organization>
            </author>
            <date day="3" month="March" year="2025"/>
            <abstract>
              <t>   Documents describing protocols that let us know if any changes are only intended to be used
   within "limited domains" often do not clearly define how the boundary needed.  Updates of the limited domain this nature typically
result in more precise language, which is implemented and enforced, or require that
   operators of these limited domains perfectly filter at all of the
   boundary nodes of the domain to protect the rest of the global
   Internet from these protocols and vice-versa.

   This document discusses some design principles and offers mechanisms
   to allow protocols helpful for readers.

Note that are designed to operate in a limited domain
   "fail-closed" rather than "fail-open", thereby making these protocols
   safer to deploy on the Internet.

   These mechanism are our script did not applicable to all protocols intended for use flag any words in a limited domain, particular, but if implemented on certain classes of
   protocols, they can significantly reduce the risks.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-wkumari-intarea-safe-limited-domains-04"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA8Vb627bSJb+L0DvUJv+0UlgMZbtcRxhMIkiyx3P+KK1nfQ0
Go1FiSxJFVMkl0VaUQd5l32WfbL9zqkqXiTZHew0MGkgoYp1OffznVPsXq/X
7YRppJP5QJTFrHfS+Gl60oRadzvdTqGLWA3E3UKJ88nDsfg0uRK3Kn/QoRKn
yhQ6kYVOE3Gd0T/djpxOc/UwELcPYcATAnoVdDtRGiZyia2iXM6KnlY483gp
k95DlvQiTOylWdHr90GGLNQ8zdcDob5k3Y4pp0ttDHYv1hnWn4/vzogyU8gk
+i8ZpwkG18p0O5keiF+LNNwT+CtdZjIs+FEnkUrwaNK8yNXM4Gm9tA9u2m+0
oc7ygSjy0hQH+/tv9g/ATK4kDkwKlSeq6HZWEA7R3O3crwYsj70dQtgjIdGG
siwWaT7odoTo0V9C6MQMxE0g3qeJDqUds1K5wfLmaKgLCOADDo5IrDSUqzl2
H4hPOp/rRLuJaQ6i/l4mOlO5uFLFKs3vjdsjLZOC5PjxdmhH1FLqeCDyKZ/0
7rNdFjBzm2T+MxAXukniP2Ec1ZCl773SnzHaoGQ0vrka34mRIqG9ujN4uyil
+JjoB5UbLNogbbSA8FrEfcGSdyFLPFBRGYTJNm3DQJzJPFdxk75hlGuZtF4w
SddxJE7TuRiliSnjoqK3Fs8/WgRI3uddGkdROg/CNCjvtyn4JRD/kEtdqCYF
v5SfdWvYSumwd9Tri9uFnsoyl21lXpLtpL37skHw1R0EmC6XJSmJLMrgZ56l
ubQ+1iL+7zKTSYv+dXDPJLxLigLkLzdJvwiwKNYt2V2Uct0ctYTf6HAh88hs
WuCd+iJNg+BPKte/b1G2aXUxzgg+0xnv4LPBg11kKaT/kjRfgsMHRR5zczY6
7h+/8Y+vD47c4wmcc8Dumsw2FvTf9E/c48HR60P/+PrYrz08OfGPR/03fsLR
4f5B/ViPVsuOXh/360c/9y9HR/uevIMjP+H4uKL09dGhn3uy//q1f3xzcuwe
3xxZBj8dX97+NLCycvH2mQ86YpKnFM1iEjIFQXEsnlPkeSEmMofuMA063Y5C
RiA8ig9p1puue/jHDz+z5zRiE/3pWUVWpw4RcOeJisRVuZziBDHk+bAKnD68
Gr6wCyOE6oGYydg4gzdQqjKkmmrrn9V0IBZFkZnBq1er1SqAc8kAx72SfMgS
ocK80tnDcS+rONr8HXxZFMv4h43R3gEZQq/XE3JqihyBnH7fLbQRSDcl7SyQ
WsJcTxXJgxIKCORxnYjVAvbNGc24jFbZFMSITVSClAghYG5rsYxtMtyWesCZ
8ntm0v6hjGNsX2BJM6+6rYiX60SJrITvGyXSGWYSVQ0mDPIbWFxCseC/UJgh
i0c2xHGJmCpMz+J07dgSWZ5GZcjvE5s9AiGGSYo98uroJ84xKizZLpZKmjKH
nL3E+YCipQwkVGHK2UyHmn5iTxxfqBBviGCcfAYpxfF6b2MhaQKxc47tc5Dv
4qIVSVPegTeIpY6iWNGvH8iqKyZp5CeVYHoIBwrvYet3ZZKomJLb168udHz7
JkBFuoLRiDwtYWvEC6KWlxGRDppkhoxC4oAc7WbWVM4nYqFkhGXkhEbhL83s
NreTTsiV2Ml0chUq/UDEuIk5hP4AtolPO9LeHAa7ohhtJ+R6TgKsqcGZujAi
XSXNcyDamQx1rAsQDztMIQGI54H0OMU0parpxqraLEh3ZC76gRmOIujaVFKj
2Aup8TPFVjxnMdlbabUOXv0xMIzpGltFOifNQ/L3gfVbxeAOLM90wn6hmbZQ
ZVaw4ow8n+V/luYEhIoSzE4cTR79iOewpRdOm4j+374F4hxkxCYVjBohL/27
c7xZSoomPshjYIuLJI3TOaIYZ5mXEPetCvklb0g5BBvSmwu5hhIO+d3zi8P6
UModbs4mjRfD2i1B5sWtX4Ic8+2bfzxonXDgTjioT6A04+aMyYgoZvOkcT2H
8o+bMzGqjMAluSe/o4Tk3t3eID7ZQaQmvylt9kpcfbo+tO8oV/G7bqcSCJST
r7MinecyQyglv639OY6BpSW5upjl6VKEwNXpEtzAGbJUW+/fGgzEEAudW1v3
2FSLID+HJ0N/cgrXcKbZ1iXhFqQDuDnibuhVOUTUTeZkt5RWHzT50DiaQxOT
8QvvcA23NjWByHTS2mDB4cK5oHXa1hBmhXGJILgrqwSV8luphuoTPSPmJFk2
OTRxcd6Y814iDj8/O3//AhQCXyEacVJy7Iwd+YGwrBJZFa/+JUciGykaXEY+
WkAh/Gpzy3rHzVcuXKlH93xqrVEyDxdYSwEKjFEoY5aYPY464J1nFMwNkCJJ
ZadYz2cUYRE3wB9sY49+NUNnW0VbgbOtZw7UIz9kLWQEC4kUHbwnpBFUbdFC
opsJ9iREKU6kaEe0YBtmgciuZjJtkTZhdXpDVv9O8OKiAAA2Rcw/F8jQbiaN
S17xBEJIZzOCm21vniJhz2AlhCk5JDfEnKv/LhHXKE/M9LzMHTBIUIk6fZnA
rbES2emXlhDX41BfCpUw1m44OZJSmlu72jpbJmv8Tnq82q5BElLBPNgTlxzj
KdahLl3vNF5Hnikz1HjwhSXtx/GVfFxQko13uuVL8fNCPTFlx5aPMUCowuV0
tm1CY9uijl3YQZyXOQIrfD0nyQNfxZzvVWBruX8Pbv3zYOvXr34CgIxn4Pth
7L+IYqlVZUlNMcST4H/amJJSkpMGAgiiW66iwKLcUZo82MxoS79TQlGaf3sH
vFdrAUkh6jy7/Hh792zP/iuurvn5ZvyfH89vxqf0fPtheHFRPXTcjNsP1x8v
TuuneuXo+vJyfHVqF2NUtIY6zy6Hv+AN0fXsenJ3fn01vHi2uz6ANKfkH7Df
LFeUSqTptJTzfjT53//pH0FJ/0EIr99/w8iTfpz0XwMXITiqxJ6WJrBZ+xMy
XndkliHtsAkBaCBfAQLHhkO6WRBKJk8POp2Xv5JkfhuIv07DrH/0NzdADLcG
vcxagyyz7ZGtxVaIO4Z2HFNJszW+Iek2vcNfWr+93BuDf30L9K1Er3/y9m8d
a0Z3u33w6w8pP3zztrRjjjY2kOxOEz4fyTBMLbyBpvMyZtezgF+3UxAdNdxw
TKOszx8FB+Q3jenwvceOpggldUJpJVdILFrFkRn4t3frDHEdP8QpJf8Lbzru
NQ0iuSePRScMG78nG3Bp2GZd/rLYUwjxsnneQJz0pojERsVgKEWK2ZU4XaVG
Wwu2vikFLg44VIkcvznomWKNwD+uQ+vz/S9/GVMFwF0lSuTYFbUR4hOWg6Cg
pqZiWPQcPWXi+j7kf3NKffR6XiwqTO5a3Drx/Z3pGkB5D9GLUC+rdaGarDZl
6faywsLexJ/fZyebR0FbdkxwTxweCFBrNqTWhMscPdu42uMvYZVWZ0uLder3
ETWXADWxDCFhAxOvNOKGw447YaOHHdZ8fWreYTjwT9EIRzt7eBZMdDuWneVS
RRppjOssIO/IAkMkeZX3Yq4VPWJB3vbxqnkIMjenyG5nG+QQgJUe0ecOSz9i
9E/vxSCjOh47pvMEBXfDgAIbRFzh4ZWOLAq4ZjaDhM3XBXXuvRki4YuFnsP1
CiBCTAXBU250zLbs77kh+7++G1v7f2FLJBoYcBthA5zsbW2gjTfHH/f7+338
2f8RLAYq2Ot2yN2sATl6epYaopApYrBgl+/3IbiI0z77icUi3Y6DYcQ2n2rb
Iw1zSBA57fwGGNuWarfjEI8tLpq1ha1TFxqjbTrJ62sG9wU11tskNl0P4IMO
h66WaUSeBZrj1Dl9JuHbrn1EJusP/xHbA/eENhSQTBq8+bbXEgGajoSGasoM
38FV0reip0dHo2Xeudhj0Z90yJeboIcbD/JB6lhOY+VRP91rGPJ8qkAbNU9V
vVBibNTlE0K6fJ9ELQTZwliNorvVSdiuMr+vm8C+4RJYlV4bZexTcUM8Hja2
yLEhg0IStclcD4OdPFZzoE8U31N/CpxsZ6Fk6j5eg0qffV0Txt9j9CxC3U77
VTiAV+BgaPuYS5E7104axRLyfXQ5TT2DFYkLCX9/et5EruNURj4vPTn3CtyK
D5alJyfSZcuFXsKvnpx2a11i6Iqux8Vxo6A1Q7ckpH8GxjOJlS6NbXV5HGzw
1ZxDlJBnuEBRlLRj67zUkUxCjr3UEKuPpzs3R2rTwv5lerc7Vn8uuQ0D3OUZ
48pmP+w0z+9SszVRBy/WNvj5ezqXgdrOxXYR5XS6w1tPWIYntTXpVzfnN0rU
yVNJq4UYfeRQX5BbuHzfmc/lBgh3YH+79m2HiTouPRImbD2+Qw910cq9g6ci
KgEzV/RmaWbbizWoFu/XZGa2UE4BPUq+lJB8g04B8oIqnPPKCp+PLs5fBO3l
voURq2o9iXNC+QzbZKVNBWIcK4uxJ6PxC49bWzf19XUtzZm4TjxdFZMsbcvQ
XVPU65uNq3r91fhudH115hv+B0d9Z94NusmDiFpvfPz+ZmOwDtP+Lsd2heqG
19Mf9TCCmap1mlhEYUIIe4dhuMu24dVwpyJbfU2PYpby3iYZXkY4CMd747j1
PZr2dqhFq+aMxdhEP3Uhq6b/7/aOqd1FrFo+WRrrcO39nVuCEBmdQFxxC8cD
HZ18praOv8ng+zQHiYN6tWby2iv50s+va2xfr+bqQFHLsw6GdN9lTVnZK0Yg
klBZSW/QH1i8bouN9gmkY0X3bSXCgF5iP5Mm9prSTXcUO3owmSH7ihewnxmj
CSDNUgci3DrQZMopyoNim5xmk7Q6k+xniVAoHGz0O1uoUyuHLvX5Hqmu9205
EHFzjmlAWnng7mFz93bE/wNL3ugkOhMQ1zYzzeN0Sn3u6nuvlxRqa7uIKanD
sqKUwCqt5fbr9xxMxu/bl+nO0/aa1xTMrrsuNZtZfuuaxuOlR2/jrDdQ6HcK
r+Rex9FKhPSlB+U1F9BcKnw+/FBdbu4ffPu2uWpcYV3SZuW5HmA9H98iGLq9
/DaHLqD9v6TI6LmtkT3u6SXskq7Nq+juBky3J1qJ0RNnr2FIVWeViy5QCxgw
PLowL7hHQf0d/EIZw+t8dWWLGx9TQaiZbYYc2DGFI1mLebSB5JscV6Xxzpm7
QBgfnT+Ct9o+3paAq2pIfRjWc9c0oWtWTTF465LVByUQNEP11MPvhGpAdmQq
MoxtsPorBWoKUIdbFxs3M/QdhS2QKbxR6905t5Vmt1PnX5nBfmW4eOq+KEo5
ssRK3lMMtI5a8Uidr69f3573ToPVfbmUue6RznMle0bOVM8JpWcXGORovoNk
FZf8zSltWDOMcpRuDul3GKfUqCAR2HxFrYRZmTPgad4sOXevwiV/0JAndAVg
b0ohiPOJ83zbuqf51BUAmAKThHJ3KmlPZODb0N7KoYR+dUtPCfSUnYXltBta
7W7iIr4yb9O1Nagq0BBtdY+GX0PPdRvtnFsJpI+NWa5T5H2z6hhEKqZe05pb
B92O//RkI+DRsfUpRPuHdIVUkNM9yVLVX6rs9Exfyj5WERBwYXRi29eUXCLb
SuW7Iy9BPve9CmVp1GNdMbwyW5etdeOBPYRcQ/N3Rdrck3UBocXaorOVpkYr
S6regrqct5kK9cwG9T3bM6rD/1KuvbwrzvmTC/+BUePijSXCZPImRi5Vg0CL
4awWaRFnDlrC9yNMHUXYBm12kL/a8XDT7NEn3Lm9fQO8SzwS8xB90/ProG0v
FXUm7Ue6mzfXDERp61lJyc3HFXcD9phuduSRP9JTt+PkWXUcwUvqurYu2cLW
qIXEBo7SSZYxxDfeGfNY4VWPj7nn7tPmIY0MQN47blJ3o+jbZXbcCUlpU1pV
ZGyIyywYz2XlFAa2aHOb2/1Yf+7TtjU1iR0hvKZ5PdlC+uNdO7nTZJWaNmHG
SzGezajuaIrCOhilvJfiZ2kaDkeOmyt3SFp9JtdbIYy9rRewS8GdEmU3NOsk
XOQpd0ZbWmBMoCidcDc1zR0+tqY3VQ17ovaiyhT/bwPx2h12qiMXsyoK/fU5
fSS94qufDOiLydvJLOcAZbebIEtTjqBmhub/CcGOYxl/iqcSkiJkz3GiEf/Z
4wic2Pmj1BR/MO2luETOkIk2S3s5RRfWrpL2H7FwRwrxhfFCzSJ/AkCIgp13
Sl8MrmtxrNPSzeV2t64nxsyULZet9N+2l1ljVMz9xv7kF9hgabwYG/Lgzyn9
zXu4JmKvh5dAK44/U58yOb/6iW677xsn390MR+Ob64934803P9O3cdDj/daS
0eT04+XED5NjDsP7JF3FhC05CNpsKpN7br7/lNJ3HmdS54syNwidQxSN1IM4
I7+Q/AkARsexTqkXJG0b95KOvl2S0mzNpTR9XfWg1cpyzS0KPS2tKXMN0PTJ
buf/AM67OxbSMwAA this should
still be reviewed as a best practice.
-->

</rfc>