draft-ietf-mboned-ipv4-uni-based-mcast-00.txt		draft-ietf-mboned-ipv4-uni-based-mcast-01.txt
	Network Working Group Dave Thaler		Network Working Group Dave Thaler
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Expires: December 2002 29 June 2002		Expires: July 2004 19 January 2004
	Unicast-Prefix-based IPv4 Multicast Addresses		Unicast-Prefix-based IPv4 Multicast Addresses
	<draft-ietf-mboned-ipv4-uni-based-mcast-00.txt>		<draft-ietf-mboned-ipv4-uni-based-mcast-01.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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.
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	in progress."		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.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	Draft Uni-Prefix-based IPv4 Multicast June 2002		Draft Uni-Prefix-based IPv4 Multicast January 2004
	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
	skipping to change at page 3, line 5		skipping to change at page 3, line 5
	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 latter
	three disadvantages above are avoided (and the first disadvantage		three disadvantages above are avoided (and the first disadvantage
	does not apply to IPv6 due to the extended size of the address		does not apply to IPv6 due to the extended size of the address
	space).		space).
	Two significant advantages of providing multicast space to every		Two significant advantages of providing multicast space to every
	Draft Uni-Prefix-based IPv4 Multicast June 2002		Draft Uni-Prefix-based IPv4 Multicast January 2004
	subnet (rather than just to an entire AS) are that:		subnet (rather than just to an entire AS) are that:
	o multicast address allocation within the range need only be		o multicast address allocation within the range need only be
	coordinated within the subnet (e.g., via ZMAAP [ZMAAP]), and		coordinated within the subnet, and hence can be done with
	hence can be done with zero configuration.		zero configuration.
	o bidirectional shared tree routing protocols may easily locate		o bidirectional shared tree routing protocols may easily locate
	the direction to the root by doing a route lookup on a		the direction to the root by doing a route lookup on a
	unicast address derived from the multicast group address.		unicast address derived from the multicast group address.
	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.
	2. Address Space		2. Address Space
	IANA should assign a /8 for this Unicast-Based Multicast (UBM)		(RFC-editor: replace TBD below with IANA-assigned value, and
	mechanism (e.g., the 225/8 which was previously leased to MASC).		delete this note.)
	The remaining 24 bits will be used as follows:
			A multicast address with the prefix TBD/8 indicates that the
			address is a Unicast-Based Multicast (UBM) address. The
			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 |
	+-----+-----------------------+----------------------------+		+-----+-----------------------+----------------------------+
	Value: | 225 | Unicast Prefix | Group ID |		Value: | TBD | Unicast Prefix | Group ID |
	+-----+-----------------------+----------------------------+		+-----+-----------------------+----------------------------+
	For subnets with a /24 or shorter prefix, the unicast prefix of		For subnets with a /24 or shorter prefix, the unicast prefix of
	the subnet is appended to the common /8. Any remaining bits may		the subnet is appended to the common /8. Any remaining bits may
	be locally assigned by hosts within the link (e.g., using manual		be locally assigned by hosts within the link (e.g., using manual
	configuration, or ZMAAP). Individual subnets with a prefix length		configuration). Individual subnets with a prefix length longer
	longer than 24 do not receive any multicast address space from		than 24 do not receive any multicast address space from this
	this mechanism; in such cases, MADCAP may be used.		mechanism; in such cases, MADCAP may be used.
	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 June 2002		Draft Uni-Prefix-based IPv4 Multicast January 2004
	3. Security Considerations		3. IANA Considerations
			IANA should assign a /8 in the IPv4 multicast address space for
			this purpose.
			4. Security Considerations
	Since dynamic assignment does not cross domain boundaries, the		Since dynamic assignment does not cross domain boundaries, the
	same well known intra-domain security techniques can be applied as		same well known intra-domain security techniques can be applied as
	with GLOP. Furthermore, the approach described here may have the		with GLOP. Furthermore, the approach described here may have the
	effect of reduced exposure to denial of space attacks based on		effect of reduced exposure to denial of space attacks based on
	dynamic allocation, since the area of dynamic allocation is		dynamic allocation, since the area of dynamic allocation is
	reduced from an entire AS to only within individual subnets.		reduced from an entire AS to only within individual subnets.
	4. 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
	5. 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-05.txt, Work in progress, May		space", draft-ietf-idr-as4bytes-07.txt, Work in progress,
	2002.		August 2003.
	[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.		2770, February 2000.
	[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.
	[V6UPBM]		[V6UPBM]
	Haberman, B., and D. Thaler, "Unicast-Prefix-based IPv6		Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
	Multicast Addresses", draft-ietf-ipngwg-uni-based-		Multicast Addresses", RFC 3306, August 2002.
	mcast-03.txt, October 2001.
	[ZMAAP]
	Catrina, O., Thaler, D., Aboba, B., and E. Guttman, "Zeroconf
	Multicast Address Allocation Protocol (ZMAAP)", draft-ietf-
	zeroconf-zmaap-02.txt, October 2001.
	Draft Uni-Prefix-based IPv4 Multicast June 2002		Draft Uni-Prefix-based IPv4 Multicast January 2004
	6. Full Copyright Statement Copyright (C) The Internet Society		7. Full Copyright Statement Copyright (C) The Internet Society
	(2002). All Rights Reserved.		(2004). All Rights Reserved.
	This document and translations of it may be copied and furnished		This document and translations of it may be copied and furnished
	to others, and derivative works that comment on or otherwise		to others, and derivative works that comment on or otherwise
	explain it or assist in its implmentation may be prepared, copied,		explain it or assist in its implmentation may be prepared, copied,
	published and distributed, in whole or in part, without		published and distributed, in whole or in part, without
	restriction of any kind, provided that the above copyright notice		restriction of any kind, provided that the above copyright notice
	and this paragraph are included on all such copies and derivative		and this paragraph are included on all such copies and derivative
	works. However, this document itself may not be modified in any		works. However, this document itself may not be modified in any
	way, such as by removing the copyright notice or references to the		way, such as by removing the copyright notice or references to the
	Internet Society or other Internet organizations, except as needed		Internet Society or other Internet organizations, except as needed
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/