Subject: [ieee-ietf-coord] Doodle poll to schedule Late June/Early July 2018 coordination call

From: "Stanley, Dorothy" <[email-masked]>
Date: Fri, 22 Jun 2018 17:10:18 +0000

All,

With apologies for the short notice, please respond to the doodle poll:
https://doodle.com/poll/hq3wa97tyuhz29fm

with your availability for a coordination call.

Agenda items:

1.       Welcome, roll call, agenda bashing

2.       Action item updates

3.       IETF new work summary

4.       802 New Work summary

5.       Review current coordination items

6.       Assess need for Montreal breakfast meeting

7.       Next meetings

8.       Adjourn

Thanks,

Dorothy and Russ
------------------------
Dorothy Stanley
Hewlett Packard Enterprise
[email-masked]<mailto:[email-masked]>
+1 630-363-1389

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 22 Jun 2018 18:54:16 -0700

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.

---

From: John Messenger <[email-masked]>
Date: Sun, 24 Jun 2018 23:37:30 +0000

I asked a couple of people in 802.1 without getting an answer.

      -- John

> On 23 Jun 2018, at 02:54, Charlie Perkins <[email-masked]> 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.
> 
> _______________________________________________
> ieee-ietf-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 24 Jun 2018 20:52:25 -0400

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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Geoff Thompson <[email-masked]>
Date: Sun, 24 Jun 2018 18:27:38 -0700

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 <[email-masked]> 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
>  [email-masked] <mailto:[email-masked]>
> On Fri, Jun 22, 2018 at 9:54 PM, Charlie Perkins <[email-masked] <mailto:[email-masked]>> wrote:
> Hello folks,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord <https://www.ietf.org/mailman/listinfo/ieee-ietf-coord>
>

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 25 Jun 2018 00:22:56 -0400

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

