Internet Group Management Protocol
From Wikipedia, the free encyclopedia
| The five layer TCP/IP model |
| 5. Application layer |
|
DHCP • DNS • FTP • HTTP • IMAP4 • IRC • NNTP • XMPP • MIME • POP3 • SIP • SMTP • SNMP • SSH • TELNET • BGP • RPC • RTP • RTCP • TLS/SSL • SDP • SOAP • L2TP • PPTP • … |
| 4. Transport layer |
| 3. Network layer |
| 2. Data link layer |
|
ATM • DTM • Ethernet • FDDI • Frame Relay • GPRS • PPP • ARP • RARP • … |
| 1. Physical layer |
|
Ethernet physical layer • ISDN • Modems • PLC • SONET/SDH • G.709 • Wi-Fi • … |
The Internet Group Management Protocol is a communications protocol used to manage the membership of Internet Protocol multicast groups. IGMP is used by IP hosts and adjacent multicast routers to establish multicast group memberships. It is an integral part of the IP multicast specification, like ICMP for unicast connections. IGMP can be used for online video and gaming, and allows more efficient use of resources when supporting these uses. IGMP does allow some attacks[1] [2] [3] [4], and firewalls commonly allow the user to disable it if it will not be needed.
Join Latency-The time it takes for data to begin flowing after an application issues a command to join a multicast group
Leave Latency-The time it takes for data to stop flowing after an application issues a command to leave a multicast group (this applies only in cases of IGMPv2,IGMPv3 not in IGMPv1).
Contents
|
[edit] IGMP version 0.
[edit] RFC 966, page 16:
The Internet Group Management Protocol (IGMP(v0)) is used between IP hosts and their immediate neighbour multicast agents to support the allocation of temporary group addresses and the addition and deletion of members of a group.
[edit] RFC 988, pages 1, 2 and 3:
IP multicasting is defined as the transmission of an IP datagram to a "host group", an set of zero or more hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same "best-efforts" reliability as regular unicast IP datagrams, i.e. the datagram is not guaranteed to arrive at all members of the destination group or in the same order relative to other datagrams. The membership of a host group is dynamic; that is, hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group, but membership in a group may be restricted to only those hosts possessing a private access key. A host may be a member of more than one group at a time. A host need not be a member of a group to send datagrams to it. A host group may be permanent or transient. A permanent group has a well-known, administratively assigned IP address. It is the address, not the membership of the group, that is permanent; at any time a permanent group may have any number of members, even zero. A transient group, on the other hand, is assigned an address dynamically when the group is created, at the request of a host. A transient group ceases to exist, and its address becomes eligible for reassignment, when its membership drops to zero.
The creation of transient groups and the maintenance of group membership information is the responsibility of "multicast agents", entities that reside in internet gateways or other special-purpose hosts. There is at least one multicast agent directly attached to every IP network or subnetwork that supports IP multicasting. A host requests the creation of new groups, and joins or leaves existing groups, by exchanging messages with a neighboring agent. Multicast agents are also responsible for internetwork delivery of multicast IP datagrams. When sending a multicast IP datagram, a host transmits it to a local network multicast address which identifies all neighboring members of the destination host group. If the group has members on other networks, a multicast agent becomes an additional recipient of the local multicast and relays the datagram to agents on each of those other networks, via the internet gateway system. Finally, the agents on the other networks each transmit the datagram as a local multicast to their own neighboring members of the destination group. Level 2: full support for IP multicasting, allows a host to create, join and leave host groups, as well as send IP datagrams to host groups. It requires implementation of the Internet Group Management Protocol (IGMP) and extension of the IP and local network service interfaces within the host. All of the following sections of this memo are applicable to level 2 implementations.
[edit] RFC 988, page 10:
Within the IP module, the membership management operations are supported by the Internet Group Management Protocol (IGMP), specified in Appendix I. As well as having messages corresponding to each of the operations specified above, IGMP also specifies a "deadman timer" procedure whereby hosts periodically confirm their memberships with the multicast agents.
The IP module must maintain a data structure listing the IP addresses of all host groups to which the host currently belongs, along with each group's loopback policy, access key, and timer variables. This data structure is used by the IP multicast transmission service to know which outgoing datagrams to loop back, and by the reception service to know which incoming datagrams to accept. The purpose of IGMP and the management interface operations is to maintain this data structure.
[edit] RFC 988, page 13:
The Internet Group Management Protocol (IGMP) is used between IP hosts and their immediate neighbor multicast agents to support the creation of transient groups, the addition and deletion of members of a group, and the periodic confirmation of group membership. IGMP is an asymmetric protocol and is specified here from the point of view of a host, rather than a multicast agent.
Like ICMP, IGMP is an integral part of IP. It is required to be implemented in full by all hosts conforming to level 2 of the IP multicasting specification. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2. All IGMP messages have the following format:
| MAC header | IP-Header | IGMP packet |
The IGMP packet format for IGMP version 0 is:
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type | Code | IGMP Checksum | |||||||||||||||||||||||||||||
| Identifier | |||||||||||||||||||||||||||||||
| Group Address | |||||||||||||||||||||||||||||||
| Access Key::: | |||||||||||||||||||||||||||||||
Type. 8 bit:
Type Description 1 Create Group Request. 2 Create Group Reply. 3 Join Group Request. 4 Join Group Reply. 5 Leave Group Request. 6 Leave Group Reply. 7 Confirm Group Request. 8 Confirm Group Reply.
Code. 8 bits.
In a Create Group Request message, this field indicates if the new host group is to be public or private. In all other Request messages, this field is set to zero.
Code Description 0 Public. 1 Private.
In a Reply message, the Code field specifies the outcome of the request. Code Description
0 Request granted. 1 Request denied, no resources. 2 Request denied, invalid code. 3 Request denied, invalid group address. 4 Request denied, invalid access key. 5-255 Request pending, retry in this many seconds.
IGMP Checksum. 16 bits.
The checksum is the 16-bit one's complement of the one's complement sum of the IGMP message starting with the IGMP Type. For computing the checksum, the checksum field should first be set to 0. When the data packet is transmitted, the checksum is computed and inserted into this field. When the data packet is received, the checksum is again computed and verified against the checksum field. If the two checksums do not match then an error has occurred.
Identifier. 32 bits.
In a Confirm Group Request message, the identifier field contains zero. In all other Request messages, the identifier field contains a value to distinguish the request from other requests by the same host. In a Reply message, the identifier field contains the same value as in the corresponding Request message.
Group Address. 32 bits.
In a Create Group Request message, the group address field contains zero. In all other Request messages, the group address field contains a host group address. In a Create Group Reply message, the group address field contains either a newly allocated host group address (if the request is granted) or zero (if denied). In all other Reply messages, the group address field contains the same host group address as in the corresponding Request message.
Access Key. 64 bits.
In a Create Group Request message, the access key field contains zero. In all other Request messages, the access key field contains the access key assigned to the host group identified in the Group Address field (zero for public groups). In a Create Group Reply message, the access key field contains either a non-zero 64-bit number (if the request for a private group is granted) or zero. In all other Reply messages, the access key field contains the same access key as in the corresponding Request.
[edit] IGMP version 1.
[edit] RFC 1054, pages 10 through 13:
The Internet Group Management Protocol (IGMP(v1)) is used by IP hosts to report their host group memberships to any immediately-neighboring multicast routers. IGMP is an asymmetric protocol and is specified here from the point of view of a host, rather than a multicast router. (IGMP may also be used, symmetrically or asymmetrically, between multicast routers.)
Like ICMP, IGMP is an integral part of IP. It is required to be implemented by all hosts conforming to level 2 of the IP multicasting specification. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2. This memo specifies version 1 of IGMP.
Informal Protocol Description. Multicast routers send Host Membership Query messages (hereinafter called Queries) to discover which host groups have members on their attached local networks. Queries are addressed to the all-hosts group (address 224.0.0.1), and carry an IP time-to-live (TTL) of 1.
Hosts respond to a Query by generating Host Membership Reports (hereinafter called Reports), reporting each host group to which they belong on the network interface from which the Query was received. In order to avoid an "implosion" of concurrent Reports and to reduce the total number of Reports transmitted, two techniques are used:
- When a host receives a Query, rather than sending Reports immediately, it starts a report delay timer for each of its group memberships on the network interface of the incoming Query. Each timer is set to a different, randomly-chosen value between zero and D seconds. When a timer expires, a report is generated for the corresponding host group. Thus, Reports are spread out over a D second interval instead of all occurring at once.
- A Report is sent with an IP destination address equal to the host group address being reported, and with an IP time-to-live of 1, so that other members of the same group on the same network can overhear the Report. If a host hears a Report for a group to which it belongs on that network, the host stops its own timer for that group and does not generate a Report for that group. Thus, in the normal case, only one Report will be generated for each group present on the network, by the member host whose delay timer expires first. Note that the multicast routers receive all IP multicast datagrams, and therefore need not be addressed explicitly. Further note that the routers need not know which hosts belong to a group, only that at least one host belongs to a group on a particular network.
There are two exceptions to the behavior described above. First, if a report delay timer is already running for a group membership when a Query is received, that timer is not reset to a new random value, but rather allowed to continue running with its current value. Second, a report delay timer is never set for a host's membership in the all- hosts group (224.0.0.1), and that membership is never reported.
If a host uses a pseudo-random number generator to compute the reporting delays, one of the host's own individual IP address should be used as part of the seed for the generator, to reduce the chance of multiple hosts generating the same sequence of delays.
A host should confirm that a received Report has the same IP host group address in its IP destination field and its IGMP group address field, to ensure that the host's own Report is not cancelled by an erroneous received Report. A host should quietly discard any IGMP message of type other than Host Membership Query or Host Membership Report.
Multicast routers send Queries periodically to refresh their knowledge of memberships present on a particular network. If no Reports are received for a particular group after some number of Queries, the routers assume that that group has no local members and that they need not forward remotely-originated multicasts for that group onto the local network. Queries are normally sent infrequently (no more than once a minute) so as to keep the IGMP overhead on hosts and networks very low. However, when a multicast router starts up, it may issue several closely-space Queries in order to quickly build up its knowledge of local memberships.
When a host joins a new group, it should immediately transmit a Report for that group, rather than waiting for a Query, in case it is the first member of that group on the network. To cover the possibility of the initial Report being lost or damaged, it is recommended that it be repeated once or twice after short delays. A simple way to accomplish this is to act as if a Query had been received for that group only, setting the group's random report delay timer.
[edit] RFC 1054, pages 16 and 17:
[edit] HOST GROUP ADDRESS ISSUES: Group Address Binding.
The binding of IP host group addresses to physical hosts may be considered a generalization of the binding of IP unicast addresses. An IP unicast address is statically bound to a single local network interface on a single IP network. An IP host group address is dynamically bound to a set of local network interfaces on a set of IP networks.
An IP host group address is not bound to a set of IP unicast addresses. The multicast routers do not need to maintain a list of individual members of each host group. For example, a multicast router attached to an Ethernet need associate only a single Ethernet multicast address with each host group having local members, rather than a list of the members' individual IP or Ethernet addresses.
[edit] CHANGES FROM RFC-988.
The IP multicast extensions specified in this memo are significantly different from those specified in RFC-988. Most of the changes are due to a shift of responsibility away from the multicast routers (called "multicast agents" in RFC-988) and onto the hosts. This new distribution of responsibility is consistent with the lightweight, soft-state gateway architecture of the Internet, and it allows the IP multicast services (in the same way as the IP unicast services) to be used among hosts on a single network when no router is up or present on the network. Thus, current single-network IP broadcast applications may be migrated to the use of IP multicast before multicast routers are widely available.
[edit] RFC 1112, page 3:
[edit] HOST GROUP ADDRESSES.
Host groups are identified by class D IP addresses, i.e., those with "1110" as their high-order four bits. Class E IP addresses, i.e., those with "1111" as their high-order four bits, are reserved for future addressing modes. In Internet standard "dotted decimal" notation, host group addresses range from 224.0.0.0 to 239.255.255.255. The address 224.0.0.0 is guaranteed not to be assigned to any group, and 224.0.0.1 is assigned to the permanent group of all IP hosts (including gateways). This is used to address all multicast hosts on the directly connected network. There is no multicast address (or any other IP address) for all hosts on the total Internet. The addresses of other well-known, permanent groups are to be published in "Assigned Numbers".
[edit] RFC 1112, page 11:
The Internet Group Management Protocol (IGMP(v1)) is used by IP hosts to report their host group memberships to any immediately-neighboring multicast routers. IGMP is an asymmetric protocol and is specified here from the point of view of a host, rather than a multicast router. (IGMP may also be used, symmetrically or asymmetrically, between multicast routers. Such use is not specified here.) Like ICMP, IGMP is an integral part of IP. It is required to be implemented by all hosts conforming to level 2 of the IP multicasting specification. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2.
[edit] RFC 1112, page 47:
IGMP [RFC 1112] is a protocol used between hosts and gateways on a single network to establish hosts' membership in particular multicast groups. The gateways use this information, in conjunction with a multicast routing protocol, to support IP multicasting across the Internet.
At this time, implementation of IGMP is OPTIONAL...Without IGMP, a host can still participate in multicasting local to its connected networks.
[edit] RFC 1112, pages 67 and 68:
A host SHOULD support local IP multicasting on all connected networks for which a mapping from Class D IP addresses to link-layer addresses has been specified (see below). Support for local IP multicasting includes sending multicast datagrams, joining multicast groups and receiving multicast datagrams, and leaving multicast groups. This implies support for all of [RFC 1112] except the IGMP protocol itself, which is OPTIONAL.
IGMP provides gateways that are capable of multicast routing with the information required to support IP multicasting across multiple networks. At this time, multicast-routing gateways are in the experimental stage and are not widely available. For hosts that are not connected to networks with multicast-routing gateways or that do not need to receive multicast datagrams originating on other networks, IGMP serves no purpose and is therefore optional for now. However, the rest of [RFC 1112] is currently recommended for the purpose of providing IP-layer access to local network multicast addressing, as a preferable alternative to local broadcast addressing. It is expected that IGMP will become recommended at some future date, when multicast-routing gateways have become more widely available.
If IGMP is not implemented, a host SHOULD still join the "all- hosts" group (224.0.0.1) when the IP layer is initialized and remain a member for as long as the IP layer is active.
Joining the "all-hosts" group will support strictly local uses of multicasting, e.g., a gateway discovery protocol, even if IGMP is not implemented.
The mapping of IP Class D addresses to local addresses is currently specified for the following types of networks:
- Ethernet/IEEE 802.3.
- Any network that supports broadcast but not multicast, addressing: all IP Class D addresses map to the local broadcast address.
- Any type of point-to-point link (e.g., SLIP or HDLC links): no mapping required. All IP multicast datagrams are sent as-is, inside the local framing.
Mappings for other types of networks will be specified in the future. A host SHOULD provide a way for higher-layer protocols or applications to determine which of the host's connected network(s) support IP multicast addressing.
[edit] RFC 1812, page 84:
[edit] INTERNET GROUP MANAGEMENT PROTOCOL - IGMP.
IGMP is a protocol used between hosts and multicast routers on a single physical network to establish hosts' membership in particular multicast groups. Multicast routers use this information, in conjunction with a multicast routing protocol, to support IP multicast forwarding across the Internet. A router SHOULD implement the multicast router part of IGMP.
| MAC header | IP-Header | IGMP packet |
The IGMP packet format for IGMP version 1 is:
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Version | Type | Unused | IGMP Checksum | ||||||||||||||||||||||||||||
| Group Address | |||||||||||||||||||||||||||||||
Version. 4 bits.
Set to 1.
Type. 4 bits.
Type Description 1 Host Membership Query. 2 Host Membership Report. 3 DVRMP
Unused. 8 bits.
Set to zero when the IGMP packet is sent and ignored when received.
IGMP Checksum. 16 bits.
The checksum is the 16-bit one's complement of the one's complement sum of the 8-byte IGMP message. When the checksum is computed, the checksum field should first be set to 0. When the data packet is transmitted, the checksum is computed and inserted into this field. When the data packet is received, the checksum is again computed and verified against the checksum field. If the two checksums do not match then an error has occurred.
Group Address. 32 bits.
In a Host Membership Query message, the group address field is zeroed when sent, ignored when received. In a Host Membership Report message, the group address field holds the IP host group address of the group being reported.
[edit] IGMP version 2.
[edit] RFC 2236, pages 1 and 2:
IGMPv2 allows group membership termination to be quickly reported to the routing protocol, which is important for high-bandwidth multicast groups and/or subnets with highly volatile group membership.
Like ICMP, IGMP is an integral part of IP. It is required to be implemented by all hosts wishing to receive IP multicasts. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2. All IGMP messages described in this document are sent with IP TTL 1, and contain the IP Router Alert option in their IP header.
[edit] RFC 2113, page 2:
The Router Alert option has the semantic "routers should examine this packet more closely". By including the Router Alert option in the IP header of its protocol message, RSVP (Resource ReSerVation Protocol) can cause the message to be intercepted while causing little or no performance penalty on the forwarding of normal data packets.
[edit] RFC 2236, pages 4 and 5:
Multicast routers use IGMP(v2) to learn which groups have members on each of their attached physical networks. A multicast router keeps a list of multicast group memberships for each attached network, and a timer for each membership. "Multicast group memberships" means the presence of at least one member of a multicast group on a given attached network, not a list of all of the members. When a host receives a General Query, it sets delay timers for each group (excluding the all-systems group) of which it is a member on the interface from which it received the query.
When a router receives a Report, it adds the group being reported to the list of multicast group memberships on the network on which it received the Report and sets the timer for the membership to the Group Membership Interval. When a host joins a multicast group, it should immediately transmit an unsolicited Version 2 Membership Report for that group, in case it is the first member of that group on the network.
When a host leaves a multicast group, if it was the last host to reply to a Query with a Membership Report for that group, it SHOULD send a Leave Group message to the all-routers multicast group (224.0.0.2).
| MAC header | IP-Header | IGMP packet |
The IGMP packet format for IGMP version 2 is:
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type | Max Response Time | IGMP Checksum | |||||||||||||||||||||||||||||
| Group Address | |||||||||||||||||||||||||||||||
Type. 8 bits.
| Type | Description |
|---|---|
| 0x11 | Group Membership Query, general or group-specific. General Query is used to learn which groups have members on an attached network. Group-Specific Query is used to learn if a particular group has any members on an attached network. These two messages are differentiated by the Group Address. |
| 0x12 | Version 1 - Membership Report. |
| 0x16 | Version 2 - Membership Report. |
| 0x17 | Leave Group. |
| 0x24 | Multicast Router Advertisement. |
| 0x25 | Multicast Router Solicitation. |
| 0x26 | Multicast Router Termination. |
Max Response Time. 8 bits.
The Max Response Time field is used only in Membership Query messages. It specifies the maximum allowed time before sending a responding report in units of 1/10 second. In all other messages, it is set to zero by the sender and ignored by receivers.
Varying this setting allows IGMPv2 routers to tune the "leave latency" (the time between the moment the last host leaves a group and when the routing protocol is notified that there are no more members). It also allows tuning of the burstiness of IGMP traffic on a subnet.
IGMP Checksum. 16 bits.
The 16-bit one's complement of the one's complement sum of the IGMP message, starting with the IGMP Type field. For computing the checksum, the checksum field should first be set to 0. When the data packet is transmitted, the checksum is computed and inserted into this field. When the data packet is received, the checksum is again computed and verified against the checksum field. If the two checksums do not match then an error has occurred.
Group Address. 32 bits.
In a Membership Query message, this field is set to zero when sending a General Query, and set to the group address being queried when sending a Group-Specific Query. In a Membership Report or Leave Group message, this field holds the IP multicast group address of the group being reported or left.
[edit] IGMP version 3
[edit] RFC 3376
From the abstract of RFC 3376: "Version 3 of IGMP adds support for "source filtering", that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers."
[edit] Interoperation With Older Versions of IGMP
IGMP version 3 hosts and routers interoperate with hosts and routers that have not yet been upgraded to IGMPv3. This compatibility is maintained by hosts and routers taking appropriate actions depending on the versions of IGMP operating on hosts and routers within a network.
[edit] Query Version Distinctions
The IGMP version of a Membership Query message is determined as follows:
| IGMPv1 Query | length = 8 octets AND Max Resp Code field is zero |
| IGMPv2 Query | length = 8 octets AND Max Resp Code field is non-zero |
| IGMPv3 Query | length >= 12 octets |
| Query messages that do not match any of the above conditions (e.g., a Query of length 10 octets) MUST be silently ignored. | |
[edit] Group Member Behavior
[edit] In the Presence of Older Version Queriers
In order to be compatible with older version routers, IGMPv3 hosts MUST operate in version 1 and version 2 compatibility modes. IGMPv3 hosts MUST keep state per local interface regarding the compatibility mode of each attached network. A host's compatibility mode is determined from the Host Compatibility Mode variable which can be in one of three states: IGMPv1, IGMPv2 or IGMPv3. This variable is kept per interface and is dependent on the version of General Queries heard on that interface as well as the Older Version Querier Present timers for the interface.
In order to switch gracefully between versions of IGMP, hosts keep both an IGMPv1 Querier Present timer and an IGMPv2 Querier Present timer per interface. IGMPv1 Querier Present is set to Older Version Querier Present Timeout seconds whenever an IGMPv1 Membership Query is received. IGMPv2 Querier Present is set to Older Version Querier Present Timeout seconds whenever an IGMPv2 General Query is received.
The Host Compatibility Mode of an interface changes whenever an older version query (than the current compatibility mode) is heard or when certain timer conditions occur. When the IGMPv1 Querier Present timer expires, a host switches to Host Compatibility mode of IGMPv2 if it has a running IGMPv2 Querier Present timer. If it does not have a running IGMPv2 Querier Present timer then it switches to Host Compatibility of IGMPv3. When the IGMPv2 Querier Present timer expires, a host switches to Host Compatibility mode of IGMPv3.
The Host Compatibility Mode variable is based on whether an older version General query was heard in the last Older Version Querier Present Timeout seconds. The Host Compatibility Mode is set depending on the following:
| Host Compatibility Mode | Timer State |
|---|---|
| IGMPv3 (default) | IGMPv2 Querier Present not running and IGMPv1 Querier Present not running |
| IGMPv2 | IGMPv2 Querier Present running and IGMPv1 Querier Present not running |
| IGMPv1 | IGMPv1 Querier Present running |
If a host receives a query which causes its Querier Present timers to be updated and correspondingly its compatibility mode, it should switch compatibility modes immediately.
When Host Compatibility Mode is IGMPv3, a host acts using the IGMPv3 protocol on that interface. When Host Compatibility Mode is IGMPv2, a host acts in IGMPv2 compatibility mode, using only the IGMPv2 protocol, on that interface. When Host Compatibility Mode is IGMPv1, a host acts in IGMPv1 compatibility mode, using only the IGMPv1 protocol on that interface.
An IGMPv1 router will send General Queries with the Max Resp Code set to 0. This MUST be interpreted as a value of 100 (10 seconds).
An IGMPv2 router will send General Queries with the Max Resp Code set to the desired Max Resp Time, i.e., the full range of this field is linear and the exponential algorithm described in section 4.1.1 is not used.
Whenever a host changes its compatibility mode, it cancels all its pending response and retransmission timers.
[edit] In the Presence of Older Version Group Members
An IGMPv3 host may be placed on a network where there are hosts that have not yet been upgraded to IGMPv3. A host MAY allow its IGMPv3 Membership Record to be suppressed by either a Version 1 Membership Report, or a Version 2 Membership Report.
[edit] Multicast Router Behavior
[edit] In the Presence of Older Version Queriers
IGMPv3 routers may be placed on a network where at least one router on the network has not yet been upgraded to IGMPv3. The following requirements apply:
- If any older versions of IGMP are present on routers, the querier MUST use the lowest version of IGMP present on the network. This must be administratively assured; routers that desire to be compatible with IGMPv1 and IGMPv2 MUST have a configuration option to act in IGMPv1 or IGMPv2 compatibility modes. When in IGMPv1 mode, routers MUST send Periodic Queries with a Max Resp Code of 0 and truncated at the Group Address field (i.e., 8 bytes long), and MUST ignore Leave Group messages. They SHOULD also warn about receiving an IGMPv2 or IGMPv3 query, although such warnings MUST be rate-limited. When in IGMPv2 mode, routers MUST send Periodic Queries truncated at the Group Address field (i.e., 8 bytes long), and SHOULD also warn about receiving an IGMPv3 query (such warnings MUST be rate-limited). They also MUST fill in the Max Resp Time in the Max Resp Code field, i.e., the exponential algorithm described in section 4.1.1 is not used.
- If a router is not explicitly configured to use IGMPv1 or IGMPv2 and hears an IGMPv1 Query or IGMPv2 General Query, it SHOULD log a warning. These warnings MUST be rate-limited.
[edit] In the Presence of Older Version Group Members
IGMPv3 routers may be placed on a network where there are hosts that have not yet been upgraded to IGMPv3. In order to be compatible with older version hosts, IGMPv3 routers MUST operate in version 1 and version 2 compatibility modes. IGMPv3 routers keep a compatibility mode per group record. A group's compatibility mode is determined from the Group Compatibility Mode variable which can be in one of three states: IGMPv1, IGMPv2 or IGMPv3. This variable is kept per group record and is dependent on the version of Membership Reports heard for that group as well as the Older Version Host Present timer for the group.
In order to switch gracefully between versions of IGMP, routers keep an IGMPv1 Host Present timer and an IGMPv2 Host Present timer per group record. The IGMPv1 Host Present timer is set to Older Version Host Present Timeout seconds whenever an IGMPv1 Membership Report is received. The IGMPv2 Host Present timer is set to Older Version Host Present Timeout seconds whenever an IGMPv2 Membership Report is received.
The Group Compatibility Mode of a group record changes whenever an older version report (than the current compatibility mode) is heard or when certain timer conditions occur. When the IGMPv1 Host Present timer expires, a router switches to Group Compatibility mode of IGMPv2 if it has a running IGMPv2 Host Present timer. If it does not have a running IGMPv2 Host Present timer then it switches to Group Compatibility of IGMPv3. When the IGMPv2 Host Present timer expires and the IGMPv1 Host Present timer is not running, a router switches to Group Compatibility mode of IGMPv3. Note that when a group switches back to IGMPv3 mode, it takes some time to regain source-specific state information. Source-specific information will be learned during the next General Query, but sources that should be blocked will not be blocked until Group Membership Interval after that.
The Group Compatibility Mode variable is based on whether an older version report was heard in the last Older Version Host Present Timeout seconds. The Group Compatibility Mode is set depending on the following:
| Group Compatibility Mode | Timer State |
|---|---|
| IGMPv3 (default) | IGMPv2 Host Present not running and IGMPv1 Host Present not running |
| IGMPv2 | IGMPv2 Host Present running and IGMPv1 Host Present not running |
| IGMPv1 | IGMPv1 Host Present running |
If a router receives a report which causes its older Host Present timers to be updated and correspondingly its compatibility mode, it SHOULD switch compatibility modes immediately.
When Group Compatibility Mode is IGMPv3, a router acts using the IGMPv3 protocol for that group.
When Group Compatibility Mode is IGMPv2, a router internally translates the following IGMPv2 messages for that group to their IGMPv3 equivalents:
| IGMPv2 Message | IGMPv3 Equivalent |
|---|---|
| Report | IS_EX( {} ) |
| Leave | TO_IN( {} ) |
IGMPv3 BLOCK messages are ignored, as are source-lists in TO_EX() messages (i.e., any TO_EX() message is treated as TO_EX( {} )).
When Group Compatibility Mode is IGMPv1, a router internally translates the following IGMPv1 and IGMPv2 messages for that group to their IGMPv3 equivalents:
| IGMP Message | IGMPv3 Equivalent |
|---|---|
| v1 Report | IS_EX( {} ) |
| v2 Report | IS_EX( {} ) |
In addition to ignoring IGMPv3 BLOCK messages and source-lists in TO_EX() messages as in IGMPv2 Group Compatibility Mode, IGMPv2 Leave messages and IGMPv3 TO_IN() messages are also ignored.
[edit] References
- ^ Spoofed IGMP report denial of service vulnerability.
- ^ Fragmented IGMP packet may promote "Denial of Service" attack.
- ^ IGMP Security Problem Statement and Requirements.
- ^ Microsoft Security Bulletin MS06-007: Vulnerability in TCP/IP Could Allow Denial of Service (913446).
[edit] External links
- http://www.networksorcery.com/enp/protocol/igmp.htm
- IPv4 Multicasting Tools and Settings on Microsoft TechNet
