



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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative References

   [RFC1897]  Hinden, R. and J. Postel, "IPv6 Testing Address
              Allocation", RFC 1897, DOI 10.17487/RFC1897, January 1996,
              <https://www.rfc-editor.org/info/rfc1897>.

   [RFC3180]  Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8",
              BCP 53, RFC 3180, DOI 10.17487/RFC3180, September 2001,
              <https://www.rfc-editor.org/info/rfc3180>.

   [RFC6034]  Thaler, D., "Unicast-Prefix-Based IPv4 Multicast
              Addresses", RFC 6034, DOI 10.17487/RFC6034, October 2010,
              <https://www.rfc-editor.org/info/rfc6034>.

   [RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
              Origin Authorizations (ROAs)", RFC 6482,
              DOI 10.17487/RFC6482, February 2012,
              <https://www.rfc-editor.org/info/rfc6482>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-odell-
              8+8-00>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-hain-ipv6-
              geo-addr-02>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-eknb-srv6ops-
              interdomain-sidspace-00>.

   [ipv6book] Buraglio, N. and B.E. Carpenter, "book6", May 2026,
              <https://ipv6textbook.com>.

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]
