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]

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...

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

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...

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...

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...

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...

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...

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...

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

" 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...

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...

“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...

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...

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...

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

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...

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)

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...

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. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__

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