Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization

From: Markku Savela <[email-masked]>
Date: Sun, 2 Jun 2002 04:51:19 +0300

> From: "Richard Draves" <[email-masked]>
>
> You are basically arguing for DIID (duplicate interface-id detection)
> instead of DAD (duplicate address detection), by using DAD on the
> link-local address to perform DIID.

I'm very much for the Unique Interface ID on a link (DIID?). I don't
see any harm from such policy. It just greatly simplifies the matters.

> It seems strange to me to perform DAD on a link-local address that is
> not actually being used. For better or worse, it's not the architecture
> that we have today and I'm not inclined to change it.

It could perphaps be considered, that doing DAD (DIID) on any address
on link, would automaticly also reserve the ID for all prefixes.

If you don't do unique ID on link, every time a new prefix is
announced by RA, there will be a flood of DAD's, as every host on the
links is "dadding" their new prefix/id combinations. (And this will go
on for global, site local prefixes or 6to4 prefixes.

---

From: "Dave Thaler" <[email-masked]>
Date: Sun, 2 Jun 2002 16:13:11 -0700

Charlie Perkins writes:
> Actually, I would be in favor of making link-local to be the
> same as "subnet-local".  I don't see the advantage in making
> any distinction.

[Note: This email is not Mobile-IP specific.  I'm talking about 
the general case, of which a home agent is a special case which
corresponds to an ND proxy as defined in the multilink subnet
draft.]

The distinction in scope is especially important for multicast,
which uses two separate ranges for link- and subnet-local
today.  The distinction is that link-local addresses are
never forwarded by any router, and hence are always possible
to use even when no multicast routing protocol is deployed.
Subnet-local addresses require a routing protocol which
must have some concept akin to host routes within the subnet.
This is fine for multicast since multicast routing protocols
already use address-specific state today, rather than multicast
prefixes.

For unicast, domains typically don't use host routes, and hence
as noted in draft-thaler-ipngwg-multilink-subnets-02.txt,
this is a difficult problem with no simple solution in the
general case.  (Which is why the RA/ND proxy solution that
people often use is not tailored to the general case, and indeed
can cause problems in the general case, leading to rules to 
prevent meltdown like in section 5.4 of that draft.)

> And, I think that the advantage of only having
> to do DAD for a single address per subnet is a very good
> advantage, one that turns out to be especially handy for
> mobile nodes while they are traveling.

[End of explanation, begin personal opinions:]
It seems to me that it's just an optimization that's not worth
the complexity of creating a problem in the general case.  I 
also don't think we should be changing the addressing architecture 
(specifically, redefining fe80::/10 as subnet-local) this late,
especially if it can cause problems in some cases (which I
believe it does, details are in Appendix A of the multilink 
subnet draft).
 
> In fact, I would say that not having this feature is tantamount
> to restricting mobile nodes to a single home address.
> Otherwise, it gets to be too much work for the home agent.

I don't understand why it's tantamount to having a single home
address.  Certainly one could conceivably have one home address 
for each of two separate home agents, without adding any additional
work for each home agent, right?  It's also non-obvious to me
why it's too much work if there's multiple home addresses
at the same home agent.  Can you elaborate?

-Dave
 
> Am I missing some good feature that results from making
> the distinction?
> 
> Regards,
> Charlie P.
> 
> 
> Dave Thaler wrote:
> 
> > As mentioned in email I sent a week or two back, this is
> > related to the issue of whether a link-local address has to be
> > unique across an entire subnet, not just a link.  Today it's
> > defined as a "link-local" not a "subnet-local" address.  This
> > means that it is not guaranteed to be unique across a subnet.
> >
> > Manually configured global addresses don't need to require
> > rights to the corresponding link-local address since
> > a) it's not necessary as they don't use the link-local address,
> > b) it's not sufficient since they need to be unique across the
> >    subnet, not just the link.
> >
> > So unless you're proposing we redefine "link-local" addresses
> > as "subnet-local" addresses (which would at least be a
> > consistent argument, albeit a change to the architecture),
> > then what you suggest does not seem to me to be the right solution.
> >
> > -Dave