In your previous mail you wrote:
Reading through section 10.4 of the MIPv6 draft (version 12), I get the
impression that:
1. Movement detection is not a simple problem to solve. The draft
doesn't really specifiy what method should be used.
=> there are many different methods, some of them are (too) slow,
some of them can detect movements when there is no movement, this can
be a problem or not... I think we need to get results from fast/smart/...
handoff special group and from implemention experiences.
2. Seeing an adverisement from a router with a different prefix is not a
good way to detect movement.
=> I agree but the other way is not better.
The preferred movement detection method seems to be loss of
reachability of the MN's default router,
=> this is not good if there are more than one router and of course
is very bad if the number of potential default routers is large enough...
which is noticed through neighbor unreachability detection
=> which uses neighbor solicitations, not router solicitations !
and/or use of the router advertisement interval option.
=> this point should be added into neighbor discovery specs (ie.
it is useful in general, not only for mobility).
> > I also can't find RFC or draft which define exactly address list in a
> > MIPv6 MN. A IPv6 node have a address list and every prefix has lifetime
=> in *theory* the list is the union of local prefixes and home prefixes,
both are in router advertisements on the local link and through the tunnel
with the home agent with the according lifetimes. In order to get the whole
list ASAP someone suggested in this list that the home agent sends router
advertisements to the MN when a home registration is done.
The issue is what happens if the home link is renumbered when the MN is
stopped. In fact this depends on how the MN knows its home prefix(es):
- very stupid implementations believe the MN is started at home then
the home prefixes will be prefixes of the first attached link: no
problem with renumbering.
- stupid implementations use a static config in order to know home
prefixes then if the config is too old the MN will not be able to
find its home link (and a home agent).
- someone suggested in the list to use a name which can be updated
when the home prefix is renumbered (but not renamed :-). It is a
fine idea out of the scope of the mobile IPv6 draft.
I think most implementations use the second way (static config)...
An open question is what to do with DHCPv6?
Regards
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
