Subject: Re: [MOBILE-IP] IPv6 Prefix Deprecation Problem

From: "T.J. Kniveton" <[email-masked]>
Date: Fri, 2 Feb 2001 11:57:39 -0800

[I am crossposting to Mobile-IP since I am throwing in some info about
mobiles]

on 2/2/01 7:41 AM, Matt Crawford wrote:

> Is it OK with everyone that a node that has been turned off for a while,
> could possibly be *unusable* on a network for two hours? We can not say
>
> I think "unusuable" is too strong.  There will presumably be newer
> prefixes advertised and no rule makes the node ignore those.

OK, here is why I posted the message. We can certainly imagine good
implementations that handle this renumbering case without a hitch. However,
in reading the rules of the draft, I can imagine correct, and possibly even
reasonable, implementations that choke at this point. For instance, if my
implementation has a strong affinity for my primary global address as long
as it remains valid, and it thinks the address is valid for a couple more
hours, it might continue to try to use that address.

Some layer above IP is choosing the source address -- either the
application, or an upper network layer on its behalf. This layer "should"
[2462] choose a prefix that has a positive preferred lifetime remaining when
it opens a connection. Perhaps that "should" should change to "must".

What bothers me boils down to the fact that we have a VALID prefix, though
it may not be preferred. A deprecated address is still a valid address and
MAY be used to start new communication. Yet the autoconfig rules do not have
any way to remove this invalid address/prefix.

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

--
TJ Kniveton
NOKIA Research

---

From: Mattias Pettersson <[email-masked]>
Date: Mon, 5 Feb 2001 10:03:20 +0100

> courses of action at this point..unless anyone can provide a good, clear,

Are your prefix lifetimes not supposed to be in the same order as the
renumbering period? If your renumbering takes one month, set valid
lifetime to one month for prefixes announces long before the renumbering
phase starts. In this way you won't end up in situations like this.

Next, I wouldn't be sure that a Mobile Node would remember it's home
prefix lifetime if it was switched off.

One requirement that we came up to when writing Mobile IPv6 i-d v13 was
that the Mobile Node must somehow know its home prefix or a DNS name
representing the home prefix or home agents anycast address. How the
Mobile Node learns this is out of scope of the draft. Thus, the upper
layer that provides the Mobile Node with the home prefix in the first
place, must also provide the new renumbered home prefix in cases like
this when the Mobile Node is switched off during renumbering.

/Mattias