On 03/02/2013 10:57, Rémi Després wrote:
> Le 2013-02-02 à 18:17, Joel M. Halpern <[email protected]> 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. 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."
To say it again in different words, u==1 does not prove that an IID is
universally unique and u==0 does not prove that an IID is locally unique.
So it's fine to specify methods for generating the u bit, but it is
incorrect to draw firm conclusions based on its value.
Brian
>
> 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
>> [email protected]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
