Network Working Group J. Thain Internet-Draft One Limited Intended status: Standards Track 14 April 2026 Expires: 16 October 2026 Internet Protocol Version 8 (IPv8) draft-thain-ipv8-00 Abstract Internet Protocol Version 8 (IPv8) is a managed network protocol suite that transforms how networks of every scale -- from home networks to the global internet -- are operated, secured, and monitored. Every manageable element in an IPv8 network is authorised via OAuth2 JWT tokens served from a local cache. Every service a device requires is delivered in a single DHCP8 lease response. Every packet transiting to the internet is validated at egress against a DNS8 lookup and a WHOIS8 registered active route. Network telemetry, authentication, name resolution, time synchronisation, access control, and translation are unified into a single coherent Zone Server platform. IPv4 is a proper subset of IPv8. An IPv8 address with the routing prefix field set to zero is an IPv4 address. No existing device, application, or network requires modification. The suite is 100% backward compatible. There is no flag day and no forced migration at any layer. IPv8 also resolves IPv4 address exhaustion. Each Autonomous System Number (ASN) holder receives 4,294,967,296 host addresses. The global routing table is structurally bounded at one entry per ASN. This document is one of the companion specifications: * draft-thain-ipv8-00 Core protocol (this document) * draft-thain-routing-protocols-00 BGP8, IBGP8, OSPF8, IS-IS8, CF * draft-thain-rine-00 Regional Inter-Network Exchange * draft-thain-zoneserver-00 Zone Server Architecture * draft-thain-whois8-00 WHOIS8 Protocol * draft-thain-netlog8-00 NetLog8 Protocol * draft-thain-support8-00 ARP8, ICMPv8, Route8 * draft-thain-ipv8-mib-00 IPv8 MIB and SNMPv8 * draft-thain-wifi8-00 WiFi8 Protocol * draft-thain-update8-00 Update8 and NIC Certification Thain Expires 16 October 2026 [Page 1] Internet-Draft IPv8 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 16 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. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. The Network Management Problem . . . . . . . . . . . . . 4 1.3. The IPv8 Management Philosophy . . . . . . . . . . . . . 5 1.4. East-West and North-South Security . . . . . . . . . . . 6 1.5. Address Exhaustion . . . . . . . . . . . . . . . . . . . 7 1.6. Routing Protocol Improvements . . . . . . . . . . . . . . 7 1.7. Backward Compatibility and Transition . . . . . . . . . . 8 2. Motivation and Problem Statement . . . . . . . . . . . . . . 8 2.1. Management Fragmentation . . . . . . . . . . . . . . . . 8 2.2. Address Exhaustion . . . . . . . . . . . . . . . . . . . 9 2.3. Routing Table Growth . . . . . . . . . . . . . . . . . . 9 2.4. Requirements for a Viable Successor . . . . . . . . . . . 9 3. IPv8 Address Format . . . . . . . . . . . . . . . . . . . . . 10 3.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 10 Thain Expires 16 October 2026 [Page 2] Internet-Draft IPv8 April 2026 3.2. Address Space . . . . . . . . . . . . . . . . . . . . . . 10 3.3. IPv4 Representation in IPv8 . . . . . . . . . . . . . . . 10 3.4. ASN Encoding in r.r.r.r . . . . . . . . . . . . . . . . . 10 3.5. Internal Zone Prefix (127.0.0.0/8) . . . . . . . . . . . 11 3.6. Inter-Company Interop Prefix (127.127.0.0) . . . . . . . 11 3.7. Two-XLATE8 Interop Model . . . . . . . . . . . . . . . . 11 3.8. Private Interop ASN (ASN 65534) . . . . . . . . . . . . . 12 3.9. RINE Peering Prefix (100.0.0.0/8) . . . . . . . . . . . . 12 3.10. Interior Link Convention (222.0.0.0/8) . . . . . . . . . 12 3.11. Address Usage Model . . . . . . . . . . . . . . . . . . . 13 4. Address Classes . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. IPv8 Packet Header . . . . . . . . . . . . . . . . . . . . . 15 5.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Socket API Compatibility . . . . . . . . . . . . . . . . 16 6. ASN Dot Notation . . . . . . . . . . . . . . . . . . . . . . 16 7. DNS A8 Record Type . . . . . . . . . . . . . . . . . . . . . 16 8. Routing Protocol Behaviour . . . . . . . . . . . . . . . . . 16 8.1. Mandatory Routing Protocols . . . . . . . . . . . . . . . 17 8.2. Deprecated Routing Protocols . . . . . . . . . . . . . . 17 8.3. eBGP8 - Mandatory Exterior Gateway Protocol . . . . . . . 17 8.4. IBGP8 - Inter-Zone Routing . . . . . . . . . . . . . . . 18 8.5. OSPF8 - Intra-Zone Routing . . . . . . . . . . . . . . . 18 8.6. IS-IS8 - Optional Interior Gateway Protocol . . . . . . . 18 8.7. Two-Tier Routing Table . . . . . . . . . . . . . . . . . 18 8.8. VRF - Virtual Routing and Forwarding . . . . . . . . . . 18 9. ICMPv8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Intra-ASN Multicast . . . . . . . . . . . . . . . . . . 19 10.2. Cross-ASN Multicast . . . . . . . . . . . . . . . . . . 19 10.3. Cross-ASN Multicast Group Assignments . . . . . . . . . 19 11. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. Compatibility and Transition . . . . . . . . . . . . . . . . 20 13.1. Single Stack Operation . . . . . . . . . . . . . . . . . 20 13.2. IPv4 Network Compatibility . . . . . . . . . . . . . . . 20 13.3. 8to4 - IPv8 Across IPv4-Only Networks . . . . . . . . . 20 13.4. Transition Sequence . . . . . . . . . . . . . . . . . . 20 14. CGNAT Behaviour . . . . . . . . . . . . . . . . . . . . . . . 20 15. Application Compatibility . . . . . . . . . . . . . . . . . . 20 16. Cloud Provider Applicability . . . . . . . . . . . . . . . . 21 17. Device Compliance Tiers . . . . . . . . . . . . . . . . . . . 21 17.1. Tier 1 - End Device . . . . . . . . . . . . . . . . . . 21 17.2. Tier 2 - L2 Network Device . . . . . . . . . . . . . . . 21 17.3. Tier 3 - L3 Network Device . . . . . . . . . . . . . . . 21 17.4. Spanning Tree - PVRST Mandatory . . . . . . . . . . . . 21 17.5. NIC Rate Limits . . . . . . . . . . . . . . . . . . . . 22 18. Security Considerations . . . . . . . . . . . . . . . . . . . 22 Thain Expires 16 October 2026 [Page 3] Internet-Draft IPv8 April 2026 18.1. ASN Prefix Spoofing . . . . . . . . . . . . . . . . . . 22 18.2. Internal Zone Prefix Protection . . . . . . . . . . . . 22 18.3. RINE Prefix Protection . . . . . . . . . . . . . . . . . 22 18.4. Interior Link Convention Protection . . . . . . . . . . 22 18.5. RFC 1918 Address Privacy . . . . . . . . . . . . . . . . 22 18.6. Cross-ASN Multicast Filtering . . . . . . . . . . . . . 23 18.7. /16 Minimum Prefix Enforcement . . . . . . . . . . . . . 23 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 19.1. IP Version Number . . . . . . . . . . . . . . . . . . . 23 19.2. Internal Zone Prefix Reservation . . . . . . . . . . . . 23 19.3. RINE Prefix Reservation . . . . . . . . . . . . . . . . 23 19.4. Interior Link Convention . . . . . . . . . . . . . . . . 23 19.5. Cross-ASN Multicast Range . . . . . . . . . . . . . . . 23 19.6. Broadcast Reservation . . . . . . . . . . . . . . . . . 23 19.7. DNS A8 Record Type . . . . . . . . . . . . . . . . . . . 24 19.8. Multicast Group Assignments . . . . . . . . . . . . . . 24 19.9. Private ASN Reservations . . . . . . . . . . . . . . . . 24 20. Informative References . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction 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. The Network Management Problem Modern network management is characterised by fragmentation. DHCP, DNS, NTP, logging, monitoring, and authentication are separate products, separately licensed, separately configured, and separately maintained with no shared awareness of network state. A device connecting to a network may require manual configuration of a dozen independent services before it is operational. Security is inconsistent -- some services are authenticated, others are not. Failures require correlating data across systems that were never designed to work together. Thain Expires 16 October 2026 [Page 4] Internet-Draft IPv8 April 2026 This fragmentation scales with every device added. Small networks cannot afford the operational complexity. Large networks cannot afford the inconsistency. The global internet has no coherent mechanism to validate that advertised routes are legitimately held by their advertisers, or that packets transiting to external destinations have been validated against any registry of active routes. IPv6 [RFC8200] addressed address exhaustion but did not address management fragmentation. After 25 years of deployment effort IPv6 carries a minority of global internet traffic. The operational cost of the dual-stack transition model, combined with the absence of management improvement, proved commercially unacceptable. IPv8 addresses both problems simultaneously. 1.3. The IPv8 Management Philosophy The central operational concept in IPv8 is the Zone Server -- a paired active/active platform that runs every service a network segment requires: address assignment (DHCP8), name resolution (DNS8), time synchronisation (NTP8), telemetry collection (NetLog8), authentication caching (OAuth8), route validation (WHOIS8 resolver), access control enforcement (ACL8), and IPv4/IPv8 translation (XLATE8). A device connecting to an IPv8 network sends one DHCP8 Discover and receives one response containing every service endpoint it requires. No subsequent manual configuration is needed for any service. The device is fully operational -- authenticated, logged, time- synchronised, zone-policy-enforced -- before its first user interaction. Every manageable element in an IPv8 network is authorised via OAuth2 JWT tokens [RFC7519]. Tokens are validated locally by the OAuth8 cache on the Zone Server without round trips to external identity providers. A device in a remote location with a temporarily unreachable cloud identity provider continues to authenticate normally -- the OAuth8 cache holds all public keys and validates signatures locally in sub- millisecond time. JWT tokens may be served by a local OAuth2 authority (home router operating in local authority mode) or by a cached enterprise OAuth2 provider. Authentication is universal, consistent, and requires no per-service credential management. Firmware and software updates for L1-L4 stack components are managed via the Update8 protocol [UPDATE8]. Update8 defines a standard vendor feed format, Zone Server validated proxy, optional local Thain Expires 16 October 2026 [Page 5] Internet-Draft IPv8 April 2026 caching, device criticality-based scheduling, and rollback prevention enforced in NIC hardware. Devices receive updates only from DNS- named sources validated by the Zone Server. Connection to an update source identified by IP address is blocked by default. The 127.0.0.0/8 r.r.r.r range is permanently reserved as the IPv8 internal zone prefix space. Organisations assign internal zone prefixes (127.1.0.0, 127.2.0.0 etc) to network zones and regions. Internal zone addresses are never routed externally. No address conflict between zones is possible. An organisation may build a network of arbitrary geographic and organisational scale -- with dozens of regional zones, each containing thousands of devices -- using familiar routing protocols without any external address coordination. 1.4. East-West and North-South Security IPv8 addresses two distinct traffic security problems: *East-west security* -- traffic between devices within a network -- is enforced by ACL8 zone isolation. Devices communicate only with their designated service gateway. The service gateway communicates only with the designated cloud service. Lateral movement between devices or zones is architecturally prevented by the absence of any permitted route to any other destination. Three independent enforcement layers provide defence in depth: NIC firmware ACL8, Zone Server gateway ACL8, and switch port OAuth2 hardware VLAN enforcement. *North-south security* -- traffic from internal devices to the internet -- is enforced at the Zone Server egress by two mandatory validation steps. First, every outbound connection must have a corresponding DNS8 lookup -- no DNS lookup means no XLATE8 state table entry means the connection is blocked. Second, the destination ASN is validated against the WHOIS8 registry -- if the destination prefix is not registered as an active route by a legitimately registered ASN holder the packet is dropped. These two steps together eliminate the primary malware command-and-control channel: connection to hardcoded IP addresses without DNS resolution. At the global routing level, BGP8 route advertisements are validated against WHOIS8 before installation in the routing table. A route that cannot be validated is not installed. Manual bogon filter list maintenance is eliminated. Prefix hijacking is architecturally difficult -- an attacker must compromise both an RIR registry entry and produce a validly signed WHOIS8 record. Thain Expires 16 October 2026 [Page 6] Internet-Draft IPv8 April 2026 1.5. Address Exhaustion IANA completed allocation of the IPv4 unicast address space in February 2011. CGNAT has extended IPv4 life but introduces latency, breaks peer-to-peer protocols, and complicates troubleshooting. The address exhaustion problem is architectural and cannot be resolved within the 32-bit IPv4 address space. IPv8 resolves address exhaustion as a consequence of its addressing architecture, not as a primary design goal. The 64-bit IPv8 address space provides 2^64 unique addresses. Each ASN holder receives 2^32 host addresses -- 4,294,967,296 addresses -- sufficient for any organisation at any scale without address exhaustion, CGNAT, or renumbering. IPv4 is a proper subset of IPv8. An IPv8 address with r.r.r.r = 0.0.0.0 is an IPv4 address, processed by standard IPv4 rules. No existing device, application, or network requires modification to participate in an IPv8 network. The suite is 100% backward compatible. There is no flag day and no forced migration at any layer. The global BGP8 routing table is structurally bounded at one entry per ASN. The /16 minimum injectable prefix rule prevents deaggregation. Most carriers advertise a single /8 summary route per regional ASN. The BGP4 routing table exceeded 900,000 prefixes with no architectural bound. The BGP8 routing table is bounded by ASN allocation rate -- approximately 175,000 entries today. 1.6. Routing Protocol Improvements IPv8 extends OSPF8 [RFC2328], BGP8 [RFC4271] (both iBGP8 and eBGP8), and IS-IS8 with a unified path quality metric -- the Cost Factor (CF). CF is a 32-bit accumulated metric derived from seven components measured from TCP session telemetry: round trip time, packet loss, congestion window state, session stability, link capacity, economic policy, and geographic distance as a physics floor. CF accumulates across every BGP8 hop from source to destination. Every router independently selects the path with the lowest accumulated CF without coordination. CF combines the dynamic composite path quality of EIGRP, the accumulated cost model of OSPF, and proportional load balancing across multiple paths -- in a single open versioned algorithm that operates end-to-end across AS boundaries. OSPF and EIGRP stop at the AS boundary. CF does not. Thain Expires 16 October 2026 [Page 7] Internet-Draft IPv8 April 2026 The geographic component of CF sets a physics floor -- no path can appear better than the speed of light over the great circle distance allows. A path that measures faster than physics permits is flagged immediately as a CF anomaly. CF is an open versioned algorithm. CFv1 is the mandatory baseline. Future versions may add carbon cost, jitter, time of day, and application layer latency signals through the IETF process. 1.7. Backward Compatibility and Transition IPv4 is a proper subset of IPv8: IPv8 address with r.r.r.r = 0.0.0.0 = IPv4 address Processed by standard IPv4 rules No modification to IPv4 device required No modification to IPv4 application required No modification to IPv4 internal network required IPv8 does not require dual-stack operation. There is no flag day. 8to4 tunnelling enables IPv8 islands separated by IPv4- only transit networks to communicate immediately. CF naturally incentivises IPv4 transit ASNs to upgrade by measuring higher latency on 8to4 paths -- an automatic economic signal without any mandate. Transition phases are independent. Tier 1 ISPs, cloud providers, enterprises, and consumer ISPs may adopt IPv8 in any order and at any pace. 8to4 ensures interoperability throughout. 2. Motivation and Problem Statement 2.1. Management Fragmentation IPv4 network management has no coherent integrated model. The protocols that operate a network -- DHCP, DNS, NTP, syslog, SNMP, authentication -- were specified independently over four decades, share no common identity model, no common authentication mechanism, and no common telemetry format. The consequences are operational: networks require specialist knowledge of each protocol independently. Security is inconsistent -- some services require authentication, others accept unauthenticated requests from any source. Failures require correlating logs across systems with different timestamp formats, different severity models, and different identity representations. Management scales with operational burden, not with network size. Thain Expires 16 October 2026 [Page 8] Internet-Draft IPv8 April 2026 IPv8 addresses this by defining a coherent management suite in which every service shares a common identity model (OAuth2 JWT), a common delivery mechanism (DHCP8), a common telemetry format (NetLog8), and a common authentication cache (OAuth8). 2.2. Address Exhaustion IANA completed allocation of the IPv4 unicast address space in February 2011. Regional Internet Registries exhausted their allocations between 2011 and 2020. CGNAT extended IPv4 life at the cost of latency, peer-to-peer protocol breakage, and troubleshooting complexity. IPv6 [RFC8200] was developed to address exhaustion. After 25 years of standardisation and deployment effort IPv6 carries a minority of global internet traffic. The dual-stack transition model -- requiring every device, application, and network to simultaneously support both protocols -- proved commercially unacceptable. The absence of a forcing function meant organisations could continue with CGNAT indefinitely. IPv8 resolves address exhaustion without dual-stack operation. IPv4 is a proper subset of IPv8. The transition requires no flag day and creates no operational discontinuity. 2.3. Routing Table Growth The BGP4 global routing table exceeded 900,000 prefixes in 2024 and grows without architectural bound. Prefix deaggregation -- advertising more specific prefixes to influence traffic engineering -- is the primary driver of growth. No protocol mechanism prevents it. BGP4 has no binding relationship between what an ASN advertises and what it is authorised to advertise. Prefix hijacking, route leaks, and bogon injection are possible because there is no route ownership registry that border routers enforce as a condition of route acceptance. IPv8 addresses both problems. The /16 minimum injectable prefix rule prevents deaggregation at inter-AS boundaries. WHOIS8 mandatory route validation creates a binding relationship between BGP8 advertisements and registered route ownership. The global BGP8 routing table is structurally bounded at one entry per ASN. 2.4. Requirements for a Viable Successor Thain Expires 16 October 2026 [Page 9] Internet-Draft IPv8 April 2026 * R1. Integrated management -- common identity, authentication, telemetry, and service delivery across all network services. * R2. Single stack operation -- no dual-stack requirement. * R3. Full backward compatibility -- existing IPv4 applications unchanged. IPv4 is a proper subset of IPv8. * R4. Full backward compatibility -- RFC 1918 internal networks unchanged. * R5. Full backward compatibility -- CGNAT deployments unchanged. * R6. Vastly expanded address space. * R7. Implementable as a software update without hardware replacement. * R8. Human readable addressing consistent with IPv4 operator familiarity. * R9. East-west and north-south traffic security enforced by protocol, not by manual configuration. * R10. Structurally bounded global routing table. IPv8 satisfies all ten requirements. 3. IPv8 Address Format 3.1. Structure An IPv8 address is a 64-bit value: r.r.r.r.n.n.n.n * *r.r.r.r* -- 32-bit ASN Routing Prefix * *n.n.n.n* -- 32-bit Host Address (identical semantics to IPv4) 3.2. Address Space 2^64 = 18,446,744,073,709,551,616 unique addresses. 2^32 ASN prefixes x 2^32 host addresses per ASN. 3.3. IPv4 Representation in IPv8 0.0.0.0.n.n.n.n Packets with r.r.r.r = 0.0.0.0 MUST be routed using standard IPv4 rules applied to the n.n.n.n field. IPv4 is a proper subset of IPv8. No modification to IPv4 devices, applications, or networks is required. 3.4. ASN Encoding in r.r.r.r The 32-bit ASN is encoded directly into r.r.r.r as a 32-bit unsigned integer in network byte order: Thain Expires 16 October 2026 [Page 10] Internet-Draft IPv8 April 2026 ASN 64496 (Example-A) = 0.0.251.240 ASN 64497 (Example-B) = 0.0.251.241 ASN 64498 (Example-C) = 0.0.251.242 3.5. Internal Zone Prefix (127.0.0.0/8) The 127.0.0.0/8 range of the r.r.r.r field is permanently reserved for internal IPv8 zone prefixes. Internal zone prefixes identify network zones within an organisation's private addressing space. 127.x.x.x.n.n.n.n Where x.x.x identifies the internal zone. Examples: 127.1.0.0.n.n.n.n Internal zone 1 (e.g. Americas) 127.2.0.0.n.n.n.n Internal zone 2 (e.g. Europe) 127.3.0.0.n.n.n.n Internal zone 3 (e.g. Asia Pacific) Internal zone prefix rules: * MUST NOT be routed externally beyond the organisation's AS boundary. * MUST NOT appear on WAN interfaces or public internet links. * MUST NOT be used in eBGP8 advertisements. * MAY be used freely within an organisation's internal routing infrastructure via OSPF8, IS-IS8, and IBGP8. * Provides 2^56 effective internal addresses across all zone prefixes. No internal address conflict is possible between zones. * Enables organisations to build geographically distributed, region- routed private networks of arbitrary scale without external address coordination. ASN numbers that encode to the 127.0.0.0/8 range in the r.r.r.r field (ASN 2130706432 through ASN 2147483647) are reserved for internal zone use and MUST NOT be allocated by IANA for public internet routing. 3.6. Inter-Company Interop Prefix (127.127.0.0) The 127.127.0.0 prefix is reserved as the standard inter- company interoperability DMZ. When two organisations need to interconnect without exposing their internal zone addressing, both deploy XLATE8 engines facing a shared 127.127.0.0 address space. Full specification in [ZONESERVER] Section 16.9. 3.7. Two-XLATE8 Interop Model Thain Expires 16 October 2026 [Page 11] Internet-Draft IPv8 April 2026 Company A Company B --------- --------- 127.1.0.0.x XLATE8-A 127.127.0.0 XLATE8-B 127.2.0.0.x Properties: * Company A never sees Company B's 127.2.0.0 addresses. * Company B never sees Company A's 127.1.0.0 addresses. * Each company controls exactly what it exposes. * No address overlap possible. No NAT complexity. * Setup time: minutes per service exposed. 3.8. Private Interop ASN (ASN 65534) ASN 65534 is reserved for private inter-company BGP8 peering consistent with [RFC6996]: 0.0.255.254.x.x.x.x ASN 65533 (0.0.255.253.x.x.x.x) is reserved for documentation and testing purposes. 3.9. RINE Peering Prefix (100.0.0.0/8) The 100.0.0.0/8 range of the r.r.r.r field is permanently reserved for the Regional Inter-Network Exchange (RINE) peering fabric. RINE addresses are used exclusively for AS-to-AS peering link addressing at IXPs and private interconnect facilities. Full specification in [RINE]. RINE addresses: * MUST NOT be advertised in the global BGP8 routing table. * MUST NOT be assigned to end devices. * MUST be filtered at all eBGP8 border routers. 3.10. Interior Link Convention (222.0.0.0/8) The n.n.n.n range 222.0.0.0/8 is the well-known IPv8 interior link address convention. Every AS MAY use .222.x.x.x for router- to-router interior link addressing within their AS. This convention is analogous to RFC 1918 [RFC1918] for IPv4 -- universally recognised, universally filtered, never routed externally, never an endpoint. Thain Expires 16 October 2026 [Page 12] Internet-Draft IPv8 April 2026 3.11. Address Usage Model +=====================+===============================+===========+ | Address Space | Usage | Routable | +=====================+===============================+===========+ | 127.x.x.x.n.n.n.n | Internal devices (all zones) | Never | +---------------------+-------------------------------+-----------+ | 127.127.0.0.n.n.n.n | Inter-company interop DMZ | Private | +---------------------+-------------------------------+-----------+ | 100.x.x.x.n.n.n.n | RINE peering links only | Never | +---------------------+-------------------------------+-----------+ | .222.x.x.x | Interior router links | Never | +---------------------+-------------------------------+-----------+ | 0.0.255.254.n.n.n.n | Private BGP8 peering | Private | +---------------------+-------------------------------+-----------+ | .n.n.n.n | Explicit public services only | Global | +---------------------+-------------------------------+-----------+ | 0.0.0.0.n.n.n.n | IPv4 compatible (r.r.r.r = 0) | IPv4 only | +---------------------+-------------------------------+-----------+ Table 1 Most devices on most networks use 127.x.x.x internal addressing. Public ASN addresses are used only for explicitly public-facing services. 4. Address Classes +=================+=================+========================+ | r.r.r.r Value | Class | Description | +=================+=================+========================+ | 0.0.0.0 | IPv4 Compatible | Route on n.n.n.n using | | | | IPv4 rules | +-----------------+-----------------+------------------------+ | 0.0.0.1 through | ASN Unicast | Route to ASN, deliver | | | | to n.n.n.n | +-----------------+-----------------+------------------------+ | 99.255.255.255 | | Public internet | | | | routing via eBGP8 | +-----------------+-----------------+------------------------+ | 100.0.0.0 | RINE Peering | AS-to-AS peering link | | through | | addressing | +-----------------+-----------------+------------------------+ | 100.255.255.255 | | MUST NOT be globally | | | | routed | +-----------------+-----------------+------------------------+ | 101.0.0.0 | ASN Unicast | Route to ASN, deliver | | through | | to n.n.n.n | Thain Expires 16 October 2026 [Page 13] Internet-Draft IPv8 April 2026 +-----------------+-----------------+------------------------+ | 126.255.255.255 | | Public internet | | | | routing via eBGP8 | +-----------------+-----------------+------------------------+ | 127.0.0.0 | Internal Zone | Internal zone | | through | Prefix | identifier | +-----------------+-----------------+------------------------+ | 127.255.255.255 | | MUST NOT be routed | | | | externally | +-----------------+-----------------+------------------------+ | 128.0.0.0 | ASN Unicast | Route to ASN, deliver | | through | | to n.n.n.n | +-----------------+-----------------+------------------------+ | ff.fe.ff.ff | | Public internet | | | | routing via eBGP8 | +-----------------+-----------------+------------------------+ | ff.ff.00.00 | Cross-ASN | General cross-ASN | | | Multicast | multicast | +-----------------+-----------------+------------------------+ | ff.ff.00.01 | OSPF8 Reserved | OSPF8 protocol | | | | multicast traffic | +-----------------+-----------------+------------------------+ | ff.ff.00.02 | BGP8 Reserved | BGP8 peer discovery | | | | multicast | +-----------------+-----------------+------------------------+ | ff.ff.00.03 | EIGRP Reserved | Reserved. Deprecated. | | | | Vendor ext. | +-----------------+-----------------+------------------------+ | ff.ff.00.04 | RIP Reserved | Reserved. Deprecated. | +-----------------+-----------------+------------------------+ | ff.ff.00.05 | IS-IS8 Reserved | IS-IS8. Vendor | | | | extensible. | +-----------------+-----------------+------------------------+ | ff.ff.00.06 | Cross-ASN | Available for future | | through | Multicast | IANA | +-----------------+-----------------+------------------------+ | ff.ff.ef.ff | (available) | assignment. | +-----------------+-----------------+------------------------+ | ff.ff.f0.00 | Reserved | Future use. | | through | | | +-----------------+-----------------+------------------------+ | ff.ff.fe.ff | | | +-----------------+-----------------+------------------------+ | ff.ff.ff.ff | Broadcast | Maps to L2 broadcast. | +-----------------+-----------------+------------------------+ | | | MUST NOT be routed. | +-----------------+-----------------+------------------------+ Thain Expires 16 October 2026 [Page 14] Internet-Draft IPv8 April 2026 Table 2 The n.n.n.n range 222.0.0.0/8 is reserved by convention for interior link addressing per Section 3.10. 4.1. Anycast Anycast is not a separate address class in IPv8. Anycast is a routing property implemented via eBGP8. The Cost Factor (CF) metric defined in [ROUTING-PROTOCOLS] routes each packet to the nearest BGP8 instance by measured cost automatically. 5. IPv8 Packet Header 5.1. Header Format IPv8 uses IP version number 8 in the Version field. The header extends IPv4 by replacing the 32-bit src/dst address fields with 64-bit equivalents. 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| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source ASN Prefix (r.r.r.r) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Host Address (n.n.n.n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination ASN Prefix (r.r.r.r) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Host Address (n.n.n.n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The IPv8 header is 8 octets longer than the IPv4 header. Thain Expires 16 October 2026 [Page 15] Internet-Draft IPv8 April 2026 5.2. Socket API Compatibility Existing IPv4 applications use the standard BSD socket API with AF_INET and sockaddr_in. The IPv8 compatibility layer intercepts socket calls transparently -- the application has zero IPv8 awareness. New applications MAY use AF_INET8 with sockaddr_in8: struct sockaddr_in8 { sa_family_t sin8_family; /* AF_INET8 */ in_port_t sin8_port; /* port number */ uint32_t sin8_asn; /* r.r.r.r ASN prefix */ struct in_addr sin8_addr; /* n.n.n.n host address */ }; 6. ASN Dot Notation Format: .... Where ASN is the autonomous system number and n.n.n.n is the host address. Example ASNs 64496-64511 are reserved for documentation per [RFC5398]. 64496.192.0.2.1 = 0.0.251.240.192.0.2.1 (Example-A) 64497.192.0.2.1 = 0.0.251.241.192.0.2.1 (Example-B) All IPv8-compliant implementations MUST accept ASN Dot Notation in all contexts where an IPv8 address is accepted. 7. DNS A8 Record Type * *Type:* A8 (IANA assignment pending) * *Format:* 64-bit IPv8 address in network byte order * RFC 1918 addresses MUST NOT be published as A8 records in public DNS. * An IPv8 resolver SHOULD request both A and A8 records. * For IPv4 applications on IPv8 hosts, the resolver returns the n.n.n.n portion; the stack prepends r.r.r.r transparently. * The nominal A8 response is an even/odd pair -- one even address and one odd address providing load balancing and redundancy by default. Example records: ns1.example.com. IN A8 0.0.59.65.192.0.2.1 ns1.example.com. IN A8 0.0.59.65.192.0.2.2 8. Routing Protocol Behaviour Thain Expires 16 October 2026 [Page 16] Internet-Draft IPv8 April 2026 8.1. Mandatory Routing Protocols +==========+============+=======================+============+ | Protocol | Scope | Function | Status | +==========+============+=======================+============+ | eBGP8 | Inter-AS | Mandatory EGP for | MANDATORY | | | | public internet | | +----------+------------+-----------------------+------------+ | IBGP8 | Inter-zone | Mandatory for | MANDATORY | | | | internal zone routing | | +----------+------------+-----------------------+------------+ | OSPF8 | Intra-zone | Mandatory for intra- | MANDATORY | | | | zone routing | | +----------+------------+-----------------------+------------+ | IS-IS8 | Intra-AS | Available in all L3 | MUST BE | | | | stacks | AVAIL. | +----------+------------+-----------------------+------------+ | Static | All scopes | Mandatory for legacy | MANDATORY | | | | and VRF routing | | +----------+------------+-----------------------+------------+ | BGP4 | Transition | IPv4 AS compatibility | TRANSITION | +----------+------------+-----------------------+------------+ Table 3 8.2. Deprecated Routing Protocols +===========+================+===================+ | Protocol | Status in IPv8 | Notes | +===========+================+===================+ | RIP/RIPv2 | DEPRECATED | Replaced by OSPF8 | +-----------+----------------+-------------------+ | EIGRP | DEPRECATED | Vendor extensible | +-----------+----------------+-------------------+ Table 4 8.3. eBGP8 - Mandatory Exterior Gateway Protocol eBGP8 is the mandatory exterior gateway protocol. All L3 devices MUST implement eBGP8. eBGP8 is 100% backward compatible with BGP4 [RFC4271]. Full specification in [ROUTING-PROTOCOLS]. The minimum injectable prefix at inter-AS boundaries is /16. Prefixes more specific than /16 MUST NOT be advertised across AS boundaries. Thain Expires 16 October 2026 [Page 17] Internet-Draft IPv8 April 2026 8.4. IBGP8 - Inter-Zone Routing IBGP8 distributes WHOIS8-validated external routes throughout an autonomous system with full CF metric awareness. CF_total = CF_external + CF_intrazone 8.5. OSPF8 - Intra-Zone Routing OSPF8 is OSPFv2 [RFC2328] extended with a CF export interface. All L3 devices MUST implement OSPF8. Full specification in [ROUTING-PROTOCOLS] Section 10.3. 8.6. IS-IS8 - Optional Interior Gateway Protocol IS-IS8 MUST be available in all IPv8 L3 routing stacks. Carriers and operators MAY deploy IS-IS8 at their discretion. IPv8 makes no recommendation regarding IGP selection. Full specification in [ROUTING-PROTOCOLS] Section 10.4. 8.7. Two-Tier Routing Table +======+========+=========+====================================+ | Tier | Scope | Index | Description | +======+========+=========+====================================+ | 1 | Global | r.r.r.r | Routes to correct AS border router | +------+--------+---------+------------------------------------+ | 2 | Local | n.n.n.n | Identical to existing IPv4 routing | | | | | table | +------+--------+---------+------------------------------------+ Table 5 When r.r.r.r = 0.0.0.0 the Tier 1 lookup is bypassed. 8.8. VRF - Virtual Routing and Forwarding VRF is mandatory for all IPv8 L3 devices. The management VRF (VLAN 4090) and OOB VRF (VLAN 4091) MUST be implemented on all IPv8-compliant devices. VRF isolation is a routing table property that cannot be bypassed by software misconfiguration. Thain Expires 16 October 2026 [Page 18] Internet-Draft IPv8 April 2026 9. ICMPv8 ICMPv8 extends ICMP [RFC792] to support 64-bit IPv8 addresses. ICMPv8 is backward compatible with ICMPv4. Both versions MUST be supported simultaneously. ICMPv8 carries full 64-bit IPv8 addresses in Echo, Destination Unreachable, Time Exceeded, Redirect, and Parameter Problem messages. Path MTU Discovery is extended for the larger IPv8 header. Full specification in [SUPPORT8]. 10. Multicast 10.1. Intra-ASN Multicast 0.0.0.0.224.0.0.0/4 All intra-ASN multicast 0.0.0.0.239.0.0.0/8 Administratively scoped intra-ASN Packets with r.r.r.r = 0.0.0.0 and n.n.n.n in the multicast range MUST NOT be forwarded beyond the local AS boundary. 10.2. Cross-ASN Multicast ff.ff.00.00.n.n.n.n General cross-ASN multicast ff.ff.00.01.n.n.n.n OSPF8 protocol traffic ff.ff.00.02.n.n.n.n BGP8 peer discovery ff.ff.00.03.n.n.n.n EIGRP (reserved, deprecated) ff.ff.00.04.n.n.n.n RIP (reserved, deprecated) ff.ff.00.05.n.n.n.n IS-IS8 (reserved, vendor ext.) 10.3. Cross-ASN Multicast Group Assignments ff.ff.00.00.224.0.0.1 All IPv8 routers ff.ff.00.00.224.0.0.2 All IPv8 Zone Servers ff.ff.00.00.224.0.0.5 OSPF8 all routers ff.ff.00.00.224.0.0.6 OSPF8 designated routers ff.ff.00.00.224.0.0.10 IBGP8 peer discovery ff.ff.00.00.239.0.0.0/8 Administratively scoped 11. Anycast Anycast in IPv8 is a routing property implemented via eBGP8 and the Cost Factor (CF) metric. No special r.r.r.r prefix is required. CF routes each packet to the nearest instance by measured path cost. 12. Broadcast The r.r.r.r value ff.ff.ff.ff is permanently reserved for broadcast and maps to the Layer 2 broadcast address. Packets with r.r.r.r = ff.ff.ff.ff MUST NOT be routed beyond the local network segment. Thain Expires 16 October 2026 [Page 19] Internet-Draft IPv8 April 2026 13. Compatibility and Transition 13.1. Single Stack Operation IPv8 does not require dual-stack operation. IPv4 is a proper subset of IPv8 with r.r.r.r = 0.0.0.0. There is no flag day and no forced migration. 13.2. IPv4 Network Compatibility Networks that have not deployed IPv8 continue to operate unchanged. IPv8 border routers strip the r.r.r.r prefix for IPv4-only destinations. 13.3. 8to4 - IPv8 Across IPv4-Only Networks IPv8 ASNs separated by IPv4-only transit ASNs communicate via 8to4 tunnelling. HTTPS tunnelling is the preferred encapsulation -- it provides automatic encryption and traverses most firewalls without special configuration. The 8TO4-ENDPOINT BGP8 attribute carries the IPv4 tunnel endpoint automatically. Zero manual tunnel configuration required. Full specification in [ROUTING-PROTOCOLS] Section 11. 13.4. Transition Sequence Phase 1: Tier 1/2 ISP routers deploy IPv8 via software update. Phase 2: Cloud providers deploy IPv8 internally. Phase 3: Enterprise networks optionally adopt ASN prefixes. Phase 4: Consumer ISPs deploy IPv8. 8to4 tunnelling enables each phase to interoperate with phases not yet completed. There is no dependency between phases. 14. CGNAT Behaviour CGNAT devices require no modification. IPv8-aware CGNAT MUST NOT modify the r.r.r.r field during translation. Only the n.n.n.n field is subject to NAT translation. CGNAT operators without an ASN MUST use r.r.r.r = 0.0.0.0. 15. Application Compatibility Existing IPv4 applications require no modification. The IPv8 socket compatibility layer transparently manages r.r.r.r via DNS8 interception and XLATE8. New applications MAY use AF_INET8 and sockaddr_in8 as defined in Section 5.2. Thain Expires 16 October 2026 [Page 20] Internet-Draft IPv8 April 2026 16. Cloud Provider Applicability IPv8 resolves VPC address overlap, VPC peering complexity, and multi- cloud routing through ASN-based disambiguation. The 127.x.x.x internal zone prefix enables cloud providers to assign unique zone prefixes to customer VPCs without address renumbering. Each customer VPC receives a unique 127.x.x.x zone prefix -- no two customer networks can overlap regardless of RFC 1918 address reuse within each VPC. 17. Device Compliance Tiers 17.1. Tier 1 - End Device End devices MUST implement: Route8 unified routing table, static routes, VRF (management plane), two default gateways (even/odd), DHCP8 client, ARP8, ICMPv8, TCP/443 persistent connection to Zone Server, NetLog8 client, ACL8 client-side enforcement, management VRF (VLAN 4090), OOB VRF (VLAN 4091), gratuitous ARP8 on boot. End devices MAY implement: OSPF8, IS-IS8, eBGP8, IBGP8. End devices DO NOT require any routing protocol to reach their default gateway. 17.2. Tier 2 - L2 Network Device L2 devices MUST implement: 802.1Q trunking, VLAN auto- creation on tagged traffic, management VRF (VLAN 4090), OOB VRF (VLAN 4091), switch port OAuth2 binding, LLDP, NetLog8 client, ARP8 (management plane only), ICMPv8 (management plane only), PVRST, Zone Server as PVRST root capability, sticky MAC binding, Zone Server MAC notification. 17.3. Tier 3 - L3 Network Device L3 devices MUST implement: All Tier 1 requirements, eBGP8, IBGP8, OSPF8, IS-IS8 (available), static routes, VRF (full), XLATE8 (mandatory on edge devices), WHOIS8 resolver, ACL8 gateway enforcement, Zone Server services (if Zone Server role), PVRST root capability, switch port OAuth2 binding support. 17.4. Spanning Tree - PVRST Mandatory PVRST is mandatory for all IPv8 L2 and L3 devices. MST is not recommended. Zone Servers are PVRST roots by default: Thain Expires 16 October 2026 [Page 21] Internet-Draft IPv8 April 2026 * Primary Zone Server (.254): PVRST root for even VLANs, priority 4096. * Secondary Zone Server (.253): PVRST root for odd VLANs, priority 4096. 17.5. NIC Rate Limits IPv8 certified NIC firmware enforces rate limits that cannot be overridden by software: Broadcasts: 10 per second maximum User unauthenticated: 10 per second, max 30 per minute User authenticated: 100 per second, max 300 per minute The DHCP8 Zone Server is the sole authority for rate limit elevation. Full NIC certification specification in [UPDATE8]. 18. Security Considerations 18.1. ASN Prefix Spoofing IPv8 border routers MUST implement ingress filtering validating that the source r.r.r.r of received packets matches the ASN of the BGP8 peer. Consistent with BCP 38 [RFC2827]. 18.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 source or destination r.r.r.r on external interfaces. NetLog8 SEC-ALERT MUST be generated for each violation. 18.3. RINE Prefix Protection The 100.x.x.x RINE prefix MUST NOT appear in eBGP8 advertisements or on non-peering interfaces. NetLog8 SEC-ALERT MUST be generated for each violation. 18.4. Interior Link Convention Protection Border routers MUST filter received BGP8 advertisements containing n.n.n.n addresses in the 222.0.0.0/8 range. NetLog8 E3 trap MUST be generated for each violation. 18.5. RFC 1918 Address Privacy RFC 1918 private addresses in n.n.n.n remain non-routable on the public internet consistent with IPv4 behaviour. Thain Expires 16 October 2026 [Page 22] Internet-Draft IPv8 April 2026 18.6. Cross-ASN Multicast Filtering Routing protocol reserved prefixes ff.ff.00.01 through ff.ff.00.05 MUST be filtered at all border routers. 18.7. /16 Minimum Prefix Enforcement Prefixes more specific than /16 MUST NOT be accepted from external BGP8 peers. Such advertisements MUST be rejected and logged via NetLog8 as SEC-ALERT. 19. IANA Considerations 19.1. IP Version Number IANA is requested to assign version number 8 in the IP Version Number registry to Internet Protocol Version 8. 19.2. Internal Zone Prefix Reservation IANA is requested to reserve the r.r.r.r range 127.0.0.0 through 127.255.255.255 as the IPv8 internal zone prefix space. ASN numbers 2130706432 through 2147483647 MUST NOT be allocated for public internet routing. 19.3. RINE Prefix Reservation IANA is requested to reserve the r.r.r.r range 100.0.0.0 through 100.255.255.255 as the IPv8 RINE peering fabric range. ASN numbers 1677721600 through 1694498815 MUST NOT be allocated for public internet routing. 19.4. Interior Link Convention IANA is requested to document the n.n.n.n range 222.0.0.0/8 as the IPv8 interior link address convention. 19.5. Cross-ASN Multicast Range IANA is requested to establish a registry for IPv8 cross-ASN multicast prefixes within ff.ff.00.00 through ff.ff.ef.ff. 19.6. Broadcast Reservation IANA is requested to reserve r.r.r.r value ff.ff.ff.ff as the IPv8 broadcast address. Thain Expires 16 October 2026 [Page 23] Internet-Draft IPv8 April 2026 19.7. DNS A8 Record Type IANA is requested to assign a DNS resource record type number for the A8 record type defined in Section 7. 19.8. Multicast Group Assignments IANA is requested to assign multicast groups within ff.ff.00.00.224.0.0.0/24 as defined in Section 10.3. 19.9. Private ASN Reservations IANA is requested to reserve ASN 65534 for private inter- company BGP8 peering and ASN 65533 for documentation and testing purposes consistent with [RFC6996]. 20. Informative References [RFC1918] Rekhter, Y., "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998, . [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering", BCP 38, RFC 2827, May 2000, . [RFC4271] Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, . [RFC5398] Huston, G., "Autonomous System (AS) Numbers Reserved for Documentation Use", RFC 5398, December 2008, . [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for Private Use", BCP 6, RFC 6996, July 2013, . [RFC7519] Jones, M., "JSON Web Token (JWT)", RFC 7519, May 2015, . Thain Expires 16 October 2026 [Page 24] Internet-Draft IPv8 April 2026 [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, July 2017, . [RINE] Thain, J., "Regional Inter-Network Exchange", Work in Progress, Internet-Draft, draft-thain-rine-00, April 2026, . [ROUTING-PROTOCOLS] Thain, J., "IPv8 Routing Protocols", Work in Progress, Internet-Draft, draft-thain-routing-protocols-00, April 2026, . [SUPPORT8] Thain, J., "IPv8 Support Protocols -- ARP8, ICMPv8, and Route8", Work in Progress, Internet-Draft, draft-thain- support8-00, April 2026, . [UPDATE8] Thain, J., "Update8 and NIC Certification", Work in Progress, Internet-Draft, draft-thain-update8-00, April 2026, . [ZONESERVER] Thain, J., "IPv8 Zone Server Architecture", Work in Progress, Internet-Draft, draft-thain-zoneserver-00, April 2026, . Author's Address Jamie Thain One Limited Hamilton Bermuda Email: jamie@one.bm Thain Expires 16 October 2026 [Page 25]