One Limited

Hamilton Bermuda jamie@one.bm

Open-IPv8-Lab

contact@alekseialeinikov.com

Internet Internet Area Working Group IPv8 internet protocol network management BGP8 Zone Server This document specifies Internet Protocol Version 8 (IPv8), an extension of IPv4 that prepends a 32-bit Route Number (RN) to each IPv4 address to produce a 64-bit address space. IPv4 is a proper subset of IPv8: an IPv8 address whose RN is zero is bit-identical to an IPv4 address, and IPv4 packets are IPv8 packets whose RN is implicitly zero. IPv8 is incrementally deployable over existing IPv4 infrastructure. Forwarding silicon, BGP4 routing, and operator administrative boundaries continue to operate without modification. IPv8-aware behaviour is implemented in software at the edges of forwarding paths and signalled through extension mechanisms (BGP large communities, IS-IS TLVs, OSPF opaque LSAs) that unupgraded transit elements flood transparently and ignore. This document defines the IPv8 address format, the textual representation conventions including the canonical hyphenated locator form, the relationship to IPv4, the architectural principles governing the suite, and the security and operational considerations applicable to all companion specifications. Routing-protocol behaviour, encapsulation rules, trust mechanisms, and management interfaces are specified in companion documents listed in §1.

Introduction This document specifies the core elements of Internet Protocol Version 8 (IPv8). IPv8 extends IPv4 by prepending a 32-bit Route Number (RN) to each IPv4 address, producing a 64-bit address space written as <RN>-<LA> where <RN> is the Route Number and <LA> is the IPv4 address within that Route Number's space. The Route Number is rendered as either a decimal integer (for RN values whose leading octet is zero) or as four dotted octets (for reserved-block RN values whose leading octet is non-zero). The hyphen between RN and LA is a fixed visual separator distinguishing the two fields. IPv4 is a proper subset of IPv8. The address 0-n.n.n.n in IPv8 is bit-identical to the IPv4 address n.n.n.n, and a device with no IPv8 awareness is, by definition of this subset relationship, originating IPv8 packets whose RN field is zero. No reformatting, conversion, or translation is required for IPv4-only devices to interoperate with IPv8. This document forms part of a companion specification suite:

• draft-thain-ipv8-06 Core protocol (this document)
• draft-thain-routing-protocols-06 BGP8, IBGP8, OSPF8, IS-IS8, CF
• draft-thain-support8-06 ARP8, ICMPv8, Route8, ACL8, DNS8
• draft-thain-rine-03 Regional Inter-Network Exchange
• draft-thain-zoneserver-03 Zone Server Architecture
• draft-thain-whois8-03 WHOIS8 Publication and Registration
• draft-thain-netlog8-06 NetLog8 Protocol
• draft-thain-ipv8-mib-02 IPv8 MIB and SNMPv8
• draft-thain-wifi8-01 WiFi8 Protocol
• draft-thain-update8-02 Update8 and NIC Certification

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

Terminology This section defines terms used throughout the IPv8 specification suite. Companion documents inherit these definitions and define additional terms specific to their scope. Route Number (RN). The 32-bit field forming the upper half of an IPv8 address. The Route Number identifies the Autonomous System (AS) within which the lower 32 bits of the address are significant. The Route Number is structurally analogous to a postal-code or telephone area-code: it routes to an administrative domain and is not itself an IP address. RN values are 32-bit identifiers compared by exact match; RNs do not have prefix-length semantics. Local Address (LA). The 32-bit field forming the lower half of an IPv8 address. The Local Address is an IPv4 address within the Route Number's space. Written as n.n.n.n in placeholder form. Prefix lengths in IPv8 apply to the Local Address field only and have the range 0 to 32, identical to IPv4 prefix length semantics. Locator. An IPv8 address rendered in its canonical hyphenated textual form <RN>-<LA>. See § for the rendering rules. Autonomous System Number (ASN). Per . The Route Number field MAY carry an ASN value, in which case <RN> represents the 32-bit ASN. The terms Route Number and ASN are used interchangeably throughout this suite when context permits; RN is preferred when describing the addressing field as an abstract identifier, ASN is preferred when describing its binding to BGP allocation. IPv4-Compatible Form. An IPv8 address with <RN> = 0. The address is bit-identical to its lower 32 bits interpreted as an IPv4 address. IPv4 packets are IPv8 packets in IPv4-Compatible Form. Cost Factor (CF). The IPv8 inter-AS path-quality metric specified in . CF combines observed round-trip time, loss, congestion, stability, capacity, economic policy, and geographic distance into a single scalar carried in BGP8 path attributes between PEs and across AS boundaries, where it is used for inter-AS path selection. CF input observations are collected by implementations within the AS and propagate via a slow-slew adjustment mechanism analogous to NTP clock-slew, providing damping against rapid oscillation in inter-AS path selection. Operator policy adjustments to CF inputs (such as economic-cost weights) are made by explicit operator action; the slew governs how observed inputs and operator adjustments together propagate through the network. CF does not replace the interior routing protocols' native metrics. OSPF cost, IS-IS metric, EIGRP composite metric, IBGP local-preference, and MED continue to govern intra-AS path selection, and operators' existing tuning of those metrics is preserved unchanged by IPv8 adoption. The IGP CF Export Interface specified in contributes intra-zone cost as a CF input to IBGP8, where it is combined with external CF to choose the best edge router for inter-AS destinations; this contribution does not alter intra-AS shortest-path computation, which continues to use the IGP's native metric. CF is designed to accumulate measurement history over time. As the measurement substrate matures and operators gain confidence in CF's accuracy across a range of operational conditions, CF might eventually become sufficient to drive interior path selection as well, retiring some of the human metric-tuning effort that currently goes into intra-AS configuration. Such a transition is not specified by the current suite and is not required for IPv8 adoption; it is noted here as a possible future direction contingent on operational experience with CF in the inter-AS role. Detailed CF semantics, measurement collection, the IGP CF Export Interface, and the slewing behaviour are specified in . RINE. Regional Inter-Network Exchange, specified in . RINE defines fifty geographic regions with bounded round-trip time and provides the inter-AS peering substrate for IPv8 with stricter admission policy than a typical internet exchange. Sun Tzu. The Neighbor Trust Verification mechanism specified in . Sun Tzu accumulates per-peer trust scores based on observed behaviour and triggers state transitions governing route acceptance. Zone Server. The unified network-services platform specified in . Each Zone Server pair (.254 active even, .253 active odd) provides DHCP8, DNS8, NTP8, NetLog8, OAuth8, ACL8, XLATE8, and Route8 management for the local zone. WHOIS8. The IPv8 management server protocol specified in . WHOIS8 ties RPKI, RDAP, RIR delegation, and operator management infrastructure (BSS/OSS) into a single management surface for routing and trust state. Specification of WHOIS8 is deliberately held pending the evolution of the underlying standards it composes. The function it provides --- confirming that a Route Number is allocated and entitled to originate a prefix --- is already met by RPKI , RPKI origin validation , and RDAP , together with the RIR delegated-statistics data; a Zone Server uses these existing mechanisms directly (an RPKI validator feeding the routing process, RDAP and delegation data for allocation). WHOIS8 will be specified as a thin profile of how a Zone Server composes those mechanisms for Route Numbers once the relevant standards (notably ASPA-based path validation) have settled, rather than as a parallel protocol defined ahead of them. XLATE8. The IPv8 forwarding-plane engine at administrative boundaries, specified in . XLATE8 operates four modes over a unified state-table substrate: native IPv8 forwarding, 4-to-8 translation (IPv4-only host origination through an IPv8-aware boundary), 8-to-4 translation (IPv8 egress to RN 0 or other IPv4-only destinations), 8-to-8 NAPT (many-to-fewer translation between RN namespaces, typically at security boundaries), and 8-over-IPv4 encapsulation across IPv4-only transit. Each Zone Server, edge router, firewall, and end-host stack participates in XLATE8 as required by its position in the topology; the modes are selected per-flow by the configured policy. ACL8. The IPv8 policy expression and enforcement mechanism specified in and . ACL8 supports first-class matching on the RN field, enabling AS-aware policy expression at line rate. Route8. The unified routing table specification in . Route8 holds IPv4 routes (as IPv8 routes with <RN> = 0) and IPv8 routes in a single table, organised as per-RN VRFs (see §). Anycast Route Origin Authorisation (AnycastROA). The signed object specified in authorising a specified set of ASes to originate a given WHOIS8 anycast prefix. Sibling to RPKI Route Origin Authorisations . An RN is a fancy VRF. The operator-facing one-liner that governs how IPv8 maps onto existing forwarding-plane infrastructure. Each RN is realised on participating routers as a VRF named by convention vrf ipv8-asn-<RN> with route distinguisher <RN>:65535. Routes within an RN are IPv4 routes within that VRF, populated by whichever interior protocols the operator runs (OSPF, IS-IS, EIGRP, IBGP, static). Inter-RN routing is BGP8 over the union of these VRFs. See § "BGP8 Routing Table".

Locator Rendering An IPv8 address rendered for human consumption uses the canonical hyphenated form <RN>-<LA>. The hyphen is a fixed visual separator that distinguishes the Route Number portion of the address from the Local Address portion. Implementations MUST accept this canonical form on input and MUST emit it on output.

RN Portion Rendering The Route Number portion of the locator is rendered as follows:

• If the leading octet of the Route Number is zero, the RN is rendered as the decimal integer value of the 32-bit Route Number. Examples: 15169-8.8.8.8, 7214-10.20.30.40, 64500-192.0.2.1.
• If the leading octet of the Route Number is non-zero, the RN is rendered as four dotted octets. Examples: 127.10.60.10-10.0.0.1 (private internal), 222.0.0.1-1.1.1.1 (interior link), 100.5.3.7-203.0.113.20 (RINE peering).

This rendering is automatic, reversible, and self-managing. ASN allocations are concentrated in the lower 24 bits of the 32-bit ASN space (approximately 128,000 ASNs allocated globally as of 2026, all within the lower 24 bits). For these allocations the leading octet is always zero, and rendering them as decimal integers matches operator expectations from the BGP ecosystem. Reserved ranges within the upper octets (such as 127.r.r.r for private internal use, 100.r.r.r for RINE peering, 222.r.r.r for interior link conventions) have non-zero leading octets and naturally render in dotted form. As ASN allocation eventually crosses 2^24, dotted rendering takes over for those allocations without specification change.

LA Portion Rendering The Local Address portion is always rendered as a dotted IPv4 quad. Standard IPv4 rendering rules apply. The LA portion is always four dotted decimal octets; the LA is never compressed, abbreviated, or rendered in any form other than the four-octet IPv4 representation.

Prefix Length Notation Prefix lengths apply to the Local Address portion only. The notation <RN>-<LA>/N denotes the IPv8 prefix consisting of the specified Route Number <RN> combined with the LA /N IPv4 prefix. Examples: 15169-10.0.0.0/8 (the 10.0.0.0/8 prefix within RN 15169), 127.10.60.10-10.20.30.0/24 (the 10.20.30.0/24 prefix within RN 127.10.60.10). Prefix lengths greater than 32 are not defined. Prefix lengths that would notionally extend across the RN boundary have no semantic meaning and MUST be rejected by implementations. The Route Number itself is not subnettable; RN values are identifiers compared by exact match, not prefix-matched.

