Re: IPv8 / BGP8 / CF - just build it

Hi Jamine,

We had internal discussions with our team and are ones that are experienced
in economics (wide range of fields, and engineering including CMOS, FPGA,
ACIS.)

1. This is what I was told. IPv8 requires two additional lookups. It
results in:

   - wider parser support
   - new match/action pipeline design
   - more TCAM/SRAM slices
   - larger die area
   - higher power draw
   - lower port density
   - new board designs
   - new optics/thermal validation
   - new NOS/SDK support
   - more heat as result of higher power draw

2. Cost areas:

   - New ASIC / merchant silicon design
   - Router/switch platform redesign
   - Carrier backbone + edge replacement
   - Hyperscaler/data-center network
   - Enterprise/CPE/firewall/load-balancer "refresh"
   - Software, OSS/BSS, routing stacks, monitoring systems
   - Testing, certification, migration labour
   - Operational risk, outages, dual-stack complexity

The approximate numbers to implement are between $500B up to $2T (more
realistic number @ $740B)

Cisco describes routing silicon release cycles in the 18–36 month range,
which means this is not software patches:
src:
https://www.cisco.com/c/dam/m/digital/elq-cmcglobal/witb/CKN/0721_CROSS.pdf

So IPv8 is control-plane cheap and data-plane expensive. The draft needs to
account for that. Maybe Trump can allocate $2T to create more jobs, more
work. You will need to likely reach out to the NSC. It will take 30 years.
If there is forcing event, maybe 10-15 years and that would require the gov
to pay all carriers and end-users.

We should stop the discussion here; You should contact the merchant silicon
companies to find out the costs and whether two additional lookups are
required and are at what costs (actual costs, power draw, heat, etc.)

--- Shrihari 212-232-2025






On Sat, May 2, 2026 at 7:23 PM Jamie Thain via NANOG <[email protected]>
wrote:

