Diff: rfc9837.original.xml

	rfc9837.original.xml	rfc9837.xml

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

	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.2.	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	3) -->	-ietf-6man-vpn-dest-opt-11" number="9837" consensus="true" updates="" obsoletes=
	<?rfc tocompact="yes"?>	"" xml:lang="en" category="exp" submissionType="IETF" tocInclude="true" sortRefs
	<?rfc tocindent="yes"?>	="true" symRefs="true" version="3">
	<?rfc compact="yes"?>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft	<front>
	-ietf-6man-vpn-dest-opt-11" category="exp" submissionType="IETF" tocInclude="tru	<title abbrev="VPN Service Destination Option">The IPv6 VPN Service Destinat
	e" sortRefs="true" symRefs="true" version="3">	ion Option</title>
	<!-- xml2rfc v2v3 conversion 3.28.1 -->	<seriesInfo name="RFC" value="9837"/>
	<front>
	<title abbrev="Svc. Dest. Opt.">The IPv6 VPN Service Destination Option</tit
	le>
	<seriesInfo name="Internet-Draft" value="draft-ietf-6man-vpn-dest-opt-11"/>
	<author initials="R." surname="Bonica" fullname="Ron Bonica">	<author initials="R." surname="Bonica" fullname="Ron Bonica">
	<organization>Juniper Networks</organization>	<organization>Juniper Networks</organization>
	<address>	<address>
	<postal>	<postal>
	<city>Herndon</city>	<city>Herndon</city>
	<region>Virginia</region>	<region>Virginia</region>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>rbonica@juniper.net</email>	<email>rbonica@juniper.net</email>
	</address>	</address>
	</author>	</author>
	<author initials="X." surname="Li" fullname="Xing Li">	<author initials="X." surname="Li" fullname="Xing Li">
	<organization>CERNET Center/Tsinghua University</organization>	<organization>CERNET Center/Tsinghua University</organization>
	<address>	<address>
	<postal>	<postal>
	<city>Beijing</city>	<city>Beijing</city>
	<country>China</country>	<country>China</country>
	</postal>	</postal>
	<email>xing@cernet.edu.cn</email>	<email>xing@cernet.edu.cn</email>
	</address>	</address>
	</author>	</author>
	<author initials="A." surname="Farrel" fullname="Adrian Farrel">	<author initials="A." surname="Farrel" fullname="Adrian Farrel">
	<organization>Old Dog Consulting</organization>	<organization>Old Dog Consulting</organization>
	<address>	<address>
	<postal>	<postal>

	<country>UK</country>	<country>United Kingdom</country>
	</postal>	</postal>
	<email>adrian@olddog.co.uk</email>	<email>adrian@olddog.co.uk</email>
	</address>	</address>
	</author>	</author>
	<author initials="Y." surname="Kamite" fullname="Yuji Kamite">	<author initials="Y." surname="Kamite" fullname="Yuji Kamite">
	<organization>NTT Communications Corporation</organization>	<organization>NTT Communications Corporation</organization>
	<address>	<address>
	<postal>	<postal>

	<city>3-4-1 Shibaura</city>	<street>3-4-1 Shibaura</street>
	<region>Minato-ku</region>	<region>Minato-ku</region>
	<country>Japan</country>	<country>Japan</country>
	</postal>	</postal>
	<email>y.kamite@ntt.com</email>	<email>y.kamite@ntt.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="L." surname="Jalil" fullname="Luay Jalil">	<author initials="L." surname="Jalil" fullname="Luay Jalil">
	<organization>Verizon</organization>	<organization>Verizon</organization>
	<address>	<address>
	<postal>	<postal>
	<city>Richardson</city>	<city>Richardson</city>
	<region>Texas</region>	<region>Texas</region>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>luay.jalil@one.verizon.com</email>	<email>luay.jalil@one.verizon.com</email>
	</address>	</address>
	</author>	</author>

	<date year="2025" month="May" day="14"/>	<date year="2025" month="August"/>
	<area>Internet</area>	<area>INT</area>
	<workgroup>6man</workgroup>	<workgroup>6man</workgroup>

	<keyword>IPv6, Destination Option, VPN</keyword>	<keyword>IPv6</keyword>
		<keyword>Destination Option</keyword>
		<keyword>VPN</keyword>
	<abstract>	<abstract>

	<?line 93?>

	<t>This document describes an experiment in which VPN service information is enc oded in an experimental IPv6 Destination Option. The experimental IPv6 Destinati on Option is called the VPN Service Option.</t>	<t>This document describes an experiment in which VPN service information is enc oded in an experimental IPv6 Destination Option. The experimental IPv6 Destinati on Option is called the VPN Service Option.</t>
	<t>One purpose of this experiment is to demonstrate that the VPN Service O ption can be deployed in a production network. Another purpose is to demonstrat e that the security measures described in this document are sufficient to protec t a VPN. Finally, this document encourages replication of the experiment.</t>	<t>One purpose of this experiment is to demonstrate that the VPN Service O ption can be deployed in a production network. Another purpose is to demonstrat e that the security measures described in this document are sufficient to protec t a VPN. Finally, this document encourages replication of the experiment.</t>
	</abstract>	</abstract>
	</front>	</front>
	<middle>	<middle>

	<?line 99?>

	<section anchor="introduction">	<section anchor="introduction">
	<name>Introduction</name>	<name>Introduction</name>
	<t>Generic Packet Tunneling <xref target="RFC2473"/> allows a router in on e network to encapsulate a packet in an IP header and send it to a router in ano ther network. The receiving router removes the outer IP header and forwards the original packet into its own network. This facilitates connectivity between netw orks that share a private addressing <xref target="RFC1918"/> <xref target="RFC4 193"/> plan but are not connected by a direct link.</t>	<t>Generic Packet Tunneling <xref target="RFC2473"/> allows a router in on e network to encapsulate a packet in an IP header and send it to a router in ano ther network. The receiving router removes the outer IP header and forwards the original packet into its own network. This facilitates connectivity between netw orks that share a private addressing <xref target="RFC1918"/> <xref target="RFC4 193"/> plan but are not connected by a direct link.</t>

	<t>The IETF refined this concept in a Framework For Virtual Private Networ ks (VPN) <xref target="RFC2764"/>. It also standardized the following VPN techno logies:</t>	<t>The IETF refined this concept in the Framework for VPN <xref target="RF C2764"/>. The IETF also standardized the following VPN technologies:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>

	<t>IPSec VPN <xref target="RFC3884"/>.</t>	<t>IPsec VPN <xref target="RFC3884"/></t>
	</li>	</li>
	<li>	<li>

	<t>Layer 3 VPN (L3VPN) <xref target="RFC4364"/>.</t>	<t>Layer 3 VPN (L3VPN) <xref target="RFC4364"/></t>
	</li>	</li>
	<li>	<li>

	<t>Virtual Private LAN Service (VPLS) <xref target="RFC4761"/><xref ta rget="RFC4762"/>.</t>	<t>Virtual Private LAN Service (VPLS) <xref target="RFC4761"/><xref ta rget="RFC4762"/></t>
	</li>	</li>
	<li>	<li>

	<t>Layer 2 VPN (L2VPN) <xref target="RFC6624"/>.</t>	<t>Layer 2 VPN (L2VPN) <xref target="RFC6624"/></t>
	</li>	</li>
	<li>	<li>

	<t>Ethernet VPN (EVPN) <xref target="RFC7432"/>.</t>	<t>Ethernet VPN (EVPN) <xref target="RFC7432"/></t>
	</li>	</li>
	<li>	<li>

	<t>Pseudowires <xref target="RFC8077"/>.</t>	<t>Pseudowires <xref target="RFC8077"/></t>
	</li>	</li>
	<li>	<li>

	<t>SRv6 <xref target="RFC8986"/>.</t>	<t>Segment Routing over IPv6 (SRv6) <xref target="RFC8986"/></t>
	</li>	</li>
	<li>	<li>

	<t>EVPN / NVO3 <xref target="RFC9469"/>.</t>	<t>EVPN / Network Virtualization over Layer 3 (NVO3) <xref target="RF C9469"/></t>
	</li>	</li>
	</ul>	</ul>

	<t>IPSec VPNs cryptographically protect all traffic from customer endpoint to customer endpoint. All of the other VPN technologies mentioned above share t he following characteristics:</t>	<t>IPsec VPNs cryptographically protect all traffic from customer endpoint to customer endpoint. All of the other VPN technologies mentioned above share t he following characteristics:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>An ingress Provider Edge (PE) router encapsulates customer data in a tunnel header. The tunnel header includes service information. Service informa tion identifies a Forwarding Information Base (FIB) entry on an egress PE router .</t>	<t>An ingress Provider Edge (PE) router encapsulates customer data in a tunnel header. The tunnel header includes service information. Service informa tion identifies a Forwarding Information Base (FIB) entry on an egress PE router .</t>
	</li>	</li>
	<li>	<li>
	<t>The ingress PE router sends the encapsulated packet to the egress P E router.</t>	<t>The ingress PE router sends the encapsulated packet to the egress P E router.</t>
	</li>	</li>
	<li>	<li>
	<t>The egress PE router receives the encapsulated packet.</t>	<t>The egress PE router receives the encapsulated packet.</t>
	</li>	</li>

	skipping to change at line 136 ¶	skipping to change at line 131 ¶
	<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>	<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>	</li>
	</ul>	</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>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>	<t>The solution described in this document offers the following benefits:< /t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>It does not require configuration on CE devices.</t>	<t>It does not require configuration on CE devices.</t>
	</li>	</li>
	<li>	<li>

	<t>It encodes service information in the IPv6 extension header. Theref ore, it does not require any non-IPv6 headers (e.g., MPLS) to carry service info rmation.</t>	<t>It encodes service information in the IPv6 extension header. Theref ore, it does not require any non-IPv6 headers (e.g., MPLS headers) to carry serv ice information.</t>
	</li>	</li>
	<li>	<li>
	<t>It supports many VPNs on a single egress PE router.</t>	<t>It supports many VPNs on a single egress PE router.</t>
	</li>	</li>
	<li>	<li>
	<t>When a single egress PE router supports many VPNs, it does not requ ire an IP address per VPN.</t>	<t>When a single egress PE router supports many VPNs, it does not requ ire an IP address per VPN.</t>
	</li>	</li>
	<li>	<li>
	<t>It does not rely on any particular control plane.</t>	<t>It does not rely on any particular control plane.</t>
	</li>	</li>
	</ul>	</ul>
	<t>One purpose of this experiment is to demonstrate that the VPN Service O ption can be deployed in a production network. Another purpose is to demonstrate that the security measures described in <xref target="security"/> of this docum ent are sufficient to protect a VPN. Finally, this document encourages replicati on of the experiment, so that operational issues can be discovered.</t>	<t>One purpose of this experiment is to demonstrate that the VPN Service O ption can be deployed in a production network. Another purpose is to demonstrate that the security measures described in <xref target="security"/> of this docum ent are sufficient to protect a VPN. Finally, this document encourages replicati on of the experiment, so that operational issues can be discovered.</t>
	</section>	</section>
	<section anchor="conventions-and-definitions">	<section anchor="conventions-and-definitions">
	<name>Conventions and Definitions</name>	<name>Conventions and Definitions</name>

	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14	<t>
	>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",	",
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i	"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	nterpreted as	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	described in BCP14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and o	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	nly when, they	be
	appear in all capitals, as shown here.</t>	interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
	<?line -18?>	target="RFC8174"/> when, and only when, they appear in all capitals, as
		shown here.
		</t>


	</section>	</section>
	<section anchor="option">	<section anchor="option">
	<name>The VPN Service Option</name>	<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>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 IPv6 Destinat ion Option contains three fields: Option Type, Opt Data Len, and Option Data. In the VPN Service Option these fields are used as follows:</t>	<t>As described in <xref target="RFC8200" section="4.2"/>, an IPv6 Destina tion Option contains three fields: Option Type, Opt Data Len, and Option Data. I n the VPN Service Option, these fields are used as follows:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>

	<t>Option Type: 8-bit selector. VPN Service Option. This field <bcp14 >MUST</bcp14> be set to RFC3692-style Experiment (0x5E) <xref target="V6MSG"/>. See Note below.</t>	<t>Option Type: 8-bit selector. VPN Service Option. This field <bcp14 >MUST</bcp14> be set to 0x5E (RFC3692-style Experiment) <xref target="V6MSG"/>. See NOTE below.</t>
	</li>	</li>
	<li>	<li>

	<t>Opt Data Len - 8-bit unsigned integer. Length of the option, in	<t>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 <bcp14>MUST</bcp14> be set to 4.</t>	field <bcp14>MUST</bcp14> be set to 4.</t>
	</li>	</li>
	<li>	<li>

	<t>Option Data - 32 bits. VPN Service Information that identifies a F IB entry on the egress PE. The FIB entry determines how the egress PE will forwa rd customer data to a CE device.</t>	<t>Option Data: 32 bits. VPN service information that identifies a FI B entry on the egress PE. The FIB entry determines how the egress PE will forwar d customer data to a CE device.</t>
	</li>	</li>
	</ul>	</ul>
	<t>A single VPN Service Option <bcp14>MAY</bcp14> appear in a Destination Options header	<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> appe ar in any other	that immediately precedes an upper-layer header. It <bcp14>MUST NOT</bcp14> appe ar in any other
	extension header. If a receiver finds the VPN Service Option 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.	extension header, it <bcp14>MUST NOT</bcp14> recognize the option.

	The packet <bcp14>MUST</bcp14> be processed according to the setting of the two	The packet <bcp14>MUST</bcp14> be processed according to the setting of th
	highest	e two highest-order bits of the Option Type (see NOTE below).</t>
	order bits of the Option Type (see NOTE below).</t>
	<t>NOTE: For this experiment, the Option Type is set to '01011110', i.e.,	<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	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	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	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	indicating that Option Data cannot be modified along the path between
	the packet's source and its destination. The remaining low-order bits	the packet's source and its destination. The remaining low-order bits
	are set to '11110' to indicate the single IPv6 Destination Option Type	are set to '11110' to indicate the single IPv6 Destination Option Type

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

	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>

	<t>Version - Defined in <xref target="RFC8200"/>. <bcp14>MUST</bcp14> be equal to 6.</t>	<t>Version - <bcp14>MUST</bcp14> be equal to 6.</t>
	</li>	</li>
	<li>	<li>

	<t>Traffic Class - Defined in <xref target="RFC8200"/>.</t>	<t>Traffic Class</t>
	</li>	</li>
	<li>	<li>

	<t>Flow Label - Defined in <xref target="RFC8200"/>.</t>	<t>Flow Label
		</t>
	</li>	</li>
	<li>	<li>

	<t>Payload Length - Defined in <xref target="RFC8200"/>.</t>	<t>Payload Length
		</t>
	</li>	</li>
	<li>	<li>

	<t>Next Header - Defined in <xref target="RFC8200"/>.</t>	<t>Next Header
		</t>
	</li>	</li>
	<li>	<li>

	<t>Hop Limit - Defined in <xref target="RFC8200"/>.</t>	<t>Hop Limit
		</t>
	</li>	</li>
	<li>	<li>

	<t>Source Address - Defined in <xref target="RFC8200"/>. Represents an interface on the ingress PE router. This address <bcp14>SHOULD</bcp14> be chose n according to guidance provided in <xref target="RFC6724"/>.</t>	<t>Source Address - 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>
	<li>	<li>

	<t>Destination Address - Defined in <xref target="RFC8200"/>. Represen ts an interface on the egress PE router. This address <bcp14>SHOULD</bcp14> be c hosen according to guidance provided in <xref target="RFC6724"/>.</t>	<t>Destination Address - Represents an interface on the egress PE rout er. This address <bcp14>SHOULD</bcp14> be chosen according to guidance provided in <xref target="RFC6724"/>.</t>
	</li>	</li>
	</ul>	</ul>

	<t>The IPv6 Destination Options Extension Header contains:</t>	<t>The IPv6 Destination Options Extension Header contains the following (a ll defined in <xref target="RFC8200"/>):</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>

	<t>Next Header - Defined in <xref target="RFC8200"/>. <bcp14>MUST</bcp 14> identify the protocol of the customer data.</t>	<t>Next Header - <bcp14>MUST</bcp14> identify the protocol of the cust omer data.</t>
	</li>	</li>
	<li>	<li>

	<t>Hdr Ext Len - Defined in <xref target="RFC8200"/>.</t>	<t>Hdr Ext Len
		</t>
	</li>	</li>
	<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>	<t>Options - 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 othe r Destination Options.</t>
	</li>	</li>
	</ul>	</ul>
	</section>	</section>
	<section anchor="control-plane-considerations">	<section anchor="control-plane-considerations">
	<name>Control Plane Considerations</name>	<name>Control Plane Considerations</name>

	<t>The FIB can be populated:</t>	<t>The FIB can be populated by:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>

	<t>By an operator, using a Command Line Interface (CLI).</t>	<t>An operator, using a Command-Line Interface (CLI)</t>
	</li>	</li>
	<li>	<li>

	<t>By a controller, using the Path Computation Element (PCE)	<t>A controller, using the Path Computation Element
	Communication Protocol (PCEP) <xref target="RFC5440"/> or the Network	Communication Protocol (PCEP) <xref target="RFC5440"/> or the Network

	Configuration Protocol (NETCONF) <xref target="RFC6241"/>.</t>	Configuration Protocol (NETCONF) <xref target="RFC6241"/></t>
	</li>	</li>
	<li>	<li>

	<t>By a routing protocol.</t>	<t>A routing protocol</t>
	</li>	</li>
	</ul>	</ul>

	<t>Routing protocol extensions that support the IPv6 VPN Service Destinati on Option are beyond the scope of this document.</t>	<t>Routing protocol extensions that support the VPN Service Option are bey ond the scope of this document.</t>
	</section>	</section>
	<section anchor="iana-considerations">	<section anchor="iana-considerations">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>

	<t>This document does not make any IANA requests.</t>	<t>This document has no IANA actions.</t>
	</section>	</section>
	<section anchor="security">	<section anchor="security">
	<name>Security Considerations</name>	<name>Security Considerations</name>
	<t>A VPN is characterized by the following security policy:</t>	<t>A VPN is characterized by the following security policy:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>Nodes outside of a VPN cannot inject traffic into the VPN.</t>	<t>Nodes outside of a VPN cannot inject traffic into the VPN.</t>
	</li>	</li>
	<li>	<li>
	<t>Nodes inside a VPN cannot send traffic outside of the VPN.</t>	<t>Nodes inside a VPN cannot send traffic outside of the VPN.</t>
	</li>	</li>
	</ul>	</ul>
	<t>A set of PE routers cooperate to enforce this security policy. If a dev ice outside of that set could impersonate a device inside of the set, it would b e possible for that device to subvert security policy. Therefore, impersonation must not be possible. The following paragraphs describe procedures that prevent impersonation.</t>	<t>A set of PE routers cooperate to enforce this security policy. If a dev ice outside of that set could impersonate a device inside of the set, it would b e 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>	<t>The VPN Service Option can be deployed:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>On the global Internet</t>	<t>On the global Internet</t>
	</li>	</li>
	<li>	<li>
	<t>Inside of a limited domain</t>	<t>Inside of a limited domain</t>
	</li>	</li>
	</ul>	</ul>

	<t>When IPv6 VPN Service Destination Option is deployed on the global Inte rnet, the tunnel that connects the ingress PE to the egress PE <bcp14>MUST</bcp1 4> be cryptographically protected by one of the following:</t>	<t>When the VPN Service Option is deployed on the global Internet, the tun nel that connects the ingress PE to the egress PE <bcp14>MUST</bcp14> be cryptog raphically protected by one of the following:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>The IPv6 Authentication Header (AH) <xref target="RFC4302"/></t>	<t>The IPv6 Authentication Header (AH) <xref target="RFC4302"/></t>
	</li>	</li>
	<li>	<li>

	<t>The IPv6 Encapsulating Security Payload (ESP) Header <xref target=" RFC4303"/>.</t>	<t>The IPv6 Encapsulating Security Payload (ESP) Header <xref target=" RFC4303"/></t>
	</li>	</li>
	</ul>	</ul>

	<t>When IPv6 VPN Service Destination Option is deployed in a limited domai n, all nodes at the edge of limited domain <bcp14>MUST</bcp14> maintain Access C ontrol Lists (ACLs). These ACL's <bcp14>MUST</bcp14> discard packets that satis fy the following criteria:</t>	<t>When the VPN Service Option is deployed in a limited domain, all nodes at the edge of limited domain <bcp14>MUST</bcp14> maintain Access Control Lists (ACLs). These ACLs <bcp14>MUST</bcp14> discard packets that satisfy the followi ng criteria:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>

	<t>Contain an IPv6 VPN Service option.</t>	<t>Contain a VPN Service Option</t>
	</li>	</li>
	<li>	<li>

	<t>Contain an IPv6 Destination Address that represents an interface in side of the limited domain.</t>	<t>Contain an IPv6 Destination Address that represents an interface in side of the limited domain</t>
	</li>	</li>
	</ul>	</ul>
	<t>The mitigation techniques mentioned above operate in fail-open mode. Th at is, they require	<t>The mitigation techniques mentioned above operate in fail-open mode. Th at is, they require
	explicit configuration in order to ensure that packets	explicit configuration in order to ensure that packets
	using the approach described in this document do not leak out of a domain.	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 o f fail-open	See <xref target="I-D.wkumari-intarea-safe-limited-domains"/> for a discussion o f fail-open
	and fail-closed modes.</t>	and fail-closed modes.</t>
	<t>For further information on the security concerns related to IP tunnels and the	<t>For further information on the security concerns related to IP tunnels and the
	recommended mitigation techniques, please see <xref target="RFC6169"/>.</t>	recommended mitigation techniques, please see <xref target="RFC6169"/>.</t>
	</section>	</section>

	skipping to change at line 315 ¶	skipping to change at line 320 ¶
	<name>Deployment Considerations</name>	<name>Deployment Considerations</name>
	<t>The VPN Service Option is imposed by an ingress PE and processed by an	<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	egress PE. It is not processed by any other nodes along the delivery path
	between the ingress PE and egress PE.</t>	between the ingress PE and egress PE.</t>
	<t>However, some networks discard packets that include IPv6 Destination Op tions.	<t>However, some networks discard packets that include IPv6 Destination Op tions.
	This is an impediment to deployment.</t>	This is an impediment to deployment.</t>
	<t>Because the VPN Service Option uses an experimental code point, there	<t>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.</t>	same code point.</t>

	<t>It is expected that, as with all experiments with IETF protocols,	<t>As with all experiments with IETF protocols, it is expected that
	care is taken by the operator to ensure that all nodes participating	care is taken by the operator to ensure that all nodes participating
	in an experiment are carefully configured.</t>	in an experiment are carefully configured.</t>
	<t>Because the VPN Service Destination Option uses an experimental code po int,	<t>Because the VPN Service Destination Option uses an experimental code po int,
	processing of this option <bcp14>MUST</bcp14> be disabled by default. Explicit c onfiguration	processing of this option <bcp14>MUST</bcp14> be disabled by default. Explicit c onfiguration
	is required to enable processing of the option.</t>	is required to enable processing of the option.</t>
	</section>	</section>
	<section anchor="experimental-results">	<section anchor="experimental-results">
	<name>Experimental Results</name>	<name>Experimental Results</name>
	<t>Parties participating in this experiment should publish experimental re sults within one year of the publication of this document. Experimental results should address the following:</t>	<t>Parties participating in this experiment should publish experimental re sults within one year of the publication of this document. Experimental results should address the following:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>Effort required to deploy	<t>Effort required to deploy
	</t>	</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>Was deployment incremental or network-wide?</t>	<t>Was deployment incremental or network-wide?</t>
	</li>	</li>
	<li>	<li>

	<t>Was there a need to synchronize configurations at each node or could nodes be configured independently?</t>	<t>Was there a need to synchronize configurations at each node, or could nodes be configured independently?</t>
	</li>	</li>
	<li>	<li>

	<t>Did the deployment require hardware upgrade?</t>	<t>Did the deployment require a hardware upgrade?</t>
	</li>	</li>
	</ul>	</ul>
	</li>	</li>
	<li>	<li>
	<t>Effort required to secure	<t>Effort required to secure
	</t>	</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>Performance impact</t>	<t>Performance impact</t>
	</li>	</li>

	skipping to change at line 375 ¶	skipping to change at line 380 ¶
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>Did you deploy two interoperable implementations?</t>	<t>Did you deploy two interoperable implementations?</t>
	</li>	</li>
	<li>	<li>
	<t>Did you experience interoperability problems?</t>	<t>Did you experience interoperability problems?</t>
	</li>	</li>
	</ul>	</ul>
	</li>	</li>
	<li>	<li>

	<t>Effectiveness and sufficiency of OAM mechanisms	<t>Effectiveness and sufficiency of Operations, Administration, and Ma intenance (OAM) mechanisms
	</t>	</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>Did PING work?</t>	<t>Did PING work?</t>
	</li>	</li>
	<li>	<li>
	<t>Did TRACEROUTE work?</t>	<t>Did TRACEROUTE work?</t>
	</li>	</li>
	<li>	<li>
	<t>Did Wireshark work?</t>	<t>Did Wireshark work?</t>
	</li>	</li>
	<li>	<li>
	<t>Did TCPDUMP work?</t>	<t>Did TCPDUMP work?</t>
	</li>	</li>
	</ul>	</ul>
	</li>	</li>
	</ul>	</ul>
	</section>	</section>

	<section anchor="acknowledgements">
	<name>Acknowledgements</name>
	<t>Thanks to Gorry Fairhurst, Antoine Fressancourt, Eliot Lear and Mark Sm
	ith for their reviews and contributions to this document.</t>
	</section>
	</middle>	</middle>
	<back>	<back>

		<displayreference target="I-D.wkumari-intarea-safe-limited-domains" to="SAFE-LIM
		-DOMAINS"/>

	<references anchor="sec-combined-references">	<references anchor="sec-combined-references">
	<name>References</name>	<name>References</name>
	<references anchor="sec-normative-references">	<references anchor="sec-normative-references">
	<name>Normative References</name>	<name>Normative References</name>

	<reference anchor="RFC6169">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	<front>	169.xml"/>
	<title>Security Concerns with IP Tunneling</title>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>	724.xml"/>
	<author fullname="D. Thaler" initials="D." surname="Thaler"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<author fullname="J. Hoagland" initials="J." surname="Hoagland"/>	200.xml"/>
	<date month="April" year="2011"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<abstract>	119.xml"/>
	<t>A number of security concerns with IP tunnels are documented in	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	this memo. The intended audience of this document includes network administrato	174.xml"/>
	rs and future protocol developers. The primary intent of this document is to rai
	se 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 (IP
	v6)</title>
	<author fullname="D. Thaler" initials="D." role="editor" surname="Th
	aler"/>
	<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 defa
	ult 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 allo
	wing administrators to provide policy that can override the default behavior. In
	dual-stack implementations, the destination address selection algorithm can con
	sider both IPv4 and IPv6 addresses -- depending on the available source addresse
	s, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa.
	</t>
	<t>Default address selection as defined in this specification appl
	ies 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 (IPv
	6). 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</tit
	le>
	<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 sig
	nify the requirements in the specification. These words are often capitalized. T
	his document defines these words as they should be interpreted in IETF documents
	. This document specifies an Internet Best Current Practices for the Internet Co
	mmunity, 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</ti
	tle>
	<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 protoco
	l 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>
	</references>	</references>
	<references anchor="sec-informative-references">	<references anchor="sec-informative-references">
	<name>Informative References</name>	<name>Informative References</name>

	<reference anchor="RFC1918">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
	<front>	918.xml"/>
	<title>Address Allocation for Private Internets</title>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>	473.xml"/>
	<author fullname="B. Moskowitz" initials="B." surname="Moskowitz"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<author fullname="D. Karrenberg" initials="D." surname="Karrenberg"/	764.xml"/>
	>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	<author fullname="G. J. de Groot" initials="G. J." surname="de Groot	884.xml"/>
	"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	<author fullname="E. Lear" initials="E." surname="Lear"/>	193.xml"/>
	<date month="February" year="1996"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	<abstract>	302.xml"/>
	<t>This document describes address allocation for private internet	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	s. This document specifies an Internet Best Current Practices for the Internet C	303.xml"/>
	ommunity, and requests discussion and suggestions for improvements.</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	</abstract>	364.xml"/>
	</front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	<seriesInfo name="BCP" value="5"/>	761.xml"/>
	<seriesInfo name="RFC" value="1918"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	<seriesInfo name="DOI" value="10.17487/RFC1918"/>	762.xml"/>
	</reference>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	<reference anchor="RFC2473">	440.xml"/>
	<front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	<title>Generic Packet Tunneling in IPv6 Specification</title>	241.xml"/>
	<author fullname="A. Conta" initials="A." surname="Conta"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	<author fullname="S. Deering" initials="S." surname="Deering"/>	624.xml"/>
	<date month="December" year="1998"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	<abstract>	432.xml"/>
	<t>This document defines the model and generic mechanisms for IPv6	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	encapsulation of Internet packets, such as IPv6 and IPv4. [STANDARDS-TRACK]</t>	077.xml"/>
	</abstract>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	</front>	986.xml"/>
	<seriesInfo name="RFC" value="2473"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<seriesInfo name="DOI" value="10.17487/RFC2473"/>	469.xml"/>
	</reference>	<reference anchor="V6MSG" target="https://www.iana.org/assignments/ipv6-
	<reference anchor="RFC2764">	parameters">
	<front>
	<title>A Framework for IP Based Virtual Private Networks</title>
	<author fullname="B. Gleeson" initials="B." surname="Gleeson"/>
	<author fullname="A. Lin" initials="A." surname="Lin"/>
	<author fullname="J. Heinanen" initials="J." surname="Heinanen"/>
	<author fullname="G. Armitage" initials="G." surname="Armitage"/>
	<author fullname="A. Malis" initials="A." surname="Malis"/>
	<date month="February" year="2000"/>
	<abstract>
	<t>This document describes a framework for Virtual Private Network
	s (VPNs) running across IP backbones. This memo provides information for the Int
	ernet community.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="2764"/>
	<seriesInfo name="DOI" value="10.17487/RFC2764"/>
	</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 to protect com
	munication between trusted components, e.g., for a secure virtual network (VN),
	overlay, or virtual private network (VPN). Virtual links established by IPsec tu
	nnel mode can conflict with routing and forwarding inside VNs because IP routing
	depends on references to interfaces and next-hop IP addresses. The IPsec tunnel
	mode specification is ambiguous on this issue, so even compliant implementation
	s cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-I
	Psec IPIP encapsulation together with IPsec transport mode, which we call IIPtra
	n. IPIP encapsulation occurs as a separate initial step, as the result of a forw
	arding lookup of the VN packet. IPsec transport mode processes the resulting (tu
	nneled) 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 the current IPsec architecture. IIPtran demonstrates how to
	configure any compliant IPsec implementation to avoid the aforementioned conflic
	ts. IIPtran is also compared to several alternative mechanisms for VN routing an
	d their respective impact on IPsec, routing, policy enforcement, and interaction
	s with the Internet Key Exchange (IKE). This memo provides information for the I
	nternet community.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="3884"/>
	<seriesInfo name="DOI" value="10.17487/RFC3884"/>
	</reference>
	<reference anchor="RFC4193">
	<front>
	<title>Unique Local 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 IPv6 unicast address format that is gl
	obally unique and is intended for local communications, usually inside of a site
	. These addresses are not expected to be routable on the global Internet. [STAND
	ARDS-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 Authentica
	tion Header (AH), which is designed to provide authentication services in IPv4 a
	nd 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 updated version of the Encapsulating
	Security Payload (ESP) protocol, which is designed to provide a mix of security
	services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin
	authentication, connectionless integrity, an anti-replay service (a form of part
	ial 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 Service Provider ma
	y use an IP backbone to provide IP Virtual Private Networks (VPNs) for its custo
	mers. This method uses a "peer model", in which the customers' edge routers (CE
	routers) send their routes to the Service Provider's edge routers (PE routers);
	there is no "overlay" visible to the customer's routing algorithm, and CE router
	s at different sites do not peer with each other. Data packets are tunneled thro
	ugh the backbone, so that the core routers do not need to know 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-Discove
	ry and Signaling</title>
	<author fullname="K. Kompella" initials="K." role="editor" surname="
	Kompella"/>
	<author fullname="Y. Rekhter" initials="Y." role="editor" surname="R
	ekhter"/>
	<date month="January" year="2007"/>
	<abstract>
	<t>Virtual Private LAN Service (VPLS), also known as Transparent L
	AN Service and Virtual Private Switched Network service, is a useful Service Pro
	vider offering. The service offers a Layer 2 Virtual Private Network (VPN); howe
	ver, in the case of VPLS, the customers in the VPN are connected by a multipoint
	Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point i
	n nature.</t>
	<t>This document describes the functions required to offer VPLS, a
	mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a p
	acket 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 Service (VPLS) Using Label Distribution P
	rotocol (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 Service (VPLS) so
	lution using pseudowires, a service previously implemented over other tunneling
	technologies and known as Transparent LAN Services (TLS). A VPLS creates an emul
	ated 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 addresse
	s and that is closed to a given set of users. Multiple VPLS services can be supp
	orted from a single Provider Edge (PE) node.</t>
	<t>This document describes the control plane functions of signalin
	g pseudowire labels using Label Distribution Protocol (LDP), extending RFC 4447.
	It is agnostic to discovery protocols. The data plane functions of forwarding a
	re also described, focusing 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) Comm
	unication 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 state
	s related to the use of a PCE in the context of Multiprotocol Label Switching (M
	PLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be fl
	exible and extensible so as to easily allow for the addition of further messages
	and objects, should 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" surn
	ame="Schoenwaelder"/>
	<author fullname="A. Bierman" initials="A." role="editor" surname="B
	ierman"/>
	<date month="June" year="2011"/>
	<abstract>
	<t>The Network Configuration Protocol (NETCONF) defined in this do
	cument provides mechanisms to install, manipulate, and delete the configuration
	of network devices. It uses an Extensible Markup Language (XML)-based data encod
	ing for the configuration data as well as the protocol messages. The NETCONF pro
	tocol operations are realized as remote procedure calls (RPCs). This document ob
	soletes 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, incl
	uding Virtual Private LAN Service, have become popular. Traditional L2VPNs often
	required a separate Service Provider infrastructure for each type and yet anoth
	er 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 the L2VPN customer's experience is virtually identical to that offered by
	traditional L2VPNs, but such that a Service Provider can maintain a single netw
	ork for L2VPNs, IP VPNs, and the Internet, as well as a common provisioning meth
	odology for all services. This document is not an Internet Standards Track speci
	fication; 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="S
	ajassi"/>
	<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 for BGP MPLS-based Ethernet
	VPNs (EVPN). The procedures described here meet the requirements specified in RF
	C 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="M
	artini"/>
	<author fullname="G. Heron" initials="G." role="editor" surname="Her
	on"/>
	<date month="February" year="2017"/>
	<abstract>
	<t>Layer 2 services (such as Frame Relay, Asynchronous Transfer Mo
	de, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Lay
	er 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 Mult
	iplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enable
	d network. This document specifies a protocol for establishing and maintaining t
	he pseudowires, using extensions to the Label Distribution Protocol (LDP). Proce
	dures for encapsulating Layer 2 PDUs are specified in other documents.</t>
	<t>This document is a rewrite of RFC 4447 for publication as an In
	ternet 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 Segment Routing over IPv6 (SRv6) Network Programming framew
	ork 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 interopera
	ble 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 N
	etwork Virtualization over Layer 3 (NVO3) Networks</title>
	<author fullname="J. Rabadan" initials="J." role="editor" surname="R
	abadan"/>
	<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 c
	ontrol plane that solves the issues of Network Virtualization Edge (NVE) auto-di
	scovery, tenant Media Access Control (MAC) / IP dissemination, and advanced feat
	ures 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 independ
	ence of the underlay IP Fabric, i.e., there is no need to enable Protocol Indepe
	ndent Multicast (PIM) in the underlay network and maintain multicast states for
	tenant Broadcast Domains. This document describes the use of EVPN for NVO3 netwo
	rks and discusses its applicability to basic Layer 2 and Layer 3 connectivity re
	quirements and to advanced features such as MAC Mobility, MAC Protection and Loo
	p 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>	<front>

	<title>Internet Protocol Version 6 (IPv6) Parameters: Destination Op tions and Hop-by-Hop Options</title>	<title>Destination Options and Hop-by-Hop Options</title>
	<author>	<author>

	<organization>Internet Assigned Numbers Authority (IANA)</organiza tion>	<organization abbrev="IANA">Internet Assigned Numbers Authority</o rganization>
	</author>	</author>
	<date/>	<date/>
	</front>	</front>

	<seriesInfo name="Web" value="https://www.iana.org/assignments/ipv6-pa rameters/ipv6-parameters.xhtml#ipv6-parameters-2"/>
	</reference>	</reference>

	<reference anchor="I-D.wkumari-intarea-safe-limited-domains">	<!-- [I-D.wkumari-intarea-safe-limited-domains]
	<front>	draft-wkumari-intarea-safe-limited-domains-04
	<title>Safe(r) Limited Domains</title>	IESG State: I-D Exists as of 06/25/25
	<author fullname="Warren Kumari" initials="W." surname="Kumari">	Long Way - author initials
	<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 are only intended to be
	used
	within "limited domains" often do not clearly define how the boundary
	of the limited domain 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 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 not applicable to all protocols intended for use
	in a limited domain, but if implemented on certain classes of
	protocols, they can significantly reduce the risks.


	</t>	<reference anchor="I-D.wkumari-intarea-safe-limited-domains" target="https://dat
	</abstract>	atracker.ietf.org/doc/html/draft-wkumari-intarea-safe-limited-domains-04">
	</front>	<front>
	<seriesInfo name="Internet-Draft" value="draft-wkumari-intarea-safe-li	<title>Safe(r) Limited Domains</title>
	mited-domains-04"/>	<author fullname="Warren Kumari" initials="W." surname="Kumari">
	</reference>	<organization>Google, LLC</organization>
		</author>
		<author fullname="Andrew Alston" initials="A." surname="Alston">
		<organization>Alston Networks</organization>
		</author>
		<author fullname="Éric Vyncke" initials="É." 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." surname="Eastlake">
		<organization>Independent</organization>
		</author>
		<date day="3" month="March" year="2025"/>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-wkumari-intarea-safe-limited-doma
		ins-04"/>
		</reference>
	</references>	</references>
	</references>	</references>

	</back>	<section anchor="acknowledgements" numbered="false">
	<!-- ##markdown-source:	<name>Acknowledgements</name>
	H4sIAAAAAAAAA8Vb627bSJb+L0DvUJv+0UlgMZbtcRxhMIkiyx3P+KK1nfQ0	<t>Thanks to <contact fullname="Gorry Fairhurst"/>, <contact fullname="Ant
	Go1FiSxJFVMkl0VaUQd5l32WfbL9zqkqXiTZHew0MGkgoYp1OffznVPsXq/X	oine Fressancourt"/>, <contact fullname="Eliot Lear"/>, and <contact fullname="M
	7YRppJP5QJTFrHfS+Gl60oRadzvdTqGLWA3E3UKJ88nDsfg0uRK3Kn/QoRKn	ark Smith"/> for their reviews and contributions to this document.</t>
	yhQ6kYVOE3Gd0T/djpxOc/UwELcPYcATAnoVdDtRGiZyia2iXM6KnlY483gp	</section>
	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


		</back>

	</rfc>	</rfc>

End of changes. 72 change blocks.
	725 lines changed or deleted	179 lines changed or added
This html diff was produced by rfcdiff 1.48.