Going IPv6 Only
blog.brixit.nl
blog.brixit.nl
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...
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.
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.
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 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?
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.
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.
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.
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.
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.
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:
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.
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?
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.
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....
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)
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.
This is IPv6 in a nutshell. The enormous lack of return for enabling IPv6 is still stopping global adoption.
Im interested in making my projects ipv6 only if I can have a long term address allocation which I cant do in ipv4
net.ipv6.conf.all.disable_ipv6=1
https://ipv6.github.com - although it still is not configured, but maybe work in progress?
I wonder though why they did it separately.