Subject: Re: Re: DAD in node requirements draft

From: "" <[email-masked]>
Date: Sun, 23 Mar 2003 12:29:39 -0800

> 	for link-local address RFC2472 exception makes sense, but for others

> 	it does not.  i'd say keep node-req text as is.

> itojun

Hmm.. OK, let's see what RFC2472 has to say about this:

"
   As long as the Interface Identifier is negotiated in the IPV6CP phase
   of the PPP connection setup, it is redundant to perform duplicate
   address detection as a part of the IPv6 Stateless Autoconfiguration
   protocol [3].  Therefore it is recommended that for PPP links with
   the IPV6CP Interface-Identifier option enabled the default value of
   the DupAddrDetectTransmits autoconfiguration variable [3] be zero.
"

And what RFC2462 has to say:

"   For safety, all addresses must be tested for uniqueness prior to
   their assignment to an interface.  In the case of addresses created
   through stateless autoconfig, however, the uniqueness of an address
   is determined primarily by the portion of the address formed from an
   interface identifier.  Thus, if a node has already verified the
   uniqueness of a link-local address, additional addresses created from
   the same interface identifier need not be tested individually
"

In a PPP link the host autoconfigures the addresses (link/global) based on IID and Prefix configured/advertised by the AR. If the AR does not add IID config option in IPv6CP, the host can use it's unique link-layer ID if required (note that otherwise autoconfiguration stops). Besides the AR and the host there is no one on the link. Therefore running DAD (NS/NA) for any autoconfigured address (including autoconfigured global) is redundant for the point-to-point link, IMHO.

Please explain why running DAD for an autoconfigured non-link local address based on IID received from IPv6CP and prefix received from RA makes sense to you.

Regards,
Kuntal

--------------------------------------------------------------------
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: [email-masked]
Date: Tue, 25 Mar 2003 11:27:39 +0900

>Please explain why running DAD for an autoconfigured non-link
>local address based on IID received from IPv6CP and prefix received
>from RA makes sense to you.

	it makes more sense when rules are simpler.  if you always perform DAD
	you can always ensure there's no duplicate.  even if machine A is
	autoconfigured with prefix P::/64 and DAD-safe link-local address
	fe80::ID, the other end could configure P:ID intentionally.

itojun

---

From: Mika Liljeberg <[email-masked]>
Date: 25 Mar 2003 20:43:07 +0200

> 	fe80::ID, the other end could configure P:ID intentionally.

It would be more efficient to always do DAD with the link-local prefix
rather than full address, and just ensure that each IID is owned by a
single machine. I.e., if you configure P:ID, do dad with FE80:ID (unless
already done) and defend all X:ID.

	MikaL

---

From: Ole Troan <[email-masked]>
Date: Tue, 25 Mar 2003 18:55:51 +0000

Mika,

> already done) and defend all X:ID.

sure, but that wouldn't allow different nodes using the same IID with
different prefix. note the mechanism is called DAD not DIID. this has
been discussed to death numerous times, please refer to the archive.

/ot

---

From: Mika Liljeberg <[email-masked]>
Date: 25 Mar 2003 21:07:48 +0200

On Tue, 2003-03-25 at 20:55, Ole Troan wrote:
> different prefix.

This is not recommended, anyway.

>  note the mechanism is called DAD not DIID. this has

I know. Means people still disagree about it.

	MikaL

---

From: Soohong Daniel Park <[email-masked]>
Date: Wed, 26 Mar 2003 16:27:25 +0900

The efficiency depends on operator policy.
Sometimes we have to perform the DAD with all addresses.

	Daniel

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Mika Liljeberg
Sent: Wednesday, March 26, 2003 3:43 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: DAD in node requirements draft

	MikaL

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 26 Mar 2003 20:42:33 +0900

>I know. Means people still disagree about it.

	how can you prevent random other node to assign P::X (which you are
	using and verified fe80::X by DAD) on the interface?  DIID does not
	work in practice.

itojun

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 26 Mar 2003 09:40:05 -0800

Hello Itojun,

>    using and verified fe80::X by DAD) on the interface?  DIID does not

That's not supposed to happen, because the other node would
be prevented from autoconfiguring the corresponding link-local
address.

