draft-ietf-mboned-embeddedrp-05.txt		draft-ietf-mboned-embeddedrp-06.txt
	skipping to change at page 1, line 13		skipping to change at page 1, line 13
	mboned Working Group P. Savola		mboned Working Group P. Savola
	Internet Draft CSC/FUNET		Internet Draft CSC/FUNET
	Expiration Date: December 2004		Expiration Date: December 2004
	B. Haberman		B. Haberman
	Caspian Networks		Caspian Networks
	June 2004		June 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-05.txt		draft-ietf-mboned-embeddedrp-06.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 7		skipping to change at page 2, line 7
	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 ............................................... 3		1. Introduction ............................................... 2
	1.1. Background ............................................. 3		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		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 ... 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
	skipping to change at page 2, line 37		skipping to change at page 2, line 37
	7.1. PIM-SM Group-to-RP Mapping ............................. 11		7.1. PIM-SM Group-to-RP Mapping ............................. 11
	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 ................................... 14
	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		Authors' Addresses ............................................. 16
	A. Discussion about Design Tradeoffs .......................... 16		A. Discussion about Design Tradeoffs .......................... 16
	B. Changes .................................................... 17
	B.4 Changes since -04 ....................................... 17
	B.3 Changes since -03 ....................................... 17
	B.2 Changes since -02 ....................................... 17
	B.3 Changes since -01 ....................................... 18
	B.4 Changes since -00 ....................................... 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 not been, on purpose, specified for IPv6.
	skipping to change at page 5, line 42		skipping to change at page 5, line 34
	| 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].		specified in [RFC3306]. If R = 1, but P is set to 0, the packet MUST
			be discarded. The behaviour if T is set to 0 when P is set to 1 is
			derived from [RFC3306] and is unspecified in this memo.
	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 7, line 47		skipping to change at page 7, line 47
	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-id's to assign to customers and self ("y" could be anything
	from 1 to F, as 0 must not be used).		from 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 group allocations. That is, the administrator selects the least		for group allocations. That is, the administrator selects the least
	specific part of the prefix, with plen=32, and the group addresses		specific part of the unicast prefix, with plen=32, and the group
	will be of the form:		addresses will be from the multicast prefix:
	FF7x:y20:2001:DB8:zzzz:zzzz:<group-id>		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" the interface ID of the RP
	address, and "zzzz:zzzz" will be assignable to anyone. In this case,		address, and there are 64 bits for group-id's or assignments. In
	the address of the RP would be:		this 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 injected to 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 a couple of RPs (and e.g., not one
	RP per subnet), this approach may be preferable to the one described		RP per subnet), this approach may be preferable to the one described
	in Example 1.		in Example 1.
	5.3. Example 3		5.3. Example 3
	As in Example 2, the network administrator can also allocate		As in Example 2, the network administrator can also assign multicast
	multicast addresses like "FF7x:y20:2001:DB8:DEAD::/80" to some of		prefixes like "FF7x:y20:2001:DB8:DEAD::/80" to some of customers. In
	customers. In this case the RP address would still be "2001:DB8::y".		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
			administrator assigns a multicast prefix, not just invidial group-
			id's.)
	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
	skipping to change at page 9, line 45		skipping to change at page 9, line 45
	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
	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 one group faces the
	similar challenges as Anycast-RP.		similar challenges as 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 network prefix		With this mechanism, the RP can be given basically any unicast
	up to /64. The interface identifier will have to be manually		network prefix up to /64. The interface identifier will have to be
	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
	prefix (e.g., an additional loopback address assigned on a router, as		unicast prefix (e.g., an additional loopback address assigned on a
	described in example 2 in Section 5.1), that address can be injected		router, as described in example 2 in Section 5.1), that address can
	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
	skipping to change at page 10, line 47		skipping to change at page 10, line 47
	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
	with a /64 prefix can create an own RP, without having to		with a /64 unicast prefix can create an 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 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, the group-to-RP mapping specified		To avoid loops and inconsistancies, for addresses in the range
	in this memo MUST be used for all embedded-RP groups (i.e., addresses		FF70::/12, the Embedded-RP mapping MUST be considered to be the
	with prefix FF70::/12).		longest 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 which would map to a
	different RP. For efficiency, the results may be cached in an		different RP. For efficiency, the results may be cached in an
	implementation-specific manner, to avoid computation for every		implementation-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
	skipping to change at page 17, line 21		skipping to change at page 17, line 21
	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 DoS
	attack, some forms of rate-limiting or other mechanisms could be		attack, some forms of rate-limiting or other mechanisms could be
	deployed to mitigate the threats while trying not to disturb the		deployed to mitigate the threats while trying not to disturb the
	legitimate usage. However, as the threats are generic, they are		legitimate usage. However, as the threats are generic, they are
	considered out of scope and discussed separately in [PIMSEC].		considered out of scope and discussed separately in [PIMSEC].
	B. Changes
	[[ RFC-Editor: please remove before publication ]]
	B.4 Changes since -04
	o Only update the boilerplates.
	B.3 Changes since -03
	o Further clarifications, especially regarding Inter/intra-domain
	terminology.
	o Recommend more strongly that multicast groups can be configured,
	and that they should be explicitly configured, to protect against
	abuse.
	o Note that more detailed controls on who can use a multicast
	address are out of scope.
	o Add discussion about controls/manageability and how that has
	changed from the MSDP model.
	B.2 Changes since -02
	o Clarified security considerations, wrt. RPs being abused by third
	parties and policy controls at the RP.
	o Clarified that only RPs, DRs next to sources sending to embedded-
	RP groups, and routers between the receivers and the RPs need to
	have support this mapping.
	o Try to be clearer that FF70::/12 is meant for PIM-SM at the
	moment, while FFF0::/12 is unspecified.
	o Minor miscellaneous changes.
	B.3 Changes since -01
	o Lots of editorial cleanups and some reorganization, without
	technical changes.
	o Remove the specification that RIID=0 SHOULD NOT be accepted, but
	state that they "must not" be used (implementation vs.
	operational wording).
	o Specify that the RP address MUST NOT be of prefixes fe80::/10,
	::/16, or ff00::/8.
	B.4 Changes since -00
	o Lots of editorial cleanups, or cleanups without techinical
	changes.
	o Reinforce the notion of Embedded RP just being a group-to-RP
	mapping mechanism (causing substantive rewriting in section 7);
	highlight the fact that precomputing the group-to-RP mapping is
	not possible.
	o Add (a bit) more text on RP redundancy and deployment tradeoffs
	wrt. RPs becoming SPoF.
	o Clarify the usability/scalability issues in section 8.
	o Clarify the security issues in Sections 8, Security
	Considerations and Appendix A, mainly by referring to a separate
	document.
	o Add a MUST that embedded-RP mappings must be honored by
	implementations.
	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/