Re: IPv8 / BGP8 / CF - just build it

Shrihari,

So the real system is IPv8 to mapping to IPv4 to forwarding.

ABSOLUTELY!!!

IPV8 is an are protocol

Imagine a long time ago in a galaxy far far away, how area codes came to
be.

Each area was a core exchange. 416, Toronto, 212 New York. Once you got to
the major exchange you don't need that number.

In the exchange there's two type of numbers, 0 and the ASN.

You have 0 the old numbers and ASN the new. On every router in the world
there is a way to separate numbering systems called VRFs and l2.5 tags.

Heres the complexity.

ip vrf Ipv8-asn-1234
     rd 1234:65535   // l2.5 label

ip vrf ipv4-asn-0
      rd 0:65535        // l2.5 label

ipip in ip is a silicon and labels put up tunnels all the time.

All silicon is optimized for this. Only pe routers will make a decision.
The overhead will be measured in hundreds of lines of code and then it will
be in LFIB.

One level of label when modern systems are capable of 10+ levels.

It's the exact same process as an mpls tags.

So the complexity is equal to 2 MPLS l3vpns.

Hopefully no one on your team thought that that would be very burdensome on
a new router.



Jamie




On Mon., May 4, 2026, 9:15 a.m. Shrihari Pandit, <[email protected]>
wrote:

> Jamie,
>
> "No new silicon required”, that’s only true because IPv8 is not being
> forwarded natively. Your actual process is:
> 1. Packets are encapsulated into IPv4
> 2. Lookup happens on IPv4
> 3. IPv8 is resolved via control-plane indirection
> 4. So the real system is IPv8 to mapping to IPv4 to forwarding.
>
> Which means:
>
>    - extra lookup (mapping)
>    - extra state (VRFs / LFIBs)
>    - extra encapsulation
>    - extra operational complexity
>
> IPv8 shifted into the control plane. It reminds me of the original ARPANET
> days, CPU based routing. If we go down this path, the control planes might
> all require something like AMD EPYC 9965 (192 cores fyi.) due to PPS rate.
>
> In reference to "loaded into 2 different LFIBs in the silicon". If I
> understand what you saying:
> A. Each “IPv8 area/ASN construct” = VRF
> B. Each mapping = BGP state
> C. Each path = label / adjacency
>
> These issues still exist, because IPv8 indirectly consumes it:
>
>    - TCAM is still consumed (VRF separation not free)
>    - LFIB size grows
>    - BGP table complexity increases
>    - convergence becomes harder
>
> Further, your statement of "if it's passing thru no v8 silicon...."
> implies that every transit node must do: [perform classification, apply
> mapping logic, encapsulate]. That's additional pipeline work.
>
> Shrihari Pandit
> Stealth Communications
> +1-212-232-2025
>
> On Mon, May 4, 2026 at 1:04 AM Jamie Thain <[email protected]> wrote:
>
>> Shrihari,
>>
>> See every 10 or 11 emails you get one that is at least an argument.
>>
>> Ipv8 is an area code based system, and the area codes.
>>
>> When an ipv8 packet arrives at your edge there are only 2 conditions.
>>
>> The route is destined for you or it's passing thru, and then there are
>> only 2 cases you have ipv8 silicon or you don't.
>>
>>  Ok if it's passing thru no v8 silicon
>>     xlate8 looks up it's asnV4 encapsulates it and sends via v4 to that
>> destination.
>>
>> Ok if it's not passing thru and this is the destination then you have two
>> route tables to be concerned with. Asn 0 and asn my asn say 1234
>>
>> There are 2 vrfs created on ipv8 configs
>>
>> ip vrf ipv8-asn-1234
>>    rd 1234:65535
>>
>> ip vrf ipv4-asn-0
>>     rd 0:65535
>>
>> So as routes the ipv8 is loaded into 2 different lfibs in the silicon and
>> managed by the ipv4 silicon.
>>
>> You create the ipv8 overlay by putting it in a vrf until ipv8 silicon is
>> naturally updated.
>>
>> Then for the main show ipv8 route it looks in bgp statement
>>
>>       include ip vrf ipv8-asn-1234 as asn 1234
>>       Include ip vrf ipv4-asn-0 as ipv4
>>
>> And shows these routes
>>
>> There is no new silicon required. From a silicon level "IPv8 is an L3VPN
>> with a globally reserved RD. If your router does L3VPN today — and every SP
>> router does — your router does IPv8 today"
>>
>> HTH
>>
>> Jamie
>>
>>
>>
>>
>>
>>
>>
>> On Sun., May 3, 2026, 10:56 a.m. Shrihari Pandit, <[email protected]>
>> wrote:
>>
>>> 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/LUGDFTDETO3FNPXL3FUQDTH6YJU3OWCC/