ietf
[Top] [All Lists]

Re: Persistent applications-level identifiers, the DNS, and RFC 2428

2003-10-01 13:05:23
--On Wednesday, 01 October, 2003 14:35 -0400 Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:

John,

The extensions in 2428 are in wide use, and they work just
fine.  I don't see any reason to change them.

Nor do I believe there is consensus that applications should
always be passing names in preference to IP addresses.  And
until there is a system for assigning stable names to hosts
that are independent of any administrative domain (since hosts
often don't live in a single administrative domain), and
quickly and reliably mapping from those names to IP addresses,
the idea that applications should pass names in preference to
IP address is something that I would classify "fantasy"  at
best.  In particular, DNS is not sufficient to replace IP
addresses in this role.

see also
http://www.cs.utk.edu/~moore/opinions/ipv6/dns-as-endpoint-id.
html

Keith, you are starting down the path I was hoping to avoid, so maybe my specific concern and suggestion wasn't clear. If is is working well as is, then I withdraw even the hint of deprecating the thing. My main objection to 2428 is not that it _permits_ addresses, but that it provides no option other than addresses and nothing on which to hang a DNS name or other identifier if one has one. That, it seems to me, is poor protocol design going forward, since it implies that the next new identifier requires yet another set of command keywords.

I suggest that it is useful, indeed important, to have a way to express and use DNS names --and, potentially, other identifiers-- as an alternative to addresses, if only because they isolate the near-user interface of the applications protocol from having to know which transport is to be used. Unlike a number of other situations in which I would agree with you, neither the "stable name" issue nor the independence of administrative domain one are significant here -- we routinely set up FTP command connections using DNS names, there are likely to be many circumstances in which it would be equally appropriate to set up the data connection that way, and FTP data connections don't persist (significantly) longer than the command connection.

We can debate --and work out-- the applicability statement that explains when one model or the other should be used. But the protocol should, at least, support the alterative of passing a name.

regards,
    john

I just had occasion to look again at RFC 2428, "FTP
Extensions  for IPv6 and NATs",  M. Allman, S. Ostermann, C.
Metz. September  1998, and to think about in the context of
the recent  flame-war^H^H^H^H^H^H^H^H^H discussions about use
of IP  addresses in applications.   2428 provides additional
syntax and  mechanisms for FTP to deal with IPv6, with some
useful  properties for NATs (useful if you believe in NATs).
It appears  to provide only for addresses and does not appear
to be  extensible except to the addressing formats of new
versions of  IP.

It seems appropriate to ask whether 2428 should be opened and
given at least the capability of passing DNS names and maybe
some syntax that would permit clean extension to future
identifiers.  In the unlikely event that there is
insufficient  interest or energy to do that work, should it
be moved to  historic or otherwise given a "not recommended"
status as  potentially harmful and inconsistent with the
principle that  applications (especially for IPv6) should be
passing names and  not IP addresses?

Please consider this a fairly narrow question.   I don't want
to  start either the "applications level identifiers" debate
or the  NAT wars again and they aren't necessary to answering
the  question.  On those topics, please, everyone, your
points --pro,  con, or otherwise-- have been made and anyone
who is going to be  convinced has been convinced.  More
traffic on those subjects in  the guise of responding to this
question will just convince more  people that it is
impossible to carry out a technical discussion  on the IETF
list.