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

[Karl Auer <[e-mail]>]

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.

Positive.

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
prevent.

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 ([e-mail])
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