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

From: John C Klensin <[email-masked]>
Date: Wed, 01 Oct 2003 12:03:54 -0400

Hi.

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.

    john

---

From: Keith Moore <[email-masked]>
Date: Wed, 1 Oct 2003 14:35:41 -0400

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

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Oct 2003 15:55:47 -0400

--On Wednesday, 01 October, 2003 14:35 -0400 Keith Moore 
<[email-masked]> 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

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.
>>
>> 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.
>>

---

From: Keith Moore <[email-masked]>
Date: Wed, 1 Oct 2003 16:28:50 -0400

> requires yet another set of command keywords.

I disagree.  A host, at least one on the public Internet
(where IP addresses are globally unique as IP was designed to work) has
reliable knowledge of its current IP addresses.  It does not have
reliable knowledge of which DNS names are currently bound to its IP
addresses, nor of the intended purposes of those DNS names  (are the
names intended to be associated with a particular host or with a
particular service that is supplied by many hosts?).  

So expecting, or even allowing, an FTP client or server to say 
"contact me at this DNS name" seems to me to be providing additional 
ways for the FTP session to fail, while adding little (if any) value.
e.g. 

- the party providing the DNS name may be doing so erroneously,

- the DNS servers providing name-to-address translation might not
  be in service and reachable,

- DNS lookup might not be available to one party or another
  (e.g. one party is on a ad hoc network and wants to use LLMNR,
  while the other party is on a connected network and expects
  DNS to work)

- if there is an intermediary involved, use of the DNS name may 
  confuse the intermediary or one or the endpoints.  for instance, 
  it is often possible to use FTP between hosts in different
  addressing realms via use of an intermediary, while DNS names
  would fail in those situations.

I'll also note that RFC 2428 already provides a way (EPSV) to  establish
FTP transfers in the usual case where the file is being transferred
between client and server and no third party is involved, which doesn't
need *any* kind of name - neither IP address nor DNS name - as the
endpoint addresses are implicit.  This should be used in the vast
majority of cases.

More fundamentally, of course, I have issues with the citing of
"applications should use names rather than addresses" as a principle to
which there is widespread agreement, and which should drive protocol 
designs, or even as something which has been demonstrated to be
workable.   We don't need to revisit that discussion again right now, or
in this context, but neither should it be taken as a given.  (Nor does
this really have anything to do with NAT - the two are only tangentially
related.)

If we're only looking at the narrow question of FTP, I submit that EPSV
is good enough for the vast majority  of cases, EPRT with either v4 or
v6 addresses is good enough for 3-party transfers (assuming that you can
manage the security issues), and any marginal value that would be
provided by adding DNS capability is fairly dubious at best and
potentially harmful.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 2 Oct 2003 09:55:05 +0859 ()

John;

> for IPv6 and NATs",

> Please consider this a fairly narrow question.

I'm afraid that your question is still too broad.

Are you asking the question for IPv6 or for NATs?

							Masataka Ohta

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Oct 2003 21:38:28 -0400

--On Thursday, 02 October, 2003 09:55 +0859 Masataka Ohta 
<[email-masked]> wrote:

>> Extensions  for IPv6 and NATs",
>

I am asking the question about FTP, about a piece of syntax in 
the protocol, and about the options that syntax permits.  If the 
addresses and address references that syntax nor permits are 
suitable for a particular situation, then one should use them. 
I am asking only about why we haven't structured that syntax so 
that use of a DNS name --or some other sort of name if/when it 
can be defined-- is possible if it turns out to be appropriate.

     john

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 2 Oct 2003 15:37:02 +0859 ()

John;

> the protocol, and about the options that syntax permits.

For what purpose?

> I am asking only about why we haven't structured that syntax

Seemingly because there was no reason to have one.

If you think you now have a reason, you should state it.

If you don't, we can debate forever on infinite variations of
reasons and associated extensions.

For example, how about extending FTP to be able to treat 
realtime stream? It is a question about FTP, about a piece
of syntax (MODE/STRU commands) in the protocol, and about
the options that syntax permits.

							Masataka Ohta

---

From: Michael Thomas <[email-masked]>
Date: Thu, 2 Oct 2003 11:04:25 -0700 (PDT)

> the options that syntax permits.

I'm with Masataka here... I'm completely confused
as to what the problem is here. And in particular,
why another rendezvous protocol like, oh say, SIP
wouldn't suffer from the same set of problems --
which obviously already does have that realtime
stream rendezvous capability :)

		  Mike

---

From: Mark Allman <[email-masked]>
Date: Thu, 02 Oct 2003 13:39:45 -0400

John-

> identifiers.

I think my hit to your narrow question is "no".  Sort of.

It seems to me that the mechanisms defined in rfc2428 are working
just fine.  Why go monkeying around with them?  It seems to me that
the practical benefits of doing so would be quite small.  You may
add a bit of flexibility in some cases, but you're also going to run
up against a raft of new problems.  What are the practical benefits
that we're going to get out of this exercise (i.e., how does this
make FTP somehow better and not just "prettier" under the hood?).

Now, if you had asked the question a little differently I might have
answered differently.  If the question is:

    Should we *add* a couple more verbs to FTP that are to be more
    generic than the current verbs and allow for DNS names and other
    "labels" we may come up with the in the future?  (With the
    intent that the new verbs and the old verbs could co-exist.)

Then I'd certainly be fine with that (assuming someone has the
energy).  If these new commands end up taking over in the future
then that's great and we can think about moving rfc2428 to historic
at that time.  But, I think the key here is that, IMO, we should
*add*, not *replace*.

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/