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.
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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
