| Internet-Draft | ASN Prefix-based Addressing for IPv6 | May 2026 |
| Kristoff | Expires 27 November 2026 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the 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 https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 November 2026.¶
Copyright (c) 2026 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC3180]. 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 [RFC6034] remain and questions about the integration into modern technology such as [RFC6482] are addressed later in this document.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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.¶
Bits: | 0 thru 15 | 16 thru 47 | 48 thru 127 |
+------+---------------+-------------------+--------+
Value: | [TBD] | 16 or 32 bit ASN | Locally Assigned |
+------+---------------+-------------------+--------+
¶
Consider, for example AS 64496. Written in hex this produces an APbA IPv6 prefix of [TBD]:0:fbf0::/48.¶
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.¶
Internet registries SHOULD provide service functions and support for APdA addresses for ASN registrants.¶
This memo requests a 16-bit IPv6 address prefix assignment from IANA.¶
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.¶
APdA addresses SHOULD have corresponding ROAs [RFC6482] if externally and publicly routed on the Internet. Network operators MAY reject APdA route announcments otherwise.¶
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).¶