Hi, Brian, On 02/02/2013 05:25 AM, Brian E Carpenter wrote: >>> o The "u" bit in an IEEE address is set to 0 to indicate universal >>> scope (implying uniqueness) or to 1 to indicate local scope >>> (without implying uniqueness). In an IID this bit is inverted, >>> i.e., 1 for universal scope and 0 for local scope. According to >>> [RFC5342], the reason for this was "to make it easier for network >>> operators to type in local-scope identifiers". >>> o The "g" bit in an IEEE address is set to 1 to indicate group >>> addressing (link-layer multicast). This value is supposed to be >>> preserved in an IID. >> >> The second bullet is not tru: e.g. temp addresses do not do anything to >> preserve the "g" bit (the "u" bit *is* forced to 0, though); > > Well yes, but the statement *is* true when an IID is created from a MAC > address, which is the point being made at that point in the document.
Agreed. (My apologies for how my phrase was worded.. "English as second language"+"24hs working" didn't help much in me crafting my response nicely). > (See my next message for my comment on Joel's reply.) > >> Section 2: >> >>> NOTE IN DRAFT: Are there other examples we should include? Are we >>> sure that no IID format defines semantics for u/g? >> >> Not that I'm aware of. -- AFAIK, the u bit is just used to reduce the >> probability of collisions if your IIDs are derived from global >> identifiers (more on this below). > > Who said that though? You are suggesting an intention which is nowhere > in the documents. Agreed, but the text notes that "that is so that it is easier for manually-configured addresses" -- i.e., the text notes that the idea is that manually-configured addresses don't "overap" with the automatically-configured ones.. > In any case, as soon as you admit a non-zero probability > of collision, the game is changed. I fully agree. That's the point I was trying to make. >> This seems to assume that the namespace (Identifiers) of two different >> technologies does not overlap. Such assumption sounds like dubious to >> me... but I might be missing something. > > Yes, I believe it was a faulty assumption from the start (and I am one > of the guilty parties). I guess the current "MUST" could be changed to "MAY" -- i.e., setting the bit to zero might still help to reduce collisions with IEEE-derived IIDs. HOwever, this discussion raises yet another (more) interesting question: considering the predictability properties of IEEE-derived IIDs, and the fact that you cannot even assume that such identifiers are unique, why are we using that scheme as the default mechanism for generating SLAAC addresses in the first place? :-) Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
