Subject: Dynamic DNS and TTL value 0, part II

From: Mikael Latvala <[email-masked]>
Date: Tue, 07 Dec 1999 16:39:25 +0200

First of all, thank you for all those who took time to answer my
questions.

To my surprise I received only one message where my proposal was
dismissed as something which could cause Internet meltdown. Because that
particular answer did not elaborate any further why my proposal might be
so disastrous I was unfortunately forced to ignore it. So in that regard
I am still waiting hear from you if any studies have been done to find
what happens to the core network when the TTL is decreased to zero.

I would agree with [email-masked] that the biggest problem with
this approach is the fact that some applications might do their own
caching. I do not know is there some Internet programming bible which
says that applications should always perform a DNS lookup before opening
a connection. If not, one could easily state that that's something that
most of the applications should do. After all, even static IP addresses
are not fixed in concrete. So from that point of view applications which
do not perform a DNS lookup before opening a connection could be
considered broken.

Also, as pointed out by Jared, making TTL 0 would not necessarily be so
bad because all but the last response to queries in recursive resolution
process could be cached. Only the response from an authorative name
server could not be cached thus not introducing too much extra traffic
in the net especially when we take into consideration the facts that:

	1. Mobile hosts are unlikely to act as servers
	2. Most connections are rather long-lived

(this was pointed out by jerry, [email-masked]).

Jerry also made an interesting comment that negative caching would be
extremely useful in wireless world where mobile hosts are often
unreachable or have run out of batteries.

Now, "TTL20" is not meant to replace MobileIP or any other mobility
mangement (MM) mechanism. Rather, it should be used together with some
particular MM so that mobile users can move seamlessly e.g. from WLAN
environment to cellular environment. TTL20 just makes it possible to
establish a connection to a mobile host which was given a dynamic IP
address (yes, this tries to fix one of the inconveniencies caused by
IPv4 address depletion). It should not be confused either with SIP which
facilitates personal mobility. SIP is designed for multimedia
applications. It is unlikely, however, that other applications, e.g.
email, web-based push services, would use SIP.

/Mikael

---

From: Robert Elz <[email-masked]>
Date: Wed, 08 Dec 1999 10:08:59 +1100

Date:        Tue, 07 Dec 1999 16:39:25 +0200
    From:        Mikael Latvala <[email-masked]>
    Message-ID:  <[email-masked]>

  | First of all, thank you for all those who took time to answer my
  | questions.

Somehow I seemed to miss them.   It isn't clear to me now which records
you're proposing should have a TTL of 0.   Some of the answers seemed to
be responding to the possibility that all DNS records have their TTL's
set to zero.  I suspect that would cause about a net trippling of all
internet traffic, from probably a factor of 50 increase in DNS traffic
(very rough back of the envelope calculation assuming that most connections
are for relatively small http transfers which usually result in several
connections to related nodes in a very short period, and that the average
depth of the domain tree is a little over 3).

On the other hand, if all you're suggesting is that the TTLs for nodes
that are known to be likely to be mobile (laptops, mobile phones, and
such) are set to 0, and servers (including particularly DNS servers)
would continue with much longer TTLs as they now have, then I doubt
that the net would notice it all that much.   I don't see why 0 would
be all that necessary though - even the most active mobile node is usually
going to retain an address for at least a minute or so - and the
extra bit of caching that can come from even a short caching period can
really help.

  | So in that regard
  | I am still waiting hear from you if any studies have been done to find
  | what happens to the core network when the TTL is decreased to zero.

I doubt that anyone is going to answer that, because conducting such an
experiment would be almost impossible.  If anyone actually had the resources
to set enough TTLs to zero to make any statistical difference to overall
net patterns, the chance of them risking net problems isn't high (ie: no-one
with the ability would have the guts...).  And even that assumes that there
aren't still large numbers of nameservers around the net which silently
promote any TTL under 300 (5 minutes) to 300 anyway.

  | So from that point of view applications which
  | do not perform a DNS lookup before opening a connection could be
  | considered broken.

This is meaningless.   If the application has a name it has to translate
it to an address before it can use it, and absent other overriding knowledge
from somewhere (that you cannot forbid) a DNS lookup has to be done to
obtain the address - so defining applications that don't do such a thing as
"broken" is pretty dumb (they obviously are - they simply don't work).   As
to how long before the connection is opened the application does the DNS
lookup, that part hasn't really even been rationally implemented, largely
because there has been no API in widespread use that has returned the TTL
to the application - the application has no idea how long it is permitted to
hang onto the address.   The usual result of that has been that applications
simply don't - they look up the address once, use it once, and exit, with no
caching at all.  Some cache it forever though, and some do multiple lookups
where one would have sufficed.

  | Also, as pointed out by Jared, making TTL 0 would not necessarily be so
  | bad because all but the last response to queries in recursive resolution
  | process could be cached.

That depends upon which TTLs are 0.   If the TTLs on the NS records for .COM
were 0, and continuing down the chain, then you would have to start at the
root for every lookup.  On the other hand if it is only (some) end node
TTLs that are to be 0 (or low anyway) then there are less problems likely.

  | Only the response from an authorative name
  | server could not be cached

I think I know what you're saying - though this looks about as backwards
as it is possible to get.   If anything, only the responses from authoritative
nameservers should be cached, all the rest is too likely to be noise.
But if you're doing full (slow) name resolution, you're only ever getting
responses from authoritative nameservers (authoritative for foor first,
authoritative for .com second, authoritative for ericsson.com third, etc).

  | 	1. Mobile hosts are unlikely to act as servers

This I believe - even more if you change that to "significant servers".
My laptop has been known to act as a ftp server for the odd period here
or there when it has been able to hand some files to someone else at an
IETF meeting or similar - but it certainly isn't going to be advertised
anywhere as a place to come to fetch stuff normally.

  | 	2. Most connections are rather long-lived

This one I think there are measurements about, and I didn't think that they
supported that conclusion.   I think most connections are very short lived.

On the other hand, if you're assuming that connections are long lived,
that has to assume that the address is going to be stable for at least that
period, which would tend to suggest that the A record ought to be able to
be cached for at least a fraction of that time (ideally perhaps a reducing
fraction, so when a node had just received its address it would be
expected to remain for at least several minutes - but after those minutes
had elapsed, a shorter TTL might be more appropriate).

  | Jerry also made an interesting comment that negative caching would be
  | extremely useful in wireless world where mobile hosts are often
  | unreachable or have run out of batteries.

This raises an interesting question though.   If you're only allowed to
cache the affirmative answer you get for a mobile node for a very short
time (or even not at all), for how long should you be able to cache the
absense of an A record for the same node?   If the answer isn't the same,
or even shorter, why?

kre

---

From: Terry Lambert <[email-masked]>
Date: Tue, 07 Dec 1999 15:01:22 -0800

Mikael Latvala wrote:
> To my surprise I received only one message where my
> proposal was dismissed as something which could cause
> Internet meltdown. Because that particular answer did
> not elaborate any further why my proposal might be so
> disastrous I was unfortunately forced to ignore it.
> So in that regard I am still waiting hear from you if
> any studies have been done to find what happens to the
> core network when the TTL is decreased to zero.

From personal experience, I would urge you to not be so
quick to dismiss the argument, merely because it is
convenient for the use-model you want to employ.  I
can't speak for everyone, but I didn't complain about
your suggestion becaquse the consequences were, to me,
self-evident.

---

The offensive thing that happens is not so much that
your servers can't cope with the traffic for the
domains that they are handling, but that the root
servers get hit more often.  If the use model is
widely deployed, that quickly becomes "too often".

This is bad; DNS is predicated on the idea that cache
hits will be more frequent than cache misses; this is
a necessary part of the scaling model for DNS, since
the root servers don't expect a lot of direct contacts.

One situation that was faced by Whistle was the lack
of a capability to do "blind secondary" support (see
ftp://ftp.whistle.com/pub/terry/drafts/draft-lambert-dns-bsec-00.txt )

Lacking this capability, a dialup server that believes
that its DNS is authoritative for the domain won't
do the necessary zone transfer from the primary at
the NOC to obtain the MX list to which it should send
its ETRN requests.  The correct way to fix this is
actually to do a slpit horizon DNS on the box, binding
an authoritative server to the LAN connection for local
machines, while binding a stealth slave to the WAN (see:
ftp://ftp.whistle.com/pub/terry/drafts/draft-lambert-dns-split-00.txt ).

In order to work around this problem, we would go out
to the top level DNS, and work our way down from the
root servers to obtain the name of the authoritative
(from the point of view of the Internet, instead of
from that of the dialup server) DNS to locate the MX
records, as visible to the Internet.

Needless to say, this was frowned upon, but without
the drafts advancing, there was very little we could
do in terms of ensuring that the locally cached DNS
information was correct, or to enable the idea that,
even though the local DNS was authoritative for the
domain, that a request should be forwarded from the
LAN request to the WAN server, in order to get the
zone transferred data; the correct soloution for this
was to do a proxy subdomain delegation for external
servers defined in the outside database, and then do
the lookup against the "delegated" subdomain (see:
ftp://ftp.whistle.com/pub/terry/drafts/draft-lambert-dns-pns-00.txt )

---

Right now, there is a heavy push for Dynamic IP in a
lot of areas for supporting customers, and particularly
as a cost control mechanism.  The largest problem that
you get when trying this is a lack of sufficient disconnect
notification.

On could easily envision a scenario where you have a
transiently connected server that connects via dialup
assignment of a Dynamic IP address.  The server sends
an "ETRN" to your NOC, and the NOC then proceeds to
perform a queue run, looking up the target IP address
for the domain in the DNS, and getting a TTL of 0 back
in the response.

The problem with doing this is that you need to make
sure that you get disconnect notification, otherwise
when the NOC goes to connect to the SMTP server on the
other end, it can get the DNS information

For a IP address, if you could assume that it would
not be given out to a new customer for some set period
of time, then a "keepalive" of one half-life of the
address reassignment would be sufficient to provide a
discopnnect notification.

Without this, you must do /30 delegations from your
own IP address blocks (to enable OSPF-based routing),
effectively giving you a block of dynamic IP addresses
that you control, but which you can outsource the point
of presence to a third party point of presence provider.

This approach lets you control the reassignment pool
retention time, giving you direct control over the
half-life, and also very nicely deals with the RADIUS
accounting record (UDP-based) problem that would otherwise
show up using proxy-accounting from the POP-provider's
pool of Dynamic IP addresses.

---

All of this still fails to address the TTL=0 issues.

The way you address the TTL=0 issues is to ensure that
the NOC itself runs a split horizon DNS, so that the TTL=0
records are only visible to your mail servers, which will
be servicing the ETRNs.

One issue that you are going face with this is that you
will need to run a split address space, as far as the mail
servers are concerned.  This can be a serious issue, if
you can't make the disconnect notification.

Possible approaches to this include:

o	Callee-authenticates-to-caller (the reverse
	of SMTP AUTH, per RFC 2554, where caller auths).

o	Creation of a virtual circuit, using PPPOE

o	Creation of a virtual circuit, using VPN

The first is yet-anoth-standard to try to push through,
whichle the second and third are very expensive on the
NOC side.

---

> I would agree with [email-masked] that the biggest
> problem with this approach is the fact that some
> applications might do their own caching. I do not know is
> there some Internet programming bible which says that
> applications should always perform a DNS lookup before
> opening a connection. If not, one could easily state that
> that's something that most of the applications should do.
> After all, even static IP addresses are not fixed in
> concrete. So from that point of view applications which
> do not perform a DNS lookup before opening a connection
> could be considered broken.

TTLs are supposed to be honored by anyone doing caching.

Unfortunately, this is not always the case, and it is
not really reasonable to expect that it would be.  I am
familiar with several DNS implementations that set a
server-wise "minimum TTL", and substitute it for any TTL
below the administratively configured minimum.

This is evil, but it is more common than you would suppose.

To deal with this, you should only _rarely_ let out Dynamic
IP addresses that have been updated via DNSUPDAT.

For example, it's useful to externalize "vpn.example.com"
or "pop3.example.com", or even "mail.example.com", so long
as they do not collide with the existing externally visible
DNS names.  These do not persist, but...

It seems to me that if you knew the "half-life", that a
TTL of the half-life of the dynamic IP address assignment
would not be unreasonable.

> Also, as pointed out by Jared, making TTL 0 would not
> necessarily be so bad because all but the last response
> to queries in recursive resolution process could be cached.

That's not how most MX software works, in practice.  In
practice, it doesn't do the standard resolver caching
for "parent" when looking up "child".

> Only the response from an authorative name server could
> not be cached thus not introducing too much extra traffic

For most TCP, this is true.

For WWW, without HTTP 1.1 persistance, this would be
Bad(tm), and similar things can be said about most
file sharing protocols, built on top of datagrams.

Also, the point about mobile IP is actually rather badly
formed: it seems to me that mobile hosts will tend to
run caching-only DN servers (though this might take a
while to find its way to Windows, this is common practice
in the more technically correct sections of the net).

Finally, the "ICQ" stuff is rather a server, even if
it is called a "client" because it registers your IP
address with a directory, such that people can contact
you, so even for "pure" clients, what you say isn't
really true.

> Jerry also made an interesting comment that negative
> caching would be extremely useful in wireless world
> where mobile hosts are often unreachable or have run
> out of batteries.

This is a maxim: "Negative caching is twice as valuable
as positive caching, when applied to any hierarchical
data store that requires full iteration of the contents
at the current level on a cache miss".  It applies to
DNS as well as it applies to directory name lookup caches
in file systems.

I don't really think that the machine being unreachable
is even really a deciding factor in its utility.

> Now, "TTL20" is not meant to replace MobileIP or any
> other mobility mangement (MM) mechanism. Rather, it
> should be used together with some particular MM so
> that mobile users can move seamlessly e.g. from WLAN
> environment to cellular environment. TTL20 just makes
> it possible to establish a connection to a mobile host
> which was given a dynamic IP address

The problem with this statement is it contradicts your
claim that "Mobile hosts are unlikely to act as servers";
you claim that, and then you go on to attempt to "fix"
the problem that you claim isn't a problem.

I see the Dynamic IP issue as applying mostly to transiently
connected devices which _are_ servers (see above).

> (yes, this tries to fix one of the inconveniencies caused
> by IPv4 address depletion).

Yes; that and differential pricing, in places where there
is no depletion, but in which the pricing differential is
driven by a "we differentiate pricing because we can"
attitude.

The IPv4 address space issues really apply, for the most
part, to non-US locations.  That's why IPv6 deployment is
more likely to occur in France and Japan, and why INRIA
and KAME (in each country, respectively), have been some
of the major driving force behind IPv6 developement and
deployment.

However, there are still common practice issues that
appear to be ready to be carried forward from IPv4 to
IPv6, and thus all of the address space in the world
will not solve the underlying problems.

On serious problem, that has yet to be adequately addressed
by this working group, is dynamic update of reverse mappings
whose forward mappings are the result of stateless IPv6
autoconfiguration.  We are supposedly willing to route
packets for these folks in and out of our networks, but are
unwilling to let them provide reverse names for themselves,
even if they have obtained forward mappings from a "home"
domain using some cryptographically secure method.

> It should not be confused either with SIP which
> facilitates personal mobility. SIP is designed for
> multimedia applications. It is unlikely, however,
> that other applications, e.g. email, web-based push
> services, would use SIP.

Worst case for email: UUCP of TCP and pull-based instead
of push-based mail retrieval.  Ugly, and expensive for
your NOC, but workable.

For web based push services, one could argue that you
should make a virtual circuit back to the "pusher" in
order to be able to "subscribe" to such services.

The real problems we are facing here are the lack of
transport level security and virtual circuits (or the
expense associated with maintaining same) for transiently
connected hosts.

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

---

From: Jerry Scharf <[email-masked]>
Date: Tue, 07 Dec 1999 17:09:29 -0800

I think focusing on the mobiles as a special case is right. I will make the 
assumption that we are not looking at mobile versions of home.netscape.com.

I think the in-addrs will generally (handwaive) get hit more than the forwards 
for these mobile machines, assuming their nature as clients. Given it's the 
rate of reuse of the address space that drives the timeout here rather than 
the mobility, it is a reasonable engineering effort to set the in-addr TTLs to 
something like 60-120 seconds. This makes the problem less abusive on the DNS 
environment without risking the mobility. Just a small matter of programming 
plus some intelligence on the part of the roaming address assigner.

jerry

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 08 Dec 1999 14:40:20 +0100

At 10:08 08.12.99 +1100, Robert Elz wrote:

>"broken" is pretty dumb (they obviously are - they simply don't work).

There's a shareware product out there that "speeds up" your network 
connection by hooking into the Windows resolver library and appending 
anything seen there to the Windows equivalent of /etc/hosts.

There ARE applications where the only problem with calling them "broken" is 
that it's a relatively polite term.

                        Harald A

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Terry Lambert <[email-masked]>
Date: Wed, 08 Dec 1999 10:27:48 -0800

Jerry Scharf wrote:
> 
> I think focusing on the mobiles as a special case is
> right. I will make the assumption that we are not
> looking at mobile versions of home.netscape.com.

Now I am confused.

It was my understanding from Mikael's posting that he
was specifically _not_ addressing the mobile IP issue,
and that his real issue was the use of DNS in the face
of Dynamic IP address assignment to servers.

He specifically excepted the idea of mobile servers
(even though he rereferenced them as a rationale for
one of his arguments -- something I put down to a
mistake).

Mikael:

Could you specifically state the problem you are trying
to solve, without referencing TTL=0 as a possible soloution?

In other words, can we get a problem statement, rather
than a problem statement and a suggested soloution?

If I was right about my assumptions, I think I agree with
you on some of this (having just implemented a NOC capable
of 100,000 virtual domains on one machine), but I think I
disagree on the actual location of the problem, and the
soloution that should be applied.

Thanks,
-- Terry Lambert

---

From: Mikael Latvala <[email-masked]>
Date: Thu, 09 Dec 1999 17:50:30 +0200

Problem statement:

In the future people will have mobile devices, i.e. mobile phone with IP
capability, which must be identified somehow so that other hosts in the
Internet can reach it. Conservative estimates say that within the next 5
years there is going to be 1 billion mobile customers and most of them will
be using services which require an IP address.

Because of the IPv4 address depletion problem ISPs (read cellular operators)
won't be able to assign static IP addresses to their customers' mobile
devices.  Therefore IPv4 addresses cannot be used to identify those mobile
devices.

What comes to mind after having dismissed IPv4 address as a viable
indentifier, is to use DNS names to identify mobile devices (e.g.
7023451234.voicestream.com). In order to guarantee that mobile devices can
be reached at all times name servers must not cache forward name/reverse
address mapppings. To make sure that this happens authoratative name servers
must always assign TTL to 0 in their responses and that value must be
honoured by local name servers.

Does this work? What are the implications on the core networks?

/Mikael

P.S. Mail archive of this mailing list is pretty badly out of date (the last
massages strored are from October).

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 09 Dec 1999 15:22:51 -0500

Why a TTL of 0, and not, say, a TTL of a small fraction of a minute
(anywhere from 5 to 60 seconds as has been proposed here?).

Routine use of a zero TTL seems extremely problematic and dangerous to
me.  I also suspect you may run into interoperability problems in
certain environments, depending on the exact queries you're doing..
(I can see some implementations prematurely expiring data from the
cache while processing SRV and MX and A6 records, which may involve
multiple DNS queries to fully resolve a name to the desired values).

I'm also willing to believe that there may be some apps out there
which do multiple queries of the name to address mapping shortly
before connecting; with a small non-zero TTL, these would end up
hitting in the cache the second and subsequent time..

A non-DNS distributed naming system I've worked with in the past
(which also did TTL-based caching) wound up having some very
non-intuitive performance properties when TTL's were set to zero.

Anyhow, I'd like to understand the problem a little better -- I can
understand that a phone would get a new ip address if it wasn't active
for a while, but it doesnt' seem like it would be so hard to arrange
for it to keep the same address while it's actively using the network,
possibly maintaining two addresses for a little while in the course of
a handoff, under the "don't let go with both hands at once"
principle..

					- Bill

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 09 Dec 1999 14:47:30 -0800

Mikael,

> be using services which require an IP address.

Would seem to be a reasonable justification for IPv6...
 
> 7023451234.voicestream.com). 

I'm not following this.  Are you suggesting replacing the IPv4 address in the
IP header with a DNS name?

Rgds,
-drc

---

From: Mikael Latvala <[email-masked]>
Date: Fri, 10 Dec 1999 15:44:18 +0200

> Would seem to be a reasonable justification for IPv6...

No kidding. But what if most of the operators/service providers do want
to stick with IPv4. Anyways, I don't think that we should get into this
IPv4 vs IPv6 discussion here. My problem is that I need to identify MSs
which use IPv4 addresses, NOT IPv6.

> IP header with a DNS name?

No, I am suggesting that you put your social security number and credit
card number in the IP header and watch criminals enrolling in
wiretapping classes. 

Seriously, I thought that it was pretty clear with my intentions.
Because most of the host, especially MSs, are not given a static IP
address, domain names could be used instead to indentify MSs. Now,
that's a truly novel idea.

/Mikael

---

From: Mikael Latvala <[email-masked]>
Date: Fri, 10 Dec 1999 15:43:31 +0200

Terry,

> the root servers don't expect a lot of direct contacts.

If most of the queries done by local name servers are non-recursive
how would those queries put extra load on the root servers if the
authoratative name server uses TTL value 0? I mean, wouldn't a 
local name server cache all the referals leading to the 
authoratative name server but not the final answer (which is 
the only one we don't want to cache). In that case if another host,
another application on the same host, or the same application wanted
to reach the same mobile host at later time most of the work would 
have already been done. The local name server would have to send only
one query to the authoratative name server. 

You point out later on that most MX software doesn't do the standard
resolver caching. Maybe so, but I don't think that most of these
MSs would receive their mail in the manner you describe below (using
ETRN command)

> you get when trying this is a lack of sufficient disconnect

Not a problem in cellular systems. E.g. in GPRS the mobile station 
(MS) explicitly signals when it wants to end its session (in GPRS 
jargon called PDP-context).

> other end, it can get the DNS information
[...]

I do not understand why this ETRN and split horizon DNS talk applies to
MSs (reason why I cut off a large section above). MSs use IMAP or POP to
fetch their mail.

> This is evil, but it is more common than you would suppose.

Thanks for pointing this out. But that can be hardly used as an argument
to dismiss TLL 0 idea. i.e. implementations which do not follow the
standard are hardly in a position to say what could be done.

> would not be unreasonable.

Give me some pointers and I'll read about this "half-life" thing.

> in the more technically correct sections of the net).

Mobile hosts running a DN server? I don't think so. At least not MS
(mobile stations) which are the future devices people use to access
services in the Internet. On MSs you want to have the bare minimum and
DN server does not belong to that group.

> is even really a deciding factor in its utility.

Did I say "the machine being unreachable is even really a deciding
factor in [negative caching] utility."? What's your point you are trying
to make? 

Anyways, thanks for you insightful comments (I mean that).

/Mikael

---

From: Terry Lambert <[email-masked]>
Date: Fri, 10 Dec 1999 11:51:04 -0800

Mikael Latvala wrote:
> If most of the queries done by local name servers are
> non-recursive how would those queries put extra load
> on the root servers if the authoratative name server
> uses TTL value 0? I mean, wouldn't a local name server
> cache all the referals leading to the authoratative
> name server but not the final answer (which is the only
> one we don't want to cache).

It depends on what you set a TTL=0 on.  If you only do
it on the terminal records, then the effect is lessened,
but not eliminated.

Consider the case of "transient.example.com"; the path
to the ., com., and example.com. authorities can be
cached.  But the answer for transient.example.com. is
not cached.

This isn't a problem, if you ignore network effects (i.e.
you are only considering a single client machine).  But
if you include them, then what it means is that no
intermediate servers can cache this data, and so their
load, as well as the load on the example.com. authority,
will be increased.

Worst case for this would be something like HTTP 1.0,
where there is a lookup and a connection for each of a
large number of clients for each of a large number of
things (HTML pages in frames, images, etc.) being
downloaded.

This is ignoring the in-addr.arpa. cache busting that
reverse records, also with a TTL=0, would have.

I don't know your personal experience, but mine says that
people send out email with interesting links to groups of
people that they work with, or give the URLs verbally to
people in adjacent cubes.  This already leads to the now
infamous so-called "slash dot effect" on a small scale.

> In that case if another host, another application on
> the same host, or the same application wanted to reach
> the same mobile host at later time most of the work
> would have already been done. The local name server
> would have to send only one query to the authoratative
> name server.

But not all of it, which is rather the point: setting
TTL=0 is effectively doing to DNS what removing the L2
cache chips would do to your computer.

> You point out later on that most MX software doesn't do
> the standard resolver caching. Maybe so, but I don't
> think that most of these MSs would receive their mail
> in the manner you describe below (using ETRN command)

This is rather the point, I think, given your mobile
phone example.

In your example, we have a name (the phone number) which
corresponds to a Dynamically assigned IP address for some
period of time.

Ignoring the other arguments that have been put forth as
to actual minimum lifetime of the the IP assignment, the
promotion by many DNS servers to some minimum (300 seconds
was quoted) regardless of your servers TTL preference, and
the fact that you could LRU IP address assignmnets to make
a "heartbeat" window...

I think that it's actually wrong to have the servers
contacting the telephones, instead of the other way
around.

The Pointcast application, and multicast video over the
mbone, both work on the "subscriber" principle; that is,
that the client machine contacts the server in order to
obtain data.

If the point of your exercise is to provide not only
the standard stock quotes and news information that
you can currently push (broadcast, BTW) over the pager
system, but also additional services, like proactive
precaching of custom portal pages, etc., I think you
would be better served by telling the phone to contact
the server.  You could do this the same way you tell
the phone that it has a phone call: without the need
for the server to know the phones IP at all.

Alternately, as others have suggested, this is an
ideal candidate for an IPv6 deployment.  The lack of
an existing competing IPv4 based deployment means that
this is actually a _better_ idea, in the long run, for
dealing with the problem.

> Not a problem in cellular systems. E.g. in GPRS the mobile
> station (MS) explicitly signals when it wants to end its
> session (in GPRS jargon called PDP-context).

I think that if you insist on having a DNS entry per phone
(which I think is wrong; see above), that you would be best
served by IPv6 stateless autoconfiguration onto your IPv6
network through your cellular gateway, and then doing very
long lived (TTL=<some large number>) DNS updates.

I still think that the way to do this is to use some
out of band signalling (like paging, ringing the cell
phone, etc.) to tell the phone to ask the server for
the data, rather than contacting the phone directly via
its IP address.

> I do not understand why this ETRN and split horizon DNS
> talk applies to MSs (reason why I cut off a large section
> above). MSs use IMAP or POP to fetch their mail.

MS == Mobile System, from context.

It barely applies; i didn't realize that you were really
attempting to solve a mobile IP problem in the context
of IPv4 and the DNS, since I assumed that the soloution
space for that was IPv6-land.

The reason it barely applies is that the transiently
connected system is responsible for contacting the
central server and _asking_ for content, instead of
the central system contacting it to push content at
it, which seems to be what you want to do.

The fundamental issue you need to address in your
design appears to be coming up with a reason why you
feel it is necessary for the central server to contact
the MS in-band, using DNS to make the contact.

You would almost be better off with a system that
allowed a DNS lookup of a particular name to result in
a reservation of an IP address on behalf of that name,
so that a subsequent non-DNS contact would have the IP
address _that will be assigned_ to the MS.

I think such a system is eminently workable, using a
pool of IP addresses sufficiently large that an LRU
on the assignments from the pool lets you set a TTL=300
or so.

It would be even better if you were to do the directory
management thing yourself, in the way that ICQ works,
only in reverse.  In other words, your protocol has the
name of the system it is attempting to contact, and it
contacts a proxy on behalf of that system.  The proxy
then handles the DNS under the covers.

There is a nice VPN-type application that utilizes this
for remote network access: it puts up a web page, and
you click on the URL for the system you want to talk to;
it tickles the system you want to talk to, and then that
system calls in.  It then communicates its IP address to
the proxy, which then communicates it by updating the
web page, which is reloaded by a Java listener (you could
as easily have used "multipart/refresh" for this).  You
then click on the new URL, and are connected to the
system that you wanted to VPN into.

> Thanks for pointing this out. But that can be hardly used
> as an argument to dismiss TLL 0 idea. i.e. implementations
> which do not follow the standard are hardly in a position
> to say what could be done.

Tell Microsoft Outlook.

Seriously, the idea may be sound, but the venue for it
must be a new protocol that is not already deployed, or
you will not be able to guarantee any level of service.
You will set the expectations of your users, and then
not be able to deliver to those expectations.

To turn it around, people who want to use a TTL=0 are
hardly in a position to dictate that everyone on the net
upgrade their DNS servers.  If we could dictate things
like this, there wouldn't be a SPAM problem.  8-).

> Give me some pointers and I'll read about this "half-life" thing.

It's simple math.

If I have some number of seconds 'N' that I know that an
IP address will not be reassigned following a disconnection,
then I know that if I verify that the connection is up every
(N/2) - 1 seconds, that I will never attempt to contact the
machine allocated that IP address and get a different machine
that has been reassigned the address following a disconnection
and an IP address reassignment.

For your particular case, if I have a TTL of (N/2) - 1, then
I can always kill the entry before a cached copy of it has
become invalid, as a result of losing the "heartbeat" (ping).

For all of the servers that have been discussed in this
thread, that means you need a minimum of X = (N/2) - 1 = 300,
so N = 601 seconds of latency between IP address reassignment
to escape the TTL=300 promotions that are going to happen
anyway.

My personal problem with SMTP/ETRN/Dynamic IP interaction
exists because of the way the SMTP contact negotiation and
queue run works.  Your protocol design need not have these
same problems; I'm stuck with mine, for interoperability
reasons 8-(.

> Mobile hosts running a DN server? I don't think so. At
> least not MS (mobile stations) which are the future devices
> people use to access services in the Internet. On MSs you
> want to have the bare minimum and DN server does not belong
> to that group.

You have three choices, if you want to use DNS this way:

1)	Implement a caching server on the device
2)	Implement caching in the resolving library on the
	device, and make sure your applications use it
	precisely the right way, perhaps by defining a
	new resolver API
3)	Implement caching in every one of your applications

At least with option #1, you get consistancy. Option #2
would work, if you designed a new API that precluded any
way to avoid the caching effects.

Both option #2 and option #3 duplicate data, and a small
footprint device really can't afford to let duplicate
data live.

If you use your own directory mechanism instead of DNS,
then your possibilities are much, much wider.

> > > where mobile hosts are often unreachable or have run
[ ... ]
> Did I say "the machine being unreachable is even really
> a deciding factor in [negative caching] utility."? What's
> your point you are trying to make?

Just that negative caching is extremely useful, regardless
of whether or not you are talking wireless or mobile, or
something else.  The additional context connected to it
made it look like a revolutionary breakthrough for wireless
communications, which is not how I think Jerry intended his
comments.  I think he intended them to apply to the geometry
of the soloution space, not limit them to the problem space
to which the soloution is being applied.

I didn't mean to impugn your comment, but out of context,
it seems to say that outside the problem space under
discussion, negative caching is less useful.

> Anyways, thanks for you insightful comments (I mean that).

No problem; I've been struggling with the issues surrounding
using Dynamic IP address assignment for over two years now,
and have been a bad boy and pounded on root servers and done
all sorts of other nasty stuff.  It's nice to be able to
discuss ones mistakes so that they aren't repeated.  8-).

-- Terry Lambert

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Dec 1999 11:05:40 -0800

> that's a truly novel idea.

It seems to me that what you really need is a combination of a
non-fixed, but nonetheless reasonably persistent IP address and a good
DNS update ritual.   Trying to use zero-TTL DNS names is very
expensive, and assigning static IP addresses is too, but there must be
a middle ground.

			       _MelloN_

---

From: [email-masked] (David C Lawrence)
Date: Fri, 10 Dec 1999 16:43:45 -0500 (EST)

David Conrad:
> > I'm not following this.  Are you suggesting replacing the IPv4
> > address in the IP header with a DNS name?

> card number in the IP header and watch criminals enrolling in

Hey, no need to be snippy.  It was a legitimate question.  It really
isn't clear where you intend to use this identifier.

> that's a truly novel idea.

It *still* isn't clear, at least not to me, and you'll pardon me for
not assuming that's because I am an idiot.

You keep talking about "identifying [mobile stations]" but it isn't
clear who or what you are trying to identify them to.  It appears you
either mean to other human beings and/or software that would want to
contact the device, or the underlying IP layer that actually performs
the contacting.  

In the first case, there's nothing novel about what you said.  It is
just like any other device on the network having a name, as has been
done for decades.  Of course, the underlying network still needs to
know how to actually route the packets, so at some level an IP (v4 or
v6) is needed.  We probably all agree static v4 addresses are a bad
idea, so if you want the v4 network, you use DHCP with a suitably low
TTL (*but not 0*, as others are explaining).  Or you use v6.  Not novel.

On the other hand, if you are talking about this identifier being used
on the routing level, being used to actually get packets between a
source and destination, then you are talking about what David said ---
which surely is a novel idea, but one not likely to go far.  It would
require *massive* overhauling of the way the Internet works.

Clearly I'm missing something about the way you view this, and I
suspect I am not alone.  Please expand on how you view this identifier
being used.

---

From: "David R. Conrad" <[email-masked]>
Date: Fri, 10 Dec 1999 20:24:00 -0800

Mikael,

> No kidding. 

I was merely making an observation, not indicating IPv6 as a solution to your
specific problem (albeit it would be one and the v6 crowd look to be searching
for a easy to point at reason for people going to the trouble of making the
transition).

> Seriously, I thought that it was pretty clear with my intentions.

No, it isn't, at least to me, or I wouldn't have bothered asking in an attempt
to help, now would I?

Given my lack of knowledge about the cellular phone system, I don't understand
why the obvious solution of dynamic DNS (perhaps using simple secure update)
with small (but non-zero) TTLs and DHCP with relatively short leases would not
solve the address scarcity issue the mobile phone providers face.  I assume
there is a reason.  Perhaps it is the issue of maintaining TCP connections
across mobile service provider boundaries?  In any event, if you would explain
(in a non-condescending fashion) I'm sure more people would bother trying to
understand why you feel you need zero TTLs.

Rgds,
-drc

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 11 Dec 1999 23:09:13 +0100

>contacting the telephones, instead of the other way

.....

>  I think you

This assumes, of course, the existence of something apart from IP over 
which the phone can be told something.

If the intent is that the phone call (or the phonecall-like connection) 
should arrive over IP to the phone (or phone-like-object), then somehow you 
have to have the calling entity (switch, server or originator) find out the 
IP address of the phone.

Once IP becomes The Network, you can't assume the existence of back channels.
Today's rant.

                     Harald A

---

From: Ted Lemon <[email-masked]>
Date: Sun, 12 Dec 1999 13:33:21 -0500

> have to have the calling entity (switch, server or originator) find out the 

If I have this right, it sounds like you're putting a static IP
address in the phone, and then having the mobile phone infrastructure
somehow do dynamic routing to that phone in realtime.  Why not use
DHCP, or some mobile-IP-targeted protocol, and give the phone an IP
address that varies depending on where it's connected?  Or am I just
not understanding what you have in mind?

			       _MelloN_

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 12 Dec 1999 21:38:05 +0100

At 13:33 12.12.99 -0500, Ted Lemon wrote:

>> should arrive over IP to the phone (or phone-like-object), then somehow
>> you have to have the calling entity (switch, server or originator) find
>> out the IP address of the phone.

>not understanding what you have in mind?

Your suggestions seem like eminently sensible ways of connecting to a phone.
All I'm saying is that this, too, will be done using IP-family protocols.

                     Harald

---

From: Terry Lambert <[email-masked]>
Date: Mon, 13 Dec 1999 11:53:41 -0800

Harald Tveit Alvestrand wrote:
> This assumes, of course, the existence of something
> apart from IP over which the phone can be told something.

Like a timer.  8-).

Ericsson is a Swedish company; I suspect that anything
they built would be used there before being shipped out
of the country, if only in labs.

The IPv4 address space exhaustion issue, which he appears
to want to work around by using Dynamic IP assignment,
and then the dynamic DNS workaround for the IP being
dynamic to allow an outside machine to contact the phone,
and then the TTL=0 workaround for having too small a pool
of dynamically assigned addresses to be able to guarantee
that the TTL will be less than the pool retention time
before an IP address is reassigned...

Sorry, but honestly, that's a kludge on a kludge on a
kludge on a kludge.

The obvious non-kludge answer, which will require a
gateway server until IPv4 goes away, is IPv6, using
either static address assignment, or, to be more cell-phone
like and help routing, IPv6 stateless autoconfiguration.

Then the only thing of interest to this list is DNS
records for the static assignments, or enabling reverse
records to be set when we allow autoconfiguration into
the address space controlled by the server, using signature
proxy (i.e. the forward record is updated securely, and
the reversse is allowed to be updated to match the forward
by virtue of the forward update having been vetted by the
forward server, and your allowing the machine to have
autoconfigured on your network).

> If the intent is that the phone call (or the phonecall-like
> connection) should arrive over IP to the phone (or
> phone-like-object), then somehow you have to have the
> calling entity (switch, server or originator) find out
> the IP address of the phone.
> 
> Once IP becomes The Network, you can't assume the existence
> of back channels. Today's rant.

I agree.  My point was that the answer in that case would
be IPv6, and that there is existing, deployed infrastructure
for pushing information to the phone, like "ring now".

If we are talking IP telephony, where IP is the _only_
channel to the phone, then the correct answer is obviously
IPv6, if for phone-to-cellular-switch security reasons
alone.

This doesn't even interfere with CALEA in the US, since
the phone company can intentionally compromise the security
by inserting a man-in-the-middle proxy at the switch (not
that that's a feature, from my point of view).

-- Terry Lambert

---

From: Mikael Latvala <[email-masked]>
Date: Tue, 14 Dec 1999 15:37:29 +0200

[email-masked] wrote:
> Given my lack of knowledge about the cellular phone system, I don't
> understand why the obvious solution of dynamic DNS (perhaps using simple
> secure update) with small (but non-zero) TTLs and DHCP with relatively
> short leases would not solve the address scarcity issue the mobile phone
> providers face.  I assume there is a reason.  Perhaps it is the issue of
> maintaining TCP connections across mobile service provider boundaries?  In
> any event, if you would explain (in a non-condescending fashion) I'm sure
> more people would bother trying to understand why you feel you need zero
> TTLs.

OK, one more attempt.

So, one day there are going to be all-IP mobile phones which have
support for only
data services, i.e. IP technology (yep, WAP is out there and might
seriously hinder this development. That is, however, another long story,
which should be discussed somewhere else, e.g. on the end2end mailing
list. BTW, I have been involved in WAP
standartization work and I can say that I hate it as much as any other
traditional datacom person). These all-IP mobile phones are the only
communication device any mobile user needs, ever. No need to have a
separate phone at work, home, etc, just one mobile phone which will use
automatically the cheapest access method currently available. For
example, I could throw away my home cordless phone and DECT phone at
work and use only my mobile phone which would attach itself
automatically to the DECT network when I come to work.

Companies which will build all-IP mobile phones have to follow the same
rules and regulations than when building traditional voice/data-service
phones. That is, there must be high enough certainty that phones calls
(sorry, I meant to say VoiP calls) get through, phones are always
reachable from the network architecture point of view, voice quality is
at least acceptable, efficient use of bandwidth, end-to-end delay
boundries, etc. The fact that a mobile phone is all-IP does not mean
that it does not have to be as reliable and "good" as a traditional
mobile phone, which is what people have unfortunately come to expect
because most of the current VoIP connections do not deliver voice which
is even close to the toll quality, not to mention the fact that you
could actually assume that you can reach somebody besides your collegue
sitting in the next cubicle.

So, how can we guarantee in IPv4 world (note, NOT in IPv6 so please save
your IPv6 answers/comments for another thread) that these all-IP mobile
phones are reachable at all times? Obvious solution would be to get
enough IP addresses (assigned in a static manner) so that domain names
can be bound to them for as long as needed. I know that IANA is sitting
on a big block of IPv4 addresses (at least 64-127 A class addresses)
which are unallocated. Those could suffice easily for the next few years
so that every new all-IP mobile phone could be assigned a static IPv4
address. My understanding is, however, that IANA is unwilling to
allocate some/most of those addresses (information on whether this is
true, where to get more information on this is greatly appreciated).

Because it seems that there are not enough IPv4 addresses to be assigned
on a permanent basis the obvious solution is to assign IPv4 addresses on
demand, i.e. dynamically and do the domain name binding in the same
manner, i.e. dynamic DNS updates. The big question; what should be the
TTL? 0, or something bigger to make sure that the copies of the data are
as current as possible. This is the reason why I posted my initial
question asking people if they had experinced or simulated cases where
TTL was 0. So far it seems that there have not been done any in-depth
studies where the implications of low TTLs have been studied. Rather,
there seems to be this common practice wisdom which says that anything
close to 0 is disastrous. Poeple have suggested of using value 300 which
sounds to me very arbitrary. Those 6 minutes would save us from
experiencing an Internet meltdown if all all-IP mobile phones would use
TTL 0 instead of TTL 300?! What are these claims based on? 

I am not saying that TTL has to be 0. All I am after is what the lower
limit on TTL should be before things start going heywire. If it is 300 I
want to know where this number came from. Answers like this is what most
DNS servers do, or that it just became de facto 10 years ago are not
acceptable. Neither that some non RFC-compliant DN servers do not honor
TTLs below certain minimum value.

It goes without saying that any reasonable answer would also explain
what were the traffic models it used when determining the TTL.

/Mikael

---

From: Terry Lambert <[email-masked]>
Date: Tue, 14 Dec 1999 14:52:30 -0800

Mikael Latvala wrote:
> So, how can we guarantee in IPv4 world (note, NOT in IPv6
> so please save your IPv6 answers/comments for another
> thread) that these all-IP mobile phones are reachable at
> all times?

You can't, not in an IPv4 world.

> Obvious solution would be to get enough IP addresses
> (assigned in a static manner) so that domain names can
> be bound to them for as long as needed. I know that
> IANA is sitting on a big block of IPv4 addresses (at
> least 64-127 A class addresses) which are unallocated.
> Those could suffice easily for the next few years so
> that every new all-IP mobile phone could be assigned a
> static IPv4 address. My understanding is, however, that
> IANA is unwilling to allocate some/most of those
> addresses (information on whether this is true, where
> to get more information on this is greatly appreciated).

I believe the authority was NSI and is now ARIN, not
IANA, but am willing to be corrected.

You are right: the allocation you are implying will
not be allowed.  Telephony is not the only potential
use to which this address space will be put, and asking
for a reservation of all of it for telephony won't work.

> Because it seems that there are not enough IPv4
> addresses to be assigned on a permanent basis the
> obvious solution is to assign IPv4 addresses on
> demand, i.e. dynamically

The problem with this is that you will need a class A
for each 16 million phones that are simultaneously
active and ready to recieve calls.

There is little difference in your IPv4 address space
requirements between half of all mobile phones turned
on vs. half of them turned off: your requirements are
too large.

In addition, using traditional routing technology, for
OSPF based routing you would be required to deploy /30's
to each phone, which means one class A per 4 million
active, ready to recieve a call, cell customers.

I submit that you would require multiple class A nets
to merely cover the state of California.

> and do the domain name binding in the same manner,
> i.e. dynamic DNS updates.

Even with each phone only having an IP when it is on
and reachable, and each phone having a permanent name
(this is not supported, but you could fake it by hacking
DNS to request leases on behalf of the hardware when
anyone looked up its name, and not respond until you
had a lease in hand), you are still out of address
space.

> The big question; what should be the TTL? 0, or
> something bigger to make sure that the copies of the
> data are as current as possible.

300, so there is never cached stale data, and never
reuse an IP until after 901 (301 after removing the
entry from your DNS, to give time for cached copies
obtained in the last second before time to drain
for 300).  You could reduce the 901 to 601 by making
the TTL "count down" in the master server.  You would
then have to reset it so long as the lease was valid,
every 149, or even more frequently.  In no case can
you assume a cached copy will drain following a removal
in anything less than 300.

> This is the reason why I posted my initial question
> asking people if they had experinced or simulated
> cases where TTL was 0.  So far it seems that there
> have not been done any in-depth studies where the
> implications of low TTLs have been studied. Rather,
> there seems to be this common practice wisdom which
> says that anything close to 0 is disastrous.

I had nearly 1,000 machines pounding on the root
servers for domain delegations, for lack of a reachable
forwarding name server.  I hardly call that a total
lack of data.  It was noticed, it was commented on,
and it was fixed (the ISP had firewalled their DNS
forwarders against use by their customers, since
sending packets costs money in that locale).

> Poeple have suggested of using value 300 which sounds
> to me very arbitrary.

It is.  It's the arbitrary value below which some DNS
servers will promote TTLs to at least 300, so it is the
minimum cache life that you can possibly depend upon
when defining you overall interaction model.

This is unpleasent; there are valid reasons for wanting
a TTL=0.  Alas, wanting does not make it so, and so
both you and I are prevented from using TTL=0 by legacy
DNS servers with which we must interoperate.

> Those 6 minutes would save us from experiencing an
> Internet meltdown if all all-IP mobile phones would use
> TTL 0 instead of TTL 300?!

No.  Those 5 minutes would not necessarily save the world
from a meltdown, merely because they represent a potential
maximum 30,000% increase in DNS traffic.

> What are these claims based on?

They are based on the fact that if you set a TTL of zero,
and then give someone a Dynamic IP address for the name
"777-7777.phone.net", and then you reassign the IP address
to "555-5555.phone.net" in under 300 seconds, anyone calling
"777-7777.phone.net" by name will possibly get a cached
copy of the "777-7777.phone.net" IP address, which has been
reassigned to "555-5555.phone.net".

And so, they will call your cell phone, and I will answer
the call on my cell phone.  This is not desirable or
expected behaviour for cell phones.

-- Terry Lambert

---

From: Mikael Latvala <[email-masked]>
Date: Wed, 15 Dec 1999 16:19:06 +0200

David,

> IANA, but am willing to be corrected.

Both wrong, it was IANA, now it is ICANN. ARIN is just a Regional
Internet Registry.

> on vs. half of them turned off: your requirements are

yup. Especially "always-on" would make dynamic IP assignment/DNS updates 
a somewhat moot point. However, there are plenty of things operators can
do on that sector, e.g. offer incentives not to sit on an IP address for
too long, just like what ISPs are doing today, if you want a static IP
address you pay extra.
For example Phil Karn from Qualcomm has written an excellent paper where
he explains why most of the folks are very happy with dynamic IP
addresses, see
http://people.qualcomm.com/karn/papers/mobility.html.

> sending packets costs money in that locale).

Interesting, when did this happen, at what frequency those machines sent
DNS queries, what happened to the root servers, what kind of hosts
(server, clients) were those which sent DNS queries, lots of kids
surffing or lots of email users, etc.?

> maximum 30,000% increase in DNS traffic.

Ah, another number I remember seeing before. Indulge me and tell where
you got this 30,000%?

/Mikael (whose arithmetic sucks)

---

From: Edward Lewis <[email-masked]>
Date: Wed, 15 Dec 1999 09:26:21 -0500

>TTL? 0, or something bigger to make sure that the copies of the data are

It seems to me that the question is "What should be the duration of the
DHCP lease?"  The problem of setting the TTL on DNS records resulting from
DHCP activity is already an ongoing issue without a good solution.  (E.g.,
if the TTL is advertised as 1/2 the remaining lease duration, how will this
impact the signature over it and the zone's serial number?)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda

Opinions expressed are property of my evil twin, not my employer.

---

From: Erik Sherk <[email-masked]>
Date: Wed, 15 Dec 1999 04:10:03 -0500

> You can't, not in an IPv4 world.
[Deleted...]
> active, ready to recieve a call, cell customers.

You wouldn't use an IGP for this because you don't care where
the cell phone is, you are interested in the location of the 
cell. So you would use something like BGP to associate an
IP address with the address of the cell and then you would use an 
IGP to get to the cell. 

Erik

---

From: "David R. Conrad" <[email-masked]>
Date: Tue, 14 Dec 1999 23:22:31 -0800

Mikael,

> My understanding is, however, that IANA is unwilling to

I can say with a fairly high level of assurance (I am an ARIN Board of
Trustees member and the person who started and ran APNIC for 4 years) that it
is highly unlikey (to put it mildly) that the remaining Class A pool would be
allocated for this purpose.  You would first have to demonstrate why a more
dynamic solution would not be feasible, which leads us to:

> manner, i.e. dynamic DNS updates. 

Right.  The number of addresses should be limited to the maximum number of
phones "on" at any given time.  Presumably this number is determined by the
capacity of the underlying phone infrastructure and addresses would be
assigned (via DHCP?) from that pool when people turned their phones on (or
they roamed into range).

This is, of course, exactly the problem IP Mobility Support (RFC 2002) set out
to solve.  But I gather you are looking for another solution.  

> The big question; what should be the TTL? 

The problem is that the TTL of a name is only relevant during "session"
initiation -- once communication is established, no client or server network
code I am aware of takes note of a change of name/address mapping (TTL
expiration or otherwise), thus a non-Mobile IP solution would need to be able
to ignore the fact that one part of the 4-tuple used in layer 4 sessions has
changed.  This would imply that the phones would be unable to do any TCP or
any of the UDP services that maintain state based on who you are talking to.

However, assuming you are doing an overlay on top of UDP or something, the
only way setting TTLs to 0 would help anything is that for each and every
packet sent, a DNS lookup was performed.  This would have a somewhat ... um...
suboptimal effect on network traffic (at least 2 additional packets for each
packet of data to be sent) and latency (particularly given there is no
caching).

> This is the reason why I posted my initial
> TTL was 0. 

In the course of this discussion, there has been ancedotal evidence posted
indicating that TTL 0 may simply not work for at least some portion of the
(arguably broken) TCP/IP stacks out there, but I know of no in depth study of
the ramifications of TTL 0 on the Internet as a whole.  Such a study would be
a bit difficult given the distributed nature of the DNS and/or the
difficulties inherent in trying to model Internet behavior.

Rgds,
-drc
Executive Director, Internet Software Consortium
Director of Engineering, Internet Engines, Inc.