Going IPv6 Only [pdf](pc.nanog.org)
pc.nanog.org
Going IPv6 Only [pdf]
https://pc.nanog.org/static/published/meetings/NANOG73/1645/20180625_Lagerholm_T-Mobile_S_Journey_To_v1.pdf
111 comments
Credit where it's due. I'm generally against anything the big 4 touch, but TMo has been absolutely on the forefront of IPv6. The first time I saw IPv6 in the wild was while on a TMo data connection.
[deleted]
Sorry, but anything in the US hasn't really been in the forefront of IPv6 adoption.
Google's IPv6 statistics (https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...) show that the US is ahead of literally every other country in the world, so I think it's fair to say US ISPs aren't doing too badly.
Belgium (50.02%) is ahead of the USA (37.19%) on that chart, although you may have missed that as it's quite a small country. Click "Europe" to zoom in a bit.
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.
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.
Ah, I did indeed miss Belgium. Surprising they don't have a table.
That's another benefit of https://stats.labs.apnic.net/ipv6/ -- the tables, including down to ASN.
Why is adoption a triangle wave pattern?
The charts graph IPv6 traffic, so it also represents a lot of human behavior. What you're seeing here is actually IPv6 being about ~4% higher on weekends compared to week-days. Looking at last week's data:
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.
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.
As mentioned/hinted by ancarda:
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).
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).
Thanks for that link, it's good to see more measurements.
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.
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.
https://labs.apnic.net/?p=479
https://labs.apnic.net/?p=655
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!).
https://labs.apnic.net/?p=655
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!).
An ISP with ten million v6-only users is not on the forefront? Be fair please.
Sadly the "happy eyeballs" algorithm obscures IPv6 problems. For example some subnets of amazon cloudfront are v4-reachable from my ISP while being v6-unreachable. But others are v6-reachable. When a DNS name points to a mix of v4 and v6 addresses nobody notices the failure because browsers are quick to fall back to v4 and thus the issue never gets reported.
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.
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.
Do you have examples of these subnets? ping me @ nahtnow at amazon dot com.
Not at a location where I can check with my home ISP right now. But last time I checked a few days ago it affected some of the AAAA records that docs.rust-lang.org was pointing to. The affected ISP is deutsche telekom.
I sent an email to the contact listed in the whois database but didn't get any reply.
I sent an email to the contact listed in the whois database but didn't get any reply.
Is it reasonable to hate and avoid IPv6 for fears of further privacy erosion (easier tracking than with IPv4)?
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.
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.
> Is it reasonable to hate and avoid IPv6 for fears of further privacy erosion (easier tracking than with IPv4)?
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.
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.
Technically, per IPv6 Address Allocation and Assignment Policy[1], there's no such things as a static IPv6 address, only address leased for a long enough period to be effectively static.
[1] https://www.ripe.net/publications/docs/ripe-552#4
[1] https://www.ripe.net/publications/docs/ripe-552#4
> no. If an ISP assigns you a dynamic prefix
oppressive regimes will assign people static IPv6 prefixes tied with their legal identities.
oppressive regimes will assign people static IPv6 prefixes tied with their legal identities.
oppressive regimes will assign people static IPv4 addresses tied with their legal identities.
If IPv4 pools and carrier-grade IPv4 NATs spreads all over the network, a user's identity is revealed to the oppressive regimes in primarily two ways:
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.
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.
Belgium limited ISP side NAT to 16:1 for law enforcement/national security log retention reasons.
In switzerland we have still no IPv6 on mobile phones at all in 2018 :-(
With my provider green.ch it is not possible to get a static IPv6.
With my provider green.ch it is not possible to get a static IPv6.
You can get static IPv6 from Fiber7.
I know. And they even delegate the ip6.arpa domain so you can do reverse lookups with your own DNS server.
source: I'm fiber7 customer since 2014 and they offered me to do the delegation when I asked them for the static prefix.
source: I'm fiber7 customer since 2014 and they offered me to do the delegation when I asked them for the static prefix.
Nice. I had the FTTH.300 and only got Fiber7 yesterday. I don't have my own DNS as friend hosts my stuff.
The static prefix is nice and they will also basically give you static IPv4 even without paying.
The static prefix is nice and they will also basically give you static IPv4 even without paying.
Are they that unlikely? My IPv4 is stable for months/years, despite being "dynamic". I don't even run a dynamic DNS client, since it's so rare that it actually changes.
It really depends on the ISP. Back when we were still using A1 (what used to be the Austrian telecom basically), we would receive a new IP address every time we reconnected. Now after switching to Liwest (a very local provider, only serves this city and some small towns around it) our IP is for all intents and purposes static, even though it wasn't advertised as such.
>we would receive a new IP address every time we reconnected.
Some devices like cable modems rarely 'reconnect'. As long as your router and cable modem stay powered you can keep your IP for months.
Some devices like cable modems rarely 'reconnect'. As long as your router and cable modem stay powered you can keep your IP for months.
We used to turn them off as soon as we stopped using the internet (this was also before any of us had a smartphone). I think the ISP also cut the connection every 24 hours and changed the IP to prevent people from having a static IP "for free".
No, it's not reasonable.
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.
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.
As an example, until about a month ago the reverse DNS of the IPv4 address my ISP assigned to me resolved to [modem-mac-address].large-isp.countrycode
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.
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 ISP provide a different IPv6 at each connection (to sell static IPv6 at higher price). Other ISP provide a /56, which means, you can shuffle on a lot of /64 on your own.
Morevover, there is the privacy extension for IPv6 that change the local part of the IPv6 at regular interval to avoid tracing.
Morevover, there is the privacy extension for IPv6 that change the local part of the IPv6 at regular interval to avoid tracing.
I wouldn't be surprised if it will be trivial to look at a certain IP and query how large pool that particular ISP are allocating for each user.
The short version is: No. Not reasonable.
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.
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.
In the worst case the ISP will give you a /64 prefix which you can complete to form an IPv6 address via SLAAC. Operating systems will generate many different temporary addresses with a short lifetime and use those for outbound connections to reduce tracking.
You should have a look at the IPv6 privacy extensions. IPv6 doesn't work as you think it does. Your devices use temporary IPs even with a static IPv6 prefix.
Can't trackers just map the prefix to your id, or do many users share a prefix? will look it up...
Sometimes, sometimes.
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.
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.
And technically it would be easily possible with IPv6 to have multiple prefixes at the same time. An ISP could give you one static prefix for incoming connections and then an additional dynamic prefix which rotates between customers every 24 hours (leaving old prefixes actives for a week in case you have long-living connections).
A single user has at least a /64 (which in IPv6 must correspond to a subnet). This is the equivalent of a NATted IPv4 address for privacy purposes.
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.
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.
My IPv4 lease has been static for the past several months. It very rarely changes; I would have to spoof a MAC address on my WAN router to get it to change.
you don't have to spoof, just leave the WAN device off around the time when your dhcp lease expires. When you come back online, you'll find you have a new lease with likely a new address.
My ISP no longer issues a new IP address upon router change. I'd probably have to go offline for at least a few hours or simultaneously change modem and router. In the meantime my household would notice, our phones would consume more of our cellular quota, my IP phone wouldn't ring, and even my thermostat would lose remote control functionality.
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.
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.
IP client addresses can and do change, be it that they move from landline to mobile or cafe wifi etc. I doubt many use the IP address to track clients for an extended period of time (one hour? one day?).
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...
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...
It's the part in the lower 64 bits that does not change as one moves around changing prefixes that worries people. And of course ways to pseudo-randomize that already exist, as mentioned already in this very discussion.
for the last 10 years or so, every single OS out there randomises the lower bits by default and even rotates it every few connections.
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.
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.
Not in the scenario actually under discussion by okket here.
[deleted]
> With IPv4 my ISP has to shuffle IPs with every reconnect. With IPv6 you could get one IP for lifetime?
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).
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).
Besides what others are saying, you also have to keep in mind that IPv4 exhaustion means that at some point, IPv4 addresses could become very expensive. Many countries are already totally out. I worked in one data center where we were purchasing blocks from companies in Africa.
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?
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?
Bear in mind privacy advocates also tend to like decentralised systems, but p2p networks benefit from IPv6 a lot.
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.
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.
For the 64bit suffix there are ipv6 privacy extensions.
For the prefix some ISPs hand out a whole /56 to the user so their CPE can rotate through multiple /64s over time.
And of course just like they can shuffle IPv4s they can also shuffle IPv6s.
I don't hink it's much more unlikely. And in the same vein, some ISPs change your IPv6 prefix regularly. It really depends on the ISP, their technology and their policies.
I'm glad that someone is finally doing this. We all really need someone to force us to migrate to v6 finally, and I only did that once I realized I couldn't access my home network over cellular anymore.
What do you do if your cellular provider goes IPv6-only, but your home ISP will only give you a v4 address?
Apple has been requiring all apps on the App Store work on IPv6-only networks for two years now [1]. They require it work on a network with NAT64 and DNS64 set up.
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...
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...
> What do you do if your cellular provider goes IPv6-only, but your home ISP will only give you a v4 address?
Get a tunnel from he[1] and access the home network through that.
[1]https://tunnelbroker.net/
Get a tunnel from he[1] and access the home network through that.
[1]https://tunnelbroker.net/
Or use a Tor hidden service, and get end-to-end encryption for free (see https://github.com/AnarchoTechNYC/meta/wiki/Connecting-to-an...)
I don't think your cellular provider would stop you from accessing ipv4 addresses, it just starts the first hop on ipv6, then tunnels it for you to wherever you're trying to reach.
The ultimate goal being decommissioning the tunnel once the rest of the world is ready (few decades obviously)
The ultimate goal being decommissioning the tunnel once the rest of the world is ready (few decades obviously)
a) It's a translator, not a tunnel.
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.
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.
a variaty of methods exists that accomplish this, including DS-lite, 6in4, 6to4 and XSLAT tunneling.
On my home network, all my device have IPv6. Unfortunately, it not native IPv6: the AT&T LTE device I use for my home internet doesn't support IPv6. (Why LTE? It's a long story- I frequently travel, and I take my connection with me. Comcast doesn't make much sense. LTE latency and bandwidth are good enough)
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.
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.
Just to warn you, even on T-Mobile, not all hotspot devices support IPv6 (either by default or at all).
I forget if inbound connections work, though.
I forget if inbound connections work, though.
> I can always ssh to any of my machines (or the VMs) from anywhere. It's just simpler.
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
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
If you just choose a completely arbitrary IPv6 address in your subnet for the server, random bad guys won't find it.
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.
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.
Statistics since 1 June:
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.
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.
No longer letting ssh listen on IPv4 address definitely cuts down on brute force attempts. One caveat is someone cleverly found a workaround to do the seemingly impossible task of scanning IPv6 address ranges. They hosted a NTP server and harvested live addresses. So I guess those who disable NTP on the most sensitive VMs might be right. One is already suppose to have a local NTP server anyway, if only by pointing hosts to the firewall's ntpd.
> Exposing an sshd to the public internet seems very risky. IPv6 or not.
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.
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.
My raspberry pi, home weather station, and test VMs are not THAT sensitive :)
Besides, with temporary IPv6, I don't think I have much to fear.
Besides, with temporary IPv6, I don't think I have much to fear.
disable password authentication, ssh keys are secure enough
would you rather emergency security patch opensshd on 10 machines or one bastion host?
Not worth the added complexity. Exposing sshd (w/ disabled passwords) is common practice and fine for most use cases. Special use cases may require special precautions, but even airgapped systems can be compromised with enough effort. I'll take my chances with the industry standard and update as needed.
If you're worried about zero days you might consider not allowing SSH through firewall and requiring connecting to VPN first. That'd require a flaw in both OpenVPN and SSH.
GP probably has password login turned off in sshd...
geoff-huston from apnic, has this set : https://ripe76.ripe.net/presentations/9-2018-05-17-ipv6-reas... describing world-wide ipv6 deployment, and the conclusion there seems to be that v6 deployment is actually slowing down, and the conclusion seems to be that no one knows why...
The low hanging fruits are all taken, the higher ones are harder to reach. But what makes an ISP/country harder to reach is not just a couple of variables.
I'd half agree with this; for those who are actively working on this, yes, the low-hanging fruit are all done, but there's still plenty of low-hanging fruit in organizations where no one's bothered to pick them.
Despite his conclusion, he likely answers it here:
• 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?
• 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?
That only applies if you have a very myopic view on what the internet does. Sure, CDN traffic may dominate by volume but it is far from the only traffic on the internet. P2P traffic is still significant.
web ⊂ internet
web ⊂ internet
P2P works through NATs as long as you are willing to signal through a central servers, e.g. discussed here: https://arxiv.org/pdf/1605.05606
I've been following the IPv6 rollout with interest for the last few years from outside the networking / RIR / LIR / ISP community and I have a question if anyone could provide some insights:
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?
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?
- APNIC ran out in 2011, but has a new-LIR pool remaining
- 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/ )
- 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/ )
You can buy IPv4 addresses on a second-hand market. A few years ago they were about $8 each, with a minimum of 256. Plus you need to pay an RIR member to hold them for you, which incurs about $50/year in RIR fees for Europe. So it's not a big deal yet.
This increases the motivation, but there are methods of delaying the hard requirement to migrate. A smaller patch is to reclaim unused blocks; a bigger one is carrier-grade NAT. e.g. in some countries such as Russia your ISP will allocate you a 10.0.0.0/8 address rather than a publicly-routable one, and will have a NAT between its customers in your city and the publicly-addressable internet.
And yes, this is an ugly solution and comes with a lot of problems and costs.
And yes, this is an ugly solution and comes with a lot of problems and costs.
It is weird to call this 'IPv6 Only'. Connectivity to the IPv4 internet is still provided. It is just that to talk IPv4 you have to go through a couple of complex translation steps.
It is IPv6 only with a fallback connection to the legacy IPv4 protocol with little to no chance of a reverse connection. Sadly, too much content is still stuck in this rapidly ageing world. Bandaid after bandaid won't help in the long term.
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.
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.
Well, are there any mobile ISPs that let you accept inbound connections?
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 :(
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 :(
There's some RFC suggesting that CGNATs handle PCP requests from the CPE thus allowing incoming connections. But sadly that's not implemented everywhere.
Yo dawg, I hear you like NAT, so I'm going to put NAT in your NAT.
While IPv6 may suck, it really is time to take IPv4 out and shoot it in the head.
While IPv6 may suck, it really is time to take IPv4 out and shoot it in the head.
Looking at mechanisms like 464XLAT, why are these currently favored over DS-Lite [1]? To me DS-Lite seems like a simple and elegant solution if you don't have a lot of public IPv4 addresses, 464XLAT looks much more compilcated.
[1] https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual...
[1] https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual...
464XLAT is simpler because it gets to piggyback off of other infrastructure that is already in place for forward-compatibility, namely NAT64 and DNS64.
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 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.
Would 464XLAT allow you to connect to e.g. Emby over IPv4, SSH port forwarding over IPv4, and BitTorrent to work (where majority of clients use IPv4) where it doesn't with DS-Lite/CGN?
Not sure about BT (there's still a NAT involved, but maybe the more conventional NAT64 allows the usual hole punching techniques to work?) or Emby (no idea what that is). I have no idea why SSH port forwarding wouldn't work with DS- Lite or 464XLAT, since from the network infrastructure's perspective it's a pretty conventional server-client connection.
Didn't work for me with DS-Lite/CGN because I couldn't port forward since I didn't have authorization for that on my ISP's CGN server. Outward IPv4 worked perfectly fine, but inward did not. If your client speaks IPv4 only (which is rather common; e.g. my smartphone with 4G has this), it won't be able to talk to your IPv6 who has IPv4 behind CGN. What would work is a port forwarding server. A server which accepts IPv4 connection on a certain port and forward it to the server which accepts IPv6. However, this has several advantages: these services are not free (and rightfully so), and the user is relying on a third party.
BitTorrent should work fine, because it has mechanisms for punching UDP holes in NATs (by agreeing on a port combination with a coordination server and having each side send a dummy UDP packet to install the mappings). The one caveat is that, for correct determination of the NATted IP address, the coordination server needs to be IPv4-only.
Not sure what's going on with SSH forwarding.
Not sure what's going on with SSH forwarding.
Won't work if they don't have correct port forwarding enabled (which a lot of BitTorrent clients suffer from). FTP passive also doesn't work IIRC. SSH port forwarding uses TCP. Say you're listening on your IPv6 address. Well, if your client is IPv4 only you won't be able to connect. Unless you use one of those 4 to 6 services I mentioned.
Ah. I thought you meant SSH port forwarding where the client is on IPv6.
Yeah, if the service has an IPv6 address only it's not going to be able to accept connections from an IPv4 client.
Yeah, if the service has an IPv6 address only it's not going to be able to accept connections from an IPv4 client.
> "At WWDC 2015 Apple announced the transition to
IPv6-only network services in iOS 9. Starting June 1,
2016 all apps submitted to the App Store must
support IPv6-only networking."
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.
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.
A rule that is not enforced properly does not invalidate the rule. Do you want to rely for your app to get approved to get a non-enforcing reviewer forever in the future? Also think of your customers on networks like TMo.
What prevents you from supporting IPv6-only networking? HTTP libraries support it out of the box. If you use sockets, just update them to use PF_INET6 and it'll be backward-compatible with IPv4 through IPv4-embedded IPv6 addresses.
Socat is your friend.
I just wish IPV6 was mostly about adding more bits to the addresses instead of the clusterfuck that they introduced.
the "clusterfuck" the introduced is mostly a nice thing in my opinion.
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.
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.
I agree with all of your points. I didn't understand this however:
>"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?
>"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?
I doubt it, it's conceptually the same, as you say. I think this is just exemplary of just how much most people, even tech people, don't understand the underlying networking paradigm.