Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!ucbvax!nrtc-gremlin!mrose
From: mrose@nrtc-gremlin.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Port Collisions
Message-ID: <14084.516553663@nrtc-gremlin.northrop.com>
Date: Thu, 15-May-86 19:29:35 EDT
Article-I.D.: nrtc-gre.14084.516553663
Posted: Thu May 15 19:29:35 1986
Date-Received: Sat, 17-May-86 04:28:09 EDT
References: <860515080358.4.MARGULIES@REDWING.SCRC.Symbolics.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: tcp-ip@sri-nic.ARPA
Organization: The ARPA Internet
Lines: 20
Approved: tcp-ip@sri-nic.arpa


    The obviously problem with a "multiplexing port" is that you can no
    longer tell by looking at the TCB what protocol is being spoken.
    This renders programs like netstat on BSD UNIX, et. al., pretty
    much worthless.  If we're going to expand the port space somehow, I
    vote we do it explicitly in the TCP headers, so it's part of the
    information in the TCB, rather than expand the port space covertly
    by exchanging the information in the TCP data.  

/mtr

    ps:  of course, this is the exact opposite of what we did in rfc973
    (iso transport on top of the tcp), primarily because I thought 1)
    keeping track of the numbers, if there ever were numbers, should be
    separate from the tcp port space, since the protocols probably
    weren't going to look anything like our good old ARM-style protocols
    ; and, 2), there's a good chance that we'd need more than 512 port
    numbers in the next three-five years.  To postpone that problem, 4K
    port numbers were reserved; presumably, though I didn't think about
    it, 2K of those are for "private" use.