Re: [ieee-ietf-coord] Rationale for 0xFFFE as octets 4 and 5 pf EUI-64?

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Charlie

Section 6 of RFC 4944 builds an EUI 48 out of panid :0: short address and from there an interface ID for IPv6. Is that what you are after?


Pascal

> Le 25 juin 2018 à 19:46, Charlie Perkins <[e-mail]> a écrit :
> 
> Hello folks,
> 
> The reason why I asked about why 0xFFFE was chosen, was because I am trying to understand how best to do something similar for 802.15 devices that have a PAN-ID and a 16-bit short address as in IEEE 1901.2.  Or, if someone has already done it, then even better.
> 
> What I saw was to make the PAN-ID into the leading 16 bits, by analogy to making the OUI into the leading 24 bits.  But the OUI already had bits set aside for U/L and I/G, whereas the PAN ID does not.  So, setting the U/L bit would effectively change the PAN-ID and that seems wrong to me.  A similar problem exists already in IEEE 1901.1 because the NID (Network ID) is made into the leading 24 bits of the EUI-64.  So, two devices on different Networks that happen to have the same 16-bit equipment identifier could end up with the same IPv6 address.
> 
> I have looked in a number of places for an existing design, or for information to guide the design, so far coming up empty handed.
> 
> Thanks for any help!
> 
> Regards,
> Charlie P.
> 
> 
>> On 6/24/2018 9:22 PM, Donald Eastlake wrote:
>> OK, it would have been better if I had said "converts the format of X
>> to Y" instead of "converts X to Y".
>> 
>> In any case, the original question from Charlie had nothing to do with
>> why or how a larger 64 bit MAC address space would be of benefit or
>> what its goals were. I believe he was just asking where the 0xFFFE
>> came from that is actually and currently used in, for example,
>> construction of some IPv6 addresses from 48 bit MAC addresses. As far
>> as I know it came from the IEEE. See for example
>> http://standards.ieee.org/develop/regauth/tut/eui.pdf which, while it
>> deprecates this "mapping", still documents FF-FF and FF-FE as
>> insertions. An earlier IEEE tutorial which, as I call, documented this
>> mapping without any deprecation, seems to no longer be on the web.
>> 
>> Thanks,
>> Donald
>> ===============================
>>  Donald E. Eastlake 3rd   [phone] (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  [e-mail]
>> 
>> 
>>> On Sun, Jun 24, 2018 at 9:27 PM, Geoff Thompson <[e-mail]> wrote:
>>> Inserting "0xFFFF to convert a MAC-48 to and EUI-64" or "0xFFFE to convert
>>> an EUI-48 to an EUI-64"
>>> does not actually "convert" anything in a useful way except to to make a
>>> "EUI-48" readable in a 64 bit system.
>>> 
>>> The purpose of developing EUI-64 was to have a larger address space that
>>> could be used for (among other things) software instances.
>>> Having a fixed 16 bit value in a 64 bit address does nothing towards
>>> achieving that goal or slowing down the usage of 48 bit addresses to extend
>>> the life of 802 physical networks.
>>> 
>>> Geoff Thompson
>>> 
>>> 
>>> On Jun 24, 2018, at 5:52 PMPDT, Donald Eastlake <[e-mail]> wrote:
>>> 
>>> Hi Charlie,
>>> 
>>> As I recall, there is/was this distinction between MAC-48 and EUI-48
>>> addresses. I think MAC-48 was just for hardware and EUI-48 was for other
>>> devices and software. Anyway, you inserted 0xFFFF to convert a MAC-48 to and
>>> EUI-64 and 0xFFFE to convert an EUI-48 to an EUI-64. The RFCs that talk
>>> about extending a 48 bit address to 64 bits to use as the low order bits of
>>> an IPv6 address say that 0xFFFE was used by mistake and that 0xFFFF should
>>> have been used (see for example the Note on page 22 of RFC 4291) but it was
>>> decided to stick with 0xFFFE for that purpose. Hope this helps.
>>> 
>>> Thanks,
>>> Donald
>>> ===============================
>>>  Donald E. Eastlake 3rd   [phone] (cell)
>>>  155 Beaver Street, Milford, MA 01757 USA
>>>  [e-mail]
>>> 
>>> On Fri, Jun 22, 2018 at 9:54 PM, Charlie Perkins
>>> <[e-mail]> wrote:
>>>> Hello folks,
>>>> 
>>>> Does anyone here remember why 0xFFFE were chosen to be the filler bits
>>>> (i.e., bytes 4 and 5 of 8) when expanding a 48-bit MAC address to be EUI-64?
>>>> It is not explained in RFC 2464.
>>>> 
>>>> Or maybe there was not a reason...?
>>>> 
>>>> Thanks in advance,
>>>> Charlie P.
>>>> 
>>>> _______________________________________________
>>>> ieee-ietf-coord mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>>> 
>>> _______________________________________________
>>> ieee-ietf-coord mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>>> 
>>> 
>> _______________________________________________
>> ieee-ietf-coord mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>> 
> 
> _______________________________________________
> ieee-ietf-coord mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord