by Craig Miller
 |
| MACs exposed* |
For the most part, this works quite well. Most MAC addresses are unique (although they only need to be unique within the same broadcast domain). But it has problems when it comes to hardware repair. What happens when you need to replace a NIC card, the GUA changes. Not good.
I have argued in the past that this was a small issue, since servers are probably going to have static IPv6 addresses, which get mapped in DNS to names. Therefore changing a NIC card won't change your GUA.
Exposing information
Other's have expressed concerns that using the MAC address in the GUA exposes that information to the outside world. But on the far side of a router, the MAC address is no longer significant, and therefore pretty useless for network attacks.But sharing the MAC address globally does reveal the hardware vendor of your NIC, since the first 3 bytes of a MAC address is registered to a manufacturer. This may lead some try to infer an installed OS, and limit their attacks based on this assumption. But the privacy extensions (RFC 4941) have all but eliminated this problem, since temporary GUAs are used for outbound connections.
When infinite is only 16 million
But in-bound connections are still received on the SLAAC MAC-based GUAs. Reading RFC 7707 (Network Reconnaissance in IPv6 Networks) has convinced me that it is time to move beyond the old MAC-based GUA. RFC 7707 discusses how an attacker can limit the number of addresses being probed from the 2^64 address space by selecting a common NIC vendor (such as Apple, 10:9a:dd:xx:yy:zz) thus reducing the address pool to 2^24. Or in more humanly understandable numbers reducing the potential address from 1 in 18,446,744,073,709,551,616 to 1 in 16,777,216 (or 16 million). Suddenly, the seemingly infinite address space of 2^64 is quite manageable to probe.A Standard to the rescue
Fortunately, there's a new standard to disconnect the MAC address from the GUA. RFC 7217 (Semantically Opaque Address Generation). Rather than use the MAC address, the RFC recommends using a cryptographic method to generate the lower 64 bits of an address. This opens the entire 2^64 address space again for a GUA on a device. Making it very difficult to guess by an attacker.The latest version of Mac OSX (10.12) and Windows (10) support this method of GUA generation. Unfortunately, Linux a former leader in the realm of IPv6 support, is behind. A feature enhancement (#4625) has been submitted to systemd for RFC 7217 support.
SLAAC, letting you slack off
Where does this leave us? IPv6 is improving, clever people are fixing the problems of the earlier implementations. With RDNSS (see IPv6 RA, RA, RA) and Semantically Opaque addresses, a SLAAC environment can be viable option to run IPv6 networks with the minimum of management hassle**.* Macadamia Nuts in and out of the shell
** OK, if you have Windows machines on the network, it may not be enough (see Dual Stack, the good, bad, and ugly)
