Le 30 sept. 2011 à 01:58, Ole Troan a écrit : >>> in the general case there is no way to guarantee that a host doesn't pick >>> the same IID. >> >> Well, "no guarantee"... unless a safe way of doing it is specified! >> And this is already the case with 4rd-addmapping-01. >> (If you would keep doubts after a careful check, please share your >> understanding.) >> >> The modified format discussed in Beijing with Xing Li, Congxiao Bao, and >> Wojciech Dec, to be documented soon, will have the same property. > > there are no guarantees, and no safe way of doing that. > there is no enforcement of global uniqueness of interface ids. > e.g. the use of longer than /64 prefixes, manual configuration. > you have a high probability of it being unique. and as long as it is only > used for pretty printing and troubleshooting, then do you care?
Still, the Modified EUI-64 format of RFC 4291 has been designed to ensure unicity of these Universal-scope IIDs. True, a user can manually configure an EUI-64 IID that he shouldn't. The confusion that results is then his responsibility. The same applies if a host behind a 4rd CE configures a 4rd IID: it won't be reachable from the Internet. Possibility of misconfiguration MUST NOT be a reason to give up specifying formats that work in absence of misconfigurations (as done with the modified EUI-64 format of RFC 4291). >>> and we'll have to specify how this would work with DAD and proxy ND. I'd >>> rather not. >> >>> left up to the implementor is my suggestion... >> >> No need for that (see above). Confirmed because of the above. Cheers, RD > > cheers, > Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
