Re: IPv6 native percentage (end user perspective)

[Michael Thomas via NANOG <nanog () lists nanog org>]

It's sort of surprising that providers haven't used v6 as a marketing 
tool. There is some new stupid Xfinity ad about Wifi going kaboom or 
something that makes about zero sense, but honestly most eyeball 
networks are differentiating themselves mostly on nothing at all (cf: 
"kaboom"). v6 actually does give a direct path from host to server 
without the network complexity which is good for latency, etc. So they 
could actually visualize it as a network with a NAT Goridan Knot in the 
middle that their new-fangled upgrade -- ipv6 -- chops in half to 
unleash the true speed potential. Or something.

The point is that bits are pretty much commodities, so prettier looking 
packaging is probably what a lot of this reduces to. Heck, you could 
even have partner programs that tout the content providers who work with 
your new tech (::snort:: 30 year old "new"). For the ones who've already 
upgraded, it's free publicity as well.

Mike, forgive my lack of caffeine



On 6/19/25 11:58 PM, jordi.palet--- via NANOG wrote:
> That’s why IPv6-only with IPv4aaS makes sense instead of dual-stack.
>
> You don’t need to run dual-stack in most parts of the network, but the customers have dual-stack in their LANs. You 
> don’t care anymore about if customers or destinations are IPv4, IPv6 or dual-stack. All become transparent to you.
>
> Moreover, if your customers are mainly residential, you will find that typically 85% of your traffic is going to CDNs 
> or content providers that are already IPv6-enabled, so your NAT64 traffic will be much lower than the actual CGN 
> traffic, and will go even lower with the time.
>
> Waiting for 100% of the content providers to be IPv6 ready will not work, always someone will be still lost in the 
> IPv4, and for sure you don’t want to get helpdesk calls complaining about that if you switch to IPv6-only (without 
> IPv4aaS).
>
> The issue is to have the right CPEs or CPE firmware that supports IPv6-only with IPv4aaS. Some vendors still need much 
> more customers pressure to offer that. An alternative is of course open source, which is available for both the CPE 
> (OpenWRT) and the NAT64 (Jool). We have done that for several customers and zero issues.
>
> Regards,
> Jordi
>
> @jordipalet
>
>
> > El 20 jun 2025, a las 7:46, Forrest Christian (List Account) via NANOG <nanog () lists nanog org> escribió:
> >
> > Which is why I asked the original question.
> >
> > My intent is not to never move to IPv6, it's just that we're in no rush to
> > do so.   Note that we've had IPv6 on-network with our own address space
> > since 2008.  It just hasn't expanded much beyond our core due to various
> > challenges and a lack of financial incentive to do so.
> >
> > If nearly 100% of the content providers were reachable via IPv6 today.  I'd
> > likely have already been switched.  If that number were still in the
> > almost-zero category, I wouldn't even consider migrating to IPv6, other
> > than in the core and niche cases that we've been running since we started
> > experimenting with it 18 years ago.
> >
> > At some point, the incremental cost of adding the necessary hardware to
> > support NAT for IPv6-only customers to access the legacy IPv4 internet will
> > be low enough that it will make sense for us to deploy it.  At that point,
> > I won't see any reason to continue deploying IPv4 for new customers, and it
> > will become our legacy protocol.   We're certainly getting closer to this
> > threshold. I don't know what that threshold is, but we are getting closer
> > and closer to it.  I do know it's going to be well before the internet
> > shuts off IPv4.
> >
> >
> >
> > On Thu, Jun 19, 2025 at 8:45 PM Adam Fathauer <adam () arfmail com> wrote:
> >
> > > What happens when a customer tries to connect to a ipv6 only resource?
> > >
> > > I routinely hear the argument that “we have plenty of v4 space left”, but
> > > what about the folks at the other end?
> > >
> > > If you wait until then, you’ll either start loosing customers or have to
> > > scramble to accommodate v6 then. Much better to do it slowly on your terms.
> > >
> > > Adam
> > >
> > > Adam
> > >
> > >
> > > ------ Original Message ------
> > >  From "Forrest Christian (List Account) via NANOG" <nanog () lists nanog org>
> > > To "North American Network Operators Group" <nanog () lists nanog org>
> > > Cc "Forrest Christian (List Account)" <lists () packetflux com>
> > > Date 6/19/2025 6:05:12 PM
> > > 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/ZWNAGD3GM6VKKNBE3QE5HHRJ26C4UXJF/
> > >
> > > _______________________________________________
> > > NANOG mailing list
> > >
> > >
> > > https://lists.nanog.org/archives/list/nanog () lists nanog org/message/A75BIETJQDTWUGEZQWSGKNE2L5SQPNHZ/
> > >
> > >
> > >
> > >
> > > --
> > > - Forrest
> > > _______________________________________________
> > > NANOG mailing list
> > >
> > > https://lists.nanog.org/archives/list/nanog () lists nanog org/message/FKFUZUB57MSQ7PNRVE5IUKTJL345WEET/
> > --
> > - Forrest
> > _______________________________________________
> > NANOG mailing list
> > https://lists.nanog.org/archives/list/nanog () lists nanog org/message/NLEG5VLBTJOXTQEZ5B3BTBPHY6C2DN4I/
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or confidential. The information is intended to be 
> for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, 
> distribution or use of the contents of this information, even if partially, including attached files, is strictly 
> prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any 
> disclosure, copying, distribution or use of the contents of this information, even if partially, including attached 
> files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to 
> inform about this communication and delete it.
>
>
>
> _______________________________________________
> NANOG mailing list
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/ZVYKHGCUYM7JJTCJLNQ75U6DOVR3NXEN/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/HFBDSWGNSLIM25TNIM7BLFUPEVQPZNP4/