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

From: "Powell, Ken" <[email-masked]>
Date: Mon, 5 Feb 2001 11:21:49 -0500

> -----Original Message-----
> From: T.J. Kniveton [mailto:[email-masked]]
> Sent: Friday, February 02, 2001 2:58 PM
> To: Matt Crawford
> Cc: [email-masked]; [email-masked]
> Subject: Re: IPv6 Prefix Deprecation Problem
>
> 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".

There are other considerations that go into source address
selection, some of which have a worse impact than selecting
an address with preferred lifetime of zero. See Richard Draves'
draft-ietf-ipngwg-default-addr-select-02 for more details.

>
> >
> > 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!"

I've had this same concern. We discussed it on the mobility list
last year, and as Mattias said, the procedure for initializing a
mobile node is beyond the scope of the Mobile IPv6 draft. We did
however discuss some possible initialization techniques to
verify that the mobile IPv6 protocol had sufficient features
to support initialization, particularly where stateless address
autoconfiguration is used on the home network.

Appendix A of draft-ietf-mobileip-ipv6-13 describes one of
these techniques. It starts by retrieving the home agent anycast
address from DNS. One problem with the appendix A approach
is that it does not account for IPsec. We need a procedure that
describes how to establish the security associations between the
mobile node and the home agent in addition to initializing
home addresses and creating bindings. Perhaps something that
uses a AAA server?

>
> 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'm looking forward to seeing your draft.

Ken

---

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

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

---

From: Richard Draves <[email-masked]>
Date: Mon, 5 Feb 2001 20:24:50 -0800

> No, the mobile node is not on its home network; it is away from home.

Ah, I didn't understand from your first message that you were asking about a
mobile node's home address. I thought you were asking about ordinary
auto-configured prefixes. Sorry.

> a general and acceptable way to avoid this problem, but I

I suspect people are willing to punt on this problem (of mobile nodes away
from home & turned off for an arbitrarily long time, while the home network
undergoes arbitrary reconfiguration). Do you think it's an important
scenario for some reason? As you hint, if the mobile node has a DNS name for
itself which is stable, then perhaps the DNS can provide the bootstrap. (If
the mobile node doesn't have a home DNS name, then what functionality is
Mobile IPv6 supposed to provide in this situation?) More generally, the
Mobile IPv6 spec doesn't solve the mobile node configuration problem.

Rich