< draft-ietf-magma-snoop-10.txt		draft-ietf-magma-snoop-11.txt >
	Network Working Group M. Christensen		Network Working Group M. Christensen
	Internet Draft Thrane & Thrane		Internet Draft Thrane & Thrane
	Expiration Date: March 2004 K. Kimball		Expiration Date: November 2004 K. Kimball
	Category: Informational Hewlett-Packard		Category: Informational Hewlett-Packard
	F. Solensky		F. Solensky
	West Ridge Networks		West Ridge Networks
	October 2003		May 2004
	Considerations for IGMP and MLD Snooping Switches		Considerations for IGMP and MLD Snooping Switches
	<draft-ietf-magma-snoop-10.txt>		<draft-ietf-magma-snoop-11.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 38 ¶		skipping to change at page 1, line 38 ¶
	progress."		progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). 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.
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003		MLD Snooping Switches
	1. Introduction		1. Introduction
	The IEEE bridge standard [BRIDGE] specifies how LAN packets are		The IEEE bridge standard [BRIDGE] specifies how LAN packets are
	'bridged', or as is more commonly used today, switched between LAN		'bridged', or as is more commonly used today, switched between LAN
	segments. The operation of a switch with respect to multicast		segments. The operation of a switch with respect to multicast
	packets can be summarized as follows. When processing a packet		packets can be summarized as follows. When processing a packet
	whose destination MAC address is a multicast address, the switch		whose destination MAC address is a multicast address, the switch
	will forward a copy of the packet into each of the remaining		will forward a copy of the packet into each of the remaining
	network interfaces that are in the forwarding state in accordance		network interfaces that are in the forwarding state in accordance
	skipping to change at page 1, line 98 ¶		skipping to change at page 1, line 98 ¶
	the network where no node has expressed interest in receiving		the network where no node has expressed interest in receiving
	packets addressed to the group address. This is in contrast to		packets addressed to the group address. This is in contrast to
	normal switch behavior where multicast traffic is typically		normal switch behavior where multicast traffic is typically
	forwarded on 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.
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003		MLD Snooping Switches
	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		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
	skipping to change at page 1, line 146 ¶		skipping to change at page 1, line 146 ¶
	2.1. Forwarding rules		2.1. Forwarding rules
	The IGMP snooping functionality is separated into a control section		The IGMP snooping functionality is separated into a control 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.
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003		MLD Snooping Switches
	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 for the control		This is the main IGMP snooping functionality for the control
	path.		path.
	skipping to change at page 1, line 196 ¶		skipping to change at page 1, line 196 ¶
	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		The 0.0.0.0 address represents a special case where the
	switch is proxying IGMP Queries for faster network		switch is proxying IGMP Queries for faster network
	convergence, but is not itself the Querier. The switch		convergence, but is not itself the Querier. The switch
	does not use its own IP address (even if it has one),		does not use its own IP address (even if it has one),
	because this would cause the Queries to be seen as coming		because this would cause the Queries to be seen as coming
	from a newly elected Querier. The 0.0.0.0 address is used		from a newly elected Querier. The 0.0.0.0 address is used
			MLD Snooping Switches
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	to indicate that the Query packets are NOT from a multicast		to indicate that the Query packets are NOT from a multicast
	router.		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 networks may include devices which implement "proxy-
	which reports received from downstream hosts are summarized and		reporting", in which reports received from downstream hosts are
	used to build internal membership states as described in		summarized and used to build internal membership states. Such
	[PROXY]. The IGMP proxy-reporting switch would then report its		proxy-reporting devices may use the all-zeros address when
	own state in response to upstream queriers. If the switch does		forwarding any summarized reports upstream. For this reason,
	not already have an IP address assigned to it, the source		IGMP membership reports received by the snooping switch must
	address for these reports should be set to all-zeros.		not be rejected because of a source IP address of 0.0.0.0.
	An IGMP proxy-reporting switch may act as Querier for the
	downstream hosts while proxy reporting to the 'real' upstream
	queriers.
	It should be noted that there may be multiple IGMP proxy-
	reporting switches in the network all using the 0.0.0.0 source
	IP address. In this case the switches can be uniquely
	identified through their link layer source MAC address.
	IGMP membership reports must not be rejected by an IGMP
	snooping switch because of a source IP address of 0.0.0.0.
	3) The switch that supports IGMP snooping must flood all		3) The switch that supports IGMP snooping must flood all
	unrecognized IGMP messages to all other ports and must not		unrecognized IGMP messages to all other ports and must not
	attempt to make use of any information beyond the end of the		attempt to make use of any information beyond the end of the
	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
	skipping to change at page 1, line 247 ¶		skipping to change at page 1, line 234 ¶
	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		The reason to worry about these trivialities is that IGMPv3
	overloads the old IGMP query message using the same type number		overloads the old IGMP query message using the same type number
	(0x11) but with an extended header. Therefore there is a risk		(0x11) but with an extended header. Therefore there is a risk
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	that IGMPv3 queries may be interpreted as older version queries		that IGMPv3 queries may be interpreted as older version queries
	by, for example, IGMPv2 snooping switches. This has already		by, for example, IGMPv2 snooping switches. This has already
	been reported [IETF56] and is discussed in section 2.2.		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
			MLD Snooping Switches
	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
	excessive network disruption.		excessive network disruption.
	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 (even though some		IP Source Address in these proxy queries (even though some
	hosts may elect to not process queries with a 0.0.0.0 IP Source		hosts may elect to not process queries with a 0.0.0.0 IP Source
	Address). When such proxy queries are received, they must not		Address). When such proxy queries are received, they must not
	be included in the Querier election process.		be included in the Querier election process.
	skipping to change at page 1, line 296 ¶		skipping to change at page 1, line 282 ¶
	timeout value 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 address outside 224.0.0.X which		1) 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 main IGMP snooping functionality for the data path.		This is the main IGMP snooping functionality for the data path.
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	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		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.		range which are not IGMP must be forwarded on all ports.
	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
			MLD Snooping Switches
	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) An unregistered packet is defined as an IPv4 multicast packet		3) An unregistered packet is defined as an IPv4 multicast packet
	with a destination address which does not match any of the		with a destination address which does not match any of the
	groups announced in earlier IGMP Membership Reports.		groups announced in earlier IGMP Membership Reports.
	If a switch receives an unregistered packet, it must forward		If a switch receives an unregistered packet, it must forward
	skipping to change at page 1, line 347 ¶		skipping to change at page 1, line 333 ¶
	process IGMPv3 Join Reports, even if this processing is limited		process IGMPv3 Join Reports, even if this processing is limited
	to the behavior for IGMPv2 Joins, i.e., is done without		to the behavior for IGMPv2 Joins, i.e., is done without
	considering any additional "include source" or "exclude source"		considering any additional "include source" or "exclude source"
	filtering. When IGMPv3 Joins are not recognized, a snooping		filtering. When IGMPv3 Joins are not recognized, a snooping
	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).
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	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 recommendation is a result of the fact that groups made up		This recommendation is a result of the fact that groups made up
	of IPv4 hosts and IPv6 hosts are completely separate and		of IPv4 hosts and IPv6 hosts are completely separate and
	distinct groups. As a result, information gleaned from the		distinct groups. As a result, information gleaned from the
	topology between members of an IPv4 group would not be		topology between members of an IPv4 group would not be
	applicable when forming the topology between members of an IPv6		applicable when forming the topology between members of an IPv6
	group.		group.
			MLD Snooping Switches
	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].
	6) Switches which rely on information in the IP header should		6) Switches which rely on information in the IP header should
	skipping to change at page 1, line 392 ¶		skipping to change at page 1, line 378 ¶
	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		The practical implementation of the (G,S1,S2,...) based data
	forwarding tables are not within the scope of this document.		forwarding tables are not within the scope of this document.
	However, one possibility is to maintain two (G,S) forwarding		However, one possibility is to maintain two (G,S) forwarding
	lists: one for the INCLUDE filter where a match of a specific		lists: one for the INCLUDE filter where a match of a specific
	(G,S) is a requirement before forwarding will happen, and one		(G,S) is a requirement before forwarding will happen, and one
	for the EXCLUDE filter where a match of a specific (G,S) will		for the EXCLUDE filter where a match of a specific (G,S) will
	result in no forwarding.		result in no forwarding.
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	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
	create for hosts in a network with a heavy multicast load) or		create for hosts in a network with a heavy multicast load) or
	pruned by the snooping 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
			MLD Snooping Switches
	router be configured to use IGMPv2. If this is not possible, and if		router be configured to use IGMPv2. If this is not possible, and if
	the snooping switch cannot recognize and process the IGMPv3		the snooping switch cannot recognize and process the IGMPv3
	membership reports, it is instead recommended that the switch's		membership reports, it is instead recommended that the switch's
	IGMP snooping functionality be disabled, as there is no clear		IGMP snooping functionality be disabled, as there is no clear
	solution to this problem.		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.
	skipping to change at page 1, line 441 ¶		skipping to change at page 1, line 427 ¶
	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 regarding groups with addresses in		MLD messages are also not sent regarding groups with addresses in
	the range FF00::/15 (which encompasses both the reserved FF00::/16		the range FF00::/15 (which encompasses both the reserved FF00::/16
	and node-local FF01::/16 IPv6 address spaces). These addresses		and node-local FF01::/16 IPv6 address spaces). These addresses
	should never 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
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	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.
	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.
			MLD Snooping Switches
	- 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
	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.
	skipping to change at page 1, line 492 ¶		skipping to change at page 1, line 477 ¶
	could easily fill its receive queue and bog down the CPU with		could easily fill its receive queue and bog down the CPU with
	irrelevant packets. This would prevent the snooping functionality		irrelevant packets. This would prevent the snooping functionality
	from performing its intended purpose and the non-MLD packets		from performing its intended purpose and the non-MLD packets
	destined for other hosts could be lost.		destined for other hosts could be lost.
	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
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	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
	configuration option is provided. If this is not the case, then		configuration option is provided. If this is not the case, then
	the implementor should seriously consider making it available since		the implementor should seriously consider making it available since
	Neighbor Discovery messages would be among those that fall into		Neighbor Discovery messages would be among those that fall into
	this false positive case and are vital for the operational		this false positive case and are vital for the 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,
			MLD Snooping Switches
	there are 2 ** (112 - 32), or more than 1.2e24 unique DIP addresses		there are 2 ** (112 - 32), or more than 1.2e24 unique DIP addresses
	which map into a single DMAC address in Ethernet and FDDI. This		which map into a single DMAC address in Ethernet and FDDI. This
	should be compared to 2**5 in the case of IPv4.		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
	[RFC3307], however, cover only the lower 32 bits of group ID.		[RFC3307], however, cover only the lower 32 bits of group ID.
	While this reduces the problem of address ambiguity to group IDs		While this reduces the problem of address ambiguity to group IDs
	with different flag and scope values for now, it should be noted		with different flag and scope values for now, it should be noted
	that the allocation policy may change in the future. Because of		that the allocation policy may change in the future. Because of
	the potential overlap it is recommended that IPv6 address based		the potential overlap it is recommended that IPv6 address based
	skipping to change at page 1, line 541 ¶		skipping to change at page 1, line 525 ¶
	upon request and do not necessarily apply to all of the vendors'		upon request and do not necessarily apply to all of the vendors'
	products.		products.
	The questions were:		The questions were:
	Q1 Does your switches perform IGMP Join aggregation? In other		Q1 Does your switches perform IGMP Join aggregation? In other
	words, are IGMP joins intercepted, absorbed by the		words, are IGMP joins intercepted, absorbed by the
	hardware/software so that only one Join is forwarded to the		hardware/software so that only one Join is forwarded to the
	querier?		querier?
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	Q2 Is multicast forwarding based on MAC addresses? Would		Q2 Is multicast forwarding based on MAC addresses? Would
	datagrams addressed to multicast IP addresses 224.1.2.3 and		datagrams addressed to multicast IP addresses 224.1.2.3 and
	239.129.2.3 be forwarded on the same ports-groups?		239.129.2.3 be forwarded on the same ports-groups?
	Q3 Is it possible to forward multicast datagrams based on IP		Q3 Is it possible to forward multicast datagrams based on IP
	addresses (not routed)? In other words, could 224.1.2.3 and		addresses (not routed)? In other words, could 224.1.2.3 and
	239.129.2.3 be forwarded on different port-groups with		239.129.2.3 be forwarded on different port-groups with
	unaltered TTL?		unaltered TTL?
	Q4 Are multicast datagrams within the range 224.0.0.1 to		Q4 Are multicast datagrams within the range 224.0.0.1 to
	224.0.0.255 forwarded on all ports whether or not IGMP Joins		224.0.0.255 forwarded on all ports whether or not IGMP Joins
	have been sent?		have been sent?
	Q5 Are multicast frames within the MAC address range		Q5 Are multicast frames within the MAC address range
	01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports		01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports
			MLD Snooping Switches
	whether or not IGMP joins have been sent?		whether or not IGMP joins have been sent?
	Q6 Does your switch support forwarding to ports on which IP		Q6 Does your switch support forwarding to ports on which IP
	multicast routers are attached in addition to the ports where		multicast routers are attached in addition to the ports where
	IGMP Joins have been received?		IGMP Joins have been received?
	Q7 Is your IGMP snooping functionality fully implemented in		Q7 Is your IGMP snooping functionality fully implemented in
	hardware?		hardware?
	Q8 Is your IGMP snooping functionality partly software		Q8 Is your IGMP snooping functionality partly software
	implemented?		implemented?
	Q9 Can topology changes (for example spanning tree configuration		Q9 Can topology changes (for example spanning tree configuration
	changes) be detected by the IGMP snooping functionality so that		changes) be detected by the IGMP snooping functionality so that
	for example new queries can be sent or tables can be updated to		for example new queries can be sent or tables can be updated to
	ensure robustness?		ensure robustness?
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	The answers were:		The answers were:
	---------------------------+-----------------------+		---------------------------+-----------------------+
	| Switch Vendor |		| Switch Vendor |
	---------------------------+---+---+---+---+---+---+		---------------------------+---+---+---+---+---+---+
	| 1 | 2 | 3 | 4 | 5 | 6 |		| 1 | 2 | 3 | 4 | 5 | 6 |
	---------------------------+---+---+---+---+---+---+		---------------------------+---+---+---+---+---+---+
	Q1 Join aggregation | x | x | x | | x | x |		Q1 Join aggregation | x | x | x | | x | x |
	Q2 Layer-2 forwarding | x | x | x | x |(1)| |		Q2 Layer-2 forwarding | x | x | x | x |(1)| |
	Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x |		Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x |
	skipping to change at page 1, line 605 ¶		skipping to change at page 1, line 587 ¶
	(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
			MLD Snooping Switches
	released in its final form.		released in its final form.
			draft-ietf-magma-snoop-11.txt: April 2004
			Editorial changes only:
			Remove reference to IGMP/MLD Proxy (draft-ietf-magma-
			proxy-06.txt) to avoid perception of content dependency.
			Updated references to reflect current revisions, author
			address.
	draft-ietf-magma-snoop-10.txt: October 2003		draft-ietf-magma-snoop-10.txt: October 2003
	The changes in this version are the result of the IESG review.		The changes in this version are the result of the IESG review.
	Substantial comments		Substantial comments
	The security considerations section was found a little		The security considerations section was found a little
	too brief. It has now been extended.		too brief. It has now been extended.
	Editorial Changes		Editorial Changes
	Removed reference RFC2375, using RFC3307 instead. New		Removed reference RFC2375, using RFC3307 instead. New
	author address information.		author address information.
	draft-ietf-magma-snoop-09.txt: August 2003		draft-ietf-magma-snoop-09.txt: August 2003
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	The changes in this version are the result of the AD review		The changes in this version are the result of the AD review
	following the WG chair review.		following the WG chair review.
	Substantial comments		Substantial comments
	There were no substantial technical comments, but a list		There were no substantial technical comments, but a list
	of suggested wordings and clarifications to improve the		of suggested wordings and clarifications to improve the
	readability and RFC conformance of the draft.		readability and RFC conformance of the draft.
	Reference in Abstract removed. Improved wording in		Reference in Abstract removed. Improved wording in
	skipping to change at page 1, line 646 ¶		skipping to change at page 1, line 638 ¶
	Improved wording in recommendations section, clarified		Improved wording in recommendations section, clarified
	integrity checking for IPv6, removed security issues		integrity checking for IPv6, removed security issues
	which were really IGMP/MLD security issues.		which were really IGMP/MLD security issues.
	Editorial Changes		Editorial Changes
	Author information changes, TOC added, fixed a wrong		Author information changes, TOC added, fixed a wrong
	indentation following section 5.		indentation following section 5.
			MLD Snooping Switches
	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 1, line 673 ¶		skipping to change at page 1, line 667 ¶
	More detail added on the special case of Source IP		More detail added on the special case of Source IP
	address 0.0.0.0.		address 0.0.0.0.
	Editorial Changes		Editorial Changes
	Moved Data Forwarding recommendation up as first bullet		Moved Data Forwarding recommendation up as first bullet
	as it really is the main recommendation.		as it really is the main recommendation.
	Added a more suitable reference for the Thaler briefing		Added a more suitable reference for the Thaler briefing
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	at the 56'th IETF meeting. Hopefully it will become a		at the 56'th IETF meeting. Hopefully it will become a
	valid link sometime soon.		valid link sometime soon.
	Moved reference to RFC2375 to the Informative section.		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
	skipping to change at page 1, line 697 ¶		skipping to change at page 1, line 688 ¶
	Substantial comments		Substantial comments
	Section 2.1.1.(4): Changed wording for IGMP forwarding		Section 2.1.1.(4): Changed wording for IGMP forwarding
	section on when spoofing of General Queries should occur.		section on when spoofing of General Queries should occur.
	Added description of how to avoid IGMP version		Added description of how to avoid IGMP version
	incompatibility problems when doing said spoofing.		incompatibility problems when doing said spoofing.
	Section 2.1.2.(3): Clarification of incompatibility		Section 2.1.2.(3): Clarification of incompatibility
	problems in mixed IGMPv2 and IGMPv3 networks. Added		problems in mixed IGMPv2 and IGMPv3 networks. Added
			MLD Snooping Switches
	recommendation for switches to implement some level of		recommendation for switches to implement some level of
	IGMPv3 Join recognition to reduce these problems.		IGMPv3 Join recognition to reduce these problems.
	Section 2.2: Advice following the briefing [IETF56], that		Section 2.2: Advice following the briefing [IETF56], that
	in some cases disabling IGMP snooping functionality is		in some cases disabling IGMP snooping functionality is
	the only 'solution'		the only 'solution'
	Section 6, IPv6 Considerations: added descriptions of		Section 6, IPv6 Considerations: added descriptions of
	behavior involving the IPv6 version of the null IP Source		behavior involving the IPv6 version of the null IP Source
	Address (to parallel the IPv4 behaviors).		Address (to parallel the IPv4 behaviors).
	skipping to change at page 1, line 724 ¶		skipping to change at page 1, line 717 ¶
	address, addition of references, draft name increment and		address, addition of references, draft name increment and
	date changes.		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
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	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 recommendation.		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.
	skipping to change at page 1, line 748 ¶		skipping to change at page 1, line 739 ¶
	Section 2.1.2.(4) Expanded rationale to discourage		Section 2.1.2.(4) Expanded rationale to discourage
	leaking info between IPv4 and IPv6 groups.		leaking info between IPv4 and IPv6 groups.
	Section 3: more strongly encourage the use of a		Section 3: more strongly encourage the use of a
	configuration option for selection of ICMPv6 message		configuration option for selection of ICMPv6 message
	types.		types.
	Editorial comments.		Editorial comments.
			MLD Snooping Switches
	Hyphenation problem resolved for groff by setting then ms		Hyphenation problem resolved for groff by setting then ms
	HY register to zero, disabling all forms for the entire		HY register to zero, disabling all forms for the entire
	document		document
	(".hy 0" and ".nr" worked only as far as the following		(".hy 0" and ".nr" worked only as far as the following
	ms macro).		ms macro).
	Sections moved around - again - to comply with		Sections moved around - again - to comply with
	rfc2223bis-03 draft. Added copyright notice after memo		rfc2223bis-03 draft. Added copyright notice after memo
	status. Removed table of contents as the draft is fairly		status. Removed table of contents as the draft is fairly
	short. Corrected a reference typo.		short. Corrected a reference typo.
	skipping to change at page 1, line 774 ¶		skipping to change at page 1, line 767 ¶
	Corrected estimates for MAC address collisions for		Corrected estimates for MAC address collisions for
	Ethernet and FDDI: both specification take the low-order		Ethernet and FDDI: both specification take the low-order
	four (not six) bytes from the IPv6 group addresses.		four (not six) bytes from the IPv6 group addresses.
	draft-ietf-magma-snoop-05.txt: January 2003		draft-ietf-magma-snoop-05.txt: January 2003
	Changes in wording of IGMP forwarding rule 6) and Data		Changes in wording of IGMP forwarding rule 6) and Data
	forwarding rule 7). Corrections in the references section.		forwarding rule 7). Corrections in the references section.
	Apart from above, no substantial changes has occured in the		Apart from above, no substantial changes has occured in the
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	document. Several editorial changes, however, have been made		document. Several editorial changes, however, have been made
	to comply with the rfc editors requirements:		to comply with the rfc editors requirements:
	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.
	skipping to change at page 1, line 799 ¶		skipping to change at page 1, line 789 ¶
	draft-ietf-magma-snoop-04.txt: November 2002		draft-ietf-magma-snoop-04.txt: November 2002
	Editorial changes only.		Editorial changes only.
	draft-ietf-magma-snoop-03.txt: October 2002		draft-ietf-magma-snoop-03.txt: October 2002
	IGMP Forwarding rules:		IGMP Forwarding rules:
	Add references to and become consistant with the current		Add references to and become consistant with the current
	IGMP proxy draft,		IGMP proxy draft,
			MLD Snooping Switches
	Unrecognized IGMP packets should not be ignored because		Unrecognized IGMP packets should not be ignored because
	"mbz" fields are not zero since packets from future		"mbz" fields are not zero since packets from future
	versions are expected to maintain consistency.		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.
	skipping to change at page 1, line 825 ¶		skipping to change at page 1, line 816 ¶
	to keep IGMP-snooping functionality from interfering with		to keep IGMP-snooping functionality from interfering with
	IPv6 and other multicast traffic. Any filtering for non-		IPv6 and other multicast traffic. Any filtering for non-
	IPv4 multicasts should be based on bridge behavior and		IPv4 multicasts should be based on bridge behavior and
	not IGMP snooping behavior.		not IGMP snooping behavior.
	IGMP snooping related problems:		IGMP snooping related problems:
	Fixed description of interoperability issues in		Fixed description of interoperability issues in
	environments with v3 routers and hosts, and v2 snooping		environments with v3 routers and hosts, and v2 snooping
	switches.		switches.
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	Added discussion of the IGMPv3 "include source" and		Added discussion of the IGMPv3 "include source" and
	"exclude source" options, and the inability to support		"exclude source" options, and the inability to support
	them on shared segments.		them on shared segments.
	IPv6 Considerations:		IPv6 Considerations:
	Clarifications regarding address ranges FF00::, FF01::		Clarifications regarding address ranges FF00::, FF01::
	and all 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
	skipping to change at page 1, line 849 ¶		skipping to change at page 1, line 838 ¶
	Introduction restores text from the -00 revision that		Introduction restores text from the -00 revision that
	describes snooping and its goals		describes snooping and its goals
	IGMP flooding rules eased, allowing management option to		IGMP flooding rules eased, allowing management option to
	broaden beyond "routers only".		broaden beyond "routers only".
	Removed a should/MAY inconsistancy between IPv4 Forwarding and		Removed a should/MAY inconsistancy between IPv4 Forwarding and
	IPv6 processing of checksums.		IPv6 processing of checksums.
			MLD Snooping Switches
	IGMP Forwarding Rules: clarify text describing processing of		IGMP Forwarding Rules: clarify text describing processing of
	non-zero reserved fields.		non-zero reserved fields.
	Data Forwarding Rules, item 3 is changed from "MUST forward to		Data Forwarding Rules, item 3 is changed from "MUST forward to
	all ports" to "MAY"; item 4 default changes from "MUST" to		all ports" to "MAY"; item 4 default changes from "MUST" to
	"should use network addresses".		"should use network addresses".
	Added two sets of additional responses to the questionnaire		Added two sets of additional responses to the questionnaire
	and text indicating that responses don't cover all products.		and text indicating that responses don't cover all products.
	skipping to change at page 1, line 874 ¶		skipping to change at page 1, line 865 ¶
	Extensive restructuring of the original text.		Extensive restructuring of the original text.
	draft-ietf-idmr-snoop-01.txt: 2001		draft-ietf-idmr-snoop-01.txt: 2001
	Added several descriptions of cases where IGMP snooping		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
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	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, Version		[IGMPv3] Cain, B., "Internet Group Management Protocol, 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, October		Packets over IEEE 1394 Networks", RFC3146, 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.
			MLD Snooping Switches
	[IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI		[IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
	Networks", RFC2467, December 1998.		Networks", RFC2467, December 1998.
	[IPV6-TOKEN] Crawford, M., Narten, T. and Thomas, S., "Transmission		[IPV6-TOKEN] Crawford, M., Narten, T. and Thomas, S., "Transmission
	of IPv6 Packets over Token Ring Networks", RFC2470,		of IPv6 Packets over Token Ring Networks", RFC2470,
	December 1998.		December 1998.
	[MLD] Deering, S., Fenner, B. and Haberman, B. "Multicast		[MLD] Deering, S., Fenner, B. and Haberman, B. "Multicast
	Listener Discovery (MLD) for IPv6", RFC2710, October		Listener Discovery (MLD) for IPv6", RFC2710, October
	1999.		1999.
	[MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery		[MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery
	Version 2 (MLDv2) for IPv6", draft-vida-mld-v2-06.txt,		Version 2 (MLDv2) for IPv6", draft-vida-mld-v2-08.txt,
	November 2002.		December 2003.
	[MRDISC] Biswas, S., Cain, B. and Haberman, B., "Multicast		[MRDISC] Biswas, S., Cain, B. and Haberman, B., "Multicast
	Router Discovery", draft-ietf-idmr-igmp-mrdisc-10.txt,		Router Discovery", draft-ietf-magma-mrdisc-00.txt,
	January 2003.		February 2004.
	[NDP] Narten, T., Nordmark, E. and Simpson, W., "Neighbor		[NDP] Narten, T., Nordmark, E. and Simpson, W., "Neighbor
	Discovery for IP Version 6 {IPv6)", RFC2461, December		Discovery for IP Version 6 {IPv6)", RFC2461, December
	1998.		1998.
	[PROXY] Fenner, B. et al, "IGMP/MLD-based Multicast
	Forwarding (IGMP/MLD Proxying)", draft-ietf-magma-
	igmp-proxy-02.txt, November 2002.
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	[RFC1112] Deering, S., "Host Extensions for IP Multicasting",		[RFC1112] Deering, S., "Host Extensions for IP 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.
	[RFC3307] Haberman, B., "Allocation Guidelines for IPv6		[RFC3307] Haberman, B., "Allocation Guidelines for IPv6
	Multicast Addresses", RFC3307, August 2002.		Multicast Addresses", RFC3307, August 2002.
	5.2. Informative References		5.2. Informative References
			[CISCO]
			Cisco Tech Notes, "Multicast In a Campus Network: CGMP and
			IGMP snooping", http://www.cisco.com/warp/public/473/22.html
	[IANA] Internet Assigned Numbers Authority, "Internet		[IANA] Internet Assigned Numbers Authority, "Internet
	Multicast Addresses",		Multicast Addresses",
	http://www.iana.org/assignments/multicast-addresses		http://www.iana.org/assignments/multicast-addresses
			MLD Snooping Switches
	[CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP		[IETF56] Briefing by Dave Thaler, Microsoft, presented to the
	and IGMP snooping",		MAGMA WG at the 56'th IETF meeting in San Francisco,
	http://www.cisco.com/warp/public/473/22.html		http://www.ietf.org/proceedings/03mar/index.html
	[MSOFT] Microsoft support article Q223136, "Some LAN Switches		[MSOFT] Microsoft support article Q223136, "Some LAN Switches
	with IGMP Snooping Stop Forwarding Multicast Packets		with IGMP Snooping Stop Forwarding Multicast Packets
	on RRAS Startup",		on RRAS Startup",
	http://support.microsoft.com/support/articles/Q223/1/36.ASP
	[IETF56] Briefing by Dave Thaler, Microsoft, presented to the		http://support.microsoft.com/support/articles/Q223/1/36.ASP
	MAGMA WG at the 56'th IETF meeting in San Francisco,
	http://www.ietf.org/proceedings/03mar/index.html
	6. Security Considerations		6. Security Considerations
	Under normal network operation, the snooping switch is expected to		Under normal network operation, the snooping switch is expected to
	improve overall network performance by limiting the scope of		improve overall network performance by limiting the scope of
	multicast flooding to a smaller portion of the local network. In		multicast flooding to a smaller portion of the local network. In
	the event of forged IGMP messages, the benefits of using a snooping		the event of forged IGMP messages, the benefits of using a snooping
	switch might be reduced or eliminated.		switch might be reduced or eliminated.
	Security considerations for IGMPv3 at the network layer of the		Security considerations for IGMPv3 at the network layer of the
	protocol stack are described in [IGMPv3]. The introduction of IGMP		protocol stack are described in [IGMPv3]. The introduction of IGMP
	snooping functionality does not alter the handling of multicast		snooping functionality does not alter the handling of multicast
	packets by the router as it does not make use of link layer		packets by the router as it does not make use of link layer
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	information.		information.
	There are, however, changes in the way that the IGMP snooping		There are, however, changes in the way that the IGMP snooping
	switch handles multicast packets within the local network. In		switch handles multicast packets within the local network. In
	particular:		particular:
	- A Query message with a forged source address which is less than		- A Query message with a forged source address which is less than
	that of the current Querier could cause snooping switches to		that of the current Querier could cause snooping switches to
	forward subsequent Membership reports to the wrong network		forward subsequent Membership reports to the wrong network
	interface. It is for this reason that IGMP Membership Reports		interface. It is for this reason that IGMP Membership Reports
	skipping to change at page 1, line 994 ¶		skipping to change at page 1, line 978 ¶
	Current-State Report Messages that would cause the switch to		Current-State Report Messages that would cause the switch to
	incorrectly believe that there is a multicast listener on the		incorrectly believe that there is a multicast listener on the
	same network segment as the originator of the forged message.		same network segment as the originator of the forged message.
	This will cause unrequested multicast packets to be forwarded		This will cause unrequested multicast packets to be forwarded
	into the network segments between the source and the router.		into the network segments between the source and the router.
	If the router requires that all Multicast Report messages be		If the router requires that all Multicast Report messages be
	authenticated as described in section 9.4 of [IGMPv3], it will		authenticated as described in section 9.4 of [IGMPv3], it will
	discard the forged Report message from the host inside the		discard the forged Report message from the host inside the
	network in the same way that it would discard one which		network in the same way that it would discard one which
	originates from a remote location. It is worth noting that if		originates from a remote location. It is worth noting that if
			MLD Snooping Switches
	the router accepts unauthenticated Report messages by virtue of		the router accepts unauthenticated Report messages by virtue of
	them having arrived over a network interface associated with		them having arrived over a network interface associated with
	the internal network, investigating the affected network		the internal network, investigating the affected network
	segments will quickly narrow the search for the source of the		segments will quickly narrow the search for the source of the
	forged messages.		forged messages.
	- As noted in [IGMPv3], there is little motivation for an		- As noted in [IGMPv3], there is little motivation for an
	attacker to forge a Membership report message since joining a		attacker to forge a Membership report message since joining a
	group is generally an unprivileged operation. The sender of		group is generally an unprivileged operation. The sender of
	the forged Membership report will be the only recipient of the		the forged Membership report will be the only recipient of the
	skipping to change at page 1, line 1015 ¶		skipping to change at page 1, line 1001 ¶
	shared LAN segment (HUB) or network without snooping switches,		shared LAN segment (HUB) or network without snooping switches,
	where all other hosts on the same segment would be unable to		where all other hosts on the same segment would be unable to
	transmit when the network segment is flooding the unwanted		transmit when the network segment is flooding the unwanted
	traffic.		traffic.
	The worst case result for each attack would remove the performance		The worst case result for each attack would remove the performance
	improvements that the snooping functionality would otherwise		improvements that the snooping functionality would otherwise
	provide. It would, however, be no worse than that experienced on a		provide. It would, however, be no worse than that experienced on a
	network with switches that do not perform multicast snooping.		network with switches that do not perform multicast snooping.
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	7. Acknowledgements		7. Acknowledgements
	We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben Carter,		We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben Carter,
	Paul Congdon, Toerless Eckert, Bill Fenner, Brian Haberman, Edward		Paul Congdon, Toerless Eckert, Bill Fenner, Brian Haberman, Edward
	Hilquist, Hugh Holbrook, Kevin Humphries, Isidor Kouvelas, Pekka		Hilquist, Hugh Holbrook, Kevin Humphries, Isidor Kouvelas, Pekka
	Savola, Suzuki Shinsuke, Jaff Thomas, Rolland Vida, and Margaret		Savola, Suzuki Shinsuke, Jaff Thomas, Rolland Vida, and Margaret
	Wasserman for comments and suggestions on this document.		Wasserman for comments and suggestions on this document.
	Furthermore, the following companies are acknowledged for their		Furthermore, the following companies are acknowledged for their
	contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks,		contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks,
	Hewlett-Packard, Vitesse Semiconductor Corporation, Thrane & Thrane		Hewlett-Packard, Vitesse Semiconductor Corporation, Thrane & Thrane
	The ordering of these names do not necessarily correspond to the		The ordering of these names do not necessarily correspond to the
	column numbers in the response table.		column numbers in the response table.
			MLD Snooping Switches
	8. Authors' Addresses		8. Authors' Addresses
	Morten Jagd Christensen		Morten Jagd Christensen
	Thrane & Thrane		Thrane & Thrane
	Lundtoftegaardsvej 93 D		Lundtoftegaardsvej 93 D
	2800 Lyngby		2800 Lyngby
	DENMARK		DENMARK
	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
	USA		USA
	email: karen.kimball@hp.com		email: karen.kimball@hp.com
	Frank Solensky		Frank Solensky
	West Ridge Networks		West Ridge Networks
	25 Porter Rd.		25 Porter Rd.
	Boxboro, MA 01719		Littleton, MA 01460
	USA		USA
	email: fsolensky@WestRidgeNetworks.com		email: fsolensky@WestRidgeNetworks.com
	9. IETF IPR Statement		9. IETF IPR Statement
	"The IETF takes no position regarding the validity or scope of any		"The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on		has made any effort to identify any such rights. Information on
	the IETF's procedures with respect to rights in standards-track and		the IETF's procedures with respect to rights in standards-track and
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	standards-related documentation can be found in [RFC-2026]. Copies		standards-related documentation can be found in [RFC-2026]. Copies
	of claims of rights made available for publication and any		of claims of rights made available for publication and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use		attempt made to obtain a general license or permission for the use
	of such proprietary rights by implementors or users of this		of such proprietary rights by implementors or users of this
	specification can be obtained from the IETF Secretariat."		specification can be obtained from the IETF Secretariat."
	10. Full Copyright Statement		10. Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain		others, and derivative works that comment on or otherwise explain
	it or assist in its implementation may be prepared, copied,		it or assist in its implementation may be prepared, copied,
			MLD Snooping Switches
	published and distributed, in whole or in part, without restriction		published and distributed, in whole or in part, without restriction
	of any kind, provided that the above copyright notice and this		of any kind, provided that the above copyright notice and this
	paragraph are included on all such copies and derivative works.		paragraph are included on all such copies and derivative works.
	However, this document itself may not be modified in any way, such		However, this document itself may not be modified in any way, such
	as by removing the copyright notice or references to the Internet		as by removing the copyright notice or references to the Internet
	Society or other Internet organizations, except as needed for the		Society or other Internet organizations, except as needed for the
	purpose of developing Internet standards in which case the		purpose of developing Internet standards in which case the
	procedures for copyrights defined in the Internet Standards process		procedures for copyrights defined in the Internet Standards process
	must be followed, or as required to translate it into languages		must be followed, or as required to translate it into languages
	other than English.		other than English.
	skipping to change at page 1, line 1106 ¶		skipping to change at page 1, line 1091 ¶
	ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR		ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgement:		Acknowledgement:
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
	RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003		MLD Snooping Switches
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. IGMP Snooping Recommendations . . . . . . . . . . . . . . . 3		2. IGMP Snooping Recommendations . . . . . . . . . . . . . . . 3
	2.1. Forwarding rules . . . . . . . . . . . . . . . . . . . . . 3		2.1. Forwarding rules . . . . . . . . . . . . . . . . . . . . . 3
	2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . . . 3		2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . . . 3
	2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . . . 6		2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . . . 6
	2.2. IGMP snooping-related problems . . . . . . . . . . . . . . 9		2.2. IGMP snooping-related problems . . . . . . . . . . . . . . 8
	3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 9		3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 9
	4. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . 11		4. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . 11
	4. Revision History . . . . . . . . . . . . . . . . . . . . . . 13		4. Revision History . . . . . . . . . . . . . . . . . . . . . . 12
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	5.1. Normative References . . . . . . . . . . . . . . . . . . . 19		5.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	5.2. Informative References . . . . . . . . . . . . . . . . . . 20		5.2. Informative References . . . . . . . . . . . . . . . . . . 19
	6. Security Considerations . . . . . . . . . . . . . . . . . . 20		6. Security Considerations . . . . . . . . . . . . . . . . . . 20
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
	8. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 22		8. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 21
	9. IETF IPR Statement . . . . . . . . . . . . . . . . . . . . . 22		9. IETF IPR Statement . . . . . . . . . . . . . . . . . . . . . 22
	10. Full Copyright Statement . . . . . . . . . . . . . . . . . 23		10. Full Copyright Statement . . . . . . . . . . . . . . . . . 22
	[To RFC Editor: The TOC page is to be moved to page 2 at		[To RFC Editor: The TOC page is to be moved to page 2 at
	publication time ]		publication time ]
	[To RFC Editor: Page renumbering in TOC and in document will be		[To RFC Editor: Page renumbering in TOC and in document will be
	necessary ]		necessary ]
End of changes. 58 change blocks.
	96 lines changed or deleted		81 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/