Subject: Re: utility of dynamic DNS

From: Francis Dupont <[email-masked]>
Date: Fri, 01 Mar 2002 09:57:33 +0100

In your previous mail you wrote:

   Perhaps.  Certainly stable IP address is preferable to being
   constantly and needlessly renumbered all the time (although if the
   practice became more prevelant, the silver lining is that it would
   likely put an end to that abomination known as IP-address dependent
   license keys).

=> unfortunately not because one can answer you may use another
abomination known as NATs (sorry Keith to use this dirty word :-).

   So for static installations such as Cable Modems and
   DSL lines, I agree with you, and I wish network providers would
   provide stable IP addresses.
   
=> I agree and there is no technical reason to stay with dynamic IP
addresses.

   However, I much prefer DHCP plus DDNS to Mobile IP.  With Dynamic
   DNS, the security model is well understood; I need only inform a
   single host with whom which I have a trust relationship --- the DNS
   server for thunk.org --- that the DNS address for my laptop should be
   changed to 1.2.3.4.
   
=> I disagree because in order to make your box quickly reachable
after an address change you have to play with RR TTLs and DNS is
*not* designed to behave well with short TTLs...

   With Mobile IP, the security model seems to be (in order to avoid
   triangle routing),

=> the key point is again inside the parenthesis: your concern is
not about Mobile IP (as you can get a trust relationship with your
home agent) but about routing optimization of Mobile IP.

   The other, is as near as I can tell, completely and totally
   hopeless as far as being practical or deployable.
   
=> and Mobile IP without routing optimization as a replacement or
a complement to DDNS?

Thanks

[email-masked]

---

From: Geoff Huston <[email-masked]>
Date: Fri, 01 Mar 2002 21:03:46 +1100

The essence of the architecture of mobility is to allow the identity of the 
mobile device to remain constant while allowing the identity of the 
location of the device within the network to vary.  The dynamic DNS 
approach attempts to bind the domain name as the device's persistent 
identity and allows the current IP address to equate to the device's 
current location.

Obviously, as already pointed out, the restriction here is that the device 
cannot support persistent state across location changes, but worse, as far 
as I can tell, is that it is an approach that has poor scaling properties. 
In order to operate correctly in a timely fashion the relevant parts of the 
DNS now require very short TTLs. At that point many of the assumptions of 
the scaleability of the DNS tend to be called into question. Is the gain 
worth the potential scaling pain?

If the issue here is one of circumventing some level of circuitous traffic 
paths, then it seems to me that there is really not much to gain - any 
cursory examination of Internet paths in terms of cable route miles reveals 
a healthy level of gratuitous overhead in any case - the so called direct 
paths you get from dynamic DNS updates as a solution to mobility may well 
be no better than the dog-leg route you were attempting to avoid.

---

From: Theodore Tso <[email-masked]>
Date: Fri, 1 Mar 2002 13:07:02 -0500

> worth the potential scaling pain?

I hear you.  However, there are other ways of keeping stable IP
addresses at a local level (i.e., using switches, or even the
blatcherous VLAN technology).  So if for example, the terminal room
staff at Minneapolis has a large enough pool of DHCP addresses for
everyone, plus some kind of local switching/VLAN architecture so that
people who use the conference network, regardless of whether they are
on the wireless or wired network, always have the same IP addresses,
then it becomes possible to keep the TTL at a fairly reasonable level,
and still win.

In addition, we should ask ourselves what sort of workload assumptions
we are placing on the mobile device.  If the mobile device is
appearing and disappearing on and off the network (due to the laptop
being off during lunch breaks, and battery/power limitations), and if
you consider other constraints (such as in the case of a GPRS device,
the ***obscenely*** high cost of network bandwidth), it seems very
unlikely that the mobile device is likely to be a primary server of a
DNS zone, a commonly accessed web server (with pubicized URL's), or
even an SMTP receiver, simply due to the cost and availability issues.

Hence, even if thunk-laptop.thunk.org has a short TTL (say, 300
seconds), it's not clear to me what a huge dent that would make in
DNS's scaleability properties.  The rest of the RR's in my zone will
have a nice, high TTL, because I know they are going to be stable.
And the number of people who would actually be using
thunk-laptop.thunk.org will be small, so it won't be appearing in many
DNS servers' caches.  (In practice, it will probably only be when I'm
asking someone to scp something from one laptop to another, or if I
set up a web server so someone can quickly look at something from my
laptop.)

Is this a general solution?  No, obviously not.  But it certainly has
the advantage that I can deploy it today, without needing to get my
ISP or anyone else involved (unless I care about updating the reverse
DNS mappings, of course --- but it sounds like that will be taken care
of at Minneapolis.)

As for claims that this doesn't solve the general problem, I wonder if
it's *necessary* to solve the general problem of someone who wishes to
suddenly and instaneously teleport some critical bit of internet
infrastructure (say www.telstra.net or ns.telstra.net) from Sidney to
Helsinki and expect it to work without needing any advance setup.  Yet
it seems to me that this is the problem which Mobile IP is trying to
solve.

If we relax the constraints sufficiently, clearly DHCP + DNS Update is
sufficient.  What's not entirely clear to me is whether there are
enough common scenarios, for which DHCP + DNS Update is not
sufficient, and for which something like the approach used by Mobile
IP would solve the problem in a cost-effective way, such that it's
worth it to deploy Mobile IP.  It may very well be that there are.  I
just don't know what they might be.

						- Ted

P.S.  I can think of some partial answers; for example, if there is
high-speed internet access in my hotel, and assuming it is reasonably
priced, I might want to use it in the morning before I go down to the
terminal room.  Presumably the hotel will be using different IP
addresses than the IETF terminal room, so I'd need to use dynamic DNS
updates to update my IP addresses.  Assuming that I use a TTL of say,
half an hour, then it would take at least that long before that cache
entry would expire, and so other hosts on the internet would take that
long before the DNS entry would expire from their cache and they would
try to contact my host.  So if my laptop supposed to receive mail over
SMTP, then clearly mobile IP would be a better solution, since the DNS
TTL timeout wouldn't be an issue.

But wait a moment; if the laptop is frequently appearing and
disappearing off the network, I wouldn't want it to be an SMTP
receiver anyway, since that would simply cause my mail to be stalled
on mail queues all over the net, and there's no guarantee that the
intervening MTA's will choose to retry delivery during the time while
the laptop is on the network.  So clearly, a pull mechanism using IMAP
is a much choice anyway, since as an IMAP client, the laptop doesn't
even need to update my DNS entry before it contacts my mail server,
and downloads my e-mail.

So it goes --- I can't think of a usage scenario where the benefits of
Mobile IP actually buys me anything, and there isn't some other way of
doing it which might be better/faster/cheaper.