draft-ietf-mboned-iana-ipv4-mcast-guidelines-02.txt		draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.txt
	Network Working Group Zaid Albanna		Network Working Group Zaid Albanna
	INTERNET DRAFT Juniper Networks		INTERNET DRAFT Juniper Networks
	Kevin Almeroth		Kevin Almeroth
	UCSB		UCSB
	David Meyer		David Meyer
	Cisco Systems		Sprint
	Michelle Schipper		Michelle Schipper
	IANA		IANA
	Category Best Current Practices		Category Best Current Practices
	April, 2001		June, 2001
	IANA Guidelines for IPv4 Multicast Address Assignments		IANA Guidelines for IPv4 Multicast Address Assignments
	<draft-ietf-mboned-iana-ipv4-mcast-guidelines-02.txt>		<draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.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 3, line 39		skipping to change at page 3, line 39
	below.		below.
	6. Local Network Control Block (224.0.0/24)		6. Local Network Control Block (224.0.0/24)
	Addresses in the Local Network Control block are used for protocol		Addresses in the Local Network Control block are used for protocol
	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. Assignment Guidelines		6.1. Assignment Guidelines
	Assignment of addresses in the Local Network Configuration Block		Pursuant to section 4.4.2 of RFC 2780 [RFC2780], assignments from the
	SHOULD BE be accompanied by a specification ("Specification		Local Network Control block follow an Expert Review, IESG Approval or
	Required"). This specification will typically take the form of an		Standards Action process. See [IANA] for the current set of
	internet draft or RFC.		assignments.
	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. Assignment Guidelines		7.1. Assignment Guidelines
	Assignment of addresses in the Internetwork Control block SHOULD BE		Pursuant to section 4.4.2 of RFC 2780 [RFC2780], assignments from the
	accompanied by a specification ("Specification Required"). This		Internetwork Control block follow an Expert Review, IESG Approval or
	specification will typically take the form of an internet draft or		Standards Action process. See [IANA] for the current set of
	RFC.		assignments.
	8. AD-HOC Block (224.0.2.0/24 - 224.0.255.0/24)		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		Addresses in the AD-HOC block have traditionally been assigned for
	those applications that don't fit in either the Local or Internetwork		those applications that don't fit in either the Local or Internetwork
	Control blocks. These addresses are globally routed and are typically		Control blocks. These addresses are globally routed and are typically
	used by applications that require small blocks of addressing (e.g.,		used by applications that require small blocks of addressing (e.g.,
	less than a /24).		less than a /24).
	8.1. Assignment Guidelines		8.1. Assignment Guidelines
	IANA SHOULD NOT assign addressing in the AD-HOC Block unless it is a		In general, the IANA SHOULD NOT assign addressing in the AD-HOC
	special circumstance accompanied by a specification ("Specification		Block. However, the IANA may under special special circumstances,
	Required"). This specification will typically take the form of an		assign addressing from this block. Pursuant to section 4.4.2 of RFC
	Internet-Draft or 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)		9. SDP/SAP Block (224.2/16)
	Addresses in the SDP/SAP block are used by applications that receive		Addresses in the SDP/SAP block are used by applications that receive
	addresses through the Session Announcement Protocol [RFC2974] for use		addresses through the Session Announcement Protocol [RFC2974] for use
	via applications like the session directory tool (such as SDR [SDR]).		via applications like the session directory tool (such as SDR [SDR]).
	9.1. Assignment Guidelines		9.1. Assignment Guidelines
	Since addresses in the SDP/SAP block are chosen randomly from the		Since addresses in the SDP/SAP block are chosen randomly from the
	skipping to change at page 6, line 22		skipping to change at page 6, line 37
	Since addresses in this block are local to a domain, no IANA		Since addresses in this block are local to a domain, no IANA
	assignment policy is required.		assignment policy is required.
	13.1.1. Relative Offsets		13.1.1. Relative Offsets
	The relative offsets [RFC2365] are used to ensure that a service can		The relative offsets [RFC2365] are used to ensure that a service can
	be located independent of the extent of the enclosing scope (see RFC		be located independent of the extent of the enclosing scope (see RFC
	2770 for details). Since there are only 256 such offsets, the IANA		2770 for details). Since there are only 256 such offsets, the IANA
	should only assign a relative offset to a protocol that provides an		should only assign a relative offset to a protocol that provides an
	infra-structure supporting service. Examples of such services include		infra-structure supporting service. Examples of such services include
	the Session Announcement Protocol [RFC2974]. See [IANA] for the		the Session Announcement Protocol [RFC2974]. Pursuant to section
	current set of assignments.		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		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 11		skipping to change at page 7, line 29
	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
	Appleals of this process are to be handled in accordance with Section		Appeals of this process are to be handled in accordance with Section
	6.5 of RFC 2026 [RFC2026].		6.5 of RFC 2026 [RFC2026].
	17. Security Considerations		17. Security Considerations
	The assignment guidelines described in this document do not alter the		The assignment guidelines described in this document do not alter the
	security properties of either the Any Source or Source Specific		security properties of either the Any Source or Source Specific
	multicast service models.		multicast service models.
	18. Acknowledgments		18. Acknowledgments
	The authors would like to thank Joe St. Sauver, John Meylor, and		The authors would like to thank Joe St. Sauver, John Meylor, Randy
	Randy Bush for their constructive feedback and comments.		Bush, and Thomas Narten for their constructive feedback and comments.
	19. Author's Address:		19. Author's Address:
	Zaid Albanna		Zaid Albanna
	1149 N. Mathilda Ave		1149 N. Mathilda Ave
	Sunnyvale, CA. 94089		Sunnyvale, CA. 94089
	zaid@juniper.net		zaid@juniper.net
	Kevin Almeroth		Kevin Almeroth
	UC Santa Barbara		UC Santa Barbara
	Sata Barbara, CA.		Santa Barbara, CA.
	Email: almeroth@cs.ucsb.edu		Email: almeroth@cs.ucsb.edu
	David Meyer		David Meyer
	Cisco Systems, Inc.		Sprint E|Solutions
	170 Tasman Drive		Email: dmm@sprint.net
	San Jose, CA, 95134
	Email: dmm@cisco.com
	Michelle Schipper		Michelle Schipper
	IANA Administrator		IANA Administrator
			Internet Assigned Numbers Authority
			4676 Admiralty Way, Suite 330
			Marina del Rey, CA 90292
	iana@iana.org		iana@iana.org
	20. References		20. References
	[IANA] http://www.iana.org/assignments/multicast-addresses		[IANA] http://www.iana.org/assignments/multicast-addresses
	[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.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/