< draft-ietf-magma-snoop-02.txt   draft-ietf-magma-snoop-03.txt >
MAGMA Working Group M. Christensen MAGMA Working Group M. Christensen
Internet Draft morten@jagd-christensen.com Internet Draft mjc@jcaps.com
June 2002 F. Solensky October 2002 K. Kimball
Expiration Date: December 2002 Premonitia Expiration Date: April 2003 Hewlett-Packard
IGMP and MLD snooping switches Considerations for IGMP and MLD snooping switches
<draft-ietf-magma-snoop-02.txt> <draft-ietf-magma-snoop-03.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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other docu¡ months and may be updated, replaced, or obsoleted by other docu-
ments at any time. It is inappropriate to use Internet-Drafts as ments at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in 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.
Abstract Abstract
This memo describes the requirements for IGMP and MLD snooping This memo describes the requirements for IGMP and MLD snooping
switches. The requirements for IGMPv2 snooping switches are based switches. The requirements for IGMPv2 snooping switches are based
on best current practices. IGMPv3 and MLDv2 snooping are also cov¡ on best current practices. IGMPv3 and MLDv2 snooping are also cov-
ered in this draft although we are not aware of any such implemen¡ ered in this draft although we are not aware of any such implemen-
tations at the time of writing. Areas which are of relevance to tations at the time of writing.
IGMP and MLD snooping switches, such as link layer topology changes
and Ethernet specific encapsulation issues are also considered.
Interoperability issues that arise betweed different versions of Note that IGMP snooping is related only to IPv4 multicast. Other
multicast packets, such as IPv6, might be suppressed by the snoop-
ing functionality if additional care is not taken in the implemen-
tation. It is desired not to restrict the flow of non-IPv4 multi-
casts other than to the degree which would happen as a result of
regular bridging functions. The same note can be made of MLD snoop-
ing switches with respect to suppression of IPv4.
RFC DRAFT October 2002
Areas which are of relevance to IGMP and MLD snooping switches,
such as link layer topology changes and Ethernet specific encapsu-
lation issues, are also considered.
Interoperability issues that arise between different versions of
IGMP are not discussed in this document. Interested readers are IGMP are not discussed in this document. Interested readers are
directed to [IGMPv3] for a thorough description of problem area. directed to [IGMPv3] for a thorough description of problem areas.
This document is intended as an accompanying document to the IGMPv3 This document is intended as an accompanying document to the IGMPv3
and MLDv2 specifications. and MLDv2 specifications.
11.. IInnttrroodduuccttiioonn 1. Introduction
When a packet with a broadcast or multicast destination address is When a packet with a broadcast or multicast destination address is
received, the switch will forward a copy into each of the remaining received, the switch will forward a copy into each of the remaining
network segments in accordance with [BRIDGE]. Eventually, the network segments in accordance with [BRIDGE]. Eventually, the
packet is made accessible to all nodes connected to the network. packet is made 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 multi-
cast packets, however, this approach could lead to less efficient cast packets, however, this approach could lead to less efficient
use of network bandwidth, particularly when the packet is intended use of network bandwidth, particularly when the packet is intended
for only a small number of nodes. Packets will be flooded into for only a small number of nodes. Packets will be flooded into
network segments where no node has any interest in receiving the network segments where no node has any interest in receiving the
packet. While nodes will rarely incur any processing overhead to packet. While nodes will rarely incur any processing overhead to
filter packets addressed to unrequested group addresses, they are filter packets addressed to unrequested group addresses, they are
unable to transmit new packets onto the shared media for the period unable to transmit new packets onto the shared media for the period
of time that the multicast packet is flooded. of time that the multicast packet is flooded. In general, signifi-
cant bandwidth can be wasted by flooding.
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 num¡
ber of attached nodes.
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 communica-
tions layers in the ISO model and instead utilizes information in tions layers in the ISO model, and instead utilize information in
the upper level protocol headers as factors to be considered in the the upper- level protocol headers as factors to be considered in
processing at the lower levels. This is analogous to the manner in the processing at the lower levels. This is analogous to the man-
which a router can act as a firewall by looking into the transport ner in which a router can act as a firewall by looking into the
protocol's header before allowing a packet to be forwarded to its transport protocol's header before allowing a packet to be for-
destination address. warded 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 net-
work where no node has expressed interest in receiving packets work 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 behaviour where multicast traffic is typically forwarded on switch behavior where multicast traffic is typically forwarded on
all interfaces. all interfaces.
RFC DRAFT October 2002
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 the requirements for this exist today. It is the authors' hope that the
information presented in this draft will supply this information. information presented in this draft will supply this foundation.
The requirements presented here is based on the following informa¡ The requirements presented here are based on the following informa-
tion sources: The IGMP specifications [RFC112][RFC2236][IGMPv3], tion sources: The IGMP specifications [RFC112][RFC2236][IGMPv3],
vendor supplied technical documents [CISCO], bug reports [MSOFT], vendor-supplied technical documents [CISCO], bug reports [MSOFT],
discussions with people invovled in design of IGMP snooping discussions with people involved in the design of IGMP snooping
switches, MAGMA mailinglist discussions, and on replies by switch switches, MAGMA mailinglist discussions, and on replies by switch
vendors to an implementation questionnaire. vendors to an implementation questionnaire.
The discussions in this document are based on IGMP which applies to The discussions in this document are based on IGMP which applies to
IPv4 only. For IPv6 we must use MLD instead. Because MLD is based IPv4 only. For IPv6 we must use MLD instead. Because MLD is based
on IGMP we do not repeat the whole discussion and requirements for on IGMP we do not repeat the whole discussion and requirements for
MLD snooping switches. Instead we point out the few cases where MLD snooping switches. Instead we point out the few cases where
there is a difference compared to IGMP. there is a difference compared to IGMP.
22.. IIGGMMPP SSnnooooppiinngg RReeqquuiirreemmeennttss 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 discus-
sion. All implementation discussions are examples only and there sion. All implementation discussions are examples only and there
may well be other ways to achieve the same functionality. may well be other ways to achieve the same functionality.
22..11.. FFoorrwwaarrddiinngg rruulleess 2.1. Forwarding rules
The IGMP snooping functionality is here separated in a control sec¡ The IGMP snooping functionality is here separated into a control
tion (IGMP forwarding) and data section (Data forwarding). section (IGMP forwarding) and a data section (Data forwarding).
22..11..11.. IIGGMMPP FFoorrwwaarrddiinngg RRuulleess 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. Alterna-
tively stated: A snooping switch SHOULD NOT forward IGMP Mem¡ tively stated: a snooping switch SHOULD NOT forward IGMP Mem-
bership Reports to ports on which only hosts are attached. An bership Reports to ports on which only hosts are attached. An
administrative control MAY be provided to override this 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 member-
ship reports (as described in IGMP versions 1 and 2) to other ship reports (as described in IGMP versions 1 and 2) to other
hosts can result in unintentionally preventing a host from hosts can result in unintentionally preventing a host from
joining a specific multicast group. This is not a problem in joining a specific multicast group. This is not a problem in
an IGMPv3 only network because there is no cancellation of IGMP an IGMPv3-only network because there is no cancellation of IGMP
Membership reports. Membership reports.
The administrative control allows IGMP Membership Report mes¡ RFC DRAFT October 2002
The administrative control allows IGMP Membership Report mes-
sages to be processed by network monitoring equipment such as sages to be processed by network monitoring equipment such as
packet analysers or port replicators. 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 follow-
ing ways: ing ways:
a) This list SHOULD be built using IGMP Multicast Router Dis¡ a) This list SHOULD be built by the snooping switch sending
covery [MRDISC] by the snooping switch sending Multicast Multicast Router Solicitation messages as described in IGMP
Router Solicitation messages on its own. 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 where the address is not 0.0.0.0. routers) where the source address is not 0.0.0.0.
c) A list of ports configured by management as described in c) Ports explicitly configured by management to be IGMP-for-
the previous step. warding ports, in addition to or instead of any of the
above methods to detect router ports.
2) IGMP snooping switches MAY implement "proxy-reporting" in which 2) IGMP snooping switches MAY also implement "proxy-reporting" in
reports received from downstream hosts are summarized and used which reports received from downstream hosts are summarized and
to build internal membership states as described in [PROXY]. used to build internal membership states as described in
An IGMP proxy-reporting switch would then report its own state [PROXY]. The IGMP proxy-reporting switch would then report its
in response to upstream queriers. If the switch does not own state in response to upstream queriers. If the switch does
alreay have an IP address it SHOULD use the address 0.0.0.0 as not already have an IP address assigned to it, the source
source in these reports. 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 down-
stream hosts while proxy reporting to the 'real' upstream stream 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 identi-
fied through their link layer source MAC address. fied through their link layer source MAC address.
IGMP membership reports MUST NOT be rejected because of a IGMP membership reports MUST NOT be rejected because of a
source IP address of 0.0.0.0; however, these messages MUST NOT source IP address of 0.0.0.0.
be included the election process so that a snooping switch does
not elected over an active router.
3) The switch that supports IGMP snooping MUST flood all unrecog¡ 3) The switch that supports IGMP snooping MUST flood all unrecog-
nized IGMP messages to all other ports and MUST NOT attempt to nized IGMP messages to all other ports and MUST NOT attempt to
make use of any information beyond the end of the network layer make use of any information beyond the end of the network layer
header. In particular, messages where any reserved fields in header.
the IGMP header are non-zero MUST NOT be subject to "normal"
snooping since this could indicate an incompatible change to In addition, earlier versions of IGMP SHOULD interpret IGMP
the IGMP message format.
RFC DRAFT October 2002
fields as defined for their versions and MUST NOT alter these
fields when forwarding the message. When generating new mes-
sages, a given IGMP version should set fields to the appropri-
ate values for its own version. If any fields are reserved or
otherwise undefined for a given IGMP version, the fields SHOULD
be ignored when parsing the message and MUST be set to zeroes
when new messages are generated by 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 initi-
ate the transmission of a General Query on all ports in order ate the transmission of a General Query on all ports in order
to reduce network convergence time. to reduce network convergence time. 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
intregity 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 take some note of the event (i.e., incre-
ment a counter). These errors and their processing are further ment a counter). These errors and their processing are further
discussed in [IGMPv3], [MLD] and [MLDv2]. discussed in [IGMPv3], [MLD] and [MLDv2].
22..11..22.. DDaattaa FFoorrwwaarrddiinngg RRuulleess 6) The snooping switch MUST NOT rely exclusively on IGMP announce-
ments to determine when entries should be removed from the for-
warding table. The reason for this is that changes in the
local topology may cause the snooping switch to fall off the
path between the router and recipient system. As a result, the
switch cannot be assured of seeing an annoucement message asso-
ciated with the recipient leaving the group.
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 exist today
which does not Join IP multicast addresses in this range before which do not Join IP multicast addresses in this range before
sending or listening to IP multicast. Furthermore since the sending or listening to IP multicasts. Furthermore since the
224.0.0.X address range is defined as link local (not to be 224.0.0.X address range is defined as link local (not to be
routed) it seems unnecessary to keep state for each address in routed) it seems unnecessary to keep state for each address in
this range. this range. Additionally, some vendors' applications, which
are not IGMP, use this 224.0.0.X address range, and these
applications would break if the switch were to prune them due
to not seeing a Join.
RFC DRAFT October 2002
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.
Discussion: An implementation could maintain separate member¡ Discussion: An implementation could maintain separate member-
ship and multicast router tables in software and then "merge" ship and multicast router tables in software and then "merge"
these tables into a current forwarding cache. these tables into a current forwarding cache.
3) If a switch receives a non-IGMP multicast packet without having 3) If a switch receives a non-IGMP IPV4 multicast packet without
first processed Membership Reports for the group address, it having first processed Membership Reports for the group
MAY forward the packet on all ports, but it MUST forward the address, it MAY forward the packet on all ports, but it MUST
packet on router ports. A switch MAY forward an unregistered forward the packet on router ports. A switch MAY forward an
packet only on router ports, but the switch MUST have a config¡ unregistered packet only on router ports, but the switch MUST
uration option that suppresses this restrictive operation and have a configuration option that suppresses this restrictive
forces flooding of unregistered packets on all ports. operation and forces flooding of unregistered packets on all
ports. In environments with v3 hosts where the snooping switch
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) IGMP snooping switches MAY maintain forwarding tables based on 4) All non-IPv4 multicast packets SHOULD be flooded, except where
normal IEEE bridging operation would result in filtering multi-
cast packets. Discussion: This ensures that enabling IGMP
snooping does not break, for example, IPv6 multicast.
5) IGMP snooping switches MAY maintain forwarding tables based on
either MAC addresses or IP addresses. If a switch supports 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.
Discussion: Forwarding based on MAC addresses is subject to the Discussion: Forwarding based on MAC addresses is subject to the
problem associated with the 32-fold IP address to 1 MAC address problem associated with the 32-fold IP address to 1 MAC address
mapping. mapping.
5) Switches which rely on information in the IP header SHOULD ver¡ 6) Switches which rely on information in the IP header SHOULD ver-
ify that the IP header checksum is correct. If the checksum ify 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 dis-
carded. carded.
22..22.. IIGGMMPP ssnnooooppiinngg rreellaatteedd pprroobblleemmss 7) The "include source" and "exclude source" options in IGMPv3 do
not work on shared segments. These options are used to register
A special problem arise in the network consisting of IGMPv3 routers RFC DRAFT October 2002
as well as IGMPv2 and IGMPv3 hosts interconnected by a IGMPv2
snooping switch. IGMPv3 has a mechanism to fall back to IGMPv2 for multicast traffic only from certain senders, or from all
when receiving IGMPv2 membership reports. This means that the net¡ except certain senders. On shared segments, if one host has
work will converged on IGMPv2 eventually. However, the convergence registered to receive a multicast data stream but has used the
time will lead to supression of v3 Hosts for several minutes. "include source" or "exclude source" option, any additional
hosts that later request membership for that same multicast
group must accept the restrictions issued in the first host's
request.
2.2. IGMP snooping related problems
A special problem arises in networks consisting of IGMPv3 routers
as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2
snooping switch. The router will continue to maintain IGMPv3 even
in the presence of IGMPv2 hosts, and thus the network will not
likely converge on IGMPv2. But it is likely that the IGMPv2 snoop-
ing switch will not recognize or process the IGMPv3 membership
reports. Groups for these unrecognized reports will then either be
flooded (with all of the problems that may create for hosts in a
network with a heavy multicast load) or pruned by the snooping
switch.
Therefore it is recommended that in such a network, the multicast Therefore it is recommended that in such a network, the multicast
router is configured to use IGMPv2. router be configured to use IGMPv2.
33.. IIPPvv66 CCoonnssiiddeerraattiioonnss 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 IGMPv3 functionality 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.
In IPv6 the protocol for multicast group maintenance is called Mul¡ The control and data forwarding rules in the IGMP section can with
ticast Listener Discovery (MLDv2). IPv6 is not widely deployed a few considerations also be applied to MLD. This means that the
today and neither is IPv6 multicast. However, it is anticipated basic functionality of intercepting MLD packets, building member-
that at some time IPv6 switches capable of MLD snooping will ship lists and multicast router lists is the same as for IGMP.
appear.
The three main differences between IGMPv3 and MLDv2 are: In IPv6, the data forwarding rules are more straight forward
because MLD is mandated for addresses with scope 2 (link-scope) or
greater. The only exception is the address FF002::1 which is the
all hosts link-scope address for which MLD messages are never sent.
Packets with the all hosts link-scope address should be forwarded
on all ports.
- MLDv2 uses ICMPv6 message types instead of IGMP message types. MLD messages are also not sent to packets in the address range
FF00X::/16 when X is 0 or 1 which are reserved and node-local
respectively, and these addresses should never appear in packets on
RFC DRAFT October 2002
the link.
The three main differences between IPv4 and IPv6 in relation to
multicast are:
- The IPv6 protocol for multicast group maintenance is called Mul-
ticast Listener Discovery (MLDv2). MLDv2 uses ICMPv6 message
types instead of IGMP message types.
- The ethernet encapsulation is a mapping of 32 bits of the 128 - The ethernet encapsulation is a mapping of 32 bits of the 128
bit DIP addresses into 48 bit DMAC addresses [IPENCAPS]. bit DIP addresses into 48 bit DMAC addresses [IPENCAPS].
- Multicast router discovery is done using Neighbor Discovery Pro¡ - Multicast router discovery is done using Neighbor Discovery Pro-
tocol (NDP) for IPv6. NDP uses ICMPv6 message types. tocol (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. Never-
theless, the switch SHOULD detect other packet integrity issues. theless, the switch SHOULD detect other packet integrity issues.
When the snooping switch detects such an error, it MUST NOT include When the snooping switch detects such an error, it MUST NOT include
information from the corresponding packet in the IGMP forwarding information from the corresponding packet in the MLD forwarding ta-
table. The forwarding code SHOULD drop the packet and take further ble. The forwarding code SHOULD drop the packet and take further
reasonable actions as advocated above. 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 redirect pack¡ header field of the IP header is ICMPv6 in order to identify pack-
ets to the CPU. If this was the case the CPU queue assigned for ets relevant for MLD snooping.
MLD would potentially be filled with non-MLD related packets. Fur¡
thermore ICMPv6 packets destined for other hosts would not reach Discussion: If an implementation was software based, wrongly iden-
their destination. A solution is either to require that the snoop¡ tifying non-MLD packets as candidates for MLD snooping, would
ing switch looks further into the packets or to be able to detect a potentially fill the CPU queue with irellevant packets thus pre-
multicast DMAC address in conjunction with ICMPv6. The first solu¡ venting the snooping functionality. Furthermore, ICMPv6 packets
tion is desirable only if it is configurable which message types destined for other hosts would not reach their destinations.
should trigger a CPU redirect and which should not. The reason is
that a hardcoding of message types is unflexible for the introduc¡ A solution is either to require that the snooping switch looks fur-
tion of new message types. The second solution introduces the risk ther into the packets, or to be able to detect a multicast DMAC
of new protocols, which are not related to MLD but uses ICMPv6 and address in conjunction with ICMPv6. The first solution is desir-
multicast DMAC addresses wrongly being identified as MLD. It is able only if it is configurable which message types should trigger
suggested that solution one is the preferred if the switch is capa¡ a CPU redirect and which should not. The reason is that a hardcod-
ble of triggering CPU redirects on individual ICMPv6 message types. ing of message types is unflexible for the introduction of new mes-
If this is not the case then use solution two. sage types. The second solution introduces the risk of new proto-
cols, which are not related to MLD but use ICMPv6 and multicast
DMAC addresses, wrongly being identified as MLD. It is suggested
that solution one is the preferred if the switch is capable of
triggering CPU redirects on individual ICMPv6 message types. If
this is not the case, then use solution two.
The mapping from IP multicast addresses to multicast DMAC addresses The mapping from IP multicast addresses to multicast DMAC addresses
RFC DRAFT October 2002
introduces a potentially enormous overlap. The structure of an IPv6 introduces a potentially enormous overlap. The structure of an IPv6
multicast address is shown in figure 5. Theoretically 2**80, two multicast address is shown in the figure below. Theoretically
to the power of 80 (128 - 8 - 4 - 4 - 32) unique DIP addresses 2**80, two to the power of 80 (128 - 8 - 4 - 4 - 32) unique DIP
could map to one DMAC address. This should be compared to 2**5 in addresses could map to one DMAC address. This should be compared to
the case of IPv4. 2**5 in the case of IPv4.
Initial allocation of IPv6 multicast addresses, however, uses only Initial allocation of IPv6 multicast addresses, however, uses only
the lower 32 bits of group ID. This eliminates the address ambigu¡ 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 ity for the time being, but it should be noted that the allocation
policy may change in the future. 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 | | 8 | 4 | 4 | 112 bits |
+--------+----+----+---------------------------------------+ +--------+----+----+---------------------------------------+
|11111111|flgs|scop| group ID | |11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------+ +--------+----+----+---------------------------------------+
Figure 5
In the case of IPv6 forwarding can be made on the basis of DMAC 4. Security Considerations
addresses in the forseable future.
Finally, we mention the reserved address range FF02::/96. This
range is similar to 224.0.0.X for IPv4 and is reserved to routing
protocols and resource discovery [RFC2375]. In the case of IPv6 it
is suggested that packets in this range are forwarded on all ports
if they are not MLD packets.
44.. SSeeccuurriittyy CCoonnssiiddeerraattiioonnss
Security considerations for IGMPv3 are accounted for in [IGMPv3]. Security considerations for IGMPv3 are accounted for in [IGMPv3].
The introduction of IGMP snooping switches adds the following con¡ The introduction of IGMP snooping switches adds the following con-
siderations with regard to IP multicast. siderations with regard to IP multicast.
The exclude source failure which could cause traffic from sources The exclude source failure which could cause traffic from sources
that are 'black listed' to reach hosts that have requested other¡ that are 'black listed' to reach hosts that have requested other-
wise. This can also occur in certain network topologies without wise. This can also occur in certain network topologies without
IGMP snooping. IGMP snooping.
It is possible to generate packets which make the switch wrongly It is possible to generate packets which make the switch wrongly
believe that there is a multicast router on the segment on which believe that there is a multicast router on the segment on which
the source is attached. This will potentially lead to excessive the source is attached. This will potentially lead to excessive
flooding on that segment. The authentication methods discussed in flooding on that segment. The authentication methods discussed in
[IGMPv3] will also provide protection in this case. [IGMPv3] will also provide protection in this case.
IGMP snooping switches which rely on the IP header of a packet for IGMP snooping switches which rely on the IP header of a packet for
their operation and which do not validate the header checksum their operation and which do not validate the header checksum
potentially will forward packets on the wrong ports. Even though potentially will forward packets on the wrong ports. Even though
the IP headers are protected by the ethernet checksum this is a the IP headers are protected by the ethernet checksum this is a
potential vulnerability. potential vulnerability.
Generally though, it is worth to stress that IP multicast must so Generally though, it is worth it to stress that IP multicast must
far be considered insecure until the work of for example the sug¡ so far be considered insecure until the work of for example the
gested Multicast Security (MSEC) working group or similar is com¡ suggested Multicast Security (MSEC) working group or similar is
pleted or at least has matured. completed or at least has matured.
55.. IIGGMMPP QQuueessttiioonnnnaaiirree RFC DRAFT October 2002
5. 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 hard-
ware/software so that only one Join is forwarded to the ware/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 data-
grams addressed to multicast IP addresses 224.1.2.3 and grams 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 unal¡ 239.129.2.3 be forwarded on different port-groups with unal-
tered TTL? 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 multi-
cast routers are attached in addition to the ports where IGMP cast routers are attached in addition to the ports where IGMP
Joins have been received? Joins have been received?
Q7 Is your IGMP snooping functionality fully implemented in hard¡ Q7 Is your IGMP snooping functionality fully implemented in hard-
ware? ware?
Q8 Is your IGMP snooping functionality partly software imple¡ Q8 Is your IGMP snooping functionality partly software imple-
mented? mented?
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?
RFC DRAFT October 2002
The answers were: The answers were:
---------------------------+-----------------------+ ---------------------------+-----------------------+
| Switch Vendor | | Switch Vendor |
---------------------------+---+---+---+---+---+---+ ---------------------------+---+---+---+---+---+---+
| 1 | 2 | 3 | 4 | 5 | 6 | | 1 | 2 | 3 | 4 | 5 | 6 |
---------------------------+---+---+---+---+---+---+ ---------------------------+---+---+---+---+---+---+
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 real soon. (2) Currently no, but will be really soon.
66.. RReeffeerreenncceess 6. IETF IPR Statement
"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 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."
7. References
[BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges"
[CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP [CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP
and IGMP snooping", http://www.cisco.com/warp/pub¡ and IGMP snooping",
lic/473/22.html
RFC DRAFT October 2002
http://www.cisco.com/warp/public/473/22.html
[IANA] Internet Assigned Numbers Authority, "Internet Multicast [IANA] Internet Assigned Numbers Authority, "Internet Multicast
Addresses", http://www.isi.edu/in-notes/iana/assign¡ Addresses", http://www.isi.edu/in-notes/iana/assign-
ments/multicast-addresses ments/multicast-addresses
[IGMPv3] Cain, B., "Internet Group Management Protocol, Version [IGMPv3] Cain, B., "Internet Group Management Protocol, Version
3", draft-ietf-idmr-igmp-v3-11.txt, May 2002. 3", draft-ietf-idmr-igmp-v3-11.txt, May 2002.
[IPENCAPS] Crawford, M., "Transmission of IPv6 Packets over Ether¡ [IPENCAPS] Crawford, M., "Transmission of IPv6 Packets over Ether-
net Networks", RFC2464, December 1998. net Networks", RFC2464, December 1998.
[MLD] Deering, S., Fenner, B., and Haberman, B. "Multicast [MLD] Deering, S., Fenner, B., and Haberman, B. "Multicast
Listener Discovery (MLD) for IPv6", RFC2710, October Listener Discovery (MLD) for IPv6", RFC2710, October
1999. 1999.
[MLDv2] Vida, R., "Multicast Listener Discovery Version 2 [MLDv2] Vida, R., "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", draft-vida-mld-v2-03.txt, June 2002. (MLDv2) for IPv6", draft-vida-mld-v2-03.txt, June 2002.
[MRDISC] Biswas, S. "IGMP Multicast Router Discovery", draft- [MRDISC] Biswas, S. "IGMP Multicast Router Discovery", draft-
ietf-idmr-igmp-mrdisc-08.txt, January 2002. ietf-idmr-igmp-mrdisc-08.txt, January 2002.
[MSOFT] Microsoft support article Q223136, "Some LAN Switches [MSOFT] Microsoft support article Q223136, "Some LAN Switches
with IGMP Snooping Stop Forwarding Multicast Packets on with IGMP Snooping Stop Forwarding Multicast Packets on
RRAS Startup", http://support.microsoft.com/sup¡ RRAS Startup", http://support.microsoft.com/sup-
port/kb/articles/Q223/1/36.ASP port/kb/articles/Q223/1/36.ASP
[PROXY] Fenner, B. et al, "IGMP-based Multicast Forwarding (IGMP [PROXY] Fenner, B. et al, "IGMP-based Multicast Forwarding (IGMP
Proxying)", draft-ietf-magma-proxy-02(?).txt. Proxying)", draft-ietf-magma-igmp-proxy-01.txt, July
2002.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC
1112, August 1989. 1112, August 1989.
[RFC2026] Bradner, S. "The Internet Standards Process -- Revision [RFC2026] Bradner, S. "The Internet Standards Process -- Revision
3", RFC2026, October 1996. 3", RFC2026, October 1996.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC2236, November 1997. 2", RFC2236, November 1997.
[RFC2375] Hinden, R. "IPv6 Multicast Address Assignments", [RFC2375] Hinden, R. "IPv6 Multicast Address Assignments",
RFC2375, July 1998. RFC2375, July 1998.
77.. AAcckknnoowwlleeddggeemmeennttss 8. Acknowledgements
We would like to thank Martin Bak, Les Bell, Yiqun Cai, Paul Cong¡ We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben Carter,
don, Toerless Eckert, Bill Fenner, Brian Haberman, Edward Hilquist, Paul Congdon, Toerless Eckert, Bill Fenner, Brian Haberman, Edward
Hugh Holbrook, Kevin Humphries, Karen Kimball and Jaff Thomas for
comments and suggestions on this document. RFC DRAFT October 2002
Hilquist, Hugh Holbrook, Kevin Humphries, Suzuki Shinsuke, Jaff
Thomas and Rolland Vida for comments and suggestions on this docu-
ment.
Furthermore, the following companies are acknowledged for their Furthermore, the following companies are acknowledged for their
contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks, contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks,
Hewlett-Packard, Vitesse Semiconductor Corporation. The ordering Hewlett-Packard, Vitesse Semiconductor Corporation. The ordering
of these names do not necessarily correspond to the column numbers of these names do not necessarily correspond to the column numbers
in the response table. in the response table.
88.. RReevviissiioonn HHiissttoorryy 9. Revision History
This section, while incomplete, is provided as a convenience to the This section, while incomplete, is provided as a convenience to the
working group members. It will be removed when the document is working group members. It will be removed when the document is
released in its final form. released in its final form.
draft-ietf-magma-snoop-01.txt: January 2002 draft-ietf-magma-snoop-03.txt: October 2002
Extensive restructuring of the original text. IGMP Forwarding rules:
Add references to and become consistant with the current IGMP
proxy draft,
Unrecognized IGMP packets should not be ignored because "mbz"
fields are not zero since packets from future versions are
expected to maintain consistency.
Corrections related to IGMP Querier election process.
Include discussion about aging out entries from the internal
forwarding table.
Add clarification to how lists of router ports may be assem-
bled.
Data Forwarding rules:
Added discussion of the problems for different IGMP environ-
ments in choosing whether to flood or to prune unregistered
multicasts.
Added refinements for how to handle NON-IPv4 multicasts, to
keep IGMP-snooping functionality from interfering with IPv6
and other multicast traffic. Any filtering for non-IPv4 multi-
casts should be based on bridge behavior and not IGMP snooping
behavior.
IGMP snooping related problems:
RFC DRAFT October 2002
Fixed description of interoperability issues in environments
with v3 routers and hosts, and v2 snooping switches.
Added discussion of the IGMPv3 "include source" and "exclude
source" options, and the inability to support them on shared
segments.
IPv6 Considerations:
Clarifications regarding address ranges FF00::, FF01:: and all
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 sec-
tion instead. tion 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 12, line 32 skipping to change at page 14, line 45
Data Forwarding Rules, item 3 is changed from "MUST forward to Data Forwarding Rules, item 3 is changed from "MUST forward to
all ports" to "MAY"; item 4 default changes from "MUST" to all ports" to "MAY"; item 4 default changes from "MUST" to
"SHOULD use network addresses". "SHOULD use network addresses".
Added two sets of additional responses to the questionnaire Added two sets of additional responses to the questionnaire
and text indicating that responses don't cover all products. and text indicating that responses don't cover all products.
Removed (commented out) description of IPR issues: IESG is Removed (commented out) description of IPR issues: IESG is
aware of them. aware of them.
The next revision: draft-ietf-magma-snoop-01.txt: January 2002
In the interest of getting this version of the draft released
before the deadline (less than seven hours from the moment
this paragraph is being typed), we briefly summarize some of
the comments on the previous version that need to be included
in the next one. We believe that other comments have been
addressed in this draft; please let the authors know if this
they have either not been included or need to be corrected.
IGMP Forwarding rules:
Add a reference to and become consistant with the next Extensive restructuring of the original text.
revision of the IGMP proxy draft,
In item 'b': include a description on how the switch draft-ietf-idmr-snoop-01.txt: 2001
determines that a Query came from the router and not
another switch. Is there some way to make this distinc¡
tion beyond the source address?
Proxy reporting: further analysis of the impact on the Added several descriptions of cases where IGMP snooping imple-
election process when using 0.0.0.0 as the source address mentations face problems. Also added several network topology
in membership report messages. Also consider the case
where the switch assumes the role of Querier when no
routers are detected and forfeits the role as soon as one
is announced.
Include some discussion about how entries are to be aged RFC DRAFT October 2002
from the list, perhaps similar to spanning tree algorithm
for unicast MAC address processing.
Data Forwarding rules: figures.
Link-local range to mention the problem is due to routing draft-ietf-idmr-snoop-00.txt: 2001
protocols not sending Report Messages for their respec¡
tive multicast addresses.
Expand discussion of non-IGMP packet forwarding for data Initial snooping draft. An overview of IGMP snooping and the
that matches an IGMPv3 record. Do snooping switches add problems to be solved.
intelligence to recognize SSM versus ASM groups?
IPv6 Considerations: 10. Author's Addresses
Is having MLD a subset of ICMPv6 an issue? Should MLDv2 Morten Jagd Christensen
be a separate protocol? jCAPS
email: mjc@jcaps.com
Add reference to ICMPv6 specification for message pro¡ Karen Kimball
cessing rules. Hewlett-Packard
email: karen.kimball@hp.com
99.. AAuutthhoorr''ss AAddddrreesssseess Frank Solensky
email: solenskyf@acm.org
Morten Jagd Christensen RFC DRAFT October 2002
email: morten@jagd-christensen.com
Frank Solensky Table of Contents
Premonitia, Inc.
1 Nanog Park
Acton, MA 01720
email: fsolensky@premonitia.com
TTaabbllee ooff CCoonntteennttss
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . 2
2. IGMP Snooping Requirements . . . . . . . . . . . . . . . . . 3 2. IGMP Snooping Requirements . . . . . . . . . . . . . . 3
2.1. Forwarding rules . . . . . . . . . . . . . . . . . . . . . 3 2.1. Forwarding rules . . . . . . . . . . . . . . . . . . 3
2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . . . 3 2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . 3
2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . . . 5 2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . 5
2.2. IGMP snooping related problems . . . . . . . . . . . . . . 6 2.2. IGMP snooping related problems . . . . . . . . . . . 7
3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 6 3. IPv6 Considerations . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . 9
5. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . 8 5. IGMP Questionnaire . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. IETF IPR Statement . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . 11
8. Revision History . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . 12
9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 13 9. Revision History . . . . . . . . . . . . . . . . . . . 13
10. Author's Addresses . . . . . . . . . . . . . . . . . . 15
 End of changes. 104 change blocks. 
227 lines changed or deleted 351 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/