Date: Tue, 4 Jun 2002 12:26:31 +0200 (CEST)
From: Erik Nordmark <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| If that is a problem then the "MAY" for the optimization in RFC 2462
| wouldn't be sufficient as a solution - very few implementations do
| the optimization today.
It depends upon whether the problem is one that always needs solving, or
just one that needs to be able to be solved.
| Possible solutions to the new prefix DAD flood could be:
| - mandate the DAD optimization with a MUST
So, I don't think we need to do that, whatever else happens. Then we
get to implementation quality and all that - in an environment where
it matters, users may want to insist on implementations that work well.
In any case, we would need a way to indicate which prefixes should not
be DAD optimized (MUST NOT) because of the multi-link issue.
| - update RFC 2462 to day that when a new prefix is configured (past
| the original "attachment" to the link) the host MUST insert a random
| delay before performing the DAD.
That's certainly a reasonable approach (though I'd prase it as "before
configuring an address using the prefix" to make it more clear that it
isn't only the DAD that needs to be delayed).
| But do we agree that the DAD flood when a new prefix is announced is
| an important problem to solve?
Like a lot of this, I suspect this may be known only when we get IPv6
nets that are really big enough that the effects can be measured. I'm
not sure there are all that many. I suspect that even the IETF net
won't have enough IPv6 nodes actively connected to it to run an experiment
there and see what happens.
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]
--------------------------------------------------------------------