[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 3376

Internet Engineering Task Force   Inter-Domain Multicast Routing Working Group
INTERNET-DRAFT                                         Brad Cain, Bay Networks
                                                  Steve Deering, Cisco Systems
draft-ietf-idmr-igmp-v3-00.txt              Ajit Thyagarajan, Torrent Networks
                                                             November 21, 1997
                                                              Expires May 1998


              Internet Group Management Protocol, Version 3


Status of this Memo

This document is an Internet Draft.   Internet Drafts are working
documents of the Internet Engineering  Task Force (IETF), its  Areas,
and its  Working Groups.   Note that other  groups may also  distribute
working documents  as Internet Drafts).

Internet Drafts  are draft  documents valid  for a  maximum of  six
months.  Internet Drafts may be  updated, replaced, or  obsoleted by
other  documents at any time.   It  is not appropriate  to use Internet
Drafts as  reference material or  to cite  them  other than  as a
"working  draft" or  "work  in progress."

Please check  the I-D  abstract  listing contained  in each  Internet
Draft directory to learn the current status of this or any other
Internet Draft.

Distribution of this document is unlimited.


                                  Abstract

This document specifies Version 3 of the Internet Group Management Protocol,
IGMPv3.  IGMP is the protocol used by IP systems to report their IP multicast
group memberships to neighboring multicast routers.  Version 3 of IGMP adds
support for ''source filtering'', that is, the ability for a system to report
interest in receiving packets *only* from specific source addresses, or from
*all but* specific source addresses, sent to a particular multicast address.
That information may be used by multicast routing protocols to avoid
delivering multicast packets from specific sources to networks where there
are no interested receivers.


This document is a product of the Inter-Domain Multicast Routing working
group within the Internet Engineering Task Force.  Comments are
solicited and should be addressed to the working group's mailing list at
idmr@cs.ucl.ac.uk and/or the author(s).


Cain, Deering, Thyagarajan      Expires May 1997                   [Page 1]


1.  INTRODUCTION

The Internet Group Management Protocol (IGMP) is used by IP systems (hosts
and routers) to report their IP multicast group memberships to any neighboring
multicast routers.  Note that an IP multicast router may itself be a member of
one or more multicast groups, in which case it performs both the "multicast
router part" of the protocol (to collect the membership information needed by
its multicast routing protocol) and the "group member part" of the protocol
(to inform itself and other, neighboring multicast routers of its
memberships).

IGMP is also used for other IP multicast management functions, using message
types other than those used for group membership reporting.  This document
specifies only the group membership reporting functions and messages.

This document specifies Version 3 of IGMP.  Version 1, specified in
[RFC-1112], was the first widely-deployed version and the first version to
become an Internet Standard.  Version 2, specified in [IGMPv2], added support
for "low leave latency", that is, a reduction in the time it takes for a
multicast router to learn that there are no longer any members of a particular
group present on an attached network.  Version 3 adds support for "source
filtering", that is, the ability for a system to report interest in receiving
packets *only* from specific source addresses, or from *all but* specific
source addresses, sent to a particular multicast address.  Version 3 is
designed to be interoperable with Versions 1 and 2.



2.  THE API FOR REQUESTING IP MULTICAST RECEPTION

Within an IP system, there is (at least conceptually) an Application
Programmming Interface or API used by upper-layer protocols or application
programs to ask the IP layer to enable and disable reception of packets sent
to specific IP multicast addresses.  In order to take full advantage of the
capabilities of IGMPv3, a system's IP API must support the following operation
(or any logical equivalent):

          IPMulticastListen ( socket, interface, multicast-address,
                              filter-mode, source-list )

where

   "socket" is an implementation-specific parameter used to distinguish among
   different requesting entities (e.g., programs or processes) within the
   system; the socket parameter of BSD Unix system calls is a specific
   example.

   "interface" is a local identifier of the network interface on which
   reception of the specified multicast address is to be enabled or disabled.
   Interfaces may be physical (e.g., an Ethernet interface) or virtual
   (e.g., the endpoint of a Frame Relay virtual circuit or the endpoint of an
   IP-in-IP "tunnel").  An implementation may allow a special "unspecified"
   value to be passed as the interface parameter, in which case the request
   would apply to the "primary" or "default" interface of the system (perhaps
   established by system configuration).  If reception of the same multicast
   address is desired on more than one interface, IPMulticastListen is
   invoked separately for each desired interface.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 2]


  "multicast-address" is the IP multicast address to which the request
   pertains.  If reception of more than one multicast address on a given
   interface is desired, IPMulticastListen is invoked separately for
   each desired multicast address.

   "filter-mode" may be either INCLUDE or EXCLUDE.  In INCLUDE mode,
   reception of packets sent to the specified multicast address is requested
   *only* from those IP source addresses listed in the source-list parameter.
   In EXCLUDE mode, reception of packets sent to the given multicast address
   is requested from all IP source addresses *except* those listed in the
   source-list parameter.

   "source-list" is an unordered list of zero or more IP unicast addresses
   from which multicast reception is desired or not desired, depending on
   the filter mode.  An implementation MAY impose a limit on the size of
   source lists, but that limit MUST NOT be less than 64 addresses per list.

For a given combination of socket, interface, and multicast address, only a
single filter mode and source list can be in effect at any one time.  However,
either the filter mode or the source list, or both, may be changed by
subsequent IPMulticastListen requests that specify the same socket, interface,
and multicast address.

Previous versions of IGMP did not support source filters and had a simpler
API consisting of Join and Leave operations to enable and disable reception of
a given multicast address (from *all* sources) on a given interface.  Those
Join and Leave operations are supported by the new API as follows:

   The Join operation is equivalent to

          IPMulticastListen ( socket, interface, multicast-address,
                              EXCLUDE, {} )

   and the Leave operation is equivalent to

          IPMulticastListen ( socket, interface, multicast-address,
                              INCLUDE, {} )

   where {} is an empty source list.

It is recommended that implementations continue to support the old API,
(perhaps as calls on the new API) for compatibility with pre-existing IP
multicast applications.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 3]


3.  MULTICAST RECEPTION STATE MAINTAINED BY SYSTEMS


3.1  Socket State

For each socket on which IPMulticastListen has been invoked, the system
records the desired multicast reception state for that socket.  That state
conceptually consists of a set of records of the form:

          (interface, multicast-address, filter-mode, source-list)

The socket state evolves in response to each invocation of IPMulticastListen
on the socket, as follows:

  o If the requested filter mode is INCLUDE *and* the requested source list is
    empty, then the entry corresponding to the requested interface and
    multicast address is deleted if present.  If no such entry is present, the
    request is ignored.

  o If the requested filter mode is EXCLUDE *or* the requested source list is
    non-empty, then the entry corresponding to the requested interface and
    multicast address, if present, is updated to contain the requested
    filter mode and source list.  If no such entry is present, a new entry is
    created, using the parameters specified in the request.


3.2  Interface State

In addition to the per-socket multicast reception state, a system must also
maintain or compute multicast reception state for each of its interfaces.
That state conceptually consists of a set of records of the form:

              (multicast-address, filter-mode, source-list)

This per-interface state is derived from the per-socket state, but may differ
from the per-socket state when different sockets have differing filter modes
and/or source lists for the same multicast address and interface.  For
example, suppose one application or process invokes the following operation on
socket s1:

          IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} )

