diff options
Diffstat (limited to 'doc/rfc/rfc988.txt')
| -rw-r--r-- | doc/rfc/rfc988.txt | 1140 |
1 files changed, 1140 insertions, 0 deletions
diff --git a/doc/rfc/rfc988.txt b/doc/rfc/rfc988.txt new file mode 100644 index 0000000..4bca41f --- /dev/null +++ b/doc/rfc/rfc988.txt @@ -0,0 +1,1140 @@ + + +Network Working Group S. E. Deering +Request for Comments: 988 Stanford University + July 1986 + + Host Extensions for IP Multicasting + + +1. STATUS OF THIS MEMO + + This memo specifies the extensions required of a host implementation + of the Internet Protocol (IP) to support internetwork multicasting. + This specification supersedes that given in RFC-966, and constitutes + a proposed protocol standard for IP multicasting in the + ARPA-Internet. The reader is directed to RFC-966 for a discussion of + the motivation and rationale behind the multicasting extension + specified here. Distribution of this memo is unlimited. + +2. INTRODUCTION + + IP multicasting is defined as the transmission of an IP datagram to a + "host group", a set of zero or more hosts identified by a single IP + destination address. A multicast datagram is delivered to all + members of its destination host group with the same "best-efforts" + reliability as regular unicast IP datagrams, i.e. the datagram is not + guaranteed to arrive at all members of the destination group or in + the same order relative to other datagrams. + + The membership of a host group is dynamic; that is, hosts may join + and leave groups at any time. There is no restriction on the + location or number of members in a host group, but membership in a + group may be restricted to only those hosts possessing a private + access key. A host may be a member of more than one group at a time. + A host need not be a member of a group to send datagrams to it. + + A host group may be permanent or transient. A permanent group has a + well-known, administratively assigned IP address. It is the address, + not the membership of the group, that is permanent; at any time a + permanent group may have any number of members, even zero. A + transient group, on the other hand, is assigned an address + dynamically when the group is created, at the request of a host. A + transient group ceases to exist, and its address becomes eligible for + reassignment, when its membership drops to zero. + + The creation of transient groups and the maintenance of group + membership information is the responsibility of "multicast agents", + entities that reside in internet gateways or other special-purpose + hosts. There is at least one multicast agent directly attached to + every IP network or subnetwork that supports IP multicasting. A host + requests the creation of new groups, and joins or leaves existing + groups, by exchanging messages with a neighboring agent. + + + +Deering [Page 1] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + + Multicast agents are also responsible for internetwork delivery of + multicast IP datagrams. When sending a multicast IP datagram, a host + transmits it to a local network multicast address which identifies + all neighboring members of the destination host group. If the group + has members on other networks, a multicast agent becomes an + additional recipient of the local multicast and relays the datagram + to agents on each of those other networks, via the internet gateway + system. Finally, the agents on the other networks each transmit the + datagram as a local multicast to their own neighboring members of the + destination group. + + This memo specifies the extensions required of a host IP + implementation to support IP multicasting, where a "host" is any + internet host or gateway other than those serving as multicast + agents. The algorithms and protocols used within and between + multicast agents are transparent to non-agent hosts and will be + specified in a separate document. This memo also does not specify + how local network multicasting is accomplished for all types of + network, although it does specify the required service interface to + an arbitrary local network and gives an Ethernet specification as an + example. Specifications for other types of network will be the + subject of future memos. + +3. LEVELS OF CONFORMANCE + + There are three levels of conformance to this specification: + + Level 0: no support for IP multicasting. + + There is, at this time, no requirement that all IP implementations + support IP multicasting. Level 0 hosts will, in general, be + unaffected by multicast activity. The only exception arises on + some types of local network, where the presence of level 1 or 2 + hosts may cause misdelivery of multicast IP datagrams to level 0 + hosts. Such datagrams can easily be identified by the presence of + a class D IP address in their destination address field; they + should be quietly discarded by hosts that do not support IP + multicasting. Class D addresses are defined in section 4 of this + memo. + + + + + + + + + + +Deering [Page 2] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + + Level 1: support for sending but not receiving multicast IP + datagrams. + + Level 1 allows a host to partake of some multicast-based services, + such as resource location or status reporting, but it does not + allow a host to create or join any host groups. An IP + implementation may be upgraded from level 0 to level 1 very easily + and with little new code. Only sections 4, 5, and 6 of this memo + are applicable to level 1 implementations. + + Level 2: full support for IP multicasting. + + Level 2 allows a host to create, join and leave host groups, as + well as send IP datagrams to host groups. It requires + implementation of the Internet Group Management Protocol (IGMP) + and extension of the IP and local network service interfaces + within the host. All of the following sections of this memo are + applicable to level 2 implementations. + +4. HOST GROUP ADDRESSES + + Host groups are identified by class D IP addresses, i.e. those with + "1110" as their high-order four bits. The remaining 28 bits are + unstructured as far as hosts are concerned. The addresses of + well-known, permanent groups are to be published in "Assigned + Numbers". Class E IP addresses, i.e. those with "1111" as their + high-order four bits, are reserved for future addressing modes. + + Appendix II contains some background discussion of several issues + related to host group addresses. + + + + + + + + + + + + + + + + + + + +Deering [Page 3] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + +5. MODEL OF A HOST IP IMPLEMENTATION + + The multicast extensions to a host IP implementation are specified in + terms of the layered model illustrated below. In this model, ICMP + and (for level 2 hosts) IGMP are considered to be implemented within + the IP module, and the mapping of IP addresses to local network + addresses is considered to be the responsibility of local network + modules. This model is for expository purposes only, and should not + be construed as constraining an actual implementation. + + | | + | Upper-Layer Protocol Modules | + |__________________________________________________________| + + --------------------- IP Service Interface ----------------------- + __________________________________________________________ + | | | | + | | ICMP | IGMP | + | IP |______________|______________| + | Module | + | | + |__________________________________________________________| + + ---------------- Local Network Service Interface ----------------- + __________________________________________________________ + | | | + | Local | IP-to-local address mapping | + | Network | (e.g. ARP) | + | Modules |_____________________________| + | (e.g. Ethernet) | + | | + + To support level 2 IP multicasting, a host IP implementation must + provide three new services: (1) sending multicast IP datagrams, (2) + receiving multicast IP datagrams, and (3) managing group membership. + Only the first service need be provided in level 1 hosts. Each of + these services is described in a separate section, below. For each + service, extensions are specified for the IP service interface, the + IP module, the local network service interface, and an Ethernet local + network module. Extensions to local network modules other than + Ethernet are mentioned briefly, but are not specified in detail. + + + + + + + + +Deering [Page 4] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + +6. SENDING MULTICAST IP DATAGRAMS + + 6.1. Extensions to the IP Service Interface + + No change to the IP service interface is required to support the + sending of multicast IP datagrams. An upper-layer protocol module + merely specifies an IP host group destination, rather than an + individual IP destination, when it invokes the existing "Send IP" + operation. + + 6.2. Extensions to the IP Module + + To support the sending of multicast IP datagrams, the IP module + must be extended to recognize IP host group addresses when routing + outgoing datagrams. Most IP implementations include the following + logic: + + if IP-destination is on the same local network, + send datagram locally to IP-destination + else + send datagram locally to GatewayTo(IP-destination) + + To allow multicast transmissions, the routing logic must be + changed to: + + if IP-destination is on the same local network + or IP-destination is a host group, + send datagram locally to IP-destination + else + send datagram locally to GatewayTo(IP-destination) + + If the sending host is itself a member of the destination group, a + copy of the outgoing datagram must be looped-back for local + delivery if and only if loopback was requested when the host + joined the group (see section 8.1). (This issue does not arise in + level 1 implementations.) + + On hosts attached to more than one network, each multicast IP + datagram must be transmitted via one network interface only, + leaving it to the multicast agents to effect delivery to any other + required networks. + + A host group address should not be placed in the source address + field of an outgoing IP datagram. A host group address may be + used in a source routing option as the last element only. + + It should be noted that a small IP time-to-live (TTL) value can + + +Deering [Page 5] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + + prevent delivery to some members of a destination group. Thus, a + large TTL value should be used to reach all members. Conversely, + a small TTL value can be used to advantage to reach only "nearby" + members of a widely-dispersed group. In clusters of low-delay + local area networks, the TTL field acts as a hop limit; thus, one + can perform expanding-ring searches by starting with a TTL of 1 + and incrementing on each retransmission, up to some limit defined + by the diameter of the cluster. + + 6.3. Extensions to the Local Network Service Interface + + No change to the local network service interface is required to + support the sending of multicast IP datagrams. The IP module + merely specifies an IP host group destination, rather than an + individual IP destination, when it invokes the existing "Send + Local" operation. + + 6.4. Extensions to an Ethernet Local Network Module + + The Ethernet directly supports the sending of local multicast + packets by allowing multicast addresses in the destination field + of Ethernet packets. All that is needed to support the sending of + multicast IP datagrams is a procedure for mapping IP host group + addresses to Ethernet multicast addresses. + + An IP host group address is mapped to an Ethernet multicast + address by placing the low-order 28-bits of the IP address into + the low-order 28 bits of an Ethernet address. The high-order 20 + bits of the Ethernet address are set to a well-known value, to be + published in "Assigned Numbers". + + [At time of publication of this memo, a block of Ethernet + multicast addresses with 28 unspecified bits had not yet been + obtained from the allocating authority. If such a block of + addresses cannot be obtained, an alternative mapping scheme will + be specified.] + + 6.5. Extensions to Local Network Modules other than Ethernet + + Other networks that directly support multicasting, such as rings + or buses conforming to the IEEE 802.2 standard, can be handled the + same way as Ethernet for the purpose of sending multicast IP + datagrams. For a network that supports broadcast but not + multicast, such as the Experimental Ethernet, all IP host group + addresses can be mapped to a single local broadcast address (at + the cost of increased overhead on all local hosts). For a + point-to-point networks like the ARPANET or a public data network + + +Deering [Page 6] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + + (X.25), all IP host group addresses might be mapped to the + well-known local address of an IP multicast agent; an agent on + such a network would take responsibility for completing multicast + delivery within the network as well as among networks. + +7. RECEIVING MULTICAST IP DATAGRAMS + + 7.1. Extensions to the IP Service Interface + + No change to the IP service interface is required to support the + reception of multicast IP datagrams. Incoming multicast IP + datagrams are delivered to upper-layer protocol modules using the + same "Receive IP" operation as normal, unicast datagrams. + + 7.2. Extensions to the IP Module + + To support the reception of multicast IP datagrams, the IP module + must be extended to recognize the addresses of IP host groups to + which the host currently belongs, in addition to the host's + individual IP address(es). An incoming datagram destined to one + of those group addresses is processed exactly the same way as + datagrams destined to one of the host's individual addresses. + Incoming datagrams destined to groups to which the host does not + belong are discarded without generating any error report. + + On hosts attached to more than one network, if a datagram arrives + via one network interface, destined for a group to which the host + belongs only on a different interface, the datagram is quietly + discarded. (This should occur only as a result of inadequate + multicast address filtering in the local network module.) + + An incoming datagram is not rejected for having an IP host group + address in its source address field or anywhere in a source + routing option. + + An ICMP error message (Destination Unreachable, Time Exceeded, + Parameter Problem, Source Quench, or Redirect) is never generated + in response to a datagram destined to an IP host group. + + 7.3. Extensions to the Local Network Service Interface + + No change to the local network service interface is required to + support the reception of multicast IP datagrams. Incoming local + network packets, whether multicast or unicast, are delivered to + the IP module using the same "Receive Local" operation. + + + + +Deering [Page 7] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + + 7.4. Extensions to an Ethernet Local Network Module + + To support the reception of multicast IP datagrams, an Ethernet + module must be able to receive packets addressed to the Ethernet + multicast addresses that correspond to the host's IP host group + addresses. It is highly desirable to take advantage of any + address filtering capabilities that the Ethernet hardware + interface may have, so that the host only receives packets that + are destined to it. + + Unfortunately, many current Ethernet interfaces have a small limit + on the number of addresses that the hardware can be configured to + recognize. However, an implementation must be capable of + listening on an arbitrary number of Ethernet multicast addresses, + which may mean "opening up" the address filter to accept all + multicast packets during those periods when the number of + addresses exceeds the limit of the filter. + + For interfaces with inadequate hardware address filtering, it may + be desirable (for performance reasons) to perform Ethernet address + filtering within the software of the Ethernet module. This is not + mandatory, however, because the IP module performs its own + filtering based on IP destination addresses. + + 7.5. Extensions to Local Network Modules other than Ethernet + + Other multicast networks, such as IEEE 802.2 networks, can be + handled the same way as Ethernet for the purpose of receiving + multicast IP datagrams. For pure broadcast networks, such as the + Experimental Ethernet, all incoming broadcast packets can be + accepted and passed to the IP module for IP-level filtering. On a + point-to-point network, multicast IP datagrams will arrive as + local network unicasts, so no change to the local network module + should be necessary. + + + + + + + + + + + + + + + +Deering [Page 8] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + +8. MANAGING GROUP MEMBERSHIP + + 8.1. Extensions to the IP Service Interface + + To allow upper-layer protocol modules to request that their host + create, join, or leave a host group, the IP service interface must + be extended to offer the following three new operations: + + CreateGroup ( private, loopback ) + --> outcome, group-address, access-key + + The CreateGroup operation requests the creation of a new, + transient host group, with this host as its only member. The + "private" argument specifies if the group is to be private or + public. The "loopback" argument specifies whether or not + datagrams sent from this host to the group should be delivered + locally as well as to other member hosts. The "outcome" result + indicates whether the request is granted or denied. If it is + granted, a new 32-bit IP host group address is returned, along + with a 64-bit access key which is zero for public groups and + non-zero for private groups. The request may be denied due to + lack of response from a multicast agent, or lack of resources. + + JoinGroup ( group-address, access-key, loopback ) --> outcome + + The JoinGroup operation requests that this host become a member of + the host group identified by "group-address", with the specified + access key. The "loopback" argument specifies whether or not + datagrams sent from this host to the group should be delivered + locally as well as to other member hosts. The "outcome" result + indicates whether the request is granted or denied. The request + may be denied due to lack of response from a multicast agent, lack + of resources, an invalid group address, an incorrect access key, + or already being a member. + + LeaveGroup ( group-address, access-key ) --> outcome + + The LeaveGroup operation requests that this host give up its + membership in the host group identified by "group-address", with + the specified access key. The "outcome" result indicates whether + the request is granted or denied. The request may be denied due + to an invalid group address, an incorrect access key, or not + currently being a member. + + Each of these operations may take up to a minute or more to + complete, depending on the number of IGMP retransmissions + + + +Deering [Page 9] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + + performed within the IP module, and time required for a multicast + agent to generate a reply. However, typical delays should be on + the order of a few seconds. + + Besides the LeaveGroup operation, a host loses its membership in a + group whenever the host or its IP module crashes, or, in rare + circumstances, when a multicast agent revokes its membership. The + IP service interface should provide some means of informing an + upper-layer module when its membership has been revoked. + Membership may be revoked due to lack of resources, deallocation + of the group address, or the discovery of another host group using + the same group address with a different access key. (See Appendix + II for discussion of address recycling issues.) + + It is important to observe that IP group membership is per-host, + rather than per-process. An IP service interface should not allow + multiple processes to invoke JoinGroup operations for the same + group as a way of achieving delivery to more than process. The IP + module delivers each incoming datagram, whether multicast or + unicast, to the single upper-layer protocol module identified by + the protocol field in the datagram's IP header; it is an + upper-layer issue whether or not to deliver incoming datagrams to + more than one process, perhaps using the concept of "process + groups" or "shared ports". + + 8.2. Extensions to the IP Module + + Within the IP module, the membership management operations are + supported by the Internet Group Management Protocol (IGMP), + specified in Appendix I. As well as having messages corresponding + to each of the operations specified above, IGMP also specifies a + "deadman timer" procedure whereby hosts periodically confirm their + memberships with the multicast agents. + + The IP module must maintain a data structure listing the IP + addresses of all host groups to which the host currently belongs, + along with each group's loopback policy, access key, and timer + variables. This data structure is used by the IP multicast + transmission service to know which outgoing datagrams to loop + back, and by the reception service to know which incoming + datagrams to accept. The purpose of IGMP and the management + interface operations is to maintain this data structure. + + On hosts attached to more than one network, each membership is + associated with a particular network interface. On such a host + the management interface operations above may each require an + additional parameter specifying to which interface the create, + + +Deering [Page 10] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + + join, or leave request applies. The group membership data + structure must also be extended to associate an interface with + each membership. If a host joins the same host group on more than + one network interface, it can expect to receive multiple copies of + each datagram sent to that group. + + 8.3. Extensions to the Local Network Service Interface + + To allow an IP module to control what packets should be accepted + by the local network module, it is necessary to extend the local + network service interface with the following two new operations: + + AcceptAddress ( group-address ) + + RejectAddress ( group-address ) + + where "group-address" is an IP host group address. The + AcceptAddress operation requests the local network module to + accept and deliver up subsequently arriving packets destined to + the local network address corresponding to "group-address". The + RejectAddress operation requests the local network module to stop + delivering up packets destined to the local network address + corresponding to "group-address". + + Any local network module is free to ignore RejectAddress requests, + and may deliver up packets destined to more addresses than just + those specified in AcceptAddress requests, if it is unable to + filter incoming packets adequately. + + 8.4. Extensions to an Ethernet Local Network Module + + An Ethernet module responds to AcceptAddress operations by adding + the corresponding Ethernet multicast address to its acceptance + filter for incoming packets. A RejectAddress operation causes the + corresponding Ethernet address to be dropped from the filter. For + Ethernet interfaces with a limit on the number of addresses that + can be added to the filter, the Ethernet software module must + detect when that threshold is exceeded and open up the filter to + accept all multicast packets. It should also detect when the + number of addresses drops below the threshold and revert to + individual address filtering. + + 8.5. Extensions to Local Network Modules other than Ethernet + + Other multicast networks, such as IEEE 802.2 networks, can be + handled the same way as Ethernet for the purpose of controlling + address filtering. For a pure broadcast network or a + + +Deering [Page 11] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + + point-to-point network, the AcceptAddress and RejectAddress + operations may have no effect; all incoming packets could be + passed to the IP module for IP-level filtering. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Deering [Page 12] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + +APPENDIX I. INTERNET GROUP MANAGEMENT PROTOCOL (IGMP) + + The Internet Group Management Protocol (IGMP) is used between IP + hosts and their immediate neighbor multicast agents to support the + creation of transient groups, the addition and deletion of members of + a group, and the periodic confirmation of group membership. IGMP is + an asymmetric protocol and is specified here from the point of view + of a host, rather than a multicast agent. + + Like ICMP, IGMP is a integral part of IP. It is required to be + implemented in full by all hosts conforming to level 2 of the IP + multicasting specification. IGMP messages are encapsulated in IP + datagrams, with an IP protocol number of 2. All 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Group Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Access Key + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + There are eight types of IGMP message: + + 1 = Create Group Request + 2 = Create Group Reply + + 3 = Join Group Request + 4 = Join Group Reply + + 5 = Leave Group Request + 6 = Leave Group Reply + + 7 = Confirm Group Request + 8 = Confirm Group Reply + + + + + +Deering [Page 13] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + + Code + + In a Create Group Request message, the code field indicates if the + new host group is to be public or private: + + 0 = public + 1 = private + + In all other Request messages, the code field contains zero. + + In a Reply message, the Code field specifies the outcome of the + request: + + 0 = request granted + 1 = request denied, no resources + 2 = request denied, invalid code + 3 = request denied, invalid group address + 4 = request denied, invalid access key + 5 - 255 = request pending, retry in this many seconds + + Checksum + + The checksum is the 16-bit one's complement of the one's + complement sum of the IGMP message starting with the IGMP Type. + For computing the checksum, the checksum field should be zero. + + Identifier + + In a Confirm Group Request message, the identifier field contains + zero. + + In all other Request messages, the identifier field contains a + value to distinguish the request from other requests by the same + host. + + In a Reply message, the identifier field contains the same value + as in the corresponding Request message. + + + + + + + + + + + + +Deering [Page 14] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + + Group Address + + In a Create Group Request message, the group address field + contains zero. + + In all other Request messages, the group address field contains a + host group address. + + In a Create Group Reply message, the group address field contains + either a newly allocated host group address (if the request is + granted) or zero (if denied). + + In all other Reply messages, the group address field contains the + same host group address as in the corresponding Request message. + + Access Key + + In a Create Group Request message, the access key field contains + zero. + + In all other Request messages, the access key field contains the + access key assigned to the host group identified in the Group + Address field (zero for public groups). + + In a Create Group Reply message, the access key field contains + either a non-zero 64-bit number (if the request for a private + group is granted) or zero. + + In all other Reply messages, the access key field contains the + same access key as in the corresponding Request. + + + + + + + + + + + + + + + + + + + +Deering [Page 15] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + + Protocol Rules + + Request messages are sent only by hosts. Reply messages are sent + only by multicast agents. If a host receives an IGMP message of a + type other than the four Reply types specified above, the message + is discarded. + + A Request message is sent with its IP destination field containing + the well-known address of the Multicast Agent Group. The IP + time-to-live field is initialized by the sender to 1, in order to + limit the scope of the request to immediate neighbor multicast + agents only. The IP source address field contains the individual + IP address of the sending host. + + A Reply message is sent only in response to a Request message. + Its IP destination address field contains the individual address + of the host that sent the corresponding Request. (A Confirm Group + Reply may also be sent to the host group address specified in its + corresponding Confirm Group Request.) The IP source address field + contains the individual IP address of the replying multicast + agent. + + When a host sends a new Create Group, Join Group, or Leave Group + Request message, it supplies an arbitrary identifier that it has + not used within the last T0 seconds. (It is usually sufficient + just to increment the identifier for each new request.) The host + initializes a timer to T1 seconds and a retransmission counter to + zero. If a Reply message with a matching identifier is not + received before the timer expires, it is reset to T1 seconds and + the retransmission counter is incremented. If the counter is less + than N1, the host retransmits the Request message with the same + identifier. If the counter equals N1, the host gives up; if the + request was to create or join a group, it is deemed to have + failed; if the request was to leave a group, it is deemed to have + succeeded. + + If a "request pending" code is received in a matching reply to a + Create Group, Join Group, or Leave Group Request, the timer is + reset to the number of seconds specified by the code and the + retransmission counter is reset to zero. The new timer value + applies to one timeout interval only -- if the timer expires, it + is reset to T1 seconds, the counter is incremented, and the + request is retransmitted. + + The first matching Reply to a Create Group, Join Group, or Leave + Group Request containing a "request granted" or "request denied" + code determines the outcome of the request. Any subsequent or + + +Deering [Page 16] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + + non-matching Replies are discarded by the host. However, if a + host receives an affirmative Create Group Reply or Join Group + Reply that neither matches an outstanding Request nor contains the + address of a group to which the host belongs, the host should + immediately send a Leave Group Request for the unexpected group + address. + + A "request granted" reply to a Create Group Request implies that, + as well as the group being created, the requesting host is granted + membership in the group, i.e. there is no need to send a separate + Join Group Request. + + Confirm Group Request messages must be sent periodically by hosts + to inform the neighboring multicast agent(s) of the hosts' + continuing membership in the specified groups. If an agent does + not receive a Confirm Group Request message for a particular group + within an agent-defined interval, it stops delivering datagrams + destined to that group. + + For each group to which it belongs, a host maintains a + confirmation timer and a variable t. The variable t is + initialized to T2 seconds. Whenever the host's request to create + or join a group is granted, and whenever the host either sends a + Confirm Group Request or receives a Confirm Group Reply with a + "request granted" code for the group, the host sets the group's + timer to a random number uniformly distributed between t and t + + T3 seconds. If the host receives a a Confirm Group Reply with a + "request pending" code, t is changed to the value of the code and + the timer is reset to a random number between the new t and t + + T3. The variable t retains its value until another "request + pending" code is received. Whenever the timer expires, the host + sends a Confirm Group Request. + + Even if a host fails to receive Confirm Group Replies to its + Requests, it continues to consider itself a member of the group, + because it may still be able to receive multicast datagrams from + other hosts on the same local network. Only if a host receives a + "request denied" code in a Confirm Group Reply does it stop + sending Confirm Group Requests and consider its membership to be + revoked. + + Multicast agents respond to Confirm Group Request messages by + sending Confirm Group Reply messages either to the individual + sender of the Request or to the host group address specified in + the Request. By sending back a Confirm Group Reply to all + neighboring members of a group, a multicast agent is able to reset + every member's timer with a single packet. The randomization of + + +Deering [Page 17] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + + the timers is intended to cause only the one member whose timer + expires first to send a Confirm Group Request, stimulating a Reply + to reset all the timers. The use of the "request pending" codes + allows the multicast agent to control the rate at which it + receives Confirm Group Requests. + + Protocol Timing Constants + + The following timing constants are specified for IGMP. They are + subject to change as a result of operational experience. + + T0 = 300 seconds minimum recycle time for identifiers + + T1 = 2 seconds retrans. interval for Create/Join/Leave Requests + + N1 = 5 tries retrans. limit for Create/Join/Leave Requests + + T2 = 15 seconds initial value for Confirm Request variable t + + T3 = 15 seconds random range for Confirm Request variable t + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Deering [Page 18] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + +APPENDIX II. HOST GROUP ADDRESS ISSUES + + This appendix is not part of the IP multicasting specification, but + provides background discussion of several issues related to IP host + group addresses. + + Group Address Binding + + The binding of IP host group addresses to physical hosts may be + considered a generalization of the binding of IP unicast + addresses. An IP unicast address is statically bound to a single + local network interface on a single IP network. An IP host group + address is dynamically bound to a set of local network interfaces + on a set of IP networks. + + It is important to understand that an IP host group address is NOT + bound to a set of IP unicast addresses. The multicast agents do + not need to maintain a list of individual members of each host + group. For example, a multicast agent attached to an Ethernet + need associate only a single Ethernet multicast address with each + host group having local members, rather than a list of the + members' individual IP or Ethernet addresses. + + Group Addresses as Logical Addresses + + Host group addresses have been defined specifically for use in the + destination address field of multicast IP datagrams. However, the + fact that group addresses are location-independent (they are not + statically bound to a single network interface) suggests possible + uses as more general "logical addresses", both in the source as + well as the destination address field of datagrams. For example, + a mobile IP host might have a host group address as its only + identity, used as the source of datagrams it sends. Whenever the + mobile host moved from one network to another, it would join its + own group on the new network and depart from the group on the old + network. Other hosts communicating with the mobile one would deal + only with the group address and would be unaware of, and + unaffected by, the changing network location of the mobile host. + + Host group addresses cannot, however, be used to solve all + problems of internetwork logical addressing, such as delivery to + the "nearest" or the "least loaded" network interface of a + multi-homed host. Furthermore, there are hazards in using group + addresses in the source address field of datagrams when the group + actually contains more than one host. For instance, the IP + datagram reassembly algorithm relies on every host using a + different source address. Also, errors in a datagram sent with a + + +Deering [Page 19] + + + +RFC 988 July 1986 +Host Extensions for IP Multicasting + + + group source address may result in error reports being returned to + all members of the group, not just the sender. In view of these + hazards, this memo specifies the use of host group addresses only + as destinations of datagrams, either in the destination address + field or as the last element of a source routing option. However, + it is recommended that datagrams with a group source address be + accepted without complaint, thereby allowing other implementations + to experiment with logical addressing applications of host group + addresses. + + Recycling of Transient Host Group Addresses + + Since host group addresses are of fixed, relatively small size, + transient group addresses must be recycled to satisfy continuing + requests for creation of new groups. The multicast agents make an + effort to ensure that a group has no members anywhere in the + internet before allocating its address to a new group. However, + under certain conditions of internetwork partitioning and + membership migration, it is impossible to guarantee unique + allocation of an address without seriously compromising the + availability and robustness of host groups. Furthermore, hosts + that are unaware that a particular group has ceased to exist may + send datagrams to it long after its address has been assigned to a + new group. Therefore, hosts should be prepared for the + possibility of misdelivery of multicast IP datagrams to unintended + hosts, even in private groups. Such misdelivery can only be + detected at a level above IP, using higher-level identifiers or + authentication tokens. (The access key of a private group might + be used in some applications as such an identifier.) Of course, + there are other threats to privacy of communication in the + internet, besides group address collision, such as untrustworthy + gateways or unsecured networks. End-to-end encryption is an + effective defense against such threats. + + + + + + + + + + + + + + + + +Deering [Page 20] + |