Storage and Wire Format Are Independent The hyphenated rendering is a display-layer convention. Implementations MAY store IPv8 addresses internally in any format (8-byte binary, packed structure, struct-of-fields, etc.) and MAY accept additional input formats for backward compatibility with earlier draft notation. The wire format specified in § is always the full 64-bit pair regardless of how the address is rendered.

ASN Simplification Configuration Implementations MUST provide a configuration option named asn-simplification (or vendor-equivalent), default enabled. When enabled, the rendering rule above applies (integer form for leading-zero RNs, dotted form for non-zero-leading RNs). When disabled, all RNs render in full dotted form regardless of the leading-octet value, suppressing RN integer compression for diagnostic purposes such as packet capture analysis or wire-format debugging. The asn-simplification setting affects display only; it does not alter the encoding of addresses on the wire, in routing tables, in JSON representations, or in protocol exchanges. Two implementations with different asn-simplification settings interoperate correctly; they differ only in how they present addresses to operators.

Architecture Overview

The Postal-Code Framing The Route Number is the postal code of the internet. It is a 32-bit identifier that routes to an administrative domain (an Autonomous System) and disambiguates Local Addresses that would otherwise collide. Approximately 128,000 ASNs are currently allocated globally; under IPv4, every one of those ASes can have a host at 8.8.8.8 or 10.0.0.1, and operators rely on Network Address Translation at administrative boundaries to hide the duplication. Under IPv8, 15169-8.8.8.8 and 64500-8.8.8.8 are distinct addresses in Route8 and never collide. The Route Number resolves at routing time what NAT resolves at boundary translation time. The postal-code framing extends to operational behaviour. Prefix lengths apply only to the Local Address field --- there is no concept of subnetting across the RN boundary, just as there is no concept of subnetting across a postal code in mailing-address syntax. The RN is a different kind of identifier than the LA, and the spec preserves that distinction throughout.

An RN is a Fancy VRF The data-plane realisation of IPv8 maps onto existing operator-deployed forwarding-plane infrastructure. Each RN is a VRF on participating routers, named by convention vrf ipv8-asn-<RN> with route distinguisher <RN>:65535. Routes within an RN are IPv4 routes within that VRF, populated by whichever interior routing protocol (OSPF, IS-IS, EIGRP, IBGP, static) the operator runs. The RN identity is established by the VRF context of the interface, not by per-packet labelling at the IPv4 layer. This framing has three structural consequences:

• Existing silicon carries IPv8 without modification. The MPLS L3VPN forwarding pipeline already provides per-VRF FIB lookup at line rate. IPv8 traffic at the wire is either plain IPv4 within a VRF or an IPv8-in-IPv4-encapsulated payload traversing a generic IPv4 path; neither presents a new forwarding case to deployed ASICs.
• Operators already understand the model. Every multi-tenant enterprise and every Tier-1 carrier already operates with multiple VRFs per router for customer L3VPNs, security zones, operational separation, and compliance scoping. IPv8 names the VRF identifier (the RN) at the inter-AS layer rather than requiring a new mental model.
• Internal segmentation is unchanged. The VRFs an operator uses today for their hospital network, phone system, payroll segment, and similar internal compartments continue to operate unchanged. These VRFs are operator-internal and not part of the public IPv8 routing system. IPv8 specifies inter-RN routing only; intra-RN segmentation and the VRFs used to realise it are out of scope and continue under existing IETF L3VPN mechanisms .

Two operational properties follow from the VRF framing: Intra-zone traffic is mostly native. Within an AS that has deployed IPv8, the bulk of traffic travels either as native IPv8 within the ipv8-asn-<RN> VRF or as plain IPv4 (the IPv4-Compatible Form) on segments where the Primary RN matches the source's RN. Encapsulation is the transition mechanism, not the steady state: IPv8-in-IPv4 encapsulation applies specifically to segments and paths where IPv8 has not yet reached native deployment. As an AS's IPv8 deployment matures and more routers gain native IPv8 capability, the fraction of traffic carried via encapsulation decreases monotonically. The end-state of full intra-AS IPv8 deployment has no encapsulation; encapsulation is exercised only at boundaries with peers that themselves have not yet completed transition. Routers host only the RNs they advertise. A router maintains a local VRF (and the associated include rn configuration under address-family ipv8) only for RNs whose routes that router originates or terminates. RNs whose routes the router merely transits via BGP8 path-vector propagation do not require local VRFs. The Route8 table () carries RIB entries for these transit RNs but does not maintain a forwarding context for them; transit packets are forwarded based on the next-hop BGP8 attribute, not via a local VRF lookup. This bounds per-router state to the RN footprint the operator has actually committed to host, not to the cardinality of the global IPv8 routing system. Detailed BGP8 VRF mechanics, advertisement units, and the relationship between VRF state and the RIB/FIB are specified in § "BGP8 Routing Table".

Adding an RN to an Interface The operator-facing behaviour of IPv8 deployment on a host or router is that assigning an IPv8 address to an interface is the complete configuration operation. The platform performs the remaining setup automatically:

1. VRF auto-creation. If a VRF named ipv8-asn-<RN> does not exist on the device, the platform creates it with route distinguisher <RN>:65535 per convention. If it already exists, the new address binding adds to the existing VRF.
2. Interface binding. The interface is bound to the VRF as either a Primary or Secondary RN binding. The first RN assigned to the interface is the Primary; subsequent RN assignments are Secondaries.
3. Default route inside the VRF. The platform populates the VRF's default route from DHCP8 (option 222 carries the RN assignment and the standard DHCP gateway field carries the gateway address) or from static configuration. The result is that traffic in this VRF's context flows toward this gateway by default.
4. Capability participation. The interface begins participating in ARP8 (with the dual-probe sequence specified in ), DNS8 lookups in the VRF's context, and ACL8 enforcement per the VRF's bound policy.

No separate VRF provisioning commands are required. The operator types one configuration line per RN per interface (or one line for the address, with the platform inferring the RN from the address structure); the platform handles the rest.

Two Paths to the Internet A host or router holding addresses in multiple RNs has multiple potential paths to the internet — one through each VRF's default gateway. The selection between paths is determined by the RN context of the traffic, not by any general path-preference configuration:

• Traffic in the Primary RN's VRF flows through the Primary RN's default gateway. This is the host's "native" path. IPv4 traffic without explicit IPv8 framing uses this path because IPv4 has no RN awareness; the segment's Primary RN supplies the implicit context.
• Traffic in a Secondary RN's VRF flows through that Secondary RN's default gateway. This path is used when an application explicitly places traffic in the Secondary RN's context — for example, by opening an AF_INET8 socket bound to a Secondary RN's address, or by being launched in a per-profile network namespace bound to that Secondary RN.
• Outbound traffic without explicit RN context routes through the Primary RN's path. The Secondary RN's path is available but is not selected by default. This matches the operator's mental model: the host is primarily on its native network and is also reachable on the secondary network for specific purposes; general-purpose traffic should follow the native network.

A host with a Primary RN binding to its corporate network and a Secondary RN binding to a management plane therefore has two paths to the internet (one through each gateway) but uses the corporate path by default for ordinary traffic and the management path only for traffic explicitly bound to the management RN. The two paths share the same physical infrastructure (one set of Ethernet interfaces, one set of switches) with VRF isolation keeping their routing contexts separate. Whether a Secondary RN's gateway actually has internet reachability is an operator policy decision encoded in the Secondary RN's VRF configuration. Some operators deploy internet-isolated Secondary RNs (a management plane that should not be reachable from the public internet); others deploy Secondary RNs with internet reachability through alternative transit (for redundancy or policy reasons). The architecture does not dictate either choice; it provides the per-RN VRF context in which the operator's policy is enforced.

Ride Existing Infrastructure, Signal at the Edges IPv8 is designed so that existing IPv4 infrastructure carries IPv8 traffic without modification. The principle:

• Forwarding silicon (commodity ASICs in deployed routers) does not change. IPv8 traffic crosses these chips encapsulated in IPv4, and the chips forward the IPv4 envelope using their existing IPv4 lookup logic. The IPv4 protocol field carries an IPv8-in-IPv4 indication that is irrelevant to the forwarding decision.
• BGP4 routing does not change. ASes that have not deployed BGP8 still carry IPv8 reachability by running an ordinary BGP instance inside each ipv8-asn-<RN> VRF (the standard L3VPN pattern per ). Routes within the VRF are IPv4 routes within the RN's address space; the RN identity is supplied by the VRF context, not by an attribute on the routes themselves. Unupgraded transit routers see ordinary IPv4 routes inside a VRF and forward them with existing L3VPN machinery.
• DNS, RPKI, and DNSSEC do not change. IPv8 publishes records using new resource record types and signed object types that ride within existing DNS and RPKI publication infrastructure.
• Operator administrative procedures do not change. RIR delegation, AS allocation, and RPKI signing operate exactly as they do for IPv4 today; IPv8 introduces new signed object types within the existing trust chain.

The IPv8-specific behaviour is implemented in software at the edges of forwarding paths: at endpoints originating or terminating IPv8 packets, at boundaries between IPv8-aware and IPv4-only forwarding spans, and at trust-validation points consuming RPKI and DNSSEC outputs. The core of the internet --- the millions of routers and switches in transit and access networks worldwide --- carries IPv8 traffic without any modification or awareness that IPv8 exists. This is the property that makes incremental adoption tractable. An AS can begin participating in IPv8 with software changes at one BGP edge router and one RPKI signing operation, with no expectation that any peer or transit provider has done anything at all.

Minimum Deployment Unit The minimum deployment unit for IPv8 participation is one BGP8-capable edge router per AS, advertising that AS's WHOIS8 anycast prefix into the surrounding BGP4 fabric. With this single upgrade:

• The AS becomes reachable as an IPv8 destination from any IPv8 source on the internet.
• All other routers within the AS continue to operate as IPv4 routers without modification.
• All hosts within the AS continue to operate as IPv4 hosts without modification, communicating via the IPv4-Compatible Form of IPv8 addressing.
• The IPv4 internet between the AS and any IPv8 source is unchanged and unaware.

Edge routers participating in the public IPv8 routing system MUST maintain IPv4 connectivity sufficient to serve as 8-over-4 encapsulation endpoints and to be reachable from IPv4-only peers. This requirement applies during the IPv8 transition period and may be relaxed in future revisions when global IPv8 adoption renders IPv4 transit unnecessary. Hosts MAY independently opt into IPv8 capability by deploying an IPv8-aware network stack (a software upgrade), at which point they originate native IPv8 packets and participate in IPv8 addressing. Host opt-in is independent of any network operator's decision to deploy IPv8; an IPv8-capable host on a purely IPv4 network can reach any IPv8-participating AS through the encapsulation rules specified in .

Per-Segment RN Invariant Every Layer 2 broadcast domain or point-to-point link is associated with exactly one Primary RN. This invariant underlies the wire-format rule specified in § and the ARP8 Primary RN Discovery mechanism specified in . IPv8 Local Addresses MUST be unique within one broadcast domain, irrespective of RN. Every IPv8 host also runs an IPv4 stack that answers ARP for its Local Address, and ARP resolves on the LA alone; two hosts sharing one LA on one segment therefore collide at ARP no matter which RNs they are bound to. Local Addresses are reused freely across broadcast domains (the same 10.0.0.0/8 space appears on every floor and in every site) but never within one. An implementation that detects two distinct link-layer addresses answering for one LA on one segment --- whether via ARP or ARP8, and whatever their RNs --- MUST treat the Local Address as duplicated: it MUST NOT forward to either claimant, and it MUST raise a duplicate-address alarm (logged, counted, and signalled to the Zone Server). A Zone Server MUST probe a candidate Local Address (ARP, sender 0.0.0.0, per ) before assigning it, and a DHCP8 client that observes a conflict MUST decline the offered address. This makes LA uniqueness a detected-and-reported configuration constraint rather than a silent failure mode.

