[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Summary: Avoiding interface failure upon DAD failure




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.

On your summarized points:

>    * 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).

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.

>    * 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)

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.


Jari Arkko wrote:
> 
> 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 majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------