draft-ietf-mboned-addrarch-03.txt		draft-ietf-mboned-addrarch-04.txt
	Internet Engineering Task Force P. Savola		Internet Engineering Task Force P. Savola
	Internet-Draft CSC/FUNET		Internet-Draft CSC/FUNET
	Obsoletes: 2776,2908,2909 (if October 18, 2005		Obsoletes: 2776,2908,2909 (if March 3, 2006
	approved)		approved)
	Expires: April 21, 2006		Intended status: Best Current
			Practice
			Expires: September 4, 2006
	Overview of the Internet Multicast Addressing Architecture		Overview of the Internet Multicast Addressing Architecture
	draft-ietf-mboned-addrarch-03.txt		draft-ietf-mboned-addrarch-04.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35		skipping to change at page 1, line 37
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 21, 2006.		This Internet-Draft will expire on September 4, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	The lack of up-to-date documentation on IP multicast address		The lack of up-to-date documentation on IP multicast address
	allocation and assignment procedures has caused a great deal of		allocation and assignment procedures has caused a great deal of
	confusion. To clarify the situation, this memo describes the		confusion. To clarify the situation, this memo describes the
	allocation and assignment techniques and mechanisms currently (as of		allocation and assignment techniques and mechanisms currently (as of
	this writing) in use.		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. Scope-relative 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 . . . . . . . . . . . . . . . . . 6		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 . . . . . . . . . . . . . . . . . . 7		3.4. Static IANA Assignment . . . . . . . . . . . . . . . . . . 7
			3.4.1. Global 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 . . . . . . . . . . . . . . . . . . . . 9		4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 10
	4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 10		4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11
	4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11		4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . . 13		8.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 14		Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15
	A.1. Changes since -01 . . . . . . . . . . . . . . . . . . . . 14		A.1. Changes since -01 . . . . . . . . . . . . . . . . . . . . 15
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Intellectual Property and Copyright Statements . . . . . . . . . . 15		Intellectual Property and Copyright Statements . . . . . . . . . . 17
	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 of IP		[RFC2908]. The consequence is that those who wish to learn of IP
	multicast and how the addressing works do not get a clear view of the		multicast and how the addressing works do not get a clear view of the
	skipping to change at page 4, line 44		skipping to change at page 4, line 44
	usage issue is that GLOP addresses are not tied to any prefix but to		usage issue is that GLOP addresses are not tied to any prefix but to
	routing domains, so they cannot be used or calculated automatically.		routing domains, so they cannot be used or calculated automatically.
	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 first		RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 first
	bits of an IPv6 unicast address in the prefix part of the IPv6		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 mapping has been proposed for IPv4 [I-D.ietf-mboned-ipv4-		A similar mapping has been proposed for IPv4
	uni-based-mcast], but it provides a rather low amount of addresses		[I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a rather low
	(e.g., 1 per an IPv4 /24 block). While there exist large networks		amount of addresses (e.g., 1 per an IPv4 /24 block). While there
	without an AS number of their own, this has not been seen to add		exist large networks without an AS number of their own, this has not
	sufficient value compared to GLOP addressing.		been seen to add sufficient value compared to GLOP addressing.
	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, obtain multicast		to allow each network operator, even each subnet, 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 [RFC3513], multicast		multicast header also includes the scope value [RFC3513], 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 5, line 22		skipping to change at page 5, line 22
	routing systems to run the group in either inter- or intra-domain		routing systems to run the group in either inter- or intra-domain
	operation. A difference to RFC 3306 is, however, that the hosts		operation. A difference to RFC 3306 is, however, that the hosts
	cannot calculate their "multicast prefix" automatically, as the		cannot calculate their "multicast prefix" automatically, as the
	prefix depends on the decisions of the operator setting up the RP but		prefix depends on the decisions of the operator setting up the RP but
	rather requires an assignment method.		rather requires an assignment method.
	All the IPv6 unicast-prefix-based allocation techniques provide		All the IPv6 unicast-prefix-based allocation techniques provide
	sufficient amount of multicast address space for the network		sufficient amount of multicast address space for the network
	operators.		operators.
	2.2. Scope-relative Allocation		2.2. Administratively Scoped Allocation
	Administratively scoped multicast [RFC2365] is provided by two		Administratively scoped multicast [RFC2365] is provided by two
	different means: under 239.0.0.0/8 in IPv4 or by 4-bit encoding in		different means: under 239.0.0.0/8 in IPv4 or by 4-bit encoding in
	the IPv6 multicast address prefix [RFC3513].		the IPv6 multicast address prefix [RFC3513].
	As IPv6 scope-relative allocations can be handled with unicast-		As IPv6 administratively scoped allocations can be handled with
	prefix-based multicast addressing as described in Section 2.1.2, and		unicast-prefix-based multicast addressing as described in
	there is no need for separate scope-relative allocations, we'll just		Section 2.1.2, we'll just discuss IPv4 in this section.
	discuss IPv4 in this section.
	The IPv4 scope-relative prefix 239.0.0.0/8 is further divided to		The IPv4 administratively scoped prefix 239.0.0.0/8 is further
	Local Scope (239.255.0.0/16) and Organization Local Scope		divided to Local Scope (239.255.0.0/16) and Organization Local Scope
	(239.192.0.0/14); other parts of the administrative scopes are either		(239.192.0.0/14); other parts of the administrative scopes are either
	reserved for expansion or undefined [RFC2365]. However, RFC 2365 is		reserved for expansion or undefined [RFC2365]. However, RFC 2365 is
	ambiguous as to whether it's the enterprises or the IETF who are		ambiguous as to whether it's the enterprises or the IETF who are
	allowed to expand the space.		allowed to expand the space.
	Topologies which act under a single administration can easily use the		Topologies which act under a single administration can easily use the
	scoped multicast addresses for their internal groups. Groups which		scoped multicast addresses for their internal groups. Groups which
	need to be shared between multiple routing domains (but not		need to be shared between multiple routing domains (but not
	propagated through the Internet) are more problematic and typically		propagated through the Internet) are more problematic and typically
	need an assignment of a global multicast address because their scope		need an assignment of a global multicast address because their scope
	is undefined.		is undefined.
	There is a large number of multicast applications (such as "Norton		There is a large number of multicast applications (such as "Norton
	Ghost") which are restricted either to a link or a site, and it is		Ghost") which are restricted either to a link or a site, and it is
	extremely undesirable to propagate them further (either to the rest		extremely undesirable to propagate them further (either to the rest
	of the site, or beyond the site). Typically many such applications		of the site, or beyond the site). Typically many such applications
	have been given or have hijacked a static IANA address assignment;		have been given or have hijacked a static IANA address assignment;
	this makes it challenging to implement proper propagation limiting --		this makes it challenging to implement proper propagation limiting --
	which could be easier if such applications could have been assigned		which could be easier if such applications could have been assigned
	specific scope-relative addresses instead. This is an area of		specific administratively scoped addresses instead. This is an area
	further future work.		of further future work.
	There has also been work on a protocol to automatically discover		There has also been work on a protocol to automatically discover
	multicast scope zones [RFC2776], but it has never been widely		multicast scope zones [RFC2776], but it has never been widely
	implemented or deployed.		implemented or deployed.
	2.3. Static IANA Allocation		2.3. Static IANA Allocation
	In some rare cases, some organizations may have been able to obtain		In some rare cases, some organizations may have been able to obtain
	static multicast address allocations (of up to 256 addresses)		static multicast address allocations (of up to 256 addresses)
	directly from IANA. Typically these have been meant as a block of		directly from IANA. Typically these have been meant as a block of
	static assignments to multicast applications, as described in		static assignments to multicast applications, as described in
	Section 3.4. In principle, IANA does not allocate multicast address		Section 3.4.1. In principle, IANA does not allocate multicast
	blocks to the operators but GLOP or Unicast-prefix-based allocations		address blocks to the operators but GLOP or Unicast-prefix-based
	should be used instead.		allocations should be used instead.
	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 7, line 9		skipping to change at page 7, line 9
	below.		below.
	Any IPv6 address assignment method should be aware of the guidelines		Any IPv6 address assignment method should be aware of the guidelines
	for the assignment of the group-IDs for IPv6 multicast addresses		for the assignment of the group-IDs for IPv6 multicast addresses
	[RFC3307].		[RFC3307].
	3.1. Derived Assignment		3.1. Derived Assignment
	There are significantly fewer options for derived address assignment		There are significantly fewer options for derived address assignment
	compared to derived allocation. Derived multicast assignment has		compared to derived allocation. Derived multicast assignment has
	only been specified for IPv6 link-scoped multicast [I-D.ietf-ipv6-		only been specified for IPv6 link-scoped multicast
	link-scoped-mcast], where the EUI64 is embedded in the multicast		[I-D.ietf-ipv6-link-scoped-mcast], where the EUI64 is embedded in the
	address, providing a node with unique multicast addresses for link-		multicast address, providing a node with unique multicast addresses
	local ASM communications.		for link-local ASM communications.
	3.2. SSM Assignment inside the Node		3.2. SSM Assignment inside the Node
	While the SSM multicast addresses have only local (to the node)		While the SSM multicast addresses have only local (to the node)
	significance, there is still a minor issue on how to assign the		significance, there is still a minor issue on how to assign the
	addresses between the applications running on the same node (or more		addresses between the applications running on the same node (or more
	precisely, an IP address).		precisely, an IP address).
	This assignment is not considered to be a problem because typically		This assignment is not considered to be a problem because typically
	the addresses for the applications are selected manually or		the addresses for the applications are selected manually or
	skipping to change at page 7, line 52		skipping to change at page 7, line 52
	or which cannot or do not want to justify a static IANA assignment.		or which cannot or do not want to justify a static IANA assignment.
	The manual assignment works when the number of participants in a		The manual assignment works when the number of participants in a
	group is small, as each participant has to be manually configured.		group is small, as each participant has to be manually configured.
	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 a globally unique assignment		static IANA assignment refers to getting an assignment for the
	for the particular application directly from IANA. Guidelines for		particular application directly from IANA. There are two main forms
	IANA are described in [RFC3171][I-D.ietf-mboned-rfc3171bis].		of IANA assignment: global and scope-relative. Guidelines for IANA
			are described in [RFC3171][I-D.ietf-mboned-rfc3171bis].
	This is seen as lucrative because it's the simplest approach for		3.4.1. Global IANA Assignment
	application developers because they can then hard-code the multicast
	address. Hard-coding requires no lease of the usable multicast		Globally unique address assignment is seen as lucrative because it's
	address, and likewise the client applications do not need to perform		the simplest approach for application developers since they can then
	any kind of service discovery (but depending on hard-coded		hard-code the multicast address. Hard-coding requires no lease of
	addresses). However, there is an architectural scaling problem with		the usable multicast address, and likewise the client applications do
	this approach, as it encourages a "land-grab" of the limited		not need to perform any kind of service discovery (but depending on
	multicast address space.		hard-coded addresses). However, there is an architectural scaling
			problem with this approach, as it encourages a "land-grab" of the
			limited multicast address space.
	[RFC3138] describes how to handle those GLOP assignments (called		[RFC3138] describes how to handle those GLOP assignments (called
	"eGLOP") which use the private-use AS number space (233.252.0.0/14).		"eGLOP") which use the private-use AS number space (233.252.0.0/14).
	It was envisioned that IANA would delegate the responsibility of		It was envisioned that IANA would delegate the responsibility of
	these to RIRs, which would assign or allocate addresses as best		these to RIRs, which would assign or allocate addresses as best
	seemed fit. However, this was never carried out as IANA did not make		seemed fit. However, this was never carried out as IANA did not make
	these allocations to RIRs due to procedural reasons.		these allocations to RIRs due to procedural reasons.
	In summary, there are applications which have obtained a static IANA		In summary, there are applications which have obtained a global
	assignment and while some of which are really needed, some of which		static IANA assignment and while some of which are really needed,
	probably should not have been granted. Conversely, there are some		some of which probably should not have been granted. Conversely,
	applications that have not obtained a static IANA assignment, yet		there are some applications that have not obtained a static IANA
	should have requested an assignment and been granted one.		assignment, yet should have requested an assignment and been granted
			one.
			3.4.2. Scope-relative IANA Assignment
			IANA also assigns numbers as an integer offset from the highest
			address in each IPv4 administrative scope as described in [RFC2365].
			For example, the SLPv2 discovery scope-relative offset is "2", so
			SLPv2 discovery address within IPv4 Local-Scope (239.255.0.0/16) is
			"239.255.255.253", within the IPv4 Organization Local-Scope
			(239.192.0.0/14) it is "239.195.255.253", and so on.
			Similar scope-relative assignments also exist with IPv6 [RFC2375].
			As IPv6 multicast addresses have much more flexible scoping, scope-
			relative assignments are also applicable to global scopes. The
			assignment policies are described in [RFC3307].
	3.5. Dynamic Assignments		3.5. Dynamic Assignments
	The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from		The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from
	Multicast Address Allocation Servers (MAAS) to applications and		Multicast Address Allocation Servers (MAAS) to applications and
	nodes, with Multicast Address Dynamic Client Allocation Protocol		nodes, with Multicast Address Dynamic Client Allocation Protocol
	(MADCAP) [RFC2730] as an example. Since then, there has been a		(MADCAP) [RFC2730] as an example. Since then, there has been a
	proposal for DHCPv6 assignment [I-D.jdurand-assign-addr-ipv6-		proposal for DHCPv6 assignment
	multicast-dhcpv6].		[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6].
	It would be rather straightforward to deploy a dynamic assignment		It would be rather straightforward to deploy a dynamic assignment
	protocol which would lease group addresses based on a multicast		protocol which would lease group addresses based on a multicast
	prefix to the applications wishing to use multicast. For example,		prefix to the applications wishing to use multicast. For example,
	only few have implemented MADCAP, and it's not significantly		only few have implemented MADCAP, and it's not significantly
	deployed. Moreover, it is not clear how widely for example the APIs		deployed. Moreover, it is not clear how widely for example the APIs
	for communication between the multicast application and the MADCAP		for communication between the multicast application and the MADCAP
	client operating at the host have been implemented [RFC2771].		client operating at the host have been implemented [RFC2771].
	An entirely different approach is Session Announcement Protocol (SAP)		An entirely different approach is Session Announcement Protocol (SAP)
	skipping to change at page 9, line 39		skipping to change at page 10, line 14
	4.1. Prefix Allocation		4.1. Prefix Allocation
	Summary of prefix allocation methods for ASM is in Figure 1.		Summary of prefix allocation methods for ASM is in Figure 1.
	+-------+--------------------------------+--------+--------+		+-------+--------------------------------+--------+--------+
	| Sect. | Prefix allocation method | IPv4 | IPv6 |		| Sect. | Prefix allocation method | IPv4 | IPv6 |
	+-------+--------------------------------+--------+--------+		+-------+--------------------------------+--------+--------+
	| 2.1.1 | Derived: GLOP | Yes | NoNeed*|		| 2.1.1 | Derived: GLOP | Yes | NoNeed*|
	| 2.1.2 | Derived: Unicast-prefix-based |No -yet | Yes |		| 2.1.2 | Derived: Unicast-prefix-based |No -yet | Yes |
	| 2.2 | Separate Scope-relative | Yes | NoNeed*|		| 2.2 | Administratively scoped | Yes | NoNeed*|
	| 2.3 | Static IANA allocation | No | No |		| 2.3 | Static IANA allocation | No | No |
	| 2.4 | Dynamic allocation protocols | No | No |		| 2.4 | Dynamic allocation protocols | No | No |
	+-------+--------------------------------+--------+--------+		+-------+--------------------------------+--------+--------+
	* = the need satisfied by IPv6 unicast-prefix-based allocation.		* = the need satisfied by IPv6 unicast-prefix-based allocation.
	Figure 1		Figure 1
	o Only ASM is affected by the assignment/allocation issues (however,		o Only ASM is affected by the assignment/allocation issues (however,
	both ASM and SSM have roughly the same address discovery issues).		both ASM and SSM have roughly the same address discovery issues).
	o GLOP allocations seem to provide a sufficient IPv4 multicast		o GLOP allocations seem to provide a sufficient IPv4 multicast
	allocation mechanism for now, but could be extended in future.		allocation mechanism for now, but could be extended in future.
	Scope-relative allocations provide the opportunity for internal		Administratively scoped allocations provide the opportunity for
	IPv4 allocations.		internal IPv4 allocations.
	o Unicast-prefix-based addresses and the derivatives provide good		o Unicast-prefix-based addresses and the derivatives provide good
	allocation strategy with IPv6, also for scoped multicast		allocation strategy with IPv6, also for scoped multicast
	addresses.		addresses.
	o Dynamic allocations are a too complex and unnecessary mechanism.		o Dynamic allocations are a too complex and unnecessary mechanism.
	o Static IANA allocations are generally an architecturally		o Static IANA allocations are generally an architecturally
	unacceptable approach.		unacceptable approach.
	4.2. Address Assignment		4.2. Address Assignment
	Summary of address assignment methods is in Figure 2.		Summary of address assignment methods is in Figure 2.
	+-------+--------------------------------+----------+----------+		+--------+--------------------------------+----------+----------+
	| Sect. | Address assignment method | IPv4 | IPv6 |		| Sect. | Address assignment method | IPv4 | IPv6 |
	+-------+--------------------------------+----------+----------+		+--------+--------------------------------+----------+----------+
	| 3.1 | Derived: link-scope addresses | No | Yes |		| 3.1 | Derived: link-scope addresses | No | Yes |
	| 3.2 | SSM (inside the node) | Yes | Yes |		| 3.2 | SSM (inside the node) | Yes | Yes |
	| 3.3 | Manual assignment | Yes | Yes |		| 3.3 | Manual assignment | Yes | Yes |
	| 3.4 | Static IANA/RIR assignment |LastResort|LastResort|		| 3.4.1 | Global IANA/RIR assignment |LastResort|LastResort|
			| 3.4.2 | Scope-relative IANA assignment | Yes | Yes |
	| 3.5 | Dynamic assignment protocols | Yes | Yes |		| 3.5 | Dynamic assignment protocols | Yes | Yes |
	+-------+--------------------------------+----------+----------+		+--------+--------------------------------+----------+----------+
	Figure 2		Figure 2
	o Manually configured assignment is what's typically done today, and		o Manually configured assignment is what's typically done today, and
	works to a sufficient degree in smaller scale.		works to a sufficient degree in smaller scale.
	o Static IANA assignment has been done extensively in the past, but		o Global IANA assignment has been done extensively in the past, but
	it needs to be tightened down to prevent problems caused by "land-		it needs to be tightened down to prevent problems caused by "land-
	grabbing".		grabbing". Scope-relative IANA assignment is acceptable but the
			size of the pool is not very high. Inter-domain routing of IPv6
			IANA-assigned prefixes is likely going to be challenging.
	o Dynamic assignment, e.g., MADCAP has been implemented, but there		o Dynamic assignment, e.g., MADCAP has been implemented, but there
	is no wide deployment, so a solution is there. However, either		is no wide deployment, so a solution is there. However, either
	there are other gaps in the multicast architecture or there is no		there are other gaps in the multicast architecture or there is no
	sufficient demand for it in the first place when manual and static		sufficient demand for it in the first place when manual and static
	IANA assignments are available. Assignments using SAP also exist		IANA assignments are available. Assignments using SAP also exist
	but are not common; global SAP assignment is unfeasible with IPv6.		but are not common; global SAP assignment is unfeasible with IPv6.
	o Derived assignments are only applicable in a fringe case of link-		o Derived assignments are only applicable in a fringe case of link-
	scoped multicast.		scoped multicast.
	skipping to change at page 11, line 18		skipping to change at page 12, line 6
	more length, and an adequate solution provided; the result also		more length, and an adequate solution provided; the result also
	needs to be written down to be shown to the IANA static assignment		needs to be written down to be shown to the IANA static assignment
	requestors. See [I-D.ietf-mboned-addrdisc-problems] for more.		requestors. See [I-D.ietf-mboned-addrdisc-problems] for more.
	o IPv6 multicast DAD and/or multicast prefix communication		o IPv6 multicast DAD and/or multicast prefix communication
	mechanisms should be analyzed (e.g.,		mechanisms should be analyzed (e.g.,
	[I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not,		[I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not,
	and specify if yes.		and specify if yes.
	o The IETF should consider whether to specify more ranges of the		o The IETF should consider whether to specify more ranges of the
	IPv4 scope-relative address space for static allocation for		IPv4 administratively scoped address space for static allocation
	applications which should not be routed over the Internet (such as		for applications which should not be routed over the Internet
	backup software, etc. -- so that these wouldn't need to use global		(such as backup software, etc. -- so that these wouldn't need to
	addresses which should never leak in any case).		use global addresses which should never leak in any case).
	o The IETF should seriously consider its static IANA allocations		o The IETF should seriously consider its static IANA allocations
	policy, e.g., "locking it down" to a stricter policy (like "IETF		policy, e.g., "locking it down" to a stricter policy (like "IETF
	Consensus") and looking at developing the discovery/rendezvous		Consensus") and looking at developing the discovery/rendezvous
	functions, if necessary.		functions, if necessary.
	5. Acknowledgements		5. Acknowledgements
	Tutoring a couple multicast-related papers, the latest by Kaarle		Tutoring a couple multicast-related papers, the latest by Kaarle
	Ritvanen [RITVANEN] convinced the author that the up-to-date		Ritvanen [RITVANEN] convinced the author that the up-to-date
	multicast address assignment/allocation documentation is necessary.		multicast address assignment/allocation documentation is necessary.
	Multicast address allocations/assignments were discussed at the		Multicast address allocations/assignments were discussed at the
	MBONED WG session at IETF59 [MBONED-IETF59].		MBONED WG session at IETF59 [MBONED-IETF59].
	Dave Thaler, James Lingard, and Beau Williamson provided useful		Dave Thaler, James Lingard, and Beau Williamson provided useful
	feedback for the preliminary version of this memo. Myung-Ki Shin,		feedback for the preliminary version of this memo. Myung-Ki Shin,
	Jerome Durand, and John Kristoff also suggested improvements.		Jerome Durand, John Kristoff, and Dave Price also suggested
			improvements.
	6. IANA Considerations		6. IANA Considerations
	This memo includes no request to IANA, but as the allocation and		This memo includes no request to IANA, but as the allocation and
	assignment of multicast addresses are related to IANA functions, it		assignment of multicast addresses are related to IANA functions, it
	wouldn't hurt if the IANA reviewed this entire memo.		wouldn't hurt if the IANA reviewed this entire memo.
	IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still		IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still
	apply to the administratively scoped prefixes.		apply to the administratively scoped prefixes.
	IANA may be interested in reviewing the accuracy of the statement on		IANA may be interested in reviewing the accuracy of the statement on
	eGLOP address assignments in Section 3.4.		eGLOP address assignments in Section 3.4.1.
	(RFC-editor: please remove this section at publication.)		(RFC-editor: please remove this section at publication.)
	7. Security Considerations		7. Security Considerations
	This memo only describes different approaches to allocating and		This memo only describes different approaches to allocating and
	assigning multicast addresses, and this has no security		assigning multicast addresses, and this has no security
	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.
	skipping to change at page 13, line 18		skipping to change at page 14, line 7
	RFC 3956, November 2004.		RFC 3956, November 2004.
	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-00		Problem Space", draft-ietf-mboned-addrdisc-problems-01
	(work in progress), March 2005.		(work in progress), November 2005.
	[I-D.ietf-mboned-ipv4-uni-based-mcast]		[I-D.ietf-mboned-ipv4-uni-based-mcast]
	Thaler, D., "Unicast-Prefix-based IPv4 Multicast		Thaler, D., "Unicast-Prefix-based IPv4 Multicast
	Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-02		Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-02
	(work in progress), October 2004.		(work in progress), October 2004.
	[I-D.ietf-mboned-rfc3171bis]		[I-D.ietf-mboned-rfc3171bis]
	Albanna, Z., Almeroth, K., Cotton, M., and D. Meyer, "IANA		Albanna, Z., Almeroth, K., Cotton, M., and D. Meyer, "IANA
	Guidelines for IPv4 Multicast Address Assignments",		Guidelines for IPv4 Multicast Address Assignments",
	draft-ietf-mboned-rfc3171bis-02 (work in progress),		draft-ietf-mboned-rfc3171bis-02 (work in progress),
	skipping to change at page 13, line 51		skipping to change at page 14, line 40
	draft-jdurand-ipv6-multicast-ra-00 (work in progress),		draft-jdurand-ipv6-multicast-ra-00 (work in progress),
	February 2005.		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>.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
	RFC 2131, March 1997.		RFC 2131, March 1997.
			[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
			Assignments", RFC 2375, July 1998.
	[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,		[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
	"Service Location Protocol, Version 2", RFC 2608,		"Service Location Protocol, Version 2", RFC 2608,
	June 1999.		June 1999.
	[RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address		[RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address
	Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,		Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
	December 1999.		December 1999.
	[RFC2771] Finlayson, R., "An Abstract API for Multicast Address		[RFC2771] Finlayson, R., "An Abstract API for Multicast Address
	Allocation", RFC 2771, February 2000.		Allocation", RFC 2771, February 2000.
	skipping to change at page 15, line 8		skipping to change at page 15, line 44
	(To be removed prior to publication as an RFC.)		(To be removed prior to publication as an RFC.)
	A.1. Changes since -01		A.1. Changes since -01
	o Mention the mechanisms which haven't been so succesful: eGLOP and		o Mention the mechanisms which haven't been so succesful: 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 scope-relative address space and the expansion		o Add a note on administraively scoped address space and the
	ambiguity.		expansion ambiguity.
	o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt		o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt
	o Minor editorial cleanups.		o Minor editorial cleanups.
	Author's Address		Author's Address
	Pekka Savola		Pekka Savola
	CSC - Scientific Computing Ltd.		CSC - Scientific Computing Ltd.
	Espoo		Espoo
	Finland		Finland
	Email: psavola@funet.fi		Email: psavola@funet.fi
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	skipping to change at page 16, line 20		skipping to change at page 17, line 47
	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		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 38 change blocks.
	75 lines changed or deleted		103 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/