Subject: Avoiding interface failure upon DAD failure

From: Jari Arkko <[email-masked]>
Date: Mon, 05 May 2003 15:56:19 +0300

Hi,

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

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:

    7.6 Avoiding Failures from Duplicate Addresses

    Upon failing Duplicate Address Detection, [13] requires IPv6 nodes to
    stop using the address and wait for reconfiguration.  In addition, if
    the failed address was a link-local address formed from an interface
    identifier, the interface should be disabled.

    Mobile nodes that wish to avoid this situation MAY use temporary
    link-local addresses as follows.  The mobile node SHOULD generate a
    random interface identifier and use it for assigning itself a
    link-local address for use on this link.  In order to do this, the
    mobile node applies to the link-local address the procedure described
    in RFC 3041 [18] for global addresses.  At most 5 consecutive
    attempts SHOULD be performed to generate such addresses and test them
    through Duplicate Address Detection.  If after these attempts no
    unique address was found, the mobile node SHOULD log a system error
    and give up attempting to find a link-local address on that
    interface, until the node moves to a new link.

And now to the questions for the IPv6 WG: Is this (a) appropriate and
(b) in line with RFC 2462 and other possible RFCs?

--Jari

--------------------------------------------------------------------
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: Pekka Savola <[email-masked]>
Date: Tue, 6 May 2003 22:31:50 +0300 (EEST)

> (b) in line with RFC 2462 and other possible RFCs?

The intent seems rather reasonable to me.

The first two sentences of the second paragraph seem slightly ambiguous to 
me:

     Mobile nodes that wish to avoid this situation MAY use temporary
     link-local addresses as follows.  The mobile node SHOULD generate a
     random interface identifier and use it for assigning itself a
     link-local address for use on this link. 

==> why a 'SHOULD'?  Would and alternative be to just use the same address 
which collided (as with the previous versions of the spec)?

It seems to me that this might be written a bit differently, like:

     Mobile nodes that wish to avoid this situation MAY use temporary
     link-local addresses by generating a
     random interface identifier and using it for assigning itself a
     link-local address for use on this link. 

As another issue:

                                              At most 5 consecutive
     attempts SHOULD be performed to generate such addresses

Does this intend to say that implementetations SHOULD do consecutive 
attempts?  I don't agree that it's necessary, RFC3041 are very random, 
and if there is a collision, something is very wrong.  Or that 
implementations SHOULD NOT perform more than 5 attempts? (A very 
reasonable thing to say.)

Depending on the intent, the sentence could be rephrased slightly.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Jari Arkko <[email-masked]>
Date: Tue, 06 May 2003 22:46:44 +0300

> The intent seems rather reasonable to me.

Great.

>      link-local address for use on this link. 

Sounds very good. The existing text indeed uses strangly MAY and
then a SHOULD.

> reasonable thing to say.)

The latter. Rephrased. Thanks.

--Jari

---

From: Bob Hinden <[email-masked]>
Date: Wed, 07 May 2003 10:54:59 -0700

Jari,

