Internet Protocol Version 8 (IPv8)
draft-thain-ipv8-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | James Thain , Aleksei Aleinikov | ||
| Last updated | 2026-10-15 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-thain-ipv8-03
Internet Area Working Group J. Thain
Internet-Draft One Limited
Intended status: Standards Track A. Aleinikov
Expires: 18 April 2027 Open-IPv8-Lab
15 October 2026
Internet Protocol Version 8 (IPv8)
draft-thain-ipv8-03
Abstract
This document specifies Internet Protocol Version 8 (IPv8), an
extension of IPv4 [RFC791] 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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Thain & Aleinikov Expires 18 April 2027 [Page 1]
Internet-Draft IPv8 October 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Locator Rendering . . . . . . . . . . . . . . . . . . . . . . 8
3.1. RN Portion Rendering . . . . . . . . . . . . . . . . . . 8
3.2. LA Portion Rendering . . . . . . . . . . . . . . . . . . 9
3.3. Prefix Length Notation . . . . . . . . . . . . . . . . . 9
3.4. Storage and Wire Format Are Independent . . . . . . . . . 9
3.5. ASN Simplification Configuration . . . . . . . . . . . . 9
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 10
4.1. The Postal-Code Framing . . . . . . . . . . . . . . . . . 10
4.2. An RN is a Fancy VRF . . . . . . . . . . . . . . . . . . 10
4.3. Adding an RN to an Interface . . . . . . . . . . . . . . 12
4.3.1. Two Paths to the Internet . . . . . . . . . . . . . . 12
4.4. Ride Existing Infrastructure, Signal at the Edges . . . . 13
4.5. Minimum Deployment Unit . . . . . . . . . . . . . . . . . 14
4.6. Per-Segment RN Invariant . . . . . . . . . . . . . . . . 15
4.7. Forwarding Silicon Compatibility . . . . . . . . . . . . 16
4.8. Trust-State Operational Pattern . . . . . . . . . . . . . 17
4.9. Identity-Driven Access Control . . . . . . . . . . . . . 18
4.9.1. Pre-Authentication Holding State and the Displacement
of 802.1X . . . . . . . . . . . . . . . . . . . . . . 18
4.9.2. Per-Interface Mode . . . . . . . . . . . . . . . . . 20
4.10. Performance and Error Telemetry . . . . . . . . . . . . . 21
5. Address Format . . . . . . . . . . . . . . . . . . . . . . . 21
Thain & Aleinikov Expires 18 April 2027 [Page 2]
Internet-Draft IPv8 October 2026
5.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Prefix Length Semantics . . . . . . . . . . . . . . . . . 22
5.3. IPv4 Representation in IPv8 . . . . . . . . . . . . . . . 22
5.4. Reserved Route Number Blocks . . . . . . . . . . . . . . 23
6. Address Classes . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4. Broadcast . . . . . . . . . . . . . . . . . . . . . . . . 26
7. IPv8 Packet Header . . . . . . . . . . . . . . . . . . . . . 26
7.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 26
7.2. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 27
7.3. Socket API Compatibility . . . . . . . . . . . . . . . . 28
8. Coexistence and Deployment . . . . . . . . . . . . . . . . . 29
8.1. Single-Stack Operation . . . . . . . . . . . . . . . . . 29
8.2. Relationship to IPv6 . . . . . . . . . . . . . . . . . . 29
8.3. Typical Deployment Pattern . . . . . . . . . . . . . . . 30
8.3.1. Four-Step Deployment Recipe . . . . . . . . . . . . . 30
8.3.2. Physical Layout . . . . . . . . . . . . . . . . . . . 32
8.3.3. Forwarding Behaviour . . . . . . . . . . . . . . . . 32
8.3.4. Corporate Deployment Variant . . . . . . . . . . . . 33
8.3.5. Deployment Trajectory . . . . . . . . . . . . . . . . 33
8.3.6. Capacity Scaling . . . . . . . . . . . . . . . . . . 34
8.4. Phased Deployment . . . . . . . . . . . . . . . . . . . . 35
8.5. Interoperation with BGP4 . . . . . . . . . . . . . . . . 36
8.6. Inter-Site Interconnection . . . . . . . . . . . . . . . 38
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 39
10. Security Considerations . . . . . . . . . . . . . . . . . . . 40
10.1. Trust Foundation . . . . . . . . . . . . . . . . . . . . 40
10.2. Route Number Spoofing . . . . . . . . . . . . . . . . . 40
10.3. Reserved Block Protection . . . . . . . . . . . . . . . 41
10.4. Per-Segment RN Invariant Enforcement . . . . . . . . . . 41
10.5. Encapsulation Boundary Trust . . . . . . . . . . . . . . 41
10.6. Cross-AS Multicast and Broadcast . . . . . . . . . . . . 42
10.7. Trust State Update Discipline . . . . . . . . . . . . . 42
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
11.1. IP Version Number . . . . . . . . . . . . . . . . . . . 42
11.2. EtherType for Native IPv8 . . . . . . . . . . . . . . . 43
11.3. Route Number Reserved Block: Private Internal . . . . . 43
11.4. Route Number Reserved Block: RINE Peering . . . . . . . 43
11.5. Route Number Reserved Block: Interior Link Convention . 43
11.6. Route Number Reserved Blocks: Future Allocation Pools . 43
11.7. DNS Resource Record Type for A8 . . . . . . . . . . . . 43
11.8. IPv8-in-IPv4 Protocol Number . . . . . . . . . . . . . . 43
11.9. .arpa Subdomain Registration . . . . . . . . . . . . . . 44
11.10. DHCP Option Codepoints . . . . . . . . . . . . . . . . . 44
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
12.1. Normative References . . . . . . . . . . . . . . . . . . 44
Thain & Aleinikov Expires 18 April 2027 [Page 3]
Internet-Draft IPv8 October 2026
12.2. Informative References . . . . . . . . . . . . . . . . . 44
13. Informative References . . . . . . . . . . . . . . . . . . . 44
Appendix A. Appendix A: Changes since -02 . . . . . . . . . . . 47
A.1. Principal Changes . . . . . . . . . . . . . . . . . . . . 47
A.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 49
A.3. Reserved RN Blocks . . . . . . . . . . . . . . . . . . . 49
A.4. RN-as-VRF Framing . . . . . . . . . . . . . . . . . . . . 49
A.5. Per-Segment RN Invariant . . . . . . . . . . . . . . . . 50
A.6. Wire Format Rule Precision . . . . . . . . . . . . . . . 50
A.7. Per-Interface Mode . . . . . . . . . . . . . . . . . . . 50
A.8. XLATE8 Unified Subsystem . . . . . . . . . . . . . . . . 51
A.9. L4 Family-Agnostic Framing and Routing-Protocol Naming . 51
A.10. Edge Router IPv4 Requirement . . . . . . . . . . . . . . 51
A.11. Typical Deployment Pattern . . . . . . . . . . . . . . . 51
A.12. BGP8 Propagation Mechanisms Across Heterogeneous
Infrastructure . . . . . . . . . . . . . . . . . . . . . 53
A.13. Intra-Zone Native Traffic and Host-What-You-Advertise . . 54
A.14. Cost Factor Scope and Behaviour . . . . . . . . . . . . . 54
A.15. Identity-Driven Access Control Cut and Refocused . . . . 55
A.16. References . . . . . . . . . . . . . . . . . . . . . . . 55
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 55
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 56
Appendix D. Authors' Addresses . . . . . . . . . . . . . . . . . 56
1. Introduction
This document specifies the core elements of Internet Protocol
Version 8 (IPv8). IPv8 extends IPv4 [RFC791] 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
Thain & Aleinikov Expires 18 April 2027 [Page 4]
Internet-Draft IPv8 October 2026
* 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
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. 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 §Section 3 for the rendering rules.
*Autonomous System Number (ASN).* Per [RFC4271]. 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.
Thain & Aleinikov Expires 18 April 2027 [Page 5]
Internet-Draft IPv8 October 2026
*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 [ROUTING-PROTOCOLS]. 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
[ROUTING-PROTOCOLS] 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 [ROUTING-PROTOCOLS].
*RINE.* Regional Inter-Network Exchange, specified in [RINE]. 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.
Thain & Aleinikov Expires 18 April 2027 [Page 6]
Internet-Draft IPv8 October 2026
*Sun Tzu.* The Neighbor Trust Verification mechanism specified in
[ROUTING-PROTOCOLS]. 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
[ZONESERVER]. 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].
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 [RFC6480], RPKI origin validation
[RFC6811], and RDAP [RFC9082] [RFC9083], 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 [ZONESERVER]. 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 [SUPPORT8] and [ZONESERVER]. ACL8 supports first-class
matching on the RN field, enabling AS-aware policy expression at line
rate.
Thain & Aleinikov Expires 18 April 2027 [Page 7]
Internet-Draft IPv8 October 2026
*Route8.* The unified routing table specification in [SUPPORT8].
Route8 holds IPv4 routes (as IPv8 routes with <RN> = 0) and IPv8
routes in a single table, organised as per-RN VRFs (see
§Section 4.2).
*Anycast Route Origin Authorisation (AnycastROA).* The signed object
specified in [WHOIS8] authorising a specified set of ASes to
originate a given WHOIS8 anycast prefix. Sibling to RPKI Route
Origin Authorisations [RFC6482].
*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
[ROUTING-PROTOCOLS] § "BGP8 Routing Table".
3. 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.
3.1. 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)
Thain & Aleinikov Expires 18 April 2027 [Page 8]
Internet-Draft IPv8 October 2026
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.
3.2. 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.
3.3. 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.
3.4. 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 §Section 7 is
always the full 64-bit pair regardless of how the address is
rendered.
3.5. 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.
Thain & Aleinikov Expires 18 April 2027 [Page 9]
Internet-Draft IPv8 October 2026
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.
4. Architecture Overview
4.1. 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.
4.2. 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.
Thain & Aleinikov Expires 18 April 2027 [Page 10]
Internet-Draft IPv8 October 2026
* *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 [RFC4364].
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
([SUPPORT8]) 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
[ROUTING-PROTOCOLS] § "BGP8 Routing Table".
Thain & Aleinikov Expires 18 April 2027 [Page 11]
Internet-Draft IPv8 October 2026
4.3. 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 [SUPPORT8]), 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.
4.3.1. 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.
Thain & Aleinikov Expires 18 April 2027 [Page 12]
Internet-Draft IPv8 October 2026
* *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.
4.4. 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
[RFC4364]). Routes within the VRF are IPv4 routes within the RN's
address space; the RN identity is supplied by the VRF context, not
Thain & Aleinikov Expires 18 April 2027 [Page 13]
Internet-Draft IPv8 October 2026
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.
4.5. 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.
Thain & Aleinikov Expires 18 April 2027 [Page 14]
Internet-Draft IPv8 October 2026
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 [SUPPORT8].
4.6. 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 §Section 7.2 and the ARP8 Primary RN
Discovery mechanism specified in [SUPPORT8].
*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 [RFC5227]) 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.
Thain & Aleinikov Expires 18 April 2027 [Page 15]
Internet-Draft IPv8 October 2026
* *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.
4.7. 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.
Thain & Aleinikov Expires 18 April 2027 [Page 16]
Internet-Draft IPv8 October 2026
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.
4.8. 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.
Thain & Aleinikov Expires 18 April 2027 [Page 17]
Internet-Draft IPv8 October 2026
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.
4.9. 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 [ZONESERVER] 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 [RFC2865] 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 [RFC6749], OpenID Connect, JWT [RFC7519]) 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.
4.9.1. Pre-Authentication Holding State and the Displacement of 802.1X
IPv8 displaces 802.1X [IEEE8021X] 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.
Thain & Aleinikov Expires 18 April 2027 [Page 18]
Internet-Draft IPv8 October 2026
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.
Thain & Aleinikov Expires 18 April 2027 [Page 19]
Internet-Draft IPv8 October 2026
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 [ZONESERVER].
ACL8 rule evaluation, default-deny posture, and audit logging are
specified in [SUPPORT8] §ACL8.
4.9.2. 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.
Thain & Aleinikov Expires 18 April 2027 [Page 20]
Internet-Draft IPv8 October 2026
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 [SUPPORT8] §ACL8 and [ZONESERVER].
4.10. Performance and Error Telemetry
The IPv8 suite's operational telemetry substrate is NetLog8
[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 [NETLOG8].
5. Address Format
5.1. Structure
An IPv8 address is a 64-bit identifier formed of two 32-bit fields:
Thain & Aleinikov Expires 18 April 2027 [Page 21]
Internet-Draft IPv8 October 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Number (RN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Address (LA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 §Section 3.
5.2. 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 §Section 11, 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.
5.3. 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.
Thain & Aleinikov Expires 18 April 2027 [Page 22]
Internet-Draft IPv8 October 2026
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 §Section 5.4. 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.
5.4. 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.
Thain & Aleinikov Expires 18 April 2027 [Page 23]
Internet-Draft IPv8 October 2026
+===============+=================================+============+
| Leading Octet | Designation | Status |
+===============+=================================+============+
| 0 | RIR-allocated conventional ASN | Active |
| | pool (lower 24 bits of 0.r.r.r) | |
+---------------+---------------------------------+------------+
| 1--32 | Super-scalar allocation (1M+ | Reserved, |
| | customer base, $25M/year) | 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+ | Reserved, |
| | subscribers, $1M/year) | policy TBD |
+---------------+---------------------------------+------------+
| 131--221 | IANA-reserved | TBD |
+---------------+---------------------------------+------------+
| 222 | Interior link convention | Active |
+---------------+---------------------------------+------------+
| 223--255 | IANA-reserved | TBD |
+---------------+---------------------------------+------------+
Table 1
The active blocks are specified as follows.
Thain & Aleinikov Expires 18 April 2027 [Page 24]
Internet-Draft IPv8 October 2026
*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]. 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
[NETLOG8]. 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 [RFC5737]
retain their IPv4 documentation-example semantics within IPv8 in any
RN context. They MUST NOT be used in production networks.
6. Address Classes
Thain & Aleinikov Expires 18 April 2027 [Page 25]
Internet-Draft IPv8 October 2026
6.1. 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.
6.2. 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 [WHOIS8] (AnycastROA mechanism).
6.3. Multicast
Multicast addressing in IPv8 follows the conventions specified in
§Section 6.3.
6.4. 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.
7. IPv8 Packet Header
7.1. Header Format
Thain & Aleinikov Expires 18 April 2027 [Page 26]
Internet-Draft IPv8 October 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Route Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Local Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Route Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Local Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
[RFC791].
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).
7.2. 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 (§Section 4.6); 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
Thain & Aleinikov Expires 18 April 2027 [Page 27]
Internet-Draft IPv8 October 2026
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 §Section 3 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.
7.3. 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
[RFC4364]). A system operator creates the VRF and the device
forwards the Route Number's traffic through the provider's
existing VPNv4 distribution machinery.
Thain & Aleinikov Expires 18 April 2027 [Page 28]
Internet-Draft IPv8 October 2026
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 [SUPPORT8]), and ARP is one protocol with
IPv8-extension behaviour for 64-bit address resolution (see
[SUPPORT8] §ARP8). The suite does not specify "TCP8", "UDP8",
"ICMP8", or "ARP8" as separate protocols; these names refer to
extensions of the existing protocols.
8. Coexistence and Deployment
8.1. 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.
8.2. 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.
Thain & Aleinikov Expires 18 April 2027 [Page 29]
Internet-Draft IPv8 October 2026
Where an operator's IPv4 infrastructure is internally implemented
using IPv4-over-IPv6 transport (for example 4in6 [RFC2473], DS-Lite
[RFC6333], 6rd [RFC5969], 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.
8.3. 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 ([SUPPORT8]) and the Zone Server
userspace platform ([ZONESERVER]). 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.
8.3.1. 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 §Section 4.2. 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 [ZONESERVER]. 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:
Thain & Aleinikov Expires 18 April 2027 [Page 30]
Internet-Draft IPv8 October 2026
* *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 [ZONESERVER]) ---
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 §Section 4.6.
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 [WHOIS8]).
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 [RFC4364]) without requiring native IPv8
awareness on intermediate routers.
Thain & Aleinikov Expires 18 April 2027 [Page 31]
Internet-Draft IPv8 October 2026
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.
8.3.2. 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
[WHOIS8] and [SUPPORT8]). 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.
8.3.3. Forwarding Behaviour
Once configured, packet forwarding through the Zone Server is
automatic. The Route8 table ([SUPPORT8]) 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 [ZONESERVER]) 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 [ZONESERVER].
Thain & Aleinikov Expires 18 April 2027 [Page 32]
Internet-Draft IPv8 October 2026
8.3.4. 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.
8.3.5. 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 §Section 4.5. 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 [ZONESERVER]) or
vertically by upgrading edge routers to native IPv8 capability in
subsequent phases as hardware support emerges through normal vendor
product cycles.
Thain & Aleinikov Expires 18 April 2027 [Page 33]
Internet-Draft IPv8 October 2026
8.3.6. 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
Thain & Aleinikov Expires 18 April 2027 [Page 34]
Internet-Draft IPv8 October 2026
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.
8.4. 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 [WHOIS8]).
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 §Section 4.5, 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
[ZONESERVER] §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.
Thain & Aleinikov Expires 18 April 2027 [Page 35]
Internet-Draft IPv8 October 2026
8.5. Interoperation with BGP4
ASes that have not deployed BGP8 continue to operate as BGP4 peers.
The protocol-level interoperation is specified in
[ROUTING-PROTOCOLS]. In summary:
* *Native BGP8 between BGP8-capable peers.* When two peers
successfully negotiate BGP8 capability per [RFC5492] on a session,
IPv8 reachability is exchanged using Multiprotocol BGP [RFC4760]
NLRI with the IPv8 AFI specified in [ROUTING-PROTOCOLS]. 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 [RFC4364] 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
[RFC8092]. The community is named asn-ibgp-path; its semantics
and propagation are specified in [ROUTING-PROTOCOLS]. BGP4-only
routers receiving such advertisements propagate the community
transparently per [RFC1997] and [RFC8092] 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 [ROUTING-PROTOCOLS].
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
Thain & Aleinikov Expires 18 April 2027 [Page 36]
Internet-Draft IPv8 October 2026
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 [RFC4271], 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 [ROUTING-PROTOCOLS] 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 [ROUTING-PROTOCOLS].
Thain & Aleinikov Expires 18 April 2027 [Page 37]
Internet-Draft IPv8 October 2026
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.
8.6. 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:
ip remote zoneserver ipv4 <remote-public-addr> encrypt
ip remote zoneserver ipv8 <RN>-<LA> encrypt
The ipv4 form designates a remote reached across the public Internet;
the Zone Server installs an 8-over-IPv4 path (protocol number per
§Section 11) 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 [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 [RFC4271], 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),
Thain & Aleinikov Expires 18 April 2027 [Page 38]
Internet-Draft IPv8 October 2026
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 §Section 8.3 (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.
9. Implementation Status
This section records the status of known implementations at the time
of writing, per the guidance of [RFC7942]. 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 §Section 5.3. 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.
Thain & Aleinikov Expires 18 April 2027 [Page 39]
Internet-Draft IPv8 October 2026
*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 (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.
10. Security Considerations
10.1. Trust Foundation
The IPv8 trust model rests on the existing RPKI [RFC6480] 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).
10.2. 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 [RFC6483] applied to IPv8 prefixes
rejects advertisements whose origin AS does not match a published
ROA.
Thain & Aleinikov Expires 18 April 2027 [Page 40]
Internet-Draft IPv8 October 2026
* RINE-level admission policy (per [RINE]) 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.
10.3. Reserved Block Protection
The reserved Route Number blocks defined in §Section 5.4 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.
10.4. Per-Segment RN Invariant Enforcement
The per-segment-one-RN invariant (§Section 4.6) 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 [SUPPORT8] 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.
10.5. Encapsulation Boundary Trust
IPv8-in-IPv4 encapsulation (specified in [SUPPORT8]) 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:
Thain & Aleinikov Expires 18 April 2027 [Page 41]
Internet-Draft IPv8 October 2026
* 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.
10.6. 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 (§Section 6.3) MUST be filtered by ingress policy at the
AS boundary; broadcast addresses MUST NOT be forwarded across any RN
boundary.
10.7. Trust State Update Discipline
Per the operational pattern in §Section 4.8, 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.
11. 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.
11.1. 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
[RFC791].
Thain & Aleinikov Expires 18 April 2027 [Page 42]
Internet-Draft IPv8 October 2026
11.2. 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 §Section 7.
11.3. 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 §Section 5.4.
11.4. 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
§Section 5.4 and detailed in [RINE].
11.5. 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 §Section 5.4.
11.6. Route Number Reserved Blocks: Future Allocation Pools
IANA is requested to record the additional RN-block reservations
specified in the table in §Section 5.4 (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.
11.7. 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.
11.8. 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 [SUPPORT8].
Thain & Aleinikov Expires 18 April 2027 [Page 43]
Internet-Draft IPv8 October 2026
11.9. .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 [WHOIS8].
11.10. 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 [ZONESERVER].
* *Option 223* --- IPv8 Interface Mode. Carries the per-interface
mode value (normal, strict, pnp, guest) as specified in
§Section 4.9.2 of this document and in [ZONESERVER].
The values 222 and 223 are taken from the DHCP private-use range
pending permanent IANA assignment.
12. References
12.1. Normative References
12.2. Informative References
13. Informative References
[IEEE8021X]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks --- Port-Based Network Access Control", IEEE
802.1X-2020, 2020.
[NETLOG8] Thain, J., "NetLog8 Protocol", Work in Progress, Internet-
Draft, draft-thain-netlog8-06, May 2026,
<https://datatracker.ietf.org/doc/html/draft-thain-
netlog8-06>.
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, August 1996,
<https://www.rfc-editor.org/rfc/rfc1997>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Thain & Aleinikov Expires 18 April 2027 [Page 44]
Internet-Draft IPv8 October 2026
[RFC2473] Conta, A., "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998,
<https://www.rfc-editor.org/rfc/rfc2473>.
[RFC2865] Rigney, C., "Remote Authentication Dial In User Service
(RADIUS)", RFC 2865, June 2000,
<https://www.rfc-editor.org/rfc/rfc2865>.
[RFC4271] Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)",
RFC 4271, January 2006,
<https://www.rfc-editor.org/rfc/rfc4271>.
[RFC4364] Rosen, E., "BGP/MPLS IP Virtual Private Networks (VPNs)",
RFC 4364, February 2006,
<https://www.rfc-editor.org/rfc/rfc4364>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007, <https://www.rfc-editor.org/rfc/rfc4760>.
[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227,
July 2008, <https://www.rfc-editor.org/rfc/rfc5227>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, February 2009,
<https://www.rfc-editor.org/rfc/rfc5492>.
[RFC5737] Arkko, J., "IPv4 Address Blocks Reserved for
Documentation", RFC 5737, January 2010,
<https://www.rfc-editor.org/rfc/rfc5737>.
[RFC5969] Townsley, W., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5969, August 2010,
<https://www.rfc-editor.org/rfc/rfc5969>.
[RFC6333] Durand, A., "Dual-Stack Lite Broadband Deployments
Following IPv4 Exhaustion", RFC 6333, August 2011,
<https://www.rfc-editor.org/rfc/rfc6333>.
[RFC6480] Lepinski, M., "An Infrastructure to Support Secure
Internet Routing", RFC 6480, February 2012,
<https://www.rfc-editor.org/rfc/rfc6480>.
[RFC6482] Lepinski, M., "A Profile for Route Origin Authorizations
(ROAs)", RFC 6482, February 2012,
<https://www.rfc-editor.org/rfc/rfc6482>.
Thain & Aleinikov Expires 18 April 2027 [Page 45]
Internet-Draft IPv8 October 2026
[RFC6483] Huston, G., "Validation of Route Origination Using the
Resource Certificate PKI and ROAs", RFC 6483, February
2012, <https://www.rfc-editor.org/rfc/rfc6483>.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811, January
2013, <https://www.rfc-editor.org/rfc/rfc6811>.
[RFC7519] Jones, M., "JSON Web Token (JWT)", RFC 7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981,
<https://www.rfc-editor.org/rfc/rfc791>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 7942, July
2016, <https://www.rfc-editor.org/rfc/rfc7942>.
[RFC8092] Heitz, J., Snijders, J., Patel, K., Bagdonas, I., and N.
Hilliard, "BGP Large Communities Attribute", RFC 8092,
February 2017, <https://www.rfc-editor.org/rfc/rfc8092>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", RFC 9082, June 2021,
<https://www.rfc-editor.org/rfc/rfc9082>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", RFC 9083, June
2021, <https://www.rfc-editor.org/rfc/rfc9083>.
[RINE] Thain, J., "Regional Inter-Network Exchange", Work in
Progress, Internet-Draft, draft-thain-rine-03, May 2026,
<https://datatracker.ietf.org/doc/html/draft-thain-rine-
03>.
Thain & Aleinikov Expires 18 April 2027 [Page 46]
Internet-Draft IPv8 October 2026
[ROUTING-PROTOCOLS]
Thain, J., "BGP8, IBGP8, OSPF8, IS-IS8, Cost Factor, and
8to4", Work in Progress, Internet-Draft, draft-thain-
routing-protocols-06, May 2026,
<https://datatracker.ietf.org/doc/html/draft-thain-
routing-protocols-06>.
[SUPPORT8] Thain, J., "IPv8 Support Protocols: ARP8, ICMPv8, Route8,
and ACL8", Work in Progress, Internet-Draft, draft-thain-
support8-06, May 2026,
<https://datatracker.ietf.org/doc/html/draft-thain-
support8-06>.
[WHOIS8] Thain, J., "WHOIS8 Protocol and Trust Bootstrap", Work in
Progress, Internet-Draft, draft-thain-whois8-03, May 2026,
<https://datatracker.ietf.org/doc/html/draft-thain-
whois8-03>.
[WIREGUARD]
Donenfeld, J., "WireGuard: Next Generation Kernel Network
Tunnel", NDSS 2017, 2017.
[ZONESERVER]
Thain, J., "Zone Server Architecture", Work in Progress,
Internet-Draft, draft-thain-zoneserver-03, May 2026,
<https://datatracker.ietf.org/doc/html/draft-thain-
zoneserver-03>.
Appendix A. Appendix A: Changes since -02
This appendix summarises the substantive changes. Editorial
corrections, reference updates, and similar housekeeping are not
enumerated individually.
A.1. Principal Changes
* *Co-author.* Aleksei Aleinikov (Open-IPv8-Lab) is added as co-
author; see Contributors.
Thain & Aleinikov Expires 18 April 2027 [Page 47]
Internet-Draft IPv8 October 2026
* *Broadcast-domain Local Address uniqueness.* The per-segment
invariant (§Section 4.6) 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 (§Section 4.9.1) 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 (§Section 8.6)
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 [SUPPORT8]. 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 [SUPPORT8].
Thain & Aleinikov Expires 18 April 2027 [Page 48]
Internet-Draft IPv8 October 2026
* *Running code.* A mainline-kernel reference implementation (the
two modules of §Section 9) now exists and has been tested
independently; correctness requirements in this revision reflect
results from loading and attacking that code on running kernels.
A.2. 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.
A.3. Reserved RN Blocks
* A complete reservation table for the RN-leading-octet namespace
has been added in §Section 5.4, 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 [ZONESERVER].
A.4. RN-as-VRF Framing
* §Section 4.2 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.
Thain & Aleinikov Expires 18 April 2027 [Page 49]
Internet-Draft IPv8 October 2026
* Internal operator VRFs (hospital, phones, payroll, customer
L3VPNs, etc.) continue to operate per [RFC4364] and are out of
scope for IPv8; only inter-RN routing is specified by the IPv8
suite.
A.5. Per-Segment RN Invariant
* §Section 4.6 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 [SUPPORT8]) detects
invariant violations at runtime.
A.6. Wire Format Rule Precision
* §Section 7.2 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.
A.7. Per-Interface Mode
* §Section 4.9.2 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).
Thain & Aleinikov Expires 18 April 2027 [Page 50]
Internet-Draft IPv8 October 2026
A.8. 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 [ZONESERVER] and [SUPPORT8].
A.9. 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.
A.10. Edge Router IPv4 Requirement
* §Section 4.5 adds the requirement that public IPv8 edge routers
maintain IPv4 connectivity sufficient to serve as 8-over-IPv4
encapsulation endpoints during the transition period.
A.11. Typical Deployment Pattern
* §Section 8.3 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.
Thain & Aleinikov Expires 18 April 2027 [Page 51]
Internet-Draft IPv8 October 2026
* 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.
Thain & Aleinikov Expires 18 April 2027 [Page 52]
Internet-Draft IPv8 October 2026
* 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.
A.12. BGP8 Propagation Mechanisms Across Heterogeneous Infrastructure
* An earlier working revision presented the asn-ibgp-path BGP large
community [RFC8092] 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
[RFC5492]; BGP-in-VRF via VPNv4 [RFC4364] where the iBGP fabric
supports L3VPN distribution; and the asn-ibgp-path BGP large
community [RFC8092] 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.
Thain & Aleinikov Expires 18 April 2027 [Page 53]
Internet-Draft IPv8 October 2026
A.13. Intra-Zone Native Traffic and Host-What-You-Advertise
* §Section 4.2 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.
A.14. 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 [ROUTING-PROTOCOLS]
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 [ROUTING-PROTOCOLS].
Thain & Aleinikov Expires 18 April 2027 [Page 54]
Internet-Draft IPv8 October 2026
A.15. 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 [RFC2865] 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 [ZONESERVER]: 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 [ZONESERVER]. The claim that a single network
interface MAY participate in multiple VLANs simultaneously is
removed; multi-zone access is described in [ZONESERVER] via vNIC
and profile mechanisms, not via Layer 2 multiplexing on a single
physical interface.
A.16. 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.
Appendix B. 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.
Thain & Aleinikov Expires 18 April 2027 [Page 55]
Internet-Draft IPv8 October 2026
On the strength of that work he is named as co-author of this
revision.
Appendix C. 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.
Appendix D. Authors' Addresses
Jamie Thain One Limited Hamilton, Bermuda Email: jamie@one.bm
Aleksei Aleinikov Open-IPv8-Lab Email: contact@alekseialeinikov.com
Thain & Aleinikov Expires 18 April 2027 [Page 56]