|
|
ARCHIVE: TCP-IP Distribution List - Archives (1985)
DOCUMENT: TCP-IP Distribution List for July 1985 (198 messages, 63214 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1985/07.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Mon, 1-Jul-85 16:52:54 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: The great leap forward
From: mills@dcn6.arpa Folks, The Internetional Clockwatching Weekend was a mixed bag. I was loaded for bear, with half a dozen radios listening and machines whirring the protocols and data recorders, when the great one-second leap (forward, backward?) ocurred on Sunday evening. NBS radio WWV was buried in static and D-region absorption on all frequencies, but Canadian radio CHU was beeping happily on several frequencies. From the latter, the offset from atomic time (UT0) to navigation time (UT1) was broadcast as -500 milliseconds before the leap and +400 milliseconds afterward. I assume the missing 100 milliseconds was either roundoff error or was dropped in a gateway. Since WWV was unhearable from here at the time, the Backroom WWV radio clock wasn't even aware of the leap until an hour and a half later, when it was heard again and began telling the corrected time. The Pogo WWVB radio clock took over three hours to realize something had changed, presumably due to low signal levels from the Boulder transmitter as received here near Washington, DC. The Ford GOES satellite clock near Detroit apparently had antenna fever, since its quality indicator indicated confidence only to the +-500 millisecond order. Its offset relative to the WWVB radio clock drifted lazily from +60 to -90 millsiseconds over the weekend. I gleefully watched the power grid, which normally wanders +-2000 milliseconds over the 24-hour period, crank in 60 additional cycles of steam so that ordinary synchronous-motor clocks would read correctly (are there any of these left?). One question remains: who paid for the extra steam? I have quite a collection of data, with raw sample offsets recorded every sixteen seconds, formatted ASCII transcriptions, data-reduction programs (in BASIC) and a bunch of graphics plots in gorgeous color for the Peritek (512 x 640) bit-map display. All this stuff is online, if anybody is interested. The results demonstrate that the fuzzballs and DCNet protocols really can synchronize clocks within a residual error of a few milliseconds. They also demonstrate that the Heath WWV radio clock is surprisingly good and easily makes the specifications of +-100 milliseconds in lock. In fact, most of the time it wanders within +-30 milliseconds unsmoothed, even after nearly 24 hours without a radio fix. However, the results also demonstrate a clear lack of functionality in all broadcast formats in that no advance notice is provided for a leap second, even though extra bits are available in the frame. Unless this is done, there is no way a device that must integrate information over several minutes or hours can determine in which minute an epochal event like a leap second occurs. One way to solve this problem, as well as the year ambiguity (the broadcast formats don't provide for this either, but some formats provide for a Daylight-Savings time indicator!), is with a manual command to the radio clock itself, which then hiccups at 23:59:60Z as required. Note that this command must be broadcast everywhere in the net, so that all dependent host clocks hiccup at the same time. Dave -------
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 01-Jul-85 17:24:19-UT From: mills@dcn6.arpa To: tcp-ip@sri-nic.arpa Subject: The great leap forward
Folks, The Internetional Clockwatching Weekend was a mixed bag. I was loaded for bear, with half a dozen radios listening and machines whirring the protocols and data recorders, when the great one-second leap (forward, backward?) ocurred on Sunday evening. NBS radio WWV was buried in static and D-region absorption on all frequencies, but Canadian radio CHU was beeping happily on several frequencies. From the latter, the offset from atomic time (UT0) to navigation time (UT1) was broadcast as -500 milliseconds before the leap and +400 milliseconds afterward. I assume the missing 100 milliseconds was either roundoff error or was dropped in a gateway. Since WWV was unhearable from here at the time, the Backroom WWV radio clock wasn't even aware of the leap until an hour and a half later, when it was heard again and began telling the corrected time. The Pogo WWVB radio clock took over three hours to realize something had changed, presumably due to low signal levels from the Boulder transmitter as received here near Washington, DC. The Ford GOES satellite clock near Detroit apparently had antenna fever, since its quality indicator indicated confidence only to the +-500 millisecond order. Its offset relative to the WWVB radio clock drifted lazily from +60 to -90 millsiseconds over the weekend. I gleefully watched the power grid, which normally wanders +-2000 milliseconds over the 24-hour period, crank in 60 additional cycles of steam so that ordinary synchronous-motor clocks would read correctly (are there any of these left?). One question remains: who paid for the extra steam? I have quite a collection of data, with raw sample offsets recorded every sixteen seconds, formatted ASCII transcriptions, data-reduction programs (in BASIC) and a bunch of graphics plots in gorgeous color for the Peritek (512 x 640) bit-map display. All this stuff is online, if anybody is interested. The results demonstrate that the fuzzballs and DCNet protocols really can synchronize clocks within a residual error of a few milliseconds. They also demonstrate that the Heath WWV radio clock is surprisingly good and easily makes the specifications of +-100 milliseconds in lock. In fact, most of the time it wanders within +-30 milliseconds unsmoothed, even after nearly 24 hours without a radio fix. However, the results also demonstrate a clear lack of functionality in all broadcast formats in that no advance notice is provided for a leap second, even though extra bits are available in the frame. Unless this is done, there is no way a device that must integrate information over several minutes or hours can determine in which minute an epochal event like a leap second occurs. One way to solve this problem, as well as the year ambiguity (the broadcast formats don't provide for this either, but some formats provide for a Daylight-Savings time indicator!), is with a manual command to the radio clock itself, which then hiccups at 23:59:60Z as required. Note that this command must be broadcast everywhere in the net, so that all dependent host clocks hiccup at the same time. Dave -------
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Jul 85 18:18:42 PDT From: sun!l5!gnu@Berkeley (John Gilmore) To: tcp-ip@Berkeley Subject: tftp for bootstrap
Sun would like to use "standard" protocols for diskless bootstrap in new products. We're looking at tftp/rarp/arp as described in RFC 906 and have run into some trouble which I hope the Internet community can shed some light on. How do you put useful information in a name that contains only alphanumeric characters? We'd like to put either the machine's internet address e.g. 192.9.1.23, or its machine type e.g. Sun-2/120, in the name, but these both use punctuation and don't work very well if run-together. It's not clear how many systems will do a tftp file transfer of an unqualified name (without any directory specified) or whether you want to put a set of boot files in the directory it would pick for that case. It's not clear whether upper and/or lower case letters are possible or preferred. [My personal preference would be a SunRPC based boot protocol, but SunRPC has not seen much use in the Internet yet, is not as "standard" as tftp, and would require people to port RPC if they wanted to boot from non-Unix machines. How big a problem are these?] [Note that the protocol and administrative setup required would also be used for booting from Sun servers, thus it must be easy to set up and explain and administer.]
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 1985 16:37-EST From: "Benoy P. De Souza" <benoy%suny-sb.csnet@csnet-relay.ARPA> To: tcp-ip@Berkeley, fa.tcp-ip Subject: Help needed in implementing IP in Modula-2 on 68K network.
Here at SUNY Stony Brook we have a distributed OS running on a network of M68Ks. We call it SAM2S (Stand-Alone-Modula-2-System). The present communication subsytem is based on XNS protocols which does not help when everything else (at least in our LAN) being based on Unix 4.2 speaks TCP/IP. Hence we are working on implementing TCP/IP in our kernel. I have taken up the task of implementing the IP part (and possibly ARP since each of these have Ethernet interfaces). I would appreciate it if anyone could give me any pointers, help, etc. on either IP and/or ARP code which is documented/explained. I am at present going through UNIX 4.2's C code written for the VAX 750/780s. I don't have any documentation (except for the tutorials on IPC from UC Berkeley). Thanks. - Benoy De Souza Computer Science, SUNY Stony Brook, NY 11794 (516)-246-7146 benoy@sbcs.csnet
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Tue, 2-Jul-85 22:53:57 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: tftp for bootstrap
From: sun!l5!gnu@BERKELEY (John Gilmore) Sun would like to use "standard" protocols for diskless bootstrap in new products. We're looking at tftp/rarp/arp as described in RFC 906 and have run into some trouble which I hope the Internet community can shed some light on. How do you put useful information in a name that contains only alphanumeric characters? We'd like to put either the machine's internet address e.g. 192.9.1.23, or its machine type e.g. Sun-2/120, in the name, but these both use punctuation and don't work very well if run-together. It's not clear how many systems will do a tftp file transfer of an unqualified name (without any directory specified) or whether you want to put a set of boot files in the directory it would pick for that case. It's not clear whether upper and/or lower case letters are possible or preferred. [My personal preference would be a SunRPC based boot protocol, but SunRPC has not seen much use in the Internet yet, is not as "standard" as tftp, and would require people to port RPC if they wanted to boot from non-Unix machines. How big a problem are these?] [Note that the protocol and administrative setup required would also be used for booting from Sun servers, thus it must be easy to set up and explain and administer.]
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Wed 3 Jul 85 01:16:57-EDT From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA> To: sun!l5!gnu@Berkeley, tcp-ip@Berkeley Cc: JNC@MIT-XX.ARPA Subject: Re: tftp for bootstrap
MIT has used TFTP to boot diskless gateways for about 5 years now. It works quite well. We really like TFTP since it is a standard IP protocol and machines usually come with server TFTP implementations. We handle the 'punctuation characters' problem by using a file name that consists of the IP address with all the fields three characters long; thus, a gateway at 18.10.0.11 would boot from a file named '018010000011'. (Actually, we use octal because we are wierd, but you get the idea). In general, we use built in configuration information, kept in some non-volatile storage. While you can avoid this on an Ethernet with broadcast, this method does not work on non-broadcast nets. In general, the spirit of IP is that the 'base solution' to any problem should work on a non-broadcast net with no gateways. We thus feel that having some small non-volatile store for information such as which directories to look in on which hosts is reasonable. Noel -------
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Wed, 3-Jul-85 02:13:04 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: tftp for bootstrap
From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA> MIT has used TFTP to boot diskless gateways for about 5 years now. It works quite well. We really like TFTP since it is a standard IP protocol and machines usually come with server TFTP implementations. We handle the 'punctuation characters' problem by using a file name that consists of the IP address with all the fields three characters long; thus, a gateway at 18.10.0.11 would boot from a file named '018010000011'. (Actually, we use octal because we are wierd, but you get the idea). In general, we use built in configuration information, kept in some non-volatile storage. While you can avoid this on an Ethernet with broadcast, this method does not work on non-broadcast nets. In general, the spirit of IP is that the 'base solution' to any problem should work on a non-broadcast net with no gateways. We thus feel that having some small non-volatile store for information such as which directories to look in on which hosts is reasonable. Noel -------
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Wed, 3-Jul-85 07:01:35 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Help needed in implementing IP in Modula-2 on 68K network.
From: "Benoy P. De Souza" <benoy%suny-sb.csnet@csnet-relay.ARPA> Here at SUNY Stony Brook we have a distributed OS running on a network of M68Ks. We call it SAM2S (Stand-Alone-Modula-2-System). The present communication subsytem is based on XNS protocols which does not help when everything else (at least in our LAN) being based on Unix 4.2 speaks TCP/IP. Hence we are working on implementing TCP/IP in our kernel. I have taken up the task of implementing the IP part (and possibly ARP since each of these have Ethernet interfaces). I would appreciate it if anyone could give me any pointers, help, etc. on either IP and/or ARP code which is documented/explained. I am at present going through UNIX 4.2's C code written for the VAX 750/780s. I don't have any documentation (except for the tutorials on IPC from UC Berkeley). Thanks. - Benoy De Souza Computer Science, SUNY Stony Brook, NY 11794 (516)-246-7146 benoy@sbcs.csnet
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Wed 3 Jul 85 10:35:02-PDT From: LYNCH@SRI-KL.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: MAP Protocol
I see that Boeing is going to have a demonstration of interconnecting the 802.4 LAN protocls with the 802.3 LAN protocols in November at the Automotive factory automation show. How does one find out what MAP is? GM is making a big fuss (as did DoD) about being able to interconnect products they buy. It sure was nice of them to dream up a different set of protocols... Guess I'd better learn about them. So, the question is: where does one get the info? Thanks, Dan -------
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 1985 11:55:06 PDT From: POSTEL@USC-ISIF.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: IP/TCP Protocol Specifications
Folks: The protocol specifications for the IP/TCP family of protocols are in the Internet Protocol Transition Workbook, the Internet Protocol Implementation Guide, the Internet Protocol Telnet Protocol and Options, and the Internet Mail Protocols volumes. These volumes contain most of the protocols used in the ARPA-Internet community. The Assigned Numbers (RFC-943) and Official Protocols (RFC-944) notes provide a index and annotated index to the protocols. All these above are available from the Network Information Center (send a note to NIC@SRI-NIC.ARPA). Several of the Internet Protocol documents have now been issued as military standards (MIL-STDs). The MIL-STDs listed below are the official DoD versions of these commmunication protocols and should be consulted for any DoD implementations. Internet Protocol (IP) MIL-STD-1777 Transmission Control Protocol (TCP) MIL-STD-1778 File Transfer Protocol (FTP) MIL-STD-1780 Simple Mail Transfer Protocol (SMTP) MIL-STD-1781 Telnet Protocol and Options (TELNET) MIL-STD-1782 These documents may be ordered from: Naval Publications and Forms Center, Code 3015 5801 Tabor Ave Philadelphia, PA 19120 1-215-697-3321 Requests can be initiated by telephone, telegraph, or mail; however, it is preferred that private industry use form DD1425, if possible. The ARPA specifications for IP (RFC-791) and TCP (RFC-793) and the DoD specifications above are intended to describe exactly the same protocols. Any difference in the protocols specified by these sets of documents should be reported to DCA and to ARPA. The RFCs and the MIL-STDs for IP and TCP differ in style and level of detail. It is strongly advised that the two sets of documents be used together. The ARPA and the DoD specifications for the FTP, SMTP, and Telnet protocols are essentially the same documents (RFCs 765, 821, 854). The MIL-STD versions have been edited slightly. Implementers should also check the "Official Protocols" memo for comments on protocol status or pending changes (RFC 944). --jon. -------
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 1985 1548-PDT (Wednesday) From: Jeff Mogul <mogul@Navajo> To: tcp-ip@sri-nic.ARPA Cc: sun!l5!gnu@Berkeley (John Gilmore) Subject: Re: tftp for bootstrap
One thing you might want to consider is a multi-stage bootstrap, where TFTP is used to load a small program that then determines (via NFS or whatever you prefer) what the host's configuration should be. For example, we have Suns here that run the V-system (instead of Sun Unix.) They load a short program called Vload, using whatever protocol Suns bootload with. Vload then reads a configuration file (located using the hardware ethernet address as an identifier) which says what programs should really be loaded. Vload uses the V protocols (which is unfortunate but that's another story) to read the config file and load the real program; all that is needed from the original bootstrap protocol is the ability to load the second-phase bootstrap program. The point here is that the non-volatile storage need not reside on the workstation or whatever; as long as the first-phase boot program can find a database on some server, either by broadcast or by wiring the server address into the code, the rest is just a matter of chasing pointers. I think TFTP is preferable to ND or NFS or FTP or whatever because it's extremely simple, which is important when it has to be squeezed into a ROM, and because it's widely available, unlike certain manufacturers' proprietary protocols. If you only care about loading Suns as Suns, then using NFS might make sense because of efficiency or convenience; if you care about loading a variety of hosts with a variety of operating systems, then TFTP makes more sense because it's simpler and more available. As to the problem of default directories: perhaps what we need is to separate the TFTP protocol from the intended use. TFTP is currently expected to listen on port 69, but there is no reason why a TFTP-based boot server couldn't listen on some other port; the port-69 server would not need a default directory, while the behaviour of the port-XX server would be defined so that alphanumeri-only file names would refer to a default directory. Alternatively (this is what our pseudo-ND server does), the TFTP-boot server might be allowed to look at the requesting host address to look up in a database which file to download.
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Wed, 3 Jul 85 15:07:26 EDT From: jas@proteon.arpa To: sun!l5!gnu@Berkeley (John Gilmore) Cc: tcp-ip@sri-nic.arpa Subject: Re: tftp for bootstrap
I'd agree with Noel about the need to some small EAROM or such for the configuration data. You might consider using the domain nameserver protocols to get additional information beyond that in the EAROM. (I don't love these protocols, but I guess there here for good now...) The HINFO record has the CPU type and O/S. You might invent a new record type for booting information. (Sometimes is it better to tweak an existing protocl a little than develop a new one.) Of course, this requires keeping the address of a domain nameserver in EAROM. My TFTP does have a default directory, but I suspect that this is very rare. Most need fully qualified names. I suspect that servers are case sensitive if the O/S behind them is, otherwise not. I suspect the hard facts of life would point at some amount of data being kept in EAROM (or EPROM). Once you surrender this point, the rest gets rather easy. -------
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Wed, 3-Jul-85 15:28:48 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: MAP Protocol
From: LYNCH@SRI-KL.ARPA I see that Boeing is going to have a demonstration of interconnecting the 802.4 LAN protocls with the 802.3 LAN protocols in November at the Automotive factory automation show. How does one find out what MAP is? GM is making a big fuss (as did DoD) about being able to interconnect products they buy. It sure was nice of them to dream up a different set of protocols... Guess I'd better learn about them. So, the question is: where does one get the info? Thanks, Dan -------
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Wed, 3 Jul 85 16:27:32 EDT From: Jim Berets <jberets@BBN-VAX.ARPA> To: LYNCH@SRI-KL.ARPA Cc: tcp-ip@SRI-NIC.ARPA, jberets@BBN-VAX.ARPA Subject: Re: MAP Protocol
"The Manufacturing Automation Protocol document is based on existing and proposed national standards for Local Area Networks. [The] document has been and will continue to be updated as new national standards are approved." -- from MAP documentation foreword For information on MAP (Manufacturing Automation Protocol), trying writing to: MAP Chairman General Motors Technical Center Manufacturing Building, A/MD-39 30300 Mound Road Warren, MI 48090-9040 Jim jberets@bbn-vax.arpa
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Wed, 3-Jul-85 16:37:40 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: IP/TCP Protocol Specifications
From: POSTEL@USC-ISIF.ARPA Folks: The protocol specifications for the IP/TCP family of protocols are in the Internet Protocol Transition Workbook, the Internet Protocol Implementation Guide, the Internet Protocol Telnet Protocol and Options, and the Internet Mail Protocols volumes. These volumes contain most of the protocols used in the ARPA-Internet community. The Assigned Numbers (RFC-943) and Official Protocols (RFC-944) notes provide a index and annotated index to the protocols. All these above are available from the Network Information Center (send a note to NIC@SRI-NIC.ARPA). Several of the Internet Protocol documents have now been issued as military standards (MIL-STDs). The MIL-STDs listed below are the official DoD versions of these commmunication protocols and should be consulted for any DoD implementations. Internet Protocol (IP) MIL-STD-1777 Transmission Control Protocol (TCP) MIL-STD-1778 File Transfer Protocol (FTP) MIL-STD-1780 Simple Mail Transfer Protocol (SMTP) MIL-STD-1781 Telnet Protocol and Options (TELNET) MIL-STD-1782 These documents may be ordered from: Naval Publications and Forms Center, Code 3015 5801 Tabor Ave Philadelphia, PA 19120 1-215-697-3321 Requests can be initiated by telephone, telegraph, or mail; however, it is preferred that private industry use form DD1425, if possible. The ARPA specifications for IP (RFC-791) and TCP (RFC-793) and the DoD specifications above are intended to describe exactly the same protocols. Any difference in the protocols specified by these sets of documents should be reported to DCA and to ARPA. The RFCs and the MIL-STDs for IP and TCP differ in style and level of detail. It is strongly advised that the two sets of documents be used together. The ARPA and the DoD specifications for the FTP, SMTP, and Telnet protocols are essentially the same documents (RFCs 765, 821, 854). The MIL-STD versions have been edited slightly. Implementers should also check the "Official Protocols" memo for comments on protocol status or pending changes (RFC 944). --jon. -------
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Wed, 3-Jul-85 17:46:42 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: tftp for bootstrap
From: jas@proteon.arpa I'd agree with Noel about the need to some small EAROM or such for the configuration data. You might consider using the domain nameserver protocols to get additional information beyond that in the EAROM. (I don't love these protocols, but I guess there here for good now...) The HINFO record has the CPU type and O/S. You might invent a new record type for booting information. (Sometimes is it better to tweak an existing protocl a little than develop a new one.) Of course, this requires keeping the address of a domain nameserver in EAROM. My TFTP does have a default directory, but I suspect that this is very rare. Most need fully qualified names. I suspect that servers are case sensitive if the O/S behind them is, otherwise not. I suspect the hard facts of life would point at some amount of data being kept in EAROM (or EPROM). Once you surrender this point, the rest gets rather easy. -------
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Wed, 3-Jul-85 18:47:59 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: MAP Protocol
From: Jim Berets <jberets@BBN-VAX.ARPA> "The Manufacturing Automation Protocol document is based on existing and proposed national standards for Local Area Networks. [The] document has been and will continue to be updated as new national standards are approved." -- from MAP documentation foreword For information on MAP (Manufacturing Automation Protocol), trying writing to: MAP Chairman General Motors Technical Center Manufacturing Building, A/MD-39 30300 Mound Road Warren, MI 48090-9040 Jim jberets@bbn-vax.arpa
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Wed, 3-Jul-85 21:26:21 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: tftp for bootstrap
From: Jeff Mogul <mogul@Navajo> One thing you might want to consider is a multi-stage bootstrap, where TFTP is used to load a small program that then determines (via NFS or whatever you prefer) what the host's configuration should be. For example, we have Suns here that run the V-system (instead of Sun Unix.) They load a short program called Vload, using whatever protocol Suns bootload with. Vload then reads a configuration file (located using the hardware ethernet address as an identifier) which says what programs should really be loaded. Vload uses the V protocols (which is unfortunate but that's another story) to read the config file and load the real program; all that is needed from the original bootstrap protocol is the ability to load the second-phase bootstrap program. The point here is that the non-volatile storage need not reside on the workstation or whatever; as long as the first-phase boot program can find a database on some server, either by broadcast or by wiring the server address into the code, the rest is just a matter of chasing pointers. I think TFTP is preferable to ND or NFS or FTP or whatever because it's extremely simple, which is important when it has to be squeezed into a ROM, and because it's widely available, unlike certain manufacturers' proprietary protocols. If you only care about loading Suns as Suns, then using NFS might make sense because of efficiency or convenience; if you care about loading a variety of hosts with a variety of operating systems, then TFTP makes more sense because it's simpler and more available. As to the problem of default directories: perhaps what we need is to separate the TFTP protocol from the intended use. TFTP is currently expected to listen on port 69, but there is no reason why a TFTP-based boot server couldn't listen on some other port; the port-69 server would not need a default directory, while the behaviour of the port-XX server would be defined so that alphanumeri-only file names would refer to a default directory. Alternatively (this is what our pseudo-ND server does), the TFTP-boot server might be allowed to look at the requesting host address to look up in a database which file to download.
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 1985 0925-PDT (Friday) From: lewis <lewis@sri-tsc> To: Jeff Mogul <mogul@Navajo> Cc: sun!l5!gnu@Berkeley (John Gilmore), tcp-ip@sri-nic.ARPA Subject: Re: tftp for bootstrap
We have been using a loader server for several years to load TIUs, BBN and Jeff Mogul also use versions of it to load GWYs. In our user testbeds, the same physical hardware is a multifunction box, depending on which module is loaded. We have found that the users often complained that the server was down, when in fact they specified improper file name syntax. This caused us to come up with two changes. There is a data base on the server hosts, which maps requestor's internet IDs to load file names (TOPS20 or Unix pathnames, depending on server). Wildcards in the database for Internet IDs exist to shorten the list. A default load then retrieves the file found in the database. In addition, Internet IDs with or without wildcards can be paired with another database file name, allowing separation of database administration for different hosts and ranges of hosts. Alternatively, the user can specify a file name to be loaded from the server. The first change involves finding the file to boot. If the user specifies any file, the database is not queried. To make it easier for the user to remember how to specify file names, we now allow suffixes to be left off and uppercase is converted to lower, and preceding blanks ( MYLOAD is myload.ext). In this case the default directory is searched. If the file name requested begins with a system directory delimiter, "<" on TOPS20 or "/" on Unix, the server takes the request literally, for people who supposedly know what they want. The second change, not implemented yet, is to return a text string to indicate the status. Currently, if the file is not found, the only perception the user has is the three minute timeout. The string packet should probably be allowed asynchronously with loading progress. It could report (file not found / illegal file name / file broken / etc.). The servee code resides in about 6K bytes nonvolatile memory, and the internet address is used as the database key for default booting. Probably some mechanism for privacy/accounting should be considered. -Mark Lewis
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 05 Jul 85 10:05:51 EDT (Fri) From: Dennis Rockwell <drockwel@CSNET-SH.ARPA> To: tcp-ip@SRI-NIC.ARPA, xni-list@CSNET-RELAY.ARPA, gateway@BBNCCM.ARPA Cc: cic@CSNET-SH.ARPA Subject: gateway confusion
Folks, If your connections to hosts on CSNET-PDN seem a bit strained this week, here's why: the core gateways are confused about it, and will point you in the wrong direction, then tell you that you can't get there from here. If you are on the ARPAnet, please tell your host to get to 192.5.58 though 10.4.0.5. If not, or if you cannot change your routing tables, please send mail through csnet-relay using either <@csnet-relay.arpa:dbj@rice.arpa> or dbj%rice@csnet-relay.arpa (to use a prime victim as an example). To the XNI people: please route your outgoing mail through csnet-relay for the duration (ie, tcp-ip%nic@csnet-relay). The gateway team is working on it, after being dragged unceremoniously out of bed (this is a BBN holiday; I'm only here myself because of this). Dennis Rockwell CSNET Technical Staff PS: the really bizarre thing is that RICE-NET is perfectly reachable; both RICE-NET and CSNET-PDN are advertised by Paul Kirton's EGP running on CSNET-RELAY.
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 85 10:27 EDT From: dca-pgs @ DDN1.ARPA To: LYNCH @ sri-kl.arpa Cc: tcp-ip @ sri-nic.arpa Subject: Re: MAP Protocol
I heard that Unisoft was working on the NBS Transport Protocol, to run under 4.2. I don't recall whether they were involved in last year's NCC demo or not. Last handle I have for Unisoft is <unisoft!unisoft@Berkeley>; also, they are located in Berkeley CA if anyone wants to call them. Anybody know if Wollongong is doing anything in this area? Best, -Pat Sullivan DCEC, Reston, VA.
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 85 10:37 EDT From: dca-pgs @ DDN1.ARPA To: tcp-ip @ sri-nic.arpa, info-unix @ brl.arpa, telecom @ bbncca.arpa Subject: $946M NSA/AT&T Contract for 3BXX's
News of this came out in this week's MIS Week. Anybody have a clue on what kind of networking (if any) was specified for these 3B's? AT&T's attitude towards TCP/IP et al has been somewhat unclear, but for a billion- dollar contract, I'm sure they could do a lot of adapting. Thanks, Pat Sullivan DCEC, Reston, VA.
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Fri, 5-Jul-85 11:08:13 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: gateway confusion
From: Dennis Rockwell <drockwel@CSNET-SH.ARPA> Folks, If your connections to hosts on CSNET-PDN seem a bit strained this week, here's why: the core gateways are confused about it, and will point you in the wrong direction, then tell you that you can't get there from here. If you are on the ARPAnet, please tell your host to get to 192.5.58 though 10.4.0.5. If not, or if you cannot change your routing tables, please send mail through csnet-relay using either <@csnet-relay.arpa:dbj@rice.arpa> or dbj%rice@csnet-relay.arpa (to use a prime victim as an example). To the XNI people: please route your outgoing mail through csnet-relay for the duration (ie, tcp-ip%nic@csnet-relay). The gateway team is working on it, after being dragged unceremoniously out of bed (this is a BBN holiday; I'm only here myself because of this). Dennis Rockwell CSNET Technical Staff PS: the really bizarre thing is that RICE-NET is perfectly reachable; both RICE-NET and CSNET-PDN are advertised by Paul Kirton's EGP running on CSNET-RELAY.
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Fri, 5-Jul-85 11:53:00 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: MAP Protocol
From: dca-pgs@DDN1.ARPA I heard that Unisoft was working on the NBS Transport Protocol, to run under 4.2. I don't recall whether they were involved in last year's NCC demo or not. Last handle I have for Unisoft is <unisoft!unisoft@Berkeley>; also, they are located in Berkeley CA if anyone wants to call them. Anybody know if Wollongong is doing anything in this area? Best, -Pat Sullivan DCEC, Reston, VA.
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Fri, 5-Jul-85 12:34:58 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: 46M NSA/AT&T Contract for 3BXX's
From: dca-pgs@DDN1.ARPA News of this came out in this week's MIS Week. Anybody have a clue on what kind of networking (if any) was specified for these 3B's? AT&T's attitude towards TCP/IP et al has been somewhat unclear, but for a billion- dollar contract, I'm sure they could do a lot of adapting. Thanks, Pat Sullivan DCEC, Reston, VA.
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Fri 5 Jul 85 12:46:35-EDT From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA> To: lewis@SRI-TSC.ARPA, mogul@SU-NAVAJO.ARPA Cc: sun!l5!gnu@UCB-VAX.ARPA, tcp-ip@SRI-NIC.ARPA, JNC@MIT-XX.ARPA Subject: Re: tftp for bootstrap
You mentioned the lack of error messages; TFTP already provides them, and the bootstrap we run prints them. -------
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Fri, 5-Jul-85 13:15:26 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: tftp for bootstrap
From: lewis <lewis@sri-tsc> We have been using a loader server for several years to load TIUs, BBN and Jeff Mogul also use versions of it to load GWYs. In our user testbeds, the same physical hardware is a multifunction box, depending on which module is loaded. We have found that the users often complained that the server was down, when in fact they specified improper file name syntax. This caused us to come up with two changes. There is a data base on the server hosts, which maps requestor's internet IDs to load file names (TOPS20 or Unix pathnames, depending on server). Wildcards in the database for Internet IDs exist to shorten the list. A default load then retrieves the file found in the database. In addition, Internet IDs with or without wildcards can be paired with another database file name, allowing separation of database administration for different hosts and ranges of hosts. Alternatively, the user can specify a file name to be loaded from the server. The first change involves finding the file to boot. If the user specifies any file, the database is not queried. To make it easier for the user to remember how to specify file names, we now allow suffixes to be left off and uppercase is converted to lower, and preceding blanks ( MYLOAD is myload.ext). In this case the default directory is searched. If the file name requested begins with a system directory delimiter, "<" on TOPS20 or "/" on Unix, the server takes the request literally, for people who supposedly know what they want. The second change, not implemented yet, is to return a text string to indicate the status. Currently, if the file is not found, the only perception the user has is the three minute timeout. The string packet should probably be allowed asynchronously with loading progress. It could report (file not found / illegal file name / file broken / etc.). The servee code resides in about 6K bytes nonvolatile memory, and the internet address is used as the database key for default booting. Probably some mechanism for privacy/accounting should be considered. -Mark Lewis
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Fri, 5-Jul-85 14:01:07 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: tftp for bootstrap
From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA> You mentioned the lack of error messages; TFTP already provides them, and the bootstrap we run prints them. -------
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Fri, 5 Jul 85 21:36:33 EDT From: Ron Natalie <ron@BRL.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: ALMOST PUBLIC DOMAIN GATEWAY CODE
The BRL gateway code and it's related operating system LOS is available for public FTP in the file arch/gw.tar on BRL-VGR. This code is restricted as government-owned. Which means you can use it, spread it around, etc..., but when it comes to charging money for it, there are some restrictions. If anybody cares to know, send me a note. The BRL gateway is a full IP gateway, supporting fragmentation, and all IP options (such as they are). It will run on any PDP-11 with memory management. We have sucessfully run it on PDP-11/34's and 11/70's as well as LSI-11/23's. Interfaces currently supported are IMPs on class A or B networks, Ethernet with ARP using the Interlan boards, Proteon V2LNI, DEC PCL-11B, and NSC Hyperchannel. A rather customized EGP exists to conform the idiosyncracies of the core gateway system. Current shortcomings are: 1. Only one ETHERNET can currently be supported at a time. 2. No ICMP timestamp support. 3. Does not send ICMP redirects. 4. Device drivers do not currently turn of routes for dead devices. 5. Documentation is sketchy, but is being revised. 6. Currently requires some media to boot off of (like floppies or RK05's). I'd be willing to take back any bug fixes and/or (cough) enhancements, provided that I could impose the same distribution requirements on them as the rest of the code. C'mon take that load off your VAX and Hack Away -Ron
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Fri, 5-Jul-85 22:20:39 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: ALMOST PUBLIC DOMAIN GATEWAY CODE
From: Ron Natalie <ron@BRL.ARPA> The BRL gateway code and it's related operating system LOS is available for public FTP in the file arch/gw.tar on BRL-VGR. This code is restricted as government-owned. Which means you can use it, spread it around, etc..., but when it comes to charging money for it, there are some restrictions. If anybody cares to know, send me a note. The BRL gateway is a full IP gateway, supporting fragmentation, and all IP options (such as they are). It will run on any PDP-11 with memory management. We have sucessfully run it on PDP-11/34's and 11/70's as well as LSI-11/23's. Interfaces currently supported are IMPs on class A or B networks, Ethernet with ARP using the Interlan boards, Proteon V2LNI, DEC PCL-11B, and NSC Hyperchannel. A rather customized EGP exists to conform the idiosyncracies of the core gateway system. Current shortcomings are: 1. Only one ETHERNET can currently be supported at a time. 2. No ICMP timestamp support. 3. Does not send ICMP redirects. 4. Device drivers do not currently turn of routes for dead devices. 5. Documentation is sketchy, but is being revised. 6. Currently requires some media to boot off of (like floppies or RK05's). I'd be willing to take back any bug fixes and/or (cough) enhancements, provided that I could impose the same distribution requirements on them as the rest of the code. C'mon take that load off your VAX and Hack Away -Ron
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Sat, 6 Jul 85 17:25:04 edt From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa> To: dca-pgs@DDN1.ARPA, info-unix@BRL.ARPA, tcp-ip@SRI-NIC.ARPA, telecom@BBNCCA.ARPA Subject: Re: $946M NSA/AT&T Contract for 3BXX's
Here's a note (in full) that I just sent out to INFO-3B which may shed some light on all this: --------------- THE WOLLONGONG GROUP NEWS BUREAU (i guess now that UPI is in trouble...:-) For Immediate release (05/03/85) WOLLONGONG SIGNS AGREEMENT WITH AT&T PALO ALTO, Calif. -- To expand communications through AT&T computers, The Wollongong Group and AT&T have signed an agreement under which Wollongong will provide its standard networking product for 3B supermicro and supermini computer under UNIX System V. "Wollongong's software products will have the required Department of Defense standard interface services for 3B users," said David J. Preston, director of marketing and sales for Wollongong. Among capabilities to be provided are: --File transfer (FTP) --Electronic mail (SMTP) --Virtual terminal (TELNET). "As a result, 3B users will be able to communicate over a multitude of networks," said Preston, including Ethernet (trademarked by Xerox Corporation), ARPANET, MILNET, the defense Data Network, point-to-point nets, and custom-designed networking systems. "Delivering this advanced standard of networking software to the UNIX System marketplace is an important step in AT&T's program to become a significant industry supplier of high-quality, state-of-the-art computing and communication systems," stated JoAnne Miller, product manager of 3B Networking Software. " This product family is another step in AT&T's overall strategy of continuing to provide and support system capabilities with the special advantage of adherence to current software standards," Miller continued. # # # In what I am sure is a completely unrelated article from today's WSJ (7/1) page 6 col 6: AT&T CONTRACT WITH U.S. INCLUDES SOFTWARE WORK NEW YORK - American Telephone & Telegraph Co.'s new computer contract with the Defense Department's National Security Agency is broader than previously announced. Government officials and sources close to the bidding said the agreement includes software development and sales of computer networks and accessories. Earlier, the agency's officials said the contract, valued at as much as $946 million through 1988, covered mainly sales and service of as many as 250 minicomputers of AT&T's 3B line, introduced last year. An NSA spokesman said the intelligence agency increased its estimate of how many minicomputers it will buy under the contract to as many as 325. The spokesman said final bidding was between AT&T and Digital Equipment Corp. Sources said the decision was based more on technical considerations than on cost. International Business Machines Corp. was eliminated earlier, a source said. (that's all of it, Yow, my fingers hurt) -Barry Shein, Boston University
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Sat, 6-Jul-85 21:49:59 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: 46M NSA/AT&T Contract for 3BXX's
From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa> Here's a note (in full) that I just sent out to INFO-3B which may shed some light on all this: --------------- THE WOLLONGONG GROUP NEWS BUREAU (i guess now that UPI is in trouble...:-) For Immediate release (05/03/85) WOLLONGONG SIGNS AGREEMENT WITH AT&T PALO ALTO, Calif. -- To expand communications through AT&T computers, The Wollongong Group and AT&T have signed an agreement under which Wollongong will provide its standard networking product for 3B supermicro and supermini computer under UNIX System V. "Wollongong's software products will have the required Department of Defense standard interface services for 3B users," said David J. Preston, director of marketing and sales for Wollongong. Among capabilities to be provided are: --File transfer (FTP) --Electronic mail (SMTP) --Virtual terminal (TELNET). "As a result, 3B users will be able to communicate over a multitude of networks," said Preston, including Ethernet (trademarked by Xerox Corporation), ARPANET, MILNET, the defense Data Network, point-to-point nets, and custom-designed networking systems. "Delivering this advanced standard of networking software to the UNIX System marketplace is an important step in AT&T's program to become a significant industry supplier of high-quality, state-of-the-art computing and communication systems," stated JoAnne Miller, product manager of 3B Networking Software. " This product family is another step in AT&T's overall strategy of continuing to provide and support system capabilities with the special advantage of adherence to current software standards," Miller continued. # # # In what I am sure is a completely unrelated article from today's WSJ (7/1) page 6 col 6: AT&T CONTRACT WITH U.S. INCLUDES SOFTWARE WORK NEW YORK - American Telephone & Telegraph Co.'s new computer contract with the Defense Department's National Security Agency is broader than previously announced. Government officials and sources close to the bidding said the agreement includes software development and sales of computer networks and accessories. Earlier, the agency's officials said the contract, valued at as much as $946 million through 1988, covered mainly sales and service of as many as 250 minicomputers of AT&T's 3B line, introduced last year. An NSA spokesman said the intelligence agency increased its estimate of how many minicomputers it will buy under the contract to as many as 325. The spokesman said final bidding was between AT&T and Digital Equipment Corp. Sources said the decision was based more on technical considerations than on cost. International Business Machines Corp. was eliminated earlier, a source said. (that's all of it, Yow, my fingers hurt) -Barry Shein, Boston University
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Sat, 6-Jul-85 21:49:59 EDT From: ihnp4!ihnp1!packard!Postmaster@Berkeley (Mail Delivery Subsystem) To: ihnp4!ucbvax!tcp-ip@Berkeley, Postmaster@Berkeley Subject: Returned mail: User unknown
----- Transcript of session follows ----- Postmaster... aliased to ggr ggr... aliased to nomad!ggr ihnp1!archimedes,ihnp1!unicorn... Connecting to ihnp1.dk... 220 ihnp1.ATT.UUCP Sendmail 4.12/9-Jan-85 ready at 9 Jul 85 10:17:30 CDT (Tue) >>> HELO py/garage/packard.DK 250 ihnp1.ATT.UUCP Hello py/garage/packard.DK, pleased to meet you >>> MAIL From:<packard!ihnp4!ucbvax!tcp-ip> 250 <packard!ihnp4!ucbvax!tcp-ip>... Sender ok >>> RCPT To:<unicorn> 550 /usr/lib/uucp/mail/unicorn... Can't create output: Permission denied ihnp1!unicorn... User unknown >>> RCPT To:<archimedes> 550 /usr/lib/uucp/mail/archimedes... Can't create output: Permission denied ihnp1!archimedes... User unknown >>> QUIT 221 ihnp1.ATT.UUCP closing connection packard!ihnp1!ihnp4!ucbvax!tcp-ip... duplicate suppressed ----- Unsent message follows ----- Date: Sat, 6-Jul-85 21:49:59 EDT From: ucbvax.ARPA!tcp-ip Subject: Re: 46M NSA/AT&T Contract for 3BXX's Message-Id: <8837@ucbvax.ARPA> Received: by py/garage/packard.DK; 8507091519 Errors-To: Postmaster Sender: ihnp4!ucbvax!tcp-ip Newsgroups: fa.tcp-ip Organization: University of California at Berkeley Apparently-To: ihnp1!unicorn Apparently-To: ihnp1!archimedes From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa> Here's a note (in full) that I just sent out to INFO-3B which may shed some light on all this: --------------- THE WOLLONGONG GROUP NEWS BUREAU (i guess now that UPI is in trouble...:-) For Immediate release (05/03/85) WOLLONGONG SIGNS AGREEMENT WITH AT&T PALO ALTO, Calif. -- To expand communications through AT&T computers, The Wollongong Group and AT&T have signed an agreement under which Wollongong will provide its standard networking product for 3B supermicro and supermini computer under UNIX System V. "Wollongong's software products will have the required Department of Defense standard interface services for 3B users," said David J. Preston, director of marketing and sales for Wollongong. Among capabilities to be provided are: --File transfer (FTP) --Electronic mail (SMTP) --Virtual terminal (TELNET). "As a result, 3B users will be able to communicate over a multitude of networks," said Preston, including Ethernet (trademarked by Xerox Corporation), ARPANET, MILNET, the defense Data Network, point-to-point nets, and custom-designed networking systems. "Delivering this advanced standard of networking software to the UNIX System marketplace is an important step in AT&T's program to become a significant industry supplier of high-quality, state-of-the-art computing and communication systems," stated JoAnne Miller, product manager of 3B Networking Software. " This product family is another step in AT&T's overall strategy of continuing to provide and support system capabilities with the special advantage of adherence to current software standards," Miller continued. # # # In what I am sure is a completely unrelated article from today's WSJ (7/1) page 6 col 6: AT&T CONTRACT WITH U.S. INCLUDES SOFTWARE WORK NEW YORK - American Telephone & Telegraph Co.'s new computer contract with the Defense Department's National Security Agency is broader than previously announced. Government officials and sources close to the bidding said the agreement includes software development and sales of computer networks and accessories. Earlier, the agency's officials said the contract, valued at as much as $946 million through 1988, covered mainly sales and service of as many as 250 minicomputers of AT&T's 3B line, introduced last year. An NSA spokesman said the intelligence agency increased its estimate of how many minicomputers it will buy under the contract to as many as 325. The spokesman said final bidding was between AT&T and Digital Equipment Corp. Sources said the decision was based more on technical considerations than on cost. International Business Machines Corp. was eliminated earlier, a source said. (that's all of it, Yow, my fingers hurt) -Barry Shein, Boston University
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1985 1808-PDT (Sunday) From: sun!l5!gnu@Berkeley (John Gilmore) To: imagen!geof@Berkeley, mogul@navajo.ARPA, tcp-ip@sri-nic.ARPA Subject: Re: tftp for bootstrap
I personally don't see much point in using tftp as a boot protocol UNLESS it will talk to existing servers. We might as well use our existing "nd" protocol if the only thing it will ever talk to is other Suns. The responses I've gotten tend strongly toward the "we did it kinda that way and it has worked for N years" type of stories, which are OK but not much help. I guess what I'm looking for is a good reason to boot with TFTP (nobody has yet said "we did it another way and are really sorry"), and some help in designing the protocol above TFTP (the file name, how we find the server), to let it interoperate with other Internet machines with minimal or no effort. It seems like the war stories all describe schemes where a custom boot server exists (maybe running TFTP but not the way it's spec'd for everybody, eg odd port #, odd file types). Can I focus this discussion to answer a specific question? What does YOUR system's TFTP server do with a file name in a RRQ which does not have any pathname delimiters? Reply to me (sun!gnu@Berkeley.arpa) and I'll summarize to the list.
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Sun, 7-Jul-85 21:50:25 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: tftp for bootstrap
From: sun!l5!gnu@BERKELEY (John Gilmore) I personally don't see much point in using tftp as a boot protocol UNLESS it will talk to existing servers. We might as well use our existing "nd" protocol if the only thing it will ever talk to is other Suns. The responses I've gotten tend strongly toward the "we did it kinda that way and it has worked for N years" type of stories, which are OK but not much help. I guess what I'm looking for is a good reason to boot with TFTP (nobody has yet said "we did it another way and are really sorry"), and some help in designing the protocol above TFTP (the file name, how we find the server), to let it interoperate with other Internet machines with minimal or no effort. It seems like the war stories all describe schemes where a custom boot server exists (maybe running TFTP but not the way it's spec'd for everybody, eg odd port #, odd file types). Can I focus this discussion to answer a specific question? What does YOUR system's TFTP server do with a file name in a RRQ which does not have any pathname delimiters? Reply to me (sun!gnu@Berkeley.arpa) and I'll summarize to the list.
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Monday, 8 Jul 1985 11:24-PDT From: imagen!geof@su-shasta.arpa To: sun!l5!gnu@su-shasta.arpa Cc: shasta!tcp-ip@sri-nic.ARPA Subject: Re: tftp for bootstrap
I must confess that my comments should really be in conjunction with Noel Chiappa's, since we are referring to the same set of TFTP implementations. I worked on some of the TFTP implementations while I was at MIT. My last message should only be read in context -- I agree that TFTP is no better a protocol than most others for bootloading, except insofar as it is possible to use other server implementations of TFTP. It is not necessary to modify a TFTP server from its "vanilla" state to make it useable for bootloading. The modifications that were done at MIT mostly were because some machines had TFTP has their only file transfer protocol (specifically, the UPDATE mode). The MIT implementations of TFTP all met spec (I presume they all still do), and few had hidden features. All ran on port 69. Some efforts were occasionally made to make sure that the implementations at MIT and ISI were able to interconnect. File names which were received were handed by the server to the operating system, and interpreted in the security and naming contexts of the server. As additional security measures: - all servers refused to overwrite existing files - the servers on Tops-20 and Multics were sufficiently isolated from a security point of view that the server had (by default) very little access to most user's files and directories. On multics, the server had to be explicitly permitted to access a portion of the directory tree. - on berkeley Unix, the server explicitly tested protections to verify that global read (or write) access existed where it was needed. This was necessary because the server had to run as root to be able to access socket 69, so our initial attempts to just have the server attempt to open the file and let the OS apply some default set of protections wouldn't work (interesting how in this case a security feature turned out to be a security bug). On most of the machines, the server would also reject any file transfer for which no directory was specified (the exception was the alto implementation, because there were no directories to speak of). On Tops-20, a device or directory spec had to be specified, but it was not necessary to specify both. For purposes of bootloading, a special directory was set up on each machine. The name of the directory was configured into the gateways, as was each machine's internet address. For reasons of code size, the bootloader was typically only able to use one interface. However, the gateways were able to boot through each other, so bootloading was possible from a wide variety of machines. Since gateway code was different for each gateway, the boot files for each gateway were named by concatenating the address of the gateway together. As Noel pointed out, this is easy to keep track of if you assign three letters to each byte for decimal or octal number (alternately, use hex). When booting, the gateway sent a read request to each host for a file whose name was the concatenation of the prefix for that host and the internet address of the gateway, unparsed as an octal string with three digits for each byte. The transfer mode was mode "image." The intent of mode "image" is that a file which is transferred to a host using it and then transferred back ends up with the same bits in it (perhaps a few more tacked onto the end); it is perfect for bootloading. We simply distributed the boot-code using TFTP mode image (with a little telnet fudging to delete the original first, see below) from the source, and were confident that it would be read back correctly. This worked on Alto's, Unices, Tops-20, and Multics (the latter two used different ways of storing the Image files - Tops-20 used 8-bit bytes with 4 bits of each 36 bit word wasted, and multics stored the bits sequentially in 36-bit words, ignoring word boundaries). The obvious way to use TFTP for bootloading is to have the gateway send a read request to every host in the list at once, and to accept the first response (and eventually reject any other responses). This is analogous to a broadcast request for booting. I'm not sure if the gateway did this in practise, or just tried the hosts in sequence. So, in summary, TFTP is a good bootloading protocol, without modification: - It supports a pseudo-broadcast mode of booting request. - It has a transfer mode that works. - It is fast enough. - It is simple (the original TFTP bootloader fit into 2Kb of ROM). - It is an internet protocol (you can boot through gateways - for a while at MIT we had two gateways booting off a network which had no other hosts on it. Each booted through the other. Worked for weeks until the power flickered one day... then we had to get out the old serial-line downloader). Problems: - You have to derive an Internet address for the host to be able to use an internet protocol to boot it. On an ethernet this is more of a problem. - You have to store both the names of the boot directories on each boot-host and the internet addresses of the boot hosts (in practise, there was only one boot rom that had all the hosts and directories in it; each gateway could not access some of the hosts in its table). This problem is minimized in a homogeneous environment, since the name of the directory can be the same everywhere. - It is an Internet protocol, so that broadcast is not a "native" mode of using it. If your nodes implement internet broadcast (I guess sun's still use host number 0 for broadcast, like the vaxen do...) you could theoretically use it, although as Noel points out, there are advantages to being able to boot through a gateway when necessary. One compromise position might be to use a broadcast scheme to get the booting information into the host, then use TFTP to boot the host. This would have the effect of compartmentalizing the nonstandard code in the system, and would add a more minor restriction to booting a host. Or use a "breath of life" scheme. Have a host periodically broadcast the booting information on the network in question, and have the bootloader just wait for the promiscuous packet to arrive. The advantage of this scheme is that you don't have to have any broadcasting booters on the local net -- they can use directed broadcast to send the breath of life packets. - Geof
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 85 11:08 EDT From: ddn-usaf @ DDN1.ARPA To: tcp-ip @ sri-nic.arpa Cc: ddn-usaf @ DDN1.ARPA Subject: take me off your mailing list
please remove my name from the tcp-ip mailing list. thank you, mike allen/ddn-usaf@ddn1
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Mon, 8-Jul-85 12:23:44 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: take me off your mailing list
From: ddn-usaf@DDN1.ARPA please remove my name from the tcp-ip mailing list. thank you, mike allen/ddn-usaf@ddn1
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 1985 1633-PDT (Monday) From: Bill Croft <croft@safe> To: sun!l5!gnu@Berkeley (John Gilmore) Cc: tcp-ip@sri-nic.ARPA, croft@safe Subject: Re: tftp for bootstrap
John, I guess what I would like to see in your new SUN Microsystems boot proms (and adopted as an internet standard) is a TWO PHASE boot: (1) The 'server location / address assignment' phase could use a simple UDP broadcast packet exchange. This exchange allows the booting client to locate boot servers by name. The same protocol can also be used to assign an IP address to the client, given his ethernet address. A sample packet exchange of such a protocol is shown below. (2) The second phase corresponds to the TFTP file transfer of the load image, given that the client knows his IP address, the servers IP address, and the file name. Optionally the client may also load through gateways if he knows a default gateway address. The boot is split into these two phases because the first is more volitile and likely to change than the second. Given that there are many TFTP 'boot/load servers' already running in the internet, it would be great to be able to utilize this resource. I could imagine that your boot code would have several entry points. The default 'power up' boot might go through both phases. However a manual entry point would allow the user to begin just the second phase, by supplying the IP addresses and pathname string mentioned above. Further, if the hardware had an EAPROM capability, a 'default' second phase boot could be completed automatically, if the person wished to make that setup option. Note that both phases of this booting use ONLY INTERNET protocols. This is in contrast to the proposed RFC903 "A Reverse Address Resolution Protocol". RFC903 proposes that we use a new ethernet link type (not ARP, but RARP) to allow a client to find his own IP address, given his ethernet address. But RFC903 can only be implemented with kernel modifications; e.g. by using the 'CMU packet filter' kernel code, or some new (as yet unwritten and unstandardized) IOCTL interface to the kernel to load this RARP information from the boot servers. Instead what you can do is have the first phase server BROADCAST his reply to the requesting client. This is only one more broadcast than the RFC903 case, but it now allows all the boot server processes to be simple UDP servers at user level with no kernel changes. Even if you did find a way to modify the kernel for RFC903, how are you going to get these mods out to all the different UNIX box companies? What about booting from TOPS20? Etc. I think the advantages are overwhelming for restricting the boot protocol to use only IP/UDP. EXAMPLE PACKET EXCHANGE OF FIRST PHASE BOOT BOOTREQUEST packet from diskless client to server: IP DST: 255.255.255.255 IP SRC: 0.0.0.0 [i.e. I don't know it yet] PROTO: UDP PORT: bootport ----- packet data is: OPCODE: BOOTREQUEST MY ETHERADDR: xx xx xx xx xx xx FILENAME: xxxxxx SERVERNAME: yyyyyy [optional] Then the boot server answers back, with a broadcast [only to this first exchange] so that we neatly bypass all the ARP bootstraping problems. After the client has his real IP address (and that of the server), a normal TFTP file read occurs. The client only accepts a BOOTACK with a CLIENT'S ETHERADDR that matches his own. BOOTACK packet from server to client: IP DST: 255.255.255.255 IP SRC: server IP address PROTO: UDP PORT: bootport ----- packet data is: OPCODE: BOOTACK CLIENT'S ETHERADDR: xx xx xx xx xx xx CLIENT'S IP ADDR: xx xx xx xx DEFAULT GATE ADDR: xx xx xx xx FILEVERSION: xx FILEDATE: xx
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 1985 17:45:57 PDT From: Stephen Casner <Casner@USC-ISIB.ARPA> To: mills@DCN6.ARPA Cc: gateway@BBN-UNIX.ARPA, egp-people@BBN-UNIX.ARPA, tcp-ip@SRI-NIC.ARPA, Casner@USC-ISIB.ARPA Subject: Re: Plea for ICMP Timestamp support
Dave, In our EPOS operating system, we use a different technique for the 60 Hz clock. Rather than adding the approximate fraction 2/3 to a fractional extension of the accumulator, we use a modulo-3 counter to add an extra 1 to the accumulator on 2 out of every 3 cycles. For the example of a millisecond clock, 17 is added on the first 2 out of 3 cycles and 16 is added on the third cycle. (In EPOS we actually keep a 48-bit clock of 40 microsecond ticks, but the principle is the same.) The advantage of this method is that it is exact rather than having an error of .000005 ms per 60 Hz tick or about 1 ms per hour. The number of instructions is about the same with either technique. Here is a code segment for the PDP11: DEC TRICYC ; Is this the third of three cycles? BPL 1$ ; No - just update time MOV #2,TRICYC ; Yes - reset the modulo-three counter ADD #INCTIM,UPTML ; Update time less 2/3 fraction to adjust BR 2$ ; for the two extra 1/3 fraction 1$: ADD #INCTIM+1,UPTML ; Update time including 1/3 fraction extra 2$: ADC UPTMM ; Carry the update out through 32 bits The BR 2$ can be eliminated by replicating code if that is practical. -- Steve -------
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Mon, 8-Jul-85 16:25:49 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: tftp for bootstrap
From: imagen!geof@su-shasta.arpa I must confess that my comments should really be in conjunction with Noel Chiappa's, since we are referring to the same set of TFTP implementations. I worked on some of the TFTP implementations while I was at MIT. My last message should only be read in context -- I agree that TFTP is no better a protocol than most others for bootloading, except insofar as it is possible to use other server implementations of TFTP. It is not necessary to modify a TFTP server from its "vanilla" state to make it useable for bootloading. The modifications that were done at MIT mostly were because some machines had TFTP has their only file transfer protocol (specifically, the UPDATE mode). The MIT implementations of TFTP all met spec (I presume they all still do), and few had hidden features. All ran on port 69. Some efforts were occasionally made to make sure that the implementations at MIT and ISI were able to interconnect. File names which were received were handed by the server to the operating system, and interpreted in the security and naming contexts of the server. As additional security measures: - all servers refused to overwrite existing files - the servers on Tops-20 and Multics were sufficiently isolated from a security point of view that the server had (by default) very little access to most user's files and directories. On multics, the server had to be explicitly permitted to access a portion of the directory tree. - on berkeley Unix, the server explicitly tested protections to verify that global read (or write) access existed where it was needed. This was necessary because the server had to run as root to be able to access socket 69, so our initial attempts to just have the server attempt to open the file and let the OS apply some default set of protections wouldn't work (interesting how in this case a security feature turned out to be a security bug). On most of the machines, the server would also reject any file transfer for which no directory was specified (the exception was the alto implementation, because there were no directories to speak of). On Tops-20, a device or directory spec had to be specified, but it was not necessary to specify both. For purposes of bootloading, a special directory was set up on each machine. The name of the directory was configured into the gateways, as was each machine's internet address. For reasons of code size, the bootloader was typically only able to use one interface. However, the gateways were able to boot through each other, so bootloading was possible from a wide variety of machines. Since gateway code was different for each gateway, the boot files for each gateway were named by concatenating the address of the gateway together. As Noel pointed out, this is easy to keep track of if you assign three letters to each byte for decimal or octal number (alternately, use hex). When booting, the gateway sent a read request to each host for a file whose name was the concatenation of the prefix for that host and the internet address of the gateway, unparsed as an octal string with three digits for each byte. The transfer mode was mode "image." The intent of mode "image" is that a file which is transferred to a host using it and then transferred back ends up with the same bits in it (perhaps a few more tacked onto the end); it is perfect for bootloading. We simply distributed the boot-code using TFTP mode image (with a little telnet fudging to delete the original first, see below) from the source, and were confident that it would be read back correctly. This worked on Alto's, Unices, Tops-20, and Multics (the latter two used different ways of storing the Image files - Tops-20 used 8-bit bytes with 4 bits of each 36 bit word wasted, and multics stored the bits sequentially in 36-bit words, ignoring word boundaries). The obvious way to use TFTP for bootloading is to have the gateway send a read request to every host in the list at once, and to accept the first response (and eventually reject any other responses). This is analogous to a broadcast request for booting. I'm not sure if the gateway did this in practise, or just tried the hosts in sequence. So, in summary, TFTP is a good bootloading protocol, without modification: - It supports a pseudo-broadcast mode of booting request. - It has a transfer mode that works. - It is fast enough. - It is simple (the original TFTP bootloader fit into 2Kb of ROM). - It is an internet protocol (you can boot through gateways - for a while at MIT we had two gateways booting off a network which had no other hosts on it. Each booted through the other. Worked for weeks until the power flickered one day... then we had to get out the old serial-line downloader). Problems: - You have to derive an Internet address for the host to be able to use an internet protocol to boot it. On an ethernet this is more of a problem. - You have to store both the names of the boot directories on each boot-host and the internet addresses of the boot hosts (in practise, there was only one boot rom that had all the hosts and directories in it; each gateway could not access some of the hosts in its table). This problem is minimized in a homogeneous environment, since the name of the directory can be the same everywhere. - It is an Internet protocol, so that broadcast is not a "native" mode of using it. If your nodes implement internet broadcast (I guess sun's still use host number 0 for broadcast, like the vaxen do...) you could theoretically use it, although as Noel points out, there are advantages to being able to boot through a gateway when necessary. One compromise position might be to use a broadcast scheme to get the booting information into the host, then use TFTP to boot the host. This would have the effect of compartmentalizing the nonstandard code in the system, and would add a more minor restriction to booting a host. Or use a "breath of life" scheme. Have a host periodically broadcast the booting information on the network in question, and have the bootloader just wait for the promiscuous packet to arrive. The advantage of this scheme is that you don't have to have any broadcasting booters on the local net -- they can use directed broadcast to send the breath of life packets. - Geof
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 85 17:31:22 EDT (Mon) From: ihnp4!ihnp1!bentley!drew@Berkeley (R. Drew Davis) Subject: Drew is on vacation thru 7/14/85
This is a recording... Your mail has been received and will be held for me. (This automatic reply program sometimes does strange things, so if you didn't mail to me, please disregard this message. Perhaps someone else mailed a news article of yours to me for my attention). I am on vacation from 7/4/85 until 7/14/85. If you have something urgent, you can contact Wyatt Chen. He has my delegation for the time that I will be away. He can be reached on (201)981-2318 or via mail to packard!ysc. His office is PY2H335. If you need to reach me personally, I can be found at home until 7/6. After that, I'll be far, far away until the evening of 7/13 when I return from the sunny shores of the Detroit vicinity. Drew
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Mon, 8-Jul-85 17:49:00 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Plea for ICMP Timestamp support
From: mills@dcn6.arpa Folks, This is a plea to the gateway implementors to incorporate ICMP Timestamp messages (cf. RFC-792) in their implementations. The reason for this timely passion is to facilitate experiments I am running to determine the feasability of synchronizing clocks across the Internet. The motivation for this is to synchonize data-base updates and cache timeouts, as well as determine one-way delays and other performance parameters. To my knowledge, the only Internet players now implementing "standard" (millisecond) ICMP Timestamps are the fuzzballs and some Unix systems, including some 4.2bsd and C/70 sites. Unfortunately, the Sun clock seems to wander badly, often over ten seconds over the course of the day. The BBN gateways do respond to ICMP Timestamp messages, but not in millisecond units. A C/70 in Germany appears to run slow by 50/60, which is hardly surprising. The following implementation hints may serve to provoke interest in bringing up an ICMP Timestamp service. Assuming some sort of line-frequency or crystal-controlled hardware clock is available, it is very simple to implement an interrupt routine that updates a double-word (32 bits) by a number of milliseconds equal to the clock interval. For 50-Hz (European) mains or crystal clocks that can be set to interrupt at a multiple of one millisecond, a 32-bit accumulator suffices; however, for 60-Hz (US) mains, an additional 16 bits of precision is neccessary for the fractional part. Just to save you some keystrokes, in the case of 60-Hz systems, the magic number of milliseconds, expressed as a 32-bit quantity in two 16-bit words, is 16 in the high-order 16 bits (integer part) and 43691 in the low-order 16 bits (fraction part). You should also roll over the clock at 24 hours, which in milliseconds expressed as a 32-bit quantity in two 16-bit words, is 1318 in the high-order 16 bits and 23552 in the low-order 16 bits. It is not necessary that the clock be synchronized to some external reference, since corrections can be computed remotely. In this case the high-order bit of the 32-bit timestamp returned in the ICMP Timestamp Reply should be set to one. If you attempt to synchronize the clock to a local reference, such as an operator command, I suggest you not disturb the clock accumulator itself, but use an additional 32-bit quantity that is added (with interrupts disabled!) modulo-24 hours to the clock accumulator before passing to the application level. In this case the high-order bit of the timestamp should be set to zero. I promise to reach out and tickle any implementation that manages this magic and report my finidngs. If there is interest in tickling fuzzballs, I will suggest appropriate targets upon individual request. I would expecially like to compare line frequency stability between the four regional power grids in (1) Quebec, (2) most of Texas, (3) west of the Rockies and (4) east of the Rockies, as well as overseas. The goal is to assess whether the rate of phase change between the grids is sufficiently small to assume reliable clocks can be achieved with relatively infrequent broadcast corrections. Dave -------
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 08 Jul 85 17:50:31 EDT (Mon) From: tmallory@bbnccv To: mills@dcn6.ARPA Cc: gateway@bbn-unix.ARPA, egp-people@bbn-unix.ARPA, tcp-ip@sri-nic.ARPA, tmallory@bbnccv Subject: Re: Plea for ICMP Timestamp support
Dave, Have you considered the alternative approach of including the time unit with the icmp time-stamp rather than forcing conversion to milliseconds which seems a little arbitrary? You would then have some idea of the granularity of the clock ticks you are comparing. (Perhaps a self-defining message using x.409?) A 24-hour rollover seems to be a reasonable request. Tracy
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 08 Jul 85 18:35:53 EDT (Mon) From: Dennis Rockwell <drockwel@CSNET-SH.ARPA> To: mills@DCN6.ARPA Cc: gateway@BBN-UNIX.ARPA, egp-people@BBN-UNIX.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Plea for ICMP Timestamp support
One thing to note about the 4.2 timestamp reply (as distributed): it is computed assuming no leap-time other than whole days. It takes the UNIX time, which is measured from midnight UT (15 years ago), divides by one day, and uses the remainder. So, for instance, the recent leap-second is basically ignored. Of course, if you look at it the other way, we've moved the zero point by the leap-time since zero. Of course, this makes no practical difference to most of us, since clocks among our machines (all in the same room) are normally different by as much as five minutes. I suppose that this is what Dave is proposing to remedy? Dave, feel free to poke CSNET-RELAY, CSNET-SH, and CSNET-DEV. For real thrills, poke 192.5.58.5, which is CSNET-DEV's PDN address. Expect to lose the first packet per five minutes, at least for a while yet. Dennis Rockwell CSNET Technical Staff
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Mon, 8-Jul-85 18:55:27 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Plea for ICMP Timestamp support
From: tmallory@bbnccv Dave, Have you considered the alternative approach of including the time unit with the icmp time-stamp rather than forcing conversion to milliseconds which seems a little arbitrary? You would then have some idea of the granularity of the clock ticks you are comparing. (Perhaps a self-defining message using x.409?) A 24-hour rollover seems to be a reasonable request. Tracy
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Mon, 8-Jul-85 19:56:45 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Plea for ICMP Timestamp support
From: Dennis Rockwell <drockwel@CSNET-SH.ARPA> One thing to note about the 4.2 timestamp reply (as distributed): it is computed assuming no leap-time other than whole days. It takes the UNIX time, which is measured from midnight UT (15 years ago), divides by one day, and uses the remainder. So, for instance, the recent leap-second is basically ignored. Of course, if you look at it the other way, we've moved the zero point by the leap-time since zero. Of course, this makes no practical difference to most of us, since clocks among our machines (all in the same room) are normally different by as much as five minutes. I suppose that this is what Dave is proposing to remedy? Dave, feel free to poke CSNET-RELAY, CSNET-SH, and CSNET-DEV. For real thrills, poke 192.5.58.5, which is CSNET-DEV's PDN address. Expect to lose the first packet per five minutes, at least for a while yet. Dennis Rockwell CSNET Technical Staff
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Mon, 8-Jul-85 20:48:08 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: tftp for bootstrap
From: Bill Croft <croft@safe> John, I guess what I would like to see in your new SUN Microsystems boot proms (and adopted as an internet standard) is a TWO PHASE boot: (1) The 'server location / address assignment' phase could use a simple UDP broadcast packet exchange. This exchange allows the booting client to locate boot servers by name. The same protocol can also be used to assign an IP address to the client, given his ethernet address. A sample packet exchange of such a protocol is shown below. (2) The second phase corresponds to the TFTP file transfer of the load image, given that the client knows his IP address, the servers IP address, and the file name. Optionally the client may also load through gateways if he knows a default gateway address. The boot is split into these two phases because the first is more volitile and likely to change than the second. Given that there are many TFTP 'boot/load servers' already running in the internet, it would be great to be able to utilize this resource. I could imagine that your boot code would have several entry points. The default 'power up' boot might go through both phases. However a manual entry point would allow the user to begin just the second phase, by supplying the IP addresses and pathname string mentioned above. Further, if the hardware had an EAPROM capability, a 'default' second phase boot could be completed automatically, if the person wished to make that setup option. Note that both phases of this booting use ONLY INTERNET protocols. This is in contrast to the proposed RFC903 "A Reverse Address Resolution Protocol". RFC903 proposes that we use a new ethernet link type (not ARP, but RARP) to allow a client to find his own IP address, given his ethernet address. But RFC903 can only be implemented with kernel modifications; e.g. by using the 'CMU packet filter' kernel code, or some new (as yet unwritten and unstandardized) IOCTL interface to the kernel to load this RARP information from the boot servers. Instead what you can do is have the first phase server BROADCAST his reply to the requesting client. This is only one more broadcast than the RFC903 case, but it now allows all the boot server processes to be simple UDP servers at user level with no kernel changes. Even if you did find a way to modify the kernel for RFC903, how are you going to get these mods out to all the different UNIX box companies? What about booting from TOPS20? Etc. I think the advantages are overwhelming for restricting the boot protocol to use only IP/UDP. EXAMPLE PACKET EXCHANGE OF FIRST PHASE BOOT BOOTREQUEST packet from diskless client to server: IP DST: 255.255.255.255 IP SRC: 0.0.0.0 [i.e. I don't know it yet] PROTO: UDP PORT: bootport ----- packet data is: OPCODE: BOOTREQUEST MY ETHERADDR: xx xx xx xx xx xx FILENAME: xxxxxx SERVERNAME: yyyyyy [optional] Then the boot server answers back, with a broadcast [only to this first exchange] so that we neatly bypass all the ARP bootstraping problems. After the client has his real IP address (and that of the server), a normal TFTP file read occurs. The client only accepts a BOOTACK with a CLIENT'S ETHERADDR that matches his own. BOOTACK packet from server to client: IP DST: 255.255.255.255 IP SRC: server IP address PROTO: UDP PORT: bootport ----- packet data is: OPCODE: BOOTACK CLIENT'S ETHERADDR: xx xx xx xx xx xx CLIENT'S IP ADDR: xx xx xx xx DEFAULT GATE ADDR: xx xx xx xx FILEVERSION: xx FILEDATE: xx
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Mon, 8-Jul-85 22:54:40 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Plea for ICMP Timestamp support
From: Stephen Casner <Casner@USC-ISIB.ARPA> Dave, In our EPOS operating system, we use a different technique for the 60 Hz clock. Rather than adding the approximate fraction 2/3 to a fractional extension of the accumulator, we use a modulo-3 counter to add an extra 1 to the accumulator on 2 out of every 3 cycles. For the example of a millisecond clock, 17 is added on the first 2 out of 3 cycles and 16 is added on the third cycle. (In EPOS we actually keep a 48-bit clock of 40 microsecond ticks, but the principle is the same.) The advantage of this method is that it is exact rather than having an error of .000005 ms per 60 Hz tick or about 1 ms per hour. The number of instructions is about the same with either technique. Here is a code segment for the PDP11: DEC TRICYC ; Is this the third of three cycles? BPL 1$ ; No - just update time MOV #2,TRICYC ; Yes - reset the modulo-three counter ADD #INCTIM,UPTML ; Update time less 2/3 fraction to adjust BR 2$ ; for the two extra 1/3 fraction 1$: ADD #INCTIM+1,UPTML ; Update time including 1/3 fraction extra 2$: ADC UPTMM ; Carry the update out through 32 bits The BR 2$ can be eliminated by replicating code if that is practical. -- Steve -------
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Mon, 8-Jul-85 23:36:28 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Drew is on vacation thru 7/14/85
From: ihnp4!ihnp1!bentley!drew@BERKELEY (R. Drew Davis) This is a recording... Your mail has been received and will be held for me. (This automatic reply program sometimes does strange things, so if you didn't mail to me, please disregard this message. Perhaps someone else mailed a news article of yours to me for my attention). I am on vacation from 7/4/85 until 7/14/85. If you have something urgent, you can contact Wyatt Chen. He has my delegation for the time that I will be away. He can be reached on (201)981-2318 or via mail to packard!ysc. His office is PY2H335. If you need to reach me personally, I can be found at home until 7/6. After that, I'll be far, far away until the evening of 7/13 when I return from the sunny shores of the Detroit vicinity. Drew
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Mon, 8 Jul 85 23:38:42 edt From: dual!mordor!seismo!rochester!ur-laser!tomk@Berkeley (Tom Kessler) To: dual!ucbvax!tcp-ip@Berkeley Subject: Re: 46M NSA/AT&T Contract for 3BXX's
Gee now if twg could only make there uucp link work...
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 08-Jul-85 20:34:56-UT From: mills@dcn6.arpa To: gateway@bbn-unix.arpa, egp-people@bbn-unix.arpa, tcp-ip@sri-nic.arpa Subject: Plea for ICMP Timestamp support
Folks, This is a plea to the gateway implementors to incorporate ICMP Timestamp messages (cf. RFC-792) in their implementations. The reason for this timely passion is to facilitate experiments I am running to determine the feasability of synchronizing clocks across the Internet. The motivation for this is to synchonize data-base updates and cache timeouts, as well as determine one-way delays and other performance parameters. To my knowledge, the only Internet players now implementing "standard" (millisecond) ICMP Timestamps are the fuzzballs and some Unix systems, including some 4.2bsd and C/70 sites. Unfortunately, the Sun clock seems to wander badly, often over ten seconds over the course of the day. The BBN gateways do respond to ICMP Timestamp messages, but not in millisecond units. A C/70 in Germany appears to run slow by 50/60, which is hardly surprising. The following implementation hints may serve to provoke interest in bringing up an ICMP Timestamp service. Assuming some sort of line-frequency or crystal-controlled hardware clock is available, it is very simple to implement an interrupt routine that updates a double-word (32 bits) by a number of milliseconds equal to the clock interval. For 50-Hz (European) mains or crystal clocks that can be set to interrupt at a multiple of one millisecond, a 32-bit accumulator suffices; however, for 60-Hz (US) mains, an additional 16 bits of precision is neccessary for the fractional part. Just to save you some keystrokes, in the case of 60-Hz systems, the magic number of milliseconds, expressed as a 32-bit quantity in two 16-bit words, is 16 in the high-order 16 bits (integer part) and 43691 in the low-order 16 bits (fraction part). You should also roll over the clock at 24 hours, which in milliseconds expressed as a 32-bit quantity in two 16-bit words, is 1318 in the high-order 16 bits and 23552 in the low-order 16 bits. It is not necessary that the clock be synchronized to some external reference, since corrections can be computed remotely. In this case the high-order bit of the 32-bit timestamp returned in the ICMP Timestamp Reply should be set to one. If you attempt to synchronize the clock to a local reference, such as an operator command, I suggest you not disturb the clock accumulator itself, but use an additional 32-bit quantity that is added (with interrupts disabled!) modulo-24 hours to the clock accumulator before passing to the application level. In this case the high-order bit of the timestamp should be set to zero. I promise to reach out and tickle any implementation that manages this magic and report my finidngs. If there is interest in tickling fuzzballs, I will suggest appropriate targets upon individual request. I would expecially like to compare line frequency stability between the four regional power grids in (1) Quebec, (2) most of Texas, (3) west of the Rockies and (4) east of the Rockies, as well as overseas. The goal is to assess whether the rate of phase change between the grids is sufficiently small to assume reliable clocks can be achieved with relatively infrequent broadcast corrections. Dave -------
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Tue, 9-Jul-85 00:58:11 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Plea for ICMP Timestamp support
From: mills@dcn6.arpa Tracy, Several years ago we chatted up the timestamp issues and ended up with a number of proposals (see old RFCs). One of the conclusions was that simple, grumpy gateways could participate with only the barest bones of code and with only minimal protocolmanship. We could recook those conclusions handily (an x.409 IP option?!), but not without shaking the dust off the ICMP spec. Notwithstanding the above, the experience with our local-net algorithms suggests a much more important issue is the sender's estimate of the intrinsic accuracy of his clock, whether derived from power mains, local radio clock or second-hand from a UPS with a free-running 59.8-Hz oscillator. Dave -------
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 09-Jul-85 03:05:42-UT From: mills@dcn6.arpa To: tmallory@bbnccv, mills@dcn6.ARPA, gateway@bbn-unix.ARPA, egp-people@bbn-unix.ARPA, tcp-ip@sri-nic.ARPA, N@DCN6.ARPA Subject: Re: Plea for ICMP Timestamp support
Tracy, Several years ago we chatted up the timestamp issues and ended up with a number of proposals (see old RFCs). One of the conclusions was that simple, grumpy gateways could participate with only the barest bones of code and with only minimal protocolmanship. We could recook those conclusions handily (an x.409 IP option?!), but not without shaking the dust off the ICMP spec. Notwithstanding the above, the experience with our local-net algorithms suggests a much more important issue is the sender's estimate of the intrinsic accuracy of his clock, whether derived from power mains, local radio clock or second-hand from a UPS with a free-running 59.8-Hz oscillator. Dave -------
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Tue, 9-Jul-85 12:18:27 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Tweaking clocks
From: mills@dcn6.arpa Folks, My apologies to some of you how might be getting three copies of the Clockwatchers Gazette. I intended to send the following reply to a recent message to the whole list, but it seems to have been swallowed. Herewith the reply: Steve, The method I proposed involves adding a fractional quantity approximately equivalent to 2/3 of a millisecond 60 times a second. The fractional quantity, expressed as a 16-bit integer, has a low-order bit that toggles at about a 001*2-^16 = 15-nanosecond period. Thus, the accumulated error after 60 ticks is about 0.9 microseconds, in other words a residual systematic error of 0.9 ppm, and that compares favorably with just about any crystal oscillator you are likely to afford. If allowed to accumulate uncorrected, however, the error after one hour would be about 3.2 milliseconds, after one day 80 milliseconds and after one year 30 seconds. According to an interview with our local power bullies, we should expect the (Eastern) 60-Hz power-grid frequency to wander over a .025-Hz band (over +-400 ppm) with daily extremes of +-3 to +-6 seconds in absolute time offsets. The fuzzball timekeeping algorithms have to yank the phase of the local clock accordingly in response to corrections broadcast on the local net, which makes the 0.9 ppm systematic error pale in the dust. While your method does have the elegance of precision, it does not lend itself to synchonization techniques which involve incremental phase adjustments, such as we use in the futzoballs. It also does not lend itself to convenient reconfiguration for oddball clocks and national frequencies. As you point out, either the method you suggest or mine costs about the same in time and code. The bottom line is, if you want short-term precision and are willing to correct your clock reasonably often, like once per day, than use a crystal clock. If you can tolerate daily variations of +-3 to +-6 seconds but don't want to correct your clock at all, then use your techniqe and a mains-frequency clock. If you are stuck with a mains-frequency clock and want to synchronize with other clocks, then use my technique. If you are stuck on a UPS with a mains-frequency clock, as some of my friends are, don't bother. Dave -------
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 09 Jul 85 13:30:31 EST (Tue) From: Christopher A Kent <cak@Purdue.EDU> To: Bill Croft <croft@su-safe.arpa> Cc: sun!l5!gnu@ucb-vax.arpa (John Gilmore), tcp-ip@sri-nic.arpa Subject: Re: tftp for bootstrap
Bill, Your protocol sounds really nice, except that IP broadcasting doesn't exist. Maybe this will provide the grease to get the wheels in motion again. chris ----------
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Tue, 9-Jul-85 13:15:42 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: 46M NSA/AT&T Contract for 3BXX's
From: dual!mordor!seismo!rochester!ur-laser!tomk@BERKELEY (Tom Kessler) Gee now if twg could only make there uucp link work...
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Tue, 9 Jul 85 14:05:24 edt From: ukma!david@anl-mcs (David Herron, NPR Lover) To: anlams!tcp-ip@Berkeley (tcp-ip@ucbvax.ARPA) Subject: Re: 46M NSA/AT&T Contract for 3BXX's
They signed a contract with The Woologong Group to provide their TCP/IP software for 3B machines. (This was announced at the same time). David Herron cbosgd!ukma!david ukma!david@anl-mcs.arpa
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Tue, 9-Jul-85 14:37:38 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Returned mail: User unknown
From: ihnp4!ihnp1!packard!Postmaster@BERKELEY (Mail Delivery Subsystem) ----- Transcript of session follows ----- Postmaster... aliased to ggr ggr... aliased to nomad!ggr ihnp1!archimedes,ihnp1!unicorn... Connecting to ihnp1.dk... 220 ihnp1.ATT.UUCP Sendmail 4.12/9-Jan-85 ready at 9 Jul 85 10:17:30 CDT (Tue) >>> HELO py/garage/packard.DK 250 ihnp1.ATT.UUCP Hello py/garage/packard.DK, pleased to meet you >>> MAIL From:<packard!ihnp4!ucbvax!tcp-ip> 250 <packard!ihnp4!ucbvax!tcp-ip>... Sender ok >>> RCPT To:<unicorn> 550 /usr/lib/uucp/mail/unicorn... Can't create output: Permission denied ihnp1!unicorn... User unknown >>> RCPT To:<archimedes> 550 /usr/lib/uucp/mail/archimedes... Can't create output: Permission denied ihnp1!archimedes... User unknown >>> QUIT 221 ihnp1.ATT.UUCP closing connection packard!ihnp1!ihnp4!ucbvax!tcp-ip... duplicate suppressed ----- Unsent message follows ----- Date: Sat, 6-Jul-85 21:49:59 EDT From: ucbvax.ARPA!tcp-ip Subject: Re: 46M NSA/AT&T Contract for 3BXX's Message-Id: <8837@ucbvax.ARPA> Received: by py/garage/packard.DK; 8507091519 Errors-To: Postmaster Sender: ihnp4!ucbvax!tcp-ip Newsgroups: fa.tcp-ip Organization: University of California at Berkeley Apparently-To: ihnp1!unicorn Apparently-To: ihnp1!archimedes From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa> Here's a note (in full) that I just sent out to INFO-3B which may shed some light on all this: --------------- THE WOLLONGONG GROUP NEWS BUREAU (i guess now that UPI is in trouble...:-) For Immediate release (05/03/85) WOLLONGONG SIGNS AGREEMENT WITH AT&T PALO ALTO, Calif. -- To expand communications through AT&T computers, The Wollongong Group and AT&T have signed an agreement under which Wollongong will provide its standard networking product for 3B supermicro and supermini computer under UNIX System V. "Wollongong's software products will have the required Department of Defense standard interface services for 3B users," said David J. Preston, director of marketing and sales for Wollongong. Among capabilities to be provided are: --File transfer (FTP) --Electronic mail (SMTP) --Virtual terminal (TELNET). "As a result, 3B users will be able to communicate over a multitude of networks," said Preston, including Ethernet (trademarked by Xerox Corporation), ARPANET, MILNET, the defense Data Network, point-to-point nets, and custom-designed networking systems. "Delivering this advanced standard of networking software to the UNIX System marketplace is an important step in AT&T's program to become a significant industry supplier of high-quality, state-of-the-art computing and communication systems," stated JoAnne Miller, product manager of 3B Networking Software. " This product family is another step in AT&T's overall strategy of continuing to provide and support system capabilities with the special advantage of adherence to current software standards," Miller continued. # # # In what I am sure is a completely unrelated article from today's WSJ (7/1) page 6 col 6: AT&T CONTRACT WITH U.S. INCLUDES SOFTWARE WORK NEW YORK - American Telephone & Telegraph Co.'s new computer contract with the Defense Department's National Security Agency is broader than previously announced. Government officials and sources close to the bidding said the agreement includes software development and sales of computer networks and accessories. Earlier, the agency's officials said the contract, valued at as much as $946 million through 1988, covered mainly sales and service of as many as 250 minicomputers of AT&T's 3B line, introduced last year. An NSA spokesman said the intelligence agency increased its estimate of how many minicomputers it will buy under the contract to as many as 325. The spokesman said final bidding was between AT&T and Digital Equipment Corp. Sources said the decision was based more on technical considerations than on cost. International Business Machines Corp. was eliminated earlier, a source said. (that's all of it, Yow, my fingers hurt) -Barry Shein, Boston University
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Tue, 9-Jul-85 16:44:59 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: tftp for bootstrap
From: Christopher A Kent <cak@Purdue.EDU> Bill, Your protocol sounds really nice, except that IP broadcasting doesn't exist. Maybe this will provide the grease to get the wheels in motion again. chris ----------
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 09-Jul-85 15:03:00-UT From: mills@dcn6.arpa To: tcp-ip@sri-nic.arpa Subject: Tweaking clocks
Folks, My apologies to some of you how might be getting three copies of the Clockwatchers Gazette. I intended to send the following reply to a recent message to the whole list, but it seems to have been swallowed. Herewith the reply: Steve, The method I proposed involves adding a fractional quantity approximately equivalent to 2/3 of a millisecond 60 times a second. The fractional quantity, expressed as a 16-bit integer, has a low-order bit that toggles at about a 001*2-^16 = 15-nanosecond period. Thus, the accumulated error after 60 ticks is about 0.9 microseconds, in other words a residual systematic error of 0.9 ppm, and that compares favorably with just about any crystal oscillator you are likely to afford. If allowed to accumulate uncorrected, however, the error after one hour would be about 3.2 milliseconds, after one day 80 milliseconds and after one year 30 seconds. According to an interview with our local power bullies, we should expect the (Eastern) 60-Hz power-grid frequency to wander over a .025-Hz band (over +-400 ppm) with daily extremes of +-3 to +-6 seconds in absolute time offsets. The fuzzball timekeeping algorithms have to yank the phase of the local clock accordingly in response to corrections broadcast on the local net, which makes the 0.9 ppm systematic error pale in the dust. While your method does have the elegance of precision, it does not lend itself to synchonization techniques which involve incremental phase adjustments, such as we use in the futzoballs. It also does not lend itself to convenient reconfiguration for oddball clocks and national frequencies. As you point out, either the method you suggest or mine costs about the same in time and code. The bottom line is, if you want short-term precision and are willing to correct your clock reasonably often, like once per day, than use a crystal clock. If you can tolerate daily variations of +-3 to +-6 seconds but don't want to correct your clock at all, then use your techniqe and a mains-frequency clock. If you are stuck with a mains-frequency clock and want to synchronize with other clocks, then use my technique. If you are stuck on a UPS with a mains-frequency clock, as some of my friends are, don't bother. Dave -------
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Wed, 10-Jul-85 03:24:48 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: 46M NSA/AT&T Contract for 3BXX's
From: ukma!david@anl-mcs (David Herron, NPR Lover) They signed a contract with The Woologong Group to provide their TCP/IP software for 3B machines. (This was announced at the same time). David Herron cbosgd!ukma!david ukma!david@anl-mcs.arpa
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 1985 1008-PDT (Wednesday) From: Bill Croft <croft@safe> To: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA> Cc: tcp-ip@SRI-NIC.ARPA, cak@purdue, John Gilmore <sun!l5!gnu@UCB-VAX.ARPA>, croft@safe Subject: Re: tftp for bootstrap
---- >Date: 09 Jul 85 13:30:31 EST (Tue) >From: Christopher A Kent <cak@Purdue.EDU> > >Your protocol sounds really nice, except that IP broadcasting doesn't exist. > Well it is implemented (perhaps non-standardly) in many Berkeley UNIXes. I hope that 4.3BSD implements the recommendations made by Jeff Mogul in RFC919/922. Those RFCs use various forms of an IP address consisting of 'all ones' or mostly ones to represent the broadcast address. ---- >Date: Wed, 10 Jul 85 08:45 EDT >From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA> > >A more general scheme for this (actually, getting the IP address), which >unfortunately requires implementing a slightly new protocol set is to >implement inverse ARP (most servers can use existing forward ARP tables; > Dave, my argument was that it would be best to implement the first phase protocol as ONLY an IP/UDP protocol. This way the server can be a user-level process (on UNIX, Multics, TOPS20, etc.) without requiring kernel/operating system mods necessary for the "reverse ARP solution". The authors of RFC903 DID implement 'reverse ARP' here at Stanford, but it required using the 'CMU packet filter' kernel code to allow a user-level server process to access arbitrary ethernet link level packet types. Any 'reverse ARP' scheme is going to require kernel mods; given that there are many different kernels out there now, with each source maintained by different organizations, a boot protocol that does not require kernel modifications I think is an overwhelming advantage. In addition, the protocol I illustrated provided several other pieces of information that "reverse ARP" lacks: (1) it allows server specification by name, instead of just address; (2) it returns IP addresses of both the client and of gateways on the cable, to allow cross-net booting; (3) it returns 'qualified' filename / version / date information. Item #3 allows the client to specify a generic name in the bootrequest (e.g. 'unix') and then the bootreply from the server could contain a qualified name based upon database lookups at the server, indexed by the client's hardware address. For example, the person performing the boot may ask to 'boot unix'; the bootreply returned from the server may contain the qualified pathname '/usr/boot/vmunix123'; the second phase boot (TFTP) then does a transfer of this new name. >Why 255.255.255.255. Shouldn't this be "CLIENT'S IP ADDR"? > In the first phase, since the client DOESNT KNOW his IP address yet, if the server sent the reply to the client's (new) IP address, the server's ARP module would be unable to discover the client's hardware address. That is why the server must broadcast this bootreply packet. I claim the slight extra overhead of this extra broadcast is well worth it, since it allows our first phase server to use only existing IP/UDP transmission (instead of implementing new ethernet link types in the kernel).
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Wed, 10 Jul 85 08:45 EDT From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA> To: Bill Croft <croft@SU-SAFE.ARPA>, John Gilmore <sun!l5!gnu@UCB-VAX.ARPA> Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: tftp for bootstrap
Date: 8 Jul 1985 1633-PDT (Monday)
From: Bill Croft <croft@safe>
John,
I guess what I would like to see in your new SUN Microsystems boot
proms (and adopted as an internet standard) is a TWO PHASE boot:
(1) The 'server location / address assignment' phase could use a
simple UDP broadcast packet exchange. This exchange allows the
booting client to locate boot servers by name. The same protocol
can also be used to assign an IP address to the client, given
his ethernet address. A sample packet exchange of such a protocol is
shown below.
A more general scheme for this (actually, getting the IP address), which
unfortunately requires implementing a slightly new protocol set is to
implement inverse ARP (most servers can use existing forward ARP tables;
with a full backup in the file system). That is, instead of saying
"What's your Ethernet address" it says "What's my protocol address." We
almost did this at MIT, but the need didn't come up. If anybody is
really interested I can try to find the full description (it's pretty
trivial; just take ARP and rearrange a few fields).
EXAMPLE PACKET EXCHANGE OF FIRST PHASE BOOT
BOOTREQUEST packet from diskless client to server:
IP DST: 255.255.255.255
IP SRC: 0.0.0.0 [i.e. I don't know it yet]
PROTO: UDP
PORT: bootport
----- packet data is:
OPCODE: BOOTREQUEST
MY ETHERADDR: xx xx xx xx xx xx
FILENAME: xxxxxx
SERVERNAME: yyyyyy [optional]
Then the boot server answers back, with a broadcast [only to this first
exchange] so that we neatly bypass all the ARP bootstraping problems.
After the client has his real IP address (and that of the server),
a normal TFTP file read occurs. The client only accepts a BOOTACK with
a CLIENT'S ETHERADDR that matches his own.
BOOTACK packet from server to client:
IP DST: 255.255.255.255
Why 255.255.255.255. Shouldn't this be "CLIENT'S IP ADDR"?
IP SRC: server IP addr