>by a malicious act. (SEND WG will eventually solve the

It seems to me that the likelihood a duplicate being detected using 
auto-configured addresses is very very small.  If it does happen it 
indicates that something is broken.  This could be hardware or software.

Drastic action is appropriate because, assuming the link-local address was 
created using the hardware mac address, the same MAC address is going to be 
used at the link layer.  If it is really a duplicate then link layer 
communication will fail.  Changing the IPv6 address (i.e., a different IPv6 
link-local address), won't have any effect.  The only remedy is to try a 
different link layer address.

>    interface, until the node moves to a new link.

Does this deal with picking different physical link layer addresses?

>(b) in line with RFC 2462 and other possible RFCs?

I think that doing DAD at all with auto-configured and temporary addresses 
isn't very beneficial due to the very low probability that a duplicate will 
be detected.  In my view the cost of doing DAD is much higher than 
benefit.  I think this is something the working group should discuss.

However, due to this very low probability of a real duplicate occurring, 
when a duplicate is detected, it indicates that something is very 
broken.  Consequentially, I am skeptical that the above mechanisms will 
really fix the problem.

Bob

---

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

Bob Hinden wrote:

> Drastic action is appropriate because, assuming the link-local address 
> was created using the hardware mac address, the same MAC address is 
> going to be used at the link layer. 

I agree, but the proposal was to use randomly generated link-local
addresses, hence the MAC address was not used.

> I think that doing DAD at all with auto-configured and temporary 
> addresses isn't very beneficial due to the very low probability that a 
> duplicate will be detected.  In my view the cost of doing DAD is much 
> higher than benefit.  I think this is something the working group should 
> discuss.

I agree. That is something that the IPv6 WG might look at in some
point. But our proposal does not propose changes to DAD, it follows
current RFCs. It simply proposes the use of an RFC 3041 like
mechanism for the generation of link-local addresses independent
of the MAC address. Given that we are not using the MAC address,
2462 rules do not call for disabling the interface. Of course,
you could view this as an end-run as Jim did...

> broken.  Consequentially, I am skeptical that the above mechanisms will 

This is good point. Let's discuss this in some more depth. Here are
the potentially guilty parties:

   (a) THIS node. In that case disabling the interface
       seems like the right thing to do.

   (b) OTHER node. Say, a broken network component responds to all
       DAD queries. In that case disabling the interface due to a
       visit to this link hurts, and it hurts on all subsequent links
       as well.

Which one is more important? Hard to say... I also can't estimate
what effect, if any, would a tough disabling rule have on the
faulty nodes, would they be less likely to exhibit bad behaviour?
You could also claim that the disable-until-the-admin-arrives
approach serves as a useful warning sign that something is
wrong either in this or the other node.

But still, our proposal appears to build some resilience to the
system (not fail forever, only on this link). It also appears to
follow 2462, or?

Comments?

--Jari

---

From: Greg Daley <[email-masked]>
Date: Thu, 08 May 2003 10:01:01 +1000

Hi Bob,

just some comments about MAC Collision & DAD optimizations

Bob Hinden wrote:
> going to be used at the link layer.  If it is really a duplicate then 
> link layer communication will fail.  Changing the IPv6 address (i.e., a 
> different IPv6 link-local address), won't have any effect.  The only 
> remedy is to try a different link layer address.

In the situation which you mention, the configuring node
has received a successful DAD defence from the existing node,
before either de-configuring the interface, or re-attempting
DAD.

This is regardless of the fact that the node which sent the
DAD defence (if it was not a DAD proxy) was able to send the
response itself, although the MAC was duplicated.

If there is some more sinister issue with link-layer
communication when the MAC addresses collide, then the orignal
DAD defence would not have succeeded. (This is this
possibility even on the first DAD attempt).

It is straight-forward for the configuring node to
inspect the source link-layer address option in the
successful DAD defence NA to check whether the MAC advertised
is the same as that of the configuring node.

If this is the case, the node should deconfigure the interface.
If the SLLAO indicates a different MAC, then I think that
deconfiguring the interface is not called for, as it isn't
likely that the configuring node's further attempt is
going to cause problems.

> higher than benefit.  I think this is something the working group should 

There are several optimizations which have been proposed
regarding DAD, which reduce the cost of DAD testing.
I'm not sure that discarding DAD is the right approach.

Greg Daley

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 May 2003 16:51:30 +0300

> likely that the configuring node's further attempt is

Sounds reasonable.

However, I'm trying to figure out what, if anything,
the Mobile IPv6 specification should say about this.
Process-wise, the behaviour that you propose i.e. a
change to the DAD behaviour belongs to the IPv6 WG.
I'm not going to change DAD -- the only options available
for me are (a) not saying anything or (b) recommending
a particular type of an address [temporary] be used
so that the implications of DAD failure are not as
severe. Both are imho within bounds of the current
RFCs, but Jim talked about an end-run and Bob didn't
see this solving the real problem in the rare case
of a collision.

The issue is not so important that it justifies a very
lengthy discussion, imho, and I will delete the text
unless it is supported here. 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.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 May 2003 16:15:07 +0200

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.
--------------------------------------------------------------------
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: Jari Arkko <[email-masked]>
Date: Thu, 08 May 2003 17:29:00 +0300

> the hands of the network manager.

I may agree with the above, but we seem to be departing
the original discussion: If someone wants to work on
improvements to DAD, or even eliminating DAD from temporary
addresses, that's something for them to drive.

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.

--Jari

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 08 May 2003 08:37:03 -0700

Hello Jari,

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 8 May 2003 21:25:39 +0300 (EEST)

> view of what is best for the users.

Why do you believe there will be DAD conflicts?

If the nodes use EUI64-based addressing, this should really, really, never
happen -- UNLESS someone is acting in a malicious manner on the link; and
in that case this proposal does not work, just adds complexity.

The simplest would be just to log an error, and disable the interface.

A MIPv6 specific interpretation of the latter could be ", until the MN
moves on to a new link when DAD can be re-tried".  This would also seem
reasonable IMO.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 08 May 2003 11:35:58 -0700

Pekka Savola wrote:
> UNLESS someone is acting in a malicious manner on the link; 

this is what we are concerned about.

the proposal makes it worthless for the malicious node to launch
an attack.

Vijay

---

From: Pekka Savola <[email-masked]>
Date: Thu, 8 May 2003 21:37:32 +0300 (EEST)

> the proposal makes it worthless for the malicious node to launch

Incorrect.  The malicious node can just reply to the RFC3041 DAD's up to 5
times, and then the interface will get disabled anyway.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 08 May 2003 11:40:25 -0700

Hello Pekka,

> Why do you believe there will be DAD conflicts?

Actually, I do not believe there will be conflicts
according to your use scenario.  But IPv6 isn't
supposed to be usable for only those scenarios.
If a node picks a random link-local address, it
should be able to use it as long as their are no
conflicts.  If such a node then moves to a new
link, there is a very small possibility of a conflict.

In that case, the newly arrived mobile node ought to
pick another address without making the device owner
curse and swear and do the <ctl-alt-delete> thing.

> A MIPv6 specific interpretation of the latter could be
> ", until the MN moves on to a new link when DAD can be
> re-tried".  This would also seem reasonable IMO.

It's reasonable, unless the next link is 15 km ahead.

Regards,
Charlie P.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 May 2003 22:08:06 +0300

> moves on to a new link when DAD can be re-tried".  This would also seem

The proposal does not attempt to survive the situation on the link;
it follows the 3041 5-attempt scheme to avoid accidental collisions
and then stops. It simply puts in some additional resilience, by
making the failure of the interface not last forever.

So, it seems that we've tried to accomplish exactly what you
suggest above -- though in a slightly different way. I'd be
happy to do this in the above way, if the group finds that
acceptable. That is, we could have some text that says that
DAD failures per 2462 last only while we are on the same
link.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 May 2003 22:28:44 +0300

> times, and then the interface will get disabled anyway.

You are both right, in a way... Pekka is right that the malicious
node case is really not defensible, at least not until SEND
arrives.

However, Vijay's point is that such a situation should not disable
the device for ever. Say, when I get home from the office I happen
to drive by the All-DAD-Probes-Answered building and my device accidentally
attaches to its WLAN network, DADs, fails, and disables my interface. I
have just one interface, so before the "admin" fixes the problem
the device is useless. If I get an important message, I won't be
alerted, because its against the law to do an "ifconfig eth0 up"
while driving. (And if its my grandmother, she'll might take
the device to the shop for repair when something this unexpected
happens.)

Anyway, I don't think there's any point in spending too much
effort on this. There are activities to take care of ND attacks,
there are activities to look at DAD optimization. Either we
find that the RFC 3041 approach is OK for link-locals as well,
use Pekka's suggestion of resetting the failure when moving to
a new link, or just skip this and depend on future specifications
to deal with it.

--Jari

---

From: Mika Liljeberg <[email-masked]>
Date: 08 May 2003 23:20:33 +0300

> link, there is a very small possibility of a conflict.

Have you done a probability analysis on this? Is the probability of
interface failure due to address collision significantly higher than,
say, link failure due to problems in the radio propagation environment?
My gut feeling is, not even close.

	MikaL

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 May 2003 23:34:53 +0300

> My gut feeling is, not even close.

I think your gut feeling is right. (Although you could argue that
in some malicious case the probability could be 1; but I don't
want to enter a discussion which is mostly a SEND issue. Plus
with the exception of EMP, radio problems don't stay once you
move to a different place ;-) .)

