Robert Elz wrote:
> | 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).
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.
> 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).
I was by no means suggesting that a node should configure
an address from every available prefix.
> 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
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.
> 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).
Honestly, I think IPv6 would be better off by prohibiting
this behavior.
> 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.
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?
> 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.
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.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
