draft-ietf-ipngwg-icmp-v3-02.txt   draft-ietf-ipngwg-icmp-v3-03.txt 
INTERNET-DRAFT A. Conta, Transwitch Internet Draft A. Conta, Transwitch
IPNG Working Group S. Deering, Cisco Systems IPv6 Working Group S. Deering, Cisco Systems
February 15, 2004
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-02.txt> <draft-ietf-ipngwg-icmp-v3-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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.
skipping to change at page 1, line 33 skipping to change at page 1, line 34
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 21, 2002. This internet draft will expire on August 20, 2004.
Abstract Abstract
This document specifies a set of Internet Control Message Protocol This document describes the format of a set of control messages used
(ICMP) messages for use with version 6 of the Internet Protocol in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the
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......................11 3.2 Packet Too Big Message......................11
3.3 Time Exceeded Message.......................12 3.3 Time Exceeded Message.......................12
3.4 Parameter Problem Message...................14 3.4 Parameter Problem Message...................14
4. ICMPv6 Informational Messages......................16 4. ICMPv6 Informational Messages......................16
4.1 Echo Request Message........................16 4.1 Echo Request Message........................16
4.2 Echo Reply Message..........................17 4.2 Echo Reply Message..........................17
5. Security Considerations............................19 5. Security Considerations............................19
6. IANA Considerations................................21
6. References.........................................21 7. References.........................................21
7.1 Normative...................................21
7. Acknowledgments....................................21 7.2 Informative.................................22
8. Acknowledgments....................................22
8. Authors' Addresses.................................22 9. Authors' Addresses.................................22
Appendix A - Changes since RFC 2463...................22 Appendix A - Changes since RFC 2463...................22
1. Introduction 1. Introduction
The Internet Protocol, version 6 (IPv6) is a new version of IP. IPv6 The Internet Protocol, version 6 (IPv6) is a new version of IP. IPv6
uses the Internet Control Message Protocol (ICMP) as defined for IPv4 uses the Internet Control Message Protocol (ICMP) as defined for IPv4
[RFC-792], with a number of changes. The resulting protocol is [RFC-792], with a number of changes. The resulting protocol is
called ICMPv6, and has an IPv6 Next Header value of 58. called ICMPv6, and has an IPv6 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
skipping to change at page 3, line 24 skipping to change at page 3, line 24
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
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].
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 MUST be fully implemented by every IPv6 node.
skipping to change at page 7, line 35 skipping to change at page 7, line 35
(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 sender 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 sending ICMPv6 error messages, an IPv6 node MUST limit incurred sending ICMPv6 error messages, an IPv6 node MUST limit
the rate of ICMPv6 error messages it sends. This situation may the rate of ICMPv6 error messages it sends. This situation may
occur when a source sending a stream of erroneous packets fails occur when a source sending a stream of erroneous packets fails
to heed the resulting ICMPv6 error messages. There are a variety to heed the resulting ICMPv6 error messages.
of ways of implementing the rate-limiting function, for example:
(f.1) Timer-based - for example, limiting the rate of
transmission of error messages to a given source, or to
any source, to at most once every T milliseconds.
(f.2) Bandwidth-based - for example, limiting the rate at which A recommended method for implementing the rate-limiting function
error messages are sent from a particular interface to is a token bucket, limiting the average rate of transmission to
some fraction F of the attached link's bandwidth. N, where N can either be packets/second or a fraction of the
attached link's bandwidth, but allowing up to B error messages
to be transmitted in a burst, as long as the long-term average
is not exceeded.
(f.3) Token-bucket based - for example, allowing up to B back- Rate-limiting mechanisms which cannot cope with bursty traffic
to-back error messages to be transmitted in a burst, but (e.g., traceroute) are not recommended; for example a simple
limiting the average rate of transmission to N messages timer-based implementation, allowing an error message every T
per second. milliseconds (even with low values for T), is not reasonable.
The limit parameters (e.g., T or F in the above examples) MUST The rate-limiting parameters SHOULD be configurable. In the
be configurable for the node, with a conservative default value case of a token-bucket implementation, the best defaults depend
(e.g., T = 0.5 second, NOT 0 seconds, or F = 2 percent, NOT 100 on where the implementation is expected to be deployed (e.g., a
percent). high-end router vs. an embedded host). For example, in a
small/mid -sized device, the possible defaults could be B=10,
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 SENDING 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
skipping to change at page 9, line 37 skipping to change at page 9, line 37
ICMPv6 Fields: ICMPv6 Fields:
Type 1 Type 1
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
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 sender
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
skipping to change at page 10, line 12 skipping to change at page 10, line 14
(NOTE: this error can occur only in nodes that do not hold a "default (NOTE: this error can occur only in nodes that do not hold a "default
route" in their routing tables). route" in their routing tables).
If the reason for the failure to deliver is administrative If the reason for the failure to deliver is administrative
prohibition, e.g., a "firewall filter", the Code field is set to 1. prohibition, e.g., a "firewall filter", the Code field is set to 1.
If the reason for the failure to deliver is that the destination is If the reason for the failure to deliver is that the destination is
beyond the scope of the source address, the Code field is set to 2. beyond the scope of the source address, the Code field is set to 2.
This condition can occur only when the scope of the source address is This condition can occur only when the scope of the source address is
smaller than the scope of the destination address (e.g., when a smaller than the scope of the destination address (e.g., when a
packet has a site-local source address and a global-scope destination packet has a link-local source address and a global-scope destination
address) and the packet cannot be delivered to the destination address) and the packet cannot be delivered to the destination
without leaving the scope of the source address (e.g., without without leaving the scope of the source address.
leaving the source's site, in the case of a site-local source
address).
If there is any other reason for the failure to deliver, e.g., If the reason for the failure to deliver can not be mapped to any of
inability to resolve the IPv6 destination address into a the specific codes listed above, the Code field is set to 3. The
corresponding link address, or a link-specific problem of some sort, example of such cases are inability to resolve the IPv6 destination
then the Code field is set to 3. address into a 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 send a Destination Unreachable message with
Code 4 in response to a packet for which the transport protocol 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
source address is not allowed due to ingress or egress filtering
policies, the Code field is set to 5.
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
occur if the router has been configured to reject all the traffic for
a specific prefix.
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.
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 19, line 7 skipping to change at page 19, line 7
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.
5. Security Considerations 5. Security Considerations
5.1 Authentication and Encryption 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]. A node SHOULD include an Authentication Header [IPv6-AUTH] or IP Encapsulating Security
Authentication Header when sending ICMP messages if a security Payload Header [IPv6-ESP]. Confidentiality for the ICMP protocol
association for use with the IP Authentication Header exists for the packet exchanges can be achieved using IP Encapsulating Security
Payload Header [IPv6-ESP]. A node SHOULD include an Authentication
Header or Encapsulating Security Payload Header when sending 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 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 Authentication Headers in ICMP packets MUST be verified for Received ICMP packets that have Authentication Header or
correctness and packets with incorrect authentication MUST be ignored Encapsulating Security Payload Header must be processed as specified
and discarded. in [IPv6-AUTH] and [IPv6-ESP]. The ICMP packets that fail the
security processing MUST be ignored and discarded.
It SHOULD be possible for the system administrator to configure a It SHOULD be possible for the system administrator to configure a
node to ignore any ICMP messages that are not authenticated using node to ignore any ICMP messages that are not authenticated using
either the Authentication Header or Encapsulating Security Payload. either the Authentication Header or Encapsulating Security Payload.
Such a switch SHOULD default to allowing unauthenticated messages. Such a switch SHOULD default to allowing unauthenticated messages.
Confidentiality issues are addressed by the IP Security Architecture
and the IP Encapsulating Security Payload documents [IPv6-SA,
IPv6-ESP].
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
achieved by applying the IPv6 Authentication mechanism [IPv6-AUTH] achieved by applying the IPv6 Authentication mechanism [IPv6-AUTH]
to the ICMP message. to the ICMP message.
2. ICMP messages may be subject to actions intended to cause the 2. ICMP messages may be subject to actions intended to cause the
message or the reply to it go to a destination different than the message or the reply to it go to a destination different than the
message originator's intention. The ICMP checksum calculation message originator's intention. The protection against this
provides a protection mechanism against changes by a malicious attack can be achieved by using the Authentication Header
interceptor in the destination and source address of the IP packet [IPv6-AUTH] or the Encapsulating Security Payload Header
carrying that message, provided the ICMP checksum field is [IPv6-ESP]. Authentication Header provides the protection against
protected against change by authentication [IPv6-AUTH] or change for the source and the destination address of the IP
encryption [IPv6-ESP] of the ICMP message. packet. Encapsulating Security Payload Header does not provide
this protection but the ICMP checksum calculation includes the
source and the destination addresses and the Encapsulating
Security Payload Header protects the checksum. Therefore, the
combination of ICMP checksum and the Encapsulating Security
Payload Header provides the protection against this attack. The
protection provided by the Encapsulating Security Payload Header
will not be as strong as the protection provided by the
Authentication Header.
3. ICMP messages may be subject to changes in the message fields, or 3. ICMP messages may be subject to changes in the message fields, or
payload. The authentication [IPv6-AUTH] or encryption [IPv6-ESP] payload. The authentication [IPv6-AUTH] or encryption [IPv6-ESP]
of the ICMP message is a protection against such actions. of the ICMP message is a protection against such actions.
4. ICMP messages may be used as attempts to perform denial of service 4. ICMP messages may be used as attempts to perform denial of service
attacks by sending back to back erroneous IP packets. An attacks by sending back to back erroneous IP packets. An
implementation that correctly followed section 2.4, paragraph (f) implementation that correctly followed section 2.4, paragraph (f)
of this specifications, would be protected by the ICMP error rate of this specifications, would be protected by the ICMP error rate
limiting mechanism. limiting mechanism.
6. References 5. The exception number 2 of rule e.3 in section 2.4 gives the
opportunity to a malicious node to cause a denial of service
attack to a multicast source. A malicious node can send a
multicast packet with an unknown destination option marked as
mandatory with the IPv6 source address of a valid multicast
source. A large number of destination nodes will send ICMP
Parameter Problem Message to the multicast source causing a denial
of service attack. The way multicast traffic is forwarded by the
multicast routers does require the malicious node to be part of
the correct multicast path i.e. near to the multicast source.
This attack can only be avoided by securing the multicast traffic.
The multicast source should be careful while sending multicast
traffic with the destination options marked as mandatory because
they can cause a denial of service attack to themselves if the
destination option is unknown to a large number of destinations.
6. IANA Considerations
IANA considerations for the values of ICMPv6 type and code are given
in [RFC-2780].
ICMPv6 type 1 "Destination Unreachable" code 2 that was unassigned in
[RFC-2463], has been assigned to "beyond scope of source address"
message.
IANA is requested to assign the following two new codes for ICMPv6
type 1 "Destination Unreachable".
5 - source address failed ingress/egress policy
6 - reject route to destination
7. References
7.1 Normative
[IPv6] Deering, S., R. Hinden, "Internet Protocol, Version 6, [IPv6] Deering, S., R. Hinden, "Internet Protocol, Version 6,
Specification", RFC2460, December 1998. Specification", RFC2460, December 1998.
[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.
[IPv6-DISC] Narten, T., E. Nordmark, W. Simpson, "Neighbor Discovery [IPv6-DISC] Narten, T., E. Nordmark, W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC2461, December, 1998. for IP Version 6 (IPv6)", RFC2461, December, 1998.
[RFC-792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC-792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC792, September 1981. RFC792, September 1981.
[RFC-2463] Conta, A., S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC2463, December, 1998.
[RFC-1122] Braden, R., "Requirements for Internet Hosts - [RFC-1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 5, RFC1122, August 1989. Communication Layers", STD 5, RFC1122, August 1989.
[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.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP14, RFC2119, March 1997. Requirement Levels", BCP14, RFC2119, March 1997.
[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., R. Atkinson, "IP Authentication Header", RFC
2402, November 1998. 2402, November 1998.
[IPv6-ESP] Kent, S., R. Atkinson, "IP Encapsulating Security [IPv6-ESP] Kent, S., R. Atkinson, "IP Encapsulating Security
Protocol (ESP)", RFC 2406, November 1998. Payload (ESP)", RFC 2406, November 1998.
7. Acknowledgments 7.2 Informative
[RFC-2780] Bradner, S., V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers",
RFC 2780, March 2000.
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,
and Brian Zill (in chronological order) provided extensive review Brian Zill, Pekka Savola, and Fred Templin (in chronological order)
information and feedback. provided extensive review information and feedback.
Bob Hinden was the document editor for this document. Mukesh Gupta and Bob Hinden were the document editors for this
document.
8. Authors' Addresses 9. Authors' Addresses
Alex Conta Stephen Deering Alex Conta Stephen Deering
Transwitch Corporation Cisco Systems, Inc. Transwitch Corporation Cisco Systems, Inc.
3 Enterprise Drive 170 West Tasman Drive 3 Enterprise Drive 170 West Tasman Drive
Shelton, CT 06484 San Jose, CA 95134-1706 Shelton, CT 06484 San Jose, CA 95134-1706
US US US US
phone: +1 408 527-8213 email: aconta@txc.com
email: aconta@txc.com email: deering@cisco.com
Appendix A - Changes from RFC 2463 Appendix A - Changes from 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.
- 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.
- Added token-bucket method as an example rate-limiting mechanism - Removed the Timer-based and the Bandwidth-based methods from the
for ICMP error messages, and changed default value for the fixed example rate-limiting mechanism for ICMP error messages. Added
timer approach, parameter T, from 1 second to 0.5 second. Token-bucket based method.
- Added specification that all ICMP error messages shall have - Added specification that all ICMP error messages shall have
exactly 32 bits of type-specific data, so that receivers can exactly 32 bits of type-specific data, so that receivers can
reliably find the embedded invoking packet even when they don't reliably find the embedded invoking packet even when they don't
recognize the ICMP message Type. recognize the ICMP message Type.
- In the description of Destination Unreachable messages, Code 3, - In the description of Destination Unreachable messages, Code 3,
added rule prohibiting forwarding of packets back onto point-to- added rule prohibiting forwarding of packets back onto point-to-
point links from which they were received, if their destination point links from which they were received, if their destination
addresses belong to the link itself ("anti-ping-ponging" rule). addresses belong to the link itself ("anti-ping-ponging" rule).
- Added description of Time Exceeded Code 1 (fragment reassembly - Added description of Time Exceeded Code 1 (fragment reassembly
timeout). timeout).
- Added "beyond scope of source address" message to the family of - Added "beyond scope of source address", "source address failed
"unreachable destination" type ICMP error messages (section 3.1). ingress/egress policy", and "reject route to destination" messages
to the family of "unreachable destination" type ICMP error
messages (section 3.1).
- Added a NOTE in section 2.4, that specifies ICMP message - Added a NOTE in section 2.4, that specifies ICMP message
processing rules precedence. processing rules precedence.
- Added ICMP REDIRECT to the list in Section 2.4 e) of cases in - Added ICMP REDIRECT to the list in Section 2.4 e) of cases in
which ICMP error messages are not to be generated. which ICMP error messages are not to be generated.
- Made minor editorial changes in Section 2.3 on checksum - Made minor editorial changes in Section 2.3 on checksum
calculation, and in Section 5.2. calculation, and in Section 5.2.
- Clarified in section 4.2, regarding the Echo Reply Message, that - Clarified in section 4.2, regarding the Echo Reply Message, that
the source address of an Echo Reply to an anycast Echo Request the source address of an Echo Reply to an anycast Echo Request
should be a unicast address, as in the case of multicast. should be a unicast address, as in the case of multicast.
- Revised the Security Considerations section. Added the use of
Encapsulating Security Payload Header for authentication.
- Added a new attack in the list of possible ICMP attacks in section
5.2.
- Separated References into Normative and Informative.
- Added reference to RFC-2780 "IANA Allocation Guidelines For Values
In the Internet Protocol and Related Headers"
 End of changes. 

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