One interesting observation about IPv6 I've made is that in Europe IPv6 and FTTx seem inversely correlated. For example Spain is one of the leaders in FTTx with 87% of homes covered, but have only 3% IPv6 adoption according to Google. Meanwhile Germany has one of the highest IPv6 adoptions in Europe, 52%, and one of the lowest FTTx coverages (16%). Latvia, Lithuania, Belarus, and Iceland all have 90% FTTx and 10% IPv6. UK, Finland, Belgium, and Netherlands on the other hand seem to be having better IPv6 adoption than FTTx.
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.
> 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.
It boggles my mind that IPv6 has such a slow roll out (it's been a thing since the early 2000s = twenty years ago).
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?
I recall being at Amazon some years ago when we were running out of IP addresses internally. A natural answer was "Why don't we all just switch to IPv6?".
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.
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.
Great story; I don't buy it. I haven't purchased a commercial-grade router (for values of more than just 'Cisco' or 'Juniper') that couldn't support IPv6 (admittedly for better and worse levels of 'support') since the early 2000s. If Amazon wanted them, they would have been supplied. Maybe it's "no one can supply routers with the IPv6 support we want (snowflake emoji)" or "we can't deploy the routers fast enough operationally". But not enough v6 capable routers is a stretch.
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.
I don't know how long ago that was, but I kinda have to call bullshit on her claim (even if it was hyperbole for the sake of making a point). Companies exist to make bespoke solutions for this very purpose, and nowadays outsourcing that kind of work is just natural for Amazon. Hell, they made a deal with Rivian to get a fleet of electric delivery trucks, getting some Chinese manufacturer to slap a Cortex m53 into a shitty plastic enclosure with Ethernet ports can't be that difficult. I bet there are AmazonBasics products that have required more forethought than that.
A core or edge router in a terabit+ scale network is a far cry from getting someone in China to make you a bunch of Netgear clones.
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 Cisco 5500 series chassis is ... jam packed with custom ASICs
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)
Fat lot of good that will do you with your project that needs to be completed next year or your company is hosed no? 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.
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.
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.
Cisco still produces brand new equipment without IPv6 support. It's not only routers, much of the rest of the networking stack needs IPv6 to be enabled as well.
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.
I think its more of a matter of perception than anything. IPv6 adoption has gone pretty smoothly imho, there hasn't been any major blowbacks or anything; for example the Google IPv6 adoption chart trend is steadily increasing.
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.
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.
Someone pointed out recently on NANOG the thing that probably killed a TON of IPv6 momentum was when they missed the deadline to get it included in Windows 95. Approximately no one was on the internet before then.
Seems pretty far fetched to me that there would have ever been a chance to have IPv6 in Win9x. For comparison, afain FreeBSD was the forerunner with IPv6 support, and they got it in 2000. So I'd say they "missed the deadline" by 5+ years. It was probably around 2005 when we realistically had somewhat usable IPv6 support at base OS level.
I think the point was that it changed the whole demand curve. If the major consumer OS at the time had v6 support things like FreeBSD would have added it earlier.
That's a different concern though - Promoting the whole use case of the internet vs migration from one protocol to another.
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.
Introducing HTTPS to existing infrastructures is easy. Just terminate it at some point. It also adds a big advantage to users that their traffic can't be read by network operators. Introducing ipv6 is harder, as you need to change all your routing, logging, banning, etc. facilities to support ipv6. It doesn't add any direct advantages for users, as all ISPs still have to support ipv4.
> Lets Encrypt was released to the public in 2014 and by like... 2019 basically all of the internet was HTTPS.
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.
7 years for a core router is on the low end aswell. High end routers consist of a chassis which can last a decade or more easily. usually the line cards inside the chassis are replaced to allow higher band with, but the control plane can stay in place for a very long time.
Easy, India vs USA stats show that. India had an internet boom after exhaustion so its adoption is new hardware. USA's boom predates IPv6 so its mostly replaced.
India's visible adoption stats are over-represented by lte deployment. Lots of broadband providers still don't have ipv6 and some major ones deployed it very recently.
Yep. Think about how long it took to get the whole country on dialup / ADSL, but how long it’s taking the whole country on FTTP (fibre to the premises). It’s a similar issue, as it’s not just a software upgrade, it’s a hardware upgrade as well.
How often were people upgrading computers in the 1990s and 2000s? How often are people upgrading now?
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.
I believe that ARPANET was 100% TCP/IP at most a year after it was rolled out in 1983. Its predecessor NCP only supported 256 nodes. So, yes, things take time but likely for different reasons.
I dug into IPv6 a few weeks ago. If you learn it from the ground up, as if you were first learning IPv4, it truly is not more complicated than IPv4+ARP. Length of address may be a reason people don't look at it at first, but if you look at it from an engineering perspective, it makes sense.
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.
> 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.
there is RDNSS for router advertisments used with slaac. although it wasnt there initially and support for it might be lacking yet.
> Also, damn every ISP and every router company that doesn't 100% support IPv6.
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.
In what way doesn't Ubiquity sorry it? I'm using only Ubiquity gear at home, and my network is fully IPv6.
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.
If you configure an EdgeRouter completely through the command line then yes it does support it. The web UI though, is completely missing things like IPv6 firewall if you just quickly want to add a rule with a few clicks.
On the Unifi gear, the IPv6 UI that is there is marked "beta"
How important is it for networks to provide DNS servers? Couldn't a device usually get away with just using 2606:4700:4700::1111 or 2001:4860:4860::8888 all the time with SLAAC? Also, what about RDNSS?
So, I was less aware of RDNSS. That makes one of my complaints moot.
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.
I know DNS itself is critical. I'm asking whether network-provided DNS is critical, or if using well-known DNS servers like Google's or Cloudflare's would be good enough on most networks.
Do those return the correct CDN servers matching your geographical location and/or ISP?
I didn't try Google or Cloudflare specifically, but I did experimentally used some other DNS provider for a while, until I eventually ran into the problem that by doing so I got the "wrong" set of servers for anything hosted on Akamai, where the route between my ISP and those specific Akamai servers was grossly overloaded in the evenings.
Switching back to my ISP's DNS meant getting a more suitable set of Akamai servers and reasonable download speeds again.
> 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.
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.
It was, at some point, routing. Not all (inter)continental data highways are/were IPv6-enabled, meaning that IPv6 does/did not have the performance of IPv4 (latency, bandwidth). Global websites with no global distribution of servers thus kept using IPv4-only to prevent significant performance regressions for the early adopter clients.
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.
Years ago, the French ISP `Free`, after much dragging of feet, enabled IPv6 support for their customers.
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.
I see the opposite right now, with transfer rates being about the same but latency over IPv4 being quite bad compared to IPv6:
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
And with IPv4:
$ 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
I have no idea why that happens. It's not on all sites though, so it's not like my ISP adds latecy to all IPv4 sites, but rather something to do with routing. The IPv4 traffic might be routed to a google datacentre further away.
> Years ago, the French ISP `Free`, after much dragging of feet, enabled IPv6 support for their customers.
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]
Hmm, my experience in the US with CenturyLink Fiber's 6rd implementation suggests it's also slower than IPv4 (I went from ~900/900 to ~500/500 when I enabled it). I decided I could live with that, but it's still a little disappointing.
The main fiber network here in Japan (NTT) had the opposite development - their old PPPoE-based IPv4 core network was under-dimensioned for modern traffic patterns, so instead of upgrading it they build the next generation core network on IPv6.
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.
For me it's a few things that keep me from fully embracing it, & largely the problem is perception, as others have noted.
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)
I've adopted IPv6 for a small business network I run and it's been great being able to punch small holes in the firewall for certain services without dealing with NAT, port conflicts for software that makes it hard to configure ports, etc. I have a bunch of services that I access there that are configured IPv6-only just because it's so much easier to configure than NAT.
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
> I'm used to the pseudo security that a NAT gives.
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.
> 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?
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.
Ping will still likely work. At least I can ping all my machines on my private network. However, I'm not able to ssh into it or anything else, because all traffic is dropped.
It all depends on firewall configuration, but I think you may unnecessarily scare people by suggesting they're wide open just because ping works.
Your hosts will also use SLAAC to determine their permanent 'management' address, that's the one you use for connecting _to_ them.
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.
Given the number of addresses available in a /64 IPv6 subnet, pick a value to statically assign to it and use that. If you have a SSH bastion host / jump box, perhaps pick ::22 as the end address part.
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.
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).
Home routers (and even small business routers from companies you'd expect better from like Ubiquiti) are often completely missing the UI for stuff like IPv6 firewall and it's a real tragedy and definitely something that is holding back adoption.
> 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):
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? ¯\_(ツ)_/¯
Your arguments regarding NAT only make sense when considering carrier grade NAT.
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.
The point is that many people are too lazy to learn a more complicated alternative to something simple they've used for a long time. And that's why ipv6 still hasn't taken off in many areas.
> 4. Firewalls require two sets of independent entries for the same service.
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.
> What about IPv6 makes it such a chore to become widespread?
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.
Oh, sure, but my point isn't about implementation complexity, it's about network architecture.
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!)
Ah, well, I'll just modernize my IPAM, no big deal....
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.
Having done some work on implementation/migration:
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.
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.
Note that this is measuring clients of Google services. It's useful for tracking consumer ISPs, but applications that really benefit from e2e connectivity have been and will be moving faster.
looks like another 10 years at most going by the current rate. And I expect it will speed up at the end when we reach something like 90% and some sites go v6 only.
>What about IPv6 makes it such a chore to become widespread?
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.
> What about IPv6 makes it such a chore to become widespread?
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.
The additional 12 bytes to store the v6 address might not be trivial to find as well (connection state tables in kernels, additional space in DBs). There's also MTU issues.
It's all about incentive I guess. What do they win by supporting ipv6?
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 :/
Not only do you have to support ipv6, ipv4 will never go away on any meaningful timescale. So even if you do the right thing and deploy it you still have the same ipv4 address constraints. There is no winning.
Even at organizations that have considerably smaller networks than Google, Amazon, Facebook and Co there are just seemingly insurmountable numbers of "small" problems that discourage all the involved parties to adopt.
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?
Video chat. File transfers without a third party host. Cell phones almost always only offer a public address over v6. Internet gaming. VPNs without address conflicts. Not being banned from Wikipedia because someone else with the same CGNAT ISP got banned.
For the average consumer they don't notice a difference. Both my home and mobile ISPs have said they have no plans to offer IPv6 connectivity because it's not a requirement.
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.
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.
Two reasons. First, it's just inertia and backward compatibility. Same reason we still use the x86 instruction set in spite of its issues. Second reason is that long IPs really are kind of inconvenient for IT and network administrator people.
With the IPv4 internet, that is. You don't need IPv4 to connect to most GitHub pages anymore.
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
the Internet is almost out of IPv4 addresses, and the ones that are left are becoming expensive to obtain. Rather than hide whole blocks of users behind NAT, they can just use IPv6.
I don't want to have my own IP, at least not without frequent changes. My servers should have static IPs but having static IPs at home or for mobile devices only makes tracking easier..
Mostly because we've invested huge amounts of engineering effort to work around the problems. The result is that for the most common use cases, things mostly work.
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.
The big one is the address space expansion, which in addition to solving "can't get addresses" also makes routing cheaper and faster (can allocate addresses based on network topology, rather than on what's available).
Whole they were breaking backwards compatibility anyway, they also introduced a faster way of getting initial addresses, changed headers and dropped some features to make routing easier to implement in hardware, and added some features to make annotation of packets in the network backbone during transit easier.
IPv6-only hosts will be able to connect to github pages now, if configured properly.
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.
We have created perhaps an easier documentation on how to make it all work on your own domain, with many screenshots and such. Here it is: https://www.orgpad.com/s/cjzpkTRIK_L
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.