Re: IPv8 / BGP8 / CF

[Joe Klein via NANOG <nanog () lists nanog org>]

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%20Foreword/Why%20IPv6%20is%20so%20complicated.md
>
> Kind regards,
>
> Job
> _______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/5ZNXWVNJZ6TVZL4W5OXJ22RIJ5J6LUA5/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/YBBF3U6HJ5ELKNYLTOXHRDDJYXA6VHRI/