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 (ka...@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
signature.asc
Description: This is a digitally signed message part
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
