A more common, though deprecated, approach seems to be to insert 0xFFFE in the middle; see “Mapping an EUI-48 to an EUI-64” in IEEE SA - Registration Authority, emphasis for the past tense mine:
Some standards have described how an EUI-48 value could be mapped to an EUI-64, as follows: Let the six octets of the EUI-48 be labeled eui48[0] through eui48[5]. Let the eight octets of the mapped EUI-64 be labeled eui64[0] through eui64[7]. The following mapping has been described:
eui64[0] = eui48[0]
eui64[1] = eui48[1]
eui64[2] = eui48[2]
eui64[3] = FFhex
eui64[4] = FEhex or eui64[4] = FFhex
eui64[5] = eui48[3]
eui64[6] = eui48[4]
eui64[7] = eui48[5]In other words, the EUI-64 value was generated by inserting either the value FFFEhex or the value FFFFhex in between eui48[2] and eui48[3].
But beware it also notes this is deprecated, emphasis mine:
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.
Earlier it stated, again emphasis mine:
The mapping described here is deprecated and it should not be used in new applications as it includes an unacceptable probability of duplicating an EUI-64.
(It’s also used in IPv6 but there it also sets a specific bit which in IPv6 defines universal/global scope, so would probably not suffer any chances of duplicating IPv6 addresses.)