"T.J. Kniveton" wrote:
>
> 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?
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.
>
> 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?
I agree with you to 100% that it should work. The MN should not be
useless after such an event.
>
> > 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.
Sure, please see below.
>
> > 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".
Nobody can contact you, since they don't know your new home address.
Does the foreign network want to give you this service?
>
> 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.
>
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
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
