Network Working Group A. Conta (Digital Equipment Corporation) INTERNET-DRAFT S. Deering (Xerox PARC) December 1994 ICMP for the Internet Protocol Version 6 (IPv6) draft-ietf-ipngwg-icmp-00.txt Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 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 RFC-1112 have been merged into ICMP, for IPv6, and are included in this document. Conta & Deering Expires in six months [Page 1] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 Table of Contents 1. Introduction.......................................3 2. ICMP for IPv6......................................3 3. ICMP Error Messages................................7 3.1 Destination Unreachable Message.............7 3.2 Packet Too Big..............................9 3.4 Time Exceeded Message.......................10 3.5 Parameter Problem Message...................12 4. ICMP Non-Error Messages............................13 4.1 Echo Message................................13 4.2 Echo Reply Message..........................14 4.3 Group Membership Message....................16 5. References.........................................18 6. Acknowledgements...................................19 7. Security Considerations............................19 Conta & Deering Expires in six months [Page 2] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 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 few changes. The Internet Group Membership Protocol (IGMP) specified for IPv4 [RFC-1112] has also been revised and has been absorbed into ICMP for IPv6. This document describes the format of a set of control messages used in ICMP for IPv6. This document does not describe the procedures that use these messages to achieve functions like Neighbor Discovery and Path MTU Discovery; these procedures are described in companion documents ([IPv6-DISC], and respectively [RFC-1191]). Terminology defined in the IPv6 specification [IPv6] and the IPv6 Routing and Addressing specification [IPv6-ADDR] applies to this document as well. 2. ICMP for IPv6 IPv6 ICMP is used by IPv6 nodes to report errors encountered in processing packets, and to perform other internet-layer functions, such as diagnostics (ICMP "ping"), neighbor discovery, and multicast membership reporting. IPv6 ICMP is an integral part of IPv6 and MUST be implemented by every IPv6 node. ICMP messages are grouped into two classes. ICMP error messages, such as: Destination Unreachable Packet Too Big Time Exceeded Parameter Problem ICMP non-error messages, such as: Echo Echo Reply Group Membership Query Group Membership Report Group Membership Termination Advertisment Solicitation Conta & Deering Expires in six months [Page 3] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 This document defines the message formats for the following IPv6 ICMP messages: ICMP error messages: Destination Unreachable (see section 3.1) Packet Too Big (see section 3.2) Time Exceeded (see section 3.3) Parameter Problem (see section 3.4) ICMP non-error messages: Echo (see section 4.1) Echo Reply (see section 4.2) Group Membership (see section 4.3) Other documents may define other ICMP messages. For example [IPv6- DISC] defines in detail the format of the following IPv6 ICMP messages: Advertisment Redirect Solicitation Every IPv6 ICMP message is preceded by an IPv6 header and zero or more IPv6 extension headers. The ICMP header is identified by a Next Header value of 1 in the immediately preceding header. The IPv6 ICMP 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 is the 16-bit one's complement of the one's complement sum of the IPv6 Source Address, the IPv6 Destination Address, the IPv6 Payload Length, the IPv6 Next Header Type, and the entire ICMP message starting with the ICMP message type. (The rationale for this Conta & Deering Expires in six months [Page 4] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 checksum computation is described in [IPv6]). For computing the checksum, the checksum field is set to zero. Implementation Notes: An application that sends ICMP messages has to fill in both the Source and Destination IPv6 Addresses in the IPv6 header before calculating the checksum. If the node has multiple source addresses, it is necessary to make an appropriate selection, based on the destination address, TClass, and flow id. This requires the implementation of a function: source_ipv6_address = get_source_address ( destination_ipv6_address, TClass, flow-id ) The following rules are suggested for implementing this mapping: (a) If the remote Internet address lies on one of the (sub)nets to which the node is directly connected, a corresponding source address may be chosen, unless the corresponding interface is known to be down. (b) The route cache may be consulted, to see if there is an active route to the specified destination network through any network interface; if so, a local IPv6 address corresponding to that interface may be chosen. If the route cache does not contain information about static routes or default routers, then consult similarly: (c) The table of static routes, and (d) The table of default routers. As default routers may be associated with a preference, chose the highest preference router. Implementations MUST observe the following rules when processing IPv6 ICMP messages (from [RFC-1122]): (a) If an IPv6 ICMP message of unknown type is received, it MUST be silently discarded. (b) Every IPv6 ICMP error message (the first four messages in Conta & Deering Expires in six months [Page 5] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 the above list) includes as much of the IPv6 offending (invoking) packet (the packet that causes the error) as will fit without making the error message packet exceed 576 octets. In case the ICMP packet that would result exceeds the size of 576 octets, then truncate the ICMP packet to a size of 576 octets. If the ICMP packet contains a pointer to a bad parameter and the ICMP message had to be truncated, the pointer may point beyond the end of the ICMP message if the bad parameter was in the part of the ICMP message that had to be truncated. (c) In those cases where the Internet layer is required to pass a IPv6 ICMP error message to the transport layer, the IPv6 Transport Protocol MUST be extracted from the original header (contained in the body of the IPv6 ICMP error message) and used to select the appropriate transport protocol entity to handle the error. (d) An IPv6 ICMP error message MUST NOT be sent as a result of receiving: (d.1.)an IPv6 ICMP error message, or (d.2.)a packet destined to an IPv6 multicast address (an exception to this rule is the Packet Too Big Message - Section 3.2 - to allow Path MTU discovery to work for IPv6 multicast), or (d.3.)a packet sent as a link-layer multicast, or (d.4.)a packet sent as a link-layer broadcast, or (d.5.)a packet whose source address does not uniquely identify a single node -- e.g., the IPv6 Unspecified Address, or an IPv6 multicast address. (e) Finally, to each sender of an erroneous data packet, an IPv6 node MUST limit the rate of ICMP error messages sent. One could limit the rate based on not sending more than N ICMP error messages per second to a certain destination. For such an implementation a value of for N is recommended. The following sections describe the message formats for the above IPv6 ICMP messages. Conta & Deering Expires in six months [Page 6] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 3. ICMP 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 ICMP packet | | exceeding 576 octets | | | IPv6 Fields: Source Address The IPv6 address of the node that composes (sends) the ICMP message. Destination Address The IPv6 address of the node to which the ICMP message is sent. IPv6 ICMP Fields: Type 3 Code 0 - intermediate router unreachable 1 - destination address unreachable (last hop) 2 - unused 3 - port unreachable 4 - unused 5 - unused 6 - destination router or prefix unkown 7 - destination address unknown (last hop) 8 - source node isolated 9 - communication with intermediate router administratively prohibited 10 - communication with destination node administratively prohibited (last hop) Unused This field is unused for all code values. Conta & Deering Expires in six months [Page 7] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 It must be initialized to zero by the sender and ignored by the receiver. Description A Destination Unreachable SHOULD be sent by a router in response to a packet which it cannot forward either because the next router destination address is unreachable (code 0), the node destination address is unreachable (code 1), the next router destination address is unknown (code 6), the node destination address is unknown (code 7), or if the router is administratively prohibited from forwarding packets to the destination of the IPv6 packet either to a router (code 11), or to the final destination which is a node (code 12). A host SHOULD generate a Destination Unreachable message in response to a packet when the transport protocol indicated by the Next Header Type field (such as UDP) is unable to demultiplex the packet (code 3) but has no protocol mechanisms to inform the sender. NOTE: The distinction between node or router for messages with code <0, or 1>, <6, or 7>, <9, or 10> is made by the ICMP packet generator based on whether the packet is being forwarded to an intermediate router (the packet is en route) or to its final destination node (last hop). Also the distinction between messages with code <0, or 1>, and <6, or 7>is made by the ICMP packet generator based on whether the packet is unreachable because of a link-level problem, or because the destination is not in the route cache. Upper layer notification A node receiving the ICMP Destination Unreachable message MUST notify the upper layer. Conta & Deering Expires in six months [Page 8] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 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 ICMP packet | | exceeding 576 octets | | | IPv6 Fields: Source Address The IPv6 address of the node that composes (sends) the ICMP message. Destination Address The IPv6 address of the node to which the ICMP message is sent. IPv6 ICMP Fields: Type TBD Code 0 MTU The 32-bits of this field contain the next hop's link Maximum Transmission Unit. Description A Packet Too Big MUST be sent by a router in response to a packet which it cannot forward because the packet is larger than the MTU of the outgoing link. A node sending packets that cannot be forwarded by a router due to the packets exceeding the MTU of the next-hop link will receive from that router the ICMP Packet Too Big message, reporting the MTU of that next-hop link. The node SHOULD store that PMTU information and use it for subsequent packets sent to the same destination. Using this mechanism, if the Conta & Deering Expires in six months [Page 9] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 packets are traversing several networks (forwarded by several routers), a node may receive several ICMP Packet Too Big messages until the PMTU to the final destination is learned. It is up to the transport or application protocol to make sure that packets lost because of inadequate PMTU are retransmitted. The minimum legal value of the next-hop MTU field in a "packet too big" message (code 4) received by an IPv6 node is 68 octets. While IPv6 requires all links in the Internet to have an MTU of 576 octets or greater, the smaller minimum legal value is required to allow Path MTU discovery to work correctly when IPv6 packets are undergo translation to IPv4 packets (see Section 5 in [IPv6-SIT]). Upper layer notification An incoming Packet Too Big message MUST be passed to the transport layer. 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 ICMP packet | | exceeding 576 octets | | | IPv6 Fields: Source Address The IPv6 address of the node that composes (sends) the ICMP message. Destination Address The IPv6 address of the node to which the ICMP message is sent. IPv6 ICMP Fields: Conta & Deering Expires in six months [Page 10] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 Type 11 Code 0 - hop limit exceeded in transit 1 - fragment reassembly time exceeded Unused It must be initialized to zero by the sender and igmored 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 discards the packet and sends an IPv6 ICMP Time Exceeded message with code 0. This indicates either a routing loop or too small an initial Hop Limit value. IPv6 systems are expected to avoid fragmentation by implementing Path MTU discovery. However, IPv6 defines an end-to-end fragmentation function for backwards compatibility with existing higher-layer pro- tocols and IPv4-to-IPv6 translation. From [RFC-1122], the IPv6 layer within IPv6 hosts MUST implement reassembly of IPv6 fragments. There MUST be a reassembly timeout. The reassembly timeout SHOULD be a fixed value. It is recommended that this value lie between 60 and 120 seconds. If the timeout expires, the partially-reassembled datagram MUST be discarded. If the fragment with offset zero was received, the destination host SHOULD also send an IPv6 ICMP Time Exceeded message with code 1. Upper layer notification An incoming Time Exceeded message MUST be passed to the transport layer. Conta & Deering Expires in six months [Page 11] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 2.5. 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 ICMP packet | | exceeding 576 octets | | | IPv6 Fields: Source Address The IPv6 address of the node that composes (sends) the ICMP message. Destination Address The IPv6 address of the node to which the ICMP message should be sent. IPv6 ICMP Fields: Type 12 Code 0 means Pointer field indicates incorrect parameter. 1 means unrecognized Next Header type 2 means unrecognized IPv6 option Pointer identifies the octet offset within the invoking packet where an error was detected. The pointer will point beyond the end of the ICMP packet, if the parameter in error is beyond what can fit in the 576-byte limit of an ICMP error message. Description If an IPv6 node processing a packet finds a problem with the parame- ters in the IPv6 header or extension headers such that it cannot com- plete processing the packet, it MUST discard the packet and SHOULD Conta & Deering Expires in six months [Page 12] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 send an ICMP Parameter Problem message. Upper layer notification A node receiving this ICMP message MUST notify the upper layer. 4. ICMP Non-Error Messages 4.1. Echo 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: Source Address The IPv6 address of the node that composes (sends) the ICMP message. Destination Address The IPv6 address of the node to which the ICMP message should be sent. IPv6 ICMP Fields: Type 8 - Echo Message Code 0 Identifier If code = 0, some identifier to match echo messages with echo replies. May be zero. Sequence Number If code = 0, a sequence number to aid in matching echo messages with echo replies. May be zero. Description Every node MUST implement an ICMP Echo server function that receives Conta & Deering Expires in six months [Page 13] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 Echo Requests and sends corresponding Echo Replies. A node SHOULD also implement an application-layer interface for sending an Echo Request and receiving an Echo Reply, for diagnostic purposes. An Echo Reply SHOULD be sent in response to an Echo 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 message was received. The source address of an Echo Reply sent in response to a unicast Echo message MUST be the same as the destination address of that Echo message. Upper layer notification A node receiving this ICMP message MUST notify the upper layer. Implementation Note: An application that sends ICMP Echo messages has to fill in both the Source and Destination IPv6 Addresses in the ICMP header before calculating the checksum. Please see the Implementation Note in Section 2. 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: Source Address The IPv6 address of the node that composes (sends) the ICMP message. Destination Address The IPv6 address of the node to which the ICMP message should be sent. Conta & Deering Expires in six months [Page 14] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 IPv6 ICMP Fields: Type 0 - Echo Reply Message Code 0 Identifier If code = 0, some identifier to match echo messages with echo replies. May be zero. Sequence Number If code = 0, a sequence number to aid in matching echo messages with echo replies. May be zero. Description Every node MUST implement an ICMP Echo server function that receives Echo Requests and sends corresponding Echo Replies. A node SHOULD also implement an application-layer interface for sending an Echo Request and receiving an Echo Reply, for diagnostic purposes. An Echo Reply SHOULD be sent in response to an Echo 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 message was received. The source address of an Echo Reply sent in response to a unicast Echo message MUST be the same as the destination address of that Echo message. The data received in the ICMP Echo message MUST be returned entirely and unmodified in the ICMP Echo Reply message. However, if the Echo Reply would exceed the path MTU of the path back to the Echo requestor, then the Echo Reply message MUST be truncated to the path MTU size and sent. Upper layer notification Echo Reply messages MUST be passed to the ICMP user interface, unless the corresponding Echo Request originated in the IP layer. Implementation Note: An application that sends ICMP ECHO messages has to fill in the ICMP header both the Source and Destination IPv6 Addresses before calculating the checksum. See the Implementation Note in Section 2. Conta & Deering Expires in six months [Page 15] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 4.3. Group Membership Messages The ICMP 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Multicast | + + | Address | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Fields: Source Address The IPv6 address of the node that composes (sends) the ICMP message. Destination Address The IPv6 address of the node to which the ICMP message is sent. IPv6 ICMP Fields: Type TBD - Group Membership Query TBD - Group Membership Report TBD - Group Membership Termination Code In Query messages, the Code field specifies the maximum time that responding Reports may be delayed. In Report and Termination messages, the Code field is initialized to zero by the sender and ignored by receivers. Unused Initialized to zero by the sender; ignored by receivers. Conta & Deering Expires in six months [Page 16] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 Multicast Address The address if 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 ICMP Group Membership messages are to convey information about multicast group membership from nodes to their neighboring routers. The details of their usage is given in [RFC-1112]. 4.4. Solicitation and Advertisment 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 | + + | | Type 33 - solicitation 34 - advertisment [IPv6-DISC] defines in detail this ICMP message header format. 5. References [IPv6]R. Hinden, "Internet Protocol Version 6 Specification", Internet Draft, . October 1994 [IPv6-ADDR] R. Hinden. IP Next Generation Addressing Architecture. Internet Draft . October 1994. Conta & Deering Expires in six months [Page 17] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 [IPv6-DISC] W. A. Simpson "Neighbor Discovery", Internet Draft, , November 1994 [IPv6-SIT] R.Gilligan, E. Nordmark, "Simple Internet Transition Overview", Internet Draft, , November 1994 [RFC-792] J. Postel, "Internet Control Message Protocol", RFC 792. [RFC-1112] S. Deering, "Host Extensions for IP Multicasting", RFC 1112. [RFC-1122] R. Braden, "Requirements for Internet Hosts - Communication Layers", RFC 1122. [RFC-1191] J. Mogul and S. Deering, "Path MTU Discovery", RFC 1191. [RFC-1256] S. Deering, "ICMP Router Discovery", RFC 1256. [TRANS-MECH] R. Gilligan, E. Nordmark. IPv6 Transition Mechanisms for Hosts and Routers. Internet Draft . November 1994. 6. Acknowledgements The document is derived from the "ICMP and IGMP for SIPP" document published as a draft by Ramesh Govindan and Steve Deering in March 1994. Extensive review information and feedback was provided by Robert Elz, Conta & Deering Expires in six months [Page 18] INTERNET-DRAFT ICMP for IPv6 December 3, 1994 Jim Bound, and others. 7. Security Considerations Security considerations are not discussed in this memo. 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 +1-603-881-0744 +1-415-812-4839 email: conta@zk3.dec.com email: deering@parc.xerox.com