RE: A common problem with SLAAC in "renumbering" scenarios

"Manfredi (US), Albert E" <albert.e.manfredi@boeing.com> Tue, 19 February 2019 20:23 UTC

Return-Path: <albert.e.manfredi@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 AA81E130F03 for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 12:23:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 A01AmRfN7yhw for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 12:23:38 -0800 (PST)
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 E5E1C130EF2 for <ipv6@ietf.org>; Tue, 19 Feb 2019 12:23:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x1JKNaFJ031376; Tue, 19 Feb 2019 15:23:36 -0500
Received: from XCH16-01-08.nos.boeing.com (xch16-01-08.nos.boeing.com [144.115.65.218]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x1JKNPvn030267 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 19 Feb 2019 15:23:25 -0500
Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-08.nos.boeing.com (144.115.65.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Tue, 19 Feb 2019 12:23:24 -0800
Received: from XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323]) by XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323%4]) with mapi id 15.01.1591.014; Tue, 19 Feb 2019 12:23:24 -0800
From: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
To: Ole Troan <otroan@employees.org>
CC: 6man WG <ipv6@ietf.org>
Subject: RE: A common problem with SLAAC in "renumbering" scenarios
Thread-Topic: A common problem with SLAAC in "renumbering" scenarios
Thread-Index: AQHUyEyd7V+FnESOAEi8Djm3PcxDpKXnkQUAgAAMpICAAAE4AP//6oXQ
Date: Tue, 19 Feb 2019 20:23:23 +0000
Message-ID: <0e0404b4b05a472ab33ca7ade7d0a7b0@boeing.com>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <d38857c2-6e92-91d6-bb5d-d3eeeb61276a@gmail.com> <CAO42Z2yb47OyXk__Sz-kO00pfcBJgLAhff5DF=mpAddR0iCnAA@mail.gmail.com> <2612280f-195a-ae7a-b3b1-9022d9282fa7@foobar.org> <56F813F4-C512-40A9-8A68-1090C76A80F6@consulintel.es> <CAHL_VyCN8kU7qnLOphfGR25-xGBe_p6WeGTkKVXwU5uy5aJ8Dg@mail.gmail.com> <65DB4854-97D2-4C31-A691-2CD93812EF93@consulintel.es> <CAHL_VyCMpCcGkEQu+RV1GRf2QLB-HD0+AOOBV0YhfQ5sbydVzQ@mail.gmail.com> <8CE7A0CD-97D9-46A0-814D-CAF8788F9964@consulintel.es> <e3e0bf2273e04f15b792665d0f66dfe5@boeing.com> <4c5fab33-2bff-e5b5-fc1d-8f60a01a146d@go6.si> <b4525832-9151-20bf-7136-31d87ba6c88d@huitema.net> <463f15cf-2754-e2e8-609d-dc0f33448c6c@go6.si> <ff649810-7242-7bc2-d36f-3f998f7bdd71@asgard.org> <9CDF41CA-83B4-4FC4-B995-EF79727C5458@steffann.nl> <CAO42Z2wA+vLmU7+sU6xLK7TO6pWfNQA5shs9zp=PqANCihLmBQ@mail.gmail.com> <BAB3061A-1808-4C0E-AA1B-2D7DD5BA63FC@employees.org> <alpine.DEB.2.20.1902191402570.24327@uplift.swm.pp. se> <E1EDCB07-CE7D-4BB5-BE07-CDA018C6DF82@employees.org>
In-Reply-To: <E1EDCB07-CE7D-4BB5-BE07-CDA018C6DF82@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [144.115.204.6]
x-tm-snts-smtp: 0A4FB72D258F317851D2A3C7312B2215B9E97A177E686C79CFF032EA5E0B07A02000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hEBOP3VlJLLKc0K2xtCRvhnUv54>
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: Tue, 19 Feb 2019 20:23:39 -0000

-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Ole Troan

> On 19 Feb 2019, at 14:07, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>>
>> Indeed. Wonder how these pesky mobile phone operators manage to deliver the same telephone number to a user, for years. Across different providers and contracts.
> 
> They use a directory to convert between the stable identifier used, and the temporary one that can be changed, so that the stable identifier is fairly easily handled by humans. If only we would have that...
> 
> Oh, wait... we do. DNS.

Exactly. An extra layer of abstraction is introduced in mobile telephony, and the "telephone number" now becomes merely a unique identifier, not used for routing. So the example is much more similar to say, what the enum wg did in the past, to convert telephone numbers into IP addresses, and really nothing to do with IP addresses as they relate to routing packets, and never mind the security/privacy issues that have been elaborated for so long, with respect to stable IIDs.

In short, if the IETF were to push for stable IPv6 addresses to customers, especially mobile customers, then the route aggregation problems don't go away, nor do the security and privacy problems. They become hidden underneath this upper layer of abstraction.

The privacy concern I think we have been trying to alleviate is to make that actual IPv6 prefix, the one used for routing packets, not permanently linked to the same household, for all time. Any abstract, DNS-like, IP address, which is mapped to the actual IPv6 address, is not really the issue here, I don't think.

Bert