< draft-ietf-magma-snoop-08.txt   draft-ietf-magma-snoop-09.txt >
Network Working Group M. Christensen Network Working Group M. Christensen
Internet Draft Thrane & Thrane Internet Draft Thrane & Thrane
Expiration Date: December 2003 K. Kimball Expiration Date: December 2003 K. Kimball
Category: Informational Hewlett-Packard Category: Informational Hewlett-Packard
F. Solensky F. Solensky
July 2003 August 2003
Considerations for IGMP and MLD Snooping Switches Considerations for IGMP and MLD Snooping Switches
<draft-ietf-magma-snoop-08.txt> <draft-ietf-magma-snoop-09.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 47 skipping to change at page 1, line 47
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This memo describes the recommendations 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
IGMP are not the focus of this document. Interested readers are
directed to [IGMPv3] for a thorough description of problem areas.
1. Introduction 1. Introduction
When processing a packet whose destination MAC address is a The IEEE bridge standard [BRIDGE] specifies how LAN packets are
multicast address, the switch will forward a copy of the packet 'bridged', or as is more commonly used today, switched between LAN
into each of the remaining network interfaces that are in the segments. The operation of a switch with respect to multicast
forwarding state in accordance with [BRIDGE]. The spanning tree packets can be summarized as follows. When processing a packet
algorithm ensures that the application of this rule at every switch whose destination MAC address is a multicast address, the switch
in the network will make the packet accessible to all nodes will forward a copy of the packet into each of the remaining
connected to the network. network interfaces that are in the forwarding state in accordance
with [BRIDGE]. The spanning tree algorithm ensures that the
application of this rule at every switch in the network will make
the packet accessible to all nodes connected to the network.
This approach works well for broadcast packets that are intended to This behaviour works well for broadcast packets that are intended
be seen or processed by all connected nodes. In the case of to 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
into network segments where no node has any interest in receiving into network segments where no node has any interest in receiving
the packet. While nodes will rarely incur any processing overhead the packet. While nodes will rarely incur any processing overhead
to filter packets addressed to unrequested group addresses, they to filter packets addressed to unrequested group addresses, they
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.
skipping to change at page 2, line 39 skipping to change at page 1, line 83
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 processing at the lower levels. This is analogous to considered in processing at the lower levels. This is analogous to
the manner in which a router can act as a firewall by looking into the manner in which a router can act as a firewall by looking into
the transport protocol's header before allowing a packet to be the transport protocol's header before allowing a 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 IP multicast traffic, an IGMP snooping switch
the benefit of conserving bandwidth on those segments of the provides the benefit of conserving bandwidth on those segments of
network where no node has expressed interest in receiving packets the network where no node has expressed interest in receiving
addressed to the group address. This is in contrast to normal packets addressed to the group address. This is in contrast to
switch behavior where multicast traffic is typically forwarded on normal switch behavior where multicast traffic is typically
all interfaces. forwarded on all interfaces.
Many switch datasheets state support for IGMP snooping, but no Many switch datasheets state support for IGMP snooping, but no
recommendations 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 recommendations 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.
Interoperability issues that arise between different versions of
IGMP are not the focus of this document. Interested readers are
directed to [IGMPv3] for a thorough description of problem areas.
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 recommendations 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 as mentioned in the recommendations section. It is
multicasts other than to the degree which would happen as a result desired not to restrict the flow of non-IPv4 multicasts other than
of regular bridging functions. Likewise, MLD snooping switches are to the degree which would happen as a result of regular bridging
discouraged from using topological information learned from IPv6 functions. Likewise, MLD snooping switches are discouraged from
traffic to alter the forwarding of IPv4 multicast packets. using topological information learned from IPv6 traffic to alter
the forwarding of IPv4 multicast packets.
2. IGMP Snooping Recommendations 2. IGMP Snooping Recommendations
The following sections list the recommendations for an IGMP The following sections list the recommendations for an IGMP
snooping switch. The recommendation is stated and is supplemented snooping switch. The recommendation is stated and is supplemented
by a 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
skipping to change at page 7, line 15 skipping to change at page 1, line 300
This recommendation is based on fact that many host systems do This recommendation is based on fact that many host systems do
not send Join IP multicast addresses in this range before not send Join IP multicast addresses in this range before
sending or listening to IP multicast packets. Furthermore, sending or listening to IP multicast packets. Furthermore,
since the 224.0.0.X address range is defined as link-local (not 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 to be routed) it seems unnecessary to keep state for each
address in this range. Additionally, some routers operate in address in this range. Additionally, some routers operate in
the 224.0.0.X address range without issuing IGMP Joins, and the 224.0.0.X address range without issuing IGMP Joins, and
these applications would break if the switch were to prune them these applications would break if the switch were to prune them
due to not having seen a Join Group message from the router. 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) An unregistered packet is defined as an IPv4 multicast packet
having first processed Membership Reports for the group with a destination address which does not match any of the
address, it may forward the packet on all ports but it must groups announced in earlier IGMP Membership Reports.
forward the packet on router ports. A switch may forward an
unregistered packet only on router ports, but the switch must If a switch receives an unregistered packet, it must forward
have a configuration option that suppresses this restrictive that packet on all ports to which an IGMP router is attached.
operation and forces flooding of unregistered packets on A switch may default to forwarding unregistered packets on all
selected ports. ports. Switches that do not forward unregistered packets to
all ports must include a configuration option to force the
flooding of unregistered packets on specified 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.
skipping to change at page 9, line 33 skipping to change at page 1, line 415
membership lists and multicast router lists, is the same as for membership lists and multicast router lists, is the same as for
IGMP. IGMP.
In IPv6, the data forwarding rules are more straight forward In IPv6, the data forwarding rules are more straight forward
because MLD is mandated for addresses with scope 2 (link-scope) or because MLD is mandated for addresses with scope 2 (link-scope) or
greater. The only exception is the address FF02::1 which is the greater. The only exception is the address FF02::1 which is the
all hosts link-scope address for which MLD messages are never sent. all hosts link-scope address for which MLD messages are never sent.
Packets with the all hosts link-scope address should be forwarded Packets with the all hosts link-scope address should be forwarded
on all ports. on all ports.
MLD messages are also not sent to packets in the address range MLD messages are also not sent regarding groups with addresses in
FF00::/15 (which encompasses both the reserved FF00::/16 and node- the range FF00::/15 (which encompasses both the reserved FF00::/16
local FF01::/16 IPv6 address spaces). These addresses should never and node-local FF01::/16 IPv6 address spaces). These addresses
appear in packets on the link. should never appear in packets on the link.
Equivalent to the IPv4 behaviors regarding the null IP Source Equivalent to the IPv4 behaviors regarding the null IP Source
address, MLD membership reports must not be rejected by an MLD address, MLD membership reports must not be rejected by an MLD
snooping switch because of an unspecified IP source address (::). snooping switch because of an unspecified IP source address (::).
Additionally, if a non-Querier switch spoofs any General Queries Additionally, if a non-Querier switch spoofs any General Queries
(as addressed in Section 2.1 above, for Spanning Tree topology (as addressed in Section 2.1 above, for Spanning Tree topology
changes), the switch should use the null IP source address (::) changes), the switch should use the null IP source address (::)
when sending said queries. When such proxy queries are received, when sending said queries. When such proxy queries are received,
they must not be included in the Querier election process. they must not be included in the Querier election process.
skipping to change at page 10, line 21 skipping to change at page 1, line 448
multicast groups, while [IPV6-TOKEN] describes the mapping for multicast groups, while [IPV6-TOKEN] describes the mapping for
token ring DMAC addresses by using three low-order bits. The token ring DMAC addresses by using three low-order bits. The
specification [IPV6-1394] makes use of a 6 bit channel number. specification [IPV6-1394] makes use of a 6 bit channel number.
- Multicast router discovery is accomplished using Neighbor - Multicast router discovery is accomplished using Neighbor
Discovery Protocol [NDP] for IPv6. NDP uses ICMPv6 message Discovery Protocol [NDP] for IPv6. NDP uses ICMPv6 message
types. types.
The IPv6 packet header does not include a checksum field. The IPv6 packet header does not include a checksum field.
Nevertheless, the switch should detect other packet integrity Nevertheless, the switch should detect other packet integrity
issues. When the snooping switch detects such an error, it must issues such as address version and payload length consistencies if
possible. When the snooping switch detects such an error, it must
not include information from the corresponding packet in the MLD not include information from the corresponding packet in the MLD
forwarding table. The forwarding code should instead drop the forwarding table. The forwarding code should instead drop the
packet and take further reasonable actions as advocated above. packet and take further reasonable actions as advocated above.
The fact that MLDv2 is using ICMPv6 adds new requirements to a The fact that MLDv2 is using ICMPv6 adds new requirements to a
snooping switch because ICMPv6 has multiple uses aside from MLD. snooping switch because ICMPv6 has multiple uses aside from MLD.
This means that it is no longer sufficient to detect that the next- This means that it is no longer sufficient to detect that the next-
header field of the IP header is ICMPv6 in order to identify header field of the IP header is ICMPv6 in order to identify
packets relevant for MLD snooping. A software-based implemention packets relevant for MLD snooping. A software-based implemention
which treats all ICMPv6 packets as candidates for MLD snooping which treats all ICMPv6 packets as candidates for MLD snooping
skipping to change at page 13, line 4 skipping to change at page 1, line 573
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] [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-09.txt: August 2003
The changes in this version are the result of the AD review
following the WG chair review.
Substantial comments
There were no substantial technical comments, but a list
of suggested wordings and clarifications to improve the
readability and RFC conformance of the draft.
Reference in Abstract removed. Improved wording in
Introduction.
Improved wording in recommendations section, clarified
integrity checking for IPv6, removed security issues
which were really IGMP/MLD security issues.
Editorial Changes
Author information changes, TOC added, fixed a wrong
indentation following section 5.
draft-ietf-magma-snoop-08.txt: June 2003 draft-ietf-magma-snoop-08.txt: June 2003
The changes in this version are the result of the WG chair The changes in this version are the result of the WG chair
review following the second WG last call. The last call itself review following the second WG last call. The last call itself
did not result in further comments. did not result in further comments.
Substantial comments Substantial comments
Requirements have now been replaced with Recommendations Requirements have now been replaced with Recommendations
throughout the draft, which is more appropriate for an throughout the draft, which is more appropriate for an
skipping to change at page 17, line 38 skipping to change at page 1, line 820
Added several descriptions of cases where IGMP snooping Added several descriptions of cases where IGMP snooping
implementations face problems. Also added several network implementations face problems. Also added several network
topology figures. topology figures.
draft-ietf-idmr-snoop-00.txt: 2001 draft-ietf-idmr-snoop-00.txt: 2001
Initial snooping draft. An overview of IGMP snooping and the Initial snooping draft. An overview of IGMP snooping and the
problems to be solved. problems to be solved.
5. References 5. References
5.1. Normative References 5.1. Normative References
[BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges"
[IGMPv3] Cain, B., "Internet Group Management Protocol, [IGMPv3] Cain, B., "Internet Group Management Protocol, Version
Version 3", RFC3376, October 2002. 3", RFC3376, October 2002.
[IPV6-1394] Fujisawa, K. and Onoe, A., "Transmission of IPv6 [IPV6-1394] Fujisawa, K. and Onoe, A., "Transmission of IPv6
Packets over IEEE 1394 Networks", RFC3146, Packets over IEEE 1394 Networks", RFC3146, October
October 2001. 2001.
[IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over [IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC2464, December 1998. Ethernet Networks", RFC2464, December 1998.
[IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over [IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
FDDI Networks", RFC2467, December 1998. Networks", RFC2467, December 1998.
[IPV6-TOKEN] Crawford, M., Narten, T. and Thomas, S., [IPV6-TOKEN] Crawford, M., Narten, T. and Thomas, S., "Transmission
"Transmission of IPv6 Packets over Token Ring of IPv6 Packets over Token Ring Networks", RFC2470,
Networks", RFC2470, December 1998. December 1998.
[MLD] Deering, S., Fenner, B. and Haberman, B. [MLD] Deering, S., Fenner, B. and Haberman, B. "Multicast
"Multicast Listener Discovery (MLD) for IPv6", Listener Discovery (MLD) for IPv6", RFC2710, October
RFC2710, October 1999. 1999.
[MLDv2] Vida, R. and Costa, L., "Multicast Listener [MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery
Discovery Version 2 (MLDv2) for IPv6", draft- Version 2 (MLDv2) for IPv6", draft-vida-mld-v2-06.txt,
vida-mld-v2-06.txt, November 2002. November 2002.
[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,
mrdisc-10.txt, January 2003. January 2003.
[NDP] Narten, T., Nordmark, E. and Simpson, W., [NDP] Narten, T., Nordmark, E. and Simpson, W., "Neighbor
"Neighbor Discovery for IP Version 6 {IPv6)", Discovery for IP Version 6 {IPv6)", RFC2461, December
RFC2461, December 1998. 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-
magma-igmp-proxy-02.txt, November 2002. igmp-proxy-02.txt, November 2002.
[RFC1112] Deering, S., "Host Extensions for IP [RFC1112] Deering, S., "Host Extensions for IP Multicasting",
Multicasting", RFC1112, August 1989. 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.
5.2. Informative References 5.2. Informative References
[IANA] Internet Assigned Numbers Authority, "Internet [IANA] Internet Assigned Numbers Authority, "Internet
Multicast Addresses", Multicast Addresses",
http://www.iana.org/assignments/multicast- http://www.iana.org/assignments/multicast-addresses
addresses
[CISCO] Cisco Tech Notes, "Multicast In a Campus Network: [CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP
CGMP and IGMP snooping", 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
Switches with IGMP Snooping Stop Forwarding with IGMP Snooping Stop Forwarding Multicast Packets
Multicast Packets on RRAS Startup", on RRAS Startup",
http://support.microsoft.com/support/articles/Q223/1/36.ASP http://support.microsoft.com/support/articles/Q223/1/36.ASP
[IETF56] Briefing by Dave Thaler, Microsoft, presented to [IETF56] Briefing by Dave Thaler, Microsoft, presented to the
the MAGMA WG at the 56'th IETF meeting in San MAGMA WG at the 56'th IETF meeting in San Francisco,
Francisco, http://www.ietf.org/proceedings/03mar/index.html
http://www.ietf.org/proceedings/03mar/index.html
[RFC2375] Hinden, R. "IPv6 Multicast Address Assignments", [RFC2375] Hinden, R. "IPv6 Multicast Address Assignments",
RFC2375, July 1998. RFC2375, July 1998.
6. Security Considerations 6. Security Considerations
Security considerations for IGMPv3 are accounted for in Security considerations for IGMPv3/MLDv2 are accounted for in
[IGMPv3]. The introduction of IGMP snooping switches adds the [IGMPv3] and [MLDv2]. The introduction of IGMP/MLD snooping
following considerations with regard to IP multicast. switches does not add any critical considerations with regard to IP
multicast security issues.
- The exclude source failure, which could cause traffic from IGMP snooping switches which rely on the IP header of a packet for
sources that are 'black listed' to reach hosts that have their operation and which do not validate the header checksum,
requested otherwise. This can also occur in certain potentially will forward packets on the wrong ports. Even though
network topologies without IGMP snooping. the IP headers are protected by a link layer checksum this is a
potential vulnerability. However, the absence of a header checksum
in IPv6 gives no means of checking the header integrity for these
packets anyway so the implications for IPv4 are not considered
critical.
- It is possible to generate packets which make the switch 7. Acknowledgements
wrongly believe that there is a multicast router on the
segment on which the source is attached. This will
potentially lead to excessive flooding on that segment.
The authentication methods discussed in [IGMPv3] will also
provide protection in this case.
- IGMP snooping switches which rely on the IP header of a We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben Carter,
packet for their operation and which do not validate the Paul Congdon, Toerless Eckert, Bill Fenner, Brian Haberman, Edward
header checksum potentially will forward packets on the Hilquist, Hugh Holbrook, Kevin Humphries, Isidor Kouvelas, Pekka
wrong ports. Even though the IP headers are protected by Savola, Suzuki Shinsuke, Jaff Thomas, Rolland Vida, and Margaret
the Ethernet checksum this is a potential vulnerability. Wasserman for comments and suggestions on this document.
- In IGMP, there is no mechanism for denying recipients Furthermore, the following companies are acknowledged for their
access to groups (i.e. no "exclude receiver" contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks,
functionality). Hence, apart from IP-level security Hewlett-Packard, Vitesse Semiconductor Corporation. The ordering
configuration outside the scope of IGMP, any multicast of these names do not necessarily correspond to the column numbers
stream may be received by any host without restriction. in the response table.
Generally, IGMP snooping must be considered insecure due to 8. Authors' Addresses
the issues above. However, none of the these issues are any
worse for IGMP snooping than for IGMP implementations in
general.
7. Acknowledgements Morten Jagd Christensen
Thrane & Thrane
Lundtoftegaardsvej 93 D
2800 Lyngby
DENMARK
email: mjc@tt.dk
We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben Karen Kimball
Carter, Paul Congdon, Toerless Eckert, Bill Fenner, Brian Hewlett-Packard
Haberman, Edward Hilquist, Hugh Holbrook, Kevin Humphries, 8000 Foothills Blvd.
Pekka Savola, Suzuki Shinsuke, Jaff Thomas, and Rolland Vida Roseville, CA 95747
for comments and suggestions on this document. USA
email: karen.kimball@hp.com
Furthermore, the following companies are acknowledged for Frank Solensky
their contributions: 3Com, Alcatel, Cisco Systems, Enterasys email: solenskyf@acm.org
Networks, Hewlett-Packard, Vitesse Semiconductor Corporation.
The ordering of these names do not necessarily correspond to
the column numbers in the response table.
8. Authors' Addresses 9. IETF IPR Statement
Morten Jagd Christensen "The IETF takes no position regarding the validity or scope of any
Thrane & Thrane intellectual property or other rights that might be claimed to
Lundtoftegaardsvej 93 D pertain to the implementation or use of the technology described in
2800 Lyngby this document or the extent to which any license under such rights
email: mjc@tt.dk might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in [RFC-2026]. Copies
of claims of rights made available for publication and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat."
Karen Kimball 10. Full Copyright Statement
Hewlett-Packard
8000 Foothills Blvd.
Roseville, CA 95747
email: karen.kimball@hp.com
Frank Solensky Copyright (C) The Internet Society (2003). All Rights Reserved.
email: solenskyf@acm.org
9. IETF IPR Statement This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
"The IETF takes no position regarding the validity or scope of The limited permissions granted above are perpetual and will not be
any intellectual property or other rights that might be revoked by the Internet Society or its successors or assigns.
claimed to pertain to the implementation or use of the
technology described in this document or the extent to which
any license under such rights might or might not be available;
neither does it represent that it has made any effort to
identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in [RFC-2026].
Copies of claims of rights made available for publication and
any assurances of licenses to be made available, or the result
of an attempt made to obtain a general license or permission
for the use of such proprietary rights by implementors or
users of this specification can be obtained from the IETF
Secretariat."
10. Full Copyright Statement This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright (C) The Internet Society (2003). All Rights Acknowledgement:
Reserved.
This document and translations of it may be copied and Funding for the RFC Editor function is currently provided by the
furnished to others, and derivative works that comment on or Internet Society.
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or
other Internet organizations, except as needed for the purpose
of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must
be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will Table of Contents
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 2. IGMP Snooping Recommendations . . . . . . . . . . . . . . . 3
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 2.1. Forwarding rules . . . . . . . . . . . . . . . . . . . . . 3
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . . . 3
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . . . 6
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 2.2. IGMP snooping-related problems . . . . . . . . . . . . . . 9
PARTICULAR PURPOSE. 3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 9
4. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . 11
4. Revision History . . . . . . . . . . . . . . . . . . . . . . 13
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Normative References . . . . . . . . . . . . . . . . . . . 18
5.2. Informative References . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
8. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 21
9. IETF IPR Statement . . . . . . . . . . . . . . . . . . . . . 21
10. Full Copyright Statement . . . . . . . . . . . . . . . . . 21
Acknowledgement: [To RFC Editor: The TOC page is to be moved to page 2 at
publication time ]
Funding for the RFC Editor function is currently provided by [To RFC Editor: Page renumbering in TOC and in document will be
the Internet Society. necessary ]
 End of changes. 58 change blocks. 
189 lines changed or deleted 221 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/