[ih] [e2e] What if there were no well known numbers?

[Joe Touch]

I had tried to develop a history for a ports usage doc I was working on;
it was posted to Internet-History a while ago. It's close to what Greg
found, but not exactly. Anyone care to help resolve the two where they
differ?

(cross-posted to Internet-history for obvious reasons)

Joe

Greg Skinner wrote:
> I wasn't involved in any of the ARPANET R&D, but I was able to piece
> together a bit from the old RFCs.  The socket as connection identifier
> made its debut in RFC 33.  It was a 8-bit field called AEN (Another
> Eight-Bit Number).  The idea that there should be a "directory"
> of sockets appeared in RFC 65. Jon Postel posed the question of
> whether standard protocols should have assigned/reserved socket
> numbers in RFC 205.  The first call for well known socket numbers came
> in RFC 322 (accompanying a concern about which socket numbers were
> currently in use at which hosts).  JP proposed that he be the "czar"
> for standard socket numbers in RFC 349.  So it seems as if well-known
> sockets were an expediency, as you say, which was preserved in TCP and
> UDP.
> 
> BTW, speaking of hosts.txt, RFC 226 contained the first cut at an
> "official" hosts list.  (Before that, the RFC noted that each telnet
> implementation provided its own list of host names.)

2. A Little History
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:
         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).

-------------- 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/20060805/67f9679c/attachment.asc>