Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!ucbvax!SCRC-YUKON.ARPA!Margulies
From: Margulies@SCRC-YUKON.ARPA.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Port Collisions
Message-ID: <860513093608.7.MARGULIES@REDWING.SCRC.Symbolics.COM>
Date: Tue, 13-May-86 09:36:00 EDT
Article-I.D.: REDWING.860513093608.7.MARGULIES
Posted: Tue May 13 09:36:00 1986
Date-Received: Wed, 14-May-86 17:45:50 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 34
Approved: tcp-ip@sri-nic.arpa

Folks,

This mail is a follow-up to a discussion I had with Jon some weeks ago.

We here at Symbolics are concerned with the process of assigning TCP/UDP
port numbers.  It is not always appropriate for us (and other vendors)
to apply for ports in the Czar-controlled first 256 ports.  Either
because of time constraints or issues of proprietary information, we
cannot always write and distribute an RFC for each of our protocols.

We have had complaints from customers that we are not the only vendor
using the `any private file proctocol' port.

We need a way to define new protocols without feat of collision with
other people.

We see two possibilities:

1) A registry of ports for private protocols.  Symbolics would be
willing to administer a simple registry for a group of ports outside the
first 256. We (or someone else, it matters not) would keep a list, and
anyone from an identifiable organization could ask for ports.  The
registrar's only function would be to hand out each such port only once.
It would be helpful, of course, if the official RFC's for TCP/UDP would
designate the group of ports involved as reserved for use through this
registry.

2) A new protocol that would vastly increase the effective namespace by
multiplexing ports.  For example, a port that the user side connects to
and sends an arbitrary (or at least a reasonably long) character string
specifying the service desired.  Some obvious use of prefixes or
suffices would suffice to avoid collisions.

--benson