< draft-ietf-magma-igmp-proxy-05.txt		draft-ietf-magma-igmp-proxy-06.txt >
	MAGMA Working Group Bill Fenner, AT&T Research		MAGMA Working Group Bill Fenner, AT&T Research
	INTERNET-DRAFT Haixiang He, Nortel Networks		INTERNET-DRAFT Haixiang He, Nortel Networks
	draft-ietf-magma-igmp-proxy-05.txt Brian Haberman, Caspian Networks		draft-ietf-magma-igmp-proxy-06.txt Brian Haberman, Caspian Networks
	Hal Sandick, Sheperd Middle School		Hal Sandick, Sheperd Middle School
	Expire: July, 2004 January, 2004		Expire: October, 2004 April, 2004
	IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying")		IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying")
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC 2026.		all provisions of Section 10 of RFC 2026.
	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
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	edge box fails over to the second connection. IGMP/MLD-based		edge box fails over to the second connection. IGMP/MLD-based
	forwarding can benefit from such mechanism and use the spare		forwarding can benefit from such mechanism and use the spare
	connection for its redundant or backup connection to multicast		connection for its redundant or backup connection to multicast
	routers. When an edge box fails over to the second connection, the		routers. When an edge box fails over to the second connection, the
	proxy upstream connection can also be updated to the new connection.		proxy upstream connection can also be updated to the new connection.
	1.2. Applicability Statement		1.2. Applicability Statement
	The IGMP/MLD-based forwarding only works in a simple tree topology.		The IGMP/MLD-based forwarding only works in a simple tree topology.
	The tree must be manually configured by designating upstream and		The tree must be manually configured by designating upstream and
	downstream interfaces on each proxy device. There are no multicast		downstream interfaces on each proxy device. In addition, the IP
	routers within the tree and the root of the tree is expected to be		addressing scheme applied to the proxying tree topology SHOULD be
	connected to a wider multicast infrastructure. This protocol is		configured to ensure a proxy device can win the IGMP/MLD Querier
	limited to a single administrative domain.		election to be able to forward multicast traffic. There are no other
			multicast routers except the proxy devices within the tree and the
			root of the tree is expected to be connected to a wider multicast
			infrastructure. This protocol is limited to a single administrative
			domain.
	In more complicated scenarios where the topology is not a tree, a		In more complicated scenarios where the topology is not a tree, a
	more robust failover mechanism is desired, or more than one		more robust failover mechanism is desired, or more than one
	administrative domains are involved, a multicast routing protocol		administrative domains are involved, a multicast routing protocol
	should be used.		should be used.
	1.3. Conventions		1.3. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	skipping to change at page 7, line 36 ¶		skipping to change at page 7, line 41 ¶
	(multicast-address, filter-mode, source-list)		(multicast-address, filter-mode, source-list)
	Each record is the result of the merge of all subscriptions for that		Each record is the result of the merge of all subscriptions for that
	record's multicast-address on downstream interfaces. If some		record's multicast-address on downstream interfaces. If some
	subscriptions are IGMPv1 or IGMPv2/MLDv1 subscriptions, these		subscriptions are IGMPv1 or IGMPv2/MLDv1 subscriptions, these
	subscriptions are converted to IGMPv3/MLDv2 subscriptions. The		subscriptions are converted to IGMPv3/MLDv2 subscriptions. The
	IGMPv3/MLDv2 and the converted subscriptions are first preprocessed		IGMPv3/MLDv2 and the converted subscriptions are first preprocessed
	to remove the timers in the subscriptions, and if the filter mode is		to remove the timers in the subscriptions, and if the filter mode is
	EXCLUDE, to remove every source whose source timer > 0. Then the		EXCLUDE, to remove every source whose source timer > 0. Then the
	preprocessed subscriptions are merged using the merging rules for		preprocessed subscriptions are merged using the merging rules for
	multiple memberships on a single interface specified in the		multiple memberships on a single interface specified in section 3.2
	IGMPv3/MLDv2 specification[RFC 3376,MLDv2] to create the membership		of the IGMPv3 specification [RFC 3376] and in section 4.2 of the
	record. For example, there are two downstream interfaces I1 and I2		MLDv2 specification [MLDv2] to create the membership record. For
	that have subscriptions for multicast address G. I1 has an		example, there are two downstream interfaces I1 and I2 that have
	IGMPv2/MLDv1 subscription that is (G). I2 has an IGMPv3/MLDv2		subscriptions for multicast address G. I1 has an IGMPv2/MLDv1
	subscription that has membership information (G, INCLUDE, (S1, S2)).		subscription that is (G). I2 has an IGMPv3/MLDv2 subscription that
	The I1's subscription is converted to an IGMPv3/MLDv2 subscription		has membership information (G, INCLUDE, (S1, S2)). The I1's
	that has membership information (G, EXCLUDE, NULL). Then the		subscription is converted to an IGMPv3/MLDv2 subscription that has
	subscriptions are preprocessed and merged and final membership record		membership information (G, EXCLUDE, NULL). Then the subscriptions are
	is (G, EXCLUDE, NULL).		preprocessed and merged and final membership record is (G, EXCLUDE,
			NULL).
	The proxy device performs the host portion of the IGMP/MLD protocol		The proxy device performs the host portion of the IGMP/MLD protocol
	on the upstream interface. If there is an IGMPv1 or IGMPv2/MLDv1		on the upstream interface. If there is an IGMPv1 or IGMPv2/MLDv1
	querier on the upstream network, then the proxy device will perform		querier on the upstream network, then the proxy device will perform
	IGMPv1 or IGMPv2/MLDv1 on the upstream interface accordingly.		IGMPv1 or IGMPv2/MLDv1 on the upstream interface accordingly.
	Otherwise, it will perform IGMPv3/MLDv2.		Otherwise, it will perform IGMPv3/MLDv2.
	If the proxy device performs IGMPv3/MLDv2 on the upstream interface,		If the proxy device performs IGMPv3/MLDv2 on the upstream interface,
	then when the composition of the membership database changes, the		then when the composition of the membership database changes, the
	change in the database is reported on the upstream interface as		change in the database is reported on the upstream interface as
	though this proxy device were a host performing the action. If the		though this proxy device were a host performing the action. If the
	proxy device performs IGMPv1 or IGMPv2/MLDv1 on the upstream		proxy device performs IGMPv1 or IGMPv2/MLDv1 on the upstream
	interface, then when the membership records are created or deleted,		interface, then when the membership records are created or deleted,
	the changes are reported on the upstream interface. All other		the changes are reported on the upstream interface. All other
	changes are ignored. When the proxy device reports using IGMPv1 or		changes are ignored. When the proxy device reports using IGMPv1 or
	skipping to change at page 8, line 45 ¶		skipping to change at page 8, line 50 ¶
	be compliant with the specification about using IGMPv3 for SSM [SSM].		be compliant with the specification about using IGMPv3 for SSM [SSM].
	Note that the proxy device should be compliant with both the IGMP		Note that the proxy device should be compliant with both the IGMP
	Host Requirement and the IGMP Router Requirement for SSM since it		Host Requirement and the IGMP Router Requirement for SSM since it
	performs IGMP Host Portion on the upstream interface and IGMP Router		performs IGMP Host Portion on the upstream interface and IGMP Router
	Portion on each downstream interface.		Portion on each downstream interface.
	An interface can be configured to perform IGMPv1 or IGMPv2. In this		An interface can be configured to perform IGMPv1 or IGMPv2. In this
	scenario, the SSM semantic will not be maintained for that interface.		scenario, the SSM semantic will not be maintained for that interface.
	However, a proxy device that supports this document should ignore		However, a proxy device that supports this document should ignore
	those IGMPv1 or IGMPv2 subscriptions sent to SSM addresses. And more		those IGMPv1 or IGMPv2 subscriptions sent to SSM addresses. And more
	importantly, the packets with source-specific addresses SHOULD not be		importantly, the packets with source-specific addresses SHOULD NOT be
	forwarded to interfaces with IGMPv2 or IGMPv1 subscriptions for these		forwarded to interfaces with IGMPv2 or IGMPv1 subscriptions for these
	addresses.		addresses.
	5. Security Considerations		5. Security Considerations
	Since only the Querier forwards packets, the IGMP/MLD Querier		Since only the Querier forwards packets, the IGMP/MLD Querier
	election process may lead to black holes if a non-forwarder is		election process may lead to black holes if a non-forwarder is
	elected Querier. An attacker on a downstream LAN can cause itself to		elected Querier. An attacker on a downstream LAN can cause itself to
	be elected Querier resulting in no packets being forwarded. However,		be elected Querier resulting in no packets being forwarded. However,
	there are some operational ways to avoid this problem. It is fairly		there are some operational ways to avoid this problem. It is fairly
	common for an operator to number the routers starting from the bottom		common for an operator to number the routers starting from the bottom
	of the subnet. So an operator can assign the subnet's lowest IP		of the subnet. So an operator SHOULD assign the subnet's lowest IP
	address to a proxy in order for the proxy to win the querier		address(es) to a proxy (proxies) in order for the proxy (proxies) to
	election.		win the querier election.
	IGMP/MLD-based forwarding does not provide "upstream loop" detection		IGMP/MLD-based forwarding does not provide "upstream loop" detection
	mechanism as described in section 3. Hence to avoid the problems		mechanism as described in section 3. Hence to avoid the problems
	caused by an "upstream loop", it MUST be administratively assured		caused by an "upstream loop", it MUST be administratively assured
	that such loops don't exist when deploying IGMP/MLD Proxying.		that such loops don't exist when deploying IGMP/MLD Proxying.
	The IGMP/MLD information presented by the proxy to its upstream		The IGMP/MLD information presented by the proxy to its upstream
	routers is the aggregation of all its downstream group membership		routers is the aggregation of all its downstream group membership
	information. Any access control applied on the group membership		information. Any access control applied on the group membership
	protocol at the upstream router can not be performed on a single		protocol at the upstream router can not be performed on a single
	skipping to change at page 10, line 13 ¶		skipping to change at page 10, line 16 ¶
	RFC 1112, August 1989.		RFC 1112, August 1989.
	[RFC 2710] Deering, S., Fenner, W., and Haberman, B., "Multicast		[RFC 2710] Deering, S., Fenner, W., and Haberman, B., "Multicast
	Listener Discovery (MLD) for IPv6", RFC 2710,		Listener Discovery (MLD) for IPv6", RFC 2710,
	October 1999.		October 1999.
	[MLDv2] Vida, R., Costa and L., Fdida, "Multicast Listener		[MLDv2] Vida, R., Costa and L., Fdida, "Multicast Listener
	Discovery Version 2 (MLDv2) for IPv6", Work in Progress.		Discovery Version 2 (MLDv2) for IPv6", Work in Progress.
	[SSM] Holbrook, H., and Cain, B., "Using IGMPv3 for Source-		[SSM] Holbrook, H., Cain, B., and Haberman, B., "Using IGMPv3
	Specific Multicast", Work in Progress.		and MLDv2 for Source-Specific Multicast", Work in Progress.
	Informative References		Informative References
	[MCAST] Deering, S., "Multicast Routing in a Datagram		[MCAST] Deering, S., "Multicast Routing in a Datagram
	Internetwork", Ph.D. Thesis, Stanford University,		Internetwork", Ph.D. Thesis, Stanford University,
	December 1991.		December 1991.
	[PIM-SM] Fenner, W., Handley, M., Holbrook, H., and Kouvelas, I.,		[PIM-SM] Fenner, W., Handley, M., Holbrook, H., and Kouvelas, I.,
	"Protocol Independent Multicast - Sparse Mode (PIM-SM):		"Protocol Independent Multicast - Sparse Mode (PIM-SM):
	Protocol Specification (Revised)", Work in Progress.		Protocol Specification (Revised)", Work in Progress.
End of changes. 10 change blocks.
	24 lines changed or deleted		28 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/