On 02/02/2013 17:48, Ray Hunter wrote: >> Fernando Gont <mailto:[email protected]> >> 2 February 2013 16:15 >> >> How could you possible ensure such uniqueness without coordination? >> (i.e., how can you ensure uniqueness if several non-cooperating >> organizations are generating OUIS with u=1?) >> >> Cheers, > You can't at a global/ multi-link level. But for IPv6, why should the > IETF care? All RFC4291 really cares about AFAIK is that the IID acts as > a tie breaker per link.
Only because it's supported by DAD, surely? There is no piece of magic that absolutely prevents two hosts claiming the same IID. Brian > It's not as though any competing LAN/Link > standards are going to be sharing a single L2 network. > > If VMware come up with a virtual "Wizzinet" to connect virtual routers > and virtual end nodes, and they coordinate the IID's to be "unique > enough" per link, and they use EUI64 format addressing, but not OUI's > administered by the IEEE, what's the problem? You're not going to plug a > physical Ethernet cable into a virtual link. > > Speaking with an operational hat on, I'd rather have access to tools and > protocols that can perform mapping/registration of e.g. DUID <=> L3 <=> > L2 bindings, such as > http://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration, rather > than any fixed transformations or encoding. Although it's not problem > free, at least we could then concentrate on ensuring DUID uniqueness in > whatever scope we were concerned about. And it covers self-generated > privacy addresses too. And potentially MAC spoofing/ locally > administered addresses. Rather than relying on static addressing > administered by some other standards body and which is reliant on good > behaviour by all participants. As I'm sure you're aware, operations are > rapidly moving to virtual machines and devices, and dedicated network > hardware with a burned-in interface ID is disappearing. > >> Ray Hunter <mailto:[email protected]> >> 2 February 2013 14:45 >> 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 <[email protected]> : >>> >>>> 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: [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 >>>> -------------------------------------------------------------------- >> ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
