[Int-area] Re: I STRONGLY OPPOSE ipv8 proposal.

[sotrdg sotrdg <[e-mail]>]

Exactly. it is just naive to think this "ipv8" slop would not break backwards compatibility when i literally proved it would

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Gyan Mishra <[e-mail]>
Sent: Thursday, April 23, 2026 7:14:18 AM
To: Jamie Thain <[e-mail]>
Cc: S Moonesamy <[e-mail]>; sotrdg sotrdg <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [Int-area] Re: I STRONGLY OPPOSE ipv8 proposal.

Hi Jamie

Responses in-line.

See this document on the status of IPv6 deployments worldwide and status:

https://www.rfc-editor.org/rfc/rfc9386.html

As you know a tremendous amount of work by operators around the world as well as vendors has gone into IPv6 deployments.

It would be impossible to get v8 adopted by any vendor let alone adoption by any IETF WG.

Their is no concrete basis to any of the problems you are trying to solve with v8.

Thanks

Gyan
On Wed, Apr 22, 2026 at 8:07 AM Jamie Thain <[e-mail]<mailto:[e-mail]>> wrote:
Gyan

That's not what i said or specifically said. I believe that both IPv4 and IPv6 are structured wrong for proper management and the goal is to make it better faster cheaper.

Gyan> You are mixing up topics that are completely orthogonal and don’t have anything to do each other.  Somehow you are trying to link management to addressing.  As I mentioned most operators use anycast IPv4 and IPv6 and build the template which can be done as IAC router config code or whatever configuration management platform you are using and you are done.

The better statement and the one i think i made is no statement because i don't know.

You see i think the problem is like this.

Architect: Good morning Mr. CTO I was just at a conference and we should do IPv6 it will only be a million dollars.

Mr. CTO what do I get for my million. What do i tell the board?

Architect: Well we'll help the world not run out of IP numbers.

Mr. CTO: Ok when it actually impacts ME come back. I'm not taking any risk without improved value for us.

Gyan> I have completed massive enterprise IPv6 deployments over the last 20 years with this basic process:

Underlay per RFC 5565 Software mesh framework the underlay core  network is single protocol underlay always and only when migration from IPv4 to IPv6 is underlay dual stacked and then IPv4 is removed.  Underlay is independent of overlay and all application traffic lives in BGP overlay so underlay can wait till the end to migrate since it’s a heavy lift.

Enterprise steps:
1. dual stack network
2. migrated all applications to IPv6
3. 6to6 proxy and 6to4 to get to Internet IPv4
4. NAT64 / DNS64 for v4 E-W to other BUs

Service Providers WLN & WLS
1. Dual Stack
2. IPv6 Mostly with IPv4AAS, 464xlat etc
3. IPv6 Only with NAT64 / DNS64 -shut CGN


So working on the industry for 50 years, I'm Arcnet old, I see the future of people running two protocols forever.

Gyan> If you follow the process I laid out it works fine

Two protocols that both need fixing.

And to me in reality on the public side of they put 4 to 6 gw everywhere, and everything public who cares.

Gyan> See steps above to get to IPv6 Only

Maybe if someone builds an ipv6 zone server equivalent and there's some ipeteus and you upgrade the protocol so it manages itself and you add two defgw by default well then the world would be a better place.

They both need fixing.

    Gyan> Please see v6ops drafts and RFCs has  tons of resources to help operators migrate from dual stack to IPv6 Only.


Jamie

On Wed., Apr. 22, 2026, 2:45 a.m. Gyan Mishra, <[e-mail]<mailto:[e-mail]>> wrote:
Hi Jamie

Can you update your draft and make it clear that the intent is to help issues related to IPv4 but not interfere with IPv6 deployments or progression.  As you mentioned your goal is the help IPv4 but not impact in any way IPv6 progression.

IPv6 has come a long way in 25 years and we are close to 30% deployment worldwide.

The reason why it had taken a long time has nothing to do with dual stack which had been historically the industry standard for deployment.

One major point to be made is operators worldwide within 3 tier internet model  have mostly all fully dual stacked to edge gateways connecting their customer networks and both.  So the IPv6 prefix is being advertised by telco operators access network WLN and WLS both IPv4 and IPv6 and here their are gaps and not yet 100%.  The server side Hyperscalers, Cloud service providers and smaller web providers if the web servers are dual stacked but the telco  operator is not dual stacked the only A query even if web server is dual stacked.  If the telco operator is dual stacked but the EE server side compute is not dual stacked then the client will send A/AAAA request but the rely is only A reply since server side is not dual stacked. This is slow to close the gap but their has been a lot of momentum in closing the gaps.

In section 3 of your draft you mentioned route table growth.  Standard operator rule is to allow LPM prefers /24 for IPv4 and /48 for IPv6.  This is required LPM routing if longer matches of an aggregation have different ownership.

You mentioned BGP4 and route leaks.

There has been tremendous work done by IDR GROW and SIDROPS to address route leaks and Route origin validation.  Today most operators world wide have deployed BGP ROA / ROV / VRP which requires each node to have a RPKI session to BGP RPKI Server which has the ROA database.  With ROV route origin validation enabled on each Internet node when the BGP update is received with ROV enabled per address family the prefix must match  the origin AS or it will be dropped and if correct is marked valid.  The next step is ASPA which is AS path validation.  The final phase is full BGP SEC.

RFC 9234 Route leak prevention is being deployed globally to which only allows peer to come up if it’s a valid peering relationship which ad RS/RC, RC/RS, Provider/Customer, Customer/Provider, Peer/Peer. A new path attribute OTC only two customer prevent leaks if OTC is advertised to others than customer peer the prefix is dropped.

RFC 8092 BGP Large Communities x:y:z 12 bytes with global value 4 byte ASN  x and local value 4 byte WLK well known community value is also used for route leak prevention similar to RTC.

CGN has helped prolong IPv4 but now we are at the tipping point close to it that we should be able to start removing CGN from telco providers fully on IPv6.

For this reason for IPv8 and ASN I think you can remove the BGP AS dependency on IP8.

Comment on this paragraph.

IPv4 network management has no coherent integrated model. The protocols that operate a network -- DHCP, DNS, NTP, syslog, SNMP, authentication -- were specified independently over four decades, share no common identity model, no common authentication mechanism, and no common telemetry format.

Most operators use anycast for those services and that works pretty well.  DHCPv4 doles out DNS.  NTP, Syslog, SNMP are all anycast and deployed once and then never touched.

Most all operators deploy router configurations as CI/CD pipeline and use IAC infrastructure as code with Ansible playbook or nornir / netbox or Go for orchestration.  So no issues here.i

UTC is the standard timestamp for routers and compute to so time is synced worldwide.  That eliminates any log correlation issues.

Thanks

Gyan

On Mon, Apr 20, 2026 at 4:39 PM Jamie Thain <[e-mail]<mailto:[e-mail]>> wrote:
Mr S. Moonesamy,

No nettelemetry is a replacement for SNMP, and LOG in one place. Every device knows where to send logs, and sends them in JSON format instead of polling. Its not meant to be Chrome NetLog.

The tools you were looking at are advanced diagnostic tools. NetLog8 is primarily a error logging tool and is quiet on error free networks.

JWT Tokens never pass beyond the Zone Server, unless you configure them to, for example, an enterprise, might have a VPN tunnel from home router to work, configured by logging a tunnel into O365.

HTH,

Jamie


On Mon, Apr 20, 2026 at 4:30 PM S Moonesamy <[e-mail]<mailto:[e-mail]>> wrote:
Dear All,

I and sending my reply to int-area mailing list.

At 09:20 AM 17-04-2026, Jamie Thain wrote:
>Thank you for your words. The goal is not to deprecate ipv6. I
>believe most of the mobile carriers will continue to use their ipv6
>infrastructure.
>
>IPv8 is meant to fix the management issues in ipv4.
>
>It's to fix the global address structure.
>
>Ipv6 can be as easily intercepted and blocked as can ipv4. So it's
>not the protocol allowing you access. It is the lack of implementation.
>
>When ipv6 grows to a meaningful level, China will add it to the great Wall.
>
>So with that said, ipv8 is not a social political issue, it's a
>technical issue.

I was reading draft-thain-ipv8-02 quickly.  The draft mentions "a
common telemetry format (NetLog8)" in Section 3.1.  I did a quick
search and I found the following:
https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/app-integration/use-netlog-capture-network-traffic
https://source.chromium.org/chromium/chromium/src/+/main:net/docs/net-log.md

Will the "common telemetry" be doing something similar to what is on
the web pages mentioned above?  If that is the case, would such
behavior "subvert the intent of communicating parties without the
agreement of those parties" (RFC 7258)?

Regards,
S. Moonesamy

>On Fri., Apr. 17, 2026, 1:01 p.m. sotrdg sotrdg,
><<mailto:[e-mail]<mailto:[e-mail]>>[e-mail]<mailto:[e-mail]>> wrote:
>1. IPv8 makes Governments across the globe much easier to block IP
>and censor internet. I am from China and i use ipv6 to bypass the
>great firewall. ipv8 makes this much easier to block since it reuses
>existing ipv4 (which is blocked for sure) and its address space is
>very small. this ipv8 proposal is just another attempt of big tech
>and governments around the world tries to kill open internet.
>
>2. Implementing ipv8 means deprecating ipv6 which is a huge
>problem.  it is not really solving anything
>
>3. it is not easy to implement ipv8 at all. Android OEMs locks down
>bootloaders and not mentioning routers too. That means billions of
>devices immediately e-waste since they will not get updated to
>support ipv8. It is just another N+1 problem.
>
>4. ipv8's address space is WAY too small. 2^64 may be enough for
>representing a machine but it does not count things like virtual
>machines which might use tons of ip addresses for a very good reason.
>
>5. To say ipv6 is not adopted is very untrue since i am using ipv6
>every day to bypass internet censorship. All my traffic, even this
>email comes from ipv6. this is just completely bs proposal

_______________________________________________
Int-area mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>