draft-ietf-ipngwg-icmp-v3-06.txt		draft-ietf-ipngwg-icmp-v3-07.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
	18 November 2004 M. Gupta, Nokia (ed.)		11 July 2005 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-06.txt>		<draft-ietf-ipngwg-icmp-v3-07.txt>
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, each author represents that any
	patent or other IPR claims of which I am aware have been disclosed,		applicable patent or other IPR claims of which he or she is aware
	and any of which I become aware will be disclosed, in accordance with		have been or will be disclosed, and any of which he or she becomes
	RFC 3668.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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 May 18, 2005.		This internet draft will expire on Jan 11 2006.
			Copyright Notice
			Copyright (C) The Internet Society (2005).
	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
	1. Introduction.....................................................3		1. Introduction.....................................................3
	2. ICMPv6 (ICMP for IPv6)...........................................3		2. ICMPv6 (ICMP for IPv6)...........................................3
	2.1 Message General Format....................................3		2.1 Message General Format....................................3
	2.2 Message Source Address Determination......................5		2.2 Message Source Address Determination......................5
	2.3 Message Checksum Calculation..............................6		2.3 Message Checksum Calculation..............................6
	2.4 Message Processing Rules..................................6		2.4 Message Processing Rules..................................6
	3. ICMPv6 Error Messages............................................9		3. ICMPv6 Error Messages............................................9
	3.1 Destination Unreachable Message...........................9		3.1 Destination Unreachable Message...........................9
	3.2 Packet Too Big Message...................................12		3.2 Packet Too Big Message...................................12
	3.3 Time Exceeded Message....................................13		3.3 Time Exceeded Message....................................13
	3.4 Parameter Problem Message................................15		3.4 Parameter Problem Message................................14
	4. ICMPv6 Informational Messages...................................17		4. ICMPv6 Informational Messages...................................16
	4.1 Echo Request Message.....................................17		4.1 Echo Request Message.....................................16
	4.2 Echo Reply Message.......................................18		4.2 Echo Reply Message.......................................17
	5. Security Considerations.........................................20		5. Security Considerations.........................................19
	5.1 Authentication and Confidentiality of ICMP messages......20		5.1 Authentication and Confidentiality of ICMP messages......19
	5.2 ICMP Attacks.............................................20		5.2 ICMP Attacks.............................................19
	6. IANA Considerations.............................................21		6. IANA Considerations.............................................21
	6.1 Procedure for new ICMPV6 Type and Code value assignments.22		6.1 Procedure for new ICMPV6 Type and Code value assignments.22
	6.2 Assignments for this document............................22		6.2 Assignments for this document............................22
	7. References......................................................23		7. References......................................................23
	7.1 Normative................................................23		7.1 Normative................................................22
	7.2 Informative..............................................24		7.2 Informative..............................................22
	8. Acknowledgments.................................................24		8. Acknowledgments.................................................23
	9. Authors' Addresses..............................................24		9. Authors' Addresses..............................................23
	Appendix A - Changes since RFC 2463................................24		Appendix A - Changes since RFC 2463................................24
	1. Introduction		1. Introduction
	The Internet Protocol, version 6 (IPv6) uses the Internet Control		The Internet Protocol, version 6 (IPv6) uses the Internet Control
	Message Protocol (ICMP) as defined for IPv4 [RFC-792], with a number		Message Protocol (ICMP) as defined for IPv4 [RFC-792], with a number
	of changes. The resulting protocol is called ICMPv6, and has an IPv6		of changes. The resulting protocol is called ICMPv6, and has an IPv6
	Next Header value of 58.		Next Header value of 58.
	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. It does not describe the procedures for using these		in ICMPv6. It does not describe the procedures for using these
	messages to achieve functions like Path MTU discovery; such		messages to chieve functions like Path MTU discovery; such procedures
	procedures are described in other documents (e.g., [PMTU]). Other		are described in other documents (e.g., [PMTU]). Other documents may
	documents may also introduce additional ICMPv6 message types, such as		also introduce additional ICMPv6 message types, such as Neighbor
	Neighbor Discovery messages [IPv6-DISC], subject to the general rules		Discovery messages [IPv6-DISC], subject to the general rules for
	for ICMPv6 messages given in section 2 of this document.		ICMPv6 messages given in section 2 of this document.
	Terminology defined in the IPv6 specification [IPv6] and the IPv6		Terminology defined in the IPv6 specification [IPv6] and the IPv6
	Routing and Addressing specification [IPv6-ADDR] applies to this		Routing and Addressing specification [IPv6-ADDR] applies to this
	document as well.		document as well.
	This document obsoletes RFC 2463 [RFC-2463].		This document obsoletes RFC 2463 [RFC2463] and updates RFC 2780
			[RFC-2780].
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC-2119].		document are to be interpreted as described in [RFC-2119].
	2. ICMPv6 (ICMP for IPv6)		2. ICMPv6 (ICMP for IPv6)
	ICMPv6 is used by IPv6 nodes to report errors encountered in		ICMPv6 is used by IPv6 nodes to report errors encountered in
	processing packets, and to perform other internet-layer functions,		processing packets, and to perform other internet-layer functions,
	such as diagnostics (ICMPv6 "ping"). ICMPv6 is an integral part of		such as diagnostics (ICMPv6 "ping"). ICMPv6 is an integral part of
	IPv6 and MUST be fully implemented by every IPv6 node.		IPv6 and the base protocol (all the messages and behavior required by
			this specification) MUST be fully implemented by every IPv6 node.
	2.1 Message General Format		2.1 Message General Format
			Every ICMPv6 message is preceded by an IPv6 header and zero or more
			IPv6 extension headers. The ICMPv6 header is identified by a Next
			Header value of 58 in the immediately preceding header. (NOTE: this
			is different than the value used to identify ICMP for IPv4.)
			The ICMPv6 messages have the following general format:
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Code | Checksum |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ Message Body +
			| |
			The type field indicates the type of the message. Its value
			determines the format of the remaining data.
			The code field depends on the message type. It is used to create an
			additional level of message granularity.
			The checksum field is used to detect data corruption in the ICMPv6
			message and parts of the IPv6 header.
	ICMPv6 messages are grouped into two classes: error messages and		ICMPv6 messages are grouped into two classes: error messages and
	informational messages. Error messages are identified as such by		informational messages. Error messages are identified as such by
	having a zero in the high-order bit of their message Type field		having a zero in the high-order bit of their message Type field
	values. Thus, error messages have message Types from 0 to 127;		values. Thus, error messages have message Types from 0 to 127;
	informational messages have message Types from 128 to 255.		informational messages have message Types from 128 to 255.
	This document defines the message formats for the following ICMPv6		This document defines the message formats for the following ICMPv6
	messages:		messages:
	ICMPv6 error messages:		ICMPv6 error messages:
	skipping to change at page 4, line 42		skipping to change at page 5, line 29
	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
	would not cause any problems with current implementations is if the		would not cause any problems with current implementations is if the
	type equals 255, use the code field for the new assignment. Existing		type equals 255, use the code field for the new assignment. Existing
	implementations would ignore the new assignments as specified in		implementations would ignore the new assignments as specified in
	section 2.4, section (b). The new messages using these expanded type		section 2.4, section (b). The new messages using these expanded type
	values, could assign fields in the message body for it's code values.		values, could assign fields in the message body for it's code values.
	Every ICMPv6 message is preceded by an IPv6 header and zero or more		Sections 3 and 4 describe the message formats for the ICMPv6 error
	IPv6 extension headers. The ICMPv6 header is identified by a Next		message types 1 through 4 and informational message types 128 and
	Header value of 58 in the immediately preceding header. (NOTE: this		129.
	is different than the value used to identify ICMP for IPv4.)
	The ICMPv6 messages have the following general format:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	+ Message Body +
	| |
	The type field indicates the type of the message. Its value
	determines the format of the remaining data.
	The code field depends on the message type. It is used to create an
	additional level of message granularity.
	The checksum field is used to detect data corruption in the ICMPv6
	message and parts of the IPv6 header.
	The subclass of ICMPv6 messages used for reporting errors, i.e.,
	those with a Type value between 0 and 127, inclusive, all have the
	following, more specific format:
	0 1 2 3		Inclusion of, at least, the start of the invoking packet is intended
	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		to allow the originator of a packet that has resulted in an ICMPv6
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		error message to identify the upper-layer protocol and process that
	| Type | Code | Checksum |		sent the packet.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| type-specific data (32 bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| As much of invoking packet |
	+ as possible without the ICMPv6 packet +
	| exceeding the minimum IPv6 MTU [IPv6] |
	2.2 Message Source Address Determination		2.2 Message Source Address Determination
	A node that originates an ICMPv6 message has to determine both the		A node that originates an ICMPv6 message has to determine both the
	Source and Destination IPv6 Addresses in the IPv6 header before		Source and Destination IPv6 Addresses in the IPv6 header before
	calculating the checksum. If the node has more than one unicast		calculating the checksum. If the node has more than one unicast
	address, it MUST choose the Source Address of the message as follows:		address, it MUST 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
	node's unicast addresses, the Source Address of the reply MUST		node's unicast addresses, the Source Address of the reply MUST
	be that same address.		be that same address.
	(b) If the message is a response to a message sent to a multicast or		(b) If the message is a response to a message sent to any other
	anycast group in which the node is a member, the Source Address		address, such as
	of the reply MUST be a unicast address belonging to the		- a multicast group address,
	interface on which the multicast or anycast packet was received.		- an anycast address implemented by the node, or
			- a unicast address which does not belong to the node
	(c) If the message is a response to a message sent to an address		the Source Address of the ICMPv6 packet MUST be a unicast
	that does not belong to the node, the Source Address SHOULD be		address belonging to the node. The address SHOULD be chosen
	that unicast address belonging to the node that will be most		according to the rules which would be used to select the source
	helpful in diagnosing the error. For example, if the message is		address for any other packet originated by the node, given the
	a response to a packet forwarding action that cannot complete		destination address of the packet, but MAY be selected in an
	successfully, the Source Address SHOULD be a unicast address		alternative way if this would lead to a more informative choice
	belonging to the interface on which the packet forwarding		of address which is reachable from the destination of the ICMPv6
	failed.		packet.
	(d) Otherwise, the node's routing table must be examined to
	determine which interface will be used to transmit the message
	to its destination, and a unicast address belonging to that
	interface MUST be used as the Source Address of the message.
	2.3 Message Checksum Calculation		2.3 Message Checksum Calculation
	The checksum is the 16-bit one's complement of the one's complement		The checksum is the 16-bit one's complement of the one's complement
	sum of the entire ICMPv6 message starting with the ICMPv6 message		sum of the entire ICMPv6 message starting with the ICMPv6 message
	type field, prepended with a "pseudo-header" of IPv6 header fields,		type field, prepended with a "pseudo-header" of IPv6 header fields,
	as specified in [IPv6, section 8.1]. The Next Header value used in		as specified in [IPv6, section 8.1]. The Next Header value used in
	the pseudo-header is 58. (NOTE: the inclusion of a pseudo-header in		the pseudo-header is 58. (NOTE: the inclusion of a pseudo-header in
	the ICMPv6 checksum is a change from IPv4; see [IPv6] for the		the ICMPv6 checksum is a change from IPv4; see [IPv6] for the
	rationale for this change.)		rationale for this change.)
	For computing the checksum, the checksum field is first set to zero.		For computing the checksum, the checksum field is first set to zero.
	2.4 Message Processing Rules		2.4 Message Processing Rules
	Implementations MUST observe the following rules when processing		Implementations MUST observe the following rules when processing
	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 at its
	be passed to the upper layer.		destination, it MUST be passed to the upper-layer process that
			originated the packet that caused the error, where this can be
			identified (see Section 2.4(d)).
	(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 possible 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
	skipping to change at page 10, line 46		skipping to change at page 10, line 46
	source address is not allowed due to ingress or egress filtering		source address is not allowed due to ingress or egress filtering
	policies, the Code field is set to 5.		policies, the Code field is set to 5.
	If the reason for the failure to deliver is that the route to the		If the reason for the failure to deliver is that the route to the
	destination is a reject route, the Code field is set to 6. This may		destination is a reject route, the Code field is set to 6. This may
	occur if the router has been configured to reject all the traffic for		occur if the router has been configured to reject all the traffic for
	a specific prefix.		a specific prefix.
	Codes 5 and 6 are more informative subsets of code 1.		Codes 5 and 6 are more informative subsets of code 1.
			For security reasons, it is recommended that implementations SHOULD
			allow sending of ICMP destination unreachable messages to be
			disabled, preferably on a per-interface basis.
	Upper layer notification		Upper layer notification
	A node receiving the ICMPv6 Destination Unreachable message MUST		A node receiving the ICMPv6 Destination Unreachable message MUST
	notify the upper-layer process if the relevant process can be		notify the upper-layer process if the relevant process can be
	identified (see section 2.4(d)).		identified (see section 2.4(d)).
	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
	skipping to change at page 12, line 47		skipping to change at page 13, line 47
	If a router receives a packet with a Hop Limit of zero, or a router		If a router receives a packet with a Hop Limit of zero, or a router
	decrements a packet's Hop Limit to zero, it MUST discard the packet		decrements a packet's Hop Limit to zero, it MUST discard the packet
	and originate an ICMPv6 Time Exceeded message with Code 0 to the		and originate an ICMPv6 Time Exceeded message with Code 0 to the
	source of the packet. This indicates either a routing loop or too		source of the packet. This indicates either a routing loop or too
	small an initial Hop Limit value.		small an initial Hop Limit value.
	An ICMPv6 Time Exceeded message with Code 1 is used to report		An ICMPv6 Time Exceeded message with Code 1 is used to report
	fragment reassembly timeout, as specified in [IPv6, Section 4.5].		fragment reassembly timeout, as specified in [IPv6, Section 4.5].
	The rules for selecting the Source Address of this message are
	defined in section 2.2.
	Upper layer notification		Upper layer notification
	An incoming Time Exceeded message MUST be passed to the upper-layer		An incoming Time Exceeded message MUST be passed to the upper-layer
	process if the relevant process can be identified (see section		process if the relevant process can be identified (see section
	2.4(d)).		2.4(d)).
	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
	skipping to change at page 19, line 5		skipping to change at page 19, line 5
	The data received in the ICMPv6 Echo Request message MUST be returned		The data received in the ICMPv6 Echo Request message MUST be returned
	entirely and unmodified in the ICMPv6 Echo Reply message.		entirely and unmodified in the ICMPv6 Echo Reply message.
	Upper layer notification		Upper layer notification
	Echo Reply messages MUST be passed to the process that originated an		Echo Reply messages MUST be passed to the process that originated an
	Echo Request message. An Echo Reply message MAY be passed to		Echo Request message. An Echo Reply message MAY be passed to
	processes that did not originate the Echo Request message.		processes that did not originate the Echo Request message.
			Note that there is no limitations on the amount of data that can be
			put in Echo Request and Echo Reply Messages.
	5. Security Considerations		5. Security Considerations
	5.1 Authentication and Confidentiality of ICMP messages		5.1 Authentication and Confidentiality of ICMP messages
	ICMP protocol packet exchanges can be authenticated using the IP		ICMP protocol packet exchanges can be authenticated using the IP
	Authentication Header [IPv6-AUTH] or IP Encapsulating Security		Authentication Header [IPv6-AUTH] or IP Encapsulating Security
	Payload Header [IPv6-ESP]. Confidentiality for the ICMP protocol		Payload Header [IPv6-ESP]. Confidentiality for the ICMP protocol
	packet exchanges can be achieved using IP Encapsulating Security		packet exchanges can be achieved using IP Encapsulating Security
	Payload Header [IPv6-ESP]. A node SHOULD include an Authentication		Payload Header [IPv6-ESP].
	Header or Encapsulating Security Payload Header when originating ICMP
	messages if a security association for use with the IP Authentication
	Header or IP Encapsulating Security Payload Header exists for the
	destination address. The security associations may have been created
	through manual configuration or through the operation of some key
	management protocol.
	Received ICMP packets that have Authentication Header or
	Encapsulating Security Payload Header must be processed as specified
	in [IPv6-AUTH] and [IPv6-ESP]. The ICMP packets that fail the
	security processing MUST be ignored and discarded.
	The system administrator MAY be allowed to configure a node to ignore		[SEC-ARCH] describes the IPsec handling of ICMP traffic in detail.
	any ICMP messages that are not authenticated using either the
	Authentication Header or Encapsulating Security Payload. If
	provided, such a switch SHOULD default to allowing unauthenticated
	messages. Note that setting up Security Associations to deal with
	all the required ICMP packets is a very difficult task (e.g.,
	consider the Path MTU Discovery packets). So Path MTU Discovery (and
	possibly some others) may not work if the node only allows
	authenticated ICMP packets.
	5.2 ICMP Attacks		5.2 ICMP Attacks
	ICMP messages may be subject to various attacks. A complete		ICMP messages may be subject to various attacks. A complete
	discussion can be found in the IP Security Architecture [IPv6-SA]. A		discussion can be found in the IP Security Architecture [IPv6-SA]. A
	brief discussion of such attacks and their prevention is as follows:		brief discussion of such attacks and their prevention is as follows:
	1. ICMP messages may be subject to actions intended to cause the		1. ICMP messages may be subject to actions intended to cause the
	receiver to believe the message came from a different source than		receiver to believe the message came from a different source than
	the message originator. The protection against this attack can be		the message originator. The protection against this attack can be
	skipping to change at page 21, line 5		skipping to change at page 20, line 27
	Parameter Problem Message to the multicast source causing a denial		Parameter Problem Message to the multicast source causing a denial
	of service attack. The way multicast traffic is forwarded by the		of service attack. The way multicast traffic is forwarded by the
	multicast routers does require the malicious node to be part of		multicast routers does require the malicious node to be part of
	the correct multicast path i.e. near to the multicast source.		the correct multicast path i.e. near to the multicast source.
	This attack can only be avoided by securing the multicast traffic.		This attack can only be avoided by securing the multicast traffic.
	The multicast source should be careful while sending multicast		The multicast source should be careful while sending multicast
	traffic with the destination options marked as mandatory because		traffic with the destination options marked as mandatory because
	they can cause a denial of service attack to themselves if the		they can cause a denial of service attack to themselves if the
	destination option is unknown to a large number of destinations.		destination option is unknown to a large number of destinations.
			6. As the ICMP messages are passed to the upper-layer processes, it
			is possible to perform attacks on the upper layer protocols (e.g.,
			TCP) with ICMP [TCP-attack]. It is recommended for the upper
			layers to perform some form of validation of ICMP messages (using
			the information contained in the payload of the ICMP message)
			before acting upon them. The actual validation checks are
			specific to the upper layers and are out of the scope of this
			spec. Protecting the upper layer with IPsec mitigates these
			attacks.
			ICMP error messages signal network error conditions that were
			encountered while processing an internet datagram. Depending on
			the particular scenario, the error conditions being reported might
			or might not get solved in the near term. Therefore, reaction to
			ICMP error messages may depend not only on the error type and
			code, but also on other factors such as the time the error
			messages are received, previous knowledge of the network error
			conditions being reported, and knowledge of the network scenario
			in which the receiving host is operating.
	6. IANA Considerations		6. IANA Considerations
	6.1 Procedure for new ICMPV6 Type and Code value assignments		6.1 Procedure for new ICMPV6 Type and Code value assignments
	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:
	skipping to change at page 23, line 16		skipping to change at page 23, line 16
	[IPv6-ADDR] Hinden, R., S. Deering, "IP Version 6 Addressing		[IPv6-ADDR] Hinden, R., S. Deering, "IP Version 6 Addressing
	Architecture", RFC2373, July 1998.		Architecture", RFC2373, July 1998.
	[PMTU] McCann, J., S. Deering, J. Mogul, "Path MTU Discovery		[PMTU] McCann, J., S. Deering, J. Mogul, "Path MTU Discovery
	for IP version 6", RFC1981, August 1996.		for IP version 6", RFC1981, August 1996.
	[IPv6-SA] Kent, S., R. Atkinson, "Security Architecture for the		[IPv6-SA] Kent, S., R. Atkinson, "Security Architecture for the
	Internet Protocol", RFC1825, November 1998.		Internet Protocol", RFC1825, November 1998.
	[IPv6-AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC		[IPv6-AUTH] Kent, S., "IP Authentication Header", draft-ietf-ipsec-
	2402, November 1998.		rfc2402bis-11.txt, work in progress.
	[IPv6-ESP] Kent, S., R. Atkinson, "IP Encapsulating Security		[IPv6-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
	Payload (ESP)", RFC 2406, November 1998.		draft-ietf-ipsec-esp-v3-10.txt, work in progress.
			[SEC-ARCH] Kent, S., K. Seo, "Security Architecture for the
			Internet Protocol", draft-ietf-ipsec-rfc2401bis-05.txt,
			work in progress.
			[TCP-attack] Gont, F., "ICMP attacks against TCP", draft-gont-tcpm-
			icmp-attacks-03.txt, work in progress.
	8. Acknowledgments		8. Acknowledgments
	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, Fred Templin and Elwyn davies (in
	provided extensive review information and feedback.		chronological order) provided extensive review information and
			feedback.
	Bob Hinden was the document editor for this document.		Bob Hinden was the document editor for this document.
	9. Authors' Addresses		9. Authors' Addresses
	Alex Conta		Alex Conta
	Transwitch Corporation		Transwitch Corporation
	3 Enterprise Drive		3 Enterprise Drive
	Shelton, CT 06484		Shelton, CT 06484
	USA		USA
	skipping to change at page 24, line 4		skipping to change at page 24, line 19
	3 Enterprise Drive		3 Enterprise Drive
	Shelton, CT 06484		Shelton, CT 06484
	USA		USA
	Email: aconta@txc.com		Email: aconta@txc.com
	Stephen Deering		Stephen Deering
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134-1706		San Jose, CA 95134-1706
	USA		USA
	Mukesh Gupta (ed.)		Mukesh Gupta (ed.)
	Nokia		Nokia
	313 Fairchild Drive		313 Fairchild Drive
	Mountain View, CA 94043		Mountain View, CA 94043
	USA		US
	Phone: +1 650-625-2264		Phone: +1 650-625-2264
	Email: mukesh.gupta@nokia.com		Email: mukesh.k.gupta@nokia.com
	Appendix A - Changes since 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.
	skipping to change at page 25, line 23		skipping to change at page 25, line 39
	Encapsulating Security Payload Header for authentication. Changed		Encapsulating Security Payload Header for authentication. Changed
	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". Also added a note
			that this document updates RFC-2780.
	- Added a procedure for new ICMPv6 Type and Code value assignments		- Added a procedure for new ICMPv6 Type and Code value assignments
	in the IANA Consideration section.		in the IANA Consideration section.
	- Replaced word "send" with "originate" to make it clear that ICMP		- Replaced word "send" with "originate" to make it clear that ICMP
	packets being forwarded are out of scope of this specification.		packets being forwarded are out of scope of this specification.
	Full Copyright Statement		- Changed the ESP and AH references to the updated ESP and AH
			drafts.
	Copyright (C) The Internet Society (2004). This document is subject		- Added reference to the updated IPsec Security Architecture draft.
	to the rights, licenses and restrictions contained in BCP 78 and
	except as set forth therein, the authors retain all their rights.
	This document and the information contained herein are provided on an		- Added a SHOULD requirement for allowing the sending of ICMP
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		destination unreachable messages to be disabled.
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		- Simplified the source address selection of the ICMPv6 packet.
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		- Reorganized the General Message Format (section 2.1).
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			- Removed the general packet format from section 2.1. It refers to
			section 3 and 4 for packet formats now.
			- Added text about attacks to the transport protocols that could
			potentially be caused by ICMP.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	skipping to change at page 26, line 24		skipping to change at page 26, line 42
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
	Acknowledgement		Disclaimer of Validity
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Copyright Statement
			Copyright (C) The Internet Society (2005). This document is subject
			to the rights, licenses and restrictions contained in BCP 78, and
			except as set forth therein, the authors retain all their rights.
			Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/