RFC 1639

FOOBAR: FTP Over Big Address Records 🎀

okay bestie, meet RFC 1639 💖 It's titled FTP Operation Over Big Address Records (FOOBAR) and it came from the Network Working Group 🌸 David M. Piscitello of Core Competence, Inc. wrote it in June 1994 ✨ Its category is Experimental, so it's a trial run and not an Internet standard 🧪 It obsoletes RFC 1545 💅 and the header doesn't list anything it updates.

---

Status of this Memo 🌈

This memo defines an Experimental Protocol for the Internet community 🧪 It does not specify an Internet standard of any kind. The authors want discussion and suggestions for improvement, and distribution of this memo is unlimited 💜

Abstract ✨

This paper describes a convention for specifying address families other than the default Internet address family in FTP commands and replies 🦋

Introduction 🌸

okay so in the File Transfer Protocol (STD 9, RFC 959), the PORT command argument <host-port> picks the data port used to set up a data connection for FTP 🎀 That same argument also shows up in the PASV reply, where it asks the server-DTP to listen on a data port that isn't its default one 👑

This RFC gives addresses other than 32-bit IPv4 addresses a way to be assigned to data ports. It does that with a "long Port (LPRT)" command and a "Long Passive (LPSV)" reply, and each one takes a <long-host-port> argument 😭 That argument allows extra address families, variable-length network addresses, and variable-length port numbers. It's giving flexibility 🔥

This is a general solution for all "next generation" IP alternatives, and for network protocols that aren't IP too 🧚 This revision also extends FTP so it can run over transport interfaces other than TCP 💅

Acknowledgments 🫶

Huge thanks to everyone at the IETF who casually mentioned how to do this but left it to the author to actually write the RFC 💀 Special thanks to Rich Colella, Bob Ullmann, Steve Lunt, Jay Israel, Jon Postel, Shawn Ostermann, and Tae Kyong Song, who all contributed to this work ✨

1. Background 🍓

The PORT command in File Transfer Protocol lets users pick an address other than the default data port for the transport connection that carries the data 🦋 The PORT command syntax is:

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

The <host-port> argument is a 32-bit internet <host-address> joined with a 16-bit TCP <port-address> 💜 That address info gets split into 8-bit fields, and each field goes out as a decimal number in character string form. Commas separate the fields. 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 🎀

The <host-port> argument also shows up in the PASV reply and in certain negative completion replies 🌸

Newer IP "next generation" options will need bigger network addresses, and FTP has to work over network and transport protocols besides IP. So FTP needs new commands and reply codes 🚀

2. The LPRT Command 🌈

The LPRT command lets users pick a "long" address for the transport connection that carries data ✨ The LPRT command syntax is:

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

The <long-host-port> argument is made by joining these fields together:

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

The starting values for the <address-family> argument match the version number of IP (see Assigned Numbers, STD 2, RFC 1340) 👑 So values from 0 to 15 decimal are reserved for IP and get assigned by IANA. Values from 16 to 255 are open for IANA to hand out to every other network layer protocol FTP might run over 🧚

Here are the relevant assigned <address-family> numbers for FOOBAR 💅

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
16              Novell IPX

Each field's value is split into 8-bit fields, and each one goes out as an unsigned decimal number in character string form. Negative numbers are explicitly not permitted ⚠️ Commas separate the fields 💜

A LPRT command is shaped like this, and yes, the order matters 💀

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 other than its default one, and to wait for a connection instead of starting one when a transfer command arrives 🌸 The reply carries the address family, the host address length indicator, the host address, the port address length, and the port address of the server's listener process ✨ The reply code for entering passive mode with a long address is 228. (By FTP's rules, that's a positive completion reply 2yz, connections x2z, passive mode entered using long address xy8) 🔥

The suggested message that goes with this reply code is:

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

4. Permanent Negative Completion Reply Codes 💅

The negative completion reply codes already tied to syntax errors in the PORT and PASV commands also fit the LPRT and LPSV commands, which are 500 and 501 🍓 But there's a gap: an extra negative completion reply code is needed to tell apart a host that supports LPRT or LPSV and still doesn't support the address family you asked for 😭

Out of the FTP reply code groupings (syntax, information, connections, authentication and accounting, and file system), "connections" seems like the most logical pick 🧠 So a new negative command completion reply code, 521, gets added, with this suggested text:

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 🌈 (Side note: someone suggested the families could also be written as ASCII strings 👀)

5. Rationale 💖

An explicit address family argument in the LPRT command and LPSV reply lets the Internet community experiment with lots of "next generation IP" and other network layer protocols, all inside one common FTP implementation framework ✨ It also allows a different address family on the command connection than on the data connection 🦋

An explicit length indicator for the host address is needed because some of the IPNG alternatives use variable-length addresses 🧚 An explicit host address is needed too, because FTP says it's necessary 💀

Adding a length indicator for the port number isn't as obvious, and it definitely goes past the bare requirement of supporting TCP port numbers 🙈

Right now at least one IPng alternative (TP/IX) supports longer port addresses 👑 With the Internet getting more and more "multi-protocol," it's reasonable that somebody, somewhere, might want FTP to run over Appletalk, IPX, and OSI networks as well as TCP/IP networks 🌍 (In theory, FTP should run 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 have to change to handle bigger network addresses, it could be wise to check right then whether the same flexibility is useful or needed for transport addresses too 🫶

6. Conclusions 🌸

The mechanism defined here is simple and extensible, and it covers both the IPNG and the multi-protocol internet needs 👑✨

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 💀

Security issues are not discussed in this memo 🙈 So if you're building on this, go in knowing it's not covered here, bestie 😭

9. Author's Address 🦋

David M. Piscitello
Core Competence, Inc.
1620 Tuckerstown Road
Dresher, PA 19025

EMail: dave@corecom.com