< draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.txt		draft-ietf-mboned-iana-ipv4-mcast-guidelines-04.txt >
			A new Request for Comments is now available in online RFC libraries.
	Network Working Group Zaid Albanna		BCP 51
	INTERNET DRAFT Juniper Networks		RFC 3171
	Kevin Almeroth
	UCSB
	David Meyer
	Sprint
	Michelle Schipper
	IANA
	Category Best Current Practices
	June, 2001
	IANA Guidelines for IPv4 Multicast Address Assignments
	<draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.txt>
	1. Status of this Memo
	This document specifies an Internet Best Current Practices for the
	Internet Community, and requests discussion and suggestions for
	improvements. Distribution of this memo is unlimited.
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC 2026.
	Internet Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	2. Copyright Notice
	Copyright (C) The Internet Society (2001). All Rights Reserved.
	3. Abstract
	This memo provides guidance for the IANA in assigning IPv4 multicast
	addresses.
	4. Introduction
	The Internet Assigned Numbers Authority (IANA) (www.iana.org) is
	charged with allocating parameter values for fields in protocols
	which have been designed, created or are maintained by the Internet
	Engineering Task Force (IETF). RFC 2780 [RFC2780] provides the IANA
	guidance in the assignment of parameters for fields in newly
	developed protocols. This memo expands on section 4.4.2 of RFC 2780
	and attempts to codify existing IANA practice used in the assignment
	IPv4 multicast addresses.
	The terms "Specification Required", "Expert Review", "IESG Approval",
	"IETF Consensus", and "Standards Action", are used in this memo to
	refer to the processes described in [RFC2434]. The keywords MUST,
	MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT,
	SHOULD, SHOULD NOT are to be interpreted as defined in RFC 2119
	[RFC2119].
	In general, due to the relatively small size of the IPv4 multicast
	addresses space, further assignment of IPv4 multicast address space
	is recommended only in limited circumstances. Specifically, the IANA
	should only assign addresses in those cases where the dynamic
	selection (SDP/SAP), GLOP, SSM or Administratively Scoped address
	spaces cannot be used. The guidelines described below are reflected
	in http://www.iana.org/assignments/multicast-addresses.
	5. Definition of Current Assignment Practice
	Unlike IPv4 unicast address assignment, where blocks of addresses are
	delegated to regional registries, IPv4 multicast addresses are
	assigned directly by the IANA. Current assignments appear as follows
	[IANA]:
	224.0.0.0 - 224.0.0.255 (224.0.0/24) Local Network Control Block
	224.0.1.0 - 224.0.1.255 (224.0.1/24) Internetwork Control Block
	224.0.2.0 - 224.0.255.0 AD-HOC Block
	224.1.0.0 - 224.1.255.255 (224.1/16) ST Multicast Groups
	224.2.0.0 - 224.2.255.255 (224.2/16) SDP/SAP Block
	224.252.0.0 - 224.255.255.255 DIS Transient Block
	225.0.0.0 - 225.255.255.255 (225/8) MALLOC Block
	226.0.0.0 - 231.255.255.255 RESERVED
	232.0.0.0 - 232.255.255.255 (232/8) Source Specific Multicast Block
	233.0.0.0 - 233.255.255.255 (233/8) GLOP Block
	234.0.0.0 - 238.255.255.255 RESERVED
	239.0.0.0 - 239.255.255.255 (239/8) Administratively Scoped Block
	The IANA generally assigns addresses from the Local Network Control,
	Internetwork Control, and AD-HOC blocks. Assignment guidelines for
	each of these blocks, as well as for the MALLOC, Source Specific
	Multicast, GLOP and Administratively Scoped Blocks, are described
	below.
	6. Local Network Control Block (224.0.0/24)
	Addresses in the Local Network Control block are used for protocol
	control traffic that is not forwarded off link. Examples of this type
	of use include OSPFIGP All Routers (224.0.0.5) [RFC2328].
	6.1. Assignment Guidelines
	Pursuant to section 4.4.2 of RFC 2780 [RFC2780], assignments from the
	Local Network Control block follow an Expert Review, IESG Approval or
	Standards Action process. See [IANA] for the current set of
	assignments.
	7. Internetwork Control Block (224.0.1/24)
	Addresses in the Internetwork Control block are used for protocol
	control that must be forwarded through the Internet. Examples include
	224.0.1.1 (NTP [RFC2030]) and 224.0.1.68 (mdhcpdisover [RFC2730]).
	7.1. Assignment Guidelines
	Pursuant to section 4.4.2 of RFC 2780 [RFC2780], assignments from the
	Internetwork Control block follow an Expert Review, IESG Approval or
	Standards Action process. See [IANA] for the current set of
	assignments.
	8. AD-HOC Block (224.0.2.0/24 - 224.0.255.0/24)
	Addresses in the AD-HOC block have traditionally been assigned for
	those applications that don't fit in either the Local or Internetwork
	Control blocks. These addresses are globally routed and are typically
	used by applications that require small blocks of addressing (e.g.,
	less than a /24).
	8.1. Assignment Guidelines
	In general, the IANA SHOULD NOT assign addressing in the AD-HOC
	Block. However, the IANA may under special special circumstances,
	assign addressing from this block. Pursuant to section 4.4.2 of RFC
	2780 [RFC2780], assignments from the AD-HOC block follow an Expert
	Review, IESG Approval or Standards Action process. See [IANA] for the
	current set of assignments.
	9. SDP/SAP Block (224.2/16)
	Addresses in the SDP/SAP block are used by applications that receive
	addresses through the Session Announcement Protocol [RFC2974] for use
	via applications like the session directory tool (such as SDR [SDR]).
	9.1. Assignment Guidelines
	Since addresses in the SDP/SAP block are chosen randomly from the
	range of addresses not already in use [RFC2974], no IANA assignment
	policy is required. Note that while no additional IANA assignment is
	required, addresses in the SDP/SAP block are explicitly for use by
	SDP/SAP and MUST NOT be used for other purposes.
	10. MALLOC Block (225/8)
	Addresses in the MALLOC block are dynamically assigned by the MALLOC
	suite of protocols [RFC2908]. This assignment is temporary and MUST
	BE reviewed annually.
	10.1. Assignment Guidelines
	Since addresses in the MALLOC block are chosen by elements of the
	MALLOC architecture, no IANA assignment policy is required. Note that
	while no additional IANA assignment is required, addresses in the
	MALLOC block are explicitly for assignment by MALLOC servers and MUST
	NOT be used for other purposes.
	11. Source Specific Multicast Block (232/8)
	The Source Specific Multicast (SSM) is an extension of IP Multicast
	in which traffic is forwarded to receivers from only those multicast
	sources for which the receivers have explicitly expressed interest,
	and is primarily targeted at one-to-many (broadcast) applications.
	11.1. Assignment Guidelines
	Because the SSM model essentially makes the entire multicast address
	space local to the host, no IANA assignment policy is required. Note,
	however, that while no additional IANA assignment is required,
	addresses in the SSM block are explicitly for use by SSM and MUST NOT
	be used for other purposes.
	12. GLOP Block (233/8)
	Addresses in the GLOP block are globally scoped statically assigned
	addresses. The assignment is made by mapping a domain's autonomous
	system number into the middle two octets of 233.X.Y.0/24. The mapping
	and assignment is defined in [RFC2770].
	12.1. Assignment Guidelines
	Because addresses in the GLOP block are algorithmically preassigned,
	no IANA assignment policy is required. Note that while no additional
	IANA assignment is required, addresses in the GLOP block are assigned
	for use as defined in RFC 2770 and MUST NOT be used for other
	purposes.
	13. Administratively Scoped Address Block (239/8)
	Addresses in the Administratively Scoped Address block are for local
	use within a domain and are described in [RFC2365].
	13.1. Assignment Guidelines
	Since addresses in this block are local to a domain, no IANA
	assignment policy is required.
	13.1.1. Relative Offsets
	The relative offsets [RFC2365] are used to ensure that a service can
	be located independent of the extent of the enclosing scope (see RFC
	2770 for details). Since there are only 256 such offsets, the IANA
	should only assign a relative offset to a protocol that provides an
	infra-structure supporting service. Examples of such services include
	the Session Announcement Protocol [RFC2974]. Pursuant to section
	4.4.2 of RFC 2780 [RFC2780], assignments of Relative Offsets follow
	an Expert Review, IESG Approval or Standards Action process. See
	[IANA] for the current set of assignments.
	14. Annual Review
	Given the dynamic nature of IPv4 multicast and its associated infra-
	structure, and the previously undocumented IPv4 multicast address
	assignment guidelines, the IANA should conduct an annual review of
	currently assigned addresses.
	14.1. Address Reclamation
	During the review described above, addresses that were mis-assigned
	should, where possible, be reclaimed or reassigned.
	The IANA should also review assignments in the AD-HOC, DIS Transient
	Groups, and ST Multicast Groups blocks and reclaim those addresses
	that are not in use on the global Internet (i.e, those applications
	which can use SSM, GLOP, or Administratively Scoped addressing, or
	are not globally routed).
	15. Use of IANA Reserved Addresses
	Applications MUST NOT use addressing in the IANA reserved blocks.
	16. Appeals Process
	Appeals of this process are to be handled in accordance with Section
	6.5 of RFC 2026 [RFC2026].
	17. Security Considerations
	The assignment guidelines described in this document do not alter the
	security properties of either the Any Source or Source Specific
	multicast service models.
	18. Acknowledgments
	The authors would like to thank Joe St. Sauver, John Meylor, Randy
	Bush, and Thomas Narten for their constructive feedback and comments.
	19. Author's Address:
	Zaid Albanna
	1149 N. Mathilda Ave
	Sunnyvale, CA. 94089
	zaid@juniper.net
	Kevin Almeroth
	UC Santa Barbara
	Santa Barbara, CA.
	Email: almeroth@cs.ucsb.edu
	David Meyer
	Sprint E|Solutions
	Email: dmm@sprint.net
	Michelle Schipper
	IANA Administrator
	Internet Assigned Numbers Authority
	4676 Admiralty Way, Suite 330
	Marina del Rey, CA 90292
	iana@iana.org
	20. References
	[IANA] http://www.iana.org/assignments/multicast-addresses
	[RFC1190] C. Topolcic, "Experimental Internet Stream
	Protocol, Version 2 (ST-II)", RFC 1190, October,
	1990.
	[RFC2026] S. Bradner, "The Internet Standards Process --
	Revision 3", RFC2026, October 1996.
	[RFC2030] Mills, D., Simple Network Time Protocol (SNTP) Version 4
	for IPv4, IPv6 and OSI", D. Mills, October 1996.
	[RFC2119] S. Bradner, "Key words for use in RFCs to
	Indicate Requirement Levels", RFC 2119, March,
	1997.
	[RFC2328] J. Moy,"OSPF Version 2", RFC 2328, April, 1998.
	[RFC2365] D. Meyer,"Administratively Scoped IP Multicast", RFC
	2365, July, 1998.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
	Writing an IANA Considerations Section in RFCs",
	BCP 26, RFC 2434, October 1998.
	[RFC2730] Hanna, S., Patel, B. and M. Shah, "Multicast Address
	Dynamic Client Allocation Protocol (MADCAP), December
	1999.
	[RFC2770] D. Meyer, and P. Lothberg, "GLOP Addressing in 233/8",		Title: IANA Guidelines for IPv4 Multicast Address
	RFC 2770, February, 2000		Assignments
			Author(s): Z. Albanna, K. Almeroth, D. Meyer, M. Schipper
			Status: Best Current Practice
			Date: August 2001
			Mailbox: zaid@juniper.net, almeroth@cs.ucsb.edu,
			dmm@sprint.net, iana@iana.org
			Pages: 8
			Characters: 15389
			Updates/Obsoletes/SeeAlso: None
	[RFC2780] S. Bradner and V. Paxson, "IANA Allocation Guidelines		I-D Tag: draft-ietf-mboned-iana-ipv4-mcast-guidelines-04.txt
	For Values In the Internet Protocol and Related
	Headers", RFC2780, March, 2000
	[RFC2908] D. Thaler, M. Handley, D.Estrin, "Theh Internet Multicast		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3171.txt
	Address Allocation Architecture", RFC 2908, September 2000.
	[RFC2974] M. Handley, C. Perkins, E. Whelan, "Session		This memo provides guidance for the Internet Assigned Numbers
	Announcement Protocol", RFC 2974, October 2000.		Authority (IANA) in assigning IPv4 multicast addresses.
	[SDR] http://www.aciri.org/sdr/		This document specifies an Internet Best Current Practices for the
			Internet Community, and requests discussion and suggestions for
			improvements. Distribution of this memo is unlimited.
	21. Full Copyright Statement		This announcement is sent to the IETF list and the RFC-DIST list.
			Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	Copyright (C) The Internet Society (2001). All Rights Reserved.		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	This document and translations of it may be copied and furnished to		To: rfc-info@RFC-EDITOR.ORG
	others, and derivative works that comment on or otherwise explain it		Subject: getting rfcs
	or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the 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 be		help: ways_to_get_rfcs
	revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		Requests for special distribution should be addressed to either the
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		specifically noted otherwise on the RFC itself, all RFCs are for
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		unlimited distribution.echo
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		Submissions for Requests for Comments should be sent to
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 12 change blocks.
	340 lines changed or deleted		31 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/