requesting reception on interface i of packets sent to multicast address m,
*only* if they come from source a, b, or c.  Suppose another application or
process invokes the following operation on socket s2:

          IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} )

requesting reception on the same interface i of packets sent to the same
multicast address m, *only* if they come from sources b, c, or d.  In order to
satisfy the reception requirements of both sockets, it is necessary for
interface i to receive packets sent to m from any one of the sources a, b, c,
or d.  Thus, in this example, the reception state of interface i for multicast
address m has filter mode INCLUDE and source list {a, b, c, d}.


Cain, Deering, Thyagarajan      Expires May 1997                   [Page 4]


(After a multicast packet has been accepted from an interface by the IP layer,
its subsequent delivery to the application or process listening on a
particular socket depends on the multicast reception state of that socket
[and possibly also on other conditions, such as what transport-layer port the
socket is bound to].  So, in the above example, if a packet arrives on
interface i, destined to multicast address m, with source address a, it may
be delivered on socket s1 but not on socket s2.)

The general rules for deriving the per-interface state from the per-socket
state are as follows:  For each distinct (interface, multicast-address) pair
that appears in any socket state, a per-interface record is created for that
multicast address on that interface.  Considering all socket records
containing the same (interface, multicast-address) pair,

  o if *any* such record has a filter mode of EXCLUDE, then the filter mode
    of the interface record is EXCLUDE, and the source list of the interface
    record is the intersection of the source lists of all socket records in
    EXCLUDE mode, minus those source addresses that appear in any socket
    record in INCLUDE mode.  For example, if the socket records for multicast
    address m on interface i are:

          from socket s1:  ( i, m, EXCLUDE, {a, b, c, d} )
          from socket s2:  ( i, m, EXCLUDE, {b, c, d, e} )
          from socket s3:  ( i, m, INCLUDE, {d, e, f} )

    then the corresponding interface record on interface i is:

                           ( m, EXCLUDE, {b, c} )

  o if *all* such records have a filter mode of INCLUDE, then the filter mode
    of the interface record is INCLUDE, and the source list of the interface
    record is the union of the source lists of all the socket records.  For
    example, if the socket records for multicast address m on interface i are:

          from socket s1:  ( i, m, INCLUDE, {a, b, c} )
          from socket s2:  ( i, m, INCLUDE, {b, c, d} )
          from socket s3:  ( i, m, INCLUDE, {e, f} )

    then the corresponding interface record on interface i is:

                           ( m, INCLUDE, {a, b, c, d, e, f} )

    *However*, there is one exception to this rule: if the source list in an
    interface record in INCLUDE mode would contain too many addresses to fit
    in an IGMP Version 3 Membership Report message (see paragraph 4.2.5), an
    interface record of the following form is created instead:

                           ( m, EXCLUDE, {} )

    That is, reception of packets to multicast address m from *all* sources is
    enabled on the interface, whenever the specific list of desired sources is
    too long to include in an IGMP Report.   The exact limit depends on the
    MTU of the attached network; on Ethernet, for example, the limit is 366
    addresses.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 5]


The above rules for deriving the interface state are (re-)evaluated whenever
an IPMulticastListen invocation modifies the socket state by adding, deleting,
or modifying a per-state record.  Note that a change of socket state does not
necessarily result in a change of interface state.



4.  MESSAGE FORMATS

IGMP messages are encapsulated in IP datagrams, with an IP protocol number
of 2.  Every IGMP message described in this document is sent with an IP
Time-to-Live of 1, and carries an IP Router Alert option [RFC2113] in its
IP header.

There are two IGMP message types of concern to the IGMPv3 protocol described
in this document:

    Type Number (hex)   Message Name
    -----------------   ------------

          0x11          Membership Query

          0x22          Version 3 Membership Report

An implementation of IGMPv3 must also support the following three message
types, for interoperation with previous versions of IGMP (see section ?):

          0x12          Version 1 Membership Report    [RFC-1112]

          0x16          Version 2 Membership Report    [IGMPv2]

          0x17          Version 2 Leave Group          [IGMPv2]

Unrecognized message types MUST be silently ignored.  Other message types
may be used by newer versions or extensions of IGMP, by multicast routing
protocols, or for other uses.

In this document, unless otherwise qualified, the capitalized words "Query"
and "Report" refer to IGMP Membership Queries and IGMP Version 3 Membership
Reports, respectively.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 6]


4.1  Membership Query Message

Membership Queries are sent by IP multicast routers to query the multicast
reception state of neighboring interfaces.  Queries 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 = 0x11  | Max Resp Time |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Group Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Reserved           |     Number of Sources (N)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address [1]                      |
   +-                                                             -+
   |                       Source Address [2]                      |
   +-                              .                              -+
   .                               .                               .
   .                               .                               .
   +-                                                             -+
   |                       Source Address [N]                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


4.1.1   Max Response Time

     The Max Response Time field specifies the maximum time allowed before
     sending a responding report, in units of 1/10 second.

     Varying this setting allows IGMPv3 routers to tune the "leave
     latency" (the time between the moment the last host leaves a group
     and the moment the routing protocol is notified that there are no more
     members).  It also allows tuning of the burstiness of IGMP traffic on
     a network.

4.1.2  Checksum

     The Checksum is the 16-bit one's complement of the one's complement
     sum of the whole IGMP message (the entire IP payload).  For
     computing the checksum, the Checksum field is set to zero.  When
     receiving packets, the checksum MUST be verified before processing
     a packet.

4.1.3  Group Address

     The Group address field is set to zero when sending a General Query,
     and set to the IP multicast address being queried when sending a
     Group-Specific Query or Group-and-Source-Specific Query (see section
     4.1.8, below).

4.1.4  Reserved

     The Reserved field is set to zero on transmission, and ignored on
     reception.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 7]


4.1.5  Number of Sources (N)

    The Number of Sources (N) field specifies how many source addresses are
    present in the Query.  This number is zero in a General Query or a
    Group-Specific Query, and non-zero in a Group-and-Source-Specific Query.
    This number is limited by the MTU of the network over which the Query is
    transmitted.  For example, on an Ethernet with an MTU of 1500 octets,
    the IP header including the Router Alert option consumes 24 octets, and
    the IGMP fields up to including the Number of Sources (N) field consume
    12 octets, leaving 1464 octets for source addresses, which limits the
    number of source addresses to 366 (1464/4).

4.1.6  Source Address [i]

    The Source Address [i] fields are a vector of n IP unicast addresses,
    where n is the value in the Number of Sources (N) field.

4.1.7  Additional Data

    If the Packet Length field in the IP header of a received Query indicates
    that there are additional octets of data present, beyond the fields
    described here, IGMPv3 implementations MUST include those octets in
    the computation to verify the received IGMP Checksum, but MUST otherwise
    ignore those additional octets.  When sending a Query, an IGMPv3
    implementation MUST NOT include additional octets beyond the fields
    described here.

4.1.8  Query Variants

