The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Apr 86 08:24 EST
From:      JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA
To:        tcp-ip@sri-nic.ARPA, johnson%northeastern.csnet@CSNET-RELAY.ARPA
Subject:   Concerning unused options in IP packets.
     I'm just learning tcp/ip myself.  In reading rfc 791, I found the
following general statement in section 3.2: 

     "In general an [IP] implementation must be conservative in its 
sending behavior, and liberal in its receiving behavior."

     Concerning assumptions about IP packet option formats this seems
like a VERY good idea.  To protect one's own system, one should hope for
good input but expect problems with incoming packets.  In general I've
found this to be the best way with most software.  Yes it's more work
and on some systems it can be very difficult.  However, covering your
tail pointer is usually a good idea.  It can be very embarrassing to
have your wonderful, totally cosmic piece of software crash in public. 
It's even more embarrassing when a real-time system like network goes
down because you drop packets on the floor and then have to get a broom
and a bucket to clean things up.  At the speeds and traffic level of
some parts of the network, the mess can get really big FAST. 

     I don't know about anyone else but I don't think I'd assume
anything about what options look like in a packet.  We all know what
happens when assumptions are made. 

Chris Johnson
Sr System Programmer
Northeastern University
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Apr 86 9:10:13 EST
From:      Terry Slattery <tcs@USNA.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   host.txt
I use host.txt frequently to look up hosts which I know to be on the
net and don't know their official names (or even a hit of their name
other than the organization name).  I have gone as far as to create
a simple script to match patterns in the host tables so that users
here can quickly look to see if they can find out the name of
the host(s) at other sites on DDN.  If (when?) host.txt goes
away, I would hope that there would be a counterpart to 'whois'
for polling the servers about potential host names.  Pattern
matching is important because I also use this script to look up
all hosts attached to particular sub-nets or imps.  It helps me
get an idea of the route my data is or will be taking to get
to a particular host.
	-tcs

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Apr 86 16:37:25 EST
From:      Mike Muuss <mike@BRL.ARPA>
To:        Murray.pa@xerox.com
Cc:        TCP-IP@sri-nic.arpa, Murray.pa@xerox.com, JLarson.pa@xerox.com
Subject:   Re:  Anybody normally send packets with unused options?
I recall a comment from the Cray TCP people that they use empty option
bytes to word-align their data areas in the packets.  I suspect that
on machines with a strong word-alignment preference, this practice
will be increasingly popular.
	-Mike
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 86 19:55 PST
From:      Jeff Makey <Makey@LOGICON.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Cc:        Makey@LOGICON.ARPA
Subject:   ICMP Redirect Wars
Every now and then, two or three of the ARPANET<->MILNET gateways will
get into an ICMP Redirect argument over who should be handling one of
my connections.  Below is the latest example of this behavior, taken
from my April 1 TCP/IP daemon log (this happened before April Fools
day, too).

Redirect 10.0.0.44 (code 0) to 26.2.0.49 (from 26.2.0.73 at 16:11:36)
Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.2.0.49 at 16:11:38)
Redirect 10.0.0.44 (code 0) to 26.2.0.49 (from 26.2.0.73 at 16:11:43)
Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.2.0.49 at 16:11:44)
Redirect 10.0.0.44 (code 0) to 26.2.0.49 (from 26.2.0.73 at 16:11:45)
Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.2.0.49 at 16:11:49)
Redirect 10.0.0.44 (code 0) to 26.2.0.49 (from 26.2.0.73 at 16:11:53)
Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.2.0.49 at 16:11:57)
Redirect 10.0.0.44 (code 0) to 26.2.0.49 (from 26.2.0.73 at 16:11:59)
Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.2.0.49 at 16:12:02)
Redirect 10.0.0.44 (code 0) to 26.0.0.104 (from 26.2.0.73 at 16:16:05)
Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.0.0.104 at 16:16:06)

