I have even implemented an IPv6-Only network. It fully works, including accessing IPv4 only websites like github.com via DNS64 and NAT64 at my router.
The only practically useful thing about my IPv6 enabled network is that I can run globally routable services on my lan, without NAT port mapping. Of course, only if the client is also IPv6.
Other than this one use case, IPv6 does nothing for me.
It doesn't work from most hotels, nor from my work lan, nor many other places because most "managed" networks are IPv4 only. It works better at Cafes because they are "unmanaged" and IPv6 is enabled by the most common ISPs, like ATT and Comcast and their provided routers.
Based on this experience, I think IPv6 is less valuable than us HN audience thinks it is. Private networks, NAT, Carrier Grade NAT are good enough, and internet really doesn't care about being completely peer-to-peer.
I think the adoption rate reflects this--it's a linear growth curve over the last 25 years. It should have been exponential.
I think cost of IPv4 reflects this--it is now below the peak, and has leveled off.
As surprising as it seems, IPv4 exhaustion has not been a serious problem. Internet marches on. IPv6 is still a solution looking for a problem, and IPv4 exhaustion wasn't one of them.
I recently moved to a 'cheap' ISP because I could get double the speed for half the price. They use CG-NAT and it's been awful.
I don't need to forward any ports but seemingly because I share an IP with a billion people I get Captchas everywhere (Google, Cloudflare etc.). I was even blocked from accessing Reddit without an account at some point.
I've been using Starlink since early 2021 with IPv6 only internally. Starlink User Terminal hands out a /56 prefix (via DHCPv6) and mine has not changed in all that time so I wouldn't call it dynamic.
The User Terminal issues a router advertisement (RA) and my gateway gives itself an address in that /64 via SLAAC in addition to assigning itself an address from the /56 prefix.
If not using prefix delegation each host's address is dependent on their SLAAC policy - if not preferring stable addresses (e.g: EUI64) then of course the public address will vary (be dynamic) when using temporary "privacy" addresses.
My gateway delegates /60 sub-prefixes of the /56 and bare-metal hosts then either delegates /62 or advertises /64s from the /60 to VMs, containers, network namespaces and so forth.
As someone else described, I have my gateway also delegate ULA prefixes by changing just the first two octets of the public delegated prefix to fddc (fd = ULA, dc = "data center :) but otherwise identical and likewise on the bare-metal hosts, etc.
ULA is used for internal services; ISP delegated prefix for anything that needs public access.
Multicast-DNS takes care of internal hostnames; everything is ${hostname}.local
There's a separate VLAN for legacy IPv4-only devices that does NAT64 using a ULA prefix.
DNS64/NAT64 for the laggards like github.com that can't grok 128 bit addresses :)
The only time I have problems with web services is when their DNS advertises an AAAA resource record but their firewall/load-balancers/servers are not configured to allow/listen on it.
As for static addresses, it says "a reservation system retains the ... IPv6 prefix even when the system is off or rebooted. However, relocating the Starlink or software updates may change these addresses."
I suspect in practice the IPv6 address will only change if you get moved to a different POP ground station. Some customers never get moved. I've been moved several times because I'm in NorCal and they keep switching me between Seattle and Los Angeles.
Yes, I use direct IPv6 peer-to-peer connections both outbound and inbound using the delegated prefix.
Even for a changing prefix, if operating a DNS authoritative server for a domain, any changes to the prefix can be quickly and automatically updated in both forward (AAAA) and reverse (PTR) resource records provided the TTL for those records is appropriately short, and thus allow almost seamless inbound via FQDNs. I do this with a bind9 (hidden) master locally that notifies external slave servers operated by a highly available, anycast, DNS service.
Why do dynamic address allocations matter? Most IPv4 consumer WAN addresses are also dynamic.
I’m asking, because I’m an advocate of having your gateway advertise a separate, stable ULA /64 in conjunction with the globally-routable dynamic /64.
This gives you a stable set of addressable LAN IPs, and you can usually ignore the dynamic globally routable IPs.
Granted this won’t work for everyone, but if dynamic global addresses are an issue, you should be requesting a plan that supports a static delegation from your ISP anyway.
It matters, because when the prefix changes, it changes IP addresses of every single device in your network.
As you wrote, internally, you can use ULA. But you cannot open access from outside, because your firewall rules will become invalid with prefix change. With classic IPv4 NAT, your internal addresses don't change, so your port forwarding works, even if the WAN address changes.
Together, with a single /64 -- which means no subnets for you -- you are getting worse deal than with IPv4. You shouldn't have to contact your ISP for a plan (for a premium, obviously), that allows you to segment your network or open access to specific devices. What's the use of direct connections -- the IPv6 promise -- when you cannot use them anyway?
In short, with limitations like these, you are getting a bad deal.
I don’t know what router you use, but openwrt lets you set firewall rules that only match the last 64 bits. This should solve your problem, provided you configure your router to hand out static IPv6 leases to devices.
There are wildly different solutions for different routers.
I'm using Mikrotik, which doesn't allow prefix-less addresses in firewall, but allows you to put hostnames into your rules (so it will ask DNS what the address is and once the ttl expires, it will ask again).
On some CPEs (I don't remember which), it allowed to enter mac addresses, so the forwarding would always work for specific device, with any GUA address.
But we have to remember, that all these solution are optional and brand-specific; there's a wide range of devices that do not have anything to solve this problem.
> It matters, because when the prefix changes, it changes IP addresses of every single device in your network.
My solution for my home network was to write a script that periodically checks my IPv6 prefix and updates the firewall rules and DNS if it ever changes. It doesn't feel like a great way to do it but it seems to work.
SLAAC requires the bottom 64 bits to be part of the host portion of the address. A network prefix larger than /64 limits SLAAC to providing link-local addresses only, which means another mechanism needs to provide routable addresses, such as DHCPv6. That, in turn, prevents the use of privacy addresses.
DHCPv6 is also optional, clients do not have to support it; some do not support it intentionally. So for example, any Android device won't be up and running on SLAAC-less network.
I think the OC was arguing that if your global /64 changes, the firewall rules would change as well for any hosted services.
I proposed that you might be able to route the external router’s WAN to a ULA via NAT to save in complexity when the PD changes, but I agree that a static delegation would by far be the easiest. Us home hosters aren’t used to that even though it is technically against the license agreement more often than not.
I'd imagine that to be short lived. IPv6 having such a huge address spaces means the IP reputations are even more worthless than IPv4 so eventually the bots would use it too, and if the ratio of bots to real users become too high sites may refuse IPv6 traffic altogether.
It’s a little different though in that rather than an IP having a bad reputation, it’s usually a /64. That’s how I have seen IPv6 reputation managed since it’s a common network slice & NAT is not really used anymore.
Ooof that's an ugly thought. But I think "refuse IPv6 traffic altogether" is not possible for any consumer site. Per the article, there's 40% adoption of IPv6 now and it's only growing. Major parts of the world rely on IPv6 working right. I guess sites could go IPv4-only but given how many other problems there are with IP reputations, that'd be awfully dumb.
CAPTCHAs are the main reason I turned IPv6 on. No idea if it will actually help in practice, it's hard to measure.
The other Starlink hassle is the geocoding for user IPv4 addresses is wildly wrong. I'm in Grass Valley, CA near Sacramento but sites all think my IP is either in Seattle or Los Angeles, depending on the week. This makes streaming services a huge PITA, I have to jump through hoops to convince them I'm in the Sacramento TV market about once a month. IPv6 could help with this too, Starlink could give out more precisely geolocated addresses. Not sure they're doing it though, all I see are IPv4 addresses in the geocoding feed: https://geoip.starlinkisp.net/feed.csv
Or, as an alternative, we try to convince people that geoIP lookups are at best uncertain and at worst actively misleading -- and perhaps shouldn't be taken at face value. I personally think this would be a great thing. For paid services that allegedly need to know where you are geographically located, use your billing address. For advertisers it's one less bit of useful information...
I was on a cruise ship in the Caribbean for a week just last month and I purchased the starlink powered internet package. Looking at my IP data, location info showed that I was actually in Dallas, Texas. Very sad!
> The only practically useful thing about my IPv6 enabled network is that I can run globally routable services on my lan, without NAT port mapping. Of course, only if the client is also IPv6.
A couple of other practically useful things:
- You never get address collisions when connecting to someone else's VPN, or connecting to your home network via VPN from someone else's private network (if you've set that up)
- If there are two people living in your home, they can play online games against a mutual friend who doesn't live in the home without anything breaking
I think you're right that IPv6 isn't a game-changing improvement for most people. It gets rid of some annoyances, it's the obviously correct thing to do for new networks (and cheaper than setting up CGNAT), but fundamentally the pile of hacks on IPv4 is "good enough" for most use cases.
so for anyone that "just browses the web" (which is overwhelming majority) there is virtually no difference/benefit?
I don't play online games, don't use VPN, have a couple of services on my local RPi that has port forwarded on router and that's it...
ipv6 could be handy when testing some service on my laptop and trying with external services but this happens so rarely that it's not an issue... on the flipside, whenever I enable ipv6 I usually run into problems :|
One, the most obvious, is actually having distributed net and serving content from your own machine and in the ancient times like 15 years ago Opera tried that by bundling sort of local http-server (?!, can't even remember the name of the project…) but it floped... I'm not sure that ipv4 was the issue or rather the fact that people don't usually have or want their machine work 24/7...
for calls we have to rely on STUN/TURN but than again some consider this a feature as it hides external IP... which with ipv6 would be even more privacy invading?
I’m hesitant to suggest specific use cases because general purpose technologies are hard to predict in their applications. I doubt whether anyone accurately forecasted the impact of JS in the browser, for example.
However, I’d love to be able to interact with my car, CCTV cameras and other IoT devices at long distance with fewer middlemen involved.
I don't see significant difference for most private people. I guess the median has three phones, a tablet and a tv box, there's not much scope to improve the network for that use case.
But IPv6 makes a difference for some other situations. If you operate a network with routers and such, it makes sense to have all connections to internal services use IPv6. Backup, file storage, databases, management interfaces, blah: Give everything its own IPv6 address, don't accept connections on IPv4, and allow IPv4 packets from 192.168/16 only to the outside world.
It's likely the web itself has been shaped by the technology underpinning it. The article would seem to suggest something similar. Look at email. Now we all connect to the central email servers at Google and they handle most of everything else. Perhaps on the IPv6 internet, you would be able to buy a USB stick that handles all your emails for you. No more centralised mail, you just have a small server in your house that does it for you. The same of social media, etc. It would be feasible to offer an entire plug-and-play P2P internet in the form-factor and cost of a small HDD.
Would people want to own such a server? I don't know, but as it stands currently, only the centralised players in the internet sphere can afford to serve content. Perhaps our relationship to these companies would be different if there was no barrier to entry for competition. Perhaps our entire conception of the internet would be different without that fundamental limitation. Or perhaps nothing would change. The central model has its advantages, but I'd also like to be able to own my own website.
> Perhaps on the IPv6 internet, you would be able to buy a USB stick that handles all your emails for you.
You are too optimistic. Poeple can't be bothered to migrate off the google to some alternative provider (also free) and you expect them to buy a "usb stick" for local (mail) server? And then have to keep their machines up all the time and also connected constantly? (not everyone lives in the USA and have FTTH)...
I already mentioned that Opera tried something like "personal pod" 15-20 years ago and it flopped...
> No more centralised mail, you just have a small server in your house that does it for you. The same of social media, etc.
"social media" case seems interesting but again - we had mastodon for distributed social media and it's adoption is lukewarm... and now we have bluesky, which is also distributed and anyone host it and whatnot and it's userbase skyrocketed... and everyone use single instance.
All in all - people don't care about it, they want convenience and nothing else...
> And then have to keep their machines up all the time and also connected constantly?
The idea would be that you plug the stick into a USB port, then it just draws power from the wall and serves files over WiFi. Similar to the Amazon Fire TV stick, it would be a full computer in a small form-factor.
> and everyone use single instance
I wonder if this has anything to do with how difficult it would be to set up your own instance? We already have distributed social media, it's called websites. I think having your own website is pretty appealing to a lot of people. BlueSky is really just a worse version of HTTP with page indexers, which only needs to be that way because of NAT.
> All in all - people don't care about it, they want convenience and nothing else...
I know that people will not bother to migrate off their current software, but the product has its own pros and cons. Perhaps if they were presented with both options when they first obtained an email address, they would have made different choices.
And actually, I think people do care quite a lot. Even something as simple as sending a file to someone is massively complicated by NAT. People don't like the fact that they need to trust their digital lives to a handful of massive American companies. That people lack knowledge of the alternatives is not a sign that there are no better alternatives. See Ford on cars, Jobs on phones, etc.
what? the world doesn't end with fortnite or whatever brain-rot is currently popular (on utterly locked up platform with excessive anti-cheat)... there is a gazzilion of super entertaining games that you can play locally... :shrug:
The main problem I had when I was on CGNAT was not so much port forwarding (annoying, but solvable), but with being banned from all sorts of stuff. The address is shared with so many people and one person did something stupid or malicious or whatnot. Sometimes you don't even know if you're banned or not.
For better or worse, IP blocks are still very common. It's easy to complain about this, but there aren't really any good methods to deal with persistent abuse.
Ah… that makes it sound as if we've reached a phase where IPv6 has no significant problems and saves a little bother compared to IPv4. Switch to v6 ⇒ escape false alarms from tools like fail2ban.
> IPv4 exhaustion is a real problem, it's just not enough to motivate people much.
Well, its only really a problem if you're poor. Rich people don't care - IPs are still cheap enough when you live in a wealthy country & have a decent job.
The people affected by IP address exhaustion are largely the exact set of people who can't do anything about it.
From the article, IPv4 only has 3.03 billion unique, routable addresses. The world population is 8.2 billion. So there's only enough IPv4 addresses for 1 unique address per 3 people on the planet. But of course, in reality, huge swathes of the IP address range are held by big companies (like amazon), universities and the US military.
Its very common for whole streets or neighbourhoods to collectively share a single IPv4 address. Its required, as a result of simple math.
You'll even see this in some parts of the US and UK.
What you're saying is similar to "there's limited amount of SWIFT codes", not enough for each person on earth, so each person cannot have their own bank to receive money transfers.
True, but each person does not need to have their own bank to send or receive money, they can have an account within a bank of their preference, and use that extra information to route money transfers precisely.
"But they can't route money directly" — most people will never need to.
Yeah I hear the argument that CG-NAT is fine for most people. It’s true, but kinda sad. It means most people won’t be able to run home servers, or learn to be the server for a multiplayer video game, or all sorts of other things I took for granted when learning the craft. It kinda locks in, technically, the consumer and producer relationship between computers on the internet. And for no good technical reason - just a quirk of history. CGNAT is usable; but it’s sad.
I agree that it’s diverging from what was envisioned for the internet originally, so the thing doesn’t reach its technical potential.
On the other hand, I find it beautiful that network routing architecture and network security architecture naturally converged on NATs — I think because they are easier to understand for people, and more closely reflect what’s actually happening, without some hidden magic.
The number of people behind CGNAT is huge and rising. It's collectively worth it. And really not that much effort. (If your internal business network is sufficiently entrenched you don't have to change it.)
It is enough for Amazon/Google/FB/Netflix - they start to choke on IPv4 and they also don't want to pay up insane amounts for holding IPv4 ranges. When they switch to IPv6 they have more cheaper addressing. Once they force it down by making faster services via IPv6 all the ISPs will follow right away because everyone will want to have their Netflix/YT streams load faster.
If it was a real problem, market pricing would reflect the increasing severity of that problem.
The truth is that people who care about port forwarding are such a small minority -- especially now that P2P file sharing has lost its hype -- that they don't make a visible dent in the rate of IPv4 exhaustion.
The truth is that major cloud providers such as Amazon AWS have begun to charge [more] for static, routed IPv4 addresses.
Last I checked (a few years ago, I suppose), AWS APIs were incapable of using IPv6 internally, so a VPC still needed to dual-stack it in order to use AWS cloud features. That may have changed by now.
Says you need to have an AWS NAT for that to work. And AFAIK, setting up a NAT requires an ipv4 elastic ip.
And it makes since that AWS would want customers to have their own IP for NAT64, so that if one customer does something to get the ip address blocklisted it doesn't impact other customers.
If they had increased prices in 2022 (or at least announced in 2022), then I could see some kind of correlation, but give it was 1.5-2 years after, I doubt there is a connection.
> i would expect aws needs a year or two from when they decide to charge for something new just to work out the details
The price had already dropped, and was continuing to fall, when they announced the change, so if rising acquisition cost was the primary reason for adding the IPv4 charge, it had already went away.
I think AWS has looked at a utilization graph and sees a time their current pool is get used up at current rates and doesn't want to go through the hassle of acquiring more IPv4 addresses, regardless of cost (even if it is "cheap").
I also think that they have statistic for their www.Amazon.com storefront, and maybe are seeing a good proportion from IPv6 and so figure that there's a 'critical mass' (especially mobile).
In practice the tech giants such as Google, Apple and Microsoft will dictate adoption of technology. When Chrome starts mandating or heavily recommending IPv6, adoption will reach 99% overnight. That's what happened with https: https://www.znetlive.com/blog/google-chrome-68-mandates-http...
The market price is only something like 5 or 10 dollars a month, but anyone having to pay that to be accessible is an embarrassing failure of the system. It doesn't matter whether it's a big dent in the number of IPs or not.
There are billions of people out there who can access the internet, and make themselves accessible through the internet the way they want, just fine without a dedicated IP address.
Maybe you have a definition of "access" that is different from the usual one. That's fine, but let's be honest, it's not the usual definition.
But is it "well off people not having a problem paying a buck or two directly or indirectly to an american corporation to be able to bounce traffic" which you refer to as "most people"? I can see how a few billion other people would have problems with that concept for many reasons apart from the obvious financial one.
And for everyone that does pay this "internet tax", it only strengthens the position of said corporations to be able to buy up even more of the available routable ips. It's not hard to see that the end result is very much not in the consumers favor, regardless of how unnecessary it feels for customers currently to have a real ip when all they want is kitten animations on social media.
This isn't necessarily true. The scarcity of IPv4 addresses could very well induce a lack of demand and decrease the price. You wouldn't dream of developing a technology that requires people to have an individual IP address, so you don't. This massively reduces the demand for v4 addresses. It's not as if there are users out there who will demand the features you can't implement, and it's not as if you could fund the entire IPv6 network by yourself to bring about those features. Then ISPs have no reason to support v6 because no customers demand it. Instead of increased price, the cost is paid through decreased service. Think of a congested road network. It could be well worth it to build some more roads and ease congestion, but if there is no one in the system willing to pay for it, everyone will suffer.
The network experience on Nintendo devices always seemed janky and home-grown. I feel like they built everything from scratch at corp HQ complete with wonky edge cases.
The reason that IPv6 is so lightly used is that it’s cheaper to use IPv4 + workarounds.
I’m not saying this is a good thing or a bad thing, or making any value judgment about IPv4 vs IPv6.
People and businesses don’t spend money on technology upgrades where the benefit is not measurably better than what they already have.
This is just common sense; no one wants to throw away money.
If you want people to use IPv6, then IPv4 has to fail first. As long as people keep making it work then the benefits of changing will never outweigh the costs.
BTW this is exactly the same situation as clean energy vs fossil fuel, etc. In that situation governments are actively putting their thumb on the economic scales in all sorts of ways. Again, I’m not offering a value judgment, just an observation.
Most people don’t need a public IPv4 address and can live with CGNAT.
For the relatively small number of people who do need public addresses, renting them from a cloud provider or buying blocks at auction are still economically viable, in comparison to the capital costs of upgrading everything that needs upgrading to support IPv6-only.
Have you tried using PCP to forward the port? I was under the (maybe-incorrect, and if so I would really like to learn) impression that most major CG-NAT setups supported it.
Yep, my point was just that STUN works far more frequently than explicit port forwarding protocols. Part of the reason (for better or worse) is that most major console networks (Xbox live, PSN, etc) will grade your connection poorly if STUN doesn’t work. Customers who otherwise don’t know about networking do complain to ISPs about this sort of thing.
I had to reluctantly deploy ipv6 on my home network because of ISP requirements + will to use pihole.
Ipv6 is hard. I had to learn quite a bit to make it work and not only I see no value, but it is significantly more difficult to use dire to the address length.
I think IPv6 is a missed opportunity, it was probably designed by experts that did not take into account the population that will use it (not the one users who do not care, but the layer above them)
I struggled to get IPv6 running on my home network, then had issues with DNS dual stack once I got it going, so I turned it off.
That said, I think the difficulty of IPv6 is in the UI of the home routers that implement it, and a lack of sane defaults.
The ISP should give every SOHO/residential customer a /60. The router of a simple IPv6 should do prefix delegation. The router should default to SLAAC for local IP addresses, and configuring DNS with Router Advertisements. And residential routers can be set up to have an internal DNS server which populates the ".internal" domain with hostnames from the network.
As a network admin, you have to learn new things like the uses of IPv6 multicast, and ND, the lack of ARP, and some other things. Home users shouldn't have to care about that.
Sorry, but under no circumstances should an ISP router auto route internal computers from the network. Thats just going to expose so many internal services, most consumers wouldn't even know they were running in the first place.
If we are to have a transition to IPv6, and I am very much in favour of this, then by all means make the addresses be globally routable, but force people to select the ports and addresses to be shared in their router. Otherwise we end up with another mess ala "open wifi".
It doesn't need to, IPv6 has unique local addresses which is are non-globally reachable; I recall those had it's own can of worms depending on deployment but it's an option for private, local addresses.
EDIT: I also understood the GP comment to be getting around the problem of long IPv6 addresses and not actually making every machine globally accessible.
>The ISP should give every SOHO/residential customer a /60.
The ISP should give every residence 295 quintillion IPv6 addresses? I know there is an abundance of ipv6 addresses but that seems like a lot of waste.
Even assigning a /96 would provide 4.3 billion ipv6 addresses (which is the same number as all ipv4 addresses in existence)
And since available ipv6 space is basically 4.3 Billion^2, assigning an ipv6 /96 would be like assigning a /32 in ipv4 terms of total ipv6 space utilization.
Like other person said, /64 is the minimum subnet size. And submitting in ipv6 is best done 4 bits at a time. A /60 is overkill for residents, but because it gives 16 subnets, not because it gives excessive addresses.
/64 acts as a soft limit due to the prevalence of SLAAC. Which is good in a way, since it means ISPs have to give out at least /64, which means you're always able to subnet (although you can't use SLAAC and must use static addresses or DHCP) unlike IPv4 where you have to pay for extra addresses.
You can DoS your whole subnet by pretending to be a billion devices. In IPv4 you can do it by occupying all the IP addresses. Therefore putting several customers on one network is a bad idea, just like in IPv4.
The purpose of SLAAC is to make it "easy" for a client to get onto the network without something like a DHCP server tracking addresses. If you set it up, it generally just works.
This doesn't seem like an IPv6-specific issue. For most broadband customers, your external IPv4 address is also generally stable. Mine hasn't changed in years.
That's not how you're supposed to use IPv6. It would just be 64 bits if that was the case. Instead, 99% of the time, it's a 64 bit subnet ID and a 64 bit device ID.
My ISP is the French "Free". They provide a router that is difficult to swap with my own (it is possible, but it is way easier to switch it to a bypass mode). With this router comes a TV box that requires IPv6 to work.
When I replace DHCP/DNS with Pihole I need to account for that. While this is not a complex setup once you understand IPv6 you still need to learn it.
I work in IT so I tried to get myself to IPv6 several times but never had any reason to do so (despite self-hosting a lot and generally being a nerd). I had to do that this time and my uninformed opinion is that it could have been done so that it is much simpler for advanced users (but not yet networking experts)
So you had to learn IPv6 the same way you learned IPv4. The question is: was it harder ?
It seems you wanted to know IPv6 without learning it because you thought it would be the same as IPv4.
And yes the Free boxes are hard to work with if you don't want to mess with vlan and still have TV services.
I think the main difference is that when I learned IPv4, pure-v4 was sufficient. Today, you can't run a pure-v6 network; you have to deal with both. The closest you can get is NAT64, which 1. doesn't always work, and 2. is still annoying to manage. (Which sucks, because doing just v6 would be nice)
I think this misses the point. An IPv4-only home network has a lot of benefits, simplifying whatever you to in it which relies on IP addresses which you'll have to handle manually in code and databases.
His scenario is really a PITA, where he's basically forced to migrate to IPv6 only because of IPTV. There might have been a solution by creating an IPv6-only VLAN just for the TV, while keeping the rest at legacy, but it's not really trivial.
IPTV with Deutsche Telekom is also a pain, because they feed it in a separate VLAN and the routers and switches need to handle IGMP messages properly (IGMP proxy, IGMP snooping).
The biggest design failure of IPv6 is that it was not designed to be backwards-compatible with IPv4. Technologies with established user bases need to evolve with backwards compatibility if they want to take advantage of existing network effects.
I also appreciated how much the linked article is adamant that IPv6 is what you get when all you do is increase the addressing size. There were wilder alternatives discussed that broke more things or took a more progressive stance. Part of the "there's no compelling 'use case' for IPv6" is that it really doesn't do anything new or exciting, it just increased the address size, and then dealt with the consequences (including "lack of backward compatibility", that was always going to be a consequence of increasing the address size).
It could work like 4 socks requests wrapped in each other like onion. But LAN services wouldn't need to care about long addressing as they don't need to cross network boundary, while letting everything else use new approach, so you could use old stuff without changing anything and there would be no need for new ip6 drivers with new vulnerabilities that are yet to be fixed.
There have been tunneling protocols and systems for IPv6 since nearly the beginning of IPv6. The ability to tunnel it hasn't solved all the "backwards compatibility" complaints for IPv6.
Same for network address translation, both NAT46 and NAT64 standards have existed for a while now and that also hasn't solved the "backwards compatibility" complaints for IPv6.
Presumably NAT46 still requires most things like middle boxes to upgrade to ipv6, and also somehow needs to squeeze ipv6 addresses into ipv4 addresses, which is only a temporary solution at best.
If addressing is two layer, e.g. NAT is 1.1.1.1 and everything behind it is in 10.0.0.0/8 network (cloudflare could use this scheme while having only one top level address), then you can use existing socks support without any new hardware or software.
My understanding is NAT46 is very nearly the same as NAT44 ("traditional NAT" between IPv4 and IPv4), using tricks like (but sometimes different from) SOCKS and UPnP and fake port numbers to accept incoming connections for one (or more) IPv4 addresses to pretend to be/delegate to some number of IPv6 consumers behind it. It doesn't solve general routing of any IPv6 address, just specific addresses routing via an IPv4 proxy.
To my understanding, the difference between NAT44 and NAT46 is really hard to spot in practice and somewhat "just" a distinction of whether or not the NAT in question thinks of its IPv6 subnet or IPv4 subnet as "primary". I've heard some major consumer-side routers quietly upgraded to NAT46 as "primary" because it does lend itself to better consumer experiences. Also I've heard some CGNAT (Carrier Grade NAT) is easier to build when considered as NAT46 than NAT44 (as awful as CGNAT is as a general thing).
NAT46 is absolutely a standard designed to be a temporary solution. It's just about the exact same ugly temporary solution as NAT44. (Or at least as NAT44 was supposed to be. The continued confusion of NAT44 as a security measure will probably keep NAT44 still in use long after its problem disappears and its temporary transition window has expired.)
(NAT64 is the interesting one that may not be as temporary as networks move to IPv6-only single stacks. Some cell carriers have already moved in that direction.)
NAT44 translates only client addresses, leaving server addresses intact, NAT46 has to translate both client and server addresses, which can be taxing if there are more servers than clients behind NAT, which is further exacerbated by server farms as each domain now has several addresses. Well, if clients connect only to facebook and google, that's only two addresses to translate.
I don't think you can use port numbers to disambiguate between servers as clients will connect to port 443 for https.
It would help everything else, applications are not the only part of the network (and many already support socks), there are middle boxes, DHCP, NAT, firewalls, reverse proxies, LAN services and what not that don't need to be aware of new addressing scheme. Firewalls might benefit from it, but even they would still mostly work, even if with less than perfect precision. And even applications can benefit from simplification due to absence of dual mode sockets and no need for two sockets to listen on 0.0.0.0 and [::].
Many already support SOCKS, but not this 4-layer thing you're suggesting. How can a device, application, whatever that doesn't have support for this use it to handle longer addresses? How can it communicate with a remote node that doesn't have support? How can that remote node communicate back?
If you just want to transport v6 over an existing v4 network there are already approaches to do that in v6.
My network is not particularly complicated. It is the ISP router that manages the biber connection (FTTH). So I have to have that specific ISP provided box, which offers me some more or less crappy features (DNS, DHCP, ...).
If I want to use Pihole for DHCP (because it handles internal registration well) and DNS (because if offers filtering) I need to disable DHCP on the ISP router. But since the TV is handled through IPv6 I need to understand it to make sure that that stack is correctly implemented.
Then I have two mesh networks (tailscale and Wireguard as a backup because I manage family networks that are not available from internet) and a docker stack which has its own surprises.
I would love to put a linux box as the egress router and handle everything there (the fiber, DNS, DHCP, etc.) but it is not possible with the provider because the SFP is proprietary (sort of)).
I am really happy to have a relatively stable 1 Gbps fiber connection so I am not complaining - but doing things exactly as I would wish is not always possible.
CGNAT would cripple every customer I've ever had, going back to the beginning of broadband. Everyone one has had something on-premises that needs to be accessible. Nearly always, it's multiple things that are critical to operations.
However. if someone wants to forever keep 100% of their accessible data in someone else's silos...
and be forced to pay 3rd parties to access anything located on their own premises (ex:cameras)
then imprisonment behind CGNAT might feel 'good enough' to them.
> Private networks, NAT, Carrier Grade NAT are good enough, and internet really doesn't care about being completely peer-to-peer.
CG-NAT adds a cost that not everyone can easily afford:
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
> First off I despise both Apple and that other evil empire (house of mouse) I want nothing to do with either of them. Now with that said I am one of four individuals that suggested and lobbied 15 other tribal nations to offer a new AppleTV device in exchange for active ROKU devices. Other nations are facing the same dilemma. Spend an exorbitant amount of money to support a small amount of antiquated devices or replace the problem devices at fraction of the cost.
Fun reasons why my home network is still on IPv4: IPv6 drains my girlfriend's phone battery :-)
Something to do with Router Advertisement intervals being too short, though I don't get why that only affects her ~5yo android phone. And IPv6 is so complex, I haven't figured out if the RA interval is something I can or should tweak, whether that comes from the PiHole or whether I'd have to flash OpenWRT on my router, or whether my ISP ultimately controls that upstream. Like, I can't figure out as easily where the boundary between me and "the internet" ends with things like the /64 prefixes and SLAAC and RDNSS and all the other acronyms.
Yeah, yeah, I should RTFM, and eventually I might figure out what makes a "good" home IPv6 network. But I can't be arsed to do that in my free time yet, and neither can most software companies cough cough Google/Android and that one guy causing IPv6 drama in the android team
Like.... Ehhh... I'll come back to it in a few more years. "Are we IPv6 yet?"
I have an Android on my IPv6 network with no issues, and this is across several different router vendors with different defaults for RAs. Maybe it's not an IPv6 issue and you're barking up the wrong tree?
Probably definitely barking up the wrong tree, yes. I happened upon a forum post somewhere about Sony Xperia XA2 battery drain on networks where router advertisment intervals were every 10 seconds or something.
Who knows, maybe I dreamed it.
Nonetheless, I disabled IPv6 again and that, somehow, was the smoking gun that solved the "my phone always runs out of charge overnight when I stay connected to your wi-fi" problem.
Most? I have not seen a _single_ hotel that supported IPv6. Not one. And I always check, just for fun.
I've been to one hotel (in Menlo Park) that used to give out public IPv4 addresses automatically, and several hotels (The Venetian, Bellagio) where you could request a public IPv4 as needed.
BTW, I'm also looking for a SIP provider that supports IPv6. So far I haven't found any in the US.
How does requesting a public IP address at a hotel even work? I’m sure if I called the front desk at any hotel and I asked about IP addresses they’d have no idea what I was talking about. Do big fancy hotels have a dedicated IT help desk line?
My anecdote with an ipv6-only home network (linux router):
Doing NAT64 runs into MTU issues and the behavior I observed is chrome would resend the request but only after 30s, firefox and other programs entirely failed to resend requests that were rejected due to MTU issues. Once I got the rejection, retrying in firefox or whatever would work though, so it seems like the path MTU was cached somewhere at the OS level. Reducing MTU manually seemed to fix the problem, but isn't that supposed to be automatic? Why didn't the kernel do the resends?
Old iPads, Androids just don't work, I'm not sure why. My iPhone 11 would connect to the network but declare itself disconnected after 24h or so (some lease or dns expiry which it doesn't renew?).
Steam hardcodes an ipv4 address for login... !! I'm not sure what to make of that, and the fact that it was reported around 10 years ago and they still haven't fixed it. Is it even using TLS?
I needed to make docker dev containers use host networking, because otherwise they'd get ipv4 addresses and try to do ipv4 traffic which couldn't be tunneled by default over ipv6.
Other than that it basically worked.
There's fundamentally only two different ways ipv6 can be configured from an ISP: SLAAC with no delegation, so you essentially share a network with other customers, or DHCPv6 delegation. Unlike IPv4 which has a million different offerings: PPPoE, DSLite, MAP-E, DHCP, etc etc and many of those aren't supported by linux.
I signed up with an ISP that claimed to support NAT64 (Biglobe) but they only support it on their SLAAC ipv6 + PPPoE ipv4 setup, not on their DHCPv6 PD + MAP-E setup, so I had to switch back to SLAAC. At this point in time the NAT64 support seems to be have been a lie... But anyways, to control my network DNS settings despite that I made a program to rewrite RA (and various other packets) with my own DNS server information.
Can it be that IPv4 price now leveled off because big players are getting ready to switch to IPv6 any time and not buying up anything that is available?
If GooG/FB/Amazon force IPv6 how long will it take for ISPs to switch? I think in one week where some people cannot reach GooG/FB and any ISP that was dragging his feet has implemented IPv6 by the end of the week.
I expect IPv6 adoption will blow up any time now as past performance is not indication of future changes ;) because there is much more required on the server side than it was ever before. ISP and home use could live with NAT but servers not really even if you can handle bunch of services on a single IP address, there is just limited traffic you can squeeze onto a single server.
TFA is suggesting almost the exact opposite. "Servers" are moving more and more to an architecture where the service is a distributed collection of machines all over the world sharing only a DNS name; multiple servers share the same physical box, relying on TLS SNI to decide which particular content is intended. While NAT itself would be a problem, the reality is that a service no longer needs some unique IP: the same public IP can be shared by Netflix and Max, and the only relevant thing is that the incoming connection specifies which of the two is intended through the DNS name.
SNI took the pressure a notch down. It was introduced 2012 and graph in article was showing peak of price of IP address in 2021 - where everyone was watching Netflix all day or was in video calls. SNI is not solving video streaming problem you just need more physical networking gear to handle streaming and more public IP addresses.
> internet really doesn't care about being completely peer-to-peer
Internet (I mean, the IETF) does care a lot about the end-to-end principle, however. It is true that "misbehaving" NATs break e2e badly. It is also true that IPv6 can also be put behind such NATs.
> I have even implemented an IPv6-Only network. It fully works, including accessing IPv4 only websites like github.com via DNS64 and NAT64 at my router.
What did you use to implement that? I found it surprisingly difficult to find software to do NAT64 on Linux.
Don't forget that Hetzner and other hosts are also charging extra for IPv4 addresses now, while IPv6 is free.
Also, you're speaking from the privileged perspective of a first-world country- many other countries missed the boat on IPv4 addresses and are limited to IPv6, which also probably explains why global uptake continues upwards despite the US stagnating.
I have never gotten github access from my IPv6-only Hetzner-hosted machine. I don't have control over their router(s) and I am not an experienced network admin who would know how to set up something that would let me simply fucking "git clone" from that machine. I would end up having to set up something janky. The fact that Github is IPv4-only in 2024 is atrociously bad and hopefully handing over business hand-over-fist to their closed-source and open-source competitors.
I love having access to all my internal machines over IPv6 from anywhere without having to use janky hacks. I'd be able to self-host boutique and portfolio websites for example (at least from IPv6-enabled clients), without having to use (and pay for) an external host just for the sake of access.
The fact that hotels and work LANs don't permit access is a "hotel and work LAN" problem, as well as a chicken-and-egg one. If enough people request it (perhaps work people want some cheap Hetzner hosts for dev environments and traveling devs want access to the same machines), the Sysops That Be will make it happen- They are certainly educated enough in the space to enable it.
You are neglecting the cost savings and the non-Western perspective, as well as the "simple developer, not devops expert" perspective.
No longer needing NATs in many situations, especially CGNATs, ISPs could give all customers static ip addresses, and peer to peer applications wouldn't need to use unreliable workarounds like STUN to traverse NATs
You are correct that - for many common environments - IPv6 lacks a compelling case for deployment. However, that is not universally true: for those organizations closer to the core of the Internet (with corresponding larger traffic and growth rates), the premise that you can carry all the traffic through CGNAT fails (simply review communications on the nanog mailing list from organizations such as Comcast, T-mobile, ATT, Google, MSFT Azure, Amazon, Verizon, etc.) to see clear evidence of such…. IPv6 solves their IPv4 exhaustion problem and has allowed the Internet continue to grow - if you’re not seeing a similar need, then it is simply that you are not at the core of the Internet.
To give ipv6 some credit, there are some very useful things like flow labels. But I agree completely with the rest of your sentiment.
IPv4 is "good enough", but we could do some things to extend its usage further.
First, adopt service location in DNS, and being to retire it at the TCP port-number layer. Then we could run more than one website per ip address, and this would significantly increase resilience against censorship. Rotating ports for censored websites is a significantly easier task than rotating IPs for them since it does not involve routing changes. This could be done with "here and now" technology.
If you're using solely the flow labels to do load balancing, malicious clients can force traffic to come through only one load balancer by setting the same flow label.
You need to add the source IP/port into the mix. But they alone are in practice enough for decent load balancing.
> internet really doesn't care about being completely peer-to-peer.
I think this is mostly the way it is because of all the NAT headaches that come with IPv4.
We regularly see the limitations of Dropbox/Google drive when we just want to share that large birthday video with our friends/family. Imagine them having a secure link to your device that you can revoke any time.
Same with all the home automation / iot devices / cctv cameras that have no excuse not to be local first/need you to install an ad infested app.
I work in media technology, and the amount of equipment in that field (think: room control systems, touch panels, projectors, media players, remote controled power switches) that does only support IPv4 is staggering.
As it might be wise to banish those devices into an isolated net anyways that might not matter too much — but a transition to IPv6-only has many places where hard- and software is the blocking factor.
> Other than this one use case, IPv6 does nothing for me.
IPv6 was not created for you, but it benefits you. NAT is computationally expensive and it does have a real impact for large organizations with thousands and tens of thousands of devices. Such as large universities or you know ISPs.
I have even implemented an IPv6-Only network. It fully works, including accessing IPv4 only websites like github.com via DNS64 and NAT64 at my router.
The only practically useful thing about my IPv6 enabled network is that I can run globally routable services on my lan, without NAT port mapping. Of course, only if the client is also IPv6.
Other than this one use case, IPv6 does nothing for me.
It doesn't work from most hotels, nor from my work lan, nor many other places because most "managed" networks are IPv4 only. It works better at Cafes because they are "unmanaged" and IPv6 is enabled by the most common ISPs, like ATT and Comcast and their provided routers.
Based on this experience, I think IPv6 is less valuable than us HN audience thinks it is. Private networks, NAT, Carrier Grade NAT are good enough, and internet really doesn't care about being completely peer-to-peer.
I think the adoption rate reflects this--it's a linear growth curve over the last 25 years. It should have been exponential.
I think cost of IPv4 reflects this--it is now below the peak, and has leveled off.
As surprising as it seems, IPv4 exhaustion has not been a serious problem. Internet marches on. IPv6 is still a solution looking for a problem, and IPv4 exhaustion wasn't one of them.