Subject: RE: Avoiding interface failure upon DAD failure

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

Charlie,

I will just say I do not support this exception for mobile nodes.  I say
figure it out and get LLs right.

/jim

> -----Original Message-----
> From: Charlie Perkins [mailto:[email-masked]] 
> Sent: Wednesday, May 07, 2003 10:07 AM
> To: Bound, Jim
> Cc: Jari Arkko; [email-masked]
> Subject: Re: Avoiding interface failure upon DAD failure
> 
> 
> 
> Hello Jim,
> 
> Bound, Jim wrote:
> 
> >Hi Jarko,
> >
> >My input is that if LLs do not pass DaD then something is 
> very broken.
> >
> If DAD fails for the link-local address, then it means that the 
> link-local address
> cannot be used.  That is what is broken.  It doesn't mean the 
> interface is broken, which is what would be solved by making 
> it fail.  That is especially true in this case, because the 
> mobile device is likely to evidence that 
> the interface
> was working correctly until it tried to connect to a new point of 
> attachment.
> 
> Since that link-local address cannot be used, the device has 
> to try another one.  Disallowing this is indeed too drastic, 
> because shutting the interface could cause major delays and 
> user inconvenience.  I don't think anyone has noticed any 
> difficulties with just picking another link local address.
> 
> >To do a work around this is not prudent in our standards 
> process when 
> >DaD breaks.  In any interoperability test suite I know if 
> you fail DaD 
> >and don't do what our specs say you fail the test period.
> >
> Did anyone ever notice a problem with selecting a new 
> link-local address? Isn't this what happens if a device tries 
> to use a 3041 address which has a conflict?
> 
> 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]
--------------------------------------------------------------------