diff options
author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
---|---|---|
committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6254.txt | |
parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6254.txt')
-rw-r--r-- | doc/rfc/rfc6254.txt | 171 |
1 files changed, 171 insertions, 0 deletions
diff --git a/doc/rfc/rfc6254.txt b/doc/rfc/rfc6254.txt new file mode 100644 index 0000000..dde072a --- /dev/null +++ b/doc/rfc/rfc6254.txt @@ -0,0 +1,171 @@ + + + + + + +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 + +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. + +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. + + 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. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + + + +McFadden Informational [Page 1] + +RFC 6254 RFC 2754 to Historic Status May 2011 + + +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 + + 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. + + 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. + +2. Details + + 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. + + 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. + + + + +McFadden Informational [Page 2] + +RFC 6254 RFC 2754 to Historic Status May 2011 + + + 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. + +3. Terminology + + 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. + +4. IANA Considerations + + IANA is instructed not to pursue or implement the IANA actions + requested in RFC 2754 [RFC2754]. + +5. Security Considerations + + 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. + +6. Acknowledgments + + 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. + +7. Informative Reference + + [RFC2754] Alaettinoglu, C., Villamizar, C., and R. Govindan, "RPS + IANA Issues", RFC 2754, January 2000. + +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 + + + + +McFadden Informational [Page 3] + |