Subject: DAD vs. DIID

From: "Nils Agne Nordbotten" <[email-masked]>
Date: Tue, 23 Jul 2002 14:31:44 +0200

Hello,

I would appreciate it if anyone could inform me of the outcome of the DAD vs. DIID discussion in Yokohama. The meeting minutes are not available at playground.sun yet.  

Regards
Nils Nordbotten

---

From: Ole Troan <[email-masked]>
Date: Tue, 23 Jul 2002 14:08:08 +0100

> I would appreciate it if anyone could inform me of the outcome of
> the DAD vs. DIID discussion in Yokohama. The meeting minutes are not
> available at playground.sun yet.

consensus in the room was for DAD.

there was also a discussion whether DAD should be done only on
manually configured addresses, and not on MAC address derived and
random ones. no consensus in the room. Erik Nordmark suggested
"optimistic DAD", but there was no time to discuss it.

optimistic DAD looks to me to be a good compromise.

cheers,
Ole
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Thu, 25 Jul 2002 10:11:54 +0200

In your previous mail you wrote:

=> it should be very fine to get an official position about this.

   
=> I disagree because the damage can be too great: I prefer
collision avoidance to collision detection...
As I explained in an old thread about this kind of issues,
the choice for optimistic DAD *must* be in the hands of the network
manager (i.e., the guy who will be in trouble if the very unlikely
event happens).

Regards

[email-masked]

---

From: Brett Pentland <[email-masked]>
Date: Fri, 26 Jul 2002 12:52:01 +1000

I admit I don't have a good feel for just how bad the consequences of a
collision are, but allowing the network manager to choose not to allow
optimistic DAD seems like a reasonable position.  In this case the
manager needs an easy way to be able to stop hosts from doing optimistic
DAD (or to be able to allow it depending on the default).  Perhaps a
flag could be added to the Router Advertisement messages to control this
behavior?

Regards,
Brett.

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 27 Jul 2002 04:17:39 +0200 (CEST)

> "optimistic DAD", but there was no time to discuss it.

I hope I merely suggested that "optimistic DAD" be explored to better
understand the issues and benefits.

> optimistic DAD looks to me to be a good compromise.

A possible implication of optimistic DAD (i.e. where an address is assigned
to the interface and used before it is known whether it is a duplicate) is
that
 - neighbor caches in order nodes will have the wrong information and need
   to be switched back to the correct, original information once DAD fails.
 - TCP connections might be reset (a packet arrives at the new node, which
   doesn't have the TCP state so it sends a reset; the real "owner" of the
   address has the TCP state)

  Erik

---

From: [email-masked]
Date: Mon, 29 Jul 2002 11:25:54 +0900

>   address has the TCP state)

	for this reason, i'm not a fan of optimistic DAD.  my preference
	is to run full DAD (will take 1 second or so), for every address
	assigned to the node.  the rule is simple - run it for every address
	you assign to the node, that's all.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Mon, 29 Jul 2002 07:09:37 +0300 (EEST)

> 	you assign to the node, that's all.

Wouldn't it be much much simpler just to do DIID?  I see zero reason for 
e.g. PRFX1::1/64 and PRFX2::1/64 being assigned on two different nodes in 
a same subnet.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: [email-masked]
Date: Mon, 29 Jul 2002 13:20:43 +0900

>e.g. PRFX1::1/64 and PRFX2::1/64 being assigned on two different nodes in 

	i see zero reason for prohibiting the above configuration.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Mon, 29 Jul 2002 07:25:53 +0300 (EEST)

> 	i see zero reason for prohibiting the above configuration.

But you agree that the above configuration is very rare, really just a 
"corner case".  Someone _might_ want it though.

Perhaps this behaviour should be configurable then?

If enabled (default), perform DIID only [and possibly skip for EUI64
addresses].  This is useful in scenarios where there is a large number of
addresses assigned in the nodes.

If disabled, perform DAD for every address without any optimizations.

---

From: Robert Elz <[email-masked]>
Date: Mon, 29 Jul 2002 14:06:58 +0700

