Subject: RE: Avoiding interface failure upon DAD failure

From: [email-masked]
Date: Tue, 6 May 2003 15:08:16 +0300

Hi Jari,

> This is something that came up in the IESG review of Mobile
> IPv6 base specification (draft-ietf-mobileip-ipv6-21.txt).
> Erik asked us to get an opinion from the IPv6 WG on this.
> 
> As you know, upon failing Duplicate Address Detection, RFC 2462
> requires IPv6 nodes to stop using the address and wait for
> reconfiguration (Section 4). In addition, if the failed address
> was a link-local address formed from an interface identifier,
> the interface should be disabled (Section 5.4.5).
> 
> The second action is relatively drastic in situations where
> a host visits a large number of networks and is therefore
> more likely to get into this situation either by accident or
> by a malicious act. (SEND WG will eventually solve the
> latter issue, though.)

I agree that the solution posed by 2462 is (IMO) too drastic.

> In Mobile IPv6, we've recommended that if the mobile
> node wishes to avoid disabling its interface, it can
> generate link-local addresses in an RFC 3041 fashion
> and use them. Therefore, the addresses will not be
> based on an interface identifier and the interface
> will not have to be disabled per RFC 2462. (Existing
> rules in the ND RFCs are followed.) Here's the text
> we have on this:

I think that this solution (& your proposed text) is a
reasonable way forward.

I think that we should consider updated 2462.

br,
John

--------------------------------------------------------------------
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: Hesham Soliman <[email-masked]>
Date: Wed, 7 May 2003 12:05:56 -0400

> Hesham Soliman wrote:
 > >  > 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?
 > > 
 > > => I would like to add that this is also needed for 
 > > the global care-of address (i.e. pick another address
 > > if DAD fails according to RFC 3041). 
 > 
 > I don't think so.  The global COA is usually formed with
 > the same ID as link local.  So, if the link-local was
 > gnerated using 3041 (as the mobile spec suggests), the
 > global whould simply re-use the ID generated for the link-local
 > address.  So no special cases is needed.
 > 

=> Well, there is nothing that prohibits having a 
different iid for globals. But anyway, I wasn't saying 
that there is an additional restriction for globals
but simply that RFC3041 will be used for both ll and 
global addresses. There was a lot of emphasis on link-locals
in the text and in emails from Jim and Charlie. 

Hesham

---

From: Jari Arkko <[email-masked]>
Date: Wed, 07 May 2003 23:01:15 +0300

Jim Bound wrote:

 > I do not think SEND needs to complete to move forward at all

There was no intent to wait for SEND. It was only mentioned
for background.

 > Just fail on the interface per the specs and move forward with the spec.

This is what I will do, unless IPv6 WG supports the proposed
text.

--Jari

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 8 May 2003 10:12:12 -0400

> The issue is not so important that it justifies a very
 > lengthy discussion, imho,

=> Agreed.

 and I will delete the text
 > unless it is supported here. 

=> I hope it is supported, otherwise, why is RFC 3041
a PS?

Perhaps we'll wait for
 > one additional round of e-mails before taking a decision,
 > it seemed that a part of the discussion was based on
 > the wrong assumption that MAC addresses were used
 > in the addresses.

=> My only comment is that I don't understand what
the discussion is about ;) 
MIPv6 effectively says: To configure a CoA use RFC 3041.
Is this wrong? Is there something wrong with this RFC 
that it should not be used for a CoA? If so, why is 
it allowed in other cases?

Hesham

---

From: [email-masked]
Date: Fri, 9 May 2003 11:38:07 +0200

[email-masked] wrote:

> => DAD is about problem (mainly from human errors)
> avoidance, DAD is NOT a security tool therefore it
> has not to be 100% reliable.

I agree that DAD is not a security tool.

I understood that  DAD was a tool to bring/keep the network
operational. It was from this point of view of operational robustness
that I was a bit amazed...

Regards,
Robert

---

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

Good move sir.  Or this will hold up MIPv6 yet again.  
/jim

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, May 07, 2003 4:01 PM
> To: Bound, Jim
> Cc: [email-masked]
> Subject: Re: Avoiding interface failure upon DAD failure
> 
> 
> Jim Bound wrote:
> 
> This is what I will do, unless IPv6 WG supports the proposed text.
> 
> --Jari
> 
>

---

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

but the default is fail the interface from IETF standards perspective
and Francis suggestion is good implementation deployment policy.  This
way MIPv6 move forward.
/jim

> From: Francis Dupont [mailto:[email-masked]] 
> Sent: Thursday, May 08, 2003 10:15 AM
> To: Bob Hinden
> Cc: Jari Arkko; [email-masked]; Erik Nordmark
>  In your previous mail you wrote:
> 
> => in general I agree with you but I have a comment about a detail:
>    
>    ... In my view the cost of doing DAD is much higher than benefit.
> 
> => my concern is the cost and the benefit can be for two 
> different persons, i.e., I have no objection about a "no-DAD" 
> policy if and only if the choice between this policy and the 
> standard one is in the hands of the network manager.
>    
> Thanks
> 
> [email-masked]
> 
> PS: DAD is not a toy: at least once it spared us a 
> disaster... If something really needs improvement in RFC 
> 2461/2462, it is more how to cleanup everything when a 
> router's sent some rogue RAs.