<pre>Network Working Group                                        S. Deering
Request for Comments: 1054                          Stanford University
Obsoletes: RFC <a href="./rfc988">988</a>                                             May 1988


                  <span class="h1">Host Extensions for IP Multicasting</span>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. STATUS OF THIS MEMO</span>

   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 <a href="./rfc988">RFC-988</a>; changes from <a href="./rfc988">RFC-988</a>
   are listed in an Appendix.  Distribution of this memo is unlimited.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. INTRODUCTION</span>

   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



<span class="grey">Deering                                                         [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


   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.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. LEVELS OF CONFORMANCE</span>

   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 <a href="#section-4">section 4</a> 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 <a href="#section-4">4</a>, <a href="#section-5">5</a>, and <a href="#section-6">6</a> 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



<span class="grey">Deering                                                         [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


   implementations.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. HOST GROUP ADDRESSES</span>

   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".

   <a href="#appendix-I">Appendix I</a>I contains some background discussion of several issues
   related to host group addresses.































<span class="grey">Deering                                                         [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. MODEL OF A HOST IP IMPLEMENTATION</span>

   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.










<span class="grey">Deering                                                         [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. SENDING MULTICAST IP DATAGRAMS</span>

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Extensions to the IP Service Interface</span>

   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).

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Extensions to the IP Module</span>

   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 )




<span class="grey">Deering                                                         [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


   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.

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Extensions to the Local Network Service Interface</span>

   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.

<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. Extensions to an Ethernet Local Network Module</span>

   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.

<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>. Extensions to Local Network Modules other than Ethernet</span>

   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



<span class="grey">Deering                                                         [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


   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.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. RECEIVING MULTICAST IP DATAGRAMS</span>

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Extensions to the IP Service Interface</span>

   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 <a href="#section-6.1">section 6.1</a>).

   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.



<span class="grey">Deering                                                         [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Extensions to the IP Module</span>

   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 <a href="#section-7.3">section 7.3</a>).

   The IP module must also be extended to implement the IGMP protocol,
   specified in <a href="#appendix-I">Appendix I</a>. 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.



<span class="grey">Deering                                                         [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


   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.)

<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Extensions to the Local Network Service Interface</span>

   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.

<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>. Extensions to an Ethernet Local Network Module</span>

   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



<span class="grey">Deering                                                         [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


   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.

<span class="h3"><a class="selflink" id="section-7.5" href="#section-7.5">7.5</a>. Extensions to Local Network Modules other than Ethernet</span>

   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                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







<span class="grey">Deering                                                        [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


      Version

         This memo specifies version 1 of IGMP.  Version 0 is specified
         in <a href="./rfc988">RFC-988</a> 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



<span class="grey">Deering                                                        [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


         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.



<span class="grey">Deering                                                        [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


   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



<span class="grey">Deering                                                        [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


        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.























<span class="grey">Deering                                                        [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


   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.

                              ________________
                             |                |
                             |                |
                             |                |
                             |                |
                   ---------&gt;|   Non-Member   |&lt;---------
                  |          |                |          |
                  |          |                |          |
                  |          |                |          |
                  |          |________________|          |
                  |                   |                  |
                  | leave group       | join group       | leave group
                  | (stop timer)      |(send report,     |
                  |                   | start timer)     |
          ________|________           |          ________|________
         |                 |&lt;---------          |                 |
         |                 |                    |                 |
         |                 |&lt;-------------------|                 |
         |                 |   query received   |                 |
         | Delaying Member |    (start timer)   |   Idle Member   |
         |                 |-------------------&gt;|                 |
         |                 |   report received  |                 |
         |                 |    (stop timer)    |                 |
         |_________________|-------------------&gt;|_________________|
                                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.












<span class="grey">Deering                                                        [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


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



<span class="grey">Deering                                                        [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


   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 <a href="./rfc1045">RFC-1045</a>) 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 <a href="./rfc988">RFC-988</a>

   The IP multicast extensions specified in this memo are significantly
   different from those specified in <a href="./rfc988">RFC-988</a>.  Most of the changes are
   due to a shift of responsibility away from the multicast routers
   (called "multicast agents" in <a href="./rfc988">RFC-988</a>) 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:




<span class="grey">Deering                                                        [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


      - 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 <a href="#appendix-I">Appendix I</a>I
        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
        <a href="./rfc988">RFC-988</a>, 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.



<span class="grey">Deering                                                        [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc1054">RFC 1054</a>          Host Extensions for IP Multicasting           May 1988</span>


      - 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]
</pre>