There are three variants of the Query message:

    (1) A "General Query" is sent by a multicast router to learn the complete
        multicast reception state of the neighboring interfaces (that is,
        the interfaces attached to the network on which the Query is
        transmitted).  In a General Query, both the Group Address field and
        the Number of Sources (N) field are zero.

    (2) A "Group-Specific Query" is sent by a multicast router to learn the
        reception state, with respect to a *single* multicast address, of the
        neighboring interfaces.  In a Group-Specific Query, the Group Address
        field contains the multicast address of interest, and the Number of
        Sources (N) field contains zero.

    (2) A "Group-and-Source-Specific Query" is sent by a multicast router to
        learn if any neighboring interface desires reception of packets sent
        to a specified multicast address, from any of a specified list of
        sources.  In a Group-and-Source-SPecific Query, the Group Address
        field contains the multicast address of interest, and the Source
        Address [i] fields contain the source address(es) of interest.

4.1.9  IP Destination Addresses for Queries

In IGMPv3, General Queries are sent with an IP destination address of
224.0.0.1, the all-systems multicast address.  Group and Group-and-Source
Queries are sent with an IP destination address equal to the multicast address
of interest.  *However*, a system MUST accept and process any Query whose IP
Destination Address field contains *any* of the addresses (unicast or
multicast) assigned to the interface on which the Query arrives.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 8]


4.2  Version 3 Membership Report Message

Version 3 Membership Reports are sent by IP systems to report (to neighboring
routers) the current multicast reception state, or changes in the multicast
reception state, of their interfaces.  Reports 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 = 0x22  |    Reserved   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |  Number of Group Records (M)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [1]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [2]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   .
                                   .
                                   .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [M]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


where each Group Record has the following internal format:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Record Type  |    Reserved   |     Number of Sources (N)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Multicast Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address [1]                      |
   +-                                                             -+
   |                       Source Address [2]                      |
   +-                              .                              -+
   .                               .                               .
   .                               .                               .
   +-                                                             -+
   |                       Source Address [N]                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 9]


4.2.1  Reserved

    The Reserved fields are set to zero on transmission, and ignored on
    reception.

4.2.2  Checksum

    The Checksum is the 16-bit one's complement of the one's complement
    sum of the whole IGMP message (the entire IP payload).  For
    computing the checksum, the Checksum field is set to zero.  When
    receiving packets, the checksum MUST be verified before processing
    a message.

4.2.3  Number of Group Records (M)

    The Number of Group Records (M) field specifies how many Group Records
    are present in this Report.

4.2.4  Group Record

    Each Group Record is a block of fields containing information pertaining
    to the sender's membership in a single multicast group on the interface
    from which the Report is sent.

4.2.4  Record Type

    See section 4.2.9, below.

4.2.5  Number of Sources (N)

    The Number of Sources (N) field specifies how many source addresses are
    present in this Group Record.

4.2.6  Multicast Address

    The Multicast Address field contains the IP multicast address to which
    this Group Record pertains.

4.2.7  Source Address [i]

    The Source Address [i] fields are a vector of n IP unicast addresses,
    where n is the value in this record's Number of Sources (N) field.

4.2.8  Additional Data

    If the Packet Length field in the IP header of a received Report indicates
    that there are additional octets of data present, beyond the last Group
    Record, IGMPv3 implementations MUST include those octets in the
    computation to verify the received IGMP Checksum, but MUST otherwise
    ignore those additional octets.  When sending a Report, an IGMPv3
    implementation MUST NOT include additional octets beyond the last Group
    Record.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 10]


4.2.9  Group Record Types

There are a number of different types of Group Records that may be included
in a Report message:

    (1) A "Current-State Record" is sent by a system in response to a Query
        received on an interface.  It reports the current reception state of
        that interface, with respect to a single multicast address.  The
        Record Type of a Current-State Record may be one of the following
        two values:

          Value  Name and Meaning
          -----  ----------------

            1    MODE_IS_INCLUDE - indicates that the interface has a filter
                          mode of INCLUDE for the specified multicast address.
                          The Source Address [i] fields in this Group Record
                          contain the interface's source list for the
                          specified multicast address, if it is non-empty.

            2    MODE_IS_EXCLUDE - indicates that the interface has a filter
                          mode of EXCLUDE for the specified multicast address.
                          The Source Address [i] fields in this Group Record
                          contain the interface's source list for the
                          specified multicast address, if it is non-empty.

    (2) A "Filter-Mode-Change Record" is sent by a system whenever a local
        invocation of IPMulticastListen causes a change of the filter mode
        (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to INCLUDE),
        of the interface-level state entry for a particular multicast address.
        The Record is included in a Report sent from the interface on which
        the change occurred.  The Record Type of a Filter-Mode-Change Record
        may be one of the following two values:

            3    CHANGE_TO_INCLUDE_MODE - indicates that the interface has
                          changed to INCLUDE filter mode for the specified
                          multicast address.  The Source Address [i] fields
                          in this Group Record contain the interface's new
                          source list for the specified multicast address,
                          if it is non-empty.

            4    CHANGE_TO_EXCLUDE_MODE - indicates that the interface has
                          changed to EXCLUDE filter mode for the specified
                          multicast address.  The Source Address [i] fields
                          in this Group Record contain the interface's new
                          source list for the specified multicast address,
                          if it is non-empty.

    (3) A "Source-List-Change Record" is sent by a system whenever a local
        invocation of IPMulticastListen causes a change of source list
        that is *not* coincident with a change of filter mode, of the
        interface-level state entry for a particular multicast address.
        The Record is included in a Report sent from the interface on which
        the change occurred.  The Record Type of a Source-List-Change Record
        may be one of the following two values:

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 11]


            5    ALLOW_NEW_SOURCES - indicates that the Source Address [i]
                          fields in this Group Record contain a list of the
                          additional sources that the system wishes to
                          hear from, for packets sent to the specified
                          multicast address.  If the change was to an INCLUDE
                          source list, these are the addresses that were added
                          to the list; if the change was to an EXCLUDE source
                          list, these are the addresses that were deleted from
                          the list.

            6    BLOCK_OLD_SOURCES - indicates that the Source Address [i]
                          fields in this Group Record contain a list of the
                          sources that the system no longer wishes to
                          hear from, for packets sent to the specified
                          multicast address.  If the change was to an INCLUDE
                          source list, these are the addresses that were
                          deleted from  the list; if the change was to an
                          EXCLUDE source list, these are the addresses that
                          were added to the list.

        If a change of source list results in both allowing new sources and
        blocking old sources, then two Group Records are sent for the same
        multicast address, one of type ALLOW_NEW_SOURCES and one of type
        BLOCK_OLD_SOURCES.

We use the term "State-Change Record" to refer to either a Filter-Mode-Change
Record or a Source-List-Change Record.

Unrecognized Record Type values MUST be silently ignored.

4.2.10  IP Destination Addresses for Reports

Version 3 Reports are sent with an IP destination address of 224.0.0.?, the
all-membership-reports multicast group address.  A system that is operating in
version 1 or version 2 compatibility modes sends version 1 and version 2
Reports to the multicast group specified in the Group Address field of the
Report.  In addition, a system MUST accept and process any version 1 or
version 2 Report whose IP Destination Address field contains *any* of the
addresses (unicast or multicast) assigned to the interface on which the Report
arrives.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 12]


4.2.11  Notation for Group Records

