On 2009-07-04 10:52, Rémi Després wrote: > > Le 3 juil. 09 à 19:01, Dave Thaler a écrit : > >>>>> 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. > > First to be noted: this discussion is only about 64 bit-IIDs on IPv6 links. > It needs not to interfere with that on IPv6 addresses whose lower bits > are never used as IIDs on IPv6 links.
If you read the text in RFC 4291 (and its predecessors), it is clearly intended to be broader than that: >> 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. That isn't restricted to the notion of a link as such; or if you prefer, it also applies to virtual links, and SIIT synthesizes a virtual link under its PREFIX. This matters if any variant of the routing architecture is adopted which resembles 8+8 and its descendants. IIDs need to be globally unique then, so tramping on the g bit would be a problem. So in fact, although the authority is 6man, the debate would need to be wider. Note, I'm not necessarily disagreeing with you; but this is a very big architectural decision. To make rapid progress here, we may prefer to skip over the u and g bits, even though it's a bit ugly. Brian > > Now on this subject, the sentence that IMHO is even more a problem is > that which precedes the sentence you quoted: > "IPv6 nodes are not required to validate that interface identifiers > created with modified EUI-64 tokens with the "u" bit set to universal > are unique." > > As we know, the only escape mechanism to define new IID types is <u', g> > = <1, 1> (where u' stands for u inverted from EUI-64). > The effect of the sentence above is that the only escape mechanism can > be used ONLY for new _universal-scope_ IIDs. > This ONLY could however be relaxed because, as long as new IID types are > not defined yet, all node stacks that have u' = 1 in their IIDs also > have g = 0. > Stacks that may in the future have both u' and g set to 1 in their local > IID can therefore have a different behavior without incompatibility with > the installed base. > > If a revision an RFC 4291-bis can be envisaged (see > www.ietf.org/mail-archive/web/behave/current/msg06102.html), the > following proposal will take the opportunity to open, by precaution, the > possibility of new IID formats of BOTH universal and local scope. > The two sentences become: > "IPv6 nodes are not required to validate that interface identifiers > created with modified EUI-64 tokens with the "u" bit set to universal > and the "g" bit set to 0 are unique. > NOTE: This use of the universal/local and group bit in the Modified > EUI-64 format identifier allows development of future technology that > can take advantage of new types of interface identifiers." > > I cannot personally identify any operational problem with this relaxation. > Besides, one can think of useful proposals based on it, but this should > be another debate. > The point here is just about formal openness to unspecified future > extensions (forward compatibility.) > > Regards, > RD > > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
