On 02/02/2013 13:26, Brian Haberman wrote:
> On 2/1/13 7:56 PM, Fernando Gont wrote:
>> 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.
> 
> And to state the obvious, that implies that u==g==1 means we are looking
> at an identifier derived from a hardware-based identifier (e.g., IEEE).

Yes, even if it make no sense.

Or of course that we are looking at an arbitrarily invented IID that means
nothing in particular. Who's to say?

    Brian
> 
>>
>> 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...)
> 
> The assumption that 0xFFFE will be in the identifier is incorrect.  That
> pattern is only inserted when the 64-bit IID is generated from a 48-bit
> IEEE identifier.  If I use a 64-bit IEEE identifier, the u bit will be
> set to 1, but the 0xFFFE pattern will (most likely) not be there.
> 
> 
> --------------------------------------------------------------------
> 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
--------------------------------------------------------------------

Reply via email to