That's not what it says. It says that the capacity at 200 cycles is 1.5x a current cell. No mention is made of the point at which the capacity of these cells drops below the capacity of regular cells, if indeed such a point even exists: it's entirely possible these cells have roughly the same performance vs cycle curve as current cells after 200 cycles, just with a generally higher capacity.

I suppose you might raise the question of why they limited their testing to 200 cycles rather than more, but I note that if each charge/discharge cycle takes 4 hours then 2000 cycles would take almost a year to complete.

~3.8 GB, apparently.

What?

No, SLAAC isn't used with link-locals -- link-local addresses are assigned automatically by the host. It's used with whatever the network range on the segment is, which will usually be a global unicast range, or sometimes ULA. That's where it's supposed to be used, it's a normal way to do v6 and it works just fine.

Maybe. But on the other hand, even active servers spend a lot of their time idle (the paper says server utilization "rarely exceeds 6%"), and I bet a lot of these "comatose" servers are actually long-forgotten old hardware, or machines that nobody can be bothered to decommission -- it's possible that on average they're older than active servers and thus eating a lot more power.

You'd know the difference, because the fingerprint of the cert wouldn't match the one in DANE.

Except nobody supports that, because closing that particular hole apparently isn't important...

You can sign SSL certificates without ever knowing the private part of the cert, so it's possible to set things up such that it's obvious that they're not leaking the private part of your certs to the NSA.

Whether they will actually do that or not remains to be seen.

Yes, you said that already and it was already a given, but what new thing can the host do now that it couldn't do before that allows it to send packets to a v6 address?

Remember, the host is still connected to the v4 internet, and it still has no v6 internet connection. It has to send v4 packets. What v4 packets can it send to reach v6 hosts?

No, because all you're still doing is telling me it'd work without explaining how.

Even with upgraded software on B, the v4 dest field is still too short for v6 addresses. This is the whole problem in the first place. How does the software upgrade help? What does the software upgrade actually do to work around this?

It's really that simple. It's not about IPv4 connecting to IPv6 (that would be forward-compatibility, which is impossible in that case) but the other way around.

Okay, here's the critically important thing: these are no different to each other!

Remember, at the IP level, there's no such thing as "connections". There's no state. It's all just packets being sent from a source address to a dest address. So we could put v4 into a v6 prefix, and v6 hosts would be able to send packets to existing v4 hosts -- this would work just fine. But those v4 hosts could never respond. They can't fit the response address into their dest field.

And because that's not possible, you can't make a TCP connection or hold a UDP conversation. The ability to "yell at the existing v4 internet but never get a reply" just isn't going to be enticing enough to get anybody to drop their v4 connections. Basically, the v6 designers didn't do it because it was pointless to do.

And then what? How would that lead to an inter-compatible v4 and v6? You're right that I don't get it; please explain it to me.

How would an existing v4 host at w.x.y.z be able to send to a v6 host at a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p? This seems like an entirely technical problem to me, and you can't normally just define your way out of those.

How would you actually go about doing this though? I've seen lots of people go "IPv6 is retarded, they should've just added some extra numbers to the end of v4", and it's very easy to just sit there and say it, but none of them have explained how they could've done that and actually had it work.

Please, be the person that explains it to the world, if it's so obvious to you: how the heck do you beat the pigeonhole principle?

For what it's worth: they don't take it. Your browser tracks your history (as it has always done, unless you've turned that off), and makes the decisions of which adverts to display locally.

Mozilla can attempt to infer your browsing history from which adverts you load (and I've seen discussions about trying to reduce the amount of information they receive, although I don't know how much of that actually made it to the implementation), but they don't get a copy of it. Only your local browser gets that.

It is, but you'd achieve a much higher resistance to precalculation attacks just by generating and sharing a longer key in the first place -- which also has the advantage of not burning hours of CPU time on every single machine.

Perhaps the best thing to do here would be for each system to download DH parameters (or get them from a package or whatever) at installation time, and then regularly change the parameters that are available for download. That avoids the massive generation time on each machine, but also limits the amount of machines that you share parameters with. So long as those parameters aren't tiny, that should be fine.

Bonus points if you include a simple "make_me_my_own_dhparams" script that makes generating your own parameters trivial, but I do think we can get most of the benefit here without requiring every single install to use it.

So... generating new DH parameters on each connection leads to connection latencies of up to a few hours, which isn't really viable?

Also, what are you trying to protect against by regenerating the key frequently? We normally cycle RSA keys every year or two because of the risk that someone might break into the server in that time and steal the key (and we don't want the stolen key to be valid forever), but that's not an issue with DH parameters because they're public anyway.

The other reason to regenerate frequently is to limit the window of opportunity for brute force attacks, but that doesn't make much sense either: instead of generating lots of small keys, just generate one bigger key in the first place. It'll take far less CPU time and yet still be far harder to brute force.

It takes my (2009 era) machine 5-300 minutes (it varies wildly depending on how lucky you get) to generate a set of 4096-bit DH parameters. And that's actual CPU time, not "sitting around waiting for the Linux entropy pool to regenerate" time. You're going to have to make some tradeoffs here.