Subject: Virtual IP

From: zhao shuo <[email-masked]>
Date: Sun, 17 Jan 1999 09:37:12 +0800

Hi:
   I have configured what I think is the correct config for wu-ftp with
Virtual services.

   Where to get HOST command draft or RFC?

---

From: Gregory A Lundberg <[email-masked]>
Date: Sun, 17 Jan 1999 23:47:42 -0500 (EST)

On Sun, 17 Jan 1999, zhao shuo wrote:

>    I have configured what I think is the correct config for wu-ftp
> with Virtual services.
> 

Before I answer your specific question, I want to point out that it is
highly unlikely HOST is what you're looking for unless you intend to work
on the development of an FTP server or client program.

To my knowledge, the HOST command is only implemented in BeroFTPD and, I
believe, NcFTP daemon and client; there may be one or two other clients or
servers which support it, but I've not heard them mentioned on the IETF
FTP Working Group mailing list.

It is currently in draft stage, and I would not expect anyone other than
those developing ot testing with Telnet or the NcFTP client against the
NcFTP or BeroFTPD servers to be able to use it.

Internet-Drafts directories are located at:

        Africa: ftp.is.co.za
        
        Europe: ftp.nordu.net
                ftp.nis.garr.it
                        
        Pacific Rim: munnari.oz.au
        
        US East Coast: ds.internic.net
        
        US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

        Title           : Extensions to FTP
        Author(s)       : R. Elz, P. Hethmon
        Filename        : draft-ietf-ftpext-mlst-05.txt
        Pages           : 46
        Date            : 16-Dec-98

TO BE PERFECTLY CLEAR HERE:

   THIS IS A DISCUSSION OF A *POSSIBLE* FUTURE FTP COMMAND.  IT MAKES
   REFERENCE TO OTHER *POSSIBLE* FUTURE FEATURES OF THE FTP PROTOCOL.

   IT IS *NOT* A CURRENT COMMAND IN ANY VERSION THE WU-FTPD DAEMON; IT IS
   IMPLEMENTED IN BeroFTPD *SOLELY* TO TEST THE VIABILITY OF THE COMMAND.

   IT IS *NOT* SUPPORTED BY ANY WIDELY-DEPLOYED CLIENTS.

   THE TEXT BELOW MAY, OR MAY NOT, BE THE CURRENT DESCRIPTION OF THE
   COMMAND AND IT MAY, OR MAY NOT, BE THE DESCRIPTION USED IN THE FINAL
   STANDARD.

Now, that said, below is the basics from a pre-draft copy I had laying
about ...

6. Virtual FTP servers

   It has become common in the Internet for many domain names to be
   allocated to a single IP address.  This has introduced the concept of
   a "virtual host", where a host appears to exist as an independent
   entity, but in reality shares all of its resources with one, or more,
   other such hosts.

   Such an arrangement presents some problems for FTP Servers, as all
   the FTP Server can detect is an incoming FTP connection to a
   particular IP address.  That is, all domain names which share the IP
   address also share the FTP server, and more importantly, its NVFS.
   This means that the various virtual hosts cannot offer different
   virtual file systems to clients, nor can they offer different
   authentication systems.

   No scheme can overcome this without modifications of some kind to the
   user-PI and the user-FTP process.  That process is the only entity
   that knows which virtual host is required.  It has performed the
   domain name to IP address translation, and thus has the original
   domain name available.

   One method which could be used to allow a style of virtual host 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 filestores of the
   virtual hosts as sub-directories in its NVFS.  This is simple, and
   supported by essentially all server-FTP implementations without
   requiring any changes.

   While that method is simple to describe, and to implement, it suffers
   from several drawbacks.  First, the "CWD" command is available only
   after the user-PI has authenticated itself to the server-FTP process.
   Thus, all virtual hosts would be required to share a common
   authentication scheme.  Second, either the server-FTP process needs
   to be modified to understand the special nature of this first CWD
   command, negating most of the advantage of this scheme, or all users
   must see the same identical NVFS view upon connecting (they must
   connect in the same initial directory) or the NVFS must implement the
   full set of virtual host directories at each possible initial
   directory for any possible user, or the virtual host will not be
   truly transparent.  Third, and again unless the server is specially
   modified, a user connecting this way to a virtual host would be able
   to trivially move to any other virtual host supported at the same
   server-FTP process, exposing the nature of the virtual host.

   Other schemes overloading other existing FTP commands have also been
   proposed, none of those have sufficient merit to be worth
   explanation.

   The conclusion from the examination of the possibilities seems to be
   that to obtain an adequate emulation of "real" FTP servers, server
   modifications to support virtual hosts are required.  A new command
   seems most likely to provide the support required.

