RE: Feedback on draft-gont-6man-stable-privacy-addresses-01

Christian Huitema <> Sat, 14 April 2012 23:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0FC8421F8572 for <>; Sat, 14 Apr 2012 16:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kmWMu8PRbXfX for <>; Sat, 14 Apr 2012 16:20:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 51CB121F856D for <>; Sat, 14 Apr 2012 16:20:06 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Sat, 14 Apr 2012 23:20:05 +0000
Received: from mail11-ch1 (localhost []) by (Postfix) with ESMTP id 1F0CD1401F6; Sat, 14 Apr 2012 23:20:05 +0000 (UTC)
X-SpamScore: -5
X-BigFish: VS-5(zz1503Mzz1202hzzz2fh2a8h668h839h944hd25h)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
Received-SPF: pass (mail11-ch1: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail11-ch1 (localhost.localdomain []) by mail11-ch1 (MessageSwitch) id 1334445604210828_27691; Sat, 14 Apr 2012 23:20:04 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTP id 259C9480045; Sat, 14 Apr 2012 23:20:04 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Sat, 14 Apr 2012 23:20:03 +0000
Received: from ([]) by ([]) with mapi id 14.02.0283.004; Sat, 14 Apr 2012 23:20:02 +0000
From: Christian Huitema <>
To: Fernando Gont <>, Fred Baker <>
Subject: RE: Feedback on draft-gont-6man-stable-privacy-addresses-01
Thread-Topic: Feedback on draft-gont-6man-stable-privacy-addresses-01
Thread-Index: AQHNGn3UDPx4Kw3MF0OxBylTRJLkeZaa55aA
Date: Sat, 14 Apr 2012 23:20:01 +0000
Message-ID: <>
References: <> <1334276068.3945.408.camel@karl> <> <1334363774.3945.541.camel@karl> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: " 6man" <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Apr 2012 23:20:07 -0000

I agree with Fred that we only need to specify "please somehow get a suitable 64 bit number."  There are a couple of requirements that have to be met -- or at least considered:

1) Uniqueness: the number must be unique within the scope of the subnet.
2) Non traceability: the number should be different for different subnet, so hosts cannot be readily traced as they move to different locations.
3) Privacy: the number should vary over time, to make it harder for Internet services to correlate sessions started by the same host.
4) Stability: the number should remain stable over time, so administrators can more easily manage which host is using what network service.

Of course, stability and privacy are contradictory, so there must be a way for arbitraging that. That's the big issue to be dealt with by the specification of privacy addresses, i.e. whatever successor we write for RFC 3484. The arbitration will be resolving about how often host generate addresses, how many addresses they generate, and under what circumstances do they use one or the other. Let's assume for now that we just want to generate addresses once per subnet.

In principle, there are two ways to meet the unique per subnet requirement: use a number that is guaranteed to be unique by design; or use a large random number that is unlikely to collide with an existing allocation. The problem of course is that random numbers will sometime collide. It may be a low probability event, but it will eventually happen. In fact, even the "unique by design" numbers like EUI64 can collide occasionally, if some management error occurred. That's why we do DAD. So, we have another requirement in the address allocation:

5) Retry: host must be able to detect potential collisions and retry, i.e. generate a different random number.

Fernando's algorithm has several advantages. It uses a hash of a pre-allocated random number, and thus mitigates the issue of weak random number generators in some hosts. It incorporates the subnet prefix, and thus meets the "non-traceability" requirement. But Fernando's algorithm has no provision for "retry", and thus misses a key requirement. So, instead of Fernando's specification, I suggest that we define the algorithm's input as:

   RID = F(Prefix, Modified_EUI64,  Network_ID, secret_key, salt) 

Where prefix , Modified_EUI64, network ID and secret key are defined as per Fernando's proposal, and "salt" is a long integer, typically set to the number of retries used to generate the 64 bit ID.

Of course, if we can support retries, we can also support privacy addresses -- the private address can be generated with just a gratuitous retry, a modified salt. In fact, with that formulation, we can be very close to the format defined in SEND (RFC 3972) -- just replace the "secret key" by the public key of the host. So we have a chance of unifying CGA, privacy addresses, and stable random addresses.

-- Christian Huitema