Subject: RE: DAD vs. DIID

From: "Bound, Jim" <[email-masked]>
Date: Mon, 12 Aug 2002 22:41:31 -0400

Hi Margaret,

To the technical discourse below.

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Friday, August 09, 2002 12:05 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: DAD vs. DIID
> 
> 
> 
> Hi Robert,
> 
> >Though, it is not entirely clear to me why
> >the /subnet IID uniqueness rather than the /link
> >uniqueness makes the case of privacy addresses easier.
> 
> To ensure IID uniqueness on a link, a node that implements
> privacy addresses would need to generate a link-local 
> address for each randomly generated IID (in addition to the
> global address generated for privacy), perform DAD on
> that address, and maintain that address for the lifetime
> of the privacy address in order to respond to other nodes'
> DAD messages.

A global prefix can use the same link-local address EUI again.
I have to now go check but I think the only requirement is not duplicate the linklocal address but the EUI of that address can be reused by non-link-local addresses.
Why does this not solve the privacy issue?

thanks
/jim

> 
> If we only require IIDs to be unique within a subnet, 
> a node that implements privacy addresses will only need
> to generate the single privacy address and perform
> DAD for that address.
> 
> As currently document (prior to the discussed changes)
> the privacy document is incompatible, in this minor way,
> with the addressing architecture and the autoconfiguration
> documents.  We had two options for what to change:
> 
>          - Relax the uniqueness restriction in the 
>                  addressing architecture, and make
>                  a corresponding change to the 
>                  autoconfiguration document.
>          -OR-
>          - Modify the privacy address document to 
>                  require the creation and maintenance of
>                  link-local addresses, as described above.
> 
> We had a consensus within the room in Yokohama to choose
> the first option, and we are currently checking that
> consenus with the list.
> 
> 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]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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: "Bound, Jim" <[email-masked]>
Date: Tue, 13 Aug 2002 11:40:33 -0400

The code I wrote for T64 does the same.
/jim

> From: Markku Savela [mailto:[email-masked]]
> Sent: Tuesday, August 13, 2002 11:27 AM
> To: [email-masked]
> Cc: Bound, Jim; [email-masked]; [email-masked];
> [email-masked]
> > From: Robert Elz <[email-masked]>
> 
> > But it seems that there aren't actually any such 
> implementations, everyone
> > I have seen who has reported has said they do DAD on all 
> addresses before
> > configuring them.   The fact that everyone did that was one of the
> > motivations for the change.
> 
> Here I have to raise a hand. I wrote implementation that actually
> followed the allowed optimization: do DAD only on link-local, and then
> freely combine that ID with announced prefixes WITHOUT doing a
> separate DAD for EACH prefix*ID combination.
> 
> This is still fully allowed by current RFC's, and I still believe this
> is GOOD, and should not be changed.
> 
> As a consequence, and observing that others may not have chosen this
> tactics, the code also defends plain ID, that is: if it sees a DAD for
> address which contains one of my ID's, it will reply to the DAD as if
> I had the address. I don't see any catastrophic failures resulting
> from it.
> 
> 
>

---

From: Tim Hartrick <[email-masked]>
Date: Wed, 14 Aug 2002 23:21:04 -0700 (PDT)

All,

> 
> Ok, first definitions:
> 
> - Node A, has "globally unigue" id = AI, implements "link local"
>   optimization (does DAD only on fe80::AI).
> 
> - Node B is the evil one :-). It has its own "globally unique" id = BI
>   for it's link local
>

I agree.  Our implementation won't allow an application to assign an address
to an interface which has the the "u" bit set.  Not even an application that
has root privileges.  Addresses of that form can only be assigned to interfaces
if the id has been derived directly from the EUI-64 of the network interface.
Yes, yes, that can be circumvented by diddling the MAC address of the network
interface but requires more work.  We don't allow the fumble fingered
administrator to abscond with someone else's id without putting some effort
into it.

I would say that Node B's implementation is kind of broken.

My general opinion on this topic is that all "statically" configured addresses
should have DAD performed on them.  This includes privacy addresses.  The
only addresses which don't require DAD are addresses which are derived
directly from an advertised prefix and a real EUI-64 which has been used to
derive a link-local address, which itself has had DAD performed on it.

