Enabling IPv6 support for GitHub Pages
github.blog
github.blog
My guess is that ISPs must have needed to choose if to invest to core network or to last mile, and that is visible here. But at the same time it seems bit weird that you'd in 2020s deploy fancy new fiber networks without IPv6.
Well there's no real value connecting to an IPv6 island. The Internet is still IPv4.
I would have thought that all the major tech companies supported it years ago on all their infrastructures, websites and apps. But there are still a lot of hold outs.
What about IPv6 makes it such a chore to become widespread?
But maybe IPv6 is so low level that it has a lot more inertia...
We have run out of IPv4 addresses. Past tense. Go to a RIR for some and you'll be put on a waiting list.
If you want a block of IPv4 space you'll be paying about US$ 30 per IP at the moment.
Users don't care, and until a lot of them do ISPs won't do anything.
People can still video chat, play games and use VPNs without v6.
https://support.xbox.com/en-US/help/hardware-network/connect... https://kb.netgear.com/19844/Why-does-my-Xbox-say-NAT-is-set...
Part of why video chat quality sucks is because the RTP traffic has to be sent through a proxy to deal with NAT, doubling load on the Internet and increasing latency.
Because it does not work.
Want to run a public service with end-to-end connectivity? Go to your RIR to request an IPv4 block and be put on a waiting list.
Or break out your cheque book and be prepared to cough up $35+/IP for the privilege of global connectivity:
* https://auctions.ipv4.global
When I signed up for a new data center internet connection, both my ISPs charged me something like $25/month for a /24.
IPv4 addresses are still relatively cheap to get.
When did the company purchase them? Was it a private sale or through a broker(?)? I'm curious as to the process, especially if it was more recent.
Similarly, IPv6 hardware accelleration was not very common on consumer/prosumer routing hardware, making it very resource-intensive (much more so than IPv4), resulting in low throughput.
... based on personal research in ~2015-2016
Performance was abysmal, 2x-10x slower than IPv4.
Turns out many of the routers out there can perform IPv4 table lookups in the data-plane (fast-path), but IPv6 is delegated to the control-plane (slow-path), for much slower performance.
And quite a quick deployment AFAICT:
> Free deployed the IPv6 infrastructure in only 5 weeks, from 7 November to 11 December 2007, thanks to an innovative 6rd (IPv6 rapid deployment) proposal by Rémi Després.[44]
Pinging www.google.com with IPv6:
$ ping www.google.com
PING www.google.com(sc-in-x67.1e100.net (2404:6800:4003:c02::67)) 56 data bytes
64 bytes from sc-in-f103.1e100.net (2404:6800:4003:c02::67): icmp_seq=1 ttl=108 time=4.46 ms
64 bytes from sc-in-x67.1e100.net (2404:6800:4003:c02::67): icmp_seq=2 ttl=108 time=3.73 ms
64 bytes from sc-in-f103.1e100.net (2404:6800:4003:c02::67): icmp_seq=3 ttl=108 time=3.73 ms
$ ping -4 www.google.com
PING (142.250.186.100) 56(84) bytes of data.
64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=1 ttl=107 time=317 ms
64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=2 ttl=107 time=317 ms
64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=3 ttl=107 time=317 ms
also, the ipv6 space is far less fragmented then ipv4. this could lead to more direct routing aswell.
So the first troubleshooting step when someone complains their home internet is slow is to say "have you enabled IPv6 service?"
Switching from PPPoE to IPv4-over-IPv6 means you get switched to CGNAT so if you want to host anything it's a downgrade, but in reward you get far greater performance.
The only thing I don't like about it, is how they created SLAAC (a way for a client to auto-configure its own IP address without DHCP) - but didn't enable routers to provide DNS information.
Therefore, in any useful deployment, you need to deal with SLAAC for IP allocation, and DHCPv6 for DNS information.
Outside of that, the spec is pretty decent.
----
Also, damn every ISP and every router company that doesn't 100% support IPv6. Shockingly, this includes Ubiquiti, which is "supposed" to be medium-enterprise grade.
ISPs and endpoint network devices are the only reason we don't have IPv6 more prevalent, combined with NAT, CGNAT etc. being good enough to keep the net hobbling along.
It's extra development and extra testing (in fact it's way more testing due to the combinatorial explosion of IPv4/IPv6 interface schemes).
That comes at a cost.
> ISPs and endpoint network devices are the only reason we don't have IPv6 more prevalent, combined with NAT, CGNAT etc. being good enough to keep the net hobbling along.
ISPs & endpoint devices are the majority of the Internet, as far as complexity is concerned. Upgrading the equipment for HW-acceleration of IPv6 (parity with IPv4) is very costly.
there is RDNSS for router advertisments used with slaac. although it wasnt there initially and support for it might be lacking yet.
DNS is critical. I'm not talking about registering an endpoint into a local DNS server (mydesktop.local), I'm talking about the endpoint knowing who to ask about google.com.
Switching back to my ISP's DNS meant getting a more suitable set of Akamai servers and reasonable download speeds again.
That complexity is also part of why the Linux kernel's built-in support for IP autoconfig at boot time for network-based root filesystems (without using a userspace DHCP client) only supports IPv4.
Router advertisements can announce a recursive DNS server (RDNSS) which local clients might like to use, eg:
https://github.com/radvd-project/radvd/blob/master/radvd.con...
Bad luck though if you are using, ahem, AIX or Windows Phone:
https://en.m.wikipedia.org/wiki/Comparison_of_IPv6_support_i...
Until Windows 10 this was correct, but now that Windows also supports RDNSS in Router Advertisements that is no longer the case.
My home network has been running SLAAC without DHCPv6 for years now.
My router is an Edgerouter by the way.
I do recall seeing some of the configuration wizard stuff not having options for IPv6 in the past, but that's just for initial configuration anyway. Once you are done with that you do everything from the config tree anyway.
On the Unifi gear, the IPv6 UI that is there is marked "beta"
Just to be clear, one can configure the IPv6 firewall through the UI. One just has to use the config-tree rather than the easy firewall configuration.
Such as Verizon who still doesn't support it on FIOS
Another thing you can see from Google IPv6 charts that before 2011 IPv6 adoption was near zero. This matches pretty well with IPv4 exhaustion; IANA pool was exhausted in 2011, and APNIC followed later that year. Before that anyone could get IPv4 address pretty liberally, so there was very little reason to think about IPv6. Especially in western world (RIPE/ARIN) where consumption was slower than e.g. APNIC; notably ARIN reached exhaustion only in 2015.
https://www.google.com/intl/en/ipv6/statistics.html
In summary, I feel that having third of internet become ipv6 in about a decade seems pretty decent result, considering how complex and especially diverse internet is.
(Yes yes you nerds were, but most people weren't)
IPv4 had just as slow a roll out in some ways. TCP/IP had its flag day in 1983:
* https://en.wikipedia.org/wiki/Flag_day_(computing)
There was early commercialization of the Internet around ±1990, but it didn't really start taking off until around 1994:
* https://en.wikipedia.org/wiki/Commercialization_of_the_Inter...
The Dot-com bubble peaked in 2000:
* https://en.wikipedia.org/wiki/Dot-com_bubble
RFC 1918 was published in 1996, and the kludge of NAPT was documented in RFC 2663 in 1999.
Given all of the above, I would say it took IPv4 about 15 years to reach the mainstream.
If we compare the http to https migration, Firesheep in 2010 demonstrated that maybe migration was the right thing to do rather than just an optional security feature for banks, Lets Encrypt was released to the public in 2014 and by like... 2019 basically all of the internet was HTTPS. There is a long tail to go for the last few sites, and some that have objections to the CA system and are holding out, but really https is just expected these days, which is a much better place than IPv6.
This is apples and oranges: absolutely zero software upgrades needed to be done to get HTTPS going and/or Let's Encrypt running.
I was able to get LE going on our F5 appliances in a few working days with zero changes to the base system/appliance software by simply installing the dehydrated ACME client and all of a sudden dozens of sites where we previously didn't want to pay for a cert were "secure".
Network hardware can stay in place for quite a while. Our previous generation of core switches lasted us 7 years before we swapped them out.
I wouldn't be surprised some of the mega-chassis routers in ISPs and other telcos sit around as long.
Google's ranking bonus had also been a great incentive.
For a lot of folks when they get to good enough they stop. Understandable.
But the "good enough" of IPv4 has taken a lot of effort in the last few years. How much gnashing of teeth has NAT caused and having to invent TURN and STUN and a bunch of others things?
Anyone remember Skype supernodes?
With IPv6 you "just" have to do firewall hole punching without all the drama of packet tuple munging.
And good luck with double-(CG-)NAT hole punching.
The senior principle project manager in charge put it very simply: "The number of routers that don't support IPv6 that we'd need to replace exceeds the world-wide yearly production of IPv6 routers capable of replacing them. At our current rate of growth, we have less than a year until we run out of IPs." (I'm badly quoting a brilliant person many years after the fact, but that's roughly my memory of the talk she gave.)
Major tech companies often have constraints like that which the rest of us wouldn't even imagine.
But how many of those routers could they make, and how quickly? And for how much? And could they really handle the kind of load that Amazon needed to handle? And how quickly could these bespoke solutions be installed, tested at scale, verified to work? Would the manufacturer provide support if they don't work as expected?
The solution that was done was to split the network into sub-networks with just the few proxy gateways between them that were needed. And it worked- I think it's still working that way. That's not free to do (every service owner had to do some networking work), but it's also perhaps less expensive than switching out all the hardware, overall.
And rest assured, Amazon always chooses the option that maximizes profit in the long run. Other than that stupid phone.
The Cisco 5500 series chassis is about 21 rack units (or about 3 feet) tall to give you an idea of the scale of these devices in the real world. They are also jam packed with custom ASICs that allow packet switching at extremely high speeds, which would need to be redesigned to handle 16 byte addresses.
The underlying issue is that there is a lot of momentum with v4, and hacks mostly work and work faster and easier, so most people end up going that way. So it keeps the momentum.
And v6 has some serious second system syndrome going on (aka we’ll dramatically fix all the stuff we wanted to do better last time, ignoring real world constraints), and the adoption shows. It was clearly designed to be a either or replacement (aka cleanroom, start fresh with this), but that’s not how real world upgrades tend to work. I keep wanting to use v6, but every time I do, it quickly ends up having to get turned off because of something broken somewhere in some product I have little choice in using or interacting with and v4 (even with tons of terrible NAT) still keeps chugging along.
Momentum is shifting of course - this isn’t a steady state forever thing - but man, ugh.
You can do both.
> And once you do the fix - which won’t require ipv6 or will use a different vendor - then you won’t be talking to them anyway.
It depends on whether you actually want to fix it.
> The underlying issue is that there is a lot of momentum with v4, and hacks mostly work and work faster and easier, so most people end up going that way. So it keeps the momentum.
Yes, which is very different from being unable to get the equipment you'd need.
And if most people don’t buy that way - then it isn’t easy to get solid equipment that can do things that way - which makes it hard to get the equipment you need.
The question was about what the company can do, talking about external constraints, so I don't really care how purchasing departments work for that topic.
> And if most people don’t buy that way - then it isn’t easy to get solid equipment that can do things that way - which makes it hard to get the equipment you need.
For smaller companies, yes. Except the argument was that smaller companies could get them already, while Amazon would exhaust the world supply.
Once we move into the realm of companies that make their own markets, it doesn't matter what "most people" do. Those companies can make their own choices and get whatever they want made.
Assuming you’re talking about the NCS 5500, I thought the whole point of that platform was that it wasn’t using Cisco proprietary ASICS and was just using Broadcom chips with IOS-XR wedged on it anyway to give it the appearance of being a budget competitor to the ASR9K while lacking the majority of the feature set because ... it’s not using Cisco’s proprietary ASICS that support all those features.
Also, they have full ipv6 routing and switching support. So does the C6500, which is ancient (and still in production in many places)
Major tech companies have constraints, but when they decide to move, they can move almost anything. It would be cool to see how constraints and problem solving approaches differed among the FANG companies as they grappled with these issues.
And even so...this anecdote is/was 'many years after the fact', so what's the issue now? Easy: they don't need it enough to spend the money to operationalize it.
We mistakenly had the same notion that "why would a new line of Cisco wireless equipment not have IPv6". That pushed back a network upgrade of a remote office a few months. Our mistake really, we should have checked.
Of manufacturers, like Kyocera, have equipment that technically supports IPv6, but no-one really knows who to configure it. IBM have a software product which is IPv6 capable, or it was when they did the initial implementation in 2012. Later versions just sort of shipped with broken IPv6, because IBM doesn't actually test in new releases.
1. I'm a small-time self hoster. I need/want to control access to geographic locations and using IPv4 makes that pretty easy. Last time I checked, IPv6 was just so wrong that it's no good to use at all, and most IPv6 addresses were "unknown" in origin.
2. I'm used to the pseudo security that a NAT gives. I hear (ad nausea) about how NAT gives you no security. The simple truth is that obscurity does give yet another layer of protection, especially for machines that you're busily configuring to become secure. Of course, a real sysadmin here will be able to scoff and laugh, but for this homebrew old timer it's true.
But also, there's the obfuscation of your IP address when you're behind a NAT. This is pretty important in these ad tracking days. AFAIK (which is almost zero), doesn't IPv6 give adware companies a very good fingerprint on you?
3. All those ICMPv6 messages sniffing (and snooping?) really don't fill me with joy joy happiness. The only recourse is to read some dead boring RFC that my poor overloaded brain doesn't really want to have anything to do with. With IPv4, if you don't want PING, you turn it off, with IPv6.... it's subtle.
4. Firewalls require two sets of independent entries for the same service.
So, IPv4 is an address space that's understood. IPv6 really does feel like a Godzillian monstrosity and a chore to type in: double colons between every number and it's in Hex? At least with IPv4 you can type the numbers in pretty rapidly on a numpad.
So, I know this answer will be unpopular, especially to professionals, but for everyone I've encountered that's turned it off, the above list is pretty accurate.
Every few years I search around for a true "IPv4 to IPv6 for noobs" and every time I only find "It's the same... with these gajillion subtle differences". So, yeah, perception is definitely an issue, but scoffing at NAT doesn't help uptake at all. I really do try to be a good netizen, but it's hard. (that said, I do have a mail server set up to use ipv6 and all is good... except for the lists of unknown sources who hammer away at its security all day, every day)
With IPv6 you can set up your machine to use "temporary" addresses which will use random addresses from your router's subnet instead of a fixed one (based off of the NIC's mac address) and for a limited duration. The duration is normally some number of hours, but you could make it 10 seconds if you preferred.
In consumer routers, port forwarding is the exact same thing as an inbound traffic firewall. But when I turn on IPv6, what is the equivalent? Is my printer still protected from random inbound internet traffic?
On my Netgear R6700, I can't figure it out from the UI or from forum posts/help content. And without being certain, I don't want to turn on IPv6. Even though I'm technical enough to understand IPv6. Because my printer or my light bulb being exposed to the internet is a huge risk that my router is supposed to stop.
You just remove the NAT from the equation.
The default is deny.
You have to explicitly enable inbound ports.
The difference is that you connect to the device address, not the NAT gateway address.
No more port conflicts.
No more split DNS.
Etc...
Copy-pasting from a previous discussion a little while ago:
---
IPv4+NAT does not remove any more classes of problems than IPv6+firewall. Firewalls under IPv6 work exactly the same way as they do with IPv4.
An IP connection is started from the 'inside' to the 'outside', and the source-destination tuple is recorded. When an 'outside' packet arrives the firewall checks its parameters to see if it corresponds with an existing connection, and if it does it passes it through. If the parameters do not correspond with anything in the firewall's table/s it assumes that someone is trying to create a new connection, which is generally not allowed by default, and therefore drops it.
The main difference is that with IPv4 and NAT the original (RFC 1918?) source address and port are changed to something corresponding to the 'outside' interface of the firewall.
With IPv6 address/port, rewriting is not done. Only state tables are updated and checked.
New connections are not allowed past the firewall towards the inside with either protocol, and only replies to connections opened from the inside are passed through.
There's no magical security behind NAT: tuples and packet flags are read, looked up in a state table, allowed or not depending on either firewall rule or state presence.
The security comes from the state checking.
[…]
I have a printer with an IPv6 stack. I also have IPv6 addresses from my ISP. Yet somehow my Asus AC-68U prevents the public Internet from reaching my printer.
---
* https://news.ycombinator.com/item?id=28390634
IPv6 firewall on my Asus:
* https://www.asus.com/us/support/FAQ/1013638/
If you want to test, find the IPv6 address of your printer and try pinging it:
It all depends on firewall configuration, but I think you may unnecessarily scare people by suggesting they're wide open just because ping works.
stop disabling ping
True. There are IPv6 port scanners available:
* http://www.ipv6scanner.com/cgi-bin/main.py
* https://www.subnetonline.com/pages/ipv6-network-tools/online...
I think most OSes do that privacy thing where they periodically randomize the suffix of their v6 address.
The 'management' address won't be used as the source addrrss packets originating _from_ the host unless the use of temporary/privacy addresses is disabled.
A friend assigned ::25 for the service vIP of his SMTP server/process, and ::143 for IMAP. Your web(mail) host could be ::80 and/or ::443. All on the same host (if you wish). If you have an HA setup you can have the vIP failover by using (e.g.) keepalived.
Using tokens may be of some interest as well:
* https://man7.org/linux/man-pages/man8/ip-token.8.html
You can have a public prefix address, as well as a local 'private' ULA address at the same time. In some ways I wish the best practice would be for IoT devices and appliances (like printers) only have link-local addresses, and perhaps ULA if advertised, with global addresses only configured via config switch. It would perhaps allay some the concerns that people have (like you do).
If you wish to do this with IPv6 you can with ULA and NPTv6:
* https://en.wikipedia.org/wiki/Unique_local_address
* https://en.wikipedia.org/wiki/IPv6-to-IPv6_Network_Prefix_Tr...
> 3. All those ICMPv6 messages sniffing (and snooping?) really don't fill me with joy joy happiness.
For those wondering: ping works by sending ICMP(v4) echo request packets. If you wish to block v4 ping you block echo requests (Type 8) and echo replies (Type 0):
* https://en.wikipedia.org/wiki/Internet_Control_Message_Proto...
ping6 works by sending ICMP(v6) echo request packets. In IPv6-land block Types 128 and 129:
* https://en.wikipedia.org/wiki/Internet_Control_Message_Proto...
To block traceroute block Types 11 (v4) and 3 (v6): TTL/hop exceeded notifications.
> IPv6 really does feel like a Godzillian monstrosity and a chore to type in: double colons between every number and it's in Hex? At least with IPv4 you can type the numbers in pretty rapidly on a numpad.
We've run out of IPv4 addresses. We need a larger address space with more bits. More bits mean more typing. Get over it? ¯\_(ツ)_/¯
I kid, I kid...they didn't sell bait.
There are a lot of unpleasant failure modes to blocking ICMP without completely understanding the implications.
> I'm used to the pseudo security that a NAT gives
> my poor overloaded brain doesn't really want to have anything to do with
You've certainly made the point that you are too lazy to learn. Otherwise, you haven't made a case against IPv6 at all.
2. MacOS and Windows use IPv6 Privacy Extensions to randomize your address https://en.wikipedia.org/wiki/IPv6_address#Temporary_address...
3. They work great though, I always had weird MTU issues with IPv4 and had to hard-code one in my router, with IPv6 Path-MTU just works. It really annoys me when people turn off ping, stop doing that.
4. Poor UI for firewalls/routers that is not optimized for dual-stack IPv4/IPv6 is indeed a problem. And not just that, home or small business routers often have no IPv6 UI at all for stuff like firewall.
With IPv4 I always had trouble remember exactly what number was what device, with IPv6 it kind of forced my hand to set up DNS entries for everything and that short-term pain (what, 15 minutes?) paid back every time I had to connect to some printer I couldn't remember if it was .218 or .215
Depends on the exact rule you're writing, but nftables can remove a lot of duplication. Many rules cover both IPv4 and IPv6. It's the default since Debian 11.
https://rachelbythebay.com/w/2015/05/15/pmtud/
> sniffing (and snooping?)
Nothing is new here. ND is basically what ARP was. You don't disable ARP, do you?
Atleast ND is a proper layer 3 seperation of link-layer discovery..
I often wished there was just a simple IPv5.
Partly some protocol choices which are quite different from IPv4, but much more importantly - existing users see relatively little benefit from conversion, so most new IPv6 installs are new installations.
Eventually the monetary pressure would be enough to get a critical mass to switch, but this hasn't happened yet.
Any code storing an IPv4 address in a uint32_t can be hard to port to IPv6. Likewise, many codebases have their own ad hoc parsers for IPv4 dotted quads and would choke on anything else.
IPv6 is not just a straightforward extension of IPv4 to bigger addresses (plus some cleverness for how to route between them, if at all).
There's a whole lot of other complexity in the protocol. There's a way you're supposed to get addresses that's not DHCP, and a good chunk of clients don't have or only recently got a DHCPv6 implementation. You're supposed to have an efficient hardware multicast implementation. Addresses are structured (unlike IPv4 CIDR), and an entire /64 is supposed to be assigned to a single customer / subnet so they can auto-configure addresses based on that. In turn, the way to auto-configure your (NAT-less) IPv6 address was to use your MAC address, i.e., give advertisers a free permanent third-party cookie, and the RFC to do something else only came out in 2007.
And, of course, for better or worse people have designs that involve NAT, and until very recently IPv6 basically demanded that you rip all of it out.
Regardless of whether you think these changes are good or not, they are certainly a chore.
These are very, very simple protocols.
SLAAC doesn't work the way DHCP works. Do you have an IPAM tool that assigns addresses? Do you have a VMM/private cloud where addresses are in a database and you set up firewall rules? Do you have a guest wifi network where you assign a quarantine IP with a short lease and then a real IP once they authenticate? None of that works with SLAAC.
Especially if you have an existing IPv4 network and are rolling out dual-stack and have no interest in breaking IPv4, adding IPv6 via SLAAC is hardly a matter of adding another column in your schema. It's an architectural change.
Again, maybe that change is good, but that's the chore - not implementing the protocol (which is basically ip link | sed | ip addr add).
For privacy addresses, if you were considering implementing IPv6 before they were widespread, you'd have to figure out a way to keep from leaking them. The obvious approach is NAT, but that's effectively not an option. So you decide not to make IPv6 available to clients, only servers that already have fixed IPv4 addresses and don't roam. Or you do manual (non-SLAAC, non-DHCPv6 because that wasn't an option) configuration. Once they became available and common in people's clients, sure, but that means we didn't have "20 years" for people to offer IPv6 on guest wifi networks, we had a lot less.
Same with NATs. Implementing "not using a NAT" is absolutely trivial; you just... don't. Redesigning your network architecture not to use one, however meritorious it may be, is a massive task.
If addresses are in a database and you set up firewall rules, you set up your clients to consistently use the same local suffix. This is approximately the same amount of work as setting up a fixed DHCP lease for a host, or setting up a static IPv4 address. Once this is done, firewall configuration is exactly the same as v4, just with a different address format.
Using a quarantine IP for new clients is a really weird way of doing things that I never saw in 5 years of working on mostly-v4 SMB enterprise environments. Clients don't support it well and never have, and revoking the lease on demand is a pain. Everyone already uses plain old firewall rules plus DNS hijacking to force people onto splash pages. If you do something that deeply weird, you're going to run into problems every time Apple slightly changes (shudder) iOS DHCP expiration logic, let alone during transition to IPv6.
You can still NAT if you want to on IPv6; you just don't have to. (In fact, NAT between an internal v6 and an external v4 network is a very widely deployed transition technology!)
I have actually seen quarantine IPs for new clients, if memory serves - it was on MIT's wifi network in the late '00s, back when MIT still had all of 18/8 and gave everyone a public un-NATted IP (just firewalling port 25/445/etc.). You'd get a 10/8 address to connect to the captive portal, and then once you authenticated you'd have to renew your IP lease to get on the network. (They eventually switched to 802.1x and no captive portal.)
Long story short, my experience is that everyone is doing at least one silly thing with their networking ("write your own IPAM" is distressingly common, for instance), and even if everyone agrees is in fact silly, it requires some sizable project planning and expense to stop doing it. Certainly a lot of people have managed to implement IPv6 just fine - a good chunk of the internet is on IPv6. But a lot of people haven't, and I don't think the primary cause is laziness.
The main point I'm trying to make is that this has nothing to do with the technical characteristics of IPv6 itself. By definition, a layer 3 protocol interacts with every single piece of network-related software out there. You have to update everything, and that's a whole lot of work no matter how you cut it. It only takes one awful hack like that MIT thing you described (whyyyyyyyyyyy) to hold up an entire migration.
(If I were MIT, I would suggest turning off router advertisements ie the infrastructure side of SLAAC, and only serving addresses over DHCPv6. Gets you an easier port of hacky shit like that.)
From the service provider point of view, as long as their customers can reach them with ipv4, they have no reasons to switch.
From the customer ISP point of view, as long as services people use provide an ipv4 option, there is no reasons to switch.
Maybe the ones that have the most reasons to switch are new internet services and new ISP which might have a hard time getting ipv4 blocks. But that's just one more reason for established services not to move too fast :/
EVERYTHING needs to work.
There's a hell of a lot of software (and, even worse, hardware) that encodes assumptions about IPv4. Everything from userspace asking specifically parsing only IPv4 addresses, to only listening for IPv4 incoming connections, to variables using the IPv4-only type, &c. And let's not even start on the L3 hardware acceleration built into so much networking equipment.
You can't flip the switch when 75% of the stuff on your device is ready. The remaining 25% will break, badly. You need to switch over every single piece of code. And then before you get any benefit out of it, you need to do the same on every remote system you want to talk to.
This is the magic and the terror of internetworking. Before IP, you had to go through this nightmare for changes at many different layers of the stack. With the clean-ish separation of IP, only one layer was make-or-break like this: layer 3. Any change to layer 3 is horrifically difficult, purely as a deployment/management challenge.
the lower in the OSI stack you go, the harder it is to initiate change.
There is still some (mostly industrial) hardware that has lackluster TCP/IP support at best (for instance, assuming the netmask is always a /24...).
migrating these networks to ipv6 is not possible, and doing 6to4 adds a crapton of complexity.
We can, and do, make massive , non-backwards-compatible changes in layers 1 and 2 every few years and no one is the wiser. Layer 3 is special. It makes that flexibility in all the other layers possible, but keeps none for itself.
We had IPv6 at our research area 10 years ago. Admins changed, and it was wind down bit by bit, because "it made problems". Not only that, I learned that the the general view over all of the admin-staff in our organization (a larger "Technical university" in Europe) agreed that IPv6 "makes problems" and nobody wants it.
Change is painful...? It is a shame, but what can you do?
I know it’s all the rage to say “gee why no v6 yet?”, but that’s a LOT of infrastructure and testing to overhaul…
The effort is much appreciated!
... which creates all sorts of routing issues.
If you don't have your own publicly accessible IP address it creates all sorts of connection issues.
NAT systems are optimized for a few devices to be active at a time. As the number grows they might not co-operate well. Game consoles are infamous for networking problems when you have anything other than a single machine.
Want to run a public service with end-to-end connectivity? Go to your RIR to request an IPv4 block and be put on a waiting list.
Or break out your cheque book and be prepared to cough up $35+/IP for the privilege:
* https://auctions.ipv4.global
* https://ipv4marketgroup.com/ipv4-pricing/
* https://ipv4connect.com/marketplace
Or get an IPv6 address block right away for $0.
Admittedly, IPv4 internet is a good chunk of the Internet, but maybe not the part of interest to you at a given point in time. http://www.delong.com/ipv6_alexa500.html
There are a couple use-cases for that, but it should allow cheaper VPSes, or less complicated network configuration by eliminating NAT.
If a host only needs to access GitGub and a few select hosts, it can be granted an IPv6 without setting up DHCP, NAT, IPv4 routing tables, etc.
I've been considering using NAT64 as a way to eliminate the need for dedicated IPv4 configuration at home, unfortunately I recently moved, and the current provider is IPv4-only. This infuriates me to no end.