----MESSAGE-BEGIN---- <1984050412490000> Return-Path: Received: from sri-tsc.arpa by SRI-NIC.ARPA with TCP; Fri 4 May 84 19:49:51-PDT Received: by sri-tsc.arpa at Fri, 4 May 84 19:49:25 pdt Message-Id: <8405050249.AA00714@sri-tsc.arpa> Date: 4 May 1984 1949-PDT (Friday) From: Greg Satz To: tcp-ip@nic Subject: network magic cookie SRI-TSC.ARPA is a PDP/11-44 running 2.9bsd. It also acts as the SRINET-GATEWAY until we get our ARPAnet port converted. Bill Croft, while he was at SRI, ported the Berkeley 4.1a/b TCP/IP code to run on PDP-11s. Just out of curiousity, we installed code in the kernel that counts all packets going through it. We wanted to know how many packets are being passed through as opposed to those packets that are destined for it directly. We only count packets originating from hosts on SRINET (packets in the ip queue with source address on SRINET) or packets destined for hosts on SRINET (before packets are passed to the device driver, the destination address is checked). Since this is done in the ip input and output routines, our data is higher than actual packets transmitted and lower than actual packets received. SRINET is network 128.18. The host number 128.18.0.0 wound up in our data. Can anyone explain what this phantom host number is? Is this an abberation of our TCP/IP code or some network entity that exists somewhere I haven't found yet? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984050606030000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC.ARPA with TCP; Sun 6 May 84 13:03:59-PDT Date: 6 May 1984 1303 PDT From: Eric P. Scott Subject: Comments on RFCs 893 and 894 To: TCP-IP@SRI-NIC.ARPA Reply-To: EPS@JPL-VLSI.ARPA [RFC893] LH: The fixed-size local network header. For 10 a Mb/s Ethernet, the 16-byte Ethernet header. The type field in the header indicates that both the packet type (trailer) and the length of the data segment. For the 10 Mb/s Ethernet, the types are between 1001 and 1010 hexadecimal (4096 and 4112 decimal). The type is calculated as 1000 (hex) plus the number of 512-byte pages of data. A maximum of 16 pages of data may be transmitted in a single trailer packet (8192 bytes). 16-byte Ethernet header? I thought the Ethernet Specification header was Destination(6)+Source(6)+Type(2)=14... or are you following the DEC convention of using the first two bytes of data to indicate the number of bytes that follow and considering this part of the header? 8192 data bytes in a packet transmitted over a network with a MTU of 1500 is a neat trick. Did you just redefine "byte" or are you using some novel form of data compression? [RFC894] Address Mappings The mapping of 32-bit Internet addresses to 48-bit Ethernet addresses can be done several ways. A static table could be used, or a dynamic discovery procedure could be used. Static Table Each host could be provided with a table of all other hosts on the local network with both their Ethernet and Internet addresses. Dynamic Discovery Mappings between 32-bit Internet addresses and 48-bit Ethernet addresses could be accomplished through the Address Resolution Protocol (ARP) [5]. Internet addresses are assigned arbitrarily on some Internet network. Each host's implementation must know its own Internet address and respond to Ethernet Address Resolution packets appropriately. It should also use ARP to translate Internet addresses to Ethernet addresses when needed. A third possibility may exist--some interfaces (DEC and Interlan come to mind) have the notion of distinct "hardware" and "physical" addresses; the hardware address is the usual "flat" Ethernet address, the physical address is the address the interface thinks it has. The physical address is initially set to the hardware address, but can be arbitrarily changed by software command. Example: Each DECnet host has a "node ID" in the range 1-1023. The DEUNA hardware address is AA-00-03-??-??-??, but its physical address is set to AA-00-04-00-xx-yy, where `xx' is the low 8 bits of the node ID, and `yy' is the high 2 (plus the constant 04--the upper six bits of `yy' will presumably be used for `area addressing' in the future; area numbers just happen to fit in six bits). yy-xx would fit nicely into a Class B address! No tables to maintain, no extra traffic on the ether, no ARP. [RFC894] Broadcast Address The broadcast Internet address (the address on that network with a host part of all binary ones) should be mapped to the broadcast Ethernet address (of all binary ones, FF-FF-FF-FF-FF-FF hex). This is the first I've heard of this! What's wrong with the 4.2 convention? [I've always made the (mostly correct) assumption that \no host on a network would be assigned address zero/. This has the useful property that no additional context is necessary to differentiate a "network address" from "a particular host" on that network. It's not hard to intuit that (for a broadcast network) sending \to the network/ is meaningful.] There's also a practical justification--it's easier to check for a zero address than all ones (which is different for Class A, B, C networks). Sure you don't want to reconsider? -=EPS=- ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984050609090000> Received: from SCRC-RIVERSIDE.ARPA by SRI-NIC.ARPA with TCP; Sun 6 May 84 10:13:11-PDT Received: from SCRC-PEACE by SCRC-RIVERSIDE via CHAOS with CHAOS-MAIL id 11538; Sun 6-May-84 13:10:04-EDT Date: Sun, 6 May 84 13:09 EDT From: Charles Hornig Subject: network magic cookie To: Greg Satz , tcp-ip@SRI-NIC.ARPA In-Reply-To: <8405050249.AA00714@sri-tsc.arpa> Message-ID: <840506130950.3.HORNIG@PEACE.SCRC.Symbolics> Date: 4 May 1984 1949-PDT (Friday) From: Greg Satz SRINET is network 128.18. The host number 128.18.0.0 wound up in our data. Can anyone explain what this phantom host number is? Is this an abberation of our TCP/IP code or some network entity that exists somewhere I haven't found yet? Unix 4.2bsd uses (in violation of standards) a host part of all zeroes to mean the broadcast address for that network. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984050619003200> Return-Path: Received: from MIT-XX.ARPA by SRI-NIC.ARPA with TCP; Sun 6 May 84 20:00:04-PDT Date: Sun 6 May 84 23:00:32-EDT From: J. Noel Chiappa Subject: Re: Comments on RFCs 893 and 894 To: EPS@JPL-VLSI.ARPA, TCP-IP@SRI-NIC.ARPA cc: JNC@MIT-XX.ARPA In-Reply-To: Message from "Eric P. Scott " of Sun 6 May 84 13:03:00-EDT I'm not on TCP-IP yet, but I happened to see a copy of your recent note. I'm not in agreement with your comments on the Ethernet spec (RFC894). I don't think that your third possibility is in fact viable (and in fact, the first should be strongly discouraged); the reason is the sinple word 'interoperability'. One of the supposed key features of Ethernet was the fact that a wide variety of components would use this medium as a standard. IP is also a standard. However, by imposing a middle layer with three implementation choices, you have removed 'guaranteed' turnkey compatability, unless you wish to implement all three options, which seems pointless if large numbers of hosts do so to accomodate a few intransigents. The first has the key problem that it requires manually updated tables everywhere (and we all know what that's like anyway); if you speak ARP and you try to talk to someone with wired tables, he may be able to get packets to you, but you won't be able to get back, (since you can't ARP him to find out what the translation is) unless you specially wire together your IP and Ether layers (which most people don't) to save the requisite information. The latter is unacceptable as a general solution because not all hardware has the ability to respond to arbitrary addresses. I'm a little confused; you mention that DEUNA hardware addresses start with AA, which I would have thought puts them in the multi-cast area. Some people implement multi-cast by receiving all multi-cast packets and having the software sort them; silly, and cheap, to be sure, but in hardware and hard to change. Still, in general, you don't want to have a standard that not everyone can implement. Thus the second is seen as the only reasonable alternative; and if we follow the logic for only having one (so that I can plug in a random 'TCP-IP-Ether speaking' box and have it WORK without mystical utterings) it seems to be obvious why that's the standard. I'd like to strongly discourage the first, too. It's OK as a quick hack to get something working, but doing it right only takes a few sides of non-main-packet-path code; hardly a serious cost. As far as the broadcast address goes, I voted for 0 but the 1's had it. (I due that a spec is due out soon; it's written and in the final stages of goin through the mill.) I will say to their support that I agree with them that we could find no strong technical reason to use either. One thing that did weigh (to what degree I don't recall) was that '0' already meant 'unknown', rather than 'broadcast', in the ICMP Information message. I'm not sure I believe your arguments about why '0' is better. The remark about 'sending \to the network/' is semantic playfulness, but of only second-order worth compared to genuine technical reasons. I also don't believe your 'easier to check' argument. Yes, it may take a longer line of code to do the check, but that's hardly what I'd call significantly 'easier'. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984050706350000> Received: from SCRC-RIVERSIDE.ARPA by SRI-NIC.ARPA with TCP; Mon 7 May 84 07:39:17-PDT Received: from SCRC-PEACE by SCRC-RIVERSIDE via CHAOS with CHAOS-MAIL id 11604; Mon 7-May-84 10:37:31-EDT Date: Mon, 7 May 84 10:35 EDT From: Charles Hornig Subject: Comments on RFCs 893 and 894 To: EPS@JPL-VLSI.ARPA, TCP-IP@SRI-NIC.ARPA In-Reply-To: The message of 6 May 84 16:03-EDT from "Eric P. Scott" Message-ID: <840507103559.5.HORNIG@PEACE.SCRC.Symbolics> Date: 6 May 1984 1303 PDT From: Eric P. Scott [RFC894] Address Mappings The mapping of 32-bit Internet addresses to 48-bit Ethernet addresses can be done several ways. A static table could be used, or a dynamic discovery procedure could be used. Static Table Dynamic Discovery A third possibility may exist--some interfaces (DEC and Interlan come to mind) have the notion of distinct "hardware" and "physical" addresses; the hardware address is the usual "flat" Ethernet address, the physical address is the address the interface thinks it has. The physical address is initially set to the hardware address, but can be arbitrarily changed by software command. When I wrote this document, there was only one choice -- ARP. There was a reason for this. I had just spent a significant part of my time trying to make our Internet Ethernet work between our 3600's, which use ARP; our 4.2bsd Unix, which used your third scheme until we figured out how to patch it; and our Spartacus K102 which uses a static table. The whiole reason for establishing a standard is interoperability. If 2 or 3 possibilities are left in the standard, then any implementation must have ALL of them. This is impractical. I would be willing to settle for a scheme in which all IP's had to support ARP but could use one of these other schemes between consenting systems. We just need a common scheme for ALL systems to use. [RFC894] Broadcast Address The broadcast Internet address (the address on that network with a host part of all binary ones) should be mapped to the broadcast Ethernet address (of all binary ones, FF-FF-FF-FF-FF-FF hex). This is the first I've heard of this! What's wrong with the 4.2 convention? [I've always made the (mostly correct) assumption that \no host on a network would be assigned address zero/. This has the useful property that no additional context is necessary to differentiate a "network address" from "a particular host" on that network. It's not hard to intuit that (for a broadcast network) sending \to the network/ is meaningful.] There's also a practical justification--it's easier to check for a zero address than all ones (which is different for Class A, B, C networks). Sure you don't want to reconsider? I picked all ones because that was the way other documents referred to it (I think IEN 212 is the right place). I also think that all ones is better than all zeroes. The zero value is likely to appear as a network name and reusing it as a broadcast address might lead to confusion between these ideas. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984050810302900> Return-Path: <@lbl-csam.ARPA:nbires!mccallum@lbl-csam> Received: from lbl-csam.ARPA by SRI-NIC.ARPA with TCP; Tue 8 May 84 16:24:27-PDT Return-Path: Received: by lbl-csam.ARPA ; Tue, 8 May 84 16:25:11 pdt Date: Tue, 8 May 84 16:30:29 mdt From: nbires!mccallum@lbl-csam (Doug McCallum) Message-Id: <8405082230.AA17239@nbires> Received: by nbires (4.12/3.7) id AA17239; Tue, 8 May 84 16:30:29 mdt To: lbl-csam!"TCP-IP@SRI-NIC.ARPA"@lbl-csam Subject: RS-232 link level protocols for TCP/IP What type of link protocols are being used to support TCP/IP over RS-232 lines. Are the vendors that are supporting that type of connection using any standards or at least letting people know what the protocols are? Thanks, Doug McCallum ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984050817290200> Return-Path: Received: from USC-ISID by SRI-NIC.ARPA with TCP; Tue 8 May 84 18:28:46-PDT Date: 8 May 1984 21:29:02 EDT From: MILLS@USC-ISID Subject: Re: RS-232 link level protocols for TCP/IP To: nbires!mccallum@LBL-CSAM, lbl-csam!"TCP-IP@SRI-NIC cc: MILLS@USC-ISID, tcp-ip@SRI-NIC In response to the message sent Tue, 8 May 84 16:30:29 mdt from nbires!mccallum@lbl-csam Doug McCallum, See RFC891. Also see RFC822 and please fix your mail munger. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984050908292200> Return-Path: Received: from bbn-unix by SRI-NIC.ARPA with TCP; Wed 9 May 84 12:23:52-PDT Received: from BBNCCA.ARPA by BBN-UNIX ; 9 May 84 12:37:01 EDT Date: Wed, 9 May 84 12:29:22 EDT From: Martin Lee Schoffstall Subject: IP gateways To: tcp-ip@sri-nic.arpa Cc: schoff@bbncca.ARPA Has anyone built a local net based on multiple ethernets and multiple IP network numbers and connected them via gateways not based on LSI11/23's and Macro11? Have you tried to connect 2 Ethernets with a 56Kbit line between half-gateways? marty (schoff@bbnu) (decvax!bbncca!schoff) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984050913163500> Return-Path: Received: from BRL-TGR by SRI-NIC.ARPA with TCP; Wed 9 May 84 14:27:02-PDT Date: Wed, 9 May 84 17:16:35 EDT From: Ron Natalie To: Martin Lee Schoffstall cc: tcp-ip@sri-nic.arpa, schoff@bbncca.arpa Subject: Re: IP gateways I am currently working on the BRL gateway. The new BRL gateway is a totally in C project running under a minimal message passing operating system called LOS (the little operating system, it was to be called the Network Operating System, but there are too many Cyber people around here). Both LOS and the new gateway are C based and attempt is being made at machine independence. Currently the work is being done on 11/34 but we may branch out in to 68000 or some other CPU. LOS will also likely be the base for the file servers in development here. One of our projects is to tie our regional gateways together with a proteon ring net. The main fibre-optic ring will be connected only to the gateways and the remaining machines will talk via Ethernet, PCL, Hyperchannel or what ever happens to be convenient at the site. The main purpose is to replace the 6 BBN-C30 IMPS that we have as the backbone now with a higher speed net and relocating the IMPS out to more hostile field environments. This is also similar to what the project Athena people at MIT are planning I believe. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984050913340400> Return-Path: Received: from USC-ISID by SRI-NIC.ARPA with TCP; Wed 9 May 84 14:34:15-PDT Date: 9 May 1984 17:34:04 EDT From: MILLS@USC-ISID Subject: Re: IP gateways To: schoff@BBNCCA, tcp-ip@SRI-NIC cc: MILLS@USC-ISID In response to the message sent Wed, 9 May 84 12:29:22 EDT from schoff@bbncca.ARPA Marty, There are three candidates I know of based on our DCNET local-net architecture and a combination of VAXen and PDP11s, the latter running our fuzzball code, which supports, among other things, full Internet gateways, multiple gateways on the Ethernet and off-cable routing, as well as time synchronization. Louie Mamakos (Louie@cvl) or Mike Petry (Petry@cvl) can provide info on the U of Maryland clone, Paal Spilling (Paal@nta-vax) on the NTARE (Norway) clone and I (Mills@isid) on the Linkabit clone. John Nagle at Ford Aerospace (jbn@facc) has a hybrid clone doing much the same thing. Further discussion is probably best directly with these gents at the given mailboxes. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984051007322700> Mail-From: ROODE created at 10-May-84 14:32:27 Date: Thu 10 May 84 14:32:27-PDT From: David Roode Subject: Re: DEC "All-In-One"; Accessible Thru TAC? To: dca-pgs@DDN1.ARPA, tcp-ip@SRI-NIC.ARPA, info-nets%mit-oz@MIT-MC.ARPA, works@RUTGERS.ARPA, human-nets@RUTGERS.ARPA cc: hawgs@SRI-NIC.ARPA, navyusers@DDN1.ARPA In-Reply-To: Message from "dca-pgs " of Thu 10 May 84 13:04:01-PDT Location: EJ286 Phone: (415) 859-2774 I believe that you are referring to a product out of the New York City DEC Office that is based on EMACS, which is a popular DEC-20 text editor that is very commonly used via Telnet. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984051011441200> Return-Path: Received: from ddn1 by SRI-NIC.ARPA with TCP; Thu 10 May 84 13:03:41-PDT Date: Thu, 10 May 84 15:44:12 EDT From: dca-pgs Subject: DEC "All-In-One"; Accessible Thru TAC? To: tcp-ip@sri-nic.arpa, info-nets%mit-oz@mit-mc.arpa, works@rutgers.arpa, human-nets@rutgers.arpa Cc: dca-pgs@DDN1.ARPA, hawgs@sri-nic.arpa, navyusers@DDN1.ARPA Was wondering if there would be any complications if one were to set up a Telnet session with a DEC host and tried to use the full-screen capabilities of All-In-One. Any problems with embedded control characters or escape sequences? Is anyone currently accessing All-in-One across the Internet via Telnet? All responses appreciated. Best, -Pat Sullivan DCA/DDN/PMO ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984051012585600> Return-Path: Received: from RUTGERS.ARPA by SRI-NIC.ARPA with TCP; Thu 10 May 84 13:59:04-PDT Date: 10 May 84 16:58:56 EDT From: Don Subject: Re: test To: jsol@BBN-UNIX.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "Jon Solomon " of 10 May 84 14:51:13 EDT Got to me... Hi, JSol! Don ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984051020072000> Return-Path: Received: from BRL-TGR by SRI-NIC.ARPA with TCP; Thu 10 May 84 21:25:56-PDT Date: Fri, 11 May 84 0:07:20 EDT From: Mike Muuss To: Martin Lee Schoffstall cc: tcp-ip@sri-nic.arpa, schoff@bbncca.arpa Subject: Re: IP gateways Is doing it between DEC PCL-11 (16 Mbps), Ethernet (10 Mbps), and a Hyperchannel (50 Mbps), with a 100 Kbps link inbetween, using PDP-11/34s running the BRL "LOS" Gateway (written in C) good enough? The 100 Kbps line, by the way, is part of our ARPANET-clone (IMPs). Best, -Mike Muuss (301)-278-6678 AV 283-6678 FTS 939-6678 ArpaNet: Mike @ BRL UUCP: ...!{decvax,research}!brl-bmd!mike Postal: Mike Muuss Leader, Advanced Computer Systems Team Computer Techniques and Analysis Branch Systems Engineering and Concepts Analysis Division U.S. Army Ballistic Research Laboratory Attn: DRSMC-BLB (Muuss) APG, MD 21005 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984051804530000> Return-Path: Received: from su-shasta.arpa by SRI-NIC.ARPA with TCP; Fri 18 May 84 12:28:59-PDT Received: from imagen by Shasta with UUCP; Fri, 18 May 84 12:26 PDT Date: Friday, 18 May 1984 11:53-PDT To: shasta!tcp-ip@sri-nic Cc: geof@su-shasta.arpa Reply-To: imagen!geof@shasta Phone: (415) 960-0714 (work) Postal-Address: IMAGEN, 2660 Marine Way, Mountain View, CA 94043 Subject: ARP for other than IP-on-Ethernets From: imagen!geof@su-shasta.arpa Has anyone assigned additional well-known numbers for using ARP on other than 10 Mb/s Ethernets? for protocols other than Internet? Is there someone who is handling these assignments? (I sent a netmail message to Dave Plummer, the author of the ARP document, but got no response). Arp is so obviously the ``right'' solution for the problem it solves, that I would like to see it used elsewhere. For example, XNS is mostly implemented on Ethernets now; maybe ARP could be used as a means of standardising vendor-supported implementations of XNS on other networks. Obviously the members of this list do not decide such issues, but a first step is to agree on what ARP hardware and network-address numbers to use for such a case. - Geof Cooper IMAGEN ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984051919591900> Return-Path: <@DCN6.ARPA:mills@dcn6> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Sat 19 May 84 13:38:57-PDT Date: 19-May-84 19:59:19-UT From: mills@dcn6 Subject: Comments on TELNET negotiations To: tcp-ip@nic cc: mills@dcn6 Folks, Those of us (and there are many) who have implemented TELNET negotiations in various user and server programs have found unsuspected problems when interworking with new hosts due to differing interpretations of the current specification RFC854. This note represents an attempt to formalize the negotiation process and examine some of the problems. Your comments on this note would be appreciated. The following, taken from RFC854, states the basic principles of TELNET option negotiations: The basic strategy for setting up the use of options is to have either party (or both) initiate a request that some option take effect. The other party may then either accept or reject the request. If the request is accepted the option immediately takes effect; if it is rejected the associated aspect of the connection remains as specified for an NVT. Clearly, a party may always refuse a request to enable, and must never refuse a request to disable some option since all parties must be prepared to support the NVT. The Model Consider two peers A and B running TELNET between them. An option O is defined as a state variable with respect to one of the peers, assumed A below, and written O(A). Note that O(B), while carrying the same option identifier and possibly semantically related, is a different option and is negotiated separately. For instance, the option "convert to upper case" naturally applies to each peer separately, while the option "remote echo" implies matching behavioral adaptations in each of them. In the following, we are only concerned about the protocol issues and not the semantic ones. The state variable O(A) can take on two values: on and off. The initial value is off, with succeeding values as determined by coupled protocol machines at both A and B. For option O(A) we will call A the server and B the user. Again, O(B) is a different option for which B is the server and A the user. Informally, the dialog proceeds as follows. The user can request a change of O(A) by sending a DO or DONT message to the server, expecting a WILL or WONT message in reply. On the other hand, the server can request a change of O(A) by sending a WILL or WONT message to the user, expecting a DO or DONT reply. The protocol is designed so that WILL/WONT is an acknowledgment of a DO and DO/DONT is an acknowledgment for a WILL. In order to avoid nonterminating negotiations, the only acceptable acknowledgment for a DONT is WONT and for a WONT is DONT. Other restrictions will be introduced later. Note the comment from RFC854: The syntax of option negotiation has been set up so that if both parties request an option simultaneously, each will see the other's request as the positive acknowledgment of its own. The model described below consists of formal state machines believed faithful to the spirit of RFC854. The intent is not to change or expand the negotiation protocol, but to express it in a form suitable for precise implementation and testing. Following is the server state diagram for the protocol. The user state diagram is identical, but relabelled as follows: DO -> WILL DONT -> WONT WILL -> DO WONT -> DONT The edges are labelled / in the usual sense, with implying sending the corresponding message and "-" indicating no action. The is either a received message from the remote peer or a local command requesting change of the option state. The nodes are labelled with the state number and implied option value, on or off. The "*" indicates a protocol error, which will be discussed later. DO/- +---------------------------------------+ | +---+ DONT/- | | | V V +-------+ DONT/- +-------+ DO/WILL +-------+ +--| 0 |---------->| 1 |---------->| 2 |--+ on/- on/- | | | | | | | | +->| off |<----------| off |<----------| on |<-+ DO/- +-------+ on/WILL +-------+ DONT/WONT +-------+ A | A off/- | | | | +----------------------------------+ | off/WONT | | | on/WILL | | | | V | V | | off/WONT +-------+ +-------+ | +-------------->| 3 | DONT/- | 4 | | | |<----------| | +------------------| off | | on | on/WILL +-------+ +-------+ | A off/- | A off/- +---+ DO/WONT +---+ DO/WONT * DONT/- Following are the state transition matrices associated with the A and B machines. The blank spaces in the matrices mean no action - the machine stays in the same state. As in the above diagram, the "*" means a protocol violation, that is, the peer refused to comply with a request to set the option value to off. The suggested action shown is believed consistent with the Principal of Least Astonishment. A user 0 off 1 off 2 on 3 off 4 on +-----------+-----------+-----------+-----------+-----------+ on | |0/DO | |0/DO |1/DO | off |3/DONT |3/- |4/DONT | | | WILL |2/- |2/DO | |3/DONT |4/DONT * | WONT |1/- | |1/DONT | |3/- | +-----------+-----------+-----------+-----------+-----------+ B server 0 off 1 off 2 on 3 off 4 on +-----------+-----------+-----------+-----------+-----------+ on | |0/WILL | |0/WILL |1/WILL | off |3/WONT |3/- |4/WONT | | | DO |2/- |2/WILL | |3/WONT |4/WONT * | DONT |1/- | |1/WONT | |3/- | +-----------+-----------+-----------+-----------+-----------+ The initial conditions of the server and user machines reflect whether either is prepared to accept the on value for the state variable. If a machine is started in state 1 it is prepared to accept this value if either requested locally (on event) or remotely (WILL or DO message). If started in state 3 it will refuse all remote requests to accept the on value, but will request this value of its peer if requested locally. Following this and in the absence of errors, the system will presumably stablize with both peers in state 2 only when the on event has been received at both machines and with one machine in state 1 and the other in state 3 or both machines in state 3 in all other cases. The following exhaustive set of scenarios demonstrate that the server/user system stabilizes in the correct final states when started from the specified initial states and when the dialog is allowed to complete as the result of a single on/off local request at A. The set must be completed by the addition of another set of states for requests at B with appropriate relabeling. Request on Request off Step State Action Event State Action Event ----------------------------- ----------------------------- 1 [1,1] -> [0,1] A:on /DO [1,1] -> [3,1] A:off /- 2 [0,1] -> [0,2] B:DO /WILL 3 [0,2] -> [2,2] A:WILL /- 1 [1,3] -> [0,3] A:on /DO [1,3] -> [3,3] A:off /- 2 [0,3] -> [0,3] B:DO /WONT 3 [0,3] -> [1,3] A:WONT /- 1 [3,1] -> [0,1] A:on /DO [3,1] -> [3,1] A:off /- 2 [0,1] -> [0,2] B:DO /WILL 3 [0,2] -> [2,2] A:WILL /- 1 [3,3] -> [0,3] A:on /DO [3,3] -> [3,3] A:off /- 2 [0,3] -> [0,3] B:DO /WONT 3 [0,3] -> [1,3] A:WONT /- 1 [2,2] -> [4,2] A:off /DONT 2 [4,2] -> [4,1] B:DONT /WONT 3 [4,1] -> [3,1] A:WONT /- Upon further exploration of the state space it is evident that the system will stabilize in the correct states even if both peers receive on or off events at the same time, but the machines are allowed to complete the handshake. In other cases, including those when a peer changes its mind midway through the handshake, it is possible to get into a configuration where a peer apparently refuses a request to set the option off; however, with the state transitions shown, this configuration will eventually stabilize in the expected states. One of the problems often experienced by TELNET implementors is nonterminating negotiation loops. A set of rules designed to prevent these loops is specified in RFC854: 3. The symmetry of the negotiation syntax can potentially lead to nonterminating acknowledgment loops -- each party seeing the incoming commands not as acknowledgments but as new requests which must be acknowledged. To prevent such loops, the following rules prevail: a. Parties may only request a change in option status; i.e., a party may not send out a "request" merely to announce what mode it is in. b. If a party receives what appears to be a request to enter some mode it is already in, the request should not be acknowledged. This non-response is essential to prevent endless loops in the negotiation. It is required that a response be sent to requests for a change of mode -- even if the mode is not changed. In practice, these rules have been found confusing and ambiguous, as well as awkward to apply in practice. By inspection of the above diagram it is immediately obvious that these rules are obeyed. The diagram is believed a more clear and concise statement of the rules, yet in a form readily useful for implementation. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984052004252700> Return-Path: Received: from SU-SCORE.ARPA by SRI-NIC.ARPA with TCP; Sun 20 May 84 11:30:00-PDT Date: Sun 20 May 84 11:25:27-PDT From: Mark Crispin Subject: Re: Comments on TELNET negotiations To: mills@DCN6.ARPA cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "mills@dcn6" of Sat 19 May 84 14:52:53-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Dave - The TOPS-20 (and WAITS, and ITS) TELNET program cheats a little on the way it implements TELNET options. Its cheating has the advantage of being (to the network) "correct" and simple. I wrote all three programs which is why the algorithms are similar. I have a state variable for each option I support, e.g. ECHOP for Echo state, TRBINP for Transmit Binary state, RCBINP for Transmit Binary state in the other direction ("receive binary"), etc. I change the state variable when I initiate an option. There are four cases: (1) I seek to set an option that is clear. I send DO/WILL as appropriate and set the state variable, causing it to immediately take effect. I either get back an acceptance, which I ignore as it is a "request to enter a state I already am in", or a rejection, which causes me to clear the state variable and acknowledge the rejection. (2) I seek to clear an option that is set. I send DONT/WONT as appropriate and clear the state variable. I either get back a WONT/DONT answer which I ignore as "request to enter a state I already am in", or get a WILL/DO which I interpret as a violation of protocol (although this probably depends upon how much later it happens). (3) I answer a "set option" and (4) "clear option" as per the spec. While this implementation is not strictly correct as it lets an option be set before the acknowledgement comes in, in practice it doesn't really hurt. While timing races can occur with things such as echo, my experience with observation with an algorithm which does the "correct" thing is that virtually nothing is bought by absolute adherance to the spec. You will always get timing races in the cases where they most often happen, that is, in the flurry of negotiations which happen when the connection is initiated. Within the lifetime of the connection, I have never noticed any serious problems due to my algorithm. Among other things, it is significantly simpler than the more complicated "correct" algorithm and consequently is more likely to be implemented correctly! On this topic, I have another grumble. Why do so many servers send IAC DO SUPPRESS-GA and users send IAC WILL SUPPRESS-GA? The SUPPRESS-GA option is only meaningful in the other direction! Its purpose is to unlock the keyboard on 2741's! ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984052007565100> Return-Path: Received: from USC-ISIF by SRI-NIC.ARPA with TCP; Sun 20 May 84 14:58:59-PDT Date: 20 May 1984 14:56:51 PDT From: POSTEL@USC-ISIF Subject: ARP for other than IP on Ethernets To: TCP-IP@SRI-NIC Geof Cooper: That seems to fall naturally to the "number czar" like all the other thing listed in the Assigned Numbers RFC. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984052007590000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC.ARPA with TCP; Sun 20 May 84 15:00:15-PDT Date: 20 May 1984 1459 PDT From: Eric P. Scott Subject: Re: TELNET Options? How about simple stuff! To: TCP-IP@SRI-NIC.ARPA Reply-To: EPS@JPL-VLSI.ARPA I claim that in the default mode for a NVT, a logical end-of-line is represented by a CR-LF character sequence. The telnet server that I've implemented for our Sperry 1100 system (which has a line-at-a-time interface) checks for this sequence, but I've seen CR-NUL or just LF appear from time to time. I'd hate to modify my server to perpetuate a kludge. The discussion of CR LF vs. CR NUL in RFC 854 is in the context of controlling the NVT printer. You have to separate telnet, the protocol, from telnet, the service, and telnet, the user program. Even though "the protocol is designed to be symmetric," communication between a user telnet and a server telnet is not quite (witness the furor over GAs). Those of us who were raised on late-60s-early-70s DEC and HP machines became accustomed to using the RETURN key to signal end-of-line. In order to make user telnet appear to the operator reasonably similar to local usage, the following conventions are thus adopted: server telnet: any USASCII code is accepted as input; if CR, don't wait for another character, but note that the last character was CR. Drop a NUL or LF that immediately follows a CR. Output as is, but insert a NUL if the last character was CR and the current is not LF. user telnet: RETURN sends CR LF; all other USASCII codes are sent as is. This is convenient for talking to other servers (SMTP, NICNAME, etc.). Received characters are output as is; NUL immediately following CR is dropped. "New line" is an old IBMism. There is a NL character in the EBCDIC set. In ASCII there really isn't (at various times I've seen CR LF, CR, LF, and US used). ASCII-68 \permits/ the use of the LF code for this purpose; this is done by traditional Unix* and modern DG operating systems. They call this "ANSI standard." A system which expects LF as its end-of-line character is probably going to be quite pleased receiving one in a telnet stream. I won't speculate further. In any case, the point is that the choice of end-of-line character(s) (and for that matter, the choice of whether to at all) is up to each particular system. (Here we go, IAC NL!) Other protocols built upon telnet (e.g. FTP) explicitly define CR LF as their end-of-line. Very few operating systems I've seen were designed with [DARPA-style] networking in mind; their telnet servers tend to be hooked into pseudo-terminals isolated from the target process' I/O requests. A lot of "smarts" just aren't possible when this is done, but "doing it right" is usually next to impossible. Secondly, in the same default mode for a NVT, with no remote echo option negotiated there are some telnet programs (mentioned above) which still packetize single characters. This has no real utility, and presents an added load to the network links which are not necessary. When your network interface has a slow link (4.8 or 9.6 KB), you can really notice this. I'm afraid you're wrong here. If anything, it's GAs which imply a line-at-a-time discipline. I've used systems that operate full-duplex, character-at-a-time, \with local echo/. If finer control is what's needed, maybe it's time to dust off RCTE (RFC 726). When I was young, and ASR-33s were The Way (300 baud was "fast"--and a rare find), and FTP hadn't yet been invented, multiplexing a 4.8Kb line was a reasonable thing to do. Fifteen years later I am stupefied by people who jump on the 9.6Kb X.25 bandwagon and then complain about how "we" are taking advantage of them. Barnum was right. So was Sturgeon. <--flame> -=EPS=- *Unix is a trademark of AT&T Bell Laboratories ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984052011034900> Return-Path: Received: from cvl by SRI-NIC.ARPA with TCP; Sun 20 May 84 12:08:08-PDT Date: 20 May 1984 15:03:49-EDT From: Louis A Mamakos Reply-to: louie@cvl To: tcp-ip@sri-nic.arpa Subject: TELNET Options? How about simple stuff! This little note is inspired by Dave Mills' note on TELNET options. There are far simpler things wrong with many telnet implementations that can also be examined and solved. The first, and my favorite dead horse to kick, is what character sequence to terminate logical lines with. Specificaly, when the telnet connection is first established, and no remote-echo or binary-mode options have been negotiated. Just about all of the Berkeley user telnet programs (2.8BDS, 4.1c BSD and 4.2BSD) insist on sending an improper sequence. I claim that in the default mode for a NVT, a logical end-of-line is represented by a CR-LF character sequence. The telnet server that I've implemented for our Sperry 1100 system (which has a line-at-a-time interface) checks for this sequence, but I've seen CR-NUL or just LF appear from time to time. I'd hate to modify my server to perpetuate a kludge. Secondly, in the same default mode for a NVT, with no remote echo option negotiated there are some telnet programs (mentioned above) which still packetize single characters. This has no real utility, and presents an added load to the network links which are not necessary. When your network interface has a slow link (4.8 or 9.6 KB), you can really notice this. So what do you, the implemtors and users of this software think? Am it off-base or confused somewhere? I think not. PLEASE! Don't forget the groady machines that we've got to get on the network that don't have remote echo and other fancy features. Remember to implement the basic NVT model first, and the go on from there. Don't leave our 1960's operating systems in the dust; we're trying.. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Louis A. Mamakos - Computer Science Center (Systems Staff) - Univ. of Maryland Internet: louie@cvl.ARPA uucp: ...!{seismo,ihnp4,allegra}!rlgvax!cvl!louie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984052309293000> Return-Path: Received: from nprdc by SRI-NIC.ARPA with TCP; Wed 23 May 84 16:41:27-PDT Date: 23 May 1984 16:29:30-PDT From: Mel Moy Reply-To: melmoy@nprdc To: dca-pgs@ddn1@RADC-TOPS20.ARPA Subject: Re: Tava PC Query Cc: info-ibmpc@usc-isib.arpa, dca-pgs@DDN1.ARPA, ddn-dod@DDN1.ARPA, tcp-ip@sri-nic.arpa, info-hz100@radc-tops20.arpa, melmoy@nprdc One of the PC magazines did a review on the compatibility of IBM compatible machines. TAVA scored high, but have heard disgruntled reports on satisfaction with quality control of the unit. CDC drives seem to be most preferred amongst users. Tandon and Qume have had problems--plus they're noisy. Mel Moy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984052312145400> Return-Path: Received: from ddn1 by SRI-NIC.ARPA with TCP; Wed 23 May 84 13:30:24-PDT Date: 23 May 84 16:14:54 EDT From: dca-pgs @ DDN1.ARPA Subject: Tava PC Query To: info-ibmpc @ usc-isib.arpa CC: dca-pgs @ DDN1.ARPA, ddn-dod @ DDN1.ARPA, tcp-ip @ sri-nic.arpa, info-hz100 @ radc-tops20.arpa Has anyone out there had any contact with the Tava PC? What have your experiences been? How well do the Qume disk drives perform? Direct responses appreciated. Thank you, Pat Sullivan DCA/DDN/PMO ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984052817041600> Return-Path: Received: from wisc-rsch.arpa by SRI-NIC.ARPA with TCP; Mon 28 May 84 20:02:52-PDT Date: Mon, 28 May 84 22:04:16 cdt Message-Id: <8405290304.AA21094@wisc-rsch.arpa> Received: by wisc-rsch.arpa; Mon, 28 May 84 22:04:16 cdt To: TCP-IP@SRI-NIC Subject: Networking Software Available for IBM VM Computers Sender: forwarder@wisc-rsch.arpa From: lhl@wisc-rsch.arpa The University of Wisconsin has implemented the DOD Internet protocols (FTP/SMTP/Telnet/TCP/IP) for IBM VM systems under con- tract to IBM. This software package, called WISCNET, is owned by IBM. IBM has licensed Wisconsin to distribute WISCNET to univer- sities and colleges. Source code will be included with the dis- tribution, which will begin in mid-June. To receive WISCNET, a university or college must sign a license agreement with the University of Wisconsin and pay a one-time distribution fee of $500. Licenses may be obtained from and should be returned to: Lawrence H. Landweber Computer Science Department University of Wisconsin - Madison 1210 W. Dayton St. Madison, WI 53706 ARPANET, CSNET: landweber@wisc-rsch.ARPA UUCP: ...!{seismo,allegra,ihnp4}!uwvax!landweber Documents describing WISCNET will be sent with licenses. BRIEF OVERVIEW OF WISCNET WISCNET includes: (1) An implementation of the standard DOD protocols TCP and IP under VM/SP Release 2 or 3. (2) Implementations of the higher-level DOD protocols FTP, SMTP, and Telnet. (3) An interface between SENDFILE and SMTP. (4) Interfaces from IP to the Ethernet and Pronet local area networks (using a DACU as described below). (5) An interace from IP to the Telenet public data network (using a Series/1 as described below). TCP/IP runs in a separate disconnected virtual machine on the VM host. Similarly, each of SMTP, server FTP, and server Telnet occupies a dedicated virtual machine. User FTP and user Telnet run within a user's virtual machine under CMS. Virtual machines communicate with one another using the Virtual Machine Communication Facility (VMCF). The VM software is written almost entirely in Pascal, with a small amount of assembler-language support. Standard IBM-released software is used throughout (i.e., no modified or unreleased sys- tem software has been employed). Local area network interfaces are available for Pronet (Pro- teon Corp. - 10 Megabit/sec token ring) and Ethernet (Interlan - 10 Megabit/sec). The IBM host is connected to these local area networks via a Device Access Control Unit (DACU), which is a UNIBUS-to-channel adapter sold by IBM. There is also an inter- face to the Telenet public data network, using an X.25 implemen- tation running on a channel-attached Series/1 front end running the RPS operating system. The latter interface allows CSNET IBM VM hosts to connect to the DARPA Internet via Telenet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984053104290000> Return-Path: Received: from nosc.ARPA by SRI-NIC.ARPA with TCP; Thu 31 May 84 12:42:41-PDT Received: from cod.ARPA by nosc.ARPA (4.12/4.7) id AA06679; Thu, 31 May 84 12:39:35 pdt Received: by cod.ARPA (4.12/4.7) id AA20014; Thu, 31 May 84 12:42:22 pdt From: Thomas Hutton Message-Id: <8405311829.AA28226@sdcsvax.UCSD> Received: by sdcsvax.UCSD; Thu, 31 May 84 11:29:13 pdt From-The-Terminal-Of: Thomas Hutton - sdcsvax (ttys7) Phone-Number: (619) 487-2698 Posted-Date: Thu, 31 May 84 11:29:13 pdt Weather: Sunny and Warm Date: 31 May 1984 1129-PDT (Thursday) To: tcp-ip@sri-nic Subject: Addition to mailing list Could you please add my name to the distribution list for the mailing group tcp-ip. Tom Hutton hutton@nosc.ARPA {internet} ucbvax!sdcsvax!hutton {uucp} ----MESSAGE-END----