draft-ietf-mboned-routingarch-06.txt		draft-ietf-mboned-routingarch-07.txt
	Internet Engineering Task Force P. Savola		Internet Engineering Task Force P. Savola
	Internet-Draft CSC/FUNET		Internet-Draft CSC/FUNET
	Obsoletes: August 15, 2006		Obsoletes: November 21, 2006
	3913,2189,2201,1584,1585		3913,2189,2201,1584,1585
	(if approved)		(if approved)
	Intended status: Best Current		Intended status: Best Current
	Practice		Practice
	Expires: February 16, 2007		Expires: May 25, 2007
	Overview of the Internet Multicast Routing Architecture		Overview of the Internet Multicast Routing Architecture
	draft-ietf-mboned-routingarch-06.txt		draft-ietf-mboned-routingarch-07.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	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.
	This Internet-Draft will expire on February 16, 2007.		This Internet-Draft will expire on May 25, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2006).
	Abstract		Abstract
	The lack of up-to-date documentation on IP multicast routing		The lack of up-to-date documentation on IP multicast routing
	protocols and procedures has caused a great deal of confusion. To		protocols and procedures has caused a great deal of confusion. To
	clarify the situation, this memo describes the routing protocols and		clarify the situation, this memo describes the routing protocols and
	techniques currently (as of this writing) in use.		techniques currently (as of this writing) in use. This memo also
			Obsoletes and reclassifies to Historic a number of older multicast
			protocols.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 5		1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 5
	2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 5		2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Setting up Multicast Forwarding State . . . . . . . . . . 6		2.1. Setting up Multicast Forwarding State . . . . . . . . . . 6
	2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 6		2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 6		2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 6		2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 6
	skipping to change at page 2, line 33		skipping to change at page 2, line 35
	2.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 10		2.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 10
	2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 10		2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 10
	2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 11		2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 11
	2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11		2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11
	2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 11		2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 11
	2.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 12		2.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 12
	2.4. Configuring and Distributing PIM RP Information . . . . . 12		2.4. Configuring and Distributing PIM RP Information . . . . . 12
	2.4.1. Manual RP Configuration . . . . . . . . . . . . . . . 12		2.4.1. Manual RP Configuration . . . . . . . . . . . . . . . 12
	2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 13		2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 13
	2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 13		2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 13
	2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 14		2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 13
	2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 14		2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 14
	2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 14		2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 14
	2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 14		2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 14
	2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 15		2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 14
	2.5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 15		2.5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 15
	2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 15		2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 15
	2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 15		2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 15
	2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 15		2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 15
	2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16		2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 15
	2.7. Restricting Multicast Flooding in the Link Layer . . . . . 16		2.7. Restricting Multicast Flooding in the Link Layer . . . . . 16
	2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 16		2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 16
	2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 16		2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 16
	2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 17		2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 17
	3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18		3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 18		5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 18		6.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	6.2. Informative References . . . . . . . . . . . . . . . . . . 20		6.2. Informative References . . . . . . . . . . . . . . . . . . 20
	Appendix A. Multicast Payload Transport Extensions . . . . . . . 22		Appendix A. Multicast Payload Transport Extensions . . . . . . . 22
	A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 22		A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 23
	A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 23		A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 23
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
	Intellectual Property and Copyright Statements . . . . . . . . . . 24		Intellectual Property and Copyright Statements . . . . . . . . . . 24
	1. Introduction		1. Introduction
	Good, up-to-date documentation of IP multicast is close to non-		Good, up-to-date documentation of IP multicast is close to non-
	existent. This issue is severely felt with multicast routing		existent. This issue is severely felt with multicast routing
	protocols and techniques. The consequence is that those who wish to		protocols and techniques. The consequence is that those who wish to
	learn of IP multicast and how the routing works in the real world do		learn of IP multicast and how the routing works in the real world do
	skipping to change at page 5, line 5		skipping to change at page 4, line 47
	This memo obsoletes and re-classifies to Historic [RFC2026] Border		This memo obsoletes and re-classifies to Historic [RFC2026] Border
	Gateway Multicast Protocol (BGMP), Core Based Trees (CBT), Multicast		Gateway Multicast Protocol (BGMP), Core Based Trees (CBT), Multicast
	OSPF (MOSPF) RFCs: [RFC3913], [RFC2189], [RFC2201], [RFC1584], and		OSPF (MOSPF) RFCs: [RFC3913], [RFC2189], [RFC2201], [RFC1584], and
	[RFC1585]. The purpose of the re-classification is to give the		[RFC1585]. The purpose of the re-classification is to give the
	readers (both implementors and deployers) an idea what the status of		readers (both implementors and deployers) an idea what the status of
	a protocol is; there may be legacy deployments of some of these		a protocol is; there may be legacy deployments of some of these
	protocols, which are not affected by this reclassification. See		protocols, which are not affected by this reclassification. See
	Section 2.1 for more on each protocol.		Section 2.1 for more on each protocol.
			Further historical perspective may be found in, for example,
			[RFC1458], [IMRP-ISSUES], and [IM-GAPS].
	1.1. Multicast-related Abbreviations		1.1. Multicast-related Abbreviations
	ASM Any Source Multicast		ASM Any Source Multicast
	BGMP Border Gateway Multicast Protocol		BGMP Border Gateway Multicast Protocol
	BSR Bootstrap Router		BSR Bootstrap Router
	CBT Core Based Trees		CBT Core Based Trees
	CGMP Cisco Group Management Protocol		CGMP Cisco Group Management Protocol
	DR Designated Router		DR Designated Router
	DVMRP Distance Vector Multicast Routing Protocol		DVMRP Distance Vector Multicast Routing Protocol
	GARP (IEEE 802.1D-2004) Generic Attribute Reg. Protocol		GARP (IEEE 802.1D-2004) Generic Attribute Reg. Protocol
	GMRP GARP Multicast Registration Protocol		GMRP GARP Multicast Registration Protocol
	IGMP Internet Group Management Protocol		IGMP Internet Group Management Protocol
	MBGP Multi-protocol BGP (*not* "Multicast BGP")		MBGP Multi-protocol BGP (*not* "Multicast BGP")
	MLD Multicast Listener Discovery		MLD Multicast Listener Discovery
	MMRP (IEEE 802.1ak) Multicast Multiple Registration Protocol		MRP (IEEE 802.1ak) Multiple Registration Protocol
			MMRP (IEEE 802.1ak) Multicast Multiple Registration Proto.
	MOSPF Multicast OSPF		MOSPF Multicast OSPF
	MSDP Multicast Source Discovery Protocol		MSDP Multicast Source Discovery Protocol
	PGM Pragmatic General Multicast		PGM Pragmatic General Multicast
	PIM Protocol Independent Multicast		PIM Protocol Independent Multicast
	PIM-DM PIM - Dense Mode		PIM-DM PIM - Dense Mode
	PIM-SM PIM - Sparse Mode		PIM-SM PIM - Sparse Mode
	PIM-SSM PIM - Source-Specific Multicast		PIM-SSM PIM - Source-Specific Multicast
	RGMP (Cisco's) Router Group Management Protocol		RGMP (Cisco's) Router Group Management Protocol
	RP Rendezvous Point		RP Rendezvous Point
	SSM Source-specific Multicast		SSM Source-specific Multicast
	skipping to change at page 6, line 14		skipping to change at page 6, line 15
	2.1. Setting up Multicast Forwarding State		2.1. Setting up Multicast Forwarding State
	The most important part of multicast routing is setting up the		The most important part of multicast routing is setting up the
	multicast forwarding state. This section describes the protocols		multicast forwarding state. This section describes the protocols
	commonly used for this purpose.		commonly used for this purpose.
	2.1.1. PIM-SM		2.1.1. PIM-SM
	By far, the most common multicast routing protocol is PIM-SM		By far, the most common multicast routing protocol is PIM-SM
	[I-D.ietf-pim-sm-v2-new]. The PIM-SM protocol includes both Any		[RFC4601]. The PIM-SM protocol includes both Any Source Multicast
	Source Multicast (ASM) and Source-Specific Multicast (SSM)		(ASM) and Source-Specific Multicast (SSM) functionality; PIM-SSM is a
	functionality; PIM-SSM is a subset of PIM-SM. Most current routing		subset of PIM-SM. Most current routing platforms support PIM-SM.
	platforms support PIM-SM.
	2.1.2. PIM-DM		2.1.2. PIM-DM
	Whereas PIM-SM has been designed to avoid unnecessary flooding of		Whereas PIM-SM has been designed to avoid unnecessary flooding of
	multicast data, PIM-DM [RFC3973] assumed that almost every subnet at		multicast data, PIM-DM [RFC3973] assumed that almost every subnet at
	a site had at least one receiver for a group. PIM-DM floods		a site had at least one receiver for a group. PIM-DM floods
	multicast transmissions throughout the network ("flood and prune")		multicast transmissions throughout the network ("flood and prune")
	unless the leaf parts of the network periodically indicate that they		unless the leaf parts of the network periodically indicate that they
	are not interested in that particular group.		are not interested in that particular group.
	skipping to change at page 7, line 46		skipping to change at page 7, line 47
	2.1.6. BGMP		2.1.6. BGMP
	BGMP [RFC3913] did not get sufficient support within the service		BGMP [RFC3913] did not get sufficient support within the service
	provider community to get adopted and moved forward in the IETF		provider community to get adopted and moved forward in the IETF
	standards process. There were no reported production implementations		standards process. There were no reported production implementations
	and no production deployments.		and no production deployments.
	2.1.7. CBT		2.1.7. CBT
	CBT [RFC2201] was an academic project that provided the basis for PIM		CBT [RFC2201][RFC2189] was an academic project that provided the
	sparse mode shared trees. Once the shared tree functionality was		basis for PIM sparse mode shared trees. Once the shared tree
	incorporated into PIM implementations, there was no longer a need for		functionality was incorporated into PIM implementations, there was no
	a production CBT implemention. Therefore, CBT never saw production		longer a need for a production CBT implementation. Therefore, CBT
	deployment.		never saw production deployment.
	2.1.8. Interactions and Summary		2.1.8. Interactions and Summary
	It is worth noting that it is possible to run different protocols		It is worth noting that it is possible to run different protocols
	with different multicast group ranges. For example, treat some		with different multicast group ranges. For example, treat some
	groups as dense or bi-dir in an otherwise PIM-SM network; this		groups as dense or bi-dir in an otherwise PIM-SM network; this
	typically requires manual configuration of the groups or a mechanism		typically requires manual configuration of the groups or a mechanism
	like BSR (Section 2.4.3). It is also possible to interact between		like BSR (Section 2.4.3). It is also possible to interact between
	different protocols, for example use DVMRP in the leaf network, but		different protocols, for example use DVMRP in the leaf network, but
	PIM-SM upstream. The basics for interactions among different		PIM-SM upstream. The basics for interactions among different
	skipping to change at page 11, line 17		skipping to change at page 11, line 17
	PIM-SM domain for the whole Internet is a completely unscalable model		PIM-SM domain for the whole Internet is a completely unscalable model
	for many reasons. Therefore it is required to be able to split up		for many reasons. Therefore it is required to be able to split up
	the multicast routing infrastructures to smaller domains, and there		the multicast routing infrastructures to smaller domains, and there
	must be a way to share information about active sources using some		must be a way to share information about active sources using some
	mechanism if the ASM model is to be supported.		mechanism if the ASM model is to be supported.
	This section discusses the options.		This section discusses the options.
	2.3.1. SSM		2.3.1. SSM
	Source-specific Multicast [I-D.ietf-ssm-arch] (sometimes also		Source-specific Multicast [RFC4607] (sometimes also referred to as
	referred to as "single-source Multicast") does not count on learning		"single-source Multicast") does not count on learning active sources
	active sources in the network. Recipients need to know the source IP		in the network. Recipients need to know the source IP addresses
	addresses using an out of band mechanism which are used to subscribe		using an out of band mechanism which are used to subscribe to the
	to the (source, group) channel. The multicast routing uses the		(source, group) channel. The multicast routing uses the source
	source address to set up the state and no further source discovery is		address to set up the state and no further source discovery is
	needed.		needed.
	As of this writing, there are attempts to analyze and/or define out-		As of this writing, there are attempts to analyze and/or define out-
	of-band source discovery functions which would help SSM in particular		of-band source discovery functions which would help SSM in particular
	[I-D.lehtonen-mboned-dynssm-req].		[I-D.lehtonen-mboned-dynssm-req].
	2.3.2. MSDP		2.3.2. MSDP
	Multicast Source Discovery Protocol [RFC3618] was invented as a stop-		Multicast Source Discovery Protocol [RFC3618] was invented as a stop-
	gap mechanism, when it became apparent that multiple PIM-SM domains		gap mechanism, when it became apparent that multiple PIM-SM domains
	(and RPs) were needed in the network, and information about the		(and RPs) were needed in the network, and information about the
	active sources needed to be propagated between the PIM-SM domains		active sources needed to be propagated between the PIM-SM domains
	using some other protocol.		using some other protocol.
	MSDP is also used to share the state about sources between multiple		MSDP is also used to share the state about sources between multiple
	RPs in a single domain for, e.g., redundancy purposes [RFC3446]. The		RPs in a single domain for, e.g., redundancy purposes [RFC3446]. The
	same can be achieved using PIM extensions [I-D.ietf-pim-anycast-rp].		same can be achieved using PIM extensions [RFC4610]. See Section 2.5
	See Section 2.5 for more information.		for more information.
	There is no intent to define MSDP for IPv6, but instead use only SSM		There is no intent to define MSDP for IPv6, but instead use only SSM
	and Embedded-RP instead [I-D.ietf-mboned-ipv6-multicast-issues].		and Embedded-RP instead [I-D.ietf-mboned-ipv6-multicast-issues].
	2.3.3. Embedded-RP		2.3.3. Embedded-RP
	Embedded-RP [RFC3956] is an IPv6-only technique to map the address of		Embedded-RP [RFC3956] is an IPv6-only technique to map the address of
	the RP to the multicast group address. Using this method, it is		the RP to the multicast group address. Using this method, it is
	possible to avoid the use of MSDP while still allowing multiple		possible to avoid the use of MSDP while still allowing multiple
	multicast domains (in the traditional sense).		multicast domains (in the traditional sense).
	skipping to change at page 12, line 40		skipping to change at page 12, line 40
	It is often easiest just to manually configure the RP information on		It is often easiest just to manually configure the RP information on
	the routers when PIM-SM is used.		the routers when PIM-SM is used.
	Originally, static RP mapping was considered suboptimal since it		Originally, static RP mapping was considered suboptimal since it
	required explicit configuration changes every time the RP address		required explicit configuration changes every time the RP address
	changed. However, with the advent of anycast RP addressing, the RP		changed. However, with the advent of anycast RP addressing, the RP
	address is unlikely to ever change. Therefore, the administrative		address is unlikely to ever change. Therefore, the administrative
	burden is generally limited to initial configuration. Since there is		burden is generally limited to initial configuration. Since there is
	usually a fair amount of multicast configuration required on all		usually a fair amount of multicast configuration required on all
	routers anyway (eg, PIM on all interfaces), adding the RP address		routers anyway (e.g., PIM on all interfaces), adding the RP address
	statically isn't really an issue. Further, static anycast RP mapping		statically isn't really an issue. Further, static anycast RP mapping
	provides the benefits of RP load sharing and redundancy (see		provides the benefits of RP load sharing and redundancy (see
	Section 2.5) without the complexity found in dynamic mechanisms like		Section 2.5) without the complexity found in dynamic mechanisms like
	Auto-RP and Bootstrap Router (BSR).		Auto-RP and Bootstrap Router (BSR).
	With such design, an anycast RP uses an address that is configured on		With such design, an anycast RP uses an address that is configured on
	a loopback interfaces of the routers currently acting as RPs, and		a loopback interfaces of the routers currently acting as RPs, and
	state is distributed using PIM [I-D.ietf-pim-anycast-rp] or MSDP		state is distributed using PIM [RFC4610] or MSDP [RFC3446].
	[RFC3446].
	Using this technique, each router might only need to be configured		Using this technique, each router might only need to be configured
	with one, portable RP address.		with one, portable RP address.
	2.4.2. Embedded-RP		2.4.2. Embedded-RP
	Embedded-RP provides the information about the RP's address in the		Embedded-RP provides the information about the RP's address in the
	group addresses which are delegated to those who use the RP, so		group addresses which are delegated to those who use the RP, so
	unless no other ASM than Embedded-RP is used, the network		unless no other ASM than Embedded-RP is used, the network
	administrator only needs to configure the RP routers.		administrator only needs to configure the RP routers.
	skipping to change at page 13, line 27		skipping to change at page 13, line 26
	not dependent on local RP addresses.		not dependent on local RP addresses.
	As the RP's address is exposed to the users and applications, it is		As the RP's address is exposed to the users and applications, it is
	very important to ensure it does not change often, e.g., by using		very important to ensure it does not change often, e.g., by using
	manual configuration of an anycast address.		manual configuration of an anycast address.
	2.4.3. BSR and Auto-RP		2.4.3. BSR and Auto-RP
	BSR [I-D.ietf-pim-sm-bsr] is a mechanism for configuring the RP		BSR [I-D.ietf-pim-sm-bsr] is a mechanism for configuring the RP
	address for groups. It may no longer be in as wide use with IPv4 as		address for groups. It may no longer be in as wide use with IPv4 as
	it was ealier, and for IPv6, Embedded-RP will in many cases be		it was earlier, and for IPv6, Embedded-RP will in many cases be
	sufficient.		sufficient.
	Cisco's Auto-RP is an older, proprietary method for distributing		Cisco's Auto-RP is an older, proprietary method for distributing
	group to RP mappings, similar to BSR. Auto-RP has little use today.		group to RP mappings, similar to BSR. Auto-RP has little use today.
	Both Auto-RP and BSR require some form of control at the routers to		Both Auto-RP and BSR require some form of control at the routers to
	ensure that only valid routers are able to advertise themselves as		ensure that only valid routers are able to advertise themselves as
	RPs. Further, flooding of BSR and Auto-RP messages must be prevented		RPs. Further, flooding of BSR and Auto-RP messages must be prevented
	at PIM borders. Additionally, routers require monitoring that they		at PIM borders. Additionally, routers require monitoring that they
	are actually using the RP(s) the administrators think they should be		are actually using the RP(s) the administrators think they should be
	skipping to change at page 14, line 35		skipping to change at page 14, line 29
	techniques explicitly.		techniques explicitly.
	2.5.1. Anycast RP		2.5.1. Anycast RP
	As mentioned in Section 2.3.2, MSDP is also used to share the state		As mentioned in Section 2.3.2, MSDP is also used to share the state
	about sources between multiple RPs in a single domain for, e.g.,		about sources between multiple RPs in a single domain for, e.g.,
	redundancy purposes [RFC3446]. The purpose of MSDP in this context		redundancy purposes [RFC3446]. The purpose of MSDP in this context
	is to share the same state information on multiple RPs for the same		is to share the same state information on multiple RPs for the same
	groups to enhance the robustness of the service.		groups to enhance the robustness of the service.
	Recent PIM extensions [I-D.ietf-pim-anycast-rp] also provide this		Recent PIM extensions [RFC4610] also provide this functionality. In
	functionality. In contrast to MSDP, this approach works for both		contrast to MSDP, this approach works for both IPv4 and IPv6.
	IPv4 and IPv6.
	2.5.2. Stateless RP Failover		2.5.2. Stateless RP Failover
	It is also possible to use some mechanisms for smaller amount of		It is also possible to use some mechanisms for smaller amount of
	redundancy as Anycast RP, without sharing state between the RPs. A		redundancy as Anycast RP, without sharing state between the RPs. A
	traditional mechanism has been to use Auto-RP or BSR (see		traditional mechanism has been to use Auto-RP or BSR (see
	Section 2.4.3) to select another RP when the active one failed.		Section 2.4.3) to select another RP when the active one failed.
	However, the same functionality could be achieved using a shared-		However, the same functionality could be achieved using a shared-
	unicast RP address ("anycast RP without state sharing") without the		unicast RP address ("anycast RP without state sharing") without the
	complexity of a dynamic mechanism. Further, Anycast RP offers a		complexity of a dynamic mechanism. Further, Anycast RP offers a
	skipping to change at page 16, line 33		skipping to change at page 16, line 25
	Multicast transmission in the link layer, for example Ethernet,		Multicast transmission in the link layer, for example Ethernet,
	typically includes some form of flooding the packets through a LAN.		typically includes some form of flooding the packets through a LAN.
	This causes unnecessary bandwidth usage and discarding unwanted		This causes unnecessary bandwidth usage and discarding unwanted
	frames on those nodes which did not want to receive the multicast		frames on those nodes which did not want to receive the multicast
	transmission.		transmission.
	Therefore a number of techniques have been developed, to be used in		Therefore a number of techniques have been developed, to be used in
	Ethernet switches between routers, or between routers and hosts, to		Ethernet switches between routers, or between routers and hosts, to
	limit the flooding.		limit the flooding.
			Some mechanisms operate with IP addresses, others with MAC addresses.
			If filtering is done based on MAC addresses, hosts may receive
			unnecessary multicast traffic (filtered out in the hosts' IP layer)
			if more than one IP multicast group addresses maps into the same MAC
			address, or if IGMPv3/MLDv2 source filters are used. Filtering based
			on IP destination addresses, or destination and sources addresses,
			will help avoid these but requires parsing of the Ethernet frame
			payload.
	These options are discussed in this section.		These options are discussed in this section.
	2.7.1. Router-to-Router Flooding Reduction		2.7.1. Router-to-Router Flooding Reduction
	A proprietary solution, Cisco's RGMP [RFC3488] has been developed to		A proprietary solution, Cisco's RGMP [RFC3488] has been developed to
	reduce the amount of flooding between routers in a switched networks.		reduce the amount of flooding between routers in a switched networks.
	This is typically only considered a problem in some Ethernet-based		This is typically only considered a problem in some Ethernet-based
	Internet Exchange points or VPNs.		Internet Exchange points or VPNs.
	There have been proposals to observe and possibly react ("snoop") PIM		There have been proposals to observe and possibly react ("snoop") PIM
	messages [I-D.ietf-l2vpn-vpls-pim-snooping].		messages [I-D.ietf-l2vpn-vpls-pim-snooping].
	2.7.2. Host/Router Flooding Reduction		2.7.2. Host/Router Flooding Reduction
	There are a number of techniques to help reduce flooding both from a		There are a number of techniques to help reduce flooding both from a
	router to hosts, and from a host to the routers (and other hosts).		router to hosts, and from a host to the routers (and other hosts).
	Cisco's proprietary CGMP [CGMP] provides a solution where the routers		Cisco's proprietary CGMP [CGMP] provides a solution where the routers
	notify the switches, but also allows the switches to snoop IGMP		notify the switches, but also allows the switches to snoop IGMP
	packets to enable faster notification of hosts no longer wishing to		packets to enable faster notification of hosts no longer wishing to
	receive a group. IPv6 is not supported.		receive a group. Fast leave behaviour support for IGMPv3 hasn't been
			implemented. Due to IGMP report suppression in IGMPv1 and IGMPv2,
			multicast is still flooded to ports which were once members of a
			group as long as there is at least one receiver on the link.
			Flooding restrictions are done based on multicast MAC addresses.
			IPv6 is not supported.
	IEEE 802.1D-2004 specification describes Generic Attribute		IEEE 802.1D-2004 specification describes Generic Attribute
	Registration Protocol (GARP), and GARP Multicast Registration		Registration Protocol (GARP), and GARP Multicast Registration
	Protocol (GMRP) [GMRP] is a link-layer multicast group application of		Protocol (GMRP) [GMRP] is a link-layer multicast group application of
	GARP that notifies switches about IP multicast group memberships.		GARP that notifies switches about MAC multicast group memberships.
			If GMRP is used in conjunction with IP multicast, then the GMRP
			registration function would become associated with an IGMP "join."
			However, this GMRP-IGMP association is beyond the scope of GMRP.
	GMRP requires support at the host stack and it has not been widely		GMRP requires support at the host stack and it has not been widely
	implemented. Further, IEEE considers GMRP obsolete having been		implemented. Further, IEEE 802.1 considers GARP and GMRP obsolete
	replaced by Multicast Multiple Registration Protocol (MMRP) that's		being replaced by Multiple Registration Protocol (MRP) and Multicast
	being specified in IEEE 802.1ak [802.1ak]. MMRP is expected to be		Multiple Registration Protocol (MMRP) that are being specified in
	mainly used between bridges. Some further information about GARP/		IEEE 802.1ak [802.1ak]. MMRP is expected to be mainly used between
	GMRP is also available in Appendix B of [RFC3488].		bridges. Some further information about GARP/GMRP is also available
			in Appendix B of [RFC3488].
	IGMP snooping [RFC4541] appears to be the most widely implemented		IGMP snooping [RFC4541] appears to be the most widely implemented
	technique. IGMP snooping requires that the switches implement a		technique. IGMP snooping requires that the switches implement a
	significant amount of IP-level packet inspection; this appears to be		significant amount of IP-level packet inspection; this appears to be
	something that is difficult to get right, and often the upgrades are		something that is difficult to get right, and often the upgrades are
	also a challenge.		also a challenge.
	Snooping switches also need to identify the ports where routers		Snooping switches also need to identify the ports where routers
	reside and therefore where to flood the packets. This can be		reside and therefore where to flood the packets. This can be
	accomplished using Multicast Router Discovery protocol [RFC4286],		accomplished using Multicast Router Discovery protocol [RFC4286],
	looking at certain IGMP queries [RFC4541], looking at PIM Hello and		looking at certain IGMP queries [RFC4541], looking at PIM Hello and
	possibly other messages, or by manual configuration. An issue with		possibly other messages, or by manual configuration. An issue with
	PIM snooping at LANs is that PIM messages can't be turned off or		PIM snooping at LANs is that PIM messages can't be turned off or
	encrypted, leading to security issues		encrypted, leading to security issues [I-D.ietf-pim-lasthop-threats].
	[I-D.savola-pim-lasthop-threats].
	IGMP proxying [I-D.ietf-magma-igmp-proxy] is sometimes used either as		IGMP proxying [RFC4605] is sometimes used either as a replacement of
	a replacement of a multicast routing protocol on a small router, or		a multicast routing protocol on a small router, or to aggregate IGMP/
	to aggregate IGMP/MLD reports when used with IGMP snooping.		MLD reports when used with IGMP snooping.
	2.7.3. Summary		2.7.3. Summary
	The following table summarizes the techniques for multicast flooding		The following table summarizes the techniques for multicast flooding
	reduction inside a single link for router-to-router and last-hop		reduction inside a single link for router-to-router and last-hop
	LANs.		LANs.
	+--------+-----+---------------------------+		+--------+-----+---------------------------+
	| R-to-R | LAN | Notes |		| R-to-R | LAN | Notes |
	+-----------------------+--------+-----+---------------------------+		+-----------------------+--------+-----+---------------------------+
	skipping to change at page 18, line 15		skipping to change at page 18, line 25
	3. Acknowledgements		3. Acknowledgements
	Tutoring a couple multicast-related papers, the latest by Kaarle		Tutoring a couple multicast-related papers, the latest by Kaarle
	Ritvanen [RITVANEN] convinced the author that up-to-date multicast		Ritvanen [RITVANEN] convinced the author that up-to-date multicast
	routing and address assignment/allocation documentation is necessary.		routing and address assignment/allocation documentation is necessary.
	Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer,		Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer,
	Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat		Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat
	Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon		Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon
	Chisholm, and John Zwiebel provided good comments, helping in		Chisholm, John Zwiebel, Dan Romascanu, and Thomas Morin provided good
	improving this document.		comments, helping in improving this document.
	4. IANA Considerations		4. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	5. Security Considerations		5. Security Considerations
	This memo only describes different approaches to multicast routing,		This memo only describes different approaches to multicast routing,
	and this has no security considerations; the security analysis of the		and this has no security considerations; the security analysis of the
	mentioned protocols is out of scope of this memo.		mentioned protocols is out of scope of this memo.
	However, there has been analysis of the security of multicast routing		However, there has been analysis of the security of multicast routing
	infrastructures [I-D.ietf-mboned-mroutesec], IGMP/MLD		infrastructures [RFC4609], IGMP/MLD [I-D.daley-magma-smld-prob], and
	[I-D.daley-magma-smld-prob], and PIM last-hop issues		PIM last-hop issues [I-D.ietf-pim-lasthop-threats].
	[I-D.savola-pim-lasthop-threats].
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[I-D.ietf-idr-rfc2858bis]		[I-D.ietf-idr-rfc2858bis]
	Bates, T., "Multiprotocol Extensions for BGP-4",		Bates, T., "Multiprotocol Extensions for BGP-4",
	draft-ietf-idr-rfc2858bis-10 (work in progress),		draft-ietf-idr-rfc2858bis-10 (work in progress),
	March 2006.		March 2006.
	[I-D.ietf-isis-wg-multi-topology]		[I-D.ietf-isis-wg-multi-topology]
	Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in		Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in
	IS-IS", draft-ietf-isis-wg-multi-topology-11 (work in		IS-IS", draft-ietf-isis-wg-multi-topology-11 (work in
	progress), October 2005.		progress), October 2005.
	[I-D.ietf-mboned-addrarch]		[I-D.ietf-mboned-addrarch]
	Savola, P., "Overview of the Internet Multicast Addressing		Savola, P., "Overview of the Internet Multicast Addressing
	Architecture", draft-ietf-mboned-addrarch-04 (work in		Architecture", draft-ietf-mboned-addrarch-05 (work in
	progress), March 2006.		progress), October 2006.
	[I-D.ietf-ospf-mt]		[I-D.ietf-ospf-mt]
	Psenak, P., "Multi-Topology (MT) Routing in OSPF",		Psenak, P., "Multi-Topology (MT) Routing in OSPF",
	draft-ietf-ospf-mt-06 (work in progress), February 2006.		draft-ietf-ospf-mt-06 (work in progress), February 2006.
	[I-D.ietf-pim-bidir]		[I-D.ietf-pim-bidir]
	Handley, M., "Bi-directional Protocol Independent		Handley, M., "Bi-directional Protocol Independent
	Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-08 (work in		Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-08 (work in
	progress), October 2005.		progress), October 2005.
	[I-D.ietf-pim-sm-v2-new]
	Fenner, B., "Protocol Independent Multicast - Sparse Mode
	(PIM-SM): Protocol Specification (Revised)",
	draft-ietf-pim-sm-v2-new-12 (work in progress),
	March 2006.
	[I-D.ietf-ssm-arch]
	Holbrook, H. and B. Cain, "Source-Specific Multicast for
	IP", draft-ietf-ssm-arch-07 (work in progress),
	October 2005.
	[RFC2026] Bradner, S., "The Internet Standards Process -- Revision		[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
	3", BCP 9, RFC 2026, October 1996.		3", BCP 9, RFC 2026, October 1996.
	[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.		[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
	Thyagarajan, "Internet Group Management Protocol, Version		Thyagarajan, "Internet Group Management Protocol, Version
	3", RFC 3376, October 2002.		3", RFC 3376, October 2002.
	[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery		[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
	Protocol (MSDP)", RFC 3618, October 2003.		Protocol (MSDP)", RFC 3618, October 2003.
	skipping to change at page 20, line 5		skipping to change at page 19, line 46
	Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.		Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
	[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous		[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
	Point (RP) Address in an IPv6 Multicast Address",		Point (RP) Address in an IPv6 Multicast Address",
	RFC 3956, November 2004.		RFC 3956, November 2004.
	[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol		[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
	Independent Multicast - Dense Mode (PIM-DM): Protocol		Independent Multicast - Dense Mode (PIM-DM): Protocol
	Specification (Revised)", RFC 3973, January 2005.		Specification (Revised)", RFC 3973, January 2005.
			[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
			"Protocol Independent Multicast - Sparse Mode (PIM-SM):
			Protocol Specification (Revised)", RFC 4601, August 2006.
			[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
			IP", RFC 4607, August 2006.
	6.2. Informative References		6.2. Informative References
	[802.1ak] "IEEE 802.1ak - Multiple Registration Protocol",		[802.1ak] "IEEE 802.1ak - Multiple Registration Protocol",
	<http://www.ieee802.org/1/pages/802.1ak.html>.		<http://www.ieee802.org/1/pages/802.1ak.html>.
	[CGMP] "Cisco Group Management Protocol",		[CGMP] "Cisco Group Management Protocol",
	<http://www.javvin.com/protocolCGMP.html>.		<http://www.javvin.com/protocolCGMP.html>.
	[GMRP] "GARP Multicast Registration Protocol",		[GMRP] "GARP Multicast Registration Protocol",
	<http://www.javvin.com/protocolGMRP.html>.		<http://www.javvin.com/protocolGMRP.html>.
	skipping to change at page 20, line 37		skipping to change at page 20, line 37
	[I-D.ietf-idmr-dvmrp-v3-as]		[I-D.ietf-idmr-dvmrp-v3-as]
	Pusateri, T., "Distance Vector Multicast Routing Protocol		Pusateri, T., "Distance Vector Multicast Routing Protocol
	Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01		Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01
	(work in progress), May 2004.		(work in progress), May 2004.
	[I-D.ietf-l2vpn-vpls-pim-snooping]		[I-D.ietf-l2vpn-vpls-pim-snooping]
	Hemige, V., "PIM Snooping over VPLS",		Hemige, V., "PIM Snooping over VPLS",
	draft-ietf-l2vpn-vpls-pim-snooping-00 (work in progress),		draft-ietf-l2vpn-vpls-pim-snooping-00 (work in progress),
	August 2006.		August 2006.
	[I-D.ietf-magma-igmp-proxy]
	Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/
	MLD-based Multicast Forwarding ('IGMP/MLD Proxying')",
	draft-ietf-magma-igmp-proxy-06 (work in progress),
	April 2004.
	[I-D.ietf-mboned-ipv6-multicast-issues]		[I-D.ietf-mboned-ipv6-multicast-issues]
	Savola, P., "IPv6 Multicast Deployment Issues",		Savola, P., "IPv6 Multicast Deployment Issues",
	draft-ietf-mboned-ipv6-multicast-issues-02 (work in		draft-ietf-mboned-ipv6-multicast-issues-02 (work in
	progress), February 2005.		progress), February 2005.
	[I-D.ietf-mboned-mroutesec]		[I-D.ietf-pim-lasthop-threats]
	Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast		Savola, P. and J. Lingard, "Last-hop Threats to Protocol
	Routing Security Issues and Enhancements",		Independent Multicast (PIM)",
	draft-ietf-mboned-mroutesec-04 (work in progress),		draft-ietf-pim-lasthop-threats-00 (work in progress),
	October 2004.		October 2006.
	[I-D.ietf-pim-anycast-rp]
	Farinacci, D. and Y. Cai, "Anycast-RP using PIM",
	draft-ietf-pim-anycast-rp-07 (work in progress),
	February 2006.
	[I-D.ietf-pim-sm-bsr]		[I-D.ietf-pim-sm-bsr]
	Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM",		Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM",
	draft-ietf-pim-sm-bsr-09 (work in progress), June 2006.		draft-ietf-pim-sm-bsr-09 (work in progress), June 2006.
	[I-D.lehtonen-mboned-dynssm-req]		[I-D.lehtonen-mboned-dynssm-req]
	Lehtonen, R., "Requirements for discovery of dynamic SSM		Lehtonen, R., "Requirements for discovery of dynamic SSM
	sources", draft-lehtonen-mboned-dynssm-req-00 (work in		sources", draft-lehtonen-mboned-dynssm-req-00 (work in
	progress), February 2005.		progress), February 2005.
	[I-D.savola-pim-lasthop-threats]		[IM-GAPS] Meyer, D. and B. Nickless, "Internet Multicast Gap
	Lingard, J. and P. Savola, "Last-hop Threats to Protocol		Analysis from the MBONED Working Group for the IESG
	Independent Multicast (PIM)",		[Expired]", draft-ietf-mboned-iesg-gap-analysis-00 (work
	draft-savola-pim-lasthop-threats-02 (work in progress),		in progress), July 2002.
	June 2006.
			[IMRP-ISSUES]
			Meyer, D., "Some Issues for an Inter-domain Multicast
			Routing Protocol [Expired]",
			draft-ietf-mboned-imrp-some-issues-01 (work in progress),
			September 1997.
	[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance		[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
	Vector Multicast Routing Protocol", RFC 1075,		Vector Multicast Routing Protocol", RFC 1075,
	November 1988.		November 1988.
			[RFC1458] Braudes, B. and S. Zabele, "Requirements for Multicast
			Protocols", RFC 1458, May 1993.
	[RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584,		[RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584,
	March 1994.		March 1994.
	[RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585,		[RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585,
	March 1994.		March 1994.
	[RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast		[RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast
	Routing -- Protocol Specification --", RFC 2189,		Routing -- Protocol Specification --", RFC 2189,
	September 1997.		September 1997.
	skipping to change at page 22, line 28		skipping to change at page 22, line 27
	Protocol Specification", RFC 3913, September 2004.		Protocol Specification", RFC 3913, September 2004.
	[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",		[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
	RFC 4286, December 2005.		RFC 4286, December 2005.
	[RFC4541] Christensen, M., Kimball, K., and F. Solensky,		[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
	"Considerations for Internet Group Management Protocol		"Considerations for Internet Group Management Protocol
	(IGMP) and Multicast Listener Discovery (MLD) Snooping		(IGMP) and Multicast Listener Discovery (MLD) Snooping
	Switches", RFC 4541, May 2006.		Switches", RFC 4541, May 2006.
			[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
			"Internet Group Management Protocol (IGMP) / Multicast
			Listener Discovery (MLD)-Based Multicast Forwarding
			("IGMP/MLD Proxying")", RFC 4605, August 2006.
			[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
			Independent Multicast - Sparse Mode (PIM-SM) Multicast
			Routing Security Issues and Enhancements", RFC 4609,
			October 2006.
			[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
			Independent Multicast (PIM)", RFC 4610, August 2006.
	[RITVANEN]		[RITVANEN]
	Ritvanen, K., "Multicast Routing and Addressing", HUT		Ritvanen, K., "Multicast Routing and Addressing", HUT
	Report, Seminar on Internetworking, May 2004,		Report, Seminar on Internetworking, May 2004,
	<http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.		<http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.
	Appendix A. Multicast Payload Transport Extensions		Appendix A. Multicast Payload Transport Extensions
	A couple of mechanisms have been, and are being specified, to improve		A couple of mechanisms have been, and are being specified, to improve
	the characteristics of the data that can be transported over		the characteristics of the data that can be transported over
	multicast.		multicast.
	skipping to change at page 24, line 7		skipping to change at page 24, line 7
	Pekka Savola		Pekka Savola
	CSC - Scientific Computing Ltd.		CSC - Scientific Computing Ltd.
	Espoo		Espoo
	Finland		Finland
	Email: psavola@funet.fi		Email: psavola@funet.fi
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2006).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes. 38 change blocks.
	91 lines changed or deleted		116 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/