Date:        Mon, 29 Jul 2002 07:25:53 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | On Mon, 29 Jul 2002 [email-masked] wrote:
  | > >Wouldn't it be much much simpler just to do DIID?  I see zero reason for 
  | > >e.g. PRFX1::1/64 and PRFX2::1/64 being assigned on two different nodes in 
  | > >a same subnet.
  | > 
  | > 	i see zero reason for prohibiting the above configuration.

Nor do I.

  | But you agree that the above configuration is very rare, really just a 
  | "corner case".  Someone _might_ want it though.

I don't agree with the first sentence there, I think I'm (a) someone...

  | Perhaps this behaviour should be configurable then?

That makes no sense.

  | If enabled (default), perform DIID only [and possibly skip for EUI64
  | addresses].  This is useful in scenarios where there is a large number of
  | addresses assigned in the nodes.
  | 
  | If disabled, perform DAD for every address without any optimizations.

The problem is that you have to know what is enabled/disabled on every other
node on the link as well.   So, this would need to be yet another RA
parameter (and there'd have to be some rule on what was permitted when
there is no router in that case).

It really is simpler just to always do DAD.

On optimistic DAD - maybe I misunderstood what Erik was suggesting, but
I assumed the "optimistic" wouldn't be "irrational" .. that is, for
optimistic DAD, which I think I'd certainly not object to (though I'm also
not sure the actual cost of full DAD is enough for it to matter) I'd
assumed the idea would be to send the first DAD NS, and wait for a reply,
and if no reply came to that one, assume the address is OK, while 
simultaneously going on and doing the rest of the DAD procedure (killing
the address if it fails).  That more or less cuts the DAD delay by 2/3 (but
it doesn't eliminate it).

This relies upon NS/NA failure being very rare (so it might be something that
you'd do on fairly reliable links, and not on ones known to have greater
packet losses).   That is, if there is another (operational) user of the
address, they're almost always going to reply to the first NS for their
address (whether or not it is for DAD purposes).   That is certainly in
line with my experiences with ARP.

kre

---

From: Francis Dupont <[email-masked]>
Date: Mon, 29 Jul 2002 10:36:45 +0200

> 	i see zero reason for prohibiting the above configuration.
   
=> I should say I agree with Itojun...

=> IMHO the worse solution is to get a mix of DAD and DIIDD (as today).
DAD had the majority at the meeting and is straightforward to implement
so we should fix inconsistencies in current specs (including mobile IPv6
one).

Regards

---

From: Markku Savela <[email-masked]>
Date: Mon, 29 Jul 2002 13:33:35 +0300

> From: [email-masked]

Then, I would like to have some consideration on how to behave in the
following situation:

 - I've 3 prefixes and 3 ids, thus I have total of 9 addresses DADded.

 - I receive 4th prefix, => I do a DAD for 3 new addresses. Do I do
   them in parallel or do I have to do them one after another? 

 - I configure a new additional ID => I do a DAD for 4 new addresses. Do I do
   them in parallel or do I have to do them one after another? 

Apparently, KAME is not able to configure multiple plain IDs to be
combined freely with all announced prefixes? Or can it?

---

From: [email-masked]
Date: Mon, 29 Jul 2002 19:38:53 +0900

>   them in parallel or do I have to do them one after another? 

	you can do them in parallel.

itojun

---

From: "Nils Agne Nordbotten" <[email-masked]>
Date: Mon, 29 Jul 2002 12:53:16 +0200

> you assign to the node, that's all.

While this is simple in traditional LANs I'm worried about the consequences
in networks like Bluetooth scatternets where devices in power saving modes
will have to be waked up. I also imagine there easily will be partitions in
such networks, and that DAD therefore will provide little assurance. Instead
address uniqueness could be assured from EUIs.

Regards
Nils Nordbotten

---

From: Francis Dupont <[email-masked]>
Date: Mon, 29 Jul 2002 14:11:00 +0200

=> it is uncommon to have 3 ids (usually there are only one or two)...

=> in parallel of course.

    - I configure a new additional ID => I do a DAD for 4 new addresses.
      Do I do them in parallel or do I have to do them one after another? 

=> idem.

=> I believe KAME has a notion of "the" id of the interface.
This should be discussed on the KAME list.

---

From: Francis Dupont <[email-masked]>
Date: Mon, 29 Jul 2002 14:18:17 +0200

=> I have no concern about the last statement. The problem with (too)
optimistic DAD is to fail to detect a collision before the damage and
when there are duplicated EUIs the damage is already very great.
This is why I proposed to use IMEIs for mobile phones which have no
IEEE devices so no EUIs but still have a globally unique hardware number.
PPP is another case where DAD can be forgotten.

Regards

---

From: Robert Elz <[email-masked]>
Date: Mon, 29 Jul 2002 21:14:50 +0700

Date:        Mon, 29 Jul 2002 12:53:16 +0200
    From:        "Nils Agne Nordbotten" <[email-masked]>
    Message-ID:  <014001c236ee$24fecd30$8cb9d8c1@nansb>

  | While this is simple in traditional LANs I'm worried about the consequences
  | in networks like Bluetooth scatternets where devices in power saving modes
  | will have to be waked up.

If the hardware is rational (a topic about which I know nothing at all,
it might not be, but perhaps if pressed, it will improve) the devices
won't need to wake up.   Remember ND (including DAD) is not ARP, packets
aren't broadcast, they're multicast, and to a multicast address which
will normally only have as members of the same multicast group nodes
sharing the same IID.    If you're one of the believers of "no IID sharing"
then doing DAD instead of DIIDD won't change that, and usually, there will
be no other members of the group than the node which is doing DAD.
The DAD packets consume an (insignificant) amount of bandwidth, but
when all is working properly, go nowhere at all.

  | I also imagine there easily will be partitions in
  | such networks, and that DAD therefore will provide little assurance.

If partitions are common (aside: why would anyone use a link where the
chances of not being able to talk to any other random node on the link,
like the router, or fileserver, ... are not negligible??) then sure,
DAD won't provide a lot or protection, but DIID would provide even less,
as less probes are done.   At least with DAD, you have a better chance of
some of your addresses being detected as duplicates, which will start waving
the red flags.

  | Instead address uniqueness could be assured from EUIs.

If EUIs are being used to form the addresses, then duplicates should
be very very rare, and all DAD really achieves in the usual case is a little
bandwidth consumption and a small delay.   But it does no harm either.

kre

---

From: Pekka Savola <[email-masked]>
Date: Tue, 30 Jul 2002 07:33:07 +0300 (EEST)

> I don't agree with the first sentence there, I think I'm (a) someone...

I'd like to hear what kind of network configuration you have in mind.
 
> It really is simpler just to always do DAD.

I agree this is a problem :-(.
 
> it doesn't eliminate it).

My main point is just that one should be able "optimize" DAD somehow if
there are long latencies involved (e.g. serialized full DAD is
unacceptable with many addresses).  How, that's another issue.  Else folks
that need to optimize it will do so anyway.

---

From: Robert Elz <[email-masked]>
Date: Tue, 30 Jul 2002 14:07:12 +0700

Date:        Tue, 30 Jul 2002 07:33:07 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | > I don't agree with the first sentence there, I think I'm (a) someone...
  | I'd like to hear what kind of network configuration you have in mind.

One obvious one is when I have two links, and have assigned pfx1::1 to
my favourite node on one of them, and pfx2::1 to my favourite (different)
node on the other, and then I decide to merge the links into one.  Applying
both prefixes to the link is easy, so I shouldn't have to renumber anything
just because of this (pyhsical) change (maybe a temporary one caused by
the death of a switch, while waiting upon a replacement - assuming I'm
too cheap to buy switches that support vlans...).   But now I have two ::1's
on the one link.

  | My main point is just that one should be able "optimize" DAD somehow if
  | there are long latencies involved (e.g. serialized full DAD is
  | unacceptable with many addresses).  How, that's another issue.  Else folks
  | that need to optimize it will do so anyway.

N different DAD's (that is for different addresses) on one link should
complete in the time it takes to do one DAD (that is, for one of those
addresses), plus noise (the time it takes to transmit the other N-1
packets).   Doing DAD for all of the addresses consumes some bandwidth,
it has no other noticeable effect (or should have) on the node that is
performing the DAD.

Certainly there will be two DAD delays when a node boots - the first to
get its LL addr, and then one more, for all of the other addresses it
creates after it has received the RA (in all of that, I'd actually expect
the random wait before sending the RS, if no RA just "happens", to be the
biggest source of delay to a booting node).   But the number of addresses
it has on the link (LL, SL, or global) should not materially affect
anything.

An implementation that has N addresses ready to verify, so does DAD on
the first, then after that is complete, DAD on the second, etc, would be
just too cheap to consider for anything real (on the other hand, for some
applications where human patience isn't an issue, that might be OK).

kre

---

From: Markku Savela <[email-masked]>
Date: Tue, 30 Jul 2002 11:39:40 +0300

> X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to [email-masked] using -f
> From: Robert Elz <[email-masked]>

> too cheap to buy switches that support vlans...).   But now I have two ::1's

But, even with DAD, you will have problems. You are announcing pfx1
and pfx2 on the same link. Thus, because both nodes have id=1

- both nodes will try to configure now pfx1::1 *AND* pfx2::1 and
  collide each other.

- both nodes can now validly try to configure fe80::1, and collide on
  that

- if a new pfx3 is announced, both nodes will collide on "pfx3::1"

I'm not saying above is bad situation. It does require implementation
to keep track of each combination, to remember wich prefix/id
combinations have collided (or it has to keep a separate list of
collided addresses, so that it doesn't try to reuse those combinations
later).

With DIID, you can remove the collided ID, and it will not be used.

Of course, implementations can be more complicated: at least I have
possibility to use "atomic" address, which will allow me to use
"pfx1::1", even if id=1 is removed. You configure prefix, id or atomic
address.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 30 Jul 2002 10:57:21 +0200

> too cheap to buy switches that support vlans...).   But now I have two ::1's
   
   But, even with DAD, you will have problems.

=> I have no problem...

   You are announcing pfx1 and pfx2 on the same link.
   Thus, because both nodes have id=1
   
=> no, they have ids=something and addresses=pfx1::1 and pfx2::1

=> not if they don't try to configure all ids with all prefixes.

=> idem.

=> idem.

=> obviously your assumptions about how the autoconf works are not shared.

=> with DAD, there is no notion of collided ID, only of collided addresses.
IMHO the confusion comes from the current mixture of DAD and DIIDD.

Regards

---

From: Markku Savela <[email-masked]>
Date: Tue, 30 Jul 2002 12:54:47 +0300

> From: Francis Dupont <[email-masked]>
> 

IPv6 addressing architecture defines the process of combining prefixes
and ids. Nothing in the RFC's prevents taking the interpretation I
presented. It's correct, and perhaps a useful feature.

> => with DAD, there is no notion of collided ID, only of collided
> addresses.  IMHO the confusion comes from the current mixture of DAD
> and DIIDD.

Well, right. Did I say anything else? This is discussion about two
choices (1) do DAD, (2) require the ID part be unique (only one node
can use) on the link.

The current autoconf is basicly DAD. I just dared to propose that
perhaps unique ID approach might be better solution.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 31 Jul 2002 02:05:01 +0900

>>>>> On Mon, 29 Jul 2002 14:11:00 +0200, 
>>>>> Francis Dupont <[email-masked]> said:

> => I believe KAME has a notion of "the" id of the interface.

No, KAME's implementation does not have such a notion, at least not
explicitly.  So, basically Markku is correct.

> This should be discussed on the KAME list.

I agree, if we need more discussion on this particular topic, perhaps
we'll have to change the place.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[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]
--------------------------------------------------------------------