I have no problem with changing our implementation to do DAD on every
address but I would have some serious reservations about creating and defending
a link-local address associated with every privacy address.  That is crazy.
If complexity is the enemy then such a scheme can't be characterized as
anything but an enemy.

tim

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 15 Aug 2002 11:30:40 -0400

Folks,

The optimizations I did for T64 were added to by our team and we as of a previous release are doing DAD for all addresses now as Tim suggests below.  What drove us was Mobile IPv6 and folks creating privacy addresses.

/jim

> From: Tim Hartrick [mailto:[email-masked]]
> Sent: Thursday, August 15, 2002 2:21 AM
> To: [email-masked]; [email-masked]

---

From: "Brian Zill" <[email-masked]>
Date: Tue, 20 Aug 2002 11:39:00 -0700

> > From: "Brian Zill" <[email-masked]>
> > 
> > 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.
> 
> Umm.. "majority of implementations"? What is this? How do you 
> count them? When was this tally performed.

I just went by the ones I know about.  Judging from the messages on this
thread, there are only one or two implementations doing "DIID".  Note
that I said "it appears", I didn't claim to have conducted an exhaustive
poll.

> Does each separate implementation count as one? Or, does the 
> number of nodes running the implementation affect the count? 
> Or some other weighing algorithm?

Well, I had just been considering each separate implementation.
Weighing them by existing node count would shift things even more
clearly in the "DAD" direction since both KAME and us do "DAD".

--Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 21 Aug 2002 08:16:14 -0400

Hi Dave,

I'm not talking about the limited way in which the "subnet-local"
multicast scope works today, but about the definition of a subnet.

The word "subnet" means a group of nodes that share a common global
prefix, including subnet ID.  The fact that we don't have a multicast 
mechanism to successfully reach this group of nodes doesn't change 
the definition of "subnet".

So, a subnet may include all of the nodes on a single link -- this will
be the most common case, where all of the nodes are generating addresses
from a single set of RAs.

A subnet may also include a subset of nodes on a single link, if there
is more than one prefix in use on the link, and not all nodes use all
of the prefixes.

Iff we adopt the multi-link subnet proposal, a subnet may also include
a set of nodes that share a subnet prefix across multiple links.  Still
without any requirement that the subnet contain all of the nodes on 
each link.

I agree that it would be quite tricky to use an IPv6 multicast address
to reach a particular subnet, given how multicast addresses are 
constructed.  There is no way for a given node to determine whether
a subnet-local multicast is intended for any of its subnets.  Besides,
as Pekka pointed out, none of the nodes on the link will have joined 
the subnet-local multicast group, so the traffic actually won't reach
any of them.

IPv4 did have a concept of subnet-local broadcast (i.e. 128.224.4.255),
but the ability to address all of the nodes on a single subnet is
apparently lacking in IPv6.  I don't consider this a big problem, but
we shouldn't pretend that "subnet-local" multicast is possible, since
it isn't.

Margaret

At 07:37 PM 8/20/02 , Dave Thaler wrote:
>[...]
> > So, while you indicate that a link-local address may not be able to
> > reach all nodes on a subnet, isn't it also true that a subnet-local
> > address may not be able to reach all of the nodes on a link?
>
>Since the boundary of a zone goes through a node, not through a link
>(ref: scoped addr arch doc), then no it is not true.  The "subnet-local"
>
>scope contains all interfaces on the link regardless of what addresses
>are on those interfaces.
>
>However, there are no subnet-local unicast addresses (only multicast
>ones)
>so the question is moot in practice.  The closest question you could
>construct in practice is: "If a link has multiple subnet prefixes
>assigned to it, and I source from a global address in one of them, and
>the destination is a subnet-local multicast group, will another machine
>on the same link, which does not have an address in the same prefix,
>receive the packet."  The answer is yes it will (so the answer to your
>question is: no, not true).
>
>-Dave

---

From: "Dave Thaler" <[email-masked]>
Date: Wed, 21 Aug 2002 19:46:32 -0700

> From: Charles E. Perkins [mailto:[email-masked]]
[...]
> As I wrote before, but perhaps buried in other text,
> I think that IP should only be concerned about the
> "subnet-local" concept, not the "link-local" concept,
> if we are to use those terms as distinguishable concepts.
> When the link-local addresses were being first discussed,
> I don't remember any discussion that suggested that a
> "link" should have a different extent than a "subnet".
> 
> It seems to me that all IP-level protocols need to
> have "subnet-local" addressing, not the newer proposed
> definition for "link-local". 

