Significance of IPv6 Interface Identifiers
updates
- rfc-4291 — IP Version 6 Addressing Architecture
Extracted elements (19)
New methods of IID formation (temporary addresses RFC 4941, CGAs RFC 3972, HBAs RFC 5535, ISATAP RFC 5214, NAT64 RFC 6052, stable privacy addresses) each independently specified different values for the 'u' and 'g' bits with no consistent semantics, confirming these bits carry no generic meaning in an IID.
Preserving the mapping of IEEE 'u' and 'g' bits into the IID retains operational usefulness: if an IID is known or suspected to have been created per RFC 4291, it can be reverse-transformed back into a MAC address for fault diagnosis. New methods are free to use these bit positions as additional pseudo-random bits to reduce duplicate IID probability.
The /127 prefix case (RFC 6164) for point-to-point inter-router links produces global unicast addresses without 64-bit IIDs where the bits in positions named 'u' and 'g' have no special significance, further demonstrating the general inapplicability of Modified EUI-64 semantics to non-MAC-derived IIDs.
The 'u' bit is not a reliable indicator of universal uniqueness because MAC addresses with universal scope are sometimes assigned to multiple devices by manufacturers, and the same virtual MAC address is widely reused in virtual machine environments. Once mapped to an IID with 'u'=1, such identifiers purport uniqueness but are actually ambiguous.
The 'u' bit was inverted when mapping from MAC to IID to make it easier for network operators to manually configure local-scope IIDs (per RFC 4291 and RFC 7042). The original rationale for preserving it was to allow future technology to take advantage of universally scoped IIDs, but this use case never materialized.
ILNP (RFC 6741), a multihoming solution that might be expected to benefit from universally unique EUI-64 IIDs, does not rely on them and uses its own Node Identifier format with uniqueness guaranteed only within the context of a given Locator, relying on DAD rather than the 'u' bit.
RFC 2526 (Reserved IPv6 Subnet Anycast Addresses) requires that for EUI-64 format IIDs the 'u' bit MUST be 0 (local) and 'g' must be 1, but neither states nor implies any semantics for these bits within anycast addresses themselves, illustrating the inconsistent treatment across specifications.
The RFC 4291 requirement for 'Modified EUI-64 format' is inapplicable to IIDs not actually based on an underlying EUI-64 address. In practice the IETF has assigned 64-bit IIDs that have nothing to do with EUI-64, making the original blanket requirement misleading for implementors of new IID schemes.
Per RFC 4862 (quoted here): if a duplicate link-local address is not formed from a hardware-based interface identifier, IP operation on the interface MAY be continued by creating a new IID. For pseudo-random IID generation methods, the process may simply be repeated.
RFC 4291 Section 2.5.1 is updated: the requirement that Interface IDs 'be constructed in Modified EUI-64 format' is replaced with 'If derived from an IEEE MAC-layer address, they must be constructed in Modified EUI-64 format.' The prior statement that the universal/local bit is 'to allow development of future technology' is explicitly obsoleted.
Specifications of other forms of 64-bit IIDs MUST specify how all 64 bits are set, but a generic semantic meaning for the 'u' and 'g' bits MUST NOT be defined. The method of generating IIDs for specific link types MAY define some local significance for certain bits.
The EUI-64 to IID transformation defined in RFC 4291 MUST be used for all cases where an IPv6 IID is derived from an IEEE MAC or EUI-64 address. With any other form of link-layer address, an equivalent transformation SHOULD be used.
The whole IID value MUST be viewed as an opaque bit string by third parties, except possibly in the local context. The bits in an IID have no generic semantics.
Duplicate Address Detection (DAD) per RFC 4862, optionally extended via a DAD proxy (RFC 6957) or Neighbor Discovery Optimization (RFC 6775), is the primary mechanism for detecting IID collisions on a link. Because DAD is mandatory for all nodes, virtually all IID collisions will be detected regardless of the 'u' bit's value.
The 'g' bit in an IID is at position 7 (position 71 in the full IPv6 address). It derives from the IEEE 'i/g' (group) bit in a MAC address and its value is preserved unchanged. After IID formation, this bit has no reliable meaning.
The IPv6 Interface Identifier (IID) is a 64-bit field appended to a prefix to form a unicast IPv6 address. It is required to be 64 bits long for all unicast addresses except those starting with binary 000. If derived from an IEEE MAC-layer address, it must be constructed in Modified EUI-64 format.
The 'u' bit in an IID is at position 6 (position 70 in the full IPv6 address counting from 0). It derives from the IEEE 'u/l' bit in a MAC address but is inverted: 1 means universal scope, 0 means local scope. After IID formation, this bit has no reliable meaning.
The 'Reserved IPv6 Interface Identifiers' registry (RFC 5453) requires Standards Action for any new reserved IID value. This document adds a note to that registry warning that full deployment of a new reserved IID would require updates to IID generation code in every deployed IPv6 stack.
No new security exposures are introduced. Treating the IID as an opaque bit string is consistent with IID formation methods that produce unpredictable, pseudo-random values, which are considered beneficial for enhancing privacy and defeating address scanning attacks.