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.
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
--------------------------------------------------------------------
