Introduction
Besides the virtually unlimited address space (a quantity that experts have argued will likely outlast the lifespan of the protocol itself), IPv6 offers many unique characteristics and features that are not found in IPv4 (i.e., the legacy Internet Protocol). The original designers of IPv6 made sure to take advantage of the opportunity to rebuild the Internet Protocol from the “ground up.” Of course, not everything they proposed has yet found its way into typical network operations. But many elements did and the best of these exist to make deployment and management of the protocol easier and more efficient.
For example, IPv6 Neighbor Discovery provides automated layer 3 address management and communication on any single network segment. Among other benefits, this facilitates the use of multicast instead of broadcast and thus reduces the volume of unnecessary traffic allowing switches and routers to operate more efficiently.
Another example of a characteristic unique to IPv6 (and offering an operational benefit) is the concept and definition of an interface identifier (or IID) as part of the overall IPv6 address. In this IPv6 back-to-basics blog, we’ll take a closer look at IPv6 interface identifiers along with how they are configured and used in operations.
A Brief History of IPv6 IIDs (or How I Learned to Stop Worrying and Decouple the Identification of Nodes from the Identification of Interfaces)
So why do we have an identifier in IPv6 explicitly but not in IPv4? A simplified explanation is that unicast IPv4 addresses were defined and deployed at a time when it was uncommon for a network endpoint (referred to as a node in IPv6) to have more than one network interface. Therefore, the part of the IPv4 address identifying the endpoint had a one-to-one relationship with that endpoint.
In IPv4, it’s common to refer to the network and host portions of a unicast address. The host portion of the address is defined by the quantity and value of the rightmost bits that are left over after defining the quantity and value of the leftmost bits (i.e., the network portion of the address).
The difference in nomenclature could perhaps be understood as a historical artifact of the fact that a network endpoint had only one network interface. This one-interface-per-host could be logically understood as a single unique network entity not requiring more than one unique address (with one unique host portion within that address).
Over time of course it became more common for an endpoint to have and use more than one network interface (along with more than one unicast IPv4 address). A contemporary example of this would be the multiple network interfaces found on a typical mobile phone; e.g., for both Wi-Fi and for 4G cellular data service. While this wasn’t yet a common operational configuration when IPv6 was being created, beginning in the early 1990s, the designers of IPv6 recognized the future architectural benefit and flexibility of decoupling the host portion of a unicast address from the more restrictive concept of a single network host with only one network interface. Thus, by comparison, the definition of IPv6 IIDs (in RFC 4291, IP Version 6 Addressing Architecture) explicitly states that they exist to “identify interfaces on a link.” What’s conspicuously missing from this definition is any characterization of those interfaces as necessarily belonging to multiple endpoints or nodes.
Defining Interface IDs
As mentioned, IPv6 interface identifiers are used to identify interfaces on a link. But what defines an IID itself? The basic definition is quite simple: In IPv6, the rightmost 64 bits of the most commonly encountered address types (e.g., global unicast (2000::/3), link-local (fe80::/10)) is reserved as an interface identifier.
If that 64-bit value sounds familiar, it should: A /64 prefix is also the smallest prefix (i.e., the least number of host bits) we are advised to configure on an interface. There are a few good reasons for this. First, from a standards perspective, any fewer than 64 bits does not constitute a proper IID as defined in RFC 4291. In addition, IPv6 stack implementations are expected to support address autoconfiguration such as SLAAC and/or stateful DHCPv6. SLAAC (stateless address auto-configuration) in particular is standardized around a 64-bit interface identifier. Attempting to configure a smaller prefix – e.g., /68, /72, /96 (incidentally, a /96 is a prefix as large as the existing IPv4 Internet!) – will be in violation of the standard and may break SLAAC (i.e., the ability for a host to auto-assign its address).
Another consequence of defining a /64 as the smallest prefix and reserving the resulting rightmost 64 bits for an interface identifier, is the implication for the idea of host address conservation in IPv6. I have argued that we can safely infer that the designers of IPv6 were unconcerned with host address conservation given a willingness to use a 64-bit IID. There is simply no technically feasible scenario where more than an infinitesimally tiny fraction of the IPv6 addresses available in a single /64 will be used.
Meanwhile, paranoia about having sufficient network prefixes drawn from the remaining leftmost 64 bits not reserved for the IID is a different beast! Still, please keep firmly in mind that the current global unicast allocation of 2000::/3 is still only 12.5% of the entire IPv6 address space (or 25% of the available 64 bits worth of network prefixes). Even given the most profligate IPv6 network prefix consumption models, no fewer than three additional /3s remain to allocate before IPv6 would be completely exhausted of unused network prefixes (and even that unlikely outcome ignores the availability of vast amounts of unused space inherent in existing allocations.
Interface ID Types
Interface ID definitions and types have changed over the intervening years since IPv6 was first defined as a standard.
Three interface ID types were initially defined. These are:
- Manual
- Modified EUI-64
- Random
The Manual IID
A manual IID is exactly what it sounds like: An IID that is manually configured by the user. Applications for manually configured IIDs may include:
- Network infrastructure addresses
- Network gateway addresses
- Internet and/or well-known services
- Servers in lower density data center deployments
Manual configuration of network addresses is obviously time consuming and operationally taxing – not just the configuration of the address itself on the device but also the accurate tracking of assigned addresses over time (an IPAM solution – especially one that provides network discovery – is essential). However, statically assigning the IID in server environments may mimic the operational model you employ today (i.e., the static assignment of IPv4 addresses to servers.
The ability to spell some words using combinations of the available hexadecimal characters results in some noteworthy manual IIDs for well-known services. For example, one social media site in particular has used an IID similar to the one found in RFC 5541 (the April Fool’s Day RFC from 2009):
2001:db8:0:0:0:face:b00c:1
If you’re manually configuring an IPv6 address for a well-known service, this type of built-in mnemonic could be helpful.
As you can see, this is really the equivalent of the manual configuration of the entire IPv6 address. The network prefix is configured as part of the link for a GUA or ULA address, or it’s a link-local address like an fe80:: prefix.
The Modified EUI-64 IID
The next type of interface ID is the modified EUI-64.
A modified EUI-64 IID is created by taking the 48-bit MAC address, inserting a hexadecimal value of 0xFFFE into the middle of it (which increases the overall length of the hexadecimal value to 64 bits), then complementing (or “flipping”) the seventh bit of the MAC address (when read from left to right; i.e., in “little endian” fashion). Finally, the resulting 64-bit value is appended to the network prefix.
Here’s an example of what that process looks like. Start with a 48-bit MAC address:
Insert a hexadecimal value of 0xFFFE into the middle of it:
Complement (or “flip”) the 7th bit from the left:
Append the resulting 64-bit value to the network prefix:
Et voilà, an IPv6 address with a modified EUI-64 IID:
Modified EUI-64 IIDs can be generated automatically by one of IPv6’s auto-addressing mechanisms, either SLAAC or DHCPv6. It’s also used when generating a link-local address. For example:
Note that almost all of the MAC addresses used in the creation of modified EUI-64 IIDs are burned-in addresses (BIA), and as such are permanently associated with a particular network interface and attached host. This raises privacy concerns given that the use of any resulting IPv6 address constructed in this fashion could allow the user’s location and activity to be tracked over time. (Some ways in which user and activity tracking might occur are described in section 2.1 of RFC 4941, Privacy Extensions for Stateless Address Autoconfiguration in IPv6). These privacy concerns led, at least in part, to the creation and specification of the next type of IID known as “random” (see RFC 4941) but with variants that we’ll cover more in depth.
The Random IID
For the sake of brevity, we’ll skip the details of the algorithm used for generating a random IID (you can read about it in RFC 4941 referenced above). More generally, it relies on a periodic (i.e., hours to days) MD5 hash of a 64-bit value stored on the host. Once the randomized IID is generated it can be used to form temporary addresses. These addresses are regenerated periodically (again, hours to days) and meet the goal of preventing or limiting any effective tracking of the host address location and user activities.
If you happen to have IPv6 connectivity, you might be able to observe examples of randomized IIDs. Here is a screen capture of my wireless interface on my laptop. I’ve obscured the last half of my MAC address for privacy. Note that there are three IPv6 addresses configured on the interface, all of which were automatically generated: the link-local address and two globally scoped addresses. The globally scoped addresses are from the ARIN allocation 2600::/12, which itself is taken from the larger overall global unicast allocation 2000::/3. (These address assignments can be found at the Internet Assigned Numbers Authority page showing IPv6 Global Unicast Address Assignments).
Based on what we just learned, if modified EUI-64 IIDs were being used in the example above, we would observe the f60f:24ff value embedded within the highlighted area of all three IPv6 addresses shown. In other words, the modified EUI-64 IPv6 addresses would be begin as follows:
By the way, why is 6 the second hexadecimal value in the IID given that the second hexadecimal value of the MAC address is 4? Recall that if the OS were generating and using a modified EUI-64 IID then the 7th bit of the IID would be flipped causing the value to change from 4 to 6. Instead, the values (highlighted in red below) indicate that randomized IIDs have been generated and used.
Note that I’ve left off the final eight hexadecimal values (as represented by the ellipses) in the IPv6 address examples above. Since we’ve obscured the last half of my MAC address for privacy reasons, we can’t derive what the actual values would be as part of the modified EUI-64 process.
You may be wondering why one of the addresses is labeled “secured.” This nomenclature reveals how the original concept of the randomized IID has evolved and become more sophisticated – as defined in the protocol standards and as configured by recent OSes.
A secured address uses a random function to generate an IID that is similar to the one used for creating temporary addresses (this method is described in RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Addre…). But a secured address will not expire or change unless the network prefix portion of the address changes (as when a host moves from one network segment to another). This method provides a “best of both worlds” approach where some anonymity is assured – especially as hosts move from network to network – but the IID remains stable while the host is connected to the same network (allowing for more effective network management than is possible with purely temporary addresses).
That’s it for this edition of IPv6 Back to Basics! Hopefully, you now have a better grasp of IPv6 interface identifiers (IIDs). Please leave a comment below with any experiences working with IPv6 IIDs or any questions you may have!
Tom Coffeen (@ipv6tom) is a co-founder of HexaBuild, an IPv6 consulting and IPv6 training company. Tom is the author of IPv6 Address Planning on O’Reilly Media. You can follow HexaBuild on Twitter and LinkedIn.
