RFC 6254

Request to Move RFC 2754 to Historic Status

📅 published May 2011, from ietf

Request to Move RFC 2754 to Historic Status 💖

  • RFC number: 6254
  • Series: Internet Engineering Task Force (IETF)
  • Author: M. McFadden (Mark McFadden, ICANN) 🎀
  • Category: Informational
  • Date: May 2011
  • Obsoletes: RFC 2754
  • Updates: nothing listed
  • ISSN: 2070-1721

Abstract ✨

okay so RFC 2754 asked that every time IANA made an address assignment, it would create the right inetnum and as-block objects and digitally sign them 🔏. The whole point was to get the IANA-held public key into software implementations of the Distributed Routing Policy System. Plot twist: this never actually happened on the public Internet 💀. This document asks for RFC 2754 to be moved to Historic status 🦋.

Status of This Memo 🌸

This document is not an Internet Standards Track specification, so it's published just for information 💅.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 🧚.

You can find out the current status of this document, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc6254 ✨.

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 read these documents carefully, because they explain 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 they come without warranty as described in the Simplified BSD License 🫶.

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 in charge of 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] asked IANA to create a repository of Routing Policy Specification Language (RPSL) objects and digitally sign them 🔏. It also named the initial objects to be signed, and asked that each time IANA made an address assignment, it would also create new objects as needed and sign those too. Again, in practice, none of this happened on the public Internet 😭. When the IETF reviewed IANA's protocol registration work, this request for IANA action was flagged as one that never got completed after the RFC was published ✨.

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] asked IANA to create a repository of RPSL objects and digitally sign them 🎀. It identified the initial objects to be signed, and it also asked that each time IANA made an address assignment, it would create new objects as needed and sign them as well.

During a review of RFCs in 2009, it became clear that the IANA actions requested in RFC 2754 were never done 🙈. In the meantime, another technology seems to be taking over the role Distributed RPSL was originally meant to play 👑. Both an architecture and infrastructure now exist for secure routing using Resource Public Key Infrastructure (RPKI) technologies 🔥. For example, the IETF has standardized the semantics of a Route Origin Authorization (ROA), which is an application of the RPKI, for validating the origination of routes 🦋.

Implementing the IANA actions in RFC 2754 would now take significant implementation complexity 😵. With alternative technology in the picture, and given that the requested actions were never implemented on the public Internet, it's proposed to reclassify RFC 2754 [RFC2754] as Historic and to direct IANA not to pursue or implement the IANA requests in that document 🫶.

3. Terminology 🌸

The word "allocation" refers to a block of addresses managed by a registry for the purpose of making assignments and allocations. The word "assignment" refers to 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 told 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 happened on 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
📦 where this page comes from