Hi, Tassos, Thanks so much for your comments. Please find my responses inline....
On 03/28/2012 09:26 PM, Tassos Chatzithomaoglou wrote: > I like & support the idea, but it's not clear to me the > randomness/stableness of the created identifiers. > > Is there a guarantee, that after rebooting or powering-off/on the host, > the produced RID will remain the same if Prefix remains the same? Well, yes: As long as all the values you use for computing the hash are the same, the resulting Interface-ID will be the same. > Is there a way to change the secret key in case someone discovers it or > for whatever reason? If you change the key, the interface ID changes. That's implicit, since the hash function is expected to be cryptographically secure. (and one would argue that this is also desired, since once the key has been compromised, an attacker could use it to predict the Interface-ID that you'd use in other networks). > I would like more examples (and probably a better definition) of the > network_id. i.e. the SSID is something that is not exactly local to the > host. Are all the usage cases like this? i.e. in case of fixed network, > would it be the directly attached router's mac? The "Network_ID" is anything that would let you differentiate from one network to another, even if the same SLAAC prefix is being advertised. For example, you're connecting to a number of wifi networks, and the router advertises the same ULA prefix, including the SSID would result in different interface identifiers. In principle, the same thing would be true for link-local addresses: you could use some sort of Network_ID when generating the Interface-ID for link-local addresses, such that the address changes when you move from one network to another. (This is useful since sometimes this link-local addresses may leak out). > Extra question/idea.. > If this address creation functionality can be transferred to a dhcp > server too (which i don't see why not, since the critical input fields > are already there), maybe the text regarding SLAAC should be replaced > with something more appropriate. Or just add a note regarding this extra > option (someone mentioned about a dhcp server creating temporary > addresses). It could be transferred. So this is a good point. -- I will try to address this in the next rev of the document. > Finally, I would prefer to keep the prefix as mandatory to the algorithm > for the exact reason that you wrote. I fully agree with you, and think it would be a bad idea to remove the prefix from the hash. Some folks have argued against including the prefix, and hence I just want to hear comments from others. > PS: should there be any paragraph about the source address selection > (rfc3484/bis) RFCs and these stable privacy addresses and how they > should be handled, especially in comparison to the temporary ones? Not sure what you mean.... Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
