Re: I-D ACTION:draft-hoon-mobileip-undad-00.txt

Hi Praveen,

You may have misunderstood what I meant.
I will discuss this below.

Praveen Rajendran wrote:

> 
> Greg  had pointed out problems with populating the NCE in cases where the
> router boots after some of the nodes or when the router goes down and comes
> up. Ed had suggested using a multicast ping for the purpose ... some
> topological features can hamper its efficacy .. but the same can equally
> apply to the normal DAD process. As RFC 2462 claims "Note that the method
> for detecting duplicates is not completely reliable, and it is possible that
> duplicate addresses will still exist." and the Optimistic DAD draft
> reinforces in section 4.4 - the DAD procedure only provides a very good and
> not a complete assurance that duplicates are absent.
> In my opinion using the Ping process would not lead to a unacceptable risk
> causing the DAD procedure to fail.

It is true that DAD itself is not currently completely
reliable. This is based on the issue of packet loss on
DAD attempts or defense.

One obvious way to improve this issue is to do more
DAD NS attempts in order to improve the chance of
detection.  This would mean that the tentative time
would in effect, be longer.

If we have to check anyway, because we have got an
unreliable DAD indication, then it's fairly important
to ensure that this check doesn't interfere with
packet reception, or harm others in the collision case.

This is what optimistic DAD does.   If we need to do
a DAD, then why go to extra effort in maintaining state
unless it contains authoritative information?

Conversely, if we can't build state for the network,
and then we shouldn't give away an address in a way which
considered 'authoritative'.  By this I mean one that
doesn't need to be DAD'ed by hosts.

The key to authoritative statements about the
availability of arbitrary addresses is that
state building has to be based on requirements
for existing IPv6 hosts.
These hosts may also be on the network with the
fast-DAD node and stateful router and must be made to
volunteer state if an authoritative DAD replacement
is to be provided.

The ping ff02::1 won't work.
Existing hosts don't have to respond to the message.

So we have three approaches to DAD optimization:

* (Authoritative) Network Stateful DAD.
   These systems contain sufficient information
   to allocate an arbitrary address on the
   network to a reuqesting host.

* Address Set Stateful DAD.
   Maintains state about a router defined set
   of addresses which are guaranteed to be
   collision free. (this is Advance-DAD)

* Stateless DAD.
   Achieves DAD by direct query of potentially
   conflicting hosts.  This can be
   heuristically determined if no responses
   are received to a DAD request.  In the
   probing interval, a configuring host must not
   cause harm to neighbors which cannot be repaired
   by DAD defense in the collision case.

Non Authoritative responses will have to fall back
to a stateless mechanism, to guarantee safety.


> Another solution can be the partitioning of the NCE  into static entries and
> mobile entries as I had stated earlier and having the static entries
> administratively configured. That would overcome the problems when the
> router boots up after some of the static nodes boot. Mobile nodes perform
> DAD after the receipt of RA messages only and the router can handle those
> cases. That would still leave the case where the router goes down and comes
> up .... carrying forward the state information cannot be enforced in such
> cases ... perhaps reconfiguring the addresses in the mobile nodes can be
> used in such cases?

Indeed, sending a new prefix (one with a short lifetime)
would work (but not for link-local).

Partitioning the NCE doesn't help though, because
keeping manual state about hosts on a network
is prohibitive.  You'd need to have complete state
about addresses used on the link.  Even DHCP doesn't
have this (DHCP addresses need to be DAD'ed).

If you didn't have that state (for example because
the router went down and there were still mobile devices
connected at L2) then it would lead to the same issue as
before: lack of authority in the address allocation.

Greg