Internet Engineering Task Force (IETF) M. McFadden
Request for Comments: 6254 ICANN
Obsoletes: 2754 May 2011
Category: Informational
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. McFadden
Request for Comments: 6254 ICANN
Obsoletes: 2754 May 2011
Category: Informational
ISSN: 2070-1721
Request to Move RFC 2754 to Historic Status
请求将RFC 2754移至历史状态
Abstract
摘要
RFC 2754 requested that each time IANA made an address assignment, it was to create appropriate inetnum and as-block objects and digitally sign them. The purpose was to distribute the IANA-held public key in software implementations of the Distributed Routing Policy System. In practice, this was never done on the public Internet. This document requests that RFC 2754 be moved to Historic status.
RFC 2754要求IANA每次进行地址分配时，都要创建适当的inetnum和as块对象，并对它们进行数字签名。目的是在分布式路由策略系统的软件实现中分发IANA持有的公钥。实际上，这从未在公共互联网上进行过。本文件要求将RFC 2754移至历史状态。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc6254.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6254.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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. Details .........................................................2
3. Terminology .....................................................3
4. IANA Considerations .............................................3
5. Security Considerations .........................................3
6. Acknowledgments .................................................3
7. Informative Reference ...........................................3
1. Introduction ....................................................2
2. Details .........................................................2
3. Terminology .....................................................3
4. IANA Considerations .............................................3
5. Security Considerations .........................................3
6. Acknowledgments .................................................3
7. Informative Reference ...........................................3
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 2754 [RFC2754] requests that the IANA create a repository of Routing Policy Specification Language (RPSL) objects and digitally sign them. The RFC identifies the initial objects to be signed and also requests that each time IANA makes an address assignment it also create new objects as needed and sign them as well. In practice, this was never done in the public Internet. During a detailed review of IANA's protocol registration activities in support of the IETF, this request for IANA action was identified as one of those that had not been completed after publication of the RFC.
互联网分配号码管理局（IANA）（www.IANA.org）负责为互联网工程任务组（IETF）设计、创建或维护的协议中的字段分配参数值。RFC 2754[RFC2754]请求IANA创建路由策略规范语言（RPSL）对象的存储库并对其进行数字签名。RFC识别要签名的初始对象，并要求IANA在每次进行地址分配时也根据需要创建新对象并对其进行签名。实际上，这在公共互联网上从未实现过。在对IANA支持IETF的协议注册活动进行详细审查期间，IANA行动请求被确定为RFC发布后尚未完成的请求之一。
This document obsoletes RFC 2754 [RFC2754], recommends that it be moved to Historic status, and directs IANA not to move forward with the IANA actions in that RFC.
本文件废除了RFC 2754[RFC2754]，建议将其移至历史状态，并指示IANA不要在该RFC中执行IANA行动。
RFC 2754 [RFC2754] requests that the IANA create a repository of RPSL objects and digitally sign them. The RFC identifies the initial objects to be signed and also requests that each time IANA makes an address assignment it also create new objects as needed and sign them as well.
RFC 2754[RFC2754]请求IANA创建RPSL对象的存储库并对其进行数字签名。RFC识别要签名的初始对象，并要求IANA在每次进行地址分配时也根据需要创建新对象并对其进行签名。
During a review of RFCs in 2009, it became apparent that the IANA actions requested in RFC 2754 were never done. In the intervening time, another technology appears to be taking the role once envisioned for Distributed RPSL. Both an architecture and infrastructure now exist for secure routing using Resource Public Key Infrastructure (RPKI) technologies. As an example, the semantics of a Route Origin Authorization (ROA) -- an application of the RPKI -- to validate the origination of routes has been standardized by the IETF.
在2009年对RFC的审查中，很明显RFC 2754中要求的IANA行动从未完成。在此期间，另一种技术似乎正在扮演分布式RPSL曾经设想的角色。现在，使用资源公钥基础设施（RPKI）技术的安全路由体系结构和基础设施都已存在。例如，路由起源授权（ROA）的语义（RPKI的一个应用程序）已被IETF标准化，用于验证路由的起源。
Implementation of the IANA actions in RFC 2754 would now require significant implementation complexity. In the face of alternative technology, and given that the requested actions have not been implemented in the public Internet, it is proposed to reclassify RFC 2754 [RFC2754] as Historic and to direct the IANA not to pursue or implement the IANA requests in that document.
在RFC 2754中实施IANA行动现在需要极大的实施复杂性。面对替代技术，鉴于请求的行动尚未在公共互联网上实施，建议将RFC 2754[RFC2754]重新归类为历史性的，并指示IANA不要继续或实施该文件中的IANA请求。
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.
“分配”一词指由注册表管理的地址块，用于进行分配和分配。“分配”一词指的是注册给最终用户的地址块或单个地址，用于特定网络或一组网络。
IANA is instructed not to pursue or implement the IANA actions requested in RFC 2754 [RFC2754].
IANA被指示不得执行或实施RFC 2754[RFC2754]中要求的IANA行动。
The intended signature of inetnum and as-block objects never took place in the public Internet. Moving RFC 2754 [RFC2754] to Historic status would have no known impact on the security of the Internet.
inetnum和as块对象的预期签名从未在公共Internet上发生。将RFC 2754[RFC2754]移至历史状态不会对互联网的安全产生已知影响。
The author would like to thank Alfred Hoenes, Russ Housley, Leo Vegoda, Terry Manderson, Jari Arkko, Dan Romascanu, Michelle Cotton, and David Conrad for their constructive feedback and comments.
作者要感谢阿尔弗雷德·霍恩斯、罗斯·霍斯利、利奥·维戈达、特里·曼德森、贾里·阿尔科、丹·罗马斯坎努、米歇尔·科顿和大卫·康拉德的建设性反馈和评论。
[RFC2754] Alaettinoglu, C., Villamizar, C., and R. Govindan, "RPS IANA Issues", RFC 2754, January 2000.
[RFC2754]Alaettinoglu，C.，Villamizar，C.，和R.Govindan，“RPS IANA问题”，RFC 2754，2000年1月。
Author's Address
作者地址
Mark McFadden Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 United States Phone: +1-608-628-2674 EMail: mark.mcfadden@icann.org URI: http://www.iana.org
马克·麦克法登互联网公司，地址：美国加利福尼亚州马里纳·德雷市海军部路4676号330室，邮编：90292电话：+1-608-628-2674电子邮件：马克。mcfadden@icann.orgURI:http://www.iana.org