On 02/03/2013 10:55 AM, Ray Hunter wrote: > What "uniqueness" is strictly required for correct operation of IPv6? > If the competing technologies can never share an L2 link, what's the > problem? > > IMVHO We should be careful what semantics we import from other standards > bodies, and only do this explicitly. > > Looking at various alternatives for the semantics of IETF defined flags: > > u = deprecated. EUI64 MAY be used in generation of IIDs. DAD SHOULD be > performed for all unicast addresses. > A distinct possibility in my book. Reasoning: IIDs are only tie breakers > per link. Collisions happen. Deal with it.
We currently do not deal with them. With start with the (fictional) assumption that we can get unique addresses if we based our IIDs on (allegedly) unique MAC addresses. But e.g. virtualization software can generate duplicate mac addresses. And in the presence of such failures, SLAAC/DAD fails (in some implementations, when DAD fails for link-local address, you need to reboot) > u==1 => derived from one (of potentially many) mapping schemes based on > a universal token, and therefore nodes MAY skip performing DAD on all > link types. > Also seems reasonable. Some might even think useful. Reality indicates that even when deemed as "unique", those tokens are not really universal. So if you skip that, you might end up in a slaac failure. Therefore, in practice you cannot really skip that. And if DAD fails, you must have some algorithm in place to solve the problem. Most likely, such algorithm is going to generate some random ID of some sort... in which case we should probably ask ourselves: why are we generating the addresses with an embedded IEEE identifier for the first try, and with a completely different scheme if DAD fails? > u==1 && g==0 => IEEE EUI64 with IEEE registered OUI on all link technology > Is probably too much (and unnecessary for correct functioning of IPv6 AFAIK) > Do we really want to tell everyone who wants to produce links that > supports IPv6 that they should obtain an OUI from the IEEE, or force > them to use u=0 when generating addresses? What value does this > restriction add for the IETF? Agreed. > u == 1 && g==0 => IEEE EUI64 with IEEE registered OUI, but only for IPv6 > unicast addresses and only on IEEE-defined link technology. > Would be fine by me, and current practice AFAIK But... is there any value in continuing with this? Cheers, -- 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 --------------------------------------------------------------------
