|Exam 300-101||Question id=420||Layer 3 Technologies|
After you review the output of the command
show ipv6 interface brief, you see that several IPv6 addresses have the 16-bit hexadecimal value of "FFFE" inserted into the address. Based on this information, what do you conclude about these IPv6 addresses?
IEEE EUI-64 was implemented when assigning IPv6 addresses on the device.|
The addresses were misconfigured and will not function as intended.|
IPv6 addresses containing "FFFE" indicate that the address is reserved for multicast.|
The IPv6 universal/local flag (bit 7) was flipped.|
IPv6 unicast forwarding was enabled, but IPv6 Cisco Express Forwarding was disabled.|
Extended Unique Identifier (EUI), as per RFC2373, allows a host to assign iteslf a unique 64-Bit IP Version 6 interface identify them EUI-64). This feature is a key benefit over IPv4 as it eliminates the need of manual configuration or DHCP as in the world of IPv4. The IPv6 EUI-64 format address is obtained through the 48-bit MAC address. The Mac address is first separated into two 24-bits, with one being OUI (Organizationally Unique Identifier) and the other being NIC specific. The 16-bit 0xFFFE is then inserted between these two 24-bits to for the 64-bit EUI address. IEEE has chosen FFFE as a reserved value which can only appear in EUI-64 generated from the EUI-48 MAC address.
Here is an example showing how the Mac Address is used to generate EUI.
Next, the seventh bit from the left, or the universal/local (U/L) bit, needs to be inverted. This bit identifies whether this interface identifier is universally or locally administered. If 0, the address is locally administered and if 1, the address is globally unique. It is worth noticing that in the OUI portion, the globally unique addresses assigned by the IEEE have always been set to 0 whereas the locally created addresses have 1 configured. Therefore, when the bit is inverted, it maintains its original scope (global unique address is still global unique and vice versa). The reason for inverting can be found in RFC4291 section 2.5.1.
Once the above is done, we have a fully functional EUI-64 format address.