Subject: IPv6 Prefix Deprecation Problem

From: "T.J. Kniveton" <[email-masked]>
Date: Thu, 01 Feb 2001 23:04:23 -0800

Hi,

I am looking through the Address Autoconfig (RFC 2462) and Neighbor
Discovery (RFC 2461) drafts, and there seems to be a bit of discrepancy
about deprecating prefixes.

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. 2461 states:
    The only way to force a node to stop using a prefix that was
previously advertised
    with a long Lifetime is to have that node receive an advertisement
for that prefix
    that changes the lifetime downward. The solution in this example is
simple: continue
    advertising the prefix with a lifetime of 0 from September 1st until
October 1st.
However, RFC 2462 has stated that unless router advertisements are
authenticated, any router advertisement trying to expire the prefix
(which still has a few days, to most of a month, of validity left), will
just lower it to two hours.

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
that an admin will log into this machine and manually remove the prefix,
or that router advertisements after a network renumber will be
authenticated. Both of these make far too many assumptions.

Aside from whether this is "OK," there is inconsistency between these
drafts. 2461 does not seem to account for the DoS attack which 2462 is
trying to avoid.

Comments?
-- 
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: Richard Draves <[email-masked]>
Date: Mon, 5 Feb 2001 20:24:50 -0800

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

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.

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

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

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 6 Feb 2001 14:02:15 +0100

> > 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? 
> 
	=> The assumption here is that as a MN you want to be reached. 
	If you do want to be reached then the mapping of your name to
	an IP address must be stored "somewhere". Unless of course 
	you will only give your IP address to people in some other way. 

	So whether it is a DNS or some other database, you need to 
	be able to query that database for your home address/prefix. Of
course 
	you also need to make sure that it survives renumbering. That's
	why a DNS seems quite reasonable. 

> 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".
> 
	=> You need some support from AAA to be able to do that. 
	In that case you would get a home prefix, perform HA
	discovery, and then register with the HA. But still to be 
	reached you would have to update a database/server somewhere. 

> Is there any interest in exploring the issue (beyond the scope of the
> draft, if need be)?
> 
	=> Sure. Also if you're statement above is implying having MNs
	that do not have any fixed home addresses then you might want to
look
	into the Homeless MIPv6 draft to see the impacts of this approach
	and how they solved it.