IPv6 – Understanding EUI-64 for MAC and IP Addressing

ip addressipv6mac addressosi

I was reading Forouzan's book. It says following:

In IPv4 addressing, there is not a specific relation between the hostid (at the IP level) and link-layer address (at the data-link layer) because the link-layer address is normally much longer than the hostid. The IPv6 addressing allows this relationship. A link-layer address whose length is less than 64 bits can be embedded as the whole or part of the interface identifier, eliminating the mapping process. Two common linklayer addressing schemes can be considered for this purpose: the 64-bit extended unique identifier (EUI-64) defined by IEEE and the 48-bit link-layer address defined by Ethernet.

Mapping EUI-64
To map a 64-bit physical address, the global/local bit of this format needs to be changed
from 0 to 1 (local to global) to define an interface address, as shown in figure below:
enter image description here

Mapping Ethernet MAC Address
We need to change the local/global bit to 1 and insert an additional 16 bits. The additional
16 bits are defined as 15 ones followed by one zero, or FFFE16.
enter image description here

I have some doubts:

  1. MAC addresses are assigned by manufacturers. Do manufacturers also assign EUI-64 addresses nowadays? (I have this doubt because I never came across 64 bit physical address when I run ipconfig -all on PC. Did I miss it?)

  2. If answer to 1 is no, then is EUI-64 just logical and always produced from 48 bit MAC address?

  3. However answer to first doubt shouldnt be no, because otherwise it would have made no sense to give first mapping as given by first diagram.

Best Answer

  1. MAC addresses are assigned by manufacturers. Do manufacturers also assign EUI-64 addresses nowadays?

The IEEE protocols use MAC addressing. Some of the IEEE protocols use 48-bit MAC addresses (MAC-48 or EUI-48), and some use 64-bit MAC addresses (EUI-64).

  1. If answer to 1 is no, then is EUI-64 just logical and always produced from 48 bit MAC address?

The answer to 1 is actually, yes, for some protocols.

  1. However answer to first doubt shouldnt be no, because otherwise it would have made no sense to give first mapping as given by first diagram

You are confusing some things, and that book is out of date. The original IPv6 SLAAC used MAC addressing, or another unique host identifier, to create a 64-bit IPv6 IID, known as a Modified EUI-64 Format Interface Identifier. Most OSes do not do this anymore, but use random addressing with privacy extensions. Most IPv6 networks will be /64, meaning the IID will be 64 bits, and most IEEE protocols use 48-bit MAC addresses, so a standard method to convert a 48-bit MAC address to a 64-bit IID was needed for the original SLAAC.

The specification for creating Modified EUI-64 Format Interface Identifiers is detailed in RFC 4291, IP Version 6 Addressing Architecture, Appendix A: Creating Modified EUI-64 Format Interface Identifiers. Notice that it covers both 48-bit and 64-bit MAC addresses, as well as other protocols that may not use MAC addressing:

Appendix A: Creating Modified EUI-64 Format Interface Identifiers

Depending on the characteristics of a specific link or node, there are a number of approaches for creating Modified EUI-64 format interface identifiers. This appendix describes some of these approaches.

Links or Nodes with IEEE EUI-64 Identifiers

The only change needed to transform an IEEE EUI-64 identifier to an interface identifier is to invert the "u" (universal/local) bit. An example is a globally unique IEEE EUI-64 identifier of the form:

|0              1|1              3|3              4|4              6|
|0              5|6              1|2              7|8              3|
+----------------+----------------+----------------+----------------+
|cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+

where "c" is the bits of the assigned company_id, "0" is the value of the universal/local bit to indicate universal scope, "g" is individual/group bit, and "m" is the bits of the manufacturer- selected extension identifier. The IPv6 interface identifier would be of the form:

|0              1|1              3|3              4|4              6|
|0              5|6              1|2              7|8              3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+

The only change is inverting the value of the universal/local bit.

Links or Nodes with IEEE 802 48-bit MACs

[EUI64] defines a method to create an IEEE EUI-64 identifier from an IEEE 48-bit MAC identifier. This is to insert two octets, with hexadecimal values of 0xFF and 0xFE (see the Note at the end of appendix), in the middle of the 48-bit MAC (between the company_id and vendor-supplied id). An example is the 48-bit IEEE MAC with Global scope:

|0              1|1              3|3              4|
|0              5|6              1|2              7|
+----------------+----------------+----------------+
|cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+

where "c" is the bits of the assigned company_id, "0" is the value of the universal/local bit to indicate Global scope, "g" is individual/group bit, and "m" is the bits of the manufacturer- selected extension identifier. The interface identifier would be of the form:

|0              1|1              3|3              4|4              6|
|0              5|6              1|2              7|8              3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+

When IEEE 802 48-bit MAC addresses are available (on an interface or a node), an implementation may use them to create interface identifiers due to their availability and uniqueness properties.

Links with Other Kinds of Identifiers

There are a number of types of links that have link-layer interface identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs. Examples include LocalTalk and Arcnet. The method to create a Modified EUI-64 format identifier is to take the link identifier (e.g., the LocalTalk 8-bit node identifier) and zero fill it to the left. For example, a LocalTalk 8-bit node identifier of hexadecimal value 0x4F results in the following interface identifier:

|0              1|1              3|3              4|4              6|
|0              5|6              1|2              7|8              3|
+----------------+----------------+----------------+----------------+
|0000000000000000|0000000000000000|0000000000000000|0000000001001111|
+----------------+----------------+----------------+----------------+

Note that this results in the universal/local bit set to "0" to indicate local scope.

Links without Identifiers

There are a number of links that do not have any type of built-in identifier. The most common of these are serial links and configured tunnels. Interface identifiers that are unique within a subnet prefix must be chosen.

When no built-in identifier is available on a link, the preferred approach is to use a universal interface identifier from another interface or one that is assigned to the node itself. When using this approach, no other interface connecting the same node to the same subnet prefix may use the same identifier.

If there is no universal interface identifier available for use on the link, the implementation needs to create a local-scope interface identifier. The only requirement is that it be unique within a subnet prefix. There are many possible approaches to select a subnet-prefix-unique interface identifier. These include the following:

  Manual Configuration  
  Node Serial Number  
  Other Node-Specific Token

The subnet-prefix-unique interface identifier should be generated in a manner such that it does not change after a reboot of a node or if interfaces are added or deleted from the node.

The selection of the appropriate algorithm is link and implementation dependent. The details on forming interface identifiers are defined in the appropriate "IPv6 over " specification. It is strongly recommended that a collision detection algorithm be implemented as part of any automatic algorithm.

Note: [EUI-64] actually defines 0xFF and 0xFF as the bits to be inserted to create an IEEE EUI-64 identifier from an IEEE MAC- 48 identifier. The 0xFF and 0xFE values are used when starting with an IEEE EUI-48 identifier. The incorrect value was used in earlier versions of the specification due to a misunderstanding about the differences between IEEE MAC-48 and EUI-48 identifiers.

This document purposely continues the use of 0xFF and 0xFE because it meets the requirements for IPv6 interface identifiers (i.e., that they must be unique on the link), IEEE EUI-48 and MAC-48 identifiers are syntactically equivalent, and that it doesn't cause any problems in practice.

Related Topic