Despite the Headlines, SLAAC Does Not Represent a Zero-Day Attack Vector

SLAAC is a mnemonic for IPv6 StateLess Address AutoConfiguration, which follows attempts at obtaining router information that happens only after the interface has established an IPv6 address for the local link. IPv6 does not use Ethernet broadcasting, which imposes scaling limitations on the devices supported on a local link. Instead, IPv6 multicasting divides devices into 16.7 million isolated Solicited-Node groups based on the last 3 bytes of their IPv6 address. Multicasting represents a significant departure from the way networks previously worked using the blunt method of broadcasting.

IPv4 and MAC Address Relationship with Network Interface Unverified

Under IPv4, IP addresses are determined using the ARP [RFC826] to request MAC addresses associated with a specific IPv4 address by using a broadcast (all one’s) destination for the MAC address recognized by switches and interfaces and replicated or flooded across all switch ports. ARP can also announce an address by setting both source and destination IPv4 addresses to the same value or to probe by setting the source to a null IP address.

The inverse of ARP was BootP described in [RFC951] back in 1985. BootP requests an IP address for the MAC address by using a broadcast (all one’s) destination IP address. BootP was superseded by DHCP. Those new to IPv6 are often surprised to find how multicasting rather than broadcasting changed the way networks, switches, and routers operate.

Router Advertisements Define the Local Network with IPv6

Customer premises equipment (CPE) shipped by Free, a subsidiary of Iliad and the second largest Internet service provider in France, provides DNS configuration in their router advertisements, which eliminates a need for DHCP for most environments. This feature was a modification that included DNS configurations in router advertisements made by [RFC5006] back in 2007 that was replaced by [RFC6106] in 2010. Having this feature removed the need to use DHCP, which was important because neither Windows XP or Mac OS X included a DHCP client able to talk over IPv6.

Untrustworthy Network Interface Assignments

Rather than worrying about an attack somehow associated with SLAAC, the issue is really related to spoofing router advertisements. This problem is similar to spoofing either ARP or DHCP responses. IT managers may imagine there are practical controls able to limit the extent of this risk with IPv4. There are not. Even secure switch ports restricting the use of MAC addresses offer limited protection for either IPv4 or IPv6 protocols. These restrictions will not mitigate the ARP spoofing risk that exists with IPv4, for example. There is still significant risk when a compromised system is within the local network where it is free to tamper with traffic. So, consider RA spoofing the same problem having similar outcomes. Don’t be confused and react to the use of different terminologies that express the perennial local network spoofing threat.

Verifiable Address Assignments

However, unlike IPv4, IPv6 does not really need a labyrinthine arrangement of device- and protocol-specific restrictions when Secure Neighbor Discovery (SeND) is supported. Although the major OS vendors do not support SeND, major networking equipment manufactures do and can enforce this protocol within their equipment as well. One alternative is to try ACL-based methods at restricting which devices are allowed to play the role of router.

Reacting to this concern by disabling IPv6 overlooks many features and applications that depend on IPv6 being made available using various methods within the OS. Not having IPv6 running on the local network will likely increase the number of unseen tunnels enabled by OSs reverting to their “interim” strategy behaviors. IPv6 represents the future growth of the Internet where it is prudent to enable this architecture and to keep it out in the open where traffic can be better monitored.

Learn how to protect Enterprises, Small Businesses, and Home Users from ransomware: