140

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

  • 14
    Wow I did not know that about IPV6, nice find. – Not Kyle stop stalking me Feb 9 '11 at 17:34
  • 17
    Well, of course it shows an Apple computer. It is a MAC address, after all. – Graeme Perrow Nov 14 '11 at 17:05
  • @Kronos, an image has gone missing on the blog entry; blog.superuser.com/2011/02/11/… Adding ".stack" to the URL helps: i.stack.imgur.com/RNXoA.png – Arjan Dec 1 '12 at 11:34
  • ...but, @KronoS, adding ".stack" actually makes another image form that same blog post disappear, like i.imgur.com/vjK73.png (okay) vs 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 Dec 1 '12 at 16:37
  • @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 Dec 1 '12 at 19:29
134

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.

  • 2
    Nice 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 Feb 9 '11 at 18:56
  • Ahh, after whois-spamming we now get IPv6 spamming: dig -t AAAA www.v6.facebook.com ;-) – Arjan Feb 9 '11 at 20:10
  • 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. – grawity Feb 9 '11 at 20:13
  • 1
    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 Sep 14 '13 at 12:33
  • 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 May 7 '14 at 23:13
1

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.

  • 3
    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 Feb 9 '11 at 21:47
  • 3
    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 Feb 10 '11 at 19:02
  • 3
    I 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 Feb 10 '11 at 19:42
  • 3
    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 Jul 27 '14 at 13:07
  • 7
    A /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 Feb 22 '15 at 16:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.