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

Jan Zorz - Go6 <jan@go6.si> Thu, 14 February 2019 11:48 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 0BE23131166 for <ipv6@ietfa.amsl.com>; Thu, 14 Feb 2019 03:48:03 -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 iWACLhK0rhZz for <ipv6@ietfa.amsl.com>; Thu, 14 Feb 2019 03:48:00 -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 68D32131163 for <ipv6@ietf.org>; Thu, 14 Feb 2019 03:48:00 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id DFAD8660C4 for <ipv6@ietf.org>; Thu, 14 Feb 2019 12:47:56 +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 ngq6UmadRYso for <ipv6@ietf.org>; Thu, 14 Feb 2019 12:47:55 +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 8F07965E78 for <ipv6@ietf.org>; Thu, 14 Feb 2019 12:47:55 +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 00967805A2 for <ipv6@ietf.org>; Thu, 14 Feb 2019 12:47:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1550144875; bh=GNYFVcK/a19AqUydhsV7ZFHOi+G4C/faTg23AvoRYhI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=jVsNceShMELzKPb6Msx9jv2IFw4UAiOofjY0VwYRXya5k2E184wT2QwA+uri6/yKh jr0zY0tcQsbblF057bo9Z3ODHaj2Nwy/md5dz0mmPueE0J7xqWeZK75UEzAZfZjm+q GfPDeir69oreoOdLytL+ekgFK14n3eAl56zfMJFE=
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: ipv6@ietf.org
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <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> <65DB4854-97D2-4C31-A691-2CD93812EF93@consulintel.es> <CAHL_VyCMpCcGkEQu+RV1GRf2QLB-HD0+AOOBV0YhfQ5sbydVzQ@mail.gmail.com>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <1e31ec6a-a743-3034-51e4-19d88e379475@go6.si>
Date: Thu, 14 Feb 2019 12:47:53 +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: <CAHL_VyCMpCcGkEQu+RV1GRf2QLB-HD0+AOOBV0YhfQ5sbydVzQ@mail.gmail.com>
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/dQiVhzREIfx1xbNNpUhnXzZ17o8>
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 11:48:03 -0000

On 14/02/2019 12:38, Richard Patterson wrote:
> On Thu, 14 Feb 2019 at 10:51, JORDI PALET MARTINEZ
> <jordi.palet@consulintel.es> wrote:
>>
>> 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.
> 
> I agree that there are better ways, but IP addresses are still
> considered personal data from a GDPR perspective, and courts also
> generally agree that they are sufficient from a copyright infringement
> enforcement perspective.

Hmm... does that mean that also every enterprise network with staff 
accessing the Internet from their network should have dynamic prefixes 
and change all the time? I don't think that network people at all those 
companies would agree. It's similar to saying that your house number and 
street name are private information and needs to change every day. Or 
car registration plate number.... every time you start your car - your 
registration plate number must change, otherwise people can track you 
around your town as they know your registration number.

There has to be a limit somewhere in how much insanity someone would 
implement.

GDPR folx needs to understand that IPv6 was just not made for what they 
wish for and with irrational requests they are breaking it. What I 
suspect is that problem in this case is lack of technical understanding 
of privacy/GDPR folx how IPv6 works in reality and what the current 
limitations are. I've been telling them this for years now, but 
apparently not successfully enough :( Maybe someone else can also try ;)

Cheers, Jan