summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6254.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6254.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6254.txt')
-rw-r--r--doc/rfc/rfc6254.txt171
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]
+