Subject: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?]

From: Margaret Wasserman <[email-masked]>
Date: Mon, 04 Mar 2002 02:57:47 -0500

Hi Hesham,

Thanks for the quick response.

>=> Then let's begin the discussions. The only reason
>for standardising the draft in the IPv6 WG was to make
>sure that we're doing the right thing. Otherwise an 
>informational RFC wouldn't have to go through the
>IPv6 WG or could have been replaced by a 3GPP spec.
>But since the competence is here, it is crucial
>that we get feedback.

That sounds good.  Let's begin the discussions...

I'll send separate threads for each issue.

>   > It is not my impression that the WG has reached consensus on some
>   > of the issues raised in this document, specifically:
>   > 
>   >          - Forbidding the use of DAD on some links
>
>=> DAD is not needed if address duplication is not
>possible. Since each terminal gets a unique
>/64 (as per the advice draft), and since all terminals
>are on p2p links, DAD would be a waste of BW.
>But please have a closer look and let us know 
>if something was missed. 

Address duplication is possible on point-to-point links, because
one end may choose an address that is already in use by the other
end.  I don't think that this is very likely, but it is possible.

However, making DAD optional (and advising against the use of DAD) 
on point-to-point links, is in direct conflict with RFC 2462,
which says:

"Duplicate Address Detection MUST take place on all unicast 
addresses, regardless of whether they are obtained through 
stateful, stateless or manual configuration..."

I don't think that we should publish an informational document that 
advises some implementors to do something that specifically
disagrees with a MUST requirement in a standards-track document.
If the standards-track document is broken, we need to fix it 
instead.

[Please note that I actually think that we should be able to 
disable DAD for some link types.  I made a proposal to that effect
several years ago, but my arguments didn't win the day.]

Margaret

--------------------------------------------------------------------
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: Mon, 4 Mar 2002 10:45:46 +0200 (EET)

> several years ago, but my arguments didn't win the day.]

I think DAD should be disableable for default for:
 - addresses generated randomly
 - addresses that are generated from e.g. EUI64 (this might be more prone 
to errors, e.g. manufacturing or "stupid" multi-port NIC's where every 
port has the same MAC address)

Most definitely not:
 - manually configured addresses

Because DAD is not a perfect (or even nearly so) solution anyway.

-- 
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: Francis Dupont <[email-masked]>
Date: Mon, 04 Mar 2002 10:28:06 +0100

=> I disagree for addresses using the explicitely negociated
interface IDs with in the first position the link-local addresses.

   
=> the point-to-point link is one case DAD is overkilling.
But as too many persons want to make DAD optional I agree
we have to be carefull. For instance we should ask that
all DAD stuff must get rough consensus in the IPv6 WG.
Another point is who makes the choice to avoid the DAD check:
my opinion is this must be the "link manager" (i.e. the manager
of the network where is the link).

=> I agree we have a procedural case at least.

=> so basically we agree!

Thanks

[email-masked]

PS: DAD is not a toy, at least one time I saw it saved us from a disaster.

---

From: Markku Savela <[email-masked]>
Date: Mon, 4 Mar 2002 11:50:58 +0200

> several years ago, but my arguments didn't win the day.]

Yes.

RFC-2462, "5.1.  Node Configuration Variables":

  DupAddrDetectTransmits = 0

 => DAD is disabled on link

So, no DAD is "conformant" too.

---

From: Francis Dupont <[email-masked]>
Date: Mon, 04 Mar 2002 11:00:27 +0100

=> I *strongly* disagree: even if the probability is small it is not zero.

=> I agree: if two boxes have the same hardware number the address
collision is no more than a detail.

   Most definitely not:
   
=> agree

=> DAD is not perfect but only the network manager should take the
decision to forget DAD in such or such situations. Of course this
implies the "DAD avoidance" is negociated by the link-layer before
(so PPP again is a good candidate for optional DAD).

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 4 Mar 2002 17:39:28 +0100 (CET)

> I think DAD should be disableable for default for:

Did you mean disabled?

> port has the same MAC address)

An interesting historic note is that the reason we embark on DAD
(back at the Stockholm IETF in the addrconf BoF/WG?) was becase even with
manufacturing derived NICs there had been cases where a bunch of NICs
had been shipped with the same MAC address in them.

The reasoning was that doing DAD once while configuring the address
seemed like a cheap approach to deal with a failure case that is
otherwise extremely difficult to trouble shoot.

Perhaps mobile IP and its need to configure a care-of-address in short time
has changed the notion that DAD is "cheap". But I don't think the difficulty
of trouble-shooting duplicate IP addresses as changed.

   Erik

---

From: "James Kempf" <[email-masked]>
Date: Mon, 4 Mar 2002 09:54:52 -0800

Margaret,

> If the standards-track document is broken, we need to fix it 

DAD has a substantial performance impact on handover if the
Mobile IPv6 care of address is changed. If the address provision
scheme is such that duplicate addresses are not possible, then
I believe it should be possible to disable it.

I agree that the change must be made in the standards-track document.
Perhaps we could quickly get a short document that describes when 
DAD can be disabled, so that the issue can be resolved as quickly
as possible. In the Mobile IPv6 specification, DAD is only a MAY.

            jak