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
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
IPv4多播地址分配的IANA指南
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.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This memo provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses.
本备忘录为Internet分配号码管理局（IANA）分配IPv4多播地址提供指导。
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.
互联网分配号码管理局（IANA）（www.IANA.org）负责为互联网工程任务组（IETF）设计、创建或维护的协议中的字段分配参数值。RFC 2780[RFC2780]为新开发协议中字段的参数分配提供IANA指南。本备忘录对RFC 2780第4.4.2节进行了扩展，并试图编纂分配IPv4多播地址中使用的现有IANA实践。
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].
本备忘录中使用术语“所需规范”、“专家评审”、“IESG批准”、“IETF共识”和“标准行动”来指代[RFC2434]中描述的过程。关键字必须、不得、可、可选、必需、推荐、应、不应、不应按照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/numbers.html.
一般来说，由于IPv4多播地址空间相对较小，建议仅在有限的情况下进一步分配IPv4多播地址空间。具体而言，IANA应仅在无法使用动态选择（SDP/SAP）、GLOP、SSM或管理范围的地址空间的情况下分配地址。下文所述的准则反映在http://www.iana.org/numbers.html.
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]:
与IPv4单播地址分配不同，IPv4单播地址分配将地址块委托给区域注册中心，IPv4多播地址由IANA直接分配。当前分配如下所示[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
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.
IANA通常从本地网络控制、网络间控制和自组织块分配地址。下面描述了这些块中每个块以及源特定多播、GLOP和管理范围块的分配准则。
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].
本地网络控制块中的地址用于未在链路外转发的协议控制流量。此类使用的示例包括OSPFIGP所有路由器（224.0.0.5）[RFC2328]。
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.
根据RFC 2780[RFC2780]第4.4.2节，本地网络控制块的任务遵循专家评审、IESG批准或标准行动流程。请参阅[IANA]了解当前的一组作业。
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]).
互联网控制块中的地址用于必须通过互联网转发的协议控制。示例包括224.0.1.1（NTP[RFC2030]）和224.0.1.68（mdhcpdiscover[RFC2730]）。
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.
根据RFC 2780[RFC2780]第4.4.2节，网络控制块的分配遵循专家评审、IESG批准或标准行动流程。请参阅[IANA]了解当前的一组作业。
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).
自组织块中的地址传统上被分配给那些不适合本地或网络间控制块的应用程序。这些地址是全局路由的，通常由需要小块寻址（例如，小于a/24）的应用程序使用。
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.
通常，IANA不应在特设块中分配地址。然而，IANA可能在特殊情况下从该块分配地址。根据RFC 2780[RFC2780]第4.4.2节，特设区块的任务遵循专家评审、IESG批准或标准行动流程。请参阅[IANA]了解当前的一组作业。
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]).
SDP/SAP块中的地址由通过会话公告协议[RFC2974]接收地址的应用程序使用，以通过诸如会话目录工具（如SDR[SDR]）之类的应用程序使用。
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.
由于SDP/SAP块中的地址是从尚未使用的地址范围[RFC2974]中随机选择的，因此不需要IANA分配策略。请注意，虽然不需要额外的IANA分配，但SDP/SAP块中的地址明确供SDP/SAP使用，不得用于其他目的。
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].
源特定多播（SSM）是IP多播的一个扩展，在该扩展中，通信量仅从接收机明确表示感兴趣的那些多播源转发给接收机，并且主要针对一对多（广播）应用。注意，该块最初分配给VMTP瞬态组[IANA]。
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.
由于SSM模型本质上使整个多播地址空间成为主机的本地地址，因此不需要IANA分配策略。然而，请注意，虽然不需要额外的IANA分配，但SSM块中的地址明确供SSM使用，不得用于其他目的。
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].
GLOP块中的地址是全局范围的静态分配地址。分配是通过将域的自治系统号映射到233.X.Y.0/24的中间两个八位字节来完成的。映射和赋值在[RFC2770]中定义。
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.
由于GLOP块中的地址是通过算法预先分配的，因此不需要IANA分配策略。此外，RFC 3138[RFC3138]将由RFC 1930[RFC1930]专用AS空间（233.252.0.0-233.255.255.255）映射的GLOP子块的分配委托给Internet路由注册表。请注意，虽然不需要额外的IANA分配，但GLOP块中的地址分配用于RFC 2770中定义的用途，不得用于其他目的。
Addresses in the Administratively Scoped Address block are for local use within a domain and are described in [RFC2365].
管理作用域地址块中的地址用于域内的本地使用，如[RFC2365]所述。
Since addresses in this block are local to a domain, no IANA assignment policy is required.
由于此块中的地址是域的本地地址，因此不需要IANA分配策略。
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.
相对偏移量[RFC2365]用于确保服务可以独立于封闭范围的范围进行定位（有关详细信息，请参阅RFC 2770）。由于只有256个这样的偏移量，IANA应该只为提供基础设施支持服务的协议分配一个相对偏移量。此类服务的示例包括会话公告协议[RFC2974]。根据RFC 2780[RFC2780]第4.4.2节，相对补偿的分配遵循专家评审、IESG批准或标准行动流程。请参阅[IANA]了解当前的一组作业。
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.
考虑到IPv4多播及其相关基础设施的动态性质，以及之前未记录的IPv4多播地址分配指南，IANA应该对当前分配的地址进行年度审查。
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).
IANA还应审查AD-HOC、DIS-Transient Group和ST多播组块中的分配，并回收那些在全球互联网上未使用的地址（即，那些可以使用SSM、GLOP或管理范围寻址，或未全局路由的应用程序）。
Applications MUST NOT use addressing in the IANA reserved blocks.
应用程序不得在IANA保留块中使用寻址。
The assignment guidelines described in this document do not alter the security properties of either the Any Source or Source Specific multicast service models.
本文档中描述的分配准则不会改变任何源或源特定多播服务模型的安全属性。
The authors would like to thank Joe St. Sauver, John Meylor, Randy Bush, and Thomas Narten for their constructive feedback and comments.
作者要感谢Joe St.Sauver、John Meylor、Randy Bush和Thomas Narten的建设性反馈和评论。
Zaid Albanna 1149 N. Mathilda Ave Sunnyvale, CA. 94089
扎伊德·阿尔班纳1149北马蒂尔达大街桑尼维尔，约94089
EMail: zaid@juniper.net
EMail: zaid@juniper.net
Kevin Almeroth UC Santa Barbara Santa Barbara, CA.
凯文·阿尔梅罗斯加州大学圣巴巴拉圣巴巴拉分校。
EMail: almeroth@cs.ucsb.edu
EMail: almeroth@cs.ucsb.edu
David Meyer Sprint E|Solutions
David Meyer Sprint E |解决方案
EMail: dmm@sprint.net
EMail: dmm@sprint.net
Michelle Schipper IANA Administrator Internet Assigned Numbers Authority 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292
Michelle Schipper IANA管理员互联网分配号码管理局4676金钟路330号套房马里纳德雷，加利福尼亚州90292
EMail: iana@iana.org
EMail: iana@iana.org
[IANA] http://www.iana.org/numbers.html
[IANA] http://www.iana.org/numbers.html
[RFC1190] Topolcic, C., "Experimental Internet Stream Protocol, Version 2 (ST-II)", RFC 1190, October 1990.
[RFC1190]Topolocic，C.，“实验互联网流协议，版本2（ST-II）”，RFC11901990年10月。
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996.
[RFC1930]霍金森，J.和T.贝茨，“自主系统（AS）的创建、选择和注册指南”，RFC 1930，1996年3月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2030]Mills，D.“IPv4、IPv6和OSI的简单网络时间协议（SNTP）第4版”，RFC 2030，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365]Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2730] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP), RFC 2730, December 1999.
[RFC2730]Hanna，S.，Patel，B.和M.Shah，“多播地址动态客户端分配协议（MADCAP）”，RFC2730，1999年12月。
[RFC2770] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC 2770, February 2000.
[RFC2770]Meyer，D.和P.Lothberg，“233/8中的GLOP寻址”，RFC 27702000年2月。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC2780]Bradner，S.和V.Paxson，“互联网协议和相关报头中值的IANA分配指南”，BCP 37，RFC 2780，2000年3月。
[RFC2908] Thaler, D., Handley, M. and D.Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000.
[RFC2908]Thaler，D.，Handley，M.和D.Estrin，“互联网多播地址分配架构”，RFC 2908，2000年9月。
[RFC2909] Thaler, D., Handley, M. and D. Estrin, "The Multicast Address-Set Claim (MASC) Protocol", RFC 2909, September 2000.
[RFC2909]Thaler，D.，Handley，M.和D.Estrin，“多播地址集声明（MASC）协议”，RFC 29092000年9月。
[RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June 2001.
[RFC3138]Meyer，D.，“233/8年的延长任务”，RFC 3138，2001年6月。
[SDR] http://www-mice.cs.ucl.ac.uk/multimedia/software/
[SDR] http://www-mice.cs.ucl.ac.uk/multimedia/software/
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。