# The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1984)
DOCUMENT: TCP-IP Distribution List for May 1984 (24 messages, 17152 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1984/05.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      4 May 1984 1949-PDT (Friday)
From:      Greg Satz <[email protected]>
To:        [email protected]
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?

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      6 May 1984 1303 PDT
From:      Eric P. Scott <[email protected]>
To:        [email protected]
Subject:   Comments on RFCs 893 and 894
[RFC893]
LH:

The fixed-size local network header.  For 10 a Mb/s Ethernet,
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

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]

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
Protocol (ARP) [5].  Internet addresses are assigned arbitrarily
on some Internet network.  Each host's implementation must know
Resolution packets appropriately.  It should also use ARP to

A third possibility may exist--some interfaces (DEC and Interlan
come to mind) have the notion of distinct "hardware" and
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]

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=-
------

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 May 84 13:09 EDT
From:      Charles Hornig <Hornig%[email protected]>
To:        Greg Satz <[email protected]>, [email protected]
Subject:   network magic cookie
    Date:  4 May 1984 1949-PDT (Friday)
From: Greg Satz <[email protected]>

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


-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Sun 6 May 84 23:00:32-EDT
From:      J. Noel Chiappa <[email protected]>
To:        [email protected], [email protected]
Cc:        [email protected]
Subject:   Re: Comments on RFCs 893 and 894
	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
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
'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'.
-------

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 May 84 10:35 EDT
From:      Charles Hornig <Hornig%[email protected]>
To:        [email protected], [email protected]
Subject:   Comments on RFCs 893 and 894
    Date: 6 May 1984 1303 PDT
From: Eric P. Scott <[email protected]>

[RFC894]

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
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]

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
between these ideas.


-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 May 84 16:30:29 mdt
From:      [email protected] (Doug McCallum)
To:        lbl-csam!"[email protected]"@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

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      8 May 1984 21:29:02 EDT
From:      [email protected]
To:        [email protected], lbl-csam!"[email protected]
Cc:        [email protected], [email protected]
Subject:   Re: RS-232 link level protocols for TCP/IP
In response to the message sent  Tue, 8 May 84 16:30:29 mdt from [email protected]

Doug McCallum,

Dave
-------

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 May 84 12:29:22 EDT
From:      Martin Lee Schoffstall <[email protected]>
To:        [email protected]
Cc:        [email protected]
Subject:   IP gateways
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
([email protected])
(decvax!bbncca!schoff)


-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 May 84 17:16:35 EDT
From:      Ron Natalie <[email protected]>
To:        Martin Lee Schoffstall <[email protected]>
Cc:        [email protected], [email protected]
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

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      9 May 1984 17:34:04 EDT
From:      [email protected]
To:        [email protected], [email protected]
Cc:        [email protected]
Subject:   Re: IP gateways
In response to the message sent  Wed, 9 May 84 12:29:22 EDT from [email protected]

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 ([email protected]) or Mike Petry ([email protected]) can provide info on
the U of Maryland clone, Paal Spilling ([email protected]) on the NTARE (Norway)
clone and I ([email protected]) on the Linkabit clone. John Nagle at Ford
Aerospace ([email protected]) has a hybrid clone doing much the same thing. Further
discussion is probably best directly with these gents at the given mailboxes.

Dave
-------

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Thu 10 May 84 14:32:27-PDT
From:      David Roode <[email protected]>
To:        [email protected], [email protected], info-nets%[email protected], [email protected], [email protected]
Cc:        [email protected], [email protected]
Subject:   Re: DEC "All-In-One"; Accessible Thru TAC?
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.
-------

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 May 84 15:44:12 EDT
From:      dca-pgs <[email protected]>
To:        [email protected], info-nets%[email protected], [email protected], [email protected]
Cc:        [email protected], [email protected], [email protected]
Subject:   DEC "All-In-One"; Accessible Thru TAC?
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
<[email protected]>


-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      10 May 84 16:58:56 EDT
From:      Don <[email protected]>
To:        [email protected], [email protected]
Subject:   Re: test
Got to me...

Hi, JSol!

Don
-------

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 May 84 0:07:20 EDT
From:      Mike Muuss <[email protected]>
To:        Martin Lee Schoffstall <[email protected]>
Cc:        [email protected], [email protected]
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
Computer Techniques and Analysis Branch
Systems Engineering and Concepts Analysis Division
U.S. Army Ballistic Research Laboratory
Attn: DRSMC-BLB (Muuss)
APG, MD  21005
-------

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Friday, 18 May 1984 11:53-PDT
From:      [email protected]
To:        [email protected]
Cc:        [email protected]
Subject:   ARP for other than IP-on-Ethernets
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

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      19-May-84 19:59:19-UT
From:      [email protected]
To:        [email protected]
Cc:        [email protected]
Subject:   Comments on TELNET negotiations
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 <event> / <action> in the usual sense, with <action>
implying sending the corresponding message and "-" indicating no action. The
<event> 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

-------

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Sun 20 May 84 11:25:27-PDT
From:      Mark Crispin <[email protected]>
To:        [email protected]
Cc:        [email protected]
Subject:   Re: Comments on TELNET negotiations
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!
-------

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      20 May 1984 14:56:51 PDT
From:      [email protected]
To:        [email protected]
Subject:   ARP for other than IP on Ethernets
Geof Cooper:

That seems to fall naturally to the "number czar" like all the other thing
listed in the Assigned Numbers RFC.

--jon.
-------

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      20 May 1984 1459 PDT
From:      Eric P. Scott <[email protected]>
To:        [email protected]
Subject:   Re: TELNET Options? How about simple stuff!
	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
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).

<Flame++> 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
of them.  Barnum was right.  So was Sturgeon.  <--flame>

-=EPS=-

*Unix is a trademark of AT&T Bell Laboratories
------

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      20 May 1984 15:03:49-EDT
From:      Louis A Mamakos <[email protected]>
To:        [email protected]
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
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: [email protected]     uucp: ...!{seismo,ihnp4,allegra}!rlgvax!cvl!louie

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      23 May 1984 16:29:30-PDT
From:      Mel Moy <[email protected]>
Cc:        [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject:   Re: Tava PC Query
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

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      23 May 84 16:14:54 EDT
From:      dca-pgs @ DDN1.ARPA
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
Subject:   Tava PC Query

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


-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 May 84 22:04:16 cdt
From:      [email protected]
To:        [email protected]
Subject:   Networking Software Available for IBM VM Computers
     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
1210 W. Dayton St.

ARPANET, CSNET: [email protected]
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.

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      31 May 1984 1129-PDT (Thursday)
From:      Thomas Hutton <[email protected]>
To:        [email protected]
Subject:   Addition to mailing list
Could you please add my name to the distribution list for the
mailing group tcp-ip.

Tom Hutton
[email protected]	{internet}
ucbvax!sdcsvax!hutton	{uucp}


END OF DOCUMENT