• Every IPv4 address on every interface attached to the segment MUST be in that Primary RN. IPv4 has no Route Number awareness; an IPv4 packet on the segment is interpreted in the segment's Primary RN by virtue of segment membership. Two IPv4 addresses on the same segment claiming to be in different RNs would break IPv4 forwarding within the segment, so the invariant is hard.
• Every IPv8-aware interface attached to the segment MUST have its Primary IPv8 address in that same Primary RN. The interface's identity-of-record is in the segment's RN; this ensures that the Primary IPv8 address and the IPv4 address (where present) refer to the same RN identity and that the segment's wire-format rule operates consistently for both.
• An IPv8 interface MAY hold any number of Secondary IPv8 addresses in other RNs. Secondary addresses are IPv8-only: they are reachable only via ETH_P_IPV8 frames carrying the explicit RN, and only from IPv8-aware peers that have discovered the secondary identities via ARP8 or other mechanism. IPv4-only neighbours have no knowledge of secondary RN identities and cannot address them; traffic from IPv4-only endpoints to a peer's secondary RN identity is delivered via the Zone Server, which performs XLATE8 translation between the IPv4 representation and the secondary IPv8 identity.
• A device participating in multiple Primary RNs MUST use multiple distinct interfaces (or VLAN-tagged sub-interfaces), one per segment, with each segment carrying exactly one Primary RN. Multiple RNs MAY share physical infrastructure through Layer 2 isolation mechanisms (VLAN tagging, MPLS, etc.); the per-segment-one-RN invariant is preserved because each L2-isolated logical segment is its own segment for purposes of the invariant.

Implementations MUST validate this invariant at configuration commit time and SHOULD detect runtime violations (such as a misconfigured neighbour claiming a conflicting Primary RN) via the ARP8 Primary RN Discovery mechanism, reporting violations via NetLog8.

