IPv4.5: A Locator/Identifier-Separated Extension to IPv4 with Post-Quantum Session Security

IPv4.5: A Locator/Identifier-Separated Extension to IPv4 with Post-Quantum Session Security Independent Researcher

info@insane-projects.com

Internet Internet Area Working Group IPv4 addressing address exhaustion post-quantum cryptography Locator/Identifier separation LISP transition NAT ML-KEM The global IPv4 address space was exhausted at the IANA level in 2011, and Carrier-Grade NAT (CGN) has since served as the primary operational workaround. CGN preserves connectivity but violates the end-to-end principle, complicates application development, and introduces substantial operational overhead. This document specifies IPv4.5, a pragmatic extension of IPv4 that introduces a 96-bit address space organized as a Locator/Identifier separation: a 32-bit IPv4 Locator, a 16-bit Site Identifier, and a 48-bit Endpoint Identifier. IPv4.5 packets are encapsulated in UDP (port 4242) for transparent transit through existing IPv4 routers, NAT devices, and firewalls without requiring infrastructure changes. Session security is established through a hybrid post-quantum key exchange combining ML-KEM-768 and X25519 , performed once per session. Subsequent data protection uses symmetric AEAD ciphers (AES-256-GCM or ChaCha20-Poly1305). The design enforces strict separation of concerns across four independent planes: data, control, identity, and cryptographic. Higher-level functions such as semantic routing and self-sovereign identity are explicitly out of scope for this specification.

Introduction

Problem Statement The IPv4 address pool managed by IANA was exhausted in February 2011. Subsequent exhaustion at each Regional Internet Registry (RIR) has forced network operators to rely on Carrier-Grade NAT (CGN) as a large-scale address sharing mechanism. While CGN preserves IPv4 reachability, it introduces the following well-documented problems:

Violation of the end-to-end principle: applications cannot rely on a globally unique, reachable address for each endpoint.
Peer-to-peer impairment: NAT traversal for real-time communication requires additional infrastructure such as STUN, TURN, and ICE.
Logging complexity: multiple subscribers share a single public IPv4 address at any given time, complicating forensic and legal demands.
Single point of failure: CGN appliances represent concentrated failure domains in operator networks.

IPv6 was designed to resolve address exhaustion definitively, but its adoption has progressed slowly after more than two decades of availability. As of 2026, IPv6 accounts for approximately 45-50% of Internet traffic by volume, and growth has decelerated. Key barriers include dual-stack operational cost, the absence of day-one benefit for early adopters, and a large installed base of IPv4-only applications and embedded devices. Furthermore, neither IPv4 nor IPv6 was designed with post-quantum cryptography (PQC) in mind. Future quantum computers capable of running Shor's algorithm would break classical elliptic-curve and RSA key exchange mechanisms, enabling "harvest now, decrypt later" attacks against recorded traffic.

Design Goals IPv4.5 is designed to satisfy the following goals:

G1 (Address Exhaustion):: Provide a globally unique address space sufficient for 6G/IoT requirements, without relying on address sharing.
G2 (Transparent Transit):: Deploy immediately over existing IPv4 infrastructure, with no changes required to intermediate routers, NAT devices, or firewalls.
G3 (Day-One ROI):: Provide immediate, measurable benefits to early adopters — including endpoint privacy and quantum-resistant session security — independent of the deployment fraction of IPv4.5 on the Internet.
G4 (Quantum Resistance):: Resist passive traffic recording and future decryption by quantum computers, using NIST-standardized post-quantum key encapsulation .
G5 (Layered Design):: Limit the network-layer specification to addressing and forwarding. Advanced functions are delegated to separate planes or companion specifications.
G6 (Privacy):: Support per-session ephemeral Endpoint Identifiers to prevent cross-session endpoint tracking.
G7 (Political Acceptability):: Require no central authority, mandatory validation service, or built-in surveillance mechanism.

Non-Goals The following are explicitly OUT OF SCOPE for this document:

Content-based or semantic routing at the network layer.
Per-packet intent or policy fields in the data plane.
Mandatory Decentralized Identifier (DID) or self-sovereign identity requirements.
Per-packet post-quantum digital signatures.
Traffic anonymization equivalent to Tor or mixnet overlays.

