5 ms·

Disabling IPv6 is recommended? I thought we are all moving to use IPv6.

8organicbits 4y ago
The link has an interesting justification, I haven't heard that before. > That's because millions of home gateway routers, especially those leased to customers by their internet service providers (ISPs), leak their unique hardware ID numbers through their Internet Protocol (IP) addresses — and those hardware ID numbers can be connected to publicly available maps that show the street locations of Wi-Fi networks.
- Sakos 4y ago
  https://www.blackhat.com/us-21/briefings/schedule/#ipvseeyou-exploiting-leaked-identifiers-in-ipv-for-street-level-geolocation-22889 https://www.blackhat.com/us-21/briefings/schedule/#ipvseeyou... It's based on this talk apparently > We assume a weak adversary who is remote to the target and has no privileged access. Our privacy attack lies in IPv6 addresses formed via EUI-64, which embed the interface's hardware MAC address in the IPv6 address. While EUI-64 IPv6 addresses are no longer used by most operating systems, they are commonly found in legacy and low-profit-margin customer premises equipment (CPE), e.g., commodity routers connecting residential and business subscribers. Because IPv6 CPE are routed hops (as opposed to IPv4 NATs), we can discover their MAC address via traceroute if they use EUI-64. > These CPE are frequently all-in-one devices that also provide Wi-Fi. Crucially, the MAC address of the Wi-Fi interface is often related to the MAC address of the wide area interface, e.g., a +/-1 offset. These Wi-Fi MACs are broadcast (the 802.11 BSSID) and captured by wardriving databases that also record their physical location. By correlating the MAC addresses embedded in IPv6 home router addresses with their Wi-Fi address counterpart, we can remotely geolocate them, fusing virtual data with meatspace. They have a tool that lets you check a given IPv6 address: https://github.com/6int/IPvSeeYou https://github.com/6int/IPvSeeYou
  - ikiris 4y ago
    Heh, I was dubious but this is a perfectly valid explanation for why you should not embed phy addresses in IPs. That said, it's absolutely toxic to be telling people to just turn off IPv6. Completely makes me lose trust in the rest of the site's content.
    - Sakos 4y ago
      A source link to a very thorough article at Tom's Guide (https://www.tomsguide.com/news/home-gateway-geolocation-bh21 https://www.tomsguide.com/news/home-gateway-geolocation-bh21) is provided close to the top of the page (in the short list). That guide links to the Black Hat presentation. > For years, turning off IPv6 (IP version 6) was on the long list below, but as of August 2021, I think it belongs here on the short list too. Very very few people need it and it was recently disclosed that there is a possible security issue with it. I think you're being a bit too accusative. Every suggestion has sources to back it up if you want to see why something is recommended.
  - jaclaz 4y ago
    >These Wi-Fi MACs are broadcast (the 802.11 BSSID) and captured by wardriving databases that also record their physical location. I am not sure to understand, while this is in theory doable, do these "captured by wardriving" databases exist? And do they cover "everywhere"?
    - veonik 4y ago
      A long while back now Google came out saying[0] they did use their Google Maps Street View cars to also collect wifi+location information. It wouldn't surprise me if they augmented this info with data they receive through Google services running on Android phones too. So my bet is, yeah, they do exist and they do pretty much cover everywhere. [0]: https://www.theguardian.com/technology/2010/may/15/google-admits-storing-private-data https://www.theguardian.com/technology/2010/may/15/google-ad...
      - jaclaz 4y ago
        I see now, thanks. Though I believe that if Google is the adversary, they have ways (only a guess, but some kind of correlation between GPS location on mobile while connected to Wi-Fi and http requests could be one) that make the "wardriving database" unneeded, I mean, there should be a constant updating of this database, or it would turn out pretty much obsolete soon.
        toast0 4y ago
        The database may have originally been filled by wardriving, but it can be updated by their distributed agents (phones with location services turned on).
      - Lukas_Skywalker 4y ago
        Google even has a geolocation API [1] where you can send the BSSID and signal strength of the access points in your range and it calculates your position. [1]: https://developers.google.com/maps/documentation/geolocation/overview#wifi_access_point_object https://developers.google.com/maps/documentation/geolocation...
