I'm not sure I agree with Geoff's concern on fragmentation of the IPv4 internet due to growth and lack of v6 migration. I absolutely agree the increased cost of maintaining ever more complex and larger scaled NATs is going to continue to drive IPv6 migration but that these are possible is exactly why fragmentation won't happen in my mind.
The cost of fragmentation (due to growth, not other factors like national politics) is far greater than the cost of running even multiple levels of NAT (e.g. CG-NAT) and, apart from already being done in many places today, this scales to nearly the same level as IPv6. Yes, IPv6 has 128 bit addresses but over half of this address space will be "wasted" for ease of use like /64s and/or ease of allocation like allocating enormous blocks that will be sparsely filled with /64s for decades to come. Meanwhile GC-NAT allows nearly 100% utilization of any public IPs via dynamic assignment. Suddenly adding nearly 32 bits (there will be inefficiencies so it won't be the theoretical 32) of address pool on top of the nearly 32 bits address pool isn't all that far from the "128" bits of IPv6. It is however god awful complicated, slower/more latent due to needing to go to NAT points, and needs more centralized care and feeding to keep running, but not really at risk of being to limiting to drive a fragmented internet in anyone's lifetime due to "running out of NAT" or such.
Hopefully however these pressures from the burden of NATs and the ability to do more than just client+server model on TCP/UDP like the article points out and continues driving IPv6 to the point NAT64 becomes cheaper/easier to run and use than dual stack with v4 NAT.
Obligatory off topic plug (sorry dang) about this tech hacker site still being v4 only.
Note although half the bits in IPv6 are wasted under current schemes, almost 7/8 of the IPv6 space is unused, precisely so that if we screw up the public allocation we have many more chances to start over.
And there is no fundamental technical limitation on subnets smaller than /64, either. Should 45 bits not be enough (and it won't be, not forever!) we could start using DHCPv6 on smaller subnets, instead of using SLAAC.
There is a lot of assumptions that are broken if you try to allocate something smaller than /64. It would be like trying to re-assign the multicast address space for unicast.
But running out of space on IPv6 is seriously not a concern. Even a "paltry" 64 bits of address space is an absurdly large number of addresses. Humans need to have colonized the entire galaxy before it becomes an issue.
Yes, 64 bits is the same amount of space as an entire IPv4 Internet NAT'ed behind every IPv4 address on the current Internet. Actually more if you take multicast and reserved addresses into account.
I believe the current allocation plan allows for 2^45 "customers" getting a /48 each. While we don't have 2^45 humans get, it's not too hard to imagine having more than one "customer" per human especially due to corporations and multi-homing, and there will be unused space due to hierarchical allocations, and I'd say that with 128 bits available, probably more than 10 of them should be devoted to future-proofing.
If each customer were to get a /64 or a /60 or perhaps a /56 by default, that would leave plenty of room for inefficient hierarchical allocation and future-proofing. But that doesn't leave many bits for subnetting.
To my knowledge, the only thing that breaks in subnets smaller than /64 is automatic address assignment, i.e. SLAAC and privacy addresses, which are in no way required, merely convenient.
There are plenty of second order effects though. Like IPv6 blacklists operating at the /64 level or higher. Sharing a /64 is like being behind the same natted IPv4 address as a bad guy.
Right, I wasn't saying that giving end-users something smaller than a /64 should actually be done. Not only does it require more effort but also it breaks higher-level things as you said. I was just saying that there's no technical breakage that would occur, especially not SLAAC or privacy addresses.
> There is a lot of assumptions that are broken if you try to allocate something smaller than /64. It would be like trying to re-assign the multicast address space for unicast.
Can you go into some details as to what breaks? I ran a dual-stack network with /112s for host subnets, and /124s for ISLs (prefix lengths chosen to make life easier for the network operators) and I wasn't aware of any problems.
Certainly, you can't use (formerly known as) class D address space in IPv4 as the major IPv4 stacks will balk if you do, and you're never gonna get into class E space either for similar reasons, but ... to use a longer prefix length than /64 in IPv6? I'm unaware of any implementations that fall over, but it's been a few years since I paid any real attention.
> Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others. A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes.
SLAAC is part of that as well.
> I ran a dual-stack network with /112s for host subnets, and /124s for ISLs (prefix lengths chosen to make life easier for the network operators) and I wasn't aware of any problems.
Easiest for network operators is to act like IPv6 doesn't have different subnet mask at all, assume every subnet is always /64 and never have to remember funny patterns. Even a point to point is most often best done as a /64 instead of a /127. Most switching hardware prefers this as well actually, by ignoring the last 64 bits of the address in routing the hardware scales significantly better in terms of TCAM usage.
Yes, they have been pushing it for a long time. But its a major undertaking, so things take time. I think its just even more impressive that they have managed to push a decade long project steadily forwards. The latest memorandum that I linked even had a short summary of the previous initiatives:
> In August 2005, OMB issued M-05-22, Transition Planning for Internet Protocol Version 6 (IPv6), requiring agencies to enable 1Pv6 on their backbone networks by June 30, 2008. This policy outlined deployment and acquisition requirements. In September 2010, OMB issued a memo entitled "Transition to IPv6," requiring Federal agencies to operationa11y deploy native IPv6 for public Internet servers and internal applications that communicate with public servers. Specifically, the 2010 memorandum required agencies to upgrade public/external facing servers and services (e.g., web, email, DNS, ISP services) to operationa11y use native IPv6 by the end of FY 2012; and to and to upgrade internal client applications that communicate with public Internet servers and supporting enterprise networks to operationally use native IPv6 by the end of FY 2014
So that 2005 memorandum laid out groundwork to setup basic ipv6 backbone networks, and mandate purchases to be ipv6 compatible. That has been happening in the past 15 years so that now we are at the point that the latest memorandum is aiming to transitioning to IPv6-only deployments. If they set the requirement to be largely IPv6-only in just couple of years, then they must believe that there is good readiness for that at the moment, and I would like to think they have done their homework here.
I was on the IPv6 transition task force for a large federal agency (well, one of the military services) from 2008-2010. They don't take it seriously, don't fund it, there's no internal mandate or accountability around it, and nobody knows how the hell it works.
Funnily enough, the first attempt at such legislation back when there was much less commercial use of internet kinda failed due to vendor pressure and allowances for continued use of IPv4 (this was specific to DoD/Government networks, and was supposed to migrate to OSI and its up-to 20 bytes addresses)
If I were a dictator I would just put a deadline on it. January 1 2027: IPv4 forwarding is turned off on all core routers.
You can still use IPv4 internally if you have legacy devices, but anything on the Internet has to use IPv6. You have about 5 years to get it done. There are lots of solutions for specific use cases including stuff like ::ffff:1.2.3.4 and IPv4/IPv6 NAT devices. Most of which won't be as necessary as people think because IPv6 support is already widespread everywhere except ISPs.
The fundamental problem of v6 is that it is not a simple extension of v4 in a practical manners. Too many add-on concerns like security. Should have fit it on v4 as well.
This can be fixed not only with privacy addresses but also with DHCPv6 instead of SLAAC. The use of the MAC in this way was a bad bit of design but it's easily remedied. There is nothing in IPv6 that mandates that addresses be assigned this way. Like IPv4 they can be anything.
I personally like stuff like :feed:cafe:babe:beef or :dead:d00d :).
I agree they can be fixed, although I disagree that DHCPv6 is the solution given Android doesn't support DHCPv6. In practice most vendors I know of just use privacy addresses by default now for IPv6, at least outside servers, so it's mostly a non-issue but the fact remains it's something not applicable to IPv4. And for quite a while it was an issue, it's just that IPv6 hasn't been popular enough for consumers to care instead of just security people.
> There is nothing in IPv6 that mandates that addresses be assigned this way. Like IPv4 they can be anything.
Yes but that's nitpicking at the core RFCs vs the many other supporting RFCs. There's no IPv4 RFC for using a MAC in the IP address, whereas there is with IPv6 (rfc2373 from a quick look, maybe others).
It allows for tracking users since the second half of your address is always constant. It's a fixed problem though since basically all consumer devices these days use privacy extension addresses, which don't expose your MAC address and periodically change to a new random IP address
Also, this ignores the fact that IP address scanning is tremendously harder on IPv6 than it is on IPv4. That's a significant security improvement right off the bat.
All of the dozens of Internet bots that try to portscan my router every day would cease to be an issue if I could turn off my IPv4 address.
This is a common misconception. Apart from the kind of NATs we have now, there is no way that IPv4 could have been expanded. A lot of routing hardware was ASIC based (I'm sure plenty still is), so packet headers were fixed and couldn't be changed without changing all the routers. Just like they had to be changed with IPv6. Any server would need to understand the old system and the new system simultaneously to be able to be backwards compatible - just like with dual stack now. Big parts of the internet wouldn't be reachable until the host, the server, and every router and middle box along the path had been upgraded. Just like with IPv6.
So you'd have all the same problems, just in a slightly different way...
> his is a common misconception. Apart from the kind of NATs we have now, there is no way that IPv4 could have been expanded.
The misconception is that IPv4 could have been expanded in a compatible way. That's not GP's point though as I read it. They could have made an incompatible IPv5 which was exactly like IPv4, except with additional address bits.
Then the operational side would be similar, and you wouldn't have to learn everything over again.
we're probably 15-20 years away from "enough people have IPv6 that you can start dropping IPv4". There's zero chance you could make an IPv5 and have any adoption at all in that time.
You would start from scratch to develop chips that would support your new formats.
IPv4+TCP and IPv6+TCP is literally baked into hard silicon on many, many devices, even if not for all phases of the protocol. We're talking redesigning switching chips, redesigning TCAM (content-addressable memories used to cache routes), etc. on top of designing yet another protocol.
At least old IPv9 had the benefit of some level of support in sw/hw when it was proposed (as it reused CLNS from OSI for internetwork protocol)
>hey could have made an incompatible IPv5 which was exactly like IPv4, except with additional address bits.
That exists, it's called enhanced IP or something. I'm having trouble finding it now since it's been a few years, but I've had a customer using it. Of course nothing besides the endpoints understood it, so it had to be wrapped in UDP. Horrible.
If you are going to have to break backward compatibility anyway, of course you are going to use that as a chance to change other things, fix some things that weren't broken but weren't great either, try for some nice to haves while you are at it.
Especially if you were predicting a migration across any compatibility break would take decades or more (or potentially forever live side-by-side), there's very pragmatic reason "rip the bandaid off" and to change everything all at once rather than make a series of far more painful "smaller" migrations that would each individually take nearly as long.
IPv6 isn't that different than IPv4. Neighbor Discovery is just ARP. Not having in-path fragmentation and loads of other IPv4 legacy crap is a good thing.
The only major change is that instead of the smallest routeable unit being a single address the smallest unit is now a whole 64 bit subnet so hosts have a bunch of bits they can use for various purposes. Network administrators don't have to worry about that for the most part, the hosts figure that out on their own.
I guess there might be a security implication if someone has built their security system around knowing everything on the network via DHCP. But that was always a mistake. If you want real security you need to use 802.1x or similar. Being told you can't use DHCP to secure your network anymore is probably shock to some admins, but hopefully they take the opportunity to reconsider their system from the ground up.
There are a lot of changes needed, especially in (old) corporate environments.
I do use ipv6 at home, and at some of our customers, but some of them would have to essentially redesign their entire networking/vpn/security plan (and yes, existing ones are not good, split horizon DNS is almost always present, DHCP is not only used for security, but also for provisioning, there are products that scan subnets and provide reports on devices required for various compliances ...). And that is a hard sell, for what they see as next to no benefits.
You might be able to access it if you have an Apple device and Private Relay enabled. I only have IPv4 at home and was surprised to see an IPv6 address when I typed in "what is my ip" into Google. For the most part, Private Relay works pretty good.
Maybe the solution for more IPv6 adoption is for tech giants like Apple, Google, Microsoft to make proxies like Private Relay ubiquitous on every device/browser.
I set one up over a decade ago because Verizon said that they would need 6 months to deploy IPv6 on FiOS. I'm still using it.
Unfortunately in the meantime spammers have discovered HE tunnels and now I get a lot more CAPCHA's than I used to. I still check my FiOS link every month to see if Verizon has turned it on yet.
All of the laptops/computers in my house have IPv6-only web servers with LetsEncrypt certificates. (These computers all share a single IPv4 address.)
To get IPv6 on all computers I just installed radvd on the router. On the router I also set up a VPN to give the IPv6 addresses over IPv4 even when they're not local.
Yes, I run a site with 4 IPv6 only VPS servers with around 9M requests per month with the help of cloudflare.
In the past, setting up the server was hard(npm, composer, docker) but it has become less of a problem now.
GitHub is the major pain point even now. Even though I use bitbucket for scm which supports IPv6, surprising number of developer tools is centralized on GitHub.
My first home server was IPv6-only, straight off of my ADSL router with a public static IPv6 address and domain dedicated to entirely to a Raspberry Pi. It worked perfectly on mobile and at home. What a pain in the ass when I discovered my university didn't support IPv6 in any capacity. Their ASN has v6 blocks but no v6 routes on campus.
I set up a non-public-facing IPv6-only web server last night, so the issues are fresh in my mind! I'm fortunate enough to have an IPv6-capable home connection, and the hosting provider I use (Scaleway) charges extra for assigning IPv4 addresses to machines, so I thought I'd see how easy it would be to save a bit of money and make this machine IPv6-only. I've IP-filtered the host to only my home and my other servers, so having IPv4 support should be a waste.
The machine is now running fine, but I had a few roadblocks setting it up:
• My provisioning scripts download a release of 'dry'[0] from GitHub, which does not support IPv6. I ended up assigning my new machine a temporary IPv4 address and removing it later.
• The scripts also import a key from 'keyserver.ubuntu.com'[1], which, again, does not support IPv6. Attempting to connect just timed out, and if I hadn't just solved the other issue, I would have assumed the host was down.
• There seems to be a bug in Scaleway's cloud firewall (the things it calls Security Groups), where you cannot allow inbound ICMPv6, only standard ICMP (for IPv4). This meant my pings never responded and I thought the machine wasn't up when it was up.
Basically, what I want you to take away from this post is that if you disable IPv6, it's still the case that during maintenance, things are going to break, often mysteriously and with bad error messages, but outside of maintenance, things will likely run smoothly. My machine runs Sentry, and after the problems I had setting it up, I didn't dare run the Sentry './install.sh' script with IPv4 disabled as I didn't trust it to handle that case correctly — and even if the script reported no errors, I wouldn't have trusted there to actually be no errors. Since then, though, it's been running fine, so having an IPv6-only server is certainly possible, even if you have to give in and assign it an IPv4 address at the start, then take it away again later.
Original implementation of DirectAccess (Always-On, transparent VPN) in Windows Vista required working IPv6 connection, this was extended with HTTPS-over-v4 backup tunnel support later on when MS found out how hard it was to get consumer v6 in 2007. Inside of DirectAccess, connectivity is pure v6 still.
In fact, since NT6, Windows is IPv6-first system in many aspects, and Microsoft made news last year when they complained that they couldn't disable v4 on guest wifi at many offices due to non-Microsoft visiting workers having issues connecting to their VPNs due to software that didn't work with NAT64/DNS64.
I have a small ceph cluster over ipv6 and also a small OpenStack cluster with the daemons and web interface all running over V6 only. My network is dual stack since not all external networks are V6 compliant, and since I cannot seem to get cephadm's built in NFS service working over V6, so some of my local fileshares need v4.
My private Wireguard network is IPv6 only. SSH on all my remote servers listens on a random statically configured IPv6 address dedicated only for ssh. Since every server has an entire /64 prefix, a random internet scanner is never going to find it (Of course I still secure ssh properly since a man in the middle still sees what IPs I'm connecting to). Some cloud server providers started offering IPv6 only servers at a cheaper price to save money on unnecessary IPv4 addresses, so there's also a financial incentive to move non-public things to IPv6 only.
The way I see it, IPv6 is somebody else’s problem.
You can’t make money with IPv6 and nobody wants it. From a customer support perspective, IPv6 is just another problem nobody needs.
We, and all the other ISPs in our market, have enough IPv4 for the foreseeable future.
NAT works where you need to conserve addresses space and those consumers that need a static IPv4 can get it, and what’s better, will pay for it.
IPv6 support on consumer devices is a dumpster fire. No way I am touching that in production.
So, no, I have no plans to deploy IPv6 to customers. I will reconsider when there’s money in it, but preferably not before various vendors have gotten their IPv6 shit together.
In other words, we the current ISPs in the market are good. Sucks to be a new ISP though.
It is the classic example of FYGM. I'm old enough to remember when being a "good netizen" would have meant that medium-sized organizations would be pushing for the new standards and practices that would allow newcomer organizations, maybe even orgs that didn't yet exist, to join and participate on the network.
Now we've wound up where IPv4 addresses are like houses: everyone who already has one is quite content with the situation (and even sees them as "investments" to be traded and hoarded and leveraged) while newcomers are absolutely hosed. And doing the right thing of expanding the pool of availability, whether by allowing more housing to be built or by migrating to IPv6, is met with cries of "there's no money in it for me so I'm not interested."
And lest anyone thing this is petulant whining on the part of a sysadmin from a new network, where I work has several legacy IPv4 assignments and we own four or five low-digit ASNs. We are set for life for IPv4, yet we've picked up our IPv6 allocations from ARIN and have actively updated our internal network such that all applications can work in a v6-only environment and we've even donated some of our address space to new organizations in our field (medicine) who needed it to get started. That is how the Internet is supposed to work, through cooperation.
That's because those "good netizen"s remember how hard it was to get the network connected/up and keep it running in the first place. After a while, the new entrants just become parties with the option of some cheap IPv4 blocks and ASNs. Then they see the value of these blocks/AS increase. Then they say "well I have mine and I get no increased value from IPv6 so who cares" and they stay put becoming FYGMs.
> That is how the Internet is supposed to work, through cooperation.
Unfortunately this just isn't scaling :( Thanks for doing your part, I hope we all do what we can.
Eh I'd say the users of IPv6 (that includes ISPs and Enterprises) aren't to blame for not adopting the protocol.
The committee in charge of selecting IPng should have demanded interoperability or at least a proper transition plan. Neither happened and we have 25 years of IPv6 with abysmal adoption.
That's not true. For connections initiated from the v4 network, you can deploy v6 on the network, use a proxy, or use 6to4, 6rd or Teredo. For connections initiated from v6, you can use NAT64. There are also various approaches to deploy one protocol over the other, like 6over4, DS-lite, 464xlat, MAP-T/E, 4rd or LW4over6.
Pretty much every interoperability method that can work with v4 is supported by v6. How is that an interoperability failure?
> Pretty shit transition plan if we've only managed to get 35% of devices on v6 in 25 years.
The plan is "start using v6, then stop using v4". What better plan do you suggest?
I'd call it more like 35% in 9 years, since Google's stats say that deployment was <1% in 2013. (The time before that was spent on updating protocols, implementing the updated protocols in software and hardware, and deploying the updates, all of which are necessary prerequisites before users can show up in those stats.)
That seems like pretty decent going, given the sheer scale of what needs to be done.
> That's not true. For connections initiated from the v4 network, you can deploy v6 on the network
Having a v6 address on a v4 network doesn't make it a v4 only network. The vast majority of networks are v4 only. If the designers cared enough about interoperability and migration they would've spent time working on a plan to have these v4 only networks talk to v6. The transition plan would be seamless since the inherent value of a v4 address and a v6 address would be the same. If you look at the ngtrans mailing list, they pretty much gave up on a transition plan in the end, and there's still a bunch of deployment guides, even "best practices", but there's still no transition plan except this "get on v6, get off v4" rubbish.
The only reason the numbers are so high is because of Mobile since the telecom carriers have full control of the IP stack on the handset.
Again, what plan do you suggest? v6 already does everything that can be done with v4, yet that's not good enough for you. What more could they have done?
It's not fair to blame them for not being able to do the impossible.
The other choices for IPng at least tried to have an actual transition plan that would involve IPv4-only networks connecting to IPng. In fact the IPng criteria requirements outlined there be a straightforward transition plan from IPv4 that was simple and realistic. Then they settled for IPv6 which had no transition plan and still doesn't have one that meets the criteria set forth in the IPng requirements -- to this day.
The selection committee and ngtrans are to blame for not ever coming up with a transition plan that included interoperability with IPv4 as a basic tenet. They've effectively made IPv6 a second class protocol and will probably end up being like this forever.
IPv6 is effectively a waste of time, and that's how it's seen by most enterprise and ISPs. I'm holding out hope for research in future Internet architectures that will hopefully not make the same mistake as IPng and instead come up with actual transition plans with their designs.
What were those other choices/what transition plan did they have?
v6 does have a transition plan, and as far as I can tell it's not really possible to do any better than it's already doing. v6 is as interoperable with v4 as is possible to be, given the design of v4.
Can you explain how it could have been better? What transition plan would meet your requirements?
There is as good interoperability as is possible with various transition technologies allowing IPv4 and IPv6 hosts to reach other, with various variants of NATs or tunneling of IPv4 over IPv6 and vice-versa, mapping individual IPv6 addresses to IPv4, mapping the IPv4 space into IPv6, etc. etc.
The basic problem is though that IPv4 has no forward compatibility.
There is no way to build anything that has a larger address space than IPv4 and remain reachable for an IPv4-only host, since the IPv4 header has fixed 32-bit address fields.
This alone is the main limiting factor of the transition (combined with people refusing to dual-stack).
I wasn’t making a blanket statement about static IPv4 availability, rather it was an observation from our own market.
That being said, most carriers or major ISPs aren’t actually that hard up for IPv4 space.
By no means will static IPv4s be available on all plans, but merely changing AP or plan type will commonly result in the ability to purchase a static IPv4.
It’s mostly about lubricating with money to find a solution rather than an all out lack of IPv4.
> IPv6 support on consumer devices is a dumpster fire. No way I am touching that in production.
Is it still? I know this was true for a while, but things seem to have been ironed out. I only occasionally have IPv6 (my ISP is doing something weird), but when I do it all seems to work fine.
Consumer device support is not a major problem, it is ISPs that are the major roadblock. Corporate oriented devices are also a slow to adopt however, which is one reason ISPs have not made the switch.
Good IPv6 host support has been a thing in almost all consumer OSes for over 10 years now. All currently supported versions of Windows, MacOS, Android[1][2] and iOS support IPv6 natively.
And, as I keep reminding HN, Windows freaking XP supported IPv6 (albeit not as a transport for DNS queries).
The problem is simply that some people don’t want to spend a couple weekends to learn a new technology (one that is old enough to purchase alcohol in all 50 states—-this is not like chasing the latest web framework).
[1] There have been various blog posts about how android is “broken by design” because it expects to configure host IP via SLAAC and receive DNS servers via RA, instead of DHCPv6. This is utter nonsense.
[2] Android did, until about 5 years ago, not like to use DNS servers with ULA prefixes (the IPv6 equivalent of IPv4 private network ranges). That’s unfortunate, but hardly a “dumpster fire”.
> Good IPv6 host support has been a thing in almost all consumer OSes for over 10 years now. All currently supported versions of Windows, MacOS, Android[1][2] and iOS support IPv6 natively.
You probably need to care about the last couple unsupported versions, too; 5-year-old Android versions are still in the wild. Thankfully, it's a rolling window and the stuff with poor support is dropping off.
> The problem is simply that some people don’t want to spend a couple weekends to learn a new technology (one that is old enough to purchase alcohol in all 50 states—-this is not like chasing the latest web framework).
The problem, speaking as someone who spent some weekends worth of time on it, is that the technology, which has only been relevant for the last handful of years regardless of when it was first released, is not nearly that simple and works just differently enough to trip you up. (And you can't just do a full replacement and drop v4, so the differences will keep tripping you up)
At my house with about 10 online devices now i have 42 ipv6 entries in the nat table out of 272 total. I have at&T adsl but would see similar results with Comcast business (which i had until a month ago). I have either linux or newish commercial devices and they have slipped ipv6 in over the past few years. no more HE tunnels for me. I suspect if more websites put it in the DNS it would just work. I am just waiting for ipv6 only VPCs in AWS.
I have a properly set up house network with IPv4 and IPv6 support infrastructure. In December, we used 1.22 TiB total traffic, of which 722.96 GiB was IPv6.
IPv6 traffic has been at least 50% for at least the last year (based on the most convenient statistics I can grab).
My sample size of two DSL modems that my ISP supports says yes. The old one would reboot if it received a fragmented IPv6 packet. The newer one is better, it doesn't crash, it just delays more or less all packets for a second if IPv6 was in use.
Wireless router support for IPv6 is iffy too, from what I've heard.
As far as we can tell from aggregate statistics, consumer devices have been leading IPv6 adoption, not lagging it.
Charts of IPv6 usage such as Google's tend to still show a strong "bathtub curve" with a very noticeable decline during 9-5 work hours making a pretty clear case that corporate/enterprise devices are the ones (greatly) lagging behind.
Consumer devices most directly feel the effects of NAT/CGNAT and feel much more pressured to route around that IPv4 "damage" with IPv6. Some consumer networks, especially mobile carriers in every part of the world, have moved to IPv6-predominant (if not "IPv6-only"; depending on how you feel about IPv6 to IPv4 gateways). The "Happy Eyeballs" algorithm has been in play on most Consumer OSes for several years now and consumer devices generally strongly prefer IPv6 services over IPv4 when given a dual-stack choice.
There are a ton of IP connected devices that aren't running a sophisticated OS. IPv6 may not be available or, even if it is, the codebase is fossilized around handling and storing IPv4 addresses.
I don't know the state of IPv6 on consumer devices, but I can imagine from an ISP point of view it's a massive support burden.
IPv6 excels on smartphone handsets since the telecom company has full control of your network/IP stack. Simple to support and manage.
However consider a home network situation, you have the consumer router, and attached to it is a bunch of devices, some which have iffy support for IPv6. They all speak IPv4 well. From an ISP perspective supporting IPv4 only makes sense because it still works and you can count on downstream devices in a home network to support it. With the impending depletion of public IPv4 addresses, ISPs can rely on CGNAT. Less burden.
I'm not sure that is true. It is true that you don't get aliased by the NAT, but one of the features of IPv6 is that you don't have to stick to a single address. Your system can choose different source addresses for every connection if it wants to. You will of course still be on the same /64, but that is the same amount of tracking as IPv4/NAT provides.
That’s fine, each to their own. You might not be alone, but you should take into account that you are an atypical customer.
Different customers value different things. In the list of things people value in their broadband, IPv6 doesn’t even register for for the majority. There are markets where you cannot even give away IPv6 connectivity.
Of those showing an interest in IPv6, many just want a static IP. If you give them one then you have solved their problems and are never heard from again.
If you really, really want IPv6 then you can usually get it in most markets. You might have to upgrade to business service or switch to an operator providing service over legacy copper facilities. That is, however, a bridge too far for almost everybody.
As an aside, you don’t indicate that you would pay a premium for IPv6 service. That’s not very enticing from a business perspective. If there was real demand for IPv6 or it could be provided for a premium that would change.
It’s a classical chicken and egg situation. No services require IPv6, so there is no demand for IPv6 and thus no IPv6 offerings either.
I’d be interested to hear why you highly value IPv6 connectivity, especially if you had a static IPv4 allocation.
> Different customers value different things. In the list of things people value in their broadband, IPv6 doesn’t even register for for the majority.
The main issue for me is that it is symptomatic of a certain culture within that ISP. If they are late with IPv6, you can expect them to also be late with other developments, like the move to consumer 10gbit connections.
> As an ISP customer, you're the last one I would choose. I highly value ipv6 connectivity in my choice of ISP. I think I'm not alone.
When considering broadband connectivity, the major considerations for the vast majority of consumers, when signing their initial agreement, in order: price, speed, reliability.
Heck, I run BGP from my home, and even I didn't consider IPv6. But then I also have my own /22 of IPv4 (and a /32 of IPv6), so that's probably why.
I don’t appreciate it. It broke so much of the original end-to-end promise of the Internet. Think of how many technologies would be vastly easier if two hosts could directly communicate, like audio and voice chats. I still miss the days when it was trivial to run a web server on your home computer if you wanted to. And now we have abominations like CGNAT that break lesser abominations like UPnP.
If we hadn’t had NAT for the last couple of decades, and someone invented it now, they’d be laughed off the stage. You see it as an enabling technology. I see it as a boat anchor that’s kept us on IPv4 way past the sell-by date.
NAT has done more than the promise of IPv6. As much as NAT sucks to have at least it's been mostly frictionless to transition to -- that can't be said about IPv6. The design of IPv6 is what has held it back for 25 years, and I don't think we'll ever see a proper transition to it, so I'd say embrace NAT.
Hard disagree. The very first NAT broke a lot of cool things that already existed. Again, think of all the serverless things we could’ve had, like truly end-to-end peer-to-peer messaging that wasn’t routed dispatched through a central routing platform. (We’d still need a locator broker, but that’s far different than piping all content through a third-party host). NAT ruined those entire concepts because the whole concept of “every host is a potential server” went out the window.
Without NAT, we’ve have already made the transition to IPv6 as the creaky old IPv4 wouldn’t have that critical bandaid that helped it limp along. IPv4+NAT can’t die quickly enough.
I personally have a dedicated IP, but the ISP's public reports say that no new customers will be able to obtain a dedicated IPs some time after 2024 or maybe 2025.
The default for all new customers is CG-NAT, unless they're tech-savvy enough to ask for something better.
115 comments
[ 3.0 ms ] story [ 208 ms ] threadThe cost of fragmentation (due to growth, not other factors like national politics) is far greater than the cost of running even multiple levels of NAT (e.g. CG-NAT) and, apart from already being done in many places today, this scales to nearly the same level as IPv6. Yes, IPv6 has 128 bit addresses but over half of this address space will be "wasted" for ease of use like /64s and/or ease of allocation like allocating enormous blocks that will be sparsely filled with /64s for decades to come. Meanwhile GC-NAT allows nearly 100% utilization of any public IPs via dynamic assignment. Suddenly adding nearly 32 bits (there will be inefficiencies so it won't be the theoretical 32) of address pool on top of the nearly 32 bits address pool isn't all that far from the "128" bits of IPv6. It is however god awful complicated, slower/more latent due to needing to go to NAT points, and needs more centralized care and feeding to keep running, but not really at risk of being to limiting to drive a fragmented internet in anyone's lifetime due to "running out of NAT" or such.
Hopefully however these pressures from the burden of NATs and the ability to do more than just client+server model on TCP/UDP like the article points out and continues driving IPv6 to the point NAT64 becomes cheaper/easier to run and use than dual stack with v4 NAT.
Obligatory off topic plug (sorry dang) about this tech hacker site still being v4 only.
And there is no fundamental technical limitation on subnets smaller than /64, either. Should 45 bits not be enough (and it won't be, not forever!) we could start using DHCPv6 on smaller subnets, instead of using SLAAC.
But running out of space on IPv6 is seriously not a concern. Even a "paltry" 64 bits of address space is an absurdly large number of addresses. Humans need to have colonized the entire galaxy before it becomes an issue.
If each customer were to get a /64 or a /60 or perhaps a /56 by default, that would leave plenty of room for inefficient hierarchical allocation and future-proofing. But that doesn't leave many bits for subnetting.
To my knowledge, the only thing that breaks in subnets smaller than /64 is automatic address assignment, i.e. SLAAC and privacy addresses, which are in no way required, merely convenient.
Several blocklists I'm aware of block at /48s, not at /64s, on the basis that customer allocations (per the spec) are supposed to be /48s.
Not enough people use IPv6 right now, so the level of complaints from this is low->zero.
Can you go into some details as to what breaks? I ran a dual-stack network with /112s for host subnets, and /124s for ISLs (prefix lengths chosen to make life easier for the network operators) and I wasn't aware of any problems.
Certainly, you can't use (formerly known as) class D address space in IPv4 as the major IPv4 stacks will balk if you do, and you're never gonna get into class E space either for similar reasons, but ... to use a longer prefix length than /64 in IPv6? I'm unaware of any implementations that fall over, but it's been a few years since I paid any real attention.
> Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others. A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes.
SLAAC is part of that as well.
> I ran a dual-stack network with /112s for host subnets, and /124s for ISLs (prefix lengths chosen to make life easier for the network operators) and I wasn't aware of any problems.
Easiest for network operators is to act like IPv6 doesn't have different subnet mask at all, assume every subnet is always /64 and never have to remember funny patterns. Even a point to point is most often best done as a /64 instead of a /127. Most switching hardware prefers this as well actually, by ignoring the last 64 bits of the address in routing the hardware scales significantly better in terms of TCAM usage.
edit: luddite not meant in a derogatory sense. We need luddites!
> At least 80% of IP-enabled assets on Federal networks are operating in IPv6-only environments by the end of FY 2025
https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-0...
Like, the US Govt has been 'going to move to ipv6' real soon now since I was a baby engineer.
> In August 2005, OMB issued M-05-22, Transition Planning for Internet Protocol Version 6 (IPv6), requiring agencies to enable 1Pv6 on their backbone networks by June 30, 2008. This policy outlined deployment and acquisition requirements. In September 2010, OMB issued a memo entitled "Transition to IPv6," requiring Federal agencies to operationa11y deploy native IPv6 for public Internet servers and internal applications that communicate with public servers. Specifically, the 2010 memorandum required agencies to upgrade public/external facing servers and services (e.g., web, email, DNS, ISP services) to operationa11y use native IPv6 by the end of FY 2012; and to and to upgrade internal client applications that communicate with public Internet servers and supporting enterprise networks to operationally use native IPv6 by the end of FY 2014
So that 2005 memorandum laid out groundwork to setup basic ipv6 backbone networks, and mandate purchases to be ipv6 compatible. That has been happening in the past 15 years so that now we are at the point that the latest memorandum is aiming to transitioning to IPv6-only deployments. If they set the requirement to be largely IPv6-only in just couple of years, then they must believe that there is good readiness for that at the moment, and I would like to think they have done their homework here.
You can still use IPv4 internally if you have legacy devices, but anything on the Internet has to use IPv6. You have about 5 years to get it done. There are lots of solutions for specific use cases including stuff like ::ffff:1.2.3.4 and IPv4/IPv6 NAT devices. Most of which won't be as necessary as people think because IPv6 support is already widespread everywhere except ISPs.
No need to worry about silly things like the popularity of such a move, the cost involved and the mountain of e-waste produced.
Good luck.
I personally like stuff like :feed:cafe:babe:beef or :dead:d00d :).
> There is nothing in IPv6 that mandates that addresses be assigned this way. Like IPv4 they can be anything.
Yes but that's nitpicking at the core RFCs vs the many other supporting RFCs. There's no IPv4 RFC for using a MAC in the IP address, whereas there is with IPv6 (rfc2373 from a quick look, maybe others).
All of the dozens of Internet bots that try to portscan my router every day would cease to be an issue if I could turn off my IPv4 address.
Here's a guide on secure router configs and an overview of some threats that are new in ipv6.
So you'd have all the same problems, just in a slightly different way...
The misconception is that IPv4 could have been expanded in a compatible way. That's not GP's point though as I read it. They could have made an incompatible IPv5 which was exactly like IPv4, except with additional address bits.
Then the operational side would be similar, and you wouldn't have to learn everything over again.
Instead they changed just about everything.
Because we're decades in here, and it's still not dominant, for the reasons given.
https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6...
we're probably 15-20 years away from "enough people have IPv6 that you can start dropping IPv4". There's zero chance you could make an IPv5 and have any adoption at all in that time.
IPv4+TCP and IPv6+TCP is literally baked into hard silicon on many, many devices, even if not for all phases of the protocol. We're talking redesigning switching chips, redesigning TCAM (content-addressable memories used to cache routes), etc. on top of designing yet another protocol.
At least old IPv9 had the benefit of some level of support in sw/hw when it was proposed (as it reused CLNS from OSI for internetwork protocol)
That exists, it's called enhanced IP or something. I'm having trouble finding it now since it's been a few years, but I've had a customer using it. Of course nothing besides the endpoints understood it, so it had to be wrapped in UDP. Horrible.
Especially if you were predicting a migration across any compatibility break would take decades or more (or potentially forever live side-by-side), there's very pragmatic reason "rip the bandaid off" and to change everything all at once rather than make a series of far more painful "smaller" migrations that would each individually take nearly as long.
The only major change is that instead of the smallest routeable unit being a single address the smallest unit is now a whole 64 bit subnet so hosts have a bunch of bits they can use for various purposes. Network administrators don't have to worry about that for the most part, the hosts figure that out on their own.
I guess there might be a security implication if someone has built their security system around knowing everything on the network via DHCP. But that was always a mistake. If you want real security you need to use 802.1x or similar. Being told you can't use DHCP to secure your network anymore is probably shock to some admins, but hopefully they take the opportunity to reconsider their system from the ground up.
I do use ipv6 at home, and at some of our customers, but some of them would have to essentially redesign their entire networking/vpn/security plan (and yes, existing ones are not good, split horizon DNS is almost always present, DHCP is not only used for security, but also for provisioning, there are products that scan subnets and provide reports on devices required for various compliances ...). And that is a hard sell, for what they see as next to no benefits.
Maybe the solution for more IPv6 adoption is for tech giants like Apple, Google, Microsoft to make proxies like Private Relay ubiquitous on every device/browser.
https://www.tunnelbroker.net/
Unfortunately in the meantime spammers have discovered HE tunnels and now I get a lot more CAPCHA's than I used to. I still check my FiOS link every month to see if Verizon has turned it on yet.
It worked perfect for that in almost every situation since my cell carrier supported v6 so any time I'm not home I could still access it.
To get IPv6 on all computers I just installed radvd on the router. On the router I also set up a VPN to give the IPv6 addresses over IPv4 even when they're not local.
It's great.
In the past, setting up the server was hard(npm, composer, docker) but it has become less of a problem now.
GitHub is the major pain point even now. Even though I use bitbucket for scm which supports IPv6, surprising number of developer tools is centralized on GitHub.
The machine is now running fine, but I had a few roadblocks setting it up:
• My provisioning scripts download a release of 'dry'[0] from GitHub, which does not support IPv6. I ended up assigning my new machine a temporary IPv4 address and removing it later.
• The scripts also import a key from 'keyserver.ubuntu.com'[1], which, again, does not support IPv6. Attempting to connect just timed out, and if I hadn't just solved the other issue, I would have assumed the host was down.
• There seems to be a bug in Scaleway's cloud firewall (the things it calls Security Groups), where you cannot allow inbound ICMPv6, only standard ICMP (for IPv4). This meant my pings never responded and I thought the machine wasn't up when it was up.
Basically, what I want you to take away from this post is that if you disable IPv6, it's still the case that during maintenance, things are going to break, often mysteriously and with bad error messages, but outside of maintenance, things will likely run smoothly. My machine runs Sentry, and after the problems I had setting it up, I didn't dare run the Sentry './install.sh' script with IPv4 disabled as I didn't trust it to handle that case correctly — and even if the script reported no errors, I wouldn't have trusted there to actually be no errors. Since then, though, it's been running fine, so having an IPv6-only server is certainly possible, even if you have to give in and assign it an IPv4 address at the start, then take it away again later.
[0]: https://github.com/moncho/dry [1]: https://keyserver.ubuntu.com/
Original implementation of DirectAccess (Always-On, transparent VPN) in Windows Vista required working IPv6 connection, this was extended with HTTPS-over-v4 backup tunnel support later on when MS found out how hard it was to get consumer v6 in 2007. Inside of DirectAccess, connectivity is pure v6 still.
In fact, since NT6, Windows is IPv6-first system in many aspects, and Microsoft made news last year when they complained that they couldn't disable v4 on guest wifi at many offices due to non-Microsoft visiting workers having issues connecting to their VPNs due to software that didn't work with NAT64/DNS64.
You can’t make money with IPv6 and nobody wants it. From a customer support perspective, IPv6 is just another problem nobody needs.
We, and all the other ISPs in our market, have enough IPv4 for the foreseeable future.
NAT works where you need to conserve addresses space and those consumers that need a static IPv4 can get it, and what’s better, will pay for it.
IPv6 support on consumer devices is a dumpster fire. No way I am touching that in production.
So, no, I have no plans to deploy IPv6 to customers. I will reconsider when there’s money in it, but preferably not before various vendors have gotten their IPv6 shit together.
In other words, we the current ISPs in the market are good. Sucks to be a new ISP though.
It's more newly formed companies that are hit by this, since they have none and have to buy them at ever increasing prices.
Now we've wound up where IPv4 addresses are like houses: everyone who already has one is quite content with the situation (and even sees them as "investments" to be traded and hoarded and leveraged) while newcomers are absolutely hosed. And doing the right thing of expanding the pool of availability, whether by allowing more housing to be built or by migrating to IPv6, is met with cries of "there's no money in it for me so I'm not interested."
And lest anyone thing this is petulant whining on the part of a sysadmin from a new network, where I work has several legacy IPv4 assignments and we own four or five low-digit ASNs. We are set for life for IPv4, yet we've picked up our IPv6 allocations from ARIN and have actively updated our internal network such that all applications can work in a v6-only environment and we've even donated some of our address space to new organizations in our field (medicine) who needed it to get started. That is how the Internet is supposed to work, through cooperation.
> That is how the Internet is supposed to work, through cooperation.
Unfortunately this just isn't scaling :( Thanks for doing your part, I hope we all do what we can.
The committee in charge of selecting IPng should have demanded interoperability or at least a proper transition plan. Neither happened and we have 25 years of IPv6 with abysmal adoption.
Pretty shit transition plan if we've only managed to get 35% of devices on v6 in 25 years.
Pretty much every interoperability method that can work with v4 is supported by v6. How is that an interoperability failure?
> Pretty shit transition plan if we've only managed to get 35% of devices on v6 in 25 years.
The plan is "start using v6, then stop using v4". What better plan do you suggest?
I'd call it more like 35% in 9 years, since Google's stats say that deployment was <1% in 2013. (The time before that was spent on updating protocols, implementing the updated protocols in software and hardware, and deploying the updates, all of which are necessary prerequisites before users can show up in those stats.)
That seems like pretty decent going, given the sheer scale of what needs to be done.
Having a v6 address on a v4 network doesn't make it a v4 only network. The vast majority of networks are v4 only. If the designers cared enough about interoperability and migration they would've spent time working on a plan to have these v4 only networks talk to v6. The transition plan would be seamless since the inherent value of a v4 address and a v6 address would be the same. If you look at the ngtrans mailing list, they pretty much gave up on a transition plan in the end, and there's still a bunch of deployment guides, even "best practices", but there's still no transition plan except this "get on v6, get off v4" rubbish.
The only reason the numbers are so high is because of Mobile since the telecom carriers have full control of the IP stack on the handset.
It's not fair to blame them for not being able to do the impossible.
The selection committee and ngtrans are to blame for not ever coming up with a transition plan that included interoperability with IPv4 as a basic tenet. They've effectively made IPv6 a second class protocol and will probably end up being like this forever.
IPv6 is effectively a waste of time, and that's how it's seen by most enterprise and ISPs. I'm holding out hope for research in future Internet architectures that will hopefully not make the same mistake as IPng and instead come up with actual transition plans with their designs.
v6 does have a transition plan, and as far as I can tell it's not really possible to do any better than it's already doing. v6 is as interoperable with v4 as is possible to be, given the design of v4.
Can you explain how it could have been better? What transition plan would meet your requirements?
The basic problem is though that IPv4 has no forward compatibility. There is no way to build anything that has a larger address space than IPv4 and remain reachable for an IPv4-only host, since the IPv4 header has fixed 32-bit address fields. This alone is the main limiting factor of the transition (combined with people refusing to dual-stack).
Not necessarily. Some ISPs and majority of cell providers in Europe only give you CGN IPv4. No IPv6, no static option.
That being said, most carriers or major ISPs aren’t actually that hard up for IPv4 space.
By no means will static IPv4s be available on all plans, but merely changing AP or plan type will commonly result in the ability to purchase a static IPv4.
It’s mostly about lubricating with money to find a solution rather than an all out lack of IPv4.
Is it still? I know this was true for a while, but things seem to have been ironed out. I only occasionally have IPv6 (my ISP is doing something weird), but when I do it all seems to work fine.
Good IPv6 host support has been a thing in almost all consumer OSes for over 10 years now. All currently supported versions of Windows, MacOS, Android[1][2] and iOS support IPv6 natively.
And, as I keep reminding HN, Windows freaking XP supported IPv6 (albeit not as a transport for DNS queries).
The problem is simply that some people don’t want to spend a couple weekends to learn a new technology (one that is old enough to purchase alcohol in all 50 states—-this is not like chasing the latest web framework).
[1] There have been various blog posts about how android is “broken by design” because it expects to configure host IP via SLAAC and receive DNS servers via RA, instead of DHCPv6. This is utter nonsense.
[2] Android did, until about 5 years ago, not like to use DNS servers with ULA prefixes (the IPv6 equivalent of IPv4 private network ranges). That’s unfortunate, but hardly a “dumpster fire”.
You probably need to care about the last couple unsupported versions, too; 5-year-old Android versions are still in the wild. Thankfully, it's a rolling window and the stuff with poor support is dropping off.
> The problem is simply that some people don’t want to spend a couple weekends to learn a new technology (one that is old enough to purchase alcohol in all 50 states—-this is not like chasing the latest web framework).
The problem, speaking as someone who spent some weekends worth of time on it, is that the technology, which has only been relevant for the last handful of years regardless of when it was first released, is not nearly that simple and works just differently enough to trip you up. (And you can't just do a full replacement and drop v4, so the differences will keep tripping you up)
My guess is that it is still a tiny minority of non-computer devices that will use ipv6 on the LAN side of a router.
IPv6 traffic has been at least 50% for at least the last year (based on the most convenient statistics I can grab).
Wireless router support for IPv6 is iffy too, from what I've heard.
Charts of IPv6 usage such as Google's tend to still show a strong "bathtub curve" with a very noticeable decline during 9-5 work hours making a pretty clear case that corporate/enterprise devices are the ones (greatly) lagging behind.
Consumer devices most directly feel the effects of NAT/CGNAT and feel much more pressured to route around that IPv4 "damage" with IPv6. Some consumer networks, especially mobile carriers in every part of the world, have moved to IPv6-predominant (if not "IPv6-only"; depending on how you feel about IPv6 to IPv4 gateways). The "Happy Eyeballs" algorithm has been in play on most Consumer OSes for several years now and consumer devices generally strongly prefer IPv6 services over IPv4 when given a dual-stack choice.
IPv6 excels on smartphone handsets since the telecom company has full control of your network/IP stack. Simple to support and manage.
However consider a home network situation, you have the consumer router, and attached to it is a bunch of devices, some which have iffy support for IPv6. They all speak IPv4 well. From an ISP perspective supporting IPv4 only makes sense because it still works and you can count on downstream devices in a home network to support it. With the impending depletion of public IPv4 addresses, ISPs can rely on CGNAT. Less burden.
Different customers value different things. In the list of things people value in their broadband, IPv6 doesn’t even register for for the majority. There are markets where you cannot even give away IPv6 connectivity.
Of those showing an interest in IPv6, many just want a static IP. If you give them one then you have solved their problems and are never heard from again.
If you really, really want IPv6 then you can usually get it in most markets. You might have to upgrade to business service or switch to an operator providing service over legacy copper facilities. That is, however, a bridge too far for almost everybody.
As an aside, you don’t indicate that you would pay a premium for IPv6 service. That’s not very enticing from a business perspective. If there was real demand for IPv6 or it could be provided for a premium that would change.
It’s a classical chicken and egg situation. No services require IPv6, so there is no demand for IPv6 and thus no IPv6 offerings either.
I’d be interested to hear why you highly value IPv6 connectivity, especially if you had a static IPv4 allocation.
AKA the ipv6 "blockchain" situation lol
The main issue for me is that it is symptomatic of a certain culture within that ISP. If they are late with IPv6, you can expect them to also be late with other developments, like the move to consumer 10gbit connections.
When considering broadband connectivity, the major considerations for the vast majority of consumers, when signing their initial agreement, in order: price, speed, reliability.
Heck, I run BGP from my home, and even I didn't consider IPv6. But then I also have my own /22 of IPv4 (and a /32 of IPv6), so that's probably why.
Stop right there.
If we hadn’t had NAT for the last couple of decades, and someone invented it now, they’d be laughed off the stage. You see it as an enabling technology. I see it as a boat anchor that’s kept us on IPv4 way past the sell-by date.
Without NAT, we’ve have already made the transition to IPv6 as the creaky old IPv4 wouldn’t have that critical bandaid that helped it limp along. IPv4+NAT can’t die quickly enough.
Yours might but mine ran out years ago.
No public cloud provider is able to provide a dedicated IPv4 address per endpoint, making cloud networking absurdly complex unnecessarily.
Entire continents are under provisioned and will never get more allocation to meet future demand.
Out of interest, why didn’t you re-up when you still could?
You could still get some two years ago.
The default for all new customers is CG-NAT, unless they're tech-savvy enough to ask for something better.
I do got a /64 IPv6 range however!