On 01/29/2013 10:18 AM, Ole Troan wrote: > [...] >>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of >>> IIDs having u=g=1 is reserved. This leaves plenty of space for future >>> uses of IIDs having u=1, as explicitly expected in RFC 4291. >> >> That goes to the argument of (d), that it isn't harmful to assign >> some space to 4rd. > > I still think we need to answer the question Brian raised. > should the interface-id have any encoded meaning?
The only point having an encoding meaning is that, *in theory*, if you have a Universal/Local bit, and you have a source of universal identifiers, then you could tell beforehand that you're not going to have address collisions. However, * Practice indicates that "universal" identifiers are reused (virtualization software being just one example). And when you find a collision, you still need some other scheme to generate the IIDs (or else, how are you going to solve the DAD failure). * You'd need some coordination to separate the different namespaces (that's why we stuff the fffe for IEEE Identifiers, right?) * We must implement slaac anyway, so.. who cares about the aforementioned uniqueness? * Those universal identifiers bring patters, which are undesirable (see e.g. draft-ietf-opsec-ipv6-host-scanning). For the stable addresses, what we should be doing is replace the IEEE-derived scheme with draft-ietf-6man-stable-privacy-addresses, and be done with it. (probably eminating that of clearing the U bit in the IID, though). Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
