> > 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? 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.
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.
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). 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.
--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 PROTECTED]
--------------------------------------------------------------------
