Internet Engineering Task Force (IETF) M. Cotton
Request for Comments: 5771 L. Vegoda
BCP: 51 ICANN
Updates: 2780 D. Meyer
Obsoletes: 3138, 3171 March 2010
Category: Best Current Practice
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Cotton
Request for Comments: 5771 L. Vegoda
BCP: 51 ICANN
Updates: 2780 D. Meyer
Obsoletes: 3138, 3171 March 2010
Category: Best Current Practice
ISSN: 2070-1721
IANA Guidelines for IPv4 Multicast Address Assignments
IPv4多播地址分配的IANA指南
Abstract
摘要
This document provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes RFC 3171 and RFC 3138 and updates RFC 2780.
本文档为Internet分配号码管理局（IANA）分配IPv4多播地址提供指导。它淘汰了RFC 3171和RFC 3138，并更新了RFC 2780。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5771.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5771.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Definition of Current Assignment Practice .......................3
4. Local Network Control Block (224.0.0/24) ........................4
4.1. Assignment Guidelines ......................................4
5. Internetwork Control Block (224.0.1/24) .........................5
5.1. Assignment Guidelines ......................................5
6. AD-HOC Blocks (I, II, and III) ..................................5
6.1. Assignment Guidelines ......................................5
7. SDP/SAP Block (224.2/16) ........................................5
7.1. Assignment Guidelines ......................................5
8. Source-Specific Multicast Block (232/8) .........................6
8.1. Assignment Guidelines ......................................6
9. GLOP Block (233/8) ..............................................6
9.1. Assignment Guidelines ......................................6
9.2. AD-HOC Block III ...........................................6
10. Administratively Scoped Block (239/8) ..........................7
10.1. Assignment Guidelines .....................................7
10.1.1. Relative Offsets ...................................7
11. Application Form ...............................................7
11.1. Size of Assignments of IPv4 Multicast Addresses ...........7
12. Annual Review ..................................................8
12.1. Address Reclamation .......................................8
12.2. Positive Renewal ..........................................8
13. Use of IANA Reserved Addresses .................................8
14. IANA Considerations ............................................8
15. Security Considerations ........................................9
16. Acknowledgments ................................................9
17. References .....................................................9
17.1. Normative References ......................................9
17.2. Informative References ....................................9
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Definition of Current Assignment Practice .......................3
4. Local Network Control Block (224.0.0/24) ........................4
4.1. Assignment Guidelines ......................................4
5. Internetwork Control Block (224.0.1/24) .........................5
5.1. Assignment Guidelines ......................................5
6. AD-HOC Blocks (I, II, and III) ..................................5
6.1. Assignment Guidelines ......................................5
7. SDP/SAP Block (224.2/16) ........................................5
7.1. Assignment Guidelines ......................................5
8. Source-Specific Multicast Block (232/8) .........................6
8.1. Assignment Guidelines ......................................6
9. GLOP Block (233/8) ..............................................6
9.1. Assignment Guidelines ......................................6
9.2. AD-HOC Block III ...........................................6
10. Administratively Scoped Block (239/8) ..........................7
10.1. Assignment Guidelines .....................................7
10.1.1. Relative Offsets ...................................7
11. Application Form ...............................................7
11.1. Size of Assignments of IPv4 Multicast Addresses ...........7
12. Annual Review ..................................................8
12.1. Address Reclamation .......................................8
12.2. Positive Renewal ..........................................8
13. Use of IANA Reserved Addresses .................................8
14. IANA Considerations ............................................8
15. Security Considerations ........................................9
16. Acknowledgments ................................................9
17. References .....................................................9
17.1. Normative References ......................................9
17.2. Informative References ....................................9
The Internet Assigned Numbers Authority (IANA) (www.iana.org) is charged with allocating parameter values for fields in protocols that 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 of IPv4 multicast addresses.
The Internet Assigned Numbers Authority (IANA) (www.iana.org) is charged with allocating parameter values for fields in protocols that 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 of IPv4 multicast addresses.translate error, please retry
This document is a revision of RFC 3171 [RFC3171], which it obsoletes. It also obsoletes RFC 3138 [RFC3138] and updates [RFC2780].
本文件是RFC 3171[RFC3171]的修订版，现已废弃。它还淘汰了RFC 3138[RFC3138]并更新了[RFC2780]。
The terms "Specification Required", "Expert Review", "IESG Approval", "IETF Review", and "Standards Action", are used in this memo to refer to the processes described in [RFC5226].
本备忘录中使用术语“所需规范”、“专家评审”、“IESG批准”、“IETF评审”和“标准行动”来指代[RFC5226]中描述的过程。
In general, due to the relatively small size of the IPv4 multicast address 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:
通常，由于IPv4多播地址空间的大小相对较小，建议仅在有限的情况下进一步分配IPv4多播地址空间。具体而言，IANA仅应在以下情况下分配地址：
- the dynamic selection Session Description Protocol/Session Announcement Protocol (SDP/SAP);
- 动态选择会话描述协议/会话公告协议（SDP/SAP）；
- GLOP (not an acronym);
- GLOP（非首字母缩略词）；
- Source-Specific Multicast (SSM); or
- 源特定多播（SSM）；或
- Administratively Scoped address spaces cannot be used.
- 无法使用管理范围的地址空间。
The guidelines described below are reflected in [IANA-protocols]. Network operators should also be aware of the availability of IPv6 multicast addresses and consider using them where feasible.
以下所述指南反映在[IANA协议]中。网络运营商也应该知道IPv6多播地址的可用性，并在可行的情况下考虑使用它们。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
The word "allocation" designates a block of addresses managed by a registry for the purpose of making assignments and allocations. The word "assignment" designates a block of addresses, or a single address, registered to an end-user for use on a specific network or set of networks.
“分配”一词指由注册表管理的地址块，用于进行分配和分配。“分配”一词指的是注册给最终用户的地址块或单个地址，用于特定网络或一组网络。
Unlike IPv4 unicast address assignment, where blocks of addresses are delegated to Regional Internet Registries (RIRs), IPv4 multicast addresses are assigned directly by the IANA. Current registration groups appear as follows [IANA]:
与IPv4单播地址分配不同，IPv4单播地址分配将地址块委托给区域Internet注册中心（RIR），IPv4多播地址由IANA直接分配。当前注册组显示如下[IANA]：
Address Range Size Designation
------------- ---- -----------
224.0.0.0 - 224.0.0.255 (/24) Local Network Control Block
Address Range Size Designation
------------- ---- -----------
224.0.0.0 - 224.0.0.255 (/24) Local Network Control Block
224.0.1.0 - 224.0.1.255 (/24) Internetwork Control Block
224.0.1.0-224.0.1.255（/24）网络间控制块
224.0.2.0 - 224.0.255.255 (65024) AD-HOC Block I
224.0.2.0-224.0.255.255（65024）临时第一区
224.1.0.0 - 224.1.255.255 (/16) RESERVED
224.1.0.0-224.1.255.255（/16）保留
224.2.0.0 - 224.2.255.255 (/16) SDP/SAP Block
224.2.0.0 - 224.2.255.255 (/16) SDP/SAP Block
224.3.0.0 - 224.4.255.255 (2 /16s) AD-HOC Block II
224.3.0.0-224.4.255.255（2/16s）临时块II
224.5.0.0 - 224.255.255.255 (251 /16s) RESERVED
224.5.0.0-224.255.255.255（251/16s）保留
225.0.0.0 - 231.255.255.255 (7 /8s) RESERVED
225.0.0.0-231.255.255.255（7/8秒）保留
232.0.0.0 - 232.255.255.255 (/8) Source-Specific Multicast Block
232.0.0.0-232.255.255.255（/8）源特定多播块
233.0.0.0 - 233.251.255.255 (16515072) GLOP Block
233.0.0.0-233.251.255.255（16515072）GLOP块
233.252.0.0 - 233.255.255.255 (/14) AD-HOC Block III
233.252.0.0-233.255.255.255（/14）临时第三区
234.0.0.0 - 238.255.255.255 (5 /8s) RESERVED
234.0.0.0-238.255.255.255（5/8s）保留
239.0.0.0 - 239.255.255.255 (/8) Administratively Scoped Block
239.0.0.0-239.255.255.255（/8）管理作用域块
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 [RFC2780], assignments from the Local Network Control Block follow an Expert Review, IESG Approval, or Standards Action process. See IANA [IANA] for the current set of assignments.
根据[RFC2780]第4.4.2节，本地网络控制块的任务遵循专家评审、IESG批准或标准行动流程。请参阅IANA[IANA]了解当前的一组作业。
Addresses in the Internetwork Control Block are used for protocol control traffic that MAY be forwarded through the Internet. Examples include 224.0.1.1 (Network Time Protocol (NTP) [RFC4330]) and 224.0.1.68 (mdhcpdiscover [RFC2730]).
互联网控制块中的地址用于可通过互联网转发的协议控制流量。示例包括224.0.1.1（网络时间协议（NTP）[RFC4330]）和224.0.1.68（mdhcpdiscover[RFC2730]）。
Pursuant to section 4.4.2 of [RFC2780], assignments from the Internetwork Control Block follow an Expert Review, IESG Approval, or Standards Action process. See IANA [IANA] for the current set of assignments.
根据[RFC2780]第4.4.2节，来自互联网控制块的分配遵循专家评审、IESG批准或标准行动流程。请参阅IANA[IANA]了解当前的一组作业。
Addresses in the AD-HOC blocks (including 224.0.2.0 - 224.0.255.255, 224.3.0.0 - 224.4.255.255, and 233.252.0.0 - 233.255.255.255) were traditionally used for assignments for those applications that don't fit in either the Local or Internetwork Control blocks. These addresses MAY be globally routed and are typically used by applications that require small blocks of addressing (e.g., less than a /24 ). Future assignments of blocks of addresses that do not fit in the Local Network or Internetwork Control blocks will be made in AD-HOC Block III.
特殊块（包括224.0.2.0-224.0.255.255、224.3.0.0-224.4.255.255和233.252.0.0-233.255.255.255）中的地址传统上用于分配不适合本地或网络间控制块的应用程序。这些地址可以全局路由，通常由需要小地址块（例如，小于a/24）的应用程序使用。不适合本地网络或网络间控制块的地址块的未来分配将在特设块III中进行。
In general, the IANA SHOULD NOT assign addresses in the AD-HOC blocks. However, the IANA MAY, under special circumstances, assign addresses from these blocks. Pursuant to section 4.4.2 of [RFC2780], assignments from the AD-HOC blocks follow an Expert Review, IESG Approval, or Standards Action process. See [IANA] for the current set of assignments.
通常，IANA不应在特设块中分配地址。然而，在特殊情况下，IANA可以从这些块分配地址。根据[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]).
SDP/SAP块中的地址由通过会话公告协议[RFC2974]接收地址的应用程序使用，以通过诸如会话目录工具（如[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使用，不得用于其他目的。
SSM [RFC4607] 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 was initially assigned to the Versatile Message Transaction Protocol (VMTP) transient groups [IANA].
SSM[RFC4607]是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 Source-Specific Multicast Block are explicitly for use by SSM and MUST NOT be used for other purposes.
由于SSM模型本质上使整个多播地址空间成为主机的本地地址，因此不需要IANA分配策略。然而，请注意，虽然不需要额外的IANA分配，但源特定多播块中的地址明确供SSM使用，不得用于其他目的。
Addresses in the GLOP Block are globally-scoped, statically-assigned addresses. The assignment is made, for a domain with a 16-bit Autonomous System Number (ASN), by mapping a domain's autonomous system number, expressed in octets as X.Y, into the middle two octets of the GLOP Block, yielding an assignment of 233.X.Y.0/24. The mapping and assignment is defined in [RFC3180]. Domains with a 32-bit ASN MAY apply for space in AD-HOC Block III, or consider using IPv6 multicast addresses.
GLOP块中的地址是全局范围的静态分配地址。对于具有16位自治系统编号（ASN）的域，通过将域的自治系统编号（以八位字节表示为X.Y）映射到GLOP块的中间两个八位字节来进行分配，从而产生233.X.Y.0/24的分配。映射和赋值在[RFC3180]中定义。具有32位ASN的域可以在ad-hoc块III中应用空间，或者考虑使用IPv6多播地址。
Because addresses in the GLOP Block are algorithmically pre-assigned, no IANA assignment policy is required.
由于GLOP块中的地址是通过算法预先分配的，因此不需要IANA分配策略。
[RFC3138] delegated to the RIRs the assignment of the GLOP sub-block (233.252.0.0 - 233.255.255.255) mapped by the private Autonomous System (AS) space (64512-65534) and the IANA reserved ASN 65535 [RFC1930]. This space was known as Extended GLOP (EGLOP). RFC 3138 should not have asked the RIRs to develop policies for the EGLOP space because [RFC2860] reserves that to the IETF. It is important to make this space available for use by network operators, and it is therefore appropriate to obsolete RFC 3138 and classify this address range as available for AD-HOC assignment as per the guidelines in section 6.
[RFC3138]授权RIRs分配由专用自治系统（AS）空间（64512-65534）和IANA保留ASN 65535[RFC1930]映射的GLOP子块（233.252.0.0-233.255.255）。这个空间被称为扩展GLOP（EGLOP）。RFC 3138不应该要求RIR为EGLOP空间制定政策，因为[RFC2860]将此保留给IETF。重要的是使该空间可供网络运营商使用，因此，根据第6节中的指南，淘汰RFC 3138并将该地址范围分类为可用于临时分配是合适的。
The first /24 in this range, 233.252.0.0/24, is assigned as "MCAST-TEST-NET" for use in documentation and example code. 233.252.0.0/24 SHOULD be used in conjunction with the [RFC2606] domain names example.com or example.net in vendor and protocol documentation. Addresses within 233.252.0.0/24 MUST NOT appear on the public Internet.
此范围内的第一个/24，233.252.0.0/24，被指定为“MCAST-TEST-NET”，用于文档和示例代码中。233.252.0.0/24应与供应商和协议文档中的[RFC2606]域名example.com或example.net一起使用。233.252.0.0/24范围内的地址不得出现在公共互联网上。
Addresses in the Administratively Scoped 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 [RFC3180] 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 [RFC2780], assignments of relative offsets follow an Expert Review, IESG Approval, or Standards Action process. See [IANA] for the current set of assignments.
相对偏移量[RFC2365]用于确保服务可以独立于封闭范围的范围进行定位（有关详细信息，请参阅[RFC3180]）。由于只有256个这样的偏移量，IANA应该只为提供基础设施支持服务的协议分配一个相对偏移量。此类服务的示例包括会话公告协议[RFC2974]。根据[RFC2780]第4.4.2节，相对补偿的分配遵循专家评审、IESG批准或标准行动流程。请参阅[IANA]了解当前的一组作业。
Requests for multicast address assignments can be submitted through the application form on the IANA web site at [IANA-registration]. It is important to submit sufficient detail to allow the IESG designated expert to review the application. If the details given in the request are not clear, or further information is needed, the IESG designated expert may request additional information before assigning an address.
可通过IANA网站[IANA注册]上的申请表提交多播地址分配请求。提交足够的细节以允许IESG指定专家审查申请非常重要。如果请求中给出的详细信息不清楚，或者需要进一步的信息，IESG指定的专家可以在分配地址之前请求额外的信息。
Occasionally, more than one multicast address is required. In these cases, multiple addresses are available in AD-HOC Block III. Where there is a requirement for a very large number of addresses, the assignment will be staged. The additional stages will only be made after the complete use of the initial assignment(s).
有时，需要多个多播地址。在这些情况下，临时区块III中有多个地址可用。如果需要大量地址，则分配将分阶段进行。附加阶段仅在完全使用初始任务后进行。
A separate document describing the policy governing assignment of addresses in the AD-HOC blocks I, II, and III will be developed and published. The format, location, and content has not yet been decided and so these will be documented in a future version of this document.
将编制并出版一份单独的文件，说明特设第一区、第二区和第三区的地址分配政策。格式、位置和内容尚未确定，因此将在本文档的未来版本中记录这些内容。
Given the dynamic nature of IPv4 multicast and its associated infrastructure, 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 [RFC1819] blocks and reclaim those addresses that are not in use on the global Internet (i.e., those applications that can use SSM, GLOP, or Administratively Scoped addressing, or are not globally routed).
IANA还应审查特设“DIS瞬态组”和ST多播组[RFC1819]块中的分配，并回收那些在全球互联网上未使用的地址（即，那些可以使用SSM、GLOP或管理范围寻址，或未全局路由的应用程序）。
It is occasionally appropriate to make temporary assignments that can be renewed as necessary. In cases where this happens the registrant needs to positively request an extension to the temporary assignment or the addresses assigned. When the IANA has not received a request to renew the registration of a temporary assignment within 30 days of the expiry of the assignment, it MUST be removed from the multicast registry.
偶尔适当的做法是安排临时任务，必要时可以续签。在这种情况下，注册人需要积极请求延长临时分配或分配的地址。如果IANA在临时分配到期后30天内未收到更新临时分配注册的请求，则必须将其从多播注册表中删除。
Addresses returned to the IANA when a temporary assignment ends MUST NOT be assigned to anyone other than the last registrant for at least one calendar year.
在至少一个日历年内，临时分配结束时返回IANA的地址不得分配给除最后一个注册人以外的任何人。
Applications MUST NOT use addressing in the IANA reserved blocks.
应用程序不得在IANA保留块中使用寻址。
IANA has updated its IPv4 multicast request and assignment procedures to reflect this document.
IANA已更新其IPv4多播请求和分配过程，以反映本文档。
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, Thomas Narten, Marshall Eubanks, Zaid Albanna (co-author of RFC 3171), Kevin Almeroth (co-author of RFC 3171), Pekka Savola, and Alfred Hoenes for their constructive feedback and comments.
作者感谢Joe St.Sauver、John Meylor、Randy Bush、Thomas Narten、Marshall Eubanks、Zaid Albanna（RFC 3171的合著者）、Kevin Almeroth（RFC 3171的合著者）、Pekka Savola和Alfred Hoenes的建设性反馈和评论。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[IANA] IANA, "IANA Protocol Registries", <http://www.iana.org/>.
[IANA]IANA，“IANA协议注册”<http://www.iana.org/>.
[IANA-protocols] IANA, "IANA Protocol Registries", <http://www.iana.org/protocols>.
[IANA协议]IANA，“IANA协议注册”<http://www.iana.org/protocols>.
[IANA-registration] IANA, "IANA Protocol Registration Forms", <http://www.iana.org/protocols/apply>.
[IANA注册]IANA，“IANA协议注册表”<http://www.iana.org/protocols/apply>.
[RFC1819] Delgrossi, L., Ed., and L. Berger, Ed., "Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+", RFC 1819, August 1995.
[RFC1819]Delgrossi，L.，Ed.，和L.Berger，Ed.，“互联网流协议版本2（ST2）协议规范-版本ST2+”，RFC 18191995年8月。
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996.
[RFC1930]霍金森，J.和T.贝茨，“自主系统（AS）的创建、选择和注册指南”，BCP 6，RFC 1930，1996年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月。
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]Eastlake 3rd，D.和A.Panitz，“保留顶级DNS名称”，BCP 32，RFC 26061999年6月。
[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月。
[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月。
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC2860]Carpenter，B.，Baker，F.和M.Roberts，“关于互联网分配号码管理局技术工作的谅解备忘录”，RFC 28602000年6月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，2000年10月。
[RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June 2001.
[RFC3138]Meyer，D.，“233/8年的延长任务”，RFC 3138，2001年6月。
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 3171, August 2001.
[RFC3171]Albanna，Z.，Almeroth，K.，Meyer，D.，和M.Schipper，“IPv4多播地址分配的IANA指南”，BCP 51，RFC 3171，2001年8月。
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001.
[RFC3180]Meyer，D.和P.Lothberg，“233/8中的GLOP寻址”，BCP 53，RFC 31802001年9月。
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4330]Mills，D.“IPv4、IPv6和OSI的简单网络时间协议（SNTP）第4版”，RFC 4330，2006年1月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[SDR] University College London / ISI, "Session Directory Tool", <http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/>.
[SDR]伦敦大学学院/ISI，“会话目录工具”<http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/>.
Authors' Addresses
作者地址
Michelle Cotton Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 United States of America
Michelle Cotton互联网公司，地址：美国加利福尼亚州马里纳德雷市海军部路4676号330室，邮编：90292
Phone: +310-823-9358
EMail: michelle.cotton@icann.org
URI: http://www.iana.org/
Phone: +310-823-9358
EMail: michelle.cotton@icann.org
URI: http://www.iana.org/
Leo Vegoda Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 United States of America
利奥·维戈达互联网公司，地址：美国加利福尼亚州马里纳·德雷市海军部路4676号330室，邮编：90292
Phone: +310-823-9358
EMail: leo.vegoda@icann.org
URI: http://www.iana.org/
Phone: +310-823-9358
EMail: leo.vegoda@icann.org
URI: http://www.iana.org/
David Meyer
大卫·梅耶尔
EMail: dmm@1-4-5.net
EMail: dmm@1-4-5.net