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

Brian E Carpenter <> Sat, 14 April 2012 14:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEDEB21F8630 for <>; Sat, 14 Apr 2012 07:56:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.514
X-Spam-Status: No, score=-100.514 tagged_above=-999 required=5 tests=[AWL=-1.123, BAYES_00=-2.599, MANGLED_BELOW=2.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XF6WGS-uB7tc for <>; Sat, 14 Apr 2012 07:56:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 44C4B21F861B for <>; Sat, 14 Apr 2012 07:56:36 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so2677109wgb.13 for <>; Sat, 14 Apr 2012 07:56:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZiNJO/j/vQMg5AhOdE+rON8+ZZeiyREW/vmVayoHBEM=; b=YJ50Y3XV5eWdkAcdHRp6+Wj52OuK9Anj5HRTUFCW3kCpe3DjXbn0uOSuoSJvhlL6w/ 7++IBO21Z643V4Xt0sW/q1lb+hX6EP5cmxl1EI9do8nSuxtKcqFWw7kr8Z/ghJUyE/ph gNbFh1/26ZqNfRy3fH1ikl60LlhPctuN0h+we0g3ayMIFwBzaP9S4HCF8+rmUXKH3yD5 wLYE7CnzXtVouS+ImOi9J8oOdKKc7WrYgH5cd2pGVclgvw5FxRsF/Q0FUXyVb6lbrd4L MSJ+a8dbHLVUVJlYPRAHg0UKzN5T3M0gDSmJN4yXyFCR4QHJ53GW+S5tsM2D3W4CIXC9 PP2g==
Received: by with SMTP id o72mr3011381wei.95.1334415395446; Sat, 14 Apr 2012 07:56:35 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id fn2sm8208189wib.0.2012. (version=SSLv3 cipher=OTHER); Sat, 14 Apr 2012 07:56:34 -0700 (PDT)
Message-ID: <>
Date: Sat, 14 Apr 2012 15:56:31 +0100
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Fernando Gont <>
Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01
References: <> <1334276068.3945.408.camel@karl> <> <1334363774.3945.541.camel@karl> <> <EMEW3|289e913e0066f2de615a1e1b85762bcbo3DBUc03tjc||> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Tim Chown <>, 6man Mailing List <>
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 14:56:37 -0000

On 2012-04-14 15:09, Fernando Gont wrote:
> On 04/14/2012 12:30 PM, Tim Chown wrote:
>> I while ago I put this one forward, which is an alternative to
>> Fernando's suggestion that you have to set the whole address:
>>  This was based on existing implementations, in Solaris and Linux (as
>> a demonstrator), with the potential for simpler renumbering in mind.
> Does this really help renumbering? e.g., if you have ACLs, they are
> based on the whole IPv6 address, rather than on the IID...

This is linked to the whole question of why people assign static
addresses and how that interacts with renumbering. By getting rid
of the MAC address (so that the server address doesn't depend on
the network interface hardware) you are part way to static addresses,
and one can imagine a prefix-renumbering mechanism that could handle
this. Of course here we want an IID that is not only stable but is
also well-known; servers don't get address privacy ;-).

Fully static addresses are a pain in renumbering, but that
discussion belongs in 6RENUM (draft-carpenter-6renum-static-problem).



>> It's probably the complete antithesis of what Fernando is trying to
>> achieve, but is aimed at the type of (server) systems that would
>> probably be DNS-advertised anyway.
> Note that having an address advertised in the DNS does not necessarily
> means that predictable addresses are not useful to an attacker.
> For example, let's assume that you know that a network link hosts 100
> different servers, each with a different domain.
> If their addresses are not predictable, and the attacker wants to find
> all of them, he may have to rely on a "dictionary" attack. However, if
> the addresses *are* predictable, he could just sweep the interested part
> of the address space.
> Note: I still don't understand the use case for this technology, or how
> the IIDs would be selected (but since they seem to be
> manually-generated, I'd expect them to be "low-byte", such as ::1, ::2,
> etc.).
> Thanks!
> Best regards,