[ih] History of the TCP/UDP port space

[Joe Touch]

I was researching this for an ID in preparation. This is consistent with
what Bob writes below, except that I didn't notice the importance of
rfc1090, but did have more specific info on the origins in the RFC series.

Corrections appreciated.

Joe

Bob Braden wrote:
> Barbara Denny asked me "when the port number space was divided into 3
> groups (well-known ports, registered ports and dynamic ports)."  I
> thought the following reply might be of more general historical
> interest.
> 
> Bob Braden

-----------------------

The term ‘port’ was first used in RFC33 to describe a simplex
communication path from a process. At a meeting described in RFC37, an
idea was described to decouple connections between processes and links
that they use as paths, and thus to include source and destination
socket identifiers in packets. RFC38 described this in detail, in which
processes might have more than one of these paths, and that more than
one may be active at a time. As a result, there was the need to add a
process identifier to the header of each message, so that the incoming
data could be demultiplexed to the appropriate process. RFC38 further
suggested that 32 bits would be used for these identifiers. RFC48
discusses the current notion of listening on a given port, but does not
discuss how the issue of port determination. RFC61 notes that the
challenge of knowing the appropriate port numbers is “left to the
processes” in general, but introduces the concept of a “well-known” port
for common services.

RFC76 addresses this issue more constructively, proposing a “telephone
book” by which an index would allow ports to be used by name, but still
assumes that both source and destination ports are fixed by such a
system. RFC333 suggests that the port pair, rather than an individual
port, would be used on both sides of the connection for demultiplexing
messages. This is the final view in RFC793 (and its predecessors,
including IEN 112), and brings us to their current meaning. RFC739
introduces the notion of generic reserved ports, used for groups of
protocols, such as “any private RJE server”. Although the overall range
of such ports was (and remains) 16 bits, only the first 256 (high 8 bits
cleared) in the range were considered assigned.
RFC758 is the first to describe a list of such well-known ports, as well
as describing ranges used for different purposes:

	 (decimal) (octal)
         0-63      0-77      Network Wide Standard Function
         64-127    100-177   Hosts Specific Functions
         128-223   200-337   Reserved for Future Use
         224-255   340-377   Any Experimental Function

In RFC820, those range meanings disappeared, and a single list of
assignments is presented. By RFC900, they appeared as decimal numbers
rather than the octal ranges used previously. RFC1340 increased this
range from 0..255 to 0..1023, and began to list TCP and UDP port
assignments individually (although the assumption was, and remains, that
once assigned a port applies to all transport protocols, including TCP,
UDP, recently SCTP and DCCP, as well as ISO-TP4 for a brief period in
the early 1990s). RFC1340 also established the registered space, though
it notes that it is not controlled by the IANA at that point. The list
provided by RFC1700 in 1994 remained the standard until it was declared
replaced by an on-line version, as of RFC3232 in 2002.

The current IANA website (www.iana.org) indicates three ranges of port
assignments:

	0-1023		Well-Known (a.k.a. ‘system’)
	1024-49151	Registered (a.k.a. ‘user’)
	49152-65535	Dynamic/Private

Well-known encompasses the previous range of 0..255 which was expanded
to 0..1023. On some systems, use of these ports requires privileged
access, e.g., that the process run as ‘root’. An additional range of
ports from 1024..49151 denotes non-privileged services, known as
‘registered’. Because both types of ports are registered, they are
sometimes distinguished by the terms ‘system’ (Well-known) and ’user’
(Registered).

------

> __________________________________________________________________
> 
> Barbara,
> 
> I just spent 2 minutes in the RFC search engine, and here is what
> I learned.
> 
> Before March 1990 (I traced it as far back as RFC 760 in Jan 1981),
> the port space was divided into well-known ports and dynamic ports,
> where the WK ports occupied the lowest 255 values and the rest was
> dynamic.
> 
> Around 1984, BSD UNIX became a factor in the Internet, and BSD reserved
> some ports in the range 256-1024 for their specific use.  These were
> not-quite-so-well-known ports, in effect.  For some years, the
> Internetters tried to ignore this intrusion on the prerogatives of the
> protocol jocks by the OS jocks.  But in March 1990, Jon Postel conceded
> to the reality of BSD importance by including "Unix Ports" in Assigned
> Numbers (RFC 1060), with the comment:
> 
>    "By convention, ports in the range 256 to 1024 are used for "Unix
>    Standard" services.  Listed here are some of the normal uses of these
>    port numbers."
> 
> Jon resolved this untidiness in July 1992 in RFC 1340.  This Assigned
> Numbers RFC expanded the well-known port space to 0-1023 and defined
> the rest (1024-65535) as "Registered".  Registered Ports had the comment:
> 
>    "The Registered Ports are not controlled by the IANA and on most systems
>    can be used by ordinary user processes or programs executed by ordinary
>    users.
> 
>    Ports are used in the TCP [45,106] to name the ends of logical
>    connections which carry long term conversations.  For the purpose of
>    providing services to unknown callers, a service contact port is
>    defined.  This list specifies the port used by the server process as its
>    contact port.  While the IANA can not control uses of these ports it
>    does register or list uses of these ports as a convienence to the
>    community.
> 
>    The Registered Ports are in the range 1024-65535."
> 
> The Unix ports were then listed in the Registered Ports space.
> 
> Hope this helps,
> 
> Bob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20060123/5ded5805/attachment.asc>