< draft-ietf-magma-snoop-01.txt		draft-ietf-magma-snoop-02.txt >
	MAGMA Working Group M. Christensen		MAGMA Working Group M. Christensen
	Internet Draft jCAPS		Internet Draft morten@jagd-christensen.com
	January 2002 F. Solensky		June 2002 F. Solensky
	Expiration Date: July 2002		Expiration Date: December 2002 Premonitia
	IGMP and MLD snooping switches		IGMP and MLD snooping switches
	<draft-ietf-magma-snoop-01.txt>		<draft-ietf-magma-snoop-02.txt>
	Status of this Memo		Status of this Memo
	This document is the successor of draft-ietf-magma-snoop-00 which was		This document is an Internet-Draft and is in full conformance with
	presented at the 52'nd IETF in Salt Lake City. The main differences		all provisions of Section 10 of RFC2026 [RFC2026].
	between this and the previous version is a restructuring of the draft
	to introduce the main result as early as possible. Also the draft has
	been trimmed to a smaller size. No new results are presented, as the
	draft is expected to published as Informational within the next four
	months.
	This document is an Internet-Draft and is in full conformance with
	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 other		Task Force (IETF), its areas, and its working groups. Note that
	groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as Internet-
			Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six
	and may be updated, replaced, or obsoleted by other documents at any		months and may be updated, replaced, or obsoleted by other docu¡
	time. It is inappropriate to use Internet-Drafts as reference		ments at any time. It is inappropriate to use Internet-Drafts as
	material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in
			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.
	Abstract		Abstract
	This memo describes the requirements for IGMP and MLD snooping		This memo describes the requirements for IGMP and MLD snooping
	switches. The requirements for IGMPv2 snooping switches are based on		switches. The requirements for IGMPv2 snooping switches are based
	best current practices. IGMPv3 and MLDv2 snooping are also covered in		on best current practices. IGMPv3 and MLDv2 snooping are also cov¡
	this draft although we are not aware of any such implementations at		ered in this draft although we are not aware of any such implemen¡
	the time of writing.		tations at the time of writing. Areas which are of relevance to
			IGMP and MLD snooping switches, such as link layer topology changes
	RFC DRAFT January 2001		and Ethernet specific encapsulation issues are also considered.
	The memo also describes the interoperability problems and issues that
	can arise when a mixed deployment of IGMPv3 and IGMPv2 capable hosts
	and routers are interconnected by a switch with IGMP snooping
	capabilities.
	Areas which are of relevance to IGMP and MLD snooping switches, such
	as link layer topology changes and Ethernet specific encapsulation
	issues are also considered.
	It is intended as an accompanying document to the IGMPv3 and MLDv2
	specifications.
	1. Introduction
	In recent years, a number of commercial vendors have introduced prod-
	ucts described as "IGMP snooping switches" to the market. These
	devices do not adhere to the conceptual model that provides the
	strict separation of functionality between different communications
	layers in the ISO model and instead utilizes information in the upper
	level protocol headers as factors to be considered in the processing
	at the lower levels.
	This is analogous to the manner in which a router can act as a fire-		Interoperability issues that arise betweed different versions of
	wall by looking into the transport protocol's header before allowing		IGMP are not discussed in this document. Interested readers are
	a packet to be forwarded to its destination address.		directed to [IGMPv3] for a thorough description of problem area.
	In the case of multicast traffic, an IGMP snooping switch provides		This document is intended as an accompanying document to the IGMPv3
	the benefit of conserving bandwidth on those segments of the network		and MLDv2 specifications.
	where no node has expressed interest in receiving packets addressed
	to the group address. This is in contrast to normal switch behaviour
	where multicast traffic is typically forwarded on all interfaces.
	Many switch datasheets state support for IGMP snooping, but no		11.. IInnttrroodduuccttiioonn
	requirements for this exist today. It is the authors hope that the
	information presented in this draft will supply this information.
	The requirements presented here is based on the following information		When a packet with a broadcast or multicast destination address is
	sources: The IGMP specifications [RFC112][RFC2236][IGMPv3], vendor		received, the switch will forward a copy into each of the remaining
	supplied technical documents [CISCO], bug reports [MSOFT], discus-		network segments in accordance with [BRIDGE]. Eventually, the
	sions with people invovled in design of IGMP snooping switches, MAGMA		packet is made accessible to all nodes connected to the network.
	mailinglist discussions, and on replies by switch vendors to an
	implementation questionnaire.
	The discussions in this document are based on IGMP which applies to		This approach works well for broadcast packets that are intended to
	IPv4 only. For IPv6 we must use MLD instead. Because MLD is based on		be seen or processed by all connected nodes. In the case of multi¡
	IGMP we do not repeat the whole discussion and requirements for MLD		cast packets, however, this approach could lead to less efficient
			use of network bandwidth, particularly when the packet is intended
			for only a small number of nodes. Packets will be flooded into
			network segments where no node has any interest in receiving the
			packet. While nodes will rarely incur any processing overhead to
			filter packets addressed to unrequested group addresses, they are
			unable to transmit new packets onto the shared media for the period
			of time that the multicast packet is flooded.
	RFC DRAFT January 2001		The problem of wasting bandwidth is even worse when the LAN segment
			is not shared, for example in Full Duplex links. Full Duplex is
			standard today for most switches operating at 1Gbps or above. In
			this case the bandwidth that is wasted is proportional to the num¡
			ber of attached nodes.
	snooping switches. Instead we point out the few cases where there is		In recent years, a number of commercial vendors have introduced
	a difference compared to IGMP.		products described as "IGMP snooping switches" to the market.
			These devices do not adhere to the conceptual model that provides
			the strict separation of functionality between different communica¡
			tions layers in the ISO model and instead utilizes information in
			the upper level protocol headers as factors to be considered in the
			processing at the lower levels. This is analogous to the manner in
			which a router can act as a firewall by looking into the transport
			protocol's header before allowing a packet to be forwarded to its
			destination address.
	2. IGMP Snooping Requirements		In the case of multicast traffic, an IGMP snooping switch provides
			the benefit of conserving bandwidth on those segments of the net¡
			work where no node has expressed interest in receiving packets
			addressed to the group address. This is in contrast to normal
			switch behaviour where multicast traffic is typically forwarded on
			all interfaces.
	The following sections list the requirements for an IGMP snooping		Many switch datasheets state support for IGMP snooping, but no
	switch. The requirement is stated and is supplemented by a discus-		requirements for this exist today. It is the authors hope that the
	sion. All implementation discussions are examples only and there may		information presented in this draft will supply this information.
	well be other ways to achieve the same functionality.
	2.1. Forwarding rules		The requirements presented here is based on the following informa¡
			tion sources: The IGMP specifications [RFC112][RFC2236][IGMPv3],
			vendor supplied technical documents [CISCO], bug reports [MSOFT],
			discussions with people invovled in design of IGMP snooping
			switches, MAGMA mailinglist discussions, and on replies by switch
			vendors to an implementation questionnaire.
	The IGMP snooping functionality is here separated in a control section		The discussions in this document are based on IGMP which applies to
	(IGMP forwarding) and data section (Data forwarding).		IPv4 only. For IPv6 we must use MLD instead. Because MLD is based
			on IGMP we do not repeat the whole discussion and requirements for
			MLD snooping switches. Instead we point out the few cases where
			there is a difference compared to IGMP.
	2.1.1. IGMP Forwarding Rules		22.. IIGGMMPP SSnnooooppiinngg RReeqquuiirreemmeennttss
	1) A snooping switch MUST only forward IGMP Membership Reports on ports		The following sections list the requirements for an IGMP snooping
	where multicast routers are attached. Alternatively stated: A snooping		switch. The requirement is stated and is supplemented by a discus¡
	switch MUST NOT forward IGMP Membership Reports to ports on which only		sion. All implementation discussions are examples only and there
	hosts are attached.		may well be other ways to achieve the same functionality.
	This is the main IGMP snooping functionality. Sending membership reports		22..11.. FFoorrwwaarrddiinngg rruulleess
	to other hosts can result (For IGMPv2 and IGMPv1) in the unwanted pre-
	vention of a host wishing to join a specific multicast group. This is
	not a problem in a IGMPv3 only network because there is no cancellation
	of IGMP Membership reports.
	The switch supporting IGMP snooping MUST maintain a list of multicast		The IGMP snooping functionality is here separated in a control sec¡
	routers and the ports on which they are attached. This list SHOULD be		tion (IGMP forwarding) and data section (Data forwarding).
	built using IGMP Multicast Router Discovery [MRDISC]. IGMP snooping
	switches MAY alternatively build this list based on
	a) The arrival port for IGMP Queries (sent by multicast routers) or		22..11..11.. IIGGMMPP FFoorrwwaarrddiinngg RRuulleess
	b) List of ports configured (by management) as having multicast routers		1) A snooping switch SHOULD forward IGMP Membership Reports only
	attached.		to those ports where multicast routers are attached. Alterna¡
			tively stated: A snooping switch SHOULD NOT forward IGMP Mem¡
			bership Reports to ports on which only hosts are attached. An
			administrative control MAY be provided to override this
			restriction, allowing the report messages to be flooded to
			other ports.
	Implementation example: IGMP snooping can be achieved by redirecting all		This is the main IGMP snooping functionality. Sending member¡
	IGMP packets (IP packets with IP-PROTO = 2) to the CPU (or similar		ship reports (as described in IGMP versions 1 and 2) to other
	higher layer entity) for IGMP message processing and table management.		hosts can result in unintentionally preventing a host from
			joining a specific multicast group. This is not a problem in
			an IGMPv3 only network because there is no cancellation of IGMP
			Membership reports.
	2) IGMP snooping switches MAY implement "proxy-reporting" in which		The administrative control allows IGMP Membership Report mes¡
	RFC DRAFT January 2001		sages to be processed by network monitoring equipment such as
			packet analysers or port replicators.
	reports received from downstream hosts are summarized and used to build		The switch supporting IGMP snooping MUST maintain a list of
	internal membership states. An IGMP proxy-reporting switch would then		multicast routers and the ports on which they are attached.
	report it's own state in response to upstream queriers. If the switch		This list can be constructed in any combination of the follow¡
	does not have an IP address it SHOULD use the address 0.0.0.0 as source		ing ways:
	in these reports.
	An IGMP proxy-reporting switch may act as Querier for the downstream		a) This list SHOULD be built using IGMP Multicast Router Dis¡
	hosts while proxy reporting to the 'real' upstream queriers.		covery [MRDISC] by the snooping switch sending Multicast
			Router Solicitation messages on its own. It MAY also snoop
			Multicast Router Advertisement messages sent by and to
			other nodes.
	It should be noted that there may be multiple IGMP proxy-reporting		b) The arrival port for IGMP Queries (sent by multicast
	switches in the network all using the 0.0.0.0 source IP address. In this		routers) where the source where the address is not 0.0.0.0.
	case the switches can be identified by their, link layer source MAC
	address.
	IGMP membership reports should not be rejected because of a source IP		c) A list of ports configured by management as described in
	address of 0.0.0.0.		the previous step.
	3) The switch that supports IGMP snooping MUST forward all unrecognized		2) IGMP snooping switches MAY implement "proxy-reporting" in which
	IGMP messages and MUST NOT attempt to make use of any information beyond		reports received from downstream hosts are summarized and used
	the end of the network layer header. In particular, messages where any		to build internal membership states as described in [PROXY].
	reserved fields are non-zero MUST NOT be subject to "normal" snooping		An IGMP proxy-reporting switch would then report its own state
	since this could indicate an incompatible change to the message format.		in response to upstream queriers. If the switch does not
			alreay have an IP address it SHOULD use the address 0.0.0.0 as
			source in these reports.
	4) An IGMP snooping switch SHOULD be aware of link layer topology		An IGMP proxy-reporting switch may act as Querier for the down¡
	changes. Following a topology change the switch SHOULD initiate the		stream hosts while proxy reporting to the 'real' upstream
	transmission of a General Query on all ports in order to reduce network		queriers.
	convergence time.
	5) An IGMP snooping switch MUST discard from the IGMP snooping process		It should be noted that there may be multiple IGMP proxy-
	IGMP packets where IP or IGMP headers have checksum errors.		reporting switches in the network all using the 0.0.0.0 source
			IP address. In this case the switches can be uniquely identi¡
			fied through their link layer source MAC address.
	2.1.2. Data Forwarding Rules		IGMP membership reports MUST NOT be rejected because of a
			source IP address of 0.0.0.0; however, these messages MUST NOT
			be included the election process so that a snooping switch does
			not elected over an active router.
	6) Packets with a destination IP (DIP) address in the 224.0.0.X range		3) The switch that supports IGMP snooping MUST flood all unrecog¡
	which are *not* IGMP MUST be forwarded on all ports.		nized IGMP messages to all other ports and MUST NOT attempt to
			make use of any information beyond the end of the network layer
			header. In particular, messages where any reserved fields in
			the IGMP header are non-zero MUST NOT be subject to "normal"
			snooping since this could indicate an incompatible change to
			the IGMP message format.
	This requirement is based on fact that many hosts exist today, which		4) An IGMP snooping switch SHOULD be aware of link layer topology
	does not Join IP multicast addresses in this range before sending or		changes. Following a topology change the switch SHOULD initi¡
	listening to IP multicast. Furthermore since the 224.0.0.X address range		ate the transmission of a General Query on all ports in order
	is defined as link local (not to be routed) it seems unnecessary to keep		to reduce network convergence time.
	state for each address in this range.
	7) Packets with a destination IP address outside 224.0.0.X which are		5) An IGMP snooping switch MUST NOT make use of information in
	*not* IGMP SHOULD be forwarded according to group based port membership		IGMP packets where the IP or IGMP headers have checksum or
	RFC DRAFT January 2001		intregity errors. The switch SHOULD NOT flood such packets but
			if it does, it SHOULD take some note of the event (i.e.: incre¡
			ment a counter). These errors and their processing are further
			discussed in [IGMPv3], [MLD] and [MLDv2].
	tables and MUST also be forwarded on router ports.		22..11..22.. DDaattaa FFoorrwwaarrddiinngg RRuulleess
	This is the core IGMP snooping requirement for the data path.		1) Packets with a destination IP (DIP) address in the 224.0.0.X
			range which are not IGMP MUST be forwarded on all ports.
	Discussion: An implementation could maintain separate membership and		This requirement is based on fact that many hosts exist today,
	multicast router tables in software and then "merge" these tables into a		which does not Join IP multicast addresses in this range before
	current forwarding cache.		sending or listening to IP multicast. Furthermore since the
			224.0.0.X address range is defined as link local (not to be
			routed) it seems unnecessary to keep state for each address in
			this range.
	8) If a switch receives a *non* IGMP multicast packet without having		2) Packets with a destination IP address outside 224.0.0.X which
	first processed Membership Reports for the group address, it MUST for-		are not IGMP SHOULD be forwarded according to group based port
	ward the packet on all ports. In other words, the switch must allow for		membership tables and MUST also be forwarded on router ports.
	the possibility that connected hosts and routers have been upgraded to
	support future versions or extensions of IGMP that the switch does not
	yet recognize. A switch MAY have a configuration option that suppresses
	this operation, but default behavior MUST be to allow flooding of unreg-
	istered packets.
	9) IGMP snooping switches MAY maintain forwarding tables based on either		This is the core IGMP snooping requirement for the data path.
	MAC addresses or IP addresses. If a switch supports both types of for-
	warding tables then the default behavior MUST be to use IP addresses.
	Discussion: Forwarding based on MAC addresses is subject to the problem		Discussion: An implementation could maintain separate member¡
	associated with the 32-fold IP address to 1 MAC address mapping.		ship and multicast router tables in software and then "merge"
			these tables into a current forwarding cache.
	10) Switches which rely on information in the IP header SHOULD verify		3) If a switch receives a non-IGMP multicast packet without having
	that the IP header checksum is correct. If the checksum fails the packet		first processed Membership Reports for the group address, it
	SHOULD be silently discarded.		MAY forward the packet on all ports, but it MUST forward the
			packet on router ports. A switch MAY forward an unregistered
			packet only on router ports, but the switch MUST have a config¡
			uration option that suppresses this restrictive operation and
			forces flooding of unregistered packets on all ports.
	2.2. IGMP snooping related problems		4) IGMP snooping switches MAY maintain forwarding tables based on
			either MAC addresses or IP addresses. If a switch supports
			both types of forwarding tables then the default behavior
			SHOULD be to use IP addresses.
	A special problem arise in the network consisting of IGMPv3 routers as		Discussion: Forwarding based on MAC addresses is subject to the
	well as IGMPv2 and IGMPv3 hosts interconnected by a IGMPv2 snooping		problem associated with the 32-fold IP address to 1 MAC address
	switch. IGMPv3 has a mechanism to fall back to IGMPv2 when receiving		mapping.
	IGMPv2 membership reports. This means that the network will converged on
	IGMPv2 eventually. However, the convergence time will lead to supression
	of v3 Hosts for several minutes.
	Therefore it is recommended that in such a network, the multicast router		5) Switches which rely on information in the IP header SHOULD ver¡
	is configured to use IGMPv2.		ify that the IP header checksum is correct. If the checksum
			fails, the information in the packet MUST NOT be incorporated
			into the forwarding table. Further, the packet SHOULD be dis¡
			carded.
	3. IPv6 Considerations		22..22.. IIGGMMPP ssnnooooppiinngg rreellaatteedd pprroobblleemmss
	In order to avoid confusion, the previous discussions have been based		A special problem arise in the network consisting of IGMPv3 routers
	on IGMPv3 functionality which only applies to IPv4 multicast. In the		as well as IGMPv2 and IGMPv3 hosts interconnected by a IGMPv2
	case of IPv6 most of the above discussions are still valid with a few		snooping switch. IGMPv3 has a mechanism to fall back to IGMPv2
			when receiving IGMPv2 membership reports. This means that the net¡
			work will converged on IGMPv2 eventually. However, the convergence
			time will lead to supression of v3 Hosts for several minutes.
	RFC DRAFT January 2001		Therefore it is recommended that in such a network, the multicast
			router is configured to use IGMPv2.
	exceptions which we will describe here.		33.. IIPPvv66 CCoonnssiiddeerraattiioonnss
	In IPv6 the protocol for multicast group maintenance is called Multi-		In order to avoid confusion, the previous discussions have been
	cast Listener Discovery (MLDv2). IPv6 is not widely deployed today		based on IGMPv3 functionality which only applies to IPv4 multicast.
	and neither is IPv6 multicast. However, it is anticipated that at		In the case of IPv6 most of the above discussions are still valid
	some time IPv6 switches capable of MLD snooping will appear.		with a few exceptions which we will describe here.
	The three main differences between IGMPv3 and MLDv2 are		In IPv6 the protocol for multicast group maintenance is called Mul¡
			ticast Listener Discovery (MLDv2). IPv6 is not widely deployed
			today and neither is IPv6 multicast. However, it is anticipated
			that at some time IPv6 switches capable of MLD snooping will
			appear.
	- MLDv2 uses ICMPv6 message types instead of IGMP message types.		The three main differences between IGMPv3 and MLDv2 are:
	- The ethernet encapsulation is a mapping of 32bits of the 128bit		- MLDv2 uses ICMPv6 message types instead of IGMP message types.
	DIP addresses into 48bit DMAC addresses [IPENCAPS].
	- Multicast router discovery is done using Neighbor Discovery Pro-		- The ethernet encapsulation is a mapping of 32 bits of the 128
	tocol (NDP) for IPv6. NDP uses ICMPv6 message types.		bit DIP addresses into 48 bit DMAC addresses [IPENCAPS].
	A minor difference which applies to the requirements section is that in		- Multicast router discovery is done using Neighbor Discovery Pro¡
	IPv6 there is no checksum in the IP header. This is the reason that the		tocol (NDP) for IPv6. NDP uses ICMPv6 message types.
	checksum validation requirement is listed as a MAY.
	The fact that MLDv2 is using ICMPv6 adds new requirements to a snooping		The IPv6 packet header does not include a checksum field. Never¡
	switch because ICMPv6 has multiple uses aside from MLD. This means that		theless, the switch SHOULD detect other packet integrity issues.
	it is no longer sufficient to detect that the next-header field of the		When the snooping switch detects such an error, it MUST NOT include
	IP header is ICMPv6 in order to redirect packets to the CPU. If this		information from the corresponding packet in the IGMP forwarding
	was the case the CPU queue assigned for MLD would potentially be filled		table. The forwarding code SHOULD drop the packet and take further
	with non-MLD related packets. Furthermore ICMPv6 packets destined for		reasonable actions as advocated above.
	other hosts would not reach their destination. A solution is either to
	require that the snooping switch looks further into the packets or to be
	able to detect a multicast DMAC address in conjunction with ICMPv6. The
	first solution is desirable only if it is configurable which message
	types should trigger a CPU redirect and which should not. The reason is
	that a hardcoding of message types is unflexible for the introduction of
	new message types. The second solution introduces the risk of new pro-
	tocols, which are not related to MLD but uses ICMPv6 and multicast DMAC
	addresses wrongly being identified as MLD. It is suggested that solution
	one is the preferred if the switch is capable of triggering CPU redi-
	rects on individual ICMPv6 message types. If this is not the case then
	use solution two.
	The mapping from IP multicast addresses to multicast DMAC addresses		The fact that MLDv2 is using ICMPv6 adds new requirements to a
	introduces a potentially enormous overlap. The structure of an IPv6 mul-		snooping switch because ICMPv6 has multiple uses aside from MLD.
	ticast address is shown in figure 5. Theoretically 2**80, two to the		This means that it is no longer sufficient to detect that the next-
	power of 80 (128 - 8 - 4 - 4 - 32) unique DIP addresses could map to one		header field of the IP header is ICMPv6 in order to redirect pack¡
	DMAC address. This should be compared to 2**5 in the case of IPv4.		ets to the CPU. If this was the case the CPU queue assigned for
			MLD would potentially be filled with non-MLD related packets. Fur¡
			thermore ICMPv6 packets destined for other hosts would not reach
			their destination. A solution is either to require that the snoop¡
			ing switch looks further into the packets or to be able to detect a
			multicast DMAC address in conjunction with ICMPv6. The first solu¡
			tion is desirable only if it is configurable which message types
			should trigger a CPU redirect and which should not. The reason is
			that a hardcoding of message types is unflexible for the introduc¡
			tion of new message types. The second solution introduces the risk
			of new protocols, which are not related to MLD but uses ICMPv6 and
			multicast DMAC addresses wrongly being identified as MLD. It is
			suggested that solution one is the preferred if the switch is capa¡
			ble of triggering CPU redirects on individual ICMPv6 message types.
			If this is not the case then use solution two.
	Initial allocation of IPv6 multicast addresses, however, uses only the		The mapping from IP multicast addresses to multicast DMAC addresses
	RFC DRAFT January 2001		introduces a potentially enormous overlap. The structure of an IPv6
			multicast address is shown in figure 5. Theoretically 2**80, two
			to the power of 80 (128 - 8 - 4 - 4 - 32) unique DIP addresses
			could map to one DMAC address. This should be compared to 2**5 in
			the case of IPv4.
	lower 32 bits of group ID. This eliminates the address ambiguity for the		Initial allocation of IPv6 multicast addresses, however, uses only
	time being but it should be noted that the allocation policy may change		the lower 32 bits of group ID. This eliminates the address ambigu¡
	in the future.		ity for the time being but it should be noted that the allocation
			policy may change in the future.
	| 8 | 4 | 4 | 112 bits |		| 8 | 4 | 4 | 112 bits |
	+--------+----+----+---------------------------------------+		+--------+----+----+---------------------------------------+
	|11111111|flgs|scop| group ID |		|11111111|flgs|scop| group ID |
	+--------+----+----+---------------------------------------+		+--------+----+----+---------------------------------------+
	Figure 5		Figure 5
	In the case of IPv6 forwarding can be made on the basis of DMAC		In the case of IPv6 forwarding can be made on the basis of DMAC
	addresses in the forseable future.		addresses in the forseable future.
	Finally, we mention the reserved address range FF0X:0:0:0:0:0:X:X where
	X is any value. This range is similar to 224.0.0.X for IPv4 and is
	reserved to routing protocols and resource discovery [RFC2375]. In the
	case of IPv6 it is suggested that packets in this range are forwarded on
	all ports if they are not MLD packets.
	4. Security Considerations
	Security considerations for IGMPv3 are accounted for in [IGMPv3].		Finally, we mention the reserved address range FF02::/96. This
	The introduction of IGMP snooping switches adds the following consid-		range is similar to 224.0.0.X for IPv4 and is reserved to routing
	erations with regard to IP multicast.		protocols and resource discovery [RFC2375]. In the case of IPv6 it
			is suggested that packets in this range are forwarded on all ports
			if they are not MLD packets.
	The exclude source failure which could cause traffic from sources		44.. SSeeccuurriittyy CCoonnssiiddeerraattiioonnss
	that are 'black listed' to reach hosts that have requested otherwise.
	This can also occur in certain network topologies without IGMP snoop-
	ing.
	It is possible to generate packets which make the switch wrongly		Security considerations for IGMPv3 are accounted for in [IGMPv3].
	believe that there is a multicast router on the segment on which the		The introduction of IGMP snooping switches adds the following con¡
	source is attached. This will potentially lead to excessive flooding		siderations with regard to IP multicast.
	on that segment. The authentication methods discussed in [IGMPv3]
	will also provide protection in this case.
	IGMP snooping switches which rely on the IP header of a packet for		The exclude source failure which could cause traffic from sources
	their operation and which do not validate the header checksum poten-		that are 'black listed' to reach hosts that have requested other¡
	tially will forward packets on the wrong ports. Even though the IP		wise. This can also occur in certain network topologies without
	headers are protected by the ethernet checksum this is a potential		IGMP snooping.
	vulnerability.
	Generally though, it is worth to stress that IP multicast must so far		It is possible to generate packets which make the switch wrongly
	be considered insecure until the work of for example the suggested		believe that there is a multicast router on the segment on which
	Multicast Security (MSEC) working group or similar is completed or at		the source is attached. This will potentially lead to excessive
	least has matured.		flooding on that segment. The authentication methods discussed in
			[IGMPv3] will also provide protection in this case.
	RFC DRAFT January 2001		IGMP snooping switches which rely on the IP header of a packet for
			their operation and which do not validate the header checksum
			potentially will forward packets on the wrong ports. Even though
			the IP headers are protected by the ethernet checksum this is a
			potential vulnerability.
	5. IGMP Questionnaire		Generally though, it is worth to stress that IP multicast must so
			far be considered insecure until the work of for example the sug¡
			gested Multicast Security (MSEC) working group or similar is com¡
			pleted or at least has matured.
	As part of this work the following questions were asked both on the		55.. IIGGMMPP QQuueessttiioonnnnaaiirree
	MAGMA discussion list and sent to known switch vendors implementing IGMP
	snooping. The individual contributions have been anonymized upon
	request.
	The questions were:		As part of this work the following questions were asked both on the
			MAGMA discussion list and sent to known switch vendors implementing
			IGMP snooping. The individual contributions have been anonymized
			upon request and do not necessarily apply to all of the vendors'
			products.
	Q1 Does your switches perform IGMP Join aggregation? In other words,		The questions were:
	are IGMP joins intercepted, absorbed by the hardware/software so that
	only one Join is forwarded to the querier?
	Q2 Is multicast forwarding based on MAC addresses? Would datagrams		Q1 Does your switches perform IGMP Join aggregation? In other
	addressed to multicast IP addresses 224.1.2.3 and 239.129.2.3 be for-		words, are IGMP joins intercepted, absorbed by the hard¡
	warded on the same ports-groups?		ware/software so that only one Join is forwarded to the
			querier?
	Q3 Is it possible to forward multicast datagrams based on IP addresses		Q2 Is multicast forwarding based on MAC addresses? Would data¡
	(not routed). In other words, could 224.1.2.3 and 239.129.2.3 be for-		grams addressed to multicast IP addresses 224.1.2.3 and
	warded on different port-groups with unaltered TTL?		239.129.2.3 be forwarded on the same ports-groups?
	Q4 Are multicast datagrams within the range 224.0.0.1 to 224.0.0.255		Q3 Is it possible to forward multicast datagrams based on IP
	forwarded on all ports whether or not IGMP Joins have been sent?		addresses (not routed). In other words, could 224.1.2.3 and
			239.129.2.3 be forwarded on different port-groups with unal¡
			tered TTL?
	Q5 Are multicast frames within the MAC address range 01:00:5E:00:00:01		Q4 Are multicast datagrams within the range 224.0.0.1 to
	to 01:00:5E:00:00:FF 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?
	Q6 Does your switch support forwarding to ports on which IP multicast		Q5 Are multicast frames within the MAC address range
	routers are attached in addition to the ports where IGMP Joins have been		01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports
	received?		whether or not IGMP joins have been sent?
	Q7 Is your IGMP snooping functionality fully implemented in hardware?		Q6 Does your switch support forwarding to ports on which IP multi¡
			cast routers are attached in addition to the ports where IGMP
			Joins have been received?
	Q8 Is your IGMP snooping functionality partly software implemented?		Q7 Is your IGMP snooping functionality fully implemented in hard¡
			ware?
	Q9 Can topology changes (for example spanning tree configuration		Q8 Is your IGMP snooping functionality partly software imple¡
	changes) be detected by the IGMP snooping functionality so that for		mented?
	example new queries can be sent or tables can be updated to ensure
	robustness?
	The answers were:		Q9 Can topology changes (for example spanning tree configuration
			changes) be detected by the IGMP snooping functionality so that
			for example new queries can be sent or tables can be updated to
			ensure robustness?
	RFC DRAFT January 2001		The answers were:
	---------------------------------------------		---------------------------+-----------------------+
	Switch Vendor		| Switch Vendor |
	-------------------------+---+---+---+---+---		---------------------------+---+---+---+---+---+---+
	| 1 | 2 | 3 | 4 |		| 1 | 2 | 3 | 4 | 5 | 6 |
	-------------------------+---+---+---+---+---		---------------------------+---+---+---+---+---+---+
	Q1 Join aggregation | x | x | x | |		Q1 Join aggregation | x | x | x | | x | x |
	Q2 Layer-2 forwarding | x | x | x | x |		Q2 Layer-2 forwarding | x | x | x | x |(1)| |
	Q3 Layer-3 forwarding |(1)| |(1)| |		Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x |
	Q4 224.0.0.X aware |(1)| x |(1)|(2)|		Q4 224.0.0.X aware |(1)| x |(1)|(2)| x | x |
	Q5 1:00:5e:0:0:X aware | x | x | x |(2)|		Q5 01:00:5e:00:00:XX aware | x | x | x |(2)| x | x |
	Q6 Mcast router list | x | x | x | x |		Q6 Mcast router list | x | x | x | x | x | x |
	Q7 Hardware implemented | | | | |		Q7 Hardware implemented | | | | | | |
	Q8 Software assisted | x | x | x | x |		Q8 Software assisted | x | x | x | x | x | x |
	Q9 Topology change aware | x | x | x | x |		Q9 Topology change aware | x | x | x | x | |(2)|
	-------------------------+---+---+---+---+---		---------------------------+---+---+---+---+---+---+
	x Means that the answer was Yes.		x Means that the answer was Yes.
	(1) In some products (typically high-end) Yes, in others No.		(1) In some products (typically high-end) Yes, in others No.
	(2) Currently no, but will be real soon.		(2) Currently no, but will be real soon.
	6. IPR Issues		66.. RReeffeerreenncceess
	It appears that a number of patents have been filed which may apply to
	this draft or parts thereof. None of these patents, listed below, have
	been filed by the authors of this draft or companies in which they are
	or have been employed.
	We, the authors, have not tried to evaluate whether these patents are
	violated by implementing IGMP snooping according to this document. The
	IETF/IESG have been notified about the patents.
	International patent: WO 96/34474, Oct. 31 1996, Title: "Broadcast
	transmission in a data network"
	US patent: Number 5,608,726, Mar. 4, 1997 (filed 1995) Title: "Network-
	ing Bridge with Multicast forwarding table"
	US patent: Number 5,898,686, Apr. 27, 1999 (filed 1996) Title: "Network-
	ing Bridge with Multicast forwarding table"
	Australian patent: Application No. 65440/98 Title: "System, Device, and
	Method for Managing Multicast Group Memberships in a Multicast Network"
	RFC DRAFT January 2001
	7. References
	[BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges"		[BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges"
	[CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP		[CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP
	and IGMP snooping", http://www.cisco.com/warp/pub-		and IGMP snooping", http://www.cisco.com/warp/pub¡
	lic/473/22.html		lic/473/22.html
	[IANA] Internet Assigned Numbers Authority, "Internet Multicast		[IANA] Internet Assigned Numbers Authority, "Internet Multicast
	Addresses", http://www.isi.edu/in-notes/iana/assign-		Addresses", http://www.isi.edu/in-notes/iana/assign¡
	ments/multicast-addresses		ments/multicast-addresses
	[IGMPv3] Cain, B., "Internet Group Management Protocol, Version		[IGMPv3] Cain, B., "Internet Group Management Protocol, Version
	3", draft-ietf-idmr-igmp-v3-06.txt, November 2000		3", draft-ietf-idmr-igmp-v3-11.txt, May 2002.
	[IPENCAPS] Crawford, M., "Transmission of IPv6 Packets over Ether-		[IPENCAPS] Crawford, M., "Transmission of IPv6 Packets over Ether¡
	net Networks", RFC2464, December 1998.		net Networks", RFC2464, December 1998.
			[MLD] Deering, S., Fenner, B., and Haberman, B. "Multicast
			Listener Discovery (MLD) for IPv6", RFC2710, October
			1999.
	[MLDv2] Vida, R., "Multicast Listener Discovery Version 2		[MLDv2] Vida, R., "Multicast Listener Discovery Version 2
	(MLDv2) for IPv6", draft-vida-mld-v2-00.txt, February		(MLDv2) for IPv6", draft-vida-mld-v2-03.txt, June 2002.
	2001.
	[MRDISC] Biswas, S. "IGMP Multicast Router Discovery", draft-		[MRDISC] Biswas, S. "IGMP Multicast Router Discovery", draft-
	ietf-idmr-igmp-mrdisc-06.txt, May 2001.		ietf-idmr-igmp-mrdisc-08.txt, January 2002.
	[MSOFT] Microsoft support article Q223136, "Some LAN Switches		[MSOFT] Microsoft support article Q223136, "Some LAN Switches
	with IGMP Snooping Stop Forwarding Multicast Packets on		with IGMP Snooping Stop Forwarding Multicast Packets on
	RRAS Startup", http://support.microsoft.com/sup-		RRAS Startup", http://support.microsoft.com/sup¡
	port/kb/articles/Q223/1/36.ASP		port/kb/articles/Q223/1/36.ASP
			[PROXY] Fenner, B. et al, "IGMP-based Multicast Forwarding (IGMP
			Proxying)", draft-ietf-magma-proxy-02(?).txt.
	[RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC		[RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC
	1112, August 1989.		1112, August 1989.
	[RFC2026] Bradner, S. "The Internet Standards Process -- Revision		[RFC2026] Bradner, S. "The Internet Standards Process -- Revision
	3", RFC2026, October 1996.		3", RFC2026, October 1996.
	RFC DRAFT January 2001
	[RFC2236] Fenner, W., "Internet Group Management Protocol, Version		[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
	2", RFC2236, November 1997.		2", RFC2236, November 1997.
	[RFC2375] Hinden, R. "IPv6 Multicast Address Assignments",		[RFC2375] Hinden, R. "IPv6 Multicast Address Assignments",
	RFC2375, July 1998.		RFC2375, July 1998.
	8. Acknowledgements		77.. AAcckknnoowwlleeddggeemmeennttss
	We would like to thank (in no identifiable order) Hugh Holbrook, Bill		We would like to thank Martin Bak, Les Bell, Yiqun Cai, Paul Cong¡
	Fenner, Yiqun Cai, Edward Hilquist, Toerless Eckert, Kevin Humphries,		don, Toerless Eckert, Bill Fenner, Brian Haberman, Edward Hilquist,
	Karen Kimball and Martin Bak for comments and suggestions on this		Hugh Holbrook, Kevin Humphries, Karen Kimball and Jaff Thomas for
	document. Furthermore, the following companies are acknowledged for		comments and suggestions on this document.
	their contributions: Vitesse Semiconductor Corporation, Cisco Sys-
	tems, Hewlett-Packard, Enterasys Networks.
	9. Author's Addresses:		Furthermore, the following companies are acknowledged for their
			contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks,
			Hewlett-Packard, Vitesse Semiconductor Corporation. The ordering
			of these names do not necessarily correspond to the column numbers
			in the response table.
	Morten Jagd Christensen		88.. RReevviissiioonn HHiissttoorryy
	jCAPS
	Begoniavej 13
	2820 Gentofte
	DENMARK
	email: morten@jcaps.com
	Frank Solensky		This section, while incomplete, is provided as a convenience to the
			working group members. It will be removed when the document is
			released in its final form.
	email: solenskyf@acm.org		draft-ietf-magma-snoop-01.txt: January 2002
			Extensive restructuring of the original text.
			draft-ietf-magma-snoop-02.txt: June 2002
			Status section removes document history; moved into this sec¡
			tion instead.
			Introduction restores text from the -00 revision that
			describes snooping and its goals
			IGMP flooding rules eased, allowing management option to
			broaden beyond "routers only".
			Removed a SHOULD/MAY inconsistancy between IPv4 Forwarding and
			IPv6 processing of checksums.
			IGMP Forwarding Rules: clarify text describing processing of
			non-zero reserved fields.
			Data Forwarding Rules, item 3 is changed from "MUST forward to
			all ports" to "MAY"; item 4 default changes from "MUST" to
			"SHOULD use network addresses".
			Added two sets of additional responses to the questionnaire
			and text indicating that responses don't cover all products.
			Removed (commented out) description of IPR issues: IESG is
			aware of them.
			The next revision:
			In the interest of getting this version of the draft released
			before the deadline (less than seven hours from the moment
			this paragraph is being typed), we briefly summarize some of
			the comments on the previous version that need to be included
			in the next one. We believe that other comments have been
			addressed in this draft; please let the authors know if this
			they have either not been included or need to be corrected.
			IGMP Forwarding rules:
			Add a reference to and become consistant with the next
			revision of the IGMP proxy draft,
			In item 'b': include a description on how the switch
			determines that a Query came from the router and not
			another switch. Is there some way to make this distinc¡
			tion beyond the source address?
			Proxy reporting: further analysis of the impact on the
			election process when using 0.0.0.0 as the source address
			in membership report messages. Also consider the case
			where the switch assumes the role of Querier when no
			routers are detected and forfeits the role as soon as one
			is announced.
			Include some discussion about how entries are to be aged
			from the list, perhaps similar to spanning tree algorithm
			for unicast MAC address processing.
			Data Forwarding rules:
			Link-local range to mention the problem is due to routing
			protocols not sending Report Messages for their respec¡
			tive multicast addresses.
			Expand discussion of non-IGMP packet forwarding for data
			that matches an IGMPv3 record. Do snooping switches add
			intelligence to recognize SSM versus ASM groups?
			IPv6 Considerations:
			Is having MLD a subset of ICMPv6 an issue? Should MLDv2
			be a separate protocol?
			Add reference to ICMPv6 specification for message pro¡
			cessing rules.
			99.. AAuutthhoorr''ss AAddddrreesssseess
			Morten Jagd Christensen
			email: morten@jagd-christensen.com
			Frank Solensky
			Premonitia, Inc.
			1 Nanog Park
			Acton, MA 01720
			email: fsolensky@premonitia.com
			TTaabbllee ooff CCoonntteennttss
			1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
			2. IGMP Snooping Requirements . . . . . . . . . . . . . . . . . 3
			2.1. Forwarding rules . . . . . . . . . . . . . . . . . . . . . 3
			2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . . . 3
			2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . . . 5
			2.2. IGMP snooping related problems . . . . . . . . . . . . . . 6
			3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 6
			4. Security Considerations . . . . . . . . . . . . . . . . . . 8
			5. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . 8
			6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
			7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
			8. Revision History . . . . . . . . . . . . . . . . . . . . . . 11
			9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 13
End of changes. 103 change blocks.
	350 lines changed or deleted		361 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/