IPv6 IPv4 translation FTP considerations

Figure 1 illustrated the IPv6-IPv4 translation FTP scenario.

The IPv6 FTP client situated in an IPv6 network and tries to communicate with an IPv4 server that situated in an IPv4 network through a translation box in the middle. It should be noted that in some scenario, the FTP client that running on the IPv6 host maybe legacy IPv4 FTP client. In this case, the communication will not succeed by only introducing translation box in the network. That case is out the scope of this document. FTP has two operation modes: passive mode and active mode. In passive mode, the server provides port used for the client to connect to. In active mode, the server connects back to the client, using the IP address and port number which provide by the client. RFC 2428 specifies IPv6 extension of FTP. Two new commands, EPRT/EPSV are specified. The EPRT command is an extension of PORT, it could provide IPv6 address and port number to the server. The EPSV command is an extension of PASV, when client sends this command, the server should responses its port number used for the client to connect. Many serves do not support EPSV command today, but most of them could support PASV mode. This document provides guidelines for implementing IPv6 FTP client to avoid the problems when an IPv6 FTP client communicating with an IPv4 server through a translation box.

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

According to RFC 2428, the IPv6 client SHOULD support EPSV and EPRT command. From the backward compatibility's perspective, this document suggests that the IPv6 FTP client SHOULD support both EPSV and PASV. The reason is that during the early stage of IPv6 transition, many FTP servers will be located in the IPv4 Internet which may not support EPSV command. This requirement implies that the IPv6 FTP client supports both IPv4 and IPv6 protocol version. This requirement is reasonable since backward compatibility to IPv4 is one of the basic requirements for any IPv6 applications especially in 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 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 and port, then the FTP serve will continually to send TCP SYN to the victim host to try to establish data connection. This kind of attack is recognized as FTP reflects attack. 2. Passive mode of FTP may benefit when traverse firewalls or NAT. using passive mode also eliminate FTP ALG in the middle box. From the above analysis, it is suggested that FTP client SHOULD use passive mode instead of active mode whenever it is possible. For IPv6 FTP client, according to RFC 2428, it should use EPSV command. In IPv4-IPv6 transition scenario, an IPv6 client may try to communicate with an IPv4 server. In this case, the IPv4 server may not support EPSV command and the EPSV command may fail. This document suggests that the IPv6 FTP client SHOULD retry with PASV command when EPSV command fails. The IPv4 FTP server will respond to PASV command with a message that contains an IPv4 address and port number of the FTP server that used for the client to connect to. The client MUST ignores the IPv4 address provided in the response; it should use the control connection's IP address to connect to the server to establish the data connection. The approach that simply ignoring PASV respond message's IP address and use control channel's IP address could not only simply the FTP client software's implementation but also can avoid the problems caused by using the IPv4 address that included in the response message. For example, if the FTP client has a private IPv4 connection and a public IPv6 connection, if it tries to use the IPv4 connection to establish data connection with the server, it will never succeed.

This document does not enforce any requirement for FTP server since this document considers the IPv6 FTP client communicating with IPv4 FTP server scenario. The IPv4 FTP server maybe just an ordinary IPv4 FTP server.

This document argues that since FTP is a protocol that could avoid ALG by slightly adjusting the operation of the IPv6 FTP client it is not recommended the translation box to implement FTP ALG. Adjusting the operation of IPv6 client is feasible because IPv6 is not widely deployed and there are not much IPv6 FTP client deployed right now. It is a good chance to give this guideline before the widely deployment of IPv6 and IPv6 FTP client.

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 the decline of the translation box's performance. 2) From the evolution perspective, if the network continues to provide support of FTP ALG all the time, the ALG function of the translation box will become more and more complex.

Although this document does not recommend implementing FTP ALG in the translation box but in some exceptional scenario the operator may want to deploy FTP ALG in their translation box for special purpose, this document also gives guidelines for FTP ALG implementation in t IPv6-IPv4 translation box. 1. Passive mode In passive mode, the IPv6 FTP client may send EPSV which may not recognized by the IPv4 FTP server. The FTP ALG may translate EPSV to PASV and the corresponding response messages should also be translated. 2. Active mode For active mode, the IPv6 FTP client may issue EPRT command which contains the client's IPv6 address and port number that used for the server to connect. The FTP ALG should translate EPRT command to PORT command. The FTP ALG should translate the client's IPv6 address to the corresponding IPv4 address. The IPv6-IPv4 mapping maybe created by the translation box during the initiating of FTP connection in statefull translation mode. In stateless translation mode, there is no need to create mapping dynamically. If the translation box using port multiplexing, the port number in the EPRT command should also be translated. 3. Default connection port According to RFC 959 if no EPSV or EPRT command issued, the server may connects to the client's control connection's port use source port 20. The FTP ALG should intercept this TCP connection and translate the corresponding port number if translation box translates the IPv6-IPv4 port number. 4. The control connection and data connection belongs to different machines The FTP protocol can support the scenario that the control connection and data connection belongs to different machines. The FTP ALG function of current version of this document does not address this scenario.

TBD

None

TBD