Date: Wed, 14 Aug 2002 14:24:44 +0300
From: Markku Savela <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| - implementation requires more complex code
I don't know how you reach that conclusion. The DAD approach is
simple to understand and to code ... any time an address is to be
assigned, run the DAD algorithm (which is the same whether it is used
for a pure DAD approach, or a DIID one). That's it. No need to
go looking to see if it has run before, no need to invent LL addresses
to run DAD on, no need to do any special case handling of incoming
NS messages to see if they're DAD< and if so reply to ones that wouldn't
otherwise have been replied to,...
| - it causes more packets on the link
This one is undisputed. I'm not aware of measurements of how many more.
Do note though that typical DAD NS packets use wire bandwidth, but
nothing else (no-one receives them), so they're not very costly.
They're also not usually very frequent (configuring new addresses
doesn't happen all that often).
| So, I'm kind of wondering what functionality is actually missing?
I don't think it is really a question of missing functionality, though
a hint of that was presented at the WG meeting. It is more a case of
there currently being two different implementations of this in the field,
which don't work well together - one of those has to be picked as the
correct one.
| I would propose following rules instead of do DAD on every address:
And this is simpler than "do DAD on every address" ?
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]
--------------------------------------------------------------------
