Internet Protocol Version 8 (IPv8) - draft-thain-ipv8-00

5 months ago
c11728a

Internet Protocol Version 8 (IPv8)

Internet-Draft

  • Workgroup: Network Working Group
  • Document: draft-thain-ipv8-00
  • Published: 14 April 2026
  • Expires: 16 October 2026
  • Author: J. Thain, One Limited
  • Intended Status: Standards Track

Abstract

IPv8 represents a managed network protocol suite redesigning operations across networks of all scales. The core innovation involves OAuth2 JWT token authorization for every manageable element, unified service delivery via DHCP8 leases, and mandatory DNS8/WHOIS8 validation for internet-bound packets.

IPv4 functionality maps directly to IPv8 when the routing prefix field equals zero, enabling complete backward compatibility without device or application modifications. No migration deadline or dual-stack requirement exists.

The addressing structure allocates 4,294,967,296 host addresses per ASN, resolving address exhaustion. The global routing table remains structurally bounded at approximately one entry per ASN holder.

The specification comprises ten companion documents covering routing protocols, zone server architecture, WHOIS8 protocol, NetLog8 telemetry, support protocols, MIB definitions, WiFi8, and update mechanisms.

Status of This Memo

This Internet-Draft follows BCP 78 and BCP 79 provisions. Internet-Drafts function as working documents with maximum six-month validity. This draft expires 16 October 2026.

Copyright Notice

Copyright 2026 IETF Trust and document authors. Subject to BCP 78 and IETF Trust Legal Provisions. Code components require Revised BSD License text.

Table of Contents

  1. Introduction
  2. Motivation and Problem Statement
  3. IPv8 Address Format
  4. Address Classes
  5. IPv8 Packet Header
  6. ASN Dot Notation
  7. DNS A8 Record Type
  8. Routing Protocol Behaviour
  9. ICMPv8
  10. Multicast
  11. Anycast
  12. Broadcast
  13. Compatibility and Transition
  14. CGNAT Behaviour
  15. Application Compatibility
  16. Cloud Provider Applicability
  17. Device Compliance Tiers
  18. Security Considerations
  19. IANA Considerations
  20. Informative References

1. Introduction

1.1 Requirements Language

Key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" follow BCP 14 RFC 2119 and RFC 8174 interpretations.

1.2 The Network Management Problem

Contemporary network management demonstrates significant fragmentation. DHCP, DNS, NTP, logging, monitoring, and authentication function as separate products with independent licensing, configuration, and maintenance. A device joining a network may require manual setup of a dozen independent services before achieving operational status. Security implementation varies inconsistently across services.

IPv6 addressed capacity limitations but overlooked management integration. Despite 25 years of deployment efforts, IPv6 remains a minority component of global internet traffic. The dual-stack operational model combined with absent management improvements proved commercially prohibitive.

IPv8 addresses both fragmentation and capacity simultaneously.

1.3 The IPv8 Management Philosophy

The Zone Server represents the central operational concept—a paired active/active platform executing all network segment services: address assignment (DHCP8), name resolution (DNS8), time synchronization (NTP8), telemetry collection (NetLog8), authentication caching (OAuth8), route validation (WHOIS8 resolver), access control enforcement (ACL8), and IPv4/IPv8 translation (XLATE8).

Network-joining devices transmit one DHCP8 Discover message and receive a single response containing all required service endpoints. No additional manual configuration becomes necessary. Devices achieve full operational status—authenticated, logged, time-synchronized, zone-policy-enforced—before user interaction.

Every manageable element receives authorization via OAuth2 JWT tokens. The OAuth8 cache on Zone Servers validates tokens locally without external identity provider round trips. Devices in remote locations with temporarily unreachable cloud providers continue authenticating normally, with the cache holding all public keys and validating signatures within sub-millisecond latencies.

Firmware and software updates for L1-L4 stack components follow the Update8 protocol specification, defining standard vendor feed formats, Zone Server-validated proxies, optional local caching, device criticality-based scheduling, and rollback prevention enforced in NIC hardware.

The 127.0.0.0/8 range remains permanently reserved as internal zone prefix space. Organizations assign internal zone prefixes to network zones and regions. These addresses never route externally, eliminating cross-zone address conflicts. Organizations construct networks of arbitrary geographic and organizational scale using familiar routing protocols without external address coordination.

1.4 East-West and North-South Security

IPv8 addresses two distinct traffic security classifications:

East-west security (inter-device traffic within networks) relies on ACL8 zone isolation enforcement. Devices communicate exclusively with designated service gateways, which connect only to designated cloud services. Lateral device or zone movement remains architecturally prevented through absent permitted routes. Defense-in-depth employs three independent enforcement layers: NIC firmware ACL8, Zone Server gateway ACL8, and switch port OAuth2 hardware VLAN enforcement.

North-south security (internal device-to-internet traffic) operates at Zone Server egress through two mandatory validation steps. Outbound connections require corresponding DNS8 lookups—absent DNS lookups prevent XLATE8 state table entry creation and result in packet blocking. Destination ASN validation against the WHOIS8 registry ensures dropped packets when destination prefixes lack registration as active routes by legitimately registered ASN holders. Together, these mechanisms eliminate primary malware command-and-control channels relying on hardcoded IP addresses without DNS resolution.

At global routing levels, BGP8 route advertisements undergo WHOIS8 validation before routing table installation. Unvalidatable routes remain uninstalled. Manual bogon filtering list maintenance becomes unnecessary. Prefix hijacking requires compromising both RIR registry entries and producing validly signed WHOIS8 records.

1.5 Address Exhaustion

IANA completed IPv4 unicast address space allocation in February 2011. Regional Internet Registries exhausted allocations between 2011 and 2020. CGNAT extended IPv4 operational life while introducing latency, breaking peer-to-peer protocols, and complicating troubleshooting. The exhaustion problem remains architectural and insoluble within 32-bit IPv4 address space limits.

IPv8 resolves exhaustion as an architectural consequence rather than primary design objective. The 64-bit address space provides 2^64 unique addresses. Each ASN holder receives 2^32 host addresses—4,294,967,296 addresses—sufficient for any organizational scale without exhaustion, CGNAT, or renumbering requirements.

IPv4 functions as a proper IPv8 subset. An IPv8 address with r.r.r.r = 0.0.0.0 constitutes an IPv4 address processed by standard IPv4 rules. Existing devices, applications, and networks require zero modifications for IPv8 network participation. The suite maintains 100% backward compatibility without flag days or forced migrations.

The global BGP8 routing table remains structurally bounded at one entry per ASN. The /16 minimum injectable prefix rule prevents deaggregation. Most carriers advertise single /8 summary routes per regional ASN. The BGP4 routing table exceeded 900,000 prefixes with no architectural bound. The BGP8 routing table remains bounded by ASN allocation rates—approximately 175,000 entries today.

1.6 Routing Protocol Improvements

IPv8 extends OSPF8, BGP8 (both iBGP8 and eBGP8), and IS-IS8 with a unified path quality metric—the Cost Factor (CF).

CF represents a 32-bit accumulated metric derived from seven TCP session telemetry components: 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 paths with the lowest accumulated CF without coordination.

CF combines EIGRP's dynamic composite path quality, OSPF's accumulated cost model, and proportional load balancing across multiple paths—within a single open versioned algorithm operating end-to-end across AS boundaries. OSPF and EIGRP terminate at AS boundaries; CF does not.

The geographic CF component establishes a physics floor—no path can appear superior to the speed of light over great circle distance allows. Paths measuring faster than physics permits receive immediate CF anomaly flags.

CF functions as an open versioned algorithm. CFv1 represents mandatory baseline functionality. Future versions may incorporate carbon cost, jitter, time-of-day, and application layer latency signals through IETF processes.

1.7 Backward Compatibility and Transition

IPv4 qualifies as a proper IPv8 subset:

  • IPv8 address with r.r.r.r = 0.0.0.0 = IPv4 address
  • Processed by standard IPv4 rules
  • No IPv4 device modification required
  • No IPv4 application modification required
  • No IPv4 internal network modification required

IPv8 eschews dual-stack operation. No flag day exists. 8to4 tunneling enables IPv8 islands separated by IPv4-only transit networks to communicate immediately. CF naturally incentivizes IPv4 transit ASN upgrades through higher latency measurements on 8to4 paths—an automatic economic signal without mandate.

Transition phases remain independent. Tier 1 ISPs, cloud providers, enterprises, and consumer ISPs may adopt IPv8 in any sequence and at any pace. 8to4 ensures interoperability throughout.

2. Motivation and Problem Statement

2.1 Management Fragmentation

IPv4 network management lacks coherent integrated models. The protocols operating networks—DHCP, DNS, NTP, syslog, SNMP, authentication—received independent specification over four decades, sharing no common identity model, authentication mechanism, or telemetry format.

