Date: Tue, 30 Jul 2002 07:33:07 +0300 (EEST)
From: Pekka Savola <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| > I don't agree with the first sentence there, I think I'm (a) someone...
| I'd like to hear what kind of network configuration you have in mind.
One obvious one is when I have two links, and have assigned pfx1::1 to
my favourite node on one of them, and pfx2::1 to my favourite (different)
node on the other, and then I decide to merge the links into one. Applying
both prefixes to the link is easy, so I shouldn't have to renumber anything
just because of this (pyhsical) change (maybe a temporary one caused by
the death of a switch, while waiting upon a replacement - assuming I'm
too cheap to buy switches that support vlans...). But now I have two ::1's
on the one link.
| My main point is just that one should be able "optimize" DAD somehow if
| there are long latencies involved (e.g. serialized full DAD is
| unacceptable with many addresses). How, that's another issue. Else folks
| that need to optimize it will do so anyway.
N different DAD's (that is for different addresses) on one link should
complete in the time it takes to do one DAD (that is, for one of those
addresses), plus noise (the time it takes to transmit the other N-1
packets). Doing DAD for all of the addresses consumes some bandwidth,
it has no other noticeable effect (or should have) on the node that is
performing the DAD.
Certainly there will be two DAD delays when a node boots - the first to
get its LL addr, and then one more, for all of the other addresses it
creates after it has received the RA (in all of that, I'd actually expect
the random wait before sending the RS, if no RA just "happens", to be the
biggest source of delay to a booting node). But the number of addresses
it has on the link (LL, SL, or global) should not materially affect
anything.
An implementation that has N addresses ready to verify, so does DAD on
the first, then after that is complete, DAD on the second, etc, would be
just too cheap to consider for anything real (on the other hand, for some
applications where human patience isn't an issue, that might be OK).
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]
--------------------------------------------------------------------
