Subject: [mobile-ip] MIPv6 v20 : error handling (DAD etc) 11.7.1

From: "Greg O'Shea" <[email-masked]>
Date: Thu, 6 Feb 2003 07:52:55 -0000

...reply to the mobile node's subsequent Binding Update with a Binding
Acknowledgement containing a Status of 134 (Duplicate Address Detection
failed). In this case, the mobile node MUST NOT attempt to re-use the
same home address...
That's probably not what you want to do: whatever it was that was
contesting the HoA could go away but we just abandoned the HoA and its
associated state (IPSec) forever. It would be better to say not to retry
the HoA for a configurable amount of time.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 06 Feb 2003 15:34:46 +0200

Greg O'Shea wrote:
> same home address

Yes. We could say "... MUST NOT attempt to re-use the same home
address until the mobile node is reconfigured or a configurable
amount of time elapses."

But would this violate what RFC 2462 requires from DAD collisions?

Jari

---

From: Greg Daley <[email-masked]>
Date: Fri, 07 Feb 2003 10:15:31 +1100

Hi Jari and Greg,

Jari Arkko wrote:
>> Acknowledgement containing a Status of 134 (Duplicate Address 
>> Detection failed). In this case, the mobile node MUST NOT attempt to 
>> re-use the same home address
>>
>> associated state (IPSec) forever. It would be better to say not to 
>> retry the HoA for a configurable amount of time.
> 
> 

I think that the HA won't actually harm any other node
by attempting DAD and failing, but RFC-2462 does instruct
that the interface is disabled on collision (don't retry).

It is reasonable to have a retry timer, but it may have to
be an arbitrary one defined in MIPv6.  The Valid(&Preferred)
Lifetime in the Prefix Information Option indicates how
long a DAD'ed address is valid for on a fixed network
(probably too long to use as a timer).  Times where a CoA
is in use could be a lot shorter if the holder of the
address is another MN visiting the home network.

So the main thing to accomplish with a timer is not to
overload the HA or the network with DAD NS's.

Nick Moore's optimistic-DAD draft suggests starting
at RETRANS_TIMER, with exponential backoff on re-DAD
attempts.  How does this sound?

Greg D.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 07 Feb 2003 18:04:37 +0200

Greg Daley wrote:
> Jari Arkko wrote:
>> Greg O'Shea wrote:
>>
>>> ...reply to the mobile node's subsequent Binding Update with a 
>>> Binding Acknowledgement containing a Status of 134 (Duplicate Address 
>>> contesting the HoA could go away but we just abandoned the HoA and 
>>> its associated state (IPSec) forever. It would be better to say not 
>>> to retry the HoA for a configurable amount of time.
>>

Sounds good to me even if the start time is a bit small.

Anyway, the high-level issue is that we've gotten feedback earlier
from the ADs when we tried to specify a not-so-drastic collision
action for care-of addresses. That may have been a different
case because we were changing the behaviour of ND directly.
Here we are not doing that as we are operating through BUs...
but still, is it going to be acceptable? I have Cced Erik
and Thomas to get an opinion...

I think the alternatives are:

1. Leave the spec as is, but when the optimistic DAD work progresses
    that can also define a new rule for home address collision
    retries.

2. As above, but change the rule in the spec so that reconfiguration
    or admin action allows the address to be used again.

3. Change the rule in the spec to a softer one, which says
    that an exponential back-off starting from, say, 10xRETRANS_TIMER
    should be applied for new registration attempts.

I'm OK with either 2 or 3, with a preference on 3 if this
would be acceptable to Erik and Thomas.

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Feb 2003 09:28:15 +0100 (CET)

I'm missing context on what problem you are trying to solve.

Quoting randomly...
> > that the interface is disabled on collision (don't retry).

Clearly the HA wouldn't disable its interface from a DAD  failure
for one of the MN's addresses.
RFC 2462 is written in the context of a node doing a DAD for its own
addresses which is quite different than the proxy case the HA is performing.

>     should be applied for new registration attempts.

Is this for HoA collisions detected by the HA?
(The earlier discussion was about CoA collisions detected by the MN, which
is different.)

A duplicate HoA seems like a new problem to worry about. 
I think leaving the specification alone and looking at optimistic
DAD ideas and also at the issues of what you bind the security to when the
HoA is changing (whether due to DAD, renumbering the home link,
temporary HoAs etc) makes the most sense.

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Feb 2003 10:42:58 +0200

> I'm missing context on what problem you are trying to solve.

See http://www.piuha.net/~jarkko/publications/mipv6/issues/issue252.txt
Basically, Greg O'Shea asks what happens if the mobile node
gets a response from the home agent that its home address has
been detected as a duplicate.

> for one of the MN's addresses.

Agreed ;-)

> Is this for HoA collisions detected by the HA?

Yes.

> (The earlier discussion was about CoA collisions detected by the MN, which

Yes.

> temporary HoAs etc) makes the most sense.

OK!

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 12 Feb 2003 17:24:45 +0200

> temporary HoAs etc) makes the most sense.

Right.

I closed this issue with no changes to the text. I also
added two paragraphs in the appendix that talks about future
extensions:

App X.Y. Neighbor Discovery Extensions

Future specifications may improve the efficiency of Neighbor Discovery
tasks, which could be helpful for fast movements. One factor which is
currently being looked at is the delays caused by the Duplicate
Address Detection mechanism. Improvements in this area are, however,
generally applicable and progressed independently from Mobile IPv6
specification.

Future functional improvements may also be relevant for Mobile IPv6
and other applications. For instance, mechanisms that would allow
recovery from a Duplicate Address Detection collision would be
useful for both care-of and home addresses.