Re: Why /64

Jeroen Massar <jeroen@massar.ch> Sun, 27 October 2013 16:10 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 247F311E8182 for <ipv6@ietfa.amsl.com>; Sun, 27 Oct 2013 09:10:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.143
X-Spam-Level:
X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315]
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 1VnaJ-cczFMb for <ipv6@ietfa.amsl.com>; Sun, 27 Oct 2013 09:10:13 -0700 (PDT)
Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE0D11E8293 for <ipv6@ietf.org>; Sun, 27 Oct 2013 09:10:10 -0700 (PDT)
Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (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 56F7E801C2A2; Sun, 27 Oct 2013 17:10:03 +0100 (CET)
Message-ID: <526D3AE2.2020300@massar.ch>
Date: Sun, 27 Oct 2013 17:10:10 +0100
From: Jeroen Massar <jeroen@massar.ch>
Organization: Massar
MIME-Version: 1.0
To: Lorenzo Colitti <lorenzo@google.com>
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> <526CE821.1000900@massar.ch> <CAKD1Yr138KfSo_g5mr-5r4-H8Fxrk0GUnDLy0nLHZr1z6PC_cg@mail.gmail.com>
In-Reply-To: <CAKD1Yr138KfSo_g5mr-5r4-H8Fxrk0GUnDLy0nLHZr1z6PC_cg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Sun, 27 Oct 2013 16:10:21 -0000

TLDR: /64 on a link is great, keep it; /48 or /56 standardized per site
is great for renumbering (at least the plan); IPv6 "privacy address" is
not really private anyway, thus bad to list as a reason for keeping /64.


On 2013-10-27 14:36, Lorenzo Colitti wrote:
> On Sun, Oct 27, 2013 at 7:17 PM, Jeroen Massar <jeroen@massar.ch
> <mailto:jeroen@massar.ch>> wrote:
> 
>     Cookies is just one of the many ways as per:
> 
>     http://panopticlick.eff.org/
> 
> 
> Ok, we shouldn't have gotten into this debate. I think that's worthless

The point that I am trying to make, but the one you do not want to hear,
is that "IPv6 privacy" does not exist, hence stating that it is a 'good
thing for having a /64 or /48' is just stating a muyth similar to
stating that "IPv6 is more secure than IPv4 as it has IPSEC" and other
such myths.

Thus, I'll nicely ask to stop making statements like that as they are
not true, and never have been. (though they look like it, and as
everybody keeps echoing them they sound like it, they are not)



If you want proper privacy then use Tor or similar systems.
(and lots of people debate if those keep you truly private...)

I'll give another few comments on your statements below, just to show
how easily they are debunked and thus how false they are.


That all said, /64's are great IMHO.

Though if there is a significant reason why people think the address
space is too small and they need to get rid of the 'barrier', then write
up a proper draft, spell out your reasoning and we can discuss that.

>From my POV there is enough space, there are just ISPs who are cutting
people short in how much they want to give out as they are stuck in
IPv4-think, which is logical in a way when they have dealt with a lot of
problems address squeeze or problems getting more space from a RIR. The
solution to these folks is education, not changes to a proper architecture.

Don't forget that one of the primary reasons for doing /48 at every site
was that it allows "easier" renumbering (at least one can keep the same
address plan ;)

As for networks that want to use shorter-than /64, they can. DHCPv6
allows this scenario. The IETF though should never be recommending any
of that and neither should the RIRs, who should actually IMHO enforce
that LIRs give out proper address space to users and not force users to
a single /128 when the ISP has more than enough space and can easily go
to the RIR to get more when they need it (though if an ISP has to return
for more they made a mistake in their initial allocation if it was only
made a few years ago...).

Greets,
 Jeroen

--

> (every one of tens of millions of iPhones will return the same result...
> ). But sure. There are other ways to track people than via IP addresses.

Just tested with my iPad2, which is just another IOS device:

"Your browser fingerprint appears to be unique amongst the 3.535.368
tested so far"

the primary reason apparently:
- User Agent, which included the exact User-Agent string
  not everybody is running IOS 7.0.3 yet = 18.95bits, 1/505052.57
- Browser Plugin Detail = 17.29 bits, 1/160698.55
  Not everybody has Bria and other Apps that allow IOS to accept
  certain media types.

Panopticlick wins again. That is HTTP indeed, but HTTP is what these
devices are being used for, not IP level so much. And if you make one
lousy connection outbound over HTTP that identifies you then that IP
address has compromised you. Unless (but that is hard to see) IOS cycles
the IPv6 address for every app; with very few apps doing IPv6 though
that is hard to test easily.

Also Google/Bing/Yahoo or whatever search engine you are allowed to use
for IDFA for some extra work there to make it possible to track you.
Though they claim you are anonymous, they track an identity which can be
extremely easily linked to a person with help of .

Next to that some apps just for 'fun' insert your mac address or other
identifying information into their requests.

Note that iPhones are predominantly HTTP users and thus have all the
problems and tracking features that come along with it. If you are all
behind a NAT it gets tricker, but nobody cares about IP level tracking,
the applications take care of that; people love logging in to social
networks.

Those 10m iphones also do not live behind the same IP address, or even
/48; though it is likely in a IPv6-environment that there will be a few
thousand in a single /48 indeed, that is, if the operator choses to
deploy them that way. It is often enough seen to deploy behind a
transparent proxy.

Still, statistics allow one to discern between them.

>     You probably mean the ISPs who require ND-proxy to get that /64 on your
>     side of the link? :)
> 
> 
> No, you're misinformed. I mean real DHCPv6 PD. See below.

