Re: Comments on <draft-gont-6man-stable-privacy-addresses-01>

Karl Auer <kauer@biplane.com.au> Wed, 18 April 2012 00:58 UTC

Return-Path: <kauer@biplane.com.au>
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 BF5F211E80E5 for <ipv6@ietfa.amsl.com>; Tue, 17 Apr 2012 17:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
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 XZfeFi09oo0s for <ipv6@ietfa.amsl.com>; Tue, 17 Apr 2012 17:58:35 -0700 (PDT)
Received: from ipmail07.adl2.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id AC9F711E807F for <ipv6@ietf.org>; Tue, 17 Apr 2012 17:58:33 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMBAG8Rjk+WZX+7/2dsb2JhbAANN4VmrmgBAQEEI2YLGCoCAlcGE680kl+PS4EYBKEqh3Q
Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.205]) ([150.101.127.187]) by ipmail07.adl2.internode.on.net with ESMTP; 18 Apr 2012 10:28:31 +0930
Subject: Re: Comments on <draft-gont-6man-stable-privacy-addresses-01>
From: Karl Auer <kauer@biplane.com.au>
To: IETF IPv6 <ipv6@ietf.org>
In-Reply-To: <295BAD95-B636-4611-B735-4FA13AB0FAB9@gmail.com>
References: <295BAD95-B636-4611-B735-4FA13AB0FAB9@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-dvYf0JCuQXfex8p4QqS8"
Date: Wed, 18 Apr 2012 10:58:31 +1000
Message-ID: <1334710711.12533.128.camel@karl>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
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: Wed, 18 Apr 2012 00:58:39 -0000

On Tue, 2012-04-17 at 16:58 -0700, Bob Hinden wrote:
> Could these types of Interface Identifiers also be generated by DHCPv6
> servers.  I would think that it would be useful to generate these hard
> to predict IIDs when a DHCPv6 server is providing addresses.  This
> would be much better than assigning them linearly that are easy to
> predict and scan for.  

Some DHCPv6 servers may assign IPv6 addresses linearly. Industrial
strength DHCPv6 servers don't (eg Nominum DCS). Linear assignment in
DHCPv6 is IMHO basically a bug. If a DHCPv6 server assigns a random
address to a new client, then you have everything stable addresses give
you - it's not based on the hardware address, it's the same whenever you
are in the same network, it's different on different networks.

A DHCPv6 server that allocates addresses linearly would be better fixed
not to do so, than to go to the trouble of implementing stable addresses
a la Gont.

The DHCPv6 model is one where the client defers to the server. While a
client can request specific addresses, and so could request one it had
generated using the stable address algorithm, it would still be entirely
up to the server whether or not to honour that request.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687