Internet Engineering Task Force J. Kristoff Internet-Draft Dataplane.org Intended status: Standards Track 26 May 2026 Expires: 27 November 2026 ASN Prefix-based Addressing for IPv6 draft-kristoff-v6ops-asn-based-addressing-03 Abstract 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. Status of This Memo 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 Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Kristoff Expires 27 November 2026 [Page 1] Internet-Draft ASN Prefix-based Addressing for IPv6 May 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Address Space . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Private, Reserved, Special Use, and Unallocated ASNs . . . . 3 5. Registry Considerations . . . . . . . . . . . . . . . . . . . 3 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 7. Criticism . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . 5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. 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 [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. Kristoff Expires 27 November 2026 [Page 2] Internet-Draft ASN Prefix-based Addressing for IPv6 May 2026 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. 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. Bits: | 0 thru 15 | 16 thru 47 | 48 thru 127 | +------+---------------+-------------------+--------+ Value: | [TBD] | 16 or 32 bit ASN | Locally Assigned | +------+---------------+-------------------+--------+ Figure 1: APbA address format 3. Example Consider, for example AS 64496. Written in hex this produces an APbA IPv6 prefix of [TBD]:0:fbf0::/48. 4. 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. 5. Registry Considerations Internet registries SHOULD provide service functions and support for APdA addresses for ASN registrants. 6. IANA Considerations This memo requests a 16-bit IPv6 address prefix assignment from IANA. Kristoff Expires 27 November 2026 [Page 3] Internet-Draft ASN Prefix-based Addressing for IPv6 May 2026 7. 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. Kristoff Expires 27 November 2026 [Page 4] Internet-Draft ASN Prefix-based Addressing for IPv6 May 2026 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. 8. Security Considerations APdA addresses SHOULD have corresponding ROAs [RFC6482] if externally and publicly routed on the Internet. Network operators MAY reject APdA route announcments otherwise. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [RFC1897] Hinden, R. and J. Postel, "IPv6 Testing Address Allocation", RFC 1897, DOI 10.17487/RFC1897, January 1996, . [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, DOI 10.17487/RFC3180, September 2001, . [RFC6034] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast Addresses", RFC 6034, DOI 10.17487/RFC6034, October 2010, . [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, . [I-D.draft_odell_88_00] O'Dell, M. D., "8+8 - An Alternate Addressing Architecture for IPv6", Work in Progress, Internet-Draft, draft-odell- Kristoff Expires 27 November 2026 [Page 5] Internet-Draft ASN Prefix-based Addressing for IPv6 May 2026 8+8-00, 24 October 1996, . [I-D.hain-ipv6-geo-addr] Hain, T. L., "An IPv6 Geographic Global Unicast Address Format", Work in Progress, Internet-Draft, draft-hain- ipv6-geo-addr-02, 12 July 2010, . [I-D.eknb-srv6ops-interdomain-sidspace] Kline, E. and N. Buraglio, "SID Space (5f00::/16) Inter- domain Addressing Recommendations", Work in Progress, Internet-Draft, draft-eknb-srv6ops-interdomain-sidspace- 00, 5 November 2024, . [ipv6book] Buraglio, N. and B.E. Carpenter, "book6", May 2026, . 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). Author's Address John Kristoff Dataplane.org Chicago, IL United States of America Phone: +1 312 493-0305 Email: jtk@dataplane.org URI: https://dataplane.org/jtk/ Kristoff Expires 27 November 2026 [Page 6]