Subject: Summary: Avoiding interface failure upon DAD failure

From: Jari Arkko <[email-masked]>
Date: Mon, 12 May 2003 18:01:28 +0300

Hi,

I'll try to summarize the discussion about this issue and propose
a way forward.

The proposal was to allow the use of randomly generated addresses
a la 3041 for link-local addresses and care-of addresses in mobile
nodes while they are roaming around. Since RFC 2462 requires less
drastic collision actions (disable address) for random
addresses than for EUI-64 based addresses (disable interface),
this was thought to have a positive effect to the resiliency
of the system, if after failure one would still like to use
the interface after moving to another link.

A part of the discussion that arose dealt with the issue
of skipping DAD and how useful (or not) it is. This part
of the discussion is not relevant for our original question,
because we follow the current RFCs and do DAD as specified.
However, it appears to be a periodically discussed subject
in the IPv6 WG. As such, some further work in the WG might
look at that. Ongoing efforts to look at optimistic DAD
is one such item and I will suggest another one later in
this e-mail.

There was also a lot of discussion of EUI-64 -based
address conflicts. This is also outside the scope of
our proposal, and is ignored in this e-mail.

But back to the proposal and the issues around it.
The following points were made:

Protocol issues:

   * Clearly, mobile nodes can use RFC 3041 addresses
     like any other application. No issue here (Hesham).

   * Mobile IPv6 should disable the link but when moving
     to a new link can re-try DAD (Pekka).

   * Discussion concludes that MAY use 3041 (Mika).

   * Move on without this and discuss the issue in depth
     in IPv6 later (Jim).

   * There is a need to work on clarifications and
     treatment of wireless cases for DAD (Greg).

Desired behaviour:

   * Collision is so rare, should not bother to prepare
     for nice treatment if it happens (Mika).

   * Rare errors should also be handled, many IPv6
     error handling mechanisms such as DAD work
     with rare events (Hesham, Jari).

   * Collision means something is serious wrong, should
     not continue (Bob, Pekka).

   * Devices should recover by themselves after moving
     elsewhere, otherwise device needs user attention
     or even service (Jari).

   * Disabling the interface is harmful to users (Charlie).

   * Diagnostics on the mobile node will be able to
     tell what's going on (Greg).

Specifics of collisions:

   * There's a difference if the DAD failure is due to
     this node or another node, in the latter case disabling
     interface harms future use. Trouble is, hard to know
     which case it is (Jari).

   * Inspection of SSLA can tell you whether to disable
     the interface or not (Greg).

   * DAD failure means the address is bad, not interface
     (Charlie).

   * Why does the collision happen - EUI-64 collision,
     software/hardware problem, malicious user, random
     collision? This has an impact on the proper "cure".
     (Jari, Pekka, Vijay)

Summary

A key requirement question is of course whether it is
desireable for the mobile nodes to disable themselves
or have some form of automatic resilience against
temporary problems. There was no clear consensus on
this issue (though the question about whether EUI-64
or something else is used affected the discussion). My
belief is that some level of resilience is necessary,
unless EUI-64 addresses are used. This idea seems to
be built into RFC 2462 as well, because it has different
collision actions.

Another important question is to what extent the
existing protocols already support the desired
behaviour. Clearly, mobile nodes can use 3041
addresses when they move around just like other
nodes. Given the current 2462 rules, collisions
for such addresses do not disable the interface.
There are two limitations of this, however: (a)
3041 does not specify the creation of link-local
addresses and (b) 3041 says that after 5 collisions,
stop generating any more addresses on that interface.
This is almost sufficient for the desired behaviour,
since mobile node could presumably use only global
care-of addresses, and getting to five collisions
is highly unlikely. (Though it would seem better
to have the limit per link.)

Another current protocol facility is Neighbor
Discovery in general, its concept of an interface.
We've lately started to realize that it may not
always be clear what is considered as an interface.
Does movement to a new link constitute the initialization
of an interface, resetting all knowledge of DAD failures,
reconstructing all data structures?

Recommended way forward:

