Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!pyramid!pesnta!hplabs!ucbvax!BU-CS.BU.EDU!root
From: root@BU-CS.BU.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: re: port collisions
Message-ID: <8605151604.AA01899@bu-cs.ARPA>
Date: Thu, 15-May-86 12:04:14 EDT
Article-I.D.: bu-cs.8605151604.AA01899
Posted: Thu May 15 12:04:14 1986
Date-Received: Fri, 16-May-86 07:55:46 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 22
Approved: tcp-ip@sri-nic.arpa


I think there is a problem here. Due to obvious security reasons
many of these protocols will need a low socket number and there are
only 255 of those guaranteed to be available (UNIX extends that to
1023 but I don't think everyone can honor that.) Some small portion
of that is already in use and if commercial trends continue I suspect
many, many vendors will need a *secure* port for their products.

The only solution I can think of is a super-server protocol which
would listen on a single secure port and map strings to available non-secure
ports indirectly (I believe the TOPS-20 IPC works something like this.)
I've thought about it a few hours and it's not easy, especially when
you start to take different TCP implementations into account (how exactly
do I reserve and "hand-off" a port number between two unrelated processes?
that's an O/S issue but I fear not generally easy.)

Doesn't SUN's RPC (which I believe is in the public domain) address this
issue (no pun intended)? If you say "do you seriously expect me to implement
RPC and XDR just to get a port number?", I sympathize, I was only trying
to find analogues for enlightenment.

	-Barry Shein, Boston University