draft-ietf-ipngwg-icmp-v3-05.txt   draft-ietf-ipngwg-icmp-v3-06.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
21 October 2004 M. Gupta, Nokia (ed.) 18 November 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-05.txt> <draft-ietf-ipngwg-icmp-v3-06.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 35 skipping to change at page 1, line 36
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 April 21, 2004. This internet draft will expire on May 18, 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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
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................................................23
7.2 Informative..............................................24 7.2 Informative..............................................24
8. Acknowledgments.................................................24 8. Acknowledgments.................................................24
9. Authors' Addresses..............................................24 9. Authors' Addresses..............................................24
Appendix A - Changes since RFC 2463................................24 Appendix A - Changes since RFC 2463................................24
1. Introduction 1. Introduction
The Internet Protocol, version 6 (IPv6) is a new version of IP. IPv6 The Internet Protocol, version 6 (IPv6) uses the Internet Control
uses the Internet Control Message Protocol (ICMP) as defined for IPv4 Message Protocol (ICMP) as defined for IPv4 [RFC-792], with a number
[RFC-792], with a number of changes. The resulting protocol is of changes. The resulting protocol is called ICMPv6, and has an IPv6
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 achieve functions like Path MTU discovery; such
procedures are described in other documents (e.g., [PMTU]). Other procedures are described in other documents (e.g., [PMTU]). Other
documents may also introduce additional ICMPv6 message types, such as documents may also introduce additional ICMPv6 message types, such as
Neighbor Discovery messages [IPv6-DISC], subject to the general rules Neighbor Discovery messages [IPv6-DISC], subject to the general rules
for ICMPv6 messages given in section 2 of this document. for 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
skipping to change at page 5, line 41 skipping to change at page 5, line 41
| 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 possible 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 originates an ICMPv6 message has to determine both the
and Destination IPv6 Addresses in the IPv6 header before calculating Source and Destination IPv6 Addresses in the IPv6 header before
the checksum. If the node has more than one unicast address, it MUST calculating the checksum. If the node has more than one unicast
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 a multicast or
anycast group in which the node is a member, the Source Address anycast group in which the node is a member, the Source Address
of the reply MUST be a unicast address belonging to the of the reply MUST be a unicast address belonging to the
interface on which the multicast or anycast packet was received. interface on which the multicast or anycast packet was received.
skipping to change at page 7, line 11 skipping to change at page 7, line 11
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
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 In the cases where it is not possible to retrieve the upper-
extension headers, it is possible that the upper-layer protocol layer protocol type from the ICMPv6 message, the ICMPv6 message
type may not be present in the ICMPv6 message, due to truncation is silently dropped after any IPv6-layer processing. One
of the original packet to meet the minimum IPv6 MTU [IPv6] example of such a case is an ICMPv6 message with unusually large
limit. In that case, the error message is silently dropped amount of extension headers that does not have the upper-layer
after any IPv6-layer processing. protocol type due to truncation of the original packet to meet
the minimum IPv6 MTU [IPv6] limit. Another example of such a
case is an ICMPv6 message with ESP extension header where it is
not possible to decrypt the original packet due to either
truncation or the unavailability of the state necessary to
decrypt the packet.
(e) An ICMPv6 error message MUST NOT be sent as a result of (e) An ICMPv6 error message MUST NOT be originated as a result of
receiving: receiving:
(e.1) an ICMPv6 error message, or (e.1) an ICMPv6 error message, or
(e.2) an ICMPv6 redirect message [IPv6-DISC], or (e.2) an ICMPv6 redirect message [IPv6-DISC], or
(e.3) a packet destined to an IPv6 multicast address (there are (e.3) a packet destined to an IPv6 multicast address (there are
two exceptions to this rule: (1) the Packet Too Big two exceptions to this rule: (1) the Packet Too Big
Message - Section 3.2 - to allow Path MTU discovery to Message - Section 3.2 - to allow Path MTU discovery to
work for IPv6 multicast, and (2) the Parameter Problem work for IPv6 multicast, and (2) the Parameter Problem
Message, Code 2 - Section 3.4 - reporting an unrecognized Message, Code 2 - Section 3.4 - reporting an unrecognized
IPv6 option that has the Option Type highest-order two IPv6 option (see section 4.2 of [IPv6]) that has the
bits set to 10), or Option Type highest-order two bits set to 10), or
(e.4) a packet sent as a link-layer multicast, (the exception (e.4) a packet sent as a link-layer multicast, (the exceptions
from e.3 applies to this case too), or from e.3 apply to this case too), or
(e.5) a packet sent as a link-layer broadcast, (the exception (e.5) a packet sent as a link-layer broadcast, (the exceptions
from e.3 applies to this case too), or from e.3 apply to this case too), or
(e.6) a packet whose source address does not uniquely identify (e.6) a packet whose source address does not uniquely identify
a single node -- e.g., the IPv6 Unspecified Address, an a single node -- e.g., the IPv6 Unspecified Address, an
IPv6 multicast address, or an address known by the ICMP IPv6 multicast address, or an address known by the ICMP
message sender to be an IPv6 anycast address. message originator to be an IPv6 anycast address.
(f) Finally, in order to limit the bandwidth and forwarding costs (f) Finally, in order to limit the bandwidth and forwarding costs
incurred by sending ICMPv6 error messages, an IPv6 node MUST incurred by originating ICMPv6 error messages, an IPv6 node MUST
limit the rate of ICMPv6 error messages it sends. This limit the rate of ICMPv6 error messages it originates. This
situation may occur when a source sending a stream of erroneous situation may occur when a source sending a stream of erroneous
packets fails to heed the resulting ICMPv6 error messages. packets fails to heed the resulting ICMPv6 error messages.
Rate-limiting of forwarded ICMP messages is out of scope of this
specification.
A recommended method for implementing the rate-limiting function A recommended method for implementing the rate-limiting function
is a token bucket, limiting the average rate of transmission to is a token bucket, limiting the average rate of transmission to
N, where N can either be packets/second or a fraction of the N, where N can either be packets/second or a fraction of the
attached link's bandwidth, but allowing up to B error messages attached link's bandwidth, but allowing up to B error messages
to be transmitted in a burst, as long as the long-term average to be transmitted in a burst, as long as the long-term average
is not exceeded. is not exceeded.
Rate-limiting mechanisms which cannot cope with bursty traffic Rate-limiting mechanisms which cannot cope with bursty traffic
(e.g., traceroute) are not recommended; for example a simple (e.g., traceroute) are not recommended; for example a simple
timer-based implementation, allowing an error message every T timer-based implementation, allowing an error message every T
milliseconds (even with low values for T), is not reasonable. milliseconds (even with low values for T), is not reasonable.
The rate-limiting parameters SHOULD be configurable. In the The rate-limiting parameters SHOULD be configurable. In the
case of a token-bucket implementation, the best defaults depend case of a token-bucket implementation, the best defaults depend
on where the implementation is expected to be deployed (e.g., a on where the implementation is expected to be deployed (e.g., a
high-end router vs. an embedded host). For example, in a high-end router vs. an embedded host). For example, in a
small/mid -sized device, the possible defaults could be B=10, small/mid -sized device, the possible defaults could be B=10,
N=10/s. N=10/s.
NOTE: THE RESTRICTIONS UNDER (e) AND (f) ABOVE TAKE PRECEDENCE OVER NOTE: THE RESTRICTIONS UNDER (e) AND (f) ABOVE TAKE PRECEDENCE OVER
ANY REQUIREMENT ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR ANY REQUIREMENT ELSEWHERE IN THIS DOCUMENT FOR ORIGINATING ICMP ERROR
MESSAGES. MESSAGES.
The following sections describe the message formats for the above The following sections describe the message formats for the above
ICMPv6 messages. ICMPv6 messages.
3. ICMPv6 Error Messages 3. ICMPv6 Error Messages
3.1 Destination Unreachable Message 3.1 Destination Unreachable Message
0 1 2 3 0 1 2 3
skipping to change at page 9, line 41 skipping to change at page 9, line 41
Code 0 - no route to destination Code 0 - no route to destination
1 - communication with destination 1 - communication with destination
administratively prohibited administratively prohibited
2 - beyond scope of source address 2 - beyond scope of source address
3 - address unreachable 3 - address unreachable
4 - port unreachable 4 - port 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
Unused This field is unused for all code values. Unused This field is unused for all code values.
It must be initialized to zero by the sender It must be initialized to zero by the originator
and ignored by the receiver. and ignored by the receiver.
Description Description
A Destination Unreachable message SHOULD be generated by a router, or A Destination Unreachable message SHOULD be generated by a router, or
by the IPv6 layer in the originating node, in response to a packet by the IPv6 layer in the originating node, in response to a packet
that cannot be delivered to its destination address for reasons other that cannot be delivered to its destination address for reasons other
than congestion. (An ICMPv6 message MUST NOT be generated if a than congestion. (An ICMPv6 message MUST NOT be generated if a
packet is dropped due to congestion.) packet is dropped due to congestion.)
If the reason for the failure to deliver is lack of a matching entry If the reason for the failure to deliver is lack of a matching entry
skipping to change at page 10, line 30 skipping to change at page 10, line 30
are inability to resolve the IPv6 destination address into a are inability to resolve the IPv6 destination address into a
corresponding link address, or a link-specific problem of some sort. corresponding link address, or a link-specific problem of some sort.
One specific case in which a Destination Unreachable message with a One specific case in which a Destination Unreachable message with a
code 3 is sent is in response to a packet received by a router from a code 3 is sent is in response to a packet received by a router from a
point-to-point link, destined to an address within a subnet assigned point-to-point link, destined to an address within a subnet assigned
to that same link (other than one of the receiving router's own to that same link (other than one of the receiving router's own
addresses). In such a case, the packet MUST NOT be forwarded back addresses). In such a case, the packet MUST NOT be forwarded back
onto the arrival link. onto the arrival link.
A destination node SHOULD send a Destination Unreachable message with A destination node SHOULD originate a Destination Unreachable message
Code 4 in response to a packet for which the transport protocol with Code 4 in response to a packet for which the transport protocol
(e.g., UDP) has no listener, if that transport protocol has no (e.g., UDP) has no listener, if that transport protocol has no
alternative means to inform the sender. alternative means to inform the sender.
If the reason for the failure to deliver is that packet with this If the reason for the failure to deliver is that packet with this
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.
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. notify the upper-layer process if the relevant process can be
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | | MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 29 skipping to change at page 11, line 29
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:
Type 2 Type 2
Code Set to 0 (zero) by the sender and ignored by the Code Set to 0 (zero) by the originator and ignored by the
receiver receiver
MTU The Maximum Transmission Unit of the next-hop link. MTU The Maximum Transmission Unit of the next-hop link.
Description Description
A Packet Too Big MUST be sent by a router in response to a packet A Packet Too Big MUST be sent by a router in response to a packet
that it cannot forward because the packet is larger than the MTU of that it cannot forward because the packet is larger than the MTU of
the outgoing link. The information in this message is used as part the outgoing link. The information in this message is used as part
of the Path MTU Discovery process [PMTU]. of the Path MTU Discovery process [PMTU].
Sending a Packet Too Big Message makes an exception to one of the Originating a Packet Too Big Message makes an exception to one of the
rules of when to send an ICMPv6 error message, in that unlike other rules of when to originate an ICMPv6 error message, in that unlike
messages, it is sent in response to a packet received with an IPv6 other messages, it is sent in response to a packet received with an
multicast destination address, or a link-layer multicast or link- IPv6 multicast destination address, or a link-layer multicast or
layer broadcast address. link-layer broadcast address.
Upper layer notification Upper layer notification
An incoming Packet Too Big message MUST be passed to the upper-layer An incoming Packet Too Big message MUST be passed to the upper-layer
process. process if the relevant process can be identified (see section
2.4(d)).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 33 skipping to change at page 12, line 33
ICMPv6 Fields: ICMPv6 Fields:
Type 3 Type 3
Code 0 - hop limit exceeded in transit Code 0 - hop limit exceeded in transit
1 - fragment reassembly time exceeded 1 - fragment reassembly time exceeded
Unused This field is unused for all code values. Unused This field is unused for all code values.
It must be initialized to zero by the sender It must be initialized to zero by the originator
and ignored by the receiver. and ignored by the receiver.
Description Description
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 send an ICMPv6 Time Exceeded message with Code 0 to the source of and originate an ICMPv6 Time Exceeded message with Code 0 to the
the packet. This indicates either a routing loop or too small an source of the packet. This indicates either a routing loop or too
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 The rules for selecting the Source Address of this message are
defined in section 2.2. 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. process if the relevant process can be identified (see section
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pointer | | Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 46 skipping to change at page 14, line 46
invoking packet where the error was detected. invoking packet where the error was detected.
The pointer will point beyond the end of the ICMPv6 The pointer will point beyond the end of the ICMPv6
packet if the field in error is beyond what can fit packet if the field in error is beyond what can fit
in the maximum size of an ICMPv6 error message. in the maximum size of an ICMPv6 error message.
Description Description
If an IPv6 node processing a packet finds a problem with a field in If an IPv6 node processing a packet finds a problem with a field in
the IPv6 header or extension headers such that it cannot complete the IPv6 header or extension headers such that it cannot complete
processing the packet, it MUST discard the packet and SHOULD send an processing the packet, it MUST discard the packet and SHOULD
ICMPv6 Parameter Problem message to the packet's source, indicating originate an ICMPv6 Parameter Problem message to the packet's source,
the type and location of the problem. indicating the type and location of the problem.
Codes 1 and 2 are more informative subsets of Code 0.
The pointer identifies the octet of the original packet's header The pointer identifies the octet of the original packet's header
where the error was detected. For example, an ICMPv6 message with where the error was detected. For example, an ICMPv6 message with
Type field = 4, Code field = 1, and Pointer field = 40 would indicate Type field = 4, Code field = 1, and Pointer field = 40 would indicate
that the IPv6 extension header following the IPv6 header of the that the IPv6 extension header following the IPv6 header of the
original packet holds an unrecognized Next Header field value. original packet holds an unrecognized Next Header field value.
Upper layer notification Upper layer notification
A node receiving this ICMPv6 message MUST notify the upper-layer A node receiving this ICMPv6 message MUST notify the upper-layer
process. process if the relevant process can be identified (see section
2.4(d)).
4. ICMPv6 Informational Messages 4. ICMPv6 Informational Messages
4.1 Echo Request Message 4.1 Echo Request 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 44 skipping to change at page 16, line 44
Sequence Number Sequence Number
A sequence number to aid in matching Echo Replies A sequence number to aid in matching Echo Replies
to this Echo Request. May be zero. to this Echo Request. May be zero.
Data Zero or more octets of arbitrary data. Data Zero or more octets of arbitrary data.
Description Description
Every node MUST implement an ICMPv6 Echo responder function that Every node MUST implement an ICMPv6 Echo responder function that
receives Echo Requests and sends corresponding Echo Replies. A node receives Echo Requests and originates corresponding Echo Replies. A
SHOULD also implement an application-layer interface for sending Echo node SHOULD also implement an application-layer interface for
Requests and receiving Echo Replies, for diagnostic purposes. originating Echo Requests and receiving Echo Replies, for diagnostic
purposes.
Upper layer notification Upper layer notification
Echo Request messages MAY be passed to processes receiving ICMP Echo Request messages MAY be passed to processes receiving ICMP
messages. messages.
4.2 Echo Reply Message 4.2 Echo Reply 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 17, line 40 skipping to change at page 17, line 40
Identifier The identifier from the invoking Echo Request message. Identifier The identifier from the invoking Echo Request message.
Sequence The sequence number from the invoking Echo Request Sequence The sequence number from the invoking Echo Request
Number message. Number message.
Data The data from the invoking Echo Request message. Data The data from the invoking Echo Request message.
Description Description
Every node MUST implement an ICMPv6 Echo responder function that Every node MUST implement an ICMPv6 Echo responder function that
receives Echo Requests and sends corresponding Echo Replies. A node receives Echo Requests and originates corresponding Echo Replies. A
SHOULD also implement an application-layer interface for sending Echo node SHOULD also implement an application-layer interface for
Requests and receiving Echo Replies, for diagnostic purposes. originating Echo Requests and receiving Echo Replies, for diagnostic
purposes.
The source address of an Echo Reply sent in response to a unicast The source address of an Echo Reply sent in response to a unicast
Echo Request message MUST be the same as the destination address of Echo Request message MUST be the same as the destination address of
that Echo Request message. that Echo Request message.
An Echo Reply SHOULD be sent in response to an Echo Request message An Echo Reply SHOULD be sent in response to an Echo Request message
sent to an IPv6 multicast or anycast address. In this case, the sent to an IPv6 multicast or anycast address. In this case, the
source address of the reply MUST be a unicast address belonging to source address of the reply MUST be a unicast address belonging to
the interface on which the Echo Request message was received. the interface on which the Echo Request message was received.
skipping to change at page 19, line 14 skipping to change at page 19, line 14
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]. A node SHOULD include an Authentication
Header or Encapsulating Security Payload Header when sending ICMP Header or Encapsulating Security Payload Header when originating ICMP
messages if a security association for use with the IP Authentication messages if a security association for use with the IP Authentication
Header or IP Encapsulating Security Payload Header exists for the Header or IP Encapsulating Security Payload Header exists for the
destination address. The security associations may have been created destination address. The security associations may have been created
through manual configuration or through the operation of some key through manual configuration or through the operation of some key
management protocol. management protocol.
Received ICMP packets that have Authentication Header or Received ICMP packets that have Authentication Header or
Encapsulating Security Payload Header must be processed as specified Encapsulating Security Payload Header must be processed as specified
in [IPv6-AUTH] and [IPv6-ESP]. The ICMP packets that fail the in [IPv6-AUTH] and [IPv6-ESP]. The ICMP packets that fail the
security processing MUST be ignored and discarded. security processing MUST be ignored and discarded.
skipping to change at page 25, line 27 skipping to change at page 25, line 27
- 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 - 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
packets being forwarded are out of scope of this specification.
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/