United States IPv6 adoption over 50%
google.com
google.com
Also I'll throw in the standard "HN is still v4 only" :).
We have IoT style devices using AWS. And IPv6 has long not really been available on AWS. Yeah, it has become a bit better the last 3-5 years.
So we have not really worked on IPv6 for our devices either. The kernel would support it, but our user space just does not use it. The typical excuse, someone else hasn't done their homework first...
Our devices work just fine with T-Mobile US SIMs. I assume you were referring to US? So where is the IPv6 only aspect?
For other offerings like NB-IoT or business PCN you're still able to do either it's just the normal consumer services that were pushed to v6 only service. Though I'm not sure if there are still any legacy connectivity options that will fallback to v4.
> I'm not sure if there are still any legacy connectivity options that will fallback to v4.
That sounds the most likely option to me.
PS. Not able to watch the video now. Hope not to forget at a more suitable moment.
Most 4g modems work as routers exposing an ethernet interface to the host, so it's certainly possible that it's doing 464xlat in the firmware, and if it doesn't tell you on some sort of status page then the only real hint that it's doing it would be a reduced path MTU.
I wouldn't be surprised if T-Mobile offer legacy service to any type of business contract or non-phone client though.
Not idea about most. I have seen it that way, but our Sierra Wireless requires ModemManager and appears as a wwan network interface.
However if your a normal consumer with a single network visible IP (if that), it's REALLY useful. I've got a /60 (16 /64s'), and I have one per port on my router and it's quite nice to be able to get to anything inside my home network from anywhere on the internet. Filesharing, monitoring home automation, opening/closing my garage door, etc.
When you put it like that, it sounds kind of scary.
I wouldn't trust the horrible default passwords and lax security built into most devices for home use to be exposed directly to the Internet even with a firewall.
Again, people are depending on something that isn't really designed to provide security to provide security. Devices that have horrible default passwords aren't secure in any environment. We need to a) do better in picking what we run on our networks and b) hold manufacturers accountable for setting sane defaults.
Some people just want their lightswitches to work.
In other words, if you have internet and you're using NAT then unless you have done some complicated stuff (port forwarding) you're probably safe.
If you have internet and you're using IPv6 then unless you have done some complicated stuff (enabling a firewall) then you're probably not safe.
I guess eventually IPv6 enabled routers will come with a firewall enabled by default but let's not hold out breaths!
Hell if you have a firewall exploit then exposing stuff to the internet doesn't matter.
Sadly, this is very far from the truth. Most routers do not filter IPv6 by default, mainly because IPv6's design assumes a per-device firewall. This means that literally you need to ensure that every device supports a firewall or otherwise operates in such a way that it is safe for public access.
This isn't my experience. If you are correct however, that is a failure of the ISP/CPE provider, not a flaw of IPv6.
> mainly because IPv6's design assumes a per-device firewall
I don't see a single mention of firewalls in the RFC[1]. But then neither did the ipv4 spec. Why would we suddenly stop using firewalls though? They have been standard on networks for decades.
First, I'm excluding enterprise firewall here.
I've verified this with multiple non-CPE routers, and except for the router itself (for obvious reasons), no, IPv6 traffic isn't really filtered. The "firewall" is laughable on some routers (including some assuming /64 filters which isn't necessarily true for some servers like OVH's). The only non-enterprise one that's working as much as an IPv4 system is Asus'.
Some routers tries to filter out DoS attacks. Those are rather confusingly called a "Firewall", but it's not really a controllable firewall per se, allowing "normal" but otherwise a malicious-if-DPIed traffic. A tell-tale sign that this is the "firewall" you have is that you cannot set IPv6 whitelists on your router.
> I don't see a single mention of firewalls in the RFC[1]. But then neither did the ipv4 spec. Why would we suddenly stop using firewalls though? They have been standard on networks for decades.
The RFC? Yeah, both IPv6 and IPv4 have evolved in the years so that there's multiple RFCs about them. For example, IPv4 don't promote ICMP firewalls but details what ICMP messages must you allow if you deploy one (unless you wholesale block that IP). IPv6 instead never allows you to block any ICMP messages except if you wholesale block an IPv6 address.
https://www.anvilsecure.com/blog/dhcp-games-with-smart-route...
It's super annoying, tbh. A subset of technologists only seem comfortable with the technology that was available when they were 18-24, regardless of how old they get.
"What's this? I never needed it before, what's the sysctl to turn it off?"
It's super annoying, tbh. A subset of developers only seem comfortable with technology invented in the past 18-24 months, regardless of how untested and unstable it is.
“What's this? It was written 2 years ago? It must be old and useless. I’m going to require my app to use the latest version and I don’t care what kind of headaches it makes for the people who actually need to make sure it’s up an running when users try to use it.”
It's already possible to connect from v6 to v4, and using 48-bit addresses wouldn't make doing so any easier. 48 bits would also be way too small; there'd be no point in going to this amount of effort to update IP only to then have to do it a second time straight afterwards.
Trying to keep jumping to the new hotness is simply a survival strategy.
IPv6 has been a draft standard since 1998. Get a better argument.
I’m not interested in another argument but calling my position “pitchforks” is a bit disengenuous and irritating (which is why I’m replying, off-topic, to you).
While I think it has something to offer I would like potentially better alternatives to be able to exist in future, this is not “pitchforks”.
systemd is the choice of basically everyone who builds distros, so of course it's going to be hard to avoid unless you volunteer to do all of that work yourself. When you take work from someone else, that comes with taking on the choices that they make.
What you state is absolutely true, but denying there’s more nuance is not helpful. That’s all I’ll say because this is not a worthwhile conversation to have here.
Even if we ignore the fact that systemd made it artificially difficult* for distros to support other init systems (so it wasn't a freely made "choice"), have you never encountered a situation where the popular choice turned out to be the wrong one? Think, for example, of people throwing their trash into nearby rivers, or developers using 2 digits to store year values.
(* Imagine being a volunteer for a distro and having to deal with bugs like "I installed my new printer and it changed my init system[0] / my system no longer boots").
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863974
Of course, turning off IPv6 fixed a lot of connectivity issues, at least back in the day. Maybe it's better now, but I see no benefit in re-enabling it. What's the value-add?
Horace Odes, III 65BCE
IP6 requires a bunch of new tooling and configuration, and if running dual stack provides plenty of new opportunities for failure.
When ever I enabled ipv6 I got 10/10 from test-ipv6.com and randomly few ours later it would go down for no reason. I used few hours to understand wtf was happening. Then I just gave up and disabled ipv6. I got peace of mind and lost nothing. Maybe someday I am bored enough to try again that sorcery and black magic.
In anticipation, where can I catch up on ipv6 routing? Does the number of route entries explode?
I do need a "business reason" to adopt it, since the Center for Internet Security benchmark dings your system if it is turned on.
That's also your business reason. The price for IPv4 connectivity will go up. At some point a startup will not use IPv4 anymore because it will be too expensive. If you don't have IPv6 access you will not be able to use the services of that startup.
Price of an IPv4 address has doubled last year and gone from about $7.50 in 2016 to about $40 now. https://ipv4marketgroup.com/ipv4-pricing/ https://ipv4.global/reports/
Consider the counter-factual: what if 64 bits ended up being not enough?
Given all the effort that needed and still needs to be done to move from IPv4 to IPv6, if we eventually needed to move to IPv7/8 it would even more difficult given how much IP in general has/is pervading civilization.
It's better to have the extra addresses and not need them, than need them and not have them.
It's the reason why ZFS went with 128 bits as well:
> Some customers already have datasets on the order of a petabyte, or 2^50 bytes. Thus the 64-bit capacity limit of 2^64 bytes is only 14 doublings away. Moore's Law for storage predicts that capacity will continue to double every 9-12 months, which means we'll start to hit the 64-bit limit in about a decade. Storage systems tend to live for several decades, so it would be foolish to create a new one without anticipating the needs that will surely arise within its projected lifetime.
> If 64 bits isn't enough, the next logical step is 128 bits. That's enough to survive Moore's Law until I'm dead, and after that, it's not my problem. But it does raise the question: what are the theoretical limits to storage capacity?
* https://web.archive.org/web/20171118074243/https://blogs.ora...
For IPv6, people memorize/type IP address all the time. So the IPv6 designers needed to balance the address space size with ergonomics - and they did this poorly, imo.
Increasing the address space by a factor of 2^96 while still reasonably allowing addresses shorter than the v4 equivalent seems like a pretty good balance to strike, especially when the vast majority of users use DNS or other automatic discovery and thus won't ever interact with them anyway.
Most people have a hard time with remembering more than a handful of important telephone numbers (15 digits per E.164), so I don't think 64- (36:31:85:fc:bc:64:21:58) or even 48-bit (da:e1:4d:a5:9d:e7) addresses would be any easier.
And if you don't like the current IPv6 addresses, be thankful the IETF didn't go with RFC 1561:
> General purpose CLNP implementations MUST handle NSAP addresses of variable length up to 20 octets, as defined in ISO/IEC 8348 [11]. TUBA implementations, especially routers, MUST accommodate these as well. Thus, for compatibility and interoperability with OSI use of CLNP, the initial octet of the Destination Address is assumed to be an Authority and Format Indicator, as defined in ISO/IEC 8348. NSAP addresses may be between 8 and 20 octets long (inclusive).
* https://datatracker.ietf.org/doc/html/rfc1561.html#section-4...
I did the math and it was something like a decade of the worlds production of disks, in a single filesystem. I could somewhat understand if it was a distributed filesystem, but it's not.
It doesn’t seem impossible that someone might have a single pool too big for 2^64 by the end of ZFS’s useful life.
Just kidding, but maybe not.
So did Jeff Bonwick:
> Thus, fully populating a 128-bit storage pool would, literally, require more energy than boiling the oceans.
* https://web.archive.org/web/20171118074243/https://blogs.ora...
As my home router only supports stateless auto configuration, it’s an additional friction point to have stable addresses. Oh, and since the /56 is assigned by my ISP, it sometimes changes, so I can’t just rely on addresses being stable.
I’m not saying that IPv6 is necessarily bad — we _need_ the extra address space! - but it definitely requires a different way of working and I haven’t completely cracked that nut myself yet. I’m almost at the point that I’m just considering using NAT with IPv6, but I fear the IP gods will spell an evil curse on me if I dare to do that.
I don't even know what's my workstation's IPv4 address. I just connect to desktop.local and my NAS with nas.local
Or just have IPv4 on the LAN.
I go to `router.localnet`, not some IP I have to remember.
NAT is a nightmare that has directly lead to the crappy world of every "IoT" device relying on some remote service that can shut down any time, instead of just... connecting to your device. Also every game having connectivity issues when trying to do peer-to-peer play. Not to mention a reliance on NAT as security, something this article advocates for, despite being a job it isn't good at.
The obsolescence of NAT is the bit of IPv4's demise I look forward to most.
This is true... but the security impact of NAT is negative. It provides no security benefit, but it does confuse people about the security properties of their network, often providing a false sense of security.
How so? Allow established, then drop. You know. The same rules in ever consumer level router on the market now.
Kinda scary/weird
This one probably is the best
"The world in which IPv6 was a good design" https://apenwarr.ca/log/20170810
It's interesting but that doesn't make it right. v6 was a good design in our world.
Remember that the IP layer exists for the purpose of routing and aggregation. Instead of tracking the current location of every machine on the planet, we bundle them into networks, and then bundle those networks together, and then bundle those bundles together too, and so on. There are maybe something like 10 billion devices that are either on the internet or that want to be on it, but with all the aggregation we're only tracking about a million routes at the global level.
This aggregation is critical for allowing the internet to scale to planetary size... but it also results in the vast majority of the addresses in the address space not being assigned to any end machine. In other words, having N in-use addresses needs a lot more than log_2(N) bits of address space.
There's likely to be less than 2^64 devices on the internet in the long run, so if we could assign one address to each of them and not have to worry about routing table sizes, then a 64-bit address space probably would be enough. But that doesn't describe IP addresses... it describes MAC addresses. And MAC addresses are in fact 64 bits long for new L2 protocols today.
Since L3 needs aggregation, which results in most L3 addresses being unused, it follows that we need more than 64 bits of L3 address space to handle the 2^64 devices that the 64-bit L2 addresses can handle.
What exactly is complicated, using hexadecimal in addresses? The IP packet format itself is as simple as ever, and management things are done in a more elegant way (ND runs over ICMP rather than ARP being sort of there on the side not-in-IP-at-all).
> not backwards compatible
Massive service providers like T-Mobile US who use NAT64 as the only way to connect to v4 hosts anymore would disagree.
> doesn't actually solve the NAT problems for home users because of how ISPs work in the real world
My ISP delegates me a /56. How else do ISPs work in the "real world"? I've heard of some giving out smaller networks but never something egregiously small.
That isn't the complicated part, but thanks for strawmanning that as hard as you possibly could.
> My ISP delegates me a /56. How else do ISPs work in the "real world"? I've heard of some giving out smaller networks but never something egregiously small.
It's got nothing to do with the size of the address space, it's that they insist on changing it constantly which invalidates firewall rules and any non-dynamic DNS.
Don't get me wrong, even though my speeds are only about 50% of spec (gigabit symmetric), the upload speed alone is a reason to avoid any other provider. I'm also paying about $25/m less than the equivalent download on Spectrum.
I would rather have 700mb/s more for upload than ipv6 to be honest (only thing I also have public/static ipv4, so maybe that I wouldn't give up ^^)
Traffic stats encompass all Facebook properties, FB, Instagram, WhatsApp (hence India topping adoption charts), Oculus, and all smaller things that used some kind service delivery tech of Facebook infrastructure (DNS, web—not limited to CDN, MQTT, etc)
It was very interesting,on, how many online (web?) services actually supported end-end ipv6 like YouTube or Facebook etc , right when they started . (~2015/2016) [1]https://datatracker.ietf.org/meeting/109/materials/slides-10...
It's definitely going to drop back below 50% over the next week or two, although I suspect the base level will go over 50% at some point this year.
If you don't need a tunnel it should be pretty painless, just set up firewall rules and enable IPv6 forwarding
I'll check it out!
But here fixed networks are being actively shut down. Mobile connections are cheaper and faster.
(That does not hold for fiber, but fiber is still not widely available. And with the dominance of mobile I am not sure that this will change quickly.)
I have a 10/10 score.
It's likely not the peering points creating the difference at this stage. Initially they created a difference in favor of v4, now they are about equal, and later they will create a difference in favor of v6. For the moment the directness of v6 to being routed out vs v4 being sent to some centralized translation entity then being routed out is the likely culprit. Particularly since these numbers are driven primarily by mobile carriers who sometimes don't even have native v4 to the end user at all.
10ms does seem like a lot though. Maybe a remote lookup? Or something to do with prefering IPv6 with a small delay (happy eyeballs related?)
Some ISPs (I'm thinking of T-Mobile, but presumably they aren't the only one) centralize their CGNAT routers, whereas v6 traffic is handed off more locally since it doesn't need to be NATed. v4 traffic may need to travel further on those ISPs.