Forwarding Silicon Compatibility IPv8-in-IPv4 encapsulation is designed to traverse existing forwarding silicon transparently. The encapsulated packet presents to forwarding ASICs as a standard IPv4 packet to a standard IPv4 destination, with an IPv4 protocol field value indicating the IPv8 payload. Because forwarding decisions in IPv4 silicon are based on the destination IPv4 address, not on the protocol field, IPv8 traffic is forwarded at line rate by silicon that has no awareness of IPv8. The MPLS L3VPN forwarding pipeline provides the matching per-VRF lookup behaviour for native IPv8 traffic within an AS. A router with native IPv8 awareness performs forwarding by selecting the VRF corresponding to the destination RN and performing an IPv4 longest-prefix-match lookup on the destination LA within that VRF. This is the same operation that existing L3VPN-aware silicon already performs for MPLS-labelled traffic; the only difference is the source of the VRF identity (an IPv8 packet's RN field rather than an MPLS label). This property is structural rather than incidental. The encapsulation design is constrained to preserve it: any mechanism that required new silicon support to operate would introduce a deployment dependency on hardware refresh cycles, which are measured in capital-expenditure timescales. By constraining the IPv8-specific behaviour to the encapsulating endpoint and the decapsulating endpoint --- both software --- existing silicon carries IPv8 traffic without modification indefinitely. Future hardware MAY accelerate native IPv8 forwarding (processing 64-bit <RN>-<LA> lookups directly without encapsulation overhead). Such hardware is not a precondition for IPv8 deployment and is expected to emerge through normal vendor product cycles in response to deployed IPv8 traffic volumes.

Trust-State Operational Pattern Trust-state data in the IPv8 suite --- including AnycastROA filter lists, WHOIS8 server certificate trust stores, RIR trust anchors, RINE region membership, and Sun Tzu peer trust baselines --- is updated via explicit operator command rather than automatic background refresh. This pattern is selected over automatic refresh for three reasons:

• Operator agency: explicit update is a deliberate action with a known timestamp, allowing the operator to investigate changes before installing them and to correlate router behaviour changes with specific update events.
• Auditability: explicit updates produce discrete events in NetLog8, syslog, and operator change-management records; automatic refresh produces a continuous stream of state changes that is harder to audit after the fact.
• Blast-radius limitation: a compromised upstream data source affects only operators who happen to refresh during the compromise window; with automatic refresh, every operator's router accepts the compromise simultaneously.

Implementations SHOULD provide separate operations for verification (showing the diff between current upstream state and locally-installed state without modification) and update (installing the upstream state). Implementations SHOULD emit a console warning when locally-installed trust state has not been refreshed for a configurable interval (default: 7 days). The operation names are not normative; the separation of verify- from-update and the operator-initiated nature of update are the normative properties.

Identity-Driven Access Control IPv8 anchors access control on signed identity claims rather than on physical network position. Each authenticated client holds a JSON Web Token (JWT) issued by OAuth8 containing claims for user identity, device identity, session context, and authorised access scopes. ACL8 enforcement points validate the JWT at each access decision and apply policy based on the token's claims, independently of which physical network the client is connected to. OAuth8/JWT in IPv8 occupies the role that RADIUS occupies in classical enterprise network AAA: it is the authentication, authorisation, and accounting substrate for network access. OAuth8/JWT is the modern equivalent, using the same identity infrastructure (OAuth2 , OpenID Connect, JWT ) that already underpins web and API access control in contemporary deployments. Operators familiar with RADIUS-based 802.1X port authentication will recognise the role; the difference is that the identity assertion is a signed JWT rather than a RADIUS attribute exchange, and the enforcement point is ACL8 at the IPv8 layer rather than a port-state machine at the switch.

Pre-Authentication Holding State and the Displacement of 802.1X IPv8 displaces 802.1X as the enterprise network admission mechanism. 802.1X is a Layer 2 port-state machine: it requires a supplicant on the endpoint (absent on much equipment), a RADIUS back end, and switch-side support, and even when all three are present it gates only the switch port. IPv8 moves admission to Layer 3 and makes it a property of a signed identity rather than of a physical port. A device that has not yet authenticated is placed by DHCP8 in a holding RN --- a reserved internal Route Number --- and issued a host route (a /32 Local Address) whose only reachable next hop is the Zone Server. From this confined address the device can reach the Zone Server's authentication endpoint and its resolver, and nothing else: there is no route out of the holding RN, no path to peers on the segment (the /32 has no on-link neighbours), and no default route. Confinement is thus the absence of a route, not a firewall rule that can be misconfigured to fail open. The device authenticates over Layer 3 by presenting an OAuth8 JWT to the Zone Server (for example over EAP-TTLS where 802.1X port control is also present, or directly over HTTPS where it is not). The Zone Server validates the token exactly as it validates any JWT at the management interface --- signature against the OAuth8 issuer, expiry, and scopes --- and reads the authorised Route Number from a token claim. On success it rebinds the device from the holding RN into the RN its identity is entitled to, and normal forwarding begins. Because the RN derives from the validated claim and not from a port lookup, the assignment travels with the token and is revoked by revoking the token. Because authentication is an ordinary Layer 3 exchange to a confined address, it works on any device with a web client and requires no supplicant, no RADIUS server, and no switch cooperation; it is the mechanism a captive portal already proves works universally, extended so that the outcome is Route Number assignment rather than mere internet unlock. The Zone Server MAY federate the authentication to any external OpenID Connect provider, so an enterprise uses its existing identity provider and a visitor signs in with a consumer account (e.g. Google), each mapped to the Route Number its verified identity warrants. A device that cannot present a token --- a printer, camera, or other appliance --- remains in the holding /32, or is placed by MAC Authentication Bypass into the pnp class RN. This is the honest security boundary of the model: token-bearing devices are authenticated into their RN, while tokenless devices are placed into one by operator policy and never promoted by self-assertion. This same mechanism operates without IPv8: a plain IPv4 DHCP server can issue the confined /32, redirect the device to the Layer 3 authentication flow, and on success renumber it into the appropriate VLAN. IPv8 deployments substitute Route Number assignment for VLAN assignment as the admission outcome; the holding-state-and-Layer-3-auth flow is identical. An operator MAY therefore adopt the admission mechanism in an IPv4 network and gain the Route Number behaviour later without changing the authentication path. Detailed mechanism, including JWT claim format, ACL8 rule grammar and worked examples, vNIC and profile abstractions for user-facing identity selection, per-profile egress routing, DHCP8 lease behaviour for JWT-driven VLAN assignment where operators choose to deploy VLANs, Zone Server federation across deployment sites, session lifecycle, and revocation propagation, is specified in . ACL8 rule evaluation, default-deny posture, and audit logging are specified in §ACL8.

Per-Interface Mode Each IPv8-aware interface operates in one of four modes, set at boot from DHCP8 option 223 or operator configuration:

• normal --- standard peer-to-peer operation, ARP8 dual- probe active, LLDP fires, firewall does policy enforcement, full IPv8 capability exposed. Suitable for typical end-user workstations and business application servers.
• strict --- concealed-host operation, only gateways visible on L2, no LLDP, gateway-mediated peer traffic, DNS- driven destination authorisation. Strict-mode interfaces refuse to forward to destinations that do not have a recent DNS resolution backing them, closing off direct-to-IP exfiltration paths. Suitable for production servers, finance/healthcare endpoints, and anything where the policy is well-defined and deviations are anomalies.
• pnp (plug-and-play) --- permissive operation for devices needing service discovery and broad outbound traffic patterns; PnP multicast (mDNS/SSDP/WS-Discovery/LLMNR) permitted, registered with the segment's ACL server so guest segments can reach published services. Suitable for printers, IoT devices, appliances, and anything that needs to "just work" when plugged into a network without complex configuration. This mode is referred to as "printer" in earlier drafts; the rename to "pnp" reflects that the same operational profile applies to all plug-and-play appliances, not only printers.
• guest --- isolation from internal RNs; outbound to RN 0 (the public IPv4 internet) and to registered pnp services on the segment; minimal inbound. Suitable for visitor devices, BYOD hosts not yet authenticated to the corporate identity system, and any endpoint where network access is granted but device trust is not.

Mode is immutable during a session; mode change requires interface reset (typically a reboot). Detailed mode semantics, the strict-mode DNS-authorisation rule, and the pnp-mode multicast registration mechanism are specified in §ACL8 and .

Performance and Error Telemetry The IPv8 suite's operational telemetry substrate is NetLog8 , which records performance metrics (link utilisation, CPU and memory load, throughput, latency, queue depth, heartbeat round-trip times sampled at configured intervals), error events (link drops, packet errors, route holds, AnycastROA rejections, ACL8 denies, configuration application failures, hardware faults), security alerts (failed authentications, rejected routes, AnycastROA mismatches, certificate validation failures, peer trust-score decrements), routing changes, configuration changes, and session-level accounting (5-minute byte-counter intervals per active session for billing and capacity planning). NetLog8 does not log traffic content, per-flow data, or routine successful authentications. A user's already-valid JWT presenting to ACL8 on each access decision produces no NetLog8 event; only the rare moments of JWT issuance at session start and authentication failures are recorded. This deliberate exclusion of routine successful events distinguishes NetLog8 from authentication logging in operating systems such as Windows NT, where thousands of routine authentication entries per hour bury the small number of events that operators actually need to investigate. NetLog8's volume is bounded by what an operator acts on, not by what the network is doing. The signal-to-noise ratio is high by design. The volume scoping permits cryptographic integrity guarantees on the audit stream that would not be feasible at line rate for traffic data. Traffic-content logging is the responsibility of the operator's chosen traffic-inspection infrastructure (corporate firewalls, IDS/IPS, scrubbing services, NetFlow collectors), which operates independently of NetLog8. Operators integrate NetLog8 with their existing observability stack (SIEM, SOC tooling, performance monitoring, alerting) via the standard NetLog8 export mechanisms specified in .

Address Format

Structure An IPv8 address is a 64-bit identifier formed of two 32-bit fields: The Route Number occupies the upper 32 bits. The Local Address occupies the lower 32 bits. The two fields are independent identifiers serving different functions: the RN identifies an administrative domain (an AS), and the LA identifies an address within that AS's space. The canonical textual rendering is the hyphenated locator form <RN>-<LA> specified in §.

Prefix Length Semantics Prefix lengths in IPv8 apply to the Local Address field only, with range 0 to 32. The notation <RN>-<LA>/N denotes the IPv8 prefix consisting of the specified Route Number <RN> combined with the LA /N IPv4 prefix. Prefix lengths greater than 32 are not defined; prefix lengths that would notionally extend across the RN boundary have no semantic meaning and MUST be rejected by implementations. The Route Number is not subnettable. There is no concept of an "RN prefix" that subdivides the RN field across IPv8 prefixes, because the RN is an administrative-domain identifier rather than an address-space coordinate. RN values are allocated by the IANA registry process specified in §, not by prefix delegation. References to "RN block" in this document and in the IPv8 suite (such as the 127.r.r.r block reserved for private internal use) refer to categorical filters on the leading octet of the RN field, not to prefix-matched ranges.

IPv4 Representation in IPv8 An IPv8 address with <RN> = 0 is the IPv4-Compatible Form. The address is bit-identical to its lower 32 bits interpreted as an IPv4 address. In rendered form, an IPv4-Compatible IPv8 address renders as 0-n.n.n.n (the integer-RN form with RN value 0). For consistency with established IPv4 notation, implementations MAY render IPv4-Compatible addresses in the equivalent n.n.n.n form (omitting the explicit RN). Both renderings are interchangeable; on the wire they encode identically. A device with no IPv8 awareness is, by virtue of the subset relationship, originating IPv8 packets in IPv4-Compatible Form. No conversion or encapsulation is performed at the originating device; the IPv4 packet is the IPv8 packet whose RN field is implicitly zero. Receivers of such a packet MAY treat it as IPv4 (under existing IPv4 semantics) or as IPv8 (under IPv4- Compatible Form semantics). The two readings produce identical results because the bytes on the wire are identical. The Route Number namespace as a whole is partitioned into the reserved blocks specified in §. RN 0 is reserved within the IPv4-Compatible Form block (the lower 24 bits of which constitute the RIR-allocated conventional ASN pool); the other reserved blocks are described below.

Reserved Route Number Blocks The Route Number namespace is partitioned by the leading octet of the 32-bit RN value into reserved blocks with distinct operational semantics. The partitioning is categorical (a match on the leading octet), not prefix-based; RN values within a block share an operational policy but are not aggregated by prefix matching. The complete reservation table is as follows. Blocks marked "Active" are defined by the current IPv8 suite. Blocks marked "Reserved, policy TBD" are held by IANA pending future allocation policy.

Leading Octet	Designation	Status
0	RIR-allocated conventional ASN pool (lower 24 bits of 0.r.r.r)	Active
1--32	Super-scalar allocation (1M+ customer base, $25M/year)	Reserved, policy TBD
33--99	IANA-reserved	TBD
100	RINE peering	Active
101--109	IANA-reserved	TBD
110--111	ARIN sub-RN pool	Reserved, policy TBD
112--113	RIPE sub-RN pool	Reserved, policy TBD
114--115	APNIC sub-RN pool	Reserved, policy TBD
116--117	LACNIC sub-RN pool	Reserved, policy TBD
118--119	AFRINIC sub-RN pool	Reserved, policy TBD
120--126	IANA-reserved	TBD
127	Private internal	Active
128--130	Cellular carrier (1M+ subscribers, $1M/year)	Reserved, policy TBD
131--221	IANA-reserved	TBD
222	Interior link convention	Active
223--255	IANA-reserved	TBD

The active blocks are specified as follows. 0.r.r.r (the IPv4-Compatible Form block). The lower 24 bits of this block (values 0 through 16,777,215) constitute the conventional RIR-allocated ASN pool. RN 0 itself is reserved as the IPv4-Compatible Form: the IPv8 address 0-n.n.n.n is the IPv4 address n.n.n.n. RN values 1 through 16,777,215 are allocated by the RIR system to AS holders under the existing ASN allocation procedures, unchanged from current IPv4 practice. 100.r.r.r (RINE peering). RN values whose leading octet is 100 are reserved for Regional Inter-Network Exchange peering prefixes, allocated per . RINE-block RNs have a structured assignment 100.<region>.<ix>.<operator> administered by the RINE peering authority. Routers SHOULD filter eBGP8 advertisements carrying RNs in this block from peers other than authorised RINE peering points; RINE delivers reachability by topology rather than by advertised RN. 127.r.r.r (private internal). RN values whose leading octet is 127 are reserved for private internal allocations. Operators MAY use any RN value within this block for internal addressing within their own administrative domain without external coordination. RNs in this block MUST NOT be advertised beyond the originating AS. Routers receiving an inter-AS advertisement carrying an RN with leading octet 127 MUST reject the advertisement and SHOULD log the event via . Private internal RNs are the IPv8 analog of RFC 1918 private IPv4 address ranges; they are operationally appropriate for home networks, lab environments, internal corporate zones, and any context where global addressability is not required. 222.r.r.r (interior link convention). RN values whose leading octet is 222 are reserved for bilateral private interior link addressing and inter-organisation private interconnection. The block provides 2^56 distinct RN values, adequate to enumerate every point-to-point interior link in any deployment without coordination conflict. Routes carrying RNs in this block default to NO_EXPORT and NO_ADVERTISE treatment in BGP8; internal addressing conventions within the block are operator-arbitrary and are not prescribed by this specification. Documentation address blocks. The IPv4 documentation ranges 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 from retain their IPv4 documentation-example semantics within IPv8 in any RN context. They MUST NOT be used in production networks.

Address Classes

Unicast A unicast IPv8 address identifies a single interface on a single device. Packets sent to a unicast address are delivered to that interface only. Unicast is the default address class.

Anycast An anycast IPv8 address identifies a service published from multiple network locations. Packets sent to an anycast address are delivered to the nearest of the published locations as determined by routing-protocol path selection. The IPv8 suite makes specific use of anycast in two contexts: the WHOIS8 infrastructure (where each AS publishes one or more anycast prefixes serving as inter-AS encapsulation destinations), and 8-over-IPv4 tunnel endpoint discovery (where DNS lookups under anycast.<RN>.asn.arpa and anycast.<RN>.asn.openipv8.org return the IPv4 anycast addresses of IPv8 PE routers participating in serving the queried RN). The trust and authorisation model for these anycast prefixes is specified in (AnycastROA mechanism).

Multicast Multicast addressing in IPv8 follows the conventions specified in §.

Broadcast Broadcast addressing in IPv8 is restricted to within the local subnet (LA portion) of an AS. Cross-AS broadcast is not defined; a packet whose LA is 255.255.255.255 MUST NOT be forwarded across any RN boundary.

IPv8 Packet Header

Header Format The header carries 32-bit Source Route Number, 32-bit Source Local Address, 32-bit Destination Route Number, and 32-bit Destination Local Address fields in place of IPv4's 32-bit source and destination address fields. All other header fields retain IPv4 semantics per . The Version field is 8 (IPv8). The IHL field measures the header in 32-bit words, including the four 32-bit address fields and any options. Minimum IHL value is 7 (28 bytes total header length without options).

Wire Format The wire format selection between native IPv8 frames (EtherType 0x8080, ETH_P_IPV8) and IPv4-Compatible frames (EtherType 0x0800, ETH_P_IP) is governed by whether the source needs to convey RN information explicitly:

• ETH_P_IP is used when the destination is reached at the segment's Primary RN. The RN context is implicit from the segment per the per-segment-RN invariant (§); the wire frame carries no explicit RN field. This is the case for all IPv4-only-to-IPv4-only traffic, for all Primary-RN-to-Primary-RN IPv8 traffic, and for any IPv4 packet on any segment.
• ETH_P_IPV8 is used when the destination is reached at any RN other than the segment's Primary --- whether the destination is on the same segment (one of a neighbour's Secondary RN identities) or off-segment (cross-boundary inter-RN traffic). The IPv8 header carries the explicit Source Route Number and Destination Route Number fields to disambiguate.

The choice is made per-packet by the sending IPv8 stack, based on the destination's RN identity as known from the ARP8 cache or other discovery mechanism. IPv4-only senders always emit ETH_P_IP frames because IPv4 has no RN concept; their traffic is interpreted in the segment's Primary RN. When an IPv8 address has <RN> = 0, the address occupies its full 64-bit field within the IPv8 header on the wire; the leading 32 zero bits are not compressed at the wire level. Wire format and textual rendering are independent: the rendering rules in § govern human display, while the wire format is always the full 64-bit pair within the header. A receiver MAY recognise that a received IPv8 packet has zero Source RN and zero Destination RN, in which case the packet is in IPv4-Compatible Form and MAY be processed via the IPv4 stack. This recognition is a pure-software optimisation and is not required.

Socket API Compatibility Existing IPv4 socket APIs (BSD sockets, Winsock, equivalents) operate without modification on IPv4-Compatible IPv8 traffic because the wire format of an IPv4-Compatible IPv8 packet is indistinguishable from an IPv4 packet at the wire layer. IPv8- aware socket APIs MAY expose the full 64-bit address through a new address family (the Linux reference implementation uses AF_INET8 = 46); such APIs are out of scope for this document and are specified in the IPv8 implementation guidance. The Linux reference implementation provides two forwarding modes, selectable per bound Route Number, so that one kernel serves both the native host/edge role and the provider-edge role:

• native --- the Route Number selects a bare forwarding table. No VRF device, route distinguisher, or MPLS label is created; the device owns nothing in any shared namespace. This is the mode for hosts and native IPv8 edges.
• vrf --- the Route Number is bound to a VRF device, so that received traffic is delivered into an ipv8-asn-<RN> VRF and the device acts as a Provider Edge for an existing L3VPN core (per ). A system operator creates the VRF and the device forwards the Route Number's traffic through the provider's existing VPNv4 distribution machinery.

