]> Dataplane.org

Chicago IL United States of America +1 312 493-0305 jtk@dataplane.org https://dataplane.org/jtk/

Operations and Management Internet Engineering Task Force IPv6 ASN addressing This document describes a method and policy for ASN prefix-based addressing for IPv6. NOTE: The author(s) have decided to forgo further work on this document. The ideas expressed herein have been largely deemed unnecessary, redundant, impractical, or undesirable. A Criticism section details this reasoning for posterity.

Introduction This document defines an ASN (Autonomous System Number) Prefix-based Allocation (APbA) addressing method for IPv6 (Internet Protocol version 6). An ASN is embedded as sub-prefix bits of an IPv6 address, resulting in approximately 1.2 quintillion addresses per AS. Advantages of this mechanism include the ability to derive AS-specific, unique, and independent address space without an protocol mechanism or registration process for networks that have an assigned ASN. This system also makes it easy to determine an association between AS and address, which is useful for debugging and auditing purposes. This mechanism draws inspiration from . Unlike that earlier specification however, this system applies specifically to unicast addressing, supports 32-bit ASNs, and provides significantly more addresses per AS. Some administrative challenges identified by remain and questions about the integration into modern technology such as are addressed later in this document.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Address Space An IPv6 address with the prefix [IANA-assigned 16-bit prefix] indicates that the adress is a APbA address. The embedded AS follows as a sub-prefix. A 16-bit AS is left-padded with 0s. The remaining 96-bit suffix bits are locally significant and defined by the corresponding AS.

APbA address format

Example Consider, for example AS 64496. Written in hex this produces an APbA IPv6 prefix of [TBD]:0:fbf0::/48.

Private, Reserved, Special Use, and Unallocated ASNs AS numbers may be reserved for private or special use. They may also be unallocated. These AS designations MUST be maintained when mapped to APbA addresses, which may render these addresses unavailable or inappropriate for public use.

Registry Considerations Internet registries SHOULD provide service functions and support for APdA addresses for ASN registrants.

IANA Considerations This memo requests a 16-bit IPv6 address prefix assignment from IANA.

Criticism This proposal provides a relatively small amount of address space (i.e., /48) per ASN and is of limited utility to most networks. Even if the [TBD] prefix could be made smaller, embedding 32 bits for an ASN is not an efficient use of the address space. To the extent any structure in IP addressing now exists, it largely derives from historical accident and locally-defined convenience. Today IP address prefixes are assumed to be of variable length to accommodate flexibility, a feature born out of necessity from the risk of IPv4 address exhaustion a generation ago. Rigid address structures offer some advantages stemming from simplicity, but strict adherence to address boundaries has largely been rejected in practice for both IPv4 and IPv6. This proposal would reintroduce a flat addressing structure, which historically have posed scaling challenges. An ASN is primarly used in routing to convey reachability information for IP addresses, but IP addresses know nothing of ASNs. An IP address may even be reachable through multiple origin autonomous systems (MOAS). In other words, the association between ASNs and IP addresses are hierarchical and unidirectional from ASN to address. This proposal would make the relationship between ASNs and addresses bi-directional. This might reflect common IP address usage, but it would also violate equally common operator expectations and practices. IANA and registries are making IPv6 address allocations and assignments of various sizes with little fanfare. Gaps in IPv6 deployment and address assignment by ISPs remain, but this typically indicates limitations in IPv6 connectivity rather than any fundamental problem with the IPv6 address allocation and assignment scheme. There is little evidence that networks with an ASN have problems obtaining IPv6 allocations and assignments. There are some barriers to obtaining an address allocation or assignment. This can be seen in fees, service agreements, contractual obligations or other process overhead between end users and address providers. This proposal might seem to minimize or even eliminate some reliance of the existing address allocation and assignment methods. However, a public ASN from existing allocation and assignment schemes is still required, further entwining the relationship among ASN registrant, ASN registry, and the associated address space. This proposal could have unintended consequences on the routing system. Should an APbA prefix only be originated by the embedded ASN? If you hold multiple ASNs what do peering sessions and route announcements look like? Could this proposal result in a large number of /48 routes in routing tables? The answers to these questions are not fully considered here.

Security Considerations APdA addresses SHOULD have corresponding ROAs if externally and publicly routed on the Internet. Network operators MAY reject APdA route announcments otherwise.

References Normative References Informative References UUNET Technologies This document presents an alternative addressing architecture for IPv6 which controls global rou ting growth with very aggressive topological aggregation. It also includes support for scalable multihoming as a distinguished service while freeing sites and service resellers from the tyranny of CIDR-based aggreg ation by providing transparent rehoming of both. This document defines an IPv6 Geographic global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [1] and the "IPv6 Addressing Architecture" [2]. It is designed to facilitate scalable Internet routing when sites attach to multiple service providers, by using a prefix based on a geographic reference to the site. A natural byproduct of this address allocation and assignment mechanism is that all addresses are fixed allowing sites to change providers at will without requiring their network to renumber. Aalyria Technologies, Inc. Energy Sciences Network This specification recommends a specific structured use of the SRv6 SIDs prefix in support of Inter-Domain SRv6 networks. The core of the proposal is to structure the address space by Autonomous System Number (ASN). Use of this proposed structure is entirely voluntary. Voluntary use of this structure aids SRv6 operations while preserving the ability to use this prefix across cooperating SRv6 domains, but not across the general Internet.

Acknowledgements The following individuals provided an array of feedback to help improve this document, and to help clarify what a dumb idea it is: Roland Dobbins, David Farmer, Nick Hilliard, Geoff Huston, Erik Kline, and Michael Richardson. Any remaining errors or imperfections are the sole responsbility of the document author(s).