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

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

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