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

Mark Smith <> Wed, 29 July 2015 01:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B968A1B34B7 for <>; Tue, 28 Jul 2015 18:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4gEN0jz3Ht1k for <>; Tue, 28 Jul 2015 18:44:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70A751B3364 for <>; Tue, 28 Jul 2015 18:44:38 -0700 (PDT)
Received: by ioii16 with SMTP id i16so6479451ioi.0 for <>; Tue, 28 Jul 2015 18:44:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=021Up6XNaItYgo7dRg/r1n/YT12F1krY9707KGbnxMo=; b=gIYLmjLu5AFQ1BZMuCmihm+MLAYJH0pyjAq4E2JxpBJLkR2bpIkuJWghKn+7DVxUrC Npm1MF+U3+FVo78QpXARv4XzlDVEKf0R+2JVYznkrCHbFpuecCQmbK6eOp1kIe2hPxPt CEd0HSo6sz9xlQw1JA6e15N+5DHDUZQzZJKVVeS3JQ6BLAmFLsCnBP+qDzdfzIfDywty 0vnJF0SbSSQrGHSkYxwdajMAQ/rkLi7Dsr28oTdAAzmqNKMtHJyuq13nmLbUmRurKHzs RqC6UY1lVnzdDYgfMbyDtVvpn5x8V+J98eZF0lPrv24amFyUX/n5wi0H/p/QT9mImM0v 2dkQ==
X-Received: by with SMTP id a28mr64241368ioj.106.1438134277857; Tue, 28 Jul 2015 18:44:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Jul 2015 18:44:08 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <20150727091241.GL84167@Space.Net> <> <> <> <20150728115944.GZ84167@Space.Net> <> <>
From: Mark Smith <>
Date: Wed, 29 Jul 2015 11:44:08 +1000
Message-ID: <>
To: Ted Lemon <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: IPv6 Operations <>
Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-01.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Jul 2015 01:44:39 -0000

Hi Ted,

On 29 July 2015 at 00:27, Ted Lemon <> wrote:
> 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.

I think to avoid recommendations like this IPv6 setup for containers,
e.g. specifying to use Neighbor Discovery Proxying and /80 prefix

(As a side note, some discussion in the ID about whether containers
should be treated as hosts, and whether containers should then be
assigned /64s might be useful. I think an argument could be made that
containers are hosts, however given how light weight they are, and
therefore how many people might have, a /64 for each one might be