Subject: RE: Avoiding interface failure upon DAD failure

From: "Bound, Jim" <[email-masked]>
Date: Mon, 12 May 2003 05:03:32 -0400

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:[email-masked]] 
> Sent: Monday, May 12, 2003 12:51 AM
> To: [email-masked]
> Cc: [email-masked]
> 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" <[email-masked]>
> To: "Bound, Jim" <[email-masked]>
> Cc: "Charles E. Perkins" <[email-masked]>; "Jari 
> Arkko" <[email-masked]>; <[email-masked]>
> 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:[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]
> > --------------------------------------------------------------------
> > 
> 
> --------------------------------------------------------------------
> 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: Greg Daley <[email-masked]>
Date: Tue, 13 May 2003 18:15:26 +1000

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