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

From: "Dave Thaler" <[email-masked]>
Date: Sun, 2 Jun 2002 15:55:40 -0700

> -----Original Message-----
> From: Dr. Subrata Goswami [mailto:[email-masked]]
> Sent: Saturday, June 01, 2002 8:46 PM
> Cc: [email-masked]; 'IPng Working Group'
> Subject: RE: [mobile-ip] RE: RFC 2462 DAD optimization
> 
> I am just curious about what are  the technical differences between a
> link-local address and a subnet-local address.

A subnet can cover multiple links, whenever you have some type of
RA/ND proxying going on.  A link-local address is unique only within
a single link, and is never proxied.  Today fe80::/10 and ffx2::/16
addresses are defined as being link-local.  This means that two
links in the same subnet can reuse the same link-local addresses.

Ffx3::/16 is a subnet-local multicast range.  There is no
subnet-local unicast range today.  Charlie is arguing that he would
like to see fe80::/10 redefined as the "subnet-local" unicast
range, rather than the link-local unicast range, which means
that a multilink subnet router (of which a home agent is one 
special case) would be required to proxy ND for link-local addresses.
(Personally, I think it's way too late to define fe80 as subnet-local.)

Today, a multilink subnet router would have no need to do that,
other than the problems resulting from anyone not doing DAD on
every address - which does not appear to be a problem today.

See draft-ietf-ipngwg-scoping-arch-03.txt
and draft-thaler-ipngwg-multilink-subnets-02.txt
for more information.
 
> I agree with Dave that, doing a DAD for "link-local" type of post-fix
> address is a unnecessary restriction.
> 
> 1. There might be global addresss manually configured with the same
> post-fix but  with different pre-fix as the link-local address of a
> node. What would HA do if a node like that moves into its territory  ?
> 2. For 64-bit post-fix it would render  2**64 perfectly good addresses
> useless.
> 
> Subrata

-Dave

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 02 Jun 2002 16:33:00 -0700

> every address - which does not appear to be a problem today.

Today there aren't any problems, but that's because nobody
is using very many subnet prefixes on the same {,multi-}link.
I think the current design decision essentially codifies that,
at least for mobile nodes.  Is that the intended result?

Another possibility would be to declare that on any link
that has the capability to support mobility agents, a
link-local address semantically has to be same as a subnet-local
address.  This would require extra work from the multi-link
proxy agent, but would make the life of network administrators
much easier since my suggested design choice is much simpler
to understand.

In fact, I would argue that the current "architecture" of
link-local addresses as you have detailed it is wrong,
because it's not in the realm of layer-3 design.  I'll
have to work out the implications for multicast later, but
my initial impression is that it's workable.  I also owe
you more text about why it's a lot of work for home agents.

Regards,
Charlie P.

---

From: [email-masked]
Date: Mon, 03 Jun 2002 08:38:40 +0900

>at least for mobile nodes.  Is that the intended result?

	(just for clarifications, not sure if it is related to the discussion)
	i don't quite parse the above paragraph.
	there are a lot of links where we assign multiple subnet prefixes
	(different /64 from different upstream ISP).  it is useful, for example,
	for RFC3178.  also, if you are willing to use router renumbering
	and such, a /64 prefix out of fec0::/48 range will be added too.

itojun

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 02 Jun 2002 16:43:32 -0700

>         and such, a /64 prefix out of fec0::/48 range will be added too.

This is interesting information.  Can you say how many prefixes
are typically advertised?

Regards,
Charlie P.

---

From: [email-masked]
Date: Mon, 03 Jun 2002 08:47:36 +0900

>are typically advertised?

	not sure about "typically", but around 3 to 5 prefixes are advertised
	in my office, another office, and home.  at past IETFs and ipngwg
	interim meetings, we advertised 2 or 3 prefixes because we were
	multi-homed.  so pls do not assume that there's single subnet prefix
	on a link.

itojun

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 02 Jun 2002 16:58:52 -0700

Hello Itojun,

>         multi-homed.  so pls do not assume that there's single subnet prefix

My guess is that you are using this feature more than most IPv6
installations.  But anyway, it's not 20 or even a dozen prefixes.
Is it reasonable for us to assume that, for most links, the number
of advertised prefixes will never exceed 10?  7?

I never meant to make the assumption that a links would see only
a single advertised prefix.  I had thought that most installations
were not using the feature very heavily, and that 1 or 2 would be the
typical number of prefixes advertised.  Now you point out that there
are some with up to 5.  This is good to know.  I wonder if we can
get to the point of agreeing on a maximum for all future applications,
so that we can agree to avoid designing for problems of scalability
that won't exist over the lifetime of IPv6.

Regards,
Charlie P.

PS. Please let me know what I can do to clarify any parsing issues
    in the above or any previous notes.  I am not trying to be
    writing mysteries or puzzles.

---

From: [email-masked]
Date: Mon, 03 Jun 2002 09:07:25 +0900

>of advertised prefixes will never exceed 10?  7?

	we never know what the future operators will do, so it is safer
	not to make assumptions.

itojun

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 02 Jun 2002 17:20:25 -0700

>         we never know what the future operators will do, so it is safer

In that case, I think we have to do something to avoid doing DAD
for all those prefixes.  One solution would be to just do it for
link-local prefixes, which according to Dave Thaler's argument
then become subnet-local prefixes.

Regards,
Charlie P.

---

From: [email-masked]
Date: Mon, 03 Jun 2002 09:23:29 +0900

>then become subnet-local prefixes.

	i don't think it necessary to do anything about DAD.  we perform DAD
	(not DIIDD) for all addresses assigned, and we will be fine.

itojun

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 02 Jun 2002 17:36:22 -0700

Hello itojun,

>         (not DIIDD) for all addresses assigned, and we will be fine.

Do you still think that is true if the mobile node has to send
out 10, or some unbounded number, of Binding Updates each time it
changes its care-of address?

The discussion in the mobile-ip group is whether a single
Binding Update can suffice for all home addresses of a mobile
node that share the same interface ID.  This led to discussion
about DAD.  The subjects are not inseparably intertwined, but
there is a relationship.

It has been my understanding that a home agent, charged with
the protocol responsibility for defending the addresses of 4,095
mobile nodes (or, say, 500,000 for some cellular plans), would
effectively disable the ability of mobile nodes to use multiple
prefixes, because equipment vendors would just "say no" if they
thought only a few mobile nodes would use this feature.

Thus, I thought that it would be a lot better to have a very
simple scaling mechanism that would still allow for a large
number of prefixes.  This is simple, if the home agent can just
defend the link-local prefix.  It's not so simple if any
increase in the number of advertised prefixes requires a
linear increase in storage or performance requirements at
the home agent.  It's really quite bad if the communication
requirement at the mobile node experiences a linear increase
in capacity requirement at handover time.

My guess is that it will just effectively mean people will not
use multiple prefixes for mobile nodes.

Regards,
Charlie P.

---

From: [email-masked]
Date: Mon, 03 Jun 2002 09:54:54 +0900

>use multiple prefixes for mobile nodes.

	i guess so too, and therefore, i don't feel a need to provide
	special hack in DAD.  it is not a protocol issue, but an operational
	matter.

itojun

---

From: Keith Moore <[email-masked]>
Date: Sun, 02 Jun 2002 22:08:19 -0400

> of advertised prefixes will never exceed 10?  7?

any number of prefixes is probably okay as far as applications
are concerned, PROVIDED that all prefixes are equally valid -
i.e. any address is as good as any other, and applications aren't
expected to pick the "right" prefix in order to be able to 
interoperate.

If this condition does not hold, even two prefixes is too many.

Keith

---

From: Robert Elz <[email-masked]>
Date: Tue, 04 Jun 2002 01:07:01 +0700

| Do you still think that is true if the mobile node has to send
  | out 10, or some unbounded number, of Binding Updates each time it
  | changes its care-of address?

Can't speak for itojun, but I would.   I assume these could all be
combined into one packet (not being a MIP person) - if not, why not?

  | It has been my understanding that a home agent, charged with
  | the protocol responsibility for defending the addresses of 4,095
  | mobile nodes (or, say, 500,000 for some cellular plans), would
  | effectively disable the ability of mobile nodes to use multiple
  | prefixes, because equipment vendors would just "say no" if they
  | thought only a few mobile nodes would use this feature.

That may be, many nodes of that type (where there are huge numbers
connected to one HA) may quite likely only be offered one prefix.
The router config at the home base will make that choice.

  | My guess is that it will just effectively mean people will not
  | use multiple prefixes for mobile nodes.

Probably true.   So what?    Other mobile nodes will still use
multiple prefixes (the HA that I would be dealing with would perhaps
be coping with a half dozen mobile nodes at any one time .. .I think
it could cope with my few prefixes).

And since all this is related, from an earlier message of yours ...

[email-masked] said:
  | Even manually configured global addresses should be required to
  | acquire rights to the corresponding link-local address.  Why not?

Simple.

There is no requirement that a node configure an address from every
available prefix.   (See above for a reason why some modes might choose
not to).

And, there's no reason at all why if a link has prefix1::/64 and
prefix2::/64 assigned to it, I shouldn't be able to manually configure
prefix1::1/128 as the address of one node, and prefix2::1/128 as the
address of an entirely different node.

They cannot both claim fe80::1

In some cases doing this might be the reason for adding a new prefix
to a link - if I have a system with a well known address (prefix1::1)
and I want to move it to a link that is currently prefix2::/64 and
where prefix2::1 is already allocated, I might choose to assign
prefix1::/64 to this link (perhaps disable auto-config of addresses
in that prefix, or perhaps not) just so my node can keep using the well
known address it has become accustomed to (as much as I hate well known
addresses, I know this kind of thing will happen).

The argument for going from a link-local which has had DAD performed
upon it, to allowing auto-config from the same IID using other prefixes
has some attraction, though it really doesn't seem to work at all in
the multi-link prefix cases (and no, changing link local to become
subnet local is not the way out of this).

But going the other way, and requiring link local to every wider scope
address is simply impossible, no matter how much easier that might make
life for home agents.

kre

ps: don't we already have a way to tell from RAs which prefix is multi-link
and which is not (because it matters to whether we send packets to routers
of just do ND for them?).   If so, we can use that to solve the DAD
optimisation problem can't we?   That is, simply prohibit DAD optimisation
for multi-link prefixes.   If we don't currently have such a method, there
are still spare bits in the RA that can easily be used to mark a prefix as
multi-subnet and hence ban DAD optimisation for it.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 03 Jun 2002 11:32:26 -0700

> it could cope with my few prefixes).

