How to avoid exposing my MAC address when using IPv6?

141

On my Macs, each IPv6 address includes the MAC address of a specific computer (not of my router). Sites such as ipv6-test.com not only show it, but even tell me it belongs to an Apple computer.

This feels like a super cookie, and might apply to other operating systems as well. How can I avoid my MAC addresses from being exposed?

Background: the MAC address is not in plain sight. Like for 2001:0db8:1:2:60:8ff:fe52:f9d8:

Take the last 64 bits (the host identifier) and add leading zeroes: 0060:08ff:fe52:f9d8.
Strip the ff:fe part from the middle. If these bytes are not there, then there's no MAC address.
For the first byte: complement the second low-order bit (the universal/local bit; if the bit is a 1, make it 0, and if it is a 0, make it 1). So: 0x00 (00000000) becomes 0x02 (00000010).
Presto: 60:8ff:fe52:f9d8 translates back to MAC address 02:60:08:52:f9:d8.

Note: since macOS 10.12 Sierra, according to Ars Technica Apple has adopted a new way of generating stable addresses that are not based on a MAC address, which Windows apparently had already been doing for years.

This question was a Super User Question of the Week.
Read the blog entry for more details or contribute to the blog yourself

Arjan

Posted 2011-02-09T17:26:12.443

Reputation: 29 084

@Arjan - nice work – Jeff Clayton – 2015-10-19T03:42:28.903

This is why I don't trust IPv6. – William Entriken – 2017-05-04T19:53:39.017

14Wow I did not know that about IPV6, nice find. – Supercereal – 2011-02-09T17:34:28.270

18Well, of course it shows an Apple computer. It is a MAC address, after all. – Graeme Perrow – 2011-11-14T17:05:53.053

@Kronos, an image has gone missing on the blog entry; http://blog.superuser.com/2011/02/11/did-you-know-that-ipv6-may-include-your-mac-address-heres-how-to-stop-it/ Adding ".stack" to the URL helps: http://i.stack.imgur.com/RNXoA.png

– Arjan – 2012-12-01T11:34:50.383

...but, @KronoS, adding ".stack" actually makes another image form that same blog post disappear, like http://i.imgur.com/vjK73.png (okay) vs http://i.stack.imgur.com/vjK73.png (not okay). In other words: maybe all images on the blog that do not currently use .stack should be re-uploaded...?

– Arjan – 2012-12-01T16:37:17.763

@Arjan I'm not sure. I'm going to have to check into this. I would like for a feature that all images uploaded to the blog are automatically uploaded to stack's imgur account. Similar to what the regular sites do currently – James Mertz – 2012-12-01T19:29:13.713

Answers

135

This is solved by two extensions to IPv6:

RFC 4941 aka "Privacy Addressing" lets outbound connections use temporary, randomly generated addresses (which are rotated every few hours).
RFC 7217 allows the primary, static address to be generated from an opaque hash which does not reveal any information.

At least one but increasingly both methods are supported by popular operating systems.

Note that these features are orthogonal. You can use both at the same time, if you want to.

Stable private addresses

In some operating systems, the MAC (EUI-48) address is simply no longer used for interface identifiers. Instead a random or hash-based identifier is used, generally according to RFC 7217.

Windows uses a custom scheme by default beginning with Windows Vista.

To check if the feature is active, run a PowerShell command:
```
Get-NetIPv6Protocol | fl RandomizeIdentifiers
```
To enable/disable the feature:
```
Set-NetIPv6Protocol -RandomizeIdentifiers Enabled
Set-NetIPv6Protocol -RandomizeIdentifiers Disabled
```
Linux (NetworkManager) supports RFC 7217 as of NetworkManager v1.2.0, using the connection profile's UUID as part of the seed. This feature is active by default in recent NM versions.

To enable or disable this feature:
```
nmcli con modify "<profilename>" ipv6.addr-gen-mode stable-privacy
nmcli con modify "<profilename>" ipv6.addr-gen-mode eui64
```
Linux (kernel SLAAC) supports RFC 7217 as of kernel v4.1.0; however, it must be manually activated by storing the secret seed via sysctl.

