draft-ietf-mboned-ipv4-uni-based-mcast-01.txt		draft-ietf-mboned-ipv4-uni-based-mcast-02.txt
	Network Working Group Dave Thaler		Network Working Group Dave Thaler
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Expires: July 2004 19 January 2004		Expires: April 2005 October 18, 2004
	Unicast-Prefix-based IPv4 Multicast Addresses		Unicast-Prefix-based IPv4 Multicast Addresses
	<draft-ietf-mboned-ipv4-uni-based-mcast-01.txt>		<draft-ietf-mboned-ipv4-uni-based-mcast-02.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, I certify that any applicable
	all provisions of Section 10 of RFC2026.		patent or other IPR claims of which I am aware have been
			disclosed, or will be disclosed, and any of which I become aware
			will be disclosed, in accordance with RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		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		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-		documents at any time. It is inappropriate to use Internet-
	Drafts as reference material or to cite them other than as "work		Drafts as reference material or to cite them other than as "work
	skipping to change at page 1, line 36		skipping to change at page 2, line 5
	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.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Draft Uni-Prefix-based IPv4 Multicast October 2004
	Draft Uni-Prefix-based IPv4 Multicast January 2004		Abstract
	This specification defines an extension to the multicast		This specification defines an extension to the multicast
	addressing architecture of the IP Version 4 protocol. The		addressing architecture of the IP Version 4 protocol. The
	extension presented in this document allows for unicast-prefix-		extension presented in this document allows for unicast-prefix-
	based allocation of multicast addresses. By delegating multicast		based allocation of multicast addresses. By delegating multicast
	addresses at the same time as unicast prefixes, network operators		addresses at the same time as unicast prefixes, network operators
	will be able to identify their multicast addresses without needing		will be able to identify their multicast addresses without needing
	to run an inter-domain allocation protocol.		to run an inter-domain allocation protocol.
	1. Introduction		1. Introduction
	RFC 2770 [GLOP] defined an experimental allocation mechanism in		RFC 3180 [GLOP] defined an experimental allocation mechanism in
	233/8 whereby an Autonomous System (AS) number is embedded in the		233/8 whereby an Autonomous System (AS) number is embedded in the
	middle 16 bits of an IPv4 multicast address, resulting in 256		middle 16 bits of an IPv4 multicast address, resulting in 256
	multicast addresses per AS. Advantages of this mechanism include		multicast addresses per AS. Advantages of this mechanism include
	the ability to get multicast address space without an inter-domain		the ability to get multicast address space without an inter-domain
	multicast address allocation protocol, and the ease of determining		multicast address allocation protocol, and the ease of determining
	the AS of the owner of an address for debugging and auditing		the AS of the owner of an address for debugging and auditing
	purposes.		purposes.
	Some disadvantages of GLOP include:		Some disadvantages of GLOP include:
	o only 256 addresses are automatically available per AS, and
	obtaining any more requires administrative effort.
	o there is work in progress [AS4B] on expanding the size of an		o there is work in progress [AS4B] on expanding the size of an
	AS number to 4 bytes, and GLOP cannot work with such AS's.		AS number to 4 bytes, and GLOP cannot work with such AS's.
	o when an AS covers multiple sites or organizations,		o when an AS covers multiple sites or organizations,
	administration of the multicast address space within an AS		administration of the multicast address space within an AS
	must be handled by other mechanisms, such as manual		must be handled by other mechanisms, such as manual
	administrative effort or MADCAP [MADCAP].		administrative effort or MADCAP [MADCAP].
	o during debugging, identifying the AS does not immediately		o during debugging, identifying the AS does not immediately
	identify the owning organization, when an AS covers multiple		identify the owning organization, when an AS covers multiple
	organizations.		organizations.
			o only 256 addresses are automatically available per AS, and
			obtaining any more requires administrative effort.
	More recently, a mechanism [V6UPBM] has been developed for IPv6		More recently, a mechanism [V6UPBM] has been developed for IPv6
	which provides a multicast range to every IPv6 subnet, which is at		which provides a multicast range to every IPv6 subnet, which is at
	a much finer granularity than an AS. As a result, the latter		a much finer granularity than an AS. As a result, the first three
	three disadvantages above are avoided (and the first disadvantage		disadvantages above are avoided (and the last disadvantage does
	does not apply to IPv6 due to the extended size of the address		not apply to IPv6 due to the extended size of the address space).
	space).
	Two significant advantages of providing multicast space to every
	Draft Uni-Prefix-based IPv4 Multicast January 2004
	subnet (rather than just to an entire AS) are that:
	o multicast address allocation within the range need only be		Draft Uni-Prefix-based IPv4 Multicast October 2004
	coordinated within the subnet, and hence can be done with
	zero configuration.
	o bidirectional shared tree routing protocols may easily locate		Another advantage of providing multicast space to every subnet
	the direction to the root by doing a route lookup on a		(rather than just to an entire AS) is that multicast address
	unicast address derived from the multicast group address.		allocation within the range need only be coordinated within the
			subnet.
	This draft specifies a mechanism similar to [V6UPBM], whereby a		This draft specifies a mechanism similar to [V6UPBM], whereby a
	range of IPv4 multicast address space is provided to most IPv4		range of IPv4 multicast address space is provided to most IPv4
	subnets. A resulting advantage over GLOP is that the mechanisms		subnets. A resulting advantage over GLOP is that the mechanisms
	in IPv4 and IPv6 become more similar.		in IPv4 and IPv6 become more similar.
			This document proposes an experimental method of statically
			allocating multicast addresses with global scope. As described in
			section 4, this experiment will last for a period of one year, but
			may be extended.
	2. Address Space		2. Address Space
	(RFC-editor: replace TBD below with IANA-assigned value, and		(RFC-editor: replace TBD below with IANA-assigned value, and
	delete this note.)		delete this note.)
	A multicast address with the prefix TBD/8 indicates that the		A multicast address with the prefix TBD/8 indicates that the
	address is a Unicast-Based Multicast (UBM) address. The		address is a Unicast-Based Multicast (UBM) address. The
	remaining 24 bits can be used as follows:		remaining 24 bits can be used as follows:
	Bits: | 8 | Unicast Prefix Length | 24 - Unicast Prefix Length |		Bits: | 8 | Unicast Prefix Length | 24 - Unicast Prefix Length |
	skipping to change at page 4, line 5		skipping to change at page 4, line 5
	Compared to GLOP, an AS will receive more address space via this		Compared to GLOP, an AS will receive more address space via this
	mechanism if it has more than a /16 for unicast space. An AS will		mechanism if it has more than a /16 for unicast space. An AS will
	receive less address space than it does from GLOP if it has less		receive less address space than it does from GLOP if it has less
	than a /16.		than a /16.
	The owner of a UBM address can be determined by taking the		The owner of a UBM address can be determined by taking the
	multicast address, shifting it left by 8 bits, and identifying the		multicast address, shifting it left by 8 bits, and identifying the
	owner of the address space covering the resulting unicast address.		owner of the address space covering the resulting unicast address.
	Draft Uni-Prefix-based IPv4 Multicast January 2004		Draft Uni-Prefix-based IPv4 Multicast October 2004
	3. IANA Considerations		3. Security Considerations
			The same well known intra-domain security techniques can be
			applied as with GLOP. Furthermore, when dynamic allocation is
			used within a prefix, the approach described here may have the
			effect of reduced exposure to denial of space attacks, since the
			topological area within which nodes compete for addresses within
			the same prefix is reduced from an entire AS to only within an
			individual subnet.
			4. IANA Considerations
	IANA should assign a /8 in the IPv4 multicast address space for		IANA should assign a /8 in the IPv4 multicast address space for
	this purpose.		this purpose.
	4. Security Considerations		This assignment should timeout one year after the assignment is
			made. The assignment may be renewed at that time.
	Since dynamic assignment does not cross domain boundaries, the
	same well known intra-domain security techniques can be applied as
	with GLOP. Furthermore, the approach described here may have the
	effect of reduced exposure to denial of space attacks based on
	dynamic allocation, since the area of dynamic allocation is
	reduced from an entire AS to only within individual subnets.
	5. Author's Address		5. Author's Address
	Dave Thaler		Dave Thaler
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052-6399		Redmond, WA 98052-6399
	Phone: +1 425 703 8835		Phone: +1 425 703 8835
	EMail: dthaler@microsoft.com		EMail: dthaler@microsoft.com
	6. Informative References		6. Informative References
	[AS4B]		[AS4B]
	Vohra, Q. and E. Chen, "BGP support for four-octet AS number		Vohra, Q. and E. Chen, "BGP support for four-octet AS number
	space", draft-ietf-idr-as4bytes-07.txt, Work in progress,		space", draft-ietf-idr-as4bytes-08.txt, Work in progress,
	August 2003.		March 2004.
	[GLOP]		[GLOP]
	Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC		Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC
	2770, February 2000.		3180, September 2001.
	[MADCAP]		[MADCAP]
	Hanna, S, Patel, B. and M. Shah, "Multicast Address Dynamic		Hanna, S, Patel, B. and M. Shah, "Multicast Address Dynamic
	Client Allocation Protocol (MADCAP)", RFC 2730, December		Client Allocation Protocol (MADCAP)", RFC 2730, December
	1999.		1999.
			Draft Uni-Prefix-based IPv4 Multicast October 2004
	[V6UPBM]		[V6UPBM]
	Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6		Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
	Multicast Addresses", RFC 3306, August 2002.		Multicast Addresses", RFC 3306, August 2002.
	Draft Uni-Prefix-based IPv4 Multicast January 2004
	7. Full Copyright Statement Copyright (C) The Internet Society		7. Full Copyright Statement Copyright (C) The Internet Society
	(2004). All Rights Reserved.		(2004). 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 translations of it may be copied and furnished		This document and the information contained herein are provided on
	to others, and derivative works that comment on or otherwise		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	explain it or assist in its implmentation may be prepared, copied,		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
	published and distributed, in whole or in part, without		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
	restriction of any kind, provided that the above copyright notice		EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
	and this paragraph are included on all such copies and derivative		THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
	works. However, this document itself may not be modified in any		ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
	way, such as by removing the copyright notice or references to the		PARTICULAR PURPOSE.
	Internet Society or other Internet organizations, except as needed
	for the purpose of developing Internet standards in which case the
	procedures for copyrights defined in the Internet Standards
	process must be followed, or as required to translate it into
	languages other than English.
	The limited permissions granted above are perpetual and will not		8. Intellectual Property
	be revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on		The IETF takes no position regarding the validity or scope of any
	an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET		Intellectual Property Rights or other rights that might be claimed
	ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR		to pertain to the implementation or use of the technology
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		described in this document or the extent to which any license
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		under such rights might or might not be available; nor does it
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		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.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/