OK so — I just migrated my personal website to use IPv6 only. It runs on AWS EC2, and my motivation was purely to save on paying the IPv4 fee that AWS is introducing next week. I put it behind Cloudflare which can provide an IPv4 proxy address for site visitors.
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.
The thing is, with my mediocre $5 VPS, all I needed to do was copy four lines of config files (as documented by the VPS provider) and open a port in the firewall on the server itself, just like on IPv4.
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?
Also their sizeable ipv4 stockpile is kind of a moat and competitive advantage; it's pretty much guaranteed that no other cloud provider can reach their scale while ipv4 remains dominant. So they have some interest in delaying ipv6. It is quite perverse considering that ipv6 really should be quite ideal for hyperscale cloud.
> 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.
> Thank you for contacting PACE. We appreciate your patience, as we are experiencing a larger volume of incidents and work-related activity. Please be mindful that we will begin our Maintenance Period starting at 6:00 AM on Tuesday, 01/23/2024, and tentatively plan to conclude by 11:59 PM on Friday, 01/26/2024.
I'll continue to follow up here, but it seems like an actual human has read the message this time.
> 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.
If they wanted people to migrate, they could first put a bit of effort into making their tools suck just a bit less on IPv6. It's not even "second class citizen" status, it's more "bastard stepchild of my least-favorite in-law" right now.
Contabo. They've supported IPv6 for a decade now based on the date on their instructions (https://contabo.com/blog/adding-ipv6-connectivity-to-your-se...). Enabling IPv6 comes down to copying "gateway6: fe80::1" to your netplan file, adding the /64 listed in the control panel, and optionally adding an IPv6 DNS server. After a reboot (or sudo netplan apply) you'll have full IPv6 connectivity.
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).
In my book, 90 minutes of fiddling in a case like this is pretty fast.'
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.
For some AWS services, such as Elastic Beanstalk, there appears to be no way to avoid consuming a public IPv4 address on the EC2 instances, except by introducing a NAT gateway.
(And "NAT gateways are an extremely cost prohibitive device in AWS, costing at least as much per day as medium sized EC2 instances!")
I have to appreciate the Brazilian effort for promoting IPv6. I attended a talk on a university about 5 years ago where members of the Brazilian Internet Steering Committee (CGI.br) talked about IPv6 and why it's the future.
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.
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.
I mean, I used to rent the $5/month VPS, and it worked well. In fact, it had much nicer developer experience than EC2 for many reasons. But my provider (digitalocean) raised the price, and I don't really need a lot of CPU resources to serve mostly static files plus a couple of tiny server processes that get very very low traffic. So I downsized to a tiny EC2 instance.
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.
June 6, 2012 is a better date; that was the "World IPv6 Launch Day".
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.
It's a tp-link Archer, and since it supports Wi-Fi 6 it must have been from 2019 or later.
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 ...
That's a leftover from back when IPv6 was very new (yes these utilities are that old), and the networking utilities (ping, traceroute, etc) understood only IPv4. It's no longer necessary, all relevant networking utilities have since been upgraded to work with both IPv4 and IPv6; you can use just "ping" with a IPv6 address and it should work.
> You can use just "ping" with a IPv6 address and it should work
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.
Interesting. I’ve tried macOS and OpenBSD and they both require using ping6 to ping IPv6 addresses. I wonder if FreeBSD changed this recently or if it was always that way. Regardless, macOS is the elephant in the room here as it’s a lot more popular than any of the (other) BSD’s.
I often use ping to check if a machine is alive or is reachable at large. Then it might be more informative if ping tried all addresses the name resolves to. You wouldn't need to specify the protocol version.
ping6 and ping4 are symlinks to ping on my system, and are equivalent to passing -4 or -6 to force a specific version. The default behavior negotiates either fine.
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 ...
fd::/8 addresses (really fc00::/7) are ULA addresses [0], defined as non-routable local addresses, so it’s expected that you can’t get out to the internet through just that address.
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.)
in december 01995 zero nsps and zero isps supported ipv6. you had to be on the 6bone, which didn't even exist until march 01996. also you probably had to write your own protocol stack because there wasn't an off-the-shelf one for your platform. in december 01995 what you had was a paper spec
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.
And? IPv6 is still under rather heavy development with significant changes still being made. As a user, I wouldn't call it well established because it's shifting too much still.
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.
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!
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.