nanog mailing list archives

Re: IPv8 / BGP8 / CF


From: Jamie Thain via NANOG <nanog () lists nanog org>
Date: Thu, 30 Apr 2026 13:55:18 +0000

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/AKF4M2DQLS3JAF3MIAEYJK7DOOTNTBCP/]

[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/H3BP2ZAYDUZ7R2KBA5S6XICI2GWLVW7E/

Current thread: