> >
> > Also, doesn't the node's stack need to allow for the possibility that
> > when it is powered back on, it is connected to a different link entirely?
>
> Good point. I didn't even get into the problems with mobile nodes. Imagine,
> for instance the following twist:
>
> The mobile node had one global address based on its home prefix. It was
> turned off on July 31st. The mobile's Home Network was renumbered, as
> described in RFC 2461, between August 1st and September 1st. Mappings from
> the old prefix to the new prefix were removed from routers on September
> 15th. The old prefix is dead.
>
> Now the mobile node is turned on, on September 25th, in a visited network.
> It starts receiving router advertisements for the local link. It configures
> a link-local care-of address. It wants to contact its Home Agent to register
> a binding for its care-of address.
>
> "I can't contact my home agent."
> "I can't contact any routers on my home network to do Home Agent Discovery."
> "My cached home address has not expired...but my home network has
> disappeared."
> "Help!"
>
> Hmmm. This could be a problem. I am writing a draft to address possible
> courses of action at this point..unless anyone can provide a good, clear,
> obvious answer.
>
=> I don't have a concrete proposal but basically the problem
here is manual configuration of the Home address / prefix.
If the MN can decouple its identity from the Home prefix
and use something more abstract (eg. NAI) then the
problem can be solved.
- The MN starts in a foreign network
- It discovers its home address (By looking up the
NAI is some location management database. eg DNS)
- The MN does dynamic HA discovery
- The MN sends a BU to the HA.
In general manually configuring the Home address seems
to be a bad approach IMO. The above approach is implementation
dependant and would not require modifications to MIPv6.
Another alternative would be to use AAAH to get a home address
but I'd rather not use AAA for this since MIPv6 already
has a mechanism for finding the HA.
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]
--------------------------------------------------------------------
