Hi Fernando, On 01/02/2013 20:13, Fernando Gont wrote: > Hi, Brian & Sheng, > > On 02/01/2013 05:13 AM, Brian E Carpenter wrote: >> We've put this together to address the general question of the >> u/g bits in Interface IDs. Discussion is requested. > > Some comments: > > > Section 1: > > >> The specification assumes that that the normal case is to transform >> an Ethernet-style address into an IID, preserving the semantics of >> two bits in particular: >> >> 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. (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. In any case, as soon as you admit a non-zero probability of collision, the game is changed. > Section 2, page 4: >> "The use of the universal/local bit in the Modified EUI-64 format >> identifier is to allow development of future technology that can take >> advantage of interface identifiers with universal scope." > > > 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.e. some non-IEEE technology is expected to obey the u/g bits? > > > 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? You can't. Operationally you *might* have enough knowledge, but that is exactly why we included the word "guessed". Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