I've not seen DHCPv6 PD live in action at any of these ISPs; I have seen
lots of people do NDproxy tricks though.

>     Amongst others: http://www.ipsidixit.net/2010/03/24/239/ one of many
>     articles on this for free.fr <http://free.fr> (the "largest IPv6
>     native deployment").
> 
> 
> Since forever Free.fr has been handing out /60 to all its customers

Hence why the above linked article exists and many other similar ones.

> (it's the maximum they can hand out with 6rd using their IPv6 allocation
> size), and sends an RA with a /64 by default. I believe that if you
> configure it they'll send out one different prefix for each port on the
> box. Look for them in your logs; I'm sure you'll still see some ff:fe in
> there, which probably means autoconf.




>     Liberty Global (Unity Media in Germany) is playing with DS-Lite, hence
>     you get 1 IPv6 address and a CGN IPv4 address (which is useless in
>     prime-time as those boxes cannot handle all the BitTorrent and other
>     heavy traffic flows).
> 
> 
> DS-lite is not limited to one IPv6 address. Where did you get that from?

While the protocol and the tools might not be limited to that, this is
how it is being deployed.

IPv6 (this whole thread :) is not limited to a single /128 either, but
this is how it is being deployed in the wide by various ISPs (cheap
hosters are a primary example, but there are also consumer ISPs, eg
Liberty Global mentioned above) who do.

> As for DS-Lite, well, you know, there's not a lot of IPv4 left.

There indeed is not; in this specific example they converted people who
had proper IPv4 connectivity to DSLITE and the former IPv4 addresses are
now used for the hosting offering of the ISP. The pain is thus being
diverted a bit.

> Nope, Comcast doesn't do that - neither in IPv4 nor in IPv6. Some
> European ISPs do. Where did you get your facts from?

I didn't say that Comcast did, note that I pointed out for them the
helpdesk article which describes, apparently stale, details about their
deployment.

> Please check your information before presenting it as facts in this sort
> of policy discussion. We really don't want to come to the wrong
> conclusion because we have the wrong data.

I fully agree, see above about your iphones statement where you provide
no facts but all statements.

Note that I am pointing out documentation that is available. That these
authoritative sources are out of date not much I can do about.

Greets,
 Jeroen