On 04/22/2013 03:39 PM, SM wrote:
At 12:40 22-04-2013, Fernando Gont wrote:
PLease see the Appendix.
I read that. I was confused by the short title (Stable Privacy
Addresses) at first. I didn't see much discussion in the draft about
privacy considerations.
There's some discussion in the Intro and the Appendix.
For what it is worth there isn't much in RFC
4941 either. I am not sure whether it is worth covering that angle in
the draft; it may end up being too much work.
What (specifically) do you have in mind? Both RFC4941 and this document
note that if you use the underlying IEEE identifier for the IID, that
becoames a "super cookie" that allows correlations. Is the much more to
say on the subject than that?
Privacy addresses are employed in addition to traditional SLAAC
addresses -- hence they don't mitigate address scanning. FWIW, this is
all discussed in the I-D.
Yes, I read that. Privacy is a bit more than address scanning.
Agreed.
From an
implementation perspective the document is good. It is difficult to
tell how the document fits in the bigger (IPv6) picture.
For (auto-configured) stable addresses you have two choices:
* traditional slacc addresses
* draft-ietf-stable-privacy-addresses
It'd be "conditionally-compliant", but not fully-compliant.
It would be easier to say:
It is RECOMMENDED that implementations provide a configuration option to
enable or disable the use of this algorithm for generating Interface
Identifiers.
Can't "SHOULD" and "RECOMMENDED" be used interchangeably?
BTW, you could steal some text from RFC 4941 for the 64-bit comment:
"Note that an IPv6 identifier does not necessarily have to be 64 bits in
length, but the algorithm specified in this document is targeted towards
64-bit interface identifiers."
Well this is not that different from the current text -- still ties the
document to 64-bit IIDs.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492