Existing specifications already can give (very) limited
support for the feature that we desired. We could add
the link-local case and in doing so say that the 5-collision
limit is per link. We could also specify that DAD issues
in general are "reset" upon movement to a new link. The
latter in particular would appear quite reasonable. However,
I am afraid of two things: (1) Perhaps the understanding
for what ND information gets reset in what kind of movements
should be developed in full for all of ND, and not just for
the particular case of collisions. (2) Continued discussion.

Therefore, my recommendation is that we delete the Section
7.6 from the Mobile IPv6 draft that deals with this issue,
and work for the better understanding of what an interface
means in the context of the following work:

   - A full & optimized movement detection scheme that has
     been suggested to be worked on in the MIP WG or one of
     its follow-up WGs.

   - Optimized DAD.

   - Possible other new work taking place wrt ND or DAD.

--Jari

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 12 May 2003 08:47:24 -0700

Hello Jari,

There is no need to delete the section.

I suspect that some of the objections were raised
would no longer be at issue once the following
are understood:

- There are no changes whatsoever to the installed
  base of IPv6 addresses

- A device could be working perfectly well, having
  run DAD on its link, but when moving to a new link
  then might reset its interface.

I would hope that most designers would realize that
the mobile device should NOT reset its interface
in this circumstance, preferring instead to choose
a(nother?) RFC 3041 randomized address.

The progression of deleting more and more performance
improvements from the specification has to be
stopped, and in this case there is no reason at
all to remove the language.

Otherwise, someone would someday find that their
mobile device stops working for no reason at all.
There have been no convincing arguments presented
why we should cause this pain, instead of allowing
and encouraging the better design.

I do not support this suggestion to delete section 7.6.

>      interface harms future use. Trouble is, hard to know

I do not see the relevance of this.  If a node moves to
a new link, on which some other node has by chance already
used RFC 3041 to configure the incoming mobile node's address,
then the incoming node should be allowed to gracefully
recover.  Therefore, this measure corrects a problem that
is completely unrelated to DAD failure.  Since the device
is "known working" from a previous link, we should not
expect that the address collision is due to interface failure.

>      collision? This has an impact on the proper "cure".

The _possibility_  (in this case, not very likely it seems)
of future specification does NOT imply that all current
specification is broken.

Regards,
Charlie P.

---

From: Mika Liljeberg <[email-masked]>
Date: 12 May 2003 20:40:41 +0300

> a(nother?) RFC 3041 randomized address.

A node using RFC3041 will have two link-local addresses on the network
interface:

- FE80::EUI64_ID
- FE80::TEMP_ID

The node will do DAD for both.

If DAD on the former fails, it is an indication of MAC address collision
(or some equally fatal problem). In this case, the MN obviously SHOULD
disable the interface (at least until it has moved to another link).

If DAD on the latter fails, it is probably just bad luck and the MN
might as well pick another TEMP_ID and try again.

With that in mind, I fail to see how using RFC3041 addresses would give
any benefit in terms of resilience, since the random nature of the
TEMP_ID selection is causing the collisions in the first place. Why is
the MIPv6 specification concerned with this anyway?

	MikaL

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 12 May 2003 10:48:05 -0700

> disable the interface (at least until it has moved to another link).

No, the mobile node should disable use of that address.

What if some other node on the new link has configured a TEMP_ID
that happens to collide with the mobile device's EUI64_ID?

The proposal is to allow, in that case, the mobile node to
configure a new TEMP_ID -- and NOT disable the hardware.

> might as well pick another TEMP_ID and try again.

Exactly.

> the MIPv6 specification concerned with this anyway?

Only because it is, in many systems, a mistake to disable
the hardware.  Not all systems.  No mandate is required, only
the _possibility_ of designing a resilient system.

Regards,
Charlie P.

---

From: Mika Liljeberg <[email-masked]>
Date: 12 May 2003 21:15:38 +0300

> No, the mobile node should disable use of that address.

In that case you're doing more than just referring to RFC3041. RFC3041
merely defines a random TEMP_ID for configuring *additional* global
addresses with better privacy characteristics. It does not remove the
existing link-local address, nor addresses configured from it.

> that happens to collide with the mobile device's EUI64_ID?

That can't happen, since RFC3041 IIDs will have the universal/local bit
set to zero, while IIDs generated from MAC addresses will have the
universal/local bit set to one.

	MikaL