On Sat, 2 Jun 2001 [EMAIL PROTECTED] wrote:
>       at the interim meeting, there was a discussion on DAD (whether
>       it is mandatory for all address, or we can do it just for link-local
>       and omit for globals that share the same interface id).
>
>       the original text is in the second bullet.  i believe it is a bit
>       confusing at best.  the first sentence recommends (SHOULD)
>       running DAD on every address you have, and then the following sentences
>       say that you MAY omit it in certain conditions.  my suggestion is to
>       keep the first sentence and remove the exception sentences.
>
>       it still leaves me a bit fuzzy feeling as DAD works only if everyone
>       does it - so MUST sounds necessary to me for DAD to be useful.
>       DAD does not always work anyways, due to network partition or ethernet
>       chip initialization delays.  so i'm okay with SHOULD on the first line.
[snip rest]

The partitioning reminds me of a fact I've been meaning to ask opinions
about.

If a link was partitioned when two hosts did DAD, and the network heals
up, what happens?  Is there any way to recover from the situation?
Are the both nodes screwed until either interface is brought up and down,
enabling DAD?

Which brings me to an idea: some implementations (routers, usually) have
knowledge of link status (cable is/is not plugged in, is broken etc.).
For these, would it make sense to defer DAD until link goes up and keep
the address tentative until then?  If a lot of implementations did this,
the consequences of broken linkcould be smaller.  Nodes have no way of
knowing if network was partitioned upstream, of course.

Also, it could be possible to redo DAD after link status cycled, but this
could add too much traffic to the network and might open a door for easier
address stealing.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to