< draft-ietf-magma-snoop-05.txt   draft-ietf-magma-snoop-06.txt >
Network Working Group M. Christensen Network Working Group M. Christensen
Internet Draft Thrane & Thrane Internet Draft Thrane & Thrane
Expiration Date: July 2003 K. Kimball Expiration Date: September 2003 K. Kimball
Category: Informational Hewlett-Packard Category: Informational Hewlett-Packard
F. Solensky F. Solensky
Bluejavelin Bluejavelin
January 2003 March 2003
Considerations for IGMP and MLD snooping switches Considerations for IGMP and MLD Snooping Switches
<draft-ietf-magma-snoop-05.txt> <draft-ietf-magma-snoop-06.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026]. all provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This memo describes the requirements for IGMP- and MLD-snooping This memo describes the requirements for IGMP- and MLD-snooping
switches. These are based on best current practices for IGMPv2, switches. These are based on best current practices for IGMPv2,
with further considerations for IGMPv3- and MLDv2-snooping. Addi- with further considerations for IGMPv3- and MLDv2-snooping.
tional areas of relevance, such as link layer topology changes and Additional areas of relevance, such as link layer topology changes
Ethernet-specific encapsulation issues, are also considered. and Ethernet-specific encapsulation issues, are also considered.
Interoperability issues that arise between different versions of Interoperability issues that arise between different versions of
IGMP are not the focus of this document. Interested readers are IGMP are not the focus of this document. Interested readers are
directed to [IGMPv3] for a thorough description of problem areas. directed to [IGMPv3] for a thorough description of problem areas.
This document is intended to accompany the IGMPv3 and MLDv2
RFC DRAFT January 2003
specifications.
1. Introduction 1. Introduction
When a packet with a broadcast or multicast destination address is When processing a packet whose destination MAC address has the
received, the switch will forward a copy into each of the remaining multicast bit (bit 7) set, the switch will forward a copy of the
network segments in accordance with [BRIDGE]. Eventually, the packet into each of the remaining network interfaces that are the
packet is made accessible to all nodes connected to the network. forwarding state in accordance with [BRIDGE]. The spanning tree
algorithm ensures that the application of this rule at every switch
in the network will make the packet accessible to all nodes
connected to the network.
This approach works well for broadcast packets that are intended to This approach works well for broadcast packets that are intended to
be seen or processed by all connected nodes. In the case of multi- be seen or processed by all connected nodes. In the case of
cast packets, however, this approach could lead to less efficient multicast packets, however, this approach could lead to less
use of network bandwidth, particularly when the packet is intended efficient use of network bandwidth, particularly when the packet is
for only a small number of nodes. Packets will be flooded into intended for only a small number of nodes. Packets will be flooded
network segments where no node has any interest in receiving the into network segments where no node has any interest in receiving
packet. While nodes will rarely incur any processing overhead to the packet. While nodes will rarely incur any processing overhead
filter packets addressed to unrequested group addresses, they are to filter packets addressed to unrequested group addresses, they
unable to transmit new packets onto the shared media for the period are unable to transmit new packets onto the shared media for the
of time that the multicast packet is flooded. In general, signifi- period of time that the multicast packet is flooded. In general,
cant bandwidth can be wasted by flooding. significant bandwidth can be wasted by flooding.
In recent years, a number of commercial vendors have introduced In recent years, a number of commercial vendors have introduced
products described as "IGMP snooping switches" to the market. products described as "IGMP snooping switches" to the market.
These devices do not adhere to the conceptual model that provides These devices do not adhere to the conceptual model that provides
the strict separation of functionality between different communica- the strict separation of functionality between different
tions layers in the ISO model, and instead utilize information in communications layers in the ISO model, and instead utilize
the upper- level protocol headers as factors to be considered in information in the upper level protocol headers as factors to be
the processing at the lower levels. This is analogous to the man- considered in the processing at the lower levels. This is
ner in which a router can act as a firewall by looking into the analogous to the manner in which a router can act as a firewall by
transport protocol's header before allowing a packet to be for- looking into the transport protocol's header before allowing a
warded to its destination address. packet to be forwarded to its destination address.
In the case of multicast traffic, an IGMP snooping switch provides In the case of multicast traffic, an IGMP snooping switch provides
the benefit of conserving bandwidth on those segments of the net- the benefit of conserving bandwidth on those segments of the
work where no node has expressed interest in receiving packets network where no node has expressed interest in receiving packets
addressed to the group address. This is in contrast to normal addressed to the group address. This is in contrast to normal
switch behavior where multicast traffic is typically forwarded on switch behavior where multicast traffic is typically forwarded on
all interfaces. all interfaces.
Many switch datasheets state support for IGMP snooping, but no Many switch datasheets state support for IGMP snooping, but no
requirements for this exist today. It is the authors' hope that requirements for this exist today. It is the authors' hope that
the information presented in this draft will supply this founda- the information presented in this draft will supply this
tion. foundation.
The requirements presented here are based on the following informa-
tion sources: The IGMP specifications [RFC112][RFC2236][IGMPv3],
vendor-supplied technical documents [CISCO], bug reports [MSOFT],
RFC DRAFT January 2003
discussions with people involved in the design of IGMP snooping The requirements presented here are based on the following
switches, MAGMA mailinglist discussions, and on replies by switch information sources: The IGMP specifications [RFC1112], [RFC2236]
vendors to an implementation questionnaire. and [IGMPv3], vendor-supplied technical documents [CISCO], bug
reports [MSOFT], discussions with people involved in the design of
IGMP snooping switches, MAGMA mailing list discussions, and on
replies by switch vendors to an implementation questionnaire.
The discussions in this document are based on IGMP, which applies The suggestions in this document are based on IGMP, which applies
only to IPv4. For IPv6, MLD must be used instead. Because MLD is only to IPv4. For IPv6, Multicast Listener Discovery [MLD] must be
based on IGMP, we do not repeat the whole discussion and require- used instead. Because MLD is based on IGMP, we do not repeat the
ments for MLD snooping switches. Instead, we point out the few entire description and requirements for MLD snooping switches.
cases where there are differences from IGMP. Instead, we point out the few cases where there are differences
from IGMP.
Note that the IGMP snooping function should apply only to IPv4 mul- Note that the IGMP snooping function should apply only to IPv4
ticasts. Other multicast packets, such as IPv6, might be suppressed multicasts. Other multicast packets, such as IPv6, might be
by IGMP snooping if additional care is not taken in the implementa- suppressed by IGMP snooping if additional care is not taken in the
tion. It is desired not to restrict the flow of non-IPv4 multi- implementation. It is desired not to restrict the flow of non-IPv4
casts other than to the degree which would happen as a result of multicasts other than to the degree which would happen as a result
regular bridging functions. The same note can be made of MLD snoop- of regular bridging functions. Likewise, MLD snooping switches are
ing switches with respect to suppression of IPv4. discouraged from using topological information learned from IPv6
traffic to alter the forwarding of IPv4 multicast packets.
2. IGMP Snooping Requirements 2. IGMP Snooping Requirements
The following sections list the requirements for an IGMP snooping The following sections list the requirements for an IGMP snooping
switch. The requirement is stated and is supplemented by a discus- switch. The requirement is stated and is supplemented by a
sion. All implementation discussions are examples only and there description of a possible implementation approach. All
may well be other ways to achieve the same functionality. implementation discussions are examples only and there may well be
other ways to achieve the same functionality.
2.1. Forwarding rules 2.1. Forwarding rules
The IGMP snooping functionality is here separated into a control The IGMP snooping functionality is here separated into a control
section (IGMP forwarding) and a data section (Data forwarding). section (IGMP forwarding) and a data section (Data forwarding).
2.1.1. IGMP Forwarding Rules 2.1.1. IGMP Forwarding Rules
1) A snooping switch should forward IGMP Membership Reports only 1) A snooping switch should forward IGMP Membership Reports only
to those ports where multicast routers are attached. Alterna- to those ports where multicast routers are attached.
tively stated: a snooping switch should not forward IGMP Mem- Alternatively stated: a snooping switch should not forward IGMP
bership Reports to ports on which only hosts are attached. An Membership Reports to ports on which only hosts are attached.
administrative control may be provided to override this An administrative control may be provided to override this
restriction, allowing the report messages to be flooded to restriction, allowing the report messages to be flooded to
other ports. other ports.
This is the main IGMP snooping functionality. Sending member- This is the main IGMP snooping functionality. Sending
ship reports (as described in IGMP versions 1 and 2) to other membership reports (as described in IGMP versions 1 and 2) to
hosts can result in unintentionally preventing a host from other hosts can result in unintentionally preventing a host
joining a specific multicast group. This is not a problem in from joining a specific multicast group. This is not a problem
in an IGMPv3-only network because there is no message
RFC DRAFT January 2003 suppression of IGMP Membership reports.
an IGMPv3-only network because there is no cancellation of IGMP
Membership reports.
The administrative control allows IGMP Membership Report mes- The administrative control allows IGMP Membership Report
sages to be processed by network monitoring equipment such as messages to be processed by network monitoring equipment such
packet analyzers or port replicators. as packet analyzers or port replicators.
The switch supporting IGMP snooping must maintain a list of The switch supporting IGMP snooping must maintain a list of
multicast routers and the ports on which they are attached. multicast routers and the ports on which they are attached.
This list can be constructed in any combination of the follow- This list can be constructed in any combination of the
ing ways: following ways:
a) This list should be built by the snooping switch sending a) This list should be built by the snooping switch sending
Multicast Router Solicitation messages as described in IGMP Multicast Router Solicitation messages as described in IGMP
Multicast Router Discovery [MRDISC]. It may also snoop Multicast Router Discovery [MRDISC]. It may also snoop
Multicast Router Advertisement messages sent by and to Multicast Router Advertisement messages sent by and to
other nodes. other nodes.
b) The arrival port for IGMP Queries (sent by multicast b) The arrival port for IGMP Queries (sent by multicast
routers) where the source address is not 0.0.0.0. routers) where the source address is not 0.0.0.0.
c) Ports explicitly configured by management to be IGMP-for- c) Ports explicitly configured by management to be IGMP-
warding ports, in addition to or instead of any of the forwarding ports, in addition to or instead of any of the
above methods to detect router ports. above methods to detect router ports.
2) IGMP snooping switches may also implement "proxy-reporting" in 2) IGMP snooping switches may also implement "proxy-reporting" in
which reports received from downstream hosts are summarized and which reports received from downstream hosts are summarized and
used to build internal membership states as described in used to build internal membership states as described in
[PROXY]. The IGMP proxy-reporting switch would then report its [PROXY]. The IGMP proxy-reporting switch would then report its
own state in response to upstream queriers. If the switch does own state in response to upstream queriers. If the switch does
not already have an IP address assigned to it, the source not already have an IP address assigned to it, the source
address for these reports should be set to all-zeros. address for these reports should be set to all-zeros.
An IGMP proxy-reporting switch may act as Querier for the down- An IGMP proxy-reporting switch may act as Querier for the
stream hosts while proxy reporting to the 'real' upstream downstream hosts while proxy reporting to the 'real' upstream
queriers. queriers.
It should be noted that there may be multiple IGMP proxy- It should be noted that there may be multiple IGMP proxy-
reporting switches in the network all using the 0.0.0.0 source reporting switches in the network all using the 0.0.0.0 source
IP address. In this case the switches can be uniquely identi- IP address. In this case the switches can be uniquely
fied through their link layer source MAC address. identified through their link layer source MAC address.
IGMP membership reports must not be rejected because of a
source IP address of 0.0.0.0.
3) The switch that supports IGMP snooping must flood all unrecog-
nized IGMP messages to all other ports and must not attempt to
make use of any information beyond the end of the network layer
RFC DRAFT January 2003 IGMP membership reports must not be rejected by an IGMP
snooping switch because of a source IP address of 0.0.0.0.
header. 3) The switch that supports IGMP snooping must flood all
unrecognized IGMP messages to all other ports and must not
attempt to make use of any information beyond the end of the
network layer header.
In addition, earlier versions of IGMP should interpret IGMP In addition, earlier versions of IGMP should interpret IGMP
fields as defined for their versions and must not alter these fields as defined for their versions and must not alter these
fields when forwarding the message. When generating new mes- fields when forwarding the message. When generating new
sages, a given IGMP version should set fields to the appropri- messages, a given IGMP version should set fields to the
ate values for its own version. If any fields are reserved or appropriate values for its own version. If any fields are
otherwise undefined for a given IGMP version, the fields should reserved or otherwise undefined for a given IGMP version, the
be ignored when parsing the message and must be set to zeroes fields should be ignored when parsing the message and must be
when new messages are generated by implementations of that IGMP set to zeroes when new messages are generated by
version. implementations of that IGMP version.
4) An IGMP snooping switch should be aware of link layer topology 4) An IGMP snooping switch should be aware of link layer topology
changes. Following a topology change the switch should initi- changes. Following a topology change the switch should
ate the transmission of a General Query on all ports in order initiate the transmission of a General Query over the receiving
to reduce network convergence time. If the switch is not the ports in order to reduce network convergence time.
Querier, it should use the 'all-zeros' IP Source Address in
these proxy queries. When such proxy queries are received, a) When a port other than the router port goes down, a Query
they must not be included in the Querier election process. Request should be directed out the switch's remaining non-
router ports for those group addresses which had included
the lost port as a destination for flooded packets. The
Query may be one of the Group-Specific forms if there are
a relatively small number of groups affected and should be
a General Query otherwise. The router port should be
excluded from receiving these Query Requests since it will
usually be the source rather than the receipient of
flooded multicast packets and is less likely to be
affected by the loss of one of the receiver ports.
b) When the router port goes down, Multicast Router Discovery
should be used to determine which of the remaining ports
is the new router port. An IGMPv3 General Query message
should be sent out the remaining ports to refresh the
forwarding tables for other groups.
c) When a new port comes up, a General Query message should
be sent out the new port to determine which groups, if
any, have receipients that have become reachable. The new
port is designated as a router port in MRD messages are
processed.
If the switch is not the Querier, it should use the 'all-zeros'
IP Source Address in these proxy queries. When such proxy
queries are received, they must not be included in the Querier
election process.
5) An IGMP snooping switch must not make use of information in 5) An IGMP snooping switch must not make use of information in
IGMP packets where the IP or IGMP headers have checksum or IGMP packets where the IP or IGMP headers have checksum or
integrity errors. The switch should not flood such packets but integrity errors. The switch should not flood such packets but
if it does, it should take some note of the event (i.e., incre- if it does, it should also take some note of the event (i.e.,
ment a counter). These errors and their processing are further increment a counter). These errors and their processing are
discussed in [IGMPv3], [MLD] and [MLDv2]. further discussed in [IGMPv3], [MLD] and [MLDv2].
6) The snooping switch must not rely exclusively on IGMP group
leave announcements to determine when entries should be removed
from the forwarding table. The snooping switch should imple-
ment a membership timeout feature to ensure unneeded forwarding
table entries will be appropriately removed if downstream mem-
bers silently leave the group or become unavailable for any
reason. If the switch implements this timeout behavior, it must
have a feature to override it if the switch is also configured
to forward unregistered multicast packets on all ports. Addi-
tionally, if timeout is implemented, a group's forwarding table
entry should be removed from a port when no IGMP report has
been received for [(Query Interval x Number of Queries) + Query
Response Time] seconds. These variables may be learned dynami-
cally but IGMP snooping switches implementing timeout should
have a configuration option that allows these variables to be
set manually.
RFC DRAFT January 2003 6) The snooping switch must not rely exclusively on the appearance
of IGMP Group Leave announcements to determine when entries
should be removed from the forwarding table. It should instead
implement the router side functionality of the IGMP/MLD
protocol as described in [PROXY] on all its non-router ports.
2.1.2. Data Forwarding Rules 2.1.2. Data Forwarding Rules
1) Packets with a destination IP (DIP) address in the 224.0.0.X 1) Packets with a destination IP (DIP) address in the 224.0.0.X
range which are not IGMP must be forwarded on all ports. range which are not IGMP must be forwarded on all ports.
This requirement is based on fact that many hosts exist today This requirement is based on fact that many hosts systems do
which do not Join IP multicast addresses in this range before not send Join IP multicast addresses in this range before
sending or listening to IP multicasts. Furthermore since the sending or listening to IP multicast packets. Furthermore
224.0.0.X address range is defined as link local (not to be since the 224.0.0.X address range is defined as link local (not
routed) it seems unnecessary to keep state for each address in to be routed) it seems unnecessary to keep state for each
this range. Additionally, some vendors' applications, which address in this range. Additionally, some routers operate in
are not IGMP, use this 224.0.0.X address range, and these the 224.0.0.X address range without issuing IGMP Joins, and
applications would break if the switch were to prune them due these applications would break if the switch were to prune them
to not seeing a Join. due to not their not having seen a Join Group message from the
router.
2) Packets with a destination IP address outside 224.0.0.X which 2) Packets with a destination IP address outside 224.0.0.X which
are not IGMP should be forwarded according to group-based port are not IGMP should be forwarded according to group-based port
membership tables and must also be forwarded on router ports. membership tables and must also be forwarded on router ports.
This is the core IGMP snooping requirement for the data path. This is the core IGMP snooping requirement for the data path.
One approach that an implementation could take would be to
maintain separate membership and multicast router tables in
software and then "merge" these tables into a forwarding cache.
Discussion: An implementation could maintain separate member- 3) If a switch receives a non-IGMP IPv4 multicast packet without
ship and multicast router tables in software and then "merge"
these tables into a current forwarding cache.
3) If a switch receives a non-IGMP IPV4 multicast packet without
having first processed Membership Reports for the group having first processed Membership Reports for the group
address, it may forward the packet on all ports, but it must address, it may forward the packet on all ports but it must
forward the packet on router ports. A switch may forward an forward the packet on router ports. A switch may forward an
unregistered packet only on router ports, but the switch must unregistered packet only on router ports, but the switch must
have a configuration option that suppresses this restrictive have a configuration option that suppresses this restrictive
operation and forces flooding of unregistered packets on all operation and forces flooding of unregistered packets on all
ports. In environments with v3 hosts where the snooping switch ports.
does not support v3, failure to flood unregistered streams
could prevent v3 hosts from receiving their traffic. Alterna-
tively, in environments where the snooping switch supports all
of the IGMP versions that are present, flooding unregistered
streams may cause IGMP hosts to be overwhelmed by multicast
traffic, even to the point of not receiving Queries and failing
to issue new membership reports for their own groups.
4) All non-IPv4 multicast packets should be flooded, except where In an environment where IGMPv3 hosts are mixed with snooping
normal IEEE bridging operation would result in filtering multi- switches that do not yet support IGMPv3, the switch's failure
cast packets. Discussion: This ensures that enabling IGMP to flood unregistered streams could prevent v3 hosts from
snooping does not break, for example, IPv6 multicast. receiving their traffic. Alternatively, in environments where
the snooping switch supports all of the IGMP versions that are
present, flooding unregistered streams may cause IGMP hosts to
be overwhelmed by multicast traffic, even to the point of not
receiving Queries and failing to issue new membership reports
for their own groups.
5) IGMP snooping switches may maintain forwarding tables based on 4) All non-IPv4 multicast packets should continue to be flooded
either MAC addresses or IP addresses. If a switch supports out all remaining ports in the forwarding state as per normal
IEEE bridging operations.
RFC DRAFT January 2003 This requirement is a result of the fact that groups made up of
IPv4 hosts and IPv6 hosts are completely separate and distinct
groups. As a result, information gleaned from the topology
between members of an IPv4 group would not be applicable when
forming the topology between members of an IPv6 group.
5) IGMP snooping switches may maintain forwarding tables based on
either MAC addresses or IP addresses. If a switch supports
both types of forwarding tables then the default behavior both types of forwarding tables then the default behavior
should be to use IP addresses. should be to use IP addresses. If the forwarding table is
keyed on the MAC address, the switch should use the destination
Discussion: Forwarding based on MAC addresses is subject to the IP address to break hashing table collisions.
problem associated with the 32-fold IP address to 1 MAC address
mapping.
6) Switches which rely on information in the IP header should ver- 6) Switches which rely on information in the IP header should
ify that the IP header checksum is correct. If the checksum verify that the IP header checksum is correct. If the checksum
fails, the information in the packet must not be incorporated fails, the information in the packet must not be incorporated
into the forwarding table. Further, the packet should be dis- into the forwarding table. Further, the packet should be
carded. discarded.
7) When IGMPv3 "include source" and "exclude source" membership 7) When IGMPv3 "include source" and "exclude source" membership
reports are received on shared segments, the switch needs to reports are received on shared segments, the switch needs to
forward the superset of all received membership reports onto forward the superset of all received membership reports onto
the shared segment. Forwarding of traffic from a particular the shared segment. Forwarding of traffic from a particular
source S to a group G must happen if at least one host on the source S to a group G must happen if at least one host on the
shared segment reports an IGMPv3 membership of the type shared segment reports an IGMPv3 membership of the type
INCLUDE(G, Slist1) or EXCLUDE(G, Slist2) where S is an element INCLUDE(G, Slist1) or EXCLUDE(G, Slist2) where S is an element
of Slist1 and not an element of Slist2. of Slist1 and not an element of Slist2.
2.2. IGMP snooping related problems 2.2. IGMP snooping related problems
A special problem arises in networks consisting of IGMPv3 routers A special problem arises in networks consisting of IGMPv3 routers
as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2 as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2
snooping switch. The router will continue to maintain IGMPv3 even snooping switch. The router will continue to maintain IGMPv3 even
in the presence of IGMPv2 hosts, and thus the network will not in the presence of IGMPv2 hosts, and thus the network will not
likely converge on IGMPv2. But it is likely that the IGMPv2 snoop- likely converge on IGMPv2. But it is likely that the IGMPv2
ing switch will not recognize or process the IGMPv3 membership snooping switch will not recognize or process the IGMPv3 membership
reports. Groups for these unrecognized reports will then either be reports. Groups for these unrecognized reports will then either be
flooded (with all of the problems that may create for hosts in a flooded (with all of the problems that may create for hosts in a
network with a heavy multicast load) or pruned by the snooping network with a heavy multicast load) or pruned by the snooping
switch. switch.
Therefore it is recommended that in such a network, the multicast Therefore it is recommended that in such a network, the multicast
router be configured to use IGMPv2. router be configured to use IGMPv2.
3. IPv6 Considerations 3. IPv6 Considerations
In order to avoid confusion, the previous discussions have been In order to avoid confusion, the previous discussions have been
based on the IGMP protocol which only applies to IPv4 multicast. based on the IGMP protocol which only applies to IPv4 multicast.
In the case of IPv6 most of the above discussions are still valid In the case of IPv6 most of the above discussions are still valid
with a few exceptions which we will describe here. with a few exceptions which we will describe here.
RFC DRAFT January 2003
The control and data forwarding rules in the IGMP section can, with The control and data forwarding rules in the IGMP section can, with
a few considerations, also be applied to MLD. This means that the a few considerations, also be applied to MLD. This means that the
basic functionality of intercepting MLD packets, and building mem- basic functionality of intercepting MLD packets, and building
bership lists and multicast router lists, is the same as for IGMP. membership lists and multicast router lists, is the same as for
IGMP.
In IPv6, the data forwarding rules are more straight forward In IPv6, the data forwarding rules are more straight forward
because MLD is mandated for addresses with scope 2 (link-scope) or because MLD is mandated for addresses with scope 2 (link-scope) or
greater. The only exception is the address FF02::1 which is the greater. The only exception is the address FF02::1 which is the
all hosts link-scope address for which MLD messages are never sent. all hosts link-scope address for which MLD messages are never sent.
Packets with the all hosts link-scope address should be forwarded Packets with the all hosts link-scope address should be forwarded
on all ports. on all ports.
MLD messages are also not sent to packets in the address range MLD messages are also not sent to packets in the address range
FF0X::/16 when X is 0 or 1 (which are reserved and node-local, FF00::/15 (which encompasses both the reserved FF00::/16 and node-
respectively), and these addresses should never appear in packets local FF01::/16 IPv6 address spaces). These addresses should never
on the link. appear in packets on the link.
The three main differences between IPv4 and IPv6 in relation to The three major differences between IPv4 and IPv6 in relation to
multicast are: multicast are:
- The IPv6 protocol for multicast group maintenance is called Mul- - The IPv6 protocol for multicast group maintenance is called
ticast Listener Discovery (MLDv2). MLDv2 uses ICMPv6 message Multicast Listener Discovery [MLDv2]. MLDv2 uses ICMPv6 message
types instead of IGMP message types. types instead of IGMP message types.
- The ethernet encapsulation is a mapping of 32 bits of the 128 - The RFCs [IPV6-ETHER] and [IPV6-FDDI] describe how 24 of the 128
bit DIP addresses into 48 bit DMAC addresses [IPENCAPS]. bit DIP address are used to form the 48 bit DMAC addresses for
multicast groups, while [IPV6-TOKEN] describes the mapping for
token ring DMAC addresses by using three low-order bits. The
specification [IPV6-1394] makes use of a 6 bit channel number.
- Multicast router discovery is done using Neighbor Discovery Pro- - Multicast router discovery is accomplished using Neighbor
tocol (NDP) for IPv6. NDP uses ICMPv6 message types. Discovery Protocol [NDP] for IPv6. NDP uses ICMPv6 message
types.
The IPv6 packet header does not include a checksum field. Never- The IPv6 packet header does not include a checksum field.
theless, the switch should detect other packet integrity issues. Nevertheless, the switch should detect other packet integrity
When the snooping switch detects such an error, it must not include issues. When the snooping switch detects such an error, it must
information from the corresponding packet in the MLD forwarding ta- not include information from the corresponding packet in the MLD
ble. The forwarding code should drop the packet and take further forwarding table. The forwarding code should instead drop the
reasonable actions as advocated above. packet and take further reasonable actions as advocated above.
The fact that MLDv2 is using ICMPv6 adds new requirements to a The fact that MLDv2 is using ICMPv6 adds new requirements to a
snooping switch because ICMPv6 has multiple uses aside from MLD. snooping switch because ICMPv6 has multiple uses aside from MLD.
This means that it is no longer sufficient to detect that the next- This means that it is no longer sufficient to detect that the next-
header field of the IP header is ICMPv6 in order to identify pack- header field of the IP header is ICMPv6 in order to identify
ets relevant for MLD snooping. packets relevant for MLD snooping. A software-based implemention
which treats all ICMPv6 packets as candidates for MLD snooping
Discussion: If an implementation was software-based, wrongly iden- could easily fill its receive queue and bog down the CPU with
tifying non-MLD packets as candidates for MLD snooping would poten- irrelevant packets. This would prevent the snooping functionality
tially fill the CPU queue with irrelevant packets thus preventing from performing its intended purpose and the non-MLD packets
the snooping functionality. Furthermore, ICMPv6 packets destined destined for other hosts could be lost.
for other hosts would not reach their destinations.
RFC DRAFT January 2003
A solution is either to require that the snooping switch looks fur- A solution is either to require that the snooping switch looks
ther into the packets, or to be able to detect a multicast DMAC further into the packets, or to be able to detect a multicast DMAC
address in conjunction with ICMPv6. The first solution is desir- address in conjunction with ICMPv6. The first solution is
able only if it is configurable which message types should trigger desirable when a configuration option allows the administrator to
a CPU redirect and which should not. The reason is that a hardcod- specify which ICMPv6 message types should trigger a CPU redirect
ing of message types is inflexible for the introduction of new mes- and which should not. The reason is that a hardcoding of message
sage types. The second solution introduces the risk of new proto- types is inflexible for the introduction of new message types. The
cols which use ICMPv6 and multicast DMAC addresses but which are second solution introduces the risk that new protocols which use
not related to MLD, wrongly being identified as MLD. It is sug- ICMPv6 and multicast DMAC addresses could be incorrectly identified
gested that solution one is preferred if the switch is capable of as MLD. It is suggested that solution one is preferred when the
triggering CPU redirects on individual ICMPv6 message types. If administrative switch is provided. If this is not the case, then
this is not the case, then use solution two. the implementator should seriously consider making this switch
available since Neighbor Discovery messages would be among those
that fall into this false positive case and are vital for the
operational integrity of IPv6 networks.
The mapping from IP multicast addresses to multicast DMAC addresses The mapping from IP multicast addresses to multicast DMAC addresses
introduces a potentially enormous overlap. The structure of an introduces a potentially enormous overlap. The structure of an
IPv6 multicast address is shown in the figure below. Theoretically IPv6 multicast address is shown in the figure below. As a result,
2**80, two to the power of 80 (128 - 8 - 4 - 4 - 32) unique DIP there are 2 ** (112 - (32 - 8)), or more than 7.9e28 unique DIP
addresses could map to one DMAC address. This should be compared addresses which map into a single DMAC address in Ethernet and
to 2**5 in the case of IPv4. FDDI. This should be compared to 2**5 in the case of IPv4.
Initial allocation of IPv6 multicast addresses, however, uses only
the lower 32 bits of group ID. This eliminates the address ambigu-
ity for the time being, but it should be noted that the allocation
policy may change in the future. Because of the potential overlap
it is recommended that IPv6 address based forwarding is preferred
to MAC address based forwarding.
| 8 | 4 | 4 | 112 bits |
+--------+----+----+---------------------------------------+
|11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------+
4. Normative References
[BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges"
[IGMPv3] Cain, B., "Internet Group Management Protocol, Version
3", RFC3376, October 2002.
[IPENCAPS] Crawford, M., "Transmission of IPv6 Packets over Ether-
net Networks", RFC2464, December 1998.
[MLD] Deering, S., Fenner, B., and Haberman, B. "Multicast
Listener Discovery (MLD) for IPv6", RFC2710, October
1999.
RFC DRAFT January 2003
[MLDv2] Vida, R., "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", draft-vida-mld-v2-06.txt, November
2002.
[MRDISC] Biswas, S. "IGMP Multicast Router Discovery", draft-
ietf-idmr-igmp-mrdisc-10.txt, January 2003.
[PROXY] Fenner, B. et al, "IGMP-based Multicast Forwarding
(IGMP Proxying)", draft-ietf-magma-igmp-proxy-01.txt,
November 2002.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC
1112, August 1989.
[RFC2026] Bradner, S. "The Internet Standards Process -- Revision
3", RFC2026, October 1996.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC2236, November 1997.
[RFC2375] Hinden, R. "IPv6 Multicast Address Assignments",
RFC2375, July 1998.
5. Informative References
[IANA]
Internet Assigned Numbers Authority, "Internet Multicast
Addresses", http://www.isi.edu/in-notes/iana/assignments/mul-
ticast-addresses
[CISCO]
Cisco Tech Notes, "Multicast In a Campus Network: CGMP and
IGMP snooping", http://www.cisco.com/warp/public/473/22.html
[MSOFT]
Microsoft support article Q223136, "Some LAN Switches with
IGMP Snooping Stop Forwarding Multicast Packets on RRAS
Startup", http://support.microsoft.com/support/kb/arti-
cles/Q223/1/36.ASP
6. Security Considerations
Security considerations for IGMPv3 are accounted for in [IGMPv3].
The introduction of IGMP snooping switches adds the following con-
siderations with regard to IP multicast.
RFC DRAFT January 2003
1) 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 with-
out IGMP snooping.
2) It is possible to generate packets which make the switch wrongly
believe that there is a multicast router on the segment on which
the source 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.
3) IGMP snooping switches which rely on the IP header of a packet
for their operation and which do not validate the header checksum
potentially will forward packets on the wrong ports. Even though
the IP headers are protected by the ethernet checksum this is a
potential vulnerability.
4) In IGMP, there is no mechanism for denying recipients access to Initial allocation of IPv6 multicast addresses as described in
groups (i.e. no "exclude receiver" functionality). Hence, apart [RFC2735], however, cover only the lower 24 bits of group ID.
from IP-level security configuration outside the scope of IGMP, any While this reduces the problem of address ambiguity to group IDs
multicast stream may be received by any host without restriction. with different flag and scope values for now, it should be noted
that the allocation policy may change in the future. Because of
the potential overlap it is recommended that IPv6 address based
forwarding is preferred to MAC address based forwarding.
Generally, IGMP snooping must be considered insecure due to the | 8 | 4 | 4 | 112 bits |
issues above. However, none of the these issues are any worse for +--------+----+----+---------------------------------------+
IGMP snooping than for IGMP implementations in general. |11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------+
7. IGMP Questionnaire 4. IGMP Questionnaire
As part of this work the following questions were asked both on the As part of this work the following questions were asked both on the
MAGMA discussion list and sent to known switch vendors implementing MAGMA discussion list and sent to known switch vendors implementing
IGMP snooping. The individual contributions have been anonymized IGMP snooping. The individual contributions have been anonymized
upon request and do not necessarily apply to all of the vendors' upon request and do not necessarily apply to all of the vendors'
products. products.
The questions were: The questions were:
Q1 Does your switches perform IGMP Join aggregation? In other Q1 Does your switches perform IGMP Join aggregation? In other
words, are IGMP joins intercepted, absorbed by the hard- words, are IGMP joins intercepted, absorbed by the
ware/software so that only one Join is forwarded to the hardware/software so that only one Join is forwarded to the
querier? querier?
Q2 Is multicast forwarding based on MAC addresses? Would data- Q2 Is multicast forwarding based on MAC addresses? Would
grams addressed to multicast IP addresses 224.1.2.3 and datagrams addressed to multicast IP addresses 224.1.2.3 and
239.129.2.3 be forwarded on the same ports-groups? 239.129.2.3 be forwarded on the same ports-groups?
Q3 Is it possible to forward multicast datagrams based on IP Q3 Is it possible to forward multicast datagrams based on IP
addresses (not routed)? In other words, could 224.1.2.3 and addresses (not routed)? In other words, could 224.1.2.3 and
239.129.2.3 be forwarded on different port-groups with
RFC DRAFT January 2003 unaltered TTL?
239.129.2.3 be forwarded on different port-groups with unal-
tered TTL?
Q4 Are multicast datagrams within the range 224.0.0.1 to Q4 Are multicast datagrams within the range 224.0.0.1 to
224.0.0.255 forwarded on all ports whether or not IGMP Joins 224.0.0.255 forwarded on all ports whether or not IGMP Joins
have been sent? have been sent?
Q5 Are multicast frames within the MAC address range Q5 Are multicast frames within the MAC address range
01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports 01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports
whether or not IGMP joins have been sent? whether or not IGMP joins have been sent?
Q6 Does your switch support forwarding to ports on which IP multi- Q6 Does your switch support forwarding to ports on which IP
cast routers are attached in addition to the ports where IGMP multicast routers are attached in addition to the ports where
Joins have been received? IGMP Joins have been received?
Q7 Is your IGMP snooping functionality fully implemented in hard- Q7 Is your IGMP snooping functionality fully implemented in
ware? hardware?
Q8 Is your IGMP snooping functionality partly software imple- Q8 Is your IGMP snooping functionality partly software
mented? implemented?
Q9 Can topology changes (for example spanning tree configuration Q9 Can topology changes (for example spanning tree configuration
changes) be detected by the IGMP snooping functionality so that changes) be detected by the IGMP snooping functionality so that
for example new queries can be sent or tables can be updated to for example new queries can be sent or tables can be updated to
ensure robustness? ensure robustness?
The answers were: The answers were:
---------------------------+-----------------------+ ---------------------------+-----------------------+
| Switch Vendor | | Switch Vendor |
skipping to change at page 12, line 50 skipping to change at page 11, line 33
Q1 Join aggregation | x | x | x | | x | x | Q1 Join aggregation | x | x | x | | x | x |
Q2 Layer-2 forwarding | x | x | x | x |(1)| | Q2 Layer-2 forwarding | x | x | x | x |(1)| |
Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x | Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x |
Q4 224.0.0.X aware |(1)| x |(1)|(2)| x | x | Q4 224.0.0.X aware |(1)| x |(1)|(2)| x | x |
Q5 01:00:5e:00:00:XX aware | x | x | x |(2)| x | x | Q5 01:00:5e:00:00:XX aware | x | x | x |(2)| x | x |
Q6 Mcast router list | x | x | x | x | x | x | Q6 Mcast router list | x | x | x | x | x | x |
Q7 Hardware implemented | | | | | | | Q7 Hardware implemented | | | | | | |
Q8 Software assisted | x | x | x | x | x | x | Q8 Software assisted | x | x | x | x | x | x |
Q9 Topology change aware | x | x | x | x | |(2)| Q9 Topology change aware | x | x | x | x | |(2)|
---------------------------+---+---+---+---+---+---+ ---------------------------+---+---+---+---+---+---+
x Means that the answer was Yes. x Means that the answer was Yes.
(1) In some products (typically high-end) Yes, in others No. (1) In some products (typically high-end) Yes; in others No.
(2) Currently no, but will be really soon. (2) Not at the time that the questionnaire was received
but expected in the near future.
RFC DRAFT January 2003 Revision History
8. IETF IPR Statement This section, while incomplete, is provided as a convenience to the
working group members. It will be removed when the document is
released in its final form.
"The IETF takes no position regarding the validity or scope of any draft-ietf-magma-snoop-06.txt: March 2003
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such pro-
prietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat."
9. Acknowledgements Changes in response to comments made during WG last call and
assessment by the WG chairs:
We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben Carter, Substantial comments
Paul Congdon, Toerless Eckert, Bill Fenner, Brian Haberman, Edward Clarification in IGMP forwarding seciton on the
Hilquist, Hugh Holbrook, Kevin Humphries, Suzuki Shinsuke, Jaff acceptance of membership reports with source IP address
Thomas and Rolland Vida for comments and suggestions on this docu- 0.0.0.0 as being a switch requirement.
ment.
Furthermore, the following companies are acknowledged for their Section 2.1.1.(4): Allow the router port to be excluded
contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks, from the General Query messages
Hewlett-Packard, Vitesse Semiconductor Corporation. The ordering
of these names do not correspond to the column numbers in the
response table.
10. Revision History Section 2.1.1.(6): Replace description of timing out
older entries with a reference to IGMP/MLD Proxying.
This section, while incomplete, is provided as a convenience to the Section 2.1.2.(3): Replaced description of timeout
working group members. It will be removed when the document is mechanism with a reference to IGMP/MLD.
released in its final form.
draft-ietf-magma-snoop-05.txt: January 2003 Changes in wording of Section 2.1.2.(4) Expanded rationale to discourage
IGMP forwarding rule 6) and Data forwarding rule 7). Corrections leaking info between IPv4 and IPv6 groups.
in the references section.
RFC DRAFT January 2003 Section 3: more strongly encourage the use of a
configuration option for selection of ICMPv6 message
types.
Apart from above, no substantial changes has occured in the docu- Editorial comments.
ment. Several editorial changes, however, have been made to comply
with the rfc editors requirements:
References splitted in normative and informative sections. Hyphenation problem resolved for groff by setting then ms
HY register to zero, disabling all forms for the entire
document
(".hy 0" and ".nr" worked only as far as the following
ms macro).
Abstract shortened. Sections moved around - again - to comply with
rfc2223bis-03 draft. Added copyright notice after memo
status. Removed table of contents as the draft is fairly
short. Corrected a reference typo.
Changed all occurances of MUST, MAY etc. to lowercase to reflect Section 2.1.2.(3): Requirement and rationale broken into
that this is not a standards track document. separate paragraphs.
Sections moved around so they appear in the required order. Added references to other IPv6 encapsulation documents,
Corrected estimates for MAC address collisions for
Ethernet and FDDI: both specification take the low-order
four (not six) bytes from the IPv6 group addresses.
draft-ietf-magma-snoop-05.txt: January 2003
Changes in wording of IGMP forwarding rule 6) and Data
forwarding rule 7). Corrections in the references section.
Apart from above, no substantial changes has occured in the
document. Several editorial changes, however, have been made
to comply with the rfc editors requirements:
References splitted in normative and informative sections,
other related references added.
Abstract shortened.
Changed all occurances of MUST, MAY etc. to lowercase to
reflect that this is not a standards track document.
Sections moved around so they appear in the required order.
draft-ietf-magma-snoop-04.txt: November 2002 Editorial changes draft-ietf-magma-snoop-04.txt: November 2002 Editorial changes
only. only.
draft-ietf-magma-snoop-03.txt: October 2002 draft-ietf-magma-snoop-03.txt: October 2002
IGMP Forwarding rules: IGMP Forwarding rules:
Add references to and become consistant with the current IGMP Add references to and become consistant with the current IGMP
proxy draft, proxy draft,
Unrecognized IGMP packets should not be ignored because "mbz" Unrecognized IGMP packets should not be ignored because "mbz"
fields are not zero since packets from future versions are fields are not zero since packets from future versions are
expected to maintain consistency. expected to maintain consistency.
Corrections related to IGMP Querier election process. Corrections related to IGMP Querier election process.
Add clarification to how lists of router ports may be assem- Add clarification to how lists of router ports may be
bled. assembled.
Data Forwarding rules: Data Forwarding rules:
Added discussion of the problems for different IGMP environ- Added discussion of the problems for different IGMP
ments in choosing whether to flood or to prune unregistered environments in choosing whether to flood or to prune
multicasts. unregistered multicasts.
Added refinements for how to handle NON-IPv4 multicasts, to Added refinements for how to handle NON-IPv4 multicasts, to
keep IGMP-snooping functionality from interfering with IPv6 keep IGMP-snooping functionality from interfering with IPv6
and other multicast traffic. Any filtering for non-IPv4 mul- and other multicast traffic. Any filtering for non-IPv4
ticasts should be based on bridge behavior and not IGMP snoop- multicasts should be based on bridge behavior and not IGMP
ing behavior. snooping behavior.
IGMP snooping related problems: IGMP snooping related problems:
Fixed description of interoperability issues in environments Fixed description of interoperability issues in environments
with v3 routers and hosts, and v2 snooping switches. with v3 routers and hosts, and v2 snooping switches.
Added discussion of the IGMPv3 "include source" and "exclude Added discussion of the IGMPv3 "include source" and "exclude
source" options, and the inability to support them on shared source" options, and the inability to support them on shared
RFC DRAFT January 2003
segments. segments.
IPv6 Considerations: IPv6 Considerations:
Clarifications regarding address ranges FF00::, FF01:: and all Clarifications regarding address ranges FF00::, FF01:: and all
hosts FF02::1 in relation to data forwarding. hosts FF02::1 in relation to data forwarding.
draft-ietf-magma-snoop-02.txt: June 2002 draft-ietf-magma-snoop-02.txt: June 2002
Status section removes document history; moved into this sec- Status section removes document history; moved into this
tion instead. section instead.
Introduction restores text from the -00 revision that Introduction restores text from the -00 revision that
describes snooping and its goals describes snooping and its goals
IGMP flooding rules eased, allowing management option to IGMP flooding rules eased, allowing management option to
broaden beyond "routers only". broaden beyond "routers only".
Removed a should/MAY inconsistancy between IPv4 Forwarding and Removed a should/MAY inconsistancy between IPv4 Forwarding and
IPv6 processing of checksums. IPv6 processing of checksums.
skipping to change at page 15, line 46 skipping to change at page 14, line 43
Removed (commented out) description of IPR issues: IESG is Removed (commented out) description of IPR issues: IESG is
aware of them. aware of them.
draft-ietf-magma-snoop-01.txt: January 2002 draft-ietf-magma-snoop-01.txt: January 2002
Extensive restructuring of the original text. Extensive restructuring of the original text.
draft-ietf-idmr-snoop-01.txt: 2001 draft-ietf-idmr-snoop-01.txt: 2001
Added several descriptions of cases where IGMP snooping imple- Added several descriptions of cases where IGMP snooping
mentations face problems. Also added several network topology implementations face problems. Also added several network
figures. topology figures.
draft-ietf-idmr-snoop-00.txt: 2001 draft-ietf-idmr-snoop-00.txt: 2001
Initial snooping draft. An overview of IGMP snooping and the Initial snooping draft. An overview of IGMP snooping and the
problems to be solved.
RFC DRAFT January 2003 5. References
problems to be solved. 5.1. Normative References
11. Author's Addresses [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges"
[IGMPv3] Cain, B., "Internet Group Management Protocol,
Version 3", RFC3376, October 2002.
[IPV6-1394] Fujisawa, K. and Onoe, A., "Transmission of IPv6
Packets over IEEE 1394 Networks", RFC3146,
October 2001.
[IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC2464, December 1998.
[IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over
FDDI Networks", RFC2467, December 1998.
[IPV6-TOKEN] Crawford, M., Narten, T. and Thomas, S.,
"Transmission of IPv6 Packets over Token Ring
Networks", RFC2470, December 1998.
[MLD] Deering, S., Fenner, B. and Haberman, B.
"Multicast Listener Discovery (MLD) for IPv6",
RFC2710, October 1999.
[MLDv2] Vida, R. and Costa, L., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", draft-
vida-mld-v2-06.txt, November 2002.
[MRDISC] Biswas, S., Cain, B. and Haberman, B., "Multicast
Router Discovery", draft-ietf-idmr-igmp-
mrdisc-10.txt, January 2003.
[NDP] Narten, T., Nordmark, E. and Simpson, W.,
"Neighbor Discovery for IP Version 6 {IPv6)",
RFC2461, December 1998.
[PROXY] Fenner, B. et al, "IGMP/MLD-based Multicast
Forwarding (IGMP/MLD Proxying)", draft-ietf-
magma-igmp-proxy-01.txt, November 2002.
[RFC1112] Deering, S., "Host Extensions for IP
Multicasting", RFC1112, August 1989.
[RFC2026] Bradner, S. "The Internet Standards Process --
Revision 3", RFC2026, October 1996.
[RFC2236] Fenner, W., "Internet Group Management Protocol,
Version 2", RFC2236, November 1997.
[RFC2375] Hinden, R. "IPv6 Multicast Address Assignments",
RFC2375, July 1998.
5.2. Informative References
[IANA] Internet Assigned Numbers Authority, "Internet
Multicast Addresses", http://www.isi.edu/in-
notes/iana/assignments/multicast-addresses
[CISCO] Cisco Tech Notes, "Multicast In a Campus Network:
CGMP and IGMP snooping",
http://www.cisco.com/warp/public/473/22.html
[MSOFT] Microsoft support article Q223136, "Some LAN
Switches with IGMP Snooping Stop Forwarding
Multicast Packets on RRAS Startup",
http://support.microsoft.com/support/kb/articles/
Q223/1/36.ASP
6. Security Considerations
Security considerations for IGMPv3 are accounted for in
[IGMPv3]. The introduction of IGMP snooping switches adds the
following considerations with regard to IP multicast.
- 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 snooping.
- It is possible to generate packets which make the switch
wrongly believe that there is a multicast router on the
segment on which the source 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.
- IGMP snooping switches which rely on the IP header of a
packet for their operation and which do not validate the
header checksum potentially will forward packets on the
wrong ports. Even though the IP headers are protected by
the Ethernet checksum this is a potential vulnerability.
- In IGMP, there is no mechanism for denying recipients
access to groups (i.e. no "exclude receiver"
functionality). Hence, apart from IP-level security
configuration outside the scope of IGMP, any multicast
stream may be received by any host without restriction.
Generally, IGMP snooping must be considered insecure due to
the issues above. However, none of the these issues are any
worse for IGMP snooping than for IGMP implementations in
general.
7. Acknowledgements
We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben
Carter, Paul Congdon, Toerless Eckert, Bill Fenner, Brian
Haberman, Edward Hilquist, Hugh Holbrook, Kevin Humphries,
Pekka Savola, Suzuki Shinsuke, Jaff Thomas, and Rolland Vida
for comments and suggestions on this document.
Furthermore, the following companies are acknowledged for
their contributions: 3Com, Alcatel, Cisco Systems, Enterasys
Networks, Hewlett-Packard, Vitesse Semiconductor Corporation.
The ordering of these names do not necessarily correspond to
the column numbers in the response table.
8. Authors' Addresses
Morten Jagd Christensen Morten Jagd Christensen
Thrane & Thrane Thrane & Thrane
Lundtoftegaardsvej 93 D Lundtoftegaardsvej 93 D
2800 Lyngby 2800 Lyngby
email: mjc@tt.dk email: mjc@tt.dk
Karen Kimball Karen Kimball
Hewlett-Packard Hewlett-Packard
8000 Foothills Blvd. 8000 Foothills Blvd.
Roseville, CA 95747 Roseville, CA 95747
email: karen.kimball@hp.com email: karen.kimball@hp.com
Frank Solensky Frank Solensky
Bluejavelin, Inc. Bluejavelin, Inc.
3 Dundee Park 3 Dundee Park
Andover, MA 01810 Andover, MA 01810
email: fsolensky@bluejavelin.net email: fsolensky@bluejavelin.net
RFC DRAFT January 2003 9. IETF IPR Statement
Table of Contents "The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to which
any license under such rights might or might not be available;
neither does it represent that it has made any effort to
identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in [RFC-2026].
Copies of claims of rights made available for publication and
any assurances of licenses to be made available, or the result
of an attempt made to obtain a general license or permission
for the use of such proprietary rights by implementors or
users of this specification can be obtained from the IETF
Secretariat."
1. Introduction . . . . . . . . . . . . . . . . . . . . . 2 10. Full Copyright Statement
2. IGMP Snooping Requirements . . . . . . . . . . . . . . 3
2.1. Forwarding rules . . . . . . . . . . . . . . . . . . 3 Copyright (C) The Internet Society (2003). All Rights
2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . 3 Reserved.
2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . 6
2.2. IGMP snooping related problems . . . . . . . . . . . 7 This document and translations of it may be copied and
3. IPv6 Considerations . . . . . . . . . . . . . . . . . . 7 furnished to others, and derivative works that comment on or
4. Normative References . . . . . . . . . . . . . . . . . 9 otherwise explain it or assist in its implementation may be
5. Informative References . . . . . . . . . . . . . . . . 10 prepared, copied, published and distributed, in whole or in
6. Security Considerations . . . . . . . . . . . . . . . . 10 part, without restriction of any kind, provided that the above
7. IGMP Questionnaire . . . . . . . . . . . . . . . . . . 11 copyright notice and this paragraph are included on all such
8. IETF IPR Statement . . . . . . . . . . . . . . . . . . 13 copies and derivative works. However, this document itself
9. Acknowledgements . . . . . . . . . . . . . . . . . . . 13 may not be modified in any way, such as by removing the
10. Revision History . . . . . . . . . . . . . . . . . . . 13 copyright notice or references to the Internet Society or
11. Author's Addresses . . . . . . . . . . . . . . . . . . 16 other Internet organizations, except as needed for the purpose
of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must
be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Acknowledgement:
Funding for the RFC Editor function is currently provided by
the Internet Society.
 End of changes. 91 change blocks. 
400 lines changed or deleted 466 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/