Anyway, what should we do with the probabilities? Are you
saying that everything with a smaller probability than
radio problems should not be pursued?

Perhaps the argument is that the probability is neglible.
It is, I agree. Still, shouldn't we do the right thing
even if the probability of the bad thing happening is
very small?

--Jari

---

From: Mika Liljeberg <[email-masked]>
Date: 08 May 2003 23:51:44 +0300

> radio problems should not be pursued?

It's part of the cost-benefit analysis. If the probability of collision
is low enough not to be a significant factor in the total failure rate,
the user is not going to see any difference one way or the other. If
this is the case, the added implementation complexity is not warranted.

> even if the probability of the bad thing happening is

Only if the cost-benefit analysis makes sense.

	MikaL

---

From: "Youn-Hee Han" <[email-masked]>
Date: Fri, 9 May 2003 17:22:44 +0900

On the whole, the discussion about this subject comes 
to a conclusion as "May use RFC3041 to configure link-local
 address or global address (CoA)". Right? 

I also hate to make this discussion long, 
I would like to give my opinion about the probability of address collision.

> Only if the cost-benefit analysis makes sense.

Not all nodes and interfaces contain IEEE identifiers. In such 
 cases, an interface identifier is generated through some other 
 means (e.g., at random), and the resultant interface identifier is 
 not globally unique. 

