< draft-ietf-magma-snoop-00.txt		draft-ietf-magma-snoop-01.txt >
	MAGMA Working Group M. Christensen		MAGMA Working Group M. Christensen
	Internet Draft Vitesse		Internet Draft jCAPS
	October 2001 F. Solensky		January 2002 F. Solensky
	Expiration Date: April 2001 Gotham Networks		Expiration Date: July 2002
	IGMP and MLD snooping switches		IGMP and MLD snooping switches
	<draft-ietf-magma-snoop-00.txt>		<draft-ietf-magma-snoop-01.txt>
	Status of this Memo		Status of this Memo
	This document is the successor of draft-ietf-idmr-snoop-01 which was		This document is the successor of draft-ietf-magma-snoop-00 which was
	presented at the 51'st IETF in London. Since then IGMP snooping has		presented at the 52'nd IETF in Salt Lake City. The main differences
	been rechartered to belong to the MAGMA working group. The main		between this and the previous version is a restructuring of the draft
	differences between this and previous version are: Responses to IGMP		to introduce the main result as early as possible. Also the draft has
	questionnaire from switch vendors, IPR section, new draft filename.		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		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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		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 months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 41 ¶
	material or to cite them other than as "work in progress."		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 interoperability problems and issues that can		This memo describes the requirements for IGMP and MLD snooping
	arise when a mixed deployment of IGMPv3 and IGMPv2 capable hosts and		switches. The requirements for IGMPv2 snooping switches are based on
	routers are interconnected by a switch with IGMP snooping		best current practices. IGMPv3 and MLDv2 snooping are also covered in
	capabilities. It is intended as an accompanying document to the		this draft although we are not aware of any such implementations at
	IGMPv3 and MLDv2 specifications.		the time of writing.
	The memo contains a brief IGMP walk through followed by a description
	of the IGMP snooping functionality. Specific examples are given
	which are all based on Ethernet as the link layer protocol. MLDv2 for
	RFC DRAFT October 2001
	IPv6 is discussed. Finally recommendations are given for the		RFC DRAFT January 2001
	behavior of IGMP snooping switches. The memo is aiming for BCP or
	Informational status.
	The purpose of this document is twofold:		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.
	- We want to summarize IGMP snooping induced problems and best cur-		Areas which are of relevance to IGMP and MLD snooping switches, such
	rent solutions. We hope that a description of IGMP snooping will		as link layer topology changes and Ethernet specific encapsulation
	be of aid to the IETF when standardizing new protocols and behav-		issues are also considered.
	iors within this scope.
	- We also hope to bring this work to the attention of switch ven-		It is intended as an accompanying document to the IGMPv3 and MLDv2
	dors, typically active within the IEEE community but perhaps not		specifications.
	within IETF, in order to minimize protocol interoperability
	problems in the future.
	1. Introduction		1. Introduction
	In recent years, a number of commercial vendors have introduced prod-		In recent years, a number of commercial vendors have introduced prod-
	ucts described as "IGMP snooping switches" to the market. These		ucts described as "IGMP snooping switches" to the market. These
	devices do not adhere to the conceptual model that provides the		devices do not adhere to the conceptual model that provides the
	strict separation of functionality between different communications		strict separation of functionality between different communications
	layers in the ISO model and instead utilizes information in the upper		layers in the ISO model and instead utilizes information in the upper
	level protocol headers as factors to be considered in the processing		level protocol headers as factors to be considered in the processing
	at the lower levels. This is analogous to the manner in which a		at the lower levels.
	router can act as a firewall by looking into the transport protocol's
	header before allowing a packet to be forwarded to its destination		This is analogous to the manner in which a router can act as a fire-
	address.		wall by looking into the transport protocol's header before allowing
			a packet to be forwarded to its destination address.
	In the case of multicast traffic, an IGMP snooping switch provides		In the case of multicast traffic, an IGMP snooping switch provides
	the benefit of conserving bandwidth on those segments of the network		the benefit of conserving bandwidth on those segments of the network
	where no node has expressed interest in receiving packets addressed		where no node has expressed interest in receiving packets addressed
	to the group address.		to the group address. This is in contrast to normal switch behaviour
			where multicast traffic is typically forwarded on all interfaces.
	The discussions in this document are based on IGMP which applies to
	IPv4 only. For IPv6 we must use MLD instead. Because MLD is based on
	IGMP with only a few differences these discussions also apply to
	IPv6.
	2. IGMP snooping overview
	For a full description of IGMP we refer to [IGMPv3], however, IGMP
	operation is summarized in the following:
	RFC DRAFT October 2001
	* Hosts send IGMP Membership Report messages to inform neighboring
	routers that they wish to join a specific IP multicast group.
	* IGMPv3 Membership Reports may be qualified with a list of allowed
	or forbidden source addresses.
	* Routers periodically send IGMP Query messages to hosts in order
	to maintain group membership state information. These queries
	can be either general or group specific queries.
	* Hosts respond to queries with Membership Reports.
	* Hosts running either IGMPv2 or IGMPv3 may also send a Leave Group
	message to routers to withdraw from the group.
	A traditional Ethernet network may be separated into different net-
	work segments to prevent placing too many devices onto the same
	shared media. These segments are connected by bridges and switches.
	When a packet with a broadcast or multicast destination address is
	received, the switch will forward a copy into each of the remaining
	network segments in accordance with the IEEE MAC bridge standard
	[BRIDGE]. Eventually, the packet is made accessible to all nodes
	connected to the network.
	This approach works well for broadcast packets that are intended to
	be seen or processed by all connected nodes. In the case of multi-
	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 pack-
	ets 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. The problem of wasting band-
	width 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, and it will be standard for 10Gbps eth-
	ernet too. In this case the wasted bandwidth is proportional to the
	number of attached nodes.
	Allowing switches to snoop IGMP packets is a creative effort to solve
	this problem. The switch uses the information in the IGMP packets as
	they are being forwarded throughout the network to determine which
	segments should receive packets directed to the group address.
	IGMP snooping is being implemented slightly different by different
	switch vendors. We will not address specific implementations here as
	documentation is not widely available. For details of one
	RFC DRAFT October 2001
	implementation we refer to [CISCO].
	In the following we will describe problems in relation to IGMP snoop-
	ing with the following constraints, which we believe are the most
	common cases.
	1. Group membership is based on multicast MAC addresses only.
	2. Forwarding is based on a 'list' of member ports for each sup-
	ported multicast group.
	3. The switch is equipped with a CPU for maintaining group member-
	ship information.
	Constraint 3 above is not a strict requirement as IGMP snooping could
	be accomplished entirely in hardware. However, when sending IGMP
	datagrams all is done to ensure that the packets are not routed. For
	example the TTL is set to 1 and the IP header contains the router
	alert option. This is a hint to developers that there is probably a
	need to send this packet to the CPU.
	IGMP snooping switches build forwarding lists by listening for (and
	in some cases intercepting) IGMP messages. Although the software
	processing the IGMP messages may maintain state information based on
	the full IP group addresses, the forwarding tables are typically
	mapped to link layer addresses. An example of such a forwarding
	table is shown in Figure 1.
	Multicast MAC address | Member ports
	-------------------------------------
	01-00-5e-00-00-01 | 2, 7
	01-00-5e-01-02-03 | 1, 2, 3, 7
	01-00-5e-23-e2-05 | 1, 4
	-------------------------------------
	Figure 1.
	Because only the least significant 23 bits of the IP address are
	mapped to Ethernet addresses [RFC1112], there is a loss of informa-
	tion when forwarding solely on the destination MAC (DMAC) address.
	This means that for example 224.0.0.123 and 239.128.0.123 and similar
	IP multicast addresses all map to MAC address 01-00-5e-00-00-7b (for
	Ethernet). As a consequence, IGMP snooping switches may collapse IP
	multicast group memberships into a single Ethernet multicast member-
	ship group.
	Finally, it should be mentioned that in addition to building and
	maintaining lists of multicast group memberships the snooping switch
	should also maintain a list of multicast routers. When forwarding
	RFC DRAFT October 2001
	multicast packets they should be forwarded on ports which have joined
	using IGMP but also on ports on which multicast routers are attached.
	The reason for this is that in IGMP there is only one active querier.
	This means that all other routers on the network are suppressed and
	thus not detectable by the switch.
	2.1. Problems in older networks
	The drawback of using IGMP snooping switches to make the flooding of
	multicast traffic more efficient is that the underlying link layer
	topology is required to remain very stable. This is especially true
	in IGMP versions 1 and 2 where group members do not transmit Member-
	ship Report messages after having overheard a report from another
	group member.
	This problem can be demonstrated with an example. In the topology
	illustrated in figure 2, a topology loop exists between four IGMP
	snooping switches labeled A, B, C and D.
	- The spanning tree algorithm would detect this loop and disable
	one of the links; for example, the link connecting ports B3 and
	C1.
	- Host H1 transmits a group Membership Report which will be flooded
	throughout the network.
	- When switch A hears the report, it determines that packets
	addressed to the group should be forwarded to port A3.
	- Router R hears the Join message and starts forwarding packets
	with the multicast destination address into the network. Host H1
	is now part of the group.
	- The link between D2 and C2 is broken. The spanning tree algo-
	rithm reactivates the blocked link B3-C1.
	- If switch A relies solely on the exchange of IGMP messages to
	alter its forwarding behavior, host H1 will be unable to receive
	packets forwarded to the group address until router R sends out
	another Membership Query.
	One possible approach to work around this limitation would be for the
	switch to keep track of which nodes belong to the group, altering the
	forwarding tables whenever a member becomes visible through a different
	port. When switch A sees that host H1 has moved from port A3 to A2, the
	RFC DRAFT October 2001
	+------+ B2
	B1 |Snoop |----- - - - +------+
	-----|Switch| | Host |
	/ | B |----- / | H1 |
	+--------+ A2 / +------+ B3 X C1 +------+ +--+---+
	A1 | Snoop |----- / -----|Snoop | |
	--+----| Switch | |Switch|-----+----
	| | A |----- -----| C | C3
	+-+-+ +--------+ A3 \ +------+ D2 / C2 +------+
	| R | \ D1 |Snoop |-----
	++-++ -----|Switch|
	| | | D |---------+------ - - -
	+------+ D3 |
	+--+---+
	| Host |
	| H2 |
	+------+
	Figure 2
	group membership table would be updated. This does not work, however,
	when more than one node joins the same group address when at least one
	of them has not yet been upgraded to IGMPv3: if hosts H1 and H2 were to
	join the group at approximately the same time, they would both start off
	random timers for the transmission of their first Membership Reports.
	If host H2 selects a longer interval than H1, it will hear H1's report
	message and cancel the one it was about to send. Switch A, therefore,
	never learns that node H2 has joined the group. When the switch learns
	that H1 is now accessible through port A2, it has no way of knowing that
	it should continue forwarding group packets to port A3 as well.
	Two recommendations can be made based on the above discussion:
	- The switch should play an active role when detecting a topology
	change; The spanning tree root bridge (which is also a snooping
	switch) should initiate the transmission of a IGMP General Query,
	for example through signalling the CPU. This will help to reduce
	the join latency otherwise introduced.
	- IGMP Membership Reports should not be flooded because this will
	lead to Join suppression.
	2.2. IGMPv2 snooping and 224.0.0.X
	Special attention should be brought to the IP address range from
	224.0.0.1 through 224.0.0.255 which is reserved for routing protocols
	and other low-level topology discovery or maintenance protocols
	[IANA]. Examples of reserved multicast addresses are:
	RFC DRAFT October 2001
	224.0.0.2 All Routers on this Subnet
	224.0.0.4 DVMRP
	224.0.0.5 (M)OSPF routers
	224.0.0.6 (M)OSPF DRs
	224.0.0.9 RIP2 Routers
	224.0.0.13 PIM Routers
	224.0.0.22 IGMPv3 Membership Reports
	Multicast routers are discouraged from routing packets when a desti-
	nation address falls within this range, regardless of the TTL value.
	The router will be the originator or consumer of these messages so it
	has less of a motivation to maintain forwarding path information for
	these addresses. As a result, it becomes less critical for the
	router to send out periodic Query messages for these groups. If the
	router chooses not to, the group would be unable to recover from
	topology changes as described above. Note that the only difference
	between the 'all hosts' address (224.0.0.1) and the remainder of this
	range is that the router has no discretion in the former case: it
	MUST NOT send Queries.
	To avoid this situation, IGMP snooping switches should be less con-
	servative when forwarding packets to these addresses and flood them
	to all ports.
	As an example of this, it is reported in [MSOFT] that a number of
	switches can be misconfigured to perform IGMP snooping and forwarding
	for all IP multicast groups:
	Figure 3 illustrates the scenario where two routers R1 and R2 are
	communicating using for example 224.0.0.6. The routers never send
	IGMP Joins for this address. The switch floods the (unknown) multi-
	cast traffic on all ports.
	Now the server SVR is started and it sends an IGMP Join for
	224.0.0.6, which is snooped by the switch. The switch then generates
	a Membership Query on all ports to determine which ports have devices
	attached that also belong to this group.
	The routers R1 and R2 do not respond and the switch builds a forward-
	ing port list with only SVR in it. Now R1 and R2 are not able to
	communicate using this address.
	There are two possible fixes to this problem: One is to require that
	all routers (also being hosts) which use IP multicast respond to IGMP
	queries in the range 224.0.0.X. This seems unnecessary as discussed
	above because of the inherent link local scope of these messages.
	RFC DRAFT October 2001
	+----+ +----------+
	--| R1 |-----| |
	+----+ | Snooping | +-----+
	| |----| SVR |
	+----+ | switch | +-----+
	--| R2 |-----| |
	+----+ +----------+
	Figure 3.
	Another solution to this problem, which is also discussed above, is
	that the switch is configured to forward all packets for a range of
	IP multicast addresses to all ports (flooding).
	It is suggested that all multicast packets in the range 224.0.0.1
	through 224.0.0.255 are forwarded on all ports. This of course
	requires an examination of the network layer header. Note that these
	are IP adress ranges and that mapping these to MAC address range
	01-00-5e-00-00-X is subject to problems discussed in the previous
	sections.
	2.3. IGMPv3 and IGMPv2 coexistence
	IGMPv3 and IGMPv2 are designed to interoperate with older versions of
	IGMP. Both hosts and routers are capable of falling back to an ear-
	lier version when receiving older IGMP messages, thus enabling a
	mixed deployment and migration to new versions. While this works fine
	in a network of hosts and routers an IGMP snooping switch introduces
	problems.
	In figure 4 where hosts H1 and H2 are connected to an IGMP snooping
	switch on ports P1 and P2 respectively, consider the following
	sequence of communication:
	- Router R sends an IGMPv3 Query
	- Host H1 sends an IGMPv2 Report since it has only implemented v2.
	R notices this and switches to IGMPv2 mode. The report is not
	received by H2 because of the snooping functionality.
	- Switch S puts H1's port P1 in the forwarding table.		Many switch datasheets state support for IGMP snooping, but no
			requirements for this exist today. It is the authors hope that the
			information presented in this draft will supply this information.
	- Host H2 sends an IGMPv3 Report in response to R's Query.		The requirements presented here is based on the following information
			sources: The IGMP specifications [RFC112][RFC2236][IGMPv3], vendor
			supplied technical documents [CISCO], bug reports [MSOFT], discus-
			sions with people invovled in design of IGMP snooping switches, MAGMA
			mailinglist discussions, and on replies by switch vendors to an
			implementation questionnaire.
	- Switch S fails to add H2's port P2 to the forwarding table		The discussions in this document are based on IGMP which applies to
	because it doesn't support IGMPv3.		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
	RFC DRAFT October 2001		RFC DRAFT January 2001
	- H2 does not receive any traffic before R sends its next Query		snooping switches. Instead we point out the few cases where there is
	which will put H2 in IGMPv2 mode.		a difference compared to IGMP.
	This introduces a Join latency for host H2, which apparently cannot be		2. IGMP Snooping Requirements
	avoided. The latency is potentially of the order of minutes. It is pos-
	sible however to reduce this latency by tuning the Query Interval which
	defaults to 125 seconds.
	When operating in a mixed deployment mode it is suggested that initially		The following sections list the requirements for an IGMP snooping
	the Query Interval is set to "a low value" until the compatibility modes		switch. The requirement is stated and is supplemented by a discus-
	have stabilized both host and routers on the same IGMP version. After		sion. All implementation discussions are examples only and there may
	stabilization the Query Interval could be increased to its original		well be other ways to achieve the same functionality.
	value.
	2.4. Source Specific Joins		2.1. Forwarding rules
	Even for IGMPv3 snooping capable switches there can be limitations		The IGMP snooping functionality is here separated in a control section
	caused by link layer based forwarding. This is illustrated in figure		(IGMP forwarding) and data section (Data forwarding).
	4.
	Assume that host H1 sends a Join(S1, G) to R and that host H2 sends a		2.1.1. IGMP Forwarding Rules
	Join(S2, G) to R.
	The switch adds both hosts to the forwarding list for group G.		1) A snooping switch MUST only forward IGMP Membership Reports on ports
			where multicast routers are attached. Alternatively stated: A snooping
			switch MUST NOT forward IGMP Membership Reports to ports on which only
			hosts are attached.
	Frames originating from sources S1 and S2 for the same multicast		This is the main IGMP snooping functionality. Sending membership reports
	address G are routed via R. These are sent from R with the router's		to other hosts can result (For IGMPv2 and IGMPv1) in the unwanted pre-
	MAC address as source.		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 is unable to distinguish the two different types of flow		The switch supporting IGMP snooping MUST maintain a list of multicast
	and forwards both flows to both hosts. This effectively disables the		routers and the ports on which they are attached. This list SHOULD be
	Join source functionality in this network configuration.		built using IGMP Multicast Router Discovery [MRDISC]. IGMP snooping
			switches MAY alternatively build this list based on
	+----+ P1+----------+		a) The arrival port for IGMP Queries (sent by multicast routers) or
	| H1 |-----| |
	+----+ | Snooping | +---+ (S1, G)
	| |----| R |--- and
	+----+ | switch | +---+ (S2, G)
	| H2 |-----| |
	+----+ P2+----------+
	Figure 4.		b) List of ports configured (by management) as having multicast routers
			attached.
	This is a problem caused by layer 2 based forwarding of a layer 3		Implementation example: IGMP snooping can be achieved by redirecting all
	flow in conjunction with the difference between the link layer and		IGMP packets (IP packets with IP-PROTO = 2) to the CPU (or similar
			higher layer entity) for IGMP message processing and table management.
	RFC DRAFT October 2001		2) IGMP snooping switches MAY implement "proxy-reporting" in which
			RFC DRAFT January 2001
	the network layer information.		reports received from downstream hosts are summarized and used to build
			internal membership states. An IGMP proxy-reporting switch would then
			report it's own state in response to upstream queriers. If the switch
			does not have an IP address it SHOULD use the address 0.0.0.0 as source
			in these reports.
	The example above means that host implementations cannot rely on the		An IGMP proxy-reporting switch may act as Querier for the downstream
	router to perform all source address filtering. Therefore they must		hosts while proxy reporting to the 'real' upstream queriers.
	still filter out packets that do not match the source address crite-
	rion specified in the Join messages. While this might be seen as an
	inconvience, this is no different than the case where the router is
	directly connected to both hosts on a shared LAN and no snooping
	switch is present.
	A complete solution would be for the switch to further qualify the		It should be noted that there may be multiple IGMP proxy-reporting
	search process by including the source IP address when determining		switches in the network all using the 0.0.0.0 source IP address. In this
	which ports should forward the packet.		case the switches can be identified by their, link layer source MAC
			address.
	Similar problems occur with the attempt to exclude sources.		IGMP membership reports should not be rejected because of a source IP
			address of 0.0.0.0.
	3. Snooping Requirements		3) The switch that supports IGMP snooping MUST forward all unrecognized
			IGMP messages 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 are non-zero MUST NOT be subject to "normal" snooping
			since this could indicate an incompatible change to the message format.
	Note that in the following we provide suggestions for good/best prac-		4) An IGMP snooping switch SHOULD be aware of link layer topology
	tices when designing IGMP snooping devices. Keywords as MUST, SHOULD,		changes. Following a topology change the switch SHOULD initiate the
	MUST NOT etc. are suggestions only.		transmission of a General Query on all ports in order to reduce network
			convergence time.
	1) All IGMP packets (IP packets with IP-PROTO = 2) SHOULD be redi-		5) An IGMP snooping switch MUST discard from the IGMP snooping process
	rected to the CPU for IGMP snooping processing and table management.		IGMP packets where IP or IGMP headers have checksum errors.
	This allows for the most flexible IGMP snooping solution.
	2) The switch that provides support for IGMP snooping MUST forward		2.1.2. Data Forwarding Rules
	all unrecognized IGMP messages and MUST NOT attempt to make use of
	any information beyond the end of the network layer header. In par-
	ticular, messages where any reserved fields are non-zero MUST NOT be
	subject to "normal" snooping since this could indicate an incompati-
	ble change to the message format.
	3) Packets with a destination IP (DIP) address in the 224.0.0.X range		6) Packets with a destination IP (DIP) address in the 224.0.0.X range
	which are *not* IGMP SHOULD be forwarded on all ports.		which are *not* IGMP MUST be forwarded on all ports.
	4) Packets with a destination IP address outside 224.0.0.X which are		This requirement is based on fact that many hosts exist today, which
	*not* IGMP SHOULD be forwarded according to port membership tables		does not Join IP multicast addresses in this range before sending or
	and MUST also be forwarded on router ports.		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.
	5) If a switch receives a *non* IGMP multicast packet without having		7) Packets with a destination IP address outside 224.0.0.X which are
	first processed Membership Reports for the group address, it MUST		*not* IGMP SHOULD be forwarded according to group based port membership
	forward the packet on all ports. In other words, the switch must		RFC DRAFT January 2001
	allow for the possibility that connected hosts and routers have been
	upgraded to support future versions or extensions of IGMP that the
	RFC DRAFT October 2001		tables and MUST also be forwarded on router ports.
	switch does not yet recognize. A switch MAY have a configuration		This is the core IGMP snooping requirement for the data path.
	option that suppresses this operation, but default behavior MUST be
	to allow flooding of unregistered packets.
	6) A snooping switch SHOULD forward IGMP Membership Reports on router		Discussion: An implementation could maintain separate membership and
	"ports" only.		multicast router tables in software and then "merge" these tables into a
			current forwarding cache.
	7) The switch supporting IGMP snooping MUST maintain a list of multi-		8) If a switch receives a *non* IGMP multicast packet without having
	cast routers. This list SHOULD be built using IGMP Multicast Router		first processed Membership Reports for the group address, it MUST for-
	Discovery [MRDISC] which is currently going through IETF Last Call.		ward the packet on all ports. In other words, the switch must allow for
	IGMP snooping switches MAY build this list based on the arrival port		the possibility that connected hosts and routers have been upgraded to
	for packets destined to 224.0.0.X, when		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.
	- The packets are IGMP Queries or		9) IGMP snooping switches MAY maintain forwarding tables based on either
			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.
	- The packets are *not* IGMP or		Discussion: Forwarding based on MAC addresses is subject to the problem
			associated with the 32-fold IP address to 1 MAC address mapping.
	- The ports are configured (by management) as having multicast		10) Switches which rely on information in the IP header SHOULD verify
	routers attached		that the IP header checksum is correct. If the checksum fails the packet
			SHOULD be silently discarded.
	8) IGMP snooping switches MAY maintain forwarding tables based on either		2.2. IGMP snooping related problems
	MAC addresses or IP addresses. If a switch supports both types of for-
	warding tables then the default behavior SHOULD be to use IP addresses.
	9) Switches which rely on information in the IP header MAY verify that		A special problem arise in the network consisting of IGMPv3 routers as
	the IP header checksum is correct. If the checksum fails the packet		well as IGMPv2 and IGMPv3 hosts interconnected by a IGMPv2 snooping
	SHOULD be silently discarded.		switch. IGMPv3 has a mechanism to fall back to IGMPv2 when receiving
			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.
	10) IGMP snooping switches SHOULD inform the CPU (or hardware) when a		Therefore it is recommended that in such a network, the multicast router
	link layer topology change has been detected. Following a topology		is configured to use IGMPv2.
	change the switch SHOULD initiate the transmission of a General Query on
	all ports in order to reduce Join latency.
	4. IPv6 Considerations		3. IPv6 Considerations
	In order to avoid confusion, the previous discussions have been based		In order to avoid confusion, the previous discussions have been based
	on IGMPv3 functionality which only applies to IPv4 multicast. In the		on IGMPv3 functionality which only applies to IPv4 multicast. In the
	case of IPv6 most of the above discussions are still valid with a few		case of IPv6 most of the above discussions are still valid with a few
			RFC DRAFT January 2001
	exceptions which we will describe here.		exceptions which we will describe here.
	In IPv6 the protocol for multicast group maintenance is called Multi-		In IPv6 the protocol for multicast group maintenance is called Multi-
	cast Listener Discovery (MLDv2). IPv6 is not widely deployed today		cast Listener Discovery (MLDv2). IPv6 is not widely deployed today
	and neither is IPv6 multicast. However, it is anticipated that at		and neither is IPv6 multicast. However, it is anticipated that at
	some time IPv6 switches capable of MLD snooping will appear.		some time IPv6 switches capable of MLD snooping will appear.
	The three main differences between IGMPv3 and MLDv2 are		The three main differences between IGMPv3 and MLDv2 are
	RFC DRAFT October 2001
	- MLDv2 uses ICMPv6 message types instead of IGMP message types.		- MLDv2 uses ICMPv6 message types instead of IGMP message types.
	- The ethernet encapsulation is a mapping of 32bits of the 128bit		- The ethernet encapsulation is a mapping of 32bits of the 128bit
	DIP addresses into 48bit DMAC addresses [IPENCAPS].		DIP addresses into 48bit DMAC addresses [IPENCAPS].
	- Multicast router discovery is done using Neighbor Discovery Pro-		- Multicast router discovery is done using Neighbor Discovery Pro-
	tocol (NDP) for IPv6. NDP uses ICMPv6 message types.		tocol (NDP) for IPv6. NDP uses ICMPv6 message types.
	A minor difference which applies to the requirements section is that in		A minor difference which applies to the requirements section is that in
	IPv6 there is no checksum in the IP header. This is the reason that the		IPv6 there is no checksum in the IP header. This is the reason that the
	skipping to change at page 12, line 33 ¶		skipping to change at page 6, line 42 ¶
	was the case the CPU queue assigned for MLD would potentially be filled		was the case the CPU queue assigned for MLD would potentially be filled
	with non-MLD related packets. Furthermore ICMPv6 packets destined for		with non-MLD related packets. Furthermore ICMPv6 packets destined for
	other hosts would not reach their destination. A solution is either to		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		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		able to detect a multicast DMAC address in conjunction with ICMPv6. The
	first solution is desirable only if it is configurable which message		first solution is desirable only if it is configurable which message
	types should trigger a CPU redirect and which should not. The reason is		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		that a hardcoding of message types is unflexible for the introduction of
	new message types. The second solution introduces the risk of new pro-		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		tocols, which are not related to MLD but uses ICMPv6 and multicast DMAC
	addresses wrongly being identified as MLD. We do not suggest a recom-		addresses wrongly being identified as MLD. It is suggested that solution
	mended solution in this case.		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 mapping from IP multicast addresses to multicast DMAC addresses
	introduces a potentially enormous overlap. The structure of an IPv6 mul-		introduces a potentially enormous overlap. The structure of an IPv6 mul-
	ticast address is shown in figure 5. Theoretically 2**80, two to the		ticast 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		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.		DMAC address. This should be compared to 2**5 in the case of IPv4.
	Initial allocation of IPv6 multicast addresses, however, uses only the		Initial allocation of IPv6 multicast addresses, however, uses only the
			RFC DRAFT January 2001
	lower 32 bits of group ID. This eliminates the address ambiguity for the		lower 32 bits of group ID. This eliminates the address ambiguity for the
	time being but it should be noted that the allocation policy may change		time being but it should be noted that the allocation policy may change
	in the future.		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
	RFC DRAFT October 2001
	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		Finally, we mention the reserved address range FF0X:0:0:0:0:0:X:X where
	is any value. This range is similar to 224.0.0.X for IPv4 and is		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		reserved to routing protocols and resource discovery [RFC2375]. In the
	case of IPv6 it is suggested that packets in this range are forwarded on		case of IPv6 it is suggested that packets in this range are forwarded on
	all ports if they are not MLD packets.		all ports if they are not MLD packets.
	5. Security Considerations		4. Security Considerations
	Security considerations for IGMPv3 are accounted for in [IGMPv3].		Security considerations for IGMPv3 are accounted for in [IGMPv3].
	The introduction of IGMP snooping switches adds the following consid-		The introduction of IGMP snooping switches adds the following consid-
	erations with regard to IP multicast.		erations with regard to IP multicast.
	The exclude source failure which could cause traffic from sources		The exclude source failure which could cause traffic from sources
	that are 'black listed' to reach hosts that have requested otherwise.		that are 'black listed' to reach hosts that have requested otherwise.
	This can also occur in certain network topologies without IGMP snoop-		This can also occur in certain network topologies without IGMP snoop-
	ing.		ing.
	skipping to change at page 13, line 42 ¶		skipping to change at page 8, line 5 ¶
	their operation and which do not validate the header checksum poten-		their operation and which do not validate the header checksum poten-
	tially will forward packets on the wrong ports. Even though the IP		tially will forward packets on the wrong ports. Even though the IP
	headers are protected by the ethernet checksum this is a potential		headers are protected by the ethernet checksum this is a potential
	vulnerability.		vulnerability.
	Generally though, it is worth to stress that IP multicast must so far		Generally though, it is worth to stress that IP multicast must so far
	be considered insecure until the work of for example the suggested		be considered insecure until the work of for example the suggested
	Multicast Security (MSEC) working group or similar is completed or at		Multicast Security (MSEC) working group or similar is completed or at
	least has matured.		least has matured.
	6. IGMP Questionnaire		RFC DRAFT January 2001
			5. IGMP Questionnaire
	As part of this work the following questions were asked both on the		As part of this work the following questions were asked both on the
	MAGMA discussion list and sent to known switch vendors implementing IGMP		MAGMA discussion list and sent to known switch vendors implementing IGMP
	snooping. The individual contributions have been anonymized upon		snooping. The individual contributions have been anonymized upon
	request.		request.
	The questions were:		The questions were:
	RFC DRAFT October 2001
	Q1 Does your switches perform IGMP Join aggregation? In other words,		Q1 Does your switches perform IGMP Join aggregation? In other words,
	are IGMP joins intercepted, absorbed by the hardware/software so that		are IGMP joins intercepted, absorbed by the hardware/software so that
	only one Join is forwarded to the querier?		only one Join is forwarded to the querier?
	Q2 Is multicast forwarding based on MAC addresses? Would datagrams		Q2 Is multicast forwarding based on MAC addresses? Would datagrams
	addressed to multicast IP addresses 224.1.2.3 and 239.129.2.3 be for-		addressed to multicast IP addresses 224.1.2.3 and 239.129.2.3 be for-
	warded on the same ports-groups?		warded on the same ports-groups?
	Q3 Is it possible to forward multicast datagrams based on IP addresses		Q3 Is it possible to forward multicast datagrams based on IP addresses
	(not routed). In other words, could 224.1.2.3 and 239.129.2.3 be for-		(not routed). In other words, could 224.1.2.3 and 239.129.2.3 be for-
	skipping to change at page 15, line 5 ¶		skipping to change at page 9, line 5 ¶
	Q8 Is your IGMP snooping functionality partly software implemented?		Q8 Is your IGMP snooping functionality partly software 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 for		changes) be detected by the IGMP snooping functionality so that for
	example new queries can be sent or tables can be updated to ensure		example new queries can be sent or tables can be updated to ensure
	robustness?		robustness?
	The answers were:		The answers were:
	RFC DRAFT October 2001		RFC DRAFT January 2001
	---------------------------------------------		---------------------------------------------
	Switch Vendor		Switch Vendor
	-------------------------+---+---+---+---+---		-------------------------+---+---+---+---+---
	| 1 | 2 | 3 | 4 |		| 1 | 2 | 3 | 4 |
	-------------------------+---+---+---+---+---		-------------------------+---+---+---+---+---
	Q1 Join aggregation | x | x | x |		Q1 Join aggregation | x | x | x | |
	Q2 Layer-2 forwarding | x | x | x |		Q2 Layer-2 forwarding | x | x | x | x |
	Q3 Layer-3 forwarding |(1)| |(1)|		Q3 Layer-3 forwarding |(1)| |(1)| |
	Q4 224.0.0.X aware |(1)| x |(1)|		Q4 224.0.0.X aware |(1)| x |(1)|(2)|
	Q5 1:00:5e:0:0:X aware | x | x | x |		Q5 1:00:5e:0:0:X aware | x | x | x |(2)|
	Q6 Mcast router list | x | x | x |		Q6 Mcast router list | x | x | x | x |
	Q7 Hardware implemented | | | |		Q7 Hardware implemented | | | | |
	Q8 Software assisted | x | x | x |		Q8 Software assisted | x | x | x | x |
	Q9 Topology change aware | x | x | x |		Q9 Topology change aware | x | x | x | x |
	-------------------------+---+---+---+---+---		-------------------------+---+---+---+---+---
	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.
	7. IPR Issues		6. IPR Issues
	It appears that a number of patents have been filed which may apply to		It appears that a number of patents have been filed which may apply to
	this draft or parts thereof. None of these patents have been filed by		this draft or parts thereof. None of these patents, listed below, have
	the authors of this draft or companies in which they are or have been		been filed by the authors of this draft or companies in which they are
	employed.		or have been employed.
	We, the authors, have not tried to evaluate whether these patents are		We, the authors, have not tried to evaluate whether these patents are
	violated by implementing IGMP snooping according to this document. The		violated by implementing IGMP snooping according to this document. The
	IETF/IESG have been notified about the patents.		IETF/IESG have been notified about the patents.
	International patent: WO 96/34474, Oct. 31 1996, Title: "Broadcast		International patent: WO 96/34474, Oct. 31 1996, Title: "Broadcast
	transmission in a data network"		transmission in a data network"
	US patent: Number 5,608,726, Mar. 4, 1997 (filed 1995) Title: "Network-		US patent: Number 5,608,726, Mar. 4, 1997 (filed 1995) Title: "Network-
	ing Bridge with Multicast forwarding table"		ing Bridge with Multicast forwarding table"
	US patent: Number 5,898,686, Apr. 27, 1999 (filed 1996) Title: "Network-		US patent: Number 5,898,686, Apr. 27, 1999 (filed 1996) Title: "Network-
	ing Bridge with Multicast forwarding table"		ing Bridge with Multicast forwarding table"
	Australian patent: Application No. 65440/98 Title: "System, Device, and		Australian patent: Application No. 65440/98 Title: "System, Device, and
	Method for Managing Multicast Group Memberships in a Multicast Network"		Method for Managing Multicast Group Memberships in a Multicast Network"
	RFC DRAFT October 2001		RFC DRAFT January 2001
	8. References		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
	skipping to change at page 17, line 5 ¶		skipping to change at page 11, line 5 ¶
	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
	[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 October 2001		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.
	9. Acknowledgements		8. Acknowledgements
	We would like to thank Bill Fenner, Yiqun Cai, Edward Hilquist and		We would like to thank (in no identifiable order) Hugh Holbrook, Bill
	Martin Bak for comments and suggestions on this document. Further-		Fenner, Yiqun Cai, Edward Hilquist, Toerless Eckert, Kevin Humphries,
	more, the following companies are acknowledged for their contribu-		Karen Kimball and Martin Bak for comments and suggestions on this
	tions: List-of-Companies will not be displayed until a sufficient		document. Furthermore, the following companies are acknowledged for
	number of replies have been received in order to keep promise about		their contributions: Vitesse Semiconductor Corporation, Cisco Sys-
	anomymization.		tems, Hewlett-Packard, Enterasys Networks.
	10. Author's Addresses:		9. Author's Addresses:
	Morten Jagd Christensen		Morten Jagd Christensen
	Vitesse Semiconductor Corporation		jCAPS
	Hoerkaer 16		Begoniavej 13
	2730 Herlev		2820 Gentofte
	DENMARK		DENMARK
	email: mjc@vitesse.com		email: morten@jcaps.com
	Frank Solensky		Frank Solensky
	Gotham Networks
	15 Discovery Way
	Acton, MA 01720
	USA
	email: fsolensky@GothamNetworks.com
	solensky@acm.org
	RFC DRAFT October 2001
	Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2		email: solenskyf@acm.org
	2. IGMP snooping overview . . . . . . . . . . . . . . . . . . . . 2
	2.1 Problems in older networks . . . . . . . . . . . . . . . . . . 5
	2.2 IGMPv2 snooping and 224.0.0.X . . . . . . . . . . . . . . . . . 6
	2.3 IGMPv3 and IGMPv2 coexistence . . . . . . . . . . . . . . . . . 8
	2.4 Source Specific Joins . . . . . . . . . . . . . . . . . . . . . 9
	3. Snooping Requirements . . . . . . . . . . . . . . . . . . . . . 10
	4. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 13
	6. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . . 13
	7. IPR Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
	10. Author's Addresses: . . . . . . . . . . . . . . . . . . . . . . 17
End of changes. 73 change blocks.
	487 lines changed or deleted		189 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/