The two modes share the wire format, the Route Number table, and the neighbour and translation machinery; they differ only in the forwarding target bound to a Route Number. An operator chooses native for a host or a standalone edge and vrf for a box stood up as a PE inside an MPLS network, and MAY move a Route Number between the two. L4 transport protocols (TCP, UDP, QUIC, SCTP) are address- family-agnostic at the protocol level and operate unchanged over either IPv4 or IPv8. There is no "TCP/IPv8" or "UDP/IPv8" as a distinct protocol; the transport state machines consume socket addresses without inspecting the address family. The same applies to ICMP and ARP: ICMP is one protocol with IPv8- extension behaviour for 64-bit addresses (see ), and ARP is one protocol with IPv8-extension behaviour for 64-bit address resolution (see §ARP8). The suite does not specify "TCP8", "UDP8", "ICMP8", or "ARP8" as separate protocols; these names refer to extensions of the existing protocols.

Coexistence and Deployment

Single-Stack Operation IPv8 deployment does not require dual-stack operation. An IPv8- aware device runs a single network stack that handles both IPv4-Compatible and full IPv8 traffic uniformly. There is no parallel IPv4 stack, no separate IPv4 routing table, and no mode-selection logic. This is structurally different from IPv6 deployment, which requires dual-stack operation throughout the deployment phase because IPv6 packets are not IPv4 packets and IPv4 packets are not IPv6 packets. In IPv8, IPv4 packets are IPv8 packets in the IPv4-Compatible Form; the same code paths handle both.

Relationship to IPv6 IPv8 specifies an extension of IPv4. This document defines IPv8 behaviour over IPv4 transport only. IPv6 is out of scope for this specification. IPv6 networks operate independently of IPv8 and require no modification to support IPv8 deployment elsewhere on the internet. IPv8 implementations have no IPv6-specific code paths, no dual-stack-with-IPv6 deployment mode, and no IPv6 capability negotiation. Where an operator's IPv4 infrastructure is internally implemented using IPv4-over-IPv6 transport (for example 4in6 , DS-Lite , 6rd , or carrier- internal IPv4-over-IPv6 backhaul), IPv8-in-IPv4 encapsulation traverses such transport as opaque IPv4 payload, identical to any other IPv4 traffic. IPv8 has no awareness of the underlying IPv6 transport and behaves identically whether the IPv4 hop is delivered natively or via IPv6 tunnel. Encapsulation of IPv8 directly within IPv6 transport is not specified by this document. Such a specification, if pursued in the future, would be the subject of a separate Internet-Draft and is not contemplated by the current IPv8 work.

Typical Deployment Pattern A typical IPv8 deployment introduces Zone Servers as Provider Edge (PE) routers alongside the operator's existing IPv4 infrastructure. The Zone Server is a commodity Linux-based appliance running the kernel-level IPv8 forwarding stack () and the Zone Server userspace platform (). The operator's existing IPv4 network is unchanged --- no encapsulation overlay, no IPv6 dependency, no flag day --- and IPv4 traffic continues to flow natively while IPv8 capability is added at the edges.

Four-Step Deployment Recipe An ISP, enterprise, or other AS operator deploys IPv8 in four steps. The steps are independent of any other AS's deployment state; each AS deploys on its own schedule. Step 1: Create the IPv8-labelled IPv4 VRF. On the operator's existing routing infrastructure, create a VRF named ipv8-asn-<RN> (where <RN> is the operator's allocated ASN) following the convention specified in §. The VRF is realised on existing routing gear using the operator's existing VRF-aware platform (Cisco, Juniper, Arista, etc.); no new hardware is required at this step, and no IPv8-specific configuration is needed on the existing routers beyond creating and naming the VRF. Step 2: Stand up two Zone Servers. Deploy two Linux machines on commodity hardware as Zone Servers, configured as the active-active even/odd pair (.254 even, .253 odd) per . Each Zone Server connects to the IPv8 VRF created in Step 1. Step 3: Enable the minimum services and set the RN. Via the Zone Server CLI or web services interface, enable the minimum service set:

• ACL8 --- perimeter defense of the Zone Server itself. The Zone Server's anycast leg faces the public IPv4 internet by definition (it terminates the WHOIS8 anycast and the 8-over-IPv4 encapsulation endpoint); ACL8 is the policy layer that controls what reaches the Zone Server's management plane, restricts inbound traffic to the services the Zone Server is intentionally publishing, and enforces the operator's security posture against signed identity claims (§Identity-Driven Access Control). A Zone Server deployed without ACL8 is an unprotected Linux host on the public internet; ACL8 is non-optional.
• XLATE8 --- translation between IPv4-Compatible and native IPv8 traffic and between RNs (§Terminology).
• DNS (DNS8 with A8 record support per ) --- destination resolution and anycast endpoint discovery.

OAuth8/JWT is implicit in this set: ACL8 evaluates JWT claims issued by OAuth8, and the two services operate as a pair. Additional services (NetLog8 logging, WHOIS8 publication, NTP8, LLDP coordination, multicast querier roles, etc.) layer onto this minimum and are enabled as the operator's deployment matures. Set the RN on the Zone Server interface connected to the IPv8 VRF (ipv8-asn-<RN>) per the per-segment-one-RN invariant in §. This single declaration --- ipv8 rn <RN> on the IPv8-facing interface --- is the only IPv8- specific configuration the operator needs to provide for the common single-zone deployment. Step 4: Scale and publish. If the operator is deploying more than a single Zone Server pair (e.g., one ZS pair per PE site across a multi-site network), enable eBGP between the Zone Server pairs so they exchange IPv8 reachability across the operator's network. Publish the AS's WHOIS8 anycast prefix in DNS so external IPv8-aware peers can discover the AS's encapsulation endpoint (per ). For the default IPv8 gateway, the operator chooses one of two options: either designate the first PE's Zone Server pair as the IPv8 default gateway, or run an ordinary BGP instance inside the ipv8-asn-<RN> VRF so the existing L3VPN-aware routing fabric distributes IPv8 routes (per ) without requiring native IPv8 awareness on intermediate routers. After these four steps, the AS is IPv8-capable. The operator can reach IPv8 destinations elsewhere on the internet, accept inbound IPv8 connections from IPv8-aware sources, and originate or terminate IPv8 traffic within its own network. No other AS's deployment progress is required; an AS that completes these four steps in the absence of any other deployed AS interoperates via the IPv4-Compatible Form with unupgraded peers.

Physical Layout The reference deployment uses each Zone Server with two 10 GbE interfaces connected to the AS's IPv8 edge router:

• Anycast leg. One interface terminates the AS's WHOIS8 anycast prefix and the 8-over-IPv4 encapsulation tunnel endpoint (per and ). This leg receives inbound IPv8 traffic from the public IPv4 internet, encapsulated within IPv4 outer headers, and decapsulates it for delivery into the AS's IPv8 RNs.
• Native IPv8 leg. One interface carries the AS's native IPv8 VRF (vrf ipv8-asn-<RN>) created in Step 1 and connects to the AS's internal IPv8 routing fabric. Traffic flowing in this VRF is native IPv8 on the wire, not encapsulated.

The two-leg layout maps cleanly onto the four XLATE8 modes: inbound traffic arrives on the anycast leg encapsulated, gets decapsulated, and exits on the native leg as native IPv8; outbound traffic flows in reverse with 4-to-8 or 8-to-4 translation applied at the boundary as needed; intra-RN traffic on the native leg never traverses the anycast leg. Operators deploying at larger scale MAY use additional interfaces (bonded for capacity, separated for management, or both); the two-leg pattern is the operational minimum.

Forwarding Behaviour Once configured, packet forwarding through the Zone Server is automatic. The Route8 table () discriminates per-packet which RN a destination belongs to and dispatches the packet to the appropriate egress VRF: IPv4-Compatible (RN 0) packets exit toward the IPv4 internet, native IPv8 packets exit on the appropriate IPv8 RN interface, and inter-RN traffic crosses between IPv8 VRFs within the Zone Server without leaving the device. XLATE8 modes (specified in ) handle translation between IPv4-only hosts and IPv8 destinations transparently; operators do not configure per-flow translation rules. The appliance presents a single coherent configuration surface to the operator while orchestrating the underlying open-source network daemons (DHCP, DNS, FRR, nftables, lldpd, chrony, etc.) as specified in .

Corporate Deployment Variant In a corporate deployment, the Zone Server occupies the same two-leg position but the inside leg connects to the corporate firewall rather than directly to the AS edge. The anycast leg faces outward (toward the corporate edge and the public IPv4 internet beyond it), terminating WHOIS8 anycast and 8-over-IPv4 encapsulation; the native IPv8 leg faces inward, connecting to the corporate firewall's inside zone. The firewall mediates between the IPv8 native VRF and the corporate internal IPv4 network, applying the operator's existing security policy. This variant preserves the corporate security architecture (the firewall remains the trust boundary) while adding IPv8 reach at the AS edge.

Deployment Trajectory The deployment story for IPv8 is every ASN that wants to use IPv8 puts a Zone Server at every PE router on commodity hardware. This is the macro-level deployment unit: not a network-wide IPv8 turn-up requiring synchronous upgrade of every router and host, but an incremental deployment in which each AS independently installs commodity-hardware Zone Servers at its existing PE-router locations and gains IPv8 participation. Other ASes' deployment progress is not a precondition; an AS can complete its IPv8 deployment in the absence of any other AS doing the same, and interoperate via the IPv4-Compatible Form with non-deployed peers and via native IPv8 (with or without encapsulation depending on intermediate transit's deployment state) with deployed peers. Commodity hardware is a load-bearing property: the Zone Server is a software product running on standard x86 or ARM server hardware with standard NICs. There is no requirement for specialised silicon, no vendor lock-in to a particular forwarding ASIC, and no capital-expenditure dependency on a hardware refresh cycle. An AS already operating a fleet of PE routers can deploy IPv8 by adding one commodity server per PE site. This deployment pattern satisfies the minimum-deployment-unit requirement in §. Operators MAY scale horizontally by deploying additional ZS appliances at the same PE site (typically as the even/odd active-active pair .254/.253 per ) or vertically by upgrading edge routers to native IPv8 capability in subsequent phases as hardware support emerges through normal vendor product cycles.

Capacity Scaling The number of Zone Server pairs an operator deploys is determined by customer base, traffic profile, and operational preference. The following figures are illustrative guidance for sizing initial deployments; specific operators will adjust based on their measured load characteristics.

• Small ISP (less than 1,000 customers). A single Zone Server pair (.254/.253 even/odd active-active) is sufficient for the entire customer base. The pair provides the minimum redundancy required for production operation.
• Mid-size service provider (on the order of 50,000 customers). Approximately four Zone Server pairs, distributed across the operator's PE sites for geographic diversity and traffic-locality benefits. The customer-to-pair ratio is roughly 12,000 customers per pair at this scale.
• Hyperscaler (millions of customers). Approximately one cloud-instance Zone Server per 10,000 customers activated on IPv8, or fewer if the operator deploys on dedicated hardware. At hyperscale, Zone Servers may run as cloud compute instances rather than as dedicated appliances; redundancy is provided by the cloud platform's standard multi-availability-zone deployment model rather than by the paired-appliance pattern. In this environment the marginal cost of an additional Zone Server is the cost of an additional compute instance, which for major cloud providers is small relative to the cost of the IPv8-activated customer base it serves.

