RFC 6996

Autonomous System (AS) Reservation for Private Use

📅 published July 2013, from ietf

Abstract 🎀

okay bestie, this RFC is all about Private Use ASNs 🦋. Those are Autonomous System Numbers that are only for private use, and the doc gives operators guidance on using them. The main drama: it grows the Private Use pool by reserving a second, much bigger range, and it updates RFC 1930 by replacing that doc's Section 10. 💅

Title Block 📜

so the official facts are: this is RFC 6996, titled "Autonomous System (AS) Reservation for Private Use" 💖. It's by J. Mitchell (that's Jon Mitchell at Microsoft Corporation) 🫶. It's a Best Current Practice (BCP 6) published in July 2013 🌸. It's been through the IETF process and is marked ISSN 2070-1721 ✨. It updates RFC 1930 🍓.

Status of This Memo 🌈

this memo documents an Internet Best Current Practice 🧚

it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 👑. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💅. more info on BCPs is in Section 2 of RFC 5741 🔥.

for the current status, errata, and feedback, check http://www.rfc-editor.org/info/rfc6996 💜.

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date 📜. please actually read those, bestie, because they spell out your rights and restrictions for this doc 🙈. any Code Components pulled out of this doc must include the Simplified BSD License text (see Section 4.e of the Trust Legal Provisions) and come with no warranty, as the Simplified BSD License describes 🫶.

1. Introduction ✨

okay so the original IANA reservation for Private Use ASNs was a block of 1023 ASNs 🌸. the IETF wrote that down in Section 10 of [RFC1930] 💖. since then, BGP [RFC4271] has shown up in new places like data center networks, and those places need a bigger Private Use AS space 🦋.

after "BGP Support for Four-Octet Autonomous System (AS) Number Space" [RFC6793] came out, the total ASN space blew up 🚀. so there's now a much larger slice that operators can use for these private cases ✨. the existing Private Use range is already widely deployed, though, and you can't really renumber it in live networks 😭. these ASNs aren't registered by definition, so there's no coordinating a switch-over 💀. so this RFC documents the existing Private Use reservation and also adds a second, bigger range that people can use too 👑.

2. Requirements Language 🎀

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119] 💅.

3. Private Use ASNs 🧚

to keep BGP growing in new network apps that use Private Use ASNs, two ranges get reserved by Section 5 of this document 🌈. the first one is part of the original 16-bit Autonomous System range from [RFC1930] 🍓. the second is a much bigger range from the Four-Octet AS Number Space [RFC6793] 🔥.

4. Operational Considerations 💜

this part is the real tea 🫖. if you use Private Use ASNs and prefixes come from them, Private Use ASNs MUST be removed from AS path attributes before they get advertised to the global Internet 🚫. that includes AS4_PATH if you're using the four-octet AS number space 🦋.

operators SHOULD make sure that all External Border Gateway Protocol (EBGP) speakers support the extensions in [RFC6793] 🫶. they should also update any implementation-specific features that recognize Private Use ASNs so they recognize both ranges. they need to do that before using the newer, numerically higher range of Private Use ASNs in the four-octet AS number space 🌸.

the bad news: some existing implementations that strip Private Use ASNs out of the AS_PATH are known to not strip them when the AS_PATH mixes Private Use and Non-Private Use ASNs 😭. if those implementations haven't been updated to recognize the new range, and a mix of old-range and new-range Private Use ASNs shows up in the AS4_PATH, they'll probably stop removing Private Use ASNs from either AS path attribute 💀.

normal AS path filtering MAY also be used to stop prefixes originating from Private Use ASNs from getting advertised to the global Internet 🛡️.

5. IANA Considerations 🌷

IANA reserved a contiguous block of 1023 Autonomous System numbers for Private Use from the "16-bit Autonomous System Numbers" registry 🎀. that's 64512 - 65534 inclusive 💖.

IANA also reserved a contiguous block of 94,967,295 Autonomous System numbers for Private Use from the "32-bit Autonomous System Numbers" registry ✨. that's 4200000000 - 4294967294 inclusive 🦋.

these reservations are documented in the IANA "Autonomous System (AS) Numbers" registry [IANA.AS] 🧚.

6. Security Considerations 💀

okay, serious moment 🙈. Private Use ASNs don't raise any unique security concerns 🫶. but using them wrong can break connectivity, especially outside a single organization, because they aren't globally unique 😱. that connectivity loss stays contained to the org misusing them, or using them without reference to Section 4 🔥.

general BGP security stuff is covered in [RFC4271] and [RFC4272] 📜. if you want to figure out who originated a route with a Private Use ASN in its AS path, you'd have to trace the route back to the nearest globally unique AS in the path, or look at other attributes 🕵️‍♀️.

7. References 📚

7.1. Normative References 💜

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🎀
  • [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. 🌸
  • [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, December 2012. 🦋

7.2. Informative References 🌈

8. Acknowledgements 🫶

the author wants to give a huge shoutout to Christopher Morrow, Jason Schiller, and John Scudder for their advice on pursuing this change 👑. thank you also to Brian Dickson, David Farmer, Jeffrey Haas, Nick Hilliard, Joel Jaeggli, Warren Kumari, and Jeff Wheeler for their comments and suggestions 💖🧚.

Author's Address 💅

Jon Mitchell Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA

EMail: Jon.Mitchell@microsoft.com 🦋

📦 where this page comes from