I wish my fiber ISP was part of that 50%. But nope, here I am behind a CGNAT and was promised IPv6 adoption about a year ago. Unfortunately the only other options in my area (downtown Milwaukee) are some form of wireless, DSL, or Spectrum.
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.
Shit Italy adoption sucks, that's so curious like I am 34 years old now but I think I've used IPv6 since I was like 13-14 years old, with tunnels like sixxs and before that there was also another one I forgot the name of, now my italian provider (fastweb fiber) supports it natively, but yeah just wondering now, we sometimes say that tech world changes fast, but can you imagine like how long things like ipv6 have been around, and still haven't had much of an impact from a practical point of view? Like I have a book of abount 150 pages that talks about IPv6, can you imagine that like every year I have to read it again because I just can't seem to retain the knowledge? Not just if it is just like something like XML too focused on machine and not very human friendly, or if it is like unmnemonic, or that you don't get in contact with it ever.. it's so curious for me
Before everyone laments their ISP is part of the slow half remember the majority of this migration is still driven by the switch to users browsing on mobile device networks rather than a traditional desktop on a hardline. E.g. T-Mobile is IPv6 only for a number of years now, using 464XLAT to let customers access IPv4 only services.
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?
In 464XLAT something on the client side (be it say Android phone itself or TMobile home router) acts as a CLAT to translate local v4 to v6. On the T-Mobile egress it'll act as a PLAT and convert back. There is some other glue to make these two work together. They had a good NANOG talk on it a few years back https://youtu.be/Xl-hIyZSAmA
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.
That's interesting. We use a Sierra Wireless EM 7455 (IIRC, not in work mode now...) with generic global firmware. I am 100% sure our software performs no 4 to 6 translation. So it would need to be in the modem. But that would mean it needs to be a standardized operator-independent protocol. Never heard that such thing exists.
> 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.
464xlat is standardized and can be set up automatically. All it needs is a DNS query to any v4-only hostname to detect if DNS64 is in operation.
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.
About 5 years ago, I asked the owner of my fixed wireless ISP if he was planning to support IPv6 and I received a 500 word email rant about the uselessness of v6. I haven't asked again. (I still get a 0/10 score at https://test-ipv6.com/)
There is a lot of cultural inertia that instantly biases against anything new in sysadmin/netadmin circles.
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?"
There is a lot of cultural inertia that instantly biases against anything old and stable in developer circles.
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.”
Sure, that's annoying too, but I don't see how it's relevant to the topic at hand. IPv6 isn't some shiny new tech, the original RFC just turned 26. It's also not just a superficial re-write of some existing tool, it fixes a real problem which clearly needs to be addressed (no pun intended).
I wish v6 just tried to fix things. The problem with v6 was that it also tried to do thing in a right way and broke too much compatibility. And then it turned out what was right in 1995 was no longer so for the last 10 years.
It mostly only broke the things it had to break. v4 isn't forwards compatible to longer address lengths, so the lack of compatibility isn't the fault of any aspect of v6's design.
v6 128-bit address was an attempt to simplify the routing. The was fear that with big routing tables that v4 stated to require 25 years ago the performance would collapse. In practice it never became an issue. Yet with smaller address space, like with just 48 bits, connecting from v6 to v4 address would be possible with much less complex nat.
That was part of it, but there was also a desire to be very sure we had enough address space to avoid needing to go through this again. SEND and privacy extensions also make use of the 128-bit address to add some security.
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.
I agree my response isn’t directly relevant, I’m just tired of seeing the same tropes over and over again about how Ops people’s only motivation is to drag their feet on everything just because they’re old and out of date. They actually have good reasons for having processes that appear to slow things down, for good reason.
One developer's "old and stable" is another developer's "filled with vulnerabilities that nobody will ever find let alone bother to fix because everyone assumes it's old and stable."
IPv6 has been a draft standard since 1998. Get a better argument.
Had this issue with a coworker who uses a decade old version of Linux and refuses to install anything other than base packages cus it's "Stable". Well I made an in house tool, and it's not stable, since his glibc had a bug that's been fixed for a decade that made it so pthreads would break. Everytime I tried telling him it's his system before someone else found the bugfix, he would go "YOU JUST DON'T KNOW HOW TO WRITE MULTITHREADED CODE! MAKE IT SINGLETHREADED AND FIND THE BUG!"
Just don’t want it forced on me and by its nature it becomes a hard dependency over time, thus, it does.
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”.
>Just don’t want it forced on me and by its nature it becomes a hard dependency over time, thus, it does.
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.
Don’t let this descend into another systemd thread. Just don’t lump all criticism against systemd as pitchforks, since it delegitimises complaints.
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.
> systemd is the choice of basically everyone who builds distros
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").
My ISP has offered ipv6 for almost 7 years. When ever I tried to you use ipv6 it was just a miserable shit show. Their support says everything is fine and in the support forums thing work fine for some and for some not so much.
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.
Reminds me of how people would get angry when you suggest a site should switch to HTTPS and people would demand you prove why it would be worth it rather than just doing it anyway since it's free and easy. Glad we have mostly moved past that.
> "What's this? I never needed it before, what's the sysctl to turn it off?"
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?
The value is that you don't get caught with your pants down when IPv4 addresses get expensive enough to shaping businesses' decisions. It's going to be a lot less stressful to come to grips with IPv6 now rather than waiting until it becomes a critical path dependency of some business goal.
"Our sires' age was worse than our grandsires'. We, their sons, are more worthless than they; so in our turn we shall give the world a progeny yet more corrupt."
On the contrary, the numbers of routes decline. Since you get a single IPv6 assignment, often a /48, you can summarize all your networks to that assignment. IPv4 is a mess in this regard. Small assignments to ISP's and businesses were made to be frugal and delay address space exhaustion. This has caused the address space to be very scattered. You can see at https://bgp.potaroo.net/index-bgp.html that IPv4 has about 900k advertised routes and IPv6 has about 150k advertised routes.
The IPv4 address space will fragment further now the price for IPv4 addresses is going up fast. Everyone with enough unused space will fractures their assignment and sell the unused pieces.
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.
Heh, well of course, if you have enough IPv4, there's not much IPv6 does for you.
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.
Because a firewall exploit means your thermostat is now controllable over the internet and you can conveniently preheat your oven over the internet too and now your house is burning down
> Every consumer router/firewall drops incoming packets by default, why would this be different for ipv6?
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.
> This isn't my experience. If you are correct however, that is a failure of the ISP/CPE provider, not a flaw of IPv6.
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.
Only when you're dependent on NAT for security. NAT isn't intended to be a security tool, and is pretty bad at mitigating against attacks that aren't just "log into this device directly." As others have said, a robust firewall and some good access controls and you'll be fine.
"anything inside my home network from anywhere on the internet" doesn't sound much like robust access controls.
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.
Robust access controls would be things like certificate auth, MFA is cool, fail2ban is good, maybe throw in some roles there; whatever floats your boat. So yeah, your security model should involve not using default passwords and not using devices that have unchangeable default passwords.
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.
I have checked it many times before and score was reliably 0/10 before. Seeing your comment I decided to check it out on this site and guess what today score is 9/10.
I’ve used ipv6 on xfinity for years, but I do use my own equipment. Unless there are regional differences it’s important to make sure it is set up right in your router.
You're absolutely right. I'm in the same situation. 10/10 ipv6, but it took a lot of configuration. I'm sure if the parent commenter connected their device directly to their modem via ethernet they'd find they had a functioning ipv6 address. Comcast is terrible for lots of reasons, ipv6 isn't one of them.
Am I the only one that hates IPv6 ergonomics? I have to transcribe IPv4 addresses all the time, I'd hate to try and do it with a 128 bit address. Could they not have gone with 64 bit addresses, was 18,446,744,073,709,551,615 addresses really not enough?
As said in another reply, I've been in contact with IPv6 for like 20 years and every year I have to understand it again I fully agree with you and would even say that even 48 bits could have done something with 281,474,976,710,656 values possible
SLAAC works well and wouldn't without a >= 64 bit subnet. In a typical /64 assignment, the ipv6 equivalent of the 32-bit ipv4 public ip is the 64-bit prefix, I think squaring the address space is appropriate.
Maybe a bit glib, but I see this as a good thing: a reason to finally fix whatever process requires you to transcribe IP addresses, which is a pain to do even with v4 ones.
Definitely not a pain for a LAN. Case in point: navigating to your router’s web interface. Very easy to do with IPv4 to do, a pain with IPv6.
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.
But in that case, that is considerably more difficult than just IPv4, as I now need to remember the prefix. Which isn’t stable, as it’s often reassigned by my ISP.
So routers should inject DNS for LAN devices, that's how mine is set up. Admittedly it can be a small pain with some browsers defaulting to DNS over HTTPS and bypassing the router's DNS, but that's pretty recent and fixable.
I go to `router.localnet`, not some IP I have to remember.
That article was really very optimistic about NAT traversal, while being very pessimistic about solutions to avoiding memorising IP addresses, which I think says something about their perspective going in.
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.
NAT not being designed for security does not negate the effect of security it does have. This goes to the 80/20 rule, IPv6 is a security nightmare if not deployed correctly, and I am surprised more home users have not gotten hit with this security time bomb
I feel that. I have a VPS that i run OpenBSD on.
I messed up my config and now my phone was publicly reachable via its /72 ipv6 from the /64 adress i was assigned.
> NAT not being designed for security does not negate the effect of security it does have.
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.
> Could they not have gone with 64 bit addresses, was 18,446,744,073,709,551,615 addresses really not enough?
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?
Heh, I'd argue that ZFS would be better if they went with 64 bits, especially since it's 2^128 blocks, not bytes, or bits.
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.
I did some calculations of my own. Assuming a index of size 2^64 and a block size of 256 KB, you could store 6,949,999,424,954 hours of 4k
REDCODE36 RAW 4K video @ 120 fps before you ran into problems.
That's the way it has been in IT for 6 decades. The problem is it's not sustainable. We ruin the planet by inventing ever new ways of wasting resources for new solutions to problems that mankind doensn't even have.
When was the last time you tried to memorize (or even type out) a ZFS block pointer address though? The ergonomics don't matter for ZFS, and so what's left to consider is address space exhaustion.
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.
If you need memorizable IPs, pick something like "2001:db8:2d4f:1::2", which isn't that much longer than the v4 equivalent of "203.0.113.45"+"192.168.1.2". In fact, it's five characters shorter.
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.
> 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.
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).
There are plenty of reasons to dislike IPv6 that are much less shallow. Like, it's overcomplicated, not backwards compatible, doesn't actually solve the NAT problems for home users because of how ISPs work in the real world, etc.
The problem is that IPv4 is not forward-compatible and not that IPv6 is not backward compatible.
There are things that map every IPv4 address to a IPv6 address, so from the IPv6-side it is backwards compatible.
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.
> What exactly is complicated, using hexadecimal in addresses?
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.
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.
There is an added benefit of 'security' every device in your home could have their ipv6 address and because it is 128 bit, it would be harder to guess or perform internet wide port scans.
At some %, some people will opt for cheaper v6 only VPSs. Perhaps hosting in countries starved of addresses will switch to v6 only as well. Or all v4 addresses will get given to servers and all consumers will be on some translation layer.
My ISP is apparently going to adopt IPv6 for fixed connections this year, so something to look forwards to. I think they've already had them for years for wireless.
Remainder that Cloudflare when using HCaptcha bot verification still do not support IPV6. It is impossible to solve it when you have a IPv6-only connection.
That's latency impact (vs v4) not just latency. -10 would mean IPv6 connections typically had better latency than IPv4 connections. This was more an concern during the early days of IPv6 deployment.
Exactly, but we are not in the early days anymore. So how is, in today's world, v6 "10ms faster" than v4? ISPs didn't magically create v6-only exchanges that happen to be in a more direct path to Google.
They're rounding the numbers, so presumably it could be anywhere from 5ms to 15ms.
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.
As a clarification the more we are not in the early days anymore the lower the IPv6 latency is expected to be so being this far along is a supporting reason not a how come.
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.
FWIW as a content provider to mobile heavy eyeball networks, Facebook has been clocking US v6 adoption consistently over 50% since Sep 2018.
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)
Yes, though realistically there is going to be an extremely long tail of things that need v4<->v6 NAT to get to that point and inevitably someone is going to use v6<->v6 NAT with some odd justification.
I have no answer to that. But I can answer why Finland has a high rate. Mobile connections have IPv6 like in most countries. For fixed ones it's impossible to get for consumer subscriptions.
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.)
163 comments
[ 2.2 ms ] story [ 214 ms ] threadDon'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 ^^)
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.
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
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.
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
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/
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.
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.
1. https://datatracker.ietf.org/doc/html/rfc2460
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...
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!
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.
I have a 10/10 score.
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!
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.
Kinda scary/weird
How so? Allow established, then drop. You know. The same rules in ever consumer level router on the market now.
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.
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.
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...
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...
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...
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.
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.
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.
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.
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)
https://www.facebook.com/ipv6/?tab=ipv6_country
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.)
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...