Operators sizing for hyperscale should note that dedicated hardware Zone Servers typically achieve higher per-instance throughput than equivalent cloud instances, owing to direct NIC access, absence of hypervisor overhead, NUMA-aware placement, and the absence of noisy-neighbour effects. The cloud-instance deployment pattern trades per-instance throughput for operational convenience (declarative provisioning, auto-scaling, multi-AZ redundancy provided by the platform). Operators with extreme per-instance throughput requirements, or operators for whom the cost of additional instances dominates the cost of additional hardware, may prefer dedicated bare-metal Zone Servers even at hyperscale. The progression from small ISP through mid-size to hyperscaler illustrates that Zone Server deployment scales linearly with the customer base. The cost per Zone Server decreases as deployment moves toward cloud-native compute instances, but this cost reduction is partially offset by reduced per-instance throughput. Operators sizing their deployments choose between dedicated hardware (higher throughput per instance, higher capital cost per instance) and cloud instances (lower throughput per instance, lower marginal cost per instance, better operational ergonomics) based on their specific traffic profile, customer growth rate, and operational preferences. Operators SHOULD benchmark against their own traffic profiles rather than against the illustrative figures in this section.

Phased Deployment A typical IPv8 deployment proceeds in the following phases. No phase requires coordination with peers, transit providers, or other ASes. Phase 1: WHOIS8 publication. The AS publishes a WHOIS8 record containing its anycast prefix and authorised origins (see ). The record is signed under the asnHolder's RPKI EE certificate and discoverable via DNS at the asn.arpa hierarchy. Phase 2: One BGP8 edge router. The AS upgrades one BGP- speaking edge router to BGP8 capability. This router advertises the AS's WHOIS8 anycast prefix into the surrounding BGP4 fabric, maintains IPv4 connectivity as required by §, and is capable of decapsulating IPv8-in-IPv4 traffic arriving at the anycast. Phase 3: Additional BGP8 edges. The AS upgrades additional edge routers as operational confidence grows. AnycastROA is updated to reflect the expanded set of authorised origins. Phase 4: Interior IPv8 awareness. The AS deploys IPv8 awareness in interior routers as needed for native IPv8 forwarding within the AS. This is typically done in stages and does not affect inter-AS connectivity. Phase 5: Host opt-in. Hosts within the AS deploy IPv8-aware network stacks as appropriate to their use cases. Pure-IPv4 hosts continue to operate via the IPv4-Compatible Form. For IPv4-only hosts on segments where IPv8-aware peers exist, the segment's Zone Server provides XLATE8 4-to-8 and 8-to-4 translation as specified in §XLATE8; the IPv4 hosts are oblivious to the translation. At every phase, the AS interoperates fully with both IPv8- participating and IPv4-only counterparts. There is no flag day and no forcing function.

Interoperation with BGP4 ASes that have not deployed BGP8 continue to operate as BGP4 peers. The protocol-level interoperation is specified in . In summary:

• Native BGP8 between BGP8-capable peers. When two peers successfully negotiate BGP8 capability per on a session, IPv8 reachability is exchanged using Multiprotocol BGP NLRI with the IPv8 AFI specified in . This is the efficient form: the full 64-bit <RN>-<LA> prefix is carried directly in the NLRI.
• BGP-in-VRF where L3VPN infrastructure exists. When the AS has MP-BGP with VPNv4 running, an ipv8-asn-<RN> VRF on each participating PE carries IPv8 reachability through the existing L3VPN distribution machinery. Route distinguisher <RN>:65535 keeps the VRFs distinct in transit; the BGP instance inside the VRF exchanges ordinary IPv4 routes within the RN's address space. Unupgraded transit routers participate as standard L3VPN PEs and Ps, propagating VPNv4 advertisements without requiring IPv8 awareness.
• asn-ibgp-path BGP large community where neither of the above applies. When the iBGP fabric is plain BGP4 with no L3VPN / VPNv4 capability, IPv8 reachability is exchanged using standard 32-bit IPv4 NLRI with the RN value carried in a BGP large community . The community is named asn-ibgp-path; its semantics and propagation are specified in . BGP4-only routers receiving such advertisements propagate the community transparently per and community-propagation rules; they do not interpret it semantically. Receiving BGP8 routers reconstruct the full <RN>-<LA> prefix from the community plus the IPv4 NLRI.
• Interior routing protocols (IS-IS, OSPF, EIGRP, IBGP) for the BGP4-only case operate inside the ipv8-asn-<RN> VRF using their standard mechanisms when L3VPN is available, or carry their own IPv8-extension behaviour (IS-IS8 unknown TLVs, OSPF8 opaque LSAs) where it isn't. Detailed mechanisms in .

The three BGP8 reachability-propagation mechanisms compose without operator intervention. BGP8 implementations select per-session based on capability negotiation and the available infrastructure: Native BGP8 where both peers negotiate it, VPNv4-based BGP-in-VRF where the iBGP fabric supports it, large-community-encoded BGP4 where it does not. A single AS-wide deployment may use different mechanisms on different segments depending on what each segment of infrastructure supports; the choice is determined at the protocol layer by what is locally available, not by operator configuration in advance. Routes installed in receiving BGP8 routers' Route8 RIBs are functionally identical regardless of which mechanism delivered them. The suite names BGP8, IBGP8, OSPF8, and IS-IS8 in companion specifications; these are not separate protocols. They are the existing protocols (BGP-4 , OSPF, IS-IS, EIGRP) with the addition of two behaviours: carrying IPv8 reachability via the multiprotocol NLRI or address-family-equivalent encoding, and participating in Cost Factor measurement collection. Packet formats, adjacency mechanisms, link-state database structures, flooding rules, convergence procedures, and the protocols' native path-selection metrics (OSPF cost, IS-IS metric, EIGRP composite metric, IBGP local-preference and MED) are all unchanged. The Cost Factor metric does not replace the interior protocols' native metrics. CF is a measurement layer for inter-AS path selection: implementations observe per-link and per-path characteristics (round-trip time, loss, congestion, capacity) within the AS and report the observations to the AS's BGP8 PEs. The PEs aggregate the observations and carry the aggregated CF value in BGP8 path attributes between PEs and across AS boundaries, where it is used for inter-AS path selection. The IGP CF Export Interface specified in additionally contributes intra-zone cost as a CF input to IBGP8, where it is combined with external CF to choose the best edge router for inter-AS destinations; this contribution does not alter intra-AS shortest-path computation, which continues to use the IGP's native metric. Operators' existing intra-AS metric tuning continues to govern intra-AS path selection. Operators running BGP, OSPF, IS-IS, or EIGRP today require no changes to their existing metric configurations; the "8" suffix on interior protocols identifies implementations that contribute CF observations and handle IPv8 reachability, not protocols with modified intra-AS path-selection logic. Detailed CF semantics, measurement collection, the IGP CF Export Interface, aggregation, and BGP8 carriage are specified in . The combined effect is that an AS can deploy IPv8 incrementally without coordinating BGP8 deployment across the AS's interior infrastructure. Operators with substantial existing L3VPN deployments can begin IPv8 participation by adding one VRF (ipv8-asn-<RN>) to their existing PE configuration; operators without L3VPN can use the large-community mechanism through their existing BGP4 iBGP; and operators deploying ZSes can establish direct BGP8 sessions between them over the AS's existing IPv4 transit. Mixed deployments where different segments use different mechanisms are common and supported by capability negotiation without operator coordination.

Inter-Site Interconnection An enterprise or operator running IPv8 at more than one site joins those sites with a single configuration statement per remote site, from which the Zone Servers establish the tunnel, authenticate each other, and exchange reachability automatically: encrypt ip remote zoneserver ipv8 - encrypt ]]> The ipv4 form designates a remote reached across the public Internet; the Zone Server installs an 8-over-IPv4 path (protocol number per §) to that endpoint. The ipv8 form designates a remote reachable over native IPv8 between the sites. In both cases the inner forwarding is Route Number forwarding; the two forms differ only in the underlay. Mutual key acceptance. When encrypt is specified, each Zone Server generates a WireGuard key pair at first boot and the two sites must each accept the other's public key before any traffic passes, in the manner of first-contact SSH host-key acceptance. On the first ip remote zoneserver statement each console displays the peer's key fingerprint and awaits confirmation; a packet can be neither encrypted nor decrypted until both operators have accepted, so the established tunnel is itself the proof that both sides consented. The accepted fingerprint is recorded in the configuration so that a rebuilt Zone Server re-pairs without prompting, and a peer that subsequently presents a different key is refused with an alarm, exactly as SSH refuses a changed host key. Reachability exchange via BGP. Once the tunnel is established the two Zone Servers exchange routes over it using BGP , not the intra-site synchronisation channel (which is reserved for the local active-active pair). The session type is derived from the two Route Numbers: two sites in the same RN peer by iBGP (they are one Autonomous System in two locations and share interior reachability), while sites in different RNs peer by eBGP with the Route Number carried as a BGP community and ordinary eBGP path semantics applied. The Route Number being the Autonomous System number makes this determination automatic; the operator types one statement and the session type follows. All Zone Servers are route reflectors. Each Zone Server sets a cluster identity and treats every same-RN peer as a route-reflector client, so a route learned from any site is reflected to every other site that server peers with, with the standard ORIGINATOR_ID and CLUSTER_LIST attributes preventing loops. There is no elected reflector and no hub to lose; the arrangement is flooding-with-suppression over the site peering graph, bounded by each server's own small number of peers rather than by the total site count. Enterprise inter-site route tables are stable for long periods, so the modest redundancy of universal reflection costs little and removes the single point of failure that an elected reflector would introduce. Relationship to the VRF-backed profile. The intra-AS VRF-backed profile of § (an ipv8-asn-<RN> VRF on an MPLS PE) and this inter-site tunnel profile are the same Route Number forwarding model over two different underlays: a provider MPLS core in the first case, an encrypted point-to- point tunnel in the second. An operator uses the VRF-backed profile where it already runs an L3VPN core and the tunnel profile to join sites across the ordinary Internet or across provider boundaries; the two compose, and a site may use one toward its carrier and the other toward a partner.

