Subject: Re: Avoiding interface failure upon DAD failure

From: Greg Daley <[email-masked]>
Date: Mon, 12 May 2003 12:10:09 +1000

Hi Jim,

At this stage, I agree that MIPv6 should not
wait for this issue.

Link-Local collision is a relatively low probability,
and diagnostics on the mobile device will be able to
identify the issue.

That said, I think that the current rfc2462 text is
unnecessarily restrictive in this regard and doesn't
cope with a legitimate application (IP mobility)
appropriately  (no offense intended to the authors,
since otherwise I think it does a good job on DAD).

Certainly, there should be follow-up both to clean up
DAD, and later to specify the correct behaviour in
a new draft in mobileip-wg.

Greg Daley

Bound, Jim wrote:
> Charlie,
> 
> You have it backwards.  We don't support this you and others have to
> convince us to alter the base standard for mobile nodes and for me you
> have not done that please don't reverse the process here.  This proposal
> is on the table for justfication not DAD.
> 
> Regards,
> /jim
> 
> 
>>-----Original Message-----
>>From: Charles E. Perkins [mailto:[email-masked]] 
>>Sent: Thursday, May 08, 2003 11:37 AM
>>To: Jari Arkko
>>Cc: [email-masked]
>>Subject: Re: Avoiding interface failure upon DAD failure
>>
>>
>>Hello Jari,
>>
>>Jari Arkko wrote:
>>
>>
>>>My intention is to follow current 2462 to the
>>>letter. The only questions are whether I can
>>>use 3041-like link local addresses, and whether
>>>the goal (avoiding disabled link) is worthwhile.
>>
>>From the point of view of someone trying to use
>>these devices, yes it is very worthwhile to
>>avoid disabling the link unnecessarily.
>>
>>I strongly support keeping this functionality
>>unless someone can point out why it is harmful.
>>We should look at this matter from the point of
>>view of what is best for the users.
>>
>>Regards,
>>Charlie P.
>>--------------------------------------------------------------------
>>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]
> --------------------------------------------------------------------

--------------------------------------------------------------------
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: "Youn-Hee Han" <[email-masked]>
Date: Mon, 12 May 2003 13:51:14 +0900

> since otherwise I think it does a good job on DAD).

I agree with you. It is so restrictive that one DAD failure
disables its interface. However, we should consider 
some suffering problems.

If a node uses EUI-64 address as its IID, DAD failure 
implies IEEE 802 address collision in almost cases. 
In this case, another IID generation is useless 
becasue the communication is not allowed by lower layer.
(This is already mentioned by Bob in this discussion)

Although nodes are attached at IEEE 802 links, however
, we can not assure that they all use EUI-64 address as thier IID.
Some nodes can ganerate random IID. So, DAD failure 
does not always implies IEEE 802 address collision.

If a node can detect whether the IID generation is useless, 
the problem can be clearly resloved. 
In my knowledge, however, it is not possible.
 
> a new draft in mobileip-wg.

As well as the correct behaviour, we can also specify
several DAD Optimization in a new draft. (e.g., oDAD)

YH

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 10 May 2003 09:26:21 -0400

Charlie,

Regards,
/jim