Re: [ieee-ietf-coord] Rationale for 0xFFFE as octets 4 and 5 pf EUI-64?
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 26 June 2018 10:57 UTC
Return-Path: <pthubert@cisco.com>
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 B650E127598 for <ieee-ietf-coord@ietfa.amsl.com>; Tue, 26 Jun 2018 03:57:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 d0eNSFpHao6e for <ieee-ietf-coord@ietfa.amsl.com>; Tue, 26 Jun 2018 03:57:48 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32DD12F1AB for <ieee-ietf-coord@ietf.org>; Tue, 26 Jun 2018 03:57:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9258; q=dns/txt; s=iport; t=1530010668; x=1531220268; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Jx7Ik6gwWk2JA14U6w57wPK3A865Y0g+vLJthSGXv4o=; b=Maij3G5vBIfrw/FRFFjkWP7CcvJqSXBy4dInZn6P0ivpskjFtRF/vpzW 068ccymloi1D/0eRsV5muwKl39UdFnkP4WyyXaKH+qw2vKZGwzqP7W//S vLr7kH23jJLAos4Oh5FTpzhFwKnLLaKPBRTApreqLzfXUYyUk3AaVc1nW Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CrAQDiGzJb/49dJa1ZAxkBAQEBAQEBAQEBAQEHAQEBAQGDKgEBAQEhYn8oCoNvlEaCB4grjGkUgWYLGAuBVIJ1AheCeSE2FgECAQEBAQEBAm0cDIUoAQEBAgIBASEROgsMBAIBCA4DBAEBAQICJgICAh8GCxUICAIEDgUIEYMNgWcDFQ+sJIIchw4NgSyBGoELh2GBVj+BDoISUC6CVkIBAQGBLAESATYKBSGCOoJVApkFLAkChX6CZIMmgwGCCotIiiVOhlYCERMBgSQjATFhcXAVO4JpCYIXAxeIWYU+bwEvjRyBH4EaAQE
X-IronPort-AV: E=Sophos;i="5.51,274,1526342400"; d="scan'208";a="134233294"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2018 10:57:40 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w5QAveko021896 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jun 2018 10:57:40 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 26 Jun 2018 05:57:39 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Tue, 26 Jun 2018 05:57:39 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Charlie Perkins <charles.perkins@earthlink.net>
CC: "ieee-ietf-coord@ietf.org" <ieee-ietf-coord@ietf.org>
Thread-Topic: [ieee-ietf-coord] Rationale for 0xFFFE as octets 4 and 5 pf EUI-64?
Thread-Index: AQHUCpUfG96DM+04w0y7izZ0lu5NiKRwfDiAgAAJ1gCAADD7AIAA4GQA//+1tjiAAFqeAIAAuwfg
Date: Tue, 26 Jun 2018 10:57:18 +0000
Deferred-Delivery: Tue, 26 Jun 2018 10:56:57 +0000
Message-ID: <70743d292ffb4c9eaa95572853e69b3a@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>
In-Reply-To: <1f8a9039-6efe-3a29-27e7-53d798d1e099@earthlink.net>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.242.164]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ieee-ietf-coord/lrlbjVSCCDlcerN6EwxO351IIB4>
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 10:57:51 -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 <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
- 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