summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3171.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3171.txt')
-rw-r--r--doc/rfc/rfc3171.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3171.txt b/doc/rfc/rfc3171.txt
new file mode 100644
index 0000000..515d2c9
--- /dev/null
+++ b/doc/rfc/rfc3171.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group Z. Albanna
+Request for Comments: 3171 Juniper Networks
+BCP: 51 K. Almeroth
+Category: Best Current Practice UCSB
+ D. Meyer
+ Sprint
+ M. Schipper
+ IANA
+ August 2001
+
+
+ IANA Guidelines for IPv4 Multicast Address Assignments
+
+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.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ This memo provides guidance for the Internet Assigned Numbers
+ Authority (IANA) in assigning IPv4 multicast addresses.
+
+1. 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].
+
+
+
+
+
+
+Albanna, et al. Best Current Practice [Page 1]
+
+RFC 3171 IANA IPv4 Multicast Guidelines August 2001
+
+
+ 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/numbers.html.
+
+2. 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 - 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 Source Specific Multicast,
+ GLOP and Administratively Scoped Blocks, are described below.
+
+3. 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].
+
+3.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.
+
+
+
+
+
+Albanna, et al. Best Current Practice [Page 2]
+
+RFC 3171 IANA IPv4 Multicast Guidelines August 2001
+
+
+4. 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 (mdhcpdiscover
+ [RFC2730]).
+
+4.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.
+
+5. 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).
+
+5.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.
+
+6. 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]).
+
+6.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.
+
+
+
+
+
+
+
+Albanna, et al. Best Current Practice [Page 3]
+
+RFC 3171 IANA IPv4 Multicast Guidelines August 2001
+
+
+7. 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.
+ Note that this block as initially assigned to the VMTP transient
+ groups [IANA].
+
+7.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.
+
+8. 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].
+
+8.1. Assignment Guidelines
+
+ Because addresses in the GLOP block are algorithmically pre-assigned,
+ no IANA assignment policy is required. In addition, RFC 3138
+ [RFC3138] delegates assignment of the GLOP sub-block mapped by the
+ RFC 1930 [RFC1930] private AS space (233.252.0.0 - 233.255.255.255)
+ to the Internet Routing Registries. 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.
+
+9. 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].
+
+9.1. Assignment Guidelines
+
+ Since addresses in this block are local to a domain, no IANA
+ assignment policy is required.
+
+
+
+
+
+
+
+Albanna, et al. Best Current Practice [Page 4]
+
+RFC 3171 IANA IPv4 Multicast Guidelines August 2001
+
+
+9.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
+ infrastructure 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.
+
+10. 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.
+
+10.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).
+
+11. Use of IANA Reserved Addresses
+
+ Applications MUST NOT use addressing in the IANA reserved blocks.
+
+12. 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.
+
+13. Acknowledgments
+
+ The authors would like to thank Joe St. Sauver, John Meylor, Randy
+ Bush, and Thomas Narten for their constructive feedback and comments.
+
+
+
+
+
+
+
+Albanna, et al. Best Current Practice [Page 5]
+
+RFC 3171 IANA IPv4 Multicast Guidelines August 2001
+
+
+14. Authors' Addresses
+
+ Zaid Albanna
+ 1149 N. Mathilda Ave
+ Sunnyvale, CA. 94089
+
+ EMail: 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
+
+ EMail: iana@iana.org
+
+15. References
+
+ [IANA] http://www.iana.org/numbers.html
+
+ [RFC1190] Topolcic, C., "Experimental Internet Stream Protocol,
+ Version 2 (ST-II)", RFC 1190, October 1990.
+
+ [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
+ selection, and registration of an Autonomous System (AS)",
+ RFC 1930, March 1996.
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
+ for IPv4, IPv6 and OSI", RFC 2030, October 1996.
+
+
+
+
+
+Albanna, et al. Best Current Practice [Page 6]
+
+RFC 3171 IANA IPv4 Multicast Guidelines August 2001
+
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+ [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
+ 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), RFC 2730,
+ December 1999.
+
+ [RFC2770] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC
+ 2770, February 2000.
+
+ [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
+ Values In the Internet Protocol and Related Headers", BCP
+ 37, RFC 2780, March 2000.
+
+ [RFC2908] Thaler, D., Handley, M. and D.Estrin, "The Internet
+ Multicast Address Allocation Architecture", RFC 2908,
+ September 2000.
+
+ [RFC2909] Thaler, D., Handley, M. and D. Estrin, "The Multicast
+ Address-Set Claim (MASC) Protocol", RFC 2909, September
+ 2000.
+
+ [RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session
+ Announcement Protocol", RFC 2974, October 2000.
+
+ [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June
+ 2001.
+
+ [SDR] http://www-mice.cs.ucl.ac.uk/multimedia/software/
+
+
+
+
+
+
+
+
+
+
+
+
+
+Albanna, et al. Best Current Practice [Page 7]
+
+RFC 3171 IANA IPv4 Multicast Guidelines August 2001
+
+
+16. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ 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
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Albanna, et al. Best Current Practice [Page 8]
+