I am attempting to grasp why does creating modified EUI-64 format interface identifiers from IEEE 802 48-bit MACs incorrectly use 0xFFFE
and why ought to’ve it used 0xFFFF
.
I belive there needs to be a sandard for EUI-64, however I used to be unable to seek out it.
What I discovered is one other Community Engineering query titled Why the FF:FE in EUI-64? with a single reply citing a Cisco Neighborhood publish with the next rationalization:
0xFFFE was chosen by the IEEE as a reserved worth to replicate the truth that a given deal with is within the modified EUI-64 format.
Nonetheless I used to be unable to seek out any requirements doc that help this declare.
The primary RFC describing IP Model 6 Addressing Structure (RFC 1884) on web page 7 describes deal with era from 48bit MACs as-is, so no EUI-64 mentions there.
The primary RFC to say EUI-64 is 2373 (which obsoleted 1884), on this doc there may be APPENDIX A : Creating EUI-64 primarily based Interface Identifiers, with the related half:
Hyperlinks or Nodes with IEEE 802 48 bit MAC’s
[EUI64] defines a technique to create a EUI-64 identifier from an IEEE 48bit MAC identifier. That is to insert two octets, with hexadecimal values of 0xFF and 0xFE, in the midst of the 48 bit MAC (between the company_id and vendor provided id).
The reference marked for EUI64 is Pointers for 64-bit World Identifier (EUI-64) Registration Authority which says
Restricted and encapsulated values
To help encapsulation of EUI-48 values inside a small subset of the EUI-64 values, the primary 4 digits of the producer’s extension identifier shall not be FFFF16 or FFFE16. Thus, the 64-bit values of the next type (the place ‘x’ is a arbitrary hexadecimal digit) are never-assigned EUI-64 values:
ccccccFFFEeeeeee16 (an EUI-48 extension)
xxxxxxFFFFxxxxxx16 (reserved by IEEE/RAC)
The letters ‘c’ and ‘e’ symbolize hexadecimal digits and present how the EUI-48 worth could be unambiguously encapsulated throughout the EUI-64 worth; the ‘c’ and ‘e’ digits symbolize the company_id and extension-identifier parts of the EUI-48 worth respectively.
My drawback with this reply is it is solely a suggestion not a regular (or ought to we take a look at it like one?), has no reason why these values had been choosen, however most significantly RFC 4291 (which obsolted 3513 and which obsoleted 2373) has a observe added on web page 22 saying
[EUI-64] truly defines 0xFF and 0xFF because 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 beginning with an IEEE EUI-48 identifier. The wrong worth was utilized in earlier variations of the specification as a consequence of a misunderstanding in regards to the variations between IEEE MAC-48 and EUI-48 identifiers.
This made me query what is the distinction between EUI-48 and MAC-48? Which commonplace describes these? Which commonplace describes the conversion that induced the misunderstanding?
Additionally method earlier than 2006 – when the RFC in query was made – the referenced guideline for EUI64 reported 404 errors for archive.org, so that they could not base that observe on it.
Additionally if the rationale for flipping the U/L bit is to make it doable to make use of the :: sorthand extra effectively and to get prettier addresses within the ensuing IPv6 addresses for regionally administered MACs (Supply: Web page 9 of RFC 2373) then utilizing 000016 would’ve made rather more sense; however they in all probability obeyed to some commonplace?!
Different paperwork I discovered
Pointers for Use of Prolonged Distinctive Identifier (EUI), Organizationally Distinctive Identifier (OUI), and Firm ID (CID)
on web page 15 says
Some requirements have described how an EUI-48 worth may very well be mapped to an
EUI-64, as follows: […]In different phrases, the EUI-64 worth was generated by inserting both the worth
FF-FEhex or the worth FF-FFhex in between eui48[2] and eui48[3].
eui64.pdf this has mentions of each values within the appropriate context MAC-48/EUI-48 however nonetheless does not give clear solutions as to why:
these values had been choosen? And why does IPv6 addressing follows this?
EDIT:
Why the additional bytes had been added to the producer’s house?
This was one in every of my authentic questions, however after making use of some frequent sense I belive it is as a result of OUIs are nonetheless 24 bits in EUI64 so it is smart to maintain it when mapping IEEE 802 48-bit MACs. Then it additionally is smart to position it within the first two MSBs of the producers’ house since it is a serial worth.
Nonetheless what’s not straight ahead is why they select the tip of the vary and never the beginning and what’s the usual/guideline that first launched it.