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

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/