*Standards-based matrix: IPv8 draft vs IPv6 + SRv6* *Area* *IPv8 draft* *IPv6 + SRv6 standards path* *Assessment* Standards maturity Individual Internet-Draft; not endorsed and no formal IETF standing. IPv6 is Internet Standard RFC 8200; SR architecture RFC 8402; SRH RFC 8754; SRv6 network programming RFC 8986. *IPv6 + SRv6 wins decisively* Address size 64-bit: 32-bit ASN + 32-bit host 128-bit IPv6 address space IPv8 is smaller and more rigid Routing model ASN-bound addressing; BGP8; WHOIS8 validation BGP4/MP-BGP, IPv6 routing, SR policy, SRv6 SIDs IPv8 couples identity/allocation/routing too tightly Path control “Cost Factor” global metric Segment Routing steers packets through ordered segments while keeping per-flow state at ingress. SRv6 is cleaner and already standardized Programmability New protocol suite SRv6 encodes packet-processing instructions in IPv6 via SIDs. SRv6 provides the useful part without replacing IP Security model OAuth2/JWT, DNS8, WHOIS8, ACL8, Zone Server IPsec, TLS/QUIC, DNSSEC, RPKI/ROA, BGP origin validation, Zero Trust overlays IPv8 over-centralizes trust Route validation WHOIS8 as critical route authority RPKI provides verifiable IP/ASN resource data; RFC 6811 defines BGP origin validation. RPKI path is stronger and deployed Zero Trust alignment Identity embedded into network suite NIST ZTA focuses on users, assets, resources, policy engines, and workflows, not replacing IP. IPv6 + ZTA is more modular Backward compatibility Claims IPv4 is a subset of IPv8 Dual-stack, NAT64/DNS64, 464XLAT, tunnels, SRv6 overlays IPv8’s “no modification” claim is not credible Failure domains Zone Server handles DHCP/DNS/NTP/auth/logging/translation Distributed services; independent failure domains IPv8 creates large blast radius Operations One integrated control stack Incremental adoption with existing tools IPv6 + SRv6 is deployable today Internet philosophy Managed, centralized, registry-dependent Decentralized, policy-based routing with optional overlays IPv8 conflicts with Internet operational reality Enterprise value Unified management vision Can be achieved with IPv6, SRv6, RPKI, DNSSEC, ZTNA, SASE, SIEM IPv8 ideas are better as overlays Cloud fit Claims VPC overlap solved by ASN/zone prefixing IPv6 addressing, SRv6 service chaining, VPNs, EVPN, cloud-native routing IPv6 + SRv6 is more flexible Best use case Conceptual thought experiment Production-grade architecture IPv8 should inform requirements, not replace IP *Bottom line* *IPv8 is trying to solve real problems—management fragmentation, routing trust, address exhaustion, and security—but it solves them by replacing too much of the Internet at once.* A better design is: *IPv6 + SRv6 + RPKI + DNSSEC + Zero Trust + modern telemetry* Joe Klein "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) "*I skate to where the puck is going to be, not to where it has been." -- *Wayne Gretzky "I never lose. I either win or learn" - Nelson Mandela On Wed, Apr 29, 2026 at 3:45 PM Joe Klein <jsklein@gmail.com> wrote:
You’re right to scrutinize this carefully—this draft is ambitious, but it contains multiple *architectural contradictions, deployment impossibilities, and security anti-patterns* that would block real-world adoption.
Below is a *Technical Deep Dive + Standards Critique (IETF/RFC-aligned)* focused on flaws, risks, and what’s fundamentally unworkable. ------------------------------ *🔍 Executive Summary (Blunt Reality)*
*IPv8 (as written) is not viable as an Internet protocol.*
Core reasons:
- ❌ Violates layering (L3 ≠ identity, auth, DNS, WHOIS, routing policy) - ❌ Centralizes trust in ways that break Internet resilience - ❌ Claims backward compatibility that is technically impossible - ❌ Reinvents IPv6 poorly (less scalable, less flexible) - ❌ Introduces operational fragility (Zone Server dependency) - ❌ Breaks fundamental Internet design principles (end-to-end, decentralization) - ❌ Ignores decades of deployed standards (RPKI, DNSSEC, BGP policy)
------------------------------ *🧠 1. Architectural Violations (Biggest Problem)* *❌ Layering Collapse (Violates Internet Model)*
IPv8 mixes:
- L3 (IP) - L7 (OAuth2, JWT) - Control plane (BGP/WHOIS) - Management plane (DHCP, logging, telemetry)
This violates the core design principle:
👉 *RFC 3439 – “Some Internet Architectural Guidelines”*
- Avoid tight coupling between layers - Prefer modularity
*Problem:*
- You cannot require *OAuth2 JWT validation for every “manageable element”* at L3 - Routers and NICs cannot depend on identity providers for packet forwarding
*Impact:*
- Breaks deterministic forwarding - Introduces latency and failure domains - Creates cascading outages (identity → network collapse)
------------------------------ *🔥 2. “Zone Server” = Massive Single Point of Failure* *❌ Centralization Anti-Pattern*
Zone Server does:
- DHCP - DNS - NTP - OAuth - Logging - Routing validation - ACL enforcement - Translation
This is effectively:
👉 “Active Directory + DNS + Firewall + RPKI + SIEM + Router” in one box *Problems:*
1. *Blast radius* - Zone Server failure = total network failure 2. *Scaling* - Cannot scale globally (contrast with DNS hierarchy, BGP federation) 3. *Security* - Single compromise = total control 4. *Latency* - Everything depends on it
------------------------------ *🔐 3. Security Model is Fundamentally Broken* *❌ JWT Everywhere (Misuse of Identity)*
Using:
- OAuth 2.0 - JSON Web Token
*Issues:*
- JWT ≠ network identity - Tokens are: - replayable - revocation-problematic - not designed for packet-level enforcement
*Missing:*
- No equivalent of: - DNSSEC - RPKI - BGPsec
------------------------------ *❌ WHOIS8 for Routing Validation*
This is one of the biggest red flags. *Reality:*
- WHOIS is: - not real-time - not cryptographically authoritative - inconsistent globally
*Existing solution:*
- RPKI + ROA (cryptographically signed)
👉 IPv8 ignores the entire modern routing security stack. ------------------------------ *🌍 4. Addressing Model is Inferior to IPv6* *❌ 64-bit Address Space*
IPv8:
- 64-bit total - 32-bit ASN + 32-bit host
Compare:
- IPv6 → 128-bit
*Problems:*
1. *Too small long-term* - IoT, identity, multi-homing → insufficient 2. *No hierarchy* - ASN-based addressing ≠ aggregation-friendly 3. *Breaks provider-independent addressing*
------------------------------ *❌ ASN = Routing Prefix*
This is fundamentally flawed. *Why:*
- ASN ≠ topology - ASN ≠ location - ASN ≠ ownership stability
*Result:*
- Forces tight coupling between: - routing policy - addressing - Eliminates flexibility of CIDR (RFC 4632)
------------------------------ *⚠️ 5. Backward Compatibility Claims Are False* *❌ “No modification required” is incorrect* *Issues:*
1. *Routers MUST translate v8 ↔ v4* - That is NAT-like behavior → breaks end-to-end 2. *Applications rely on IP semantics* - Changing address structure breaks assumptions 3. *ARP8 requirement* - Requires stack changes on all hosts
👉 This is effectively:
- A new protocol requiring universal upgrade
------------------------------ *🔄 6. ARP8 Model is Problematic* *❌ Dual-probe (ARP8 + ARP4)*
Problems:
- Adds latency - Race conditions - Cache poisoning risk increases - Breaks deterministic neighbor discovery
Compare:
- Neighbor Discovery Protocol - Already solved this cleanly
------------------------------ *📉 7. Routing Model is Unrealistic* *❌ /16 Minimum Prefix Rule* *Problem:*
- Breaks traffic engineering - Removes multihoming flexibility - Conflicts with real-world needs
------------------------------ *❌ Cost Factor (CF)* *Issues:*
- Requires: - global telemetry sharing - synchronized metrics - Violates: - policy-based routing reality
👉 BGP is policy-driven, not metric-driven ------------------------------ *🌐 8. DNS8 + “DNS Required for All Traffic”* *❌ Blocking IP-only traffic*
This breaks:
- Security tools - Embedded systems - Emergency fallback systems
Also:
- DNS is not always trusted or available
------------------------------ *🚫 9. Operational Fragility* *❌ “Everything in DHCP8”*
Single DHCP response provides:
- identity - routing - DNS - auth endpoints
*Problem:*
- DHCP becomes critical infrastructure - Any failure → total outage
------------------------------ *⚡ 10. Even/Odd Gateway Model* *❌ Artificial and unnecessary*
Problems:
- Not topology-aware - Breaks ECMP best practices - Conflicts with modern routing (leaf-spine, SRv6)
------------------------------ *🔬 11. Ignoring Existing Solutions*
IPv8 tries to solve problems already addressed by:
- IPv6 → address space - Segment Routing over IPv6 → path control - RPKI → validation - Zero Trust Architecture → identity - QUIC → performance + encryption
👉 IPv8 reinvents all of these—poorly and incompatibly. ------------------------------ *🧨 12. Critical Design Contradictions* *Contradiction Examples:*
- “No dual stack” vs Requires translation at boundaries - “100% backward compatible” vs Requires ARP8 + DHCP8 + routing changes - “Decentralized Internet” vs Central Zone Server dependency
------------------------------ *🧭 Final Assessment (Your Level – Straight Talk)*
From a *real-world IPv6 / BGP / Zero Trust / infrastructure perspective*: *IPv8 is:*
- ❌ Over-centralized - ❌ Over-engineered - ❌ Misaligned with Internet architecture - ❌ Ignoring 25+ years of operational reality
*The core fatal flaws:*
1. *Layer violation (biggest)* 2. *Centralized control plane* 3. *Incorrect trust model (WHOIS/JWT)* 4. *Inferior addressing vs IPv6* 5. *False backward compatibility*
------------------------------ *🧠 What **Is **Valuable in This Draft*
There *are* ideas worth extracting:
- Unified telemetry concept - Stronger default security posture - Integrated provisioning vision
👉 But these belong in:
- Zero Trust overlays - SDN/SASE architectures - Not a new IP protocol
Joe Klein
"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) "*I skate to where the puck is going to be, not to where it has been." -- *Wayne Gretzky "I never lose. I either win or learn" - Nelson Mandela
On Wed, Apr 29, 2026 at 3:34 PM Job Snijders via NANOG < nanog@lists.nanog.org> wrote:
I thought Brian's "Why IPv6 is so complicated" was interesting, especially the "Why adding bits isn't simple" section.
https://github.com/becarpenter/book6/blob/main/01.%20Introduction%20and%20Fo...
Kind regards,
Job _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5ZNXWVNJ...