- stonepresto 4y ago
  I think there's a better justification. Since IPv6 is still new-ish to SOHO, and often is lightly used at best, the firmware devs might not spend as much time building that support into the firmware. When devs get laxidasical, bugs happen.
  - feanaro 4y ago
    I'm not sure that's a better justification. It's definitely an additional justification, making the whole thing that much worse. But street-level geolocation is pretty bad in itself.
- zekica 4y ago
  This only correct for the router itself. Not for any devices connecting behind it.
njibhu 4y ago
There are a lot of shortcomings of IPv6 which prevents it to be widely used (particularly on the consumer network side). First thing to know is that it shifts responsibilities. The router is not responsible anymore for assigning IPs to the network. The devices assign their own IP address using SLAAC. You could use DHCPv6, but many devices simply won't support it (windows and android to begin with). Which brings the following issues: - No support for multi-homing. Example: You have two connections, a slow reliable one, and a fast unreliable one. With IPv4 you can easily setup multiwan in any proper L3 router. The router will ping both routes, and if the fast one is working, using it as main gateway. When it doesn't answer anymore, the router simply change its route. Because of NAT, this is transparent to the devices behind its network. For IPv6, this doesn't work anymore, because the IP prefix is set by the provider, without NAT the second provider will simply refuse to forward any packet which originates from an IP which doesn't have their prefix. The "solution" is to have your own address space, and use BGP to change the routes (which is out of reach for all of private consumers). - ISPs got it wrong ! I'm in Germany, tried 3 different providers, they all assign to my router a /64 subnet instead of /60 or /56 (as recommended by ARIN). The problem is that SLAAC only works with /64, below the devices usually won't assign themselves an IP anymore. So you can only have one network, you can't have a Guest network with a different prefix. - As mentioned by the article, the design is terrible for privacy: SLAAC works by simply taking the prefix from the router and filling the rest with the mac address. Which means that anybody on the internet gets to know your mac address. EDIT: This is wrong. See throw0101a answer below. - Captive portals: SLAAC does not directly support assigning DNS servers. So most captive portals simply break because the network's firewall blocks DNS requests as long as they don't use the proper DNS server, but the device might simply not even be able to receive it. (SLAAC has an extension where it can tell the device to receive the DNS servers from DHCPv6, but many devices simply ignore it and treat DNS like browsers do with DoH). EDIT: This is wrong. See throw0101a answer below. - Security within networks: Because the responsibilities of who assigns IP is shifted to the devices, switches cannot prevent devices to assign themselves IP anymore. So it's very easy for malicious devices to flood routing tables of switches by telling them that they own all IPv6 for the whole /64. Makes the whole network abysmally slow, or completely down. Most of these issues are solved by using NAT6 (or NPT), but the issue with it, is that it breaks some applications. Ipv6 promised to get rid of NAT, so some applications took the liberty to assume that their local IP would always be the same visible on the internet. Not sure if that's this particular case for SIP, but it's usually broken with NAT6.
tryauuum 4y ago
if you don't have ipv6 access to internet, makes sense to disable it in router's kernel. It makes the attack surface smaller By default Linux assigns a link-local ipv6 address to each interface, this can be undesirable
redleader55 4y ago
The author shows a complete lack of knowledge on IPv6. Yes, you do get a SLAAC address which basically contains you MAC, but if your OS supports it, you will also get a anonymized address which does not leak your MAC on the internet. Windows, Android, Linux, iOS all support MAC address anonymization, so as long as you are using a recent OS you should be fine. Very weird suggestion...
- whyoh 4y ago
  Right. But isn't it so that each device gets its own IPv6 public address? So that PC1 and PC2 connected through the same modem are identifiable by different IPs, while you can still see that they're from the same modem/household? If that's the case, it can be a privacy concern.
  - tommiegannert 4y ago
    Theoretically, even non-router devices could use more than one address, just to confuse what's listening on the other side. In that scenario, DHCPv6 would be responsible for keeping the assigned subnet filled randomly, rather than being conservative and consistent with address assignments. I don't know if anyone is doing it now, but I don't think we should dismiss IPv6 for this reason.
    - megous 4y ago
      Android doesn't respect/implement DHCPv6. But there are IPv6 privacy extensions that periodically rotate the IPv6 addresses of the device. https://datatracker.ietf.org/doc/html/rfc4941 https://datatracker.ietf.org/doc/html/rfc4941
      - tommiegannert 4y ago
        Thanks for the reference! Doing that directly with SLAAC is of course even nicer.
