APNIC's stats check for that. For the US, it makes the difference between 58.74% capable and 57.85% preferring, so it doesn't produce a huge discrepancy.
683 karma · joined June 6, 2012
You can look at the AS breakdowns on APNIC's stats and see that ASs that serve non-mobile customers are getting v6, and that some ASs for mobile users aren't. So no, it won't stall.
Slow down perhaps, but it has to slow down at some point or it'll go above 100%.
v6 has optional leading zeros and ":: splits the address in two where it appears". v4 has field merging, three different number bases, and it has optional leading zeros too but they turn the field into octal!
The network my desktop is on doesn't use v4. It works. v4 isn't a required dependency.
If they only got one shot at changing HTTP, do you think they would have tied TLS to HTTP/2 or given up on HTTP/2 altogether?
The problem is that you can't use those bits to expand v4's address space, without taking all of the same steps v6 needed to do. v4 has no mechanism to get v4 hosts to understand extra address bits, wherever you put them.
Oh, that and the fact that IP addresses are stored in many more places than just the v4 packet header. Consider DNS, DHCP, ARP, gethostbyname(), struct sockaddr_in, databases using VARCHAR(15), etc etc etc. The packet header is only a tiny part of the story.
But for another, the v4 space is available as a subset of the v6 space:
$ ping 64:ff9b::8.8.8.8
PING 64:ff9b::8.8.8.8(64:ff9b::808:808) 56 data bytes
64 bytes from 64:ff9b::808:808: icmp_seq=1 ttl=113 time=9.82 ms
Half of the Internet is using v6. If a lack of firewall was as common or as dangerous as people think, the supposed security disaster would have already happened. It hasn't.
The only caveat is that if you're using RFC1918, it greatly limits who can connect -- only your ISP, or another customer connected to the same shared VLAN your router is, or anyone that can physically attach to that network (or anybody in a position to order, blackmail or social engineer those three groups or their employees) can do it, because they're the only people that can set a route to your router for RFC1918 destinations.
Other than that, the connection will just head right on through your router. NAT's whole thing is to change the source address of your outbound connections. Inbound ones (when they don't match port forward rules) are ignored by it, which means they get routed by the router in exactly the same way they would if the router wasn't doing NAT.
At best you could argue that RFC1918 blocks connections, which would be somewhat closer to true, but... well, it doesn't. If you actually want to stop all connections from outside your network, you've always had to do it with a firewall on the router.
And of course, I said "if". You can NAT on public IP space. On residential connections you're unlikely to have public IP space on v4, but that's just a consequence of v4 being exhausted.
Layer 3 of the Internet is the one that requires support in all software and on all routers in the network path, and those are run by millions of people in hundreds of countries with no central entity that can force them to do anything.
HTTP->HTTPS is only similar in terms of number of users, not in terms of the deployment itself. The network effects for IP are much stronger than for HTTP.
They don't "sorta" use v6, they're properly using it, and you can certainly go v6-only. I'm posting from a machine with no v4. Also, if you want to go there: HTTPS was released before IPv6, and yet still no browser is HTTPS only, despite how much easier it is to deploy it.
And no, proxies were either never obsoleted or they were obsoleted by routing. Nothing to do with v6.
It, um. No, it doesn't do that. You can use proxies and VPNs in v6, and you're about as trackable by IP as you are on v4.
We've never done something like the v4->v6 migration before, on this sort of scale. It's not clear what the par time for something like this is. Maybe 30 years is a normal amount of time for it to take?
Each v4 address has a corresponding /48 of IPv6 tunnelled to it. The router with that IP receives the tunnelled v6 packets, extracts them and routes them on natively to the end host. This is something that v6 already does, so you don't need to make posts complaining about how dumb they were for not doing it.
The only reason those networks aren't exposed to the whole Internet on v4 is because they're using RFC1918, not because of NAT -- but that still leaves them exposed to some outside networks, so routers come with firewalls, which act as an actual security boundary.
And they won't be exposed on v6, because those exact same firewalls work their magic on v6 too.
NAT doesn't provide and isn't needed for security. Its main security contribution is to confuse people about how secure their network is.
I mean, yes, you'll get a constant stream of them on IPv4, but why would you run a server on v4 unless you absolutely needed to? The address space is so small you can scan every IP in 5 minutes per port, and if you have my v4 address you can enumerate every single server I'm running just by scanning 65k ports.
Meanwhile, on v6, even the latter of those takes a thousand years. How would people even find the server?
NAT is about dealing with address space shortages, not security.
v6 is about as backwards compatible with v4 as it's possible to be. If you have a way to make it more backwards compatible then I'd love to hear it, but when I ask this all I ever get are things that don't work, or things that v6 already does.
Also... the ability for people to deterministically reach out to a specific device on your network is the exact same ability you use to deterministically reach out to specific devices on their networks, just viewed from the opposite side. If the Internet wasn't a place where people could decide to run services on their networks and connect to services that other people ran on their networks, what would the point even be?
IPv6 supports customer-controlled prefix rotation. You can select how often it happens by configuring your router to periodically change its DUID. Of course, your ISP can ignore this signal and always assign the same prefix anyway, but you can hardly blame that on IPv6.
(Ideally your ISP would be running NAT64 for you, especially if it's a VPS provider only giving you v6, but for whatever reason few of them do...)
They didn't use the reserved bit, because there's a field that's already meant for this purpose: the next protocol field. Set that to 0x29 and it indicates that the first bytes of the payload contain a v6 address. Every v4 address has a /48 of v6 space tunnelled to it using this mechanism, and any two v4 addresses can talk v6 between them (including to the entire networks behind those addresses) via it.
If doing basically exactly what you suggested isn't enough to stop you from complaining about v6's designers, how could they possibly have done any better?
On v6, you don't use NAT and networks are /64. Finding every server requires scanning 65536 ports on all 2^64 IPs, which is about 72 billion petabytes of traffic. There are ways to prune this down somewhat, but however you do it the search space is still far larger.
If you want attackers to not know what's behind your router, you want v6.
"the :1 is short for :0001 basically" is easy enough: you get 2001::0001::0001.
Then "just put that bit at the very end" -- but which bit? If it means the ":0001", then there's two of them and they can't both go at the very end. If not, then it fails to specify which bit. Either way I don't see how these instructions are followable at all, let alone easily.
If setting your client machine MTU to 1280 (`ip link set mtu 1280 dev eth0` or equivalent) magically fixes it, that's your problem.