| Network Working Group | P. Hethmon |
| Internet-Draft | Hethmon Brothers |
| Updates: 959 (if approved) | R. McMurray |
| Intended status: Standards Track | Microsoft Corporation |
| Expires: May 16, 2013 | November 12, 2012 |
File Transfer Protocol HOST Command for Virtual Hosts
draft-hethmon-mcmurray-ftpext-ftp-hosts-01
The File Transfer Protocol, as defined in RFC 959, does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 16, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
It is common on the Internet for many DNS names to resolve to a single IP address. This practice has introduced the concept of a "virtual host", where a host appears to exist as an independent entity, but in reality shares its physical resources with one or more similar hosts.
Such an arrangement presents some problems for FTP servers, as an FTP server distinguishes incoming FTP connections by their IP addresses rather than their DNS names. Therefore, all DNS names that share a common IP address are handled by the same FTP server and share the same Network Virtual File System (NVFS).
This means that different virtual hosts cannot offer different virtual file systems to clients, nor can they offer different authentication systems. Any scheme to overcome this issue needs to indicate not only the destination IP address, but also the virtual host name that is associated with the desired virtual FTP server. Typical user-FTP processes currently use hostnames to perform hostname to IP address resolution and then ignore hostnames for the rest of the FTP session, therefore any mechanism to overcome this issue would require modifications to the user-PI and server-PI.
It should be noted that this same problem existed for HTTP/1.0 as defined in [RFC1945], and was resolved in HTTP/1.1 as defined in [RFC2616] through the addition of the Host request header field. The goal of this document is to bring a similar level of feature parity to FTP by introducing a new HOST command that allows user-FTP processes to specify which virtual host to connect to for a server-FTP process that is handling requests for multiple virtual hosts on a single IP address.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
In examples, "C>" and "S>" indicate lines sent by the client and server, respectively.
This document also uses notation defined in [RFC0959] and [RFC1123]. In particular, the terms "reply", "user", "NVFS", "NVT", "file", "pathname", "FTP commands", "DTP", "user-FTP process", "user-PI", "user-DTP", "server-FTP process", "server-PI", "server-DTP", "mode", "type", "control connection", "data connection", and "ASCII", are all used here as defined there.
Syntax required is defined using the Augmented BNF defined in [RFC5234]. Some general ABNF definitions are required throughout the document; those will be defined later in this section. At first reading, it may be wise to simply recall that these definitions exist here, and skip to the next section.
This document imports the core definitions given in Appendix B of [RFC5234]. There definitions will be found for basic ABNF elements like ALPHA, DIGIT, SP, etc. To that, the following term is added for use in this document.
TCHAR = VCHAR / SP / HTAB ; visible plus white space
The VCHAR (from [RFC5234]) and TCHAR rules give basic character types from varying sub-sets of the ASCII character set for use in various commands and responses.
Note that in ABNF, string literals are case insensitive. That convention is preserved in this document, and implies that FTP commands and parameters that are added by this specification have values that can be represented in any case. That is, "HOST" is the same as "host", "Host", "HoSt", etc., and "ftp.example.com" is the same as "Ftp.Example.Com", "fTp.eXample.cOm", etc.
Section 4.2 of [RFC0959] defines the format and meaning of replies by the server-PI to FTP commands from the user-PI. Those reply conventions are used here without change.
error-response = error-code SP *TCHAR CRLF
error-code = ("4" / "5") 2DIGIT
Implementers should note that the ABNF syntax (which was not used in [RFC0959]) used in this document, and other FTP related documents, sometimes shows replies using the one line format. Unless otherwise explicitly stated, that is not intended to imply that multi-line responses are not permitted. Implementers should assume that, unless stated to the contrary, any reply to any FTP command (including QUIT) can be of the multi-line format described in [RFC0959].
Throughout this document, replies will be identified by the three-digit code that is their first element. Thus the term "500 reply" means a reply from the server-PI using the three digit code "500".
A new command "HOST" is added to the FTP command set in order to allow a server-FTP process to determine which of possibly many virtual hosts to which the client wishes to connect. This command MUST be issued before the user is authenticated, as this will allow the authentication scheme and set of legal users to be dependent upon the virtual host that is chosen.
Server-FTP processes that conform to this specification MUST treat a situation where the HOST command is issued more than once before the user has been authenticated as though a previous HOST command was not sent, and return the appropriate reply for the new HOST command. Server-FTP processes MUST treat a situation where the HOST command is issued after the user has been authenticated as an erroneous sequence of commands and return a 503 reply.
Servers should note that the response to the HOST command is a sensible time to send their "welcome" message. This allows the message to be personalized for any virtual hosts that are supported, and also allows the client to determine the supported languages, or representations, for the message, and other messages, via the FEAT response, and select an appropriate one via the LANG command. See [RFC2640] for more information.
It should be noted that user-PI implementations that were created before the introduction of the HOST command will not support this new command. A similar problem existed with the introduction of the Host header for HTTP in [RFC2616], and HTTP server implementations had to determine how best accomodate HTTP requests from down-level clients that did not support the Host header. With this in mind, Server-FTP processes will need to determine how best to accomodate FTP requests from down-level FTP clients that do not support the HOST command, but those considerations are outside the scope of this document.
The HOST command is defined as follows.
host-command = "HOST" SP hostname CRLF
hostname = domain / IP-literal
domain = sub-domain *("." sub-domain)
sub-domain = let-dig [ldh-str]
let-dig = ALPHA / DIGIT
ldh-str = *( ALPHA / DIGIT / "-" ) let-dig
IP-literal = ( "[" IPv6address "]" ) / IPv4address
IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
ls32 = ( h16 ":" h16 ) / IPv4address
; least-significant 32 bits of address
h16 = 1*4HEXDIG
; 16 bits of address represented in hexadecimal
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
host-response = host-ok / error-response
host-ok = "220" [ SP *TCHAR ] CRLF
The "hostname" rule is a restricted form of the "host" rule specified in [RFC3986]. Details of the additional restrictions imposed by this document are given further down in this section in the discussion of the syntax; they aim at simplifying implementations by only allowing what currently is specified precisely and in use on the Internet. The "IPv4address" and "IPv6address" ABNF rules and all subordinate ABNF rules given above are taken literally from [RFC3986] and reproduced here for the convenience of readers; however, [RFC3986] remains the normative specification for the syntactic form of IPv4 and IPv6 address literals, in order to ensure identical presentation in 'ftp' URI hostname parts and in the protocol element specified here.
As with all FTP commands, the "HOST" command word is case independent, and MAY be specified in any character case desired.
The "hostname" (given as a parameter) specifies the virtual host to which access is desired. This SHOULD be the same host name that was used to obtain the IP address to which the FTP control connection was made, after any client conversions have been completed that convert an abbreviated or local alias to a complete (fully qualified) domain name, but before resolving a DNS alias (owner of a CNAME resource record) to its canonical name.
Internationalization of domain names is only supported through the use of IDNA "A-Labels" for <sub-domain> as described in [RFC5890]. For example, the following HOST command specifies an internationalized domain name:
HOST xn--e1afmkfd.com
If the user was given an IPv4 or IPv6 literal address, and consequently was not required to derive the literal address from a hostname, the client MAY send the HOST command with the IPv4 or IPv6 literal address as specified to it. While it may seem counter-intuitive to specify a literal address by using the HOST command after the client has already connected to the server using a literal address, this should be expected behavior because a user-FTP process should not be required to differentiate between a fully qualified domain name and an IPv4 or IPv6 network literal address. That being said, if the IPv4 or IPv6 literal address specified by the client does not match the literal address for the server, the server MUST respond with a 504 reply to indicate that the IPv4 or IPv6 literal address is not valid.
When the hostname parameter contains a literal address, square brackets are expected to disambiguate IPv6 address syntax from port numbers syntax. Therefore, if the literal address is an IPv6 address, the IPv6 address is required to be enclosed in square brackets (after eliminating any syntax that might also - but is not required to - be enclosed in brackets, and from which the server deduced that a literal address had been specified.) For example, the following examples MAY be sent if the client had been instructed to respectively connect to "192.0.2.1", "FE80::c000:0201", or "192.0.2.1" and IPv6 syntax is preferred:
HOST 192.0.2.1
HOST [FE80::c000:0201]
HOST [::192.0.2.1]
The client MUST NOT send the port number as part of the HOST command, even when the client has been instructed to connect to a non-standard port. The reason for this requirement is that the user-PI will have established a connection to the server-PI before the HOST command is sent, therefore specifying a different port with the HOST command has no meaning. For example, the server-PI MUST respond with a 501 reply if the client sends a HOST command with syntax like either of the following examples:
HOST 192.0.2.1:2112
HOST [FE80::c000:0201]:2112
The hostname parameter is otherwise to be treated as a fully qualified domain name or relative name as those terms are defined in section 3.1 of [RFC1034]. This implies that the name is to be treated as a case-independent string, meaning that uppercase ASCII characters are to be treated as equivalent to their corresponding lowercase ASCII characters, but otherwise preserved as given. It also implies some limits on the length of the parameter and of the components that create its internal structure. Those limits are not altered in any way here.
Neither [RFC1034] nor [RFC1035] impose any other restrictions upon what kinds of names can be stored in the DNS. This specification, however, only allows the use of names that can be inferred from the ABNF grammar given for the "hostname". Similarly, this specification restricts address literals to the IPv4 and IPv6 address families well established in the Internet.
Upon receiving the HOST command, before authenticating the user-PI, a server-FTP process SHOULD validate that the hostname given represents a valid virtual host for that server, and, if it is valid, establish the appropriate environment for that virtual host. The resultant actions needed to create that environment are not specified here, and may range from doing nothing at all, to performing a simple change of working directory, changing authentication schemes and/or username and password lists, or making much more elaborate state changes - such as creating isolated environments for each FTP session.
The "220" reply code for the HOST command is the same as the code that is used in the initial "welcome" message that is sent after the connection is established.
If the hostname specified would normally be acceptable, but for any reason is temporarily unavailable, the server-FTP process SHOULD reply to the HOST command with a 421 reply and close the connection. In this particular situation, the server-FTP process MAY choose to keep the connection open in order to allow the user-PI an opportunity to choose another virtual host with a subsequent HOST command.
If the hostname specified is unknown at the server, or if the server is otherwise unwilling to treat the particular connection as a connection to the hostname specified, the server SHOULD respond with a 504 reply.
As specified in [RFC0959], the REIN command returns the state of the connection to what it was immediately after the transport connection was opened. This specification makes no changes to that behavior. The effect of a HOST command MUST be reset if a REIN command is performed, and a new HOST command MUST be issued afterwards in order to connect to a virtual host.
A user-PI that conforms to this specification MUST send the HOST command after opening the transport connection, or after any REIN command, before attempting to authenticate the user with the USER command. The following example illustrates what a typical login sequence might look like when the HOST command is used:
C> HOST ftp.example.com
S> 220 Host accepted
C> USER foo
S> 331 Password required
C> PASS bar
S> 230 User logged in
If a user-PI sends an additional HOST command before attempting to authenticate the user, a server-FTP process that conforms to this specification MUST treat the additional HOST command as though a previous HOST command was not sent, and return the appropriate reply for the new HOST command. For example, if a user specifies the wrong virtual host by mistake, sending a subsequent HOST command will rectify the error. The following example illustrates what the login sequence might look like when the HOST command is sent twice before a user has been authenticated:
C> HOST foo.example.com
S> 220 Host accepted
C> HOST bar.example.com
S> 220 Host accepted
C> USER foo
S> 331 Password required
C> PASS bar
S> 230 User logged in
The HOST command can be used in combination with the ACCT command to differentiate between a user's various accounts on a specific virtual host. In this scenario, the user-PI sends a HOST command which the server-PI uses to route activity to the correct virtual host; the user-PI sends credentials using the USER and PASS commands which the server-PI validates; then, the user-PI sends an ACCT command to specify any additional account information for the server-PI implementation. The following example illustrates a sequential series of client commands that specify both a HOST and ACCT, with the server responses omitted for brevity:
C> HOST ftp.example.com
C> USER foo
C> PASS bar
C> ACCT project1
This is also true when the HOST command is used with the AUTH and ADAT commands that are discussed in [RFC2228] and [RFC4217]. In this scenario, the user-PI sends a HOST command which the server-PI uses to route activity to the correct virtual host, then the user-PI uses the AUTH and ADAT commands to negotiate the security mechanism and relevant authentication token(s) with the server-PI, then the user-PI sends user credentials using the USER and PASS commands which the server-PI validates. After which the user-PI MAY send an ACCT command to specify any additional account information for the server-PI implementation. The following example illustrates a sequential series of client commands that specify both a HOST and ACCT when used in conjunction with the security commands that are discussed in [RFC2228] and [RFC4217], with the server responses omitted for brevity:
C> HOST ftp.example.com
C> AUTH <mechanism-name>
C> ADAT <base64data>
C> USER foo
C> PASS bar
C> ACCT project1
The state diagrams in this section illustrate typical sequences for command and reply interchange between the user-PI and server-PI. These diagrams are modeled on the similar diagrams in section 6 of [RFC0959].
In each diagram, the (B) "begin" state is assumed to occur after the transport connection has opened, or after a REIN command has succeeded. Other commands (such as FEAT [RFC2389]) that require no authentication may have intervened.
Additionally, a three-digit reply indicates a precise server reply code. A single digit on a reply path indicates any server reply that begins with that digit, except where a precise server reply code is defined on another path. For example, a single digit "5" will apply to "500", "501", "502", etc., when those reply codes are not expressly defined in the diagram. For each command there are three possible outcomes: success (S), failure (F), and error (E). In the state diagrams below we use the symbol B for "begin", and the symbol W for "wait for reply".
For each of these diagrams, without any state transitions being shown, a REIN command will return the diagram from any wait state to the (B) "begin" state.
The state diagram in Figure 1 shows a typical sequence of flow of control when HOST is used with USER and PASS to log in to a particular FTP virtual host.
+---+ HOST +---+ 1,3,5
| B |---------->| W |-----------------
+---+ +---+ |
| | |
2,500,502 | | 4,501,503,504 |
-------------- ----------- |
| | V
V 1 | +---+
+---+ USER +---+-------------->| E |
| |---------->| W | 2 | +---+
+---+ +---+------- | ^
| | | | |
3 | | 4,5 | | |
-------------- ----- | | |
| | | | |
| -------------------
| 1| | | |
V | | ------>+---+
+---+ PASS +---+ 2 | | | S |
| |---------->| W |-------------->+---+
+---+ +---+ | |
| | |
|4,5 | |
| | --->+---+
| --------->| F |
---------------->+---+
After a user has logged in, an additional account may be required by the server and specified by the client by using ACCT command. With this in mind, the state diagram in Figure 2 shows a typical sequence of flow of control when HOST is used with USER and PASS to log in to an FTP virtual host and ACCT is used to specify an account.
+---+ HOST +---+ 1,3,5
| B |---------->| W |-----------------
+---+ +---+ |
| | |
2,500,502 | | 4,501,503,504 |
-------------- ------------- |
| | |
V 1 | V
+---+ USER +---+-------------->+---+
| |---------->| W | 2 ----->| E |
+---+ +---+------ | --->+---+
| | | | | |
3 | | 4,5 | | | |
-------------- ----- | | | |
| | | | | |
| | | | | |
| ---------- | |
| 1| | | | |
V | | | | |
+---+ PASS +---+ 2 | ------->+---+
| |---------->| W |-------------->| S |
+---+ +---+ ----------->+---+
| | | | | |
3 | |4,5| | | |
-------------- -------- | ----
| | | | | |
| | | | | |
| ------------ |
| 1,3| | | | |
V | 2| | | V
+---+ ACCT +---+-- | ------>+---+
| |---------->| W | 4,5 --------->| F |
+---+ +---+-------------->+---+
The state diagram in Figure 3 shows a typical sequence of flow of control when HOST is used with the AUTH and ADAT commands that are discussed in [RFC2228]. (NOTE: Section 4 provides additional information about using the HOST command with TLS.)
+---+ HOST +---+ 1,3,5
| B |---------->| W |------------------
+---+ +---+ |
| | |
2,500,502 | | 4,501,503,504 |
-------------- ------------- |
| | |
V | |
+---+ AUTH +---+ 4,5 | |
| |---------->| W |----------->| |
+---+ +---+ | |
334 | | | |
-------------- | | |
| 234 | | |
| ------------ | |
V | 4,5 | |
+---+ | ADAT +---+----------->| |
| |---------->| W | 335 | |
+---+ | +---+----- | |
^ | | | | |
| | | | | |
----------------------- | |
| | | |
---- 235 | | |
| -------------- | |
| | | V
V V 1 | +---+
+---+ USER +---+--------------->| E |
| |---------->| W | 2 | +---+
+---+ +---+------- | ^
| | | | |
3 | | 4,5 | | |
-------------- ------ | | |
| | | | |
| --------------------
| 1| | | |
V | | ------->+---+
+---+ PASS +---+ 2 | | | S |
| |---------->| W |--------------->+---+
+---+ +---+ | |
| | |
|4,5 | |
| | -->+---+
| --------->| F |
----------------->+---+
After a user has logged in with the security commands that are discussed in [RFC2228], an additional account may be required by the server and specified by the client by using ACCT command. The state diagram in Figure 4 shows a typical sequence of flow of control when HOST is used with the AUTH and ADAT commands to log in to an FTP virtual host and ACCT is used to specify an account.
+---+ HOST +---+ 1,3,5
| B |---------->| W |------------------
+---+ +---+ |
| | |
2,500,502 | | 4,501,503,504 |
+-------------- -------------- |
| | |
V | |
+---+ AUTH +---+ 4,5 | |
| |---------->| W |------------>| |
+---+ +---+ | |
334 | | | |
-------------- | | |
| 234 | | |
| ------------ | |
V | 4,5 | |
+---+ | ADAT +---+------------>| |
| |---------->| W | 335 | |
+---+ | +---+----- | |
^ | | | | |
| | | | | |
----------------------- | |
| | | |
---- 235| | |
| -------------- | |
| | | |
V V 1 | V
+---+ USER +---+--------------->+---+
| |---------->| W | 2 ----->| E |
+---+ +---+------- | --->+---+
| | | | | |
3 | | 4,5 | | | |
-------------- ------ | | | |
| | | | | |
| ----------- | |
| 1| | | | |
V | | | | |
+---+ PASS +---+ 2 | ------->+---+
| |---------->| W |--------------->| S |
+---+ +---+ ------------>+---+
| | | | | |
3 | |4,5| | | |
-------------- --------- | ----
| | | | | |
| ------------- |
| 1,3| | | | |
V | 2| | | V
+---+ ACCT +---+-- | ------>+---+
| |---------->| W | 4,5 --------->| F |
+---+ +---+--------------->+---+
The server-PI SHOULD return a 500 or 502 reply if the HOST command is unrecognized or unimplemented, as specified in [RFC0959]. For example, a server-PI that predates or otherwise chooses not conform to this specification would be expected to return a 500 or 502 reply.
As discussed in section 3 of this document, if a HOST command is sent after a user has been authenticated, the server MUST treat the situation as an invalid sequence of commands and return a 503 reply.
A 501 reply SHOULD be sent if the hostname given is syntactically invalid, and a 504 reply SHOULD be sent if a syntactically valid hostname is not a valid virtual host name for the server. In all such cases, the server-FTP process MUST do one of the following:
A user-PI receiving a 500 or 502 reply to a HOST command SHOULD assume that the server-PI does not implement virtual servers by using the HOST command. The user-PI MAY then proceed to login as if the HOST command had not been sent.
A user-PI receiving an error reply that is different from the errors that have been described here SHOULD assume that the virtual HOST is unavailable, and terminate communications.
A server-PI that receives a USER command to begin the authentication sequence without having received a HOST command SHOULD NOT reject the USER command. Clients conforming to earlier FTP specifications do not send HOST commands. In this case the server MAY act as if some default virtual host had been explicitly selected, or MAY enter an environment that is different from that of any supported virtual hosts, perhaps one in which a union of all available accounts exists and which presents an NVFS that appears to contain subdirectories that contain the NVFS for all supported virtual hosts.
When replying to the FEAT command [RFC2389], a server-FTP process that supports the HOST command MUST include a line containing the single word "HOST". This word is case insensitive, and MAY be sent in any mixture of upper or lower case, however it SHOULD be sent in upper case. That is, the response SHOULD be:
C> FEAT
S> 211- <any descriptive text>
S> ...
S> HOST
S> ...
S> 211 End
The ellipses indicate place holders where other features may be included, and are not required. The one-space indentation of the feature lines is mandatory [RFC2389].
As discussed in section 3 of this document, a server implementation MUST treat an additional HOST command that was sent before a user has been authenticated as though a previous HOST command was not sent. In this situation, the server implementation MUST reset the authentication environment, as that would allow for segregation between the security environments for each virtual host on an FTP server. The implementation details for security environments may vary greatly based on the requirements of each server implementation and operating system, and those details are outside the scope of the protocol itself. For example, a virtual host "foo.example.com" on an FTP server might use a specific username and password list, while the virtual host "bar.example.com" on the same FTP server might use a different username and password list. In such a scenario, resetting the security environment is necessary for the virtual servers to appear to behave independently from a client perspective, while the actual server implementation details are irrelevant at the protocol level.
Section 15.1.1 of [RFC4217] discusses the use of X.509 certificates for server authentication. Taking the information from that document into account, when securing FTP sessions with the security mechanisms that are defined in [RFC4217], client implementations SHOULD verify that the hostname which they specify in the parameter for the HOST command matches the identity that is specified in the server's X.509 certificate in order to prevent man-in-the-middle attacks.
When the HOST command is used in combination with the FTP security extensions that were introduced in [RFC2228] and [RFC4217], the HOST command SHOULD precede the security handshake when the user-PI is not providing the "server_name" in the extended client hello as defined in [RFC6066]. This allows both user-PI and server-FTP processes to map an FTP HOST with the correct server name in the server's certificate. If the HOST command is sent after the security handshake, then mapping an FTP HOST to a security certificate will not take place before the secure session is established and the user-PI will be unable to verify the server's identity as presented in the server certificate message.
If the user-PI is providing the "server_name" in the extended client hello as defined in Section 3 of [RFC6066], the user-PI MAY provide the HOST command after the security handshake because the client will be able to verify the server's identity as presented in the server Certificate message. However, the server-PI MUST verify that the name in the HOST command matches the "server_name" that is provided in the extended client hello.
A general discussion of issues related to the security of FTP can be found in [RFC2577].
IANA is requested to register the following FTP extension according to the procedure established by [RFC5797]:
| cmd | FEAT Code | description | type | conf | RFC#s/References and Notes |
|---|---|---|---|---|---|
| HOST | HOST | Hostname | a | o | TBD |
NOTE TO RFC EDITOR: Please update TBD in the above table with the number of this document.
| [RFC1945] | Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |
| [RFC2577] | Allman, M. and S. Ostermann, "FTP Security Considerations", RFC 2577, May 1999. |
| [RFC2616] | Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| [RFC5797] | Klensin, J. and A. Hoenes, "FTP Command and Extension Registry", RFC 5797, March 2010. |
Due to the level of scope for adding a new command to FTP, a brief discussion of suggested alternatives to a HOST command and their respective limitations is warranted. The suggested alternatives that are discussed in this appendix have been proposed in the past, but each of these ideas was deemed insufficient for the reasons that are listed within each section of the appendix.
One suggested method to emulate a form of virtual hosts would be for the client to simply send a "CWD" command after connecting, using the virtual host name as the argument to the CWD command. This would allow the server-FTP process to implement the file stores of the virtual hosts as sub-directories in its NVFS. This suggestion is simple in concept, and most server-FTP implementations support this without requiring any code changes. While this method is simple to describe, and to implement, it suffers from several drawbacks:
Another suggested method would be to simply overload the "ACCT" for FTP virtual hosts, but this proposal is unacceptable for several reasons with regard to when the ACCT command is sent during the request flow. Sections 5.4 and 6 of [RFC0959] document the request flow for a login sequence as USER -> PASS -> ACCT. This flow of commands may be acceptable when you are considering a single user having multiple accounts on an FTP server, but fails to differentiate between virtual hosts when you consider the following two issues:
An additional suggestion would be to overload well-known syntax through the existing USER command, as illustrated in the following example:
C> USER foo@example.com
S> 331 Password required
C> PASS bar
S> 230 User logged in
In this example, the user "foo" might be attempting to log on to the virtual host "example.com" on an FTP server. This suggestion may seem plausible at first, but introduces several implementation problems. For example:
The conclusion from the examination of the existing possibilities seems to be that in order to obtain an adequate emulation of "real" FTP servers, client and server modifications to support virtual hosts are necessary. Therefore a new FTP command seems the most likely solution to provide the required level of support.
Robert Elz and Paul Hethmon provided a detailed discussion of the HOST command in their Internet draft titled "Extensions to FTP" as part of their work with the FTPEXT Working Group at the IETF. Their work formed the basis for much of this document, and their help has been greatly appreciated. They would also like to credit Bernhard Rosenkraenzer for having first suggested and described the HOST command.
Several people have provided a wealth of constructive feedback about earlier versions of this document that have helped to shape its development; many of their suggestions have been incorporated, and their contributions are gratefully acknowledged. There are far too many to mention here, but authors of this document would like to specifically thank Alexey Melnikov, Alfred Hoenes, John Klensin, Joe Touch, Paul Ford-Hutchinson, Daniel Stenberg, Mykyta Yevstifeyev, and Anthony Bryan for their assistance. In addition, Alec Rowell's help in making sections of this document more readable was invaluable.