draft-ietf-mboned-embeddedrp-07.txt		rfc3956.txt
	mboned Working Group P. Savola		Network Working Group P. Savola
	Internet Draft CSC/FUNET		Request for Comments: 3956 CSC/FUNET
	Expiration Date: January 2005		Updates: 3306 B. Haberman
	B. Haberman		Category: Standards Track JHU APL
	Caspian Networks		November 2004
	July 2004
	Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
	draft-ietf-mboned-embeddedrp-07.txt		Embedding the Rendezvous Point (RP) Address
			in an IPv6 Multicast Address
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		This document specifies an Internet standards track protocol for the
	patent or other IPR claims of which I am aware have been disclosed,		Internet community, and requests discussion and suggestions for
	and any of which I become aware will be disclosed, in accordance with		improvements. Please refer to the current edition of the "Internet
	RFC 3668.		Official Protocol Standards" (STD 1) for the standardization state
			and status of this protocol. Distribution of this memo is unlimited.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at http://		Copyright Notice
	www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		Copyright (C) The Internet Society (2004).
	http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This memo defines an address allocation policy in which the address		This memo defines an address allocation policy in which the address
	of the Rendezvous Point (RP) is encoded in an IPv6 multicast group		of the Rendezvous Point (RP) is encoded in an IPv6 multicast group
	address. For Protocol Independent Multicast - Sparse Mode (PIM-SM),		address. For Protocol Independent Multicast - Sparse Mode (PIM-SM),
	this can be seen as a specification of a group-to-RP mapping		this can be seen as a specification of a group-to-RP mapping
	mechanism. This allows an easy deployment of scalable inter-domain		mechanism. This allows an easy deployment of scalable inter-domain
	multicast, and simplifies the intra-domain multicast configuration as		multicast and simplifies the intra-domain multicast configuration as
	well. This memo updates the addressing format presented in RFC 3306.		well. This memo updates the addressing format presented in RFC 3306.
	Table of Contents		Table of Contents
	1. Introduction ............................................... 2		1. Introduction ............................................... 2
	1.1. Background ............................................. 2		1.1. Background ............................................ 2
	1.2. Solution ............................................... 3		1.2. Solution ............................................. 2
	1.3. Assumptions and Scope .................................. 4		1.3. Assumptions and Scope ................................. 3
	1.4. Terminology ............................................ 4		1.4. Terminology .......................................... 4
	1.5. Abbreviations .......................................... 4		1.5. Abbreviations ........................................ 4
	2. Unicast-Prefix-based Address Format ........................ 5		2. Unicast-Prefix-based Address Format ........................ 4
	3. Modified Unicast-Prefix-based Address Format ............... 5		3. Modified Unicast-Prefix-based Address Format ............... 5
	4. Embedding the Address of the RP in the Multicast Address ... 6		4. Embedding the Address of the RP in the Multicast Address ... 5
	5. Examples ................................................... 7		5. Examples ................................................... 7
	5.1. Example 1 .............................................. 7		5.1. Example 1 ............................................ 7
	5.2. Example 2 .............................................. 7		5.2. Example 2 ............................................ 7
	5.3. Example 3 .............................................. 8		5.3. Example 3 ............................................ 8
	5.4. Example 4 .............................................. 8		5.4. Example 4 ............................................ 8
	6. Operational Considerations ................................. 9		6. Operational Considerations ................................. 8
	6.1. RP Redundancy .......................................... 9		6.1. RP Redundancy ......................................... 8
	6.2. RP Deployment .......................................... 9		6.2. RP Deployment ........................................ 9
	6.3. Guidelines for Assigning IPv6 Addresses to RPs ......... 9		6.3. Guidelines for Assigning IPv6 Addresses to RPs ........ 9
	6.4. Use as a Substitute for BSR ............................ 10		6.4. Use as a Substitute for BSR ........................... 9
	6.5. Controlling the Use of RPs ............................. 10		6.5. Controlling the Use of RPs ............................ 9
	7. The Embedded-RP Group-to-RP Mapping Mechanism .............. 11		7. The Embedded-RP Group-to-RP Mapping Mechanism .............. 10
	7.1. PIM-SM Group-to-RP Mapping ............................. 11		7.1. PIM-SM Group-to-RP Mapping ............................ 10
	7.2. Overview of the Model .................................. 11		7.2. Overview of the Model ................................. 11
	8. Scalability Analysis ....................................... 12		8. Scalability Analysis ....................................... 12
	9. Acknowledgements ........................................... 13		9. Acknowledgements ........................................... 13
	10. Security Considerations ................................... 14		10. Security Considerations ..................................... 13
	11. References ................................................ 15		11. References .................................................. 15
	11.1. Normative References .................................. 15		11.1. Normative References .................................. 15
	11.2. Informative References ................................ 15		11.2. Informative References ................................ 15
	Authors' Addresses ............................................. 16		A. Discussion about Design Tradeoffs ........................... 16
	A. Discussion about Design Tradeoffs .......................... 16		Authors' Addresses .............................................. 17
			Full Copyright Statement ......................................... 18
	1. Introduction		1. Introduction
	1.1. Background		1.1. Background
	As has been noticed [V6MISSUES], there exists a deployment problem		As has been noticed [V6MISSUES], there exists a deployment problem
	with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs have no		with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs have no
	way of communicating the information about (active) multicast sources		way of communicating the information about (active) multicast sources
	to other multicast domains, as Multicast Source Discovery Protocol		to other multicast domains, as Multicast Source Discovery Protocol
	(MSDP) [MSDP] has not been, on purpose, specified for IPv6.		(MSDP) [MSDP] has deliberately not been specified for IPv6.
	Therefore the whole interdomain Any Source Multicast (ASM) model is		Therefore the whole interdomain Any Source Multicast (ASM) model is
	rendered unusable; Source-Specific Multicast (SSM) [SSM] avoids these		rendered unusable; Source-Specific Multicast (SSM) [SSM] avoids these
	problems but is not a complete solution for several reasons, as noted		problems but is not a complete solution for several reasons, as noted
	below.		below.
	Further, it has been noted that there are some problems with the		Further, it has been noted that there are some problems with the
	support and deployment of mechanisms SSM would require [V6MISSUES]:		support and deployment of mechanisms SSM would require [V6MISSUES]:
	it seems unlikely that SSM could be usable as the only interdomain		it seems unlikely that SSM could be usable as the only interdomain
	multicast routing mechanism in the short term.		multicast routing mechanism in the short term.
	1.2. Solution		1.2. Solution
	This memo describes a multicast address allocation policy in which		This memo describes a multicast address allocation policy in which
	the address of the RP is encoded in the IPv6 multicast group address,		the address of the RP is encoded in the IPv6 multicast group address,
	and specifies a PIM-SM group-to-RP mapping to use the encoding,		and specifies a PIM-SM group-to-RP mapping to use the encoding,
	leveraging and extending unicast-prefix -based addressing [RFC3306].		leveraging, and extending unicast-prefix-based addressing [RFC3306].
	This mechanism not only provides a simple solution for IPv6		This mechanism not only provides a simple solution for IPv6
	interdomain Any Source Multicast but can be used as a simple solution		interdomain Any Source Multicast but can be used as a simple solution
	for IPv6 intradomain ASM with scoped multicast addresses as well. It		for IPv6 intra-domain ASM with scoped multicast addresses as well.
	can also be used as an automatic RP discovery mechanism in those
	deployment scenarios which would have previously used the Bootstrap		It can also be used as an automatic RP discovery mechanism in those
			deployment scenarios that would have previously used the Bootstrap
	Router protocol (BSR) [BSR].		Router protocol (BSR) [BSR].
	The solution consists of three elements:		The solution consists of three elements:
	o A specification of a subrange of [RFC3306] IPv6 multicast group		o A specification of a subrange of [RFC3306] IPv6 multicast group
	addresses defined by setting one previously unused bit of the		addresses defined by setting one previously unused bit of the
	Flags field to "1",		Flags field to "1",
	o A specification of the mapping by which such a group address		o a specification of the mapping by which such a group address
	encodes the RP address that is to be used with this group, and		encodes the RP address that is to be used with this group, and
	o A description of operational procedures to operate ASM with PIM-		o a description of operational procedures to operate ASM with PIM-SM
	SM on these IPv6 multicast groups.		on these IPv6 multicast groups.
	Addresses in the subrange will be called embedded-RP addresses.		Addresses in the subrange will be called embedded-RP addresses.
	This scheme obviates the need for MSDP, and the routers are not		This scheme obviates the need for MSDP, and the routers are not
	required to include any multicast configuration, except when they act		required to include any multicast configuration, except when they act
	as an RP.		as an RP.
	This memo updates the addressing format presented in RFC 3306.		This memo updates the addressing format presented in RFC 3306.
	Some design tradeoffs are discussed in Appendix A.		Some design tradeoffs are discussed in Appendix A.
	1.3. Assumptions and Scope		1.3. Assumptions and Scope
	A 128-bit RP address can't be embedded into a 128-bit group address		A 128-bit RP address can't be embedded into a 128-bit group address
	with space left to carry the group identity itself. An appropriate		with space left to carry the group identity itself. An appropriate
	form of encoding is thus defined by requiring that the Interface-IDs		form of encoding is thus defined by requiring that the Interface-IDs
	of RPs in the embedded-RP range can be assigned to be a specific		of RPs in the embedded-RP range can be assigned to be a specific
	value.		value.
	If these assumptions can't be followed, either operational procedures		If these assumptions can't be followed, operational procedures and
	and configuration must be slightly changed or this mechanism can not		configuration must be slightly changed, or this mechanism can't be
	be used.		used.
	The assignment of multicast addresses is outside the scope of this		The assignment of multicast addresses is outside the scope of this
	document; it is up to the RP and applications to ensure that group		document; it is up to the RP and applications to ensure that group
	addresses are unique using some unspecified method. However, the		addresses are unique by using some unspecified method. However, the
	mechanisms are very probably similar to ones used with [RFC3306].		mechanisms are probably similar to those used with [RFC3306].
	Similarly, RP failure management methods, such as Anycast-RP, are out		Similarly, RP failure management methods, such as Anycast-RP, are out
	of scope for this document. These do not work without additional		of scope for this document. These do not work without additional
	specification or deployment. This is covered briefly in Section 6.1.		specification or deployment. This is covered briefly in Section 6.1.
	1.4. Terminology		1.4. Terminology
	Embedded-RP behaves as if all the members of the group were all		Embedded-RP behaves as if all the members of the group were intra-
	intra-domain to the information distribution. However, as it gives a		domain to the information distribution. However, as it gives a
	solution for the global IPv6 multicast Internet, spanning multiple		solution for the global IPv6 multicast Internet, spanning multiple
	administrative domains, we say it is a solution for inter-domain		administrative domains, we say it is a solution for inter-domain
	multicast.		multicast.
	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
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1.5. Abbreviations		1.5. Abbreviations
	skipping to change at page 4, line 52		skipping to change at page 4, line 31
	DR Designated Router		DR Designated Router
	IGP Interior Gateway Protocol		IGP Interior Gateway Protocol
	MLD Multicast Listener Discovery		MLD Multicast Listener Discovery
	MSDP Multicast Source Discovery Protocol		MSDP Multicast Source Discovery Protocol
	PIM Protocol Independent Multicast		PIM Protocol Independent Multicast
	PIM-SM Protocol Independent Multicast - Sparse Mode		PIM-SM Protocol Independent Multicast - Sparse Mode
	RIID RP Interface ID (as specified in this memo)		RIID RP Interface ID (as specified in this memo)
	RP Rendezvous Point		RP Rendezvous Point
	RPF Reverse Path Forwarding		RPF Reverse Path Forwarding
	SPT Shortest Path Tree		SPT Shortest Path Tree
	SSM Source-specific Multicast		SSM Source-Specific Multicast
	2. Unicast-Prefix-based Address Format		2. Unicast-Prefix-based Address Format
	As described in [RFC3306], the multicast address format is as		As described in [RFC3306], the multicast address format is as
	follows:		follows:
	| 8 | 4 | 4 | 8 | 8 | 64 | 32 |		| 8 | 4 | 4 | 8 | 8 | 64 | 32 |
	+--------+----+----+--------+----+----------------+----------+		+--------+----+----+--------+----+----------------+----------+
	|11111111|flgs|scop|reserved|plen| network prefix | group ID |		|11111111|flgs|scop|reserved|plen| network prefix | group ID |
	+--------+----+----+--------+----+----------------+----------+		+--------+----+----+--------+----+----------------+----------+
	Where flgs are "0011". (The first two bits have been yet undefined,		Where flgs are "0011". (The first two bits are as yet undefined,
	sent as zero and ignored on receipt.)		sent as zero and ignored on receipt.)
	3. Modified Unicast-Prefix-based Address Format		3. Modified Unicast-Prefix-based Address Format
	This memo specifies a modification to the unicast-prefix-based		This memo specifies a modification to the unicast-prefix-based
	address format by specifying the second high-order bit ("R-bit") as		address format by specifying the second high-order bit ("R-bit") as
	follows:		follows:
	| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |		| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
	+--------+----+----+----+----+----+----------------+----------+		+--------+----+----+----+----+----+----------------+----------+
	|11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID |		|11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID |
	+--------+----+----+----+----+----+----------------+----------+		+--------+----+----+----+----+----+----------------+----------+
	+-+-+-+-+		+-+-+-+-+
	flgs is a set of 4 flags: |0|R|P|T|		flgs is a set of four flags: |0|R|P|T|
	+-+-+-+-+		+-+-+-+-+
	R = 1 indicates a multicast address that embeds the address on the		When the highest-order bit is 0, R = 1 indicates a multicast address
	RP. Then P MUST be set to 1, and consequently T MUST be set to 1, as		that embeds the address on the RP. Then P MUST be set to 1, and
	specified in [RFC3306]. In effect, this implies the prefix		consequently T MUST be set to 1, as specified in [RFC3306]. In
	FF70::/12.		effect, this implies the prefix FF70::/12. In this case, the last 4
			bits of the previously reserved field are interpreted as embedding
			the RP interface ID, as specified in this memo.
	The behavior is unspecified if P or T is not set to 1, as then the		The behavior is unspecified if P or T is not set to 1, as then the
	prefix would not be FF70::/12. Likewise, encoding and the protocol		prefix would not be FF70::/12. Likewise, the encoding and the
	mode used when the two high-order bit in "flgs" are set to 11		protocol mode used when the two high-order bits in "flgs" are set to
	("FFF0::/12") is intentionally unspecified until such time that the		11 ("FFF0::/12") is intentionally unspecified until such time that
	highest-order bit is defined.		the highest-order bit is defined. Without further IETF
			specification, implementations SHOULD NOT treat the FFF0::/12 range
	In the case that R = 1, the last 4 bits of the previously reserved		as Embedded-RP.
	field are interpreted as embedding the RP interface ID, as specified
	in this memo.
	R = 0 indicates a multicast address that does not embed the address		R = 0 indicates a multicast address that does not embed the address
	of the RP and follows the semantics defined in [ADDRARCH] and		of the RP and follows the semantics defined in [ADDRARCH] and
	[RFC3306]. In this context, the value of "RIID" MUST be sent as zero		[RFC3306]. In this context, the value of "RIID" MUST be sent as zero
	and MUST be ignored on receipt.		and MUST be ignored on receipt.
	4. Embedding the Address of the RP in the Multicast Address		4. Embedding the Address of the RP in the Multicast Address
	The address of the RP can only be embedded in unicast-prefix -based		The address of the RP can only be embedded in unicast-prefix -based
	ASM addresses.		ASM addresses.
	That is, to identify whether an address is a multicast address as		That is, to identify whether it is a multicast address as specified
	specified in this memo and to be processed any further, it must		in this memo and to be processed any further, an address must satisfy
	satisfy all of the below:		all of the following:
	o it MUST be a multicast address and have R, P, and T flag bits set
	to 1 -- that is, be part of the prefix FF70::/12 (note that
	FFF0::/12 is yet unspecified),
	o "plen" MUST NOT be 0 (ie. not SSM), and		o It MUST be a multicast address with "flgs" set to 0111, that is, to
			be of the prefix FF70::/12,
			o "plen" MUST NOT be 0 (i.e., not SSM), and
	o "plen" MUST NOT be greater than 64.		o "plen" MUST NOT be greater than 64.
	The address of the RP can be obtained from a multicast address		The address of the RP can be obtained from a multicast address
	satisfying the above criteria by taking the two steps:		satisfying the above criteria by taking the following two steps:
	1. copy the first "plen" bits of the "network prefix" to a zeroed		1. Copy the first "plen" bits of the "network prefix" to a zeroed
	128-bit address structure, and		128-bit address structure, and
	2. replace the last 4 bits with the contents of "RIID".		2. replace the last 4 bits with the contents of "RIID".
	These two steps could be illustrated as follows:		These two steps could be illustrated as follows:
	| 20 bits | 4 | 8 | 64 | 32 |		| 20 bits | 4 | 8 | 64 | 32 |
	+---------+----+----+----------------+----------+		+---------+----+----+----------------+----------+
	|xtra bits|RIID|plen| network prefix | group ID |		|xtra bits|RIID|plen| network prefix | group ID |
	+---------+----+----+----------------+----------+		+---------+----+----+----------------+----------+
	|| \\ vvvvvvvvvvv		|| \\ vvvvvvvvvvv
	|| ``====> copy plen bits of "network prefix"		|| ``====> copy plen bits of "network prefix"
	skipping to change at page 6, line 47		skipping to change at page 6, line 32
	|| +------------+--------------------------+		|| +------------+--------------------------+
	|| | network pre| 0000000000000000000000 |		|| | network pre| 0000000000000000000000 |
	|| +------------+--------------------------+		|| +------------+--------------------------+
	\\		\\
	``=================> copy RIID to the last 4 bits		``=================> copy RIID to the last 4 bits
	+------------+---------------------+----+		+------------+---------------------+----+
	| network pre| 0000000000000000000 |RIID|		| network pre| 0000000000000000000 |RIID|
	+------------+---------------------+----+		+------------+---------------------+----+
	One should note that there are several operational scenarios (see		One should note that there are several operational scenarios (see
	Example 3 below) when [RFC3306] statement "all non-significant bits		Example 3 below) when the [RFC3306] statement "all non-significant
	of the network prefix field SHOULD be zero" is ignored. This is to		bits of the network prefix field SHOULD be zero" is ignored. This is
	allow multicast group address allocations to be consistent with		to allow multicast group address allocations to be consistent with
	unicast prefixes, while the multicast addresses would still use the		unicast prefixes; the multicast addresses would still use the RP
	RP associated with the network prefix.		associated with the network prefix.
	"plen" higher than 64 MUST NOT be used as that would overlap with the		"plen" higher than 64 MUST NOT be used, as that would overlap with
	high-order bits of multicast group-id.		the high-order bits of multicast group-id.
	When processing an encoding to get the RP address, the multicast		When processing an encoding to get the RP address, the multicast
	routers MUST perform at least the same address validity checks to the		routers MUST perform at least the same address validity checks to the
	calculated RP address as to one received via other means (like BSR		calculated RP address as to one received via other means (like BSR
	[BSR] or MSDP for IPv4). At least fe80::/10, ::/16, and ff00::/8		[BSR] or MSDP for IPv4). At least fe80::/10, ::/16, and ff00::/8
	MUST be excluded. This is particularly important as the information		MUST be excluded. This is particularly important, as the information
	is obtained from an untrusted source, i.e., any Internet user's		is obtained from an untrusted source, i.e., any Internet user's
	input.		input.
	One should note that the 4 bits reserved for "RIID" set the upper		One should note that the 4 bits reserved for "RIID" set the upper
	bound for RPs for the combination of scope, network prefix, and group		bound for RPs for the combination of scope, network prefix, and group
	ID -- without varying any of these, you can 2^4-1 = 15 different RPs		ID -- without varying any of these, one can have 2^4-1 = 15 different
	(as RIID=0 is reserved, see section 6.3). However, each of these is		RPs (as RIID=0 is reserved, see section 6.3). However, each of these
	an IPv6 group address of its own (i.e., there can be only one RP per		is an IPv6 group address of its own (i.e., there can be only one RP
	multicast address).		per multicast address).
	5. Examples		5. Examples
	Four examples of multicast address allocation and resulting group-to-		Four examples of multicast address allocation and resulting group-
	RP mappings are described here, to better illustrate the		to-RP mappings are described here to better illustrate the
	possibilities provided by the encoding.		possibilities provided by the encoding.
	5.1. Example 1		5.1. Example 1
	The network administrator of 2001:DB8::/32 wants to set up an RP for		The network administrator of 2001:DB8::/32 wants to set up an RP for
	the network and all the customers, by placing it on an existing		the network and all the customers, by placing it on an existing
	subnet, e.g., 2001:DB8:BEEF:FEED::/64.		subnet, e.g., 2001:DB8:BEEF:FEED::/64.
	In that case, the group addresses would be something like		In that case, the group addresses would be something like
	"FF7x:y40:2001:DB8:BEEF:FEED::/96", and then their RP address would		"FF7x:y40:2001:DB8:BEEF:FEED::/96", and then their RP address would
	be "2001:DB8:BEEF:FEED::y". There are still 32 bits of multicast		be "2001:DB8:BEEF:FEED::y". There are still 32 bits of multicast
	group-id's to assign to customers and self ("y" could be anything		group-ids to assign to customers and self ("y" could be anything from
	from 1 to F, as 0 must not be used).		1 to F, as 0 must not be used).
	5.2. Example 2		5.2. Example 2
	As in Example 1, the network administrator of 2001:DB8::/32 wants to		As in Example 1, the network administrator of 2001:DB8::/32 wants to
	set up the RP, but to make it more flexible, wants to place it on a		set up the RP but, to make it more flexible, wants to place it on a
	specifically routed subnet, and wants to keep larger address space		specifically routed subnet and wants to keep larger address space for
	for group allocations. That is, the administrator selects the least		group allocations. That is, the administrator selects the least
	specific part of the unicast prefix, with plen=32, and the group		specific part of the unicast prefix, with plen=32, and the group
	addresses will be from the multicast prefix:		addresses will be from the multicast prefix:
	FF7x:y20:2001:DB8::/64		FF7x:y20:2001:DB8::/64
	Where "x" is the multicast scope, "y" the interface ID of the RP		where "x" is the multicast scope, "y" is the interface ID of the RP
	address, and there are 64 bits for group-id's or assignments. In		address, and there are 64 bits for group-ids or assignments. In this
	this case, the address of the RP would be:		case, the address of the RP would be:
	2001:DB8::y		2001:DB8::y
	The address 2001:DB8::y/128 is assigned to a router as a loopback		The address 2001:DB8::y/128 is assigned to a router as a loopback
	address and injected to the routing system; if the network		address and is injected into the routing system; if the network
	administrator sets up only one or a couple of RPs (and e.g., not one		administrator sets up only one or two RPs (and, e.g., not one RP per
	RP per subnet), this approach may be preferable to the one described		subnet), this approach may be preferable to the one described in
	in Example 1.		Example 1.
	5.3. Example 3		5.3. Example 3
	As in Example 2, the network administrator can also assign multicast		As in Example 2, the network administrator can also assign multicast
	prefixes like "FF7x:y20:2001:DB8:DEAD::/80" to some of customers. In		prefixes such as "FF7x:y20:2001:DB8:DEAD::/80" to some of customers.
	this case the RP address would still be "2001:DB8::y". (Note that		In this case the RP address would still be "2001:DB8::y". (Note that
	this is just a more specific subcase of Example 2, where the		this is just a more specific subcase of Example 2, where the
	administrator assigns a multicast prefix, not just invidial group-		administrator assigns a multicast prefix, not just individual group-
	id's.)		ids.)
	Note the second rule of deriving the RP address: the "plen" field in		Note the second rule of deriving the RP address: the "plen" field in
	the multicast address, 0x20 = 32, refers to the length of "network		the multicast address, 0x20 = 32, refers to the length of "network
	prefix" field considered when obtaining the RP address. In this		prefix" field considered when obtaining the RP address. In this
	case, only the first 32 bits of the network prefix field, "2001:DB8"		case, only the first 32 bits of the network prefix field, "2001:DB8",
	are preserved: the value of "plen" takes no stance on actual		are preserved: the value of "plen" takes no stance on actual
	unicast/multicast prefix lengths allocated or used in the networks,		unicast/multicast prefix lengths allocated or used in the networks,
	here from 2001:DB8:DEAD::/48.		here from 2001:DB8:DEAD::/48.
	In short, this distinction allows more flexible RP address		In short, this distinction allows more flexible RP address
	configuration in the scenarios where it is desirable to have the		configuration in the scenarios where it is desirable to have the
	group addresses to be consistent with the unicast prefix allocations.		group addresses be consistent with the unicast prefix allocations.
	5.4. Example 4		5.4. Example 4
	In the network of Examples 1, 2 and 3, the network admin sets up		In the network of Examples 1, 2, and 3, the network admin sets up
	addresses for use by their customers, but an organization wants to		addresses for use by customers, but an organization wants to have its
	have their own PIM-SM domain. The organization can pick multicast		own PIM-SM domain. The organization can pick multicast addresses
	addresses like "FF7x:y30:2001:DB8:BEEF::/80", and then their RP		such as "FF7x:y30:2001:DB8:BEEF::/80", and then the RP address would
	address would be "2001:DB8:BEEF::y".		be "2001:DB8:BEEF::y".
	6. Operational Considerations		6. Operational Considerations
	This section describes the major operational considerations for those		This section describes the major operational considerations for those
	deploying this mechanism.		deploying this mechanism.
	6.1. RP Redundancy		6.1. RP Redundancy
	A technique called "Anycast RP" is used within a PIM-SM domain to		A technique called "Anycast RP" is used within a PIM-SM domain to
	share an address and multicast state information between a set of		share an address and multicast state information between a set of RPs
	RP's mainly for redundancy purposes. Typically, MSDP has been used		mainly for redundancy purposes. Typically, MSDP has been used for
	for that as well [ANYCASTRP]. There are also other approaches, like		this as well [ANYCASTRP]. There are also other approaches, such as
	using PIM for sharing this information [ANYPIMRP].		using PIM for sharing this information [ANYPIMRP].
	The most feasible candidate for RP failover is using PIM for Anycast		The most feasible candidate for RP failover is using PIM for Anycast
	RP or "anycasting" (i.e., the shared-unicast model [ANYCAST]) the RP		RP or "anycasting" (i.e., the shared-unicast model [ANYCAST]) the RP
	address in the Interior Gateway Protocol (IGP) without state sharing		address in the Interior Gateway Protocol (IGP) without state sharing
	(depending on the redundancy requirements, this may or may not be		(although depending on the redundancy requirements, this may or may
	enough, though). However, the redundancy mechanisms are outside of		not be enough). However, the redundancy mechanisms are outside of
	the scope of this memo.		the scope of this memo.
	6.2. RP Deployment		6.2. RP Deployment
	As there is no need to share inter-domain state with MSDP, each		As there is no need to share inter-domain state with MSDP, each
	Designated Router connecting multicast sources could act as an RP		Designated Router connecting multicast sources could act as an RP
	without scalability concerns about setting up and maintaining MSDP		without scalability concerns about setting up and maintaining MSDP
	sessions.		sessions.
	This might be particularly attractive when concerned about RP		This might be particularly attractive when one is concerned about RP
	redundancy. In the case where the DR close to a major source for a		redundancy. In the case where the DR close to a major source for a
	group acts as the RP, a certain amount of fate-sharing properties can		group acts as the RP, a certain amount of fate-sharing properties can
	be obtained without using any RP failover mechanisms: if the DR goes		be obtained without using any RP failover mechanisms: if the DR goes
	down, the multicast transmission may not work anymore in any case.		down, the multicast transmission may not work anymore in any case.
	Along the same lines, it's may also be desirable to distribute the RP		Along the same lines, its may also be desirable to distribute the RP
	responsibilities to multiple RPs. As long as different RPs serve		responsibilities to multiple RPs. As long as different RPs serve
	different groups, this is trivial: each group could map to a		different groups, this is trivial: each group could map to a
	different RP (or sufficiently many different RPs that the load on one		different RP (or sufficiently many different RPs that the load on one
	RP is not a problem). However, load sharing one group faces the		RP is not a problem). However, load sharing challenges one group
	similar challenges as Anycast-RP.		faces are similar to those of Anycast-RP.
	6.3. Guidelines for Assigning IPv6 Addresses to RPs		6.3. Guidelines for Assigning IPv6 Addresses to RPs
	With this mechanism, the RP can be given basically any unicast		With this mechanism, the RP can be given basically any unicast
	network prefix up to /64. The interface identifier will have to be		network prefix up to /64. The interface identifier will have to be
	manually configured to match "RIID".		manually configured to match "RIID".
	RIID = 0 must not be used as using it would cause ambiguity with the		RIID = 0 must not be used, as using it would cause ambiguity with the
	Subnet-Router Anycast Address [ADDRARCH].		Subnet-Router Anycast Address [ADDRARCH].
	If an administrator wishes to use an RP address that does not conform		If an administrator wishes to use an RP address that does not conform
	to the addressing topology but is still from the network provider's		to the addressing topology but is still from the network provider's
	unicast prefix (e.g., an additional loopback address assigned on a		unicast prefix (e.g., an additional loopback address assigned on a
	router, as described in example 2 in Section 5.1), that address can		router, as described in Example 2 in Section 5.1), that address can
	be injected into the routing system via a host route.		be injected into the routing system via a host route.
	6.4. Use as a Substitute for BSR		6.4. Use as a Substitute for BSR
	With embedded-RP, use of BSR or other RP configuration mechanisms		With embedded-RP, use of BSR or other RP configuration mechanisms
	throughout the PIM domain is not necessary, as each group address		throughout the PIM domain is not necessary, as each group address
	specifies the RP to be used.		specifies the RP to be used.
	6.5. Controlling the Use of RPs		6.5. Controlling the Use of RPs
	Compared to the MSDP inter-domain ASM model, the control and		Compared to the MSDP inter-domain ASM model, the control and
	management of who can use an RP and how changes slightly and deserves		management of who can use an RP, and how, changes slightly and
	explicit discussion.		deserves explicit discussion.
	MSDP advertisement filtering typically includes at least two		MSDP advertisement filtering typically includes at least two
	capabilities: being able to filter who is able to create a global		capabilities: filtering who is able to create a global session
	session ("source filtering"), and being able to filter which groups		("source filtering") and filtering which groups should be globally
	should be globally accessible ("group filtering"). These are done to		accessible ("group filtering"). These are done to prevent local
	prevent local groups from being advertised to the outside, or		groups from being advertised to the outside or unauthorized senders
	preventing unauthorized senders from creating global groups.		from creating global groups.
	However, such controls do not yet block the outsiders from using such		However, such controls do not yet block the outsiders from using such
	groups, as they could join the groups even without Source Active		groups, as they could join the groups even without Source Active
	advertisement with a (Source, Group) or (S,G) Join by		advertisement with a (Source, Group) or (S,G) Join by
	guessing/learning the source and/or the group address. For proper		guessing/learning the source and/or the group address. For proper
	protection, one should set up, e.g., PIM multicast scoping borders at		protection, one should set up, for example, PIM multicast scoping
	the border routers. Therefore, embedded-RP has by default roughtly		borders at the border routers. Therefore, embedded-RP has by default
	equivalent level of "protection" as MSDP with SA filtering.		a roughly equivalent level of "protection" as MSDP with SA filtering.
	A new issue with control comes from the fact that nodes in a "foreign		A new issue with control is that nodes in a "foreign domain" may
	domain" may register to an RP, or send PIM Join to an RP. (These have		register to an RP, or send PIM Join to an RP. (These have been
	been possible in the past as well, to a degree, but only through		possible in the past as well, to a degree, but only through willful
	willfull attempts or purposeful RP configuration at DRs.) The main		attempts or purposeful RP configuration at DRs.) The main threat in
	threat in this case is that an outsider illegitimately uses the RP to		this case is that an outsider may illegitimately use the RP to host
	host his/hers own group(s). This can be mitigated to an extent by		his/hers own group(s). This can be mitigated to an extent by
	filtering which groups or group ranges are allowed at the RP; more		filtering which groups or group ranges are allowed at the RP; more
	specific controls are beyond the scope of this memo. Note that this		specific controls are beyond the scope of this memo. Note that this
	does not seem to be a serious threat in the first place as anyone		does not seem to be a serious threat in the first place, as anyone
	with a /64 unicast prefix can create an own RP, without having to		with a /64 unicast prefix can create their own RP without having to
	illegitimately get it from someone else.		illegitimately get it from someone else.
	7. The Embedded-RP Group-to-RP Mapping Mechanism		7. The Embedded-RP Group-to-RP Mapping Mechanism
	This section specifies the group-to-RP mapping mechanism for Embedded		This section specifies the group-to-RP mapping mechanism for Embedded
	RP.		RP.
	7.1. PIM-SM Group-to-RP Mapping		7.1. PIM-SM Group-to-RP Mapping
	The only PIM-SM modification required is implementing this mechanism		The only PIM-SM modification required is implementing this mechanism
	as one group-to-RP mapping method.		as one group-to-RP mapping method.
	The implementation will have to recognize the address format and		The implementation will have to recognize the address format and
	derive and use the RP address using the rules in Section 4. This		derive and use the RP address by using the rules in Section 4. This
	information is used at least when performing Reverse Path Forwarding		information is used at least when performing Reverse Path Forwarding
	(RPF) lookups, when processing Join/Prune messages, or performing		(RPF) lookups, when processing Join/Prune messages, or performing
	Register-encapsulation.		Register-encapsulation.
	To avoid loops and inconsistancies, for addresses in the range		To avoid loops and inconsistencies, for addresses in the range
	FF70::/12, the Embedded-RP mapping MUST be considered to be the		FF70::/12, the Embedded-RP mapping MUST be considered the longest
	longest possible match and higher priority than any other mechanism.		possible match and higher priority than any other mechanism.
	It is worth noting that compared to the other group-to-RP mapping		It is worth noting that compared to the other group-to-RP mapping
	mechanisms, which can be precomputed, the embedded-RP mapping must be		mechanisms, which can be precomputed, the embedded-RP mapping must be
	redone for every new IPv6 group address which would map to a		redone for every new IPv6 group address that would map to a different
	different RP. For efficiency, the results may be cached in an		RP. For efficiency, the results may be cached in an implementation-
	implementation-specific manner, to avoid computation for every		specific manner, to avoid computation for every embedded-RP packet.
	embedded-RP packet.
	This group-to-RP mapping mechanism must be supported by the RP, the		This group-to-RP mapping mechanism must be supported by the RP, the
	DR adjacent to the senders and any router on the path from any		DR adjacent to the senders, and any router on the path from any
	receiver to the RP. Paths for Shortest Path Tree (SPT) formation and		receiver to the RP. Paths for Shortest Path Tree (SPT) formation and
	Register-Stop do not require the support, as those are accomplished		Register-Stop do not require the support, as those are accomplished
	with an (S,G) Join.		with an (S,G) Join.
	7.2. Overview of the Model		7.2. Overview of the Model
	This section gives a high-level, non-normative overview of how		This section gives a high-level, non-normative overview of how
	Embedded RP operates, as specified in the previous section.		Embedded RP operates, as specified in the previous section.
	The steps when a receiver wishes to join a group are:		The steps when a receiver wishes to join a group are as follows:
			1. A receiver finds out a group address by some means (e.g., SDR or a
			web page).
			2. The receiver issues an Multicast Listener Discovery (MLD) Report,
			joining the group.
	1. A receiver finds out a group address from some means (e.g., SDR
	or a web page).
	2. The receiver issues an Mulicast Listener Discovery (MLD)
	Report, joining the group.
	3. The receiver's DR will initiate the PIM-SM Join process towards		3. The receiver's DR will initiate the PIM-SM Join process towards
	the RP encoded in the multicast address, irrespective of		the RP encoded in the multicast address, irrespective of whether
	whether it is in the "local" or "remote" PIM domain.		it is in the "local" or "remote" PIM domain.
	The steps when a sender wishes to send to a group are:		The steps when a sender wishes to send to a group are as follows:
	1. A sender finds out a group address using an unspecified method		1. A sender finds out a group address by using an unspecified method
	(e.g, by contacting the administrator for group assignment or		(e.g., by contacting the administrator for group assignment or
	using a multicast address assignment protocol).		using a multicast address assignment protocol).
	2. The sender sends to the group.		2. The sender sends to the group.
	3. The sender's DR will send the packets unicast-encapsulated in		3. The sender's DR will send the packets unicast-encapsulated in
	PIM-SM Register-messages to the RP address encoded in the		PIM-SM Register-messages to the RP address encoded in the
	multicast address (in the special case that DR is the RP, such		multicast address (in the special case that DR is the RP, such
	sending is only conceptual).		sending is only conceptual).
	In fact, all the messages go as specified in [PIM-SM] -- embedded-RP		In fact, all the messages go as specified in [PIM-SM]; embedded-RP
	just acts as a group-to-RP mapping mechanism; instead of obtaining		just acts as a group-to-RP mapping mechanism. Instead of obtaining
	the address of the RP from local configuration or configuration		the address of the RP from local configuration or configuration
	protocols (e.g., BSR), it is derived transparently from the encoded		protocols (e.g., BSR), the algorithm derives it transparently from
	multicast address.		the encoded multicast address.
	8. Scalability Analysis		8. Scalability Analysis
	Interdomain MSDP model for connecting PIM-SM domains is mostly		Interdomain MSDP model for connecting PIM-SM domains is mostly
	hierarchical in configuration and deployment, but flat with regard to		hierarchical in configuration and deployment, but flat with regard to
	information distribution. The embedded-RP inter-domain model behaves		information distribution. The embedded-RP inter-domain model behaves
	as if every group formed its own Internet-wide PIM domain, with the		as if every group formed its own Internet-wide PIM domain, with the
	group mapping to a single RP, wherever the receivers or senders are.		group mapping to a single RP, wherever the receivers or senders are
	So, the inter-domain multicast becomes a flat, RP-centered topology.		located. Hence, the inter-domain multicast becomes a flat, RP-
	The scaling issues are described below.		centered topology. The scaling issues are described below.
	Previously foreign sources sent the unicast-encapsulated data to		Previously, foreign sources sent the unicast-encapsulated data to
	their "local" RP, now they do so to the "foreign" RP responsible for		their "local" RP; now they are sent to the "foreign" RP responsible
	the specific group. This is especially important with large		for the specific group. This is especially important with large
	multicast groups where there are a lot of heavy senders --		multicast groups where there are a lot of heavy senders --
	particularly if implementations do not handle unicast-decapsulation		particularly if implementations do not handle unicast-decapsulation
	well.		well.
	With IPv4 ASM multicast, there is roughly two kinds of Internet-wide		With IPv4 ASM multicast, there are roughly two kinds of Internet-wide
	state: MSDP (propagated everywhere), and multicast routing state (on		state: MSDP (propagated everywhere), and multicast routing state (on
	the receiver or sender branches). The former is eliminated, but the		the receiver or sender branches). The former is eliminated, but the
	backbone routers might end up with (*, G) and (S, G, rpt) state		backbone routers might end up with (*, G) and (S, G, rpt) state
	between receivers (and past receivers, for PIM Prunes) and the RP, in		between receivers (and past receivers, for PIM Prunes) and the RP, in
	addition to (S, G) states between the receivers and senders, if SPT		addition to (S, G) states between the receivers and senders, if SPT
	is used. However, the total amount of state is smaller.		is used. However, the total amount of state is smaller.
	The embedded-RP model is practically identical in both inter-domain		In both inter-domain and intra-domain cases, the embedded-RP model is
	and intra-domain cases to the traditional PIM-SM in intra-domain. On		practically identical to the traditional PIM-SM in intra-domain. On
	the other hand, PIM-SM has been deployed (in IPv4) in inter-domain		the other hand, PIM-SM has been deployed (in IPv4) in inter-domain
	using MSDP; compared to that inter-domain model, this specification		using MSDP; compared to that inter-domain model, this specification
	simplifies the tree construction (i.e., multicast routing) by		simplifies the tree construction (i.e., multicast routing) by
	removing the RP for senders and receivers in foreign domains, and		removing the RP for senders and receivers in foreign domains and
	eliminating the MSDP information distribution.		eliminating the MSDP information distribution.
	As the address of the RP is tied to the multicast address, the RP		As the address of the RP is tied to the multicast address, the RP
	failure management becomes more difficult, as the deployed failover		failure management becomes more difficult, as the deployed failover
	or redundancy mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot be		or redundancy mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot be
	used as-is. However, Anycast-RP using PIM provides equal redundancy;		used as-is. However, Anycast-RP using PIM provides equal redundancy;
	this described briefly in Section 6.1.		this described briefly in Section 6.1.
	The PIM-SM specification states, "Any RP address configured or		The PIM-SM specification states, "Any RP address configured or
	learned MUST be a domain-wide reachable address". What "reachable"		learned MUST be a domain-wide reachable address". What "reachable"
	precisely means is not clear, even without embedded-RP. This		precisely means is not clear, even without embedded-RP. This
	statement cannot be proven especially with the foreign RPs as one can		statement cannot be proven, especially with the foreign RPs, as one
	not even guarantee that the RP exists. Instead of manually		cannot even guarantee that the RP exists. Instead of manually
	configuring RPs and DRs (configuring a non-existent RP was possible		configuring RPs and DRs (configuring a non-existent RP was possible,
	though rare), with this specification the hosts and users using		though rare), with this specification the hosts and users using
	multicast indirectly specify the RP themselves, lowering the		multicast indirectly specify the RP themselves, lowering the
	expectancy of the RP reachability. This is a relatively significant		expectancy of the RP reachability. This is a relatively significant
	problem but not much different from the current multicast deployment:		problem but not much different from the current multicast deployment:
	e.g., MLDv2 (S,G) joins, whether ASM or SSM, yield the same result		e.g., MLDv2 (S,G) joins, whether ASM or SSM, yield the same result
	[PIMSEC].		[PIMSEC].
	Being able to join/send to remote RPs raises security concerns that		Being able to join/send to remote RPs raises security concerns that
	are considered separately, but it has an advantage too: every group		are considered separately, but it has an advantage too: every group
	has a "responsible RP" which is able to control (to some extent) who		has a "responsible RP" that is able to control (to some extent) who
	are able to send to the group.		is able to send to the group.
	A more extensive description and comparison of the inter-domain		A more extensive description and comparison of the inter-domain
	multicast routing models (traditional ASM with MSDP, embedded-RP,		multicast routing models (traditional ASM with MSDP, embedded-RP,
	SSM) and their security properties has been described in [PIMSEC].		SSM) and their security properties has been described in [PIMSEC].
	9. Acknowledgements		9. Acknowledgements
	Jerome Durand commented on an early draft of this memo. Marshall		Jerome Durand commented on an early version of this memo. Marshall
	Eubanks noted an issue regarding short plen values. Tom Pusateri		Eubanks noted an issue regarding short plen values. Tom Pusateri
	noted problems with an earlier SPT-join approach. Rami Lehtonen		noted problems with an earlier SPT-join approach. Rami Lehtonen
	pointed out issues with the scope of SA-state and provided extensive		pointed out issues with the scope of SA-state and provided extensive
	commentary. Nidhi Bhaskar gave the draft a thorough review.		commentary. Nidhi Bhaskar gave the document a thorough review.
	Toerless Eckert, Hugh Holbrook, and Dave Meyer provided very		Toerless Eckert, Hugh Holbrook, and Dave Meyer provided very
	extensive feedback. In particular, Pavlin Radoslavov, Dino		extensive feedback. In particular, Pavlin Radoslavov, Dino
	Farinacci, Nidhi Bhaskar, and Jerome Durand provided good comments		Farinacci, Nidhi Bhaskar, and Jerome Durand provided good comments
	during and after WG last call. Mark Allman, Bill Fenner, Thomas		during and after WG last call. Mark Allman, Bill Fenner, Thomas
	Narten, and Alex Zinin provided substantive comments during the IESG		Narten, and Alex Zinin provided substantive comments during the IESG
	evaluation. The whole MboneD working group is also acknowledged for		evaluation. The whole MboneD working group is also acknowledged for
	the continued support and comments.		continued support and comments.
	10. Security Considerations		10. Security Considerations
	The addresses of RPs are encoded in the multicast addresses -- and		The addresses of RPs are encoded in the multicast addresses, thus
	thus become more visible as single points of failure. Even though		becoming more visible as single points of failure. Even though this
	this does not significantly affect the multicast routing security, it		does not significantly affect the multicast routing security, it may
	may expose the RP to other kinds of attacks. The operators are		expose the RP to other kinds of attacks. The operators are
	encouraged to pay special attention to securing these routers. See		encouraged to pay special attention to securing these routers. See
	Section 6.1 on considerations regarding failover and Section 6.2 on		Section 6.1 for considerations regarding failover and Section 6.2 for
	placement of RPs leading to a degree of fate-sharing properties.		placement of RPs leading to a degree of fate-sharing properties.
	As any RP will have to accept PIM-SM Join/Prune/Register messages		As any RP will have to accept PIM-SM Join/Prune/Register messages
	from any DR, this might cause a potential Denial of Service attack		from any DR, this might cause a potential Denial of Service attack
	scenario. However, this can be mitigated by the fact that the RP can		scenario. However, this can be mitigated, as the RP can discard all
	discard all such messages for all multicast addresses that do not		such messages for all multicast addresses that do not encode the
	encode the address of the RP. Both the sender- and receiver-based		address of the RP. Both the sender- and receiver-based attacks are
	attacks are described at more length in [PIMSEC].		described at greater length in [PIMSEC].
	Additionally the implementation SHOULD also allow manual		Additionally, the implementation SHOULD also allow manual
	configuration of which multicast prefixes are allowed to be used.		configuration of which multicast prefixes are allowed to be used.
	This can be used to limit the use of the RP to designated groups		This can be used to limit the use of the RP to designated groups
	only. In some cases, it is desirable to be able to restrict (at the		only. In some cases, being able to restrict (at the RP) which
	RP) which unicast addresses are allowed to send or join to a group.		unicast addresses are allowed to send or join to a group is
	(However, note that Join/Prune messages would still leave state in		desirable. (However, note that Join/Prune messages would still leave
	the network, and Register messages can be spoofed [PIMSEC].)		state in the network, and Register messages can be spoofed [PIMSEC].)
	Obviously, these controls are only possible at the RP, not at the		Obviously, these controls are only possible at the RP, not at the
	intermediate routers or the DR.		intermediate routers or the DR.
	It is RECOMMENDED that routers supporting this specification do not		It is RECOMMENDED that routers supporting this specification do not
	act as RPs unless explicitly configured to do so; as becoming an RP		act as RPs unless explicitly configured to do so, as becoming an RP
	does not require any advertisement (e.g., through BSR or manually),		does not require any advertisement (e.g., through BSR or manually).
	otherwise any router could potentially become an RP (and be abused as		Otherwise, any router could potentially become an RP (and be abused
	such). Further, multicast groups or group ranges to-be-served MAY		as such). Further, multicast groups or group ranges to-be-served MAY
	need to be explicitly configured at the RPs, to protect from being		need to be explicitly configured at the RPs, to protect them from
	used unwillingly. Note that the more specific controls (e.g.,		being used unwillingly. Note that the more specific controls (e.g.,
	"insider-must-create" or "invite-outsiders" models) to who is allowed		"insider-must-create" or "invite-outsiders" models) as to who is
	to use the groups are beyond the scope of this memo.		allowed to use the groups are beyond the scope of this memo.
	Excluding internal-only groups from MSDP advertisements does not		Excluding internal-only groups from MSDP advertisements does not
	protect the groups from outsiders, only offers security by obscurity;		protect the groups from outsiders but only offers security by
	embedded-RP offers similar level of protection. When real protection		obscurity; embedded-RP offers similar level of protection. When real
	is desired, e.g., PIM scoping should be set up at the borders; this		protection is desired, PIM scoping for example, should be set up at
	is described at more length in Section 6.5.		the borders. This is described at more length in Section 6.5.
	One should observe that the embedded-RP threat model is actually		One should observe that the embedded-RP threat model is actually
	rather similar to SSM; both mechanisms significantly reduce the		rather similar to SSM; both mechanisms significantly reduce the
	threats at the sender side. On the receiver side, the threats are		threats at the sender side. On the receiver side, the threats are
	somewhat comparable, as an attacker could do an MLDv2 (S,G) join		somewhat comparable, as an attacker could do an MLDv2 (S,G) join
	towards a non-existent source, which the local RP could not block		towards a non-existent source, which the local RP could not block
	based on the MSDP information.		based on the MSDP information.
	The implementation MUST perform at least the same address validity		The implementation MUST perform at least the same address validity
	checks to the embedded-RP address as to one received via other means;		checks to the embedded-RP address as it would to one received via
	at least fe80::/10, ::/16, and ff00::/8 should be excluded. This is		other means; at least fe80::/10, ::/16, and ff00::/8 should be
	particularly important as the information is derived from the		excluded. This is particularly important, as the information is
	untrusted source (i.e., any user in the Internet), not from the local		derived from the untrusted source (i.e., any user in the Internet),
	configuration.		not from the local configuration.
	A more extensive description and comparison of the inter-domain		A more extensive description and comparison of the inter-domain
	multicast routing models (traditional ASM with MSDP, embedded-RP,		multicast routing models (traditional ASM with MSDP, embedded-RP,
	SSM) and their security properties has been done separately in		SSM) and their security properties has been done separately in
	[PIMSEC].		[PIMSEC].
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing		[ADDRARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6
	Architecture", RFC3513, April 2003.		(IPv6) Addressing Architecture", RFC 3513, April 2003.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3306] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6		[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
	Multicast Addresses", RFC3306, August 2002.		Multicast Addresses", RFC3306, August 2002.
	11.2. Informative References		11.2. Informative References
	[ANYCAST] Hagino, J., Ettikan, K., "An analysis of IPv6		[ANYCAST] Hagino, J. and K. Ettikan, "An analysis of IPv6 anycast",
	anycast", work-in-progress, draft-ietf-ipngwg-ipv6-		Work in Progress, June 2003.
	anycast-analysis-02.txt, June 2003.
	[ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and		[ANYCASTRP] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci,
	MSDP", RFC 3446, January 2003.		"Anycast Rendevous Point (RP) mechanism using Protocol
			Independent Multicast (PIM) and Multicast Source
			Discovery Protocol (MSDP)", RFC 3446, January 2003.
	[ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM",		[ANYPIMRP] Farinacci, D. and Y. Cai, "Anycast-RP using PIM", Work in
	work-in-progress, draft-ietf-pim-anycast-rp-02.txt,		Progress, June 2004.
	June 2004.
	[BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for		[BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for
	PIM Sparse Mode", work-in-progress, draft-ietf-pim-sm-		PIM Sparse Mode", Work in Progress, July 2004.
	bsr-03.txt, February 2003.
	[MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Source		[MSDP] Fenner, B. and D. Meyer, "Multicast Source Discovery
	Discovery Protocol (MSDP)", RFC 3618, October 2003.		Protocol (MSDP)", RFC 3618, October 2003.
	[PIMSEC] Savola, P., Lehtonen, R., Meyer, D., "PIM-SM Multicast		[PIMSEC] Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast
	Routing Security Issues and Enhancements",		Routing Security Issues and Enhancements", Work in
	work-in-progress, draft-ietf-mboned-mroutesec-02.txt,		Progress, October 2004.
	June 2004.
	[PIM-SM] Fenner, B. et al, "Protocol Independent Multicast -		[PIM-SM] Fenner, B. et al, "Protocol Independent Multicast -
	Sparse Mode (PIM-SM): Protocol Specification (Revised),		Sparse Mode (PIM-SM): Protocol Specification (Revised)",
	work-in-progress, draft-ietf-pim-sm-v2-new-09.txt,		Work in Progress, July 2004.
	February 2004.
	[SSM] Holbrook, H. et al, "Source-Specific Multicast for IP",		[SSM] Holbrook, H. et al, "Source-Specific Multicast for IP",
	work-in-progress, draft-ietf-ssm-arch-04.txt,		Work in Progress, September 2004.
	October 2003.
	[V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues",
	work-in-progress, draft-savola-v6ops-multicast-
	issues-03.txt, February 2004.
	Authors' Addresses
	Pekka Savola
	CSC/FUNET
	Espoo, Finland
	EMail: psavola@funet.fi
	Brian Haberman		[V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", Work in
	Caspian Networks		Progress, September 2004.
	One Park Drive, Suite 300
	Research Triangle Park, NC 27709
	EMail: brian@innovationslab.net
	Phone: +1-919-949-4828
	A. Discussion about Design Tradeoffs		A. Discussion about Design Tradeoffs
	The document only specifies FF70::/12 for now; if/when the upper-most		The document only specifies FF70::/12 for now; if/when the upper-most
	bit is used, one must specify how FFF0::/12 applies to Embedded-RP.		bit is used, one must specify how FFF0::/12 applies to Embedded-RP.
	For example, a different mode of PIM or another protocol might use		For example, a different mode of PIM or another protocol might use
	that range, in contrast to FF70::/12, as currently specified, being		that range, in contrast to FF70::/12, as currently specified, being
	for PIM-SM only.		for PIM-SM only.
	Instead of using flags bits ("FF70::/12"), one could have used the		Instead of using flags bits ("FF70::/12"), one could have used the
	left-most reserved bits instead ("FF3x:8000::/17").		leftmost reserved bits instead ("FF3x:8000::/17").
	It has been argued that instead of allowing the operator to specify		It has been argued that instead of allowing the operator to specify
	RIID, the value could be pre-determined (e.g., "1"). However, this		RIID, the value could be pre-determined (e.g., "1"). However, this
	has not been adopted, as this eliminates address assignment		has not been adopted, as this eliminates address assignment
	flexibility from the operator.		flexibility from the operator.
	Values 64 < "plen" < 96 would overlap with upper bits of the		Values 64 < "plen" < 96 would overlap with upper bits of the
	multicast group-id; due to this restriction, "plen" must not exceed		multicast group-id; due to this restriction, "plen" must not exceed
	64 bits. This is in line with RFC 3306.		64 bits. This is in line with RFC 3306.
	skipping to change at page 17, line 23		skipping to change at page 17, line 5
	In any case, such modifications are beyond the scope of this memo.		In any case, such modifications are beyond the scope of this memo.
	For the cases where the RPs do not exist or are unreachable, or too		For the cases where the RPs do not exist or are unreachable, or too
	much state is being generated to reach in a resource exhaustion		much state is being generated to reach in a resource exhaustion
	Denial of Service attack, some forms of rate-limiting or other		Denial of Service attack, some forms of rate-limiting or other
	mechanisms could be deployed to mitigate the threats while trying not		mechanisms could be deployed to mitigate the threats while trying not
	to disturb the legitimate usage. However, as the threats are		to disturb the legitimate usage. However, as the threats are
	generic, they are considered out of scope and discussed separately in		generic, they are considered out of scope and discussed separately in
	[PIMSEC].		[PIMSEC].
	Intellectual Property Statement		Authors' Addresses
			Pekka Savola
			CSC/FUNET
			Espoo, Finland
			EMail: psavola@funet.fi
			Brian Haberman
			Johns Hopkins University Applied Physics Lab
			11100 Johns Hopkins Road
			Laurel, MD 20723-6099
			US
			Phone: +1 443 778 1319
			EMail: brian@innovationslab.net
			Full Copyright Statement
			Copyright (C) The Internet Society (2004).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			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
	on the IETF's procedures with respect to rights in IETF Documents can		on the IETF's procedures with respect to rights in IETF Documents can
	be found in BCP 78 and BCP 79.		be found in BCP 78 and BCP 79.
	skipping to change at page 17, line 47		skipping to change at page 18, line 45
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
	Disclaimer of Validity
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	Acknowledgement		Acknowledgement
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/