Perhaps you are suggesting that bad things can happen if
nodes do not do DAD, or exhibit some other protocol violation.
In that case I would agree with you, but I don't think that
is a suitable basis for making such decisions.

I am in the group that believes DIID is a (far!) better
solution.   It is certainly more scalable, and it retrieves
for our future benefit the ability to use many routing prefixes
on the same link.

Regards,
Charlie P.

---

From: Mika Liljeberg <[email-masked]>
Date: 26 Mar 2003 19:58:36 +0200

On Wed, 2003-03-26 at 13:42, Jun-ichiro itojun Hagino wrote:
> 	using and verified fe80::X by DAD) on the interface?

If X is a new ID for the other node, it would have to do DAD with
fe80::X. If the node alrady owns X, it could skip the DAD.

In any case, I defend my id X against all possible prefix::X, so the
other node will no be able to take it no matter what prefix it uses.

>   DIID does not	work in practice.

It does work if everyone follows the same rules.

Besides, if you do DAD for every address, a new prefix appearing in a RA
will cause a DAD storm as every node on the link will attempt to
configure a new address at the same time.

	MikaL

---

From: Greg Daley <[email-masked]>
Date: Mon, 31 Mar 2003 12:45:26 +1000

Hi Mika,

just a quick comment on DAD-storms below.

> configure a new address at the same time.

This sounds just like the many-nodes-moving issue in MIPv6
which we're working on in mobile-ip.

Current 2462/1 policy causes a delay of 0-1000ms for each DAD
packet. So while there may be a storm, it shouldn't affect
L2.

Additionally, EUI-64 based addresses are only one of a set of
available addresses now, with rfc3041 and CGA based addresses
being possible.  In these cases (manditorily in CGA) different
suffixes are required for each address (local, global scope), so
there is no gain from doing DIID.  With 3041 addresses, we're still
likely to see an additional EUI-64 based address for local comms
anyway.

I'd make the guess that at least 3041 addresses and possibly CGA-like
addresses will be prevalent as IPv6 adoption continues.

Greg

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 1 Apr 2003 08:53:09 +1000

[Dang!  I'd missed this thread under a pile of site-local discussion]

> be prevented from autoconfiguring the corresponding link-local

So long as all nodes DAD for fe80::X before using Y::X, indeed.
And it seems to me that it's unsafe to do this any other way,
since there's plenty of stuff around doing "DIID".  On the 
other hand, the 3041 and CGA people are probably wondering why
they have to check this silly fe80::X first! 

I myself am happy to go with whichever solution causes least
harm ...

> nodes do not do DAD, or exhibit some other protocol violation.

Such as Optimistic DAD?  I started on draft-moore-ipv6-optimistic-dad
shortly after Yokohama, where I got the impression that DIID
was on the way out.  It's easily retrofitted to the DIID way of 
thinking, Ed Remmell did this in his implementation.

I'm interested in hearing the thoughts of the group ...

cheers,
	Nick
-- 
Nick 'Sharkey' Moore  <[email-masked]>  <http://zoic.org/sharkey>

---

From: Mika Liljeberg <[email-masked]>
Date: 01 Apr 2003 07:48:09 +0300

Hi Nick,

> [Dang!  I'd missed this thread under a pile of site-local discussion]

;-)

> they have to check this silly fe80::X first! 

Well, they have to do either DAD or DIID anyway. I don't see why they
should care which.

> I myself am happy to go with whichever solution causes least

The safe way, in my opinion, is for all nodes to defend their IDs
against both DAD and DIID, regardless of which approach they use
themselves. I.e., always respond to both fe80::X and P::X.

This way DAD and DIID can happily coexist on a network. Nodes that want
the benefits of a unique ID can do DIID. Nodes that want to share an ID
can do DAD. The DAD vs DIID behaviour could even be configurable per
interface.

> was on the way out.

I sure hope not. I don't think we will be changing our implementation,
unless DIID becomes expressly forbidden by a future standards track RFC.
I would be .. somewhat opposed to that.

>   It's easily retrofitted to the DIID way of 

For reasons of efficiency, DIID would seem to make more sense for mobile
nodes.

	MikaL