In message <200204102021.QAA08214@ginger.lcs.mit.edu>, "J. Noel Chiappa" writes
:
> > From: Alex Zinin <azinin@nexsi.com>
>
> > By name I mean a permanent host ID. Theoretically, DNS resolve could
> > return the host ID and then another method could be used to find the
> > actual routing address based on it.
>
> Why not have the DNS return both? That would save creating a whole separate
> lookup mechanism (to convert from host ID to address), plus the
> cost/complexity/fragility of another lookup step.
Because the name to address mapping is relatively static and the
mapping of address to location in the topology is not (given today's
use of the terms "name" and "address" to mean DNS name and IP
address of mobile entity).
> Later, if that host wants to move, it could provide a new address (either
> directly to its correspondents, or indirectly via some servers, or most likel
> y
> both), but the things on the far end would still know they were talking to th
> e
> same entity because it's host ID hadn't changed.
>
> Noel
This does not solve the problem. Having a mapping of name to some
topological significant identifier (a dynamically assigned address,
such as one handed out by DHCP) is only part of the problem. It is
also a part of the problem that DNS doesn't solve very well on certain
time scales.
When we talk about mobility, based on the discussions we've been
hearing on this list, we could be trying to solve one of three
practical problem (or in some cases no practical problem at all).
1. Very long time scale mobility. A prefix changes the provider
that they use. For those where this occurs at all, this happens
on the order of once every few years and there is generally a
month overlap to aid the transition. This works well using DNS,
IP aliases on interfaces, editing some config files and DHCP to
cover the unwashed masses. It doesn't appear to work well when
the entitu being moved in the topology is ISP sized and
therefore the reconfiguration on the entity end spans a large
number of administrative entities which are diverse in their use
of technology and the amount of locally available clue.
2. Medium time scale mobility. There are two flavors of this.
a. No requirement for active TCP connections to remain up. For
example, a user shuts off the laptop, leaves the office, goes
somewhere else and powers up again. For this, DNS alone is
adequate. The user can get another DHCP lease and could go
tell the home office to update the DNS record to temporarily
to point to the laptop (or be the client, meaning the guy on
the connect side of the TCP connection, for all services).
b. Active TCP connections must remain up. Same example above,
except the user suspends the laptop before leaving. In this
case, DNS alone doesn't do the job. I've never gone to
something like an IETF meeting and asked them to announce my
/32 and wouldn't expect them to accommodate the request, and
wouldn't expect it to work if they did. This leaves us with
some sort of "home station" based approach. IP Mobile does
the trick. Even simpler, use a fixed address on the loopback,
use a PPP over tunnel connection, and run the tunnel over ssh
if you want encryption, over a plain ol' TCP connection if
not. The trick is getting the applications you care about to
bind to the loopback address. Use the source Luke.
3. Short time scale mobility. Again two flavors.
a. Topologically constrained such that advertising a /32 is no
big deal. For example, a host which will not be physically
moved may have two ethernets so that when one NIC or ethernet
switch goes, the other takes over. People who have worked in
a NOC or other "must be available" will recognize this problem
and its (many) solutions. The simplest solution is to provide
a fixed IP address for the loopback. You have the same issue
here as in 2b of getting the applications for which the mobile
entity (in this case the server with two ethernets) is on the
client or connecting end. The IGP at the site advertises the
/32 for the loopback address through any interfaces that are
up and recovery is on the order of LAN IGP convergence time.
b. Not topologically constrained. This covers the case where
someone with a mobile device such as a laptop moves to other
administrative domains and expects connections to stay up. An
example would be going from the 802.11 coverage at home to the
office, town library, local school (where applicable), IETF
meeting, etc. It is not feasible to advertise a /32 as one
moves. Here you are again stuck with the home base approach.
We now return to our normally scheduled revolutionary irrelevant
drivel.
Curtis
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT