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.
The other alternative I can understand, although I do not favor it, is
to not allow the diagnostic at all.
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
--------------------------------------------------------------------