In the rest of this document, we use the following notation to describe the
contents of a Group Record pertaining to a particular multicast address:

        IS_IN ( x )  -  Type MODE_IS_INCLUDE, source addresses x
        IS_EX ( x )  -  Type MODE_IS_EXCLUDE, source addresses x
        TO_IN ( x )  -  Type CHANGE_TO_INCLUDE_MODE, source addresses x
        TO_EX ( x )  -  Type CHANGE_TO_EXCLUDE_MODE, source addresses x
        ALLOW ( x )  -  Type ALLOW_NEW_SOURCES, source addresses x
        BLOCK ( x )  -  Type BLOCK_OLD_SOURCES, source addresses x

where x is either:

        - a capital letter (e.g., "A") to represent the set of source
          addresses,

        - a list of zero or more lower-case letters enclosed in braces
          (e.g., "{a, b, c}" or "{}") to represent the individual source
          addresses in the list, or

        - a set expression (e.g., "A + B"), where "x + y" means the union of
          x and y,  "x * y" means the intersection of x and y, and "x - y"
          means the removal of all elements of set y from set x.

4.2.12 Membership Report Size

If the entire list of Group Records does not fit within the MTU limits of a
single Report message, the Group Records are sent in as many Report
messages required to report the entire list of Group Records.  Each Report
is filled with the maximum number of Group Records within the MTU limit.

Similarly, if the list of source addresses comprising a single Group Record
does not fit within the MTU limits of a single Report message, the Group
Record is sent in as many Report messages required to report the entire list
of sources.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 13]


5.  PROTOCOL DESCRIPTION

The purpose of IGMP is to enable each multicast router to learn, for each of
its directly attached networks, which multicast addresses are of interest to
the systems attached to those networks.  This information is then provided to
whichever multicast routing protocol is being used by the router, in order to
ensure that multicast packets are delivered to all networks where there are
interested receivers.

IGMP version 3 adds the capability for a multicast router to learn which
*sources* are of interest to neighboring systems, for packets sent to any
particular multicast address.

It is important to understand that a multicast router needs to know only that
*at least one* system on an attached network is interested in packets to a
particular multicast address from a particular source; the multicast router
does not need to keep track of the interests of each individual neighboring
system.

IGMP is an asymmetric protocol, defining separate behaviors for group members
-- that is, hosts or routers that wish to receive multicast packets -- and
multicast routers.  A multicast router that is also a group member performs
both parts of the protocol, receiving its own IGMP message transmissions as
well as those of its neighbors.

If a multicast router has more than one interface on the same network, it
needs to operate the multicast router part of IGMP over only one of those
interfaces.  A group member, on the other hand, must operate the group
member part of IGMP over all interfaces from which reception of multicast
packets has been requested by IPMulticastListen invocations.

Membership in the all-systems multicast group, address 224.0.0.1, is handled
as a special case: reception of packets destined to the all-systems multicast
address, from all sources, is permanently enabled on all interfaces on which
multicast reception is supported.  No IGMP messages are ever sent regarding
the all-systems multicast address.

Note that, in the following descriptions, timer and counter names appear in
square brackets.  The default values for those timers and counters are
specified in section 7.


5.1  Group Member Behavior

For interoperability with multicast routers running older versions of IGMP,
systems maintain a MulticastRouterVersion variable for each interface on which
multicast reception is desired.  This section describes the behavior of group
member systems on interfaces for which MulticastRouterVersion = 3.  The
algorithm for determining MulticastRouterVersion, and the behavior for
versions other than 3, are described in section 6.1.

There are three types of events that trigger IGMP protocol actions on an
interface on which multicast reception is enabled:

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 14]


  o a change of the interface reception state, caused by a local invocation of
    IPmulticastListen.

  o reception of a Query.

  o reception of a Report.

The following subsections describe the actions to be taken for each of those
cases.

5.1.1  Action on Change of Interface State

An invocation of IPMulticastListen may cause the multicast reception state of
an interface to change, according to the rules in section 3.2.  Each such
change affects the per-interface entry for a single multicast address.

A change of interface state causes the system immediately to transmit a State-
Change Report from that interface, with the Group field of the Report carrying
the affected multicast address.  The contents of the rest of the report are
determined by comparing the filter mode and source list for that multicast
address before and after the change, according to the table below.  If no
interface state existed for that multicast address before the change (i.e.,
the change consisted of creating a new per-interface record), or if no state
exists after the change (i.e., the change consisted of deleting a per-
interface record), then the "non-existant" state is considered to have a
filter mode of INCLUDE and an empty source list.

  Old State         New State         State-Change Report Sent
  ---------         ---------         ------------------------

  INCLUDE (A)       INCLUDE (B)       ALLOW (B-A), BLOCK (A-B)

  EXCLUDE (A)       EXCLUDE (B)       ALLOW (A-B), BLOCK (B-A)

  INCLUDE (A)       EXCLUDE (B)       TO_EX (B)

  EXCLUDE (A)       INCLUDE (B)       TO_IN (B)

To cover the possibility of the State-Change Report being missed by one or
more multicast routers, it is retransmitted [Robustness Variable] - 1 more
times, at intervals chosen at random from the range (0, [Unsolicited Report
Interval]].

If more changes to the same interface state entry occur before all the
retransmissions of the State-Change Report for the first change have been
completed, each such additional change triggers the immediate transmission of
a State-Change Report reflecting the difference between the newest state and
the state *before* the first change for which retransmissions were not
completed.  The transmission of the newer State-Change Report terminates
retransmissions of the earlier State-Change Reports for the same multicast
address, and becomes the first of [Robustness Variable] transmissions of the
newer Report.


Cain, Deering, Thyagarajan      Expires May 1997                   [Page 15]


5.1.2  Action on Reception of a Query

A system may receive any of the three variants of IGMPv3 Query messages: a
General Query, a Group-Specific Query, or a Group-and-Source-Specific Query
(see section 4.1.8).

When a system receives a General Query, it adjusts the global "report delay
timer" on the interface from which the Query was received.  If the timer is
not running, it is set to a random value, using the finest clock granularity
available on the system, from the range (0, MaxResponseTime], where
MaxResponseTime is obtained from the Query message.  If the global report
timer is already running, it is reset to a new random value only if the
requested MaxResponseTime is less than the remaining value of the running
timer.  Otherwise, it is left running with its current value.

