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

Jan Zorz - Go6 <jan@go6.si> Fri, 15 February 2019 12:13 UTC

Return-Path: <jan@go6.si>
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 C8B12130DC9 for <ipv6@ietfa.amsl.com>; Fri, 15 Feb 2019 04:13:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=go6.si
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 neTNOyiMVaLX for <ipv6@ietfa.amsl.com>; Fri, 15 Feb 2019 04:13:34 -0800 (PST)
Received: from mx.go6lab.si (mx.go6lab.si [91.239.96.23]) (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 243E3124408 for <ipv6@ietf.org>; Fri, 15 Feb 2019 04:13:34 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id CBFBE66077; Fri, 15 Feb 2019 13:13:29 +0100 (CET)
X-Virus-Scanned: amavisd-new at go6.si
Received: from mx.go6lab.si ([IPv6:::1]) by localhost (mx.go6lab.si [IPv6:::1]) (amavisd-new, port 10024) with LMTP id UdbuIhZ9sdhk; Fri, 15 Feb 2019 13:13:28 +0100 (CET)
Received: from mail.go6.si (mail.go6.si [IPv6:2001:67c:27e4::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.go6.si", Issuer "Let's Encrypt Authority X3" (not verified)) by mx.go6lab.si (Postfix) with ESMTPS id C516465E65; Fri, 15 Feb 2019 13:13:28 +0100 (CET)
Received: from ISOC-BMDKQ4.local (unknown [IPv6:2001:67c:27e4:102:182a:e622:682:93c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Jan Zorz", Issuer "COMODO RSA Client Authentication and Secure Email CA" (not verified)) (Authenticated sender: jan) by mail.go6.si (Postfix) with ESMTPSA id 7B598807BC; Fri, 15 Feb 2019 13:13:28 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1550232808; bh=OZhErXq/cAi53X0+dKsQZD9Jd+qICiy4wx433qJ9eEc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=s+rXq8ZZTeFS8IwsnOXtkGcrSsgxt9Mx3TkF6FLflilNoVrbhzoj1OUfsB4B82hiP bXJFK1+OcsyNekk8Bsdi35JuTa3GzBYTgDXIPA6LvmI4x4dednzZgSoghf3i9zWYYX YkkABrXylcWdbzBnpuPr9s1DaG2M4s1O34Mphx2E=
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: Christian Huitema <huitema@huitema.net>
Cc: ipv6@ietf.org
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <c16e0e1f-1ed2-ad88-80f1-070bdd8bccca@go6.si> <1F2C2AEE-1C7D-481C-BBA7-7E507312C53A@employees.org> <e56a6e5b-648d-200e-c35d-97f15a31fb2a@asgard.org> <CAO42Z2zh7fKAgQJq9aLCTiFoSSsTeGM=pK3gXitg+gcxH=9fhQ@mail.gmail.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> <463f 15cf-2754-e2e8-609d-dc0f33448c6c@go6.si> <444A9043-0EDF-4F21-9DCE-BF019B81D078@huitema.net>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <48b6d536-592b-0fcb-66da-b9b2201210e9@go6.si>
Date: Fri, 15 Feb 2019 13:13:27 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <444A9043-0EDF-4F21-9DCE-BF019B81D078@huitema.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/FN-XohOuDTrX4njjeyKCqr9ApQU>
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: Fri, 15 Feb 2019 12:13:36 -0000

On 15/02/2019 10:37, Christian Huitema wrote:
> 
> 
>> On Feb 14, 2019, at 11:30 PM, Jan Zorz - Go6 <jan@go6.si> wrote:
>> 
>> /64 for each device is fine. What I'm questioning is if we really
>> need to make underlying to be something that was never meant to be
>> if L7 and above is broken? I think L7 and above needs to be fixed
>> first and then changing of addresses in transport layer can have
>> any effect. Until then - let's transport packets in a way that
>> doesn't break often and make user grumpy.
> 
> We are pretty far from the original thread, but let me say that
> looking at layers as if they were isolated does not work. Tracking
> uses all the cues that it can, from MAC addresses to GPU model. It
> will of course use 64 bit prefixes when available. That a beautiful
> index for the surveillance operations. It is pretty clear that we
> need to somehow defend against that.

Actually, we are not very far from original thread, as sometimes 
operators are implementing PD to be "dynamic" also because of percieved 
privacy reasons and it's essential that we figure out if changing the 
prefixes dynamically adds anything to privacy or nothing.

Cheers, Jan