On 02/02/2013 17:17, Joel M. Halpern wrote: > 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.
Actually, you don't. You know that it looks as if it was made in Modified EUI-64 format, but you don't know that there is a genuine MAC address behind it. You can apply heuristics (like "Is 0xFFFE present?" and "Is the OUI an IEEE-assigned value?") but that's all. Also, u==0 does not imply that it is not Modified EUI-64. The examples in RFC 4291 all use EUI-64 with u==0, i.e. Modified EUI-64 with u==1, but those are only examples. In the end all you have is 64 meaningless bits, as far as I can tell. Brian > 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. > > Aside from anything else, I do not see a motivation for changing the rule. > 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 [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
