Internet DRAFT - draft-liu-ftpext2-ftp64
draft-liu-ftpext2-ftp64
FTPEXT2 D. Liu
Internet-Draft China Mobile
Intended status: Best Current Practice Iljitsch. Beijnum
Expires: January 16, 2014 IMDEA Networks
Hui. Deng
Z. Cao
China Mobile
July 15, 2013
Recommendations for FTP Clients and Servers in the IPv6/IPv4 Transition
Scenario
draft-liu-ftpext2-ftp64-00
Abstract
The File transfer protocol, which was originally defined in RFC 114
and published in 1971, well before TCP and IP were created. However,
it is still in wide use. Many FTP servers implement RFC 959, which
requires IPv4. RFC 2428 defines extensions that allow FTP to work
over IPv6 by introducing the EPRT and EPSV commands. When IPv6 FTP
clients attempt to communicate with IPv4 FTP servers through an
IPv6-IPv4 translator, only certain combinations of FTP client and
server behavior lead to successful file transfers. This document
proposes the best current practice for IPv6 FTP client
implementations in the IPv6-IPv4 translation scenario, allowing file
transfers to succeed without the presence of an ALG (Application
Layer Gateway).
Status of This Memo
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 January 16, 2014.
Copyright Notice
Liu, et al. Expires January 16, 2014 [Page 1]
Internet-Draft Recommendation for IPv6 FTP client July 2013
Copyright (c) 2013 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. IPv6 FTP Client Considerations . . . . . . . . . . . . . . . 3
4. FTP Server considerations . . . . . . . . . . . . . . . . . . 5
5. FTP ALG considerations . . . . . . . . . . . . . . . . . . . 5
5.1. FTP ALG limitations . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Figure 1 illustrates FTP [RFC0959] in the IPv6-IPv4 translation
scenario.
+------------------------------------------------------+
| |
| |
| +----------------+ +--------------+ |
| | IPv6 Network | | IPv4 Network | |
| | +-----------+ | +------------+ | +----------+ | |
| | |IPv6 |--|--| IPv6-IPv4 |--|-|IPv4 | | |
| | |FTP Client | | | Translator | | |FTP Server| | |
| | +-----------+ | +------------+ | +----------+ | |
| | | | | |
| +----------------+ +--------------+ |
| |
| |
+------------------------------------------------------+
Liu, et al. Expires January 16, 2014 [Page 2]
Internet-Draft Recommendation for IPv6 FTP client July 2013
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
Liu, et al. Expires January 16, 2014 [Page 3]
Internet-Draft Recommendation for IPv6 FTP client July 2013
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.
Liu, et al. Expires January 16, 2014 [Page 4]
Internet-Draft Recommendation for IPv6 FTP client July 2013
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
Liu, et al. Expires January 16, 2014 [Page 5]
Internet-Draft Recommendation for IPv6 FTP client July 2013
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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions
for IPv6 and NATs", RFC 2428, September 1998.
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.
Liu, et al. Expires January 16, 2014 [Page 6]
Internet-Draft Recommendation for IPv6 FTP client July 2013
[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
Dapeng Liu
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: liudapeng@chinamobile.com
Iljitsch van Beijnum
IMDEA Networks
Avda. del Mar Mediterraneo, 22, Leganes
Madrid 28918
Spain
Email: iljitsch@muada.com
Hui Deng
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: denghui@chinamobile.com
Zhen Cao
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: caozhen@chinamobile.com
Liu, et al. Expires January 16, 2014 [Page 7]
