1

The IEEE Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID) [PDF] have a section titled, "Mapping an EUI-48 to an EUI-64". This section starts:

Mapping an EUI-48 to an EUI-64 is deprecated.

And yet, use of this algorithm for converting EUI-48 to EUI-64 in order to form "interface identifiers" seems to be codified in IPv6 standards (see appendix A).

The IEEE documentation states that the mapping algorithm is deprecated because,

Mapping an EUI-48 assigned with an MA-S/OUI-36 or MA-M assignment to an EUI-64 potentially creates a duplicate of an EUI-64 assigned with a different MA-S/OUI-36 or MA-M. The IEEE RA has taken appropriate actions to mitigate creation of duplicates based on this mapping but, to protect the integrity of EUI-64 identifiers, this mapping is deprecated.

  1. How is it possible that there could ever be a duplicate EUI-64 when using this algorithm, assuming all parties correctly and completely follow the IEEE standards?
  2. Why does IPv6 specify the use of this "deprecated" algorithm for converting EUI-48 to EUI-64? Or is use of this algorithm not technically, officially part of IPv6? (IMHO it is absolutely a de facto standard, in any case, but here I am asking about the de jure standard, so-to-speak.)
Improve this question
1
  • Deprecated means don't use it in any new standards / implementations. Older, existing systems may still use it. (when you only have a 48bit address [ethernet] and need a 64bit one [ipv6]...) SLAAC's use of the MAC (L2) to form an IPv6 (L3) address was always a horrible idea.
    – Ricky
    Commented Dec 5, 2023 at 21:42

2 Answers 2

Reset to default
2

How is it possible that there could ever be a duplicate EUI-64 when using this algorithm, assuming all parties correctly and completely follow the IEEE standards?

There are 32,768 (including locally assigned 64-bit MAC, but excluding group MAC, addresses) that include a single 48-bit MAC address. That would limit the IEEE in building MAC addressing if it is allowed.

Why does IPv6 specify the use of this "deprecated" algorithm for converting EUI-48 to EUI-64?

You misunderstand one of the possible IPv6 ways of generating an IPv6 IID, which is using at 48-bit MAC address to generate a modified EUI-64 in the IPv6 address. It is not used as a layer-2 MAC address, but it could (is not mandated to) be used as the IID in a layer-3 IP address, and it is only one of many ways to try to generate a unique IID for a link. Do not confuse the network layers or which group controls the addressing for which protocols (IEEE for ethernet, et al that use MAC addressing, and the IETF that controls IP).

Improve this answer
5
  • Thanks for the answer! In regards to my second question, are you saying that it not part of official IETF standards that hosts with an EUI-48 "should" or "may" use the deprecated EUI-48 to EUI-64 algorithm to generate an IPv6 IID? In other words, the IETF is not suggesting or recommending this deprecated algorithm?
    – dsedivec
    Commented Dec 4, 2023 at 1:11
  • No, most OSes now use random addressing for IPv6 IIDs. Remember, not all layer-2 protocols use MAC addressing, which is why the appendix for RFC 4291 suggests several ways of generating an IID, but says any unique number in a host could be used.
    – Ron Maupin ♦
    Commented Dec 4, 2023 at 1:13
  • OK, I can live with "it's not canonical to use that algorithm for IPv6 IIDs". Regarding your first answer, I understand that you lose 2^16=32,768 possible IDs when you go from EUI-48 to EUI-64. However, the only way I can see that this would matter is if a single organization wants to use a single OUI for both EUI-64 and EUI-48 IDs, in which case I would think it's their responsibility to never use an EUI-64 with an extension beginning FFFE. More importantly, though, why does the IEEE doc specifically mention that this is a problem between OUI-36 allocations?
    – dsedivec
    Commented Dec 4, 2023 at 1:20
  • Your question is about IPv6 using the conversion that the IEEE says not to use. Remember, IPv6 is not a data-link protocol, so it does not have the same problem that ethernet has in that regard. IPv6 can use DAD to tell it that there is another host with the same IP address, so choose another, which is not an option for data-link protocols. In any case, it is largely not used with modern OSes that use random addressing and privacy protection. Your question is trying to confuse two different network layers, each controlled by a different standards organization.
    – Ron Maupin ♦
    Commented Dec 7, 2023 at 3:09
  • I am guilty of asking two questions. My first question does not involve IPv6, it's asking how there could ever be a duplicate EUI-64, which only involves the IEEE: they define EUI-64, and they used to define the algorithm for converting EUI-48 to EUI-64. (Search for "EUI-64 encapsulation" to find some pre-deprecation references on IEEE mailing lists, for example.) I've added my own answer for the first question, so I'll mark your answer as accepted to avoid this question hanging out as unanswered forever. Thank you again for your input.
    – dsedivec
    Commented Dec 7, 2023 at 3:30
0

I think I figured out an example of when an OUI-36's EUI-48 converted to EUI-64 can conflict with another EUI-64. The IEEE wording may be very exactly designed to point out that the conflict happens when one OUI's EUI-48 is converted to EUI-64, while the second OUI's is generated as an EUI-64 by the organization.

For example, say Company X is assigned OUI-36 01-23-45-67-8. They generate the EUI-48 01-23-45-67-89-AD. Following the deprecated IEEE algorithm to convert this to an EUI-64, you would get 01-23-45-FF-FE-67-89-AD.

Now say that Company Y is assigned OUI-36 01-23-45-FF-F. They would be free to generate the EUI-64 01-23-45-FF-FE-67-89-AD, because the first 36 bits of this EUI-64 are their assigned OUI-36. However, this now duplicates the EUI-64 generated from Company X's EUI-48.

I assume the IEEE's "appropriate actions to mitigate creation of duplicates based on this mapping" is probably just a refusal to allocate any MA-S/OUI-36 that ends in FF-F (and, likewise, refusal to allocate any MA-M ending in F).

(I am a little surprised that they ever considered using this algorithm, unless MA-M and MA-S were introduced after this EUI-48-to-64 algorithm.)

Improve this answer
1
  • MA-S and MA-M are indeed relatively new., being introduced in 2014. Long after the IPv6 standards were nailed down.
    – Peter Green
    Commented Sep 27 at 20:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.