No doubt that many IPv6 networks will have only a few nodes,
and many will have only a few prefixes.  My questions were
related whether that model should be our design goal.

>   | acquire rights to the corresponding link-local address.  Why not?

...?...

> available prefix.   (See above for a reason why some modes might choose

I was by no means suggesting that a node should configure
an address from every available prefix.

> They cannot both claim fe80::1

Exactly -- and I am suggesting that there are enough IPv6
addresses available so that there is no motivation to support
the use of prefix{1,2}::1 for two different nodes on the same
link.  Maybe one of them could find a different interface ID.
I didn't yet see why enabling the behavior you suggest has
any advantages.

> addresses, I know this kind of thing will happen).

Honestly, I think IPv6 would be better off by prohibiting
this behavior.

> address is simply impossible, no matter how much easier that might make

Either I didn't understand this, or I don't see why it's impossible.
Actually, I was only concerned with global scope and site-local scope.
Is the only roadblock the desire to maintain an interface ID when
moving a node to a new subnet?

> multi-subnet and hence ban DAD optimisation for it.

This solution works for me, I guess because I don't see any
driving need to put home agents on multi-link subnets.

Regards,
Charlie P.

---

From: Robert Elz <[email-masked]>
Date: Tue, 04 Jun 2002 16:35:31 +0700

