Re: [ieee-ietf-coord] Rationale for 0xFFFE as octets 4 and 5 pf EUI-64?
Robert Grow <bobgrow@cox.net> Tue, 26 June 2018 15:12 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 DE728130E84 for <ieee-ietf-coord@ietfa.amsl.com>; Tue, 26 Jun 2018 08:12:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 xHlVS4Ke2aaO for <ieee-ietf-coord@ietfa.amsl.com>; Tue, 26 Jun 2018 08:12:37 -0700 (PDT)
Received: from fed1rmfepo103.cox.net (fed1rmfepo103.cox.net [68.230.241.145]) by ietfa.amsl.com (Postfix) with ESMTP id CF0BC130DFD for <ieee-ietf-coord@ietf.org>; Tue, 26 Jun 2018 08:12:36 -0700 (PDT)
Received: from fed1rmimpo109.cox.net ([68.230.241.158]) by fed1rmfepo103.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180626151236.MMCE4184.fed1rmfepo103.cox.net@fed1rmimpo109.cox.net> for <ieee-ietf-coord@ietf.org>; Tue, 26 Jun 2018 11:12:36 -0400
Received: from [192.168.1.2] ([68.101.170.159]) by fed1rmimpo109.cox.net with cox id 3TCR1y0063Shbfo01TCWZm; Tue, 26 Jun 2018 11:12:35 -0400
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A090209.5B3257E4.0010, 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=U/viNaju 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=48vgC7mUAAAA:8 a=5Up8faWwAAAA:8 a=AUd_NHdVAAAA:8 a=o83nqyVRAAAA:8 a=pGLkceISAAAA:8 a=vI3iYzKKGoUksG8A8mUA:9 a=rlVhngfOp0H9ntcr:21 a=YC1m6pllJ_9ivakK:21 a=QEXdDO2ut3YA:10 a=Od2VD5mNr3sA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=DyTIyT2i5bKf2by9bU5a: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 (1.0)
From: Robert Grow <bobgrow@cox.net>
X-Mailer: iPad Mail (15F79)
In-Reply-To: <3Nxt1y00P0xxhYs01Nxuaq>
Date: Tue, 26 Jun 2018 08:12:24 -0700
Cc: Charlie Perkins <charles.perkins@earthlink.net>, "ieee-ietf-coord@ietf.org" <ieee-ietf-coord@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <15B88F7B-0A03-4713-98DB-3C2F636A545E@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> <1f8a9039-6efe-3a29-27e7-53d798d1e099@earthlink.net> <3Nxt1y00P0xxhYs01Nxuaq>
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ieee-ietf-coord/MD-DBqTv_fxXo6nuOkk8CArE7R8>
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 15:12:40 -0000
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
- 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