Richard Draves wrote:
>
> > Specifically, let's consider the scenario described in RFC
> > 2461 on page
> > 78-79. A prefix has been advertised with a lifetime of two months, a
> > machine is turned off on July 31st, then on Aug. 1st, it's decided the
> > prefix should expire on Sep 1st. The host is turned back during
> > September, at which point the prefix is deprecated, but the
> > node's last
> > received advertisement indicates the prefix is valid until the end of
> > September.
>
> I don't know of any implementations that keep prefixes in a persistent
> store. My expectaction would be that when the host is turned back on in
> September, it will send an RS and get RAs and auto-configure itself without
> any memory of the old prefix.
No, the mobile node is not on its home network; it is away from home.
RSs sent on the VISITED link will allow auto-configuration of a COA.
Getting RAs from the HOME link would require tunneling a RS to the home
network. And to tunnel this RA, you need the HA's address (the first n
bits of your cached copy are now bogus). Back to square 1.
> Furthermore, I think the site administrator has screwed up by advertising a
> two month lifetime and then trying to remove the prefix in one month.
Maybe true. Which leaves the questions, why does 2462 give this as an
example of network renumbering, why are lifetimes 32 bits and why does
the RFC allow infinite lifetimes on network prefixes?
This is academic anyway. The problem isn't necessarily that the old
prefix doesn't go away fast enough. The problem is that a mobile node,
away from home, may wake up from being turned off during a renumbering
event, and have NO WAY to contact its home agent or even home network.
Either it has stale prefix info, or NO prefix info, but with no binding
at its home agent, and thus no tunneled router advertisements at any
point during the renumbering, it doesn't have CURRENT prefix info.
Whether the renumbering took place over a day, month, or year is
immaterial - the mobile simply has to be away from home and not register
with the HA when the renumbering starts, and then start using Mobile
IPv6 after the network renumbering for the problem to arise.
This was my original point, which perhaps I have not effectively
described. There is a way around this, using DNS, but that requires
services that may not be available on the visited network. I can not see
a general and acceptable way to avoid this problem, but I remain open to
suggestions.
Thanks,
--
T.J. Kniveton
NOKIA Research Center
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
