ASN Prefix-based Addressing for IPv6
draft-kristoff-v6ops-asn-based-addressing-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | John Kristoff | ||
| Last updated | 2026-05-26 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kristoff-v6ops-asn-based-addressing-03
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]