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

[Robert Grow <[e-mail]>]

But, is there anything that prevents it from being a duplicate of an EUI-48?  I don’t think so.

—Bob

> On Jun 26, 2018, at 3:57 AM, Pascal Thubert (pthubert) <pthubert=[e-mail]> wrote:
> 
> Hello Charlie, 
> 
> As I understand RFC 4944, the 48bits address is built on pan-id (2 octets) concatenated with 0s (2 octets) concatenated with short address (2 octets).
> 
> So no, two devices on different PANs that happen to have the same 16-bit short address cannot end up with the same IPv6 address.
> 
> Take care,
> 
> Pascal
> 
>> -----Original Message-----
>> From: Charlie Perkins <[e-mail]>
>> Sent: lundi 25 juin 2018 20:45
>> To: Pascal Thubert (pthubert) <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: [ieee-ietf-coord] Rationale for 0xFFFE as octets 4 and 5 pf EUI-64?
>> 
>> 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
> 
> _______________________________________________
> ieee-ietf-coord mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord