"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 PROTECTED]
--------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