On Sun, Jun 24, 2018 at 9:27 PM, Geoff Thompson <[email-masked]> wrote:
> 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
>
>
> 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
> On Fri, Jun 22, 2018 at 9:54 PM, Charlie Perkins
> <[email-masked]> wrote:
>>
>> Hello folks,
>>
>> (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.
>>

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 25 Jun 2018 10:46:04 -0700

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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 25 Jun 2018 18:20:10 +0000

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 <[email-masked]> 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.
> 
>

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 25 Jun 2018 11:44:30 -0700

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.

---

From: ROBERT GROW <[email-masked]>
Date: Mon, 25 Jun 2018 12:19:50 -0700

Charlie:

You have parallels to the problems with converting a 48-bit MAC address into a 64-bit MAC address.  One possible reason for the choice of 0xFFFE and 0XFFFF in the 4th and 5th octets is that it places the created address close to the end of the range for an OUI/MA-L assignment.  

First, a couple of terminology nits.  EUI stands for Extended Unique Identifier.  I would assert that any mapping (especially if done by a third party), has a probability of creating a duplicate number, violating the definition of uniqueness.  Therefore, while the original number might be an EUI-48, the output of the mapping should not be called an EUI-64, because it doesn’t meet the definitions of an Extended Unique Identifier.  Additionally, Some problems with mapping a 48-bit MAC address into a 64-bit MAC address:

1.  There are no restrictions on using an address block assignment for both EUI-48 and EUI-64 creation.  Because the EUI-64 space is very large, it is less likely that a duplicate will be created from a 48-bit MAC address if the assignee is creating EUI-64 sequentially from the base of xx-xx-xx-00-00-00-00-00 (it is a long way from xx-xx-xx-00-00-00-00-00 to xx-xx-xx-FF-FE-yy-yy-yy).  But, there is no requirement for the assignee to do such sequential assignment.

2.  Consideration also has to be given to whether the mapping is done by the device “owning” the EUI-64, or by a third party.  When the device owns the EUI-64, the assignee has options to mitigate the probability for duplicate creation (e.g., sequential assignment of EUI-64).  In the third-party case, I know of no mitigation techniques to reduce the probability of creating a duplicate address when doing the mapping.

3.  For decades, even before there were 64-bit MAC addresses, the IEEE RA has offered blocks of addresses smaller than 2^24.  The IAB I believe was the original (4096 48-bit MAC addresses).  The OUI-36 assignment (now called MA-S) came about with 64-bit MAC addresses.  With either of these assignment types, the IEEE specified mapping will create a 64-bit address in a block potentially assigned to another entity.  (Subsequently, a medium sized block MA-M, was offered by the IEEE RA, and this size block has the same problems as the smaller MA-S block).

4.  For third-party mapping, the source typically would be an address in the frame  As we all know, the destination address can have the I/G and/or U/L bit set to 1, either of which places the address outside the range for EUI.  For the source address, only I/G bit must be zero in a valid address, but a local address by definition is only unique on the layer 2 network (the edge of the L2 network bounded by a router). 

You are up against similar problems.  In general, mappings into either 48-bit or 64-bit MAC addresses create a probability of creating a duplicate where before the only probability was the result of error or failure.

—Bob

> On Jun 25, 2018, at 11:44 AM, Charlie Perkins <[email-masked]> wrote:
> 
> 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.
>

---

From: ROBERT GROW <[email-masked]>
Date: Mon, 25 Jun 2018 12:54:35 -0700

Charlie:

An additional thought just hit me.  A CID could be used to place a mapped address into the local address space.  (Don’t now if that meets your IPv6 requirements.)  Something like mapping pp-pp to cc-cc-cc-pp-pp-xx.  I haven’t really thought about it enough to look for the subtle faults, but the CID provides the U/L and I/G bits per Std 802 addressing and would provide a degree of isolation from other algorithmic address assignment (except when Wi-Fi random local address selection covers the complete local address space.  The xx bits could either lead or trail the pp-pp I think.  Std 802c specifies the Structured Local Address Plan (SLAP), the CID portion being one quadrant of the local space.  Another quadrant might also be used, the SAI (Standard Assigned Identifier) quadrant, where rather than using one or more CID, a fixed block could be allocated for the mapping.  The same caveat about Wi-Fi random local address use for privacy would hold for the SAI quadrant.

More thought required on this obviously.  Also, you will want to work with the RAC during standard development if doing any mapping into 48-bit or 64-bit MAC addresses.

—Bob

> On Jun 25, 2018, at 12:19 PM, ROBERT GROW <[email-masked]> wrote:
> 
> Charlie:
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 25 Jun 2018 16:06:48 -0400

Bob:

It seems that any OIU could be used as the prefix for cc-cc-cc-pp-pp-xx, not just a CID.  If there is adequate demand for the pp-pp to cc-cc-cc-pp-pp-xx conversion, then anOUI or CID could be assigned for this purpose.

Russ

> On Jun 25, 2018, at 3:54 PM, ROBERT GROW <[email-masked]> wrote:
> 
> Charlie:
>

---

From: Robert Grow <[email-masked]>
Date: Mon, 25 Jun 2018 14:34:50 -0700

Russ:

An assignment of an OUI for that purpose would violate current IEEE RA guidelines.  The RAC would need to be convinced why an OUI is needed and a CID won’t do before the OUI assignment would be done.

I haven’t reviewed if any existing OUI assignments to IETF or IEEE 802 could be used for the prefix.  Knowing for sure that EUIs based on that OUI wouldn’t be duplicated by the mapping could be a challenge.

—Bob

> On Jun 25, 2018, at 1:06 PM, Russ Housley <[email-masked]> wrote:
> 
> Bob:
>

---

From: "Stanley, Dorothy" <[email-masked]>
Date: Mon, 25 Jun 2018 21:50:21 +0000

All,

The results of the doodle poll show the most attendees for THURSDAY, June 28th at 8am Pacific.
The coordination list and other items are here: https://www.iab.org/activities/joint-activities/iab-ieee-coordination/ .

Cindy, would you please send out a webex invite with teleconference meeting details?

Thanks,

Dorothy

------------------------
Dorothy Stanley

From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Stanley, Dorothy
Sent: Friday, June 22, 2018 10:10 AM
To: [email-masked]
Cc: Russ Housley <[email-masked]>
Subject: [ieee-ietf-coord] Doodle poll to schedule Late June/Early July 2018 coordination call

All,

Agenda items:

2.       Action item updates

3.       IETF new work summary

4.       802 New Work summary

7.       Next meetings

8.       Adjourn

Thanks,

Dorothy and Russ
------------------------
Dorothy Stanley

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 26 Jun 2018 10:57:18 +0000

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 <[email-masked]>
> Sent: lundi 25 juin 2018 20:45
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]
> 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.
> 
> > 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
> >
> 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.
> >>
> >>> 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
> >>>> 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
> >>>>
> >>>>
> >>>> 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
> >>>>> 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?

---

From: Robert Grow <[email-masked]>
Date: Tue, 26 Jun 2018 08:12:24 -0700

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=[email-masked]> wrote:
> 
> Hello Charlie, 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 26 Jun 2018 15:18:48 +0000

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

> From: Robert Grow <[email-masked]>
> Sent: mardi 26 juin 2018 17:12
> Cc: Charlie Perkins <[email-masked]>; [email-masked]
> > On Jun 26, 2018, at 3:57 AM, Pascal Thubert (pthubert)
> <pthubert=[email-masked]> 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
> >
> >> 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.
> >>
> >>>> Le 25 juin 2018 à 19:46, Charlie Perkins
> >>>> <[email-masked]> a
> >> écrit :
> >>>>
> >>>> Hello folks,
> >>>>
> >> 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.
> >>>>
> >> making the OUI into the leading 24 bits.  But the OUI already had
> >> 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.
> >>>>
> >>>>> OK, it would have been better if I had said "converts the format
> >>>>> of X to Y" instead of "converts X to Y".
> >>>>>
> >>>>> this mapping without any deprecation, seems to no longer be on the
> web..
> >>>>>
> >>>>> Thanks,
> >>>>> Donald
> >>>>>  155 Beaver Street, Milford, MA 01757 USA  [email-masked]
> >>>>>
> >>>>>
> >>>>>> The purpose of developing EUI-64 was to have a larger address
> >>>>>> space that could be used for (among other things) software instances.
> >>>>>> On Jun 24, 2018, at 5:52 PMPDT, Donald Eastlake
> >>>>>> <[email-masked]>
> >> wrote:
> >>>>>>
> >>>>>> Hi Charlie,
> >>>>>>
> >>>>>> 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
> >>>>>>  155 Beaver Street, Milford, MA 01757 USA  [email-masked]
> >>>>>>
> >>>>>>> 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?

---

From: Roger Marks <[email-masked]>
Date: Tue, 26 Jun 2018 12:19:56 -0400

Historically, before the mapping was deprecated, the IEEE stated that:

"To support mapping of EUI-48 values within small subsets of the EUI-64
values, the first four digits of the manufacturer's extension identifier of
an EUI-64 shall not be FFFF or FFFE."

In my understanding, that was the key to preventing such collisions.

Roger

On June 26, 2018 at 9:19:26 AM, Pascal Thubert (pthubert) (
pthubert=[email-masked]) 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

> But, is there anything that prevents it from being a duplicate of an
EUI-48? I
> don’t think so.
> >> Subject: Re: [ieee-ietf-coord] Rationale for 0xFFFE as octets 4 and 5
pf EUI-
> 64?

---

From: Robert Grow <[email-masked]>
Date: Tue, 26 Jun 2018 10:22:45 -0700

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=[email-masked]> wrote:
> 
> Hello Bob:
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 26 Jun 2018 17:40:52 +0000

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

> From: ieee-ietf-coord <[email-masked]> On Behalf Of Robert
> Grow
> Sent: mardi 26 juin 2018 19:23
> To: Pascal Thubert (pthubert) <pthubert=[email-masked]>
> 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.
> 
> 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=[email-masked]> wrote:
> >
> > Hello Bob:
> >
> particular confusion between the EUI-48 derived from PANid/short_addr  and
> a real network address is impossible.
> >> EUI-48?  I don’t think so.
> >>
> >> —Bob
> >>
> >>>> 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.
> >>>>
> >>>> 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.
> >>>>>>
> >>>>>>> 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
> >>>>>>>> does not actually "convert" anything in a useful way except to
> >>>>>>>> to make a "EUI-48" readable in a 64 bit system.
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>> 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

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 29 Jun 2018 16:43:45 -0700

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.

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 29 Jun 2018 23:00:01 -0700

Hello folks,

Please excuse my stupid typo, which I will point out inline below...

On 6/29/2018 4:43 PM, Charlie Perkins wrote:
> 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 
> 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.
>
> is not an EUI-64, and that IPv6 Duplicate Address Detection was 
> designed just to eliminate such conflicts as these.
>
> Regards,
> Charlie P.
>
>
>> 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
>>
>>> 5 pf EUI-64?
>>> Yes, an EUI-64 used as a 64-bit MAC address can have 0xFFFE in 
>>> octets 4 and
>>> 5.
>>>
>>>> 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
>>>>
>>>>> Subject: Re: [ieee-ietf-coord] Rationale for 0xFFFE as octets 4 
>>>>> and 5 pf EUI-
>>> 64?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 30 Jun 2018 08:55:37 +0000

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 <[email-masked]> a écrit :
> 
> Hello folks,
> 
>> 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:
> 
>> 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:
> 
>> 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.
>> 
>>