rfc9776v3.txt   rfc9776.txt 
skipping to change at line 271 skipping to change at line 271
* "filter-mode" may be either INCLUDE or EXCLUDE. In INCLUDE mode, * "filter-mode" may be either INCLUDE or EXCLUDE. In INCLUDE mode,
reception of packets sent to the specified multicast address is reception of packets sent to the specified multicast address is
requested only from those IP source addresses listed in the requested only from those IP source addresses listed in the
source-list parameter. In EXCLUDE mode, reception of packets sent source-list parameter. In EXCLUDE mode, reception of packets sent
to the given multicast address is requested from all IP source to the given multicast address is requested from all IP source
addresses except those listed in the source-list parameter. addresses except those listed in the source-list parameter.
* "source-list" is an unordered list of zero or more IP unicast * "source-list" is an unordered list of zero or more IP unicast
addresses from which multicast reception is desired or not addresses from which multicast reception is desired or not
desired, depending on the filter-mode. An implementation MAY desired, depending on the filter-mode. An implementation MAY
impose a limit on the size of source lists, but that limit MUST 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 NOT be less than 64 addresses per list. When an operation causes
the source list size limit to be exceeded, the service interface the source-list size limit to be exceeded, the service interface
MUST return an error. MUST return an error.
For a given combination of socket, interface, and multicast address, 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 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, time. However, either the filter-mode or the source-list, or both,
may be changed by subsequent IPMulticastListen requests that specify may be changed by subsequent IPMulticastListen requests that specify
the same socket, interface, and multicast address. Each subsequent the same socket, interface, and multicast address. Each subsequent
request completely replaces any earlier request for the given socket, request completely replaces any earlier request for the given socket,
interface, and multicast address. interface, and multicast address.
Previous versions of IGMP did not support source filters and had a Previous versions of IGMP did not support source filters and had a
simpler service interface consisting of Join and Leave operations to simpler service interface consisting of Join and Leave operations to
enable and disable reception of a given multicast address (from all enable and disable reception of a given multicast address (from all
sources) on a given interface. The equivalent operations in the new sources) on a given interface. The equivalent operations in the new
skipping to change at line 300 skipping to change at line 300
The Join operation is equivalent to: The Join operation is equivalent to:
IPMulticastListen ( socket, interface, multicast-address, IPMulticastListen ( socket, interface, multicast-address,
EXCLUDE, {} ) EXCLUDE, {} )
and the Leave operation is equivalent to: and the Leave operation is equivalent to:
IPMulticastListen ( socket, interface, multicast-address, IPMulticastListen ( socket, interface, multicast-address,
INCLUDE, {} ) INCLUDE, {} )
where {} is an empty source list. where {} is an empty source-list.
An example of an API providing the capabilities outlined in this An example of an API providing the capabilities outlined in this
service interface is in [RFC3678]. service interface is in [RFC3678].
3. Multicast Reception State Maintained by Systems 3. Multicast Reception State Maintained by Systems
3.1. Socket State 3.1. Socket State
For each socket on which IPMulticastListen has been invoked, the For each socket on which IPMulticastListen has been invoked, the
system records the desired multicast reception state for that socket. system records the desired multicast reception state for that socket.
That state conceptually consists of a set of records of the form: That state conceptually consists of a set of records of the form:
(interface, multicast-address, filter-mode, source-list) (interface, multicast-address, filter-mode, source-list)
The socket state evolves in response to each invocation of The socket state evolves in response to each invocation of
IPMulticastListen on the socket, as follows: IPMulticastListen on the socket, as follows:
* If the requested filter-mode is INCLUDE and the requested source * If the requested filter-mode is INCLUDE and the requested source-
list is empty, then the entry corresponding to the requested list is empty, then the entry corresponding to the requested
interface and multicast address is deleted if present. If no such interface and multicast address is deleted if present. If no such
entry is present, the request is ignored. entry is present, the request is ignored.
* If the requested filter-mode is EXCLUDE or the requested source * If the requested filter-mode is EXCLUDE or the requested source-
list is non-empty, then the entry corresponding to the requested list is non-empty, then the entry corresponding to the requested
interface and multicast address, if present, is changed to contain interface and multicast address, if present, is changed to contain
the requested filter-mode and source list. If no such entry is the requested filter-mode and source-list. If no such entry is
present, a new entry is created, using the parameters specified in present, a new entry is created, using the parameters specified in
the request. the request.
3.2. Interface State 3.2. Interface State
In addition to the per-socket multicast reception state, a system In addition to the per-socket multicast reception state, a system
must also maintain or compute multicast reception state for each of must also maintain or compute multicast reception state for each of
its interfaces. That state conceptually consists of a set of records its interfaces. That state conceptually consists of a set of records
of the form: of the form:
(multicast-address, filter-mode, source-list) (multicast-address, filter-mode, source-list)
At most, one record per multicast-address exists for a given At most, one record per multicast-address exists for a given
interface. This per-interface state is derived from the per-socket interface. This per-interface state is derived from the per-socket
state, but it may differ from the per-socket state when different state, but it may differ from the per-socket state when different
sockets have differing filter-modes and/or source lists for the same sockets have differing filter-modes and/or source-lists for the same
multicast address and interface. For example, suppose one multicast address and interface. For example, suppose one
application or process invokes the following operation on socket s1: application or process invokes the following operation on socket s1:
IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} ) IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} )
requesting reception on interface i of packets sent to multicast requesting reception on interface i of packets sent to multicast
address m, only if they come from source a, b, or c. Suppose another address m, only if they come from source a, b, or c. Suppose another
application or process invokes the following operation on socket s2: application or process invokes the following operation on socket s2:
IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} ) IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} )
requesting reception on the same interface i of packets sent to the 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. 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 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 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 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 state of interface i for multicast address m has filter-mode INCLUDE
and source list {a, b, c, d}. and source-list {a, b, c, d}.
After a multicast packet has been accepted from an interface by the After a multicast packet has been accepted from an interface by the
IP layer, its subsequent delivery to the application or process IP layer, its subsequent delivery to the application or process
listening on a particular socket depends on the multicast reception listening on a particular socket depends on the multicast reception
state of that socket (and possibly also on other conditions, such as 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 what transport-layer port the socket is bound to). So, in the above
example, if a packet arrives on interface i, destined to multicast example, if a packet arrives on interface i, destined to multicast
address m, with source address a, it will be delivered on socket s1 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 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 subject to source filtering and must always be processed by hosts and
skipping to change at line 388 skipping to change at line 388
could be delivered to all sockets whether they had joined or not. could be delivered to all sockets whether they had joined or not.
The general rules for deriving the per-interface state from the per- The general rules for deriving the per-interface state from the per-
socket state are as follows: For each distinct (interface, multicast- socket state are as follows: For each distinct (interface, multicast-
address) pair that appears in any socket state, a per-interface address) pair that appears in any socket state, a per-interface
record is created for that multicast address on that interface. record is created for that multicast address on that interface.
Considering all socket records containing the same (interface, Considering all socket records containing the same (interface,
multicast-address) pair, multicast-address) pair,
* if any such record has a filter-mode of EXCLUDE, then the filter- * 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 mode of the interface record is EXCLUDE, and the source-list of
the interface record is the intersection of the source lists of the interface record is the intersection of the source-lists of
all socket records in EXCLUDE mode, minus those source addresses all socket records in EXCLUDE mode, minus those source addresses
that appear in any socket record in INCLUDE mode. For example, if that appear in any socket record in INCLUDE mode. For example, if
the socket records for multicast address m on interface i are: the socket records for multicast address m on interface i are:
- from socket s1: ( i, m, EXCLUDE, {a, b, c, d} ) - from socket s1: ( i, m, EXCLUDE, {a, b, c, d} )
- from socket s2: ( i, m, EXCLUDE, {b, c, d, e} ) - from socket s2: ( i, m, EXCLUDE, {b, c, d, e} )
- from socket s3: ( i, m, INCLUDE, {d, e, f} ) - from socket s3: ( i, m, INCLUDE, {d, e, f} )
skipping to change at line 413 skipping to change at line 413
If a fourth socket is added, such as: If a fourth socket is added, such as:
- from socket s4: ( i, m, EXCLUDE, {} ) - from socket s4: ( i, m, EXCLUDE, {} )
then the interface record becomes: then the interface record becomes:
- ( m, EXCLUDE, {} ) - ( m, EXCLUDE, {} )
* if all such records have a filter-mode of INCLUDE, then the * if all such records have a filter-mode of INCLUDE, then the
filter-mode of the interface record is INCLUDE, and the source filter-mode of the interface record is INCLUDE, and the source-
list of the interface record is the union of the source lists of list of the interface record is the union of the source-lists of
all the socket records. For example, if the socket records for all the socket records. For example, if the socket records for
multicast address m on interface i are: multicast address m on interface i are:
- from socket s1: ( i, m, INCLUDE, {a, b, c} ) - from socket s1: ( i, m, INCLUDE, {a, b, c} )
- from socket s2: ( i, m, INCLUDE, {b, c, d} ) - from socket s2: ( i, m, INCLUDE, {b, c, d} )
- from socket s3: ( i, m, INCLUDE, {e, f} ) - from socket s3: ( i, m, INCLUDE, {e, f} )
then the corresponding interface record on interface i is: then the corresponding interface record on interface i is:
- ( m, INCLUDE, {a, b, c, d, e, f} ) - ( m, INCLUDE, {a, b, c, d, e, f} )
An implementation MUST NOT use an EXCLUDE interface record to An implementation MUST NOT use an EXCLUDE interface record to
represent a group when all sockets for this group are in INCLUDE represent a group when all sockets for this group are in INCLUDE
state. If system resource limits are reached when an interface state. If system resource limits are reached when an interface
state source list is calculated, an error MUST be returned to the state source-list is calculated, an error MUST be returned to the
application that requested the operation. application that requested the operation.
The above rules for deriving the interface state are (re-)evaluated The above rules for deriving the interface state are (re-)evaluated
whenever an IPMulticastListen invocation modifies the socket state by whenever an IPMulticastListen invocation modifies the socket state by
adding, deleting, or modifying a per-socket state record. Note that adding, deleting, or modifying a per-socket state record. Note that
a change of socket state does not necessarily result in a change of a change of socket state does not necessarily result in a change of
interface state. interface state.
4. Message Formats 4. Message Formats
skipping to change at line 823 skipping to change at line 823
* A Current-State Record is sent by a system in response to a Query * A Current-State Record is sent by a system in response to a Query
received on an interface. It reports the current reception state received on an interface. It reports the current reception state
of that interface, with respect to a single multicast address. of that interface, with respect to a single multicast address.
The Record Type of a Current-State Record may be one of the The Record Type of a Current-State Record may be one of the
following two values: following two values:
1. MODE_IS_INCLUDE - indicates that the interface has a filter- 1. MODE_IS_INCLUDE - indicates that the interface has a filter-
mode of INCLUDE for the specified multicast address. The mode of INCLUDE for the specified multicast address. The
Source Address [i] fields in this Group Record contain the Source Address [i] fields in this Group Record contain the
interface's source list for the specified multicast address, interface's source-list for the specified multicast address,
if it is non-empty. if it is non-empty.
2. MODE_IS_EXCLUDE - indicates that the interface has a filter- 2. MODE_IS_EXCLUDE - indicates that the interface has a filter-
mode of EXCLUDE for the specified multicast address. The mode of EXCLUDE for the specified multicast address. The
Source Address [i] fields in this Group Record contain the Source Address [i] fields in this Group Record contain the
interface's source list for the specified multicast address, interface's source-list for the specified multicast address,
if it is non-empty. An SSM-aware host SHOULD NOT send a if it is non-empty. An SSM-aware host SHOULD NOT send a
MODE_IS_EXCLUDE record type for multicast addresses that fall MODE_IS_EXCLUDE record type for multicast addresses that fall
within the SSM address range as they will be ignored by SSM- within the SSM address range as they will be ignored by SSM-
aware routers [RFC4604]. aware routers [RFC4604].
* A Filter-Mode-Change Record is sent by a system whenever a local * A Filter-Mode-Change Record is sent by a system whenever a local
invocation of IPMulticastListen causes a change of the filter-mode invocation of IPMulticastListen causes a change of the filter-mode
(i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to
INCLUDE) of the interface-level state entry for a particular INCLUDE) of the interface-level state entry for a particular
multicast address. The Record is included in a Report sent from multicast address. The Record is included in a Report sent from
the interface on which the change occurred. The Record Type of a the interface on which the change occurred. The Record Type of a
Filter-Mode-Change Record may be one of the following two values: Filter-Mode-Change Record may be one of the following two values:
3. CHANGE_TO_INCLUDE_MODE - indicates that the interface has 3. CHANGE_TO_INCLUDE_MODE - indicates that the interface has
changed to INCLUDE filter-mode for the specified multicast changed to INCLUDE filter-mode for the specified multicast
address. The Source Address [i] fields in this Group Record address. The Source Address [i] fields in this Group Record
contain the interface's new source list for the specified contain the interface's new source-list for the specified
multicast address, if it is non-empty. multicast address, if it is non-empty.
4. CHANGE_TO_EXCLUDE_MODE - indicates that the interface has 4. CHANGE_TO_EXCLUDE_MODE - indicates that the interface has
changed to EXCLUDE filter-mode for the specified multicast changed to EXCLUDE filter-mode for the specified multicast
address. The Source Address [i] fields in this Group Record address. The Source Address [i] fields in this Group Record
contain the interface's new source list for the specified contain the interface's new source-list for the specified
multicast address, if it is non-empty. An SSM-aware host multicast address, if it is non-empty. An SSM-aware host
SHOULD NOT send a CHANGE_TO_EXCLUDE_MODE record type for SHOULD NOT send a CHANGE_TO_EXCLUDE_MODE record type for
multicast addresses that fall within the SSM address range. multicast addresses that fall within the SSM address range.
* A Source-List-Change Record is sent by a system whenever a local * A Source-List-Change Record is sent by a system whenever a local
invocation of IPMulticastListen causes a change of the source list invocation of IPMulticastListen causes a change of the source-list
that is not coincident with a change of the filter-mode, of the that is not coincident with a change of the filter-mode, of the
interface-level state entry for a particular multicast address. interface-level state entry for a particular multicast address.
The Record is included in a Report sent from the interface on The Record is included in a Report sent from the interface on
which the change occurred. The Record Type of a Source-List- which the change occurred. The Record Type of a Source-List-
Change Record may be one of the following two values: Change Record may be one of the following two values:
5. ALLOW_NEW_SOURCES - indicates that the Source Address [i] 5. ALLOW_NEW_SOURCES - indicates that the Source Address [i]
fields in this Group Record contain a list of the additional fields in this Group Record contain a list of the additional
sources that the system wishes to receive, for packets sent to sources that the system wishes to receive, for packets sent to
the specified multicast address. If the change was to an the specified multicast address. If the change was to an
INCLUDE source list, these are the addresses that were added INCLUDE source-list, these are the addresses that were added
to the list; if the change was to an EXCLUDE source list, to the list; if the change was to an EXCLUDE source-list,
these are the addresses that were deleted from the list. these are the addresses that were deleted from the list.
6. BLOCK_OLD_SOURCES - indicates that the Source Address [i] 6. BLOCK_OLD_SOURCES - indicates that the Source Address [i]
fields in this Group Record contain a list of the sources that fields in this Group Record contain a list of the sources that
the system no longer wishes to receive, for packets sent to the system no longer wishes to receive, for packets sent to
the specified multicast address. If the change was to an the specified multicast address. If the change was to an
INCLUDE source list, these are the addresses that were deleted INCLUDE source-list, these are the addresses that were deleted
from the list; if the change was to an EXCLUDE source list, from the list; if the change was to an EXCLUDE source-list,
these are the addresses that were added to the list. these are the addresses that were added to the list.
If a change of source list results in both allowing new sources and 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 blocking old sources, then two Group Records are sent for the same
multicast address, one of type ALLOW_NEW_SOURCES and one of type multicast address, one of type ALLOW_NEW_SOURCES and one of type
BLOCK_OLD_SOURCES. BLOCK_OLD_SOURCES.
We use the term "State-Change Record" to refer to either a Filter- We use the term "State-Change Record" to refer to either a Filter-
Mode-Change Record or a Source-List-Change Record. Mode-Change Record or a Source-List-Change Record.
Unrecognized Record Type values MUST be silently ignored. Unrecognized Record Type values MUST be silently ignored.
4.2.14. IP Source Addresses for Reports 4.2.14. IP Source Addresses for Reports
skipping to change at line 1009 skipping to change at line 1009
5.1. Action on Change of Interface State 5.1. Action on Change of Interface State
An invocation of IPMulticastListen may cause the multicast reception An invocation of IPMulticastListen may cause the multicast reception
state of an interface to change, according to the rules in state of an interface to change, according to the rules in
Section 3.2. Each such change affects the per-interface entry for a Section 3.2. Each such change affects the per-interface entry for a
single multicast address. single multicast address.
A change of interface state causes the system to immediately transmit A change of interface state causes the system to immediately transmit
a State-Change Report from that interface. The type and contents of a State-Change Report from that interface. The type and contents of
the Group Record(s) in that Report are determined by comparing the the Group Record(s) in that Report are determined by comparing the
filter-mode and source list for the affected multicast address before filter-mode and source-list for the affected multicast address before
and after the change, according to Table 3. If no interface state and after the change, according to Table 3. If no interface state
existed for that multicast address before the change (i.e., the existed for that multicast address before the change (i.e., the
change consisted of creating a new per-interface record), or if no change consisted of creating a new per-interface record), or if no
state exists after the change (i.e., the change consisted of deleting state exists after the change (i.e., the change consisted of deleting
a per-interface record), then the "non-existent" state is considered a per-interface record), then the "non-existent" state is considered
to have a filter-mode of INCLUDE and an empty source list. to have a filter-mode of INCLUDE and an empty source-list.
+=============+=============+==========================+ +=============+=============+==========================+
| Old State | New State | State-Change Record Sent | | Old State | New State | State-Change Record Sent |
+=============+=============+==========================+ +=============+=============+==========================+
| INCLUDE (A) | INCLUDE (B) | ALLOW (B-A), BLOCK (A-B) | | INCLUDE (A) | INCLUDE (B) | ALLOW (B-A), BLOCK (A-B) |
+-------------+-------------+--------------------------+ +-------------+-------------+--------------------------+
| EXCLUDE (A) | EXCLUDE (B) | ALLOW (A-B), BLOCK (B-A) | | EXCLUDE (A) | EXCLUDE (B) | ALLOW (A-B), BLOCK (B-A) |
+-------------+-------------+--------------------------+ +-------------+-------------+--------------------------+
| INCLUDE (A) | EXCLUDE (B) | TO_EX (B) | | INCLUDE (A) | EXCLUDE (B) | TO_EX (B) |
+-------------+-------------+--------------------------+ +-------------+-------------+--------------------------+
| EXCLUDE (A) | INCLUDE (B) | TO_IN (B) | | EXCLUDE (A) | INCLUDE (B) | TO_IN (B) |
+-------------+-------------+--------------------------+ +-------------+-------------+--------------------------+
Table 3: Transmitted Group Records for State Changes Table 3: Transmitted Group Records for State Changes
If the computed source list for either an ALLOW or a BLOCK State- If the computed source-list for either an ALLOW or a BLOCK State-
Change Record is empty, that record is omitted from the Report Change Record is empty, that record is omitted from the Report
message. message.
To cover the possibility of the State-Change Report being missed by To cover the possibility of the State-Change Report being missed by
one or more multicast routers, it is retransmitted [Robustness one or more multicast routers, it is retransmitted [Robustness
Variable] - 1 more times, at intervals chosen at random from the Variable] - 1 more times, at intervals chosen at random from the
range (0, [Unsolicited Report Interval]). range (0, [Unsolicited Report Interval]).
If more changes to the same interface state entry occur before all If more changes to the same interface state entry occur before all
the retransmissions of the State-Change Report for the first change the retransmissions of the State-Change Report for the first change
skipping to change at line 1104 skipping to change at line 1104
+--------+------------------------------+ +--------+------------------------------+
| ALLOW | All with retransmission | | ALLOW | All with retransmission |
| | state that must be forwarded | | | state that must be forwarded |
+--------+------------------------------+ +--------+------------------------------+
| BLOCK | All with retransmission | | BLOCK | All with retransmission |
| | state that must be blocked | | | state that must be blocked |
+--------+------------------------------+ +--------+------------------------------+
Table 4: Change Record Construction Table 4: Change Record Construction
If the computed source list for either an ALLOW or a BLOCK record is If the computed source-list for either an ALLOW or a BLOCK record is
empty, that record is omitted from the State-Change Report. empty, that record is omitted from the State-Change Report.
| Note: When the first State-Change Report is sent, the non- | Note: When the first State-Change Report is sent, the non-
| existent pending report to merge with can be treated as a | existent pending report to merge with can be treated as a
| Source-Change Report with empty ALLOW and BLOCK records (no | Source-Change Report with empty ALLOW and BLOCK records (no
| sources have retransmission state). | sources have retransmission state).
5.2. Action on Reception of a Query 5.2. Action on Reception of a Query
When a system receives a Query, it does not respond immediately. When a system receives a Query, it does not respond immediately.
skipping to change at line 1169 skipping to change at line 1169
4. If there already is a pending response to a previous Query 4. If there already is a pending response to a previous Query
scheduled for this group, and either the new Query is a Group scheduled for this group, and either the new Query is a Group
Specific Query or the recorded source-list associated with the Specific Query or the recorded source-list associated with the
group is empty, then the group source-list is cleared and a group is empty, then the group source-list is cleared and a
single response is scheduled using the Group Timer. The new single response is scheduled using the Group Timer. The new
response is scheduled to be sent at the earliest of the remaining response is scheduled to be sent at the earliest of the remaining
time for the pending report and the selected delay. time for the pending report and the selected delay.
5. If the received Query is a Group-and-Source Specific Query and 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 there is a pending response for this group with a non-empty
source-list, then the group source list is augmented to contain source-list, then the group source-list is augmented to contain
the list of sources in the new Query and a single response is the list of sources in the new Query and a single response is
scheduled using the Group Timer. The new response is scheduled scheduled using the Group Timer. The new response is scheduled
to be sent at the earliest of the remaining time for the pending to be sent at the earliest of the remaining time for the pending
report and the selected delay. report and the selected delay.
When the timer in a pending response record expires, the system When the timer in a pending response record expires, the system
transmits, on the associated interface, one or more Report messages transmits, on the associated interface, one or more Report messages
carrying one or more Current-State Records (see Section 4.2.13), as carrying one or more Current-State Records (see Section 4.2.13), as
follows: follows:
1. If the expired timer is the Interface Timer (i.e., it is a 1. If the expired timer is the Interface Timer (i.e., it is a
pending response to a General Query), then one Current-State pending response to a General Query), then one Current-State
Record is sent for each multicast address for which the specified Record is sent for each multicast address for which the specified
interface has reception state, as described in Section 3.2. The interface has reception state, as described in Section 3.2. The
Current-State Record carries the multicast address and its Current-State Record carries the multicast address and its
associated filter-mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and associated filter-mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and
source list. Multiple Current-State Records are packed into source-list. Multiple Current-State Records are packed into
individual Report messages, to the extent possible. individual Report messages, to the extent possible.
This naive algorithm may result in bursts of packets when a This naive algorithm may result in bursts of packets when a
system is a member of a large number of groups. Instead of using system is a member of a large number of groups. Instead of using
a single Interface Timer, implementations are recommended to a single Interface Timer, implementations are recommended to
spread transmission of such Report messages over the interval (0, spread transmission of such Report messages over the interval (0,
[Max Response Time]). Note that any such implementation MUST [Max Response Time]). Note that any such implementation MUST
avoid the "ack-implosion" problem, i.e., MUST NOT send a Report avoid the "ack-implosion" problem, i.e., MUST NOT send a Report
immediately on reception of a General Query. immediately on reception of a General Query.
2. If the expired timer is a Group Timer and the list of recorded 2. If the expired timer is a Group Timer and the list of recorded
sources for that group is empty (i.e., it is a pending response sources for that group is empty (i.e., it is a pending response
to a Group Specific Query), then if and only if the interface has to a Group Specific Query), then if and only if the interface has
reception state for that group address, a single Current-State reception state for that group address, a single Current-State
Record is sent for that address. The Current-State Record Record is sent for that address. The Current-State Record
carries the multicast address and its associated filter-mode carries the multicast address and its associated filter-mode
(MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and source list. (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and source-list.
3. If the expired timer is a Group Timer and the list of recorded 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 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 response to a Group-and-Source Specific Query), then if and only
if the interface has reception state for that group address, the if the interface has reception state for that group address, the
contents of the responding Current-State Record is determined contents of the responding Current-State Record is determined
from the interface state and the pending response record, as from the interface state and the pending response record, as
specified in Table 5. specified in Table 5.
+=====================+=========================+===============+ +=====================+=========================+===============+
skipping to change at line 1228 skipping to change at line 1228
+---------------------+-------------------------+---------------+ +---------------------+-------------------------+---------------+
| EXCLUDE (A) | B | IS_IN (B-A) | | EXCLUDE (A) | B | IS_IN (B-A) |
+---------------------+-------------------------+---------------+ +---------------------+-------------------------+---------------+
Table 5: Current-State Record Construction Table 5: Current-State Record Construction
If the resulting Current-State Record has an empty set of source If the resulting Current-State Record has an empty set of source
addresses, then no response is sent. addresses, then no response is sent.
Finally, after any required Report messages have been generated, the Finally, after any required Report messages have been generated, the
source lists associated with any reported groups are cleared. source-lists associated with any reported groups are cleared.
6. Description of the Protocol for Multicast Routers 6. Description of the Protocol for Multicast Routers
The purpose of IGMP is to enable each multicast router to learn, for The purpose of IGMP is to enable each multicast router to learn, for
each of its directly attached networks, which multicast addresses are each of its directly attached networks, which multicast addresses are
of interest to the systems attached to those networks. IGMPv3 adds of interest to the systems attached to those networks. IGMPv3 adds
the capability for a multicast router to also learn which sources are the capability for a multicast router to also learn which sources are
of interest to neighboring systems, for packets sent to any of interest to neighboring systems, for packets sent to any
particular multicast address. The information gathered by IGMP is particular multicast address. The information gathered by IGMP is
provided to whichever multicast routing protocol is being used by the provided to whichever multicast routing protocol is being used by the
skipping to change at line 1281 skipping to change at line 1281
used to build and refresh the group membership state of systems on used to build and refresh the group membership state of systems on
attached networks. Systems respond to these Queries by reporting attached networks. Systems respond to these Queries by reporting
their group membership state (and their desired set of sources) with their group membership state (and their desired set of sources) with
Current-State Records in IGMPv3 Membership Reports. Current-State Records in IGMPv3 Membership Reports.
As a member of a multicast group, a system may express interest in As a member of a multicast group, a system may express interest in
receiving or not receiving traffic from particular sources. As the receiving or not receiving traffic from particular sources. As the
desired reception state of a system changes, it reports these changes desired reception state of a system changes, it reports these changes
using Filter-Mode-Change Records or Source-List-Change Records. using Filter-Mode-Change Records or Source-List-Change Records.
These records indicate an explicit state change in a group at a 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. 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 When a group membership is terminated at a system or traffic from a
particular source is no longer desired, a multicast router must query particular source is no longer desired, a multicast router must query
for other members of the group or listeners of the source before for other members of the group or listeners of the source before
deleting the group (or source) and pruning its traffic. deleting the group (or source) and pruning its traffic.
To enable all systems on a network to respond to changes in group To enable all systems on a network to respond to changes in group
membership, multicast routers send specific queries. A Group membership, multicast routers send specific queries. A Group
Specific Query is sent to verify there are no systems that desire Specific Query is sent to verify there are no systems that desire
reception of the specified group or to "rebuild" the desired reception of the specified group or to "rebuild" the desired
reception state for a particular group. Group Specific Queries are reception state for a particular group. Group Specific Queries are
skipping to change at line 2215 skipping to change at line 2215
forger. If the forger then sends no more Query Messages, other forger. If the forger then sends no more Query Messages, other
routers' Other-Querier-Present Timer will time out and one will routers' Other-Querier-Present Timer will time out and one will
resume the role of Querier. During this time, if the forger ignores resume the role of Querier. During this time, if the forger ignores
Leave messages, traffic might flow to groups with no members for up Leave messages, traffic might flow to groups with no members for up
to [Group Membership Interval]. to [Group Membership Interval].
A Denial-of-Service (DoS) attack on a host could be staged through A Denial-of-Service (DoS) attack on a host could be staged through
forged Group-and- Source Specific Queries. The attacker can find out forged Group-and- Source Specific Queries. The attacker can find out
about membership of a specific host with a General Query. After about membership of a specific host with a General Query. After
that, it could send a large number of Group-and-Source Specific that, it could send a large number of Group-and-Source Specific
Queries, each with a large source list and the Maximum Response Time 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 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 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 send the delayed response. This would consume both memory and CPU
cycles in order to augment the recorded sources with the source lists cycles in order to augment the recorded sources with the source-lists
included in the successive Queries. included in the successive Queries.
To protect against such a DoS attack, a host stack implementation To protect against such a DoS attack, a host stack implementation
could restrict the number of Group-and-Source Specific Queries per could restrict the number of Group-and-Source Specific Queries per
group membership within this interval and/or record only a limited group membership within this interval and/or record only a limited
number of sources. number of sources.
Forged Query Messages from the local network can be easily traced. Forged Query Messages from the local network can be easily traced.
There are three measures necessary to defend against externally There are three measures necessary to defend against externally
forged Queries: forged Queries:
skipping to change at line 2466 skipping to change at line 2466
4. In IGMPv3, a single Membership Report now bundles multiple 4. In IGMPv3, a single Membership Report now bundles multiple
multicast Group Records to decrease the number of packets sent. multicast Group Records to decrease the number of packets sent.
In comparison, the previous versions of IGMP required that each In comparison, the previous versions of IGMP required that each
multicast group be reported in a separate message. multicast group be reported in a separate message.
A.3. Switching Router Filter Modes from EXCLUDE to INCLUDE A.3. Switching Router Filter Modes from EXCLUDE to INCLUDE
If hosts exist in both EXCLUDE and INCLUDE modes for a single If hosts exist in both EXCLUDE and INCLUDE modes for a single
multicast group in a network, the router must be in EXCLUDE mode as 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 well (see Section 6.2.1). In EXCLUDE mode, a router forwards traffic
from all sources unless that source exists in the exclusion source from all sources unless that source exists in the exclusion source-
list. If all hosts in EXCLUDE mode cease to exist, it would be list. If all hosts in EXCLUDE mode cease to exist, it would be
desirable for the router to switch back to INCLUDE mode seamlessly desirable for the router to switch back to INCLUDE mode seamlessly
without interrupting the flow of traffic to existing receivers. without interrupting the flow of traffic to existing receivers.
One of the ways to accomplish this is for routers to keep track of 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 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 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 EXCLUDE mode, it implies that there are no hosts in EXCLUDE mode on
the network (otherwise, a Membership Report from that host would have the network (otherwise, a Membership Report from that host would have
refreshed the Group Timer). The router can then switch to INCLUDE refreshed the Group Timer). The router can then switch to INCLUDE
mode seamlessly with the list of sources currently being forwarded in mode seamlessly with the list of sources currently being forwarded in
its source list. its source-list.
Appendix B. Summary of Changes from IGMPv2 Appendix B. Summary of Changes from IGMPv2
While the main additional feature of IGMPv3 is the addition of source While the main additional feature of IGMPv3 is the addition of source
filtering, the following is a summary of other changes from filtering, the following is a summary of other changes from
[RFC2236]. [RFC2236].
* State is maintained as Group + List-of-Sources, not simply Group * State is maintained as Group + List-of-Sources, not simply Group
as in IGMPv2. as in IGMPv2.
 End of changes. 33 change blocks. 
37 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.48.