RE: [EXTERNAL] Re: 64bit MAC addresses and SLAAC

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Wed, 17 June 2020 16:18 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100B43A099C for <ipv6@ietfa.amsl.com>; Wed, 17 Jun 2020 09:18:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=boeing.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 hVBl30UgdbMi for <ipv6@ietfa.amsl.com>; Wed, 17 Jun 2020 09:18:03 -0700 (PDT)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DACA3A0995 for <ipv6@ietf.org>; Wed, 17 Jun 2020 09:18:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 05HGHv9v032508; Wed, 17 Jun 2020 12:18:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1592410680; bh=9Wn406WU0TLsizs8Nl9l8CmmCHkxjPJ26C5mP0eOjNk=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ZSJnQyUeMEIZuTpTh8fFiZHiZPoZWiuqi0aWDf4cVvg3QVqGMMCWJPd4YpyJra+gr f1gEgnMYITzQMt7od32rfYy/kWwFjuGwPZxAn3c8gXP5636NImwmmhP2mMI7sh/PkL EEjHznzkQ795hWra+dmxtNbzzTmt+/EFx8mUcX5NNfV+hdbvnfWRcyS4w/2VRBw2zy oCJl7Lqqi4xcHULTfGaMg0wNqKD/px+0w1obLsdtmCbL0OOAmNpnKtzrxXO/xK4fcX HTiFTLmdI/GFjU7zYC0/eZSnrmqoxpO69wyQk0V0oRfH+rRBhAzU4YO97qSSRwpmRa Q3l9664oP6hmw==
Received: from XCH16-07-11.nos.boeing.com (xch16-07-11.nos.boeing.com [144.115.66.113]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 05HGHmp9031142 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 17 Jun 2020 12:17:48 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-11.nos.boeing.com (144.115.66.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Wed, 17 Jun 2020 09:17:46 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.1979.003; Wed, 17 Jun 2020 09:17:46 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Fernando Gont <fgont@si6networks.com>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, Bob Hinden <bob.hinden@gmail.com>
CC: IPv6 List <ipv6@ietf.org>
Subject: RE: [EXTERNAL] Re: 64bit MAC addresses and SLAAC
Thread-Topic: [EXTERNAL] Re: 64bit MAC addresses and SLAAC
Thread-Index: AQHWRLxN0Qr4A0D/IESNhjm9Y08LE6jc+jnw
Date: Wed, 17 Jun 2020 16:17:46 +0000
Message-ID: <79d494caa7874696b787aadb80cc322b@boeing.com>
References: <e8a25961-5ac9-d35e-77dd-bf86f45cd077@gmail.com> <a17ae9f3-001c-07f6-84f9-a0ca583e6a00@gmail.com> <7AE5B6D0-AB01-4077-A9EF-5BD86F428681@gmail.com> <7a3b839f-099e-8fd3-35a2-4625df3c369e@gmail.com> <76e8bd7a-4333-480f-de0f-dcc775418739@si6networks.com>
In-Reply-To: <76e8bd7a-4333-480f-de0f-dcc775418739@si6networks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: C56FC98562519F4E1F948031813ED237CDC78C7E76DE289E2BF5DE678D2FD84C2000:8
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ViyF4bhZmyJps22mex9yii0IHYA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 16:18:05 -0000

Fernando, I think an unspoken assumption in these past several messages is that
privacy is ALWAYS a required property. However, there are cases where address
privacy is not only not required, but it is also desirable and useful to be able to
track a node by a stable and unchanging IP address or prefix.

This is not intended to challenge the non-use of MAC addresses in Interface
Identifiers per your documents, but just to say that in some environments the
randomization and constant changing of IP addresses may actual run counter to
operational objectives.

Thanks - Fred

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Fernando Gont
> Sent: Wednesday, June 17, 2020 8:21 AM
> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>; Bob Hinden <bob.hinden@gmail.com>
> Cc: IPv6 List <ipv6@ietf.org>
> Subject: [EXTERNAL] Re: 64bit MAC addresses and SLAAC
> 
> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
> know that the content is safe.
> On 17/6/20 08:39, Alexandre Petrescu wrote:
> > Le 15/06/2020 à 23:01, Bob Hinden a écrit :
> >> Alexandre,
> >>
> >>> On Jun 15, 2020, at 1:23 PM, Alexandre Petrescu
> >>> <alexandre.petrescu@gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Before the sanitary situation I was studying an issue at ISO.
> >>>
> >>> The issue is about 64bit MAC addresses and SLAAC.
> >>>
> >>> SLAAC needs a 48bit MAC addresses in order to work, and it can not
> >>> work with a 64bit MAC address; (but yes, it can with 64bit IIDs).
> >>
> >> SLACC does not specify the length of the Interface ID, it does not
> >> require require 48-bit MAC addresses, and the reason for Modified
> >> EUI-64 Format Interface Identifiers in RFC4291 was to support 64bit
> >> EUI-64 Identifiers.   We have since moved away from using MAC
> >> addresses as Interface IDs.  See RFC 8064.
> >
> > Bob,
> >
> > RFC8064 says "this document [...] recommends against embedding stable
> > link-layer addresses in IPv6 Interface Identifiers".
> >
> > But a 64bit MAC address could be a random number as well, not
> > necessarily stable.  Windows randomizes some of its MAC addresses.
> 
> Reusing IDs in multiple contexts is known to be a bad idea. See e.g.:
> https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation and
> https://tools.ietf.org/html/draft-gont-numeric-ids-sec-considerations
> 
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------