From touch at ISI.EDU Sat Aug 5 10:10:22 2006 From: touch at ISI.EDU (Joe Touch) Date: Sat, 05 Aug 2006 10:10:22 -0700 Subject: [ih] [e2e] What if there were no well known numbers? In-Reply-To: <20060805040424.A84515@gds.best.vwh.net> References: <5.1.0.14.2.20060804154539.00b13e40@boreas.isi.edu> <20060805040424.A84515@gds.best.vwh.net> Message-ID: <44D4D0FE.70703@isi.edu> 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: