Amazon is horribly behind on a lot of things (just look how long it took them to get DNSSEC working, and it took them a couple of tries to not break entire domains for people using it!). They're ahead of Azure, but that's about the best you can say about that.
I suppose it makes sense, IPv4 addressing is now an additional method to make money for Amazon, so why make it easy for customers to migrate?
If AT&T and AWS went IPv6 by default, most of the US would convert over quickly.
Comcast and the mobile carriers went ipv6 years ago, that's already something like over half the US endpoints? It hasn't sped adoption (Github STILL isn't ipv6 for git).
Another example, I've been trying to get Georgia Tech to fix their ipv6 linux mirrors for over half a year, they advertise they support ipv6 and publish AAAA records that don't work. http://rsync.gtlib.gatech.edu/ < check it out.
So yeah, even when it's deployed nobody checks to see if it's still working when ipv4 is fine.
It's not the only issue it has continued to have.... https://bugs.gentoo.org/585524
I'll continue to follow up here, but it seems like an actual human has read the message this time.
Any word? Why not look up email for one of the staff here https://www.pace.gatech.edu/staff seems like they unfortunately don't check any of the primary emails for the mirror as we've not heard from them in a year or two.
Again, we get it if they have upstream issues not being able to support ipv6, but drop the AAAA records and stop advertising it if that's the case, that's not a big request.
Well, their default images come with a script that'll allow you to `sudo -H enable_ipv6`, but I removed their customisations so I had to do it manually.
They have raised their prices since I last ordered a server there, it looks like €5,45 is the cheapest server you can get these days (includes VAT of course).
Ideally it'd be 5 minutes (1 minute to locate and click a checkbox, 4 minutes to test all services from a few locations), but this is still fast. It includes zero tech support tickets, for instance.
Actually, why doesn’t Apple mandate the IPv6 transition for iOS?
At roughly the same time, Android added 'clatd' so existing apps would just work in an IPv6-only environment via NAT64.
Apple refused to implement clatd, instead forcing app developers to fix their own code. More work upfront, but now iOS apps should have an easier time transitioning their server-side components to IPv6, compared to Android apps.
It's actually not, and I think you learned that, and why it's not, in this process. Sorry.
IPv4 is 43 years old
But even that was negligible since nobody actually had IPv6 connectivity. Even now I still don't have a home wifi router that supports it, though at least my ISP does since last year.
The real driver of IPv6 was the rise of smartphones.
Hmm, I just went deep into the settings and there's an IPv6 toggle (disabled by default, and requires playing with menus to make it actually work) now. I don't remember seeing that (and I explicitly checked) when we switched the ISP-side last April. But the firmware is dated after that, so I choose to trust my memory.
Actually trying to connect to ipv6 stuff besides the router itself (in fd00::/8, that's good) just gives "Destination unreachable: Beyond scope of source address" though (probably because I only have an fe80 link-local address though?). If I play with the settings some more I get a ::/64 address, but that just gives me a black hole ... wait, is that even a legitimate address? Do I need to fill in the prefix manually or something?
I'll play with this some more in the morning I guess. But I certainly wouldn't expect a normal user to get IPv6 working under these circumstances if I haven't figured it out yet ...
Turn IPv6 with stateless RDNSS on (should be the default on all modern routers)
ping6 google.com
That's it as long as your ISP supports IPv6. No need to figure out a fd00::/8 that you maybe may not have.
I'm testing with `ping ipv6.google.com` as well as the router IPs. Between each change, I disconnect from wifi.
The router itself has a ping tool and can ping ipv6.google.com just fine. So I assume the upstream options are correct.
For the LAN, I have 4 options:
* ND Proxy gives me an fd/8 address. I can ping the router via its fd/8 or fe80 address, google blackholes.
* DHCPv6 gives me an ::/64 address. I can ping the router via its fd/8 or ::/64 addresses, google blackholes
* SLAAC + Stateless DHCP does not give me any address (I still have the default fe80 address). I can ping the router via its fd/8 or ::/64 addresses, google gives Destination unreachable: Beyond scope of source address
* SLAAC + RDNSS does not give me any address (I still have the default fe80 address). I can ping the router via its fd/8 or ::/64 addresses, google gives Destination unreachable: Beyond scope of source address
In all cases, the IPv6 addresses the router says are its DNS servers blackhole. I do have working DNS returning IPv6 address for google though; presumably because the ipv4 DNS server it advertises (which is the router itself) still works.
If I bypass the wifi router, the ISP router gives me both an address in both fd/8 (in the same /64 as the wifi router gets assigned, which makes sense) and in 2607/16, besides the usual fe80. The ISP router is really bad, all it has is an "it's connected" indicator and a bunch of phone numbers and URLs for support.
Still bypassing, pinging `ip6-allnodes` gives me 3 responses, all with fe80::/64 addresses: my computer, an unknown, and the wifi router; I can ping those addresses, as well as the wifi router's fd/8 address.
Maybe I should play with the router's upstream settings ... "Get IPv6 address" has auto, slaac, dhcpv6, non-address ... since I can ping it from outside that has to be right. If I disable "Prefix delegation" the ::/64 box is editable but it complains about literally anything entered. And I don't have anything meaningful to manually enter a DNS address.
Hm, I just noticed that the last bit of the router's address varies between some of its addresses ...
Do you have any smart home devices? Protocols like Thread and HomeKit establish their own randomly-generated ULA prefixes and advertise them through RA’s (router advertisements) and correctly-configured devices in your LAN will observe the RA for that network and generate a local address for it (including your router.) So just seeing a fd/8 address doesn’t mean your actual router gave you it, it just means that something on your network is using a ULA prefix.
Basically, it’s possible the real problem is that you’re not actually seeing an RA from a “real” (routable) IPv6 subnet when behind your router.
> If I bypass the wifi router, the ISP router gives me both an address in both fd/8 (in the same /64 as the wifi router gets assigned, which makes sense) and in 2607/16, besides the usual fe80
When you do this, can you ping out? (`ping6 2607:f8b0:4004:c17::65` or something to rule out DNS issues.)
> Maybe I should play with the router's upstream settings ... "Get IPv6 address" has auto, slaac, dhcpv6, non-address ... since I can ping it from outside that has to be right. If I disable "Prefix delegation" the ::/64 box is editable but it complains about literally anything entered. And I don't have anything meaningful to manually enter a DNS address
What you want here is dhcpv6 and prefix delegation. This will make your router ask the ISP for a real IPv6 network to use, and upon receiving this from your ISP, will send RA’s out to your local network for a “real” (2607/16 or whatever) network. A prefix length of 64 should do it, unless you need multiple subnets inside your router. (People say dhcpv6 is obsolete by SLAAC, but prefix delegation is a different thing… if you want to have your own router obtain a network prefix from an ISP, DHCPv6+PD is the only way to do this.)
Not on BSD-derived operating systems (macOS included). You must use ping6 to ping an IPv6 address (including a hostname that only publishes AAAA records.)
From `man ping6` on macOS Sonoma:
> There have been many discussions on why we separate ping6 and ping(8). Some people argued that it would be more convenient to uniform the ping command for both IPv4 and IPv6.
> The following are an answer to the request:
> From a developer's point of view: since the underling raw sockets API is totally different between IPv4 and IPv6, we would end up having two types of code base. There would actually be less benefit to uniform the two commands into a single command from the developer's standpoint.
> From an operator's point of view: unlike ordinary network applications like remote login tools, we are usually aware of address family when using network management tools. We do not just want to know the reachability to the host, but want to know the reachability to the host via a particular network protocol such as IPv6. Thus, even if we had a unified ping(8) command for both IPv4 and IPv6, we would usually type a -6 or -4 option (or something like those) to specify the particular address family. This essentially means that we have two different commands.
Not true. FreeBSD:
> ping -- send ICMP or ICMPv6 ECHO_REQUEST packets to network hosts
> sudo ping google.com PING google.com(par21s03-in-x0e.1e100.net (2a00:1450:4007:810::200e)) 56 data bytes
2012? Wow, that's pretty bad. We were talking about how ridiculously slow IPv6 rollout was while I was at university, and that was 2002-06.
It's fine. The only breakages I've had are when the ISP's v4 DHCP goes down (v6 websites keep working) or when IPv6 delegation fails somehow and my machines lose v6 (v6 only stuff breaks).
Your mobile phone probably already uses IPv6 (especially if you use VoLTE) and it's fine, too.
As a fun aside, global smartphone sales in 2021 were 1.4Bn units. That alone is enough internet devices to exhaust the entire IPv4 address space every three years. I wonder if anyone was imagining that 43 years ago.
https://www.gartner.com/en/newsroom/press-releases/2022-03-0...
What made me disable it was some issue in Linux network stack, with ipv6 broadcast, on by default, exploitable to root execution.
For me it is yet another complex service that I do not need, and that should not be exposed to network. Ipv4 network stack code is far smaller, simpler and way more tested over decades!
Which setting was that? I've had 0 issues with IPv6 on EC2 for a while now. Not all services support v6, though, but that's a separate issue.
This has more to do with AWS, less with IPv6.
It was very informative, and I also found out they offer free courses about IPv6 networking, with certificates included.
I think CZ.NIC offers something similar, but they should be promoted more often so sysadmins can prepare themselves for the eventual shutdown of public IPv4 addresses.
(And "NAT gateways are an extremely cost prohibitive device in AWS, costing at least as much per day as medium sized EC2 instances!")
I'm sure that many HNers would appreciate the information here, but if you prefer my Gmail username is the same as my HN username. Thank you!
https://www.knowmatic.app/how-to-migrate-aws-ec2-instance-fr...
I didn't find such great docs on the Cloudflare part, but some of these were useful:
https://www.reddit.com/r/selfhosted/comments/14d16lt/if_i_on...
https://community.cloudflare.com/t/the-page-isn-t-redirectin...
https://stackoverflow.com/questions/4616521/nginx-configurat...
https://developers.cloudflare.com/support/troubleshooting/cl...
I would go back to the 5/mo VPS if it became clearly better than the alternative. I don't really need an IPv4 for what I use it for, though, as long as someone else wants to provide an inexpensive (or free tier) proxy service.
But the thing is, even though IPv6 is such well established tech, it was not a great migration experience.
I'm not a network engineer, and you have to figure out how to update a bunch of networking configuration to make this switch on an existing instance, with lots of potential footguns. Even after I got the IPv6 address provisioned and the virtual networking correctly configured, the connectivity was still broken until I found an obscure security group setting that was still set to allow only IPv4 traffic. A lot of basic debugging tools like curl are designed to use IPv4 by default. You have to figure out how to get your webserver (nginx in my case) to listen on the IPv6 interface, which is fiddly. And it's easy to inadvertently break ssh connectivity, which turns out to also be set up to expect IPv4 traffic only...
In the end, it took about 90 minutes of fiddling, including migrating to Cloudflare, fixing DNS, etc. I mean, it's fine. I learned some things.
But if we're all going to switch to an IPv6 world, it would really be nice if the systems and tooling made it slightly easier, somehow.