[ieee-ietf-coord] Whether or not RFC 4944 can produce address collisions

[Charlie Perkins <[e-mail]>]

Hello Pascal and all,

Yes there are quite a few cases.  My original observation was that RFC 
4944 followed by RFC 2464 might produce 64-IIDs that were the same from 
devices residing on PANs with different PAN IDs.  I was wondering what I 
might be missing.  The ensuing discussion has been quite interesting!

If PAN_ID_1 = 0xFC78 and PAN_ID_2 = 0xFE78, and on each PAN there were a 
device with the 16-bit short address 0x1234, applying RFC 4944 would 
produce two 48-bit MAC addresses MAC_1 = 0xFC34-0000-1234 and MAC_2 = 
0xFE78-0000-1234.  And then for both MAC_1 and MAC_2, RFC 2464 would 
produce the 64-bit Interface ID = 0xFC-34-00-FF-FE-00-12-34.

It seems to me that it would have been better to put the PAN_ID bits in 
the middle, and the filler bits as the prefix when extending the 48-bit 
MAC address to be a 64-bit Interface ID.

Or, I might *still* be missing something...  I understand that the IID 
is not an EUI-64, and that IPv6 Duplicate Address Detection was designed 
just to eliminate such conflicts as these.

Regards,
Charlie P.


On 6/26/2018 10:40 AM, Pascal Thubert (pthubert) wrote:
> Makes sense to me Robert;
>
> I understand that the 48 bits and then the 64 bits values generated by RFC 4944 and the by adding FFFE in the middle will not collide with EUI-64 assigned by the IEEE-RA because of the U/L bit setting.
> At least, the IPv6 IIDs will not collide. So in the particular case of RFC4944, IPv6 autoconf works and does not create a risk of a collision between an IPv6 address derived from a short address and one derived from a long address. Also to Charlie's original point, there is not collision between IPv6 addresses derived from short addresses if the PAN IDs are different.
>
> Cheers,
>
> Pascal
>
>> -----Original Message-----
>> From: ieee-ietf-coord <[e-mail]> On Behalf Of Robert
>> Grow
>> Sent: mardi 26 juin 2018 19:23
>> To: Pascal Thubert (pthubert) <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?
>>
>> 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
>> _______________________________________________
>> ieee-ietf-coord mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord