nanog mailing list archives

RE: IPv6 native percentage (end user perspective)


From: Gary Sparkes via NANOG <nanog () lists nanog org>
Date: Thu, 19 Jun 2025 22:12:41 +0000

I don't want to restart the recurring argument, but I'll just put this out
there: Why bother adding the cost of supporting a dual-stack network when there is precisely zero cost for me to stick 
with IPv4? From a cost perspective, if I have to assign everyone an IPv4 address and an IPv6 address to deploy IPv6, 
why would I bother assigning the IPv6 address? I have plenty of addresses to continue handing out IPv4 addresses 
directly to customers for at least several years, so there is no benefit to me in adding the overhead of dealing with 
both IPv6 and IPv4 on a per-customer basis simultaneously.

At a minimum, because if they're already going to be on CGNAT, it will greatly improve their general internet access 
experience. 

Even if they won't be on CGNAT, it will still, in general, improve their internet experience on things like VOIP, 
multiplayer gaming, and other such similarly network centric applications that can take advantage of it. The removal of 
NAT layers at all is a huge benefit. 

Users would silently see faster and more reliable functionality of existing things that can take v6 advantage. I've 
implemented v6 tunnels for people on v4 only ISPs just as an easy way to resolve a variety of v4 headaches/issues that 
we used to just consider 'normal'. 

Running dual stack provides all the benefits for applications that can take advantage of it, without some of the 
downsides incurred by v6 transition technologies like 464XLAT and the like. It should be a zero-cost outside of labor 
effort to implement/support. Things like NAT64 and DNS64 do work for the most part but have rough edges when 
applications cannot handle v6 addressing (this is still a big issue with some stuff!). 

Overall dual stack is the smoothest way, and can reduce V4 load and complexity - thus leading to potential hardware 
downsizing and cost savings. 

-----Original Message-----
From: Forrest Christian (List Account) via NANOG <nanog () lists nanog org> 
Sent: Thursday, June 19, 2025 6:05 PM
To: North American Network Operators Group <nanog () lists nanog org>
Cc: Forrest Christian (List Account) <lists () packetflux com>
Subject: Re: IPv6 native percentage (end user perspective)

Just to provide some perspective from my viewpoint:

I can run dual-stack.  But I don't want to, at least for a specific
customer.   I want a particular customer to be IPv4 or IPv6, with an
eventual transition to 100% IPv6.

I don't want to restart the recurring argument, but I'll just put this out
there: Why bother adding the cost of supporting a dual-stack network when there is precisely zero cost for me to stick 
with IPv4? From a cost perspective, if I have to assign everyone an IPv4 address and an IPv6 address to deploy IPv6, 
why would I bother assigning the IPv6 address? I have plenty of addresses to continue handing out IPv4 addresses 
directly to customers for at least several years, so there is no benefit to me in adding the overhead of dealing with 
both IPv6 and IPv4 on a per-customer basis simultaneously.

However, I'm willing to migrate (over several years) to an IPv6-only network and run a CGNAT box to access IPv4, but 
only once the cost of running the CGNAT box becomes negligible. Once that occurs, I want to start getting ahead of the 
curve and set up a CGNAT box, then begin offering only
IPv6 to new customers.

Of course, the size and cost of the CGNAT device are directly related to the flows and/or bandwidth, which is why I was 
curious about the
percentages.   If it's 10% IPv6, then I'm not close to where I need to be.
If it's 95%, then I can (and should) start moving to IPv6.   Somewhere in
the middle is the threshold, not quite sure where that number is.


On Thu, Jun 19, 2025 at 3:24 PM Mark Andrews via NANOG < nanog () lists nanog org> wrote:

You are asking the wrong question.

Switching on IPv6 doesn’t require you to switch off IPv4.  You can but 
you don’t have to.  I find it sad that ISPs still think IPv4 and IPv6 
are mutually exclusive.  Nobody is asking for people to switch off 
IPv4. They are only asking that you enable IPv6 so they can reach you 
without having to run the traffic though a CGN 44 or 64.

For most eyeball networks the majority of your traffic will be IPv6 
the moment you turn IPv6 on as most of the large content providers 
offer IPv6 and implementations prefer IPv6.

Mark
--
Mark Andrews

On 20 Jun 2025, at 06:13, Forrest Christian (List Account) via NANOG 
<
nanog () lists nanog org> wrote:

I see numerous statistics from Google and similar sources that 
indicate
the
percentage of end users who are IPv6 native.   What I'm missing are
statistics going the other way - what percentage of sites (or 
endpoints that customers regularly connect to) are IPv6-native, from 
a total
traffic
perspective?

That is, if I switch to IPv6 on my eyeball network, how much of my
existing
traffic will I have to CGNAT in some way to reach the IPv4-only network?

We have sufficient IPv4 address resources to stick with IPv4 for the 
foreseeable future.  However, at some point, the percentage of 
traffic using IPv6 becomes so high that the reasons not to move become less
significant.   For example, the CGNAT box becomes significantly smaller,
as
most of the traffic should flow around it on IPv6.

--
- Forrest
_______________________________________________
NANOG mailing list

https://lists.nanog.org/archives/list/nanog () lists nanog org/message/ZW
NAGD3GM6VKKNBE3QE5HHRJ26C4UXJF/

_______________________________________________
NANOG mailing list

https://lists.nanog.org/archives/list/nanog () lists nanog org/message/A7
5BIETJQDTWUGEZQWSGKNE2L5SQPNHZ/



--
- Forrest
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/FKFUZUB57MSQ7PNRVE5IUKTJL345WEET/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/52KYGGZ2FAHKVUMPKLK6HO7MFBPF326U/

Current thread: