Internet Engineering Task Force (IETF) T. Manderson
Request for Comments: 6491 L. Vegoda
Category: Standards Track ICANN
ISSN: 2070-1721 S. Kent
BBN
February 2012
Internet Engineering Task Force (IETF) T. Manderson
Request for Comments: 6491 L. Vegoda
Category: Standards Track ICANN
ISSN: 2070-1721 S. Kent
BBN
February 2012
Resource Public Key Infrastructure (RPKI) Objects Issued by IANA
IANA发布的资源公钥基础设施（RPKI）对象
Abstract
摘要
This document provides specific direction to IANA as to the Resource Public Key Infrastructure (RPKI) objects it should issue.
本文档就IANA应该发布的资源公钥基础设施（RPKI）对象向IANA提供了具体指导。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见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/rfc6491.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6491.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Required Reading . . . . . . . . . . . . . . . . . . . . . . . 3
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Reserved Resources . . . . . . . . . . . . . . . . . . . . . . 4
6. Unallocated Resources . . . . . . . . . . . . . . . . . . . . 4
7. Special Purpose Registry Resources . . . . . . . . . . . . . . 4
8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. Informational Objects . . . . . . . . . . . . . . . . . . . . 5
10. Certificates and Certificate Revocation Lists (CRLs) . . . . . 5
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
12. Security Considerations . . . . . . . . . . . . . . . . . . . 6
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
14.1. Normative References . . . . . . . . . . . . . . . . . . 6
14.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. IANA Reserved IPv4 Address Blocks . . . . . . . . . . 10
Appendix B. IANA Reserved IPv6 Address Blocks . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Required Reading . . . . . . . . . . . . . . . . . . . . . . . 3
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Reserved Resources . . . . . . . . . . . . . . . . . . . . . . 4
6. Unallocated Resources . . . . . . . . . . . . . . . . . . . . 4
7. Special Purpose Registry Resources . . . . . . . . . . . . . . 4
8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. Informational Objects . . . . . . . . . . . . . . . . . . . . 5
10. Certificates and Certificate Revocation Lists (CRLs) . . . . . 5
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
12. Security Considerations . . . . . . . . . . . . . . . . . . . 6
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
14.1. Normative References . . . . . . . . . . . . . . . . . . 6
14.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. IANA Reserved IPv4 Address Blocks . . . . . . . . . . 10
Appendix B. IANA Reserved IPv6 Address Blocks . . . . . . . . . . 11
"An Infrastructure to Support Secure Internet Routing" [RFC6480] directs IANA [RFC2860] to issue Resource Public Key Infrastructure (RPKI) objects for which it is authoritative. This document describes the objects IANA will issue. If IANA is directed to issue additional RPKI objects in future, this document will be revised and a new version issued.
“支持安全Internet路由的基础设施”[RFC6480]指示IANA[RFC2860]发布其权威的资源公钥基础设施（RPKI）对象。本文档描述了IANA将发布的对象。如果IANA被指示在未来发布额外的RPKI对象，则将修订本文件并发布新版本。
The signed objects described here that IANA will issue are the unallocated, reserved, special use IPv4 and IPv6 address blocks, and the unallocated and reserved Autonomous System numbers. These number resources are managed by IANA for the IETF; thus, IANA bears the responsibility of issuing the corresponding RPKI objects. The reader is encouraged to consider the technical effects on the public routing system of the signed object issuance proposed for IANA in this document.
这里描述的IANA将发布的签名对象是未分配、保留、特殊用途的IPv4和IPv6地址块，以及未分配和保留的自治系统号。这些数字资源由IANA为IETF管理；因此，IANA负责发布相应的RPKI对象。鼓励读者考虑在本文档中为IANA提出的签名对象发布的公共路由系统的技术效果。
This document does not deal with BGP [RFC4271] routing systems, as those are under the policy controls of the organizations that operate them. Readers are directed to "Local Trust Anchor Management for the Resource Public Key Infrastructure" [TA-MGMT] for a description of how to locally override IANA issued objects, e.g., to enable use of unallocated, reserved, and special use IPv4 and IPv6 address blocks in a local context.
本文件不涉及BGP[RFC4271]路由系统，因为这些路由系统受运营这些系统的组织的政策控制。读者请参阅“资源公钥基础设施的本地信任锚管理”[TA-MGMT]，了解如何本地覆盖IANA发布的对象，例如，在本地上下文中启用未分配、保留和特殊用途IPv4和IPv6地址块。
The direction to IANA contained herein follows the ideal that it should represent the ideal technical behavior for registry and related registry actions.
本文中对IANA的指导遵循的理想是，它应该代表注册表和相关注册表操作的理想技术行为。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Readers should be familiar with the RPKI, the RPKI repository structure, and the various RPKI objects, uses, and interpretations described in the following: [RFC6480], [RFC6487], [RFC6482], [RFC6493], [TA-MGMT], [RFC6483], [RPKI-USE], [RFC6484], and [RFC6486].
读者应该熟悉RPKI、RPKI存储库结构以及以下[RFC6480]、[RFC6487]、[RFC6482]、[RFC6493]、[TA-MGMT]、[RFC6483]、[RPKI-USE]、[RFC6484]和[RFC6486]中描述的各种RPKI对象、用途和解释。
Note: The addresses used in this document are not example addresses; therefore, they are not compliant with [RFC3849], [RFC5735], and [RFC5771]. This is intentional, as the practices described in this document are directed to specific instances of real world addresses.
注：本文件中使用的地址不是示例地址；因此，它们不符合[RFC3849]、[RFC5735]和[RFC5771]。这是有意的，因为本文档中描述的实践是针对真实世界地址的特定实例的。
Internet Number Resources (INR): The number identifiers for IPv4 [RFC0791] and IPv6 [RFC2460] addresses, and for Autonomous Systems (ASes).
Internet数字资源（INR）：IPv4[RFC0791]和IPv6[RFC2460]地址以及自治系统（ASE）的数字标识符。
IANA: Internet Assigned Numbers Authority (a traditional name, used here to refer to the technical team making and publishing the assignments of Internet protocol technical parameters). The technical team of IANA is currently a part of ICANN [RFC2860].
IANA：互联网分配号码管理局（传统名称，此处用于指制定和发布互联网协议技术参数分配的技术团队）。IANA的技术团队目前是ICANN[RFC2860]的一部分。
RPKI: Resource Public Key Infrastructure. A Public Key Infrastructure designed to provide a secure basis for assertions about holdings of Internet number resources. Certificates issued under the RPKI contain additional attributes that identify IPv4, IPv6, and Autonomous System number resources [RFC6480].
资源公钥基础设施。一种公开密钥基础设施，旨在为有关互联网号码资源持有情况的断言提供安全基础。在RPKI下颁发的证书包含标识IPv4、IPv6和自治系统号资源的附加属性[RFC6480]。
ROA: Route Origination Authorization. A ROA is an RPKI object that enables the holder of the address prefix to specify an AS that is permitted to originate (in BGP) routes for that prefix [RFC6482].
ROA：路由发起授权。ROA是一个RPKI对象，它使地址前缀的持有者能够指定允许为该前缀发起（在BGP中）路由的AS[RFC6482]。
AS 0 ROA: A ROA containing a value of 0 in the ASID field. "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origination Authorizations (ROAs)" [RFC6483] states "A ROA with a subject of AS 0 (AS 0 ROA) is
AS 0 ROA：在ASID字段中包含值0的ROA。“使用资源证书公钥基础设施（PKI）和路由发起授权（ROA）验证路由发起”[RFC6483]声明“主题为AS 0（AS 0 ROA）的ROA是
an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context."
由前缀持有人证明，在路由上下文中不应使用ROA中描述的前缀以及任何更具体的前缀。”
"Not intended to be (publicly) routed": This phrase refers to prefixes that are not meant to be represented in the global Internet routing table (for example 192.168/16 [RFC1918]).
“不打算（公开）路由”：此短语指的是不打算在全局Internet路由表中表示的前缀（例如192.168/16[RFC1918]）。
Reserved IPv4 and IPv6 resources are held back for various reasons by IETF action. Generally, such resources are not intended to be globally routed. An example of such a reservation is 127.0.0.0/8 [RFC5735]. See Appendixes A and B for IANA reserved resources.
保留的IPv4和IPv6资源因各种原因被IETF操作阻止。通常，此类资源不打算全局路由。这种保留的一个例子是127.0.0.0/8[RFC5735]。IANA保留资源见附录A和附录B。
IANA SHOULD issue an AS 0 ROA for all reserved IPv4 and IPv6 resources not intended to be routed. The selection of the [RFC2119] terminology is intentional as there may be situations where the AS 0 ROA is removed or not issued prior to an IANA registry action. It is not appropriate to place IANA into a situation where, through normal internal operations, its behavior contradicts IETF standards.
IANA应为所有不打算路由的保留IPv4和IPv6资源发出AS 0 ROA。[RFC2119]术语的选择是有意的，因为在IANA注册行动之前，可能存在as 0 ROA被删除或未发布的情况。将IANA置于通过正常内部操作其行为违反IETF标准的情况下是不合适的。
There are a small number of reserved resources that are intended to be routed, for example 192.88.99.0/24 [RFC3068]. See Appendixes A and B for IANA reserved resources.
有少量预定路由的保留资源，例如192.88.99.0/24[RFC3068]。IANA保留资源见附录A和附录B。
IANA MUST NOT issue any ROAs (AS 0 or otherwise) for reserved resources that are expected to be globally routed.
IANA不得为预期全局路由的保留资源颁发任何ROA（0或其他形式）。
Internet Number Resources that have not yet been allocated for special purposes [RFC5736], to Regional Internet Registries (RIRs), or to others are considered as not intended to be globally routed.
尚未分配用于特殊目的[RFC5736]、区域互联网注册中心（RIR）或其他目的的互联网号码资源被视为不打算进行全球路由。
IANA SHOULD issue an AS 0 ROA for all Unallocated Resources. The selection of the [RFC2119] terminology is intentional as there may be situations where the AS 0 ROA is removed or not issued prior to an IANA registry action. It is not appropriate to place IANA into a situation where, through normal internal operations, its behavior contradicts IETF standards.
IANA应为所有未分配的资源颁发AS 0 ROA。[RFC2119]术语的选择是有意的，因为在IANA注册行动之前，可能存在as 0 ROA被删除或未发布的情况。将IANA置于通过正常内部操作其行为违反IETF标准的情况下是不合适的。
Special Registry Resources [RFC5736] fall into one of two categories in terms of routing. Either the resource is intended to be seen in the global Internet routing table in some fashion, or it isn't. An example of a Special Registry Resources INR that is intended for
特殊注册表资源[RFC5736]在路由方面分为两类。资源可能会以某种方式出现在全局Internet路由表中，也可能不会。一个特殊注册资源INR的示例，用于
global routing is 2001::/32 [RFC4380]. An example of an INR not intended to be seen would be 2001:002::/48 [RFC5180].
全局路由为2001:：/32[RFC4380]。不希望看到的INR示例为2001:002:：/48[RFC5180]。
IANA MUST NOT issue any ROAs (AS 0 or otherwise) for Special Purpose Registry Resources that are intended to be globally routed.
IANA不得为拟进行全局路由的特殊用途注册表资源颁发任何ROA（如0或其他）。
IANA SHOULD issue an AS 0 ROA for Special Purpose Registry Resources that are not intended to be globally routed.
IANA应为不打算全局路由的特殊用途注册表资源颁发AS 0 ROA。
Within the IPv4 multicast [RFC5771] and IPv6 multicast [RFC4291] registries there are a number of Multicast registrations that are not intended to be globally routed.
在IPv4多播[RFC5771]和IPv6多播[RFC4291]注册表中，存在许多不打算全局路由的多播注册。
IANA MUST issue an AS 0 ROA covering the following IPv4 and IPv6 multicast INRs:
IANA必须发布覆盖以下IPv4和IPv6多播INR的AS 0 ROA：
IPv4: - Local Network Control Block 224.0.0.0 - 224.0.0.255 (224.0.0/24) - IANA Reserved portions of RESERVED 224.1.0.0-224.1.255.255 (224.1/16) - RESERVED 224.5.0.0-224.251.255.255 (251 /16s) 225.0.0.0-231.255.255.255 (7 /8s)
IPv4:-本地网络控制块224.0.0.0-224.0.0.255（224.0.0/24）-保留224.1.0-224.1.255.255（224.1/16）的IANA保留部分-保留224.5.0.0-224.251.255.255（251/16s）225.0.0.0-231.255.255（7/8s）
IPv6: - Node-Local Scope Multicast Addresses - Link-Local Scope Multicast Addresses
IPv6:-节点本地作用域多播地址-链路本地作用域多播地址
IANA MUST NOT issue any ROAs (AS 0 or otherwise) for any other multicast addresses unless directed by an IESG-approved Standards Track document with an appropriate IANA Considerations section.
IANA不得为任何其他多播地址颁发任何ROA（如0或其他），除非IESG批准的标准跟踪文件中有适当的IANA注意事项部分另有指示。
One informational object that can exist at a publication point of an RPKI repository is the Ghostbusters Record [RFC6493].
RPKI存储库的发布点上可能存在的一个信息对象是Ghostbusters记录[RFC6493]。
IANA MUST issue a ghostbusters object appropriate in content for the resources IANA maintains.
IANA必须为IANA维护的资源发布内容中合适的ghostbusters对象。
Before IANA can issue a ROA, it MUST first establish an RPKI Certification Authority (CA) that covers unallocated, reserved, and special use INRs. A CA that covers these INRs MUST contain RFC 3379
IANA在发布ROA之前，必须首先建立一个RPKI认证机构（CA），涵盖未分配、保留和特殊用途的INR。涵盖这些INR的CA必须包含RFC 3379
extensions [RFC3779] for those corresponding number resources in its certificate. This CA MUST issue single-use end-entity (EE) certificates for each ROA that it generates. The EE certificate will conform to the Resource Certificate Profile [RFC6487] and the additional constraints specified in [RFC6482]. IANA MUST maintain a publication point for this CA's use and MUST publish manifests [RFC6486] (with its corresponding EE certificate) for this publication point. IANA MUST issue a CRL under this CA certificate for the EE certificates noted above. All objects issued by this CA will conform to the RPKI Certificate Policy [RFC6484].
扩展[RFC3779]，用于其证书中相应的数字资源。该CA必须为其生成的每个ROA颁发单一使用终端实体（EE）证书。EE证书将符合资源证书配置文件[RFC6487]和[RFC6482]中指定的附加约束。IANA必须维护此CA使用的发布点，并且必须为此发布点发布清单[RFC6486]（及其相应的EE证书）。IANA必须根据本CA证书为上述EE证书颁发CRL。此CA颁发的所有对象都将符合RPKI证书策略[RFC6484]。
This document directs IANA to issue, or refrain from issuing, the specific RPKI objects described here for the current set of reserved, unallocated, and special registry Internet Number Resources. Further, IANA MUST notify all other INR registries that RPKI objects have been issued for the Internet Number Resources described in this document to avoid the potential for issuance of duplicate objects that might confuse relying parties.
本文档指示IANA针对当前保留、未分配和特殊注册表Internet编号资源集发布或不发布此处描述的特定RPKI对象。此外，IANA必须通知所有其他INR注册中心，已针对本文件中所述的互联网号码资源发布了RPKI对象，以避免发布可能会混淆依赖方的重复对象。
This document does not alter the security profile of the RPKI from that already discussed in SIDR WG documents.
本文件不会改变已在SIDR工作组文件中讨论的RPKI安全配置文件。
The authors acknowledge Dave Meyer for helpful direction with regard to multicast assignments.
作者感谢Dave Meyer在多播分配方面提供的有用指导。
[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月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480]Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，RFC 6480，2012年2月。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6482]Lepinski，M.，Kent，S.，和D.Kong，“路线原产地授权（ROA）的配置文件”，RFC 64822012年2月。
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, February 2012.
[RFC6483]Huston，G.和G.Michaelson，“使用资源证书公钥基础设施（PKI）和路由起源授权（ROA）验证路由起源”，RFC 6483，2012年2月。
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, February 2012.
[RFC6484]Kent，S.，Kong，D.，Seo，K.，和R.Watro，“资源公钥基础设施（RPKI）的证书政策（CP）”，BCP 173，RFC 6484，2012年2月。
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, February 2012.
[RFC6486]Austein，R.，Huston，G.，Kent，S.，和M.Lepinski，“资源公钥基础设施（RPKI）清单”，RFC 64862012年2月。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC6487]Huston，G.，Michaelson，G.，和R.Loomans，“X.509 PKIX资源证书的配置文件”，RFC 6487，2012年2月。
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, February 2012.
[RFC6493]布什，R.，“资源公钥基础设施（RPKI）捉鬼记录”，RFC6493，2012年2月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC 919, October 1984.
[RFC0919]Mogul，J.，“广播互联网数据报”，STD 5，RFC 919，1984年10月。
[RFC0922] Mogul, J., "Broadcasting Internet datagrams in the presence of subnets", STD 5, RFC 922, October 1984.
[RFC0922]Mogul，J.，“在存在子网的情况下广播互联网数据报”，STD 5，RFC 922，1984年10月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[RFC2544]Bradner，S.和J.McQuaid，“网络互连设备的基准测试方法”，RFC 2544，1999年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月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068]Huitema，C.，“6to4中继路由器的选播前缀”，RFC3068，2001年6月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779]Lynn，C.，Kent，S.，和K.Seo，“IP地址和AS标识符的X.509扩展”，RFC 3779，2004年6月。
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004.
[RFC3849]Huston，G.，Lord，A.，和P.Smith，“为文档保留IPv6地址前缀”，RFC 3849，2004年7月。
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.
[RFC3879]Huitema，C.和B.Carpenter，“不推荐现场本地地址”，RFC 3879，2004年9月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927]Cheshire，S.，Aboba，B.和E.Guttman，“IPv4链路本地地址的动态配置”，RFC 3927，2005年5月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
[RFC4843]Nikander，P.，Laganier，J.，和F.Dupont，“覆盖可路由加密哈希标识符（RAYD）的IPv6前缀”，RFC 4843，2007年4月。
[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, "IPv6 Benchmarking Methodology for Network Interconnect Devices", RFC 5180, May 2008.
[RFC5180]Popoviciu，C.，Hamza，A.，Van de Velde，G.，和D.Dugatkin，“网络互连设备的IPv6基准测试方法”，RFC 51802008年5月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]Cotton，M.和L.Vegoda，“特殊用途IPv4地址”，BCP 153，RFC 57352010年1月。
[RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special Purpose Address Registry", RFC 5736, January 2010.
[RFC5736]Huston，G.，Cotton，M.和L.Vegoda，“IANA IPv4专用地址注册”，RFC 57362010年1月。
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010.
[RFC5737]Arkko，J.，Cotton，M.和L.Vegoda，“为文档保留的IPv4地址块”，RFC 5737，2010年1月。
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, March 2010.
[RFC5771]Cotton，M.，Vegoda，L.，和D.Meyer，“IPv4多播地址分配的IANA指南”，BCP 51，RFC 57712010年3月。
[RPKI-USE] Manderson, T., Sriram, K., and R. White, "Use Cases and Interpretation of RPKI Objects for Issuers and Relying Parties", Work in Progress, October 2011.
[RPKI-USE]Manderson，T.，Sriram，K.，和R.White，“发行人和依赖方RPKI对象的用例和解释”，正在进行的工作，2011年10月。
[TA-MGMT] Reynolds, M. and S. Kent, "Local Trust Anchor Management for the Resource Public Key Infrastructure", Work in Progress, December 2011.
[TA-MGMT]Reynolds，M.和S.Kent，“资源公钥基础设施的本地信任锚管理”，正在进行的工作，2011年12月。
This list of Address Space and RFCs was correct at the time of writing this document.
在编写本文档时，此地址空间和RFC列表是正确的。
+--------------------+------------------------------------+---------+
| Prefix | RFC | TBR |
+--------------------+------------------------------------+---------+
| 0.0.0.0/8 | [RFC1122], Section 3.2.1.3 | No |
| 10.0.0.0/8 | [RFC1918] | No |
| 127.0.0.0/8 | [RFC1122], Section 3.2.1.3 | No |
| 169.254.0.0/16 | [RFC3927] | No |
| 172.16.0.0/12 | [RFC1918] | No |
| 192.0.0.0/24 | [RFC5736] | Various |
| 192.0.2.0/24 | [RFC5737] | No |
| 192.88.99.0/24 | [RFC3068] | Yes |
| 192.168.0.0/16 | [RFC1918] | No |
| 198.18.0.0/15 | [RFC2544] | No |
| 198.51.100.0/24 | [RFC5737] | No |
| 203.0.113.0/24 | [RFC5737] | No |
| 224.0.0.0/4 | [RFC5771] | No |
| 240.0.0.0/4 | [RFC1112], Section 4 | No |
| 255.255.255.255/32 | [RFC0919], Section 7 and | No |
| | [RFC0922], Section 7 | |
+--------------------+------------------------------------+---------+
+--------------------+------------------------------------+---------+
| Prefix | RFC | TBR |
+--------------------+------------------------------------+---------+
| 0.0.0.0/8 | [RFC1122], Section 3.2.1.3 | No |
| 10.0.0.0/8 | [RFC1918] | No |
| 127.0.0.0/8 | [RFC1122], Section 3.2.1.3 | No |
| 169.254.0.0/16 | [RFC3927] | No |
| 172.16.0.0/12 | [RFC1918] | No |
| 192.0.0.0/24 | [RFC5736] | Various |
| 192.0.2.0/24 | [RFC5737] | No |
| 192.88.99.0/24 | [RFC3068] | Yes |
| 192.168.0.0/16 | [RFC1918] | No |
| 198.18.0.0/15 | [RFC2544] | No |
| 198.51.100.0/24 | [RFC5737] | No |
| 203.0.113.0/24 | [RFC5737] | No |
| 224.0.0.0/4 | [RFC5771] | No |
| 240.0.0.0/4 | [RFC1112], Section 4 | No |
| 255.255.255.255/32 | [RFC0919], Section 7 and | No |
| | [RFC0922], Section 7 | |
+--------------------+------------------------------------+---------+
TBR: To Be Routed, the intention of the RFC pertaining to the address block.
待路由：与地址块有关的RFC的意图。
Table 1: IPv4 Address Blocks and the RFCs that Direct IANA to Reserve Them
表1:IPv4地址块和指示IANA保留它们的RFC
This list of Address Space and RFCs was correct at the time of writing this document.
在编写本文档时，此地址空间和RFC列表是正确的。
+----------------+-----------+-----+
| Prefix | RFC | TBR |
+----------------+-----------+-----+
| 0000::/8 | [RFC4291] | No |
| 0100::/8 | [RFC4291] | No |
| 0200::/7 | [RFC4291] | No |
| 0400::/6 | [RFC4291] | No |
| 0800::/5 | [RFC4291] | No |
| 1000::/4 | [RFC4291] | No |
| 4000::/3 | [RFC4291] | No |
| 6000::/3 | [RFC4291] | No |
| 8000::/3 | [RFC4291] | No |
| A000::/3 | [RFC4291] | No |
| C000::/3 | [RFC4291] | No |
| E000::/4 | [RFC4291] | No |
| F000::/5 | [RFC4291] | No |
| F800::/6 | [RFC4291] | No |
| FC00::/7 | [RFC4193] | No |
| FE00::/9 | [RFC4291] | No |
| FE80::/10 | [RFC4291] | No |
| FEC0::/10 | [RFC3879] | No |
| FF00::/8 | [RFC4291] | No |
| 2001:0002::/48 | [RFC5180] | No |
| 2001:10::/28 | [RFC4843] | No |
+----------------+-----------+-----+
+----------------+-----------+-----+
| Prefix | RFC | TBR |
+----------------+-----------+-----+
| 0000::/8 | [RFC4291] | No |
| 0100::/8 | [RFC4291] | No |
| 0200::/7 | [RFC4291] | No |
| 0400::/6 | [RFC4291] | No |
| 0800::/5 | [RFC4291] | No |
| 1000::/4 | [RFC4291] | No |
| 4000::/3 | [RFC4291] | No |
| 6000::/3 | [RFC4291] | No |
| 8000::/3 | [RFC4291] | No |
| A000::/3 | [RFC4291] | No |
| C000::/3 | [RFC4291] | No |
| E000::/4 | [RFC4291] | No |
| F000::/5 | [RFC4291] | No |
| F800::/6 | [RFC4291] | No |
| FC00::/7 | [RFC4193] | No |
| FE00::/9 | [RFC4291] | No |
| FE80::/10 | [RFC4291] | No |
| FEC0::/10 | [RFC3879] | No |
| FF00::/8 | [RFC4291] | No |
| 2001:0002::/48 | [RFC5180] | No |
| 2001:10::/28 | [RFC4843] | No |
+----------------+-----------+-----+
TBR: To Be Routed, the intention of the RFC pertaining to the address block.
待路由：与地址块有关的RFC的意图。
Table 2: IPv6 Address Blocks and the RFCs that Direct IANA to Reserve Them
表2:IPv6地址块和指示IANA保留它们的RFC
Authors' Addresses
作者地址
Terry Manderson Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 United States of America
Terry Manderson互联网名称和编号分配公司美国加利福尼亚州马里纳德雷市海军部路4676号330室90292
Phone: +1-310-823-9358
EMail: terry.manderson@icann.org
URI: http://www.iana.org/
Phone: +1-310-823-9358
EMail: terry.manderson@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: +1-310-823-9358
EMail: leo.vegoda@icann.org
URI: http://www.iana.org/
Phone: +1-310-823-9358
EMail: leo.vegoda@icann.org
URI: http://www.iana.org/
Steve Kent BBN
史蒂夫·肯特BBN
EMail: kent@bbn.com
EMail: kent@bbn.com