SIPP Working Group R. Govindan (Bellcore) INTERNET-DRAFT S. Deering (Xerox PARC) March 20, 1994 ICMP and IGMP for the Simple Internet Protocol Plus (SIPP) 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." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Distribution of this memo is unlimited. 1. Introduction The Simple Internet Protocol Plus (SIPP) is a new version of IP. SIPP uses the Internet Control Message Protocol (ICMP [1]) and the Internet Group Management Protocol (IGMP [7]) with a few changes. This document describes the format of control messages used in ICMP and IGMP for SIPP. This document does not describe the procedures that use these messages to achieve functions like Router Discovery and Path MTU Discovery; these procedures are described in companion documents ([4], [5], and [6]). Terminology defined in the SIPP specification [2] and the SIPP Routing and Addressing specification [3] applies to this document as well. Expires: September 20, 1994 [Page 1] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 2. ICMP for SIPP The SIPP Internet Control Message Protocol (SIPP ICMP) is used by SIPP routers to report errors encountered in processing packets. SIPP hosts may also send SIPP ICMP messages; the Echo message is one such. As with IPv4, SIPP ICMP is an integral part of SIPP and MUST be implemented by every SIPP module. This document defines the message formats for the following SIPP ICMP messages: Destination Unreachable Time Exceeded Parameter Problem Redirect Host Advertisement Router Advertisement Router Solicitation Echo and Echo Reply The first four messages are collectively called SIPP ICMP error mes- sages. Every SIPP ICMP message is preceded by a SIPP header and zero or more SIPP option headers. The header immediately preceding the SIPP ICMP message MUST have a payload type of 1. Like IPv4 ICMP messages, SIPP ICMP messages have the following for- mat: 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. The meaning of the code field depends on the message type. If the destination of a transmitted ICMP message, or the source of a received ICMP message, is an IPv4 host (the C-bit in the correspond- ing address is 1 [8]), the checksum is the 16-bit one's complement of Expires: September 20, 1994 [Page 2] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 the one's complement sum of the SIPP Source Identifying Address, the SIPP Destination Identifying Address, the SIPP Payload Type and the entire ICMP message starting with the ICMP message type. Otherwise, the checksum is the 16-bit one's complement of the one's complement sum of the SIPP Source Identifying Address, the SIPP Destination Identifying Address, the SIPP Payload Length, the SIPP Payload Type, and the entire ICMP message starting with the ICMP message type. (The rationale for this checksum computation is described in [2]). For computing the checksum, the checksum field is zeroed. As with IPv4 ICMP, implementations MUST observe the following rules when processing SIPP ICMP messages (from [9]): If a SIPP ICMP message of unknown type is received, it MUST be silently discarded. Every SIPP ICMP error message (the first four messages in the above list) includes as much of the SIPP invoking packet (the packet that causes the error) as will fit without making the error message packet exceed 576 octets. In those cases where the Internet layer is required to pass a SIPP ICMP error message to the transport layer, the SIPP Payload Type MUST be extracted from the original header (contained in the body of the SIPP ICMP error message) and used to select the appropriate transport protocol entity to handle the error. A SIPP ICMP error message MUST NOT be sent as a result of receiving: a SIPP ICMP error message, or a packet destined to a SIPP multicast address (an exception to this rule is the "packet too big" Destination Unreachable Message - Section 2.1 - to allow Path MTU discovery to work for SIPP multicast), or a packet sent as a link-layer broadcast, or a non-initial fragment, or a packet whose source address does not uniquely identify a single host -- e.g., the SIPP Unspecified Address, the SIPP Loopback Address, or a SIPP multicast address. Expires: September 20, 1994 [Page 3] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 Finally, to each sender of an erroneous data packet, a SIPP node SHOULD not send more than N ICMP error messages per second. The value of N should be fixed. The value of for N is recom- mended. The following sections describe the message formats for the above SIPP ICMP messages. Expires: September 20, 1994 [Page 4] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 2.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 error packet | | exceeding 576 octets | | | SIPP Fields: Source Address Sequence An address sequence for the router that sends the ICMP message. Destination Address Sequence The "consumed" portion of the route sequence in the invoking packet, reversed (see Appendix). SIPP ICMP Fields: Type 3 Code 1 - destination address unreachable 2 - payload type unknown 3 - port unreachable 4 - packet too big 13 - communication administratively prohibited Unused This field is unused for all code values other than 4 and must have a zero value. For the "packet too big" message (code 4), the higher order 16-bits of this field are unused and must have a zero value and the lower order 16-bits contain the next-hop MTU size [4]. Expires: September 20, 1994 [Page 5] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 Description A Destination Unreachable SHOULD be sent by a router in response to a packet which it cannot forward either because the destination address is unreachable (code 1), or if the router is administratively prohi- bited from forwarding packets to the destination of the SIPP packet (code 13). A Destination Unreachable 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 (code 4). A host SHOULD generate a Destination Unreachable message in response to a packet when the packet's SIPP payload type is not recognized (code 2), or when the transport protocol indicated by the Payload Type field (such as UDP) is unable to demultiplex the packet (code 3) but has no protocol mechanisms to inform the sender. Codes 3, 8, and 13 are exactly the same as the corresponding IPv4 ICMP codes for Destination Unreachables. Codes 1, 7, 2, and 4 are also exactly the same as the corresponding IPv4 ICMP codes for Desti- nation Unreachables, but have different names. Codes 0, 6, 7, 8, 9, 10, 11, 12 are not used in SIPP ICMP. The minimum legal value of the next-hop MTU field in a "packet too big" message (code 4) received by a SIPP host is 68 octets. While SIPP 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 SIPP packets are undergo trans- lation to IPv4 packets (see Section 5 in [8]). Expires: September 20, 1994 [Page 6] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 2.2. 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 error packet | | exceeding 576 octets | | | SIPP Fields: Source Address Sequence An address sequence for the router that sends the ICMP message. Destination Address Sequence The "consumed" portion of the route sequence in the invoking packet, reversed (see Appendix). SIPP ICMP Fields: Type 11 Code 0 - hop limit exceeded in transit 1 - fragment reassembly time exceeded Description If a SIPP router encounters a SIPP packet with a zero hop limit, it discards the packet and sends a SIPP ICMP Time Exceeded message with code 0. SIPP systems are expected to avoid fragmentation by implementing Path MTU discovery. However, SIPP defines an end-to-end fragmentation function for backwards compatibility with existing higher-layer pro- tocols and IP-to-SIPP translation. Expires: September 20, 1994 [Page 7] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 From [9], the SIPP layer within SIPP hosts MUST implement reassembly of SIPP fragments. There MUST be a reassembly timeout. The reassem- bly 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 a SIPP ICMP Time Exceeded message with code 1. Expires: September 20, 1994 [Page 8] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 2.3. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As much of invoking packet | | as will fit without error packet | | exceeding 576 octets | | | SIPP Fields: Source Address Sequence An address sequence for the router that sends the ICMP message. Destination Address Sequence The "consumed" portion of the route sequence in the invoking packet, reversed (see Appendix). SIPP ICMP Fields: Type 12 Code 0 means Pointer field indicates incorrect parameter. Pointer If code = 0, identifies the octet offset within the invoking packet where an error was detected. Description If a SIPP node processing a packet finds a problem with the parame- ters in the SIPP header or optional headers such that it cannot com- plete processing the packet, it MUST discard the packet and SHOULD send an ICMP Parameter Problem message. Unlike the corresponding IPv4 ICMP message, the Pointer occupies the lower 16-bits of the second 32-bit word. Expires: September 20, 1994 [Page 9] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 2.4. Redirect 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LA Len | ASeq Len | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-layer | | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIPP | | address | | sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As much of invoking packet | | as will fit without error packet | | exceeding 576 octets | | | SIPP Fields: Source Address Sequence An address sequence for the router sending the redirect. Destination Address Sequence The source identifying address in the packet for which the redirect is sent. SIPP ICMP Fields: Type 5 Code 0 - Redirect packet to host 1 - Redirect packet to router LA Len Number of octets in the link-layer address. If code = 0, length must be zero. ASeq Len Number of 64-bit words in the SIPP address sequence. Expires: September 20, 1994 [Page 10] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 If code = 0, length must be zero. Lifetime The maximum number of seconds that the redirect may be considered valid. SIPP Address Sequence An Address sequence [3] for the redirectee (the router towards whom the redirect points). If code = 0, this field is NULL. Link-layer Address The link-layer address of the redirectee. The link- layer address is zero-filled at the end to the nearest 64-bit boundary. If code = 0, this field is NULL. Description A router may send a redirect in one of two situations: either a) another router R on the same subnet has advertised a shorter path to the destination or b) the destination D is on the same subnet. In case a), code must be 1, the SIPP Address Sequence field must con- tain an address sequence for R and the Link-layer Address must con- tain R's link-layer address. In case b), code must be 0, both the Link-layer Address and the SIPP Address Sequence must be NULL. Expires: September 20, 1994 [Page 11] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 2.5. Host Advertisement 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LA Len | Num ASeqs | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-layer | | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASeq Len[1] | ASeq Len[2] | ASeq Len[3] | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ASeq Len[n] | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIPP | | address | | sequence[1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIPP | | address | | sequence[2] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | | | SIPP Fields: Source Address Sequence A unicast address sequence for the sending host. Destination Address Sequence The All Nodes multicast address with intra-link scope, or the SIPP address of a neighbor. SIPP ICMP Fields: Type Code 0 LA Len Length (in octets) of the Link-layer Address. Expires: September 20, 1994 [Page 12] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 Num ASeqs The number of address sequences that this advertise- ment carries. Lifetime The maximum number of seconds that the advertisement may be considered valid. Link-layer Address The link-layer address of the interface on which this advertisement is sent. The link-layer address is zero-filled to the nearest 64-bit boundary. ASeq Len[i], i = 1, ..., Num ASeqs The length in 64-bit words of each address sequence in the advertisement. The length array is zero-filled to the nearest 64-bit boundary. SIPP address sequence[i], i = 1, ..., Num ASeqs The SIPP address sequences of the host sending the advertisement. Each address sequence consists of one or more 64-bit words. The number of 64-bits words in address sequence[1] is indicated by "ASeq Len[1]" and so on. Description Each host may send a host advertisement either periodically, or in response to a Host Solicitation (Section 2.6). Specific procedures for the use of host advertisements are described elsewhere [6]. Expires: September 20, 1994 [Page 13] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 2.6. Host Solicitation 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SIPP Fields Source Address Sequence A globally hierarchical unicast address sequence for the sender. Destination Address Sequence SIPP All Hosts multicast address with intra-link scope. SIPP ICMP Fields Type Code 0 Reserved Sent as zero, ignored upon reception. Description The host solicitation message, in conjunction with the host adver- tisement message, may be used for link-layer address resolution. Specific procedures for achieving this function are described else- where [6]. Expires: September 20, 1994 [Page 14] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 2.7. Router Advertisement 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 | LA Len | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-layer | | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unicast Address | | Prefixes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobility Scope | | Prefixes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SIPP Fields: Source Address Sequence A unicast address for the router sending the adver- tisement. Destination Address Sequence The All Nodes Multicast Address with intra-link scope, or the SIPP address of a neighbor. SIPP ICMP Fields: Type 9 Code 0 LA Len Length (in octets) of the link-layer address. Lifetime The maximum number of seconds that the advertisement may be considered valid. Link-layer Address The Link-layer address of the interface on which this Expires: September 20, 1994 [Page 15] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 advertisement is sent. The Link-layer address is zero-filled to the nearest 64-bit boundary. Unicast Address Prefixes Prefixes that a host receiving this advertisement may use to form valid unicast addresses for itself. These may either be local-use prefixes or prefixes of the globally hierarchical unicast address space [3]. The sub-fields of this field are (see Figure 1): Num Prefs The number of prefixes advertised. Masklen[i], i=1, ..., Num Prefs Length of the mask for unicast address prefix[i]. This array is zero filled to the nearest 64-bit boundary. Prefix[i], i=1, ... ,Num Prefs The list of unicast address prefixes. The number of 64-bit words in prefix[i] is ceil(Masklen[i]/64). Mobility Scope Prefixes Each mobility scope prefix defines a topological region over which, if a mobile host receiving the advertisement moves, it need not perform special mobile routing procedures (e.g., regis- tering with a new foreign agent). The structure of this field is identical to the structure of the subnet cluster prefix field (Figure 1). Expires: September 20, 1994 [Page 16] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Prefs=m | Masklen[1] | Masklen[2] | Masklen[3] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | Masklen[m] | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix[1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix[m] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Description A router may send a Router Advertisement either periodically, or in response to a Router Solicitation (section 2.8). These messages are used for Router Discovery [5]. Specific procedures for achieving this function in SIPP are described in [6]. Expires: September 20, 1994 [Page 17] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 2.8. Router Solicitation 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SIPP Fields Source Address Sequence Address sequence of sender. This may be a globally- routable hierarchical unicast address sequence or a local-use address sequence. Destination Address Sequence SIPP All Routers multicast address with intra-link scope. SIPP ICMP Fields Type 10 Code 0 Reserved Sent as zero, ignored upon reception. Description Hosts send router solicitations to obtain router advertisements. Specific procedures for achieving performing router discovery using these two messages are described in [6]. Expires: September 20, 1994 [Page 18] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 2.9. Echo and Echo Reply 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 ... +-+-+-+-+- SIPP Fields: Source Address Sequence A globally hierarchical unicast address sequence for the source. Destination Address Sequence A globally hierarchical unicast address sequence for the destination. SIPP ICMP Fields: Type 0 - Echo Reply Message 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 The data received in the echo message must be returned unmodified in the echo reply message. Expires: September 20, 1994 [Page 19] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 3. IGMP for SIPP The SIPP Internet Group Management Protocol (IGMP) is used by SIPP hosts to report their group memberships to any immediately- neighboring multicast routers and by multicast routers to query hosts for group membership information. SIPP IGMP is an integral part of SIPP, and MUST be implemented by every SIPP module. IGMP messages may also be sent between routers to exchange group membership, prune and join information; the formats of such messages are not specified here. Each SIPP IGMP message is preceded by a SIPP header and zero or more SIPP option headers. The header immediately preceding the SIPP header MUST have a payload type of 2. SIPP IGMP 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Unused | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIPP | + Multicast | | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SIPP IGMP Fields: Version 1 Type There are two types of IGMP messages of concern to hosts: 1 - Host Membership Query 2 - Host Membership Report Reserved Zeroed when sent, ignored when received. Checksum If the destination of the ICMP message is an IPv4 mul- ticast group (the C-bit in the destination address is 1 [8]), the checksum is the 16-bit one's complement of Expires: September 20, 1994 [Page 20] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 the one's complement sum of the SIPP Source Identify- ing Address, the SIPP Destination Identifying Address, the SIPP Payload Type and the entire ICMP message starting with the ICMP message type. Otherwise, the checksum is the 16-bit one's complement of the one's complement sum of the SIPP Source Identifying Address, the SIPP Destination Identifying Address, the SIPP Payload Length, the SIPP Payload Type, and the entire ICMP message starting with the ICMP message type. (The rationale for this checksum computation is described in [2]). For computing the checksum, the checksum field is zeroed. SIPP Multicast Address In a Host Membership Query message, the SIPP multicast address is zeroed when sent and ignored when received. In a Host Membership Report message, the SIPP multi- cast address field holds the multicast address of the group being reported. Description Multicast routers send Host Membership Query messages to discover which host groups have members on attached networks. These queries are sent to the SIPP All-Hosts multicast group with intra-link scope. Hosts respond to a query by generating Host Membership Reports, reporting each group they belong to on the network interface from which the query was received. Reports are generally sent to the SIPP multicast group address of the group being reported, with intra-link scope; other members of the group receive this report and desist from sending a report themselves. Hosts receiving a group report should confirm that the SIPP destination address and the multicast address in the SIPP IGMP message are identical; the report MUST be silently discarded otherwise. Details of the protocol are described in [7]. References [1] J. Postel, "Internet Control Message Protocol", RFC 792. [2] S. Deering, "Simple Internet Protocol Plus SIPP Specification", Internet Draft, . Expires: September 20, 1994 [Page 21] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 [3] S. Deering, P. Francis and R. Govindan, "Simple Internet Protocol Plus Routing and Addressing Overview", Internet Draft, . [4] J. Mogul and S. Deering, "Path MTU Discovery", RFC 1191. [5] S. Deering, "ICMP Router Discovery", RFC 1256. [6] W. A. Simpson, "Neighbor Discovery", Internet Draft, . [7] S. Deering, "Host Extensions for IP Multicasting", RFC 1112. [8] R.Gilligan, E. Nordmark, R. Hinden, "IPAE: The SIPP Interopera- bility and Transition Mechanism", Internet Draft, . [9] R. Braden, "Requirements for Internet Hosts - Communication Layers", RFC 1122. Authors' Addresses Ramesh Govindan Stephen Deering Bell Communications Research Xerox Palo Alto Research Center MRE2P-341, 445 South Street 3333 Coyote Hill Road Morristown, NJ 07960 Palo Alto, CA 94304 +1-201-989-0381 +1-415-812-4839 email: rxg@thumper.bellcore.com email: deering@parc.xerox.com Appendix: Router Reversal of Route Sequences When a router encounters an error in processing a packet, it sends an ICMP error message to the packet's source. This section specifies the rule for forming the route sequence in the ICMP error message. Let the route sequence in the invoking packet be , where R0 is the source identifying address and Rn the destina- tion identifying address. Let Rj be the active element in the route sequence. From the host route sequence reversal rules described Expires: September 20, 1994 [Page 22] INTERNET-DRAFT ICMP and IGMP for SIPP March 20, 1994 above, j is always >= 1. The route sequence in the ICMP error message is , where is a source-capable address sequence for the router generating the ICMP error message. The active element in this route sequence is Rj-1. Intuitively, the "consumed" portion of the invoking packet's route sequence is used to route the error message back to the source. Expires: September 20, 1994 [Page 23]