Relationship to Existing Work IPv4.5 is inspired by, but distinct from, the Locator/Identifier Separation Protocol (LISP) . LISP is an overlay tunneling protocol designed to scale BGP routing; IPv4.5 defines a new wire format with explicit addressing semantics and integrated session security. IPv4.5 borrows the Map-Server/Map-Resolver architecture of LISP as one supported implementation of its EID-Locator Mapping Service. The UDP encapsulation approach is analogous to QUIC , which demonstrated that a new transport protocol can achieve broad deployment by operating over existing UDP/IP infrastructure. IPv4.5 is complementary to IPv6 and does not compete with it.

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 when, and only when, they appear in all capitals, as shown here.

Terminology

Locator: A 32-bit IPv4 address that identifies the network attachment point of an IPv4.5 anchor. Locators are allocated from existing IPv4 address pools and are routed by unmodified IPv4 infrastructure using standard routing protocols (BGP, OSPF, IS-IS).
Site Identifier (Site ID): A 16-bit value allocated by the operator of an IPv4.5 anchor. Identifies a logical administrative domain (e.g., a data center, campus, or enterprise network) behind a single Locator.
Endpoint Identifier (EID): A 48-bit value that uniquely identifies an endpoint within a Site. EIDs may be statically assigned (persistent) or dynamically generated per session (ephemeral; see eNID).
IPv4.5 Address: The 96-bit triple [Locator | Site ID | EID] that globally and uniquely identifies an IPv4.5 endpoint.
Anchor: An IPv4.5-aware node holding one or more Locators, responsible for encapsulating and decapsulating IPv4.5 packets to and from standard UDP/IPv4 packets for endpoints in its site.
Edge Translator: A gateway that enables communication between IPv4.5 endpoints and IPv4-only endpoints, performing address and header conversion in both directions.
EID-Locator Mapping Service (ELMS): A distributed service that maps Endpoint Identifiers to their current Locators, enabling resolution of EIDs not directly resolvable via DNS.
Ephemeral Network Interface Designator (eNID): A per-session randomly generated EID used to prevent cross-session endpoint tracking. Modeled after IPv6 Privacy Extensions and Semantically Opaque Interface Identifiers .
Intent Negotiation Protocol (INP): A control-plane protocol through which endpoints request session-level service characteristics (latency class, bandwidth class) from the network operator's policy controller.
AX Record: A new DNS resource record type conveying a 96-bit IPv4.5 address, analogous to the A record (IPv4) and AAAA record (IPv6).

Architecture Overview

Four-Plane Separation IPv4.5 is organized into four independent planes, each with a well-defined scope and interface boundary:

IPv4.5 Four-Plane Architecture

Data Plane (mandatory): Forwards IPv4.5 packets between anchors and endpoints. Applies AEAD encryption and decryption using symmetric session keys. Stateless except for per-session symmetric key material.
Control Plane (mandatory): Resolves EIDs to Locators, negotiates session policies, and handles endpoint mobility. Implemented as a separate daemon or process. MUST NOT be on the forwarding fast path.
Identity Plane (optional): Authenticates endpoints during the initial handshake using one of four supported identity models. MUST NOT be referenced by the data plane after handshake completion.
Cryptographic Plane (mandatory): Performs hybrid post-quantum key exchange to establish session keys. Provides derived key material to the data plane for symmetric encryption.

Operating Modes IPv4.5 defines four operating modes for staged deployment:

Mode A (Pass-Through): Pure IPv4 operation. No IPv4.5 processing. All existing IPv4 traffic continues unmodified.
Mode B (Translated): An IPv4.5 endpoint communicates with a legacy IPv4-only endpoint through an Edge Translator. REQUIRED for deployments that must interoperate with IPv4-only peers.
Mode C (Encapsulated): An IPv4.5 endpoint communicates with another IPv4.5 endpoint using UDP encapsulation over standard IPv4 (protocol 17, port 4242). No changes are required to intermediate routers. This is the baseline operational mode for Phase 1 and Phase 2 deployment. All IPv4.5 implementations MUST support Mode C.
Mode D (Native, OPTIONAL): An IPv4.5 endpoint communicates with another IPv4.5 endpoint using IP Protocol 144 directly, without UDP encapsulation. Requires router firmware support. Intended for Phase 3 deployment.

Addressing

