rfc9805xml2.original.xml		rfc9805.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
	<?rfc toc="yes"?>
	<?rfc tocompact="yes"?>
	<?rfc tocdepth="3"?>
	<?rfc tocindent="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<rfc category="std"
	docName="draft-ietf-6man-deprecate-router-alert-13"
	ipr="trust200902" updates="2711">
	<front>
	<title abbrev="Deprecate IPv6 Router Alert For New Protocols">
	Deprecation Of The IPv6 Router Alert Option For New Protocols
	</title>
	<author fullname="Ron Bonica" initials="R." surname="Bonica">		<!DOCTYPE rfc [
	<organization>Juniper Networks</organization>		<!ENTITY nbsp "&#160;">
	<address>		<!ENTITY zwsp "&#8203;">
	<postal>		<!ENTITY nbhy "&#8209;">
	<country>USA</country>		<!ENTITY wj "&#8288;">
	</postal>		]>
	<email>rbonica@juniper.net</email>
	</address>
	</author>
	<date day="29" month="April" year="2025"/>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	<area>INT Area</area>		tf-6man-deprecate-router-alert-13" number="9805" consensus="true" ipr="trust2009
	<workgroup>6man</workgroup>		02" updates="2711" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="
	<keyword>IPv6</keyword>		true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
	<abstract>		<front>
	<t>This document deprecates the IPv6 Router Alert Option.		<title abbrev="Deprecate IPv6 Router Alert for New Protocols">Deprecation of
			the IPv6 Router Alert Option for New Protocols</title>
			<seriesInfo name="RFC" value="9805"/>
			<author fullname="Ron Bonica" initials="R." surname="Bonica">
			<organization>Juniper Networks</organization>
			<address>
			<postal>
			<country>United States of America</country>
			</postal>
			<email>rbonica@juniper.net</email>
			</address>
			</author>
			<date month="June" year="2025"/>
			<area>INT</area>
			<workgroup>6man</workgroup>
			<keyword>IPv6</keyword>
			<abstract>
			<t>This document deprecates the IPv6 Router Alert Option.
	Protocols that use the Router Alert Option may continue to do so,		Protocols that use the Router Alert Option may continue to do so,
	even in future versions. However, new protocols that are standardized		even in future versions. However, new protocols that are standardized
	in the future must not use the Router Alert Option.</t>		in the future must not use the Router Alert Option.</t>
			<t>This document updates RFC 2711. </t>
	<t>This document updates RFC 2711. </t>		</abstract>
			</front>
	</abstract>		<middle>
	</front>		<section numbered="true" toc="default">
			<name>Introduction</name>
	<middle>		<t>In IPv6 <xref target="RFC8200" format="default"></xref>, optional inter
	<section title="Introduction">		net-layer
	<t>In <xref target="RFC8200">IPv6</xref>, optional internet-layer
	information is encoded in separate headers that may be placed		information is encoded in separate headers that may be placed
	between the IPv6 header and the upper-layer header in a packet.		between the IPv6 header and the upper-layer header in a packet.
	There is a small number of such extension headers, each one		There is a small number of such extension headers, each one
	identified by a distinct Next Header value.</t>		identified by a distinct Next Header value.</t>
			<t>One of these extension headers is called the Hop-by-Hop Options
	<t>One of these extension headers is called the Hop-by-Hop Options
	header. The Hop-by-Hop Options header is used to carry optional		header. The Hop-by-Hop Options header is used to carry optional
	information that may be examined and processed by every node along		information that may be examined and processed by every node along
	a packet's delivery path.</t>		a packet's delivery path.</t>
			<t>The Hop-by-Hop Options header can carry one or more options.
	<t>The Hop-by-Hop Options header can carry one or more options.		Among these is the Router Alert Option <xref target="RFC2711" format="defa
	Among these is the <xref target="RFC2711">Router Alert Option		ult"></xref>.
	</xref>.</t>		</t>
			<t>The Router Alert Option provides a mechanism whereby
	<t>The Router Alert Option provides a mechanism whereby
	routers can know when to intercept datagrams not addressed to		routers can know when to intercept datagrams not addressed to
	them without having to extensively examine every datagram.		them without having to extensively examine every datagram.
	The semantic of the Router Alert Option is, "routers should		The semantic of the Router Alert Option is that "routers should
	examine this datagram more closely". Excluding this option		examine this datagram more closely". Excluding this option
	tells the router that there is no need to examine this datagram		tells the router that there is no need to examine this datagram
	more closely.</t>		more closely.</t>
			<t>As explained below, the Router Alert Option introduces many issues.</t>
	<t>As explained below, the Router Alert Option introduces many issues.</t>		<t>This document updates <xref target="RFC2711" format="default"/>.
			Implementers of protocols that continue to use the Router Alert
	<t>This document updates <xref target="RFC2711"/>.</t>		Option can continue to reference <xref target="RFC2711" format="default"/>
			for Router
	<t>Implementers of protocols that continue to use the Router
	Option can continue to reference <xref target="RFC2711"/> for Router
	Alert Option details. </t>		Alert Option details. </t>
			</section>
	</section>		<section anchor="ReqLang" numbered="true" toc="default">
			<name>Requirements Language</name>
	<section anchor="ReqLang" title="Requirements Language">		<t>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"MAY", and "OPTIONAL" in this document are to be interpreted as		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	described in <xref target="RFC2119">BCP 14</xref>		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	<xref target="RFC8174"/> when, and only when, they appear in all		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	capitals, as shown here.</t>		be interpreted as
	</section>		described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
	<section title= "Issues Associated With The IPv6 Router Alert Option">		</t>
	<t><xref target="RFC6398"/> identifies security considerations		</section>
			<section numbered="true" toc="default">
			<name>Issues Associated with the IPv6 Router Alert Option</name>
			<t><xref target="RFC6398" format="default"/> identifies security considera
			tions
	associated with the Router Alert Option. In a nutshell,		associated with the Router Alert Option. In a nutshell,
	the IP Router Alert Option does not provide a		the IP Router Alert Option does not provide a
	universal mechanism to accurately and reliably distinguish		universal mechanism to accurately and reliably distinguish
	between IP Router Alert packets of interest and unwanted IP Router		between IP Router Alert packets of interest and unwanted IP Router
	Alerts. This creates a security concern, because, short of		Alerts. This creates a security concern because, short of
	appropriate router-implementation-specific mechanisms, the router's		appropriate router-implementation-specific mechanisms, the router's
	control plane is at risk of being flooded by unwanted traffic.</t>		control plane is at risk of being flooded by unwanted traffic.</t>
			<aside>
	<t>NOTE: Many routers maintain separation between forwarding		<t>NOTE: Many routers maintain separation between forwarding
	and control plane hardware. The forwarding plane is implemented		and control plane hardware. The forwarding plane is implemented
	on high-performance Application Specific Integrated Circuits (ASIC)		on high-performance Application-Specific Integrated Circuits (ASICs)
	and Network Processors (NP), while the control plane is implemented		and Network Processors (NPs), while the control plane is implemented
	on general-purpose processors. Given this difference, the control		on general-purpose processors. Given this difference, the control
	plane is more susceptible to a Denial-of-Service (DoS) attack than the		plane is more susceptible to a Denial-of-Service (DoS) attack than the
	forwarding plane.</t>		forwarding plane.</t>
			</aside>
	<t><xref target="RFC6192"/> demonstrates how a network operator can		<t><xref target="RFC6192" format="default"/> demonstrates how a network oper
	deploy Access Control Lists (ACL) that protect the control plane from		ator can
	DoS attack. These ACLs are effective and efficient when they select		deploy Access Control Lists (ACLs) that protect the control plane from
			DoS attacks. These ACLs are effective and efficient when they select
	packets based upon information that can be found in a fixed position.		packets based upon information that can be found in a fixed position.
	However, they become less effective and less efficient when they		However, they become less effective and less efficient when they
	must parse an IPv6 Hop-by-Hop Options header, searching for the		must parse a Hop-by-Hop Options header, searching for the
	Router Alert Option.</t>		Router Alert Option.</t>
			<t>Network operators can address the security considerations
	<t>So, network operators can address the security considerations		raised in <xref target="RFC6398" format="default"/> by:</t>
	raised in <xref target="RFC6398"/> by:</t>		<ul spacing="normal">
			<li>
	<t><list style="symbols">		<t>Deploying the operationally complex and computationally
	<t>Deploying the operationally complex and computationally		expensive ACLs described in <xref target="RFC6192" format="default"/>.</t>
	expensive ACLs described in <xref target="RFC6192"/>.</t>		</li>
	<t>Configuring their routers to ignore the Router		<li>
			<t>Configuring their routers to ignore the Router
	Alert Option.</t>		Alert Option.</t>
	<t>Dropping or severely rate limiting packets that contain the		</li>
	IPv6 Hop-by-hop Options header at the network edge.</t>		<li>
	</list></t>		<t>Dropping or severely rate limiting packets that contain the
			Hop-by-Hop Options header at the network edge.</t>
	<t>These options become less viable as protocol designers continue		</li>
			</ul>
			<t>These options become less viable as protocol designers continue
	to design protocols that use the Router Alert Option.</t>		to design protocols that use the Router Alert Option.</t>
	<t><xref target="RFC9673"></xref> seeks to eliminate Hop-by-Hop		<t><xref target="RFC9673" format="default"/> seeks to eliminate hop-by-hop
	processing on the control plane. However, because of its unique		processing on the control plane. However, because of its unique
	function, the Router Alert option is granted an exception to this rule.		function, the Router Alert option is granted an exception to this rule.
	One approach would be to deprecate the Router Alert option, because		One approach would be to deprecate the Router Alert option, because
	current usage beyond the local network appears to be limited,		current usage beyond the local network appears to be limited
	and packets containing Hop-by-Hop options are frequently dropped.		and packets containing Hop-by-Hop options are frequently dropped.
	Deprecation would allow current implementations to continue using it,		Deprecation would allow current implementations to continue using it,
	but its use could be phased out over time.</t>		but its use could be phased out over time.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title= "Deprecate The IPv6 Router Alert Option">		<name>Deprecation of the IPv6 Router Alert Option</name>
	<t>This document deprecates the IPv6 Router Alert Option.		<t>This document deprecates the IPv6 Router Alert Option.
	Protocols that use the Router Alert Option MAY continue to do so,		Protocols that use the Router Alert Option <bcp14>MAY</bcp14> continue to do
			so,
	even in future versions. However, new protocols that are standardized		even in future versions. However, new protocols that are standardized
	in the future MUST NOT use the Router Alert Option.		in the future <bcp14>MUST NOT</bcp14> use the Router Alert Option.
	<xref target="Legacy"/> contains an exhaustive list of protocols that may		<xref target="Legacy" format="default"/> contains an exhaustive list of prot
			ocols that <bcp14>MAY</bcp14>
	continue to use the Router Alert Option. </t>		continue to use the Router Alert Option. </t>
	<t>This document updates <xref target="RFC2711"/>.</t>		<t>This document updates <xref target="RFC2711" format="default"/>.</t>
			</section>
	</section>		<section numbered="true" toc="default">
			<name>Future Work</name>
	<section title="Future Work">		<t>
			A number of protocols
	<t>		use the Router Alert option; these are listed in <xref target="Legacy" format="d
	As listed in <xref target="Legacy"/>, there are a number of protocols		efault"/>. The only protocols in
	that use the Router Alert option. The only protocols in		<xref target="Legacy" format="default"/> that have widespread deployment are
	the Appendix that have wide spread deployment are		Multicast Listener Discovery Version 2 (MLDv2) <xref target="RFC9777" format="de
	<xref target="RFC3810">Multicast Listener Discovery Version 2 (MLDv2) </xref>		fault"></xref>
	and		and
	<xref target="RFC4286">Multicast Router Discovery (MRD) </xref>.		Multicast Router Discovery (MRD) <xref target="RFC4286" format="default"></xref
	The other protocols have either limited deployment, are Experimental, or have no		>.
	known implementation.		The other protocols either have limited deployment, are experimental, or have no
			known implementation.
	</t>		</t>
	<t>		<t>
	It is left for future work to develop new versions of MLDv2 and MRD that do not		It is left for future work to develop new versions of MLDv2 and MRD that do not
	rely on the Router Alert option. That task is out of scope for this document.		rely on the Router Alert option. That task is out of scope for this document.
	</t>		</t>
	</section>		</section>
			<section anchor="Security" numbered="true" toc="default">
	<section anchor="Security" title="Security Considerations">		<name>Security Considerations</name>
	<t>This document mitigates all security considerations associated with the I		<t>This document mitigates all security considerations associated with the
	Pv6 Router Alert		IPv6 Router Alert
	Option. These security considerations can be found in <xref target="RFC2711"		Option. These security considerations can be found in <xref target="RFC2711"
	></xref>,		format="default"/>,
	<xref target="RFC6192"></xref> and <xref target="RFC6398"></xref>.</t>		<xref target="RFC6192" format="default"/>, and <xref target="RFC6398" format
	</section>		="default"/>.</t>
			</section>
	<section title="IANA Considerations">		<section numbered="true" toc="default">
	<t>IANA is requested to mark the Router Alert Option as "Deprecated for New		<name>IANA Considerations</name>
	Protocols" in the Destination		<t>IANA has marked the Router Alert Option as "DEPRECATED for New Protocol
	Options and Hop-by-hop Options Registry (https://www.iana.org/assignments/ip		s" in the <eref brackets="angle" target="https://www.iana.org/assignments/ipv6-p
	v6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2)		arameters">"Destination
	and add a pointer to this document.</t>		Options and Hop-by-Hop Options" registry</eref>
	<t>		and added this document as a reference.</t>
	IANA is also requested to make a note in the IPv6 Router Alert Option Values		<t>
	Registry		IANA has also made a note in the
	(https://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-v		<eref brackets ="angle" target="https://www.iana.org/assignments/ipv6-router
	alues.xhtml?)		alert-values">"IPv6 Router Alert Option Values" registry</eref> stating that the
	stating that this registry is closed for allocations along with a reference		registry
	to this document.		is closed for allocations and added a reference to this document.
	Please change all experimental codepoints in this registry as "reserved" (i.		The experimental codepoints in this registry have been changed to "Reserved"
	e., they are no longer		(i.e., they are no longer
	available for experimentation).		available for experimentation).
	</t>		</t>
	</section>		</section>
			</middle>
	<section title="Acknowledgements">
	<t>Thanks to Zafar Ali, Brian Carpenter, Toerless Eckert, David Farmer,
	Adrian Farrel, Bob Hinden and Jen Linkova for their reviews of this document
	.</t>
	</section>
	</middle>
	<back>		<back>
	<references title="Normative References">		<references>
	<?rfc include="reference.RFC.2711"?>		<name>References</name>
			<references>
	<?rfc include="reference.RFC.6398"?>
	<?rfc include="reference.RFC.2119"?>
	<?rfc include='reference.RFC.8174'?>
	<?rfc include='reference.RFC.8200'?>
	<?rfc include='reference.RFC.9673'?>
	</references>
	<references title="Informative References">
	<?rfc include="reference.RFC.6192"?>
	<?rfc include='reference.RFC.1633"?>
	<?rfc include='reference.RFC.3810'?>
	<?rfc include='reference.RFC.3031'?>
	<?rfc include='reference.RFC.4286'?>
	<?rfc include='reference.RFC.5946'?>
	<?rfc include='reference.RFC.5979'?>
	<?rfc include='reference.RFC.6016'?>
	<?rfc include='reference.RFC.8029'?>
	<?rfc include='reference.RFC.5971'?>
	<?rfc include='reference.RFC.6401'?>
	<?rfc include='reference.RFC.3175'?>
	<?rfc include='reference.RFC.4080'?>
	<?rfc include='reference.RFC.7506'?>
	<?rfc include='reference.RFC.3208'?>
	<?rfc include='reference.RFC.9570'?>		<name>Normative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
			711.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
			398.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
			119.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			174.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			200.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			673.xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
			192.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
			633.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			777.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
			031.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
			286.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
			946.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
			979.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
			016.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			029.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
			971.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
			401.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
			175.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
			080.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			506.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
			208.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			570.xml"/>
			</references>
	</references>		</references>
			<section anchor="Legacy" numbered="true" toc="default">
	<section anchor="Legacy" title="Protocols That Use The Router Alert Optio		<name>Protocols That Use the Router Alert Option</name>
	n">		<t><xref target="Depend" format="default"/> contains an exhaustive list of
	<t><xref target="Depend"/> contains an exhaustive list of protocols that us		protocols that use the
	e the
	IPv6 Router Alert Option. There are no known IPv6 implementations of		IPv6 Router Alert Option. There are no known IPv6 implementations of
	MPLS PING. Neither INTSERV nor NSIS are widely deployed. All NSIS		MPLS Ping. Neither Integrated Services (Intserv) nor Next Steps in Signali
	protocols are EXPERIMENTAL. Pragmatic Generic Multicast (PGM) is		ng (NSIS) are widely deployed. All NSIS
	EXPERIMENTAL and there are no known IPv6 implementations.</t>		protocols are experimental. Pragmatic Generic Multicast (PGM) is
			experimental, and there are no known IPv6 implementations.</t>
	<texttable anchor="Depend" style="full"
	title="Protocols That Use The IPv6 Router Alert Option">
	<ttcol>Protocol</ttcol>
	<ttcol>References</ttcol>
	<ttcol>Application</ttcol>
	<c>Multicast Listener Discovery Version 2 (MLDv2)</c>
	<c><xref target="RFC3810"/></c>
	<c>IPv6 Multicast</c>
	<c/>
	<c/>
	<c/>
	<c>Multicast Router Discovery (MRD)</c>
	<c><xref target="RFC4286"/></c>
	<c>IPv6 Multicast</c>
	<c/>
	<c/>
	<c/>
	<c>Pragmatic General Multicast (PGM)</c>
	<c><xref target="RFC3208"/></c>
	<c>IPv6 Multicast</c>
	<c/>
	<c/>
	<c/>
	<c>MPLS PING (Use of router alert deprecated)</c>
	<c><xref target="RFC7506"/><xref target="RFC8029"/><xref target="RFC9570
	"/></c>
	<c>MPLS OAM</c>
	<c/>
	<c/>
	<c/>
	<c>Resource Reservation Protocol (RSVP): Both IPv4 and IPv6 implementati
	ons</c>
	<c><xref target="RFC3175"/> <xref target="RFC5946"/> <xref
	target="RFC6016"/> <xref target="RFC6401"/></c>
	<c><xref target="RFC1633">Integrated Services (INTSERV) </xref>
	and
	<xref target="RFC3031">Multiprotocol Label Switching (MPLS)</xref></c>
	<c/>
	<c/>
	<c/>
	<c>Next Steps In Signaling (NSIS)</c>
	<c><xref target="RFC5979"/> <xref target="RFC5971"/></c>
	<c><xref target="RFC4080">NSIS </xref></c>		<table anchor="Depend" align="center">
	</texttable>		<name>Protocols That Use the IPv6 Router Alert Option</name>
			<thead>
			<tr>
			<th align="left">Protocol</th>
			<th align="left">References</th>
			<th align="left">Application</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left">Multicast Listener Discovery Version 2 (MLDv2)</td>
			<td align="left"><xref target="RFC9777" format="default"/></td>
			<td align="left">IPv6 Multicast</td>
			</tr>
			<tr>
			<td align="left">Multicast Router Discovery (MRD)</td>
			<td align="left"><xref target="RFC4286" format="default"/></td>
			<td align="left">IPv6 Multicast</td>
			</tr>
			<tr>
			<td align="left">Pragmatic General Multicast (PGM)</td>
			<td align="left"><xref target="RFC3208" format="default"/></td>
			<td align="left">IPv6 Multicast</td>
			</tr>
			<tr>
			<td align="left">MPLS Ping (Use of the Router Alert Option is deprec
			ated)</td>
			<td align="left"><xref target="RFC7506" format="default"/><xref targ
			et="RFC8029" format="default"/><xref target="RFC9570" format="default"/></td>
			<td align="left">MPLS Operations, Administration, and Maintenance (O
			AM)</td>
			</tr>
			<tr>
			<td align="left">Resource Reservation Protocol (RSVP): Both IPv4 and
			IPv6 implementations</td>
			<td align="left"><xref target="RFC3175" format="default"/> <xref tar
			get="RFC5946" format="default"/> <xref target="RFC6016" format="default"/> <xref
			target="RFC6401" format="default"/></td>
			<td align="left">Integrated Services (Intserv) <xref target="RFC1633
			"
			format="default"></xref> and Multiprotocol Label Switching
			(MPLS) <xref
			target="RFC3031" format="default"></xref></td>
			</tr>
			<tr>
			<td align="left">Next Steps in Signaling (NSIS)</td>
			<td align="left"><xref target="RFC5979" format="default"/> <xref tar
			get="RFC5971" format="default"/></td>
			<td align="left">NSIS <xref target="RFC4080" format="default"></xref
			></td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
			<section numbered="false" toc="default">
			<name>Acknowledgements</name>
			<t>Thanks to <contact fullname="Zafar Ali"/>, <contact fullname="Brian
			Carpenter"/>, <contact fullname="Toerless Eckert"/>, <contact
			fullname="David Farmer"/>, <contact fullname="Adrian Farrel"/>, <contact
			fullname="Bob Hinden"/>, and <contact fullname="Jen Linkova"/> for their
			reviews of this document.</t>
			</section>
			</back>
	</back>
	</rfc>		</rfc>
End of changes. 34 change blocks.
	288 lines changed or deleted		271 lines changed or added
This html diff was produced by rfcdiff 1.48.