Re: IPv8 / BGP8 / CF

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

*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%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/BL2JKWYKAP3SS2BA63HVTKEIGSTISIFM/