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

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

I agree with that Charlie. 

Flipping the universal local bit creates a possible overlap. I guess that was missed at the time.

A recommendation not to use 2 pans that differ just by that bit in a same subnet would be welcome...

Take care,

Pascal

> Le 30 juin 2018 à 08:00, Charlie Perkins <[e-mail]> a écrit :
> 
> Hello folks,
> 
> Please excuse my stupid typo, which I will point out inline below...
> 
> 
>> On 6/29/2018 4:43 PM, Charlie Perkins wrote:
>> 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.
> 
> This should be:
> 
> MAC_1 = 0xFC78-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.
> 
> This should be:
> 
> RFC 2464 would produce the 64-bit Interface ID = 0xFC-78-00-FF-FE-00-12-34.
> 
> Anyway, the problem should be clear.
> 
> Regards,
> Charlie P.
> 
> ======================================================================
> 
>> 
>> 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
>> 
>> _______________________________________________
>> 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