draft-ietf-mboned-addrarch-06.txt		draft-ietf-mboned-addrarch-07.txt
	Internet Engineering Task Force P. Savola		Internet Engineering Task Force P. Savola
	Internet-Draft CSC/FUNET		Internet-Draft CSC/FUNET
	Obsoletes: 2908 (if approved) August 3, 2009		Obsoletes: 2908 (if approved) October 25, 2010
	Intended status: Informational		Intended status: Informational
	Expires: February 4, 2010		Expires: April 28, 2011
	Overview of the Internet Multicast Addressing Architecture		Overview of the Internet Multicast Addressing Architecture
	draft-ietf-mboned-addrarch-06.txt		draft-ietf-mboned-addrarch-07.txt
			Abstract
			The lack of up-to-date documentation on IP multicast address
			allocation and assignment procedures has caused a great deal of
			confusion. To clarify the situation, this memo describes the
			allocation and assignment techniques and mechanisms currently (as of
			this writing) in use.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on April 28, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on February 4, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	The lack of up-to-date documentation on IP multicast address		described in the Simplified BSD License.
	allocation and assignment procedures has caused a great deal of
	confusion. To clarify the situation, this memo describes the
	allocation and assignment techniques and mechanisms currently (as of
	this writing) in use.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology: Allocation or Assignment . . . . . . . . . . 3		1.1. Terminology: Allocation or Assignment . . . . . . . . . . 3
	2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 4		2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 4
	2.1. Derived Allocation . . . . . . . . . . . . . . . . . . . . 4		2.1. Derived Allocation . . . . . . . . . . . . . . . . . . . . 4
	2.1.1. GLOP Allocation . . . . . . . . . . . . . . . . . . . 4		2.1.1. GLOP Allocation . . . . . . . . . . . . . . . . . . . 4
	2.1.2. Unicast-prefix-based Allocation . . . . . . . . . . . 4		2.1.2. Unicast-prefix-based Allocation . . . . . . . . . . . 4
	2.2. Administratively Scoped Allocation . . . . . . . . . . . . 5		2.2. Administratively Scoped Allocation . . . . . . . . . . . . 5
	2.3. Static IANA Allocation . . . . . . . . . . . . . . . . . . 6		2.3. Static IANA Allocation . . . . . . . . . . . . . . . . . . 6
	2.4. Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6		2.4. Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6
	3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 7		3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 6
	3.1. Derived Assignment . . . . . . . . . . . . . . . . . . . . 7		3.1. Derived Assignment . . . . . . . . . . . . . . . . . . . . 7
	3.2. SSM Assignment inside the Node . . . . . . . . . . . . . . 7		3.2. SSM Assignment inside the Node . . . . . . . . . . . . . . 7
	3.3. Manually Configured Assignment . . . . . . . . . . . . . . 7		3.3. Manually Configured Assignment . . . . . . . . . . . . . . 7
	3.4. Static IANA Assignment . . . . . . . . . . . . . . . . . . 8		3.4. Static IANA Assignment . . . . . . . . . . . . . . . . . . 8
	3.4.1. Global IANA Assignment . . . . . . . . . . . . . . . . 8		3.4.1. Global IANA Assignment . . . . . . . . . . . . . . . . 8
	3.4.2. Scope-relative IANA Assignment . . . . . . . . . . . . 8		3.4.2. Scope-relative IANA Assignment . . . . . . . . . . . . 8
	3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8		3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8
	4. Summary and Future Directions . . . . . . . . . . . . . . . . 9		4. Summary and Future Directions . . . . . . . . . . . . . . . . 9
	4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 10		4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 10
	4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11		4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11
	4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11		4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 13		8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . . 13		8.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15		Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15
	A.1. Changes between -05 and -06 . . . . . . . . . . . . . . . 15		A.1. Changes between -06 and -07 . . . . . . . . . . . . . . . 15
	A.2. Changes between -04 and -05 . . . . . . . . . . . . . . . 15		A.2. Changes between -05 and -06 . . . . . . . . . . . . . . . 15
	A.3. Changes between -03 and -04 . . . . . . . . . . . . . . . 16		A.3. Changes between -04 and -05 . . . . . . . . . . . . . . . 15
	A.4. Changes between -02 and -03 . . . . . . . . . . . . . . . 16		A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 16
	A.5. Changes between -01 and -02 . . . . . . . . . . . . . . . 16		A.5. Changes between -02 and -03 . . . . . . . . . . . . . . . 16
			A.6. Changes between -01 and -02 . . . . . . . . . . . . . . . 16
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	Good, up-to-date documentation of IP multicast is close to non-		Good, up-to-date documentation of IP multicast is close to non-
	existent. Particularly, this is an issue with multicast address		existent. Particularly, this is an issue with multicast address
	allocations (to networks and sites) and assignments (to hosts and		allocations (to networks and sites) and assignments (to hosts and
	applications). This problem is stressed by the fact that there		applications). This problem is stressed by the fact that there
	exists confusing or misleading documentation on the subject		exists confusing or misleading documentation on the subject
	[RFC2908]. The consequence is that those who wish to learn about IP		[RFC2908]. The consequence is that those who wish to learn about IP
	skipping to change at page 5, line 5		skipping to change at page 5, line 5
	because the unicast-prefix-based allocation (described below)		because the unicast-prefix-based allocation (described below)
	addresses the same need in a simpler fashion.		addresses the same need in a simpler fashion.
	2.1.2. Unicast-prefix-based Allocation		2.1.2. Unicast-prefix-based Allocation
	RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 high-		RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 high-
	order bits of an IPv6 unicast address in the prefix part of the IPv6		order bits of an IPv6 unicast address in the prefix part of the IPv6
	multicast address, leaving at least 32 bits of group-id space		multicast address, leaving at least 32 bits of group-id space
	available after the prefix mapping.		available after the prefix mapping.
	A similar IPv4 mapping is described in		A similar IPv4 mapping is described in [RFC6034], but it provides a
	[I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a limited		limited number of addresses (e.g., 1 per an IPv4 /24 block).
	number of addresses (e.g., 1 per an IPv4 /24 block).
	The IPv6 unicast-prefix-based allocations are an extremely useful way		The IPv6 unicast-prefix-based allocations are an extremely useful way
	to allow each network operator, even each subnet, to obtain multicast		to allow each network operator, even each subnet, to obtain multicast
	addresses easily, through an easy computation. Further, as the IPv6		addresses easily, through an easy computation. Further, as the IPv6
	multicast header also includes the scope value [RFC4291], multicast		multicast header also includes the scope value [RFC4291], multicast
	groups of smaller scope can also be used with the same mapping.		groups of smaller scope can also be used with the same mapping.
	The IPv6 Embedded RP technique [RFC3956], used with Protocol		The IPv6 Embedded RP technique [RFC3956], used with Protocol
	Independent Multicast - Sparse Mode (PIM-SM), further leverages the		Independent Multicast - Sparse Mode (PIM-SM), further leverages the
	unicast-prefix-based allocations, by embedding the unicast prefix and		unicast-prefix-based allocations, by embedding the unicast prefix and
	skipping to change at page 6, line 31		skipping to change at page 6, line 29
	In some rare cases, organizations may have been able to obtain static		In some rare cases, organizations may have been able to obtain static
	multicast address allocations (of up to 256 addresses) directly from		multicast address allocations (of up to 256 addresses) directly from
	IANA. Typically these have been meant as a block of static		IANA. Typically these have been meant as a block of static
	assignments to multicast applications, as described in Section 3.4.1.		assignments to multicast applications, as described in Section 3.4.1.
	If another means of obtaining addresses is available that approach is		If another means of obtaining addresses is available that approach is
	preferable.		preferable.
	Especially for those operators that only have a 32-bit AS number and		Especially for those operators that only have a 32-bit AS number and
	need IPv4 addresses, an IANA allocation from "AD-HOC Block III" (the		need IPv4 addresses, an IANA allocation from "AD-HOC Block III" (the
	previous so-called "eGLOP" block) is an option		previous so-called "eGLOP" block) is an option [RFC5771].
	[I-D.ietf-mboned-rfc3171bis].
	2.4. Dynamic Allocation		2.4. Dynamic Allocation
	RFC 2908 [RFC2908] proposed three different layers of multicast		RFC 2908 [RFC2908] proposed three different layers of multicast
	address allocation and assignment, where layers 3 (inter-domain		address allocation and assignment, where layers 3 (inter-domain
	allocation) and layer 2 (intra-domain allocation) could be applicable		allocation) and layer 2 (intra-domain allocation) could be applicable
	here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an		here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an
	example of the former, and Multicast Address Allocation Protocol		example of the former, and Multicast Address Allocation Protocol
	(AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest		(AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest
	and technical problems) is an example of the latter.		and technical problems) is an example of the latter.
	skipping to change at page 8, line 14		skipping to change at page 8, line 11
	This is the most commonly used technique when the multicast		This is the most commonly used technique when the multicast
	application does not have a static IANA assignment.		application does not have a static IANA assignment.
	3.4. Static IANA Assignment		3.4. Static IANA Assignment
	In contrast to manually configured assignment, as described above,		In contrast to manually configured assignment, as described above,
	static IANA assignment refers to getting an assignment for the		static IANA assignment refers to getting an assignment for the
	particular application directly from IANA. There are two main forms		particular application directly from IANA. There are two main forms
	of IANA assignment: global and scope-relative. Guidelines for IANA		of IANA assignment: global and scope-relative. Guidelines for IANA
	are described in [I-D.ietf-mboned-rfc3171bis].		are described in [RFC5771].
	3.4.1. Global IANA Assignment		3.4.1. Global IANA Assignment
	Globally unique address assignment is seen as lucrative because it's		Globally unique address assignment is seen as lucrative because it's
	the simplest approach for application developers since they can then		the simplest approach for application developers since they can then
	hard-code the multicast address. Hard-coding requires no lease of		hard-code the multicast address. Hard-coding requires no lease of
	the usable multicast address, and likewise the client applications do		the usable multicast address, and likewise the client applications do
	not need to perform any kind of service discovery (but depending on		not need to perform any kind of service discovery (but depending on
	hard-coded addresses). However, there is an architectural scaling		hard-coded addresses). However, there is an architectural scaling
	problem with this approach, as it encourages a "land-grab" of the		problem with this approach, as it encourages a "land-grab" of the
	skipping to change at page 13, line 6		skipping to change at page 13, line 6
	considerations; the security analysis of the mentioned protocols is		considerations; the security analysis of the mentioned protocols is
	out of scope of this memo.		out of scope of this memo.
	Obviously, especially the dynamic assignment protocols are inherently		Obviously, especially the dynamic assignment protocols are inherently
	vulnerable to resource exhaustion attacks, as discussed e.g., in		vulnerable to resource exhaustion attacks, as discussed e.g., in
	[RFC2730].		[RFC2730].
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-mboned-ipv4-uni-based-mcast]
	Thaler, D., "Unicast-Prefix-based IPv4 Multicast
	Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-06
	(work in progress), March 2009.
	[I-D.ietf-mboned-rfc3171bis]
	Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
	IPv4 Multicast Address Assignments",
	draft-ietf-mboned-rfc3171bis-07 (work in progress),
	April 2009.
	[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,		[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
	RFC 2365, July 1998.		RFC 2365, July 1998.
	[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8",		[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8",
	BCP 53, RFC 3180, September 2001.		BCP 53, RFC 3180, September 2001.
	[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6		[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
	Multicast Addresses", RFC 3306, August 2002.		Multicast Addresses", RFC 3306, August 2002.
	[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast		[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
	skipping to change at page 13, line 43		skipping to change at page 13, line 32
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, February 2006.		Architecture", RFC 4291, February 2006.
	[RFC4489] Park, J-S., Shin, M-K., and H-J. Kim, "A Method for		[RFC4489] Park, J-S., Shin, M-K., and H-J. Kim, "A Method for
	Generating Link-Scoped IPv6 Multicast Addresses",		Generating Link-Scoped IPv6 Multicast Addresses",
	RFC 4489, April 2006.		RFC 4489, April 2006.
	[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for		[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
	IP", RFC 4607, August 2006.		IP", RFC 4607, August 2006.
			[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
			IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
			March 2010.
			[RFC6034] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast
			Addresses", RFC 6034, October 2010.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-malloc-aap]		[I-D.ietf-malloc-aap]
	Handley, M. and S. Hanna, "Multicast Address Allocation		Handley, M. and S. Hanna, "Multicast Address Allocation
	Protocol (AAP)", June 2000.		Protocol (AAP)", June 2000.
	[I-D.ietf-mboned-addrdisc-problems]		[I-D.ietf-mboned-addrdisc-problems]
	Savola, P., "Lightweight Multicast Address Discovery		Savola, P., "Lightweight Multicast Address Discovery
	Problem Space", draft-ietf-mboned-addrdisc-problems-02		Problem Space", draft-ietf-mboned-addrdisc-problems-02
	(work in progress), March 2006.		(work in progress), March 2006.
	[I-D.ietf-mboned-session-announcement-req]		[I-D.ietf-mboned-session-announcement-req]
	Asaeda, H. and V. Roca, "Requirements for IP Multicast		Asaeda, H. and V. Roca, "Requirements for IP Multicast
	Session Announcement in the Internet",		Session Announcement",
	draft-ietf-mboned-session-announcement-req-01 (work in		draft-ietf-mboned-session-announcement-req-03 (work in
	progress), March 2009.		progress), March 2010.
	[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]		[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]
	Durand, J., "IPv6 multicast address assignment with		Durand, J., "IPv6 multicast address assignment with
	DHCPv6",		DHCPv6",
	draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work		draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work
	in progress), February 2005.		in progress), February 2005.
	[MBONED-IETF59]		[MBONED-IETF59]
	"MBONED WG session at IETF59",		"MBONED WG session at IETF59",
	<http://www.ietf.org/proceedings/04mar/172.htm>.		<http://www.ietf.org/proceedings/04mar/172.htm>.
	skipping to change at page 15, line 18		skipping to change at page 15, line 14
	[RITVANEN]		[RITVANEN]
	Ritvanen, K., "Multicast Routing and Addressing", HUT		Ritvanen, K., "Multicast Routing and Addressing", HUT
	Report, Seminar on Internetworking, May 2004,		Report, Seminar on Internetworking, May 2004,
	<http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.		<http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.
	Appendix A. Changes		Appendix A. Changes
	(To be removed prior to publication as an RFC.)		(To be removed prior to publication as an RFC.)
	A.1. Changes between -05 and -06		A.1. Changes between -06 and -07
			o Update uni-based-mcast and iana updates references to point to
			RFCs.
			A.2. Changes between -05 and -06
	o Editorial updates.		o Editorial updates.
	o Obsolete only RFC2908; the rest only move to Historic.		o Obsolete only RFC2908; the rest only move to Historic.
	o Category is Informational instead of BCP (in line with the routing		o Category is Informational instead of BCP (in line with the routing
	architecture.		architecture.
	o Move 3171bis and v4-uni-based to Normative references in order to		o Move 3171bis and v4-uni-based to Normative references in order to
	make sure we don't go forward until they're resolved.		make sure we don't go forward until they're resolved.
	o Resolve pending issues per IETF75 discussion, in particular major		o Resolve pending issues per IETF75 discussion, in particular major
	changes to eGLOP and IANA policy discussions.		changes to eGLOP and IANA policy discussions.
	A.2. Changes between -04 and -05		A.3. Changes between -04 and -05
	o Editorial updates. These and the following are from Spencer		o Editorial updates. These and the following are from Spencer
	Dawkins.		Dawkins.
	o New text explicitly stating that GLOP for v6 is not needed and		o New text explicitly stating that GLOP for v6 is not needed and
	GLOP for 4byte ASNs isn't (and likely won't be) defined.		GLOP for 4byte ASNs isn't (and likely won't be) defined.
	o Expand reasons for filtering difficulties with global IANA		o Expand reasons for filtering difficulties with global IANA
	assignments for local apps, and that it would be easier if these		assignments for local apps, and that it would be easier if these
	were done from the local pool.		were done from the local pool.
	o Explicitly mention dynamic allocations protocols' lack of benefit		o Explicitly mention dynamic allocations protocols' lack of benefit
	and abandonment.		and abandonment.
	A.3. Changes between -03 and -04		A.4. Changes between -03 and -04
	o S/scope-relative/administratively scoped/ and expand Static IANA		o S/scope-relative/administratively scoped/ and expand Static IANA
	Assignment section to two subsections; mainly from Dave Price.		Assignment section to two subsections; mainly from Dave Price.
	o Mention the routing challenges of IPv6 IANA assigned prefixes in		o Mention the routing challenges of IPv6 IANA assigned prefixes in
	section 4.2		section 4.2
	A.4. Changes between -02 and -03		A.5. Changes between -02 and -03
	o Reword architectural implications of Static IANA and editorial		o Reword architectural implications of Static IANA and editorial
	improvements; mainly from John Kristoff.		improvements; mainly from John Kristoff.
	A.5. Changes between -01 and -02		A.6. Changes between -01 and -02
	o Mention the mechanisms which haven't been so successful: eGLOP and		o Mention the mechanisms which haven't been so successful: eGLOP and
	MZAP.		MZAP.
	o Remove the appendices on multicast address discovery (a separate		o Remove the appendices on multicast address discovery (a separate
	draft now) and IPv4 unicast-prefix-based multicast addressing.		draft now) and IPv4 unicast-prefix-based multicast addressing.
	o Add a note on administratively scoped address space and the		o Add a note on administratively scoped address space and the
	expansion ambiguity.		expansion ambiguity.
End of changes. 21 change blocks.
	58 lines changed or deleted		56 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/