draft-ietf-mboned-embeddedrp-06.txt		draft-ietf-mboned-embeddedrp-07.txt
	mboned Working Group P. Savola		mboned Working Group P. Savola
	Internet Draft CSC/FUNET		Internet Draft CSC/FUNET
	Expiration Date: December 2004		Expiration Date: January 2005
	B. Haberman		B. Haberman
	Caspian Networks		Caspian Networks
	June 2004		July 2004
	Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address		Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
	draft-ietf-mboned-embeddedrp-06.txt		draft-ietf-mboned-embeddedrp-07.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	and any of which I become aware will be disclosed, in accordance with		and any of which I become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	skipping to change at page 2, line 12		skipping to change at page 2, line 12
	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 ............................................... 3
	1.3. Assumptions and Scope .................................. 4		1.3. Assumptions and Scope .................................. 4
	1.4. Terminology ............................................ 4		1.4. Terminology ............................................ 4
	2. Unicast-Prefix-based Address Format ........................ 4		1.5. Abbreviations .......................................... 4
			2. Unicast-Prefix-based Address Format ........................ 5
	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 ... 6
	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 ................................. 9
	6.1. RP Redundancy .......................................... 9		6.1. RP Redundancy .......................................... 9
	6.2. RP Deployment .......................................... 9		6.2. RP Deployment .......................................... 9
	skipping to change at page 2, line 47		skipping to change at page 2, line 48
	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 not been, on purpose, specified for IPv6.
	Therefore the whole interdomain Any Source Multicast 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 (ASM) but can be used as a simple		interdomain Any Source Multicast but can be used as a simple solution
	solution for IPv6 intradomain ASM with scoped multicast addresses as		for IPv6 intradomain ASM with scoped multicast addresses as well. It
	well. It can also be used as an automatic RP discovery mechanism in		can also be used as an automatic RP discovery mechanism in those
	those deployment scenarios which would have previously used the		deployment scenarios which would have previously used the Bootstrap
	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
	skipping to change at page 4, line 5		skipping to change at page 3, line 46
	SM on these IPv6 multicast groups.		SM 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.
	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, either operational procedures
	and configuration must be slightly changed or this mechanism can not		and configuration must be slightly changed or this mechanism can not
	skipping to change at page 4, line 38		skipping to change at page 4, line 38
	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 all
	intra-domain to the information distribution. However, as it gives a		intra-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
			ASM Any Source Multicast
			BSR Bootstrap Router
			DR Designated Router
			IGP Interior Gateway Protocol
			MLD Multicast Listener Discovery
			MSDP Multicast Source Discovery Protocol
			PIM Protocol Independent Multicast
			PIM-SM Protocol Independent Multicast - Sparse Mode
			RIID RP Interface ID (as specified in this memo)
			RP Rendezvous Point
			RPF Reverse Path Forwarding
			SPT Shortest Path Tree
			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 have been 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:		address format by specifying the second high-order bit ("R-bit") as
			follows:
	1. If the two high-order bits in "flgs" are set to 01, the address
	of the RP is embedded in the multicast address, as described in
	this memo.
	2. If the two high-order bit in "flgs" are set to 01, interpret
	the last low-order 4 bits of "reserved" field as signifying the
	RP interface ID ("RIID"), as described in this memo.
	The encoding and the protocol mode used when the two high-order bit
	in "flgs" are set to 11 is intentionally unspecified until such time
	that the highest-order bit is defined.
	In consequence, the address format becomes:
	| 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 4 flags: |0|R|P|T|
	+-+-+-+-+		+-+-+-+-+
	R = 1 indicates a multicast address that embeds the address on the		R = 1 indicates a multicast address that embeds the address on the
	RP. Then P MUST be set to 1, and consequently T MUST be set to 1, as		RP. Then P MUST be set to 1, and consequently T MUST be set to 1, as
	specified in [RFC3306]. If R = 1, but P is set to 0, the packet MUST		specified in [RFC3306]. In effect, this implies the prefix
	be discarded. The behaviour if T is set to 0 when P is set to 1 is		FF70::/12.
	derived from [RFC3306] and is unspecified in this memo.
			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
			mode used when the two high-order bit in "flgs" are set to 11
			("FFF0::/12") is intentionally unspecified until such time that the
			highest-order bit is defined.
	In the case that R = 1, the last 4 bits of the previously reserved		In the case that R = 1, the last 4 bits of the previously reserved
	field are interpreted as embedding the RP interface ID, as specified		field are interpreted as embedding the RP interface ID, as specified
	in this memo.		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.
	skipping to change at page 6, line 16		skipping to change at page 6, line 16
	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 an address is a multicast address as
	specified in this memo and to be processed any further, it must		specified in this memo and to be processed any further, it must
	satisfy all of the below:		satisfy all of the below:
	o it MUST be a multicast address and have R, P, and T flag bits set		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		to 1 -- that is, be part of the prefix FF70::/12 (note that
	FFF0::/12 is unspecified),		FFF0::/12 is yet unspecified),
	o "plen" MUST NOT be 0 (ie. not SSM), and		o "plen" MUST NOT be 0 (ie. 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 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"
	|| +------------+------------------------+		|| +------------+--------------------------+
	|| | network pre| 0000000000000000000000 |		|| | network pre| 0000000000000000000000 |
	|| +------------+------------------------+		|| +------------+--------------------------+
	\\		\\
	``=================> copy RIID to the last 4 bits		``=================> copy RIID to the last 4 bits
	+------------+---------------------+--+		+------------+---------------------+----+
	| network pre| 0000000000000000000 |ID|		| 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 [RFC3306] statement "all non-significant bits
	of the network prefix field SHOULD be zero" is ignored. This is to		of the network prefix field SHOULD be zero" is ignored. This is to
	allow multicast group address allocations to be consistent with		allow multicast group address allocations to be consistent with
	unicast prefixes, while the multicast addresses would still use the		unicast prefixes, while the multicast addresses would still use the
	RP associated with the network prefix.		RP 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 the
	high-order bits of multicast group-id.		high-order bits of multicast group-id.
	skipping to change at page 9, line 20		skipping to change at page 9, line 20
	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
	RP's mainly for redundancy purposes. Typically, MSDP has been used		RP's mainly for redundancy purposes. Typically, MSDP has been used
	for that as well [ANYCASTRP]. There are also other approaches, like		for that as well [ANYCASTRP]. There are also other approaches, like
	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 IGP without state sharing (depending on the redundancy		address in the Interior Gateway Protocol (IGP) without state sharing
	requirements, this may or may not be enough, though). However, the		(depending on the redundancy requirements, this may or may not be
	redundancy mechanisms are outside of the scope of this memo.		enough, though). However, the redundancy mechanisms are outside of
			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 DR		As there is no need to share inter-domain state with MSDP, each
	connecting multicast sources could act as an RP without scalability		Designated Router connecting multicast sources could act as an RP
	concerns about setting up and maintaining MSDP sessions.		without scalability concerns about setting up and maintaining MSDP
			sessions.
	This might be particularly attractive when concerned about RP		This might be particularly attractive when 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, it's 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
	skipping to change at page 10, line 32		skipping to change at page 10, line 32
	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: being able to filter who is able to create a global
	session ("source filtering"), and being able to filter which groups		session ("source filtering"), and being able to filter which groups
	should be globally accessible ("group filtering"). These are done to		should be globally accessible ("group filtering"). These are done to
	prevent local groups from being advertised to the outside, or		prevent local groups from being advertised to the outside, or
	preventing unauthorized senders from creating global groups.		preventing unauthorized senders 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 an (S,G) Join by guessing/learning the source		advertisement with a (Source, Group) or (S,G) Join by
	and/or the group address. For proper protection, one should set up,		guessing/learning the source and/or the group address. For proper
	e.g., PIM multicast scoping borders at the border routers.		protection, one should set up, e.g., PIM multicast scoping borders at
	Therefore, embedded-RP has by default roughtly equivalent level of		the border routers. Therefore, embedded-RP has by default roughtly
	"protection" as MSDP with SA filtering.		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 comes from the fact that nodes in a "foreign
	domain" may register to an RP, or send PIM Join to an RP. (These have		domain" may register to an RP, or send PIM Join to an RP. (These have
	been possible in the past as well, to a degree, but only through		been possible in the past as well, to a degree, but only through
	willfull attempts or purposeful RP configuration at DRs.) The main		willfull attempts or purposeful RP configuration at DRs.) The main
	threat in this case is that an outsider illegitimately uses the RP to		threat in this case is that an outsider illegitimately uses the RP to
	host his/hers own group(s). This can be mitigated to an extent by		host 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
	skipping to change at page 11, line 47		skipping to change at page 11, line 47
	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:
	1. A receiver finds out a group address from some means (e.g., SDR		1. A receiver finds out a group address from some means (e.g., SDR
	or a web page).		or a web page).
	2. The receiver issues an MLD Report, joining the group.		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 it is in the "local" or "remote" PIM domain.		whether 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:
	1. A sender finds out a group address using an unspecified method		1. A sender finds out a group address 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.
	skipping to change at page 13, line 44		skipping to change at page 13, line 44
	9. Acknowledgements		9. Acknowledgements
	Jerome Durand commented on an early draft of this memo. Marshall		Jerome Durand commented on an early draft 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 draft 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. The whole MboneD working group is		during and after WG last call. Mark Allman, Bill Fenner, Thomas
	also acknowledged for the continued support and comments.		Narten, and Alex Zinin provided substantive comments during the IESG
			evaluation. The whole MboneD working group is also acknowledged for
			the 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 -- and
	thus become more visible as single points of failure. Even though		thus become more visible as single points of failure. Even though
	this does not significantly affect the multicast routing security, it		this does not significantly affect the multicast routing security, it
	may expose the RP to other kinds of attacks. The operators are		may 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 on considerations regarding failover and Section 6.2 on
	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 DoS attack scenario.		from any DR, this might cause a potential Denial of Service attack
	However, this can be mitigated by the fact that the RP can discard		scenario. However, this can be mitigated by the fact that the RP can
	all such messages for all multicast addresses that do not encode the		discard all such messages for all multicast addresses that do not
	address of the RP. Both the sender- and receiver-based attacks are		encode the address of the RP. Both the sender- and receiver-based
	described at more length in [PIMSEC].		attacks are described at more 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, it is desirable to be able to restrict (at the
	RP) which unicast addresses are allowed to send or join to a group.		RP) which unicast addresses are allowed to send or join to a group.
	(However, note that Join/Prune messages would still leave state in		(However, note that Join/Prune messages would still leave state in
	the network, and Register messages can be spoofed [PIMSEC].)		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.
	skipping to change at page 15, line 41		skipping to change at page 15, line 41
	11.2. Informative References		11.2. Informative References
	[ANYCAST] Hagino, J., Ettikan, K., "An analysis of IPv6		[ANYCAST] Hagino, J., Ettikan, K., "An analysis of IPv6
	anycast", work-in-progress, draft-ietf-ipngwg-ipv6-		anycast", work-in-progress, draft-ietf-ipngwg-ipv6-
	anycast-analysis-02.txt, June 2003.		anycast-analysis-02.txt, June 2003.
	[ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and		[ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and
	MSDP", RFC 3446, January 2003.		MSDP", RFC 3446, January 2003.
	[ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM",		[ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM",
	work-in-progress, draft-ietf-pim-anycast-rp-00.txt,		work-in-progress, draft-ietf-pim-anycast-rp-02.txt,
	November 2003.		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, draft-ietf-pim-sm-
	bsr-03.txt, February 2003.		bsr-03.txt, February 2003.
	[MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Source		[MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Source
	Discovery Protocol (MSDP)", RFC 3618, October 2003.		Discovery Protocol (MSDP)", RFC 3618, October 2003.
	[PIMSEC] Savola, P., Lehtonen, R., Meyer, D., "PIM-SM Multicast		[PIMSEC] Savola, P., Lehtonen, R., Meyer, D., "PIM-SM Multicast
	Routing Security Issues and Enhancements",		Routing Security Issues and Enhancements",
	work-in-progress, draft-ietf-mboned-mroutesec-00.txt,		work-in-progress, draft-ietf-mboned-mroutesec-02.txt,
	April 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, draft-ietf-pim-sm-v2-new-09.txt,
	February 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, draft-ietf-ssm-arch-04.txt,
	October 2003.		October 2003.
	skipping to change at page 17, line 16		skipping to change at page 17, line 16
	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.
	The embedded-RP addressing could be used to convey other information		The embedded-RP addressing could be used to convey other information
	(other than RP address) as well, for example, what should be the RPT		(other than RP address) as well, for example, what should be the RPT
	threshold for PIM-SM. These could be, whether feasible or not,		threshold for PIM-SM. These could be, whether feasible or not,
	encoded in the RP address somehow, or in the multicast group address.		encoded in the RP address somehow, or in the multicast group address.
	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 DoS		much state is being generated to reach in a resource exhaustion
	attack, some forms of rate-limiting or other mechanisms could be		Denial of Service attack, some forms of rate-limiting or other
	deployed to mitigate the threats while trying not to disturb the		mechanisms could be deployed to mitigate the threats while trying not
	legitimate usage. However, as the threats are generic, they are		to disturb the legitimate usage. However, as the threats are
	considered out of scope and discussed separately in [PIMSEC].		generic, they are considered out of scope and discussed separately in
			[PIMSEC].
	Intellectual Property Statement		Intellectual Property Statement
	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
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/