Address Format An IPv4.5 address is 96 bits wide, consisting of three contiguous fields:

IPv4.5 96-bit Address Format The total address space is 2^96 ≈ 7.9 × 10^28, sufficient for all projected 6G, IoT, and cloud workloads through at least 2050 by multiple orders of magnitude.

Address Allocation

Locator: IPv4.5 reuses existing IPv4 address allocations from IANA and the Regional Internet Registries. No new global registry or allocation process is required. BGP announcements for Locators are identical to existing IPv4 BGP practice .
Site ID: The anchor operator allocates Site IDs within its Locator's space. No registration with any external authority is required.
Endpoint ID: EIDs may be assigned by an operator-managed allocation service (analogous to DHCP) or generated autonomously by the endpoint (analogous to IPv6 SLAAC). Implementations generating EIDs autonomously MUST use a cryptographically secure random number generator conforming to .

Textual Representation The canonical textual representation of an IPv4.5 address is: :::: ]]> where the Endpoint Identifier is written as three 16-bit groups separated by colons. Leading zeros within each group MAY be omitted. The double-colon (::) serves as a field separator and MUST NOT be interpreted using IPv6 zero-compression rules. Example: An implementation parsing an IPv4.5 address MUST reject strings that do not contain exactly two "::" separators.

Reserved Addresses The following addresses are reserved and MUST NOT be assigned to operational endpoints: IPv4.5 Reserved Addresses

Pattern	Purpose
0.0.0.0::0::0:0:0	Unspecified address
127.0.0.1::::	Loopback (all Site IDs and EIDs)
224.0.0.0/4::::	Multicast Locator range
LOCATOR::FFFF::*	Site-local scope
LOCATOR::FFFE::*	Link-local scope
LOCATOR::FFFF::FFFF:*	IPv4-Embedded EID (compatibility)

For Edge Translator (Mode B) operation, a pure IPv4 endpoint with address A.B.C.D behind translator at address T is represented as:

Example: IPv4 198.51.100.42 behind translator 203.0.113.1: 203.0.113.1::FFFF::FFFF:C633:642A ]]>

Ephemeral Endpoint Identifiers (eNIDs) To mitigate cross-session endpoint tracking, implementations SHOULD use a per-session randomly generated EID (Ephemeral Network Interface Designator, eNID). An eNID:

MUST be generated using a cryptographically secure random number generator conforming to .
SHOULD be regenerated at the start of each new session or after a configurable interval (recommended default: 24 hours).
MUST NOT be reused across sessions to distinct destination endpoints.
SHOULD be statistically indistinguishable from a static EID to on-path observers.

Packet Format

IPv4.5 Fixed Header The IPv4.5 fixed header is exactly 20 bytes. When operating in Mode C, the Locator fields are carried in the outer IPv4 header and are NOT repeated in the IPv4.5 header.

IPv4.5 Fixed Header (20 bytes)

Field Descriptions

Version (4 bits)

MUST be set to 1 for this version of IPv4.5. Packets with Version ≠ 1 MUST be silently discarded.

Type (4 bits)

Identifies the purpose of the packet:

Value	Name	Description
0	DATA	Carries upper-layer payload
1	HANDSHAKE	Session establishment and key exchange
2	CONTROL	Control-plane messages (ELMS, INP)
3	ECHO	Echo request/reply (diagnostic)
4	ERROR	Reports error conditions to the sender
5	KEEPALIVE	NAT/firewall session keepalive
6-14	—	Unassigned; see
15	—	Reserved; MUST NOT be used

Hop Limit (8 bits)

Initialized to 64 by sending implementations. Each IPv4.5-aware forwarding node MUST decrement this field by 1. See .

Payload Length (16 bits)

Length in bytes of all content following the 20-byte fixed IPv4.5 header, including any extension headers.

Next Header (8 bits)

Identifies the protocol of the immediately following header or upper-layer payload. Uses IANA-assigned Internet Protocol Number values.

Flags (8 bits)

Bit	Symbol	Meaning
0 (MSB)	E	Payload is AEAD-encrypted and authenticated
1	F	Fragmentation extension header is present
2	X	Additional extension headers are present
3	M	More fragments follow (used with F)
4	C	Compression (reserved for future use)
5	N	NAT traversal extension present
6-7	—	Reserved; MUST be sent as zero

