rfc9776v1.txt | rfc9776.txt | |||
---|---|---|---|---|
skipping to change at line 94 ¶ | skipping to change at line 94 ¶ | |||
4.1.3. Group Address | 4.1.3. Group Address | |||
4.1.4. Flags | 4.1.4. Flags | |||
4.1.5. S Flag (Suppress Router-Side Processing) | 4.1.5. S Flag (Suppress Router-Side Processing) | |||
4.1.6. QRV (Querier's Robustness Variable) | 4.1.6. QRV (Querier's Robustness Variable) | |||
4.1.7. QQIC (Querier's Query Interval Code) | 4.1.7. QQIC (Querier's Query Interval Code) | |||
4.1.8. Number of Sources (N) | 4.1.8. Number of Sources (N) | |||
4.1.9. Source Address [i] | 4.1.9. Source Address [i] | |||
4.1.10. Additional Data | 4.1.10. Additional Data | |||
4.1.11. Query Variants | 4.1.11. Query Variants | |||
4.1.12. IP Destination Addresses for Queries | 4.1.12. IP Destination Addresses for Queries | |||
4.2. Version 3 Membership Report Message | 4.2. IGMPv3 Membership Report Message | |||
4.2.1. Reserved | 4.2.1. Reserved | |||
4.2.2. Checksum | 4.2.2. Checksum | |||
4.2.3. Flags | 4.2.3. Flags | |||
4.2.4. Number of Group Records (M) | 4.2.4. Number of Group Records (M) | |||
4.2.5. Group Record | 4.2.5. Group Record | |||
4.2.6. Record Type | 4.2.6. Record Type | |||
4.2.7. Aux Data Len | 4.2.7. Aux Data Len | |||
4.2.8. Number of Sources (N) | 4.2.8. Number of Sources (N) | |||
4.2.9. Multicast Address | 4.2.9. Multicast Address | |||
4.2.10. Source Address [i] | 4.2.10. Source Address [i] | |||
skipping to change at line 118 ¶ | skipping to change at line 118 ¶ | |||
4.2.14. IP Source Addresses for Reports | 4.2.14. IP Source Addresses for Reports | |||
4.2.15. IP Destination Addresses for Reports | 4.2.15. IP Destination Addresses for Reports | |||
4.2.16. Notation for Group Records | 4.2.16. Notation for Group Records | |||
4.2.17. Membership Report Size | 4.2.17. Membership Report Size | |||
5. Description of the Protocol for Group Members | 5. Description of the Protocol for Group Members | |||
5.1. Action on Change of Interface State | 5.1. Action on Change of Interface State | |||
5.2. Action on Reception of a Query | 5.2. Action on Reception of a Query | |||
6. Description of the Protocol for Multicast Routers | 6. Description of the Protocol for Multicast Routers | |||
6.1. Conditions for IGMP Queries | 6.1. Conditions for IGMP Queries | |||
6.2. IGMP State Maintained by Multicast Routers | 6.2. IGMP State Maintained by Multicast Routers | |||
6.2.1. Definition of Router Filter-Mode | 6.2.1. Definition of Router Filter Mode | |||
6.2.2. Definition of Group Timers | 6.2.2. Definition of Group Timers | |||
6.2.3. Definition of Source Timers | 6.2.3. Definition of Source Timers | |||
6.3. IGMPv3 Source-Specific Forwarding Rules | 6.3. IGMPv3 Source-Specific Forwarding Rules | |||
6.4. Action on Reception of Reports | 6.4. Action on Reception of Reports | |||
6.4.1. Reception of Current-State Records | 6.4.1. Reception of Current-State Records | |||
6.4.2. Reception of Filter-Mode-Change and Source-List-Change | 6.4.2. Reception of Filter-Mode-Change and Source-List-Change | |||
Records | Records | |||
6.5. Switching Router Filter-Modes | 6.5. Switching Router Filter Modes | |||
6.6. Action on Reception of Queries | 6.6. Action on Reception of Queries | |||
6.6.1. Timer Updates | 6.6.1. Timer Updates | |||
6.6.2. Querier Election | 6.6.2. Querier Election | |||
6.6.3. Building and Sending Specific Queries | 6.6.3. Building and Sending Specific Queries | |||
7. Interoperation With Older Versions of IGMP | 7. Interoperation With Older Versions of IGMP | |||
7.1. Query Version Distinctions | 7.1. Query Version Distinctions | |||
7.2. Group Member Behavior | 7.2. Group Member Behavior | |||
7.2.1. In the Presence of Older Version Queriers | 7.2.1. In the Presence of Older Version Queriers | |||
7.2.2. In the Presence of Older Version Group Members | 7.2.2. In the Presence of Older Version Group Members | |||
7.3. Multicast Router Behavior | 7.3. Multicast Router Behavior | |||
skipping to change at line 208 ¶ | skipping to change at line 208 ¶ | |||
network. Version 3 adds support for source filtering, that is, the | network. Version 3 adds support for source filtering, that is, the | |||
ability for a system to report interest in receiving packets only | ability for a system to report interest in receiving packets only | |||
from specific source addresses, as required to support Source- | from specific source addresses, as required to support Source- | |||
Specific Multicast (SSM) [RFC3569], or from all but specific source | Specific Multicast (SSM) [RFC3569], or from all but specific source | |||
addresses, sent to a particular multicast address. Version 3 is | addresses, sent to a particular multicast address. Version 3 is | |||
designed to be interoperable with Versions 1 and 2. | designed to be interoperable with Versions 1 and 2. | |||
This document uses "SSM-aware" to refer to systems that support SSM | This document uses "SSM-aware" to refer to systems that support SSM | |||
as defined in [RFC4607]. | as defined in [RFC4607]. | |||
This document updates [RFC2236] as a proper implementation of Version | This document updates [RFC2236] as a proper implementation of IGMPv3 | |||
3 of IGMP needs to implement Version 2 Report and Leave message | needs to implement IGMPv2 Report and Leave message handling. | |||
handling. | ||||
This document obsoletes [RFC3376] as it provides clarifications and | This document obsoletes [RFC3376] as it provides clarifications and | |||
fixes for errata in [RFC3376]. Detailed updates for those changes | fixes for errata in [RFC3376]. Detailed updates for those changes | |||
are described in Appendix C. | are described in Appendix C. | |||
1.1. Conventions Used in This Document | 1.1. Conventions Used in This Document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
skipping to change at line 375 ¶ | skipping to change at line 374 ¶ | |||
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 | |||
routers. | routers. | |||
Filtering of packets based upon a socket's multicast reception state | Filtering of packets based upon a socket's multicast reception state | |||
is a new feature of this service interface. The previous service | is a feature of this service interface. The previous service | |||
interface [RFC1112] described no filtering based upon multicast join | interface [RFC1112] described no filtering based upon multicast join | |||
state; rather, a join on a socket simply caused the host to join a | state; rather, a join on a socket simply caused the host to join a | |||
group on the given interface, and packets destined for that group | group on the given interface, and packets destined for that group | |||
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, | |||
skipping to change at line 448 ¶ | skipping to change at line 447 ¶ | |||
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 | |||
IGMP messages are encapsulated in IPv4 datagrams, with an IP protocol | IGMP messages are encapsulated in IPv4 datagrams, with an IP protocol | |||
number of 2. Every IGMP message described in this document is sent | number of 2. Every IGMP message described in this document is sent | |||
with an IP Time-to-Live of 1, IP Precedence of Internetwork Control | with an IP Time-to-Live of 1, IP Precedence of Internetwork Control | |||
(e.g., Type of Service 0xc0), and carries an IP Router Alert option | (e.g., Type of Service 0xc0), and carries an IP Router Alert option | |||
[RFC2113] in its IP header. IGMP message types are registered per | [RFC2113] in its IP header. IGMP message types are registered per | |||
[RFC9778]. | [BCP57]. | |||
There are two IGMP message types of concern to the IGMPv3 protocol | There are two IGMP message types of concern to the IGMPv3 protocol | |||
described in this document: | described in this document: | |||
+===================+=============================+ | +===================+==========================+ | |||
| Type Number (hex) | Message Name | | | Type Number (hex) | Message Name | | |||
+===================+=============================+ | +===================+==========================+ | |||
| 0x11 | Membership Query | | | 0x11 | Membership Query | | |||
+-------------------+-----------------------------+ | +-------------------+--------------------------+ | |||
| 0x22 | Version 3 Membership Report | | | 0x22 | IGMPv3 Membership Report | | |||
+-------------------+-----------------------------+ | +-------------------+--------------------------+ | |||
Table 1: New Messages Introduced by IGMPv3 | Table 1: New Messages Introduced by IGMPv3 | |||
An implementation of IGMPv3 MUST also support the following three | An implementation of IGMPv3 MUST also support the following three | |||
message types, for interoperation with previous versions of IGMP (see | message types, for interoperation with previous versions of IGMP (see | |||
Section 7): | Section 7): | |||
+===================+=============================+===========+ | +===================+==========================+===========+ | |||
| Type Number (hex) | Message Name | Reference | | | Type Number (hex) | Message Name | Reference | | |||
+===================+=============================+===========+ | +===================+==========================+===========+ | |||
| 0x12 | Version 1 Membership Report | [RFC1112] | | | 0x12 | IGMPv1 Membership Report | [RFC1112] | | |||
+-------------------+-----------------------------+-----------+ | +-------------------+--------------------------+-----------+ | |||
| 0x16 | Version 2 Membership Report | [RFC2236] | | | 0x16 | IGMPv2 Membership Report | [RFC2236] | | |||
+-------------------+-----------------------------+-----------+ | +-------------------+--------------------------+-----------+ | |||
| 0x17 | Version 2 Leave Group | [RFC2236] | | | 0x17 | IGMPv2 Leave Group | [RFC2236] | | |||
+-------------------+-----------------------------+-----------+ | +-------------------+--------------------------+-----------+ | |||
Table 2: Legacy IGMP Messages | Table 2: Legacy IGMP Messages | |||
Unrecognized message types MUST be silently ignored. Other message | Unrecognized message types MUST be silently ignored. Other message | |||
types may be used by newer versions or extensions of IGMP, by | types may be used by newer versions or extensions of IGMP, by | |||
multicast routing protocols, or for other uses. | multicast routing protocols, or for other uses. | |||
In this document, unless otherwise qualified, the capitalized words | In this document, unless otherwise qualified, the capitalized words | |||
"Query" and "Report" refer to IGMP Membership Queries and IGMP | "Query" and "Report" refer to IGMP Membership Queries and IGMPv3 | |||
Version 3 Membership Reports, respectively. | Membership Reports, respectively. | |||
4.1. Membership Query Message | 4.1. Membership Query Message | |||
Membership Queries are sent by IP multicast routers to query the | Membership Queries are sent by IP multicast routers to query the | |||
multicast reception state of neighboring interfaces. Queries have | multicast reception state of neighboring interfaces. Queries have | |||
the following format: | the following format: | |||
0 1 2 3 | 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 | 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at line 518 ¶ | skipping to change at line 517 ¶ | |||
+- -+ | +- -+ | |||
| Source Address [N] | | | Source Address [N] | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 1: IGMPv3 Query Message | Figure 1: IGMPv3 Query Message | |||
4.1.1. Max Resp Code | 4.1.1. Max Resp Code | |||
The Max Resp Code field specifies the maximum time allowed before | The Max Resp Code field specifies the maximum time allowed before | |||
sending a responding report. The actual time allowed, called the | sending a responding report. The actual time allowed, called the | |||
"Max Resp Time", is represented in units of 1/10 second and is | "Max Response Time", is represented in units of 1/10 second and is | |||
derived from the Max Resp Code as follows: | derived from the Max Resp Code as follows: | |||
* If Max Resp Code < 128, Max Resp Time = Max Resp Code | * If Max Resp Code < 128, Max Response Time = Max Resp Code | |||
* If Max Resp Code >= 128, Max Resp Code represents a floating-point | * If Max Resp Code >= 128, Max Resp Code represents a floating-point | |||
value as follows: | value as follows: | |||
0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
|1| exp | mant | | |1| exp | mant | | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
Max Resp Time = (mant | 0x10) << (exp + 3) | Max Response Time = (mant | 0x10) << (exp + 3) | |||
Figure 2: Max Resp Code Representation | Figure 2: Max Resp Code Representation | |||
Small values of Max Resp Time allow IGMPv3 routers to tune the "leave | Small values of Max Response Time allow IGMPv3 routers to tune the | |||
latency" (the time between the moment the last host leaves a group | "leave latency" (the time between the moment the last host leaves a | |||
and the moment the routing protocol is notified that there are no | group and the moment the routing protocol is notified that there are | |||
more members). Larger values, especially in the exponential range, | no more members). Larger values, especially in the exponential | |||
allow tuning of the burstiness of IGMP traffic on a network. | range, allow tuning of the burstiness of IGMP traffic on a network. | |||
4.1.2. Checksum | 4.1.2. Checksum | |||
The Checksum field is the 16-bit one's complement of the one's | The Checksum field is the 16-bit one's complement of the one's | |||
complement sum of the whole IGMP message (the entire IP payload). | complement sum of the whole IGMP message (the entire IP payload). | |||
For computing the checksum, the Checksum field is set to zero. When | For computing the checksum, the Checksum field is set to zero. When | |||
receiving packets, the checksum MUST be verified before processing a | receiving packets, the checksum MUST be verified before processing a | |||
packet [RFC1071]. | packet [RFC1071]. | |||
4.1.3. Group Address | 4.1.3. Group Address | |||
The Group Address field is set to zero when sending a General Query | The Group Address field is set to zero when sending a General Query | |||
and set to the IP multicast address being queried when sending a | and set to the IP multicast address being queried when sending a | |||
Group-Specific Query or Group-and-Source-Specific Query (see | Group-Specific Query or Group-and-Source Specific Query (see | |||
Section 4.1.9, below). | Section 4.1.11, below). | |||
4.1.4. Flags | 4.1.4. Flags | |||
The Flags field is a bitstring managed by the "IGMP Type Numbers" | The Flags field is a bitstring managed by the "IGMP Type Numbers" | |||
registry defined in [RFC9778]. | registry defined in [BCP57]. | |||
4.1.5. S Flag (Suppress Router-Side Processing) | 4.1.5. S Flag (Suppress Router-Side Processing) | |||
When set to one, the S flag indicates to any receiving multicast | When set to one, the S flag indicates to any receiving multicast | |||
routers that they are to suppress the normal timer updates they | routers that they are to suppress the normal timer updates they | |||
perform upon hearing a Query. It does not, however, suppress the | perform upon receiving a Query. It does not, however, suppress the | |||
querier election or the normal "host-side" processing of a Query that | Querier election or the normal "host-side" processing of a Query that | |||
a router may be required to perform as a consequence of itself being | a router may be required to perform as a consequence of itself being | |||
a group member. | a group member. | |||
4.1.6. QRV (Querier's Robustness Variable) | 4.1.6. QRV (Querier's Robustness Variable) | |||
If non-zero, the QRV field contains the [Robustness Variable] value | If non-zero, the QRV field contains the [Robustness Variable] value | |||
used by the querier, i.e., the sender of the Query. If the querier's | used by the querier, i.e., the sender of the Query. If the querier's | |||
[Robustness Variable] exceeds 7, the maximum value of the QRV field, | [Robustness Variable] exceeds 7, the maximum value of the QRV field, | |||
the QRV is set to zero. Routers adopt the QRV value from the most | the QRV is set to zero. Routers adopt the QRV value from the most | |||
recently received Query as their own [Robustness Variable] value, | recently received Query as their own [Robustness Variable] value, | |||
skipping to change at line 611 ¶ | skipping to change at line 610 ¶ | |||
Multicast routers that are not the current querier adopt the QQI | Multicast routers that are not the current querier adopt the QQI | |||
value from the most recently received Query as their own [Query | value from the most recently received Query as their own [Query | |||
Interval] value, unless that most recently received QQI was zero, in | Interval] value, unless that most recently received QQI was zero, in | |||
which case the receiving routers use the default [Query Interval] | which case the receiving routers use the default [Query Interval] | |||
value specified in Section 8.2. | value specified in Section 8.2. | |||
4.1.8. Number of Sources (N) | 4.1.8. Number of Sources (N) | |||
The Number of Sources (N) field specifies how many source addresses | The Number of Sources (N) field specifies how many source addresses | |||
are present in the Query. This number is zero in a General Query or | are present in the Query. This number is zero in a General Query or | |||
a Group-Specific Query and non-zero in a Group-and-Source-Specific | a Group Specific Query and non-zero in a Group-and-Source Specific | |||
Query. This number is limited by the MTU of the network over which | Query. This number is limited by the MTU of the network over which | |||
the Query is transmitted. For example, on an Ethernet with an MTU of | the Query is transmitted. For example, on an Ethernet with an MTU of | |||
1500 octets, the IP header including the Router Alert option consumes | 1500 octets, the IP header including the Router Alert option consumes | |||
24 octets, and the IGMP fields up to and including the Number of | 24 octets, and the IGMP fields up to and including the Number of | |||
Sources (N) field consume 12 octets, leaving 1464 octets for source | Sources (N) field consume 12 octets, leaving 1464 octets for source | |||
addresses, which limits the number of source addresses to 366 | addresses, which limits the number of source addresses to 366 | |||
(1464/4). | (1464/4). | |||
4.1.9. Source Address [i] | 4.1.9. Source Address [i] | |||
skipping to change at line 645 ¶ | skipping to change at line 644 ¶ | |||
4.1.11. Query Variants | 4.1.11. Query Variants | |||
There are three variants of the Query message: | There are three variants of the Query message: | |||
1. A General Query is sent by a multicast router to learn the | 1. A General Query is sent by a multicast router to learn the | |||
complete multicast reception state of the neighboring interfaces | complete multicast reception state of the neighboring interfaces | |||
(that is, the interfaces attached to the network on which the | (that is, the interfaces attached to the network on which the | |||
Query is transmitted). In a General Query, both the Group | Query is transmitted). In a General Query, both the Group | |||
Address field and the Number of Sources (N) field are zero. | Address field and the Number of Sources (N) field are zero. | |||
2. A Group-Specific Query is sent by a multicast router to learn the | 2. A Group Specific Query is sent by a multicast router to learn the | |||
reception state, with respect to a single multicast address, of | reception state, with respect to a single multicast address, of | |||
the neighboring interfaces. In a Group-Specific Query, the Group | the neighboring interfaces. In a Group Specific Query, the Group | |||
Address field contains the multicast address of interest, and the | Address field contains the multicast address of interest, and the | |||
Number of Sources (N) field contains zero. | Number of Sources (N) field contains zero. | |||
3. A Group-and-Source-Specific Query is sent by a multicast router | 3. A Group-and-Source Specific Query is sent by a multicast router | |||
to learn if any neighboring interface desires reception of | to learn if any neighboring interface desires reception of | |||
packets sent to a specified multicast address, from any of a | packets sent to a specified multicast address, from any of a | |||
specified list of sources. In a Group-and-Source-Specific Query, | specified list of sources. In a Group-and-Source Specific Query, | |||
the Group Address field contains the multicast address of | the Group Address field contains the multicast address of | |||
interest, and the Source Address [i] fields contain the source | interest, and the Source Address [i] fields contain the source | |||
address(es) of interest. | address(es) of interest. | |||
4.1.12. IP Destination Addresses for Queries | 4.1.12. IP Destination Addresses for Queries | |||
In IGMPv3, General Queries are sent with an IP destination address of | In IGMPv3, General Queries are sent with an IP destination address of | |||
224.0.0.1, the all-systems multicast address. Group-Specific and | 224.0.0.1, the all-systems multicast address. Group Specific and | |||
Group-and-Source-Specific Queries are sent with an IP destination | Group-and-Source Specific Queries are sent with an IP destination | |||
address equal to the multicast address of interest. However, a | address equal to the multicast address of interest. However, a | |||
system MUST accept and process any Query whose IP Destination Address | system MUST accept and process any Query whose IP Destination Address | |||
field contains any of the addresses (unicast or multicast) assigned | field contains any of the addresses (unicast or multicast) assigned | |||
to the interface on which the Query arrives. | to the interface on which the Query arrives. | |||
4.2. Version 3 Membership Report Message | 4.2. IGMPv3 Membership Report Message | |||
Version 3 Membership Reports are sent by IP systems to report (to | IGMPv3 Membership Reports are sent by IP systems to report (to | |||
neighboring routers) the current multicast reception state, or | neighboring routers) the current multicast reception state, or | |||
changes in the multicast reception state, of their interfaces. | changes in the multicast reception state, of their interfaces. | |||
Reports have the following format: | Reports have the following format: | |||
0 1 2 3 | 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 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type = 0x22 | Reserved | Checksum | | | Type = 0x22 | Reserved | Checksum | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Flags | Number of Group Records (M) | | | Flags | Number of Group Records (M) | | |||
skipping to change at line 750 ¶ | skipping to change at line 749 ¶ | |||
The Checksum field is the 16-bit one's complement of the one's | The Checksum field is the 16-bit one's complement of the one's | |||
complement sum of the whole IGMP message (the entire IP payload). | complement sum of the whole IGMP message (the entire IP payload). | |||
For computing the checksum, the Checksum field is set to zero. When | For computing the checksum, the Checksum field is set to zero. When | |||
receiving packets, the checksum MUST be verified before processing a | receiving packets, the checksum MUST be verified before processing a | |||
message. | message. | |||
4.2.3. Flags | 4.2.3. Flags | |||
The Flags field is a bitstring managed by the "IGMP Type Numbers" | The Flags field is a bitstring managed by the "IGMP Type Numbers" | |||
registry defined in [RFC9778]. | registry defined in [BCP57]. | |||
4.2.4. Number of Group Records (M) | 4.2.4. Number of Group Records (M) | |||
The Number of Group Records (M) field specifies how many Group | The Number of Group Records (M) field specifies how many Group | |||
Records are present in this Report. | Records are present in this Report. | |||
4.2.5. Group Record | 4.2.5. Group Record | |||
Each Group Record is a block of fields containing information | Each Group Record is a block of fields containing information | |||
pertaining to the sender's membership in a single multicast group on | pertaining to the sender's membership in a single multicast group on | |||
skipping to change at line 868 ¶ | skipping to change at line 867 ¶ | |||
* 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 hear from, for packets sent | sources that the system wishes to receive, for packets sent to | |||
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 hear from, 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. | |||
skipping to change at line 905 ¶ | skipping to change at line 904 ¶ | |||
the destination subnet. The 0.0.0.0 source address may be used by a | the destination subnet. The 0.0.0.0 source address may be used by a | |||
system that has not yet acquired an IP address. Note that the | system that has not yet acquired an IP address. Note that the | |||
0.0.0.0 source address may simultaneously be used by multiple systems | 0.0.0.0 source address may simultaneously be used by multiple systems | |||
on a LAN. Routers MUST accept a report with a source address of | on a LAN. Routers MUST accept a report with a source address of | |||
0.0.0.0. | 0.0.0.0. | |||
4.2.15. IP Destination Addresses for Reports | 4.2.15. IP Destination Addresses for Reports | |||
Version 3 Reports are sent with an IP destination address of | Version 3 Reports are sent with an IP destination address of | |||
224.0.0.22, to which all IGMPv3-capable multicast routers listen. A | 224.0.0.22, to which all IGMPv3-capable multicast routers listen. A | |||
system that is operating in version 1 or version 2 compatibility | system that is operating in v1 or v2 compatibility modes sends v1 or | |||
modes sends version 1 or version 2 Reports to the multicast group | v2 Reports to the multicast group specified in the Group Address | |||
specified in the Group Address field of the Report. In addition, a | field of the Report. In addition, a system MUST accept and process | |||
system MUST accept and process any version 1 or version 2 Report | any v1 or v2 Report whose IP Destination Address field contains any | |||
whose IP Destination Address field contains any of the addresses | of the addresses (unicast or multicast) assigned to the interface on | |||
(unicast or multicast) assigned to the interface on which the Report | which the Report arrives. | |||
arrives. | ||||
4.2.16. Notation for Group Records | 4.2.16. Notation for Group Records | |||
In the rest of this document, we use the following notation to | In the rest of this document, we use the following notation to | |||
describe the contents of a Group Record pertaining to a particular | describe the contents of a Group Record pertaining to a particular | |||
multicast address: | multicast address: | |||
IS_IN ( x ) - Type MODE_IS_INCLUDE, source addresses x | * IS_IN ( x ) - Type MODE_IS_INCLUDE, source addresses x | |||
IS_EX ( x ) - Type MODE_IS_EXCLUDE, source addresses x | * IS_EX ( x ) - Type MODE_IS_EXCLUDE, source addresses x | |||
TO_IN ( x ) - Type CHANGE_TO_INCLUDE_MODE, source addresses x | * TO_IN ( x ) - Type CHANGE_TO_INCLUDE_MODE, source addresses x | |||
TO_EX ( x ) - Type CHANGE_TO_EXCLUDE_MODE, source addresses x | * TO_EX ( x ) - Type CHANGE_TO_EXCLUDE_MODE, source addresses x | |||
ALLOW ( x ) - Type ALLOW_NEW_SOURCES, source addresses x | * ALLOW ( x ) - Type ALLOW_NEW_SOURCES, source addresses x | |||
BLOCK ( x ) - Type BLOCK_OLD_SOURCES, source addresses x | * BLOCK ( x ) - Type BLOCK_OLD_SOURCES, source addresses x | |||
where x is either: | where x is either: | |||
* a capital letter (e.g., "A") to represent the set of source | * a capital letter (e.g., "A") to represent the set of source | |||
addresses or | addresses or | |||
* a set expression (e.g., "A+B"), where "A+B" means the union of | * a set expression (e.g., "A+B"), where "A+B" means the union of | |||
sets A and B, "A*B" means the intersection of sets A and B, and | sets A and B, "A*B" means the intersection of sets A and B, and | |||
"A-B" means the removal of all elements of set B from set A. | "A-B" means the removal of all elements of set B from set A. | |||
4.2.17. Membership Report Size | 4.2.17. Membership Report Size | |||
If the set of Group Records required in a Report does not fit within | If the set of Group Records required in a report does not fit within | |||
the size limit of a single Report message (as determined by the MTU | the size limit of a single Report message (as determined by the MTU | |||
of the network on which it will be sent), the Group Records are sent | of the network on which it will be sent), the Group Records are sent | |||
in as many Report messages as needed to report the entire set. | in as many Report messages as needed to report the entire set. | |||
If a single Group Record contains so many source addresses that it | If a single Group Record contains so many source addresses that it | |||
does not fit within the size limit of a single Report message, and if | does not fit within the size limit of a single Report message, and if | |||
its Type is not MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, it is | its Type is not MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, it is | |||
split into multiple Group Records, each containing a different subset | split into multiple Group Records, each containing a different subset | |||
of the source addresses and each sent in a separate Report message. | of the source addresses and each sent in a separate Report message. | |||
If its Type is MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, a single | If its Type is MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, a single | |||
skipping to change at line 1031 ¶ | skipping to change at line 1029 ¶ | |||
+=============+=============+==========================+ | +=============+=============+==========================+ | |||
| 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 | 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 | |||
have been completed, each such additional change triggers the | have been completed, each such additional change triggers the | |||
immediate transmission of a new State-Change Report. | immediate transmission of a State-Change Report. | |||
The contents of the new transmitted report are calculated as follows. | The contents of the new transmitted report are calculated as follows. | |||
As was done with the first report, the interface state for the | As was done with the first report, the interface state for the | |||
affected group before and after the latest change is compared. The | affected group before and after the latest change is compared. The | |||
report records expressing the difference are built according to | report records expressing the difference are built according to | |||
Table 3. However, these records are not transmitted in a message but | Table 3. However, these records are not transmitted in a message but | |||
instead are merged with the contents of the pending report to create | instead are merged with the contents of the pending report to create | |||
the new State-Change report. The rules for merging the difference | the new State-Change report. The rules for merging the difference | |||
report resulting from the state change and the pending report are | report resulting from the state change and the pending report are | |||
described below. | described below. | |||
The transmission of the merged State-Change Report terminates | The transmission of the merged State-Change Report terminates | |||
retransmissions of the earlier State-Change Reports for the same | retransmissions of the earlier State-Change Reports for the same | |||
multicast address, and becomes the first of [Robustness Variable] | multicast address, and becomes the first of [Robustness Variable] | |||
transmissions of State-Change Reports. | transmissions of State-Change Reports. | |||
Each time a source is included in the difference report calculated | Each time a source is included in the difference report calculated | |||
above, retransmission state for that source needs to be maintained | above, retransmission state for that source needs to be maintained | |||
until [Robustness Variable] State-Change reports have been sent by | until [Robustness Variable] State-Change Reports have been sent by | |||
the host. This is done in order to ensure that a series of | the host. This is done in order to ensure that a series of | |||
successive state changes do not break the protocol robustness. | successive state changes do not break the protocol robustness. | |||
If the interface reception-state change that triggers the new report | If the interface reception-state change that triggers the new report | |||
is a filter-mode change, then the next [Robustness Variable] State- | is a filter-mode change, then the next [Robustness Variable] State- | |||
Change Reports will include a Filter-Mode-Change Record. This | Change Reports will include a Filter-Mode-Change Record. This | |||
applies even if any number of source-list changes occur in that | applies even if any number of source-list changes occur in that | |||
period. The host has to maintain retransmission state for the group | period. The host has to maintain retransmission state for the group | |||
until the [Robustness Variable] State-Change reports have been sent. | until the [Robustness Variable] State-Change Reports have been sent. | |||
When [Robustness Variable] State-Change reports with Filter-Mode- | When [Robustness Variable] State-Change Reports with Filter-Mode- | |||
Change Records have been transmitted after the last filter-mode | Change Records have been transmitted after the last filter-mode | |||
change, and if source-list changes to the interface reception have | change, and if source-list changes to the interface reception have | |||
scheduled additional reports, then the next State-Change report will | scheduled additional reports, then the next State-Change Report will | |||
include Source-List-Change Records. | include Source-List-Change Records. | |||
Each time a State-Change Report is transmitted, the contents are | Each time a State-Change Report is transmitted, the contents are | |||
determined as follows. If the report should contain a Filter-Mode- | determined as follows. If the report should contain a Filter-Mode- | |||
Change Record, and if the current filter-mode of the interface is | Change Record, and if the current filter-mode of the interface is | |||
INCLUDE, a TO_IN record is included in the report; otherwise, a TO_EX | INCLUDE, a TO_IN record is included in the report; otherwise, a TO_EX | |||
record is included. If instead the report should contain Source- | record is included. If instead the report should contain a Source- | |||
List-Change Records, an ALLOW and a BLOCK record are included. The | List-Change Record, an ALLOW and a BLOCK record are included. The | |||
contents of these records are built according to Table 4. | contents of these records are built according to Table 4. | |||
+========+==============================+ | +========+==============================+ | |||
| Record | Sources Included | | | Record | Sources Included | | |||
+========+==============================+ | +========+==============================+ | |||
| TO_IN | All in the current interface | | | TO_IN | All in the current interface | | |||
| | state that must be forwarded | | | | state that must be forwarded | | |||
+--------+------------------------------+ | +--------+------------------------------+ | |||
| TO_EX | All in the current interface | | | TO_EX | All in the current interface | | |||
| | state that must be blocked | | | | state that must be blocked | | |||
+--------+------------------------------+ | +--------+------------------------------+ | |||
| 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 | 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-existent | | Note: When the first State-Change Report is sent, the non- | |||
pending report to merge with can be treated as a source-change report | | existent pending report to merge with can be treated as a | |||
with empty ALLOW and BLOCK records (no sources have retransmission | | Source-Change Report with empty ALLOW and BLOCK records (no | |||
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. | |||
Instead, it delays its response by a random amount of time, bounded | Instead, it delays its response by a random amount of time, bounded | |||
by the Max Resp Time value derived from the Max Resp Code in the | by the Max Response Time value derived from the Max Resp Code in the | |||
received Query message. A system may receive a variety of Queries on | received Query message. A system may receive a variety of Queries on | |||
different interfaces and of different kinds (e.g., General Queries, | different interfaces and of different kinds (e.g., General Queries, | |||
Group-Specific Queries, and Group-and-Source-Specific Queries), each | Group Specific Queries, and Group-and-Source Specific Queries), each | |||
of which may require its own delayed response. | of which may require its own delayed response. | |||
Before scheduling a response to a Query, the system must first | Before scheduling a response to a Query, the system must first | |||
consider previously scheduled pending responses as, in many cases, it | consider previously scheduled pending responses as, in many cases, it | |||
can schedule a combined response. Therefore, the system must be able | can schedule a combined response. Therefore, the system must be able | |||
to maintain the following state: | to maintain the following state: | |||
* A timer per interface for scheduling responses to General Queries. | * A timer per interface for scheduling responses to General Queries. | |||
* A per-group and interface timer for scheduling responses to Group- | * A per-group and Interface Timer for scheduling responses to Group | |||
Specific and Group-and-Source-Specific Queries. | Specific and Group-and-Source Specific Queries. | |||
* A per-group and interface list of sources to be reported in the | * A per-group and interface list of sources to be reported in the | |||
response to a Group-and-Source-Specific Query. | response to a Group-and-Source Specific Query. | |||
When a new Query with the Router Alert option arrives on an | When a Query with the Router Alert option arrives on an interface, | |||
interface, provided the system has state to report, a delay for a | provided the system has state to report, a delay for a response is | |||
response is randomly selected in the range (0, [Max Resp Time]) where | randomly selected in the range (0, [Max Response Time]) where Max | |||
Max Resp Time is derived from Max Resp Code in the received Query | Response Time is derived from Max Resp Code in the received Query | |||
message. The following rules are then used to determine if a Report | message. The following rules are then used to determine if a Report | |||
needs to be scheduled and the type of Report to schedule. The rules | needs to be scheduled and the type of Report to schedule. The rules | |||
are considered in order and only the first matching rule is applied. | are considered in order and only the first matching rule is applied. | |||
1. If there is a pending response to a previous General Query | 1. If there is a pending response to a previous General Query | |||
scheduled sooner than the selected delay, no additional response | scheduled sooner than the selected delay, no additional response | |||
needs to be scheduled. | needs to be scheduled. | |||
2. If the received Query is a General Query, the interface timer is | 2. If the received Query is a General Query, the Interface Timer is | |||
used to schedule a response to the General Query after the | used to schedule a response to the General Query after the | |||
selected delay. Any previously pending response to a General | selected delay. Any previously pending response to a General | |||
Query is canceled. | Query is canceled. | |||
3. If the received Query is a Group-Specific Query or a Group-and- | 3. If the received Query is a Group Specific Query or a Group-and- | |||
Source-Specific Query and there is no pending response to a | Source Specific Query and there is no pending response to a | |||
previous Query for this group, then the group timer is used to | previous Query for this group, then the Group Timer is used to | |||
schedule a report. If the received Query is a Group-and-Source- | schedule a report. If the received Query is a Group-and-Source | |||
Specific Query, the list of queried sources is recorded to be | Specific Query, the list of queried sources is recorded to be | |||
used when generating a response. | used when generating a response. | |||
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 Resp Time]). Note that any such implementation MUST avoid | [Max Response Time]). Note that any such implementation MUST | |||
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. | |||
+=====================+=========================+===============+ | +=====================+=========================+===============+ | |||
| Per-Interface State | Set of Sources in the | Current-State | | | Per-Interface State | Set of Sources in the | Current-State | | |||
| | Pending Response Record | Record | | | | Pending Response Record | Record | | |||
+=====================+=========================+===============+ | +=====================+=========================+===============+ | |||
| INCLUDE (A) | B | IS_IN (A*B) | | | INCLUDE (A) | B | IS_IN (A*B) | | |||
+---------------------+-------------------------+---------------+ | +---------------------+-------------------------+---------------+ | |||
| EXCLUDE (A) | B | IS_IN (B-A) | | | EXCLUDE (A) | B | IS_IN (B-A) | | |||
+---------------------+-------------------------+---------------+ | +---------------------+-------------------------+---------------+ | |||
Table 5 | 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. IGMP version | of interest to the systems attached to those networks. IGMPv3 adds | |||
3 adds the capability for a multicast router to also learn which | the capability for a multicast router to also learn which sources are | |||
sources are of interest to neighboring systems, for packets sent to | of interest to neighboring systems, for packets sent to any | |||
any particular multicast address. The information gathered by IGMP | particular multicast address. The information gathered by IGMP is | |||
is provided to whichever multicast routing protocol is being used by | provided to whichever multicast routing protocol is being used by the | |||
the router, in order to ensure that multicast packets are delivered | router, in order to ensure that multicast packets are delivered to | |||
to all networks where there are interested receivers. | all networks where there are interested receivers. | |||
This section describes the part of IGMPv3 that is performed by | This section describes the part of IGMPv3 that is performed by | |||
multicast routers. Multicast routers may also themselves become | multicast routers. Multicast routers may also themselves become | |||
members of multicast groups, and therefore also perform the group | members of multicast groups, and therefore also perform the group | |||
member part of IGMPv3, as described in Section 5. | member part of IGMPv3, as described in Section 5. | |||
A multicast router performs the protocol described in this section | A multicast router performs the protocol described in this section | |||
over each of its directly attached networks. If a multicast router | over each of its directly attached networks. If a multicast router | |||
has more than one interface to the same network, it only needs to | has more than one interface to the same network, it only needs to | |||
operate this protocol over one of those interfaces. On each | operate this protocol over one of those interfaces. On each | |||
skipping to change at line 1272 ¶ | skipping to change at line 1270 ¶ | |||
(However, see Appendix A.2, item 1 for discussion.) | (However, see Appendix A.2, item 1 for discussion.) | |||
IGMPv3 is backward compatible with previous versions of the IGMP | IGMPv3 is backward compatible with previous versions of the IGMP | |||
protocol. In order to remain backward compatible with older IGMP | protocol. In order to remain backward compatible with older IGMP | |||
systems, IGMPv3 multicast routers MUST also implement versions 1 and | systems, IGMPv3 multicast routers MUST also implement versions 1 and | |||
2 of the protocol (see Section 7). | 2 of the protocol (see Section 7). | |||
6.1. Conditions for IGMP Queries | 6.1. Conditions for IGMP Queries | |||
Multicast routers send General Queries periodically to request group | Multicast routers send General Queries periodically to request group | |||
membership information from an attached network. These queries are | membership information from an attached network. These Queries are | |||
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 Group 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 | |||
sent when a router receives a State-Change record indicating a system | sent when a router receives a State-Change Record indicating a system | |||
is leaving a group. | is leaving a group. | |||
A Group-and-Source Specific Query is used to verify there are no | A Group-and-Source Specific Query is used to verify there are no | |||
systems on a network that desire receiving traffic from a set of | systems on a network that desire receiving traffic from a set of | |||
sources. Group-and-Source Specific Queries list sources for a | sources. Group-and-Source Specific Queries list sources for a | |||
particular group that have been requested to no longer be forwarded. | particular group that have been requested to no longer be forwarded. | |||
This query is sent by a multicast router to learn if any systems | This query is sent by a multicast router to learn if any systems | |||
desire reception of packets to the specified group address from the | desire reception of packets to the specified group address from the | |||
specified source addresses. Group-and-Source Specific Queries are | specified source addresses. Group-and-Source Specific Queries are | |||
only sent in response to State-Change Records and never in response | only sent in response to State-Change Records and never in response | |||
skipping to change at line 1317 ¶ | skipping to change at line 1315 ¶ | |||
6.2. IGMP State Maintained by Multicast Routers | 6.2. IGMP State Maintained by Multicast Routers | |||
Multicast routers implementing IGMPv3 keep state per group per | Multicast routers implementing IGMPv3 keep state per group per | |||
attached network. This group state consists of a filter-mode, a list | attached network. This group state consists of a filter-mode, a list | |||
of sources, and various timers. For each attached network running | of sources, and various timers. For each attached network running | |||
IGMP, a multicast router records the desired reception state for that | IGMP, a multicast router records the desired reception state for that | |||
network. That state conceptually consists of a set of records of the | network. That state conceptually consists of a set of records of the | |||
form: | form: | |||
(multicast address, group timer, filter-mode, (source records)) | (multicast address, Group Timer, Router Filter Mode, (source records)) | |||
Each source record is of the form: | Each source record is of the form: | |||
(source address, source timer) | (source address, Source Timer) | |||
If all sources within a given group are desired, an empty source | If all sources within a given group are desired, an empty source | |||
record list is kept with filter-mode set to EXCLUDE. This means | record list is kept with filter-mode set to EXCLUDE. This means | |||
hosts on this network want all sources for this group to be | hosts on this network want all sources for this group to be | |||
forwarded. This is the IGMPv3 equivalent to an IGMPv1 or IGMPv2 | forwarded. This is the IGMPv3 equivalent to an IGMPv1 or IGMPv2 | |||
group join. | group join. | |||
6.2.1. Definition of Router Filter-Mode | 6.2.1. Definition of Router Filter Mode | |||
To reduce internal state, IGMPv3 routers keep a filter-mode per group | To reduce internal state, IGMPv3 routers keep a filter mode per group | |||
per attached network. This filter-mode is used to condense the total | 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 | desired reception state of a group to a minimum set such that all | |||
systems' memberships are satisfied. This filter-mode may change in | systems' memberships are satisfied. This filter mode may change in | |||
response to the reception of particular types of group records or | response to the reception of particular types of Group Records or | |||
when certain timer conditions occur. In the following sections, we | when certain timer conditions occur. In the following sections, we | |||
use the term "router filter-mode" to refer to the filter-mode of a | 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 | particular group within a router. Section 6.4 describes the changes | |||
of a router filter-mode per group record received. | of a Router Filter Mode per Group Record received. | |||
Conceptually, when a group record is received, the router filter-mode | Conceptually, when a Group Record is received, the Router Filter Mode | |||
for that group is updated to cover all the requested sources using | 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 | 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 | filter-mode of EXCLUDE is received, the Router Filter Mode for that | |||
group will be EXCLUDE. | group will be EXCLUDE. | |||
When a router filter-mode for a group is EXCLUDE, the source record | 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 that | list contains two types of sources. The first type is the set that | |||
represents conflicts in the desired reception state; this set must be | represents conflicts in the desired reception state; this set must be | |||
forwarded by some router on the network. The second type is the set | forwarded by some router on the network. The second type is the set | |||
of sources that hosts have requested to not be forwarded. Appendix A | of sources that hosts have requested to not be forwarded. Appendix A | |||
describes the reasons for keeping two different sets when in EXCLUDE | describes the reasons for keeping two different sets when in EXCLUDE | |||
mode. | mode. | |||
When a router filter-mode for a group is INCLUDE, the source record | 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 | 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 | desired set of sources for that group. Each source in the source | |||
record list must be forwarded by some router on the network. | record list must be forwarded by some router on the network. | |||
Because a reported group record with a filter-mode of EXCLUDE will | Because a reported Group Record with a filter-mode of EXCLUDE will | |||
cause a router to transition its filter-mode for that group to | cause a router to transition its filter-mode for that group to | |||
EXCLUDE, a mechanism for transitioning a router's filter-mode back 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 | INCLUDE must exist. If all systems with a Group Record in EXCLUDE | |||
filter-mode cease reporting, it is desirable for the router filter- | filter-mode cease reporting, it is desirable for the Router Filter | |||
mode for that group to transition back to INCLUDE mode. This | Mode for that group to transition back to INCLUDE mode. This | |||
transition occurs when the group timer expires and is explained in | transition occurs when the Group Timer expires and is explained in | |||
detail in Section 6.5. | detail in Section 6.5. | |||
6.2.2. Definition of Group Timers | 6.2.2. Definition of Group Timers | |||
The group timer is only used when a group is in EXCLUDE mode and it | 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 | 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 | 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. | timer with a lower bound of zero kept per group per attached network. | |||
Group timers are updated according to the types of group records | Group timers are updated according to the types of Group Records | |||
received. | received. | |||
A group timer expiring when a router filter-mode for the group is | 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 means there are no listeners on the attached network in | |||
EXCLUDE mode. At this point, a router will transition to INCLUDE | EXCLUDE mode. At this point, a router will transition to INCLUDE | |||
filter-mode. Section 6.5 describes the actions taken when a group | filter-mode. Section 6.5 describes the actions taken when a Group | |||
timer expires while in EXCLUDE mode. | Timer expires while in EXCLUDE mode. | |||
Table 6 summarizes the role of the group timer. Section 6.4 | Table 6 summarizes the role of the Group Timer. Section 6.4 | |||
describes the details of setting the group timer per type of group | describes the details of setting the Group Timer per type of Group | |||
record received. | Record received. | |||
+=============+=======+=========================================+ | +=============+=======+=========================================+ | |||
| Group | Group | Actions/Comments | | | Group | Group | Actions/Comments | | |||
| Filter-Mode | Timer | | | | Filter-Mode | Timer | | | |||
| | Value | | | | | Value | | | |||
+=============+=======+=========================================+ | +=============+=======+=========================================+ | |||
| INCLUDE | Timer | All members in INCLUDE mode. | | | INCLUDE | Timer | All members in INCLUDE mode. | | |||
| | >= 0 | | | | | >= 0 | | | |||
+-------------+-------+-----------------------------------------+ | +-------------+-------+-----------------------------------------+ | |||
| EXCLUDE | Timer | At least one member in EXCLUDE mode. | | | EXCLUDE | Timer | At least one member in EXCLUDE mode. | | |||
skipping to change at line 1408 ¶ | skipping to change at line 1406 ¶ | |||
+-------------+-------+-----------------------------------------+ | +-------------+-------+-----------------------------------------+ | |||
| EXCLUDE | Timer | No more listeners to group. If all | | | EXCLUDE | Timer | No more listeners to group. If all | | |||
| | == 0 | source timers have expired, then delete | | | | == 0 | source timers have expired, then delete | | |||
| | | Group Record. If there are still | | | | | Group Record. If there are still | | |||
| | | source record timers running, switch to | | | | | source record timers running, switch to | | |||
| | | INCLUDE filter-mode using those source | | | | | INCLUDE filter-mode using those source | | |||
| | | records with running timers as the | | | | | records with running timers as the | | |||
| | | INCLUDE source record state. | | | | | INCLUDE source record state. | | |||
+-------------+-------+-----------------------------------------+ | +-------------+-------+-----------------------------------------+ | |||
Table 6 | Table 6: Group Timer Actions | |||
6.2.3. Definition of Source Timers | 6.2.3. Definition of Source Timers | |||
A source timer is kept per source record and is a decrementing timer | 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 | with a lower bound of zero. Source timers are updated according to | |||
the type and filter-mode of the group record received. Source timers | the type and filter-mode of the Group Record received. Source timers | |||
are always updated (for a particular group) whenever the source is | are always updated (for a particular group) whenever the source is | |||
present in a received record for that group. Section 6.4 describes | present in a received record for that group. Section 6.4 describes | |||
the setting of source timers per type of group records received. | the setting of source timers per type of Group Records received. | |||
A source record with a running timer with a router filter-mode for | 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 | the group of INCLUDE means that there is currently one or more | |||
systems (in INCLUDE filter-mode) that desire to receive that source. | systems (in INCLUDE filter-mode) that desire to receive that source. | |||
If a source timer expires with a router filter-mode for the group of | If a Source Timer expires with a Router Filter Mode for the group of | |||
INCLUDE, the router concludes that traffic from this particular | INCLUDE, the router concludes that traffic from this particular | |||
source is no longer desired on the attached network and deletes the | source is no longer desired on the attached network and deletes the | |||
associated source record. | associated source record. | |||
Source timers are treated differently when a router filter-mode for a | 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 | 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 | 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 | one system desires the source. It should therefore be forwarded by a | |||
router on the network. Appendix A describes the reasons for keeping | router on the network. Appendix A describes the reasons for keeping | |||
state for sources that have been requested to be forwarded while in | state for sources that have been requested to be forwarded while in | |||
EXCLUDE state. | EXCLUDE state. | |||
If a source timer expires with a router filter-mode for the group of | 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 | EXCLUDE, the router informs the routing protocol that there is no | |||
longer a receiver on the network interested in traffic from this | longer a receiver on the network interested in traffic from this | |||
source. | source. | |||
When a router filter-mode for a group is EXCLUDE, source records are | 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 | only deleted when the Group Timer expires. Section 6.3 describes the | |||
actions that should be taken dependent upon the value of a source | actions that should be taken dependent upon the value of a Source | |||
timer. | Timer. | |||
6.3. IGMPv3 Source-Specific Forwarding Rules | 6.3. IGMPv3 Source-Specific Forwarding Rules | |||
When a multicast router receives a datagram from a source destined to | 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 | a particular group, a decision has to be made whether to forward the | |||
datagram onto an attached network or not. The multicast routing | datagram onto an attached network or not. The multicast routing | |||
protocol in use is in charge of this decision and should use the | protocol in use is in charge of this decision and should use the | |||
IGMPv3 information to ensure that all sources/groups desired on a | IGMPv3 information to ensure that all sources/groups desired on a | |||
subnetwork are forwarded to that subnetwork. IGMPv3 information does | subnetwork are forwarded to that subnetwork. IGMPv3 information does | |||
not override multicast routing information; for example, if the | not override multicast routing information; for example, if the | |||
IGMPv3 filter-mode group for G is EXCLUDE, a router may still forward | IGMPv3 filter-mode group for G is EXCLUDE, a router may still forward | |||
packets for excluded sources to a transit subnet. | packets for excluded sources to a transit subnet. | |||
To summarize, Table 7 describes the forwarding suggestions made by | To summarize, Table 7 describes the forwarding suggestions made by | |||
IGMP to the routing protocol for traffic originating from a source | IGMP to the routing protocol for traffic originating from a source | |||
destined to a group. It also summarizes the actions taken upon the | 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 | expiration of a Source Timer based on the Router Filter Mode of the | |||
group. | group. | |||
+=============+==========+=======================================+ | +=============+==========+=======================================+ | |||
| Group | Group | Action | | | Group | Group | Action | | |||
| Filter-Mode | Timer | | | | Filter-Mode | Timer | | | |||
| | Value | | | | | Value | | | |||
+=============+==========+=======================================+ | +=============+==========+=======================================+ | |||
| INCLUDE | TIMER > | Suggest to forward traffic from | | | INCLUDE | TIMER > | Suggest to forward traffic from | | |||
| | 0 | source. | | | | 0 | source. | | |||
+-------------+----------+---------------------------------------+ | +-------------+----------+---------------------------------------+ | |||
| INCLUDE | TIMER == | Suggest to stop forwarding traffic | | | INCLUDE | TIMER == | Suggest to stop forwarding traffic | | |||
| | 0 | from source and remove source record. | | | | 0 | from source and remove source record. | | |||
| | | If there are no more source records | | | | | If there are no more source records | | |||
| | | for the group, delete group record. | | | | | for the group, delete Group Record. | | |||
+-------------+----------+---------------------------------------+ | +-------------+----------+---------------------------------------+ | |||
| INCLUDE | No | Suggest to not forward source. | | | INCLUDE | No | Suggest to not forward source. | | |||
| | Source | | | | | Source | | | |||
| | Elements | | | | | Elements | | | |||
+-------------+----------+---------------------------------------+ | +-------------+----------+---------------------------------------+ | |||
| EXCLUDE | TIMER > | Suggest to forward traffic from | | | EXCLUDE | TIMER > | Suggest to forward traffic from | | |||
| | 0 | source. | | | | 0 | source. | | |||
+-------------+----------+---------------------------------------+ | +-------------+----------+---------------------------------------+ | |||
| EXCLUDE | TIMER == | Suggest to not forward traffic from | | | EXCLUDE | TIMER == | Suggest to not forward traffic from | | |||
| | 0 | source (DO NOT remove record). | | | | 0 | source (DO NOT remove record). | | |||
+-------------+----------+---------------------------------------+ | +-------------+----------+---------------------------------------+ | |||
| EXCLUDE | No | Suggest to forward traffic from | | | EXCLUDE | No | Suggest to forward traffic from | | |||
| | Source | source. | | | | Source | source. | | |||
| | Elements | | | | | Elements | | | |||
+-------------+----------+---------------------------------------+ | +-------------+----------+---------------------------------------+ | |||
Table 7 | Table 7: IGMP Forwarding Recommendations | |||
6.4. Action on Reception of Reports | 6.4. Action on Reception of Reports | |||
SSM-aware routers SHOULD ignore records that contain multicast | SSM-aware routers SHOULD ignore records that contain multicast | |||
addresses in the SSM address range if the record type is | addresses in the SSM address range if the record type is | |||
MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE. SSM-aware routers SHOULD | MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE. SSM-aware routers SHOULD | |||
ignore IGMPv1/IGMPv2 Report and IGMPv2 DONE messages that contain | ignore IGMPv1/IGMPv2 Report and IGMPv2 DONE messages that contain | |||
multicast addresses in the SSM address range, SHOULD NOT use such | multicast addresses in the SSM address range, SHOULD NOT use such | |||
Reports to establish IP forwarding state, and MAY log an error if it | Reports to establish IP forwarding state, and MAY log an error if it | |||
receives such a message. | receives such a message. | |||
6.4.1. Reception of Current-State Records | 6.4.1. Reception of Current-State Records | |||
When receiving Current-State Records, a router updates both its group | When receiving Current-State Records, a router updates both its group | |||
and source timers. In some circumstances, the reception of a type of | and source timers. In some circumstances, the reception of a type of | |||
group record will cause the router filter-mode for that group to | Group Record will cause the Router Filter Mode for that group to | |||
change. Table 8 describes the actions, with respect to state and | change. Table 8 describes the actions, with respect to state and | |||
timers that occur to a router's state upon reception of Current- | timers that occur to a router's state upon reception of Current- | |||
State Records. | State Records. | |||
The following notation is used to describe the updating of source | The following notation is used to describe the updating of source | |||
timers. The notation ( A, B ) will be used to represent the total | timers. The notation ( A, B ) will be used to represent the total | |||
number of sources for a particular group, where | number of sources for a particular group, where | |||
A = set of source records whose source timers > 0 (Sources that at | * A = set of source records whose source timers > 0 (Sources that at | |||
least one host has requested to be forwarded) | 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) | * 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 | 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 | 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 | INCLUDE, a single set is used to describe the set of sources | |||
requested to be forwarded (e.g., simply (A)). | requested to be forwarded (e.g., simply (A)). | |||
In Tables 8 and 9, abbreviations are used for several variables (all | In Tables 8 and 9, abbreviations are used for several variables (all | |||
of which are described in detail in Section 8). The variable GMI is | of which are described in detail in Section 8). The variable GMI is | |||
an abbreviation for the Group Membership Interval, which is the time | an abbreviation for the Group Membership Interval, which is the time | |||
in which group memberships will time out. The variable LMQT is an | in which group memberships will time out. The variable LMQT is an | |||
abbreviation for the Last Member Query Time, which is the total time | abbreviation for the Last Member Query Time, which is the total time | |||
spent after Last Member Query Count retransmissions. LMQT represents | spent after [Last Member Query Count] retransmissions. LMQT | |||
the "leave latency" or the difference between the transmission of a | represents the leave latency or the difference between the | |||
membership change and the change in the information given to the | transmission of a membership change and the change in the information | |||
routing protocol. | given to the routing protocol. | |||
Within the "Actions" section of the router state tables, we use the | 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 | 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 | 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 | 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. | that the Group Timer for the group should be set to value J. | |||
+=========+========+===========+=================+ | +=========+========+===========+=================+ | |||
| Router | Report | New | Actions | | | Router | Report | New | Actions | | |||
| State | Rec'd | Router | | | | State | Rec'd | Router | | | |||
skipping to change at line 1563 ¶ | skipping to change at line 1562 ¶ | |||
+---------+--------+-----------+-----------------+ | +---------+--------+-----------+-----------------+ | |||
| EXCLUDE | IS_IN | EXCLUDE | (A)=GMI | | | EXCLUDE | IS_IN | EXCLUDE | (A)=GMI | | |||
| (X,Y) | (A) | (X+A,Y-A) | | | | (X,Y) | (A) | (X+A,Y-A) | | | |||
+---------+--------+-----------+-----------------+ | +---------+--------+-----------+-----------------+ | |||
| EXCLUDE | IS_EX | EXCLUDE | (A-X-Y)=GMI | | | EXCLUDE | IS_EX | EXCLUDE | (A-X-Y)=GMI | | |||
| (X,Y) | (A) | (A-Y,Y*A) | Delete (X-A) | | | (X,Y) | (A) | (A-Y,Y*A) | Delete (X-A) | | |||
| | | | Delete (Y-A) | | | | | | Delete (Y-A) | | |||
| | | | Group Timer=GMI | | | | | | Group Timer=GMI | | |||
+---------+--------+-----------+-----------------+ | +---------+--------+-----------+-----------------+ | |||
Table 8 | Table 8: Actions on Current-State Report Reception | |||
6.4.2. Reception of Filter-Mode-Change and Source-List-Change Records | 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 | 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- | system sends either a Source-List-Change Record or a Filter-Mode- | |||
Change Record for that group. As with Current-State Records, routers | Change Record for that group. As with Current-State Records, routers | |||
must act upon these records and possibly change their own state to | must act upon these records and possibly change their own state to | |||
reflect the new desired membership state of the network. | reflect the new desired membership state of the network. | |||
Routers must query sources that are requested to be no longer | Routers must query sources that are requested to be no longer | |||
forwarded to a group. When a router queries or receives a query for | 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 | a specific set of sources, it lowers its source timers for those | |||
sources to a small interval of Last Member Query Time seconds. If | sources to a small interval of [Last Member Query Time] seconds. If | |||
group records are received in response to the queries which express | Group Records are received in response to the queries which express | |||
interest in receiving traffic from the queried sources, the | interest in receiving traffic from the queried sources, the | |||
corresponding timers are updated. | corresponding timers are updated. | |||
Similarly, when a router queries a specific group, it lowers its | Similarly, when a router queries a specific group, it lowers its | |||
group timer for that group to a small interval of Last Member Query | Group Timer for that group to a small interval of [Last Member Query | |||
Time seconds. If any group records expressing EXCLUDE mode interest | Time] seconds. If any Group Records expressing EXCLUDE mode interest | |||
in the group are received within the interval, the group timer for | in the group are received within the interval, the Group Timer for | |||
the group is updated and the suggestion to the routing protocol to | the group is updated and the suggestion to the routing protocol to | |||
forward the group stands without any interruption. | forward the group stands without any interruption. | |||
During a query period (i.e., Last Member Query Time seconds), the | During a query period (i.e., [Last Member Query Time] seconds), the | |||
IGMP component in the router continues to suggest to the routing | IGMP component in the router continues to suggest to the routing | |||
protocol that it forwards traffic from the groups or sources that it | protocol that it forwards traffic from the groups or sources that it | |||
is querying. It is not until after Last Member Query Time seconds | is querying. It is not until after [Last Member Query Time] seconds | |||
without receiving a record expressing interest in the queried group | without receiving a record expressing interest in the queried group | |||
or sources that the router may prune the group or sources from the | or sources that the router may prune the group or sources from the | |||
network. | network. | |||
Table 9 describes the changes in group state and the action(s) taken | Table 9 describes the changes in group state and the action(s) taken | |||
when receiving either Filter-Mode-Change or Source-List-Change | when receiving either Filter-Mode-Change or Source-List-Change | |||
Records. This table also describes the queries that are sent by the | Records. This table also describes the queries that are sent by the | |||
querier when a particular report is received. | querier when a particular report is received. | |||
We use the following notation for describing the queries that are | We use the following notation for describing the queries that are | |||
sent. We use the notation 'Q(G)' to describe a Group-Specific Query | 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 | 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 | 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 | a result of the action (e.g., A*B), then no query is sent as a result | |||
of the operation. | of the operation. | |||
In order to maintain protocol robustness, queries sent by actions in | In order to maintain protocol robustness, queries sent by actions in | |||
Table 9 need to be transmitted [Last Member Query Count] times, once | Table 9 need to be transmitted [Last Member Query Count] times, once | |||
every [Last Member Query Interval]. | every [Last Member Query Interval]. | |||
If while scheduling new queries there are already pending queries to | If while scheduling new queries there are already pending queries to | |||
skipping to change at line 1654 ¶ | skipping to change at line 1653 ¶ | |||
| (X,Y) | (A) | (A-Y,Y*A) | Delete (X-A) | | | (X,Y) | (A) | (A-Y,Y*A) | Delete (X-A) | | |||
| | | | Delete (Y-A) | | | | | | Delete (Y-A) | | |||
| | | | Send Q(G,A-Y) | | | | | | Send Q(G,A-Y) | | |||
| | | | Group Timer=GMI | | | | | | Group Timer=GMI | | |||
+---------+--------+-------------+---------------------+ | +---------+--------+-------------+---------------------+ | |||
| EXCLUDE | TO_IN | EXCLUDE | (A)=GMI | | | EXCLUDE | TO_IN | EXCLUDE | (A)=GMI | | |||
| (X,Y) | (A) | (X+A,Y-A) | Send Q(G,X-A) | | | (X,Y) | (A) | (X+A,Y-A) | Send Q(G,X-A) | | |||
| | | | Send Q(G) | | | | | | Send Q(G) | | |||
+---------+--------+-------------+---------------------+ | +---------+--------+-------------+---------------------+ | |||
Table 9 | Table 9: Actions on Change Record Reception | |||
6.5. Switching Router Filter-Modes | 6.5. Switching Router Filter Modes | |||
The group timer is used as a mechanism for transitioning the router | The Group Timer is used as a mechanism for transitioning the Router | |||
filter-mode from EXCLUDE to INCLUDE. | Filter Mode from EXCLUDE to INCLUDE. | |||
When a group timer expires with a router filter-mode of EXCLUDE, a | 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 | router assumes that there are no systems with a filter-mode of | |||
EXCLUDE present on the attached network. When a router's filter-mode | EXCLUDE present on the attached network. When a router's filter-mode | |||
for a group is EXCLUDE and the group timer expires, the router | for a group is EXCLUDE and the Group Timer expires, the Router Filter | |||
filter-mode for the group transitions to INCLUDE. | Mode for the group transitions to INCLUDE. | |||
A router uses source records with running source timers as its state | 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 | 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 | records with source timers greater than zero (i.e., requested to be | |||
forwarded), a router switches to filter-mode of INCLUDE using those | forwarded), a router switches to filter-mode of INCLUDE using those | |||
source records. Source records whose timers are zero (from the | source records. Source records whose timers are zero (from the | |||
previous EXCLUDE mode) are deleted. | previous EXCLUDE mode) are deleted. | |||
For example, if a router's state for a group is EXCLUDE(X,Y) and the | 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- | Group Timer expires for that group, the router switches to filter- | |||
mode of INCLUDE with state INCLUDE(X). | mode of INCLUDE with state INCLUDE(X). | |||
6.6. Action on Reception of Queries | 6.6. Action on Reception of Queries | |||
6.6.1. Timer Updates | 6.6.1. Timer Updates | |||
When a router sends or receives a query with a clear Suppress Router- | When a router sends or receives a query with a clear Suppress Router- | |||
Side Processing flag, it must update its timers to reflect the | Side Processing flag, it must update its timers to reflect the | |||
correct timeout values for the group or sources being queried. | correct timeout values for the group or sources being queried. | |||
Table 10 describes the timer actions when sending or receiving a | Table 10 describes the timer actions when sending or receiving a | |||
Group-Specific or Group-and-Source Specific Query with the S flag not | Group Specific or Group-and-Source Specific Query with the S flag not | |||
set. | set. | |||
+========+===================================================+ | +========+===================================================+ | |||
| Query | Action | | | Query | Action | | |||
+========+===================================================+ | +========+===================================================+ | |||
| Q(G,A) | Source Timer for sources in A are lowered to LMQT | | | Q(G,A) | Source Timer for sources in A are lowered to LMQT | | |||
+--------+---------------------------------------------------+ | +--------+---------------------------------------------------+ | |||
| Q(G) | Group Timer is lowered to LMQT | | | Q(G) | Group Timer is lowered to LMQT | | |||
+--------+---------------------------------------------------+ | +--------+---------------------------------------------------+ | |||
Table 10 | Table 10: Timer Updates on Query | |||
When a router sends or receives a query with the S flag set, it will | When a router sends or receives a query with the S flag set, it will | |||
not update its timers. | not update its timers. | |||
6.6.2. Querier Election | 6.6.2. Querier Election | |||
IGMPv3 elects a single querier per subnet using the same querier | IGMPv3 elects a single querier per subnet using the same Querier | |||
election mechanism as IGMPv2, namely by IP address. When a router | election mechanism as IGMPv2, namely by IP address. When a router | |||
receives a general query with a lower IP address, it sets the Other | receives a General Query with a lower IP address, it sets the Other- | |||
Querier Present timer to Other Querier Present Interval and ceases to | Querier-Present Timer to [Other Querier Present Interval] and ceases | |||
send general queries on the network if it was the previously elected | to send general queries on the network if it was the previously | |||
querier. After its Other-Querier Present timer expires, it should | elected querier. After its Other-Querier-Present Timer expires, it | |||
begin sending General Queries. | should begin sending General Queries. | |||
If a router receives an older version general query, it MUST use the | If a router receives an older version General Query, it MUST use the | |||
oldest version of IGMP on the network. For a detailed description of | oldest version of IGMP on the network. For a detailed description of | |||
compatibility issues between IGMP versions, see Section 7. | compatibility issues between IGMP versions, see Section 7. | |||
6.6.3. Building and Sending Specific Queries | 6.6.3. Building and Sending Specific Queries | |||
6.6.3.1. Building and Sending Group-Specific Queries | 6.6.3.1. Building and Sending Group Specific Queries | |||
When a table action "Send Q(G)" is encountered, the group timer must | When a table action "Send Q(G)" is encountered, the Group Timer must | |||
be lowered to LMQT. The router must then immediately send a group- | be lowered to LMQT. The router must then immediately send a Group | |||
specific query as well as schedule [Last Member Query Count - 1] | Specific Query as well as schedule [Last Member Query Count] - 1 | |||
query retransmissions to be sent every [Last Member Query Interval] | query retransmissions to be sent every [Last Member Query Interval] | |||
over [Last Member Query Time]. | over [Last Member Query Time]. | |||
When transmitting a group-specific query, if the group timer is | When transmitting a Group Specific Query, if the Group Timer is | |||
larger than LMQT, the "Suppress Router-Side Processing" bit is set in | larger than LMQT, the "Suppress Router-Side Processing" bit is set in | |||
the query message. | the query message. | |||
6.6.3.2. Building and Sending Group-and-Source-Specific Queries | 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 | When a table action "Send Q(G,X)" is encountered by a querier in | |||
Table 9 (Section 6.4.2), the following actions must be performed for | Table 9 (Section 6.4.2), the following actions must be performed for | |||
each of the sources in X of group G, with the source timer larger | each of the sources in X of group G, with the Source Timer larger | |||
than LMQT: | than LMQT: | |||
* Set the number of retransmissions for each source to [Last Member | * Set the number of retransmissions for each source to [Last Member | |||
Query Count]. | Query Count]. | |||
* Lower the source timer to LMQT. | * Lower the Source Timer to LMQT. | |||
The router must then immediately send a group and source specific | The router must then immediately send a Group-and-Source Specific | |||
query as well as schedule [Last Member Query Count - 1] query | Query as well as schedule [Last Member Query Count] - 1 query | |||
retransmissions to be sent every [Last Member Query Interval] over | retransmissions to be sent every [Last Member Query Interval] over | |||
[Last Member Query Time]. The contents of these queries are | [Last Member Query Time]. The contents of these queries are | |||
calculated as follows. | calculated as follows. | |||
When building a group and source specific query for group G, two | When building a Group-and-source Specific Query for group G, two | |||
separate query messages are sent for the group. The first one has | separate query messages are sent for the group. The first one has | |||
the "Suppress Router-Side Processing" bit set and contains all the | the "Suppress Router-Side Processing" bit set and contains all the | |||
sources with retransmission state and timers greater than LMQT. The | sources with retransmission state and timers greater than LMQT. The | |||
second has the "Suppress Router-Side Processing" bit clear and | second has the "Suppress Router-Side Processing" bit clear and | |||
contains all the sources with retransmission state and timers lower | contains all the sources with retransmission state and timers lower | |||
or equal to LMQT. If either of the two calculated messages does not | or equal to LMQT. If either of the two calculated messages does not | |||
contain any sources, then its transmission is suppressed. | contain any sources, then its transmission is suppressed. | |||
Note: If a group-specific query is scheduled to be transmitted at the | | Note: If a Group Specific Query is scheduled to be transmitted | |||
same time as a group and source specific query for the same group, | | at the same time as a Group-and-Source Specific Query for the | |||
then transmission of the group and source specific message with the | | same group, then transmission of the Group-and-Source Specific | |||
"Suppress Router-Side Processing" bit set may be suppressed. | | Query message with the "Suppress Router-Side Processing" bit | |||
| set may be suppressed. | ||||
7. Interoperation With Older Versions of IGMP | 7. Interoperation With Older Versions of IGMP | |||
IGMP version 3 hosts and routers interoperate with hosts and routers | IGMPv3 hosts and routers interoperate with hosts and routers that | |||
that have not yet been upgraded to IGMPv3. This compatibility is | have not yet been upgraded to IGMPv3. This compatibility is | |||
maintained by hosts and routers taking appropriate actions depending | maintained by hosts and routers taking appropriate actions depending | |||
on the versions of IGMP operating on hosts and routers within a | on the versions of IGMP operating on hosts and routers within a | |||
network. | network. | |||
7.1. Query Version Distinctions | 7.1. Query Version Distinctions | |||
The IGMP version of a Membership Query message is determined as | The IGMP version of a Membership Query message is determined as | |||
follows: | follows: | |||
* IGMPv1 Query: length = 8 octets AND Max Resp Code field is zero | * IGMPv1 Query: length = 8 octets AND Max Resp Code field is zero | |||
skipping to change at line 1790 ¶ | skipping to change at line 1790 ¶ | |||
* IGMPv3 Query: length >= 12 octets | * IGMPv3 Query: length >= 12 octets | |||
Query messages that do not match any of the above conditions (e.g., a | Query messages that do not match any of the above conditions (e.g., a | |||
Query of length 10 octets) MUST be silently ignored. | Query of length 10 octets) MUST be silently ignored. | |||
7.2. Group Member Behavior | 7.2. Group Member Behavior | |||
7.2.1. In the Presence of Older Version Queriers | 7.2.1. In the Presence of Older Version Queriers | |||
In order to be compatible with older version routers, IGMPv3 hosts | In order to be compatible with older version routers, IGMPv3 hosts | |||
MUST operate in version 1 and version 2 compatibility modes. IGMPv3 | MUST operate in v1 and v2 compatibility modes. IGMPv3 hosts MUST | |||
hosts MUST keep state per local interface regarding the compatibility | keep state per local interface regarding the compatibility mode of | |||
mode of each attached network. A host's compatibility mode is | each attached network. A host's compatibility mode is determined | |||
determined from the Host Compatibility Mode variable, which can be in | from the Host Compatibility Mode variable, which can be in one of | |||
one of three states: IGMPv1, IGMPv2, or IGMPv3. This variable is | three states: IGMPv1, IGMPv2, or IGMPv3. This variable is kept per | |||
kept per interface and is dependent on the version of General Queries | interface and is dependent on the version of General Queries received | |||
heard on that interface as well as the Older Version Querier Present | on that interface as well as the Older-Version-Querier-Present Timer | |||
timers for the interface. | for the interface. | |||
In order to switch gracefully between versions of IGMP, hosts keep | In order to switch gracefully between versions of IGMP, hosts keep | |||
both an IGMPv1 Querier Present timer and an IGMPv2 Querier Present | both an IGMPv1-Querier-Present Timer and an IGMPv2-Querier-Present | |||
timer per interface. IGMPv1 Querier Present is set to Older Version | Timer per interface. IGMPv1-Querier-Present Timer is set to [Older | |||
Querier Present Timeout seconds whenever an IGMPv1 Membership Query | Version Querier Present Interval] seconds whenever an IGMPv1 | |||
is received. IGMPv2 Querier Present is set to Older Version Querier | Membership Query is received. IGMPv2-Querier-Present Timer is set to | |||
Present Timeout seconds whenever an IGMPv2 General Query is received. | [Older Version Querier Present Interval] seconds whenever an IGMPv2 | |||
General Query is received. | ||||
The Host Compatibility Mode of an interface changes whenever an older | The Host Compatibility Mode of an interface changes whenever an older | |||
version query (than the current compatibility mode) is heard or when | version query (than the current compatibility mode) is received or | |||
certain timer conditions occur. When the IGMPv1 Querier Present | when certain timer conditions occur. When the IGMPv1-Querier-Present | |||
timer expires, a host switches to Host Compatibility Mode of IGMPv2 | Timer expires, a host switches to Host Compatibility Mode of IGMPv2 | |||
if it has a running IGMPv2 Querier Present timer. If it does not | 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 | have a running IGMPv2 Querier Present timer, then it switches to Host | |||
Compatibility of IGMPv3. When the IGMPv2 Querier Present timer | Compatibility of IGMPv3. When the IGMPv2 Querier Present timer | |||
expires, a host switches to Host Compatibility Mode of IGMPv3. | expires, a host switches to Host Compatibility Mode of IGMPv3. | |||
The Host Compatibility Mode variable is based on whether an older | The Host Compatibility Mode variable is based on whether an older | |||
version General query was heard in the last Older Version Querier | version General Query was received in the last [Older Version Querier | |||
Present Timeout seconds. The Host Compatibility Mode variable value | Present Interval] seconds. The Host Compatibility Mode variable | |||
MUST NOT be changed by an older version group-specific query. The | value MUST NOT be changed by an older version Group Specific Query. | |||
Host Compatibility Mode is set depending on the following: | The Host Compatibility Mode is set depending on the following: | |||
+=========================+========================================+ | +=========================+========================================+ | |||
| Host Compatibility Mode | Timer State | | | Host Compatibility Mode | Timer State | | |||
+=========================+========================================+ | +=========================+========================================+ | |||
| IGMPv3 (default) | IGMPv2 Querier Present not running and | | | IGMPv3 (default) | IGMPv2 Querier Present not running and | | |||
| | IGMPv1 Querier Present not running | | | | IGMPv1 Querier Present not running | | |||
+-------------------------+----------------------------------------+ | +-------------------------+----------------------------------------+ | |||
| IGMPv2 | IGMPv2 Querier Present running and | | | IGMPv2 | IGMPv2 Querier Present running and | | |||
| | IGMPv1 Querier Present not running | | | | IGMPv1 Querier Present not running | | |||
+-------------------------+----------------------------------------+ | +-------------------------+----------------------------------------+ | |||
| IGMPv1 | IGMPv1 Querier Present running | | | IGMPv1 | IGMPv1 Querier Present running | | |||
+-------------------------+----------------------------------------+ | +-------------------------+----------------------------------------+ | |||
Table 11 | Table 11: Host Compatibility Mode Settings | |||
If a host receives a query that causes its Querier Present timers to | If a host receives a query that causes its Querier Present timers to | |||
be updated and correspondingly its compatibility mode, it should | be updated and correspondingly its compatibility mode, it should | |||
switch compatibility modes immediately. | switch compatibility modes immediately. | |||
When Host Compatibility Mode is IGMPv3, a host acts using the IGMPv3 | When Host Compatibility Mode is IGMPv3, a host acts using the IGMPv3 | |||
protocol on that interface. When Host Compatibility Mode is IGMPv2, | protocol on that interface. When Host Compatibility Mode is IGMPv2, | |||
a host acts in IGMPv2 compatibility mode, using only the IGMPv2 | a host acts in IGMPv2 compatibility mode, using only the IGMPv2 | |||
protocol, on that interface. When Host Compatibility Mode is IGMPv1, | protocol, on that interface. When Host Compatibility Mode is IGMPv1, | |||
a host acts in IGMPv1 compatibility mode, using only the IGMPv1 | a host acts in IGMPv1 compatibility mode, using only the IGMPv1 | |||
protocol on that interface. | protocol on that interface. | |||
An IGMPv1 router will send General Queries with the Max Resp Code set | 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). | 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 | 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 | to the desired Max Response Time, i.e., the full range of this field | |||
linear and the exponential algorithm described in Section 4.1.1 is | is linear and the exponential algorithm described in Section 4.1.1 is | |||
not used. | not used. | |||
Whenever a host changes its compatibility mode, it cancels all its | Whenever a host changes its compatibility mode, it cancels all its | |||
pending response and retransmission timers. | pending response and retransmission timers. | |||
An SSM-aware host that receives an IGMPv1 Query, an IGMPv2 General | An SSM-aware host that receives an IGMPv1 Query, an IGMPv2 General | |||
Query, or an IGMPv2 Group Specific Query for a multicast address in | Query, or an IGMPv2 Group Specific Query for a multicast address in | |||
the SSM address range SHOULD log an error. It is RECOMMENDED that | the SSM address range SHOULD log an error. It is RECOMMENDED that | |||
implementations provide a configuration option to disable use of the | implementations provide a configuration option to disable use of the | |||
Host Compatibility Mode to allow networks to operate only in SSM | Host Compatibility Mode to allow networks to operate only in SSM | |||
mode. This configuration option SHOULD be disabled by default. | mode. This configuration option SHOULD be disabled by default. | |||
7.2.2. In the Presence of Older Version Group Members | 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 | 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 | have not yet been upgraded to IGMPv3. A host MAY allow its IGMPv3 | |||
Membership Record to be suppressed by either a Version 1 Membership | Membership Record to be suppressed by either an IGMPv1 Membership | |||
Report, or a Version 2 Membership Report. SSM-aware hosts MUST NOT | Report or an IGMPv2 Membership Report. SSM-aware hosts MUST NOT | |||
allow its IGMPv3 Membership Record to be suppressed. | allow its IGMPv3 Membership Record to be suppressed. | |||
7.3. Multicast Router Behavior | 7.3. Multicast Router Behavior | |||
7.3.1. In the Presence of Older Version Queriers | 7.3.1. In the Presence of Older Version Queriers | |||
IGMPv3 routers may be placed on a network where at least one router | 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 | on the network has not yet been upgraded to IGMPv3. The following | |||
requirements apply: | requirements apply: | |||
skipping to change at line 1893 ¶ | skipping to change at line 1894 ¶ | |||
compatible with IGMPv1 and IGMPv2 MUST have a configuration option | compatible with IGMPv1 and IGMPv2 MUST have a configuration option | |||
to act in IGMPv1 or IGMPv2 compatibility modes. When in IGMPv1 | to act in IGMPv1 or IGMPv2 compatibility modes. When in IGMPv1 | |||
mode, routers MUST send Periodic Queries with a Max Resp Code of 0 | 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 | and truncated at the Group Address field (i.e., 8 bytes long) and | |||
MUST ignore Leave Group messages. They SHOULD also warn about | MUST ignore Leave Group messages. They SHOULD also warn about | |||
receiving an IGMPv2 or IGMPv3 query, although such warnings MUST | receiving an IGMPv2 or IGMPv3 query, although such warnings MUST | |||
be rate-limited. When in IGMPv2 mode, routers MUST send Periodic | be rate-limited. When in IGMPv2 mode, routers MUST send Periodic | |||
Queries truncated at the Group Address field (i.e., 8 bytes long) | Queries truncated at the Group Address field (i.e., 8 bytes long) | |||
and SHOULD also warn about receiving an IGMPv3 query (such | and SHOULD also warn about receiving an IGMPv3 query (such | |||
warnings MUST be rate-limited). They also MUST fill in the Max | warnings MUST be rate-limited). They also MUST fill in the Max | |||
Resp Time in the Max Resp Code field, i.e., the exponential | Response Time in the Max Resp Code field, i.e., the exponential | |||
algorithm described in Section 4.1.1 is not used. | algorithm described in Section 4.1.1 is not used. | |||
* If a router is not explicitly configured to use IGMPv1 or IGMPv2 | * 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 | and receives an IGMPv1 Query or IGMPv2 General Query, it SHOULD | |||
warning. These warnings MUST be rate-limited. | log a warning. These warnings MUST be rate-limited. | |||
* It is RECOMMENDED that implementations provide a configuration | * It is RECOMMENDED that implementations provide a configuration | |||
option to disable use of compatibility mode to allow networks to | option to disable use of compatibility mode to allow networks to | |||
operate only in SSM mode. This configuration option SHOULD be | operate only in SSM mode. This configuration option SHOULD be | |||
disabled by default. | disabled by default. | |||
7.3.2. In the Presence of Older Version Group Members | 7.3.2. In the Presence of Older Version Group Members | |||
IGMPv3 routers may be placed on a network where there are hosts that | 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 | have not yet been upgraded to IGMPv3. In order to be compatible with | |||
older version hosts, IGMPv3 routers MUST operate in version 1 and | older version hosts, IGMPv3 routers MUST operate in v1 and v2 | |||
version 2 compatibility modes. IGMPv3 routers keep a compatibility | compatibility modes. IGMPv3 routers keep a compatibility mode per | |||
mode per group record. A group's compatibility mode is determined | Group Record. A group's compatibility mode is determined from the | |||
from the Group Compatibility Mode variable, which can be in one of | Group Compatibility Mode variable, which can be in one of three | |||
three states: IGMPv1, IGMPv2, or IGMPv3. This variable is kept per | states: IGMPv1, IGMPv2, or IGMPv3. This variable is kept per Group | |||
group record and is dependent on the version of Membership Reports | Record and is dependent on the version of Membership Reports received | |||
heard for that group as well as the Older Version Host Present timer | for that group as well as the Older-Version-Host-Present Timer for | |||
for the group. | the group. | |||
In order to switch gracefully between versions of IGMP, routers keep | In order to switch gracefully between versions of IGMP, routers keep | |||
an IGMPv1 Host Present timer and an IGMPv2 Host Present timer per | an IGMPv1-Host-Present Timer and an IGMPv2-Host-Present Timer per | |||
group record. The IGMPv1 Host Present timer is set to Older Version | Group Record. The IGMPv1-Host-Present Timer is set to [Older Version | |||
Host Present Timeout seconds whenever an IGMPv1 Membership Report is | Host Present Interval] seconds whenever an IGMPv1 Membership Report | |||
received. The IGMPv2 Host Present timer is set to Older Version Host | is received. The IGMPv2-Host-Present Timer is set to [Older Version | |||
Present Timeout seconds whenever an IGMPv2 Membership Report is | Host Present Interval] seconds whenever an IGMPv2 Membership Report | |||
received. | is received. | |||
The Group Compatibility Mode of a group record changes whenever an | The Group Compatibility Mode of a Group Record changes whenever an | |||
older version report (than the current compatibility mode) is heard | older version report (than the current compatibility mode) is | |||
or when certain timer conditions occur. When the IGMPv1 Host Present | received or when certain timer conditions occur. When the IGMPv1- | |||
timer expires, a router switches to Group Compatibility Mode of | Host-Present Timer expires, a router switches to Group Compatibility | |||
IGMPv2 if it has a running IGMPv2 Host Present timer. If it does not | Mode of IGMPv2 if it has a running IGMPv2 Host Present timer. If it | |||
have a running IGMPv2 Host Present timer, then it switches to Group | does not have a running IGMPv2 Host Present timer, then it switches | |||
Compatibility Mode of IGMPv3. When the IGMPv2 Host Present timer | to Group Compatibility Mode of IGMPv3. When the IGMPv2-Host-Present | |||
expires and the IGMPv1 Host Present timer is not running, a router | Timer expires and the IGMPv1-Host-Present Timer is not running, a | |||
switches to Group Compatibility Mode of IGMPv3. Note that when a | router switches to Group Compatibility Mode of IGMPv3. Note that | |||
group switches back to IGMPv3 mode, it takes some time to regain | when a group switches back to IGMPv3 mode, it takes some time to | |||
source- specific state information. Source-specific information will | regain source- specific state information. Source-specific | |||
be learned during the next General Query, but sources that should be | information will be learned during the next General Query, but | |||
blocked will not be blocked until [Group Membership Interval] after | sources that should be blocked will not be blocked until [Group | |||
that. | Membership Interval] after that. | |||
The Group Compatibility Mode variable is based on whether an older | The Group Compatibility Mode variable is based on whether an older | |||
version report was heard in the last Older Version Host Present | version report was received in the last [Older Version Host Present | |||
Timeout seconds. The Group Compatibility Mode is set depending on | Interval] seconds. The Group Compatibility Mode is set depending on | |||
the following: | the following: | |||
+==========================+=====================================+ | +==========================+=====================================+ | |||
| Group Compatibility Mode | Timer State | | | Group Compatibility Mode | Timer State | | |||
+==========================+=====================================+ | +==========================+=====================================+ | |||
| IGMPv3 (default) | IGMPv2 Host Present not running and | | | IGMPv3 (default) | IGMPv2 Host Present not running and | | |||
| | IGMPv1 Host Present not running | | | | IGMPv1 Host Present not running | | |||
+--------------------------+-------------------------------------+ | +--------------------------+-------------------------------------+ | |||
| IGMPv2 | IGMPv2 Host Present running and | | | IGMPv2 | IGMPv2 Host Present running and | | |||
| | IGMPv1 Host Present not running | | | | IGMPv1 Host Present not running | | |||
+--------------------------+-------------------------------------+ | +--------------------------+-------------------------------------+ | |||
| IGMPv1 | IGMPv1 Host Present running | | | IGMPv1 | IGMPv1 Host Present running | | |||
+--------------------------+-------------------------------------+ | +--------------------------+-------------------------------------+ | |||
Table 12 | Table 12: Group Compatibility Mode Settings | |||
If a router receives a report that causes its older Host Present | If a router receives a report that causes its older Host Present | |||
timers to be updated and correspondingly its compatibility mode, it | timers to be updated and correspondingly its compatibility mode, it | |||
SHOULD switch compatibility modes immediately. | SHOULD switch compatibility modes immediately. | |||
When Group Compatibility Mode is IGMPv3, a router acts using the | When Group Compatibility Mode is IGMPv3, a router acts using the | |||
IGMPv3 protocol for that group. | IGMPv3 protocol for that group. | |||
When Group Compatibility Mode is IGMPv2, a router internally | When Group Compatibility Mode is IGMPv2, a router internally | |||
translates the following IGMPv2 messages for that group to their | translates the following IGMPv2 messages for that group to their | |||
IGMPv3 equivalents: | IGMPv3 equivalents: | |||
+================+===================+ | +================+===================+ | |||
| IGMPv2 Message | IGMPv3 Equivalent | | | IGMPv2 Message | IGMPv3 Equivalent | | |||
+================+===================+ | +================+===================+ | |||
| Report | IS_EX( {} ) | | | Report | IS_EX( {} ) | | |||
+----------------+-------------------+ | +----------------+-------------------+ | |||
| Leave | TO_IN( {} ) | | | Leave | TO_IN( {} ) | | |||
+----------------+-------------------+ | +----------------+-------------------+ | |||
Table 13 | Table 13: IGMPv2 Compatibility | |||
Mode Message Translation | ||||
IGMPv3 BLOCK messages are ignored, as are source-lists in TO_EX() | IGMPv3 BLOCK messages are ignored, as are source-lists in TO_EX() | |||
messages (i.e., any TO_EX() message is treated as TO_EX( {} )). | messages (i.e., any TO_EX() message is treated as TO_EX( {} )). | |||
When Group Compatibility Mode is IGMPv1, a router internally | When Group Compatibility Mode is IGMPv1, a router internally | |||
translates the following IGMPv1 and IGMPv2 messages for that group to | translates the following IGMPv1 and IGMPv2 messages for that group to | |||
their IGMPv3 equivalents: | their IGMPv3 equivalents: | |||
+================+===================+ | +================+===================+ | |||
| IGMPv2 Message | IGMPv3 Equivalent | | | IGMPv2 Message | IGMPv3 Equivalent | | |||
+================+===================+ | +================+===================+ | |||
| v1 Report | IS_EX( {} ) | | | v1 Report | IS_EX( {} ) | | |||
+----------------+-------------------+ | +----------------+-------------------+ | |||
| v2 Report | IS_EX( {} ) | | | v2 Report | IS_EX( {} ) | | |||
+----------------+-------------------+ | +----------------+-------------------+ | |||
Table 14 | Table 14: IGMPv1 Compatibility | |||
Mode Message Translation | ||||
In addition to ignoring IGMPv3 BLOCK messages and source-lists in | In addition to ignoring IGMPv3 BLOCK messages and source-lists in | |||
TO_EX() messages as in IGMPv2 Group Compatibility Mode, IGMPv2 Leave | TO_EX() messages as in IGMPv2 Group Compatibility Mode, IGMPv2 Leave | |||
messages and IGMPv3 TO_IN() messages are also ignored. | messages and IGMPv3 TO_IN() messages are also ignored. | |||
8. List of Timers, Counters, and Their Default Values | 8. List of Timers, Counters, and Their Default Values | |||
Most of these timers are configurable. If non-default settings are | Most timers and counters are configurable. If non-default settings | |||
used, they MUST be consistent among all systems on a single link. | are used, they MUST be consistent among all systems on a single link. | |||
Note that parentheses are used to group expressions to make the | Note that parentheses are used to group expressions to make the | |||
algebra clear. | algebra clear. | |||
8.1. Robustness Variable | 8.1. Robustness Variable | |||
The Robustness Variable allows tuning for the expected packet loss on | The Robustness Variable allows tuning for the expected packet loss on | |||
a network. If a network is expected to be lossy, the Robustness | a network. If a network is expected to be lossy, the Robustness | |||
Variable may be increased. IGMP is robust to (Robustness Variable - | Variable may be increased. IGMP is robust to (Robustness Variable - | |||
1) packet losses. The Robustness Variable MUST NOT be zero and | 1) packet losses. The Robustness Variable MUST NOT be zero and | |||
SHOULD NOT be one. Default: 2. | SHOULD NOT be one. Default: 2. | |||
8.2. Query Interval | 8.2. Query Interval | |||
The Query Interval is the interval between General Queries sent by | The Query Interval is the interval between General Queries sent by | |||
the Querier. Default: 125 seconds. | the Querier. Default: 125 seconds. | |||
By varying the [Query Interval], an administrator may tune the number | By varying the Query Interval, an administrator may tune the number | |||
of IGMP messages on the network; larger values cause IGMP Queries to | of IGMP messages on the network; larger values cause IGMP Queries to | |||
be sent less often. | be sent less often. | |||
8.3. Query Response Interval | 8.3. Query Response Interval | |||
The Query Response Interval uses the Max Response Time to calculate | The Query Response Interval uses the Max Response Time to calculate | |||
the Max Resp Code that is inserted into the periodic General Queries. | the Max Resp Code that is inserted into the periodic General Queries. | |||
Default: 100 (10 seconds). | Default: 100 (10 seconds). | |||
By varying the [Query Response Interval], an administrator may tune | By varying the [Query Response Interval], an administrator may tune | |||
skipping to change at line 2044 ¶ | skipping to change at line 2047 ¶ | |||
the traffic less bursty, as host responses are spread out over a | the traffic less bursty, as host responses are spread out over a | |||
larger interval. The number of seconds represented by the [Query | larger interval. The number of seconds represented by the [Query | |||
Response Interval] must be less than the [Query Interval]. | Response Interval] must be less than the [Query Interval]. | |||
8.4. Group Membership Interval | 8.4. Group Membership Interval | |||
The Group Membership Interval is the amount of time that must pass | The Group Membership Interval is the amount of time that must pass | |||
before a multicast router decides there are no more members of a | before a multicast router decides there are no more members of a | |||
group or a particular source on a network. | group or a particular source on a network. | |||
This value MUST be ((the Robustness Variable) times (the Query | This value MUST be ([Robustness Variable] times [Query Interval]) | |||
Interval)) plus (2 * Query Response Interval). | plus (2 * [Query Response Interval]). | |||
8.5. Other Querier Present Interval | 8.5. Other Querier Present Interval | |||
The Other Querier Present Interval is the length of time that must | The Other Querier Present Interval is the length of time that must | |||
pass before a multicast router decides that there is no longer | pass before a multicast router decides that there is no longer | |||
another multicast router that should be the querier. This value MUST | another multicast router that should be the querier. This value MUST | |||
be ((the Robustness Variable) times (the Query Interval)) plus (one | be ([Robustness Variable] times [Query Interval]) plus (0.5 times | |||
half of one Query Response Interval). | [Query Response Interval]). | |||
8.6. Startup Query Interval | 8.6. Startup Query Interval | |||
The Startup Query Interval is the interval between General Queries | The Startup Query Interval is the interval between General Queries | |||
sent by a Querier on startup. Default: 1/4 the Query Interval. | sent by a Querier on startup. Default: 1/4 times [Query Interval]. | |||
8.7. Startup Query Count | 8.7. Startup Query Count | |||
The Startup Query Count is the number of Queries sent out on startup, | The Startup Query Count is the number of Queries sent out on startup, | |||
separated by the Startup Query Interval. Default: The Robustness | separated by the Startup Query Interval. Default: [Robustness | |||
Variable. | Variable]. | |||
8.8. Last Member Query Interval | 8.8. Last Member Query Interval | |||
The Last Member Query Interval (LMQI) is the Max Response Time used | The Last Member Query Interval (LMQI) is the Max Response Time used | |||
to calculate the Max Resp Code that is inserted into Group-Specific | to calculate the Max Resp Code that is inserted into Group Specific | |||
Queries sent in response to Leave Group messages. It is also the Max | 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- | Response Time used in calculating the Max Resp Code for Group-and- | |||
Source-Specific Query messages. Default: 10 (1 second). | Source Specific Query messages. Default: 10 (1 second). | |||
Note that for values of LMQI greater than 12.8 seconds, a limited set | Note that for values of LMQI greater than 12.8 seconds, a limited set | |||
of values can be represented, corresponding to sequential values of | of values can be represented, corresponding to sequential values of | |||
Max Resp Code. When converting a configured time to a Max Resp Code | 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 | value, it is recommended to use the exact value, if possible, or the | |||
next lower value if the requested value is not exactly representable. | next lower value if the requested value is not exactly representable. | |||
This value may be tuned to modify the "leave latency" of the network. | 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 | A reduced value results in reduced time to detect the loss of the | |||
last member of a group or source. | last member of a group or source. | |||
8.9. Last Member Query Count | 8.9. Last Member Query Count | |||
The Last Member Query Count is the number of Group-Specific Queries | The Last Member Query Count is the number of Group Specific Queries | |||
sent before the router assumes there are no local members. The Last | sent before the router assumes there are no local members. The Last | |||
Member Query Count is also the number of Group-and-Source-Specific | Member Query Count is also the number of Group-and-Source Specific | |||
Queries sent before the router assumes there are no listeners for a | Queries sent before the router assumes there are no listeners for a | |||
particular source. Default: The Robustness Variable. | particular source. Default: [Robustness Variable]. | |||
8.10. Last Member Query Time | 8.10. Last Member Query Time | |||
The Last Member Query Time is the time value represented by the Last | The Last Member Query Time is the time value represented by [Last | |||
Member Query Interval, multiplied by the Last Member Query Count. It | Member Query Interval] times [Last Member Query Count]. It is not a | |||
is not a tunable value, but it may be tuned by changing its | tunable value, but it may be tuned by changing its components. | |||
components. | ||||
8.11. Unsolicited Report Interval | 8.11. Unsolicited Report Interval | |||
The Unsolicited Report Interval is the time between repetitions of a | The Unsolicited Report Interval is the time between repetitions of a | |||
host's initial report of membership in a group. Default: 1 second. | host's initial report of membership in a group. Default: 1 second. | |||
8.12. Older Version Querier Present Interval | 8.12. Older Version Querier Present Interval | |||
The Older Version Querier Present Interval is the timeout for | The Older Version Querier Present Interval is the timeout for | |||
transitioning a host back to IGMPv3 mode once an older version query | transitioning a host back to IGMPv3 mode once an older version query | |||
is heard. When an older version query is received, hosts set their | is received. When an older version query is received, hosts set | |||
Older Version Querier Present Timer to Older Version Querier Present | their Older-Version-Querier-Present Timer to [Older Version Querier | |||
Interval. | Present Interval]. | |||
It is RECOMMENDED to use the default values for calculating the | It is RECOMMENDED to use the default values for calculating the | |||
interval value as hosts do not know the values configured on the | interval value as hosts do not know the values configured on the | |||
querying routers. This value SHOULD be [Robustness Variable] times | querying routers. This value SHOULD be [Robustness Variable] times | |||
[Query Interval] plus (10 times the Max Resp Time in the last | [Query Interval] plus (10 times the Max Response Time in the last | |||
received query message). | received query message). | |||
8.13. Older Host Present Interval | 8.13. Older Host Present Interval | |||
The Older Host Present Interval is the timeout for transitioning a | The Older Host Present Interval is the timeout for transitioning a | |||
group back to IGMPv3 mode once an older version report is sent for | group back to IGMPv3 mode once an older version report is sent for | |||
that group. When an older version report is received, routers set | that group. When an older version report is received, routers set | |||
their Older Host Present Timer to Older Host Present Interval. | their Older-Host-Present Timer to [Older Host Present Interval]. | |||
This value MUST be ((the Robustness Variable) times (the Query | This value MUST be ([Robustness Variable] times [Query Interval]) | |||
Interval)) plus (one Query Response Interval). | plus [Query Response Interval]. | |||
8.14. Configuring Timers | 8.14. Configuring Timers | |||
This section is meant to provide advice to network administrators on | This section is meant to provide advice to network administrators on | |||
how to tune these settings to their network. Ambitious router | how to tune these settings to their network. Ambitious router | |||
implementations might tune these settings dynamically based upon | implementations might tune these settings dynamically based upon | |||
changing characteristics of the network. | changing characteristics of the network. | |||
8.14.1. Robustness Variable | 8.14.1. Robustness Variable | |||
The Robustness Variable tunes IGMP to expected losses on a link. | The Robustness Variable tunes IGMP to expected losses on a link. | |||
IGMPv3 is robust to (Robustness Variable - 1) packet losses, e.g., if | IGMPv3 is robust to ([Robustness Variable] - 1) packet losses, e.g., | |||
the Robustness Variable is set to the default value of 2, IGMPv3 is | if the Robustness Variable is set to the default value of 2, IGMPv3 | |||
robust to a single packet loss but may operate imperfectly if more | is robust to a single packet loss but may operate imperfectly if more | |||
losses occur. On lossy subnetworks, the Robustness Variable should | losses occur. On lossy subnetworks, the Robustness Variable should | |||
be increased to allow for the expected level of packet loss. | be increased to allow for the expected level of packet loss. | |||
However, increasing the Robustness Variable increases the leave | However, increasing the Robustness Variable increases the leave | |||
latency of the subnetwork. (The leave latency is the time between | latency of the subnetwork. (The leave latency is the time between | |||
when the last member stops listening to a source or group and when | when the last member stops listening to a source or group and when | |||
the traffic stops flowing.) | the traffic stops flowing.) | |||
8.14.2. Query Interval | 8.14.2. Query Interval | |||
The overall level of periodic IGMP traffic is inversely proportional | The overall level of periodic IGMP traffic is inversely proportional | |||
to the Query Interval. A longer Query Interval results in a lower | to the Query Interval. A longer Query Interval results in a lower | |||
overall level of IGMP traffic. The Query Interval MUST be equal to | overall level of IGMP traffic. The Query Interval MUST be equal to | |||
or longer than the Max Response Time inserted in General Query | or longer than the Max Response Time inserted in General Query | |||
messages. | messages. | |||
8.14.3. Max Response Time | 8.14.3. Max Response Time | |||
The burstiness of IGMP traffic is inversely proportional to the Max | The burstiness of IGMP traffic is inversely proportional to the Max | |||
Response Time. A longer Max Response Time will spread Report | Response Time. A longer Max Response Time will spread Report | |||
messages over a longer interval. However, a longer Max Response Time | messages over a longer interval. However, a longer Max Response Time | |||
in Group-Specific and Source-and-Group-Specific Queries extends the | in Group Specific and Source-and-Group Specific Queries extends the | |||
leave latency. (The leave latency is the time between when the last | leave latency. (The leave latency is the time between when the last | |||
member stops listening to a source or group and when the traffic | member stops listening to a source or group and when the traffic | |||
stops flowing.) The expected rate of Report messages can be | stops flowing.) The expected rate of Report messages can be | |||
calculated by dividing the expected number of Reporters by the Max | calculated by dividing the expected number of Reporters by the Max | |||
Response Time. The Max Response Time may be dynamically calculated | Response Time. The Max Response Time may be dynamically calculated | |||
per Query by using the expected number of Reporters for that Query as | per Query by using the expected number of Reporters for that Query as | |||
follows: | follows: | |||
+===========================+===============================+ | +======================+============================================+ | |||
| Query Type | Expected Number of Reporters | | | Query Type | Expected Number of Reporters | | |||
+===========================+===============================+ | +======================+============================================+ | |||
| General Query | All systems on the subnetwork | | | General Query | All systems on the subnetwork | | |||
+---------------------------+-------------------------------+ | +----------------------+--------------------------------------------+ | |||
| Group-Specific Query | All systems that had | | | Group Specific | All systems that had expressed interest in | | |||
| | expressed interest in the | | | Query | the group on the subnetwork | | |||
| | group on the subnetwork | | +----------------------+--------------------------------------------+ | |||
+---------------------------+-------------------------------+ | | Source-and-Group | All systems on the subnetwork that had | | |||
| Source-and-Group-Specific | All systems on the subnetwork | | | Specific Query | expressed interest in the source and group | | |||
| Query | that had expressed interest | | +----------------------+--------------------------------------------+ | |||
| | in the source and group | | ||||
+---------------------------+-------------------------------+ | ||||
Table 15 | Table 15: Expected Number of IGMP Reporters | |||
A router is not required to calculate these populations or tune the | A router is not required to calculate these populations or tune the | |||
Max Response Time dynamically; these are simply guidelines. | Max Response Time dynamically; these are simply guidelines. | |||
9. Security Considerations | 9. Security Considerations | |||
IGMP provides any form of confidentiality. This means any device on | IGMP provides any form of confidentiality. This means any device on | |||
a link can passively receive any IGMP message on the link. Such | a link can passively receive any IGMP message on the link. Such | |||
access can lead to privacy concerns around potentially sensitive | access can lead to privacy concerns around potentially sensitive | |||
multicast groups or the ability to identify/map the devices on a | multicast groups or the ability to identify/map the devices on a | |||
skipping to change at line 2206 ¶ | skipping to change at line 2206 ¶ | |||
We consider the ramifications of a forged message of each type and | We consider the ramifications of a forged message of each type and | |||
describe the usage of an IPsec Authentication Header (AH) to | describe the usage of an IPsec Authentication Header (AH) to | |||
authenticate messages if desired. | authenticate messages if desired. | |||
9.1. Query Message | 9.1. Query Message | |||
A forged Query message from a machine with a lower IP address than | 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 | the current Querier will cause Querier duties to be assigned to the | |||
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: | |||
* Routers SHOULD NOT forward Queries. This is easier for a router | * Routers SHOULD NOT forward Queries. This is easier for a router | |||
to accomplish if the Query carries the Router Alert option. | to accomplish if the Query carries the Router Alert option. | |||
skipping to change at line 2265 ¶ | skipping to change at line 2265 ¶ | |||
SHOULD be accepted on any interface. | SHOULD be accepted on any interface. | |||
2. Ignore Report messages without Router Alert options [RFC2113] and | 2. Ignore Report messages without Router Alert options [RFC2113] and | |||
require routers to not forward Report messages. (The requirement | require routers to not forward Report messages. (The requirement | |||
is not a requirement of generalized filtering in the forwarding | is not a requirement of generalized filtering in the forwarding | |||
path, as the packets already have Router Alert options in them.) | path, as the packets already have Router Alert options in them.) | |||
This solution breaks backwards compatibility with implementations | This solution breaks backwards compatibility with implementations | |||
of IGMPv1 or earlier versions of IGMPv2 that did not require a | of IGMPv1 or earlier versions of IGMPv2 that did not require a | |||
Router Alert. | Router Alert. | |||
A forged Version 1 Report Message may put a router into "version 1 | A forged v1 Report message may put a router into "v1 members present" | |||
members present" state for a particular group, meaning that the | state for a particular group, meaning that the router will ignore | |||
router will ignore Leave messages. This can cause traffic to flow to | Leave messages. This can cause traffic to flow to groups with no | |||
groups with no members for up to [Group Membership Interval]. This | members for up to [Group Membership Interval]. This can be solved by | |||
can be solved by providing routers with a configuration switch to | providing routers with a configuration switch to ignore v1 messages | |||
ignore Version 1 messages completely. This breaks automatic | completely. This breaks automatic compatibility with v1 hosts, so it | |||
compatibility with Version 1 hosts, so it should only be used in | should only be used in situations where "fast leave" is critical. | |||
situations where "fast leave" is critical. | ||||
A forged Version 2 Report Message may put a router into "version 2 | A forged v2 Report message may put a router into "v2 members present" | |||
members present" state for a particular group, meaning that the | state for a particular group, meaning that the router will ignore | |||
router will ignore IGMPv3 source-specific state messages. This can | IGMPv3 source-specific state messages. This can cause traffic to | |||
cause traffic to flow from unwanted sources for up to [Group | flow from unwanted sources for up to [Group Membership Interval]. | |||
Membership Interval]. This can be solved by providing routers with a | This can be solved by providing routers with a configuration switch | |||
configuration switch to ignore Version 2 messages completely. This | to ignore v2 messages completely. This breaks automatic | |||
breaks automatic compatibility with Version 2 hosts, so it should | compatibility with v2 hosts, so it should only be used in situations | |||
only be used in situations where source include and exclude is | where source include and exclude is critical. | |||
critical. | ||||
9.3. State-Change Report Messages | 9.3. State-Change Report Messages | |||
A forged State-Change Report message will cause the Querier to send | A forged State-Change Report message will cause the Querier to send | |||
out Group-Specific or Source-and-Group-Specific Queries for the group | out Group Specific or Source-and-Group Specific Queries for the group | |||
in question. This causes extra processing on each router and on each | in question. This causes extra processing on each router and on each | |||
member of the group, but it cannot cause loss of desired traffic. | member of the group, but it cannot cause loss of desired traffic. | |||
There are two defenses against externally forged State-Change Report | There are two defenses against externally forged State-Change Report | |||
messages: | messages: | |||
1. Ignore the State-Change Report message if you cannot identify the | 1. Ignore the State-Change Report message if you cannot identify the | |||
source address of the packet as belonging to a subnet assigned to | source address of the packet as belonging to a subnet assigned to | |||
the interface on which the packet was received. This solution | the interface on which the packet was received. This solution | |||
means that State-Change Report messages sent by mobile hosts | means that State-Change Report messages sent by mobile hosts | |||
without addresses on the local subnet will be ignored. State- | without addresses on the local subnet will be ignored. State- | |||
skipping to change at line 2338 ¶ | skipping to change at line 2336 ¶ | |||
authenticated individually so, e.g., a host cannot forge a | authenticated individually so, e.g., a host cannot forge a | |||
message that only routers should be allowed to send. | message that only routers should be allowed to send. | |||
This solution only directly applies to Query and Leave messages in | This solution only directly applies to Query and Leave messages in | |||
IGMPv1 and IGMPv2 as Reports are sent to the group being reported, | IGMPv1 and IGMPv2 as Reports are sent to the group being reported, | |||
and it is not feasible to agree on a key for host-to-router | and it is not feasible to agree on a key for host-to-router | |||
communication for arbitrary multicast groups. | communication for arbitrary multicast groups. | |||
10. IANA Considerations | 10. IANA Considerations | |||
All IGMP types described in this document are managed via [RFC9778]. | All IGMP types described in this document are managed via [BCP57]. | |||
IANA has replaced each reference to [RFC3376] with a reference to | IANA has replaced each reference to [RFC3376] with a reference to | |||
this document in both the "IGMP Type Numbers" and "IPFIX Information | this document in both the "IGMP Type Numbers" and "IPFIX Information | |||
Elements" registries. | Elements" registries. | |||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
[BCP57] Best Current Practice 57, | ||||
<https://www.rfc-editor.org/info/bcp57>. | ||||
At the time of writing, this BCP comprises the following: | ||||
Haberman, B., Ed., "IANA Considerations for Internet Group | ||||
Management Protocols", BCP 57, RFC 9778, | ||||
DOI 10.17487/RFC9778, March 2025, | ||||
<https://www.rfc-editor.org/info/rfc9778>. | ||||
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, | [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, | |||
RFC 1112, DOI 10.17487/RFC1112, August 1989, | RFC 1112, DOI 10.17487/RFC1112, August 1989, | |||
<https://www.rfc-editor.org/info/rfc1112>. | <https://www.rfc-editor.org/info/rfc1112>. | |||
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, | [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, | |||
DOI 10.17487/RFC2113, February 1997, | DOI 10.17487/RFC2113, February 1997, | |||
<https://www.rfc-editor.org/info/rfc2113>. | <https://www.rfc-editor.org/info/rfc2113>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
skipping to change at line 2383 ¶ | skipping to change at line 2390 ¶ | |||
August 2006, <https://www.rfc-editor.org/info/rfc4604>. | August 2006, <https://www.rfc-editor.org/info/rfc4604>. | |||
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for | [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for | |||
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, | IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, | |||
<https://www.rfc-editor.org/info/rfc4607>. | <https://www.rfc-editor.org/info/rfc4607>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC9778] Haberman, B., Ed., "IANA Considerations for Internet Group | ||||
Management Protocols", BCP 57, RFC 9778, | ||||
DOI 10.17487/RFC9778, March 2025, | ||||
<https://www.rfc-editor.org/info/rfc9778>. | ||||
11.2. Informative References | 11.2. Informative References | |||
[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the | [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the | |||
Internet checksum", RFC 1071, DOI 10.17487/RFC1071, | Internet checksum", RFC 1071, DOI 10.17487/RFC1071, | |||
September 1988, <https://www.rfc-editor.org/info/rfc1071>. | September 1988, <https://www.rfc-editor.org/info/rfc1071>. | |||
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. | [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. | |||
Thyagarajan, "Internet Group Management Protocol, Version | Thyagarajan, "Internet Group Management Protocol, Version | |||
3", RFC 3376, DOI 10.17487/RFC3376, October 2002, | 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, | |||
<https://www.rfc-editor.org/info/rfc3376>. | <https://www.rfc-editor.org/info/rfc3376>. | |||
skipping to change at line 2413 ¶ | skipping to change at line 2415 ¶ | |||
[RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface | [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface | |||
Extensions for Multicast Source Filters", RFC 3678, | Extensions for Multicast Source Filters", RFC 3678, | |||
DOI 10.17487/RFC3678, January 2004, | DOI 10.17487/RFC3678, January 2004, | |||
<https://www.rfc-editor.org/info/rfc3678>. | <https://www.rfc-editor.org/info/rfc3678>. | |||
Appendix A. Design Rationale | Appendix A. Design Rationale | |||
A.1. The Need for State-Change Messages | A.1. The Need for State-Change Messages | |||
IGMPv3 specifies two types of Membership Reports: Current-State and | IGMPv3 specifies two types of Membership Reports: Current-State and | |||
State Change. This section describes the rationale for needing both | State-Change. This section describes the rationale for needing both | |||
types of Reports. | types of Reports. | |||
Routers need to distinguish Membership Reports that were sent in | Routers need to distinguish Membership Reports that were sent in | |||
response to Queries from those that were sent as a result of a change | 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 | in interface state. Membership reports that are sent in response to | |||
Membership Queries are used mainly to refresh the existing state at | Membership Queries are used mainly to refresh the existing state at | |||
the router; they typically do not cause transitions in state at the | the router; they typically do not cause transitions in state at the | |||
router. Membership Reports that are sent in response to changes in | router. Membership Reports that are sent in response to changes in | |||
interface state require the router to take some action in response to | interface state require the router to take some action in response to | |||
the received report (see Section 6.4). | the received report (see Section 6.4). | |||
The inability to distinguish between the two types of reports would | The inability to distinguish between the two types of reports would | |||
force a router to treat all Membership Reports as potential changes | force a router to treat all Membership Reports as potential changes | |||
in state, and it could result in increased processing at the router | in state, and it could result in increased processing at the router | |||
as well as an increase in IGMP traffic on the network. | as well as an increase in IGMP traffic on the network. | |||
A.2. Host Suppression | A.2. Host Suppression | |||
In IGMPv1 and IGMPv2, a host would cancel sending pending membership | In IGMPv1 and IGMPv2, a host would cancel sending pending Membership | |||
reports if a similar report was observed from another member on the | Reports if a similar report was observed from another member on the | |||
network. In IGMPv3, this suppression of host membership reports has | network. In IGMPv3, this suppression of host Membership Reports has | |||
been removed. The following points explain the reasons behind this | been removed. The following points explain the reasons behind this | |||
decision. | decision. | |||
1. Routers may want to track per-host membership status on an | 1. Routers may want to track per-host membership status on an | |||
interface. This allows routers to implement fast leaves (e.g., | interface. This allows routers to implement fast leaves (e.g., | |||
for layered multicast congestion control schemes) as well as | for layered multicast congestion control schemes) as well as | |||
track membership status for possible accounting purposes. | track membership status for possible accounting purposes. | |||
2. Membership Report suppression does not work well on bridged LANs. | 2. Membership Report suppression does not work well on bridged LANs. | |||
Many bridges and Layer 2 / Layer 3 switches that implement IGMP | Many bridges and Layer 2 / Layer 3 switches that implement IGMP | |||
snooping do not forward IGMP messages across LAN segments in | snooping do not forward IGMP messages across LAN segments in | |||
order to prevent membership report suppression. Removing | order to prevent Membership Report suppression. Removing | |||
membership report suppression eases the job of these IGMP | Membership Report suppression eases the job of these IGMP | |||
snooping devices. | snooping devices. | |||
3. By eliminating membership report suppression, hosts have fewer | 3. By eliminating Membership Report suppression, hosts have fewer | |||
messages to process; this leads to a simpler state machine | messages to process; this leads to a simpler state machine | |||
implementation. | implementation. | |||
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 | |||
skipping to change at line 2508 ¶ | skipping to change at line 2510 ¶ | |||
changing the maximum from 25.5 seconds to about 53 minutes, for | changing the maximum from 25.5 seconds to about 53 minutes, for | |||
use on links with a huge number of systems. | use on links with a huge number of systems. | |||
* Hosts retransmit state-change messages for increased robustness. | * Hosts retransmit state-change messages for increased robustness. | |||
* Additional data sections are defined, to allow later extensions. | * Additional data sections are defined, to allow later extensions. | |||
* Report packets are sent to 224.0.0.22, to assist Layer 2 switches | * Report packets are sent to 224.0.0.22, to assist Layer 2 switches | |||
in snooping. | in snooping. | |||
* Report packets can contain multiple group records, to allow | * Report packets can contain multiple Group Records, to allow | |||
reporting of full current state using fewer packets. | reporting of full current state using fewer packets. | |||
* Hosts no longer perform suppression, to simplify implementations | * Hosts no longer perform suppression, to simplify implementations | |||
and permit explicit membership tracking. | and permit explicit membership tracking. | |||
* A new S flag in Query messages fixes robustness issues, which were | * A new S flag in Query messages fixes robustness issues, which were | |||
also present in IGMPv2. | also present in IGMPv2. | |||
Appendix C. Summary of Changes from RFC 3376 | Appendix C. Summary of Changes from RFC 3376 | |||
skipping to change at line 2534 ¶ | skipping to change at line 2536 ¶ | |||
* Modified the metadata to fix the Obsoletes vs. Updates | * Modified the metadata to fix the Obsoletes vs. Updates | |||
relationship with [RFC2236] per Erratum 1501. | relationship with [RFC2236] per Erratum 1501. | |||
* Updated the introductory text to describe the Updates relationship | * Updated the introductory text to describe the Updates relationship | |||
with [RFC2236] per Erratum 7339. | with [RFC2236] per Erratum 7339. | |||
* Updated the definition of Group Membership Interval to address | * Updated the definition of Group Membership Interval to address | |||
Erratum 6725. | Erratum 6725. | |||
* Updated the text relating to the router filter-mode to address | * Updated the text relating to the Router Filter Mode to address | |||
Erratum 5562. | Erratum 5562. | |||
* Clarified the use of General Queries in the Querier election | * Clarified the use of General Queries in the Querier election | |||
process. | process. | |||
Acknowledgments | Acknowledgments | |||
We would like to thank Ran Atkinson, Luis Costa, Toerless Eckert, | We would like to thank Ran Atkinson, Luis Costa, Toerless Eckert, | |||
Dino Farinacci, Serge Fdida, Wilbert de Graaf, Sumit Gupta, Mark | Dino Farinacci, Serge Fdida, Wilbert de Graaf, Sumit Gupta, Mark | |||
Handley, Bob Quinn, Michael Speer, Dave Thaler, and Rolland Vida for | Handley, Bob Quinn, Michael Speer, Dave Thaler, and Rolland Vida for | |||
End of changes. 186 change blocks. | ||||
371 lines changed or deleted | 373 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |