It's worst sin is neglecting the obvious need for a transition mechanism
If its worse sin is not doing the impossible, then it's doing pretty good: you can't talk between v4 and v6 hosts because of the pigeon-hole principle. There's just not enough space in the v4 dest header to fit a 128-bit address.
If you have a brilliant idea for getting around that, please do share.
I believe compassion is necessary trait in order to work well in a community.
We'd better make damn sure these AIs want to work well in a community, then. Preferably our community. And if it evolves, make sure it continues to want that.
That's a hard problem, and it's the one these scientists are worried about.
"Just". I'd rather be told if my packets are reaching the remote end or not, rather than have to break out a microscope and go hunting. Assuming I even have enough access at both ends to do that.
Yeah, typing them out's a pain. I wish we could have a shorthand format like "~::2" which took the first N bits from your current network prefix. But I almost never type v6 addresses; it's usually DNS, or then copy/paste if I really am dealing with IPs for some reason. For that matter, I don't even know the v4 addresses for most of my machines -- I could give you the subnet, but I have no idea which IPs are which.
For what it's worth, v6 assignments currently start with 2001 or 2{4,6,8,a,c}0*, which is pretty similar to the well-known RFC1918 ranges. And you'll see your own prefix often enough to remember it, hex or no hex.
I figure that the port scanner doesn't really care how long it takes to run, but I really appreciate getting proper error messages back from programs when my firewall blocks stuff. You could perhaps involve "-m recent" and start dropping when too many connections come in from a single source.
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.
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.
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/64s available... for each person on the planet. And each/64 has essentially no limit on the number of hosts it supports. I could understand an argument that each person might end up running billions of computers (which would be no problem at all), but a quarter of a billion networks? Each?
And that's just using the 2000::/3 space. There are five more unused/3s available, so we could do it all over again five more times (presumably with smaller-than-/64 subnets) before actually running out.
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.
So, with the third party out of the equation, how does one know that the security certificate you receive from random-site.com is the one that random-site.com intended you to receive?
By comparing the fingerprint with the list of valid fingerprints for the site, as published by the site via DANE.
I don't know that. It should be perfectly possible to make a machine that can drive as well as, or better than, a human can. Have we managed to make that already? I don't know, but from the info Google have been publishing, it actually looks like we have, or are pretty damn close.
Just because it's a machine doesn't automatically mean that it sucks at making decisions. Humans are machines too, and we let them drive.
If it would boot your Linux distro it'd also boot whatever malware was trying to trojan Windows and that's exactly what they're trying to avoid
No it's not. Malware is the excuse, much like child porn or terrorists are the excuse for internet filtering (and more or less anything else you want to force through as a law these days).
The real goal is to make it as hard as possible to switch away from Windows.
I might be guessing wrong here, but I'm thinking the primary intention of these new TLDs was to earn ICANN shitloads of money. It costs $185,000 just to apply for one, and $25,000/year to keep it.
Every Fortune 500 company doing the same thing would be a dream come true for them.
Slashdot Mirror
It's worst sin is neglecting the obvious need for a transition mechanism
If its worse sin is not doing the impossible, then it's doing pretty good: you can't talk between v4 and v6 hosts because of the pigeon-hole principle. There's just not enough space in the v4 dest header to fit a 128-bit address.
If you have a brilliant idea for getting around that, please do share.
I believe compassion is necessary trait in order to work well in a community.
We'd better make damn sure these AIs want to work well in a community, then. Preferably our community. And if it evolves, make sure it continues to want that.
That's a hard problem, and it's the one these scientists are worried about.
And so would I if I absolutely had to -- I'd even remember the v6 addresses -- but I don't. My life is easier than that.
We can't refuse to do v6 because "DNS is hard"; v4 with NAT everywhere is way harder.
"Just". I'd rather be told if my packets are reaching the remote end or not, rather than have to break out a microscope and go hunting. Assuming I even have enough access at both ends to do that.
Yeah, typing them out's a pain. I wish we could have a shorthand format like "~::2" which took the first N bits from your current network prefix. But I almost never type v6 addresses; it's usually DNS, or then copy/paste if I really am dealing with IPs for some reason. For that matter, I don't even know the v4 addresses for most of my machines -- I could give you the subnet, but I have no idea which IPs are which.
For what it's worth, v6 assignments currently start with 2001 or 2{4,6,8,a,c}0*, which is pretty similar to the well-known RFC1918 ranges. And you'll see your own prefix often enough to remember it, hex or no hex.
I figure that the port scanner doesn't really care how long it takes to run, but I really appreciate getting proper error messages back from programs when my firewall blocks stuff. You could perhaps involve "-m recent" and start dropping when too many connections come in from a single source.
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 /64s available... for each person on the planet. And each /64 has essentially no limit on the number of hosts it supports. I could understand an argument that each person might end up running billions of computers (which would be no problem at all), but a quarter of a billion networks? Each?
And that's just using the 2000::/3 space. There are five more unused /3s available, so we could do it all over again five more times (presumably with smaller-than-/64 subnets) before actually running out.
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.
So, with the third party out of the equation, how does one know that the security certificate you receive from random-site.com is the one that random-site.com intended you to receive?
By comparing the fingerprint with the list of valid fingerprints for the site, as published by the site via DANE.
Of course, browsers refuse to implement that...
I don't know that. It should be perfectly possible to make a machine that can drive as well as, or better than, a human can. Have we managed to make that already? I don't know, but from the info Google have been publishing, it actually looks like we have, or are pretty damn close.
Just because it's a machine doesn't automatically mean that it sucks at making decisions. Humans are machines too, and we let them drive.
If it would boot your Linux distro it'd also boot whatever malware was trying to trojan Windows and that's exactly what they're trying to avoid
No it's not. Malware is the excuse, much like child porn or terrorists are the excuse for internet filtering (and more or less anything else you want to force through as a law these days).
The real goal is to make it as hard as possible to switch away from Windows.
I might be guessing wrong here, but I'm thinking the primary intention of these new TLDs was to earn ICANN shitloads of money. It costs $185,000 just to apply for one, and $25,000/year to keep it.
Every Fortune 500 company doing the same thing would be a dream come true for them.