A friend sent me a message recently asking about the advisability of assigning a DNS
AAAA record (for an IPv6 address) to a computer’s current IPv6 address. He wrote, One thing that I wasn’t certain about with IPv6 was whether or not this address could/would change in the future. As such, I wasn’t sure if I should create the AAAA record using it. Fun!
I knew that machine in question runs Linux and that it acts as a server, always running on the same firewall-protected network.
His question gets to an interesting thing, and configurable too.
Most networks that currently run IPv6 are set up to use stateless autoconfigured IPv6 addresses—as opposed to static addresses or those handed out by a DHCPv6 server (which is actually completely different from an IPv4 DHCP server). This is a cool thing: an IPv6 network doesn’t need a DHCP server. IPv6 has self-help addressing baked into the protocol.
From MAC to address
Stateless autoconfigured addresses are typically based on the ethernet MAC. Most operating systems let you find your MAC(s) pretty easily.
- Linux – here the MAC is
[bash]$ /sbin/ip link show dev eth0 2: eth0:
mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000 link/ether dc:69:ae:40:45:10 brd ff:ff:ff:ff:ff:ff
- Mac OS X – here the MAC is
[bash]$ /sbin/ifconfig en1 en1: flags=8823
mtu 1500 ether 28:cf:e9:38:a0:fb nd6 options=1 media: autoselect ( ) status: inactive
- Windows (from a
cmd.exeprompt) – here it’s
00:1a:4a:8a:43:4d, but note the different presentation, using hyphens instead of colons
C:> ipconfig /all … stuff snipped … Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : domain.com Description … … … . . : Red Hat VirtIO Ethernet Adapter Physical Address… … … : 00-1A-4A-8A-43-4D
An ethernet MAC is a 48-bit number, but the interface-identifier portion of an IPv6 address is usually 64 bits, so padding is added. The Cisco support forum has a good explanation of how a MAC becomes the host portion of an IPv6 address.
Avoiding the trackers
You can easily imagine bad information-leakage scenarios, however, if a machine’s MAC is that easy to get from an address. It’d be relatively trivial to follow someone across networks merely by following the trailing 64 bits of their addresses. Even without a user logging in, Google could identify unique machines merely from their IPv6 addresses as they traveled from hotspot to hotspot.
So the RFC writers of the world created the concept of IPv6 temporary addresses, aka privacy extensions. The idea is that these are short-lived, randomly generated 64-bit interface identifiers that can be used as the source address for outbound internet connections. They are obsoleted fairly quickly, so the addresses themselves don’t aid machine tracking.
The temporary addresses live alongside the MAC-based autoconf addresses, and both can be used. OS X (since Lion), iOS, Windows (since Vista), Windows Server (since 2008), and Android (since version 4) all prefer temporary addresses for new outbound connections. If you use IPv6 to contact a web site, these operating environments will prefer to use a temporary address, making is difficult for anyone to track you by your address alone.
Controlling the privacy extensions
Is OS X since Lion, the
sysctl utility can be used to enable or disable your machine’s use of temporary IPv6 addresses. By default, it’s enabled:
[bash]$ /usr/sbin/sysctl net.inet6.ip6.use_tempaddr net.inet6.ip6.use_tempaddr: 1
If you’re running OS X as a server, you may want to disable them entirely:
Alternatively, newer versions of OS X allow you to use temporary addresses but prefer the MAC-based one:
In the world of Linux, each distribution family chooses its own default policy concerning the creation and use of temporary addresses. Administrators can, of course, override the default policy should they so choose.
The Linux kernel can operate in three different IPv6 autoconf modes; each system has a default setting, which can be overridden on any given interface. Just like in OS X, the
sysctl utility is used, but unlike OS X, Linux rolls preferance and usage into a single entry that can have one of three settings:
0: don’t use temp addresses (default in CentOS, Fedora, and Debian)
1: use temp addresses but don’t prefer them
2: use temp addresses and prefer them (default in Ubuntu)
For a better explanation, see this fine blog post.
Also unlike OS X, the system’s default setting can be overridden on any given interface.
# set the default to use and prefer temp addresses /sbin/sysctl -w net.ipv6.conf.default.use_tempaddr=2 # disable temp addresses on wired interface eth0 /sbin/sysctl -w net.ipv6.conf.eth0.use_tempaddr=0
The bottom line
For servers, I see no reason to use temporary addresses except in odd cases like web spidering where the randomization might be helpful. For mobile systems, temporary addresses should certainly be the default, since they are the machines most susceptible to tracking.