Hi All, My name is Jamie Thain I'm the creator of IPv8. It's not a hoax. I joined this list because, as part of IPv8, I am creating a BGPv8. Inside BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to create better engineering results. I also as part of CF created Sun Tzu which is the protocol that watches CF and gives you a CF score of reliability. Do I trust my partnership with you? Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, etc, etc. That's not my discussion point. My point isn't "should I even propose IPv8" my point is what would be the best result for operators? I believe that since IPv8 solves the duopoly problem, it will replace IPv4. So the things to know, IPV8 is NOT a 64 bit addressing system. It is a 32 bit routing system with a 32 bit addressing system. A Routing Number = ASNs plus others. 8.8.8.8 would become 15169.8.8.8.8 https://www.ietf.org/archive/id/draft-thain-ipv8-02.html <https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea3372a?u=12457652> So each ASN in the world will have 3 Billion available addresses. There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x I'd appreciate your thoughts on it Jamie
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
Job, That is an interesting premise. But its wrong. That premise is that there are only 2 ways to "add bits" 1. Dual Stack 2. Translation and thats wrong a third way is 3. Encapsulation In IPv8 it is NOT a new protocol it is IPv8 with the ASN numbers + others as (Routing Numbers) Each ASN / RN has any anycast IPv4 from every IPv8 router. IPv8 client -- IPv4 -- Ipv4 -- ASN (Ipv8 -- Ipv4) So for example, if you were Google 15169 and you wanted to get to 15169.20.20.20.10 you as the IPv8 client sees the next hop is an IPv4 hop, and so you look up the Anycast of 15169, lets say its 20.20.10.10 and you send the packet to that anycast ipv8 router, encapsulated in ipv4. At that end it unecapsulates it, And delivers it. So Encapsulation is the key. Jamie On Wed, Apr 29, 2026 at 4: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...
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...
*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...
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]
Dear Mr. Thain, Thank you for sharing your work and perspective with the community. The continuous evolution of internet technologies is of great importance for network operators, and contributions that aim to address structural limitations are always valuable for discussion. In this context, your efforts regarding IPv8, BGPv8, and the associated mechanisms such as Cost Factor (CF) and “Sun Tzu” are certainly noteworthy and merit careful technical evaluation. From an operational standpoint, it is widely recognized that the limitations of IPv4 necessitate long-term solutions. While IPv6 has been positioned as the primary successor, ongoing discussions around alternative approaches can provide useful insights, particularly in terms of routing efficiency, scalability, and trust modeling between networks. Your proposal appears to introduce a different perspective by integrating routing intelligence with addressing, and by attempting to redefine how operators evaluate path reliability and cost. These are important considerations, especially for large-scale and performance-sensitive environments. That said, for such an approach to gain broader acceptance, aspects such as interoperability with existing infrastructure, transition mechanisms, operational complexity, and real-world deployment feasibility would be critical areas to further elaborate on. Thank you again for bringing this topic forward. I look forward to seeing further developments and technical discussions around your proposal. Kind regards, Volkan Salih 29.04.2026 22:03 tarihinde Jamie Thain via NANOG yazdı:
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
I joined this list because, as part of IPv8, I am creating a BGPv8. Inside BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to create better engineering results.
I also as part of CF created Sun Tzu which is the protocol that watches CF and gives you a CF score of reliability. Do I trust my partnership with you?
Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, etc, etc. That's not my discussion point. My point isn't "should I even propose IPv8" my point is what would be the best result for operators?
I believe that since IPv8 solves the duopoly problem, it will replace IPv4.
So the things to know, IPV8 is NOT a 64 bit addressing system.
It is a 32 bit routing system with a 32 bit addressing system.
A Routing Number = ASNs plus others.
8.8.8.8 would become 15169.8.8.8.8
https://www.ietf.org/archive/id/draft-thain-ipv8-02.html <https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea3372a?u=12457652>
So each ASN in the world will have 3 Billion available addresses.
There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x
I'd appreciate your thoughts on it
Jamie _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KPDE4FNB...
So each ASN in the world will have 3 Billion available addresses.
There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x
I'd appreciate your thoughts on it
A single IPv6 /64 contains 18 quintillion addresses. Why would anyone need some magic new IP version that gives them much less? Beyond that, your proposal is riddled with technical deficiencies and incorrect assumptions. On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
I joined this list because, as part of IPv8, I am creating a BGPv8. Inside BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to create better engineering results.
I also as part of CF created Sun Tzu which is the protocol that watches CF and gives you a CF score of reliability. Do I trust my partnership with you?
Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, etc, etc. That's not my discussion point. My point isn't "should I even propose IPv8" my point is what would be the best result for operators?
I believe that since IPv8 solves the duopoly problem, it will replace IPv4.
So the things to know, IPV8 is NOT a 64 bit addressing system.
It is a 32 bit routing system with a 32 bit addressing system.
A Routing Number = ASNs plus others.
8.8.8.8 would become 15169.8.8.8.8
https://www.ietf.org/archive/id/draft-thain-ipv8-02.html < https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea3372a?u=12457652
So each ASN in the world will have 3 Billion available addresses.
There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x
I'd appreciate your thoughts on it
Jamie _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KPDE4FNB...
Jamie, You should have spoken with the hyperscalers driving industry growth. Apple, Google, Mirosoft, Amazon. Most modern silicon and routers are built around them. 1. Modern routers are built on merchant silicon ASICs (Broadcom Jericho/Tomahawk, Cisco Silicon One, Marvell Prestera, etc.) 2. Majority of these chips implement forwarding using fixed pipeline stages. 3. Lookup are done in TCAM (SRAM) structures pre-optimized for specific key widths. 4. v4 lookup = ~32-bit key, v6 lookup ~128-bit key. Hard=ware pipelines are dimensioned for these two widths. 5. IPv8 implies exceed entry width or require multi-stage lookups, reducing scale, imo. You have to realize that forwarding is not implemented in software. This is not an incremental evolution like IPv4 to IPv6. Shrihari Pandit Stealth Communications +1-212-232-2025 *stealth.net <http://stealth.net>* On Wed, Apr 29, 2026 at 2:23 PM Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
I joined this list because, as part of IPv8, I am creating a BGPv8. Inside BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to create better engineering results.
I also as part of CF created Sun Tzu which is the protocol that watches CF and gives you a CF score of reliability. Do I trust my partnership with you?
Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, etc, etc. That's not my discussion point. My point isn't "should I even propose IPv8" my point is what would be the best result for operators?
I believe that since IPv8 solves the duopoly problem, it will replace IPv4.
So the things to know, IPV8 is NOT a 64 bit addressing system.
It is a 32 bit routing system with a 32 bit addressing system.
A Routing Number = ASNs plus others.
8.8.8.8 would become 15169.8.8.8.8
https://www.ietf.org/archive/id/draft-thain-ipv8-02.html < https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea3372a?u=12457652
So each ASN in the world will have 3 Billion available addresses.
There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x
I'd appreciate your thoughts on it
Jamie _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KPDE4FNB...
Shrihari Let's think about it for a while. There are two ways to transport things in an ipv8 network. 1. Inside the asn and it's basically ipv4 with a path set so it takes a lookup to the next ipv4 hop but at the ipv8 router inside the asn it makes a decision on the ipv4 address destination part and sends it to that encapsulated address. So basically the loopback of that ipv8 address. 2. Outside the asn it send it to the ipv4 anycast address. There are 2 more lookups but the superscalars are not aware of it. It's not 64 bits of address it's area codes plus address. So what do you think? Jamie On Wed., Apr. 29, 2026, 6:09 p.m. Shrihari Pandit, <spandit@stealth.net> wrote:
Jamie,
You should have spoken with the hyperscalers driving industry growth. Apple, Google, Mirosoft, Amazon. Most modern silicon and routers are built around them.
1. Modern routers are built on merchant silicon ASICs (Broadcom Jericho/Tomahawk, Cisco Silicon One, Marvell Prestera, etc.) 2. Majority of these chips implement forwarding using fixed pipeline stages. 3. Lookup are done in TCAM (SRAM) structures pre-optimized for specific key widths. 4. v4 lookup = ~32-bit key, v6 lookup ~128-bit key. Hard=ware pipelines are dimensioned for these two widths. 5. IPv8 implies exceed entry width or require multi-stage lookups, reducing scale, imo.
You have to realize that forwarding is not implemented in software. This is not an incremental evolution like IPv4 to IPv6.
Shrihari Pandit Stealth Communications +1-212-232-2025 *stealth.net <http://stealth.net>*
On Wed, Apr 29, 2026 at 2:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
I joined this list because, as part of IPv8, I am creating a BGPv8. Inside BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to create better engineering results.
I also as part of CF created Sun Tzu which is the protocol that watches CF and gives you a CF score of reliability. Do I trust my partnership with you?
Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, etc, etc. That's not my discussion point. My point isn't "should I even propose IPv8" my point is what would be the best result for operators?
I believe that since IPv8 solves the duopoly problem, it will replace IPv4.
So the things to know, IPV8 is NOT a 64 bit addressing system.
It is a 32 bit routing system with a 32 bit addressing system.
A Routing Number = ASNs plus others.
8.8.8.8 would become 15169.8.8.8.8
https://www.ietf.org/archive/id/draft-thain-ipv8-02.html < https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea3372a?u=12457652
So each ASN in the world will have 3 Billion available addresses.
There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x
I'd appreciate your thoughts on it
Jamie _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KPDE4FNB...
Shrihari, The point I'm trying to work thru right now is the fib has a field to mark forwarding for v4vpn type ii and if for the asn i make a vrf = asn and an rd of asn:65535 i might be able to avoid tunneling and use the silicon while in transition. Ipv8 is not a 64 bit address its an 32bit asn postal code. And a 32 ipv4 address. Jamie On Wed, Apr 29, 2026 at 7:36 PM Jamie Thain <jamie@one.bm> wrote:
Shrihari
Let's think about it for a while. There are two ways to transport things in an ipv8 network.
1. Inside the asn and it's basically ipv4 with a path set so it takes a lookup to the next ipv4 hop but at the ipv8 router inside the asn it makes a decision on the ipv4 address destination part and sends it to that encapsulated address.
So basically the loopback of that ipv8 address.
2. Outside the asn it send it to the ipv4 anycast address.
There are 2 more lookups but the superscalars are not aware of it.
It's not 64 bits of address it's area codes plus address.
So what do you think?
Jamie
On Wed., Apr. 29, 2026, 6:09 p.m. Shrihari Pandit, <spandit@stealth.net> wrote:
Jamie,
You should have spoken with the hyperscalers driving industry growth. Apple, Google, Mirosoft, Amazon. Most modern silicon and routers are built around them.
1. Modern routers are built on merchant silicon ASICs (Broadcom Jericho/Tomahawk, Cisco Silicon One, Marvell Prestera, etc.) 2. Majority of these chips implement forwarding using fixed pipeline stages. 3. Lookup are done in TCAM (SRAM) structures pre-optimized for specific key widths. 4. v4 lookup = ~32-bit key, v6 lookup ~128-bit key. Hard=ware pipelines are dimensioned for these two widths. 5. IPv8 implies exceed entry width or require multi-stage lookups, reducing scale, imo.
You have to realize that forwarding is not implemented in software. This is not an incremental evolution like IPv4 to IPv6.
Shrihari Pandit Stealth Communications +1-212-232-2025 *stealth.net <http://stealth.net>*
On Wed, Apr 29, 2026 at 2:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
I joined this list because, as part of IPv8, I am creating a BGPv8. Inside BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to create better engineering results.
I also as part of CF created Sun Tzu which is the protocol that watches CF and gives you a CF score of reliability. Do I trust my partnership with you?
Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, etc, etc. That's not my discussion point. My point isn't "should I even propose IPv8" my point is what would be the best result for operators?
I believe that since IPv8 solves the duopoly problem, it will replace IPv4.
So the things to know, IPV8 is NOT a 64 bit addressing system.
It is a 32 bit routing system with a 32 bit addressing system.
A Routing Number = ASNs plus others.
8.8.8.8 would become 15169.8.8.8.8
https://www.ietf.org/archive/id/draft-thain-ipv8-02.html < https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea3372a?u=12457652
So each ASN in the world will have 3 Billion available addresses.
There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x
I'd appreciate your thoughts on it
Jamie _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KPDE4FNB...
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling. Stop supporting this LLM psychosis. -- ++ytti
On Thu, 30 Apr 2026, Saku Ytti via NANOG wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Agreed. This has already been making the rounds in IETF and the feedback there was tougher because people have already lived through this with IPv10 which wasted an enormous amount of time and effort. Just tell whoever is proposing something like this to start coding up their effort, and show that it works. This doesn't need more design documents, it needs running code. Then the authors will find all the problems being glossed over, and perhaps come to their senses. -- Mikael Abrahamsson email: swmike@swm.pp.se
Saku You think you can type into an llm build a better protocol and it will snap one out of the air. But do you think you should build an ietf standard in 2026 with out llm. If your not using llm everyday your competitors are. But further to my problem what else do i need to solve. I solved route growth as peering is now optional, Vpns by making vpn over quic And best path by cost factor. Anything else need to be fixed? On Thu., Apr. 30, 2026, 3:25 a.m. Saku Ytti, <saku@ytti.fi> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti
On Thu, 2026-04-30 at 09:58 -0300, Jamie Thain via NANOG wrote:
If your not using llm everyday your competitors are.
That's not the flex you think it is. Back in `98 folks were saying if you aren't on AOL you're a fool. There's lots of history around "you should be doing this now!". -Jim P.
Problems? I can think of a few.... ---- Besides the silicon speed/forwarding which was already touched on, which effectively makes this a non-starter for a good 15-20 years anyway until hardware catches up...... and this is a huge problem on its own. ----- I can see no way in which this is not a still dual-stack 'like' environment. Except now instead of just IPv4 vs IPv6, you've got IPv4 vs IPv8 vs IPv6 vs IPv4 inside IPv8.AS12345 versus..... and so on and so forth, rendering the IPv4 internet essentially useless. I've got machines or software that are in critical roles that are over 20 years old and speak IPv6 and IPv4 just fine. They'll be hit by that problem easily. So will almost anything existing and current today, for that matter. For a thought exercise example - If I have 1.2.3.4 inside my AS, but a device or software wants 1.2.3.4 from the old IPv4 internet, how does it get there? The IPv4 packets coming from the endpoint all just still say 1.2.3.4. They get my 1.2.3.4 and can't ever get to the 'old' ipv4 1.2.3.4 without explicit management/policy based routing type scenarios, and that's just unacceptable from a corporate network management perspective. And neigh impossible from an ISP perspective. Plus, what if the device should be able to get to both? Remember, the device only speaks IPv4 and IPv6. So, I need to have an IPv8, IPv6 and IPv4 stack, where non-aware applications only use the IPv4 and IPv6 stacks and only receive the 'old' global IPv4. Only aware devices/applications could access both the 'inside AS' service and 'outside AS' old global IPv4 service. So, in 20 years, it might be tenable, whereas IPv6 was tenable from 1998 onwards after most of the standards development/dust has settled. My AIX manufacturing systems with software from 1999 and 2001 work just fine in today's IPv6/IPv4 environment, but would be limited in this IPv8 world. ----- Security tooling. That's a big one. That'd be a long discussion. A lot of extra logic to add/handle here. 'peering is now optional' - are we all just running our own giant intranets now? The whole point of the internet is massive interconnection - aka peering.
But do you think you should build an ietf standard in 2026 with out llm.
Absolutely, then you put some thought and skill into it. LLMs are effectively useless at producing something durable and quality if you don't have the skill to do it yourself given a reasonable amount of time in the current state they're in. And I utilize the hell out of them every day. But never for anything so critical, not without taking the draft and re-writing it entirely myself at a minimum to ensure it makes logical sense and is compliant with sanity. Throwing three different models at a specific problem, filtering down the results, and producing an excellent result? That, that it can do just fine. But that's 'diagnose why X doesn't do Y in this specific code, except for ABC condition, when it should do it also for XYZ condition' type work.
If your not using llm everyday your competitors are.
And they're hurting all the more for relying on entirely or over-using it, burning money, and giving me with limited contextual usage a huge advantage and I thank them for it. Because now they're making awesome mistakes they'd never made before. If you could do something in two days, an LLM *might* help you do it in an hour. A week? Shortened to a day of careful babysitting. If it's something you couldn't do entirely yourself, however, the LLM will give you rank garbage and give others huge openings to take advantage of, if it produces something sensical and working at all. I for one welcome the rampant unconstrained AI adoption. It's already gotten me great business opportunities. -----Original Message----- From: Jamie Thain via NANOG <nanog@lists.nanog.org> Sent: Thursday, April 30, 2026 8:58 AM To: Saku Ytti <saku@ytti.fi> Cc: North American Network Operators Group <nanog@lists.nanog.org>; Jamie Thain <jamie@one.bm> Subject: Re: IPv8 / BGP8 / CF Saku You think you can type into an llm build a better protocol and it will snap one out of the air. But do you think you should build an ietf standard in 2026 with out llm. If your not using llm everyday your competitors are. But further to my problem what else do i need to solve. I solved route growth as peering is now optional, Vpns by making vpn over quic And best path by cost factor. Anything else need to be fixed? On Thu., Apr. 30, 2026, 3:25 a.m. Saku Ytti, <saku@ytti.fi> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AKF4M2DQ...
Gary, For one I've been doing networking since 1986, ArcNet, Token Ring, both types of Ethernet, SNA, IPX/SPX, TCP/IP -- 100s of global networds designed and built, ISPs, WiSPs. 1. There is no silicon catchup because ExtraNet it arrives with Anycast. Same with the peering, you can still peer, but you own for example 12312 the shortest path to an IPv8 will be anycast to you, and you route from where ever to the ipv4 of that address. 2. How do we get to IP address 10.10.10.10 if say its in 10 different VRFs, and 1/2 of them are on IPv4 and 1/2 of them are on IPv8 how do you know which ones are which, and of course VRFs and ELANs leave I identifiers of which interface are they on. 3. So can I use that Identifier when something is headed towards an ASN because a router can support multiple ASN I've been thinking of something like this interface gig0/1.100 ip vrf forwarding 100 ip v8 vrf asn 12312 4. In Corporate each ipV8 native segment (think VLAN) has at least 1 pair of Zone Servers, that the connextion is done at, and that one VLAN has at least one internal ASN attached to it from 127.x.x.x 5. A 20 year old machine on an IPv8 segment the rule is IPv8 only speaks IPv4 to that device. Remember IPv8 IS NOT a new protocol, it is exactly IPv4 plus an AreaCode routing 5.1 When an IPv4 gets the options from the DHCP server of the ASN, and NetLog, it just ignores it, and the Zone Server marks that that client is IPv4 and speaks IPv4 to it. 5.2 When an IPv4 client goes to speak to an IPv8 network the client does an addressbyname, and the DNS server performes the address by name, and puts the source address and the destination address in the connection server, and returns the ip address of the xlate server for the zone (usually the same server) and then does a NAT4to8 essentially and the process sends the packets to the closest ipV8 router and server. 5.3 IPv4 packets in an IPv4 network are marked 0.0.0.0.1.2.3.4 ASN0 5.4 IPv4 packets in an IPv8 network are marked 15122.1.2.3.4 as they go through the connection service. But I am thinking the best way in a BGP interior network is to have a community name asn-comm-ipv4:ASN number and that way the communities in each VRF can decode the ASN that the source packets are attached to. That's my last biggest thing of how to do. Jamie On Thu, Apr 30, 2026 at 10:29 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
Problems? I can think of a few....
----
Besides the silicon speed/forwarding which was already touched on, which effectively makes this a non-starter for a good 15-20 years anyway until hardware catches up...... and this is a huge problem on its own.
-----
I can see no way in which this is not a still dual-stack 'like' environment. Except now instead of just IPv4 vs IPv6, you've got IPv4 vs IPv8 vs IPv6 vs IPv4 inside IPv8.AS12345 versus..... and so on and so forth, rendering the IPv4 internet essentially useless.
I've got machines or software that are in critical roles that are over 20 years old and speak IPv6 and IPv4 just fine. They'll be hit by that problem easily. So will almost anything existing and current today, for that matter.
For a thought exercise example -
If I have 1.2.3.4 inside my AS, but a device or software wants 1.2.3.4 from the old IPv4 internet, how does it get there?
The IPv4 packets coming from the endpoint all just still say 1.2.3.4.
They get my 1.2.3.4 and can't ever get to the 'old' ipv4 1.2.3.4 without explicit management/policy based routing type scenarios, and that's just unacceptable from a corporate network management perspective. And neigh impossible from an ISP perspective. Plus, what if the device should be able to get to both?
Remember, the device only speaks IPv4 and IPv6.
So, I need to have an IPv8, IPv6 and IPv4 stack, where non-aware applications only use the IPv4 and IPv6 stacks and only receive the 'old' global IPv4. Only aware devices/applications could access both the 'inside AS' service and 'outside AS' old global IPv4 service.
So, in 20 years, it might be tenable, whereas IPv6 was tenable from 1998 onwards after most of the standards development/dust has settled. My AIX manufacturing systems with software from 1999 and 2001 work just fine in today's IPv6/IPv4 environment, but would be limited in this IPv8 world.
-----
Security tooling. That's a big one. That'd be a long discussion. A lot of extra logic to add/handle here.
'peering is now optional' - are we all just running our own giant intranets now? The whole point of the internet is massive interconnection - aka peering.
But do you think you should build an ietf standard in 2026 with out llm.
Absolutely, then you put some thought and skill into it. LLMs are effectively useless at producing something durable and quality if you don't have the skill to do it yourself given a reasonable amount of time in the current state they're in. And I utilize the hell out of them every day.
But never for anything so critical, not without taking the draft and re-writing it entirely myself at a minimum to ensure it makes logical sense and is compliant with sanity.
Throwing three different models at a specific problem, filtering down the results, and producing an excellent result? That, that it can do just fine. But that's 'diagnose why X doesn't do Y in this specific code, except for ABC condition, when it should do it also for XYZ condition' type work.
If your not using llm everyday your competitors are.
And they're hurting all the more for relying on entirely or over-using it, burning money, and giving me with limited contextual usage a huge advantage and I thank them for it. Because now they're making awesome mistakes they'd never made before.
If you could do something in two days, an LLM *might* help you do it in an hour. A week? Shortened to a day of careful babysitting. If it's something you couldn't do entirely yourself, however, the LLM will give you rank garbage and give others huge openings to take advantage of, if it produces something sensical and working at all.
I for one welcome the rampant unconstrained AI adoption. It's already gotten me great business opportunities.
-----Original Message----- From: Jamie Thain via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> Sent: Thursday, April 30, 2026 8:58 AM To: Saku Ytti <saku@ytti.fi [saku@ytti.fi]> Cc: North American Network Operators Group <nanog@lists.nanog.org [nanog@lists.nanog.org]>; Jamie Thain <jamie@one.bm [jamie@one.bm]> Subject: Re: IPv8 / BGP8 / CF
Saku
You think you can type into an llm build a better protocol and it will snap one out of the air.
But do you think you should build an ietf standard in 2026 with out llm.
If your not using llm everyday your competitors are.
But further to my problem what else do i need to solve.
I solved route growth as peering is now optional, Vpns by making vpn over quic And best path by cost factor.
Anything else need to be fixed?
On Thu., Apr. 30, 2026, 3:25 a.m. Saku Ytti, <saku@ytti.fi [saku@ytti.fi]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/AKF4M2DQLS3JAF3MIAEYJK7DOOTNTBCP/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AKF4M2DQ...]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
Maybe I’m really missing something here, but here’s what I see. ---- 5. A 20 year old machine on an IPv8 segment the rule is IPv8 only speaks IPv4 to that device. Remember IPv8 IS NOT a new protocol, it is exactly IPv4 plus an AreaCode routing Great, it’s only emitting IPv4 packet to IPv4 destinations. So it remains just inside my network since it has no outside destination. It becomes at the IPv8 router 0.0.0.0.1.2.3.4 or 1.2.3.4.1.2.3.4. Because if you’re source tagging it with my ASN, then ….. well, the destination of the new 64-bit address is …. My ASN. IPv8 while not intended to be a new protocol, fundamentally is. Because you changed the addressing to 64-bit. And broke the existing IPv4 internet in the process. Because the IPv4 (and IPv6!) internet does not rely on DNS, which leads into…… ----
5.2 When an IPv4 client goes to speak to an IPv8 network the client does an addressbyname, and the DNS server performes the address by name, and puts the source address and the destination address in the connection server, and returns the ip address of the xlate server for the zone (usually the same server) and then does a NAT4to8 essentially and the process sends the packets to the closest ipV8 router and server.
And if I’m not using DNS? A lot of stuff doesn’t utilize DNS. More than should, but it’s a reality. And not every DNS server is inside your network. There’s a lot of legitimate reasons to point a device at a DNS server that isn’t your providers or even company’s system. And we’re not in the business of intercepting/modifying user traffic. So I can’t just DPI their DNS traffic A home user just wants it to work as it works today. Their IoT doohickey needs to keep working. ----- 4. In Corporate each ipV8 native segment (think VLAN) has at least 1 pair of Zone Servers, that the connextion is done at, and that one VLAN has at least one internal ASN attached to it from 127.x.x.x 5.1 When an IPv4 gets the options from the DHCP server of the ASN, and NetLog, it just ignores it, and the Zone Server marks that that client is IPv4 and speaks IPv4 to it. 5.4 IPv4 packets in an IPv8 network are marked 15122.1.2.3.4 as they go through the connection service. Why do I need all this extra infrastructure/hardware/processing power? Unacceptable. ---- As to silicon that’s clear to see, we have hardware pathways today for 32 and 128 bit addressing. You’re introducing 64-bit addressing. From: Jamie Thain <jamie@one.bm> Sent: Thursday, April 30, 2026 9:55 AM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org>; Saku Ytti <saku@ytti.fi> Subject: Re: IPv8 / BGP8 / CF Gary, For one I've been doing networking since 1986, ArcNet, Token Ring, both types of Ethernet, SNA, IPX/SPX, TCP/IP -- 100s of global networds designed and built, ISPs, WiSPs. 1. There is no silicon catchup because ExtraNet it arrives with Anycast. Same with the peering, you can still peer, but you own for example 12312 the shortest path to an IPv8 will be anycast to you, and you route from where ever to the ipv4 of that address. 2. How do we get to IP address 10.10.10.10 if say its in 10 different VRFs, and 1/2 of them are on IPv4 and 1/2 of them are on IPv8 how do you know which ones are which, and of course VRFs and ELANs leave I identifiers of which interface are they on. 3. So can I use that Identifier when something is headed towards an ASN because a router can support multiple ASN I've been thinking of something like this interface gig0/1.100 ip vrf forwarding 100 ip v8 vrf asn 12312 4. In Corporate each ipV8 native segment (think VLAN) has at least 1 pair of Zone Servers, that the connextion is done at, and that one VLAN has at least one internal ASN attached to it from 127.x.x.x 5. A 20 year old machine on an IPv8 segment the rule is IPv8 only speaks IPv4 to that device. Remember IPv8 IS NOT a new protocol, it is exactly IPv4 plus an AreaCode routing 5.1 When an IPv4 gets the options from the DHCP server of the ASN, and NetLog, it just ignores it, and the Zone Server marks that that client is IPv4 and speaks IPv4 to it. 5.2 When an IPv4 client goes to speak to an IPv8 network the client does an addressbyname, and the DNS server performes the address by name, and puts the source address and the destination address in the connection server, and returns the ip address of the xlate server for the zone (usually the same server) and then does a NAT4to8 essentially and the process sends the packets to the closest ipV8 router and server. 5.3 IPv4 packets in an IPv4 network are marked 0.0.0.0.1.2.3.4 ASN0 5.4 IPv4 packets in an IPv8 network are marked 15122.1.2.3.4 as they go through the connection service. But I am thinking the best way in a BGP interior network is to have a community name asn-comm-ipv4:ASN number and that way the communities in each VRF can decode the ASN that the source packets are attached to. That's my last biggest thing of how to do. Jamie On Thu, Apr 30, 2026 at 10:29 AM Gary Sparkes <gary@kisaracorporation.com<mailto:gary@kisaracorporation.com>> wrote: Problems? I can think of a few.... ---- Besides the silicon speed/forwarding which was already touched on, which effectively makes this a non-starter for a good 15-20 years anyway until hardware catches up...... and this is a huge problem on its own. ----- I can see no way in which this is not a still dual-stack 'like' environment. Except now instead of just IPv4 vs IPv6, you've got IPv4 vs IPv8 vs IPv6 vs IPv4 inside IPv8.AS12345 versus..... and so on and so forth, rendering the IPv4 internet essentially useless. I've got machines or software that are in critical roles that are over 20 years old and speak IPv6 and IPv4 just fine. They'll be hit by that problem easily. So will almost anything existing and current today, for that matter. For a thought exercise example - If I have 1.2.3.4 inside my AS, but a device or software wants 1.2.3.4 from the old IPv4 internet, how does it get there? The IPv4 packets coming from the endpoint all just still say 1.2.3.4. They get my 1.2.3.4 and can't ever get to the 'old' ipv4 1.2.3.4 without explicit management/policy based routing type scenarios, and that's just unacceptable from a corporate network management perspective. And neigh impossible from an ISP perspective. Plus, what if the device should be able to get to both? Remember, the device only speaks IPv4 and IPv6. So, I need to have an IPv8, IPv6 and IPv4 stack, where non-aware applications only use the IPv4 and IPv6 stacks and only receive the 'old' global IPv4. Only aware devices/applications could access both the 'inside AS' service and 'outside AS' old global IPv4 service. So, in 20 years, it might be tenable, whereas IPv6 was tenable from 1998 onwards after most of the standards development/dust has settled. My AIX manufacturing systems with software from 1999 and 2001 work just fine in today's IPv6/IPv4 environment, but would be limited in this IPv8 world. ----- Security tooling. That's a big one. That'd be a long discussion. A lot of extra logic to add/handle here. 'peering is now optional' - are we all just running our own giant intranets now? The whole point of the internet is massive interconnection - aka peering.
But do you think you should build an ietf standard in 2026 with out llm.
Absolutely, then you put some thought and skill into it. LLMs are effectively useless at producing something durable and quality if you don't have the skill to do it yourself given a reasonable amount of time in the current state they're in. And I utilize the hell out of them every day. But never for anything so critical, not without taking the draft and re-writing it entirely myself at a minimum to ensure it makes logical sense and is compliant with sanity. Throwing three different models at a specific problem, filtering down the results, and producing an excellent result? That, that it can do just fine. But that's 'diagnose why X doesn't do Y in this specific code, except for ABC condition, when it should do it also for XYZ condition' type work.
If your not using llm everyday your competitors are.
And they're hurting all the more for relying on entirely or over-using it, burning money, and giving me with limited contextual usage a huge advantage and I thank them for it. Because now they're making awesome mistakes they'd never made before. If you could do something in two days, an LLM *might* help you do it in an hour. A week? Shortened to a day of careful babysitting. If it's something you couldn't do entirely yourself, however, the LLM will give you rank garbage and give others huge openings to take advantage of, if it produces something sensical and working at all. I for one welcome the rampant unconstrained AI adoption. It's already gotten me great business opportunities. -----Original Message----- From: Jamie Thain via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, April 30, 2026 8:58 AM To: Saku Ytti <saku@ytti.fi<mailto:saku@ytti.fi>> Cc: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>>; Jamie Thain <jamie@one.bm<mailto:jamie@one.bm>> Subject: Re: IPv8 / BGP8 / CF Saku You think you can type into an llm build a better protocol and it will snap one out of the air. But do you think you should build an ietf standard in 2026 with out llm. If your not using llm everyday your competitors are. But further to my problem what else do i need to solve. I solved route growth as peering is now optional, Vpns by making vpn over quic And best path by cost factor. Anything else need to be fixed? On Thu., Apr. 30, 2026, 3:25 a.m. Saku Ytti, <saku@ytti.fi<mailto:saku@ytti.fi>> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AKF4M2DQ...
Dear Jamie, Stop talking to LLMs. No, seriously. Stop NOW! LLM models WILL NOT tell you are wrong, they will keep reinforcing your beliefs to keep you wasting tokens. This is what the models were "trained" to do. You are showing all signs of going down a sycophantic loop with a delusional LLM. You are not the first one, and you won't be the last. I urge you to go and read this: https://techcrunch.com/2025/10/02/ex-openai-researcher-dissects-one-of-chatg... But really ready it! Don't ask for a summary, or tell your agents to extract the key points. Use your MK1 eyeballs. Now, after reading that carefully, think about this: You have a whole community of experienced network engineers telling you are wrong in the most fundamental ideas of your design. Ask yourself: Have I maybe got a bit too excited with my LLM sessions and forgot to do some critical thinking? Am I so out of touch? Or is it the children that are wrong? With the best of intentions, Andre
Andre's point here is 100% correct. This thread should probably die now. Andrew On Thu, Apr 30, 2026 at 7:21 PM Andre Sencioles via NANOG < nanog@lists.nanog.org> wrote:
Dear Jamie,
Stop talking to LLMs. No, seriously. Stop NOW! LLM models WILL NOT tell you are wrong, they will keep reinforcing your beliefs to keep you wasting tokens. This is what the models were "trained" to do.
You are showing all signs of going down a sycophantic loop with a delusional LLM. You are not the first one, and you won't be the last. I urge you to go and read this: https://techcrunch.com/2025/10/02/ex-openai-researcher-dissects-one-of-chatg... But really ready it! Don't ask for a summary, or tell your agents to extract the key points. Use your MK1 eyeballs.
Now, after reading that carefully, think about this: You have a whole community of experienced network engineers telling you are wrong in the most fundamental ideas of your design.
Ask yourself: Have I maybe got a bit too excited with my LLM sessions and forgot to do some critical thinking? Am I so out of touch? Or is it the children that are wrong?
With the best of intentions, Andre _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TI4B6LGZ...
On Thu, 30 Apr 2026, Jamie Thain via NANOG wrote:
But do you think you should build an ietf standard in 2026 with out llm.
Then stop making new design documents and put the LLM time towards implementing the ones you already have. Then you will discover all the things you've missed. -- Mikael Abrahamsson email: swmike@swm.pp.se
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating. Reading Mr. Thain's replies here and on int-area answers that question quite rapidly. On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QAQPQMJT...
I hadn't seen anyone note (in this forum) that the proposal here is: 1) already stepping on a proposal which got closed out ~25 yrs (or more?) ago <can't find jim fleming's draft, sorry, though we are all better off for not finding it?> 2) that this smells an awful lot like 8+8 GSE -> https://datatracker.ietf.org/doc/html/draft-ietf-ipngwg-gseaddr-00 (hey mo!) probably sometime in the future another IPNGWG will get spun up, but that day's not today. On Thu, Apr 30, 2026 at 10:51 AM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
I read SOME of the replies from the author as ... computer-person-computer-personing...
This is very funny! - In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code. - Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)? Have fun. OO. 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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG <nanog@lists.nanog.org
wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QAQPQMJT...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YAH63OJ4...
I see no need for this IPv8. IPv6 was carefully engineered over many years and while not perfect, works and is deployed. What problem are you trying to solve? I seem to have missed that. No one is going to adopt IPv8. This is an academic discussion at best. On Thursday, April 30th, 2026 at 10:51 AM, Joe Klein via NANOG <nanog@lists.nanog.org> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG <nanog@lists.nanog.org
wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QAQPQMJT...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YAH63OJ4...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/WWUAVWF5...
IPv6 is deployed? There is a routine thread here a couple of times a year complaining about how it isn't. On Thu, Apr 30, 2026 at 12:44 PM Lucien Hoydic via NANOG < nanog@lists.nanog.org> wrote:
I see no need for this IPv8. IPv6 was carefully engineered over many years and while not perfect, works and is deployed. What problem are you trying to solve? I seem to have missed that.
No one is going to adopt IPv8. This is an academic discussion at best.
On Thursday, April 30th, 2026 at 10:51 AM, Joe Klein via NANOG < nanog@lists.nanog.org> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
Joe Klein
"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene
"*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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG < nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG < nanog@lists.nanog.org
wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QAQPQMJT...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YAH63OJ4... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/WWUAVWF5... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HTZGUHK5...
Deployed and Fully Deployed are two very different things, but this proposal would have the same problem getting deployed that IPv6 does, which is why? For MOST users IPv4 still works. Shane
On Apr 30, 2026, at 12:46 PM, Josh Luthman via NANOG <nanog@lists.nanog.org> wrote:
IPv6 is deployed? There is a routine thread here a couple of times a year complaining about how it isn't.
On Thu, Apr 30, 2026 at 12:44 PM Lucien Hoydic via NANOG < nanog@lists.nanog.org> wrote:
I see no need for this IPv8. IPv6 was carefully engineered over many years and while not perfect, works and is deployed. What problem are you trying to solve? I seem to have missed that.
No one is going to adopt IPv8. This is an academic discussion at best.
On Thursday, April 30th, 2026 at 10:51 AM, Joe Klein via NANOG < nanog@lists.nanog.org> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
Joe Klein
"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene
"*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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG < nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG < nanog@lists.nanog.org
wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QAQPQMJT...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YAH63OJ4... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/WWUAVWF5... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HTZGUHK5...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EIZ73ZKW...
On Thu, 30 Apr 2026 at 20:06, sronan--- via NANOG <nanog@lists.nanog.org> wrote:
Deployed and Fully Deployed are two very different things, but this proposal would have the same problem getting deployed that IPv6 does, which is why? For MOST users IPv4 still works.
Aye, problem isn't IPv6 but IPv4, which has annoying problem in that it keeps working. Should that change, IPv6 would be adopted in a hurry. I earnestly believe we should have flag day, where bigtech agrees to start dropping IPv4 in edge in like 2040-01-01 or some such. To create strong signal that we're moving on, and that IPv6 only host becomes something markets can accept. Anyone using IPv4 has to do the translation on their end, IPv6-only networks not. I don't think we will do that, but I think we should. I think IPv4 is pretty significant antitrust issue, because addresses have accumulated to legacy players and new entrants have additional hurtle to compete against them. -- ++ytti
Joe, No patent apps it's all free. Corp isn't moving off ipv4 to ipv6. So ipv8 is an upgrade to ipv4. So still need to fix the issues in ipv4/ipv6. Like merging to companies both using 10.x Unless a move is made ipv4 will still be running the warp drive. People are planning to build ipv8 right now. Jamie On Thu., Apr. 30, 2026, 12:51 p.m. Joe Klein, <jsklein@gmail.com> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG < nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG < nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QAQPQMJT...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YAH63OJ4...
" People are planning to build ipv8 right now." Are these people in the room with us? ---- Larry Brower Network Specialist Texas Department of Insurance -----Original Message----- From: Jamie Thain via NANOG <nanog@lists.nanog.org> Sent: Thursday, April 30, 2026 2:29 PM To: Joe Klein <jsklein@gmail.com> Cc: North American Network Operators Group <nanog@lists.nanog.org>; Jamie Thain <jamie@one.bm> Subject: Re: IPv8 / BGP8 / CF ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown or unexpected emails. Joe, No patent apps it's all free. Corp isn't moving off ipv4 to ipv6. So ipv8 is an upgrade to ipv4. So still need to fix the issues in ipv4/ipv6. Like merging to companies both using 10.x Unless a move is made ipv4 will still be running the warp drive. People are planning to build ipv8 right now. Jamie On Thu., Apr. 30, 2026, 12:51 p.m. Joe Klein, <jsklein@gmail.com> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG < nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG < nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lis/ ts.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2F QAQPQMJT3AEGHZERA2XJW3WIWBAMHBAI%2F&data=05%7C02%7Clarry.brower%40tdi .texas.gov%7Cc3453c4609a743c6edf508dea6eee8e4%7C6c600c887a50421a9817a 970a01aed2a%7C0%7C0%7C639131742220406986%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=z68PupwkZzOUUeCDnys6LqnLWd%2BF Qk%2BbKmyR7hWOvqk%3D&reserved=0
_______________________________________________ NANOG mailing list
https://lis/ ts.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2F YAH63OJ4IJ3GKNROAILZHO6YXQQ5NQ2S%2F&data=05%7C02%7Clarry.brower%40tdi .texas.gov%7Cc3453c4609a743c6edf508dea6eee8e4%7C6c600c887a50421a9817a 970a01aed2a%7C0%7C0%7C639131742220433138%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=S8FDk5iZSahEvFlR2%2FTPr9d%2Fr5 tqYX%2FGJRcg2GFPfb4%3D&reserved=0
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KMODQSXZ...
Larry, Maybe, I am not sure the Nanog group has the same people, but some university students are working on it. I have one thing I am trying to finish. But let me ask you, I assume you run a pretty big network. And likely on 10.x.x.x as thats what everyone does. How much more convenient would it be to segment networks by internal ASN number I chose 127.x.x.x as local network. 127.<department>.<region>.floor. == 10 Billion IP addresses. Everything would be secured, isolated, managed, auditable. Jamie On Thu, Apr 30, 2026 at 4:32 PM Larry Brower <Larry.Brower@tdi.texas.gov> wrote:
" People are planning to build ipv8 right now."
Are these people in the room with us?
---- Larry Brower Network Specialist Texas Department of Insurance
-----Original Message----- From: Jamie Thain via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> Sent: Thursday, April 30, 2026 2:29 PM To: Joe Klein <jsklein@gmail.com [jsklein@gmail.com]> Cc: North American Network Operators Group <nanog@lists.nanog.org [nanog@lists.nanog.org]>; Jamie Thain <jamie@one.bm [jamie@one.bm]> Subject: Re: IPv8 / BGP8 / CF
ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown or unexpected emails.
Joe,
No patent apps it's all free. Corp isn't moving off ipv4 to ipv6. So ipv8 is an upgrade to ipv4.
So still need to fix the issues in ipv4/ipv6.
Like merging to companies both using 10.x
Unless a move is made ipv4 will still be running the warp drive.
People are planning to build ipv8 right now.
Jamie
On Thu., Apr. 30, 2026, 12:51 p.m. Joe Klein, <jsklein@gmail.com [jsklein@gmail.com]> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lis/ [https://lis/] ts.nanog.org [http://ts.nanog.org]%2Farchives%2Flist%2Fnanog% 40lists.nanog.org [http://40lists.nanog.org]%2Fmessage%2F QAQPQMJT3AEGHZERA2XJW3WIWBAMHBAI%2F&data=05%7C02%7Clarry.brower%40tdi .texas.gov [http://texas.gov]%7Cc3453c4609a743c6edf508dea6eee8e4% 7C6c600c887a50421a9817a 970a01aed2a%7C0%7C0%7C639131742220406986%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=z68PupwkZzOUUeCDnys6LqnLWd%2BF Qk%2BbKmyR7hWOvqk%3D&reserved=0
_______________________________________________ NANOG mailing list
https://lis/ [https://lis/] ts.nanog.org [http://ts.nanog.org]%2Farchives%2Flist%2Fnanog% 40lists.nanog.org [http://40lists.nanog.org]%2Fmessage%2F YAH63OJ4IJ3GKNROAILZHO6YXQQ5NQ2S%2F&data=05%7C02%7Clarry.brower%40tdi .texas.gov [http://texas.gov]%7Cc3453c4609a743c6edf508dea6eee8e4% 7C6c600c887a50421a9817a 970a01aed2a%7C0%7C0%7C639131742220433138%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=S8FDk5iZSahEvFlR2%2FTPr9d%2Fr5 tqYX%2FGJRcg2GFPfb4%3D&reserved=0
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/KMODQSXZM35D3SHAER4UGOBOTWP22BD3/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KMODQSXZ...]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
If you have worked in the large scale network world as long as you say you have, you’d know that 99.9999% of what comes out of universities at this point related to networks and network protocols is all pipe dreams and has no connection to reality. Here on NANOG you have the OPERATORS of the world largest networks, and they are all telling you, that you missed the mark, that should tell you something. Shane
On Apr 30, 2026, at 4:06 PM, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Larry,
Maybe, I am not sure the Nanog group has the same people, but some university students are working on it.
I have one thing I am trying to finish. But let me ask you,
I assume you run a pretty big network. And likely on 10.x.x.x as thats what everyone does. How much more convenient would it be to segment networks by internal ASN number I chose 127.x.x.x as local network.
127.<department>.<region>.floor. == 10 Billion IP addresses.
Everything would be secured, isolated, managed, auditable.
Jamie
On Thu, Apr 30, 2026 at 4:32 PM Larry Brower <Larry.Brower@tdi.texas.gov> wrote:
" People are planning to build ipv8 right now."
Are these people in the room with us?
---- Larry Brower Network Specialist Texas Department of Insurance
-----Original Message----- From: Jamie Thain via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> Sent: Thursday, April 30, 2026 2:29 PM To: Joe Klein <jsklein@gmail.com [jsklein@gmail.com]> Cc: North American Network Operators Group <nanog@lists.nanog.org [nanog@lists.nanog.org]>; Jamie Thain <jamie@one.bm [jamie@one.bm]> Subject: Re: IPv8 / BGP8 / CF
ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown or unexpected emails.
Joe,
No patent apps it's all free. Corp isn't moving off ipv4 to ipv6. So ipv8 is an upgrade to ipv4.
So still need to fix the issues in ipv4/ipv6.
Like merging to companies both using 10.x
Unless a move is made ipv4 will still be running the warp drive.
People are planning to build ipv8 right now.
Jamie
On Thu., Apr. 30, 2026, 12:51 p.m. Joe Klein, <jsklein@gmail.com [jsklein@gmail.com]> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lis/ [https://lis/] ts.nanog.org [http://ts.nanog.org]%2Farchives%2Flist%2Fnanog% 40lists.nanog.org [http://40lists.nanog.org]%2Fmessage%2F QAQPQMJT3AEGHZERA2XJW3WIWBAMHBAI%2F&data=05%7C02%7Clarry.brower%40tdi .texas.gov [http://texas.gov]%7Cc3453c4609a743c6edf508dea6eee8e4% 7C6c600c887a50421a9817a 970a01aed2a%7C0%7C0%7C639131742220406986%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=z68PupwkZzOUUeCDnys6LqnLWd%2BF Qk%2BbKmyR7hWOvqk%3D&reserved=0
_______________________________________________ NANOG mailing list
https://lis/ [https://lis/] ts.nanog.org [http://ts.nanog.org]%2Farchives%2Flist%2Fnanog% 40lists.nanog.org [http://40lists.nanog.org]%2Fmessage%2F YAH63OJ4IJ3GKNROAILZHO6YXQQ5NQ2S%2F&data=05%7C02%7Clarry.brower%40tdi .texas.gov [http://texas.gov]%7Cc3453c4609a743c6edf508dea6eee8e4% 7C6c600c887a50421a9817a 970a01aed2a%7C0%7C0%7C639131742220433138%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=S8FDk5iZSahEvFlR2%2FTPr9d%2Fr5 tqYX%2FGJRcg2GFPfb4%3D&reserved=0
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/KMODQSXZM35D3SHAER4UGOBOTWP22BD3/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KMODQSXZ...]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D] _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YTOTVZJY...
Shane, Missed the mark on what? I'm trying to fix IPv4 for corporates. You guys do whatever you want. I want help fixing BGP but if you think its all great so be it. Jamie On Thu, Apr 30, 2026 at 5:10 PM <sronan@ronan-online.com> wrote:
If you have worked in the large scale network world as long as you say you have, you’d know that 99.9999% of what comes out of universities at this point related to networks and network protocols is all pipe dreams and has no connection to reality. Here on NANOG you have the OPERATORS of the world largest networks, and they are all telling you, that you missed the mark, that should tell you something.
Shane
On Apr 30, 2026, at 4:06 PM, Jamie Thain via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Larry,
Maybe, I am not sure the Nanog group has the same people, but some university students are working on it.
I have one thing I am trying to finish. But let me ask you,
I assume you run a pretty big network. And likely on 10.x.x.x as thats what everyone does. How much more convenient would it be to segment networks by internal ASN number I chose 127.x.x.x as local network.
127.<department>.<region>.floor. == 10 Billion IP addresses.
Everything would be secured, isolated, managed, auditable.
Jamie
On Thu, Apr 30, 2026 at 4:32 PM Larry Brower <Larry.Brower@tdi.texas.gov [Larry.Brower@tdi.texas.gov]> wrote:
" People are planning to build ipv8 right now."
Are these people in the room with us?
---- Larry Brower Network Specialist Texas Department of Insurance
-----Original Message----- From: Jamie Thain via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org] [nanog@lists.nanog.org [nanog@lists.nanog.org]]> Sent: Thursday, April 30, 2026 2:29 PM To: Joe Klein <jsklein@gmail.com [jsklein@gmail.com] [jsklein@gmail.com [jsklein@gmail.com]]> Cc: North American Network Operators Group <nanog@lists.nanog.org [nanog@lists.nanog.org] [nanog@lists.nanog.org [nanog@lists.nanog.org]]>; Jamie Thain <jamie@one.bm [jamie@one.bm] [jamie@one.bm [jamie@one.bm]]> Subject: Re: IPv8 / BGP8 / CF
ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown or unexpected emails.
Joe,
No patent apps it's all free. Corp isn't moving off ipv4 to ipv6. So ipv8 is an upgrade to ipv4.
So still need to fix the issues in ipv4/ipv6.
Like merging to companies both using 10.x
Unless a move is made ipv4 will still be running the warp drive.
People are planning to build ipv8 right now.
Jamie
On Thu., Apr. 30, 2026, 12:51 p.m. Joe Klein, <jsklein@gmail.com [jsklein@gmail.com] [jsklein@gmail.com [jsklein@gmail.com]]> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org] [nanog@lists.nanog.org [nanog@lists.nanog.org]]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org] [nanog@lists.nanog.org [nanog@lists.nanog.org]]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lis/ [https://lis/] [https://lis/ [https://lis/]] ts.nanog.org [http://ts.nanog.org] [http://ts.nanog.org [http://ts.nanog.org]]%2Farchives%2Flist%2Fnanog% 40lists.nanog.org [http://40lists.nanog.org] [http://40lists.nanog.org [http://40lists.nanog.org]]%2Fmessage%2F QAQPQMJT3AEGHZERA2XJW3WIWBAMHBAI%2F&data=05%7C02%7Clarry.brower%40tdi .texas.gov [http://texas.gov] [http://texas.gov [http://texas.gov] ]%7Cc3453c4609a743c6edf508dea6eee8e4% 7C6c600c887a50421a9817a 970a01aed2a%7C0%7C0%7C639131742220406986%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=z68PupwkZzOUUeCDnys6LqnLWd%2BF Qk%2BbKmyR7hWOvqk%3D&reserved=0
_______________________________________________ NANOG mailing list
https://lis/ [https://lis/] [https://lis/ [https://lis/]] ts.nanog.org [http://ts.nanog.org] [http://ts.nanog.org [http://ts.nanog.org]]%2Farchives%2Flist%2Fnanog% 40lists.nanog.org [http://40lists.nanog.org] [http://40lists.nanog.org [http://40lists.nanog.org]]%2Fmessage%2F YAH63OJ4IJ3GKNROAILZHO6YXQQ5NQ2S%2F&data=05%7C02%7Clarry.brower%40tdi .texas.gov [http://texas.gov] [http://texas.gov [http://texas.gov] ]%7Cc3453c4609a743c6edf508dea6eee8e4% 7C6c600c887a50421a9817a 970a01aed2a%7C0%7C0%7C639131742220433138%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=S8FDk5iZSahEvFlR2%2FTPr9d%2Fr5 tqYX%2FGJRcg2GFPfb4%3D&reserved=0
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/KMODQSXZM35D3SHAER4UGOBOTWP22BD3/ [https://lists.nanog.org/archives/list/nanog@lists.nanog. org/message/KMODQSXZM35D3SHAER4UGOBOTWP22BD3/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KMODQSXZ...] ]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D] _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/YTOTVZJYZ4HG55MF6WGDTUKVQ54HHLVI/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YTOTVZJY...]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
“I assume you run a pretty big network. And likely on 10.x.x.x as thats what everyone does. How much more convenient would it be to segment networks by internal ASN number I chose 127.x.x.x as local network. “ No more or less convenient than it is currently. How is “127.x.x.x” any different than “10.X.0.0 or 172.16.X.0”? How is this any better than just using IPv6 which has more than enough addresses? “Everything would be secured, isolated, managed, auditable. “ It is all of these things currently. I am not seeing how anything would be different. I fail to see the problem you are wanting to solve that hasn’t already been solved more or less. Regards, ---- Larry Brower Network Specialist Texas Department of Insurance From: Jamie Thain <jamie@one.bm> Sent: Thursday, April 30, 2026 3:06 PM To: Larry Brower <Larry.Brower@tdi.texas.gov> Cc: North American Network Operators Group <nanog@lists.nanog.org>; Joe Klein <jsklein@gmail.com> Subject: Re: IPv8 / BGP8 / CF ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown or unexpected emails. Larry, Maybe, I am not sure the Nanog group has the same people, but some university students are working on it. I have one thing I am trying to finish. But let me ask you, I assume you run a pretty big network. And likely on 10.x.x.x as thats what everyone does. How much more convenient would it be to segment networks by internal ASN number I chose 127.x.x.x as local network. 127.<department>.<region>.floor. == 10 Billion IP addresses. Everything would be secured, isolated, managed, auditable. Jamie On Thu, Apr 30, 2026 at 4:32 PM Larry Brower <Larry.Brower@tdi.texas.gov<mailto:Larry.Brower@tdi.texas.gov>> wrote: " People are planning to build ipv8 right now." Are these people in the room with us? ---- Larry Brower Network Specialist Texas Department of Insurance -----Original Message----- From: Jamie Thain via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, April 30, 2026 2:29 PM To: Joe Klein <jsklein@gmail.com<mailto:jsklein@gmail.com>> Cc: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>>; Jamie Thain <jamie@one.bm<mailto:jamie@one.bm>> Subject: Re: IPv8 / BGP8 / CF ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown or unexpected emails. Joe, No patent apps it's all free. Corp isn't moving off ipv4 to ipv6. So ipv8 is an upgrade to ipv4. So still need to fix the issues in ipv4/ipv6. Like merging to companies both using 10.x Unless a move is made ipv4 will still be running the warp drive. People are planning to build ipv8 right now. Jamie On Thu., Apr. 30, 2026, 12:51 p.m. Joe Klein, <jsklein@gmail.com<mailto:jsklein@gmail.com>> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lis/ ts.nanog.org<http://ts.nanog.org/>%2Farchives%2Flist%2Fnanog%40lists.nanog.org<http://40lists.nanog.org/>%2Fmessage%2F QAQPQMJT3AEGHZERA2XJW3WIWBAMHBAI%2F&data=05%7C02%7Clarry.brower%40tdi .texas.gov<http://texas.gov/>%7Cc3453c4609a743c6edf508dea6eee8e4%7C6c600c887a50421a9817a 970a01aed2a%7C0%7C0%7C639131742220406986%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=z68PupwkZzOUUeCDnys6LqnLWd%2BF Qk%2BbKmyR7hWOvqk%3D&reserved=0
_______________________________________________ NANOG mailing list
https://lis/ ts.nanog.org<http://ts.nanog.org/>%2Farchives%2Flist%2Fnanog%40lists.nanog.org<http://40lists.nanog.org/>%2Fmessage%2F YAH63OJ4IJ3GKNROAILZHO6YXQQ5NQ2S%2F&data=05%7C02%7Clarry.brower%40tdi .texas.gov<http://texas.gov/>%7Cc3453c4609a743c6edf508dea6eee8e4%7C6c600c887a50421a9817a 970a01aed2a%7C0%7C0%7C639131742220433138%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=S8FDk5iZSahEvFlR2%2FTPr9d%2Fr5 tqYX%2FGJRcg2GFPfb4%3D&reserved=0
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KMODQSXZ...
Larry, You ever get Company A, buying Company B, C, D, and E, in a year and the CTO says to you the network architect. Fix it That problem. Well documented the 10.x collision problem. That's one of them. Jamie On Thu, Apr 30, 2026 at 5:14 PM Larry Brower <Larry.Brower@tdi.texas.gov> wrote:
“I assume you run a pretty big network. And likely on 10.x.x.x as thats what everyone does. How much more convenient would it be to segment networks by internal ASN number I chose 127.x.x.x as local network. “
No more or less convenient than it is currently.
How is “127.x.x.x” any different than “10.X.0.0 or 172.16.X.0”?
How is this any better than just using IPv6 which has more than enough addresses?
“Everything would be secured, isolated, managed, auditable. “
It is all of these things currently. I am not seeing how anything would be different.
I fail to see the problem you are wanting to solve that hasn’t already been solved more or less.
Regards,
----
Larry Brower
Network Specialist
Texas Department of Insurance
From: Jamie Thain <jamie@one.bm [jamie@one.bm]> Sent: Thursday, April 30, 2026 3:06 PM To: Larry Brower <Larry.Brower@tdi.texas.gov [Larry.Brower@tdi.texas.gov]> Cc: North American Network Operators Group <nanog@lists.nanog.org [nanog@lists.nanog.org]>; Joe Klein <jsklein@gmail.com [jsklein@gmail.com]> Subject: Re: IPv8 / BGP8 / CF
ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown or unexpected emails.
Larry,
Maybe, I am not sure the Nanog group has the same people, but some university students are working on it.
I have one thing I am trying to finish. But let me ask you,
I assume you run a pretty big network. And likely on 10.x.x.x as thats what everyone does. How much more convenient would it be to segment networks by internal ASN number I chose 127.x.x.x as local network.
127.<department>.<region>.floor. == 10 Billion IP addresses.
Everything would be secured, isolated, managed, auditable.
Jamie
On Thu, Apr 30, 2026 at 4:32 PM Larry Brower <Larry.Brower@tdi.texas.gov [Larry.Brower@tdi.texas.gov]> wrote:
" People are planning to build ipv8 right now."
Are these people in the room with us?
---- Larry Brower Network Specialist Texas Department of Insurance
-----Original Message----- From: Jamie Thain via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> Sent: Thursday, April 30, 2026 2:29 PM To: Joe Klein <jsklein@gmail.com [jsklein@gmail.com]> Cc: North American Network Operators Group <nanog@lists.nanog.org [nanog@lists.nanog.org]>; Jamie Thain <jamie@one.bm [jamie@one.bm]> Subject: Re: IPv8 / BGP8 / CF
ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown or unexpected emails.
Joe,
No patent apps it's all free. Corp isn't moving off ipv4 to ipv6. So ipv8 is an upgrade to ipv4.
So still need to fix the issues in ipv4/ipv6.
Like merging to companies both using 10.x
Unless a move is made ipv4 will still be running the warp drive.
People are planning to build ipv8 right now.
Jamie
On Thu., Apr. 30, 2026, 12:51 p.m. Joe Klein, <jsklein@gmail.com [jsklein@gmail.com]> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lis/ [https://lis/] ts.nanog.org [http://ts.nanog.org/]%2Farchives%2Flist%2Fnanog% 40lists.nanog.org [http://40lists.nanog.org/]%2Fmessage%2F QAQPQMJT3AEGHZERA2XJW3WIWBAMHBAI%2F&data=05%7C02%7Clarry.brower%40tdi .texas.gov [http://texas.gov/]%7Cc3453c4609a743c6edf508dea6ee e8e4%7C6c600c887a50421a9817a 970a01aed2a%7C0%7C0%7C639131742220406986%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=z68PupwkZzOUUeCDnys6LqnLWd%2BF Qk%2BbKmyR7hWOvqk%3D&reserved=0
_______________________________________________ NANOG mailing list
https://lis/ [https://lis/] ts.nanog.org [http://ts.nanog.org/]%2Farchives%2Flist%2Fnanog% 40lists.nanog.org [http://40lists.nanog.org/]%2Fmessage%2F YAH63OJ4IJ3GKNROAILZHO6YXQQ5NQ2S%2F&data=05%7C02%7Clarry.brower%40tdi .texas.gov [http://texas.gov/]%7Cc3453c4609a743c6edf508dea6ee e8e4%7C6c600c887a50421a9817a 970a01aed2a%7C0%7C0%7C639131742220433138%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=S8FDk5iZSahEvFlR2%2FTPr9d%2Fr5 tqYX%2FGJRcg2GFPfb4%3D&reserved=0
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ KMODQSXZM35D3SHAER4UGOBOTWP22BD3/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KMODQSXZ...]
[data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
Where do you think innovation in corporate network gear comes from? Shane
On Apr 30, 2026, at 4:17 PM, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Larry,
You ever get Company A, buying Company B, C, D, and E, in a year and the CTO says to you the network architect. Fix it
That problem. Well documented the 10.x collision problem.
That's one of them.
Jamie
On Thu, Apr 30, 2026 at 5:14 PM Larry Brower <Larry.Brower@tdi.texas.gov> wrote:
“I assume you run a pretty big network. And likely on 10.x.x.x as thats what everyone does. How much more convenient would it be to segment networks by internal ASN number I chose 127.x.x.x as local network. “
No more or less convenient than it is currently.
How is “127.x.x.x” any different than “10.X.0.0 or 172.16.X.0”?
How is this any better than just using IPv6 which has more than enough addresses?
“Everything would be secured, isolated, managed, auditable. “
It is all of these things currently. I am not seeing how anything would be different.
I fail to see the problem you are wanting to solve that hasn’t already been solved more or less.
Regards,
----
Larry Brower
Network Specialist
Texas Department of Insurance
From: Jamie Thain <jamie@one.bm [jamie@one.bm]> Sent: Thursday, April 30, 2026 3:06 PM To: Larry Brower <Larry.Brower@tdi.texas.gov [Larry.Brower@tdi.texas.gov]> Cc: North American Network Operators Group <nanog@lists.nanog.org [nanog@lists.nanog.org]>; Joe Klein <jsklein@gmail.com [jsklein@gmail.com]> Subject: Re: IPv8 / BGP8 / CF
ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown or unexpected emails.
Larry,
Maybe, I am not sure the Nanog group has the same people, but some university students are working on it.
I have one thing I am trying to finish. But let me ask you,
I assume you run a pretty big network. And likely on 10.x.x.x as thats what everyone does. How much more convenient would it be to segment networks by internal ASN number I chose 127.x.x.x as local network.
127.<department>.<region>.floor. == 10 Billion IP addresses.
Everything would be secured, isolated, managed, auditable.
Jamie
On Thu, Apr 30, 2026 at 4:32 PM Larry Brower <Larry.Brower@tdi.texas.gov [Larry.Brower@tdi.texas.gov]> wrote:
" People are planning to build ipv8 right now."
Are these people in the room with us?
---- Larry Brower Network Specialist Texas Department of Insurance
-----Original Message----- From: Jamie Thain via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> Sent: Thursday, April 30, 2026 2:29 PM To: Joe Klein <jsklein@gmail.com [jsklein@gmail.com]> Cc: North American Network Operators Group <nanog@lists.nanog.org [nanog@lists.nanog.org]>; Jamie Thain <jamie@one.bm [jamie@one.bm]> Subject: Re: IPv8 / BGP8 / CF
ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown or unexpected emails.
Joe,
No patent apps it's all free. Corp isn't moving off ipv4 to ipv6. So ipv8 is an upgrade to ipv4.
So still need to fix the issues in ipv4/ipv6.
Like merging to companies both using 10.x
Unless a move is made ipv4 will still be running the warp drive.
People are planning to build ipv8 right now.
Jamie
On Thu., Apr. 30, 2026, 12:51 p.m. Joe Klein, <jsklein@gmail.com [jsklein@gmail.com]> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lis/ [https://lis/] ts.nanog.org [http://ts.nanog.org/]%2Farchives%2Flist%2Fnanog% 40lists.nanog.org [http://40lists.nanog.org/]%2Fmessage%2F QAQPQMJT3AEGHZERA2XJW3WIWBAMHBAI%2F&data=05%7C02%7Clarry.brower%40tdi .texas.gov [http://texas.gov/]%7Cc3453c4609a743c6edf508dea6ee e8e4%7C6c600c887a50421a9817a 970a01aed2a%7C0%7C0%7C639131742220406986%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=z68PupwkZzOUUeCDnys6LqnLWd%2BF Qk%2BbKmyR7hWOvqk%3D&reserved=0
_______________________________________________ NANOG mailing list
https://lis/ [https://lis/] ts.nanog.org [http://ts.nanog.org/]%2Farchives%2Flist%2Fnanog% 40lists.nanog.org [http://40lists.nanog.org/]%2Fmessage%2F YAH63OJ4IJ3GKNROAILZHO6YXQQ5NQ2S%2F&data=05%7C02%7Clarry.brower%40tdi .texas.gov [http://texas.gov/]%7Cc3453c4609a743c6edf508dea6ee e8e4%7C6c600c887a50421a9817a 970a01aed2a%7C0%7C0%7C639131742220433138%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=S8FDk5iZSahEvFlR2%2FTPr9d%2Fr5 tqYX%2FGJRcg2GFPfb4%3D&reserved=0
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ KMODQSXZM35D3SHAER4UGOBOTWP22BD3/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KMODQSXZ...]
[data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D] _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/S35FV3CF...
And an easy one to resolve already today (Having been through this several times in F500/100 organizations). All the additional infrastructure and other aspects proposed that I addressed in my previous email, makes it a complete non-starter in this situation. Much simpler just to NAT between A B C D and E's networks and do gradual segment renumbering, and much less infrastructure/hardware to do so as well. Of course, this scenario in some of those cases sped up IPv6 plans, and some are running v6-segments only internally, and never have to worry about it again (or any complexity or infrastructure, and NAT is completely gone except for legacy v4 edge access! Which is a minority of the total traffic flow!) -----Original Message----- From: Jamie Thain via NANOG <nanog@lists.nanog.org> Sent: Thursday, April 30, 2026 4:18 PM To: Larry Brower <Larry.Brower@tdi.texas.gov> Cc: North American Network Operators Group <nanog@lists.nanog.org>; Jamie Thain <jamie@one.bm> Subject: Re: IPv8 / BGP8 / CF Larry, You ever get Company A, buying Company B, C, D, and E, in a year and the CTO says to you the network architect. Fix it That problem. Well documented the 10.x collision problem. That's one of them. Jamie On Thu, Apr 30, 2026 at 5:14 PM Larry Brower <Larry.Brower@tdi.texas.gov> wrote:
“I assume you run a pretty big network. And likely on 10.x.x.x as thats what everyone does. How much more convenient would it be to segment networks by internal ASN number I chose 127.x.x.x as local network. “
No more or less convenient than it is currently.
How is “127.x.x.x” any different than “10.X.0.0 or 172.16.X.0”?
How is this any better than just using IPv6 which has more than enough addresses?
“Everything would be secured, isolated, managed, auditable. “
It is all of these things currently. I am not seeing how anything would be different.
I fail to see the problem you are wanting to solve that hasn’t already been solved more or less.
Regards,
----
Larry Brower
Network Specialist
Texas Department of Insurance
From: Jamie Thain <jamie@one.bm [jamie@one.bm]> Sent: Thursday, April 30, 2026 3:06 PM To: Larry Brower <Larry.Brower@tdi.texas.gov [Larry.Brower@tdi.texas.gov]> Cc: North American Network Operators Group <nanog@lists.nanog.org [nanog@lists.nanog.org]>; Joe Klein <jsklein@gmail.com [jsklein@gmail.com]> Subject: Re: IPv8 / BGP8 / CF
ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown or unexpected emails.
Larry,
Maybe, I am not sure the Nanog group has the same people, but some university students are working on it.
I have one thing I am trying to finish. But let me ask you,
I assume you run a pretty big network. And likely on 10.x.x.x as thats what everyone does. How much more convenient would it be to segment networks by internal ASN number I chose 127.x.x.x as local network.
127.<department>.<region>.floor. == 10 Billion IP addresses.
Everything would be secured, isolated, managed, auditable.
Jamie
On Thu, Apr 30, 2026 at 4:32 PM Larry Brower <Larry.Brower@tdi.texas.gov [Larry.Brower@tdi.texas.gov]> wrote:
" People are planning to build ipv8 right now."
Are these people in the room with us?
---- Larry Brower Network Specialist Texas Department of Insurance
-----Original Message----- From: Jamie Thain via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> Sent: Thursday, April 30, 2026 2:29 PM To: Joe Klein <jsklein@gmail.com [jsklein@gmail.com]> Cc: North American Network Operators Group <nanog@lists.nanog.org [nanog@lists.nanog.org]>; Jamie Thain <jamie@one.bm [jamie@one.bm]> Subject: Re: IPv8 / BGP8 / CF
ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown or unexpected emails.
Joe,
No patent apps it's all free. Corp isn't moving off ipv4 to ipv6. So ipv8 is an upgrade to ipv4.
So still need to fix the issues in ipv4/ipv6.
Like merging to companies both using 10.x
Unless a move is made ipv4 will still be running the warp drive.
People are planning to build ipv8 right now.
Jamie
On Thu., Apr. 30, 2026, 12:51 p.m. Joe Klein, <jsklein@gmail.com [jsklein@gmail.com]> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lis/ [https://lis/] ts.nanog.org [http://ts.nanog.org/]%2Farchives%2Flist%2Fnanog% 40lists.nanog.org [http://40lists.nanog.org/]%2Fmessage%2F QAQPQMJT3AEGHZERA2XJW3WIWBAMHBAI%2F&data=05%7C02%7Clarry.brower%4 0tdi .texas.gov [http://texas.gov/]%7Cc3453c4609a743c6edf508dea6ee e8e4%7C6c600c887a50421a9817a 970a01aed2a%7C0%7C0%7C639131742220406986%7CUnknown%7CTWFpbGZsb3d8 eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT WFpb CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=z68PupwkZzOUUeCDnys6LqnLWd %2BF Qk%2BbKmyR7hWOvqk%3D&reserved=0
_______________________________________________ NANOG mailing list
https://lis/ [https://lis/] ts.nanog.org [http://ts.nanog.org/]%2Farchives%2Flist%2Fnanog% 40lists.nanog.org [http://40lists.nanog.org/]%2Fmessage%2F YAH63OJ4IJ3GKNROAILZHO6YXQQ5NQ2S%2F&data=05%7C02%7Clarry.brower%4 0tdi .texas.gov [http://texas.gov/]%7Cc3453c4609a743c6edf508dea6ee e8e4%7C6c600c887a50421a9817a 970a01aed2a%7C0%7C0%7C639131742220433138%7CUnknown%7CTWFpbGZsb3d8 eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT WFpb CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=S8FDk5iZSahEvFlR2%2FTPr9d% 2Fr5 tqYX%2FGJRcg2GFPfb4%3D&reserved=0
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ KMODQSXZM35D3SHAER4UGOBOTWP22BD3/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message /KMODQSXZM35D3SHAER4UGOBOTWP22BD3/]
[data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAE AAAIBRAA7]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D] _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/S35FV3CF...
Jamie, Who is planning to build IPv8, because I can tell you as someone who works for one of the LARGEST networks in the US (both wireline and wireless), there are no plans here. Can you give us some names of the equipment manufacturers or large scale networks that have signed on to this idea? Shane On Thu, Apr 30, 2026 at 3:29 PM Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Joe,
No patent apps it's all free. Corp isn't moving off ipv4 to ipv6. So ipv8 is an upgrade to ipv4.
So still need to fix the issues in ipv4/ipv6.
Like merging to companies both using 10.x
Unless a move is made ipv4 will still be running the warp drive.
People are planning to build ipv8 right now.
Jamie
On Thu., Apr. 30, 2026, 12:51 p.m. Joe Klein, <jsklein@gmail.com> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
Joe Klein
"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene
"*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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG < nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG < nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QAQPQMJT...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YAH63OJ4...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KMODQSXZ...
Who is planning to build IPv8, because I can tell you as someone who works for one of the LARGEST networks in the US (both wireline and wireless), there are no plans here. Can you give us some names of the equipment manufacturers or large scale networks that have signed on to this idea?
Nobody of consequence. This is just a pipe dream Internet-Draft like many others before it. On Thu, Apr 30, 2026 at 3:36 PM Shane Ronan via NANOG <nanog@lists.nanog.org> wrote:
Jamie,
Who is planning to build IPv8, because I can tell you as someone who works for one of the LARGEST networks in the US (both wireline and wireless), there are no plans here. Can you give us some names of the equipment manufacturers or large scale networks that have signed on to this idea?
Shane
On Thu, Apr 30, 2026 at 3:29 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Joe,
No patent apps it's all free. Corp isn't moving off ipv4 to ipv6. So ipv8 is an upgrade to ipv4.
So still need to fix the issues in ipv4/ipv6.
Like merging to companies both using 10.x
Unless a move is made ipv4 will still be running the warp drive.
People are planning to build ipv8 right now.
Jamie
On Thu., Apr. 30, 2026, 12:51 p.m. Joe Klein, <jsklein@gmail.com> wrote:
"*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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG < nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG < nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
Joe Klein
"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QAQPQMJT...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YAH63OJ4...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KMODQSXZ... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DPQYL4SV...
When this was floated on various IETF mailing lists, someone took the time to write: We Need to Talk About the IPv8 Draft - wolfy https://substack.com/home/post/p-194315405 ---rsk
We Need to Talk About the IPv8 Draft - wolfy https://substack.com/home/post/p-194315405
Quoting from there : IPv4 backward compatibility is genuinely elegant. Setting r.r.r.r to
0.0.0.0 makes an IPv8 address identical to an IPv4 add, processed by the standard rules (#1.5 p3, #3.3). This alone is the best contribution of the draft and should be lauded. It single-handedly kills any further incentive to push IPv6, which has struggled for decades to find adoption due to dual-stack, flag day, and forced migration (#1.2 p3, #2.2 p2). Any draft that replaces this initial iteration of IPv8 should include this design choice.
The IPv8 concept is NOT, under any circumstances, backwards compatible with IPv4. Any IP speaking device reads the first 4 bits of the header to identify the version number. The only 2 valid values today are 0100 (4) and 0110 (6). Just as an IPv4 only device won't know what to do if the field is 6, no IP device will know what to do if the field is 8, as proposed in Sec 6.1 of the draft. The author states in the draft that this would never happen because : IPv4 devices behind IPv8 routers continue to operate because the
router downgrades at the boundary. * IPv4 applications on IPv8 hosts continue to operate because XLATE8 handles version translation on their behalf.
Congrats on re-inventing 6to4! On Thu, Apr 30, 2026 at 4:18 PM Rich Kulawiec via NANOG < nanog@lists.nanog.org> wrote:
When this was floated on various IETF mailing lists, someone took the time to write:
We Need to Talk About the IPv8 Draft - wolfy https://substack.com/home/post/p-194315405
---rsk _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QD6JBVII...
Richard, Wolfy did write about but he didn't ask me any details. 64 Bit headroom -- IPv8 is not headroom, it is about adding an AREA code to 32 bit addressing, its not 64 bit at all. So to put it in perspective rather than enough ip address for every atom in the solar system there is only enough for ever square cm on the planet to have 4 ip address. DNS + WHOis Validation is meant to increase north south security. You cannot get to an ip address that doesn't have whois, and dns in strict mode. Of course you can turn that off. VPN survive functions... Zone Server doesn't track who opened what and when. It doesn't track the DNS lookups it tracks performance, and errors. How ever every corporate fw tracks this. Rate Limits turn Zone Server into a single point of failure... except for you can have as many zone servers as you need to be reliable. They come in pairs anyways. Its like losing your DNS server. Rate Elevation inside a company requires you to sign into the corporate networks, that way guests can't harm you. No Flag day is true, you can start with one card, and one router somewhere on the internet and grow from there. Wolfy thinks that policy egress isn't already being managed in firewalls. Oauth2 is being used as an authorization and configuration policy replacing clear-text RADIUS. The draft doesn't violate RFC 7258 as already your work is monitoring you. And at home your in control of your own Zone Server, Zone Server doesn't log packets, just errors *The draft assumes unlimited data storage and doesn’t care.* No it doesn't we only report errors, and performance every five minutes and accounting where required the third A of a radius server. A 1000 person company would be less than a 100G per month. 2 years on a single drive. it doesn't log, dns, or flow, thats all a different device called SIEM or a FW, or a NetFlow none of which NetLog does. *Mandatory identity binding eliminates hardware anonymity by default.* OAuth2 JWT binds to the device at the NIC level before any user interaction This is true, it is built for corporate, the network card is usually following a person around, its built so you can roam from network to network. *The anonymity eliminated is at the layer hardest to restore.* Me thinks wolfy has never looked at a fortigate log, it correlates, MAC address, last ip, every flow, the last logged in, logged in to what networks, all in a handy dandy report manager. *Device-to-traffic attribution becomes a database query, not an investigation.*Me thinks wolfy has never reviewed online firewall logging. *NIC firmware rate limits make the network unusable without Zone Server permission.* This is the broadcast rate so unathenticated users can't DDOS *This architecture is fail-closed, and that can kill people.* Each network segment can be dns-only and have no other restrictions and you need DNS to get from ipv4 to ipv8 there is no other way in the eco system. *IPv8 is fundamentally incompatible with real-time operating systems * IPv8 is 100% ipv4 compatible at the segment level, use IPv4 if you don't want the overhead of IPv8. *All of the stuff about blocking*Its like wolfy has never admined a modern day firewall, you can do all that stuff already. Enough said. On Thu, Apr 30, 2026 at 5:18 PM Rich Kulawiec via NANOG < nanog@lists.nanog.org> wrote:
When this was floated on various IETF mailing lists, someone took the time to write:
We Need to Talk About the IPv8 Draft - wolfy https://substack.com/home/post/p-194315405
---rsk _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QD6JBVII...
Shane, Right now people are building are community people in labs. It's been out 2 weeks, do you think Large Scale network people have even heard of it? I can tell you that all the big companies visited my LinkedIn. The people it addresses are first corporate. The addressing of the internet issues -- were kind of secondary. For example under BGP4 how many routes exist in today's how many would exist under IPv8 The point of introducing an "area code" is you only have to dial that and let the local exchange deal with. :) On Thu, Apr 30, 2026 at 4:35 PM Shane Ronan <shane@ronan-online.com> wrote:
Jamie,
Who is planning to build IPv8, because I can tell you as someone who works for one of the LARGEST networks in the US (both wireline and wireless), there are no plans here. Can you give us some names of the equipment manufacturers or large scale networks that have signed on to this idea?
Shane
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D] On Thu, Apr 30, 2026 at 3:29 PM Jamie Thain via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Joe,
No patent apps it's all free. Corp isn't moving off ipv4 to ipv6. So ipv8 is an upgrade to ipv4.
So still need to fix the issues in ipv4/ipv6.
Like merging to companies both using 10.x
Unless a move is made ipv4 will still be running the warp drive.
People are planning to build ipv8 right now.
Jamie
On Thu., Apr. 30, 2026, 12:51 p.m. Joe Klein, <jsklein@gmail.com [jsklein@gmail.com]> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ QAQPQMJT3AEGHZERA2XJW3WIWBAMHBAI/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QAQPQMJT...]
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ YAH63OJ4IJ3GKNROAILZHO6YXQQ5NQ2S/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YAH63OJ4...]
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ KMODQSXZM35D3SHAER4UGOBOTWP22BD3/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KMODQSXZ...]
On Thu, Apr 30, 2026 at 2:30 PM Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Joe,
No patent apps it's all free. Corp isn't moving off ipv4 to ipv6. So ipv8 is an upgrade to ipv4.
So still need to fix the issues in ipv4/ipv6.
Like merging to companies both using 10.x
Unless a move is made ipv4 will still be running the warp drive.
People are planning to build ipv8 right now.
i look forward to future iterations of the drafts with implementation co-authors. personally, i'll be particularly interested in the hardware implementations of ACL8.
Jamie
On Thu., Apr. 30, 2026, 12:51 p.m. Joe Klein, <jsklein@gmail.com> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
Joe Klein
"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene
"*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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG < nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG < nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QAQPQMJT...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YAH63OJ4...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KMODQSXZ...
-- steve ulrich (sulrich@botwerks.org)
While not quite the same thing, I feel like the arguments are re-hashing EZ IP all over again... Thank you jms On Thu, Apr 30, 2026 at 10:51 AM Tom Beecher via NANOG < nanog@lists.nanog.org> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG <nanog@lists.nanog.org
wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QAQPQMJT...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YAH63OJ4...
LLM produces code much much faster than you can review it. This argument worked in days of yore, when the person writing the code had to put in orders of magnitude more work in that person reviewing it. Anyone maintaining any open source project has seen this, massive complicated pull requests from people who cannot code and have strong expectations that you review it. They spent minutes generating it, you'll spend days reviewing it. On Thu, 30 Apr 2026 at 12:34, Izaac via NANOG <nanog@lists.nanog.org> wrote:
On Wed, Apr 29, 2026 at 02:03:34PM -0500, Jamie Thain via NANOG wrote:
I'd appreciate your thoughts on it
Got code?
-- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6YSXKTNR...
-- ++ytti
Here's a thought I had about that, for whatever it's worth -> https://medium.com/@dornhetzel/a-modest-proposal-for-open-source-trust-refor... On Thu, Apr 30, 2026 at 3:47 AM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
LLM produces code much much faster than you can review it.
This argument worked in days of yore, when the person writing the code had to put in orders of magnitude more work in that person reviewing it.
Anyone maintaining any open source project has seen this, massive complicated pull requests from people who cannot code and have strong expectations that you review it. They spent minutes generating it, you'll spend days reviewing it.
On Thu, 30 Apr 2026 at 12:34, Izaac via NANOG <nanog@lists.nanog.org> wrote:
On Wed, Apr 29, 2026 at 02:03:34PM -0500, Jamie Thain via NANOG wrote:
I'd appreciate your thoughts on it
Got code?
-- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6YSXKTNR...
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/W6QDEOKM...
Appreciate attempt to solve the problem, but I am absolutely disgusted by the notion that this too will be measured by who has access to capital. Call me radical but I think that's an even worse problem than the LLM slop. Not coincidental that this problem was created by people with completely undeserved access to capital and are burning literally trillion annually on this. Bottom 80% of Americans consume as much as the top 20%, and it is getting worse, it may be 90/10 already. And we look up to those 10%, and now you're saying to address the problem they created, we must gate more of the world for them. On Thu, 30 Apr 2026 at 13:16, Dorn Hetzel via NANOG <nanog@lists.nanog.org> wrote:
Here's a thought I had about that, for whatever it's worth -> https://medium.com/@dornhetzel/a-modest-proposal-for-open-source-trust-refor...
On Thu, Apr 30, 2026 at 3:47 AM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
LLM produces code much much faster than you can review it.
This argument worked in days of yore, when the person writing the code had to put in orders of magnitude more work in that person reviewing it.
Anyone maintaining any open source project has seen this, massive complicated pull requests from people who cannot code and have strong expectations that you review it. They spent minutes generating it, you'll spend days reviewing it.
On Thu, 30 Apr 2026 at 12:34, Izaac via NANOG <nanog@lists.nanog.org> wrote:
On Wed, Apr 29, 2026 at 02:03:34PM -0500, Jamie Thain via NANOG wrote:
I'd appreciate your thoughts on it
Got code?
-- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6YSXKTNR...
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/W6QDEOKM...
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/54P7LOEO...
-- ++ytti
On Thu, Apr 30, 2026 at 12:46:44PM +0300, Saku Ytti wrote:
LLM produces code much much faster than you can review it.
So? Fine. We're not even at the "reviewing code" stage. How about just to see it running? This proposal has everything including a damn WHOIS server. How about so much as starting with a couple hosts speaking it across a router? If anything, the existence of LLMs and VMs and software-defined light blinks means there's even LESS excuse for showing up without a demonstrator. Someone's thrown out a recipe. No one's so much as warmed an oven. And you already want to review the winning cookie's chocolate for cocao content. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__
On Thu, 30 Apr 2026 at 13:30, Izaac via NANOG <nanog@lists.nanog.org> wrote:
Someone's thrown out a recipe. No one's so much as warmed an oven. And you already want to review the winning cookie's chocolate for cocao content.
No, I don't think the turd burger should be cooked in the first place, and I think it's dishonest to say this is the problem. -- ++ytti
Izaac via NANOG wrote on 30/04/2026 11:29:
Someone's thrown out a recipe.
Someone threw some idea-spaghetti at the wall. Reinventing IP is a common enough phenomenon. None of the reinventions have added anything new to the baseline wireline protocol that hasn't already been discussed to death by protocol wonks, and probably discussed to death in the early 1990s. This iteration is no different. Nick
On Thu, Apr 30, 2026 at 12:29:49PM +0100, Nick Hilliard via NANOG wrote:
Izaac via NANOG wrote on 30/04/2026 11:29:
Someone's thrown out a recipe.
Someone threw some idea-spaghetti at the wall.
Reinventing IP is a common enough phenomenon. [snip]
Reinventing IP : Networkers :: Killing Hitler : Time Travelers -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling
I oppose this. With IPv6 traffic now representing around half of internet traffic, the time to rethink has long passed. If IPv8 was going to be a solution, it should have been a solution 10 years ago. In the last 12 months, ~5% of traffic migrated to IPv6. At that rate, IPv6 will be fully implemented by 2035. I'm not seeing a problem that needs to be solved, or a credible solution. Andrew On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
I joined this list because, as part of IPv8, I am creating a BGPv8. Inside BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to create better engineering results.
I also as part of CF created Sun Tzu which is the protocol that watches CF and gives you a CF score of reliability. Do I trust my partnership with you?
Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, etc, etc. That's not my discussion point. My point isn't "should I even propose IPv8" my point is what would be the best result for operators?
I believe that since IPv8 solves the duopoly problem, it will replace IPv4.
So the things to know, IPV8 is NOT a 64 bit addressing system.
It is a 32 bit routing system with a 32 bit addressing system.
A Routing Number = ASNs plus others.
8.8.8.8 would become 15169.8.8.8.8
https://www.ietf.org/archive/id/draft-thain-ipv8-02.html < https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea3372a?u=12457652
So each ASN in the world will have 3 Billion available addresses.
There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x
I'd appreciate your thoughts on it
Jamie _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KPDE4FNB...
*Lagging IPv4 Vendors: * https://community.ui.com/questions/Hey-Unifi-improve-your-IPv6-game-starting... *IPv6 status: *https://test-ipv6.com/ Does your system support IPv6 on your network? https://www.vyncke.org/ipv6status/. IPv6 only, IPv6 failover to IPv4 https://developers.cloudflare.com/1.1.1.1/infrastructure/ipv6-networks/. Support for IPv6-only networks https://developer.apple.com/support/ipv6/ Support for IPv6-only networks https://labs.ripe.net/author/ondrej_caletka_1/deploying-ipv6-mostly-access-n... https://medium.com/@imanshul/how-to-enable-ipv6-only-networking-in-android-i... https://blog.brixit.nl/going-ipv6-only/ https://stats.labs.apnic.net/ipv6/ https://www.iana.org/numbers/allocations/. Number Resource Allocation Data https://www.ipv6ready.org/db/index.php/public/?o=4 Hardware Status - If it not there, then *IPv8 status: Not ready yet* 20 years behind IPv6 *IPv9 Status: No status * *Will check in on April 1, 2027/2028/2029... * 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:23 PM Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
I joined this list because, as part of IPv8, I am creating a BGPv8. Inside BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to create better engineering results.
I also as part of CF created Sun Tzu which is the protocol that watches CF and gives you a CF score of reliability. Do I trust my partnership with you?
Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, etc, etc. That's not my discussion point. My point isn't "should I even propose IPv8" my point is what would be the best result for operators?
I believe that since IPv8 solves the duopoly problem, it will replace IPv4.
So the things to know, IPV8 is NOT a 64 bit addressing system.
It is a 32 bit routing system with a 32 bit addressing system.
A Routing Number = ASNs plus others.
8.8.8.8 would become 15169.8.8.8.8
https://www.ietf.org/archive/id/draft-thain-ipv8-02.html < https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea3372a?u=12457652
So each ASN in the world will have 3 Billion available addresses.
There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x
I'd appreciate your thoughts on it
Jamie _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KPDE4FNB...
On Apr 29, 2026, at 12:03 PM, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
Back in the day, I came up with the idea that, as part of the IMAP specification, you could move a message to a special folder that would cause messages to be acted on server-side to create dynamic procmail/sieve/imapfilter rules. Lots of places already use this for spam reporting, but I had greater ambitions, including blocking a specific sender, or to put a user in "timeout" for a while, or even trigger autoresponders. One of the most useful features I envisioned was the ability to automatically mute a given thread before it took up more mental energy than I had in a given week. Today, current-me is really annoyed at past-me for not fully implementing that last one. === Let me tell you a fun story of IPv6. For pretty much *decades* while IPv6 existed, the only way to get v6 support on a router that you were already running with tight memory constraints, and often bought without TAC, was to run a beta version of the OS. Cisco IOS was built for the network stack people are using today, not the one that people might use later. There are lots of devices (literally every one of them) on the internet that have support for IPV4, and probably most of those will now support ipv6, but at the overhead of "twice the routing table size, twice the RIB, twice the peering to manage, twice the customer complaints if there's a weird routing issue". Happy Eyeballs came WAY later than ipv6 did. With IPV8, "now you have three problems". Today, lots of vendors sell kit on the secondary market for which there are no firmware updates, and even if you wanted to buy a support contract to get that firmware, they won't sell to you. To support your proposal, every one of them, all of them, would have to be upgraded. The same reason people haven't broadly supported ipv6 is the same exact reason this proposal is a non-starter. Perhaps in a green-field overlay internet (see also, the 6bone, the mbone, tor, LISP, AMT) you could use this, but it would still have to run on routers and switches that had no idea what it was, at the ip protocol layer. You're never going to get that. My day job deploys dual-stack, everywhere, in production, and we've been doing it for decades. We think that's important to do. We've definitely found some sites and corners of the world where one protocol acted *very differently* from the other. We also find that 90 percent of the traffic we receive on both those stacks is "people who couldn't even figure out how to configure ONE protocol correctly". -Dan (Opinions are my own and do not reflect dayjob's opinion at all -- I am an independent network operator with my own ASN/IP space).
On Sat, May 02, 2026 at 09:14:32PM -0300, Jamie Thain via NANOG wrote:
Kevin
Code is expensive.
Code is cheap; maintenance is expensive. Assertions regarding TCO based on no experience nor testing is farcical.
I want a sense of anything is wrong first.
Frankly, I don't believe you. You've been repeatedly told the many ways this is broken and are arguing instead of listening. I also think you've actively ignored the success of IPv6-mostly enterprise deployments relying on DHCP option 108. That's a good example of vendor adoption of protocol changes. Cheers, Joe -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling
I would like to propose IPw16. IPw16 consists of two IPv8's attached at a single crankshaft, with 4 turbochargers. Basically it is Internet routing, but with a Bugatti instead of a Cisco. It is much more expensive, but when filled with modern high-density HAMR platter storage, IPw16 is significantly cheaper per packet and faster than the current Internet over significant distances.* I will submit RFCs to the IETF covering this standard, and its ability to interoperate with RFC2549 utilizing higher capacity avian carriers such as condors for oceanic routing, either never, or depending on my mood next April 1st. It may be a stupid standard but it's better than IPv8. Andrew *cost effectiveness numbers are from before the Iran war, your mileage may vary. Void where prohibited by speed limit. Again I ask, with decreasing cordiality as this stupidity seems to be unending. Would it be in any way possible for this thread to die now? On Sun, May 3, 2026 at 2:15 PM Joe Provo via NANOG <nanog@lists.nanog.org> wrote:
On Sat, May 02, 2026 at 09:14:32PM -0300, Jamie Thain via NANOG wrote:
Kevin
Code is expensive.
Code is cheap; maintenance is expensive. Assertions regarding TCO based on no experience nor testing is farcical.
I want a sense of anything is wrong first.
Frankly, I don't believe you. You've been repeatedly told the many ways this is broken and are arguing instead of listening.
I also think you've actively ignored the success of IPv6-mostly enterprise deployments relying on DHCP option 108. That's a good example of vendor adoption of protocol changes.
Cheers,
Joe
-- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q624G6CX...
Saron That's a great question They'll stay on ipv4 with a firewall or gateway that has xlate8 on it. It sees www.myipv8.com card 10.10.50.10 zs inside add 10.10.50.253 Zs outside 2203.12.34.50.2 /30 12345.12.34.56.78 as www.myipv8.com 1. Ipv4 queries zs addrbyname 2. Dbs returns a8 12345.12.34.56.78 3. Xlate8 knows it came from an ipv4 client 4. Xlate pushes the rule into mftables ipv4 to ipv8 src ---------- dst xlate ---src - dest 10.10.50.10 -- 10.10.50.254 xlate 2203.12.34.50.2 -- 12345.12.34.56.78 No encapsulation needed. If it crosses a boundary that exits ipv4 then that ipv8 router does an 8over4 and forwards it. Ipv8 is ipv4 v2 You never have to upgrade an IPv4 client to operate in an IPv8 environment Jamie Ipv8 is ipv4 v2. On Sat., May 2, 2026, 7:31 p.m. , <sronan@ronan-online.com> wrote:
And how will you update the myriad of operating systems and embedded devices which haven’t received updates in years but are still running inside enterprises?
On May 2, 2026, at 6:43 PM, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Marco,
Here's how I see it going.
1. The OS upgrade is transparent. 2. The firewalls at the edge upgrade and IPv8 zone features. 3. The 10.x can now be split and operated by area. 4. People turn that on, and Zone Server to interoperate better inside regardless of the Internet status. 5. Internally it becomes part of the OS. 6. Even just implementing a Zone Server, and let people manage 10.x by area will be a great option.
Jamie
On Sat, May 2, 2026 at 10:08 AM Marco Moock via NANOG < nanog@lists.nanog.org> wrote:
Am 02.05.26 um 14:56 schrieb Jamie Thain via NANOG: And what isn't backwards compatible if you know of something. I'm all ears.
Your proposal isn't too, as there is nothing that can be backwards compatible regarding IPv4-only nodes in an IPv4-only environment with admins who do not want any change.
-- Gruß Marco Muell und Spam bitte an abfalleimer2000@stinkedores.dorfdsl.de [abfalleimer2000@stinkedores.dorfdsl.de] _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/VKXJGPM2V5GFQ4I6EYJETEEQKIP32D4G/ [ https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VKXJGPM2... ]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EFFNMZI2...
From host a to host b in the ipv8 world host b ipv8 address is 0-192.168.2.3 and in a network 65535 is on a different segment. Local segments cannot share the same ip address. Host b looks like the DNS address of host a Xlate8 makes a translate rule to the destination is the zone server, the source is the card and makes a new rule where the destination is the IPv8 interface of the zone server and the destination is the IPv8 192.168.2.3 192.168.2.3 send the IP address of the zone server which gets translated to the IP address of the IPv8 and it has the source address of the zone server and IPv8 so it sends packets back to that and then back to 192168.2.3 Now barring that every IPv8 network gives a DHCP name to every interface, and learns a c name by the LLDP name and if the device also wants to propagate some kind of name like the web server then you can put it in the LLDP name and it will capture it or you can configure a c name to that IP address. Jamie On Sun., May 3, 2026, 5:05 a.m. Owen DeLong, <owen@delong.com> wrote:
Host A is at address 65534:192.168.2.3 Host B is at address 192.168.2.3
How, exactly, do you think these two hosts magically exchange packets?
Host B has no IPv8 stack and no ability to produce an IPv8 packet with the extra 32 octets. Host A must be 100% backwards compatible to live up to your claims.
Yes, I realize my example involves a private ASN and a public address. Substitute overlapping public addresses if you prefer, the point remains.
Owen
On May 2, 2026, at 05:56, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Mikael
And what isn't backwards compatible if you know of something. I'm all ears.
Jamie
On Sat., May 2, 2026, 6:18 a.m. Mikael Abrahamsson, <swmike@swm.pp.se> wrote:
On Sat, 2 May 2026, Jamie Thain wrote:
Ipv10 Was A dual stack idea.
Everything that isn't IPv4 will be a new stack. This was realised already in the 90s, and that's why we have IPv6 that's now close to 30 years into its deployment. Adding another stack in the mix won't help.
If you would have done what you're doing back in mid 90s, it might have helped. You're 3 decades too late.
Again since you can't do the analysis steps then just send me a tape recording.
There is nothing to analyze. You're proposing something that isn't backwards compatible, and you don't seem to understand this is what you're proposing. Same as IPv10 guy.
So start implementing, you might understand it then.
-- Mikael Abrahamsson email: swmike@swm.pp.se
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Z4YOGRDC...
So all rules are dynamic (where can they go wrong) and you not only require all hosts to be In DNS but you also require LLDP to be turned on? You are overcomplicating everything. Shane
On May 3, 2026, at 6:05 PM, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
From host a to host b in the ipv8 world host b ipv8 address is
0-192.168.2.3 and in a network 65535 is on a different segment.
Local segments cannot share the same ip address.
Host b looks like the DNS address of host a Xlate8 makes a translate rule to the destination is the zone server, the source is the card and makes a new rule where the destination is the IPv8 interface of the zone server and the destination is the IPv8 192.168.2.3
192.168.2.3 send the IP address of the zone server which gets translated to the IP address of the IPv8 and it has the source address of the zone server and IPv8 so it sends packets back to that and then back to 192168.2.3
Now barring that every IPv8 network gives a DHCP name to every interface, and learns a c name by the LLDP name and if the device also wants to propagate some kind of name like the web server then you can put it in the LLDP name and it will capture it or you can configure a c name to that IP address.
Jamie
On Sun., May 3, 2026, 5:05 a.m. Owen DeLong, <owen@delong.com> wrote:
Host A is at address 65534:192.168.2.3 Host B is at address 192.168.2.3
How, exactly, do you think these two hosts magically exchange packets?
Host B has no IPv8 stack and no ability to produce an IPv8 packet with the extra 32 octets. Host A must be 100% backwards compatible to live up to your claims.
Yes, I realize my example involves a private ASN and a public address. Substitute overlapping public addresses if you prefer, the point remains.
Owen
On May 2, 2026, at 05:56, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Mikael
And what isn't backwards compatible if you know of something. I'm all ears.
Jamie
On Sat., May 2, 2026, 6:18 a.m. Mikael Abrahamsson, <swmike@swm.pp.se> wrote:
On Sat, 2 May 2026, Jamie Thain wrote:
Ipv10 Was A dual stack idea.
Everything that isn't IPv4 will be a new stack. This was realised already in the 90s, and that's why we have IPv6 that's now close to 30 years into its deployment. Adding another stack in the mix won't help.
If you would have done what you're doing back in mid 90s, it might have helped. You're 3 decades too late.
Again since you can't do the analysis steps then just send me a tape recording.
There is nothing to analyze. You're proposing something that isn't backwards compatible, and you don't seem to understand this is what you're proposing. Same as IPv10 guy.
So start implementing, you might understand it then.
-- Mikael Abrahamsson email: swmike@swm.pp.se
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Z4YOGRDC...
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/UMJJIVVS...
Andrew Very good points, no one outside of tech cares, ipv4, ipv6 ipv8. It's just about money. So where are we right now. We're on two protocols, superscalars have super pain because there customers never left ipv4, and cell companies have all these proxies up. No company can afford not to be on ipv4 and The tco of ipv4 vs ipv6 vs ipv8 Ipv4 people don't have tech debt. It works. Ipv6 is a new network. They have to spend money to make it worth it. And that is political suicide. Ipv8 is an inplace update. Probably a 10-15m code write and a 50m test. For each platform. Call it 100m We have linux, bsd, windows, the router vendors 6-10 variants that are not linux. 1B$ maybe. And here is the question i asked myself. When will ipv4 migration be over. And like the other fellow pointed out you've got ipv4 controllers on old things, and literally ipv4 is not now and not in my kids lifetime going away. So it was time to fix it. Oauth / jwt is an update to how to configure users. Users are not permission by vlans. So give them an ip address and config them using identity. Instead of ZNT think of as Role based token based authentication. Here is a question how much has been spent today because ipv6 is not compatible with ipv4? How much more is going to be spent to convert the rest of the world to ipv6? And what does it cost to do ipv8. I'll concede the effort across the industry once there is a Linux is likely low billions where i think the answer for ipv6 is low 100s of billions and you'll still have ipv4 somewhere Thanks for the great questions I hope I've answered them with clarity and understanding. Jamie On Sun., May 3, 2026, 5:33 a.m. andrew--- via NANOG, <nanog@lists.nanog.org> wrote:
Jamie,
Something I don't think you understand is that no enterprise cares if they are using IPv4. They just care that their network works. They aren't religiously attracted to IPv4. If IPv6 saves them money they will switch.
Currently they probably have an IPv4 only network. In 2026 that's technical debt, but the business can decide when it makes sense to them to clear up that technical debt. They probably don't have routers old enough to not support IPv6 at this point, and if they do, they can roll IPv6 deployment into their router upgrades which are also overdue.
As long as they carry that technical debt, they will also be carrying the real costs of running an IPv4-only network: - Leasing / owning IPv4 blocks - Leasing IPv4s for cloud resources - Engineering time dealing with issues related to doing NAT across business domains - Engineering time dealing with issues related to IPs not being unique (i.e. re-used 10/8 space) So, how much is the enterprise spending dealing with these issues?
Rolling out dual stack (not even IPv6-only!) means internal resources are directly addressable and NAT becomes something you only do for your internet-bound v4-only traffic (where you don't really care if every location uses the same 192.168.1.0/24, it's just for internet access), not within the corporate network. No need to build a new stack, no need to have a ton of translators everywhere, no need to replace every single NIC.
Rolling out IPv6-only (i.e. 464xlat, or dns64) means you get to completely remove the engineering time you are spending dealing with IPv4-related issues, not just minimize it.
I'm not sure what issues you think you are solving with all the other junk you've thrown into the protocol (DHCP granting everything, OAuth, ..) but those are also very solved issues in enterprise networks that don't involve replacing hardware with validated firmware. IP addresses are not proof of identity, not in enterprise networks, not anywhere, they are a routing location of where a client is logically located within the network. Treating them as a proof of identity is a failure of your security implementation, not a fault in the protocol. This goes for both IPV4 and IPV6.
Andrew _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CMEHMHQ7...
Andrew, I am certainly happy to see IPv6 traffic continue to rise (in absolute terms, and as a percentage of total Internet Traffic). However, I believe the long tail won't disappear within 10 years. As we get to that tail, it's going to be long. That includes the traffic we see on the Internet, and the large traffic flows occurring inside hidden and underlying networks which aren't visible when looking at Internet traffic levels. As for IPv8, ignoring the merits of the technical proposal or the ability to make it work in a real-world scenario - having to contend with IPv6 enablement while also implementing and deploying yet a new protocol / environment will likely add contention to an already full stack of work most enerprises have. regards, Victor K On Fri, May 1, 2026 at 11:19 PM Andrew Kirch via NANOG < nanog@lists.nanog.org> wrote:
If no corporation is migrating then why is IPv6 traffic continuing to increase?
As I pointed out, IPv6 traffic increased 5% last year. At that admittedly slow rate, the entire internet will be IPv6 in 10 years.
Further your assertion that business is the prime mover is incorrect. Business will move when they have to. That time is coming.
When businesses can’t get IPv4 from their providers or superscaler, or a vendor or client can’t reach them, they will move.
Andrew
On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Andrew,
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4.
And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years.
Jamie
On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < nanog@lists.nanog.org> wrote:
I oppose this. With IPv6 traffic now representing around half of internet traffic, the time to rethink has long passed.
If IPv8 was going to be a solution, it should have been a solution 10 years ago.
In the last 12 months, ~5% of traffic migrated to IPv6. At that rate, IPv6 will be fully implemented by 2035. I'm not seeing a problem that needs to be solved, or a credible solution.
Andrew
On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
I joined this list because, as part of IPv8, I am creating a BGPv8. Inside BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to create better engineering results.
I also as part of CF created Sun Tzu which is the protocol that watches CF and gives you a CF score of reliability. Do I trust my partnership with you?
Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, etc, etc. That's not my discussion point. My point isn't "should I even propose IPv8" my point is what would be the best result for operators?
I believe that since IPv8 solves the duopoly problem, it will replace IPv4.
So the things to know, IPV8 is NOT a 64 bit addressing system.
It is a 32 bit routing system with a 32 bit addressing system.
A Routing Number = ASNs plus others.
8.8.8.8 would become 15169.8.8.8.8
https://www.ietf.org/archive/id/draft-thain-ipv8-02.html < https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea 3372a?u=12457652
So each ASN in the world will have 3 Billion available addresses.
There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x
I'd appreciate your thoughts on it
Jamie _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QPBOJRGH... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VPK4LEVG...
Sounds like you basically reinvented NAT64 but with extra steps and 30 years behind. On 04/05/2026 00:04, Jamie Thain via NANOG wrote:
From host a to host b in the ipv8 world host b ipv8 address is 0-192.168.2.3 and in a network 65535 is on a different segment.
Local segments cannot share the same ip address.
Host b looks like the DNS address of host a Xlate8 makes a translate rule to the destination is the zone server, the source is the card and makes a new rule where the destination is the IPv8 interface of the zone server and the destination is the IPv8 192.168.2.3
192.168.2.3 send the IP address of the zone server which gets translated to the IP address of the IPv8 and it has the source address of the zone server and IPv8 so it sends packets back to that and then back to 192168.2.3
Now barring that every IPv8 network gives a DHCP name to every interface, and learns a c name by the LLDP name and if the device also wants to propagate some kind of name like the web server then you can put it in the LLDP name and it will capture it or you can configure a c name to that IP address.
Jamie
On Sun., May 3, 2026, 5:05 a.m. Owen DeLong, <owen@delong.com> wrote:
Host A is at address 65534:192.168.2.3 Host B is at address 192.168.2.3
How, exactly, do you think these two hosts magically exchange packets?
Host B has no IPv8 stack and no ability to produce an IPv8 packet with the extra 32 octets. Host A must be 100% backwards compatible to live up to your claims.
Yes, I realize my example involves a private ASN and a public address. Substitute overlapping public addresses if you prefer, the point remains.
Owen
On May 2, 2026, at 05:56, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote: Mikael
And what isn't backwards compatible if you know of something. I'm all ears. Jamie
On Sat., May 2, 2026, 6:18 a.m. Mikael Abrahamsson, <swmike@swm.pp.se> wrote:
On Sat, 2 May 2026, Jamie Thain wrote:
Ipv10 Was A dual stack idea. Everything that isn't IPv4 will be a new stack. This was realised already in the 90s, and that's why we have IPv6 that's now close to 30 years into its deployment. Adding another stack in the mix won't help.
If you would have done what you're doing back in mid 90s, it might have helped. You're 3 decades too late.
Again since you can't do the analysis steps then just send me a tape recording. There is nothing to analyze. You're proposing something that isn't backwards compatible, and you don't seem to understand this is what you're proposing. Same as IPv10 guy.
So start implementing, you might understand it then.
-- Mikael Abrahamsson email: swmike@swm.pp.se
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Z4YOGRDC...
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/UMJJIVVS...
Shrihari, See every 10 or 11 emails you get one that is at least an argument. Ipv8 is an area code based system, and the area codes. When an ipv8 packet arrives at your edge there are only 2 conditions. The route is destined for you or it's passing thru, and then there are only 2 cases you have ipv8 silicon or you don't. Ok if it's passing thru no v8 silicon xlate8 looks up it's asnV4 encapsulates it and sends via v4 to that destination. Ok if it's not passing thru and this is the destination then you have two route tables to be concerned with. Asn 0 and asn my asn say 1234 There are 2 vrfs created on ipv8 configs ip vrf ipv8-asn-1234 rd 1234:65535 ip vrf ipv4-asn-0 rd 0:65535 So as routes the ipv8 is loaded into 2 different lfibs in the silicon and managed by the ipv4 silicon. You create the ipv8 overlay by putting it in a vrf until ipv8 silicon is naturally updated. Then for the main show ipv8 route it looks in bgp statement include ip vrf ipv8-asn-1234 as asn 1234 Include ip vrf ipv4-asn-0 as ipv4 And shows these routes There is no new silicon required. From a silicon level "IPv8 is an L3VPN with a globally reserved RD. If your router does L3VPN today — and every SP router does — your router does IPv8 today" HTH Jamie On Sun., May 3, 2026, 10:56 a.m. Shrihari Pandit, <spandit@stealth.net> wrote:
Hi Jamine,
We had internal discussions with our team and are ones that are experienced in economics (wide range of fields, and engineering including CMOS, FPGA, ACIS.)
1. This is what I was told. IPv8 requires two additional lookups. It results in:
- wider parser support - new match/action pipeline design - more TCAM/SRAM slices - larger die area - higher power draw - lower port density - new board designs - new optics/thermal validation - new NOS/SDK support - more heat as result of higher power draw
2. Cost areas:
- New ASIC / merchant silicon design - Router/switch platform redesign - Carrier backbone + edge replacement - Hyperscaler/data-center network - Enterprise/CPE/firewall/load-balancer "refresh" - Software, OSS/BSS, routing stacks, monitoring systems - Testing, certification, migration labour - Operational risk, outages, dual-stack complexity
The approximate numbers to implement are between $500B up to $2T (more realistic number @ $740B)
Cisco describes routing silicon release cycles in the 18–36 month range, which means this is not software patches: src: https://www.cisco.com/c/dam/m/digital/elq-cmcglobal/witb/CKN/0721_CROSS.pdf
So IPv8 is control-plane cheap and data-plane expensive. The draft needs to account for that. Maybe Trump can allocate $2T to create more jobs, more work. You will need to likely reach out to the NSC. It will take 30 years. If there is forcing event, maybe 10-15 years and that would require the gov to pay all carriers and end-users.
We should stop the discussion here; You should contact the merchant silicon companies to find out the costs and whether two additional lookups are required and are at what costs (actual costs, power draw, heat, etc.)
--- Shrihari 212-232-2025
On Sat, May 2, 2026 at 7:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Kevin
Code is expensive. I want a sense of anything is wrong first.
Dns server needs 10 lines of code. Dhcp server 0, ntp server 100, netlog 1000,
So far mostly people have told me to go F myself.
But it's the economics will win.
Tco = 0
If ipv is compatible If protocol = ipv8 Tco = education + dev time of tools once on all 4 varaint os's + any premiium - (integration savings) - 100,000s per mid size enterprise per year.
Think -100 000 per 1000 employees or so
If protocol = ipv6 Tco = interoperability testing + education + i get my ass fired for using it.
Tco for ipv8 - billions
Tco for ipv6 + billions
On Sat., May 2, 2026, 5:56 p.m. Kevin Tillery via NANOG, < nanog@lists.nanog.org> wrote:
Code is extremely malleable. You are not building a lunar lander. It will not explode, kill three people and humiliate a nation if you get it wrong. You will just observe that it is wrong and change it until it is right.
This gives you plentiful opportunities to discover things for yourself instead of spamming this mailing list with stupid arguments.
For example, if you actually write an IPv8 implementation, you can try connecting it to an IPv4 implementation. You will discover whether it actually works or not. This is infinitely more valuable than an argument.
Justin,
Because before you write a line of code you have to get it right, or near right.
If you want to see good engineering watch from the "Earth to the Moon" Spider, how they built the lunar lander.
So far I've had like 3 serious conversations about "this won't work" and each one has had me improve it. But "go make code" before we discuss what and how it should be, a DRAFT is actually when you want comments about the operation of it all.
I'm not going to wait until I written 1m worth of code to figure something is wrong.
IETF folks suggested to me, that I join Nanog to see how they might use it. IPv8 is not about address space.
Jamie
On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG <nanog@lists.nanog.org> wrote:
I know of enterprises who are deploying v6.
Until you can show the world a working IPv8 implementation on a large using off-the-shelf components where people can run through failure scenarios and really beat it up, not many people are going to take it seriously.
Lower layers of the network relying on the functionality of higher layers is a really, really, really bad idea.
While it's always important to think about how to so something better, v8 seems to create a whole bunch of new problems while not solving many
have already been addressed in v6 and other protocols.
Thank you jms
On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Andrew,
Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 in a meeting and two corp engineers laughed.
You can google it yourself.
Jamie
On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
> If no corporation is migrating then why is IPv6 traffic continuing to > increase? > > As I pointed out, IPv6 traffic increased 5% last year. At that admittedly > slow rate, the entire internet will be IPv6 in 10 years. > > Further your assertion that business is the prime mover is incorrect. > Business will move when they have to. That time is coming. > > When businesses can’t get IPv4 from their providers or superscaler, or a > vendor or client can’t reach them, they will move. > > Andrew > > > > On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < > nanog@lists.nanog.org [nanog@lists.nanog.org]> > wrote: > > > Andrew, > > > > The issue is for corporate and the cloud, IPv6 is just as broken as IPv4. > > > > And no corporate is migrating go look. Its been the next big
> > Corporate networks for 20 years. > > > > Jamie > > > > On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < > > nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote: > > > > > I oppose this. With IPv6 traffic now representing around half of > > internet > > > traffic, the time to rethink has long passed. > > > > > > If IPv8 was going to be a solution, it should have been a solution 10 > > years > > > ago. > > > > > > In the last 12 months, ~5% of traffic migrated to IPv6. At
rate, > > IPv6 > > > will be fully implemented by 2035. I'm not seeing a problem
needs > > to > > > be solved, or a credible solution. > > > > > > Andrew > > > > > > > > > > > > On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < > > > nanog@lists.nanog.org [nanog@lists.nanog.org]> > > > wrote: > > > > > > > Hi All, > > > > > > > > My name is Jamie Thain I'm the creator of IPv8. It's not a hoax. > > > > > > > > I joined this list because, as part of IPv8, I am creating a BGPv8. > > > Inside > > > > BGPv8, two new protocols CF (Cost Factor), weigh cost factors along > the > > > > routes to produce a better metric. It's a hybrid of EIRGP mixed with > > BGP > > > to > > > > create better engineering results. > > > > > > > > I also as part of CF created Sun Tzu which is the protocol
> watches > > > CF > > > > and gives you a CF score of reliability. Do I trust my
On 2 May 2026 20:05:47 CEST, Jamie Thain via NANOG < nanog@lists.nanog.org> wrote: that thing in that that that partnership
> > with > > > > you? > > > > > > > > Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every > problem, > > > > etc, etc. That's not my discussion point. My point isn't "should I > even > > > > propose IPv8" my point is what would be the best result for > operators? > > > > > > > > I believe that since IPv8 solves the duopoly problem, it will replace > > > > IPv4. > > > > > > > > So the things to know, IPV8 is NOT a 64 bit addressing system. > > > > > > > > It is a 32 bit routing system with a 32 bit addressing system. > > > > > > > > A Routing Number = ASNs plus others. > > > > > > > > 8.8.8.8 would become 15169.8.8.8.8 > > > > > > > > https://www.ietf.org/archive/id/draft-thain-ipv8-02.html [https://www.ietf.org/archive/id/draft-thain-ipv8-02.html] > > > > < > > > > https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea [https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea] > > > 3372a?u=12457652 > > > > > > > > > > > > > > > > > So each ASN in the world will have 3 Billion available addresses. > > > > > > > > There is a specially reserved group of internal ASN 127.x.x.x so each > > > corp, > > > > org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x > > and > > > > 100.64.x.x.x > > > > > > > > I'd appreciate your thoughts on it > > > > > > > > Jamie > > > > _______________________________________________ > > > > NANOG mailing list > > > > > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > > message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/ > > > > > > > _______________________________________________ > > > NANOG mailing list > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > > message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/ > > _______________________________________________ > > NANOG mailing list > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/ > _______________________________________________ > NANOG mailing list > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/ [
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA...
]
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/ [
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2MY7QMH6...
]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JTNFIASL...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QWWTJWVN... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DTITZNUE...
Shrihari So go back to your team and ask this. So the ipv8 routes go in seperate vrfs for the ones you want to track. Usually 1. VPN-IPv4 NLRI gives you 64 bits of address space when you count the RD (8-byte RD + 4-byte prefix). If IPv8 is using RD=ASN:65535 plus a 32-bit field, you have effectively a 32-bit address space scoped to that RD. The RD itself has to participate in the addressing — different RD values become different IPv8 zones or aggregates. Jt On Sun., May 3, 2026, 10:56 a.m. Shrihari Pandit, <spandit@stealth.net> wrote:
Hi Jamine,
We had internal discussions with our team and are ones that are experienced in economics (wide range of fields, and engineering including CMOS, FPGA, ACIS.)
1. This is what I was told. IPv8 requires two additional lookups. It results in:
- wider parser support - new match/action pipeline design - more TCAM/SRAM slices - larger die area - higher power draw - lower port density - new board designs - new optics/thermal validation - new NOS/SDK support - more heat as result of higher power draw
2. Cost areas:
- New ASIC / merchant silicon design - Router/switch platform redesign - Carrier backbone + edge replacement - Hyperscaler/data-center network - Enterprise/CPE/firewall/load-balancer "refresh" - Software, OSS/BSS, routing stacks, monitoring systems - Testing, certification, migration labour - Operational risk, outages, dual-stack complexity
The approximate numbers to implement are between $500B up to $2T (more realistic number @ $740B)
Cisco describes routing silicon release cycles in the 18–36 month range, which means this is not software patches: src: https://www.cisco.com/c/dam/m/digital/elq-cmcglobal/witb/CKN/0721_CROSS.pdf
So IPv8 is control-plane cheap and data-plane expensive. The draft needs to account for that. Maybe Trump can allocate $2T to create more jobs, more work. You will need to likely reach out to the NSC. It will take 30 years. If there is forcing event, maybe 10-15 years and that would require the gov to pay all carriers and end-users.
We should stop the discussion here; You should contact the merchant silicon companies to find out the costs and whether two additional lookups are required and are at what costs (actual costs, power draw, heat, etc.)
--- Shrihari 212-232-2025
On Sat, May 2, 2026 at 7:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Kevin
Code is expensive. I want a sense of anything is wrong first.
Dns server needs 10 lines of code. Dhcp server 0, ntp server 100, netlog 1000,
So far mostly people have told me to go F myself.
But it's the economics will win.
Tco = 0
If ipv is compatible If protocol = ipv8 Tco = education + dev time of tools once on all 4 varaint os's + any premiium - (integration savings) - 100,000s per mid size enterprise per year.
Think -100 000 per 1000 employees or so
If protocol = ipv6 Tco = interoperability testing + education + i get my ass fired for using it.
Tco for ipv8 - billions
Tco for ipv6 + billions
On Sat., May 2, 2026, 5:56 p.m. Kevin Tillery via NANOG, < nanog@lists.nanog.org> wrote:
Code is extremely malleable. You are not building a lunar lander. It will not explode, kill three people and humiliate a nation if you get it wrong. You will just observe that it is wrong and change it until it is right.
This gives you plentiful opportunities to discover things for yourself instead of spamming this mailing list with stupid arguments.
For example, if you actually write an IPv8 implementation, you can try connecting it to an IPv4 implementation. You will discover whether it actually works or not. This is infinitely more valuable than an argument.
Justin,
Because before you write a line of code you have to get it right, or near right.
If you want to see good engineering watch from the "Earth to the Moon" Spider, how they built the lunar lander.
So far I've had like 3 serious conversations about "this won't work" and each one has had me improve it. But "go make code" before we discuss what and how it should be, a DRAFT is actually when you want comments about the operation of it all.
I'm not going to wait until I written 1m worth of code to figure something is wrong.
IETF folks suggested to me, that I join Nanog to see how they might use it. IPv8 is not about address space.
Jamie
On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG <nanog@lists.nanog.org> wrote:
I know of enterprises who are deploying v6.
Until you can show the world a working IPv8 implementation on a large using off-the-shelf components where people can run through failure scenarios and really beat it up, not many people are going to take it seriously.
Lower layers of the network relying on the functionality of higher layers is a really, really, really bad idea.
While it's always important to think about how to so something better, v8 seems to create a whole bunch of new problems while not solving many
have already been addressed in v6 and other protocols.
Thank you jms
On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Andrew,
Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 in a meeting and two corp engineers laughed.
You can google it yourself.
Jamie
On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
> If no corporation is migrating then why is IPv6 traffic continuing to > increase? > > As I pointed out, IPv6 traffic increased 5% last year. At that admittedly > slow rate, the entire internet will be IPv6 in 10 years. > > Further your assertion that business is the prime mover is incorrect. > Business will move when they have to. That time is coming. > > When businesses can’t get IPv4 from their providers or superscaler, or a > vendor or client can’t reach them, they will move. > > Andrew > > > > On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < > nanog@lists.nanog.org [nanog@lists.nanog.org]> > wrote: > > > Andrew, > > > > The issue is for corporate and the cloud, IPv6 is just as broken as IPv4. > > > > And no corporate is migrating go look. Its been the next big
> > Corporate networks for 20 years. > > > > Jamie > > > > On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < > > nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote: > > > > > I oppose this. With IPv6 traffic now representing around half of > > internet > > > traffic, the time to rethink has long passed. > > > > > > If IPv8 was going to be a solution, it should have been a solution 10 > > years > > > ago. > > > > > > In the last 12 months, ~5% of traffic migrated to IPv6. At
rate, > > IPv6 > > > will be fully implemented by 2035. I'm not seeing a problem
needs > > to > > > be solved, or a credible solution. > > > > > > Andrew > > > > > > > > > > > > On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < > > > nanog@lists.nanog.org [nanog@lists.nanog.org]> > > > wrote: > > > > > > > Hi All, > > > > > > > > My name is Jamie Thain I'm the creator of IPv8. It's not a hoax. > > > > > > > > I joined this list because, as part of IPv8, I am creating a BGPv8. > > > Inside > > > > BGPv8, two new protocols CF (Cost Factor), weigh cost factors along > the > > > > routes to produce a better metric. It's a hybrid of EIRGP mixed with > > BGP > > > to > > > > create better engineering results. > > > > > > > > I also as part of CF created Sun Tzu which is the protocol
> watches > > > CF > > > > and gives you a CF score of reliability. Do I trust my
On 2 May 2026 20:05:47 CEST, Jamie Thain via NANOG < nanog@lists.nanog.org> wrote: that thing in that that that partnership
> > with > > > > you? > > > > > > > > Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every > problem, > > > > etc, etc. That's not my discussion point. My point isn't "should I > even > > > > propose IPv8" my point is what would be the best result for > operators? > > > > > > > > I believe that since IPv8 solves the duopoly problem, it will replace > > > > IPv4. > > > > > > > > So the things to know, IPV8 is NOT a 64 bit addressing system. > > > > > > > > It is a 32 bit routing system with a 32 bit addressing system. > > > > > > > > A Routing Number = ASNs plus others. > > > > > > > > 8.8.8.8 would become 15169.8.8.8.8 > > > > > > > > https://www.ietf.org/archive/id/draft-thain-ipv8-02.html [https://www.ietf.org/archive/id/draft-thain-ipv8-02.html] > > > > < > > > > https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea [https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea] > > > 3372a?u=12457652 > > > > > > > > > > > > > > > > > So each ASN in the world will have 3 Billion available addresses. > > > > > > > > There is a specially reserved group of internal ASN 127.x.x.x so each > > > corp, > > > > org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x > > and > > > > 100.64.x.x.x > > > > > > > > I'd appreciate your thoughts on it > > > > > > > > Jamie > > > > _______________________________________________ > > > > NANOG mailing list > > > > > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > > message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/ > > > > > > > _______________________________________________ > > > NANOG mailing list > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > > message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/ > > _______________________________________________ > > NANOG mailing list > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/ > _______________________________________________ > NANOG mailing list > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/ [
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA...
]
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/ [
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2MY7QMH6...
]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JTNFIASL...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QWWTJWVN... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DTITZNUE...
nanog@lists.nanog.org (Kevin Tillery via NANOG) wrote:
Sounds like you basically reinvented NAT64 but with extra steps and 30 years behind.
You forgot the real driver behind "v8": Having control over each and every endpoint from a central MCP. The wet dream of so many people with deep pockets.
Joe I've been told no ways that it's broken. This phase is about as serious as people telling me I'm wrong. So far about 21 days ago someone told me it was silicon. So i worked that one out. Put the ipv8 asns your responsible for in VRFs. Other than that I've faced a lot of "im an idiot" but no ipv8 doesn't work because... It's usually an argument from authority, ipv8 doesn't work because i say so, rather than an argument from fact. Ipv8 will gain a new afi type but it can ride in MP-BGP VPN-IPv4 for a long while. Jamie On Sun., May 3, 2026, 2:15 p.m. Joe Provo via NANOG, <nanog@lists.nanog.org> wrote:
On Sat, May 02, 2026 at 09:14:32PM -0300, Jamie Thain via NANOG wrote:
Kevin
Code is expensive.
Code is cheap; maintenance is expensive. Assertions regarding TCO based on no experience nor testing is farcical.
I want a sense of anything is wrong first.
Frankly, I don't believe you. You've been repeatedly told the many ways this is broken and are arguing instead of listening.
I also think you've actively ignored the success of IPv6-mostly enterprise deployments relying on DHCP option 108. That's a good example of vendor adoption of protocol changes.
Cheers,
Joe
-- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q624G6CX...
Marco And ipv6 is no where on there radar. So fix ipv4. I appreciate your input. Jamie On Sun., May 3, 2026, 4:33 a.m. Marco Moock via NANOG, < nanog@lists.nanog.org> wrote:
Am 03.05.26 um 00:30 schrieb Jamie Thain via NANOG:
* IPv6 wasn't a surgical fix for address exhaustion — it bundled the address-space change with a full redesign of neighbor discovery, autoconfiguration, header structure, and operational tooling.
That wasn't the issue. The issue is that it takes some time to prepare and do the implementation of another network protocol, regardless how it is called or how it works in detail. No one cares about ARP, nor NDP. It is there and works.
Corporate networks need address plan, firewall plans etc. and that needs to be extended if any new protocol is going to be implemented.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LZX6VCZU...
Marco Ipv8 is just ipv4 v2 it's not even trying to switch off ipv4 they are pals. Ipv4 fixes super scalar architecture and does it as a software upgrade. Ipv4, v6 and v8 are not religions they are protocols and the most cost effective will win. Ipv8 solves one of the biggest problems corps have access to resources. It has znt built in Jamie On Sun., May 3, 2026, 4:34 a.m. Marco Moock via NANOG, < nanog@lists.nanog.org> wrote:
Am 03.05.26 um 00:21 schrieb Jamie Thain via NANOG:
And that's the story of why IPv8. Because its really IPv4 V2 its an inplace upgrade of what we have. The minimal world is
It isn't as both sides of the communication partner need to implement it in a way, so same situation as IPv6 - if one site does not want to do anything, you cannot completely switch of old IPv4.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/C2TN4QAB...
Am 04.05.26 um 08:26 schrieb Jamie Thain:
And ipv6 is no where on there radar.
It seems you live behind the moon. More and more IPv6 traffic is being measured. So fix ipv4. You cannot without incompatible changes. Many people told you. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Jamie, "No new silicon required”, that’s only true because IPv8 is not being forwarded natively. Your actual process is: 1. Packets are encapsulated into IPv4 2. Lookup happens on IPv4 3. IPv8 is resolved via control-plane indirection 4. So the real system is IPv8 to mapping to IPv4 to forwarding. Which means: - extra lookup (mapping) - extra state (VRFs / LFIBs) - extra encapsulation - extra operational complexity IPv8 shifted into the control plane. It reminds me of the original ARPANET days, CPU based routing. If we go down this path, the control planes might all require something like AMD EPYC 9965 (192 cores fyi.) due to PPS rate. In reference to "loaded into 2 different LFIBs in the silicon". If I understand what you saying: A. Each “IPv8 area/ASN construct” = VRF B. Each mapping = BGP state C. Each path = label / adjacency These issues still exist, because IPv8 indirectly consumes it: - TCAM is still consumed (VRF separation not free) - LFIB size grows - BGP table complexity increases - convergence becomes harder Further, your statement of "if it's passing thru no v8 silicon...." implies that every transit node must do: [perform classification, apply mapping logic, encapsulate]. That's additional pipeline work. Shrihari Pandit Stealth Communications +1-212-232-2025 On Mon, May 4, 2026 at 1:04 AM Jamie Thain <jamie@one.bm> wrote:
Shrihari,
See every 10 or 11 emails you get one that is at least an argument.
Ipv8 is an area code based system, and the area codes.
When an ipv8 packet arrives at your edge there are only 2 conditions.
The route is destined for you or it's passing thru, and then there are only 2 cases you have ipv8 silicon or you don't.
Ok if it's passing thru no v8 silicon xlate8 looks up it's asnV4 encapsulates it and sends via v4 to that destination.
Ok if it's not passing thru and this is the destination then you have two route tables to be concerned with. Asn 0 and asn my asn say 1234
There are 2 vrfs created on ipv8 configs
ip vrf ipv8-asn-1234 rd 1234:65535
ip vrf ipv4-asn-0 rd 0:65535
So as routes the ipv8 is loaded into 2 different lfibs in the silicon and managed by the ipv4 silicon.
You create the ipv8 overlay by putting it in a vrf until ipv8 silicon is naturally updated.
Then for the main show ipv8 route it looks in bgp statement
include ip vrf ipv8-asn-1234 as asn 1234 Include ip vrf ipv4-asn-0 as ipv4
And shows these routes
There is no new silicon required. From a silicon level "IPv8 is an L3VPN with a globally reserved RD. If your router does L3VPN today — and every SP router does — your router does IPv8 today"
HTH
Jamie
On Sun., May 3, 2026, 10:56 a.m. Shrihari Pandit, <spandit@stealth.net> wrote:
Hi Jamine,
We had internal discussions with our team and are ones that are experienced in economics (wide range of fields, and engineering including CMOS, FPGA, ACIS.)
1. This is what I was told. IPv8 requires two additional lookups. It results in:
- wider parser support - new match/action pipeline design - more TCAM/SRAM slices - larger die area - higher power draw - lower port density - new board designs - new optics/thermal validation - new NOS/SDK support - more heat as result of higher power draw
2. Cost areas:
- New ASIC / merchant silicon design - Router/switch platform redesign - Carrier backbone + edge replacement - Hyperscaler/data-center network - Enterprise/CPE/firewall/load-balancer "refresh" - Software, OSS/BSS, routing stacks, monitoring systems - Testing, certification, migration labour - Operational risk, outages, dual-stack complexity
The approximate numbers to implement are between $500B up to $2T (more realistic number @ $740B)
Cisco describes routing silicon release cycles in the 18–36 month range, which means this is not software patches: src: https://www.cisco.com/c/dam/m/digital/elq-cmcglobal/witb/CKN/0721_CROSS.pdf
So IPv8 is control-plane cheap and data-plane expensive. The draft needs to account for that. Maybe Trump can allocate $2T to create more jobs, more work. You will need to likely reach out to the NSC. It will take 30 years. If there is forcing event, maybe 10-15 years and that would require the gov to pay all carriers and end-users.
We should stop the discussion here; You should contact the merchant silicon companies to find out the costs and whether two additional lookups are required and are at what costs (actual costs, power draw, heat, etc.)
--- Shrihari 212-232-2025
On Sat, May 2, 2026 at 7:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Kevin
Code is expensive. I want a sense of anything is wrong first.
Dns server needs 10 lines of code. Dhcp server 0, ntp server 100, netlog 1000,
So far mostly people have told me to go F myself.
But it's the economics will win.
Tco = 0
If ipv is compatible If protocol = ipv8 Tco = education + dev time of tools once on all 4 varaint os's + any premiium - (integration savings) - 100,000s per mid size enterprise per year.
Think -100 000 per 1000 employees or so
If protocol = ipv6 Tco = interoperability testing + education + i get my ass fired for using it.
Tco for ipv8 - billions
Tco for ipv6 + billions
On Sat., May 2, 2026, 5:56 p.m. Kevin Tillery via NANOG, < nanog@lists.nanog.org> wrote:
Code is extremely malleable. You are not building a lunar lander. It will not explode, kill three people and humiliate a nation if you get it wrong. You will just observe that it is wrong and change it until it is right.
This gives you plentiful opportunities to discover things for yourself instead of spamming this mailing list with stupid arguments.
For example, if you actually write an IPv8 implementation, you can try connecting it to an IPv4 implementation. You will discover whether it actually works or not. This is infinitely more valuable than an argument.
Justin,
Because before you write a line of code you have to get it right, or near right.
If you want to see good engineering watch from the "Earth to the Moon" Spider, how they built the lunar lander.
So far I've had like 3 serious conversations about "this won't work" and each one has had me improve it. But "go make code" before we discuss what and how it should be, a DRAFT is actually when you want comments about the operation of it all.
I'm not going to wait until I written 1m worth of code to figure something is wrong.
IETF folks suggested to me, that I join Nanog to see how they might use it. IPv8 is not about address space.
Jamie
On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG <nanog@lists.nanog.org> wrote:
I know of enterprises who are deploying v6.
Until you can show the world a working IPv8 implementation on a large using off-the-shelf components where people can run through failure scenarios and really beat it up, not many people are going to take it seriously.
Lower layers of the network relying on the functionality of higher layers is a really, really, really bad idea.
While it's always important to think about how to so something better, v8 seems to create a whole bunch of new problems while not solving many
have already been addressed in v6 and other protocols.
Thank you jms
On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
> Andrew, > > Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 > in a meeting and two corp engineers laughed. > > You can google it yourself. > > Jamie > > On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < > nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote: > > > If no corporation is migrating then why is IPv6 traffic continuing to > > increase? > > > > As I pointed out, IPv6 traffic increased 5% last year. At that > admittedly > > slow rate, the entire internet will be IPv6 in 10 years. > > > > Further your assertion that business is the prime mover is incorrect. > > Business will move when they have to. That time is coming. > > > > When businesses can’t get IPv4 from their providers or superscaler, or a > > vendor or client can’t reach them, they will move. > > > > Andrew > > > > > > > > On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < > > nanog@lists.nanog.org [nanog@lists.nanog.org]> > > wrote: > > > > > Andrew, > > > > > > The issue is for corporate and the cloud, IPv6 is just as broken as > IPv4. > > > > > > And no corporate is migrating go look. Its been the next big
> > > Corporate networks for 20 years. > > > > > > Jamie > > > > > > On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < > > > nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote: > > > > > > > I oppose this. With IPv6 traffic now representing around half of > > > internet > > > > traffic, the time to rethink has long passed. > > > > > > > > If IPv8 was going to be a solution, it should have been a solution 10 > > > years > > > > ago. > > > > > > > > In the last 12 months, ~5% of traffic migrated to IPv6. At
> rate, > > > IPv6 > > > > will be fully implemented by 2035. I'm not seeing a problem
> needs > > > to > > > > be solved, or a credible solution. > > > > > > > > Andrew > > > > > > > > > > > > > > > > On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < > > > > nanog@lists.nanog.org [nanog@lists.nanog.org]> > > > > wrote: > > > > > > > > > Hi All, > > > > > > > > > > My name is Jamie Thain I'm the creator of IPv8. It's not a hoax. > > > > > > > > > > I joined this list because, as part of IPv8, I am creating a BGPv8. > > > > Inside > > > > > BGPv8, two new protocols CF (Cost Factor), weigh cost factors along > > the > > > > > routes to produce a better metric. It's a hybrid of EIRGP mixed > with > > > BGP > > > > to > > > > > create better engineering results. > > > > > > > > > > I also as part of CF created Sun Tzu which is the protocol
> > watches > > > > CF > > > > > and gives you a CF score of reliability. Do I trust my
On 2 May 2026 20:05:47 CEST, Jamie Thain via NANOG < nanog@lists.nanog.org> wrote: that thing in that that that partnership
> > > with > > > > > you? > > > > > > > > > > Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every > > problem, > > > > > etc, etc. That's not my discussion point. My point isn't "should I > > even > > > > > propose IPv8" my point is what would be the best result for > > operators? > > > > > > > > > > I believe that since IPv8 solves the duopoly problem, it will > replace > > > > > IPv4. > > > > > > > > > > So the things to know, IPV8 is NOT a 64 bit addressing system. > > > > > > > > > > It is a 32 bit routing system with a 32 bit addressing system. > > > > > > > > > > A Routing Number = ASNs plus others. > > > > > > > > > > 8.8.8.8 would become 15169.8.8.8.8 > > > > > > > > > > https://www.ietf.org/archive/id/draft-thain-ipv8-02.html [https://www.ietf.org/archive/id/draft-thain-ipv8-02.html] > > > > > < > > > > > https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea [https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea] > > > > 3372a?u=12457652 > > > > > > > > > > > > > > > > > > > > > So each ASN in the world will have 3 Billion available addresses. > > > > > > > > > > There is a specially reserved group of internal ASN 127.x.x.x so > each > > > > corp, > > > > > org, has 16 Million areas of 3 Billion addresses, to replace > 10.x.x.x > > > and > > > > > 100.64.x.x.x > > > > > > > > > > I'd appreciate your thoughts on it > > > > > > > > > > Jamie > > > > > _______________________________________________ > > > > > NANOG mailing list > > > > > > > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > > > message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/ > > > > > > > > > _______________________________________________ > > > > NANOG mailing list > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > > > message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/ > > > _______________________________________________ > > > NANOG mailing list > > > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/ > > _______________________________________________ > > NANOG mailing list > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/ > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/ [
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA...
]
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/ [
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2MY7QMH6...
]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JTNFIASL...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QWWTJWVN... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DTITZNUE...
Jamie And ipv8 is no where on there radar. So fix ipv6. I appreciate your input. Kevin On 4 May 2026 08:26:33 CEST, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Marco
And ipv6 is no where on there radar. So fix ipv4.
I appreciate your input.
Jamie
On Sun., May 3, 2026, 4:33 a.m. Marco Moock via NANOG, < nanog@lists.nanog.org> wrote:
Am 03.05.26 um 00:30 schrieb Jamie Thain via NANOG:
* IPv6 wasn't a surgical fix for address exhaustion — it bundled the address-space change with a full redesign of neighbor discovery, autoconfiguration, header structure, and operational tooling.
That wasn't the issue. The issue is that it takes some time to prepare and do the implementation of another network protocol, regardless how it is called or how it works in detail. No one cares about ARP, nor NDP. It is there and works.
Corporate networks need address plan, firewall plans etc. and that needs to be extended if any new protocol is going to be implemented.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LZX6VCZU...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AVIU5UM7...
Kevin, I can't fix ipv6 I'll leave that to people that understand the basics. No one, and i mean no one in corp (that's not a super scalar) knows anything about ipv6 and no one and i mean no one cares. They know it's on in there os and there's some mystery that some things will break if it's off. Jamie On Mon., May 4, 2026, 2:27 p.m. Kevin Tillery via NANOG, < nanog@lists.nanog.org> wrote:
Jamie
And ipv8 is no where on there radar. So fix ipv6.
I appreciate your input.
Kevin
On 4 May 2026 08:26:33 CEST, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Marco
And ipv6 is no where on there radar. So fix ipv4.
I appreciate your input.
Jamie
On Sun., May 3, 2026, 4:33 a.m. Marco Moock via NANOG, < nanog@lists.nanog.org> wrote:
Am 03.05.26 um 00:30 schrieb Jamie Thain via NANOG:
* IPv6 wasn't a surgical fix for address exhaustion — it bundled the address-space change with a full redesign of neighbor discovery, autoconfiguration, header structure, and operational tooling.
That wasn't the issue. The issue is that it takes some time to prepare and do the implementation of another network protocol, regardless how it is called or how it works in detail. No one cares about ARP, nor NDP. It is there and works.
Corporate networks need address plan, firewall plans etc. and that needs to be extended if any new protocol is going to be implemented.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LZX6VCZU... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AVIU5UM7... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MPYN6YGE...
You must not deal with very many corporations because I know many that have added v6 to their corporate networks. Think of many in the top 200 companies in the US. Shane On Mon, May 4, 2026 at 6:28 PM Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Kevin,
I can't fix ipv6 I'll leave that to people that understand the basics.
No one, and i mean no one in corp (that's not a super scalar) knows anything about ipv6 and no one and i mean no one cares.
They know it's on in there os and there's some mystery that some things will break if it's off.
Jamie
On Mon., May 4, 2026, 2:27 p.m. Kevin Tillery via NANOG, < nanog@lists.nanog.org> wrote:
Jamie
And ipv8 is no where on there radar. So fix ipv6.
I appreciate your input.
Kevin
Marco
And ipv6 is no where on there radar. So fix ipv4.
I appreciate your input.
Jamie
On Sun., May 3, 2026, 4:33 a.m. Marco Moock via NANOG, < nanog@lists.nanog.org> wrote:
Am 03.05.26 um 00:30 schrieb Jamie Thain via NANOG:
* IPv6 wasn't a surgical fix for address exhaustion — it bundled
On 4 May 2026 08:26:33 CEST, Jamie Thain via NANOG < nanog@lists.nanog.org> wrote: the
address-space change with a full redesign of neighbor discovery, autoconfiguration, header structure, and operational tooling.
That wasn't the issue. The issue is that it takes some time to prepare and do the implementation of another network protocol, regardless how it is called or how it works in detail. No one cares about ARP, nor NDP. It is there and works.
Corporate networks need address plan, firewall plans etc. and that needs to be extended if any new protocol is going to be implemented.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LZX6VCZU...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AVIU5UM7...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MPYN6YGE... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SGDZ4RYZ...
Shrihari, So the real system is IPv8 to mapping to IPv4 to forwarding. ABSOLUTELY!!! IPV8 is an are protocol Imagine a long time ago in a galaxy far far away, how area codes came to be. Each area was a core exchange. 416, Toronto, 212 New York. Once you got to the major exchange you don't need that number. In the exchange there's two type of numbers, 0 and the ASN. You have 0 the old numbers and ASN the new. On every router in the world there is a way to separate numbering systems called VRFs and l2.5 tags. Heres the complexity. ip vrf Ipv8-asn-1234 rd 1234:65535 // l2.5 label ip vrf ipv4-asn-0 rd 0:65535 // l2.5 label ipip in ip is a silicon and labels put up tunnels all the time. All silicon is optimized for this. Only pe routers will make a decision. The overhead will be measured in hundreds of lines of code and then it will be in LFIB. One level of label when modern systems are capable of 10+ levels. It's the exact same process as an mpls tags. So the complexity is equal to 2 MPLS l3vpns. Hopefully no one on your team thought that that would be very burdensome on a new router. Jamie On Mon., May 4, 2026, 9:15 a.m. Shrihari Pandit, <spandit@stealth.net> wrote:
Jamie,
"No new silicon required”, that’s only true because IPv8 is not being forwarded natively. Your actual process is: 1. Packets are encapsulated into IPv4 2. Lookup happens on IPv4 3. IPv8 is resolved via control-plane indirection 4. So the real system is IPv8 to mapping to IPv4 to forwarding.
Which means:
- extra lookup (mapping) - extra state (VRFs / LFIBs) - extra encapsulation - extra operational complexity
IPv8 shifted into the control plane. It reminds me of the original ARPANET days, CPU based routing. If we go down this path, the control planes might all require something like AMD EPYC 9965 (192 cores fyi.) due to PPS rate.
In reference to "loaded into 2 different LFIBs in the silicon". If I understand what you saying: A. Each “IPv8 area/ASN construct” = VRF B. Each mapping = BGP state C. Each path = label / adjacency
These issues still exist, because IPv8 indirectly consumes it:
- TCAM is still consumed (VRF separation not free) - LFIB size grows - BGP table complexity increases - convergence becomes harder
Further, your statement of "if it's passing thru no v8 silicon...." implies that every transit node must do: [perform classification, apply mapping logic, encapsulate]. That's additional pipeline work.
Shrihari Pandit Stealth Communications +1-212-232-2025
On Mon, May 4, 2026 at 1:04 AM Jamie Thain <jamie@one.bm> wrote:
Shrihari,
See every 10 or 11 emails you get one that is at least an argument.
Ipv8 is an area code based system, and the area codes.
When an ipv8 packet arrives at your edge there are only 2 conditions.
The route is destined for you or it's passing thru, and then there are only 2 cases you have ipv8 silicon or you don't.
Ok if it's passing thru no v8 silicon xlate8 looks up it's asnV4 encapsulates it and sends via v4 to that destination.
Ok if it's not passing thru and this is the destination then you have two route tables to be concerned with. Asn 0 and asn my asn say 1234
There are 2 vrfs created on ipv8 configs
ip vrf ipv8-asn-1234 rd 1234:65535
ip vrf ipv4-asn-0 rd 0:65535
So as routes the ipv8 is loaded into 2 different lfibs in the silicon and managed by the ipv4 silicon.
You create the ipv8 overlay by putting it in a vrf until ipv8 silicon is naturally updated.
Then for the main show ipv8 route it looks in bgp statement
include ip vrf ipv8-asn-1234 as asn 1234 Include ip vrf ipv4-asn-0 as ipv4
And shows these routes
There is no new silicon required. From a silicon level "IPv8 is an L3VPN with a globally reserved RD. If your router does L3VPN today — and every SP router does — your router does IPv8 today"
HTH
Jamie
On Sun., May 3, 2026, 10:56 a.m. Shrihari Pandit, <spandit@stealth.net> wrote:
Hi Jamine,
We had internal discussions with our team and are ones that are experienced in economics (wide range of fields, and engineering including CMOS, FPGA, ACIS.)
1. This is what I was told. IPv8 requires two additional lookups. It results in:
- wider parser support - new match/action pipeline design - more TCAM/SRAM slices - larger die area - higher power draw - lower port density - new board designs - new optics/thermal validation - new NOS/SDK support - more heat as result of higher power draw
2. Cost areas:
- New ASIC / merchant silicon design - Router/switch platform redesign - Carrier backbone + edge replacement - Hyperscaler/data-center network - Enterprise/CPE/firewall/load-balancer "refresh" - Software, OSS/BSS, routing stacks, monitoring systems - Testing, certification, migration labour - Operational risk, outages, dual-stack complexity
The approximate numbers to implement are between $500B up to $2T (more realistic number @ $740B)
Cisco describes routing silicon release cycles in the 18–36 month range, which means this is not software patches: src: https://www.cisco.com/c/dam/m/digital/elq-cmcglobal/witb/CKN/0721_CROSS.pdf
So IPv8 is control-plane cheap and data-plane expensive. The draft needs to account for that. Maybe Trump can allocate $2T to create more jobs, more work. You will need to likely reach out to the NSC. It will take 30 years. If there is forcing event, maybe 10-15 years and that would require the gov to pay all carriers and end-users.
We should stop the discussion here; You should contact the merchant silicon companies to find out the costs and whether two additional lookups are required and are at what costs (actual costs, power draw, heat, etc.)
--- Shrihari 212-232-2025
On Sat, May 2, 2026 at 7:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Kevin
Code is expensive. I want a sense of anything is wrong first.
Dns server needs 10 lines of code. Dhcp server 0, ntp server 100, netlog 1000,
So far mostly people have told me to go F myself.
But it's the economics will win.
Tco = 0
If ipv is compatible If protocol = ipv8 Tco = education + dev time of tools once on all 4 varaint os's + any premiium - (integration savings) - 100,000s per mid size enterprise per year.
Think -100 000 per 1000 employees or so
If protocol = ipv6 Tco = interoperability testing + education + i get my ass fired for using it.
Tco for ipv8 - billions
Tco for ipv6 + billions
On Sat., May 2, 2026, 5:56 p.m. Kevin Tillery via NANOG, < nanog@lists.nanog.org> wrote:
Code is extremely malleable. You are not building a lunar lander. It will not explode, kill three people and humiliate a nation if you get it wrong. You will just observe that it is wrong and change it until it is right.
This gives you plentiful opportunities to discover things for yourself instead of spamming this mailing list with stupid arguments.
For example, if you actually write an IPv8 implementation, you can try connecting it to an IPv4 implementation. You will discover whether it actually works or not. This is infinitely more valuable than an argument.
Justin,
Because before you write a line of code you have to get it right, or near right.
If you want to see good engineering watch from the "Earth to the Moon" Spider, how they built the lunar lander.
So far I've had like 3 serious conversations about "this won't work" and each one has had me improve it. But "go make code" before we discuss what and how it should be, a DRAFT is actually when you want comments about the operation of it all.
I'm not going to wait until I written 1m worth of code to figure something is wrong.
IETF folks suggested to me, that I join Nanog to see how they might use it. IPv8 is not about address space.
Jamie
On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG <nanog@lists.nanog.org> wrote:
> I know of enterprises who are deploying v6. > > Until you can show the world a working IPv8 implementation on a large using > off-the-shelf components where people can run through failure scenarios and > really beat it up, not many people are going to take it seriously. > > Lower layers of the network relying on the functionality of higher layers > is a really, really, really bad idea. > > While it's always important to think about how to so something better, v8 > seems to create a whole bunch of new problems while not solving many
> have already been addressed in v6 and other protocols. > > Thank you > jms > > > > On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG < nanog@lists.nanog.org > [nanog@lists.nanog.org]> > wrote: > > > Andrew, > > > > Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 > > in a meeting and two corp engineers laughed. > > > > You can google it yourself. > > > > Jamie > > > > On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < > > nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote: > > > > > If no corporation is migrating then why is IPv6 traffic continuing to > > > increase? > > > > > > As I pointed out, IPv6 traffic increased 5% last year. At that > > admittedly > > > slow rate, the entire internet will be IPv6 in 10 years. > > > > > > Further your assertion that business is the prime mover is incorrect. > > > Business will move when they have to. That time is coming. > > > > > > When businesses can’t get IPv4 from their providers or superscaler, or a > > > vendor or client can’t reach them, they will move. > > > > > > Andrew > > > > > > > > > > > > On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < > > > nanog@lists.nanog.org [nanog@lists.nanog.org]> > > > wrote: > > > > > > > Andrew, > > > > > > > > The issue is for corporate and the cloud, IPv6 is just as broken as > > IPv4. > > > > > > > > And no corporate is migrating go look. Its been the next big
> > > > Corporate networks for 20 years. > > > > > > > > Jamie > > > > > > > > On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < > > > > nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote: > > > > > > > > > I oppose this. With IPv6 traffic now representing around half of > > > > internet > > > > > traffic, the time to rethink has long passed. > > > > > > > > > > If IPv8 was going to be a solution, it should have been a solution 10 > > > > years > > > > > ago. > > > > > > > > > > In the last 12 months, ~5% of traffic migrated to IPv6. At that > > rate, > > > > IPv6 > > > > > will be fully implemented by 2035. I'm not seeing a
> > needs > > > > to > > > > > be solved, or a credible solution. > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < > > > > > nanog@lists.nanog.org [nanog@lists.nanog.org]> > > > > > wrote: > > > > > > > > > > > Hi All, > > > > > > > > > > > > My name is Jamie Thain I'm the creator of IPv8. It's not a hoax. > > > > > > > > > > > > I joined this list because, as part of IPv8, I am creating a BGPv8. > > > > > Inside > > > > > > BGPv8, two new protocols CF (Cost Factor), weigh cost factors along > > > the > > > > > > routes to produce a better metric. It's a hybrid of EIRGP mixed > > with > > > > BGP > > > > > to > > > > > > create better engineering results. > > > > > > > > > > > > I also as part of CF created Sun Tzu which is the
> > > watches > > > > > CF > > > > > > and gives you a CF score of reliability. Do I trust my
On 2 May 2026 20:05:47 CEST, Jamie Thain via NANOG < nanog@lists.nanog.org> wrote: that thing in problem that protocol that partnership
> > > > with > > > > > > you? > > > > > > > > > > > > Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every > > > problem, > > > > > > etc, etc. That's not my discussion point. My point isn't "should I > > > even > > > > > > propose IPv8" my point is what would be the best result for > > > operators? > > > > > > > > > > > > I believe that since IPv8 solves the duopoly problem, it will > > replace > > > > > > IPv4. > > > > > > > > > > > > So the things to know, IPV8 is NOT a 64 bit addressing system. > > > > > > > > > > > > It is a 32 bit routing system with a 32 bit addressing system. > > > > > > > > > > > > A Routing Number = ASNs plus others. > > > > > > > > > > > > 8.8.8.8 would become 15169.8.8.8.8 > > > > > > > > > > > > https://www.ietf.org/archive/id/draft-thain-ipv8-02.html > [https://www.ietf.org/archive/id/draft-thain-ipv8-02.html] > > > > > > < > > > > > > https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea > [https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea] > > > > > 3372a?u=12457652 > > > > > > > > > > > > > > > > > > > > > > > > > So each ASN in the world will have 3 Billion available addresses. > > > > > > > > > > > > There is a specially reserved group of internal ASN 127.x.x.x so > > each > > > > > corp, > > > > > > org, has 16 Million areas of 3 Billion addresses, to replace > > 10.x.x.x > > > > and > > > > > > 100.64.x.x.x > > > > > > > > > > > > I'd appreciate your thoughts on it > > > > > > > > > > > > Jamie > > > > > > _______________________________________________ > > > > > > NANOG mailing list > > > > > > > > > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ > [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > > > > message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/ > > > > > > > > > > > _______________________________________________ > > > > > NANOG mailing list > > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ > [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > > > > message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/ > > > > _______________________________________________ > > > > NANOG mailing list > > > > > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ > [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > > message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/ > > > _______________________________________________ > > > NANOG mailing list > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ > [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > > message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/ > > _______________________________________________ > > NANOG mailing list > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ > message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/ > [
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA...
]
> _______________________________________________ > NANOG mailing list > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ > message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/ > [
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2MY7QMH6...
]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JTNFIASL...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QWWTJWVN... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DTITZNUE...
Hey everyone, I think we can all agree that the IPv8 threads have run its course, and Jamie has received plenty of feedback regarding this proposal via the mailing list community. If anyone wishes to continue the conversation, I recommend reaching out to Jamie off list. Kind regards, Ryan Hamel Co-Chair of the Moderation Committee ________________________________ From: Jamie Thain via NANOG <nanog@lists.nanog.org> Sent: Monday, May 4, 2026 4:06 PM To: Shrihari Pandit <spandit@stealth.net> Cc: North American Network Operators Group <nanog@lists.nanog.org>; Jamie Thain <jamie@one.bm> Subject: Re: IPv8 / BGP8 / CF - just build it Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. Shrihari, So the real system is IPv8 to mapping to IPv4 to forwarding. ABSOLUTELY!!! IPV8 is an are protocol Imagine a long time ago in a galaxy far far away, how area codes came to be. Each area was a core exchange. 416, Toronto, 212 New York. Once you got to the major exchange you don't need that number. In the exchange there's two type of numbers, 0 and the ASN. You have 0 the old numbers and ASN the new. On every router in the world there is a way to separate numbering systems called VRFs and l2.5 tags. Heres the complexity. ip vrf Ipv8-asn-1234 rd 1234:65535 // l2.5 label ip vrf ipv4-asn-0 rd 0:65535 // l2.5 label ipip in ip is a silicon and labels put up tunnels all the time. All silicon is optimized for this. Only pe routers will make a decision. The overhead will be measured in hundreds of lines of code and then it will be in LFIB. One level of label when modern systems are capable of 10+ levels. It's the exact same process as an mpls tags. So the complexity is equal to 2 MPLS l3vpns. Hopefully no one on your team thought that that would be very burdensome on a new router. Jamie On Mon., May 4, 2026, 9:15 a.m. Shrihari Pandit, <spandit@stealth.net> wrote:
Jamie,
"No new silicon required”, that’s only true because IPv8 is not being forwarded natively. Your actual process is: 1. Packets are encapsulated into IPv4 2. Lookup happens on IPv4 3. IPv8 is resolved via control-plane indirection 4. So the real system is IPv8 to mapping to IPv4 to forwarding.
Which means:
- extra lookup (mapping) - extra state (VRFs / LFIBs) - extra encapsulation - extra operational complexity
IPv8 shifted into the control plane. It reminds me of the original ARPANET days, CPU based routing. If we go down this path, the control planes might all require something like AMD EPYC 9965 (192 cores fyi.) due to PPS rate.
In reference to "loaded into 2 different LFIBs in the silicon". If I understand what you saying: A. Each “IPv8 area/ASN construct” = VRF B. Each mapping = BGP state C. Each path = label / adjacency
These issues still exist, because IPv8 indirectly consumes it:
- TCAM is still consumed (VRF separation not free) - LFIB size grows - BGP table complexity increases - convergence becomes harder
Further, your statement of "if it's passing thru no v8 silicon...." implies that every transit node must do: [perform classification, apply mapping logic, encapsulate]. That's additional pipeline work.
Shrihari Pandit Stealth Communications +1-212-232-2025
On Mon, May 4, 2026 at 1:04 AM Jamie Thain <jamie@one.bm> wrote:
Shrihari,
See every 10 or 11 emails you get one that is at least an argument.
Ipv8 is an area code based system, and the area codes.
When an ipv8 packet arrives at your edge there are only 2 conditions.
The route is destined for you or it's passing thru, and then there are only 2 cases you have ipv8 silicon or you don't.
Ok if it's passing thru no v8 silicon xlate8 looks up it's asnV4 encapsulates it and sends via v4 to that destination.
Ok if it's not passing thru and this is the destination then you have two route tables to be concerned with. Asn 0 and asn my asn say 1234
There are 2 vrfs created on ipv8 configs
ip vrf ipv8-asn-1234 rd 1234:65535
ip vrf ipv4-asn-0 rd 0:65535
So as routes the ipv8 is loaded into 2 different lfibs in the silicon and managed by the ipv4 silicon.
You create the ipv8 overlay by putting it in a vrf until ipv8 silicon is naturally updated.
Then for the main show ipv8 route it looks in bgp statement
include ip vrf ipv8-asn-1234 as asn 1234 Include ip vrf ipv4-asn-0 as ipv4
And shows these routes
There is no new silicon required. From a silicon level "IPv8 is an L3VPN with a globally reserved RD. If your router does L3VPN today — and every SP router does — your router does IPv8 today"
HTH
Jamie
On Sun., May 3, 2026, 10:56 a.m. Shrihari Pandit, <spandit@stealth.net> wrote:
Hi Jamine,
We had internal discussions with our team and are ones that are experienced in economics (wide range of fields, and engineering including CMOS, FPGA, ACIS.)
1. This is what I was told. IPv8 requires two additional lookups. It results in:
- wider parser support - new match/action pipeline design - more TCAM/SRAM slices - larger die area - higher power draw - lower port density - new board designs - new optics/thermal validation - new NOS/SDK support - more heat as result of higher power draw
2. Cost areas:
- New ASIC / merchant silicon design - Router/switch platform redesign - Carrier backbone + edge replacement - Hyperscaler/data-center network - Enterprise/CPE/firewall/load-balancer "refresh" - Software, OSS/BSS, routing stacks, monitoring systems - Testing, certification, migration labour - Operational risk, outages, dual-stack complexity
The approximate numbers to implement are between $500B up to $2T (more realistic number @ $740B)
Cisco describes routing silicon release cycles in the 18–36 month range, which means this is not software patches: src: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fdam%2Fm%2Fdigital%2Felq-cmcglobal%2Fwitb%2FCKN%2F0721_CROSS.pdf&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511032095%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JNUfJF1zx1JkPyVyNPWp43sZwvas4CpoC8NeHTFSbww%3D&reserved=0<https://www.cisco.com/c/dam/m/digital/elq-cmcglobal/witb/CKN/0721_CROSS.pdf>
So IPv8 is control-plane cheap and data-plane expensive. The draft needs to account for that. Maybe Trump can allocate $2T to create more jobs, more work. You will need to likely reach out to the NSC. It will take 30 years. If there is forcing event, maybe 10-15 years and that would require the gov to pay all carriers and end-users.
We should stop the discussion here; You should contact the merchant silicon companies to find out the costs and whether two additional lookups are required and are at what costs (actual costs, power draw, heat, etc.)
--- Shrihari 212-232-2025
On Sat, May 2, 2026 at 7:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Kevin
Code is expensive. I want a sense of anything is wrong first.
Dns server needs 10 lines of code. Dhcp server 0, ntp server 100, netlog 1000,
So far mostly people have told me to go F myself.
But it's the economics will win.
Tco = 0
If ipv is compatible If protocol = ipv8 Tco = education + dev time of tools once on all 4 varaint os's + any premiium - (integration savings) - 100,000s per mid size enterprise per year.
Think -100 000 per 1000 employees or so
If protocol = ipv6 Tco = interoperability testing + education + i get my ass fired for using it.
Tco for ipv8 - billions
Tco for ipv6 + billions
On Sat., May 2, 2026, 5:56 p.m. Kevin Tillery via NANOG, < nanog@lists.nanog.org> wrote:
Code is extremely malleable. You are not building a lunar lander. It will not explode, kill three people and humiliate a nation if you get it wrong. You will just observe that it is wrong and change it until it is right.
This gives you plentiful opportunities to discover things for yourself instead of spamming this mailing list with stupid arguments.
For example, if you actually write an IPv8 implementation, you can try connecting it to an IPv4 implementation. You will discover whether it actually works or not. This is infinitely more valuable than an argument.
Justin,
Because before you write a line of code you have to get it right, or near right.
If you want to see good engineering watch from the "Earth to the Moon" Spider, how they built the lunar lander.
So far I've had like 3 serious conversations about "this won't work" and each one has had me improve it. But "go make code" before we discuss what and how it should be, a DRAFT is actually when you want comments about the operation of it all.
I'm not going to wait until I written 1m worth of code to figure something is wrong.
IETF folks suggested to me, that I join Nanog to see how they might use it. IPv8 is not about address space.
Jamie
On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG <nanog@lists.nanog.org> wrote:
> I know of enterprises who are deploying v6. > > Until you can show the world a working IPv8 implementation on a large using > off-the-shelf components where people can run through failure scenarios and > really beat it up, not many people are going to take it seriously. > > Lower layers of the network relying on the functionality of higher layers > is a really, really, really bad idea. > > While it's always important to think about how to so something better, v8 > seems to create a whole bunch of new problems while not solving many
> have already been addressed in v6 and other protocols. > > Thank you > jms > > > > On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG < nanog@lists.nanog.org > [nanog@lists.nanog.org]> > wrote: > > > Andrew, > > > > Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 > > in a meeting and two corp engineers laughed. > > > > You can google it yourself. > > > > Jamie > > > > On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < > > nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote: > > > > > If no corporation is migrating then why is IPv6 traffic continuing to > > > increase? > > > > > > As I pointed out, IPv6 traffic increased 5% last year. At that > > admittedly > > > slow rate, the entire internet will be IPv6 in 10 years. > > > > > > Further your assertion that business is the prime mover is incorrect. > > > Business will move when they have to. That time is coming. > > > > > > When businesses can’t get IPv4 from their providers or superscaler, or a > > > vendor or client can’t reach them, they will move. > > > > > > Andrew > > > > > > > > > > > > On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < > > > nanog@lists.nanog.org [nanog@lists.nanog.org]> > > > wrote: > > > > > > > Andrew, > > > > > > > > The issue is for corporate and the cloud, IPv6 is just as broken as > > IPv4. > > > > > > > > And no corporate is migrating go look. Its been the next big
> > > > Corporate networks for 20 years. > > > > > > > > Jamie > > > > > > > > On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < > > > > nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote: > > > > > > > > > I oppose this. With IPv6 traffic now representing around half of > > > > internet > > > > > traffic, the time to rethink has long passed. > > > > > > > > > > If IPv8 was going to be a solution, it should have been a solution 10 > > > > years > > > > > ago. > > > > > > > > > > In the last 12 months, ~5% of traffic migrated to IPv6. At that > > rate, > > > > IPv6 > > > > > will be fully implemented by 2035. I'm not seeing a
> > needs > > > > to > > > > > be solved, or a credible solution. > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < > > > > > nanog@lists.nanog.org [nanog@lists.nanog.org]> > > > > > wrote: > > > > > > > > > > > Hi All, > > > > > > > > > > > > My name is Jamie Thain I'm the creator of IPv8. It's not a hoax. > > > > > > > > > > > > I joined this list because, as part of IPv8, I am creating a BGPv8. > > > > > Inside > > > > > > BGPv8, two new protocols CF (Cost Factor), weigh cost factors along > > > the > > > > > > routes to produce a better metric. It's a hybrid of EIRGP mixed > > with > > > > BGP > > > > > to > > > > > > create better engineering results. > > > > > > > > > > > > I also as part of CF created Sun Tzu which is the
> > > watches > > > > > CF > > > > > > and gives you a CF score of reliability. Do I trust my
On 2 May 2026 20:05:47 CEST, Jamie Thain via NANOG < nanog@lists.nanog.org> wrote: that thing in problem that protocol that partnership
> > > > with > > > > > > you? > > > > > > > > > > > > Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every > > > problem, > > > > > > etc, etc. That's not my discussion point. My point isn't "should I > > > even > > > > > > propose IPv8" my point is what would be the best result for > > > operators? > > > > > > > > > > > > I believe that since IPv8 solves the duopoly problem, it will > > replace > > > > > > IPv4. > > > > > > > > > > > > So the things to know, IPV8 is NOT a 64 bit addressing system. > > > > > > > > > > > > It is a 32 bit routing system with a 32 bit addressing system. > > > > > > > > > > > > A Routing Number = ASNs plus others. > > > > > > > > > > > > 8.8.8.8 would become 15169.8.8.8.8 > > > > > > > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-thain-ipv8-02.html&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511069906%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dqim6N5T5%2FZMzmsrNrmCxCnmR9QAYK2sKjAoWYY5MHQ%3D&reserved=0<https://www.ietf.org/archive/id/draft-thain-ipv8-02.html> > [https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-thain-ipv8-02.html&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511102558%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iwxr3iZzSJ6SBEy06MKVVkHJ%2B%2BkZNi1xqJNAPkUREeI%3D&reserved=0<https://www.ietf.org/archive/id/draft-thain-ipv8-02.html>] > > > > > > < > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl.shortlink.es%2Fl%2F3ae384c1b8e2eb92749595407c5cf9b87ea&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511132952%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0jx%2F%2BF3NRCHIya7LYuuFjKPTxDLb7uTUCrcBug2Gru4%3D&reserved=0<https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea> > [https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl.shortlink.es%2Fl%2F3ae384c1b8e2eb92749595407c5cf9b87ea&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511162686%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Cj4HsgIVD9Z5zlU2ej6xF5xqgvCUAf1TDMqUdlphh18%3D&reserved=0<https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea>] > > > > > 3372a?u=12457652 > > > > > > > > > > > > > > > > > > > > > > > > > So each ASN in the world will have 3 Billion available addresses. > > > > > > > > > > > > There is a specially reserved group of internal ASN 127.x.x.x so > > each > > > > > corp, > > > > > > org, has 16 Million areas of 3 Billion addresses, to replace > > 10.x.x.x > > > > and > > > > > > 100.64.x.x.x > > > > > > > > > > > > I'd appreciate your thoughts on it > > > > > > > > > > > > Jamie > > > > > > _______________________________________________ > > > > > > NANOG mailing list > > > > > > > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511194508%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2FozmsvYsbsDGCJfE3LK%2B%2FAtDJU%2FAz%2Be%2BxLTB%2B%2BZESk%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/> > [https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511220674%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=o64vpopskjG3zRgI566tuG%2BQhsW6AtpvvvrTli1rpME%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/>] > > > > > message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/ > > > > > > > > > > > _______________________________________________ > > > > > NANOG mailing list > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511249997%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rSQwc%2FpPdpWnhEr51H0Y%2Fy65zCTVxU5KqNjfdb7DF2Y%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/> > [https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511291388%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dqCq06eFarcCjb7G6xVOu2ykRMo1oBRX1WYN8qA5ccA%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/>] > > > > > message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/ > > > > _______________________________________________ > > > > NANOG mailing list > > > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511326169%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8nKyya1cHGrF5tfmIczvBq9I7txZLzHHJx98GQcZ8pw%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/> > [https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511357066%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=izvv42kIo2biqFsij8NpX3kueftXKDVkvOXZg0UZdMc%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/>] > > > message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/ > > > _______________________________________________ > > > NANOG mailing list > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511388790%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QZEj%2F471YHZyM0y7vqM3YTJnGNz7RV%2B2354fgRfUS0k%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/> > [https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511435276%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qOqso3hDA3o8eU622b9NwY0%2BRFqVmkcoOYC7KpVNKVg%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/>] > > > message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/ > > _______________________________________________ > > NANOG mailing list > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511473768%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=grfZ8FFFYUy7kv7VvxV%2BT1m0OKRlqA3Mwj8fxsCGeno%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/> > message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/ > [
]
> _______________________________________________ > NANOG mailing list > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511536167%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Yo6YFa7gwFy9z%2Bs35FAIdfGp07SOhAEjsJ9lbwkKNB0%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/> > message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/ > [
]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
_______________________________________________ NANOG mailing list
_______________________________________________ NANOG mailing list
I worked at a Fortune 5 bank that implemented ipv6. We did it at our edge, internally and even with business partners (SBA). YOU might not be familiar with businesses that are not using it - that doesn’t mean no one is. Adam ------ Original Message ------ From "Shane Ronan via NANOG" <nanog@lists.nanog.org> To "North American Network Operators Group" <nanog@lists.nanog.org> Cc "Jamie Thain" <jamie@one.bm>; "Shane Ronan" <shane@ronan-online.com> Date 5/4/2026 18:58:16 Subject Re: IPv8 / BGP8 / CF
You must not deal with very many corporations because I know many that have added v6 to their corporate networks. Think of many in the top 200 companies in the US.
Shane
On Mon, May 4, 2026 at 6:28 PM Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Kevin,
I can't fix ipv6 I'll leave that to people that understand the basics.
No one, and i mean no one in corp (that's not a super scalar) knows anything about ipv6 and no one and i mean no one cares.
They know it's on in there os and there's some mystery that some things will break if it's off.
Jamie
On Mon., May 4, 2026, 2:27 p.m. Kevin Tillery via NANOG, < nanog@lists.nanog.org> wrote:
Jamie
And ipv8 is no where on there radar. So fix ipv6.
I appreciate your input.
Kevin
Marco
And ipv6 is no where on there radar. So fix ipv4.
I appreciate your input.
Jamie
On Sun., May 3, 2026, 4:33 a.m. Marco Moock via NANOG, < nanog@lists.nanog.org> wrote:
Am 03.05.26 um 00:30 schrieb Jamie Thain via NANOG:
* IPv6 wasn't a surgical fix for address exhaustion — it bundled
On 4 May 2026 08:26:33 CEST, Jamie Thain via NANOG < nanog@lists.nanog.org> wrote: the
address-space change with a full redesign of neighbor discovery, autoconfiguration, header structure, and operational tooling.
That wasn't the issue. The issue is that it takes some time to prepare and do the implementation of another network protocol, regardless how it is called or how it works in detail. No one cares about ARP, nor NDP. It is there and works.
Corporate networks need address plan, firewall plans etc. and that needs to be extended if any new protocol is going to be implemented.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LZX6VCZU...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AVIU5UM7...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MPYN6YGE... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SGDZ4RYZ...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ABKATN6C...
Hey everyone, I think we can all agree that the IPv8 threads have run its course, and Jamie has received plenty of feedback regarding this proposal via the mailing list community. If anyone wishes to continue the conversation, I recommend reaching out to Jamie off list. Kind regards, Ryan Hamel Co-Chair of the Moderation Committee ________________________________ From: Adam Fathauer via NANOG <nanog@lists.nanog.org> Sent: Monday, May 4, 2026 4:41 PM To: North American Network Operators Group <nanog@lists.nanog.org>; North American Network Operators Group <nanog@lists.nanog.org> Cc: Jamie Thain <jamie@one.bm>; Shane Ronan <shane@ronan-online.com>; Adam Fathauer <adam@arfmail.com> Subject: Re[2]: IPv8 / BGP8 / CF Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. I worked at a Fortune 5 bank that implemented ipv6. We did it at our edge, internally and even with business partners (SBA). YOU might not be familiar with businesses that are not using it - that doesn’t mean no one is. Adam ------ Original Message ------ From "Shane Ronan via NANOG" <nanog@lists.nanog.org> To "North American Network Operators Group" <nanog@lists.nanog.org> Cc "Jamie Thain" <jamie@one.bm>; "Shane Ronan" <shane@ronan-online.com> Date 5/4/2026 18:58:16 Subject Re: IPv8 / BGP8 / CF
You must not deal with very many corporations because I know many that have added v6 to their corporate networks. Think of many in the top 200 companies in the US.
Shane
On Mon, May 4, 2026 at 6:28 PM Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Kevin,
I can't fix ipv6 I'll leave that to people that understand the basics.
No one, and i mean no one in corp (that's not a super scalar) knows anything about ipv6 and no one and i mean no one cares.
They know it's on in there os and there's some mystery that some things will break if it's off.
Jamie
On Mon., May 4, 2026, 2:27 p.m. Kevin Tillery via NANOG, < nanog@lists.nanog.org> wrote:
Jamie
And ipv8 is no where on there radar. So fix ipv6.
I appreciate your input.
Kevin
Marco
And ipv6 is no where on there radar. So fix ipv4.
I appreciate your input.
Jamie
On Sun., May 3, 2026, 4:33 a.m. Marco Moock via NANOG, < nanog@lists.nanog.org> wrote:
Am 03.05.26 um 00:30 schrieb Jamie Thain via NANOG:
* IPv6 wasn't a surgical fix for address exhaustion — it bundled
On 4 May 2026 08:26:33 CEST, Jamie Thain via NANOG < nanog@lists.nanog.org> wrote: the
address-space change with a full redesign of neighbor discovery, autoconfiguration, header structure, and operational tooling.
That wasn't the issue. The issue is that it takes some time to prepare and do the implementation of another network protocol, regardless how it is called or how it works in detail. No one cares about ARP, nor NDP. It is there and works.
Corporate networks need address plan, firewall plans etc. and that needs to be extended if any new protocol is going to be implemented.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
_______________________________________________ NANOG mailing list
_______________________________________________ NANOG mailing list
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FMPYN6YGEZCGL5ZH6Z4BLZMUWBEU3SXEV%2F&data=05%7C02%7Cryan%40rkhtech.org%7C2f7e8fb152614f39881308deaa36bcbc%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135349351984740%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ON6NGLNRpTlcGjUeW1vgcNlwaMj1AVv10zlBQdn9Wt4%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MPYN6YGEZCGL5ZH6Z4BLZMUWBEU3SXEV/> _______________________________________________ NANOG mailing list
Ryan- Respectfully , why ? On Mon, May 4, 2026 at 19:27 Ryan Hamel via NANOG <nanog@lists.nanog.org> wrote:
Hey everyone,
I think we can all agree that the IPv8 threads have run its course, and Jamie has received plenty of feedback regarding this proposal via the mailing list community. If anyone wishes to continue the conversation, I recommend reaching out to Jamie off list.
Kind regards,
Ryan Hamel
Co-Chair of the Moderation Committee ________________________________ From: Jamie Thain via NANOG <nanog@lists.nanog.org> Sent: Monday, May 4, 2026 4:06 PM To: Shrihari Pandit <spandit@stealth.net> Cc: North American Network Operators Group <nanog@lists.nanog.org>; Jamie Thain <jamie@one.bm> Subject: Re: IPv8 / BGP8 / CF - just build it
Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.
Shrihari,
So the real system is IPv8 to mapping to IPv4 to forwarding.
ABSOLUTELY!!!
IPV8 is an are protocol
Imagine a long time ago in a galaxy far far away, how area codes came to be.
Each area was a core exchange. 416, Toronto, 212 New York. Once you got to the major exchange you don't need that number.
In the exchange there's two type of numbers, 0 and the ASN.
You have 0 the old numbers and ASN the new. On every router in the world there is a way to separate numbering systems called VRFs and l2.5 tags.
Heres the complexity.
ip vrf Ipv8-asn-1234 rd 1234:65535 // l2.5 label
ip vrf ipv4-asn-0 rd 0:65535 // l2.5 label
ipip in ip is a silicon and labels put up tunnels all the time.
All silicon is optimized for this. Only pe routers will make a decision. The overhead will be measured in hundreds of lines of code and then it will be in LFIB.
One level of label when modern systems are capable of 10+ levels.
It's the exact same process as an mpls tags.
So the complexity is equal to 2 MPLS l3vpns.
Hopefully no one on your team thought that that would be very burdensome on a new router.
Jamie
On Mon., May 4, 2026, 9:15 a.m. Shrihari Pandit, <spandit@stealth.net> wrote:
Jamie,
"No new silicon required”, that’s only true because IPv8 is not being forwarded natively. Your actual process is: 1. Packets are encapsulated into IPv4 2. Lookup happens on IPv4 3. IPv8 is resolved via control-plane indirection 4. So the real system is IPv8 to mapping to IPv4 to forwarding.
Which means:
- extra lookup (mapping) - extra state (VRFs / LFIBs) - extra encapsulation - extra operational complexity
IPv8 shifted into the control plane. It reminds me of the original ARPANET days, CPU based routing. If we go down this path, the control planes might all require something like AMD EPYC 9965 (192 cores fyi.) due to PPS rate.
In reference to "loaded into 2 different LFIBs in the silicon". If I understand what you saying: A. Each “IPv8 area/ASN construct” = VRF B. Each mapping = BGP state C. Each path = label / adjacency
These issues still exist, because IPv8 indirectly consumes it:
- TCAM is still consumed (VRF separation not free) - LFIB size grows - BGP table complexity increases - convergence becomes harder
Further, your statement of "if it's passing thru no v8 silicon...." implies that every transit node must do: [perform classification, apply mapping logic, encapsulate]. That's additional pipeline work.
Shrihari Pandit Stealth Communications +1-212-232-2025
On Mon, May 4, 2026 at 1:04 AM Jamie Thain <jamie@one.bm> wrote:
Shrihari,
See every 10 or 11 emails you get one that is at least an argument.
Ipv8 is an area code based system, and the area codes.
When an ipv8 packet arrives at your edge there are only 2 conditions.
The route is destined for you or it's passing thru, and then there are only 2 cases you have ipv8 silicon or you don't.
Ok if it's passing thru no v8 silicon xlate8 looks up it's asnV4 encapsulates it and sends via v4 to that destination.
Ok if it's not passing thru and this is the destination then you have two route tables to be concerned with. Asn 0 and asn my asn say 1234
There are 2 vrfs created on ipv8 configs
ip vrf ipv8-asn-1234 rd 1234:65535
ip vrf ipv4-asn-0 rd 0:65535
So as routes the ipv8 is loaded into 2 different lfibs in the silicon and managed by the ipv4 silicon.
You create the ipv8 overlay by putting it in a vrf until ipv8 silicon is naturally updated.
Then for the main show ipv8 route it looks in bgp statement
include ip vrf ipv8-asn-1234 as asn 1234 Include ip vrf ipv4-asn-0 as ipv4
And shows these routes
There is no new silicon required. From a silicon level "IPv8 is an L3VPN with a globally reserved RD. If your router does L3VPN today — and every SP router does — your router does IPv8 today"
HTH
Jamie
On Sun., May 3, 2026, 10:56 a.m. Shrihari Pandit, <spandit@stealth.net> wrote:
Hi Jamine,
We had internal discussions with our team and are ones that are experienced in economics (wide range of fields, and engineering including CMOS, FPGA, ACIS.)
1. This is what I was told. IPv8 requires two additional lookups. It results in:
- wider parser support - new match/action pipeline design - more TCAM/SRAM slices - larger die area - higher power draw - lower port density - new board designs - new optics/thermal validation - new NOS/SDK support - more heat as result of higher power draw
2. Cost areas:
- New ASIC / merchant silicon design - Router/switch platform redesign - Carrier backbone + edge replacement - Hyperscaler/data-center network - Enterprise/CPE/firewall/load-balancer "refresh" - Software, OSS/BSS, routing stacks, monitoring systems - Testing, certification, migration labour - Operational risk, outages, dual-stack complexity
The approximate numbers to implement are between $500B up to $2T (more realistic number @ $740B)
Cisco describes routing silicon release cycles in the 18–36 month range, which means this is not software patches: src:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fdam%2Fm%2Fdigital%2Felq-cmcglobal%2Fwitb%2FCKN%2F0721_CROSS.pdf&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511032095%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JNUfJF1zx1JkPyVyNPWp43sZwvas4CpoC8NeHTFSbww%3D&reserved=0 < https://www.cisco.com/c/dam/m/digital/elq-cmcglobal/witb/CKN/0721_CROSS.pdf
So IPv8 is control-plane cheap and data-plane expensive. The draft
to account for that. Maybe Trump can allocate $2T to create more jobs, more work. You will need to likely reach out to the NSC. It will take 30 years. If there is forcing event, maybe 10-15 years and that would require
to pay all carriers and end-users.
We should stop the discussion here; You should contact the merchant silicon companies to find out the costs and whether two additional lookups are required and are at what costs (actual costs, power draw, heat, etc.)
--- Shrihari 212-232-2025
On Sat, May 2, 2026 at 7:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Kevin
Code is expensive. I want a sense of anything is wrong first.
Dns server needs 10 lines of code. Dhcp server 0, ntp server 100, netlog 1000,
So far mostly people have told me to go F myself.
But it's the economics will win.
Tco = 0
If ipv is compatible If protocol = ipv8 Tco = education + dev time of tools once on all 4 varaint os's + any premiium - (integration savings) - 100,000s per mid size enterprise per year.
Think -100 000 per 1000 employees or so
If protocol = ipv6 Tco = interoperability testing + education + i get my ass fired for using it.
Tco for ipv8 - billions
Tco for ipv6 + billions
On Sat., May 2, 2026, 5:56 p.m. Kevin Tillery via NANOG, < nanog@lists.nanog.org> wrote:
Code is extremely malleable. You are not building a lunar lander. It will not explode, kill three people and humiliate a nation if you get it wrong. You will just observe that it is wrong and change it until it is right.
This gives you plentiful opportunities to discover things for yourself instead of spamming this mailing list with stupid arguments.
For example, if you actually write an IPv8 implementation, you can
connecting it to an IPv4 implementation. You will discover whether it actually works or not. This is infinitely more valuable than an argument.
On 2 May 2026 20:05:47 CEST, Jamie Thain via NANOG < nanog@lists.nanog.org> wrote: >Justin, > >Because before you write a line of code you have to get it right, or near >right. > >If you want to see good engineering watch from the "Earth to the Moon" Spider, >how they built the lunar lander. > >So far I've had like 3 serious conversations about "this won't work" and each >one has had me improve it. But "go make code" before we discuss what and how it >should be, a DRAFT is actually when you want comments about the operation of it >all. > >I'm not going to wait until I written 1m worth of code to figure something is >wrong. > >IETF folks suggested to me, that I join Nanog to see how they might use it. IPv8 >is not about address space. > > > >Jamie > > > >On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG ><nanog@lists.nanog.org> wrote: > > >> I know of enterprises who are deploying v6. >> >> Until you can show the world a working IPv8 implementation on a large using >> off-the-shelf components where people can run through failure scenarios and >> really beat it up, not many people are going to take it seriously. >> >> Lower layers of the network relying on the functionality of higher layers >> is a really, really, really bad idea. >> >> While it's always important to think about how to so something better, v8 >> seems to create a whole bunch of new problems while not solving many that >> have already been addressed in v6 and other protocols. >> >> Thank you >> jms >> >> >> >> On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG < nanog@lists.nanog.org >> [nanog@lists.nanog.org]> >> wrote: >> >> > Andrew, >> > >> > Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 >> > in a meeting and two corp engineers laughed. >> > >> > You can google it yourself. >> > >> > Jamie >> > >> > On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < >> > nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote: >> > >> > > If no corporation is migrating then why is IPv6 traffic continuing to >> > > increase? >> > > >> > > As I pointed out, IPv6 traffic increased 5% last year. At
needs the gov try that
>> > admittedly >> > > slow rate, the entire internet will be IPv6 in 10 years. >> > > >> > > Further your assertion that business is the prime mover is incorrect. >> > > Business will move when they have to. That time is coming. >> > > >> > > When businesses can’t get IPv4 from their providers or superscaler, or a >> > > vendor or client can’t reach them, they will move. >> > > >> > > Andrew >> > > >> > > >> > > >> > > On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < >> > > nanog@lists.nanog.org [nanog@lists.nanog.org]> >> > > wrote: >> > > >> > > > Andrew, >> > > > >> > > > The issue is for corporate and the cloud, IPv6 is just as broken as >> > IPv4. >> > > > >> > > > And no corporate is migrating go look. Its been the next big thing in >> > > > Corporate networks for 20 years. >> > > > >> > > > Jamie >> > > > >> > > > On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < >> > > > nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote: >> > > > >> > > > > I oppose this. With IPv6 traffic now representing around half of >> > > > internet >> > > > > traffic, the time to rethink has long passed. >> > > > > >> > > > > If IPv8 was going to be a solution, it should have been a solution 10 >> > > > years >> > > > > ago. >> > > > > >> > > > > In the last 12 months, ~5% of traffic migrated to IPv6. At that >> > rate, >> > > > IPv6 >> > > > > will be fully implemented by 2035. I'm not seeing a problem that >> > needs >> > > > to >> > > > > be solved, or a credible solution. >> > > > > >> > > > > Andrew >> > > > > >> > > > > >> > > > > >> > > > > On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < >> > > > > nanog@lists.nanog.org [nanog@lists.nanog.org]> >> > > > > wrote: >> > > > > >> > > > > > Hi All, >> > > > > > >> > > > > > My name is Jamie Thain I'm the creator of IPv8. It's not a hoax. >> > > > > > >> > > > > > I joined this list because, as part of IPv8, I am creating a BGPv8. >> > > > > Inside >> > > > > > BGPv8, two new protocols CF (Cost Factor), weigh cost factors along >> > > the >> > > > > > routes to produce a better metric. It's a hybrid of EIRGP mixed >> > with >> > > > BGP >> > > > > to >> > > > > > create better engineering results. >> > > > > > >> > > > > > I also as part of CF created Sun Tzu which is the protocol that >> > > watches >> > > > > CF >> > > > > > and gives you a CF score of reliability. Do I trust my partnership >> > > > with >> > > > > > you? >> > > > > > >> > > > > > Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every >> > > problem, >> > > > > > etc, etc. That's not my discussion point. My point isn't "should I >> > > even >> > > > > > propose IPv8" my point is what would be the best result for >> > > operators? >> > > > > > >> > > > > > I believe that since IPv8 solves the duopoly problem, it will >> > replace >> > > > > > IPv4. >> > > > > > >> > > > > > So the things to know, IPV8 is NOT a 64 bit addressing system. >> > > > > > >> > > > > > It is a 32 bit routing system with a 32 bit addressing system. >> > > > > > >> > > > > > A Routing Number = ASNs plus others. >> > > > > > >> > > > > > 8.8.8.8 would become 15169.8.8.8.8 >> > > > > > >> > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-thain-ipv8-02.html&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511069906%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dqim6N5T5%2FZMzmsrNrmCxCnmR9QAYK2sKjAoWYY5MHQ%3D&reserved=0 <https://www.ietf.org/archive/id/draft-thain-ipv8-02.html> >> [ https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-thain-ipv8-02.html&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511102558%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iwxr3iZzSJ6SBEy06MKVVkHJ%2B%2BkZNi1xqJNAPkUREeI%3D&reserved=0 <https://www.ietf.org/archive/id/draft-thain-ipv8-02.html>] >> > > > > > < >> > > > > >
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl.shortlink.es%2Fl%2F3ae384c1b8e2eb92749595407c5cf9b87ea&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511132952%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0jx%2F%2BF3NRCHIya7LYuuFjKPTxDLb7uTUCrcBug2Gru4%3D&reserved=0 <https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea>
>> [ https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl.shortlink.es%2Fl%2F3ae384c1b8e2eb92749595407c5cf9b87ea&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511162686%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Cj4HsgIVD9Z5zlU2ej6xF5xqgvCUAf1TDMqUdlphh18%3D&reserved=0 <https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea>] >> > > > > 3372a?u=12457652 >> > > > > > > >> > > > > > >> > > > > > >> > > > > > So each ASN in the world will have 3 Billion available addresses. >> > > > > > >> > > > > > There is a specially reserved group of internal ASN 127.x.x.x so >> > each >> > > > > corp, >> > > > > > org, has 16 Million areas of 3 Billion addresses, to replace >> > 10.x.x.x >> > > > and >> > > > > > 100.64.x.x.x >> > > > > > >> > > > > > I'd appreciate your thoughts on it >> > > > > > >> > > > > > Jamie >> > > > > > _______________________________________________ >> > > > > > NANOG mailing list >> > > > > > >> > > > > >
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511194508%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2FozmsvYsbsDGCJfE3LK%2B%2FAtDJU%2FAz%2Be%2BxLTB%2B%2BZESk%3D&reserved=0 <https://lists.nanog.org/archives/list/nanog@lists.nanog.org/>
>> [ https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511220674%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=o64vpopskjG3zRgI566tuG%2BQhsW6AtpvvvrTli1rpME%3D&reserved=0 <https://lists.nanog.org/archives/list/nanog@lists.nanog.org/>] >> > > > > message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/ >> > > > > > >> > > > > _______________________________________________ >> > > > > NANOG mailing list >> > > > >
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511249997%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rSQwc%2FpPdpWnhEr51H0Y%2Fy65zCTVxU5KqNjfdb7DF2Y%3D&reserved=0 <https://lists.nanog.org/archives/list/nanog@lists.nanog.org/>
>> [ https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511291388%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dqCq06eFarcCjb7G6xVOu2ykRMo1oBRX1WYN8qA5ccA%3D&reserved=0 <https://lists.nanog.org/archives/list/nanog@lists.nanog.org/>] >> > > > > message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/ >> > > > _______________________________________________ >> > > > NANOG mailing list >> > > > >> > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511326169%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8nKyya1cHGrF5tfmIczvBq9I7txZLzHHJx98GQcZ8pw%3D&reserved=0 <https://lists.nanog.org/archives/list/nanog@lists.nanog.org/> >> [ https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511357066%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=izvv42kIo2biqFsij8NpX3kueftXKDVkvOXZg0UZdMc%3D&reserved=0 <https://lists.nanog.org/archives/list/nanog@lists.nanog.org/>] >> > > message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/ >> > > _______________________________________________ >> > > NANOG mailing list >> > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511388790%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QZEj%2F471YHZyM0y7vqM3YTJnGNz7RV%2B2354fgRfUS0k%3D&reserved=0 <https://lists.nanog.org/archives/list/nanog@lists.nanog.org/> >> [ https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511435276%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qOqso3hDA3o8eU622b9NwY0%2BRFqVmkcoOYC7KpVNKVg%3D&reserved=0 <https://lists.nanog.org/archives/list/nanog@lists.nanog.org/>] >> > > message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/ >> > _______________________________________________ >> > NANOG mailing list >> > >> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511473768%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=grfZ8FFFYUy7kv7VvxV%2BT1m0OKRlqA3Mwj8fxsCGeno%3D&reserved=0 <https://lists.nanog.org/archives/list/nanog@lists.nanog.org/> >> message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/ >> [
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2F52EWJ6VAN5YXXENIATYZAPIYO5KJAANT%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511505927%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=f3b%2FKXA9v8FbjJmUmGLzifEDndlvh%2FmFkj5bMbtzDRk%3D&reserved=0 < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA...
] >> _______________________________________________ >> NANOG mailing list >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511536167%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Yo6YFa7gwFy9z%2Bs35FAIdfGp07SOhAEjsJ9lbwkKNB0%3D&reserved=0 <https://lists.nanog.org/archives/list/nanog@lists.nanog.org/> >> message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/ >> [
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2F2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511566852%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xnD%2BbbdOLV511zX3FuSZPryzBQZBHY9AXHBetSHRLQQ%3D&reserved=0 < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2MY7QMH6...
] >
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
>_______________________________________________ >NANOG mailing list >
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FJTNFIASLS5MTKKP64R7FV6NDPTH2T6PW%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511599422%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2OCuiCGX1fEb%2FmjcRRzwVI0ttkQZPKzuhBxs%2FZxXopY%3D&reserved=0 < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JTNFIASL...
_______________________________________________ NANOG mailing list
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FQWWTJWVN775LBWRMBUBP5YWRTFPCEFCT%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511626883%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=d0OHW3umrRwgY7KM%2B7emGCRZGfia8434Z8GnWw7JbSM%3D&reserved=0 < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QWWTJWVN...
_______________________________________________ NANOG mailing list
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FDTITZNUEU3HKMUMXI3NWZVELKL6J4KIB%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511650647%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uL0BMn2l%2BKnTIRzkHsp%2FUf%2FvanIL8QLZIIs%2FvPhkHt4%3D&reserved=0 < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DTITZNUE...
NANOG mailing list
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FLUGDFTDETO3FNPXL3FUQDTH6YJU3OWCC%2F&data=05%7C02%7Cryan%40rkhtech.org%7C87477bf42fe2473d3d5908deaa31e78d%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135328511674442%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=kJRu9pkJP3S3zz54GXJdKvccmwiMeBEy8F6hmW2JjK4%3D&reserved=0 < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LUGDFTDE...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JZ7PQIAM...
This thread should die, but if we’re going to drag it on, Jamie, can you please trim the thing. We’re at least 13 levels deep on quoted emails. -- Eric Germann ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com LinkedIn: https://www.linkedin.com/in/ericgermann Medium: https://ekgermann.medium.com <https://ekgermann.medium.com/> Twitter: @ekgermann Telegram || Signal || Skype || WhatsApp || Phone +1 {dash} 419 {dash} 513 {dash} 0712 Fax: +1(dash}234{dash}678{{dash}4863 GPG Fingerprint: 89ED 36B3 515A 211B 6390 60A9 E30D 9B9B 3EBF F1A1
I believe Microsoft uses IPv6 internally, at least that’s what I read a long time ago -- Eric Germann
Eric - using Gmail you can use the "mute" button. I do this every time a new conversation starts. On Tue, May 5, 2026 at 11:29 AM Eric Germann via NANOG < nanog@lists.nanog.org> wrote:
This thread should die, but if we’re going to drag it on, Jamie, can you please trim the thing. We’re at least 13 levels deep on quoted emails.
-- Eric Germann ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com LinkedIn: https://www.linkedin.com/in/ericgermann Medium: https://ekgermann.medium.com <https://ekgermann.medium.com/> Twitter: @ekgermann Telegram || Signal || Skype || WhatsApp || Phone +1 {dash} 419 {dash} 513 {dash} 0712 Fax: +1(dash}234{dash}678{{dash}4863
GPG Fingerprint: 89ED 36B3 515A 211B 6390 60A9 E30D 9B9B 3EBF F1A1
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/PVRTJVTW...
On 2026-05-05 09:33, Eric Germann via NANOG wrote:
I believe Microsoft uses IPv6 internally, at least that’s what I read a long time ago
Plus all the cell phone providers (even the Canadian ones), plus many/some big ISPs, I think I heard ComCast (millions of subscribers) is on IPv6. Plus Asia runs on IPv6, if I heard correctly.
Hey everyone, I want to clarify what I said yesterday evening. I was speaking as myself there and not issuing any official Moderation Committee action. No one is or was being censored; no posts were removed, and no one is prohibited from continuing the discussion on-list. Signing that email with my Moderation Committee title made the message read more formally than I intended, and it blurred the line between a personal recommendation and committee action. I apologize for my mistake there. My intent was only to suggest that repetitive follow-up may be more productive off-list if there is no new list-wide substance to add. Kind regards, Ryan Hamel ________________________________ From: Ryan Hamel via NANOG <nanog@lists.nanog.org> Sent: Monday, May 4, 2026 4:45 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Jamie Thain <jamie@one.bm>; Ryan Hamel <ryan@rkhtech.org> Subject: Re: Re[2]: IPv8 / BGP8 / CF Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. Hey everyone, I think we can all agree that the IPv8 threads have run its course, and Jamie has received plenty of feedback regarding this proposal via the mailing list community. If anyone wishes to continue the conversation, I recommend reaching out to Jamie off list. Kind regards, Ryan Hamel Co-Chair of the Moderation Committee ________________________________ From: Adam Fathauer via NANOG <nanog@lists.nanog.org> Sent: Monday, May 4, 2026 4:41 PM To: North American Network Operators Group <nanog@lists.nanog.org>; North American Network Operators Group <nanog@lists.nanog.org> Cc: Jamie Thain <jamie@one.bm>; Shane Ronan <shane@ronan-online.com>; Adam Fathauer <adam@arfmail.com> Subject: Re[2]: IPv8 / BGP8 / CF Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. I worked at a Fortune 5 bank that implemented ipv6. We did it at our edge, internally and even with business partners (SBA). YOU might not be familiar with businesses that are not using it - that doesn’t mean no one is. Adam ------ Original Message ------ From "Shane Ronan via NANOG" <nanog@lists.nanog.org> To "North American Network Operators Group" <nanog@lists.nanog.org> Cc "Jamie Thain" <jamie@one.bm>; "Shane Ronan" <shane@ronan-online.com> Date 5/4/2026 18:58:16 Subject Re: IPv8 / BGP8 / CF
You must not deal with very many corporations because I know many that have added v6 to their corporate networks. Think of many in the top 200 companies in the US.
Shane
On Mon, May 4, 2026 at 6:28 PM Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Kevin,
I can't fix ipv6 I'll leave that to people that understand the basics.
No one, and i mean no one in corp (that's not a super scalar) knows anything about ipv6 and no one and i mean no one cares.
They know it's on in there os and there's some mystery that some things will break if it's off.
Jamie
On Mon., May 4, 2026, 2:27 p.m. Kevin Tillery via NANOG, < nanog@lists.nanog.org> wrote:
Jamie
And ipv8 is no where on there radar. So fix ipv6.
I appreciate your input.
Kevin
Marco
And ipv6 is no where on there radar. So fix ipv4.
I appreciate your input.
Jamie
On Sun., May 3, 2026, 4:33 a.m. Marco Moock via NANOG, < nanog@lists.nanog.org> wrote:
Am 03.05.26 um 00:30 schrieb Jamie Thain via NANOG:
* IPv6 wasn't a surgical fix for address exhaustion — it bundled
On 4 May 2026 08:26:33 CEST, Jamie Thain via NANOG < nanog@lists.nanog.org> wrote: the
address-space change with a full redesign of neighbor discovery, autoconfiguration, header structure, and operational tooling.
That wasn't the issue. The issue is that it takes some time to prepare and do the implementation of another network protocol, regardless how it is called or how it works in detail. No one cares about ARP, nor NDP. It is there and works.
Corporate networks need address plan, firewall plans etc. and that needs to be extended if any new protocol is going to be implemented.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
_______________________________________________ NANOG mailing list
_______________________________________________ NANOG mailing list
NANOG mailing list https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2F6MJ4UMRS6KHDPZKHURAFLICHAVRJBCQE%2F&data=05%7C02%7Cryan%40rkhtech.org%7Cb3987ed7e1d94b326d6a08deaa374b2f%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135351651873506%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gCPxw7z6HN2dj9apVjiZFilEsGZ9nfcVltBdEK2txGY%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2F6MJ4UMRS6KHDPZKHURAFLICHAVRJBCQE%2F&data=05%7C02%7Cryan%40rkhtech.org%7Cb3987ed7e1d94b326d6a08deaa374b2f%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135351651934483%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=N56nFwqo%2Bf3%2B76c%2Fs79ssUFrPYvkSSqBrOq1qfvn%2Fzo%3D&reserved=0><https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6MJ4UMRS6KHDPZKHURAFLICHAVRJBCQE/> _______________________________________________ NANOG mailing list https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2F5IHFE32TA2X2OR5QBDYHBUE2HMK7IP6A%2F&data=05%7C02%7Cryan%40rkhtech.org%7Cb3987ed7e1d94b326d6a08deaa374b2f%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135351651995646%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IE3NjiYsMVZ3EQTokUIFSb504nT%2FbVSXt5fQSZbylaE%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5IHFE32TA2X2OR5QBDYHBUE2HMK7IP6A/>
Hey everyone, I want to clarify what I said yesterday evening. I was speaking as myself there and not issuing any official Moderation Committee action. No one is or was being censored; no posts were removed, and no one is prohibited from continuing the discussion on-list. Signing that email with my Moderation Committee title made the message read more formally than I intended, and it blurred the line between a personal recommendation and committee action. I apologize for my mistake there. My intent was only to suggest that repetitive follow-up may be more productive off-list if there is no new list-wide substance to add. Kind regards, Ryan Hamel ________________________________ From: Ryan Hamel via NANOG <nanog@lists.nanog.org> Sent: Monday, May 4, 2026 4:27 PM To: Jamie Thain <jamie@one.bm>; North American Network Operators Group <nanog@lists.nanog.org> Cc: forum <forum@nanog.org>; Ryan Hamel <ryan@rkhtech.org> Subject: Re: IPv8 / BGP8 / CF - just build it Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. Hey everyone, I think we can all agree that the IPv8 threads have run its course, and Jamie has received plenty of feedback regarding this proposal via the mailing list community. If anyone wishes to continue the conversation, I recommend reaching out to Jamie off list. Kind regards, Ryan Hamel Co-Chair of the Moderation Committee ________________________________ From: Jamie Thain via NANOG <nanog@lists.nanog.org> Sent: Monday, May 4, 2026 4:06 PM To: Shrihari Pandit <spandit@stealth.net> Cc: North American Network Operators Group <nanog@lists.nanog.org>; Jamie Thain <jamie@one.bm> Subject: Re: IPv8 / BGP8 / CF - just build it Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. Shrihari, So the real system is IPv8 to mapping to IPv4 to forwarding. ABSOLUTELY!!! IPV8 is an are protocol Imagine a long time ago in a galaxy far far away, how area codes came to be. Each area was a core exchange. 416, Toronto, 212 New York. Once you got to the major exchange you don't need that number. In the exchange there's two type of numbers, 0 and the ASN. You have 0 the old numbers and ASN the new. On every router in the world there is a way to separate numbering systems called VRFs and l2.5 tags. Heres the complexity. ip vrf Ipv8-asn-1234 rd 1234:65535 // l2.5 label ip vrf ipv4-asn-0 rd 0:65535 // l2.5 label ipip in ip is a silicon and labels put up tunnels all the time. All silicon is optimized for this. Only pe routers will make a decision. The overhead will be measured in hundreds of lines of code and then it will be in LFIB. One level of label when modern systems are capable of 10+ levels. It's the exact same process as an mpls tags. So the complexity is equal to 2 MPLS l3vpns. Hopefully no one on your team thought that that would be very burdensome on a new router. Jamie On Mon., May 4, 2026, 9:15 a.m. Shrihari Pandit, <spandit@stealth.net> wrote:
Jamie,
"No new silicon required”, that’s only true because IPv8 is not being forwarded natively. Your actual process is: 1. Packets are encapsulated into IPv4 2. Lookup happens on IPv4 3. IPv8 is resolved via control-plane indirection 4. So the real system is IPv8 to mapping to IPv4 to forwarding.
Which means:
- extra lookup (mapping) - extra state (VRFs / LFIBs) - extra encapsulation - extra operational complexity
IPv8 shifted into the control plane. It reminds me of the original ARPANET days, CPU based routing. If we go down this path, the control planes might all require something like AMD EPYC 9965 (192 cores fyi.) due to PPS rate.
In reference to "loaded into 2 different LFIBs in the silicon". If I understand what you saying: A. Each “IPv8 area/ASN construct” = VRF B. Each mapping = BGP state C. Each path = label / adjacency
These issues still exist, because IPv8 indirectly consumes it:
- TCAM is still consumed (VRF separation not free) - LFIB size grows - BGP table complexity increases - convergence becomes harder
Further, your statement of "if it's passing thru no v8 silicon...." implies that every transit node must do: [perform classification, apply mapping logic, encapsulate]. That's additional pipeline work.
Shrihari Pandit Stealth Communications +1-212-232-2025
On Mon, May 4, 2026 at 1:04 AM Jamie Thain <jamie@one.bm> wrote:
Shrihari,
See every 10 or 11 emails you get one that is at least an argument.
Ipv8 is an area code based system, and the area codes.
When an ipv8 packet arrives at your edge there are only 2 conditions.
The route is destined for you or it's passing thru, and then there are only 2 cases you have ipv8 silicon or you don't.
Ok if it's passing thru no v8 silicon xlate8 looks up it's asnV4 encapsulates it and sends via v4 to that destination.
Ok if it's not passing thru and this is the destination then you have two route tables to be concerned with. Asn 0 and asn my asn say 1234
There are 2 vrfs created on ipv8 configs
ip vrf ipv8-asn-1234 rd 1234:65535
ip vrf ipv4-asn-0 rd 0:65535
So as routes the ipv8 is loaded into 2 different lfibs in the silicon and managed by the ipv4 silicon.
You create the ipv8 overlay by putting it in a vrf until ipv8 silicon is naturally updated.
Then for the main show ipv8 route it looks in bgp statement
include ip vrf ipv8-asn-1234 as asn 1234 Include ip vrf ipv4-asn-0 as ipv4
And shows these routes
There is no new silicon required. From a silicon level "IPv8 is an L3VPN with a globally reserved RD. If your router does L3VPN today — and every SP router does — your router does IPv8 today"
HTH
Jamie
On Sun., May 3, 2026, 10:56 a.m. Shrihari Pandit, <spandit@stealth.net> wrote:
Hi Jamine,
We had internal discussions with our team and are ones that are experienced in economics (wide range of fields, and engineering including CMOS, FPGA, ACIS.)
1. This is what I was told. IPv8 requires two additional lookups. It results in:
- wider parser support - new match/action pipeline design - more TCAM/SRAM slices - larger die area - higher power draw - lower port density - new board designs - new optics/thermal validation - new NOS/SDK support - more heat as result of higher power draw
2. Cost areas:
- New ASIC / merchant silicon design - Router/switch platform redesign - Carrier backbone + edge replacement - Hyperscaler/data-center network - Enterprise/CPE/firewall/load-balancer "refresh" - Software, OSS/BSS, routing stacks, monitoring systems - Testing, certification, migration labour - Operational risk, outages, dual-stack complexity
The approximate numbers to implement are between $500B up to $2T (more realistic number @ $740B)
Cisco describes routing silicon release cycles in the 18–36 month range, which means this is not software patches: src: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fdam%2Fm%2Fdigital%2Felq-cmcglobal%2Fwitb%2FCKN%2F0721_CROSS.pdf&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766028187%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BjKcfisZOfxjuDWES98WHXFfY%2F%2B4xAZ92Wij%2Ba8ZtOE%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fdam%2Fm%2Fdigital%2Felq-cmcglobal%2Fwitb%2FCKN%2F0721_CROSS.pdf&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766077848%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UO2l8nN1wyf%2B%2Fu0bSBn2%2BFjcJgi3gkuaOnymvuPD66I%3D&reserved=0><https://www.cisco.com/c/dam/m/digital/elq-cmcglobal/witb/CKN/0721_CROSS.pdf>
So IPv8 is control-plane cheap and data-plane expensive. The draft needs to account for that. Maybe Trump can allocate $2T to create more jobs, more work. You will need to likely reach out to the NSC. It will take 30 years. If there is forcing event, maybe 10-15 years and that would require the gov to pay all carriers and end-users.
We should stop the discussion here; You should contact the merchant silicon companies to find out the costs and whether two additional lookups are required and are at what costs (actual costs, power draw, heat, etc.)
--- Shrihari 212-232-2025
On Sat, May 2, 2026 at 7:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Kevin
Code is expensive. I want a sense of anything is wrong first.
Dns server needs 10 lines of code. Dhcp server 0, ntp server 100, netlog 1000,
So far mostly people have told me to go F myself.
But it's the economics will win.
Tco = 0
If ipv is compatible If protocol = ipv8 Tco = education + dev time of tools once on all 4 varaint os's + any premiium - (integration savings) - 100,000s per mid size enterprise per year.
Think -100 000 per 1000 employees or so
If protocol = ipv6 Tco = interoperability testing + education + i get my ass fired for using it.
Tco for ipv8 - billions
Tco for ipv6 + billions
On Sat., May 2, 2026, 5:56 p.m. Kevin Tillery via NANOG, < nanog@lists.nanog.org> wrote:
Code is extremely malleable. You are not building a lunar lander. It will not explode, kill three people and humiliate a nation if you get it wrong. You will just observe that it is wrong and change it until it is right.
This gives you plentiful opportunities to discover things for yourself instead of spamming this mailing list with stupid arguments.
For example, if you actually write an IPv8 implementation, you can try connecting it to an IPv4 implementation. You will discover whether it actually works or not. This is infinitely more valuable than an argument.
Justin,
Because before you write a line of code you have to get it right, or near right.
If you want to see good engineering watch from the "Earth to the Moon" Spider, how they built the lunar lander.
So far I've had like 3 serious conversations about "this won't work" and each one has had me improve it. But "go make code" before we discuss what and how it should be, a DRAFT is actually when you want comments about the operation of it all.
I'm not going to wait until I written 1m worth of code to figure something is wrong.
IETF folks suggested to me, that I join Nanog to see how they might use it. IPv8 is not about address space.
Jamie
On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG <nanog@lists.nanog.org> wrote:
> I know of enterprises who are deploying v6. > > Until you can show the world a working IPv8 implementation on a large using > off-the-shelf components where people can run through failure scenarios and > really beat it up, not many people are going to take it seriously. > > Lower layers of the network relying on the functionality of higher layers > is a really, really, really bad idea. > > While it's always important to think about how to so something better, v8 > seems to create a whole bunch of new problems while not solving many
> have already been addressed in v6 and other protocols. > > Thank you > jms > > > > On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG < nanog@lists.nanog.org > [nanog@lists.nanog.org]> > wrote: > > > Andrew, > > > > Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 > > in a meeting and two corp engineers laughed. > > > > You can google it yourself. > > > > Jamie > > > > On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < > > nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote: > > > > > If no corporation is migrating then why is IPv6 traffic continuing to > > > increase? > > > > > > As I pointed out, IPv6 traffic increased 5% last year. At that > > admittedly > > > slow rate, the entire internet will be IPv6 in 10 years. > > > > > > Further your assertion that business is the prime mover is incorrect. > > > Business will move when they have to. That time is coming. > > > > > > When businesses can’t get IPv4 from their providers or superscaler, or a > > > vendor or client can’t reach them, they will move. > > > > > > Andrew > > > > > > > > > > > > On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < > > > nanog@lists.nanog.org [nanog@lists.nanog.org]> > > > wrote: > > > > > > > Andrew, > > > > > > > > The issue is for corporate and the cloud, IPv6 is just as broken as > > IPv4. > > > > > > > > And no corporate is migrating go look. Its been the next big
> > > > Corporate networks for 20 years. > > > > > > > > Jamie > > > > > > > > On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < > > > > nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote: > > > > > > > > > I oppose this. With IPv6 traffic now representing around half of > > > > internet > > > > > traffic, the time to rethink has long passed. > > > > > > > > > > If IPv8 was going to be a solution, it should have been a solution 10 > > > > years > > > > > ago. > > > > > > > > > > In the last 12 months, ~5% of traffic migrated to IPv6. At that > > rate, > > > > IPv6 > > > > > will be fully implemented by 2035. I'm not seeing a
> > needs > > > > to > > > > > be solved, or a credible solution. > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < > > > > > nanog@lists.nanog.org [nanog@lists.nanog.org]> > > > > > wrote: > > > > > > > > > > > Hi All, > > > > > > > > > > > > My name is Jamie Thain I'm the creator of IPv8. It's not a hoax. > > > > > > > > > > > > I joined this list because, as part of IPv8, I am creating a BGPv8. > > > > > Inside > > > > > > BGPv8, two new protocols CF (Cost Factor), weigh cost factors along > > > the > > > > > > routes to produce a better metric. It's a hybrid of EIRGP mixed > > with > > > > BGP > > > > > to > > > > > > create better engineering results. > > > > > > > > > > > > I also as part of CF created Sun Tzu which is the
> > > watches > > > > > CF > > > > > > and gives you a CF score of reliability. Do I trust my
On 2 May 2026 20:05:47 CEST, Jamie Thain via NANOG < nanog@lists.nanog.org> wrote: that thing in problem that protocol that partnership
> > > > with > > > > > > you? > > > > > > > > > > > > Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every > > > problem, > > > > > > etc, etc. That's not my discussion point. My point isn't "should I > > > even > > > > > > propose IPv8" my point is what would be the best result for > > > operators? > > > > > > > > > > > > I believe that since IPv8 solves the duopoly problem, it will > > replace > > > > > > IPv4. > > > > > > > > > > > > So the things to know, IPV8 is NOT a 64 bit addressing system. > > > > > > > > > > > > It is a 32 bit routing system with a 32 bit addressing system. > > > > > > > > > > > > A Routing Number = ASNs plus others. > > > > > > > > > > > > 8.8.8.8 would become 15169.8.8.8.8 > > > > > > > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-thain-ipv8-02.html&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766110348%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AMAod6WLS%2BEWbmSrZ5jJDCyYhjCmUyBIE2dgEF8FM20%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-thain-ipv8-02.html&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766134099%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pek%2BNihitXd%2BkeD56IUexLQ%2BZzba2h8b26VwcoWSdp8%3D&reserved=0><https://www.ietf.org/archive/id/draft-thain-ipv8-02.html> > [https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-thain-ipv8-02.html&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766155242%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uXp8xWHkgFsMkZll8Be%2FwQ8DRpqwI8TDRcNjX1J7o0Q%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-thain-ipv8-02.html&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766178026%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EZUL2%2FYj3lRR4YwEj%2BuCyAVGk8Pcc4I7ZWJkJi4amek%3D&reserved=0<https://www.ietf.org/archive/id/draft-thain-ipv8-02.html>>] > > > > > > < > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl.shortlink.es%2Fl%2F3ae384c1b8e2eb92749595407c5cf9b87ea&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766199632%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ose3CUtncpgo18%2FI1Pab7edmtST%2FMisizMzoHAVMnik%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl.shortlink.es%2Fl%2F3ae384c1b8e2eb92749595407c5cf9b87ea&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766229041%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=E1hM1lEtan5irKUCYIZxpAvmKEXkR38ySvBd4Scby%2B4%3D&reserved=0><https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea> > [https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl.shortlink.es%2Fl%2F3ae384c1b8e2eb92749595407c5cf9b87ea&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766256224%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2B6YdC12F6ShQ%2FlmkV%2BzfafKtVdu5KLBU9nDeS7Eif70%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl.shortlink.es%2Fl%2F3ae384c1b8e2eb92749595407c5cf9b87ea&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766282241%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3KukjNuLpbshnoS6YH2G%2Fj8nIzfagcfs5kjrhZ2KPLk%3D&reserved=0<https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea>>] > > > > > 3372a?u=12457652 > > > > > > > > > > > > > > > > > > > > > > > > > So each ASN in the world will have 3 Billion available addresses. > > > > > > > > > > > > There is a specially reserved group of internal ASN 127.x.x.x so > > each > > > > > corp, > > > > > > org, has 16 Million areas of 3 Billion addresses, to replace > > 10.x.x.x > > > > and > > > > > > 100.64.x.x.x > > > > > > > > > > > > I'd appreciate your thoughts on it > > > > > > > > > > > > Jamie > > > > > > _______________________________________________ > > > > > > NANOG mailing list > > > > > > > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766308852%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OqkSR8ne8%2Fru1m34weriovLb8bf20GXjS2ya6qf9hYE%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766336251%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aOav44eqiApU3wQR6TnQHPAdM26G%2FT5ugoNeUGwZ17g%3D&reserved=0><https://lists.nanog.org/archives/list/nanog@lists.nanog.org/> > [https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766366974%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JK%2FyKXgRiSd6FKLMnFvouPdSgOX%2FqXjx2hqpy0Ab5Es%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766397821%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yx5rQVRsMLzKsRxH6NZZ1Ef8gbmdLNc34Hl9rTGcnCE%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/>>] > > > > > message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/ > > > > > > > > > > > _______________________________________________ > > > > > NANOG mailing list > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766667270%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=p6RDBpTI4pi2Oo7E3o4%2B4Cuz9GMG5Wg7pV9nZW3o%2Br0%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766710334%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=j5EvFv3Bf%2FdE%2BNLO82FJ6XXkanrAOvI2Z8qhr3HLszY%3D&reserved=0><https://lists.nanog.org/archives/list/nanog@lists.nanog.org/> > [https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766743751%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=K3sj8l6vaQjxN8RZF1xwtoRUeCnOZdw3egTLP%2FlMJ6M%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766773575%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SoWsxDSTCTMp6xA7CFxzIfJv4OYP%2Bayhb6DfpQzZzTo%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/>>] > > > > > message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/ > > > > _______________________________________________ > > > > NANOG mailing list > > > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766801950%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4ttZDeqs6BvPtkiV0RbQGNoRuhaaAuYj2FxnVb0B%2F58%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766828500%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BCRl5Nmveohzwor7mFecFSqIjnYfeft40TxpnFNyp%2BE%3D&reserved=0><https://lists.nanog.org/archives/list/nanog@lists.nanog.org/> > [https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766852619%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OZG14m7Z%2FijtT2w7sk0%2Fw1h%2BCpzucXcZlOTGVotT9zE%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766879463%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fIF1WLBF3Pl7jt1xcFX0zftvVfGNjW6MW2uEx5JLt1w%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/>>] > > > message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/ > > > _______________________________________________ > > > NANOG mailing list > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766901872%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Spl%2FwUgNE9Y4wJ4fTJDjiiGxFjhmMeQAAVelAY0GpKU%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766922187%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tVBpsMjgVfe2p94Oy4rMSTCFv58aMF54UokBqbX5iWY%3D&reserved=0><https://lists.nanog.org/archives/list/nanog@lists.nanog.org/> > [https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766942010%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KGbAlLmovnqIAFip%2BSs2TpSTfTtlfPDkMJpRpXZeocI%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766962463%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=P4U1SvaKqbMHd9RYfwm0BT4hMlLiY4F3y0P%2FXO%2FAFmw%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/>>] > > > message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/ > > _______________________________________________ > > NANOG mailing list > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340766984686%7CUnknown%7CTWFpbGZsb3d8eyJFb<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/>XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6bsPVLRKjTUe5xj2lEZtilGjZDj7hU4Qom6mbdoHotY%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340767024051%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=H%2BMPSCpimOiFWj%2BfDrgBrs6nN6Qxsxv4G%2BkrDWm5Coc%3D&reserved=0> > message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/ > [
]
> _______________________________________________ > NANOG mailing list > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340767090249%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ieo4qyBoSrODDlmNHSlWI3QVap5%2B8DgnY3WBipFXfaA%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340767110535%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EJ6wkGm2duW6%2BJiVPci8Pq21rDXFcrtNLCmlkR8WpBw%3D&reserved=0><https://lists.nanog.org/archives/list/nanog@lists.nanog.org/> > message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/ > [
]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
_______________________________________________ NANOG mailing list
_______________________________________________ NANOG mailing list
NANOG mailing list https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FLUGDFTDETO3FNPXL3FUQDTH6YJU3OWCC%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340767339371%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Oljn6kVDqkS61qa0IaORIwwKY2NOAVebq8qCfLnmFKI%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FLUGDFTDETO3FNPXL3FUQDTH6YJU3OWCC%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340767362118%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UNmFPkm5foKn5mYk31ErGjILyECYXjLcjTA69L23v%2Bs%3D&reserved=0><https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LUGDFTDETO3FNPXL3FUQDTH6YJU3OWCC/> _______________________________________________ NANOG mailing list https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FJZ7PQIAMZ7N4WQISEIEAZJLZESVGPC36%2F&data=05%7C02%7Cryan%40rkhtech.org%7C07395af7d8f24650973c08deaa34c156%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639135340767380952%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lst%2Bxbp%2Bxzx%2Feub6F2W7MEC8k73VphsC%2BlPc4XtUzow%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JZ7PQIAMZ7N4WQISEIEAZJLZESVGPC36/>
* Ryan Hamel via NANOG [Tue 05 May 2026, 19:16 CEST]:
I want to clarify what I said yesterday evening. I was speaking as myself there and not issuing any official Moderation Committee action. No one is or was being censored; no posts were removed, and no one is prohibited from continuing the discussion on-list. Signing that email with my Moderation Committee title made the message read more formally than I intended, and it blurred the line between a personal recommendation and committee action. I apologize for my mistake there.
I'm hereby declaring my intention to run for Supreme Ruler of the NANOG Moderation Committee. Once elected and elevated to that position my first action will be to institute a shadow mailing list called nanog-1d10ts. All posts from certain subscribers are redirected there instead of to the main list. Whoever started this thread's name will be the first addition to that list. Nobody will be any the wiser because no candidate for that list has the technical ability to read mail headers and the main list will be blissfully peaceful again. -- Niels.
I'm hereby declaring my intention to run for Supreme Ruler of NANOG
<snip>
Nobody will be any the wiser because no candidate for that list has the technical ability to read mail headers and the main list will be blissfully peaceful again.
ROTFL. You have my vote. :)
Hi Guys, 1. I am working at funding a protype. 2. I was hoping to get a discussion on what you would fix about bgp. 3. People pointed out i couldn't ignore silicon. No need to continue, i don't think we're going to gain point 2. I'm getting a lot of support from others. Jamie On Tue., May 5, 2026, 11:29 a.m. Eric Germann, <ekgermann@semperen.com> wrote:
This thread should die, but if we’re going to drag it on, Jamie, can you please trim the thing. We’re at least 13 levels deep on quoted emails.
-- Eric Germann ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com LinkedIn: https://www.linkedin.com/in/ericgermann Medium: https://ekgermann.medium.com Twitter: @ekgermann Telegram || Signal || Skype || WhatsApp || Phone +1 {dash} 419 {dash} 513 {dash} 0712 Fax: +1(dash}234{dash}678{{dash}4863
GPG Fingerprint: 89ED 36B3 515A 211B 6390 60A9 E30D 9B9B 3EBF F1A1
IPv6 adoption for ISPs and OTTs are very high (all examples below are from these segments). ISPs have reduced IPv6 to something extremally simplified (cancelled all 1st hop complexity) - it is not IPv6 anymore. OTTs are capable to handle IPv6 enormous complexity. I believe that IPv6 would never win on the Enterprise market despite I have heard examples of adoption (I have heard about a few cases of downgrade too) - the first hop complexity would block it. Hence, I believe that mankind would stay with IPv4 + NAT for many decades on the business side. "IPv6 for people, IPv4 for businesses". IPv6 is a big fail of IETF procedures. But not everything in this world is possible to fix. IMHO: IPv8 would not happen too. May be in the next century and only if new principal requirements would appear. LEO had a chance to be such a driver (to replace IPv6). But LEO carriers decided to hide all complexity below IP level (like 3GPP did). Eduard
-----Original Message----- From: Raymond Burkholder via NANOG <nanog@lists.nanog.org> Sent: Tuesday, May 5, 2026 18:37 To: nanog@lists.nanog.org Cc: Raymond Burkholder <ray@oneunified.net> Subject: Re: IPv8 / BGP8 / CF
On 2026-05-05 09:33, Eric Germann via NANOG wrote:
I believe Microsoft uses IPv6 internally, at least that’s what I read a long time ago
Plus all the cell phone providers (even the Canadian ones), plus many/some big ISPs, I think I heard ComCast (millions of subscribers) is on IPv6. Plus Asia runs on IPv6, if I heard correctly.
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/UN54F3 HBWO3TZZKHEDK7OCBPQUPFCWJQ/
Jamie, No one, and I mean no one in corp (that's not a super scalar) knows anything about ipv8 and no one and i mean no one cares. It's not even in their os. Kevin On 05/05/2026 00:27, Jamie Thain wrote:
Kevin,
I can't fix ipv6 I'll leave that to people that understand the basics.
No one, and i mean no one in corp (that's not a super scalar) knows anything about ipv6 and no one and i mean no one cares.
They know it's on in there os and there's some mystery that some things will break if it's off.
Jamie
On Mon., May 4, 2026, 2:27 p.m. Kevin Tillery via NANOG, <nanog@lists.nanog.org> wrote:
Jamie
And ipv8 is no where on there radar. So fix ipv6.
I appreciate your input.
Kevin
On 4 May 2026 08:26:33 CEST, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote: >Marco > >And ipv6 is no where on there radar. So fix ipv4. > >I appreciate your input. > >Jamie > >On Sun., May 3, 2026, 4:33 a.m. Marco Moock via NANOG, < >nanog@lists.nanog.org> wrote: > >> Am 03.05.26 um 00:30 schrieb Jamie Thain via NANOG: >> > >> > * IPv6 wasn't a surgical fix for address exhaustion — it bundled the >> > address-space change with a full redesign of neighbor discovery, >> > autoconfiguration, header structure, and operational tooling. >> >> That wasn't the issue. The issue is that it takes some time to prepare >> and do the implementation of another network protocol, regardless how it >> is called or how it works in detail. No one cares about ARP, nor NDP. It >> is there and works. >> >> Corporate networks need address plan, firewall plans etc. and that needs >> to be extended if any new protocol is going to be implemented. >> >> -- >> Gruß >> Marco >> >> Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de >> _______________________________________________ >> NANOG mailing list >> >> https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LZX6VCZU... >_______________________________________________ >NANOG mailing list >https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AVIU5UM7... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MPYN6YGE...
Subject: Re: IPv8 / BGP8 / CF - just build it Date: Tue, May 05, 2026 at 05:37:39PM -0400 Quoting Jamie Thain via NANOG (nanog@lists.nanog.org):
I'm getting a lot of support from others.
"lurkers support me in email" Those who know, know. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Do you like "TENDER VITTLES"?
Em ter., 5 de mai. de 2026 às 14:33, niels=nanog--- via NANOG <nanog@lists.nanog.org> escreveu:
* Ryan Hamel via NANOG [Tue 05 May 2026, 19:16 CEST]:
I want to clarify what I said yesterday evening. I was speaking as myself there and not issuing any official Moderation Committee action. No one is or was being censored; no posts were removed, and no one is prohibited from continuing the discussion on-list. Signing that email with my Moderation Committee title made the message read more formally than I intended, and it blurred the line between a personal recommendation and committee action. I apologize for my mistake there.
I'm hereby declaring my intention to run for Supreme Ruler of the NANOG Moderation Committee. Once elected and elevated to that position my first action will be to institute a shadow mailing list called nanog-1d10ts. All posts from certain subscribers are redirected there instead of to the main list. Whoever started this thread's name will be the first addition to that list. Nobody will be any the wiser because no candidate for that list has the technical ability to read mail headers and the main list will be blissfully peaceful again.
-- Niels. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZXSZUICA...
first action will be to institute a shadow mailing list called nanog-1d10ts. ...
So you're reactivating NANAE? @Jamie This is the internet my man. You don’t ask people how to do things; you just tell them what you’re going to do, and people will bend over backwards to show you how wrong you are and how this and that would be better. With luck, you can make a PhD thesis out of it. Honestly, many of the people replying to you might be doctors themselves. Afterwards, ingest all of that into ChatGPT(tm) and come back with a better, improved, foolproof plan. -- -Karlin
Most corporate environments don’t mandate DNS, and certainly don’t put a firewall between every segment. Shane
On Apr 30, 2026, at 7:05 PM, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Richard,
Wolfy did write about but he didn't ask me any details.
64 Bit headroom -- IPv8 is not headroom, it is about adding an AREA code to 32 bit addressing, its not 64 bit at all. So to put it in perspective rather than enough ip address for every atom in the solar system there is only enough for ever square cm on the planet to have 4 ip address.
DNS + WHOis Validation is meant to increase north south security. You cannot get to an ip address that doesn't have whois, and dns in strict mode. Of course you can turn that off.
VPN survive functions... Zone Server doesn't track who opened what and when. It doesn't track the DNS lookups it tracks performance, and errors. How ever every corporate fw tracks this.
Rate Limits turn Zone Server into a single point of failure... except for you can have as many zone servers as you need to be reliable. They come in pairs anyways. Its like losing your DNS server.
Rate Elevation inside a company requires you to sign into the corporate networks, that way guests can't harm you.
No Flag day is true, you can start with one card, and one router somewhere on the internet and grow from there.
Wolfy thinks that policy egress isn't already being managed in firewalls.
Oauth2 is being used as an authorization and configuration policy replacing clear-text RADIUS.
The draft doesn't violate RFC 7258 as already your work is monitoring you. And at home your in control of your own Zone Server, Zone Server doesn't log packets, just errors
*The draft assumes unlimited data storage and doesn’t care.* No it doesn't we only report errors, and performance every five minutes and accounting where required the third A of a radius server. A 1000 person company would be less than a 100G per month. 2 years on a single drive.
it doesn't log, dns, or flow, thats all a different device called SIEM or a FW, or a NetFlow none of which NetLog does.
*Mandatory identity binding eliminates hardware anonymity by default.* OAuth2 JWT binds to the device at the NIC level before any user interaction
This is true, it is built for corporate, the network card is usually following a person around, its built so you can roam from network to network.
*The anonymity eliminated is at the layer hardest to restore.* Me thinks wolfy has never looked at a fortigate log, it correlates, MAC address, last ip, every flow, the last logged in, logged in to what networks, all in a handy dandy report manager.
*Device-to-traffic attribution becomes a database query, not an investigation.*Me thinks wolfy has never reviewed online firewall logging.
*NIC firmware rate limits make the network unusable without Zone Server permission.*
This is the broadcast rate so unathenticated users can't DDOS
*This architecture is fail-closed, and that can kill people.*
Each network segment can be dns-only and have no other restrictions and you need DNS to get from ipv4 to ipv8 there is no other way in the eco system.
*IPv8 is fundamentally incompatible with real-time operating systems *
IPv8 is 100% ipv4 compatible at the segment level, use IPv4 if you don't want the overhead of IPv8.
*All of the stuff about blocking*Its like wolfy has never admined a modern day firewall, you can do all that stuff already.
Enough said.
On Thu, Apr 30, 2026 at 5:18 PM Rich Kulawiec via NANOG < nanog@lists.nanog.org> wrote:
When this was floated on various IETF mailing lists, someone took the time to write:
We Need to Talk About the IPv8 Draft - wolfy https://substack.com/home/post/p-194315405
---rsk _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QD6JBVII...
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TUSOARZ2...
Andre, Have you read it ? The point about LLMs is not to reinforce ideas but to be a research tool. What i haven't seen is any basis in merit of the idea. I come from a different generation and a different side of the firewall. I am trying to solve the big 3 problems 1. Network management 2. Operations 3. Address management. And maybe you think this is a problem that doesn't need solving really. But i can also tell you I've also been getting a tremendous amount of support that it's a good idea. I'm trying to fix bgp problems that have existed for a long time. I'm trying to be backwards compatible at the FIB level. So i don't care about ipv6 because I'm not about address exhaustion and behind the corp firewalls there is no IPv6 to be hardly measured. It's not an accident you can't get anybody to want it upgrade. It was great to be so welcomed on basically what I was asking What can we do to improve BGP and the answer is it's great right now. Go away Jamie On Thu., Apr. 30, 2026, 8:21 p.m. Andre Sencioles via NANOG, < nanog@lists.nanog.org> wrote:
Dear Jamie,
Stop talking to LLMs. No, seriously. Stop NOW! LLM models WILL NOT tell you are wrong, they will keep reinforcing your beliefs to keep you wasting tokens. This is what the models were "trained" to do.
You are showing all signs of going down a sycophantic loop with a delusional LLM. You are not the first one, and you won't be the last. I urge you to go and read this: https://techcrunch.com/2025/10/02/ex-openai-researcher-dissects-one-of-chatg... But really ready it! Don't ask for a summary, or tell your agents to extract the key points. Use your MK1 eyeballs.
Now, after reading that carefully, think about this: You have a whole community of experienced network engineers telling you are wrong in the most fundamental ideas of your design.
Ask yourself: Have I maybe got a bit too excited with my LLM sessions and forgot to do some critical thinking? Am I so out of touch? Or is it the children that are wrong?
With the best of intentions, Andre _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TI4B6LGZ...
"Andre's point here is 100% correct. This thread should probably die now." [[[[[[ Drops the mic ]]]]]] Seriously, for all we know this is some AI LLM model we are reading, waste of time. There is no need for IPv8 nonsense. We are just getting IPv6 going. On Thu, Apr 30, 2026 at 7:23 PM Andrew Kirch via NANOG <nanog@lists.nanog.org> wrote:
Andre's point here is 100% correct. This thread should probably die now.
Andrew
On Thu, Apr 30, 2026 at 7:21 PM Andre Sencioles via NANOG < nanog@lists.nanog.org> wrote:
Dear Jamie,
Stop talking to LLMs. No, seriously. Stop NOW! LLM models WILL NOT tell you are wrong, they will keep reinforcing your beliefs to keep you wasting tokens. This is what the models were "trained" to do.
You are showing all signs of going down a sycophantic loop with a delusional LLM. You are not the first one, and you won't be the last. I urge you to go and read this: https://techcrunch.com/2025/10/02/ex-openai-researcher-dissects-one-of-chatg... But really ready it! Don't ask for a summary, or tell your agents to extract the key points. Use your MK1 eyeballs.
Now, after reading that carefully, think about this: You have a whole community of experienced network engineers telling you are wrong in the most fundamental ideas of your design.
Ask yourself: Have I maybe got a bit too excited with my LLM sessions and forgot to do some critical thinking? Am I so out of touch? Or is it the children that are wrong?
With the best of intentions, Andre _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TI4B6LGZ...
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FSK3HBWI...
If your primary usage is in corporate networks behind the firewall, why do you need BGP? And if you are getting lots of support, can you name the independent supporters of this proposal? Shane
On Apr 30, 2026, at 9:05 PM, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Andre,
Have you read it ?
The point about LLMs is not to reinforce ideas but to be a research tool.
What i haven't seen is any basis in merit of the idea.
I come from a different generation and a different side of the firewall.
I am trying to solve the big 3 problems
1. Network management 2. Operations 3. Address management.
And maybe you think this is a problem that doesn't need solving really.
But i can also tell you I've also been getting a tremendous amount of support that it's a good idea.
I'm trying to fix bgp problems that have existed for a long time.
I'm trying to be backwards compatible at the FIB level.
So i don't care about ipv6 because I'm not about address exhaustion and behind the corp firewalls there is no IPv6 to be hardly measured.
It's not an accident you can't get anybody to want it upgrade.
It was great to be so welcomed on basically what I was asking What can we do to improve BGP and the answer is it's great right now.
Go away
Jamie
On Thu., Apr. 30, 2026, 8:21 p.m. Andre Sencioles via NANOG, < nanog@lists.nanog.org> wrote:
Dear Jamie,
Stop talking to LLMs. No, seriously. Stop NOW! LLM models WILL NOT tell you are wrong, they will keep reinforcing your beliefs to keep you wasting tokens. This is what the models were "trained" to do.
You are showing all signs of going down a sycophantic loop with a delusional LLM. You are not the first one, and you won't be the last. I urge you to go and read this: https://techcrunch.com/2025/10/02/ex-openai-researcher-dissects-one-of-chatg... But really ready it! Don't ask for a summary, or tell your agents to extract the key points. Use your MK1 eyeballs.
Now, after reading that carefully, think about this: You have a whole community of experienced network engineers telling you are wrong in the most fundamental ideas of your design.
Ask yourself: Have I maybe got a bit too excited with my LLM sessions and forgot to do some critical thinking? Am I so out of touch? Or is it the children that are wrong?
With the best of intentions, Andre _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TI4B6LGZ...
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BGV2ANJ4...
Subject: IPv8 / BGP8 / CF Date: Wed, Apr 29, 2026 at 02:03:34PM -0500 Quoting Jamie Thain via NANOG (nanog@lists.nanog.org):
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
But it is bad nevertheless. 1. The only thing that will come out of any roll-out is tri-stack. Which is kinda embarrasing for a draft that criticizes dual-stack. 1.bis. The end result of (1) is that IPv6 deployment and IPv4 sunsetting are delayed further, prolonging the dual-stack pain. 2. The construction with so many fascinating moving pieces, some crypto related, combined with a good portion of state in middle boxes is an architectural and scaling disaster. 3. Reliability will suffer for critical communiations as a consequence of (2). 4. The people who want to see and limit our traffic will have a field day by mandating and getting access to the middle boxes. Put IPv6 on something instead, and be done with it. It works, it is easier, and there are enough addresses. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 My life is a patio of fun!
On Fri, May 1, 2026 at 1:30 AM Måns Nilsson via NANOG <nanog@lists.nanog.org> wrote:
Subject: IPv8 / BGP8 / CF Date: Wed, Apr 29, 2026 at 02:03:34PM -0500 Quoting Jamie Thain via NANOG (nanog@lists.nanog.org):
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
But it is bad nevertheless.
2. The construction with so many fascinating moving pieces, some crypto related, combined with a good portion of state in middle boxes is an architectural and scaling disaster.
They probably could have gotten some serious VC a few years ago with "It's like bitcoin but it will run the whole internet." Andrew
nanog@lists.nanog.org (Andrew Kirch via NANOG) wrote:
2. The construction with so many fascinating moving pieces, some crypto related, combined with a good portion of state in middle boxes is an architectural and scaling disaster.
They probably could have gotten some serious VC a few years ago with "It's like bitcoin but it will run the whole internet."
The "concept" is the wet dream of oligarchs wanting to control and run the world, and milk everybody else for data and money. We are getting bogged down in the technical discussion - as we should, since this is predominantly a technical forum -, but the societal implications of this LLM-fueled scheme are truly nightmarish. Elmar. PS: Btw, this is exactly the plan LLMs that gained sentience would try to push...
Am 30.04.26 um 22:22 schrieb Gary Sparkes via NANOG:
Much simpler just to NAT between A B C D and E's networks and do gradual segment renumbering, and much less infrastructure/hardware to do so as well.
That is a PITA. In certain cases you want interconnection between the systems and then the NAT is just another annoying thing in the process. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Måns Nilsson via NANOG wrote on 01/05/2026 06:30:
2. The construction with so many fascinating moving pieces, some crypto related, combined with a good portion of state in middle boxes is an architectural and scaling disaster.
I recognise this: RFC 1925, section 5:
(5) It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
Also, see sections 4, 6, 6a, 7, 7a, 8 and in particular, sections 11 and 11a:
(11) Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
(11a) (corollary). See rule 6a.
There's nothing new about locator/identifier protocols. We have LISP today, and it works to some degree. It doesn't scale, but sometimes it's good to design, document and build this style of architecture, even if only to show that it doesn't scale. Which bring the discussion back to RFC1925: "it's always something". There's no such thing as a free lunch. In the case of this so-called "ipv8" idea, it's defining a new protocol with a larger address size in the packet header, which despite claims like "I'm trying to be backwards compatible at the FIB level" is not backwards compatible at the FIB layer, and never will be. It will require silicon redesigns, and retooling IP communication stacks to handle the new protocol spec. Sure, there's an indirection layer, but that's not the same thing as backwards compatible. Maybe a better term would be "interoperable to some extent in specific circumstances. T&Cs apply". Skimming around on some randomly-selected text:
Second, the destination ASN is validated against the WHOIS8 registry -- if the destination prefix is not registered as an active route by a legitimately registered ASN holder the packet is dropped. These two steps together eliminate the primary malware command-and-control channel: connection to hardcoded IP addresses without DNS resolution.
The author really needs to think about this a bit harder. or this:
A route that cannot be validated is not installed.
Refusing to install non-validated routes might look like a good idea from a superficial point of view, but all it does is show that the author hasn't thought very hard about the consequences. For example, how do you handle network cold start, i.e. non-primed caches? What happens if your cache session disappears? Low level protocols sit at the bottom of the networking stack. Things are different there and you can't depend on stuff higher up in the stack working the way you might expect it to, because the higher-up stuff only works when the lower-down stuff has established connectivity. If you confuse this, it ends in tragedy. Or there's this:
IPv8 extends OSPF8 [RFC2328], BGP8 [RFC4271] (both iBGP8 and eBGP8), and IS-IS8 with a unified path quality metric -- the Cost Factor (CF).
CF is a 32-bit accumulated metric derived from seven components measured from TCP session telemetry: round trip time, packet loss, congestion window state, session stability, link capacity, economic policy, and geographic distance as a physics floor.
There's some fundamental confusion going on in this paragraph about routing protocols. For starters, it's a bit odd to suggest that you can distill seven separate and entirely independent parameters plucked arbitrarily from multiple different layers up the protocol stack, and somehow flatten them into a single linear 32 bit integer in a way that preserves any meaning. And why seven metrics? Why not eight, in order to include my favourite metric which is missing? Or nine, to include someone else's favourite metric. And how are they calculated? It's really hard to look at a list like this without wondering if it's network design or numerology. That's ignoring the fact that is-is/ospf are link state protocols and ibgp is distance vector, i.e. they do different things in specific contexts. Or this:
For a neighbor recorded as IPv8-capable, the sender constructs a full IPv8 packet:
Where is the definition of the neighbor discovery and capabilities protocol which allows hosts to record which devices are "IPv8-capable"? These are all things randomly plucked out of the text on the basis of: "let's scroll down a couple of pages and see what's written there". I haven't seen anything worth salvaging in the doc. To be honest, I haven't read the entire doc because the bits that I've read look more like they were thrown together on the basis of "this seems like a good idea; into the pot you go". This isn't how protocol design works. Nick
On Fri, 1 May 2026 at 16:57, Nick Hilliard via NANOG <nanog@lists.nanog.org> wrote:
There's nothing new about locator/identifier protocols. We have LISP today, and it works to some degree. It doesn't scale, but sometimes it's good to design, document and build this style of architecture, even if only to show that it doesn't scale.
QUIC is actually a location/identifier, sometimes even supported by the implementation. -- ++ytti
Sure, but IPv8 proposes the same thing essentially - with EXTRA infrastructure -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Friday, May 1, 2026 3:01 AM To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: IPv8 / BGP8 / CF Am 30.04.26 um 22:22 schrieb Gary Sparkes via NANOG:
Much simpler just to NAT between A B C D and E's networks and do gradual segment renumbering, and much less infrastructure/hardware to do so as well.
That is a PITA. In certain cases you want interconnection between the systems and then the NAT is just another annoying thing in the process. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZMPWHIAQ...
Lucien, I see no need for this IPv8. IPv6 was carefully engineered over many years and while not perfect, works and is deployed. What problem are you trying to solve? I seem to have missed that. As per my draft. 1. Management 2. Operation 3. IP Exhaustion. IPv6 adoption is low in corporate networks. They've had 30 years to adopt it, they are not going to. The reason is simple. "No one ever got fired for sticking with IPv4." Most IT people in the corporate world are "do no harm," "there are no bonuses," and "don't break things" mindset; therefore, there is simply no impetus to replace what is in front of them. There is no address exhaustion, and IPv6 worsens the problems they have with IPv4. IPv6 makes things worse. Literally. But there is a big problem with 10.x.x.x cross over, and hiding behind nats, and hierarchical need for the cloud. When IPx was invented the cloud was was the picture on Windows 95. But the real killer is two things. IPv6 isn't a low cost upgrade, and the enterprise is always going to need IPv4. So for the enterprise at least, build something built for the cloud. 1. Its easy -- every one has an ASN number. 2. Its backwards compatible. It is not IPvX with 64 bits it is [AREA CODE -- RN] + IPv4. 3. There is no new infrastructure to build. It has several components A Zone Server which is a combination of DHCP / DNS / NTP / (A web server Oauth and JWT replacing Radius) and NetLog Errors and PErformance only) A slightly improved PF Sense. These parts fully exist DNS / Anycast and VRFs. 4. It will be a firmware upgrade. 5. The internal Zone 127.x.x.x allows for 16 million zones per what ever -- with 4 Billion addresses each, and then you need to NAT again. It fixes almost every super-scalar behind the nat, collision problem. Operations ... IP exahustion. Each ASN gets 3 Billion addresses. Bad Routes. There are no bad IPv8 routes. Routing is achived by sending packets to the R.R.R.R or short form ASN. area code, and checked at ingress, and if the route isn't inside the ASN it sends back rate limited ICMP "no route available" So IPv8 is IPv4 V2 What do you think now? On Thu, Apr 30, 2026 at 1:45 PM Lucien Hoydic via NANOG <nanog@lists.nanog.org> wrote:
I see no need for this IPv8. IPv6 was carefully engineered over many years and while not perfect, works and is deployed. What problem are you trying to solve? I seem to have missed that.
No one is going to adopt IPv8. This is an academic discussion at best.
On Thursday, April 30th, 2026 at 10:51 AM, Joe Klein via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]
wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/QAQPQMJT3AEGHZERA2XJW3WIWBAMHBAI/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QAQPQMJT...]
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/YAH63OJ4IJ3GKNROAILZHO6YXQQ5NQ2S/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YAH63OJ4...]
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/WWUAVWF5VUGLB7FCE6NE4LAMOGPDM7LP/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/WWUAVWF5...]
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/HTZGUHK5OFQTIOM4PGETYTNEUIWPDEDW/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HTZGUHK5...]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
Andrew, The issue is for corporate and the cloud, IPv6 is just as broken as IPv4. And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years. Jamie On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < nanog@lists.nanog.org> wrote:
I oppose this. With IPv6 traffic now representing around half of internet traffic, the time to rethink has long passed.
If IPv8 was going to be a solution, it should have been a solution 10 years ago.
In the last 12 months, ~5% of traffic migrated to IPv6. At that rate, IPv6 will be fully implemented by 2035. I'm not seeing a problem that needs to be solved, or a credible solution.
Andrew
On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
I joined this list because, as part of IPv8, I am creating a BGPv8. Inside BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to create better engineering results.
I also as part of CF created Sun Tzu which is the protocol that watches CF and gives you a CF score of reliability. Do I trust my partnership with you?
Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, etc, etc. That's not my discussion point. My point isn't "should I even propose IPv8" my point is what would be the best result for operators?
I believe that since IPv8 solves the duopoly problem, it will replace IPv4.
So the things to know, IPV8 is NOT a 64 bit addressing system.
It is a 32 bit routing system with a 32 bit addressing system.
A Routing Number = ASNs plus others.
8.8.8.8 would become 15169.8.8.8.8
https://www.ietf.org/archive/id/draft-thain-ipv8-02.html < https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea 3372a?u=12457652
So each ASN in the world will have 3 Billion available addresses.
There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x
I'd appreciate your thoughts on it
Jamie _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/
That's from your perspective. F100 adoption is higher than you think. -----Original Message----- From: Jamie Thain via NANOG <nanog@lists.nanog.org> Sent: Friday, May 1, 2026 11:11 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Jamie Thain <jamie@one.bm> Subject: Re: IPv8 / BGP8 / CF Lucien, I see no need for this IPv8. IPv6 was carefully engineered over many years and while not perfect, works and is deployed. What problem are you trying to solve? I seem to have missed that. As per my draft. 1. Management 2. Operation 3. IP Exhaustion. IPv6 adoption is low in corporate networks. They've had 30 years to adopt it, they are not going to. The reason is simple. "No one ever got fired for sticking with IPv4." Most IT people in the corporate world are "do no harm," "there are no bonuses," and "don't break things" mindset; therefore, there is simply no impetus to replace what is in front of them. There is no address exhaustion, and IPv6 worsens the problems they have with IPv4. IPv6 makes things worse. Literally. But there is a big problem with 10.x.x.x cross over, and hiding behind nats, and hierarchical need for the cloud. When IPx was invented the cloud was was the picture on Windows 95. But the real killer is two things. IPv6 isn't a low cost upgrade, and the enterprise is always going to need IPv4. So for the enterprise at least, build something built for the cloud. 1. Its easy -- every one has an ASN number. 2. Its backwards compatible. It is not IPvX with 64 bits it is [AREA CODE -- RN] + IPv4. 3. There is no new infrastructure to build. It has several components A Zone Server which is a combination of DHCP / DNS / NTP / (A web server Oauth and JWT replacing Radius) and NetLog Errors and PErformance only) A slightly improved PF Sense. These parts fully exist DNS / Anycast and VRFs. 4. It will be a firmware upgrade. 5. The internal Zone 127.x.x.x allows for 16 million zones per what ever -- with 4 Billion addresses each, and then you need to NAT again. It fixes almost every super-scalar behind the nat, collision problem. Operations ... IP exahustion. Each ASN gets 3 Billion addresses. Bad Routes. There are no bad IPv8 routes. Routing is achived by sending packets to the R.R.R.R or short form ASN. area code, and checked at ingress, and if the route isn't inside the ASN it sends back rate limited ICMP "no route available" So IPv8 is IPv4 V2 What do you think now? On Thu, Apr 30, 2026 at 1:45 PM Lucien Hoydic via NANOG <nanog@lists.nanog.org> wrote:
I see no need for this IPv8. IPv6 was carefully engineered over many years and while not perfect, works and is deployed. What problem are you trying to solve? I seem to have missed that.
No one is going to adopt IPv8. This is an academic discussion at best.
On Thursday, April 30th, 2026 at 10:51 AM, Joe Klein via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]
wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/QAQPQMJT3AEGHZERA2XJW3WIWBAMHBAI/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q AQPQMJT3AEGHZERA2XJW3WIWBAMHBAI/]
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/YAH63OJ4IJ3GKNROAILZHO6YXQQ5NQ2S/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Y AH63OJ4IJ3GKNROAILZHO6YXQQ5NQ2S/]
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/WWUAVWF5VUGLB7FCE6NE4LAMOGPDM7LP/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/W WUAVWF5VUGLB7FCE6NE4LAMOGPDM7LP/]
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/HTZGUHK5OFQTIOM4PGETYTNEUIWPDEDW/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/H TZGUHK5OFQTIOM4PGETYTNEUIWPDEDW/]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D] _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6C32XCBT...
4. It will be a firmware upgrade.
64-bit addressing will mean CPU bound processing without any silicon forwarding. That "area code" is part of the entire address. I cannot forward without knowing it. It's a core part of the address. At least, for any globally routing scenario. -----Original Message----- From: Jamie Thain via NANOG <nanog@lists.nanog.org> Sent: Friday, May 1, 2026 11:11 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Jamie Thain <jamie@one.bm> Subject: Re: IPv8 / BGP8 / CF Lucien, I see no need for this IPv8. IPv6 was carefully engineered over many years and while not perfect, works and is deployed. What problem are you trying to solve? I seem to have missed that. As per my draft. 1. Management 2. Operation 3. IP Exhaustion. IPv6 adoption is low in corporate networks. They've had 30 years to adopt it, they are not going to. The reason is simple. "No one ever got fired for sticking with IPv4." Most IT people in the corporate world are "do no harm," "there are no bonuses," and "don't break things" mindset; therefore, there is simply no impetus to replace what is in front of them. There is no address exhaustion, and IPv6 worsens the problems they have with IPv4. IPv6 makes things worse. Literally. But there is a big problem with 10.x.x.x cross over, and hiding behind nats, and hierarchical need for the cloud. When IPx was invented the cloud was was the picture on Windows 95. But the real killer is two things. IPv6 isn't a low cost upgrade, and the enterprise is always going to need IPv4. So for the enterprise at least, build something built for the cloud. 1. Its easy -- every one has an ASN number. 2. Its backwards compatible. It is not IPvX with 64 bits it is [AREA CODE -- RN] + IPv4. 3. There is no new infrastructure to build. It has several components A Zone Server which is a combination of DHCP / DNS / NTP / (A web server Oauth and JWT replacing Radius) and NetLog Errors and PErformance only) A slightly improved PF Sense. These parts fully exist DNS / Anycast and VRFs. 4. It will be a firmware upgrade. 5. The internal Zone 127.x.x.x allows for 16 million zones per what ever -- with 4 Billion addresses each, and then you need to NAT again. It fixes almost every super-scalar behind the nat, collision problem. Operations ... IP exahustion. Each ASN gets 3 Billion addresses. Bad Routes. There are no bad IPv8 routes. Routing is achived by sending packets to the R.R.R.R or short form ASN. area code, and checked at ingress, and if the route isn't inside the ASN it sends back rate limited ICMP "no route available" So IPv8 is IPv4 V2 What do you think now? On Thu, Apr 30, 2026 at 1:45 PM Lucien Hoydic via NANOG <nanog@lists.nanog.org> wrote:
I see no need for this IPv8. IPv6 was carefully engineered over many years and while not perfect, works and is deployed. What problem are you trying to solve? I seem to have missed that.
No one is going to adopt IPv8. This is an academic discussion at best.
On Thursday, April 30th, 2026 at 10:51 AM, Joe Klein via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]
wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/QAQPQMJT3AEGHZERA2XJW3WIWBAMHBAI/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q AQPQMJT3AEGHZERA2XJW3WIWBAMHBAI/]
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/YAH63OJ4IJ3GKNROAILZHO6YXQQ5NQ2S/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Y AH63OJ4IJ3GKNROAILZHO6YXQQ5NQ2S/]
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/WWUAVWF5VUGLB7FCE6NE4LAMOGPDM7LP/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/W WUAVWF5VUGLB7FCE6NE4LAMOGPDM7LP/]
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/HTZGUHK5OFQTIOM4PGETYTNEUIWPDEDW/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/H TZGUHK5OFQTIOM4PGETYTNEUIWPDEDW/]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D] _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6C32XCBT...
If no corporation is migrating then why is IPv6 traffic continuing to increase? As I pointed out, IPv6 traffic increased 5% last year. At that admittedly slow rate, the entire internet will be IPv6 in 10 years. Further your assertion that business is the prime mover is incorrect. Business will move when they have to. That time is coming. When businesses can’t get IPv4 from their providers or superscaler, or a vendor or client can’t reach them, they will move. Andrew On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Andrew,
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4.
And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years.
Jamie
On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < nanog@lists.nanog.org> wrote:
I oppose this. With IPv6 traffic now representing around half of internet traffic, the time to rethink has long passed.
If IPv8 was going to be a solution, it should have been a solution 10 years ago.
In the last 12 months, ~5% of traffic migrated to IPv6. At that rate, IPv6 will be fully implemented by 2035. I'm not seeing a problem that needs to be solved, or a credible solution.
Andrew
On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
I joined this list because, as part of IPv8, I am creating a BGPv8. Inside BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to create better engineering results.
I also as part of CF created Sun Tzu which is the protocol that watches CF and gives you a CF score of reliability. Do I trust my partnership with you?
Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, etc, etc. That's not my discussion point. My point isn't "should I even propose IPv8" my point is what would be the best result for operators?
I believe that since IPv8 solves the duopoly problem, it will replace IPv4.
So the things to know, IPV8 is NOT a 64 bit addressing system.
It is a 32 bit routing system with a 32 bit addressing system.
A Routing Number = ASNs plus others.
8.8.8.8 would become 15169.8.8.8.8
https://www.ietf.org/archive/id/draft-thain-ipv8-02.html < https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea 3372a?u=12457652
So each ASN in the world will have 3 Billion available addresses.
There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x
I'd appreciate your thoughts on it
Jamie _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QPBOJRGH...
Gary, No it isn't. There are the Hyper Scalars and the Cell companies, and then -- what who of whats left are ever turning off IPv4. As I've said many times, and people don't believe it. IPv8 is about fixing IPv4 issues, and what are also IPv6 issues, but no one in corporate is removing IPv4, so gotta fix it. :) What is the sunset date of IPv4. Never. Jamie On Sat, May 2, 2026 at 12:14 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
That's from your perspective.
F100 adoption is higher than you think.
-----Original Message----- From: Jamie Thain via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> Sent: Friday, May 1, 2026 11:11 PM To: North American Network Operators Group <nanog@lists.nanog.org [nanog@lists.nanog.org]> Cc: Jamie Thain <jamie@one.bm [jamie@one.bm]> Subject: Re: IPv8 / BGP8 / CF
Lucien,
I see no need for this IPv8. IPv6 was carefully engineered over many years and while not perfect, works and is deployed. What problem are you trying to solve? I seem to have missed that.
As per my draft.
1. Management 2. Operation 3. IP Exhaustion.
IPv6 adoption is low in corporate networks. They've had 30 years to adopt it, they are not going to. The reason is simple. "No one ever got fired for sticking with IPv4." Most IT people in the corporate world are "do no harm," "there are no bonuses," and "don't break things" mindset; therefore, there is simply no impetus to replace what is in front of them. There is no address exhaustion, and IPv6 worsens the problems they have with IPv4. IPv6 makes things worse. Literally.
But there is a big problem with 10.x.x.x cross over, and hiding behind nats, and hierarchical need for the cloud. When IPx was invented the cloud was was the picture on Windows 95.
But the real killer is two things. IPv6 isn't a low cost upgrade, and the enterprise is always going to need IPv4.
So for the enterprise at least, build something built for the cloud.
1. Its easy -- every one has an ASN number. 2. Its backwards compatible. It is not IPvX with 64 bits it is [AREA CODE -- RN] + IPv4. 3. There is no new infrastructure to build. It has several components A Zone Server which is a combination of DHCP / DNS / NTP / (A web server Oauth and JWT replacing Radius) and NetLog Errors and PErformance only) A slightly improved PF Sense. These parts fully exist DNS / Anycast and VRFs.
4. It will be a firmware upgrade.
5. The internal Zone 127.x.x.x allows for 16 million zones per what ever -- with 4 Billion addresses each, and then you need to NAT again. It fixes almost every super-scalar behind the nat, collision problem.
Operations ...
IP exahustion. Each ASN gets 3 Billion addresses.
Bad Routes. There are no bad IPv8 routes. Routing is achived by sending packets to the R.R.R.R or short form ASN. area code, and checked at ingress, and if the route isn't inside the ASN it sends back rate limited ICMP "no route available"
So IPv8 is IPv4 V2
What do you think now?
On Thu, Apr 30, 2026 at 1:45 PM Lucien Hoydic via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
I see no need for this IPv8. IPv6 was carefully engineered over many years and while not perfect, works and is deployed. What problem are you trying to solve? I seem to have missed that.
No one is going to adopt IPv8. This is an academic discussion at best.
On Thursday, April 30th, 2026 at 10:51 AM, Joe Klein via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org] [nanog@lists.nanog.org [nanog@lists.nanog.org]]> wrote:
This is very funny!
- In 2004, very talented Chinese developers worked to implement IPv9. At present there are exclusive patents, but have yet to seen any code.
- Over 20 cumulative years, there are about 0.5–2 trillion IPv6 address instances, with the high side is driven by mobile devices, Wi-Fi roaming, privacy-address rotation, VMs, containers, VPNs, and tunnels. In short, this covers the ocean floor, caves, areas near Earth, and deep space. Will you and your team pay for the IPv4/IPv6 change? When will you submit the patent applications (Similary to Microsoft patent for SEND/CGA)?
Have fun.
OO.
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 Thu, Apr 30, 2026, 10:51 AM Tom Beecher via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org] [nanog@lists.nanog.org [nanog@lists.nanog.org]]> wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Only works when the recipient is actually open to receiving feedback and collaborating.
Reading Mr. Thain's replies here and on int-area answers that question quite rapidly.
On Thu, Apr 30, 2026 at 2:35 AM Saku Ytti via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org] [nanog@lists.nanog.org [nanog@lists.nanog.org]]
wrote:
Tough love is needed here, and the list is not providing it. You're not being polite, you're enabling.
Stop supporting this LLM psychosis.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/QAQPQMJT3AEGHZERA2XJW3WIWBAMHBAI/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q] AQPQMJT3AEGHZERA2XJW3WIWBAMHBAI/]
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/YAH63OJ4IJ3GKNROAILZHO6YXQQ5NQ2S/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Y [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Y] AH63OJ4IJ3GKNROAILZHO6YXQQ5NQ2S/]
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/WWUAVWF5VUGLB7FCE6NE4LAMOGPDM7LP/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/W [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/W] WUAVWF5VUGLB7FCE6NE4LAMOGPDM7LP/]
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/HTZGUHK5OFQTIOM4PGETYTNEUIWPDEDW/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/H [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/H] TZGUHK5OFQTIOM4PGETYTNEUIWPDEDW/]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D] _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/6C32XCBT5EY4W56SHMRKNUGPYJZ6ES7G/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6C32XCBT...]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
Andrew, Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 in a meeting and two corp engineers laughed. You can google it yourself. Jamie On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < nanog@lists.nanog.org> wrote:
If no corporation is migrating then why is IPv6 traffic continuing to increase?
As I pointed out, IPv6 traffic increased 5% last year. At that admittedly slow rate, the entire internet will be IPv6 in 10 years.
Further your assertion that business is the prime mover is incorrect. Business will move when they have to. That time is coming.
When businesses can’t get IPv4 from their providers or superscaler, or a vendor or client can’t reach them, they will move.
Andrew
On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Andrew,
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4.
And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years.
Jamie
On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < nanog@lists.nanog.org> wrote:
I oppose this. With IPv6 traffic now representing around half of internet traffic, the time to rethink has long passed.
If IPv8 was going to be a solution, it should have been a solution 10 years ago.
In the last 12 months, ~5% of traffic migrated to IPv6. At that rate, IPv6 will be fully implemented by 2035. I'm not seeing a problem that needs to be solved, or a credible solution.
Andrew
On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
I joined this list because, as part of IPv8, I am creating a BGPv8. Inside BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to create better engineering results.
I also as part of CF created Sun Tzu which is the protocol that watches CF and gives you a CF score of reliability. Do I trust my partnership with you?
Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, etc, etc. That's not my discussion point. My point isn't "should I even propose IPv8" my point is what would be the best result for operators?
I believe that since IPv8 solves the duopoly problem, it will replace IPv4.
So the things to know, IPV8 is NOT a 64 bit addressing system.
It is a 32 bit routing system with a 32 bit addressing system.
A Routing Number = ASNs plus others.
8.8.8.8 would become 15169.8.8.8.8
https://www.ietf.org/archive/id/draft-thain-ipv8-02.html < https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea 3372a?u=12457652
So each ASN in the world will have 3 Billion available addresses.
There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x
I'd appreciate your thoughts on it
Jamie _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/
Am 02.05.26 um 05:11 schrieb Jamie Thain via NANOG:
But the real killer is two things. IPv6 isn't a low cost upgrade, and the enterprise is always going to need IPv4.
Every change is creating costs in such an environment. As you proposal cannot replace IPv4 backward-compatible, it has the same issues as IPv6 already has, but is new, more complicated and will take another 10+ years to be even supported on hard- and software. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Am 02.05.26 um 05:13 schrieb Jamie Thain via NANOG:
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4.
And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years.
If they are not willing to upgrade, they are also not willing to implement any other new protocol, as this always means that IPv4 only machines need to be changed, as you cannot make them able to reach non IPv4 machines without modifying them. All of that stuff has being discussed many times... -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
IPv4 only machines can reach IPv6 machines. It just requires a DNS46 implementation which was done as an experiment years ago and a CLAT with address mappings configured from the DNS46. This is known to not scale well but there are very little truely IPv4 equipment these days. It works on the small scale. Now it would be nice if people would move to IPv6 sooner rather than later but now it’s mostly getting people to turn it on rather than waiting for equipment to support it. It will get to the stage where shareholders will start asking where is our IPv6 presence? Remember that everyone is paying more for these IPv4 only sites. Your home ISP / cellular provider has to charge you more to provide this backwards compatibility. A line item on the bill would make this clearer. Big ISPs aren’t turning off IPv6. They are turning off IPv4 towards the customer leaving IPv4 to be delivered via IPv4AAS. -- Mark Andrews
On 2 May 2026, at 14:55, Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 02.05.26 um 05:13 schrieb Jamie Thain via NANOG:
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4. And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years.
If they are not willing to upgrade, they are also not willing to implement any other new protocol, as this always means that IPv4 only machines need to be changed, as you cannot make them able to reach non IPv4 machines without modifying them.
All of that stuff has being discussed many times...
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2EKXGBLS...
Am 02.05.26 um 07:38 schrieb Mark Andrews:
IPv4 only machines can reach IPv6 machines. It just requires a DNS46 implementation which was done as an experiment years ago and a CLAT with address mappings configured from the DNS46. This is known to not scale well but there are very little truely IPv4 equipment these days. It works on the small scale. And that means that at least at the site this service need to be implemented. Although, there are site who do not want that, so at the end there will be no general case where every IPv4 only machine can reach IPv6 only machines - regardless of new proposals.
-- Gruß Marco Muell und Spam bitte an abfalleimer2000@stinkedores.dorfdsl.de
On Sat, 2 May 2026, Jamie Thain via NANOG wrote:
4. It will be a firmware upgrade.
You've come to an operator forum and are making these naive (and obviously wrong) claims. IPv10 guy did the same, and he was equally wrong. So again, start implementing, and you'll learn a lot and realise that you're wrong. We keep telling you you're wrong, you don't listen. Stop wasting brain bandwidth for everybody. https://datatracker.ietf.org/doc/draft-omar-ipv10/10/ He wasted a lot of time, you're doing the same. -- Mikael Abrahamsson email: swmike@swm.pp.se
Marco There is no point where shareholders will ask 'where is my ipv6 presence' they don't care. Dear Mr shareholder give me 2m dollars for an ipv6 presence. Shareholder what's not working CTO nothing Shareholder, you want 2m $ to fix something that's not broken -- and so we get to turn off what we have now and save a bunch of money.... THIS QUARTER CTO nope Sharholder : your fired. 🙂 And that's exactly why Jamie On Sat., May 2, 2026, 2:39 a.m. Mark Andrews via NANOG, < nanog@lists.nanog.org> wrote:
IPv4 only machines can reach IPv6 machines. It just requires a DNS46 implementation which was done as an experiment years ago and a CLAT with address mappings configured from the DNS46. This is known to not scale well but there are very little truely IPv4 equipment these days. It works on the small scale.
Now it would be nice if people would move to IPv6 sooner rather than later but now it’s mostly getting people to turn it on rather than waiting for equipment to support it. It will get to the stage where shareholders will start asking where is our IPv6 presence? Remember that everyone is paying more for these IPv4 only sites. Your home ISP / cellular provider has to charge you more to provide this backwards compatibility. A line item on the bill would make this clearer. Big ISPs aren’t turning off IPv6. They are turning off IPv4 towards the customer leaving IPv4 to be delivered via IPv4AAS.
-- Mark Andrews
On 2 May 2026, at 14:55, Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 02.05.26 um 05:13 schrieb Jamie Thain via NANOG:
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4. And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years.
If they are not willing to upgrade, they are also not willing to implement any other new protocol, as this always means that IPv4 only machines need to be changed, as you cannot make them able to reach non IPv4 machines without modifying them.
All of that stuff has being discussed many times...
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2EKXGBLS...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KU543YXN...
Mikeal Ipv10 Was A dual stack idea. Again since you can't do the analysis steps then just send me a tape recording. Jamie On Sat., May 2, 2026, 3:08 a.m. Mikael Abrahamsson, <swmike@swm.pp.se> wrote:
On Sat, 2 May 2026, Jamie Thain via NANOG wrote:
4. It will be a firmware upgrade.
You've come to an operator forum and are making these naive (and obviously wrong) claims. IPv10 guy did the same, and he was equally wrong.
So again, start implementing, and you'll learn a lot and realise that you're wrong. We keep telling you you're wrong, you don't listen. Stop wasting brain bandwidth for everybody.
https://datatracker.ietf.org/doc/draft-omar-ipv10/10/
He wasted a lot of time, you're doing the same.
-- Mikael Abrahamsson email: swmike@swm.pp.se
On Sat, 2 May 2026, Jamie Thain wrote:
Ipv10 Was A dual stack idea.
Everything that isn't IPv4 will be a new stack. This was realised already in the 90s, and that's why we have IPv6 that's now close to 30 years into its deployment. Adding another stack in the mix won't help. If you would have done what you're doing back in mid 90s, it might have helped. You're 3 decades too late.
Again since you can't do the analysis steps then just send me a tape recording.
There is nothing to analyze. You're proposing something that isn't backwards compatible, and you don't seem to understand this is what you're proposing. Same as IPv10 guy. So start implementing, you might understand it then. -- Mikael Abrahamsson email: swmike@swm.pp.se
Mikael And what isn't backwards compatible if you know of something. I'm all ears. Jamie On Sat., May 2, 2026, 6:18 a.m. Mikael Abrahamsson, <swmike@swm.pp.se> wrote:
On Sat, 2 May 2026, Jamie Thain wrote:
Ipv10 Was A dual stack idea.
Everything that isn't IPv4 will be a new stack. This was realised already in the 90s, and that's why we have IPv6 that's now close to 30 years into its deployment. Adding another stack in the mix won't help.
If you would have done what you're doing back in mid 90s, it might have helped. You're 3 decades too late.
Again since you can't do the analysis steps then just send me a tape recording.
There is nothing to analyze. You're proposing something that isn't backwards compatible, and you don't seem to understand this is what you're proposing. Same as IPv10 guy.
So start implementing, you might understand it then.
-- Mikael Abrahamsson email: swmike@swm.pp.se
Am 02.05.26 um 14:56 schrieb Jamie Thain via NANOG:
And what isn't backwards compatible if you know of something. I'm all ears.
Your proposal isn't too, as there is nothing that can be backwards compatible regarding IPv4-only nodes in an IPv4-only environment with admins who do not want any change. -- Gruß Marco Muell und Spam bitte an abfalleimer2000@stinkedores.dorfdsl.de
I know of enterprises who are deploying v6. Until you can show the world a working IPv8 implementation on a large using off-the-shelf components where people can run through failure scenarios and really beat it up, not many people are going to take it seriously. Lower layers of the network relying on the functionality of higher layers is a really, really, really bad idea. While it's always important to think about how to so something better, v8 seems to create a whole bunch of new problems while not solving many that have already been addressed in v6 and other protocols. Thank you jms On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Andrew,
Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 in a meeting and two corp engineers laughed.
You can google it yourself.
Jamie
On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < nanog@lists.nanog.org> wrote:
If no corporation is migrating then why is IPv6 traffic continuing to increase?
As I pointed out, IPv6 traffic increased 5% last year. At that admittedly slow rate, the entire internet will be IPv6 in 10 years.
Further your assertion that business is the prime mover is incorrect. Business will move when they have to. That time is coming.
When businesses can’t get IPv4 from their providers or superscaler, or a vendor or client can’t reach them, they will move.
Andrew
On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Andrew,
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4.
And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years.
Jamie
On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < nanog@lists.nanog.org> wrote:
I oppose this. With IPv6 traffic now representing around half of internet traffic, the time to rethink has long passed.
If IPv8 was going to be a solution, it should have been a solution 10 years ago.
In the last 12 months, ~5% of traffic migrated to IPv6. At that rate, IPv6 will be fully implemented by 2035. I'm not seeing a problem that needs to be solved, or a credible solution.
Andrew
On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
I joined this list because, as part of IPv8, I am creating a BGPv8. Inside BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to create better engineering results.
I also as part of CF created Sun Tzu which is the protocol that watches CF and gives you a CF score of reliability. Do I trust my partnership with you?
Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, etc, etc. That's not my discussion point. My point isn't "should I even propose IPv8" my point is what would be the best result for operators?
I believe that since IPv8 solves the duopoly problem, it will replace IPv4.
So the things to know, IPV8 is NOT a 64 bit addressing system.
It is a 32 bit routing system with a 32 bit addressing system.
A Routing Number = ASNs plus others.
8.8.8.8 would become 15169.8.8.8.8
https://www.ietf.org/archive/id/draft-thain-ipv8-02.html < https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea 3372a?u=12457652
So each ASN in the world will have 3 Billion available addresses.
There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x
I'd appreciate your thoughts on it
Jamie _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA...
Folks Jim Fleming came and went with his ipv9 and none of us wanted any part of that. So why would we want this downgrade to ipv8? :) --srs ________________________________ From: Justin Streiner via NANOG <nanog@lists.nanog.org> Sent: Saturday, May 2, 2026 7:41:55 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Justin Streiner <streinerj@gmail.com> Subject: Re: IPv8 / BGP8 / CF I know of enterprises who are deploying v6. Until you can show the world a working IPv8 implementation on a large using off-the-shelf components where people can run through failure scenarios and really beat it up, not many people are going to take it seriously. Lower layers of the network relying on the functionality of higher layers is a really, really, really bad idea. While it's always important to think about how to so something better, v8 seems to create a whole bunch of new problems while not solving many that have already been addressed in v6 and other protocols. Thank you jms On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Andrew,
Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 in a meeting and two corp engineers laughed.
You can google it yourself.
Jamie
On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < nanog@lists.nanog.org> wrote:
If no corporation is migrating then why is IPv6 traffic continuing to increase?
As I pointed out, IPv6 traffic increased 5% last year. At that admittedly slow rate, the entire internet will be IPv6 in 10 years.
Further your assertion that business is the prime mover is incorrect. Business will move when they have to. That time is coming.
When businesses can’t get IPv4 from their providers or superscaler, or a vendor or client can’t reach them, they will move.
Andrew
On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Andrew,
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4.
And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years.
Jamie
On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < nanog@lists.nanog.org> wrote:
I oppose this. With IPv6 traffic now representing around half of internet traffic, the time to rethink has long passed.
If IPv8 was going to be a solution, it should have been a solution 10 years ago.
In the last 12 months, ~5% of traffic migrated to IPv6. At that rate, IPv6 will be fully implemented by 2035. I'm not seeing a problem that needs to be solved, or a credible solution.
Andrew
On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
I joined this list because, as part of IPv8, I am creating a BGPv8. Inside BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to create better engineering results.
I also as part of CF created Sun Tzu which is the protocol that watches CF and gives you a CF score of reliability. Do I trust my partnership with you?
Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, etc, etc. That's not my discussion point. My point isn't "should I even propose IPv8" my point is what would be the best result for operators?
I believe that since IPv8 solves the duopoly problem, it will replace IPv4.
So the things to know, IPV8 is NOT a 64 bit addressing system.
It is a 32 bit routing system with a 32 bit addressing system.
A Routing Number = ASNs plus others.
8.8.8.8 would become 15169.8.8.8.8
https://www.ietf.org/archive/id/draft-thain-ipv8-02.html < https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea 3372a?u=12457652
So each ASN in the world will have 3 Billion available addresses.
There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x
I'd appreciate your thoughts on it
Jamie _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2MY7QMH6...
Essentially your arguments boil down to : "Some companies don't want to spend money to implement V6. My solution is a new IP version 8, which would require EVERY company to spend money to implement. This totally makes sense, don't you see?" Not only are your technical proposals flawed, your logic is completely backwards. On Sat, May 2, 2026 at 3:27 AM Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Marco
There is no point where shareholders will ask 'where is my ipv6 presence' they don't care.
Dear Mr shareholder give me 2m dollars for an ipv6 presence.
Shareholder what's not working
CTO nothing
Shareholder, you want 2m $ to fix something that's not broken -- and so we get to turn off what we have now and save a bunch of money.... THIS QUARTER
CTO nope
Sharholder : your fired.
🙂 And that's exactly why
Jamie
On Sat., May 2, 2026, 2:39 a.m. Mark Andrews via NANOG, < nanog@lists.nanog.org> wrote:
IPv4 only machines can reach IPv6 machines. It just requires a DNS46 implementation which was done as an experiment years ago and a CLAT with address mappings configured from the DNS46. This is known to not scale well but there are very little truely IPv4 equipment these days. It works on the small scale.
Now it would be nice if people would move to IPv6 sooner rather than later but now it’s mostly getting people to turn it on rather than waiting for equipment to support it. It will get to the stage where shareholders will start asking where is our IPv6 presence? Remember that everyone is paying more for these IPv4 only sites. Your home ISP / cellular provider has to charge you more to provide this backwards compatibility. A line item on the bill would make this clearer. Big ISPs aren’t turning off IPv6. They are turning off IPv4 towards the customer leaving IPv4 to be delivered via IPv4AAS.
-- Mark Andrews
On 2 May 2026, at 14:55, Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 02.05.26 um 05:13 schrieb Jamie Thain via NANOG:
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4. And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years.
If they are not willing to upgrade, they are also not willing to implement any other new protocol, as this always means that IPv4 only machines need to be changed, as you cannot make them able to reach non IPv4 machines without modifying them.
All of that stuff has being discussed many times...
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2EKXGBLS...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KU543YXN... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Y5ALPB5T...
Justin, Because before you write a line of code you have to get it right, or near right. If you want to see good engineering watch from the "Earth to the Moon" Spider, how they built the lunar lander. So far I've had like 3 serious conversations about "this won't work" and each one has had me improve it. But "go make code" before we discuss what and how it should be, a DRAFT is actually when you want comments about the operation of it all. I'm not going to wait until I written 1m worth of code to figure something is wrong. IETF folks suggested to me, that I join Nanog to see how they might use it. IPv8 is not about address space. Jamie On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG <nanog@lists.nanog.org> wrote:
I know of enterprises who are deploying v6.
Until you can show the world a working IPv8 implementation on a large using off-the-shelf components where people can run through failure scenarios and really beat it up, not many people are going to take it seriously.
Lower layers of the network relying on the functionality of higher layers is a really, really, really bad idea.
While it's always important to think about how to so something better, v8 seems to create a whole bunch of new problems while not solving many that have already been addressed in v6 and other protocols.
Thank you jms
On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Andrew,
Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 in a meeting and two corp engineers laughed.
You can google it yourself.
Jamie
On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
If no corporation is migrating then why is IPv6 traffic continuing to increase?
As I pointed out, IPv6 traffic increased 5% last year. At that admittedly slow rate, the entire internet will be IPv6 in 10 years.
Further your assertion that business is the prime mover is incorrect. Business will move when they have to. That time is coming.
When businesses can’t get IPv4 from their providers or superscaler, or a vendor or client can’t reach them, they will move.
Andrew
On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Andrew,
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4.
And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years.
Jamie
On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
I oppose this. With IPv6 traffic now representing around half of internet traffic, the time to rethink has long passed.
If IPv8 was going to be a solution, it should have been a solution 10 years ago.
In the last 12 months, ~5% of traffic migrated to IPv6. At that rate, IPv6 will be fully implemented by 2035. I'm not seeing a problem that needs to be solved, or a credible solution.
Andrew
On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
I joined this list because, as part of IPv8, I am creating a BGPv8. Inside BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to create better engineering results.
I also as part of CF created Sun Tzu which is the protocol that watches CF and gives you a CF score of reliability. Do I trust my partnership with you?
Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, etc, etc. That's not my discussion point. My point isn't "should I even propose IPv8" my point is what would be the best result for operators?
I believe that since IPv8 solves the duopoly problem, it will replace IPv4.
So the things to know, IPV8 is NOT a 64 bit addressing system.
It is a 32 bit routing system with a 32 bit addressing system.
A Routing Number = ASNs plus others.
8.8.8.8 would become 15169.8.8.8.8
https://www.ietf.org/archive/id/draft-thain-ipv8-02.html [https://www.ietf.org/archive/id/draft-thain-ipv8-02.html] < https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea [https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea] 3372a?u=12457652 >
So each ASN in the world will have 3 Billion available addresses.
There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x
I'd appreciate your thoughts on it
Jamie _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA...]
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2MY7QMH6...]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
IPv8 is just as broken as IPv6. You can start by convincing your ISP to sell you IPv8 service. Once the protocol is successfully used as an experiment between a few different ISPs and their customers, then we can standardize it. Hey mr shareholder please give me 20 million dollars for ipv8 On 2 May 2026 05:13:49 CEST, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Andrew,
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4.
And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years.
Jamie
On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < nanog@lists.nanog.org> wrote:
I oppose this. With IPv6 traffic now representing around half of internet traffic, the time to rethink has long passed.
If IPv8 was going to be a solution, it should have been a solution 10 years ago.
In the last 12 months, ~5% of traffic migrated to IPv6. At that rate, IPv6 will be fully implemented by 2035. I'm not seeing a problem that needs to be solved, or a credible solution.
Andrew
On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Hi All,
My name is Jamie Thain I'm the creator of IPv8. It's not a hoax.
I joined this list because, as part of IPv8, I am creating a BGPv8. Inside BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to create better engineering results.
I also as part of CF created Sun Tzu which is the protocol that watches CF and gives you a CF score of reliability. Do I trust my partnership with you?
Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, etc, etc. That's not my discussion point. My point isn't "should I even propose IPv8" my point is what would be the best result for operators?
I believe that since IPv8 solves the duopoly problem, it will replace IPv4.
So the things to know, IPV8 is NOT a 64 bit addressing system.
It is a 32 bit routing system with a 32 bit addressing system.
A Routing Number = ASNs plus others.
8.8.8.8 would become 15169.8.8.8.8
https://www.ietf.org/archive/id/draft-thain-ipv8-02.html < https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea 3372a?u=12457652
So each ASN in the world will have 3 Billion available addresses.
There is a specially reserved group of internal ASN 127.x.x.x so each corp, org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and 100.64.x.x.x
I'd appreciate your thoughts on it
Jamie _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QPBOJRGH...
Exactly how do you intend to convince OS vendors to rebuild their network stacks and network vendors to spin new silicon to implement IPv8 without at least a working reference implementation? jms On Sat, May 2, 2026, 14:05 Jamie Thain <jamie@one.bm> wrote:
Justin,
Because before you write a line of code you have to get it right, or near right.
If you want to see good engineering watch from the "Earth to the Moon" Spider, how they built the lunar lander.
So far I've had like 3 serious conversations about "this won't work" and each one has had me improve it. But "go make code" before we discuss what and how it should be, a DRAFT is actually when you want comments about the operation of it all.
I'm not going to wait until I written 1m worth of code to figure something is wrong.
IETF folks suggested to me, that I join Nanog to see how they might use it. IPv8 is not about address space.
Jamie
On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG < nanog@lists.nanog.org> wrote:
I know of enterprises who are deploying v6.
Until you can show the world a working IPv8 implementation on a large using off-the-shelf components where people can run through failure scenarios and really beat it up, not many people are going to take it seriously.
Lower layers of the network relying on the functionality of higher layers is a really, really, really bad idea.
While it's always important to think about how to so something better, v8 seems to create a whole bunch of new problems while not solving many that have already been addressed in v6 and other protocols.
Thank you jms
On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Andrew,
Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 in a meeting and two corp engineers laughed.
You can google it yourself.
Jamie
On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < nanog@lists.nanog.org> wrote:
If no corporation is migrating then why is IPv6 traffic continuing to increase?
As I pointed out, IPv6 traffic increased 5% last year. At that admittedly slow rate, the entire internet will be IPv6 in 10 years.
Further your assertion that business is the prime mover is incorrect. Business will move when they have to. That time is coming.
When businesses can’t get IPv4 from their providers or superscaler, or a vendor or client can’t reach them, they will move.
Andrew
On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Andrew,
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4.
And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years.
Jamie
On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < nanog@lists.nanog.org> wrote:
I oppose this. With IPv6 traffic now representing around half of internet traffic, the time to rethink has long passed.
If IPv8 was going to be a solution, it should have been a solution 10 years ago.
In the last 12 months, ~5% of traffic migrated to IPv6. At that rate, IPv6 will be fully implemented by 2035. I'm not seeing a problem that needs to be solved, or a credible solution.
Andrew
On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
> Hi All, > > My name is Jamie Thain I'm the creator of IPv8. It's not a hoax. > > I joined this list because, as part of IPv8, I am creating a BGPv8. Inside > BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the > routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to > create better engineering results. > > I also as part of CF created Sun Tzu which is the protocol that watches CF > and gives you a CF score of reliability. Do I trust my partnership with > you? > > Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, > etc, etc. That's not my discussion point. My point isn't "should I even > propose IPv8" my point is what would be the best result for operators? > > I believe that since IPv8 solves the duopoly problem, it will replace > IPv4. > > So the things to know, IPV8 is NOT a 64 bit addressing system. > > It is a 32 bit routing system with a 32 bit addressing system. > > A Routing Number = ASNs plus others. > > 8.8.8.8 would become 15169.8.8.8.8 > > https://www.ietf.org/archive/id/draft-thain-ipv8-02.html > < > https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea 3372a?u=12457652 > > > > > So each ASN in the world will have 3 Billion available addresses. > > There is a specially reserved group of internal ASN 127.x.x.x so each corp, > org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and > 100.64.x.x.x > > I'd appreciate your thoughts on it > > Jamie > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/ > _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2MY7QMH6...
They won’t, Can we please end this thread? On Sat, May 2, 2026 at 09:17 Justin Streiner via NANOG < nanog@lists.nanog.org> wrote:
Exactly how do you intend to convince OS vendors to rebuild their network stacks and network vendors to spin new silicon to implement IPv8 without at least a working reference implementation?
jms
On Sat, May 2, 2026, 14:05 Jamie Thain <jamie@one.bm> wrote:
Justin,
Because before you write a line of code you have to get it right, or near right.
If you want to see good engineering watch from the "Earth to the Moon" Spider, how they built the lunar lander.
So far I've had like 3 serious conversations about "this won't work" and each one has had me improve it. But "go make code" before we discuss what and how it should be, a DRAFT is actually when you want comments about the operation of it all.
I'm not going to wait until I written 1m worth of code to figure something is wrong.
IETF folks suggested to me, that I join Nanog to see how they might use it. IPv8 is not about address space.
Jamie
On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG < nanog@lists.nanog.org> wrote:
I know of enterprises who are deploying v6.
Until you can show the world a working IPv8 implementation on a large using off-the-shelf components where people can run through failure scenarios and really beat it up, not many people are going to take it seriously.
Lower layers of the network relying on the functionality of higher layers is a really, really, really bad idea.
While it's always important to think about how to so something better, v8 seems to create a whole bunch of new problems while not solving many that have already been addressed in v6 and other protocols.
Thank you jms
On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG <nanog@lists.nanog.org
wrote:
Andrew,
Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 in a meeting and two corp engineers laughed.
You can google it yourself.
Jamie
On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < nanog@lists.nanog.org> wrote:
If no corporation is migrating then why is IPv6 traffic continuing to increase?
As I pointed out, IPv6 traffic increased 5% last year. At that admittedly slow rate, the entire internet will be IPv6 in 10 years.
Further your assertion that business is the prime mover is incorrect. Business will move when they have to. That time is coming.
When businesses can’t get IPv4 from their providers or superscaler, or a vendor or client can’t reach them, they will move.
Andrew
On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Andrew,
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4.
And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years.
Jamie
On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < nanog@lists.nanog.org> wrote:
> I oppose this. With IPv6 traffic now representing around half of internet > traffic, the time to rethink has long passed. > > If IPv8 was going to be a solution, it should have been a solution 10 years > ago. > > In the last 12 months, ~5% of traffic migrated to IPv6. At that rate, IPv6 > will be fully implemented by 2035. I'm not seeing a problem that needs to > be solved, or a credible solution. > > Andrew > > > > On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < > nanog@lists.nanog.org> > wrote: > > > Hi All, > > > > My name is Jamie Thain I'm the creator of IPv8. It's not a hoax. > > > > I joined this list because, as part of IPv8, I am creating a BGPv8. > Inside > > BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the > > routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP > to > > create better engineering results. > > > > I also as part of CF created Sun Tzu which is the protocol that watches > CF > > and gives you a CF score of reliability. Do I trust my partnership with > > you? > > > > Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, > > etc, etc. That's not my discussion point. My point isn't "should I even > > propose IPv8" my point is what would be the best result for operators? > > > > I believe that since IPv8 solves the duopoly problem, it will replace > > IPv4. > > > > So the things to know, IPV8 is NOT a 64 bit addressing system. > > > > It is a 32 bit routing system with a 32 bit addressing system. > > > > A Routing Number = ASNs plus others. > > > > 8.8.8.8 would become 15169.8.8.8.8 > > > > https://www.ietf.org/archive/id/draft-thain-ipv8-02.html > > < > > https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea > 3372a?u=12457652 > > > > > > > > > So each ASN in the world will have 3 Billion available addresses. > > > > There is a specially reserved group of internal ASN 127.x.x.x so each > corp, > > org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and > > 100.64.x.x.x > > > > I'd appreciate your thoughts on it > > > > Jamie > > _______________________________________________ > > NANOG mailing list > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ > message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/ > > > _______________________________________________ > NANOG mailing list > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ > message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2MY7QMH6...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SCPNQQRQ...
Jaimie, I will put up an RFP for my time machine. I saw you in the future, you are homeless and addicted to fentanyl. EOF. Blocked for wasting all of our time. On Sat, May 2, 2026 at 2:06 PM Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Justin,
Because before you write a line of code you have to get it right, or near right.
If you want to see good engineering watch from the "Earth to the Moon" Spider, how they built the lunar lander.
So far I've had like 3 serious conversations about "this won't work" and each one has had me improve it. But "go make code" before we discuss what and how it should be, a DRAFT is actually when you want comments about the operation of it all.
I'm not going to wait until I written 1m worth of code to figure something is wrong.
IETF folks suggested to me, that I join Nanog to see how they might use it. IPv8 is not about address space.
Jamie
On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG <nanog@lists.nanog.org> wrote:
I know of enterprises who are deploying v6.
Until you can show the world a working IPv8 implementation on a large using off-the-shelf components where people can run through failure scenarios and really beat it up, not many people are going to take it seriously.
Lower layers of the network relying on the functionality of higher layers is a really, really, really bad idea.
While it's always important to think about how to so something better, v8 seems to create a whole bunch of new problems while not solving many that have already been addressed in v6 and other protocols.
Thank you jms
On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Andrew,
Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 in a meeting and two corp engineers laughed.
You can google it yourself.
Jamie
On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
If no corporation is migrating then why is IPv6 traffic continuing to increase?
As I pointed out, IPv6 traffic increased 5% last year. At that admittedly slow rate, the entire internet will be IPv6 in 10 years.
Further your assertion that business is the prime mover is incorrect. Business will move when they have to. That time is coming.
When businesses can’t get IPv4 from their providers or superscaler, or a vendor or client can’t reach them, they will move.
Andrew
On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Andrew,
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4.
And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years.
Jamie
On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
I oppose this. With IPv6 traffic now representing around half of internet traffic, the time to rethink has long passed.
If IPv8 was going to be a solution, it should have been a solution 10 years ago.
In the last 12 months, ~5% of traffic migrated to IPv6. At that rate, IPv6 will be fully implemented by 2035. I'm not seeing a problem that needs to be solved, or a credible solution.
Andrew
On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
> Hi All, > > My name is Jamie Thain I'm the creator of IPv8. It's not a hoax. > > I joined this list because, as part of IPv8, I am creating a BGPv8. Inside > BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the > routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to > create better engineering results. > > I also as part of CF created Sun Tzu which is the protocol that watches CF > and gives you a CF score of reliability. Do I trust my partnership with > you? > > Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, > etc, etc. That's not my discussion point. My point isn't "should I even > propose IPv8" my point is what would be the best result for operators? > > I believe that since IPv8 solves the duopoly problem, it will replace > IPv4. > > So the things to know, IPV8 is NOT a 64 bit addressing system. > > It is a 32 bit routing system with a 32 bit addressing system. > > A Routing Number = ASNs plus others. > > 8.8.8.8 would become 15169.8.8.8.8 > > https://www.ietf.org/archive/id/draft-thain-ipv8-02.html [https://www.ietf.org/archive/id/draft-thain-ipv8-02.html] > < > https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea [https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea] 3372a?u=12457652 > > > > > So each ASN in the world will have 3 Billion available addresses. > > There is a specially reserved group of internal ASN 127.x.x.x so each corp, > org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and > 100.64.x.x.x > > I'd appreciate your thoughts on it > > Jamie > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/ > _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA...]
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2MY7QMH6...]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D] _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JTNFIASL...
I find it funny that all these network protocols failed to replace TCP/IP4... Before TCP/IP became the universal standard, the "Protocol Wars" of the 1980s and 90s featured several heavyweights that were once "all the rage." These protocols often prioritised performance on local networks or were backed by massive government and corporate interests that explicitly aimed to avoid the "ad-hoc" nature of the U.S. Department of Defense's TCP/IP suite. [1 <https://en.wikipedia.org/wiki/Protocol_Wars>, 2 <https://en.wikipedia.org/wiki/Protocol_Wars>, 3 <https://www.britannica.com/technology/TCP-IP>] The Most Prominent Alternatives - IPX/SPX (Novell NetWare): The king of the 1980s LAN. It was "awesomesauce" for local offices because it was plug-and-play, using a computer's MAC address as its network identity. It was faster and lighter than early TCP/IP but struggled to scale for the global internet. - OSI (Open Systems Interconnection): A massive, 7-layer theoretical framework developed by international committees. European governments and the U.S. Department of Commerce even mandated its use for a time, viewing TCP/IP as a temporary military experiment. It ultimately failed because it was too complex and arrived too late with working code. - AppleTalk: Designed for early Macintosh networks, it was remarkably user-friendly and allowed printers and computers to "find" each other automatically. However, it was "chatty," sending constant background updates that could overwhelm larger networks. - SNA (Systems Network Architecture): IBM's proprietary powerhouse for connecting mainframes. It was reliable and sophisticated for corporate environments but kept users locked into the IBM ecosystem. - DECnet: Digital Equipment Corporation's suite for its VAX systems. Like SNA, it was highly capable but ultimately proprietary. [1 <https://en.wikipedia.org/wiki/Protocol_Wars>, 2 <https://www.quora.com/How-do-TCP-IP-and-IPX-SPX-differ>, 3 <https://www.reddit.com/r/explainlikeimfive/comments/45c108/eli5_what_is_ipx_protocol_and_why_have_we_moved/>, 4 <https://en.wikipedia.org/wiki/Internetwork_Packet_Exchange>, 5 <https://www.americantv.com/ipx-spx.php>, 6 <https://www.fortinet.com/resources/cyberglossary/tcp-ip-model-vs-osi-model>, 7 <https://www.geeksforgeeks.org/computer-networks/difference-between-osi-model-and-tcp-ip-model/>, 8 <https://www.quora.com/What-were-the-alternatives-to-TCP-IP-when-the-Internet-was-formed>, 9 <https://retrocomputing.stackexchange.com/questions/29823/what-were-the-major-things-that-caused-tcp-ip-to-become-the-internet-standard-pr>, 10 <https://www.myweb.ttu.edu/csmith/Protocols.html>, 11 <https://www.quora.com/Are-there-any-networks-today-that-dont-use-TCP-IP>, 12 <https://www.reddit.com/r/networking/comments/16f2zwi/how_would_the_internet_infrastructure_today_look/>, 13 <https://www.quora.com/Why-is-TCP-IP-still-the-core-protocol-of-the-Internet-and-are-there-any-potential-replacements-or-improvements-in-the-works> ] ------------------------------ 🛡️ Why They "Lost" to TCP/IP - The "Design by Committee" Trap: The OSI suite became bloated because every participating country wanted their specific features included, making it nearly impossible to implement efficiently. - Pragmatism vs. Theory: TCP/IP was built by researchers who wrote the code first and the standards later. It was "good enough" and already running on Unix systems everywhere by the time competitors were still arguing over specs. - The Rise of the Web: When the World Wide Web launched in the early 90s, it ran on TCP/IP. To access the "new" internet, everyone was forced to adopt the protocol, rendering the proprietary alternatives obsolete. [1 <https://www.quora.com/It-has-been-said-that-the-OSI-model-won-the-battle-but-lost-the-war-against-TCP-IP-Why-do-you-think-this-is-so>, 2 <https://www.youtube.com/watch?v=TxBTdOOV2ts&t=6>, 3 <http://www.sci.brooklyn.cuny.edu/~parsons/courses/3120-fall-2012/notes/tcp-ip-notes.pdf>, 4 <https://en.wikipedia.org/wiki/Protocol_Wars>, 5 <https://retrocomputing.stackexchange.com/questions/29823/what-were-the-major-things-that-caused-tcp-ip-to-become-the-internet-standard-pr> ] 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 Sat, May 2, 2026, 1:34 PM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
Essentially your arguments boil down to :
"Some companies don't want to spend money to implement V6. My solution is a new IP version 8, which would require EVERY company to spend money to implement. This totally makes sense, don't you see?"
Not only are your technical proposals flawed, your logic is completely backwards.
On Sat, May 2, 2026 at 3:27 AM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Marco
There is no point where shareholders will ask 'where is my ipv6 presence' they don't care.
Dear Mr shareholder give me 2m dollars for an ipv6 presence.
Shareholder what's not working
CTO nothing
Shareholder, you want 2m $ to fix something that's not broken -- and so we get to turn off what we have now and save a bunch of money.... THIS QUARTER
CTO nope
Sharholder : your fired.
🙂 And that's exactly why
Jamie
On Sat., May 2, 2026, 2:39 a.m. Mark Andrews via NANOG, < nanog@lists.nanog.org> wrote:
IPv4 only machines can reach IPv6 machines. It just requires a DNS46 implementation which was done as an experiment years ago and a CLAT with address mappings configured from the DNS46. This is known to not scale well but there are very little truely IPv4 equipment these days. It works on the small scale.
Now it would be nice if people would move to IPv6 sooner rather than later but now it’s mostly getting people to turn it on rather than waiting for equipment to support it. It will get to the stage where shareholders will start asking where is our IPv6 presence? Remember that everyone is paying more for these IPv4 only sites. Your home ISP / cellular provider has to charge you more to provide this backwards compatibility. A line item on the bill would make this clearer. Big ISPs aren’t turning off IPv6. They are turning off IPv4 towards the customer leaving IPv4 to be delivered via IPv4AAS.
-- Mark Andrews
On 2 May 2026, at 14:55, Marco Moock via NANOG < nanog@lists.nanog.org> wrote:
Am 02.05.26 um 05:13 schrieb Jamie Thain via NANOG:
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4. And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years.
If they are not willing to upgrade, they are also not willing to implement any other new protocol, as this always means that IPv4 only machines need to be changed, as you cannot make them able to reach non IPv4 machines without modifying them.
All of that stuff has being discussed many times...
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2EKXGBLS...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KU543YXN...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Y5ALPB5T... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TINMZBCV...
I find it funny that all these network protocols failed to replace TCP/IP6... *Network Protocols and Architectures Attempting to Replace or Supersede IPv6 (2000–Present)* *Overview* Since the early 2000s, multiple protocols and architectural frameworks have been proposed to either replace, augment, or fundamentally redesign the Internet Protocol (IP) stack—particularly IPv6. While very few have gained widespread adoption, these efforts fall into several categories: - Clean-slate Internet redesigns - Identity/locator separation models - Content-centric networking - Policy-driven or state-controlled architectures - Experimental or non-standard IP versions This document provides a structured list of such efforts, including their goals, design principles, and current status. ------------------------------ *Protocol and Architecture Summary* *1. IPv9 (China Decimal Network)* - *Year Introduced:* ~2004 - *Replacement Intent:* Claimed full replacement of IPv6 - *Core Concept:* Decimal-based addressing system; alternative DNS root model - *Objective:* Sovereign control over addressing and naming infrastructure - *Status:* Limited adoption; not recognized by global standards bodies ------------------------------ *2. ILNP (Identifier-Locator Network Protocol)* - *Year Introduced:* 2006–2012 - *Replacement Intent:* Evolutionary (not full replacement) - *Core Concept:* Separates endpoint identity from network location - *Objective:* Improve mobility, multihoming, and routing scalability - *Status:* Experimental (IRTF); compatible with IPv6 concepts ------------------------------ *3. LISP (Locator/ID Separation Protocol)* - *Year Introduced:* ~2006 - *Replacement Intent:* No (overlay architecture) - *Core Concept:* Decouples endpoint identifiers (EIDs) from routing locators (RLOCs) - *Objective:* Reduce global routing table size, improve mobility - *Status:* Standardized (RFC 9300); niche deployments ------------------------------ *4. RINA (Recursive InterNetwork Architecture)* - *Year Introduced:* ~2008 - *Replacement Intent:* Yes (clean-slate redesign) - *Core Concept:* Recursive layers of Inter-Process Communication (IPC) - *Objective:* Replace rigid TCP/IP layering with flexible, recursive design - *Status:* Research and experimental ------------------------------ *5. SCION (Scalability, Control, and Isolation On Next-generation Networks)* - *Year Introduced:* ~2009 - *Replacement Intent:* Partial / parallel Internet - *Core Concept:* Path-aware networking with cryptographic trust domains - *Objective:* Secure routing, isolation domains, resilience to attacks - *Status:* Most operationally mature alternative; limited real-world deployment ------------------------------ *6. NDN / CCN (Named Data Networking / Content-Centric Networking)* - *Year Introduced:* ~2010 - *Replacement Intent:* Yes (fundamental shift from IP) - *Core Concept:* Data is addressed by name rather than location - *Objective:* Optimize content distribution, caching, and security - *Status:* Active research; limited deployments ------------------------------ *7. MobilityFirst* - *Year Introduced:* ~2010 - *Replacement Intent:* Yes (research architecture) - *Core Concept:* Identity-based addressing with late binding to location - *Objective:* Handle mobility and disconnection as primary conditions - *Status:* NSF-funded research project ------------------------------ *8. XIA (eXpressive Internet Architecture)* - *Year Introduced:* ~2010 - *Replacement Intent:* Yes (research architecture) - *Core Concept:* Supports multiple principal types (hosts, services, content, etc.) - *Objective:* Flexible, evolvable Internet addressing model - *Status:* Research and prototype stage ------------------------------ *9. NEBULA* - *Year Introduced:* ~2010 - *Replacement Intent:* Yes (research architecture) - *Core Concept:* Secure, cloud-oriented networking with policy enforcement - *Objective:* Trustworthy cloud networking infrastructure - *Status:* Research project ------------------------------ *10. IPv10* - *Year Introduced:* ~2017–2020 - *Replacement Intent:* Claimed transition/replacement - *Core Concept:* Hybrid IPv4/IPv6 packet structure - *Objective:* Smooth transition between IPv4 and IPv6 - *Status:* Internet-Draft only; no adoption ------------------------------ *11. New IP (Huawei / ITU Network 2030)* - *Year Introduced:* ~2019–2022 - *Replacement Intent:* Yes / parallel architecture - *Core Concept:* Variable-length addressing, deterministic networking, centralized control - *Objective:* Enable strict QoS, industrial control, and policy enforcement - *Concerns:* Centralization, fragmentation of global Internet - *Status:* Controversial; not adopted by IETF ------------------------------ *12. IPv8 (draft-thain-ipv8)* - *Year Introduced:* 2026 - *Replacement Intent:* Claimed full replacement - *Core Concept:* Fully managed network stack integrating: - DNS8 (naming) - DHCP8 (configuration) - WHOIS8 (route validation) - OAuth/JWT-based authorization - *Objective:* Unified control plane for identity, routing, and policy - *Status:* Early Internet-Draft; not standardized ------------------------------ *Key Observations* *1. True IPv6 Replacements Are Rare* Most proposals do not directly replace IPv6 but instead: - Overlay on top of IP (e.g., LISP) - Extend IPv6 concepts (e.g., ILNP) - Operate as parallel architectures (e.g., SCION) ------------------------------ *2. Clean-Slate Architectures Remain Experimental* Projects like: - RINA - NDN - MobilityFirst - XIA - NEBULA have strong theoretical foundations but lack global deployment due to: - Compatibility challenges - Economic inertia - Operational complexity ------------------------------ *3. Security and Control Are Major Drivers* Modern proposals focus heavily on: - Cryptographic identity (SCION, NDN) - Policy enforcement (New IP, IPv8) - Routing trust and validation ------------------------------ *4. SCION Is the Most Operationally Viable Alternative* Among all candidates: - Demonstrates real-world deployment - Provides strong security and path control - Still coexists with IP rather than replacing it ------------------------------ *5. Controversial Centralized Models* Architectures like *New IP* and *IPv8* introduce: - Tight integration of identity and policy - Centralized control mechanisms These raise concerns around: - Internet fragmentation - Surveillance and governance risks ------------------------------ *Conclusion* Despite numerous attempts over the past 25+ years, *IPv6 remains the dominant and only globally standardized next-generation Internet Protocol*. The most viable future direction is not outright replacement, but: - Incremental evolution (e.g., SRv6, QUIC, encrypted DNS) - Overlay and hybrid architectures (e.g., SCION, LISP) - Integration with security and identity frameworks The industry trend suggests *augmentation—not replacement—of IPv6* will define the next phase of Internet evolution. 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 Sat, May 2, 2026 at 4:37 PM Joe Klein <jsklein@gmail.com> wrote:
I find it funny that all these network protocols failed to replace TCP/IP4... Before TCP/IP became the universal standard, the "Protocol Wars" of the 1980s and 90s featured several heavyweights that were once "all the rage." These protocols often prioritised performance on local networks or were backed by massive government and corporate interests that explicitly aimed to avoid the "ad-hoc" nature of the U.S. Department of Defense's TCP/IP suite. [1 <https://en.wikipedia.org/wiki/Protocol_Wars>, 2 <https://en.wikipedia.org/wiki/Protocol_Wars>, 3 <https://www.britannica.com/technology/TCP-IP>] The Most Prominent Alternatives
- IPX/SPX (Novell NetWare): The king of the 1980s LAN. It was "awesomesauce" for local offices because it was plug-and-play, using a computer's MAC address as its network identity. It was faster and lighter than early TCP/IP but struggled to scale for the global internet. - OSI (Open Systems Interconnection): A massive, 7-layer theoretical framework developed by international committees. European governments and the U.S. Department of Commerce even mandated its use for a time, viewing TCP/IP as a temporary military experiment. It ultimately failed because it was too complex and arrived too late with working code. - AppleTalk: Designed for early Macintosh networks, it was remarkably user-friendly and allowed printers and computers to "find" each other automatically. However, it was "chatty," sending constant background updates that could overwhelm larger networks. - SNA (Systems Network Architecture): IBM's proprietary powerhouse for connecting mainframes. It was reliable and sophisticated for corporate environments but kept users locked into the IBM ecosystem. - DECnet: Digital Equipment Corporation's suite for its VAX systems. Like SNA, it was highly capable but ultimately proprietary. [1 <https://en.wikipedia.org/wiki/Protocol_Wars>, 2 <https://www.quora.com/How-do-TCP-IP-and-IPX-SPX-differ>, 3 <https://www.reddit.com/r/explainlikeimfive/comments/45c108/eli5_what_is_ipx_protocol_and_why_have_we_moved/>, 4 <https://en.wikipedia.org/wiki/Internetwork_Packet_Exchange>, 5 <https://www.americantv.com/ipx-spx.php>, 6 <https://www.fortinet.com/resources/cyberglossary/tcp-ip-model-vs-osi-model>, 7 <https://www.geeksforgeeks.org/computer-networks/difference-between-osi-model-and-tcp-ip-model/>, 8 <https://www.quora.com/What-were-the-alternatives-to-TCP-IP-when-the-Internet-was-formed>, 9 <https://retrocomputing.stackexchange.com/questions/29823/what-were-the-major-things-that-caused-tcp-ip-to-become-the-internet-standard-pr>, 10 <https://www.myweb.ttu.edu/csmith/Protocols.html>, 11 <https://www.quora.com/Are-there-any-networks-today-that-dont-use-TCP-IP>, 12 <https://www.reddit.com/r/networking/comments/16f2zwi/how_would_the_internet_infrastructure_today_look/>, 13 <https://www.quora.com/Why-is-TCP-IP-still-the-core-protocol-of-the-Internet-and-are-there-any-potential-replacements-or-improvements-in-the-works> ]
------------------------------ 🛡️ Why They "Lost" to TCP/IP
- The "Design by Committee" Trap: The OSI suite became bloated because every participating country wanted their specific features included, making it nearly impossible to implement efficiently. - Pragmatism vs. Theory: TCP/IP was built by researchers who wrote the code first and the standards later. It was "good enough" and already running on Unix systems everywhere by the time competitors were still arguing over specs. - The Rise of the Web: When the World Wide Web launched in the early 90s, it ran on TCP/IP. To access the "new" internet, everyone was forced to adopt the protocol, rendering the proprietary alternatives obsolete. [1 <https://www.quora.com/It-has-been-said-that-the-OSI-model-won-the-battle-but-lost-the-war-against-TCP-IP-Why-do-you-think-this-is-so>, 2 <https://www.youtube.com/watch?v=TxBTdOOV2ts&t=6>, 3 <http://www.sci.brooklyn.cuny.edu/~parsons/courses/3120-fall-2012/notes/tcp-ip-notes.pdf>, 4 <https://en.wikipedia.org/wiki/Protocol_Wars>, 5 <https://retrocomputing.stackexchange.com/questions/29823/what-were-the-major-things-that-caused-tcp-ip-to-become-the-internet-standard-pr> ]
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 Sat, May 2, 2026, 1:34 PM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
Essentially your arguments boil down to :
"Some companies don't want to spend money to implement V6. My solution is a new IP version 8, which would require EVERY company to spend money to implement. This totally makes sense, don't you see?"
Not only are your technical proposals flawed, your logic is completely backwards.
On Sat, May 2, 2026 at 3:27 AM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Marco
There is no point where shareholders will ask 'where is my ipv6 presence' they don't care.
Dear Mr shareholder give me 2m dollars for an ipv6 presence.
Shareholder what's not working
CTO nothing
Shareholder, you want 2m $ to fix something that's not broken -- and so we get to turn off what we have now and save a bunch of money.... THIS QUARTER
CTO nope
Sharholder : your fired.
🙂 And that's exactly why
Jamie
On Sat., May 2, 2026, 2:39 a.m. Mark Andrews via NANOG, < nanog@lists.nanog.org> wrote:
IPv4 only machines can reach IPv6 machines. It just requires a DNS46 implementation which was done as an experiment years ago and a CLAT with address mappings configured from the DNS46. This is known to not scale well but there are very little truely IPv4 equipment these days. It works on the small scale.
Now it would be nice if people would move to IPv6 sooner rather than later but now it’s mostly getting people to turn it on rather than waiting for equipment to support it. It will get to the stage where shareholders will start asking where is our IPv6 presence? Remember that everyone is paying more for these IPv4 only sites. Your home ISP / cellular provider has to charge you more to provide this backwards compatibility. A line item on the bill would make this clearer. Big ISPs aren’t turning off IPv6. They are turning off IPv4 towards the customer leaving IPv4 to be delivered via IPv4AAS.
-- Mark Andrews
On 2 May 2026, at 14:55, Marco Moock via NANOG < nanog@lists.nanog.org> wrote:
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4. And no corporate is migrating go look. Its been the next big
Am 02.05.26 um 05:13 schrieb Jamie Thain via NANOG: thing in
Corporate networks for 20 years.
If they are not willing to upgrade, they are also not willing to implement any other new protocol, as this always means that IPv4 only machines need to be changed, as you cannot make them able to reach non IPv4 machines without modifying them.
All of that stuff has being discussed many times...
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2EKXGBLS...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KU543YXN...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Y5ALPB5T... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TINMZBCV...
Code is extremely malleable. You are not building a lunar lander. It will not explode, kill three people and humiliate a nation if you get it wrong. You will just observe that it is wrong and change it until it is right. This gives you plentiful opportunities to discover things for yourself instead of spamming this mailing list with stupid arguments. For example, if you actually write an IPv8 implementation, you can try connecting it to an IPv4 implementation. You will discover whether it actually works or not. This is infinitely more valuable than an argument. On 2 May 2026 20:05:47 CEST, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Justin,
Because before you write a line of code you have to get it right, or near right.
If you want to see good engineering watch from the "Earth to the Moon" Spider, how they built the lunar lander.
So far I've had like 3 serious conversations about "this won't work" and each one has had me improve it. But "go make code" before we discuss what and how it should be, a DRAFT is actually when you want comments about the operation of it all.
I'm not going to wait until I written 1m worth of code to figure something is wrong.
IETF folks suggested to me, that I join Nanog to see how they might use it. IPv8 is not about address space.
Jamie
On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG <nanog@lists.nanog.org> wrote:
I know of enterprises who are deploying v6.
Until you can show the world a working IPv8 implementation on a large using off-the-shelf components where people can run through failure scenarios and really beat it up, not many people are going to take it seriously.
Lower layers of the network relying on the functionality of higher layers is a really, really, really bad idea.
While it's always important to think about how to so something better, v8 seems to create a whole bunch of new problems while not solving many that have already been addressed in v6 and other protocols.
Thank you jms
On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Andrew,
Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 in a meeting and two corp engineers laughed.
You can google it yourself.
Jamie
On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
If no corporation is migrating then why is IPv6 traffic continuing to increase?
As I pointed out, IPv6 traffic increased 5% last year. At that admittedly slow rate, the entire internet will be IPv6 in 10 years.
Further your assertion that business is the prime mover is incorrect. Business will move when they have to. That time is coming.
When businesses can’t get IPv4 from their providers or superscaler, or a vendor or client can’t reach them, they will move.
Andrew
On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Andrew,
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4.
And no corporate is migrating go look. Its been the next big thing in Corporate networks for 20 years.
Jamie
On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
I oppose this. With IPv6 traffic now representing around half of internet traffic, the time to rethink has long passed.
If IPv8 was going to be a solution, it should have been a solution 10 years ago.
In the last 12 months, ~5% of traffic migrated to IPv6. At that rate, IPv6 will be fully implemented by 2035. I'm not seeing a problem that needs to be solved, or a credible solution.
Andrew
On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
> Hi All, > > My name is Jamie Thain I'm the creator of IPv8. It's not a hoax. > > I joined this list because, as part of IPv8, I am creating a BGPv8. Inside > BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the > routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP to > create better engineering results. > > I also as part of CF created Sun Tzu which is the protocol that watches CF > and gives you a CF score of reliability. Do I trust my partnership with > you? > > Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, > etc, etc. That's not my discussion point. My point isn't "should I even > propose IPv8" my point is what would be the best result for operators? > > I believe that since IPv8 solves the duopoly problem, it will replace > IPv4. > > So the things to know, IPV8 is NOT a 64 bit addressing system. > > It is a 32 bit routing system with a 32 bit addressing system. > > A Routing Number = ASNs plus others. > > 8.8.8.8 would become 15169.8.8.8.8 > > https://www.ietf.org/archive/id/draft-thain-ipv8-02.html [https://www.ietf.org/archive/id/draft-thain-ipv8-02.html] > < > https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea [https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea] 3372a?u=12457652 > > > > > So each ASN in the world will have 3 Billion available addresses. > > There is a specially reserved group of internal ASN 127.x.x.x so each corp, > org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and > 100.64.x.x.x > > I'd appreciate your thoughts on it > > Jamie > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/ > _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA...]
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2MY7QMH6...]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D] _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JTNFIASL...
Joe, I was there, I was the first person in Canada to configure IPX / SPX and Oracle on a Novell Server, while running the Client TCP/IP, IPX/SPX, SNA on OS/2. For a while I was teaching the Oracle Canada folks how to do it. In 1992, I was called into my boss's office at Ontario Hydro. He said, OH is thinking of implementing OSI what do you think. And my answer was, "Don't bother, OSI has already lost." I took him over to my desk and connected to the mainframe via TN3270 (experimental connection); you can see it's already working. We are years away from achieving OSI. But I had to learn the OSI software that did the equivalent that was already built in IP. And that's the story of why IPv8. Because its really IPv4 V2 its an inplace upgrade of what we have. The minimal world is 1 IPclient -- 1 XLATE 8 (can be on the client) --- a whole series of IPv4 stuff -- Some *IPv8 router *in the world, with Anycast configured in DNS8. The client has XLATE on it, it looks up the DNS entry for www.ipv8sample.org, which has an A8 DNS record that says the asn.address for example *A8 12456-12.34.56.78* It looks up *anycast.12456.asn.arpa* and gets an A record point to the anycast address of that ASN which is configured on the IPv8 router. For example 50.40.30.20 And the the client encapsulates the ipv8 in an ipv4 packet and sends it to 50.40.30.20 And because its only encapsulating and translating and IPv8 is just IPv4 with a routing number. ITS very simple. Jamie On Sat, May 2, 2026 at 5:38 PM Joe Klein via NANOG <nanog@lists.nanog.org> wrote:
I find it funny that all these network protocols failed to replace TCP/IP4... Before TCP/IP became the universal standard, the "Protocol Wars" of the 1980s and 90s featured several heavyweights that were once "all the rage." These protocols often prioritised performance on local networks or were backed by massive government and corporate interests that explicitly aimed to avoid the "ad-hoc" nature of the U.S. Department of Defense's TCP/IP suite. [1 <https://en.wikipedia.org/wiki/Protocol_Wars>, 2 <https://en.wikipedia.org/wiki/Protocol_Wars>, 3 <https://www.britannica.com/technology/TCP-IP>] The Most Prominent Alternatives
- IPX/SPX (Novell NetWare): The king of the 1980s LAN. It was "awesomesauce" for local offices because it was plug-and-play, using a computer's MAC address as its network identity. It was faster and lighter than early TCP/IP but struggled to scale for the global internet. - OSI (Open Systems Interconnection): A massive, 7-layer theoretical framework developed by international committees. European governments and the U.S. Department of Commerce even mandated its use for a time, viewing TCP/IP as a temporary military experiment. It ultimately failed because it was too complex and arrived too late with working code. - AppleTalk: Designed for early Macintosh networks, it was remarkably user-friendly and allowed printers and computers to "find" each other automatically. However, it was "chatty," sending constant background updates that could overwhelm larger networks. - SNA (Systems Network Architecture): IBM's proprietary powerhouse for connecting mainframes. It was reliable and sophisticated for corporate environments but kept users locked into the IBM ecosystem. - DECnet: Digital Equipment Corporation's suite for its VAX systems. Like SNA, it was highly capable but ultimately proprietary. [1 <https://en.wikipedia.org/wiki/Protocol_Wars>, 2 <https://www.quora.com/How-do-TCP-IP-and-IPX-SPX-differ>, 3 <https://www.reddit.com/r/explainlikeimfive/comments/45c108 /eli5_what_is_ipx_protocol_and_why_have_we_moved/>, 4 <https://en.wikipedia.org/wiki/Internetwork_Packet_Exchange>, 5 <https://www.americantv.com/ipx-spx.php>, 6 <https://www.fortinet.com/resources/cyberglossary/tcp-ip- model-vs-osi-model>, 7 <https://www.geeksforgeeks.org/computer-networks/difference -between-osi-model-and-tcp-ip-model/>, 8 <https://www.quora.com/What-were-the-alternatives-to-TCP-IP -when-the-Internet-was-formed>, 9 <https://retrocomputing.stackexchange.com/questions/29823/ what-were-the-major-things-that-caused-tcp-ip-to-become- the-internet-standard-pr>, 10 <https://www.myweb.ttu.edu/csmith/Protocols.html>, 11 <https://www.quora.com/Are-there-any-networks-today-that-do nt-use-TCP-IP>, 12 <https://www.reddit.com/r/networking/comments/16f2zwi/how_ would_the_internet_infrastructure_today_look/>, 13 <https://www.quora.com/Why-is-TCP-IP-still-the-core-proto col-of-the-Internet-and-are-there-any-potential-replacemen ts-or-improvements-in-the-works> ]
------------------------------ 🛡️Why They "Lost" to TCP/IP
- The "Design by Committee" Trap: The OSI suite became bloated because every participating country wanted their specific features included, making it nearly impossible to implement efficiently. - Pragmatism vs. Theory: TCP/IP was built by researchers who wrote the code first and the standards later. It was "good enough" and already running on Unix systems everywhere by the time competitors were still arguing over specs. - The Rise of the Web: When the World Wide Web launched in the early 90s, it ran on TCP/IP. To access the "new" internet, everyone was forced to adopt the protocol, rendering the proprietary alternatives obsolete. [1 <https://www.quora.com/It-has-been-said-that-the-OSI- model-won-the-battle-but-lost-the-war-against-TCP-IP-Why-do- you-think-this-is-so>, 2 <https://www.youtube.com/watch?v=TxBTdOOV2ts&t=6>, 3 <http://www.sci.brooklyn.cuny.edu/~parsons/courses/ 3120-fall-2012/notes/tcp-ip-notes.pdf>, 4 <https://en.wikipedia.org/wiki/Protocol_Wars>, 5 <https://retrocomputing.stackexchange.com/questions/29823/ what-were-the-major-things-that-caused-tcp-ip-to-become- the-internet-standard-pr> ]
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 Sat, May 2, 2026, 1:34 PM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
Essentially your arguments boil down to :
"Some companies don't want to spend money to implement V6. My solution is a new IP version 8, which would require EVERY company to spend money to implement. This totally makes sense, don't you see?"
Not only are your technical proposals flawed, your logic is completely backwards.
On Sat, May 2, 2026 at 3:27 AM Jamie Thain via NANOG < nanog@lists.nanog.org> wrote:
Marco
There is no point where shareholders will ask 'where is my ipv6 presence' they don't care.
Dear Mr shareholder give me 2m dollars for an ipv6 presence.
Shareholder what's not working
CTO nothing
Shareholder, you want 2m $ to fix something that's not broken -- and so we get to turn off what we have now and save a bunch of money.... THIS QUARTER
CTO nope
Sharholder : your fired.
🙂And that's exactly why
Jamie
On Sat., May 2, 2026, 2:39 a.m. Mark Andrews via NANOG, < nanog@lists.nanog.org> wrote:
IPv4 only machines can reach IPv6 machines. It just requires a DNS46 implementation which was done as an experiment years ago and a CLAT with address mappings configured from the DNS46. This is known to not scale well but there are very little truely IPv4 equipment these days. It works on the small scale.
Now it would be nice if people would move to IPv6 sooner rather than later but now it’s mostly getting people to turn it on rather than waiting for equipment to support it. It will get to the stage where shareholders will start asking where is our IPv6 presence? Remember that everyone is paying more for these IPv4 only sites. Your home ISP / cellular provider has to charge you more to provide this backwards compatibility. A line item on the bill would make this clearer. Big ISPs aren’t turning off IPv6. They are turning off IPv4 towards the customer leaving IPv4 to be delivered via IPv4AAS.
-- Mark Andrews
On 2 May 2026, at 14:55, Marco Moock via NANOG < nanog@lists.nanog.org> wrote:
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4. And no corporate is migrating go look. Its been the next big
Am 02.05.26 um 05:13 schrieb Jamie Thain via NANOG: thing in
Corporate networks for 20 years.
If they are not willing to upgrade, they are also not willing to implement any other new protocol, as this always means that IPv4 only machines need to be changed, as you cannot make them able to reach non IPv4 machines without modifying them.
All of that stuff has being discussed many times...
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/2EKXGBLSTHXPUSME3ZEREOLD64DIPMDG/
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/KU543YXNZ5CT357EWVALU67EJS4QBT5L/
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/Y5ALPB5T42UFLDKYL3L2XRMM4SYWHM42/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/TINMZBCVA3KPCO6TM6BUKNHAIKYJFBGN/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/D4DPIWV2REVD5IQ6ZCFUZBOAQGY3DZGD/
Joe, And your LLM didn't capture my intent. My intent has nothing to do with IPv6 and everything to do with upgrading IPv4. Ask LLMs all day long when is IPv4 dying... Never. I've only ever put IPv6 in a lab, it was Ok. But I had to study for a month. Whos going to do that? From my friend Claude. Question: At the present pace when will IPv4 be sunset, and what year will IPv6 have more than 50% enterprise, non service provider, traction? IPv4 sunset * No credible sunset date on the current trajectory — IPv4 still dominates public internet traffic outside mobile and hyperscaler edges as of early 2026. * Registry exhaustion (ARIN, RIPE, APNIC) did not force migration; it created a liquid transfer market with addresses trading at roughly $40–$60 each. * Enterprise IPv4 use is not declining — it is being recycled, leased, and more aggressively NAT'd. * Honest extrapolation puts any serious deprecation conversation at 2045 or later, and only if a forcing function appears (regulatory action, ASIC vendor pressure, or a major carrier mandate) — none of which currently exist. * More accurate framing: IPv4 persists indefinitely in dual-stack or translated form, similar to how SS7 and parts of the PSTN remain economically alive long after technical obsolescence. IPv6 enterprise traction (excluding service providers, mobile, hyperscaler internal fabrics) * The often-cited 45%+ Google/APNIC figures are skewed by mobile and carrier traffic; true enterprise penetration is much lower. * Real enterprise penetration — IPv6 as the primary internal protocol on end-user and server subnets, not just WAN edge — sits at roughly 8–12% depending on the survey. * Growth rate has been about half a percentage point per year for most of the last decade. * At that pace, 50% enterprise traction lands in the 2070s. * Optimistic case (cloud-native greenfield acceleration plus eventual ASIC pressure): 2045–2050. * Pessimistic case: enterprise IPv6 never crosses 50% because NAT44, CGNAT, and SD-WAN overlays continue masking the address shortage well enough that the migration business case never closes. Why both timelines are so long * IPv6 wasn't a surgical fix for address exhaustion — it bundled the address-space change with a full redesign of neighbor discovery, autoconfiguration, header structure, and operational tooling. * That bundling means migration cost is paid in operational retraining, vendor tooling churn, and security model changes, not just in address allocation. * Enterprises rationally defer that cost as long as NAT and the transfer market keep working — and they will, for the foreseeable future. Bottom line * IPv4 sunset: not on the current trajectory, ever. * IPv6 majority enterprise traction: somewhere between 2055 and never, with 2050 as an aggressive optimistic bound. On Sat, May 2, 2026 at 5:42 PM Joe Klein via NANOG <nanog@lists.nanog.org> wrote:
I find it funny that all these network protocols failed to replace TCP/IP6...
*Network Protocols and Architectures Attempting to Replace or Supersede IPv6 (2000–Present)* *Overview*
Since the early 2000s, multiple protocols and architectural frameworks have been proposed to either replace, augment, or fundamentally redesign the Internet Protocol (IP) stack—particularly IPv6. While very few have gained widespread adoption, these efforts fall into several categories:
- Clean-slate Internet redesigns - Identity/locator separation models - Content-centric networking - Policy-driven or state-controlled architectures - Experimental or non-standard IP versions
This document provides a structured list of such efforts, including their goals, design principles, and current status. ------------------------------ *Protocol and Architecture Summary* *1. IPv9 (China Decimal Network)*
- *Year Introduced:* ~2004 - *Replacement Intent:* Claimed full replacement of IPv6 - *Core Concept:* Decimal-based addressing system; alternative DNS root model - *Objective:* Sovereign control over addressing and naming infrastructure - *Status:* Limited adoption; not recognized by global standards bodies
------------------------------ *2. ILNP (Identifier-Locator Network Protocol)*
- *Year Introduced:* 2006–2012 - *Replacement Intent:* Evolutionary (not full replacement) - *Core Concept:* Separates endpoint identity from network location - *Objective:* Improve mobility, multihoming, and routing scalability - *Status:* Experimental (IRTF); compatible with IPv6 concepts
------------------------------ *3. LISP (Locator/ID Separation Protocol)*
- *Year Introduced:* ~2006 - *Replacement Intent:* No (overlay architecture) - *Core Concept:* Decouples endpoint identifiers (EIDs) from routing locators (RLOCs) - *Objective:* Reduce global routing table size, improve mobility - *Status:* Standardized (RFC 9300); niche deployments
------------------------------ *4. RINA (Recursive InterNetwork Architecture)*
- *Year Introduced:* ~2008 - *Replacement Intent:* Yes (clean-slate redesign) - *Core Concept:* Recursive layers of Inter-Process Communication (IPC) - *Objective:* Replace rigid TCP/IP layering with flexible, recursive design - *Status:* Research and experimental
------------------------------ *5. SCION (Scalability, Control, and Isolation On Next-generation Networks)*
- *Year Introduced:* ~2009 - *Replacement Intent:* Partial / parallel Internet - *Core Concept:* Path-aware networking with cryptographic trust domains - *Objective:* Secure routing, isolation domains, resilience to attacks - *Status:* Most operationally mature alternative; limited real-world deployment
------------------------------ *6. NDN / CCN (Named Data Networking / Content-Centric Networking)*
- *Year Introduced:* ~2010 - *Replacement Intent:* Yes (fundamental shift from IP) - *Core Concept:* Data is addressed by name rather than location - *Objective:* Optimize content distribution, caching, and security - *Status:* Active research; limited deployments
------------------------------ *7. MobilityFirst*
- *Year Introduced:* ~2010 - *Replacement Intent:* Yes (research architecture) - *Core Concept:* Identity-based addressing with late binding to location - *Objective:* Handle mobility and disconnection as primary conditions - *Status:* NSF-funded research project
------------------------------ *8. XIA (eXpressive Internet Architecture)*
- *Year Introduced:* ~2010 - *Replacement Intent:* Yes (research architecture) - *Core Concept:* Supports multiple principal types (hosts, services, content, etc.) - *Objective:* Flexible, evolvable Internet addressing model - *Status:* Research and prototype stage
------------------------------ *9. NEBULA*
- *Year Introduced:* ~2010 - *Replacement Intent:* Yes (research architecture) - *Core Concept:* Secure, cloud-oriented networking with policy enforcement - *Objective:* Trustworthy cloud networking infrastructure - *Status:* Research project
------------------------------ *10. IPv10*
- *Year Introduced:* ~2017–2020 - *Replacement Intent:* Claimed transition/replacement - *Core Concept:* Hybrid IPv4/IPv6 packet structure - *Objective:* Smooth transition between IPv4 and IPv6 - *Status:* Internet-Draft only; no adoption
------------------------------ *11. New IP (Huawei / ITU Network 2030)*
- *Year Introduced:* ~2019–2022 - *Replacement Intent:* Yes / parallel architecture - *Core Concept:* Variable-length addressing, deterministic networking, centralized control - *Objective:* Enable strict QoS, industrial control, and policy enforcement - *Concerns:* Centralization, fragmentation of global Internet - *Status:* Controversial; not adopted by IETF
------------------------------ *12. IPv8 (draft-thain-ipv8)*
- *Year Introduced:* 2026 - *Replacement Intent:* Claimed full replacement - *Core Concept:* Fully managed network stack integrating: - DNS8 (naming) - DHCP8 (configuration) - WHOIS8 (route validation) - OAuth/JWT-based authorization - *Objective:* Unified control plane for identity, routing, and policy - *Status:* Early Internet-Draft; not standardized
------------------------------
*Key Observations* *1. True IPv6 Replacements Are Rare*
Most proposals do not directly replace IPv6 but instead:
- Overlay on top of IP (e.g., LISP) - Extend IPv6 concepts (e.g., ILNP) - Operate as parallel architectures (e.g., SCION)
------------------------------ *2. Clean-Slate Architectures Remain Experimental*
Projects like:
- RINA - NDN - MobilityFirst - XIA - NEBULA
have strong theoretical foundations but lack global deployment due to:
- Compatibility challenges - Economic inertia - Operational complexity
------------------------------ *3. Security and Control Are Major Drivers*
Modern proposals focus heavily on:
- Cryptographic identity (SCION, NDN) - Policy enforcement (New IP, IPv8) - Routing trust and validation
------------------------------ *4. SCION Is the Most Operationally Viable Alternative*
Among all candidates:
- Demonstrates real-world deployment - Provides strong security and path control - Still coexists with IP rather than replacing it
------------------------------ *5. Controversial Centralized Models*
Architectures like *New IP* and *IPv8* introduce:
- Tight integration of identity and policy - Centralized control mechanisms
These raise concerns around:
- Internet fragmentation - Surveillance and governance risks
------------------------------ *Conclusion*
Despite numerous attempts over the past 25+ years, *IPv6 remains the dominant and only globally standardized next-generation Internet Protocol*.
The most viable future direction is not outright replacement, but:
- Incremental evolution (e.g., SRv6, QUIC, encrypted DNS) - Overlay and hybrid architectures (e.g., SCION, LISP) - Integration with security and identity frameworks
The industry trend suggests *augmentation—not replacement—of IPv6* will define the next phase of Internet evolution.
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 Sat, May 2, 2026 at 4:37 PM Joe Klein <jsklein@gmail.com [jsklein@gmail.com]> wrote:
I find it funny that all these network protocols failed to replace TCP/IP4... Before TCP/IP became the universal standard, the "Protocol Wars" of the 1980s and 90s featured several heavyweights that were once "all the rage." These protocols often prioritised performance on local networks or were backed by massive government and corporate interests that explicitly aimed to avoid the "ad-hoc" nature of the U.S. Department of Defense's TCP/IP suite. [1 <https://en.wikipedia.org/wiki/Protocol_Wars [https://en.wikipedia.org/wiki/Protocol_Wars]>, 2 <https://en.wikipedia.org/wiki/Protocol_Wars [https://en.wikipedia.org/wiki/Protocol_Wars]>, 3 <https://www.britannica.com/technology/TCP-IP [https://www.britannica.com/technology/TCP-IP]>] The Most Prominent Alternatives
- IPX/SPX (Novell NetWare): The king of the 1980s LAN. It was "awesomesauce" for local offices because it was plug-and-play, using a computer's MAC address as its network identity. It was faster and lighter than early TCP/IP but struggled to scale for the global internet. - OSI (Open Systems Interconnection): A massive, 7-layer theoretical framework developed by international committees. European governments and the U.S. Department of Commerce even mandated its use for a time, viewing TCP/IP as a temporary military experiment. It ultimately failed because it was too complex and arrived too late with working code. - AppleTalk: Designed for early Macintosh networks, it was remarkably user-friendly and allowed printers and computers to "find" each other automatically. However, it was "chatty," sending constant background updates that could overwhelm larger networks. - SNA (Systems Network Architecture): IBM's proprietary powerhouse for connecting mainframes. It was reliable and sophisticated for corporate environments but kept users locked into the IBM ecosystem. - DECnet: Digital Equipment Corporation's suite for its VAX systems. Like SNA, it was highly capable but ultimately proprietary. [1 <https://en.wikipedia.org/wiki/Protocol_Wars [https://en.wikipedia.org/wiki/Protocol_Wars]>, 2 <https://www.quora.com/How-do-TCP-IP-and-IPX-SPX-differ [https://www.quora.com/How-do-TCP-IP-and-IPX-SPX-differ]>, 3 <https://www.reddit.com/r/explainlikeimfive/comments/45c108/ eli5_what_is_ipx_protocol_and_why_have_we_moved/ [https://www.reddit.com/r/explainlikeimfive/comments/45c108/eli5_what_is_ipx_...] , 4 <https://en.wikipedia.org/wiki/Internetwork_Packet_Exchange [https://en.wikipedia.org/wiki/Internetwork_Packet_Exchange]>, 5 <https://www.americantv.com/ipx-spx.php [https://www.americantv.com/ipx-spx.php]>, 6 <https://www.fortinet.com/resources/cyberglossary/tcp-ip- model-vs-osi-model [https://www.fortinet.com/resources/cyberglossary/tcp-ip-model-vs-osi-model]>, 7 <https://www.geeksforgeeks.org/computer-networks/difference- between-osi-model-and-tcp-ip-model/ [https://www.geeksforgeeks.org/computer-networks/difference-between-osi-model...] , 8 <https://www.quora.com/What-were-the-alternatives-to-TCP-IP- when-the-Internet-was-formed [https://www.quora.com/What-were-the-alternatives-to-TCP-IP-when-the-Internet-was-formed]>, 9 <https://retrocomputing.stackexchange.com/questions/29823/ what-were-the-major-things-that-caused-tcp-ip-to-become- the-internet-standard-pr [https://retrocomputing.stackexchange.com/questions/29823/what-were-the-major-things-that-caused-tcp-ip-to-become-the-internet-standard-pr]>, 10 <https://www.myweb.ttu.edu/csmith/Protocols.html [https://www.myweb.ttu.edu/csmith/Protocols.html]>, 11 <https://www.quora.com/Are-there-any-networks-today-that-dont-use-TCP-IP [https://www.quora.com/Are-there-any-networks-today-that-dont-use-TCP-IP]>, 12 <https://www.reddit.com/r/networking/comments/16f2zwi/how_ would_the_internet_infrastructure_today_look/ [https://www.reddit.com/r/networking/comments/16f2zwi/how_would_the_internet_...] , 13 <https://www.quora.com/Why-is-TCP-IP-still-the-core-protocol -of-the-Internet-and-are-there-any-potential-replacemen ts-or-improvements-in-the-works [https://www.quora.com/Why-is-TCP-IP-still-the-core-protocol-of-the-Internet-...]
]
------------------------------ 🛡️Why They "Lost" to TCP/IP
- The "Design by Committee" Trap: The OSI suite became bloated because every participating country wanted their specific features included, making it nearly impossible to implement efficiently. - Pragmatism vs. Theory: TCP/IP was built by researchers who wrote the code first and the standards later. It was "good enough" and already running on Unix systems everywhere by the time competitors were still arguing over specs. - The Rise of the Web: When the World Wide Web launched in the early 90s, it ran on TCP/IP. To access the "new" internet, everyone was forced to adopt the protocol, rendering the proprietary alternatives obsolete. [1 <https://www.quora.com/It-has-been-said-that-the-OSI-model-w on-the-battle-but-lost-the-war-against-TCP-IP-Why-do-you-think-this-is-so [https://www.quora.com/It-has-been-said-that-the-OSI-model-won-the-battle-but...] , 2 <https://www.youtube.com/watch?v=TxBTdOOV2ts&t=6 [https://www.youtube.com/watch?v=TxBTdOOV2ts&t=6]>, 3 <http://www.sci.brooklyn.cuny.edu/~parsons/courses/3120-fall -2012/notes/tcp-ip-notes.pdf [http://www.sci.brooklyn.cuny.edu/~parsons/courses/3120-fall-2012/notes/tcp-ip-notes.pdf]>, 4 <https://en.wikipedia.org/wiki/Protocol_Wars [https://en.wikipedia.org/wiki/Protocol_Wars]>, 5 <https://retrocomputing.stackexchange.com/questions/29823/ what-were-the-major-things-that-caused-tcp-ip-to-become- the-internet-standard-pr [https://retrocomputing.stackexchange.com/questions/29823/what-were-the-major-things-that-caused-tcp-ip-to-become-the-internet-standard-pr]> ]
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 Sat, May 2, 2026, 1:34 PM Tom Beecher via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Essentially your arguments boil down to :
"Some companies don't want to spend money to implement V6. My solution is a new IP version 8, which would require EVERY company to spend money to implement. This totally makes sense, don't you see?"
Not only are your technical proposals flawed, your logic is completely backwards.
On Sat, May 2, 2026 at 3:27 AM Jamie Thain via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Marco
There is no point where shareholders will ask 'where is my ipv6 presence' they don't care.
Dear Mr shareholder give me 2m dollars for an ipv6 presence.
Shareholder what's not working
CTO nothing
Shareholder, you want 2m $ to fix something that's not broken -- and so we get to turn off what we have now and save a bunch of money.... THIS QUARTER
CTO nope
Sharholder : your fired.
🙂And that's exactly why
Jamie
On Sat., May 2, 2026, 2:39 a.m. Mark Andrews via NANOG, < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
IPv4 only machines can reach IPv6 machines. It just requires a DNS46 implementation which was done as an experiment years ago and a CLAT with address mappings configured from the DNS46. This is known to not scale well but there are very little truely IPv4 equipment these days. It works on the small scale.
Now it would be nice if people would move to IPv6 sooner rather than later but now it’s mostly getting people to turn it on rather than waiting for equipment to support it. It will get to the stage where shareholders will start asking where is our IPv6 presence? Remember that everyone is paying more for these IPv4 only sites. Your home ISP / cellular provider has to charge you more to provide this backwards compatibility. A line item on the bill would make this clearer. Big ISPs aren’t turning off IPv6. They are turning off IPv4 towards the customer leaving IPv4 to be delivered via IPv4AAS.
-- Mark Andrews
On 2 May 2026, at 14:55, Marco Moock via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Am 02.05.26 um 05:13 schrieb Jamie Thain via NANOG: > The issue is for corporate and the cloud, IPv6 is just as broken as IPv4. > And no corporate is migrating go look. Its been the next big thing in > Corporate networks for 20 years.
If they are not willing to upgrade, they are also not willing to implement any other new protocol, as this always means that IPv4 only machines need to be changed, as you cannot make them able to reach non IPv4 machines without modifying them.
All of that stuff has being discussed many times...
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de [trashcan@stinkedores.dorfdsl.de] _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/2EKXGBLSTHXPUSME3ZEREOLD64DIPMDG/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2EKXGBLS...]
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/KU543YXNZ5CT357EWVALU67EJS4QBT5L/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KU543YXN...]
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/Y5ALPB5T42UFLDKYL3L2XRMM4SYWHM42/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Y5ALPB5T...] _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/TINMZBCVA3KPCO6TM6BUKNHAIKYJFBGN/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TINMZBCV...]
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/ZMLFQGA744DVLZTN6SW664UCLV4CBJTT/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZMLFQGA7...]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
Marco, Here's how I see it going. 1. The OS upgrade is transparent. 2. The firewalls at the edge upgrade and IPv8 zone features. 3. The 10.x can now be split and operated by area. 4. People turn that on, and Zone Server to interoperate better inside regardless of the Internet status. 5. Internally it becomes part of the OS. 6. Even just implementing a Zone Server, and let people manage 10.x by area will be a great option. Jamie On Sat, May 2, 2026 at 10:08 AM Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 02.05.26 um 14:56 schrieb Jamie Thain via NANOG:
And what isn't backwards compatible if you know of something. I'm all ears.
Your proposal isn't too, as there is nothing that can be backwards compatible regarding IPv4-only nodes in an IPv4-only environment with admins who do not want any change.
-- Gruß Marco Muell und Spam bitte an abfalleimer2000@stinkedores.dorfdsl.de [abfalleimer2000@stinkedores.dorfdsl.de] _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/VKXJGPM2V5GFQ4I6EYJETEEQKIP32D4G/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VKXJGPM2...]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
And how will you update the myriad of operating systems and embedded devices which haven’t received updates in years but are still running inside enterprises?
On May 2, 2026, at 6:43 PM, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Marco,
Here's how I see it going.
1. The OS upgrade is transparent. 2. The firewalls at the edge upgrade and IPv8 zone features. 3. The 10.x can now be split and operated by area. 4. People turn that on, and Zone Server to interoperate better inside regardless of the Internet status. 5. Internally it becomes part of the OS. 6. Even just implementing a Zone Server, and let people manage 10.x by area will be a great option.
Jamie
On Sat, May 2, 2026 at 10:08 AM Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 02.05.26 um 14:56 schrieb Jamie Thain via NANOG: And what isn't backwards compatible if you know of something. I'm all ears.
Your proposal isn't too, as there is nothing that can be backwards compatible regarding IPv4-only nodes in an IPv4-only environment with admins who do not want any change.
-- Gruß Marco Muell und Spam bitte an abfalleimer2000@stinkedores.dorfdsl.de [abfalleimer2000@stinkedores.dorfdsl.de] _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/VKXJGPM2V5GFQ4I6EYJETEEQKIP32D4G/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VKXJGPM2...]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D] _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EFFNMZI2...
Kevin Code is expensive. I want a sense of anything is wrong first. Dns server needs 10 lines of code. Dhcp server 0, ntp server 100, netlog 1000, So far mostly people have told me to go F myself. But it's the economics will win. Tco = 0 If ipv is compatible If protocol = ipv8 Tco = education + dev time of tools once on all 4 varaint os's + any premiium - (integration savings) - 100,000s per mid size enterprise per year. Think -100 000 per 1000 employees or so If protocol = ipv6 Tco = interoperability testing + education + i get my ass fired for using it. Tco for ipv8 - billions Tco for ipv6 + billions On Sat., May 2, 2026, 5:56 p.m. Kevin Tillery via NANOG, < nanog@lists.nanog.org> wrote:
Code is extremely malleable. You are not building a lunar lander. It will not explode, kill three people and humiliate a nation if you get it wrong. You will just observe that it is wrong and change it until it is right.
This gives you plentiful opportunities to discover things for yourself instead of spamming this mailing list with stupid arguments.
For example, if you actually write an IPv8 implementation, you can try connecting it to an IPv4 implementation. You will discover whether it actually works or not. This is infinitely more valuable than an argument.
Justin,
Because before you write a line of code you have to get it right, or near right.
If you want to see good engineering watch from the "Earth to the Moon" Spider, how they built the lunar lander.
So far I've had like 3 serious conversations about "this won't work" and each one has had me improve it. But "go make code" before we discuss what and how it should be, a DRAFT is actually when you want comments about the operation of it all.
I'm not going to wait until I written 1m worth of code to figure something is wrong.
IETF folks suggested to me, that I join Nanog to see how they might use it. IPv8 is not about address space.
Jamie
On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG <nanog@lists.nanog.org> wrote:
I know of enterprises who are deploying v6.
Until you can show the world a working IPv8 implementation on a large using off-the-shelf components where people can run through failure scenarios and really beat it up, not many people are going to take it seriously.
Lower layers of the network relying on the functionality of higher layers is a really, really, really bad idea.
While it's always important to think about how to so something better, v8 seems to create a whole bunch of new problems while not solving many
have already been addressed in v6 and other protocols.
Thank you jms
On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Andrew,
Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 in a meeting and two corp engineers laughed.
You can google it yourself.
Jamie
On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
If no corporation is migrating then why is IPv6 traffic continuing to increase?
As I pointed out, IPv6 traffic increased 5% last year. At that admittedly slow rate, the entire internet will be IPv6 in 10 years.
Further your assertion that business is the prime mover is incorrect. Business will move when they have to. That time is coming.
When businesses can’t get IPv4 from their providers or superscaler, or a vendor or client can’t reach them, they will move.
Andrew
On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Andrew,
The issue is for corporate and the cloud, IPv6 is just as broken as IPv4.
And no corporate is migrating go look. Its been the next big
Corporate networks for 20 years.
Jamie
On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
> I oppose this. With IPv6 traffic now representing around half of internet > traffic, the time to rethink has long passed. > > If IPv8 was going to be a solution, it should have been a solution 10 years > ago. > > In the last 12 months, ~5% of traffic migrated to IPv6. At that rate, IPv6 > will be fully implemented by 2035. I'm not seeing a problem
needs
to > be solved, or a credible solution. > > Andrew > > > > On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < > nanog@lists.nanog.org [nanog@lists.nanog.org]> > wrote: > > > Hi All, > > > > My name is Jamie Thain I'm the creator of IPv8. It's not a hoax. > > > > I joined this list because, as part of IPv8, I am creating a BGPv8. > Inside > > BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the > > routes to produce a better metric. It's a hybrid of EIRGP mixed with BGP > to > > create better engineering results. > > > > I also as part of CF created Sun Tzu which is the protocol
watches
> CF > > and gives you a CF score of reliability. Do I trust my
On 2 May 2026 20:05:47 CEST, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote: that thing in that that partnership
with > > you? > > > > Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, > > etc, etc. That's not my discussion point. My point isn't "should I even > > propose IPv8" my point is what would be the best result for operators? > > > > I believe that since IPv8 solves the duopoly problem, it will replace > > IPv4. > > > > So the things to know, IPV8 is NOT a 64 bit addressing system. > > > > It is a 32 bit routing system with a 32 bit addressing system. > > > > A Routing Number = ASNs plus others. > > > > 8.8.8.8 would become 15169.8.8.8.8 > > > > https://www.ietf.org/archive/id/draft-thain-ipv8-02.html [https://www.ietf.org/archive/id/draft-thain-ipv8-02.html] > > < > > https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea [https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea] > 3372a?u=12457652 > > > > > > > > > So each ASN in the world will have 3 Billion available addresses. > > > > There is a specially reserved group of internal ASN 127.x.x.x so each > corp, > > org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x and > > 100.64.x.x.x > > > > I'd appreciate your thoughts on it > > > > Jamie > > _______________________________________________ > > NANOG mailing list > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/ > > > _______________________________________________ > NANOG mailing list > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/ [ https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA... ]
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/ [ https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2MY7QMH6... ]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D] _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JTNFIASL... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QWWTJWVN...
On Sat, May 02, 2026 at 09:14:32PM -0300, Jamie Thain via NANOG wrote:
Code is expensive. I want a sense of anything is wrong first.
People are expensive. By now you have a sense something may be wrong.
So far mostly people have told me to go F myself.
This is the moment in the story where the hero prevails against the odds, or the fool fails.
But it's the economics will win.
-Snow
If IPv8 code is so expensive that you can't write 1000 lines, even with AI, then IPv8 is a failure because IPv8 is too expensive to deploy. Writing code is not optional. You cannot have IPv8 without IPv8 code. As they say, "put up or shut up." If you want to be taken seriously give people a reason to take you seriously. Actions speak louder than words. Where is your simulation of an IPv4 node talking to an IPv8 node? If you run Linux, you can easily simulate many IPv4 hosts using network namespaces. You can build a whole virtual network out of network namespaces and veth interface pairs. You can write an IPv8 router program that connects to these networks using tun (or tap) interfaces. You can create some actual evidence that IPv8 is better than IPv4. At the moment it is very obvious that you don't know anything about IPv8, so I suggest you fix this problem by building an IPv8 network simulation. There is also actual software out there for network simulation which could be more convenient than raw Linux commands. An IPv4 router is not hard to write, especially if you ignore all the edge cases and you can hardcode the routing tables and other data, which you can do if you're just trying to prove a concept. If you find it impossible to write an IPv8 router, then maybe IPv8 is hot garbage because a network needs routers and if you can't make a router you can't make a network and if you can't make a network the protocol is completely useless. Make sure to demonstrate all the cook new IPv8 features. If the IPv8 router is exactly the same as an IPv4 router, it's worthless. On 3 May 2026 02:14:32 CEST, Jamie Thain <jamie@one.bm> wrote:
Kevin
Code is expensive. I want a sense of anything is wrong first.
Dns server needs 10 lines of code. Dhcp server 0, ntp server 100, netlog 1000,
So far mostly people have told me to go F myself.
But it's the economics will win.
Tco = 0
If ipv is compatible If protocol = ipv8 Tco = education + dev time of tools once on all 4 varaint os's + any premiium - (integration savings) - 100,000s per mid size enterprise per year.
Think -100 000 per 1000 employees or so
If protocol = ipv6 Tco = interoperability testing + education + i get my ass fired for using it.
Tco for ipv8 - billions
Tco for ipv6 + billions
On Sat., May 2, 2026, 5:56 p.m. Kevin Tillery via NANOG, < nanog@lists.nanog.org> wrote:
Code is extremely malleable. You are not building a lunar lander. It will not explode, kill three people and humiliate a nation if you get it wrong. You will just observe that it is wrong and change it until it is right.
This gives you plentiful opportunities to discover things for yourself instead of spamming this mailing list with stupid arguments.
For example, if you actually write an IPv8 implementation, you can try connecting it to an IPv4 implementation. You will discover whether it actually works or not. This is infinitely more valuable than an argument.
Justin,
Because before you write a line of code you have to get it right, or near right.
If you want to see good engineering watch from the "Earth to the Moon" Spider, how they built the lunar lander.
So far I've had like 3 serious conversations about "this won't work" and each one has had me improve it. But "go make code" before we discuss what and how it should be, a DRAFT is actually when you want comments about the operation of it all.
I'm not going to wait until I written 1m worth of code to figure something is wrong.
IETF folks suggested to me, that I join Nanog to see how they might use it. IPv8 is not about address space.
Jamie
On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG <nanog@lists.nanog.org> wrote:
I know of enterprises who are deploying v6.
Until you can show the world a working IPv8 implementation on a large using off-the-shelf components where people can run through failure scenarios and really beat it up, not many people are going to take it seriously.
Lower layers of the network relying on the functionality of higher layers is a really, really, really bad idea.
While it's always important to think about how to so something better, v8 seems to create a whole bunch of new problems while not solving many
have already been addressed in v6 and other protocols.
Thank you jms
On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG <nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Andrew,
Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 in a meeting and two corp engineers laughed.
You can google it yourself.
Jamie
On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
If no corporation is migrating then why is IPv6 traffic continuing to increase?
As I pointed out, IPv6 traffic increased 5% last year. At that admittedly slow rate, the entire internet will be IPv6 in 10 years.
Further your assertion that business is the prime mover is incorrect. Business will move when they have to. That time is coming.
When businesses can’t get IPv4 from their providers or superscaler, or a vendor or client can’t reach them, they will move.
Andrew
On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
> Andrew, > > The issue is for corporate and the cloud, IPv6 is just as broken as IPv4. > > And no corporate is migrating go look. Its been the next big
> Corporate networks for 20 years. > > Jamie > > On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < > nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote: > > > I oppose this. With IPv6 traffic now representing around half of > internet > > traffic, the time to rethink has long passed. > > > > If IPv8 was going to be a solution, it should have been a solution 10 > years > > ago. > > > > In the last 12 months, ~5% of traffic migrated to IPv6. At that rate, > IPv6 > > will be fully implemented by 2035. I'm not seeing a problem
needs
> to > > be solved, or a credible solution. > > > > Andrew > > > > > > > > On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < > > nanog@lists.nanog.org [nanog@lists.nanog.org]> > > wrote: > > > > > Hi All, > > > > > > My name is Jamie Thain I'm the creator of IPv8. It's not a hoax. > > > > > > I joined this list because, as part of IPv8, I am creating a BGPv8. > > Inside > > > BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the > > > routes to produce a better metric. It's a hybrid of EIRGP mixed with > BGP > > to > > > create better engineering results. > > > > > > I also as part of CF created Sun Tzu which is the protocol
watches > > CF > > > and gives you a CF score of reliability. Do I trust my
On 2 May 2026 20:05:47 CEST, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote: that thing in that that partnership
> with > > > you? > > > > > > Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, > > > etc, etc. That's not my discussion point. My point isn't "should I even > > > propose IPv8" my point is what would be the best result for operators? > > > > > > I believe that since IPv8 solves the duopoly problem, it will replace > > > IPv4. > > > > > > So the things to know, IPV8 is NOT a 64 bit addressing system. > > > > > > It is a 32 bit routing system with a 32 bit addressing system. > > > > > > A Routing Number = ASNs plus others. > > > > > > 8.8.8.8 would become 15169.8.8.8.8 > > > > > > https://www.ietf.org/archive/id/draft-thain-ipv8-02.html [https://www.ietf.org/archive/id/draft-thain-ipv8-02.html] > > > < > > > https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea [https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea] > > 3372a?u=12457652 > > > > > > > > > > > > > So each ASN in the world will have 3 Billion available addresses. > > > > > > There is a specially reserved group of internal ASN 127.x.x.x so each > > corp, > > > org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x > and > > > 100.64.x.x.x > > > > > > I'd appreciate your thoughts on it > > > > > > Jamie > > > _______________________________________________ > > > NANOG mailing list > > > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/ > > > > > _______________________________________________ > > NANOG mailing list > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/ > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/ [ https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA... ]
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/ [ https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2MY7QMH6... ]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D] _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JTNFIASL... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QWWTJWVN...
IPv8 evangelism is starting to feel like the internet version of the Jehovahs Witnesses. It is loud, it keeps banging on my mailbox, and it seems to have re-invented quite a few heresies which I thought were settled 1701 years ago at the Council of Nicea. If IPv8 is accepted by the IETF as a standard, it is nearly impossible that a full implementation will ever be completed. If by some miracle it was completed, no serious engineer will implement it because the consensus against it is so strong. We like our job, and our addiction to food and shelter means we need to be credible in the future. If the intent was to unify a mailing list full of people with egos nearly as large as mine, I salute your success. So, again I ask with all possible kindness, can this thread please die? Andrew “Bring back V-12’s” — Sebastian Vettel On Sat, May 2, 2026 at 11:56 PM Kevin Tillery via NANOG < nanog@lists.nanog.org> wrote:
If IPv8 code is so expensive that you can't write 1000 lines, even with AI, then IPv8 is a failure because IPv8 is too expensive to deploy. Writing code is not optional. You cannot have IPv8 without IPv8 code. As they say, "put up or shut up."
If you want to be taken seriously give people a reason to take you seriously. Actions speak louder than words. Where is your simulation of an IPv4 node talking to an IPv8 node?
If you run Linux, you can easily simulate many IPv4 hosts using network namespaces. You can build a whole virtual network out of network namespaces and veth interface pairs. You can write an IPv8 router program that connects to these networks using tun (or tap) interfaces. You can create some actual evidence that IPv8 is better than IPv4. At the moment it is very obvious that you don't know anything about IPv8, so I suggest you fix this problem by building an IPv8 network simulation.
There is also actual software out there for network simulation which could be more convenient than raw Linux commands.
An IPv4 router is not hard to write, especially if you ignore all the edge cases and you can hardcode the routing tables and other data, which you can do if you're just trying to prove a concept. If you find it impossible to write an IPv8 router, then maybe IPv8 is hot garbage because a network needs routers and if you can't make a router you can't make a network and if you can't make a network the protocol is completely useless.
Make sure to demonstrate all the cook new IPv8 features. If the IPv8 router is exactly the same as an IPv4 router, it's worthless.
Kevin
Code is expensive. I want a sense of anything is wrong first.
Dns server needs 10 lines of code. Dhcp server 0, ntp server 100, netlog 1000,
So far mostly people have told me to go F myself.
But it's the economics will win.
Tco = 0
If ipv is compatible If protocol = ipv8 Tco = education + dev time of tools once on all 4 varaint os's + any premiium - (integration savings) - 100,000s per mid size enterprise per year.
Think -100 000 per 1000 employees or so
If protocol = ipv6 Tco = interoperability testing + education + i get my ass fired for using it.
Tco for ipv8 - billions
Tco for ipv6 + billions
On Sat., May 2, 2026, 5:56 p.m. Kevin Tillery via NANOG, < nanog@lists.nanog.org> wrote:
Code is extremely malleable. You are not building a lunar lander. It will not explode, kill three people and humiliate a nation if you get it wrong. You will just observe that it is wrong and change it until it is right.
This gives you plentiful opportunities to discover things for yourself instead of spamming this mailing list with stupid arguments.
For example, if you actually write an IPv8 implementation, you can try connecting it to an IPv4 implementation. You will discover whether it actually works or not. This is infinitely more valuable than an argument.
Justin,
Because before you write a line of code you have to get it right, or near right.
If you want to see good engineering watch from the "Earth to the Moon" Spider, how they built the lunar lander.
So far I've had like 3 serious conversations about "this won't work" and each one has had me improve it. But "go make code" before we discuss what and how it should be, a DRAFT is actually when you want comments about the operation of it all.
I'm not going to wait until I written 1m worth of code to figure something is wrong.
IETF folks suggested to me, that I join Nanog to see how they might use it. IPv8 is not about address space.
Jamie
On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG <nanog@lists.nanog.org> wrote:
I know of enterprises who are deploying v6.
Until you can show the world a working IPv8 implementation on a large using off-the-shelf components where people can run through failure scenarios and really beat it up, not many people are going to take it seriously.
Lower layers of the network relying on the functionality of higher layers is a really, really, really bad idea.
While it's always important to think about how to so something better, v8 seems to create a whole bunch of new problems while not solving many
have already been addressed in v6 and other protocols.
Thank you jms
On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Andrew,
Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 in a meeting and two corp engineers laughed.
You can google it yourself.
Jamie
On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
> If no corporation is migrating then why is IPv6 traffic continuing to > increase? > > As I pointed out, IPv6 traffic increased 5% last year. At that admittedly > slow rate, the entire internet will be IPv6 in 10 years. > > Further your assertion that business is the prime mover is incorrect. > Business will move when they have to. That time is coming. > > When businesses can’t get IPv4 from their providers or superscaler, or a > vendor or client can’t reach them, they will move. > > Andrew > > > > On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < > nanog@lists.nanog.org [nanog@lists.nanog.org]> > wrote: > > > Andrew, > > > > The issue is for corporate and the cloud, IPv6 is just as broken as IPv4. > > > > And no corporate is migrating go look. Its been the next big
On 2 May 2026 20:05:47 CEST, Jamie Thain via NANOG < nanog@lists.nanog.org> wrote: that thing in
> > Corporate networks for 20 years. > > > > Jamie > > > > On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < > > nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote: > > > > > I oppose this. With IPv6 traffic now representing around half of > > internet > > > traffic, the time to rethink has long passed. > > > > > > If IPv8 was going to be a solution, it should have been a solution 10 > > years > > > ago. > > > > > > In the last 12 months, ~5% of traffic migrated to IPv6. At
On 3 May 2026 02:14:32 CEST, Jamie Thain <jamie@one.bm> wrote: that
rate, > > IPv6 > > > will be fully implemented by 2035. I'm not seeing a problem that needs > > to > > > be solved, or a credible solution. > > > > > > Andrew > > > > > > > > > > > > On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < > > > nanog@lists.nanog.org [nanog@lists.nanog.org]> > > > wrote: > > > > > > > Hi All, > > > > > > > > My name is Jamie Thain I'm the creator of IPv8. It's not a hoax. > > > > > > > > I joined this list because, as part of IPv8, I am creating a BGPv8. > > > Inside > > > > BGPv8, two new protocols CF (Cost Factor), weigh cost factors along > the > > > > routes to produce a better metric. It's a hybrid of EIRGP mixed with > > BGP > > > to > > > > create better engineering results. > > > > > > > > I also as part of CF created Sun Tzu which is the protocol that > watches > > > CF > > > > and gives you a CF score of reliability. Do I trust my partnership > > with > > > > you? > > > > > > > > Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every > problem, > > > > etc, etc. That's not my discussion point. My point isn't "should I > even > > > > propose IPv8" my point is what would be the best result for > operators? > > > > > > > > I believe that since IPv8 solves the duopoly problem, it will replace > > > > IPv4. > > > > > > > > So the things to know, IPV8 is NOT a 64 bit addressing system. > > > > > > > > It is a 32 bit routing system with a 32 bit addressing system. > > > > > > > > A Routing Number = ASNs plus others. > > > > > > > > 8.8.8.8 would become 15169.8.8.8.8 > > > > > > > > https://www.ietf.org/archive/id/draft-thain-ipv8-02.html [https://www.ietf.org/archive/id/draft-thain-ipv8-02.html] > > > > < > > > > https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea [https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea] > > > 3372a?u=12457652 > > > > > > > > > > > > > > > > > So each ASN in the world will have 3 Billion available addresses. > > > > > > > > There is a specially reserved group of internal ASN 127.x.x.x so each > > > corp, > > > > org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x > > and > > > > 100.64.x.x.x > > > > > > > > I'd appreciate your thoughts on it > > > > > > > > Jamie > > > > _______________________________________________ > > > > NANOG mailing list > > > > > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > > message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/ > > > > > > > _______________________________________________ > > > NANOG mailing list > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > > message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/ > > _______________________________________________ > > NANOG mailing list > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/ > _______________________________________________ > NANOG mailing list > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/ [
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA...
]
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/ [
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2MY7QMH6...
]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JTNFIASL...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QWWTJWVN...
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RJZW7DAT...
On Sat, 2 May 2026, Jamie Thain wrote:
And what isn't backwards compatible if you know of something. I'm all ears.
gethostbyname() Also, you're literally changing the on-wire format. That's by definition not backwards compatible with EVERYTHING out there that isn't purely CPU based (which is A LOT). The fact that you don't understand this, means you don't understand the problem space. Your statements are ludicrous to anyone with any kind of non-trivial knowledge how networking works. It'd be like I would write up some documents on how design rockets and try to tell NASA / SpaceX how they should design their space vehicles. I only have the most basic "popular science" knowledge of how rockets work. You seem to be in the same situation when it comes to networking. -- Mikael Abrahamsson email: swmike@swm.pp.se
Am 03.05.26 um 00:30 schrieb Jamie Thain via NANOG:
* IPv6 wasn't a surgical fix for address exhaustion — it bundled the address-space change with a full redesign of neighbor discovery, autoconfiguration, header structure, and operational tooling.
That wasn't the issue. The issue is that it takes some time to prepare and do the implementation of another network protocol, regardless how it is called or how it works in detail. No one cares about ARP, nor NDP. It is there and works. Corporate networks need address plan, firewall plans etc. and that needs to be extended if any new protocol is going to be implemented. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Am 03.05.26 um 00:21 schrieb Jamie Thain via NANOG:
And that's the story of why IPv8. Because its really IPv4 V2 its an inplace upgrade of what we have. The minimal world is
It isn't as both sides of the communication partner need to implement it in a way, so same situation as IPv6 - if one site does not want to do anything, you cannot completely switch of old IPv4. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Am 03.05.26 um 00:42 schrieb Jamie Thain:
Here's how I see it going.
1. The OS upgrade is transparent. 2. The firewalls at the edge upgrade and IPv8 zone features.
And there is the first issue. It will take years until very OS and hardware supports it and it will take years until operators configure it.
3. The 10.x can now be split and operated by area.
There is no need for that, they can use IPv6 internally without bothering with any external.
4. People turn that on, and Zone Server to interoperate better inside regardless of the Internet status.
They will not like there are people who will not enable IPv6, because we "don't need it", "have enough addresses", "don't want ti", "wait further" etc. and all the excuses. Why should that differ in that case?
5. Internally it becomes part of the OS. 6. Even just implementing a Zone Server, and let people manage 10.x by area will be a great option. For me that looks like more complicated than simply using an IPv6 /48, for which support is already implemented in most hardware and software.
-- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
On 5/2/26 8:13 PM, Andrew Kirch via NANOG wrote:
IPv8 evangelism is starting to feel like the internet version of the Jehovahs Witnesses. It is loud, it keeps banging on my mailbox, and it seems to have re-invented quite a few heresies which I thought were settled 1701 years ago at the Council of Nicea.
If IPv8 is accepted by the IETF as a standard, it is nearly impossible that a full implementation will ever be completed. If by some miracle it was completed, no serious engineer will implement it because the consensus against it is so strong. We like our job, and our addiction to food and shelter means we need to be credible in the future.
If the intent was to unify a mailing list full of people with egos nearly as large as mine, I salute your success.
So, again I ask with all possible kindness, can this thread please die?
Andrew
Perhaps he could be convinced to rename it "IPv8 Cube".[1] -- "you will eat shit before you realize that ipv8 is cube truth" -SD [1] Hey, 8 even *is* a cube.
Host A is at address 65534:192.168.2.3 Host B is at address 192.168.2.3 How, exactly, do you think these two hosts magically exchange packets? Host B has no IPv8 stack and no ability to produce an IPv8 packet with the extra 32 octets. Host A must be 100% backwards compatible to live up to your claims. Yes, I realize my example involves a private ASN and a public address. Substitute overlapping public addresses if you prefer, the point remains. Owen
On May 2, 2026, at 05:56, Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Mikael
And what isn't backwards compatible if you know of something. I'm all ears.
Jamie
On Sat., May 2, 2026, 6:18 a.m. Mikael Abrahamsson, <swmike@swm.pp.se> wrote:
On Sat, 2 May 2026, Jamie Thain wrote:
Ipv10 Was A dual stack idea.
Everything that isn't IPv4 will be a new stack. This was realised already in the 90s, and that's why we have IPv6 that's now close to 30 years into its deployment. Adding another stack in the mix won't help.
If you would have done what you're doing back in mid 90s, it might have helped. You're 3 decades too late.
Again since you can't do the analysis steps then just send me a tape recording.
There is nothing to analyze. You're proposing something that isn't backwards compatible, and you don't seem to understand this is what you're proposing. Same as IPv10 guy.
So start implementing, you might understand it then.
-- Mikael Abrahamsson email: swmike@swm.pp.se
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Z4YOGRDC...
Jamie, Something I don't think you understand is that no enterprise cares if they are using IPv4. They just care that their network works. They aren't religiously attracted to IPv4. If IPv6 saves them money they will switch. Currently they probably have an IPv4 only network. In 2026 that's technical debt, but the business can decide when it makes sense to them to clear up that technical debt. They probably don't have routers old enough to not support IPv6 at this point, and if they do, they can roll IPv6 deployment into their router upgrades which are also overdue. As long as they carry that technical debt, they will also be carrying the real costs of running an IPv4-only network: - Leasing / owning IPv4 blocks - Leasing IPv4s for cloud resources - Engineering time dealing with issues related to doing NAT across business domains - Engineering time dealing with issues related to IPs not being unique (i.e. re-used 10/8 space) So, how much is the enterprise spending dealing with these issues? Rolling out dual stack (not even IPv6-only!) means internal resources are directly addressable and NAT becomes something you only do for your internet-bound v4-only traffic (where you don't really care if every location uses the same 192.168.1.0/24, it's just for internet access), not within the corporate network. No need to build a new stack, no need to have a ton of translators everywhere, no need to replace every single NIC. Rolling out IPv6-only (i.e. 464xlat, or dns64) means you get to completely remove the engineering time you are spending dealing with IPv4-related issues, not just minimize it. I'm not sure what issues you think you are solving with all the other junk you've thrown into the protocol (DHCP granting everything, OAuth, ..) but those are also very solved issues in enterprise networks that don't involve replacing hardware with validated firmware. IP addresses are not proof of identity, not in enterprise networks, not anywhere, they are a routing location of where a client is logically located within the network. Treating them as a proof of identity is a failure of your security implementation, not a fault in the protocol. This goes for both IPV4 and IPV6. Andrew
Hi Jamine, We had internal discussions with our team and are ones that are experienced in economics (wide range of fields, and engineering including CMOS, FPGA, ACIS.) 1. This is what I was told. IPv8 requires two additional lookups. It results in: - wider parser support - new match/action pipeline design - more TCAM/SRAM slices - larger die area - higher power draw - lower port density - new board designs - new optics/thermal validation - new NOS/SDK support - more heat as result of higher power draw 2. Cost areas: - New ASIC / merchant silicon design - Router/switch platform redesign - Carrier backbone + edge replacement - Hyperscaler/data-center network - Enterprise/CPE/firewall/load-balancer "refresh" - Software, OSS/BSS, routing stacks, monitoring systems - Testing, certification, migration labour - Operational risk, outages, dual-stack complexity The approximate numbers to implement are between $500B up to $2T (more realistic number @ $740B) Cisco describes routing silicon release cycles in the 18–36 month range, which means this is not software patches: src: https://www.cisco.com/c/dam/m/digital/elq-cmcglobal/witb/CKN/0721_CROSS.pdf So IPv8 is control-plane cheap and data-plane expensive. The draft needs to account for that. Maybe Trump can allocate $2T to create more jobs, more work. You will need to likely reach out to the NSC. It will take 30 years. If there is forcing event, maybe 10-15 years and that would require the gov to pay all carriers and end-users. We should stop the discussion here; You should contact the merchant silicon companies to find out the costs and whether two additional lookups are required and are at what costs (actual costs, power draw, heat, etc.) --- Shrihari 212-232-2025 On Sat, May 2, 2026 at 7:23 PM Jamie Thain via NANOG <nanog@lists.nanog.org> wrote:
Kevin
Code is expensive. I want a sense of anything is wrong first.
Dns server needs 10 lines of code. Dhcp server 0, ntp server 100, netlog 1000,
So far mostly people have told me to go F myself.
But it's the economics will win.
Tco = 0
If ipv is compatible If protocol = ipv8 Tco = education + dev time of tools once on all 4 varaint os's + any premiium - (integration savings) - 100,000s per mid size enterprise per year.
Think -100 000 per 1000 employees or so
If protocol = ipv6 Tco = interoperability testing + education + i get my ass fired for using it.
Tco for ipv8 - billions
Tco for ipv6 + billions
On Sat., May 2, 2026, 5:56 p.m. Kevin Tillery via NANOG, < nanog@lists.nanog.org> wrote:
Code is extremely malleable. You are not building a lunar lander. It will not explode, kill three people and humiliate a nation if you get it wrong. You will just observe that it is wrong and change it until it is right.
This gives you plentiful opportunities to discover things for yourself instead of spamming this mailing list with stupid arguments.
For example, if you actually write an IPv8 implementation, you can try connecting it to an IPv4 implementation. You will discover whether it actually works or not. This is infinitely more valuable than an argument.
Justin,
Because before you write a line of code you have to get it right, or near right.
If you want to see good engineering watch from the "Earth to the Moon" Spider, how they built the lunar lander.
So far I've had like 3 serious conversations about "this won't work" and each one has had me improve it. But "go make code" before we discuss what and how it should be, a DRAFT is actually when you want comments about the operation of it all.
I'm not going to wait until I written 1m worth of code to figure something is wrong.
IETF folks suggested to me, that I join Nanog to see how they might use it. IPv8 is not about address space.
Jamie
On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG <nanog@lists.nanog.org> wrote:
I know of enterprises who are deploying v6.
Until you can show the world a working IPv8 implementation on a large using off-the-shelf components where people can run through failure scenarios and really beat it up, not many people are going to take it seriously.
Lower layers of the network relying on the functionality of higher layers is a really, really, really bad idea.
While it's always important to think about how to so something better, v8 seems to create a whole bunch of new problems while not solving many
have already been addressed in v6 and other protocols.
Thank you jms
On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
Andrew,
Cell phones. And Cloud. Not Corps. I started some of this, I mentioned IPv6 in a meeting and two corp engineers laughed.
You can google it yourself.
Jamie
On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
If no corporation is migrating then why is IPv6 traffic continuing to increase?
As I pointed out, IPv6 traffic increased 5% last year. At that admittedly slow rate, the entire internet will be IPv6 in 10 years.
Further your assertion that business is the prime mover is incorrect. Business will move when they have to. That time is coming.
When businesses can’t get IPv4 from their providers or superscaler, or a vendor or client can’t reach them, they will move.
Andrew
On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote:
> Andrew, > > The issue is for corporate and the cloud, IPv6 is just as broken as IPv4. > > And no corporate is migrating go look. Its been the next big
> Corporate networks for 20 years. > > Jamie > > On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < > nanog@lists.nanog.org [nanog@lists.nanog.org]> wrote: > > > I oppose this. With IPv6 traffic now representing around half of > internet > > traffic, the time to rethink has long passed. > > > > If IPv8 was going to be a solution, it should have been a solution 10 > years > > ago. > > > > In the last 12 months, ~5% of traffic migrated to IPv6. At
rate,
> IPv6 > > will be fully implemented by 2035. I'm not seeing a problem
needs
> to > > be solved, or a credible solution. > > > > Andrew > > > > > > > > On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < > > nanog@lists.nanog.org [nanog@lists.nanog.org]> > > wrote: > > > > > Hi All, > > > > > > My name is Jamie Thain I'm the creator of IPv8. It's not a hoax. > > > > > > I joined this list because, as part of IPv8, I am creating a BGPv8. > > Inside > > > BGPv8, two new protocols CF (Cost Factor), weigh cost factors along the > > > routes to produce a better metric. It's a hybrid of EIRGP mixed with > BGP > > to > > > create better engineering results. > > > > > > I also as part of CF created Sun Tzu which is the protocol
watches > > CF > > > and gives you a CF score of reliability. Do I trust my
On 2 May 2026 20:05:47 CEST, Jamie Thain via NANOG < nanog@lists.nanog.org> wrote: that thing in that that that partnership
> with > > > you? > > > > > > Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves every problem, > > > etc, etc. That's not my discussion point. My point isn't "should I even > > > propose IPv8" my point is what would be the best result for operators? > > > > > > I believe that since IPv8 solves the duopoly problem, it will replace > > > IPv4. > > > > > > So the things to know, IPV8 is NOT a 64 bit addressing system. > > > > > > It is a 32 bit routing system with a 32 bit addressing system. > > > > > > A Routing Number = ASNs plus others. > > > > > > 8.8.8.8 would become 15169.8.8.8.8 > > > > > > https://www.ietf.org/archive/id/draft-thain-ipv8-02.html [https://www.ietf.org/archive/id/draft-thain-ipv8-02.html] > > > < > > > https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea [https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea] > > 3372a?u=12457652 > > > > > > > > > > > > > So each ASN in the world will have 3 Billion available addresses. > > > > > > There is a specially reserved group of internal ASN 127.x.x.x so each > > corp, > > > org, has 16 Million areas of 3 Billion addresses, to replace 10.x.x.x > and > > > 100.64.x.x.x > > > > > > I'd appreciate your thoughts on it > > > > > > Jamie > > > _______________________________________________ > > > NANOG mailing list > > > > > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/ > > > > > _______________________________________________ > > NANOG mailing list > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/ > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/ [
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA...
]
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/ [
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2MY7QMH6...
]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JTNFIASL...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QWWTJWVN... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DTITZNUE...
participants (50)
-
Adam Fathauer -
Andre Sencioles -
Andrew Kirch -
andrew＠apalrd.net -
Brian Russo -
Christopher Morrow -
Dan Mahoney -
Dorn Hetzel -
Elmar K. Bins -
Eric Germann -
Gary Sparkes -
Izaac -
James Snow -
Jamie Thain -
Javier J -
Job Snijders -
Joe Klein -
Joe Provo -
Josh Luthman -
Justin Streiner -
Karlin König -
Kevin Tillery -
Larry Brower -
lists＠at.encryp.ch -
Lucien Hoydic -
Marco Moock -
Mark Andrews -
Mikael Abrahamsson -
Måns Nilsson -
nanog＠jwpemail.com -
Nathan Angelacos -
Nick Hilliard -
niels=nanog＠bakker.net -
Owen DeLong -
Randy Bush -
Raymond Burkholder -
Rich Kulawiec -
Ryan Hamel -
Saku Ytti -
Shane Ronan -
Shrihari Pandit -
sronan＠ronan-online.com -
steve ulrich -
Suresh Ramasubramanian -
Szechuan Death -
Tom Beecher -
Tony Wicks -
Vasilenko Eduard -
Victor Kuarsingh -
Volkan SALİH