Five years of IPv6: whither the next five?
blog.apnic.net
blog.apnic.net
Without any extra effort the following sites (small sample from Alexa top 500) use IPv6:
* google.com
* youtube.com
* gmail.com
* facebook.com
* wikipedia.org
* netflix.com
Without IPv6 (no AAAA DNS records):
* reddit.com
* amazon.com
* twitter.com
* news.ycombinator.com
* imgur.com
* bing.com
* ebay.com
It's happening, slowly. ISPs who care are supporting it. A significant portion of my every day web traffic is over IPv6 and nobody has noticed. People on my local network are using it on Linux, Windows and Mac OS X and they don't even know what IPv6 is.
Google is clearly leading the IPv6 charge and has a statistics page[1] for those interested.
[0] https://blog.kylemanna.com/ipv6/comcast-automatically-enabli...
Are you in Calgary? Telus always rolls out experiments in Calgary first. For example, until recently their only deployed GPON networks have been in Calgary subdivisions.
Mobile is the main reason why Canada is >15% adoption on google-stats [1]. On DSL/cable, Rogers and Cogeco provide IPv6, as do smaller re-sellers such as Teksavvy on DSL, but otherwise big players such as Bell and Videotron have been dragging their feet and giving lame excuses.
[1] https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
Sites did load over v6 but it was slow compared to v4.
Progress
Yes. I have T-Mobile in SF, and going to test-ipv6.com shows "10/10 readiness score".
I don't think that's right at all. It might be true in the USA, but that's only like 3 providers, isn't it?
I'm in the UK and I don't have IPv6 on my mobile or at home. I travel to ROI often and my phone has never picked up on IPv6 address. I was in Italy a couple weeks ago and I never got an IPv6 address. I know I checked because a friend of mine keeps telling me bullshit like this about how real IPv6 is, and I've never had an IPv6 address.
I was in Spain at the beginning of the year and didn't get one; and Germany late last year: No IPv6.
Since you're from the UK, I suppose you are a Vodafone customer and therefore roaming in the Vodafone network in Germany (which does not support IPv6 yet).
On some networks/devices you might have to enable IPv6 explicitly, by setting the APN to IPv4/IPv6.
In Singapore, Singtel seems to be the only provider that supports IPv6. Unfortunately only for postpaid plans.
That's pretty neat, I'd like to check mine out.
As a geek, one who has put the networking stack into the ETA-10 (yeah, I know, nobody knows that machine, CDC spinoff super computer) and SCO's unix (yeah, I know, it sucked), so as a geek who gets the stack pretty well, I've never warmed up to IPv6.
To me, it seems like it went too far. 64 bits not enough? Really? Unless I'm doing the math wrong 64 bits is enough for 2635249153 addresses for every human on the planet.
slovax ~/p bc
2^64
18446744073709551616
./(7*1000^3)
2635249153.38707880228571428571
I don't get it. Seems over engineered. IPv4 works pretty well, seems like a slight improvement would have been enough.
But with WebAssembly, you'll not be locked into it, or into transpilers that produce it. Chances are, we'll see other reasonable languages being compiled to WebAssembly and getting mass adoption.
(WebAssembly is a stack machine with a bytecode interpreter, running in the browser, with code downloaded from the net. Java tried to be basically the same thing, only 25 years too early.)
Also, with a relative clean slate, they have a chance to make DOM manipulation transactional finally.
Sun was inept in many regards, but not terribly greedy.
I don't see how JS doesn't magically have GC pauses. WebAssembly doesn't have a GC built-in, so it may host a pauseless process.
2001:4860:4860::8888
Also, most people dealing with rfc1918 networks would much rather get rid of addressing conflicts and other problems resulting from non-unique addresses, like security problems arising from ambiguous addressing. (Or don't know what they're missing...)
If not, DNS is there for that.
So an operation responsible for less than 0.1% of the total time spent routing a packet now takes twice as much time... or it would if CPUs weren't superscalar for a long time now. That's paid back in tenfold just by the omission of the header checksum.
Do you have any benchmarks showing a real-world difference? https://www.unix-experience.fr/2013/ipv4ipv6-performances-co... shows performance to be identical on modern computers.
A bunch of very large-scale network operators (like Comcast, T-Mobile USA, Verizon, and Facebook) seem to strongly disagree with that, given how eagerly they've deployed IPv6 to get away from the hell that is IPv4 NAT and CGN.
Yes, IPv6 has lots of complexity/flaws/idiosyncrasies/weirdnesses (multicast, mobility, slaac, ndp, prettyprinting / the colons, extension headers, etc.) that mostly only look good through the rose-tinted glasses of the 90s and significantly slowed down deployment -- and in the end mostly ended up as "difference for difference's sake".
128 bits of addressing space and getting away from IPv4 NAT were unambiguously good. 128 bits is a lot, but memory/bandwidth is just going to get cheaper (for slow links you should use header-compression anyway), and it was better to go whole hog and skip 64 and go to 128 to avoid a future 64->128 transition. Given how the 32->128 transition is going, this seems like it was an excellent decision.
TL;DR:
* Multicast and mobility are shits
* NDP an overcomplicated shit
* The SLAAC / DCHPv6 thing is a ripe mess
* getting IPv6 provider-independent space is too hard
* extension headers are tricky, slow to parse, a source of tricky security issues, and thus are almost completely unused on the Internet in general
Basically almost all the moving parts in ipv6 (beyond the wire format and its 128-bit addresses) that aren't dangerously convoluted / mostly unused are pretty much just NIH'd reimplementations of the corresponding IPv4 protocols (like ARP, say).
Edit: somebody replied and deleted their comment. Since I had written a response I am editing this comment.
> Then your real complaint... is that you don't have 128-bit machine registers
Agreed, although my real complaint is more towards IPv6, for not thinking about this real-life limitation.
> what the urgent need to pass IPv6 addresses in machine registers
It's much slower than IPv4 to deal with! 64 bit addresses wouldn't have had this problem and still would have enough space for everyone on earth.
> And how is it "irritating af"?
Apart from the speed concerns: > The equality operator doesn't work, nor do other logical operators. Everything has to be defined.
Depends on the architecture. On amd64 (the architecture I'm typing this comment on), a 128-bit struct, like defined above, will fit in registers — yes, in 64-bit registers. The amd64 ABI[1] will split them across two registers. For example, if we take the above struct and use it,
void foo() {
ipv6_addr addr = { { 1, 2, 3, 4, 5, 6, 7, 8, }, };
bar(addr);
}
movabsq $578437695752307201, %rdi
xorl %esi, %esi
jmp bar
In [1]: hex(578437695752307201)
Out[1]: '0x807060504030201'
The non-optimized version is similar, but more drawn out:
# for some reason we zero it first
movq $0, -16(%rbp)
movq $0, -8(%rbp)
# then we init it again… okay gcc.
movb $1, -16(%rbp)
movb $2, -15(%rbp)
movb $3, -14(%rbp)
movb $4, -13(%rbp)
movb $5, -12(%rbp)
movb $6, -11(%rbp)
movb $7, -10(%rbp)
movb $8, -9(%rbp)
# move the struct into rdx/rax
movq -16(%rbp), %rdx
movq -8(%rbp), %rax
# just to move it into the arg-passing registers
movq %rdx, %rdi
movq %rax, %rsi
# call the function
call bar
It's twice as wide, yes, but that doesn't necessarily mean you're needing to pass it in memory.
> still would have enough space for everyone on earth.
IP addresses aren't just numbers assigned to machines. They must also — effectively — encode the route to that machine; you can sort of imagine it as a tree, with each bit giving you successively more local directions on the Internet. Now, of course, that's not exactly how it works, but the point is that some parts of that tree are going to be sparsely populated. Having a wider address space means you can make bigger, but not necessarily full, allocations in the address space, allowing you to keep whole networks together in a common prefixes, which results in simpler routing tables. (At least, that's the idea as I understand it.)
And it's not just 1 per person: I have more than one device, and I move between networks during the course of a day. If all of the networks I frequented actually had IPv6, I'd bog down at least 6–8 IPv6 addresses during the course of a boring day, and that's not counting stuff like networking equipment.
It's not just a simple question of "are there enough bits to assign each person an address"
> The equality operator doesn't work, nor do other logical operators.
On amd64 at least, __int128_t exists, I believe, and I think it should come with operators. In higher-level languages, you can define < and == simply enough.
Now, I grant that the above is highly architecture specific, and there definitely exist architectures where this doesn't apply. And those, yes, 128-bit will be slower than a theoretical 64-bit. I just don't think it's worth worrying about.
[1]: https://software.intel.com/sites/default/files/article/40212...
Exactly, and the huge address space allows the standard to right out set some structure to it, with 48 bits for global routing, 16 bits for subnet addressing, plus 64 bits for link-local, interface identifier. Routing is only concerned about the first 64 bits (which has all the fast operations you could dream of) and global routing only the first 48 even. Obviously doing some work to match the topology to the address space in a smart way by leveraging CIDR to reduce the size of routing tables is always going to be useful.
https://en.wikipedia.org/wiki/IPv6_address#Unicast_and_anyca...
So what? Didn't you notice that the 128 bits are split in half: {network|host}? Anything that needs to route things around is only concerned about the first 64 bits. Once you're hitting on the local scope the last 64 bits is what matters ~99.9% of the time. So you can have your efficient 64-bit comparison right there for most of the traffic.
I agree. It sucks, 64 bits almost certainly would have worked and languages/libraries/OSes tend to not do their fair share at taking care of IPv6-related stuff. That, along with all the prettyprinting/parsing business with the colons is legitimately annoying.
However, IPv6 was designed not just to fix IPv4's sins, but to ensure that there'd never be an address exhaustion issue with IPv6, no matter how many decades it would be in use. That's why there's 128 bits of overkill; the IPv6 designers knew that the IPv4->IPv6 transition would be awful (they even underestimated just how awful it'd be), that IPv6 would keep running for a long time once it got deployed -- and wanted to do their best to avoid subjecting the world to a transition from IPv6.
RFC5962 is "Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)" [1]
But that assumes that the ISP has addresses to spare. If not, we have the three layers of nat. ISP->apartment complex->customer router->all customer devices.
And then we have intermediates, like ISP->municipal->apartment complex->customer router->customer devices. Now we have four layers of nat.
In the really worse case, ISP are split up into multiple ones, and you can get carrier grade NAT in the form of ISP->ISP->municipal->apartment complex->customer router->customer devices. Five layers of nat and up.
Multilevel NAT is a form of sadness that NAT never was designed to do.
Also there's the issue that you'll end up having multiple devices with the same RFC1918 addresses, which is an immense pain in the arse to deal with.
It's a nasty hack to keep the net running until we can sunset IPv4. That's it.
64-bit IP would have been fine. If I were asked to extend IPv4 that's what I would do. I've ranted about the annoyance of 128-bit address lengths, but it's not a show stopper and it's something that could be fixed at the UI level and with better DNS management systems.
There are cool things about 128-bit addresses like SLAAC and cryptographically meaningful addressing.
We have IPv6. It works. It's getting deployed. There's absolutely nothing to be gained and a lot to be lost by bikeshedding about why 64-bit would have been veryveryslightly better. It's like arguing in 2017 about how PCs would be 0.5% faster if we were using the DEC Alpha instruction set instead of x86_64 or what the world would be like if Apple had stuck with PPC.
Just deploy IPv6. Please.
128 bits allows routing tables to be super small and fast. While RAM has gotten cheaper, it is still slow, and smaller routing tables are way more important than smaller addresses.
However, I agree with your central point - IPv4 was "good enough" that IPv6 is going to be a tougher battle than it ought to be. However, IPv6 is winning that battle already. 15% of google's users use IPv6, and it's increasing sigmoidally. [1]
This is only kind of true if you can fit your network completely into the RFC1918 space (which many large companies, for example, can not). Again, given the aggressiveness many of the providers, like Verizon, have taken in their IPv6 roll-out, including internally, and given how much of a complete mess NAT is at scale (with CGN and statefulness), I am personally dubious that IPv4 has the capability to carry us much further forward.
Won't this make scanning the address space nigh on untenable for the foreseeable future? The big thing is to retire IPv4 then.
I can somewhat easily remember a bunch of IPv4 addresses. I'll probably never memorize an IPv6 one, unless it's one of the 0xface cafe babe 0000 ones. Which waste address space even more, see above.
If it is, then your ISP is incompetent. You should get a /48 by default, at the very least a /56.
> there's something wrong here.
Why?
> I'll probably never memorize an IPv6 one, unless it's one of the 0xface cafe babe 0000 ones. Which waste address space even more, see above.
Why would you want to? Except for a few special ones (routers and DNS servers, mostly), which you probably should configure to use easy to remember addresses, what's the point of remembering addresses when there is DNS?
No, the last 64 bits should never be involved in routing, /64 is the prefix length for a single ethernet segment. A site should by default have at least a /48.
Another good talk from that conference is about how Carrier Grade NATs are (amazingly) even worse in practice than they sound in theory[1]. During the Q&A portion one of the audience members points out that as technologies like CGN become required to provide IPv4 service it will cause the cost of supporting IPv4 to rise over time and naturally push ISPs to kill IPv4 as the use of v4 drops while the costs to support it do not.
I can also recommend a short talk by Cloudflare about their experience serving IPv6 traffic[2] and another on the history and future of IPv6[3].
[0] https://www.youtube.com/watch?v=nNMNglk_CvE
[1] https://www.youtube.com/watch?v=fbk4H6EmZzI
[ * ] caveats apply
However, public IPv6 addresses are obviously part of provisioned ranges. And without NAT, there's no ambiguity about assignment to devices. So in practice, with IPv6 you're sharing something as unique as a MAC with all peers.
One solution is using proxies with anonymously provisioned IPv6. Tor will eventually handle that. It's also possible for VPN services. FrootVPN, for example, does that already, whether you're connecting to their servers via IPv4 or IPv6.
It's definitely still a problem if your ISP assigns you too small of an IPv6 range, and doesn't stop people from tracking you as your range, but it does as well, if not better, than NAT at stopping people tracking your individual devices.
Yes. I'm planning to run a Tor exit relay that does something like that. It'll connect with directory servers and upstream relays on a stable IPv4 address, however. Changing the exit IPv6 will screw up bandwidth measurements. But it doesn't matter, because I don't want the relay used as anything but exit role.
We pressured the ISP to remove this information. They resisted, said it was policy, we read the RFCs and argued back. A few weeks later it was removed.
Similarly, most Linux distributions now enable IPv6 privacy extensions. Once people settle in their habits, it becomes more difficult to change this type of behaviour.
IPv6 is a big change. Adopt early, influence policy while you can :)
Additionally, Windows seems to be doing pretty well in backward compatibility. IMHO, its major source of issues.
Color TV was designed to be compatible with black&white. Stereo FM radio compatible with mono, stereo vinyl records with mono. Electricity changes very, very slowly.
When computers become such an essential part of every day life, you cannot make radical changes any more every couple of years.
If your design becomes successful, you may be stuck with it for a couple of decades.
The failure of IPv6 is also the success of IPv4 engineering. When IPv6 was designed in the mid 90s, there were many issues that might hold back IPv4 down the road.
It is only in the last couple of years, that issues (related to the IPv4 address shortage) pop up that basically cannot be solved anymore and make IPv6 an attractive alternative.
Another big part of it is that all of the features of IPv6 except the address length change were back-ported to IPv4 (e.g. address auto-assignment and IPsec) removing the carrots and leaving only the "stick" of the IPv4 address shortage (which barely registered at all until a few years ago) to push people to v6.
Designing around an incremental upgrade strategy is hard. It's a very important design constraint for an upgrade though!
The extra, wastefully spent bits in IPv6 make it super expensive to implement routing tables. Compare that approach to the 2^48 effective limit in the 2^64 bit address space in AMD64. Like IPv6, AMD64 is an upgrade from a 32-bit system - but AMD64 included support for the previous 32-bit version and won its war long ago, while IPv6 is still reluctantly limping along.
Upgrades of huge interconnected systems need to be incremental. As a human, invested in the process, it's hard to accept that: the point of the upgrade is to replace the old system :)
On Python 3, I'm okay with having more discussions about some line thats failing at a byte/unicode boundary, instead of the "your entire design ignored the unicode/byte distinction, but mostly worked until now, and you've unwittingly built a mountain of technical debt." The language, going forward, encourages the correct behavior. Now if only my co-workers would stop working on that mountain long enough to switch to it…
I've just read the usual crappy "why 2^128" bollocks etc (you don't run internet routing, do you) here and the other usual whining.
However, how do you effectively use multiple connections to the internet, without resorting to PI and something like BGP?
What is stopping you from using multiple connections to the internet?
Each link will have a prefix that you are delegated and your SLAAC or DHCPv6 will give out addresses etc.
Now which one will your device use? Your PC cannot know that link C is down because that is only known by your router.
IPv6 does not address the same basics that IPv4 failed at - routing around crap, without a routing protocol.
* add another entry to the global routing table thus nullifying a benefit of IPv6
* cost a bloody fortune (approx £5,000 per year)
* is your mum able to ask for BGP peering
I am personally able to pay the price for PI but not everyone is and that is my fucking point. Why should your mum not be able to ask for a internet connection that is able to tolerate a failure?
There is NPT but it is simply NAT via another name.
I've been running IPv6 at home for quite a long time. I passed the WAF at least two years ago.
Any more ideas?
Cheers
Jon
And your router should withdraw the prefix from RAs, so the PC stops using it.
The kernel routing table of your PC should remove the link once the PHY has been detected to be down. That's even if your PC supports multipathing.
We don't rely on layer 3 to communicate a link is down to us - we rely on layer 1.
With IPv4 the router will just fix up NAT. With IPv6 you now have to deal with significantly more complexity.
How so?
In a multihomed environment, you'd still be PAT'ing to unique addresses on the WAN side (unless a FHRP is in use, which would be rare) - if one of those links go down, so too does all of the flows associated with address of the link. If no dynamic routing protocol or redirects are in use, the gateway with the down link will also eat half (assuming two gateways) of all egress traffic.
IPv6 should be easier as no NAT/PAT is in use, therefore you have no challenges with statefulness or routing symmetry.
Yes, your connections will get temporary eaten. But for the typical developers workload that won't be a huge issue because most connections you do are short-lived. Configuring all your clients to properly switch vs. configuring your NAT router (with builtin functionality for exactly that) is orders of magnitude more complex.
This is the next big step as far as I see it.
IPv6 has been the future of IP networking for decades. Yet here we are and I still often surf the Internet without v6 connectivity.
It suffers from a fundamental problem: As long as IPv6 is not universally available nobody has a real advantage from supporting it. But as long as it provides no advantage many ISPs and web server operators won't bother supporting it.
I think this is a design flaw. IPv6 was built without a plausible transition plan. The plan "over time more and more people will switch to v6 and at some point everyone will have it" clearly doesn't work and will never work.
Google statistics show that nearly 20% of their traffic is over v6, which is honestly not bad. The USA itself is 35%, with no latency hit.
This is totally bad. We need close to a 100% for v6 to make any sense. 20% IPv6 is pretty pointless.
Considering how it was 2% not many years ago, this is a huge improvement.
What's going to drive this further is that the cost of supporting IPv4 will increase more and more as IP-space is exhausted and ISPs will have to apply new hacks like CGN.
At that point getting people to IPv6 and IPv6-only will be a purely be about economics.
Also my ISP blocks some ports incoming lst time I checked, even on IPv6, even on their business plans, without a static IP. And I assume they would do the same with v6 because they don't support static prefixes themselves.
To be fair their IPv4s are very static and only change when I change my WAN MAC address or am offline for longer than a DHCP lease (power outage)
Coding for a mix of paths creates a 3 way test problem. You have to test purely legacy, the mix of legacy and new and then just the new. You suddenly have to start coding for runtime depended details.
The only thing that was the critical flaw in v4 was lack of address space. Yes, there are obviously a lot of other issues with v4, but instead of just fixing that one critical flaw, v6 suffered from classic scope creep, put in the kitchen sink, in a way incompatible with v4, and 2 decades later we're still 5 years away.
This gets suggested and rehashed on every single IPv6 comment section. There is no way to make IPv6 compatible with IPv4: by the Pigeonhole principle, there is simply no way to reference 2 ^ 128 objects using only 32-bits. The next usual hack is to "add an option" or something; but all the routing hardware would need to understand that option, which entails upgrading the entire Internet, which is exactly what IPv6 is doing/has done, except that adding an option ends up with a worse design.
Any suggestion needs to fulfill a. any machine should be reachable and b. you can't upgrade everything, or you may as well just go with what we've got.
In the end either all those things were backported to IPv4 or turned out to be bad ideas. IPv6 ended up being just more bits, but with a fully incompatible implementation.
If they had known this at the beginning, we could have transitioned to IPv6 long ago, by designing for a smooth transition period and reusing as much of the IPv4 stack as possible.
An end-to-end extension header would have been simple - something that can fallback to NAT connection tracking when it's not recognised. And it would have saved man-centuries of effort.
There is no such thing, it's still PPPoE and PPP, just that there is IPV6CP and IPv6 on top of PPP. And that, in principle, can run through the same PPP session as IPCP and IPv4, though a weird ISP might not support that, obviously.
Also, most people who ask for IPv6 for their VMs or whatever don't even have any use for it. IPv6 will be a huge mess, if I only think about sending emails via IPv6, how should that even work properly?
Can you clarify what you mean by that?
Email works fine.
This is extremely hard with IPv4 already, it will be a huge mess with IPv6.
I know it seems rather excessive to use an entire /64 and only populate a few addresses, but I'd rather have too many addresses available than too few.
It's baked into the standard that IPv6 networks shouldn't be smaller than /64. If a provider is disregarding the standard so blatantly I would probably avoid them.
Really, why on earth would a cloud provider be so stingy with IPv6 that they'd give less than a /64 per customer? ARIN gives out /32s like candy and a single /32 can be split into ~4.3 billion /64s.
Suffice to say I've got IPv6 to the internet gateway, but no further. => They fulfilled their contractual obligation to "provide ipv6 connectivity", while being entirely useless. They'll probably use us as a stat to prove that no one wants ipv6 anyway...
There is no choice in provider.
So, it's a problem. For no reason at all.
Also, no, it's not really just a minor problem. Reconfiguring your one client device might be trivial, but that's really not the question.
The question is what you do with a setup with a few dozen devices/machines/routers/whatever.
First of all, even if you do a new setup, it's idiotic that you'd have to consider the idiosyncrasies of your ISP when designing your network, instead of choosing whatever setup fits your internal requirements best. That you possibly cannot buy a certain printer because it doesn't support DHCPv6, or whatever.
But it's a lot worse when you think about switching ISPs with an existing setup: Having to completely rebuild your network because of your ISP's idiocy is ... well, idiotic. Suppose you have a bunch of routers that do SLAAC for end devices and obtain prefixes via DHCP-PD from the uplink router. Really, all that should be technically required in such a setup to switch from one provider to another would be to unplug the old line, plug in the new line, everything should renumber automatically, while keeping the exact same network structure. Good luck reconfiguring all of that to work with a /65 ... and when you have done that, tell me again that it's a minor problem.
All the stuff that I've been talking about is what is required so that in the end, you can just plug in your laptop and have IPv6 connectivity without any manual intervention on your part. Yeah, that's how it is supposed to be. But that depends, among other things, on the ISP providing a reasonably sized prefix.
Also, there is more to networks than "the router" and "clients". You can have more than one router, you can have servers, you can have routers with multiple interfaces that are isolated from one another ... not everything is "my home DSL router with built-in WiFi access point, used by one smartphone, one tablet, and one laptop".
And I think you might be confusing SLAAC with DHCP? Those are two completely distinct mechanisms, and you don't need DHCP in IPv6 networks at all, in particular not for client systems.
Solutions to this problem that try to avoid penalizing other users sharing a prefix will certainly be interesting. Some approaches ban per /128 and extend this ban to a /64 if two or three addresses within the /64 got banned.
I was trying to figure out where the deception played into it
There are large ISP's that already have for the most part gone ipv6-only. Here's T-Mobile USA's roadmap: http://www.rmv6tf.org/wp-content/uploads/2017/04/04-IPv6-NAv...
Apple has already required all apps to support ipv6-only on iOS for some time. I think it's going to be a lot less rocky than you think.
This was true for the first generation of products which weren't designed with v6 in mind. I don't think it's necessarily true anymore. The fixed length fields and much easier routing tables should lead to less complex hardware. (Not that it matters since everyone is dual stacked for the forseeable future.)
However practically eliminated is possible, even likely. ISPs are moving that way, we are out of IPv4 addresses and all. Eventually penetration will be large enough that some smaller servers will decide that having an ipv4 presence isn't worth it. Probably because the ipv4 static address costs money and ipv6 is cheaper.