diff options
Diffstat (limited to 'doc/rfc/rfc1054.txt')
| -rw-r--r-- | doc/rfc/rfc1054.txt | 1061 |
1 files changed, 1061 insertions, 0 deletions
diff --git a/doc/rfc/rfc1054.txt b/doc/rfc/rfc1054.txt new file mode 100644 index 0000000..06ca2fa --- /dev/null +++ b/doc/rfc/rfc1054.txt @@ -0,0 +1,1061 @@ +Network Working Group S. Deering +Request for Comments: 1054 Stanford University +Obsoletes: RFC 988 May 1988 + + + 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 multicasting. It is + proposed as a standard for IP multicasting in the Internet. This + specification is a major revision of RFC-988; changes from RFC-988 + are listed in an Appendix. 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 intact 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. 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. Those IP + multicast addresses that are not reserved for permanent groups are + available for dynamic assignment to transient groups which exist only + as long as they have members. + + Internetwork forwarding of IP multicast datagrams is handled by + "multicast routers" which may be co-resident with, or separate from, + internet gateways. A host transmits an IP multicast datagram as a + local network multicast which reaches all immediately-neighboring + members of the destination host group. If the datagram has an IP + time-to-live greater than 1, the multicast router(s) attached to the + local network take responsibility for forwarding it towards all other + networks that have members of the destination group. On those other + member networks that are reachable within the IP time-to-live, an + + + +Deering [Page 1] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + + attached multicast router completes delivery by transmitting the + datagram as a local multicast. + + 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 acting as multicast + routers. The algorithms and protocols used within and between + multicast routers are transparent to hosts and will be specified in + separate documents. 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 described in section 4 of this memo. + + 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 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 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 + + + +Deering [Page 2] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + + 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. Class E IP addresses, i.e., + those with "1111" as their high-order four bits, are reserved for + future addressing modes. + + In Internet standard "dotted decimal" notation, host group addresses + range from 224.0.0.0 to 239.255.255.255. The address 224.0.0.0 is + guaranteed not to be assigned to any group, and 224.0.0.1 is assigned + to the permanent group of all IP hosts. This is used to address all + multicast hosts on the directly connected network. There is no + multicast address (or any other IP address) for all hosts on the + total Internet. The addresses of other well-known, permanent groups + are to be published in "Assigned Numbers". + + Appendix II contains some background discussion of several issues + related to host group addresses. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Deering [Page 3] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + +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 1 multicasting, a host IP implementation must + support the transmission of multicast IP datagrams. To support level + 2 IP multicasting, a host must also support the reception of + multicast IP datagrams. Each of these two new 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 1054 Host Extensions for IP Multicasting May 1988 + + +6. SENDING MULTICAST IP DATAGRAMS + +6.1. Extensions to the IP Service Interface + + Multicast IP datagrams are sent using the same "Send IP" operation + used to send unicast IP datagrams; an upper-layer protocol module + merely specifies an IP host group address, rather than an individual + IP address, as the destination. However, a number of extensions may + be necessary or desirable. + + First, the service interface should provide a way for the upper-layer + protocol to specify the IP time-to-live of an outgoing multicast + datagram, if such a capability does not already exist. If the + upper-layer protocol chooses not to specify a time-to-live, it should + default to 1 for all multicast IP datagrams, so that an explicit + choice is required to multicast beyond a single network. + + Second, for hosts that may be attached to more than one network, the + service interface should provide a way for the upper-layer protocol + to identify which network interface is be used for the multicast + transmission. Only one interface is used for the initial + transmission; multicast routers are responsible for forwarding to any + other networks, if necessary. If the upper-layer protocol chooses + not to identify an outgoing interface, a default interface should be + used, preferably under the control of system management. + + Third (level 2 implementations only), for the case in which the host + is itself a member of a group to which a datagram is being sent, the + service interface should provide a way for the upper-layer protocol + to inhibit local delivery of the datagram; by default, a copy of the + datagram is looped back. This is a performance optimization for + upper-layer protocols that restrict the membership of a group to one + process per host (such as a routing protocol), or that handle + loopback of group communication at a higher layer (such as a + multicast transport protocol). + +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 ) + + + + +Deering [Page 5] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + + 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, + unless inhibited by the sender. (Level 2 implementations only.) + + A host group address should not be placed in the source address field + or anywhere in a source routing option of an outgoing IP datagram. + +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 23-bits of the IP address into the low-order + 23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex). + Because there are 28 significant bits in an IP host group address, + more than one host group address may map to the same Ethernet + multicast address. + +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, may 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 may be mapped to a + single local broadcast address (at the cost of increased overhead on + all local hosts). For a point-to-point link joining two hosts (or a + + + +Deering [Page 6] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + + host and a multicast router), multicasts should be transmitted + exactly like unicasts. For a store-and-forward network like the + ARPANET or a public X.25 network, all IP host group addresses might + be mapped to the well-known local address of an IP multicast router; + a router 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 + + Incoming multicast IP datagrams are received by upper-layer protocol + modules using the same "Receive IP" operation as normal, unicast + datagrams. Selection of a destination upper-layer protocol is based + on the protocol field in the IP header, regardless of the destination + IP address. However, before any datagrams destined to a particular + group can be received, an upper-layer protocol must ask the IP module + to join that group. Thus, the IP service interface must be extended + to provide two new operations: + + JoinHostGroup ( group-address, interface ) + + LeaveHostGroup ( group-address, interface ) + + The JoinHostGroup operation requests that this host become a member + of the host group identified by "group-address" on the given network + interface. The LeaveGroup operation requests that this host give up + its membership in the host group identified by "group-address" on the + given network interface. The interface argument may be omitted on + hosts that may be attached to only one network. For hosts that may + be attached to more than one network, the upper-layer protocol may + choose to leave the interface unspecified, in which case the request + will apply to the default interface for sending multicast datagrams + (see section 6.1). + + It is permissible to join the same group on more than one interface, + in which case duplicate multicast datagrams may be received. It is + also permissible for more than one upper-layer protocol to request + membership in the same group. + + Both operations should return immediately (i.e., they are non- + blocking operations), indicating success or failure. Either + operation may fail due to an invalid group address or interface + identifier. JoinHostGroup may fail due to lack of local resources. + LeaveHostGroup may fail because the host does not belong to the given + group on the given interface. LeaveHostGroup may succeed, but the + membership persist, if more than one upper-layer protocol has + requested membership in the same group. + + + +Deering [Page 7] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + +7.2. Extensions to the IP Module + + To support the reception of multicast IP datagrams, the IP module + must be extended to maintain a list of host group memberships + associated with each network interface. An incoming datagram + destined to one of those groups 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. + (These cases should occur only as a result of inadequate multicast + address filtering in a local network module.) + + An incoming datagram is not rejected for having an IP time-to-live of + 1 (i.e., the time-to-live should not automatically be decremented on + arriving datagrams that are not being forwarded). 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. + + The list of host group memberships is updated in response to + JoinHostGroup and LeaveHostGroup requests from upper-layer protocols. + Each membership should have an associated reference count or similar + mechanism to handle multiple requests to join and leave the same + group. On the first request to join and the last request to leave a + group on a given interface, the local network module for that + interface is notified, so that it may update its multicast reception + filter (see section 7.3). + + The IP module must also be extended to implement the IGMP protocol, + specified in Appendix I. IGMP is used to keep neighboring multicast + routers informed of the host group memberships present on a + particular local network. To support IGMP, every level 2 host must + join the "all-hosts" group (address 224.0.0.1) on each network + interface at initialization time and must remain a member for as long + as the host is active. + + (Datagrams addressed to the all-hosts group are recognized as a + special case by the multicast routers and are never forwarded beyond + a single network, regardless of their time-to-live. Thus, the all- + hosts address may not be used as an internet-wide broadcast address. + For the purpose of IGMP, membership in the all-hosts group is really + necessary only while the host belongs to at least one other group. + + + +Deering [Page 8] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + + However, it is specified that the host shall remain a member of the + all-hosts group at all times because (1) it is simpler, (2) the + frequency of reception of unnecessary IGMP queries should be low + enough that overhead is negligible, and (3) the all-hosts address may + serve other routing-oriented purposes, such as advertising the + presence of gateways or resolving local addresses.) + +7.3. Extensions to the Local Network Service Interface + + Incoming local network multicast packets are delivered to the IP + module using the same "Receive Local" operation as local network + unicast packets. To allow the IP module to tell the local network + module which multicast packets to accept, the local network service + interface is extended to provide two new operations: + + JoinLocalGroup ( group-address ) + + LeaveLocalGroup ( group-address ) + + where "group-address" is an IP host group address. The + JoinLocalGroup operation requests the local network module to accept + and deliver up subsequently arriving packets destined to the given IP + host group address. The LeaveLocalGroup operation requests the local + network module to stop delivering up packets destined to the given IP + host group address. The local network module is expected to map the + IP host group addresses to local network addresses as required to + update its multicast reception filter. Any local network module is + free to ignore LeaveLocalGroup requests, and may deliver up packets + destined to more addresses than just those specified in + JoinLocalGroup requests, if it is unable to filter incoming packets + adequately. + + The local network module must not deliver up any multicast packets + that were transmitted from that module; loopback of multicasts is + handled at the IP layer or higher. + +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 receives only those 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. Nevertheless, an implementation must be capable of + + + +Deering [Page 9] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + + 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 point-to-point or + store-and-forward networks, multicast IP datagrams will arrive as + local network unicasts, so no change to the local network module + should be necessary. + +APPENDIX I. INTERNET GROUP MANAGEMENT PROTOCOL (IGMP) + + The Internet Group Management Protocol (IGMP) is used by IP hosts to + report their host group memberships to any immediately-neighboring + multicast routers. IGMP is an asymmetric protocol and is specified + here from the point of view of a host, rather than a multicast + router. (IGMP may also be used, symmetrically or asymmetrically, + between multicast routers. Such use is not specified here.) + + Like ICMP, IGMP is a integral part of IP. It is required to be + implemented 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 of concern to hosts + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Group Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Deering [Page 10] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + + Version + + This memo specifies version 1 of IGMP. Version 0 is specified + in RFC-988 and is now obsolete. + + Type + + There are two types of IGMP message of concern to hosts: + + 1 = Host Membership Query + 2 = Host Membership Report + + Unused + + Unused field, zeroed when sent, ignored when received. + + Checksum + + The checksum is the 16-bit one's complement of the one's + complement sum of the 8-octet IGMP message. For computing + the checksum, the checksum field is zeroed. + + Group Address + + In a Host Membership Query message, the group address field + is zeroed when sent, ignored when received. + + In a Host Membership Report message, the group address field + holds the IP host group address of the group being reported. + +Informal Protocol Description + + Multicast routers send Host Membership Query messages (hereinafter + called Queries) to discover which host groups have members on their + attached local networks. Queries are addressed to the all-hosts + group (address 224.0.0.1), and carry an IP time-to-live of 1. + + Hosts respond to a Query by generating Host Membership Reports + (hereinafter called Reports), reporting each host group to which they + belong on the network interface from which the Query was received. + In order to avoid an "implosion" of concurrent Reports and to reduce + the total number of Reports transmitted, two techniques are used: + + 1. When a host receives a Query, rather than sending Reports + immediately, it starts a report delay timer for each of its + group memberships on the network interface of the incoming + Query. Each timer is set to a different, randomly-chosen + value between zero and D seconds. When a timer expires, a + + + +Deering [Page 11] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + + Report is generated for the corresponding host group. Thus, + Reports are spread out over a D second interval instead of + all occurring at once. + + 2. A Report is sent with an IP destination address equal to the + host group address being reported, and with an IP + time-to-live of 1, so that other members of the same group on + the same network can overhear the Report. If a host hears a + Report for a group to which it belongs on that network, the + host stops its own timer for that group and does not generate + a Report for that group. Thus, in the normal case, only one + Report will be generated for each group present on the + network, by the member host whose delay timer expires first. + Note that the multicast routers receive all IP multicast + datagrams, and therefore need not be addressed explicitly. + Further note that the routers need not know which hosts + belong to a group, only that at least one host belongs to a + group on a particular network. + + There are two exceptions to the behavior described above. First, if + a report delay timer is already running for a group membership when a + Query is received, that timer is not reset to a new random value, but + rather allowed to continue running with its current value. Second, a + report delay timer is never set for a host's membership in the all- + hosts group (224.0.0.1), and that membership is never reported. + + If a host uses a pseudo-random number generator to compute the + reporting delays, one of the host's own individual IP address should + be used as part of the seed for the generator, to reduce the chance + of multiple hosts generating the same sequence of delays. + + A host should confirm that a received Report has the same IP host + group address in its IP destination field and its IGMP group address + field, to ensure that the host's own Report is not cancelled by an + erroneous received Report. A host should quietly discard any IGMP + message of type other than Host Membership Query or Host Membership + Report. + + Multicast routers send Queries periodically to refresh their + knowledge of memberships present on a particular network. If no + Reports are received for a particular group after some number of + Queries, the routers assume that that group has no local members and + that they need not forward remotely-originated multicasts for that + group onto the local network. Queries are normally sent infrequently + (no more than once a minute) so as to keep the IGMP overhead on hosts + and networks very low. However, when a multicast router starts up, + it may issue several closely-space Queries in order to quickly build + up its knowledge of local memberships. + + + +Deering [Page 12] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + + When a host joins a new group, it should immediately transmit a + Report for that group, rather than waiting for a Query, in case it is + the first member of that group on the network. To cover the + possibility of the initial Report being lost or damaged, it is + recommended that it be repeated once or twice after short delays. (A + simple way to accomplish this is to act as if a Query had been + received for that group only, setting the group's random report delay + timer. The state transition diagram below illustrates this + approach.) + + Note that, on a network with no multicast routers present, the only + IGMP traffic is the one or more Reports sent whenever a host joins a + new group. + +State Transition Diagram + + IGMP behavior is more formally specified by the state transition + diagram below. A host may be in one of three possible states, with + respect to any single IP host group on any single network interface: + + - Non-Member state, when the host does not belong to the group + on the interface. This is the initial state for all + memberships on all network interfaces; it requires no storage + in the host. + + - Delaying Member state, when the host belongs to the group on + the interface and has a report delay timer running for that + membership. + + - Idle Member state, when the host belongs to the group on the + interface and does not have a report delay timer running for + that membership. + + There are five significant events that can cause IGMP state + transitions: + + - "join group" occurs when the host decides to join the group on + the interface. It may occur only in the Non-Member state. + + - "leave group" occurs when the host decides to leave the group + on the interface. It may occur only in the Delaying Member + and Idle Member states. + + - "query received" occurs when the host receives a valid IGMP + Host Membership Query message. To be valid, the Query message + must be at least 8 octets long and have a correct IGMP + checksum. A single Query applies to all memberships on the + interface from which the Query is received. It is ignored for + + + +Deering [Page 13] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + + memberships in the Non-Member or Delaying Member state. + + - "report received" occurs when the host receives a valid IGMP + Host Membership Report message. To be valid, the Report + message must be at least 8 octets long, have a correct IGMP + checksum, and contain the same IP host group address in its IP + destination field and its IGMP group address field. A Report + applies only to the membership in the group identified by the + Report, on the interface from which the Report is received. + It is ignored for memberships in the Non-Member or Idle Member + state. + + - "timer expired" occurs when the report delay timer for the + group on the interface expires. It may occur only in the + Delaying Member state. + + All other events, such as receiving invalid IGMP messages, or IGMP + messages other than Query or Report, are ignored in all states. + + There are three possible actions that may be taken in response to the + above events: + + - "send report" for the group on the interface. + + - "start timer" for the group on the interface, using a random + delay value between 0 and D seconds. + + - "stop timer" for the group on the interface. + + + + + + + + + + + + + + + + + + + + + + + +Deering [Page 14] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + + In the following diagram, each state transition arc is labelled with + the event that causes the transition, and, in parentheses, any + actions taken during the transition. + + ________________ + | | + | | + | | + | | + --------->| Non-Member |<--------- + | | | | + | | | | + | | | | + | |________________| | + | | | + | leave group | join group | leave group + | (stop timer) |(send report, | + | | start timer) | + ________|________ | ________|________ + | |<--------- | | + | | | | + | |<-------------------| | + | | query received | | + | Delaying Member | (start timer) | Idle Member | + | |------------------->| | + | | report received | | + | | (stop timer) | | + |_________________|------------------->|_________________| + timer expired + (send report) + + The all-hosts group (address 224.0.0.1) is handled as a special case. + The host starts in Idle Member state for that group on every + interface, never transitions to another state, and never sends a + report for that group. + +Protocol Parameters + + The maximum report delay, D, is 10 seconds. + + + + + + + + + + + + +Deering [Page 15] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + +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 routers do not + need to maintain a list of individual members of each host group. + For example, a multicast router 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 group source address may result in error reports + being returned to all members of the group, not just the sender. In + + + +Deering [Page 16] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + + view of these hazards, this memo specifies the use of host group + addresses only in the IP destination address field. However, it is + recommended that datagrams with a group source address, or a group + address as part of a source routing option, be accepted without + complaint, thereby allowing other implementations to experiment with + logical addressing applications of host group addresses. + +Allocation of Transient Host Group Addresses + + This memo does not specify how transient group address are allocated. + It is anticipated that different portions of the IP transient host + group address space will be allocated using different techniques. + For example, there may be a number of servers that can be contacted + to acquire a new transient group address. Some higher-level + protocols (such as VMTP, specified in RFC-1045) may generate higher- + level transient "process group" or "entity group" addresses which are + then algorithmically mapped to a subset of the IP transient host + group addresses, similarly to the way that IP host group addresses + are mapped to Ethernet multicast addresses. A portion of the IP + group address space may be set aside for random allocation by + applications that can tolerate occasional collisions with other + multicast users, perhaps generating new addresses until a suitably + "quiet" one is found. + + In general, a host cannot assume that datagrams sent to any host + group address will reach only the intended hosts, or that datagrams + received as a member of a transient host group are intended for the + recipient. Misdelivery must be detected at a level above IP, using + higher-level identifiers or authentication tokens. Information + transmitted to a host group address should be encrypted or governed + by administrative routing controls if the sender is concerned about + unwanted listeners. + +APPENDIX III. CHANGES FROM RFC-988 + + The IP multicast extensions specified in this memo are significantly + different from those specified in RFC-988. Most of the changes are + due to a shift of responsibility away from the multicast routers + (called "multicast agents" in RFC-988) and onto the hosts. This new + distribution of responsibility is consistent with the lightweight, + soft-state gateway architecture of the Internet, and it allows the IP + multicast services (in the same way as the IP unicast services) to be + used among hosts on a single network when no router is up or present + on the network. Thus, current single-network IP broadcast + applications may be migrated to the use of IP multicast before + multicast routers are widely available. The following changes are a + consequence of this shift of responsibility: + + + + +Deering [Page 17] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + + - Private hosts groups and access keys have been eliminated. + The multicast routers are no longer considered trustworthy + controllers of group membership; it is up to hosts and their + administrators to provide their own mechanisms to prevent + unwanted eavesdropping on group communication, perhaps by + using end-to-end encryption or by imposing restrictions on the + flow of IP multicast datagrams into and out of particular + administrative domains. + + - The CreateHostGroup operation has been eliminated. The + responsibility for allocating transient host groups has been + moved from multicast routers to the hosts. See Appendix II + for a brief discussion of some ways in which hosts might do + their own transient group allocation. + + - The JoinHostGroup and LeaveHostGroup operations have become + non-blocking, because it is no longer necessary to await + approval from a multicast router when changing membership. It + is also no longer possible for a host to have its membership + revoked by a multicast router. + + - The IGMP protocol is substantially different from that in + RFC-988, reflecting the changed roles of hosts and multicast + routers. + + - The new IGMP requires that there be an "all-hosts" group. + There is no longer a need for an "all-multicast-agents" group. + + Other changes that are not related to the shift of responsibility + are: + + - The decision whether or not to loop back a multicast datagram + sent from a member of the destination group is now made at the + time the datagram is sent, rather than at the time the group + is joined. This gives the sender another degree of scope + control, beyond the IP time-to-live. + + - The handling of IP time-to-live, and of multiple network + interfaces, has been more precisely specified. + + - Hosts are no longer allowed to place an IP host group address + in a source routing option. + + - The AcceptAddress and RejectAddress operations at the local + network service interface have been renamed JoinLocalGroup and + LeaveLocalGroup to emphasize their semantic similarity to the + JoinHostGroup and LeaveHostGroup operations at the IP service + interface. + + + +Deering [Page 18] + +RFC 1054 Host Extensions for IP Multicasting May 1988 + + + - A new mapping algorithm for Ethernet multicast addresses has + been specified. + + - The organization of the memo has been changed somewhat, and a + state transition diagram has been added to the IGMP + specification. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Deering [Page 19] + |