Hi Andrew, Thanks for your comments. >Of three problems that the draft aims to solve, 1st (EUI64 addresses) does not >really seem to be much of a problem as everyone does privacy addresses today >(you saw stats yourself at >ipv6-hackers meeting), the second (not changing >the address) is an implementation choice, so the third one remains as an open >problem, sort of.
It has problem because there are some deficiencies with that RFC. This is the main reason that I wanted to address those problems. The statistics about Privacy Addresses was more related to the problem that RFC 4941 makes by generating a public address based on EUI-64. So, it also responds to request to that as well as using temporary addresses. This means there is no privacy. So, this update is to that section of the RFC to ignore the step in order to use other approach to generate public addresses, i.e., stable addresses. >Now: what's the comparison between the amount of nonvolatile storage taken by >code implementing the algorithm vs code to store IIDs ? It is wording issue and can be interpreted to store all IIDs in a stable storage. The update might not make any problem to the current implementations if they did it correctly but would be consider for any new implementation of this RFC not to store more than the currently assigned IIDs to the network interfaces. >P.s. I agree with what Fernando wrote as well. As I explained to Fernando, I just named it like that but it does not mean that I used CGA algorithm as it is different inputs by executing a hash function on them and the purpose is not like CGA to find a binding between the IP address and the public key. This means the IPR of CGA is not considered for this algorithm. Thanks, Best, Hosnieh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
