Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!ucbvax!MIT-MULTICS.ARPA!JSLove
From: JSLove@MIT-MULTICS.ARPA.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Port Collisions
Message-ID: <860516021852.205689@MIT-MULTICS.ARPA>
Date: Thu, 15-May-86 22:18:00 EDT
Article-I.D.: MIT-MULT.860516021852.205689
Posted: Thu May 15 22:18:00 1986
Date-Received: Sat, 17-May-86 04:40:46 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 138
Approved: tcp-ip@sri-nic.arpa

I think symbolic port names are a great idea.  There are several
approaches which could be taken.  Possibly implementations of some of
these already exist, but I don't know about them.

A service multiplexing protocol:  this applies to TCP but not to UDP
because it relies on connections.  First, reserve one low numbered TCP
port for this protocol.  When a user establish a connection to this
server, the user sends the contact name, and optional contact arguments,
in ASCII, terminated by a network newline (CRLF).  The contact name is
always required, and should either be registered, or long and self
explanatory.  CHAOS protocol allows arguments to follow the contact
name, and I think we should allow this also, but they depend on the
contact name and the only specification here is that they be delimited
from the contact name by a space.  The protocol server which listens on
this TCP port should parse the contact line, look it up in the available
service list, and pass off that connection as if it had just been
established to the service on a reserved port.  If the service is
unavailable, the connection should be aborted.

Note that "multiplexing" in this case is not used in the sense that is
it used in IEN 90, the MUX protocol.

TCBs on such systems should contain a comment field which is filled in
with the service name.  Then listing the TCBs can show the comment, and
it won't matter that all the multiplexed services are to the multiplexed
port.  (Multics already does this; it makes the TCB list much easier to
read.)

There should be no significant performance impact in using this
mechanism for TELNET, SUPDUP, SMTP, FINGER, or FTP control connections.
While services used for metering, like TIME, ECHO, DISCARD, etc., can be
expected to require dedicated port numbers, there should be no need to
dedicate port numbers for private services thereafter.  Even DOMAIN TCP
connections could use multiplexing.

There should be a reserved contact name which lists the available
contact names.  The WKS domain RR would be useful only in showing that
multiplexed service is available.  Perhaps this list operation should
include port numbers for contacting the services, when available.  A
standard format should be used, so that the list is machine-readable as
well as human-readable.

A fly in the ointment is that some services reserve port numbers in ways
that can't be multiplexed.  For example, the FTP data port is port 20.
A replacement for the FTP "PORT" command would be needed to eliminate
this assumption.  This could be addressed by modifying the FTP
specification and all similar protocols if it is ever needed.  But since
we are doing this primarily for new protocols, they can be devised with
some mechanism for negotiating additional connections, as needed, which
does not require reserving ports.

There are other advantages within operating systems.  Services other
than TCP which support streams could hand off, for example, SMTP
connections in a similar manner.  If an X.25 network like TYMNET is
connected two sites, the operating system might permit an X.25 level 3
connection to be passed off to the SMTP server.  The contact name
arguments in that case might include a host name and associated password
since you couldn't verify the host in the same way that you might using
the Internet.

An alternative or additional protocol could use a UDP service to map
contact names to ports.  You would send the contact name to the port as
a datagram, and receive back a datagram which would indicate that 1) the
service is available on port P, 2) the service is available on the
multiplexed port M, or 3) that the service is unavailable.  Choice #2
only applies to connection based services, but #1 and #3 could apply to
either TCP or UDP, and perhaps other lower level services as well.  If
the query packet also contained a transport ID (e.g., 6 for TCP) or name
(e.g., "TCP") then the service could be more generally applicable.

This permits the equivalent of multiplexed service on UDP, a minimum
cost of an extra datagram per host per service per bootload to find out
what the port number is assigned to a service.  It wouldn't matter that
one Symbolics 3600 was running NFILE on port 57, and another on port
666, as long as they both call the service "NFILE".

The UDP service could not be expected to be able to construct packets
large enough to contain the names of all the available services.  While
in many cases they would fit, it would be unreasonable to expect that
this always be the case.  Rather than add complexity to this protocol it
would be better to require contacting the TCP port to get the service
list.

The number czar (tsar?)  would still be needed to hand out contact names
like "TELNET" and "FINGER", and prefixes like "SYMBOLICS-".  Once Benson
has the "SYMBOLICS-" prefix he can hand out SYMBOLICS-PRIVATE-1,
SYMBOLICS-NFILE, and so on without having to bother the czar or fear of
conflict with the rest of the world.

The server port number returned by UDP can have any value.  The number
needn't be less than 256 or 1024 to provide security.  The 255 well
known ports are just that:  well known.  If a host implements security
based on port number, then it is only necessary to ensure that the port
number given out by the UDP multiplexing port is secured, even if it is
port FFFF (hex).  The UNIX port scheme depends on the user-side port
being less than 1024 to ensure that the connection is valid, not the
server side port number.

It is unnecessary to encode contact names in every packet, especially
for TCP.  A port number is sufficient to keep track of packets, and only
the two parties to a conversation need know how the numbers map to
services.  This may not be strictly true for gateways that restrict
services.  Schemes that I have heard of restrict the SYN-bearing TCP
packets.  I'm afraid that they would have to prohibit the multiplex
port.  However, the UDP port translation could be used to avoid using
the multiplex port for all contact names which don't require arguments.

It would be nice to see an alternative to UDP that was in most ways
identical to it, but which had a contact name in the packet instead of
one of the port numbers.  For simple transactions this would avoid the
complexity of exchanging packets to get the port number before anything
could be accomplished.  The format of the packet would be as follows:
The length would be in the pseudo header.  The source port would be
replaced by a transaction ID (15 bit number) and a query/response flag
(one bit).  The destination port would be replaced by an ASCII character
string, terminated by one or two nulls to take an even number of
characters.  Two bytes would be reserved for an optional checksum.  The
rest would be data octets.  If the contact name is long, the number of
available data octets would be fewer than for UDP, but if the response
flag were set, perhaps the contact name could be omitted from the
response packet, permitting longer responses.  Otherwise, the
query/response flag would indicate which of the ID and the contact name
is the local "port".

If there already exist RFCs describing protocols which implement any of
these schemes, please point them out.  Otherwise, someone with immediate
need for these services could write an RFC or two.

All that is necessary for the Internet to generally convert to this mode
of operation is that a version of Berkeley Unix get into the field which
supports multiplexed service and which has user programs which attempt
multiplexed operation if it is available.  I think the advantages of
this mode of operation will become so apparent that the rest of the
network will be converted within a year or two.

The time will come when both TCP and TP4 are considered hopelessly
outmoded antiques.  By making TCP services more flexible in this way,
perhaps that can be postponed.