(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.
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.
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.
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.
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
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.
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.
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
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.
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.
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
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.
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.
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:
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.
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).
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.
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
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.
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:
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:
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.
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",
RFC2402, November 1998.
[IANA-REG] http://www.iana.org/assignments/igmp-type-numbers
[RFC-1112] Deering, S., "Host Extensions for IP Multicasting", STD
5, RFC1112, August 1989.
[RFC-2113] Katz, D., "IP Router Alert Option," RFC2113, February,
1997.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC-2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC2236, November 1997.
[RFC-3228] Fenner, B., "IANA Considerations for IPv4 Internet Group
Management Protocol (IGMP)", BCP 57, RFC3228, February
2002.
13. Informative References
[RFC-1071] Braden, R., Borman, D. and C. Partridge, "Computing the
Internet checksum", RFC1071, September 1988.
[FILTER-API] Thaler, D., B. Fenner, and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", Work in
Progress.
[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", RFC2710, 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.
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