summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6996.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6996.txt')
-rw-r--r--doc/rfc/rfc6996.txt227
1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc6996.txt b/doc/rfc/rfc6996.txt
new file mode 100644
index 0000000..e4ef413
--- /dev/null
+++ b/doc/rfc/rfc6996.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) J. Mitchell
+Request for Comments: 6996 Microsoft Corporation
+BCP: 6 July 2013
+Updates: 1930
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+ Autonomous System (AS) Reservation for Private Use
+
+Abstract
+
+ This document describes the reservation of Autonomous System Numbers
+ (ASNs) that are for Private Use only, known as Private Use ASNs, and
+ provides operational guidance on their use. This document enlarges
+ the total space available for Private Use ASNs by documenting the
+ reservation of a second, larger range and updates RFC 1930 by
+ replacing Section 10 of that document.
+
+Status of This Memo
+
+ This memo documents an Internet Best Current Practice.
+
+ 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). Further information on
+ BCPs is available in 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/rfc6996.
+
+Copyright Notice
+
+ Copyright (c) 2013 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.
+
+
+
+
+Mitchell Best Current Practice [Page 1]
+
+RFC 6996 Private Use AS Reservation July 2013
+
+
+1. Introduction
+
+ The original IANA reservation of Autonomous System Numbers (ASNs) for
+ Private Use was a block of 1023 ASNs. This was also documented by
+ the IETF in Section 10 of [RFC1930]. Since the time that the range
+ was reserved, the Border Gateway Protocol (BGP) [RFC4271] has seen
+ deployment in new application domains, such as data center networks,
+ which require a larger Private Use AS space.
+
+ Since the introduction of "BGP Support for Four-Octet Autonomous
+ System (AS) Number Space" [RFC6793], the total size of ASN space has
+ increased dramatically. A larger subset of the space is available to
+ network operators to deploy in these Private Use cases. The existing
+ range of Private Use ASNs is widely deployed, and the ability to
+ renumber this resource in existing networks cannot be coordinated
+ given that these ASNs, by definition, are not registered. Therefore,
+ this RFC documents the existing Private Use ASN reservation while
+ also introducing a second, larger range that can also be utilized.
+
+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 interpreted as described in RFC 2119 [RFC2119].
+
+3. Private Use ASNs
+
+ To allow the continued growth of BGP protocol usage in new network
+ applications that utilize Private Use ASNs, two ranges of ASNs are
+ reserved by Section 5 of this document. The first is part of the
+ original 16-bit Autonomous System range previously defined in
+ [RFC1930], and the second is a larger range out of the Four-Octet AS
+ Number Space [RFC6793].
+
+4. Operational Considerations
+
+ If Private Use ASNs are used and prefixes originate from these ASNs,
+ Private Use ASNs MUST be removed from AS path attributes (including
+ AS4_PATH if utilizing a four-octet AS number space) before being
+ advertised to the global Internet. Operators SHOULD ensure that all
+ External Border Gateway Protocol (EBGP) speakers support the
+ extensions described in [RFC6793] and that implementation-specific
+ features that recognize Private Use ASNs have been updated to
+ recognize both ranges prior to making use of the newer, numerically
+ higher range of Private Use ASNs in the four-octet AS number space.
+ Some existing implementations that remove Private Use ASNs from the
+ AS_PATH are known to not remove Private Use ASNs if the AS_PATH
+ contains a mixture of Private Use and Non-Private Use ASNs. If such
+
+
+
+Mitchell Best Current Practice [Page 2]
+
+RFC 6996 Private Use AS Reservation July 2013
+
+
+ implementations have not been updated to recognize the new range of
+ ASNs in this document and a mix of old and new range Private Use ASNs
+ exist in the AS4_PATH, these implementations will likely cease to
+ remove any Private Use ASNs from either of the AS path attributes.
+ Normal AS path filtering MAY also be used to prevent prefixes
+ originating from Private Use ASNs from being advertised to the global
+ Internet.
+
+5. IANA Considerations
+
+ IANA has reserved, for Private Use, a contiguous block of 1023
+ Autonomous System numbers from the "16-bit Autonomous System Numbers"
+ registry, namely 64512 - 65534 inclusive.
+
+ IANA has also reserved, for Private Use, a contiguous block of
+ 94,967,295 Autonomous System numbers from the "32-bit Autonomous
+ System Numbers" registry, namely 4200000000 - 4294967294 inclusive.
+
+ These reservations have been documented in the IANA "Autonomous
+ System (AS) Numbers" registry [IANA.AS].
+
+6. Security Considerations
+
+ Private Use ASNs do not raise any unique security concerns. Loss of
+ connectivity might result from their inappropriate use, specifically
+ outside of a single organization, since they are not globally unique.
+ This loss of connectivity is limited to the organization using
+ Private Use ASNs inappropriately or without reference to Section 4.
+ General BGP security considerations are discussed in [RFC4271] and
+ [RFC4272]. Identification of the originator of a route with a
+ Private Use ASN in the AS path would have to be done by tracking the
+ route back to the neighboring globally unique AS in the path or by
+ inspecting 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.
+
+
+
+
+Mitchell Best Current Practice [Page 3]
+
+RFC 6996 Private Use AS Reservation July 2013
+
+
+7.2. Informative References
+
+ [IANA.AS] IANA, "Autonomous System (AS) Numbers",
+ <http://www.iana.org/assignments/as-numbers/>.
+
+ [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
+ selection, and registration of an Autonomous System (AS)",
+ BCP 6, RFC 1930, March 1996.
+
+ [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
+ RFC 4272, January 2006.
+
+8. Acknowledgements
+
+ The author would like to acknowledge Christopher Morrow, Jason
+ Schiller, and John Scudder for their advice on how to pursue this
+ change. The author would also like to thank 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mitchell Best Current Practice [Page 4]
+