Subject: RE: DAD vs. DIID

From: "Brian Zill" <[email-masked]>
Date: Thu, 15 Aug 2002 20:37:16 -0700

Maybe a summary would help:

"DIID":
 - Nodes need to create a link-local address
   corresponding to every IID they use on a given
   link (and perform DAD on it).
 - Nodes don't need to perform DAD for non link-local
   address.
 - Multi-link subnet routers would have to defend
   link-local addresses across links, which could be
   considered confusing and nonsensical.

"DAD":
 - Nodes don't need to create otherwise unnecessary
   link-local addresses corresponding to the IIDs they
   use for temporary or public-key-derived addresses.
 - Nodes need to perform DAD on all their addresses.
 - No strange consequences for multi-link subnets.

As far as implementation complexity goes, it seems to me that "DAD" is
far simpler, since the rule is the same for all addresses and you don't
need to create extra addresses only used for doing DAD.

Regarding efficiency, I think it depends upon whether a node has more
prefixes or IIDs.  For nodes on a link with lots of prefixes, "DIID"
saves a little bandwidth by not having to do as much DAD.  For nodes
with lots of IIDs, "DAD" saves node resources related to configuring
twice as many addresses.  Offhand, I'd be tempted to give the edge to
"DIID" here, but since I've seen various creative proposals for using
large numbers of IIDs per node, it's not clear.  My machines generally
have more IIDs then prefixes.  But I think the numbers have to get
pretty significant in either case before these concerns begin to matter.

The multi-link subnet router issue is more clear.  "DAD" is a better
architectural fit.  Link-local addresses stay link-local and don't
become these quasi-subnet-local addresses that are unique across the
subnet but only reachable on-link.

My take: given that it appears the majority of implementations currently
do "DAD", and that "DAD" provides for a cleaner multi-link subnet
architecture, I think "DAD" is the better choice.

--Brian

--------------------------------------------------------------------
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: Markku Savela <[email-masked]>
Date: Fri, 16 Aug 2002 09:24:26 +0300

> From: "Brian Zill" <[email-masked]>
> 

Umm.. "majority of implementations"? What is this? How do you count
them? When was this tally performed.

Does each separate implementation count as one? Or, does the number of
nodes running the implementation affect the count? Or some other
weighing algorithm?
--------------------------------------------------------------------
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 16 Aug 2002 16:54:23 +0900

>>>>> On Thu, 15 Aug 2002 20:37:16 -0700, 
>>>>> "Brian Zill" <[email-masked]> said:

> architecture, I think "DAD" is the better choice.

(Aside from the point if multi-link subnet is a good thing or not), I
tend to agree your analysis and conclusion.

What is the "majority" can be controversial, but just for record, all
*BSDs (actually derived from a single codebase, KAME) always do DAD
for all addresses.  Also, by watching the discussion so far, there
seems to be no implementation except Markku's that can be called
"DIID".  At best, we saw implementations that enable the optimization
described in RFC 2462, which I don't call DIID in this context.

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 16 Aug 2002 09:15:36 -0700

Hello Brian,

I haven't studied the multi-link subnet draft.  But, in order
to be responsive to your note before taking that time...

>    considered confusing and nonsensical.

It seems to me that, if you allow two nodes on the same
subnet to share a link-local address, then you are really
starting to eliminate the usefulness of link-local addressing.

If I think about how a network protocol should work that
would use link-local addresses, I do not want that protocol
to know about the sub-network-layer structure of my network.
It seems to me that up until recently there was always
a (correct!) assumption that the addressability of
a "link" was co-terminous with the addressability
of the subnet using that link.  In other words, the
"link-local address" was equally well "subnet-local".
Breaking this characteristic suddenly puts "link-local
addresses" outside the scope of IP, since IP deals with
putting together subnets, not structures with finer
granularity.  This idea of having multiple identical
link-local addresses on the same subnet exposes IP
to a level of structure granularity for which it is
poorly equipped.

In summary, I think that the sub-network definition of
"link-local" address muddies the distinction between
network-layer addressing and layer-2 addressing, which
is a bad thing and to be avoided.

I would say that multi-link routers have to defend
link-local addresses across the network extent for which
they were defined, which is a subnet.

>  - No strange consequences for multi-link subnets.

     But I think the strange consequences are not at all strange,
     if one takes a layer-3 view of layer-3 addressing concept.

     Or, maybe there is a move to demote link-layer addresses
     to be sub-network concepts?

And, please don't forget the negative impact on home agent operation.

> need to create extra addresses only used for doing DAD.

But I have a rule which I think is better, for which DIID is far
simpler.  Rewording:

   As far as implementation complexity goes, it seems to me that "DIID" is
   far simpler, since the rule is the same for all addresses and you don't
   need to create extra protocol for coordinating all devices on a subnet.

The rule is that link-local addresses are unique on a subnet.  This
disambiguates nodes on a subnet from the perspective of network-layer
protocol, which is an appropriate function for a network-layer address.

> saves a little bandwidth by not having to do as much DAD.

Or, in the case I was discussing, a LOT of bandwidth at an important
time when responsiveness is important for the user experience,
if we get to the point of utilizing IPv6 capabilities for many 
subnet prefixes.  I'd like to keep that possibility open for the
future.

>                                                           For nodes

You are right.  And, in fact, my understanding of IID is that each on
gives another (real or virtual) _network interface_.  Since multiple
IIDs define multiple network interfaces, a remote node shouldn't be
able to tell whether or not different IIDs belong to the "same" node.

Nodes without a link-local address almost seem to not have a
(real or virtual) network interface.  That doesn't seem right
to me.   Maybe that is the flip side of an "unnumbered interface",
a sort of "extraneously-numbered  non-interface".

> subnet but only reachable on-link.

This would be wrong.  A link-local address SHOULD be reachable
over all parts of the subnet, and it would be the responsibility
of the multi-link subnet router to make it happen.  I don't think
"DAD" is a better architectural fit to the IP model of subnet
addressing, unless you are also willing to jettison the network-layer
significance of what "link-local" address was supposed to mean.

Regards,
Charlie P.