< draft-ietf-magma-snoop-09.txt		draft-ietf-magma-snoop-10.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: March 2004 K. Kimball
	Category: Informational Hewlett-Packard		Category: Informational Hewlett-Packard
	F. Solensky		F. Solensky
	August 2003		West Ridge Networks
			October 2003
	Considerations for IGMP and MLD Snooping Switches		Considerations for IGMP and MLD Snooping Switches
	<draft-ietf-magma-snoop-09.txt>		<draft-ietf-magma-snoop-10.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 48 ¶
	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.
			RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	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
	with [BRIDGE]. The spanning tree algorithm ensures that the		with [BRIDGE]. The spanning tree algorithm ensures that the
	skipping to change at page 1, line 95 ¶		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
	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
	directed to [IGMPv3] for a thorough description of problem areas.		directed to [IGMPv3] for a thorough description of problem areas.
	skipping to change at page 1, line 141 ¶		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
	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.
	Sending membership reports to other hosts can result, for		Sending membership reports to other hosts can result, for
	skipping to change at page 1, line 189 ¶		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
			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 snooping switches may also implement "proxy-reporting" in
	which reports received from downstream hosts are summarized and		which reports received from downstream hosts are summarized and
	used to build internal membership states as described in		used to build internal membership states as described in
	skipping to change at page 1, line 237 ¶		skipping to change at page 1, line 247 ¶
	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
	skipping to change at page 1, line 283 ¶		skipping to change at page 1, line 296 ¶
	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,
	skipping to change at page 1, line 332 ¶		skipping to change at page 1, line 347 ¶
	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.
	skipping to change at page 1, line 375 ¶		skipping to change at page 1, line 392 ¶
	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
	skipping to change at page 1, line 422 ¶		skipping to change at page 1, line 441 ¶
	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:
	skipping to change at page 1, line 470 ¶		skipping to change at page 1, line 492 ¶
	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,
	there are 2 ** (112 - (32 - 8)), or more than 7.9e28 unique DIP		there are 2 ** (112 - 32), or more than 1.2e24 unique DIP addresses
	addresses which map into a single DMAC address in Ethernet and		which map into a single DMAC address in Ethernet and FDDI. This
	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
	[RFC2735], however, cover only the lower 24 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
	forwarding is preferred to MAC address based forwarding.		forwarding is preferred to MAC address based forwarding.
	| 8 | 4 | 4 | 112 bits |		| 8 | 4 | 4 | 112 bits |
	+--------+----+----+---------------------------------------+		+--------+----+----+---------------------------------------+
	|11111111|flgs|scop| group ID |		|11111111|flgs|scop| group ID |
	+--------+----+----+---------------------------------------+		+--------+----+----+---------------------------------------+
	skipping to change at page 1, line 516 ¶		skipping to change at page 1, line 541 ¶
	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
	skipping to change at page 1, line 548 ¶		skipping to change at page 1, line 575 ¶
	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 578 ¶		skipping to change at page 1, line 607 ¶
	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-10.txt: October 2003
			The changes in this version are the result of the IESG review.
			Substantial comments
			The security considerations section was found a little
			too brief. It has now been extended.
			Editorial Changes
			Removed reference RFC2375, using RFC3307 instead. New
			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 628 ¶		skipping to change at page 1, line 673 ¶
	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 675 ¶		skipping to change at page 1, line 724 ¶
	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 723 ¶		skipping to change at page 1, line 774 ¶
	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 770 ¶		skipping to change at page 1, line 825 ¶
	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 817 ¶		skipping to change at page 1, line 874 ¶
	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
	skipping to change at page 1, line 863 ¶		skipping to change at page 1, line 922 ¶
	January 2003.		January 2003.
	[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		[PROXY] Fenner, B. et al, "IGMP/MLD-based Multicast
	Forwarding (IGMP/MLD Proxying)", draft-ietf-magma-		Forwarding (IGMP/MLD Proxying)", draft-ietf-magma-
	igmp-proxy-02.txt, November 2002.		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
			Multicast Addresses", RFC3307, August 2002.
	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-addresses		http://www.iana.org/assignments/multicast-addresses
	[CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP		[CISCO] Cisco Tech Notes, "Multicast In a Campus Network: 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 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		http://support.microsoft.com/support/articles/Q223/1/36.ASP
	[IETF56] Briefing by Dave Thaler, Microsoft, presented to the		[IETF56] Briefing by Dave Thaler, Microsoft, presented to the
	MAGMA WG at the 56'th IETF meeting in San Francisco,		MAGMA WG at the 56'th IETF meeting in San 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, July 1998.
	6. Security Considerations		6. Security Considerations
	Security considerations for IGMPv3/MLDv2 are accounted for in		Under normal network operation, the snooping switch is expected to
	[IGMPv3] and [MLDv2]. The introduction of IGMP/MLD snooping		improve overall network performance by limiting the scope of
	switches does not add any critical considerations with regard to IP		multicast flooding to a smaller portion of the local network. In
	multicast security issues.		the event of forged IGMP messages, the benefits of using a snooping
			switch might be reduced or eliminated.
	IGMP snooping switches which rely on the IP header of a packet for		Security considerations for IGMPv3 at the network layer of the
	their operation and which do not validate the header checksum,		protocol stack are described in [IGMPv3]. The introduction of IGMP
	potentially will forward packets on the wrong ports. Even though		snooping functionality does not alter the handling of multicast
	the IP headers are protected by a link layer checksum this is a		packets by the router as it does not make use of link layer
	potential vulnerability. However, the absence of a header checksum
	in IPv6 gives no means of checking the header integrity for these		RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003
	packets anyway so the implications for IPv4 are not considered
	critical.		information.
			There are, however, changes in the way that the IGMP snooping
			switch handles multicast packets within the local network. In
			particular:
			- A Query message with a forged source address which is less than
			that of the current Querier could cause snooping switches to
			forward subsequent Membership reports to the wrong network
			interface. It is for this reason that IGMP Membership Reports
			should be sent to all multicast routers as well as the current
			Querier.
			- It is possible for a host on the local network to generate
			Current-State Report Messages that would cause the switch to
			incorrectly believe that there is a multicast listener on the
			same network segment as the originator of the forged message.
			This will cause unrequested multicast packets to be forwarded
			into the network segments between the source and the router.
			If the router requires that all Multicast Report messages be
			authenticated as described in section 9.4 of [IGMPv3], it will
			discard the forged Report message from the host inside the
			network in the same way that it would discard one which
			originates from a remote location. It is worth noting that if
			the router accepts unauthenticated Report messages by virtue of
			them having arrived over a network interface associated with
			the internal network, investigating the affected network
			segments will quickly narrow the search for the source of the
			forged messages.
			- As noted in [IGMPv3], there is little motivation for an
			attacker to forge a Membership report message since joining a
			group is generally an unprivileged operation. The sender of
			the forged Membership report will be the only recipient of the
			multicast traffic to that group. This is in contrast to a
			shared LAN segment (HUB) or network without snooping switches,
			where all other hosts on the same segment would be unable to
			transmit when the network segment is flooding the unwanted
			traffic.
			The worst case result for each attack would remove the performance
			improvements that the snooping functionality would otherwise
			provide. It would, however, be no worse than that experienced on a
			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. The ordering		Hewlett-Packard, Vitesse Semiconductor Corporation, Thrane & Thrane
	of these names do not necessarily correspond to the column numbers		The ordering of these names do not necessarily correspond to the
	in the response table.		column numbers in the response table.
	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
	email: solenskyf@acm.org		West Ridge Networks
			25 Porter Rd.
			Boxboro, MA 01719
			USA
			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.
	skipping to change at page 1, line 992 ¶		skipping to change at page 1, line 1106 ¶
	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
	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 . . . . . . . . . . . . . . 9
	3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 9		3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 9
	4. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . 11		4. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . 11
	4. Revision History . . . . . . . . . . . . . . . . . . . . . . 13		4. Revision History . . . . . . . . . . . . . . . . . . . . . . 13
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		5. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	5.1. Normative References . . . . . . . . . . . . . . . . . . . 18		5.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	5.2. Informative References . . . . . . . . . . . . . . . . . . 19		5.2. Informative References . . . . . . . . . . . . . . . . . . 20
	6. Security Considerations . . . . . . . . . . . . . . . . . . 20		6. Security Considerations . . . . . . . . . . . . . . . . . . 20
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
	8. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 21		8. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 22
	9. IETF IPR Statement . . . . . . . . . . . . . . . . . . . . . 21		9. IETF IPR Statement . . . . . . . . . . . . . . . . . . . . . 22
	10. Full Copyright Statement . . . . . . . . . . . . . . . . . 21		10. Full Copyright Statement . . . . . . . . . . . . . . . . . 23
	[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. 35 change blocks.
	33 lines changed or deleted		147 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/