> 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).
Exatly. Isn't expecting things still working with misconfigurations a fantasy? Cheers, Xiaohong > > >>>> 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