When the global report timer expires, the system transmits one or more
Reports reporting for each multicast address present on that interface, its
filter mode (either MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and the list of
sources associated with the multicast address; any group-specific report
delay timers, if running, on that interface are deleted as well.  If there
is a change in filter mode or source address list of a multicast group with
the global report delay timer still running, a State-Change Report is sent
for that multicast group address as specified in Section 5.1.1; the global
report delay timer is not deleted.

When a system receives a Group-Specific Query, it performs a similar set of
actions as it does when receiving a General Query, *except* that the actions
are performed only for the multicast address that was specified in the
Group-Specific Query and using the "group-specific report delay timer"
instead of the global timer.

When a multicast group address's report delay timer expires, the system
transmits a Report, reporting that multicast address and the filter mode
(either MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and the entire list of sources
addresses associated with the multicast address.

When a system receives a Group-and-Source-Specific Query, it performs the same
actions as it does when receiving a Group-Specific Query, *except*:

  o the pending report record and report delay timer it creates are
    *in addition to* any record and timer it may have created for the same
    multicast address in response to a General or Group-Specific Query.

  o the initial contents of the newly-created pending report record are
    determined by comparing the source list in the received Query with the
    local state, as specified in the following table:

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 16]


    Local State       Query Source List       Pending Report Record
    -----------       -----------------       ---------------------

    INCLUDE (A)             B                 IS_IN (A*B)

    EXCLUDE (A)             B                  IS_IN (B-A)


Cain, Deering, Thyagarajan      Expires May 1997                   [Page 17]


5.2  Multicast Router Behavior

5.2.1 Overview

Multicast routers use the IGMP protocol to periodically query the multicast
reception state of hosts attached to local subnetworks. General Queries are
sent periodically; Group-Specific and Group-and-Source-Specific Queries are
sent in response to Filter-Mode-Change and Source-List-Change records.

IGMPv3 is backward compatible with previous versions of the IGMP protocol.
In order to remain backward compatible with older IGMP hosts and routers,
IGMPv3 routers must also implement versions 1 and 2 of the protocol
(see section 6).


5.2.2  Conditions for IGMP Queries

IGMPv3 routers send General Queries periodically to request group membership
information.  Hosts respond to these queries with Current-State Reports.  As
hosts update the state of individual Group Records, they may send send
Filter-Mode-Change Records or Source-List-Change Records.  In order for all
hosts on a subnet to respond to changes in group membership, a router sends
specific queries.  A Group-Specific Query is sent to verify there are no
neighboring interfaces that desire reception of the specified group.  A
Group-and-Source Specific Query lists sources within a group that have been
requested to be deleted (i.e. not forwarded).  This query is sent by a
router to learn if any neighboring interfaces desire reception of packets to
the specified group address from the specified source addresses.  Section
4.1.8 describes each query in more detail.


5.2.3  IGMP State Maintained by Multicast Routers

Routers implementing the IGMPv3 protocol must keep keep state per group
per interface.  This state consists of a filter-mode, list of sources, and
various timers.  For each interface on which IGMP exists, a router records
the desired reception state for that locally attached network.  That state
conceptually consists of a set of records of the form:

      (multicast address, group timer, filter-mode, source-element list)

Each member of the source-element list is a record of the form:

      (source address, source timer)

If all sources within a given group are desired, an empty source element list
is kept with the filter-mode set to EXCLUSION.  This means forward all
sources for this group. This is equivalent to the older version join of
single group (i.e.  as in previous versions of IGMP).


5.2.3.1 Definition of Router Filter-Mode

To reduce internal state, IGMPv3 routers keep a filter-mode per group per
interface.  This filter-mode is used to condense the total desired reception
state of a group to a minimum set such that all systems memberships are
satisfied.  The filter-mode of a group record may change when receiving new
reports, or when certain timer conditions occur.  Upon receiving a host
report, the filter-mode is updated to represent the most number of sources
desired with the least amount of state.  In general, once a filter-mode of
EXCLUSION is received, the router filter-mode for that group record will be
EXCLUSION.  A mechanism to transition back to an INCLUSION filter-mode is
specified as all hosts with EXCLUSION filter-mode may cease reporting,
leaving the router filter-mode in an EXCLUSION state.  Section 5.2.5
describes the changes of a router-filter mode per host report received.
Section 5.2.6 describes the change in filter-mode when certain timer
conditions are met.


5.2.3.2 Definition Group Timers

A group timer is kept per group per interface state record.  A group timer
is a decrementing timer with a lower bound of zero.  Group timers are updated
according to the filter-mode of the group record and type of host report
received.  Group timers are not always updated per a received group report.
A group timer expiring when the filter-mode is INCLUSION means there are no
listeners on the attached subnet for that group.  A group timer expiring
when the filter-mode is EXCLUSION means there are no listeners on the
attached subnet in EXCLUSION mode.  Section 5.2.5 details the exact setting
of the group timer per filter mode and report received.  Section 5.2.6
details the events when a group timer expires while in EXCLUSION mode.


5.2.3.3 Definition of Source Timers

A source timer is kept per source element record.  A source timer is a
decrementing timer with a lower bound of zero.  Source timers are updated
according to the filter-mode of the group record and type of host report
received.  Unlike group timers, source timers are always updated for a
particular group whenever the source is present in a received record for
that group.  Section 5.2.5 details the exact setting of the source timer per
filter mode and report received.

The actions performed upon the expiry of source element timers depend upon
the group filter-mode.  If a source timer expires with the group in
INCLUSION filter-mode, the router concludes that traffic from this particular
source is no longer desired on the locally attached interface, and deletes the
associated record.  If a source timer expires with the group in EXCLUSION
filter-mode, the router stops forwarding traffic from this source onto the
interface, but does not delete its record.  Section 5.2.4 details the actions
that should be taken, dependant upon the value of a source timer.


5.2.4  IGMPv3 Source Specific Forwarding Rules

When a router receives a datagram from a source destined to a particular
group, a decision has to be made whether to forward the datagram onto
the subnetwork or not.  This decision is first dependent on any multicast
routing protocols present.  Assuming that there are no other routers
downstream (or that downstream routers support source-specific pruning/
grafting), the forwarding decision depends on the presence of a group
record and/or a source-specific record.  If no group record exists, the
datagram is not forwarded on the subnetwork.  Even if a group record exists,
a source-specific record may or may not exist for the particular source.

To summarize, the following table details the actions to be performed
for traffic originating from a source destined to a group, and upon
the expiry of a source-specific timer, based on the group mode and the
value of the source-specific timer, if it exists:

  Group
  Filter-Mode      Source Timer Value        Action
  -----------      ------------------        ------

  INCLUDE          TIMER > 0                 Forward source

  INCLUDE          TIMER == 0                Stop forwarding source and
                                               remove source record

  INCLUDE          None                      Don't forward source

  EXCLUDE          TIMER > 0                 Don't forward source

  EXCLUDE          TIMER == 0                Start forwarding source

  EXCLUDE          None                      Forward source


5.2.5  Actions upon Reception of Reports

5.2.5.1 Reception of Current-State reports

When receiving Current-State Reports, routers update both group timers and
source timers.  Depending on the routers current filter-mode for a group and
the filter-mode of a Current-State Report received for that group, a router
may change to a different filter-mode per group.  The table below details the
actions, with respect to state and timers, that occur at a router when
receiving Current-State Reports.

The following notation is used to describe the updating of source timers.
The notation ( A, B ) will be used to represent the total number of sources
for a particular group, where

          A = set of sources whose timers > 0 (being forwarded)
          B = set of sources whose timers = 0 (not being forwarded)

The variable TQ is one query period plus the time to report field of the
last General Query.  The variable RI is the time to report field of the
last send Query.

  Router State       Report Rec'd  New Router State         Actions
  ------------       ------------  ----------------         -------

  INCLUDE (A)        IS_IN (B)     INCLUDE (A+B)            (B) = TQ
                                                            Group Timer = TQ

  INCLUDE (A)        IS_EX (B)     EXCLUDE (A*B,B-A)        (B-A) = 0
                                                            Group Timer = TQ

  EXCLUDE (X,Y)      IS_IN (A)     EXCLUDE (X+A,Y-A)        (A) = TQ

  EXCLUDE (X,Y)      IS_EX (B)     EXCLUDE (X*A,Y-A)        Group Timer = TQ


5.2.5.2 Reception of Filter-Mode-Change and Source-List-Change Reports

When a change in the global state of a group occurs in a host, the host
sends either a Source-List-Change Report or a Filter-Mode-Change Report for
that group.  As with Current-State Reports, routers must act upon these
reports and possibly change their state to reflect the new desired
membership state.

Routers must query any sources that are requested to be deleted from the
network.  When a router queries a specific set of sources, it sets the
source timers to a small interval (5 secs).  If host membership reports are
received which express interest in receiving traffic from the specific
sources, the corresponding timers are updated.  Similarly, when a router
queries a specific group, it sets the group timer to a small interval
(5 secs).  If any membership reports expressing interest in the group are
received within the interval, the group timer is updated and traffic is
forwarded without any interruption.  During the interval, the router continues
to forward traffic from the sources that were requested to be deleted to
prevent traffic from being interrupted to other interested hosts.

The following table details the change in state and actions that are taken
when receiving either Filter-Mode-Change or Source-List-Change Reports
dependent upon the current state of the group.

  Router State      Report Rec'd New Router State           Actions
  ------------      ------------ ----------------           -------

  INCLUDE (A)       ALLOW (B)    INCLUDE (A+B)              (B)=TQ
                                                            Group Timer=TQ

  INCLUDE (A)       BLOCK (B)    INCLUDE (A)                (A*B)=RI
                                                            Send Q(G,A*B)

  INCLUDE (A)       ALLOW (B),   INCLUDE (A+B)              (B)=TQ
                    BLOCK (C)                               (A*C)=RI
                                                            Send Q(G,A*C)
                                                            Group Timer=TQ

  INCLUDE (A)       TO_EX (B)    EXCLUDE (A*B,B-A)          (A*B)=RI
                                                            Send Q(G,A*B )
                                                            Group Timer=TQ

  INCLUDE (A)       TO_IN (B)    INCLUDE (A+B)              (B)=TQ
                                                            (A-B)=RI
                                                            Send Q(G,A-B)
                                                            Group Timer=TQ

  EXCLUDE (X,Y)     ALLOW (A)    EXCLUDE (X+A,Y-A)          (A)=TQ

  EXCLUDE (X,Y)     BLOCK (A)    EXCLUDE (X+(A-Y),Y)        (A-Y)=RI
                                                            Send Q(G,A-Y)

  EXCLUDE (X,Y)     ALLOW (A),   EXCLUDE (X+A+(B-Y),Y-A)    (A)=TQ
                    BLOCK (B)                               (B-Y)=RI
                                                            Send Q(G,B-Y)

  EXCLUDE (X,Y)     TO_EX (A)    EXCLUDE (X*A,Y*A)          (A-Y)=RI
                                                            Send Q(G,A-Y)
                                                            Group Timer=TQ

  EXCLUDE (X,Y)     TO_IN (A)    EXCLUDE (X+A,Y-A)          (A)=TQ
                                                            (X-A)=RI
                                                            Send Q(G,*)


5.2.6  Switching Filter-Modes

The IGMPv3 group timer is used as a mechanism for transitioning from
EXCLUSION filter-mode to INCLUSION filter-mode.  When a group timer
expires with the group in INCLUSION filter-mode, a router concludes that
there are no group members present on the locally attached interface and
deletes the group record and the associated source records.

When a group timer expires with the group in EXCLUSION filter-mode, a router
assumes that there are no hosts in EXCLUSION filter-mode are present on the
attached subnetwork, and switches to INCLUSION filter-mode.  In addition,
all source-element records with zero timer values are deleted and the group
timer assumes the maximum value among all the remaining source-element
records corresponding to that group.  A Group-Specific Query is then sent
for the group to determine the desired group and source state for that group.


5.2.7  Action of Reception of Queries

IGMPv3 uses the same querier election method as previous versions.  Upon
receiving an IGMPv3 General Query from another router, the querier ceases to
send General Queries and sets the OTHER_QUERIER_PRESENT timer.  Upon expiry
of OTHER_QUERIER_PRESENT timer, a router becomes the querier.  Routers who
are not the acting querier reset OTHER_QUERIER_PRESENT timer upon reception
of a IGMPv3 General Query.  For details of compatibility between versions
see section 6.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 18]


