RFC 1545

RFC 1545: FTP Operation Over Big Address Records (FOOBAR) 💖

Network Working Group 🌸

Okay bestie, here's the official paperwork up top 📄:

• Request for Comments: 1545 🎀
• Written by: D. Piscitello (David M. Piscitello) of Bellcore 🧑‍💻
• Category: Experimental 🧪
• Date: November 1993 📅
• Obsoletes / Updates: this title block doesn't list any ✨

---

Status of This Memo 🌸

This memo defines an Experimental Protocol for the Internet community, so it's a fun experiment and not an Internet standard of any kind 🧪. Discussion and suggestions for improvement are super welcome 💬. Distribution of this memo is unlimited 🌈.

Abstract 🍓

So this doc is basically about giving the PORT command longer addresses 📬. Think of it as a glow-up for PORT 💅.

Introduction 🧚

This RFC describes a way to assign long addresses in the HOST-PORT specification for the data port that gets used when you set up a data connection for File Transfer Protocol, FTP (STD 9, RFC 959). It's a general solution that works for all "next generation" IP alternatives, and it can also be stretched to let FTP run over transport interfaces other than TCP 🦋. Iconic, honestly.

Acknowledgments 🫶

Many thanks to all the folks in the IETF who casually mentioned how to do this, but then left it to the author to write the RFC 😭. Special thanks to Rich Colella, Bob Ullmann, Shawn Ostermann, Steve Lunt, and Brian Carpenter, who had the time and decency to comment on the initial draft 💖 :-)

---

1. Background ✨

So the PORT command in File Transfer Protocol lets users pick an address other than the default data port for the transport connection that data gets sent over 🧚. The syntax looks like this:

PORT <SP> <host-port> <CRLF>

The <host-port> argument is a 32-bit internet <host-address> stuck together with a 16-bit TCP <port-address> 🔥. That address info gets chopped into 8-bit fields, and each field is sent as a decimal number in character string form, separated by commas 🌸. So a PORT command looks like PORT h1,h2,h3,h4,p1,p2, where h1 is the high order 8 bits of the internet host address 💅.

Next-gen IP alternatives are expected to need bigger addresses, so FTP needs new commands and reply codes to handle that 👑. This memo is the one that sorts it out ✨.

2. The LPRT Command 🦋

The LPRT command lets users pick a "long" address for the transport connection that data gets sent over 🌈. The syntax is:

LPRT <SP> <long-host-port> <CRLF>

The <long-host-port> argument is made from these fields, in order:

• an 8-bit <address-family> argument (af)
• an 8-bit <host-address-length> argument (hal)
• a <host-address> that is <host-address-length> long (h1, h2, ...)
• an 8-bit <port-address-length> (pal)
• a <port-address> that is <port-address-length> long (p1, p2, ...)

The <address-family> takes the version number of IP (see Assigned Numbers, STD 2, RFC 1340). More generally, it's an Internet layer protocol number 🧠. These are the relevant IPng version numbers:

Decimal         Keyword
------          -------
0               reserved
1-3             unassigned
4               Internet Protocol (IP)
5               ST Datagram Mode
6               SIP
7               TP/IX
8               PIP
9               TUBA
10-14           unassigned
15              reserved

Each field's value gets chopped into 8-bit fields, and each one is sent as an unsigned decimal number in character string form 🔢. Negative numbers are explicitly not permitted, so no minus vibes here 🙅‍♀️. The fields are separated by commas.

So an LPRT command looks like this in general:

LPRT af,hal,h1,h2,h3,h4...,pal,p1,p2...

Here h1 is the high order 8 bits of the internet host address, and p1 is the high order 8 bits of the port number (transport address) 💖.

3. The LPSV Command 🎀

The L(ONG) PASSIVE command asks the server-DTP to listen on a data port that isn't its default one, and to wait for a connection instead of starting one when it gets a transfer command 🧚‍♀️. The response includes the address family, the host address length indicator, the host address, the port address length, and the port address the server is listening on 🫧.

The reply code for entering passive mode with a long address is 228. Interpretation according to FTP is: positive completion reply 2yz, connections x2z, passive mode entered using long address xy8 🔥. The suggested message that goes with it is:

228 Entering Long Passive Mode (af,hal,h1,h2,h3,h4...,pal,p1,p2...)

4. Permanent Negative Completion Reply Codes 💅

The negative completion reply codes for syntax errors in the PORT and PASV commands also work for LPRT and LPSV, which are 500 and 501 🙌. But there's a gap: we need a new negative completion reply code for when a host supports LPRT or LPSV and still doesn't support the address family someone asked for 🙈.

FTP groups its reply codes into syntax, information, connections, authentication and accounting, and file system. "Connections" seems like the most logical home for this one, so we're adding 521 with this suggested message:

521 Supported address families are (af1, af2, ..., afn)

Here, (af1, af2, ..., afn) are the version numbers of the "next generation" or other protocol families the host supports 🌸. IP address noted earlier.

5. Rationale 🧠

Having an explicit address family argument in the LPRT command and the LPSV reply lets the Internet community experiment with a bunch of "next generation IP" alternatives inside one common FTP implementation framework 🧪. It also means the command and data connections can use different address families 🤸‍♀️.

An explicit length indicator for the host address is necessary, because some of the IPNG alternatives use variable length addresses 📏. An explicit host address is also necessary, because FTP says it's necessary 🤷‍♀️ (no cap, that's the whole reason).

The port number length indicator is less obvious 👀. It goes beyond the bare minimum of supporting TCP port numbers. At least one IPng alternative (TP/IX) already supports longer port addresses 🦋. And with the Internet getting more and more "multi-protocol," someone, somewhere, might want FTP to run over Appletalk, IPX, and OSI networks as well as TCP/IP networks 🌍. (In theory, FTP should work over any transport protocol that offers the same service as TCP 💫.) Some of those transport protocols might offer transport selectors or port numbers longer than 16 bits, so a length indicator could be useful 🔢. If FTP really does need to change to fit larger network addresses, it's probably smart to figure out right now whether that same flexibility is useful or needed for transport addresses too 🧠✨.

6. Conclusions 👑

The mechanism defined here is simple, extensible, and meets both IPNG needs and possibly multi-protocol internet needs 💖. Iconic, periodt.

7. References 📚

• STD 9, RFC 959: Postel, J., and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, USC/Information Sciences Institute, October 1985. 🗂️
• STD 2, RFC 1340: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. (Does not include recently assigned IPv7 numbers.) 🔢
• STD 3, RFC 1123: Braden, R., Editor, "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, USC/Information Sciences Institute, October 1989. 🖥️

8. Security Considerations 💀

Plot twist: security issues are not discussed in this memo 😱. Please take that seriously, bestie 🙏.

⚠️ Security isn't covered in this memo, so don't assume anything about it from here. Go check other sources before you ship anything 💀.

9. Author's Address 💌

David M. Piscitello Bell Communications Research NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701

EMail: dave@mail.bellcore.com 💜