Internet Protocol Version 8 (IPv8)

Introduction

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

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

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 . 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 defines a standard vendor feed format, Zone Server validated proxy, optional local 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.

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.

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.

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

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.

Motivation and Problem Statement

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. 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).

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

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.

Requirements for a Viable Successor

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.

IPv8 Address Format

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)

Address Space 2^64 = 18,446,744,073,709,551,616 unique addresses. 2^32 ASN prefixes x 2^32 host addresses per ASN.

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.

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: ASN 64496 (Example-A) = 0.0.251.240 ASN 64497 (Example-B) = 0.0.251.241 ASN 64498 (Example-C) = 0.0.251.242

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.

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 Section 16.9.

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

Private Interop ASN (ASN 65534) ASN 65534 is reserved for private inter-company BGP8 peering consistent with : 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.

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

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 <own-asn>.222.x.x.x for router-to-router interior link addressing within their AS. This convention is analogous to RFC 1918 for IPv4 -- universally recognised, universally filtered, never routed externally, never an endpoint.

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
<asn>.222.x.x.x	Interior router links	Never
0.0.255.254.n.n.n.n	Private BGP8 peering	Private
<own-asn>.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 use 127.x.x.x internal addressing. Public ASN addresses are used only for explicitly public-facing services.

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 through	RINE Peering	AS-to-AS peering link addressing
100.255.255.255		MUST NOT be globally routed
101.0.0.0 through	ASN Unicast	Route to ASN, deliver to n.n.n.n
126.255.255.255		Public internet routing via eBGP8
127.0.0.0 through	Internal Zone Prefix	Internal zone identifier
127.255.255.255		MUST NOT be routed externally
128.0.0.0 through	ASN Unicast	Route to ASN, deliver to n.n.n.n
ff.fe.ff.ff		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 ext.
ff.ff.00.04	RIP Reserved	Reserved. Deprecated.
ff.ff.00.05	IS-IS8 Reserved	IS-IS8. Vendor extensible.
ff.ff.00.06 through	Cross-ASN Multicast	Available for future IANA
ff.ff.ef.ff	(available)	assignment.
ff.ff.f0.00 through	Reserved	Future use.
ff.ff.fe.ff
ff.ff.ff.ff	Broadcast	Maps to L2 broadcast.
		MUST NOT be routed.

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

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 routes each packet to the nearest BGP8 instance by measured cost automatically.

IPv8 Packet Header

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. <CODE BEGINS> 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <CODE ENDS> The IPv8 header is 8 octets longer than the IPv4 header.

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 */ };

ASN Dot Notation Format: <ASN>.<n>.<n>.<n>.<n> 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 . 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.

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

Routing Protocol Behaviour

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 AVAIL.
Static	All scopes	Mandatory for legacy and VRF routing	MANDATORY
BGP4	Transition	IPv4 AS compatibility	TRANSITION

Deprecated Routing Protocols

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

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 . Full specification in . The minimum injectable prefix at inter-AS boundaries is /16. Prefixes more specific than /16 MUST NOT be advertised across AS boundaries.

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

OSPF8 - Intra-Zone Routing OSPF8 is OSPFv2 extended with a CF export interface. All L3 devices MUST implement OSPF8. Full specification in Section 10.3.

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 Section 10.4.

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 is bypassed.

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.

ICMPv8 ICMPv8 extends ICMP 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 .

Multicast

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.

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.)

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

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.

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.

Compatibility and Transition

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.

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.

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 Section 11.

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.

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.

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.

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.

Device Compliance Tiers

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.

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.

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.

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:

Primary Zone Server (.254): PVRST root for even VLANs, priority 4096.
Secondary Zone Server (.253): PVRST root for odd VLANs, priority 4096.

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 .

Security Considerations

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 .

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.

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.

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.

RFC 1918 Address Privacy RFC 1918 private addresses in n.n.n.n remain non-routable on the public internet consistent with IPv4 behaviour.

Cross-ASN Multicast Filtering Routing protocol reserved prefixes ff.ff.00.01 through ff.ff.00.05 MUST be filtered at all border routers.

/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.

IANA Considerations

IP Version Number IANA is requested to assign version number 8 in the IP Version Number registry to Internet Protocol Version 8.

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.

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.

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.

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.

Broadcast Reservation IANA is requested to reserve r.r.r.r value ff.ff.ff.ff as the IPv8 broadcast address.

DNS A8 Record Type IANA is requested to assign a DNS resource record type number for the A8 record type defined in Section 7.

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.

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 .