6.  INTEROPERATION WITH OLDER VERSIONS OF IGMP

IGMP version 3 hosts and routers interoperate with hosts and routers that
have not yet been upgraded to IGMPv3.  This compatibility is maintained by
hosts and routers taking appropriate actions depending on the versions of
IGMP operating on hosts and routers within a network.


6.1  Query Version Distinctions

The IGMP version of a Host Membership Query message is determined as
follows:

   IGMPv1 Query: length = 8 octets AND Max Response Time field is zero

   IGMPv2 Query: length = 8 octets AND Max Response Time field is non-zero

   IGMPv3 Query: length >= 12 octets AND Reserved field is zero

Query messages that do not match any of the above conditions (e.g., a
Query of length 10 octets) must be silently ignored.


6.2  Group Member Behavior

IGMPv3 hosts can operate in version 1 and version 2 compatibility modes.
The mode in which a host operates is governed by the version of the querier
router on an interface.  The version of the querier can be determined
from a Host Membership Query.

IGMPv3 hosts keep state per local interface regarding the version of querier
on the attached network.  Hosts can be in one of three states depending on
the version of querier on their attached networks.  This state is reflected
by Querier Version, a state variable kept per interface describing the
version of querier on the attached network.  This state variable can have
only one of three values: IGMPv3, IGMPv2, IGMPv1.  When Querier Version is
IGMPv3, a host acts using the IGMPv3 protocol.  When Querier Version
is IGMPv2, a host acts in IGMPv2 compatibility mode, using only the IGMPv2
protocol.  When Querier Version is IGMPv1, a host acts in IGMPv1
compatibility mode, using the IGMPv1 protocol.

If a lower version query (as compared to Querier Version) is received on
an interface, this state will change immediately to reflect the older
version querier and the host will operate in that lower version
compatibility mode.  However, if a higher version query (as compared to
Querier Version) is received, it will not immediately change it's state.
This is to prevent the problem when newer version queries are sent by a
router restarting and having not yet yielded to an older version querier.

Each time a non-version 3 query is received, a host sets a timer: Older
Version Querier Present Timeout.  The state variable, Querier Version,
reflecting the version of querier on an interface will be based on this
timer.  If a host hears a newer version query (as compared to Querier
Version), it will not change its operating state until after the timer
expires.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 19]


6.2.1  In the Presence of Older Version Queriers

An IGMPv3 host may be placed on a network where the Querier router has
not yet been upgraded to IGMPv3.  The following requirements apply:

     An older version router expects older version Membership Reports in
     response to its Queries, and will not pay attention to Version 3
     Membership Reports.  Therefore, a state variable MUST be kept for each
     interface, describing whether the multicast Querier on that
     interface is running IGMPv1, IGMPv2, or IGMPv3.  This variable MUST be
     based upon whether or not the older version query was heard in the
     last [Older Version Querier Present Timeout] seconds, and MUST NOT be
     based upon the type of the last Query heard.  This state variable MUST
     be used to decide what type of Membership Reports to send for unsolicited
     Membership Reports as well as Membership Reports in response to Queries.

     Version 1 Querier

     An IGMPv1 router will send General Queries with the Max Response
     Time set to 0.  This MUST be interpreted as a value of 100 (10
     seconds).

     An IGMPv3 host MAY suppress Leave Group messages and Filter-Mode-
     Change Reports on a network where the Querier is using IGMPv1.

     Version 2 Querier

     An IGMPv3 host MAY suppress Filter-Mode-Change Reports on a network
     where the Querier is using IGMPv2.

