Brian E Carpenter wrote: > On 02/02/2013 17:48, Ray Hunter wrote: >>> Fernando Gont <mailto:fg...@si6networks.com> >>> 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=) >>> >>> 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 What "uniqueness" is strictly required for correct operation of IPv6? If the competing technologies can never share an L2 link, what's the problem?
IMVHO We should be careful what semantics we import from other standards bodies, and only do this explicitly. Looking at various alternatives for the semantics of IETF defined flags: u = deprecated. EUI64 MAY be used in generation of IIDs. DAD SHOULD be performed for all unicast addresses. A distinct possibility in my book. Reasoning: IIDs are only tie breakers per link. Collisions happen. Deal with it. u==1 => derived from one (of potentially many) mapping schemes based on a universal token, and therefore nodes MAY skip performing DAD on all link types. Also seems reasonable. Some might even think useful. u==1 && g==0 => IEEE EUI64 with IEEE registered OUI on all link technology Is probably too much (and unnecessary for correct functioning of IPv6 AFAIK) Do we really want to tell everyone who wants to produce links that supports IPv6 that they should obtain an OUI from the IEEE, or force them to use u=0 when generating addresses? What value does this restriction add for the IETF? u == 1 && g==0 => IEEE EUI64 with IEEE registered OUI, but only for IPv6 unicast addresses and only on IEEE-defined link technology. Would be fine by me, and current practice AFAIK u==1 && g==1 => reserved for future use by the IETF for generating addresses on all technologies for both unicast and multicast Is currently a possibility. I wouldn't object. Beyond that, if you want a Universally Unique Identifier you should probably be looking at rfc4122, rather than abusing/re-using IID's for this function. >> 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:v6...@globis.net> >>> 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 <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=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==> global uniqueness, or >>> u==> 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= 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=g=1 case in IETF documents would not fit with the existing IEEE >>> definition of EUI64, where u=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=he 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=ll 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=ve 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=one 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 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
