< draft-ietf-magma-snoop-06.txt   draft-ietf-magma-snoop-07.txt >
Network Working Group M. Christensen Network Working Group M. Christensen
Internet Draft Thrane & Thrane Internet Draft Thrane & Thrane
Expiration Date: September 2003 K. Kimball Expiration Date: October 2003 K. Kimball
Category: Informational Hewlett-Packard Category: Informational Hewlett-Packard
F. Solensky F. Solensky
Bluejavelin Bluejavelin
March 2003 May 2003
Considerations for IGMP and MLD Snooping Switches Considerations for IGMP and MLD Snooping Switches
<draft-ietf-magma-snoop-06.txt> <draft-ietf-magma-snoop-07.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 2, line 9 skipping to change at page 2, line 9
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 has the When processing a packet whose destination MAC address is a
multicast bit (bit 7) set, the switch will forward a copy of the multicast address, the switch will forward a copy of the packet
packet into each of the remaining network interfaces that are the into each of the remaining network interfaces that are 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 5, line 18 skipping to change at page 5, line 18
network layer header. network layer header.
In addition, earlier versions of IGMP should interpret IGMP In addition, earlier versions of IGMP should interpret IGMP
fields as defined for their versions and must not alter these fields as defined for their versions and must not alter these
fields when forwarding the message. When generating new fields when forwarding the message. When generating new
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. implementations of that IGMP version. An exception may occur
if the switch is performing a spoofing function, and is aware
of the settings for new or reserved fields that would be
required to correctly spoof for a different 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 changes caused by Spanning Tree operation. When a port is
initiate the transmission of a General Query over the receiving enabled or disabled by Spanning Tree, a General Query may be
ports in order to reduce network convergence time. sent on all active non-router ports in order to reduce network
convergence time. Non-Querier switches should be aware of
a) When a port other than the router port goes down, a Query whether the Querier is in IGMPv3 mode. If so, the switch should
Request should be directed out the switch's remaining non- not spoof any General Queries unless it is able to send an
router ports for those group addresses which had included IGMPv3 Query that adheres to the most recent information sent
the lost port as a destination for flooded packets. The by the true Querier. In no case should a switch introduce a
Query may be one of the Group-Specific forms if there are spoofed IGMPv2 Query into an IGMPv3 network, as this may create
a relatively small number of groups affected and should be excessive network disruption.
a General Query otherwise. The router port should be
excluded from receiving these Query Requests since it will
usually be the source rather than the receipient of
flooded multicast packets and is less likely to be
affected by the loss of one of the receiver ports.
b) When the router port goes down, Multicast Router Discovery
should be used to determine which of the remaining ports
is the new router port. An IGMPv3 General Query message
should be sent out the remaining ports to refresh the
forwarding tables for other groups.
c) When a new port comes up, a General Query message should
be sent out the new port to determine which groups, if
any, have receipients that have become reachable. The new
port is designated as a router port in MRD messages are
processed.
If the switch is not the Querier, it should use the 'all-zeros' If the switch is not the Querier, it should use the 'all-zeros'
IP Source Address in these proxy queries. When such proxy IP Source Address in these proxy queries (even though some
queries are received, they must not be included in the Querier hosts may elect to not process queries with a 0.0.0.0 IP Source
election process. Address). When such proxy queries are received, they must not
be included in the Querier election process.
5) An IGMP snooping switch must not make use of information in 5) An IGMP snooping switch must not make use of information in
IGMP packets where the IP or IGMP headers have checksum or IGMP packets where the IP or IGMP headers have checksum or
integrity errors. The switch should not flood such packets but integrity errors. The switch should not flood such packets but
if it does, it should 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 instead should be removed from the forwarding table. It should
implement the router side functionality of the IGMP/MLD implement a membership timeout mechanism such as the router-
protocol as described in [PROXY] on all its non-router ports. side functionality of the IGMP protocol as described in
[IGMPv3] on all its non-router ports. This 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 (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 systems do This requirement is based on fact that many host systems do not
not send Join IP multicast addresses in this range before send Join IP multicast addresses in this range before sending
sending or listening to IP multicast packets. Furthermore or listening to IP multicast packets. Furthermore, since the
since the 224.0.0.X address range is defined as link local (not 224.0.0.X address range is defined as link-local (not to be
to be routed) it seems unnecessary to keep state for each routed) it seems unnecessary to keep state for each address in
address in this range. Additionally, some routers operate in this range. Additionally, some routers operate in the
the 224.0.0.X address range without issuing IGMP Joins, and 224.0.0.X address range without issuing IGMP Joins, and these
these applications would break if the switch were to prune them applications would break if the switch were to prune them due
due to not their not having seen a Join Group message from the to not having seen a Join Group message from the router.
router.
2) Packets with a destination IP address outside 224.0.0.X which 2) Packets with a destination IP address outside 224.0.0.X which
are not IGMP should be forwarded according to group-based port are not IGMP should be forwarded according to group-based port
membership tables and must also be forwarded on router ports. membership tables and must also be forwarded on router ports.
This is the core IGMP snooping requirement for the data path. This is the core IGMP snooping requirement for the data path.
One approach that an implementation could take would be to 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.
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 all operation and forces flooding of unregistered packets on
ports. selected ports.
In an environment where IGMPv3 hosts are mixed with snooping In an environment where IGMPv3 hosts are mixed with snooping
switches that do not yet support IGMPv3, the switch's failure switches that do not yet support IGMPv3, the switch's failure
to flood unregistered streams could prevent v3 hosts from to flood unregistered streams could prevent v3 hosts from
receiving their traffic. Alternatively, in environments where receiving their traffic. Alternatively, in environments where
the snooping switch supports all of the IGMP versions that are the snooping switch supports all of the IGMP versions that are
present, flooding unregistered streams may cause IGMP hosts to present, flooding unregistered streams may cause IGMP hosts to
be overwhelmed by multicast traffic, even to the point of not be overwhelmed by multicast traffic, even to the point of not
receiving Queries and failing to issue new membership reports receiving Queries and failing to issue new membership reports
for their own groups. for their own groups.
It is encouraged that snooping switches at least recognize and
process IGMPv3 Join Reports, even if this processing is limited
to the behavior for IGMPv2 Joins, i.e., is done without
considering any additional "include source" or "exclude source"
filtering. When IGMPv3 Joins are not recognized, a snooping
switch may incorrectly prune off the unregistered data streams
for the groups (as noted above); alternatively, it may fail to
add in forwarding to any new IGMPv3 hosts if the group has
previously been joined as IGMPv2 (because the data stream is
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 requirement is a result of the fact that groups made up of
IPv4 hosts and IPv6 hosts are completely separate and distinct IPv4 hosts and IPv6 hosts are completely separate and distinct
groups. As a result, information gleaned from the topology groups. As a result, information gleaned from the topology
between members of an IPv4 group would not be applicable when between members of an IPv4 group would not be applicable when
forming the topology between members of an IPv6 group. 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. If the forwarding table is should be to use IP addresses. IP address based forwarding is
keyed on the MAC address, the switch should use the destination preferred because the mapping between IP multicast addresses
IP address to break hashing table collisions. and link-layer multicast addresses is ambiguous. In the case
of Ethernet, there is a multiplicity of 1 Ethernet address to
32 IP addresses [RFC1112].
6) Switches which rely on information in the IP header should 6) Switches which rely on information in the IP header should
verify that the IP header checksum is correct. If the checksum verify that the IP header checksum is correct. If the checksum
fails, the information in the packet must not be incorporated fails, the information in the packet must not be incorporated
into the forwarding table. Further, the packet should be into the forwarding table. Further, the packet should be
discarded. discarded.
7) When IGMPv3 "include source" and "exclude source" membership 7) When IGMPv3 "include source" and "exclude source" membership
reports are received on shared segments, the switch needs to reports are received on shared segments, the switch needs to
forward the superset of all received membership reports onto forward the superset of all received membership reports onto
the shared segment. Forwarding of traffic from a particular the shared segment. Forwarding of traffic from a particular
source S to a group G must happen if at least one host on the source S to a group G must happen if at least one host on the
shared segment reports an IGMPv3 membership of the type shared segment reports an IGMPv3 membership of the type
INCLUDE(G, Slist1) or EXCLUDE(G, Slist2) where S is an element INCLUDE(G, Slist1) or EXCLUDE(G, Slist2) where S is an element
of Slist1 and not an element of Slist2. of Slist1 and not an element of Slist2.
2.2. IGMP snooping related problems 2.2. IGMP snooping-related problems
A special problem arises in networks consisting of IGMPv3 routers A special problem arises in networks consisting of IGMPv3 routers
as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2 as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2
snooping switch. The router will continue to maintain IGMPv3 even snooping switch as recently reported [IETF56]. The router will
in the presence of IGMPv2 hosts, and thus the network will not continue to maintain IGMPv3 even in the presence of IGMPv2 hosts,
likely converge on IGMPv2. But it is likely that the IGMPv2 and thus the network will not converge on IGMPv2. But it is likely
snooping switch will not recognize or process the IGMPv3 membership that the IGMPv2 snooping switch will not recognize or process the
reports. Groups for these unrecognized reports will then either be IGMPv3 membership reports. Groups for these unrecognized reports
flooded (with all of the problems that may create for hosts in a will then either be flooded (with all of the problems that may
network with a heavy multicast load) or pruned by the snooping create for hosts in a network with a heavy multicast load) or
switch. 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 be configured to use IGMPv2. router be configured to use IGMPv2. If this is not possible, and if
the snooping switch cannot recognize and process the IGMPv3
membership reports, it is instead recommended that the switch's
IGMP snooping functionality be disabled, as there is no clear
solution to this problem.
3. IPv6 Considerations 3. IPv6 Considerations
In order to avoid confusion, the previous discussions have been In order to avoid confusion, the previous discussions have been
based on the IGMP protocol which only applies to IPv4 multicast. based on the IGMP protocol which only applies to IPv4 multicast.
In the case of IPv6 most of the above discussions are still valid In the case of IPv6 most of the above discussions are still valid
with a few exceptions which we will describe here. with a few exceptions which we will describe here.
The control and data forwarding rules in the IGMP section can, with The control and data forwarding rules in the IGMP section can, with
a few considerations, also be applied to MLD. This means that the a few considerations, also be applied to MLD. This means that the
skipping to change at page 8, line 39 skipping to change at page 8, line 45
greater. The only exception is the address FF02::1 which is the greater. The only exception is the address FF02::1 which is the
all hosts link-scope address for which MLD messages are never sent. all hosts link-scope address for which MLD messages are never sent.
Packets with the all hosts link-scope address should be forwarded Packets with the all hosts link-scope address should be forwarded
on all ports. on all ports.
MLD messages are also not sent to packets in the address range MLD messages are also not sent to packets in the address range
FF00::/15 (which encompasses both the reserved FF00::/16 and node- FF00::/15 (which encompasses both the reserved FF00::/16 and node-
local FF01::/16 IPv6 address spaces). These addresses should never local FF01::/16 IPv6 address spaces). These addresses should never
appear in packets on the link. appear in packets on the link.
Equivalent to the IPv4 behaviors regarding the null IP Source
address, MLD membership reports must not be rejected by an MLD
snooping switch because of an unspecified IP source address (::).
Additionally, if a non-Querier switch spoofs any General Queries
(as addressed in Section 2.1 above, for Spanning Tree topology
changes), the switch should use the null IP source address (::)
when sending said queries. When such proxy queries are received,
they must not be included in the Querier election process.
The three major differences between IPv4 and IPv6 in relation to The three major differences between IPv4 and IPv6 in relation to
multicast are: multicast are:
- The IPv6 protocol for multicast group maintenance is called - The IPv6 protocol for multicast group maintenance is called
Multicast Listener Discovery [MLDv2]. MLDv2 uses ICMPv6 message Multicast Listener Discovery [MLDv2]. MLDv2 uses ICMPv6 message
types instead of IGMP message types. types instead of IGMP message types.
- The RFCs [IPV6-ETHER] and [IPV6-FDDI] describe how 24 of the 128 - The RFCs [IPV6-ETHER] and [IPV6-FDDI] describe how 24 of the 128
bit DIP address are used to form the 48 bit DMAC addresses for bit DIP address are used to form the 48 bit DMAC addresses for
multicast groups, while [IPV6-TOKEN] describes the mapping for multicast groups, while [IPV6-TOKEN] describes the mapping for
skipping to change at page 11, line 44 skipping to change at page 12, line 33
(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
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-07.txt: May 2003
The current version reflects comments made at the 56'th IETF
meeting and from the previous WG last call. The majority of
changes appear in sections 2.1 and 2.2, and even the changes
here are in reality not substantial.
Substantial comments
Section 2.1.1.(4): Changed wording for IGMP forwarding
section on when spoofing of General Queries should occur.
Added description of how to avoid IGMP version
incompatibility problems when doing said spoofing.
Section 2.1.2.(3): Clarification of incompatibility
problems in mixed IGMPv2 and IGMPv3 networks. Added
recommendation for switches to implement some level of
IGMPv3 Join recognition to reduce these problems.
Section 2.2: Advice following the briefing [IETF56], that
in some cases disabling IGMP snooping functionality is
the only 'solution'
Section 6, IPv6 Considerations: added descriptions of
behavior involving the IPv6 version of the null IP Source
Address (to parallel the IPv4 behaviors).
Added reference to [IGMPv3] in stead of [PROXY] for group
membership maintenance and timeout.
Editorial Changes
Really minor stuff such as change of authors email
address, addition of references, draft name increment and
date changes.
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 seciton 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 requirement.
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
skipping to change at page 13, line 17 skipping to change at page 14, line 44
References splitted in normative and informative sections, References splitted in normative and informative sections,
other related references added. other related references added.
Abstract shortened. Abstract shortened.
Changed all occurances of MUST, MAY etc. to lowercase to Changed all occurances of MUST, MAY etc. to lowercase to
reflect that this is not a standards track document. reflect that this is not a standards track document.
Sections moved around so they appear in the required order. Sections moved around so they appear in the required order.
draft-ietf-magma-snoop-04.txt: November 2002 Editorial changes draft-ietf-magma-snoop-04.txt: November 2002
only.
draft-ietf-magma-snoop-03.txt: October 2002 Editorial changes only.
IGMP Forwarding rules: draft-ietf-magma-snoop-03.txt: October 2002
Add references to and become consistant with the current IGMP
proxy draft,
Unrecognized IGMP packets should not be ignored because "mbz" IGMP Forwarding rules:
fields are not zero since packets from future versions are Add references to and become consistant with the current
expected to maintain consistency. 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. Corrections related to IGMP Querier election process.
Add clarification to how lists of router ports may be Add clarification to how lists of router ports may be
assembled. assembled.
Data Forwarding rules: Data Forwarding rules:
Added discussion of the problems for different IGMP Added discussion of the problems for different IGMP
environments in choosing whether to flood or to prune environments in choosing whether to flood or to prune
unregistered multicasts. unregistered multicasts.
Added refinements for how to handle NON-IPv4 multicasts, to Added refinements for how to handle NON-IPv4 multicasts,
keep IGMP-snooping functionality from interfering with IPv6 to keep IGMP-snooping functionality from interfering with
and other multicast traffic. Any filtering for non-IPv4 IPv6 and other multicast traffic. Any filtering for non-
multicasts should be based on bridge behavior and not IGMP IPv4 multicasts should be based on bridge behavior and
snooping behavior. not IGMP snooping behavior.
IGMP snooping related problems: IGMP snooping related problems:
Fixed description of interoperability issues in environments Fixed description of interoperability issues in
with v3 routers and hosts, and v2 snooping switches. environments with v3 routers and hosts, and v2 snooping
switches.
Added discussion of the IGMPv3 "include source" and "exclude Added discussion of the IGMPv3 "include source" and
source" options, and the inability to support them on shared "exclude source" options, and the inability to support
segments. them on shared segments.
IPv6 Considerations: IPv6 Considerations:
Clarifications regarding address ranges FF00::, FF01:: and all Clarifications regarding address ranges FF00::, FF01::
hosts FF02::1 in relation to data forwarding. 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 Status section removes document history; moved into this
section instead. section instead.
Introduction restores text from the -00 revision that Introduction restores text from the -00 revision that
describes snooping and its goals describes snooping and its goals
IGMP flooding rules eased, allowing management option to IGMP flooding rules eased, allowing management option to
skipping to change at page 15, line 47 skipping to change at page 17, line 30
[MRDISC] Biswas, S., Cain, B. and Haberman, B., "Multicast [MRDISC] Biswas, S., Cain, B. and Haberman, B., "Multicast
Router Discovery", draft-ietf-idmr-igmp- Router Discovery", draft-ietf-idmr-igmp-
mrdisc-10.txt, January 2003. mrdisc-10.txt, January 2003.
[NDP] Narten, T., Nordmark, E. and Simpson, W., [NDP] Narten, T., Nordmark, E. and Simpson, W.,
"Neighbor Discovery for IP Version 6 {IPv6)", "Neighbor Discovery for IP Version 6 {IPv6)",
RFC2461, December 1998. RFC2461, December 1998.
[PROXY] Fenner, B. et al, "IGMP/MLD-based Multicast [PROXY] Fenner, B. et al, "IGMP/MLD-based Multicast
Forwarding (IGMP/MLD Proxying)", draft-ietf- Forwarding (IGMP/MLD Proxying)", draft-ietf-
magma-igmp-proxy-01.txt, November 2002. magma-igmp-proxy-02.txt, November 2002.
[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.
skipping to change at page 16, line 33 skipping to change at page 18, line 15
[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/kb/articles/
Q223/1/36.ASP Q223/1/36.ASP
[IETF56] Briefing by Dave Thaler, Microsoft, presented to
the MAGMA WG at the 56'th IETF meeting in San
Francisco.
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
network topologies without IGMP snooping. network topologies without IGMP snooping.
skipping to change at page 18, line 23 skipping to change at page 19, line 38
Karen Kimball Karen Kimball
Hewlett-Packard Hewlett-Packard
8000 Foothills Blvd. 8000 Foothills Blvd.
Roseville, CA 95747 Roseville, CA 95747
email: karen.kimball@hp.com email: karen.kimball@hp.com
Frank Solensky Frank Solensky
Bluejavelin, Inc. Bluejavelin, Inc.
3 Dundee Park 3 Dundee Park
Andover, MA 01810 Andover, MA 01810
email: fsolensky@bluejavelin.net email: 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
identify any such rights. Information on the IETF's identify any such rights. Information on the IETF's
 End of changes. 32 change blocks. 
99 lines changed or deleted 156 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/