The following table summarizes an IGMPv3 host response to different types
of queries:

  Querier
  Version  Query Type                         Host Response
  -------  ----------                         -------------
  IGMPv1   Host Membership Query              IGMPv1 Membership Report
  IGMPv2   Host Membership Query              IGMPv2 Membership Report
  IGMPv2   Group-Specific Membership Query    IGMPv2 Membership Report
  IGMPv3   Host Membership Query              IGMPv3 Membership Report
  IGMPv3   Group-Specific Membership Query    IGMPv3 Membership Report
  IGMPv3   Source-Specific Membership Query   IGMPv3 Membership Report

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 20]


6.2.2  In the Presence of Older Version Group Members

An IGMPv3 host may be placed on a network where there are hosts that have
not yet been upgraded to IGMPv3.  The following requirement applies:

     The host MUST allow its Membership Report to be suppressed by
     either a Version 1 Membership Report, or a Version 2 Membership
     Report.

     An IGMPv3 host or router MUST internally map older version reports
     to version 3 reports in the following way:

     Type of IGMP Message                Mapping
     --------------------                -------
     IGMPv1 Membership Report:           IS_EX(0) Report

     IGMPv2 Membership Report:           IS_EX(0) Report

     IGMPv2 Group Specific Query:        Q(G,*) for group being queried

     IGMPv2 Leave Message:               TO_IN(NULL) for group in leave
                                         message

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 21]


6.2.3  Group Member Compatibility State Transition Diagram


                                    RQ3
                                -----------
                                |         |
                                |         V
                RQ1/ST      -------------------   RQ2/ST
             ---------------|                 |----------------
             |              |     V3 Mode     |               |
             |      ------->|                 |<-------       |
             |      |       -------------------       |       |
             |      |                                 |       |
             |      |TE/DT                       TE/DT|       |
             |      |                                 |       |
             V      |                                 |       V
         -------------------                    -------------------
     ----|                 |                    |                 |----
  RQ3|   |    V1 Mode      |<-------------------|     V2 Mode     |   |RQ3
     --->|                 |       RQ1/RT       |                 |<---
         -------------------                    -------------------
           |    ^   |    ^                          |         ^
           |    |   |    |                          |         |
           ------   ------                          -----------
           RQ1/RT    RQ2                              RQ2/RT

  Actions
  -------
  ST : start Older Version Querier Present Timer
  DT : delete Older Version Querier Present Timer
  TE : Older Version Querier Present Timer expires
  RT : reset Older Version Querier Present Timer

  Events
  ------
  RQ1 : Receive IGMPv1 Host Membership Query
  RQ2 : Receive IGMPv2 Host Membership Query
  RQ3 : Receive IGMPv3 Host Membership Query

  States
  ------
  V3 Mode : An IGMPv3 router is the present querier on an interface.  The
            host uses IGMPv3 Membership Reports

  V2 Mode : An IGMPv2 router is the present querier on an interface.  The
            host uses IGMPv2 Membership Reports and IGMPv2 Leave Group
            messages.

  V1 Mode : An IGMPv1 router is the present querier on an interface.  The
            host uses IGMPv1 Membership Reports.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 22]


6.3  Multicast Router Behavior

6.3.1  In the Presence of Older Version Queriers

IGMPv3 routers may be placed on a network where at least one router on the
network has not not yet been upgraded to IGMPv3.  The following requirements
apply:

      If any older versions of IGMP are present on routers, the querier MUST
      use the lowest version of IGMP present on the network.
      This must be administratively assured; routers that desire to be
      compatible with IGMPv1 and IGMPv2 MUST have a configuration option to
      send IGMPv1 and IGMPv2 queries.  When in IGMPv1 mode, routers MUST
      send Periodic Queries with a Max Response Time of 0, and MUST ignore
      Leave Group messages.  They SHOULD also warn about receiving an
      IGMPv2 or IGMPv3 query, although such warnings MUST be rate-limited.

      If a router is not explicitly configured to use IGMPv1 and hears an
      IGMPv1 Query or IGMPv2 Query, it SHOULD log a warning.  These warnings
      MUST be rate-limited.


6.3.2  In the Presence of Older Version Group Members

IGMPv3 routers may be placed on a network where there are hosts that have not
yet been upgraded to IGMPv3.  The following requirements apply:

      IGMPv3 routers MUST keep state per group being forwarded per interface
      regarding the lowest version of IGMP heard.  For each group being
      forwarded per interface, the state variable Oldest Host Present is
      kept.  Groups can be in one of three states reflected by the state
      variable: Oldest Host Present.

      Routers MUST act in a compatibility mode on a per group per interface.
      The following table summarizes the types of messages to be used
      dependent on the value of Oldest Host Present.

      Oldest Host Present             Messages Utilized
      -------------------             -----------------
          IGMPv1                      Version 1 Host Membership Queries
          IGMPv2                      Version 2 Host Membership Queries,
                                      Version 2 Group-Specific Host
                                       Membership Queries
          IGMPv3                      Version 3 General Membership Queries,
                                      Version 3 Group-Specific Membership
                                       Queries,
                                      Version 3 Group-and-Source Specific
                                       Membership Queries

      A router MUST keep a timer per group, Older Host Present Timeout, if
      it hears an non-version 3 report for a group.  This SHOULD be set to
      the value of two query periods.  If a router does not hear a lower
      version report for the length of two query periods, it assumes that
      the older version members have left and reverts to version 3 operation
      for that group.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 23]


6.3.3  Router Compatibility State Transition Diagram*


                                    RV3MR
                                 -----------
                                 |         |
                                 |         V
                 RV1MR/ST     -------------------   RV2MR/ST
              ----------------|                 |----------------
              |               |     V3 Mode     |               |
              |       ------->|                 |<-------       |
              |       |       -------------------       |       |
              |       |                                 |       |
              |       |TE/DT                       TE/DT|       |
              |       |                                 |       |
              V       |                                 |       V
           -------------------                    -------------------
       ----|                 |                    |                 |----
  RV3MR|   |    V1 Mode      |<-------------------|     V2 Mode     |   |RV3MR
       --->|                 |     RV1MR/RT       |                 |<---
           -------------------                    -------------------
             |    ^   |    ^                          |         ^
             |    |   |    |                          |         |
             ------   ------                          -----------
            RV1MR/RT   RV2MR                            RV2MR/RT


                * with respect to a single multicast group

  Actions
  -------
  ST : start Older Host Present Timer
  DT : delete Older Host Present Timer
  TE : Older Host Present Timer expires
  RT : reset Older Host Present Timer

  Events
  ------
  RV1MR : Receive Version 1 Membership Report
  RV2MR : Receive Version 2 Membership Report
  RV3MR : Receive Version 3 Membership Report

  States
  ------
  V3 Mode : A router operates using only IGMPv3 messages for this group.

  V2 Mode : An IGMPv2 Membership Report has been heard for this group
            within the last Older Host Present Timeout seconds.  A router
            operates using only IGMPv2 messages for this group.

  V1 Mode : An IGMPv1 Membership Report has been heard for this group
            within the last Older Host Present Timeout seconds.  A router
            operates using only IGMPv1 messages for this group.

  Note: In V1 Mode and V2 Mode, the Host Membership Query is still a
        version 3 query.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 24]


