summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1885.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1885.txt')
-rw-r--r--doc/rfc/rfc1885.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc1885.txt b/doc/rfc/rfc1885.txt
new file mode 100644
index 0000000..0f5b836
--- /dev/null
+++ b/doc/rfc/rfc1885.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group A. Conta, Digital Equipment Corporation
+Request for Comments: 1885 S. Deering, Xerox PARC
+Category: Standards Track December 1995
+
+
+
+
+ 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.
+
+
+Abstract
+
+
+ This document specifies a set of Internet Control Message Protocol
+ (ICMP) messages for use with version 6 of the Internet Protocol
+ (IPv6). The Internet Group Management Protocol (IGMP) messages
+ specified in STD 5, RFC 1112 have been merged into ICMP, for IPv6,
+ and are included in this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta & Deering Standards Track [Page 1]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+Table of Contents
+
+
+
+ 1. Introduction........................................3
+
+ 2. ICMPv6 (ICMP for IPv6)..............................3
+
+ 2.1 Message General Format.......................3
+
+ 2.2 Message Source Address Determination.........4
+
+ 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......................14
+
+ 4.1 Echo Request Message........................14
+
+ 4.2 Echo Reply Message..........................15
+
+ 4.3 Group Membership Messages...................17
+
+ 5. References.........................................19
+
+ 6. Acknowledgements...................................19
+
+ 7. Security Considerations............................19
+
+ Authors' Addresses....................................20
+
+
+
+
+
+
+
+
+
+
+Conta & Deering Standards Track [Page 2]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+1. Introduction
+
+ The Internet Protocol, version 6 (IPv6) is a new version of IP. IPv6
+ uses the Internet Control Message Protocol (ICMP) as defined for IPv4
+ [RFC-792], with a number of changes. The Internet Group Membership
+ Protocol (IGMP) specified for IPv4 [RFC-1112] has also been revised
+ and has been absorbed into ICMP for IPv6. 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 or multicast
+ group membership maintenance; such procedures are described in other
+ documents (e.g., [RFC-1112, RFC-1191]). 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.
+
+
+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") and multicast membership
+ reporting. ICMPv6 is an integral part of IPv6 and MUST be fully
+ implemented by every IPv6 node.
+
+
+2.1 Message General Format
+
+ ICMPv6 messages are grouped into two classes: error messages and
+ informational messages. Error messages are identified as such by
+ having 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.
+
+ This document defines the message formats for the following ICMPv6
+ messages:
+
+
+
+
+
+
+
+
+
+Conta & Deering Standards Track [Page 3]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+ 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)
+
+ ICMPv6 informational messages:
+
+ 128 Echo Request (see section 4.1)
+ 129 Echo Reply (see section 4.2)
+ 130 Group Membership Query (see section 4.3)
+ 131 Group Membership Report (see section 4.3)
+ 132 Group Membership Reduction (see section 4.3)
+
+
+ Every ICMPv6 message is preceded by an IPv6 header and zero or more
+ IPv6 extension headers. The ICMPv6 header is identified by a Next
+ Header value of 58 in the immediately preceding header. (NOTE: this
+ is different than the value used to identify ICMP for IPv4.)
+
+ The ICMPv6 messages have the following general format:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Message Body +
+ | |
+
+ The type field indicates the type of the message. Its value
+ determines the format of the remaining data.
+
+ The code field depends on the message type. It is used to create an
+ additional level of message granularity.
+
+ The checksum field is used to detect data corruption in the ICMPv6
+ message and parts of the IPv6 header.
+
+
+2.2 Message Source Address Determination
+
+ A node that sends 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:
+
+
+
+Conta & Deering Standards Track [Page 4]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+ (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 a multicast or
+ anycast group in which the node is a member, the Source Address
+ of the reply must be a unicast address belonging to the
+ interface on which the multicast or anycast packet was received.
+
+ (c) If the message is a response to a message sent to an address
+ that does not belong to the node, the Source Address should be
+ that unicast address belonging to the node that will be most
+ helpful in diagnosing the error. For example, if the message is
+ a response to a packet forwarding action that cannot complete
+ successfully, the Source Address should be a unicast address
+ belonging to the interface on which the packet forwarding
+ failed.
+
+ (d) Otherwise, the node's routing table must be examined to
+ determine which interface will be used to transmit the message
+ to its destination, and a unicast address belonging to that
+ interface must be used as the Source Address of the message.
+
+
+2.3 Message Checksum Calculation
+
+ 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, 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. (NOTE: 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 set to zero.
+
+
+2.4 Message Processing Rules
+
+ Implementations MUST observe the following rules when processing
+ ICMPv6 messages (from [RFC-1122]):
+
+ (a) If an ICMPv6 error message of unknown type is received, it MUST
+ be passed to the upper layer.
+
+ (b) If an ICMPv6 informational message of unknown type is received,
+ it MUST be silently discarded.
+
+
+
+
+Conta & Deering Standards Track [Page 5]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+ (c) Every ICMPv6 error message (type < 128) includes as much of the
+ IPv6 offending (invoking) packet (the packet that caused the
+ error) as will fit without making the error message packet
+ exceed 576 octets.
+
+ (d) In those cases where the internet-layer protocol is required to
+ pass an ICMPv6 error message to the upper-layer protocol, 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 protocol entity to handle the
+ error.
+
+ If the original packet had an unusually large amount of
+ extension headers, it is possible that the upper-layer protocol
+ type may not be present in the ICMPv6 message, due to truncation
+ of the original packet to meet the 576-octet limit. In that
+ case, the error message is silently dropped after any IPv6-layer
+ processing.
+
+ (e) An ICMPv6 error message MUST NOT be sent as a result of
+ receiving:
+
+ (e.1) an ICMPv6 error message, or
+
+ (e.2) 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 that has the Option Type highest-order two
+ bits set to 10), or
+
+ (e.3) a packet sent as a link-layer multicast, (the exception
+ from e.2 applies to this case too), or
+
+ (e.4) a packet sent as a link-layer broadcast, (the exception
+ from e.2 applies to this case too), or
+
+ (e.5) 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 sender to be an IPv6 anycast address.
+
+ (f) Finally, to each sender of an erroneous data packet, an IPv6
+ node MUST limit the rate of ICMPv6 error messages sent, in order
+ to limit the bandwidth and forwarding costs incurred by the
+ error messages when a generator of erroneous packets does not
+ respond to those error messages by ceasing its transmissions.
+
+
+
+Conta & Deering Standards Track [Page 6]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+ There are a variety 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 error messages are sent from a particular interface
+ to some fraction F of the attached link's bandwidth.
+
+ The limit parameters (e.g., T or F in the above examples) MUST
+ be configurable for the node, with a conservative default value
+ (e.g., T = 1 second, NOT 0 seconds, or F = 2 percent, NOT 100
+ percent).
+
+ The following sections describe the message formats for the above
+ ICMPv6 messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta & Deering Standards Track [Page 7]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+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 will fit without the ICMPv6 packet +
+ | exceeding 576 octets |
+
+ 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 - not a neighbor
+ 3 - address unreachable
+ 4 - port unreachable
+
+ Unused This field is unused for all code values.
+ It must be initialized to zero by the sender
+ 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
+ (NOTE: this error can occur only in nodes that do not hold a "default
+ route" in their routing tables).
+
+
+
+Conta & Deering Standards Track [Page 8]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+ 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 next destination
+ address in the Routing header is not a neighbor of the processing
+ node but the "strict" bit is set for that address, then the Code
+ field is set to 2.
+
+ If there is any other reason for the failure to deliver, e.g.,
+ inability to resolve the IPv6 destination address into a
+ corresponding link address, or a link-specific problem of some sort,
+ then the Code field is set to 3.
+
+ A destination node SHOULD send 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.
+
+ Upper layer notification
+
+ A node receiving the ICMPv6 Destination Unreachable message MUST
+ notify the upper-layer protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta & Deering Standards Track [Page 9]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+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 will fit without the ICMPv6 packet +
+ | exceeding 576 octets |
+
+ IPv6 Fields:
+
+ Destination Address
+
+ Copied from the Source Address field of the invoking
+ packet.
+
+ ICMPv6 Fields:
+
+ Type 2
+
+ Code 0
+
+ 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 [RFC-1191].
+
+ Sending a Packet Too Big Message makes an exception to one of the
+ rules of when to send an ICMPv6 error message, in that unlike other
+ messages, it is sent in response to a packet received with an IPv6
+ multicast destination address, or a link-layer multicast or link-
+ layer broadcast address.
+
+ Upper layer notification
+
+ An incoming Packet Too Big message MUST be passed to the upper-layer
+ protocol.
+
+
+
+
+
+
+Conta & Deering Standards Track [Page 10]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+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 will fit without the ICMPv6 packet +
+ | exceeding 576 octets |
+
+ 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 sender
+ and ignored by the receiver.
+
+ Description
+
+ If a router receives a packet with a Hop Limit of zero, or a router
+ decrements a packet's Hop Limit to zero, it MUST discard the packet
+ and send 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.
+
+ The router sending an ICMPv6 Time Exceeded message with Code 0 SHOULD
+ consider the receiving interface of the packet as the interface on
+ which the packet forwarding failed in following rule (d) for
+ selecting the Source Address of the message.
+
+ Upper layer notification
+
+ An incoming Time Exceeded message MUST be passed to the upper-layer
+ protocol.
+
+
+
+Conta & Deering Standards Track [Page 11]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+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 will fit without the ICMPv6 packet +
+ | exceeding 576 octets |
+
+ 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 576-byte limit 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 send an
+ ICMPv6 Parameter Problem message to the packet's source, indicating
+ the type and location of the problem.
+
+ The pointer identifies the octet of the original packet's header
+ where the error was detected. For example, an ICMPv6 message with
+ Type field = 4, Code field = 1, and Pointer field = 40 would indicate
+
+
+
+Conta & Deering Standards Track [Page 12]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+ 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
+ protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta & Deering Standards Track [Page 13]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+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.
+
+ 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 sends corresponding Echo Replies. A node
+ SHOULD also implement an application-layer interface for sending Echo
+ Requests and receiving Echo Replies, for diagnostic purposes.
+
+ Upper layer notification
+
+ A node receiving this ICMPv6 message MAY notify the upper-layer
+ protocol.
+
+
+
+
+Conta & Deering Standards Track [Page 14]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+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.
+
+ Sequence The sequence number from the invoking Echo Request
+ Number 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 sends corresponding Echo Replies. A node
+ SHOULD also implement an application-layer interface for sending 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 address. The source address of the reply
+ MUST be a unicast address belonging to the interface on which the
+ multicast Echo Request message was received.
+
+
+
+
+Conta & Deering Standards Track [Page 15]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+ The data received in the ICMPv6 Echo Request message MUST be returned
+ entirely and unmodified in the ICMPv6 Echo Reply message, unless the
+ Echo Reply would exceed the MTU of the path back to the Echo
+ requester, in which case the data is truncated to fit that path MTU.
+
+ Upper layer notification
+
+ Echo Reply messages MUST be passed to the ICMPv6 user interface,
+ unless the corresponding Echo Request originated in the IP layer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta & Deering Standards Track [Page 16]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+4.3 Group Membership Messages
+
+ The ICMPv6 Group Membership Messages have the following 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Maximum Response Delay | Unused |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | Multicast |
+ + +
+ | Address |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ IPv6 Fields:
+
+ Destination Address
+
+ In a Group Membership Query message, the multicast
+ address of the group being queried, or the Link-Local
+ All-Nodes multicast address.
+
+ In a Group Membership Report or a Group Membership
+ Reduction message, the multicast address of the
+ group being reported or terminated.
+
+ Hop Limit 1
+
+ ICMPv6 Fields:
+
+ Type 130 - Group Membership Query
+ 131 - Group Membership Report
+ 132 - Group Membership Reduction
+
+ Code 0
+
+ Maximum Response Delay
+
+ In Query messages, the maximum time that responding
+ Report messages may be delayed, in milliseconds.
+
+
+
+
+
+Conta & Deering Standards Track [Page 17]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+ In Report and Reduction messages, this field is
+ is initialized to zero by the sender and ignored by
+ receivers.
+
+ Unused Initialized to zero by the sender; ignored by receivers.
+
+ Multicast Address
+
+ The address of the multicast group about which the
+ message is being sent. In Query messages, the Multicast
+ Address field may be zero, implying a query for all
+ groups.
+
+ Description
+
+ The ICMPv6 Group Membership messages are used to convey information
+ about multicast group membership from nodes to their neighboring
+ routers. The details of their usage is given in [RFC-1112].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta & Deering Standards Track [Page 18]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+5. References
+
+ [IPv6] Deering, S., and R. Hinden, "Internet Protocol, Version
+ 6, Specification", RFC 1883, Xerox PARC, Ipsilon
+ Networks, December 1995.
+
+ [IPv6-ADDR] Hinden, R., and S. Deering, Editors, "IP Version 6
+ Addressing Architecture", RFC 1884, Ipsilon Networks,
+ Xerox PARC, December 1995.
+
+ [IPv6-DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
+ Discovery for IP Version 6 (IPv6)", Work in Progress.
+
+ [RFC-792] Postel, J., "Internet Control Message Protocol", STD 5,
+ RFC 792, USC/Information Sciences Institute, September
+ 1981.
+
+ [RFC-1112] Deering, S., "Host Extensions for IP Multicasting", STD
+ 5, RFC 1112, Stanford University, August 1989.
+
+ [RFC-1122] Braden, R., "Requirements for Internet Hosts -
+ Communication Layers", STD 3, RFC 1122, USC/Information
+ Sciences Institute, October 1989.
+
+ [RFC-1191] Mogul, J., and S. Deering, "Path MTU Discovery", RFC
+ 1191, DECWRL, Stanford University, November 1990.
+
+
+6. Acknowledgements
+
+ The document is derived from previous ICMP drafts 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, and Scott Bradner
+ (in chronological order) provided extensive review information and
+ feedback.
+
+
+7. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+Conta & Deering Standards Track [Page 19]
+
+RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
+
+
+Authors' Addresses:
+
+ Alex Conta Stephen Deering
+ Digital Equipment Corporation Xerox Palo Alto Research Center
+ 110 Spitbrook Rd 3333 Coyote Hill Road
+ Nashua, NH 03062 Palo Alto, CA 94304
+
+ Phone: +1-603-881-0744 Phone: +1-415-812-4839
+ EMail: conta@zk3.dec.com EMail: deering@parc.xerox.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta & Deering Standards Track [Page 20]
+