doc: Add RFC documents

1 files changed, 2971 insertions, 0 deletions

diff --git a/doc/rfc/rfc3376.txt b/doc/rfc/rfc3376.txt
new file mode 100644
index 0000000..eab9bb7
--- /dev/null
+++ b/doc/rfc/rfc3376.txt
@@ -0,0 +1,2971 @@
+
+
+
+
+
+
+Network Working Group                                            B. Cain
+Request for Comments: 3376                               Cereva Networks
+Obsoletes: 2236                                               S. Deering
+Category: Standards Track                                    I. Kouvelas
+                                                           Cisco Systems
+                                                               B. Fenner
+                                                    AT&T Labs - Research
+                                                          A. Thyagarajan
+                                                                Ericsson
+                                                            October 2002
+
+
+             Internet Group Management Protocol, Version 3
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document specifies Version 3 of the Internet Group Management
+   Protocol, IGMPv3.  IGMP is the protocol used by IPv4 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 obsoletes RFC 2236.
+
+
+
+
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                     [Page 1]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+Table of Contents
+
+   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  The Service Interface for Requesting IP Multicast Reception .   3
+   3.  Multicast Reception State Maintained by Systems . . . . . . .   5
+   4.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .   7
+   5.  Description of the Protocol for Group Members . . . . . . . .  19
+   6.  Description of the Protocol for Multicast Routers . . . . . .  24
+   7.  Interoperation with Older Versions of IGMP. . . . . . . . . .  35
+   8.  List of Timers, Counters, and Their Default Values. . . . . .  40
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  43
+   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  47
+   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  47
+   12. Normative References. . . . . . . . . . . . . . . . . . . . .  47
+   13. Informative References. . . . . . . . . . . . . . . . . . . .  47
+       Appendix A. Design Rationale. . . . . . . . . . . . . . . . .  49
+       Appendix B. Summary of changes from IGMPv2. . . . . . . . . .  50
+       Authors' Addresses. . . . . . . . . . . . . . . . . . . . . .  52
+       Full Copyright Statement. . . . . . . . . . . . . . . . . . .  53
+
+1. Introduction
+
+   The Internet Group Management Protocol (IGMP) is used by IPv4 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
+   [RFC-2236], 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, as required to support
+   Source-Specific Multicast [SSM], 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.
+
+
+
+Cain, et. al.               Standards Track                     [Page 2]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   Multicast Listener Discovery (MLD) is used in a similar way by IPv6
+   systems.  MLD version 1 [MLD] implements the functionality of IGMP
+   version 2; MLD version 2 [MLDv2] implements the functionality of IGMP
+   version 3.
+
+   The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
+   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC-2119].  Due to the lack of italics, emphasis is indicated herein
+   by bracketing a word or phrase in "*" characters.
+
+2. The Service Interface for Requesting IP Multicast Reception
+
+   Within an IP system, there is (at least conceptually) a service
+   interface 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 service interface must
+   support the following operation:
+
+      IPMulticastListen ( socket, interface, multicast-address,
+                          filter-mode, source-list )
+
+   where:
+
+   o "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.
+
+   o "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.
+
+   o "multicast-address" is the IP multicast address, or group, 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.
+
+
+
+
+
+Cain, et. al.               Standards Track                     [Page 3]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   o "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.
+
+   o "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.  When an operation causes the source list
+     size limit to be exceeded, the service interface MUST return an
+     error.
+
+   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.  Each subsequent
+   request completely replaces any earlier request for the given socket,
+   interface and multicast address.
+
+   Previous versions of IGMP did not support source filters and had a
+   simpler service interface consisting of Join and Leave operations to
+   enable and disable reception of a given multicast address (from *all*
+   sources) on a given interface.  The equivalent operations in the new
+   service interface follow:
+
+   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.
+
+   An example of an API providing the capabilities outlined in this
+   service interface is in [FILTER-API].
+
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                     [Page 4]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+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 changed 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)
+
+     At most one record per multicast-address exists for a given
+     interface.  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:
+
+
+
+Cain, et. al.               Standards Track                     [Page 5]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+        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}.
+
+     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 will be delivered on
+     socket s1 but not on socket s2.  Note that IGMP Queries and Reports
+     are not subject to source filtering and must always be processed by
+     hosts and routers.
+
+     Filtering of packets based upon a socket's multicast reception
+     state is a new feature of this service interface.  The previous
+     service interface [RFC1112] described no filtering based upon
+     multicast join state; rather, a join on a socket simply caused the
+     host to join a group on the given interface, and packets destined
+     for that group could be delivered to all sockets whether they had
+     joined or not.
+
+     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} )
+
+
+
+
+
+Cain, et. al.               Standards Track                     [Page 6]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+     then the corresponding interface record on interface i is:
+
+                         ( m, EXCLUDE, {b, c} )
+
+     If a fourth socket is added, such as:
+
+        from socket s4:  ( i, m, EXCLUDE, {} )
+
+     then the interface record becomes:
+
+                         ( m, EXCLUDE, {} )
+
+   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} )
+
+     An implementation MUST NOT use an EXCLUDE interface record to
+     represent a group when all sockets for this group are in INCLUDE
+     state.  If system resource limits are reached when an interface
+     state source list is calculated, an error MUST be returned to the
+     application which requested the operation.
+
+   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-socket 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 IPv4 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, IP Precedence of Internetwork Control
+   (e.g., Type of Service 0xc0), and carries an IP Router Alert option
+   [RFC-2113] in its IP header.  IGMP message types are registered by
+   the IANA [IANA-REG] as described by [RFC-3228].
+
+
+
+
+
+Cain, et. al.               Standards Track                     [Page 7]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   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 7):
+
+           0x12          Version 1 Membership Report    [RFC-1112]
+
+           0x16          Version 2 Membership Report    [RFC-2236]
+
+           0x17          Version 2 Leave Group          [RFC-2236]
+
+   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.
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                     [Page 8]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+       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 Code |           Checksum            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Group Address                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Resv  |S| QRV |     QQIC      |     Number of Sources (N)     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Source Address [1]                      |
+      +-                                                             -+
+      |                       Source Address [2]                      |
+      +-                              .                              -+
+      .                               .                               .
+      .                               .                               .
+      +-                                                             -+
+      |                       Source Address [N]                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.1.1. Max Resp Code
+
+   The Max Resp Code field specifies the maximum time allowed before
+   sending a responding report.  The actual time allowed, called the Max
+   Resp Time, is represented in units of 1/10 second and is derived from
+   the Max Resp Code as follows:
+
+   If Max Resp Code < 128, Max Resp Time = Max Resp Code
+
+   If Max Resp Code >= 128, Max Resp Code represents a floating-point
+   value as follows:
+
+       0 1 2 3 4 5 6 7
+      +-+-+-+-+-+-+-+-+
+      |1| exp | mant  |
+      +-+-+-+-+-+-+-+-+
+
+   Max Resp Time = (mant | 0x10) << (exp + 3)
+
+   Small values of Max Resp Time allow 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).  Larger values, especially in the exponential range,
+   allow tuning of the burstiness of IGMP traffic on a network.
+
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                     [Page 9]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+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.
+   [RFC-1071]
+
+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.9, below).
+
+4.1.4. Resv (Reserved)
+
+   The Resv field is set to zero on transmission, and ignored on
+   reception.
+
+4.1.5. S Flag (Suppress Router-Side Processing)
+
+   When set to one, the S Flag indicates to any receiving multicast
+   routers that they are to suppress the normal timer updates they
+   perform upon hearing a Query.  It does not, however, suppress the
+   querier election or the normal "host-side" processing of a Query that
+   a router may be required to perform as a consequence of itself being
+   a group member.
+
+4.1.6. QRV (Querier's Robustness Variable)
+
+   If non-zero, the QRV field contains the [Robustness Variable] value
+   used by the querier, i.e., the sender of the Query.  If the querier's
+   [Robustness Variable] exceeds 7, the maximum value of the QRV field,
+   the QRV is set to zero.  Routers adopt the QRV value from the most
+   recently received Query as their own [Robustness Variable] value,
+   unless that most recently received QRV was zero, in which case the
+   receivers use the default [Robustness Variable] value specified in
+   section 8.1 or a statically configured value.
+
+4.1.7. QQIC (Querier's Query Interval Code)
+
+   The Querier's Query Interval Code field specifies the [Query
+   Interval] used by the querier.  The actual interval, called the
+   Querier's Query Interval (QQI), is represented in units of seconds
+   and is derived from the Querier's Query Interval Code as follows:
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 10]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   If QQIC < 128, QQI = QQIC
+
+   If QQIC >= 128, QQIC represents a floating-point value as follows:
+
+       0 1 2 3 4 5 6 7
+      +-+-+-+-+-+-+-+-+
+      |1| exp | mant  |
+      +-+-+-+-+-+-+-+-+
+
+   QQI = (mant | 0x10) << (exp + 3)
+
+   Multicast routers that are not the current querier adopt the QQI
+   value from the most recently received Query as their own [Query
+   Interval] value, unless that most recently received QQI was zero, in
+   which case the receiving routers use the default [Query Interval]
+   value specified in section 8.2.
+
+4.1.8. 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.9. 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.10. 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.
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 11]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+4.1.11. 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.
+
+   3. 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.12. 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-Specific and
+   Group-and-Source-Specific 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.
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 12]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+       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]                       .
+      .                                                               .
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 13]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   where each Group Record has the following internal format:
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Record Type  |  Aux Data Len |     Number of Sources (N)     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Multicast Address                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Source Address [1]                      |
+      +-                                                             -+
+      |                       Source Address [2]                      |
+      +-                                                             -+
+      .                               .                               .
+      .                               .                               .
+      .                               .                               .
+      +-                                                             -+
+      |                       Source Address [N]                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      .                                                               .
+      .                         Auxiliary Data                        .
+      .                                                               .
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+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.
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 14]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+4.2.5. Record Type
+
+   See section 4.2.12, below.
+
+4.2.6. Aux Data Len
+
+   The Aux Data Len field contains the length of the Auxiliary Data
+   field in this Group Record, in units of 32-bit words.  It may contain
+   zero, to indicate the absence of any auxiliary data.
+
+4.2.7. Number of Sources (N)
+
+   The Number of Sources (N) field specifies how many source addresses
+   are present in this Group Record.
+
+4.2.8. Multicast Address
+
+   The Multicast Address field contains the IP multicast address to
+   which this Group Record pertains.
+
+4.2.9. 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.10. Auxiliary Data
+
+   The Auxiliary Data field, if present, contains additional information
+   pertaining to this Group Record.  The protocol specified in this
+   document, IGMPv3, does not define any auxiliary data.  Therefore,
+   implementations of IGMPv3 MUST NOT include any auxiliary data (i.e.,
+   MUST set the Aux Data Len field to zero) in any transmitted Group
+   Record, and MUST ignore any auxiliary data present in any received
+   Group Record.  The semantics and internal encoding of the Auxiliary
+   Data field are to be defined by any future version or extension of
+   IGMP that uses this field.
+
+4.2.11. 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, et. al.               Standards Track                    [Page 15]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+4.2.12. Group Record Types
+
+   There are a number of different types of Group Records that may be
+   included in a Report message:
+
+   o 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.
+
+   o 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.
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 16]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   o 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:
+
+          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.13. IP Source Addresses for Reports
+
+   An IGMP report is sent with a valid IP source address for the
+   destination subnet.  The 0.0.0.0 source address may be used by a
+   system that has not yet acquired an IP address.  Note that the
+   0.0.0.0 source address may simultaneously be used by multiple systems
+   on a LAN.  Routers MUST accept a report with a source address of
+   0.0.0.0.
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 17]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+4.2.14. IP Destination Addresses for Reports
+
+   Version 3 Reports are sent with an IP destination address of
+   224.0.0.22, to which all IGMPv3-capable multicast routers listen.  A
+   system that is operating in version 1 or version 2 compatibility
+   modes sends version 1 or 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.
+
+4.2.15. 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:
+
+   o a capital letter (e.g., "A") to represent the set of source
+     addresses, or
+
+   o a set expression (e.g., "A+B"), where "A+B" means the union of sets
+     A and B, "A*B" means the intersection of sets A and B, and "A-B"
+     means the removal of all elements of set B from set A.
+
+4.2.16. Membership Report Size
+
+   If the set of Group Records required in a Report does not fit within
+   the size limit of a single Report message (as determined by the MTU
+   of the network on which it will be sent), the Group Records are sent
+   in as many Report messages as needed to report the entire set.
+
+   If a single Group Record contains so many source addresses that it
+   does not fit within the size limit of a single Report message, if its
+   Type is not MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, it is split
+   into multiple Group Records, each containing a different subset of
+   the source addresses and each sent in a separate Report message.  If
+   its Type is MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, a single Group
+   Record is sent, containing as many source addresses as can fit, and
+
+
+
+Cain, et. al.               Standards Track                    [Page 18]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   the remaining source addresses are not reported; though the choice of
+   which sources to report is arbitrary, it is preferable to report the
+   same set of sources in each subsequent report, rather than reporting
+   different sources each time.
+
+5. Description of the Protocol for Group Members
+
+   IGMP is an asymmetric protocol, specifying separate behaviors for
+   group members -- that is, hosts or routers that wish to receive
+   multicast packets -- and multicast routers.  This section describes
+   the part of IGMPv3 that applies to all group members.  (Note that a
+   multicast router that is also a group member performs both parts of
+   IGMPv3, receiving and responding to its own IGMP message
+   transmissions as well as those of its neighbors.  The multicast
+   router part of IGMPv3 is described in section 6.)
+
+   A system performs the protocol described in this section over all
+   interfaces on which multicast reception is supported, even if more
+   than one of those interfaces is connected to the same network.
+
+   For interoperability with multicast routers running older versions of
+   IGMP, systems maintain a MulticastRouterVersion variable for each
+   interface on which multicast reception is supported.  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 7.
+
+   The all-systems multicast address, 224.0.0.1, is handled as a special
+   case.  On all systems -- that is all hosts and routers, including
+   multicast routers -- 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.
+
+   There are two types of events that trigger IGMPv3 protocol actions on
+   an interface:
+
+   o a change of the interface reception state, caused by a local
+     invocation of IPMulticastListen.
+
+   o reception of a Query.
+
+   (Received IGMP messages of types other than Query are silently
+   ignored, except as required for interoperation with earlier versions
+   of IGMP.)
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 19]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   The following subsections describe the actions to be taken for each
+   of these two cases.  In those descriptions, timer and counter names
+   appear in square brackets.  The default values for those timers and
+   counters are specified in section 8.
+
+5.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 to immediately transmit
+   a State-Change Report from that interface.  The type and contents of
+   the Group Record(s) in that Report are determined by comparing the
+   filter mode and source list for the affected 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-existent" state is considered
+   to have a filter mode of INCLUDE and an empty source list.
+
+     Old State         New State         State-Change Record 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)
+
+   If the computed source list for either an ALLOW or a BLOCK State-
+   Change Record is empty, that record is omitted from the Report
+   message.
+
+   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 new State-Change Report.
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 20]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   The contents of the new transmitted report are calculated as follows.
+   As was done with the first report, the interface state for the
+   affected group before and after the latest change is compared.  The
+   report records expressing the difference are built according to the
+   table above.  However these records are not transmitted in a message
+   but instead merged with the contents of the pending report, to create
+   the new State-Change report.  The rules for merging the difference
+   report resulting from the state change and the pending report are
+   described below.
+
+   The transmission of the merged 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 State-Change Reports.
+
+   Each time a source is included in the difference report calculated
+   above, retransmission state for that source needs to be maintained
+   until [Robustness Variable] State-Change reports have been sent by
+   the host.  This is done in order to ensure that a series of
+   successive state changes do not break the protocol robustness.
+
+   If the interface reception-state change that triggers the new report
+   is a filter-mode change, then the next [Robustness Variable] State-
+   Change Reports will include a Filter-Mode-Change record.  This
+   applies even if any number of source-list changes occur in that
+   period.  The host has to maintain retransmission state for the group
+   until the [Robustness Variable] State-Change reports have been sent.
+   When [Robustness Variable] State-Change reports with Filter-Mode-
+   Change records have been transmitted after the last filter-mode
+   change, and if source-list changes to the interface reception have
+   scheduled additional reports, then the next State-Change report will
+   include Source-List-Change records.
+
+   Each time a State-Change Report is transmitted, the contents are
+   determined as follows.  If the report should contain a Filter-Mode-
+   Change record, then if the current filter-mode of the interface is
+   INCLUDE, a TO_IN record is included in the report, otherwise a TO_EX
+   record is included.  If instead the report should contain Source-
+   List-Change records, an ALLOW and a BLOCK record are included.  The
+   contents of these records are built according to the table below.
+
+      Record   Sources included
+      ------   ----------------
+      TO_IN    All in the current interface state that must be forwarded
+      TO_EX    All in the current interface state that must be blocked
+      ALLOW    All with retransmission state that must be forwarded
+      BLOCK    All with retransmission state that must be blocked
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 21]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   If the computed source list for either an ALLOW or a BLOCK record is
+   empty, that record is omitted from the State-Change report.
+
+   Note: When the first State-Change report is sent, the non-existent
+   pending report to merge with, can be treated as a source-change
+   report with empty ALLOW and BLOCK records (no sources have
+   retransmission state).
+
+5.2. Action on Reception of a Query
+
+   When a system receives a Query, it does not respond immediately.
+   Instead, it delays its response by a random amount of time, bounded
+   by the Max Resp Time value derived from the Max Resp Code in the
+   received Query message.  A system may receive a variety of Queries on
+   different interfaces and of different kinds (e.g., General Queries,
+   Group-Specific Queries, and Group-and-Source-Specific Queries), each
+   of which may require its own delayed response.
+
+   Before scheduling a response to a Query, the system must first
+   consider previously scheduled pending responses and in many cases
+   schedule a combined response.  Therefore, the system must be able to
+   maintain the following state:
+
+   o A timer per interface for scheduling responses to General Queries.
+
+   o A per-group and interface timer for scheduling responses to Group-
+     Specific and Group-and-Source-Specific Queries.
+
+   o A per-group and interface list of sources to be reported in the
+     response to a Group-and-Source-Specific Query.
+
+   When a new Query with the Router-Alert option arrives on an
+   interface, provided the system has state to report, a delay for a
+   response is randomly selected in the range (0, [Max Resp Time]) where
+   Max Resp Time is derived from Max Resp Code in the received Query
+   message.  The following rules are then used to determine if a Report
+   needs to be scheduled and the type of Report to schedule.  The rules
+   are considered in order and only the first matching rule is applied.
+
+   1. If there is a pending response to a previous General Query
+      scheduled sooner than the selected delay, no additional response
+      needs to be scheduled.
+
+   2. If the received Query is a General Query, the interface timer is
+      used to schedule a response to the General Query after the
+      selected delay.  Any previously pending response to a General
+      Query is canceled.
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 22]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   3. If the received Query is a Group-Specific Query or a Group-and-
+      Source-Specific Query and there is no pending response to a
+      previous Query for this group, then the group timer is used to
+      schedule a report.  If the received Query is a Group-and-Source-
+      Specific Query, the list of queried sources is recorded to be used
+      when generating a response.
+
+   4. If there already is a pending response to a previous Query
+      scheduled for this group, and either the new Query is a Group-
+      Specific Query or the recorded source-list associated with the
+      group is empty, then the group source-list is cleared and a single
+      response is scheduled using the group timer.  The new response is
+      scheduled to be sent at the earliest of the remaining time for the
+      pending report and the selected delay.
+
+   5. If the received Query is a Group-and-Source-Specific Query and
+      there is a pending response for this group with a non-empty
+      source-list, then the group source list is augmented to contain
+      the list of sources in the new Query and a single response is
+      scheduled using the group timer.  The new response is scheduled to
+      be sent at the earliest of the remaining time for the pending
+      report and the selected delay.
+
+   When the timer in a pending response record expires, the system
+   transmits, on the associated interface, one or more Report messages
+   carrying one or more Current-State Records (see section 4.2.12), as
+   follows:
+
+   1. If the expired timer is the interface timer (i.e., it is a pending
+      response to a General Query), then one Current-State Record is
+      sent for each multicast address for which the specified interface
+      has reception state, as described in section 3.2.  The Current-
+      State Record carries the multicast address and its associated
+      filter mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and source list.
+      Multiple Current-State Records are packed into individual Report
+      messages, to the extent possible.
+
+      This naive algorithm may result in bursts of packets when a system
+      is a member of a large number of groups.  Instead of using a
+      single interface timer, implementations are recommended to spread
+      transmission of such Report messages over the interval (0, [Max
+      Resp Time]).  Note that any such implementation MUST avoid the
+      "ack-implosion" problem, i.e., MUST NOT send a Report immediately
+      on reception of a General Query.
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 23]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   2. If the expired timer is a group timer and the list of recorded
+      sources for the that group is empty (i.e., it is a pending
+      response to a Group-Specific Query), then if and only if the
+      interface has reception state for that group address, a single
+      Current-State Record is sent for that address.  The Current-State
+      Record carries the multicast address and its associated filter
+      mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and source list.
+
+   3. If the expired timer is a group timer and the list of recorded
+      sources for that group is non-empty (i.e., it is a pending
+      response to a Group-and-Source-Specific Query), then if and only
+      if the interface has reception state for that group address, the
+      contents of the responding Current-State Record is determined from
+      the interface state and the pending response record, as specified
+      in the following table:
+
+                         set of sources in the
+      interface state   pending response record   Current-State Record
+      ---------------   -----------------------   --------------------
+
+       INCLUDE (A)                B                   IS_IN (A*B)
+
+       EXCLUDE (A)                B                   IS_IN (B-A)
+
+   If the resulting Current-State Record has an empty set of source
+   addresses, then no response is sent.
+
+   Finally, after any required Report messages have been generated, the
+   source lists associated with any reported groups are cleared.
+
+6. Description of the Protocol for Multicast Routers
+
+   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.  IGMP version
+   3 adds the capability for a multicast router to also learn  which
+   *sources* are of interest to neighboring systems, for packets sent to
+   any particular multicast address.  The information gathered by IGMP
+   is 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.
+
+   This section describes the part of IGMPv3 that is performed by
+   multicast routers.  Multicast routers may also themselves become
+   members of multicast groups, and therefore also perform the group
+   member part of IGMPv3, described in section 5.
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 24]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   A multicast router performs the protocol described in this section
+   over each of its directly-attached networks.  If a multicast router
+   has more than one interface to the same network, it only needs to
+   operate this protocol over one of those interfaces.  On each
+   interface over which this protocol is being run, the router MUST
+   enable reception of multicast address 224.0.0.22, from all sources
+   (and MUST perform the group member part of IGMPv3 for that address on
+   that interface).
+
+   Multicast routers need 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; a multicast router is not required
+   to keep track of the interests of each individual neighboring system.
+   (However, see Appendix A.2 point 1 for discussion.)
+
+   IGMPv3 is backward compatible with previous versions of the IGMP
+   protocol.  In order to remain backward compatible with older IGMP
+   systems, IGMPv3 multicast routers MUST also implement versions 1 and
+   2 of the protocol (see section 7).
+
+6.1. Conditions for IGMP Queries
+
+   Multicast routers send General Queries periodically to request group
+   membership information from an attached network.  These queries are
+   used to build and refresh the group membership state of systems on
+   attached networks.  Systems respond to these queries by reporting
+   their group membership state (and their desired set of sources) with
+   Current-State Group Records in IGMPv3 Membership Reports.
+
+   As a member of a multicast group, a system may express interest in
+   receiving or not receiving traffic from particular sources.  As the
+   desired reception state of a system changes, it reports these changes
+   using Filter-Mode-Change Records or Source-List-Change Records.
+   These records indicate an explicit state change in a group at a
+   system in either the group record's source list or its filter-mode.
+   When a group membership is terminated at a system or traffic from a
+   particular source is no longer desired, a multicast router must query
+   for other members of the group or listeners of the source before
+   deleting the group (or source) and pruning its traffic.
+
+   To enable all systems on a network to respond to changes in group
+   membership, multicast routers send specific queries.  A Group-
+   Specific Query is sent to verify there are no systems that desire
+   reception of the specified group or to "rebuild" the desired
+   reception state for a particular group.  Group-Specific Queries are
+   sent when a router receives a State-Change record indicating a system
+   is leaving a group.
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 25]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   A Group-and-Source Specific Query is used to verify there are no
+   systems on a network which desire to receive traffic from a set of
+   sources.  Group-and-Source Specific Queries list sources for a
+   particular group which have been requested to no longer be forwarded.
+   This query is sent by a multicast router to learn if any systems
+   desire reception of packets to the specified group address from the
+   specified source addresses.  Group-and-Source Specific Queries are
+   only sent in response to State-Change Records and never in response
+   to Current-State Records.  Section 4.1.11 describes each query in
+   more detail.
+
+6.2. IGMP State Maintained by Multicast Routers
+
+   Multicast routers implementing IGMPv3 keep state per group per
+   attached network.  This group state consists of a filter-mode, a list
+   of sources, and various timers.  For each attached network running
+   IGMP, a multicast router records the desired reception state for that
+   network.  That state conceptually consists of a set of records of the
+   form:
+
+      (multicast address, group timer, filter-mode, (source records))
+
+   Each source record is of the form:
+
+      (source address, source timer)
+
+   If all sources within a given group are desired, an empty source
+   record list is kept with filter-mode set to EXCLUDE.  This means
+   hosts on this network want all sources for this group to be
+   forwarded.  This is the IGMPv3 equivalent to a IGMPv1 or IGMPv2 group
+   join.
+
+6.2.1. Definition of Router Filter-Mode
+
+   To reduce internal state, IGMPv3 routers keep a filter-mode per group
+   per attached network.  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.  This filter-mode may change in
+   response to the reception of particular types of group records or
+   when certain timer conditions occur.  In the following sections, we
+   use the term "router filter-mode" to refer to the filter-mode of a
+   particular group within a router.  Section 6.4 describes the changes
+   of a router filter-mode per group record received.
+
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 26]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   Conceptually, when a group record is received, the router filter-mode
+   for that group is updated to cover all the requested sources using
+   the least amount of state.  As a rule, once a group record with a
+   filter-mode of EXCLUDE is received, the router filter-mode for that
+   group will be EXCLUDE.
+
+   When a router filter-mode for a group is EXCLUDE, the source record
+   list contains two types of sources.  The first type is the set which
+   represents conflicts in the desired reception state; this set must be
+   forwarded by some router on the network.  The second type is the set
+   of sources which hosts have requested to not be forwarded.  Appendix
+   A describes the reasons for keeping this second set when in EXCLUDE
+   mode.
+
+   When a router filter-mode for a group is INCLUDE, the source record
+   list is the list of sources desired for the group.  This is the total
+   desired set of sources for that group.  Each source in the source
+   record list must be forwarded by some router on the network.
+
+   Because a reported group record with a filter-mode of EXCLUDE will
+   cause a router to transition its filter-mode for that group to
+   EXCLUDE, a mechanism for transitioning a router's filter-mode back to
+   INCLUDE must exist.  If all systems with a group record in EXCLUDE
+   filter-mode cease reporting, it is desirable for the router filter-
+   mode for that group to transition back to INCLUDE mode.  This
+   transition occurs when the group timer expires and is explained in
+   detail in section 6.5.
+
+6.2.2. Definition of Group Timers
+
+   The group timer is only used when a group is in EXCLUDE mode and it
+   represents the time for the *filter-mode* of the group to expire and
+   switch to INCLUDE mode.  We define a group timer as a decrementing
+   timer with a lower bound of zero kept per group per attached network.
+   Group timers are updated according to the types of group records
+   received.
+
+   A group timer expiring when a router filter-mode for the group is
+   EXCLUDE means there are no listeners on the attached network in
+   EXCLUDE mode.  At this point, a router will transition to INCLUDE
+   filter-mode.  Section 6.5 describes the actions taken when a group
+   timer expires while in EXCLUDE mode.
+
+   The following table summarizes the role of the group timer.  Section
+   6.4 describes the details of setting the group timer per type of
+   group record received.
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 27]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+      Group
+      Filter-Mode      Group Timer Value      Actions/Comments
+      -----------      -----------------      ----------------
+
+      INCLUDE          Timer >= 0             All members in INCLUDE
+                                              mode.
+
+      EXCLUDE          Timer > 0              At least one member in
+                                              EXCLUDE mode.
+
+      EXCLUDE          Timer == 0             No more listeners to
+                                              group.  If all source
+                                              timers have expired then
+                                              delete Group Record.
+                                              If there are still
+                                              source record timers
+                                              running, switch to
+                                              INCLUDE filter-mode
+                                              using those source records
+                                              with running timers as the
+                                              INCLUDE source record
+                                              state.
+
+6.2.3. Definition of Source Timers
+
+   A source timer is kept per source record and is a decrementing timer
+   with a lower bound of zero.  Source timers are updated according to
+   the type and filter-mode of the group record received.  Source timers
+   are always updated (for a particular group) whenever the source is
+   present in a received record for that group.  Section 6.4 describes
+   the setting of source timers per type of group records received.
+
+   A source record with a running timer with a router filter-mode for
+   the group of INCLUDE means that there is currently one or more
+   systems (in INCLUDE filter-mode) which desire to receive that source.
+   If a source timer expires with a router filter-mode for the group of
+   INCLUDE, the router concludes that traffic from this particular
+   source is no longer desired on the attached network, and deletes the
+   associated source record.
+
+   Source timers are treated differently when a router filter-mode for a
+   group is EXCLUDE.  If a source record has a running timer with a
+   router filter-mode for the group of EXCLUDE, it means that at least
+   one system desires the source.  It should therefore be forwarded by a
+   router on the network.  Appendix A describes the reasons for keeping
+   state for sources that have been requested to be forwarded while in
+   EXCLUDE state.
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 28]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   If a source timer expires with a router filter-mode for the group of
+   EXCLUDE, the router informs the routing protocol that there is no
+   longer a receiver on the network interested in traffic from this
+   source.
+
+   When a router filter-mode for a group is EXCLUDE, source records are
+   only deleted when the group timer expires.  Section 6.3 describes the
+   actions that should be taken dependent upon the value of a source
+   timer.
+
+6.3. IGMPv3 Source-Specific Forwarding Rules
+
+   When a multicast router receives a datagram from a source destined to
+   a particular group, a decision has to be made whether to forward the
+   datagram onto an attached network or not.  The multicast routing
+   protocol in use is in charge of this decision, and should use the
+   IGMPv3 information to ensure that all sources/groups desired on a
+   subnetwork are forwarded to that subnetwork.  IGMPv3 information does
+   not override multicast routing information; for example, if the
+   IGMPv3 filter-mode group for G is EXCLUDE, a router may still forward
+   packets for excluded sources to a transit subnet.
+
+   To summarize, the following table describes the forwarding
+   suggestions made by IGMP to the routing protocol for traffic
+   originating from a source destined to a group.  It also summarizes
+   the actions taken upon the expiration of a source timer based on the
+   router filter-mode of the group.
+
+      Group
+      Filter-Mode    Source Timer Value    Action
+      -----------    ------------------    ------
+
+      INCLUDE        TIMER > 0             Suggest to forward traffic
+                                           from source
+
+      INCLUDE        TIMER == 0            Suggest to stop forwarding
+                                           traffic from source and
+                                           remove source record.  If
+                                           there are no more source
+                                           records for the group, delete
+                                           group record.
+
+      INCLUDE        No Source Elements    Suggest to not forward source
+
+      EXCLUDE        TIMER > 0             Suggest to forward traffic
+                                           from source
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 29]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+      EXCLUDE        TIMER == 0            Suggest to not forward
+                                           traffic from source
+                                           (DO NOT remove record)
+
+      EXCLUDE        No Source Elements    Suggest to forward traffic
+                                           from source
+
+6.4. Action on Reception of Reports
+
+6.4.1. Reception of Current-State Records
+
+   When receiving Current-State Records, a router updates both its group
+   and source timers.  In some circumstances, the reception of a type of
+   group record will cause the router filter-mode for that group to
+   change.  The table below describes the actions, with respect to state
+   and timers that occur to a router's state upon reception of Current-
+   State Records.
+
+   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 source records whose source timers > 0 (Sources that at
+       least one host has requested to be forwarded)
+   B = set of source records whose source timers = 0 (Sources that IGMP
+       will suggest to the routing protocol not to forward)
+
+   Note that there will only be two sets when a router's filter-mode for
+   a group is EXCLUDE.  When a router's filter-mode for a group is
+   INCLUDE, a single set is used to describe the set of sources
+   requested to be forwarded (e.g., simply (A)).
+
+   In the following tables, abbreviations are used for several variables
+   (all of which are described in detail in section 8).  The variable
+   GMI is an abbreviation for the Group Membership Interval, which is
+   the time in which group memberships will time out.  The variable LMQT
+   is an abbreviation for the Last Member Query Time, which is the total
+   time spent after Last Member Query Count retransmissions.  LMQT
+   represents the  "leave latency", or the difference between the
+   transmission of a membership change and the change in the information
+   given to the routing protocol.
+
+   Within the "Actions" section of the router state tables, we use the
+   notation 'A=J', which means that the set A of source records should
+   have their source timers set to value J.  'Delete A' means that the
+   set A of source records should be deleted.  'Group Timer=J' means
+   that the Group Timer for the group should be set to value J.
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 30]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   Router State   Report Rec'd  New Router State         Actions
+   ------------   ------------  ----------------         -------
+
+   INCLUDE (A)    IS_IN (B)     INCLUDE (A+B)            (B)=GMI
+
+   INCLUDE (A)    IS_EX (B)     EXCLUDE (A*B,B-A)        (B-A)=0
+                                                         Delete (A-B)
+                                                         Group Timer=GMI
+
+   EXCLUDE (X,Y)  IS_IN (A)     EXCLUDE (X+A,Y-A)        (A)=GMI
+
+   EXCLUDE (X,Y)  IS_EX (A)     EXCLUDE (A-Y,Y*A)        (A-X-Y)=GMI
+                                                         Delete (X-A)
+                                                         Delete (Y-A)
+                                                         Group Timer=GMI
+
+6.4.2. Reception of Filter-Mode-Change and Source-List-Change Records
+
+   When a change in the global state of a group occurs in a system, the
+   system sends either a Source-List-Change Record or a Filter-Mode-
+   Change Record for that group.  As with Current-State Records, routers
+   must act upon these records and possibly change their own state to
+   reflect the new desired membership state of the network.
+
+   Routers must query sources that are requested to be no longer
+   forwarded to a group.  When a router queries or receives a query for
+   a specific set of sources, it lowers its source timers for those
+   sources to a small interval of Last Member Query Time seconds.  If
+   group records are received in response to the queries which express
+   interest in receiving traffic from the queried sources, the
+   corresponding timers are updated.
+
+   Similarly, when a router queries a specific group, it lowers its
+   group timer for that group to a small interval of Last Member Query
+   Time seconds.  If any group records expressing EXCLUDE mode interest
+   in the group are received within the interval, the group timer for
+   the group is updated and the suggestion to the routing protocol to
+   forward the group stands without any interruption.
+
+   During a query period (i.e., Last Member Query Time seconds), the
+   IGMP component in the router continues to suggest to the routing
+   protocol that it forwards traffic from the groups or sources that it
+   is querying.  It is not until after Last Member Query Time seconds
+   without receiving a record expressing interest in the queried group
+   or sources that the router may prune the group or sources from the
+   network.
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 31]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   The following table describes the changes in group state and the
+   action(s) taken when receiving either Filter-Mode-Change or Source-
+   List-Change Records.  This table also describes the queries which are
+   sent by the querier when a particular report is received.
+
+   We use the following notation for describing the queries which are
+   sent.  We use the notation 'Q(G)' to describe a Group-Specific Query
+   to G.  We use the notation 'Q(G,A)' to describe a Group-and-Source
+   Specific Query to G with source-list A.  If source-list A is null as
+   a result of the action (e.g., A*B) then no query is sent as a result
+   of the operation.
+
+   In order to maintain protocol robustness, queries sent by actions in
+   the table below need to be transmitted [Last Member Query Count]
+   times, once every [Last Member Query Interval].
+
+   If while scheduling new queries, there are already pending queries to
+   be retransmitted for the same group, the new and pending queries have
+   to be merged.  In addition, received host reports for a group with
+   pending queries may affect the contents of those queries.  Section
+   6.6.3 describes the process of building and maintaining the state of
+   pending queries.
+
+Router State   Report Rec'd New Router State        Actions
+------------   ------------ ----------------        -------
+
+INCLUDE (A)    ALLOW (B)    INCLUDE (A+B)           (B)=GMI
+
+INCLUDE (A)    BLOCK (B)    INCLUDE (A)             Send Q(G,A*B)
+
+INCLUDE (A)    TO_EX (B)    EXCLUDE (A*B,B-A)       (B-A)=0
+                                                    Delete (A-B)
+                                                    Send Q(G,A*B)
+                                                    Group Timer=GMI
+
+INCLUDE (A)    TO_IN (B)    INCLUDE (A+B)           (B)=GMI
+                                                    Send Q(G,A-B)
+
+EXCLUDE (X,Y)  ALLOW (A)    EXCLUDE (X+A,Y-A)       (A)=GMI
+
+EXCLUDE (X,Y)  BLOCK (A)    EXCLUDE (X+(A-Y),Y)     (A-X-Y)=Group Timer
+                                                    Send Q(G,A-Y)
+
+EXCLUDE (X,Y)  TO_EX (A)    EXCLUDE (A-Y,Y*A)       (A-X-Y)=Group Timer
+                                                    Delete (X-A)
+                                                    Delete (Y-A)
+                                                    Send Q(G,A-Y)
+                                                    Group Timer=GMI
+
+
+
+Cain, et. al.               Standards Track                    [Page 32]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+EXCLUDE (X,Y)  TO_IN (A)    EXCLUDE (X+A,Y-A)       (A)=GMI
+                                                    Send Q(G,X-A)
+                                                    Send Q(G)
+
+6.5. Switching Router Filter-Modes
+
+   The group timer is used as a mechanism for transitioning the router
+   filter-mode from EXCLUDE to INCLUDE.
+
+   When a group timer expires with a router filter-mode of EXCLUDE, a
+   router assumes that there are no systems with a *filter-mode* of
+   EXCLUDE present on the attached network.  When a router's filter-mode
+   for a group is EXCLUDE and the group timer expires, the router
+   filter-mode for the group transitions to INCLUDE.
+
+   A router uses source records with running source timers as its state
+   for the switch to a filter-mode of INCLUDE.  If there are any source
+   records with source timers greater than zero (i.e., requested to be
+   forwarded), a router switches to filter-mode of INCLUDE using those
+   source records.  Source records whose timers are zero (from the
+   previous EXCLUDE mode) are deleted.
+
+   For example, if a router's state for a group is EXCLUDE(X,Y) and the
+   group timer expires for that group, the router switches to filter-
+   mode of INCLUDE with state INCLUDE(X).
+
+6.6. Action on Reception of Queries
+
+6.6.1. Timer Updates
+
+   When a router sends or receives a query with a clear Suppress
+   Router-Side Processing flag, it must update its timers to reflect the
+   correct timeout values for the group or sources being queried.  The
+   following table describes the timer actions when sending or receiving
+   a Group-Specific or Group-and-Source Specific Query with the Suppress
+   Router-Side Processing flag not set.
+
+      Query      Action
+      -----      ------
+      Q(G,A)     Source Timer for sources in A are lowered to LMQT
+      Q(G)       Group Timer is lowered to LMQT
+
+   When a router sends or receives a query with the Suppress Router-Side
+   Processing flag set, it will not update its timers.
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 33]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+6.6.2. Querier Election
+
+   IGMPv3 elects a single querier per subnet using the same querier
+   election mechanism as IGMPv2, namely by IP address.  When a router
+   receives a query with a lower IP address, it sets the Other-Querier-
+   Present timer to Other Querier Present Interval and ceases to send
+   queries on the network if it was the previously elected querier.
+   After its Other-Querier Present timer expires, it should begin
+   sending General Queries.
+
+   If a router receives an older version query, it MUST use the oldest
+   version of IGMP on the network.  For a detailed description of
+   compatibility issues between IGMP versions see section 7.
+
+6.6.3. Building and Sending Specific Queries
+
+6.6.3.1. Building and Sending Group Specific Queries
+
+   When a table action "Send Q(G)" is encountered, then the group timer
+   must be lowered to LMQT.  The router must then immediately send a
+   group specific query as well as schedule [Last Member Query Count -
+   1] query retransmissions to be sent every [Last Member Query
+   Interval] over [Last Member Query Time].
+
+   When transmitting a group specific query, if the group timer is
+   larger than LMQT, the "Suppress Router-Side Processing" bit is set in
+   the query message.
+
+6.6.3.2. Building and Sending Group and Source Specific Queries
+
+   When a table action "Send Q(G,X)" is encountered by a querier in the
+   table in section 6.4.2, the following actions must be performed for
+   each of the sources in X of group G, with source timer larger than
+   LMQT:
+
+   o Set number of retransmissions for each source to [Last Member Query
+     Count].
+
+   o Lower source timer to LMQT.
+
+   The router must then immediately send a group and source specific
+   query as well as schedule [Last Member Query Count - 1] query
+   retransmissions to be sent every [Last Member Query Interval] over
+   [Last Member Query Time].  The contents of these queries are
+   calculated as follows.
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 34]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   When building a group and source specific query for a group G, two
+   separate query messages are sent for the group.  The first one has
+   the "Suppress Router-Side Processing" bit set and contains all the
+   sources with retransmission state and timers greater than LMQT.  The
+   second has the "Suppress Router-Side Processing" bit clear and
+   contains all the sources with retransmission state and timers lower
+   or equal to LMQT.  If either of the two calculated messages does not
+   contain any sources, then its transmission is suppressed.
+
+   Note: If a group specific query is scheduled to be transmitted at the
+   same time as a group and source specific query for the same group,
+   then transmission of the group and source specific message with the
+   "Suppress Router-Side Processing" bit set may be suppressed.
+
+7. 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.
+
+7.1. Query Version Distinctions
+
+   The IGMP version of a Membership Query message is determined as
+   follows:
+
+      IGMPv1 Query: length = 8 octets AND Max Resp Code field is zero
+
+      IGMPv2 Query: length = 8 octets AND Max Resp Code field is
+                    non-zero
+
+      IGMPv3 Query: length >= 12 octets
+
+   Query messages that do not match any of the above conditions (e.g., a
+   Query of length 10 octets) MUST be silently ignored.
+
+7.2. Group Member Behavior
+
+7.2.1. In the Presence of Older Version Queriers
+
+   In order to be compatible with older version routers, IGMPv3 hosts
+   MUST operate in version 1 and version 2 compatibility modes.  IGMPv3
+   hosts MUST keep state per local interface regarding the compatibility
+   mode of each attached network.  A host's compatibility mode is
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 35]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   determined from the Host Compatibility Mode variable which can be in
+   one of three states:  IGMPv1, IGMPv2 or IGMPv3.  This variable is
+   kept per interface and is dependent on the version of General Queries
+   heard on that interface as well as the Older Version Querier Present
+   timers for the interface.
+
+   In order to switch gracefully between versions of IGMP, hosts keep
+   both an IGMPv1 Querier Present timer and an IGMPv2 Querier Present
+   timer per interface.  IGMPv1 Querier Present is set to Older Version
+   Querier Present Timeout seconds whenever an IGMPv1 Membership Query
+   is received.  IGMPv2 Querier Present is set to Older Version Querier
+   Present Timeout seconds whenever an IGMPv2 General Query is received.
+
+   The Host Compatibility Mode of an interface changes whenever an older
+   version query (than the current compatibility mode) is heard or when
+   certain timer conditions occur.  When the IGMPv1 Querier Present
+   timer expires, a host switches to Host Compatibility mode of IGMPv2
+   if it has a running IGMPv2 Querier Present timer.  If it does not
+   have a running IGMPv2 Querier Present timer then it switches to Host
+   Compatibility of IGMPv3.  When the IGMPv2 Querier Present timer
+   expires, a host switches to Host Compatibility mode of IGMPv3.
+
+   The Host Compatibility Mode variable is based on whether an older
+   version General query was heard in the last Older Version Querier
+   Present Timeout seconds.  The Host Compatibility Mode is set
+   depending on the following:
+
+   Host Compatibility Mode       Timer State
+   -----------------------       -----------
+
+         IGMPv3 (default)        IGMPv2 Querier Present not running
+                                 and IGMPv1 Querier Present not running
+
+         IGMPv2                  IGMPv2 Querier Present running
+                                 and IGMPv1 Querier Present not running
+
+         IGMPv1                  IGMPv1 Querier Present running
+
+   If a host receives a query which causes its Querier Present timers to
+   be updated and correspondingly its compatibility mode, it should
+   switch compatibility modes immediately.
+
+   When Host Compatibility Mode is IGMPv3, a host acts using the IGMPv3
+   protocol on that interface.  When Host Compatibility Mode is IGMPv2,
+   a host acts in IGMPv2 compatibility mode, using only the IGMPv2
+   protocol, on that interface.  When Host Compatibility Mode is IGMPv1,
+   a host acts in IGMPv1 compatibility mode, using only the IGMPv1
+   protocol on that interface.
+
+
+
+Cain, et. al.               Standards Track                    [Page 36]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   An IGMPv1 router will send General Queries with the Max Resp Code set
+   to 0.  This MUST be interpreted as a value of 100 (10 seconds).
+
+   An IGMPv2 router will send General Queries with the Max Resp Code set
+   to the desired Max Resp Time, i.e., the full range of this field is
+   linear and the exponential algorithm described in section 4.1.1 is
+   not used.
+
+   Whenever a host changes its compatibility mode, it cancels all its
+   pending response and retransmission timers.
+
+7.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.  A host MAY allow its IGMPv3
+   Membership Record to be suppressed by either a Version 1 Membership
+   Report, or a Version 2 Membership Report.
+
+7.3. Multicast Router Behavior
+
+7.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 yet been upgraded to IGMPv3.  The following
+   requirements apply:
+
+   o 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 act in IGMPv1 or IGMPv2 compatibility modes.  When in IGMPv1
+     mode, routers MUST send Periodic Queries with a Max Resp Code of 0
+     and truncated at the Group Address field (i.e., 8 bytes long), and
+     MUST ignore Leave Group messages.  They SHOULD also warn about
+     receiving an IGMPv2 or IGMPv3 query, although such warnings MUST be
+     rate-limited.  When in IGMPv2 mode, routers MUST send Periodic
+     Queries truncated at the Group Address field (i.e., 8 bytes long),
+     and SHOULD also warn about receiving an IGMPv3 query (such warnings
+     MUST be rate-limited).  They also MUST fill in the Max Resp Time in
+     the Max Resp Code field, i.e., the exponential algorithm described
+     in section 4.1.1 is not used.
+
+   o If a router is not explicitly configured to use IGMPv1 or IGMPv2
+     and hears an IGMPv1 Query or IGMPv2 General Query, it SHOULD log a
+     warning.  These warnings MUST be rate-limited.
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 37]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+7.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.  In order to be compatible with
+   older version hosts, IGMPv3 routers MUST operate in version 1 and
+   version 2 compatibility modes.  IGMPv3 routers keep a compatibility
+   mode per group record.  A group's compatibility mode is determined
+   from the Group Compatibility Mode variable which can be in one of
+   three states:  IGMPv1, IGMPv2 or IGMPv3.  This variable is kept per
+   group record and is dependent on the version of Membership Reports
+   heard for that group as well as the Older Version Host Present timer
+   for the group.
+
+   In order to switch gracefully between versions of IGMP, routers keep
+   an IGMPv1 Host Present timer and an IGMPv2 Host Present timer per
+   group record.  The IGMPv1 Host Present timer is set to Older Version
+   Host Present Timeout seconds whenever an IGMPv1 Membership Report is
+   received.  The IGMPv2 Host Present timer is set to Older Version Host
+   Present Timeout seconds whenever an IGMPv2 Membership Report is
+   received.
+
+   The Group Compatibility Mode of a group record changes whenever an
+   older version report (than the current compatibility mode) is heard
+   or when certain timer conditions occur.  When the IGMPv1 Host Present
+   timer expires, a router switches to Group Compatibility mode of
+   IGMPv2 if it has a running IGMPv2 Host Present timer.  If it does not
+   have a running IGMPv2 Host Present timer then it switches to Group
+   Compatibility of IGMPv3.  When the IGMPv2 Host Present timer expires
+   and the IGMPv1 Host Present timer is not running, a router switches
+   to Group Compatibility mode of IGMPv3.  Note that when a group
+   switches back to IGMPv3 mode, it takes some time to regain source-
+   specific state information.  Source-specific information will be
+   learned during the next General Query, but sources that should be
+   blocked will not be blocked until [Group Membership Interval] after
+   that.
+
+   The Group Compatibility Mode variable is based on whether an older
+   version report was heard in the last Older Version Host Present
+   Timeout seconds.  The Group Compatibility Mode is set depending on
+   the following:
+
+
+
+
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 38]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   Group Compatibility Mode      Timer State
+   ------------------------      -----------
+
+         IGMPv3 (default)        IGMPv2 Host Present not running
+                                 and IGMPv1 Host Present not running
+
+         IGMPv2                  IGMPv2 Host Present running
+                                 and IGMPv1 Host Present not running
+
+         IGMPv1                  IGMPv1 Host Present running
+
+   If a router receives a report which causes its older Host Present
+   timers to be updated and correspondingly its compatibility mode, it
+   SHOULD switch compatibility modes immediately.
+
+   When Group Compatibility Mode is IGMPv3, a router acts using the
+   IGMPv3 protocol for that group.
+
+   When Group Compatibility Mode is IGMPv2, a router internally
+   translates the following IGMPv2 messages for that group to their
+   IGMPv3 equivalents:
+
+       IGMPv2 Message                IGMPv3 Equivalent
+       --------------                -----------------
+
+         Report                        IS_EX( {} )
+
+         Leave                         TO_IN( {} )
+
+   IGMPv3 BLOCK messages are ignored, as are source-lists in TO_EX()
+   messages (i.e., any TO_EX() message is treated as TO_EX( {} )).
+
+   When Group Compatibility Mode is IGMPv1, a router internally
+   translates the following IGMPv1 and IGMPv2 messages for that group to
+   their IGMPv3 equivalents:
+
+       IGMP Message                  IGMPv3 Equivalent
+       ------------                  -----------------
+
+         v1 Report                      IS_EX( {} )
+
+         v2 Report                      IS_EX( {} )
+
+   In addition to ignoring IGMPv3 BLOCK messages and source-lists in
+   TO_EX() messages as in IGMPv2 Group Compatibility Mode, IGMPv2 Leave
+   messages and IGMPv3 TO_IN() messages are also ignored.
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 39]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+8. 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.
+
+8.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
+
+8.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.
+
+8.3. Query Response Interval
+
+   The Max Response Time used to calculate the Max Resp Code 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 less bursty, as host responses are spread out over a
+   larger interval.  The number of seconds represented by the [Query
+   Response Interval] must be less than the [Query Interval].
+
+8.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 or a particular source on a network.
+
+   This value MUST be ((the Robustness Variable) times (the Query
+   Interval)) plus (one Query Response Interval).
+
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 40]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+8.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).
+
+8.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.
+
+8.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.
+
+8.8. Last Member Query Interval
+
+   The Last Member Query Interval is the Max Response Time used to
+   calculate the Max Resp Code inserted into Group-Specific Queries sent
+   in response to Leave Group messages.  It is also the Max Response
+   Time used in calculating the Max Resp Code for Group-and-Source-
+   Specific Query messages.  Default: 10 (1 second)
+
+   Note that for values of LMQI greater than 12.8 seconds, a limited set
+   of values can be represented, corresponding to sequential values of
+   Max Resp Code.  When converting a configured time to a Max Resp Code
+   value, it is recommended to use the exact value if possible, or the
+   next lower value if the requested value is not exactly representable.
+
+   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 or source.
+
+8.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.  The Last
+   Member Query Count is also the number of Group-and-Source-Specific
+   Queries sent before the router assumes there are no listeners for a
+   particular source.  Default: the Robustness Variable.
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 41]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+8.10. Last Member Query Time
+
+   The Last Member Query Time is the time value represented by the Last
+   Member Query Interval, multiplied by the Last Member Query Count.  It
+   is not a tunable value, but may be tuned by changing its components.
+
+8.11. Unsolicited Report Interval
+
+   The Unsolicited Report Interval is the time between repetitions of a
+   host's initial report of membership in a group.  Default: 1 second.
+
+8.12. Older Version Querier Present Timeout
+
+   The Older Version Querier Interval is the time-out for transitioning
+   a host back to IGMPv3 mode once an older version query is heard.
+   When an older version query is received, hosts set their Older
+   Version Querier Present Timer to Older Version Querier Interval.
+
+   This value MUST be ((the Robustness Variable) times (the Query
+   Interval in the last Query received)) plus (one Query Response
+   Interval).
+
+8.13. Older Host Present Interval
+
+   The Older Host Present Interval is the time-out for transitioning a
+   group back to IGMPv3 mode once an older version report is sent for
+   that group.  When an older version report is received, routers set
+   their Older Host Present Timer to Older Host Present Interval.
+
+   This value MUST be ((the Robustness Variable) times (the Query
+   Interval)) plus (one Query Response Interval).
+
+8.14. Configuring Timers
+
+   This section is meant to provide advice to network administrators on
+   how to tune these settings to their network.  Ambitious router
+   implementations might tune these settings dynamically based upon
+   changing characteristics of the network.
+
+8.14.1. Robustness Variable
+
+   The Robustness Variable tunes IGMP to expected losses on a link.
+   IGMPv3 is robust to (Robustness Variable - 1) packet losses, e.g., if
+   the Robustness Variable is set to the default value of 2, IGMPv3 is
+   robust to a single packet loss but may operate imperfectly if more
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 42]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   losses occur.  On lossy subnetworks, the Robustness Variable should
+   be increased to allow for the expected level of packet loss. However,
+   increasing the Robustness Variable increases the leave latency of the
+   subnetwork.  (The leave latency is the time between when the last
+   member stops listening to a source or group and when the traffic
+   stops flowing.)
+
+8.14.2. Query Interval
+
+   The overall level of periodic IGMP traffic is inversely proportional
+   to the Query Interval.  A longer Query Interval results in a lower
+   overall level of IGMP traffic.  The Query Interval MUST be equal to
+   or longer than the Max Response Time inserted in General Query
+   messages.
+
+8.14.3. Max Response Time
+
+   The burstiness of IGMP traffic is inversely proportional to the Max
+   Response Time.  A longer Max Response Time will spread Report
+   messages over a longer interval.  However, a longer Max Response Time
+   in Group-Specific and Source-and-Group-Specific Queries extends the
+   leave latency.  (The leave latency is the time between when the last
+   member stops listening to a source or group and when the traffic
+   stops flowing.)  The expected rate of Report messages can be
+   calculated by dividing the expected number of Reporters by the Max
+   Response Time.  The Max Response Time may be dynamically calculated
+   per Query by using the expected number of Reporters for that Query as
+   follows:
+
+      Query Type            Expected number of Reporters
+      ----------            ----------------------------
+
+      General Query         All systems on subnetwork
+
+      Group-Specific Query  All systems that had expressed interest
+                            in the group on the subnetwork
+
+      Source-and-Group-     All systems on the subnetwork that had
+      Specific Query        expressed interest in the source and group
+
+   A router is not required to calculate these populations or tune the
+   Max Response Time dynamically; these are simply guidelines.
+
+9. Security Considerations
+
+   We consider the ramifications of a forged message of each type, and
+   describe the usage of IPSEC AH to authenticate messages if desired.
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 43]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+9.1. 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].
+
+   A DoS attack on a host could be staged through forged Group-and-
+   Source-Specific Queries.  The attacker can find out about membership
+   of a specific host with a general query.  After that it could send a
+   large number of Group-and-Source-Specific queries, each with a large
+   source list and the Maximum Response Time set to a large value.  The
+   host will have to store and maintain the sources specified in all of
+   those queries for as long as it takes to send the delayed response.
+   This would consume both memory and CPU cycles in order to augment the
+   recorded sources with the source lists included in the successive
+   queries.
+
+   To protect against such a DoS attack, a host stack implementation
+   could restrict the number of Group-and-Source-Specific Queries per
+   group membership within this interval, and/or record only a limited
+   number of sources.
+
+   Forged Query messages from the local network can be easily traced.
+   There are three measures necessary to defend against externally
+   forged Queries:
+
+   o Routers SHOULD NOT forward Queries.  This is easier for a router to
+     accomplish if the Query carries the Router-Alert option.
+
+   o Hosts SHOULD ignore v2 or v3 Queries without the Router-Alert
+     option.
+
+   o Hosts SHOULD ignore v1, v2 or v3 General Queries sent to a
+     multicast address other than 224.0.0.1, the all-systems address.
+
+9.2. Current-State 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:
+
+
+
+Cain, et. al.               Standards Track                    [Page 44]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   o 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.  Report messages with a source address of 0.0.0.0 SHOULD
+     be accepted on any interface.
+
+   o Ignore Report messages without Router Alert options [RFC-2113], 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 IGMPv1 or earlier versions of IGMPv2 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.
+
+   A forged Version 2 Report Message may put a router into "version 2
+   members present" state for a particular group, meaning that the
+   router will ignore IGMPv3 source-specific state messages.  This can
+   cause traffic to flow from unwanted sources for up to [Group
+   Membership Interval].  This can be solved by providing routers with a
+   configuration switch to ignore Version 2 messages completely.  This
+   breaks automatic compatibility with Version 2 hosts, so should only
+   be used in situations where source include and exclude is critical.
+
+9.3. State-Change Report Messages
+
+   A forged State-Change Report message will cause the Querier to send
+   out Group-Specific or Source-and-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.
+   There are two defenses against externally forged State-Change Report
+   messages:
+
+
+
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 45]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   o Ignore the State-Change Report message if you cannot identify the
+     source address of the packet as belonging to a subnet assigned to
+     the interface on which the packet was received.  This solution
+     means that State-Change Report messages sent by mobile hosts
+     without addresses on the local subnet will be ignored.  State-
+     Change Report messages with a source address of 0.0.0.0 SHOULD be
+     accepted on any interface.
+
+   o Ignore State-Change Report messages without Router Alert options
+     [RFC-2113], and require that routers not forward State-Change
+     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.)
+
+9.4. IPSEC Usage
+
+   In addition to these measures, IPSEC in Authentication Header mode
+   [AH] may be used to protect against remote attacks by ensuring that
+   IGMPv3 messages came from a system on the LAN (or, more specifically,
+   a system with the proper key).  When using IPSEC, the messages sent
+   to 224.0.0.1 and 224.0.0.22 should be authenticated using AH.  When
+   keying, there are two possibilities:
+
+   1. Use a symmetric signature algorithm with a single key for the LAN
+      (or a key for each group).  This allows validation that a packet
+      was sent by a system with the key.  This has the limitation that
+      any system with the key can forge a message; it is not possible to
+      authenticate the individual sender precisely.  It also requires
+      disabling IPSec's Replay Protection.
+
+   2. When appropriate key management standards have been developed, use
+      an asymmetric signature algorithm.  All systems need to know the
+      public key of all routers, and all routers need to know the public
+      key of all systems.  This requires a large amount of key
+      management but has the advantage that senders can be authenticated
+      individually so e.g., a host cannot forge a message that only
+      routers should be allowed to send.
+
+   This solution only directly applies to Query and Leave messages in
+   IGMPv1 and IGMPv2, since Reports are sent to the group being reported
+   and it is not feasible to agree on a key for host-to-router
+   communication for arbitrary multicast groups.
+
+
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 46]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+10. IANA Considerations
+
+   All IGMP types described in this document are already assigned in
+   [IANA-REG].
+
+11. Acknowledgments
+
+   We would like to thank Ran Atkinson, Luis Costa, Toerless Eckert,
+   Dino Farinacci, Serge Fdida, Wilbert de Graaf, Sumit Gupta, Mark
+   Handley, Bob Quinn, Michael Speer, Dave Thaler and Rolland Vida for
+   comments and suggestions on this document.
+
+   Portions of the text of this document were copied from [RFC-1112] and
+   [RFC-2236].
+
+12. Normative References
+
+   [AH]         Kent, S. and R. Atkinson, "IP Authentication Header",
+                RFC 2402, November 1998.
+
+   [IANA-REG]   http://www.iana.org/assignments/igmp-type-numbers
+
+   [RFC-1112]   Deering, S., "Host Extensions for IP Multicasting", STD
+                5, RFC 1112, August 1989.
+
+   [RFC-2113]   Katz, D., "IP Router Alert Option," RFC 2113, February,
+                1997.
+
+   [RFC-2119]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC-2236]   Fenner, W., "Internet Group Management Protocol, Version
+                2", RFC 2236, November 1997.
+
+   [RFC-3228]   Fenner, B., "IANA Considerations for IPv4 Internet Group
+                Management Protocol (IGMP)", BCP 57, RFC 3228, February
+                2002.
+
+13. Informative References
+
+   [RFC-1071]   Braden, R., Borman, D. and C.  Partridge, "Computing the
+                Internet checksum", RFC 1071, September 1988.
+
+   [FILTER-API] Thaler, D., B. Fenner, and B. Quinn, "Socket Interface
+                Extensions for Multicast Source Filters", Work in
+                Progress.
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 47]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   [SSM]        Bhattacharyya, S., et. al., "An Overview of Source-
+                Specific Multicast (SSM)", Work in Progress.
+
+   [MLD]        Deering, S., Fenner, W. and B. Haberman, "Multicast
+                Listener Discovery (MLD) for IPv6", RFC 2710, October
+                1999.
+
+   [MLDV2]      Vida, R., L. Costa, S. Fdida, S. Deering, B. Fenner, I.
+                Kouvelas, and B. Haberman, "Multicast Listener Discovery
+                Version 2 (MLDv2) for IPv6", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 48]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+Appendix A.  Design Rationale
+
+A.1  The Need for State-Change Messages
+
+   IGMPv3 specifies two types of Membership Reports: Current-State and
+   State Change.  This section describes the rationale for the need for
+   both these types of Reports.
+
+   Routers need to distinguish Membership Reports that were sent in
+   response to Queries from those that were sent as a result of a change
+   in interface state.  Membership reports that are sent in response to
+   Membership Queries are used mainly to refresh the existing state at
+   the router; they typically do not cause transitions in state at the
+   router.  Membership Reports that are sent in response to changes in
+   interface state require the router to take some action in response to
+   the received report (see Section 6.4).
+
+   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 increased processing at the router as
+   well as an increase in IGMP traffic on the network.
+
+A.2  Host Suppression
+
+   In IGMPv1 and IGMPv2, a host would cancel sending a pending
+   membership reports if a similar report was observed from another
+   member on the network.  In IGMPv3, this suppression of host
+   membership reports has been removed.  The following points explain
+   the reasons behind this decision.
+
+   1. Routers may want to track per-host membership status on an
+      interface.  This allows routers to implement fast leaves (e.g.,
+      for layered multicast congestion control schemes) as well as track
+      membership status for possible accounting purposes.
+
+   2. Membership Report suppression does not work well on bridged LANs.
+      Many bridges and Layer2/Layer3 switches that implement IGMP
+      snooping do not forward IGMP messages across LAN segments in order
+      to prevent membership report suppression.  Removing membership
+      report suppression eases the job of these IGMP snooping devices.
+
+   3. By eliminating membership report suppression, hosts have fewer
+      messages to process; this leads to a simpler state machine
+      implementation.
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 49]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   4. In IGMPv3, a single membership report now bundles multiple
+      multicast group records to decrease the number of packets sent.
+      In comparison, the previous versions of IGMP required that each
+      multicast group be reported in a separate message.
+
+A.3 Switching Router Filter Modes from EXCLUDE to INCLUDE
+
+   If there exist hosts in both EXCLUDE and INCLUDE modes for a single
+   multicast group in a network, the router must be in EXCLUDE mode as
+   well (see section 6.2.1).  In EXCLUDE mode, a router forwards traffic
+   from all sources unless that source exists in the exclusion source
+   list.  If all hosts in EXCLUDE mode cease to exist, it would be
+   desirable for the router to switch back to INCLUDE mode seamlessly
+   without interrupting the flow of traffic to existing receivers.
+
+   One of the ways to accomplish this is for routers to keep track of
+   all sources desired by hosts that are in INCLUDE mode even though the
+   router itself is in EXCLUDE mode.  If the group timer now expires in
+   EXCLUDE mode, it implies that there are no hosts in EXCLUDE mode on
+   the network (otherwise a membership report from that host would have
+   refreshed the group timer).  The router can then switch to INCLUDE
+   mode seamlessly with the list of sources currently being forwarded in
+   its source list.
+
+Appendix B.  Summary of Changes from IGMPv2
+
+   While the main additional feature of IGMPv3 is the addition of source
+   filtering, the following is a summary of other changes from RFC 2236.
+
+   o State is maintained as Group + List-of-Sources, not simply Group as
+     in IGMPv2.
+
+   o Interoperability with IGMPv1 and IGMPv2 systems is defined as
+     operations on the IGMPv3 state.
+
+   o The IP Service Interface has changed to allow specification of
+     source-lists.
+
+   o The Querier includes its Robustness Variable and Query Interval in
+     Query packets to allow synchronization of these variables on non-
+     Queriers.
+
+   o The Max Response Time in Query messages has an exponential range,
+     changing the maximum from 25.5 seconds to about 53 minutes, for use
+     on links with huge numbers of systems.
+
+   o Hosts retransmit state-change messages for increased robustness.
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 50]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+   o Additional data sections are defined to allow later extensions.
+
+   o Report packets are sent to 224.0.0.22, to assist layer-2 switches
+     in "snooping".
+
+   o Report packets can contain multiple group records, to allow
+     reporting of full current state using fewer packets.
+
+   o Hosts no longer perform suppression, to simplify implementations
+     and permit explicit membership tracking.
+
+   o New Suppress Router-Side Processing (S) flag in Query messages
+     fixes robustness issues which were also present in IGMPv2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 51]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+Authors' Addresses
+
+   Brad Cain
+   Cereva Networks
+
+
+   Steve Deering
+   Cisco Systems, Inc.
+   170 Tasman Drive
+   San Jose, CA 95134-1706
+
+   Phone: +1-408-527-8213
+   EMail: deering@cisco.com
+
+
+   Bill Fenner
+   AT&T Labs - Research
+   75 Willow Rd.
+   Menlo Park, CA 94025
+
+   Phone: +1-650-330-7893
+   EMail: fenner@research.att.com
+
+
+   Isidor Kouvelas
+   Cisco Systems, Inc.
+   170 Tasman Drive
+   San Jose, CA 95134-1706
+
+   Phone: +1-408-525-0727
+   EMail: kouvelas@cisco.com
+
+
+   Ajit Thyagarajan
+   Ericsson IP Infrastructure
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 52]
+
+RFC 3376                         IGMPv3                     October 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cain, et. al.               Standards Track                    [Page 53]
+