7.  LIST OF TIMERS, COUNTERS, AND THEIR DEFAULT VALUES

Most of these timers are  configurable.   If  non-default  settings  are
used,  they MUST be consistent among all systems on a single link.  Note
that parentheses are used to  group  expressions  to  make  the  algebra
clear.

7.1.  Robustness Variable

The Robustness Variable allows tuning for the expected packet loss on a
network.  If a network is expected to be lossy, the Robustness Variable
may be increased.  IGMP is robust to (Robustness Variable - 1) packet
losses.  The Robustness Variable MUST NOT be zero, and SHOULD NOT be
one.  Default: 2

7.2.  Query Interval

The Query Interval is the interval between General Queries sent by the
Querier.  Default: 125 seconds.

By varying the [Query Interval], an administrator may tune the number of
IGMP messages on the network; larger values cause IGMP Queries to be sent
less often.

7.3.  Query Response Interval

The Max Response Time inserted into the periodic General Queries.
Default: 100 (10 seconds)

By varying the [Query Response Interval], an administrator may tune the
burstiness of IGMP messages on the network; larger values make the
traffic lest bursty, as host responses are spread out over a larger
interval.  The number of seconds represented by the [Query Response
Interval] must me less than the [Query Interval].

7.4.  Group Membership Interval

The Group Membership Interval is the amount of time that must pass
before a multicast router decides there are no more members of a group
on a network.  This value MUST be ((the Robustness Variable) times (the
Query Interval)) plus (one Query Response Interval).

7.5.  Other Querier Present Interval

The Other Querier Present Interval is the length of time that must pass
before a multicast router decides that there is no longer another
multicast router which should be the querier.  This value MUST be ((the
Robustness Variable) times (the Query Interval)) plus (one half of one
Query Response Interval).

7.6.  Startup Query Interval

The Startup Query Interval is the interval between General Queries sent
by a Querier on startup.  Default: 1/4 the Query Interval.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 25]


7.7.  Startup Query Count

The Startup Query Count is the number of Queries sent out on startup,
separated by the Startup Query Interval.  Default: the Robustness
Variable.

7.8.  Last Member Query Interval

The Last Member Query Interval is the Max Response Time inserted into
Group-Specific Queries sent in response to Leave Group messages, and is
also the amount of time between Group-Specific Query messages.  Default:
10 (1 second)

This value may be tuned to modify the "leave latency" of the network.  A
reduced value results in reduced time to detect the loss of the last
member of a group.

7.9.  Last Member Query Count

The Last Member Query Count is the number of Group-Specific Queries sent
before the router assumes there are no local members.  Default: the
Robustness Variable.

7.10.  Unsolicited Report Interval

The Unsolicited Report Interval is the time between repetitions of a
host's initial report of membership in a group.  Default: 10 seconds.

7.11.  Version 1 Router Present Timeout

The Version 1 Router Present Timeout is how long a host must wait after
hearing a Version 1 Query before it may send any IGMPv2 messages.
Value: 400 seconds.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 26]


9.  SECURITY CONSIDERATIONS

We consider the ramifications of a forged message of each type.

Query Message:

     A forged Query message from a machine with a lower IP address than
     the current Querier will cause Querier duties to be assigned to the
     forger.  If the forger then sends no more Query messages, other
     routers' Other Querier Present timer will time out and one will
     resume the role of Querier.  During this time, if the forger
     ignores Leave Messages, traffic might flow to groups with no
     members for up to [Group Membership Interval].

Report messages:

     A forged Report message may cause multicast routers to think there
     are members of a group on a network when there are not.  Forged
     Report messages from the local network are meaningless, since
     joining a group on a host is generally an unprivileged operation,
     so a local user may trivially gain the same result without forging
     any messages.  Forged Report messages from external sources are
     more troublesome; there are two defenses against externally forged
     Reports:
     - Ignore the Report if you cannot identify the source address of
       the packet as belonging to a network assigned to the interface on
       which the packet was received.  This solution means that Reports
       sent by mobile hosts without addresses on the local network will
       be ignored.
     - Ignore Report messages without Router Alert options [RFC2113], and
       require that routers not forward Report messages.  (The
       requirement is not a requirement of generalized filtering in the
       forwarding path, since the packets already have Router Alert
       options in them).  This solution breaks backwards compatibility
       with implementations of earlier versions of this specification
       which did not require Router Alert.

     A forged Version 1 Report Message may put a router into "version 1
     members present" state for a particular group, meaning that the
     router will ignore Leave messages.  This can cause traffic to flow
     to groups with no members for up to [Group Membership Interval].
     This can be solved by providing routers with a configuration switch
     to ignore Version 1 messages completely.  This breaks automatic
     compatibility with Version 1 hosts, so should only be used in
     situations where "fast leave" is critical.

Leave messages:

     A forged Leave message will cause the Querier to send out Group-
     Specific Queries for the group in question.  This causes extra
     processing on each router and on each member of the group, but can
     not cause loss of desired traffic.

Cain, Deering, Thyagarajan      Expires May 1997                   [Page 27]

10.  ACKNOWLEDGMENTS

Some of the text of this document was copied from [RFC1112] and [IGMPv2].


11.  REFERENCES

[RFC1112]  Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
           August 1989.

[IGMPv2]   Fenner, W., "Internet Group Management Protocol, Version 2",
           Internet-Draft, October 1996.

[RFC2113]  Katz, D., "IP Router Alert Option," RFC 2113, April 1996.


12.0  APPENDIX A.

This section elaborates on the need for the various types of Group Records
described in Section 4.2.9 by considering an alternate approach in sending
Group Membership Report messages.

In this approach, the Group Records included within each Group Membership
Report consist of the filter mode (either MODE_IS_INCLUDE or MODE_IS_EXCLUDE)
and the complete list of sources specified for that address.  In other words,
each Report conveys the "Full State" of the Group Record on an interface.
There are only two types of Group Records in this approach, and they follow
the filter mode of the interface multicast address state.

While this approach reduces the number of types of Group Records along with
the processing required to "compute" the membership report by a system, it
unfortunately requires additional processing by the router.  Since the Group
Records are only of two types, it is not possible to distinguish Reports that
were sent in response to Queries from those that were sent by a change of
interface state.  Membership reports which are sent in response to Membership
Queries are only used to refresh the existing state and typically do not
modify the multicast address state on the router.  Reports that are sent in
response to changes in interface state of a multicast address require that the
router take some action in response to the received report (see Section
5.2.5).  The inability to distinguish between the two types of reports would
force a router to treat all Membership Reports as potential changes in state
and could result in unnecessary queries from the router.


13.  AUTHORS' ADDRESSES

   Brad Cain
   Bay Networks, Inc.
   3 Federal Street
   Billerica, MA 01821
   phone: +1-978-916-1316
   email: bcain@baynetworks.com

   Steve Deering
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA 95134-1706
   phone: +1-408-527-8213
   email: deering@cisco.com

   Ajit Thyagarajan
   Torrent Networking Technologies
   8181 Professional Place
   Landover, MD 20785
   phone: +1-301-429-0246
   email: ajit@torrentnet.com


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/