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

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

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