Brian,
Thanks for your comments.
Further remarks below.
Regards,
RD
Le 4 juil. 09 à 15:56, Brian E Carpenter a écrit :
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:
I had not read RFC 3513 yet (the predecessor of RFC 4291 where the
word "global" was used rather than "universal" in the considered
sentence), but I agree that both express a constraint on u and g bits
"in general".
An update of the the document is therefore needed, if this constraint
has to be relaxed, as I suggest, *for IPv6 addresses that by
construction will never appear as source or destination on any IPv6
link*,
This update is IMHO desirable in the context of 2009 as new IPv6-
address formats are under study, in particular for SIIT.
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.
While I understand that ISATAP introduces an "IPv6 virtual link" (non-
broadcast multiple access in this case), I don't believe the IPv4
side of a SIIT can be considered as an "IPv6 virtual link": nothing
is IPv6 on this side.
Yet I take the point that it should be clear that the u-g bits
constraint that MUST apply to IPv6 addresses that may be used on an
IPv6 links concerns BOTH physical AND virtual IPv6 links.
My second point applies only to addresses that can appear on IPv6
links (the first point was about those that can't).
I hope it's clear that change is proposed to the rule that, on IPv6
links (physical or virtual), addresses MUST have 64-bits IIDs, with u-
g bits conforming to modified EUI-64 rules.
The point is only that there remains only one combination of u and g
bits available for new IID formats (namely u=1, g=1), and that
therefore it should be available for all new IID formats, NOT ONLY
for new IID formats that have universal scope, but ALSO for those
that have local scope.
This of course isn't an amendment of EUI-64 itself, just an amendment
of modified EUI-64 rules.
Note, I'm not necessarily disagreeing with you; but this is a very
big architectural decision.
Not so big in my understanding.
It's no more than this:
Point-1: u and g rules apply ONLY to IPv6 addresses that may be used
on IPv6 links (real or virtual).
Point-2: in IIDs, the only escape combination of u and g bits MAY be
used for ALL possible new IID formats (having universal OR local
scopes).
If there are real technical objections to this, they have to be
looked at, but I personally don't know any.
To make rapid progress here, we may
prefer to skip over the u and g bits, even though it's a bit ugly.
When identified and possible, aren't simple and clean designs always
preferable to ugly ones, in particular to make future work easier?
(When a significant simplification is seen to be possible now, this
is IMHO the best time to decide it: later it is likely to be more
difficult).
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
--------------------------------------------------------------------
