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); 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). 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. 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? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
