Brian, I agree that this is a good time to clarify uses of u and g bits, and support the initiative Sheng and yourself has taken. Comments and suggestions inline.
2013-02-01 21:13, Fernando Gont <fg...@si6networks.com> : > 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). It completely eliminates collisions for all devices that comply with IEEE specifications, and dramatically reduces it where some vendors have reused some IEEE MAC addresses. If two devices have the same IEEE MAC address on a link, they have a problem at the link layer, even before having one at the IP layer, and has to be fixed. In any case, and more important in my understanding, this doesn't change that any IID having u=g=1 can never conflict with IEEE-derived IIDs, be they duplicated or not. A clarification on this would IMHO be useful. > 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. AFAIK, it means that *if u=1* the structure of other bits has to be universally specified. This is used so far for IEEE-derived IIDs. It can advantageously be used for other technologies, as foreseen in RFC4291 itself. 4rd is just the first proposed new use. > i.e. some non-IEEE technology is expected to obey the u/g bits? - For all addresses subject to SLAAC, all IETF technologies are constrained by the u-bit meaning of RFC4291. If u=0, all other bits have no recognizable structure; if u=11 if all other bits have a recognizable - For addresses that aren't subject to SLAAC like, for instance, those of inter-router links of RFC6164, the RFC4291 structure of /64 IIDs isn't applicable. A clarification on this would IMHO be useful. Now, a new point: The sentence of RFC 4291 about future technologies ((*) above) is, in my understanding and if taken rigorously, less open than it can be concerning future technologies. It is sufficient that IIDs of new technologies using u=1 have a universally recognizable structure. There IID scopes can have a non-universal scope without breaking anything. Your draft can be a place to clarify this. Note that this point is made in general, as a contribution to clarify the u/g issue, not because it would concern 4rd. IIDs of 4rd are universally unique (each one contains a globally unique IPv4 address, plus a CNP field which has different values for all CEs that share this address). > 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? All currently specified randomizations concern IIDs that have u=0. None can conflict with formats specified for u=1 IIDs. Regards, RD > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
