On 02/01/2013 09:41 PM, Joel M. Halpern wrote: > With regard to section 3, I would ask the question in the reverse. > (which may actually be the same quewstion Fernando is asking.) > > If we assume that there is value in being able to perform the diagnostic > operation described, then it seems that one needs to be able to tell > when it can be applied. > Currently, that is u==1 in the IID field. > The text says that u==1 must be used n the IID field for IIDs derived > from EUI-64. > But it the goes on to say that u=1 can be used by other addresses. > If u=1 can be used by addresses not derived from EUI-64, then the > diagnostic operation can not be applied without a-priori knowledge. > And in the presence of such knowledge, the u bit does not seem to help. > > The obvious answer is that to enable the diagnostic, and because there > is no need to make a gratuitous change, we stick with u=1 being used > always and only for addresses derived from EUI-64.
But if we enforce u=1 only for IIDS based on EUI-64, there might be other IIDs generated with some other mechanism, that lead to IIDs with such bit set to 1. Unless u=1 is enforced for all identifiers, chances are that eventually some other technology will generate an IID with u==1, and one would mistakenly assume that such IID was based on IEEE identifiers... (yes, in order for such "collisions" to occur, u would have to be 1, and the other technology would also have to produce the 0xfffe we currently insert to generate the Modified EUI64 identifiers... but "s* happens", they say...) 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 --------------------------------------------------------------------
