And with many ISPs worldwide (including mine) still not supporting IPv6 at all, this becomes a problem, not giving incentive to anyone to do the work to support IPv6 (or at least abandon IPv4) as it will only harm them by being inaccessible.
The problem being that dualstack is worse in every way than IPv4, and worse in every way than IPv6.
The very fact that IPv6 adoption actually requires dual-stack IPv4+IPv6 adoption first is the very reason that adoption took such a hugely long time. If IPv6 could have been made backwards compatible somehow (it's probably mathematically impossible) then adoption would have been much faster (just look at HTTP -> HTTP2 -> HTTP3 already).
From a backwards compatibility perspective, HTTP2->HTTP3 is really very similar to IPv4->IPv6. HTTP3 isn't really backwards compatible with HTTP2. The client just establishes a lower version connection and then the server (which must implement both versions) adds a header to the response telling the client they can establish a HTTP3 connection if they want to. In IP land you get to skip the lower version initial connection because you've already figured it out from DNS, but other than that pretty much the same deal. In both cases both clients and servers that use a new version are dual-stacked because there are plenty of both clients and servers that only support the lower version.
Thinking about it more, the salient difference is that HTTP->HTTP2->HTTP3 is not a network-level problem to a similar extent (apart from clients and servers, you do have proxies and CDNs that need to support both, but these are far fewer actors, and it's much easier to switch CDN to one that supports HTTPx than it is to switch ISP as a server operator), that is the reason why adoption was much faster.
How exactly would have that solved anything? It would have exactly the same transition issues IPv6 has, since the main issue is that IPv4-only hosts cannot communicate with IPv6-only hosts. And there is no way around that - for any alternative proposal.
By making the transition from ipv4 to ipv5 as painless as possible and more like the switch from 32 bit to 64 bit addressing in CPU architectures. At some point everything is 32 byte safe by default and then it’s just working.
IPv4 to IPv6 is nowhere as simple, IPv6 brings tons of new baggage along with it.
It doesn't really solve the main issue here in that IPv4-only hosts (which are not aware of IPv6-anything, have no 6to4, AutoIPv6, anything) cannot talk to IPv6 hosts.
For the inverse direction there is the DNS64+NAT64 combo which works fairly well.
I don't really see the issue to worry about IPv4-only hosts that are not IPv6-aware. Virtually all TCP/IP stacks connected to the Internet have IPv6-capabilities.
> There shouldn't really be any rush to move servers into IPv6, it's end users' ISPs that should.
The problem is people who run servers typically pay for their IPs, while people who run clients typically don't. So, as an end-user, I don't care if I have an IPv4 or an IPv6. As someone running a server, I might.
As an ISP, I of course care if I need to acquire more IPv4's to cover all my clients. But, if all the world's servers are IPv4, I still need to provide IPv4 IPs to my clients, even if I run dual stack, so IPv6 is at best an extra cost, it doesn't save me any money.
> IPv6 clients can be backward compatible, servers aren't.
Not sure what you mean. How would an IPv4-only server send a reply packet to an IPv6-only client? There is CGNAT of course, but there we're again in dual-stack territory.
> But, if all the world's servers are IPv4, I still need to provide IPv4 IPs to my clients
That's the incorrect part. You don't need it. You can translate 6 to 4, it's not exactly CGNAT but it appears exactly the same for the IPv4 servers. That will save you from getting an address to any of your users, only the translation servers need it.
Can you provide any docs or technology name? I still don't understand how the routing devices can tell which IPv6 to route the reply to if they receive two reply packets from the same server to the same IPv4 address. With CGNAT they would assign a TCP/UDP source port in the outgoing request, and use that to route based on destination port in the incoming reply, with all the disadvantages that brings.
Can it be done without stateful connection tracking?
6to4 doesn't allow an IPv6 host to send a packet to an IPv4 address. It only allows IPv6 packets addressed to IPv6 hosts to be routed by IPv4 routers. An IPv4-only TCP/UDP server receiving such a packet would not know what to do with it, as the payload of the IPv4 packet is an IPv6 packet, not a TCP/UDP packet.
On the other hand, 6to4 is stateless, so it has that going for it.
Well, you still need firewall traversal, so you still can't do peer-to-peer connections, something still needs to allow you to punch a hole in the firewall.
The only advantage that IPv6 with public IPs behind a firewall has compared to NAT is that each host can use the same port behind the firewall, you don't need a unique port for each host. I don't see this as a major advantage for an end-user (though it is helpful for large internal networks).
Firewall traversal for mediated PtP through basic stateful firewalls is simple - both sides start sending UDP packets to each other and outgoing packets open hole in firewall for incoming packets.
The same approach does not work reliably with NAT, mainly because you do not know translated port numbers. It also may fail if both sides are behind the same NAT, as NAT pinning is sometimes not implemented.
Even if they go with dualstack, they do DS-Lite instead (public IPv6, CGNAT-ed IPv4). For customers that have already public IPv4, that's negative incentive to even consider switching to it, thus the IPv6 ranks are not growing, even if they could.
Yep, I have zero ISPs in my country supporting IPv6 AFAIK. Data centers support it, but nothing for home connections.
Major ISP performed some IPv6 tests. In 2012. No news since then.
Funny thing is that despite all IPv4 "shortage" I have white IPv4 right now and can accept connections. Also it's almost static, unless I'd turn off my modem for a prolonged period of time, it won't change. So no real shortage, it seems.
Same here. CGNAT for years. I was into running home servers at some point, where I called my ISP and they kindly put me into a different pool where the IP is NOT static but a real IP (non-CGNAT).
Actually now looking back, unless I need to host something at home (which is a hobby than a need) I find CGNAT to be actually safer while still using IP addresses efficiently.
If I remember correctly, one reason for the quick adaption of SSL certificates was the combination of Let's Encrypt and Google saying it would improve ranking. Why doesn't Google just do the same for IPv6? With all the benefits of IPv6, wouldn't Google benefit from such a move as well?
I was about to say. Cause they can't figure out IPV6 either. Their K8 and VPC networking is still not IPv6 complaint last I checked. If you're bored you can get this [extention](https://chrome.google.com/webstore/detail/ipvfoo/ecanpcehffn...) and see just how much of the internet is actually IPv6
Vint was a trophy for the Google founders; they could, so they did. Zuckerberg no doubt got a similar thrill out of having purchased Carmack's employment.
I don't think GP comment belittles Vint. It belittles Google, for just hiring him for his name and not for his expertise. Vint is very vocal about IPv6 adaptation, yet it sounds like his opinion seems to be treated as if he was some kind of intern there. "Cool Vint, you do your stuff, publish your papers and we do our stuff".
Lorenzo Colitti is Google's IPv6 czar but when supporting IPv6 costs (hundreds of) millions of dollars, "input" is not enough. There needs to be a business case which there really isn't so far.
GCP supports enough IPv6 that you can host sites on it with an external IPv6 address. The user's internal network addresses might be IPv4, but that's (hopefully?) a detail not exposed to the public internet.
As evidence, my personal website https://john-millikin.com runs on a GCP e2-micro and is reachable from IPv6-only clients.
I think the issue is that the problem space is unequal.
TLS solved a problem that affected everyone, that end users didn’t understand. The ranking incentive made sense.
IPv6 honestly doesn’t really solve a problem for anyone. The people who can’t deal with CGNAT or have other problems are a tiny minority, and they have solutions to those problems.
The other benefits of IPv6 create more headaches than they solve. Why would you roll the dice and take outages to eliminate IPv4?
Do you have additional data on this? Carrier grade nat equipment or hardware that supports tunneling ipv4 over ipv6 seems like it would be a very small percentage of a consumer network buildout cost.
IMHO we aren't seeing these developing countries as early adopters of mass IPv6 or having local-only services move to IPv6-only due to lack of IPv4 addresses.
Like, I fully understand that they would be feeling much more pressure to migrate, but I don't see that this pressure working; and if even they aren't pushed to IPv6 then why would the western world do so?
Well, that's the way to solve this chicken-and-egg problem - the people who need IPv6 the most will switch to it, perhaps by a mandate from the top, and then it will make practical sense for others to switch as well to ensure interoperability.
> The people who can’t deal with CGNAT or have other problems are a tiny minority
If you ever made a call online your latency has been impacted because we can't reliably establish connections between end users and have to proxy the calls through the (hopefully close) DC. The services are also more expensive for you, because they have to account for that traffic.
This impacts you whether you are behind a NAT or not.
If you are behind CGNAT, you're going to get more captchas and likely get occasionally ratelimited, because someone is bound to misbehave, or the aggregate of that traffic from a small IP range will look like an attack at some point.
CGNAT is a menace to any low latency connection since now your route needs to jump through some NATed hops that may be under varying amounts of load depending on how large the translation tables are. Things get worse if connectivity has to be established by some middlebox as you have no idea how many hops it takes to go to the middlebox and you have no guarantee how loaded this box is. Using a public TURN server can be terrible for VoIP call latency.
Some online games try avoid p2p because it can expose the players to other gamer in the session, who can then try DoS their IP as a competitive advantage.
Places that require calls to be recorded securely will need non p2p still.
And privacy conscious users are screwed either approach (p2p/centralised) if they want to hide their IP.
Not being natted doesn't mean you have to talk to others directly - just that you can. And yeah, once you have people who want to cheat in some ways, you'll need the centralised oversight / validation for the service either way.
It somewhat benefits large incumbent cloud providers that the costs of IPv4 blocks are non-trivial, it acts as a moat.
I'm not accusing them of having this as their reasoning or objective, but it's only new entrants or those without big war chests who are hurt by IPv4 scarcity.
If I were Google or AWS I would actively discourage industrial IPv6 adoption as a strategy.
It's because there are still significant issues in the average user's stack. If I enable IPv6, my ISP puts me behind a single address still and requires NAT that my router won't do.
If you already have a Linux router consider setting up NAT64. With it your entire internal network can be single stacked and when it comes to IPv4 only content you'll just NAT like you normally would.
I’m curious as to why so many major sites are not working. I would expect them to be behind some kind of cloud load balancer which automatically brings IPv6?
There is a ton of logging infrastructure etc. that would all have to be changed to do ipv6. And sadly, the benefit to individual users is little, as every ISP has ipv4 already. So other features get prioritized: https://meta.stackoverflow.com/a/348224
Some major cloud companies also sit on giant piles of ipv4 addresses, like Amazon for example. They of course have negative incentives in ipv6 adoption, as they want their ipv4 investment, which lies in the billions, to pay off as much as possible.
The ISPs on the other hand are heavily incentivized to support ipv6 because the less traffic there is via ipv4, the less load there is on their carrier grade NAT infrastructure. Furthermore, ipv6 allows for cleaner routing tables, at least that's the theory.
Major sites that aren't cloud providers already supported IPv4 so there's not necessarily a clear incentive to spend lots of money upgrading equipment and rolling out IPv6.
Only within the last couple months did AWS announce single stack IPv6 for VPCs (i.e. cloud providers don't have a great IPv6 support story)
The benefits go beyond just curtailing address exhaustion. No NAT necessary. No need for DHCP to assign IP addresses in a LAN. IP scanning becoming infeasible due to 64-bit subnets. No more ARP spoofing with NDP+SEND. Etc etc.
These are benefits of an ipv6 only world - dual stack doesn’t save you much on these (though it may perhaps if you do pure ipv6 internal and nat to ipv4 at the boundary).
My concern with no NAT and every device on my network having a unique, publicly visible IP address it that sites can distinguish between individual devices coming from my network... I like the ability to hide what's on my network behind my router.
Privacy addresses don't hide what's on your network as much as NAT does, which is what the GP wants.
For example with privacy addreses, monitors outside the network can easily see you have 5 devices on at the same time, 4 of which connect to port 443, 3 of which connects to updates.microsoft.com or whatever (just an example).
With NAT, monitors outside the network can see the connections, but cannot see (from IP/port information alone) that there are 5 distinct devices and what they individually connect to.
But what advantage is there for HN or Stack Exchange going IPv6 other than general goodwill? It increases logging costs and has additional requirements and they can’t sunset ipv4 anyway so they’ll have to maintain both.
Perhaps if ipv6 had faster ipv6 transit-only networks there would be some desire on the server side, but transit is transit.
Better performance for users from those networks? I can see that it wouldn't matter for most cases, but for latency-sensitive services like VoIP or gaming, those users are going to notice that your site is faster than your competitors even if they don't know why.
In most cases where I've been able to hit a dual-stack server from a dual-stack client, the IPv6 has been at best the same speed as IPv4, and often slower for unknown reasons somewhere in the pipeline.
It's noticeably better for me (on an NTT reseller) and most people in Japan, although I understand that's because the ISP is deliberately underprovisioning their IPv4 connections to create that incentive.
Anyone use NAT64 and totd (trick or treat daemon) in 2022? I tried this last in 2007-ish and found some fun places where this broke (eg: Google web results would sometimes return an IPv4 address in an URL) but a lot things mostly just worked.
This site: https://whynoipv6.com/country/us -- provides a "wall of shame" summary of sites that do not yet fully support IPv6, in order of Alexa rank. It is definitely surprising, even shameful, that so many top sites make this list.
That Twitter and Amazon don't have full IPv6 support yet blows my mind.
It's also worth noting that IPv6 networks definitely DO exist in the real world.
My tiny startup provides software to run sports teams (mostly swim teams) and we've run into several cases where new wifi gets installed at a neighborhood pool, and the network is IPv6 only. So far, the pattern seems to be cases where AT&T is the ISP in the Houston area. To troubleshoot these issues via phone support, we ask if the customer can reach amazon.com or twitter.com. If not, it's a pretty good sign they are on a IPv6 only network.
Apple also requires IPv6 support for backend services for approval of iOS apps in the App Store (although, in practice, this requirement is not consistently checked).
See: https://developer.apple.com/support/ipv6/
[Edit] To clarify, I'm not affiliated with the Why No IPv6? site. I just found it to be a useful resource. The site credits https://crawler.ninja/ as the source of its data.
[Edit 2] Added link to Apple's IPv6-only support policy.
What a strange layout - the sidebar, which cannot be manually collapsed, covers up page content at moderate widths, until the page is quite wide. When the window gets narrow enough, some of what's in the sidebar can't be accessed at all.
Reddit ipv6 was enabled before Christmas but got disabled because of issues with the Android app and square’s okhttp lib I think. Namely that it didn’t support happy eyeballs.
> Apple also requires IPv6 support for backend services for approval of iOS apps in the App Store
It really doesn't. It requires that the iOS apps work on IPv6 networks with DNS64/NAT64/whatever it's called. It meerly suggests that you might want to have server side IPv6, since your iOS apps need to support it anyway.
I run an ipv6-only local network for fun, so I can tell you the name you're looking for is 464XLAT. In this style of setup, IPv4 packets are translated into IPv6, routed over the IPv6-only network, and translated back to IPv4.
NAT64 and DNS64 are not the same thing as 464XLAT.
It's been a number of years since I had to work on this at a previous company, but my recollection is that Android relies 464XLAT to make sure that all android apps will work properly on ipv6-only mobile networks that use carrier grade NAT.
Apple on the other hand demands that your app actually natively works with ipv6. I didn't have access to an ipv6 network when I was working on solving this issue in our networking libraries, so I used this https://www.jool.mx/en/ to set up NAT64 and I used bind9 to do DNS64 in order to create an ipv6 network for testing ipv6 functionality.
No, the iOS requirement is for DNS64/NAT64. The server can be IPv4, the app has to work with an IPv6 address provided by DNS64. If 464XLAT were the deployed, the app could continue to speak IPv4, but it can't. Nothing to poster you replied to said contradicted that, so I'm not sure where you got it from that they speak about 464XLAT?
Maybe I misinterpreted the original poster's comment, my understanding was they were referring to IPv6-only carrier networks.
In the US (unsure about other countries but they may work the same), the IPv6-only carrier networks mostly (all?) use 464XLAT and not DNS64.
My comments are intentionally devoid of talking about what Apple's requirements are because I don't know then and as far as I know the other posters are correct there.
Indeed, IPv6 has existed for 26 years yet here we are in 2022 still having issues using it. Sites/apps are still deployed IPv4 only, consumer equipment is not ready for IPv6, and very few ISPs are even providing customers with native IPv6 addresses.
Mine is, luckily, so I've been able to set my network up, but I'm struggling to see how the world is gonna make this transition in the near future tbh. My guess is we'll be stuck with carrier grade NAT for a long time.
Just because the equipment can do it, doesn't mean it's ready. I was trying to get my home network setup for IPv6, but the DSL modem would reboot if a fragmented packet was sent, so that's not really ready. The replacement modem didn't reboot, but had severe induced latency, so I went in a different direction and still don't have IPv6.
My ISP is dual stack (cox), as is AT&T fiber -- but that is only for residential. Almost all consumer gear is IPv6 compatible, much of Cisco Meraki's still isn't or is limited.
Frankly, given the peering issues and lack of support from major peers it's not going to happen soon...
And the mess that is v6 when things go wrong...
I'm going to say it again. Private v6 and a powerful v6<->v4 NAT if you insist on using v6 only on devices, we're nowhere near the point where people can't afford a single v4 address and if the phone companies can do it at huge scale so can others...
Edit:
"Adding support via cloudflare" ??? doesn't that mitigate pretty much 90% of all of the advantages of v6 in the first place? that's just implementing it for tech-point scoring...
It's not about tech point scoring, it's about quickly solving a problem. Specifically how can my customers on IPv6-only networks reach my service hosted on Heroku (which does not support IPv6)? Cloudflare is a practical and relatively easy solution to that problem.
Enabling ipv6 creates a lot of routing problems and networking issues on my network, so it remains off and NAT with upnp is used instead (and sometimes tunnels which provide ipv6).
ISPs and home routers need to do a better job handling ipv6 traffic as well and end user devices need to fix bugs with implementations.
For a few years now, I've tried enabling IPv6 at home (not exclusively, just dual stack). Every time I do, I inevitably turn it off because something breaks (usually some website that pretends to have an AAAA record but then it times out and has to fall back to IPv4).
Until it's easy for nerds like me, I just don't see it taking off. So far I haven't found a compelling reason to spend the time to get it to work well, and it doesn't work well out of the box, so I see no reason to use IPv6.
That's great, but my lived experience is different from yours. Maybe my setup is broken, maybe my ISPs DNS is broken, maybe my router is misconfigured, maybe something else.
The point is, I don't see a compelling reason to figure it out. Everything works just as well without IPv6, so there is no point in going through the hassle of figuring out why it doesn't work for me.
Fair. I setup it up more for the learning experience than anything else. Yes, it was a bit of trial and error before everything Just Worked. Most of my traffic is IPv6 nowadays and this is mostly with the larger entities like Google. My biggest happiness is the NAT crutch goes away, but too few networks have IPv6 deployed for this to be a boon for me.
Yeah I have a friend at an IX, with a lot of insight into IPv6 and he's constantly "chasing" ipv6 support in his personal life. It's just not worth my time right now.
And someone in this thread said the problem is not at the consumer level but at the enterprise level, BS. There is maybe 1 or 2 ISPs out of a dozen here that do IPv6 at all.
Mostly it's enabled for mobile operators for some reason, maybe they need the IPs more than regular broadband operators.
Mobile operators have a lot more client devices, and many weren't around as ISPs in the time when large allocations were being given out. Most adults have at least one phone, and many children too.
> For a few years now, I've tried enabling IPv6 at home.
Is this same-ISP or through HE Tunnel? If latter, unfortunately Cogent doesn't peer with HE (HE tried to, Cogent rejected) and if your IPv6 is through HE Tunnelbroker or your ISP peers exclusively through HE in IPv6, you'll run into problems.
I had the same experience for many years, running first Asus routers then pfSense.
What finally made IPv6 bearable was switching to OpenWRT. I still have annoying IPv6 issues now and then but they're at least fairly infrequent now.
Of course I don't try to do anything fancy with IPv6 like using it for services, that'll only end in tears as my ISP gives me new prefixes all the time.
But yeah, it's been far from plug-and-play even with OpenWRT, and as someone who has a proper IPv4 address there's very, very little incentive to put in the effort besides the nerd factor.
I bet ipv6 is superseded soon by something else. To have a standard that is still not adopted after decades surely means theres some fundamental difficulty that means it’s actually really hard to migrate to for many or its just too complex.
The sheer fact that so many systems had to be updated for IPv6, and many many have not .. implies that any new system would struggle just as badly to reach adoption.
The only successor to IPv4 that could stand a chance would be something that would require zero hardware replacements at ISPs, carriers, home-routers, and all the other devices that would potentially be impacted.
While it's taken awhile for vendors to do, updating software to be IPv6 capable hasn't really been an issue or a challenge. Even if a few Internet of Shit devices refuse to speak IPv6, the overwhelming majority of stacks do.
The problem has always been with the IPv6 transition plan, which is nonexistent. This is the way it was selected, even when the contenders were offering actual transition plans where IPv4 interoperate with IPng. This has been a fundamental failure of the design and selection committee for IPng/IPv6.
No, it's just like why the US hasn't switched to metric yet. Installed base and little economic advantage. China, India and other upcoming countries will need to switch to ipv6 eventually, but it will take a long time for Europe and the US, and they may never switch completely.
The reason some of the bigger sites don't offer IPv6 is to not have to deal with stupid broken client configurations.
There are so many groups out there that don't care to setup anything, and ignorantly, or not, break their existing IPv6 in weird ways.
We offer IPv6 services, but have to publish an "IPv4 only" version of some of our endpoints to have customers get around their own brokeness.
Also, I feel the biggest obsticle to IPv6 deployment is mostly the Enterprise firewall tech. Many residential users and mobile users have working IPv6 just fine right now. But I have yet to encounter an enterprise firewall setup for IPv6 properly, even if their ISP offered it.
But yet, they are willing to complain left and right about the CG-NAT restrictions (or overburdened) that they run into, with the easiest solution right in front of their face.
Google can do this because it has a clout on ISPs to interconnect to them, and ISPs do have an incentive to not break Google, so Google's job is easier than many others which don't operate an autonomous network. Essentially Google has its own ISP (which to be clear is separate from Google Fiber's), and you don't (unless you're representing a large corporation here). Also the only cost for ISPs to connect to Google is fiber and equipment costs, which incentivises ISPs to peer with Google.
The real problem of deploying IPv6 is that despite record-high prices of IPv4 addresses and the cost of CGNAT (both monentary and performance-wise), it's still cheaper to do IPv4 only rather than dealing with the hassles of running both IPv4 and IPv6. With IPv4, you can just pick a Tier-1 carrier and you're guaranteed to traverse the whole internet, at least those who didn't proactively blocked you. With IPv6, you are exposed to ugly Tier-1 fights like when Hurricane-Electric tried to interconnect to Cogent to no avail (https://www.datacenterknowledge.com/archives/2009/10/22/peer...), even trying to bake a cake à la Microsoft-Mozilla browser cake wars (https://www.youtube.com/watch?v=7CObnXjmDtg), and even today it's still not resolved (https://www.theregister.com/2018/08/28/ipv6_peering_squabble...). Even Google is not spared with this interconnection woes: it's mitigated, sure, but there are still some parts of IPv6 internet that cannot reach Google, it's just those parts don't really use Google's services or have sane IPv4 interconnectivity (and to clarify, this isn't due to state-level blocking, those people just didn't realised that they don't have a path to Google via IPv6).
Speaking as someone who maintains dual-stack production services, you'd be surprised how much extra work is involved for something which (frankly) should be a simple feature to enable.
> The reason some of the bigger sites don't offer IPv6 is to not have to deal with stupid broken client configurations.
That seems like a bunch of FUD. Do you think that the sites that do have ipv6 are spending any significant amount of time "dealing with stupid broken client configurations"? Or indeed that such clients are really common in the wild, considering how much of the internet would be broken for them? Last I checked, about third of alexa top100 is ipv6 enabled; if it works for them then what makes your site so special that you can't enable ipv6?
> That seems like a bunch of FUD. Do you think that the sites that do have ipv6 are spending any significant amount of time "dealing with stupid broken client configurations"?
Ask Google, Cloudflare or Akamai engineers (those who actually deal with IPv6 problems) and they'll probably answer somewhere between "it's harder in practice" to "why can't peering issues go away when they f**king interconnect on IPv4"? It's not that IPv6 is inherently problematic, actually it's a lot better theoretically, but in practice unless you are a large network which has the capability to connect to everywhere in world and sidestep peering issues like Google, Akamai, and Cloudflare, you will encounter problems immediately. This is not theoretical, you haven't seen the likes of OpenStreetMaps who are experiencing peering problems (https://github.com/openstreetmap/operations/issues/559), and not everyone can use US services which exposes them to risks like the CLOUD Act, which allows US law enforcement to access data anywhere as long as it is operated by US companies (most European companies for example).
The real problem of deploying IPv6 is that despite record-high prices of IPv4 addresses and the cost of CGNAT (both monentary and performance-wise), it's still cheaper to do IPv4 only rather than dealing with the hassles of running both IPv4 and IPv6. With IPv4, you can just pick a Tier-1 carrier and you're guaranteed to traverse the whole internet, at least those who didn't proactively blocked you. With IPv6, you are exposed to ugly Tier-1 fights like when Hurricane-Electric tried to interconnect to Cogent to no avail (https://www.datacenterknowledge.com/archives/2009/10/22/peer...), even trying to bake a cake à la Microsoft-Mozilla browser cake wars (https://www.youtube.com/watch?v=7CObnXjmDtg), and even today it's still not resolved (https://www.theregister.com/2018/08/28/ipv6_peering_squabble...). Even Google is not spared with this interconnection woes: it's mitigated, sure, but there are still some parts of IPv6 internet that cannot reach Google, it's just those parts don't really use Google's services or have sane IPv4 interconnectivity (and to clarify, this isn't due to state-level blocking, those people just didn't realised that they don't have a path to Google via IPv6).
Also some internet services (some video streaming protocols for example) also use other services than HTTP and will actually need to adapt to IPv6, but this is a very small issue (because you can fix software easier than pettyness) than the peering issue described above.
> Also, I feel the biggest obsticle to IPv6 deployment is mostly the Enterprise firewall tech. Many residential users and mobile users have working IPv6 just fine right now.
I agree and I feel a little bit ashamed to be part of the problem myself.
Consumers use whatever they tech provides them by default. Which means devices can go from not supporting to supporting something within span of one generation of devices.
On the other hand, enterprise uses whatever their engineers know. And most enterprise engineers learned stuff a long time ago when IPv6 wasn't the thing and in environments where it did not make sense to deploy IPv6.
I never needed to learn IPv6 because incentives were always against doing so.
This is exactly the kind of things for which the government is necessary. We won't have IPv6 unless it is legally mandated that any service which is available over IPv4 is also available over IPv6 and that all customers be given IPv6 addresses.
Slap a physical loadbalancer in front of them of your services or whatever, but we either get the government to do it, get the telcos to end IPv4 support or give up.
I always wanted to go full native ipv6. However all the ipv6 enable ISPs I’ve used in multiple countries will give you a /64 address, which cant be subneted without some ugly hacks. Worst part is that there is no reason for that. There are plenty of addresses. I seem to recall reading somewhere that the recommended addresspace for a home user would be /48.
What's sad about so many major services failing to get IPv6 going is that other service providers who are considered lesser have managed it without much issue, and every single person I know who works in tech has IPv6 dual stack networks at their home. IPv6 seems to have more residential service penetration in the US than it does in commercial/provider space. Neither GCP nor AWS correctly support IPv6 dual stack across their entire portfolio, yet has-beens like Rackspace Cloud had it working on OpenStack over a decade ago.
The point I'm making is that getting IPv6 dual stack networks in place where you have existing IPv4 connectivity /really/ isn't that hard. Organizations make it difficult, rather than it being intrinsically difficult, and it's only gotten easier as time has gone on and early adopters have paved the way. Hell I've got dual stack IPv6 set up on my Digital Ocean droplets without any issues and all their services correctly support dual stack configurations... what's the story with Google and Amazon?
155 comments
[ 0.24 ms ] story [ 174 ms ] threadhttps://ipv6.github.com - although it still is not configured, but maybe work in progress?
I wonder though why they did it separately.
The very fact that IPv6 adoption actually requires dual-stack IPv4+IPv6 adoption first is the very reason that adoption took such a hugely long time. If IPv6 could have been made backwards compatible somehow (it's probably mathematically impossible) then adoption would have been much faster (just look at HTTP -> HTTP2 -> HTTP3 already).
Thinking about it more, the salient difference is that HTTP->HTTP2->HTTP3 is not a network-level problem to a similar extent (apart from clients and servers, you do have proxies and CDNs that need to support both, but these are far fewer actors, and it's much easier to switch CDN to one that supports HTTPx than it is to switch ISP as a server operator), that is the reason why adoption was much faster.
There shouldn't really be any rush to move servers into IPv6, it's end users' ISPs that should. Somehow things are happening completely backwards.
I recall that DJB made pretty much this argument in the distance past when he predicted IPv6 would fail.
IPv4 to IPv6 is nowhere as simple, IPv6 brings tons of new baggage along with it.
Switching the communication protocol is a local, remote and all the parts in between problem.
Ultimately tunnelling and anycast is the way to do interoperability.
For the inverse direction there is the DNS64+NAT64 combo which works fairly well.
The problem is people who run servers typically pay for their IPs, while people who run clients typically don't. So, as an end-user, I don't care if I have an IPv4 or an IPv6. As someone running a server, I might.
As an ISP, I of course care if I need to acquire more IPv4's to cover all my clients. But, if all the world's servers are IPv4, I still need to provide IPv4 IPs to my clients, even if I run dual stack, so IPv6 is at best an extra cost, it doesn't save me any money.
> IPv6 clients can be backward compatible, servers aren't.
Not sure what you mean. How would an IPv4-only server send a reply packet to an IPv6-only client? There is CGNAT of course, but there we're again in dual-stack territory.
That's the incorrect part. You don't need it. You can translate 6 to 4, it's not exactly CGNAT but it appears exactly the same for the IPv4 servers. That will save you from getting an address to any of your users, only the translation servers need it.
Can it be done without stateful connection tracking?
https://en.wikipedia.org/wiki/6to4
On the other hand, 6to4 is stateless, so it has that going for it.
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-trans...
The only advantage that IPv6 with public IPs behind a firewall has compared to NAT is that each host can use the same port behind the firewall, you don't need a unique port for each host. I don't see this as a major advantage for an end-user (though it is helpful for large internal networks).
The same approach does not work reliably with NAT, mainly because you do not know translated port numbers. It also may fail if both sides are behind the same NAT, as NAT pinning is sometimes not implemented.
It is not hacky, it is essentially how stateful outgoing-only firewall is supposed to work for UDP.
https://dl.acm.org/doi/pdf/10.17487/RFC1385
Major ISP performed some IPv6 tests. In 2012. No news since then.
Funny thing is that despite all IPv4 "shortage" I have white IPv4 right now and can accept connections. Also it's almost static, unless I'd turn off my modem for a prolonged period of time, it won't change. So no real shortage, it seems.
I'm behind CGNAT. I set up a wireguard tunnel to a VPS to allow inbound connections, but that adds cost, complexity, and latency...
Actually now looking back, unless I need to host something at home (which is a hobby than a need) I find CGNAT to be actually safer while still using IP addresses efficiently.
I'd still want to see real v6 adoption though.
Which is why ISPs are pushing carrier-grade NAT.
As evidence, my personal website https://john-millikin.com runs on a GCP e2-micro and is reachable from IPv6-only clients.
Azure doesn't have a good ICMP implementation even on IPv4.
Plus, if the big guys don't adopt IPv6 first, than Google would only be hurting their search quality if they demote projects using IPv4 only.
TLS solved a problem that affected everyone, that end users didn’t understand. The ranking incentive made sense.
IPv6 honestly doesn’t really solve a problem for anyone. The people who can’t deal with CGNAT or have other problems are a tiny minority, and they have solutions to those problems.
The other benefits of IPv6 create more headaches than they solve. Why would you roll the dice and take outages to eliminate IPv4?
For developing countries where such equipment can be costly and unscalable it does matter.
Like, I fully understand that they would be feeling much more pressure to migrate, but I don't see that this pressure working; and if even they aren't pushed to IPv6 then why would the western world do so?
The allocation of ipv4 addresses are not fair. These developing Countries deserve the right to host and develop their own tech industries.
Already India is mandating the use of ipv6 by the end of the year.
https://timesofindia.indiatimes.com/business/india-business/...
China too
http://www.cac.gov.cn/2021-07/23/c_1628629122784001.htm
The rest of the world should enable ipv6 if they wish to easily capture this growing market.
If you ever made a call online your latency has been impacted because we can't reliably establish connections between end users and have to proxy the calls through the (hopefully close) DC. The services are also more expensive for you, because they have to account for that traffic.
This impacts you whether you are behind a NAT or not.
If you are behind CGNAT, you're going to get more captchas and likely get occasionally ratelimited, because someone is bound to misbehave, or the aggregate of that traffic from a small IP range will look like an attack at some point.
Places that require calls to be recorded securely will need non p2p still.
And privacy conscious users are screwed either approach (p2p/centralised) if they want to hide their IP.
I'm not accusing them of having this as their reasoning or objective, but it's only new entrants or those without big war chests who are hurt by IPv4 scarcity.
If I were Google or AWS I would actively discourage industrial IPv6 adoption as a strategy.
If you already have a Linux router consider setting up NAT64. With it your entire internal network can be single stacked and when it comes to IPv4 only content you'll just NAT like you normally would.
Some major cloud companies also sit on giant piles of ipv4 addresses, like Amazon for example. They of course have negative incentives in ipv6 adoption, as they want their ipv4 investment, which lies in the billions, to pay off as much as possible.
The ISPs on the other hand are heavily incentivized to support ipv6 because the less traffic there is via ipv4, the less load there is on their carrier grade NAT infrastructure. Furthermore, ipv6 allows for cleaner routing tables, at least that's the theory.
Only within the last couple months did AWS announce single stack IPv6 for VPCs (i.e. cloud providers don't have a great IPv6 support story)
If hacker news can’t be bothered why should anyone bother?
The main major wins for ipv6 have been management networks that have gone past the limits of private ipv4 ranges (comcast and mobiles devices).
But what advantages do the servers have to switching?
For example with privacy addreses, monitors outside the network can easily see you have 5 devices on at the same time, 4 of which connect to port 443, 3 of which connects to updates.microsoft.com or whatever (just an example).
With NAT, monitors outside the network can see the connections, but cannot see (from IP/port information alone) that there are 5 distinct devices and what they individually connect to.
There are growing costs with IPv4:
* https://auctions.ipv4.global/prior-sales
Getting ISPs with the times is the "short term" plan
Perhaps if ipv6 had faster ipv6 transit-only networks there would be some desire on the server side, but transit is transit.
It depends very much on which network, though.
Is there a newer/similar approach to try?
I do use something like that everyday.
My setup is:
- Ipv6 only and NAT64/DNS64 for everything. That covers all wifi mobile traffic (Android/Iphone) and 99% of Laptop/Desktop traffic.
- IPv4 statically configured for few laptop with special needs (corporate VPN)
One good side effect of this approach is that it keeps most of the IoT shit (generally compatible IPv4 only) disconnected from the internet.
This site: https://whynoipv6.com/country/us -- provides a "wall of shame" summary of sites that do not yet fully support IPv6, in order of Alexa rank. It is definitely surprising, even shameful, that so many top sites make this list.
That Twitter and Amazon don't have full IPv6 support yet blows my mind.
It's also worth noting that IPv6 networks definitely DO exist in the real world.
My tiny startup provides software to run sports teams (mostly swim teams) and we've run into several cases where new wifi gets installed at a neighborhood pool, and the network is IPv6 only. So far, the pattern seems to be cases where AT&T is the ISP in the Houston area. To troubleshoot these issues via phone support, we ask if the customer can reach amazon.com or twitter.com. If not, it's a pretty good sign they are on a IPv6 only network.
Apple also requires IPv6 support for backend services for approval of iOS apps in the App Store (although, in practice, this requirement is not consistently checked). See: https://developer.apple.com/support/ipv6/
Fortunately, adding IPv6 support to a site is relatively simple using Cloudflare. See: https://www.cloudflare.com/ipv6/
[Edit] To clarify, I'm not affiliated with the Why No IPv6? site. I just found it to be a useful resource. The site credits https://crawler.ninja/ as the source of its data.
[Edit 2] Added link to Apple's IPv6-only support policy.
What a strange layout - the sidebar, which cannot be manually collapsed, covers up page content at moderate widths, until the page is quite wide. When the window gets narrow enough, some of what's in the sidebar can't be accessed at all.
Unfortunately OkHttp is naively priotising IPv6 regardless if the IPv6 connection is good or not.
Geekflare (https://gf.dev/) has several other useful tools, worth checking out.
This page is useful to test the IPv6 compatibility of your current network/browser: https://test-ipv6.com/
It really doesn't. It requires that the iOS apps work on IPv6 networks with DNS64/NAT64/whatever it's called. It meerly suggests that you might want to have server side IPv6, since your iOS apps need to support it anyway.
I run an ipv6-only local network for fun, so I can tell you the name you're looking for is 464XLAT. In this style of setup, IPv4 packets are translated into IPv6, routed over the IPv6-only network, and translated back to IPv4.
It's been a number of years since I had to work on this at a previous company, but my recollection is that Android relies 464XLAT to make sure that all android apps will work properly on ipv6-only mobile networks that use carrier grade NAT.
Apple on the other hand demands that your app actually natively works with ipv6. I didn't have access to an ipv6 network when I was working on solving this issue in our networking libraries, so I used this https://www.jool.mx/en/ to set up NAT64 and I used bind9 to do DNS64 in order to create an ipv6 network for testing ipv6 functionality.
Correct, that's my point. What my parent poster is describing is 464XLAT, not DNS64 and/or NAT64.
In the US (unsure about other countries but they may work the same), the IPv6-only carrier networks mostly (all?) use 464XLAT and not DNS64.
My comments are intentionally devoid of talking about what Apple's requirements are because I don't know then and as far as I know the other posters are correct there.
Mine is, luckily, so I've been able to set my network up, but I'm struggling to see how the world is gonna make this transition in the near future tbh. My guess is we'll be stuck with carrier grade NAT for a long time.
Is that true? I had assumed that all network equipment could do IPv6, but the functionality was not exposed by default.
It is not all consumer.
And the mess that is v6 when things go wrong...
I'm going to say it again. Private v6 and a powerful v6<->v4 NAT if you insist on using v6 only on devices, we're nowhere near the point where people can't afford a single v4 address and if the phone companies can do it at huge scale so can others...
Edit: "Adding support via cloudflare" ??? doesn't that mitigate pretty much 90% of all of the advantages of v6 in the first place? that's just implementing it for tech-point scoring...
ISPs and home routers need to do a better job handling ipv6 traffic as well and end user devices need to fix bugs with implementations.
Until it's easy for nerds like me, I just don't see it taking off. So far I haven't found a compelling reason to spend the time to get it to work well, and it doesn't work well out of the box, so I see no reason to use IPv6.
The point is, I don't see a compelling reason to figure it out. Everything works just as well without IPv6, so there is no point in going through the hassle of figuring out why it doesn't work for me.
And someone in this thread said the problem is not at the consumer level but at the enterprise level, BS. There is maybe 1 or 2 ISPs out of a dozen here that do IPv6 at all.
Mostly it's enabled for mobile operators for some reason, maybe they need the IPs more than regular broadband operators.
Wired connections tend to be one per household.
Is this same-ISP or through HE Tunnel? If latter, unfortunately Cogent doesn't peer with HE (HE tried to, Cogent rejected) and if your IPv6 is through HE Tunnelbroker or your ISP peers exclusively through HE in IPv6, you'll run into problems.
What finally made IPv6 bearable was switching to OpenWRT. I still have annoying IPv6 issues now and then but they're at least fairly infrequent now.
Of course I don't try to do anything fancy with IPv6 like using it for services, that'll only end in tears as my ISP gives me new prefixes all the time.
But yeah, it's been far from plug-and-play even with OpenWRT, and as someone who has a proper IPv4 address there's very, very little incentive to put in the effort besides the nerd factor.
The only successor to IPv4 that could stand a chance would be something that would require zero hardware replacements at ISPs, carriers, home-routers, and all the other devices that would potentially be impacted.
While it's taken awhile for vendors to do, updating software to be IPv6 capable hasn't really been an issue or a challenge. Even if a few Internet of Shit devices refuse to speak IPv6, the overwhelming majority of stacks do.
The problem has always been with the IPv6 transition plan, which is nonexistent. This is the way it was selected, even when the contenders were offering actual transition plans where IPv4 interoperate with IPng. This has been a fundamental failure of the design and selection committee for IPng/IPv6.
There are so many groups out there that don't care to setup anything, and ignorantly, or not, break their existing IPv6 in weird ways.
We offer IPv6 services, but have to publish an "IPv4 only" version of some of our endpoints to have customers get around their own brokeness.
Also, I feel the biggest obsticle to IPv6 deployment is mostly the Enterprise firewall tech. Many residential users and mobile users have working IPv6 just fine right now. But I have yet to encounter an enterprise firewall setup for IPv6 properly, even if their ISP offered it.
But yet, they are willing to complain left and right about the CG-NAT restrictions (or overburdened) that they run into, with the easiest solution right in front of their face.
Google can do this because it has a clout on ISPs to interconnect to them, and ISPs do have an incentive to not break Google, so Google's job is easier than many others which don't operate an autonomous network. Essentially Google has its own ISP (which to be clear is separate from Google Fiber's), and you don't (unless you're representing a large corporation here). Also the only cost for ISPs to connect to Google is fiber and equipment costs, which incentivises ISPs to peer with Google.
The real problem of deploying IPv6 is that despite record-high prices of IPv4 addresses and the cost of CGNAT (both monentary and performance-wise), it's still cheaper to do IPv4 only rather than dealing with the hassles of running both IPv4 and IPv6. With IPv4, you can just pick a Tier-1 carrier and you're guaranteed to traverse the whole internet, at least those who didn't proactively blocked you. With IPv6, you are exposed to ugly Tier-1 fights like when Hurricane-Electric tried to interconnect to Cogent to no avail (https://www.datacenterknowledge.com/archives/2009/10/22/peer...), even trying to bake a cake à la Microsoft-Mozilla browser cake wars (https://www.youtube.com/watch?v=7CObnXjmDtg), and even today it's still not resolved (https://www.theregister.com/2018/08/28/ipv6_peering_squabble...). Even Google is not spared with this interconnection woes: it's mitigated, sure, but there are still some parts of IPv6 internet that cannot reach Google, it's just those parts don't really use Google's services or have sane IPv4 interconnectivity (and to clarify, this isn't due to state-level blocking, those people just didn't realised that they don't have a path to Google via IPv6).
Speaking as someone who maintains dual-stack production services, you'd be surprised how much extra work is involved for something which (frankly) should be a simple feature to enable.
That seems like a bunch of FUD. Do you think that the sites that do have ipv6 are spending any significant amount of time "dealing with stupid broken client configurations"? Or indeed that such clients are really common in the wild, considering how much of the internet would be broken for them? Last I checked, about third of alexa top100 is ipv6 enabled; if it works for them then what makes your site so special that you can't enable ipv6?
Ask Google, Cloudflare or Akamai engineers (those who actually deal with IPv6 problems) and they'll probably answer somewhere between "it's harder in practice" to "why can't peering issues go away when they f**king interconnect on IPv4"? It's not that IPv6 is inherently problematic, actually it's a lot better theoretically, but in practice unless you are a large network which has the capability to connect to everywhere in world and sidestep peering issues like Google, Akamai, and Cloudflare, you will encounter problems immediately. This is not theoretical, you haven't seen the likes of OpenStreetMaps who are experiencing peering problems (https://github.com/openstreetmap/operations/issues/559), and not everyone can use US services which exposes them to risks like the CLOUD Act, which allows US law enforcement to access data anywhere as long as it is operated by US companies (most European companies for example).
The real problem of deploying IPv6 is that despite record-high prices of IPv4 addresses and the cost of CGNAT (both monentary and performance-wise), it's still cheaper to do IPv4 only rather than dealing with the hassles of running both IPv4 and IPv6. With IPv4, you can just pick a Tier-1 carrier and you're guaranteed to traverse the whole internet, at least those who didn't proactively blocked you. With IPv6, you are exposed to ugly Tier-1 fights like when Hurricane-Electric tried to interconnect to Cogent to no avail (https://www.datacenterknowledge.com/archives/2009/10/22/peer...), even trying to bake a cake à la Microsoft-Mozilla browser cake wars (https://www.youtube.com/watch?v=7CObnXjmDtg), and even today it's still not resolved (https://www.theregister.com/2018/08/28/ipv6_peering_squabble...). Even Google is not spared with this interconnection woes: it's mitigated, sure, but there are still some parts of IPv6 internet that cannot reach Google, it's just those parts don't really use Google's services or have sane IPv4 interconnectivity (and to clarify, this isn't due to state-level blocking, those people just didn't realised that they don't have a path to Google via IPv6).
Also some internet services (some video streaming protocols for example) also use other services than HTTP and will actually need to adapt to IPv6, but this is a very small issue (because you can fix software easier than pettyness) than the peering issue described above.
I agree and I feel a little bit ashamed to be part of the problem myself.
Consumers use whatever they tech provides them by default. Which means devices can go from not supporting to supporting something within span of one generation of devices.
On the other hand, enterprise uses whatever their engineers know. And most enterprise engineers learned stuff a long time ago when IPv6 wasn't the thing and in environments where it did not make sense to deploy IPv6.
I never needed to learn IPv6 because incentives were always against doing so.
Slap a physical loadbalancer in front of them of your services or whatever, but we either get the government to do it, get the telcos to end IPv4 support or give up.
net.ipv6.conf.all.disable_ipv6=1
This is IPv6 in a nutshell. The enormous lack of return for enabling IPv6 is still stopping global adoption.
Is it just me, or is anyone else bothered that HN isn’t IP6 yet?
I think this and GitHub being non IP6 were the biggest surprises.
Im interested in making my projects ipv6 only if I can have a long term address allocation which I cant do in ipv4
The point I'm making is that getting IPv6 dual stack networks in place where you have existing IPv4 connectivity /really/ isn't that hard. Organizations make it difficult, rather than it being intrinsically difficult, and it's only gotten easier as time has gone on and early adopters have paved the way. Hell I've got dual stack IPv6 set up on my Digital Ocean droplets without any issues and all their services correctly support dual stack configurations... what's the story with Google and Amazon?
I suspect there will be a future need to proxy between the two networks - great opportunity for entrepreneurs, cybercriminals or governments who pry.
https://web.archive.org/web/20120505075239/http://www.sixxs....