Subject: RE: DAD vs. DIID

From: "Brian Zill" <[email-masked]>
Date: Tue, 20 Aug 2002 12:17:08 -0700

Hi Charlie,

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

I guess we're just going to have to disagree about link-local vs.
subnet-local.  These are two distinct scopes and should be treated as
such by the architecture.  One shouldn't assume that because you can
reach a node via a global address in the same subnet prefix as you that
you can also reach it via a link-local address.  "DIID" breaks this by
making the false assumption that these scopes are equivalent.

The whole point of multi-link subnet routers is to allow multiple links,
of possibly different physical characteristics, MTUs, etc, to belong to
the same subnet.  And to do it in an architecturally consistent way.  A
multi-link subnet router is a real router that drops the hop count
between links.  It leaves link-local addresses as unique on their link,
as it should.

Maybe we should define unicast address prefixes for each scope as we
have for multicast, so there would be subnet-local unicast addresses.
That would allow people who want to do things on a subnet, rather than
link, basis to do so.

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

You would have the same problem with "DIID" if the mobile node has a
large number of home addresses that differed in the IID part.  As I
noted in my earlier mail, there are plenty of creative proposals for
using lots of IIDs per node, just as I suspect there are some for using
lots of prefixes per subnet.  Let's not break the architecture here over
a optimization that has a lot of questionable assumptions in it.

If we can't live with "DAD", then I'd much prefer we revise the whole
duplicate address detection mechanism.  Currently DAD has two serious
flaws and one major inconvienience: It doesn't protect against duplicate
addresses on reconnected networks (something I would think would happen
a lot on some types of wireless links), it doesn't document a recourse
to take when your only address is a duplicate (retry with a random
address is the obvious solution, but that isn't standardized like EUI-64
is), and it takes longer than we would like.

--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: "Charles E. Perkins" <[email-masked]>
Date: Wed, 21 Aug 2002 08:31:32 -0700

Hello Brian,

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".  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.

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.  Perhaps it would be
better to rename these addresses (FE80::/10) to be
called "subnet-local".

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".

Regards,
Charlie P.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 21 Aug 2002 14:02:17 -0400

> "link" should have a different extent than a "subnet".

Note: the term "subnet-local" has a specific meaning with regards to
multicast. Subnet-local != link-local (per addrarch).

For unicast, things are less clear. That is, for unicast, there is
link-local, site-local, and global. That's it. There is no
"subnet-local" definition per se (note that RFC 2460 does not define
the term "subnet"). My assumption has been that when folks talk about
scoping, they generally assume the scope boundaries for unicast and
multicast are the same (i.e., site-local multicast corresponds to a
site in unicast). This may not be a requirement per se, but I would
think that having two different notions of what the "site" boundaries
were would at best be confusing.

But looking at addr-arch, I see it contains the wording:

>   Currently IPv6 continues the IPv4 model that a subnet prefix is
>   associated with one link.  Multiple subnet prefixes may be assigned
>   to the same link.

So this could lead one to conclude that unicast "subnet" means
"link". And link has a *very* specific meaning (per 2460):

   link        - a communication facility or medium over which nodes can
                 communicate at the link layer, i.e., the layer
                 immediately below IPv6.  Examples are Ethernets (simple
                 or bridged); PPP links; X.25, Frame Relay, or ATM
                 networks; and internet (or higher) layer "tunnels",
                 such as tunnels over IPv4 or IPv6 itself.

So, per the current specs, I conclude that in the case of unicast,
"subnet" is equivalent to "link". Personally, I much prefer that
"link" be used then because it's much more precise, and because
"subnet" in multicast terms is different than "subnet" in unicast
terms. This is confusing.

> 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".

I think we are in agreement so long as "subnet-local" ==
"link-local". Again, I think it would be better to stick with the
latter terminology, as it is more clearly defined, and at present, the
two terms seem to be equivalent. If you look at the revised addr-arch
document, however, it contains the words:

      2.7 Multicast Addresses

      ...
             subnet-local scope is given a different and larger value
             than link-local to enable possible support for subnets
             that span multiple links.

But this leaves open the question about whether "subnet" == "link" is
really still supposed to be the case with unicast addresses.

Thomas

---

From: Robert Elz <[email-masked]>
Date: Thu, 22 Aug 2002 19:55:36 +0700

Date:        Wed, 21 Aug 2002 08:31:32 -0700
    From:        "Charles E. Perkins" <[email-masked]>
    Message-ID:  <[email-masked]>

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

I think there's a chasm between uses of the term "subnet" occuring here.

The subnet in the sense that is bring proposed in multi-link-subnets
is something that's being defined by the IP layer - IP has never used the
term in the ISO sense, that's what "link" means.

As I understand it, here a "subnet" is simply "the collection of nodes
that can be addressed using the same prefix" (where that prefix is not
an aggregate of others).

That is, one might define prefix::/64 and address a collection of nodes
out of that prefix, that's the subnet.

Traditional IP has said that the nodes so addressed all have to be
connected to the same link.   But that's certainly for the IP layer
to define, it isn't fixed in concrete by someone else.

Whether that traditional definition should be changed or not is the topic
of the multi-link-subnet draft (I think) - and I'm not taking a position
on that here - but we certainly need to make sure that we're all using
the terminology the same way.

kre

ps: there is absolutely no need to have a concept of "subnet local"
addressing, or scope, in order to make any of this work, if making it
work was to happen.

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 22 Aug 2002 08:53:47 -0700

Hello Robert,

Robert Elz wrote:

>                        ...................

That is the meaning I have been using.
That is the meaning which is useful for IP.

However, I would typically allow for a subnet to be
an aggregate of other subnets.  In which case, I would
define a link-local address to be local to the longest
prefix (not having subaggregated subnets).  With this
definition, the link-local address is again useful for IP.

Regards,
Charlie P.

---

From: Robert Elz <[email-masked]>
Date: Fri, 23 Aug 2002 14:43:45 +0700

Date:        Thu, 22 Aug 2002 08:53:47 -0700
    From:        Charlie Perkins <[email-masked]>
    Message-ID:  <[email-masked]>

  | That is the meaning I have been using.
  | That is the meaning which is useful for IP.

Yes, but in this case, IP certainly does have a role in
"messing around with the details of how the subnet is actually
constructed" as it is IP that is defining the thing.

  | However, I would typically allow for a subnet to be
  | an aggregate of other subnets.

I'm not opposing that, I just don't want to think about what it
would mean for this right now (I suspect, probably nothing).

  |  In which case, I would
  | define a link-local address to be local to the longest
  | prefix (not having subaggregated subnets).  With this
  | definition, the link-local address is again useful for IP.

As long as we're going to keep the term "link local" I think it really
needs to be in some way related to a link.

And I think addresses that only work on a link (are never routed) are
useful to IP.

I suspect that things are getting stuck on the concept of requiring routing
to reach a node whose address would have (IPv4 world, initial IPv6 too)
have made one assume that it was necessarily on the same link - that is,
it has the same prefix as I have.

I'm still unsure whether we need such a thing, I guess I should go back
and read the multi-link subnet draft again, and see if there's enough there
to inspire me (the why, not the how).

But I certainly don't see it as being fundamentally opposed to the nature
of IP for the "one prefix implies one link" rule to be abolished.   Really,
while it was sort of there in theory, IPv4 never enforced that anyway,
it was not at all uncommon for a router to carve a piece out of a prefix
that applied to a link, and route packets to nodes in that piece (implementing
it on the link using proxy-arp).

It seems that this is just being recognised now, rather than silently
tolerated (and with that, the need for proxy-ND removed).

kre