The secret key is a 128-bit hexadecimal string (shaped like an IPv6 address), that must be stored in the net.ipv6.conf.default.stable_secret sysctl. To make it persistent, it could be put in /etc/sysctl.d/50-rfc7217.conf or similar:
```
net.ipv6.conf.default.stable_secret = 84a0:d5aa:52b0:4d35:k567:3aa6:7af5:474c
```
Setting the secret automatically activates this mode for all network interfaces. To check whether the feature is active, look for "addrgenmode stable_secret" in ip -d link, or the value "2" in sysctl net.ipv6.conf.<ifname>.addr_gen_mode.

Temporary private addresses

As defined in RFC 4941, temporary privacy addresses are generated randomly and rotated every few hours.

Windows supports temporary addresses as of Windows XP SP2.

To enable/disable this feature:
```
netsh interface ipv6 set privacy state=enabled
netsh interface ipv6 set privacy state=disabled
```
Note that Windows no longer uses MAC-address-based primary addresses starting with Windows Vista.
Linux (NetworkManager): Recent versions of NetworkManager handle RA on their own, although the two values below have identical meanings to sysctl (2 = prefer privacy address, 1 = prefer main address):
```
 nmcli con modify <name> ipv6.ip6-privacy 2
```
Also, as of 1.2.0 a better mode became available, which changes the main address to no longer be MAC-based but instead unique for every network (RFC 7217):

(Note that privacy addressing is orthogonal to addr-gen-mode; it's possible to use both.)

Side note: As of 1.4.0, NM allows randomizing the MAC address itself, too. Set wifi.cloned-mac-address to stable to have a different MAC for every network (recommended), or random to randomize it for every connection (may cause problems).

In all cases, <name> must be the connection name, e.g. WiFi SSID or "Wired Connection 1". Use nmcli con to list all.

To make this the default for new connections, as of 1.2.0 you can change /etc/NetworkManager/NetworkManager.conf:
```
 [connection]
 ipv6.addr-gen-mode=stable-privacy
 wifi.cloned-mac-address=stable
```
Linux (kernel SLAAC) supports temporary addresses, but does not use them by default. They can be activated through sysctls.

To enable temporary addresses and make them preferred for outgoing connections:
```
 sysctl net.ipv6.conf.all.use_tempaddr=2
 sysctl net.ipv6.conf.default.use_tempaddr=2
```
To enable temporary address generation, but keep the static SLAAC address as preferred:
```
 sysctl net.ipv6.conf.all.use_tempaddr=1
 sysctl net.ipv6.conf.default.use_tempaddr=1
```
The all or default part can be replaced with a specific interface name; e.g. net.ipv6.conf.eth0.use_tempaddr.

(I used ip link set eth0 down && ip link set eth0 up to force an address assignment, but you can also run rdisc6 eth0 or just wait a few minutes for the next periodic Router Advertisement.)
Mac OS X – enabled by default since OS X 10.7 Lion:
```
 sysctl -w net.inet6.ip6.use_tempaddr=1
```
Temporary addresses, if enabled, will be preferred.

FreeBSD:

 sysctl net.inet6.ip6.use_tempaddr=1

 sysctl net.inet6.ip6.prefer_tempaddr=1

NetBSD:
```
 sysctl -w net.inet6.ip6.use_tempaddr=1
```
Temporary addresses preference? I have no idea. The autoconf address seems to be preferred. ifconfig doesn't appear to list any address properties.
OpenBSD – support added in 5.2; enabled and preferred by default in 5.3.
```
 ifconfig em0 autoconfprivacy
```
ifconfig shows "autoconfprivacy" next to temporary addresses.

Notes on configuration:

On Linux, OS X, and all BSDs, edit /etc/sysctl.conf to make the setting permanent.
On Windows, the changes will persist automatically. (You can append store=active to the netsh command if you want it to only last until reboot.)

Partially based on IPv6 Operating Systems at IPv6INT.net. See also General IPv6 Notes

If the hardware address is used in the IPv6 address, it usually means your network uses IPv6 Stateless Autoconfiguration. In such case, you can simply pick your own address suffix and configure IPv6 manually.

However, even though the manually added address will not have your hardware info, it will still be static (unlike with Privacy Addressing, which changes addresses every so often). Also, static addresses can be a pain in a network larger than 2-3 devices.

user1686

Posted 2011-02-09T17:26:12.443

Reputation: 283 655

IMO you should switch the sysctl commands for instructions on adding to /etc/sysctl.conf (or, on Arch Linux, /etc/sysctl.d/any_file_name). Lots of people may be busy and not read the whole post. Also, people will very rarely want to make this change just until the next reboot. – Zaz – 2015-06-04T20:42:53.347

2Nice side effect on my Mac and a FRITZ!Box 7340 router: I get two addresses in ifconfig. Outgoing connections use the random autoconf temporary address, which changes every now and then. Good! But for incoming connections (when opened up in my router), I can still use the autoconf address. I don't mind exposing that in DNS records (though maybe I could even somehow choose another address for that too). – Arjan – 2011-02-09T18:56:01.587

Ahh, after whois-spamming we now get IPv6 spamming: dig -t AAAA www.v6.facebook.com ;-)