Notes: All times are Pacific Standard Time (HH:MM:SS).
       Code 0 means "Redirect datagrams for the Network" [RFC 792].
       10.0.0.44 is XX.LCS.MIT.EDU.
       26.2.0.73 is SRI-MILNET-GW.ARPA (my host's assigned ARPANET<->
            MILNET gateway [DDN Mgt Bulletin #23]).
       26.2.0.49 is BBN-MILNET-GW.ARPA.
       26.0.0.104 is DCEC-MILNET-GW.ARPA.
       It was a TCP/SMTP connection sending from XX.LCS.MIT.EDU to
            LOGICON.ARPA (26.2.0.3).  I don't know exactly when the
            connection was established, but we received the SMTP DATA
            command at 16:12:15 and the last of 10868 bytes trickled
            in at 16:17:07 (for an average of 37.2 bytes per second).
            (The piece of mail was Arms-Discussion digest V6 #69.)

An occasional redirect is fine, but this whipsawing back and forth
can't be good for anybody (due to the ICMP overhead).  Is this sort of
behavior just a symptom of the poor ARPANET<->MILNET performance or
does it contribute to the problem?

                        :: Jeff Makey
                           Makey@LOGICON.ARPA

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 1986 22:16:48 EST
From:      MILLS@USC-ISID.ARPA
To:        mike@BRL.ARPA, Murray.pa@XEROX.COM
Cc:        TCP-IP@SRI-NIC.ARPA, JLarson.pa@XEROX.COM, MILLS@USC-ISID.ARPA
Subject:   Re:  Anybody normally send packets with unused options?
In response to the message sent      Tue, 1 Apr 86 16:37:25 EST from mike@BRL.ARPA

Mike,

Cray may save a nanosecond or two when constructing a packet to send, but
it sure doesn't help when receiving a packet. The practice may be getting
popular as you say, but it's broken. Our Internet Toolbook should include
a chapter on how to compute checksums in wonderfully wierd ways for
TOPS-20s, Multices, Univax and Borroughs, not to mention a 7090 and
anything else with oddly sized words.

Dave
-------
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 1986 07:55:53 PST
From:      Dan Lynch <LYNCH@USC-ISIB.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        LYNCH@USC-ISIB.ARPA
Subject:   Diabolically Execrable?

Ddoes anyone out there think that the recent performance of Milnet/Arpanet
is simply a test of the robustness of the protocols involved?/

If so, then  you could tell the authorities that the data arrived
intact and in order, but the need for it vanished before it arrived.

Dan

PS.  It only took me 30 minutes to compose this, Noel.  Maybe things
are improving???
-------
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Apr 86 09:36 EST
From:      Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   FTP protocol violations

Folks,

4.2BSD replies with 200 to DELE rather than 250.  

If being permissive about what one accepts means accepting this, should
I make my implementation ignore the second two digits of positive
responses to simple model commands?  I can't see taking too and 250 and
no other 2xy's.




-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 1986 16:23-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        DCP@SCRC-QUABBIN.ARPA
Cc:        romkey@MIT-BORAX.ARPA, Margulies@SCRC-YUKON.ARPA tcp-ip@SRI-NIC.ARPA
Subject:   Re: FTP protocol violations
The  robustness  principle  says  that  you  accept anything that
works, but you do the right thing for anything you put out.  John
is  perfectly  correct in accepting wierd responses if he can get
it to work.  On the other hand, the 4.2 implementation  is  WRONG
and should be fixed post haste.

For  those  of  you  on  the MILNET side of the house, there will
eventually be  a  suite  of  protocl  certifiers  including  FTP.
(Please,  no  inquiries,  I've  told  you all I know) Each milnet
system will eventually have to toe the line.

Mike
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Apr 86 14:15:37 est
From:      romkey@BORAX.LCS.MIT.EDU (John Romkey)
To:        Margulies@SCRC-YUKON.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   FTP protocol violations
   Date: Wed, 2 Apr 86 09:36 EST
   From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>

   If being permissive about what one accepts means accepting this, should
   I make my implementation ignore the second two digits of positive
   responses to simple model commands?  I can't see taking too and 250 and
   no other 2xy's.

That's the way my IBM PC FTP does it. The command state machine is
just driven by the first digit. The other two digits can be used to
get more information, but unless I've missed something somewhere,
you can safely ignore them in deciding whether or not a command
succeeded, or what to do next.
						- john romkey	
						  ftp software
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Apr 86 17:06 EST
From:      David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
To:        John Romkey <romkey@BORAX.LCS.MIT.EDU>, Margulies@SCRC-YUKON.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   FTP protocol violations
    Date: Wed, 2 Apr 86 14:15:37 est
    From: romkey@BORAX.LCS.MIT.EDU (John Romkey)

       Date: Wed, 2 Apr 86 09:36 EST
       From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>

       If being permissive about what one accepts means accepting this, should
       I make my implementation ignore the second two digits of positive
       responses to simple model commands?  I can't see taking too and 250 and
       no other 2xy's.

    That's the way my IBM PC FTP does it. The command state machine is
    just driven by the first digit. The other two digits can be used to
    get more information, but unless I've missed something somewhere,
    you can safely ignore them in deciding whether or not a command
    succeeded, or what to do next.
						    - john romkey	
						      ftp software

Wait a minute.  A spec is a spec.  What's the point of the two digits if
(a) some hosts send the wrong ones, and (b) some hosts don't bother to
look at them.  If the spec said you could be lazy, then it would be OK.
If the spec doesn't, an implementation is INCORRECT if it sends the
wrong codes and an implementation is ASKING FOR TROUBLE if it accepts
more than what the spec says.

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Apr 86 17:37:01 est
From:      romkey@BORAX.LCS.MIT.EDU (John Romkey)
To:        DCP@SCRC-QUABBIN.ARPA
Cc:        Margulies@SCRC-YUKON.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   more FTP protocol violations
   Date: Wed, 2 Apr 86 17:06 EST
   From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>

       Date: Wed, 2 Apr 86 14:15:37 est
       From: romkey@BORAX.LCS.MIT.EDU (John Romkey)

	  Date: Wed, 2 Apr 86 09:36 EST
	  From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>

	  .....

       .....

   Wait a minute.  A spec is a spec.  What's the point of the two digits if
   (a) some hosts send the wrong ones, and (b) some hosts don't bother to
   look at them.  If the spec said you could be lazy, then it would be OK.
   If the spec doesn't, an implementation is INCORRECT if it sends the
   wrong codes and an implementation is ASKING FOR TROUBLE if it accepts
   more than what the spec says.

I probably should've just done this the first time, but I had to go
reread the spec to be sure. From RFC 959, last paragraph of page 36:

     "The three digits of the reply each have a special significance.
      This is intended to allow a range of very simple to very
      sophisticated responses by the user-process.  The first digit
      denotes whether the response is good, bad or incomplete.
      (Referring to the state diagram), an unsophisticated user-process
      will be able to determine its next action (proceed as planned,
      redo, retrench, etc.) by simply examining this first digit.  A
      user-process that wants to know approximately what kind of error
      occurred (e.g. file system error, command syntax error) may
      examine the second digit, reserving the third digit for the finest
      gradation of information (e.g., RNTO command without a preceding
      RNFR)."

And Section 6 presents some simple state machines for commands, using
only the first digit of the code to drive them. So we can be lazy if
we want to.

It makes sense to me to have an error indication (first digit) and
then a more specific error code (second digit), but it doesn't seem to
me that we should really have to worry about "what kind of success"
happened when there was no error, which is what the original question
was about (4.2 returning a strange success code). So I think most user
implementations can probably ignore the second and third digits in the
case of success.

Of course, if there is a "standard" response (250) to send in the case of
success, a server should probably send that instead of something else
that's similar but not quite the same (200). Appendix II of RFC959
says that the correct success response to a DELE is 250.
					- john
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Apr 86 17:44 EST
From:      David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
To:        John Romkey <romkey@BORAX.LCS.MIT.EDU>, DCP@SCRC-QUABBIN.ARPA
Cc:        Margulies@SCRC-YUKON.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   more FTP protocol violations
    Date: Wed, 2 Apr 86 17:37:01 est
    From: romkey@BORAX.LCS.MIT.EDU (John Romkey)

       Date: Wed, 2 Apr 86 17:06 EST
       From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>

	   Date: Wed, 2 Apr 86 14:15:37 est
	   From: romkey@BORAX.LCS.MIT.EDU (John Romkey)

	      Date: Wed, 2 Apr 86 09:36 EST
	      From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>

	      .....

	   .....

       Wait a minute.  A spec is a spec.  What's the point of the two digits if
       (a) some hosts send the wrong ones, and (b) some hosts don't bother to
       look at them.  If the spec said you could be lazy, then it would be OK.
       If the spec doesn't, an implementation is INCORRECT if it sends the
       wrong codes and an implementation is ASKING FOR TROUBLE if it accepts
       more than what the spec says.

    I probably should've just done this the first time, but I had to go
    reread the spec to be sure. From RFC 959, last paragraph of page 36:

	 "The three digits of the reply each have a special significance.
	  This is intended to allow a range of very simple to very
	  sophisticated responses by the user-process.  The first digit
	  denotes whether the response is good, bad or incomplete.
	  (Referring to the state diagram), an unsophisticated user-process
	  will be able to determine its next action (proceed as planned,
	  redo, retrench, etc.) by simply examining this first digit.  A
	  user-process that wants to know approximately what kind of error
	  occurred (e.g. file system error, command syntax error) may
	  examine the second digit, reserving the third digit for the finest
	  gradation of information (e.g., RNTO command without a preceding
	  RNFR)."

    And Section 6 presents some simple state machines for commands, using
    only the first digit of the code to drive them. So we can be lazy if
    we want to.

    It makes sense to me to have an error indication (first digit) and
    then a more specific error code (second digit), but it doesn't seem to
    me that we should really have to worry about "what kind of success"
    happened when there was no error, which is what the original question
    was about (4.2 returning a strange success code). So I think most user
    implementations can probably ignore the second and third digits in the
    case of success.

OK, that takes care of the user end; user ends are allowed to be lazy.

    Of course, if there is a "standard" response (250) to send in the case of
    success, a server should probably send that instead of something else
    that's similar but not quite the same (200). Appendix II of RFC959
    says that the correct success response to a DELE is 250.

Several (all?) Unix server implementations send 200.  This is NOT the
correct response, and I think a user program that does look at all three
digits is allowed to consider this a protocol violation.

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Apr 86 07:29 EST
From:      Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>
To:        David C. Plummer <DCP@SCRC-QUABBIN.ARPA>, John Romkey <romkey@BORAX.LCS.MIT.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   FTP protocol violations
    Date: Wed, 2 Apr 86 17:06 EST
    From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>

	Date: Wed, 2 Apr 86 14:15:37 est
	From: romkey@BORAX.LCS.MIT.EDU (John Romkey)

	   Date: Wed, 2 Apr 86 09:36 EST
	   From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>

	   If being permissive about what one accepts means accepting this, should
	   I make my implementation ignore the second two digits of positive
	   responses to simple model commands?  I can't see taking too and 250 and
	   no other 2xy's.

	That's the way my IBM PC FTP does it. The command state machine is
	just driven by the first digit. The other two digits can be used to
	get more information, but unless I've missed something somewhere,
	you can safely ignore them in deciding whether or not a command
	succeeded, or what to do next.
							- john romkey	
							  ftp software

    Wait a minute.  A spec is a spec.  What's the point of the two digits if
    (a) some hosts send the wrong ones, and (b) some hosts don't bother to
    look at them.  If the spec said you could be lazy, then it would be OK.
    If the spec doesn't, an implementation is INCORRECT if it sends the
    wrong codes and an implementation is ASKING FOR TROUBLE if it accepts
    more than what the spec says.

I would point out that the general princible: `be precise in what you
send, be forgiving in what you receive' has been stated many times for
the internet protocol set.  FTP, however, nowhere says that the
implication of this is to just look at the first digit.  What are the
chances of a clarification from on-high?

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Apr 86 07:48 EST
From:      Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>
To:        John Romkey <romkey@BORAX.LCS.MIT.EDU>, DCP@SCRC-QUABBIN.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   more FTP protocol violations
    Date: Wed, 2 Apr 86 17:37:01 est
    From: romkey@BORAX.LCS.MIT.EDU (John Romkey)

       Date: Wed, 2 Apr 86 17:06 EST
       From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>

	   Date: Wed, 2 Apr 86 14:15:37 est
	   From: romkey@BORAX.LCS.MIT.EDU (John Romkey)

	      Date: Wed, 2 Apr 86 09:36 EST
	      From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>

	      .....

	   .....

       Wait a minute.  A spec is a spec.  What's the point of the two digits if
       (a) some hosts send the wrong ones, and (b) some hosts don't bother to
       look at them.  If the spec said you could be lazy, then it would be OK.
       If the spec doesn't, an implementation is INCORRECT if it sends the
       wrong codes and an implementation is ASKING FOR TROUBLE if it accepts
       more than what the spec says.

    I probably should've just done this the first time, but I had to go
    reread the spec to be sure. From RFC 959, last paragraph of page 36:

	 "The three digits of the reply each have a special significance.
	  This is intended to allow a range of very simple to very
	  sophisticated responses by the user-process.  The first digit
	  denotes whether the response is good, bad or incomplete.
	  (Referring to the state diagram), an unsophisticated user-process
	  will be able to determine its next action (proceed as planned,
	  redo, retrench, etc.) by simply examining this first digit.  A
	  user-process that wants to know approximately what kind of error
	  occurred (e.g. file system error, command syntax error) may
	  examine the second digit, reserving the third digit for the finest
	  gradation of information (e.g., RNTO command without a preceding
	  RNFR)."

    And Section 6 presents some simple state machines for commands, using
    only the first digit of the code to drive them. So we can be lazy if
    we want to.

    It makes sense to me to have an error indication (first digit) and
    then a more specific error code (second digit), but it doesn't seem to
    me that we should really have to worry about "what kind of success"
    happened when there was no error, which is what the original question
    was about (4.2 returning a strange success code). So I think most user
    implementations can probably ignore the second and third digits in the
    case of success.

    Of course, if there is a "standard" response (250) to send in the case of
    success, a server should probably send that instead of something else
    that's similar but not quite the same (200). Appendix II of RFC959
    says that the correct success response to a DELE is 250.
					    - john

I wish that someone at the NIC would mark old RFC files old.  I was
reading 765 ...

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Apr 86 07:50 EST
From:      Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>
To:        David C. Plummer <DCP@SCRC-QUABBIN.ARPA>, John Romkey <romkey@BORAX.LCS.MIT.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   more FTP protocol violations
    Date: Wed, 2 Apr 86 17:44 EST
    From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>

	Date: Wed, 2 Apr 86 17:37:01 est
	From: romkey@BORAX.LCS.MIT.EDU (John Romkey)

	   Date: Wed, 2 Apr 86 17:06 EST
	   From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>

	       Date: Wed, 2 Apr 86 14:15:37 est
	       From: romkey@BORAX.LCS.MIT.EDU (John Romkey)

		  Date: Wed, 2 Apr 86 09:36 EST
		  From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>

		  .....

	       .....

	   Wait a minute.  A spec is a spec.  What's the point of the two digits if
	   (a) some hosts send the wrong ones, and (b) some hosts don't bother to
	   look at them.  If the spec said you could be lazy, then it would be OK.
	   If the spec doesn't, an implementation is INCORRECT if it sends the
	   wrong codes and an implementation is ASKING FOR TROUBLE if it accepts
	   more than what the spec says.

	I probably should've just done this the first time, but I had to go
	reread the spec to be sure. From RFC 959, last paragraph of page 36:

	     "The three digits of the reply each have a special significance.
	      This is intended to allow a range of very simple to very
	      sophisticated responses by the user-process.  The first digit
	      denotes whether the response is good, bad or incomplete.
	      (Referring to the state diagram), an unsophisticated user-process
	      will be able to determine its next action (proceed as planned,
	      redo, retrench, etc.) by simply examining this first digit.  A
	      user-process that wants to know approximately what kind of error
	      occurred (e.g. file system error, command syntax error) may
	      examine the second digit, reserving the third digit for the finest
	      gradation of information (e.g., RNTO command without a preceding
	      RNFR)."

	And Section 6 presents some simple state machines for commands, using
	only the first digit of the code to drive them. So we can be lazy if
	we want to.

	It makes sense to me to have an error indication (first digit) and
	then a more specific error code (second digit), but it doesn't seem to
	me that we should really have to worry about "what kind of success"
	happened when there was no error, which is what the original question
	was about (4.2 returning a strange success code). So I think most user
	implementations can probably ignore the second and third digits in the
	case of success.

    OK, that takes care of the user end; user ends are allowed to be lazy.

	Of course, if there is a "standard" response (250) to send in the case of
	success, a server should probably send that instead of something else
	that's similar but not quite the same (200). Appendix II of RFC959
	says that the correct success response to a DELE is 250.

    Several (all?) Unix server implementations send 200.  This is NOT the
    correct response, and I think a user program that does look at all three
    digits is allowed to consider this a protocol violation.

I disagree. The paragraph above says clearly that the basic response
semantics are implied by the first digit.  It seems to me that the spec
should be revised to state that for success the later two digits are
unimportant.

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Apr 86 11:29:18 PST
From:      gds@sri-spam.ARPA (Greg Skinner)
To:        tcp-ip@sri-nic.ARPA
Subject:   Re:  more FTP protocol violations
I don't have a copy of RFC959 handy, but here's an interesting paragraph
from RFC765 on the sequencing of commands and replies.

   The table below lists alternative success and failure replies for
   each command.  These must be *strictly* (emphasis mine) adhered to; a
   server may substitute text in the replies, but the meaning and action
   implied by the code numbers and by the specific command reply
   sequence cannot be altered.

And, in the sequence for DELE

   DELE, CWD
      250
      450, 550
      500, 501, 502, 421, 530

So it would seem (at least to implementors of RFC765 FTP) that the
burden of protocol correctness is on the server end.  If I'm not
mistaken 4.2bsd FTP was written sometime afterwards with all the X
commands, which may account for the fact that it didn't conform to
RFC765.

   From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>

   Several (all?) Unix server implementations send 200.  This is NOT the
   correct response, and I think a user program that does look at all three
   digits is allowed to consider this a protocol violation.

Well, not all.  I wrote an FTP server for a pdp11 v6 Unix once that
returned 250 for a successful delete.  RFC765 seems to suggest that a
user FTP implement a FSM to interpret server replies, rather than match
on the replies themselves.  Considering the fact that the requested
action is completed, independent of whether or not the response from the
DELE indicates so, it seems to be a bit nitpicky to require an exact
interpretation of the successful reply to a DELE, and also bothersome
for a user FTP to match exactly on its response.  (Does anyone out there
actually examine for the grade of success?)  But, of course, one should
be conservative in what one sends, etc.

--gregbo

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Thu 3 Apr 86 12:18:31-PST
From:      Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA>
To:        Margulies@SCRC-YUKON.ARPA
Cc:        romkey@MIT-BORAX.ARPA, DCP@SCRC-QUABBIN.ARPA, tcp-ip@SRI-NIC.ARPA, OLE@SRI-NIC.ARPA
Subject:   Re: more FTP protocol violations
Folks,
		The way to find the current version of any given RFC is to look
in [SRI-NIC.ARPA]RFC:RFC-INDEX.TXT. In this file you will find the 
phrase: "Obsoletes RFC xxx" in the entry for the new one. I'll look
into making this a two-way street so that RFC-765 would be marked 
"Obsoleted by RFC-959".

Cheers,

	Ole
-------
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Apr 86 09:59:36 EST
From:      Chris Torek <chris@gyre.umd.edu>
To:        DCP@scrc-quabbin.ARPA, Margulies@scrc-yukon.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re:  FTP protocol violations
Instead of complaining about the broken 4.x ftp server, I thought
it more useful to provide the fix.  Here it is.  Feel free to give
it to anyone whose server is still wrong.

Chris

RCS file: RCS/ftpd.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -c -r1.1 -r1.2
*** /tmp/,RCSt1003149	Thu Apr  3 09:58:20 1986
--- /tmp/,RCSt2003149	Thu Apr  3 09:58:23 1986
***************
*** 559,565 ****
  ack(s)
  	char *s;
  {
! 	reply(200, "%s command okay.", s);
  }
  
  nack(s)
--- 559,565 ----
  ack(s)
  	char *s;
  {
! 	reply(250, "%s command okay.", s);
  }
  
  nack(s)
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 1986 1406-PST (Thursday)
From:      johnsson@decwrl.DEC.COM (Richard Johnsson)
To:        tcp-ip@sri-nic.ARPA
Subject:   Core gateway slot problem
Has the problem of running out of Core gateway slots for connected
networks suddenly gotten worse? Our network (128.45.0) seems to be
going in and out (mostly out today) although our EGP process has been
running continuously for the last three days. In the past my experience
has been that once we got a slot we kept it until our gateway crashed.

Richard
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 1986 14:45-PST
From:      Rafael Bracho <spar!rxb@decwrl.dec.com>
To:        tcp-ip@ucbvax.berkeley.edu
Subject:   Please post in tcp-ip groups
Could you please post this message? Thanks.

===============
Subject: Arpanet/Ethernet gateway needed.
Reply-To: rxb@spar.UUCP (Rafael Bracho)
Distribution: net
Organization: Schlumberger Palo Alto Research
Keywords: tcp-ip, arpanet, gateways, HDH, 1822-J

I need some advise from arpanet wizards:

We just got our arpanet port assigned and are in the process of putting
together an arpanet/ethernet gateway.  We have an HDH port (1822-J) which
pretty much limits us to the ACC IF-11/HDH board (is this correct?), a Unibus
board with HDH normally downloaded into it.  We'd like something with
reasonable performance, we are getting 56kb DDS between our computer room and
the IMP.

Could anyone tell me what is the hardware I should buy? Which software can I
get to run on it? Is there anyone out in net-land that has an HDH port and
an arpanet/ethernet gateway?

Help is most appreciated.

					Rafael Bracho
					Schlumberger Palo Alto Research
					415-496-4644
					BRACHO@SRI-KL.ARPA
					...{decwrl,hplabs}!spar!rxb

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 86 16:33:00 PST
From:      <gary@acc.arpa>
To:        "garry%cadif-oak" <garry%cadif-oak@cornell>
Cc:        tcp-ip@sri-nic
Subject:   tcp for AT&T
Garry,

Wollongong has a contract with AT&T IS to supply TCP/IP for all levels
of 3B's.  This is bing coordinated by Computer Systems Division in Lisle.
AT&T plans to offer the package as a supported product from them.

ACC has a contract also with AT&T to supply 3B - 1822 interfaces for
all of the 3B's.  We have delivered the initial prototype units to
AT&T and will be supplying the production units this month.

Our development plans call for supporting a DDN X.25 interface sometime
in the future for the 3B's as well.

Please contact me direct about your specific application.

Email:  gary@ACC.ARPA
Telephone:  805-963-9431

Regards,

Gary Krall
------
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      03 APR 86 16:13:06
From:      {ATE.R/CHESTNUT}ONTYME@OFFICE-1
To:        tcp-ip@sri-nic.arpa
Subject:   Removal from distribution list
Please remove me (RC.TYM@OFFICE-1) from the TCP-IP distribution list. The 
material has a slant somewhat different from what I had expected.

Thank you.

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Apr 86 17:54:34 EST
From:      garry@batcomputer.tn.cornell.edu (Garry Wiegand)
To:        arpa.tcp-ip
Subject:   tcp for an AT&T 3b20 (got one?)
We've great big AT&T 3b20 (n o t the same as a 3b2!) standing around here 
lookin' dumb. Reason she's dumb (and deaf) is she only speaks "3b" protocol 
(whatever that may be) on the ethernet.

Anybody have/heard of tcp implemented on this beast? 

garry wiegand         garry%cadif-oak@cu-arpa.cs.cornell.edu
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Thu,  3 Apr 86 21:17:27 EST
From:      "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
To:        dcp@SCRC-STONY-BROOK.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   FTP specs and conventions
One thing I wondered about is why the Symbolics FTP server
responds to the LIST and NLST commands with exactly the same data?
Was there a reason for leaving out the usual data like creation
dates and sizes and such?

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Fri 4 Apr 86 01:42:47-MST
From:      Mark Crispin <MRC@SIMTEL20.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   nested replies, Milnet/ARPANET performance
Folks -

     I'm sort of annoyed by the style of replies which include the
message being replied to in the reply.  It gets rather tedious quite
quickly.  Can we all make an effort not to do this?  It's much better
to write a reply that makes the context of the message obvious than
to write one that has 5 or 6 new text lines in a 100+ line message...

     I've complained about the Milnet/ARPANET performance for over a
year now.  In the SF Bay Area the local ARPANET TAC is 300 baud only,
so most of us haven't even bothered getting an ARPANET TAC ID.  This
is alright since there are lots of ARPANET hosts (Stanford, SRI)
around here for ARPANET access.  But the SRI Milnet TAC is the only one
with dialups, and it gets heavy usage.  If the TAC is busy or in
catatonic mode (a distressingly common occurance) I find myself cut off
from Milnet.  It has been impossible to do serious heavy-duty editing,
real-time debugging, or any of the other software development tasks I
do here if I have to go through the Milnet/ARPANET gateways, and it's
been that way for over a year.

     I'll grant that Telnet between ARPANET and Milnet is an abuse of
the gateways, but given the totally inadequate Milnet access around
here the choices narrow down to that or being cut off.  Actually there
isn't a choice now; if the Milnet TAC is down we are effectively cut
off from Milnet.

     I question the wisdom of maintaining the Milnet and ARPANET as
discreet networks.  From what I can tell the perceived need for the
split has evaporated.  There must be a lot of unnecessary trunk
duplication, not to mention all that gateway traffic which would go
away if we rejoined Milnet and ARPANET into a single net.  How about
it, DCA?

-- Mark -- trying to do production work on two production nets, neither
	   of which are producing very good results...
-------
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Fri 4 Apr 86 00:14:07-EST
From:      Ken Rossman <sy.Ken@CU20B.COLUMBIA.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Core gateway slot problem
  Has the problem of running out of Core gateway slots for connected
  networks suddenly gotten worse? Our network (128.45.0) seems to be going
  in and out (mostly out today) although our EGP process has been running
  continuously for the last three days. In the past my experience has been
  that once we got a slot we kept it until our gateway crashed.

We've been having lots of trouble from our network lately also (128.59).
Tons of mail is piling up here.  /Ken
-------
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Apr 86 8:18:46 EST
From:      Ron Natalie <ron@BRL.ARPA>
To:        Richard Johnsson <johnsson@decwrl.dec.com>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  Core gateway slot problem
Actually, I've noted a strange phenomena which I don't think is slot
related.  Periodically the a Reachability message is sent with a fewer
number of nets but all pointed to a single (but different than usual)
gateway.  Any one else see this.

(By the way, I haven't seen the GGP counting to infinity artifact showing
up in EGP messages recently, so I guess that's been fixed).

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 86 11:50 PST
From:      Jeff Makey <Makey@LOGICON.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Cc:        Makey@LOGICON.ARPA
Subject:   Re: Core gateway slot problem
On April 3, at 16:31:56, 18:01:31, and 20:01:24 PST our SMTP server
received SYNs from CU20B.COLUMBIA.EDU (128.59.32.128) but was unable to
respond, being informed by SRI-MILNET-GW.ARPA (via ICMP) that the
destination net was unreachable.  (LOGICON.ARPA is on the MILNET, so we
must go through the ARPANET to get to CU-NET.)

Why is it that CU20B can send packets to LOGICON, but sometimes we
can't send to them?

We finally did complete a connection at 22:39:07 PST.  Also, we have
had this type of problem much more frequently with RED.RUTGERS.EDU
(128.6.4.2), whose internet gateway is also on the ARPANET.

                      :: Jeff Makey
                         Makey@LOGICON.ARPA

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Apr 86 10:19 EST
From:      David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
To:        George J. Carrette <GJC@MC.LCS.MIT.EDU>, dcp@SCRC-STONY-BROOK.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   FTP specs and conventions
    Date: Thu,  3 Apr 86 21:17:27 EST
    From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>

    One thing I wondered about is why the Symbolics FTP server
    responds to the LIST and NLST commands with exactly the same data?
    Was there a reason for leaving out the usual data like creation
    dates and sizes and such?

Because the code for :LIST says
	  ;; Some day do better than this.
and then calls the NLST code.  Thanks for pointing this out.

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      04 Apr 86 11:02:06 EST (Fri)
From:      Mike Brescia <brescia@BBNCCV.ARPA>
To:        Ron Natalie <ron@brl.ARPA>
Cc:        Richard Johnsson <johnsson@decwrl.dec.COM>, tcp-ip@sri-nic.ARPA
Subject:   reissue: Core gateway routing bug found
I do not recall seeing a copy of this message returned from NIC.  Thursday,
April 3  is the first full day which should show sanity in the routing.

	Mike 

--- copy etc. ---

To: tcp-ip@BBNCCV.ARPA
Subject: Core gateway routing bug
Date: 02 Apr 86 14:21:09 EST (Wed)
From: tmallory@BBNCCV.ARPA

A bug in the routing code of the LSI-11 gateway software has been
isolated which is responsible for most of the problems experienced
by users of the core gateways for either routing or packet transmission.
The bug caused oscillating routing and added greatly to the amount of
overhead traffic associated with routing, contributing to congestion on
the Arpanet and Milnet.

We have started patching all of the core gateways.  This will take some
time, though we hope to have the initial pass complete sometime tomorrow.
It will take several days to update all of the load devices, so minor
problems may reappear as gateways with old binaries are reloaded during
the normal course of operations(power failures, etc.).

Thank you all for your patience,

Tracy Mallory
BBNCC
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Apr 86 11:50:16 EST
From:      Ra <root%bostonu.csnet@CSNET-RELAY.ARPA>
To:        security@red.rutgers.edu, tcp-ip@sri-nic.ARPA
Subject:   Thought on data encryption on networks

Most of us run networks that do not have any encryption facilities
(perhaps in theory, but not something a sys mgr can just turn on.)

The problem is that the minute someone says 'hey, we need some
encryption on this net' out come the macho data encryption types
to explain to you that the only encryptions worth doing are too
expensive (or complicated) to run, and then slink away again
leaving you defenseless. Worse, you usually end up sitting thru
a long scolding about how even if you implemented the best it
is probably about to be broken or illegal or something.

Oh, where is Arthur to slice this gordian knot? Meanwhile, Joe Cracker
plugs his PC into your net, goes into promiscuous mode and has the
most fun he can with his pants on.

How outlandish would it be to come up with (I am probably not
qualified to do this, although those that are probably won't)
some sort of reasonably hard to crack stream oriented protocol?
There has to be something in between clear text and you-need-
a-cray-ethernet-board-but-it-cant-be-cracked.

Suggestions? If your inclination is to say 'yer iggorant, this
is solved' then how come none of the major O/S's have put it
into their device drivers or wherever?

	-Barry Shein, Boston University
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 1986 13:29:09 EST
From:      MILLS@USC-ISID.ARPA
To:        sy.Ken@CU20B.COLUMBIA.EDU, tcp-ip@SRI-NIC.ARPA
Cc:        MILLS@USC-ISID.ARPA
Subject:   Re: Core gateway slot problem
In response to the message sent  Fri 4 Apr 86 00:14:07-EST from sy.Ken@CU20B.COLUMBIA.EDU

Ken,

I suspect BBN warriors may be too bloodied and weary to have announced
a damage report, so please treat the following as an unofficial summary.
When the core tables were expanded over 128 nets at least two bugs developed
which reesulted in broken, oscillating routes within the core system. The
problems then led to massive surges in gateway control traffic, as well as
massive surges in redirects, not to mention aimlessly wandering datagrams
carrying possibly useful user traffic. The situation became acute about
a week ago, since when BBN has been feverishly updating all the core gateways,
some of which are fiendishly hard to update (bubble memories, etc.). In the
last couple of days things have improved, which is a good sign.

The evidence is not hard to detect upon inspection of the EGP hop-count
fields received by your EGP peer. You may notice the gateways wandering
about the ARPANET or MILNET, as well as the high incidence of unusually
large hop counts, not to mention the incidence of nets bobbing up and down.

I have also noticed locally a marked increase in the incidence of ARPANET
host-down messages, which may be realted to gateway reloading and
the suspected traffic surges.

My personal, unsubstantiated suspiciion suspicion is that instabilities
in the core routing system due inconsistent tables (becasue of overflow) may have
contributed significantly to the recent deterioration in performance.

Dave
-------
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Fri 4 Apr 86 17:03:05-PST
From:      "RAJENDRA K JAIN" <jain@hudson.dec.com>
To:        "tcp-ip" <tcp-ip@sri-nic.ARPA>
Subject:   Timeout algorithms for packet retransmissions
Some time ago, there was a discussion of retransmission
timeout algorithms on this forum. To those still interested in the
topic I would like to point out that a survey of various algorithms
and their problems was published recently:

Jain Raj, "Divergence of Timeout Algorithms for Packet Retransmissions",
IEEE Phoenix Conference on Computer Communications, Phoenix, AZ,
March 27-28, 1986, pp. 174-179. 

The paper has 17 references to other papers on the subject. If you can't
find the proceedings in your local library, I would be happy 
to mail you a reprint. Please send your U. S. Mail address to 
Jain@Hudson.DEC.Com
*** Please do not directly reply to this message. ***

Regards.
-Raj Jain
------
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 1986 14:29:47 EST
From:      MILLS@USC-ISID.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Martians go home
Folks,

I just caught a beta-4.3bsd coughing up ICMP Source Quench and claiming
its address to be 127.0.0.1, but truly was on a net-128.5 subnet. This
is yet again evidence supporting the well-travelled axiom that says
to resist the urge to encroach on the net-address space as a substitute
for intra-host routing mechaniss. I would like to suggest that
a new net be conceived called DEAD-LETTER with net number 127.0. Volunteers
are invited to submit gateways to that net.

Dave
-------
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Apr 86 15:26:57 EST
From:      Mike Muuss <mike@BRL.ARPA>
To:        Ra <root%bostonu.csnet@csnet-relay.arpa>
Cc:        security@red.rutgers.edu, tcp-ip@sri-nic.arpa
Subject:   Re:  Thought on data encryption on networks
There are two levels of protection that you require:

*)  Link-level protection, to keep people from disrupting your local cable(s).

*)  End-to-End protection, to keep your conversation private even if
some (or all) of the cables that carry the conversation are not protected.

Link-level protection is a local issue -- if you can find a vendor who will
sell you, say, Ethernet cards with 10 Mbps DES encryption built in, you
could replace all the boards on your cable(s), and be protected.

End-to-end protection will only work if both ends are expecting it.
As there is presently no presentation level (ISO level 6) encryption
defined for the TCP protocol family, you won't be able to use this
very well.  (Let me encourage you to consider how to optionally
negotiate in end-to-end encryption on top of a TCP connection, and
write up an RFC!)  Also, note that this will probably have to be a
software implementation, so that it can be specified for, and added
to, all the existing TCP implementations.  This may have a performance
impact.

There is also the issue of key management, which in a relatively static
system like the DARPA Internet (as opposed to a tactical network) is
fairly easy to implement (tedious, but possible).

Note that for the military community, the BLACKER system addresses the
end-to-end needs, as well as the key management issues.  Link-level
encryption is still the responsiblity of the individual link managers.

	-Mike

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 1986 16:29-CST
From:      SNELSON@STL-HOST1.ARPA
To:        TCP-IP@SRI-NIC.ARPA
Cc:        SNELSON@STL-HOST1.ARPA
Subject:   THOUGHT ON DATA ENCRYPTION ON NETWORKS
MIKE MUUSS THOUGHTS IN REPLY TO MKE BRESCIA ARE AS SUCCINCT AS THEY
CAN GET. I AGREE. I HAVE BEEN USING THE HERMES MAIL ENCRYTION FEATURE
FOR A LONG TIME AND IT ASSURES THE PRIVACY I DESIRE. I THINK THE
DECISION MAKERS ARE GOING TO HAVE TO DEFINE THE DIFFERENCE BETWEEN
INDIVIDUAL PRIVACY AND SECURITY OF INFORMATION. IT IS THE SAME OLD
STORY. MANAGEMENT HAS TO DECIDE WHAT NEEDS PROTECTION, WHAT IS NICE
TO HAVE AND WHAT DOESNT MEAN ZILCH.

STEVE

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Sun,  6 Apr 86 09:23:19 EST
From:      "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
To:        root%bostonu.csnet@CSNET-RELAY.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, security@RED.RUTGERS.EDU
Subject:   DADA & Encryption
There is a very simple and cheap encryption method that is also the
only one known to be impossible to break. That is a one-time-key
method.  I have been using this by putting it into the applications
such as FTP right at the places that streams are opened. The practical
restriction of a one-time-key method is that you must generate a tape
(or other secure medium) of enough random bytes and then send it by a
trusted person to the machine you want to send messages to. Then, each
time you send a byte to the other host XOR it with one from your
key-tape. If you never repeat your key then nobody will be able to
break the code except by stealing the key. If what you want to
encrypt is mail traffic then a 1 gigabyte video disk would probably
do for a quite a few months before you have to make and send another
one. 

On the other hand, with a key as long as a gigabyte you could risk
repeating it because a spy would have to be listening for quite a while
to catch a repeat key, so it would take care of a random with an IBM-PC
Unless of course he also had a gigabyte of video disk to write to
in real time over the course of a few months.


-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Sun,  6 Apr 86 09:35:41 EST
From:      "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
To:        DCP@SCRC-QUABBIN.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, dcp@SCRC-STONY-BROOK.ARPA
Subject:   FTP specs and conventions, LIST command
Of course it is extremely unfortunate that there is no spec for the
format of the data in the LIST command. If only there was an RFC for
a more reasonable file access protocol...

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 86 18:54:48 EST
From:      Charles Hedrick <HEDRICK@RED.RUTGERS.EDU>
To:        Makey@LOGICON.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Core gateway slot problem
Asymmetry in routing is quite easy to occur.  In order to send a
packet from us to you, we have to know about our own local gateway, and
our local gateway has to know about some Arpanet/Milnet gateway.  We
always know about our local gateway (it is hardwired in our routing
table), and I am fairly sure our gateway always knows about one of the
core gateways.  This means that we can always get packets to any host
that is directly connected to the Arpanet or Milnet.  In order to
respond, your host must know about an Arpanet/Milnet gateway and that
gateway must know about our local gateway.  Again, you probably always
know about some Arpanet/Milnet gateway.  Recently, due to various
bugs that have been discussed here enough, the Arpanet/Milnet gateways
have had a tendency to lose track of external gateways such as ours. The
result is that you can't get a packet back to us.  When the core
gateways lose track of us, we can often establish connections to
machines that are directly on the Arpanet by sending them redirects
pointing to our gateway.  We haven't been very successful in doing this
to sites behind a gateway.  (The fact that we can do it at all is, of
course, a security problem.  As far as I can tell, anybody on the
network can change around any 4.2 system's routing table in any way that
he wants.)

-------
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Apr 86 07:56:31 est
From:      Gavin Hemphill <hemphill@nrl-aic>
To:        tcp-ip@sri-nic
Cc:        drenet@drea-xx
Subject:   Performance Improvement?
Well whatever was done re fixing bugs in the core gateways HAS made
a difference.  The performace between MILNET and CDNNET via ARPANET
has NEVER been better than it has since the middle of last week.
I don't have any quantitative measurements (though someone with
more expertise might want to gather the stats), but the percieved
response to Telnet and FTP has been super
	G++
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Mon, 07 Apr 86 13:15:47 -0500
From:      /Steve Dyer <dyer@harvard.HARVARD.EDU>
To:        tcp-ip@sri-nic.ARPA
Subject:   Excelan TCP/IP boards for PC/ATs
Does anyone have any direct experience with the Excelan 205 ethernet
controllers and EXOS 8111 software for the IBM PC and AT?  I'm interested
in exploring ways to interconnect a bunch of PCs, some running XENIX,
others running DOS.  After exploring the market, it looks like Excelan
may be the only solution available right now, given that XENIX access is
necessary.
-- 
Steve Dyer
dyer@harvard.HARVARD.EDU
{bbncca,bbnccv,harvard,ima,ihnp4}!spdcc!dyer


-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Apr 86 11:44:20 est
From:      Gavin Hemphill <hemphill@nrl-aic>
To:        tcp-ip@sri-nic
Cc:        drenet@drea-xx
Subject:   ooops, I meant to say DRENET

   Date: Mon, 7 Apr 86 07:56:31 est
   From: Gavin Hemphill <hemphill@nrl-aic>

   Well whatever was done re fixing bugs in the core gateways HAS made
   a difference.  The performace between MILNET and DRENET
   (not CDNNET) via ARPANET
   has NEVER been better than it has since the middle of last week.
   I don't have any quantitative measurements (though someone with
   more expertise might want to gather the stats), but the percieved
   response to Telnet and FTP has been super
	   G++

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Mon, 07 Apr 86 19:48:31 -0500
From:      Gurudatta Parulkar <parulkar@dewey.udel.EDU>
To:        tcp-ip@dewey.udel.EDU
Subject:   Flooding

It seems that some kind of flooding was explored as routing strategy for 
ARPANET long back. But it never became popular. I would like to get some 
pointers to papers, reports, RFCs, etc. which talk about this flooding 
and also talk about why it was given up. Could somebody help me with 
these pointers ?

We at University of Delaware are exploring the possibility of using flooding 
in a LAN. Are there any other groups looking into such a possibility ? Please
send me a note.


Thank you very much.

-guru


:______________________________________________________________________________
:Gurudatta M. Parulkar
:University of Delaware
:Department of Computer and Information Sciences
:Newark, DE  19716
:
:ARPA: parulkar@dewey.udel.EDU
:CSNET: parulkar%dewey.udel.EDU@csnet-relay
:UUCP: ...!harvard!parulkar@dewey.udel.EDU
:______________________________________________________________________________



-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Apr 86 19:33:49 EST
From:      Mike Muuss <mike@BRL.ARPA>
To:        Gavin Hemphill <hemphill@nrl-aic.arpa>
Cc:        tcp-ip@sri-nic.arpa, drenet@drea-xx.arpa
Subject:   Re:  Performance Improvement?
I concur.  A quick test to Berkeley showed roughly 2 second RTT,
which is much better than before.  Not great, but usable.  Thanks!

From BRL-VGR:
----monet.berkeley.edu PING Statistics----
59 packets transmitted, 57 packets received, 3% packet loss
round-trip (ms)  min/avg/max = 1090/1953/5500

	-Mike
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Apr 86 20:03:10 EST
From:      Mike Muuss <mike@BRL.ARPA>
To:        PADLIPSKY@usc-isi.arpa
Cc:        TCP-IP@sri-nic.arpa
Subject:   Encrypt at which level?
Mike Padlipsky asked why I thought Level 6 was the right place to implement
encryption, and even though my answer is sketchy, I figured I'd share it
with everybody.

It seems to me that code translation, e2e encryption, and some sort of
standard data compression ought to be available as "protocol family"
services to *any* application, just for the asking.  At the right point in
the dialog (perhaps before the first data byte, perhaps after some initial
exchange), the user program should make some kind of call to the next lower
level interface and say "please begin encrypting with a key of XXX".

The exact implementation point of e2e encryption isn't REALLY important
though, as long as a good place for it in the protocol suite exists, and
most everybody can be made to agree to do it there.  It could be provided by
a library function, or as direct code within each application, or as an
operating system capability, I dont really care, but I feel that some basic
level of encryption should be available as a primitive capability.

It would be nice, for example, to consider an extention to the SMTP protocol
to go something like:

220 brl-sem Server SMTP (Complaints/bugs to:  mmdf@brl.arpa)
HELO brl-sem
250 brl-sem
CRYPT
250 encryption with our common key being enabled.
MAIL FROM:<mike@brl-sem>
250 OK

and thus have both the address and data portion encrypted (as an option).

TELNET IAC-DO-ENCRYPT etc etc might also be nice.

Government sites handling what used to be called "For Official Use Only
(FOUO)" data and researchers with unpublished data to exchange would
be the most likely candidates to desire this type of capability.

The key management issues would be a drag.  Host-pair, Group-pair, User-pair
basis, or what?  How to update?  What to do when the keys don't match?
Handling the user interface issues would also take thought and work, but
encryption is something that WOULD be useful to have.

How this fits together with Multi-Level Secure hosts interfacing to 
BLACKER isn't clear either.  The simple answer is:  "not at all -- BLACKER
is different", yet having BLACKERs protecting gateways to LANs *still*
does not handle the complete end-to-end requirement.  BLACKERs
protecting hosts would.  I need to think about this more.

	-Mike
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 1986 11:03-PST
From:      postel@usc-isib.arpa
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Flooding

The current IMP level routing procedure is basically a flooding
type algorithm.  Here are two references for further information.

--jon.

-----


McQuillan, J. M., I. Richer, E. Rosen

   "An Overview of the New Routing Algorithm for the Arpanet," 
   Proceedings of IEEE, Spring 1979.

   "The New Routing Algorithm for the ARPANET," IEEE Transactions on 
   Communications, May 1980, pp. 711-719.

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Apr 86 12:23:25 pst
From:      lekash@AMES-NAS.ARPA (John Lekashman)
To:        tcp-ip@sri-nic.ARPA
Subject:   clogged queues
We have a machine that is reading IP packets and occasionally
getting clogged with data, some for undefined addresses, some
for processes being slow.  It is on a LAN, (hyperchannel to
be precise.)

I'm looking for advice on which end of the queue to have the 
driver throw things away when its full.  Both cost the same.

					thanks
					john
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 86 12:40:00 PST
From:      <gary@acc.arpa>
To:        "hunt" <hunt@bbnccj>
Cc:        arpanetmgr@ddn1,tcp-ip@sri-nic
Subject:   alias...
Doug,

Who is the "Arpanet Program Manager" at the DDN PMO??  What group
does he/she fall into?

Thanks,

Gary
------
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Apr 86 9:41:31 EST
From:      Jim Berets <jberets@BBN-VAX.ARPA>
To:        Mike Muuss <mike@BRL.ARPA>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re:  Encrypt at which level?
Mike,

A little bit of looking through my file cabinet revealed
a "draft proposed ANSI standard for Presentation Layer
Encryption" dated April, 1984.  "The primary purpose ...
is to define the functional and procedural characteristics
of cryptographic operations ... on behalf of a requesting
application layer entity (End User)."

At the time, this standard was being developed under the
auspices of ANSI X3T1.  Interested parties could probably
obtain updated copies from ANSI.

Jim
<jberets@bbn-vax>
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 1986 1734-PST (Tuesday)
From:      Aki Shohara <shohara@sri-tsc.ARPA>
To:        se
Cc:        TCP-IP@SRI-NIC.ARPA, Makey@LOGICON.ARPA
Subject:   Re: Core gateway slot problem
This message erroneously routed to me.
aki shohara.
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Apr 86 9:01:19 BST
From:      Steve Kille <steve@ucl-cs.arpa>
To:        mike@brl.arpa
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Encrypt at which level?
I agree that for many cases, encypting at level 6 seems correct.
I note that the ISO presentation has hooks for this.   However,
this is not sufficient for store and forward services (or any
spooled service) such as mail.   Here, to obtain end to end
encryption, it will need to be at the application level.
Marshall Rose wrote a very good paper on the mail issues for
the Washington 85 IFIP 6.5 Symposium (published North Holland).
It also describes an implementation.


Steve

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Apr 86 15:14:44 EST
From:      Doug Hunt <hunt@bbnccj.ARPA>
To:        tcp-ip@sri-nic.arpa
Cc:        arpanetmgr@ddn1.arpa, hunt@bbnccj.arpa
Subject:   note on recent arpanet performance problem

	Status of Remedial Action for Arpanet Performance Problems

This note describes an Arpanet performance problem, together with the
steps being taken to correct it.  The discussion covers (1) the
symptoms, (2) an explanation of the problem, (3) the recommended
solution, and (4) a timetable for implementing the solution.  This note
concludes with a recommended procedure for reporting Arpanet performance
problems to the Arpanet Manager at the DDN Program Management Office.

The Symptoms

Basically, the Arpanet appears sluggish -- interactive as well as bulk
transfer traffic can be subjected to very large delays.  This can
manifest itself as an overflowing typeahead (input) buffer to a TAC, or
a file transfer that takes much longer than should be required for the
file size and data path bandwidths involved.

The Problem

The BBNCC Network Analysis Group considered a number of hypotheses that
could explain the sluggish network behavior.  They have found that much
of the performance degradation in the Arpanet can be traced to host
blocking owing to a lack of per-connection resources in PSNs.  This
blocking would exhibit the symptoms described above.

A host must have a PSN allocate to it certain resources in order to
establish and use a host-host network connection.  To establish the
connection, both the source and destination hosts must be allocated
"connection blocks" by their respective source and destination PSNs.
Having done so, to send a message a host must be allocated a "message
number".  The connection blocks and message numbers are resources
internal to the PSN; until a PSN allocates these resources to a host,
the host is blocked.  

Analysis of the Arpanet in recent months shows that, for many PSNs,
there is excessive blocking of attached hosts because of a shortage of
connection blocks.  Twelve PSNs in particular exhibit this problem
consistently.  These PSNs are: SRI2, RCC5, STAN11, DCEC20, ISI22, ISI27,
PURDU37, SRI51, LBL68, SAC80, BBN82, and WISC94.  Alleviating the
connection block shortage problem for these and other Arpanet PSNs
should provide a significant improvement in network performance as seen
by hosts.

The Solution

The PSN release used on the Arpanet, "Release 3/4", supports only 73
connection blocks in each direction -- enough to support 73 full-duplex
streams.  Measurements have shown that, for many PSNs including those
listed above, there is excessive contention for these 73 connection
blocks.  Analysis of the traffic patterns of the attached hosts
indicates that increasing the number of connection blocks to 255 -- the
number supported in PSN Release 5 -- should greatly reduce the
likelihood of hosts blocking owing to a connection block shortage.

The Timetable

On March 12, the DDN Program Management Office (PMO) issued a "Network
Change Directive", authorizing the installation of PSN release 5 to most
Arpanet sites prior to May 2, 1986.  A few sites will not receive the
new release until later, since those sites have not yet had the hardware
upgrade necessary to support PSN release 5.  Those sites with the most
serious performance problems will be the first sites to receive the new
release.  PSN release 5 has already been subjected to extensive
operational use, as the DDN PMO has previously authorized the
installation of PSN release 5 on other networks, such as the MILNET.  

Recommended Procedure for Reporting Arpanet Performance Problems

In order to facilitate resolution of performance problems on the Arpanet
it is important that the Arpanet Manager at the DDN PMO be informed of
problems noticed by Arpanet users.  Currently, the Arpanet Manager at
the DDN PMO is Captain Callaway.  Arpanet users are encouraged to
include this office, with mailbox "arpanetmgr 'at' ddn1", on network
mail regarding Arpanet problems.  The description of the problem should
be as detailed as possible.  Include information such as:

1.  description of problem
2.  time of day problem occurs
3.  duration of problem
4.  host you are using
5.  gateway you are using (if applicable)
6.  host you are attempting to reach
7.  general description of computing you are engaged in --  e.g., "I am
    transferring files from my host to host XYZ.  Approximate size of
    file is 64k bytes".
8.  provide any other information you think would be helpful in 
    resolving the problem.

Since the DDN PMO establishes the policies for operating and managing
the Arpanet, it is important that the PMO Arpanet Manager be aware of
problems experienced by Arpanet users. 

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 1986 16:07:17 EST
From:      PADLIPSKY@USC-ISI.ARPA
To:        mike@BRL.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Encrypt at which level?
In response to your message sent      Mon, 7 Apr 86 20:03:10 EST

Mike--
   Oh, dear, now you've gone and made me violate my vow not to work
up a sweat over ISOmetrics in public anymore....
   After several drafts that got too esoteric, I'll try to confine
myself to a couple of brief (possibly cryptic, but no pun is
intended) observations:  In the first place, by Sutton's Law
it does make sense to "floogle" at L6; it's where the data are.
However, doing so would leave the lower L's headers unfloogled,
which I don't believe is consistent with what its proponents
seemed to think "end-to-end encryption" implied back in the bygone
days when I occasionally talked to them (informally, of course).
Let's pretend you meant "data encryption."  (Or not, since it's
more or less a purist's point, along the lines of trying to
prevent anybody who has a different set of associations/connotations
with/for E-E E from being misled.)
   In the second place, putting floogling at L6 gives rise to all
sorts of questions I don't know the answers to about the nature
of the L7-L6 interface (which led me down a devious route I don't
want to go into here to a perception of still another architectural
inelegancy in the Seven Story Highrise).  For a while, I thought
L6 floogling would require L6 to take inappropriate cognizance of
L7's distinction between control and data.  Then I thought that
floogling didn't but being able to virtualize and devirtualize the
data did.  Now from Steve's response I begin to wonder if I was
right in the first place (and I still think I'm part right in
the second place).  Perhaps Steve will respond further if I just
assert that it's not obvious to me that you HAVE TO floogle
at L7, unless it has something to do with needing the control
information to be in the clear while the data are still encrypted
(or befloogled, as the case may be).
   Anyway, as of now I wish I hadn't asked...and if I let myself
go on any longer I imagine everybody else will wish so too,
so I'll steer clear of such fun topics as whether floogled sessions,
transport connections, and network-layer connectionless whatevers
(associations, maybe) are or aren't meaningful, muchless the
possible significance of floogling at the top, middle, or bottom
of a layer.  (But it would be delightful to take them up one at a
time if anybody else feels like it.)
   cheers, map
P.S. In case anybody's curious, Sutton was "Willie-the-Actor," and
when asked why he robbed all those banks he's alleged to have replied
"Because that's where they keep the money."
-------
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      08 Apr 86 21:58:18 EST (Tue)
From:      "Thomas Narten" <narten@Purdue.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Ethernet monitor wanted
We were recently struck by an unusual and deadly problem that killed
our Ethernet and many of the machines on it. The problem was apparently
caused by a piece of hardware that didn't take a power surge well.

The problem consisted of two things: The net became jammed with bogus
traffic (not legal packets), and lots of corrupted packets that had
correct Ethernet checksums in them. The jamming was intermittent, and
temporary, but the effects of the corrupted packets were felt for quite
a while.

IP packets were OK because they were checksummed at higher layers.
During one 3 hour period, one of our machines recorded over 200,000
IP checksum errors. Unfortunately, ARP relies on the Ethernet checksum
and hence the ARP tables became severely corrupted. You can imagine the
confusion this caused. (i.e. connections break, the ability to reach a
host comes and goes, ...)

Conclusion (as noted in this mail list before): its tough debugging a
network without tools.

We were fortunate enough to have MIT's PC monitoring program that plugs
into the Ethernet and prints out everything it sees. It was extremely
useful to us. In using it, however, I thought a more general monitoring
program would be extremely useful (even during times the network is
functioning normally).

I am wondering what (if any) other sorts of "promiscuous reader"
programs have been written and if they are available for use.

Things that would be useful include:

Having massive statistics gathered over a period of time. It would be
nice if the program could be run for an hour/day/week to accumulate
information about numbers/types/sizes of packets. This information
could (perhaps later) be broken down in such a way that one could see
all the stats for a given source address, or a given destination (i.e.
broadcast would be interesting), packet type (i.e. protocol), etc.

It would also be useful to have an interactive, screen oriented program
that lets you select what you see. This would be most useful when
tracking down problems.

Do any such programs exist? What are there capabities? What other sorts
of things would be useful to include?

Thomas Narten
----------
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Apr 86 00:44:13 est
From:      romkey@BORAX.LCS.MIT.EDU (John Romkey)
To:        narten@Purdue.EDU
Cc:        tcp-ip@sri-nic.arpa
Subject:   Ethernet monitor wanted
I'm extending MIT's "netwatch" monitor for my company. Right now I'm
planning on adding the features you've mentioned (long term statistics
gathering), plus some more real time statistics gathering, and error
indications. We'll be announcing the new product at the end of the
month.

I'm also thinking about adding a really neat mode for TCP where it
will pick up all the TCP packets that go by for a connection and
analyze them, reporting things like out of sequence packets,
retransmitted packets, and detecting problems like silly window
syndrome. I don't think it should be too incredibly difficult to do.
Maybe it'll show us how bad all of our TCP's *really* are...

I'd also really like to hear from other people on what features they
think would be useful. What are the most common protocol failures you
find? What would you most like to be able to do with an independent
monitor while debugging a new protocol implementation?
					- john romkey
					  ftp software
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Apr 86 02:00:04 EST
From:      Ra <root%bostonu.csnet@CSNET-RELAY.ARPA>
To:        narten@purdue.edu, tcp-ip@sri-nic.ARPA
Subject:   Re:  Ethernet monitor wanted

There is a program, 'traffic' that runs on SUN3s (it comes with the
SUN release tape) that does at least part of what you want. It
uses the bitmap display to draw nice graphs of what's going on
and from/to whom. There are various panels that can be selected
for viewing.

In addition they have a program 'etherfind' that takes a classic
"ya hadda be there since V6 or you're lost" 'find' kinda pattern
and dumps ethernet info like vmstat to any terminal, it's also
very helpful (eg. I could hear a diskless node crying for a rarp
and verify that no one was answering, and, past that, watch a
tftpboot fail, all ultimately caused by set up files being wrong,
but it was nice to see something.)

	-Barry Shein, Boston University

(that reference is to V6 UNIX of course...sorry)
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Apr 86 03:22:26 est
From:      karn@mouton.ARPA (Phil R. Karn at mouton.ARPA)
To:        tcp-ip@sri-nic.arpa
Subject:   Re:  Encrypt at which level?
I thought this issue was resolved long ago -- if you're really paranoid
you need to do it twice, on an end-to-end basis (transport or above)
to protect the information in the message AND on a hop-by-hop basis
(link level) to guard against traffic analysis.

Phil
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 1986 07:54:25 PST
From:      Dan Lynch <LYNCH@USC-ISIB.ARPA>
To:        "Thomas Narten" <narten@PURDUE.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA, LYNCH@USC-ISIB.ARPA
Subject:   Re: Ethernet monitor wanted
There is a commercial product out now called the LANalyzer, from Excelan,
that does much of what you want and has even more features.  In order
to be sure of capturing all packets it comes packaged as a board that
plugs into an IBM Xt (or above or a compatible, of course) plus the
software to drive the board and display the packet info in
many different formats.  IN addition to sniffing for anything you can imagine it can also generate packets of any variety and thus allow one to see how
a target system performs under known "assault".  The baord plus 
software goes for under $10K.  They can be reached at 408-434-2300
for more info.

Dan
-------
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Apr 86 08:16 EST
From:      JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA
To:        tcp-ip@sri-nic.ARPA, johnson%northeastern.csnet@CSNET-RELAY.ARPA
Subject:   Re: LAN flooding.
In response to:

:Gurudatta M. Parulkar
:University of Delaware
:Department of Computer and Information Sciences

     >We at University of Delaware are exploring the
     >possibility of using flooding in a LAN. Are there
     >any other groups looking into such a possibility ?
     >Please send me a note. 

Maybe I missed something here.  The LANs I know of all have a broadcast
address available to them.  Why would you want to flood a LAN when one
packet will do? 
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Apr 86 08:42 EST
From:      JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA
To:        tcp-ip@sri-nic.ARPA, johnson%northeastern.csnet@CSNET-RELAY.ARPA
Subject:   TCP/IP and DECNET
     We at Northeastern University have a growing contingent of both 
TCP/IP nodes (UNIX) and DECNET nodes (VMS).  I had a brilliant idea the 
other day.  Why not get ULTRIX to translate between TCP/IP and DECNET.  
This would certainly seem a logical place to do it because ULTRIX 
understands about both.  You would also only need one of these nodes on a 
network to do the gateway job of translation.  A WONDERFUL idea right?

     Guess what ULTRIX can't do folks.  Apparently with a funny 
sendmail.cf you CAN route mail from the TCP/IP world to DECNET but not 
back and FTP is just NOT possible.  Remote login isn't doable either.

     Why is the world so perverse?  Why do brilliant ideas come 
stillborn?  I didn't think I wanted much.  When I was asking about 
various vendor's TCP/IP for VMS awhile back, nobody really liked any 
vendor software.  I heard all kinds of horror stories right and left.  
I thought here would be a chance to get both worlds in one box but 
NOOOOO. (cry cry sob sob *sigh*). 

     Does anybody out there know of someone trying to solve the problem 
of getting ULTRIX to do the right thing between TCP/IP and DECNET?  Is 
DEC maybe?  Please (whimper whimper)?

Chris Johnson
Northeastern University
johnson@northeastern.csnet
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Apr 86 11:44:50 pst
From:      imagen!geof@decwrl.DEC.COM (Geof Cooper)
To:        narten@Purdue.EDU
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Ethernet monitor wanted
 > I am wondering what (if any) other sorts of "promiscuous reader"
 > programs have been written and if they are available for use.

I believe that Excelan makes such a device.

- Geof
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Wed 9 Apr 86 13:22:37-PST
From:      Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA>
To:        LYNCH@USC-ISIB.ARPA
Cc:        narten@PURDUE.EDU, tcp-ip@SRI-NIC.ARPA, OLE@SRI-NIC.ARPA
Subject:   Re: Ethernet monitor wanted
CMC (Communication Machinery Corporation) of Santa Barbara has an
Ethernet monitor, the DRN-1700  (aka "Spidermonitor" from Scotland).
Contact Russ Sharer (805) 963-9471 for details.

Ole
-------
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 1986 00:42-EST
From:      CERF@usc-isi.ARPA
To:        parulkar@dewey.udel.EDU
Cc:        tcp-ip@dewey.udel.EDU
Subject:   Re: Flooding
Flooding is used in the current Shortest Path First Routing algorithm.
Check with Steve Cohn at BBN for references.

Vint
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 1986 1202-PST (Thursday)
From:      lewis <lewis@sri-tsc.ARPA>
To:        tcp-ip@sri-nic
Cc:        
Subject:   Re: Ethernet monitor wanted
For those with SUN3 workstations, there is a graphical Ethernet watch program.
You start up the rpc.etherd in the background, and the user program is
called "traffic" in usr/bin I think. It of course uses permiscuous mode.
The user is able to split his window into several displays for parsing
packets into time varying histograms by protocol, host, or destination,
the 8 busiest sources are displayed. You can also view load, ei 100%
is 10 Megabits/sec. It does not keep long term statistics. 
	There is another SUN3 etherwatch program with a non-graphical
interface, and if it collects statistics, I will post a description
after I look at it.
-Mark Lewis

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Apr 86  9:14:38 EST
From:      Ken Lebowitz <kjl@bbn-clxx.arpa>
To:        tcp-ip@sri-nic
Subject:   VMS TCP/IP on a serial line?
Can anyone tell me if Wollongong's networking code for VMS is capable of
performing TCP/IP through a serial line device?  Has anyone out there
actually done this (I seem to remember somebody having done this on a UNIX
host)?

Thanks,

Ken Lebowitz
BBN Laboratories

ARPA:	kjl@bbn-clxx.arpa or kjl@clxx.bbn.com
UUCP:	...!{decvax,ihnp4,harvard}!bbncca!kjl
CSNET:	kjl%bbn-clxx.arpa@csnet-relay

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 86 16:06:22 EST (Thu)
From:      Frederick E Serr <fserr@BBNCC5.ARPA>
To:        Bill Chiarchiaro <wjc@ll-vlsi.ARPA>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: ARPAnet Usage
During the second week of December, 1985, the busiest node on the
ARPANET was RCC5, here at BBN.  It handled the following numbers of
packets per second: 

	       From    Into    Out
	       Hosts   Hosts  Trunks

Average		16	21	77
Peak Hour	18	28 	77

The first row is the average over five days (Mon-Fri), 24-hours per
day.  The second row is for a busy hour (identified as a peak for the
entire net, it may not be THE peak for this node).  During this same
hour packet rates of over 100/sec out internode trunks were observed
on other nodes.  This node has six busy hosts on it, including several
gateways.

I hope that this somewhat delayed response still provides some useful
info.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Apr 86 17:45:16 EST
From:      Louis A. Mamakos <louie@trantor.UMD.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Wollongong problem
Ah yes, the TELNET end-of-line discussion surfaces again.  I inquired 
about this on the list a few years ago while I was writing the TELNET
server for our Sperry 1100 host.  The feeling at that time was that
the correct action for an end-of-line was the CR LF sequence.  

This works out pretty well since the Sperry machine is a line at a time
type machine.  The TELNET session is symmetric;  it sends lines terminated
by CR LF to you, and you reply in turn.

It seems that a problem like this should be fairly easy to accomodate in
my TELNET server, but what do we have standards for?  We have this same
problem with our Wollongong host, and have beat on the vendor to fix this.
The user TELNET with Berkeley 4.2 was damaged in a similar fashion and it
was a simple 3 line fix to the program.  Its been more than a year, and the
Wollongong people have yet to address THIS simple problem; let along hard
ones like subnetting.  

This seems to have degenerated into a flame;  sorry about that.  I just
wanted to make the point that the fuzzballs are not the only hosts that
are upset by this particular bug.

Louis A. Mamakos  WA3YMH    Internet: louie@TRANTOR.UMD.EDU
  University of Maryland, Computer Science Center - Systems Programming

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Apr 86 17:57:12 EST
From:      jas@proteon.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   naked CR's
The server telnet in Ultrix-32m V1.1 has the same bug. My local user
telnets can cope, but only after they recieve one more character. Unfortunately,
smart editors on Unix send naked CR to implement "go-to-beginning-of-line",
so you lose big with this sever telnet.

(I presume this is a standard raw 4.2BSD bug, and that DEC fixes it in V1.2.)
-------

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      10-Apr-86 13:44:35-UT
From:      hwb@gw.umich.edu
To:        tcp-ip@sri-nic.arpa
Cc:        hwb@GW.UMICH.EDU
Subject:   Packet switch rates.
Hi:
 
What packet transfer rates are people observing in IP switches these days.
I would be interested in some figures of dedicated switches as well as
through machines that also serve a host function. A good example would be
a packet rate per second for a switch that connects two Ethernets, but
other examples would be appreciated, too. As I think that this is of general
interest I would suggest to post the examples to this list.
 
	-- Hans-Werner Braun
-------
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 86 18:55 EST
From:      Rudy.Nedved@A.CS.CMU.EDU
To:        tcp-ip@sri-nic.arpa
Subject:   telnet
Wait until you try to use the binary option in connection with
telnet. CMU has lots of special terminals that use the 8th bit....but
there are two communities of busted telnet servers. 4.2BSD puts you
in "raw" mode instead of just passing the 8th bit thru and some IBM
sites that use EBCDIC (sic?)  use the BINARY option to mean no
translation [I don't remeber seeing an TELNET option to change from
NVT ASCII to EBCDIC.].

Given that the majority of machines around here implement 4.2BSD
telnet, we are going to "hack" our systems to send out IAC WILL
BINARY to indicate that the system is NOT a busted 4.2BSD site. I
hope 4.3 does not have this bug too and that they finally fix the EOL
problems.

I can understand how the old telnet servers and user programs got
incorrectly implemented but any future servers should be fixed since
the specifications for the options and telnet have been cleaned up
alot. You just have to read them VERY carefully and completely.

The only implementation of telnet that seems to be ALMOST correctly
implemented is TOPS-20 telnet. (Maybe?) there is a race condition bug for the
option negotiations (it loses information) and some questions about
CR NUL handling which implies a bare CR versus CR LF.

-Rudy
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Apr 86 18:59:14 EST
From:      Martin Schoffstall <schoff%rpics.csnet@CSNET-RELAY.ARPA>
To:        kjl%bbn-clxx.arpa@csnet-relay.arpa, tcp-ip%sri-nic.arpa@csnet-relay.arpa
Cc:        weltyc%rpicie.csnet@CSNET-RELAY.ARPA
Subject:   Re:  VMS TCP/IP on a serial line?
well..  we have been trying to do this with help from the TWG
development group.  We just applied the latest vms patches to
make it compatible with rick@seismo's SL software but it didn't
work.  We are going to modify the SL code shortly if we can't get
VMS "fixed".

marty

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Apr 1986  00:06 MST
From:      "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Cc:        WANCHO@SIMTEL20.ARPA
Subject:   PCs and TACs
Perhaps because this host holds the largest collection of anonymously
FTPable "public domain" software on the Internet, we are probably
indirectly responsible for a high volume of not only those FTP
transfers, but also high volumes of down and uploads between many
hosts and users with PCs on TACs.  Also, with widely available PCs, we
have found many people downloading entire mail files and composing
responses offline for later uploads and adding to the volume of such
traffic.

Most of these transfers are done using some variant of the Christensen
Protocol, commonly misnamed "xmodem" protocol, or KERMIT.  Although
the KERMIT protocol allows for user-settable packet sizes, the
arguably more efficient Christensen protocol does not.  It is fixed at
132- or the newer 133-byte blocks.  This presents a problem at any
speed above 300 bps with TAC input buffers defaulted to 64, and it is
not so simple to get DCA to make a change for selected ports (it used
to take a phone call).

At one time there was some work in progress to implement one of
several protocols at the TAC level.  That effort seems to have died.
We feel that such an effort such be revisited due to the proliferation
of these PCs and what currently amounts to packet/character file
transfers loading the network.

Could it be possible that the C/30 TACs currently in use might be
upgraded C/30e's?  If so, then, depending on the amount of extra
memory available, it might be possible to seriously consider
implementing the basic protocols of either KERMIT, Christensen, or
maybe even X.PC at the TAC level.

In any event, we would like to see the input buffer pool on each TAC
redistributed to the *active* ports.  In many cases, the default input
buffer size for each port can be easily raised to 134.  With C/30e's
it may even be possible to raise that to 1,030 to accomodate the
latest variation of the Christensen protocol, without the paperwork to
make such a "simple" change request necessary.  A low-overhead
Christensen transfer would then be possile at higher speeds and thus
reduce the duration of such transfers.  (I intended to insert a pitch
for upgrading the TAC dialin modems to 2,400 bps, but I'm already
pushing my luck.)

Now, having said all that, are there data to back up our claim that
file transfers through TACs are becoming, if not already, a
significant factor in network loading to justify a TAC level protocol
implementation?

--Frank
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      10-Apr-86 17:30:19-UT
From:      mills@dcn6.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   Wollongong problem
Folks,

It appears that the Wollongong user TELNET for VMS does not pad the CR
(carriage return) with either NUL (idle) or LF (line feed) entered from the
keyboard, so is in violation of the TELNET specification (RFC-854, page 10).
At least some servers become cranky when faced with "bare" CR, at least in
some cases. Fred Ball at Ford noticed the Wollongong struck with the fuzzball
TELNET server, but other servers may peal that gong as well.

Dave
-------
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Apr 86 02:02:58 est
From:      karn@mouton.ARPA (Phil R. Karn at mouton.ARPA)
To:        tcp-ip@sri-nic.arpa
Subject:   Telnet cr/lf
Clearly, implementations which don't send cr/lf sequences when operating
in standard NVT mode are broken. But I assume that the server offers
to echo and that the user accepts (as almost all Unix systems do) then
the connection reverts to "raw" mode -- otherwise things like screen
editors break.  Is this a reasonable interpretation?

Phil
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Apr 86 09:53:02 -0500
From:      Gurudatta Parulkar <parulkar@dewey.udel.EDU>
To:        JOHNSON%northeastern.csnet@csnet-relay.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: LAN flooding.

Thank you very much for asking the following question. So let me take this 
opportunity to elaborate little more of NOAHnet, the flood LAN we are
developing. Noahnet uses a graph like topology with 4-5 interconnections per
node. It uses a "kind of flooding" to route all data messages around the 
network and it does not do store and forward. Every node starts forwarding an
incoming message to all its UNOCCUPIED adjacent nodes as soon as it receives
the first (couple of) bit(s) (one may think of it as
a kind of circuit switching). Thus, delay at each node is very small. 
It uses short status and command messages to release nodes which don't
form successful path. In short, our claims are that

1. Graph like topology should provide required reliability to LANs.

2. The topology and our flooding protocol permit multiple messages to
be active in the network at any time.

3. Flooding associated with no store and forward provide fast routing strategy.

4. Any thing that you can think of !

Noahnet nodes will be more expensive than other LAN interfaces but not
order of magnitude. Flooding looks wasteful, but the modified flooding 
does not seem to be THAT (?) wasteful. We are doing formal performance 
analysis to prove (disprove!) these claims.

I hope that it gives a better picture of what we are doing. So WHAT DO
THINK ?? We do have few tech reports describing the Noahnet effort, in case,
you would like to see more details.

Thanks for your attention.

-guru

>>We at University of Delaware are exploring the possibility of using
>>flooding in a LAN. Are there any other groups looking into such a
>>possibility ? Please send me a note.


> Maybe I missed something here.  The LANs I know of all have a broadcast
> address available to them.  Why would you want to flood a LAN when one
> packet will do? 
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 1986 1059-PST (Friday)
From:      Barry Leiner <leiner@RIACS.ARPA>
To:        Mike Muuss <mike@BRL.ARPA>
Cc:        security@red.rutgers.edu, tcp-ip@sri-nic.ARPA, Ra <root%bostonu.csnet@csnet-relay.ARPA>
Subject:   Re:  Thought on data encryption on networks
Mike,

MOst of the work I am aware of in ETE encryption in the internet has
been working on top of IP (i.e. encrypts IP packets on a packet by
packet basis).

Barry

----------
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Apr 86 08:35 EST
From:      "Brendan Healey, 0734 752175" <OPERATOR%PSI%REAFSB%SDRRTR%slb-test.csnet@CSNET-RELAY.ARPA>
To:        apollo@yale.ARPA, info-kermit@cu20b.columbia.edu, info-vax@sri-kl.ARPA, sun-spots@rice.edu, tcp-ip@sri-nic.ARPA, unix-emacs@bbn-unix.ARPA, unix-wizards@brl.ARPA
	Hello distribution list!, my name is Brendan Healey, I am
	the computer centre manager for Fairchild Semiconductor ltd
	at Reading ENGLAND. I would appreciate it if you would
	add my name to the distribution list. I have a 8600-11/785
	cluster system, attached to the worldwide Schlumberger
	Information Network, and 4 sun 3/50's.
	Reading is the site of the European Research, Design and
	Applications Centre (ERDAC). Our interests range from
	Pascal to Prolog, C UNIX, SUNS, VAX/VMS and communications.

	Address being:-

	system%reafsb%smrvx2%eps731%slb-test.csnet@csnet-relay.arpa

	Thankyou,
						Brendan Healey
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Apr 86 09:31  EST
From:      David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
To:        mills@DCN6.ARPA, jas@PROTEON.ARPA, Rudy.Nedved%A.CS.CMU.EDU@SCRC-STONY-BROOK.ARPA, Phil R. Karn at mouton.ARPA <karn@MOUTON.ARPA>, tcp-ip@SRI-NIC.ARPA
Subject:   Wollongong problem
Time more my yearly TELNET flame:

(Implement and) Use SUPDUP.

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 86 15:11:45 mst
From:      Joe Choy 303-497-1222 <choy%ncar.csnet@CSNET-RELAY.ARPA>
To:        tcp-ip@sri-nic.ARPA
Cc:        
Subject:   EXCELAN EXPERIENCE REFERENCES
I would appreciate anyone who has any expeience with the Excelan board and
EXOS software on a VAX VMS system and/or 11/70 running RSX11M+ relating
their comments to me.  We have users who are considering the products.  We
are especially interested in problems encountered, support provided by
Excelan, compatibility (or the lack of it) with other TCP/IP products, and
anything else that might be worth noting.

Please reply to me directly:   choy@ncar.csnet

Thanks in advance!


-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 86 16:24:00 MST
From:      <mgeorge@sandia-2>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   VAX 11/750 running Wollengong Software

	Here at Sandia Labs, Albuquerque, NM, we recently brought
	a new host onto MILNET.  SANDIA-2 is a VAX 11/750 running VMS
	and The Wollengong Group IP/TCP software.  Our IMP interface 
	is an ACC LH/DH-11.

	I am looking for VMS procedures to set up and run the following
	applications:

	"handle" interpreting for local users' incoming mail
	"finger" utility
	bulletin boards: setting up and running
	distribution lists: setting up and running
	any other modern conveniences for users and administrators

	Any help will be appreciated in this area.  If anyone has 
	information as to how this configuration of VAX and Wollengong
	should perform or any bugs detected, I'd be interested.

	Send responses to:

		MGEORGE@SANDIA-2

	Thanks in advance.

						- Mike George
						  Division 2633
						  Sandia National Labs
						  P.O. Box 5800
						  Albuquerque, NM 87185
						  505-844-



9357
						  FTS-844-9357

------
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 86 14:37 EST
From:      Rudy.Nedved@A.CS.CMU.EDU
To:        karn@mouton.ARPA (Phil R. Karn at mouton.ARPA)
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Telnet cr/lf
The connection only reverts to RAW mode when DO BINARY is done. The
normal mode is non-RAW or COOKED depending on what you are using. 
Interrupt and other special operations characters do not work in RAW
mode. RAW tells the terminal driver (whatever flavor) to not act on
any characters. CRMOD in non-RAW mode tells the driver to convert from
CR to LF since Unix wants "newline" which is a LF. Also CRMOD on output
makes LF into CR LF.

-Rudy
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Apr 86 13:22:54 GMT
From:      Larry Byard <byard@bbncc-eur.ARPA>
To:        "Frank J. Wancho" <WANCHO@simtel20.arpa>
Cc:        TCP-IP@sri-nic.arpa, stt-eng@bbncc-eur.arpa
Subject:   Re: PCs and TACs
Oooops.  Make that all IMPs (PSNs) in Europe are C/30Es.  There are
no C/30E TACs.  Larry

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Apr 86 22:16:18 cst
From:      jsq@SALLY.UTEXAS.EDU (John Quarterman)
To:        TCP-IP@SRI-NIC.ARPA
Subject:   4.3BSD IP subnet ARP hack
Someone asked a few weeks ago if an ARP hack had been implemented for 4.3BSD.
(This is a way to allow subnet gateways to respond to ARP requests for hosts
that are on subnets other than the one of the requesting host:  the subnet
gateway thus becomes a bridge and only subnet bridges need know about subnets.)
I have reimplemented Smoot Carl-Mitchell's 4.2BSD ARP hack in 4.3BSD.
It is available by anonymous ftp (login anonymous, password guest) from
sally.utexas.edu as the shell archive /pub/subarp.shar.  I will also post
it to mod.sources on USENET, and have sent it to Berkeley.
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 86  0825 PST
From:      Joe Weening <JJW@SU-AI.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Telnet binary option
Ah yes, Unix and the Telnet binary option.  Most of our hosts at Stanford
have been fixed not to interpret this as raw mode, since it's useless for
our main use of Telnet, i.e., connecting people's terminals to hosts.
Binary mode allow terminals with an "edit" or "meta" key to send this as
the 200 bit, which is useful for EMACS and other programs, but terminals
continue to send CR when you type <return>, not LF, which is what raw mode
expects; and they need both CR and LF to move to the beginning of the next
line.  Raw mode confuses the hell out of non-Unix hosts.

RFC 856 says that both sides need an "interpretation" of binary mode, with
no suggestions as to what such an interpretation might be.  So I guess
it's all right for consenting Unixes to do whatever they want, but when
the other host is not known to be Unix, it seems a bit presumptuous to
assume it will use Unix conventions.

						Joe

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 1986 07:59-EST
From:      CERF@USC-ISI.ARPA
To:        LYNCH@USC-ISIB.ARPA
Cc:        narten@PURDUE.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Ethernet monitor wanted

Charlie Brown's Complete Systems Inc is reselling a box made by Xerox which
does all kinds of tests - including finding breaks in Ethernet cables. This
box sells for something like $2-3K I believe. Gary McGreal and Charlie Brown
are running this out of Northern Virginia.  I will get the phone number
if anyone is interested.

Vint
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Apr 86 21:09:26 EST
From:      "Christopher A. Kent" <cak@Purdue.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   ICMP responses to broadcasts
Let me second John Romkey's assertion that no good ICMP implementation
should send redirects in response to a broadcast packet. Might I also
ask at this time why our core gateway does just that? We receive
several redirects a second in response to the rwho/ruptime packets
our Unix hosts send (no ruptime flames, please.)

chris
-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Apr 86 00:19:12 -0800
From:      Marshall Rose <mrose@nrtc-gremlin>
To:        Ra <root%bostonu.csnet@csnet-relay.ARPA>
Cc:        security@red.rutgers, tcp-ip@sri-nic.ARPA
Subject:   Re: Thought on data encryption on networks
[ Forgive me for joining so late on this one but I'm inclined to
    correct one mistyped fact... ]

> Oh, where is Arthur to slice this gordian knot? 

    Arthur?  It was the Persian boy, "Alexander the Great", who tackled
    the Gordian knot.  He did not use subtlety but brute force in doing
    so.

/mtr
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 1986 07:16-EST
From:      CERF@USC-ISI.ARPA
To:        CERF@USC-ISI.ARPA
Cc:        LYNCH@USC-ISIB.ARPA, narten@PURDUE.EDU tcp-ip@SRI-NIC.ARPA
Subject:   Re: Ethernet monitor wanted
Complete Systems Inc
3206 Wildmere Place
Herndon, VA 22071
(703) 620-5372

for Ethernet Monitors fromCharlie Brown (redistributing Xerox product)
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 1986 1132-PST (Monday)
From:      Jeff Mogul <mogul@su-navajo.arpa>
To:        "Christopher A. Kent" <cak@Purdue.EDU>
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: ICMP responses to broadcasts
    Let me second John Romkey's assertion that no good ICMP implementation
    should send redirects in response to a broadcast packet. Might I also
    ask at this time why our core gateway does just that? We receive
    several redirects a second in response to the rwho/ruptime packets
    our Unix hosts send (no ruptime flames, please.)

Maybe it's because your Unix host is sending broadcasts to the wrong
IP address?  (That is, Net.0.0.0 instead of Net.255.255.255)
Of course, it would be nice if gateways looked at the
data-link header to see if something arrived as a broadcast, but
this is one of those little things that is impossible in some systems
(e.g., 4.3), which is why these systems really are unsuited for
use as gateways.

One would hope that the core gateways are capable of handling this, but
I would not be surprised if they are not.

I would also be unsurprised if the core gateways still know nothing
at all about broadcasts.  Perhaps someone can fill us in.
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Apr 86 09:02:57 EST
From:      law%h-sc4@harvard.HARVARD.EDU
To:        CERF@USC-ISI.ARPA, LYNCH@USC-ISIB.ARPA
Cc:        narten@PURDUE.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Ethernet monitor wanted
Yes, would be interested in further info regarding ethernet monitors.
	Lew Law
-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Apr 86 09:46  EST
From:      David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Data after a FIN
We are noticing several hosts (e.g., UTAH-CS) that are sending a FIN,
then sending data, and finally a second FIN.  Technically, The spec
says this should happen and the data should be discarded.  What I want
to know is
 - Who is doing this (I suspect 4.3BSD)?  and
 - Why?  and
 - Why doesn't anybody else know about it?
I was under the impression this list was a clearing-house for ideas, but
have absolutely no recollection of this being discussed.

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Mon 14 Apr 86 14:42:35-EST
From:      "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
To:        OPERATOR%PSI%REAFSB%SDRRTR%slb-test.csnet@CSNET-RELAY.ARPA, apollo@YALE.ARPA, info-kermit@CU20B.COLUMBIA.EDU, info-vax@SRI-KL.ARPA, sun-spots@RICE.EDU, tcp-ip@SRI-NIC.ARPA, unix-emacs@BBN-UNIX.ARPA, unix-wizards@BRL.ARPA
Cc:        JNC@XX.LCS.MIT.EDU
	Does anyone know of a 'suitable' tool (definition of exactly
what such a tool should do purposely left unstated) to apply to people
like this? The polite 'education' method of informing people (which I
was a believer in for a while) that this is not a sociable thing to do
always seems to miss a few newcomers who promptly make the same
mistake. My current theory (regressing to 17th century penal ideology)
is that we should punish the offendors so horribly that word of what
happens to you when you do this will become instant network folklore.
I used to send such pinheads a few megabytes of mail manually, but
maybe a tool that sends them 253 copies of SF-LOVERS every hour for
three weeks is the right thing.

	Noel
-------
-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Apr 86 6:08:36 EST
From:      Mike Muuss <mike@BRL.ARPA>
To:        Hostmaster@sri-nic.arpa, tcp-ip@sri-nic.arpa
Cc:        Unix-Wizards@BRL.ARPA, GouldBugs@BRL.ARPA
Subject:   Host table & 4.2BSD problem
The version of /etc/htable distributed with 4.2 BSD, when applied to
the very latest host table from the NIC, fills your disks with
the word "bucsa" repeated over and over again.

The offending new host entry is:

HOST : 192.12.185.1 : BU-CS.BU.EDU,BU-CS.ARPA,BU-CS,BUCSA,A : SUN-3 : UNIX ::

This is currently the only host in the table with a single character
name, and the 4.2 BSD version of "htable" has a (defective) special
case in the handling of this.  Never fear, the 4.3 version is correct,
but you don't have it yet.

SUGGESTIONS:

1)  The NIC should probably remove the alias "A" from BUCSA.  (*I* won't
forget that host name anytime soon -- it's etched on 200 Mbytes of disk!)

2)  All UNIX caretakers should apply the following patch to
file /usr/src/etc/htable/scan.l:

From:

{ALPHA}               return (NAME);

To:

{ALPHA}               {
	                      yylval.namelist = newname(yytext);
	                      return (NAME);
	              }

Note that Gould UTX 1.2 has this bug as well (a faithful port of the
Berkeley bug).  All you folks with binary systems, file an SPR.
	Bugs!
	 -Mike
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Apr 86 6:39:04 EST
From:      Mike Muuss <mike@BRL.ARPA>
To:        Hostmaster@sri-nic.arpa
Cc:        tcp-ip@sri-nic.arpa
Subject:   Bad host entries
Turns out that there is more fun.
The Berkeley HTABLE program will not accept CPUs of the form:
SUN-2/50,they must instead be written SUN2-50.  No slashes.

There are 5 such errors in the new host table:
jove.caltech.edu
ganymede.caltech.edu
leda.caltech.edu
laplace.db.mcc.com
weierstrass.db.mcc.com

This problem exists with both 4.2 and 4.3 BSD version of HTABLE,
so I suggest that the table gets fixed.
	Best,
	 -Mike
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Tue 15 Apr 86 10:39:22-PST
From:      HOSTMASTER@SRI-NIC.ARPA
To:        brescia@BBNCCV.ARPA
Cc:        mike@BRL.ARPA, Hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, STAHL@SRI-NIC.ARPA
Subject:   Re: Bad host entries
You're right, Mike.  Single character names and nicknames are
disallowed in the table.  This is written up in RFC 952, DoD Internet
Host Table Specification.  There obviously was a slip-up here.  We'll
correct the table and investigate to see why it happened.

- Mary
-------
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Apr 86 11:27:59 PST
From:      chuq%plaid@SUN.COM (Chuq Von Rospach)
To:        JNC@xx.lcs.mit.edu
Cc:        tcp-ip@sri-nic.arpa, unix-wizards@BRL.ARPA
Subject:   requests
>> Message-ID: <12198824179.25.JNC@XX.LCS.MIT.EDU>

>> ...we should punish the offendors so horribly that word of what
>> happens to you when you do this will become instant network folklore.
>> I used to send such pinheads a few megabytes of mail manually, but
>> maybe a tool that sends them 253 copies of SF-LOVERS every hour for
>> three weeks is the right thing.

What is the purpose of flaming to death a person WHO DOESN'T KNOW BETTER?
I'm not saying that the protocols, procedures and folklore of the net (whether
ARPA or USENET) are arcane or confusing -- especially to those who have
learned the ropes.  Remember, you were a novice once, yourself.

Flaming someone for screwing up doesn't solve the problem. Information solves
the problem.  In all my time working with USENET, only rarely did I see 
a person or account repeat a mistake. Reacting to a misplaced message like
it was a personal affront only causes the new users (new blood and ideas
we can ALWAYS use to keep the groups fresh) the withdraw and decide we're
all a bunch of idiots (or worse).  The over-reaction is MUCH worse than
the crime.

> Each netmailer need make such mistakes only once or twice if, in reply,
> they received a canned tutorial on the constituate parts of netdom,
> pathnames, list-of-lists, requests, etc., etc.  I've not seen such a
> summary available for distribution, but I'd sure like to see one.


Good information is key.  A couple of years back (was it that long ago,
already?) I rewrote the etiquette doc for USENET.  Perhaps what we need 
is something similar for ARPA lists, so that when someone does screw up
we have a concise and non-flaming resource to help them keep from screwing
up twice.

chuq
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Tue 15 Apr 86 11:43:04-PST
From:      HOSTMASTER@SRI-NIC.ARPA
To:        mike@BRL.ARPA
Cc:        Hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, STAHL@SRI-NIC.ARPA
Subject:   Re: Bad host entries
Mike,

In the latest version of "Assigned Numbers", RFC 960, SUN-2/50 is
listed as an "official" machine name.  SUN2-50 is not listed there.

People bringing hosts onto the net should make this RFC or its latest
update part of their library.  It can be FTPed from SRI-NIC as
pathname RFC:RFC960.TXT.  The latest version can always be found on
SRI-NIC as RFC:ASSIGNED-NUMBERS.TXT, so one doesn't necessarily have
to remember its RFC number.

- Mary
-------
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Apr 86 9:09:26 EST
From:      Bruce Brolsma <brolsma@BBN-SPCA.ARPA>
To:        JNC@xx.lcs.mit.EDU
Cc:        unix-wizards@brl.ARPA, tcp-ip@sri-nic.ARPA
Subject:   requests
> Message-ID: <12198824179.25.JNC@XX.LCS.MIT.EDU>

> ...we should punish the offendors so horribly that word of what
> happens to you when you do this will become instant network folklore.
> I used to send such pinheads a few megabytes of mail manually, but
> maybe a tool that sends them 253 copies of SF-LOVERS every hour for
> three weeks is the right thing.


Now, these things couldn't POSSIBLY happen because netmail address
paths seem abstruse and impenetrable, especially to newcomers,
could they????  

The half-second it takes me to discard such messages doesn't particularly
bother me, perhaps because I am inclined to be merciful toward most
everyone.  It's a bit like sex education; after the fact punishment
ain't gonna do all that much to alleviate the problem.  

Each netmailer need make such mistakes only once or twice if, in reply, they
received a canned tutorial on the constituate parts of netdom, pathnames,
list-of-lists, requests, etc., etc.  I've not seen such a summary available
for distribution, but I'd sure like to see one.

    
-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Apr 86 09:28:43 est
From:      martin%sabre@mouton.bellcore.com (Martin J Levy)
To:        tcp-ip@sri-nic.arpa
Subject:   Hyperchannel tcp/ip for 4.2bsd.
i'm in the process of bringing up 3 machines on a hyperchannel with
steve glasser's (Tek) driver. i would like to know any other sites
which are running such code. i have been able to find steve.

martin levy
bellcore.
-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 86 09:31:00 EST (Tue)
From:      Mike Brescia <brescia@BBNCCV.ARPA>
To:        Mike Muuss <mike@brl.ARPA>
Cc:        Hostmaster@sri-nic.ARPA, tcp-ip@sri-nic.ARPA, brescia@BBNCCV.ARPA
Subject:   Re: Bad host entries
re: single character names

Every site (well, a lot of them) has hosts named A, B, ... .  While the NIC
people check for unique names, they should also editorially remove such short
names.  Thus BUCSA could be A.CS.BU.EDU, and still be named as A within the
CS.BU.EDU domain.

ISIA, BBNA, CMUA, etc. thank you.

re: form of cpu name, e.g. SUN-2/50

We have (had?) a list of 'Official Machine Names', 'Official System Names',
'Official Protocol and Service Names', and 'Official Terminal Type Names' in
RFC 943, 'Assigned Numbers' so that we can avoid such problems.  Perhaps the
rule for inventing those names should be stated in those sections, to prevent
future breakage.

Proposed statement of rule for names - 

"Official Names consist of only alphanumeric and hyphen (minus sign) characters."

Mike
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 86 10:32:51 EST (Tue)
From:      Mike Brescia <brescia@BBNCCV.ARPA>
To:        tcp-ip@sri-nic.ARPA
Subject:   Re: ICMP responses to broadcasts

     Let me second John Romkey's assertion that no good ICMP implementation
     should send redirects in response to a broadcast packet. Might I also
     ask at this time why our core gateway does just that? 

Chris, your gateway is on a ring.  Its driver does not recognize broadcasts as
such, and will rebroadcast them as well as send a redirect each time it comes
around until the TTL disappears.  This means that if the TTL is 10, you get 10
copies of the 'rwho' packet and 10 redirects.  This has been the case since
day one on the ring.  (It had been fixed in fibernet and ethernet drivers long
ago.)

The fix in the gateway is to drop all IP-type packets addressed to
'hardware-broadcast' before they leave the local net layer.

This is the first report of this being some kind of problem.  We'll put it on
the queue of things to fix before the latest release is completely frozen.

	Mike
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Apr 86 10:47:39 EST
From:      "Mary C. Akers" <makers@bbncct.ARPA>
To:        "J. Noel Chiappa" <JNC@xx.lcs.mit.edu>
Cc:        tcp-ip@sri-nic.arpa, makers@bbncct.arpa
Noel

You notion has merit.  I have had several such discussions with fellow office
mates as to a "just punishment."  We came to the conclusion that if EVERYONE
who received mailing list addition/deletion messages answered the message with
a detailed explanation of the correct procedures it might help correct the
problem.  Considering the size of some lists it might even match your 
253-copies-of-SF-Lovers-per-hour figure.

What say gentle readers?  Is this a just/effective method?

Mary
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Apr 86 12:52:08 EST
From:      Barry Shein <bzs%bostonu.csnet@CSNET-RELAY.ARPA>
To:        Hostmaster@sri-nic.ARPA, mike@brl.ARPA, tcp-ip@sri-nic.ARPA
Cc:        GouldBugs@brl.ARPA, Unix-Wizards@brl.ARPA
Subject:   Re:  Host table & 4.2BSD problem
I would request that the alias for BUCSA that is causing the
trouble ("A") be immediately removed from the host table entry,
it was a mistake that it was ever sent. Apologies (although
obviously the software shouldn't have fallen off the floor
which I won't take responsibility for.)

	-Barry Shein, Boston University
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 1986 09:00:07 EST (Wed)
From:      Dan Hoey <hoey@nrl-aic.ARPA>
To:        Mike Muuss <mike@BRL.ARPA>
Cc:        Hostmaster@sri-nic.ARPA, tcp-ip@sri-nic.ARPA
Subject:   Re: Bad host entries
    From tcp-ip-RELAY@SRI-NIC.ARPA  Wed Apr 16 07:42:50 1986
    Date:     Tue, 15 Apr 86 6:39:04 EST

    The Berkeley HTABLE program will not accept CPUs of the form:
    SUN-2/50,they must instead be written SUN2-50.  No slashes.

No, Mike, you have probably been confused by htable's off-by-3 error
messages.  HTABLE likes SUN-2/50 fine, but it can't cope with CPUs of
the form "3Bn".  When EYEZOD came out, I got Hostmaster to change its
machine type to "ATT-3B20", but the problem resurfaced with the .BU.EDU
batch that brought us BUCSA.  The five offending hosts are:

HOST : 192.12.185.21 : BUCSC.BU.EDU,BUCSC,DEATHSTAR : 3B5 : UNIX : TCP/TELNET,TCP/SMTP,TCP/FTP :
HOST : 192.12.185.22 : TIE1.BU.EDU,TIE1 : 3B2 : UNIX : UDP :
HOST : 192.12.185.23 : TIE2.BU.EDU,TIE2 : 3B2 : UNIX : UDP :
HOST : 192.12.185.24 : TIE3.BU.EDU,TIE3,BUDD : 3B2 : UNIX : UDP :
HOST : 192.12.185.25 : TIE4.BU.EDU,TIE4 : 3B2 : UNIX : UDP :

More errors came in host table version 530:  24 host names with
"Berkeley.EDU" in their names.  Can the 4.3 HTABLE handle lower case?

Dan Hoey
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Apr 86 11:46:59 EST
From:      Chris Torek <chris@gyre.umd.edu>
To:        Hostmaster@sri-nic.arpa, mike@brl.arpa, tcp-ip@sri-nic.arpa
Cc:        GouldBugs@brl.arpa, Unix-Wizards@brl.arpa
Subject:   Re:  Host table & 4.2BSD problem
Note that the 4.3 htable still cannot handle lowercase, nor does
it like host names of the form `3B5' (begins with a digit).  I
plan to throw out the current source for htable and start over...

Chris
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 1986 12:25:49 EST (Wed)
From:      Dan Hoey <hoey@nrl-aic.ARPA>
To:        tcp-ip@SRI-NIC.ARPA, unix-wizards@BRL.ARPA
Cc:        Hostmaster@SRI-NIC.ARPA
Subject:   Newer revised HTABLE for 4.2BSD
Here are context diffs for /usr/src/etc/{scan.l,htable.h} that will
allow machines like 3B2 and hosts like UCBVAX.Berkeley.EDU.  It
shouldn't have any problem with one-character host names, either.

This diff is between the 4.2 scan.l and the new one.  If you have
applied the change Mike Muuss sent out yesterday, the form of your
{ALPHA} rule will be different but the effect is the same: the rule is
deleted, because it is handled by the revised rule.

This change will NOT handle machine types like "360/50".  Tokens must
contain an alphabetic character before the first slash, dot, or hyphen.
This prevents ambiguity in parsing octet notation.

And yes, this will accept some invalid syntax, too.  The Hostmaster
will have to get a new canary.

Dan Hoey

*** 4.2/scan.l	Thu Jun 30 20:19:45 1983
--- scan.l	Wed Apr 16 12:10:14 1986
***************
*** 9,17
  
  BLANK	[ \t]
  DIGIT	[0-9]
! ALPHA	[A-Z]
! ANUM	[0-9A-Z]
! NAMECHR	[0-9A-Z./-]
  
  %%
  "NET"		{

--- 9,17 -----
  
  BLANK	[ \t]
  DIGIT	[0-9]
! ALPHA	[A-Za-z]
! ANUM	[0-9A-Za-z]
! NAMECHR	[0-9A-Za-z./-]
  
  %%
  "NET"		{
***************
*** 29,36
  			return (KEYWORD);
  		}
  
! {ALPHA}{NAMECHR}*{ANUM}	{
! 			yylval.namelist = newname(yytext);
  			return (NAME);
  		}
  

--- 29,36 -----
  			return (KEYWORD);
  		}
  
! {DIGIT}*{ALPHA}{NAMECHR}*	{
! 			yylval.namelist = newname(lower(yytext));
  			return (NAME);
  		}
  
***************
*** 33,40
  			yylval.namelist = newname(yytext);
  			return (NAME);
  		}
- 
- {ALPHA}		return (NAME);
  
  {DIGIT}+	{
  			yylval.number = atoi(yytext);

--- 33,38 -----
  			yylval.namelist = newname(lower(yytext));
  			return (NAME);
  		}
  
  {DIGIT}+	{
  			yylval.number = atoi(yytext);
*** 4.2/htable.h	Thu Nov  3 15:35:32 1983
--- htable.h	Wed Apr 16 10:47:32 1986
***************
*** 34,39
  #define	KW_HOST		3
  
  struct name *newname();
  char *malloc();
  
  char *infile;			/* Input file name */

--- 34,40 -----
  #define	KW_HOST		3
  
  struct name *newname();
+ char *lower();
  char *malloc();
  
  char *infile;			/* Input file name */
================
End of diffs.
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Wed 16 Apr 86 14:20:33-CST
From:      DB.CHAMBERS@MCC.ARPA
To:        mike@BRL.ARPA
Cc:        hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, c3@MCC.ARPA
Subject:   UNIX htable and slashes

Mike,

Regarding your message (brought to my attention by <ai.clive@mcc.arpa>):

--------
	Return-Path: <tcp-ip-RELAY@SRI-NIC.ARPA>
	Received: from SRI-NIC.ARPA by MCC.ARPA with TCP; Wed 16 Apr 86 06:07:28-CST
	Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Tue 15 Apr 86 04:52:09-PST
	Date:     Tue, 15 Apr 86 6:39:04 EST
	From:     Mike Muuss <mike@BRL.ARPA>
	To:       Hostmaster@sri-nic.arpa
	cc:       tcp-ip@sri-nic.arpa
	Subject:  Bad host entries
	
	Turns out that there is more fun.
	The Berkeley HTABLE program will not accept CPUs of the form:
	SUN-2/50,they must instead be written SUN2-50.  No slashes.
	
	There are 5 such errors in the new host table:
	jove.caltech.edu
	ganymede.caltech.edu
	leda.caltech.edu
	laplace.db.mcc.com
	weierstrass.db.mcc.com
	
	This problem exists with both 4.2 and 4.3 BSD version of HTABLE,
	so I suggest that the table gets fixed.
		Best,
		 -Mike
--------

Bull pucky.

0. htable is perfectly capable of handling the slash. There are slashed 
   CpuTypes all through hosts.txt. Why should just these five bomb out?

   htable's parser expects OpSys, CpuType, and so forth to be a NAME 
   token, which the lexical analyzer returns on encountering:

	[A-Z]	or	[A-Z][0-9A-Z./-]*[0-9A-Z]

   The embedded slash is quite kosher.

   There ARE problems with hosts.txt.530, but this isn't one of them.

1. htable does not like lower case in NAMEs; get those entries
   containing "Berkeley" out of there! ("BERKELEY", perhaps?)

2. The lexer throws away the ;-commented lines at the beginning;
   the parser is reporting syntax errors on line numbers other than
   physical line numbers in the hosts source file.

   The five offending hosts are in fact

HOST : 192.12.185.21 : BUCSC.BU.EDU,BUCSC,DEATHSTAR : 3B5 : UNIX : TCP/TELNET,TCP/SMTP,TCP/FTP :
HOST : 192.12.185.22 : TIE1.BU.EDU,TIE1 : 3B2 : UNIX : UDP :
HOST : 192.12.185.23 : TIE2.BU.EDU,TIE2 : 3B2 : UNIX : UDP :
HOST : 192.12.185.24 : TIE3.BU.EDU,TIE3,BUDD : 3B2 : UNIX : UDP :
HOST : 192.12.185.25 : TIE4.BU.EDU,TIE4 : 3B2 : UNIX : UDP :

   As noted above, htable expects a NAME to begin with an ALPHA, i.e. [A-Z].
   3Bx doesn't quite cut it.

3. I edited the "Berkeley" (->"BERKELEY") and "3Bx" (-> "ATT3Bx") entries 
   in hosts.txt.530 and ran it through htable on a 4.2 and a 4.3 beta 
   machine. Worked fine on both.

4. I agree completely with your comment "I suggest that the table gets fixed."
--------

Cheers,
  John 

-------
-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Wed 16 Apr 86 15:14:33-CST
From:      DB.CHAMBERS@MCC.ARPA
To:        mike@BRL.ARPA
Cc:        hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, c3@MCC.ARPA
Subject:   UNIX htable and slash, P.S.

Mike,

Ahem. I should note that our hosts.txt is massaged quite a bit before
being htable'd, hence my error line numbers are probably farther from the
truth than the amount by which lex/yacc usually blows it. Same claim
regarding the defective hosts, however.

Cheers,
  John
-------
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Apr 86 18:19:15 EST
From:      Chris Torek <chris@gyre.umd.edu>
To:        beta43_bugs@monet.berkeley.edu
Cc:        tcp-ip@sri-nic.arpa, unix-wizards@brl.arpa
Subject:   htable breaks on current nictab.txt (with fix)
Index: /usr/src/etc/htable/scan.l 4.3Beta Fix

Description:
	As you probably know by now, the NIC tables acquired some
	new names that broke htable.  I do not speak of the one-
	letter names that leaked out of BU, but rather of the
	lowercase in all the `.Berkeley.EDU', and of the `CPUType'
	`3B5'.

Repeat-By:
	Run htable on the current nictab.txt.

Fix:
	Below.  This is not terribly clean, but suffices for the
	moment...

Chris

RCS file: RCS/scan.l,v
retrieving revision 1.1
retrieving revision 1.2
diff -c2 -r1.1 -r1.2
*** /tmp/,RCSt1001893	Wed Apr 16 18:12:31 1986
--- /tmp/,RCSt2001893	Wed Apr 16 18:12:32 1986
***************
*** 16,22 ****
  BLANK	[ \t]
  DIGIT	[0-9]
! ALPHA	[A-Z]
! ANUM	[0-9A-Z]
! NAMECHR	[0-9A-Z./-]
  
  %%
--- 16,22 ----
  BLANK	[ \t]
  DIGIT	[0-9]
! ALPHA	[A-Za-z]
! ANUM	[0-9A-Za-z]
! NAMECHR	[0-9A-Za-z./-]
  
  %%
***************
*** 42,45 ****
--- 42,52 ----
  
  {ALPHA}		{
+ 			yylval.namelist = newname(yytext);
+ 			return (NAME);
+ 		}
+ 
+ {DIGIT}+{ALPHA}{NAMECHR}* {
+ 			fprintf(stderr, "Warning: nonstandard name \"%s\"\n",
+ 				yytext);
  			yylval.namelist = newname(yytext);
  			return (NAME);
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 86 22:08:12 EST
From:      Mel <Pleasant@RED.RUTGERS.EDU>
To:        Hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   more on htable
I'm not on this list at the moment so if this problem has already been
reported, please excuse....  The 4.2 version of htable will also not
accept the cpu type "3B2".  If you look at the parser code, you see that
NAME must begin with an alphabetic.....

			-Mel
-------
-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Apr 86 10:17:18 -0500
From:      speter@ATHENA.MIT.EDU
To:        tcp-ip@sri-nic
Subject:   --Please remove me---
Please remove me from this mailing list.  Thankyou.

			peter osgood
		speter@trillian.MIT.EDU
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 86 11:18 PST
From:      Tom Perrine <tom@LOGICON.ARPA>
To:        tcp-ip@sri-nic
Cc:        Tom Perrine <tom@logicon>
Subject:   Re: The Host Table
Several of the latest versions of the hosttable have been imaginative
in the interpretation of RFC952. This has caused problems for some sites
(especially those running BSD).

May I suggest that RFC952 be updated to be a little more precise with
its definition of "host name" and "cpu type"?

The RFC states that host names are "up to 24 characters, drawn from the
alphabet (A-Z), digits (0-9), minus sign (-), and period (.)." Note
that this sort of implies that only uppercase alphabetics will be
allowed.  It is later noted that "no distinction is made between upper
and lower case."

As to "cpu type", you are referred to "Assigned Numbers".  Could the
SYNTAX for a cpu type be reproduced here?  I am not sure that there IS
a syntax for forming cpu type, just the list of known cpu types.

With respect to the BBNCA problem, the rfc states that "single
character names or nicknames are not allowed", so 4.[23] failed on an
illegally-formed HOST line. (Catastrophically, unfortunately.)

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Thu 17 Apr 86 11:22:43-PST
From:      Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA>
To:        DB.CHAMBERS@MCC.ARPA
Cc:        mike@BRL.ARPA, hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, c3@MCC.ARPA, OLE@SRI-NIC.ARPA
Subject:   Re: UNIX htable and slashes
Foo. Berkeley petitioned us for the longest time to take the mixed case
name contrary to our original policy. We finally gave in and said, yes
you can have a mixed case name (in line with the domain specification).
If this breaks UNIX, then take it up with BERKELEY, (or Berkeley) as
most of the UNIX on the net comes from there. OK?

Ole
-------
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Apr 86 14:25:33 pst
From:      mckenney@sri-unix.ARPA (Paul E. McKenney)
To:        tcp-ip@sri-nic.ARPA
Subject:   NIC host table conversion
It is rumored that a new version of the Unix utility to convert the NIC
host table exists somewhere.  Is this true?
I have obtained a hacked version of the utility that handles the current host
table, but full letter-of-the-law compliance with RFC952 seems to require more
than just minor hacking.  The version I have demands that at least one of the
characters in '[a-zA-Z]/-' appear in the cputype and opsysname fields, in direct
violation of the RFC, which would allow a cputype like '10.2.3.4', for example.

Any pointers to the improved version would be deeply appreciated.
	Thanx, Paul (mckenney@sri-unix.ARPA)
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Apr 86 12:16  EST
From:      David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
To:        Chris Torek <chris%gyre.umd.edu@MIT-MC.ARPA>, Hostmaster@SRI-NIC.ARPA, mike@BRL.ARPA, tcp-ip@SRI-NIC.ARPA
Cc:        GouldBugs@BRL.ARPA, Unix-Wizards@BRL.ARPA
Subject:   Re:  Host table & 4.2BSD problem
    Date: Wed, 16 Apr 86 11:46:59 EST
    From: Chris Torek <chris@gyre.umd.edu>

    Note that the 4.3 htable still cannot handle lowercase, nor does
    it like host names of the form `3B5' (begins with a digit).  I
    plan to throw out the current source for htable and start over...

I'm glad somebody had the sense to fix broken parsers instead of
administratively imposing restrictions on what companies call their
machines.  You just can't prefice the company name onto the machine
name.  Suppose 3Com built a machine called the 747?


-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Apr 86 14:06:23 cst
From:      jbc%mccdb-dillo@mcc.ARPA (John B. Chambers)
To:        DB.CHAMBERS%MCC.ARPA@mcc.ARPA, OLE%SRI-NIC.ARPA@mcc.ARPA
Cc:        c3%MCC.ARPA@mcc.ARPA, hostmaster%SRI-NIC.ARPA@mcc.ARPA, mike%BRL.ARPA@mcc.ARPA, tcp-ip%SRI-NIC.ARPA@mcc.ARPA
Subject:   Re: UNIX htable and slashes

Foo indeed.

A fix has been posted on unix-wizards for the current htable
"problem," but ...

The grammar in rfc952 defines

	<domainname>	::= <hname>
	...
	<hname>		::= <<name>*["."<name>]
	...
	<name>		::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
	...

What, pray tell, is a <let> ? It certainly doesn't appear later in the grammar.
It's evidently not the same as a <print-char>, used in the definition of
commentary text. Could it be that I'm supposed to go back and read the
"Assumption" that says a "'name' ... is a text string ... drawn from the
alphabet (A-Z), digits (0-9), minus sign (-), and period (.) ...?" Shall
I then infer (A-Z) implies (a-z)? Ok, how about the definition for cputype:

	<cputype> 	::= PDP-11/70 | DEC-1080 | C/30 | CDC6400...etc.

Sorry, but my parser doesn't understand "...etc." Likewise for opsys:

	<opsys>		::= ITS | MULTICS | TOPS20 | UNIX...etc.

I haven't seen anything here starting with a digit yet. Do I assume that
3B5 is thus invalid, or that anything goes?

I've personally seen four lexical variations for htable this week.
That shouldn't really have to happen.

Tell you what. If <somebody> agrees on a complete grammar, I'll just 
bet that <somebody-else> would be happy to implement it. :-)

--------
Cheers,
  John
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Thu 17 Apr 86 16:48:05-PST
From:      Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA>
To:        hoey@NRL-AIC.ARPA
Cc:        DB.CHAMBERS@MCC.ARPA, mike@BRL.ARPA, hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, c3@MCC.ARPA, OLE@SRI-NIC.ARPA
Subject:   Re: UNIX htable and slashes
Having a name in a particular case is not contrary to the spirit of
RFC 952. Of course it doesn't make a difference to the software, but
it may make an emotional difference to the users. Names are very
touchy things to some people.

We resisted mixed case for a while due to the extra work involved in
maintaining the database. 

Ole
-------
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Apr 86 15:40:53 EST
From:      Chris Torek <chris@gyre.umd.edu>
To:        DB.CHAMBERS@mcc.arpa, mike@brl.arpa
Cc:        c3@mcc.arpa, hostmaster@sri-nic.arpa, tcp-ip@sri-nic.arpa
Subject:   Re:  UNIX htable and slashes
The off-by-three error in line numbers is caused not by the lexer
scan.l, but rather by a very bogus routine in htable.c that copies
the first three comments from the input table to the Unix-style
host table.  I say `very bogus' because if there are fewer than
three comment lines, it eats the first non-comment line, never to
be seen again.  And of course it does not inform the error routine
of the number of lines it ate.

Chris

P.S.  Lest you beleive I think the current htable is awful, no, it
is, I think, just far too trusting.  There is a certain elegance in
using a generalised scanner and parser for this task.  Of course
there is a certain cost as well: htable is extremely slow.

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Apr 86 16:09:08 EST
From:      Ra <root@bu-cs.bu.edu>
To:        JNC@xx.lcs.mit.edu, makers@bbncct.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Crime and Punishment

Sending massive amounts of stuff as punishment is more likely
to punish various system administrators who have to clean the
mess up, and likely aren't culpable (remember, in distributed
systems the image of a room full of users under the admin's
watchful eye is probably misleading.)

You should have more faith in the desire people have to maintain
their image in the eyes of others and just send a quick e-mail
note if that's what you feel like doing, it should be sufficient.

It reminds me once of a conversation (years ago, when I was a young
hacker) with a faculty member about some admin who had royally teed
me off: "I'm not gonna let this one go.." "What are you gonna do?
Crash the system?" (long pause of confusion) "No, I'm gonna go to
their office and yell at them" "Oh, right" "right...".

	-Barry Shein, Boston University

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Apr 86 17:28  EST
From:      David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
To:        Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA>, DB.CHAMBERS@MCC.ARPA
Cc:        mike@BRL.ARPA, hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, c3@MCC.ARPA
Subject:   Re: UNIX htable and slashes
    Date: Thu 17 Apr 86 11:22:43-PST
    From: Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA>

    Foo. Berkeley petitioned us for the longest time to take the mixed case
    name contrary to our original policy. We finally gave in and said, yes
    you can have a mixed case name (in line with the domain specification).
    If this breaks UNIX, then take it up with BERKELEY, (or Berkeley) as
    most of the UNIX on the net comes from there. OK?

Bingo!  This is the 1980s, after all.  Even the 1970s had mixed case.  I
know of some systems of the 1960s that had mixed case.  When was the
last ASR-33 made, anyway?

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 1986 17:45:29 EST (Thu)
From:      Dan Hoey <hoey@nrl-aic.ARPA>
To:        Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA>
Cc:        DB.CHAMBERS@MCC.ARPA, mike@BRL.ARPA, hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, c3@MCC.ARPA
Subject:   Re: UNIX htable and slashes
    Date: Thu 17 Apr 86 11:22:43-PST
    From: Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA>

    Foo. Berkeley petitioned us for the longest time to take the mixed case
    name contrary to our original policy. We finally gave in and said, yes
    you can have a mixed case name (in line with the domain
    specification)....

I have no problem with the host table being in mixed case, though a
little slow experimentation would have made the changeover easier.  RFC
952 says no case distinction is made, perhaps warning us that mixed
case might occur in the table.  But this ``petitioning'' thing sounds
like someone is making a distinction, and that is contrary to RFC 952.
Maybe we should start petitioning NIC to periodically change the case
of random characters in the table, just to make sure no one thinks that
it makes a difference.

Dan
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Apr 1986  23:07 EST
From:      Rob Austein <SRA@XX.LCS.MIT.EDU>
To:        "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
Cc:        sra@XX.LCS.MIT.EDU, TCP-IP@SRI-NIC.ARPA
Subject:   PCs and TACs
The last time I saw this question go by (NIC survey to host
administrators, maybe?), John Romkey commented that an alternative to
TAC support for KERMIT would be a TAC option that would pass IP
packets down the RS232 connection, thus allowing direct use of FTP (or
any other network protcol) from PCs.  MIT-LCS already has something
vaugely like this for faculty and staff with PCs at home.  Now that
the TACACS system is in place a direct IP option on TACs wouldn't be
any particular security risk, either, for them as worry about such
things.  Direct IP support is a good bit more flexible than support
for a particular bulk data protocol, so it is something to think
about.

--Rob
-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Apr 86 08:34:36 pst
From:      ARPA@mckenney (Paul E. McKenney)
To:        hostmaster@sri-nic.ARPA, tcp-ip@sri-nic.ARPA
Subject:   Re:* Unix htable and slashes
How about a policy of informing sites of changes in policy?
			Paul (mckenney@sri-unix.arpa)
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Apr 86 11:07:44 -0600
From:      Dave Cohrs <dave@rsch.wisc.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Wisconsin changes network numbers...
I know there are a lot of sites that still don't use the name server.
I thought y'all might want to see the following notice so there
isn't as much bouncing mail on the 25th...

This applies to the hosts in the 'wisc.edu' domain.

dave

------- Forwarded Message

From:    Brian Pinkerton <brian@rsch.wisc.edu>
Date:    Thu, 17 Apr 86 16:41:48 -0600
To:      msgs-all
Subject: IMPORTANT ARPANET INFO


On Friday, April 25, we will be converting to a new set of Internet
host numbers on ALL local machines.  The change is motivated by a
desire to provide a more organized, more expandable network
environment.

On the 'flag day', you will not notice any difference on local
machines.  We expect to complete the local conversion process sometime
during the early morning (4:00-6:00am).  You may still reference
machines by whatever names you called them before, although their
associated numbers will be different.  Expect most local machines to be
down sometime during that (4-6am) period for conversion (this includes
the workstations).

The problems with the conversion will come from outside sites on
ARPANET who may not have up to date host tables.  The Network
Information Center will have prepared a new hosttable in advance of the
conversion, so sites that are on the ball will have no problem.  Those
sites that do not fetch this new host table will unable to reach
Wisconsin until they do.  I will be mailing all site administrators
Wednesday to notify them of this change.

brian

------- End of Forwarded Message

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Apr 86 15:46:07 -0800
From:      Richard Johnson <raj@ICS.UCI.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Need good source of ethernet cable
We need to purchase about 300 meters of ethernet cable and are looking
for a good inexpensive (not cheap! :-)) source.  Our previous source
delivered cable with connectors which simply screwed onto the ends.  We have
sometimes had problems with these coming off as the transceiver is attached.
What we would really like is what (I believe) is called "crimp" type
connectors (like what you get from Inmac I think) and it's hard for me to
believe that we have to pay Inmac prices in order to get them.

Any ideas?  You should probably send directly to me.  If anyone thinks
a summary to the net is necessary, I'll be glad to oblige.

raj.
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 1986 0922-EST
From:      Kevin Paetzold <PAETZOLD@MARLBORO.DEC.COM>
To:        tcp-ip@sri-nic
Subject:   [Kevin Paetzold <PAETZOLD@MARKET>: Re:  UNIX htable and slashes]
i meant to send this to the list but somehow that does not seem to have 
happened.

- - - - - - - Begin message from: Kevin Paetzold <PAETZOLD@MARKET>
Date: 18 Apr 1986 0918-EST
From: Kevin Paetzold <PAETZOLD@MARKET>
To: Chris Torek <chris@gyre.umd.edu>, DB.CHAMBERS@mcc.arpa,
    mike@brl.arpa
telephone: 617-460-2203
Subject: Re:  UNIX htable and slashes
Message-ID: <"MS11(5146)+GLXLIB0(4)-4" 12199813787.19.126.7685 at MARKET>
References: Message from Chris Torek <chris@gyre.umd.edu>
              of 18-Apr-86 0318-EST
In-reply-to: <8604172040.AA06529@gyre.umd.edu>

Isn't it about time this Unix htable discusion got taken off line.
i got tired of reading about it 25 messages ago.  it is certainly much more
annoying than the occasional subscription message to this list.  

   --------
- - - - - - - End forwarded message
   --------
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Apr 86 09:33:49 EST
From:      mazzarelli%h-sc4@harvard.HARVARD.EDU
To:        OLE@SRI-NIC.ARPA, hoey@nrl-aic.ARPA
Cc:        DB.CHAMBERS@MCC.ARPA, c3@MCC.ARPA, hostmaster@SRI-NIC.ARPA, mike@BRL.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: UNIX htable and slashes
(Quick note--ASR 33s went out of production only about ten years ago.)

                          --pm@harvard.edu
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 1986 10:11:19 EST
From:      PADLIPSKY@USC-ISI.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Telnet Options stuff
Perhaps I just failed to spot it, but my impression is that
in the midst of reminding us all that New Telnet "Binary" is not
identically equal to Old Telnet "Raw" nobody ever told Phil Karn
explicitly that "Echo" doesn't imply/include either.  Everybody's
probably worked it out independently, but just in case....

On the Raw vs. Binary issue, I think I recall that the "improvement"
Binary made was that you could get out of it (i.e., IACs still
applied) and I also think I was against it then.  Given around 14
more years of maturity/mellowing/tiredness, I now think that in
addition to Binary, Telnet should offer a Raw Option that you
are in forever once negotiated (where forever, of course, means
until the connection is closed).  If people agree, they should
probably CC: Postel@USC-ISIB with their "votes".  (No apology
seems to be needed [from me to Jon], since this mailing list is
clearly not "offical" and he'd be put to even more trouble if I
went to the bother of making the proposal in an RFC.  Right, Jon?)

cheers, map
-------
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Apr 86 11:50:01 cst
From:      jbc%mccdb-dillo@mcc.ARPA (John B. Chambers)
To:        DB.CHAMBERS%mcc.ARPA@mcc.ARPA, chris%gyre.umd.edu@mcc.ARPA, mike%brl.ARPA@mcc.ARPA
Cc:        c3%mcc.ARPA@mcc.ARPA, hostmaster%sri-nic.ARPA@mcc.ARPA, tcp-ip%sri-nic.ARPA@mcc.ARPA
Subject:   Re:  UNIX htable and slashes
Absolutely correct, which is why I posted my P.S. -- my manipulations
of the host table before htabling were causing my entries to be off
by a variable number in the 20-30 range when syntax errors were reported.
Running a virgin hosts.txt through htable produces the constant
error in the reported line number you mention.

Thanks for that clarification, Chris.

Cheers,
  John
-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Apr 86 12:06:47 cst
From:      jbc%mccdb-dillo@mcc.ARPA (John B. Chambers)
To:        OLE%SRI-NIC.ARPA@mcc.ARPA, hoey%nrl-aic.ARPA@mcc.ARPA
Cc:        DB.CHAMBERS%MCC.ARPA@mcc.ARPA, c3%MCC.ARPA@mcc.ARPA, hostmaster%SRI-NIC.ARPA@mcc.ARPA, mike%BRL.ARPA@mcc.ARPA, tcp-ip%SRI-NIC.ARPA@mcc.ARPA
Subject:   Re: UNIX htable and slashes

As I told Ole, yes, 952 mumbles in the assumptions section that no
case distinction is made. That's still no apology for a slightly
defective grammar spec for a file that has been, and for some sites
will continue to be for a while, pretty important. RFC822, Section 3.3,
was a good example of a decent lexical specification (from an
implementor's point of view).

And as Ole mentioned earlier, the "policy" has long been to use
only upper case. Thus, we have a "policy", a "petition", and a
slightly vague specification. The distributed htable addressed
what was once a "safe" (because of "policy"?) subset, I suppose.

[P.S. I liked your closing suggestion. :-) ]
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 86 15:48 EST
From:      JHodges @ DDN2.ARPA
To:        brolsma @ bbn-spca.arpa
Cc:        jnc @ xx.lcs.mit.edu, unix-wizards @ brl.arpa, tcp-ip @ sri-nic.arpa
Subject:   Re:   requests
I second the motion for a summary of the parts of netdom,
pathnames, list-of-lists, etc.  Basically, a short discussion of
how to get added to lists, whom to ask for information when you
can't seem to find it in the logical places, etc.

FLAMING serves no purpose in this instance!
How would Noel like to receive SF-LOVERS for three weeks???
That does not solve the problem!

Jim

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 86 16:36 EST
From:      JHodges @ DDN2.ARPA
To:        tcp-ip @ sri-nic.arpa, unix-wizards @ brl.arpa
Cc:        JHodges @ DDN2.ARPA
Subject:   Requests/Crime and Punishment
Okay,
So everyone agrees that at lest something ought to be done.
If there is any interest in getting a summary produced,
I volunteer to do it if I can get the cooperation of others 
on the net.

If there is sufficient interest in this, let me know.  
Perhaps Chuq can start things off by sending me a copy of
his "etiquette" document.  
Would anybody be willing to volunteer some time on their host
for me to edit this thing? (I only have access to E-mail currently).
If not, I'll still do it!

Okay, let's get some ideas and suggestions for things that you would
like to see put into this document.  Also, specific actions that 
the user can take to access groups and networks which are not
currently known to the NIC.

Oh yes.  Reply to me directly, okay?

Jim

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 1986 18:19-EST
From:      CERF@USC-ISI.ARPA
To:        SRA@XX.LCS.MIT.EDU
Cc:        WANCHO@SIMTEL20.ARPA, TCP-IP@SRI-NIC.ARPA
Subject:   Re: PCs and TACs
Accepting IP on an unprotected (ie no link level) line could
be pretty messy. I would suggest that a reliable async link level
would be appropriate which does error detection and retransmission
if you go down this path.

Vint
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 1986 18:24-EST
From:      CERF@USC-ISI.ARPA
To:        PADLIPSKY@USC-ISI.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Telnet Options stuff
I have been giving some thought to this whole raw binary question in the
context of messaging and have to believe that a mode you can get into
but not out of seems very awkward.  If I had my choice, I would prefer
a mode which still has enough structure that you can distinguish control
from data - whether this means looking for escape sequences and using
quote characters or having byte counts/framing conventions is a matter
of design choice.  If I had to vote, I guess it would be against the
diode protocol (one-way - enter at your own risk...).

Vint
Z
-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Apr 86 23:02:42 cst
From:      wupeter wu <pwu@maccunix>
To:        tcp-ip-request@sri-nic.arpa
Subject:   Ethernet Board
Does anyone know where I can buy Ungermann-Bass Ethernet controllers
#2274A or @2273A for the IBM RT PC?

Any info or pointers or hints will be greatly appreciated.

peter
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Apr 86 23:22:41 est
From:      romkey@BORAX.LCS.MIT.EDU (John Romkey)
To:        CERF@USC-ISI.ARPA
Cc:        SRA@XX.LCS.MIT.EDU, WANCHO@SIMTEL20.ARPA, TCP-IP@SRI-NIC.ARPA
Subject:   raw IP through a TAC dialup
   Date: 18 Apr 1986 18:19-EST
   Sender: CERF@USC-ISI.ARPA
   From: CERF@USC-ISI.ARPA

   Accepting IP on an unprotected (ie no link level) line could
   be pretty messy. I would suggest that a reliable async link level
   would be appropriate which does error detection and retransmission
   if you go down this path.

   Vint

Actually, I've used SLIP, which doesn't do any error detection that
the serial line doesn't do, over a 1200 baud dialup several times
recently, between a PC at home and a VAX ant MIT. Error rates aren't
bad at all. There are some bigger problems, though:
	- timeouts in TCP/IP implementations. Many programs seem to
	  expect fairly high speed connections. They just don't hack
	  1200 baud very well. Retransmitting a 500 byte packet over a
	  1200 baud line is a disaster!  Things are better now than
	  they were two years ago when we did some experiments at MIT
	  with a (really stupid) serial line protocol and some dialups
	  on a gateway (which Rob mentioned a couple of messages
	  back), but most TCP implementations just aren't up to
	  performing well over networks whose speeds range from 1200
	  bps to 10Mbps.

	- addressing. This is an issue SLIP doesn't, um, address.
	  Suppose you've got a bunch of dialups on a gateway, in a
	  hunt group. The IP address of each dialup pretty much needs
	  to be set by the gateway, not the machine that's dialing in.
	  SLIP requires that both ends have "preordained" addresses
	  and already know them, but in this case, the machine that's
	  dialing in has to figure out its address. I have a few ideas
	  for fixing up this problem but I'm not sure how practical it
	  is to implement them.

	  (BTW, I'm only picking on SLIP 'cause it's there and people
	  are implementing it...)

	Also, you're going to turn the TAC into a real gateway, which
might be more than it can handle. I don't really know.

	I don't mean to be discouraging, I think it's a great idea,
being able to send raw IP datagrams through a TAC, but there are some
problems to think about. If someone were to implement SLIP for the
TAC, I've got IBM PC software they could use right now. If someone
does some other serial protocol, I'll implement it, too, provided that
it's not too monstrous.
	Is there anyone out there working on this sort of thing right now?
					- john
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Apr 86 02:55:58 EST
From:      Chris Torek <chris@gyre.umd.edu>
To:        CERF@usc-isi.arpa, romkey@mit-borax.arpa
Cc:        SRA@xx.lcs.mit.edu, TCP-IP@sri-nic.arpa, WANCHO@simtel20.arpa
Subject:   Re:  raw IP through a TAC dialup
SLIP dialins can select their addresses in any number of ways.  If
your machine `knows' its own Internet address, it can log in using
a name that `means' that address.  If it is willing to take pot
luck, it can log in using a different name which implies an extra
bit of protocol: the remote end will pick a number and send it,
*before* starting up the SLIP protocol.

I prefer that remote machines have fixed addresses, for aesthetic
reasons.  If you do not like having one login per remote machine
---though we who use UUCP have found that this is most definitely
a good idea, in general---you can have a different bit of protocol
where the dialling machine gives its number to the dialled machine
before either starts up SLIP.

Chris
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Sat 19 Apr 86 13:34:20-MST
From:      Mark Crispin <MRC@SIMTEL20.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Unix htable and slashes
I've got a great idea.  Why don't we change our software to invert the
case?  That is, we'll do just like Unix and show SUMEX-AIM.ARPA as
"sumex-aim.arpa" (ugh, acronyms should be upper case), but our friends
at Bezerkeley will get "bERKELEY".  The point is to cure people of being
obscessed with case and worry about important details.
-------
-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 1986 17:36:12 EST
From:      MILLS@USC-ISID.ARPA
To:        romkey@MIT-BORAX.ARPA, CERF@USC-ISI.ARPA
Cc:        SRA@XX.LCS.MIT.EDU, WANCHO@SIMTEL20.ARPA, TCP-IP@SRI-NIC.ARPA, MILLS@USC-ISID.ARPA
Subject:   Re: raw IP through a TAC dialup
In response to the message sent  Fri, 18 Apr 86 23:22:41 est from romkey@BORAX.LCS.MIT.EDU 

We have been using 1200-bps asynchronous IP connections since 1979 with
generally good results, but usually with hosts which implement the "Nagle
Algorithm" or something similar. The protocol is in fact somewhat fancier
than simple stuff-'n-send and includes timekeeping, address recognition and
reachability determination, but does not retransmit (by intent) in case of
error. See RFC-891 for further details. We also have implemented the MIT
PCIP serial-line protocol to keep our PC's babbling with the Internet.

I have personally used Internet protocols on the Amateur AX.25 packet-radio
channel with mixed results, primarily due to massive congestion and broken
implementations also sharing the channel. See RFC-981 for was stories in that
arena. The raw channel rate is 1200 bps and is shared by up to maybe a hundred
stations at different times, so you can see TCP must be almost as heroic as
when negoitating an ARPANET<->MILNET path nowadays.

Dave
-------
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 1986 16:43-PST
From:      William "Chops" Westfield <BillW@SU-SCORE.ARPA>
To:        CERF@USC-ISI.ARPA
Cc:        romkey@MIT-BORAX.ARPA, SRA@XX.LCS.MIT.EDU WANCHO@SIMTEL20.ARPA, TCP-IP@SRI-NIC.ARPA
Subject:   Re: raw IP through a TAC dialup
Seems like some varient of RARP in the TAC ought to solve that
problem failrly easilly...

BillW
-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 1986 18:15-EST
From:      CERF@USC-ISI.ARPA
To:        romkey@MIT-BORAX.ARPA
Cc:        SRA@XX.LCS.MIT.EDU, WANCHO@SIMTEL20.ARPA TCP-IP@SRI-NIC.ARPA
Subject:   Re: raw IP through a TAC dialup
John,

good point about addressing. The commercial world is struggling with
dial-up X.25 which is now being standardized as X.32 - the problem is
to identify the caller and to bind the identity to the X.25 address.
One might contemplate "logical IP" addresses which are assigned to the
caller once the caller is suitable authenticated. Then comes the problme
or initiating calls to this "floating"logical IP address - has many
of the same problems as the problem of internet routing when a network
in the internet becomes partitioned.

Vint
-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Apr 86 21:57:54 PST
From:      karels@monet.berkeley.edu (Mike Karels)
To:        Ole Jorgen Jacobsen <OLE@sri-nic.arpa>, tcp-ip@sri-nic.arpa
Cc:        hostmaster@sri-nic.arpa
Subject:   Re: UNIX htable and slashes
Although I wasn't directly involved with the request to change the case
of the Berkeley.EDU domain, I was around while it was being discussed.
The intent of the change was to test the ability of the 4.3BSD UNIX
nameserver to maintain case, at the request of several outside organizations.
No one had any expectation that the HOSTS.TXT file would be changed along
with the name server database, and we were as surprised as anyone else
when we were unable to process the new host file.  I would suggest
that HOSTS.TXT be changed back to the original all-caps format.
(Otherwise, the Berkeley hosts might as well be lower case along
with the domain name!)

I'm even more surprised at the volume of mail that this has generated.
It took me a lot less time to change the host table scanner than to
filter out all of the junk mail.

		Mike
-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Apr 86 13:10:04 EST
From:      hsphup!elvy%lownlab.UUCP@harvard.HARVARD.EDU (999999@Marc Elvy)
To:        lownlab!harvard!"tcp-ip@sri-nic.arpa"
Subject:   Serial IP Addressing
In response to:
	From: BORAX.LCS.MIT.EDU:romkey (John Romkey)
	Message-Id: <8604190422.AA22723@BORAX.LCS.MIT.EDU>
	Subject: raw IP through a TAC dialup

Hello, John.  To respond to your query, my company has had some people working
on precisely the problems you indicated with the SLIP code.  Without presenting
a sales pitch, allow me to say that we have a product (called "connect", for
what that's worth) that

(1) uses a serial line protocol (not SLIP) for IP packet transmission,
(2) has been tested from 1200 to 19200 bits per second over serial lines
    (it IS dependent upon the operating system's implementation of TCP/IP)
(3) utilizes a simple handshaking protocol upon initial connection so that
    modems (yes, several sites are running it over unconditioned phone lines
    using 9600bps full-duplex modems) do not have to be dedicated to one
    remote host, and
(4) detects dropped (physical) connections and automatically attempts to
    re-establish the lost link (one can define autodialers to it).

The product is not mature, but it has been running successfully, and the
automatic loss-of-carrier recovery has turned out to be very useful,
especially when operating over noisy phone lines.

I will avoid saying more in the interest of keeping the discussion academic.
I will be happy to provide more details, though, to interested persons.

Marc Elvy (elvy@harvard.HARVARD.EDU is simplest)
Marble Associates, Inc.
Cambridge, Massachusetts
(617) 354-3557
-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Mon 21 Apr 86 23:59:39-EST
From:      "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
To:        brescia@BBNCCV.ARPA, tcp-ip@SRI-NIC.ARPA
Cc:        JNC@XX.LCS.MIT.EDU
Subject:   Re: ICMP responses to broadcasts
	Mike, sorry, but I think dropping incoming broadcast IP
packets is bogus. This will break at least one existing ICMP message.
(In addition, this won't fix the case where someone sends packets
directly the the gateway with a destination address that translates to
broadcast.)
	My opinion is that the *right* thing is for the gateway's IP
layer to recognize the IP broadcast addresses (thanks to 4.2 the C
gateway recognizes the illegal net.0's as well as net.1's, all 0's,
all 1's, etc) and do the right thing.  Network layers should discard
(with an ICMP Host Unreachable error message, if you want) packets
which are sent to a valid IP address which is not an IP broadcast
address but which is the local broadcast address. I.e., a packet
shouldn't get broadcast unless it specifically asks for it.
	IP packets which are addressed to the broadcast address should
be handled as stated in the RFC (if you want a minimal implementation
in the gateway, you can just accept them for local processing only, or
simply ignore them). No ICMP error messages should be returned by
*anyone* in response to any message sent to an IP broadcast address.

	Noel
-------
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Apr 86 02:01:36 EST
From:      Barry Shein <bzs@bu-cs.bu.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   Thought on Serial IP links

I have been thinking about the problem of attaching computers from,
typically, homes to, for example, a campus. Perhaps a little out-loud
thinking would move us all closer to a solution as, I agree, the
emergence of internet protocols on PCs does present some new and
interesting problems. Further, I am presuming in my model that an
ethernet exists at the 'campus' end. Sites that do not fit this
model could at modest cost, or perhaps other similar solutions
could be made to fit (the framework is really more general.)

Problems

1. A PC will typically connect to a campus over a serial line via
a phone connection to/from a pair of modems. A typical scheme is
to dial-up a capable host as a user and then request that the line
be set into a special mode to pass packets, that is, a point to
point link (p-p) analogous to ones currently in use.

The primary problem with this model is that the host in question is
being used as a packet switch if (and this is likely) the primary
target of packets is not the host which was dialed. Further, this
yields a milking-machine problem, although this may be unavoidable
in the near future putting it directly on the host is not the best
solution.

2. The PC needs an IP address and an internet hostname (even if one
only locally recognized.) Two obvious solutions are either the PC
stores it and announces it to the host it is p-p'd to or it uses
something analagous to RARP as suggested on this list.

The worst problem with this is that in most current schemes each
p-p link requires a NETWORK address. Various software hacks analogous
to subnetting can be used, but read on.

3. Links and identities are temporary, unlike most internet hosts
we would expect that most of these p-p links are usually NOT on-line.
In the proposed p-p model this is not a major problem, but is worth
noting for the ensuing discussion.

One easy way to solve this problem would be to put an ethernet in your
home and use one of the commercially available level 2 bridges, level
3 would be overkill here as most likely all packets on the remote
('home') side probably want to travel to the local ('campus') end
anyway.

The problem with this is the cost of providing the pieces, they are
quite simply additive to the original cost as you still need two modems
to effect the bridge, so I will reject it but note that it leads to the
next proposal.

-> What you really want is an ethernet drop cable which extends from your
house to the campus.

This could be accomplished by a magic box which had a modem at one
end, a transceiver to the campus ethernet at the other and received
packets over the serial link and simply transmitted them into the
ethernet.  Further, I believe this box could be made quite
economically out of something like the Bridge or Annex TCP
multiplexors. The only requirement would be that they be modified
quite a bit at the software level (actually, simplified, as they are
simply now IP level links) and hardware would have to either support
multiple ethernet addresses (one for each serial line) or multiple
ethernet interfaces (that is, either logical or physical translation
from each serial port to an ethernet transceiver.)

I am not enough of an electrical engineer to judge how hard it would
be to provide such a box, hopefully someone on this list could.

The general idea would be that the PC would behave as if it were
attached to an ethernet but use its serial port to pass data back and
forth. Thus, it would be responsible to answer ARP requests etc.
Conceivably this could be moved into the local multiplexor, but that
is simply an efficiency hack. I believe at the software level this
would be quite simple in the PC, mostly re-using the existing serial
and ethernet software already (typically, as in PC/IP) provided.

One problem with this is the assignment of IP addresses and their
mapping to ethernet hardware addresses. Another problem would be ARP
caches in remote hosts as this mapping would change as people hung up
the phone and others re-used the ethernet address.

Thinking about this, I would require that the PC not have an IP
address at all but use a RARP protocol. I would administer this by
having the user apply at the hosting site for a username, password,
hostname and IP address. The magical box would, on attach, allow the
user to present a username/password pair and then query a server (we
assume this box has no significant disk space, and we need a more
universal database anyhow) for the hostname/IP address to return which
will then be bound to the link.

The next problem is the cache'd IP->ethernet addresses that most hosts
would keep. One could take the attitude that it really doesn't much
matter. If a packet were sent from that host with the 'wrong' IP
address to that ethernet address the PC, realizing it is not a
gateway, would ignore the packet and the ARP cache would die away soon
enough, for security's sake the magic box could even provide this
filtering.

Another solution perhaps more appealing to those concerned with
robustness would be the addition of another protocol to the ARP suite,
namely a Flush ARP broadcast packet type. The magic box, upon
realizing that the line has hung up could broadcast the ethernet/IP
address pair with a field 'ARP_FLUSH' indicating that hosts who
currently cache this pair should immediately forget it. This, I
believe, presents little burden to anyone involved.

The niceties of this approach are 1) A user could use their
IP/hostname from any PC (or have one for each, their choice) by simply
specifying a user/password pair after dialing in 2) the PC appears to
be a part of the ethernet already in place and 3) the hardware
involved seems simple, at least to me, and cost effective, and puts
the milking-machine problem in the right place (away from a host and
into the net directly.)

Although I realize there are some large 'ifs' here, primarily the
mythical box, I do believe a scheme like this is a far better approach
than I have seen so far. I would project that the additional cost
(beyond the modems already assumed) would be on the order of $250/port
all at the 'campus' end (which is attractive, as it is re-usable and
thus easier to justify.) The major unique thought here is the assignment
of an ethernet address to each serial link.

I await your judgement. I will name it the Remote Transceiver Protocol
(RXP.) It obviously needs some more fleshing out (such as whether SLIP
is robust enough for such a link both in providing error handling and
flow control) but I think this is enough to see if it stimulates any
basic judgement on the merits of the idea.

	-Barry Shein, Boston University
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Tue 22 Apr 86 08:13:20-EST
From:      "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
To:        bzs@BU-CS.BU.EDU, tcp-ip@SRI-NIC.ARPA
Cc:        JNC@XX.LCS.MIT.EDU
Subject:   Re: Thought on Serial IP links
	If you get into the middle term future the thing to use to
go over the phone system is ISDN. In the short term future, as someone
pointed out, you can't get IP packets through a TAC without turning
a TAC into a gateway; probably not possible. Look for commercial vendors
to provide dial in gateway boxes if you want packet access over the phone.
This discussion is getting a bit long; let's move it to TELECOM or some
other suitable mailing list.

	Noel
-------
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Apr 86 09:00 EST
From:      JOHNSON%northeastern.edu@CSNET-RELAY.ARPA
To:        tcp-ip@sri-nic.ARPA, johnson%northeastern.edu@CSNET-RELAY.ARPA
Subject:   netowrk etiquette.
>Okay, So everyone agrees that at lest something ought to be
>done. If there is any interest in getting a summary produced,
>I volunteer to do it if I can get the cooperation of others
>on the net. 
>
>If there is sufficient interest in this, let me know. Perhaps
>Chuq can start things off by sending me a copy of his
>"etiquette" document. Would anybody be willing to volunteer
>some time on their host for me to edit this thing? (I only
>have access to E-mail currently). If not, I'll still do it! 
>
>Okay, let's get some ideas and suggestions for things that
>you would like to see put into this document.  Also, specific
>actions that the user can take to access groups and networks
>which are not currently known to the NIC. 
>
>Oh yes.  Reply to me directly, okay? 
>
>Jim 

     Well, one suggestion is putting a reasonable return address in
anything you send.  Please not the above doesn't have one.  Sometimes
mailers do strange and wonderful things to addreses such that direct
reply is impossible.  Or I might (I didn't in this case) know what
address to return to.  If you expect to be called back you should always
leave your phone number and address (a business card?).  So how about
an address with a real name at the end if you expect a response.  Most
people do this but not everyone by any stretch of the imagination. 

     An "etiquette" document is a great idea.  How are we to tell people 
where to get it?  Where's the obvious place?  NIC maybe?

     Cheers (and in reponse to my own request),


Chris Johnson
Northeastern University
johnson@northeastern.csnet   (CSNET)
johnson@northeastern.edu      (ARPA style. This is new, would someone 
                               please try it and let me know?)
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 1986 13:02:10 PST
From:      MOCKAPETRIS@USC-ISIB.ARPA
To:        ole@SRI-NIC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   lower caste berkeley?
Ole,

The lower case of berkeley in the host tables torpedoes TOPS-20 as well
as UNIX, or at least some TOPS-20s and some UNIXes.

This morning I went to send a message to KJD@monet.berkeley.edu.  Since
I don't touch type, I hit escape after typing kjd@monet to SNDMSG.
SNDMSG happily completed this to kjd@monet.berkeley.edu. Fine.  Moving
on, I hit CR to type the text.  SNDMSG said "? No such host".
Evidently, its in the table, so when SNDMSG reads the whole table it
finds it, but when GTHST is asked to retrieve its address, names with
lower case lose.  Perhaps bad hashing.  The lower case names are also
invisible to cnvhst.

I'm not really complaining that you did it, it has always seemed to me
that such case-sensitivity was in poor taste in any system, but just
wanted to mention that UNIX wasn't the only guilty party.

paul
-------
-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Apr 86 18:17:49 -0500
From:      bjp@mitre-bedford.ARPA
To:        tcp-ip@sri-nic.ARPA
Cc:        bjp%ulana@mitre-bedford.ARPA
Subject:   ULANA specification
     A working draft of the ULANA system specification is available for
user and industry review on the milnet.  The specification can be FTPed
from mitre-b-ulana.  The user name is guest and the password is anonymous.
The specification is in file specs.ulana.

     The purpose of the ULANA I program is to provide a set of standard
components for implementing data communications networks for the Air Force.
This draft specification defines a family of components that can be imple-
mented in a wide variety of local area network configurations to satisfy
Air Force users' unclassified and classified data communications require-
ments.

     This specification is also available in the ULANA reading room at
Hanscom AFB, MA.  Appointments for the reading room may be arranged through
LT. Sam Current, ESD/DCC-2, 617-271-8517.  Your comments on the working
draft are welcome, but we remind you that this does not commit the
Government to actually publishing a ULANA Request for Proposal.

     Please address any comments to comments@mitre-b-ulana.arpa via
electronic mail.
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Apr 86 15:21:56 est
From:      romkey@BORAX.LCS.MIT.EDU (John Romkey)
To:        tcp-ip@sri-nic.arpa
Subject:   ICMP responses to broadcasts
My opinion is that internally there should be some additional state
associated with incoming packets marking them as a broadcast (the
hardware driver can usually figure this unambiguously), and that any
code that cares whether or not a packet is broadcast should inspect a
flag rather than having to compare the addresses. In some systems this
isn't practical because they have no way of communicating that extra
state information to higher level protocols.

Invert this scheme and have a flag marking outgoing packets as
broadcast, too. When the packet gets to the IP layer, the IP layer can
fill in the IP broadcast address and tell the hardware driver to
broadcast packets.
					- john

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Apr 86 15:47 EST
From:      Paul Jones(919) 962-6501, <ULTIMA%UNC.BITNET@WISCVM.WISC.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   tcp-ip mailing list
Please add me to the TCP/IP mailing list.
           Paul Jones
           ultima@unc.bitnet
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Tue 22 Apr 86 22:38:35-MST
From:      Mark Crispin <MRC@SIMTEL20.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   network etiquette
I'm sorry to bother everybody on this list about this.  I'm really getting
fed up over this though:

	** Do NOT reply to a message by including the text of **
	** the message being replied to in the reply.	      **

It seems that after all the efforts to stomp this behavior out of mailers
it is now reappearing in certain Unix mailers.  Hearsay claims that this
is the *default* -- I hope this is not true.
-------
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Tue 22 Apr 86 22:48:14-MST
From:      Mark Crispin <MRC@SIMTEL20.ARPA>
To:        MOCKAPETRIS@USC-ISIB.ARPA
Cc:        ole@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: lower caste berkeley?
Paul -

     This bug must be in the ISI version of TOPS-20.  The standard
versions of TOPS-20 (5.4 and 6.1) fold the case correctly.  That
is, user host names to look up are folded prior to doing the table
lookup, and when the host table is loaded all names are converted
to uppercase.  Then MONET.Berkeley.EDU => MONET.BERKELEY.EDU.  This
is done in the RDFLD routine.

     I wouldn't be surprised if the hash lookup failed if the strings
were stored in mixed case, that is if RDFLD didn't fold case.
Probably that's what happened at ISI.

     Alternatively, you could have been bit by SNDMSG.  I'm surprised
that people still use that ancient tool.

-- Mark --
-------
-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Apr 86 07:18:30 pst
From:      minshall%ucbopal@BERKELEY.EDU (Greg Minshall)
To:        tcp-ip@sri-nic.arpa
Subject:   Telnet
Hello.

The 4.2 Unix Telnet client (user) responds to a "DO ECHO" with a "WILL ECHO"
(and then, of course, doesn't REALLY echo network data).  This has been fixed
in 4.3 Unix.

The question is:  are there any other Telnet client implementations which
respond to "DO ECHO" with "WILL ECHO"?

Thanks.

Greg Minshall

(why - I would like the 4.3 Telnet server to be able to distinguish between
	wounded 4.2 clients and the rest of the world - and I won't apologize
	too much for this attempt at compatibility)
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 1986 10:20:18 PST
From:      BRADEN@USC-ISIB.ARPA
To:        JNC@XX.LCS.MIT.EDU, brescia@BBNCCV.ARPA, tcp-ip@SRI-NIC.ARPA
Cc:        BRADEN@USC-ISIB.ARPA
Subject:   Re: ICMP responses to broadcasts
In response to the message sent  Mon 21 Apr 86 23:59:39-EST from JNC@XX.LCS.MIT.EDU

There seem to be two discussions interwoven here: how a gateway should/
should not responds to a local net;work broadcast packet it receives, and
how IP-level broadcasts should be implemented.

On the second question, the answer probably is: it doesn't 
matter, because IP broadcast is a bad idea in general anyway.  We should
be looking at Deering's proposal in RFC966 for IP multicast.

Bob Braden

-------
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 1986 1429-PST (Wednesday)
From:      Jeff Mogul <mogul@su-navajo.arpa>
To:        BRADEN@USC-ISIB.ARPA
Cc:        JNC@XX.LCS.MIT.EDU, brescia@BBNCCV.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: ICMP responses to broadcasts
Bob Braden writes:
    [How should IP-level broadcasts be implemented?]: it doesn't 
    matter, because IP broadcast is a bad idea in general anyway.  We should
    be looking at Deering's proposal in RFC966 for IP multicast.

I agree that multicast is better, in principle.  In practice, oodles
of hosts are doing broadcast now, and there is an awful lot of hardware
that supports broadcast but not multicast, or supports multicast
inadequately.  So, it really does matter how these broadcasts are done.

Since I wrote RFC919 to propose a standard for broadcasting, I suppose
I should defend it.  I asked Jon Postel about this last month, and
he replied:

    Well, "official protocols" (rfc-961) says they are "experimental" and
    "proposed protocols".  However, there is no competing proposal.  So,
    i'd say to any one that asks, "if you are going to do a broadcast do
    it the rfc-919 and rfc-922 way".  I have not received any recent
    questions about it that i recall.  Maybe, the next version of official
    protocols should raise the status somewhat.
    
If anyone would like to propose that IP broadcasting be banned, then
I suspect there will be insurmountable opposition: most people will
keep doing it.  Otherwise, let's try to be consistent on how it's done.
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 1986 12:27:48 EST
From:      MILLS@USC-ISID.ARPA
To:        minshall%ucbopal@UCBVAX.Berkeley.EDU, tcp-ip@SRI-NIC.ARPA
Cc:        MILLS@USC-ISID.ARPA
Subject:   Re: Telnet
In response to the message sent  Wed, 23 Apr 86 07:18:30 pst from minshall%ucbopal@BERKELEY.EDU 

Greg,

Your message left a wedge of uncertainty in the repair itself. Did you mean
the TELNET user client would respond "wont" to a "do echo" or that it would
echo like it advertises? The Principle of Least Astonishment would select the
former, although adventuring the latter would invite a glorious war and
demonstrate TCP ack-ack fights need not be confined to the transport layer.

No, our TELNET user client grumbles "wont" to just about anything.

Dave
-------
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Apr 86 21:20:06 pst
From:      minshall%ucbopal@BERKELEY.EDU (Greg Minshall)
To:        MILLS@usc-isid.arpa, tcp-ip@sri-nic.arpa
Subject:   Re: Telnet
Dave,
	The fix in client Telnet is to reply "WONT ECHO" to "DO ECHO".
Greg
-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Thu 24 Apr 86 11:03:43-PST
From:      Steve Dennett <DENNETT@SRI-NIC.ARPA>
To:        Jhodges@DDN2.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Etiquette Document

Some Rand Corp. folks prepared a large document for the NSF entitled
"Toward an Ethics and Etiquette for Electronic Mail" last year.  You
can get info on ftping it by sending a request to:

		RAND-DOCS@RAND-UNIX.ARPA

Steve Dennett
dennett@sri-nic.arpa 
-------
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Thu 24 Apr 86 11:33:32-MST
From:      Mark Crispin <MRC@SIMTEL20.ARPA>
To:        minshall%ucbopal@UCBVAX.BERKELEY.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Telnet
Greg Minshall -

     The TOPS-20 Telnet client (user) rejects incoming "DO ECHO" as being
meaningless, along with the equally meaningless "DO SUPPRESS-GA".

-- Mark --
-------
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Thu Apr 24 17:15:05 1986
From:      hassler@lognet2.ARPA (Barry D. Hassler)
To:        tcp-ip@sri-nic
Subject:   Philosophical question: OSI layers vs DDN protocols
        A somewhat "philosophical" question for you:

        In comparison with the OSI protocol  layers,  where  does
one  place  the  DDN  (ARPANET) protocols? Specifically, in which
protocol are the layer 5 (session) functions subsumed?

        I would feel they are in the top of TCP, while  others  I
have  spoken  with say they are in the bottom of the "upper layer
protocols".  I  have  also  heard  "the  session  layer  is   not
implemented at all." Ovviously, it *is* implemented somewhere, so
the source of that statement shall remain forever anonymous.

        There probably is not a "clear-cut" dividing line  as  to
where  the   implementation  of  protocols falls in comparison to
OSI, but for some reason, this question is a matter of hot debate
right  now.  Any input you may have would be greatly appreciated.
Please send responses directly to me at "hassler@lognet2.ARPA".

Thank You,

-BDH
-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Apr 86 19:23:12 est
From:      romkey@BORAX.LCS.MIT.EDU (John Romkey)
To:        TCP-IP@sri-nic.arpa
Cc:        serial-ip@xx.lcs.mit.edu
Subject:   re: raw IP through a TAC dialup
Since it looks like there's a lot of interest in serial line IP and
there's currently no good forum for discussing it, I've created a list
where we can discuss the issues without burdening the rest of tcp-ip
with our wanderings. The list address is serial-ip@xx.lcs.mit.edu
(mit-xx.arpa for those of you who remain undomainified). The request
address is serial-ip-request@xx.lcs.mit.edu. I'm willing to maintain
the list for now. I'll arrange some place to keep archives.

Some things to talk about:
	- current implementations
	- addressing: especially dialups
	- error recovery
	- compression
	- whatever everyone else wants to talk about

Maybe after some discussion we can come up with a protocol or set of
protocols for sending IP over serial lines and get them blessed.
				- john
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Fri 25 Apr 86 00:28:13-EST
From:      Drew D. Perkins <DP4Q@TE.CC.CMU.EDU>
To:        tcp-ip@SRI-NIC.ARPA, unix-wizards@BRL.ARPA
Subject:   DMV11 driver for Ultrix
I'm in need of a DMV11 driver for Ultrix on a uVAXII.  Does anyone have
one of these?  DMV11's are the QBUS equivalent of a DMR11.

Drew
Drew.Perkins@te.cc.cmu.edu
-------
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 1986 17:03-PST
From:      Steve Deering <deering@su-pescadero.ARPA>
To:        tcp-ip@sri-nic.ARPA
Subject:   Re: ICMP responses to broadcasts
John Romkey writes:

    My opinion is that internally there should be some additional state
    associated with incoming packets marking them as a broadcast (the
    hardware driver can usually figure this unambiguously), and that any
    code that cares whether or not a packet is broadcast should inspect a
    flag rather than having to compare the addresses.

But the decision to withhold ICMP error reports should be based on
whether or not the packet was broadcast or multicast AT THE IP LEVEL,
NOT the local network level.  If a packet destined to a unicast IP
address happens to be delivered as a local net broadcast or multicast,
it should still be treated as an IP unicast for the purposes of ICMP.
Conversely, an IP broadcast or multicast may be transmitted as a sequence
of local net unicasts; it should still be treated as a broadcast by ICMP.
I really think you should inspect the IP address to make such decisions.
I understand that it can be messy checking for all the different flavours
of IP broadcast address (at least IP multicast addresses can all be
recognized with a single test), but these tests tend to be out of the
performance-critical main path, so I don't think it's such a big deal.

							-- Steve Deering
-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Apr 1986  18:10 EST
From:      Jon Solomon <JSOL@BUCS20.BU.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Subnetting
I need to ask some naive level questions about Subnetting. The
RFC's didn't explain themselves too fully and I need more info.

Can those interested in hearing naive questions please send me mail?

--JSol
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Apr 86 14:32:05 est
From:      dab@BORAX.LCS.MIT.EDU (David A. Bridgham)
To:        tcp-ip@sri-nic.ARPA
Subject:   ICMP responses to broadcasts
   Date: 25 Apr 1986 17:03-PST
   From: Steve Deering <deering@su-pescadero.ARPA>

   But the decision to withhold ICMP error reports should be based on
   whether or not the packet was broadcast or multicast AT THE IP LEVEL,
   NOT the local network level.

I quite disagree.  If the packet was broadcast at the local net level,
then it should be treated as a broadcast packet for the purposes of
not sending ICMP responses, regardless of what internet address the
packet was sent to.  This prevents all manner of nasties which will
occur when someone broadcasts a packet with a non-broadcast IP
address.

   I understand that it can be messy checking for all the different flavours
   of IP broadcast address (at least IP multicast addresses can all be
   recognized with a single test), but these tests tend to be out of the
   performance-critical main path, so I don't think it's such a big deal.

In some systems anyway, the check for broadcastedness *is* in the
critical path.  If you only do that check to decide about returning an
ICMP message then it wouldn't be, but gateways, at least, need to
check every packet so that broadcast packets are not forwarded.  The
check for a broadcast IP address is also just one test (set the net
and subnet (if used) fields to all 1's and check if the address is all
1's).  The problem is that there are many machines that do not use the
IP broadcast address when they broadcast packets.  That's what makes
the check for an IP broadcast address slightly messy.
							Dave
-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Apr 86 10:18:25 EDT
From:      jas@proteon.arpa
To:        deering@su-pescadero.ARPA
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Re: ICMP responses to broadcasts
While I agree that there may be some good purist reasons to generate
ICMPs over IP unicasts sent as LAN broadcasts, there are some very compelling
practical reasons not to. If you have a lot of gateways on an ethernet,
and this poor misguided packet arrives, a lot of gateways will generate
ICMPs in perfect synchronization. This will generate a mega-collision
on your Ethernet, which may be a very bad idea. Remember Jeff Schiller's
mail about wedging his DEQNA's over a similar ICMP synchrony?

More directly, I would consider an IP unicast sent to a LAN broadcast
to be a violation of the (unwritten) specs for IP over most LANs.
Bad packets go in the bit-bucket, to make life safe and easy for all of us.
-------

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 86 10:20:25 EDT
From:      Roy <MARANTZ@RED.RUTGERS.EDU>
To:        JSOL@BUCS20.BU.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Subnetting
Fire away.

Roy
-------
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Mon 28 Apr 86 12:49:50-EDT
From:      "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
To:        dab@BORAX.LCS.MIT.EDU, tcp-ip@SRI-NIC.ARPA
Cc:        JNC@XX.LCS.MIT.EDU
Subject:   Re: ICMP responses to broadcasts
	Let's go back to basic philosophy on this one, and see if we
can clear it up.

	I don't see why anyone would send a (local) broadcast packet
to a (local) non-broadcast address, or vice versa. (Note that I don't
include remote directed broadcast.) It's a slightly suspicious thing
to do. (The only good reason I can think of to do anything like this
is if you're on a net where you don't know where gateways are. You
send out a broadcast packet, and hope for ICMP Redirects. There will
soon be a new ICMP message for finding gateways, so that will fix
that.)
	If anyone else can think of any good reasons to do such a
thing, please reply to me (privately), and I'll sum up the responses,
along with any places where a need is pointed out. I'd prefer to fix
any such needs with explicit mechanisms, and outlaw this kludge.

	The problem then reduces to a much simpler one; you have a
broken packet: what do you do? Now, it's a known fact that dropping
broken things silently makes tracking down problems real hard; it's
also known that having everyone do something when a error happens
usually causes the universe to go berserk.
	In addition, whatever generated the bogus packets may not be
in any shape to take automatic error messages, or make any use of
them. The solution that seems to address all these is to notify
'network central', whoever or wherever that is. On the other hand,
there may be a human debugging some code, and he might be able to use
an error message right away, rather than 3 weeks later when the
'network central' sends out their monthly report and notes these
crazy packets they saw several weeks ago. So, here's my philosophy on
what to do.

	If the packet was a local hardware broadcast, and you are a
host, drop it: let the gateways (which will also have the packet)
figure out what to do. The gateways will have more smarts to limit the
amount of berserkness in the response, as well as limiting the number
of responses in case they do get it wrong.
	If you are a gateway, things get complicated, and I'm not sure
I have figured out all the cases right here off the top of my head.
For instance, if the source looks like it was on an attached wire,
send an ICMP error to the source (making sure it wasn't a broadcast),
since the guy created a bad packet. I guess we need a new ICMP error
type for this. However, if the source wasn't local, then either the
packet has a bad source address or a gateway blew it; there's not much
you can do. Log the message for the network wizards to ponder and drop
it.

	If the packet was not a hardware broadcast, and you are a host,
it's probably OK to send an ICMP error message since you were the only
one to receive it. I guess the same goes for gateways here.

	We still have the problem of what to do with packets that are
in error and *really* broadcast, and I guess they get handled in much
the same way as the case above for ones which were hardware broadcast.
In no circumstances should hosts reply to messages which were hardware
broadcast!
	I guess the same set of strategies will apply to multicast
packets, when they eventually arrive in service everywhere. Also,
gateways should always notify 'network central' whenever they notice
anything wrong; there may not be a human or intelligent automaton
getting the message, and the guys who run the net are the ultimate
safety belt. In general, remember: there are more ways to lose than we
can plan for in advance, so the ultimate fallback is to "do nothing
and notify the humans".

	I hope this puts a few heavy duty nails in the coffin of this
one.

	Noel
-------
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Apr 86 10:32:41 EDT
From:      Ken Lebowitz <kjl@bbn-clxx.arpa>
To:        tcp-ip@nic
Subject:   SUN 1822 interface
Hi,

Is anyone (ACC?) making a VME 1822 interface board which one could use with
a SUN-3?  Also, if such a board exists, is there a SUN driver available for
use with it?

Thanks,

Ken Lebowitz
BBN Laboratories

ARPA:	kjl@bbn-clxx.arpa or kjl@clxx.bbn.com
UUCP:	...!{decvax,ihnp4,harvard}!bbncca!kjl
CSNET:	kjl%bbn-clxx.arpa@csnet-relay

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Apr 86 11:05:37 edt
From:      Todd Eugene Fuller <tef%virginia.csnet@CSNET-RELAY.ARPA>
To:        mod.protocols.tcp-ip
Subject:   tcp-ip mailing list

Please add me to the tcp-ip mailing list.

		Thank you

		Todd Fuller
		tef@uvacs.UUCP


END OF DOCUMENT