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.
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.
> 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.
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.
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 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.
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.
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 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.
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.
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.
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)
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 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...
[+] [-] zamadatix|4 years ago|reply
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.
[+] [-] immibis|4 years ago|reply
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.
[+] [-] ISP_throwaway|4 years ago|reply
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.
[+] [-] yjftsjthsd-h|4 years ago|reply
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.
[+] [-] nousermane|4 years ago|reply
Not necessarily. Some ISPs and majority of cell providers in Europe only give you CGN IPv4. No IPv6, no static option.
[+] [-] hossbeast|4 years ago|reply
[+] [-] welterde|4 years ago|reply
It's more newly formed companies that are hit by this, since they have none and have to buy them at ever increasing prices.
[+] [-] jiggawatts|4 years ago|reply
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.
[+] [-] kstrauser|4 years ago|reply
Stop right there.
[+] [-] usbqk|4 years ago|reply
[+] [-] rwmj|4 years ago|reply
[+] [-] cytzol|4 years ago|reply
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/
[+] [-] xPaw|4 years ago|reply
[+] [-] miyuru|4 years ago|reply
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.
[+] [-] escalt|4 years ago|reply
[+] [-] DarylZero|4 years ago|reply
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.
[+] [-] _zllx|4 years ago|reply
[+] [-] sekh60|4 years ago|reply
[+] [-] p_l|4 years ago|reply
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.
[+] [-] bin_bash|4 years ago|reply
[+] [-] Klathmon|4 years ago|reply
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.
[+] [-] api|4 years ago|reply
[+] [-] pantalaimon|4 years ago|reply
[+] [-] hcurtiss|4 years ago|reply
[+] [-] pojntfx|4 years ago|reply
[+] [-] zokier|4 years ago|reply
> 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...
[+] [-] jandrese|4 years ago|reply
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.
[+] [-] p_l|4 years ago|reply
[+] [-] ngcc_hk|4 years ago|reply
Good luck.
[+] [-] stephen_g|4 years ago|reply
So you'd have all the same problems, just in a slightly different way...
[+] [-] api|4 years ago|reply