On Fri, Mar 01, 2002 at 09:03:46PM +1100, Geoff Huston wrote: > > 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? > 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.