Ah, yes. When I said:
I run v6 everywhere and I've never had any problems reaching other v4 hosts
I meant to say:
I run v6 everywhere and I've never had any problems reaching other reachable v4 hosts
Sorry about that.
Because it's not big enough to number all our hosts?
I can reach the hosts that have v4 over v4, but not the ones that don't.
It's less TCAM overall, because of the large address space: you only need one v6 allocation to cover what ends up being thousands of separate tiny allocations in v4.
According to this video at 18:44, Comcast measure v6 on their residential deployment (the one in this world) as being slightly faster than v4. I'm not sure if that's a precise enough platform specification for you, but there it is.
Is this really that difficult?
203.0.113.168+192.168.1.2 vs 2001:db8:71a8:1::2
203.0.113.168+192.168.1.3 vs 2001:db8:71a8:1::3
203.0.113.168+192.168.1.4 vs 2001:db8:71a8:1::4
203.0.113.168+192.168.1.8 vs 2001:db8:71a8:1::8
203.0.113.168+192.168.1.9 vs 2001:db8:71a8:1::9
203.0.113.168+192.168.1.10 vs 2001:db8:71a8:1::10
The v6 side is shorter! Plus of course I'm totally ignoring DNS, which is the elephant in the room here. Use DNS. This is exactly what it's for.
It's actually not much of a problem. I run v6 everywhere and I've never had any problems reaching other v4 hosts.
Why? Because I also run v4 everywhere and use that to reach v4 hosts. This is extremely easy to do: you just deploy v6, and then don't undeploy your v4, and there you go. v6 works over the same network topology as v4 does, so you can easily run both.
This also has the advantage of not being impossible.
I don't buy this argument: tech people manage to remember their v4 addresses today (which usually consist of a pair of 32-bit addresses for each host), so they ought to be able to remember their v6 addresses (which consist of 48-56 bits of prefix plus 8 bits of host ID, with the rest of the bits being zero).
Unless they pick a horrible nasty address that's not mostly zeros, but if you pick a nasty unrememberable address and refuse to use DNS for it then you can't really complain about how nasty and unrememberable it is.
It isn't particularly hard. Just drop connections that come from the internet by default. Something like this in ip6tables on the router:
ip6tables -A FORWARD -p icmpv6 -j ACCEPT
ip6tables -A FORWARD -m state --state INVALID -j DROP
ip6tables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i eth0 -o ppp0 -j ACCEPT
ip6tables -A FORWARD -p tcp -j REJECT --reject-with tcp-reset
ip6tables -A FORWARD -j REJECT --reject-with icmp6-adm-prohibited
Basically it's exactly the same as you do on v4, except you don't add a -j MASQUERADE rule. You can open holes in it by doing:
ip6tables -A FORWARD -p tcp -d <dst IP> --dport 3389 -j ACCEPT
or even something like:
ip6tables -A FORWARD -p tcp --dport 22 -j ACCEPT
to allow inbound ssh to all machines at once.
It's not that it wasn't considered. The biggest problem with interop between v6 and v4 is that you can't really do interop between v6 and v4. The v4 header only has 32 bits available for the dest host, so there's no way to specify which v6 host you want to send packets to.
Unless you count NAT64-like solutions or 6to4-like solutions, both of which do already exist.
And IPv6 still has the same shortsighted flaws for futureproofing as IPv4; It lacks extensibility. Sure it looks infeasibly big now, but they keep saying that and then we find we run out of space. It wasn't that long ago when a terabyte was considered unbelievably big yet now computers routinely come with drives of such capacities!
It does lack a way of expanding the address space, but we'd need to actually run out of space first for that to be a problem, and 128 bits really is a lot. 1 TB drives and v6 are in completely different ballparks: if v4 is 1 TB, then v6 is 80 million billion yottabytes. There are 300 million
And that's just using the 2000::/3 space. There are five more unused
A single subnet? That's not enough for a lot of people.
Everybody with a guest wifi network, for instance.
There are, however, conceivable reasons why they might not want to (or be able to) give that $5 to Valve.
I'd say the main purpose is to encrypt more stuff, and "not throwing a wobbly when you see a self-signed cert" is just a part of that. (Since you can't just turn off cert warnings and be done with it; you need some way to enable encryption without enabling authentication.)
It's not just for forms, or whatever "submit" was supposed to mean. All HTTP requests to the site except for the first one (per session? I'm not sure how long these headers are cached for) will go over TLS.
No, we created it to make it actually possible to do unauthenticated encryption with self-signed certificates on public websites. Currently, nobody uses self-signed certs because of the invalid cert warnings.
<meta> tags or HTTP headers are sent after the SSL negotiation, so neither of them can change the negotiation behavior. (Putting text on the page telling people to ignore the warning doesn't work either, because they'd need to ignore the warning just to see the text.) The only way a new header is going to work is if you use http:// for the first request, and then include a header that tells the browser it can pull the same pages over TLS, but without doing authenticity checks on the certificate.
Which is pretty much how this Alt-Svc header works.
Valid certificate not required. In particular this means you can use self-signed certs without a big massive warning.
Obviously a valid certificate via https:// is better, but if your choice is between a self-signed cert that throws a big warning and unsecured http://, you're going to choose the latter. Alt-Svc adds the option of delivering your http:// site over an encrypted connection.
(Nitpicker's corner: yes, the connection will be unauthenticated, which yes, means an active MITM can still read the contents. An active MITM is harder to pull off than passive sniffing, is obviously more evil, and is detectable, which makes this better than unsecured HTTP even if you don't get 100% perfect protection with it.)
If you're at the point where you can insert arbitrary HTTP headers into a connection, you don't really need to insert a header that causes the client to make requests from one of your own servers in order to sniff the data in the connection. Just sniff the connection.
It's the same third party that lets you have random-site.com rather than an IP, so you're stuck with them anyway.
To thine own self be true. (If not that, at least make some money.)