- throw0101a 4y ago

The link has an interesting justification, I haven't heard that before. > That's because millions of home gateway routers, especially those leased to customers by their internet service providers (ISPs), leak their unique hardware ID numbers through their Internet Protocol (IP) addresses — and those hardware ID numbers can be connected to publicly available maps that show the street locations of Wi-Fi networks.

Sakos 4y ago
https://www.blackhat.com/us-21/briefings/schedule/#ipvseeyou-exploiting-leaked-identifiers-in-ipv-for-street-level-geolocation-22889 https://www.blackhat.com/us-21/briefings/schedule/#ipvseeyou... It's based on this talk apparently > We assume a weak adversary who is remote to the target and has no privileged access. Our privacy attack lies in IPv6 addresses formed via EUI-64, which embed the interface's hardware MAC address in the IPv6 address. While EUI-64 IPv6 addresses are no longer used by most operating systems, they are commonly found in legacy and low-profit-margin customer premises equipment (CPE), e.g., commodity routers connecting residential and business subscribers. Because IPv6 CPE are routed hops (as opposed to IPv4 NATs), we can discover their MAC address via traceroute if they use EUI-64. > These CPE are frequently all-in-one devices that also provide Wi-Fi. Crucially, the MAC address of the Wi-Fi interface is often related to the MAC address of the wide area interface, e.g., a +/-1 offset. These Wi-Fi MACs are broadcast (the 802.11 BSSID) and captured by wardriving databases that also record their physical location. By correlating the MAC addresses embedded in IPv6 home router addresses with their Wi-Fi address counterpart, we can remotely geolocate them, fusing virtual data with meatspace. They have a tool that lets you check a given IPv6 address: https://github.com/6int/IPvSeeYou https://github.com/6int/IPvSeeYou
- ikiris 4y ago
  Heh, I was dubious but this is a perfectly valid explanation for why you should not embed phy addresses in IPs. That said, it's absolutely toxic to be telling people to just turn off IPv6. Completely makes me lose trust in the rest of the site's content.
  - Sakos 4y ago
    A source link to a very thorough article at Tom's Guide (https://www.tomsguide.com/news/home-gateway-geolocation-bh21 https://www.tomsguide.com/news/home-gateway-geolocation-bh21) is provided close to the top of the page (in the short list). That guide links to the Black Hat presentation. > For years, turning off IPv6 (IP version 6) was on the long list below, but as of August 2021, I think it belongs here on the short list too. Very very few people need it and it was recently disclosed that there is a possible security issue with it. I think you're being a bit too accusative. Every suggestion has sources to back it up if you want to see why something is recommended.
- jaclaz 4y ago
  >These Wi-Fi MACs are broadcast (the 802.11 BSSID) and captured by wardriving databases that also record their physical location. I am not sure to understand, while this is in theory doable, do these "captured by wardriving" databases exist? And do they cover "everywhere"?
  - veonik 4y ago
    A long while back now Google came out saying[0] they did use their Google Maps Street View cars to also collect wifi+location information. It wouldn't surprise me if they augmented this info with data they receive through Google services running on Android phones too. So my bet is, yeah, they do exist and they do pretty much cover everywhere. [0]: https://www.theguardian.com/technology/2010/may/15/google-admits-storing-private-data https://www.theguardian.com/technology/2010/may/15/google-ad...
    - jaclaz 4y ago
      I see now, thanks. Though I believe that if Google is the adversary, they have ways (only a guess, but some kind of correlation between GPS location on mobile while connected to Wi-Fi and http requests could be one) that make the "wardriving database" unneeded, I mean, there should be a constant updating of this database, or it would turn out pretty much obsolete soon.
      - toast0 4y ago
        The database may have originally been filled by wardriving, but it can be updated by their distributed agents (phones with location services turned on).
    - Lukas_Skywalker 4y ago
      Google even has a geolocation API [1] where you can send the BSSID and signal strength of the access points in your range and it calculates your position. [1]: https://developers.google.com/maps/documentation/geolocation/overview#wifi_access_point_object https://developers.google.com/maps/documentation/geolocation...
stonepresto 4y ago
I think there's a better justification. Since IPv6 is still new-ish to SOHO, and often is lightly used at best, the firmware devs might not spend as much time building that support into the firmware. When devs get laxidasical, bugs happen.
- feanaro 4y ago
  I'm not sure that's a better justification. It's definitely an additional justification, making the whole thing that much worse. But street-level geolocation is pretty bad in itself.
zekica 4y ago
This only correct for the router itself. Not for any devices connecting behind it.

njibhu 4y ago

There are a lot of shortcomings of IPv6 which prevents it to be widely used (particularly on the consumer network side). First thing to know is that it shifts responsibilities. The router is not responsible anymore for assigning IPs to the network. The devices assign their own IP address using SLAAC. You could use DHCPv6, but many devices simply won't support it (windows and android to begin with). Which brings the following issues: - No support for multi-homing. Example: You have two connections, a slow reliable one, and a fast unreliable one. With IPv4 you can easily setup multiwan in any proper L3 router. The router will ping both routes, and if the fast one is working, using it as main gateway. When it doesn't answer anymore, the router simply change its route. Because of NAT, this is transparent to the devices behind its network. For IPv6, this doesn't work anymore, because the IP prefix is set by the provider, without NAT the second provider will simply refuse to forward any packet which originates from an IP which doesn't have their prefix. The "solution" is to have your own address space, and use BGP to change the routes (which is out of reach for all of private consumers). - ISPs got it wrong ! I'm in Germany, tried 3 different providers, they all assign to my router a /64 subnet instead of /60 or /56 (as recommended by ARIN). The problem is that SLAAC only works with /64, below the devices usually won't assign themselves an IP anymore. So you can only have one network, you can't have a Guest network with a different prefix. - As mentioned by the article, the design is terrible for privacy: SLAAC works by simply taking the prefix from the router and filling the rest with the mac address. Which means that anybody on the internet gets to know your mac address. EDIT: This is wrong. See throw0101a answer below. - Captive portals: SLAAC does not directly support assigning DNS servers. So most captive portals simply break because the network's firewall blocks DNS requests as long as they don't use the proper DNS server, but the device might simply not even be able to receive it. (SLAAC has an extension where it can tell the device to receive the DNS servers from DHCPv6, but many devices simply ignore it and treat DNS like browsers do with DoH). EDIT: This is wrong. See throw0101a answer below. - Security within networks: Because the responsibilities of who assigns IP is shifted to the devices, switches cannot prevent devices to assign themselves IP anymore. So it's very easy for malicious devices to flood routing tables of switches by telling them that they own all IPv6 for the whole /64. Makes the whole network abysmally slow, or completely down. Most of these issues are solved by using NAT6 (or NPT), but the issue with it, is that it breaks some applications. Ipv6 promised to get rid of NAT, so some applications took the liberty to assume that their local IP would always be the same visible on the internet. Not sure if that's this particular case for SIP, but it's usually broken with NAT6.

tryauuum 4y ago

if you don't have ipv6 access to internet, makes sense to disable it in router's kernel. It makes the attack surface smaller By default Linux assigns a link-local ipv6 address to each interface, this can be undesirable

redleader55 4y ago

The author shows a complete lack of knowledge on IPv6. Yes, you do get a SLAAC address which basically contains you MAC, but if your OS supports it, you will also get a anonymized address which does not leak your MAC on the internet. Windows, Android, Linux, iOS all support MAC address anonymization, so as long as you are using a recent OS you should be fine. Very weird suggestion...

whyoh 4y ago
Right. But isn't it so that each device gets its own IPv6 public address? So that PC1 and PC2 connected through the same modem are identifiable by different IPs, while you can still see that they're from the same modem/household? If that's the case, it can be a privacy concern.
- tommiegannert 4y ago
  Theoretically, even non-router devices could use more than one address, just to confuse what's listening on the other side. In that scenario, DHCPv6 would be responsible for keeping the assigned subnet filled randomly, rather than being conservative and consistent with address assignments. I don't know if anyone is doing it now, but I don't think we should dismiss IPv6 for this reason.
  - megous 4y ago
    Android doesn't respect/implement DHCPv6. But there are IPv6 privacy extensions that periodically rotate the IPv6 addresses of the device. https://datatracker.ietf.org/doc/html/rfc4941 https://datatracker.ietf.org/doc/html/rfc4941
    - tommiegannert 4y ago
      Thanks for the reference! Doing that directly with SLAAC is of course even nicer.
throw0101a 4y ago