6.1. The HOST command

   A new command "HOST" is added to the FTP command set to allow
   server-FTP process to determine to which of possibly many virtual
   hosts the client wishes to connect.  This command is intended to be
   issued before the user is authenticated, allowing the authentication
   scheme, and set of legal users, to be dependent upon the virtual host
   chosen.  Server-FTP processes may, if they desire, permit the HOST
   command to be issued after the user has been authenticated, or may
   treat that as an erroneous sequence of commands.  The behavior of the
   server-FTP process which does allow late HOST commands is undefined.
   One reasonable interpretation would be for the user-PI to be returned
   to the state it existed after the TCP connection was first
   established, before user authentication.

6.2. Syntax of the HOST command

   The HOST command is defined as follows.

        host-command     = "Host" SP hostname CRLF
        hostname         = 1*DNCHAR 1*( "." 1*DNCHAR ) [ "." ]
        DNCHAR           = ALPHA / DIGIT / "_" / "$" / "!" /
                           "%" / "[" / "]"
        host-response    = host-ok / error-response
        host-ok          = "234" [ SP *TCHAR ] CRLF

   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.  It should normally be the same name that
   was used to obtain the IP address to which the FTP control connection
   was made, after any client conversions to convert an abbreviated or
   local alias to a fully qualified domain name, but before resolving a
   DNS alias (owner of a CNAME resource record) to its canonical name.
   The parameter is to be treated as a complete domain name, as
   specified in section 3.1 of RFC 1034 [15].  That implies that the
   name is to be treated as a case independent string, in that upper
   case ASCII characters are to be treated as equivalent to the
   corresponding lower case ASCII characters, but otherwise preserved as
   given.

6.3. HOST command semantics

   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 so, establish the
   appropriate environment for that virtual host.  The meaning of that
   is not specified here, and may range from doing nothing at all, or
   performing a simple change of working directory, to much more
   elaborate state changes, as required.

6.4. HOST command errors

   The server-PI shall reply with a 500 or 502 reply if the HOST command
   is unrecognized or unimplemented.  A 503 reply may be sent if the
   HOST command is given after a previous HOST command, or after a user
   has been authenticated.  Alternately, the server may accept the
   command at such a time, with server defined behavior.  A 501 reply
   should be sent if the hostname given is syntactically invalid, and a
   504 reply if a syntactically valid hostname is not a valid virtual
   host name for the server.

   In all such cases the server-FTP process should act as if no HOST
   command had been given.

   A user-PI receiving a 500 or 502 reply should assume that the
   server-PI does not implement the HOST command style virtual server.
   It may then proceed to login as if the HOST command had succeeded,
   and perhaps, attempt a CWD command to the hostname after
   authenticating the user.

   A user-PI receiving some other error reply should assume that the
   virtual HOST is unavailable, and terminate communications.

6.5. FEAT response for HOST command

   A server-FTP process that supports the host command, and virtual FTP
   servers, MUST include in the response to the FEAT command [10], a
   feature line indicating that the HOST command is supported.  This
   line should contain the single word "HOST".  This MAY be sent in
   upper or lower case, or a mixture of both (it is case insensitive)
   but SHOULD be transmitted in upper case only.  That is, the response
   SHOULD be

        C> Feat
        S> 211- <any descriptive text>
        S>  ...
        S>  HOST
        S>  ...
        S> 211 End

   The ellipses indicate placeholders where other features may be
   included, and are not required.  The one space indentation of the
   feature lines is mandatory [10].

-- 

Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195