>It *is* solved by DHCP, but not by RFC4941: RFC4941 addresses are >generated *in addition* to SLAAC addresses. That's why, I'm told, >Windows replaces traditional SLAAC addresses with a time-invariant >version of RFC4941 - besides *additionally* implementing RFC4941 for >temporary addresses.
>Here we're mitigating address-scanning attacks, while bringing other >benefits such as privacy, by removing IIDs that are constant across >networks. The node is still vulnerable to privacy attacks when you have an IID lifetime for the IP address as explained in your draft. Why offer a partial solution to the problem with the implementation of two RFCs?! What needs to be done is write one RFCs to address both issues. This can be done by more generalizing the solution instead of focusing on a small group of people who thinks having the same IID in the same network and changing it just among two networks would solve the privacy problem. It is not really true. As I wrote in the last email, standards documents should pertain to general issues. With respect to your draft, the only general issue that is addressed is that of the IID generation algorithm. Whether or not an IID in a network is fixed or not is a network policy issue and not a standards issue. A standard might suggest that the time frame for the use of an IID should be kept short but nothing more. If more management is needed in the generation of the IID then other approaches can be used other that neighbor discovery. Again, there are thousands of RFCs that have never been implemented or used because they do not focus on general solutions. The lifetime of the IP address should be left to the discretion of the users and not the standard except for explaining the potential dangers inherent in using longer time periods. In the standard, you just need to explain how the implementation should provide a way to use a parameter containing the lifetime. So then the implementation could obtain this value during the installation of this feature. This will generalize the solution and will give a possible way of changing the lifetime based on the network policy so that the whole draft does not focus on something that does not really solve the privacy issue. Hosnieh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