| My questions were related whether that model should be our design goal.

Maximum flexibility.   Long term we will find a way to use that.
This implies minimum assumptions, and even fewer unnecessary rules.

  | Exactly -- and I am suggesting that there are enough IPv6
  | addresses available so that there is no motivation to support
  | the use of prefix{1,2}::1 for two different nodes on the same
  | link.  Maybe one of them could find a different interface ID.

You missed the point of the example.   prefix1::1 and prefix2::1
were originally assigned to different nodes on different links.
Then the links were merged into one.

  | I didn't yet see why enabling the behavior you suggest has
  | any advantages.

The alternative is renumbering nodes sometimes.   Not renumbering
is almost always an advantage.    And here we're talking about the IID
part changing, so we don't even get the benefit of local connections
continuing to work using site local addresses - everything stops.

  | Honestly, I think IPv6 would be better off by prohibiting
  | this behavior.

I certainly disagree with that.   I see no compelling reason here
to prohibit anything.

kre

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 4 Jun 2002 12:20:34 +0200 (CEST)

> 	special hack in DAD.  it is not a protocol issue, but an operational

I agree that we don't need to change DAD here. Doing multiple DAD messages
(one per home address) should be in the noise from a performance perspective.

If there is a concern that a mobile node shouldn't need to send multiple
binding updates, then I think that concern applies to both having
multiple prefixes on the home link as well as using RFC 3041 home addresses
(and presumably DHCPv6 assigned home addresses as well).
With RFC 3041 a host will by default have 7 home addresses - 6 deprecated
and 1 preferred temporary address - plus whatever stable (non-temporary)
home addresses it has.

Allowing for a single BU to the home agent with RFC 3041 home
addresses requires that the home agent to maintain the set of home address
each mobile node is using and e.g. treat a BU for any address in the set
as applying to the whole set.

The current mechanism (with ICMP Mobile Prefix Solicitation/Advertisement)
only allows the HA to guess the set of home addresses when stateless
address conf is used. So perhaps this part of the protocol should be
extended with explicit messages from the MN to HA to indicate which home
addresses it is using. Then one can always do a single BU independent of
how many home addresses a mobile node is using, and idependently of how
the MN has acquired those home addresses.

My 2 cents,
   Erik