It's defined today as non-routed.  
You're proposing to route link-local addresses, so you're
the one with the "new proposed definition" :)

> As I tried to point out
> in my previous message, IP doesn't have any business
> messing around with details about how the subnet is
> actually constructed.

Here we disagree.  A multi-link subnet router does that
(as do IPv4 ARP proxies today, for that matter).

> Thus, to restate, I believe that "link-local" addresses
> are not required to traverse the entire extent of the
> physical medium on which a subnet is defined, then they
> are useless for IP protocols.  

Could not parse the above.  Maybe you meant "I believe
that IF ..."?
     ^^

> Perhaps it would be
> better to rename these addresses (FE80::/10) to be
> called "subnet-local".

That's what your position boils down to, yes.
(I pointed this out on this list prior to last IETF.)
At this point I am undecided on this issue, other than
deciding that if fe80::/10 is not subnet-local, DAD
is cleaner than DIID.

> Do you have examples of protocols that properly use
> "link-local" addresses instead of "subnet-local"
> protocols?  It seems to me that DAD, multicast,
> router advertisements, and Mobile IP all need to
> have the "subnet-local" property, and I can't think
> of any network-layer use for the non-network-layer
> definition of "link-local".

For unicast link-local addresses, I can't either right 
offhand, although I can't say one might not exist.

I agree that DAD on *non-link-local* addresses needs 
to have the subnet-local property, but unfortunately
DAD is currently defined using multicast scope 2 
rather than 3 as it should have been.  This means
workarounds are required, but this is orthogonal
to whether fe80::/10 should be left as link-local
or changed to be subnet-local.

-Dave

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 22 Aug 2002 09:01:39 -0400

> > but
>"Subnet-local" multicast is indeed possible.
>"Network-prefix-local" multicast is not possible.

While I'm not sure that I agree with the terminology, since this is a change
from the common use of the word "subnet", and doesn't really agree with the
use of the term "subnet ID" in the addrarch, I now understand your distinction.

I don't think that we should overload the term "subnet" in this way, so 
we should probably change one of these terms.

Using your terminology (I hope)...

A "subnet" is defined to be a scope that encompasses one or more links.
It can be as small as a single link, or as large as a whole site.  The
definition of a "subnet" is not related to how network prefixes are 
configured on those links and/or nodes.  In particular, it has no special
relationship to the "subnet ID" of a unicast address.

In IPv6, we have the ability to send subnet-local multicast traffic, 
but not subnet-local unicast traffic.

The point of "multi-link subnets" (let me know if I'm wrong) is to allow a
network prefix to span multiple links.  So, really, we are talking about 
"multi-link network prefixes", not subnets at all.  

In order to make "multi-link network prefixes" work properly with
mechanisms such as DAD and RA, we need to forward certain link-local
multicast packets between those links.  This makes "multi-link network
prefixes" more messy and complex than they would be if they'd been 
planned into the architecture from the beginning.

Folks have discussed the fact that subnet-local multicast addresses should
really have been used for DAD, RA, etc.  But, this doesn't necessarily make
sense.  If you buy-in to the concept of "multi-link subnet prefixes", you'd
want these messages to span all of the links that are intended to share a
set of network prefixes.  It isn't clear to me that this is the same set of
links that would comprise a single multicast subnet, but you could probably
define it that way, if desired.

But, even if it would help to use subnet-local multicast, we couldn't
change this now for two reasons:

         1 - These mechanisms are already widely implemented using
                 link-local multicast addresss.
         2 - We haven't defined the equivalent of a subnet-local all-nodes
                 multicast address and/or a subnet-local solicited-nodes
                 multicast address.  So, we don't currently have the means
                 to reach the right sets of nodes at the subnet-local scope.

The addrarch, ND and autoconf RFCs currently make the architectural
assumption that a full unicast network prefix (site-local and/or global 
prefix PLUS subnet ID) will only span a single link, which is, apparently,
in no way related to what scope a subnet-local multicast packet will span.  
Do you agree?

So, really, the question is:

Do we want to modify the IPv6 architecture so that a single unicast
network prefix can span more than one link?  By definition, a subnet
already spans multiple links.

Margaret