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

[Robert Grow <[e-mail]>]

Pascal:

The only restriction on EUI-64 is that the bits corresponding to U/L and I/G are zero (allowing the EUI-64 to be used as MAC addresses).  Virtually all of the other 2^62 values could be already assigned or assigned in the future to an equipment manufacturer and used for any purpose, including as 64-bit MAC addresses.  

Yes, an EUI-64 used as a 64-bit MAC address can have 0xFFFE in octets 4 and 5.

The few exceptions where existing OUI assignments, (e.g., IAB, and Xerox Block ID assignments) that were not to be used for creating EUI-64 probably aren’t worth going into.

Therefore, in general, any EUI-48 or 48-bit value that looks like an EUI-48 (using any mapping that preserves the U/L and I/G bits) into a 64-bit value could produce a duplicate of an EUI-64.  

And consequentially IMHO,  the output of the mapping is not an EUI-64!  We need to stop calling things that are not EUI values assigned by the IEEE-RA by the name EUI.  That leads people to think the output of a mapping has the same uniqueness as an EUI, when it doesn’t.  And, when we mix a value created by some mapping the same as an EUI, we are defining protocols that will encounter duplicates for reasons other than hardware failure or manufacturing error.  Those human errors and failure have for decades been the only cause of duplicate values.  If protocols are going to use mappings instead of or in addition to EUIs, people need to know the assumption of global uniqueness assumed with an EUI is violated and there will be additional causes for seeing duplicates.

—Bob



> On Jun 26, 2018, at 8:18 AM, Pascal Thubert (pthubert) <pthubert=[e-mail]> wrote:
> 
> Hello Bob:
> 
> This is very specific to 802.15.4 which natively uses EUI-64. So that particular confusion between the EUI-48 derived from PANid/short_addr  and a real network address is impossible.
> Now, whether the EUI-64 derived from that EUI-48 can collision with a EUI-64 derived from a MAC-64 is beyond me. 
> I guess the U/L bit at least will differ, no? Can a MAC-64 have 0xFFFE in the middle?
> 
> Take care,
> 
> Pascal
> 
>> -----Original Message-----
>> From: Robert Grow <[e-mail]>
>> Sent: mardi 26 juin 2018 17:12
>> To: Pascal Thubert (pthubert) <[e-mail]>
>> Cc: Charlie Perkins <[e-mail]>; [e-mail]
>> Subject: Re: [ieee-ietf-coord] Rationale for 0xFFFE as octets 4 and 5 pf EUI-64?
>> 
>> 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
> 
> _______________________________________________
> ieee-ietf-coord mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord