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

Tom Herbert <tom@herbertland.com> Tue, 19 February 2019 21:03 UTC

Return-Path: <tom@herbertland.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 53C41129AA0 for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 13:03:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 B1aaDEqWmJVC for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 13:03:50 -0800 (PST)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 AA81812426E for <ipv6@ietf.org>; Tue, 19 Feb 2019 13:03:50 -0800 (PST)
Received: by mail-qt1-x82f.google.com with SMTP id p25so24612421qtb.3 for <ipv6@ietf.org>; Tue, 19 Feb 2019 13:03:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=j9JYvJfUH3VbV8vkduL8zipoNtT87kMWW+YpPGYxqeI=; b=09rUWJ3ddcmX0h3yV8unqre32FagALaoxYbDpEKD/SLwdM+shu4f3KHcGZn7qmB9ws mAq3b6eKUAGOL6JUkYWmpjSDy38T4vFMB59axbrwQ8qtXRU3UwfkmvhDdWC/eP5sC04E dahopSpGP1vv8I5creiQ5DodEma2otugYU48tbCRGsOkiCflXThRVMMXWKd9R/0VCRHT GNhodV3Qw7J3S96DqV/hXa9P1+dxFmXNwscSILmB8QQNh9xWtKKNgZ+AOxATYwiOR123 R/Z0Pbx4hreAmmlD/97rJbrQEwM2A+zyTpyH9XvQRK/b9nI5K9zDgb0q7Q29yLgh+xZn t4xQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=j9JYvJfUH3VbV8vkduL8zipoNtT87kMWW+YpPGYxqeI=; b=V/o7WETsh9fwL7liZl9R++yUh0ZPevsfIOAJCN7aJ/Plh19rQMr8Z7goIuBGHfSkXs ZbagHRlXmIaVVgvaEURiKR5HMs+M/gKDrldMAjAMds/0nRLjvMcsheXzsVKQHWb2oPpz XiBVUjWLyKD1hHXQ86320lFKgvQNtE1Tl2csWvQhaBadhdzUgZwfvzIbXj4m3Ql+3Mqm WVoPtK61YroTwVpLICD5eLPPvmSEztxTnhHf9g3cmFXwM4zUcjtqXnpikZCIGoxlfbKZ 9+fWSbkgFanUKFnT99XAwg43/kzYKsXWQjvgOg/Wi+6LI3KXOU2mG8chKnfbELxrCUFO QESg==
X-Gm-Message-State: AHQUAuaLS2E99bLip9jzhSfScO9GXkK9IBISp9wQ89rvKXhs+trhJuHc ksBqZsdhL0f/h2mBRsoYLOTXc+55BT9kki4gZw7lBg==
X-Google-Smtp-Source: AHgI3IZKlRdVvJLRQ5YIS+a9DniKD/td7WIFUxtOEEbFjmv5SUALKqN47JuWOD5TAEYEzfn4kP5UxxG0sk49KI6CKbo=
X-Received: by 2002:a0c:9681:: with SMTP id a1mr12187851qvd.72.1550610229709; Tue, 19 Feb 2019 13:03:49 -0800 (PST)
MIME-Version: 1.0
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> <E1EDCB07-CE7D-4BB5-BE07-CDA018C6DF82@employees.org> <0e0404b4b05a472ab33ca7ade7d0a7b0@boeing.com>
In-Reply-To: <0e0404b4b05a472ab33ca7ade7d0a7b0@boeing.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 19 Feb 2019 13:03:38 -0800
Message-ID: <CALx6S35A_CiwNkARMHKVCZ_QQLObPLq-XJuyOLf-93JjVOGkvw@mail.gmail.com>
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
Cc: Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/QqEyftw1sIetUsmOhfa7i9i8K0A>
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 21:03:53 -0000

On Tue, Feb 19, 2019 at 12:23 PM Manfredi (US), Albert E
<albert.e.manfredi@boeing.com> wrote:
>
> -----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.
>
I believe in mobile networks it the stable identifier of a device is
an IMSI. It would be a very bad idea to create IP addresses that embed
an IMSI, there is not security or privacy in that. It's similar to how
MAC addresses shouldn't be encode in IP addresses. So there is always
at least some decoupling between identity and address. As the demand
for secuirity and privacy increases, the need for decoupling them
increases as well. Taking that to its fullest extent, maximum privacy
and security happens when addresses are completely decoupled from
identity so that a third party cannot make any inference or
correlations about identity, location, or any other PII just based on
observation of IP addresses in packets. That requires very dynamic
addressing.

Tom

> 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
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------