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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 14 February 2019 10:51 UTC

Return-Path: <prvs=1948fd41cf=jordi.palet@consulintel.es>
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 E905713107D for <ipv6@ietfa.amsl.com>; Thu, 14 Feb 2019 02:51:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 F63IlFTEP6pu for <ipv6@ietfa.amsl.com>; Thu, 14 Feb 2019 02:51:53 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8760B131050 for <ipv6@ietf.org>; Thu, 14 Feb 2019 02:51:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1550141509; x=1550746309; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=UwS/ohYh3Q8h/mTXuXXi3Z4dqP35/gMXq2Rsj8cMLNM=; b=TiDYRt0q8rq5c G6gydtDFHQ4Ws0Z/MUAfgcTusTqkqnhsCaVwQbxPBv59bCA6lIbq+7XEUXyS/COZ 0smaxJpDZvW5QbR3pbSi2L28vAAzY7EhAIuqd0bMCMvHVo306R/nPiTksNkd/BZa ukIgy+KmSAlUDDawFzkWSme1262vy8=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Thu, 14 Feb 2019 11:51:49 +0100
X-Spam-Processed: mail.consulintel.es, Thu, 14 Feb 2019 11:51:48 +0100
Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006154646.msg for <ipv6@ietf.org>; Thu, 14 Feb 2019 11:51:47 +0100
X-MDRemoteIP: 2001:470:1f09:495:2cd1:4c11:8272:8b78
X-MDHelo: [10.10.10.139]
X-MDArrival-Date: Thu, 14 Feb 2019 11:51:47 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1948fd41cf=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.7.190210
Date: Thu, 14 Feb 2019 11:51:42 +0100
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Richard Patterson <richard@helix.net.nz>
CC: 6man WG <ipv6@ietf.org>
Message-ID: <65DB4854-97D2-4C31-A691-2CD93812EF93@consulintel.es>
Thread-Topic: A common problem with SLAAC in "renumbering" scenarios
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <m1gptWx-0000G3C@stereo.hq.phicoh.net> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <d40b41c3-ff1b-cab4-a8de-16692a78e8fd@go6.si> <D1E45CAD-08D0-43D4-90F7-C4DD44CB32C0@employees.org> <alpine.DEB.2.20.1902041330531.23912@uplift.swm.pp.se> <46B8DB92-DC81-4242-9780-0D00FB6BDB7A@employees.org> <1c7ebabb-d6f6-d877-d4aa-d6c0fc7d5c60@go6.si> <6278.1549471453@dooku.sandelman.ca> <CAO42Z2xdKtLJV11KXELBKca6CWn=B6Avz6bO_94kFFXaKiZ-pQ@mail.gmail.com> <4602.1549908472@localhost> <CAO42Z2w1swQNuwnrOyTCEMXt0NSyrBx7Ww3kUN-7dfEV=fvk3A@mail.gmail.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>
In-Reply-To: <CAHL_VyCN8kU7qnLOphfGR25-xGBe_p6WeGTkKVXwU5uy5aJ8Dg@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gM921Od0lz5Ra8thj4-XzzOahw4>
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: Thu, 14 Feb 2019 10:51:56 -0000

There are many other ways to track people. I don't really think that having a different prefix, even if it changes every few minutes, will avoid anyone to be tracked.

In addition to that, I think it is easy for operators to implement a policy such as a configuration web page for your connectivity where you can choose a non-persistent prefix to be changed in your network every "n" hours. Up to the ISP to decide if the default policy is "persistent" or "non-persistent".

Up to each ISP to decide if they allow the customer to choose the number of hours of persistence.

If I'm the one designing this web page, I will make sure to warn the users in the "non-persistent" option, with some text in the line of: "when your prefix is replaced, your network is shortly interrupted, so running transactions may break. In addition to that, it may happen that when the prefix is replaced due to a power out-age, reboot or reset of the router or other network devices, some other devices in your network may remember the old prefix for some time, and you may experience connectivity difficulties during that period".

So it is up to each user to balance if they want a "false privacy feeling" or "network stability and the ability to run services which not depend on crappy dynamic DNS service, which most of the time you also need to pay extra for, and are slower to reach".

Regards,
Jordi
 
 

-----Mensaje original-----
De: ipv6 <ipv6-bounces@ietf.org> en nombre de Richard Patterson <richard@helix.net.nz>
Fecha: jueves, 14 de febrero de 2019, 11:41
Para: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
CC: 6man WG <ipv6@ietf.org>
Asunto: Re: A common problem with SLAAC in "renumbering" scenarios

    On Thu, 14 Feb 2019 at 10:22, JORDI PALET MARTINEZ
    <jordi.palet=40consulintel.es@dmarc.ietf.org> wrote:
    >
    > Why not? This is already happening in IPv4. I've got from a major operator in Spain (and other operators in other countries do the same), the same IPv4 address for decades! I'm talking about residential services, with both DSL and GPON. Not to mention business services were you actually pay for that static address a monthly fee.
    >
    > Any contract can have special clauses, that clearly indicate that "in case of major technology or network changes or similar events, renumbering can happen and in those situations the customers will be alerted with a minimum of 1 month" (this is just an example, I can think in many alternative wordings).
    
    
    If we're ignoring the network topology issues, then the next obvious
    issue is privacy and tracking.
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.