RFC 2428

FTP Extensions for IPv6 and NATs

📅 published September 1998, from ietf

FTP Extensions for IPv6 and NATs 🎀

okay bestie, this is the RFC that gives FTP its IPv6 glow-up 💖 It's RFC 2428 and it's on the Standards Track 👑 The authors are M. Allman (NASA Lewis/Sterling Software), S. Ostermann (Ohio University), and C. Metz (The Inner Net). It's dated September 1998 🦋 The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Status of this Memo 📜

This doc is an Internet standards track protocol for the Internet community, and it's asking everyone to talk about it and suggest improvements 💬 If you want the official standardization state, check the current "Internet Official Protocol Standards" (STD 1) 🔍 And yes, distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (1998). All Rights Reserved. 💅

Abstract 🧚

FTP was built on the assumption that the network layer uses a 32-bit address, specifically IP version 4 🥺 But once IP version 6 shows up, addresses won't be 32 bits anymore 😭 This paper adds extensions so FTP can work over both IPv4 and IPv6. The framework is also built to support other network protocols down the road 🔮

1. Introduction ✨

Heads up, the keywords like MUST and SHOULD in this document are used as defined in RFC 2119 [Bra97] 📚

FTP, as described in [PR85], can only talk about IPv4 data connections 🙃 It assumes addresses are 32 bits long, but IPv6 [DH96] changes that for real. RFC 1639 [Pis94] already added extensions so FTP can run over different network protocols, but the mechanism can break in a multi-protocol setup 💀 During the switch from IPv4 to IPv6, FTP needs a way to negotiate which network protocol gets used for the data transfer 🤝

This document gives FTP a way to share data connection endpoint info for network protocols beyond IPv4 🦋 The big change: the PORT and PASV commands get replaced with EPRT and EPSV 🔄 Section 2 covers the EPRT command, and Section 3 covers EPSV. Section 4 explains how these two new commands get used together, Section 5 gives a quick look at security considerations, and Section 6 wraps everything up 🎀

2. The EPRT Command 💌

The EPRT command lets you specify an extended address for the data connection. That extended address MUST consist of the network protocol as well as the network and transport addresses 🌸 The format looks like this:

EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>

The EPRT command keyword MUST be followed by a single space (ASCII 32) ✨ After the space, a delimiter character (<d>) MUST be specified 🍓 That delimiter MUST be one of the ASCII characters in range 33-126 inclusive. The character "|" (ASCII 124) is recommended, unless it clashes with a character needed to encode the network address 💜

The <net-prt> argument MUST be an address family number defined by IANA in the latest Assigned Numbers RFC (RFC 1700 [RP94] as of the writing of this document) 🔢 This number tells you which protocol to use, and implicitly how long the address is. This doc uses two address family numbers from [RP94] as examples, and they look like this:

AF Number   Protocol
---------   --------
1           Internet Protocol, Version 4 [Pos81a]
2           Internet Protocol, Version 6 [DH96]

The <net-addr> is a protocol specific string representation of the network address 🌐 For the two address families above (AF Number 1 and 2), addresses MUST be in the following format:

AF Number   Address Format      Example
---------   --------------      -------
1           dotted decimal      132.235.1.2
2           IPv6 string         1080::8:800:200C:417A
            representations
            defined in [HD96]

The <tcp-port> argument must be the string representation of the number of the TCP port on which the host is listening for the data connection 🎧

Here are some sample EPRT commands for you 😌

EPRT |1|132.235.1.2|6275|

EPRT |2|1080::8:800:200C:417A|5282|

The first command tells the server to use IPv4 to open a data connection to the host "132.235.1.2" on TCP port 6275 💅 The second one tells the server to use the IPv6 network protocol, with the network address "1080::8:800:200C:417A", to open a TCP data connection on port 5282 🧚

When a valid EPRT command comes in, the server MUST return a code of 200 (Command OK) 🥳 The standard negative error codes 500 and 501 [PR85] handle most errors, like syntax errors, involving EPRT. But we do need one extra code: 522 means the server doesn't support the requested network protocol 🙈 Here's how to read it:

5yz Negative Completion
x2z Connections
xy2 Extended Port Failure - unknown network protocol

The text portion of the response MUST indicate which network protocols the server does support 💖 If the network protocol is unsupported, the response string MUST look like this:

<text stating that the network protocol is unsupported> \
    (prot1,prot2,...,protn)