Flow Label (16 bits)

Identifies a traffic flow for ECMP load distribution and QoS treatment. When assigned by INP (), reflects the negotiated SLA class. Otherwise, MUST be set to a pseudorandom value.

Mode C Encapsulation In Mode C, an IPv4.5 packet is encapsulated in UDP over IPv4 :

IPv4.5 Mode C Packet Structure The outer IPv4 DF bit MUST be set to enable Path MTU Discovery (). The outer IP TTL SHOULD be set to 64.

Extension Headers Extension headers provide optional functionality. They are chained using the Next Header field and MUST be processed in the order they appear. IPv4.5 Extension Header Types

Next Header	Extension Type	Description
0x00	Hop-by-Hop Options	Options processed by every forwarding node
0x01	Routing	Explicit source routing via designated anchors
0x02	Mobility	Locator change notification for mobile endpoints
0x03	Fragmentation	Source-originated fragmentation and reassembly
0x04	Authentication	Handshake signature and certificate chain
0x05	ESP-X	AEAD-encrypted and authenticated payload container
0x06	Destination Options	Options processed only by the destination
0xFF	No Next Header	No content follows

Fragmentation Extension Header

IPv4.5 Fragmentation Extension Header (8 bytes) Fragment reassembly MUST time out after 60 seconds. Incomplete fragment sets MUST be silently discarded.

Forwarding

Path MTU Discovery All IPv4.5 implementations MUST support Path MTU Discovery (PMTUD) as defined in and . Implementations SHOULD also implement Packetization Layer Path MTU Discovery (PLPMTUD) as a fallback when ICMP messages are filtered. The minimum IPv4.5 Path MTU is 1280 bytes. In Mode C, the minimum effective payload MTU is: The Don't Fragment (DF) bit MUST be set in the outer IPv4 header. When a router drops an oversized packet, it MUST return an ICMP Fragmentation Needed (Type 3, Code 4) message to the sending anchor. The anchor MUST propagate this information to the originating endpoint via an IPv4.5 ERROR message (Type 4, Error Code MTU_EXCEEDED).

Fragmentation Source endpoints MUST fragment packets that exceed the discovered Path MTU using the IPv4.5 Fragmentation Extension Header (Next Header 0x03). Intermediate nodes MUST NOT fragment IPv4.5 packets.

Hop Limit Processing When an IPv4.5-aware node forwards a packet, it MUST decrement the Hop Limit by 1. If the resulting value is zero:

The node MUST NOT forward the packet.
The node SHOULD send an IPv4.5 ERROR message (Type 4, Error Code HOP_LIMIT_EXCEEDED) to the source Locator.
The packet MUST be discarded.

Address Resolution

DNS AX Records A new DNS resource record type, AX, is defined to carry IPv4.5 addresses. An AX record contains a 96-bit IPv4.5 address in network byte order and supports standard TTL semantics identical to A and AAAA records. When A, AAAA, and AX records are all present, endpoints SHOULD use a Happy Eyeballs v3 algorithm (extending ) with AX as the highest-preference address family.

EID-Locator Mapping Service (ELMS) For EIDs not directly resolvable via DNS, ELMS provides Locator resolution. ELMS is a distributed, decentralized service. Three implementation architectures are defined:

Architecture 1 (LISP-Compatible): Follows the LISP Map-Server/Map-Resolver architecture .
Architecture 2 (DHT-Based): Implemented as a Kademlia-based distributed hash table. No central server is required.
Architecture 3 (BGP SAFI): EID-to-Locator mappings distributed via BGP using SAFI 144 (see ). Suitable for large ISP deployments.

ELMS resolution MUST be performed by the control-plane daemon. Results MUST be cached locally. ELMS queries MUST NOT block the forwarding fast path.

Control Plane

Session Establishment Overview IPv4.5 session establishment follows these steps:

The initiating endpoint resolves the target's Locator via DNS (AX record) or ELMS.
A HANDSHAKE packet (Type 1, Subtype 0x01 Client Hello) is sent to the target's Locator.
The responder processes the Client Hello and sends a HANDSHAKE reply (Subtype 0x02 Server Hello).
Both endpoints independently derive identical symmetric session keys using HKDF (see ).
Subsequent DATA packets (Type 0) are encrypted using the derived keys.

