Subject: RE: Summary: Avoiding interface failure upon DAD failure

From: "Bound, Jim" <[email-masked]>
Date: Tue, 13 May 2003 18:59:04 -0400

Hi Jari,

Charlie and I have been having an offline discussion.  We don't fully
agree but we agree on a lot more :--)  And reading the mail.

Here is wild suggestion and close to what you first proposed with
restriction clause.

In the spec:

MAY use 3041 in DAD failure.

But I would suggest wording that this is for the specific case of a
"mobile node" moving.

The reason I change is because I believe DAD failures are more possible
than stationary nodes.  The market requires mobile nodes and the mipv6
spec done.  

This is a solution for today and right now.  The additional text states
this does not apply to stationary nodes so we don't have those nodes
ignoring DAD failures. Which was my main concern that we would open
pandora's box.  With the restriction we keep pandora in her box (not
being gender insensitive but pandora was a female sorry and I like this
old allegory).

Then what we do is go work on this entire problem space of DAD and this
is just one of the issues for mobile nodes of many we can work on and
really subset of movement detection.

We move the MIPv6 spec forward.
We define a new problem space for movement detection we need to work on.
And we not spend another 5 months debating this with multiple sides feet
dug into the mud.
We move forward to PS, we implement further (as this spec has a lot of
implementation) and we see what happens.  

If we are wrong we go back and fix it during post PS process.  PS is not
the end of the day or the end of the work.

We are allowed to be wrong once in awhile, but at this point in the IETF
we MUST always move forward and begin to help some of the problems we
have with getting stuff done in this community at large.

My .50cents,
/jim

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Monday, May 12, 2003 11:01 AM
> To: [email-masked]
> Subject: Summary: Avoiding interface failure upon DAD failure
> 
> 
> 
> 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]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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: Jari Arkko <[email-masked]>
Date: Fri, 16 May 2003 00:25:32 +0300

> But I would suggest wording that this is for the specific case of a

Well, perhaps this could be one way forward.

But the above e-mail and some private conversions with other
folks have alerted me to the fact that the original text
that we proposed was unclear. It seems that many people
interpreted it as "IF you run into a DAD failure, THEN you MAY
start to use temporary addresses". However, this was not the
intention. What we wanted to say was "You MAY use temporary
addresses all of the time".

Clarifying that might be another way forward. I do like
your idea of binding this to movements only, perhaps that
could also be done. How about:

7.6 Failures from Duplicate Addresses

    Upon failing Duplicate Address Detection, [13] requires IPv6 nodes to
    stop using the address and wait for manual configuration of a new address.
    In addition, if the failed address was a link-local address formed
    from an interface identifier, the interface should be disabled.

    Mobile nodes that wish to avoid a disabled link MAY avoid the use
    of interface identifiers when generating link-local addresses
    (and subsequent global addresses). If a collision is detected for
    such an address, it is no longer used but the status of the interface
    stays unchanged.

    Instead, mobile nodes MAY use temporary link-local addresses by
    generating a random interface identifier and using it for assigning
    itself a link-local address and derived care-of addresses for use on
    this link. In order to do this, the mobile node applies to the link-local
    address the procedure described in RFC 3041 [18] for global
    addresses. Implementations SHOULD NOT make more than 5 consecutive
    attempts to generate such addresses and test them through Duplicate
    Address Detection. If after these attempts no unique address was
    found, the mobile node SHOULD log a system error and give up
    attempting to find a link-local address on that interface, until
    the node moves to a new link.

--Jari