Joe, Thanks for the outline and let me speak to each one or them. As I am at v3 of the DRAFT documents, and the point of producing a DRAFT is to fix each one. The reality is that IPv6 has reached maturity in terms of global participation. No company is going to introduce IPv6 as there is no compelling reason to. - ❌ Violates layering (L3 ≠ identity, auth, DNS, WHOIS, routing policy) This is simply wrong, a zone server, has a new replacement for RADIUS in a Web based JWT Oath server. 802.1x authentication has existed for years, but is lowly used. - ❌ Claims backward compatibility that is technically impossible I guess I am too old, I lived through IPX IPXv2, IPXv3, and IPXv4. IPv8 = IPv4 + routing number. So there is no change in the IPv4 protocol, so it works. It was an exclamation point from someone who has never written "backwards compatible" software in there lives... - ❌ Reinvents IPv6 poorly (less scalable, less flexible) Zones, are more scalable. There are reserved the 127.x.x.x ASN space for internal addressing. Internal addressing just went 23M Nat + CGNat addresses to 2^56 addresses. This is exactly what i aimed to fix. Scalable. ❌ Breaks fundamental Internet design principles (end-to-end, decentralization) Absolutely this is what I fixed so that every that Internet addressing is hierarchical. ❌ Breaks fundamental Internet design principles (end-to-end, decentralization) Au Contrair I make a set tools to manage these. Jamie 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: - ❌ 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) On Wed, Apr 29, 2026 at 4:46 PM Joe Klein via NANOG <nanog@lists.nanog.org> 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 [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%20Foreword/Why%20IPv6%20is%20so%20complicated.md [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/5ZNXWVNJZ6TVZL4W5OXJ22RIJ5J6LUA5/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5ZNXWVNJ...]
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/YBBF3U6HJ5ELKNYLTOXHRDDJYXA6VHRI/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YBBF3U6H...]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]