Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-01.txt

Ted Lemon <ted.lemon@nominum.com> Tue, 28 July 2015 14:27 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A67F1ABB1A for <v6ops@ietfa.amsl.com>; Tue, 28 Jul 2015 07:27:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 6qzd1oIHhgtD for <v6ops@ietfa.amsl.com>; Tue, 28 Jul 2015 07:27:24 -0700 (PDT)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 6397B1A6F30 for <v6ops@ietf.org>; Tue, 28 Jul 2015 07:27:24 -0700 (PDT)
Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 33B8BDA008A for <v6ops@ietf.org>; Tue, 28 Jul 2015 14:27:24 +0000 (UTC)
Received: from [10.0.20.178] (71.233.41.235) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 28 Jul 2015 07:27:23 -0700
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <CAPi140PKh64L=nr96pv3dn7FO_Y9pW162YzBT8kZHSMsedGYtQ@mail.gmail.com>
Date: Tue, 28 Jul 2015 10:27:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <BE811683-3BBA-40F0-B047-282DA7E774AA@nominum.com>
References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <m1ZIZ4w-0000CbC@stereo.hq.phicoh.net> <CAKD1Yr2z6T86gmQMPZwbgFB4mdt7=xWNuei5jaQg=vpG7-zLVg@mail.gmail.com> <m1ZJdjZ-0000CcC@stereo.hq.phicoh.net> <20150727091241.GL84167@Space.Net> <m1ZJfOr-0000CgC@stereo.hq.phicoh.net> <C9C3FBC4-44F3-45D2-B8C4-3725396E5D40@nominum.com> <CAPi140Mx96dBgeaCkrsDD+-J85OZDo5Di+gHTBiaGDzYK2us4w@mail.gmail.com> <20150728115944.GZ84167@Space.Net> <CAPi140PKh64L=nr96pv3dn7FO_Y9pW162YzBT8kZHSMsedGYtQ@mail.gmail.com>
To: IPv6 Operations <v6ops@ietf.org>
X-Mailer: Apple Mail (2.2102)
X-Originating-IP: [71.233.41.235]
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/eXzVhiePX6Dm9F7vp0tdf2IYbc0>
Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-01.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2015 14:27:25 -0000

Having read the document, it seems a bit pie in the sky.   The idea that subdividing a prefix will give users privacy is nonsensical: if it is well known that ISP X provides a /48 to every home, then people will assume that all hosts in any given /48 in that ISP’s allocation will belong to the same person or same household.

Given that, then if there is some performance reason for clustering multiple address assignments to the same host, the way to do it is to delegate a /120 to that host, and have a route to that /120 that points to that host.   If the host needs more than 256 addresses, delegate something bigger, or delegate multiple /120s.

This is really easy to do.   It doesn’t give you a ton of privacy, but I don’t think it gives you less privacy than delegating a /64, and in some sense it gives you more because now you can do multiple allocations and still get the efficiency of address clustering, and the snooper doesn’t have as much information about address allocation patterns.

And if you don’t want to do DHCPv6-PD, then SLAAC is actually ideal for this application, because you can in principle use a random number generator to produce the host part of the address, and just generate a bunch of random numbers with entropy so that a snooper can’t predict which addresses will be held in common by the same host.

But I still really don’t see the point of this.