< draft-ietf-magma-snoop-07.txt   draft-ietf-magma-snoop-08.txt >
Network Working Group M. Christensen Network Working Group M. Christensen
Internet Draft Thrane & Thrane Internet Draft Thrane & Thrane
Expiration Date: October 2003 K. Kimball Expiration Date: December 2003 K. Kimball
Category: Informational Hewlett-Packard Category: Informational Hewlett-Packard
F. Solensky F. Solensky
Bluejavelin July 2003
May 2003
Considerations for IGMP and MLD Snooping Switches Considerations for IGMP and MLD Snooping Switches
<draft-ietf-magma-snoop-07.txt> <draft-ietf-magma-snoop-08.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 42 skipping to change at page 1, line 41
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 Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. 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 recommendations 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. with further considerations for IGMPv3- and MLDv2-snooping.
Additional areas of relevance, such as link layer topology changes Additional areas of relevance, such as link layer topology changes
and 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.
1. Introduction 1. Introduction
When processing a packet whose destination MAC address is a When processing a packet whose destination MAC address is a
multicast address, the switch will forward a copy of the packet multicast address, the switch will forward a copy of the packet
into each of the remaining network interfaces that are the into each of the remaining network interfaces that are in the
forwarding state in accordance with [BRIDGE]. The spanning tree forwarding state in accordance with [BRIDGE]. The spanning tree
algorithm ensures that the application of this rule at every switch algorithm ensures that the application of this rule at every switch
in the network will make the packet accessible to all nodes in the network will make the packet accessible to all nodes
connected to the network. 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 be seen or processed by all connected nodes. In the case of
multicast packets, however, this approach could lead to less multicast packets, however, this approach could lead to less
efficient use of network bandwidth, particularly when the packet is efficient use of network bandwidth, particularly when the packet is
intended for only a small number of nodes. Packets will be flooded intended for only a small number of nodes. Packets will be flooded
skipping to change at page 2, line 35 skipping to change at page 2, line 34
are unable to transmit new packets onto the shared media for the are unable to transmit new packets onto the shared media for the
period of time that the multicast packet is flooded. In general, period of time that the multicast packet is flooded. In general,
significant 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 the strict separation of functionality between different
communications layers in the ISO model, and instead utilize communications layers in the ISO model, and instead utilize
information in the upper level protocol headers as factors to be information in the upper level protocol headers as factors to be
considered in the processing at the lower levels. This is considered in processing at the lower levels. This is analogous to
analogous to the manner in which a router can act as a firewall by the manner in which a router can act as a firewall by looking into
looking into the transport protocol's header before allowing a the transport protocol's header before allowing a packet to be
packet to be forwarded to its destination address. 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 the benefit of conserving bandwidth on those segments of the
network 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 recommendations for this exist today. It is the authors' hope that
the information presented in this draft will supply this the information presented in this draft will supply this
foundation. foundation.
The requirements presented here are based on the following The recommendations presented here are based on the following
information sources: The IGMP specifications [RFC1112], [RFC2236] information sources: The IGMP specifications [RFC1112], [RFC2236]
and [IGMPv3], vendor-supplied technical documents [CISCO], bug and [IGMPv3], vendor-supplied technical documents [CISCO], bug
reports [MSOFT], discussions with people involved in the design of reports [MSOFT], discussions with people involved in the design of
IGMP snooping switches, MAGMA mailing list discussions, and on IGMP snooping switches, MAGMA mailing list discussions, and on
replies by switch vendors to an implementation questionnaire. replies by switch vendors to an implementation questionnaire.
The suggestions 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, Multicast Listener Discovery [MLD] must be only to IPv4. For IPv6, Multicast Listener Discovery [MLD] must be
used instead. Because MLD is based on IGMP, we do not repeat the used instead. Because MLD is based on IGMP, we do not repeat the
entire description and requirements for MLD snooping switches. entire description and recommendations for MLD snooping switches.
Instead, we point out the few cases where there are differences Instead, we point out the few cases where there are differences
from IGMP. from IGMP.
Note that the IGMP snooping function should apply only to IPv4 Note that the IGMP snooping function should apply only to IPv4
multicasts. Other multicast packets, such as IPv6, might be multicasts. Other multicast packets, such as IPv6, might be
suppressed by IGMP snooping if additional care is not taken in the suppressed by IGMP snooping if additional care is not taken in the
implementation. It is desired not to restrict the flow of non-IPv4 implementation. It is desired not to restrict the flow of non-IPv4
multicasts other than to the degree which would happen as a result multicasts other than to the degree which would happen as a result
of regular bridging functions. Likewise, MLD snooping switches are of regular bridging functions. Likewise, MLD snooping switches are
discouraged from using topological information learned from IPv6 discouraged from using topological information learned from IPv6
traffic to alter the forwarding of IPv4 multicast packets. traffic to alter the forwarding of IPv4 multicast packets.
2. IGMP Snooping Requirements 2. IGMP Snooping Recommendations
The following sections list the requirements for an IGMP snooping The following sections list the recommendations for an IGMP
switch. The requirement is stated and is supplemented by a snooping switch. The recommendation is stated and is supplemented
description of a possible implementation approach. All by a description of a possible implementation approach. All
implementation discussions are examples only and there may well be implementation discussions are examples only and there may well be
other ways to achieve the same functionality. 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 separated into a control section
section (IGMP forwarding) and a data section (Data forwarding). (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. to those ports where multicast routers are attached.
Alternatively stated: a snooping switch should not forward IGMP Alternatively stated: a snooping switch should not forward IGMP
Membership Reports to ports on which only hosts are attached. Membership Reports to ports on which only hosts are attached.
An 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 This is the main IGMP snooping functionality for the control
membership reports (as described in IGMP versions 1 and 2) to path.
other hosts can result in unintentionally preventing a host
from joining a specific multicast group. This is not a problem Sending membership reports to other hosts can result, for
in an IGMPv3-only network because there is no message IGMPv1 and IGMPv2, in unintentionally preventing a host from
suppression of IGMP Membership reports. joining a specific multicast group.
When an IGMPv1 or IGMPv2 host receives a membership report for
a group address that it is intending to join, the host will
suppress its own membership report for the same group. This
join or message suppression is a requirement for IGMPv1 and
IGMPv2 hosts. However, if a switch does not receive a
membership report from the host it will not forward multicast
data to it.
This is not a problem in an IGMPv3-only network because there
is no suppression of IGMP Membership reports.
The administrative control allows IGMP Membership Report The administrative control allows IGMP Membership Report
messages to be processed by network monitoring equipment such messages to be processed by network monitoring equipment such
as 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 This list can be constructed in any combination of the
following 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.
The 0.0.0.0 address represents a special case where the
switch is proxying IGMP Queries for faster network
convergence, but is not itself the Querier. The switch
does not use its own IP address (even if it has one),
because this would cause the Queries to be seen as coming
from a newly elected Querier. The 0.0.0.0 address is used
to indicate that the Query packets are NOT from a multicast
router.
c) Ports explicitly configured by management to be IGMP- c) Ports explicitly configured by management to be IGMP-
forwarding 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
skipping to change at page 5, line 23 skipping to change at page 5, line 43
messages, a given IGMP version should set fields to the messages, a given IGMP version should set fields to the
appropriate values for its own version. If any fields are appropriate values for its own version. If any fields are
reserved or otherwise undefined for a given IGMP version, the reserved or otherwise undefined for a given IGMP version, the
fields should be ignored when parsing the message and must be fields should be ignored when parsing the message and must be
set to zeroes when new messages are generated by set to zeroes when new messages are generated by
implementations of that IGMP version. An exception may occur implementations of that IGMP version. An exception may occur
if the switch is performing a spoofing function, and is aware if the switch is performing a spoofing function, and is aware
of the settings for new or reserved fields that would be of the settings for new or reserved fields that would be
required to correctly spoof for a different IGMP version. required to correctly spoof for a different IGMP version.
The reason to worry about these trivialities is that IGMPv3
overloads the old IGMP query message using the same type number
(0x11) but with an extended header. Therefore there is a risk
that IGMPv3 queries may be interpreted as older version queries
by, for example, IGMPv2 snooping switches. This has already
been reported [IETF56] and is discussed in section 2.2.
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 caused by Spanning Tree operation. When a port is changes caused by Spanning Tree operation. When a port is
enabled or disabled by Spanning Tree, a General Query may be enabled or disabled by Spanning Tree, a General Query may be
sent on all active non-router ports in order to reduce network sent on all active non-router ports in order to reduce network
convergence time. Non-Querier switches should be aware of convergence time. Non-Querier switches should be aware of
whether the Querier is in IGMPv3 mode. If so, the switch should whether the Querier is in IGMPv3 mode. If so, the switch should
not spoof any General Queries unless it is able to send an not spoof any General Queries unless it is able to send an
IGMPv3 Query that adheres to the most recent information sent IGMPv3 Query that adheres to the most recent information sent
by the true Querier. In no case should a switch introduce a by the true Querier. In no case should a switch introduce a
spoofed IGMPv2 Query into an IGMPv3 network, as this may create spoofed IGMPv2 Query into an IGMPv3 network, as this may create
skipping to change at page 5, line 52 skipping to change at page 6, line 31
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 also take some note of the event (i.e., if it does, it should also take some note of the event (i.e.,
increment a counter). These errors and their processing are increment a counter). These errors and their processing are
further discussed in [IGMPv3], [MLD] and [MLDv2]. further discussed in [IGMPv3], [MLD] and [MLDv2].
6) The snooping switch must not rely exclusively on the appearance 6) The snooping switch must not rely exclusively on the appearance
of IGMP Group Leave announcements to determine when entries of IGMP Group Leave announcements to determine when entries
should be removed from the forwarding table. It should should be removed from the forwarding table. It should
implement a membership timeout mechanism such as the router- implement a membership timeout mechanism such as the router-
side functionality of the IGMP protocol as described in side functionality of the IGMP protocol as described in the
IGMP and MLD specifications (See Normative Reference section
[IGMPv3] on all its non-router ports. This timeout value for IGMPv1-3 and MLDv1-2) on all its non-router ports. This
should be configurable. timeout value should be configurable.
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 address outside 224.0.0.X which
range which are not IGMP must be forwarded on all ports.
This requirement is based on fact that many host systems do not
send Join IP multicast addresses in this range before sending
or listening to IP multicast packets. Furthermore, since the
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
this range. Additionally, some routers operate in the
224.0.0.X address range without issuing IGMP Joins, and these
applications would break if the switch were to prune them due
to not having seen a Join Group message from the router.
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 main IGMP snooping functionality for the data path.
One approach that an implementation could take would be to One approach that an implementation could take would be to
maintain separate membership and multicast router tables in maintain separate membership and multicast router tables in
software and then "merge" these tables into a forwarding cache. software and then "merge" these tables into a forwarding cache.
2) Packets with a destination IP (DIP) address in the 224.0.0.X
range which are not IGMP must be forwarded on all ports.
This recommendation is based on fact that many host systems do
not send Join IP multicast addresses in this range before
sending or listening to IP multicast packets. Furthermore,
since the 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 this range. Additionally, some routers operate in
the 224.0.0.X address range without issuing IGMP Joins, and
these applications would break if the switch were to prune them
due to not having seen a Join Group message from the router.
3) If a switch receives a non-IGMP IPv4 multicast packet without 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 operation and forces flooding of unregistered packets on
selected ports. selected ports.
In an environment where IGMPv3 hosts are mixed with snooping In an environment where IGMPv3 hosts are mixed with snooping
skipping to change at page 7, line 17 skipping to change at page 7, line 49
switch may incorrectly prune off the unregistered data streams switch may incorrectly prune off the unregistered data streams
for the groups (as noted above); alternatively, it may fail to for the groups (as noted above); alternatively, it may fail to
add in forwarding to any new IGMPv3 hosts if the group has add in forwarding to any new IGMPv3 hosts if the group has
previously been joined as IGMPv2 (because the data stream is previously been joined as IGMPv2 (because the data stream is
seen as already having been registered). seen as already having been registered).
4) All non-IPv4 multicast packets should continue to be flooded 4) All non-IPv4 multicast packets should continue to be flooded
out all remaining ports in the forwarding state as per normal out all remaining ports in the forwarding state as per normal
IEEE bridging operations. IEEE bridging operations.
This requirement is a result of the fact that groups made up of This recommendation is a result of the fact that groups made up
IPv4 hosts and IPv6 hosts are completely separate and distinct of IPv4 hosts and IPv6 hosts are completely separate and
groups. As a result, information gleaned from the topology distinct groups. As a result, information gleaned from the
between members of an IPv4 group would not be applicable when topology between members of an IPv4 group would not be
forming the topology between members of an IPv6 group. applicable when forming the topology between members of an IPv6
group.
5) IGMP snooping switches may maintain forwarding tables based on 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. IP address based forwarding is should be to use IP addresses. IP address based forwarding is
preferred because the mapping between IP multicast addresses preferred because the mapping between IP multicast addresses
and link-layer multicast addresses is ambiguous. In the case and link-layer multicast addresses is ambiguous. In the case
of Ethernet, there is a multiplicity of 1 Ethernet address to of Ethernet, there is a multiplicity of 1 Ethernet address to
32 IP addresses [RFC1112]. 32 IP addresses [RFC1112].
skipping to change at page 7, line 47 skipping to change at page 8, line 31
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.
The practical implementation of the (G,S1,S2,...) based data
forwarding tables are not within the scope of this document.
However, one possibility is to maintain two (G,S) forwarding
lists: one for the INCLUDE filter where a match of a specific
(G,S) is a requirement before forwarding will happen, and one
for the EXCLUDE filter where a match of a specific (G,S) will
result in no forwarding.
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 as recently reported [IETF56]. The router will snooping switch as recently reported [IETF56]. The router will
continue to maintain IGMPv3 even in the presence of IGMPv2 hosts, continue to maintain IGMPv3 even in the presence of IGMPv2 hosts,
and thus the network will not converge on IGMPv2. But it is likely and thus the network will not converge on IGMPv2. But it is likely
that the IGMPv2 snooping switch will not recognize or process the that the IGMPv2 snooping switch will not recognize or process the
IGMPv3 membership reports. Groups for these unrecognized reports IGMPv3 membership reports. Groups for these unrecognized reports
will then either be flooded (with all of the problems that may will then either be flooded (with all of the problems that may
skipping to change at page 10, line 4 skipping to change at page 10, line 47
A solution is either to require that the snooping switch looks A solution is either to require that the snooping switch looks
further 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 address in conjunction with ICMPv6. The first solution is
desirable when a configuration option allows the administrator to desirable when a configuration option allows the administrator to
specify which ICMPv6 message types should trigger a CPU redirect specify which ICMPv6 message types should trigger a CPU redirect
and which should not. The reason is that a hardcoding of message and which should not. The reason is that a hardcoding of message
types is inflexible for the introduction of new message types. The types is inflexible for the introduction of new message types. The
second solution introduces the risk that new protocols which use second solution introduces the risk that new protocols which use
ICMPv6 and multicast DMAC addresses could be incorrectly identified ICMPv6 and multicast DMAC addresses could be incorrectly identified
as MLD. It is suggested that solution one is preferred when the as MLD. It is suggested that solution one is preferred when the
administrative switch is provided. If this is not the case, then configuration option is provided. If this is not the case, then
the implementator should seriously consider making this switch the implementor should seriously consider making it available since
available since Neighbor Discovery messages would be among those Neighbor Discovery messages would be among those that fall into
that fall into this false positive case and are vital for the this false positive case and are vital for the operational
operational integrity of IPv6 networks. 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. As a result, IPv6 multicast address is shown in the figure below. As a result,
there are 2 ** (112 - (32 - 8)), or more than 7.9e28 unique DIP there are 2 ** (112 - (32 - 8)), or more than 7.9e28 unique DIP
addresses which map into a single DMAC address in Ethernet and addresses which map into a single DMAC address in Ethernet and
FDDI. This should be compared 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 as described in Initial allocation of IPv6 multicast addresses as described in
[RFC2735], however, cover only the lower 24 bits of group ID. [RFC2735], however, cover only the lower 24 bits of group ID.
skipping to change at page 12, line 29 skipping to change at page 12, line 48
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) Not at the time that the questionnaire was received (2) Not at the time that the questionnaire was received
but expected in the near future. but expected in the near future.
Revision History Revision History
[To RFC Editor: This section is to be removed at publication time]
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-08.txt: June 2003
The changes in this version are the result of the WG chair
review following the second WG last call. The last call itself
did not result in further comments.
Substantial comments
Requirements have now been replaced with Recommendations
throughout the draft, which is more appropriate for an
Informational draft.
Clarifications regarding the overloading of the IGMP
query message in section 2.1.1.
Clarification regarding the data forwarding in the case
of INCLUDE/EXCLUDE filters.
More detail added on the special case of Source IP
address 0.0.0.0.
Editorial Changes
Moved Data Forwarding recommendation up as first bullet
as it really is the main recommendation.
Added a more suitable reference for the Thaler briefing
at the 56'th IETF meeting. Hopefully it will become a
valid link sometime soon.
Moved reference to RFC2375 to the Informative section.
draft-ietf-magma-snoop-07.txt: May 2003 draft-ietf-magma-snoop-07.txt: May 2003
The current version reflects comments made at the 56'th IETF The current version reflects comments made at the 56'th IETF
meeting and from the previous WG last call. The majority of meeting and from the previous WG last call. The majority of
changes appear in sections 2.1 and 2.2, and even the changes changes appear in sections 2.1 and 2.2, and even the changes
here are in reality not substantial. here are in reality not substantial.
Substantial comments Substantial comments
Section 2.1.1.(4): Changed wording for IGMP forwarding Section 2.1.1.(4): Changed wording for IGMP forwarding
skipping to change at page 13, line 32 skipping to change at page 14, line 37
draft-ietf-magma-snoop-06.txt: March 2003 draft-ietf-magma-snoop-06.txt: March 2003
Changes in response to comments made during WG last call and Changes in response to comments made during WG last call and
assessment by the WG chairs: assessment by the WG chairs:
Substantial comments Substantial comments
Clarification in IGMP forwarding section on the Clarification in IGMP forwarding section on the
acceptance of membership reports with source IP address acceptance of membership reports with source IP address
0.0.0.0 as being a switch requirement. 0.0.0.0 as being a switch recommendation.
Section 2.1.1.(4): Allow the router port to be excluded Section 2.1.1.(4): Allow the router port to be excluded
from the General Query messages from the General Query messages
Section 2.1.1.(6): Replace description of timing out Section 2.1.1.(6): Replace description of timing out
older entries with a reference to IGMP/MLD Proxying. older entries with a reference to IGMP/MLD Proxying.
Section 2.1.2.(3): Replaced description of timeout Section 2.1.2.(3): Replaced description of timeout
mechanism with a reference to IGMP/MLD. mechanism with a reference to IGMP/MLD.
skipping to change at page 17, line 41 skipping to change at page 18, line 45
[RFC1112] Deering, S., "Host Extensions for IP [RFC1112] Deering, S., "Host Extensions for IP
Multicasting", RFC1112, August 1989. Multicasting", RFC1112, August 1989.
[RFC2026] Bradner, S. "The Internet Standards Process -- [RFC2026] Bradner, S. "The Internet Standards Process --
Revision 3", RFC2026, October 1996. Revision 3", RFC2026, October 1996.
[RFC2236] Fenner, W., "Internet Group Management Protocol, [RFC2236] Fenner, W., "Internet Group Management Protocol,
Version 2", RFC2236, November 1997. Version 2", RFC2236, November 1997.
[RFC2375] Hinden, R. "IPv6 Multicast Address Assignments",
RFC2375, July 1998.
5.2. Informative References 5.2. Informative References
[IANA] Internet Assigned Numbers Authority, "Internet [IANA] Internet Assigned Numbers Authority, "Internet
Multicast Addresses", http://www.isi.edu/in- Multicast Addresses",
notes/iana/assignments/multicast-addresses http://www.iana.org/assignments/multicast-
addresses
[CISCO] Cisco Tech Notes, "Multicast In a Campus Network: [CISCO] Cisco Tech Notes, "Multicast In a Campus Network:
CGMP and IGMP snooping", CGMP and IGMP snooping",
http://www.cisco.com/warp/public/473/22.html http://www.cisco.com/warp/public/473/22.html
[MSOFT] Microsoft support article Q223136, "Some LAN [MSOFT] Microsoft support article Q223136, "Some LAN
Switches with IGMP Snooping Stop Forwarding Switches with IGMP Snooping Stop Forwarding
Multicast Packets on RRAS Startup", Multicast Packets on RRAS Startup",
http://support.microsoft.com/support/kb/articles/ http://support.microsoft.com/support/articles/Q223/1/36.ASP
Q223/1/36.ASP
[IETF56] Briefing by Dave Thaler, Microsoft, presented to [IETF56] Briefing by Dave Thaler, Microsoft, presented to
the MAGMA WG at the 56'th IETF meeting in San the MAGMA WG at the 56'th IETF meeting in San
Francisco. Francisco,
http://www.ietf.org/proceedings/03mar/index.html
[RFC2375] Hinden, R. "IPv6 Multicast Address Assignments",
RFC2375, July 1998.
6. Security Considerations 6. Security Considerations
Security considerations for IGMPv3 are accounted for in Security considerations for IGMPv3 are accounted for in
[IGMPv3]. The introduction of IGMP snooping switches adds the [IGMPv3]. The introduction of IGMP snooping switches adds the
following considerations with regard to IP multicast. following considerations with regard to IP multicast.
- The exclude source failure, which could cause traffic from - The exclude source failure, which could cause traffic from
sources that are 'black listed' to reach hosts that have sources that are 'black listed' to reach hosts that have
requested otherwise. This can also occur in certain requested otherwise. This can also occur in certain
skipping to change at page 19, line 35 skipping to change at page 20, line 40
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.
3 Dundee Park
Andover, MA 01810
email: solenskyf@acm.org email: solenskyf@acm.org
9. IETF IPR Statement 9. IETF IPR Statement
"The IETF takes no position regarding the validity or scope of "The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be any intellectual property or other rights that might be
claimed to pertain to the implementation or use of the claimed to pertain to the implementation or use of the
technology described in this document or the extent to which technology described in this document or the extent to which
any license under such rights might or might not be available; any license under such rights might or might not be available;
neither does it represent that it has made any effort to neither does it represent that it has made any effort to
 End of changes. 30 change blocks. 
66 lines changed or deleted 134 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/