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
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… Pascal Thubert (pthubert)
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… Robert Grow
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… Roger Marks
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… Pascal Thubert (pthubert)
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… Robert Grow
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… Pascal Thubert (pthubert)
- Re: [ieee-ietf-coord] Doodle poll to schedule Lat… Stanley, Dorothy
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… Robert Grow
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… Russ Housley
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… ROBERT GROW
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… ROBERT GROW
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… Charlie Perkins
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… Pascal Thubert (pthubert)
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… Charlie Perkins
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… Donald Eastlake
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… Donald Eastlake
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… John Messenger
- [ieee-ietf-coord] Rationale for 0xFFFE as octets … Charlie Perkins
- [ieee-ietf-coord] Doodle poll to schedule Late Ju… Stanley, Dorothy
- Re: [ieee-ietf-coord] Rationale for 0xFFFE as oct… Geoff Thompson
- [ieee-ietf-coord] Whether or not RFC 4944 can pro… Charlie Perkins
- Re: [ieee-ietf-coord] Whether or not RFC 4944 can… Pascal Thubert (pthubert)
- Re: [ieee-ietf-coord] Whether or not RFC 4944 can… Charlie Perkins