ASIP: AS-Structured Internet Protocol (128-bit)
draft-hause-asip-00
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 | Jordan Hause | ||
| Last updated | 2026-04-16 | ||
| 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-hause-asip-00
Network Working Group J. Hause
Internet-Draft Independent
Intended status: Experimental 16 April 2026
Expires: 18 October 2026
ASIP: AS-Structured Internet Protocol (128-bit)
draft-hause-asip-00
Abstract
ASIP (AS-Structured Internet Protocol; IP version 8 on the wire) is a
128-bit network protocol that defines a new address family alongside
IPv4. ASIP is NOT a wire-level superset of IPv4: an unmodified IPv4
device cannot send, receive, or forward an ASIP packet.
Interoperation between ASIP-aware endpoints and legacy IPv4 networks
is provided by a defined transition mechanism (stateless translation
at AS boundaries and encapsulation across non-upgraded transit), not
by wire compatibility.
ASIP's addressing architecture arranges the 128-bit address as four
32-bit fields (ASN routing locator, zone, subnet, host). The ASN
locator is used as a routing hint rather than a hard identity
binding; multihoming, ASN transfer, and cross-ASN anycast remain
possible through multi-address semantics defined in Sections 8, 11,
and 14. This structure is intended to reduce operational friction
during transition (familiar dotted-decimal notation, clean
aggregation at the ASN boundary) rather than to achieve wire-level
IPv4 compatibility.
This document specifies the core protocol: address format, packet
header, address classes, routing behavior, transition mechanisms, and
security considerations. The Zone Server reference architecture
(Section 16) is Informative and non-normative. The Cost Factor
routing metric (Section 17) is OPTIONAL and is specified in a
separate companion document (draft-asip-cf-00); Section 17 of this
document is a one-paragraph forward reference. Interplanetary realm
reservations (Section 3.12) are reserved allocations only; delay-
tolerant transport is out of scope for this document. Operators MAY
deploy ASIP addressing without any of the above.
This specification extends the ASN-locator addressing model of
[I-D.thain-ipv8] to a 128-bit four-field address format; see
Section 1.3 for the relationship between the two proposals.
Hause Expires 18 October 2026 [Page 1]
Internet-Draft ASIP April 2026
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 18 October 2026.
Copyright Notice
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.
Table of Contents
1. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5
1.1. 1.1. Requirements Language . . . . . . . . . . . . . . . 6
1.2. 1.2. Design Philosophy . . . . . . . . . . . . . . . . . 6
1.3. 1.3. Relationship to Prior Work . . . . . . . . . . . . 7
1.4. 1.4. What ASIP Is Not . . . . . . . . . . . . . . . . . 7
2. 2. Motivation and Problem Statement . . . . . . . . . . . . 7
2.1. 2.1. Address Exhaustion . . . . . . . . . . . . . . . . 8
2.2. 2.2. Routing Table Growth . . . . . . . . . . . . . . . 8
2.3. 2.3. Transition Model Failure . . . . . . . . . . . . . 8
2.4. 2.4. Requirements for a Viable Successor . . . . . . . . 8
3. 3. ASIP Address Format . . . . . . . . . . . . . . . . . . . 10
3.1. 3.1. Structure . . . . . . . . . . . . . . . . . . . . . 10
3.2. 3.2. Address Space . . . . . . . . . . . . . . . . . . . 11
3.3. 3.3. IPv4-Mapped ASIP Addresses . . . . . . . . . . . . 11
3.4. 3.4. ASN Encoding . . . . . . . . . . . . . . . . . . . 12
3.5. 3.5. Internal Zone Prefix (127.0.0.0/8 in r.r.r.r) . . . 12
3.6. 3.6. Inter-Organization Interop Prefix (127.127.0.0) . . 13
3.7. 3.7. RINE Peering Prefix (100.0.0.0/8 in r.r.r.r) . . . 13
Hause Expires 18 October 2026 [Page 2]
Internet-Draft ASIP April 2026
3.8. 3.8. Interior Link Convention (222.0.0.0/8 in
h.h.h.h) . . . . . . . . . . . . . . . . . . . . . . . . 14
3.9. 3.9. Private ASN Reservations . . . . . . . . . . . . . 14
3.10. 3.10. Link-Local Scope (169.254.0.0/16 in r.r.r.r) . . . 14
3.11. 3.11. Mesh and Ad-Hoc Scope (240.0.0.0/8 in r.r.r.r) . . 15
3.12. 3.12. Realm Architecture and Interplanetary Addressing
(Informative) . . . . . . . . . . . . . . . . . . . . . 16
3.13. 3.13. Documentation and Testing Range (254.0.0.0/8 in
r.r.r.r) . . . . . . . . . . . . . . . . . . . . . . . . 19
3.14. 3.14. Stateless Address Autoconfiguration
(SLAAC-ASIP) . . . . . . . . . . . . . . . . . . . . . . 20
3.14.1. 3.14.1. Overview . . . . . . . . . . . . . . . . . 20
3.14.2. 3.14.2. Host Identifier Generation . . . . . . . . 20
3.14.3. 3.14.3. Duplicate Address Detection (DAD) . . . . . 21
3.14.4. 3.14.4. SLAAC-ASIP Sequence . . . . . . . . . . . . 22
3.15. 3.15. Address Usage Summary . . . . . . . . . . . . . . 22
4. 4. Address Classes . . . . . . . . . . . . . . . . . . . . . 23
4.1. 4.1. Scope Hierarchy . . . . . . . . . . . . . . . . . . 25
4.2. 4.2. Multicast Prefix Assignments (r.r.r.r =
255.255.255.x) . . . . . . . . . . . . . . . . . . . . . 26
5. 5. ASIP Packet Header . . . . . . . . . . . . . . . . . . . 26
5.1. 5.1. Header Format . . . . . . . . . . . . . . . . . . . 27
5.2. 5.2. Design Rationale: What Was Dropped from IPv4 . . . 29
5.3. 5.3. Extension Headers . . . . . . . . . . . . . . . . . 29
5.4. 5.4. Flow Label Usage . . . . . . . . . . . . . . . . . 31
5.5. 5.5. Socket API Compatibility . . . . . . . . . . . . . 32
5.6. 5.6. IPv4/ASIP Coexistence Processing . . . . . . . . . 33
6. 6. Notation and Address Compression . . . . . . . . . . . . 33
6.1. 6.1. Canonical Notation . . . . . . . . . . . . . . . . 33
6.2. 6.2. ASN Integer Notation . . . . . . . . . . . . . . . 34
6.3. 6.3. Zero-Field Compression (:: Notation) . . . . . . . 34
6.4. 6.4. Compression Examples . . . . . . . . . . . . . . . 35
6.5. 6.5. Expansion Algorithm . . . . . . . . . . . . . . . . 36
6.6. 6.6. Flat Dotted Notation (Wire/Debug Format) . . . . . 36
6.7. 6.7. CIDR Prefix Notation . . . . . . . . . . . . . . . 37
6.8. 6.8. Design Note on Notation Choices . . . . . . . . . . 37
7. 7. DNS Integration . . . . . . . . . . . . . . . . . . . . . 38
7.1. 7.1. A-ASIP Record Type . . . . . . . . . . . . . . . . 38
7.2. 7.2. Resolution Behavior . . . . . . . . . . . . . . . . 38
7.3. 7.3. Dual Record Example . . . . . . . . . . . . . . . . 39
8. 8. Routing Protocol Behavior . . . . . . . . . . . . . . . . 39
8.1. 8.1. Multi-Tier Routing Table . . . . . . . . . . . . . 39
8.2. 8.2. Routing Protocol Extensions . . . . . . . . . . . . 40
8.3. 8.3. eBGP-ASIP . . . . . . . . . . . . . . . . . . . . . 40
8.3.1. 8.3.1. Multihoming, Anycast, and ASN Transfer . . . 42
8.3.2. 8.3.2. Locator Rewriting . . . . . . . . . . . . . . 42
8.4. 8.4. WHOIS-ASIP Route Validation . . . . . . . . . . . . 43
8.5. 8.5. iBGP-ASIP and OSPF-ASIP . . . . . . . . . . . . . . 45
Hause Expires 18 October 2026 [Page 3]
Internet-Draft ASIP April 2026
9. 9. ICMP-ASIP . . . . . . . . . . . . . . . . . . . . . . . . 45
9.1. 9.1. Core Messages . . . . . . . . . . . . . . . . . . . 45
9.2. 9.2. Neighbor Discovery . . . . . . . . . . . . . . . . 46
9.3. 9.3. ARP-ASIP Compatibility . . . . . . . . . . . . . . 47
10. 10. Multicast . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. 10.1. Scoped Multicast Model . . . . . . . . . . . . . 48
10.2. 10.2. Intra-ASN Multicast (IPv4 Compatible) . . . . . . 49
10.3. 10.3. Cross-ASN Multicast . . . . . . . . . . . . . . . 50
10.4. 10.4. Well-Known Multicast Groups . . . . . . . . . . . 50
10.5. 10.5. Multicast Listener Discovery . . . . . . . . . . 50
10.6. 10.6. Composition of Multicast Scope with Realm and Mesh
Scope . . . . . . . . . . . . . . . . . . . . . . . . . 51
11. 11. Anycast and Broadcast . . . . . . . . . . . . . . . . . 53
11.1. 11.1. Anycast . . . . . . . . . . . . . . . . . . . . . 53
11.2. 11.2. Broadcast . . . . . . . . . . . . . . . . . . . . 53
12. 12. Compatibility and Transition . . . . . . . . . . . . . . 54
12.1. 12.1. Deployment Model . . . . . . . . . . . . . . . . 54
12.2. 12.2. IPv4/ASIP Stateless Translation at AS
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 54
12.3. 12.3. ASIP-to-IPv4 Encapsulation Across IPv4 Transit . 56
12.4. 12.4. Transition Value . . . . . . . . . . . . . . . . 57
12.5. 12.5. IPv6 Coexistence . . . . . . . . . . . . . . . . 58
12.6. 12.6. CGNAT Behavior . . . . . . . . . . . . . . . . . 58
12.7. 12.7. Stateless Translation Reference: Packet-Level
Walkthrough . . . . . . . . . . . . . . . . . . . . . . 59
12.7.1. 12.7.1. Simple TCP Data Packet (ASIP -> IPv4) . . . 59
12.7.2. 12.7.2. ICMP-ASIP Echo Request -> ICMPv4 Echo
Request . . . . . . . . . . . . . . . . . . . . . . . 60
12.7.3. 12.7.3. ICMPv4 Destination Unreachable Carrying a
Truncated IPv4 Inner Header (-> ICMP-ASIP) . . . . . 61
12.7.4. 12.7.4. ICMPv4 Type 3 Code 4 (Fragmentation Needed /
DF Set) -> ICMP-ASIP Packet Too Big . . . . . . . . . 62
12.7.5. 12.7.5. Fragmented Inner Payload (-> IPv4) . . . . 63
12.7.6. 12.7.6. IPv4 DF Bit Handling (IPv4 -> ASIP) . . . . 63
12.7.7. 12.7.7. ICMP-ASIP Error Back to IPv4 Originator
(Reverse Direction) . . . . . . . . . . . . . . . . . 64
12.7.8. 12.7.8. Port-Restricted Inner ICMP . . . . . . . . 65
12.8. 12.8. Path MTU Discovery and Encapsulation Budget . . . 65
13. 13. Application Compatibility . . . . . . . . . . . . . . . 67
13.1. 13.1. Legacy Applications . . . . . . . . . . . . . . . 67
13.2. 13.2. New Applications . . . . . . . . . . . . . . . . 67
13.3. 13.3. URL and URI Representation . . . . . . . . . . . 67
14. 14. Security Considerations . . . . . . . . . . . . . . . . 67
14.1. 14.1. ASN Locator Spoofing . . . . . . . . . . . . . . 68
14.2. 14.2. Internal Zone Prefix Protection . . . . . . . . . 70
14.3. 14.3. RINE Prefix Protection . . . . . . . . . . . . . 70
14.4. 14.4. Interior Link Convention Protection . . . . . . . 70
14.5. 14.5. RFC 1918 Address Privacy . . . . . . . . . . . . 70
Hause Expires 18 October 2026 [Page 4]
Internet-Draft ASIP April 2026
14.6. 14.6. Prefix Granularity Enforcement . . . . . . . . . 71
14.7. 14.7. Header Overhead and DDoS . . . . . . . . . . . . 71
14.8. 14.8. Privacy Considerations . . . . . . . . . . . . . 71
14.9. 14.9. SLAAC-ASIP Security . . . . . . . . . . . . . . . 72
14.10. 14.10. Link-Local Scope Enforcement . . . . . . . . . . 72
14.11. 14.11. Scope Boundary Enforcement . . . . . . . . . . . 72
14.12. 14.12. Extension Header Security . . . . . . . . . . . 73
14.13. 14.13. Flow Label Security . . . . . . . . . . . . . . 74
14.14. 14.14. STRIDE Summary . . . . . . . . . . . . . . . . . 74
14.15. 14.15. Translator State and ICMP Error Attribution . . 77
15. 15. IANA Considerations . . . . . . . . . . . . . . . . . . 78
15.1. 15.1. IP Version Number . . . . . . . . . . . . . . . . 78
15.2. 15.2. Address Family . . . . . . . . . . . . . . . . . 78
15.3. 15.3. Reserved ASN Ranges . . . . . . . . . . . . . . . 79
15.4. 15.4. DNS A-ASIP Record Type . . . . . . . . . . . . . 80
15.5. 15.5. ICMP-ASIP Next-Header Value and Type Registry . . 80
15.6. 15.6. Cross-ASN Multicast Registry . . . . . . . . . . 81
15.7. 15.7. Broadcast Reservation . . . . . . . . . . . . . . 81
15.8. 15.8. Next Header Values . . . . . . . . . . . . . . . 81
15.9. 15.9. GENEVE Inner-Protocol Assignment for
ASIP-to-IPv4 . . . . . . . . . . . . . . . . . . . . . 81
15.10. 15.10. WHOIS-ASIP Registry Domain Delegation . . . . . 81
16. 16. Zone Server Reference Architecture (Informative) . . . . 81
16.1. 16.1. Concept . . . . . . . . . . . . . . . . . . . . . 82
16.2. 16.2. Service Delivery Model . . . . . . . . . . . . . 82
16.3. 16.3. Authentication Model . . . . . . . . . . . . . . 82
16.4. 16.4. Why This Is Informative, Not Normative . . . . . 82
17. 17. Cost Factor Routing Metric (Informative) . . . . . . . . 83
18. 18. Acknowledgment of Trade-offs . . . . . . . . . . . . . . 83
18.1. 18.1. Header Overhead . . . . . . . . . . . . . . . . . 83
18.2. 18.2. Rigid Hierarchy . . . . . . . . . . . . . . . . . 84
18.3. 18.3. ASN Dependency . . . . . . . . . . . . . . . . . 84
18.4. 18.4. Transition Realism . . . . . . . . . . . . . . . 84
18.5. 18.5. Relationship to IPv6 . . . . . . . . . . . . . . 85
18.6. 18.5a. UNRESOLVED: Multihoming Under an ASN-Shaped
Address . . . . . . . . . . . . . . . . . . . . . . . . 85
18.7. 18.5b. Server-Side Multi-Address Operational Impact . . 85
18.8. 18.6. WHOIS-ASIP Adoption . . . . . . . . . . . . . . . 88
18.9. 18.7. 32-Bit Host Field and SLAAC Constraints . . . . . 88
18.10. 18.8. Interplanetary Address Reservation . . . . . . . 89
18.11. 18.9. Complexity Budget . . . . . . . . . . . . . . . . 89
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 89
19.1. Normative References . . . . . . . . . . . . . . . . . . 89
19.2. Informative References . . . . . . . . . . . . . . . . . 91
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 94
1. 1. Introduction
Hause Expires 18 October 2026 [Page 5]
Internet-Draft ASIP April 2026
1.1. 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.
1.2. 1.2. Design Philosophy
ASIP is built on three premises.
*First,* ASIP is a new address family with a defined transition
mechanism. It is not a wire-level superset of IPv4. Any packet
carrying Version=8 in the IP header will be dropped by unmodified
IPv4 routers, hosts, and middleboxes; conversely, ASIP-aware nodes
receive IPv4 traffic only through the transition mechanisms defined
in Section 12. The goal is not wire compatibility, which is
unachievable without changing the framing layer. The goal is a
transition path that minimizes operator-facing churn: familiar
dotted-decimal notation, natural mapping of existing IPv4 host
addresses into the ASIP host field, and stateless translation at AS
boundaries so that legacy IPv4 endpoints remain reachable by ASIP-
aware peers without application-layer changes.
*Second,* the address format should reflect routing topology so that
aggregation is natural and deaggregation is visible. Arranging the
128-bit address as ASN/Zone/Subnet/Host makes the default aggregation
boundary obvious and provides a single-lookup inter-AS forwarding
path for the common case. The ASN field is a routing locator used as
a forwarding hint, not a globally binding identity; Sections 8, 11,
and 14 define how multihomed, anycast, and transferred ASNs are
handled through multi-address semantics rather than through a one-
ASN-per-host rule.
*Third,* a protocol specification must not exceed its scope. ASIP
defines an address format, a packet header, and the routing behaviors
those imply. Operational tooling, management platforms,
authentication frameworks, and forward-looking realm designs are
Informative only. An operator MAY adopt ASIP addressing without
adopting any of them.
Hause Expires 18 October 2026 [Page 6]
Internet-Draft ASIP April 2026
1.3. 1.3. Relationship to Prior Work
This specification extends the ASN-locator addressing concept of
[I-D.thain-ipv8] from a 64-bit two-field address (ASN / Host) to a
128-bit four-field address (ASN / Zone / Subnet / Host). The dotted-
decimal r.r.r.r notation for the ASN locator, the concept of encoding
Autonomous System identity into the address prefix, and the Zone
Server management architecture described in Section 16 (Informative)
are derived from that prior work. The extensions contributed by this
document are: the 128-bit address format with Zone and Subnet fields,
the stateless translation mechanism defined in Section 12, the
ingress-filter mechanism defined in Section 14.1, the byte-level
encoding specifications in Section 12.7, and the security-
considerations treatment in Section 14.
[I-D.thain-ipv8] remains a distinct proposal with different
addressing semantics; this document does not supersede it and does
not claim to. The two specifications MAY coexist as parallel
proposals in the IETF process.
1.4. 1.4. What ASIP Is Not
ASIP is not a wire-compatible extension of IPv4. It is not a network
management suite. It does not, at the protocol layer, mandate
specific authentication mechanisms, logging formats, route-validation
registries, or device firmware behaviors. Section 16 (Zone Server)
is Informative, Section 17 (Cost Factor) is OPTIONAL and deferred to
a companion document, and Section 3.12 (realm reservations beyond
Earth) is reserved allocation only. The core protocol's correctness
does not depend on any of them; a compliant ASIP implementation can
ignore all three.
The core address-layer specification stands alone: the packet header
of §5, the address format of §3, and the link-local, mesh, and realm
scopes of §§3.10-3.12 are self-contained and do not depend on any
companion protocol. Inter-AS routing, route-ownership validation,
and transit across non-upgraded IPv4 networks require the extensions
named in Sections 8 and 12, and those extensions are REQUIRED for the
use cases that depend on them; they are not part of the core address-
layer specification.
2. 2. Motivation and Problem Statement
Hause Expires 18 October 2026 [Page 7]
Internet-Draft ASIP April 2026
2.1. 2.1. Address Exhaustion
IANA completed allocation of the IPv4 unicast address space in
February 2011. Regional Internet Registries exhausted their pools
between 2011 and 2020. CGNAT has extended IPv4's operational life at
the cost of added latency, broken peer-to-peer protocols, complicated
troubleshooting, and centralized failure domains.
The address exhaustion problem is architectural and cannot be
resolved within a 32-bit address space.
2.2. 2.2. Routing Table Growth
The BGP4 global routing table exceeded 1,000,000 prefixes by 2024 and
grows without architectural bound. Prefix deaggregation for traffic
engineering purposes is the primary growth driver. No BGP4 mechanism
structurally prevents it.
BGP4 has no binding relationship between what an ASN advertises and
what it is authorized to advertise. Prefix hijacking, route leaks,
and bogon injection remain possible because route ownership
validation is not enforced as a condition of route acceptance. RPKI
and BGPsec have seen limited deployment due to operational complexity
and incomplete adoption incentives.
2.3. 2.3. Transition Model Failure
IPv6 required dual-stack operation: every device, application, and
network supporting both IPv4 and IPv6 simultaneously. This model
imposed cost with no incremental benefit to early adopters.
Organizations that deployed IPv6 still required full IPv4 support for
the foreseeable future. The absence of a forcing function allowed
indefinite deferral.
Any viable successor must provide value to individual adopters before
universal adoption occurs.
2.4. 2.4. Requirements for a Viable Successor
These are the goals ASIP sets for itself. Wire-level IPv4
compatibility and zero-modification deployment are not among them:
both are unachievable at the framing layer once Version=8 is used,
because unmodified IPv4 forwarding elements discard packets whose
Version field is not 4.
Hause Expires 18 October 2026 [Page 8]
Internet-Draft ASIP April 2026
* *R1.* Defined transition mechanism. ASIP-aware endpoints MUST be
able to reach unmodified IPv4 endpoints through stateless
translation and encapsulation mechanisms specified in Section 12.
Wire-level IPv4 compatibility on the Version=8 code point is
explicitly not claimed.
* *R2.* Single-stack operation on the end host. An ASIP-aware host
MUST be able to reach both IPv4 and ASIP destinations through a
single ASIP socket API; dual stacks in the application layer are
not required. Network paths in transition will carry both IPv4
and ASIP frames; that is unavoidable and is not called "dual
stack" here.
* *R3.* Expanded address space sufficient to eliminate exhaustion
and CGNAT dependency and to reduce forced renumbering for the
common case of upstream-provider change within a fixed ASN. The
requirement is "reduce" rather than "eliminate" because the z:s:h
identifier triple of §3.1 is stable across ASN transfer and
locator rewrite, but the r.r.r.r field of any affected address
changes per §8.3.2, and in that narrow sense some renumbering
events persist. Residual renumbering events include (a) ASN
transfer between organizations (§8.3.1), (b) multihoming add/drop
where the set of r.r.r.r locators advertised for a host changes,
(c) locator rewrite at an AS boundary (§8.3.2; not visible to most
applications per §3.1's identifier/locator separation), (d)
acquisition-driven merger of two ASNs into one, and (e) RIR policy
revocation of an ASN. Common-case provider-change (an enterprise
swapping upstream ISPs while keeping its own ASN) produces zero
renumbering under ASIP, which is the benefit R3 claims.
* *R4.* Structurally bounded global routing table in the common
case, with multihoming, anycast, and traffic engineering preserved
through the mechanisms defined in Sections 8.3, 11.1, and 14.
* *R5.* Route ownership validation defined at the protocol layer
(Section 8.4). Because route-ownership validation is a core
guarantee, it is REQUIRED for any deployment that relies on the
structural routing-table bound; it is RECOMMENDED but not REQUIRED
for early deployments that accept BGP4-equivalent route hygiene.
* *R6.* Implementable via software update on existing forwarding
hardware (line cards, NICs, kernels, middleboxes). Hardware that
cannot be updated to parse a 40-byte Version=8 header is
incompatible with ASIP and MUST be replaced or bypassed via
tunnels at the deployment boundary.
* *R7.* Human-readable addressing consistent with IPv4 operator
familiarity.
Hause Expires 18 October 2026 [Page 9]
Internet-Draft ASIP April 2026
* *R8.* Incremental adoption value at the AS boundary. An AS that
deploys ASIP internally and at its borders benefits before
universal adoption; transit across non-upgraded IPv4 networks uses
the mechanisms of Section 12.
* *R9.* No flag day for legacy IPv4 endpoints; they continue to
operate unchanged and are reached via translation. There is,
however, a per-device software-update flag day for any node that
wishes to participate in ASIP forwarding or origination.
* *R10.* Clear separation between protocol-layer requirements and
operational recommendations (Sections 16, 17).
3. 3. ASIP Address Format
3.1. 3.1. Structure
An ASIP address is a 128-bit value composed of four 32-bit fields:
r.r.r.r . z.z.z.z . s.s.s.s . h.h.h.h | | | | | | | | ASN Zone Subnet
Host Locator ID ID ID (32 bit) (32 bit) (32 bit) (32 bit)
* *r.r.r.r* -- ASN Routing Locator. A 32-bit value drawn from the
Autonomous System Number space and used as the inter-AS forwarding
key. The ASN locator is a routing hint; it is NOT a globally
binding identity. A single host MAY be reached via multiple
addresses with different r.r.r.r values, and a single ASN MAY be
advertised from multiple locations. Rewriting of r.r.r.r at
ingress or egress is permitted under the conditions defined in
Section 8.3 and Section 11.1.
* *z.z.z.z* -- Zone Identifier. Identifies a network zone, region,
or organizational division within the AS. Allocated by the AS
operator. Locally significant.
* *s.s.s.s* -- Subnet Identifier. Identifies a subnet within a
zone. Allocated by the zone operator. Locally significant.
* *h.h.h.h* -- Host Identifier. Identifies a host within a subnet.
Its value space is the same as an IPv4 host address so that
existing operational practice (well-known host addresses, DHCP
pools, broadcast conventions) carries over without
reinterpretation.
*Identifier/locator separation:* r.r.r.r is a routing locator only,
not a host-identity field. Binding ASN identity into the address as
a hard property of the host would break multihoming, ASN transfer,
and cross-ASN anycast: a multihomed host reachable through two ASes
Hause Expires 18 October 2026 [Page 10]
Internet-Draft ASIP April 2026
could not present a single identity, an ASN transfer would force
every affected host to acquire a new identity, and a single anycast
service could not be advertised from multiple ASNs. Under the
locator-only semantics defined here, a multihomed host has one
address per upstream AS it is reachable through; an anycast service
has one address per ASN it is advertised from; an ASN transfer
rewrites the r.r.r.r locator of the affected addresses without
changing the underlying host. The z.z.z.z, s.s.s.s, and h.h.h.h
fields collectively form a stable identifier within an operator's
scope; r.r.r.r is allowed to change as reachability changes.
Section 8 defines the routing-layer consequences; Section 14 defines
the security consequences.
3.2. 3.2. Address Space
Total: 2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456
Per ASN: 2^96 = 79,228,162,514,264,337,593,543,950,336 Per Zone: 2^64
= 18,446,744,073,709,551,616 Per Subnet: 2^32 = 4,294,967,296
This is identical in total size to IPv6 (2^128) but with a fixed
hierarchical structure that directly encodes routing topology.
3.3. 3.3. IPv4-Mapped ASIP Addresses
When the ASN Locator, Zone ID, and Subnet ID are all zero, the Host
ID field encodes an IPv4 address:
0.0.0.0 . 0.0.0.0 . 0.0.0.0 . h.h.h.h
This form is analogous to IPv6's ::ffff:0:0/96 IPv4-mapped address
block [RFC4291]. It is a representation inside the ASIP address
space of an IPv4 destination; it is NOT a wire-level IPv4 packet. An
ASIP-aware host that wishes to reach an unmodified IPv4 endpoint
constructs an IPv4-mapped destination and passes it to the ASIP
stack, which either:
1. Forwards the traffic as a Version=8 frame to an ASIP/IPv4
translator at the AS boundary (Section 12.2), which emits
Version=4 on the downstream IPv4 network; or
2. Encapsulates the Version=8 frame in a Version=4 packet for
transit across non-upgraded IPv4 infrastructure (Section 12.3).
An unmodified IPv4 device cannot send or receive a Version=8 frame
directly. The IPv4-mapped address form exists so that the ASIP stack
and application layer have a single address type for both ASIP and
IPv4 destinations, not so that IPv4 hosts are silently reclassified
as "ASIP compliant."
Hause Expires 18 October 2026 [Page 11]
Internet-Draft ASIP April 2026
An ASIP implementation that receives a Version=8 packet where r.r.r.r
= 0.0.0.0, z.z.z.z = 0.0.0.0, and s.s.s.s = 0.0.0.0 MUST treat the
h.h.h.h field as an IPv4 destination and forward it toward the IPv4/
ASIP translator selected by Section 12.
*r=0 with z≠0 or s≠0.* The IPv4-mapped form above requires all three
of r, z, s to be zero. The partial form (r.r.r.r = 0.0.0.0 with
z.z.z.z or s.s.s.s non-zero) is not defined by this document and,
consistent with the AS 0 reservation of [RFC7607], is not a valid
origin or destination for ASIP traffic. ASIP implementations MUST
drop any received Version=8 packet whose source or destination
r.r.r.r = 0.0.0.0 is accompanied by a non-zero z.z.z.z or s.s.s.s,
and SHOULD log the event.
*Realm containment exception:* Section 4.1 defines strict scope
containment: an address in realm X is not visible outside realm X.
IPv4-mapped addresses (r=z=s=0) are an explicit exception to the
terrestrial-realm containment rule because they represent a legacy
IPv4 destination that has no realm of its own. IPv4-mapped traffic
is handled by translators at the terrestrial/realm boundary and is
never forwarded natively into a non-terrestrial realm.
3.4. 3.4. ASN Encoding
The 32-bit ASN is encoded directly into the r.r.r.r field as a 32-bit
unsigned integer in network byte order:
ASN 64496 = 0.0.251.240 (documentation, per RFC 5398) ASN 64497 =
0.0.251.241 (documentation, per RFC 5398) ASN 15169 = 0.0.59.65
(example: Google) ASN 13335 = 0.0.52.23 (example: Cloudflare)
3.5. 3.5. Internal Zone Prefix (127.0.0.0/8 in r.r.r.r)
The r.r.r.r range 127.0.0.0/8 is permanently reserved for internal
zone prefixes. These addresses identify network zones within an
organization's private addressing space and are never routed
externally.
127.1.0.0 . z.z.z.z . s.s.s.s . h.h.h.h (Internal zone 1) 127.2.0.0 .
z.z.z.z . s.s.s.s . h.h.h.h (Internal zone 2) 127.3.0.0 . z.z.z.z .
s.s.s.s . h.h.h.h (Internal zone 3)
Internal zone prefix rules:
* MUST NOT be routed beyond the organization's AS boundary.
* MUST NOT appear on WAN interfaces or public internet links.
Hause Expires 18 October 2026 [Page 12]
Internet-Draft ASIP April 2026
* MUST NOT appear in eBGP-ASIP advertisements.
* MAY be used freely within an organization's routing
infrastructure.
* Provides 2^(24+32+32+32) = 2^120 effective internal addresses per
organization (24 free bits in the r.r.r.r field after the fixed
127/8 prefix, plus the full Zone, Subnet, and Host fields). The
same 127.0.0.0/8 prefix space is reused independently inside every
organization; the 2^120 figure is a per-organization capacity, not
a globally partitioned one.
Organizations may build geographically distributed, multi-region
private networks of arbitrary scale without external address
coordination and with zero possibility of zone-to-zone address
conflict.
ASN numbers that encode to the 127.0.0.0/8 range (ASN 2,130,706,432
through ASN 2,147,483,647) are reserved for internal zone use and
MUST NOT be allocated by IANA for public internet routing.
3.6. 3.6. Inter-Organization Interop Prefix (127.127.0.0)
The prefix 127.127.0.0 in the r.r.r.r field is reserved as a standard
inter-organization interconnect DMZ. When two organizations need to
peer without exposing internal addressing:
Org A Org B ----- ----- 127.1.0.0.z.s.h <-> XLATE <->
127.127.0.0.z.s.h <-> XLATE <-> 127.2.0.0.z.s.h
Neither organization exposes its internal zone topology to the other.
Each controls exactly what it publishes into the shared 127.127.0.0
space.
3.7. 3.7. RINE Peering Prefix (100.0.0.0/8 in r.r.r.r)
The r.r.r.r range 100.0.0.0/8 is reserved for Regional Inter-Network
Exchange (RINE) peering fabric addressing. RINE addresses are used
exclusively for AS-to-AS peering links at IXPs and private
interconnect facilities.
* MUST NOT be advertised in the global eBGP-ASIP routing table.
* MUST NOT be assigned to end devices.
* MUST be filtered at all eBGP-ASIP border routers.
Hause Expires 18 October 2026 [Page 13]
Internet-Draft ASIP April 2026
3.8. 3.8. Interior Link Convention (222.0.0.0/8 in h.h.h.h)
The h.h.h.h range 222.0.0.0/8 is designated by convention for router-
to-router interior link addressing within an AS. This is a soft
convention, not a scope boundary.
Two distinct filtering behaviors apply and MUST NOT be conflated:
* *Route-advertisement filtering (Section 14.4):* eBGP-ASIP border
routers MUST NOT advertise prefixes whose covered addresses have
h.h.h.h in 222.0.0.0/8 as reachable interior links. This prevents
interior-link addressing from being exported to other ASes.
* *Data-plane filtering:* Border routers MUST NOT filter data
packets solely on the basis of a 222.0.0.0/8 h.h.h.h value. The
host field is locally significant; other ASes MAY use 222.x.x.x
host addresses for any purpose and their traffic must transit
normally. Filtering h.h.h.h values at border routers would break
legitimate inter-AS traffic from operators who use this range
internally.
Conflating the two would cause legitimate external traffic to be
dropped whenever a remote operator happened to use 222.x.x.x host
values internally; the two behaviors are therefore kept distinct as a
normative requirement.
3.9. 3.9. Private ASN Reservations
Consistent with RFC 6996:
* ASN 65534 (r.r.r.r = 0.0.255.254): Reserved for private inter-
organization eBGP-ASIP peering.
* ASN 65533 (r.r.r.r = 0.0.255.253): Reserved for documentation and
testing.
3.10. 3.10. Link-Local Scope (169.254.0.0/16 in r.r.r.r)
The r.r.r.r range 169.254.0.0/16 is reserved for link-local
addressing, directly analogous to both IPv4's APIPA (169.254.0.0/16)
and IPv6's fe80::/10. The familiar range was chosen deliberately so
that operators immediately recognize the scope.
169.254.0.0:0.0.0.0:0.0.0.0:h.h.h.h Compressed: 169.254.0.0::h.h.h.h
Link-local rules:
Hause Expires 18 October 2026 [Page 14]
Internet-Draft ASIP April 2026
* MUST NOT be forwarded by any router. Link-local addresses are
valid only on the physical or virtual link where they originate.
* MUST be usable without any prior configuration, DHCP, or router
contact. A device that has received no configuration of any kind
MUST be able to generate and use a link-local address.
* MUST be used for neighbor discovery, router solicitation, and
SLAAC-ASIP bootstrapping (Section 3.14).
* The h.h.h.h field is self-assigned by the device (see Section 3.14
for generation rules).
* Multiple link-local addresses MAY exist on a single interface.
Link-local addresses serve the same critical bootstrapping role as
fe80:: in IPv6: they provide a communication channel that exists
before any infrastructure (DHCP, DNS, routing) is available. Every
ASIP interface MUST have at least one link-local address at all
times.
3.11. 3.11. Mesh and Ad-Hoc Scope (240.0.0.0/8 in r.r.r.r)
The r.r.r.r range 240.0.0.0/8 is reserved for mesh and ad-hoc network
addressing. This range is used by devices participating in self-
organizing networks where no AS infrastructure exists: disaster
recovery, battlefield mesh, sensor networks, and similar
environments.
240.x.x.x:z.z.z.z:s.s.s.s:h.h.h.h
Mesh scope rules:
* MUST NOT be routed beyond the mesh boundary.
* MAY be bridged to AS-routed networks via a mesh gateway that
performs address translation for unicast traffic. Multicast is
NOT forwarded across a mesh gateway in either direction per §10.6
rule 5; application-layer relay is the only sanctioned path for
cross-mesh multicast delivery.
* Devices within a mesh self-assign addresses using SLAAC-ASIP
(Section 3.14) with DAD.
* The x.x.x portion of 240.x.x.x MAY be used to identify distinct
mesh domains.
Hause Expires 18 October 2026 [Page 15]
Internet-Draft ASIP April 2026
3.12. 3.12. Realm Architecture and Interplanetary Addressing
(Informative)
This subsection is INFORMATIVE. The reservations described here set
aside r.r.r.r ranges and nothing more; no delay-tolerant transport,
no inter-realm relay, and no non-terrestrial routing protocol is
defined by this document. A compliant ASIP implementation MAY ignore
this section entirely except to filter the reserved ranges as
unallocated.
ASIP reserves ranges in the r.r.r.r field for network realms beyond
the terrestrial internet. A realm is a physically or logically
distinct routing domain where light-speed delay, intermittent
connectivity, or governance boundaries make standard BGP convergence
assumptions invalid.
The rationale is forward-looking: deep-space networking (DTN) is
already standardized via the Bundle Protocol [RFC9171] but has no
native IP-layer addressing scheme. Reserving realm prefixes now
costs nothing and avoids a renumbering event later. The reservations
are held unallocated until a companion specification defines how they
are to be used.
*Realm Allocations:*
+==========================+===========================+==========+
| r.r.r.r Range | Realm | Status |
+==========================+===========================+==========+
| 0.0.0.1 - 96.255.255.255 | Terrestrial (Earth) | Active |
+--------------------------+---------------------------+----------+
| 97.0.0.0/8 | Near-Earth Infrastructure | Reserved |
+--------------------------+---------------------------+----------+
| 98.0.0.0/8 | Cislunar / Lunar | Reserved |
+--------------------------+---------------------------+----------+
| 99.0.0.0/8 | Martian | Reserved |
+--------------------------+---------------------------+----------+
| 241.0.0.0 - | Future Celestial Bodies | Reserved |
| 249.255.255.255 | | |
+--------------------------+---------------------------+----------+
| 250.0.0.0/8 | Delay-Tolerant (DTN) | Reserved |
| | Relay | |
+--------------------------+---------------------------+----------+
Table 1
*Realm properties:*
Hause Expires 18 October 2026 [Page 16]
Internet-Draft ASIP April 2026
(The bullets below are descriptive guidance on operating
characteristics; the RFC 2119 keywords within them are normative only
for operators who voluntarily deploy into the named realm per a
future companion DTN profile. None of these bullets imposes a
conformance requirement on ASIP core implementations, which per the
section opener MAY ignore §3.12 entirely.)
* *Near-Earth (97.0.0.0/8):* LEO and GEO satellite constellations,
space stations, orbital infrastructure. Round-trip times up to
~600ms. Standard TCP is functional with tuning. eBGP-ASIP peering
is viable with extended timers.
* *Cislunar/Lunar (98.0.0.0/8):* Earth-Moon communication. ~2.5
second round-trip. TCP is marginal; DTN overlays are RECOMMENDED
within the scope of a companion profile. eBGP-ASIP peering within
that companion profile would require hold timers of 30+ seconds.
* *Martian (99.0.0.0/8):* Earth-Mars communication. 4-24 minute one-
way delay depending on orbital position. TCP is non-functional.
Any companion deployment profile for this realm would necessarily
use DTN store-and-forward; eBGP-ASIP is not applicable and a
delay-tolerant routing protocol is needed (out of scope for this
document).
* *DTN Relay (250.0.0.0/8):* Addresses for DTN relay nodes that
bridge between realms. In a future companion profile these nodes
would participate in multiple realms and perform store-and-forward
routing across light-speed boundaries; this document defines no
such behavior.
Each realm operates as an independent routing domain. Inter-realm
traffic is forwarded by relay gateways that bridge the appropriate
delay-tolerant transport. The realm prefix in r.r.r.r allows any
router to determine the destination realm from a single 32-bit lookup
and route to the appropriate relay gateway.
The remainder of this subsection is Informative guidance for
operators who elect to experiment with realm-scoped deployments;
normative MUSTs and MUST NOTs below are normative only within such
deployments and have no effect on implementations that ignore §3.12
entirely per the opening paragraph of this subsection. The normative
core-protocol rules that cover cross-realm scope violations for any
deployment are in §14.11 and §10.6.
*Realm identification is implicit in r.r.r.r.* There is no separate
realm-ID field in the ASIP header (§5.1). A border relay determines
the destination realm by looking up the destination address's r.r.r.r
value against the realm-allocation table above; the source realm is
Hause Expires 18 October 2026 [Page 17]
Internet-Draft ASIP April 2026
determined the same way from the source address. No packet-format
changes are required to carry realm identity, and no companion
protocol defines a realm-ID explicit field in this document.
*Mesh/realm and mesh-as-relay interaction.* A mesh node (§3.11,
240.0.0.0/8 in r.r.r.r) is by construction scoped to its mesh domain
and does not hold an address in any non-terrestrial realm range
(97/8, 98/8, 99/8, 241/8–249/8, 250/8). A realm relay is, by
definition, a border node that holds addresses in both the
terrestrial realm and the non-terrestrial realm it bridges; a mesh
node holds neither (its r.r.r.r is in 240/8) and therefore cannot be
a realm relay. Operators who wish a physically-mesh deployment to
participate in realm-crossing SHOULD front that deployment with a
terrestrial AS boundary (a mesh gateway per §3.11) and attach that AS
to a realm relay via standard terrestrial peering. A node SHOULD NOT
simultaneously hold a mesh (240/8) and a non-terrestrial realm (any
of 97/8, 98/8, 99/8, 241/8–249/8, 250/8, as enumerated earlier in
this paragraph) r.r.r.r address on the same interface; dual-homing
across the two scopes is NOT RECOMMENDED and should use a gateway
node with two interfaces if attempted.
*Delay-tolerant profile for core ASIP machinery.* Several pieces of
core ASIP machinery have implicit sub-second-RTT assumptions that do
not hold at interplanetary distances:
* *SLAAC-ASIP DAD (§3.14.3)* expects a probe response within
RetransTimer (IPv6 default 1000 ms); at cislunar RTT (~2.5 s) DAD
timers require at minimum 4x extension and at Martian RTT
(minutes) DAD as specified is inoperable.
* *NDP neighbor-cache aging (§9.2)* inherits IPv6 defaults
(ReachableTime on the order of 30 s); link-level reachability
assumptions break when a "link" is a light-minute.
* *PMTUD (§12.8)* assumes ICMP-ASIP Packet Too Big arrives within a
data-flow RTT; at realm scale PMTU discovery would stall.
* *Translator per-flow state (§14.15)* ages at TCP/UDP-scale
defaults; per-flow state for a cross-realm flow would expire
before the first round-trip completes.
* *eBGP-ASIP hold timers (§8.3)* default in the single-digit-minutes
range; cislunar is tractable with tuning, Martian is not.
This document does NOT define a DTN profile that adjusts the above.
Until a companion DTN profile is published, §3.12 realm reservations
98/8, 99/8, 241/8–249/8, and 250/8 are *reserved address space only*
and should not be deployed over the public internet for real traffic.
Hause Expires 18 October 2026 [Page 18]
Internet-Draft ASIP April 2026
97/8 (Near-Earth) operates at sub-second RTT and is the only realm
range for which the core ASIP timers above are tractable with
standard tuning. This restricts interplanetary realm use to
reserved-address status until a DTN profile exists; that restriction
is a scope choice, not a protocol defect.
*Cross-realm authentication (Informative guidance; core filtering
rule is normative in §14.11).* A packet arriving at a terrestrial
realm relay with a source r.r.r.r in a remote realm's range (e.g.,
99.x.x.x claiming to originate on Mars) is trivially spoofable within
the local realm unless the relay verifies the packet's origin through
some mechanism outside the ASIP header. This document does not
define a cross-realm authentication mechanism; the companion DTN
profile should define one (e.g., BPSec [RFC9172] over the Bundle
Protocol carrying ASIP as payload, or a relay-to-relay IPsec/ESP
tunnel anchored to published realm-relay identity). Until that
profile exists, a realm relay SHOULD treat packets sourced from a
remote realm as authenticated only when received on a physical or
cryptographic channel that is itself bound to the peer realm's relay
(e.g., a preshared-key IPsec tunnel to a specific named Martian relay
endpoint). Unauthenticated packets carrying remote-realm source
addresses SHOULD be dropped at the terrestrial-realm ingress under
this Informative guidance; the normative MUST-drop rule for scope-
boundary violations in general lives in §14.11 and covers this case
by the scope-containment principle.
*Design note:* These allocations are deliberately generous.
Reserving entire /8 blocks for bodies that currently have zero
networked devices is intentional. The cost of reserving address
space now is zero. The cost of not having it when Mars has a
permanent settlement is a protocol revision.
3.13. 3.13. Documentation and Testing Range (254.0.0.0/8 in r.r.r.r)
The r.r.r.r range 254.0.0.0/8 is reserved for documentation,
examples, and testing. This is analogous to IPv4's 192.0.2.0/24
(TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24 (TEST-
NET-3), but provides a substantially larger space suitable for
complex multi-AS test scenarios.
Addresses within 254.0.0.0/8 MUST NOT appear on any production
network and MUST be filtered at all border routers. Example:
254.0.0.1::192.168.1.1 (test ASN 1, host 192.168.1.1)
254.0.0.2:0.0.0.3::10.0.0.1 (test ASN 2, zone 3, host 10.0.0.1)
Hause Expires 18 October 2026 [Page 19]
Internet-Draft ASIP April 2026
3.14. 3.14. Stateless Address Autoconfiguration (SLAAC-ASIP)
ASIP supports stateless address autoconfiguration, derived from IPv6
SLAAC [RFC4862] but adapted for the 32-bit host field.
3.14.1. 3.14.1. Overview
SLAAC-ASIP allows a device to configure a routable ASIP address
without contacting a DHCP server. The device learns the network
prefix (r.r.r.r:z.z.z.z:s.s.s.s, 96 bits) from Router Advertisements
and generates the h.h.h.h host portion locally.
SLAAC-ASIP is OPTIONAL. Operators MAY require DHCP-ASIP-only
addressing via a flag in Router Advertisements, identical to IPv6's M
(Managed) flag. SLAAC-ASIP and DHCP-ASIP MAY coexist on the same
network.
3.14.2. 3.14.2. Host Identifier Generation
The h.h.h.h field (32 bits) is generated by one of three methods, in
order of preference:
*Method 1: Stable Opaque Identifier (RECOMMENDED)*
A stable, pseudorandom 32-bit host ID derived from a hash of the
interface identifier, network prefix, a secret key, and a counter
[RFC7217 adapted]:
h.h.h.h = truncate_32(SHA-256(prefix || interface_id || secret_key ||
counter))
This produces a stable address per network (the same device on the
same network always gets the same address) without revealing hardware
identity. This is the ASIP equivalent of IPv6's RFC 7217 stable
privacy addresses.
*Method 2: Temporary Random Identifier (Privacy Extension)*
A cryptographically random 32-bit value, regenerated periodically
(RECOMMENDED interval: 24 hours). Analogous to IPv6 temporary
addresses [RFC8981]. Used for outbound connections where tracking
prevention is desired.
*Method 3: MAC-Derived Identifier (NOT RECOMMENDED)*
The lower 24 bits of the MAC address (OUI stripped) with the upper 8
bits set to a hash of the full 48-bit MAC:
Hause Expires 18 October 2026 [Page 20]
Internet-Draft ASIP April 2026
h.h.h.h = hash_8(MAC[0:6]) || MAC[3:6]
This method is NOT RECOMMENDED because it exposes hardware identity,
analogous to the privacy concerns with IPv6's original EUI-64 scheme.
It is defined for constrained devices that lack a cryptographic
random number generator.
*Reserved host values:* h.h.h.h = 0.0.0.0 (network identifier) and
h.h.h.h = 255.255.255.255 (subnet broadcast) are reserved and MUST
NOT be generated by SLAAC-ASIP. If Method 1's hash output or Method
2's random draw produces one of these reserved values, the
implementation MUST discard the candidate and regenerate (for Method
1, by incrementing the counter and re-hashing; for Method 2, by
drawing a new random value). The probability of this event is 2/2^32
per draw and does not meaningfully affect the DAD retry budget.
3.14.3. 3.14.3. Duplicate Address Detection (DAD)
Before using a SLAAC-ASIP-generated address, a device MUST perform
Duplicate Address Detection using ICMP-ASIP Neighbor Solicitation
messages (analogous to IPv6 DAD [RFC4862]). The device sends an
ICMP-ASIP Neighbor Solicitation to the tentative address using its
link-local address as the source. If a response is received, the
address is in use and the device MUST generate a new h.h.h.h
(increment the counter for Method 1, regenerate for Method 2).
*Collision bound and DHCP-ASIP fallback:* The 32-bit host field is
smaller than IPv6's 64-bit interface identifier. Birthday-paradox
analysis gives the following collision probabilities on a single
subnet with N concurrent SLAAC-generated host IDs drawn uniformly at
random from 2^32: P(collision) ~= 1 - exp(-N^2 / 2^33). At N=10,000:
P ~= 1.16%. At N=50,000: P ~= 25.3%. At N=65,536 (2^16): P ~= 39.3%.
The 50%-collision point is N ~= sqrt(2 ln 2 * 2^32) ~= 77,162 hosts.
Modern datacenter leaf subnets routinely approach the tens of
thousands. Accordingly:
* On subnets expected to carry fewer than 10,000 concurrent devices,
SLAAC-ASIP MAY be used as the sole addressing method.
* On subnets that may exceed 10,000 concurrent devices, Router
Advertisements MUST set the M (Managed) flag and devices MUST
obtain addresses via DHCP-ASIP. SLAAC-ASIP MAY still be used for
the link-local bootstrap address.
* DAD retries MUST be bounded. After 3 collisions, a device MUST
fall back to DHCP-ASIP or report failure to the operator rather
than re-rolling indefinitely.
Hause Expires 18 October 2026 [Page 21]
Internet-Draft ASIP April 2026
Operators deploying very large flat L2 domains (>10k hosts) SHOULD
segment those domains into smaller subnets rather than relying on
32-bit SLAAC uniqueness. The trade-off narrative motivating the 10k
threshold, including the birthday-paradox curve and the relation to
IPv6's 64-bit interface identifier, is summarized in §18.7.
3.14.4. 3.14.4. SLAAC-ASIP Sequence
1. Interface comes up 2. Generate link-local address:
169.254.0.0::h.h.h.h (SLAAC-ASIP Method 1 or 2) 3. Perform DAD on
link-local address 4. Send Router Solicitation from link-local
address 5. Receive Router Advertisement containing prefix (r:z:s) 6.
Generate host ID h.h.h.h for the advertised prefix 7. Perform DAD on
the full address r:z:s:h 8. Address is ready for use
The entire sequence completes in under 2 seconds on a typical wired
network, comparable to IPv6 SLAAC.
3.15. 3.15. Address Usage Summary
+=================+==================+=========================+
| r.r.r.r Range | Usage | Scope |
+=================+==================+=========================+
| 0.0.0.0 (with | IPv4-mapped | Translated/encapsulated |
| z=0, s=0) | | per Section 12 |
+-----------------+------------------+-------------------------+
| 0.0.0.1 - | Terrestrial ASN | Global (eBGP-ASIP) |
| 96.255.255.255 | Unicast | |
+-----------------+------------------+-------------------------+
| 97.0.0.0/8 | Near-Earth | Realm (reserved) |
| | Infrastructure | |
+-----------------+------------------+-------------------------+
| 98.0.0.0/8 | Cislunar / Lunar | Realm (reserved) |
+-----------------+------------------+-------------------------+
| 99.0.0.0/8 | Martian | Realm (reserved) |
+-----------------+------------------+-------------------------+
| 100.0.0.0/8 | RINE peering | Link (IXP only) |
| | links | |
+-----------------+------------------+-------------------------+
| 101.0.0.0 - | Terrestrial ASN | Global (eBGP-ASIP) |
| 126.255.255.255 | Unicast | |
+-----------------+------------------+-------------------------+
| 127.0.0.0/8 | Internal zone | Organization |
| | prefixes | |
+-----------------+------------------+-------------------------+
| 128.0.0.0 - | Terrestrial ASN | Global (eBGP-ASIP) |
| 169.253.255.255 | Unicast | |
+-----------------+------------------+-------------------------+
Hause Expires 18 October 2026 [Page 22]
Internet-Draft ASIP April 2026
| 169.254.0.0/16 | Link-local | Link only |
+-----------------+------------------+-------------------------+
| 169.255.0.0 - | Terrestrial ASN | Global (eBGP-ASIP) |
| 239.255.255.255 | Unicast | |
+-----------------+------------------+-------------------------+
| 240.0.0.0/8 | Mesh / Ad-hoc | Mesh domain |
+-----------------+------------------+-------------------------+
| 241.0.0.0 - | Future celestial | Reserved |
| 249.255.255.255 | bodies | |
+-----------------+------------------+-------------------------+
| 250.0.0.0/8 | DTN Relay | Realm bridge |
+-----------------+------------------+-------------------------+
| 251.0.0.0 - | Reserved | Future use |
| 253.255.255.255 | | |
+-----------------+------------------+-------------------------+
| 254.0.0.0/8 | Documentation / | Never routed |
| | Testing | |
+-----------------+------------------+-------------------------+
| 255.0.0.0 - | Reserved | Future use; MUST NOT be |
| 255.255.254.255 | | routed |
+-----------------+------------------+-------------------------+
| 255.255.255.0 - | Cross-ASN | Per-value assignment; |
| 255.255.255.254 | Multicast | see Sections 4.2 and 10 |
+-----------------+------------------+-------------------------+
| 255.255.255.255 | Broadcast | L2 broadcast only |
+-----------------+------------------+-------------------------+
Table 2
Most devices on most networks use either internal zone addressing
(127.x.x.x) or their organization's public ASN. Link-local
(169.254.x.x) is always present on every interface as a bootstrap
channel.
4. 4. Address Classes
+=================+================+==========================+
| r.r.r.r Value | Class | Description |
+=================+================+==========================+
| 0.0.0.0 (z=0, | IPv4-Mapped | Legacy IPv4 destination; |
| s=0) | | translated/encapsulated |
| | | per Section 12 |
+-----------------+----------------+--------------------------+
| 0.0.0.1 - | Terrestrial | Earth internet, public |
| 96.255.255.255 | ASN Unicast | routing via eBGP-ASIP |
+-----------------+----------------+--------------------------+
| 97.0.0.0/8 | Near-Earth | LEO/GEO satellite |
| | Realm | infrastructure |
Hause Expires 18 October 2026 [Page 23]
Internet-Draft ASIP April 2026
| | | (reserved) |
+-----------------+----------------+--------------------------+
| 98.0.0.0/8 | Cislunar Realm | Earth-Moon |
| | | infrastructure |
| | | (reserved) |
+-----------------+----------------+--------------------------+
| 99.0.0.0/8 | Martian Realm | Mars infrastructure |
| | | (reserved) |
+-----------------+----------------+--------------------------+
| 100.0.0.0/8 | RINE Peering | AS-to-AS link addressing |
| | | only |
+-----------------+----------------+--------------------------+
| 101.0.0.0 - | Terrestrial | Earth internet, public |
| 126.255.255.255 | ASN Unicast | routing via eBGP-ASIP |
+-----------------+----------------+--------------------------+
| 127.0.0.0/8 | Internal Zone | Organization-scoped, |
| | | never routed externally |
+-----------------+----------------+--------------------------+
| 128.0.0.0 - | Terrestrial | Earth internet, public |
| 169.253.255.255 | ASN Unicast | routing via eBGP-ASIP |
+-----------------+----------------+--------------------------+
| 169.254.0.0/16 | Link-Local | Single link only, never |
| | | forwarded by routers |
+-----------------+----------------+--------------------------+
| 169.255.0.0 - | Terrestrial | Earth internet, public |
| 239.255.255.255 | ASN Unicast | routing via eBGP-ASIP |
+-----------------+----------------+--------------------------+
| 240.0.0.0/8 | Mesh / Ad-Hoc | Self-organizing |
| | | networks, mesh-scoped |
+-----------------+----------------+--------------------------+
| 241.0.0.0 - | Interplanetary | Future celestial body |
| 249.255.255.255 | (Reserved) | allocations |
+-----------------+----------------+--------------------------+
| 250.0.0.0/8 | DTN Relay | Delay-tolerant relay |
| | | nodes (reserved) |
+-----------------+----------------+--------------------------+
| 251.0.0.0 - | Reserved | Future use |
| 253.255.255.255 | | |
+-----------------+----------------+--------------------------+
| 254.0.0.0/8 | Documentation | MUST NOT appear on |
| | / Testing | production networks |
+-----------------+----------------+--------------------------+
| 255.0.0.0 - | Reserved | Future use; MUST NOT be |
| 255.255.254.255 | | routed |
+-----------------+----------------+--------------------------+
| 255.255.255.0 - | Cross-ASN | Per-value assignment; |
| 255.255.255.254 | Multicast | see Section 4.2 and |
| | | Section 10 |
Hause Expires 18 October 2026 [Page 24]
Internet-Draft ASIP April 2026
+-----------------+----------------+--------------------------+
| 255.255.255.255 | Broadcast | L2 broadcast, MUST NOT |
| | | be routed |
+-----------------+----------------+--------------------------+
Table 3
4.1. 4.1. Scope Hierarchy
ASIP defines a formal scope hierarchy for addresses, drawn from
IPv6's multicast scope model but applied universally:
+==============+==================+===========================+
| Scope Level | Boundary | Example r.r.r.r Ranges |
+==============+==================+===========================+
| Link | Single physical/ | 169.254.0.0/16 (link- |
| | virtual link | local) |
+--------------+------------------+---------------------------+
| Mesh | Self-organizing | 240.0.0.0/8 |
| | network domain | |
+--------------+------------------+---------------------------+
| Organization | AS boundary | 127.0.0.0/8 (internal |
| | | zones) |
+--------------+------------------+---------------------------+
| Terrestrial | Earth internet | 0.0.0.1 - 96.x, 101.x - |
| | | 126.x, 128.x - 239.x |
+--------------+------------------+---------------------------+
| Realm | Celestial body / | 97.x, 98.x, 99.x, 241.x - |
| | region | 249.x, 250.x |
+--------------+------------------+---------------------------+
| Universal | All realms | Not yet defined; requires |
| | | inter-realm relay |
+--------------+------------------+---------------------------+
Table 4
With the one exception called out immediately below for mesh, each
strictly-nested scope level in the table contains the ones below it.
A link-local address is never visible at organization scope. An
organization-internal address is never visible at terrestrial scope.
A terrestrial address is never visible in another realm without
explicit relay. This containment is enforced by routers at each
boundary.
*Mesh scope (240.0.0.0/8) is orthogonal rather than strictly nested.*
A mesh domain is not contained within a terrestrial AS and is not a
non-terrestrial realm; it is a self-organizing scope reachable only
via the mesh-gateway bridge of §3.11. For scope-boundary enforcement
Hause Expires 18 October 2026 [Page 25]
Internet-Draft ASIP April 2026
(§14.11) it is treated as a peer of "terrestrial" and "realm": mesh
addresses MUST NOT leave the mesh domain natively, and terrestrial or
realm addresses MUST NOT enter a mesh domain natively; a mesh gateway
that performs address translation is the only sanctioned bridge.
IPv4-mapped addresses (r=z=s=0, Section 3.3) are the single explicit
exception: they represent a legacy IPv4 destination that has no
realm, are handled by the translators defined in Section 12, and MUST
NOT be forwarded natively into any non-terrestrial realm.
4.2. 4.2. Multicast Prefix Assignments (r.r.r.r = 255.255.255.x)
+=================+==============================================+
| r.r.r.r | Assignment |
+=================+==============================================+
| 255.255.255.0 | General cross-ASN multicast (includes all |
| | well-known protocol groups; see §10.4) |
+-----------------+----------------------------------------------+
| 255.255.255.1 | RESERVED for a future per-protocol OSPF-ASIP |
| | group encoding; MUST NOT be used by current |
| | implementations (see §10.4) |
+-----------------+----------------------------------------------+
| 255.255.255.2 | RESERVED for a future per-protocol eBGP-ASIP |
| | peer-discovery group encoding; MUST NOT be |
| | used by current implementations (see §10.4) |
+-----------------+----------------------------------------------+
| 255.255.255.3 | RESERVED for a future per-protocol IS-IS- |
| | ASIP group encoding; MUST NOT be used by |
| | current implementations (see §10.4) |
+-----------------+----------------------------------------------+
| 255.255.255.4 - | Available for IANA assignment |
| 255.255.255.127 | |
+-----------------+----------------------------------------------+
| 255.255.255.128 | Reserved, future use |
| - | |
| 255.255.255.254 | |
+-----------------+----------------------------------------------+
| 255.255.255.255 | Broadcast |
+-----------------+----------------------------------------------+
Table 5
5. 5. ASIP Packet Header
Hause Expires 18 October 2026 [Page 26]
Internet-Draft ASIP April 2026
5.1. 5.1. Header Format
ASIP uses IP version number 8 in the Version field. The base header
is fixed-length (40 bytes), drawing from IPv6's design decision to
eliminate variable-length options from the base header. Additional
functionality (fragmentation, routing options, hop-by-hop processing)
is provided via extension headers identified by the Next Header
field, identical in mechanism to IPv6 [RFC8200].
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version|
Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Source ASN Prefix (r.r.r.r) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Source Zone ID (z.z.z.z) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Source Subnet ID (s.s.s.s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Source Host ID (h.h.h.h) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Destination ASN Prefix (r.r.r.r) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Destination Zone ID (z.z.z.z) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Destination Subnet ID (s.s.s.s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Destination Host ID (h.h.h.h) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*Field definitions:*
Hause Expires 18 October 2026 [Page 27]
Internet-Draft ASIP April 2026
+=============+======+=============================================+
| Field | Bits | Description |
+=============+======+=============================================+
| Version | 4 | Always 8 for ASIP |
+-------------+------+---------------------------------------------+
| Traffic | 8 | Differentiated services (DSCP + ECN), |
| Class | | identical to IPv6 Traffic Class and |
| | | backward compatible with IPv4 ToS/DSCP |
+-------------+------+---------------------------------------------+
| Flow Label | 20 | Per-flow identifier for QoS and ECMP |
| | | hashing, identical semantics to IPv6 |
| | | [RFC6437]. Enables routers to identify |
| | | packets belonging to the same flow without |
| | | deep packet inspection. Source-assigned; |
| | | zero if unused. |
+-------------+------+---------------------------------------------+
| Payload | 16 | Length of payload after the base header, in |
| Length | | octets. Does not include the 40-byte base |
| | | header itself. (IPv6 semantics.) |
+-------------+------+---------------------------------------------+
| Next Header | 8 | Identifies the type of the immediately |
| | | following header. Values are drawn from |
| | | the IPv6 Next Header registry for protocols |
| | | that are identical under ASIP (6 = TCP, 17 |
| | | = UDP, 43 = Routing, 44 = Fragment, 59 = No |
| | | Next Header, 60 = Destination Options, |
| | | 50/51 = ESP/AH). ASIP-specific protocols |
| | | receive distinct assignments; see |
| | | Section 5.3 and Section 15.5. ICMP-ASIP = |
| | | 143 (to be assigned by IANA). |
+-------------+------+---------------------------------------------+
| Hop Limit | 8 | Decremented by 1 at each forwarding node. |
| | | Packet is discarded when it reaches 0. |
| | | (Identical to IPv6 Hop Limit and IPv4 TTL |
| | | in function.) |
+-------------+------+---------------------------------------------+
| Source | 128 | Full 128-bit ASIP source address (r.r.r.r : |
| Address | | z.z.z.z : s.s.s.s : h.h.h.h) |
+-------------+------+---------------------------------------------+
| Destination | 128 | Full 128-bit ASIP destination address |
| Address | | |
+-------------+------+---------------------------------------------+
Table 6
*Total base header size: 40 bytes.* This is identical to IPv6 and 20
bytes larger than IPv4's minimum header.
Hause Expires 18 October 2026 [Page 28]
Internet-Draft ASIP April 2026
5.2. 5.2. Design Rationale: What Was Dropped from IPv4
The ASIP header deliberately omits several IPv4 fields:
* *IHL (Internet Header Length):* Unnecessary. The ASIP base header
is fixed at 40 bytes. Variable-length options are handled via
extension headers, not inline.
* *Identification, Flags, Fragment Offset:* Moved to a Fragment
Extension Header (Next Header = 44), identical to IPv6's approach.
Fragmentation is performed only by the source, not by intermediate
routers. This eliminates the performance penalty of router-path
fragmentation and the reassembly-based attacks that plagued IPv4.
*Fragmentation happens at the inner ASIP layer only, not at any
outer encapsulation (§12.3).* ASIP-to-IPv4 encapsulators MUST set
the outer IPv4 DF bit (§12.8) so that outer fragmentation is
suppressed; any too-big condition is reported upstream and
fragmentation, if needed, is performed by the ASIP source. This
eliminates the ambiguity of where fragmentation occurs in a
translate-plus-encapsulate path.
* *Header Checksum:* Dropped, identical to IPv6's rationale. Link-
layer (L2) and transport-layer (L4) checksums provide integrity
verification. The per-hop header checksum in IPv4 was a
performance bottleneck on high-speed routers (recomputed at every
hop due to TTL decrement) with no security benefit.
5.3. 5.3. Extension Headers
ASIP uses the same extension header mechanism as IPv6. Extension
headers are chained via the Next Header field and processed in order.
The following extension headers are defined:
Hause Expires 18 October 2026 [Page 29]
Internet-Draft ASIP April 2026
+============+=============+====================================+
| Next | Extension | Description |
| Header | Header | |
| Value | | |
+============+=============+====================================+
| 0 | Hop-by-Hop | Options examined by every node |
| | Options | along the path |
+------------+-------------+------------------------------------+
| 43 | Routing | Source routing and related |
| | | functions |
+------------+-------------+------------------------------------+
| 44 | Fragment | Fragmentation and reassembly |
+------------+-------------+------------------------------------+
| 50 | ESP | Encapsulating Security Payload |
| | | (IPsec) |
+------------+-------------+------------------------------------+
| 51 | AH | Authentication Header (IPsec) |
+------------+-------------+------------------------------------+
| 59 | No Next | Nothing follows this header |
| | Header | |
+------------+-------------+------------------------------------+
| 60 | Destination | Options examined only by the |
| | Options | destination |
+------------+-------------+------------------------------------+
| 143 | ICMP-ASIP | ASIP ICMP messages (to be assigned |
| | | by IANA; distinct from IPv6 NH=58 |
| | | to prevent dispatcher ambiguity |
| | | across header-stripping |
| | | middleboxes) |
+------------+-------------+------------------------------------+
| (reserved, | Mobility | Explicitly out of scope for this |
| no | | document. No Next Header value is |
| assignment | | requested in §15 for ASIP |
| requested) | | mobility. A future specification |
| | | MAY define Mobile ASIP and request |
| | | an IANA assignment at that time; |
| | | this document does not reserve or |
| | | request any code point for it. |
+------------+-------------+------------------------------------+
Table 7
By reusing IPv6's extension header numbering and semantics, ASIP
benefits from the extensive implementation experience and security
analysis already applied to IPv6 extension header processing
[RFC8200, RFC7045].
Hause Expires 18 October 2026 [Page 30]
Internet-Draft ASIP April 2026
*IPsec (AH/ESP) over ASIP.* AH (NH=51) and ESP (NH=50) inherit IPv6's
semantics [RFC4301, RFC4302, RFC4303] verbatim, except that the AH
Integrity Check Value computation covers the full 128-bit ASIP source
and destination addresses as written on the wire. Because the
r.r.r.r locator is allowed to be rewritten at AS boundaries (§8.3.2),
AH's immutable-field assumption does not hold for r.r.r.r across a
locator rewrite; AH-protected traffic MUST NOT traverse a boundary
that rewrites r.r.r.r, or the ICV check will fail at the far end.
ESP is unaffected because it does not sign the outer IP header.
Operators who require locator rewriting on AH-protected flows MUST
use tunnel-mode ESP or re-establish the SA after the rewriting
boundary.
*Enforcement at rewriting nodes.* The "MUST NOT traverse" rule above
is a prevention rule, not a suggestion. A router that would
otherwise rewrite r.r.r.r per §8.3.2 MUST first parse the extension-
header chain of the inbound packet; if any AH header (NH=51) is
present anywhere in the chain, the router MUST NOT rewrite and MUST
drop the packet, emitting ICMP-ASIP Destination Unreachable (Type=1,
Code=10 "Administratively Prohibited by AH-rewrite policy"; exact
Code per the §15.5 registry). Silently rewriting an AH-protected
packet produces an ICV-failure symptom at the destination that is
indistinguishable from an on-path attack and MUST be avoided. A
middlebox that strips AH before rewrite to avoid this check is a
downgrade attacker; endpoints that require AH integrity SHOULD
additionally verify via an ESP-protected channel or out-of-band
attestation that no rewrite-capable intermediary is on the path.
This is a classical downgrade-attack concern inherited from IPsec and
is not unique to ASIP.
*Ordering with ingress filtering.* At a border router that both
implements §14.1 ingress filtering and performs §8.3.2 locator
rewrite, the ingress filter MUST run on the received packet as it
arrived on the wire, before any rewrite. The rewrite MUST occur
after the ingress filter has validated the original source r.r.r.r
against the peer's authorized-origin set. Performing rewrite before
ingress filtering would either (i) validate the rewritten value
against the wrong peer set, or (ii) fail to validate at all; both
outcomes break BCP 38 semantics.
5.4. 5.4. Flow Label Usage
The 20-bit Flow Label enables per-flow identification without
transport-layer inspection. Semantics are identical to IPv6 Flow
Label [RFC6437]: the value is opaque to the network, source-assigned,
and used as an input to hash-based path-selection functions.
Hause Expires 18 October 2026 [Page 31]
Internet-Draft ASIP April 2026
* *ECMP hashing:* Routers MAY use the flow label (combined with
source and destination addresses) as input to ECMP hash functions,
ensuring all packets of a flow traverse the same path. This is
the primary intended use.
* *QoS classification:* Middleboxes MAY classify traffic by flow
label as a hint only.
A source that does not use flow-based path selection MUST set the
flow label to zero. Routers MUST NOT parse structure inside the flow
label, MUST NOT make security decisions based on its value, and MUST
NOT rewrite it in the forwarding path.
*Relationship to external path-selection metrics.* Any path-selection
metric external to this specification (e.g., the OPTIONAL Cost Factor
of §17 / draft-asip-cf-00, or a future operator-defined metric) MUST
NOT be encoded into the flow label and MUST NOT cause a router to
parse structure inside it. The flow label remains opaque regardless
of whether such a metric is deployed. Where an external metric
drives path selection, the flow label MAY be used as an ECMP hash
input that pins a flow to whichever path that metric selected — this
is an emergent property of hash-based forwarding, not a structural
use of the flow label.
5.5. 5.5. Socket API Compatibility
Existing IPv4 applications use the standard BSD socket API with
AF_INET and sockaddr_in. The ASIP compatibility layer intercepts
these calls transparently. The application requires zero ASIP
awareness.
New applications MAY use AF_ASIP with sockaddr_asip:
c struct sockaddr_asip { sa_family_t asip_family; /* AF_ASIP */
in_port_t asip_port; /* Port number */ uint32_t asip_asn; /* r.r.r.r
ASN locator */ uint32_t asip_zone; /* z.z.z.z Zone ID */ uint32_t
asip_subnet; /* s.s.s.s Subnet ID */ uint32_t asip_host; /* h.h.h.h
Host ID */ uint32_t asip_flowlabel; /* Flow label (20 bits) */
uint32_t asip_scope_id; /* Interface index for link-local and mesh
scopes; zero for all other scopes */ };
All numeric fields except asip_family are in network byte order. The
flow label occupies the low-order 20 bits of asip_flowlabel; the
upper 12 bits MUST be zero on transmission and MUST be ignored on
reception. The asip_scope_id field is in host byte order and carries
the interface index disambiguating which link a link-local
(169.254.0.0/16 in r.r.r.r, §3.10) or mesh (240.0.0.0/8 in r.r.r.r,
§3.11) address refers to; it serves the same role as
Hause Expires 18 October 2026 [Page 32]
Internet-Draft ASIP April 2026
sockaddr_in6.sin6_scope_id [RFC4291]. asip_scope_id MUST be zero for
non-link-local, non-mesh addresses and MUST be ignored by the stack
for those scopes. An application operating on link-local or mesh
addresses across multiple interfaces MUST set asip_scope_id to the
correct interface index; a bind or sendto with asip_scope_id=0 on a
multi-interface host for a link-local address is implementation-
defined and MAY fail with EINVAL.
5.6. 5.6. IPv4/ASIP Coexistence Processing
When an ASIP-aware router receives a packet with Version = 4, it
processes it as standard IPv4. When an ASIP-aware router receives a
packet with Version = 8, it processes the 128-bit source and
destination addresses as specified in Sections 3 and 8. If the
destination has r=z=s=0 (IPv4-mapped form, Section 3.3), the packet's
endpoint is an IPv4 host and the router forwards it toward an IPv4/
ASIP translator at the AS boundary (Section 12.2) rather than
attempting to dispatch it on h.h.h.h alone; the source may be either
a native ASIP address (the common case, §12.7.1) or itself
IPv4-mapped (the IPv4-to-IPv4-over-ASIP relay case, rare). A
Version=8 packet is always a Version=8 frame on the wire; the r=z=s=0
condition on either address is an addressing form, not an alternate
forwarding mode.
Routers, hosts, and middleboxes that are not ASIP-aware see a
Version=8 frame as an unrecognized IP version and drop it. This is
not a quiet no-op; it is a hard break. Every forwarding element in
the path between two ASIP-aware endpoints must either be ASIP-aware
or be bypassed by the transition mechanisms in Section 12. This cost
is the reason ASIP is specified as a new address family with a
transition mechanism rather than as a wire-level IPv4 superset.
6. 6. Notation and Address Compression
ASIP defines a colon-separated field notation as the canonical text
representation, with compression rules that eliminate consecutive
all-zero fields. All compliant implementations MUST accept both
compressed and uncompressed forms and MUST be able to produce
compressed output.
6.1. 6.1. Canonical Notation
The canonical ASIP text representation uses colons to separate the
four 32-bit fields. Each field is written in standard dotted
decimal:
r.r.r.r:z.z.z.z:s.s.s.s:h.h.h.h
Hause Expires 18 October 2026 [Page 33]
Internet-Draft ASIP April 2026
Examples (uncompressed): 0.0.59.65:0.0.0.1:0.0.0.10:192.0.2.1 (ASN
15169, Zone 1, Subnet 10, Host) 0.0.251.240:0.0.0.0:0.0.0.0:10.0.0.1
(ASN 64496, flat network) 0.0.0.0:0.0.0.0:0.0.0.0:8.8.8.8 (IPv4
compatible: 8.8.8.8) 127.1.0.0:0.0.0.5:0.0.1.0:10.0.0.1 (Internal
zone 1, zone 5, subnet 256)
6.2. 6.2. ASN Integer Notation
The r.r.r.r field MAY be written as a plain decimal ASN integer
instead of dotted decimal. This is the RECOMMENDED human-facing
format for public addresses:
{ASN}:z.z.z.z:s.s.s.s:h.h.h.h
Examples (uncompressed): 15169:0.0.0.1:0.0.0.10:192.0.2.1 (same as
first example above) 64496:0.0.0.0:0.0.0.0:10.0.0.1 (same as second
example above) 0:0.0.0.0:0.0.0.0:8.8.8.8 (IPv4 compatible)
All compliant implementations MUST accept both dotted-decimal and
integer forms for the ASN field. Implementations SHOULD produce ASN
integer notation in user-facing output.
6.3. 6.3. Zero-Field Compression (:: Notation)
One or more consecutive fields whose value is 0.0.0.0 MAY be replaced
by ::, analogous to IPv6 zero compression [RFC5952]. Since ASIP has
exactly four fields, the compression rules are simpler and less
ambiguous than IPv6.
*Rules:*
1. :: replaces one or more consecutive all-zero fields (a field is
all-zero when its 32-bit value is 0x00000000, i.e., 0.0.0.0).
2. :: MUST NOT appear more than once in a single address.
3. When multiple runs of consecutive zero fields exist and are of
equal length, :: SHOULD replace the leftmost run.
4. :: MAY replace a single all-zero field. (Unlike RFC 5952's
recommendation for IPv6, single-field compression is permitted in
ASIP because each field is 32 bits and eliminating even one saves
substantial notation length.)
Hause Expires 18 October 2026 [Page 34]
Internet-Draft ASIP April 2026
5. The host field (h.h.h.h) MUST always be written explicitly. ::
MUST NOT compress the rightmost field. (Rationale: the host
field is the most operationally significant for debugging, and
omitting it creates dangerous ambiguity with IPv4-compatible
addresses.)
6. The ASN field (r.r.r.r) written as integer 0 is valid. Both
0::10.0.0.1 and ::10.0.0.1 expand to ASN=0, zone=0, subnet=0,
host=10.0.0.1 and are semantically identical; the leading 0
before :: is an explicit-field form that the expansion algorithm
(§6.5) collapses to the same wire value as the ::-only form.
Implementations MUST treat the two as equivalent.
*Compression table* (all possible positions for four fields where
h.h.h.h is never compressed):
+============================+==========+==========================+
| Fields Present | Notation | Meaning |
+============================+==========+==========================+
| All four explicit | A:Z:S:H | No compression |
+----------------------------+----------+--------------------------+
| Zone is zero | A::S:H | z = 0.0.0.0 |
+----------------------------+----------+--------------------------+
| Subnet is zero | A:Z::H | s = 0.0.0.0 |
+----------------------------+----------+--------------------------+
| Zone and Subnet are zero | A::H | z = 0.0.0.0, s = 0.0.0.0 |
+----------------------------+----------+--------------------------+
| ASN and Zone are zero | ::S:H | r = 0, z = 0.0.0.0 |
+----------------------------+----------+--------------------------+
| ASN, Zone, Subnet are zero | ::H | r = 0, z = 0.0.0.0, s = |
| | | 0.0.0.0 |
+----------------------------+----------+--------------------------+
Table 8
*Note:* Because :: can only appear once, an address where only the
ASN and Subnet are zero (but the Zone is non-zero) cannot compress
both. In this case, write the ASN explicitly as 0:Z:0.0.0.0:H or
compress only the longer run. In practice this pattern is rare.
6.4. 6.4. Compression Examples
``` UNCOMPRESSED COMPRESSED ----------- ----------
Public host, flat network: 64496:0.0.0.0:0.0.0.0:192.0.2.1
64496::192.0.2.1
Hause Expires 18 October 2026 [Page 35]
Internet-Draft ASIP April 2026
Public host, zone 1, subnet 10: 15169:0.0.0.1:0.0.0.10:192.0.2.1
15169:0.0.0.1:0.0.0.10:192.0.2.1 (no zero fields, no compression)
IPv4 compatible: 0:0.0.0.0:0.0.0.0:8.8.8.8 ::8.8.8.8
Internal zone, flat: 127.1.0.0:0.0.0.0:0.0.0.0:10.0.0.1
127.1.0.0::10.0.0.1
Internal zone, with zone and subnet:
127.1.0.0:0.0.0.5:0.0.1.0:10.0.0.1 127.1.0.0:0.0.0.5:0.0.1.0:10.0.0.1
(no zero fields, no compression)
Internal zone, zone set, subnet zero:
127.2.0.0:0.0.0.3:0.0.0.0:172.16.0.1 127.2.0.0:0.0.0.3::172.16.0.1
RINE peering link: 100.0.0.1:0.0.0.0:0.0.0.0:10.255.0.1
100.0.0.1::10.255.0.1
Loopback (all zeros except host): 0:0.0.0.0:0.0.0.0:127.0.0.1
::127.0.0.1
Multicast: 255.255.255.0:0.0.0.0:0.0.0.0:224.0.0.1
255.255.255.0::224.0.0.1 ```
6.5. 6.5. Expansion Algorithm
To expand a compressed address, an implementation:
1. Splits the string on :: to obtain a left part and a right part.
2. Splits each part on : to count explicit fields.
3. Inserts enough 0.0.0.0 fields between left and right to bring the
total to exactly four (ASN, Zone, Subnet, Host).
4. If the ASN field is a plain integer, converts it to a 32-bit
unsigned value in network byte order.
5. If no :: is present, all four fields must be explicit.
This algorithm is deterministic and requires no lookahead.
6.6. 6.6. Flat Dotted Notation (Wire/Debug Format)
For diagnostic output, packet dumps, and wire-level representations,
implementations MAY use flat dotted notation with all 16 octets dot-
separated:
Hause Expires 18 October 2026 [Page 36]
Internet-Draft ASIP April 2026
0.0.59.65.0.0.0.1.0.0.0.10.192.0.2.1
This format is unambiguous but not human-friendly for routine use.
It MUST be accepted by all parsers. Implementations SHOULD NOT
produce this format in user-facing output; use canonical or
compressed notation instead.
6.7. 6.7. CIDR Prefix Notation
ASIP CIDR notation appends a prefix length to the compressed address,
separated by /:
15169::/32 (ASN 15169, all addresses within that ASN)
15169:0.0.0.1::/64 (ASN 15169, Zone 1, all subnets/hosts)
127.1.0.0::/32 (Internal zone 1, all addresses) ::0.0.0.0/0 (Default
route)
The prefix length counts bits from the most significant bit of the
r.r.r.r field. Common prefix boundaries:
+===============+==============+===================================+
| Prefix Length | Boundary | Meaning |
+===============+==============+===================================+
| /32 | After ASN | All addresses within one AS |
+---------------+--------------+-----------------------------------+
| /64 | After Zone | All subnets/hosts within one zone |
+---------------+--------------+-----------------------------------+
| /96 | After Subnet | All hosts within one subnet |
+---------------+--------------+-----------------------------------+
| /128 | Full address | Single host |
+---------------+--------------+-----------------------------------+
| /0 | None | Default route |
+---------------+--------------+-----------------------------------+
Table 9
6.8. 6.8. Design Note on Notation Choices
The choice to retain dotted decimal and use colons only as field
separators is deliberate. IPv6's hexadecimal colon notation
(2001:0db8::1) is compact but unfamiliar to many operators and a
common source of transcription errors. ASIP notation is immediately
readable by anyone who can read an IPv4 address. The :: compression
symbol is borrowed from IPv6 because it is the one piece of IPv6
notation that operators already understand and that solves a real
readability problem.
Hause Expires 18 October 2026 [Page 37]
Internet-Draft ASIP April 2026
The requirement that h.h.h.h always be explicit is a deliberate
safety constraint. In IPv4 troubleshooting, the host address is the
most commonly referenced field. Allowing it to be compressed away
would make compressed ASIP addresses actively hostile to operational
debugging. The upper fields (ASN, Zone, Subnet) are structural and
rarely change during a troubleshooting session; the host field
changes constantly.
This is an explicit trade-off: ASIP addresses are longer to write
than IPv6 addresses but shorter to understand, and common compressed
forms (like ::8.8.8.8 for IPv4-compatible addresses or
64496::192.0.2.1 for flat-network hosts) are concise enough for
routine use.
7. 7. DNS Integration
7.1. 7.1. A-ASIP Record Type
A new DNS resource record type, A-ASIP, is defined for ASIP
addresses.
* *Type:* A-ASIP (IANA assignment pending)
* *Wire format:* 128-bit ASIP address in network byte order
* *Presentation format:* Canonical notation with compression
(Section 6)
7.2. 7.2. Resolution Behavior
An ASIP-aware resolver SHOULD request both A and A-ASIP records.
Resolution behavior by address-family hint:
* *AF_INET (IPv4-only):* Return A records only. A-ASIP records MUST
NOT be returned through an AF_INET query. Legacy applications
that call gethostbyname() or getaddrinfo() with AF_INET receive
the A record unchanged.
* *AF_ASIP (ASIP-only):* Return A-ASIP records preferentially. When
no A-ASIP record exists but an A record does, synthesize an
IPv4-mapped A-ASIP (r=z=s=0, h = the A record, §3.3) and return
it; the stack routes such traffic via §12 translation or
encapsulation. The stack does not synthesize an ASN locator for
an IPv4-only destination.
* *AF_UNSPEC (both):* Return both A and A-ASIP records if present,
with A-ASIP records ordered first. Applications using Happy
Eyeballs [RFC8305] or equivalent MUST treat the returned set as an
Hause Expires 18 October 2026 [Page 38]
Internet-Draft ASIP April 2026
ordered preference list and MAY attempt connections in parallel.
The resolver MUST NOT silently drop A records when A-ASIP records
exist; doing so breaks dual-availability semantics.
When only an A record is available for an AF_ASIP or AF_UNSPEC query,
the synthesis described above applies. An A-ASIP record MUST NOT be
returned to an AF_INET application.
RFC 1918 addresses MUST NOT be published as A-ASIP records in public
DNS.
7.3. 7.3. Dual Record Example
ns1.example.com. IN A 192.0.2.1 ns1.example.com. IN A-ASIP
15169:0.0.0.1:0.0.0.10:192.0.2.1
8. 8. Routing Protocol Behavior
8.1. 8.1. Multi-Tier Routing Table
ASIP routing uses a tiered lookup model derived directly from the
address structure:
+======+=========+===================+=====================+
| Tier | Field | Scope | Function |
+======+=========+===================+=====================+
| 1 | r.r.r.r | Global (inter-AS) | Routes packet to |
| | | | correct AS border |
+------+---------+-------------------+---------------------+
| 2 | z.z.z.z | AS-internal | Routes packet to |
| | | (inter-zone) | correct zone |
+------+---------+-------------------+---------------------+
| 3 | s.s.s.s | Zone-internal | Routes packet to |
| | | (intra-zone) | correct subnet |
+------+---------+-------------------+---------------------+
| 4 | h.h.h.h | Subnet-local | Delivers to host |
| | | | (identical to IPv4) |
+------+---------+-------------------+---------------------+
Table 10
When r.r.r.r = 0.0.0.0, z.z.z.z = 0.0.0.0, and s.s.s.s = 0.0.0.0, the
packet is IPv4-mapped (§3.3) and the lookup yields a route toward an
IPv4/ASIP translator (§12.2); the Version=8 frame remains a Version=8
frame on the wire until it reaches the translator (§5.6). The tier
structure above describes the lookup ordering for ASIP-native
packets, not an alternate wire format.
Hause Expires 18 October 2026 [Page 39]
Internet-Draft ASIP April 2026
In practice, most backbone routers perform a single Tier 1 lookup
(32-bit ASN match) and forward. The remaining tiers are resolved
only within the destination AS. In the common single-origin case,
the global routing table contains one entry per ASN; multihoming,
anycast, and traffic-engineering more-specifics documented in §8.3.1
add entries on top of that baseline, and §8.3's "honest bound"
paragraph states the realistic table size.
8.2. 8.2. Routing Protocol Extensions
ASIP extends existing routing protocols rather than replacing them:
+==========+================+============+========================+
| Protocol | ASIP Extension | Scope | Status |
+==========+================+============+========================+
| BGP4 | eBGP-ASIP | Inter-AS | REQUIRED for internet- |
| | | (Tier 1) | facing routers |
+----------+----------------+------------+------------------------+
| iBGP | iBGP-ASIP | Inter-zone | RECOMMENDED for multi- |
| | | (Tier 2) | zone AS |
+----------+----------------+------------+------------------------+
| OSPFv2 | OSPF-ASIP | Intra-zone | RECOMMENDED for intra- |
| | | (Tier 3) | zone routing |
+----------+----------------+------------+------------------------+
| IS-IS | IS-IS-ASIP | Intra-AS | OPTIONAL alternative |
| | | (Tier 2/3) | IGP |
+----------+----------------+------------+------------------------+
| Static | Unchanged | All tiers | Always available |
+----------+----------------+------------+------------------------+
Table 11
*Note on existing protocols:* ASIP does not deprecate any existing
routing protocol. Operators MAY continue to use RIPv2, EIGRP, or any
other protocol within their AS for IPv4-compatible traffic. The
"ASIP" extensions add awareness of the 128-bit address space. They
do not remove any existing functionality. Operators MAY additionally
deploy the OPTIONAL Cost Factor metric (§17 companion draft), which
has no effect on conformance to this specification.
8.3. 8.3. eBGP-ASIP
eBGP-ASIP extends BGP4 [RFC4271] with:
* 128-bit address family support (AFI/SAFI for ASIP; see §15.2).
* WHOIS-ASIP route validation integration (Section 8.4, REQUIRED
where the structural routing-table bound is relied upon).
Hause Expires 18 October 2026 [Page 40]
Internet-Draft ASIP April 2026
* An OPTIONAL Cost Factor path attribute specified in a separate
companion document (§17); eBGP-ASIP conformance does not require
CF.
eBGP-ASIP operates alongside BGP4 on the same peering session via
multi-protocol extensions [RFC4760]. eBGP-ASIP does not replace BGP4
for IPv4 prefixes; the two AFIs coexist.
*Prefix granularity and table bound.* The nominal inter-AS
aggregation boundary is /32 in the r.r.r.r field (one prefix per ASN
locator). Prefixes more specific than /32 in r.r.r.r (i.e.,
subdividing a single ASN's address space at the inter-AS boundary)
SHOULD NOT be advertised across AS boundaries; they MAY be advertised
when operationally necessary to support the use cases in
Section 8.3.1. Aggregation less specific than /32 (covering multiple
ASN locators under a single prefix) MAY be performed down to /16 for
internal backbone use but MUST NOT be used to obscure origin at
peering boundaries.
*Honest bound.* The routing-table entry count under ASIP is not equal
to the ASN count. Approximately 74,000 ASNs exist globally (2026);
any bound that simply counts allocated or announced ASNs (e.g., a
"~175,000-entry" figure derived from allocated-but-unannounced ASN
counts) would conflate "ASN count" with "routing-table entry count"
and ignore the reasons operators deaggregate today. The actual entry
count under ASIP will be larger than the ASN count whenever:
* An AS is multihomed and injects separate more-specifics to steer
traffic per upstream (Section 8.3.1);
* An AS uses anycast across multiple origin locations
(Section 11.1);
* An AS splits traffic engineering announcements for failover;
* An AS has legitimately acquired address space from a transferred
ASN and continues to announce the old locator.
Forbidding these use cases does not remove them; operators would
respond by splitting into additional ASNs, which grows the locator
count rather than shrinking the table. The realistic structural
bound is "substantially smaller than today's 1M+ BGP4 table in the
common case, with a long tail of more-specifics driven by the
traffic-engineering use cases that ASIP cannot eliminate." The
specification records the trade-off in that form because a single-
number headline figure would omit the deaggregation drivers that an
implementer must size for.
Hause Expires 18 October 2026 [Page 41]
Internet-Draft ASIP April 2026
8.3.1. 8.3.1. Multihoming, Anycast, and ASN Transfer
Because r.r.r.r is a routing locator rather than a host identity, the
following cases work without re-coupling identifier and locator:
* *Multihoming.* A host reachable through two upstream ASes is
assigned one ASIP address per upstream (e.g., ASN_A:z:s:h and
ASN_B:z:s:h). DNS-ASIP publishes both A-ASIP records.
Applications use happy-eyeballs-style selection between them. The
host's stable identity is the z:s:h triple under its own
administrative scope; r.r.r.r varies with reachability. Server-
side operational impact of a client presenting multiple addresses
is addressed in §18.5b.
* *Cross-ASN anycast.* An anycast service advertised from multiple
ASNs is assigned one address per origin ASN. Each origin ASN
advertises its own ASN_n::h.h.h.h prefix. Clients use DNS-ASIP to
obtain one or more candidate anycast addresses and the routing
system steers each packet to the nearest instance via normal BGP
path selection. This is strictly equal in capability to current
cross-ASN anycast (Cloudflare, Google) and is not artificially
constrained to a single ASN.
* *ASN transfer.* When an ASN transfers between organizations, the
addresses using that ASN as their r.r.r.r locator also transfer.
Operators MAY renumber affected hosts by rewriting r.r.r.r at
ingress (Section 8.3.2); the z:s:h portion remains stable and no
application reconfiguration is required for hosts addressed
through stable identifiers rather than bare ASIP literals.
8.3.2. 8.3.2. Locator Rewriting
An AS border router MAY rewrite the r.r.r.r field of packets on
ingress or egress when the rewrite is a pure locator change (z, s, h
unchanged) and the mapping is published in WHOIS-ASIP (Section 8.4)
or equivalent. Locator rewriting is used for:
* Stateless IPv4/ASIP translation at AS boundaries (Section 12.2);
* ASN transfer renumbering (Section 8.3.1);
* Privacy rewriting of internal z.z.z.z and s.s.s.s as described in
Section 14.8.
Locator rewriting MUST NOT alter the transport-layer payload or
checksums in ways inconsistent with the translation rules of
Section 12. A router performing locator rewrite MUST enforce the AH-
rewrite prohibition defined in §5.3 ("Enforcement at rewriting
Hause Expires 18 October 2026 [Page 42]
Internet-Draft ASIP April 2026
nodes"): any inbound packet carrying an AH extension header (NH=51)
MUST be dropped with the ICMP-ASIP administratively-prohibited code
rather than silently rewritten. A router that rewrites AH-protected
traffic produces an ICV-failure symptom indistinguishable from an on-
path attack; the prohibition is normative in both §5.3 (from the
IPsec-interaction perspective) and here (from the rewrite-
implementation perspective), and the two statements are semantically
identical.
8.4. 8.4. WHOIS-ASIP Route Validation
eBGP-ASIP routers validate received route advertisements against
WHOIS-ASIP, a route-ownership registry. A route advertisement that
cannot be validated against a registered WHOIS-ASIP entry SHOULD NOT
be installed in the routing table.
WHOIS-ASIP is functionally similar to RPKI [RFC6480] but is scoped to
ASIP's locator model: the registry maps each r.r.r.r value (and any
legitimate more-specifics permitted by Section 8.3.1) to the ASN
authorized to originate it. Because the common case is one prefix
per ASN, the registry is substantially smaller than RPKI's prefix
space; the long tail of multihoming, anycast, and TE more-specifics
is registered explicitly.
*Normative status.* Route-ownership validation is a core guarantee of
this document (Section 2.4 R5). Accordingly:
* Deployments that rely on the structural routing-table bound or on
the "one route = one authorized origin" property MUST deploy
WHOIS-ASIP validation on all eBGP-ASIP sessions.
* Deployments willing to accept BGP4-equivalent route hygiene (no
route validation, hijacks and leaks possible) MAY defer WHOIS-ASIP
validation during transition. Such deployments MUST NOT claim the
structural routing-table bound.
The structural routing-table guarantee does not exist without route-
ownership validation: a deployment that accepts any eBGP-ASIP
advertisement from any peer inherits the same hijack, leak, and
bogon-injection pathology as BGP4, and no "one route = one authorized
origin" property can be claimed. The two tiers above bind R5's
REQUIRED/RECOMMENDED status to the property the deployment actually
relies on.
Hause Expires 18 October 2026 [Page 43]
Internet-Draft ASIP April 2026
*Chicken-and-egg.* As with RPKI, WHOIS-ASIP adoption provides
meaningful protection only when a critical mass of originating ASes
publish records. Early adopters SHOULD publish WHOIS-ASIP records
even when few peers validate them, and SHOULD default to log-only for
received advertisements that fail validation until peering partners
converge on enforcement. See Section 18.6.
*Bootstrap transport.* WHOIS-ASIP services MUST be reachable over
IPv4 during the transition period so that new ASNs can bootstrap
their ASIP routing locators without a pre-existing ASIP path. After
ASIP native reachability is established, WHOIS-ASIP services MAY be
reached over ASIP. This avoids the chicken-and-egg failure mode
where two new ASIP-native ASNs cannot discover each other's r.r.r.r
locator because the registry they depend on is itself only reachable
via ASIP.
*Response authentication.* WHOIS-ASIP responses MUST be
authenticated: the structural routing-table bound and the "one route
= one authorized origin" property both depend on a validator being
able to trust that the WHOIS-ASIP record it retrieved reflects the
registry's actual entry. A companion specification (draft-asip-
whois-00, out of scope for this document) is expected to define the
signature and trust-anchor model; an RPKI-style X.509 hierarchy
[RFC6480] is the working assumption. Until that specification is
published, eBGP-ASIP deployments relying on WHOIS-ASIP validation
MUST obtain records over an authenticated channel (e.g., TLS with
HPKP-equivalent pinning, or signed zone file distribution) and MUST
NOT accept unauthenticated WHOIS-ASIP responses as a basis for route
acceptance. Without authentication, an adversary in the IPv4
bootstrap path could inject forged locator-to-ASN bindings into a
validator's cache and defeat the entire route-validation chain.
*Service discovery.* WHOIS-ASIP service endpoints MUST be published
via DNS using the SRV record _whois-asip._tcp.{registry-domain} and
MUST be reachable at the IPv4 address(es) to which that SRV resolves.
Registry operators MUST publish their SRV records under at least one
well-known registry domain delegated by IANA (see §15.10). This
resolves the bootstrap-discovery gap: a new ASN needs only a working
IPv4 DNS resolver to locate its regional WHOIS-ASIP service; no pre-
existing ASIP path, hard-coded endpoint, or out-of-band configuration
is required.
Hause Expires 18 October 2026 [Page 44]
Internet-Draft ASIP April 2026
8.5. 8.5. iBGP-ASIP and OSPF-ASIP
iBGP-ASIP distributes external routes within an AS. OSPF-ASIP
extends OSPFv2 with 128-bit address support. Both are specified
fully in companion documents. iBGP-ASIP and OSPF-ASIP conformance
does not require CF awareness; where an operator deploys the OPTIONAL
CF attribute of §17's companion draft, iBGP-ASIP MAY carry it
transparently across the AS. Neither iBGP-ASIP nor OSPF-ASIP defines
CF behavior in this document.
Neither is mandatory. An operator running a single-zone AS may use
OSPF-ASIP alone. An operator running a flat network may use static
routes alone with ASIP addressing. The protocol does not prescribe
internal network architecture.
9. 9. ICMP-ASIP
ICMP-ASIP extends ICMP [RFC792] to support 128-bit addresses,
incorporating the Neighbor Discovery functions from IPv6's ICMPv6
[RFC4443]. ICMP-ASIP is identified by Next Header value 143 (to be
assigned by IANA; see Section 15.5). Both ICMPv4 and ICMP-ASIP MUST
be supported simultaneously by ASIP implementations.
*Why not NH=58.* ICMP-ASIP MUST NOT reuse IPv6's ICMPv6 Next-Header
value (58). Reuse would create a dispatcher ambiguity: a middlebox
that strips or normalizes the outer ASIP header while preserving the
NH chain would deliver the inner payload to an ICMPv6 handler that
expects 128-bit ICMPv6 semantics, not ICMP-ASIP. Because the
message-type registries, Neighbor Discovery option codes, and
checksum pseudo-headers differ between ICMPv6 and ICMP-ASIP, the
collision would silently produce wrong behavior rather than a clean
error. A distinct Next-Header value (requested value 143, subject to
IANA assignment) eliminates the ambiguity.
9.1. 9.1. Core Messages
ICMP-ASIP carries full 128-bit addresses in Echo Request/Reply,
Destination Unreachable, Time Exceeded, Redirect, Packet Too Big, and
Parameter Problem messages. Path MTU Discovery is extended for the
ASIP header.
The initial ICMP-ASIP Type values used normatively elsewhere in this
document (§12.7, §12.8) are listed here for implementer convenience;
the full registry is established per §15.5 and follows ICMPv6
[RFC4443] numbering unless otherwise noted:
Hause Expires 18 October 2026 [Page 45]
Internet-Draft ASIP April 2026
+=========+============================+============================+
| Type | Name | Normative use in this |
| | | spec |
+=========+============================+============================+
| 1 | Destination Unreachable | §12.7.3, §12.7.7, §5.3 |
| | | (AH-rewrite drop) |
+---------+----------------------------+----------------------------+
| 2 | Packet Too Big | §12.7.4, §12.8 (PMTUD) |
+---------+----------------------------+----------------------------+
| 3 | Time Exceeded | Hop Limit = 0 drop |
+---------+----------------------------+----------------------------+
| 4 | Parameter Problem | Header malformed |
+---------+----------------------------+----------------------------+
| 128 | Echo Request | §12.7.2 |
+---------+----------------------------+----------------------------+
| 129 | Echo Reply | §12.7.2 |
+---------+----------------------------+----------------------------+
| 133-137 | Router/Neighbor Discovery | §9.2, §3.14 |
| | (RS, RA, NS, NA, Redirect) | |
+---------+----------------------------+----------------------------+
Table 12
Values not listed above follow the ICMPv6 registry [RFC4443] until
§15.5's IANA action establishes a distinct ICMP-ASIP registry.
9.2. 9.2. Neighbor Discovery
ASIP adopts IPv6's Neighbor Discovery Protocol (NDP) [RFC4861] in
full, adapted for the four-field address format. NDP replaces ARP
for ASIP-native address resolution, providing:
* *Router Solicitation / Router Advertisement (RS/RA):* Used by
hosts to discover routers and obtain network prefixes for SLAAC-
ASIP (Section 3.14). RAs carry the 96-bit prefix (r:z:s), the M
flag (managed addressing via DHCP-ASIP), the A flag (autonomous
SLAAC-ASIP permitted), and prefix lifetime.
* *Neighbor Solicitation / Neighbor Advertisement (NS/NA):* Used for
address resolution (replacing ARP), Duplicate Address Detection
(DAD), and neighbor unreachability detection. All NS/NA messages
use link-local source addresses (169.254.0.0::h.h.h.h).
* *Redirect:* Used by routers to inform hosts of a better first-hop
router for a destination.
Hause Expires 18 October 2026 [Page 46]
Internet-Draft ASIP April 2026
NDP messages are sent to solicited-node multicast addresses derived
from the target's h.h.h.h field. The solicited-node group is formed
from the low 24 bits of h.h.h.h, mirroring IPv6's 24-bit L2-multicast
form (IEEE 802.3 33:33:xx:xx:xx:xx for Ethernet). Collisions on the
high 8 bits of h.h.h.h cause two ASIP hosts to share a solicited-node
group; the NA reply carries the full 32-bit h.h.h.h and the requester
discriminates at L3.
*Collision-rate difference versus IPv6.* Because ASIP's h.h.h.h is 32
bits rather than IPv6's 64-bit interface identifier, only 8 bits of
the host field are elided into the solicited-node group (versus 40
bits elided in IPv6). Both protocols use 24 bits of the host/IID to
form the solicited-node group, so both partition into 2^24 groups;
under uniformly-random SLAAC host IDs, the expected number of other
hosts sharing a given host's group is (N-1) / 2^24 for both ASIP and
IPv6, where N is the subnet's host count. At N=1000 this is
approximately 6×10^-5 on both protocols; at N=10,000 approximately
6×10^-4; at N=1,000,000 approximately 0.06. The solicited-node
collision rate is therefore not materially worse on ASIP than on IPv6
at realistic subnet sizes. The 32-bit host field's distinct
collision concern is the full-identifier birthday collision (two
hosts drawing the same h.h.h.h value); that concern is covered
quantitatively in §3.14.3 and addressed by §3.14.3's DHCP-ASIP-at-10k
threshold. The solicited-node-group concern and the full-identifier
concern are separate collision mechanisms operating at different
layers (L3 group membership vs. L3 uniqueness) and MUST NOT be
conflated: the group-level collision is negligible at realistic
subnet sizes, while the identifier-level collision becomes material
at N~10,000 and above.
9.3. 9.3. ARP-ASIP Compatibility
For backward compatibility on mixed IPv4/ASIP L2 segments, an ARP-
style resolution mechanism for 128-bit addresses (provisionally "ARP-
ASIP") MAY be supported as a fallback. On pure ASIP links, NDP
(§9.2) is the specified mechanism and MUST be used. An ASIP link on
which neither NDP nor a specified ARP-ASIP is available is a
misconfiguration; this document does not define ARP-ASIP wire format,
and a companion specification would be required before ARP-ASIP is
interoperable. ASIP-only deployments that depend on ARP-ASIP before
such a companion document is published are NOT INTEROPERABLE and
SHOULD NOT be built; operators needing L2 resolution on ASIP MUST
deploy NDP per §9.2.
10. 10. Multicast
Hause Expires 18 October 2026 [Page 47]
Internet-Draft ASIP April 2026
10.1. 10.1. Scoped Multicast Model
ASIP adopts IPv6's scoped multicast architecture [RFC4291, RFC7346],
adapted to the four-field address structure. Multicast scope
determines how far a multicast packet is forwarded and is encoded
directly in the address.
ASIP multicast uses the low-order 4 bits of the z.z.z.z field to
encode scope (values 0-15), mirroring the IPv6 multicast scope field
[RFC7346]. The remaining 28 bits of z.z.z.z MUST be zero for scoped
multicast (r.r.r.r = 255.255.255.0/24). Packets received with non-
zero values in those 28 bits MUST be dropped at ingress (not merely
ignored by receivers), because forwarding a packet whose reserved
bits are non-zero would create a covert-channel and scope-bypass
surface that a future assignment of those bits may not resolve
safely.
Hause Expires 18 October 2026 [Page 48]
Internet-Draft ASIP April 2026
+============+====================+==========================+
| z.z.z.z | Scope | Boundary |
| Low Nibble | | |
+============+====================+==========================+
| 0x0 | Reserved | MUST NOT be used |
+------------+--------------------+--------------------------+
| 0x1 | Interface-local | Never leaves the |
| | | originating interface |
+------------+--------------------+--------------------------+
| 0x2 | Link-local | Single physical/virtual |
| | | link |
+------------+--------------------+--------------------------+
| 0x3 | Reserved | MUST NOT be used |
+------------+--------------------+--------------------------+
| 0x4 | Admin-local | Administratively defined |
| | | (site, building) |
+------------+--------------------+--------------------------+
| 0x5 | Site-local | Single site / campus |
+------------+--------------------+--------------------------+
| 0x6-0x7 | Unassigned | Reserved for future |
| | | scope levels |
+------------+--------------------+--------------------------+
| 0x8 | Organization-local | Single AS / organization |
+------------+--------------------+--------------------------+
| 0x9-0xD | Unassigned | Reserved for future |
| | | scope levels |
+------------+--------------------+--------------------------+
| 0xE | Global | Entire terrestrial |
| | | internet |
+------------+--------------------+--------------------------+
| 0xF | Reserved | MUST NOT be used |
+------------+--------------------+--------------------------+
Table 13
Routers MUST NOT forward a scoped multicast packet beyond its
indicated scope boundary. Routers MUST drop scoped multicast packets
whose z.z.z.z low nibble is a Reserved or Unassigned value, and
SHOULD log the event. This is a hard enforcement, not a suggestion.
10.2. 10.2. Intra-ASN Multicast (IPv4 Compatible)
Packets with r.r.r.r = 0.0.0.0 (all upper fields zero) and h.h.h.h in
the IPv4 multicast range (224.0.0.0/4) are treated as intra-ASN
multicast and MUST NOT be forwarded beyond the local AS boundary.
This preserves full compatibility with existing IPv4 multicast
deployments.
Hause Expires 18 October 2026 [Page 49]
Internet-Draft ASIP April 2026
10.3. 10.3. Cross-ASN Multicast
Cross-ASN multicast uses r.r.r.r values in the range 255.255.255.0
through 255.255.255.254. The single r.r.r.r value 255.255.255.255 is
reserved for broadcast (§11.2) and MUST NOT be used for multicast.
The z.z.z.z field encodes the scope. The s.s.s.s and h.h.h.h fields
identify the multicast group, providing a 64-bit group space within
each scope level and each r.r.r.r assignment.
255.255.255.0 : {scope} : {group-hi} : {group-lo}
10.4. 10.4. Well-Known Multicast Groups
The addresses below are the canonical well-known groups. They use
the general cross-ASN multicast r.r.r.r prefix 255.255.255.0 of §4.2
with IPv4-familiar group values in h.h.h.h, so that operators who
recognize 224.0.0.5 and 224.0.0.6 from IPv4 OSPF see the same values
here. The per-protocol r.r.r.r values 255.255.255.1 (OSPF-ASIP),
255.255.255.2 (eBGP-ASIP), and 255.255.255.3 (IS-IS-ASIP) in the §4.2
table are reserved for future per-protocol use (e.g., a protocol-
specific group-ID encoding that does not overlap the IPv4 224/4
values); an implementation MUST join the 255.255.255.0-prefixed
groups below to participate in the listed protocols, and a
255.255.255.1/2/3 address MUST NOT be used in place of the addresses
below until a companion specification defines those prefixes' group-
ID encoding.
255.255.255.0:0.0.0.2::224.0.0.1 All ASIP routers (link-local)
255.255.255.0:0.0.0.2::224.0.0.2 All ASIP Zone Servers (link-local)
255.255.255.0:0.0.0.2::224.0.0.5 OSPF-ASIP all routers (link-local)
255.255.255.0:0.0.0.2::224.0.0.6 OSPF-ASIP designated routers (link-
local) 255.255.255.0:0.0.0.8::224.0.0.10 iBGP-ASIP peer discovery
(organization-local) 255.255.255.0:0.0.0.14::224.0.0.1 All ASIP
routers (global)
10.5. 10.5. Multicast Listener Discovery
ASIP uses MLD-ASIP, adapted from IPv6's MLDv2 [RFC3810], for
multicast group membership management. MLD-ASIP operates over ICMP-
ASIP and uses link-local source addresses (169.254.0.0::h.h.h.h) for
all messages, identical to IPv6's requirement that MLD use link-local
sources. This ensures multicast membership management functions
before any global addressing is configured.
Hause Expires 18 October 2026 [Page 50]
Internet-Draft ASIP April 2026
10.6. 10.6. Composition of Multicast Scope with Realm and Mesh Scope
§10.1 defines a multicast scope nibble (link, subnet, admin, site,
org, global, …) drawn from IPv6 precedent. §4.1 defines an orthogonal
scope hierarchy including realm (§3.12) and mesh (§3.11). Neither
section states how the two compose. The rules below are NORMATIVE
for any router enforcing either scope:
1. *Scope = Interface-local or Link-local (0x1, 0x2).* Never cross
any boundary, including realm and mesh boundaries. Confined to
the originating link.
2. *Scope = Admin-local, Site-local, Organization-local (0x4, 0x5,
0x8).* Confined to the originating AS. MUST NOT cross an AS
boundary, MUST NOT cross a realm boundary, and MUST NOT cross a
mesh gateway. "Organization-local scope in realm A" does not
imply reachability in realm B even if the two realms share an
operator.
3. *Scope = Global (0xE).* Confined to the originating realm's
terrestrial scope (or, if originated in a non-terrestrial realm,
to that realm's internal global scope). "Global" is *realm-
local-global*, not universal. A multicast packet with scope=0xE
originating in realm A MUST NOT be forwarded into realm B by any
relay. No "universal-across-realms" multicast scope is currently
defined; the Universal row in §4.1's scope table is reserved for
a future inter-realm-multicast specification and has no encoding
today.
4. *Realm-boundary ingress rule.* A router that receives a multicast
packet on an interface it classifies as being at a realm boundary
(i.e., the packet's source r.r.r.r lies in a different realm from
the router's local realm) MUST drop the packet regardless of the
packet's multicast scope nibble. Realm boundaries are hard drops
for multicast; no multicast scope permits realm crossing in this
document.
5. *Mesh-boundary rule.* Multicast packets originated in a mesh
domain (§3.11) MUST NOT be forwarded out of the mesh by a mesh
gateway, regardless of scope nibble. Conversely, non-mesh
multicast MUST NOT be forwarded into a mesh domain by a mesh
gateway. If a use case requires a mesh to receive a copy of a
terrestrial multicast, the gateway MUST terminate the terrestrial
multicast and originate a new mesh-scoped multicast (application-
level relay), not forward natively.
Hause Expires 18 October 2026 [Page 51]
Internet-Draft ASIP April 2026
6. *Link-local unicast scope (§3.10) and multicast.* Link-local
multicast (nibble = 0x2) is the multicast analog of link-local
unicast. Both are bounded to the single link and are not
affected by realm or mesh boundaries because they never reach a
boundary node's forwarding plane.
*Interaction matrix (informative summary):*
+====================+============+=========+=========+==========+
| Multicast scope | Crosses | Crosses | Crosses | Crosses |
| | link? | AS? | realm? | mesh |
| | | | | gateway? |
+====================+============+=========+=========+==========+
| 0x0 Reserved | Drop | Drop | Drop | Drop |
+--------------------+------------+---------+---------+----------+
| 0x1 Interface- | No | No | No | No |
| local | | | | |
+--------------------+------------+---------+---------+----------+
| 0x2 Link-local | Intra-link | No | No | No |
| | only | | | |
+--------------------+------------+---------+---------+----------+
| 0x3 Reserved | Drop | Drop | Drop | Drop |
+--------------------+------------+---------+---------+----------+
| 0x4 Admin-local | Yes (admin | No | No | No |
| | scope) | | | |
+--------------------+------------+---------+---------+----------+
| 0x5 Site-local | Yes (site) | No | No | No |
+--------------------+------------+---------+---------+----------+
| 0x6-0x7 Unassigned | Drop | Drop | Drop | Drop |
+--------------------+------------+---------+---------+----------+
| 0x8 Organization- | Yes (AS) | No | No | No |
| local | | | | |
+--------------------+------------+---------+---------+----------+
| 0x9-0xD Unassigned | Drop | Drop | Drop | Drop |
+--------------------+------------+---------+---------+----------+
| 0xE Global | Yes | Yes | *No* | No |
+--------------------+------------+---------+---------+----------+
| 0xF Reserved | Drop | Drop | Drop | Drop |
+--------------------+------------+---------+---------+----------+
Table 14
Rule 4 is the load-bearing rule: no multicast packet crosses a realm
boundary natively in this document, regardless of scope nibble. §10.1
multicast scope and §4.1 realm scope are orthogonal dimensions, and a
packet may satisfy one scope test while violating the other; Rule 4
composes the two so that realm-boundary enforcement dominates every
multicast scope nibble and no combination admits a realm crossing.
Hause Expires 18 October 2026 [Page 52]
Internet-Draft ASIP April 2026
11. 11. Anycast and Broadcast
11.1. 11.1. Anycast
Anycast is a routing property, not a distinct address class. Two
anycast cases are supported:
* *Same-ASN anycast.* Multiple origin sites within the same ASN
advertise the same ASIP prefix. The inter-AS routing system
steers each packet to the nearest origin by normal BGP path
selection. This is the straightforward extension of IPv4 anycast.
* *Cross-ASN anycast.* An anycast service reachable from multiple
different ASNs (the current Cloudflare/Google model) is assigned
multiple ASIP addresses, one per origin ASN, and is published
under a single DNS-ASIP name with all its A-ASIP records. Clients
use normal DNS-ASIP resolution to obtain the candidate set; the
routing system steers each flow to the instance best-reached
through its chosen destination address. This preserves the
operational capability that BGP4 anycast delivers today.
The cross-ASN case is the reason Section 3.1 defines r.r.r.r as a
routing locator rather than a host identity. An anycast service host
is not "owned" by one ASN; it is reachable through several, each with
its own locator.
Ordering and selection among anycast instances uses standard BGP
path-selection criteria [RFC4271]. If an operator separately deploys
the OPTIONAL Cost Factor metric (§17 / draft-asip-cf-00), CF MAY
additionally influence anycast instance selection per that companion
draft; CF-based anycast selection is not required by this document.
11.2. 11.2. Broadcast
The r.r.r.r value 255.255.255.255 is permanently reserved for
broadcast and maps to the Layer 2 broadcast address. Broadcast
packets MUST NOT be routed beyond the local network segment.
*Note:* As with IPv6, ASIP RECOMMENDS using multicast with a scope no
broader than required instead of broadcast for most use cases.
Broadcast remains defined for IPv4 compatibility. Link-layer
resolution on ASIP-only segments uses NDP (§9.2); any ARP-style
fallback (§9.3) is undefined in this document and MUST NOT be assumed
interoperable.
Hause Expires 18 October 2026 [Page 53]
Internet-Draft ASIP April 2026
12. 12. Compatibility and Transition
12.1. 12.1. Deployment Model
ASIP is a new address family on the wire. An ASIP-aware end host
runs a network stack that originates Version=8 frames for ASIP
destinations. For IPv4-mapped destinations (Section 3.3) the stack
emits a Version=8 frame whose r=z=s=0 source and destination are
handled by a translator (Section 12.2); where no translator is
reachable, the host MAY fall back to emitting a native Version=4
frame on the same interface. That fallback is a dual-stack kernel
data path by any reasonable definition, and this document
acknowledges it as such. The single-stack property claimed by ASIP
is narrower and scoped explicitly: applications see one address
family (AF_ASIP), and sockets above the kernel are not duplicated per
version.
"Single-stack" in this document therefore refers to the socket API
surface exposed to applications, not to the kernel's forwarding
behavior. During transition, an ASIP-aware host's kernel will
process both IPv4 and ASIP frames, and forwarding elements in the
path will be IPv4-only, ASIP-aware, or both. That is unavoidable.
Networks that have not deployed ASIP continue to operate as pure IPv4
networks. They require no modification. They are also not reachable
by ASIP-native traffic except through the translation and
encapsulation mechanisms below.
12.2. 12.2. IPv4/ASIP Stateless Translation at AS Boundaries
ASIP-aware AS border routers MAY act as stateless translators between
Version=8 frames carrying IPv4-mapped addresses (r=z=s=0) and
Version=4 frames. The translation rules follow SIIT [RFC7915]
adapted for the ASIP address format:
* An ASIP-to-IPv4 translation strips the r=z=s=0 address prefix,
emitting an IPv4 packet with h.h.h.h as the IPv4 source/
destination.
* An IPv4-to-ASIP translation prepends r=z=s=0 on ingress, producing
a Version=8 frame whose addresses are IPv4-mapped.
* Transport checksums are recomputed per SIIT.
*Origin advertisement requirement (normative; see §14.1).* Operators
deploying this section's stateless translation MUST originate the
0.0.0.0::/96 IPv4-mapped prefix via eBGP-ASIP from the translator-
owning ASN, so that the §14.1 ingress filter at every downstream peer
Hause Expires 18 October 2026 [Page 54]
Internet-Draft ASIP April 2026
treats r=z=s=0 sourced traffic as originating from a legitimate peer
rather than as spoofed. Without this advertisement, reverse-
direction reply traffic (§12.7.1, common case) will be dropped at the
first non-translator-declared peering boundary. This is a deployment
requirement, not a wire-format requirement. This requirement binds
only to operators deploying §12.2 stateless translation; operators
deploying only §12.3 encapsulation (ASIP-to-IPv4 tunneling) MUST NOT
originate 0.0.0.0::/96, because they do not serve that prefix and
originating an unserved prefix is exactly the hijack pattern WHOIS-
ASIP (§8.4) rejects.
Translation is stateless in the data-plane forward direction: any
Version=8 frame with r=z=s=0 can be emitted as Version=4 using only
information from the packet itself. ICMP error translation and
reverse-path locator reconstruction require a stable mapping between
the IPv4 literal and the originating ASIP source's r.r.r.r value; see
§12.7.1 and §12.7.3 for the mechanisms. That mapping MAY be per-flow
state or an administratively configured static mapping; the forward-
direction translation itself remains stateless.
*h.h.h.h addressability constraint.* An ASIP source whose traffic is
stateless-translated to IPv4 emits IPv4 packets with Src = S8.h.h.h.h
(§12.7.1). Reply traffic from the IPv4 destination therefore targets
that h.h.h.h value as an IPv4 address on the public IPv4 internet.
For stateless §12.2 translation to work without a NAT44-style
rewrite, S8.h.h.h.h MUST be a globally routable IPv4 address owned by
the translator operator and reachable via the translator on the
return path. ASIP sources whose h.h.h.h falls in RFC 1918 private
space, CGN shared space (100.64.0.0/10), or any other non-publicly-
routable IPv4 range MUST either (i) be assigned a publicly-routable
h.h.h.h from a translator-owned IPv4 pool for egress, with the
translator performing h.h.h.h rewrite (stateful NAT44, as in §12.6
CGNAT behavior), or (ii) use §12.3 encapsulation instead of §12.2
translation. The constraint is load-bearing because the IPv4 return
path has no ASIP locator information and can only reach the h.h.h.h
literal; a non-publicly-routable h.h.h.h simply produces unreachable
return traffic.
*Path-asymmetric traffic and multihoming.* The h.h.h.h-ownership rule
above also constrains return-path routing for multihomed ASIP clients
(§8.3.1). Because reply traffic is addressed to the IPv4 h.h.h.h
that the forward-direction translator owns, and IPv4-side routing
steers that reply back to the translator that announced the h.h.h.h,
return traffic inherently lands at the same translator that created
the forward-direction mapping. A stateless translator at a different
ASN's border that receives an inbound IPv4 packet whose Dst is not in
its own translator-owned pool MUST silently drop the packet and MUST
NOT synthesize a forged ASIP source by guessing a reverse mapping.
Hause Expires 18 October 2026 [Page 55]
Internet-Draft ASIP April 2026
When an ASIP client deliberately switches outbound traffic from
ASN_A's translator to ASN_B's translator (e.g., uplink failover), the
client's ASIP source address changes (new h.h.h.h from ASN_B's pool,
per the rewrite or multihoming model); existing IPv4-side sessions
bound to the ASN_A h.h.h.h do not survive the switch and MUST be
reopened. Session-continuity mitigations are covered in §18.5b. The
translator's behavior is strictly "drop what you don't own, do not
fabricate": fabricating a reverse mapping would inject forged ASIP
source addresses into a downstream path and violate §14.1 ingress
filtering at every subsequent hop.
12.3. 12.3. ASIP-to-IPv4 Encapsulation Across IPv4 Transit
Where two ASIP-aware sites are separated by IPv4-only transit, they
MAY tunnel Version=8 frames inside Version=4 packets. The normative
encapsulation is GENEVE over UDP [RFC8926] using IANA-assigned port
6081, with ASIP frames carried as the inner protocol. An IANA-
assigned ASIP-to-IPv4 protocol type is requested for GENEVE's
protocol field (Section 15.9).
Rationale. GENEVE/UDP is the encapsulation of choice for modern
virtual networks (VXLAN, NVGRE are similar but older): it is
stateless, adds 16 bytes of UDP+GENEVE overhead on top of the outer
IPv4 header, is supported by commodity silicon, does not introduce
per-flow TCP congestion-control interactions between unrelated
tenants, and does not require a handshake before the first packet.
HTTPS (TCP/TLS) tunneling is NOT RECOMMENDED for general transit use:
TCP-over-TCP introduces nested congestion control and head-of-line
blocking across unrelated inner flows; TLS handshakes add round-trips
on every tunnel re-establishment; per-packet bytes above the inner L4
payload are ASIP(40)+IPv4(20)+TCP(20)+TLS(~29) = 109 rather than the
76 of GENEVE/UDP (ASIP(40)+IPv4(20)+UDP(8)+GENEVE(8)). HTTPS
tunneling is retained only as a last-resort traversal option (see
below).
Operators MAY use alternative encapsulation methods:
* *GRE or IP-in-IP* for high-throughput backbone links where UDP NAT
traversal is not a concern.
* *WireGuard or IPsec/ESP* where per-tunnel authentication and
encryption are required.
* *HTTPS as a last-resort traversal option* for environments that
block UDP and non-HTTPS TCP. HTTPS tunneling is NOT RECOMMENDED
for general transit use because of the overhead and congestion-
control pathology noted above. It is MAY, not SHOULD.
Hause Expires 18 October 2026 [Page 56]
Internet-Draft ASIP April 2026
The 8TO4-ENDPOINT eBGP-ASIP attribute carries the IPv4 tunnel
endpoint address automatically. Tunnel MTU and Path MTU Discovery
behave as defined in [RFC8926]; operators MUST account for the
encapsulation overhead when sizing MTU (see §12.8).
*GENEVE option TLVs.* This document defines no ASIP-specific GENEVE
option classes. ASIP-to-IPv4 encapsulation MUST use GENEVE with no
options in the baseline defined here; the 8-byte GENEVE header in
§12.8's overhead budget assumes zero options. Implementations that
receive ASIP-to-IPv4 GENEVE frames carrying unknown option TLVs MUST
process them per [RFC8926] §3.5 (critical-bit handling). Future ASIP
deployments that wish to define option TLVs (e.g., for per-flow
telemetry, inter-AS traffic-engineering hints) MUST do so in a
companion specification and MUST request an option class from IANA's
GENEVE registry; inline invention of TLVs by operators breaks interop
and is NOT RECOMMENDED.
*Tunnel endpoint authentication and reflection/amplification.* UDP-
based encapsulation on a well-known port is a reflection/
amplification surface if decapsulators accept packets from any outer
source. ASIP-to-IPv4 decapsulators MUST maintain a configured
allowlist of peer tunnel endpoint IPv4 addresses (learned via the
8TO4-ENDPOINT eBGP-ASIP attribute or administratively configured) and
MUST silently drop inbound GENEVE/UDP/6081 packets whose outer IPv4
source is not on that allowlist. Decapsulators MUST NOT emit ICMPv4
error messages in response to unauthorized outer sources (doing so
converts the decapsulator into a reflector). Decapsulators SHOULD
rate-limit per outer source. Where operators require cryptographic
endpoint authentication rather than source-address allowlisting
(e.g., when the outer IPv4 path is subject to spoofing), WireGuard or
IPsec/ESP MUST be used instead of bare GENEVE/UDP as noted above.
12.4. 12.4. Transition Value
Unlike IPv6, which offered no incremental benefit to early adopters
until a critical mass was reached, ASIP provides localized value at
each adoption phase. These are not "phases of global deployment";
each benefits the individual adopter.
* *ISP backbone adopter:* Reduced routing-table churn on the subset
of the table that is ASIP-native, assuming WHOIS-ASIP is deployed
(Section 8.4). Early adopters will not see a full 1M-entry table
reduction because they inherit a transit environment dominated by
IPv4 prefixes, and the BGP4 table their routers carry is
unaffected by a parallel ASIP table; the per-adopter benefit grows
with ASIP adoption across their peering set.
Hause Expires 18 October 2026 [Page 57]
Internet-Draft ASIP April 2026
* *Cloud providers:* ASN+Zone addressing eliminates VPC address
overlap within and across cooperating ASIP-aware tenants; cross-
region routing inside a cloud's own ASIP deployment is simpler
than the IPv4 overlay-on-overlay model.
* *Enterprise:* Internal zone addressing (127.x.x.x) enables multi-
region private networks without external address coordination or
RFC 1918 conflict management. This benefit is realized entirely
inside the enterprise and requires no upstream ASIP deployment.
* *Consumer ISPs:* For customers whose reachable destinations are
ASIP-native, CGNAT can be bypassed. For customers whose
destinations remain IPv4, CGNAT is unchanged.
Each role interoperates with non-upgraded peers via Section 12.2
translation and Section 12.3 encapsulation. There is no dependency
between roles. Organizations adopt at their own pace, but the claim
"each adopter benefits fully regardless of anyone else's deployment"
is too strong; the honest claim is that each adopter obtains
localized value and pays localized cost.
12.5. 12.5. IPv6 Coexistence
ASIP and IPv6 MAY coexist on the same infrastructure; neither
supersedes the other. An operator already running IPv6 MAY continue
to run it and adopt ASIP as a parallel address family, as a
replacement at the AS boundary, or not at all. ASIP does not claim
to be technically superior to IPv6; it offers an alternative
transition path whose costs and benefits differ. See Section 18.5
for a candid discussion.
12.6. 12.6. CGNAT Behavior
CGNAT devices that are not ASIP-aware are IPv4-only middleboxes and
operate unchanged on IPv4 traffic. They cannot process Version=8
frames. An ASIP-aware CGNAT MAY translate the h.h.h.h field of
IPv4-mapped ASIP addresses in the same way it translates IPv4 source
addresses today; it MUST NOT modify r.r.r.r, z.z.z.z, or s.s.s.s
during translation. CGNAT operators without a publicly registered
ASN MUST NOT originate non-mapped ASIP traffic onto the public
internet; they MAY use internal zone prefixes (Section 3.5) for
subscriber addressing and MUST translate at the AS boundary.
Hause Expires 18 October 2026 [Page 58]
Internet-Draft ASIP April 2026
12.7. 12.7. Stateless Translation Reference: Packet-Level Walkthrough
This subsection is NORMATIVE for implementations that perform IPv4/
ASIP stateless translation per §12.2. It supplements §12.2 by
specifying the byte-level behavior for the cases that translator
implementations most often get wrong: ICMP errors carrying truncated
inner headers, fragmented inner payloads, the IPv4 DF bit, and ICMPv4
Fragmentation Needed. Byte values are hexadecimal; offsets are zero-
based.
*Notation.* ASIP source S8 = ASN 0.0.59.65, zone 0, subnet 0, host
192.0.2.1 (compressed: 15169::192.0.2.1). IPv4 destination D4 =
198.51.100.1. IPv4-mapped ASIP destination D8m = ::198.51.100.1.
All checksums shown are illustrative placeholders denoted cksum;
implementations MUST compute them per [RFC7915] (transport) and per
the respective protocol (ICMP).
12.7.1. 12.7.1. Simple TCP Data Packet (ASIP -> IPv4)
Inbound to translator: Version=8 frame, 40-byte ASIP header + 20-byte
TCP header + 100-byte payload; S = 15169::192.0.2.1, D =
::198.51.100.1.
ASIP header fields on the wire (big-endian):
Offset Bytes Field 0x00 80 00 00 00 Version=8, TC=0, FlowLabel=0 0x04
00 78 06 40 PayloadLen=120, NH=6(TCP), HopLimit=64 0x08 00 00 3B 41
00 00 00 00 S.rrrr=0.0.59.65, S.zzzz=0.0.0.0 0x10 00 00 00 00 C0 00
02 01 S.ssss=0.0.0.0, S.hhhh=192.0.2.1 0x18 00 00 00 00 00 00 00 00
D.rrrr=0.0.0.0, D.zzzz=0.0.0.0 0x20 00 00 00 00 C6 33 64 01
D.ssss=0.0.0.0, D.hhhh=198.51.100.1 0x28 [TCP header 20 bytes] 0x3C
[payload 100 bytes]
After translation, the translator emits Version=4 frame:
Offset Bytes Field 0x00 45 00 00 8C V=4, IHL=5, ToS=0, TotLen=140
0x04 00 00 00 00 ID=0 (see note), Flags=0, FragOff=0 0x08 40 06 CC CC
TTL=64, Proto=6(TCP), HdrChecksum (CC CC = computed) 0x0C C0 00 02 01
Src=192.0.2.1 (h.h.h.h of S) 0x10 C6 33 64 01 Dst=198.51.100.1
(h.h.h.h of D) 0x14 [TCP header 20 bytes, checksum recomputed per RFC
7915] 0x28 [payload 100 bytes]
The r.r.r.r=0.0.59.65 source ASN locator is dropped because the
egress IPv4 network has no field to carry it. Reply traffic from D4
arrives at the translator as Version=4 with Src=198.51.100.1,
Dst=192.0.2.1, and is translated back to Version=8 with S8' =
::198.51.100.1, D8' = 15169::192.0.2.1. *The translator MUST maintain
sufficient state (or an administratively configured reverse mapping)
Hause Expires 18 October 2026 [Page 59]
Internet-Draft ASIP April 2026
to recover the original S8.r.r.r.r = 0.0.59.65 on the return path*;
without it, the reply is translated with S8'.r.r.r.r = 0 (the
IPv4-mapped form) and arrives at the original client under a
different source address than the one it sent to, breaking any per-
address state at the client. This state is implicit in the SIIT
[RFC7915] model when one side is IPv4-mapped; it is stated explicitly
here because the r.r.r.r locator has no IPv4 analog and a translator
that omits reverse-path reconstruction will produce source-address
mismatch on every reply.
*IPv4 ID field:* set to 0 when DF is off and the packet is not
fragmented. When DF is set (see §12.7.4) or fragmentation is needed,
the translator assigns a 16-bit ID per RFC 7915.
*ASIP pseudo-header for transport checksums.* TCP, UDP, and ICMP-ASIP
checksums over ASIP are computed using the IPv6 pseudo-header format
[RFC8200 §8.1] with the 128-bit ASIP Source and Destination Addresses
substituted verbatim for the IPv6 address fields, the 32-bit upper-
layer packet length, 24 zero bits, and the 8-bit upper-layer protocol
identifier (Next Header). The pseudo-header is never transmitted; it
is a checksum input only. Translator implementations performing
IPv4<->ASIP translation MUST recompute the transport checksum using
the IPv4 pseudo-header on the IPv4 side and the ASIP pseudo-header
above on the ASIP side; incremental update [RFC1624] is permitted
only when both pseudo-headers are fully known to the translator.
*TCP options.* TCP options (Timestamp, SACK-Permitted, MSS, Window
Scale, etc.) are part of the TCP header, not the IP layer. They pass
through IPv4<->ASIP translation byte-for-byte unchanged; only the TCP
checksum is recomputed. The MSS option value (if present on a SYN)
is end-host-visible: the translator MUST NOT rewrite it, but the ASIP
and IPv4 sides' PMTU discovery (§12.8, §12.7.4) jointly determine the
actual usable segment size, and an MSS advertised for a larger
IPv4-side MTU will be clamped by the normal PMTU path.
12.7.2. 12.7.2. ICMP-ASIP Echo Request -> ICMPv4 Echo Request
An ICMP-ASIP Echo Request (NH=143, Type=128) from 15169::192.0.2.1 to
::198.51.100.1 is translated to an ICMPv4 Echo Request (Proto=1,
Type=8). The identifier and sequence fields pass through unchanged;
the payload passes through unchanged; the ICMP checksum is
recomputed. Return direction reverses the type mapping (ICMPv4
Type=0 -> ICMP-ASIP Type=129).
*Return-path locator reconstruction.* The ICMPv4 Echo Reply arrives
at the translator with IPv4 Src = the original D4 and IPv4 Dst = the
h.h.h.h that was emitted as the IPv4 source on the forward Echo
Request. To deliver the reply back to the originating ASIP host with
Hause Expires 18 October 2026 [Page 60]
Internet-Draft ASIP April 2026
the full S8 = r:z:s:h preserved, the translator MUST apply the same
r.r.r.r reconstruction state or administrative-mapping rule specified
in §12.7.3 (forward direction is stateless; reverse direction
requires mapping). Because Echo flows are often short-lived (single
exchange) and high-volume (traceroute, PMTUD probes), translators
that maintain per-flow mapping state SHOULD use an Echo-specific
short timeout (RECOMMENDED: 60 seconds from the last forward Echo
Request) to bound state growth independently of longer TCP/UDP flow
state. See §14.15.
12.7.3. 12.7.3. ICMPv4 Destination Unreachable Carrying a Truncated
IPv4 Inner Header (-> ICMP-ASIP)
This is the translation case implementers most frequently get wrong.
An IPv4 router upstream of the translator emits ICMPv4 Type=3
(Destination Unreachable), which includes as its payload the first 28
bytes of the offending IPv4 packet (20-byte IPv4 header + 8 bytes of
the next protocol, per RFC 792 semantics and RFC 1812 minimum). When
this error arrives at the translator with inner Src=192.0.2.1 (the
IPv4 form of the ASIP originator), the translator MUST synthesize an
ICMP-ASIP error whose inner payload is a reconstructed ASIP header,
not a pass-through of the IPv4 header.
Inbound ICMPv4 (bytes after IPv4 outer header):
Offset Bytes Field 0x00 03 01 [cksum] 00 00 00 00 Type=3, Code=1(host
unreach), Unused 0x08 [inner IPv4 hdr 20 bytes: Src=192.0.2.1,
Dst=198.51.100.1, Proto=6] 0x1C [inner IPv4 first 8 bytes of TCP:
SrcPort, DstPort, SeqNum]
Outbound ICMP-ASIP (NH=143):
Offset Bytes Field 0x00 01 01 [cksum] 00 00 00 00 Type=1(Dst
Unreach), Code=1, Unused 0x08 [reconstructed inner ASIP hdr 40 bytes]
Version=8, PayloadLen=copied from original, NH=6(TCP),
HopLimit=copied, S.rrrr=0.0.59.65, S.zzzz=0, S.ssss=0,
S.hhhh=192.0.2.1 D.rrrr=0, D.zzzz=0, D.ssss=0, D.hhhh=198.51.100.1
0x30 [copied first 8 bytes of TCP: SrcPort, DstPort, SeqNum]
Hause Expires 18 October 2026 [Page 61]
Internet-Draft ASIP April 2026
*The inner ASIP header's S.rrrr field MUST be reconstructed* from the
translator's per-session state or administrative mapping (the
r.r.r.r=0.0.59.65 of the original ASIP source). If the translator
lacks that state, it emits S.rrrr=0 (IPv4-mapped form) and the
originating ASIP host's ICMP error-correlation will fail silently for
any packet where the host tracks error association by full 128-bit
source. The normative consequence is that *stateless translation is
stateless in the forward direction only*; ICMP error translation
requires either (i) per-flow ingress state or (ii) an
administratively stable source-locator mapping. Implementations MUST
document which approach they use.
The ICMPv4-to-ICMP-ASIP Type/Code mapping follows RFC 7915 §4 for the
common cases (Host Unreachable, Net Unreachable, Protocol
Unreachable, Port Unreachable, TTL Expired, Parameter Problem).
12.7.4. 12.7.4. ICMPv4 Type 3 Code 4 (Fragmentation Needed / DF Set)
-> ICMP-ASIP Packet Too Big
When the IPv4-side MTU cannot accommodate a translated packet whose
inner originator set the ASIP "atomic fragment" intent (analogous to
IPv4 DF), the translator converts the ICMPv4 Type=3 Code=4 error into
an ICMP-ASIP Packet Too Big message. Because ASIP-to-IPv4
translation shrinks the packet by 20 bytes (ASIP base header is 40
bytes; IPv4 minimum header is 20 bytes), an ASIP packet of size X
translates to an IPv4 packet of size X-20. To fit at the IPv4 next-
hop MTU M, the ASIP origin may send packets up to M+20 bytes. The
reported MTU to the ASIP originator is therefore IPv4_next_hop_MTU +
(ASIP_hdr - IPv4_hdr) = IPv4_next_hop_MTU + 20. This is consistent
with RFC 7915 §5.1 MTU handling and symmetric with the IPv4->ASIP
direction rule in §12.7.6 (which subtracts 20).
Worked example: IPv4-side link reports next-hop MTU = 1500.
Translator emits ICMP-ASIP Packet Too Big with MTU = 1520. The ASIP
originator caches MTU=1520 for the destination; a 1520-byte ASIP
packet becomes a 1500-byte IPv4 packet after translation and fits
exactly. Implementations MUST NOT report the unadjusted IPv4 MTU
(doing so causes a 20-byte per-packet efficiency loss) and MUST NOT
report IPv4_next_hop_MTU - 20 (doing so causes a 40-byte per-packet
loss and diverges from RFC 7915).
*Fragment-needed-on-fragmented-inner corner case.* If the ICMPv4
Type=3 Code=4 error arrives as a response to a translated ASIP packet
that was already a fragment (NH=44 fragment header present), the
translator emits ICMP-ASIP Packet Too Big and the originator MUST re-
fragment at the lower MTU at the source, not via intermediate-router
fragmentation (§5.2: ASIP fragments only at the source). This
preserves IPv6/ASIP fragmentation semantics.
Hause Expires 18 October 2026 [Page 62]
Internet-Draft ASIP April 2026
12.7.5. 12.7.5. Fragmented Inner Payload (-> IPv4)
An ASIP packet containing a Fragment Extension Header (NH=44)
translates to an IPv4 packet with Flags.MF and FragOff set from the
fragment header. The 32-bit fragment Identification in the ASIP
fragment header is truncated to 16 bits for the IPv4 ID field; the
low-order 16 bits are used. This is a lossy truncation but matches
RFC 7915 §5.1.1 behavior. *The translator MUST NOT perform
reassembly*; it forwards fragments as fragments. If the IPv4-side
link MTU cannot carry the translated fragment, ICMPv4 Type=3 Code=4
is returned upstream and handled per §12.7.4.
*Fragment-ID collision attack surface.* Two ASIP fragmented flows
whose 32-bit fragment IDs differ only in the upper 16 bits collapse
to the same 16-bit IPv4 ID after truncation. On the IPv4 side, a
reassembler may mis-associate fragments from the two flows, producing
a fragmentation-based injection or corruption surface analogous to
the RFC 7915 §5.1.1 caveat. Translators SHOULD assign the IPv4 ID
field by hashing (source address, destination address, fragment ID)
rather than by simple truncation when per-flow state is available, to
reduce collision probability; implementations that use simple low-
16-bit truncation MUST rate-limit the number of distinct fragmented
flows translated concurrently, or MUST refuse to translate fragments
above a configured flow-count threshold.
*IPv4 -> ASIP direction (fragments).* An IPv4 packet with Flags.MF=1
or FragOff!=0 arriving at the translator is a fragment of a larger
original datagram. The translator MUST perform per-fragment
translation without reassembly: each IPv4 fragment becomes an ASIP
packet carrying a Fragment Extension Header (NH=44) whose 32-bit
Identification is the zero-extended IPv4 16-bit ID (upper 16 bits set
to 0), whose M and FragOff fields mirror the IPv4 Flags.MF and
FragOff respectively, and whose payload is the fragmented upper-layer
bytes verbatim. Reassembly occurs only at the ASIP destination,
never at the translator. Fragments arriving out of order are
translated in arrival order and forwarded independently; the
translator MUST NOT buffer fragments waiting for earlier parts. This
preserves the "stateless in the forward direction" property of §12.2
and matches RFC 7915 §4.1 behavior.
12.7.6. 12.7.6. IPv4 DF Bit Handling (IPv4 -> ASIP)
When translating an IPv4 packet with DF=1 to ASIP, the translator:
* If the IPv4 packet fits in the ASIP-side MTU with added overhead,
forwards it as a single ASIP packet (no Fragment Extension
Header).
Hause Expires 18 October 2026 [Page 63]
Internet-Draft ASIP April 2026
* If the IPv4 packet does not fit, responds with ICMPv4 Type=3
Code=4 (Fragmentation Needed) to the IPv4 source with next-hop MTU
= ASIP_MTU - 20. The IPv4 source reduces its sending size.
When DF=0, the translator MAY fragment the IPv4 packet inline on the
IPv4 side before translation, or MAY translate-then-fragment on the
ASIP side with a Fragment Extension Header. Either is compliant;
implementations SHOULD prefer DF=1-respecting behavior for all IPv4
traffic because it matches modern IPv4-side deployment practice
(PMTUD relies on DF=1).
*Header-size delta with fragment extension header.* When the
translate-then-fragment path adds an ASIP Fragment Extension Header
(NH=44, 8 bytes), the IPv4->ASIP header delta is +28 bytes (ASIP
40-byte base + 8-byte frag ext, minus IPv4 20-byte header), not the
+20 bytes used elsewhere in §12.7. A translator that emits
fragmented ASIP output from a non-fragmented IPv4 input MUST account
for the additional 8 bytes of fragment-extension overhead when
deciding whether an output fragment will fit its ASIP-side MTU; the
PMTU-reported value on the ASIP side is reduced by 8 additional bytes
relative to the §12.7.4 +20 formula in this case. This is a
translator-local accounting concern; the ASIP originator sees only
the end-to-end PMTU and does not need separate knowledge of the
translator's fragment-ext decision.
12.7.7. 12.7.7. ICMP-ASIP Error Back to IPv4 Originator (Reverse
Direction)
When an IPv4 originator (S4 = 203.0.113.7) sends to an IPv4-mapped
ASIP destination that reaches an unreachable ASIP host via the
translator, the far-side ASIP router emits an ICMP-ASIP error (e.g.,
Type=1 Destination Unreachable) whose inner reconstructed header
shows S8 = ::203.0.113.7 (the translator's forward-direction
synthesis) and some non-zero destination. That ICMP-ASIP error
transits back toward the translator. The translator MUST synthesize
an ICMPv4 error whose inner header is a reconstructed IPv4 header
matching the packet S4 originally sent: inner Src = 203.0.113.7,
inner Dst = the IPv4 h.h.h.h that S4 originally used as the
destination. The outer ICMPv4 source address is the translator's
IPv4 address (standard ICMP-originating-router semantics). Without
this reverse synthesis, S4 receives an ICMP error referencing an IPv4
destination it never addressed, and IPv4-side error correlation
fails. The translation uses the same state or administrative-mapping
requirement as the forward ICMP path (§12.7.3): the translator must
recover the original IPv4 Dst from the ICMP-ASIP inner header's
D.hhhh field.
Hause Expires 18 October 2026 [Page 64]
Internet-Draft ASIP April 2026
12.7.8. 12.7.8. Port-Restricted Inner ICMP
Some firewalls drop ICMPv4 Destination Unreachable messages whose
inner TCP/UDP header indicates a port the firewall considers policy-
blocked. When the translator receives such an error, it has already
committed to forwarding the error back to the ASIP originator; the
translator MUST NOT apply secondary port filtering on the inner
payload of an ICMP error unless explicitly configured to do so.
Conversely, if the IPv4-side firewall drops the error, the ASIP
originator receives no feedback and its PMTU discovery or error
correlation stalls. This is a pre-existing operational pathology
inherited from IPv4; it is not created by ASIP and is not resolved
here. Operators SHOULD disable aggressive ICMP filtering on
translator-adjacent firewalls, identical to the advice given for IPv4
PMTUD.
12.8. 12.8. Path MTU Discovery and Encapsulation Budget
This subsection is NORMATIVE. ASIP PMTUD is semantically identical
to IPv6 PMTUD [RFC8201] extended for the ASIP-to-IPv4 encapsulation
of §12.3. Operators who deploy ASIP over non-upgraded IPv4 transit
MUST account for the overhead below, or applications will experience
silent truncation, black-holing, or PTB storms.
*Encapsulation overhead budget (single-level GENEVE/UDP/IPv4 over
Ethernet):*
Ethernet frame payload (L2 MTU) 1500 bytes - Ethernet header -14 -
Outer IPv4 header -20 - Outer UDP header -8 - GENEVE header (no
options) -8 - Inner ASIP base header -40
------------------------------------------------- Available for inner
L4 / application 1410 bytes
On a standard 1500-byte L2 link, an ASIP flow traversing ASIP-to-IPv4
encapsulation has a *1410-byte inner payload budget*, not 1500.
Applications and middleware that assume a 1500-byte MTU will emit
1500-byte inner packets; those packets will either be silently
truncated or trigger Packet Too Big storms, depending on the
encapsulator's policy.
*Jumbo-frame paths.* On end-to-end 9000-byte jumbo-frame paths, the
budget is 9000 - 14 - 20 - 8 - 8 - 40 = 8910 bytes inner payload.
Jumbo-frame paths are not universal; any path segment that does not
support jumbo frames reduces the budget to that segment's MTU.
Operators deploying ASIP-to-IPv4 across mixed-MTU paths MUST NOT
assume jumbo MTU end-to-end.
*Normative requirements:*
Hause Expires 18 October 2026 [Page 65]
Internet-Draft ASIP April 2026
* *(MUST)* ASIP-aware hosts MUST implement PMTUD per [RFC8201]: on
receipt of an ICMP-ASIP Packet Too Big (Type=2), the host MUST
cache the reported MTU per destination (and per source address,
see below) and MUST NOT emit packets larger than the cached MTU to
that destination until the cache entry expires.
* *(MUST)* ASIP-to-IPv4 encapsulators MUST set the outer IPv4 DF bit
so that intermediate IPv4-only links trigger ICMPv4 Type=3 Code=4
rather than silently fragmenting the outer IPv4 packet.
Translation of the ICMPv4 error back to ICMP-ASIP Packet Too Big
is specified in §12.7.4.
* *(MUST)* The ASIP minimum link MTU is 1280 bytes (identical to
IPv6's minimum per RFC 8200 §5). On receipt of an ICMP-ASIP
Packet Too Big whose reported MTU is less than 1280, the ASIP
originator MUST clamp the cached PMTU to 1280 for the affected
destination and MUST use a Fragment Extension Header (NH=44) to
carry larger application payloads in 1280-byte pieces.
Implementations MUST NOT set a cached PMTU below 1280 regardless
of the reported value, and MUST NOT emit ASIP packets smaller than
1280 bytes on the wire except as trailing fragments. The "< 48"
degenerate case (ASIP 40-byte base header + 8-byte minimum upper-
layer header) is equally covered by this rule.
* *(MUST, per-source-address cache)* Hosts that hold multiple ASIP
source addresses (multihoming, §8.3.1) MUST cache PMTU state keyed
by the tuple (source address, destination address), not by
destination alone. The forward path differs per source address
because r.r.r.r steers inter-AS forwarding; PMTU to the same
destination via two different locators MAY differ. Flushing the
cache only on destination change will cause PTB storms when the
host switches source addresses.
* *(SHOULD)* Encapsulating gateways SHOULD probe path MTU
proactively (e.g., using Packetization-Layer PMTUD per [RFC8899])
rather than waiting for the first ICMP Packet Too Big event in the
data flow.
* *(MAY)* Operators with strict application MTU requirements MAY
configure their ASIP-to-IPv4 transit to use GRE (-24 outer:
IPv4(20)+GRE(4)) or IP-in-IP (-20 outer: IPv4(20) only) instead of
GENEVE/UDP (-36 outer: IPv4(20)+UDP(8)+GENEVE(8)). IP-in-IP
recovers 16 bytes of inner payload per packet versus GENEVE/UDP at
the cost of losing UDP-based NAT traversal and per-flow port
entropy for ECMP hashing. The choice is a trade-off between
payload efficiency and outer-transport properties.
Hause Expires 18 October 2026 [Page 66]
Internet-Draft ASIP April 2026
*Deliberate non-resolution: outer PMTU vs. inner PMTU.* When an ASIP-
to-IPv4 tunnel reports a path MTU via ICMPv4 on the outer path, the
encapsulator MUST translate that to an ICMP-ASIP Packet Too Big on
the inner flow (§12.7.4). When an ICMP-ASIP Packet Too Big is
received on the inner flow from beyond the decapsulator, the
encapsulator MUST NOT re-generate an ICMPv4 error on the outer path;
the inner error is propagated to the inner originator directly. This
is the standard IP-in-IP tunneling behavior [RFC4459] and is restated
here because translation-plus-encapsulation paths combine both
semantics.
13. 13. Application Compatibility
13.1. 13.1. Legacy Applications
Existing IPv4 applications require no modification. The ASIP socket
compatibility layer intercepts standard BSD socket calls (AF_INET,
connect(), bind(), etc.) and transparently manages the upper 96 bits
via DNS-ASIP resolution and routing table state. The application
never sees an ASIP address.
13.2. 13.2. New Applications
Applications that wish to leverage ASIP addressing directly MAY use
the AF_ASIP address family and sockaddr_asip structure defined in
Section 5.5. Libraries SHOULD provide helper functions for
converting between ASIP canonical/compressed notation strings and
sockaddr_asip structures.
13.3. 13.3. URL and URI Representation
ASIP addresses in URLs use canonical or compressed notation enclosed
in brackets, consistent with IPv6 convention [RFC3986]:
https://[15169:0.0.0.1:0.0.0.10:192.0.2.1]:443/path (full, no
compression needed) https://[15169::192.0.2.1]:443/path (flat
network, compressed) https://[::8.8.8.8]:443/path (IPv4 compatible,
compressed) https://[64496::10.0.0.1]:8080/api (documentation ASN,
compressed)
Parsers MUST handle both compressed and uncompressed forms within
brackets. The host field h.h.h.h is always present per Section 6.3
Rule 5, which prevents ambiguity with bare IPv4 addresses in URLs.
14. 14. Security Considerations
Hause Expires 18 October 2026 [Page 67]
Internet-Draft ASIP April 2026
14.1. 14.1. ASN Locator Spoofing
ASIP border routers MUST implement ingress filtering validating that
the source r.r.r.r of received packets is a legitimate origin for the
eBGP-ASIP session over which the packet arrived. The legitimate-
origin set is the union of the peer's own ASN locators and any ASN
locators the peer has validly announced (including multihoming and
anycast more-specifics per Section 8.3.1).
This is consistent with BCP 38 [RFC2827]. Because the locator is
carried in the address rather than inferred from prefix ownership,
the check is a direct field match rather than a lookup. Note that
the check validates the locator, not the host identity: an operator
who rewrites r.r.r.r at an internal boundary (Section 8.3.2) MUST
ensure that the rewritten locator still passes the ingress-filter
check at the next external boundary.
*IPv4-mapped source (r=z=s=0) handling at ingress.* An incoming
Version=8 frame with source r.r.r.r=0 is by definition a packet
emitted (or re-emitted) by a §12.2 translator: either (a) IPv4-to-
ASIP forward, where the translator prepended r=z=s=0 on ingress, or
(b) IPv4-to-ASIP reply to a native ASIP client, where the IPv4 source
gets lifted to ::S4 (§12.7.1 reverse direction, the common case of
every reply from an IPv4 destination to an ASIP-native originator).
Both cases produce legitimate downstream traffic whose source locator
is 0.0.0.0. The filter below treats them uniformly. A border router
MUST accept r=z=s=0 sourced Version=8 frames on an interface if and
only if *both* of the following hold: (i) the peer's legitimate-
origin set on that eBGP-ASIP session (or administratively configured
adjacency) contains the 0.0.0.0::/96 IPv4-mapped prefix; and (ii) the
receiving interface satisfies a uRPF-style reception check for
0.0.0.0::/96 in the sense of [RFC3704]. Condition (ii) prevents the
one-bit-flip attack in which a transit peer that merely re-advertises
0.0.0.0::/96 thereby unlocks blanket acceptance of r=z=s=0 source
packets across _all_ its customer-facing ingress without applying BCP
38 to its own customers; condition (ii) restricts acceptance to
interfaces consistent with the route for the IPv4-mapped prefix.
Transit ASes that re-advertise 0.0.0.0::/96 MUST themselves apply
§14.14's intra-AS BCP 38 rule on their customer-facing ingress, so
that a downstream customer cannot spoof r=z=s=0 into a transit AS
that is itself trusted by its upstream peers. Carriage of the
0.0.0.0::/96 prefix is expected to be propagated by normal eBGP-ASIP
advertisement from the translator-owning ASN outward, exactly as any
other originated prefix; transit ASes re-advertise it and MUST
include it in the outbound legitimate-origin set they present to
their own downstream peers. A receiving border router that is a
transit hop several ASNs away from the originating translator will
therefore see 0.0.0.0::/96 in its upstream peer's advertised set and,
Hause Expires 18 October 2026 [Page 68]
Internet-Draft ASIP April 2026
provided the packet arrives on the interface associated with that
upstream route (uRPF condition (ii)), will correctly accept r=z=s=0
reply traffic. This preserves the §12.7.1 reverse-direction reply
path across arbitrary-length multi-AS transit.
*uRPF mode selection (normative).* Condition (ii) admits two modes
from [RFC3704]: strict (packet accepted only if the best-path route
for 0.0.0.0::/96 in the router's RIB points out the same interface on
which the packet arrived) and feasible-path/loose (packet accepted if
any route for 0.0.0.0::/96 exists via the receiving interface,
whether or not best-path; loose mode accepts if any route exists in
the RIB at all, regardless of interface). Leaving the mode
unspecified would produce implementation divergence: one vendor
strict-mode-drops legitimate asymmetric reply traffic, while another
vendor loose-mode-accepts exactly the one-bit-flip pattern condition
(ii) was written to block. Accordingly: - On single-homed edge eBGP-
ASIP interfaces facing stub customers or transit-free peers, routers
MUST apply strict-mode uRPF for 0.0.0.0::/96; strict mode is the mode
that actually closes the one-bit-flip gap. - On multihomed-customer-
facing interfaces and on transit/core interfaces where asymmetric
return paths are expected (e.g., a customer multihomed to two
upstreams advertising via primary but receiving replies via backup),
routers MUST apply feasible-path uRPF per [RFC3704] §2.2 (packet
accepted if the receiving interface is _any_ reverse path for
0.0.0.0::/96 in the RIB, not only the best path). Feasible-path uRPF
tolerates legitimate asymmetry while still requiring a per-interface
route association, which continues to block the one-bit-flip attack
from an interface that has no 0.0.0.0::/96 route at all. - Loose-mode
uRPF (the "any route anywhere" variant) MUST NOT be used for
0.0.0.0::/96 reception on any eBGP-ASIP interface; loose mode
degenerates condition (ii) into condition (i) and reintroduces the
one-bit-flip acceptance gap that condition (ii) was written to block.
- During a transient RIB state where 0.0.0.0::/96 is absent (BGP
flap, session reset), condition (ii) will fail and legitimate r=z=s=0
replies will be dropped for the duration of the absence. This is the
same transient-drop behavior that RFC 3704 uRPF applies to IPv4 BCP
38 and is accepted as a standard operational cost; operators SHOULD
minimize 0.0.0.0::/96 churn by configuring the prefix with eBGP-ASIP
dampening disabled and with a stable originator. The mode selection
above is enforceable at configuration time: the operator knows which
of its interfaces are single-homed-edge vs. multihomed/transit, and
per-interface mode configuration is standard in every eBGP-ASIP-
capable router. An implementation that cannot determine the correct
mode per-interface MUST default to strict mode and reject r=z=s=0
traffic on any interface where strict uRPF fails; this is the safe
default. On any eBGP-ASIP session whose legitimate-origin set does
NOT contain 0.0.0.0::/96, or where the uRPF reception check fails,
packets with r=z=s=0 source MUST be dropped: the all-zero locator is
Hause Expires 18 October 2026 [Page 69]
Internet-Draft ASIP April 2026
not a valid origin for a peer that has not propagated the IPv4-mapped
originator prefix, and an attacker on such a link cannot bypass the
§14.1 locator-match filter by forging r=z=s=0 (which would otherwise
evade the filter because no non-zero ASN is present to compare
against). Operators who deploy stateless §12.2 translation at their
AS boundary MUST originate the 0.0.0.0::/96 prefix via eBGP-ASIP so
that downstream reply traffic flows are not black-holed by peer
ingress filters; a translator deployment that silently serves §12.2
without this advertisement will see its reverse-direction replies
dropped at the first non-translator-declared boundary. Operators
deploying only §12.3 encapsulation (ASIP-to-IPv4 tunneling) without
§12.2 translation MUST NOT originate 0.0.0.0::/96, because they do
not serve that prefix; originating a prefix one does not serve is a
hijack pattern WHOIS-ASIP (§8.4) is specifically designed to reject.
14.2. 14.2. Internal Zone Prefix Protection
The 127.x.x.x internal zone prefix MUST NOT appear on WAN interfaces.
Border routers MUST drop packets with 127.x.x.x as source or
destination r.r.r.r on external interfaces and SHOULD log each
violation.
14.3. 14.3. RINE Prefix Protection
The 100.x.x.x RINE prefix MUST NOT appear in eBGP-ASIP advertisements
or on non-peering interfaces. Border routers MUST filter these
prefixes and SHOULD log violations.
14.4. 14.4. Interior Link Convention Protection
Border routers MUST filter received eBGP-ASIP route advertisements
whose announced reachability would treat the 222.0.0.0/8 h.h.h.h
range as an externally routable interior-link address. This is a
control-plane filter applied to route advertisements only.
Border routers MUST NOT filter data-plane packets based solely on the
h.h.h.h value being in 222.0.0.0/8. The h.h.h.h field is locally
significant and other ASes may legitimately use any h.h.h.h value for
any purpose. Per Section 3.8, route-advertisement filtering and
data-plane filtering are distinct and MUST NOT be conflated.
14.5. 14.5. RFC 1918 Address Privacy
RFC 1918 private addresses in h.h.h.h remain non-routable on the
public internet, consistent with IPv4 behavior.
Hause Expires 18 October 2026 [Page 70]
Internet-Draft ASIP April 2026
14.6. 14.6. Prefix Granularity Enforcement
*More-specifics than /32 in r.r.r.r.* Prefixes more specific than /32
in the r.r.r.r field subdivide a single ASN locator's address space
across multiple route advertisements. Such announcements SHOULD NOT
be accepted at external eBGP-ASIP boundaries. They MAY be accepted
when they are explicitly listed in the originating ASN's WHOIS-ASIP
record (Section 8.4) as legitimate multihoming, anycast, or TE more-
specifics (Section 8.3.1). A blanket "no deaggregation ever" rule
would force operators to split into additional ASNs to achieve the
same traffic-engineering granularity, which grows the locator count
and does not shrink the table; the WHOIS-ASIP-authorized-more-
specifics model supports the real use cases BGP4 already supports
without this perverse incentive.
*Less-specifics than /32 in r.r.r.r.* Aggregation covering multiple
ASN locators (less specific than /32) MAY be performed for internal
backbone routing but MUST NOT be advertised across peering
boundaries, because such an aggregate obscures the per-ASN origin
that WHOIS-ASIP validation depends on.
This resolves the tension between §8.3 aggregation-to-/16 and the
"one route = one ASN" property: aggregation is a routing-table
optimization internal to an operator, not a peering-advertisement
practice.
14.7. 14.7. Header Overhead and DDoS
The 40-byte ASIP header is 20 bytes larger than IPv4's minimum header
and identical in size to IPv6. In volumetric DDoS scenarios, this
increases per-packet overhead for both attacker and defender. The
net effect is approximately equivalent; the additional header bytes
do not create a meaningful amplification vector. Rate limiting and
traffic scrubbing operate identically to IPv4 and IPv6 at the
transport layer.
14.8. 14.8. Privacy Considerations
The r.r.r.r field reveals the origin ASN of every packet. This is
functionally equivalent to existing BGP prefix-to-AS mapping via
whois lookups, but encoded directly in the address rather than
requiring a secondary lookup. Operators concerned about origin AS
privacy at the packet level may use VPN or tunnel encapsulation to
mask the outer ASIP header, identical to existing practice with IPv4/
IPv6.
Hause Expires 18 October 2026 [Page 71]
Internet-Draft ASIP April 2026
The z.z.z.z and s.s.s.s fields reveal internal network topology to
external observers. Operators who consider this unacceptable SHOULD
use XLATE-ASIP (address translation) at their AS boundary to replace
internal z.z.z.z and s.s.s.s values with a public-facing address
before packets exit the AS. This is recommended for all operators as
a baseline privacy practice.
14.9. 14.9. SLAAC-ASIP Security
SLAAC-ASIP inherits the security properties and risks of IPv6 SLAAC
[RFC4862]:
* *Rogue Router Advertisements:* A malicious device on a link may
send forged Router Advertisements containing incorrect prefixes,
redirecting traffic or causing denial of service. RA Guard
[RFC6105] adapted for ASIP SHOULD be deployed on all access
switches.
* *DAD Attacks:* An attacker may respond to every DAD probe,
preventing legitimate devices from configuring addresses. This is
mitigated by limiting DAD attempts and falling back to DHCP-ASIP.
* *Host ID Tracking:* MAC-derived host identifiers (SLAAC-ASIP
Method 3) enable device tracking across networks. Implementations
SHOULD default to Method 1 (stable opaque) or Method 2 (temporary
random) to prevent this.
* *Temporary Address Rotation:* Method 2 temporary addresses SHOULD
be regenerated on a configurable interval (default 24 hours) and
MUST be regenerated when moving between networks.
14.10. 14.10. Link-Local Scope Enforcement
Link-local addresses (169.254.0.0/16 in r.r.r.r) MUST NOT be
forwarded by any router under any circumstances. Routers MUST
silently drop packets with link-local source or destination addresses
received on any interface other than the originating link. This
enforcement prevents link-local addresses from being used as a side
channel to bypass scope boundaries.
14.11. 14.11. Scope Boundary Enforcement
Each scope level (Section 4.1) represents a security boundary.
Routers at scope boundaries MUST enforce the containment hierarchy:
* Link-local traffic MUST NOT exit the link.
Hause Expires 18 October 2026 [Page 72]
Internet-Draft ASIP April 2026
* Mesh-scoped traffic MUST NOT exit the mesh domain. Conversely,
non-mesh traffic MUST NOT enter a mesh domain natively (§3.11; the
only sanctioned entry is a mesh-gateway-performed translation).
* Organization-scoped traffic (127.x.x.x) MUST NOT exit the AS.
* Terrestrial traffic MUST NOT be forwarded into a non-terrestrial
realm without explicit relay configuration. Conversely, a
terrestrial router receiving a packet whose source r.r.r.r lies in
a non-terrestrial realm range (97/8, 98/8, 99/8, 241/8–249/8,
250/8) on an interface that is not a configured realm-relay
ingress MUST drop the packet. A terrestrial router MUST NOT
accept such a packet on general peering links; realm-sourced
traffic is accepted only on a physical or cryptographic channel
configured as a realm-relay ingress. Without this ingress-side
restriction, an attacker in a terrestrial peer's path could spoof
a non-terrestrial source r.r.r.r and bypass realm-boundary
controls that §3.12 authorizes only at designated relay points.
* Cross-realm multicast is governed by §10.6; no multicast scope
crosses a realm boundary natively in this document.
Violation of scope boundaries MUST be dropped as specified above and
SHOULD be logged as a security event.
14.12. 14.12. Extension Header Security
ASIP reuses IPv6's extension header mechanism and therefore inherits
the same security considerations [RFC7045, RFC8200]. Implementations
MUST:
* Limit the number of extension headers per packet to at most 8
distinct headers and the total length of the extension-header
chain to at most 256 bytes. Packets exceeding either bound MUST
be dropped at the ingress node and SHOULD be counted. These
limits make the "long chain of extension headers" IDS-evasion
attack [RFC7112] ineffective while preserving realistic legitimate
use (at most one Hop-by-Hop, one Destination Options before
routing, one Routing, one Fragment, one AH or ESP, one Destination
Options after routing per RFC 8200 §4.1).
* Require the full ASIP header chain, through and including the
upper-layer protocol header, to be contained in the first fragment
of a fragmented packet. Packets that violate this requirement
MUST be dropped. This matches [RFC7112] and prevents first-
fragment-only inspection bypass.
Hause Expires 18 October 2026 [Page 73]
Internet-Draft ASIP April 2026
* Drop packets with unrecognized extension header types at
intermediate nodes (unless the header is a Destination Options
header, which is only processed at the final destination).
* Implement rate limiting on packets with Hop-by-Hop Options
headers, which require processing at every node.
14.13. 14.13. Flow Label Security
The flow label is source-assigned and opaque to the network. Routers
MUST NOT trust flow labels for security decisions. An attacker may
set arbitrary flow labels to manipulate ECMP distribution or QoS
classification. Flow labels SHOULD be used as hints for performance
optimization, never as security-relevant identifiers.
14.14. 14.14. STRIDE Summary
The preceding §§14.1-14.13 address individual threats. This
subsection consolidates coverage against the STRIDE categories
(Spoofing, Tampering, Repudiation, Information disclosure, Denial of
service, Elevation of privilege) so that gaps are visible in one
place. Normative statements in this subsection that are not already
covered elsewhere are load-bearing.
*Spoofing.*
* ASN-locator spoofing at peer ingress: covered normatively in
§14.1.
* Intra-AS source-address spoofing (a host on the internal side of
r.r.r.r faking a different z:s:h): NOT covered at the protocol
layer. Operators MUST deploy BCP 38-equivalent ingress filtering
on internal AS-access segments; this is a standard operational
control and is not specific to ASIP, but is named here so that
implementers do not assume §14.1's border-only filter suffices.
* DNS-ASIP response spoofing: mitigated by DNSSEC at the DNS layer;
ASIP imposes no additional requirements. A-ASIP records MUST be
served over DNSSEC-validated zones where the deploying operator
relies on A-ASIP-vs-A preference for policy decisions.
* WHOIS-ASIP response spoofing: covered normatively by §8.4
"Response authentication."
* ICMP-ASIP error-source spoofing: an on-path or off-path attacker
can forge an ICMP-ASIP Packet Too Big or Destination Unreachable
to poison a host's PMTU cache or abort a connection. Hosts MUST
validate that the inner header of an ICMP-ASIP error corresponds
Hause Expires 18 October 2026 [Page 74]
Internet-Draft ASIP April 2026
to a packet the host recently sent (source address, destination
address, and at least 8 bytes of upper-layer header, identical to
RFC 5927 guidance for ICMPv4); errors that do not match MUST be
discarded.
* NDP / RA spoofing on link-local: mitigated by RA Guard (§14.9) and
by NDP cache entry validation; no new normative text needed.
*Tampering.*
* In-transit modification of unprotected traffic: not addressable at
the IP layer; relies on upper-layer integrity (TLS, QUIC, AH,
ESP). §14 makes no additional claim.
* Extension-header chain tampering: bounded by §14.12 (max 8
headers, max 256 bytes, first-fragment inclusion).
* GENEVE option tampering: mitigated by §12.3's "no options in the
baseline" rule; future option-class additions MUST define their
own integrity story in the companion specification that introduces
them.
* Flow-label manipulation by intermediate nodes: forbidden by §5.4
("Routers MUST NOT … rewrite it in the forwarding path"); an on-
path tamperer can manipulate it, but doing so is classified as a
QoS/ECMP impact only and never a security-relevant change, per
§14.13.
*Repudiation.*
* Translator logging: §14.15 (below) requires an observable counter
of failed ICMP-error translations; operators SHOULD additionally
log stateful translation session establishment and teardown at
rates compatible with their incident-response workflow. This
document does not mandate a specific log schema.
* Locator-rewrite attribution gaps: when §8.3.2 rewrites r.r.r.r,
downstream logs show the rewritten locator, not the original.
Operators performing rewrite MUST retain a (timestamp, pre-
rewrite, post-rewrite, peer-session) audit record for the period
required by applicable policy; failing this, post-incident
attribution across a rewrite boundary is impossible.
* CF telemetry attribution: CF is specified in a separate companion
document (§17 / draft-asip-cf-00); attribution of CF values to
specific peers is a CF-companion concern and is not pinned down
here.
Hause Expires 18 October 2026 [Page 75]
Internet-Draft ASIP April 2026
*Information disclosure.*
* Flow-label as a side-channel: covered normatively in §14.13.
* Extension-header chain as a fingerprinting vector: a responder's
choice of extension-header ordering (AH vs. ESP placement,
presence of Destination Options) can identify the implementation.
Implementations SHOULD NOT emit optional extension headers that
are not required by the packet's function; this is an RFC 8200
best practice restated for ASIP.
* Translator state as a timing oracle: a per-flow translator that
differentiates response latency between "first packet of a flow"
(state creation) and "subsequent packets" (state hit) exposes an
observable that an attacker can use to probe another user's flow
existence. Translators SHOULD minimize the timing delta between
state-miss and state-hit, or SHOULD apply a constant-time pad to
external-facing response latency.
* Multicast-scope network-topology disclosure: a receiver that
observes which scope nibbles reach it learns the network's scope-
boundary topology. This is not a new threat class (IPv6 MLD has
the same property) and is accepted.
* Internal zone (127.x) address leakage: covered normatively in
§14.2. A packet with 127.x source arriving on a WAN interface is
a configuration error that leaks internal topology; the MUST-drop
rule in §14.2 prevents propagation.
*Denial of service.*
* Translator state exhaustion: covered in §14.15 (below).
* GENEVE reflection: covered in §12.3 "Tunnel endpoint
authentication and reflection/amplification."
* ICMP-ASIP amplification: ICMP-ASIP Echo Reply is 1:1 in size with
Echo Request and does NOT amplify on its own. However, ICMP-ASIP
Destination Unreachable messages whose inner payload is set to the
maximum permitted 1232-byte quotation ([RFC4443]-equivalent) do
amplify a small triggering packet to ~1232 bytes plus headers.
Routers emitting ICMP-ASIP errors MUST apply rate limits per
(source, destination) pair, as required of ICMPv6 routers by
[RFC4443] §2.4. Unsolicited Neighbor Advertisements and Router
Advertisements are link-scoped and do not amplify across routers.
Hause Expires 18 October 2026 [Page 76]
Internet-Draft ASIP April 2026
* SLAAC DAD storms: a malicious host that responds positively to
every DAD probe can starve a subnet. Mitigated by §3.14.3's
bounded-retry rule and DHCP-ASIP fallback, plus RA Guard per
§14.9.
* WHOIS-ASIP query amplification: WHOIS-ASIP responses can be
substantially larger than queries (especially for prefix-to-ASN
enumerations). WHOIS-ASIP servers MUST apply per-client rate
limits and MUST NOT answer unauthenticated bulk-enumeration
queries over UDP. The authenticated-channel requirement of §8.4
("Response authentication") restricts large-response queries to
TLS-authenticated clients.
* Flow-label-driven router-CPU exhaustion via ECMP hashing: flow
labels are source-assigned and an attacker can choose labels to
maximize cache-line contention in an ECMP hash-bucket table.
Routers SHOULD include a random per-router seed in ECMP hashing so
that an attacker cannot target a specific hash bucket without
knowing the seed.
*Elevation of privilege.*
* Multicast scope escape: covered by §10.6 composition rules and by
§14.11 scope-boundary enforcement.
* Realm-boundary escape: covered by §3.12 "Cross-realm
authentication" and by §14.11; supplemented by §10.6 rule 4 for
multicast.
* Internal-zone (127.x) addresses leaking externally: covered by
§14.2.
* eBGP-ASIP route injection by a non-authorized AS: covered by
§8.4's WHOIS-ASIP validation where deployed; where WHOIS-ASIP is
not enforced, operators accept BGP4-equivalent route hygiene (§8.4
"Normative status") and an injection remains possible, same as
today's BGP4.
14.15. 14.15. Translator State and ICMP Error Attribution
§12.7.1 and §12.7.3 require translators to maintain a mapping between
IPv4 literals and the originating ASIP source locator in order to
reconstruct ICMP errors and return-path source addresses. This
mapping is an attack surface:
Hause Expires 18 October 2026 [Page 77]
Internet-Draft ASIP April 2026
* *Memory exhaustion via ICMP flood.* If the mapping is per-flow
session state, an attacker can exhaust translator memory by
opening many short-lived flows and solicit ICMP errors that force
state allocation. Translators SHOULD bound per-session state,
apply LRU eviction, and log state-table pressure events.
* *Stale-mapping misattribution.* If the mapping is administrative/
static, a long-lived mapping entry can survive past the
originating ASIP host's address changes (locator transfer, ASN
renumbering). Misattributed ICMP errors are a low-severity
information leak but not a traffic-injection vector. Operators
SHOULD age out administrative mappings on ASN-transfer events.
* *Observability requirement.* Translators MUST expose a counter of
ICMP-error translations that failed for lack of mapping state; a
sudden increase in this counter indicates either an attack or a
misconfigured mapping and SHOULD be monitored.
* *Short-flow state lifetime.* Echo and single-probe flows (§12.7.2)
generate high-rate, low-value mapping entries that, if aged at the
same timeout as TCP/UDP flow state, amplify the memory-exhaustion
surface above. Translators that maintain per-flow mapping state
SHOULD apply a distinct short timeout (RECOMMENDED: 60 seconds) to
Echo/ping-class traffic and MAY apply the longer TCP/UDP default
only to flows carrying a transport connection. This caps Echo-
based state amplification without harming correlation of
legitimate traceroute and PMTU probes.
15. 15. IANA Considerations
15.1. 15.1. IP Version Number
IANA is requested to assign version number 8 in the IP Version Number
registry to ASIP (AS-Structured Internet Protocol), the 128-bit four-
field protocol specified in this document.
15.2. 15.2. Address Family
IANA is requested to assign:
* An Address Family Identifier (AFI) for ASIP in the Address Family
Numbers registry. This is the AFI that eBGP-ASIP (§8.3), iBGP-
ASIP, and any Multiprotocol BGP [RFC4760] usage MUST carry to
announce ASIP reachability.
* A Subsequent Address Family Identifier (SAFI) for ASIP unicast.
Hause Expires 18 October 2026 [Page 78]
Internet-Draft ASIP April 2026
* A Subsequent Address Family Identifier (SAFI) for ASIP multicast
(for MP-BGP carriage of the cross-ASN multicast prefixes defined
in §10.3 and §4.2).
eBGP-ASIP conformance (§8.3) requires the AFI/SAFI assignment to
exist before interoperable inter-AS ASIP routing can be deployed.
Until IANA has assigned these values, experimental deployments MAY
use a pair of Private Use AFI/SAFI values agreed between peers; such
deployments MUST NOT advertise prefixes over assigned-value peering
until the formal assignment is completed.
15.3. 15.3. Reserved ASN Ranges
IANA is requested to reserve the following ASN ranges for ASIP use.
Each /8 in r.r.r.r spans 2^24 = 16,777,216 ASN values; a /16 spans
2^16 = 65,536. Rows below that span a single /8 or /16 carry the
corresponding 2^24 or 2^16 Count; rows that span multiple /8 ranges
(241.0.0.0–249.255.255.255; 251.0.0.0–253.255.255.255) carry the sum,
and the partial-/8 row 255.0.0.0–255.255.254.255 excludes the 256
values reserved for cross-ASN multicast and broadcast per §15.6 and
§15.7:
+===============+=================+=============+================+
| ASN Range | r.r.r.r | Count | Purpose |
| (decimal) | Equivalent | | |
+===============+=================+=============+================+
| 1,627,389,952 | 97.0.0.0/8 | 16,777,216 | Near-Earth |
| - | | | infrastructure |
| 1,644,167,167 | | | realm |
| | | | (Informative, |
| | | | Section 3.12) |
+---------------+-----------------+-------------+----------------+
| 1,644,167,168 | 98.0.0.0/8 | 16,777,216 | Cislunar / |
| - | | | Lunar realm |
| 1,660,944,383 | | | (Informative, |
| | | | Section 3.12) |
+---------------+-----------------+-------------+----------------+
| 1,660,944,384 | 99.0.0.0/8 | 16,777,216 | Martian realm |
| - | | | (Informative, |
| 1,677,721,599 | | | Section 3.12) |
+---------------+-----------------+-------------+----------------+
| 1,677,721,600 | 100.0.0.0/8 | 16,777,216 | RINE peering |
| - | | | fabric |
| 1,694,498,815 | | | |
+---------------+-----------------+-------------+----------------+
| 2,130,706,432 | 127.0.0.0/8 | 16,777,216 | Internal zone |
| - | | | prefixes |
| 2,147,483,647 | | | |
Hause Expires 18 October 2026 [Page 79]
Internet-Draft ASIP April 2026
+---------------+-----------------+-------------+----------------+
| 2,851,995,648 | 169.254.0.0/16 | 65,536 | Link-local |
| - | | | scope |
| 2,852,061,183 | | | |
+---------------+-----------------+-------------+----------------+
| 4,026,531,840 | 240.0.0.0/8 | 16,777,216 | Mesh / ad-hoc |
| - | | | scope |
| 4,043,309,055 | | | |
+---------------+-----------------+-------------+----------------+
| 4,043,309,056 | 241.0.0.0 - | 150,994,944 | Future |
| - | 249.255.255.255 | | celestial |
| 4,194,303,999 | | | bodies |
| | | | (Informative) |
+---------------+-----------------+-------------+----------------+
| 4,194,304,000 | 250.0.0.0/8 | 16,777,216 | DTN relay |
| - | | | realm |
| 4,211,081,215 | | | (Informative) |
+---------------+-----------------+-------------+----------------+
| 4,211,081,216 | 251.0.0.0 - | 50,331,648 | Reserved for |
| - | 253.255.255.255 | | future use |
| 4,261,412,863 | | | |
+---------------+-----------------+-------------+----------------+
| 4,261,412,864 | 254.0.0.0/8 | 16,777,216 | Documentation |
| - | | | and testing |
| 4,278,190,079 | | | |
+---------------+-----------------+-------------+----------------+
| 4,278,190,080 | 255.0.0.0 - | 16,776,960 | Reserved for |
| - | 255.255.254.255 | | future use |
| 4,294,967,039 | | | (non- |
| | | | multicast/ |
| | | | broadcast) |
+---------------+-----------------+-------------+----------------+
Table 15
15.4. 15.4. DNS A-ASIP Record Type
IANA is requested to assign a DNS resource record type number for the
A-ASIP record type defined in Section 7.
15.5. 15.5. ICMP-ASIP Next-Header Value and Type Registry
IANA is requested to assign a previously-unassigned value in the IP
Protocol Numbers / IPv6 Extension Header registry for ICMP-ASIP. The
requested value is 143; any unassigned value in the range 143-252
that IANA prefers is acceptable. The assigned value MUST NOT be 58
(ICMPv6) to prevent dispatcher ambiguity across header-stripping
middleboxes.
Hause Expires 18 October 2026 [Page 80]
Internet-Draft ASIP April 2026
IANA is also requested to establish a registry for ICMP-ASIP message
types, initially populated with types corresponding to ICMPv4
[RFC792] and ICMPv6 [RFC4443] equivalents including Neighbor
Solicitation, Neighbor Advertisement, Router Solicitation, and Router
Advertisement for SLAAC-ASIP and neighbor discovery.
15.6. 15.6. Cross-ASN Multicast Registry
IANA is requested to establish a registry for ASIP cross-ASN
multicast prefix assignments within r.r.r.r = 255.255.255.0/24, with
scope values as defined in Section 10.1.
15.7. 15.7. Broadcast Reservation
IANA is requested to reserve r.r.r.r = 255.255.255.255 as the ASIP
broadcast address.
15.8. 15.8. Next Header Values
ASIP draws from the IPv6 Next Header registry for shared protocols
(TCP, UDP, ESP, AH, Routing, Fragment, Destination Options, No Next
Header). It requests a distinct value for ICMP-ASIP (Section 15.5)
rather than reusing NH=58, to eliminate dispatcher ambiguity at
header-stripping middleboxes.
15.9. 15.9. GENEVE Inner-Protocol Assignment for ASIP-to-IPv4
IANA is requested to assign a GENEVE [RFC8926] inner-protocol type
identifying encapsulated ASIP frames for use by the ASIP-to-IPv4
transit encapsulation defined in Section 12.3.
15.10. 15.10. WHOIS-ASIP Registry Domain Delegation
IANA is requested to delegate one or more well-known registry domains
for WHOIS-ASIP service discovery (§8.4 "Service discovery"). Each
delegated domain MUST carry an _whois-asip._tcp SRV record resolvable
over IPv4 so that a bootstrapping ASN can locate its regional WHOIS-
ASIP service without a pre-existing ASIP path. The specific
delegation structure (single global domain vs. per-RIR domains) is
left to IANA and the RIR community; this specification requires only
that the delegation exist and that the SRV record be IPv4-resolvable
during transition.
16. 16. Zone Server Reference Architecture (Informative)
This section is INFORMATIVE. Nothing in this section is a protocol-
layer requirement. Operators MAY deploy ASIP addressing without any
Zone Server infrastructure.
Hause Expires 18 October 2026 [Page 81]
Internet-Draft ASIP April 2026
16.1. 16.1. Concept
The Zone Server is a reference architecture for unified network
service delivery. A Zone Server is a paired active/active platform
that consolidates address assignment (DHCP-ASIP), name resolution
(DNS-ASIP), time synchronization (NTP8), telemetry collection
(NetLog8), authentication caching, route validation, access control,
and IPv4/ASIP address translation (XLATE-ASIP) into a single
operational platform.
The motivation is operational: modern networks require a minimum of
6-8 independently configured, independently authenticated,
independently monitored services before a device is operational. The
Zone Server consolidates these into a single platform with a shared
identity model and a single configuration surface.
16.2. 16.2. Service Delivery Model
A device connecting to a Zone Server-equipped network sends one DHCP-
ASIP Discover and receives a single response containing every service
endpoint it requires. No subsequent manual configuration is needed.
The device is fully operational (addressed, authenticated, time-
synchronized, logged) before its first user interaction.
16.3. 16.3. Authentication Model
The Zone Server reference architecture recommends OAuth2 JWT
[RFC7519] as the universal authentication mechanism. Tokens are
validated locally by the Zone Server without round trips to external
identity providers. This enables continued operation when upstream
identity providers are unreachable.
Operators MAY use alternative authentication mechanisms. The Zone
Server architecture is a recommendation, not a protocol-layer
mandate.
16.4. 16.4. Why This Is Informative, Not Normative
Bundling operational architecture into a protocol specification is a
category error. Protocols define wire formats and interoperability
requirements. Operational architecture defines how organizations
deploy and manage their networks. These are different concerns with
different rates of change, different stakeholders, and different
consensus requirements.
Hause Expires 18 October 2026 [Page 82]
Internet-Draft ASIP April 2026
The Zone Server architecture is published as a companion
specification to enable operators who want unified management to
deploy it. Operators who do not want it lose nothing. ASIP
addressing works without it.
17. 17. Cost Factor Routing Metric (Informative)
The Cost Factor (CF) routing metric is specified in a separate
companion document (draft-asip-cf-00). CF is intended as an OPTIONAL
multi-dimensional path-selection input beyond the standard BGP
attributes (LOCAL_PREF, AS_PATH, ORIGIN, MED). CF is NOT a protocol-
layer requirement of this document: ASIP eBGP-ASIP sessions MUST
function correctly using only standard BGP path-selection criteria
[RFC4271], and no normative behavior defined in §§3–15 of this
document depends on CF. An operator MAY deploy ASIP without any CF
awareness; conformance to this specification does not require
parsing, emitting, or acting on a CF path attribute. Implementers
seeking the CF component set, accumulation semantics, wire-format
encoding, and physics-floor rules MUST consult the companion draft;
partial CF machinery is intentionally not reproduced here because a
partial reproduction could be treated as specification despite not
being a complete one, which would fork CF semantics between the two
documents.
18. 18. Acknowledgment of Trade-offs
Every protocol design involves trade-offs. This section makes them
explicit rather than pretending they don't exist. Items marked
UNRESOLVED describe cases where the design has no clean answer; they
are documented here rather than hidden.
18.1. 18.1. Header Overhead
The 40-byte ASIP base header is 20 bytes larger than IPv4 (20 bytes)
and identical in size to IPv6 (40 bytes). By adopting IPv6's fixed-
header design (dropping IHL, header checksum, and inline
fragmentation), ASIP achieves header parity with IPv6 while carrying
the same 128-bit address space in a structured four-field format. On
bandwidth-constrained links (satellite, IoT, cellular), the 20-byte
overhead versus IPv4 is non-trivial. Header compression (ROHC or
equivalent adapted for ASIP) is RECOMMENDED for such environments.
Per-packet overhead in ASIP-to-IPv4 transit is higher because of the
outer IPv4 and UDP headers. The total bytes above the inner L4
payload are ASIP(40) + IPv4(20) + UDP(8) + GENEVE(8) = 76 bytes, of
which the inner ASIP header contributes 40 bytes and the
encapsulation framing (IPv4 + UDP + GENEVE) contributes 36 bytes. An
HTTPS (TCP/TLS) tunneling alternative costs 109 total bytes per
Hause Expires 18 October 2026 [Page 83]
Internet-Draft ASIP April 2026
packet (ASIP(40) + IPv4(20) + TCP(20) + TLS(~29)) and introduces TCP
congestion-control interactions; GENEVE/UDP is preferred because it
avoids both the extra 33 bytes and the TCP-over-TCP pathology (see
§12.3 rationale).
18.2. 18.2. Rigid Hierarchy
The fixed four-field address structure (ASN/Zone/Subnet/Host) imposes
a specific network topology model. Organizations whose networks do
not map naturally to this hierarchy (highly flat networks, mesh
topologies, multi-ASN single-logical-network deployments) may find
the structure constraining. The Zone and Subnet fields are locally
significant and operator-assigned, which provides flexibility within
an organization. The r.r.r.r field is drawn from the global ASN
number space and is constrained by external allocation.
18.3. 18.3. ASN Dependency
Every ASIP-routable address requires an ASN locator. Organizations
that do not currently hold an ASN must obtain one before deploying
ASIP with public-facing addresses. The ASN allocation process is
well-established via RIRs but adds a bureaucratic step that IPv4 and
IPv6 do not require for basic internet connectivity. Organizations
using only internal zone addressing (127.x.x.x) or link-local
addressing (169.254.x.x) do not require a public ASN.
18.4. 18.4. Transition Realism
ASIP is not wire-compatible with IPv4. Every router, OS kernel, NIC
driver, firewall, IDS/IPS, load balancer, and middlebox in the
forwarding path of an ASIP-aware endpoint must receive a software
update to process Version=8 frames natively; hardware that cannot be
updated must be replaced or bypassed via the Section 12.3
encapsulation. Until that happens for each deployment segment, ASIP-
to-IPv4 encapsulation handles transit, but encapsulation adds
overhead (36 bytes of encapsulation framing per packet: outer
IPv4(20) + UDP(8) + GENEVE(8); total bytes above the inner L4 payload
are 76 with the 40-byte inner ASIP header included) and operational
complexity (tunnel MTU, PMTU discovery, endpoint discovery). The
transition is incremental, not instantaneous, and not free. The
abstract and Section 1.2 state this plainly rather than claiming "no
modification required."
Hause Expires 18 October 2026 [Page 84]
Internet-Draft ASIP April 2026
18.5. 18.5. Relationship to IPv6
ASIP does not claim that IPv6 is technically deficient. IPv6 is a
well-designed protocol that solves the address exhaustion problem,
and ASIP borrows extensively from its design: the fixed 40-byte
header, extension header mechanism, flow label, traffic class, SLAAC
model, scoped multicast, and the elimination of header checksums and
router-path fragmentation are all IPv6 innovations adopted wholesale.
ASIP's residual contribution is the structured four-field address
format (ASN locator / Zone / Subnet / Host), the IPv4-mapped address
form, and a more structured relationship between the routing locator
and the registered ASN. Whether this narrower contribution justifies
a new protocol version rather than a set of IPv6 deployment
guidelines is a legitimate question that this document does not claim
to settle. Both protocols MAY coexist indefinitely.
18.6. 18.5a. UNRESOLVED: Multihoming Under an ASN-Shaped Address
Section 8.3.1 handles multihoming by assigning one address per
upstream ASN. This preserves capability but has a real cost: a
multihomed host presents multiple stable addresses to applications,
DNS-ASIP, and any system that identifies a host by its address
literal rather than by name. Applications that hash or pin on IP
address (legacy configuration files, certain rate-limit systems,
session-affinity middleware) will see the same host as two hosts.
Happy-eyeballs-style selection helps on the client side but does not
solve the server-side identification problem. Alternatives
considered and rejected were: (i) a separate non-locator host
identifier field, which would have required a header redesign; (ii)
identifier/locator split via HIP or LISP-style mapping, which would
have added a mapping-service dependency on the critical path.
Neither was compatible with the "familiar dotted-decimal, no new
control plane" goal. The chosen trade-off is documented here as a
cost the design accepts, not a cost it resolves.
18.7. 18.5b. Server-Side Multi-Address Operational Impact
The multi-address model in §8.3.1 creates concrete operational
consequences for any server-side system that derives identity or
state from the client's source IP literal. This subsection names the
affected systems, prescribes mitigations, and states the normative
status of each mitigation. It converts §18.5a's acknowledgment of
the multihoming trade-off into deployable operator guidance.
*Affected systems (non-exhaustive):*
Hause Expires 18 October 2026 [Page 85]
Internet-Draft ASIP April 2026
+====================+==============================================+
| System | Failure mode under multi-address |
+====================+==============================================+
| HTTP session | One user is routed to different backends |
| stickiness keyed | across requests if the client switches |
| on source IP | between its per-ASN addresses. |
+--------------------+----------------------------------------------+
| Rate limiters | Effective per-user limit is multiplied by |
| keyed on source IP | the number of upstream ASNs; DoS defenses |
| | under-count. |
+--------------------+----------------------------------------------+
| Stateful firewalls | Return traffic on a different source |
| with per-IP state | address than the forward flow is dropped |
| tables | or mismatched to a different state entry. |
+--------------------+----------------------------------------------+
| IP allow-lists / | A client reachable via ASN_A is allow- |
| IP block-lists | listed by its ASN_A address; the same |
| | client arriving via ASN_B is not |
| | recognized. |
+--------------------+----------------------------------------------+
| TLS session | Resumption tickets bound to the ASN_A |
| resumption keyed | address fail when the client reconnects |
| on peer IP | from its ASN_B address, forcing full |
| | handshakes. |
+--------------------+----------------------------------------------+
| Abuse-reporting, | A single user action appears in logs as |
| audit logs, SIEM | multiple distinct sources; incident |
| correlation | investigation must cross-reference. |
+--------------------+----------------------------------------------+
| CAPTCHA / risk- | Reputation does not aggregate across a |
| score systems | client's addresses. |
| keyed on IP | |
+--------------------+----------------------------------------------+
| Path-bound PMTU | A host must track PMTU per source |
| caches (see §12.8) | address, not per destination, because the |
| | forward path differs per address. |
+--------------------+----------------------------------------------+
Table 16
*Mitigations.* The following mitigations address the above failure
modes. Normative status is assigned per mitigation; operators
deploying ASIP servers in the public internet SHOULD implement the
normative ones.
* *(Normative, SHOULD) Prefer session-token stickiness over IP
stickiness.* HTTP load balancers SHOULD use cookie-based or JWT-
based stickiness rather than source-IP hashing when serving ASIP
Hause Expires 18 October 2026 [Page 86]
Internet-Draft ASIP April 2026
clients. This is the single most effective mitigation and the one
operators can implement without any ASIP-specific support from
clients.
* *(Normative, SHOULD) Group by ASN in rate limiters.* Rate limiters
SHOULD include the r.r.r.r ASN locator as an aggregation key in
addition to the full 128-bit address, so that clients from the
same enterprise ASN aggregate into one bucket. This is effective
for the common multihoming case where a client's two addresses
share the enterprise's two transit ASNs. For clients whose
multiple addresses come from disjoint ASNs (e.g., a home user
multihomed across two retail ISPs), ASN-grouping does not
aggregate and token-based identity (cookies, JWTs) SHOULD be used
instead.
* *(Normative, SHOULD) Export z:s:h as the stable-identity triple in
logs.* Where logs must correlate a user across addresses, the
z:s:h 96-bit triple under the same administrative scope (§3.1
identifier/locator separation) is the stable portion. Logging
systems SHOULD record both the full address and the z:s:h triple
so downstream correlation is possible.
* *(Advisory, MAY) DNS-based address preference rules.*
Authoritative DNS-ASIP servers MAY order A-ASIP records in a
consistent preference order per client (by ASN geography, by
peering cost, etc.) so that a given client preferentially selects
the same server-side address most of the time, reducing but not
eliminating the multi-address fan-out. This is advisory because
it depends on DNS resolver and client cache behavior that the
server cannot control.
* *(Normative, MUST -- see §12.8) Per-address PMTU cache.* Hosts
holding multiple ASIP source addresses MUST cache PMTU state keyed
by (source address, destination address), not by destination
alone, because the forward path is a function of the chosen source
address. The MUST status is defined in §12.8 and applies
identically here; this subsection does not weaken it.
* *(Advisory, MAY) TLS session resumption across addresses.* TLS
server implementations MAY accept resumption tickets regardless of
peer-IP continuity when the ticket includes a client-identity
binding (PSK or channel ID). This is advisory because RFC 8446
does not require IP continuity and most existing implementations
already accept resumption across address changes; the note is
included for implementations that currently check peer IP.
Hause Expires 18 October 2026 [Page 87]
Internet-Draft ASIP April 2026
* *(Advisory, MAY) Firewall session reconciliation.* Stateful
firewalls MAY use a client-identity tag (TLS channel ID, QUIC
connection ID, or application cookie) as an auxiliary state key so
that return traffic on a different source address is matched to
the existing forward-flow state. This is advisory because the
firewall must be in the application's trust domain to read such
identifiers.
*Deliberate non-resolution.* The normative/advisory split above is
deliberate: mitigations that a single operator can deploy without
cooperation from clients, DNS, or other operators are normative
(SHOULD); mitigations that require cross-party coordination or depend
on application semantics outside the firewall/LB boundary are
advisory (MAY). This distinction is not a design escape hatch; it
reflects what a deploying operator can actually control.
Applications that cannot tolerate multi-address semantics at all
SHOULD pin the client to a single address in DNS-ASIP (publish only
one A-ASIP record per client) at the cost of losing multihoming
failover — this is a deployment choice, not a protocol defect.
18.8. 18.6. WHOIS-ASIP Adoption
WHOIS-ASIP route validation provides meaningful security only if
widely adopted. An eBGP-ASIP router that enforces WHOIS-ASIP
validation in a network where most peers do not publish WHOIS-ASIP
records will reject legitimate routes. The same chicken-and-egg
problem that limited RPKI deployment applies here. The
simplification from one-route-per-ASN reduces but does not eliminate
this problem.
18.9. 18.7. 32-Bit Host Field and SLAAC Constraints
The 32-bit host field (h.h.h.h) is substantially smaller than IPv6's
64-bit interface identifier. This limits SLAAC-ASIP to methods that
produce 32-bit identifiers rather than the full EUI-64 derivation
available in IPv6. Birthday-paradox analysis (§3.14.3) gives
approximately 39% collision probability at N=65,536 and 50% at
N~77,000; the 10,000-host DHCP-ASIP-fallback threshold sits well
below this point (~1% collision probability) to give DAD retries a
large safety margin. Modern datacenter leaf-subnet populations
routinely approach or exceed 10,000, so the threshold is
operationally material: the collision region is reached by real
fabrics, not by theoretical corner cases. Section 3.14.3 specifies
the consequence: deployments expected to exceed ~10,000 concurrent
hosts per subnet MUST use DHCP-ASIP rather than relying on SLAAC-ASIP
uniqueness, and DAD retries are bounded to prevent indefinite re-
rolling.
Hause Expires 18 October 2026 [Page 88]
Internet-Draft ASIP April 2026
18.10. 18.8. Interplanetary Address Reservation
Reserving large ASN ranges for celestial bodies that currently have
zero networked devices may appear wasteful. The counter-argument is
that address space reservation costs nothing today but prevents
painful renumbering later. IPv4's failure to reserve space for
mobile devices, IoT, and cloud infrastructure before they existed is
a cautionary example. The reservations are deliberately generous and
can always be narrowed later; they cannot easily be widened once
allocated.
18.11. 18.9. Complexity Budget
ASIP is more complex than either IPv4 or IPv6 individually. It
combines IPv4's addressing familiarity, IPv6's header and extension
mechanism, a new hierarchical address structure, SLAAC, scoped
multicast, and forward-looking realm allocations. Each feature is
independently justified, but the aggregate complexity is a real
adoption barrier. Implementors must understand three protocol
generations to build a compliant stack. This specification attempts
to mitigate complexity by making most features OPTIONAL or
RECOMMENDED rather than REQUIRED, but the specification itself is
long. A novel routing metric (the OPTIONAL Cost Factor, §17) is
deliberately excised to a companion draft so that the ASIP address-
family specification is not burdened with a metric it does not
require.
19. References
19.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/rfc/rfc2119>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/rfc/rfc2827>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/rfc/rfc3704>.
Hause Expires 18 October 2026 [Page 89]
Internet-Draft ASIP April 2026
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/rfc/rfc4271>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/rfc/rfc4443>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/rfc/rfc4760>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/rfc/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/rfc/rfc4862>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/rfc/rfc6437>.
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of
Oversized IPv6 Header Chains", RFC 7112,
DOI 10.17487/RFC7112, January 2014,
<https://www.rfc-editor.org/rfc/rfc7112>.
[RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel,
"Codification of AS 0 Processing", RFC 7607,
DOI 10.17487/RFC7607, August 2015,
<https://www.rfc-editor.org/rfc/rfc7607>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC7915, June 2016,
<https://www.rfc-editor.org/rfc/rfc7915>.
Hause Expires 18 October 2026 [Page 90]
Internet-Draft ASIP April 2026
[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/rfc/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/rfc/rfc8201>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/rfc/rfc8926>.
19.2. Informative References
[I-D.thain-ipv8]
Thain, J., "Internet Protocol Version 8 (IPv8)", Work in
Progress, Internet-Draft, draft-thain-ipv8-00, April 2026,
<https://datatracker.ietf.org/doc/draft-thain-ipv8/>.
[RFC1624] Rijsinghani, A., Ed., "Computation of the Internet
Checksum via Incremental Update", RFC 1624,
DOI 10.17487/RFC1624, May 1994,
<https://www.rfc-editor.org/rfc/rfc1624>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/rfc/rfc1812>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/rfc/rfc1918>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/rfc/rfc2328>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/rfc/rfc3810>.
Hause Expires 18 October 2026 [Page 91]
Internet-Draft ASIP April 2026
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/rfc/rfc4291>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/rfc/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/rfc/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/rfc/rfc4303>.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April
2006, <https://www.rfc-editor.org/rfc/rfc4459>.
[RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for
Documentation Use", RFC 5398, DOI 10.17487/RFC5398,
December 2008, <https://www.rfc-editor.org/rfc/rfc5398>.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
DOI 10.17487/RFC5927, July 2010,
<https://www.rfc-editor.org/rfc/rfc5927>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/rfc/rfc5952>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/rfc/rfc6105>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/rfc/rfc6480>.
Hause Expires 18 October 2026 [Page 92]
Internet-Draft ASIP April 2026
[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for
Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July
2013, <https://www.rfc-editor.org/rfc/rfc6996>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013,
<https://www.rfc-editor.org/rfc/rfc7045>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/rfc/rfc7217>.
[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
DOI 10.17487/RFC7346, August 2014,
<https://www.rfc-editor.org/rfc/rfc7346>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/rfc/rfc792>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/rfc/rfc8305>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/rfc/rfc8899>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/rfc/rfc8981>.
Hause Expires 18 October 2026 [Page 93]
Internet-Draft ASIP April 2026
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
January 2022, <https://www.rfc-editor.org/rfc/rfc9171>.
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/rfc/rfc9172>.
Author's Address
Jordan Hause
Independent
Email: truixprojects@gmail.com
Hause Expires 18 October 2026 [Page 94]