+------------------------------------------------------+
|                                                      |
|                                                      |
| +----------------+                  +--------------+ |
| | IPv6 Network   |                  | IPv4 Network | |
| | +-----------+  |  +------------+  | +----------+ | |
| | |IPv6       |--|--| IPv6-IPv4  |--|-|IPv4      | | |
| | |FTP Client |  |  | Translator |  | |FTP Server| | |
| | +-----------+  |  +------------+  | +----------+ | |
| |                |                  |              | |
| +----------------+                  +--------------+ |
|                                                      |
|                                                      |
+------------------------------------------------------+
      Figure 1. IPv6-IPv4 translation the FTP scenario.
            

Figure 1

The IPv6 FTP client is situated in an IPv6 network and communicates with an IPv4 server that is situated in an IPv4 network through a translation box in the middle. Here "IPv6 FTP client" means an FTP client that supports IPv6, i.e., it implements [RFC2428]. "IPv4 server" means an FTP server with only IPv4 connectivity, which may or may not support the RFC2428 extensions.

The situation where a legacy IPv4 FTP client that does not support the RFC2428 extensions runs on the IPv6 host is out of scope.

FTP has two operation modes: passive mode and active mode. In passive mode, the server listens on a TCP port, which the client connects to. In active mode, the server connects back to the client, using the IP address and port number provided by the client.

RFC2428 specifies extensions to the FTP protocol which let it work over IPv6, and make it easier for FTP to work through firewalls and NATs. Two new commands are specified: EPRT and EPSV. The EPRT command is an extension of the existing PORT command. It provides and IP address (IPv4 or IPv6) and a port number to the server to connect to. The EPSV command is a simplified version of the PASV command. Unlike with PASV, with EPSV the server does not respond with an IP address for the client to connect to. Instead, the server only specifies a port number. The IP address the client should connect to is the same IP address that the client is already connected to for the control channel TCP session.

Many servers do not support EPSV command today, or send a valid response, but the subsequent data channel connection fails to establish. However, most of these servers support PASV mode. This document provides recommendations for IPv6 FTP clients that allow them to successfully communicate with an IPv4 server through a stateless [RFC6145] or stateful [RFC6146] IPv6-IPv4 translation box.

2. Conventions used in this document

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

3. IPv6 FTP Client Considerations

According to [RFC2428], the IPv6 client SHOULD support EPSV and EPRT commands. This document recommends that the IPv6 FTP client SHOULD support both EPSV and PASV command. The reason is that during the early stage of IPv6 transition, many FTP servers will be still located in the IPv4 Internet and not support the EPSV command. This requirement implies that the IPv6 FTP client SHOULD support both IPv4 and IPv6. This requirement is reasonable since backward compatibility to IPv4 is one of the basic requirements for any IPv6 applications especially during the early stage of IPv6 transition.

Most of today's dedicated IPv4 FTP client software uses passive mode as the default mode. According to RFC 2428, for IPv6 FTP client, EPSV command MUST be used when the control and data connection is established between the same two machines. The reasons that both IPv4 and IPv6 FTP client prefer passive mode includes:

1. Active mode of FTP may introduce security issues. For example, the attacker may use PORT/EPRT command to specify a victim host's IP address and port, and then the FTP serve will send TCP SYN to the victim host to attempt to establish data connection. This kind of attack is recognized as FTP reflects attack.
2. Using passive mode of FTP can traverse firewalls and NATs more easily because passive mode does not require the middle box to implement an FTP ALG (Application Layer Gateway).

Considering the above, it is recommended that the IPv6 FTP client SHOULD use passive mode instead of active mode whenever it is possible.

In IPv6/IPv4 translation scenario, an IPv6 FTP client which is located in the IPv6 network may need to communicate with an IPv4 server which is located in the IPv4 network. In this case, the IPv4 server may not support EPSV command and if the IPv6 FTP client uses the EPSV command, the command may not be recognized so no file transfer can be established.

This document recommends that the IPv6 FTP client SHOULD retry with PASV command when EPSV command fails with a 50x response from the server, the server sends a 229 response but the data connection cannot be established, or the control channel TCP session is lost between the 229 response and any other messages sent over the control channel by the server.

After the client issues a PASV command, the IPv4 FTP server will respond with a 227 message that contains an IPv4 address and port number of the FTP server for the client to connect to. The IPv6 FTP client MUST ignore the IPv4 address provided in the response; instead, it MUST use the remote IP address used for the control channel to establish the data connection.

Many IPv4 FTP clients already ignore the IP address in the 227 response because this way, the data connection will still be established if the server includes its [RFC1918] address in the 227 response. Also, if a dual stack host connects over IPv6 for the control channel and then over IPv4 for the data channel, the server may reject the data channel connection because it comes from an unexpected address.

Another important benefit of this approach is that the translation box will not need to implement FTP ALG [RFC6384].

4. FTP Server considerations

Clients conforming to the recommendations listed above will be able to transfer files to/from all FTP servers. However, FTP servers are encouraged to support the EPSV command if this can be done successfully. If the server cannot successfully use the EPSV command, for instance, because the server is located behind an application aware firewall that only allows incoming data connections after observing 227 responses in the FTP control channel, then servers SHOULD return a 502 response when the client sends the EPSV command.

Implementers of FTP server software SHOULD include a setting that allows the EPSV command to return a 502 response.

5. FTP ALG considerations

This document recommends that the translation box does not need to implement FTP ALG [RFC6384] in the IPv6/IPv4 translation scenario. Instead, it is recommended that the IPv6 FTP client implementation should comply with this document to avoid the necessity of implementation FTP ALG in the IPv6/IPv4 translation box.

Adjusting the behaviour of IPv6 clients is feasible because IPv6 is not widely deployed and there are not much IPv6 FTP client been deployed currently. It is a good chance to publish this recommendation before the widely deployment of IPv6 and IPv6 FTP client.

5.1. FTP ALG limitations

Implementing FTP ALG in the translation box may have some limitations, such as:

1) FTP ALG may case to increase the complexity of translation box, since FTP ALG needs to understand FTP protocol and translate the application layer payload and update the header of FTP control packets. ALG could also cause impair the translation box's performance.

2) From the evolution perspective, if the network continues to provide support of FTP ALG indefinitely, the ALG function of the translation box will become more and more complex.

6. Security Considerations

FTP security is discussed in [RFC2577]. The extension that is defined in this document will not impact the FTP security.

7. IANA Considerations

No IANA action is required.

8. Acknowledgments

The authors want to thanks the following people for their useful suggestions: Robert Oslin, Anthony Bryan.

9. References

9.1. Normative References

[RFC0959]	Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC2428]	Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for IPv6 and NATs", RFC 2428, September 1998.
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2. Informative References

[RFC1918]	Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC2577]	Allman, M. and S. Ostermann, "FTP Security Considerations", RFC 2577, May 1999.
[RFC6145]	Li, X., Bao, C. and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6146]	Bagnulo, M., Matthews, P. and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6384]	van Beijnum, I., "An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation", RFC 6384, October 2011.

Authors' Addresses