Several guys think that DAD is far more likely to succeed than fail 
for even randomly auto-configured addresses. right?
However, such optimistic thought becomes valid only when randomly 
auto-configured addresses are truly random and they are distributed 
uniformly and globally. 

We can think an unfortunated case that two or more nodes use 
the same seed for random number generation. 
If the nodes meet in a link, the collision probability may be high. 
To think another example, let us assume that there is a series 
of links where a great quantity of IPv6  nodes exists 
and a node wanders about within the series of links. 
If the node generates its CoA randomly whenever moving to 
 one of the series, the probability of address collision may be high, too. 

The above cases occurs more frequently in the future, 
where more and more real-objects have their IPv6 address 
(please think about ubiquitous computing environment).

Comments?

--YH

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 May 2003 12:37:41 +0300

>  address or global address (CoA)". Right? 

I think so.

> the same seed for random number generation. 

You are right. RFC 3041 does bring this up in Section 3.2.2
and even references some documents on good random number
generation. This will help folks produce good implementations.
I'm sure it won't prevent some other folks from producing
bad implementations ;-( If there's anything positive in
that, maybe its the fact that such implementations are
much more likely to collide with another device of the
same kind than with the good implementations.

--Jari

---

From: Mika Liljeberg <[email-masked]>
Date: 09 May 2003 19:47:13 +0300

> auto-configured addresses are truly random and they are distributed 

Fair enough, but having a bad random number generator is no excuse for
retrying many times (with bad random numbers). The random number
generator should be fixed instead.

	MikaL