Remi, >>>> 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).
that's a property that was highly speculative 15 years ago when it was specified and a property that has never been verified. but, let me turn the question around. what are the requirements for a globally unique interface-id? how is it going to be used? both for encapsulation and translation? is it expected that routers have to make forwarding decisions on an interface-id? cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
