doc: Add RFC documents

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]
+