Date: Thu, 22 Aug 2002 00:46:24 +0300
From: Markku Savela <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| The main fact is that my version is just an implementation based on
| the autoconfigure RFC, taking the allowed DAD optimization (= do DAD
| on link-local, combine id with announced prefixes without doing DAD on
| those combinations).
The problem is that this only works if no-one is allowed to create
addresses that don't have link local - otherwise the order in which
the addresses are created makes a race condition wrt DAD.
| Some want to disallow the DAD optimization. I would like to present
| another proposal:
|
| ********************************************
| leave autoconfigure basicly RFC as it is now
| ********************************************
That doesn't work. Something has to solve the problem that has been
identified.
| I think autoconfiguration should be the normal mode how IPv6 nodes get
| their addresses.
Autoconfiguration has always been planned as just one way that addresses
can be allocated. It may turn out to be the most common, but it certainly
shouldn't yet be being elevated to the status of being the "normal" way.
| - just hope you are lucky
Well, I'm not sure if you were in Yokohama, but Steve Deering started
to make a proposal along those lines. It was going to be essential if
the DIID proposal was adopted (I'll let Steve explain it, and why, if
he feels inclined) - it kind of just fell by the wayside, when DAD was
preferred by just about everyone in the room.
| Choosing this does not require a change in any stacks that do DAD on
| all addresses (KAME, Microsoft). It only affects abnormal address
| configurations.
Obviously you can define "abnormal" so as anything affected fits, but
certainly KAME (and I suspect Microsoft) would need to change, as it
allows addresses that aren't based upon a LL address to be defined.
Such addresses are subject to DAD, so that's OK, they won't be duplicates,
but the IID part isn't defended against attempts to re-use it in other
addresses (different prefix). They would need to change.
It is true that there's a tiny chance that when a new prefix
is advertised, a node will fail to be able to assign it, because some other
node had already assigned itself that prefix with the node's IID (the
chance of this in reality seem about as great as the chances of duplicate
3041 addresses, assuming good random number generators, but never mind).
DIID would avoid that tiny possibility.
On the other hand, DIID forbids subnets being merged into one link, if
they happen to have nodes assigned with the same IID (like "1"). There
is no problem with uniqueness of the addresses, the prefixes differ, but
because the IIDs don't, DIID would prohibit them from being used on the
same link.
I know which of those I believe is the more likely to actually happen in
practice, and which is the more serious if it does happen - and it isn't
the first in either case.
kre
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
