IDMR Working Group M. Christensen
Internet Draft Exbit Technology
February 2001 F. Solensky
Expiration Date: August 2001 Gotham Networks
IGMPv3 and IGMP Snooping switches
<draft-ietf-idmr-snoop-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo describes the interoperability problems and issues that can
arise when a mixed deployment of IGMPv3 and IGMPv2 capable hosts and
routers are interconnected by a switch with IGMP snooping
capabilities. It is intended as a accompanying document to the
IGMPv3 specification.
The memo contains a brief IGMP walk through followed by a description
of the IGMP snooping functionality. Specific examples are given
which are all based on Ethernet as the link layer protocol. Finally
recommendations are given for the behavior of IGMP snooping switches.
The purpose of this document is twofold:
- We want to summarize IGMP snooping induced problems so that IETF
can take appropriate actions when deciding on new protocols and
behaviors.
Christensen, Solensky [Page 1]
RFC DRAFT February 2001
- We also hope to bring the attention to switch vendors so that we
can minimize the interoperability problems in the future.
1. Introduction
In recent years, a number of commercial vendors have introduced prod-
ucts described as "IGMP snooping switches" to the market. These
devices do not adhere to the conceptual model that provides the
strict separation of functionality between different communications
layers in the ISO model and instead utilizes information in the upper
level protocol headers as factors to be considered in the processing
at the lower levels. This is analogous to the manner in which a
router can act as a firewall by looking into the transport protocol's
header before allowing a packet to be forwarded to its destination
address.
In the case of multicast traffic, an IGMP snooping switch provides
the benefit of conserving bandwidth on those segments of the network
where no node has expressed interest in receiving packets addressed
to the group address.
2. IGMP snooping overview
For a full description of IGMP we refer to [IGMPv3], however, IGMP
operation can be summarized in the following:
* Hosts send IGMP Membership Report messages to inform neighboring
routers that they wish to join a specific IP multicast group.
* IGMPv3 Membership Reports may be qualified with a list of allowed
or forbidden source addresses.
* Routers periodically send IGMP Group Query messages to Hosts in
order to maintain group membership state information. These
queries can be either general or group specific queries.
* Hosts respond to queries with membership Reports.
* Hosts running either IGMPv2 or IGMPv3 may also send a Leave Group
message to routers to withdraw from the group.
A traditional Ethernet network may be separated into different net-
work segments to prevent placing too many devices onto the same
shared media. These segments are connected by bridges and switches.
Christensen, Solensky [Page 2]
RFC DRAFT February 2001
When a packet with a broadcast or multicast destination address is
received, the switch will forward a copy into each of the remaining
network segments in accordance with [BRIDGE]. Eventually, the packet
is made accessible to all nodes connected to the network.
This approach works well for broadcast packets that are intended to
be seen or processed by all connected nodes. In the case of multi-
cast packets, however, this approach could lead to less efficient use
of network bandwidth, particularly when the packet is intended for
only a small number of nodes. Packets will be flooded into network
segments where no node has any interest in receiving the packet.
While nodes will rarely incur any processing overhead to filter pack-
ets addressed to unrequested group addresses, they are unable to
transmit new packets onto the shared media for the period of time
that the multicast packet is flooded.
The problem of wasting bandwidth is even worse when the LAN segment
is not shared, for example in Full Duplex links. Full Duplex is
standard today for most switches operating at 1Gbps or above. In this
case the bandwidth that is wasted is proportional to the number of
attached nodes.
Allowing switches to snoop IGMP packets is a creative effort to solve
this problem. The switch uses the information in the IGMP packets as
they are being flooded throughout the network to determine which seg-
ments should receive packets directed to the group address.
IGMP snooping is being implemented slightly different by different
switch vendors. We will not address specific implementations here as
documentation is not widely available. For details of one implementa-
tion we refer to [CISCO].
In the following we will describe problems in relation to IGMP snoop-
ing with the following constraints, which we believe are the most
common cases.
1. Group membership is based on multicast MAC addresses only.
2. Forwarding is based on port masks for each supported multicast
group.
3. The switch is equipped with a CPU for maintaining group member-
ship information.
Constraint 3 above is not a strict requirement as IGMP snooping could
be accomplished entirely in hardware. However it becomes more diffi-
cult to support future modifications to the protocol.
Christensen, Solensky [Page 3]
RFC DRAFT February 2001
IGMP snooping switches build forwarding lists by listening for (and
in some cases intercepting) IGMP messages. Although the software
processing the IGMP messages may maintain state information based on
the full IP group addresses, the forwarding tables are typically
mapped to link layer addresses. An example of such a forwarding
table is shown in Figure 1.
Multicast MAC address | Member ports
-------------------------------------
01-00-5e-00-00-01 | 2, 7
01-00-5e-01-02-03 | 1, 2, 3, 7
01-00-5e-23-e2-05 | 1, 4
-------------------------------------
Figure 1.
Because only the least significant 23 bits of the IP address are
mapped to Ethernet addresses [RFC1112], there is a loss of informa-
tion when forwarding solely on the destination MAC address. This
means that for example 224.0.0.123 and 239.128.0.123 and similar IP
multicast addresses all map to MAC address 01-00-5e-00-00-7b (for
Ethernet). As a consequence, IGMP snooping switches may collapse IP
multicast group memberships into a single Ethernet multicast member-
ship group.
Finally, it should be mentioned that in addition to building and
maintaining lists of multicast group memberships the snooping switch
should also maintain a list of multicast routers. When forwarding
multicast packets they should be forwarded on ports which have
expressed joined using IGMP but also on ports on which multicast
routers are attached.
2.1. Problems in older networks
The drawback of using IGMP snooping switches to make the flooding of
multicast traffic more efficient is that the underlying link layer
topology is required to remain very stable. This is especially true
in IGMP versions 1 and 2 where group members do not transmit member-
ship report messages after having overheard a report from another
group member.
This problem can be demonstrated with an example. In the topology
illustrated in figure 2, a topology loop exists between four IGMP
snooping switches labeled A, B, C and D.
- The spanning tree algorithm would detect this loop and disable
one of the links; for example, the link connecting ports B3 and
Christensen, Solensky [Page 4]
RFC DRAFT February 2001
C1.
- Node N1 transmits a group membership report which will be flooded
throughout the network.
- When switch A hears the report, it determines that packets
addressed to the group should be forwarded to port A3.
- Router R hears the Join message and starts forwarding packets
with the multicast destination address into the network. Node N1
is now part of the group.
- The link between D2 and C2 is broken. The spanning tree algo-
rithm reactivates the blocked link B3-C1.
- If switch A relies solely on the exchange of IGMP messages to
alter its forwarding behavior, node N1 will be unable to receive
packets forwarded to the group address until router R sends out
another membership query request.
+------+ B2
B1 | |----- - - - +------+
-----| SS B | | Node |
/ | |----- / | N1 |
+--------+ A2 / +------+ B3 X C1 +------+ +--+---+
A1 | |----- / -----| | |
--+----| Switch | | SS C |-----+----
| | A |----- -----| | C3
+-+-+ +--------+ A3 \ +------+ D2 / C2 +------+
| R | \ D1 | |-----
++-++ -----| SS D |
| | | |---------+------ - - -
+------+ D3 |
+--+---+
| Node |
| N2 |
+------+
Figure 2
One possible approach to work around this limitation would be for the
switch to keep track of which nodes belong to the group, altering the
forwarding tables whenever a member becomes visible through a different
port. When switch A sees that node N1 has moved from port A3 to A2, the
group membership table would be updated. This does not work, however,
when more than one node joins the same group address when at least one
of them has not yet been upgraded to IGMPv3: if nodes N1 and N2 were to
join the group at approximately the same time, they would both start off
random timers for the transmission of their first membership report
Christensen, Solensky [Page 5]
RFC DRAFT February 2001
messages. If node N2 selects a longer interval than N1, it will hear
N1's report message and cancel the one it was about to send. Switch A,
therefore, never learns that node N2 has joined the group. When the
switch learns that N1 is now accessible through port A2, it has no way
of knowing that it should continue forwarding group packets to port A3
as well.
2.2. IGMPv2 snooping and 224.0.0.X
Special attention should be brought to the address range from
224.0.0.0 through 224.0.0.255 which is reserved for routing protocols
and other low-level topology discovery or maintenance protocols
[IANA]. Examples of reserved multicast addresses are:
224.0.0.2 All Routers on this Subnet
224.0.0.4 DVMRP
224.0.0.5 MOSPF
224.0.0.6 MOSPF
224.0.0.9 RIP2 Routers
224.0.0.13 PIM Routers
224.0.0.22 IGMPv3 Membership Reports
Multicast routers are discouraged from routing packets with a desti-
nation address falls within this range, regardless of the TTL value.
The router will be the originator or consumer of these messages so it
has less of a motivation to maintain forwarding path information for
these addresses. As a result, it becomes less critical for the
router to send out periodic Query messages for these groups. If the
router chooses not to the group would be unable to recover from
topology changes as described above. Note that the only difference
between the 'all hosts' address (224.0.0.1) and the remainder of this
range is that the router has no discretion in the former case: it
MUST NOT send Queries.
To avoid this situation, IGMP snooping switches should be less con-
servative when forwarding packets to these addresses and flood them
to all ports.
It is reported in [MSOFT] that a number of switches can be mis- con-
figured to perform IGMP snooping and forwarding for all IP multi-
cast groups.
Figure 3 illustrates one scenario where two routers R1 and R2 are
communicating using for example 224.0.0.6. The routers never send
IGMP joins for this address. The switch floods the (unknown) multi-
cast traffic on all ports.
Christensen, Solensky [Page 6]
RFC DRAFT February 2001
Now the server SVR is started and it sends an IGMP join for
224.0.0.6, which is snooped by the switch. It then generates a mem-
bership query on all ports to determine which ports have devices that
also belong to this group.
The routers R1 and R2 do not respond and the switch builds a forward-
ing port list with only SVR in it. Now R1 and R2 are not able to
communicate using this address.
+----+ +----------+
| R1 |-----| |
+----+ | Snooping | +-----+
| |----| SVR |
+----+ | switch | +-----+
| R2 |-----| |
+----+ +----------+
Figure 3.
There are two possible fixes to this problem: One is to require that
all routers (also being hosts) which use IP multicast responds to
IGMP queries in the range 224.0.0.X. This seems unnecessary as dis-
cussed above because of the inherent link local scope of these mes-
sages.
Another solution to this problem, which is also discussed above, is
that the switch is configured to forward all packets for a range of
IP multicast addresses to all ports (flooding).
It is suggested that all multicast packets in the range 224.0.0.1
through 224.0.0.255 are forwarded on all ports.
2.3. IGMPv2 and IGMPv3 coexistence
Consider the following sequence of communication (figure 4.):
- Router R sends IGMPv3 Query
- Host H1 sends IGMPv2 Report (since it has only implemented v2).
- switch S puts H1's port P1 in the flooding list.
- Host H2 sends IGMPv3 Report.
- Switch S fails to put H2's port P2 in the flooding list because
it doesn't support IGMPv3.
Christensen, Solensky [Page 7]
RFC DRAFT February 2001
- H2 never sees any traffic.
{{need to provide description of solution that allows this. Step 4
sounds wrong}}
2.4. Source Specific Joins
Even for IGMPv3 snooping capable switches there can be limitations
caused by link layer based forwarding. This is illustrated in figure
4.
Assume that host H1 sends a Join(S1, G) to R and that host H2 sends a
Join(S2, G) to R.
The switch adds both hosts to the forwarding list for group G.
Frames originating from sources S1 and S2 for the same multicast
address G are routed via R. These are sent from R with the router's
MAC address as source.
The switch is unable to distinguish the two different types of flow
and forwards both flows to both hosts. This effectively disables the
Join source functionality in this network configuration.
+----+ +----------+
| H1 |-----| |
+----+ | Snooping | +---+
| |----| R |---(S1, G) and (S2, G)
+----+ | switch | +---+
| H2 |-----| |
+----+ +----------+
Figure 4.
This is a problem without an obvious solution because of the differ-
ence between the link layer and the network layer information.
One approach would be for the switch to simply flood the packets to
both ports. This requires that the host implementations do not rely
on the router to perform all of the source address filtering for the
group address: they must still filter out packets that do not match
the source address criteria specified in the join messages. While
this might be seen as an inconvience, this is no different than the
case where the router is directly connected to both hosts on a shared
LAN and no snooping switch is present.
An alternative approach would be for the switch to further qualify
the search process by including source address when determining which
Christensen, Solensky [Page 8]
RFC DRAFT February 2001
ports should forward the packet. While this could work for very sim-
ple cases, it is unlikely that this approach could scale into more
complex topologies or provide satisfactory performance in even the
simple cases.
Similar problems occur with the attempt to exclude sources.
3. Snooping Requirements
The switch that provides support for IGMP packet snooping MUST for-
ward all unrecognized IGMP messages and MUST NOT attempt to make use
of any information beyond the end of the network layer header. In
particular, messages where any Reserved fields are non-zero MUST NOT
be snooped since this could indicate an incompatible change to the
message format.
If a switch receives a multicast packet without having first pro-
cessed Membership Reports for the group address, it MUST forward the
packet into all active network segments. In other words, the switch
must allow for the possibility that connected hosts and routers have
been upgraded to support future versions or extensions of IGMP that
the switch does not yet recognize. A switch MAY have a configuration
option that suppresses this operation, but default behavior MUST be
to allow flooding of unregistered packets.
In order to operate correctly, the switch supporting IGMP snooping
MUST also maintain a list of multicast routers. This list SHOULD be
built using IGMP Multicast Router Discovery [MRDISC] which is cur-
rently going through IETF Last Call. IGMP snooping switches MAY in
addition use information about which ports packets for the address
224.0.0.X range arrive, when
- The packets are IGMP Queries or
- The packets are anything but IGMP or
- The ports are manually configured as having multicast routers
attached
4. Security Considerations
Security considerations for IGMPv3 are accounted for in [IGMPv3].
The introduction of IGMP snooping switches adds the following consid-
erations with regard to IP multicast.
Christensen, Solensky [Page 9]
RFC DRAFT February 2001
The exclude source failure which could cause traffic from sources
that are 'black listed' to reach hosts that have requested otherwise.
This can also occur in certain network topologies without IGMP snoop-
ing.
It is possible to generate packets which make the switch wrongly
believe that there is a multicast router on the segment on which the
sender is attached. This will potentially lead to excessive flooding
on that segment. The authentication methods discussed in [IGMPv3]
will also provide protection in this case.
Generally though, it is worth to stress that IP multicast must so far
be considered insecure until the work of for example the suggested
Multicast Security (MSEC) working group or similar is completed or at
lease has matured.
5. References
[BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges"
[CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP
and IGMP snooping"
[IANA] Internet Assigned Numbers Authority, "Internet Multicast
Addresses", http://www.isi.edu/in-notes/iana/assign-
ments/multicast-addresses
[IGMPv3] Cain, B., "Internet Group Management Protocol, Version
3", draft-ietf-idmr-igmp-v3-06.txt, November 2000
[MRDISC] Biswas, S. "IGMP Multicast Router Discovery", draft-ietf-
idmr-igmp-mrdisc-05.txt, October 2000.
[MSOFT] Microsoft support article Q223136, "Some LAN Switches
with IGMP Snooping Stop Forwarding Multicast Packets on
RRAS Startup", http://support.microsoft.com/sup-
port/kb/articles/Q223/1/36.ASP
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC
1112, August 1989.
Christensen, Solensky [Page 10]
RFC DRAFT February 2001
[RFC2026] Bradner, S. "The Internet Standards Process -- Revision
3", RFC2026, October 1996.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC2236, November 1997.
6. Author's Addresses:
Morten Jagd Christensen
Exbit Technology
Hoerkaer 18
2730 Herlev
DENMARK
email: mjc@exbit.dk
Frank Solensky
Gotham Networks
15 Discovery Way
Acton, MA 01720
USA
email: fsolensky@GothamNetworks.com (effective 09 March 2001)
solensky@acm.org
Christensen, Solensky [Page 11]
RFC DRAFT February 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IGMP snooping overview . . . . . . . . . . . . . . . . . . . . . 2
2.1. Problems in older networks . . . . . . . . . . . . . . . . . . 4
2.2. IGMPv2 snooping and 224.0.0.X . . . . . . . . . . . . . . . . . 6
2.3. IGMPv2 and IGMPv3 coexistence . . . . . . . . . . . . . . . . . 7
2.4. Source Specific Joins . . . . . . . . . . . . . . . . . . . . . 8
3. Snooping Requirements . . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Author's Addresses: . . . . . . . . . . . . . . . . . . . . . . . 11
Christensen, Solensky [Page 12]
