Brian, Bob,
2013-02-03 12:43, Brian E Carpenter <brian.e.carpen...@gmail.com> : > On 03/02/2013 10:57, Rémi Després wrote: >> Le 2013-02-02 à 18:17, Joel M. Halpern <j...@joelhalpern.com> a écrit : >> >>> I a not clear what aspect of the semantics of u==1 and the relationship to >>> EUI-64 is a dead duck. Currently, if you see something with u==1, you know >>> it was made from an EUI-64. Under your proposal, you would not know that. >>> Yous tae below tat the presence of ==1 doesn't mean that. to the best of >>> my knowledge, currently, it does mean that. It may not be derived from the >>> EUI-64 of the interface yo want to reach, but it is derived from an EUI-64. >>> Otherwise, u would be set to 0. >>> >>> You are proposing to change this rule. >> >> Same understanding. >> u=1 has a meaning that shouldn't be negated now. >> >>> Aside from anything else, I do not see a motivation for changing the rule. > > Actually, I don't think that is what the draft proposes. What it proposes > is that we delete > the fiction that the bit has any meaning after it arrives > in an IID. Serious disagreement with the extreme view that, today, the u bit has no meaning. See (*) and (**) below. > It seems to be that fiction that causes confusion, not the > rule about how to generate Modified EUI-64 format from a MAC address. > > Quoting a wise colleague, "magic bits are almost never worth the pain." Agreed. But the u bit isn't "magic". It is just a bit whose function has been specified (and used, see (*) below). > To say it again in different words, u==1 does not prove that an IID is > universally unique Agreed. (*) It remains that IIDs having u=1 SHOULD be unique, i.e. with rare enough exceptions. This is somewhat similar to the expectation that ULA collisions shouldn't be seen). This theoretical unicity has been extensively used to assign stable IIDs, without administrative action, to hosts that have no privacy constraints requiring the opposite. If our understanding differs on this, I suppose we should go further into it. > and u==0 does not prove that an IID is locally unique. Agreed. > So it's fine to specify methods for generating the u bit, but it is > incorrect to draw firm conclusions based on its value. Disagreed. Here is one "firm" conclusion, and a useful one AFAIK to "allow development of future technology that can take advantage of interface identifiers with universal scope": (**) "All IIDs that comply with RFC 4291, that have u=1, and that are based on an IEEE MAC address, also have g=0 and bits 24-39 = 0xFE." Disagreeing on this would need an explanation. Conclusion: your ug draft, which is IMHO welcome to clarify what seems misunderstood, must be clear about issue (*) and (**) above, one way or another. Steps backward without carefully checked justifications should be avoided. Regards, RD -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
