draft-ietf-mboned-iana-ipv4-mcast-guidelines-00.txt		draft-ietf-mboned-iana-ipv4-mcast-guidelines-01.txt
	Network Working Group Zaid Albanna		Network Working Group Zaid Albanna
	INTERNET DRAFT Worldcom		INTERNET DRAFT Juniper Networks
	Kevin Almeroth		Kevin Almeroth
	UCSB		UCSB
	David Meyer		David Meyer
	Cisco Systems		Cisco Systems
	Michelle Schipper		Michelle Schipper
	IANA		IANA
	Category Best Current Practices		Category Best Current Practices
	March, 2001		April, 2001
	IANA Guidelines for IPv4 Multicast Address Allocation		IANA Guidelines for IPv4 Multicast Address Allocation
	<draft-ietf-mboned-iana-ipv4-mcast-guidelines-00.txt>		<draft-ietf-mboned-iana-ipv4-mcast-guidelines-01.txt>
	1. Status of this Memo		1. Status of this Memo
	This document specifies an Internet Best Current Practices for the		This document specifies an Internet Best Current Practices for the
	Internet Community, and requests discussion and suggestions for		Internet Community, and requests discussion and suggestions for
	improvements. Distribution of this memo is unlimited.		improvements. Distribution of this memo is unlimited.
	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 RFC 2026.		all provisions of Section 10 of RFC 2026.
	skipping to change at page 4, line 5		skipping to change at page 4, line 5
	control traffic that is not forwarded off link. Examples of this type		control traffic that is not forwarded off link. Examples of this type
	of use include OSPFIGP All Routers (224.0.0.5) [RFC2328].		of use include OSPFIGP All Routers (224.0.0.5) [RFC2328].
	6.1. Allocation Guidelines		6.1. Allocation Guidelines
	Allocation of addresses in the Local Network Configuration Block		Allocation of addresses in the Local Network Configuration Block
	SHOULD BE be accompanied by a specification ("Specification		SHOULD BE be accompanied by a specification ("Specification
	Required"). This specification will typically take the form of an		Required"). This specification will typically take the form of an
	internet draft or RFC.		internet draft or RFC.
			Internet Draf-draft-ietf-mboned-iana-IPv4-mcast-guidelines-01.txt April, 2001
	7. Internetwork Control Block (224.0.1/24)		7. Internetwork Control Block (224.0.1/24)
	Addresses in the Internetwork Control block are used for protocol		Addresses in the Internetwork Control block are used for protocol
	control that must be forwarded through the Internet. Examples include		control that must be forwarded through the Internet. Examples include
	224.0.1.1 (NTP [RFC2030]) and 224.0.1.68 (mdhcpdisover [RFC2730]).		224.0.1.1 (NTP [RFC2030]) and 224.0.1.68 (mdhcpdisover [RFC2730]).
	7.1. Allocation Guidelines		7.1. Allocation Guidelines
	Allocation of addresses in the Internetwork Control block SHOULD BE		Allocation of addresses in the Internetwork Control block SHOULD BE
	accompanied by a specification ("Specification Required"). This		accompanied by a specification ("Specification Required"). This
	skipping to change at page 5, line 21		skipping to change at page 5, line 21
	10.1. Allocation Guidelines		10.1. Allocation Guidelines
	Since addresses in the MALLOC block are chosen by elements of the		Since addresses in the MALLOC block are chosen by elements of the
	MALLOC architecture, no IANA allocation policy is required. Note that		MALLOC architecture, no IANA allocation policy is required. Note that
	while no additional IANA allocation is required, addresses in the		while no additional IANA allocation is required, addresses in the
	MALLOC block are explicitly for allocation by MALLOC servers and MUST		MALLOC block are explicitly for allocation by MALLOC servers and MUST
	NOT be used for other purposes.		NOT be used for other purposes.
	11. Source Specific Multicast Block (232/8)		11. Source Specific Multicast Block (232/8)
	The Source Specific Multicast (SSM) block use is outlined in [SSM].		The Source Specific Multicast (SSM) is an extension of IP Multicast
	In general, SSM is an extension of IP Multicast in which traffic is		in which traffic is forwarded to receivers from only those multicast
	forwarded to receivers from only those multicast sources for which		sources for which the receivers have explicitly expressed interest,
	the receivers have explicitly expressed interest, and is primarily		and is primarily targeted at one-to-many (broadcast) applications.
	targeted at one-to-many (broadcast) applications where large receiver
	audiences require traffic from a small number of well known sources.
	11.1. Allocation Guidelines		11.1. Allocation Guidelines
	Because the SSM model essentially makes the entire multicast address		Because the SSM model essentially makes the entire multicast address
	space local to the host, no IANA allocation policy is required. Note,		space local to the host, no IANA allocation policy is required. Note,
	however, that while no additional IANA allocation is required,		however, that while no additional IANA allocation is required,
	addresses in the SSM block are explicitly for use by SSM and MUST NOT		addresses in the SSM block are explicitly for use by SSM and MUST NOT
	be used for other purposes.		be used for other purposes.
	12. GLOP Block (233/8)		12. GLOP Block (233/8)
	skipping to change at page 6, line 25		skipping to change at page 6, line 17
	Addresses in the Administratively Scoped Address block are for local		Addresses in the Administratively Scoped Address block are for local
	use within a domain and are described in [RFC2365].		use within a domain and are described in [RFC2365].
	13.1. Allocation Guidelines		13.1. Allocation Guidelines
	Since addresses in this block are local to a domain, no IANA		Since addresses in this block are local to a domain, no IANA
	allocation policy is required.		allocation policy is required.
	13.1.1. Relative Offsets		13.1.1. Relative Offsets
	The relative offsets are used to ensure that a service can be located		The relative offsets [RFC2365] are used to ensure that a service can
	independent of the extent of the enclosing scope (see RFC 2770 for		be located independent of the extent of the enclosing scope (see RFC
	details). Since there are only 256 such offsets, the IANA should only		2770 for details). Since there are only 256 such offsets, the IANA
	assign a relative offset to a protocol that provides an infra-		should only assign a relative offset to a protocol that provides an
	structure supporting service. See [IANA] for the current set of		infra-structure supporting service. Examples of such services include
	assignments.		the Session Announcement Protocol [RFC2974]. See [IANA] for the
			current set of assignments.
	14. Annual Review		14. Annual Review
	Given the dynamic nature of IPv4 multicast and its associated infra-		Given the dynamic nature of IPv4 multicast and its associated infra-
	structure, and the previously undocumented IPv4 multicast address		structure, and the previously undocumented IPv4 multicast address
	assignment guidelines, the IANA should conduct an annual review of		assignment guidelines, the IANA should conduct an annual review of
	currently assigned addresses.		currently assigned addresses.
	14.1. Address Reclamation		14.1. Address Reclamation
	skipping to change at page 7, line 19		skipping to change at page 7, line 11
	that are not in use on the global Internet (i.e, those applications		that are not in use on the global Internet (i.e, those applications
	which can use SSM, GLOP, or Administratively Scoped addressing, or		which can use SSM, GLOP, or Administratively Scoped addressing, or
	are not globally routed).		are not globally routed).
	15. Use of IANA Reserved Addresses		15. Use of IANA Reserved Addresses
	Applications MUST NOT use addressing in the IANA reserved blocks.		Applications MUST NOT use addressing in the IANA reserved blocks.
	16. Appeals Process		16. Appeals Process
	An applicant that is denied a multicast assignment may ask for		Appleals of this process are to be handled in accordance with Section
	additional consideration of its application. Such appeals SHOULD be		6.5 of RFC 2026 [RFC2026].
	granted only in those cases in which (i). the applicant did not
	provide a specification, or (ii). the applicant believes that the
	IANA did not understand the technical basis on which the application
	rests (and hence the need for assignment of globally scoped
	addressing).
	16.1. Requirements [RFC2026]
	All appeals must include a detailed and specific description of the
	facts of the dispute.
	All appeals must be initiated within two months of the public
	knowledge of the action or decision to be challenged.
	At all stages of the appeals process, the individuals or bodies
	responsible for making the decisions have the discretion to define
	the specific procedures they will follow in the process of making
	their decision.
	In all cases a decision concerning the disposition of the dispute,
	and the communication of that decision to the parties involved, must
	be accomplished within a reasonable period of time.
	16.2. Process
	When an application is appealed, the application (and specification,
	if one was provided) is to be reviewed by the IESG, indicating to the
	IANA whether the application should be accepted. The IESG MAY
	additionally employ Expert Review of the application.
	16.2.1. Process Failure
	If an applicant should disagree with an action taken by the IANA and
	IESG in this process, that application should first try to clairfy
	its position with the IANA. If the IANA is unable to satisfy the
	applicant, the applicant may ask for its application (and
	specification, if one was provided) to be reviewed by the IAB.
	The IAB decision is final with respect to the question of whether an
	assignment should be made.
	17. Security Considerations		17. Security Considerations
	Security issues are not discussed in this memo.		The allocation guidelines described in this document do not alter the
			security properties of either the Any Source or Source Specific
			multicast service models.
	18. Acknowledgments		18. Acknowledgments
	The authors would like to thank Joe St. Sauver and John Meylor for		The authors would like to thank Joe St. Sauver, John Meylor, and
	their constructive feedback and comments.		Randy Bush for their constructive feedback and comments.
	19. Author's Address:		19. Author's Address:
	Zaid Albanna		Zaid Albanna
	Worldcom		1149 N. Mathilda Ave
	22001 Loudoun County Parkway		Sunnyvale, CA. 94089
	Ashburn, VA. 20147		zaid@juniper.net
	Email: zaid@mci.net
	Kevin Almeroth		Kevin Almeroth
	UC Santa Barbara		UC Santa Barbara
	Sata Barbara, CA.		Sata Barbara, CA.
	Email: almeroth@cs.ucsb.edu		Email: almeroth@cs.ucsb.edu
	David Meyer		David Meyer
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 Tasman Drive		170 Tasman Drive
	San Jose, CA, 95134		San Jose, CA, 95134
	Email: dmm@cisco.com		Email: dmm@cisco.com
	Michelle Schipper		Michelle Schipper
	IANA		IANA Administrator
	iana@iana.org		iana@iana.org
	20. References		20. References
	[IANA] http://www.iana.org		[IANA] http://www.iana.org
	[RFC1190] C. Topolcic, "Experimental Internet Stream		[RFC1190] C. Topolcic, "Experimental Internet Stream
	Protocol, Version 2 (ST-II)", RFC 1190, October,		Protocol, Version 2 (ST-II)", RFC 1190, October,
	1990.		1990.
	skipping to change at page 9, line 49		skipping to change at page 8, line 43
	Dynamic Client Allocation Protocol (MADCAP), December		Dynamic Client Allocation Protocol (MADCAP), December
	1999.		1999.
	[RFC2770] D. Meyer, and P. Lothberg, "GLOP Addressing in 233/8",		[RFC2770] D. Meyer, and P. Lothberg, "GLOP Addressing in 233/8",
	RFC 2770, February, 2000		RFC 2770, February, 2000
	[RFC2780] S. Bradner and V. Paxson, "IANA Allocation Guidelines		[RFC2780] S. Bradner and V. Paxson, "IANA Allocation Guidelines
	For Values In the Internet Protocol and Related		For Values In the Internet Protocol and Related
	Headers", RFC2780, March, 2000		Headers", RFC2780, March, 2000
	[RFC2908] D. Thaler, M. Handley, D.Estrin, "The Internet Multicast		[RFC2908] D. Thaler, M. Handley, D.Estrin, "Theh Internet Multicast
	Address Allocation Architecture", RFC 2908, September 2000.		Address Allocation Architecture", RFC 2908, September 2000.
	[RFC2974] M. Handley, C. Perkins, E. Whelan, "Session		[RFC2974] M. Handley, C. Perkins, E. Whelan, "Session
	Announcement Protocol", RFC 2974, October 2000.		Announcement Protocol", RFC 2974, October 2000.
	[SDR] http://www.aciri.org/sdr/		[SDR] http://www.aciri.org/sdr/
	[SSM] Holbrook, H., and Cain, B., "Source-Specific Multicast
	for IP", draft-holbrook-ssm-arch-01.txt, Work in
	progress.
	21. Full Copyright Statement		21. Full Copyright Statement
	Copyright (C) The Internet Society (2001). All Rights Reserved.		Copyright (C) The Internet Society (2001). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/