– Arjan – 2011-02-09T20:10:55.563

6@Arjan: IPv6 addresses along the lines of de4d:b33f aren't that bad for memorizing; also, they're put in place by their owner, whereas whois spam is a) annoying and b) caused by outsiders who don't have control of your domain. – user1686 – 2011-02-09T20:13:59.333

As an aside: it seems (some of) the above might tell the OS to prefer the temporary address, but applications could still override this preference.

– Arjan – 2013-09-14T12:33:30.343

AFAICS using temporary addresses (IPv6 privacy) is effectively unusable with some ISPs due to router advertisements with an absurd short max lifetime of 40s, which overrides the kernel settings. Linux see ip a for preferred_lft. So ssh connections will break each 40s if you enable this feature. It's not even usable for normal web-surfers, as each download must be finished within 40s as well. – Tino – 2014-05-07T23:13:16.823

@Tino: They won't. preferred_lft only defines when the address should be used for new outgoing connections, but when it expires, the address still remains valid for the valid_lft time. So even in a normal situation, when a temporary address stops being preferred after 10 hours (and a new one is generated), it will still remain valid for around a week. – user1686 – 2014-05-08T13:20:34.137

@Tino: So this is only a problem when the routers set maximum valid lifetime to 40 seconds. This would break regular (non-privacy) SLAAC addresses too, in exactly the same way. (Though I'm not sure if it does – I think I remember setting mine to 30 seconds, just a bit higher than the advertisement interval, and it would just refresh every time an advertisement was received. I may be wrong.) – user1686 – 2014-05-08T13:21:36.397

@grawity: That is exactly what my ISP does. My ISP's router nails (unchangable) preferred_lft to 30s and maximum_lft (or what it's called) to 40s. SLAAC is unaffected because the MAC does not change, so the IP stays the same after refresh. The privacy address may change, Kernels seem to differ here and I don't know why (yet). On Debian with a 2.6.x kernel, the IP changes each 30s (and is approx. 45s usable), while on a crrent Ubuntu the address changes only with reboots (AFAICS) when I enable privacy. – Tino – 2014-05-09T17:02:40.357

FYI, this only applies to certain IP addressing schemes. More than likely you (or your ISP) are using IPv6 autoconfiguration, which requires a fairly large block of IPs to accomplish in the first place. The solution could be to turn this feature off. Your ISP might use DHCP to assign addresses as well, which is still possible with IPv6.

Ernie Dunbar

Posted 2011-02-09T17:26:12.443

Reputation: 679

