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

Re: Avoiding interface failure upon DAD failure



Hi Jim,

Your point is taken.

When a supposed unique identifier fails to be unique,
we have the problem.  The Current RFC2462 text only
refers to those link-local addresses formed from
(unique) interface identifiers.

I've been looking to see if there's a way to work
around this issue in the fe80::EUI_64 case.

I originally thought that the node
undertaking DAD would be able to tell if there's
a MAC collision (or not) by inspecting options
in the DAD defence NA.
My thought was that the conflicting MAC address
would be contained in the NA's Target Link-Layer
Address Option (which must be sent).
Presence of a different MAC could be used to detect
MAC non-collision.

I've since realized that a defending node
can send any of its MAC addresses in the TLLAO.
So reception of a different MAC address does not
imply that there is no MAC collision.

Where there is a MAC Collision, there's no
mechanism short of changing the MAC address of
the interface which could allow safe operation.

Maybe this could be done more automatically (choosing
a (random) MAC address from the local scope perhaps),
but I'm not sure that this should be in a Stateless
Address Autoconfiguration document.

Greg

Bound, Jim wrote:
> Greg and Youn-Hee,
> 
> It is restrictive yes.  But to relax that is fine if well thought out
> and discussed.  But I think it important to understand why the nature of
> the restriction is to much and it what cases.  As Youn-Hee pointed
> predicting IEEE 802 IID failures is a challenge.  Also one does not have
> to use IEEE 802 for IID as a note.  It could be CPU ID, etc.  
> 
> But discussion of when its ok to keep moving the failure mode is prudent
> for us to truly understand in the IETF.
> 
> /jim
> 
> 
>>-----Original Message-----
>>From: Youn-Hee Han [mailto:yhhan@sait.samsung.co.kr] 
>>Sent: Monday, May 12, 2003 12:51 AM
>>To: greg.daley@eng.monash.edu.au
>>Cc: ipng@sunroof.eng.sun.com
>>Subject: Re: Avoiding interface failure upon DAD failure
>>
>>
>>Greg Daley wrote:
>>
>>
>>>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).
>>
>>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.
>> 
>>
>>>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.
>>
>>As well as the correct behaviour, we can also specify
>>several DAD Optimization in a new draft. (e.g., oDAD)
>>
>>YH
>>
>>
>>----- Original Message ----- 
>>From: "Greg Daley" <greg.daley@eng.monash.edu.au>
>>To: "Bound, Jim" <Jim.Bound@hp.com>
>>Cc: "Charles E. Perkins" <charliep@iprg.nokia.com>; "Jari 
>>Arkko" <jari.arkko@kolumbus.fi>; <ipng@sunroof.eng.sun.com>
>>Sent: Monday, May 12, 2003 11:10 AM
>>Subject: Re: Avoiding interface failure upon DAD failure
>>
>>
>>
>>>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:charliep@iprg.nokia.com]
>>>>>Sent: Thursday, May 08, 2003 11:37 AM
>>>>>To: Jari Arkko
>>>>>Cc: ipng@sunroof.eng.sun.com
>>>>>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 
>>>>
>>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
>>
>>--------------------------------------------------------------------
>>
>>>
>>>--------------------------------------------------------------------
>>>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
>>--------------------------------------------------------------------
>>
> 


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