Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At 06:34 22-04-2013, RJ Atkinson wrote:
It would reduce consensus within the WG and the IETF as a whole
to remove that text -- as it clarifies that other mechanisms for
generating such IDs are not affected by this specification.

The document shepherd write-up mentioned that there is "Nothing in particular" to report about the working group discussions. There were two WG participants discussing about draft-ietf-6man-stable-privacy-addresses during the WGLC (excluding the listed author and the WG Chairs).

I'll comment on the draft.  The document is well-written.

From Section 1:

  'The "Privacy Extensions for Stateless Address Autoconfiguration in
   IPv6" [RFC4941] were introduced to complicate the task of
   eavesdroppers and other information collectors to correlate the
   activities of a node, and basically result in temporary (and random)
   Interface Identifiers that are typically more difficult to leverage
   than those based on IEEE identifiers.'

There are some warnings in RFC 4941 about correlation. I don't see any notes about that in this draft. My reading of this proposal is that it is to mitigate address scanning. I could not find any guidance on whether to use RFC 4941 or this draft for "privacy addresses".

From Section 3:

  "The aforementioned algorithm MUST be employed for generating
   the interface identifiers for all of the IPv6 addresses
   configured with SLAAC for a given interface, including IPv6
   link-local addresses."

The requirement is repeated in the note:

  "This means that this document does not formally obsolete or
   deprecate any of the existing algorithms to generate Interface IDs
   (e.g. such as that specified in [RFC2464]).  However, those IPv6
   implementations that employ this specification must generate all
   of their "stable" addresses as specified in this document."

I read that as meaning that this document informally obsoletes or deprecates some of the existing algorithms but it's better not to say it formally as it would be controversial.

  "Implementations conforming to this specification SHOULD provide the
   means for a system administrator to enable or disable the use of this
   algorithm for generating Interface Identifiers."

If the implementation does not provide the means for the administrator to enable or disable the use of the algorithm, does it conform to this specification?

Regards,
-sm






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]