148

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

7
  • 15
    Wow I did not know that about IPV6, nice find. Feb 9 '11 at 17:34
  • 22
    Well, of course it shows an Apple computer. It is a MAC address, after all. 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 Dec 1 '12 at 19:29
143

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 primary interface identifier is no longer generated from MAC or EUI-64 – instead it is generated using a hash or random seed (usually according to RFC 7217)

This kind of address is still static per network – the same OS on the same machine within the same IPv6 prefix should always generate the same suffix. It is suitable for incoming connections.

  • Windows beginning with Windows Vista uses a custom scheme.

    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
    

    This can also be done using netsh interface ipv6.

  • NetworkManager on Linux supports RFC 7217 starting with NM 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
    
  • systemd-networkd kind of supports RFC 7217 using this .network file option, but appears to require you to explicitly list network prefixes for which this mode should be used:

    [Network]
    IPv6Token=prefixstable:2001:db8:abcd:123::/64
    

    If no prefixes match, it will still fall back to EUI-64 method.

  • dhcpcd on Linux/BSD supports RFC 7217 using this option in /etc/dhcpcd.conf:

    slaac private
    

    To disable this feature and use traditional EUI-64 identifiers:

    slaac hwaddr
    
  • Linux kernel SLAAC supports RFC 7217 as of Linux 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), which you can generate using:

    uuidgen | sed "s/-//g; s/..../:&/g; s/^://"
    

    This secret key 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 file:

    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

This feature (defined in RFC 4941) provides additional addresses which are generated randomly and rotated every few hours. These addresses are used for outgoing connections only – you still retain your MAC-based or RFC7217-based primary address for incoming connections.

  • 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 now supports hash-based primary address generation starting with Vista, so this feature isn't as critical.

  • NetworkManager on Linux: 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
    

    Note that NetworkManager now supports RFC7217-based primary address generation starting with v1.2.0, so this feature isn't as important.

    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
    
  • dhcpcd supports temporary address using the slaac ... temporary sub-option:

     slaac private temporary
    

    or

     slaac hwaddr temporary
    
  • Linux kernel SLAAC supports temporary addresses, but does not use them by default. They can be activated by setting these sysctls:

     sysctl net.ipv6.conf.all.use_tempaddr=2
     sysctl net.ipv6.conf.default.use_tempaddr=2
    

    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
    
  • Older NetBSD versions:

     sysctl -w net.inet6.ip6.use_tempaddr=1
    

    Latest NetBSD appears to no longer have kernel SLAAC support, in which case follow dhcpcd instructions instead.

  • 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.

9
  • 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
  • 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
    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
  • 1
    @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
    May 8 '14 at 13:20
  • 1
    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
    Jun 4 '15 at 20:42
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.

13
  • 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. 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
  • 9
    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. 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.