Archive for July 2014

Consistency of EUI-64 (MAC) based IPv6 addresses   Leave a comment

During a recent meeting we had a discussion about how static or consistent SLAAC IPv6 addresses are in the context of EUI-64 based addresses. My contention was that EUI-64 based IPv6 addresses are largely static. So here is what I meant when I said these are largely static.

What is a MAC derived IPv6 address, and does it change?

Consider this arbitrary IPv6 address, fd9a:1111:2222:3333:250:11ff:fe22:3344.

Like all IPv6 addresses this is composed of two 64 bit portions. (See IPv6 interface identifiers or RFC 4291 for additional information.) In this case those areā€¦
network identifier: fd9a:1111:2222:3333
host identifier: 250:11ff:fe22:3344

The network portion, (first part), fd9a:1111:2222:3333, represents the subnet and comes from the router advertisement.

When might that change? It could only change have to be configured at the router, and it would result from a network admin, or somebody like that, deciding to change network addresses, which would then involve setting up the corresponding routes through the network. It is possible, but in an environment like ours, it’s unlikely without advanced notification as this would affect firewall rules, and would even break manually entered static addressed systems without a fair amount of coordination. Ultimately this network portion of the address should be as unchanging as a static address that is manually entered.

The second part, (host portion), 250:11ff:fe22:3344, is calculated by the host.

Before we look at the potential for change, let’s examine this part of the address. It is important to realize that the ‘250’ portion is really a short hand way of writing ‘0250’. So the host portion really looks like 0250:11ff:fe22:3344, when you consider all 64 bits. Because of the ‘ff:fe’ portion in the middle of this host identifier, we can also infer that it is based on the 48 bit MAC address of that interface, which is actually treated as an EUI-48 number when used to calculate an EUI-64 based IPv6 address. (That fact is only important in explaining why we always see ‘ff:fe’ in the address.)

To translate the above IPv6 address back to the MAC address:

  1. First we drop the network identifier fd9a:1111:2222:3333 which is irrelevant, since it pertains only to the network.
  2. We remove the fffe in the middle and scrunch the numbers together, like so: 02-50-11-22-33-44.
  3. The last thing to do is to invert the 7th bit in from the left, commonly known as the U/L bit, and we end up with 00-50-11-22-33-44.

To convert the MAC address to EUI-64 and IPv6 address:

  1. The MAC is treated as EUI-48 and we plunk ‘fffe’ in the middle: 0050:11ff:fe22:3344
  2. Then again we flip the 7th bit in from the left: 0250:11ff:fe22:3344
  3. Given the host portion of the network, it can be combined with any network prefix for a network, to which the interface is connected, forming a valid v6 address.

As you can see, this method for calculating an IPv6 address does not really allow for any wiggle room in terms of changing the host portion of the address without also changing the MAC address, or more to the point the Ethernet address. Certainly it is possible to do that, but it implies that the Admin must do that intentionally, and therefore plan for it. The implication then is that, if neither network or host portion are likely to change, the address is consistent.

What about DAD?

At this point some people wonder, well what about Duplicate Address Detection. It is true that all unicast IPv6 addresses must go through duplicate address detection, and especially with locally managed MAC addresses, it is possible to get duplication. If the address that fails that process than it cannot be used. Here are some points to help explain the implications:

  • A duplicate MAC address on a network is not a normal accepted condition. If you have duplicate MAC addresses on the same network something is already broken at the Ethernet layer.
  • A link-local address is always the first address configured using SLAAC. (RFC 4862: 4)
  • While it is theoretically possible for a EUI-64 derived IPv6 address to be a duplicate, the behavior of Duplicate Address Detection (DAD) implies that the interface would be disabled as a result when a link local address is detected as a duplicate. (RFC 4862: 5.4.5)
  • Because all EUI-64 derived IPv6 addresses for a given network interface are derived from the same MAC address and have the same host identifier, it is reasonable to assume either they are all unique or the interface would be disabled and non-functional until fixed regardless of the network prefix. This does not reflect on an instability of IPv6 addresses derived from MAC addresses, but rather on a dependency that the Ethernet layer not be broken, but that dependency is there no matter how IPv6 addresses are assigned.

What about changes in MAC addresses?

Without a doubt systems do change their MAC addresses. This happens most often when there is a change in the hardware. In those instances, when using IPv6 addresses derived from a MAC address, there can be implications.

  • When network firewalls are managed on a host by host basis, instead of on a network by network basis, every IP address change results in firewall rule changes. The longer it takes to implement firewall changes, the more planning would be required for hardware changes, or the greater the need for the ability to handle emergency firewall changes quickly.
  • In an environment where administrators were oblivious to MAC addresses, IPv6 address provisioning based on MAC addresses dictates that more attention be paid to MAC addresses up front, but well implemented automation can take care of that.
  • If you are concerned about the manufacturer of your systems being made public, and you use the burned in MAC address (not locally managed MAC addresses), then it would be possible for outsiders to determine that information from the IPv6 address using the methods above. However, my personal opinion is that “security by obscurity” is not security at all, and the false sense of security that it provides, does more harm than good over the long term. That said, if one does not want to expose the burned in addresses beyond the local network, one can use locally managed MAC addresses, which then requires that the MAC be set each time you provision a system. It should also be noted that since locally managed MAC addresses can be moved from one system to another, it also pretty much negates any impact of hardware changes.

Posted July 12, 2014 by metzlertech in Networking