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

[Charlie Perkins <[e-mail]>]

Hello Pascal,

Yes, I saw that specification, but it seemed to me that it still has the 
same problem as I mentioned in the previous email.  By RFC 4944, two 
devices on different PANs that happen to have the same 16-bit short 
address could end up with the same IPv6 address.

It doesn't have to be that way, to my understanding.

Regards,
Charlie P.


On 6/25/2018 11:20 AM, Pascal Thubert (pthubert) wrote:
> 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
> _______________________________________________
> ieee-ietf-coord mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord