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/