From braden at ISI.EDU Tue Jan 17 11:36:36 2006 From: braden at ISI.EDU (Bob Braden) Date: Tue, 17 Jan 2006 11:36:36 -0800 (PST) Subject: [ih] History of the TCP/UDP port space Message-ID: <200601171936.LAA12471@gra.isi.edu> 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 __________________________________________________________________ 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 From touch at ISI.EDU Mon Jan 23 14:42:51 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 23 Jan 2006 14:42:51 -0800 Subject: [ih] History of the TCP/UDP port space In-Reply-To: <200601171936.LAA12471@gra.isi.edu> References: <200601171936.LAA12471@gra.isi.edu> Message-ID: <43D55BEB.30302@isi.edu> 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: From braden at ISI.EDU Mon Jan 23 15:11:46 2006 From: braden at ISI.EDU (Bob Braden) Date: Mon, 23 Jan 2006 15:11:46 -0800 (PST) Subject: [ih] History of the TCP/UDP port space Message-ID: <200601232311.PAA15200@gra.isi.edu> Joe, I think you are confusing ARPAnet NCP port assignments with TCP/IP port assignments. The concept was carried over, but the assignment details were different. I was recounting the history of TCP/IP port assignments. Bob From touch at ISI.EDU Mon Jan 23 16:13:41 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 23 Jan 2006 16:13:41 -0800 Subject: [ih] History of the TCP/UDP port space In-Reply-To: <200601232311.PAA15200@gra.isi.edu> References: <200601232311.PAA15200@gra.isi.edu> Message-ID: <43D57135.30701@isi.edu> I was treating the concept as a continuum, i.e., that the concept of NCP ports came first and was carried over into TCP/IP. Joe Bob Braden wrote: > Joe, > > I think you are confusing ARPAnet NCP port assignments with TCP/IP > port assignments. The concept was carried over, but the assignment > details were different. I was recounting the history of TCP/IP > port assignments. > > Bob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: From dpreed at reed.com Mon Jan 23 18:51:17 2006 From: dpreed at reed.com (David P. Reed) Date: Mon, 23 Jan 2006 21:51:17 -0500 Subject: [ih] History of the TCP/UDP port space In-Reply-To: <200601171936.LAA12471@gra.isi.edu> References: <200601171936.LAA12471@gra.isi.edu> Message-ID: <43D59625.3060603@reed.com> Looking back in my memory on some non-Unix implementations of early TCP stacks, there were some other inputs that may not have been very clearly documented. In systems that had strong "security" goals, the right to listen on a particular port was handled in different ways. The "Berkeley sockets" interface is now pretty ubiquitous, but prior to that, the OS APIs were not part of the protocol definition. So on Multics and on some other early implementations I remember vaguely, the ability to associate a port number with a process was constrained by some very different APIs - the "bind" call was not standard. I don't have the documents near at hand, but I'd suggest that Ken Pogran (who did an early Multics stack with Doug Wells), Dave Clark (who did a stack on the Xerox Alto), Dave Moon (who helped with a stack, perhaps along with Stallman, Knight, and Greenblatt, for the MIT AI Lab's ITS), and the TENEX stack all had various constraints on the way ports were associated with processes that required dividing up the port address space. There are aspects of the design evolution that had little to do with BSD, which came a lot later. I suspect even the CADR Lisp Machine and the various VAX OS's had non-BSD-style APIs that shaped the requirements on the port space and usage. 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 > >__________________________________________________________________ > >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 > > > > From jnc at mercury.lcs.mit.edu Mon Jan 23 19:13:28 2006 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 23 Jan 2006 22:13:28 -0500 (EST) Subject: [ih] History of the TCP/UDP port space Message-ID: <20060124031328.8CB1F872DA@mercury.lcs.mit.edu> Slightly off-topic, but before some errors get into the record... > From: "David P. Reed" > I'd suggest that Ken Pogran (who did an early Multics stack with Doug > Wells) Umm, maybe it was NCP that Ken worked on? By '77, when I arrived, Ken was working on the LNI. The Multics stack work when I was there was done by Drew Mason (initially), and Dave Clark did a lot of work on it too, before he temporarily left for sabbatical at Cambridge. (Not sure who worked on it after that, I think it got turned into code supported by the MIT IS people - Jeff Schiller would probably remember this better than I.) Doug Wells may have worked on it early on, but he left shortly after I arrived in '77, and I seem to recall he was working on something else (maybe thinking about TCP for PDP-11 Unix, which never happened until much later)? > Dave Clark (who did a stack on the Xerox Alto) That was a port of his BCPL code for Tripos, which he did while at Cambridge. (Those were wierd implementations - I'll leave out the details for now.) > Dave Moon (who helped with a stack, perhaps along with Stallman, > Knight, and Greenblatt, for the MIT AI Lab's ITS) I don't think Moon did one, at least not while he was at MIT. (He may have worked on one at 'Bolics.) The ITS one was done by Ken Herrenstein. I don't know who did the ITS NCP code (perhaps the source says, if anyone really cares :-). > I suspect even the CADR Lisp Machine No, the first TCP for any LispM was done at 'Bolics, long after TCP was finalized. Noel From dpreed at reed.com Mon Jan 23 19:55:50 2006 From: dpreed at reed.com (David P. Reed) Date: Mon, 23 Jan 2006 22:55:50 -0500 Subject: [ih] History of the TCP/UDP port space In-Reply-To: <20060124031328.8CB1F872DA@mercury.lcs.mit.edu> References: <20060124031328.8CB1F872DA@mercury.lcs.mit.edu> Message-ID: <43D5A546.5020503@reed.com> Noel - Thanks for mentioning additional names. You are right - my vague memory of who did what should not be taken as historically valid. I had conversations with these people at the time about the APIs, but I was not closely involved in any of those projects, as I said. I was suggesting who I thought were some of the key contributors to follow up and find the API documentation - not to grant credit... My main point, that the network APIs in these and other non-Unix OS's were far from the now-current Berkeley Unix Sockets API, is what I was trying to get across - these other systems were not at all like Unix in many ways, and they already had "mature" APIs to NCP, which were retained so that apps could be ported forward easily. Berkeley Sockets's centrality came later. Though "Sockets" seems to be a reference implementation for nearly all stacks today, the interfaces were extremely varied in the early days, and the protocol spec avoided spec'ing in terms of an API (some think this a bad idea - but since I/O APIs were quite different from OS to OS then, it was a pragmatic choice). Noel Chiappa wrote: >Slightly off-topic, but before some errors get into the record... > > > From: "David P. Reed" > > > I'd suggest that Ken Pogran (who did an early Multics stack with Doug > > Wells) > >Umm, maybe it was NCP that Ken worked on? By '77, when I arrived, Ken was >working on the LNI. The Multics stack work when I was there was done by Drew >Mason (initially), and Dave Clark did a lot of work on it too, before he >temporarily left for sabbatical at Cambridge. (Not sure who worked on it after >that, I think it got turned into code supported by the MIT IS people - Jeff >Schiller would probably remember this better than I.) Doug Wells may have >worked on it early on, but he left shortly after I arrived in '77, and I seem >to recall he was working on something else (maybe thinking about TCP for >PDP-11 Unix, which never happened until much later)? > > > Dave Clark (who did a stack on the Xerox Alto) > >That was a port of his BCPL code for Tripos, which he did while at Cambridge. >(Those were wierd implementations - I'll leave out the details for now.) > > > Dave Moon (who helped with a stack, perhaps along with Stallman, > > Knight, and Greenblatt, for the MIT AI Lab's ITS) > >I don't think Moon did one, at least not while he was at MIT. (He may have >worked on one at 'Bolics.) The ITS one was done by Ken Herrenstein. I don't >know who did the ITS NCP code (perhaps the source says, if anyone really >cares :-). > > > I suspect even the CADR Lisp Machine > >No, the first TCP for any LispM was done at 'Bolics, long after TCP was >finalized. > > Noel > > > > From jnc at mercury.lcs.mit.edu Tue Jan 24 05:30:27 2006 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 24 Jan 2006 08:30:27 -0500 (EST) Subject: [ih] APIs (was Re: History of the TCP/UDP port space) Message-ID: <20060124133027.BDAD7872E5@mercury.lcs.mit.edu> > From: Dan McDonald > For those of us younger (or only months older) than the ARPAnet and/or > UNIX :-) > do you think we - the audience - could hear about some of these other > API approaches? Well, most of them were pretty vanilla/obvious and/or boring, and I'm not at all sure they are worth the effort to recover from the trash-heap of history.... I no longer recall most of them (not that I was that familiar with them anway, even at the time), no doubt for a good reason! I do recall much of one that I wrote for Bridge/3Com, but other than the use of upcalls (more below), it was relatively uninteresting - just passed all the relevant data (e.g. for passive TCP open, just the local port number, along with a routine to upcall when a connection opened) in the obvious way. There were a number that did have interesting ideas (such as upcalls), and I don't know about all of them, but I do know some of them had papers about them which it ought to be possible to find. > The x-kernel oriented itself around upcalls, citing a Clark paper when > crediting the concept. (My papers are at the office, but is this the > same BCPL stuff you mentioned, Noel?) I don't recall exactly how much the early BCPL versions used upcalls, but yes, it was those implementations (plus, I think, the Multics one) where he developed the concept of upcalls. The other thing that came out of those early implementations (specifically the BCPL one) was some ideas he had about how TCP could be split up, so that the TCP state machine would be (basically) a library, and the buffering would be integrated with the application, to optimize data handling (e.g. minimize the number of copies) - not sure if there was a paper that talked about that. I don't think that idea ever caught on - I know some systems did use a variant of that, where there were multiple TCP implementations, and e.g. the user TELNET used a simple single shift register for the output buffer, because it only had to handle a human typing. Both Dave's original BCPL one, and ones we did at MIT for a PDP-11 Unix (where only the input packet demux was in the kernel) used that concept, so the latter machine actually had two different TCP implementations, one suitable for low-rate applications, and one for high. > What use is history if you can't learn from it? Indeed... :-) Noel From jnc at mercury.lcs.mit.edu Tue Jan 24 05:48:27 2006 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 24 Jan 2006 08:48:27 -0500 (EST) Subject: [ih] History of the TCP/UDP port space Message-ID: <20060124134827.5AAC1872E3@mercury.lcs.mit.edu> > I was suggesting who I thought were some of the key contributors to > follow up and find the API documentation - not to grant credit... Ah, got it. > My main point, that the network APIs in these and other non-Unix OS's > were far from the now-current Berkeley Unix Sockets API > ... > these other systems were not at all like Unix in many ways Yes, indeed - but even in Unix, things looked very different from sockets in the early stages! I got the impression that sockets came about as much because Unix didn't have a really good complex asynchronous data-handling interface model to follow, as for any other reason. I certainly remember that when adding network I/O to V6 Unix, one basically had to start from scratch, because the only data-handling interface model available was file I/O, which was nowhere near rich enough (semantically). For a long time, each Unix networking effort: - the NCP (I forget who did that - U Illinois, I think, maybe?) - the first BBN Unix code (for PDP-11's) - an early PDP-11 Unix done by U Illinois (IIRC - John Day was I think involved in that one) - the MIT PDP-11 Unix effort - the MIT PDP-11 Unix CHAOS protocol implementation, done by the Plasma people, IIRC (for completeness :-) - the second BBN Unix code (for the early Unix VAX versions) was completely standalone, and took little from the prior work, although they mostly looked vaguely similar (except for the MIT one, which was oddball because it only did packet demux in the kernel - although I no longer recall if TCP was in the same process as the application, or whether they were separate processes). But I don't think any looked much like sockets. (I think the MIT stuff may have borrowed some from an earlier RAND [I think?] project which had added generic IPC to Unix - i.e. not simply pipes, with their "common parent" requirement.) I'm not really sure what (if any) the influences on sockets were. I have this vague memory that they looked more like the TWENEX interface than anything else, but that could easily be incorrect... > and they already had "mature" APIs to NCP, which were retained so that > apps could be ported forward easily. Yes - of course, one had to make minor tweaks (e.g. the destination address was different). > the protocol spec avoided spec'ing in terms of an API Well, yes and no. If you read the TCP RFC, there is a pseudo-spec for an interface (IIRC), but it's mostly there to show you what pieces of data you have to pass across interface. > (some think this a bad idea - but since I/O APIs were quite different > from OS to OS then, it was a pragmatic choice). Exactly - that was explicitly the reason no standard API was given. Of course, back then, the whole concept of portability was just coming about - most OS's were still written in machine language, and so were many applications - so there wouldn't have been much point to a standard interface anyway. Noel From touch at ISI.EDU Tue Jan 24 08:04:26 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 24 Jan 2006 08:04:26 -0800 Subject: [ih] History of the TCP/UDP port space In-Reply-To: <6.2.5.6.1.20060123213149.02c96e30@alum.mit.edu> References: <200601232311.PAA15200@gra.isi.edu> <6.2.5.6.1.20060123213149.02c96e30@alum.mit.edu> Message-ID: <43D6500A.2050901@isi.edu> Hi, Mike, Mike Padlipsky wrote: > At 03:11 PM 1/23/2006, Bob Braden wrote: >> Joe, >> >> I think you are confusing ARPAnet NCP port assignments with TCP/IP >> port assignments. > > it's worse than that. > > without prejudice to my views on the subject 'history''s accuracy, or > even comprehensibility, my first reaction to the message this one was > responding to was 'what? we didn't have ports when rfc 33 would have > been written; i'm not even sure we had sockets yet.' > > so i looked at what purports to be a transcription of rfc 33 according > to the first googhit on 'rfc index' and immediately noticed that it had > a 1973 [sic: 3, as in three] publication date, which is absurd. [but > enough other 2-digit rfcs refer to it that i'll take the 3 as a typo for > 0.] sure enough, we had sockets, not ports. The versions on-line appear to have a typo on the first page, indicating 1973 there, but using 1970 for the headings of the remainder and even in a self-referential note on page 17. I'll forward this to the updates to-do list ;-) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: From craig at aland.bbn.com Tue Jan 24 09:02:17 2006 From: craig at aland.bbn.com (Craig Partridge) Date: Tue, 24 Jan 2006 12:02:17 -0500 Subject: [ih] History of the TCP/UDP port space In-Reply-To: Your message of "Tue, 24 Jan 2006 08:48:27 EST." <20060124134827.5AAC1872E3@mercury.lcs.mit.edu> Message-ID: <20060124170217.973EB68@aland.bbn.com> In message <20060124134827.5AAC1872E3 at mercury.lcs.mit.edu>, Noel Chiappa writes : >I'm not really sure what (if any) the influences on sockets were. I have this >vague memory that they looked more like the TWENEX interface than anything >else, but that could easily be incorrect... The VAX BBN implementation used /dev/tcp with ioctls to open sockets (an idea Bell Labs reinvented 10 years or so later). It was also the first implementation to use mbufs. The innards were wildly different from the BSD TCP and, indeed, from the PDP-11 (and TOPS-20) implementations at BBN. Craig From mills at udel.edu Tue Jan 24 11:55:41 2006 From: mills at udel.edu (David L. Mills) Date: Tue, 24 Jan 2006 19:55:41 +0000 Subject: [ih] History of the TCP/UDP port space In-Reply-To: <43D59625.3060603@reed.com> References: <200601171936.LAA12471@gra.isi.edu> <43D59625.3060603@reed.com> Message-ID: <43D6863D.8060506@udel.edu> David, Non-Unix APIs? Redux the Fuzzball. Fuzzballs were PDP11 garages in which to park one or more portable processes implementing the RT-11 virtual machine. Each machine had an IP address; the Hellospeak routing algorithm figured out in which garage they were parked. Each machine had a doorbell process that listened for a packet, looked up the destination port and loaded the designated program, much like inetd does now. The TCP interface included simple open and close and urgent interrupt that actually worked. I don't submit this as novel, just as an historic example of TCP interface. The first use I can document was for the SATNET coming-out party at the 1979 National Computer Conference. Dave David P. Reed wrote: > Looking back in my memory on some non-Unix implementations of early > TCP stacks, there were some other inputs that may not have been very > clearly documented. In systems that had strong "security" goals, the > right to listen on a particular port was handled in different ways. > The "Berkeley sockets" interface is now pretty ubiquitous, but prior > to that, the OS APIs were not part of the protocol definition. So on > Multics and on some other early implementations I remember vaguely, > the ability to associate a port number with a process was constrained > by some very different APIs - the "bind" call was not standard. > > I don't have the documents near at hand, but I'd suggest that Ken > Pogran (who did an early Multics stack with Doug Wells), Dave Clark > (who did a stack on the Xerox Alto), Dave Moon (who helped with a > stack, perhaps along with Stallman, Knight, and Greenblatt, for the > MIT AI Lab's ITS), and the TENEX stack all had various constraints on > the way ports were associated with processes that required dividing up > the port address space. There are aspects of the design evolution > that had little to do with BSD, which came a lot later. > > I suspect even the CADR Lisp Machine and the various VAX OS's had > non-BSD-style APIs that shaped the requirements on the port space and > usage. > > 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 >> >> __________________________________________________________________ >> >> 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 >> >> >> >> From touch at ISI.EDU Tue Jan 24 16:51:56 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 24 Jan 2006 16:51:56 -0800 Subject: [ih] History of the TCP/UDP port space In-Reply-To: <6.2.5.6.1.20060124142530.02c67e18@alum.mit.edu> References: <200601232311.PAA15200@gra.isi.edu> <6.2.5.6.1.20060123213149.02c96e30@alum.mit.edu> <43D6500A.2050901@isi.edu> <6.2.5.6.1.20060124142530.02c67e18@alum.mit.edu> Message-ID: <43D6CBAC.9040706@isi.edu> Mike Padlipsky wrote: > At 08:04 AM 1/24/2006, Joe Touch wrote: >> I'll forward this to the updates >> to-do list ;-) > > is that your delicate way of saying you're not going to 'post' the > message to the list, or did you not notice that it was intended for the > list? I did post that message - and this - to the I-H list. The to-do list is for the RFC-Editor's (abundant) queue ;-) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: From the.map at alum.mit.edu Mon Jan 23 22:53:11 2006 From: the.map at alum.mit.edu (Mike Padlipsky) Date: Mon, 23 Jan 2006 22:53:11 -0800 Subject: [ih] History of the TCP/UDP port space In-Reply-To: <200601232311.PAA15200@gra.isi.edu> References: <200601232311.PAA15200@gra.isi.edu> Message-ID: <6.2.5.6.1.20060123213149.02c96e30@alum.mit.edu> At 03:11 PM 1/23/2006, Bob Braden wrote: >Joe, > >I think you are confusing ARPAnet NCP port assignments with TCP/IP >port assignments. it's worse than that. without prejudice to my views on the subject 'history''s accuracy, or even comprehensibility, my first reaction to the message this one was responding to was 'what? we didn't have ports when rfc 33 would have been written; i'm not even sure we had sockets yet.' so i looked at what purports to be a transcription of rfc 33 according to the first googhit on 'rfc index' and immediately noticed that it had a 1973 [sic: 3, as in three] publication date, which is absurd. [but enough other 2-digit rfcs refer to it that i'll take the 3 as a typo for 0.] sure enough, we had sockets, not ports. the date typo red herring aside, a little skimming [and some firefox-finding] made it clear that rfc 33's use of 'port' was rhetorical, not technical. that is, it couches everything in terms of sockets at the beginning, and uses the term a number of times, then goes on to some meant-to-be useful abstractions about ports later in the document, or perhaps was sneakily trying to get the name changed but that definitely didn't take if it was the intent. 'sockets' was the term of art for years. [it might be the case that 'port' appeared often enough in the later part of the document, which was presumably led to by a search on something like 'rfc ports', that 'socket' didn't get noticed up at the top, i suppose.] it's also worth noting that rfc 33 predated the final form of the arpanet host-host protocol, although it was apparently a fairly major step on the path to the ah-hp. i'm utterly disinclined to dig out the references, especially when i know from personal experience that some references aren't available in the rfc archives, but my memory's pretty clear on the following: the original arpanet host-host protocol [often miscalled ncp, which was really the term supposed to be used for the combination of the host-host and host-imp protocol interpreters in given hosts] used pairs of simplex sockets for processes to communicate over/through, and the underheralded 'initial connection protocol' used 'well-known sockets' to allow a user process to get the number [probably the even number, but who cares] of the base socket of the even-odd pair it would be able to use to 'talk' to the desired server process [telnet = 3, ftp = 23 sounds faintly familiar but is almost certainly wrong]. well-known sockets were the first thousand or so. the rest of the socket world could be used freely by pairs of processes for whatever purpose they 'wanted' [provided, of course, they knew what numbers to use ... which was what the initial connection protocol achieved for telnet, ftp, and some others i can't be bothered to try to remember]. the real point is that when tcp came along, duplex communication paths seemed more sensible, and they were called ports [i suspect after starting out being called sockets as well, but i wasn't going to the tcp design meetings because i wasn't implementing a tcp interpreter, so can't be sure]. the similarities to good old ah-hp socket pairs were pretty striking, tho ... and, of course, telnet and ftp user processes then went off to well-known ports instead of well-known sockets [but since as well as being duplex ports also didn't have to be unique on both ends the initial connection protocol became pretty much moot]. to end on a charming anecnote, what's left of my memory's hazy [and i'm too lazy to refresh it] on the exact 'shape' of socket numbers/identifiers, but i do clearly recall -- and a quick look back at rfc 33 confirms, even tho i'm pretty sure the 'shape' it specifies isn't what eventually was settled on -- that they used to have a final 8-bit field called 'aen', for 'another eight-bit number', and good old ed [or edwin, as he prefers] meyer, who was my officemate at project mac at the time, suggested that the field should be called 'pin' rather than 'aen', since pins and sockets went together. sadly, it doesn't seem to've made it into the literature, and i'm not at all sure that he even proposed it in public, but i'm pretty sure the source code for the multics host-host protocol interpreter went along with the joke [especially since he wrote the initial implementation of it, and his group leader was -- and still is -- inordinately fond of puns]. cheers, map [whose shoulder problems caused him to break down some time ago and create a 'signature' file to apologize for the lack of his formerly customary e-volubility -- and who's been employing shiftless typing for a long time now to spare his wristsnfingers, in case you didn't know ... and who's further broken down and done http://www.lafn.org/~ba213/mapstuff.html , rather grudgingly] -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.map at alum.mit.edu Tue Jan 24 14:27:16 2006 From: the.map at alum.mit.edu (Mike Padlipsky) Date: Tue, 24 Jan 2006 14:27:16 -0800 Subject: [ih] History of the TCP/UDP port space In-Reply-To: <43D6500A.2050901@isi.edu> References: <200601232311.PAA15200@gra.isi.edu> <6.2.5.6.1.20060123213149.02c96e30@alum.mit.edu> <43D6500A.2050901@isi.edu> Message-ID: <6.2.5.6.1.20060124142530.02c67e18@alum.mit.edu> At 08:04 AM 1/24/2006, Joe Touch wrote: >I'll forward this to the updates >to-do list ;-) is that your delicate way of saying you're not going to 'post' the message to the list, or did you not notice that it was intended for the list? cheers, map [whose shoulder problems caused him to break down some time ago and create a 'signature' file to apologize for the lack of his formerly customary e-volubility -- and who's been employing shiftless typing for a long time now to spare his wristsnfingers, in case you didn't know ... and who's further broken down and done http://www.lafn.org/~ba213/mapstuff.html , rather grudgingly] From touch at ISI.EDU Mon Jan 30 11:09:01 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 30 Jan 2006 11:09:01 -0800 Subject: [ih] FYI - call for papers for ACM Anniversary Message-ID: <43DE644D.2000804@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 CALL FOR PAPERS On the occasion of the 60th anniversary of the ACM, the April or May 2007 issue of /Communications of the ACM/ will be devoted to articles on the history of the organization, its activities, and its role in the development of computing. The editors are particularly interested in papers from historians of computing. Articles should be about 3000 words in length and should be submitted to David S. Wise (dswise at cs.indiana.edu) by 16 May 2006. Authors will be notified of a preliminary decision in October 2006 and will have until December 15 to submit a revised version for final consideration. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD3mRNE5f5cImnZrsRAkmYAJ9nlroGuDKZSjgGlNX4OkfPSLy/dQCgt+lh Azk8jx7ig8gDZVMoaBKs4Qg= =oZCT -----END PGP SIGNATURE-----