Operational consequences demand specialist knowledge across each protocol independently. Security consistency varies—some services require authentication while others accept unauthenticated requests from any source. Failures necessitate correlating logs across systems featuring different timestamp formats, severity models, and identity representations. Management scaling accompanies operational burden rather than network size.

IPv8 addresses this through defining coherent management suites where every service shares common identity models (OAuth2 JWT), delivery mechanisms (DHCP8), telemetry formats (NetLog8), and authentication caches (OAuth8).

2.2 Address Exhaustion

IANA completed IPv4 unicast address space allocation in February 2011. RIRs exhausted allocations between 2011 and 2020. CGNAT extended IPv4 lifespan at costs including latency, peer-to-peer protocol breakage, and troubleshooting complexity.

IPv6 received development to address exhaustion. Despite 25 years of standardization and deployment effort, IPv6 carries minority global internet traffic shares. The dual-stack transition requirement—compelling every device, application, and network to simultaneously support both protocols—proved commercially unacceptable. Absent forcing functions allowed indefinite CGNAT continuation.

IPv8 resolves exhaustion without dual-stack operation. IPv4 qualifies as a proper IPv8 subset. 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 boundaries. Prefix deaggregation—advertising more specific prefixes influencing traffic engineering—drives primary growth. No protocol mechanism prevents it.

BGP4 maintains no binding relationship between ASN advertisements and authorization to advertise. Prefix hijacking, route leaks, and bogon injection remain possible through absent route ownership registries that border routers enforce as route acceptance conditions.

IPv8 addresses both problems. The /16 minimum injectable prefix rule prevents inter-AS deaggregation. WHOIS8 mandatory route validation creates binding relationships between BGP8 advertisements and registered route ownership. The global BGP8 routing table remains structurally bounded at one entry per ASN.

2.4 Requirements for a Viable Successor

  • R1. Integrated management—common identity, authentication, telemetry, and service delivery across network services
  • R2. Single stack operation—no dual-stack requirement
  • R3. Full backward compatibility—existing IPv4 applications unchanged; IPv4 qualifies as proper IPv8 subset
  • R4. Full backward compatibility—RFC 1918 internal networks unchanged
  • R5. Full backward compatibility—CGNAT deployments unchanged
  • R6. Vastly expanded address space
  • R7. Implementable as 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 manual configuration
  • R10. Structurally bounded global routing table

IPv8 satisfies all ten requirements.

3. IPv8 Address Format

3.1 Structure

An IPv8 address consists of 64 bits:

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 route using standard IPv4 rules applied to the n.n.n.n field. IPv4 qualifies as a proper IPv8 subset. Device, application, or network modifications remain unnecessary.

3.4 ASN Encoding in r.r.r.r

The 32-bit ASN encodes directly into r.r.r.r as a 32-bit unsigned integer in network byte order:

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 remains permanently reserved for internal IPv8 zone prefixes, identifying network zones within organizational private addressing spaces.

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 route externally beyond organizational AS boundaries
  • MUST NOT appear on WAN interfaces or public internet links
  • MUST NOT appear in eBGP8 advertisements
  • MAY be used freely within organizational internal routing infrastructure via OSPF8, IS-IS8, and IBGP8
  • Provides 2^56 effective internal addresses across all zone prefixes; no internal address conflicts between zones remain possible
  • Enables organizations to construct geographically distributed, region-routed private networks of arbitrary scale without external address coordination

ASN numbers encoding to the 127.0.0.0/8 range in the r.r.r.r field (ASN 2130706432 through ASN 2147483647) remain reserved for internal zone use and MUST NOT receive IANA allocation for public internet routing.

3.6 Inter-Company Interop Prefix (127.127.0.0)

The 127.127.0.0 prefix remains reserved as standard inter-company interoperability DMZ. When two organizations require interconnection without exposing internal zone addressing, both deploy XLATE8 engines facing shared 127.127.0.0 address space.

3.7 Two-XLATE8 Interop Model

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 observes Company B's 127.2.0.0 addresses
  • Company B never observes Company A's 127.1.0.0 addresses
  • Each company controls exactly what it exposes
  • No address overlap remains possible; no NAT complexity emerges
  • Setup requires minutes per exposed service

3.8 Private Interop ASN (ASN 65534)

ASN 65534 remains reserved for private inter-company BGP8 peering consistent with RFC 6996:

0.0.255.254.x.x.x.x

ASN 65533 (0.0.255.253.x.x.x.x) remains 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 remains permanently reserved for the Regional Inter-Network Exchange (RINE) peering fabric. RINE addresses function exclusively for AS-to-AS peering link addressing at IXPs and private interconnect facilities.

