Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services
RFC 6382
Document | Type |
RFC - Best Current Practice
(October 2011; No errata)
Also known as BCP 169
|
|
---|---|---|---|
Authors | Danny McPherson , Ryan Donnelly , Frank Scalzo | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | WG Document | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 6382 (Best Current Practice) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ron Bonica | ||
Send notices to | (None) |
Internet Engineering Task Force (IETF) D. McPherson Request for Comments: 6382 R. Donnelly BCP: 169 F. Scalzo Category: Best Current Practice Verisign, Inc. ISSN: 2070-1721 October 2011 Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services Abstract This document makes recommendations regarding the use of unique origin autonomous system numbers (ASNs) per node for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. Network management and monitoring techniques, or other operational mechanisms, may employ this new discriminator in whatever manner best accommodates their operating environment. 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/rfc6382. Copyright Notice 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 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. McPherson, et al. Best Current Practice [Page 1] RFC 6382 Unique ASNs for Anycasted Services October 2011 Table of Contents 1. Introduction ....................................................2 2. Terminology .....................................................4 3. Recommendation for Unique Origin ASNs ...........................5 4. Additional Recommendations for Globally Anycasted Services ......6 5. Security Considerations .........................................7 6. Deployment Considerations .......................................7 7. Acknowledgements ................................................9 8. IANA Considerations .............................................9 9. References ......................................................9 9.1. Normative References .......................................9 9.2. Informative References .....................................9 1. Introduction IP anycasting [RFC4786] has been deployed for an array of network services since the early 1990s. It provides a mechanism for a given network resource to be available in a more distributed manner, locally and/or globally, with a more robust and resilient footprint, commonly yielding better localization and absorption of systemic query loads, as well as better protections in the face of distributed denial-of-service (DDoS) attacks, network partitions, and other similar incidents. A large part of the Internet root DNS infrastructure, as well as many other resources, has been anycasted for nearly a decade. While the benefits realized by anycasting network services is proven, some issues do emerge with asserting routing system reachability for a common network identifier from multiple locations. Specifically, anycasting in BGP requires injection of reachability information in the routing system for a common IP address prefix from multiple locations. These anycasted prefixes and network services have traditionally employed a common origin autonomous system number (ASN) in order to preserve historically scarce 16-bit AS number space utilized by BGP for routing domain identifiers in the global routing system. Additionally, a common origin AS number was used in order to ease management overhead of resource operations associated with acquiring and maintaining multiple discrete AS numbers as well as to avoid triggering various operations-oriented reporting functions aimed at identifying "inconsistent origin AS announcements" observed in the routing system. As a result, the representation of routing system path attributes associated with those service instances, and that anycasted prefix itself, typically bear no per-instanceShow full document text