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

Roger Marks <r.b.marks@ieee.org> Tue, 26 June 2018 16:20 UTC

Return-Path: <r.b.marks@ieee.org>
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 46730131062 for <ieee-ietf-coord@ietfa.amsl.com>; Tue, 26 Jun 2018 09:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.com
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 vLvczG4zT6Nj for <ieee-ietf-coord@ietfa.amsl.com>; Tue, 26 Jun 2018 09:20:00 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BAB8131059 for <ieee-ietf-coord@ietf.org>; Tue, 26 Jun 2018 09:19:59 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id k20-v6so7578189ljk.9 for <ieee-ietf-coord@ietf.org>; Tue, 26 Jun 2018 09:19:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=QHkxLKma5Atfqn06NvcHWlktH6B/BeRYB7dIvwC0dFU=; b=0bACaTI7jDQJoRbwHOFBeg2vxDPGmX0RNXLWi8OMhiMfR8I2xhlUx96wMjabLdRR+J N3zu6TpGVq6iEREaKgT6uZ+RsVT2lmST9wEjeuyYUnYsaY0hQTy5fWnjRxCwrTUtIa2x Nk2OD9pJkvnVsWu1ZkdQ9iraHVo2HmFPCsUX/XI8wA6ZlYMIcHk//gDF6w4PADuQEjOk LqbYci1OJj1gtj1sLXPm20uTFSECrSHHxucnUq/0NHBEMaNWJjM9n7NAOFjoXEOs7opi +xpRazEsNwU3fn7IxmYEz26NdObHhp20OD5jMPp0QW8lml6RY2Yr0AiKd8HHeseQs4c9 oRUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=QHkxLKma5Atfqn06NvcHWlktH6B/BeRYB7dIvwC0dFU=; b=nCHSyex/e9QsSaQplSyf5mkeyt86X5ZJEop07O+pU8sUgmL2SMISH5W41ltmz1W9SJ T8Ow3iAmpXFgs8ZVAKtAA4b7ccdbjU9hxCrVH++e5mhT/aUUSWybO4IzwAeletLJInGO V9DcelkPfgQiyuGh9Tip7yhV5x19/MUKPQUrzZdqGiWlu8mJTpPQYq2cJEImmfNLTXol p/tUTTK2GkVbRvGJ9UxOTFnimUNjjQleYI5UWDo7nPhkOMTG1nkJhRK2/SG/ZHIkTdOF cXjAGS37QTDtFrQ6tdgYEZs2fKoBF0z1USBKUecIxFAyFMgJ1++K2/r8Stt2CR65CRTd 4ofA==
X-Gm-Message-State: APt69E1S8Isk7+Kg4dIqQmUe+2cBYxtEmOzPlsRSTOdBfR/AMXqKozOK mM4/r1/go0BH/YwtERq/rxXMp46jF4ECZqD4Qds/bA==
X-Google-Smtp-Source: AAOMgpfy4lr5MmYX20xd7n9DxcFtayd/2yTF6cf0mZSnzNxO1n8UC3fexvlWCJb/6MW4FThc9DkgDMBfPS38X4NI+8U=
X-Received: by 2002:a2e:8990:: with SMTP id c16-v6mr1670394lji.123.1530029997163; Tue, 26 Jun 2018 09:19:57 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 26 Jun 2018 12:19:56 -0400
From: Roger Marks <r.b.marks@ieee.org>
In-Reply-To: <aa8c454d93804dfb9015362cb67731b8@XCH-RCD-001.cisco.com>
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> <1f8a9039-6efe-3a29-27e7-53d798d1e099@earthlink.net> <3Nxt1y00P0xxhYs01Nxuaq> <15B88F7B-0A03-4713-98DB-3C2F636A545E@cox.net> <aa8c454d93804dfb9015362cb67731b8@XCH-RCD-001.cisco.com>
X-Mailer: Airmail (492)
MIME-Version: 1.0
Date: Tue, 26 Jun 2018 12:19:56 -0400
Message-ID: <CAFBzqpdvnO2w+WSV6VX9cQE_D5becg56=WbdUQvzyw5utTNN0w@mail.gmail.com>
To: Robert Grow <bobgrow@cox.net>, "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
Cc: "ieee-ietf-coord@ietf.org" <ieee-ietf-coord@ietf.org>, Charlie Perkins <charles.perkins@earthlink.net>
Content-Type: multipart/alternative; boundary="0000000000007a375b056f8dde9f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ieee-ietf-coord/IyAH8a8EXnZjBzWmfXAaRYvxaEs>
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: Tue, 26 Jun 2018 16:20:05 -0000

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=40cisco.com@dmarc.ietf.org) 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 <bobgrow@cox.net>
> Sent: mardi 26 juin 2018 17:12
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Cc: Charlie Perkins <charles.perkins@earthlink.net>;
ieee-ietf-coord@ietf.org
> 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=40cisco..com@dmarc.ietf.org> 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 <charles.perkins@earthlink.net>
> >> Sent: lundi 25 juin 2018 20:45
> >> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> >> Cc: ieee-ietf-coord@ietf.org
> >> 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
> >>>> <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