RINE addresses:

  • MUST NOT appear in global BGP8 routing table advertisements
  • MUST NOT receive assignment to end devices
  • MUST filter 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 comprises 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 parallels RFC 1918 for IPv4—universally recognized, universally filtered, never routed externally, never an endpoint.

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

Most devices on most networks employ 127.x.x.x internal addressing. Public ASN addresses apply exclusively to 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 99.255.255.255 ASN Unicast Route to ASN, deliver to n.n.n.n; public internet routing via eBGP8
100.0.0.0 through 100.255.255.255 RINE Peering AS-to-AS peering link addressing; MUST NOT be globally routed
101.0.0.0 through 126.255.255.255 ASN Unicast Route to ASN, deliver to n.n.n.n; public internet routing via eBGP8
127.0.0.0 through 127.255.255.255 Internal Zone Prefix Internal zone identifier; MUST NOT be routed externally
128.0.0.0 through ff.fe.ff.ff ASN Unicast Route to ASN, deliver to n.n.n.n; public internet routing via eBGP8
ff.ff.00.00 Cross-ASN Multicast General cross-ASN 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 extensible
ff.ff.00.04 RIP Reserved Reserved; deprecated
ff.ff.00.05 IS-IS8 Reserved IS-IS8; vendor extensible
ff.ff.00.06 through ff.ff.ef.ff Cross-ASN Multicast Available for future IANA assignment
ff.ff.f0.00 through ff.ff.fe.ff Reserved Future use
ff.ff.ff.ff Broadcast Maps to L2 broadcast; MUST NOT be routed

The n.n.n.n range 222.0.0.0/8 remains reserved by convention for interior link addressing per Section 3.10.

4.1 Anycast

Anycast does not constitute a separate address class in IPv8. Anycast represents a routing property implemented via eBGP8. The Cost Factor (CF) metric defined in the routing protocols specification routes each packet to the nearest BGP8 instance by measured cost automatically.

5. IPv8 Packet Header

5.1 Header Format

IPv8 employs 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 extends the IPv4 header by eight octets.

5.2 Socket API Compatibility

Existing IPv4 applications employ standard BSD socket API with AF_INET and sockaddr_in. The IPv8 compatibility layer intercepts socket calls transparently—applications require zero IPv8 awareness. New applications MAY employ 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: <ASN>.<n>.<n>.<n>.<n>

Where ASN represents the autonomous system number and n.n.n.n comprises the host address. Example ASNs 64496-64511 remain reserved for documentation per RFC 5398.

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 IPv8 addresses appear.

7. DNS A8 Record Type

  • Type: A8 (IANA assignment pending)
  • Format: 64-bit IPv8 address in network byte order
  • RFC 1918 addresses MUST NOT appear 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 consists of even/odd pairs—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

8.1 Mandatory Routing Protocols

Protocol Scope Function Status
eBGP8 Inter-AS Mandatory EGP for public internet MANDATORY
IBGP8 Inter-zone Mandatory for internal zone routing MANDATORY
OSPF8 Intra-zone Mandatory for intra-zone routing MANDATORY
IS-IS8 Intra-AS Available in all L3 stacks MUST BE AVAILABLE
Static All scopes Mandatory for legacy and VRF routing MANDATORY
BGP4 Transition IPv4 AS compatibility TRANSITION

8.2 Deprecated Routing Protocols

Protocol Status in IPv8 Notes
RIP/RIPv2 DEPRECATED Replaced by OSPF8
EIGRP DEPRECATED Vendor extensible

8.3 eBGP8 - Mandatory Exterior Gateway Protocol

eBGP8 comprises the mandatory exterior gateway protocol. All L3 devices MUST implement eBGP8. eBGP8 maintains 100% backward compatibility with BGP4 (RFC 4271).

The minimum injectable prefix at inter-AS boundaries measures /16. Prefixes more specific than /16 MUST NOT appear in advertisements across AS boundaries.

8.4 IBGP8 - Inter-Zone Routing

IBGP8 distributes WHOIS8-validated external routes throughout autonomous systems with full CF metric awareness.

CF_total = CF_external + CF_intrazone

8.5 OSPF8 - Intra-Zone Routing

OSPF8 comprises OSPFv2 (RFC 2328) extended with a CF export interface. All L3 devices MUST implement OSPF8.

8.6 IS-IS8 - Optional Interior Gateway Protocol

