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]