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

ROBERT GROW <bobgrow@cox.net> Mon, 25 June 2018 19:54 UTC

Return-Path: <bobgrow@cox.net>
X-Original-To: ieee-ietf-coord@ietfa.amsl.com
Delivered-To: ieee-ietf-coord@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B663130E5D for <ieee-ietf-coord@ietfa.amsl.com>; Mon, 25 Jun 2018 12:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N79BPGArwTs4 for <ieee-ietf-coord@ietfa.amsl.com>; Mon, 25 Jun 2018 12:54:37 -0700 (PDT)
Received: from fed1rmfepo201.cox.net (fed1rmfepo201.cox.net [68.230.241.146]) by ietfa.amsl.com (Postfix) with ESMTP id 50B36130E33 for <ieee-ietf-coord@ietf.org>; Mon, 25 Jun 2018 12:54:37 -0700 (PDT)
Received: from fed1rmimpo210.cox.net ([68.230.241.161]) by fed1rmfepo201.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180625195436.DQAT4167.fed1rmfepo201.cox.net@fed1rmimpo210.cox.net> for <ieee-ietf-coord@ietf.org>; Mon, 25 Jun 2018 15:54:36 -0400
Received: from [192.168.1.8] ([68.101.170.159]) by fed1rmimpo210.cox.net with cox id 37uc1y0083Shbfo017ucrK; Mon, 25 Jun 2018 15:54:36 -0400
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A090210.5B31487C.001E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.2 cv=bow8PASi c=1 sm=1 tr=0 a=Q0J3Qw+k6U+l0SJkLnvISQ==:117 a=Q0J3Qw+k6U+l0SJkLnvISQ==:17 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=ehnVqmJ0bsIA:10 a=kviXuzpPAAAA:8 a=5Up8faWwAAAA:8 a=o83nqyVRAAAA:8 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=XHqSvd4TipYcGN3fGKUA:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=PtC2tsv_92plIFvP:21 a=t0y0ZEUog_yo6XVi:21 a=YlwBZfIejVYJzihX:21 a=QEXdDO2ut3YA:10 a=Od2VD5mNr3sA:10 a=qrIFiuKZe2vaD64auk6j:22 a=DyTIyT2i5bKf2by9bU5a:22 a=w1C3t2QeGrPiZgrLijVG:22
X-CM-Score: 0.00
Authentication-Results: cox.net; auth=pass (PLAIN) smtp.auth=bobgrow@cox.net
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: ROBERT GROW <bobgrow@cox.net>
In-Reply-To: <37Kx1y01j0xxhYs017KylF>
Date: Mon, 25 Jun 2018 12:54:35 -0700
Cc: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, "ieee-ietf-coord@ietf.org" <ieee-ietf-coord@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AE133811-AEBA-4392-8CFC-F1DFB45F37D3@cox.net>
References: <TU4PR8401MB06214FDFC0652364F7728557ED750@TU4PR8401MB0621.NAMPRD84.PROD.OUTLOOK.COM> <70d78698-7ec3-3a6e-3200-a958ba520141@earthlink.net> <CAF4+nEEYtZ4diFxLDtwKT=jxXzoyPxmSK3HPKeGHhaDzQKcquQ@mail.gmail.com> <FE807CB8-8EDB-475C-9CF6-B7564CF74AF9@ieee.org> <CAF4+nEE4WpNnkrN+LWL6sXeBLyyqPD6L9Mw0+ddqMMYVafZA8w@mail.gmail.com> <1d723f40-f816-ce07-c807-fde49fc215f4@earthlink.net> <C1AC193E-730A-4897-A5A4-C63A77BEAB3C@cisco.com> <36kh1y02X0xxhYs016kjPL> <37Kx1y01j0xxhYs017KylF>
To: Charlie Perkins <charles.perkins@earthlink.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ieee-ietf-coord/5B3P38LQsGbXXoRTQTZlTBx3QSw>
Subject: Re: [ieee-ietf-coord] Rationale for 0xFFFE as octets 4 and 5 pf EUI-64?
X-BeenThere: ieee-ietf-coord@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Management-level discussions between IEEE and IETF on topics of interest to both SDOs <ieee-ietf-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ieee-ietf-coord>, <mailto:ieee-ietf-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ieee-ietf-coord/>
List-Post: <mailto:ieee-ietf-coord@ietf.org>
List-Help: <mailto:ieee-ietf-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ieee-ietf-coord>, <mailto:ieee-ietf-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jun 2018 19:54:40 -0000

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 <bobgrow@cox.net> wrote:
> 
> 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 <charles.perkins@earthlink.net> 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.
>> 
>> 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 <charles.perkins@earthlink.net> 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   +1-508-333-2270 (cell)
>>>>> 155 Beaver Street, Milford, MA 01757 USA
>>>>> d3e3e3@gmail.com
>>>>> 
>>>>> 
>>>>>> On Sun, Jun 24, 2018 at 9:27 PM, Geoff Thompson <thompson@ieee.org> 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 <d3e3e3@gmail.com> 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   +1-508-333-2270 (cell)
>>>>>> 155 Beaver Street, Milford, MA 01757 USA
>>>>>> d3e3e3@gmail.com
>>>>>> 
>>>>>> On Fri, Jun 22, 2018 at 9:54 PM, Charlie Perkins
>>>>>> <charles.perkins@earthlink.net> 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
>>>>>>> ieee-ietf-coord@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>>>>>> _______________________________________________
>>>>>> ieee-ietf-coord mailing list
>>>>>> ieee-ietf-coord@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>>>>>> 
>>>>>> 
>>>>> _______________________________________________
>>>>> ieee-ietf-coord mailing list
>>>>> ieee-ietf-coord@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>>>>> 
>>>> _______________________________________________
>>>> ieee-ietf-coord mailing list
>>>> ieee-ietf-coord@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>>> _______________________________________________
>>> ieee-ietf-coord mailing list
>>> ieee-ietf-coord@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>> 
>> _______________________________________________
>> ieee-ietf-coord mailing list
>> ieee-ietf-coord@ietf.org
>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
> 
> _______________________________________________
> ieee-ietf-coord mailing list
> ieee-ietf-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord