One document matched: draft-van-beijnum-behave-ftp64-03.txt
Differences from draft-van-beijnum-behave-ftp64-02.txt
Behavior Engineering for Hindrance I. van Beijnum
Avoidance IMDEA Networks
Internet-Draft May 19, 2009
Expires: November 20, 2009
IPv6-to-IPv4 translation FTP considerations
draft-van-beijnum-behave-ftp64-03
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 20, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
FTP has an active and a passive mode, both as original commands that
are IPv4-specific, and in extended, IP version agnostic commands.
The only FTP mode that works without changes through an IPv6-to-IPv4
van Beijnum Expires November 20, 2009 [Page 1]
Internet-Draft IPv6-to-IPv4 FTP May 2009
translator is extended passive However, many existing FTP servers
don't support this mode, and some clients don't ask for it. This
document describes the optimal server, client and middlebox (if any)
behavior to minimize this problem.
1. Introduction
[RFC0959] specifies two modes of operation for FTP: active mode, in
which the server connects back to the client on port 20 or a client-
provided port number, and passive mode, where the server opens a port
for the client to connect to. Without additional action, active mode
doesn't work through NATs or firewalls. And in both cases, an IPv4
address is specified, making both modes incompatible with IPv6.
These issues were solved in [RFC2428], which specifies the EPSV
(extended passive) mode that only specifies a port number and the
EPRT (extended port) command which allows the client to supply an
IPv6 address to the server.
A survey done in April of 2009 of 25 randomly picked and/or well-
known FTP sites reachable over IPv4 showed that only 12 of them
supported EPSV over IPv4. Additionally, only 2 of those 12 indicated
that they supported EPSV in response to the FEAT command ([RFC2389]),
while one supported EPSV but not FEAT. In 5 cases, issuing the EPSV
command to the server led to a significant delay, in 3 cases followed
by a control channel reset. It appears that in these cases, the
server did support EPSV but a middlebox didn't. All 25 servers were
able to successfully complete a transfer in PASV mode as required by
[RFC1123]. More tests showed that the use of an address family
argument with the EPSV command is widely mis- or unimplemented in
servers. The additional tests with more servers showed that
approximately 65% of FTP servers support EPSV successfully and around
96% support PASV successfully. Clients weren't extensively tested,
but previous experience from the author suggests that most clients
support PASV, with the notable exception of the command line client
included with Windows, which only supports PORT when running over
IPv4 and EPRT when running over IPv6.
Based on the survey, this document recommends that all FTP servers
and client implement EPSV and that IPv6 FTP clients are updated to
retry with PASV when EPSV fails under the assumptiont that they are
communicating through an IPv6-to-IPv4 translator. Additionally,
there are guidelines for operators choosing to implement an
application layer gateway functionality to provide connectivity
between unupdated servers and/or clients.
The recommendations in this document apply to all forms of IPv6-to-
IPv4 translation, including stateless translation such as [RFC2765]
van Beijnum Expires November 20, 2009 [Page 2]
Internet-Draft IPv6-to-IPv4 FTP May 2009
and statefull translation such as [I-D.bagnulo-behave-nat64].
2. Notational Conventions
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. Server requirements
All FTP servers MUST support EPSV mode. Further, all FTP servers
MUST be configurable to respond with an error to EPSV and EPRT
commands, even though the server is capable of EPSV and/or EPRT.
This way, FTP servers residing behind firewalls or other middleboxes
that break EPSV or EPRT functionality will trigger clients to fall
back to PASV or PORT immediately rather than potentially suffering a
timeout.
All FTP servers MUST only use the local address used for the control
channel session in PASV responses. This allows an ALG to translate
the response to the PASV command to an EPSV response without loss of
information.
All FTP servers MUST indicate support for EPSV and/or EPRT when
available in response to the FEAT command and MUST NOT list EPSV
and/or EPRT in response to the FEAT command when EPSV and/or EPRT is
administratively disabled as outlined above.
4. Client requirements
All FTP clients MUST support EPSV when communicating over IPv6.
It is highly RECOMMENDED that FTP clients react by retrying with PASV
or EPRT when the EPSV command fails, either because of an error
response by the server, because the data connection couldn't be
created or because the control channel session was terminated. In
the latter two cases, a client MAY cache the name or address of the
FTP server and issue PASV rather than EPSV in future sessions. In
that case, the cache entry SHOULD be cleared if older than 7 days and
the server indicates EPSV support in its FEAT response where it
previously did not indicate EPSV support in its FEAT response.
When an FTP client is communicating over IPv6 and it is unable to use
the EPSV (and possibly EPRT) command successfully, it SHOULD retry
with PASV. However, the server will respond to the PASV command with
van Beijnum Expires November 20, 2009 [Page 3]
Internet-Draft IPv6-to-IPv4 FTP May 2009
an IPv4 address that the client must use to connect to for the data
connection. If the client has IPv4 reachability, it SHOULD set up a
data connection towards the IPv4 address. If the client doesn't have
IPv4 reachability, it SHOULD assume that it is communicating through
an IPv6-to-IPv4 translator, and that the IPv4 address in the server's
response is the same IPv4 address that the control channel session is
connected to. Under this assumption, the client SHOULD connect to
the address used for the control channel session on the indicated
port number.
Clients SHOULD NOT use any arguments with the EPSV command; many IPv4
FTP servers react adversely to "EPSV 1". Clients SHOULD assume that
servers are unaware of the IP version used by clients. This may be
the result from a server implementation that uses the updated IPv6
socket API with IPv4-mapped addresses, or because the server resides
behind an IPv6-to-IPv4 translator.
5. ALG functionality
This document does not speak out in favor or against the deployment
of an FTP application layer gateway. However, should an ALG be
implemented, it SHOULD behave as follows. Note that the translation
of EPSV through all translators and EPRT through a stateless
translator is relatively simple and that of EPRT through a stateful
translator relatively difficult. As such, an ALG used with a
stateful translator MAY choose to support only EPSV. However, an ALG
used with a stateless translator SHOULD also support EPRT.
5.1. Control channel translation
The IPv6-to-IPv4 FTP ALG intercepts all TCP sessions towards IPv4
port 21 destinations. The FTP ALG implements the Telnet protocol
([RFC0854]) used for control channel interactions to the degree
necessary to interpret commands and responses and re-issue those
commands and responses, modifying them as outlined below. Option
negotiation attempts by either the client or the server, except for
those allowed by [RFC1123], SHOULD be rejected by the FTP ALG without
relaying those attempts. This avoids the situation where the client
and the server negotiate options unknown to the FTP ALG.
If the client issues the AUTH command the client is attempting to
negotiate [RFC2228] security mechanisms which are likely to be
incompatible with the FTP ALG function. In this situation, the FTP
ALG MUST switch to transparently fowarding all data on the control
channel in both directions until the end of the control channel
session. This requirement applies regardless of the response of the
server.
van Beijnum Expires November 20, 2009 [Page 4]
Internet-Draft IPv6-to-IPv4 FTP May 2009
5.2. EPSV to PASV translation
Although many IPv4 FTP servers support the EPSV command, some servers
react adversely to this command, and there is no reliable way to
detect in advance that this will happen. As such, an FTP ALG MAY
translate all occurrences of the EPSV command issued by the the
client to the PASV command, and reformat a 227 response as a
corresponding 229 response.
For instance, if the client issues EPSV (or EPSV 2 to indicate IPv6
as the network protocol), this is translated to the PASV command. If
the server with address 192.0.2.31 then reponds with:
227 Entering Passive Mode (192,0,2,31,237,19)
The FTP ALG reformats this as:
229 Entering Extended Passive Mode (|||60691|)
If the server's 227 response contains an IPv4 address that doesn't
match the destination of the control channel, the FTP ALG SHOULD send
the following response to the client:
425 Can't open data connection.
It is important that the response is in the 4xx range to indicate a
temporary condition.
If the client issues an EPSV command with a numeric argument other
than 2, the ALG MUST NOT pass the command on to the server, but
rather respond with a 522 error.
If the client issues EPSV ALL, the FTP ALG MUST NOT pass this command
to the server, but respond with:
202 Command not implemented.
This avoids the situation where an FTP server may react adversely to
receiving a PASV command after the client indicated that it will only
use EPSV during this session.
5.3. EPRT to PORT translation
Should the IPv6 client issue an EPRT command, the FTP ALG MAY
translate this EPRT command to a PORT command. The translation is
different depending on whether the translator is a stateless one-to-
one translator or a stateful one-to-many translator.
van Beijnum Expires November 20, 2009 [Page 5]
Internet-Draft IPv6-to-IPv4 FTP May 2009
5.3.1. Stateless EPRT translation
If the address specified in the EPRT command is the client's IPv6
address, then the FTP ALG reformats the EPRT command into a PORT
command with the IPv4 address that maps to the client's IPv6 address.
The port number MUST be preserved for compatibility with stateless
translators.
If the address specified in the EPRT command is not the client's IPv4
address, the ALG's response is undefined. It may pass along the
command unchanged, respond with an error, or attempt to perform an
appropriate translation.
5.3.2. Stateful EPRT translation
If the address in the EPRT command is the IPv6 address of the control
channel client's address, the stateful translator selects an unused
port number in combination with the IPv4 address used for the control
channel towards the FTP server, and sets up a mapping from that
transport address to the one specified by the client in the EPRT
command. The PORT command with the IPv4 address and port used on the
IPv4 side of the mapping is only issued towards the server once the
mapping is created. Initially, the mapping is such that either any
transport address or the FTP server's IPv4 address with any port
number is accepted as a source, but once the three-way handshake is
complete, the mapping is narrowed to only match the negotiated TCP
session.
If the address in the EPRT command is not the client's IPv6 address,
the ALG's response is undefined.
5.4. Default port 20 translation
If the client doesn't issue an EPSV or EPRT command, it is invoking
the default active FTP behavior where the server sets up a TCP
session towards the default FTP data port (port 20). In the case of
a stateless translator, this doesn't pose any problems. In the case
of a stateless translator, it would be impossible to map incoming
sessions from the IPv4 FTP server to the correct IPv6 host if
multiple IPv6 hosts have sessions with the same FTP server at the
same time. As such, this case isn't supported in the presence of a
stateful translator and the data connection won't be established.
5.5. Timeouts
Wherever possible, control channels SHOULD NOT time out while there
is an active data channel. A timeout of at least 30 seconds is
recommended for mappings created by the FTP ALG that are waiting for
van Beijnum Expires November 20, 2009 [Page 6]
Internet-Draft IPv6-to-IPv4 FTP May 2009
initial packets.
Whenever a command from the client isn't propagated to the server,
the FTP ALG instead issues a NOOP command in order to keep the
keepalive state between the client and the server synchronized. The
response to the NOOP command is not sent back to the client.
6. IANA considerations
None.
7. Security considerations
In the majority of cases, FTP is used without further security
mechanisms. This allows a passive attacker to obtain the login
credentials, and an attacker that can modify packets to change the
data transferred. However, FTP can be used with TLS in order to
solve these issues. IPv6-to-IPv4 translation and the FTP ALG don't
impact the security issues in the former case nor the use of TLS in
the latter case. However, if FTP is used with TLS or another
authentication mechanism, the ALG function is not performed so only
passive transfers from a server that implements EPSV or a client that
supports PASV will succeed.
8. References
8.1. Normative References
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for
the File Transfer Protocol", RFC 2389, August 1998.
[RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228,
October 1997.
van Beijnum Expires November 20, 2009 [Page 7]
Internet-Draft IPv6-to-IPv4 FTP May 2009
[RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions
for IPv6 and NATs", RFC 2428, September 1998.
8.2. Informative References
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[I-D.bagnulo-behave-nat64]
Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
Address and Protocol Translation from IPv6 Clients to IPv4
Servers", draft-bagnulo-behave-nat64-03 (work in
progress), March 2009.
Appendix A. Acknowledgement
Kentaro Ebisawa and Remi Denis-Courmont provided useful comments.
Iljitsch van Beijnum is partly funded by Trilogy, a research project
supported by the European Commission under its Seventh Framework
Program.
Appendix B. Document and discussion information
The latest version of this document will always be available at
http://www.muada.com/drafts/. Please direct questions and comments
to the BEHAVE mailinglist or directly to the author.
Author's Address
Iljitsch van Beijnum
IMDEA Networks
Avda. del Mar Mediterraneo, 22
Leganes, Madrid 28918
Spain
Email: iljitsch@muada.com
van Beijnum Expires November 20, 2009 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 09:49:39 |