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. The rule concerning the u=1 can advantageously be completed with new uses (provided they don't conflict wit previous uses). Regards, RD > I have no problem with clarifying under-specified corner cases. > But why change the rule we have? Is there a problem with the current rule > that I am missing? > > Yours, > Joel > > On 2/2/2013 3:35 AM, Brian E Carpenter wrote: >> Joel, >> >> On 02/02/2013 00:41, 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. >> >> Correct. Semantically, it's a dead duck. That's already true, whatever >> words are written in RFCs - the fact that u=1 does not prove the IID >> comes from a MAC address with u=0, and vice versa. >> >>> 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 that doesn't mean that the IID was derived from a MAC address, >> so its value is limited. >> >>> The other alternative I can understand, although I do not favor it, is >>> to not allow the diagnostic at all. >> >> The alternative is what we have today: *assume* that an IID that looks >> as if it came from a MAC address in fact did so. >> >> Brian >> >>> >>> Yours, >>> Joel >>> >>> On 2/1/2013 3:13 PM, Fernando Gont wrote: >>> >>>> Section 3: >>>>> It should be noted that IIDs known or guessed to have been created >>>>> according to RFC 4941 could be transformed back into MAC addresses, >>>>> for example during fault diagnosis. For that reason, keeping the >>>>> "u" >>>>> and "g" bits in the IID has operational value. Therefore, the >>>>> EUI-64 >>>>> to IPv6 IID transformation defined in RFC 4941 MUST be used for all >>>>> cases where an IID is derived from a MAC address. >>>> >>>> How can you tell whether an IID was really derived from a MAC address, >>>> or you just had pretty bad luck with your IID randomization -- such tha >>>> it *looks* like derived form a mac address? >>>> >>>> Thanks! >>>> >>>> Cheers, >>>> >>> >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
