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 <[email protected]>
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 <[email protected] [[email protected]]>
> Sent: Thursday, April 30, 2026 8:58 AM
> To: Saku Ytti <[email protected] [[email protected]]>
> Cc: North American Network Operators Group <[email protected]
> [[email protected]]>; Jamie Thain <[email protected] [[email protected]]>
> 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, <[email protected] [[email protected]]>
> 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/[email protected]/
> message/AKF4M2DQLS3JAF3MIAEYJK7DOOTNTBCP/
> [https://lists.nanog.org/archives/list/[email protected]/message/AKF4M2DQLS3JAF3MIAEYJK7DOOTNTBCP/]

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