> When IPv6 was developed in the mid-90s, the Internet was not accessed by a large number of mobile devices and privacy was not the priority it has become today. To address these privacy concerns, the SLAAC protocol was updated with mechanisms that were termed “Privacy Extensions for Stateless Address Autoconfiguration in IPv6”, codified in RFC 4941. This allows for the IPv6 address interface identifier to be generated randomly. If the same interface identifier is generated for two devices in the same local area network, the Duplicate Address Detection (DAD) function of the IPv6 Neighbor Discovery Protocol (NDP) will resolve the situation.
Prior to those times tracking protection wasn't critical in protocol design (or most people's minds in general) and so using the MAC was a great way to self select an address without extra steps.
"Prevents" is overstating this a bit. The IPv6 Privacy Extension is a hack that doesn't completely mitigate this sort of problem. It's just better than nothing, and is all we have.
With IPv4 you reveal the IP of your IP Masq/Nat router, which is often inside your home/business. It can be dynamic or static, but generally changes pretty slowly. There might be a single person behind that IP, or 100s.
With IPv6 your /64 is often inside your home/business. It can be dynamics or static, but generally changes pretty slowly. There might be a single person behind that /64, or 100s. Different outgoing connections see different IPv6 addresses, and they change over time (slowly).
Most importantly just like a mac address, the outgoing connections never use the IPv6 address based on mac address.
So how does the privacy extension not protect the privacy of users by hiding the mac address?
> So how does the privacy extension not protect the privacy of users by hiding the mac address?
I never said it didn't. I stated that people overstate the protection the facility provides, not that it didn't provide protection.
The deficiencies of the privacy extensions have been discussed widely for years. A quick internet search will show the various criticisms and responses better than any reply I can make here will.
I should, however, clarify what I was trying to say -- I was not trying to say the privacy extensions aren't worthwhile. They're great, and people should use them!
What I was trying to say is that people often think of them as a panacea or a 100% solution. They aren't exactly that (what is?), and the nature of the design of the privacy extensions are such that they make other important network management activities more difficult.
My main criticism of PE (and it's not a showstopper sort of criticism) is that the extensions are hacky and it shows. They were thought up after-the-fact to try to mitigate a security mistake made in the original IPv6 protocol.
Sure, but the original parent was complaining about the mac address (not any larger privacy issues) and the PE does a good job of hiding the mac address and is enable by default in many common operating systems (Mac, Windows, Ubuntu, etc.)
IPv6 is old. Back then, not only servers but also desktops were commonly on a fixed public IP address, accessible from anywhere on the Internet. Hiding the MAC address would gain very little, since the IP address was enough to uniquely identify a host.
Even now, some large traditional sites put static public IPs on workstations. When I was a lbl.gov, you got a (minimally firewalled) public ip via dhcp, and the hostname sent by your workstation was used to create a dns record of foo.dhcp.lbl.gov. You could request a static address for your host, and you'd be assigned an even less firewalled ip along with a foo.lbl.gov record.
A decade later this still seems to be at least partly in place, as I'm able to browse the webserver running on an old colleague's desktop.
Wow. I work for another US government agency down the road from LBNL, and here I can't even see many internal servers from my laptop because there is a firewall between the (wired!) laptop-accessible network and the inner ring that the servers are on.
I think my sysadmin group would have a collective heart attack if they saw that setup! It's quite incredible to me how independent various parts (and pseudo parts like the national labs) are from each other.
LBNL is an incredibly open, yet monitored network (in the spirit of the collaborative research that goes on there.)
You can be certain that most every packet in, out, or through the place gets captured and inspected by Bro (errr, I guess Zeek now. https://www.zeek.org/ )
I should also mention that not every host had a public IP. I worked with the group that managed midrange compute clusters, which were always behind NAT, with bastion login nodes.
IPv6 was designed long before surveillance capitalism was a concern and before security in general was as much of a concern as it is today.
Addresses don't have to be assigned that way. There are other ways of assigning addresses including privacy addresses and DHCPv6. The address space is so big that just generating a random address, while not RFC, is "okay" on all but huge networks if you're working in a /64.
> This allows us to enumerate a particular subset of active IPv6 hosts which can then be scanned.
So if you have turned off the firewall in your CPE, someone might heave an easier time scanning your network, without having to find your ip address from a http access log or using webrtc etc.
The property of scanning resitance due to address sparsity in IPv6 is not very strong (nor is it meant to be a security boundary) and there are many things like this that can go around it.
If one were to scan all the IPv4 internet for broken/exposed UPnP service to target, they could then use IPv4 to craft a special message instructing the service to phone home to an IPv6-only domain. If the client has IPv6 enabled and the phone-home goes through, it is determined that there is a link from broken/exposed IPv4 UPnP to a potentially unknown IPv6 address. This gives a new set of previously unknown IPv6 addresses. These IPv6 addresses can now be scanned for other vulnerabilities.
Is there a way to gather the list of all domains/subdomains, etc? Because if they are servers, it is unlikely there isn't a dns entry against each of these ipv6.
Most nameservers disallow zone transers (requesting the full zone file), preventing this. Additionally it's more and more common for IPs to have a fixed generic PTR that just describes the IP instead of the host, and for a lot of hosts to not even have dns records. (My last webapp never bothered with dns for the dozens of ephemeral webserver instances).
It should be noted that there are two main protocols for mapping ports, UPnP and Port Control Protocol (or NAT-PMP, which is PCP version 0).
UPnP is dramatically more complicated and has correspondingly more implementation bugs. If you need to have something enabled on your router for mapping ports, use Port Control Protocol and disable UPnP.
I assume to open the firewall. If you're going to run IPv6 at home, you probably want the firewall equivalent of NAT: Connections are allowed outbound, but not inbound unless on a specifically whitelisted IP/port.
You can continue to use NAT with IPv6. If/when I have to run IPv6 on my LAN, I plan on doing exactly that. I explicitly don't want outside connections to be made directly to arbitrary machines inside my LAN. I have a DMZ for a solid reason.
Well, a router more than a firewall. Either way, a mechanism to do this is essentially a NAT.
What I want is a single IP address that is exposed to the internet at large, which is serviced by various different servers behind the firewall depending on the ports. The outgoing traffic from these servers should be from the same single IP address.
It's been well known since it first existed that UPnP is a security nightmare. If anyone really wants to use it, extra care should be taken to ensure that it is never exposed beyond your LAN, although it's far better to just disable it entirely.
It's too much to expect non-techies to know this, but they really, really need to be informed about it.
41 comments
[ 3.9 ms ] story [ 109 ms ] threadPrior to those times tracking protection wasn't critical in protocol design (or most people's minds in general) and so using the MAC was a great way to self select an address without extra steps.
With IPv4 you reveal the IP of your IP Masq/Nat router, which is often inside your home/business. It can be dynamic or static, but generally changes pretty slowly. There might be a single person behind that IP, or 100s.
With IPv6 your /64 is often inside your home/business. It can be dynamics or static, but generally changes pretty slowly. There might be a single person behind that /64, or 100s. Different outgoing connections see different IPv6 addresses, and they change over time (slowly).
Most importantly just like a mac address, the outgoing connections never use the IPv6 address based on mac address.
So how does the privacy extension not protect the privacy of users by hiding the mac address?
I never said it didn't. I stated that people overstate the protection the facility provides, not that it didn't provide protection.
The deficiencies of the privacy extensions have been discussed widely for years. A quick internet search will show the various criticisms and responses better than any reply I can make here will.
I should, however, clarify what I was trying to say -- I was not trying to say the privacy extensions aren't worthwhile. They're great, and people should use them!
What I was trying to say is that people often think of them as a panacea or a 100% solution. They aren't exactly that (what is?), and the nature of the design of the privacy extensions are such that they make other important network management activities more difficult.
My main criticism of PE (and it's not a showstopper sort of criticism) is that the extensions are hacky and it shows. They were thought up after-the-fact to try to mitigate a security mistake made in the original IPv6 protocol.
A decade later this still seems to be at least partly in place, as I'm able to browse the webserver running on an old colleague's desktop.
I think my sysadmin group would have a collective heart attack if they saw that setup! It's quite incredible to me how independent various parts (and pseudo parts like the national labs) are from each other.
You can be certain that most every packet in, out, or through the place gets captured and inspected by Bro (errr, I guess Zeek now. https://www.zeek.org/ )
I should also mention that not every host had a public IP. I worked with the group that managed midrange compute clusters, which were always behind NAT, with bastion login nodes.
Addresses don't have to be assigned that way. There are other ways of assigning addresses including privacy addresses and DHCPv6. The address space is so big that just generating a random address, while not RFC, is "okay" on all but huge networks if you're working in a /64.
So if you have turned off the firewall in your CPE, someone might heave an easier time scanning your network, without having to find your ip address from a http access log or using webrtc etc.
The property of scanning resitance due to address sparsity in IPv6 is not very strong (nor is it meant to be a security boundary) and there are many things like this that can go around it.
Same question for reverse dns?
UPnP is dramatically more complicated and has correspondingly more implementation bugs. If you need to have something enabled on your router for mapping ports, use Port Control Protocol and disable UPnP.
What I want is a single IP address that is exposed to the internet at large, which is serviced by various different servers behind the firewall depending on the ports. The outgoing traffic from these servers should be from the same single IP address.
That's a NAT in my book.
It seems that you did to me.
That's exactly what a firewall is for.
All I was saying is that you can use a NAT with IPv6 if you wish, and I'm interested in the sort of routing that a NAT can accomplish.
What specifically are you trying to achieve?
It's too much to expect non-techies to know this, but they really, really need to be informed about it.