Re: Why /64

Jeroen Massar <jeroen@massar.ch> Mon, 28 October 2013 17:06 UTC

Return-Path: <jeroen@massar.ch>
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 C35AD11E8286 for <ipv6@ietfa.amsl.com>; Mon, 28 Oct 2013 10:06:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5dOFedDtj2w for <ipv6@ietfa.amsl.com>; Mon, 28 Oct 2013 10:06:34 -0700 (PDT)
Received: from icaras.de.unfix.org (icaras.de.unfix.org [78.47.209.234]) by ietfa.amsl.com (Postfix) with ESMTP id E5CD211E8260 for <ipv6@ietf.org>; Mon, 28 Oct 2013 10:06:11 -0700 (PDT)
Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 9C569801C2A2; Mon, 28 Oct 2013 18:06:01 +0100 (CET)
Message-ID: <526E995D.1000502@massar.ch>
Date: Mon, 28 Oct 2013 18:05:33 +0100
From: Jeroen Massar <jeroen@massar.ch>
Organization: Massar Networking
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Octavio Alvarez <alvarezp@alvarezp.ods.org>
Subject: Re: Why /64
References: <20131021224346.32495.64932.idtracker@ietfa.amsl.com> <52695DDE.70909@gont.com.ar> <526AA24F.6010609@gmail.com> <526AACA5.7090604@si6networks.com> <E0F0D3DE-D31B-4CC2-9384-DFEBCCB8F557@ecs.soton.ac.uk> <EMEW3|9f43bef2fe7433173858819bd0eeee2dp9OKUJ03tjc|ecs.soton.ac.uk|E0F0D3DE-D31B-4CC2-9384-DFEBCCB8F557@ecs.soton.ac.uk> <526AC8AF.4060608@si6networks.com> <8C48B86A895913448548E6D15DA7553BA7B978@xmb-rcd-x09.cisco.com> <CAKD1Yr0q2dY041CMarFfTZZx6=qHC-eJ+74qgiHP-dt7+ga7yg@mail.gmail.com> <526CDC59.4070204@massar.ch> <CAKD1Yr0_anudWNpWRkvMGvD_pvyEscnuqEsPUy4YNm3e9Hue9g@mail.gmail.com> <CAPv4CP9k_J2GCOFhTCBz3U-nQmCWSjc4nceexaWwYZ-nDMpJmw@mail.gmail.com> <CAKFn1SG1PC_kA-pO5Or8VyeaOzvLfpmQe0LiiYkXU_HzNqGzCQ@mail.gmail.com> <526E250E.5050607@massar.ch> <526E9517.1090207@alvarezp.ods.org>
In-Reply-To: <526E9517.1090207@alvarezp.ods.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Cc: "<ipv6@ietf.org>" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 28 Oct 2013 17:06:52 -0000

On 2013-10-28 17:47 , Octavio Alvarez wrote:
> On 10/28/2013 01:49 AM, Jeroen Massar wrote:
>> On 2013-10-27 15:50, Roger Jørgensen wrote:
>> [..]
>>> Privacy isn't just one single thing. That the user might lose privacy
>>> elsewhere in the entire stack that make up Internet, that's NOT an
>>> argument to give up /64 because we have lost privacy anyhow.
>>
>> I am NOT arguing that a /64 should go the way of the dodo.
>> I am only stating that this "IPv6 Privacy Address" thing is a myth.
> 
> Which is also inaccurate, as the purpose is not to provide privacy, but
> just to prevent anti-privacy through the IPv6 address.

Please explain this "anti-privacy" concept.

> It's difficult to choose the right words for this.

You mean that it is difficult to justify randomizing bits as it does not
solve the problem at hand: you can and will be tracked.

>From the intro of RFC4941:
----
   Changing the interface
   identifier (and the global scope addresses generated from it) over
   time makes it more difficult for eavesdroppers and other information
   collectors to identify when different addresses used in different
   transactions actually correspond to the same node."
----

As it states 'more difficult'. Since 2001 (RFC3041 which has the same
wording and intent) this kind of tracking tech and the compute power has
advanced enough though that the difficulty is futile.

Greets,
 Jeroen