Rémi,

I think you've misunderstood me. Please see below.

On 02/06/2013 02:01 AM, Rémi Després wrote:

2013-02-06  00:45, Doug Barton <do...@dougbarton.us> :

On 02/05/2013 05:57 AM, Rémi Després wrote:
Hi, Doug,

Please see inline.


2013-02-04 à 18:37, Doug Barton <do...@dougbarton.us> :

On 02/04/2013 12:38 AM, Rémi Després wrote:
It remains that IIDs having u=1 SHOULD be unique, i.e. with
rare enough exceptions. This is somewhat similar to the
expectation that ULA collisions shouldn't be seen).

This theoretical unicity has been extensively used to assign
stable IIDs, without administrative action, to hosts  that
have no privacy constraints requiring the opposite.

What software exists that makes determinations based on the u
bit?

(*) Major OSes can assign IIDs derived from IEEE MAC addresses of
their LAN adapters (if not by default, at least as a
possibility). They do it because of what IEEE and IETF have
specified, each one for its own domain, concerning their
respective u bits.

Yes, you've described reality. You haven't answered my questions.

Fair enough. My answer is that no software that I know makes
determination based on the u bit.

Thanks, that matches my (admittedly imperfect) understanding as well.

My point is that it isn't sufficient for the IETF u bit to have no
meaning. (a) It has what is specified in RFC 4291. (b) No software I
know creates IIDs having u = 1 without an IEEE-based OUI.

So my new question is, why do you care?

To amplify slightly, I am ambivalent about un-defining the u and g bits. Generally such a thing is difficult to do, since it's nearly impossible to get a complete survey of all software everywhere that may use those bits, and determine if it is safe to stop to just stop caring about them.

OTOH, I am not a fan of magic bits in general, and I have never seen an adequate explanation of why an implementor should care about these 2. So I'm sympathetic to the argument about un-defining them, but you seem to be vehemently opposed to it, so I'm trying to understand your objection. "It's important because it's important!" doesn't help me. :)

Doug

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to