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 <nanog@lists.nanog.org> 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, < nanog@lists.nanog.org> 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.
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 <nanog@lists.nanog.org> 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
have already been addressed in v6 and other protocols.
Thank you jms
On Fri, May 1, 2026, 23:22 Jamie Thain via NANOG < nanog@lists.nanog.org [nanog@lists.nanog.org]> 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 < nanog@lists.nanog.org [nanog@lists.nanog.org]> 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 < nanog@lists.nanog.org [nanog@lists.nanog.org]> 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
> Corporate networks for 20 years. > > Jamie > > On Thu, Apr 30, 2026 at 5:26 PM Andrew Kirch via NANOG < > nanog@lists.nanog.org [nanog@lists.nanog.org]> 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
rate,
> IPv6 > > will be fully implemented by 2035. I'm not seeing a problem
needs
> to > > be solved, or a credible solution. > > > > Andrew > > > > > > > > On Wed, Apr 29, 2026 at 3:23 PM Jamie Thain via NANOG < > > nanog@lists.nanog.org [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
watches > > CF > > > and gives you a CF score of reliability. Do I trust my
On 2 May 2026 20:05:47 CEST, Jamie Thain via NANOG < nanog@lists.nanog.org> wrote: that thing in that that that 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/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > message/KPDE4FNBRLQYZOVF5FUAAGJCBSKNS42Q/ > > > > > _______________________________________________ > > NANOG mailing list > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] > > message/D3YXYDYJWWH3A7WZZBYSJQAZOMLECQK7/ > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/QPBOJRGHJ72YGIQ5BIPMIM4WIXCLZOLA/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ [https://lists.nanog.org/archives/list/nanog@lists.nanog.org/] message/VPK4LEVG7XSXPYL54J3OZKBOJN27HWWD/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/52EWJ6VAN5YXXENIATYZAPIYO5KJAANT/ [
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52EWJ6VA...
]
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/ message/2MY7QMH6L67IEHGXMNM5SWFWP4LWCW6C/ [
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2MY7QMH6...
]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JTNFIASL...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QWWTJWVN... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DTITZNUE...