> > > Another way of looking at it is that the "new"
> > > Ruter advertisement should inform hosts that
> > > this subnet is "being renumbered". I think
> > > this is a clean option. I don't think this
> > > should be a MIP issue. MIPv6 solves the problem
> > > when the MN is away from home, which is when
> > > MIPv6 is espected to solve it. I would suggest
> > > that this is a ND-MIP interaction issue.
>
> I don't think this is a general enough solution. In the common case, an
> administrator would renumber by adding the new prefix and marking the old
> prefix to time-out. A mobile node that returns home during the time-out
> delta could probably surmise that a renumbering was going on without
> needing
> an extra bit in the router advertisement. Yes, the extra bit could serve
> to
> aid those mobile nodes that don't come home until after the old prefix has
> expired, but how long does the router continue to advertise the "being
> renumbered" bit?
>
=> You can do it for the same duration that you advertise dual
prefixes for or more. There are no hard rules for how long that
should be
and I think that's a good thing.
I would argue that having a flag is better than simply just
advertising two
prefixes at the same time. If you have a flag then at least you're
encouraging the MN's (or just any IPv6 node) to use the new
prefix in establishing its new connection. On the other hand,
advertising two prefixes may not necessarily mean that you
are renumbering. Even if one of them has a shorter lifetime.
> At some point the administrator has to claim that the
> "being renumbered" state has finished, confusing any mobile nodes that
> don't
> return home until after that. And if some administrators never get around
> to turning the bit off, you'll have some networks in a state of perpetual
> renumberment.
>
=> Well, the way of turning the flag off can be automated and
set when you turn it on. I think that would depend on the
implementation.
As to the confusion if the MN returns after the flag is turned off,
I think
the confusion already exists, that's why we're having this
discussion.
Adding the flag will make it possible to reduce the confusion by
keeping it on for a bit longer. When I mentioned a "being
renumbered"
flag I didn't mean that it MUST mean that. You could think of
a flag that says "new prefix" and be included in the new prefix
option.
It certainly should be interpreted in a way that doesn't confuse
hosts
and make them think they're in a transient state.
I'm not saying this is the best way, but it is certainly a stright
forward
solution that seems quite simple.
> I think there's a better solution. Have mobile nodes attempt to treat
> every
> home agent they encounter as their home agent. A mobile node should only
> be
> able to successfully do so if the home agent actually is its home agent.
>
=> I'm not quite sure if I understand this correctly. The MN will
have a fixed home address with a certain prefix. If it asumes
that it has a new Home address every time it hears an RA with
the H flag set (for HA), that's ok but that doesn't solve the
mobility
problem for other Home addresses. It still needs to update
the original "home" HA. The HA is only updated when the MN
is in foreign subnet. What you're saing (if I understood it
correctly)
means the MN will have a new Home Address every time
it moves to a new subnet. Again that's fine but it doesn't help
the fixed home address and all the connections using it.
> Note that there has to be some sort of security authorization between the
> mobile node and the home agent or bad people visiting your link could
> steal
> one of your addresses (such authorization is required for the mobile node
> to
> securely update the home agent as to what its care-of-address is, so the
> authorization capability must exist). In other words, if you pass
> security,
> you're at home (or one of your homes, at any rate).
>
=> That authorisation only happens when you're in a foreign subnet.
> Now the MIPv6 draft is
> a little weak regarding how this authorization should be done, but I think
> that's a problem for the mobile ip working group.
>
=> I disagree here. MIPv6 BUs are secured using AH and that's
mandatory.
How a security asociation is established is not a MIP problem. It
can be manually configured or dynamically using IKE.
Hesham
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