The numeric code and whatever's between '(' and ')' are for software to read. The text between the code and the '(' is for humans and can say anything you want, but it MUST NOT include the characters '(' and ')' 🤖 In the unsupported case, the text SHOULD say that the network protocol in the EPRT command isn't supported by the server. The list inside the parentheses MUST be a comma separated list of address family numbers 🌈 Here are two example response strings:
Network protocol not supported, use (1)

Network protocol not supported, use (1,2)

3. The EPSV Command 🦋

The EPSV command asks a server to listen on a data port and wait for a connection 👂 It takes an optional argument. The response only includes the TCP port number of that listening connection. The response format is similar to the EPRT argument, so the same parsing routines can handle both commands ♻️ It also leaves a placeholder for the network protocol and/or network address, in case the EPSV response needs them later 🔮 The response code for entering passive mode with an extended address MUST be 229 💫 According to [PR85], this code means:

2yz Positive Completion
x2z Connections
xy9 Extended Passive Mode Entered

The text returned for the EPSV command MUST be:

<text indicating server is entering extended passive mode> \
    (<d><d><d><tcp-port><d>)

The part inside the parentheses MUST be the exact string the EPRT command needs to open the data connection, as described above 🎀

The first two fields inside the parentheses MUST be blank 🙃 The third field MUST be the string representation of the TCP port number on which the server is listening for a data connection. The data connection will use the same network protocol as the control connection 🤝 It'll also use the same network address as the control connection. Here's an example response string:

Entering Extended Passive Mode (|||6446|)

The standard negative error codes 500 and 501 handle all errors involving EPSV, like syntax errors 🙌

When EPSV comes with no argument, the server picks the network protocol for the data connection based on what the control connection is using 🧠 But with proxy FTP, that protocol might not be the right fit for talking between the two servers 😬 So the client needs a way to ask for a specific protocol. If the server returns a protocol the host connecting to that port doesn't support, the client MUST issue an ABOR (abort) command so the server can close the listening connection 🛑 After that, the client can send an EPSV command asking for a specific network protocol, like this:

EPSV<space><net-prt>

If the server supports the requested protocol, it SHOULD use it ✅ If not, the server MUST return the 522 error messages outlined in section 2 🥲

Last one: the EPSV command can take the argument "ALL" to tell Network Address Translators that EPRT (and other data commands) won't be used anymore 🌙 Here's an example:

EPSV<space>ALL

When the server gets an EPSV ALL command, it MUST reject all data connection setup commands other than EPSV (i.e., EPRT, PORT, PASV, et al.). Section 4 explains this use of EPSV in more detail 🫶

4. Command Usage 🍭

When the control and data connections are being set up between the same two machines for an FTP transfer, the EPSV command MUST be used 💜 Using EPSV helps transfers that go through firewalls or Network Address Translators (NATs) perform better 🚀 [Bel94] in RFC 1579 recommends using the passive command behind firewalls, since firewalls usually don't allow incoming connections, and those are needed when you use PORT (EPRT) 🧱 Also, using EPSV the way this document defines it doesn't make NATs rewrite the network address in the traffic as it's forwarded. A NAT would have to change the address if EPRT were used 😮‍💨

And if the client sends "EPSV ALL", NATs may be able to put the connection on a "fast path" through the translator 🏎️ That's because EPRT will never be used, so the data portion of the segments never needs translating 🧚‍♀️ If a client only expects two-way FTP transfers, it SHOULD send this command as soon as possible ⏰

If a client issues EPSV ALL and then later realizes it must do a three-way FTP transfer, a new FTP session MUST be started. No cap, that's a lot of restarting 💀

5. Security Issues 🚨

The authors don't believe these changes to FTP introduce new security problems 🔐 A companion Work in Progress [AO98] goes deeper into FTP security issues and techniques for reducing them 🕵️‍♀️

6. Conclusions 🌟

The extensions in this paper will let FTP run over a whole bunch of network protocols, and that's iconic 👑🎉

References 📚✨

okay bestie, here's the whole reading list 🫶 every single one of these gets cited above, so here they are with all their details:

  • [AO98] Allman, M., and S. Ostermann, "FTP Security Considerations", Work in Progress.
  • [Bel94] Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February 1994.
  • [Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [DH96] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
  • [HD96] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
  • [Pis94] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR)", RFC 1639, June 1994.
  • [Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
  • [Pos81b] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
  • [PR85] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
  • [RP94] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html

Authors' Addresses 🎀

these are the people who wrote it, bestie, so you know who to thank (or slide into the DMs of) 💅

Mark Allman
NASA Lewis Research Center/Sterling Software
21000 Brookpark Rd.  MS 54-2
Cleveland, OH  44135

Phone: (216) 433-6586
EMail: mallman@lerc.nasa.gov
http://gigahertz.lerc.nasa.gov/~mallman/
Shawn Ostermann
School of Electrical Engineering and Computer Science
Ohio University
416 Morton Hall
Athens, OH  45701

Phone: (740) 593-1234
EMail: ostermann@cs.ohiou.edu
Craig Metz
The Inner Net
Box 10314-1954
Blacksburg, VA  24062-0314

Phone:  (DSN) 754-8590
EMail: cmetz@inner.net

Copyright (C) The Internet Society (1998). All Rights Reserved.

okay, the legal bit, but I kept every single condition 🫶

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.

However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
📦 where this page comes from