Implementation Status This section records the status of known implementations at the time of writing, per the guidance of . It will be removed before publication as an RFC. Linux kernel reference implementation. A mainline-style Linux kernel module implements the IPv8 forwarding plane: the Route Number shim over IPv4, the Route Number forwarding table with native and VRF forwarding modes, the per-flow source-RN cache, ARP8 neighbour resolution, XLATE8 translation, the AF_INET8 socket family, and 8-over-IPv4 transport, as described in §. It builds against current mainline kernels as two loadable modules with a small UAPI patch and modifies nothing in the existing IPv4 code paths. The Zone Server userspace daemon (zoneCore) implements DHCP8, DNS8 with the A8 record, and the operator console. Independent testing and educational toolkit. Aleksei Aleinikov independently tested the kernel implementation in his own virtual-machine environment, on running Linux kernels including kernels built with KASAN, KCSAN and lockdep, under functional and adversarial load. Results from that testing drove several of the correctness requirements in this revision, including the broadcast-domain Local Address uniqueness rule, the duplicate-address alarm, and the transit source-RN preservation rule. He also maintains Open-IPv8-Lab (https://github.com/LF3551/Open-IPv8-Lab), an educational userspace toolkit based on draft-thain-ipv8-02 that lets anyone try IPv8 addressing, packet formats and routing behaviour hands-on; it is not an implementation of this revision and does not use the kernel modules.

Security Considerations

Trust Foundation The IPv8 trust model rests on the existing RPKI trust chain. Each Regional Internet Registry operates a RPKI trust anchor that signs delegation certificates to ASN holders. ASN holders sign WHOIS8 records, AnycastROAs, and router certificates under their End-Entity certificate. The IPv8 suite introduces new signed object types within this chain but does not introduce new PKI infrastructure. Compromise of the RPKI trust chain affects IPv8 identically to how it affects ordinary BGP routing security: a compromised RIR trust anchor permits forgery of any signed object under that RIR's hierarchy. Mitigations are inherited from RPKI operational practice (key ceremonies, hardware security modules, audit logs, incident response procedures).

Route Number Spoofing A malicious BGP speaker MAY attempt to advertise an IPv8 prefix with a Route Number it does not legitimately hold. The defences against RN spoofing are:

• AnycastROA validation at any BGP router consuming the AnycastROA filter list rejects advertisements claiming to originate a WHOIS8 anycast from an unauthorised AS.
• RPKI Route Origin Validation applied to IPv8 prefixes rejects advertisements whose origin AS does not match a published ROA.
• RINE-level admission policy (per ) MUST validate both the /24 covering prefix's origin against the WHOIS8 record and the /32 anycast prefix's origin against AnycastROA. Mismatches are rejected and logged via NetLog8.

These defences combine to make Route Number spoofing detectable at multiple points. The WHOIS8 anycast specifically is structurally resistant to hijack: because the anycast is allocated as a /32, no longer-prefix-match attack is possible, and equally-specific advertisements from unauthorised ASes are caught by AnycastROA validation. Within its design scope, the WHOIS8 anycast hijack attack class is eliminated.

Reserved Block Protection The reserved Route Number blocks defined in § MUST be protected from inter-AS leakage:

• Routers MUST reject any inter-AS advertisement carrying an RN with leading octet 127 (private internal).
• Routers MUST reject any advertisement of RN with leading octet 100 (RINE peering) from a non-RINE peer.
• Routers MUST reject any advertisement of RN with leading octet 222 (interior link convention) outside the originating AS, and SHOULD apply NO_EXPORT/NO_ADVERTISE treatment internally.

These rejections SHOULD be logged via NetLog8 and SHOULD contribute to Sun Tzu trust evaluation of the offending peer.

Per-Segment RN Invariant Enforcement The per-segment-one-RN invariant (§) is security-relevant: a misconfigured or malicious neighbour claiming a Primary RN that conflicts with the segment's established Primary RN can disrupt IPv8 forwarding decisions on the segment. Implementations MUST detect such conflicts via the ARP8 Primary RN Discovery mechanism specified in and MUST emit a NetLog8 SEC-ALERT event when a conflict is observed. Implementations SHOULD refuse to forward IPv8 traffic on the affected interface until the conflict is resolved.

Encapsulation Boundary Trust IPv8-in-IPv4 encapsulation (specified in ) places trust in the integrity of the outer IPv4 path between encapsulator and decapsulator. This trust is identical to the trust placed in IPv4 by any application or protocol traversing IPv4 today. Specifically:

• Outer-header integrity is protected by the IPv4 header checksum and any link-layer protections present.
• Inner-payload confidentiality and integrity are the responsibility of higher-layer protocols (TLS, IPsec, etc.) exactly as for any IPv4-transported traffic.
• An attacker capable of intercepting and modifying IPv4 packets in flight can intercept and modify IPv8-in-IPv4 encapsulated packets equivalently. The encapsulation introduces no new vulnerability beyond those inherent to IPv4 transport.

Cross-AS Multicast and Broadcast Cross-AS multicast and broadcast in IPv8 carry the same amplification and reflection risks as in IPv4. Cross-AS multicast group assignments (§) MUST be filtered by ingress policy at the AS boundary; broadcast addresses MUST NOT be forwarded across any RN boundary.

Trust State Update Discipline Per the operational pattern in §, trust-state updates are operator-initiated. The security implications:

• A compromised upstream data source affects only operators who happen to update during the compromise window. The blast radius is limited compared to automatic refresh.
• An operator who declines to update (perhaps after observing anomalous diff output from verify) preserves their pre- compromise state. The verify-before-update separation is load-bearing for this property and SHOULD NOT be removed in implementations.
• An operator who updates and subsequently observes incident symptoms can roll back to a previous version of the trust state by replaying the prior update. Implementations SHOULD retain the previous N versions of trust state to support this recovery path.

IANA Considerations This section enumerates IANA registry actions requested by this document. Companion documents in the IPv8 suite request additional codepoints in their respective IANA Considerations sections.

IP Version Number IANA is requested to assign the IP version number 8 to "Internet Protocol Version 8 (IPv8)" in the IP Version Numbers registry .

EtherType for Native IPv8 IANA is requested to coordinate with the IEEE Registration Authority to assign EtherType 0x8080 (referenced for the Altair 8800) for native IPv8 frames carrying the IPv8 header specified in §.

Route Number Reserved Block: Private Internal IANA is requested to record the reservation of Route Numbers with leading octet 127 (127.r.r.r) for private internal RN allocations as specified in §.

Route Number Reserved Block: RINE Peering IANA is requested to record the reservation of Route Numbers with leading octet 100 (100.r.r.r) for RINE peering as specified in § and detailed in .

Route Number Reserved Block: Interior Link Convention IANA is requested to record the reservation of Route Numbers with leading octet 222 (222.r.r.r) for the Interior Link Convention as specified in §.

Route Number Reserved Blocks: Future Allocation Pools IANA is requested to record the additional RN-block reservations specified in the table in § (leading octets 1--32 for super-scalar allocation, 110--119 for RIR sub-RN pools, 128--130 for cellular carrier allocation, and the various IANA-reserved ranges in between). Allocation policy for these blocks is to be defined by future IETF action.

DNS Resource Record Type for A8 IANA is requested to assign a DNS Resource Record Type code to the A8 record type, which carries an IPv8 address as RDATA. The RDATA format is the 64-bit IPv8 address in network byte order (8 octets). The exact codepoint is to be assigned by IANA.

IPv8-in-IPv4 Protocol Number IANA is requested to assign an IPv4 Protocol Number to "IPv8- in-IPv4 Encapsulation" in the Protocol Numbers registry. This codepoint identifies an IPv4 packet whose payload is an IPv8 packet, as specified in .

.arpa Subdomain Registration IANA is requested to delegate the asn.arpa zone for use by the IPv8 specification suite. The zone hosts records of the form <RN>.asn.arpa (per-AS WHOIS8 fast-path discovery) and anycast.<RN>.asn.arpa (per-AS AnycastROA filter list publication and 8-over-IPv4 tunnel endpoint discovery) as specified in .

DHCP Option Codepoints IANA is requested to assign codepoints in the BOOTP/DHCP Parameters registry for the IPv8-specific options:

• Option 222 --- IPv8 Default Route Number. Carries the Primary RN assignment for the segment scope, as specified in .
• Option 223 --- IPv8 Interface Mode. Carries the per-interface mode value (normal, strict, pnp, guest) as specified in § of this document and in .

The values 222 and 223 are taken from the DHCP private-use range pending permanent IANA assignment.

References

Normative References

Informative References

Informative References IEEE NDSS 2017

Appendix A: Changes since -02 This appendix summarises the substantive changes. Editorial corrections, reference updates, and similar housekeeping are not enumerated individually.

Principal Changes

• Co-author. Aleksei Aleinikov (Open-IPv8-Lab) is added as co-author; see Contributors.
• Broadcast-domain Local Address uniqueness. The per-segment invariant (§) now states explicitly that IPv8 Local Addresses MUST be unique within one broadcast domain irrespective of RN, with a required duplicate-address alarm and a required pre-assignment ARP probe. This closes a cross-RN address-collision case identified by the reference test laboratory: because every IPv8 host also answers ARP for its Local Address, two hosts sharing a Local Address on one segment collide regardless of their Route Numbers. Local Addresses remain freely reusable across broadcast domains.
• Pre-authentication holding state; displacement of 802.1X. The Identity-Driven Access Control section (§) now specifies that an unauthenticated device is confined to a holding RN on a /32 Local Address reachable only to the Zone Server, authenticates over Layer 3 by presenting an OAuth8 JWT, and is rebound into its entitled RN on success. IPv8 is stated to displace 802.1X: admission becomes a property of a signed identity reached at Layer 3 rather than a Layer 2 port-state machine, needs no supplicant, RADIUS server, or switch cooperation, federates to any OpenID Connect provider, and confines by the absence of a route rather than by a firewall rule. The same mechanism is noted to operate in an IPv4 network with VLAN assignment as the admission outcome.
• Inter-site interconnection. A new section (§) specifies the ip remote zoneserver ... encrypt model: WireGuard tunnels with SSH-style mutual key acceptance, reachability exchange over BGP (iBGP for same-RN sites, eBGP for different-RN, derived automatically from the Route Numbers), and all Zone Servers acting as route reflectors. Its relationship to the VRF-backed MPLS profile is stated: the same Route Number forwarding model over two underlays.
• Transit source-RN preservation. Clarified that a router forwarding a packet that arrived encapsulated preserves the originator's source Route Number end to end rather than substituting its own.
• ARP8 and ICMPv8 alignment with running code. The ARP8 Primary RN discovery is the dual-probe (ARP8 then ARP after a short interval) with first-answer mode permanence. The ARP8 protocol type is the IPv8 EtherType; the value 0x86DD8 in earlier companion text does not fit the 16-bit field and is corrected in . ICMPv8 is carried as ordinary ICMP within the IPv8 header addressed to the source RN, not as a distinct 36-octet header; the earlier description is corrected in .
• Running code. A mainline-kernel reference implementation (the two modules of §) now exists and has been tested independently; correctness requirements in this revision reflect results from loading and attacking that code on running kernels.

Notation

• Canonical locator form changed from dotted eight-octet notation (R.R.R.R.n.n.n.n) to hyphenated form (<RN>-<LA>). The hyphen is a fixed visual separator distinguishing the RN portion from the LA portion. The RN portion renders as a decimal integer for leading-zero RNs and as four dotted octets for reserved-block RNs.
• The dotted-eight-octet form is no longer canonical for output; implementations MUST accept it on input for compatibility with earlier draft notation but MUST emit the hyphenated form on output.
• Reserved-block notation changed from 127.0.0.0/8 style (which incorrectly implied prefix-match semantics over an RN range) to 127.r.r.r style (which correctly indicates a categorical filter on the leading octet of the RN field). The Route Number is not subnettable; RN values are exact- match identifiers.

Reserved RN Blocks

• A complete reservation table for the RN-leading-octet namespace has been added in §, including blocks reserved for future allocation policy (super-scalar, cellular carrier, RIR sub-RN pools).
• The 127.127.0.0/16 "Inter-Company Interop Prefix" designation has been removed from the core draft; the inter-organisation translation use case is covered by the general two-XLATE8 model specified in .

RN-as-VRF Framing

• § adds the operator-facing "An RN is a fancy VRF" framing, with explicit reference to the vrf ipv8-asn-<RN> naming convention and the <RN>:65535 route distinguisher.
• The framing makes explicit that intra-RN routing is IPv4 routing within a VRF, using whichever interior routing protocols (OSPF, IS-IS, EIGRP, IBGP, static) the operator runs, and that inter-RN routing (BGP8) operates over the union of VRFs.
• Internal operator VRFs (hospital, phones, payroll, customer L3VPNs, etc.) continue to operate per and are out of scope for IPv8; only inter-RN routing is specified by the IPv8 suite.

Per-Segment RN Invariant

• § adds the explicit per-segment-one-RN invariant: every L2 broadcast domain or point-to-point link has exactly one Primary RN.
• The invariant requires that every IPv4 address on every interface on the segment is in the Primary RN, and that every Primary IPv8 address on the segment is in the same Primary RN.
• Secondary IPv8 addresses MAY exist in other RNs and are addressable from IPv8-aware peers via ETH_P_IPV8 carrying the explicit RN. IPv4-only peers reach Secondary RN identities via Zone Server XLATE8.
• ARP8 Primary RN Discovery (specified in ) detects invariant violations at runtime.

Wire Format Rule Precision

• § clarifies that the choice between ETH_P_IP and ETH_P_IPV8 is governed by whether the destination's RN can be inferred from the segment's Primary RN context, not solely by whether the packet crosses an L2 segment boundary.
• ETH_P_IPV8 is used whenever the destination RN is not the segment's Primary RN, including for IPv8-to-IPv8 traffic on the same segment when addressing a peer's Secondary RN identity.
• ETH_P_IP is used when the destination is reached at the segment's Primary RN, which is the case for all IPv4-only traffic and for Primary-RN-to-Primary-RN IPv8 traffic.

Per-Interface Mode

• § documents the four interface modes (normal, strict, pnp, guest) with the rename of "printer" to "pnp" reflecting the broader plug-and-play appliance scope of the mode.
• DHCP option 223 is identified as the carrier of the per- interface mode value (separate from DHCP option 222 which carries the Primary RN assignment).

XLATE8 Unified Subsystem

• The XLATE8 entry in §Terminology is expanded to document the four operational modes: native IPv8 forwarding, 4-to-8 translation, 8-to-4 translation, 8-to-8 NAPT, and 8-over-IPv4 encapsulation. Detailed mechanism is specified in and .

L4 Family-Agnostic Framing and Routing-Protocol Naming

• §Socket API Compatibility makes explicit that TCP, UDP, QUIC, SCTP, ICMP, and ARP are not duplicated as "TCP8", "UDP8", etc. ICMP is one protocol with IPv8-extension behaviour; the same applies to ARP. The "-8" suffix names refer to extension behaviour, not to separate protocols.
• §Interoperation with BGP4 adds a parallel statement for routing protocols: BGP8, IBGP8, OSPF8, and IS-IS8 are not separate protocols. They are the existing protocols (BGP-4, OSPF, IS-IS, EIGRP) with the Cost Factor metric carried as the path-quality signal in place of the protocol's native metric, and with the IPv8 multiprotocol NLRI or address- family-equivalent encoding where reachability is carried. Packet formats, adjacency mechanisms, link-state database structures, flooding rules, and convergence procedures are unchanged. Operators running these protocols today need no new operational knowledge beyond understanding the CF metric and its slewing behaviour.

Edge Router IPv4 Requirement

• § adds the requirement that public IPv8 edge routers maintain IPv4 connectivity sufficient to serve as 8-over-IPv4 encapsulation endpoints during the transition period.

Typical Deployment Pattern

• § adds the canonical first-deployment recipe: a commodity-hardware Zone Server appliance installed as a Provider Edge router alongside the operator's existing IPv4 infrastructure. The IPv4 network is unchanged --- no encapsulation overlay, no IPv6 dependency, no flag day.
• The section is organised around a four-step deployment recipe: (1) create the IPv8-labelled IPv4 VRF named ipv8-asn-<RN> on existing routing infrastructure, (2) stand up two Linux Zone Servers on commodity hardware as the active-active even/odd pair, (3) enable the minimum services (ACL8, XLATE8, DNS; OAuth8/JWT implicit) and set the RN on the IPv8-facing interface, (4) enable eBGP between additional ZS pairs if deployed, publish the AS's WHOIS8 anycast in DNS, and either make the first PE the IPv8 default gateway or use BGP4 to distribute IPv8 routes.
• Physical layout specified: two 10 GbE interfaces per Zone Server, one terminating the AS's WHOIS8 anycast prefix and 8-over-IPv4 encapsulation endpoint, one carrying the native IPv8 VRF.
• Minimum service set: ACL8, XLATE8, DNS (with OAuth8/JWT as the identity substrate that ACL8 evaluates against). ACL8 is identified as non-optional because the Zone Server's anycast leg faces the public IPv4 internet by definition; ACL8 is the perimeter defense layer that protects the Zone Server itself, not merely an internal policy mechanism.
• Forwarding behaviour clarified: Route8 performs per-packet RN discrimination in the Linux kernel automatically; XLATE8 modes handle 4-to-8 / 8-to-4 / 8-to-8 / 8-over-4 translation without per-flow operator configuration.
• Corporate deployment variant documented: same two-leg layout, but the inside leg connects to the corporate firewall rather than directly to the AS edge, preserving the corporate security architecture.
• Deployment trajectory stated: every ASN that wants to use IPv8 puts a Zone Server at every PE router on commodity hardware. Per-AS independent deployment; no synchronous network-wide upgrade required.
• Capacity scaling guidance added: small ISP (under 1,000 customers) needs one ZS pair; mid-size service provider (around 50,000 customers) needs roughly four pairs distributed across PE sites; hyperscaler (millions of customers) needs approximately one cloud-instance ZS per 10,000 IPv8-activated customers, or fewer if deployed on dedicated hardware. The guidance notes the throughput tradeoff: dedicated hardware Zone Servers achieve higher per-instance throughput than cloud instances (direct NIC access, no hypervisor overhead, NUMA-aware placement, no noisy-neighbour effects), while cloud instances trade per-instance throughput for operational convenience (declarative provisioning, auto-scaling, multi-AZ redundancy). Figures are illustrative; operators benchmark against their own traffic profiles.

BGP8 Propagation Mechanisms Across Heterogeneous Infrastructure

• An earlier working revision presented the asn-ibgp-path BGP large community as the primary mechanism for carrying IPv8 reachability through BGP4-only iBGP transit. An intermediate revision of this document over-narrowed the framing in the opposite direction, presenting BGP-in-VRF as the sole mechanism. Both framings were incomplete.
• The accurate framing is that three mechanisms compose to deliver IPv8 reachability across heterogeneous AS interiors: Native BGP8 NLRI between BGP8-capable peers where capability is negotiated per ; BGP-in-VRF via VPNv4 where the iBGP fabric supports L3VPN distribution; and the asn-ibgp-path BGP large community where the iBGP fabric is plain BGP4 only.
• The choice of mechanism is determined per session by capability negotiation and locally-available infrastructure, not by operator configuration in advance. A single AS may use different mechanisms on different segments depending on what each region of infrastructure supports.
• This composition is what permits IPv8 deployment in heterogeneous environments — large carrier ASes with mixed generations of routing equipment where some segments support L3VPN and others do not — without requiring synchronous infrastructure upgrades.
• §Interoperation with BGP4 now presents all three mechanisms with this composition framing. RFC 1997, RFC 4760, RFC 5492, and RFC 8092 are normative references for the capability-negotiation, multiprotocol-NLRI, and large-community machinery the mechanisms rely on.

Intra-Zone Native Traffic and Host-What-You-Advertise

• § now states two operational properties of the RN-as-VRF framing: (1) intra-zone traffic is mostly native IPv8 within vrf ipv8-asn-<RN>, with encapsulation reserved for the transition mechanism rather than the steady state; and (2) routers host local VRFs only for RNs whose routes they originate or terminate, not for RNs they merely transit via BGP8 path-vector propagation. The Route8 table carries RIB entries for transit RNs but does not maintain forwarding contexts for them.

Cost Factor Scope and Behaviour

• The Cost Factor (CF) terminology entry in §Terminology is rewritten to scope CF correctly: CF is the IPv8 inter-AS path-quality metric. It is carried in BGP8 path attributes between PEs and across AS boundaries and governs inter-AS path selection.
• CF does not replace the interior routing protocols' native metrics. OSPF cost, IS-IS metric, EIGRP composite metric, IBGP local-preference, and MED continue to govern intra-AS shortest-path computation. Operators' existing metric tuning is preserved unchanged by IPv8 adoption.
• The IGP CF Export Interface specified in contributes intra-zone cost as a CF input to IBGP8, where it is combined with external CF to choose the best edge router for inter-AS destinations. This is an inter-AS path-selection refinement; it does not alter intra-AS shortest-path computation.
• CF input values are observations collected by implementations and propagate via a slow-slew adjustment mechanism analogous to NTP clock-slew, providing damping against rapid oscillation in inter-AS path selection. Operator policy adjustments to CF inputs are made by explicit operator action; the slew governs how observed inputs and operator adjustments together propagate.
• A forward-looking note is added: as the CF measurement substrate matures and operators gain confidence in CF's accuracy across a range of operational conditions, CF could eventually become sufficient to drive interior path selection as well, retiring some of the human metric-tuning effort. This is not specified by the current suite and is not required for IPv8 adoption; it is noted as a possible future direction contingent on operational experience.
• Detailed CF semantics, measurement collection, aggregation, and BGP8 carriage are specified in .

Identity-Driven Access Control Cut and Refocused

• §Identity-Driven Access Control reduced by approximately half to focus on the architectural framing: OAuth8/JWT as the modern equivalent of RADIUS for network AAA in IPv8, with ACL8 as the enforcement point.
• The following subsections were removed from this core document and are now specified entirely in : Named JWT Claims and ACL8 Rule Syntax (including the token:<claim-name> rule grammar and worked examples); Virtual NICs as the Identity Unit; Profiles; Per-Profile Egress Routing. These details belong to the Zone Server product surface rather than the core protocol specification.
• The Per-Interface Mode subsection ({#per-interface-mode}) is retained in core because the four modes (normal, strict, pnp, guest) are normatively bound to DHCP option 223 and the mode enumeration is referenced from the IANA section.
• VLAN deployment discussion in this section was reduced to a single pointer to . The claim that a single network interface MAY participate in multiple VLANs simultaneously is removed; multi-zone access is described in via vNIC and profile mechanisms, not via Layer 2 multiplexing on a single physical interface.

References

• All companion-draft references updated to their current revision numbers.
• RFC 4364 (BGP/MPLS IP VPNs) added as a normative reference for the RN-as-VRF framing and for internal operator VRF treatment.
• RFC 2865 (RADIUS), RFC 6749 (OAuth 2.0), and RFC 7519 (JWT) added as informative references for the OAuth8/JWT-as-modern- RADIUS-replacement framing in §Identity-Driven Access Control.

Contributors IPv8 is the joint work of the authors. Aleksei Aleinikov (Open-IPv8-Lab) independently tested the kernel implementation in a virtual-machine test environment; his results drove a number of the correctness requirements in this revision, including the broadcast-domain Local Address uniqueness rule and its duplicate-address alarm and the transit source-RN preservation rule. He also maintains Open-IPv8-Lab, an educational IPv8 toolkit for hands-on experimentation. On the strength of that work he is named as co-author of this revision.

Acknowledgements The author thanks the IETF community for prior work on RPKI, DNSSEC, and BGP routing security on which this specification builds. IPv8 introduces no new cryptographic primitives, no new PKI infrastructure, and no new DNS infrastructure; it composes existing well-deployed mechanisms into a coherent addressing and trust framework.

Authors' Addresses Jamie Thain One Limited Hamilton, Bermuda Email: jamie@one.bm Aleksei Aleinikov Open-IPv8-Lab Email: contact@alekseialeinikov.com