IS-IS8 MUST remain available in all IPv8 L3 routing stacks. Carriers and operators MAY deploy IS-IS8 at their discretion. IPv8 makes no selection recommendation regarding IGP choice.

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

When r.r.r.r = 0.0.0.0 the Tier 1 lookup receives bypass.

8.8 VRF - Virtual Routing and Forwarding

VRF remains mandatory for all IPv8 L3 devices. The management VRF (VLAN 4090) and OOB VRF (VLAN 4091) MUST receive implementation on all IPv8-compliant devices. VRF isolation qualifies as a routing table property that software misconfiguration cannot circumvent.

9. ICMPv8

ICMPv8 extends ICMP (RFC 792) to support 64-bit IPv8 addresses. ICMPv8 maintains backward compatibility with ICMPv4. Both versions MUST receive simultaneous support. ICMPv8 carries full 64-bit IPv8 addresses in Echo, Destination Unreachable, Time Exceeded, Redirect, and Parameter Problem messages. Path MTU Discovery receives extension for the larger IPv8 header.

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 forward beyond local AS boundaries.

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 represents a routing property implemented via eBGP8 and the Cost Factor (CF) metric. No special r.r.r.r prefix receives requirement. CF routes each packet to the nearest instance by measured path cost.

12. Broadcast

The r.r.r.r value ff.ff.ff.ff remains permanently reserved for broadcast and maps to the Layer 2 broadcast address. Packets with r.r.r.r = ff.ff.ff.ff MUST NOT route beyond local network segments.

13. Compatibility and Transition

13.1 Single Stack Operation

IPv8 eschews dual-stack operation requirement. IPv4 qualifies as a proper IPv8 subset with r.r.r.r = 0.0.0.0. No flag day exists and no forced migration occurs.

13.2 IPv4 Network Compatibility

Networks that have not deployed IPv8 continue operating 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 tunneling. HTTPS tunneling represents 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.

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 tunneling enables each phase to interoperate with phases not yet completed. No dependency exists 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 remains subject to NAT translation. CGNAT operators without ASNs 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.

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 remains mandatory for all IPv8 L2 and L3 devices. MST does not receive recommendation. Zone Servers function as PVRST roots by default:

  • 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 software cannot override:

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 constitutes the sole authority for rate limit elevation.

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 BGP8 peer ASN. Consistent with BCP 38 (RFC 2827).

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 appear 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 appear 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 appear 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 behavior.

18.6 Cross-ASN Multicast Filtering

Routing protocol reserved prefixes ff.ff.00.01 through ff.ff.00.05 MUST filter at all border routers.

18.7 /16 Minimum Prefix Enforcement

Prefixes more specific than /16 MUST NOT appear in external BGP8 peer acceptance. Such advertisements MUST receive rejection and logging via NetLog8 as SEC-ALERT.

19. IANA Considerations

19.1 IP Version Number

IANA receives request to assign version number 8 in the IP Version Number registry to Internet Protocol Version 8.

19.2 Internal Zone Prefix Reservation

IANA receives request 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 receive allocation for public internet routing.

19.3 RINE Prefix Reservation

IANA receives request 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 receive allocation for public internet routing.

19.4 Interior Link Convention

IANA receives request 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 receives request 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 receives request to reserve r.r.r.r value ff.ff.ff.ff as the IPv8 broadcast address.

19.7 DNS A8 Record Type

IANA receives request to assign a DNS resource record type number for the A8 record type defined in Section 7.

19.8 Multicast Group Assignments

IANA receives request 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 receives request to reserve ASN 65534 for private inter-company BGP8 peering and ASN 65533 for documentation and testing purposes consistent with RFC 6996.

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
  • [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, draft-thain-rine-00, April 2026
  • [ROUTING-PROTOCOLS] Thain, J., "IPv8 Routing Protocols", Work in Progress, draft-thain-routing-protocols-00, April 2026
  • [SUPPORT8] Thain, J., "IPv8 Support Protocols -- ARP8, ICMPv8, and Route8", Work in Progress, draft-thain-support8-00, April 2026
  • [UPDATE8] Thain, J., "Update8 and NIC Certification", Work in Progress, draft-thain-update8-00, April 2026
  • [ZONESERVER] Thain, J., "IPv8 Zone Server Architecture", Work in Progress, draft-thain-zoneserver-00, April 2026

Author's Address

Jamie Thain
One Limited, Hamilton, Bermuda
Email: jamie@one.bm

Source: IETF Draft - IPv8 (draft-thain-ipv8-00)