And I've only ever had v6, both on DOCSIS and fiber. Both observations are pretty useless in the grand scheme of things; actual adoption rates are what matter.
> At this point it would be best to recognize the sunk cost and give up on the migration.
That's a pretty wild thing to say in the comment section of an article about v6 reaching 50% eyeballs-side deployment.
How would several billion smartphones be able to connect to the Internet without IPv6?
There isn't enough RFC 1918 (or 100.64.0.0/10) space for IPv4-only to be practical: Comcast—not even mobile—went to IPv6 because running their TR-069 management over multiple 10/8 became untenable.
IPv6 is making all sorts of things possible without most people realizing it.
> Those phones are reaching half the internet via 64 gateways, no difference to reaching via 44 gateways.
And how would they have gotten first-hop connectivity without IPv6?
Comcast added IPv6 many years ago on their wired ISP side because they ran out of IPv4 for TR-069 management, and they had way fewer subscribers (at least at the time) than many mobile telcos.
And that half of the Internet is also some of the most bandwidth intensive stuff: Youtube, Netflix, Instagram. The CG-NAT hardware costs of streaming would be huge.
The network isn't just the open internet. There's also the part inside the network. You can view Comcast as a black box that magically gets packets from one side to the other, but Comcast engineers can't.
If you want to run a single massive scale network sure. One of the costs of scaling that the majority don’t see
No reason you can’t carry IPv4 over any protocol you want. Multi tennant vxlans can carry whatever you want over your base network. Maybe an IPv6 underlay makes sense there, doesn’t really matter
> I don't think this is inherently a problem. [...] My router for example has a similar UI to forwarding a port with IPv4 and opening the port for IPv6.
Glad to hear that you don't have a problem with your router, but how does that relate to GPs problems with theirs?
The solution for them is "get a better router" because the problem is not the IPv6 protocol. Opening a port is not harder than creating a NAT forwarding and if your hardware can't do it then it's bad.
The point of local networks of a minimum size of 64 bit isn't only to have MAC-based addresses (48 bit would have been enough for that, fwiw), but in general to support non-coordinated/probabilistic self-assignment schemes with negligible collision probability.
Picking a random local address (which is very important for privacy, as you've mentioned) is much easier if you don't have to do an elaborate dance of listen, announce, listen for collisions etc. first (practically that still happens, but collisions are the absolute exception).
> So is the bigger address range better?
Yes, because consider the alternative of re-doing all of this again in a future in which IP usage for some reason jumps by a few orders of magnitude again.
Due to hardware getting better over time, the per-packet cost of a few extra bits is going down all the time, while the cost of rolling out a future IPv7 increases with every new deployed host.
The best thing about SLAAC is that it forces your ISP to give you at least 64 bits. Otherwise you know Comcast would only give out a /128 and charge you for more, so you'd use NAT at home just like IPv4.
Unfortunately SLAAC doesn't force upstream to provide a /64 universally.
Some ISPs are reportedly giving out a /128, and SLAAC works adequately with a router performing IPv6 NAT, so those ISPs don't see a problem.
Mobile phone as WiFi access point is another common way people access the net nowadays. I've occasionally seen permanent installations, with a phone taped to a window. I've never seen a mobile phone AP offer IPv6 to clients, but if they do they have to use SLAAC-compatible IPv6 NAT in that situation.
> Some ISPs are reportedly giving out a /128, and SLAAC works adequately with a router performing IPv6 NAT, so those ISPs don't see a problem.
Wow, that’s diabolical. Presumably these routers are some custom CPEs then? I don’t even know whether regular home routers support NAT66.
> I've never seen a mobile phone AP offer IPv6 to clients
I’ve only even seen it work without NAT when there was any v6! Usually the phone gets a /64, and there is a bit of trickery involved to make that shareable to other devices (NDP rewriting), but it works pretty well.
> This becomes noticeable when pipelines on IPv6 connected servers suddenly have random request/post failures to public services. Then either the whole service is temporarily having issues or there are a few bad IPv6 endpoints while all the IPv4 endpoints are fine.
Do you have examples for this? I've never experienced this, and I've been using IPv6 for years.
Also, how can you be sure that the same request to IPv4 would have been fine? Did you actually see consistent failures on v6 and consistent success on v4? Otherwise, if a service has a reasonably low error rate, success on retry is the expected outcome, regardless of the path the retry takes.
There were indeed consistent failures to specific IPv6 endpoints, clearly identifiable through curl, while all the IPv4 endpoints were ok.
This happened with pypi (IPv6 BGP routing problem caused by a bad route from one of our peers combined with their fastly CDN not reply to us on IPv6 from the other side of the ocean for some weird reason), but also with yum and apt mirrors (seemingly random problems with the IPv6 service or firewall of the remote endpoint), and various other web resources accessed from pipelines.
The solution always was to temporarily block the bad IPv6 endpoint(s) or temporarily completely disabling IPv6 on the server itself or on the squid proxy server for workloads without direct connectivity.
Obviously it also can be the other way around, but in practice it appears to happen less often with IPv4, and if it does things get addressed quickly instead of taking hours or days or weeks.
Open source download mirrors often have much better targetting for v4 than v6. Just a few days ago, I was downloading installer images to check an issue and adding -4 to the command line reduced the download time significantly.
This works in many countries, since the signalling protocols historically assumed a trusted small set of participants, not unlike email – with similar consequences once those assumptions became less and less true.
Was just going to ask if anyone remembered the name of this one. It was amazing! 15 year old me felt very important/futuristic syncing the news before school in the morning and reading during school break!
Edit: after looking it up with plucker as a starting point I think the one I actually used was AvantGo, same idea though I think.
I worked on a real estate app. We added mobile support by generating a static website from the database, including listing previews and stuff. Realtors were amazed that they could have the entire database that looked like a full website. That was fully offline. Plucker made it possible
I haven't had an outright rejection, but definitely a few odd moments with call center agents. "theircompanyname@myname.com" is definitely not the default expectation :)
How would proof even look like? I don't think AWS digitally signs their invoices, and everything else can be faked just as easily as the original assertion.
A person bumps into at the train station. They just need $5 to get home. Could you just spare them $5? They had the money, but they lost their wallet and now they just need to get home.
Not sure I’d call that “stopping wasting my tokens”.
reply