Re: Consensus call on adopting: <draft-gont-6man-stable-privacy-addresses-01>

Karl Auer <> Fri, 13 April 2012 00:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17EDF21F8638 for <>; Thu, 12 Apr 2012 17:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vQ0ijK04LW1D for <>; Thu, 12 Apr 2012 17:14:34 -0700 (PDT)
Received: from (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by (Postfix) with ESMTP id 05BC721F85D1 for <>; Thu, 12 Apr 2012 17:14:32 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMBACJvh0+WZX+7/2dsb2JhbAANNoVytyYBAQEEI0sbCxgqAgJXGbQCiw6QO4EYBKEoh3M
Received: from (HELO []) ([]) by with ESMTP; 13 Apr 2012 09:44:30 +0930
Subject: Re: Consensus call on adopting: <draft-gont-6man-stable-privacy-addresses-01>
From: Karl Auer <>
In-Reply-To: <>
References: <>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-9r76ynRjHdTUHGcSdXz4"
Date: Fri, 13 Apr 2012 10:14:28 +1000
Message-ID: <1334276068.3945.408.camel@karl>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
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: Fri, 13 Apr 2012 00:14:35 -0000

On Thu, 2012-04-12 at 14:28 -0700, Bob Hinden wrote:
> This is a consensus call on adopting:
>     Title     : A method for Generating Stable Privacy-Enhanced Addresses with
>                 IPv6 Stateless Address Autoconfiguration (SLAAC)
>     Author(s) : Fernando Gont
>     Filename  : draft-gont-6man-stable-privacy-addresses-01
>     Pages     : 15
>     Date      : 2012-12-31
> as a 6MAN working group document.  Please state your opinion, positive
> or negative, on the mailing list or to the chairs.


That said, I have some comments. My apologies if I have missed some
discussion where these were covered already:

1: I'm unsure about this bit:

    IPv6 implementations conforming to this specification
    MUST generate interface identifiers using the algorithm
    specified in this section.

While this does not explicitly *say* that other interface identifiers
MUST NOT be used, that interpretation seems to be possible. A hint that
stable addresses may be used alongside privacy addresses, is found in
the sentence:

    On the other hand, in scenarios in which "Privacy Extensions"
    are employed, implementation of the mechanism described in this
    document would [...]

Section five does mention replacing IEEE-based interface IDs, but I
think it needs to be stronger, one way or the other. The document should
make clear which other mechanisms it excludes, if any - for example,
that a host using this mechanism SHOULD NOT (MUST NOT?) also generate
interface IDs based on IEEE identifiers but MAY also use privacy
extensions. See also point 4 below.

2: What exactly is a "serial number"? Do all machines, even
small/embedded etc machines, have a serial number? Seems to me that the
algorithm should use a default value, such as zero, for the "serial
number" if none is available OR should fail to generate a secret key
(and thus fail to generate interface IDs later). My preference would be
for the first of these - i.e., a default.

3: Related to the previous point, if it is possible to fail to generate
a secret key, there needs to be a defined value for "secret key" that
indicates an invalid secret key - perhaps zero. If the secret key has
this value, the host MUST NOT autoconfigure a stable address.

4: Assuming point 1 above has relevance, and a host using this algorithm
MUST NOT also use IEEE-based interface IDs, then a host which fails to
generate a stable address for any reason MUST NOT fall back to the use
of IEEE-based interface IDs. Why? Because that would expose the host to
precisely the disadvantages that the stable addresses were supposed to

5: Duplicate address detection is not mentioned explicitly, but probably
should be - what happens if a host does DAD and determines that its
stable address is already in use?

6: The interface IDs generated are 64 bits long. I think it should be
stated explicitly that this algorithm MUST NOT be used where the prefix
is not 64 bits long.

7: Add "An implementation SHOULD provide the means for the user to
enable and disable the use of stable addresses."
8: This may be a bit out of scope, but it occurs to me that being able
to specify a static interface identifier and have it used in any
(64-bit) prefix would also be useful in some contexts. That is, have an
address which is stable, but explicitly specified.
Regards, K.

Karl Auer (

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