draft-ietf-mboned-addrarch-05.txt		draft-ietf-mboned-addrarch-06.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 October 16, 2006		Obsoletes: 2908 (if approved) August 3, 2009
	(if approved)		Intended status: Informational
	Intended status: Best Current		Expires: February 4, 2010
	Practice
	Expires: April 19, 2007
	Overview of the Internet Multicast Addressing Architecture		Overview of the Internet Multicast Addressing Architecture
	draft-ietf-mboned-addrarch-05.txt		draft-ietf-mboned-addrarch-06.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	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.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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		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 19, 2007.		This Internet-Draft will expire on February 4, 2010.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents in effect on the date of
			publication of this document (http://trustee.ietf.org/license-info).
			Please review these documents carefully, as they describe your rights
			and restrictions with respect to this document.
	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. 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 . . . . . . . . . . . . . . . . . 6		3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 7
	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 . . . . . . . . . . . . . . . . . . . 9		3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8
	4. Summary and Future Directions . . . . . . . . . . . . . . . . 10		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 -04 and -05 . . . . . . . . . . . . . . . 15		A.1. Changes between -05 and -06 . . . . . . . . . . . . . . . 15
	A.2. Changes between -03 and -04 . . . . . . . . . . . . . . . 16		A.2. Changes between -04 and -05 . . . . . . . . . . . . . . . 15
	A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 16		A.3. Changes between -03 and -04 . . . . . . . . . . . . . . . 16
	A.4. Changes between -01 and -02 . . . . . . . . . . . . . . . 16		A.4. Changes between -02 and -03 . . . . . . . . . . . . . . . 16
			A.5. Changes between -01 and -02 . . . . . . . . . . . . . . . 16
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
	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 about IP		[RFC2908]. The consequence is that those who wish to learn about 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 3, line 26		skipping to change at page 3, line 26
	The aim of this document is to provide a brief overview of multicast		The aim of this document is to provide a brief overview of multicast
	addressing and allocation techniques. The term 'addressing		addressing and allocation techniques. The term 'addressing
	architecture' refers to the set of addressing mechanisms and methods		architecture' refers to the set of addressing mechanisms and methods
	in an informal manner.		in an informal manner.
	It is important to note that Source-specific Multicast (SSM)		It is important to note that Source-specific Multicast (SSM)
	[RFC4607] does not have these addressing problems because SSM group		[RFC4607] does not have these addressing problems because SSM group
	addresses have only local significance; hence, this document focuses		addresses have only local significance; hence, this document focuses
	on the Any Source Multicast (ASM) model.		on the Any Source Multicast (ASM) model.
	This memo obsoletes RFCs 2776, 2908, and 2909 and re-classifies them		This memo obsoletes and re-classifies to Historic RFC 2908, and re-
	Historic.		classifies to Historic RFCs 2776 and 2909.
	1.1. Terminology: Allocation or Assignment		1.1. Terminology: Allocation or Assignment
	Almost all multicast documents and many other RFCs (such as DHCPv4		Almost all multicast documents and many other RFCs (such as DHCPv4
	[RFC2131] and DHCPv6 [RFC3315]) have used the terms address		[RFC2131] and DHCPv6 [RFC3315]) have used the terms address
	"allocation" and "assignment" interchangeably. However, the operator		"allocation" and "assignment" interchangeably. However, the operator
	and address management communities use these terms for two		and address management communities use these terms for two
	conceptually different processes.		conceptually different processes.
	In unicast operations, address allocations refer to leasing a large		In unicast operations, address allocations refer to leasing a large
	skipping to change at page 4, line 37		skipping to change at page 4, line 37
	sufficient for multicast testing or small scale use, it might not be		sufficient for multicast testing or small scale use, it might not be
	sufficient in all cases for extensive multicast use.		sufficient in all cases for extensive multicast use.
	A minor operational debugging issue with GLOP addresses is that the		A minor operational debugging issue with GLOP addresses is that the
	connection between the AS and the prefix is not apparent from the		connection between the AS and the prefix is not apparent from the
	prefix when the AS number is greater than 255, but has to be		prefix when the AS number is greater than 255, but has to be
	calculated (e.g., from [RFC3180], AS 5662 maps to 233.22.30.0/24). A		calculated (e.g., from [RFC3180], AS 5662 maps to 233.22.30.0/24). A
	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.
	GLOP allocation algorithm has not been defined for IPv6 multicast		GLOP mapping is not available with 4-byte AS numbers [RFC4893].
			Unicast-prefix-based Allocation or an IANA allocation from "AD-HOC
			Block III" (the previous so-called "eGLOP" block) could be used
			instead as needed.
			The GLOP allocation algorithm has not been defined for IPv6 multicast
	because the unicast-prefix -based allocation (described below)		because the unicast-prefix -based allocation (described below)
	addresses the same need in a simpler fashion. GLOP hasn't been (and		addresses the same need in a simpler fashion.
	likely never will be) specified for 4-byte AS numbers
	[I-D.ietf-idr-as4bytes].
	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 mapping has been proposed for IPv4		A similar IPv4 mapping is described in
	[I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a rather low		[I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a limited
	amount of addresses (e.g., 1 per an IPv4 /24 block). Although large		number of addresses (e.g., 1 per an IPv4 /24 block).
	networks without an AS number do exist, this technique has not been
	seen to add 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, 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 [RFC3513], 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
	interface identifier of the PIM-SM Rendezvous Point (RP) in the		interface identifier of the PIM-SM Rendezvous Point (RP) in the
	prefix. This provides all the necessary information needed to the		prefix. This provides all the necessary information needed to the
	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 from RFC 3306 is, however, that the hosts		operation. A difference from 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,		prefix depends on the decisions of the operator setting up the RP,
	but instead requires an assignment method.		but instead 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 network operators.
	operators.
	2.2. Administratively Scoped Allocation		2.2. Administratively Scoped Allocation
	Administratively scoped multicast address allocation [RFC2365] is		Administratively scoped multicast address allocation [RFC2365] is
	provided by two different means: under 239.0.0.0/8 in IPv4 or by		provided by two different means: under 239.0.0.0/8 in IPv4 or by
	4-bit encoding in the IPv6 multicast address prefix [RFC3513].		4-bit encoding in the IPv6 multicast address prefix [RFC4291].
	Since IPv6 administratively scoped allocations can be handled with		Since IPv6 administratively scoped allocations can be handled with
	unicast-prefix-based multicast addressing as described in		unicast-prefix-based multicast addressing as described in
	Section 2.1.2, we'll just discuss IPv4 in this section.		Section 2.1.2, we'll only discuss IPv4 in this section.
	The IPv4 administratively scoped prefix 239.0.0.0/8 is further		The IPv4 administratively scoped prefix 239.0.0.0/8 is further
	divided to Local Scope (239.255.0.0/16) and Organization Local Scope		divided into Local Scope (239.255.0.0/16) and Organization Local
	(239.192.0.0/14); other parts of the administrative scopes are either		Scope (239.192.0.0/14); other parts of the administrative scopes are
	reserved for expansion or undefined [RFC2365]. However, RFC 2365 is		either reserved for expansion or undefined [RFC2365]. However, RFC
	ambiguous as to whether the enterprises or the IETF are allowed to		2365 is ambiguous as to whether the enterprises or the IETF are
	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 (even if not		need to be shared between multiple routing domains (even if 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 (beyond the link or		extremely undesirable to propagate them further (beyond the link or
	the site). Typically many such applications have been given or have		the site). Typically many such applications have been given or have
	hijacked a static IANA address assignment. The fact that assignments		hijacked a static IANA address assignment. Given the fact that
	to typically locally used applications come from the same range as		assignments to typically locally used applications come from the same
	global applications, implementing proper propagation limiting is		range as global applications, implementing proper propagation
	challenging. Filtering would be easier if such applications would in		limiting is challenging. Filtering would be easier if a separate,
	future be assigned specific administratively scoped addresses		identifiable range would be used for such assignments in the future;
	instead. This is an area of further future work.		this is an area 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, organizations may have been able to obtain static
	static multicast address allocations (of up to 256 addresses)		multicast address allocations (of up to 256 addresses) directly from
	directly from IANA. Typically these have been meant as a block of		IANA. Typically these have been meant as a block of static
	static assignments to multicast applications, as described in		assignments to multicast applications, as described in Section 3.4.1.
	Section 3.4.1. In principle, IANA should not and does not allocate		If another means of obtaining addresses is available that approach is
	multicast address blocks to the operators but GLOP or Unicast-prefix-		preferable.
	based allocations should be used instead.
			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
			previous so-called "eGLOP" block) is an option
			[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 7, line 6		skipping to change at page 7, line 11
	It can be concluded that dynamic multicast address allocation		It can be concluded that dynamic multicast address allocation
	protocols provide no benefit beyond GLOP/unicast-prefix-based		protocols provide no benefit beyond GLOP/unicast-prefix-based
	mechanisms and have been abandoned.		mechanisms and have been abandoned.
	3. Multicast Address Assignment		3. Multicast Address Assignment
	There are a number of possible ways for an application, node or set		There are a number of possible ways for an application, node or set
	of nodes to learn a multicast address as described below.		of nodes to learn a multicast address as described 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 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 [RFC4489], where		only been specified for IPv6 link-scoped multicast [RFC4489], where
	the EUI64 is embedded in the multicast address, providing a node with		the EUI64 is embedded in the multicast address, providing a node with
	unique multicast addresses for link-local ASM communications.		unique multicast addresses 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 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 IP address.		addresses between the applications running on the same 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 these applications are selected manually or
	statically, but if done using an Application Programming Interface		statically, but if done using an Application Programming Interface
	(API), the API could check that the addresses do not conflict prior		(API), the API could check that the addresses do not conflict prior
	to assigning one.		to assigning one.
	3.3. Manually Configured Assignment		3.3. Manually Configured Assignment
	With manually configured assignment, the network operator who has a		With manually configured assignment, a network operator who has a
	multicast address prefix assigns the multicast group addresses to the		multicast address prefix assigns the multicast group addresses to the
	requesting nodes using a manual process.		requesting nodes using a manual process.
	Typically the user or administrator which wants to use a multicast		Typically, the user or administrator that wants to use a multicast
	address for particular application requests an address from the		address for a particular application requests an address from the
	network operator using phone, email, or similar means, and the		network operator using phone, email, or similar means, and the
	network operator provides the user with a multicast address. Then		network operator provides the user with a multicast address. Then
	the user/administrator of the node or application manually configures		the user/administrator of the node or application manually configures
	the application to use the assigned multicast address.		the application to use the assigned multicast address.
	This is a relatively simple process; it has been sufficient for		This is a relatively simple process; it has been sufficient for
	certain applications which require manual configuration in any case,		certain applications which require manual configuration in any case,
	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 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 [RFC3171][I-D.ietf-mboned-rfc3171bis].		are described in [I-D.ietf-mboned-rfc3171bis].
	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
	limited multicast address space.		limited multicast address space.
	[RFC3138] describes how to handle those GLOP assignments (called
	"eGLOP") which use the private-use AS number space (233.252.0.0/14).
	It was envisioned that IANA would delegate the responsibility of
	these to RIRs, which would assign or allocate addresses as best
	seemed fit. However, this was never carried out as IANA did not make
	these allocations to RIRs due to procedural reasons.
	In summary, there are applications which have obtained a global
	static IANA assignment and while some of the assignments were really
	needed, others probably should not have been granted. Conversely,
	there are some applications that have not obtained a static IANA
	assignment, yet should have requested an assignment and been granted
	one.
	3.4.2. Scope-relative IANA Assignment		3.4.2. Scope-relative IANA Assignment
	IANA also assigns numbers as an integer offset from the highest		IANA also assigns numbers as an integer offset from the highest
	address in each IPv4 administrative scope as described in [RFC2365].		address in each IPv4 administrative scope as described in [RFC2365].
	For example, the SLPv2 discovery scope-relative offset is "2", so		For example, the SLPv2 discovery scope-relative offset is "2", so
	SLPv2 discovery address within IPv4 Local-Scope (239.255.0.0/16) is		SLPv2 discovery address within IPv4 Local-Scope (239.255.0.0/16) is
	"239.255.255.253", within the IPv4 Organization Local-Scope		"239.255.255.253", within the IPv4 Organization Local-Scope
	(239.192.0.0/14) it is "239.195.255.253", and so on.		(239.192.0.0/14) it is "239.195.255.253", and so on.
	Similar scope-relative assignments also exist with IPv6 [RFC2375].		Similar scope-relative assignments also exist with IPv6 [RFC2375].
	As IPv6 multicast addresses have much more flexible scoping, scope-		As IPv6 multicast addresses have much more flexible scoping, scope-
	relative assignments are also applicable to global scopes. The		relative assignments are also applicable to global scopes. The
	assignment policies are described in [RFC3307].		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, other mechanisms have
	proposal for DHCPv6 assignment		also been proposed (e.g., DHCPv6 assignment
	[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6].		[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]) but these have not
			gained traction.
	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. However, only		prefix to applications wishing to use multicast. However, only few
	few have implemented MADCAP, and it hasn't been significantly		have implemented MADCAP, and it hasn't been significantly deployed.
	deployed. So, it is not clear if the lack of deployment is due to a		So, it is not clear if the lack of deployment is due to a currently
	currently missing need. Moreover, it is not clear how widely for		missing need. Moreover, it is not clear how widely for example the
	example the APIs for communication between the multicast application		APIs for communication between the multicast application and the
	and the MADCAP client operating at the host have been implemented		MADCAP client operating at the host have been implemented [RFC2771].
	[RFC2771].
	An entirely different approach is Session Announcement Protocol (SAP)		An entirely different approach is Session Announcement Protocol (SAP)
	[RFC2974]. In addition to advertising global multicast sessions, the		[RFC2974]. In addition to advertising global multicast sessions, the
	protocol also has associated ranges of addresses for both IPv4 and		protocol also has associated ranges of addresses for both IPv4 and
	IPv6 which can be used by SAP-aware applications to create new groups		IPv6 which can be used by SAP-aware applications to create new groups
	and new group addresses. Creating a session (and obtaining an		and new group addresses. Creating a session (and obtaining an
	address) is a rather tedious process which is why it isn't done all		address) is a rather tedious process which is why it isn't done all
	that often. (Note that the IPv6 SAP address is unroutable in the		that often. It is also worth noting that the IPv6 SAP address is
	inter-domain multicast.)		unroutable in the inter-domain multicast.
	A conclusion about dynamic assignment protocols is that:		A conclusion about dynamic assignment protocols is that:
	1. multicast is not significantly attractive in the first place,		1. multicast is not significantly attractive in the first place,
	2. most applications have a static IANA assignment and thus require		2. most applications have a static IANA assignment and thus require
	no dynamic or manual assignment,		no dynamic or manual assignment,
	3. those that cannot be easily satisfied with IANA or manual		3. those that cannot be easily satisfied with IANA or manual
	assignment (i.e., where dynamic assignment would be desirable)		assignment (i.e., where dynamic assignment would be desirable)
	skipping to change at page 10, line 12		skipping to change at page 10, line 7
	In consequence, more work on rendezvous/service discovery would be		In consequence, more work on rendezvous/service discovery would be
	needed to make dynamic assignments more useful.		needed to make dynamic assignments more useful.
	4. Summary and Future Directions		4. Summary and Future Directions
	This section summarizes the mechanisms and analysis discussed in this		This section summarizes the mechanisms and analysis discussed in this
	memo, and presents some potential future directions.		memo, and presents some potential future directions.
	4.1. Prefix Allocation		4.1. Prefix Allocation
	Summary of prefix allocation methods for ASM is in Figure 1.		A summary of prefix allocation methods for ASM is shown 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 | Yes |		| 2.1.2 | Derived: Unicast-prefix-based | No | Yes |
	| 2.2 | Administratively scoped | Yes | NoNeed*|		| 2.2 | Administratively scoped | Yes | NoNeed*|
	| 2.3 | Static IANA allocation | No | No |		| 2.3 | Static IANA allocation | Yes** | 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.
			** = mainly using the AD-HOC block III (former "eGLOP")
	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.
	both ASM and SSM have roughly the same address discovery issues).
	o GLOP allocations seem to provide a sufficient IPv4 multicast
	allocation mechanism for now, but could be extended in future.
	Administratively scoped allocations provide the opportunity for
	internal IPv4 allocations.
	o Unicast-prefix-based addresses and the derivatives provide good		o With IPv4, GLOP allocations provide a sufficient IPv4 multicast
	allocation strategy with IPv6, also for scoped multicast		allocation mechanism for those that have 16-bit AS number. IPv4
	addresses.		unicast-prefix based allocation offers some addresses. IANA is
			also allocating from the AD-HOC block III (former "eGLOP") with
			especially 32-bit AS number holders in mind. Administratively
			scoped allocations provide the opportunity for internal IPv4
			allocations.
	o Dynamic allocations are a too complex and unnecessary mechanism.		o With IPv6, unicast-prefix-based addresses and the derivatives
			provide a good allocation strategy and this also works for scoped
			multicast addresses.
	o Static IANA allocations are generally an architecturally		o Dynamic allocations are too complex and unnecessary a mechanism.
	unacceptable approach.
	4.2. Address Assignment		4.2. Address Assignment
	Summary of address assignment methods is in Figure 2.		A summary of address assignment methods is shown 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.1 | Global IANA/RIR assignment |LastResort|LastResort|		| 3.4.1 | Global IANA/RIR assignment |LastResort|LastResort|
	| 3.4.2 | Scope-relative IANA assignment | Yes | Yes |		| 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 typical today, and works to a
	works to a sufficient degree in smaller scale.		sufficient degree in smaller scale.
	o Global IANA assignment has been done extensively in the past, but		o Global IANA assignment has been done extensively in the past.
	it needs to be tightened down to prevent problems caused by "land-		Scope-relative IANA assignment is acceptable but the size of the
	grabbing". Scope-relative IANA assignment is acceptable but the		pool is not very high. Inter-domain routing of IPv6 IANA-assigned
	size of the pool is not very high. Inter-domain routing of IPv6		prefixes is likely going to be challenging and as a result that
	IANA-assigned prefixes is likely going to be challenging.		approach is not very appealing.
	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, either there are other gaps in the		is no wide deployment. Therefore, either there are other gaps in
	multicast architecture or there is no sufficient demand for it in		the multicast architecture or there is no sufficient demand for it
	the first place when manual and static IANA assignments are		in the first place when manual and static IANA assignments are
	available. Assignments using SAP also exist but are not common;		available. Assignments using SAP also exist but are not common;
	global SAP assignment is unfeasible with IPv6.		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.
	4.3. Future Actions		4.3. Future Actions
	o Multicast address discovery/"rendezvous" needs to be analyzed at		o Multicast address discovery/"rendezvous" needs to be analyzed at
	more length, and an adequate solution provided; the result also		more length, and an adequate solution provided. See
	needs to be written down to be shown to the IANA static assignment		[I-D.ietf-mboned-addrdisc-problems] and
	requestors. See [I-D.ietf-mboned-addrdisc-problems] for more.		[I-D.ietf-mboned-session-announcement-req] for more.
	o IPv6 multicast DAD and/or multicast prefix communication
	mechanisms should be analyzed (e.g.,
	[I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not,
	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 administratively scoped address space for static allocation		IPv4 administratively scoped address space for static allocation
	for applications which should not be routed over the Internet		for applications which should not be routed over the Internet
	(such as backup software, etc. -- so that these wouldn't need to		(such as backup software, etc. -- so that these wouldn't need to
	use global 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 consider its static IANA allocations policy, e.g.,
	policy, e.g., "locking it down" to a stricter policy (like "IETF		"locking it down" to a stricter policy (like "IETF Consensus") and
	Consensus") and looking at developing the discovery/rendezvous		looking at developing the discovery/rendezvous functions, if
	functions, if necessary.		necessary.
	5. Acknowledgements		5. Acknowledgements
	Tutoring a couple multicast-related papers, the latest by Kaarle		Tutoring a couple of multicast-related papers, the latest by Kaarle
	Ritvanen [RITVANEN] convinced the author that updated multicast		Ritvanen [RITVANEN] convinced the author that updated multicast
	address assignment/allocation documentation is needed.		address assignment/allocation documentation is needed.
	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, John Kristoff, Dave Price, and Spencer Dawkins also		Jerome Durand, John Kristoff, Dave Price, Spencer Dawkins, and Alfred
	suggested improvements.		Hoenes 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.
	assignment of multicast addresses are related to IANA functions, it
	wouldn't hurt if the IANA reviewed this entire memo.
	IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still
	apply to the administratively scoped prefixes.
	IANA may be interested in reviewing the accuracy of the statement on		IANA considerations in sections 4.1.1 and 4.1.2 of obsoleted and now
	eGLOP address assignments in Section 3.4.1.		Historic [RFC2908] were never implemented in IANA registry. No
			update is necessary.
	(RFC-editor: please remove this section at publication.)		(RFC-editor: This section may be removed prior to publication;
			alternatively, the second paragraph may be left intact.)
	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.
	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.
	[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
	"IANA Guidelines for IPv4 Multicast Address Assignments",
	BCP 51, RFC 3171, August 2001.
	[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
	Addresses", RFC 3307, August 2002.		Addresses", RFC 3307, August 2002.
	[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
	(IPv6) Addressing Architecture", RFC 3513, April 2003.
	[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous		[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
	Point (RP) Address in an IPv6 Multicast Address",		Point (RP) Address in an IPv6 Multicast Address",
	RFC 3956, November 2004.		RFC 3956, November 2004.
			[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
			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.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-idr-as4bytes]
	Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
	Number Space", draft-ietf-idr-as4bytes-12 (work in
	progress), November 2005.
	[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-ipv4-uni-based-mcast]		[I-D.ietf-mboned-session-announcement-req]
	Thaler, D., "Unicast-Prefix-based IPv4 Multicast		Asaeda, H. and V. Roca, "Requirements for IP Multicast
	Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-02		Session Announcement in the Internet",
	(work in progress), October 2004.		draft-ietf-mboned-session-announcement-req-01 (work in
			progress), March 2009.
	[I-D.ietf-mboned-rfc3171bis]
	Albanna, Z., Almeroth, K., Cotton, M., and D. Meyer, "IANA
	Guidelines for IPv4 Multicast Address Assignments",
	draft-ietf-mboned-rfc3171bis-02 (work in progress),
	March 2004.
	[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.
	[I-D.jdurand-ipv6-multicast-ra]
	Durand, J. and P. Savola, "Route Advertisement Option for
	IPv6 Multicast Prefixes",
	draft-jdurand-ipv6-multicast-ra-00 (work 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>.
	[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		[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
	Assignments", RFC 2375, July 1998.		Assignments", RFC 2375, July 1998.
	[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
	"Service Location Protocol, Version 2", RFC 2608,
	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.
	[RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope		[RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope
	Zone Announcement Protocol (MZAP)", RFC 2776,		Zone Announcement Protocol (MZAP)", RFC 2776,
	February 2000.		February 2000.
	skipping to change at page 15, line 23		skipping to change at page 14, line 50
	Multicast Address Allocation Architecture", RFC 2908,		Multicast Address Allocation Architecture", RFC 2908,
	September 2000.		September 2000.
	[RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M.,		[RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M.,
	Kumar, S., and D. Thaler, "The Multicast Address-Set Claim		Kumar, S., and D. Thaler, "The Multicast Address-Set Claim
	(MASC) Protocol", RFC 2909, September 2000.		(MASC) Protocol", RFC 2909, September 2000.
	[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session		[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
	Announcement Protocol", RFC 2974, October 2000.		Announcement Protocol", RFC 2974, October 2000.
	[RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138,
	June 2001.
	[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,		[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
	and M. Carney, "Dynamic Host Configuration Protocol for		and M. Carney, "Dynamic Host Configuration Protocol for
	IPv6 (DHCPv6)", RFC 3315, July 2003.		IPv6 (DHCPv6)", RFC 3315, July 2003.
			[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
			Number Space", RFC 4893, May 2007.
	[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 -04 and -05		A.1. Changes between -05 and -06
			o Editorial updates.
			o Obsolete only RFC2908; the rest only move to Historic.
			o Category is Informational instead of BCP (in line with the routing
			architecture.
			o Move 3171bis and v4-uni-based to Normative references in order to
			make sure we don't go forward until they're resolved.
			o Resolve pending issues per IETF75 discussion, in particular major
			changes to eGLOP and IANA policy discussions.
			A.2. 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 explictly stating that GLOP for v6 is not needed and GLOP		o New text explicitly stating that GLOP for v6 is not needed and
	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.2. Changes between -03 and -04		A.3. 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.3. Changes between -02 and -03		A.4. 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.4. Changes between -01 and -02		A.5. Changes between -01 and -02
	o Mention the mechanisms which haven't been so succesful: 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.
	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
	Copyright (C) The Internet Society (2006).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	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
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 66 change blocks.
	180 lines changed or deleted		167 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/