Date: Sun, 02 Jun 2002 17:36:22 -0700
From: "Charles E. Perkins" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| 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 PROTECTED] 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.
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
