Inline Rémi Després wrote: > 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: Right. "Normal case." Not "exclusive case." >>> 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). This is also my interpretation. > 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=1 can never conflict with IEEE-derived IIDs, be they > duplicated or not. A clarification on this would IMHO be useful.
I have a problem with any assumption that u=1 => global uniqueness, or u=1 => IEEE EUI64 with IEEE administered OUI. Carefully reading RFC4291 I come up with the following: Quote: "Modified EUI-64 format-based interface identifiers may have universal scope when derived from a universal token (e.g., IEEE 802 48-bit MAC or IEEE EUI-64 identifiers [EUI64])" Note the "may" and note the "e.g." Quote: "EUI64 *format*" Note the complete absence of text like "when u=1, the IID SHOULD/MUST be formed from an IEEE EUI64, including a globally unique OUI portion administered by the IEEE." I therefore openly question any assumptions regarding the IEEE as being defined as the sole and exclusive source of "universal tokens" in the IPv6 addressing architecture. If another standards body built a link technology based on EUI64 *format* identifiers, but with their own OUI administration, that should never be a problem for IPv6, because RFC4291 only requires IID's to be "unique within a subnet prefix." They are not required to be globally unique across all link technologies. This is backed up by another quote from RFC4291: "The details of forming interface identifiers are defined in the appropriate "IPv6 over <link>" specification" Even the IEEE definition of EUI64 in http://standards.ieee.org/develop/regauth/tut/eui64.pdf states Quote "When an EUI-64 is used within the context of an IEEE standard, the standard shall be reviewed by the IEEE RAC for correctness and clarity. When an EUI-64 is referenced within non-IEEE standards, there shall not be any reference to IEEE unless approved by the IEEE RAC." Was this coupling of standards ever reviewed by the IEEE? Because it seems to me that the lack of universally clear handling of the u=1 g=1 case in IETF documents would not fit with the existing IEEE definition of EUI64, where u=1 g=1 is clearly a globally administered multicast address, and is not available for any other use. So my conclusion is that any coupling between IEEE and IETF standards should be weak at most, and also limited to individual links. > > >> 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= 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= all other bits have no recognizable > structure; if u 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=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= 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 --------------------------------------------------------------------