Intent Negotiation Protocol (INP) Endpoints MAY request specific session service characteristics through INP. INP operates at the session level only. Per-packet intent fields in the data plane are explicitly prohibited by this specification. INP SLA Classes

Class	Description	Authorization
BEST_EFFORT	Default forwarding treatment	None required
LOW_LATENCY	Expedited Forwarding treatment	Operator policy
HIGH_BANDWIDTH	Guaranteed bandwidth reservation	Operator policy
DETERMINISTIC	Hard real-time guarantee	Pre-arranged contract
BACKGROUND	Lower-than-default priority	None required

Endpoint Mobility When an endpoint changes its network attachment point (Locator), it MUST:

Generate a new IPv4.5 address using the same EID under the new Locator.
Send a CONTROL message (Mobility Notification) to active peers, conveying the new Locator.
Update its ELMS registration with the new Locator.

Existing session keys remain valid across a Locator change. Re-authentication is NOT required.

Identity Plane Identity authentication in IPv4.5 is OPTIONAL. When used, it occurs exclusively during the HANDSHAKE phase. The data plane MUST NOT carry identity assertions after handshake completion.

Anonymous Mode (Default) When no identity model is selected, the session uses only ephemeral EIDs (eNIDs) and ephemeral cryptographic key pairs. Anonymous mode is the DEFAULT and MUST be supported by all implementations.

X.509 PKI Mode Endpoints authenticate using X.509 certificates compatible with the existing Web PKI. This mode is RECOMMENDED for server-to-client authentication in public-facing services.

DID Mode Endpoints authenticate using W3C Decentralized Identifiers . DID documents are resolved from the decentralized identifier infrastructure; no certificate authority is required. This mode is OPTIONAL.

Pre-Shared Key (PSK) Mode Endpoints sharing a pre-established symmetric secret authenticate using PSK mode. PSK MUST be combined with the hybrid PQC key exchange () to preserve forward secrecy. RECOMMENDED for constrained IoT devices and closed enterprise deployments.

Cryptographic Plane

Hybrid Post-Quantum Handshake IPv4.5 session establishment uses a hybrid key exchange combining:

X25519 : Classical elliptic-curve Diffie-Hellman, providing security against classical computers.
ML-KEM-768 : NIST-standardized lattice-based Key Encapsulation Mechanism, providing security against quantum computers capable of running Shor's algorithm.

The hybrid construction ensures session key security as long as at least one of the two component algorithms remains unbroken.

Handshake Message Formats

Client Hello (Type 1, Subtype 0x01)

IPv4.5 Client Hello Message The total Client Hello size is approximately 1252 bytes before identity material, which exceeds the minimum Mode C MTU of 1232 bytes. Sending implementations MUST fragment the Client Hello using the Fragmentation Extension Header when the discovered path MTU is insufficient.

Server Hello (Type 1, Subtype 0x02)

IPv4.5 Server Hello Message

Key Derivation After the handshake exchange, both parties independently compute: The HKDF construction follows and Section 7.1. Labels are fixed ASCII strings. Implementations MUST verify that both X25519 and ML-KEM operations succeed before proceeding to data exchange.

Supported Cipher Suites IPv4.5 Cipher Suites

Code	Cipher Suite	Recommendation
0x01	AES-256-GCM	RECOMMENDED for hardware with AES-NI
0x02	ChaCha20-Poly1305	RECOMMENDED for software-only implementations
0x03-0xFF	—	Reserved

Both suites provide Authenticated Encryption with Associated Data (AEAD) as specified in .

Nonce Management The AEAD nonce (96 bits) for DATA packet protection is constructed as: The sequence number MUST start at 1 and MUST be incremented by 1 for each DATA packet transmitted. Implementations MUST initiate key rotation before the sequence number reaches 2^32. Nonces MUST NEVER be reused under the same session key.

Forward Secrecy and Key Rotation All session key material is derived from ephemeral key pairs generated fresh for each session. Long-term identity keys are used only to authenticate the handshake and are never used for encryption. Active sessions MUST be re-keyed upon whichever of the following thresholds occurs first:

3600 seconds (1 hour) of elapsed session time; or
2^32 DATA packets sent under the current session key.

Key material from the previous epoch MUST be explicitly zeroized using compiler-barrier-protected routines before being overwritten.

