Here’s the fourth and final entry of Cisco Press author and chair of the Rocky Mountain IPv6 Task Force Scott Hogg’s multi-part blog on IPv6 addressing. This week: dealing with IPv6 privacy addressing.
We hope these particular blog entries have been helpful. Please check back soon for additional technical blog posts on IPv6 adoption. Also, be sure to check out the Infoblox IPv6 CoE page for more IPv6 adoption resources.
Thanks Scott! -Tom
PRIVACY ADDRESSING/TEMPORARY ADDRESSING POLICY
When IPv6 was first being defined in the standards organizations concerns arose of the use of a node’s MAC address to form the last 64 bits of the IPv6 address. The EUI-64 technique uses the 48 bytes of the MAC address split into two 24-bit sections with a predetermined set of bits (FFFE) in between (not counting the universal/local bit). The concern came from the fact that no matter what subnet the user’s computer was on it would have an identifiable interface identifier, making it easy to track a user’s activity and thus identity. To avoid this issue, the IETF created an RFC titled “Privacy Extensions for Stateless Address Autoconfiguration in IPv6” (RFC 3041). This IETF RFC was later updated “Privacy Extensions for Stateless Address Autoconfiguration in IPv6” (RFC 4941).
Privacy addresses use an MD5 hash of the EUI-64 concatenated with a random number that can change over time to create the interface identifier. Different implementations of this RFC rotate the address at different frequencies and some implementations allow this feature to be disabled.
The security issue that privacy addressing creates is that forensics and troubleshooting are made increasingly difficult with privacy addresses. Because the IPv6 address may be assigned in a stateless way, network and security administrators would not know what IPv6 address any node had at any given point in time. Privacy addressing also requires Dynamic DNS (DDNS) and firewall state to update every time the address changes. This adds difficulty to creating granular firewall policy when IP addresses change often. Therefore, systems used with firewalls should use static IPv6 addresses instead.
While privacy addresses have their place in allowing users to anonymously communicate with servers there are some security trade-offs to this privacy. When we talk about individuals using their own home computers to connect to the Internet that is one thing. However, when we talk about a company’s internal network the use of the computer for personal use is typically not within the “acceptable use policy”. Therefore, preserving a user’s privacy on a corporate enterprise network is not a “right” that must be granted.
One could argue that the MAC address of a host is already used within the source address of an Ethernet II frame. The MAC address can be changed locally on a computer if the administrator of that system desires to change it. The organizations that assign OUIs to NIC manufacturers have no way of tracking which user their allocations were given to and which user ended up with which MAC address. The lower 64 bits of the IPv6 address don’t necessarily have to use the MAC address, but they do have to be unique.
Privacy extensions are supported by default on Windows XP, Server 2003, Vista, Server 2008, and Windows 7 but not supported on Windows NT or Windows 2000. On Windows XP you can run the “netsh interface ip6 show privacy” command to display the parameters of the privacy extension addresses. Privacy extensions can be disabled on Windows XP by running the “netsh interface IPv6 set privacy state=disabled” command.
To disable privacy extensions on a Linux host you simply use the following command.
echo “0” > /proc/sys/net/ipv6/conf/default/use_tempaddr
Windows 7 does not use the EUI-64 technique by default when forming its interface identifier. Microsoft has blurred the lines between these two address autoconfiguration concepts with their temporary addresses and now their randomly-generated interface identifiers. However, thankfully Microsoft has given us the ability to disable or enable this feature as needed with the following commands.
netsh interface ipv6 set global randomizeidentifiers=disabled
netsh interface ipv6 set global randomizeidentifiers=enabled
Microsoft has provided a setting to prevent the use of privacy extension; this setting can also be deployed with a Active Directory (AD) to all hosts member of the AD domain. The commands are:
netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent
netsh interface ipv6 set privacy state=disabled store=persistent
Linux systems also support privacy and temporary addressing. To configure a Linux system to use privacy addresses enter the following commands.
sysctl net.ip6.conf.eth0.use_tempaddr=2
sysctl net.ipv6.conf.all.use_tempaddr=2
If you want to configure the Linux system to enable a temporary IPv6 address along with the autoconfigured address, then enter the following command.
sysctl net.ipv6.conf.all.use_tempaddr=1
BSD systems are also capable of supporting privacy extensions. The following commands can be used on a FreeBSD system to enable IPv6 privacy addressing.
sysctl net.inet6.ip6.use_tempaddr=1
sysctl net.inet6.ip6.prefer_tempaddr=1
To enable privacy addressing on a NetBSD, enter the following command.
sysctl -w net.inet6.ip6.use_tempaddr=1
Apple MAC OS X also supports temporary addressing and it is enabled on MAC OS X 10.7 Lion by default. The following command can be used to set this manually.
sysctl -w net.inet6.ip6.use_tempaddr=1
Solaris 10 does not have privacy addresses enabled by default. Temporary addresses can be configured by using the Neighbor Discovery Daemon (in.ndpd). The settings are controlled by the /etc/inet/ndpd.conf file. Enter the following command to this file to enable the use of privacy addresses.
ifdefault TmpAddrsEnabled true
To enable privacy addressing on a per-interface basis you can add the following line to the /etc/inet/ndpd.conf file.
if interface TmpAddrsEnabled true
For example, if a Solaris 10 system is using an interface named pcn1, you place the following entry:
if pcn1 TmpAddrsEnabled true
For the above-mentioned reasons, many organizations will not use privacy addressing or temporary addressing on any server or system with the internal network or engineering network or for any application server. Most critical servers will have statically configured IPv6 addresses. Many enterprises should use DHCPv6 as the preferred method of dynamically assigning addresses to hosts, and then use Extended Unique Identifier 64 (EUI-64) if DHCPv6 is not available. The issue here is that many organizations currently have a large population of Microsoft Windows XP and older Apple Mac OS X systems that do not have native DHCPv6 client software. Regardless, organizations should keep track of what IPv6 addresses all hosts are using. However, some may allow subscriber mobile devices to use privacy addressing for accessing the Internet.
SUMMARY
Enterprises should prefer the use of DHCPv6 over SLAAC or Stateless DHCPv6 for dynamic address assignment to end-nodes. DHCPv6 provides the security benefits of privacy addressing, but allows for the management and forensic information required to operate the network environment.
Following is a listing of a typical address preference order for systems in an enterprise environments:
Servers/appliances in data centers, DMZ, or cloud:
· Statically assigned
· Stateful DHCPv6 – very rare cases and only by approval
· SLAAC – never allowed (possibly disable RA messages)
Host based end-node systems internal to the enterprise:
· Stateful DHCPv6
· Stateless DHCPv6 (if nodes do now support DHCPv6)
· SLAAC – only if no other means is supported.
· Privacy addresses are not allowed at all.
eof
