Going IPv6 Only [pdf]
pc.nanog.org
pc.nanog.org
Alternative data from Facebook -- https://www.facebook.com/ipv6/?tab=ipv6_country -- is quite a bit different but shows Belgium (50.45%) and India (50.27%) are both slightly ahead the US (49.28%).
It's very hard to measure IPv6 adoption. I would personally go with Google's measurements as I suspect the numbers are higher on Facebook because fewer people access Facebook at work, where those networks tend to have less IPv6.
June 16th (Sat): 23.91%
June 17th (Sun): 23.14%
June 18th (Mon): 20.10%
June 21 (Thu): 20.27%
June 22 (Fri): 21.30%
June 23 (Sat): 23.73%
June 24 (Sun): 23.01%
Home users tend to get IPv6 because their ISP's router got an update; it's largely invisible, so IPv6 traffic is higher on weekends, when fewer people are at work.
Edit: Also, I forgot to mention, this pattern breaks quite a bit for the holidays. Look at the data around December 25; you'll see lots of bumps, but it doesn't have that weekly crash happening on Monday.
a) You missed Belgium. (Common oversight, due to the size on the map.)
b) Google's stats have something of a US-centric bias; https://stats.labs.apnic.net/ipv6/ is a little less biased (which also shows Belgium and India in the lead).
Would you elaborate a bit on APNIC's data having less bias than Google? As far as I know, Google is quite popular worldwide, with the exception of China, so measurements taken on Google servers should give decent accuracy for every country.
Do you know how APNIC get their data? I'm happy to switch over to it if it's more representative and accurate.
From what I've gleaned, the use of Google ads catches the use case of people who don't actively use Google -- based on the delta in metrics between Google's stats and APNIC's, I would suspect that Google isn't quite as popular globally as you think it is (but their ad platform is!).
The other problem is that such issues are difficult to report in the first place as private customer because customer support is geared towards dealing with user errors or last mile problems.
I sent an email to the contact listed in the whois database but didn't get any reply.
With IPv4 my ISP has to shuffle IPs with every reconnect. With IPv6 you could get one IP for lifetime?
While ISP that hand out a static IPv4 can exist, it's much more unlikely, whereas with IPv6 it will become the norm.
Morevover, there is the privacy extension for IPv6 that change the local part of the IPv6 at regular interval to avoid tracing.
Most ISPs give you a new prefix occasionally, such as every night. They don't need to, but so many do it anyway that a tracker cannot assume that 2001:a61:2574:a00/64 is the same customer as yesterday. It may be the same, usually isn't, so tracking is very imprecise.
Often, in order to allow customers to use multiple subnets, ISPs will allocate a /56 (256 subnets) to customers.
For privacy purposes these have the same behavior as IPv4 addresses, in that they in theory can be rotated between users but in practice have lifetimes on the order of months.
v6 isn't easier to track. Some of the trackability from v4 remains, some goes away. As an example of the latter, if you go to a café with a wlan and stay for an hour, your laptop may use three different v6 addresses in that time.
Allocation of IPv4 address by your ISP is not a secure process; if your privacy depends on it your privacy is already compromised. And address allocation policy is independent of which protocol you're using anyway.
The forward DNS still exists, and is useful (I have a CNAME pointing to it), but the reverse DNS was probably just a convenient but privacy-leaking configuration that was noticed while preparing for GDPR.
Some devices like cable modems rarely 'reconnect'. As long as your router and cable modem stay powered you can keep your IP for months.
There are better tools for tracking, like cookies, session IDs, anything that client software voluntarily sends with some request of any kind. Nowadays even with least trackable protocol possible, DNS, as of DNS-over-HTTPS...
The thing that remains static is the prefix you got from your ISP but that works in exactly the same way as your v4 address you get when you connect.
no. If an ISP assigns you a dynamic prefix and the various machines in your network use any one of the various privacy features like temporary addresses then the only additional information you leak is some information about how many devices are in your LAN, but as the devices make up additional addresses, it's very fuzzy.
> With IPv4 my ISP has to shuffle IPs with every reconnect. With IPv6 you could get one IP for lifetime?
Your ISP can hand out a new prefix whenever you connect, or even while you are connected. Most of them do this by default.
>While ISP that hand out a static IPv4 can exist, it's much more unlikely, whereas with IPv6 it will become the norm.
it doesn't look like it - at least here in Switzerland, all providers that do provide v6 addresses hand out dynamic prefixes by default and most don't even offer the option of getting a static prefix.
With my provider green.ch it is not possible to get a static IPv6.
source: I'm fiber7 customer since 2014 and they offered me to do the delegation when I asked them for the static prefix.
The static prefix is nice and they will also basically give you static IPv4 even without paying.
oppressive regimes will assign people static IPv6 prefixes tied with their legal identities.
a) IP pool logging, requires a known IP address and time.
b) NAT logging, requires a known IP address, outgoing port number, and time.
It means the cost of tracking users is moderate to ISPs and authorities, also, for a random observer without access to internal records, a IPv4 user is effectively pseudonymous to the city-level until enough information is revealed.
But if the oppressive regimes really assign assign people static IPv6 prefixes tied with their legal identities intentionally, without any type of privacy extension, it would mean after I use my network connection for a while...
__everyone on the Internet, not just ISPs, can track my activity, possibility tied with my legal identity.__
I'm well aware of the existence of mass surveillance on IPv4, and I'm not advocating IPv4 for a false sense of security, I'm all for IPv6. But this is a true issue for consideration. Using a VPN, or Tor for day-to-day web browsing is the only practical solution to this problem I can think of...
On the other hand, IPv6 will bring end-to-end communications back to the Internet and revive P2P. To that day, perhaps a P2P-based, full mesh, optionally anonymous network will become practical. To this extent, IPv6 does more good than harm.
My question is, without continued adoption of IPv6, could we get to the point where there are two Internets? One that is more accessible for companies that can still afford IPv4 addresses for their servers? Or will worrying about IPv4 users be such an edge case that it will be like designing for IE11?
In theory, yes; in practice, most ISPs will give you a new prefix via DHCPv6-PD anytime your DUID changes (plus sometimes when it doesn't!).
Your web browser is more liable to erode your privacy than IPv6 is (any more than IPv4, anyway).
I'm not sure if it's the IPv4 shortage or copyright infringement/government surveillance pressure to maintain tight linkage between IP address, account, and legally liable person or address to raid.
We can't have it both ways. Either we have flat connectivity and a global address space like IPv6 and have static IPs, or we have to host all services in the cloud. I'd rather have static IPs.
Get a tunnel from he[1] and access the home network through that.
The ultimate goal being decommissioning the tunnel once the rest of the world is ready (few decades obviously)
b) You're ultimately still right that it enables connectivity to IPv4-only resources, but depending on the IPv6 client device, you may NEED to use a DNS 'A' record to get the traffic to use NAT64/DNS64, rather than trying to connect to a bare IPv4 address.
Essentially your device gets only an IPv6 address and the router translates IPv4 addresses to IPv6 ones. Your DNS server does the same thing. The end result is that your device talks only native IPv6, but the router is translating back and forth as necessary for IPv4.
It's actually pretty easy to test if you have an extra Mac laying around. There's a hidden checkbox on the Network preferences pane that lets any Mac create a NAT64 / DNS64 WiFi network [2].
[1] https://developer.apple.com/support/ipv6/ [2] https://developer.apple.com/library/archive/documentation/Ne...
Anyway, whenever I get a server, I make sure IPv6 is supported. No IPv6, no business from me -- even for a VPS.
With IPv6, I don't have to worry about NAT: I can always ssh to any of my machines (or the VMs) from anywhere. It's just simpler.
When I'm abroad and don't have IPv6, I ssh to one of my servers so I can connect to my home devices. That's a nuisance I'd like to avoid.
It's nice to know TMob is going IPv6 only. When I replace my "home" LTE internet, I may switch from AT&T to TMobile if the price is competitive.
Exposing an sshd to the public internet seems very risky. IPv6 or not.
Even with v6 in your LAN, you probably still want the firewall to drop all incoming connections and then use some kind of VPN or bastion host to get inside
That depends on factors.
Personally, I prefer an SNT/VPN such as ZeroTier or WireGuard. SSH would suffice, so would SSH over Tor. Thing is though; you only need to expose 1 of these to public internet. The rest is redundant. Which can be useful though.
This feels unintuitive, after all my IPv4 SSH servers have people banging on them 24/7, but that's orders of magnitude for you, bad guys who can try one host per second every second of every day, for a lifetime, can explore all of the actively deployed unicast IPv4 space. But those same bad guys will drown in the enormity of a single 64-bit IPv6 home subnet, never finding anything unless a well known address (e.g. ::80 for a web server is popular) was used for a server.
If you use the default static addressing ("default" in the protocol sense, it's not the default in any major desktop OS today) they might find you, in a lifetime's worth of searching, by being clever and looking at specific device manufacturers. You probably have a MAC address from a popular company like Intel or 3Com, and there are only a few billion of those laying around, so it's a headstart.
But you don't have to give them that headstart. So don't, just pick a random address from the other half of the pool. Roll dice if you don't trust your RNG.
An SSH server on port 22, home broadband connection: 212k failed IPv4 login attempts, zero failed IPv6 login attempts.
An SSH server on port 22, university connection: 269k failed IPv4 login attempts, zero on IPv6.
> If you just choose a completely arbitrary IPv6 address in your subnet for the server, random bad guys won't find it.
So that is true, but it also seems they won't even bother looking. My computer is as obvious as I can make it, it's listening on 2001:xxxx:xxx0::1/44, and still has had no attempts. Nothing on port 80 either.
And of course, there's nothing to prevent having several IPs on one machine, each for a different service. A DNS name for a web server then isn't revealing a possible SSH server.
Besides, with temporary IPv6, I don't think I have much to fear.
I forget if inbound connections work, though.
• The Client / Server CDN-centric Internet does not require each endpoint to have a globally unique permanent address
• Addresses are increasingly being used in the role of ephemeral session tokens, not as persistent endpoint identifiers
If you have to support ipv4 anyway and the benefit of ipv6 for your services is not high enough, why bother?
web ⊂ internet
ARIN is already out of IPv4, RIPE just finished their last /8 and are now going through the remaining available pile - what happens when they're all gone? Won't the world sort of be forced to migrate?
And yes, this is an ugly solution and comes with a lot of problems and costs.
- RIPE ran out in 2012, but has a new-LIR pool remaining (part of which is that /8 you mentioned)
- LACNIC ran out in 2014, but has a new-LIR pool remaining
- ARIN ran out in 2015, and does not have a new-LIR pool
- AFRINIC is the only RIR with a general-use pool available
As akvadrako says, there's a secondary market, except the current pricing is around 16+USD/IP, with the semi-obvious minimum of a /24 (so, 4000+USD). Given that (in ARIN region) that /24 would have cost you 250USD up-front, it's a marked increase.
(Actual current numbers, FWIW: https://www.ipv4auctions.com/customer/account/previous/ )
Do we really want a one way connection world? If not, adapt IPv6. By default IPv6 CPE gear blocks incoming connections, which is good. Firewall rules can be changed, if needed. You can't change forced CG-NAT.
While IPv6 may suck, it really is time to take IPv4 out and shoot it in the head.
Carrier firewalls kill mobile p2p networks even though mobile+p2p are made for each other: it'd be amazing to be able to build decentralised services running on swarms of phones, but the lack of stable device-to-device connectivity except via massive Google and Apple datacenters is a killer problem :(
[1] https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual...
Not sure how much of this background you need, but since Wikipedia doesn't explain it well: as an ISP, you want your IPv6-only customers to be able to access the IPv4 internet. So you represent the entire IPv4 internet as an IPv6 prefix (generally ::ffff:0:0:0/96) and get IPv6 clients to send their IPv4 traffic to that subnet. So e.g. if they user wants to access an IPv4 service at 1.2.3.4, you instead send them a DNS response with the address ::ffff:0:12:34. Then you route packets to the "IPv4 subnet" to a system that both does NAT and translates packets from v4 to v6.
The main point here is that you have to implement this or some other non-DS-Lite solution, because it solves a problem that DS-Lite does not address: support for IPv6-only clients on an IPv6-only ISP that still want to talk to old IPv4 servers.
Where this gets interesting is that once you've implemented NAT64 + DNS64, a solution to the backward-compatibility problem falls out neatly - convert IPv4 packets to IPv6 packets using a reverse of the protocol-aware translation that NAT64 boxes do, and then feed those into the NAT64-enabled network. So the marginal complexity for solving the backward-compatibility problem through 464XLAT is lower than implementing all of DS-Lite.
Not sure what's going on with SSH forwarding.
Yeah, if the service has an IPv6 address only it's not going to be able to accept connections from an IPv4 client.
In effect this is not true, as a developer without the time to fully implement IPv6-only networking I've been slapped with this rule in the app store review guidelines for non-complying apps numerous times. Just submit a new review and you'll get another reviewer who does not check this and you'll pass.
The rule they cite is also that you have to be able to support IPv6 for iPad-apps, not iPhone apps...
So even if it's the rule, I think that in reality it's not going to be true for all the users apps.
Things like MTU path-discovery, NDP and SLAAC make a lot of sense and are definitely improvements over the solutions we have in IPv4. Broadcast makes little sense on a layer 3 perspective. The use of link-local and unique-global addresses also makes sense, and having a different address class for multicast makes implementing multicast more convenient.
>"and having a different address class for multicast makes implementing multicast more convenient."
IPV4 has a different class for multicast as well - the first 4 bits are 1110. IP range 224.0.0.0 - 239.255.255.255.
Or did you mean something else?