Backward Compatibility Considerations IPv4.5 provides transparent IPv4 transit, not full backward compatibility. Mode A traffic (pure IPv4) is entirely unaffected. Mode C traffic traverses unmodified IPv4 routers as standard UDP/4242 traffic. Firewalls blocking non-standard UDP ports may prevent IPv4.5 sessions. Implementations SHOULD attempt UDP/4242 first, and if blocked, retry using UDP/443. Operators deploying IPv4.5 SHOULD configure firewalls to permit inbound and outbound UDP/4242 during the transition period.

Privacy Considerations A static EID enables correlation of an endpoint's sessions across time and network positions, analogous to MAC address tracking. Implementations SHOULD use ephemeral EIDs (eNIDs) for user-facing applications. See . The Locator is carried in cleartext in the outer IPv4 header. The Site ID is carried in cleartext in the IPv4.5 fixed header. Both fields are observable to all on-path entities. No protection of Locator or Site ID confidentiality is provided by this specification. IPv4.5 does not protect against traffic analysis based on timing, packet sizes, or communication volumes. Applications requiring traffic analysis resistance SHOULD use Tor or mixnet overlays operating over IPv4.5 sessions.

Security Considerations

Threat Model This specification is designed to protect against: passive eavesdropping (including by future quantum computers via "harvest now, decrypt later"); active injection, modification, or replay of IPv4.5 packets; endpoint impersonation during session establishment; and session hijacking. This specification does NOT protect against: compromised endpoints; physical hardware access; legal compulsion of key material; traffic analysis; or vulnerabilities in cryptographic implementations.

Protections Provided Confidentiality: All DATA packets are protected by AEAD using session keys derived from the hybrid PQC handshake. Integrity: AEAD authentication detects and causes rejection of any modified, truncated, or corrupted DATA packet. Replay Protection: Monotonically increasing sequence numbers combined with AEAD authentication prevent replay. Forward Secrecy: Ephemeral key pairs ensure compromise of long-term key material does not expose past sessions. Quantum Resistance: The hybrid ML-KEM-768 + X25519 key exchange is secure against quantum computers running Shor's algorithm. Symmetric keys of 256 bits retain approximately 128 bits of security against Grover's algorithm. Endpoint Authentication (optional): When identity modes are used, signature algorithms SHOULD use ML-DSA-65 for quantum resistance.

Implementation Requirements Implementations MUST:

Use constant-time implementations for all cryptographic operations to prevent timing side-channel attacks.
Explicitly zeroize all key material after use using compiler-barrier-protected routines.
Validate all header fields in received packets before processing.
Implement PMTUD and respond to ICMP Fragmentation Needed.

Implementations MUST NOT:

Reuse AEAD nonces under any circumstances.
Continue data transmission after sequence number exhaustion without successful re-keying.
Log session key material in plaintext.

Denial-of-Service Considerations HANDSHAKE processing involves asymmetric cryptographic operations. Implementations SHOULD implement HANDSHAKE rate limiting (recommended: no more than 1000 new sessions per second per anchor) and SHOULD employ a lightweight proof-of-work or cookie mechanism to deter amplified HANDSHAKE flooding. ELMS deployments SHOULD use Anycast addressing, multi-tier caching with signed responses, and rate limiting of Map-Request messages per source address.

IANA Considerations

UDP Port Number IANA is requested to assign UDP port 4242 in the "Service Name and Transport Protocol Port Number Registry":

Service Name: ipv45
Transport Protocol: UDP
Port Number: 4242
Description: IPv4.5 Data Transport (Mode C encapsulation)
Assignee: N. Matsukami <info@insane-projects.com>
Reference: This document

IP Protocol Number IANA is requested to assign IP Protocol Number 144 in the "Assigned Internet Protocol Numbers" registry:

Decimal: 144
Keyword: IPv4.5
Protocol: Internet Protocol version 4.5
Reference: This document

DNS Resource Record Type IANA is requested to assign a new DNS RR type in the "Domain Name System (DNS) Parameters" registry:

Type: AX
Value: [to be assigned by IANA]
Meaning: IPv4.5 Address Record
Reference: This document

The wire format of the AX record carries a 96-bit IPv4.5 address in network byte order (12-byte RDATA field).

BGP Subsequent Address Family Identifier (SAFI) IANA is requested to assign SAFI value 144 in the "Subsequent Address Family Identifiers (SAFI) Parameters" registry:

Value: 144
Name: IPv4.5 EID-Locator Mapping
Reference: This document

IPv4.5 Packet Type Registry IANA is requested to create a new registry "IPv4.5 Packet Types" within a new "IPv4.5 Parameters" registry group. Future assignments in values 6-14 require Standards Action . IPv4.5 Packet Types (Initial Values)

Value	Name	Reference
0	DATA	This document
1	HANDSHAKE	This document
2	CONTROL	This document
3	ECHO	This document
4	ERROR	This document
5	KEEPALIVE	This document
6-14	Unassigned	Standards Action
15	Reserved	—

IPv4.5 Error Code Registry IANA is requested to create a new registry "IPv4.5 Error Codes" within the "IPv4.5 Parameters" registry group: IPv4.5 Error Codes (Initial Values)

Value	Name	Description
0	UNSPECIFIED	Unspecified error
1	HOP_LIMIT_EXCEEDED	Hop Limit reached zero
2	MTU_EXCEEDED	Packet exceeds path MTU
3	UNREACHABLE	Destination unreachable
4	AUTH_FAILED	Handshake authentication failure
5	POLICY_DENIED	INP policy rejection
6-255	Unassigned	Standards Action

References Normative References Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM) National Institute of Standards and Technology (NIST) Module-Lattice-Based Digital Signature Standard (ML-DSA) National Institute of Standards and Technology (NIST) Informative References Decentralized Identifiers (DIDs) v1.0 W3C Recommendation Kademlia: A Peer-to-peer Information System Based on the XOR Metric Proceedings of IPTPS 2002

Deployment Considerations

Phase 1 (2027-2030): Early Adoption IPv4.5 is deployed as a user-space overlay using Mode C encapsulation. No kernel changes are required. Day-one benefits include quantum-resistant session encryption, ephemeral EIDs for endpoint privacy, and global reachability without CGN for endpoints behind cooperative ISPs.

Phase 2 (2030-2035): Infrastructure Integration OS kernel integration, router support for ELMS BGP SAFI, and deployment of Edge Translators for IPv4 interoperability. ISPs offering native IPv4.5 addressing can eliminate CGN for IPv4.5- capable subscribers.

Phase 3 (2035+): Native Protocol IP Protocol 144 (Mode D) is assigned and native IPv4.5 forwarding is enabled in router hardware. IPv4 continues as the backward- compatible locator plane.

Open Issues

DNS AX Record Wire Format: A companion specification is needed for the complete AX record format, including DNSSEC signing.
TLS WG Coordination: Alignment with draft-ietf-tls-hybrid-design should be evaluated.
UDP/443 Fallback: The mechanism for detecting UDP/4242 blockage and falling back to UDP/443 needs specification.
Edge Translator HA: High-availability state synchronization for Edge Translators requires a separate specification.
ELMS DHT Specification: The Kademlia-based architecture requires a companion document.
Handshake Fragmentation: The Client Hello fragmentation strategy requires detailed specification for interoperability.
BGP-X Extensions: The BGP SAFI 144 specification requires a separate document.

Change Log

draft-matsukami-intarea-ipv45-00 Initial submission to the IETF Datatracker (April 2026).

Address space redesigned to globally unique 96-bit addresses with explicit Locator/Identifier separation.
Semantic communication, per-packet intent fields, mandatory DID/SSI, and per-packet PQC signatures removed from scope.
Backward compatibility claim refined to "transparent IPv4 transit" with four explicit operating modes (A through D).
Four-plane separation (data, control, identity, cryptographic) introduced.
Hybrid PQC (ML-KEM-768 + X25519 ) specified, referencing NIST FIPS 203 finalized August 2024.

Acknowledgements The author thanks the IETF int-area mailing list participants for their ongoing discussion of IPv4 transition mechanisms and addressing architecture. The Locator/Identifier separation concept builds directly on foundations laid by LISP and its successors . The QUIC protocol demonstrated that a new transport protocol can achieve wide deployment via UDP encapsulation and strongly influenced the Mode C design. The TLS 1.3 security model informed the session security architecture. The eNID privacy mechanism is modeled after IPv6 Privacy Extensions and Semantically Opaque Interface Identifiers .