Re: Persistent applications-level identifiers, the DNS, and RFC 2428
Aha. Then we are having a difference of opinion about architecture and aesthetics, not function. Putting in a new verb for the same function each time one wants to provide what is logically the same information in a different form impresses me as a bad idea. You prefer it. No, I don't. I share your desire to do something that is quite generic and extendable and not end up with a ton of these commands. My point was that EPRT/EPSV are working fine and rather than try to kludge something on top of those why not just aim for a GPRT/GPSV which would be very generic and general commands that could take any sorts of identifiers of hosts that one might ever want to throw at it. That could be based on 2428, for sure. That strikes me as a clean approach. (Oh ... and to resurrect another notion from the days of haggling over the i-ds before 2428 ... I'd also think the transport protocol stuff should be negotiated, as well.) allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/
Re: Persistent applications-level identifiers, the DNS, and RFC 2428
John- 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. 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/
RE: Persistent applications-level identifiers, the DNS, and RFC 2428
Mark / John, Mark Allman wrote: 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*. This makes sense to me. For the same reason we are stuck supporting PORT and PASV forever, I think that we are stuck supporting EPRT and EPSV forever as well and that two new verbs that would include the functionality of EPRT and EPSV with extended semantics that would allow passing names and foo is the way to go. John C Klensin wrote: given that 2428 is at Proposed I believe there is deployed EPRT/EPSV code based on 2428; IMHO you can't assume that this code base will be upgraded to support names. It's too late. Michel.
Re: Persistent applications-level identifiers, the DNS, and RFC 2428
John; I just had occasion to look again at RFC 2428, FTP Extensions 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? I am asking the question about FTP, about a piece of syntax in 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
RE: Persistent applications-level identifiers, the DNS, and RFC 2428
John, John C Klensin wrote: My ambitious in raising these questions are _very_ limited and, in particular, I don't see this as a back door to solving the non-DNS, topology-independent, persistent identifier problem. (It seems to me that needs to be solved through the front door, or not at all.). I'm with you here. So, we know we need something more universal, but in the meantime we band-aid FTP to keep going. Because of its special status and the fact that it is widespread, FTP might justify doing the work for only one protocol. It is clear that to be worthy of the effort, this should be deployed way before a persistent identifier solution is rolled out though. As long as I'm not the one doing the work I don't have a problem with it :-D However, I do have a concern: when later a generic identifier mechanism is deployed, we will have two standards. Have you had any thoughts on the possible collisions there? Michel.
RE: Persistent applications-level identifiers, the DNS, and RFC 2428
--On Thursday, 02 October, 2003 10:31 -0700 Michel Py [EMAIL PROTECTED] wrote: John, John C Klensin wrote: My ambitious in raising these questions are _very_ limited and, in particular, I don't see this as a back door to solving the non-DNS, topology-independent, persistent identifier problem. (It seems to me that needs to be solved through the front door, or not at all.). I'm with you here. So, we know we need something more universal, but in the meantime we band-aid FTP to keep going. Because of its special status and the fact that it is widespread, FTP might justify doing the work for only one protocol. It is clear that to be worthy of the effort, this should be deployed way before a persistent identifier solution is rolled out though. As long as I'm not the one doing the work I don't have a problem with it :-D However, I do have a concern: when later a generic identifier mechanism is deployed, we will have two standards. Have you had any thoughts on the possible collisions there? My goal is precisely to avoid ending up with either two standards or eight verbs. Explanation of the latter: IPv4 IPv6 self-referent DNSStableID address address RFC959 2428 ?????? Verb PORT,PASVEPRT,EPSV ?DPRT,DPSV? ?IPRT,IPSV? That seems to me excessive, if we can avoid it. So the suggestion is whether, given that 2428 is at Proposed, maybe it would be worth revising it, and the syntax for EPRT and EPSV, to _permit_ use of a DNS name now and to provide a clear extension path for a generic/stable identifier. Too many DNS implementations are still having to support the X forms of the directory changing and modifying commands, and it has been a very long time. All of them will need to support, esentially forever, PORT and PASV. Ending up with eight verbs seems to me to be poor architecture, worse interface design, and a magnet for poor implementations. --On Thursday, 02 October, 2003 13:39 -0400 Mark Allman [EMAIL PROTECTED] wrote: ... 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? I do not want to monkey around with those _mechanisms_. I am objecting only to the syntax, which is extensible only by adding more verbs (see below). 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?). In the, admittedly rare, situations in which the transfer is really third-party, and not even bound tightly to one of the other two, passing the domain name of the third host (one that is not at either end of the command connection) would seem more consistent with general architectural principles. That seems to me to be especially true because, for those cases, the command connection host(s) are likely to get the pointer to that host in DNS name or URI form, not as an address. In a world of NATs and split-horizon DNS setups (not that I like either), it seems far preferable to have the DNS name resolved from the host that is going to use the results to open a connection. Again, this is a rare case but one that has occasionally been important with the IPv4 (and NCP) implementations of FTP. 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*. Aha. Then we are having a difference of opinion about architecture and aesthetics, not function. Putting in a new verb for the same function each time one wants to provide what is logically the same information in a different form impresses me as a bad idea. You prefer it. I don't know how to resolve that difference of aesthetic convictions other than with some beauty is in the mind of the beholder platitude... and that doesn't produce a resolution. john
RE: Persistent applications-level identifiers, the DNS, and RFC 2428
John, John C Klensin wrote: My goal is precisely to avoid ending up with either two standards or eight verbs. Explanation of the latter: IPv4 IPv6 self-referent DNS StableID addressaddress RFC959 2428 ?????? Verb PORT,PASVEPRT,EPSV ?DPRT,DPSV? ?IPRT,IPSV? That seems to me excessive, if we can avoid it. So the suggestion is whether, given that 2428 is at Proposed, maybe it would be worth revising it, and the syntax for EPRT and EPSV, to _permit_ use of a DNS name now and to provide a clear extension path for a generic/stable identifier. There is an issue with backwards compatibility here: Let's say we have a source host that has an implementation that allows EPRT and EPSV to use a name as well as an address. The destination host is a legacy host (meaning, a host implementing only 2428 as it is today, address only). How will the destination react when receiving an EPSV with a name instead of an address? More generically, how will a host react when receiving an EPSV with foo when foo is unknown? I am curious about the mechanism you envision to determine what kind of info is being passed. Michel.
Re: Persistent applications-level identifiers, the DNS, and RFC 2428
My goal is precisely to avoid ending up with either two standards or eight verbs. Explanation of the latter: IPv4 IPv6 self-referent DNSStableID address address RFC959 2428 ?????? Verb PORT,PASVEPRT,EPSV ?DPRT,DPSV? ?IPRT,IPSV? That seems to me excessive, if we can avoid it. If a case could actually be made for using DNS names in FTP (and IMHO the case against is far heavier than the case in favor) it would be a simple matter to define new address types for EPSV and EPRT. I don't see why new commands would be necessary. In the, admittedly rare, situations in which the transfer is really third-party, and not even bound tightly to one of the other two, passing the domain name of the third host (one that is not at either end of the command connection) would seem more consistent with general architectural principles. Which principles are those? That it's better to use an ambiguous reference to a host than a unambiguous one? That it's better to add extra complexity and failure modes to a system than to use a simple and reliable mechanism? That it's better to encourage fragmenting the DNS to reflect disjoint addressing realms than it is to encourage a sane address space? That seems to me to be especially true because, for those cases, the command connection host(s) are likely to get the pointer to that host in DNS name or URI form, not as an address. In a world of NATs and split-horizon DNS setups (not that I like either), it seems far preferable to have the DNS name resolved from the host that is going to use the results to open a connection. It might seem that way, but experience indicates that DNS names are _less_ reliable than IP addresses in referrals. Because even with all of the harm done by RFC 1918 addersses, DNS is far more screwed up in practice than IP. Partly this is because DNS depends on even things to be accessible, configured, and working properly in order to function than IP does; and part of this is because there are more games played with DNS than with IP. And while use of RFC 1918 addresses at least provides a clue that the address is not usable outside of the local realm, there's no way to know whether a DNS name is globally usable or not. And given the potential for a DNS name to produce different RRs at different locations of the net (yes there are people doing this), it's not clear at all that having the DNS name resolved from the host that is going to use the address is the right meaning. I would argue that the lookup that is the closest to where the DNS name is _specified_ is more likely to be the right one. (Though I'd argue even more strongly that producing different RRs at different locations is simply broken.) At any rate, until someone defines a good way to make 3rd party FTP transfers secure, any arguments about why DNS names are needed for 3rd party transfers seem moot. Keith
Persistent applications-level identifiers, the DNS, and RFC 2428
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
Re: Persistent applications-level identifiers, the DNS, and RFC 2428
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 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.
Re: Persistent applications-level identifiers, the DNS, and RFC 2428
--On Wednesday, 01 October, 2003 14:35 -0400 Keith Moore [EMAIL PROTECTED] 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.
Re: Persistent applications-level identifiers, the DNS, and RFC 2428
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 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.
RE: Persistent applications-level identifiers, the DNS, and RFC 2428
John, John C Klensin wrote: 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. It seems to me that this does not buy us much if it is limited to FTP. Do you have in mind generalizing the mechanism of passing names instead of addresses to other apps, and at which layer would the address-to-name mapping occur? If I understood you correctly: The way it works today is: - You pass a name to the app. - The app looks up the name and maps an address to it. - The app opens a TCP connection to the address. Is what you are proposing: - You pass a name to the app. - The app opens a TCP connection to the name. - The TCP layer manages the mapping. -or- - You pass a name to the app. - The app opens a connects the session layer by name. - The session layer maps an address to the name and opens a TCP connection to the address. -or- Something else? Michel.
RE: Persistent applications-level identifiers, the DNS, and RFC 2428
--On Wednesday, 01 October, 2003 14:48 -0700 Michel Py [EMAIL PROTECTED] wrote: John, John C Klensin wrote: 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. It seems to me that this does not buy us much if it is limited to FTP. Do you have in mind generalizing the mechanism of passing names instead of addresses to other apps, and at which layer would the address-to-name mapping occur? My ambitious in raising these questions are _very_ limited and, in particular, I don't see this as a back door to solving the non-DNS, topology-independent, persistent identifier problem. (It seems to me that needs to be solved through the front door, or not at all.). Remember that FTP is a bit special -- it is the only major (widely deployed and used) application protocol we have that uses two TCP connections, one for a dialogue about what is to be done and one to actually move data. That means it must have mechanisms for one or the other machine to tell the other one set up a data channel to port X on machine Y We've also had a few IESG statements from time to time that have provide guidance/instructions to applications writers to get the explicit addresses out of the apps whenever possible. As Keith notes, there is controversy as to whether that goal is realistic, at least given present our tools and identifier collection. But, given those IESG statements, the character of set up a data channel to port X on machine Y, and some of the edge cases for which it has been used, it would seem at least superficially sensible to be able to specify Y as a DNS name or other identifier or, as was pointed out to me in a private note, to be able to specify the X and Y combination with a URI of some sort. I've got no particular interest in prohibiting the use of an IP address in Y (others can fight that war, I hope somewhere far away, if they want to), only some interest in exploring whether it is rational to have capability for a name as an additional option. I do, architecturally and aesthetically, have an interest in not having to introduce a new pair of FTP command verbs each time someone figures out a different way to talk about (or identify) a host. And that interest is why I got concerned when I noticed that 2428 had no provision for a name, or expansion of the syntax to accept a name, DNS or otherwise. If I understood you correctly: The way it works today is: - You pass a name to the app. - The app looks up the name and maps an address to it. - The app opens a TCP connection to the address. yes. Is what you are proposing: - You pass a name to the app. - The app opens a TCP connection to the name. - The TCP layer manages the mapping. -or- - You pass a name to the app. - The app opens a connects the session layer by name. - The session layer maps an address to the name and opens a TCP connection to the address. Both of those alternatives go down the Stable, non-DNS, identifier that Keith and others are concerned about. For the purpose of this discussion/ question, I'm not -- I am purely worried about how to handle this unusual situation with FTP. Coming back to your first scenario, we have - You pass a name to the app. - The app looks up the name and maps an address to it. - The app opens a TCP connection to the address, establishing the command channel - Either the app or the host at the remote end of the connection obtains a name or address, somehow. In the most common case, it will be its own target, so it makes sense for it to obtain its own address (or the address of the adapter from which the TCP connection was opened), but there are some other cases. - It passes that address or name to the remote host, along with a port number. - If it passes a name, the remote host looks up the name, maps an address to it, and opens a TCP connection to it, establishing the data channel. john
Re: Persistent applications-level identifiers, the DNS, and RFC 2428
John; I just had occasion to look again at RFC 2428, FTP Extensions 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
Re: Persistent applications-level identifiers, the DNS, and RFC 2428
--On Thursday, 02 October, 2003 09:55 +0859 Masataka Ohta [EMAIL PROTECTED] wrote: John; I just had occasion to look again at RFC 2428, FTP Extensions 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? 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
