draft-ietf-idr-as-private-reservation-05.txt | rfc6996.txt | |||
---|---|---|---|---|
Network Working Group J. Mitchell | Internet Engineering Task Force (IETF) J. Mitchell | |||
Internet-Draft Microsoft Corporation | Request for Comments: 6996 Microsoft Corporation | |||
Updates: 1930 (if approved) May 29, 2013 | BCP: 6 July 2013 | |||
Intended status: Best Current Practice | Updates: 1930 | |||
Expires: November 30, 2013 | Category: Best Current Practice | |||
ISSN: 2070-1721 | ||||
Autonomous System (AS) Reservation for Private Use | Autonomous System (AS) Reservation for Private Use | |||
draft-ietf-idr-as-private-reservation-05 | ||||
Abstract | Abstract | |||
This document describes the reservation of Autonomous System numbers | This document describes the reservation of Autonomous System Numbers | |||
(ASNs) that are for Private Use only and MUST NOT be advertised to | (ASNs) that are for Private Use only, known as Private Use ASNs, and | |||
the Internet, known as Private Use ASNs. This document enlarges the | provides operational guidance on their use. This document enlarges | |||
total space available for Private Use ASNs by documenting the | the total space available for Private Use ASNs by documenting the | |||
reservation of a second, larger range and updates RFC 1930 by | reservation of a second, larger range and updates RFC 1930 by | |||
replacing Section 10. | replacing Section 10 of that document. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This memo documents an Internet Best Current Practice. | |||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
BCPs is available in Section 2 of RFC 5741. | ||||
This Internet-Draft will expire on November 30, 2013. | 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 Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
1. Introduction | 1. Introduction | |||
The original IANA reservation of Autonomous System Numbers (ASNs) for | The original IANA reservation of Autonomous System Numbers (ASNs) for | |||
Private Use was a block of 1023 ASNs. This was also documented by | Private Use was a block of 1023 ASNs. This was also documented by | |||
IETF in Section 10 of [RFC1930]. Since the time when that range was | the IETF in Section 10 of [RFC1930]. Since the time that the range | |||
reserved, Border Gateway Protocol (BGP), documented in [RFC4271], has | was reserved, the Border Gateway Protocol (BGP) [RFC4271] has seen | |||
seen deployment in new application domains, such as datacenter | deployment in new application domains, such as data center networks, | |||
networks, which require a larger Private Use AS Space. | which require a larger Private Use AS space. | |||
Since the introduction of BGP Support for Four-octet AS Number Space | Since the introduction of "BGP Support for Four-Octet Autonomous | |||
[RFC6793], the total size of the ASN space has increased | System (AS) Number Space" [RFC6793], the total size of ASN space has | |||
dramatically, and a larger subset of the space should be available to | increased dramatically. A larger subset of the space is available to | |||
network operators to deploy in these Private Use cases. The existing | network operators to deploy in these Private Use cases. The existing | |||
range of Private Use ASNs is widely deployed and the ability to | range of Private Use ASNs is widely deployed, and the ability to | |||
renumber this resource in existing networks cannot be coordinated | renumber this resource in existing networks cannot be coordinated | |||
given these ASNs by definition are not registered. Therefore this | given that these ASNs, by definition, are not registered. Therefore, | |||
documents the existing Private Use ASN reservation, while also | this RFC documents the existing Private Use ASN reservation while | |||
introducing a second, larger range that can also be utilized. | also introducing a second, larger range that can also be utilized. | |||
2. Requirements Language | 2. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
3. Private Use ASNs | 3. Private Use ASNs | |||
To allow the continued growth of usage of the BGP protocol in new | To allow the continued growth of BGP protocol usage in new network | |||
network applications that utilize Private Use ASNs, two ranges of | applications that utilize Private Use ASNs, two ranges of ASNs are | |||
ASNs are reserved by this document in Section 6. The first, which | reserved by Section 5 of this document. The first is part of the | |||
was previously defined in [RFC1930] out of the original 16-bit | original 16-bit Autonomous System range previously defined in | |||
Autonomous System range, and a second, larger range out of the higher | [RFC1930], and the second is a larger range out of the Four-Octet AS | |||
part of the Four-Octet AS Number Space [RFC6793]. | Number Space [RFC6793]. | |||
4. Operational Considerations | 4. Operational Considerations | |||
If Private Use ASNs are used and prefixes are originated from these | If Private Use ASNs are used and prefixes originate from these ASNs, | |||
ASNs, Private Use ASNs MUST be removed from AS path attributes | Private Use ASNs MUST be removed from AS path attributes (including | |||
(including AS4_PATH if utilizing four-octet AS number space) before | AS4_PATH if utilizing a four-octet AS number space) before being | |||
being advertised to the global Internet. Operators SHOULD ensure all | advertised to the global Internet. Operators SHOULD ensure that all | |||
EBGP speakers support [RFC6793] and ensure any implementation | External Border Gateway Protocol (EBGP) speakers support the | |||
specific features that recognize Private Use ASNs have been updated | extensions described in [RFC6793] and that implementation-specific | |||
to recognize both ranges prior to making use of the newer, | features that recognize Private Use ASNs have been updated to | |||
numerically higher range of Private Use ASNs in the four-octet AS | recognize both ranges prior to making use of the newer, numerically | |||
number space. Some existing implementations that remove Private Use | higher range of Private Use ASNs in the four-octet AS number space. | |||
ASNs from the AS_PATH are known to not remove Private Use ASNs if the | Some existing implementations that remove Private Use ASNs from the | |||
AS_PATH contains a mixture of Private Use and Non-Private Use ASNs. | AS_PATH are known to not remove Private Use ASNs if the AS_PATH | |||
If such implementations have not been updated to recognize the new | contains a mixture of Private Use and Non-Private Use ASNs. If such | |||
range of ASNs in this document and a mix of old and new range Private | implementations have not been updated to recognize the new range of | |||
Use ASNs exist in the AS4_PATH, these implementations will likely | ASNs in this document and a mix of old and new range Private Use ASNs | |||
cease to remove any Private Use ASNs from either of the AS path | exist in the AS4_PATH, these implementations will likely cease to | |||
attributes. Normal AS path filtering MAY also be used to prevent | remove any Private Use ASNs from either of the AS path attributes. | |||
prefixes originating from Private Use ASNs from being advertised to | Normal AS path filtering MAY also be used to prevent prefixes | |||
the global Internet. | originating from Private Use ASNs from being advertised to the global | |||
Internet. | ||||
5. 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. | ||||
6. IANA Considerations | ||||
[Note to IANA, this paragraph to be removed upon publication: The | 5. IANA Considerations | |||
IANA should update the "16-bit Autonomous System Numbers" registry to | ||||
reference this RFC for the existing Private Use reservation. The end | ||||
of the "32-bit Autonomous System Numbers" range will be reserved for | ||||
Private Use, and a size of 94,967,295 (value to replace TBD1 below) | ||||
corresponding to the range of 4200000000 (value to replace TBD2 | ||||
below) to 4294967294 (value to replace TBD3 below). Text after this | ||||
sentence should be published in the document.] | ||||
IANA has reserved, for Private Use, a contiguous block of 1023 | IANA has reserved, for Private Use, a contiguous block of 1023 | |||
Autonomous System numbers from the "16-bit Autonomous System Numbers" | Autonomous System numbers from the "16-bit Autonomous System Numbers" | |||
registry, namely 64512 - 65534 inclusive. | registry, namely 64512 - 65534 inclusive. | |||
IANA has also reserved, for Private Use, a contiguous block of TBD1 | IANA has also reserved, for Private Use, a contiguous block of | |||
Autonomous System numbers from the "32-bit Autonomous System Numbers" | 94,967,295 Autonomous System numbers from the "32-bit Autonomous | |||
registry, namely TBD2 - TBD3 inclusive. | System Numbers" registry, namely 4200000000 - 4294967294 inclusive. | |||
These reservations have been documented in the IANA Autonomous System | These reservations have been documented in the IANA "Autonomous | |||
Numbers Registry [IANA.AS]. | System (AS) Numbers" registry [IANA.AS]. | |||
7. Security Considerations | 6. Security Considerations | |||
Private Use ASNs do not raise any unique security concerns. Loss of | Private Use ASNs do not raise any unique security concerns. Loss of | |||
connectivity might result from inappropriate use of them, | connectivity might result from their inappropriate use, specifically | |||
specifically outside of a single organization, since they are not | outside of a single organization, since they are not globally unique. | |||
globally unique. This loss of connectivity is limited to the | This loss of connectivity is limited to the organization using | |||
organization using Private Use ASNs inappropriately or without | Private Use ASNs inappropriately or without reference to Section 4. | |||
reference to Section 4. General BGP security considerations are | General BGP security considerations are discussed in [RFC4271] and | |||
discussed in [RFC4271] and [RFC4272]. Identification of the | [RFC4272]. Identification of the originator of a route with a | |||
originator of a route with a Private Use ASN in the AS path would | Private Use ASN in the AS path would have to be done by tracking the | |||
have to be done by tracking the route back to the neighboring | route back to the neighboring globally unique AS in the path or by | |||
globally unique AS in the path or by inspecting other attributes. | inspecting other attributes. | |||
8. References | 7. References | |||
8.1. Normative References | 7.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway | [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway | |||
Protocol 4 (BGP-4)", RFC 4271, January 2006. | Protocol 4 (BGP-4)", RFC 4271, January 2006. | |||
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet | [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet | |||
Autonomous System (AS) Number Space", RFC 6793, December | Autonomous System (AS) Number Space", RFC 6793, | |||
2012. | December 2012. | |||
8.2. Informative References | 7.2. Informative References | |||
[IANA.AS] IANA, "Autonomous System (AS) Numbers", May 2013, | [IANA.AS] IANA, "Autonomous System (AS) Numbers", | |||
<http://www.iana.org/assignments/as-numbers/>. | <http://www.iana.org/assignments/as-numbers/>. | |||
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, | [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, | |||
selection, and registration of an Autonomous System (AS)", | selection, and registration of an Autonomous System (AS)", | |||
BCP 6, RFC 1930, March 1996. | BCP 6, RFC 1930, March 1996. | |||
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC | [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", | |||
4272, January 2006. | 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 | Author's Address | |||
Jon Mitchell | Jon Mitchell | |||
Microsoft Corporation | Microsoft Corporation | |||
One Microsoft Way | One Microsoft Way | |||
Redmond, WA 98052 | Redmond, WA 98052 | |||
USA | USA | |||
Email: Jon.Mitchell@microsoft.com | EMail: Jon.Mitchell@microsoft.com | |||
End of changes. 25 change blocks. | ||||
99 lines changed or deleted | 88 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |