Internet Area Working Group N. Matsukami Internet-Draft Independent Researcher Intended status: Standards Track 20 April 2026 Expires: 22 October 2026 IPv4.5: A Locator/Identifier-Separated Extension to IPv4 with Post- Quantum Session Security draft-matsukami-intarea-ipv45-00 Abstract 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 [FIPS203] and X25519 [RFC7748], 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. 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/. Matsukami Expires 22 October 2026 [Page 1] Internet-Draft IPv4.5 April 2026 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 22 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Relationship to Existing Work . . . . . . . . . . . . . . 5 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 7 3.1. Four-Plane Separation . . . . . . . . . . . . . . . . . . 7 3.2. Operating Modes . . . . . . . . . . . . . . . . . . . . . 8 4. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Address Format . . . . . . . . . . . . . . . . . . . . . 8 4.2. Address Allocation . . . . . . . . . . . . . . . . . . . 9 4.3. Textual Representation . . . . . . . . . . . . . . . . . 9 4.4. Reserved Addresses . . . . . . . . . . . . . . . . . . . 10 4.5. Ephemeral Endpoint Identifiers (eNIDs) . . . . . . . . . 10 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. IPv4.5 Fixed Header . . . . . . . . . . . . . . . . . . . 11 5.2. Field Descriptions . . . . . . . . . . . . . . . . . . . 11 5.3. Mode C Encapsulation . . . . . . . . . . . . . . . . . . 13 5.4. Extension Headers . . . . . . . . . . . . . . . . . . . . 14 5.5. Fragmentation Extension Header . . . . . . . . . . . . . 15 6. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 16 6.2. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 16 Matsukami Expires 22 October 2026 [Page 2] Internet-Draft IPv4.5 April 2026 6.3. Hop Limit Processing . . . . . . . . . . . . . . . . . . 16 7. Address Resolution . . . . . . . . . . . . . . . . . . . . . 16 7.1. DNS AX Records . . . . . . . . . . . . . . . . . . . . . 16 7.2. EID-Locator Mapping Service (ELMS) . . . . . . . . . . . 17 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Session Establishment Overview . . . . . . . . . . . . . 17 8.2. Intent Negotiation Protocol (INP) . . . . . . . . . . . . 18 8.3. Endpoint Mobility . . . . . . . . . . . . . . . . . . . . 18 9. Identity Plane . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Anonymous Mode (Default) . . . . . . . . . . . . . . . . 19 9.2. X.509 PKI Mode . . . . . . . . . . . . . . . . . . . . . 19 9.3. DID Mode . . . . . . . . . . . . . . . . . . . . . . . . 19 9.4. Pre-Shared Key (PSK) Mode . . . . . . . . . . . . . . . . 19 10. Cryptographic Plane . . . . . . . . . . . . . . . . . . . . . 19 10.1. Hybrid Post-Quantum Handshake . . . . . . . . . . . . . 19 10.2. Handshake Message Formats . . . . . . . . . . . . . . . 20 10.2.1. Client Hello (Type 1, Subtype 0x01) . . . . . . . . 20 10.2.2. Server Hello (Type 1, Subtype 0x02) . . . . . . . . 20 10.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 21 10.4. Supported Cipher Suites . . . . . . . . . . . . . . . . 21 10.5. Nonce Management . . . . . . . . . . . . . . . . . . . . 21 10.6. Forward Secrecy and Key Rotation . . . . . . . . . . . . 22 11. Backward Compatibility Considerations . . . . . . . . . . . . 22 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 13.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 23 13.2. Protections Provided . . . . . . . . . . . . . . . . . . 23 13.3. Implementation Requirements . . . . . . . . . . . . . . 23 13.4. Denial-of-Service Considerations . . . . . . . . . . . . 24 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 14.1. UDP Port Number . . . . . . . . . . . . . . . . . . . . 24 14.2. IP Protocol Number . . . . . . . . . . . . . . . . . . . 24 14.3. DNS Resource Record Type . . . . . . . . . . . . . . . . 25 14.4. BGP Subsequent Address Family Identifier (SAFI) . . . . 25 14.5. IPv4.5 Packet Type Registry . . . . . . . . . . . . . . 25 14.6. IPv4.5 Error Code Registry . . . . . . . . . . . . . . . 26 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 15.1. Normative References . . . . . . . . . . . . . . . . . . 27 15.2. Informative References . . . . . . . . . . . . . . . . . 28 Appendix A. Deployment Considerations . . . . . . . . . . . . . 30 A.1. Phase 1 (2027-2030): Early Adoption . . . . . . . . . . . 30 A.2. Phase 2 (2030-2035): Infrastructure Integration . . . . . 30 A.3. Phase 3 (2035+): Native Protocol . . . . . . . . . . . . 31 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 31 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 31 C.1. draft-matsukami-intarea-ipv45-00 . . . . . . . . . . . . 31 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 Matsukami Expires 22 October 2026 [Page 3] Internet-Draft IPv4.5 April 2026 1. Introduction 1.1. 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) [RFC6598] as a large-scale address sharing mechanism. While CGN preserves IPv4 reachability, it introduces the following well-documented problems: 1. Violation of the end-to-end principle: applications cannot rely on a globally unique, reachable address for each endpoint. 2. Peer-to-peer impairment: NAT traversal for real-time communication requires additional infrastructure such as STUN, TURN, and ICE. 3. Logging complexity: multiple subscribers share a single public IPv4 address at any given time, complicating forensic and legal demands. 4. Single point of failure: CGN appliances represent concentrated failure domains in operator networks. IPv6 [RFC8200] 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. 1.2. 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 Matsukami Expires 22 October 2026 [Page 4] Internet-Draft IPv4.5 April 2026 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 [FIPS203]. 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. 1.3. 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. 1.4. Relationship to Existing Work IPv4.5 is inspired by, but distinct from, the Locator/Identifier Separation Protocol (LISP) [RFC9300]. 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 [RFC9301] as one supported implementation of its EID-Locator Mapping Service. Matsukami Expires 22 October 2026 [Page 5] Internet-Draft IPv4.5 April 2026 The UDP encapsulation approach is analogous to QUIC [RFC9000], 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. 1.5. Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. 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. Matsukami Expires 22 October 2026 [Page 6] Internet-Draft IPv4.5 April 2026 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 [RFC8981] and Semantically Opaque Interface Identifiers [RFC7217]. 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). 3. Architecture Overview 3.1. Four-Plane Separation IPv4.5 is organized into four independent planes, each with a well- defined scope and interface boundary: +------------------+------------------+---------------------+ | Identity Plane | Control Plane | Cryptographic Plane | | (optional; | (ELMS, INP, | (ML-KEM-768 + | | handshake only) | mobility) | X25519, AEAD) | +------------------+------------------+---------------------+ | Data Plane (packet forwarding + AEAD protection) | +-----------------------------------------------------------+ Figure 1: 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. Matsukami Expires 22 October 2026 [Page 7] Internet-Draft IPv4.5 April 2026 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. 3.2. 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. 4. Addressing 4.1. Address Format An IPv4.5 address is 96 bits wide, consisting of three contiguous fields: Matsukami Expires 22 October 2026 [Page 8] Internet-Draft IPv4.5 April 2026 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Site Identifier (16 bits) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Endpoint Identifier (48 bits, continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: 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. 4.2. 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 [RFC4760]. 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 [RFC4086]. 4.3. 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: Matsukami Expires 22 October 2026 [Page 9] Internet-Draft IPv4.5 April 2026 192.0.2.1::1234::DEAD:BEEF:0001 Locator: 192.0.2.1 Site ID: 0x1234 Endpoint ID: 0xDEADBEEF0001 An implementation parsing an IPv4.5 address MUST reject strings that do not contain exactly two "::" separators. 4.4. Reserved Addresses The following addresses are reserved and MUST NOT be assigned to operational endpoints: +=======================+===================================+ | 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) | +-----------------------+-----------------------------------+ Table 1: IPv4.5 Reserved Addresses For Edge Translator (Mode B) operation, a pure IPv4 endpoint with address A.B.C.D behind translator at address T is represented as: T::FFFF::FFFF:: Example: IPv4 198.51.100.42 behind translator 203.0.113.1: 203.0.113.1::FFFF::FFFF:C633:642A 4.5. 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 [RFC4086]. Matsukami Expires 22 October 2026 [Page 10] Internet-Draft IPv4.5 April 2026 * 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. 5. Packet Format 5.1. 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. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver=1| Type | Hop Limit | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Flags | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Site ID (16 bits) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source Endpoint ID (48 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Site ID (16 bits) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination Endpoint ID (48 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: IPv4.5 Fixed Header (20 bytes) 5.2. 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: Matsukami Expires 22 October 2026 [Page 11] Internet-Draft IPv4.5 April 2026 +=======+===========+========================================+ | 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 Section 14.5 | +-------+-----------+----------------------------------------+ | 15 | — | Reserved; MUST NOT be used | +-------+-----------+----------------------------------------+ Table 2 Hop Limit (8 bits) Initialized to 64 by sending implementations. Each IPv4.5-aware forwarding node MUST decrement this field by 1. See Section 6.3. 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) Matsukami Expires 22 October 2026 [Page 12] Internet-Draft IPv4.5 April 2026 +=========+========+=============================================+ | 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 | +---------+--------+---------------------------------------------+ Table 3 Flow Label (16 bits) Identifies a traffic flow for ECMP load distribution and QoS treatment. When assigned by INP (Section 8.2), reflects the negotiated SLA class. Otherwise, MUST be set to a pseudorandom value. 5.3. Mode C Encapsulation In Mode C, an IPv4.5 packet is encapsulated in UDP [RFC0768] over IPv4 [RFC0791]: Matsukami Expires 22 October 2026 [Page 13] Internet-Draft IPv4.5 April 2026 +---------------------------------------------------+ | Outer IPv4 Header (20 bytes) | | IHL=5, Protocol=17 (UDP), TTL=64 | | DF=1 (Don't Fragment MUST be set) | | Src IP = Sending anchor Locator | | Dst IP = Receiving anchor Locator | +---------------------------------------------------+ | UDP Header (8 bytes) | | Src Port = 4242 (or ephemeral) | | Dst Port = 4242 | +---------------------------------------------------+ | IPv4.5 Fixed Header (20 bytes) | +---------------------------------------------------+ | Extension Headers (variable, optional) | +---------------------------------------------------+ | Upper-Layer Payload (variable) | +---------------------------------------------------+ Figure 4: IPv4.5 Mode C Packet Structure The outer IPv4 DF bit MUST be set to enable Path MTU Discovery (Section 6.1). The outer IP TTL SHOULD be set to 64. 5.4. Extension Headers Extension headers provide optional functionality. They are chained using the Next Header field and MUST be processed in the order they appear. Matsukami Expires 22 October 2026 [Page 14] Internet-Draft IPv4.5 April 2026 +=============+================+=================================+ | Next Header | Extension Type | Description | +=============+================+=================================+ | 0x00 | Hop-by-Hop | Options processed by every | | | Options | 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 processed only by the | | | Options | destination | +-------------+----------------+---------------------------------+ | 0xFF | No Next Header | No content follows | +-------------+----------------+---------------------------------+ Table 4: IPv4.5 Extension Header Types 5.5. Fragmentation Extension Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Reserved | Fragment Offset | Res |M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: IPv4.5 Fragmentation Extension Header (8 bytes) Fragment reassembly MUST time out after 60 seconds. Incomplete fragment sets MUST be silently discarded. 6. Forwarding Matsukami Expires 22 October 2026 [Page 15] Internet-Draft IPv4.5 April 2026 6.1. Path MTU Discovery All IPv4.5 implementations MUST support Path MTU Discovery (PMTUD) as defined in [RFC1191] and [RFC8201]. Implementations SHOULD also implement Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] 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: 1280 - 20 (outer IPv4) - 8 (UDP) - 20 (IPv4.5) = 1232 bytes 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). 6.2. 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. 6.3. 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: 1. The node MUST NOT forward the packet. 2. The node SHOULD send an IPv4.5 ERROR message (Type 4, Error Code HOP_LIMIT_EXCEEDED) to the source Locator. 3. The packet MUST be discarded. 7. Address Resolution 7.1. 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. Matsukami Expires 22 October 2026 [Page 16] Internet-Draft IPv4.5 April 2026 host.example.com. 3600 IN AX 192.0.2.1::0100::DEAD:BEEF:0001 host.example.com. 3600 IN A 192.0.2.1 host.example.com. 3600 IN AAAA 2001:db8::1 When A, AAAA, and AX records are all present, endpoints SHOULD use a Happy Eyeballs v3 algorithm (extending [RFC8305]) with AX as the highest-preference address family. 7.2. 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 [RFC9300] [RFC9301]. Architecture 2 (DHT-Based) Implemented as a Kademlia-based [KADEMLIA] distributed hash table. No central server is required. Architecture 3 (BGP SAFI) EID-to-Locator mappings distributed via BGP using SAFI 144 (see Section 14.4). 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. 8. Control Plane 8.1. Session Establishment Overview IPv4.5 session establishment follows these steps: 1. The initiating endpoint resolves the target's Locator via DNS (AX record) or ELMS. 2. A HANDSHAKE packet (Type 1, Subtype 0x01 Client Hello) is sent to the target's Locator. 3. The responder processes the Client Hello and sends a HANDSHAKE reply (Subtype 0x02 Server Hello). 4. Both endpoints independently derive identical symmetric session keys using HKDF (see Section 10.3). Matsukami Expires 22 October 2026 [Page 17] Internet-Draft IPv4.5 April 2026 5. Subsequent DATA packets (Type 0) are encrypted using the derived keys. 8.2. 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. +================+================================+=================+ | Class | Description | Authorization | +================+================================+=================+ | BEST_EFFORT | Default forwarding treatment | None required | +----------------+--------------------------------+-----------------+ | LOW_LATENCY | Expedited Forwarding treatment | Operator | | | | policy | +----------------+--------------------------------+-----------------+ | HIGH_BANDWIDTH | Guaranteed bandwidth | Operator | | | reservation | policy | +----------------+--------------------------------+-----------------+ | DETERMINISTIC | Hard real-time guarantee | Pre-arranged | | | | contract | +----------------+--------------------------------+-----------------+ | BACKGROUND | Lower-than-default priority | None required | +----------------+--------------------------------+-----------------+ Table 5: INP SLA Classes 8.3. Endpoint Mobility When an endpoint changes its network attachment point (Locator), it MUST: 1. Generate a new IPv4.5 address using the same EID under the new Locator. 2. Send a CONTROL message (Mobility Notification) to active peers, conveying the new Locator. 3. Update its ELMS registration with the new Locator. Existing session keys remain valid across a Locator change. Re- authentication is NOT required. Matsukami Expires 22 October 2026 [Page 18] Internet-Draft IPv4.5 April 2026 9. 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. 9.1. 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. 9.2. X.509 PKI Mode Endpoints authenticate using X.509 certificates [RFC5280] compatible with the existing Web PKI. This mode is RECOMMENDED for server-to- client authentication in public-facing services. 9.3. DID Mode Endpoints authenticate using W3C Decentralized Identifiers [W3C-DID]. DID documents are resolved from the decentralized identifier infrastructure; no certificate authority is required. This mode is OPTIONAL. 9.4. 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 (Section 10) to preserve forward secrecy. RECOMMENDED for constrained IoT devices and closed enterprise deployments. 10. Cryptographic Plane 10.1. Hybrid Post-Quantum Handshake IPv4.5 session establishment uses a hybrid key exchange combining: * *X25519* [RFC7748]: Classical elliptic-curve Diffie-Hellman, providing security against classical computers. * *ML-KEM-768* [FIPS203]: 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. Matsukami Expires 22 October 2026 [Page 19] Internet-Draft IPv4.5 April 2026 10.2. Handshake Message Formats 10.2.1. Client Hello (Type 1, Subtype 0x01) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype=0x01 | Identity Type | Cipher Suite (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client Random Nonce (32 bytes) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | X25519 Ephemeral Public Key (32 bytes) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ML-KEM-768 Public Key (1184 bytes) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identity Material (variable, type-dependent) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: 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. 10.2.2. Server Hello (Type 1, Subtype 0x02) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype=0x02 |Selected Cipher| Session ID (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Random Nonce (32 bytes) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | X25519 Ephemeral Public Key (32 bytes) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ML-KEM-768 Ciphertext (1088 bytes) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identity Material + Signature (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Matsukami Expires 22 October 2026 [Page 20] Internet-Draft IPv4.5 April 2026 Figure 7: IPv4.5 Server Hello Message 10.3. Key Derivation After the handshake exchange, both parties independently compute: shared_x25519 = X25519(local_eph_priv, remote_eph_pub) [32 bytes] shared_kem = ML-KEM-768.Decapsulate(ct, local_mlkem_priv) [32 bytes] ikm = shared_x25519 || shared_kem [64 bytes] salt = client_nonce || server_nonce [64 bytes] tx_key = HKDF-SHA-256(ikm, salt, "IPv4.5-C2S-KEY-v1", 32) [32 bytes] rx_key = HKDF-SHA-256(ikm, salt, "IPv4.5-S2C-KEY-v1", 32) [32 bytes] The HKDF construction follows [RFC5116] and [RFC8446] Section 7.1. Labels are fixed ASCII strings. Implementations MUST verify that both X25519 and ML-KEM operations succeed before proceeding to data exchange. 10.4. Supported 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 | +-----------+-------------------+---------------------------+ Table 6: IPv4.5 Cipher Suites Both suites provide Authenticated Encryption with Associated Data (AEAD) as specified in [RFC5116]. 10.5. Nonce Management The AEAD nonce (96 bits) for DATA packet protection is constructed as: nonce = session_id (16) || reserved (16) || sequence_no (64) Matsukami Expires 22 October 2026 [Page 21] Internet-Draft IPv4.5 April 2026 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. 10.6. 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. 11. 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. 12. 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 Section 4.5. 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. Matsukami Expires 22 October 2026 [Page 22] Internet-Draft IPv4.5 April 2026 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. 13. Security Considerations 13.1. 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. 13.2. 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 [FIPS204] for quantum resistance. 13.3. Implementation Requirements Implementations MUST: * Use constant-time implementations for all cryptographic operations to prevent timing side-channel attacks. Matsukami Expires 22 October 2026 [Page 23] Internet-Draft IPv4.5 April 2026 * 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. 13.4. 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. 14. IANA Considerations 14.1. 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 * Reference: This document 14.2. IP Protocol Number IANA is requested to assign IP Protocol Number 144 in the "Assigned Internet Protocol Numbers" registry: * Decimal: 144 Matsukami Expires 22 October 2026 [Page 24] Internet-Draft IPv4.5 April 2026 * Keyword: IPv4.5 * Protocol: Internet Protocol version 4.5 * Reference: This document 14.3. 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). 14.4. 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 14.5. 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 [RFC8126]. Matsukami Expires 22 October 2026 [Page 25] Internet-Draft IPv4.5 April 2026 +=======+============+==================+ | 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 | — | +-------+------------+------------------+ Table 7: IPv4.5 Packet Types (Initial Values) 14.6. IPv4.5 Error Code Registry IANA is requested to create a new registry "IPv4.5 Error Codes" within the "IPv4.5 Parameters" registry group: +=======+====================+==================================+ | 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 | +-------+--------------------+----------------------------------+ Table 8: IPv4.5 Error Codes (Initial Values) Matsukami Expires 22 October 2026 [Page 26] Internet-Draft IPv4.5 April 2026 15. References 15.1. Normative References [FIPS203] National Institute of Standards and Technology (NIST), "Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)", NIST FIPS 203, August 2024, . [FIPS204] National Institute of Standards and Technology (NIST), "Module-Lattice-Based Digital Signature Standard (ML- DSA)", NIST FIPS 204, August 2024, . [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . Matsukami Expires 22 October 2026 [Page 27] Internet-Draft IPv4.5 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, . [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, . [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [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, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., "The Locator/ID Separation Protocol (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022, . [RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., "Locator/ID Separation Protocol (LISP) Control Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022, . 15.2. Informative References [KADEMLIA] Maymounkov, P. and D. Mazieres, "Kademlia: A Peer-to-peer Information System Based on the XOR Metric", Proceedings of IPTPS 2002, 2002. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . Matsukami Expires 22 October 2026 [Page 28] Internet-Draft IPv4.5 April 2026 [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [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, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [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, . [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2012, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . Matsukami Expires 22 October 2026 [Page 29] Internet-Draft IPv4.5 April 2026 [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, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., "Geneve: Generic Network Virtualization Encapsulation", RFC 8926, DOI 10.17487/RFC8926, November 2020, . [RFC9299] Cabellos, A. and D. Saucez, Ed., "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", RFC 9299, DOI 10.17487/RFC9299, October 2022, . [W3C-DID] Sporny, M., Guy, A., Sabadello, M., and D. Reed, "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, July 2022, . Appendix A. Deployment Considerations A.1. 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. A.2. 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. Matsukami Expires 22 October 2026 [Page 30] Internet-Draft IPv4.5 April 2026 A.3. 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. Appendix B. Open Issues 1. DNS AX Record Wire Format: A companion specification is needed for the complete AX record format, including DNSSEC signing. 2. TLS WG Coordination: Alignment with draft-ietf-tls-hybrid-design should be evaluated. 3. UDP/443 Fallback: The mechanism for detecting UDP/4242 blockage and falling back to UDP/443 needs specification. 4. Edge Translator HA: High-availability state synchronization for Edge Translators requires a separate specification. 5. ELMS DHT Specification: The Kademlia-based architecture requires a companion document. 6. Handshake Fragmentation: The Client Hello fragmentation strategy requires detailed specification for interoperability. 7. BGP-X Extensions: The BGP SAFI 144 specification requires a separate document. Appendix C. Change Log C.1. 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. Matsukami Expires 22 October 2026 [Page 31] Internet-Draft IPv4.5 April 2026 * Hybrid PQC (ML-KEM-768 [FIPS203] + X25519 [RFC7748]) 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 [RFC6830] and its successors [RFC9300] [RFC9301]. The QUIC protocol [RFC9000] 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 [RFC8446] informed the session security architecture. The eNID privacy mechanism is modeled after IPv6 Privacy Extensions [RFC8981] and Semantically Opaque Interface Identifiers [RFC7217]. Author's Address Nao Matsukami Independent Researcher Email: info@insane-projects.com Matsukami Expires 22 October 2026 [Page 32]