From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3171.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc3171.txt (limited to 'doc/rfc/rfc3171.txt') 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] + -- cgit v1.2.3