doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc4443.txt b/doc/rfc/rfc4443.txt
new file mode 100644
index 0000000..7f3d485
--- /dev/null
+++ b/doc/rfc/rfc4443.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group                                           A. Conta
+Request for Comments: 4443                                    Transwitch
+Obsoletes: 2463                                               S. Deering
+Updates: 2780                                              Cisco Systems
+Category: Standards Track                                  M. Gupta, Ed.
+                                                         Tropos Networks
+                                                              March 2006
+
+
+               Internet Control Message Protocol (ICMPv6)
+        for the Internet Protocol Version 6 (IPv6) Specification
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes the format of a set of control messages used
+   in ICMPv6 (Internet Control Message Protocol).  ICMPv6 is the
+   Internet Control Message Protocol for Internet Protocol version 6
+   (IPv6).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                     [Page 1]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+Table of Contents
+
+
+   1. Introduction ....................................................2
+   2. ICMPv6 (ICMP for IPv6) ..........................................3
+      2.1. Message General Format .....................................3
+      2.2. Message Source Address Determination .......................5
+      2.3. Message Checksum Calculation ...............................5
+      2.4. Message Processing Rules ...................................5
+   3. ICMPv6 Error Messages ...........................................8
+      3.1. Destination Unreachable Message ............................8
+      3.2. Packet Too Big Message ....................................10
+      3.3. Time Exceeded Message .....................................11
+      3.4. Parameter Problem Message .................................12
+   4. ICMPv6 Informational Messages ..................................13
+      4.1. Echo Request Message ......................................13
+      4.2. Echo Reply Message ........................................14
+   5. Security Considerations ........................................15
+      5.1. Authentication and Confidentiality of ICMP Messages .......15
+      5.2. ICMP Attacks ..............................................16
+   6. IANA Considerations ............................................17
+      6.1. Procedure for New ICMPV6 Type and Code Value Assignments ..17
+      6.2. Assignments for This Document .............................18
+   7. References .....................................................19
+      7.1. Normative References ......................................19
+      7.2. Informative References ....................................19
+   8. Acknowledgements ...............................................20
+   Appendix A - Changes since RFC 2463................................21
+
+1. Introduction
+
+   The Internet Protocol version 6 (IPv6) uses the Internet Control
+   Message Protocol (ICMP) as defined for IPv4 [RFC-792], with a number
+   of changes.  The resulting protocol is called ICMPv6 and has an IPv6
+   Next Header value of 58.
+
+   This document describes the format of a set of control messages used
+   in ICMPv6.  It does not describe the procedures for using these
+   messages to achieve functions like Path MTU discovery; these
+   procedures are described in other documents (e.g., [PMTU]).  Other
+   documents may also introduce additional ICMPv6 message types, such as
+   Neighbor Discovery messages [IPv6-DISC], subject to the general rules
+   for ICMPv6 messages given in Section 2 of this document.
+
+   Terminology defined in the IPv6 specification [IPv6] and the IPv6
+   Routing and Addressing specification [IPv6-ADDR] applies to this
+   document as well.
+
+
+
+
+Conta, et al.               Standards Track                     [Page 2]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+   This document obsoletes RFC 2463 [RFC-2463] and updates RFC 2780
+   [RFC-2780].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC-2119].
+
+2. ICMPv6 (ICMP for IPv6)
+
+   ICMPv6 is used by IPv6 nodes to report errors encountered in
+   processing packets, and to perform other internet-layer functions,
+   such as diagnostics (ICMPv6 "ping").  ICMPv6 is an integral part of
+   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
+
+   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.  (This is
+   different from 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
+   informational messages.  Error messages are identified as such by a
+   zero in the high-order bit of their message Type field values.  Thus,
+   error messages have message types from 0 to 127; informational
+   messages have message types from 128 to 255.
+
+
+
+
+Conta, et al.               Standards Track                     [Page 3]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+   This document defines the message formats for the following ICMPv6
+   messages:
+
+      ICMPv6 error messages:
+
+          1    Destination Unreachable      (see Section 3.1)
+          2    Packet Too Big               (see Section 3.2)
+          3    Time Exceeded                (see Section 3.3)
+          4    Parameter Problem            (see Section 3.4)
+
+          100  Private experimentation
+          101  Private experimentation
+
+          127  Reserved for expansion of ICMPv6 error messages
+
+      ICMPv6 informational messages:
+
+          128  Echo Request                 (see Section 4.1)
+          129  Echo Reply                   (see Section 4.2)
+
+          200  Private experimentation
+          201  Private experimentation
+
+          255  Reserved for expansion of ICMPv6 informational messages
+
+   Type values 100, 101, 200, and 201 are reserved for private
+   experimentation.  They are not intended for general use.  It is
+   expected that multiple concurrent experiments will be done with the
+   same type values.  Any wide-scale and/or uncontrolled usage should
+   obtain real allocations as defined in Section 6.
+
+   Type values 127 and 255 are reserved for future expansion of the type
+   value range if there is a shortage in the future.  The details of
+   this are left for future work.  One possible way of doing this that
+   would not cause any problems with current implementations is that if
+   the type equals 127 or 255, the code field should be used for the new
+   assignment.  Existing implementations would ignore the new
+   assignments as specified in Section 2.4, (b).  The new messages using
+   these expanded type values could assign fields in the message body
+   for its code values.
+
+   Sections 3 and 4 describe the message formats for the ICMPv6 error
+   message types 1 through 4 and informational message types 128 and
+   129.
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                     [Page 4]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+   Inclusion of, at least, the start of the invoking packet is intended
+   to allow the originator of a packet that has resulted in an ICMPv6
+   error message to identify the upper-layer protocol and process that
+   sent the packet.
+
+2.2.  Message Source Address Determination
+
+   A node that originates an ICMPv6 message has to determine both the
+   Source and Destination IPv6 Addresses in the IPv6 header before
+   calculating the checksum.  If the node has more than one unicast
+   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
+       node's unicast addresses, the Source Address of the reply MUST be
+       that same address.
+
+   (b) If the message is a response to a message sent to any other
+       address, such as
+
+       - a multicast group address,
+       - an anycast address implemented by the node, or
+       - a unicast address that does not belong to the node
+
+      the Source Address of the ICMPv6 packet MUST be a unicast address
+      belonging to the node.  The address SHOULD be chosen according to
+      the rules that would be used to select the source address for any
+      other packet originated by the node, given the destination address
+      of the packet.  However, it MAY be selected in an alternative way
+      if this would lead to a more informative choice of address
+      reachable from the destination of the ICMPv6 packet.
+
+2.3.  Message Checksum Calculation
+
+   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
+   type field, and prepended with a "pseudo-header" of IPv6 header
+   fields, as specified in [IPv6, Section 8.1].  The Next Header value
+   used in the pseudo-header is 58.  (The inclusion of a pseudo-header
+   in the ICMPv6 checksum is a change from IPv4; see [IPv6] for the
+   rationale for this change.)
+
+   For computing the checksum, the checksum field is first set to zero.
+
+2.4.  Message Processing Rules
+
+   Implementations MUST observe the following rules when processing
+   ICMPv6 messages (from [RFC-1122]):
+
+
+
+
+Conta, et al.               Standards Track                     [Page 5]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+   (a) If an ICMPv6 error message of unknown type is received at its
+       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,
+       it MUST be silently discarded.
+
+   (c) Every ICMPv6 error message (type < 128) MUST include as much of
+       the IPv6 offending (invoking) packet (the packet that caused the
+       error) as possible without making the error message packet exceed
+       the minimum IPv6 MTU [IPv6].
+
+   (d) In cases where the internet-layer protocol is required to pass an
+       ICMPv6 error message to the upper-layer process, the upper-layer
+       protocol type is extracted from the original packet (contained in
+       the body of the ICMPv6 error message) and used to select the
+       appropriate upper-layer process to handle the error.
+
+       In cases where it is not possible to retrieve the upper-layer
+       protocol type from the ICMPv6 message, the ICMPv6 message is
+       silently dropped after any IPv6-layer processing.  One example of
+       such a case is an ICMPv6 message with an unusually large amount
+       of extension headers that does not have the upper-layer protocol
+       type due to truncation of the original packet to meet the minimum
+       IPv6 MTU [IPv6] limit.  Another example is an ICMPv6 message with
+       an ESP extension header for which 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 originated as a result of
+       receiving the following:
+
+       (e.1) An ICMPv6 error message.
+
+       (e.2) An ICMPv6 redirect message [IPv6-DISC].
+
+       (e.3) A packet destined to an IPv6 multicast address.  (There are
+             two exceptions to this rule: (1) the Packet Too Big Message
+             (Section 3.2) to allow Path MTU discovery to work for IPv6
+             multicast, and (2) the Parameter Problem Message, Code 2
+             (Section 3.4) reporting an unrecognized IPv6 option (see
+             Section 4.2 of [IPv6]) that has the Option Type highest-
+             order two bits set to 10).
+
+       (e.4) A packet sent as a link-layer multicast (the exceptions
+             from e.3 apply to this case, too).
+
+
+
+
+Conta, et al.               Standards Track                     [Page 6]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+       (e.5) A packet sent as a link-layer broadcast (the exceptions
+             from e.3 apply to this case, too).
+
+       (e.6) A packet whose source address does not uniquely identify a
+             single node -- e.g., the IPv6 Unspecified Address, an IPv6
+             multicast address, or an address known by the ICMP message
+             originator to be an IPv6 anycast address.
+
+   (f) Finally, in order to limit the bandwidth and forwarding costs
+       incurred by originating ICMPv6 error messages, an IPv6 node MUST
+       limit the rate of ICMPv6 error messages it originates.  This
+       situation may occur when a source sending a stream of erroneous
+       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
+       is a token bucket, limiting the average rate of transmission to
+       N, where N can be either 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.
+
+       Rate-limiting mechanisms that cannot cope with bursty traffic
+       (e.g., traceroute) are not recommended; for example, a simple
+       timer-based implementation, allowing an error message every T
+       milliseconds (even with low values for T), is not reasonable.
+
+       The rate-limiting parameters SHOULD be configurable.  In the case
+       of a token-bucket implementation, the best defaults depend on
+       where the implementation is expected to be deployed (e.g., a
+       high-end router vs. an embedded host).  For example, in a
+       small/mid-size device, the possible defaults could be B=10,
+       N=10/s.
+
+   NOTE: THE RESTRICTIONS UNDER (e) AND (f) ABOVE TAKE PRECEDENCE OVER
+   ANY REQUIREMENT ELSEWHERE IN THIS DOCUMENT FOR ORIGINATING ICMP ERROR
+   MESSAGES.
+
+   The following sections describe the message formats for the above
+   ICMPv6 messages.
+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                     [Page 7]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+3. ICMPv6 Error Messages
+
+3.1.  Destination Unreachable Message
+
+       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             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             Unused                            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    As much of invoking packet                 |
+      +                as possible without the ICMPv6 packet          +
+      |                exceeding the minimum IPv6 MTU [IPv6]          |
+
+   IPv6 Fields:
+
+   Destination Address
+
+                  Copied from the Source Address field of the invoking
+                  packet.
+
+   ICMPv6 Fields:
+
+   Type           1
+
+   Code           0 - No route to destination
+                  1 - Communication with destination
+                        administratively prohibited
+                  2 - Beyond scope of source address
+                  3 - Address 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.
+                  It must be initialized to zero by the originator
+                  and ignored by the receiver.
+   Description
+
+   A Destination Unreachable message SHOULD be generated by a router, or
+   by the IPv6 layer in the originating node, in response to a packet
+   that cannot be delivered to its destination address for reasons other
+   than congestion.  (An ICMPv6 message MUST NOT be generated if a
+   packet is dropped due to congestion.)
+
+   If the reason for the failure to deliver is lack of a matching entry
+   in the forwarding node's routing table, the Code field is set to 0.
+
+
+
+Conta, et al.               Standards Track                     [Page 8]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+   (This error can occur only in nodes that do not hold a "default
+   route" in their routing tables.)
+
+   If the reason for the failure to deliver is administrative
+   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
+   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
+   smaller than the scope of the destination address (e.g., when a
+   packet has a link-local source address and a global-scope destination
+   address) and the packet cannot be delivered to the destination
+   without leaving the scope of the source address.
+
+   If the reason for the failure to deliver cannot be mapped to any of
+   other codes, the Code field is set to 3.  Example of such cases are
+   an inability to resolve the IPv6 destination address into a
+   corresponding link address, or a link-specific problem of some sort.
+
+   One specific case in which a Destination Unreachable message is sent
+   with a code 3 is in response to a packet received by a router from a
+   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
+   addresses).  In such a case, the packet MUST NOT be forwarded back
+   onto the arrival link.
+
+   A destination node SHOULD originate a Destination Unreachable message
+   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
+   alternative means to inform the sender.
+
+   If the reason for the failure to deliver is that the 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.
+
+   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.
+
+
+
+
+
+
+Conta, et al.               Standards Track                     [Page 9]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+   Upper Layer Notification
+
+   A node receiving the ICMPv6 Destination Unreachable message MUST
+   notify the upper-layer process if the relevant process can be
+   identified (see Section 2.4, (d)).
+
+3.2.  Packet Too Big Message
+
+       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             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             MTU                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    As much of invoking packet                 |
+      +               as possible without the ICMPv6 packet           +
+      |               exceeding the minimum IPv6 MTU [IPv6]           |
+
+   IPv6 Fields:
+
+   Destination Address
+
+                  Copied from the Source Address field of the invoking
+                  packet.
+
+   ICMPv6 Fields:
+
+   Type           2
+
+   Code           Set to 0 (zero) by the originator and ignored by the
+                  receiver.
+
+   MTU            The Maximum Transmission Unit of the next-hop link.
+
+   Description
+
+   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
+   the outgoing link.  The information in this message is used as part
+   of the Path MTU Discovery process [PMTU].
+
+   Originating a Packet Too Big Message makes an exception to one of the
+   rules as to when to originate an ICMPv6 error message.  Unlike other
+   messages, it is sent in response to a packet received with an IPv6
+   multicast destination address, or with a link-layer multicast or
+   link-layer broadcast address.
+
+
+
+
+Conta, et al.               Standards Track                    [Page 10]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+   Upper Layer Notification
+
+   An incoming Packet Too Big message MUST be passed to the upper-layer
+   process if the relevant process can be identified (see Section 2.4,
+   (d)).
+
+3.3.  Time Exceeded Message
+
+       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             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             Unused                            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    As much of invoking packet                 |
+      +               as possible without the ICMPv6 packet           +
+      |               exceeding the minimum IPv6 MTU [IPv6]           |
+
+   IPv6 Fields:
+
+   Destination Address
+                  Copied from the Source Address field of the invoking
+                  packet.
+
+   ICMPv6 Fields:
+
+   Type           3
+
+   Code           0 - Hop limit exceeded in transit
+                  1 - Fragment reassembly time exceeded
+
+   Unused         This field is unused for all code values.
+                  It must be initialized to zero by the originator
+                  and ignored by the receiver.
+
+   Description
+
+   If a router receives a packet with a Hop Limit of zero, or if a
+   router 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 source of the packet.  This indicates either a routing loop or
+   too small an initial Hop Limit value.
+
+   An ICMPv6 Time Exceeded message with Code 1 is used to report
+   fragment reassembly timeout, as specified in [IPv6, Section 4.5].
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 11]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+   Upper Layer Notification
+
+   An incoming Time Exceeded message MUST be passed to the upper-layer
+   process if the relevant process can be identified (see Section 2.4,
+   (d)).
+
+3.4.  Parameter Problem Message
+
+       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             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                            Pointer                            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    As much of invoking packet                 |
+      +               as possible without the ICMPv6 packet           +
+      |               exceeding the minimum IPv6 MTU [IPv6]           |
+
+   IPv6 Fields:
+
+   Destination Address
+
+                  Copied from the Source Address field of the invoking
+                  packet.
+
+   ICMPv6 Fields:
+
+   Type           4
+
+   Code           0 - Erroneous header field encountered
+                  1 - Unrecognized Next Header type encountered
+                  2 - Unrecognized IPv6 option encountered
+
+   Pointer        Identifies the octet offset within the
+                  invoking packet where the error was detected.
+
+                  The pointer will point beyond the end of the ICMPv6
+                  packet if the field in error is beyond what can fit
+                  in the maximum size of an ICMPv6 error message.
+
+   Description
+
+   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
+   processing the packet, it MUST discard the packet and SHOULD
+   originate an ICMPv6 Parameter Problem message to the packet's source,
+   indicating the type and location of the problem.
+
+
+
+Conta, et al.               Standards Track                    [Page 12]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+   Codes 1 and 2 are more informative subsets of Code 0.
+
+   The pointer identifies the octet of the original packet's header
+   where the error was detected.  For example, an ICMPv6 message with a
+   Type field of 4, Code field of 1, and Pointer field of 40 would
+   indicate that the IPv6 extension header following the IPv6 header of
+   the original packet holds an unrecognized Next Header field value.
+
+   Upper Layer Notification
+
+   A node receiving this ICMPv6 message MUST notify the upper-layer
+   process if the relevant process can be identified (see Section 2.4,
+   (d)).
+
+4. ICMPv6 Informational Messages
+
+4.1.  Echo Request Message
+
+       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             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           Identifier          |        Sequence Number        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Data ...
+      +-+-+-+-+-
+
+   IPv6 Fields:
+
+   Destination Address
+
+                  Any legal IPv6 address.
+
+   ICMPv6 Fields:
+
+   Type           128
+
+   Code           0
+
+   Identifier     An identifier to aid in matching Echo Replies
+                  to this Echo Request.  May be zero.
+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 13]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+   Sequence Number
+
+                  A sequence number to aid in matching Echo Replies
+                  to this Echo Request.  May be zero.
+
+   Data           Zero or more octets of arbitrary data.
+
+   Description
+
+   Every node MUST implement an ICMPv6 Echo responder function that
+   receives Echo Requests and originates corresponding Echo Replies.  A
+   node SHOULD also implement an application-layer interface for
+   originating Echo Requests and receiving Echo Replies, for diagnostic
+   purposes.
+
+   Upper Layer Notification
+
+   Echo Request messages MAY be passed to processes receiving ICMP
+   messages.
+
+4.2.  Echo Reply Message
+
+       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             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           Identifier          |        Sequence Number        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Data ...
+      +-+-+-+-+-
+
+   IPv6 Fields:
+
+   Destination Address
+
+                  Copied from the Source Address field of the invoking
+                  Echo Request packet.
+
+   ICMPv6 Fields:
+
+   Type           129
+
+   Code           0
+
+   Identifier     The identifier from the invoking Echo Request message.
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 14]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+   Sequence Number
+
+                  The sequence number from the invoking Echo Request
+                  message.
+
+   Data           The data from the invoking Echo Request message.
+
+   Description
+
+   Every node MUST implement an ICMPv6 Echo responder function that
+   receives Echo Requests and originates corresponding Echo Replies.  A
+   node SHOULD also implement an application-layer interface for
+   originating Echo Requests and receiving Echo Replies, for diagnostic
+   purposes.
+
+   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
+   that 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
+   source address of the reply MUST be a unicast address belonging to
+   the interface on which the Echo Request message was received.
+
+   The data received in the ICMPv6 Echo Request message MUST be returned
+   entirely and unmodified in the ICMPv6 Echo Reply message.
+
+   Upper Layer Notification
+
+   Echo Reply messages MUST be passed to the process that originated an
+   Echo Request message.  An Echo Reply message MAY be passed to
+   processes that did not originate the Echo Request message.
+
+   Note that there is no limitation on the amount of data that can be
+   put in Echo Request and Echo Reply Messages.
+
+5. Security Considerations
+
+5.1.  Authentication and Confidentiality of ICMP Messages
+
+   ICMP protocol packet exchanges can be authenticated using the IP
+   Authentication Header [IPv6-AUTH] or IP Encapsulating Security
+   Payload Header [IPv6-ESP].  Confidentiality for the ICMP protocol
+   packet exchanges can be achieved using the IP Encapsulating Security
+   Payload Header [IPv6-ESP].
+
+   [SEC-ARCH] describes the IPsec handling of ICMP traffic in detail.
+
+
+
+
+Conta, et al.               Standards Track                    [Page 15]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+5.2.  ICMP Attacks
+
+   ICMP messages may be subject to various attacks.  A complete
+   discussion can be found in the IP Security Architecture [IPv6-SA].  A
+   brief discussion of these attacks and their prevention follows:
+
+   1. ICMP messages may be subject to actions intended to cause the
+      receiver to believe the message came from a different source from
+      that of the message originator.  The protection against this
+      attack can be achieved by applying the IPv6 Authentication
+      mechanism [IPv6-AUTH] to the ICMP message.
+
+   2. ICMP messages may be subject to actions intended to cause the
+      message or the reply to it to go to a destination different from
+      that of the message originator's intention.  The protection
+      against this attack can be achieved by using the Authentication
+      Header [IPv6-AUTH] or the Encapsulating Security Payload Header
+      [IPv6-ESP].  The Authentication Header provides the protection
+      against change for the source and the destination address of the
+      IP packet.  The 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 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
+      payload.  The authentication [IPv6-AUTH] or encryption [IPv6-ESP]
+      of the ICMP message protects against such actions.
+
+   4. ICMP messages may be used to attempt denial-of-service attacks by
+      sending back to back erroneous IP packets.  An implementation that
+      correctly followed Section 2.4, paragraph (f), of this
+      specification, would be protected by the ICMP error rate limiting
+      mechanism.
+
+   5. The exception number 2 of rule e.3 in Section 2.4 gives a
+      malicious node the opportunity 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 an ICMP Parameter Problem
+      Message to the multicast source, causing a denial-of-service
+      attack.  The way multicast traffic is forwarded by the multicast
+      routers requires that the malicious node be part of the correct
+
+
+
+Conta, et al.               Standards Track                    [Page 16]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+      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. 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 that the upper
+      layers 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 specification.
+      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 at which 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.1.  Procedure for New ICMPV6 Type and Code Value Assignments
+
+   The IPv6 ICMP header defined in this document contains the following
+   fields that carry values assigned from IANA-managed name spaces: Type
+   and Code.  Code field values are defined relative to a specific Type
+   value.
+
+   Values for the IPv6 ICMP Type fields are allocated using the
+   following procedure:
+
+   1. The IANA should allocate and permanently register new ICMPv6 type
+      codes from IETF RFC publication.  This is for all RFC types,
+      including standards track, informational, and experimental status,
+      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
+      approval can request reclaimable ICMPV6 type code assignments from
+      the IANA.  The IANA will tag the values as "reclaimable in
+      future".
+
+
+
+Conta, et al.               Standards Track                    [Page 17]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+      The "reclaimable in the future" tag will be removed when an RFC is
+      published that documents the protocol as defined in 1.  This will
+      make the assignment permanent and update the reference on the IANA
+      web pages.
+
+      At the point where the ICMPv6 type values are 85% assigned, the
+      IETF will review the assignments tagged "reclaimable in the
+      future" and inform the IANA which ones should be reclaimed and
+      reassigned.
+
+   3. Requests for new ICMPv6 type value assignments from outside the
+      IETF are only made through the publication of an IETF document,
+      per 1 above.  Note also that documents published as "RFC Editor
+      contributions" [RFC-3978] are not considered IETF documents.
+
+   The assignment of new Code values for the Type values defined in this
+   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
+
+   The following has updated assignments located at:
+
+      http://www.iana.org/assignments/icmpv6-parameters
+
+   The IANA has reassigned ICMPv6 type 1 "Destination Unreachable" code
+   2, which was unassigned in [RFC-2463], to:
+
+         2 - Beyond scope of source address
+
+   The IANA has assigned the following two new codes values for ICMPv6
+   type 1 "Destination Unreachable":
+
+         5 - Source address failed ingress/egress policy
+         6 - Reject route to destination
+
+   The IANA has assigned the following new type values:
+
+         100  Private experimentation
+         101  Private experimentation
+
+         127  Reserved for expansion of ICMPv6 error messages
+
+         200  Private experimentation
+         201  Private experimentation
+
+
+
+
+Conta, et al.               Standards Track                    [Page 18]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+         255  Reserved for expansion of ICMPv6 informational messages
+
+7. References
+
+7.1.  Normative References
+
+   [IPv6]       Deering, S. and R. Hinden, "Internet Protocol, Version 6
+                (IPv6) Specification", RFC 2460, December 1998.
+
+   [IPv6-DISC]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
+                Discovery for IP Version 6 (IPv6)", RFC 2461, December
+                1998.
+
+   [RFC-792]    Postel, J., "Internet Control Message Protocol", STD 5,
+                RFC 792, September 1981.
+
+   [RFC-2463]   Conta, A. and S. Deering, "Internet Control Message
+                Protocol (ICMPv6) for the Internet Protocol Version 6
+                (IPv6) Specification", RFC 2463, December 1998.
+
+   [RFC-1122]   Braden, R., "Requirements for Internet Hosts -
+                Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [RFC-2119]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC-3978]   Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
+                3978, March 2005.
+
+7.2.  Informative References
+
+   [RFC-2780]   Bradner, S. and V. Paxson, "IANA Allocation Guidelines
+                For Values In the Internet Protocol and Related
+                Headers", BCP 37, RFC 2780, March 2000.
+
+   [IPv6-ADDR]  Hinden, R. and S. Deering, "Intpernet Protocol Version 6
+                (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+   [PMTU]       McCann, J., Deering, S., and J. Mogul, "Path MTU
+                Discovery for IP version 6", RFC 1981, August 1996.
+
+   [IPv6-SA]    Kent, S. and R. Atkinson, "Security Architecture for the
+                Internet Protocol", RFC 2401, November 1998.
+
+   [IPv6-AUTH]  Kent, S., "IP Authentication Header", RFC 4302, December
+                2005.
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 19]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+   [IPv6-ESP]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
+                4203, December 2005.
+
+   [SEC-ARCH]   Kent, S. and K. Seo, "Security Architecture for the
+                Internet Protocol", RFC 4301, December 2005.
+
+   [TCP-attack] Gont, F., "ICMP attacks against TCP", Work in Progress.
+
+8.  Acknowledgements
+
+   The document is derived from previous ICMP documents of the SIPP and
+   IPng working group.
+
+   The IPng working group, and particularly Robert Elz, Jim Bound, Bill
+   Simpson, Thomas Narten, Charlie Lynn, Bill Fink, Scott Bradner,
+   Dimitri Haskin, Bob Hinden, Jun-ichiro Itojun Hagino, Tatuya Jinmei,
+   Brian Zill, Pekka Savola, Fred Templin, and Elwyn Davies (in
+   chronological order) provided extensive review information and
+   feedback.
+
+   Bob Hinden was the document editor for this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 20]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+Appendix A - Changes since 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
+     were supposed to be references to e.3.
+
+   - Removed the Timer-based and the Bandwidth-based methods from the
+     example rate-limiting mechanism for ICMP error messages.  Added
+     Token-bucket based method.
+
+   - Added specification that all ICMP error messages shall have exactly
+     32 bits of type-specific data, so that receivers can reliably find
+     the embedded invoking packet even when they don't recognize the
+     ICMP message Type.
+
+   - In the description of Destination Unreachable messages, Code 3,
+     added rule prohibiting forwarding of packets back onto point-to-
+     point links from which they were received, if their destination
+     addresses belong to the link itself ("anti-ping-ponging" rule).
+
+   - Added description of Time Exceeded Code 1 (fragment reassembly
+     timeout).
+
+   - Added "beyond scope of source address", "source address failed
+     ingress/egress policy", and "reject route to destination" messages
+     to the family of "unreachable destination" type ICMP error messages
+     (Section 3.1).
+
+   - Reserved some ICMP type values for experimentation.
+
+   - Added a NOTE in Section 2.4 that specifies ICMP message processing
+     rules precedence.
+
+   - Added ICMP REDIRECT to the list in Section 2.4, (e) of cases in
+     which ICMP error messages are not to be generated.
+
+   - Made minor editorial changes in Section 2.3 on checksum
+     calculation, and in Section 5.2.
+
+   - Clarified in Section 4.2, regarding the Echo Reply Message; the
+     source address of an Echo Reply to an anycast Echo Request should
+     be a unicast address, as in the case of multicast.
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 21]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+   - Revised the Security Considerations section.  Added the use of the
+     Encapsulating Security Payload Header for authentication.  Changed
+     the requirement of an option of "not allowing unauthenticated ICMP
+     messages" to MAY from SHOULD.
+
+   - 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".  Also added a note
+     that this document updates RFC 2780.
+
+   - Added a procedure for new ICMPv6 Type and Code value assignments in
+     the IANA Considerations section.
+
+   - Replaced word "send" with "originate" to make it clear that ICMP
+     packets being forwarded are out of scope of this specification.
+
+   - Changed the ESP and AH references to the updated ESP and AH
+     documents.
+
+   - Added reference to the updated IPsec Security Architecture
+     document.
+
+   - Added a SHOULD requirement for allowing the sending of ICMP
+     destination unreachable messages to be disabled.
+
+   - Simplified the source address selection of the ICMPv6 packet.
+
+   - Reorganized the General Message Format (Section 2.1).
+
+   - Removed the general packet format from Section 2.1.  It refers to
+     Sections 3 and 4 for packet formats now.
+
+   - Added text about attacks to the transport protocols that could
+     potentially be caused by ICMP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 22]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+Authors' Addresses
+
+   Alex Conta
+   Transwitch Corporation
+   3 Enterprise Drive
+   Shelton, CT 06484
+   USA
+
+   EMail: aconta@txc.com
+
+
+   Stephen Deering
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+   USA
+
+
+   Mukesh Gupta, Ed.
+   Tropos Networks
+   555 Del Rey Avenue
+   Sunnyvale, CA 94085
+
+   Phone: +1 408-331-6889
+   EMail: mukesh.gupta@tropos.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 23]
+
+RFC 4443                 ICMPv6 (ICMP for IPv6)               March 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   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.
+
+   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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   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
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 24]
+