> Kevin
>
> Code is expensive. I want a sense of anything is wrong first.
>
> Dns server needs 10 lines of code. Dhcp server 0, ntp server 100, netlog
> 1000,
>
> So far mostly people have told me to go F myself.
>
> But it's the economics will win.
>
> Tco = 0
>
> If ipv is compatible
>      If protocol = ipv8
>           Tco = education + dev time of tools once on all 4 varaint os's +
> any premiium - (integration savings)
>       - 100,000s per mid size enterprise per year.
>
>         Think -100 000 per 1000 employees or so
>
>      If protocol = ipv6
>            Tco = interoperability testing + education + i get my ass fired
> for using it.
>
> Tco for ipv8 - billions
>
> Tco for ipv6 + billions
>
>
>
> On Sat., May 2, 2026, 5:56 p.m. Kevin Tillery via NANOG, <
> [email protected]> wrote:
>
> > Code is extremely malleable. You are not building a lunar lander. It will
> > not explode, kill three people and humiliate a nation if you get it
> wrong.
> > You will just observe that it is wrong and change it until it is right.
> >
> > This gives you plentiful opportunities to discover things for yourself
> > instead of spamming this mailing list with stupid arguments.
> >
> > For example, if you actually write an IPv8 implementation, you can try
> > connecting it to an IPv4 implementation. You will discover whether it
> > actually works or not. This is infinitely more valuable than an argument.
> >
> >
> > On 2 May 2026 20:05:47 CEST, Jamie Thain via NANOG <
> [email protected]>
> > wrote:
> > >Justin,
> > >
> > >Because before you write a line of code you have to get it right, or
> near
> > >right.
> > >
> > >If you want to see good engineering watch from the "Earth to the Moon"
> > Spider,
> > >how they built the lunar lander.
> > >
> > >So far I've had like 3 serious conversations about "this won't work" and
> > each
> > >one has had me improve it. But "go make code" before we discuss what and
> > how it
> > >should be, a DRAFT is actually when you want comments about the
> operation
> > of it
> > >all.
> > >
> > >I'm not going to wait until I written 1m worth of code to figure
> > something is
> > >wrong.
> > >
> > >IETF folks suggested to me, that I join Nanog to see how they might use
> > it. IPv8
> > >is not about address space.
> > >
> > >
> > >
> > >Jamie
> > >
> > >
> > >
> > >On Sat, May 2, 2026 at 11:12 AM Justin Streiner via NANOG
> > ><[email protected]> wrote:
> > >
> > >
> > >> I know of enterprises who are deploying v6.
> > >>
> > >> Until you can show the world a working IPv8 implementation on a large
> > using
> > >> off-the-shelf components where people can run through failure
> scenarios
> > and
> > >> really beat it up, not many people are going to take it seriously.
> > >>
> > >> Lower layers of the network relying on the functionality of higher
> > layers
> > >> is a really, really, really bad idea.
> > >>
> > >> While it's always important to think about how to so something better,
> > v8
> > >> seems to create a whole bunch of new problems while not solving many
> > that
> > >> have already been addressed in v6 and other protocols.
> > >>
> > >> Thank you
> > >> jms
> > >>
> > >>
> > >>
> > >> On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG <
> [email protected]
> > >> [[email protected]]>
> > >> wrote:
> > >>
> > >> > Andrew,
> > >> >
> > >> > Cell phones. And Cloud. Not Corps. I started some of this, I
> > mentioned IPv6
> > >> > in a meeting and two corp engineers laughed.
> > >> >
> > >> > You can google it yourself.
> > >> >
> > >> > Jamie
> > >> >
> > >> > On Sat, May 2, 2026 at 12:19 AM Andrew Kirch via NANOG <
> > >> > [email protected] [[email protected]]> wrote:
> > >> >
> > >> > > If no corporation is migrating then why is IPv6 traffic continuing
> > to
> > >> > > increase?
> > >> > >
> > >> > > As I pointed out, IPv6 traffic increased 5% last year.  At that
> > >> > admittedly
> > >> > > slow rate, the entire internet will be IPv6 in 10 years.
> > >> > >
> > >> > > Further your assertion that business is the prime mover is
> > incorrect.
> > >> > > Business will move when they have to.  That time is coming.
> > >> > >
> > >> > > When businesses can’t get IPv4 from their providers or
> superscaler,
> > or a
> > >> > > vendor or client can’t reach them, they will move.
> > >> > >
> > >> > > Andrew
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Fri, May 1, 2026 at 11:14 PM Jamie Thain via NANOG <
> > >> > > [email protected] [[email protected]]>
> > >> > > wrote:
> > >> > >
> > >> > > > Andrew,
> > >> > > >
> > >> > > > The issue is for corporate and the cloud, IPv6 is just as broken
> > as
> > >> > IPv4.
> > >> > > >
> > >> > > > And no corporate is migrating go look.  Its been the next big
> > thing in
> > >> > > > Corporate networks for 20 years.
> > >> > > >
> > >> > > > Jamie
> > >> > > >
> > >> > > > On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG <
> > >> > > > [email protected] [[email protected]]> wrote:
> > >> > > >
> > >> > > > > I oppose this.  With IPv6 traffic now representing around half
> > of
> > >> > > > internet
> > >> > > > > traffic, the time to rethink has long passed.
> > >> > > > >
> > >> > > > > If IPv8 was going to be a solution, it should have been a
> > solution 10
> > >> > > > years
> > >> > > > > ago.
> > >> > > > >
> > >> > > > > In the last 12 months, ~5% of traffic migrated to IPv6.  At
> that
> > >> > rate,
> > >> > > > IPv6
> > >> > > > > will be fully implemented by 2035.  I'm not seeing a problem
> > that
> > >> > needs
> > >> > > > to
> > >> > > > > be solved, or a credible solution.
> > >> > > > >
> > >> > > > > Andrew
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG <
> > >> > > > > [email protected] [[email protected]]>
> > >> > > > > wrote:
> > >> > > > >
> > >> > > > > > Hi All,
> > >> > > > > >
> > >> > > > > > My name is Jamie Thain I'm the creator of IPv8. It's not a
> > hoax.
> > >> > > > > >
> > >> > > > > > I joined this list because, as part of IPv8, I am creating a
> > BGPv8.
> > >> > > > > Inside
> > >> > > > > > BGPv8, two new protocols CF (Cost Factor), weigh cost
> factors
> > along
> > >> > > the
> > >> > > > > > routes to produce a better metric. It's a hybrid of EIRGP
> > mixed
> > >> > with
> > >> > > > BGP
> > >> > > > > to
> > >> > > > > > create better engineering results.
> > >> > > > > >
> > >> > > > > > I also as part of CF created Sun Tzu which is the protocol
> > that
> > >> > > watches
> > >> > > > > CF
> > >> > > > > > and gives you a CF score of reliability.  Do I trust my
> > partnership
> > >> > > > with
> > >> > > > > > you?
> > >> > > > > >
> > >> > > > > > Now, beyond an on-slaught of IPv8 is stupid, IPv6 solves
> every
> > >> > > problem,
> > >> > > > > > etc, etc. That's not my discussion point. My point isn't
> > "should I
> > >> > > even
> > >> > > > > > propose IPv8" my point is what would be the best result for
> > >> > > operators?
> > >> > > > > >
> > >> > > > > > I believe that since IPv8 solves the duopoly problem, it
> will
> > >> > replace
> > >> > > > > > IPv4.
> > >> > > > > >
> > >> > > > > > So the things to know, IPV8 is NOT a 64 bit addressing
> system.
> > >> > > > > >
> > >> > > > > > It is a 32 bit routing system with a 32 bit addressing
> system.
> > >> > > > > >
> > >> > > > > > A Routing Number = ASNs plus others.
> > >> > > > > >
> > >> > > > > > 8.8.8.8 would become 15169.8.8.8.8
> > >> > > > > >
> > >> > > > > > https://www.ietf.org/archive/id/draft-thain-ipv8-02.html
> > >> [https://www.ietf.org/archive/id/draft-thain-ipv8-02.html]
> > >> > > > > > <
> > >> > > > > >
> https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea
> > >> [https://l.shortlink.es/l/3ae384c1b8e2eb92749595407c5cf9b87ea]
> > >> > > > > 3372a?u=12457652
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > So each ASN in the world will have 3 Billion available
> > addresses.
> > >> > > > > >
> > >> > > > > > There is a specially reserved group of internal ASN
> 127.x.x.x
> > so
> > >> > each
> > >> > > > > corp,
> > >> > > > > > org, has 16 Million areas of 3 Billion addresses, to replace
> > >> > 10.x.x.x
> > >> > > > and
> > >> > > > > > 100.64.x.x.x
> > >> > > > > >
> > >> > > > > > I'd appreciate your thoughts on it
> > >> > > > > >
> > >> > > > > > Jamie
> > >> > > > > > _______________________________________________
> > >> > > > > > NANOG mailing list
> > >> > > > > >
> > >> > > > > >
> https://lists.nanog.org/archives/list/[email protected]/
> > >> [https://lists.nanog.org/archives/list/[email protected]/]
> > >> > > > > message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/
> > >> > > > > >
> > >> > > > > _______________________________________________
> > >> > > > > NANOG mailing list
> > >> > > > > https://lists.nanog.org/archives/list/[email protected]/
> > >> [https://lists.nanog.org/archives/list/[email protected]/]
> > >> > > > > message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/
> > >> > > > _______________________________________________
> > >> > > > NANOG mailing list
> > >> > > >
> > >> > > > https://lists.nanog.org/archives/list/[email protected]/
> > >> [https://lists.nanog.org/archives/list/[email protected]/]
> > >> > > message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/
> > >> > > _______________________________________________
> > >> > > NANOG mailing list
> > >> > > https://lists.nanog.org/archives/list/[email protected]/
> > >> [https://lists.nanog.org/archives/list/[email protected]/]
> > >> > > message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/
> > >> > _______________________________________________
> > >> > NANOG mailing list
> > >> >
> > >> > https://lists.nanog.org/archives/list/[email protected]/
> > >> message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/
> > >> [
> >
> https://lists.nanog.org/archives/list/[email protected]/message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/
> > ]
> > >> _______________________________________________
> > >> NANOG mailing list
> > >> https://lists.nanog.org/archives/list/[email protected]/
> > >> message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/
> > >> [
> >
> https://lists.nanog.org/archives/list/[email protected]/message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/
> > ]
> > >
> >
> >[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
> > >_______________________________________________
> > >NANOG mailing list
> > >
> >
> https://lists.nanog.org/archives/list/[email protected]/message/JTNFIASLS5MTKKP64R7FV6NDPTH2T6PW/
> > _______________________________________________
> > NANOG mailing list
> >
> >
> https://lists.nanog.org/archives/list/[email protected]/message/QWWTJWVN775LBWRMBUBP5YWRTFPCEFCT/
> _______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/[email protected]/message/DTITZNUEU3HKMUMXI3NWZVELKL6J4KIB/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/BKKG3AQCLINX6ZEMSQNZR5JJ2MUPICTM/