Network Working Group D. Liu
Internet-Draft China Mobile
Intended status: Informational Iljitsch van. Beijnum
Expires: April 4, 2011 IMDEA Networks
Z. Cao
China Mobile
October 17, 2010
FTP extension for IPv4/IPv6 transition
draft-liu-ftp64-extension-00
Abstract
The File transfer protocol, which is defined by the RFC 959, has a
long history, but still being widely used. The original version of
FTP specification defines IPv4 version of FTP. RFC 2428 defines IPv6
extensions of FTP, introducingEPRT and EPSV command. In the IPv6-
IPv4 translation scenario, considerations should be applied to FTP
client, server and translation box to ensure FTP protocol work
properly. This document discusses the details for FTP to work in
IPv4-IPv6 transitiion scenario. This document proposes to update
IPv6 FTP client's specification to make it easier to work in 6to4
scenario.
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 April 4, 2011.
Copyright Notice
Copyright (c) 2010 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
Liu, et al. Expires April 4, 2011 [Page 1]
Internet-Draft FTP extension for IPv4/IPv6 transition Oct. 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . 4
3. Client considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Server considerations . . . . . . . . . . . . . . . . . . . . . 5
5. FTP ALG considerations . . . . . . . . . . . . . . . . . . . . 5
5.1. FTP ALG limitations . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Liu, et al. Expires April 4, 2011 [Page 2]
Internet-Draft FTP extension for IPv4/IPv6 transition Oct. 2010
1. Introduction
Figure 1 illustrated the IPv6-IPv4 translation FTP scenario.
+----------------------------------------------- -----+
| |
| |
| +----------------+ +--------------+ |
| | IPv6 Network | | IPv4 Network | |
| | +-----------+ | +-----------+ | +----------+ | |
| | |IPv6 |--|--|Translation|--|-|IPv4 | | |
| | |FTP Client | | | Box | | |FTP Server| | |
| | +-----------+ | +-----------+ | +----------+ | |
| | | | | |
| +----------------+ +--------------+ |
| |
| |
+------------------------------------------------ ----+
Figure 1 IPv6-IPv4 translation FTP scenario.
Figure 1
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 and extensions
for implementing IPv6 FTP client to avoid the problems when an IPv6
FTP client communicating with an IPv4 server through a translation
box.
Liu, et al. Expires April 4, 2011 [Page 3]
Internet-Draft FTP extension for IPv4/IPv6 transition Oct. 2010
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 RFC 2119 [RFC2119].
3. Client considerations
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
Liu, et al. Expires April 4, 2011 [Page 4]
Internet-Draft FTP extension for IPv4/IPv6 transition Oct. 2010
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.
4. Server considerations
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.
5. FTP ALG considerations
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.
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 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.
6. Security Considerations
TBD
Liu, et al. Expires April 4, 2011 [Page 5]
Internet-Draft FTP extension for IPv4/IPv6 transition Oct. 2010
7. IANA Considerations
None
8. Acknowledgments
TBD
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.draft-ietf-behave-ftp64-05]
I. van Beijnum, "An FTP ALG for IPv6-to-IPv4 translation",
2010,
<http://tools.ietf.org/html/draft-ietf-behave-ftp64-05>.
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
Liu, et al. Expires April 4, 2011 [Page 6]
Internet-Draft FTP extension for IPv4/IPv6 transition Oct. 2010
Zhen Cao
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: caozhen@chinamobile.com
Liu, et al. Expires April 4, 2011 [Page 7]