Subject: Re: IPv6 Prefix Deprecation Problem

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 05 Feb 2001 15:12:37 -0800

"Hesham Soliman (ERA)" wrote:
>         => 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.

Thanks for your input, Hesham. This alternative, similar to Appendix A
of the Draft, is one of the alternatives 	I was considering, and
probably the best event sequence when DNS will help you out and you have
configured with the NAI properly. There are a couple of other
possibilities, and it might be optimal to have a fallback if you can not
get the home network prefix because of lack of needed services, or lack
of correct configuration.

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

Yes, it probably takes the least amount of manual intervention, which is
a good thing.

Mattias Pettersson wrote:
> 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. 

It may or may not be possible to have enough a priori knowledge of the
renumbering to start advertising shortened lifetimes "long" before the
renumbering. Regardless, wouldn't it be better to have a spec that
handles possible and reasonable situations, rather than saying things
will work if you implement and configure just-so?

To me, it is not a far stretch of the imagination to picture a laptop
that is a MN running MIPv6, which sits for a long period of time on a
foreign network, and is switched off for a few months. I mean, maybe
it's not the common case..but it should still work! Right?

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

OK.. But if the state this machine is keeping around is its home network
prefix, it could be toast. If it is keeping its home address, home agent
address, and home network prefix without any lifetimes, it still may not
be able to communicate with its home network or any correspondents using
its home address. The lifetime is not really the problem. It's how much
information and support you need to determine your identity and origins.

> 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

Well, DNS is the option that's most likely to survive a network
renumbering. But, can we really mandate that DNS is available for a
mobile node when it's configuring on a foreign network?...

> Mobile Node learns this is out of scope of the draft. Thus, the upper

Appendix A deals with it in a limited situation as Hesham denoted above.
What if DNS is not available? It may also be able to continue supporting
mobility at the IP layer, but without use of the Home Address, if the
home network can not be resolved. I.e. what if the visited network
becomes your new, temporary "home network" and you can continue to roam,
keeping open TCP connections, using your COA as your "home address".

Is there any interest in exploring the issue (beyond the scope of the
draft, if need be)?

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

Good point.

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

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 4 Feb 2001 20:22:41 +0100

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

	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

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 06 Feb 2001 10:26:53 +0100

> will work if you implement and configure just-so?

Along with what Richard Draves I think that the site administrator has
to plan things already when the site is constructed.

Also, since ND is un-acknowledged when it comes to RAs, this can happen:
 - The router sends RAs with lifetime of one year.
 - A host configures itself with this.
 - The router decreases RA lifetime to one week.
 - The host misses all RAs from this point.
 - After one week the old prefix is invalid on the link.
 - The host still sees it valid for almost one year unless it's being
advertised with lifetime 0.

Unlikely, but still possible. So the initial lifetime of one year is a
bad choice.

> it's not the common case..but it should still work! Right?

I agree with you to 100% that it should work. The MN should not be
useless after such an event.

> information and support you need to determine your identity and origins.

Sure, please see below.

> keeping open TCP connections, using your COA as your "home address".

Nobody can contact you, since they don't know your new home address.

Does the foreign network want to give you this service?

> > this when the Mobile Node is switched off during renumbering.

I think we should not put any futher requirements on Mobile IPv6 itself.
The bootstrapping sequence described in Appendix A takes care of
everything, with one requirement: Mobile IPv6 needs the home prefix.

Some function has to find out this current home prefix on every
invocation of Mobile IPv6.

Example:
while (1) {
	if (stored_home_prefix == NULL) {
		stored_home_prefix = magic_function(magic_ID);
	}
	error = invoke_mobile_ipv6(stored_home_prefix);
	if (error) {
		stored_home_prefix = NULL;
	}
}

So Mobile IPv6 would complain if stored_home_prefix wouldn't work and
thus need to fall back on some other (magic) function, e.g.
 - function = DNS, ID = home agents anycast address name, for instance
 - function = AAA, ID = NAI (?)
 - function = manual... user has to find the new home prefix.
 - ...

Whatever this function is it is needed when we create a system using
Mobile IPv6. However, Mobile IPv6 itself doesn't need this. If the
foreign network doesn't support AAA or DNS, maybe we have to stick to
manual intervention.

Or do we want to agree upon a new method, in addition to the ones listed
above? The problem is to make every foreign network support them.

/Mattias

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 6 Feb 2001 16:24:23 -0800

I recall having once read in some internet-draft that, in order not to
disrupt intra-site communications during renumbering, that intra-site
communications should use site-local addresses.

But I can't recall how it is a host decides when another host can be reached
via a site-local address, nor can I find where I read that text.

Can anyone point me to the IDs/RFCs that talk about this?

Thanks,

PF

---

From: Robert Elz <[email-masked]>
Date: Wed, 07 Feb 2001 12:22:36 +0700

Date:        Tue, 6 Feb 2001 16:24:23 -0800
    From:        "Paul Francis" <[email-masked]>
    Message-ID:  <006b01c0909c$528dda60$1300a8c0@dellchan>

  | But I can't recall how it is a host decides when another host can be reached
  | via a site-local address, nor can I find where I read that text.

This is still one of life's mysteries I think - several ideas have
been floated, but nothing yet committed to a draft that I'm aware of.

The include placing the site locals in the DNS, and having clients
do a match on the global addresses to see if the site local should
refer to the same site (one that finds no attraction to me at all).

And having the client send from its site local addr (so the packet cannot
leave the site) to the remote global addr an ICMP saying "tell me your
addresses", and receiving a list that includes the site locals for the
destination (or receiving an ICMP error indicating an attempt to cross
the site boundary with a site local source addr).   (If the source doesn't
have, or doesn't want to use, its site local addr, then there's no point
doing any of this, may as well just use global addr of the dest a well).
This one I like - it adds a small delay in communications the first time
a connection is attempted to a new node (only for connections initiated, 
responses would never do this) but that is bounded by the RTT to the edge
of the site, which is usually of the order of a couple of ms.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Feb 2001 09:19:01 -0600

Once you *know* that a host has a site local address, the
address selection draft tells you when to use it.  I've always
assumed that they would be in the DNS along with global addresses.
Presumably large sites will be running two-faced DNS anyway, so
these addresses will never go outside.

   Brian

---

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

> Can anyone point me to the IDs/RFCs that talk about this?

draft-ietf-ipngwg-site-prefixes-nn.txt, which has expired.
The secretariat is getting too efficient :-(

I just reposted the I-D.

  Erik

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 7 Feb 2001 11:17:42 -0800

> these addresses will never go outside.

The other think I recall, though, is that somehow the reason for using
site-local addresses is explicitly to avoid using two-faced DNS.  (If one
were using two-faced DNS, then the better approach would be to use some kind
of globally-unique but non-ISP assigned prefix.  You'd use this prefix for
internal traffic only, but since it is globally unique, you wouldn't have
the renumbering problem you have when using site-local addresses when you
merge two sites.)

PF

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 6 Feb 2001 16:24:23 -0800

Thanks,

PF