Subject: RE: IPv6 Prefix Deprecation Problem

From: Richard Draves <[email-masked]>
Date: Mon, 5 Feb 2001 16:46:58 -0800

> 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.

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.

Rich
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 05 Feb 2001 17:33:11 -0800

> 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.

> 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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 7 Feb 2001 17:25:56 +0100 (CET)

> any memory of the old prefix.

The Solaris 8 IPv6 implementation retains the IPv6 addresses configured through
stateless autoconfig in stable storage (together with the prefix lifetimes).
This is only used as a fallback should the node reboot and find no routers on
the link (i.e. no response after 3 RSs).  The implementation does not retain
the on-link prefixes - just the addrconf prefixes.

This helps in the power failure scenario when the hosts
on a link might reboot before the routers. While they can't communicate
off-link until the routers appear there is some benefit in being able to
communicate on-link using the same addresses (global or site-local) that they
had before the power failure.

  Erik