RFC 617

A Note on Socket Number Assignment 2 🎀

Okay bestie, the title block is giving: this is RFC 617 🦋, written by Edward Taft (PARC-MAXC) and dated Feb 1974, with NIC #21771. It came out of the Network Working Group. The header doesn't list a category, and it doesn't obsolete or update anything. ✨

INTRODUCTION ✨

Okay so in a bunch of protocols and other docs, people assume (or just kinda imply) that a user process driving one end of a Telnet connection gets free access to a group of socket numbers that start with or surround the Telnet socket numbers. 💅

For example, the File Transfer Protocol (RFC 542, NIC #17759) says the default data transfer sockets are S+2, S+3, U+4, and U+5, where S and U are the server and user sockets used in the initial connection (ICP). 🧚

The proposed Network Graphics Protocol (NIC #19933) sets up a second connection pair for graphics data, parallel to the Telnet connection, using sockets n+6 and n+7 at both ends, where n is the Telnet receive socket. 🌈

I really need protocol designers to know that the Host-Host Protocol (NIC #8246) explicitly puts no interpretations or constraints on how hosts assign socket numbers, except that the low-order bit indicates direction of data flow. 🫶 We should stop making extra assumptions. The "Socket Number List" document (RFC 503, NIC #15747) does this when it says the low-order 8 bits are "user-specified," and that could accidentally rule out certain host software architectures or protocol implementations. 💀

AN EXAMPLE 🍓

To show you where I'm coming from, let me walk through the user software interface to the network in the PDP-10 NCP implementation that's currently used at HARV-10, CMU-10A, and CMU-108. Then I'll explain why the fixed socket number requirements of those two protocols I mentioned earlier cause implementation problems, especially at the server end. 😭

Opening a connection at one of these hosts creates a "device" (kinda like mounting a disk pack). So an open connection can be hit by any of a bunch of operations on devices in 10/50, like assigning logical names, opening for data transfer, and reassigning to another job. 👑

The NCP lets a (non-privileged) user program pick the low-order 8 bits of the socket number of any connection it opens. It can also specify that the other 24 bits get assigned in one of three ways: 🔥

• As a function of the job number, making a "job-relative" socket.
• As a function of the user identification, making a "user-relative" socket.
• As a "guaranteed unique" number, i.e. one assigned by the NCP such that no other socket number in use has the same high-order 24 bits.

A program can also specify all 32 bits of a local socket number, as long as the high-order 24 bits match the corresponding bits in some other socket already owned by the same job. ✨

The NCP will only allow assignment of a socket generated in any of the above ways if it's not already in use by the same or any other job. 🙈

---

PROBLEMS IN THE FTP SERVER IMPLEMENTATION 5 ✨

The FTP server is built in a way that some readers might find reminiscent of Padlipsky's "Unified User Level Protocol" (RFC 451, NIC #14135). Instead of directly running most FTP functions (system access and file transfer especially), it maps FTP commands into local commands that it "types" on a pseudo-Teletype (PTY) to a subjob. It also maps local responses back into FTP responses. 🧠

This makes maximum use of existing software and mechanisms for user authentication, accounting, and file access. It also means the (privileged) FTP server doesn't have to do those things interpretively. (This conforms to the "principle of least privilege" described in RFC 501, NIC #15818.) 🔐

In this implementation, FTP data transfers are performed by an entirely different process (with a different user identification) from the one that manages the server end of the Telnet connection. So server sockets S and S+1 belong to the server "control" job, and sockets S+2 and S+3 sit in the same 256-socket number range. That means the latter two sockets are inaccessible to the "data transfer" subjob. 🫠

Those who attended last spring's FTP meeting may remember that I objected strongly to the requirement that the FTP server use a fixed pair of data sockets relative to its Telnet sockets. The old scheme let the server freely choose its data sockets, and I preferred that. 💜 The main reason is that the fixed pair would seem to rule out the "two-process" scheme I just described. 🙅

In fact, in our case there is a way around the problem. The FTP server control job can open the data connections itself, then "reassign" the created "device" to the data transfer subjob. A kludgey solution at best, and one I'd much rather have avoided! Inter-job socket reassignment is hardly an operation you'd expect to find in most operating systems. 😤

DIFFICULTIES WITH THE GRAPHICS PROTOCOL 💜

A graphics connection parallel to the Telnet connection (at a fixed socket number distance) could run into the same difficulty I described above for FTP connections. 🌸

In the most frequently used model of Telnet communication, as well as in many implementations, the server Telnet is a process quite separate from the "user" process under its control. The two processes are typically connected through the operating system's terminal service, so the "user" process sees a ,terminal" rather than a "network connection." 📺

In Tenex, for example, a job controlled from a network terminal has no handle whatsoever on the server Telnet connection. So it has no way of getting control of sockets n+6 and n+7 for a graphics connection. 🚫

In the Harvard-Carnegie 10/50 implementation, a job logged in from the network does have control (i.e. is considered the owner) of the server Telnet sockets. It's kinda accidental though, for largely accidental reasons. 🙈

There's another problem too. Many operating systems provide ways to change the association between terminals and jobs. To use familiar terminology, a terminal may be "detached" from one job and "attached" to another, without destroying any jobs or any network connections. 🔄

So it's totally possible for a user to start a program that uses sockets n+6 and n+7 (where n is the server Telnet receive socket). They could then detach their terminal from that job, attach it to another job, and try to run a program using the Graphics Protocol. The data connection would fail because sockets n+6 and n+7 are already in use, since it's the same network terminal and therefore the same value of n. 💀

CONCLUSION 7 🌈

There are, of course, a few network-wide socket number conventions that are needed for establishing the initial connection. ✨

Reserving sockets 0-255 for standard ICP functions is one example of that. 🎀

I also think that, to keep things simple, it's reasonable to expect any process to be able to gain control of a small block of "adjacent" sockets, like an even-odd pair (as in ICP), as long as it asks for them at the same time. 🧚

But as the examples above have shown, adding further fixed socket number requirements risks making unwarranted assumptions about protocol implementations, the structure of user processes, and so on, at individual hosts. 😭

Once the initial Telnet connection is established, any other necessary connections should be set up by negotiating over the Telnet connection. For example: Please connect to my socket xxxxxx, then OK, connecting via my socket yyyyyy. 🫶 There is absolutely no need for any protocol to specify fixed socket numbers, except for the purposes of the initial connection (ICP). 👑💖