I presume I am misunderstanding you Brian.
You seem to be saying that because some liet coul violate the spec, and
set u==1 on something that did not come from an EUI-64 on that device,
then it ollows that the spec is meaningless.
It is true for almost all our specs tat they can be ignored, bent, or
violated, and mostly, things still work.
That does not make the specs or their requirements meaningless.
The fact that you can make a u==0 IID from anything you want is
irrelevant to the question of what u==1 means.
Is there an implementation in the real world that is violating the spec
by generating u==1 from something other than EUI values? I wuld be very
surprised, but if you know of such, and there is a reason they di it,
that would e useful information.
As far as I can tell, all of the confusion regarding the spec has been
in what else we are allowed to specify. So having a clearer spec would
help us. But that, by itself, even with pithy quotes, is not a reason
to change an existing IETF agreement.
Is there a problem with the current rules?
Yours,
Joel
On 2/3/2013 6:43 AM, Brian E Carpenter wrote:
On 03/02/2013 10:57, Rémi Després wrote:
Le 2013-02-02 à 18:17, Joel M. Halpern <j...@joelhalpern.com> 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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
