|
It has been six (6) years since I last wrote about SLAAC. With the latest standard, RFC 8981, it is time to revisit it, and understand how it has evolved over the years.
Stateless Address Auto Configuration (SLAAC) was a novel improvement over the static address configuration of IPv4 in the late 1990s. It rose out of the interesting quandary of how to create a globally unique address without the help of any servers. In the early days of SLAAC, the interface MAC address, expanded to a EUI-64, was used to create the IID (Interface ID) or last 64 bits of the IPv6 address.
History of adding Privacy to SLAAC
Privacy issues arose rather quickly, since MAC addresses are burned into the interface card, and therefore do not change. The concern was that with a static global IPv6 address, users could be easily tracked (web-based cookies were still in their infancy at the time).
Over the years, SLAAC and Privacy have been revisited by the IETF:
- in 2001: RFC 3041 – Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (Obsoleted by: RFC 4941)
- in 2007: RFC 4841 – Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (Obsoleted by: RFC 8981)
- in 2021: RFC 8981 – Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 (current standard)
RFC 3041 – Privacy Extensions for Stateless Address Autoconfiguration in IPv6
In 2001 RFC 3041 introduced the concept of Privacy Extensions for SLAAC. IPv6 already had the concept of multiple addresses, since every interface had a Link-Local, and a Global Address.
An additional address, the Temporary Address was added. The Temporary Address would use an algorithm to create a randomized IID. A new Temporary Address would be generated on a daily or weekly basis (RFC 3041 is fuzzy on this point). A new Temporary Address would be generated just before the existing one expired.
Temporary Addresses would be used for outbound connections, thus providing some level of privacy and “makes it more difficult for eavesdroppers and other information collectors to identify”1 the user.
RFC 4941 – Privacy Extensions for Stateless Address Autoconfiguration in IPv6
The IETF updated the standard of using Privacy Extensions in 2007 with RFC 4841. The key differences from 2001 are:
- Exclude Anycast (RFC2526) addresses from potential Temporary Address pool
- Add User configuration to enable/disable Temporary Addresses
- Duplicate Address Detection (DAD) must be run on all new Temporary Addresses, not just the first
- Default state of Temporary Addressing is disabled
- Different IIDs for different Prefixes are allowed
- Algorithm used to generate random IIDs is no longer limited to MD5
Hosts would still use the MAC address (EUI-64) to create a Stable Address, and create Temporary Addresses in addition to the Stable Address.
RFC 8981 – Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6
Fast forward to 2021, where IPv6 adoption is running at 35% (based on Google’s IPv6 Stats), and privacy has become a real concern of internet users.
The key changes from the 2007 (RFC 4941) standard:
- Configuration of Stable Addresses are no longer required, a host is permitted to only instantiate Temporary Addresses
- Temporary Addresses are now enabled by default
- Reduces the maximum life time of Temporary Addresses from 1 week to 2 days, and concurrent Temporary Addresses from 7 to 3
- A life time randomization is also introduced, Temporary Addresses will no longer have the same lifetime
With these changes, a host now can only have Temporary Addresses and the duration of each will be different. Finally, IPv6 web surfers will have Internet anonymity similar to those hiding behind IPv4 NAT.
Privacy vs Usability
The standard around SLAAC and Privacy has been evolving. As the major OS’s implement the latest round of changes (in RFC 8981), the use of Temporary Addresses will increase, since the default has changed to enabled.
In the Enterprise
I see this as introducing some problems with the use of SLAAC. Enterprises, which have non-reputability requirements, want to be able to link an Address with an employee. In the past, DHCPv6 has been the solution, since a host will obtain the same address (or IID) every time, making security and non-reputability easier. However, not all OS’s implement DHCPv6, most notably Android. Android phones and IoT that is based on Android will continue to use SLAAC into the future. I don’t expect that Enterprise IT will welcome the change that SLAAC Temporary Addresses on devices are now enabled by default.
In the SOHO (Small Office/Home Office) Networks
A higher level of Privacy is usually desired in smaller networks, where plug-and-play are important to deployment. I see SLAAC more often deployed in these smaller networks because of the simplicity. But with the option of hosts only using Temporary Addresses, reachability can be an issue. The SOHO network will have to rely on mDNS and Service Discovery to find printers, security cameras, and other IoT devices. Unfortunately not all IoT will implement Bonjour/Avahi (Service Discovery Protocols).
In long-lived TCP connections
Since Temporary Addresses will be enabled by default, and are used by out-bound connections by default, what is to happen to long-lived TCP connections, such as ssh to remote devices.
When Temporary Addresses age out, these long-lived TCP connections are broken. With a single ssh session, there is little effort in logging in again. But what if the host is an IT management station, and there are many ssh TCP sessions, all seemingly randomly aging out? Suddenly, it is no longer fun.
Fortunately, the authors of ssh saw the need to bind a ssh session to a specific source IP address. If the host has a Stable Address, one just needs to bind the session to the Stable Address as a source address. This is done with a -b option where myhost.example.com is the DNS name of my Stable Address.
ssh -b myhost.example.com remotehost.example.com
Another type of long-lived TCP session is one of file sharing, or mounting a remote server on the local filesystem, making it easy to do file operations. sshfs not only is an excellent way to do file sharing, but the link is encrypted (since it uses ssh under the covers). However, sshfs will also fall prey to every changing Temporary Addresses, breaking those file sharing connections.
Unfortunately, sshfs does not have a -b option, but it does implement ssh‘s -o options mechanism. One can bind a file sharing to a local Stable Address by:
sshfs -oBindAddress=myhost.example.com remotehost.example.com:/tmp local_mount_point/
Erosion of SLAAC Simplicity
The Privacy pendulum has swung to the more privacy side with the latest SLAAC Temporary Addresses standard (RFC 8981), and only time will tell if more networks gravitate towards, or away from using SLAAC. SLAAC had the upper hand on simplicity, but the complexity of creating a Semantically Opaque Stable Address (RFC 7217), and managing up to three Temporary Addresses, each with their own lifetime timers has eroded that simplicity.
I can see use-cases for Temporary-Address-only hosts, such as web-surfing at a coffee shop, but in stable networks, such as Enterprise or SOHO, having Temporary Addresses enabled by default may be a challenge.
Notes:
- 1) Quote from RFC 3041 Abstract
Really good article.
It makes easier to understand the SLAAC evolution and the considerations to address for better deployments. And as mentioned in our meetings, IPv6 is not an static thing, it is in continue change for the benefit of all, I hope.