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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 15 February 2019 09:57 UTC

Return-Path: <alexandre.petrescu@gmail.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 BBE5E130FA0 for <ipv6@ietfa.amsl.com>; Fri, 15 Feb 2019 01:57:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 HXhiuLx636su for <ipv6@ietfa.amsl.com>; Fri, 15 Feb 2019 01:57:08 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 1EC96130F9F for <ipv6@ietf.org>; Fri, 15 Feb 2019 01:57:07 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x1F9v5gE037408 for <ipv6@ietf.org>; Fri, 15 Feb 2019 10:57:05 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id ECB682063AE for <ipv6@ietf.org>; Fri, 15 Feb 2019 10:57:05 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E2156201892 for <ipv6@ietf.org>; Fri, 15 Feb 2019 10:57:05 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x1F9v5QY024022 for <ipv6@ietf.org>; Fri, 15 Feb 2019 10:57:05 +0100
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: 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: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <a036a6a4-26c7-66df-9094-7af67e424711@gmail.com>
Date: Fri, 15 Feb 2019 10:57:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; 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: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/UeRvTwXfh9jvtVY7AjIzKQpp0EI>
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 09:57:11 -0000


Le 15/02/2019 à 10:37, Christian Huitema a écrit :
> 
> 
>> 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.

Address the surveillance operations at their root would allow freedom to 
design session continuity IPv6 mechanisms safely assuming that the root 
of the surveillance operations is ok.

If possible :-)

(I can assure you that changing IP addresses all the time is a nightmare 
in implementations :-)

Alex

> 
> -- Christian Huitema 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>