Apparently, one reason to assign at least a /56: "ISPs that only hand out a single /64 prevent you from any subnetting at all. If that /64 is on the WAN interface then you'll never get decent IPv6 on your LAN(s). This is the ISPs fault and they should fix this by giving out a decent amount (/48 or /56) of addresses."

– Arjan – 2014-07-27T13:07:45.420

7A /64 is not "a fairly large block"; it is the smallest reasonable allocation block for a subnet. Several IPv6 features require that a subnet be /64, and you have forgotten (or not realized) that IPv6 was designed in large part to prevent anyone ever running out of addresses ever again. You must free your mind from the old thinking of needing to conserve precious addresses; it has no place in IPv6. – Michael Hampton – 2015-02-22T16:54:29.003

2@Ernie: Not at all. There are enough /48s (networks with 2^80 addresses) that each person could have about 40,000. ISPs should be giving out /56s at the very least. – Zaz – 2015-06-04T20:59:06.940

1"... free your mind from the old thinking of needing to conserve..." famous last words – William Entriken – 2017-05-04T19:55:47.707

I have a static /56 and use my isps stateless autoconfig and afaik sysctl net.ipv6.conf.all.use_tempaddr=2 sysctl net.ipv6.conf.default.use_tempaddr=2 work since I can't get a reverse dns to stick to the ipv6 addresses which means they can't be the same. – orange_juice6000 – 2019-04-27T15:38:37.633

As for large blocks: according to Wikipedia in "General allocation": RIRs assign smaller blocks to ISPs, which then distribute this in /48 sized parts to their clients. Indeed, my ISP also assigns /48 prefixes to consumer-grade subscribers. Not too odd then?

– Arjan – 2011-02-09T21:47:00.377

A single /48 will be sufficient for every last customer they have until the end of time, regardless of growth (2^80 hosts!). While this might seem like overkill, it certainly makes routing simple. A /96 network would be sufficient to provide IP addresses for the entire IPv4 internet. Any network smaller than a /64 wouldn't allow MAC autoconfiguration. – Ernie Dunbar – 2011-02-10T17:27:13.793

2I mean that I myself have a /48 block for my Macs, printer, Squeezebox, fridge and toaster, and whatever other 2^80 machines I decide to hook up. And so do all other subscribers at my ISP. And all of that appears to be quite common according to Wikipedia. – Arjan – 2011-02-10T18:22:02.923

1eh, what? I can't even think of a reason to assign a /64 to a single residential client (beyond autoconfiguration, and even that is pointless), let alone a /48. They say that the only possible reason for IP exhaustion in IPv6 would be astonishingly poor address allocation, and it looks like your ISP qualifies. – Ernie Dunbar – 2011-02-10T18:49:53.830

Then blame Wikipedia, and Arin's draft IPv6 Addressing Plans: All customers get one /48 unless they can show that they need more than 65k subnets. But also: If you have lots of consumer customers you may want to assign /56s to private residence sites — which still is more than I ever need. ;-) But, things might change: my ISP never promised this, though obviously their customers have configured modem/routers based on this.

– Arjan – 2011-02-10T19:02:49.470

3I think when Arin says "customer" they mean "ISP". Any ISP (including very, very large ones) can allocate a single /64 for their entire network and be done with it. No further routing required. But allocating blocks of IP addresses numbering in the trillions to joe-average residential customers is downright foolhardy. – Ernie Dunbar – 2011-02-10T19:42:57.487

1I'm quite sure that's not what that page means, as otherwise If you have lots of consumer customers you may want to assign /56s to private residence sites would be pointless? Apart from that: I'm no expert; just quoting what I've linked to, and what I'm using myself. – Arjan – 2011-02-10T19:53:14.850

Just noticed that the link in my above comment links to a now old version: see IPv6 Addressing Plans for the current Arin proposal. No changes in All customers get one /48 unless they can show that they need more than 65k subnets. [...] If you have lots of consumer customers you may want to assign /56s to private residence sites. though.

– Arjan – 2011-04-12T11:38:59.380