As per Relevance of the word membership, we have this rfc below:
Network Working Group W.
Request for Comments: 2236 Xerox
Updates: 1112 November 1997
Category: Standards
Internet Group Management Protocol, Version 2
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1997). All Rights Reserved
This memo documents IGMPv2, used by IP hosts to report
multicast group memberships to routers. It updates STD 5, RFC 1112.
IGMPv2 allows group membership termination to be quickly reported
the routing protocol, which is important for high-bandwidth
groups and/or subnets with highly volatile group membership
This document is a product of the Inter-Domain Multicast
working group within the Internet Engineering Task Force.
are solicited and should be addressed to the working group's
list at idmr@cs.ucl.ac.uk and/or the author(s).
1.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [RFC 2119].
2.
The Internet Group Management Protocol (IGMP) is used by IP hosts
report their multicast group memberships to any immediately
neighboring multicast routers. This memo describes only the use
IGMP between hosts and routers to determine group membership
Routers that are members of multicast groups are expected to
Fenner Standards Track [Page 1]
RFC 2236 Internet Group Management Protocol November 1997
as hosts as well as routers, and may even respond to their
queries. IGMP may also be used between routers, but such use is
specified here
Like ICMP, IGMP is a integral part of IP. It is required to
implemented by all hosts wishing to receive IP multicasts.
messages are encapsulated in IP datagrams, with an IP protocol
of 2. All IGMP messages described in this document are sent with
TTL 1, and contain the IP Router Alert option [RFC 2113] in their
header. All IGMP messages of concern to hosts have the
format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Max Resp Time | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.
There are three types of IGMP messages of concern to the host
router interaction
0x11 = Membership
There are two sub-types of Membership Query messages
- General Query, used to learn which groups have members on
attached network
- Group-Specific Query, used to learn if a particular
has any members on an attached network
These two messages are differentiated by the Group Address,
described in section 1.4 . Membership Query messages
referred to simply as "Query" messages
0x16 = Version 2 Membership
0x17 = Leave
There is an additional type of message, for backwards-
with IGMPv1:
0x12 = Version 1 Membership
Fenner Standards Track [Page 2]
RFC 2236 Internet Group Management Protocol November 1997
This document refers to Membership Reports simply as "Reports".
no version is specified, the statement applies equally to
versions
Unrecognized message types should be silently ignored. New
types may be used by newer versions of IGMP, by multicast
protocols, or other uses
2.2. Max Response
The Max Response Time field is meaningful only in Membership
messages, and specifies the maximum allowed time before sending
responding report in units of 1/10 second. In all other messages,
is set to zero by the sender and ignored by receivers
Varying this setting allows IGMPv2 routers to tune the "
latency" (the time between the moment the last host leaves a
and when the routing protocol is notified that there are no
members), as discussed in section 7.8. It also allows tuning of
burstiness of IGMP traffic on a subnet, as discussed in section 7.3.
2.3.
The checksum is the 16-bit one's complement of the one's
sum of the whole IGMP message (the entire IP payload). For
the checksum, the checksum field is set to zero. When
packets, the checksum MUST be computed and inserted into this field
When receiving packets, the checksum MUST be verified
processing a packet
2.4. Group
In a Membership Query message, the group address field is set to
when sending a General Query, and set to the group address
queried when sending a Group-Specific Query
In a Membership Report or Leave Group message, the group
field holds the IP multicast group address of the group
reported or left
2.5. Other
Note that IGMP messages may be longer than 8 octets,
future backwards-compatible versions of IGMP. As long as the Type
one that is recognized, an IGMPv2 implementation MUST ignore
past the first 8 octets while processing the packet. However,
IGMP checksum is always computed over the whole IP payload, not
over the first 8 octets
Fenner Standards Track [Page 3]
RFC 2236 Internet Group Management Protocol November 1997
3. Protocol
Note that defaults for timer values are described later in
document. Timer and counter names appear in square brackets
The term "interface" is sometimes used in this document to mean "
primary interface on an attached network"; if a router has
physical interfaces on a single network this protocol need only
on one of them. Hosts, on the other hand, need to perform
actions on all interfaces that have memberships associated with them
Multicast routers use IGMP to learn which groups have members on
of their attached physical networks. A multicast router keeps a
of multicast group memberships for each attached network, and a
for each membership. "Multicast group memberships" means
presence of at least one member of a multicast group on a
attached network, not a list of all of the members. With respect
each of its attached networks, a multicast router may assume one
two roles: Querier or Non-Querier. There is normally only
Querier per physical network. All multicast routers start up as
Querier on each attached network. If a multicast router hears
Query message from a router with a lower IP address, it MUST become
Non-Querier on that network. If a router has not heard a
message from another router for [Other Querier Present Interval],
resumes the role of Querier. Routers periodically [Query Interval
send a General Query on each attached network for which this
is the Querier, to solicit membership information. On startup,
router SHOULD send [Startup Query Count] General Queries
closely together [Startup Query Interval] in order to quickly
reliably determine membership information. A General Query
addressed to the all-systems multicast group (224.0.0.1), has a
Address field of 0, and has a Max Response Time of [Query
Interval].
When a host receives a General Query, it sets delay timers for
group (excluding the all-systems group) of which it is a member
the interface from which it received the query. Each timer is set
a different random value, using the highest clock
available on the host, selected from the range (0, Max Response Time
with Max Response Time as specified in the Query packet. When a
receives a Group-Specific Query, it sets a delay timer to a
value selected from the range (0, Max Response Time] as above for
group being queried if it is a member on the interface from which
received the query. If a timer for the group is already running,
is reset to the random value only if the requested Max Response
is less than the remaining value of the running timer. When
group's timer expires, the host multicasts a Version 2
Report to the group, with IP TTL of 1. If the host receives
Fenner Standards Track [Page 4]
RFC 2236 Internet Group Management Protocol November 1997
host's Report (version 1 or 2) while it has a timer running, it
its timer for the specified group and does not send a Report,
order to suppress duplicate Reports
When a router receives a Report, it adds the group being reported
the list of multicast group memberships on the network on which
received the Report and sets the timer for the membership to
[Group Membership Interval]. Repeated Reports refresh the timer.
no Reports are received for a particular group before this timer
expired, the router assumes that the group has no local members
that it need not forward remotely-originated multicasts for
group onto the attached network
When a host joins a multicast group, it should immediately
an unsolicited Version 2 Membership Report for that group, in case
is the first member of that group on the network. To cover
possibility of the initial Membership Report being lost or damaged
it is recommended that it be repeated once or twice after
delays [Unsolicited Report Interval]. (A simple way to
this is to send the initial Version 2 Membership Report and then
as if a Group-Specific Query was received for that group, and set
timer appropriately).
When a host leaves a multicast group, if it was the last host
reply to a Query with a Membership Report for that group, it
send a Leave Group message to the all-routers multicast
(224.0.0.2). If it was not the last host to reply to a Query, it
send nothing as there must be another member on the subnet. This
an optimization to reduce traffic; a host without sufficient
to remember whether or not it was the last host to reply MAY
send a Leave Group message when it leaves a group. Routers
accept a Leave Group message addressed to the group being left,
order to accommodate implementations of an earlier version of
standard. Leave Group messages are addressed to the all-
group because other group members have no need to know that a
has left the group, but it does no harm to address the message to
group
When a Querier receives a Leave Group message for a group that
group members on the reception interface, it sends [Last Member
Count] Group-Specific Queries every [Last Member Query Interval]
the group being left. These Group-Specific Queries have their
Response time set to [Last Member Query Interval]. If no Reports
received after the response time of the last query expires,
routers assume that the group has no local members, as above.
Querier to non-Querier transition is ignored during this time;
same router keeps sending the Group-Specific Queries
Fenner Standards Track [Page 5]
RFC 2236 Internet Group Management Protocol November 1997
Non-Queriers MUST ignore Leave Group messages, and Queriers
ignore Leave Group messages for which there are no group members
the reception interface
When a non-Querier receives a Group-Specific Query message, if
existing group membership timer is greater than [Last Member
Count] times the Max Response Time specified in the message, it
its group membership timer to that value
4. Compatibility with IGMPv1
An IGMPv2 host may be placed on a subnet where the Querier router
not yet been upgraded to IGMPv2. The following requirements apply
The IGMPv1 router will send General Queries with the
Response Time set to 0. This MUST be interpreted as a value
100 (10 seconds).
The IGMPv1 router expects Version 1 Membership Reports
response to its Queries, and will not pay attention to Version 2
Membership Reports. Therefore, a state variable MUST be
for each interface, describing whether the multicast Querier
that interface is running IGMPv1 or IGMPv2. This variable
be based upon whether or not an IGMPv1 query was heard in
last [Version 1 Router Present Timeout] seconds, and MUST NOT
based upon the type of the last Query heard. This
variable MUST be used to decide what type of Membership
to send for unsolicited Membership Reports as well as
Reports in response to Queries
An IGMPv2 host MAY suppress Leave Group messages on a
where the Querier is using IGMPv1.
An IGMPv2 router may be placed on a subnet where at least one
on the subnet has not yet been upgraded to IGMPv2. The
requirements apply
If any IGMPv1 routers are present, the querier MUST use IGMPv1.
The use of IGMPv1 must be administratively configured, as
is no reliable way of dynamically determining whether IGMPv
routers are present on a network. Implementations MAY provide
way for system administrators to enable the use of IGMPv1
their routers; in the absence of explicit configuration,
configuration MUST default to IGMPv2. When in IGMPv1 mode
routers MUST send Periodic Queries with a Max Response Time
0, and MUST ignore Leave Group messages. They SHOULD also
about receiving an IGMPv2 query, although such warnings MUST
rate-limited
Fenner Standards Track [Page 6]
RFC 2236 Internet Group Management Protocol November 1997
If a router is not explicitly configured to use IGMPv1 and
an IGMPv1 Query, it SHOULD log a warning. These warnings
be rate-limited
5. Compatibility with IGMPv1
An IGMPv2 host may be placed on a subnet where there are hosts
have not yet been upgraded to IGMPv2. The following
applies
The host MUST allow its Membership Report to be suppressed
either a Version 1 Membership Report or a Version 2
Report
An IGMPv2 router may be placed on a subnet where there are hosts
have not yet been upgraded to IGMPv2. The following
apply
If a router receives a Version 1 Membership Report, it MUST
a timer to note that there are version 1 hosts present which
members of the group for which it heard the report. This
should be the same as the [Group Membership Interval].
If there are version 1 hosts present for a particular group,
router MUST ignore any Leave Group messages that it receives
that group
6. Host State
Host behavior is more formally specified by the state
diagram below. A host may be in one of three possible states
respect to any single IP multicast group on any single
interface
- "Non-Member" state, when the host does not belong to the group
the interface. This is the initial state for all memberships
all network interfaces; it requires no storage in the host
- "Delaying Member" state, when the host belongs to the group on
interface and has a report delay timer running for that membership
- "Idle Member" state, when the host belongs to the group on
interface and does not have a report delay timer running for
membership
Fenner Standards Track [Page 7]
RFC 2236 Internet Group Management Protocol November 1997
There are five significant events that can cause IGMP
transitions
- "join group" occurs when the host decides to join the group on
interface. It may occur only in the Non-Member state
- "leave group" occurs when the host decides to leave the group
the interface. It may occur only in the Delaying Member and
Member states
- "query received" occurs when the host receives either a
General Membership Query message, or a valid Group-
Membership Query message. To be valid, the Query message must
at least 8 octets long, and have a correct IGMP checksum.
group address in the IGMP header must either be zero (a
Query) or a valid multicast group address (a Group-Specific Query).
A General Query applies to all memberships on the interface
which the Query is received. A Group-Specific Query applies
membership in a single group on the interface from which the
is received. Queries are ignored for memberships in the Non-
state
- "report received" occurs when the host receives a valid
Membership Report message (Version 1 or Version 2). To be valid
the Report message must be at least 8 octets long and have
correct IGMP checksum. A Membership Report applies only to
membership in the group identified by the Membership Report, on
interface from which the Membership Report is received. It
ignored for memberships in the Non-Member or Idle Member state
- "timer expired" occurs when the report delay timer for the group
the interface expires. It may occur only in the Delaying
state
All other events, such as receiving invalid IGMP messages, or
messages other than Query or Report, are ignored in all states
There are seven possible actions that may be taken in response to
above events
- "send report" for the group on the interface. The type of
is determined by the state of the interface. The Report Message
sent to the group being reported
Fenner Standards Track [Page 8]
RFC 2236 Internet Group Management Protocol November 1997
- "send leave" for the group on the interface. If the
state says the Querier is running IGMPv1, this action SHOULD
skipped. If the flag saying we were the last host to report
cleared, this action MAY be skipped. The Leave Message is sent
the ALL-ROUTERS group (224.0.0.2).
- "set flag" that we were the last host to send a report for
group
- "clear flag" since we were not the last host to send a report
this group
- "start timer" for the group on the interface, using a delay
chosen uniformly from the interval (0, Max Response Time],
Max Response time is specified in the Query. If this is
unsolicited Report, the timer is set to a delay value
uniformly from the interval (0, [Unsolicited Report Interval] ].
- "reset timer" for the group on the interface to a new value,
a delay value chosen uniformly from the interval (0, Max
Time], as described in "start timer".
- "stop timer" for the group on the interface
In all of the following state diagrams, each state transition arc
labeled with the event that causes the transition, and,
parentheses, any actions taken during the transition. Note that
transition is always triggered by the event; even if the action
conditional, the transition still occurs
Fenner Standards Track [Page 9]
RFC 2236 Internet Group Management Protocol November 1997
________________
| |
| |
| |
| |
--------->| Non-Member |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| leave group | join group | leave
| (stop timer, |(send report, | (send
| send leave if | set flag, | if flag set
| flag set) | start timer) |
________|________ | ________|________
| |<--------- | |
| | | |
| |<-------------------| |
| | query received | |
| Delaying Member | (start timer) | Idle Member |
---->| |------------------->| |
| | | report received | |
| | | (stop timer, | |
| | | clear flag) | |
| |_________________|------------------->|_________________|
| query received | timer
| (reset timer if | (send report
| Max Resp Time | set flag
| < current timer) |
-------------------
The all-systems group (address 224.0.0.1) is handled as a
case. The host starts in Idle Member state for that group on
interface, never transitions to another state, and never sends
report for that group
In addition, a host may be in one of two possible states with
to any single network interface
- "No IGMPv1 Router Present", when the host has not heard an IGMPv
style query for the [Version 1 Router Present Timeout]. This
the initial state
- "IGMPv1 Router Present", when the host has heard an IGMPv1
query within the [Version 1 Router Present Timeout].
Fenner Standards Track [Page 10]
RFC 2236 Internet Group Management Protocol November 1997
There are two events that can cause state transitions
- "IGMPv1 query received", when the host receives a query with
Max Response Time field set to 0.
- "timer expires", when the timer set to note the presence of
IGMPv1 router expires
And a single action that can be triggered by an event
- "set timer", setting the timer to its maximum value [Version 1
Router Present Timeout] and (re)starting it
________________
| |
| |
| No IGMPv1 |
| Router |
| Present |
| |
---->| |----
| | | |
| |________________| |
timer expires | | IGMPv1
| ________________ |
| | | | (set timer
| | | |
| | | |
-----| IGMPv1 |<---
| Router |
| Present |
| |
---->| |----
| |________________| |
| |
| IGMPv1 query received |
| (set timer) |
---------------------------
Fenner Standards Track [Page 11]
RFC 2236 Internet Group Management Protocol November 1997
7. Router State
Router behavior is more formally specified by the state
diagrams below
A router may be in one of two possible states with respect to
single attached network
- "Querier", when this router is designated to transmit
Membership Queries on this network
- "Non-Querier", when there is another router designated to
IGMP membership Queries on this network
The following three events can cause the router to change states
- "query timer expired" occurs when the timer set for
transmission expires
- "query received from a router with a lower IP address" occurs
an IGMP Membership Query is received from a router on the
network with a lower IP address
- "other querier present timer expired" occurs when the timer set
note the presence of another querier with a lower IP address on
network expires
There are three actions that may be taken in response to the
events
- "start general query timer" for the attached network
- "start other querier present timer" for the attached network [
Querier Present Interval].
- "send general query" on the attached network. The General Query
sent to the all-systems group (224.0.0.1), and has a Max
Time of [Query Response Interval].
Fenner Standards Track [Page 12]
RFC 2236 Internet Group Management Protocol November 1997
--------------------------------
_______|________ gen. query timer |
--------- | | expired |
| Initial |---------------->| | (send general query, |
--------- (send gen. q., | | set gen. q. timer) |
set initial gen. q. | |<----------------------
timer) | Querier |
| |
-----| |<---
| | | |
| |________________| |
query received from a | | other
router with a lower | | present
IP address | |
(set other querier | ________________ | (send
present timer) | | | | query,set gen
| | | | q. timer
| | | |
---->| Non |----
| Querier |
| |
| |
---->| |----
| |________________| |
| query received from a |
| router with a lower IP |
| address |
| (set other querier |
| present timer) |
---------------------------
A router should start in the Initial state on all attached networks
and immediately move to Querier state
In addition, to keep track of which groups have members, a router
be in one of four possible states with respect to any single
multicast group on any single attached network
- "No Members Present" state, when there are no hosts on the
which have sent reports for this multicast group. This is
initial state for all groups on the router; it requires no
in the router
- "Members Present" state, when there is a host on the network
has sent a Membership Report for this multicast group
Fenner Standards Track [Page 13]
RFC 2236 Internet Group Management Protocol November 1997
- "Version 1 Members Present" state, when there is an IGMPv1 host
the network which has sent a Version 1 Membership Report for
multicast group
- "Checking Membership" state, when the router has received
Leave Group message but has not yet heard a Membership Report
the multicast group
There are six significant events that can cause router
transitions
- "v2 report received" occurs when the router receives a Version 2
Membership Report for the group on the interface. To be valid,
Report message must be at least 8 octets long and must have
correct IGMP checksum
- "v1 report received" occurs when the router receives a Version 1
Membership report for the group on the interface. The
validity requirements apply
- "leave received" occurs when the router receives an IGMP
Leave message for the group on the interface. To be valid,
Leave message must be at least 8 octets long and must have
correct IGMP checksum
- "timer expired" occurs when the timer set for a group
expires
- "retransmit timer expired" occurs when the timer set to
a group-specific Membership Query expires
- "v1 host timer expired" occurs when the timer set to note
presence of version 1 hosts as group members expires
There are six possible actions that may be taken in response to
above events
- "start timer" for the group membership on the interface -
resets the timer to its initial value [Group Membership Interval
if the timer is currently running
- "start timer*" for the group membership on the interface -
alternate action sets the timer to [Last Member Query Interval] *
[Last Member Query Count] if this router is a Querier, or the [
Response Time] in the packet * [Last Member Query Count] if
router is a non-Querier
Fenner Standards Track [Page 14]
RFC 2236 Internet Group Management Protocol November 1997
- "start retransmit timer" for the group membership on the
[Last Member Query Interval].
- "start v1 host timer" for the group membership on the interface
also resets the timer to its initial value [Group
Interval] if the timer is currently running
- "send group-specific query" for the group on the attached network
The Group-Specific Query is sent to the group being queried,
has a Max Response Time of [Last Member Query Interval].
- "notify routing +" notify the routing protocol that there
members of this group on this connected network
- "notify routing -" notify the routing protocol that there are
longer any members of this group on this connected network
The state diagram for a router in Querier state follows
Fenner Standards Track [Page 15]
RFC 2236 Internet Group Management Protocol November 1997
________________
----------------------------| |<-----------------------
| | |timer expired |
| timer expired| |(notify routing -, |
| (notify routing -)| No Members |clear rxmt tmr) |
| ------->| Present |<------- |
| | | | | |
|v1 report rec'd | | | | ------------ |
|(notify routing +, | |________________| | | rexmt timer| |
| start timer, | | | | expired | |
| start v1 host | v2 report received| | | (send g-s | |
| timer) | (notify routing +,| | | query, | |
| | start timer)| | | st rxmt | |
| __________|______ | _____|_|______ tmr)| |
| | |<------------ | | | |
| | | | |<----- |
| | | v2 report received | | |
| | | (start timer) | | |
| | Members Present |<-------------------| Checking | |
| ----->| | leave received | Membership | |
| | | | (start timer*, | | |
| | | | start rexmt timer,| | |
| | | | send g-s query) | | |
| | --->| |------------------->| | |
| | | |_________________| |______________| |
| | |v2 report rec'd | | | |
| | |(start timer) | |v1 report rec'd |v1 report rec'd |
| | ---------------- |(start timer, |(start timer, |
| |v1 host | start v1 host timer) | start v1 host |
| |tmr ______________V__ | timer) |
| |exp'd | |<---------------------- |
| ------| | |
| | Version 1 |timer expired |
| | Members Present |(notify routing -) |
------->| |-------------------------------------------
| |<--------------------
------->|_________________| v1 report rec'd |
| v2 report rec'd | | (start timer, |
| (start timer) | | start v1 host timer) |
----------------- --------------------------
Fenner Standards Track [Page 16]
RFC 2236 Internet Group Management Protocol November 1997
The state diagram for a router in Non-Querier state is similar
but non-Queriers do not send any messages and are only driven
message reception.Note that non-Queriers do not care whether
Membership Report message is Version 1 or Version 2.
________________
| |
| |
timer expired| |timer
(notify routing -)| No Members |(notify routing -)
--------->| Present |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| |report received |
| |(notify routing +,|
| | start timer) |
________|________ | ________|________
| |<--------- | |
| | report received | |
| | (start timer) | |
| Members Present |<-------------------| Checking |
| | g-s query rec'd | Membership |
| | (start timer*) | |
---->| |------------------->| |
| |_________________| |_________________|
| report received |
| (start timer) |
-----------------
8. List of timers and default
Most of these timers are configurable. If non-default
are used, they MUST be consistent among all routers on a
link. Note that parentheses are used to group expressions
make the algebra clear
8.1. Robustness
The Robustness Variable allows tuning for the expected packet loss
a subnet. If a subnet is expected to be lossy, the
Variable may be increased. IGMP is robust to (Robustness Variable-1)
packet losses. The Robustness Variable MUST NOT be zero, and
NOT be one. Default: 2
Fenner Standards Track [Page 17]
RFC 2236 Internet Group Management Protocol November 1997
8.2. Query
The Query Interval is the interval between General Queries sent
the Querier. Default: 125 seconds
By varying the [Query Interval], an administrator may tune the
of IGMP messages on the subnet; larger values cause IGMP Queries
be sent less often
8.3. Query Response
The Max Response Time inserted into the periodic General Queries
Default: 100 (10 seconds
By varying the [Query Response Interval], an administrator may
the burstiness of IGMP messages on the subnet; larger values make
traffic less bursty, as host responses are spread out over a
interval. The number of seconds represented by the [Query
Interval] must be less than the [Query Interval].
8.4. Group Membership
The Group Membership Interval is the amount of time that must
before a multicast router decides there are no more members of
group on a network. This value MUST be ((the Robustness Variable
times (the Query Interval)) plus (one Query Response Interval).
8.5. Other Querier Present
The Other Querier Present Interval is the length of time that
pass before a multicast router decides that there is no
another multicast router which should be the querier. This
MUST be ((the Robustness Variable) times (the Query Interval))
(one half of one Query Response Interval).
8.6. Startup Query
The Startup Query Interval is the interval between General
sent by a Querier on startup. Default: 1/4 the Query Interval
8.7. Startup Query
The Startup Query Count is the number of Queries sent out on startup
separated by the Startup Query Interval. Default: the
Variable
Fenner Standards Track [Page 18]
RFC 2236 Internet Group Management Protocol November 1997
8.8. Last Member Query
The Last Member Query Interval is the Max Response Time inserted
Group-Specific Queries sent in response to Leave Group messages,
is also the amount of time between Group-Specific Query messages
Default: 10 (1 second
This value may be tuned to modify the "leave latency" of the network
A reduced value results in reduced time to detect the loss of
last member of a group
8.9. Last Member Query
The Last Member Query Count is the number of Group-Specific
sent before the router assumes there are no local members. Default
the Robustness Variable
8.10. Unsolicited Report
The Unsolicited Report Interval is the time between repetitions of
host's initial report of membership in a group. Default: 10 seconds
8.11. Version 1 Router Present
The Version 1 Router Present Timeout is how long a host must
after hearing a Version 1 Query before it may send any IGMPv
messages. Value: 400 seconds
9. Message
This information is provided elsewhere in the document, but
summarized here for convenience
Message Type Destination
------------ -----------------
General Query ALL-SYSTEMS (224.0.0.1)
Group-Specific Query The group being
Membership Report The group being
Leave Message ALL-ROUTERS (224.0.0.2)
Note: in older (i.e., non-standard and now obsolete) versions
IGMPv2, hosts send Leave Messages to the group being left.
router SHOULD accept Leave Messages addressed to the group
left in the interests of backwards compatibility with such hosts
In all cases, however, hosts MUST send to the ALL-ROUTERS
to be compliant with this specification
Fenner Standards Track [Page 19]
RFC 2236 Internet Group Management Protocol November 1997
10. Security
We consider the ramifications of a forged message of each type
Query Message
A forged Query message from a machine with a lower IP address
the current Querier will cause Querier duties to be assigned to
forger. If the forger then sends no more Query messages,
routers' Other Querier Present timer will time out and one
resume the role of Querier. During this time, if the
ignores Leave Messages, traffic might flow to groups with
members for up to [Group Membership Interval].
A forged Query message sent to a group with members will cause
hosts which are members of the group to report their memberships
This causes a small amount of extra traffic on the LAN, but
no protocol problems
Report messages
A forged Report message may cause multicast routers to think
are members of a group on a subnet when there are not.
Report messages from the local subnet are meaningless,
joining a group on a host is generally an unprivileged operation
so a local user may trivially gain the same result without
any messages. Forged Report messages from external sources
more troublesome; there are two defenses against externally
Reports
- Ignore the Report if you cannot identify the
address of the packet as belonging to a subnet assigned to
interface on which the packet was received. This solution
that Reports sent by mobile hosts without addresses on the
subnet will be ignored
- Ignore Report messages without Router Alert options [RFC 2113],
and require that routers not forward Report messages. (
requirement is not a requirement of generalized filtering in
forwarding path, since the packets already have Router
options in them). This solution breaks backwards
with implementations of earlier versions of this
which did not require Router Alert
Fenner Standards Track [Page 20]
RFC 2236 Internet Group Management Protocol November 1997
A forged Version 1 Report Message may put a router into "version 1
members present" state for a particular group, meaning that
router will ignore Leave messages. This can cause traffic to
to groups with no members for up to [Group Membership Interval].
There are two defenses against forged v1 Reports
- To defend against externally sourced v1 Reports, ignore
Report if you cannot identify the source address of the packet
belonging to a subnet assigned to the interface on which
packet was received. This solution means that v1 Reports sent
mobile hosts without addresses on the local subnet will
ignored
- Provide routers with a configuration switch to ignore Version 1
messages completely. This breaks automatic compatibility
Version 1 hosts, so should only be used in situations where "
leave" is critical. This solution protects against
version 1 reports from the local subnet as well
Leave message
A forged Leave message will cause the Querier to send out Group
Specific Queries for the group in question. This causes
processing on each router and on each member of the group, but
not cause loss of desired traffic. There are two defenses
externally forged Leave messages
- Ignore the Leave message if you cannot identify the
address of the packet as belonging to a subnet assigned to
interface on which the packet was received. This solution
that Leave messages sent by mobile hosts without addresses on
local subnet will be ignored
- Ignore Leave messages without Router Alert options [RFC 2113],
and require that routers not forward Leave messages. (
requirement is not a requirement of generalized filtering in
forwarding path, since the packets already have Router
options in them). This solution breaks backwards
with implementations of earlier versions of this
which did not require Router Alert
11.
IGMPv2 was designed by Rosen Sharma and Steve Deering
Fenner Standards Track [Page 21]
RFC 2236 Internet Group Management Protocol November 1997
12.
RFC 2119 Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2113 Katz, D., "IP Router Alert Option," RFC 2113,
February 1997.
RFC 1112 Deering, S., "Host Extensions for IP Multicasting",
STD 5, RFC 1112, August 1989.
Fenner Standards Track [Page 22]
RFC 2236 Internet Group Management Protocol November 1997
13. Appendix I - Changes from IGMPv
The IGMPv1 "Version" and "Type" fields are combined into a
"Type" field
A new IGMP Type is assigned to Version 2 Membership Report messages
so a router may tell the difference between an IGMPv1 and IGMPv2
report
A new IGMP Type is created for the IGMPv2 Leave Group message
The Membership Query message is changed so that a previously
field contains a new value, the Max Response Time
The IGMPv2 spec now specifies a querier election mechanism.
IGMPv1, the querier election was left up to the multicast
protocol, and different protocols used different mechanisms.
could result in more than one querier per network, so the
mechanism has been standardized in IGMPv2. However, this means
care must be taken when an IGMPv2 router is trying to coexist with
IGMPv1 router that uses a different querier election mechanism.
particular, it means that an IGMPv2 router must be able to act as
IGMPv1 router on a particular network if configured to do so.
actions required include
- Set the Max Response Time field to 0 in all queries
- Ignore Leave Group messages
The IGMPv2 spec relaxes the requirements on validity-checking
Membership Queries and Membership Reports. When upgrading
implementation, be sure to remove any checks that do not belong
The IGMPv2 spec requires the presence of the IP Router Alert
[RFC 2113] in all packets described in this memo
14. Author's
William C.
Xerox
3333 Coyote Hill
Palo Alto, CA 94304
Phone: +1 650 812 4816
EMail: fenner@parc.xerox.
Fenner Standards Track [Page 23]
RFC 2236 Internet Group Management Protocol November 1997
15. Full Copyright
Copyright (C) The Internet Society (1997). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Fenner Standards Track [Page 24]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
