draft-ietf-ipngwg-icmp-v3-04.txt		draft-ietf-ipngwg-icmp-v3-05.txt
	Internet Draft A. Conta, Transwitch		Internet Draft A. Conta, Transwitch
	IPv6 Working Group S. Deering, Cisco Systems		IPv6 Working Group S. Deering, Cisco Systems
	1 June 2004		21 October 2004 M. Gupta, Nokia (ed.)
	Internet Control Message Protocol (ICMPv6)		Internet Control Message Protocol (ICMPv6)
	for the Internet Protocol Version 6 (IPv6)		for the Internet Protocol Version 6 (IPv6)
	Specification		Specification
	<draft-ietf-ipngwg-icmp-v3-04.txt>		<draft-ietf-ipngwg-icmp-v3-05.txt>
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	and any of which I become aware will be disclosed, in accordance with		and any of which I become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 36		skipping to change at page 1, line 35
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet- Drafts as reference		time. It is inappropriate to use Internet- Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This internet draft will expire on December 4, 2004.		This internet draft will expire on April 21, 2004.
	Abstract		Abstract
	This document describes the format of a set of control messages used		This document describes the format of a set of control messages used
	in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the		in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the
	Internet Control Message Protocol for Internet Protocol version 6		Internet Control Message Protocol for Internet Protocol version 6
	(IPv6).		(IPv6).
	Table of Contents		Table of Contents
	skipping to change at page 4, line 15		skipping to change at page 4, line 15
	ICMPv6 error messages:		ICMPv6 error messages:
	1 Destination Unreachable (see section 3.1)		1 Destination Unreachable (see section 3.1)
	2 Packet Too Big (see section 3.2)		2 Packet Too Big (see section 3.2)
	3 Time Exceeded (see section 3.3)		3 Time Exceeded (see section 3.3)
	4 Parameter Problem (see section 3.4)		4 Parameter Problem (see section 3.4)
	100 Private experimentation		100 Private experimentation
	101 Private experimentation		101 Private experimentation
			127 Reserved for expansion of ICMPv6 error messages
	ICMPv6 informational messages:		ICMPv6 informational messages:
	128 Echo Request (see section 4.1)		128 Echo Request (see section 4.1)
	129 Echo Reply (see section 4.2)		129 Echo Reply (see section 4.2)
	200 Private experimentation		200 Private experimentation
	201 Private experimentation		201 Private experimentation
	255 Reserved for expansion		255 Reserved for expansion of ICMPv6 informational messages
	Type values 100, 101, 200, and 201 are reserved for private		Type values 100, 101, 200, and 201 are reserved for private
	experimentation. These are not intended for general use. It is		experimentation. These are not intended for general use. It is
	expected that multiple concurrent experiments will be done with the		expected that multiple concurrent experiments will be done with the
	same type values. Any wide scale and/or uncontrolled usage should		same type values. Any wide scale and/or uncontrolled usage should
	obtain real allocations as defined in section 6.		obtain real allocations as defined in section 6.
	Type value 255 is reserved for future expansion of the type value		Type value 255 is reserved for future expansion of the type value
	range if there should be a shortage in the future. The details of		range if there should be a shortage in the future. The details of
	this are left for future work. One possible way of doing this that		this are left for future work. One possible way of doing this that
	skipping to change at page 5, line 36		skipping to change at page 5, line 36
	following, more specific format:		following, more specific format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Code | Checksum |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| type-specific data (32 bits) |		| type-specific data (32 bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| As much of invoking packet |		| As much of invoking packet |
	+ as will fit without the ICMPv6 packet +		+ as possible without the ICMPv6 packet +
	| exceeding the minimum IPv6 MTU [IPv6] |		| exceeding the minimum IPv6 MTU [IPv6] |
	2.2 Message Source Address Determination		2.2 Message Source Address Determination
	A node that sends an ICMPv6 message has to determine both the Source		A node that sends an ICMPv6 message has to determine both the Source
	and Destination IPv6 Addresses in the IPv6 header before calculating		and Destination IPv6 Addresses in the IPv6 header before calculating
	the checksum. If the node has more than one unicast address, it MUST		the checksum. If the node has more than one unicast address, it MUST
	choose the Source Address of the message as follows:		choose the Source Address of the message as follows:
	(a) If the message is a response to a message sent to one of the		(a) If the message is a response to a message sent to one of the
	skipping to change at page 6, line 49		skipping to change at page 6, line 49
	ICMPv6 messages (from [RFC-1122]):		ICMPv6 messages (from [RFC-1122]):
	(a) If an ICMPv6 error message of unknown type is received, it MUST		(a) If an ICMPv6 error message of unknown type is received, it MUST
	be passed to the upper layer.		be passed to the upper layer.
	(b) If an ICMPv6 informational message of unknown type is received,		(b) If an ICMPv6 informational message of unknown type is received,
	it MUST be silently discarded.		it MUST be silently discarded.
	(c) Every ICMPv6 error message (type < 128) MUST include as much of		(c) Every ICMPv6 error message (type < 128) MUST include as much of
	the IPv6 offending (invoking) packet (the packet that caused the		the IPv6 offending (invoking) packet (the packet that caused the
	error) as will fit without making the error message packet		error) as possible without making the error message packet
	exceed the minimum IPv6 MTU [IPv6].		exceed the minimum IPv6 MTU [IPv6].
	(d) In those cases where the internet-layer protocol is required to		(d) In those cases where the internet-layer protocol is required to
	pass an ICMPv6 error message to the upper-layer process, the		pass an ICMPv6 error message to the upper-layer process, the
	upper-layer protocol type is extracted from the original packet		upper-layer protocol type is extracted from the original packet
	(contained in the body of the ICMPv6 error message) and used to		(contained in the body of the ICMPv6 error message) and used to
	select the appropriate upper-layer process to handle the error.		select the appropriate upper-layer process to handle the error.
	If the original packet had an unusually large amount of		If the original packet had an unusually large amount of
	extension headers, it is possible that the upper-layer protocol		extension headers, it is possible that the upper-layer protocol
	skipping to change at page 9, line 17		skipping to change at page 9, line 17
	3.1 Destination Unreachable Message		3.1 Destination Unreachable Message
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Code | Checksum |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Unused |		| Unused |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| As much of invoking packet |		| As much of invoking packet |
	+ as will fit without the ICMPv6 packet +		+ as possible without the ICMPv6 packet +
	| exceeding the minimum IPv6 MTU [IPv6] |		| exceeding the minimum IPv6 MTU [IPv6] |
	IPv6 Fields:		IPv6 Fields:
	Destination Address		Destination Address
	Copied from the Source Address field of the invoking		Copied from the Source Address field of the invoking
	packet.		packet.
	ICMPv6 Fields:		ICMPv6 Fields:
	skipping to change at page 11, line 15		skipping to change at page 11, line 15
	3.2 Packet Too Big Message		3.2 Packet Too Big Message
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Code | Checksum |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MTU |		| MTU |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| As much of invoking packet |		| As much of invoking packet |
	+ as will fit without the ICMPv6 packet +		+ as possible without the ICMPv6 packet +
	| exceeding the minimum IPv6 MTU [IPv6] |		| exceeding the minimum IPv6 MTU [IPv6] |
	IPv6 Fields:		IPv6 Fields:
	Destination Address		Destination Address
	Copied from the Source Address field of the invoking		Copied from the Source Address field of the invoking
	packet.		packet.
	ICMPv6 Fields:		ICMPv6 Fields:
	skipping to change at page 12, line 15		skipping to change at page 12, line 15
	3.3 Time Exceeded Message		3.3 Time Exceeded Message
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Code | Checksum |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Unused |		| Unused |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| As much of invoking packet |		| As much of invoking packet |
	+ as will fit without the ICMPv6 packet +		+ as possible without the ICMPv6 packet +
	| exceeding the minimum IPv6 MTU [IPv6] |		| exceeding the minimum IPv6 MTU [IPv6] |
	IPv6 Fields:		IPv6 Fields:
	Destination Address		Destination Address
	Copied from the Source Address field of the invoking		Copied from the Source Address field of the invoking
	packet.		packet.
	ICMPv6 Fields:		ICMPv6 Fields:
	skipping to change at page 14, line 15		skipping to change at page 14, line 15
	3.4 Parameter Problem Message		3.4 Parameter Problem Message
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Code | Checksum |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Pointer |		| Pointer |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| As much of invoking packet |		| As much of invoking packet |
	+ as will fit without the ICMPv6 packet +		+ as possible without the ICMPv6 packet +
	| exceeding the minimum IPv6 MTU [IPv6] |		| exceeding the minimum IPv6 MTU [IPv6] |
	IPv6 Fields:		IPv6 Fields:
	Destination Address		Destination Address
	Copied from the Source Address field of the invoking		Copied from the Source Address field of the invoking
	packet.		packet.
	ICMPv6 Fields:		ICMPv6 Fields:
	skipping to change at page 21, line 18		skipping to change at page 21, line 18
	The IPv6 ICMP header [ICMPV6] contains the following fields that		The IPv6 ICMP header [ICMPV6] contains the following fields that
	carry values assigned from IANA-managed name spaces: Type and Code.		carry values assigned from IANA-managed name spaces: Type and Code.
	Code field values are defined relative to a specific Type value.		Code field values are defined relative to a specific Type value.
	Values for the IPv6 ICMP Type fields are allocated using the		Values for the IPv6 ICMP Type fields are allocated using the
	following procedure:		following procedure:
	1. The IANA should allocate and permanently register new ICMPv6 type		1. The IANA should allocate and permanently register new ICMPv6 type
	codes from IETF RFC publication. This is for all RFC types		codes from IETF RFC publication. This is for all RFC types
	including standards track, informational, experimental status,		including standards track, informational, and experimental status
	etc.		that originate from the IETF and have been approved by the IESG
			for publication.
	2. IETF working groups with working group consensus and area director		2. IETF working groups with working group consensus and area director
	approval can request reclaimable ICMPV6 type code assignments from		approval can request reclaimable ICMPV6 type code assignments from
	the IANA. The IANA will tag the values as "reclaimable in		the IANA. The IANA will tag the values as "reclaimable in
	future".		future".
	The "reclaimable in the future" tag will be removed when an is		The "reclaimable in the future" tag will be removed when an RFC is
	published documenting the protocol as defined in 1). This will		published documenting the protocol as defined in 1). This will
	make the assignment permanent.		make the assignment permanent and update the reference on the IANA
			web pages.
	At the point where the type values are 85% assigned, the IANA will		At the point where the ICMPv6 type values are 85% assigned, the
	request that the IETF review the assignments tagged "reclaimable		IETF will review the assignments tagged "reclaimable in the
	in the future" and make a recommendation to the IANA which ones		future" and inform the IANA which ones should be reclaimed and
	can be reclaimed and reassigned.		reassigned.
	3. Requests for type value assignments from outside of the IETF		3. Requests for new ICMPv6 type value assignments from outside the
	should be sent to the IETF for review. The general guideline for		IETF are only made through the publication of an IETF document,
	this review is that the assignment should be made if there is		per 1) above. Note also that documents published as "RFC Editor
	public and open documentation of the protocol and if the		contributions" [RFC 3667] are not considered to be IETF documents.
	assignment is not being used to circumvent an existing IETF
	protocol or work in progress.
	The policy for assigning Code values for new IPv6 ICMP Types should		The assignment of new Code values for the Type values defined in this
	be defined in the document defining the new Type values.		document require standards action or IESG approval. The policy for
			assigning Code values for new IPv6 ICMP Types not defined in this
			document should be defined in the document defining the new Type
			values.
	6.2 Assignments for this document		6.2 Assignments for this document
	The following should update the assignments located at:		The following should update the assignments located at:
	http://www.iana.org/assignments/icmpv6-parameters		http://www.iana.org/assignments/icmpv6-parameters
	The IANA is requested to reassign ICMPv6 type 1 "Destination		The IANA is requested to reassign ICMPv6 type 1 "Destination
	Unreachable" code 2, that was unassigned in [RFC-2463], to:		Unreachable" code 2, that was unassigned in [RFC-2463], to:
	2 - beyond scope of source address		2 - beyond scope of source address
	The IANA is requested to assign the following two new codes values		The IANA is requested to assign the following two new codes values
	for ICMPv6 type 1 "Destination Unreachable":		for ICMPv6 type 1 "Destination Unreachable":
	5 - source address failed ingress/egress policy		5 - source address failed ingress/egress policy
	6 - reject route to destination		6 - reject route to destination
	skipping to change at page 23, line 31		skipping to change at page 23, line 33
	The document is derived from previous ICMP drafts of the SIPP and		The document is derived from previous ICMP drafts of the SIPP and
	IPng working group.		IPng working group.
	The IPng working group and particularly Robert Elz, Jim Bound, Bill		The IPng working group and particularly Robert Elz, Jim Bound, Bill
	Simpson, Thomas Narten, Charlie Lynn, Bill Fink, Scott Bradner,		Simpson, Thomas Narten, Charlie Lynn, Bill Fink, Scott Bradner,
	Dimitri Haskin, Bob Hinden, Jun-ichiro Itojun Hagino, Tatuya Jinmei,		Dimitri Haskin, Bob Hinden, Jun-ichiro Itojun Hagino, Tatuya Jinmei,
	Brian Zill, Pekka Savola, and Fred Templin (in chronological order)		Brian Zill, Pekka Savola, and Fred Templin (in chronological order)
	provided extensive review information and feedback.		provided extensive review information and feedback.
	Mukesh Gupta and Bob Hinden were the document editors for this		Bob Hinden was the document editor for this document.
	document.
	9. Authors' Addresses		9. Authors' Addresses
	Alex Conta Stephen Deering		Alex Conta
	Transwitch Corporation Cisco Systems, Inc.		Transwitch Corporation
	3 Enterprise Drive 170 West Tasman Drive		3 Enterprise Drive
	Shelton, CT 06484 San Jose, CA 95134-1706		Shelton, CT 06484
	US US		USA
			Email: aconta@txc.com
	email: aconta@txc.com		Stephen Deering
			Cisco Systems, Inc.
			170 West Tasman Drive
			San Jose, CA 95134-1706
			USA
			Mukesh Gupta (ed.)
			Nokia
			313 Fairchild Drive
			Mountain View, CA 94043
			USA
			Phone: +1 650-625-2264
			Email: mukesh.gupta@nokia.com
	Appendix A - Changes from RFC 2463		Appendix A - Changes since RFC 2463
	The following changes were made from RFC 2463:		The following changes were made from RFC 2463:
	- Edited the Abstract to make it a little more elaborate.		- Edited the Abstract to make it a little more elaborate.
	- Corrected typos in section 2.4, where references to sub-bullet e.2		- Corrected typos in section 2.4, where references to sub-bullet e.2
	were supposed to be references to e.3.		were supposed to be references to e.3.
	- Removed the Timer-based and the Bandwidth-based methods from the		- Removed the Timer-based and the Bandwidth-based methods from the
	example rate-limiting mechanism for ICMP error messages. Added		example rate-limiting mechanism for ICMP error messages. Added
	skipping to change at page 25, line 9		skipping to change at page 25, line 24
	the requirement of an option of "not allowing unauthenticated ICMP		the requirement of an option of "not allowing unauthenticated ICMP
	messages" to MAY from SHOULD.		messages" to MAY from SHOULD.
	- Added a new attack in the list of possible ICMP attacks in section		- Added a new attack in the list of possible ICMP attacks in section
	5.2.		5.2.
	- Separated References into Normative and Informative.		- Separated References into Normative and Informative.
	- Added reference to RFC-2780 "IANA Allocation Guidelines For Values		- Added reference to RFC-2780 "IANA Allocation Guidelines For Values
	In the Internet Protocol and Related Headers"		In the Internet Protocol and Related Headers"
			- Added a procedure for new ICMPv6 Type and Code value assignments
			in the IANA Consideration section.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2004). This document is subject
	to the rights, licenses and restrictions contained in BCP 78 and		to the rights, licenses and restrictions contained in BCP 78 and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/