The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 00:53:11 GMT
From:      louie@TRANTOR.UMD.EDU ("Louis A. Mamakos")
To:        comp.protocols.tcp-ip
Subject:   Re: EtherTalk broadcast invasion

Gee, it's too bad EtherTalk doesn't use an ethernet multicast address, rather
than using the (global) broadcast address.  This way, only those who feel they
are interested would have to listen for this stuff.

By the way, how did this "big-lan@suvm.bitnet" address escape on to the
internet?  This is a little unfriendly.

louie

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 01:02:00 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: subnetting zero-numbers

From: nomad@cs.orst.edu (Lee Vincent Damon)

       I have just finished reading rfc950 (finally). I notice in this
    doc that the "zero address" of each subnet is supposed to remain 
    unused, along with the "all-one" address.  When I issued numbers
    on my subnet I knew about the all ones, but not about the zeros. None
    of our machines have complained so I was wondering if the zero's
    "this net" requirement has been removed and we just have an old doc?

If viewed in isolation, there is no intrinsic reason why the zero
host address should be banned; unfortunately, things like this can
never safely be viewed in isolation.  The problem comes from the
historical use of that address as a broadcast address by some hosts
(chiefly, 4.2BSD-derived systems).  Even though the standards now
specify an "all ones" broadcast address, many hosts still treat
the "all zeros" host address as a broadcast.  So, you might have
some hosts that are sending packets as link-level broadcasts when
they are meant to be sending unicasts, and other hosts that may
refuse to receive or forward packets addressed to the all zeros
host.

Further, some systems use an all-zeros host part to refer to the
network rather than a specific host; e.g., 128.45.1.1 is a host
but 125.45.0.0 is a network.

In summary, use of the zero host address can lead to confusion
and chaos.  As a general principle of address space engineering
(a discipline I just invented), it is always a bad idea to use
the "zero" address for a real object.  You're likely to find
it used by mistake.

By the way, the zero subnet number is also a bad idea, for
similar (but not identical) reasons.

-Jeff

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 02:41:00 GMT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re: Leaping clocks

Phill,
 
Meanwhile what happens over here in Europe? Since you officially leap
at 7pm EST and UK is 5 hours advance on you - it sounds as if the UK
(as the 'owner' of the long. 0 just east of the centre of London all
associated with the high tech work on timekeeping done here over 200
years ago so as to sail the seas with better effect to found and hold
the empire.....) is the point of origin for the world leaping. Prehaps
Dave knows more detail.
 
Happy new year from the time-centre of the universe - (and of course
that is why we invented Dr. Who and the Time Lords...)
John

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 Jan 88 13:45:55 -0500
From:      robb <robb@PARK-STREET.BBN.COM>
To:        Craig Partridge <craig@NNSC.NSF.NET>
Cc:        tcp-ip@SRI-NIC.ARPA, robb@PARK-STREET.BBN.COM
Subject:   Re: ICMP type #7?

Craig,

	Could I bother you for a little more information?  You say

    "Looking at one of the CSNET machines, I discovered that out of 170,000
	IP packets received, ... "

	By CSNET machine, you mean host, rather than gateway, right?
	
	How recently did you notice this occurrence and can you give a historical
perspective to this problem (not noticed/not looked for a week/month ago)?

	Is it possible to find out where some of these ICMP messages are coming
from and what the contents of some of these messages might be?

	I ask these questions because I want to see if it is, perhaps,
our gateways that are, say, sending out an incorrect ICMP message in
response to some problem (ttl expire, redirect, whatever).

	Thank you.

robb.

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 08:16:36 GMT
From:      dupuy@westend.columbia.edu (Alexander Dupuy)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

Ever since the leap second (23:59:60 GMT Jan 1, 1988) the realtime clocks on
Sun-3s have been behaving strangely.  When booting /vmunix, just after the
message about using nn buffers, the kernel prints out a little message like the
above.  That's not too bothersome for us, since we use rdate and ntpd to keep
our Suns' clocks in synch anyhow.

What is bothersome is that the system clocks have started to slew wildly.
Using a little program I hacked up, I have found that there are spurious deltas
showing up in adjtime(2) on *ANY SUN-3* which has had its time set or adjusted
since the leap second.  Running the following program a few times:

adjtime.c
---------
#include <sys/time.h>

struct timeval delta = { 0, 0 },
	    olddelta = { 0, 0 };

main ()
{
	if ( adjtime (&delta, &olddelta) == -1)
		perror ("adjtime");

	printf ("adjust %d.%d, oldslew %d.%d\n", delta.tv_sec, delta.tv_usec,
					olddelta.tv_sec, olddelta.tv_usec);
}

I get results like this:

Script started on Fri Jan  1 02:14:18 1988

finest# alias adj '/src/local/local/netdate/adjtime; date'
finest# adj
adjust 0.0, oldslew -1490.-143408
Fri Jan  1 02:15:26 EST 1988
westend# adj
adjust 0.0, oldslew 0.0
Fri Jan  1 02:15:32 EST 1988
westend# adj
adjust 0.0, oldslew -1729.-961408
Fri Jan  1 02:15:46 EST 1988
westend# 

westend# date 8712311650
Thu Dec 31 16:50:00 EST 1987
westend# adj
adjust 0.0, oldslew 0.0
Thu Dec 31 16:50:09 EST 1987
westend# adj
adjust 0.0, oldslew 0.0
Thu Dec 31 16:50:29 EST 1987
westend# adj
adjust 0.0, oldslew 0.0
Thu Dec 31 16:50:48 EST 1987

script done on Thu Dec 31 16:50:49 1987

As can be seen, every ten to fifteen seconds, some monstrous time adjustment
gets added in by the kernel.  This is *not* being done by ntp or any other time
daemon - it even happens in single user mode.  It can also be seen that after
the date is reset to 1987 (GMT) this behavior disappears, and time stabilizes.
The silly message when booting disappears as well.

So it looks like the guilty party is /sys/sundev/clock.c.  But not having
source code, what can I do?

Other observations: Our Sun-2s (bless their little obsolete cpus) have not even
stuttered since the leap second went down.  Their TOD clock code seems to be
just fine.

So will someone with access to Sun kernel sources please help me out?  This is
a serious bug, and I imagine Sun will have a patched OBJ/clock.o for binary
sites eventually, but in the meantime, it is stretching the resources of ntpd
to even keep the machines within a *minute* or so of true time.  The poor
machines which aren't running ntp are okay until they are rebooted, or someone
foolishly tries to set their time, but once that happens, their watch gears get
unsprung.

@alex
---
arpanet: dupuy@columbia.edu
uucp:	...!seismo!columbia!dupuy

---
arpanet: dupuy@columbia.edu
uucp:	...!seismo!columbia!dupuy

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 08:23:52 GMT
From:      dupuy@westend.columbia.edu (Alexander Dupuy)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!


Forgot to give the versions for which this problem exists:

SunOS 3.2
@(#)clock.c 1.1 86/07/07

and

SunOS 3.4
@(#)clock.c 1.2 86/10/08
---
arpanet: dupuy@columbia.edu
uucp:	...!seismo!columbia!dupuy

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jan 88 20:20
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@NSS.Cs.Ucl.AC.UK>
To:        Mills <@NSS.Cs.Ucl.AC.UK:Mills@louie.udel.edu>
Cc:        tcp-ip <@NSS.Cs.Ucl.AC.UK:tcp-ip@sri-nic.arpa>
Subject:   Re:  Leaping clocks
Dave,
 
One hour after sending my 'Empire time' msg (Stars Wars is showing on
the TV at this moment) I heard on the 'news' that Paris and not London
pushed the leap button. I'll console myself with the knowledge that we
are both part of the ECC. Years ago I worked at the National Physical
Laboratory Teddington and I thought the atomic clock there had some
national role.
 
Missing has been the education of why we have leap seconds. I assume
they are always positive and are because of either or both - the Earth
does not rotate at a smooth constant rate year by year, the rotation is
slowing down (and the Moon moving further away). 
 
John
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 17:05:53 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: EtherTalk broadcast invasion

As it stands, I see it as an excelent argument for IP routers in the great
router vs. bridge debate.  From what you say, it appears that you can't
have more than 250 MACs using EtherTalk anywhere in your bridged Ether,
and if you have even a hundred, people will notice.  Presumably the 8-bit
node ID is *really* built-in, even if the 20 broadcasts in less than a
second aren't?  Or, do they do it quickly because the defense protocol
breaks down when two nodes try to defend the same address at the same
time?  Whichever, I assume that it won't be long before they lose a big
order because of it, and set some engineers to work on inserting a slightly
more global world-view.

jbvb

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 18:33:46 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/SMTP ULTRIX <-> MULTICS PROBLEM

This may sound somewhat ridiculous but try padding the message so that the data
length is either modulo 2 or modulo 4 bytes (octets) in length.  Not all DEC
interfaces are necessarily byte oriented.

Merton Campbell Crockett
EATON Information Management Systems

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 18:45:55 GMT
From:      robb@PARK-STREET.BBN.COM (robb)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP type #7?


Craig,

	Could I bother you for a little more information?  You say

    "Looking at one of the CSNET machines, I discovered that out of 170,000
	IP packets received, ... "

	By CSNET machine, you mean host, rather than gateway, right?
	
	How recently did you notice this occurrence and can you give a historical
perspective to this problem (not noticed/not looked for a week/month ago)?

	Is it possible to find out where some of these ICMP messages are coming
from and what the contents of some of these messages might be?

	I ask these questions because I want to see if it is, perhaps,
our gateways that are, say, sending out an incorrect ICMP message in
response to some problem (ttl expire, redirect, whatever).

	Thank you.

robb.

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 19:30:16 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Need TCP/IP on RSTS/E

Bill,  You should contact Phil Denzer at Process Software in 
Amherst, MA.  They do a lot of PDP-11 based TCP/IP stuff.
They are at 413-549-6994.

Dan
-------

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 1988 02:09 EST
From:      Charles Jerian <cpj@citi.umich.edu>
To:        dupuy@columbia.edu, tcp-ip@sri-nic.arpa
Subject:   adjtime issue
The following script shuts off the automatic adjtime from the
hardware clock every 30 secs
for suns
if  [ x$1 = "xoff" ]
then echo "dosynctodr/W 0"|adb -k -w /vmunix /dev/mem
else if [ x$1 = "xon" ] 
then echo "dosynctodr/W 1"|adb -k -w /vmunix /dev/mem
else  echo "dosynctodr/D" |adb -k /vmunix /dev/mem 

fi
fi
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 01:56:58 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

Alex,

The problem is that the leap second occured in a leap year, an event probably
unanticipated by Sun. Not to worry, it is easily fixed by simply stacking 
another penny on the pendulum, as was done by the Big Ben keepers. You may
have to use the old-fashioned kind before they started adding all that
aluminum goop. Old Pence are the best kind, but they are rather hard to find.

Dave

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 04:20:00 GMT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re:  Leaping clocks

Dave,
 
One hour after sending my 'Empire time' msg (Stars Wars is showing on
the TV at this moment) I heard on the 'news' that Paris and not London
pushed the leap button. I'll console myself with the knowledge that we
are both part of the ECC. Years ago I worked at the National Physical
Laboratory Teddington and I thought the atomic clock there had some
national role.
 
Missing has been the education of why we have leap seconds. I assume
they are always positive and are because of either or both - the Earth
does not rotate at a smooth constant rate year by year, the rotation is
slowing down (and the Moon moving further away). 
 
John

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 06:27:09 GMT
From:      slevy@UC.MSC.UMN.EDU (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Re:  WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

Whew.  I was pinging umd1.umd.edu at leap second time, hoping to catch it in
the act (wonder how many others were doing the same thing?), when suddenly
the time difference started hurtling into outer space.  For a moment I
wondered if Dave Mills had added a leap minute instead of second, but no,
our SUNs had all gone mad.  It was a great relief to hear that someone
else saw the same thing.

I believe I have a fix for this..  Probably the easiest way to
distribute it without annoying SUN too much is as a binary patch.
Say:

# adb -w -k /vmunix /dev/mem
resettodr+0xca?X
	(It should contain 0x536efff4, a subqw #1,a6@(-0xc) instruction.)
	(Change it to NOP's in the /vmunix file with...)
.?W 4e714e71
	(and in the running kernel (this seems to be safe) with...)
./W 4e714e71
$q
#


For those who have source, the relevant module is sun3/clock.c.
The line in resettodr() reading

	t += MONTHSEC(--mon, year);

breaks, since MONTHSEC evaluates the --mon twice in leap years.
It could change to

	mon--;
	t += MONTHSEC(mon, year);

This appears to work on our SUNs running 3.3.


				Stuart Levy, Minn. Supercomputer Center
				slevy@uc.msc.umn.edu

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 07:02:28 GMT
From:      karn@faline.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Leaping clocks

Leap seconds are inserted once per year, on the average. They keep UTC
(Coordinated Universal Time, as broadcast by WWV) within 0.7 seconds of
another time scale, UT1.  UT1 is the time as determined by astronomical
observations of the rotation of the earth, corrected for an annual
fluctuation of about +/- 30 milliseconds caused by seasonal movement of
atmospheric mass and a slight annual distortion in the shape of the earth
caused by solar tidal effects.

Basically, the problem is that the second was defined to be too short with
respect to the average rotation rate of the earth, so additional seconds
have to be inserted periodically into UTC to allow the earth to "catch up".

As you point out there is also a very long term trend having to do with the
transfer of angular momentum from the earth's rotation to the moon. However,
this amounts only to about 1 millisecond per century.

References: Reference Data for Radio Engineers, Howard Sams & co.

Phil

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 07:09:00 GMT
From:      cpj@CITI.UMICH.EDU (Charles Jerian)
To:        comp.protocols.tcp-ip
Subject:   adjtime issue

The following script shuts off the automatic adjtime from the
hardware clock every 30 secs
for suns
if  [ x$1 = "xoff" ]
then echo "dosynctodr/W 0"|adb -k -w /vmunix /dev/mem
else if [ x$1 = "xon" ] 
then echo "dosynctodr/W 1"|adb -k -w /vmunix /dev/mem
else  echo "dosynctodr/D" |adb -k /vmunix /dev/mem 

fi
fi

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 08:13:10 GMT
From:      lear@aramis.rutgers.edu (eliot lear)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip books

Dr. Hedrick has written an introduction to TCP-IP which is perfect
for the beginner.  The documentation is located on INTERNET host
TOPAZ.RUTGERS.EDU [128.6.4.194] located in pub/tcp-ip-docs.  In that
same directory is a group of relavent RFCs such as RFC 791.
-- 
Eliot Lear
[lear@rutgers.edu]

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 13:35:08 GMT
From:      martillo@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Need TCP/IP on RSTS/E


I believe that in some incarnation the PC/IP package ran on PDP-11s
under unix.  The software of course nowadays runs on PCs and makes no
use of Unix (or Unix-like) system calls except I think for _exit()
which is provided in the microsoft C library for DOS.  If you have
a C compiler, it might be worth trying to compile the  PC/IP programs
on your PDP-11.

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 16:22:17 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Leaping clocks

Phil,

In that reference (Seventh Edition, 1985) it also points out that on 1 January
1972 the NBS reference was retarded ten seconds with respect to the International
Atomic Time (TAI) scale maintained by the BIH. Since leap seconds have been
syncronized since then, I conclude the whole thing is a plot to make sure
the rest of the world is always ahead of us.

Dave

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 20:09:51 GMT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Response to Long Distance NFS Query


Sure, and I remeber running DECX for days and having things turn up
100 % OK, but then having the machine blow up with hardware errors
five minutes after the normal OS was booted.  There's no diagnostic
like actually trying to use the system.

-Ron

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 20:19:31 GMT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: UVax Ultrix Blues also Pyramid-98xe Blues


I believe TAC's only offer a window for the buffer they have.  The interesting
thing is that they don't slide the window when data has been received, they
wait until the buffer is full (empty) until they open the window up to the
full buffer size.  What this causes is usually a sequence of available window
that goes 64, 32, 0, 64, 32, 0, 64, 32, 0...

-Ron

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 22:03:47 GMT
From:      slevy@UC.MSC.UMN.EDU (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Re:  WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

I forgot to mention in sending out the SUN kernel binary patch that
it ONLY works in leap years -- if you just apply the patch, it will break
in January 1989.  Probably everybody will have an official SUN fix by then
but you might want to keep a note of what changed, just in case.

					Stuart

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 88 08:25:17 GMT
From:      kre@munnari.oz (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

In article <8801020627.AA19752@uc.msc.umn.edu>,
slevy@UC.MSC.UMN.EDU (Stuart Levy) writes:
> I believe I have a fix for this..  Probably the easiest way to
> distribute it without annoying SUN too much is as a binary patch.

Then, In article <8801022203.AA25123@uc.msc.umn.edu>,
slevy@UC.MSC.UMN.EDU (Stuart Levy) writes again:
> I forgot to mention in sending out the SUN kernel binary patch that
> it ONLY works in leap years -- if you just apply the patch, it will break
> in January 1989.

Here's an alternative (binary) patch that will work in both leap years,
and in boring old ordinary years.


# adb -w -k /vmunix /dev/mem
resettodr+0xca?X
	(It should contain 0x536efff4, a subqw #1,a6@(-0xc) instruction.
	If you applied Stuart's patch it will contain 0x4e714e71, 2 nop's
	so put back the subw in both the kernel a.out, and memory)
.?W 536efff4
./W 536efff4
	(next, apply a slightly better fix)
resettodr+0xc0?i
	(it should contain "bnes resettodr+0xca", which we will change to be
	"bnes resettodr+0xce" and avoid the incorrect subw)
.?w 660c
	(now verify that its correct)
.?i
	(and assuming it is "bnes resettodr+0xca", change the running kernel)
./w 660c
$q

I can't verify that this actually fixes the reported problem, but it clearly
does fix a bug, and should have the same effect this year as Stuart's fix,
while not hurting next year.  I used SunOS 3.4 to do this, in case other
versions of SunOS deviate (3.3 is apparently the same), here is the original
section of binary ...

_resettodr+0xa6:                        movw    a6@(-0x10),d0
_resettodr+0xaa:                        moveq   #3,d1
_resettodr+0xac:                        andw    d1,d0
_resettodr+0xae:                        andl    #0xffff,d0
_resettodr+0xb4:                        bnes    _resettodr+0xca
_resettodr+0xb6:                        subqw   #1,a6@(-0xc)
_resettodr+0xba:                        cmpw    #2,a6@(-0xc)
_resettodr+0xc0:                        bnes    _resettodr+0xca	<<<< change this to
_resettodr+0xc2:                        movl    #0x263b80,d0
_resettodr+0xc8:                        bras    _resettodr+0xde
_resettodr+0xca:                        subqw   #1,a6@(-0xc)
_resettodr+0xce:                        moveq   #0,d0		<<<< branch to here
_resettodr+0xd0:                        movw    a6@(-0xc),d0
_resettodr+0xd4:                        lea     _monthsec:l,a0
_resettodr+0xda:                        movl    a0@(-4,d0:l:4),d0
_resettodr+0xde:                        addl    d0,d7

kre

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      03 Jan 88 16:25:05 EST (Sun)
From:      dm@bfly-vax.bbn.com
To:        Robert Elz <munnari!kre@uunet.uu.net>
Cc:        tcp-ip@sri-nic.ARPA, dm@bfly-vax.bbn.com
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

Could someone explain to the rest of us why adding a leap-second had
any effect on Sun workstations other than making their clock be off by
one second (more than usual)?  Or is 1988 one bit too much in some
data structure?
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 88 21:25:05 GMT
From:      dm@BFLY-VAX.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!


Could someone explain to the rest of us why adding a leap-second had
any effect on Sun workstations other than making their clock be off by
one second (more than usual)?  Or is 1988 one bit too much in some
data structure?

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 88 23:15:17 GMT
From:      slevy@UC.MSC.UMN.EDU (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

It wasn't the leap second, just the fact that 1988 is a leap year.
SUN-3's contain a date-and-time clock chip, and there's kernel code
to translate UNIX time <=> the clock chip's format.  In leap years,
the code broke and loaded garbage into the chip.  Later, on reading it
back, it noticed that the chip contained an invalid date.

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 00:16:11 GMT
From:      MRC@PANDA.PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   clocks

This business of leap seconds makes me wonder.  The last I read about times
on the network, the entire issue of leap seconds was ignored; RFC 868 simply
says "the number of seconds since 00:00 1 January 1900".  None of the examples
indicate any leap seconds (but were they any before May 1983?).  So, what are
the time servers returning, the 32-bit value with leap seconds or without
them?  I hope it's the latter!
-------

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 00:31:00 GMT
From:      ks@pur-ee
To:        comp.protocols.tcp-ip
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

In article <8801032141.AA15091@ucbvax.Berkeley.EDU> dm@BFLY-VAX.BBN.COM writes:
>
>Could someone explain to the rest of us why adding a leap-second had
>any effect on Sun workstations other than making their clock be off by
>one second (more than usual)?  Or is 1988 one bit too much in some
>data structure?

The Sun3 and the software for its Time of Day chip has been developed since
the last leap year.  If the system clock drifts from the time of day
clock, it is, by default, resynced.  A routine converts the YYMMDD.HHMMSS.THT
from the TOD chip to unix time in seconds from the beginning of time
(00:00 Jan 1 1970 GMT).  This routine did this incorrectly during leap years.
A "--mon" was used in an argument to a MACRO, and in leap years, that argument
got evaluated twice.

Can you say time bomb?

						Kirk Smith

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 01:31:09 GMT
From:      ks@ee.ecn.purdue.edu  (Kirk Smith)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!
In article <8801032141.AA15091@ucbvax.Berkeley.EDU> dm@BFLY-VAX.BBN.COM writes:
>
>Could someone explain to the rest of us why adding a leap-second had
>any effect on Sun workstations other than making their clock be off by
>one second (more than usual)?  Or is 1988 one bit too much in some
>data structure?

The Sun3 and the software for its Time of Day chip has been developed since
the last leap year.  If the system clock drifts from the time of day
clock, it is, by default, resynced.  A routine converts the YYMMDD.HHMMSS.THT
from the TOD chip to unix time in seconds from the beginning of time
(00:00 Jan 1 1970 GMT).  This routine did this incorrectly during leap years.
A "--mon" was used in an argument to a MACRO, and in leap years, that argument
got evaluated twice.

Can you say time bomb?

						Kirk Smith
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 02:33:13 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  clocks

Mark,

Before 1 January 1972, when the international time scales were rationalized
and leap-seconds introduced, the time standards were corrected at appropriate
intervals to maintain time with respect to Earth rotation to within 100 ms
or so. This fact, along with the fact that atomic clocks were rare near the
beginning of the century, makes it meaningless to consider leaps before that
date. There have been maybe a dozen leap seconds since then, all positive;
however, I don't have the dates handy at the moment.

In 1980, when IEN-142 was published, and again in 1983, when its successor
was published, it didn't seem like such a big deal to tell time down to the
milliseconds, especially since the precision provided by the protocol was
only to the second. Since these documents were published, protocols and
measurement techniques have evolved to the point that events can be synchronized
with high reliability to within a couple of milliseconds over campus LANs and
within a couple of hundred milliseconds over typical Internet paths. Thus,
it comes as no surprise that the leap-second issue has now become important.
See RFC-956, -957 and -958 for further discussion on timetelling in the
Internet and a description of the Network Time Protocol (NTP) which makes
all this possible.

I considered the issue of whether to build in leap-second corrections for
NTP, at least back to their inception in 1972 and decided against it. For
just about any purpose, it is not necessary to order events with respect
to what I will call archival time to better than a second; however, when
that becomes necessary, the user would have to insert the leaps as necessary
and using archival information telling when they were made.

In fact, the time scale NTP uses really concides with International Atomic
Time (TA-NBS). After leap-second corrections TA-NBS becomes UTC-NBS as
broadcast. TA-NTP concided with TA-NBS just after the original correction
was inserted prior to 1 January 1972. The rest is history.

Dave

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 04:01:00 GMT
From:      mp@allegra
To:        comp.protocols.tcp-ip
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

If anyone has a patch for sun4's, please send it along; we don't yet
have source code or much knowledge of the assembly language.  A
short-term workaround, for both sun3's and sun4's, is to minimize
reliance on the tod clock: run rdate as soon as possible after booting,
and patch the kernel variable dosynctodr to be 0 so that the unix date
is not periodically copied (well, actually, it's adjtime'd) from the
incorrect info in the todr.  This workaround may result in
the unix date running a bit slow due to missed clock interrupts.

    Mark Plotnick
    Department of Solar Calendars
    allegra!mp

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 05:01:21 GMT
From:      allegra!mp@ucbvax.Berkeley.EDU  (Mark Plotnick)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!
If anyone has a patch for sun4's, please send it along; we don't yet
have source code or much knowledge of the assembly language.  A
short-term workaround, for both sun3's and sun4's, is to minimize
reliance on the tod clock: run rdate as soon as possible after booting,
and patch the kernel variable dosynctodr to be 0 so that the unix date
is not periodically copied (well, actually, it's adjtime'd) from the
incorrect info in the todr.  This workaround may result in
the unix date running a bit slow due to missed clock interrupts.

    Mark Plotnick
    Department of Solar Calendars
    allegra!mp
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jan 88 13:32
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@NSS.Cs.Ucl.AC.UK>
To:        Mills <@NSS.Cs.Ucl.AC.UK:Mills@louie.udel.edu>
Cc:        TCP-IP <@NSS.Cs.Ucl.AC.UK:TCP-IP@sri-nic.arpa>, Mark Crispin <@NSS.Cs.Ucl.AC.UK:MRC@panda.panda.com>
Subject:   Re:  clocks
Dave,
 
Your extensive and timely(!) knowledge about time-keeping makes me wonder
if you are thinking of applying for Swiss nationality. The Swiss have
great respect for clocks. They have that great engineering principle -
if its working don't muck it about. As far as I know they are alone in Europe
in NOT changing there time + or - 1 hour each year; they must be miffed by all
this 1 second leaping done at infrequent intervals.
 
John
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 16:19:53 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Leaping-clock Sunshines

Folks,

I have received several requests for the power-grid graphs mentioned in my
recent message on leaping clocks. They can be found on louie.udel.edu in
~ftp/pub/clock.bit and ~ftp/pub/leap.bit with the usual anonymous login.
Both of these are Sun-format bitmaps suitable for the screenload program
consisting of 41472 octets and must be retrieved in image (binary) mode.
The first graph shows the offset in milliseconds of the eastern power
grid from nominal UT for the day preceeding the 30 June 1985 leap second
and the day one week later. The second shows the offset on 30 June and
1 July. Note that radio reception conditions happened to be so bad during
and after the leap that both the WWVB and WWV clocks had dropped out of
synchronization for three hours following the leap. This further supports
the requirement that the leap should be scheduled in advance not only in
all timekeeping hosts, as is done now in the NTP-speaking world and
fuzzballs, but also in the radio clocks themselves. This in fact should
not be hard to do, since all radio clocks known to me already have a
firmware-driven microprocessor inside.

Dave

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 17:45:43 GMT
From:      bzs@bu-cs.bu.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!


Oops, I lost the original note so I sent a reply to unix-wizards.
Anyhow, I found that adb'ing the kernel (or via sources) and setting
the variable 'dosynctodr' to zero (it's a flag which defaults to one)
that this problem seems to be ameliorated. I still am not sure what's
causing it or if it's related to the leap-second or not but sections
of the source which slew the clock seem to always check dosynctodr
first.  It shouldn't affect using adjtime from outside the kernel.

I would consider this an emergency patch until someone from Sun sheds
some light on the issue of what's really going on but the systems I've
applied this patch to have been keeping time fine. I'm sure there's
some negative consequence to this patch (always have to set time on
boot? not sure.) I agree tho, I've had systems getting off by an hour
or more of late.

	-Barry Shein, Boston University

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 17:50:35 GMT
From:      bzs@bu-cs.bu.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!


Urgh, the nice thing about all these patches is one gets so many to
choose from. Stu Levy's looks better than mine (mine: to turn off
dosynctodr), if you applied mine undo it (trivial) and try his.

I'm copying the note so it nullifies my advice on Unix-wizards also.

	-Barry Shein, Boston University

Date: Sat, 2 Jan 88 00:27:09 CST
From: slevy@uc.msc.umn.edu (Stuart Levy)
To: tcp-ip@sri-nic.arpa, westend!dupuy@columbia.edu
Subject: Re:  WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

Whew.  I was pinging umd1.umd.edu at leap second time, hoping to catch it in
the act (wonder how many others were doing the same thing?), when suddenly
the time difference started hurtling into outer space.  For a moment I
wondered if Dave Mills had added a leap minute instead of second, but no,
our SUNs had all gone mad.  It was a great relief to hear that someone
else saw the same thing.

I believe I have a fix for this..  Probably the easiest way to
distribute it without annoying SUN too much is as a binary patch.
Say:

# adb -w -k /vmunix /dev/mem
resettodr+0xca?X
	(It should contain 0x536efff4, a subqw #1,a6@(-0xc) instruction.)
	(Change it to NOP's in the /vmunix file with...)
.?W 4e714e71
	(and in the running kernel (this seems to be safe) with...)
./W 4e714e71
$q
#


For those who have source, the relevant module is sun3/clock.c.
The line in resettodr() reading

	t += MONTHSEC(--mon, year);

breaks, since MONTHSEC evaluates the --mon twice in leap years.
It could change to

	mon--;
	t += MONTHSEC(mon, year);

This appears to work on our SUNs running 3.3.


				Stuart Levy, Minn. Supercomputer Center
				slevy@uc.msc.umn.edu

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 17:57:43 GMT
From:      rob@PRESTO.IG.COM (Rob Liebschutz)
To:        comp.protocols.tcp-ip
Subject:   IEEE Network Magazine

Does anyone know where (or if) IEEE Network Magazine can be purchased
in the Bay area?  Computer Literacy carries various other IEEE
magazines, but not this one.

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 1988 23:22-EST
From:      bassen@ifi.uio.no        (Tor Sverre Lande)
To:        Michael St. Johns <STJOHNS@SRI-NIC.ARPA>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: UVax ULTRIX Blues
Well, there is a couple of more hints using TCP/IP on Ultrix.

1. If you also are running DECNET do ALL the DECNET-stuff before
"ifconfig" in rc.local. The DECNET-software changes your
ehternet-adress so if you do "ifconfig" before "ncp ...." your TCP/IP
will never work. Did you ever think hardware ethernet-addresses should
be unique?!?

2. If you are using subnets and have a gateway taking max. 576 bytes
packets between your subnets there is an undocumented kernel-option
NETCONSERVE setting max packetsize to 576 to all non-local subnets.
This is the same option as SUBNETSARELOCAL in 4.3bsd.

-Bassen
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 18:30:22 GMT
From:      bzs@bu-cs.bu.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!


It's starting to look like a leap-year, not a leap-second bug, a macro
expanding to add some value twice instead of once (quick analysis.)

Don't believe everything you read on the net (joke.)

	-B

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 19:29:14 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: Leaping clocks

Does that mean we get to put Dave in space?  Gee, I think he is already
high enough!  :-)

dennis

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 21:32:00 GMT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re:  clocks

Dave,
 
Your extensive and timely(!) knowledge about time-keeping makes me wonder
if you are thinking of applying for Swiss nationality. The Swiss have
great respect for clocks. They have that great engineering principle -
if its working don't muck it about. As far as I know they are alone in Europe
in NOT changing there time + or - 1 hour each year; they must be miffed by all
this 1 second leaping done at infrequent intervals.
 
John

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 21:34:45 GMT
From:      mark@nova.usc.edu (Mark A. Brown)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!


Here's a binary patch for the leap year bug that will work for Sun 4s.

# adb -w -k /vmunix /dev/mem
resettodr+0x110?X
	(It should contain 0xba276001, a sub %i5, 0x1, %i5 instruction.
	(Change it to a nop in both /vmunix and kernel memory)
.?W 0x1000000
./W 0x1000000
	(To make yourself feel better, do the following)
.?i
./i
	(If they're nop's, things should now be better)
$q

We are running the SYS4 GAMMA release, but things should be the same
for SYS4 3.2.  If not, here's the original GAMMA binary and you can go from
there.

_resettodr+0xf0:                srl     %i5, 0x10, %i5
_resettodr+0xf4:                orcc    %g0, %i1, %g0
_resettodr+0xf8:                bne     _resettodr + 0x120
_resettodr+0xfc:                sub     %i5, 0x1, %i5
_resettodr+0x100:               sll     %i5, 0x10, %i5
_resettodr+0x104:               srl     %i5, 0x10, %i5
_resettodr+0x108:               cmp     %i5, 0x2
_resettodr+0x10c:               bne,a   _resettodr + 0x120
_resettodr+0x110:               sub     %i5, 0x1, %i5	     <<< change to nop
_resettodr+0x114:               sethi   %hi(0x263800), %o5
_resettodr+0x118:               ba      _resettodr + 0x134
_resettodr+0x11c:               add     %o5, 0x380, %i3
_resettodr+0x120:               sll     %i5, 0x10, %i5
_resettodr+0x124:               srl     %i5, 0x10, %i5
_resettodr+0x128:               sub     %i5, 0x1, %i3
_resettodr+0x12c:               sll     %i3, 0x2, %i3
_resettodr+0x130:               ld      [%i3 + %l7], %i3
_resettodr+0x134:               add     %i4, %i3, %i4
_resettodr+0x138:               mov     %i4, %o0



	Mark

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 22:09:00 GMT
From:      karn@JUPITER.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Leap second list

I just had a most enjoyable chat with Mr. Kerry Kingham of the US Naval
Observatory.  Kerry provided me with the following list of leap seconds.
Each took place on the very last minute of the last day of the indicated
month:

June 1972
December 1972
December 1973
December 1974
December 1975
December 1976
December 1977
December 1978
December 1979
June 1981
June 1982
June 1983
June 1985
December 1987

It turns out that there is a very amusing reason for the obvious patterns
you see here. The original BIH policy was to declare leap seconds at the end
of the year whenever possible, using the June date only when necessary to
stay within the +/- 0.8 second UTC-UT1 limit.

However, it seems that the French eventually rebelled at having to come in
to work, thereby missing their New Year's Eve parties year after year, so in
1981 they decided to "anticipate" the need for a year-end leap second by
doing it in June. That one took UTC as far behind UT1 as it has ever been
(-0.78 seconds), just barely within the limit.  (Fortunately WWV UT1
corrections (which only go to +/- 0.7 sec) could still handle this because
their absolute values are truncated down to the next lower 100 ms multiple.)

I mentioned the griping we've heard from various parties about what leap
seconds do to radio clocks, and he says "Oh, that's nothing". He then told
me about how several very upset people called him up once to ask why there
was no leap second in that year. It seems that they had systems with a
hardwired "positive leap second every December 31st" rule -- and some of
those systems were in orbit! He then took great pleasure in letting them
know that it is also possible to have NEGATIVE leap seconds...

Kerry also improved my understanding of UT1. It is based on raw observations
of the earth's rotation angle (defined as UT0) corrected for the effects of
polar wandering.  The earth's rotational poles wander over a roughly
circular path every 14 months or so. This is caused by changes in the
earth's mass distribution (solar tides, seasonal atmosphere mass shifts,
melting snow caps, etc). The amplitude of the polar variation is roughly the
size of a baseball diamond, and it causes small changes in the observer's true
latitude and longitude -- therefore affecting the observer's astronomical
observations on the order of +/- 30 ms.

Phil

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 00:41:09 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: Need TCP/IP on RSTS/E


    ....  If you have a C compiler, it might be worth trying to compile
    the  PC/IP programs on your PDP-11.

All fine, except that PC-IP is 1) dependent on an 18 ticks/sec clock in a
lot of places 2) very 808x-dependent in the tasking, timer and display
modules and 3) has a built-in hardware driver which would need a complete
re-write for another interface/architecture.  The problem with RSTS is
that DEC has never done anything to ease user-written device drivers,
and there was nothing like the VMS XE driver to allow user programs to
get at the raw ethernet the last I knew.  It would be a good place to
start, but it won't be a short job.

jbvb

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Tue, 05 Jan 88 08:44:09 EST
From:      Jim Petty <PETTY@MITVMA.MIT.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Subscription
Please add me to the tcp-ip subscription list.

Thankx Jim
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 04:16:29 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Leaping clocks

Dennis,

Gee, I thought I presented my position to you when you were at DARPA, as
well as your predecessor Barry Leiner and his predecessor Vint Cerf,
not to mention assorted ears at DCEC and NOSC. I would be pleased to
demonstrate things Internet, including fuzzballs, leaping clocks and
other packet poppers, in orbit or other equally exotic place. How about
the African bush using HF radio, or in a submarine under the Arctic
using sonar, or on the Moon using laser or in China using OSCAR satellite?
As for orbit, gotta fix the boosters first. Maybe the Russians would launch
a fuzzsputnik. We could say it represented critical technology and set them
back fifteen years.

Dave

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 04:22:00 GMT
From:      bassen@IFI.UIO.NO (Tor Sverre Lande)
To:        comp.protocols.tcp-ip
Subject:   Re: UVax ULTRIX Blues

Well, there is a couple of more hints using TCP/IP on Ultrix.

1. If you also are running DECNET do ALL the DECNET-stuff before
"ifconfig" in rc.local. The DECNET-software changes your
ehternet-adress so if you do "ifconfig" before "ncp ...." your TCP/IP
will never work. Did you ever think hardware ethernet-addresses should
be unique?!?

2. If you are using subnets and have a gateway taking max. 576 bytes
packets between your subnets there is an undocumented kernel-option
NETCONSERVE setting max packetsize to 576 to all non-local subnets.
This is the same option as SUBNETSARELOCAL in 4.3bsd.

-Bassen

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 06:11:58 GMT
From:      melohn@Sun.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: Santa's PSN 7 status

After catching up on my mail over the holidays, it appeared as though
everyone now believes the problems related to "stuck VCs" have been
fixed. However, when I drop my host Sun.COM back to the non-patched
version of our kernel (the one that doesn't attempt to kludge around
the BBN bug by always sending an RR with each packet) I still notice
"stuck VCs", easily reproduceable on one-way VCs between us and
machines on IMPs 11 and 68. Either the latest version of Andy's patch
has not been fully deployed, or it too does NOT fix the problem.

On the 128 byte packet problem; we are in the process of getting
packet traces from the ARPAnet to see exactly what the packet traffic
looks like when we appear to lose the 128 byte packets. I should point
out that this too only appears to happen between us and 1822 hosts
running the new end to end; I suspect that we will find another PSN
7.0 bug at the root cause of this problem. More as soon as I have
the traces.

We are in the process of testing a new version of our software to
handle multiple incoming VCs from the same IP host. Because multiple
VCs are used for X.25 loopback by the PSN under the new end to end, we
feel we have little choice but to support them. I do feel that
requiring this support without any warning that such support would be
required by the new end to end was a mistake, one that our mutual
customers may have to live with until we can test and manufacture
a new software release. It also conceptually wastes VCs, which are
limited resources in many X.25 implementations, because it encourages
in many more cases two or more one-way VCs between host pairs where
a single VC would have existed under the old end to end.

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 07:39:33 GMT
From:      map@GAAK.LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   Need TCP/IP on RSTS/E


   Date: Mon,  4 Jan 88 19:41:09 EST
   From: "James B. VanBokkelen" <JBVB@AI.AI.MIT.EDU>

       ....  If you have a C compiler, it might be worth trying to compile
       the  PC/IP programs on your PDP-11.

   All fine, except that PC-IP is ...

You missed the point earlier in that message where the author said
that they thought it had originally been done on PDP11s.  That's
actually where the author went wrong.  The PCIP code was originally
designed for the MS-DOS environment and is therefore probably
completely unsuited to conversion to RSTS.  The MIT UNIX V6 code on
the other hand ... :-\

					... The problem with RSTS is
   that DEC has never done anything to ease user-written device drivers,
   and there was nothing like the VMS XE driver to allow user programs to
   get at the raw ethernet the last I knew.
I heard rumors (shortly after you left the RSTS community James, and
shortly before I did) that such an interface was in the offing.  I
have not heard what came of that.

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 13:44:09 GMT
From:      PETTY@MITVMA.MIT.EDU (Jim Petty)
To:        comp.protocols.tcp-ip
Subject:   Subscription

Please add me to the tcp-ip subscription list.

Thankx Jim

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 14:18:21 GMT
From:      steve@NOTE.NSF.GOV (Stephen Wolff)
To:        comp.protocols.tcp-ip
Subject:   Re: 300 Megabit/second national network?


"A Research and Development Strategy for High Performance Computing",
November 20, 1987, is a product of the Federal Coordinating Council on
Science, Engineering, and Technology (FCCSET - pronounced "fixit"[!])
Committee on Computer Research and Appications, an organ of the Office
of Science and Technology Policy.  The report treats four topics:

                High performance computers,
                Software technology and algorithms,
                Networking, and
                Basic research and human resources.

Federal agencies participating in the Networking section included NSF,
NASA, NBS, DHHS, DoE, NIH, DARPA, and NRL.  They solicited white papers
from users and providers of network services in late 1986, and held a
workshop in February 1987 at which six working groups drawn from
industry, universities, and government addressed networking requirements
and future alternatives, special requirements for supercomputer
networks, internet concepts, future standards and service requirements,
computer network security, and the government role in networking; the
networking portion of the FCCSET report is a distillation of the white
papers and six working group reports.

The participating Federal agencies named above are distributing the
report; if you send me your postal address I'll mail you a copy.

-s

PS: The report is also being reprinted in the Proceedings of the recent
2nd TCP/IP Interoperability Conference, organized by Advanced Computing
Environments, 21370 Vai Avenue, Cupertino, CA 95014.

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 18:35:03 GMT
From:      Stevens@A.ISI.EDU (Jim Stevens)
To:        comp.protocols.tcp-ip
Subject:   IP & TCP Precedence


2 Questions about IP & TCP Precedence:

(1) The IP Request For Comments (RFC-791) and IP Military Standard
(MIL-STD-1777) specify that Type Of Service (TOS) including
precedence is a parameter that can be passed from the upper layer
protocols to IP during a SEND operation and can be passed from IP to
the upper layer protocols during a RECEIVE operation.

How many IP implementations support this?

How many people actually use this?


(2) The TCP Military Standard (MIL-STD-1778) specifies the actions that
TCP is to perform based upon the precedence passed up from IP in the
TOS.  The TCP Request For Comments (RFC-793) allows implementations to
optionally perform precedence based upon the TOS passed up from IP.

How many TCP implementations support this?

How many people actually use this?



Jim
-------

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 20:59:56 GMT
From:      jsloan@wright.EDU (John Sloan)
To:        comp.sys.encore,comp.unix.questions,comp.protocols.tcp-ip
Subject:   Problems with Encore Annex server


We're having some problems with our Encore Annex terminal servers
talking to our SUN-3/280S timesharing system. We're hoping someone
can give us some advice on where to start troubleshooting. We'll
call Encore and/or Sun, but first we'd like to know where the problem
is likely to be so we know what questions to ask. Any help would be
appreciated. If its a case of RTFM, feel free to flame a bit, but
please provide a reference. BTW, other than this small glitch,
we're very happy with out Annex servers. I have paperwork on
my desk to purchase four more.

SYMPTOMS

While using vi on the SUN through an Annex, the terminal freezes up.
No amount of control keys of any flavor will free it. The status line
on the terminal indicates that the NO SCROLL key is NOT active.  We can
break back to the annex and open another terminal session, and kill our
previous incarnation. Meanwhile, users continue to access the SUN both
through the same Annex and another Annex without any problems.

The problem is fairly rare, showing up on the average less than once a
day.  It has occurred on both Annexes.  It has never been observed
while connecting to either our VAX 750 or 785 or our SUN-3/180S,
although the 380S is our main system and so just may be more likely to
exhibit the problem. It has never been reported to occur outside of vi.
It has never been reported while using the same model terminal on a
direct connect line.

It happened (twice :-( ) while editing this posting, which is unusual.

When you kill the previous session, you can recover the file as usual
with the -r switch. Killing vi is not enough, though, as the csh is
also hungup, so you must kill -9 that as well.

SPECIFICS

Terminal	WYSE 60 (although we believe that it has occurred
			on other makes and models, we don't have
			the evidence to back this up)
Annex		Annex-UX
		Software Rel 2.1
		Harward Rev 1.4
		ROM Rev 0305
Sun-3/280S	Vanilla SunOS 3.4
Command		rlogin

TROUBLESHOOTING

The only thing that looks significant (to me) is that when the problem
occurs, a "netstat" on the annex shows

Active Connections
Proto	Recv-Q	Send-Q	Local Address		Foreign Address	(state)
tcp	0	71	(192.26.92.245).750	odin.login	ESTABLISHED

where the Send-Q (here, 71) grows by one each time you hit a key. Hence,
it seems that the input is being queued but is not being sent. Still,
thr problem could be at either end.

On "odin", a netstat shows that the Recv-Q and Send-Q of the same socket
are empty (which is expected).

On the annex, a "netstat -i" shows 1 alignment error, 1 interface
reset, and 29 TX DMA Underruns, but these numbers do not grow when
the problem reoccurs, so it seems unlikely that they have anything
to do with it. Likewise with some error counts under "netstat -s".

If there is a way to take force a crash dump on the Annex we don't
know what it is, and besides would be reluctant to do so while other
users were on it being productive.

If anyone has had similar difficulties, or even better, has some notion
of how to further troubleshoot this, we'd appreciate hearing from you.
We don't have ethernet diagnostic equipment, but this has the smell of
a software problem, almost like an XON/XOFF problem where the XON back
to the annex is getting lost (nope, we have yet to find any evidence of
this).

Again, the problem could be at either end.

Thanks for any hints at all.

-- john

John Sloan                     Wright State University Research Center
jsloan@SPOTS.Wright.Edu       3171 Research Blvd., Kettering, OH 45420
...!cbosgd!wright!jsloan               (513) 259-1384   (513) 873-2491
Logic Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.
-- 
John Sloan                     Wright State University Research Center
jsloan@SPOTS.Wright.Edu       3171 Research Blvd., Kettering, OH 45420
...!cbosgd!wright!jsloan               (513) 259-1384   (513) 873-2491
Logic Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 21:17:51 GMT
From:      bkc@CLUTX.CLARKSON.EDU (Brad Clements)
To:        comp.protocols.tcp-ip
Subject:   Remote Virtual Disk


Help! I am looking for a program(s) that will redirect MS-DOS file I/O commands
to another system such as unix.  I have heard that there is a system somewhere
called Remote Virtual Disk (RVD) that allows a user to map an MS-DOS disk drive
to the root of a remote Unix system. Does anyone know where I can find this
software or something that does the same thing?

Please reply to 
Brad Clements
bkc@clutx.clarkson.edu
bkc@clutx.bitnet

Thanks!

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 22:24:33 GMT
From:      lekash@ORVILLE.NAS.NASA.GOV (John Lekashman)
To:        comp.protocols.tcp-ip
Subject:   Re:  IP & TCP Precedence


	2 Questions about IP & TCP Precedence:
	
	(1) The IP Request For Comments (RFC-791) and IP Military Standard
	(MIL-STD-1777) specify that Type Of Service (TOS) including
	precedence is a parameter that can be passed from the upper layer
	protocols to IP during a SEND operation and can be passed from IP to
	the upper layer protocols during a RECEIVE operation.
	
	How many IP implementations support this?
	
	How many people actually use this?
	
I did a socket option to the kernel to allow a user program
to set different values for the type of service.   Currently
this only consists of allowing it to set the value of that
byte in the header.  My feeling is that this should have some sort
of abstraction of what sort of service is desired, and the
TCP will cause the IP layer to set this byte value appropriately.
The exact details of what sorts of service one might ask for,
and appropriate TOS byte settings for such are not worked out.

One major reason is attempting to figure out authentication 
mechanisms in a connectionless environment, ie preventing
every random who feels like it setting his own personal 
workstation to get high bandwidth, low delay, high reliability,
which then results in lossages to those who do the 'right thing'
whatever that happens to be.  Still, the setting allows us
to send ftp data traffic over satellite channels, and telnet,
acks and such over terrestrial lines.  (with appropriate software
switches in gateways and bridges.

Maybe we'll even use it beyond the lab one day, if we get 
smart enough TCP's everywhere, which deal with satellites well.

					john
	

	

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 23:25:41 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   MILNET/?/UMDNET/SURA/GWU-GATE traffic question

LANL is used by a number of folks on (or with access to) the Internet.
When they cannot 'telnet' to our hosts here, they start calling us up
and telling us how to do our job.  So far, none of the suggestions have
been very appealing.  The current problem causing some users grief manifests
itself as follows:

	1. A user on GWUVM.GWU.EDU attempts to telnet to MILNET-GW.LANL.GOV.
	2. The connection times out.
	3. The user is pissed and calls us up.

I have tried various things on our end to find out what is going on.  Here
are the things I found out when the problem was first reported:

	1. I could talk to GWUVM.GWU.EDU from our subnets but not
	   directly from MILNET-GW.LANL.GOV.
	   This made absolutely no sense.

	2. I sent 100 ICMP ECHO request's from MILNET-GW.LANL.GOV
	   and 100 reply's were received.  But, of the 100 reply's
	   received about 20% had DUPLICATE SEQUENCE NUMBERS!

I was getting curious.

	3. I sent a more sophisticated ICMP ECHO packet with out much
	   hope of a response.  This one is coded up with the IP RECORD
	   ROUTE option.  Some hosts on the Internet actually respond
	   to these, like our 4.3BSD hosts (a local modification),
	   and A.ISI.EDU.  I wish others would.

	   Low and Behold, back came the following IP header and option:

	   x00: x4f001400	IP header
	   x04: x86450000	    "
	   x08: x11010000	    "
	   x0c: x80a401ea	IP source	GWU-GATE host GWUVM.GWU.EDU
	   x10: x1a00005a 	IP destination 	MILNET host MILNET-GW.LANL.GOV
	   x14: x01072728	IP option field	NOP | RR option header
	   x18: x80080a0e	The		UMDNET host TRANTOR.UMD.EDU
	   x1c: x81020101 	route		UMD-BOGON-NET host 129.2.1.1
	   x20: x80a70101	traversed	SURA host 128.167.1.1
	   x24: x80a70201	as		SURA host 128.167.2.1
	   x28: x80a70102	far		SURA host 128.167.1.2
	   x2c: x80a72101	as		SURA host 128.167.33.1
	   x30: x80a72101	allowed		SURA host 128.167.33.1
	   x34: x80a72101	by		SURA host 128.167.33.1
	   x38: x80a72101	option.		SURA host 128.167.33.1

Unfortunately, thats all you get in an IP option.

So, what's going on?  For sure, if a packet has to hop around in the
SURA network before it (goes to/comes from) GWU-GATE, its going to take
some time.  Maybe get lost?  Maybe get duplicated?

What kind of network media/link levels do packets traverse here? I want to
make sure that LANL doesn't acquire (as in purchase) any hardware/protocols
that behave as above.  Maybe we already have.  Yikes!

Phil Wood  (cpw@lanl.gov)

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 01:48:42 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re:Remote Virtual Disk

That is the name of a protocol included in the MIT PC-IP distribution.
It allows creation of virtual DOS volumes on Unix systems, but 1) it
doesn't allow read/write sharing of those volumes, and 2) it requires
Unix source code and kernel modifications to install.  I've never used
it on a PC, but I've used Unices sharing disks via the same protocol,
and there were some unloveable aspects about spinup-spindown...

I don't know how you get the source for the Unix side.  I'd start
with the contact for PC-IP at MIT (the Microcomputer Office), and
see if they can help/redirect you.

jbvb

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jan 88 08:07:24 est
From:      snorthc@NSWC-OAS.ARPA
To:        bkc@clutx.clarkson.edu, tcp-ip@sri-nic.ARPA
Subject:   Re:  Remote Virtual Disk
I looked into RVD several months ago.  It is a large [code size] system
that does not appear to be in production use anywhere (rumored to still
be used in a UNIX host - UNIX host fashion at its birthplace, MIT).
I would suggest you consider one of the following commercial products:
	NFS;
	NetBios/TCP;
	Locus "DOS Merge".
(If my job depended on making the best choice I would choose NFS, if you
want the choice with the most future/potential choose NetBIOS/TCP)

	Best of luck, let us know how you work your problem out,
	Stephen Northcutt (snorthc@nswc-g.arpa)

Caveat: I have been looking at the problem you describe for several months
and am not completely satisfied with any of the alternatives.
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 04:23:13 GMT
From:      martillo@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Need TCP/IP on RSTS/E


While the display code and the network interface code (which live in
their own separate library modules) are rather dependent on
characteristics of the PC and DOS, I would say the rest of the code is
rather machine and OS independent even though small chunks of assembly
code would have to be rewritten for a given target machine.

I thought the PCIP code was developed under a Darpa grant for the DOS
environment but that the starting point was a package which ran under
PDP11 Unix and there is a comment in the tasking package to this effect.

However, once I asked Jerry Saltzer why the event flag was cleared by the
scheduler and not left for the task to clear so that useful information
could be passed via the event flag to the task and he mentioned in reply
that the tasking piece at least was running on Multics in 1966 (I may have
the year off) so that large chunks of the code have run in at least
3 different environments.  I think I saw that Tim Maroney ported the
code to the Macintosh so that chunks of PCIP have run in at least
4 very different environments.  

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 05:36:07 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  IP & TCP Precedence

Jim,

The fuzzball implementation supports TOS in IP and transport-level clients.
The mapping is controlled by arguments to the IP function calls. TOS is
interpreted by the queueing discipline as a priority, so that all IP packets
with a TOS octet value of x are serviced before any TOS with value x-1. There
are additional features for fairness and even a lie or two. The scheme should
not be considered as conforming to specification, but as an experiment in
queueing disciplines driven by pragmatic considerations. The NSFNET Backbone
presently supports this discipline, which is currently in evaluation.

Dave

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 06:00:07 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Remote Virtual Disk

Brad:

Softronics offers a product called Softerm PC which includes a "seamless disk"
or "remote virtual disk" capability.  In release 2.00.09 of the software, I
was able to access the disk on our DDN gateway VAX running bsd 4.3.  They
were some problems with the implementation:

    1.  The procedure that you create for the "seamless disk" had to log
	you in to the correct account on the host system.  (MS-DOS wanted
	to interpret the "/" in the UNIX path name as a MS-DOS switch.)
    2.  The files name had to follow MS-DOS naming conventions and file
	name length restrictions.
    3.  The file name had to be all upper case characters unless you used
	the UNIX upper/lower case translation capability by logging in
	using upper case characters in which case you could access files
	with lower case names.

I currently use release 2.10.02 but haven't gotten around to retesting to
see if they corrected the above problems.

Merton Campbell Crockett

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1988 1359-EST
From:      franceus@TYCHO.ARPA  (Paul Franceus)
To:        tcp-ip at sri-nic.arpa
Subject:   TOD clock problem on Sun 3.
I have been reading this discussion with interest.  It seems that we have a very
interesting manifestation of this problem.  Here we have 4 Sun 3's (3 160s and a
260).  Two of the machines appear to be keeping proper time (the 260 and one of
the 160s) while the other 2 are both messed up.  Also, on the two that are 
wrong, the clock is skewing at different rates.  Seems rather strange to me,
does this make sense to anyone?

Paul Franceus
Natl. Computer Security Center
-------

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 10:31:23 GMT
From:      whna@cgch.UUCP (Heinz Naef)
To:        comp.protocols.tcp-ip,comp.sources.wanted,comp.unix.questions
Subject:   Application Programming Interface for FTP

Did anyone develop a (limited) FTP client, implemented as a C programming
library, usable from within application programs to allow them to request
standard FTP servers in the network to send or receive a file?

Do any standard semantics exist for such an application programming interface?

Any comments are welcome.

Regards,
Heinz Naef, c/o CIBA-GEIGY AG, R-1032.5.62, P.O.Box, CH-4002 Basel, Switzerland
uucp: cgch!whna - bitnet: whna%cgch.uucp@cernvax.bitnet
                  phone: (+41) 61 37 26 75
                  fax:   (+41) 61 36 43 54 (Attn: H.Naef, R-1032.5.62)

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 13:07:24 GMT
From:      snorthc@NSWC-OAS.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re:  Remote Virtual Disk

I looked into RVD several months ago.  It is a large [code size] system
that does not appear to be in production use anywhere (rumored to still
be used in a UNIX host - UNIX host fashion at its birthplace, MIT).
I would suggest you consider one of the following commercial products:
	NFS;
	NetBios/TCP;
	Locus "DOS Merge".
(If my job depended on making the best choice I would choose NFS, if you
want the choice with the most future/potential choose NetBIOS/TCP)

	Best of luck, let us know how you work your problem out,
	Stephen Northcutt (snorthc@nswc-g.arpa)

Caveat: I have been looking at the problem you describe for several months
and am not completely satisfied with any of the alternatives.

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 14:47:36 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Remote Virtual Disk

Brad:

I forgot to mention in the previous missive that Softerm PC does not support
any of the TCP/IP suite of protocols but you do have your choice of

	1.  Crosstalk
	2.  Hayes-verify
	3.  Kermit
	4.  Softrans
	5.  Xmodem
	6   Xmodem-CRC

Softrans is a Softronics home-brew file transfer protocol with an encoding
algorithm which allows you to transfer 8 bit binary data over links which only
support 7 bit data transfers.  (They include source for Softrans so that you
can adapt it to your host system).

Merton Campbell Crockett

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 15:22:50 GMT
From:      zgel05@apctrc.UUCP (George E. Lehmann)
To:        comp.protocols.tcp-ip
Subject:   Spooky Routing by Sun TCP/IP

Tulsa, Oklahoma
Keywords: routing, tcp/ip, telnet, ftp


We have a bunch of Suns configured on several seperate nets something like:
            +-----------------+
            | VM running KNET |
            +-----------------+
                    |
     ---------------+----------+----------+--------------- 193.9.200 Ethernet
                               |          |
                           +---+---+  +---+---+
                           | Sun A |  | Sun B |
                           +---+---+  +---+---+
                               |          |
                    -----------+----------+--------- 193.9.202 Ethernet

We have a problem where VM tries to talk to Sun B using Sun A as a router,
but Sun B responds to VM using its 193.9.200 interface.  Since VM does not
have the 193.9.200 interface for Sun B defined, it ignores the response.

Questions: Is the Sun trying to be smart, recognizing it can get to the
193.9.200 net in one less hop by using a different interface to respond on?
If so, is there a way to turn off this smartness without unplugging the
second interface?

Any answers to these questions, or general enlightenment in this area will
be greatly appreciated.
-- 
George Lehmann,  ...!uunet!apctrc!zgel05
Amoco Production Co., PO BOX 3385, Tulsa, Ok  74102  ph:918-660-4066
Standard Disclaimer: Contents are my responsibility, not AMOCO's.

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 16:12:36 GMT
From:      budd@bu-cs.BU.EDU (Philip Budne)
To:        comp.sys.encore,comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: Problems with Encore Annex server

Sun 3.4 has known TCP window problems.  I don't remember ever seeing
problems of this nature between our 280 and Annexen, but we did
between Sun 3.4 and WISCnet.  We now run 4.3 TCP code in our Suns.

Try using tcpdump to view the traffic between the two systems.

	Phil Budne, Boston University

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 18:59:00 GMT
From:      franceus@TYCHO.ARPA (Paul Franceus)
To:        comp.protocols.tcp-ip
Subject:   TOD clock problem on Sun 3.

I have been reading this discussion with interest.  It seems that we have a very
interesting manifestation of this problem.  Here we have 4 Sun 3's (3 160s and a
260).  Two of the machines appear to be keeping proper time (the 260 and one of
the 160s) while the other 2 are both messed up.  Also, on the two that are 
wrong, the clock is skewing at different rates.  Seems rather strange to me,
does this make sense to anyone?

Paul Franceus
Natl. Computer Security Center
-------

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 19:39:33 GMT
From:      nasa@ms.uky.edu (Eric Freeman)
To:        comp.protocols.tcp-ip
Subject:   ping with routing

I have heard of a version of ping that shows routing information.  If anyone
knows information about it or has it could they please mail it to me.  Much
thanks in advance.

				Eric Freeman

-------------------------------------------------------------------------------
			  	      
Eric Freeman		        	  		"A spirit with a vision
freeman@dftnic.gsfc.nasa.gov  		  		 is a dream with a 
freeman@ssvs.gsfc.nasa.gov				 mission"
nasa@e.ms.uky.edu					       Neil Peart

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 20:15:52 GMT
From:      nowicki@SUN.COM (Bill Nowicki)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote Virtual Disk


	I am looking for a program(s) that will redirect MS-DOS file
	I/O commands to another system such as unix.

Why not use PC-NFS? Just call 1-800-334-SUNM (1-800-334-7866) and give
them Master Card or Visa, and it will be shipped in 48 hours.  

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 20:42:06 GMT
From:      larry@pdn.UUCP (Larry Swift)
To:        comp.protocols.tcp-ip
Subject:   ip/icmp/echo messages

While waiting for 4.3 BSD source code, I have been reading rfc's, etc, 
trying to figure out:

	 1)  whether icmp echo/reply messages can be sent with ip headers 
		 that specify strict source routing (via raw sockets only?),
	 2)  whether this would be useful in creating a looptest tool for 
		 customer service to check out specific serial links, and
	 3)  who has already implemented such an animal (probably only
		 about 50,000 people or so?).  I understand there's a program
		 called "ping" which uses echo.  Is it what I'm looking for?
		 Where can I get it?

Thanks in advance.

Larry Swift                     UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207          Phone: (813) 530-8605
P. O. Box 2826           
Largo, FL, 34649-9981   

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 21:07:13 GMT
From:      NIC@SRI-NIC.ARPA (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   ARPANET UPGRADE


It has been determined that some ARPANET host sites have had difficulty cutting
over to the new End-to-End protocols (PSN 7.0).  For this reason, a
cut back to the old End-to-End protocols is being considered for
Sunday, 16 January.

Site representatives who feel this will cause disruption of network
services, user software changes, or need more time to prepare for the
cutover, are asked to contact Annette Bauman, ABauman@DDN1.ARPA,
(703) 285-5445/(AV) 356-5445 or Bobby Powell, SCCMGR@DDN1.ARPA, 
(703) 285-5228/(AV) 356-5228.  If no response is received by 14 January,
we will proceed as planned. 
-------

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 21:17:52 GMT
From:      tom@tsdiag.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Objectivity


Gary,

My comment directed at identifing the problem, not your product.
I am glad to hear your comments that the problem is being worked on.

I just don't like it when people say that X.25 is trash when the real problem
is the configuration a carrier will allow or problems with a vendor's product.

Good luck fixing the problem.
-- 
Thomas A. Moulton, W2VY          Life is too short to be mad about things.
Home: (201) 779-W2VY             Packet: w2vy@kd6th  Voice: 145.190 (r)
Work: (201) 492-4880 x3226       FAX:  (201) 493-9167
Concurrent Computer Corp.        uucp: ...!ihnp4!hotps!ka2qhd!w2vy

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 22:37:53 GMT
From:      ROMKEY@XX.LCS.MIT.EDU (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: Need TCP/IP on RSTS/E

> All fine, except that PC-IP is 1) dependent on an 18 ticks/sec clock in a
> lot of places 2) very 808x-dependent in the tasking, timer and display
> modules and 3) has a built-in hardware driver which would need a complete
> re-write for another interface/architecture.  The problem with RSTS is

It's not *that* much of a problem. The 18 ticks/second clock is parametrized
in a constant in a header file so that all references to ticks can
be done as seconds * (ticks/second). It's not really a problem through
most of the code.

The 8086 dependencies are simply that there's some assembly code. In
the tasking package, you need to rewrite the code which does a context
switch. The timer code isn't 8086 dependent, and anyone who might be
porting PC/IP to another system would probably through out the entire
display package, anyway.

Any hardware drivers would have to be rewritten from scratch, anyway, since
it's a different set of hardware.

PC/IP origially ran on a PDP-11. If porting it back to a PDP-11 turns out
to be difficult, it shouldn't be because of architectural problems
or because of 8086 dependencies. PC/IP was derived from the PDP-11
V6 Unix code Mike Patton mentioned in a later message. I don't know if you
can still find someone at MIT who can or will give you that code.
				- john romkey
-------

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 00:23:32 GMT
From:      DLE@CSL.SRI.COM (David L. Edwards)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems with Encore Annex server


The TCP window problem in Sun 3.4 has been patched by Sun.  The problem
was that it was possible to get a negative window size which some
hosts, such as Tops-20, would hang the connection. 

The Sun bug fix ID is unix/3.4/kernel/tcp.seq.  The bug report
number was 1006132 and it was fixed in 3.4.2.  It is available
via anonymous FTP from several places.

David Edwards, SRI International

-------

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1988 05:55-EST
From:      GBELING@A.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Cc:        GBELING@A.ISI.EDU
Subject:   laep time units
hi, 
that was an interesting discussion on problems we encountered too with our 
sun zoo. but suddenly the leap-second leped to my eye: what does the 
german watch maker industry about this problem? 
so i leaped to the conclusion to ask somebody about this. 
what i got back was no answer but a question:
  
from the cuickoo clock cuckoos labor union:
unfortunately this leap second falls just in the time of our greatest 
activity. because we cannot break what shall we do in this additional time?
play leapfrog with ourselves??? 
  
this leads me to another reason for this additional time unit: 
for me as an user this is just introduced to make me look older than i am. 
regards gerd beling FRG
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 03:17:30 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: IP & TCP Precedence

Jim,  As you must have figured out by now, no one supports the precedence
and TOS fileds in any meaningful way.  Those fileds were defined 15 years
ago because they knew they had to be reserved up front if anyone could
ever figure out how to use the information they purport to convey.
Now we finally see one soul (Dave Mills, the tireless experimenter) using
those fields to see if he can make some improvements in gateway behaviour.

The trouble is that everyone has to play the "game" if those parameters
are ever to have any use.  The ISO equivalent protocols have also
defined those parameters and I see no use of them there, either.

Dan
-------

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1988 0918-EST
From:      hsw@TYCHO.ARPA  (Howard Weiss)
To:        tcp-ip at sri-nic.arpa
Subject:   Official Sun Patch for TOD problems.

	I received this message via the UNIX-WIZARDS mailing list and it
looks like it was not distributed to TCP-IP.  This is claimed to be
the official SUN patch for Sun OS 3.2, 3.3, 3.4, 3.5.

Howard Weiss

------------------------------------------------------


From: Chuq Von Rospach <chuq@plaid.Sun.COM>
Subject: Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!
Date: 5 Jan 88 21:57:40 GMT
Sender: news@sun.uucp
Keywords: TOD, clock, ntp, date
To:       unix-wizards@SEM.BRL.MIL

In article <5203@columbia.edu> dupuy@columbia.edu (Alexander Dupuy) writes:
>Ever since the leap second (23:59:60 GMT Jan 1, 1988) the realtime clocks on
>Sun-3s have been behaving strangely.  When booting /vmunix, just after the
>message about using nn buffers, the kernel prints out a little message like the
>above.

here's the official sun3 patch. The official sun4 patch will be posted as
soon as it gets released and I get approval.

Chuq
Sun Tech Support
============================================
There exists a problem for all Sun3 (68020) machines running SunOS
Releases 3.0-3.5, 4.0beta1, and all Sun4 (SPARC) machines running SunOS
Release Sys4-3.2 FCS and 4.0beta1.

As of Jan 1 00:00 1988, the clock routine in the kernel will put the
clock chip into an uncertain state if you attempt to set the date.
The visible effects of this is to 1) cause the message

        WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

to appear while booting vmunix, and to 2) cause the system date to start
to drift widely. Any attempts to actually *set* the date will have only a
temporary effect (i.e., the date you set will be good for about 30 seconds).

In order to solve this problem, you must patch both the kernel and system
object files.

==============================================================================

          Sun3 System Patch
          Releases 3.2, 3.3, 3.4, 3.5

As root, run the follwing command:

          echo 'resettodr+c0?i' | adb /vmunix - | grep reset

You should see the following printed out:

          _resettodr+c0:      bnes      _resettodr+0xca

If you see instead:

          _resettodr+c0:      bnes      _resettodr+0xce

the patch has already been applied to this system.
Proceed with the rest of the patch procedure anyway!

If you do not see either of these messages, go no further with this patch,
and please contact Sun Microsystems Customer Service.

If you do see either of those messages, then run, as root,
the following commands:

          cp /sys/OBJ/clock.o /sys/OBJ/clock.o-
          echo 'resettodr+c0?w 660c' | adb -w /sys/OBJ/clock.o

          echo 'resettodr+c0?w 660c' | adb -w /vmunix

Reboot and then *set* the date.

If you build kernels for your system, also rebuild your kernel.

Chuq "Fixed in 4.0" Von Rospach                   chuq@sun.COM                  Delphi: CHUQ

                       What do you mean 'You don't really want to hurt her?'
                                    I'm a Super-Villian! That's my Schtick!

-----------------------------
-------

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Thu 7 Jan 88 13:09:50-PST
From:      Doug <Faunt@SPAR-20.SPAR.SLB.COM>
To:        DLE@CSL.SRI.COM
Cc:        budd@BU-CS.BU.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Problems with Encore Annex server
We got that, thanks. 
-------
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Thu 7 Jan 88 14:10:47-EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        Stevens@A.ISI.EDU
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: IP & TCP Precedence
Why do you ask?
-------
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 10:09:28 GMT
From:      steve@NOTE.NSF.GOV (Stephen Wolff)
To:        comp.protocols.tcp-ip
Subject:   Re: MILNET/?/UMDNET/SURA/GWU-GATE traffic question


You're being misled by one of the technical differences between SURANET
and MILNET.  GWUVM is a host (128.164.1.234) on one of the campus
networks (128.164) connected via SURANET (128.167) to the rest of the
Internet. SURANET, like most (but not all) mid-level nets in the NSFNET,
is composed of IP routers (in SURANET'S case, Proteon P4200s) linked
together by serial lines.

What Record Route is showing you is the packet traveling from
128.167.33.1 - presumably the GWU_campus_net-to-SURANET P4200 gateway at
GWU - (but why it spent so much time there I don't understand) to
128.167.11.2 - the next P4200 (which happens to be at NSF) - to the
principal node of SURANET at University of Maryland, College Park, where
it is loaded onto MILNET. That is in fact the most direct route there
is.  Thereafter, there is quite possibly as much "hopping around" on the
packet's way to LANL via MILNET, but because MILNET uses a distinct
communications subnet (based on the PSNs) that operates below the
IP level, that's all invisible to Record Route.  I.e., since P4200s are
gateways as well as packet switches, each has a "host" number and so
leaves a fewmet for Record Route, but Record Route can't see the MILNET
packet switches.

From just behind the SURANET gateway at NSF, I see RTTs of 1500 ms or so
to MILNET-GW.LANL.GOV; this seems totally unreasonable.  Perhaps there
is congestion at the UMd gateway to MILNET which, combined with the
suspect behavior of the SURANET gateway at GWU, might cause your users'
connections to time out.  I suspect the SURANET folks are conducting
their own investigation and we'll hear from them in due course...

-s

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 10:55:00 GMT
From:      GBELING@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   laep time units

hi, 
that was an interesting discussion on problems we encountered too with our 
sun zoo. but suddenly the leap-second leped to my eye: what does the 
german watch maker industry about this problem? 
so i leaped to the conclusion to ask somebody about this. 
what i got back was no answer but a question:
  
from the cuickoo clock cuckoos labor union:
unfortunately this leap second falls just in the time of our greatest 
activity. because we cannot break what shall we do in this additional time?
play leapfrog with ourselves??? 
  
this leads me to another reason for this additional time unit: 
for me as an user this is just introduced to make me look older than i am. 
regards gerd beling FRG

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jan 88 16:01 5
From:      "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Happy New Year and   *  h e l p  *
     Happy New Year and I have a question.

     We have a back bone ethernet around the campus.  Off of this is the 
occasional diskless workstation farm.  These are Sun systems.  That's 
the topology.

     We also have a set of Class B internet addresses.  The back bone 
has been given a subset of these addresses and we want to use a 
different subset for the off back bone diskless systems.  

     We have been waiting for Sun OS 3.4 to come so that we could use 
subnets which seems to be the solution to separating things.  We now 
have 3.4 but can't get any of the diskless wonders to boot when we put 
the class B addresses up.  HOWEVER, booting seems to work just fine when
the diskless ethernet segments are given a class C address and the back
bone a class B address.  We believe we are having a tough time making
Sun OS 3.4 work with subnets but aren't sure.  It's hard to tell with
UNIX and we only have a moderate level of expertise here. 

     One more fly in the ointment is that we have a ComputerVision 
system which is a Sun diskless wonder farm off a disk server which is 
running Sun OS 3.2 and isn't likely to change any time soon. 
ComputerVision is a little behind. 

     Question:

     1) Has anybody made subnets or a similar configuration to the 
        above work with Sun OS 3.4?  If so, HOW? (*help*)

                             or

     2) If I bring this mess up with class B addresses on the back bone
        and class C addresses on the diskless segments, will packets  
        with class C addresses ever escape on to the back bone?  These 
        diskless systems are to be allowed to log in to other machines 
        which are on the back bone.  The problem is that we are 
        scheduled to be connected to JVNCNet REAL soon and I don't want 
        addressing snafus because we can't get Sun OS to work or because 
        it doesn't work.  Right now I very willing to believe that 
        problem is us and not Sun but one never knows.


                          * h e l p *

Chris Johnson
Northeastern University.
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 13:50:47 GMT
From:      larry@pdn.UUCP (Larry Swift)
To:        comp.protocols.tcp-ip
Subject:   Re: ping with routing

In article <7987@g.ms.uky.edu> nasa@ms.uky.edu (Eric Freeman) writes:
:I have heard of a version of ping that shows routing information.  If anyone
:knows information about it or has it could they please mail it to me.  Much
:thanks in advance.

Me too, please.

Larry Swift                     UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207          Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 14:18:00 GMT
From:      hsw@TYCHO.ARPA (Howard Weiss)
To:        comp.protocols.tcp-ip
Subject:   Official Sun Patch for TOD problems.


	I received this message via the UNIX-WIZARDS mailing list and it
looks like it was not distributed to TCP-IP.  This is claimed to be
the official SUN patch for Sun OS 3.2, 3.3, 3.4, 3.5.

Howard Weiss

------------------------------------------------------


From: Chuq Von Rospach <chuq@plaid.Sun.COM>
Subject: Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!
Date: 5 Jan 88 21:57:40 GMT
Sender: news@sun.uucp
Keywords: TOD, clock, ntp, date
To:       unix-wizards@SEM.BRL.MIL

In article <5203@columbia.edu> dupuy@columbia.edu (Alexander Dupuy) writes:
>Ever since the leap second (23:59:60 GMT Jan 1, 1988) the realtime clocks on
>Sun-3s have been behaving strangely.  When booting /vmunix, just after the
>message about using nn buffers, the kernel prints out a little message like the
>above.

here's the official sun3 patch. The official sun4 patch will be posted as
soon as it gets released and I get approval.

Chuq
Sun Tech Support
============================================
There exists a problem for all Sun3 (68020) machines running SunOS
Releases 3.0-3.5, 4.0beta1, and all Sun4 (SPARC) machines running SunOS
Release Sys4-3.2 FCS and 4.0beta1.

As of Jan 1 00:00 1988, the clock routine in the kernel will put the
clock chip into an uncertain state if you attempt to set the date.
The visible effects of this is to 1) cause the message

        WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

to appear while booting vmunix, and to 2) cause the system date to start
to drift widely. Any attempts to actually *set* the date will have only a
temporary effect (i.e., the date you set will be good for about 30 seconds).

In order to solve this problem, you must patch both the kernel and system
object files.

==============================================================================

          Sun3 System Patch
          Releases 3.2, 3.3, 3.4, 3.5

As root, run the follwing command:

          echo 'resettodr+c0?i' | adb /vmunix - | grep reset

You should see the following printed out:

          _resettodr+c0:      bnes      _resettodr+0xca

If you see instead:

          _resettodr+c0:      bnes      _resettodr+0xce

the patch has already been applied to this system.
Proceed with the rest of the patch procedure anyway!

If you do not see either of these messages, go no further with this patch,
and please contact Sun Microsystems Customer Service.

If you do see either of those messages, then run, as root,
the following commands:

          cp /sys/OBJ/clock.o /sys/OBJ/clock.o-
          echo 'resettodr+c0?w 660c' | adb -w /sys/OBJ/clock.o

          echo 'resettodr+c0?w 660c' | adb -w /vmunix

Reboot and then *set* the date.

If you build kernels for your system, also rebuild your kernel.

Chuq "Fixed in 4.0" Von Rospach                   chuq@sun.COM                  Delphi: CHUQ

                       What do you mean 'You don't really want to hurt her?'
                                    I'm a Super-Villian! That's my Schtick!

-----------------------------
-------

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 15:56:00 GMT
From:      JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.")
To:        comp.protocols.tcp-ip
Subject:   Happy New Year and   *  h e l p  *


     Happy New Year and I have a question.

     We have a back bone ethernet around the campus.  Off of this is the 
occasional diskless workstation farm.  These are Sun systems.  That's 
the topology.

     We also have a set of Class B internet addresses.  The back bone 
has been given a subset of these addresses and we want to use a 
different subset for the off back bone diskless systems.  

     We have been waiting for Sun OS 3.4 to come so that we could use 
subnets which seems to be the solution to separating things.  We now 
have 3.4 but can't get any of the diskless wonders to boot when we put 
the class B addresses up.  HOWEVER, booting seems to work just fine when
the diskless ethernet segments are given a class C address and the back
bone a class B address.  We believe we are having a tough time making
Sun OS 3.4 work with subnets but aren't sure.  It's hard to tell with
UNIX and we only have a moderate level of expertise here. 

     One more fly in the ointment is that we have a ComputerVision 
system which is a Sun diskless wonder farm off a disk server which is 
running Sun OS 3.2 and isn't likely to change any time soon. 
ComputerVision is a little behind. 

     Question:

     1) Has anybody made subnets or a similar configuration to the 
        above work with Sun OS 3.4?  If so, HOW? (*help*)

                             or

     2) If I bring this mess up with class B addresses on the back bone
        and class C addresses on the diskless segments, will packets  
        with class C addresses ever escape on to the back bone?  These 
        diskless systems are to be allowed to log in to other machines 
        which are on the back bone.  The problem is that we are 
        scheduled to be connected to JVNCNet REAL soon and I don't want 
        addressing snafus because we can't get Sun OS to work or because 
        it doesn't work.  Right now I very willing to believe that 
        problem is us and not Sun but one never knows.


                          * h e l p *

Chris Johnson
Northeastern University.

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 15:58:44 GMT
From:      ncs-med!pwcs!quest!cnt!rod@umn-cs.arpa  (rod merry)
To:        tcp-ip@sri-nic.arpa
Subject:   gated/RIP info request
I'm looking for background information, specs, RFCs, or source on
the protocols supported by "gated".  My understanding is that RIP
is among these, if not, I'm real interested in getting info on it
too.  Please respond directly and I will summarize.

Thanks in advance
rod
-- 
Rod Merry                               rod@cnt.MN.ORG
Computer Network Technology             {quest|meccts}!cnt!rod
9440 Science Center Drive		     
Minneapolis, MN 55428                        (612)535-8111
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 16:08:59 GMT
From:      jbs@eddie.MIT.EDU (Jeff Siegal)
To:        comp.protocols.tcp-ip
Subject:   RARP or BOOTP for BSD wanted

We need one of these protocols so our Cisco terminal server can
determine its IP address when it boots up.  Any suggestions?

Jeff Siegal

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 17:46:52 GMT
From:      hedrick@aramis.rutgers.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   bootp/rarp

I am sending a copy of bootp to Jeff under separate cover.  We recommend
using bootp rather than rarp where possible:
  - it is designed to go through gateways.  You can boot a large
	network of cisco equipment from a single boot host (or from
	more than one, as long as they are all on one subnet) if
	if want to.  THis may be convenient for networks where it
	is not practical to have servers at each location.
  - it does not need a kernel change to install.  Rarp does not use
	TCP or UDP, so you need to hack some kernel tables if your
	system doesn't already implement it.  Note that Sun, which
	does claim to implement it, often can't be used to boot
	cisco equipment, because Sun's RARP drops all but one request
	when it gets several at once.
Bootp requests that your kernel have an ioctl to install a new
ARP table entry.  This is needed in order to get the response back
to the requestor.  Obviously the requestor is not yet in a position
to respond to an ARP request.  4.3, and most vendor-supplied versions
of 4.2, has such a call.

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 18:08:04 GMT
From:      vasilis+@andrew.cmu.EDU (Vasilis Apostolides)
To:        comp.protocols.tcp-ip
Subject:   Re: Official Sun Patch for TOD problems.


Thanks, since I now subscribe to the tcp-ip bboard it isn't necessary to mail 
me more related stuff. Anyway, the official Sun patch doesn't help us since it 
only covers versions 3.2 and there after (so binary patch doesn't directly 
apply to older suns -- v3.0!)

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 19:33:22 GMT
From:      chuq@plaid.Sun.COM (Chuq Von Rospach)
To:        comp.protocols.tcp-ip
Subject:   Sun TOD Clock bug Patches for all releases

[These are the official patches from Sun for all known affected releases
 in the field. If you have any questions or problems, please call Sun
 Tech Support]

There exists a problem for all Sun3 (68020) machines running SunOS
Releases 3.0-3.5, and all Sun4 (SPARC) machines running SunOS
Release Sys4-3.2 FCS and Sys4-3.2L GAMMA. This problem does not
exist for Sun-2's.

As of Jan 1 00:00 1988, the clock routine in the kernel will put the
clock chip into an uncertain state if you attempt to set the date.
The visible effects of this is to 1) cause the message
  
        WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!  
  
to appear while booting vmunix, and to 2) cause the system date to start
to drift widely. Any attempts to actually *set* the date will have only a
temporary effect (i.e., the date you set will be good for about 30 seconds).
  
In order to solve this problem, you must patch both the kernel and system
object files.

==============================================================================

	Sun3 System Patch
	Releases 3.2, 3.3, 3.4, 3.5
  
  This is for Diskful and Server Machines only. Diskless machines need to
  be fixed on the server.

As root, run the follwing command:

	echo 'resettodr+c0?i' | adb /vmunix - | grep reset

You should see the following printed out:

	_resettodr+c0:	bnes	_resettodr+0xca

If you see instead:

	_resettodr+c0:	bnes	_resettodr+0xce

the patch has already been applied to this system.
Proceed with the rest of the patch procedure anyway!

If you do not see either of these messages, go no further with this patch,
and please contact Sun Microsystems Customer Service.

If you do see either of those messages, then run, as root,
the following commands:

	echo 'resettodr+c0?w 660c' | adb -w /vmunix

Reboot and then *set* the date.

If you build kernels for your system, or are a server for diskless clients,
do, as root

	cp /sys/OBJ/clock.o /sys/OBJ/clock.o- 
	echo 'resettodr+c0?w 660c' | adb -w /sys/OBJ/clock.o


and then rebuild your kernel and/or the kernels for your diskless clients.

==============================================================================

        Sun3 System Patch
	Release SunOS Release 3.0

  This is for Diskful and Server Machines only. Diskless machines need to
  be fixed on the server.

As root, run the following command:

        echo 'todset+0xb4?i' | adb /vmunix -

You should see the following printed out:

        _todset+0xb4:   bnes    _todset+0xbe

If you see instead:

        _todset+0xb4:   bnes    _todset+0xc2

the patch has already been applied to this system.
Proceed with the rest of the patch procedure anyway!

If you do not see either of these messages, go no further with this patch,
and please contact Sun Microsystems Customer Service.

If you do see either of those messages, then run, as root,
the following command:

        echo 'todset+0xb4?w 0x660c' | adb -w /vmunix

Reboot and then *set* the date.

If you build kernels for your system, or are a server for diskless clients,
do, as root

        cp /sys/OBJ/clock.o /sys/OBJ/clock.o-
        echo 'todset+0xb4?w 0x660c' | adb -w /sys/OBJ/clock.o

and then rebuild your kernel and/or the kernels for your diskless clients.

==============================================================================

	Sun4 System Patch
	Release Sys4-3.2 FCS, Sys4-3.2L GAMMA
  
  This is for Diskful and Server Machines only. Diskless machines need to
  be fixed on the server.
	
	echo 'resettodr+0x110?i' | adb /vmunix -

You should see the following printed out:

	_resettodr+0x110:               sub     %i5, 0x1, %i5

If you see instead:

	_resettodr+0x110:               sub     %i5, 0x0, %i5

the patch has already been applied to this system.
Proceed with the rest of the patch procedure anyway!

If you do not see either of these messages, go no further with this patch,
and please contact Sun Microsystems Customer Service.

If you do see either of those messages, then run, as root,
the following command:

	echo 'resettodr+0x110?W ba276000' | adb -w -k /vmunix /dev/mem

Reboot and then *set* the date.

If you build kernels for your system, or are a server for diskless clients,
do, as root

	cp /sys/sun4/OBJ/clock.o /sys/sun4/OBJ/clock.o- 
	echo 'resettodr+0x110?W ba276000' | adb -w /sys/sun4/OBJ/clock.o 

and then rebuild your kernel and/or the kernels for your diskless clients.

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 20:23:58 GMT
From:      larry@sbo.UUCP (Larry Mullen)
To:        comp.protocols.tcp-ip
Subject:   Re:  Remote Virtual Disk


	We also market a product to provide a virtual disk for PCs. The
name is PC Interface. It supports multiple PCs over RS232, or LAN under tcp/ip,
or xns. It will allow the PC users to set up multiple virtual disks on our
Unix system, based on a Unix login and password. Users can also use the PCs
as virtual terminals. Apparently, it was developed by Locus, but part of it 
must be ported to the Unix which you connect to.

							Larry Mullen

							...mot!nud!sbo!larry

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 88 01:33:52 EST
From:      gross@gateway.mitre.org (Phill Gross)
To:        tcp-ip@sri-nic.arpa
Subject:   Leaping Lizards

Since the leaptime issue has hung around until Christmas (for Orthodox 
Christians, that is), I thought it would be appropriate to give wider 
distribution to a private note I exchanged earlier.  (The note below 
was originally in response to a comment about "Pope Julian's" calendar.)

> Actually, it was Pope Gregory XIII who, in 1582, revised the Julian calendar
> by lopping out 10 days.  He declared that Oct 5th, 1582 would become Oct
> 15th.  The extra ten days had accumulated because the year is actually 
> 365.2425 solar days long, not 365.25 as Caesar and all our elementary 
> school texts claim.  (Actually, the year is 365 days, 5 hours, 48 minutes 
> and 48 seconds, which is 365.242216 solar days, but who's to quibble?)
> 
> This means that under Caesar's rules, in every century you were adding about
> .75 too many days.  By the 1500's, this amounted to approximately the
> aforementioned 10 days.  To keep things straight in the future, Gregory
> added the rule that henceforth centesimal years would be leap years only
> when divisible by 400.  This cleverly means that you only add 97 days every
> 400 years, instead of 100, which is more like it (.2425 x 400 = 97).
> 
> Of course, Britain and the colonies didn't catch on until September 1752,
> which meant they had to chop out 11 days (try typing `cal 1752' on your local
> Unix box).  This plays havoc with the biographers of our founding fathers,
> most of whom were born before the British date switch but died after it.
> Since the Eastern Orthodox and the Roman Catholics had mutually 
> excommunicated each other, Russia didn't catch on until after the 1917 
> revolution.
> 
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 22:22:54 GMT
From:      jth@cuuxb.ATT.COM (6414~)
To:        comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: What is the procedure to simulate the limits of protocols?

In article <4431@caip.rutgers.edu> schen@caip.rutgers.edu (Shin Chen) writes:
>
>I would like know how one goes about finding the theoretical and real
>limits (maximum, minimum,and average) of various protocols. This includes
>equipment, methodology and/or ideas.  
>- Shin Chen
Misha Shwarz of Columbia University has written a good text on the
subject. It's more on the analysis side but it's part of the answer to
your question. Protocol venders should be able to provide benchmark
data (caveat emptor) on their products.
					Joe Heneghan

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 22:41:14 GMT
From:      ROMKEY@XX.LCS.MIT.EDU (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote Virtual Disk

A recent message contained some disinformation about RVD.

RVD is the Remote Virtual Disk protocol, which was designed and implemented
at the MIT Lab for Computer Science several years ago. It is a DISK
sharing protocol rather than a FILE sharing protocol. It sends requests
to a server for reading and writing disk blocks by offset into the disk.
Because it is a disk sharing protocol, it sits below the filesystem,
so although you could share a disk between a UNIX and an MS-DOS system,
it wouldn't be useful because there would either be a UNIX or an MS-DOS
filesystem on that disk that one of the two systems wouldn't understand.

RVD was originally written for 4.2BSD. The VAXen at LCS all had small
disks (RK07's) and we wanted to have some disk servers to share things
like UNIX which didn't change very often, and to have some large private
disks for individual projects. RVD doesn't provide any synchronization
between disk accesses. Since synchronization would really have to
occur at a filesystem level and RVD is below the filesystem, this
is fairly reasonable. RVD allowed disks to be accessed as read only
or read write (shared or exclusive). Nobody ever wrote the companion
synchronization protocol that would be needed to allow multiple writers,
so we never used it in this mode.

Also, RVD was never a part of PC/IP. I wrote a PC/IP RVD client as a hack,
and a few people around LCS started using it. But we never got RVD packaged
up and stabilized as much as we felt was necessary in order to include
it in PC/IP, largely because of all the UNIX modications that were necessary.
There were some references to it in the PC/IP documentation, though.
I don't believe that MIT ever had an 'official' release of RVD, though a
few copies were slipped to people.

Anyway, RVD is not useful for sharing filesystems between UNIX and MS-DOS
because it's a disk protocol and not a file protocol, and
because it wouldn't allow multiple writers.

To get back to the desired goal, I would recommend one of two approaches:
	NFS - currently only available from Sun
or
	SMB over NETBIOS - put up a NETBIOS SMB server
		on the UNIX system and get NETBIOS
		for the PC and run the PC LAN program.
		NETBIOS for the PC is available from
		many vendors and there are a few
		people out there working on it for
		UNIX (try Syntax).

			- john romkey
-------

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 23:42:39 GMT
From:      beadel@OSWEGO.OSWEGO.EDU (Edward.F.Beadel@oswego.oswego.edu, Jr.)
To:        comp.protocols.tcp-ip
Subject:   Re: Need TCP/IP on RSTS/E

>> 					... The problem with RSTS is
>>    that DEC has never done anything to ease user-written device drivers,
>>    and there was nothing like the VMS XE driver to allow user programs to
>>    get at the raw ethernet the last I knew.
>  I heard rumors (shortly after you left the RSTS community James, and
>  shortly before I did) that such an interface was in the offing.  I
>  have not heard what came of that.

In the RSTS/E V9.4 Programming Manual (DEC Order Number AA-EZ09A-TC {
including AD-EZ09A-T1,T2}) the aboved problem is addressed: " In order to
increase the flexibility of Ethernet on RSTS/E, DIGITAL has provided a
direct interface to the Ethernet data link layer for RSTS/E users. This 
interface resembles the interface provided for the DMC/DMR communications
devices, and can be programmed with or without DECnet/E on the system."
(page 11-3)

This allows use of both UNIBUS controllers (DELUA and DEUNA) as device XE:
and the Q-bus controller (DEQNA) as device XH:.

		Edward F. Beadel, Jr.
		RSTS SIG Steering Committee
		UNIGIG rep to DECUS PDP-11 Task Force

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 88 00:49:50 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Xerox's XNS protocols....

Is there on line documentation anywhere for the XNS protocols ?
At the moment, Id especially like to get a sort of overview on
how the whole thing works...

Thanks
Bill W
-------

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 88 00:58:20 GMT
From:      Stevens@A.ISI.EDU (Jim Stevens)
To:        comp.protocols.tcp-ip
Subject:   Why IP & TCP Precedence Query


Michael Padlipsky wanted to know why I asked about IP & TCP
Precedence.

Well, I am trying (for quite a while now actually) to complete an RFC
on a new protocol called Transaction Transport Protocol (TTP).  TTP
differs from TCP and UDP by providing reliable message delivery
instead of reliable byte stream or unreliable packet delivery.
Anyway, one of the optional TTP services is precedence and
preemption.  Note that the optional TTP service is more than just a
field reservation since the draft TTP RFC actually describes the
processing which is performed at the TTP level based upon the TOS. 

I propose to get the priority level out of the precedence field
within the IP Type Of Service (TOS) field.  In fact, my TTP packet
format includes the IP TOS within the TTP pseudo header of
information which is obtained from the IP layer and is TTP
checksummed (similar to UDP & TCP pseudo headers except that the zero
octet is replaced by the IP TOS).  My question to the TCP-IP
distribution list was prompted when a reviewer questioned whether the
IP TOS field was available from all IP implementations. 

Since no one has said otherwise, I presume that the IP TOS is
available in all IP implementations.

As pointed out by John Lekashman <lekash@orville.nas.nasa.gov>,
authentication is required for fair TOS processing by IP to prevent
people from setting their priority to the highest possible and thus
hogging the network.  Also as pointed out by Dan Lynch
<LYNCH@A.ISI.EDU>, the IP TOS processing would have to be implemented
by everyone if the TOS parameters are ever to have any use.

I feel that precedence makes more sense at the Transport Level since
the authentication issues are simpler than at the Internet Level
and also since fewer people would have to implement precedence for it
to make sense.


Jim


P.S I have been asked if I could forward any responses I got to the
TCP-IP distribution list.  Well so far all of the responses that I
have received were also CC'd to the list.


P.P.S I feel that there is a flaw to TCP's use of precedence and
security.  The TCP Military Standard (MIL-STD-1778) specifies the
processing to be performed based upon the IP precedence field and
security options.  (I believe that the TCP RFC also specifies the use
of the IP TOS and Security options but do not have a copy of the RFC
with me to check right now).  The use of the IP fields is fine and
dandy since it is a standard and since it saves space in the TCP
header.  Unfortunately, TCP does not checksum the IP precedence field
or the security options.  Thus these fields could have been changed
or corrupted en route between the 2 TCP implementations and this
change would not be detected by TCP.

You could say that the IP header checksum would detect this sort of
error.  Well if we must depend upon the IP header checksum why does
TCP have a checksummed pseudo header at all?  I am sure that the
reason we have the TCP pseudo header is to detect if IP corrupted the
addresses and protocol number.  I am also sure that the reason why
the TCP pseudo header does not include the precedence and security
fields is just an oversight.


-------

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 88 01:01:11 GMT
From:      andre@nrc-ut.UUCP (Andre' Hut)
To:        comp.protocols.tcp-ip
Subject:   Re: WWV update

In article <8712241814.AA06202@trantor.UMD.EDU> louie@TRANTOR.UMD.EDU ("Louis A. Mamakos") writes:
>Hey, if we're gonna insist on an advance-warning-leap-second, then we really
>should insist on having the YEAR be transmitted as well.  Please!

Yeah!  And how about a checksum too?  Every once and awhile, my heathkit clock sets itself to
the "correct" time, but it is several hours off.
-- 
-----------------------------------------------------------------------------
                sdcsvax-\         ihnp4-\
                         \               \
Andre' Hut              sdcrdcf!psivax!nrcvax!nrc-ut!andre
                         /              /        /
                hplabs--/ ucbvax!calma-/        /
				utah-gr!uplherc/
Network Research Corporation
923 Executive Park Dr. Suite C
Salt Lake City, Utah 84117
-----------------------------------------------------------------------------

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 88 06:16:25 GMT
From:      gamiddleton@watmath.waterloo.edu (Guy Middleton)
To:        comp.protocols.tcp-ip
Subject:   where to get POP?

I know this has been discussed here before, but I can't find my copy.  Can
anybody tell me where to get POP (and what it does, exactly)?  Thanks.

 -Guy Middleton, University of Waterloo Institute for Computer Research
 gamiddleton@math.waterloo.edu, watmath!gamiddleton

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 88 08:08:06 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Leaping Lizards

Phill,

Wonderful, I love it! Now, we have something going. Pure Science and Pure
History have to be one and the same. My Wife, the History Major, salutes you.
Remeber, the Roman roads go straight as the arrow and do bob from bot
to top; however, the Scots, being more sneaky, snake form side to side...

Dave

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 88 13:14:32 GMT
From:      steve@BRILLIG.UMD.EDU (Steve D. Miller)
To:        comp.protocols.tcp-ip
Subject:   Re: MILNET/?/UMDNET/SURA/GWU-GATE traffic question


	Subject: Re: MILNET/?/UMDNET/SURA/GWU-GATE traffic question 
	From: Stephen Wolff <steve@note.nsf.gov>

	What Record Route is showing you is the packet traveling from
	128.167.33.1 - presumably the GWU_campus_net-to-SURANET P4200
	gateway at GWU - (but why it spent so much time there I don't
	understand) to 128.167.11.2 - the next P4200 (which happens to be at
	NSF) - to the principal node of SURANET at University of Maryland,
	College Park, where it is loaded onto MILNET.  That is in fact the
	most direct route there is.

   Indeed, that is the most direct route there is.  However, one of the
restrictions under which we at UMCP operate is that we can never ever
forward packets from ARPANET, NSFNET, SURANET, et al.  directly to MILNET.
(Otherwise, we'd effectively be a mailbridge.)  The only packets that can
cross our MILNET gateway are those with an IP source address on network
128.8.  (There is a hack in the kernel on maryland-gw.arpa (a 4.3BSD host)
that enforces this restriction.)

   A quick peek at the UMCP ARPANET gateways tells me that they're routing
MILNET traffic via DCEC-MILNET-GW.ARPA, at least for the moment.  I don't
have access to the UMCP SURANET gateways, so I don't know exactly what they
want to do with MILNET traffic, but I assume they send it to the ARPANET
gateways.  If someone from SURANET is reading this, and could check the
routing, that would be good...

	-Steve

Spoken: Steve Miller    Domain: steve@mimsy.umd.edu    UUCP: uunet!mimsy!steve
Phone: +1-301-454-1808  USPS: UMIACS, Univ. of Maryland, College Park, MD 20742

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 88 14:34:44 GMT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Application Programming Interface for FTP


Yes, I have such a thing (I think), I'll mail it to you under a separate
letter when I dig it out.

-Ron

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 88 14:47:24 GMT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Happy New Year and * h e l p *


We have much the same situation and are also on JvNCnet.  We
just run 3.2 on everything and tell them that they are on a
class B net and let the routers do ARP spoofing.  We use CISCO,
but most of the popular gateways support this mode of operation.
The only area where any level of trickery arises is when a host
has interfaces on two subnet cables.  All of our Suns run 3.2.
We decided to hold out until 4.0 rather than spending the semester
debugging 3.4 which doesn't really offer any increased features
(just bugs).

-Ron

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 88 16:51:38 GMT
From:      ron@MANTA.NOSC.MIL (Ron Broersma)
To:        comp.protocols.tcp-ip
Subject:   Re:  Happy New Year and   *  h e l p  *

I have had similar (painful) experiences with trying to get the subnet
support on Sun OS 3.4 to work.  I saw similar problems with the early 
attempts at getting subnets in 4.2 BSD and I assume that the Sun code
has the same problems.  I was able to fix the 4.2 problems because I had
sources for it.  I don't have Sun sources so I have had a hard time 
isolating the problem in Sun OS.  Of course, all these problems were fixed
in 4.3 which supports subnets very well in my experience.

From what I can tell, it looks like the routing code is very braindamaged.
On a host with multiple interfaces on the same Class B net (but all on
different subnets) it cannot seem to figure out what's the right net interface
to use when installing a route.  It often gets the wrong one.  I also found
that I had to turn off routed because it was making important routes just
disappear.

At this point I've sort of given up on subnet support in Sun OS until my
sources arrive (soon, I hope).  Once I have sources I'm sure I'll be able
to track down the problem and get a better understanding of what's going
on.

--Ron
(ron@nosc.mil)

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 88 16:54:34 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Net Management meeting on Jan 21

There will be a meeting of the network management working group to describe
the work in process and delineate schedules for accomplishments in this
year.  The final agenda wil be announced by Jan 15.  The meeting will take place
at the Santa Clara Marriott hotel (on the corner of Great America Parkway
and Mission College Blvd in Santa Clara.  It is about 5 miles from San Jose
airport.)  If you wish to attend please send me a message or call anyone 
at Advanced Computing Environments (408-996-2042) to sign up for the
meeting.  This meeting is open to all and is scheduled to run from 9-5.

Dan
-------

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 88 17:48:09 GMT
From:      jimbys@tybalt.caltech.edu  (James V. Bys)
To:        tcp-ip@sri-nic.arpa
Subject:   tn3270
A while ago there was posted (I hope in this newsgroup) the location
of a tn3270 package available via anonymous ftp.  I have misplaced
this location.  Could someone remind me of it?

Thanks!

James V. Bys
California Institute of Technology

Internet address: jimbys@iago.caltech.edu
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 88 18:11:02 GMT
From:      long@yale.UUCP (H. Morrow Long)
To:        comp.protocols.tcp-ip
Subject:   Query on ICMP redirect handling when received by 4.3BSD hosts


	We (Yale CS and EE depts) are preparing for an NFSNET (actually JVNCnet)
	gateway that will be added to the local network configuration in
	addition to our ARPAnet gateway.  We have successfully used Gated
	to replace the the EGP daemon on our local backbone and we would
	like to have the gateway used for reaching default routes be dynamically
	switched (between JVNCnet and ARPAnet) by using ICMP redirects.
	Unfortunately looking at the 4.3BSD code it appears that although
	sending ICMP redirects from a 4.3BSD gateway is fairly developed the
	receiving of an ICMP redirect by a 4.3BSD host merely marks the fact
	that the route was obtained dynamically from an ICMP redirect but the
	redirect is never aged and removed (timed out).  The 4.3BSD routed
	has a comment inside main.c in the infinite for loop where select
	is called to wait for RIP input and process() is called if there is
	rip input that says 'handle ICMP redirects' but there is code in the
	4.3BSD routed that appears to handle ICMP redirects.  Is this true?
	Is there a version of routed that does?
	
						H. Morrow Long
						long-morrow@cs.yale.edu

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 88 21:39:07 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: ip/icmp/echo messages

I don't know about 4.3 unix, but I can answer your questions in a more
general sense.

	 3)  who has already implemented such an animal (probably only
		 about 50,000 people or so?).  I understand there's a program
		 called "ping" which uses echo.  Is it what I'm looking for?

  Cisco systems gateways and terminal severs have a ping command that
fully supports (both loose and strict) source routes, timestamps, and
record route.  A number of design decisions were made so that these
would be maximally useful.

	 1) Can icmp echo/reply messages can be sent with ip headers 
		 that specify strict source routing.

Yes, of course you can send ICMP messages with source routes.  However,
it is not clearly defined what should happen when, say, and ICMP echo
request with options is received.  The ICMP spec says that you should
just swap the IP source and destination addresses and send the packet.
However, if the packet has a source route, you might want to use the
reverse route for the echo reply, and this requires more processing.
In the cisco products, source routes are reversed, but record route
and timestamp pointers are left unchanged (so you can see both paths).
4.3 bsd sends out the echo reply with no options whatsoever...

Another problem is that very many systems, including gateways, do not
fully (or correctly) support IP options.  In the case of a source routed
packet, it will probably just get dropped along the way, even if the path
is good.  Record route and timestamps just won't get filled in.

An additional problems is that the IP header really isn't quite big enough.
It could be really useful to have a loose source route and a record route
in the same packet, but they would only be able to hold a total of 8 hops,
which is not enough to be useful.


	 2)  whether this would be useful in creating a looptest tool for 
		 customer service to check out specific serial links, and

Well, the PING command all by itself is about the single most useful
network debugging tool we have found.  It isn't clear how useful
adding option support to it is.  I guess potentially this would allow
you to debug more of a network from some specific site, especially if
you have gateways that cannot be remotely logged into.  And yes, it is
especially useful for debugging serial links.  Cisco's ping process
wont reply to a ping addressed to a 'down' interface, even if the ping
arrives and would be sent out on an 'up' interface.  This is a useful
feature, as it potentially lets you tell which side of a link is down,
but I think that it is not common.

Bill Westfield
cisco Systems.
-------

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 88 21:59:15 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP or BOOTP for BSD wanted


A BOOTP server for 4.x BSD is available via anonymous FTP from 
lancaster.andrew.cmu.edu.  "cd" to directory "pub" and get bootp.tar in binary 
mode.  The server is a slightly improved version of Bill Croft's (Stanford) 
original code.

Drew

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 88 01:23:28 GMT
From:      JLarson.pa@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Xerox's XNS protocols....

They are in hardcopy form (bound gray booklets w/graphics). The protocols you
probably are most interested in are;

Internet Transport Protocols, XSIS 028112
Courier: The Remote Procedure Call Protocol, XSIS 038112
Time Protocol, XSIS 088210
Clearinghouse Protocol, XSIS 078404
Authentication Protocol, XSIS 098210

They can be obtained by sending US mail to;

	Xerox Corporation
	475 Oakmead Parkway
	Sunnyvale, CA  94086
	ATTN:  Pam Cance

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 88 03:18:02 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Happy New Year and * h e l p *

Ron's commands might leave the impression that Rutgers does not
support subnets on our Suns.  Our copy of SunOS 3.2 does support
subnets.  (It is quite easy to do this, even without source.)  While
we use proxy ARP on our cisco gateways to do some of the subnet
routing, where we choose to do so we do it by telling the hosts
explicitly that it should treat all routes as local (route add 0.0.0.0
`hostname` 0).  Of course this is not practical for hosts with
interfaces on more than one Ethernet.

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 88 04:07:32 GMT
From:      dpk@bway.UUCP (Doug Kingston)
To:        comp.protocols.tcp-ip
Subject:   Re:  Happy New Year and * h e l p *

By default, Sun does not initialize the netmask with ifconfig
	e.g. ifconfig le0 `hostname` netmask 255.255.255.0

This needs to be done on the server only, since a 3.3 or 3.4 SunOS
diskless node will make a ICMP netmask request.

I am interested in knowing if this is the problem.

-Doug-

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 88 04:09:52 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: Application Programming Interface for FTP

FTP Software's PC/TCP Developer's Kit (V2.0) has such an interface.  I didn't
do it, but I'm not now aware of any others, or any standard to follow.  There
are a dozen or more functions you can call, like ftp_stor() and so forth.

jbvb

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 88 15:42:38 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Leaping Lizards

Dave:

Be careful what you say!  Scotland has great scenery and you need curves to
have a place for a lay by so the tourists can stretch their legs and enjoy
the view.  Anyway, its sometimes difficult to go in a straight line after
consuming the Water of Life and its wiser to snake the road and keep the
vehicles off the berm.

Merton

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jan 88 00:46:55 -0500
From:      Jeffrey C Honig <jch@devvax.tn.cornell.edu>
To:        long@yale-zoo.arpa (H. Morrow Long)
Cc:        tcp-ip@sri-nic.arpa, gated-people@devvax.TN.CORNELL.EDU
Subject:   Re: Query on ICMP redirect handling when received by 4.3BSD hosts
>	We (Yale CS and EE depts) are preparing for an NFSNET (actually JVNCnet)
>	gateway that will be added to the local network configuration in
>	addition to our ARPAnet gateway.  We have successfully used Gated
>	to replace the the EGP daemon on our local backbone and we would
>	like to have the gateway used for reaching default routes be dynamically
>	switched (between JVNCnet and ARPAnet) by using ICMP redirects.
>	Unfortunately looking at the 4.3BSD code it appears that although
>	sending ICMP redirects from a 4.3BSD gateway is fairly developed the
>	receiving of an ICMP redirect by a 4.3BSD host merely marks the fact
>	that the route was obtained dynamically from an ICMP redirect but the
>	redirect is never aged and removed (timed out).  The 4.3BSD routed
>	has a comment inside main.c in the infinite for loop where select
>	is called to wait for RIP input and process() is called if there is
>	rip input that says 'handle ICMP redirects' but there is code in the
>	4.3BSD routed that appears to handle ICMP redirects.  Is this true?
>	Is there a version of routed that does?

Gated will time out routes learned by ICMP redirect.

Jeff
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 88 23:39:43 GMT
From:      tsmith@USNA.MIL ("Tim G. Smith", Mechanical)
To:        comp.protocols.tcp-ip
Subject:   Manufacturers of networking equipment


  Does anyone know of a good source of information about manufacturers of
networking equipment?  I have been reading Data Communications magazine but I
would like to find other (more TCP/IP oriented) sources of information. 

  If anyone out on the net has any experience with networking
manufacturers I am currently trying to gather some info on who
manufactures reliable, reasonably priced 9.6-64 kb modems suitable for use
with SLIP. I am also interested in hearing about experiences with
microwave or laser transmision of either TCP/IP or SLIP over short (up to
2 miles) distances. 

					Thanks,
					Tim Smith

				E-Mail :<tsmith@usna.mil>

				US mail:Tim Smith
					CADIG mailstop: 11G
					US Naval Academy
					Annapolis, MD 21402

				Tel #  :(301)267-4413
					

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 88 06:55:32 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Leaping Lizards

Merton,

Nonsense, and mind ye haggis, m'boy. Wee ken I spent the year teaching
the lads computer science at Edinburgh a few years back. Why, e'en the
sheep did mow the fuzz on Arthur's tail and the thistle's ball and
thus became the fuzz-ball. 'Ta and a round to fair Robert, but mind
the tee shot on the fourteenth...

Dave

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 88 18:20:20 GMT
From:      slevy@UC.MSC.UMN.EDU (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Re:  Happy New Year and * h e l p *

> By default, Sun does not initialize the netmask with ifconfig
> 	e.g. ifconfig le0 `hostname` netmask 255.255.255.0
> 
> This needs to be done on the server only, since a 3.3 or 3.4 SunOS
> diskless node will make a ICMP netmask request.

Be aware that there may be a bootstrapping problem with this.
The ICMP netmask request is broadcast, not sent only to the server,
and SUNs (3.3 at least) take the first reply received.
So if there are subnet-capable machines that haven't got the word yet,
they might propagate wrong broadcast masks.  If you wire the netmask
into the server, and then either take other hosts down or feed them
the right mask, just once, everything should work after that :->.

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 88 22:18:39 GMT
From:      srg@quick.COM (Spencer Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: Why IP & TCP Precedence Query


I think one of the biggest warts in TCP/IP is the stupid checksum spec.
Including noncontiguous, and sometimes nonexistent, fields in the checksum
insures that they will be slow and awkward to compute.  If you're designing
a new protocol, PLEASE have the checksum include all of, and only, your
header and data.  If you feel you can't trust your IP level to check its
own header checksum, then please recompute the ip checksum yourself; don't
pluck bits of that header out and pretend they're your own.  If the IP
header got mangled, you shouldn't even see the packet.  If that's not
true, you need to fix your IP module.  Let's hear it for layering.

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 88 03:26:39 GMT
From:      Stevens@A.ISI.EDU (Jim Stevens)
To:        comp.protocols.tcp-ip
Subject:   Pseudo-Headers & Checksumming


Spencer Garrett responded to my message about TCP/IP Precedence &
Preemption and raised a very interesting point about pseudo-headers
and checksumming.  Garrett's message follows:

    > I think one of the biggest warts in TCP/IP is the stupid
    > checksum spec.  Including noncontiguous, and sometimes
    > nonexistent, fields in the checksum insures that they will be
    > slow and awkward to compute.  If you're designing a new
    > protocol, PLEASE have the checksum include all of, and only,
    > your header and data.  If you feel you can't trust your IP
    > level to check its own header checksum, then please recompute
    > the ip checksum yourself; don't pluck bits of that header out
    > and pretend they're your own.  If the IP header got mangled,
    > you shouldn't even see the packet.  If that's not true, you
    > need to fix your IP module.  Let's hear it for layering.

Since I am designing a new protocol, I am interested in people's
comments on the implementation difficulty of using pseudo-headers. 

In addition, I am interested in any responses on why we have
pseudo-headers which are checksummed at all in TCP.  Especially in
light of the fact that there are other IP fields which TCP could use
but does not checksum.  Two such IP fields are precedence (within
IP type of service) and security options.

Is the old "End to End Argument" a reason for having pseudo-headers?
(Reference "End-to-End Arguments in System Design" by J.H. Saltzer,
D.P. Reed, and D.D. Clark, ACM Transactions on Computer System, Nov
1984.) 

Does the pseudo-header checksumming issue have anything in common
with the issue of whether the ARP packets should have their own
checksum in addition to relying upon the Ethernet checksum?
(Remember all the messages on this subject on TCP-IP about a year or
so ago.)

If we are worried about implementation efficiency, should we place
the checksum field at the end of the protocol packet (i.e. a protocol
data unit for a particular protocol) as well as make the data to be
checksummed contiguous?  For example, David Cheriton's Versatile
Message Transaction Protocol (VMTP) places the checksum at the very
end of the VMTP packets (even after the user data) to allow the
checksum "to be calculated as part of a software copy or hardware
transmission or reception as expected in an intelligent network
interface".   (Quotes are from Cheriton's July 1987 Preliminary
Version 0.3 description of VMTP.)

Jim Stevens
-------

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 88 03:27:01 GMT
From:      carrs@TROUT.NOSC.MIL (Stephen M. Carr)
To:        comp.protocols.tcp-ip
Subject:   Forwarded: RE: Forwarded: Leaping Lizards

-------
Forwarded mail follows:
From yx0quinn@nardacva.arpa Sun Jan 10 09:52:03 1988
Message-Id: <8801101751.AA05806@trout.nosc.mil>
Date: 10 Jan 88 12:49:00 EST
From: "NEAL_QUINN" <yx0quinn@nardacva.arpa>
Subject: RE: Forwarded: Leaping Lizards
To: "carrs" <carrs>
Reply-To: "NEAL_QUINN" <yx0quinn@nardacva.arpa>

Steve,

	Just some historical clarification:  the Pope was worried that Easter
had been steadily marching closer to winter as the years wore on, thus moving
it further away from the traditional renewal period of the year, the commence-
ment of Spring.  He not only adjusted the calendar, but also 'floated' the 
day of Easter by making it the first Sunday after the first full moon after
the Vernal Equinox, thereby keeping it in line with the pagan rites that at
that time were providing fierce competition in the plebicite.

	Also, there were two major adjustments to what is now the Julian cal-
endar:  The first by Gaius Julius Caesar, who stole days from February to make
his one of the longest months, and another by Augustus Caesar, who also followed
suite.
 
               R,
               NAQJR
------

-------

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 88 07:46:41 GMT
From:      cheriton@PESCADERO.STANFORD.EDU ("David Cheriton")
To:        comp.protocols.tcp-ip
Subject:   Re:  Pseudo-Headers & Checksumming

VMTP has no need for pseudo headers a la TCP because the "entity identifiers",
the transport-level endpoints, are (inter)network level independent as is the
rest of the packet.  The data to be checksummed is contiguous as well.
Putting the checksum anywhere except at the very end of the packet seems
disasterous if you want to look good on a 100 megabit network.

David Cheriton

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 88 17:16:36
From:      Leonard D Woren <LDW@MVSA.USC.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  tn3270
The original message on how to get tn3270 was posted before I
subscribed to tcp-ip, but I have a copy that was forwarded to me when
I was trying to get tn3270.  The original posting was from Greg
Minshall on 17 Aug 87.  The specifics are:
   host - arpa.berkeley.edu (10.0.0.78)  I was unable to get this to
          work, but ucbarpa.berkeley.edu did work.
   directory - pub
   file - tn3270.tar (>700K)
        - compress(1) version in tn3270.tar.Z (>300K)

It can also be obtained on a diskette, but I can't find the info on
that right now.


/Leonard

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 88 15:05:42 GMT
From:      narten@PURDUE.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: Pseudo-Headers & Checksumming

>VMTP has no need for pseudo headers a la TCP because the "entity identifiers",
>the transport-level endpoints, are (inter)network level independent as is the
>rest of the packet.

One other important implication of the independence between the VMTP
and IP layer concerns ICMP errors. The ICMP spec requires that the
first 64 bits (8 bytes) of the transport level header be returned
along with the IP header. In protocols like TCP/UDP, the 8 byte
source/destination pair is actually part of the IP header, and by
careful arrangement of the transport header fields, source/destination
ports reside at the beginning of the packet. Because of the pseudo
header, TCP/UDP actually get back 12 bytes of useful transport header
information.  Errors such as src quench and port unreachables can then
matched up with the protocol control block that originates the
offending datagram.

In newer protocols like VMTP, I wonder if 8 bytes of transport header
is sufficient.  According the packet format given in the 86 SIGCOMM
paper, entity identifiers are 32 bits long, hence the
source/destination identifiers would use up all 64 bits of data. This
leaves no room for other possibly important information like the
forwarded entity identifier.  Without the forwarded entity identifier
field, ICMP error processing would appear to be much more difficult if
not impossible in some cases.

For instance, consider a request to read a file. The request would
first go to the directory server, which might forward the request to a
second server which answers the query directly. If the second server
is unreachable, where would ICMP errors go? Most likely, they go back
to the first server (not the originating client). The server would not
be able to match the source entity indentifier with any of its own,
and the ICMP error would likely be ignored. Meanwhile, the client
originating the request retransmits a few times and finally times out.

Is ICMP useful to newer protocols, and if not, can the Internet
operate effectively without it?

Thomas

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 88 15:56:45 GMT
From:      fedor@NISC.NYSER.NET (Mark Fedor)
To:        comp.protocols.tcp-ip
Subject:   Re:  Query on ICMP redirect handling when received by 4.3BSD hosts


	/etc/routed does not listen to ICMP redirects.  If you want your
	routing daemon to listen to redirects, use gated.  You can
	make gated run just like a "routed -q" with a very simple
	config file of:

	HELLO no
	RIP quiet
	EGP no

	Good luck,

	Mark Fedor

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 88 16:21:46 GMT
From:      fedor@NISC.NYSER.NET (Mark Fedor)
To:        comp.protocols.tcp-ip
Subject:   Re:  gated/RIP info request


	Gated supports RIP as described in the UNIX routed man
	page (with some HELLO-like extensions),  HELLO (formal
	specs, RFC 891); Beware that the HELLO in gated has changed
	to parallel the NSFNet fuzzballs, so RFC 891 is out of date.
	Gated also supports EGP (kirton's EGP). EGP (formal specs,
	RFC 904, Kirton's EGP under UNIX, RFC 911)

	Mark

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 88 16:40:15 GMT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Pseudo-Headers & Checksumming


You seem to imply that you can throw the IP addresses away when you
get to the TCP layer.  The TCP port numbers are only significant when
paired with the ip addresses as well.  You must remember this
information somewhere, so you need the pseudoheader.  Since the idea
of the checksum is to prevent insidious little errors that "can't"
happen (it's a little useless for error correction as it is a very
weak), you really want to cover all the relevent

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 88 17:42:48 GMT
From:      mckenney@distek4..istc.sri.com (Paul E. McKenney)
To:        comp.protocols.tcp-ip
Subject:   Re: Pseudo-Headers & Checksumming

In article <8801111505.AA02117@percival.cs.purdue.edu> narten@PURDUE.EDU
(Thomas Narten) writes:
>Is ICMP useful to newer protocols, and if not, can the Internet
>operate effectively without it?

Better yet:  Can ICMP be used by newer protocols that cannot fit the
source information into eight bytes?

High-speed hosts with lots of memory to burn could use the IP
`Identification' field to help match ICMP replies with recently-sent
packets, but only as long as they never send more than 65536 packets per
RTT.  This would not interfere with the normal use of this field (as an
aid in reassembling datagrams).  Furthermore, a host could unilaterally
make this use of the field, no cooperation is required.

If it is necessary to support more than 65536 packets per RTT, a new IP
OPTION field analogous to the SATNET `Stream Identifier' could be defined --
at a cost of an additional 32 to 64 bits per packet, of course!

				Thanx, Paul

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 88 18:55:14 GMT
From:      rfox@amelia.nas.nasa.gov (Richard Fox)
To:        comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: What is the procedure to simulate the limits of protocols?

In article <1477@cuuxb.ATT.COM> jth@cuuxb.UUCP (Joe Heneghan) writes:
>In article <4431@caip.rutgers.edu> schen@caip.rutgers.edu (Shin Chen) writes:
>>
>>I would like know how one goes about finding the theoretical and real
>>limits (maximum, minimum,and average) of various protocols. This includes
>>equipment, methodology and/or ideas.  
>>- Shin Chen
>Misha Shwarz of Columbia University has written a good text on the
>subject. It's more on the analysis side but it's part of the answer to
>your question. Protocol venders should be able to provide benchmark
>data (caveat emptor) on their products.
>					Joe Heneghan

Do you know where we can get a  copy of this document? I would be interested
in reading this document, because one of things that I am doing is trying
to find the real limts on certain protocols and hardware and I have found
that it is not easily modeled by any sain computation.


thanks rich
.

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 88 19:44:54 GMT
From:      JLarson.pa@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Xerox's XNS protocols....

As it turns out, there are two XNS introduction documents (in hardcopy form
only);

Xerox Network Systems Architecture: 
	Introduction to Xerox Network Systems, XNSG 058504
	General Information Manual, XNSG 068504

The first is a short overview, whereas the second is quite long (~200 pages)
with discussions of many of the different protocols.

They (and other XNS documentation) can be had by sending a message with your US
mail address to Hilary Cornell <HCornell.osbunorth@Xerox.com>.  Please allow 10
working days for delivery.

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 88 01:16:36 GMT
From:      LDW@MVSA.USC.EDU (Leonard D Woren)
To:        comp.protocols.tcp-ip
Subject:   Re:  tn3270

The original message on how to get tn3270 was posted before I
subscribed to tcp-ip, but I have a copy that was forwarded to me when
I was trying to get tn3270.  The original posting was from Greg
Minshall on 17 Aug 87.  The specifics are:
   host - arpa.berkeley.edu (10.0.0.78)  I was unable to get this to
          work, but ucbarpa.berkeley.edu did work.
   directory - pub
   file - tn3270.tar (>700K)
        - compress(1) version in tn3270.tar.Z (>300K)

It can also be obtained on a diskette, but I can't find the info on
that right now.


/Leonard

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 88 06:31:14 GMT
From:      km@emory.uucp (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   KA9Q TCP/IP for Unix-PC?

I understand there is a version of KA9Q TCP/IP for
the AT&T Unix-PC. Can someone send me the information
about it (like where to get it). My interest is in using
it with SLIP over an async modem.
-- 
Ken Mandelberg      |  {decvax,sun!sunatl,gatech}!emory!km  UUCP
Emory University    |  km@emory                             BITNET
Dept of Math and CS |  km@emory.ARPA                        ARPA,CSNET
Atlanta, GA 30322   |  Phone: (404) 727-7963

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jan 88 12:30 CDT
From:      <RLW5809%TAMSTAR.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Please remove my name from the TCP-IP Discussion List
Please remove my name from the TCP-IP-L list.

                            Thanks!

                            RLW5809@TAMVENUS
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 88 13:17:09 GMT
From:      hls@oce-rd1.oce.nl (Harry Schreurs)
To:        comp.unix.wizards,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Need help implementing IEN 116 nameserver

Currently we use the IEN 116 nameserver which was recently
sent to com.sources.unix for our Bridge terminal servers.
We also have terminal servers from Ungermann-Bass in use ( NIU's ).
We are now changing the XNS based software for these terminal servers
to TCP/IP based software. Although it should be possible to use
the above mentioned nameserver, the NIU's refuse to work with
our nameserver.
After some studying we found that the NIU's only accept responses
from our nameserver where the the IP identification has the value 0x4944 !!
This however is impossible with 4.3 BSD. I'am not able to specify the value
in the identification field of the IP header.

In ip_output.c I found the following code:

===================================================
	/*
	 * Fill in IP header.
	 */
	if ((flags & IP_FORWARDING) == 0) {
		ip->ip_v = IPVERSION;
		ip->ip_off &= IP_DF;
		ip->ip_id = htons(ip_id++);
		ip->ip_hl = hlen >> 2;
	} else
		hlen = ip->ip_hl << 2;
===================================================

The IP identification in an outgoing IP packet is given the
value of the variable ip_id which is afterwards incremented.

So I cannot assign a specific value without modifying the
source of ip_output.c

Any Suggestions?

===============================================================================
Harry Schreurs                             | DISCLAIMER:  This  note  does  not
Oce Nederland B.V., Research & Development | necessarily represent the position
p.o. box 101, 5900 MA  Venlo               | of  Oce-Nederland  B.V.  Therefore
The Netherlands         telex 58037 Oce NL | no liability or responsibility for
hls@oce.nl  or  ..!uunet!mcvax!oce-rd1!hls | whatever will be accepted.

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 88 14:13:00 GMT
From:      W8SDZ@SIMTEL20.ARPA (Keith Petersen)
To:        comp.protocols.tcp-ip
Subject:   KA9Q TCP/IP for Unix-PC?

The latest version (871225.4) of the KA9Q TCP/IP package is available
via standard anonymous FTP from SIMTEL20:

Filename			Type	 Bytes	 CRC

Directory PD1:<MISC.KA9Q-TCPIP>
NELSON.ARC.2			BINARY	  7413  B587H
NET_BM.ARC.7			BINARY	 19127  122CH
NET_DES.ARC.5			BINARY	 26249  1336H
NET_DOC.ARC.5			BINARY	143157  42C5H
NET_PC.ARC.3			BINARY	126524  0DEEH <--for IBM-PC
NET_SRC.ARC.8			BINARY	302422  0A1DH
TNC_ASH.ARC.4			BINARY	 57076  F2ECH
TNC_LDR.ARC.4			BINARY	 15790  0D43H
TNC_TNC1.ARC.4			BINARY	 52127  B5F7H
TNC_TNC2.ARC.4			BINARY	 49542  0413H

--Keith

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 88 15:21:38 GMT
From:      EWR@SEED.AMS.COM (Betsy Ramsey)
To:        comp.protocols.tcp-ip
Subject:   VAX/VMS and cisco AGS Gateways


	The AMS has a cisco Systems AGS-1E1D Internet gateway (soft-
	ware version 6.1(1)) that connects our Ethernet local area
	network to the Arpanet over a DDN X.25 connection.  We're
	having problems getting our CMU/Tek TCP/IP software (V6.2) on
	our VAX/VMS (V4.6) systems to communicate successfully through
	the gateway.  Our TOPS-20 TCP/IP software does not have this
	problem.

	If you have a cisco Systems AGS gateway (any model) connected
	to your Ethernet, and you are running any brand of TCP/IP
	software on a VAX/VMS system, I'd appreciate hearing from you.

	In particular, I'd like to know the following:

	     o  What AGS model and software revision are you using?

	     o  What TCP/IP software and version are you running on
		your VMS system?

	     o  Are you having any problems with the combination of
		the two?

	My apologies to those users who are reading this message on
	more than one list.


	Betsy Ramsey
	American Mathematical Society
	Providence, RI
	401-272-9500

	Internet: EWR@SEED.AMS.COM
-------

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 88 17:30:00 GMT
From:      RLW5809@TAMSTAR.BITNET
To:        comp.protocols.tcp-ip
Subject:   Please remove my name from the TCP-IP Discussion List

Please remove my name from the TCP-IP-L list.

                            Thanks!

                            RLW5809@TAMVENUS

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 88 17:37:27 GMT
From:      Stevens@A.ISI.EDU (Jim Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Pseudo-Headers & Checksumming


Ron, 

Sorry if I did not explain myself sufficiently.

The IP RFC 791 Receive Packet interface to Higher Level Protocols
specifies that the following information is to be made available to the
Higher Level Protocols:

RECV (BufPTR, prot, => result, src, dst, TOS, len, opt)
 
 where:

  BufPTR = buffer pointer
  prot = protocol
  result = response
    OK = datagram received ok
    Error = error in arguments
  len = length of buffer
  src = source address
  dst = destination address
  TOS = type of service (including precedence)
  opt = option data (including security/compartment information).

Now although TCP can use all of this information, in actual common use
only the prot, len, src, and dst parameters are normally used.

Note that TCP does NOT need a pseudoheader to receive this information,
rather the pseudoheader is ONLY used to verify that the most common
information passed to TCP from IP is End-to-End correct.

Thus the question(s) under consideration is(are) not whether TCP (and other
transport protocols) need the information which is passed from IP to
TCP.

Rather the questions under consideration are:

1.  Since TCP (and other transport protocols) need this information
from IP, should TCP trust the information to be correct and not have
been corrupted along the way.

2.  If TCP cannot trust IP to delivery the information 99.9999999%
correct, why does TCP only specify part of the IP information in the
pseudo-header instead of all of the passed information.


Jim Stevens

-------

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 1988 12:39-PST
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        Thomas Narten <narten@purdue.edu>
Cc:        end2end-interest@venera.isi.edu, tcp-ip@sri-nic.arpa
Subject:   Re: Pseudo-Headers & Checksumming
	From: Thomas Narten <narten@purdue.edu>:

	     ...According the packet format given in the 86 SIGCOMM
	paper, entity identifiers are 32 bits long, hence the
	source/destination identifiers would use up all 64 bits of data. This
	leaves no room for other possibly important information like the
	forwarded entity identifier.  Without the forwarded entity identifier
	field, ICMP error processing would appear to be much more difficult if
	not impossible in some cases.

The VMTP header format has changed significantly since the SIGCOMM paper
was written.  Entity identifiers are now 64 bits long, and the client
entity id is the first field of the header, which means it (and it alone)
is returned in ICMP messages.  That works out well, because the client
entity id is all that is needed to identify the appropriate protocol
control block, both at the client end and the server end, as well as
in any intermediate forwarders.

Steve Deering
-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 88 05:05:57 GMT
From:      minshall@VIOLET.BERKELEY.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270

Jim,
	You *can* ftp tn3270, but I would suggest buying it by mail.
It is a fairly large body of code (something like 350Kbytes compressed);
additionally, it is useful for the University to have some idea of
tn3270 usage in the world (for when the University makes future development
plans).

	The following is a canned message on how to acquire tn3270
via the mail:

-----

    New versions of the tn3270 and mset commands, used to logon to CMS from
unix, has been available since the late summer of 1987.

    New features are:

	o	Error messages, in English, overlay a portion of the
		screen when the user types an erroneous entry (invalid
		control sequence, attempt to enter data in an "input
		disallowed" field, etc.).

	o	Ability to "escape to shell".  This, by itself, is
		mostly useful in an MS-DOS (or non-BSD) system.

	o	An Application Programming Interface (API).  This allows
		programs, running under Unix or MS-DOS, to read and
		write the 3270 screen, and to send keystrokes (3270)
		to tn3270.  This makes use of the "escape to shell"
		feature.  Included in the (beta) distribution is a
		program which uses the API to receive files sent from
		the IBM host (we don't supply the IBM side at this point,
		and the rather stupid protocol is likely to change in
		the future).

	o	Yale ASCII/7171/4994 "transparent" mode should now
		be fully implemented.  SAS-Graph, for example,
		supports doing graphics to TEK terminals over
		this interface.  Locally, we use the X windowing
		system terminal emulator (xterm), which provides
		some TEK emulation, to display SAS-Graph graphics
		on our workstations.

	o	Mset now prints out program function (PF) keys in
		numerical order.

	o	Various bugs have been fixed.


    To obtain the source for tn3270, send a check for $100.00 (US) payable
to "Regents of the University of California" to:

	Campus Software Office
	295 Evans Hall
	UC Berkeley, CA  94720
	USA

Specify that you are ordering tn3270.

    This version will run under MS-DOS if the PC has the Ungermann-Bass
smart TCP board (NIU).

    This version will compile under MS-DOS if you have: 512K of memory;
Microsoft C version 4.0; Microsoft MASM 4.0; the Ungermann-Bass "socket
emulation library"; and Polymake from Polytron (Hillsboro, Oregon).

Greg Minshall

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 88 05:36:14 GMT
From:      brian@sdcsvax.UCSD.EDU (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   routing problems?  Core gateways?

I can't ping SEISMO.CSS.GOV from our host 'SDCSVAX.UCSD.EDU' at
26.5.0.3.  I can ping SEISMO quite nicely from our neighbor on the same
IMP (NOSC.MIL at 26.0.0.3).  We are both using the same default gateway
at 26.2.0.73, which seems to be the way the packets are going.

I guess that SEISMO could have different routes back to SDCSVAX than they 
do back to NOSC, but I don't know WHY they'd have them, since we're both
on the same IMP.

SEISMO isn't an isolated case - I can't ping any of the following hosts
from SDCSVAX, but I can from NOSC:

	uxe.cso.uiuc.edu	128.174.5.54
	mcc.com			10.3.0.62
	ius2.cs.cmu.edu		128.2.254.176
	cs.utah.edu		10.0.0.4

There are others.  And there are hundreds of mail messages waiting in
our queue because we can't get to their nameservers to get delivery 
addresses.  (There ARE hosts on network 10 that I can ping, btw, such 
as UCBVAX.)

I called the Milnet NOC, and they seemed to think that it's a core
gateway problem and told me to call BBN.  BBN assures me that they were
already working on the problem - seems that they see a problem with one
of the gateways, but I don't know what that problem would be.

I'd like to understand what's going on, as well as get it fixed.  The
only thing I can think of is that NOSC is connected to the IMP with
1822, and we're connected with X.25, but don't quite see how that would
make a difference either.  NOSC is running EGP for our 128.54 network, 
so I don't think that's the problem - if indeed that is even relevant,
since we're dealing directly with network 26 source addresses in the
pings.

Oh yeah, we've been having this sort of problem since Friday.  I'm not
sure it's always the same hosts.

I'm stumped.  Anybody got any ideas?  

	Brian Kantor
		UCSD Office of Academic Computing
		Academic Network Operations Group  
		UCSD B-028, La Jolla, CA 92093 USA
		brian@sdcsvax.ucsd.edu	(619) 534-6865

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 88 13:14:02 GMT
From:      kre@munnari.oz (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: bootp/rarp

I have a small box that has a prom monitor, and wants to use some
protocol to discover its IP address (or might want to, if it hasn't
been configured).

I currently use rarp, and would like to add bootp as an alternative.

My problem is that bootp requires sending udp to the IP broadcast
address, and that is something which (unfortunately) isn't a
constant.  That is, on many cables in the world, packets with
255's in them will be forwarded, or dropped, or just about anything
other than what you would hope.  There are many networks that still
use 0's as the broadcast address, regardless of whether or not that's
the right thing to do.

I don't much like this as a solution, but I'm contemplating sending
the broadcast to 255.255.255.255 initially, and if that works, fine.
If there's no response, I'll try 0.0.0.0 and see if that might happen
to succeed.  Then alternate.  I'm not sure if 4.2 really accepted
0.0.0.0 as a broadcast address, or only net.0, and I no longer have
virgin 4.2 sources around to check it.  Anyone know for sure?

Also, any opinions on mangling bootp this way?  Please don't bother
saying "ignore the 0 stuff", that's not acceptable.

kre

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 88 16:47:54 GMT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: VAX/VMS and cisco AGS Gateways


We have a large number of VMS machines connected to the ARPANET using
CISCO gateways (ours is an 1822 DH interface).  The TCP software we
use is Wollengong WIN/TCP 3.something.  The CISCO version is somewhere
around 6.0 I suspect, but we've not had any problems even with CISCO
version 5 and the Wollongong Version 2 TCP.  Something is most likely
misconfigured.  You might try calling CISCO customer support.

-Ron

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 88 19:02:13 GMT
From:      hans@umd5.umd.edu (Hans Breitenlohner)
To:        comp.protocols.tcp-ip
Subject:   Re: MILNET/?/UMDNET/SURA/GWU-GATE traffic question

This is an attempt to explain some of the strangeness which was reported
in and around SURA-net land.
As far as I can tell from the fragments of information, the packet 
traversed the following path:
        milnet-gw.lanl.gov             26.0.0.90
                                         Milnet                  ???
        some milnet to arpa gateway
                                         Arpanet                  56 kb serial
        umd.umd.edu/trantor.umd.edu    10.8.0.20/128.8.10.14
                                         UMD subnet 128.8.10      Ether
        bogon-gw.umd.edu               128.8.10.41/129.2.1.1
                                         UMD-BOGON-NET 129.2      Ether
        sura1 gateway at U of Md       129.2.1.2/128.167.1.1
                                         SURA subnet 128.167.1    Ether
        sura2 gateway at U of Md       128.167.1.2/128.167.2.1
                                         SURA subnet 128.167.2    56 kb serial
        sura gateway at George Washington 128.167.2.2/128.164.1.1
                                         GWU campus net           Ether
        gwuvm.gwu.edu                  128.164.1.234
>
> so far, so good
>
                                         GWU campus net           Ether
        sura gateway at GWU            128.164.1.1/128.167.2.2
                                         SURA subnet 128.167.2    56 kb serial
        sura2 gateway at U of Md       128.167.2.1/128.167.1.2
                                         SURA subnet 128.167.1    Ether
        sura1 gateway at U of Md       128.167.1.1/128.167.33.1
                                         SURA subnet 128.167.33   56 kb serial
        sura gateway at NRL            128.167.33.2
                                         SURA subnet 128.167.33   56 kb serial
        sura1 gateway at U of Md       128.167.33.1
>
> and so on, ad infinitum (or nearly so) between sura1 and sura-NRL.
>
Trantor is a Vax running 4.3 BSD.  Bogon-gw, sura1 and sura2 are Proteon
p4200 routers running release 7.4 of their software, which honors the
'record route' option.  The remaining sura gateways are Proteon p4200
routers running release 7.3 of their software, which ignores the 'record route'
option.  This shows the usefulness of this IP option, and makes us wish more
software packages would honor it.

The following is educated guesswork, since I never got to see things in this
state, and since I do not have access to gateways outside the University of
Maryland.  Apparently the gateway at NRL was advertising net 26 reachability
with a small hop count.  There was a static route configured in it,
and routing and advertising are not easily separated in that software.
This is a bad situation at any time, and for several reasons.  Apparently
it was aggravated by local Ethernet problems at NRL, which caused the gateway
to decide that the Ethernet was down, and send the packet to its default
network gateway, which was pointing back to sura1 at U of Md.

The fact that the packet arrived at all is likely a result of NRL's ethernet
problems being transient, or of the fact that the routing information between
the two gateways got straightened out and the packet was returned along the
route by which it was sent out.  Since no date/time was given with the
problem report it is hard to verify any of this.

This seems adequate to explain the extraordinary delays and the packet loss
reported.  I am at a loss to explain the duplicated packets.  Perhaps someone
else can help out with that.

The problem has been resolved, and traffic between SURA-net and Milnet should
perform much better now.  The sura1 gateway will no longer believe
net 26 advertisements from NRL, and I understand that the static route will
also be removed from the gateway there.  Ironically this is a leftover from
past attempts by various other groups to confine Milnet traffic to their
local connections.  

Thanks to cpw for reporting the problem and providing useful information.

In a case like this, where the problem was clearly confined to one net 
(128.167) it would likely be faster and more effective to contact the
administrator of the net in question directly.  The necessary information
can be obtained using the 'whois' utility (as in 'whois 128.167.0.0').
For more information on it and other services provided by the NIC you might
want to get a copy of "DDN NEW USER GUIDE", Publication # NIC 50001.  If you
can not get it through your network administrator, use the NIC's toll free
phone number 800-235-3155 to order one.

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 88 19:34:34 GMT
From:      merlin@hqda-ai.UUCP (David S. Hayes)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   Re: gated/RIP info request

In article <8801111621.AA00905@nisc.nyser.net>, fedor@NISC.NYSER.NET (Mark Fedor) writes:
> 
> 	Gated supports RIP as described in the UNIX routed man
 [deleted]
> 	Gated also supports EGP (kirton's EGP). EGP (formal specs,
> 	RFC 904, Kirton's EGP under UNIX, RFC 911)

This looks like it's just the sort of thing one would want in a
gateway Sun system.  Can anyone tell me where I can get the code
for 'gated'?  I can FTP if necessary.

T i A,
-- 
David S. Hayes, The Merlin of Avalon	PhoneNet:  (202) 694-6900
UUCP:  *!uunet!cos!hqda-ai!merlin	ARPA:  ai01@hios-pent.arpa

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jan 88 23:40 EDT
From:      <BEAME%MCMASTER.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP/IP Terminal servers on VMS Vaxen

Here at McMaster University, we have 2 780s, 1 785 and 1 8600 each equipted
with an IVECS card. We also have several CS/100s connected to other services.

Most of our 8600 access is through Ethernet with our own PC based terminal
emulator.

Here is a small list of problems/requirements of the IVECS cards.

1. A UNIBUS. Newer Vaxen don't have UNIBUSes.

2. Each IVECS card can emulate up to 6 DMF-32s and also takes up one CSR and
   vector for each emulated DMF. We had problems finding room when we added
   the IVECS card to the 8600 which already had lots of RS232 DMZ access.

3. You require a NCS/150 or NCS/150 AT to download the software to the
   cards and do any network management.

4. You can only do TELNET or RLOGIN so file transfer must be accomplished
   via serial protocols like Kermit. (We use Kermit on our PCs).

5. Currently, hitting Control-S with-out a Control-Q may lose data.

I quess I should give some good points too.

1. We have very little problem with the cards.

2. The Vax is off-loaded of all the TELNET TCP/IP processing.

    - Carl Beame
      BEAME@MCMASTER.BITNET


-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 88 19:54:27 GMT
From:      adam@hyper.lap.upenn.edu (Adam Feigin)
To:        comp.protocols.tcp-ip
Subject:   Missed article on D. Comer's TCP/IP book

Sorry to have to ask.....

I missed the article referencing Doug Comers new book on TCP/IP, although
I caught one of the followups. Could someone please send me relevant info
about it (Title, Publisher, ISBN #, etc.)

Thanks in advance.
						Adam

------------------------------------------------------------------------------
ARPAnet: {root,adam}@{hyper,apollo}.lap.upenn.edu          
UUCP: {harvard,decwrl,rutgers,ihnp4}!super.upenn.edu!hyper.lap.upenn.edu!adam

                                                      Adam Feigin
						   Network Administrator
					         Language Analysis Project
					         University of Pennsylvania
 -----------------------------------------------------------------------------

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 88 20:22:56 GMT
From:      Stevens@A.ISI.EDU (Jim Stevens)
To:        comp.protocols.tcp-ip
Subject:   ANSI drafts

T. Knowles of CAP Scientific, UK published a paper entitled "Security in
Military OSI Networks" in the IEE 2nd International Conference on Secure
Communication Systems during October 1986.  Knowles states that "In the
USA ANSI have fairly advanced drafts for [security] enhancements to the
Transport and Presentation Layers".

Does anyone know of these drafts and how I could get a copy?

Thanks,  Jim Stevens
-------

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 88 20:39:00 GMT
From:      deering@PESCADERO.STANFORD.EDU (Steve Deering)
To:        comp.protocols.tcp-ip
Subject:   Re: Pseudo-Headers & Checksumming


	From: Thomas Narten <narten@purdue.edu>:

	     ...According the packet format given in the 86 SIGCOMM
	paper, entity identifiers are 32 bits long, hence the
	source/destination identifiers would use up all 64 bits of data. This
	leaves no room for other possibly important information like the
	forwarded entity identifier.  Without the forwarded entity identifier
	field, ICMP error processing would appear to be much more difficult if
	not impossible in some cases.

The VMTP header format has changed significantly since the SIGCOMM paper
was written.  Entity identifiers are now 64 bits long, and the client
entity id is the first field of the header, which means it (and it alone)
is returned in ICMP messages.  That works out well, because the client
entity id is all that is needed to identify the appropriate protocol
control block, both at the client end and the server end, as well as
in any intermediate forwarders.

Steve Deering

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 88 23:42:15 GMT
From:      stever@videovax.Tek.COM (Steven E. Rice, P.E.)
To:        comp.dcom.modems,comp.protocols.tcp-ip,comp.protocols.misc,comp.mail.misc
Subject:   Information wanted on "safe" mappings for serial transmissions.

I am looking for information on character mappings that are used or have
been used to allow the transfer of binary (8-bit) data through channels
that cannot pass all byte values.  There are, of course, the various Hex
schemes, which simply encode each byte as two ASCII characters, but the
efficiency seems to be poorer than is necessary.  Is there a standard
8-bit to 6-bit mapping (in which 3 bytes are encoded as 4 characters for
transmission) that avoids these problems?

The mapping used in UUENCODE and UUDECODE has problems with some BITNET
sites, which change some of the special characters.  Frank daCruz wrote
in his book on Kermit that if they had it to do all over again, they
wouldn't be quite so ambitious with their use of the character set
(characters from space through tilde are used, as well as various
control characters).

I would like to be able to map arbitrary data streams to a "safe"
set of characters for transmission through a potentially-hostile
serial path.  I was thinking of using the upper- and lower-case
letters (52), the digits 0 through 9 (10), and the "+" and "-"
signs (2), for a total of 64 characters.  Is this safe, or will I
find some network node converting all my lower-case letters to
upper case?

I'm certain there are many of you who have faced just such a problem.
If you can shed any light on the issue, please send email to me at the
address below.  Thanks!

					Steve Rice

-----------------------------------------------------------------------------
* Every knee shall bow, and every tongue confess that Jesus Christ is Lord! *
new: stever@videovax.tv.Tek.com
old: {decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jan 88 10:24:59 PST
From:      DDN Reference <NIC@SRI-NIC.ARPA>
To:        action@SRI-NIC.ARPA
Cc:        nic@SRI-NIC.ARPA
Subject:   [The Mailer Daemon <Mailer@SRI-NIC.ARPA>: Message of 13-Jan-88 15:48:24]
Action folks,

Hmmm, I noticed that the message indicates that it could not mail to
TCP-IP@SRI-NIC.ARPA. Can someone please investigate. This is not my
area of expertise, so I have no idea what could have gone wrong.

Nan
                ---------------

Date: Wed, 13 Jan 88 15:48:35 PST
From: The Mailer Daemon <Mailer@SRI-NIC.ARPA>
To: NIC@SRI-NIC.ARPA
Subject: Message of 13-Jan-88 15:48:24

Message failed for the following:
tcp-ip@SRI-NIC.ARPA: No such directory name
	    ------------
Date: Wed, 13 Jan 88 15:48:24 PST
From: DDN Reference <NIC@SRI-NIC.ARPA>
Subject: Annonuncement of latest GOSIP profile
To: tcp-ip@SRI-NIC.ARPA, ietf-interest@GATEWAY.MITRE.ORG,
    internics@SRI-NIC.ARPA, iso@NRTC.NORTHROP.COM, isode@NRTC.NORTHROP.COM
cc: nic@SRI-NIC.ARPA, mulvenna@ICST-ECF.ARPA, ebel@DCA-EMS.ARPA
Message-ID: <12366378943.34.NIC@SRI-NIC.ARPA>

Dear Network Colleagues,

We are sending the following announcement to you because many of you 
will be very interested in reading the documents mentioned, if you have
not already done so.

Elizabeth Feinler,
DDN Network Information Center

---------------------------------------------------------------------

A Federal Information Processing Standard (FIPS) has been issued by the
National Bureau of Standards (NBS) for GOSIP in the Federal Register, 
V52, No. 208, Oct. 28, 1987.  [See below for obtaining 
documents/files.]

This FIPS proposes a Federal Information Processing Standard for a 
Government Open Systems Interconnection Profile (GOSIP), and, in 
essence, spells out the policy of the Federal government including the 
DoD transition from TCP/IP to ISO international protocols.

GOSIP is to be used by Federal government agencies when acquiring 
computer network products and services and communications systems or 
services that provide equivalent functionality to the protocols defined
in the GOSIP documents.

Currently, GOSIP supports the Message Handling Systems  (MHS) and File 
Transfer, Access, and Management applications (FTAM).  GOSIP also 
supports interconnection of the following network technologies: CCITT 
Recommendation X.25; Carrier Sense Multiple Access with Collision 
Detection (IEEE 802.3): Token Bus (IEEE 802.4); and Token Ring (IEEE 
802.5).  Additional applications and network technologies will be added
to later versions of the GOSIP document or vendor products in which 
such protocols are embedded.

The proposed transition from TCP/IP to international protocols is 
expected to have considerable impact and has been given a great deal of
thought and review by the Government.  It may well have impact on your 
activities, making it particularly important that you are aware of the 
adopted policy and the GOSIP FIPS itself.

If you have questions or wish to respond, the details for how to do so 
are included in the Federal Register issue or in the NIC online file 
[PROTOCOLS:GOSIP-FEDREG.TXT].

Gerry Mulvenna (MULVENNA@ICST-ECF.ARPA) at NBS is available to answer 
questions you might have about the GOSIP FIPS, and is willing to 
forward formal responses received via electronic mail to the Director, 
ICST.

--------------------------------------------------------------------

      DOCUMENT PATHNAMES AT SRI-NIC.ARPA  [26.0.0.73 or 10.0.0.51]

1.  PROTOCOLS:GOSIP-FEDREG.TXT         (contains the Federal Register
                                        announcement of the FIPS)
2.  PROTOCOLS:GOSIP-V1.DOC             (contains GOSIP profile itself)
3.  PROTOCOLS:OSDIR-7-87.TXT           (contains OSD directive to
                                        proceed with policy within DoD)
4.  PROTOCOLS:GOSIP-FIPS-DRAFT.TXT     (contains the GOSIP FIPS draft)


All files are available from the DDN Network Information Center host,
SRI-NIC.ARPA, via FTP (using the anonymous login convention), KERMIT,
or SERVICE (the NIC's automatic electronic mail service).  Hardcopy is
available from NTIS and also from the DDN NIC.  (NIC copies may be
obtained for the cost of reproduction and handling.)  Call the NIC at
800-235-3155 or 415-859-3695 if you need further assistance obtaining
either the online or hardcopies.

-------
-------
-------

-------
-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jan 88 10:51:21 PST
From:      NIC Operations <ACTION@SRI-NIC.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   FIPS

Dear Network Colleagues,

We are sending the following announcement to you because many of you 
will be very interested in reading the documents mentioned, if you have
not already done so.

Elizabeth Feinler,
DDN Network Information Center

---------------------------------------------------------------------

A Federal Information Processing Standard (FIPS) has been issued by the
National Bureau of Standards (NBS) for GOSIP in the Federal Register, 
V52, No. 208, Oct. 28, 1987.  [See below for obtaining 
documents/files.]

This FIPS proposes a Federal Information Processing Standard for a 
Government Open Systems Interconnection Profile (GOSIP), and, in 
essence, spells out the policy of the Federal government including the 
DoD transition from TCP/IP to ISO international protocols.

GOSIP is to be used by Federal government agencies when acquiring 
computer network products and services and communications systems or 
services that provide equivalent functionality to the protocols defined
in the GOSIP documents.

Currently, GOSIP supports the Message Handling Systems  (MHS) and File 
Transfer, Access, and Management applications (FTAM).  GOSIP also 
supports interconnection of the following network technologies: CCITT 
Recommendation X.25; Carrier Sense Multiple Access with Collision 
Detection (IEEE 802.3): Token Bus (IEEE 802.4); and Token Ring (IEEE 
802.5).  Additional applications and network technologies will be added
to later versions of the GOSIP document or vendor products in which 
such protocols are embedded.

The proposed transition from TCP/IP to international protocols is 
expected to have considerable impact and has been given a great deal of
thought and review by the Government.  It may well have impact on your 
activities, making it particularly important that you are aware of the 
adopted policy and the GOSIP FIPS itself.

If you have questions or wish to respond, the details for how to do so 
are included in the Federal Register issue or in the NIC online file 
[PROTOCOLS:GOSIP-FEDREG.TXT].

Gerry Mulvenna (MULVENNA@ICST-ECF.ARPA) at NBS is available to answer 
questions you might have about the GOSIP FIPS, and is willing to 
forward formal responses received via electronic mail to the Director, 
ICST.

--------------------------------------------------------------------

      DOCUMENT PATHNAMES AT SRI-NIC.ARPA  [26.0.0.73 or 10.0.0.51]

1.  PROTOCOLS:GOSIP-FEDREG.TXT         (contains the Federal Register
                                        announcement of the FIPS)
2.  PROTOCOLS:GOSIP-V1.DOC             (contains GOSIP profile itself)
3.  PROTOCOLS:OSDIR-7-87.TXT           (contains OSD directive to
                                        proceed with policy within DoD)
4.  PROTOCOLS:GOSIP-FIPS-DRAFT.TXT     (contains the GOSIP FIPS draft)


All files are available from the DDN Network Information Center host,
SRI-NIC.ARPA, via FTP (using the anonymous login convention), KERMIT,
or SERVICE (the NIC's automatic electronic mail service).  Hardcopy is
available from NTIS and also from the DDN NIC.  (NIC copies may be
obtained for the cost of reproduction and handling.)  Call the NIC at
800-235-3155 or 415-859-3695 if you need further assistance obtaining
either the online or hardcopies.

-------
-------
-------
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 88 03:17:21 GMT
From:      mtune!petsd!pedsga!tsdiag!dennisb@rutgers.edu
To:        tcp-ip@sri-nic.arpa
Subject:   Mischa Schwartz - Protocols and Analysis
Someone out there was looking for 

Telecommunication Networks: Protocols, Modeling and Analysis
by Mischa Schwartz - ISBN 0-201-16423-X.

I have seen it in most B.Dalton bookstores in the NJ and NYC area. With the
ISBN number, any book store can order it.

Spose
Dennis
-- 
Dennis Lee Black                                 Concurrent Computer Corp
                                                 Cust Serv, Data Comm Sup
                                                 40 Pine Street
                                                 Neptune, New Jersey 07756
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 88 03:40:00 GMT
From:      BEAME@MCMASTER.BITNET
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Terminal servers on VMS Vaxen


Here at McMaster University, we have 2 780s, 1 785 and 1 8600 each equipted
with an IVECS card. We also have several CS/100s connected to other services.

Most of our 8600 access is through Ethernet with our own PC based terminal
emulator.

Here is a small list of problems/requirements of the IVECS cards.

1. A UNIBUS. Newer Vaxen don't have UNIBUSes.

2. Each IVECS card can emulate up to 6 DMF-32s and also takes up one CSR and
   vector for each emulated DMF. We had problems finding room when we added
   the IVECS card to the 8600 which already had lots of RS232 DMZ access.

3. You require a NCS/150 or NCS/150 AT to download the software to the
   cards and do any network management.

4. You can only do TELNET or RLOGIN so file transfer must be accomplished
   via serial protocols like Kermit. (We use Kermit on our PCs).

5. Currently, hitting Control-S with-out a Control-Q may lose data.

I quess I should give some good points too.

1. We have very little problem with the cards.

2. The Vax is off-loaded of all the TELNET TCP/IP processing.

    - Carl Beame
      BEAME@MCMASTER.BITNET

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 88 10:06:00 CST
From:      "Rick Watson" <ccaw001@utadnx.cc.utexas.edu>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   ether packet type 90-00
If I send a properly formatted packet of type 90-00 to DEC ethernet
controllers, DEUNA, DEQNA, DELUA, etc, the packet will be forwarded,
according to the manual, by the controller, to wherever you set in
the forwarding address field.  Does anyone know for sure if in the case
of VMS, Ultrix and BSD 4.3 if it is always the case that the packet
is forwarded by the controller and not the port driver?  

The reason I ask is that I seem to get different timing and response
results when I am "pinging" interfaces owned by Ultrix and VMS.

The "Loop Message Format" is described in the DELUA manual, among others.

Rick Watson
University of Texas Computation Center
 arpa:   ccaw001@utadnx.cc.utexas.edu
 uucp:   ...seismo!ut-sally!ut-emx!rick
 bitnet: ccaw001@utadnx
 span:   utspan::ccaw001
 phone:  512/471-8220 471-3241

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 88 07:05:51 GMT
From:      dag@hub.ucsb.edu (Darren Daggit)
To:        comp.protocols.tcp-ip
Subject:   Re: routing problems?  Core gateways?

In article <4481@sdcsvax.UCSD.EDU> brian@sdcsvax.UCSD.EDU (Brian Kantor) writes:
>I can't ping SEISMO.CSS.GOV from our host 'SDCSVAX.UCSD.EDU' at
>26.5.0.3.  I can ping SEISMO quite nicely from our neighbor on the same
>IMP (NOSC.MIL at 26.0.0.3).  We are both using the same default gateway
>at 26.2.0.73, which seems to be the way the packets are going.
>
>SEISMO isn't an isolated case - I can't ping any of the following hosts
>from SDCSVAX, but I can from NOSC:
>
>	uxe.cso.uiuc.edu	128.174.5.54
>	mcc.com			10.3.0.62
>	ius2.cs.cmu.edu		128.2.254.176
>	cs.utah.edu		10.0.0.4

Brian,

I can get to all of these hosts, and haven't seen any problems routing to them.
We are sending stuff through SDSC to the NSFNET backbone and on from there,
so things probably aren't touching the same piece of ethernet cable that you
are on, but the systems are reachable.

There have been reported problems that affect at least one of these systems
(cs.utah.edu).  The gateway psc.psc.edu has evidently been in trouble over 
the past few days, and things haven't been shuttled around the way they
should.

>There are others.  And there are hundreds of mail messages waiting in
>our queue because we can't get to their nameservers to get delivery 
>addresses.  (There ARE hosts on network 10 that I can ping, btw, such 
>as UCBVAX.)

I don't have my map of how the UCSD campus is connected to SDSC at hand, but
UCBVAX may not be a good example.  If you are routing things through the least
number of hops then stuff to UCBVAX probably isn't going to your default
gateway, the fastest route would be through the SDSC Proteon and out to the 
BARRNET (There are two R's in BARRNET aren't there?) backbone.  Is this right?
I have noticed that when the SDSC link into the NSFNET goes down we can still
get to the BARRNET, so the SDSC Proteon is routing things correctly in that
respect.

>I called the Milnet NOC, and they seemed to think that it's a core
>gateway problem and told me to call BBN.  BBN assures me that they were
>already working on the problem - seems that they see a problem with one
>of the gateways, but I don't know what that problem would be.

That is probably the PSC.PSC.EDU gateway, maybe it is effecting more than
one site.
 
  I hope this helps,
     --darren

>	Brian Kantor
>		UCSD Office of Academic Computing
>		Academic Network Operations Group  
>		UCSD B-028, La Jolla, CA 92093 USA
>		brian@sdcsvax.ucsd.edu	(619) 534-6865


-----------------------------------------------------------------------------
Darren Griffiths                      BITNET   -   DAG@SBITP
Systems Manager                       ARPA     -   DAG@NOBBS.UCSB.EDU
Physics Computer Services                          (128.111.8.50)
University of California              HEPNET   -   NOBBS::DAG  
Santa Barbara, CA  93106                           13326::DAG
(805)961-2602

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 88 15:42:39 GMT
From:      narten@purdue.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: Pseudo-Headers & Checksumming

Where can one find more recent information on VMTP than the SIGCOMM
paper?

Thomas

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 88 15:46:25 GMT
From:      miket@ccicpg.UUCP (Mike Tracy)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Adaptors for thinwire to thickwire

This probably won't help your immediate problem of connecting a
thin-lan to a normal ethernet cable, but I was reading about
a product called LattisNet.  It apparently is a twisted pair ethernet.
It uses a star type of topology and phone lines (unshielded twisted pairs)
to make a low cost ethernet.

Does anyone know if the system is any good ?

Michael D. Tracy	Computer Consoles Incorporated
(714)458-7282		9801 Muirlands Boulevard
			Irvine, CA 92718
{allegra!hplabs!felix,seismo!rlgvax}!ccicpg!miket

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 88 16:06:00 GMT
From:      ccaw001@UTADNX.CC.UTEXAS.EDU ("Rick Watson")
To:        comp.protocols.tcp-ip
Subject:   ether packet type 90-00

If I send a properly formatted packet of type 90-00 to DEC ethernet
controllers, DEUNA, DEQNA, DELUA, etc, the packet will be forwarded,
according to the manual, by the controller, to wherever you set in
the forwarding address field.  Does anyone know for sure if in the case
of VMS, Ultrix and BSD 4.3 if it is always the case that the packet
is forwarded by the controller and not the port driver?  

The reason I ask is that I seem to get different timing and response
results when I am "pinging" interfaces owned by Ultrix and VMS.

The "Loop Message Format" is described in the DELUA manual, among others.

Rick Watson
University of Texas Computation Center
 arpa:   ccaw001@utadnx.cc.utexas.edu
 uucp:   ...seismo!ut-sally!ut-emx!rick
 bitnet: ccaw001@utadnx
 span:   utspan::ccaw001
 phone:  512/471-8220 471-3241

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 88 16:28:57 GMT
From:      mminnich@UDEL.EDU (Mike Minnich)
To:        comp.protocols.tcp-ip
Subject:   Re: bootp/rarp

> I'm not sure if 4.2 really accepted
> 0.0.0.0 as a broadcast address, or only net.0, and I no longer have
> virgin 4.2 sources around to check it.  

Robert,

Last I tried using 0.0.0.0 as a BOOTP broadcast address in a 4.2
environment, most if not all of our  Unix UDP servers went belly-up,
into some kind of tight loop.  Since at the time I was interested in
making BOOTP work, I decided to use a hard-wired (non-broadcast) IP
address and wait for 4.3 to resolve the broadcast problem.

Hope this helps.  

mike

PS - I didn't try net.0, but I would strongly suspect that it would work.

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 88 16:30:31 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Pseudo-Headers & Checksumming

Thomas,

"Real soon now" Dave Cheriton will submit an RFC on VMTP [we hope].

    Bob Braden
    

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 88 17:37:10 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: gated/RIP info request

David S. Hayes writes:

> This looks like it's just the sort of thing one would want in a
> gateway Sun system.  Can anyone tell me where I can get the code
> for 'gated'?  I can FTP if necessary.
> 
> T i A,

As long as the "gateway Sun system" is connecting the same class of
network number with the same subnet mask you are probably right.
Sun systems can only act as gateways between networks of the same
class and subnet mask. Maybe a Sun could gateway between a
class C non-subnetted network and a class B network with
subnetmask == 255.255.255.0.

Phil Wood  (cpw@lanl.gov)

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 88 17:52:29 GMT
From:      brian@sdcsvax.UCSD.EDU (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: routing problems?  Core gateways?

Well, we're a little closer to the solution - at least we know what the
real problem is, although not the cause.

As I said, we're X.25 connected to our Milnet IMP.  That requires that
we have an X.25 virtual circuit for each separate host or gateway on the
Milnet that we want to talk to.  If we are the first person to send a
packet to that address, we open the VC in the range from 1 to 32.  If
the distant host is the first to send a packet to us, the IMP must open
the VC in the range 64-33.  If a VC is open already (no matter whether
the IMP or our interface opened it), it will be used.  If a VC is idle
for a configurable length of time (currently 60 seconds), the circuit
will be closed.

It seems that our problem is caused by the IMP not being able to open
VCs to us.  We CAN open outgoing VCs, but if the first packet from a
host or gateway on the Milnet is originated by them instead of us, then
the VC connection won't happen and things don't work.

Our problem with Seismo and other hosts is that they are on the far
side of gateways to the Arpanet, so that packets from them to us must
pass through a minimum of TWO gateways - one from them to Arpa, then one
of the Arpa-Milnet mailbridges - in order to get to us.  That
means that since the ICMP echo response (as well as all other traffic from
them to us) might well come to our host through a different mailbridge
than the one through which we send the packets to them, they might
indeed wind up seeing our packets but we won't see theirs, because the
X.25 VC from the IMP for that mailbridge couldn't be opened.

Clear as mud, eh?

We think it started after the IMP was reloaded after a power failure
last Saturday.  The NOC has somebody looking into it, they tell me.  In
the meantime, we're working around the problem by sending a single ping
packet to each of the seven mailbridges once every 45 seconds.  That's
sufficient to keep the X.25 virtual circuits active so people can get to
us.  It doesn't cure the problem, but it's a whole lot more livable this
way.

Deep gratitude to Mike Brescia of BBN who helped figure out what's going
on - or not going on, in this case.

	Brian Kantor	UCSD Office of Academic Computing
			Academic Network Operations Group  
			UCSD B-028, La Jolla, CA 92093 USA

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 88 17:54:19 GMT
From:      terrell@musky2.EDU (Roger Terrell)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   I need a good "manual" for tcp/ip


I am trying to set up TCP/IP on a VAX 11/780, but have not attempted
this sort of thing before.  Can anyone tell me of a good reference
for it?  The information that I need is not technical info on how
it works, etc. (although that wouldn't hurt), but I need information
on configuring it:  How to set up configuration files etc.  I am using
CMU TCP/IP.  If you don't know of a reference work, but would be willing
to give a few tips from your own experience, please e-mail me anyway.

Thanks,

Roger


-- 

Roger Terrell
Muskingum College			...cbosgd!musky2!terrell (UUCP)
New Concord, OH  43762

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 88 02:33:05 GMT
From:      slevy@UC.MSC.UMN.EDU (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Re: gated/RIP info request

> Sun systems can only act as gateways between networks of the same
> class and subnet mask.
 
> Phil Wood  (cpw@lanl.gov)

Are you sure about that?  We use SUN-3's as gateways between class-B
and class-C nets, and they seem to work just fine.  There -is- a restriction
that only one network can be subnetted (can gateway among subnets of
a single net, can gateway also onto class A/B/C non-subnetted nets, but cannot
gateway between subnets of two different nets).  This is true under SUN 3.3
at least.

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 88 03:13:34 GMT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help implementing IEN 116 nameserver


That's probably not the bug.  We use a perfectly normal sun kernel
with an IEN116 nameserver with the UB products.  The problem that
we have is that the UDP checksum code in the UB box is defective.
If you do not have udp checksumming turned on (you leave the checksum
field zero), the box doesn't realize that you are not computing checksums
and ignores you.  The quick solution is to turn on checksums on the
machine that is providing name service (on BSD UNIX poke _udpcksum to
1).

-Ron

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 88 03:19:57 GMT
From:      harvisr!sob@husc6.harvard.edu  (Scott Bradner)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: LattisNet
I've been testing the LattisNet product for the last 2 months.
It seems to work just fine.

There was some badmouthing of this product by a-large-computer-company,
saying that it did not run at 10MB. I have seen no reason to feel that
might be true.  I have tested a sun 3/60 connected via LattisNet to
Harvard's backbone & see no change in throughput or error counts when
compaired to a sun direct connected to the backbone.

Scott
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 88 04:05:33 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: gated/RIP info request

< in reference to Sun's as gateways >

I know for sure that they only have one place in memory for a subnet mask.
Maybe, if you do not subnet, things work.

I also know that we have to trash (logically, for the indefinite future)
the IPC boards from Sun.   We have a class B subnetted with 6 bits for net
and 10 for host.  I know that's a strange way to subnet.  But, hey, that's
the way DEC does it!  We also have a Class C subnetted with 3 bits for subnet
and 5 bits for host (now thats more like it).  It cuts down on the plethora
of broadcasts/arps/rarps/ICMP-Redirects/ICMP-Mask-replys from every host known
to man, when ONE Sun client boots!

Oh, oh.  I'm beginning to feel stressed!  Is this time for a flame on banner?
No, I must maintain some kind of decorum.  I'll just cut the remainder of this
message, and save it for later.  Actually, its pretty good ..., nah.

One does have a choice though, there are other's out there that make real
IP routers.

Phil Wood  cpw@lanl.gov

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 88 04:27:52 GMT
From:      garrett@udel.EDU (Joel Garrett)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Adaptors for thinwire to thickwire

In article <9177@ccicpg.UUCP> miket@ccicpg.UUCP (Mike Tracy) writes:
...
>thin-lan to a normal ethernet cable, but I was reading about
>a product called LattisNet.  It apparently is a twisted pair ethernet.
>It uses a star type of topology and phone lines (unshielded twisted pairs)
>to make a low cost ethernet.
>
>Does anyone know if the system is any good ?
>
Actually, Lattisnet allows you to run ethernet protocols over Fiber, Twisted
Pairs (shielded and unshielded).  We will be using the Shielded Twisted
Pair host modules to give us Ethernet over our equivalent to IBM's shielded
pairs cable in our new building.  The local var for Synoptics just came out
this past monday to perform a live test on a sample of our cabling and using
some of our ethernet equipment that will end up on the new building network.
All worked like a charm!

					Joel Garrett
					Center for Composite Materials
					University of Delaware

					garrett@udel.edu

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jan 88 11:47:01 CST
From:      Bryan McWilliams <OPRBBDM%TCSVM.BITNET@CUNYVM.CUNY.EDU>
To:        lattisnet <TCP-IP@SRI-NIC.ARPA>
Subject:   Re: Adaptors for thinwire to thickwire
1) I have two lattisnets installed; can't say enough goood about the
product.  It's easy to install, and vey reliable.
e
2) Thin wire to thick wire -- just use a reducer.
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jan 88 11:00:43 EST
From:      Ken Pogran <pogran@ccq.bbn.com>
To:        oconnor@sccgate.scc.com
Cc:        brian@sdcsvax.ucsd.edu, tcp-ip@sri-nic.arpa
Subject:   Re: routing problems?  Core gateways?
Mike,

I can confirm that PSN 7.0 has NOT been installed in the MILNET
yet, and there's no chance that that PSN was accidentally reloaded
with PSN 7.0 software (hosts on that node wouldn't be able to
communicate AT ALL with the rest of the MILNET if that had
happened!).

I'm not plugged in to the trouble-shooting process on the MILNET,
so I can't speculate on what Brian's problem might actually be.
I agree with you that the external symptoms do resemble the
ARPANET PSN 7 "stuck VC" problem, but I think the explanation has
to turn out to be quite different.

Regards,
 Ken

P.S.: With regard to the point that "only Sun users experienced
the 'hung VC' problem with PSN 7.0", it's fair to say that Sun's
was the only X.25 implementation that we FOUND on the ARPANET
that encountered that problem; it's possible that other
implementors could have made the same design decisions that Sun
made and could have had the problem, too.  But, as I said above,
that's a PSN 7 problem and certainly isn't what Brian's seeing on
the MILNET right now.
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 88 08:30:14 GMT
From:      melohn@SUN.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: gated/RIP info request

To clarify: Suns running version 3.3 or later of the Sun Operating
System can in fact route packets between class A, B, C, or any
combination thereof.  There is only ONE subnet mask possible in the
3.X series of releases, so if you are routing between two subnetted
networks of any class, the subnet masks must be the same. Routing
between a subnetted network and a non-subnetted net is never a
problem, and the entire restriction will dissappear in release 4.0,
which uses the 4.3 subnetting code.

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 88 12:34:00 GMT
From:      cball@ishmael.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Adaptors for thinwire to thickw


>/* Written 10:46 am  Jan 14, 1988 by miket@ccicpg.UUCP in ishmael:comp.protocols.tcp-ip */
>...  It[Latisnet] apparently is a twisted pair ethernet.
>It uses a star type of topology and phone lines (unshielded twisted pairs)
>to make a low cost ethernet.
>
>Does anyone know if the system is any good ?

I am also very interested from anyone with experience with this, or any
similar system.  It doesn't seem especially cheap at $600+/node[from Digital
Review, which gave a positive review], but the twisted pair star configuration
sounds worthwhile.  We frequently shuffle Sun nodes between offices; running
and re-running coax that can't be touched during office hours is a real pain.
Also, our experience is that thin ethernets with direct connections to
workstations are only marginally reliable.

Charles Ball
Intermetrics, Inc.
cball@inmet.com

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 88 15:20:35 GMT
From:      oconnor@SCCGATE.SCC.COM (Michael J. O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Re: routing problems?  Core gateways?

Brian,
	Your problem is similar to the one we experience with PSN 7.0
software.  In our case, the incoming VC would be created but only one
packet would be received.  If we pinged the origin of the VC, traffic
would begin flowing.  The problem was attributed to the new PSN code
expecting an X.25 RR after the first packet which our X.25 didn't provide.
This was a change from PSN 6 behavior.  We also set up a periodic pinging
of the mailbridges in order to keep mail flowing (the suggestion came from
BBN).
	What is dissimilar is the fact that we are an Arpanet node while
you are Milnet.  I didn't think PSN 7.0 was to be installed in the Milnet
just yet so unless someone slipped up reloading your PSN I don't know how
you could have the same problem as us.
	We are using Sun's X.25 in our gateway and were told that only Sun
users experienced the "hung VC" problem with PSN 7.0.
	I'd be interested to know whether or not you have the resources to
determine whether you get no incoming packets on the bad VCs or just one.

			Mike

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 88 16:00:43 GMT
From:      pogran@ccq.bbn.COM (Ken Pogran)
To:        comp.protocols.tcp-ip
Subject:   Re: routing problems?  Core gateways?

Mike,

I can confirm that PSN 7.0 has NOT been installed in the MILNET
yet, and there's no chance that that PSN was accidentally reloaded
with PSN 7.0 software (hosts on that node wouldn't be able to
communicate AT ALL with the rest of the MILNET if that had
happened!).

I'm not plugged in to the trouble-shooting process on the MILNET,
so I can't speculate on what Brian's problem might actually be.
I agree with you that the external symptoms do resemble the
ARPANET PSN 7 "stuck VC" problem, but I think the explanation has
to turn out to be quite different.

Regards,
 Ken

P.S.: With regard to the point that "only Sun users experienced
the 'hung VC' problem with PSN 7.0", it's fair to say that Sun's
was the only X.25 implementation that we FOUND on the ARPANET
that encountered that problem; it's possible that other
implementors could have made the same design decisions that Sun
made and could have had the problem, too.  But, as I said above,
that's a PSN 7 problem and certainly isn't what Brian's seeing on
the MILNET right now.

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 88 17:47:01 GMT
From:      OPRBBDM@TCSVM.BITNET (Bryan McWilliams)
To:        comp.protocols.tcp-ip
Subject:   Re: Adaptors for thinwire to thickwire

1) I have two lattisnets installed; can't say enough goood about the
product.  It's easy to install, and vey reliable.
e
2) Thin wire to thick wire -- just use a reducer.

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 88 18:04:26 GMT
From:      lekash@ORVILLE.NAS.NASA.GOV (John Lekashman)
To:        comp.protocols.tcp-ip
Subject:   Re: LattisNet

We've been using Lattisnet for about fifty machines, and it
seems to work pretty well.  When it was first installed, there
were some packet dropping problems, and they came out and
installed some sort of additional buffering.  Perhaps you
have an older version, or else the lower cost, less buffered
version.  Maybe when the machine count goes to a hundred,
we might have a different story to tell, (ie its time to
buffer more.)  However, single point to point transfers seem
to run as fast between machines on the Lattisnet as those
not on it.  This was tried only with sun 3/260's and SGI
irises, so far.
					john

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 88 19:24:19 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: bootp/rarp


I'm pretty sure that the original 4.2bsd only supported net.0.  I'm sure Mike 
Karel's will correct me if I'm wrong...  We were faced with the same problem 
when we implemented a BOOTP for PCIP (IBMPC).  My solution was to use 
255.255.255.255 as the defautl, as was specified by the RFC.  However I left a 
hook to extend it to net.0 if desired.  With PCIP, the IP address is normally 
stored on a disk and is loaded into memory at boot time.  All programs use the 
IP address in memory, not the disk.  Thus, my BOOTP program modified the IP 
address in memory after it found the address.  However, it figures out which 
broadcast address to use by seeing what is in memory when it starts, which is 
the IP address on the disk.  If the address is 0.0.0.0, it uses the default of 
255.255.255.255.  However, if it is stored as net.0 or net.subnet.0, it uses 
that as the address.  This is not per the spec, but I couldn't think of 
anything it would break.  Currently all of our PC's are configured to use 
128.2.0.0 since we still have plenty of 4.2 machines.  Of course if you are 
using a ROM and can't even store this much info (i.e. you don't have an EEPROM 
or battery backed up memory or...) then I don't think there is going to be 
much you can do.

Drew

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 88 19:45:46 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   lattisnet


We've been using Lattisnet for quite some time now (2 years?).  In fact, we 
were one of their initial beta testers.  We aren't using the thinwire stuff 
yet, but we are using their system over our IBM cabling system and over fiber. 
 We have a few hundred connections to multiple lattisnets and have never had a 
single hardware failure.  Our campus backbone is also a lattisnet box.

I can't say enough good things about the product.  We are very happy with it 
and we are using it in almost all future ethernet connections, as well as 
converting many old connections to it.  It's ease of use and maintenance are 
great since it gives us a star shaped ethernet in centralized wire closets.  
As far as cost goes, it is a bit more expensive.  However, we feel the 
additional cost is small compared to what we get in maintainability.  In the 
long run it may even be cheaper when we factor in technician time for 
installation and maintenance.

Drew

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 88 22:01:44 GMT
From:      tim@Data-IO.COM (The Daemon's Slave)
To:        comp.mail.misc,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   3COM mail <-> Unix Mail?


  Does anyone know of some hardware/software that will allow one to have
a 3com_mail to  Unix_mail gateway?   Even  a gateway  to VMS_mail  would
help.  Any suggestions or pointers  will be much appreciated as we  need
this as soon as possible.
-- 
<tim@Data-IO.COM>            ..uunet            Tim Rosmus (Sys Admin)
..sun!fluke----------\           |               Data I/O Corporation
..uw-beaver------------!tikal!pilchuck!tim      10525 Willows Road N.E.
..decvax!microsoft---/                        Redmond, WA  (206)881-6444

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 88 22:02:44 GMT
From:      lm@arizona.edu (Larry McVoy)
To:        comp.protocols.tcp-ip,comp.sources.wanted,comp.unix.questions
Subject:   Re: Application Programming Interface for FTP

In article <571@cgcha.cgch.UUCP> whna@cgch.UUCP (Heinz Naef) writes:
>Did anyone develop a (limited) FTP client, implemented as a C programming
>library, usable from within application programs to allow them to request
>standard FTP servers in the network to send or receive a file?
>
How about

/*
 * send a file via ftp
 *
 * Bugs	- no error checking/handling
 *	- password is in cleartext
 */
send(host, user, passwd, file)
	char* host;
	char* user;
	char* passwd;
	char* file;
{
	FILE* ftp;

	ftp = popen("ftp", "w");
	fprintf(ftp, "open %s\n", host);
	fprintf(ftp, "%s\n", user);
	fprintf(ftp, "%s\n", passwd);
	fprintf(ftp, "put %s\n", file);
	pclose(ftp);
}

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 88 00:44:43 GMT
From:      mike@devvax.JPL.NASA.GOV (Mike Tankenson)
To:        comp.protocols.tcp-ip
Subject:   Ethernet loopback interface problem

I have a question about the loopback interface found on our Sun
workstations.  Our problem is that when we do a netstat -a, a bunch of the
following connections are formed (ie. dozens):

Active connections (including servers)
Proto Recv-Q Send-Q  Local Address      Foreign Address    (state)
tcp        0      0  loopback.2703      loopback.sunrpc    TIME_WAIT
tcp        0      0  loopback.2702      loopback.sunrpc    TIME_WAIT
tcp        0      0  loopback.2701      loopback.sunrpc    TIME_WAIT
.
.
.

These go away after awhile, but we can't figure out why they should be
there in the first place.  Here is our entry for loopback:

127.0.0.1   loopback lb localhost loghost datehost

Here's some more funny stuff.  One another Sun we have an entry of:

127.0.0.1   loghost me loopback localhost

and there's no loopback connections created during a netstat -a!  What
could be the difference?

We are running Sun OS 3.3 on our 'problem' Sun, and 3.4 on our 'good' Sun.

Thanks in advance.

--mike
-- 
Mike Tankenson                Telos/Jet Propulsion Laboratory - NASA
4800 Oak Grove Drive, Pasadena, CA.  91109            (818) 354-1447
Uucp: seismo!cit-vax!jplpro!mike
Arpa: jplpro!mike@cit-vax.ARPA -or- mike@jplpro.JPL.NASA.GOV

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 88 22:53:55 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Ethernet loopback interface problem


Netstat will report the first name on the line in the host table
(actually, the "official name" as returned by gethostbyaddr() which
will be the first name after the numeric address. See 'man gethostent'
for details.) You can change it if you like by just reordering the
names and rebuilding the yellow pages (cd /etc/yp;make).

	-Barry Shein, Boston University

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jan 88 21:32:25 -0500
From:      Robert Hinden <hinden@PARK-STREET.BBN.COM>
To:        Thomas Narten <narten@PURDUE.EDU>
Cc:        Mills@LOUIE.UDEL.EDU, tcp-ip@SRI-NIC.ARPA, hinden@PARK-STREET.BBN.COM
Subject:   Re: Not a good day for EGP
Thomas,

In fact, both Purdue gateways (Butterfly and LSI-11) have been up with out
any restarts for a month or more.  See attached status reports.

Bob

	gstatus: 10/31/86 10:23
	For documentation, type "gstatus \?"
Beginning at Sun Jan 17 21:24:58 1988 (EST)
Source Host: 10.2.0.82 (Arpanet inoc.bbn.com)


Butterfly Gateway 91 PURD-BF 10.0.0.37 (Arpanet)	Sun Jan 17 21:25:05 1988 (EST)

Version 3.10 Gateway Number 32, Autonomous System 60

Last restart: 11/30 09:23

Interfaces:
	UP:	PURD-BF 10.0.0.37 (Arpanet)
	UP:	PURD-BF 128.210.2.1 (purdue-ccnet)
	UP:	PURD-BF 128.10.2.200 (Purdue-CS)
	UP:	PURD-BF 128.211.0.51 (purdue-cs-cyp)
	UP:	PURD-BF 192.5.91.60 (purdue-ecn1)


Gateway 16 PURDUE 10.2.0.37 (Arpanet)	Sun Jan 17 21:25:09 1988 (EST)

Version 1008.2

Last restart: 12/18 10:24
Features on: THR EGP 
RUP sequence number = 044630
Memory:  80784 bytes in use, 123368 bytes idle, 1680 bytes free

Interfaces:
	UP:    PURDUE 10.2.0.37 (Arpanet) (since 12/18 10:24)
		output q: 2, allocated: 48, data size: 1006

	UP:    PURDUE 192.5.48.6 (purdue-cs-net) (since 12/18 10:24)
		output q: 0, allocated: 31, data size: 1600


gstatus terminated at Sun Jan 17 21:25:09 1988 (EST)

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 1988 19:32-EST
From:      CERF@A.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   [The Mailer Daemon <Mailer@A.ISI.EDU>: Message of 9-Jan-88 ...]

Sigh - second attempt.

-v

	
Begin forwarded message
Date: Sat 9 Jan 88 10:48:39-EST
From: The Mailer Daemon <Mailer@A.ISI.EDU>
To: CERF@A.ISI.EDU
Subject: Message of 9-Jan-88 10:48:29

Message failed for the following:
tcp-ip@venera.isi.edu.#Internet: 550 <tcp-ip@venera.isi.edu>... User unknown
	    ------------
Date: 9 Jan 1988 10:48-EST
Sender: CERF@A.ISI.EDU
Subject: SIGCOMM
From: CERF@A.ISI.EDU
To: tcp-ip@VENERA.ISI.EDU
Message-ID: <[A.ISI.EDU] 9-Jan-88 10:48:27.CERF>

With apologies to those of you who are not SIGCOMM members (you
should be!!), I am using this distribution list to clarify a
statement I made in the most recent Computer Communications Review
(the quarterly publication of ACM/SIGCOMM).

In that issue, I described a debate in which it was proposed, I
thought, to drop "conferences with papers" from the ACM/SIGCOMM
activities and to concentrate on focused workshops. In fact, I
misunderstood Dave Clark's suggestion. He was merely pointing out
that we should have only one such "paperful" conference sponsored
by SIGCOMM - other activities ought to be workshop in format.

Jose Garcia-Luna from SRI International also pointed out his objections
to dropping all conference activity from SIGCOMM - and hastened to
remind me that we have such a conference scheduled in October 88
(SIGCOMM 88 at Stanford University).

So, having been "reset" by two people whose opinions I certainly
respect, I intend to pursue the single, high-quality SIGCOMM
conference approach and to retain Datacomm in its workshop form.

Now, if you'll excuse me, I have go go charter a boat in Bimini...

Vint
-------

          --------------------
End forwarded message
		
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 88 14:48:28 GMT
From:      sadler@shorty.UUCP
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   TCP/IP implementation over AT&T's STARLAN

The University of Wisconsin - Madison has recently recieved a few
3b1s through AT&T's University Grant Program.  While we are glad
to have also been given a bunch of Ethernet cards with Wollingong
TCP/IP, we didn't get as many cards as machines.  We recieved 
enough Starlan cards to make up the ballance, though.  This leads
up to my question.

Has anyone implemented TCP/TP on Starlan?  I have been told by a
couple of friends that they had seen this at a USENIX a few years
ago, but they were not sure who had done it.  

Does anyone know about this implementation of TCP/IP?  If noone does, I
probably will end up doing this adaptation of the Wollingong software.

With that second part in mind, does anyone know anything about the starlan
driver and the Ethernet driver for the 3b1 computer?


All help is greatly appreciated.


Jonathan Sadler
Computing Systems Labratory
Computer Science Department
University of Wisconsin - Madison

+-------------------+-------------------+-------------------------------------+ !       Home        !       Work        !             On the Nets             !
+-------------------+-------------------+-------------------------------------+ ! 1402 Regent #330  ! 1210 W. Dayton    !Internet: sadler@{cs.wisc.edu        !
! Madison, WI 53711 ! Madison, WI 53706 !          csd4.milw.wisc.edu}        ! ! (608) 257-7549    ! (608) 262-2389    !UUCP:	   sadler@uwvax.UUCP          !
+-------------------+-------------------+-------------------------------------+

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 1988 19:53-EST
From:      CERF@A.ISI.EDU
To:        Stevens@A.ISI.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Pseudo-Headers & Checksumming
Jim,

I am going through a bunch of messages serially so I haven't yet
seen any responses to your checksum query (if any). 

The pseudo-header was an attempt to fashion a true end/end checksum
at the TCP level which included everything necessary at the TCP level
to be sure you were getting a valid packet from the putative origin.

We considered replicating information from the IP header in the TCP
header as a way of making the TCP header easier to checksum, but
the header was already so big, we decided to try the pseudo-header
approach instead. 

It's possible that we just went too far on the "end/end" road and
could have left some of the information covered in the TCP checksum
out (that is, left it to IP level), but at the time, there was
great concern that the IP level would only be checked host-gateway,
gateway-gateway and gateway-host, not really end/end. So many times
we found problems with lower level subsystems by doing end/end checking
that we allowed ourselves the "awkward" luxury of the TCP pseudo-header.

I seem to recall a recent exchange on TCP-IP in which the TCP level
checksum proved very helpful in protecting against some LAN problems
arising at the IP level, but that only underscores the value of
end/end, not necessarily making an argument for the pseudo-header
we chose for TCP. Really, my recollection of the pseudo header was
to avoid making the TCP and IP headers redundant.

Vint Cerf
-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 88 16:50:41 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   A good day for timewarps

Folks,

Two of the four Internet timetellers normally synchronized to NBS radio time
have blown their springs. ISI (128.9.2.129) is ticking one year in the past
and NCAR (128.116.64.3) is ticking one day in the future. The remaining two,
UMD1 (128.8.10.1) and FORD1 (128.5.0.1), are presently in-chime with NBS;
however, access to FORD1 is frequently unstable due to network problems. Since
all NSFNET Backbone fuzzballs except U Maryland are synchronized to NCAR,
these tockers will also be ticking one day in the future.

At ISI the system startup file must be updated to the present year.
Apparently, probably due to known hardware problems, the file was restored as
of last year. At NCAR the bugfix I left on the disk there must be installed.
Cornell was notified of the NCAR bug last week but so far has not installed
the fix. I cannot do either of these things from here.

Dave

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 88 18:17:39 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Not a good day for EGP

Folks,

I am used to seeing some amount of trash in the core gateway routing tables,
but this morning it has gotten out of hand. At the end of this message is a
summary of the world according to the PURDUE LSI-11 core gateway. The first
part shows the neighbors which at one time were up, but are at the moment
offline, crashed or worse. The second part shows a mess of 68 apparently bogus
nets (!) presently sloshing over all Internet corespeakers at the moment. I
constructed this list from the full PURDUE routing table by deleting all named
networks and all unnamed networks in the range 128.x.x.x, 129.x.x.x and
192.x.x.x. Some of the remainder are marked unreachable, so are not included
in PURDUE routing updates sent to its neighbors. The others are in fact now
sloshing all over the Internet, overflowing routing tables and crashing at
least three EGPspeakers known to me.

From the hop counts and first-hop gateways listed, I suspect
counting-to-infinity is in progress on the MILNET side of the mailbridges, so
the bogons might eventually evaporate from the core tables. However, the three
EGPspeakers I watch are now crashing at intervals of a few hours, so the bogon
generator may be barking at those intervals or less. I strongly suspect a
malformed EGP update is being sent to a core gateway, which results not only
in broken tables, but a malformed EGP update being sent back to the remaining
EGP population. While my crashed EGPspeakers may deserve additional anti-bogon
insulation, the bogonspeakers should be found and fried ASAP.

Could it be that some list of gateways within an EGP update has overflowed a
count field or broken a parser?

Dave

Gateway 16 PURDUE 10.2.0.37 (Arpanet)	Sun Jan 17 09:52:25 1988 (EST)

Neighbors:
	DOWN:	golden-gateway.stanford.edu 10.1.0.11 (Arpanet) (EGP or indirect via EGP)
	DOWN:	gateway.rice.edu 10.4.0.62 (Arpanet) (EGP or indirect via EGP)
	DOWN:	a.cs.uiuc.edu 10.3.0.37 (Arpanet) (EGP or indirect via EGP)
	DOWN:	rita.acs.washington.edu 10.1.0.91 (Arpanet) (EGP or indirect via EGP)
	DOWN:	iu.ai.sri.com 10.5.0.2 (Arpanet) (EGP or indirect via EGP)
	DOWN:	ISTC 10.1.0.107 (Arpanet)  
	DOWN:	gold.bacs.indiana.edu 10.7.0.37 (Arpanet) (EGP or indirect via EGP)
	DOWN:	princeton.edu 10.7.0.96 (Arpanet) (EGP or indirect via EGP)
	DOWN:	oberon.usc.edu 10.0.0.121 (Arpanet) (EGP or indirect via EGP)
	DOWN:	ngp.utexas.edu 10.0.0.62 (Arpanet) (EGP or indirect via EGP)
	DOWN:	think.com 10.4.0.6 (Arpanet) (EGP or indirect via EGP)
	DOWN:	lad 10.6.0.62 (Arpanet) (EGP or indirect via EGP)
	DOWN:	YALE 10.2.0.9 (Arpanet) (EGP or indirect via EGP)
	DOWN:	10.7.0.62 (Arpanet) (EGP or indirect via EGP)
	DOWN:	192.5.48.18 (purdue-cs-net) (EGP or indirect via EGP)
	DOWN:	potomac.ads.com 10.5.0.25 (Arpanet) (EGP or indirect via EGP)
	DOWN:	xn.ll.mit.edu 10.2.0.10 (Arpanet) (EGP or indirect via EGP)
	DOWN:	columbia.edu 10.3.0.89 (Arpanet) (EGP or indirect via EGP)
	DOWN:	teknowledge-vaxc 10.5.0.11 (Arpanet) (EGP or indirect via EGP)
	DOWN:	utah-arpa-gw 10.3.0.4 (Arpanet) (EGP or indirect via EGP)
	DOWN:	VAN 10.5.0.63 (Arpanet) (EGP or indirect via EGP)
	DOWN:	TEST2 10.2.0.63 (Arpanet) (EGP or indirect via EGP)
	DOWN:	10.7.0.111 (Arpanet) (EGP or indirect via EGP)
	DOWN:	10.0.5.91 (Arpanet) (EGP or indirect via EGP)
	DOWN:	att 10.5.0.89 (Arpanet) (EGP or indirect via EGP)

Network Table:
	     193.252.102	4 hops (ext) via MILLBL 10.0.0.68 (Arpanet)
	     207.255.92		6 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     125		Unreachable
	     127		Unreachable
	     159.249		5 hops (ext) via MILBBN 10.5.0.5 (Arpanet)
	     159.183		5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     135.251		5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     207.250.89		5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     191.151		6 hops (ext) via MILISI 10.2.0.22 (Arpanet)
	      19		Unreachable
	     207.252.253	6 hops (ext) via MILISI 10.2.0.22 (Arpanet)
	     100		6 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     159.250		5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     143.151		4 hops (ext) via MILLBL 10.0.0.68 (Arpanet)
	     159.59		5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     207.250.115	5 hops (ext) via MILARPA 10.2.0.28 (Arpanet)
	     207.250.83		6 hops (ext) via MILSAC 10.2.0.80 (Arpanet)
	     207.252.247	4 hops via MILDCEC 10.7.0.20 (Arpanet)
	     159.255		4 hops (ext) via MILLBL 10.0.0.68 (Arpanet)
	     207.255.40		6 hops (ext) via MILSAC 10.2.0.80 (Arpanet)
	     207.252.98		5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     135.239		5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     159.164		5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     159.254		5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     207.255.253	6 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     207.255.167	6 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     193.255.57		6 hops (ext) via MILISI 10.2.0.22 (Arpanet)
	     126		Unreachable
	     159.167		5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     193.252.249	Unreachable
	     199.253.7		6 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     207.252.220	6 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	      84		1 hop (ext) via umn-rei-uc 10.2.0.94 (Arpanet)
	      42		Unreachable
	     159.89		6 hops (ext) via MILISI 10.2.0.22 (Arpanet)
	     207.255.234	6 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     207.253.52		4 hops (ext) via MILLBL 10.0.0.68 (Arpanet)
	     143.180		5 hops (ext) via MILBBN 10.5.0.5 (Arpanet)
	     193.252.205	5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     199.250.83		4 hops (ext) via MILLBL 10.0.0.68 (Arpanet)
	     159.235		4 hops via MILDCEC 10.7.0.20 (Arpanet)
	     143.252		5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     207.252.215	5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     207.253.88		5 hops (ext) via MILBBN 10.5.0.5 (Arpanet)
	     143.250		6 hops (ext) via MILISI 10.2.0.22 (Arpanet)
	     207.253.217	6 hops (ext) via MILISI 10.2.0.22 (Arpanet)
	     207.252.249	5 hops (ext) via MILBBN 10.5.0.5 (Arpanet)
	     159.180		6 hops (ext) via MILISI 10.2.0.22 (Arpanet)
	     207.252.242	5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     159.243		4 hops (ext) via MILLBL 10.0.0.68 (Arpanet)
	     131.237		4 hops (ext) via MILLBL 10.0.0.68 (Arpanet)
	     199.255.174	5 hops (ext) via MILARPA 10.2.0.28 (Arpanet)
	     159.149		6 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	      61		Unreachable
	     207.252.172	4 hops via MILDCEC 10.7.0.20 (Arpanet)
	      60		Unreachable
	     207.255.51		6 hops via MILDCEC 10.7.0.20 (Arpanet)
	     199.253.217	5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     199.253.202	5 hops (ext) via ISI 10.3.0.27 (Arpanet)
	     195.253.219	6 hops (ext) via MILISI 10.2.0.22 (Arpanet)
	     207.253.147	5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     207.253.89		5 hops (ext) via ISI 10.3.0.27 (Arpanet)
	     207.252.255	6 hops (ext) via MILISI 10.2.0.22 (Arpanet)
	     207.243.181	5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	      63		Unreachable
	     159.210		5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     159.62		5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet)
	     207.250.17		5 hops (ext) via MILARPA 10.2.0.28 (Arpanet)

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 88 21:10:31 GMT
From:      narten@PURDUE.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: Not a good day for EGP

>Neighbors:
>
>	DOWN:	192.5.48.18 (purdue-cs-net) (EGP or indirect via EGP)

The list of "down" neighbors may be a bit deceiving.  The machine
192.5.48.18 hasn't peered with Purdue LSI gateway since before
Christmas. I would suggest that the LSI gateway hasn't been rebooted
in over a month and that the entry is old, but...

>However, the three EGPspeakers I watch are now crashing at intervals
>of a few hours, so the bogon generator may be barking at those
>intervals or less.

Perhaps the definition of "crashed" needs to be examined. According to
my own logs, the Purdue gateway has flawlessly responded to ICMP
echoes every 15 minutes for the last 3 days. Although the gateway can
probably reboot and completely rebuild all its route tables in only a
few minutes, it seems unlikely that I would miss every one of the
crashes.

Thomas

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 88 21:17:54 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Agenda for Netman meeting on 21 Jan

The meeting set for this coming Thursday, Jan 21, at the Santa Clara Marriott
has the following agenda:

9:00  Presentation of Architecture, Amatzia Ben-Artzi
10:30 Presentation of mapping from ISO to TCP/UDP, Marshall Rose
Noon  Lunch
1:30  Presentation of "Profile", Jim Robertson

Then it will open up to a general discussion of managed objects and plans
for implementation.  Lee LaBarre wil act as discussion leader.

If you are planning on attending and have not yet notified me, please do
so.  Either by email or by calling Advanced Computing Environments
at 408-996-2042.

Dan
-------

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 88 00:32:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   [The Mailer Daemon <Mailer@A.ISI.EDU>: Message of 9-Jan-88 ...]


Sigh - second attempt.

-v

	
Begin forwarded message
Date: Sat 9 Jan 88 10:48:39-EST
From: The Mailer Daemon <Mailer@A.ISI.EDU>
To: CERF@A.ISI.EDU
Subject: Message of 9-Jan-88 10:48:29

Message failed for the following:
tcp-ip@venera.isi.edu.#Internet: 550 <tcp-ip@venera.isi.edu>... User unknown
	    ------------
Date: 9 Jan 1988 10:48-EST
Sender: CERF@A.ISI.EDU
Subject: SIGCOMM
From: CERF@A.ISI.EDU
To: tcp-ip@VENERA.ISI.EDU
Message-ID: <[A.ISI.EDU] 9-Jan-88 10:48:27.CERF>

With apologies to those of you who are not SIGCOMM members (you
should be!!), I am using this distribution list to clarify a
statement I made in the most recent Computer Communications Review
(the quarterly publication of ACM/SIGCOMM).

In that issue, I described a debate in which it was proposed, I
thought, to drop "conferences with papers" from the ACM/SIGCOMM
activities and to concentrate on focused workshops. In fact, I
misunderstood Dave Clark's suggestion. He was merely pointing out
that we should have only one such "paperful" conference sponsored
by SIGCOMM - other activities ought to be workshop in format.

Jose Garcia-Luna from SRI International also pointed out his objections
to dropping all conference activity from SIGCOMM - and hastened to
remind me that we have such a conference scheduled in October 88
(SIGCOMM 88 at Stanford University).

So, having been "reset" by two people whose opinions I certainly
respect, I intend to pursue the single, high-quality SIGCOMM
conference approach and to retain Datacomm in its workshop form.

Now, if you'll excuse me, I have go go charter a boat in Bimini...

Vint
-------

          --------------------
End forwarded message
		

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 88 00:53:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Pseudo-Headers & Checksumming

Jim,

I am going through a bunch of messages serially so I haven't yet
seen any responses to your checksum query (if any). 

The pseudo-header was an attempt to fashion a true end/end checksum
at the TCP level which included everything necessary at the TCP level
to be sure you were getting a valid packet from the putative origin.

We considered replicating information from the IP header in the TCP
header as a way of making the TCP header easier to checksum, but
the header was already so big, we decided to try the pseudo-header
approach instead. 

It's possible that we just went too far on the "end/end" road and
could have left some of the information covered in the TCP checksum
out (that is, left it to IP level), but at the time, there was
great concern that the IP level would only be checked host-gateway,
gateway-gateway and gateway-host, not really end/end. So many times
we found problems with lower level subsystems by doing end/end checking
that we allowed ourselves the "awkward" luxury of the TCP pseudo-header.

I seem to recall a recent exchange on TCP-IP in which the TCP level
checksum proved very helpful in protecting against some LAN problems
arising at the IP level, but that only underscores the value of
end/end, not necessarily making an argument for the pseudo-header
we chose for TCP. Really, my recollection of the pseudo header was
to avoid making the TCP and IP headers redundant.

Vint Cerf

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 88 02:19:11 GMT
From:      mrose@gonzo.twg.COM (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Draft memo for Netman meeting on 21 Jan 88


     A copy of the draft memo which will be discussed at the January
     21st Netman meeting has been posted to the GWMON list.  If you are
     not on the list, but are planning to attend, please drop me a note
     and I will send you a copy of the draft.

     Comments on the draft will be solicited (and encouraged!) on
     Thursday's meeting.

/mtr

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 88 02:32:25 GMT
From:      hinden@PARK-STREET.BBN.COM (Robert Hinden)
To:        comp.protocols.tcp-ip
Subject:   Re: Not a good day for EGP

Thomas,

In fact, both Purdue gateways (Butterfly and LSI-11) have been up with out
any restarts for a month or more.  See attached status reports.

Bob

	gstatus: 10/31/86 10:23
	For documentation, type "gstatus \?"
Beginning at Sun Jan 17 21:24:58 1988 (EST)
Source Host: 10.2.0.82 (Arpanet inoc.bbn.com)


Butterfly Gateway 91 PURD-BF 10.0.0.37 (Arpanet)	Sun Jan 17 21:25:05 1988 (EST)

Version 3.10 Gateway Number 32, Autonomous System 60

Last restart: 11/30 09:23

Interfaces:
	UP:	PURD-BF 10.0.0.37 (Arpanet)
	UP:	PURD-BF 128.210.2.1 (purdue-ccnet)
	UP:	PURD-BF 128.10.2.200 (Purdue-CS)
	UP:	PURD-BF 128.211.0.51 (purdue-cs-cyp)
	UP:	PURD-BF 192.5.91.60 (purdue-ecn1)


Gateway 16 PURDUE 10.2.0.37 (Arpanet)	Sun Jan 17 21:25:09 1988 (EST)

Version 1008.2

Last restart: 12/18 10:24
Features on: THR EGP 
RUP sequence number = 044630
Memory:  80784 bytes in use, 123368 bytes idle, 1680 bytes free

Interfaces:
	UP:    PURDUE 10.2.0.37 (Arpanet) (since 12/18 10:24)
		output q: 2, allocated: 48, data size: 1006

	UP:    PURDUE 192.5.48.6 (purdue-cs-net) (since 12/18 10:24)
		output q: 0, allocated: 31, data size: 1600


gstatus terminated at Sun Jan 17 21:25:09 1988 (EST)

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 88 03:04:55 GMT
From:      narten@PURDUE.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: Not a good day for EGP

>In fact, both Purdue gateways (Butterfly and LSI-11) have been up with out
>any restarts for a month or more.  See attached status reports.

In that case, the extra bogus nets (or some other recent problem) may
be causing the EGP servers to "burp" periodically.

Three times in the last 4 days, the Butterfly EGP decided that
we (128.211.1.1) were no longer an EGP neighbor, and restarted the
neighbor aquisition protocol.  In each case, events happened suddenly
and without warning; no cease commands were received, and we had not
even declared the Butterfly down for lack of responses to hellos &
polls.  I am fairly certain that this had not happening even once in
the entire preceding month.

I can't speak for the LSI-11 gateway, because we aren't peering with
it anymore.

Thomas

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 88 13:10:46 GMT
From:      swb@TCGOULD.TN.CORNELL.EDU (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   Re: A good day for timewarps

I'd like to ask everyone **not** to use NCAR.NSF.NET (128.116.64.3) or
any of the other *.nsf.net fuzzballs as time servers.  Granted time
service doesn't take too many resources, the NCAR fuzzball is a
central node in NSFNET, with about 30-40 institutions on the other
side of the ethernet it is connected to and lots of traffic going
through it on its point-to-point links.  It is already so congested
that it spasms from time to time.  A few cycles here and there at this
point make a tremendous difference in the survivability of NSFNET.  So
PLEASE use one of the others to NTP-peer with.
						Scott

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 88 17:18:42 GMT
From:      asjoshi@phoenix.Princeton.EDU (Amit S. Joshi)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.sys.ibm.pc,rec.ham-radio.packet
Subject:   Turbo C port of the KA9Q TCP/IP

Hello,

I have received a number of requests for the Turbo C port of the KA9Q
TCP/IP code. I have been mailing it out but now I am swamped. I thought
that only a few people would be interested in the code when I made the
offer to mail out copies. I shall therefore post the stuff to the net.

I would like to warn everybody that the version I have ported is NOT the
Christmas release. I am not using it for a packet radio, in fact I am
only using things to the socket level and so I have no plans to port the
Christmas release either. Also since I am not using most of the features
I have not tested them extensively. I am reasonably certain everthing
works over the ethernet with the 3COM board (I have used that portion),
but the rest I know that it compiles - I have fixed all the problems
that cropped in the ethernet portion and fixed similar code in other
places similarly.

My apologies to those people who requested and had to wait and then get
this message. I'll probably post to comp.protocols.tcp-ip.ibmpc unless I
get messages to the contrary soon.

-- 
Amit Joshi	BITNET	|	Q3696@PUCC.BITNET
		USENET	| {seismo, rutgers}\!princeton\!phoenix\!asjoshi
"There's a pleasure in being mad... which none but madmen know!" - St.Dryden

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 88 17:40:58 GMT
From:      NIC@SRI-NIC.ARPA (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   ARPANET UPGRADE


The PSN 7.0 New End-to-End Deployment to the ARPANET
is now complete.  The ARPANET is permanently running the
New End-to-End protocol, with no cutback to the Old End-to-End
anticipated, except if emergency conditions should arise.  A 
message from Ken Pogran describing the recent corrective actions is 
"attached".

Minor problems are still being cleaned up, but none, we believe,
which seriously impact any users.  Should problems arise or
persist, however, please continue to send messages to
ARPAUPGRADE@BBN.COM, call the BBN Hotline at (800) 492-4992 or DCA 
at (703) 285-5445/5228.

We thank everybody for their past and continued cooperation
in this endeavor.

Ken Turkewitz (BBNCC), Russ Mundy (DCA), Annette Bauman (DCA)


------------------message from Ken Pogran---------------

Here's the latest on the trials and tribulations of the ARPANET
Beta Test of PSN 7 and the New End-to-End Protocol:

In a message entitled "Santa's PSN 7 status" that I sent on
23 December, I announced that BBN had found the solution to the
"stuck VC" problem afflicting Sun hosts connected to the ARPANET
with X.25, and that we had also determined that the "128 byte"
problem was a host problem.  Well, Santa turned out to be a
Grinch, because we were dead wrong on both counts.

However, both problems have now (cross your fingers!) been fixed,
along with a few others.  The problems (and their resolutions)
are as follows.

1.  "Stuck VCs." See my previous messages for a detailed
    description of the problem.  In essence, asymmetric traffic
    flows originating from an 1822-connected host and destined to
    an X.25-connected host could result in a "deadly embrace",
    with the destination host and the PSN each waiting for the
    other to do something.  Although this case sounds obscure, it
    in fact corresponds to traffic flows from the MILNET (and
    perhaps some other networks) across 1822-connected gateways
    to the ARPANET and then to X.25-connected hosts -- a common
    situation.  This problem specifically afflicted Sun hosts,
    due to implementation choices Sun made in their X.25 code.
    After much discussion, our designers were convinced
    that Suns's implementation choices were in fact reasonable (our
    apologies to Bill Melohn at Sun for our being hard over in
    the other direction at first) and that the PSN's behavior
    needed to change to more closely resemble that under the Old
    End-to-End protocol (which obviously did not result in a
    deadly embrace).

    Accomplishing the desired change in behavior in the PSN
    turned out to be a lot more complex than we thought; we went
    through several iterations of "fixes" each of which we
    thought would do it but each of which turned out to be
    incomplete in handling some obscure case or other and was
    therefore incorrect.  (The 1822-X.25 interoperability module
    in the PSN is, in effect, a level 3 protocol converter
    tightly integrated into the End-to-End Protocol machinery,
    and it has all the complexity that protocol converters
    typically have.  The ultimate "fix" involves a design change
    rather than a simple coding fix; the design issues are
    probably worth an RFC at some point.) Last weekend we bit the
    bullet and designed and coded a much more complex change,
    which was tested at selected nodes early this week, with
    complete success.  The "stuck VC" dragon has, we believe,
    finally been slain.  Our apologies to everyone on the ARPANET
    with an X.25-connected Sun who's been waiting for a fix to
    this problem, and our thanks to Bill Melohn of Sun and Bob
    Enger of Contel for their patience, which we sorely tried.

2.  The "128 byte" problem.  X.25 packets of length 128 or
    multiples thereof appeared to be "lost" under certain
    circumstances.  The circumstances under which such packets
    were "lost" were, again, communication FROM an 1822-connected
    host TO an X.25-connected host.  Upon looking at the line
    between a PSN and a Sun host with a datascope, we saw "pings"
    of such packets going into the Sun, with no response from the
    Sun, and concluded it was a Sun problem.  Sun looked more
    closely than we and noticed that the packet the PSN sent had
    the "M" bit set, indicating this was one packet of a
    multi-packet sequence, but the PSN never sent another packet.
    This was, in fact, another PSN 1822-X.25 interoperability bug
    which has now been found and fixed.

3.  The HDH problem affecting Yale and Rice.  There were several
    bugs in the PSN 7 HDH interface code that kept Yale and Rice
    off the air a good bit of the time since PSN 7 was deployed.
    These bugs, too, have now been found and fixed.
-------

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 88 21:46:27 GMT
From:      nowicki@SUN.COM (Bill Nowicki)
To:        comp.protocols.tcp-ip
Subject:   Subnet support in SunOS 3.3

Last week there were several incorrect messages to this list about the
IP subnet support in SunOS releases.  As developer of this software, I
would like to brave the flames and clear up the misconceptions.

All SunOS releases support any number of any combination of Class A, B,
or C internet addreses, and will route between them.  Release 3.3 and
beyond (3.5 is the current release) support any number of non-subnetted
networks (standard subnet masks), and any number of interfaces on a
subnetted IP network (a single non-standard mask).  3.3 was to support
sites like Berkeley and Stanford, that tend to have a single class A or
B network number, with routers connecting the various subnets together,
and connecting them to the outside world (e.g. Arpanet).  Suns can be
used for any of these routing functions. Some more esoteric
configurations with multiple (DIFFERENT) non-standard netmasks on the
same machine are supported in a release that is currently in Beta
test.  ALL releases since 3.3 handled (and never forwarded) all six
kinds of broadcast addresses.  As described in RFC950, subnets of all
zeros should not be used, and a single netmask should be used throughout
a single IP network number.

Some specific examples of supported configurations are given in the
release documentation; in general it is a good idea to read the manual
first before posting a message to a world-wide distribution list.

	-- Bill Nowicki
	   Sun Microsystems

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 88 21:49:06 GMT
From:      karn@FALINE.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Fun and Games with TCP/IP

I posted this note on the USENET amateur packet radio group last weekend,
and a few people suggested that this group might appreciate it also.

Phil

From: karn@faline.bellcore.com (Phil R. Karn)
Newsgroups: rec.ham-radio.packet
Subject: Amateur TCP/IP path contest
Message-ID: <1712@faline.bellcore.com>
Date: 15 Jan 88 22:29:27 GMT
Organization: Bell Communications Research

Now that TCP/IP is really starting to take off in the amateur world, I think
it would be fun to start a running contest. The goal is to see who can come
up with the most complex, ad-hoc Internet path involving one or more amateur
packet radio links.  This is inspired by Mike O'Dell's famous "worst wire"
contest. The only requirement is that the path must actually work!  At a
minimum, you must successfully complete a three-way TCP handshake and then
successfully close the connection.

To start things off, I'd like to describe an experiment we did last weekend.
As many of you know, Telenet has this nifty service called PC Pursuit. From
any Telenet access number, you may connect to a remote dialout modem in in
something like 6 metropolitan areas.  As long as you use it only during
evenings and weekends, it costs $25/month -- flat rate!  Several amateur
TCP/IP groups have begun using PC Pursuit to link their otherwise isolated
"islands", with excellent results.

Last weekend Al, WB0MPQ (another resident of Warren, NJ) dialed up a PC
Pursuit link to Brian, WB6RQN, in the Maryland suburbs of DC. While the link
was up, I had Bob, WA3PXX, telnet briefly to a Bellcore machine named
"sabre" in Navesink, NJ.  The path was as follows:

Node, location			Link/Subnetwork
----				---- ----------
wa3pxx.ampr (PC/XT)
				222.06 Mhz AX.25 link
duplex RF repeater
Gaithersburg, MD(?)
				223.66 Mhz AX.25 link
wb6rqn.ampr (PC/AT)
Germantown, MD
				SLIP on 1200 baud dialup phone line (C&P Tel)
Telenet dialer port
Washington, DC
				GTE Telenet X.25 network
Telenet TIP port
Rahway, NJ
				SLIP on 1200 baud dialup phone line (NJ Bell)
wb0mpq.ampr (PC/XT)
Warren, NJ
				147.525/430.05 Mhz full duplex AX.25 link
switch.ka9q.ampr (PX/XT)
Warren, NJ
				KA9Q shack Ethernet
sun.ka9q.ampr (Sun 3/75)
				SLIP on 9600 bps dialup phone line (NJ Bell)
Micom terminal switch
Piscataway, NJ
				T-1 leased line (portion) (NJ Bell)
Micom terminal switch
Morristown, NJ
				hardwired RS-232 line
doomsday.bellcore.com (Sun 2/170)
				Lab Ethernet
Ethernet repeater
				Machine room central Ethernet
DEC Lan Bridge
				Building backbone Ethernet
Ethernet repeater
				Building "core" Ethernet
Vitalink Translan
				T-1 leased line (portion) (NJ Bell)
Vitalink Translan
Piscataway, NJ
				T-1 leased line (portion) (NJ Bell)
Vitalink Translan
Navesink, NJ
				building backbone Ethernet
DEC Lan Bridge
				Building wing Ethernet
DEC Lan Bridge
				Lab Ethernet
sabre.bellcore.com (Vax 11/750?)

...and back.

This was a direct end-to-end connection; the TCPs on wa3pxx.ampr and
sabre.bellcore.com spoke directly to each other.  Excluding the endpoints
themselves, the path their IP datagrams took included:

8 Ethernets
5 IP gateways (2 Suns, 3 PC's running KA9Q net.exe)
4 radio frequencies on 3 amateur bands
3 dialup phone links (2 @ 1200 baud, 1 @ 9600 baud)
3 T-1 digital leased lines with multiplexors
3 Vitalink Translan IIIs
3 DEC Translan 100s
2 Micom terminal switches
2 Ethernet repeaters
1 full duplex RF repeater
1 public X.25 network (Telenet)
1 partridge in a pear tree :-)

So...can anybody top this?  Who will be the first to include an amateur
satellite link in a TCP/IP path once AMSAT Phase 3-C is launched later this
year?

73, Phil

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 88 22:46:39 GMT
From:      chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   TN3270 RFC

Good afternoon!
I have heard rumblings for the past couple of weeks about an RFC detailing
negotiations and options for TN3270 specifically, but I was wondering if
there is any "hard" date when something like this will be around. Anyone
have the inside line on this?
		Thanks in advance,
					Chris Vandenberg
					ACC
					(chris@acc-sb-unix.arpa)

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 88 22:54:05 GMT
From:      philipp@GMUVAX2.GMU.EDU (Philip Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Where to find... supdup and tn3270 specs

Hi.

	I need to know whatever happened to the ad hoc tn3270
group -- did they ever produce and RFC and if so where can it
be FTPd from?  Also, is there a formal description of SUPDUP
that doesn't presume PDP-10 assembly language programming (or
indeed, NCP and 9 bit bytes)?  I've never hacked on a PDP-10
(I guess I've been unlucky :-), and I'm using TCP (aren't
we all?).

Thanks,

-Philip

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jan 88 07:13:40 EST
From:      Bruce Crabill <BRUCE%UMDD.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: TN3270 RFC
My understanding is that it was sent to Jon Postel back in November or
December and is currently sitting on his desk.

                                       Bruce
-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 88 03:59:39 GMT
From:      kopaz@rdlvax.RDL.COM (John 'Echo' Kopaz)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.sys.ibm.pc,comp.unix.questions
Subject:   Help!!!  token rings

prelude:	i know very little about nets and stuff 
		(enough to be dangerous)....

question:	what would be required (hw/sw) to connect a token ring of pc's 
		to an ethernet of suns, vaxen, and an alliant?  i want to be 
		able to rlogin from the pc's and/or submit jobs to mdqs.  i 
		would also like to to stick to tcp/ip as transfer/internet 
		protocols on the token ring (if i can...).

query:		can pc-nfs do this???  ( it would be nice to have all systems
		under nfs.....)

background:	we are running bsd4.3 on the vax, the current sun release, and 
		a bsd4.2 derivative  on the alliant ( all these under nfs ).  
		we are running desk view on the pc's ( also trying other 
		multitasking dos ).

plead:		where would i look to gain knowlage in this area?  
		texts, papers, etc...  ( taking the prelude into concideration )

respond:	via email please  ( i don't have time to read the news all the
		time.:-)

disclamer:	the spelling is mine.

signature:

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 88 04:07:48 GMT
From:      kopaz@rdlvax.RDL.COM (John 'Echo' Kopaz)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.sys.ibm.pc,comp.unix.questions
Subject:   Help!!!  token rings

( sorry about the multiple post. this one includes my .sig....)

prelude:	i know very little about nets and stuff 
		(enough to be dangerous)....

question:	what would be required (hw/sw) to connect a token ring of pc's 
		to an ethernet of suns, vaxen, and an alliant?  i want to be 
		able to rlogin from the pc's and/or submit jobs to mdqs.  i 
		would also like to to stick to tcp/ip as transfer/internet 
		protocols on the token ring (if i can...).

query:		can pc-nfs do this???  ( it would be nice to have all systems
		under nfs.....)

background:	we are running bsd4.3 on the vax, the current sun release, and 
		a bsd4.2 derivative  on the alliant ( all these under nfs ).  
		we are running desk view on the pc's ( also trying other 
		multitasking dos ).

plead:		where would i look to gain knowlage in this area?  
		texts, papers, etc...  ( taking the prelude into concideration )

respond:	via email please  ( i don't have time to read the news all the
		time.:-)

disclamer:	the spelling is mine.

signature:
	  ___                  ,,  __            ,,   _   ,
	 (   >      /             /  `     /         ' ) /
	  __/______/_  ____      /--   _. /_  __      /-<   _____   __.  __.
	 / /  (_) / /_/ / <_    (___, (__/ /_(_)     /   ) (_) /_)_(_/|_/  |_
	<_/                                                   /           (|
                        john a. kopaz [aka echo.]            '
            research scientist by association / test specimen
voice: 213-410-1244 -- fax: 213-216-5940 -- corporeal: rdl
arpa : kopaz@rdlvax.rdl.com                            5721 w. slauson ave.
uucp : ...!{psivax,csun,sdcrdcf,ttidca}!rdlvax!kopaz   culver city, ca 90320

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jan 88 13:53:06 -0500
From:      Andy Malis <malis@CC5.BBN.COM>
To:        "Barry D. Hassler" <wrtfac!hassler@LOGNET2.ARPA>
Cc:        malis@CC5.BBN.COM, tcp-ip@SRI-NIC.ARPA
Subject:   Re: IP class B and C to X.25 address translation
The following message didn't seem to make it out of my host when
I sent it the first time.  Since this is a topic that comes up
from time to time, I thought I would resend it.

Andy

------- Forwarded Message

To: "Barry D. Hassler" <wrtfac!hassler@LOGNET2.ARPA>
cc: malis,tcp-ip@sri-nic.arpa
Subject: Re: IP class B and C to X.25 address translation 
In-reply-to: Your message of Sun, 27 Dec 00 19:87:13 +0000.
             <7137.8712280332@wrtfac.cdc.com> 
Date: Mon, 28 Dec 87 11:44:33 -0500
From: Andy Malis <malis@cc5.bbn.com>

Barry asked the following:

        Has there been any standardization on the translation of
        Class B or C IP addresses to X.25 addresses? I am aware
        of the translation standard for Class A addresses, but
        have not seen any for B or C. 

Barry,

There is an informal standardization for Class B: the first two
octets of the IP address are the network number, the third octet
is treated identically to the second octet of Class A addresses,
and the fourth octet is treated identically to the fourth octet
of Class A addresses.  The third octet of Class A addresses is
dropped completely in Class B addresses.

There is absolutely no standardization for Class C, because there
are so few local network address bits to play with.  The host
network software support person for Class C nets must provide his
or her own mapping between the Class C addresses and X.25
addresses for that net.  For example, the five most significant
bits of the fourth octet of the Class C address could be the host
number, and the three least significant bits the PSN number.  It
is a compromise between the number of PSNs on the network and the
maximum number of hosts on a PSN.

Regards,
Andy

------- End of Forwarded Message

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 88 16:24:00 CST
From:      "CALVIN R. GEORGE" <george@eglin-vax.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.ARPA>
Subject:   POSIX
Pardon me for bugging this community but can someone point me to a
POSIX interest group or tell me where I can get a recent stab at the
POSIX standard?

I understand that NBS has accelerated their efforts and may be ahead of
IEEE in coming up with a standard.

Any help would be appreciated.

thanks,
Calvin George
------
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 88 12:13:40 GMT
From:      BRUCE@UMDD.BITNET (Bruce Crabill)
To:        comp.protocols.tcp-ip
Subject:   Re: TN3270 RFC

My understanding is that it was sent to Jon Postel back in November or
December and is currently sitting on his desk.

                                       Bruce

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jan 88 17:32:04 EST
From:      Doug Nelson <08071DEN%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        zgel05@apctrc.uucp, tcp-ip@sri-nic.arpa
Subject:   Re:  Spooky Routing by Sun TCP/IP
>We have a bunch of Suns configured on several seperate nets something like:
>    +-----------------+
>    | VM running KNET |
>    +-----------------+
>           |
>-----------+----------+----------+--------------- 193.9.200 Ethernet
>                      |          |
>                  +---+---+  +---+---+
>                  | Sun A |  | Sun B |
>                  +---+---+  +---+---+
>                      |          |
>           -----------+----------+--------- 193.9.202 Ethernet
>
>We have a problem where VM tries to talk to Sun B using Sun A as a router,
>but Sun B responds to VM using its 193.9.200 interface.  Since VM does not
>have the 193.9.200 interface for Sun B defined, it ignores the response.
>
>Questions: Is the Sun trying to be smart, recognizing it can get to the
>193.9.200 net in one less hop by using a different interface to respond on?
>If so, is there a way to turn off this smartness without unplugging the
>second interface?

Is the Sun responding to the KNET using its 193.9.202 address (it should
be)?  If so, it shouldn't matter that the response comes back on the
"wrong" interface.  What version of the KNET software are you running?
I have seen cases where it refuses to acknowledge other nodes that aren't
listed in its tables, and I suspect this is another symptom of that problem.
I also think that this may be fixed in the latest KNET release.

So, the answer may not be that the Sun is being too smart, but that the KNET
is being too dumb.

Doug Nelson
Michigan State University
Computer Laboratory
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 88 15:35:35 GMT
From:      larry@pdn.UUCP (Larry Swift)
To:        comp.protocols.tcp-ip
Subject:   multicast

Is there any way a socket can be specified as a multicast to (specifically)
two destinations rather than one or all (ie, broadcast)?

Larry Swift                     UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207          Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 88 16:52:50 GMT
From:      EWR@SEED.AMS.COM (Betsy Ramsey)
To:        comp.protocols.tcp-ip
Subject:   VAX/VMS TCP/IP and cisco AGS Gateway

I am still having problems using the VMS CMU TCP/IP software with our
cisco systems AGS-1E1D (DDN X.25) gateway, but I'd like to thank those
who have responded with suggestions.  (Please keep them coming!)

I'd also like to say that the support people at cisco have been very
responsive, even though the problem is almost certainly with the CMU
software, not their gateway (which is working fine with our DEC-20s on
the same Ethernet as the VAXs).
-------

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 88 18:53:06 GMT
From:      malis@CC5.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: IP class B and C to X.25 address translation

The following message didn't seem to make it out of my host when
I sent it the first time.  Since this is a topic that comes up
from time to time, I thought I would resend it.

Andy

------- Forwarded Message

To: "Barry D. Hassler" <wrtfac!hassler@LOGNET2.ARPA>
cc: malis,tcp-ip@sri-nic.arpa
Subject: Re: IP class B and C to X.25 address translation 
In-reply-to: Your message of Sun, 27 Dec 00 19:87:13 +0000.
             <7137.8712280332@wrtfac.cdc.com> 
Date: Mon, 28 Dec 87 11:44:33 -0500
From: Andy Malis <malis@cc5.bbn.com>

Barry asked the following:

        Has there been any standardization on the translation of
        Class B or C IP addresses to X.25 addresses? I am aware
        of the translation standard for Class A addresses, but
        have not seen any for B or C. 

Barry,

There is an informal standardization for Class B: the first two
octets of the IP address are the network number, the third octet
is treated identically to the second octet of Class A addresses,
and the fourth octet is treated identically to the fourth octet
of Class A addresses.  The third octet of Class A addresses is
dropped completely in Class B addresses.

There is absolutely no standardization for Class C, because there
are so few local network address bits to play with.  The host
network software support person for Class C nets must provide his
or her own mapping between the Class C addresses and X.25
addresses for that net.  For example, the five most significant
bits of the fourth octet of the Class C address could be the host
number, and the three least significant bits the PSN number.  It
is a compromise between the number of PSNs on the network and the
maximum number of hosts on a PSN.

Regards,
Andy

------- End of Forwarded Message

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 88 20:59:14 GMT
From:      german@UXC.CSO.UIUC.EDU (Gregory German)
To:        comp.protocols.tcp-ip
Subject:   Help!!!  token rings


I am currently un-aware of any PC NFS products that would work with the
4Mbs Token Ring.  If there is such a product please let me know.

I a currently using the IBM TCP/IP for the PC to TELNET, FTP, etc to
from other TCP/IP machines on our network.  The IBM software includes
an IP gateway between Token Ring, IBM PC Network (new cards) and ethernet.

The IBM software is part of Program Number 5798-FAL.  It has a fair number of
TCP/IP based programs which I will not detail here.  The TELNET emulates an
h19u ascii terminal or uses tn3270 if talking to a VM host.  TFTP and FTP
are available, though there is no server mode for FTP.  There are also 
several commands to deal with mail from the PC that I have not played with,
but they seem based on the Rand Mail Handler as far as the user interface
is concerned and use SMTP to POP server.

Though I haven't tried it you could probably also gateway with a Proteon
p4200 with both 4Mbs token ring and ethernet.

I belive FTP has suport for TCP/IP on the token ring, though I am uncertain
what they recomend at the gateway between token ring and ethernet.

Hope this helps some,
         Greg German (german@uxc.CSO.UIUC.EDU) (217-333-8293)
US Mail: Univ of Illinois, CSO, 1304 W Springfield Ave, Urbana, IL  61801
Office:  181 Digital Computer Lab.

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 88 21:25:42 GMT
From:      MRC@PANDA.PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP class B and C to X.25 address translation

Andy -

     For the record, PANDA and BBN TOPS-20's implement class C
PSN addresses as being in old ARPANET 8-bit format; that is, the
low order 6 bits is the PSN number and the high order 2 bits is
the host number.  This is relatively simple to change, though,
and to my knowledge no TOPS-20 system is on a class C PSN network.

     All TOPS-20's use 1822 instead of X.25 when talking to PSN's.

-- Mark --
-------

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 88 22:07:00 GMT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Where to find... supdup and tn3270 specs


    Date: Mon, 18 Jan 88 17:54:05 est
    From: philipp@gmuvax2.gmu.edu (Philip Prindeville)

    Hi.

	    I need to know whatever happened to the ad hoc tn3270
    group -- did they ever produce and RFC and if so where can it
    be FTPd from?  Also, is there a formal description of SUPDUP
    that doesn't presume PDP-10 assembly language programming (or
    indeed, NCP and 9 bit bytes)?  I've never hacked on a PDP-10
    (I guess I've been unlucky :-), and I'm using TCP (aren't
    we all?).

SUPDUP is RFC734.  It does not use 9-bit bytes for transmission; it uses
8 bit bytes and works today over TCP and CHAOS (and any other 8-bit
meduim).  (It took me all of two hours to convert the ITS SUPDUP server
and/or user to TCP from NCP.)  Many of the definitions look like they
deal with 12 or 36 bit quantities, but view them as logical fields
instead of parts of a 36 bit word.  I have written and maintained user
ends of SUPDUP for PDP-11s (many years ago) so things aren't really that
PDP-10/ITS specific.

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 88 22:10:22 GMT
From:      CASNER@VENERA.ISI.EDU (Stephen Casner)
To:        comp.protocols.tcp-ip
Subject:   Re:  A good day for timewarps

Folks,
	The system startup file for WWVB.ISI.EDU has been reentered to
bring it up to 1988, so it should once again be ticking the correct time.

								-- Steve
-------

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 88 22:24:00 GMT
From:      george@EGLIN-VAX.ARPA ("CALVIN R. GEORGE")
To:        comp.protocols.tcp-ip
Subject:   POSIX

Pardon me for bugging this community but can someone point me to a
POSIX interest group or tell me where I can get a recent stab at the
POSIX standard?

I understand that NBS has accelerated their efforts and may be ahead of
IEEE in coming up with a standard.

Any help would be appreciated.

thanks,
Calvin George
------

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 88 22:31:44 GMT
From:      MRC@PANDA.PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: Where to find... supdup and tn3270 specs

Philip Prindeville -

     I wrote the SUPDUP RFC (RFC 734) 10 years ago.  It doesn't
require any knowledge of PDP-10 assembly language programming,
although it was written in a day when PDP-10 conventions were
more widely understood.  Today, I would probably write it a bit
differently.

    However, it isn't that difficult to understand octal numbers
or even the n,,m format.  n,,m is a way of specifying a 36-bit
quantity, where n is the more significant 18 bits and m is the
least significant 18 bits.  PDP-10's are big-endian, so the number
120,,54 is equivalent to 00012000054 bit is easier to understand.
36-bit quantities are only used in the terminal code registers
sent at startup.  They're sent as 6-bit bytes (in our example, as
00 01 20 00 00 54) and on a byte-oriented machine I'd store them
in the least significant 6 bits of 6 consecutive 8-bit bytes.

     If you bothered to read the RFC, you'd realize that there
are no NCP dependencies at all; the connections are 8-bits.  A
9 and 12-bit character set for keyboard INPUT are possible for
operating systems which swallow them.  The rules for folding
such characters down are well defined in the RFC, and if a
client SUPDUP doesn't want to send such characters it doesn't
have to (all it has to do is not set the bit saying it has such
a keyboard).

     People who have never seen a line of PDP-10 assembly code
have read, understood, and implemented Unix code based on the
SUPDUP RFC.  Give it a try.

-- Mark --
-------

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 88 00:52:31 GMT
From:      dave@vdelta.UUCP (Dave Arnold)
To:        comp.protocols.tcp-ip,comp.lang.c
Subject:   C binding interfaces for TCP/IP

I am new to TCP/IP, so please excuse me if this is elementary, but...

Could someone please tell me what approach is taken for applications
programs to use a TCP/IP network?  More specifically, what does a C
program look like that is doing network I/O on a TCP/IP network?
Is the source code for the FTP client portable across all systems on
the ARPA Internet?
 
Are there efforts underway to standardize a C language interface for TCP/IP?
I have asked a particular vendor about this for VAX/VMS, and all he said was
"You get a QIO interface".  Great, so when we migrate to OSI, we will have
to rewrite all our software.  How does BSD sockets and streams fit into this?

We would like to create a "Virtual network runtime library", that would allow
application programs to interface to any kind of network.  Has such a model
already been suggested?  Does anybody think that this idea is not feasable?

Thanks in advance.

Dave Arnold
dave@arnold.UUCP

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jan 88 15:16 MDT
From:      <STGEORGE%UNMB.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Hop problem
Can anyone tell me the status of thw work being done to get around the
limitation of TCP/IP to a hop of 15 nodes? Thanks.
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 88 13:44:43 GMT
From:      dunigan@ORNL-MSR.ARPA (Tom Dunigan 576-2522)
To:        comp.protocols.tcp-ip
Subject:   seeking experiences with IBM 9370 tcp/ip


Our IBM types are planning on installing and evaluating an IBM 9370,
including an Ethernet tcp/ip connection.  We would be interested
in the experiences of others with the 9370 tcp/ip.  (Is the
software just the wiscnet stuff?)
   thanks
   Tom Dunigan
     dunigan@ornl-msr.arpa

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 88 15:21:00 GMT
From:      stanonik@NPRDC.ARPA (Ron Stanonik)
To:        comp.protocols.tcp-ip
Subject:   imp->psn upgrade, ecu override

Our imp (26) was recently upgraded to a psn.  Our interface
was an lhdh through an ecu to an ecu at the imp.  Our interface
is still an lhdh through an ecu, but the former ecu at the
imp was replaced by something that came with the psn.  What's
puzzling is that the folks doing the installation had us set
our ecu to override ("disable error overflow induced reset").
At one time it was very important not to override because we'd
lose rfnm's and without an imp reset our operating system
(4.1bsd, 4.2bsd?) would hit an rfnm limit and not open any
more network connections.  Since the imp-to-psn switch, we've
noticed lost rfnm's again (and coincidently our operating system,
4.3bsd, going comatose).  Maybe this will go away with the
recent 1822-to-x.25 fixes to the psn's, but we still wonder
if our ecu should be set to override?  Any ideas?

Thanks,

Ron Stanonik
stanonik@nprdc.arpa

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 88 15:56:36 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: Help!!!  token rings

We do indeed have products for token rings: One for the IBM TOKREUI
software interface (which is emulated by some other vendors), and one for
the Proteon P1340/1344 card in native mode.  As of this moment, the TOKREUI
version supports source-routing on bridged rings, the P1340 doesn't yet.
We don't include an NFS, but we do have Telnets (including TN3270), Rlogins,
SMTP mail (no POP), FTP client & server, TFTP client/server, LPR, REXEC,
RSH, RCP, Finger, etc.

Our software can use any IP router that has an interface for 802.5, including
P4200s, IBM software, or RTs with 4BSD and multiple interfaces.

James VanBokkelen
FTP Software Inc.

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 88 16:11:09 GMT
From:      jtn@potomac.ads.com (John T. Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: ARPANET UPGRADE

> The PSN 7.0 New End-to-End Deployment to the ARPANET
> is now complete.  The ARPANET is permanently running the
> New End-to-End protocol, with no cutback to the Old End-to-End
> anticipated, except if emergency conditions should arise.  A 
> message from Ken Pogran describing the recent corrective actions is 
> "attached".
> 
> Minor problems are still being cleaned up, but none, we believe,
> which seriously impact any users.
> 
> Ken Turkewitz (BBNCC), Russ Mundy (DCA), Annette Bauman (DCA)


Our site is seriously impacted.  Our machine (potomac.ads.com) is
unable to talk to the ARPAnet (except sun.com which is an X.25 site
like us, running the DDN software provided by Sun.  I take it from the
above message that BBN no longer feels the problem is with the 7.0 PSN
software but rather with the sites.





-- 


John T. Nelson			UUCP: sun!sundc!potomac!jtn
Advanced Decision Systems	Internet:  jtn@potomac.ads.com
1500 Wilson Blvd #512; Arlington, VA 22209-2401		(703) 243-1611

"Hi... My name is Hobbes.  I'm the product of a malicious 5-year old's
twisted and destructive imagination.  Would YOU like to be my friend?"

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 88 17:23:00 GMT
From:      WWB.TYM@OFFICE-1.ARPA (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Which gateway boxes can do this?

We might want to set up an IP net along the following lines.  Money will be 
tight at first, but maybe will grow (with usage).  For the configuration I am 
now envisioning, a gateway box with the following characteristics would seem to
be in order.  I would like to hear any information on which of the gateway 
gadgets on the market can do most or all of the below listed things in a 
reasonable fashion.  Opinions on the relative merits of vendor's 
implementations, support, etc., would also be of interest.

Description: This box should be an IP Gateway (Router) capable of interfacing 
to:

   (1) ARPANET or MILNET PSN using both 1822DH and DDN X.25 style interfaces.  
   [There is an issue of port availability which may require DH initially.  
   X.25 is ultimately desired.  Naturally we would not want to have to buy 
   different boxes at that point.]

   (2) Ethernet.  1 initially, possibly 2.

   (3) Another of its own kind at a very distant point, preferably via an 
   assortment of leased line types such as 9.6 voice grade modem, 50kb analog, 
   56kb DDS, whatever the demand eventually warrants.  It is probable that a 
   large proportion of the IP traffic will cross this wire!!

   (4) Public data network such as TYMNET, for the purpose of performing 
   function (3).  This is not indispensable but would be very nice to have, 
   e.g., have permanent VC through the PDN to connect the 2 (or possibly more) 
   geographically separate gateway boxes.  There is a chance that help with 
   certification can be arranged if someone thinks they have the code but 
   hasn't gotten to certification yet.  Of course, in return for help we would 
   expect concessions.

Beyond the link interface requirements, all the obvious protocol requirements 
for an IP gateway apply.  Support for DECNET would be nice to have.  The 
product as a whole must be supported by the vendor, i.e., we want somebody else
to fix bugs and deal with evolution of the protocol world.

I am in rather a hurry to get at least some generalities together for the end 
users.  I know who some of the potential vendors would be, but probably not 
all, and in some cases the descriptive info I have just isn't very clear.  Thus
I would be appreciative of any definite statements or educated guesses about 
who can actually deliver such a thing.  Proteon, cisco Systems, and probably 
Sun seem to be in the ballpark.  There are hints that Ford Aerospace and 
possibly Bridge may have something.  If there's anyone else I should talk to, 
let me know who and where.

Please reply directly.  I will summarize to net if requested.  Thanks in 
advance for all information and assistance.

Bill Barns
ARPA: WWB.TYM@OFFICE-1.ARPA

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 88 17:37:35 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Where to find... supdup and tn3270 specs

Some people think SUPDUP is a swell protocol.  Why doesn't one of them
take the time to write a reasonable protocol RFC on SUPDUP, without
assuming 36-bit machines.  Then the rest of the Internet world can
find out how wonderful SUPDUP is.

   Bob Braden

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jan 88 22:44:32 EST
From:      Nick Gimbrone <NJG%CORNELLA.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: seeking experiences with IBM 9370 tcp/ip
>Our IBM types are planning on installing and evaluating an IBM 9370,
>including an Ethernet tcp/ip connection.  We would be interested
>in the experiences of others with the 9370 tcp/ip.  (Is the
>software just the wiscnet stuff?)
The IBM TCP/IP for VM product (5798-FAL, or just FAL for short :-) has
its roots in the Wiscnet package.  BUT (a big but) the code has been
extensively worked on by IBM Yorktown.  The current FAL product is
faster, more stable, and in all around better than Wiscnet ever was.  I
would not make any negative assumptions based upon earlier experiences
with the Wiscnet code.  On the hardware side (the 9370 and its ethernet
controler) I'm afraid I cann't offer any words of wisdom.  For
discussions of FAL software (and related hardware issues) you might
want to join the IBMTCP-L list hosted at CUNYVM.CUNY.EDU (or
CUNYVM.BITNET).
  (I believe you subscribe by sending a one line mail file containing
   'SUB IBMTCP-L <your name>' to LISTSERV@CUNYVM.CUNY.EDU, but I may
   be wrong.)
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 88 20:12:53 GMT
From:      hrp@ishmael.CRAY.COM (Hal Peterson)
To:        comp.protocols.tcp-ip
Subject:   C binding interfaces for TCP/IP

There is a /usr/group technical committee working on a standard
Network Interface, probably for eventual inclusion in POSIX.  The
chairman of the Network Interface Technical Committee is Steve Albert,
reachable at ihnp4!research!ssa.  I don't know if this does you any
immediate good for VMS, but it may provide a model for your virtual
network runtime library.

Hal Peterson / Cray Research / 1345 Northland Dr. / Mendota Hts, MN  55120
hrp%hall.CRAY.COM@umn-rei-uc.ARPA	ihnp4!cray!hrp	    (612) 681-5884

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 88 21:02:01 GMT
From:      mdm@trwrb.UUCP (Michael D. Marcinkevicz)
To:        comp.protocols.tcp-ip
Subject:   Info on DECnet-TCP/IP gateway hardware & software

What hardware/software are you using for your DECnet-TCP/IP gateway?

We will soon be acquiring the DEC ULTRIX DECnet-TCP/IP gateway
software package.  Any information you have on your evaluation 
of the product or third party vendors for the MicroVax II or Sun Microsystems
machines would be greatly appreciated.  ALSO, any other third-party equipment
that performs DECnet-TCP/IP routing would be helpful.

At the end of the discussions, I'll distribute a summary of comments
received.

		Michael Marcinkevicz			(213) 812-2154
		TRW Space and Defense Sector, Communications services
		trwrb!mdm@trwind.TRW.COM		(ARPA)
		...{decvax,ihnp4,ucbvax}!trwrb!mdm	(UUCP)

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 88 21:02:15 GMT
From:      mdm@trwrb.UUCP (Michael D. Marcinkevicz)
To:        comp.protocols.tcp-ip
Subject:   Re: seeking experiences with IBM 9370 tcp/ip

We'll be installing ACCES/MVS on our 3090-400 and 3084QX to allow
us a TCP/IP interface for our IBM hosts and the rest of the net (LAN).

I'll post our evaluation when complete.

	Michael Marcinkevicz			(213) 812-2154
	TRW Space and Defense Sector, Communications services
	trwrb!mdm@trwind.TRW.COM		(ARPA)
	...{decvax,ihnp4,ucbvax}!trwrb!mdm	(UUCP)
	

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 88 21:11:27 GMT
From:      jsq@longway.UUCP (John S. Quarterman)
To:        comp.protocols.tcp-ip
Subject:   Re: POSIX

>Pardon me for bugging this community but can someone point me to a
>POSIX interest group or tell me where I can get a recent stab at the
>POSIX standard?

Yes:  std-unix@uunet.uu.net, requests to std-unix-request@uunet.uu.net;
also distributed as newsgroup comp.std.unix on USENET.  I'm the moderator.

There are various paper mailing lists and levels of participation in the
various committees.  I will send you in a separate message a copy of my
semi-monthly posting on that subject.  Most people on the TCP-IP list
are probably not interested.

>I understand that NBS has accelerated their efforts and may be ahead of
>IEEE in coming up with a standard.

Yes.  There will be a report on that in comp.std.unix in the next few days.

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 88 21:16:00 GMT
From:      STGEORGE@UNMB.BITNET
To:        comp.protocols.tcp-ip
Subject:   Hop problem

Can anyone tell me the status of thw work being done to get around the
limitation of TCP/IP to a hop of 15 nodes? Thanks.

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      21 January 1988 0640-PST (Thursday)
From:      stanonik@nprdc.arpa (Ron Stanonik)
To:        tcp-ip@sri-nic.arpa
Subject:   Re:  imp->psn upgrade, ecu override
Excuse my confusion, imp to psn is just a name change.  What
happened here was a "complete swap-out of the old C-30 IMP/PSN
which a new C-30 IMP/PSN in the new "standard configuration".

Still the question remains, why set the ecu to override?
The new c-30 should still respond to an error induced reset
from the ecu (rejnp frame?), right?

Thanks,

Ron
stanonik@nprdc.arpa
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 88 22:42:20 GMT
From:      dlnash@EMX.UTEXAS.EDU (Donald L. Nash)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM Token Ring <--> IP world


> The following article came through the TCP/IP discussion group yesterday.
> Enjoy,
> 
> DR

Thanks, Dan.  I think info-tcpip is gatewayed to comp.protocols.tcpip,
which I read.  I probably saw this and didn't notice it.  I'll have
to read c.p.tcpip more carefully.

Don

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 88 23:10:05 GMT
From:      carrs@TROUT.NOSC.MIL (Stephen M. Carr)
To:        comp.protocols.tcp-ip
Subject:   C-KERMIT For Honeywell DPS-6 & Tandem NonStop TXP

-------
Ladies/Gentlemen,
 
1.  Forgive me for bothering this forum for a query that is not 
inline with TCP/IP.  Under the circumstances, however, this 
target audience is likely to be able to help me more than any 
other forum I am aware of.
 
2.  We need to identify and procure a working version of Columbia 
University's C-KERMIT that will execute on a Honeywell DPS-6 
under the GCOS6 Mod 400 Version 3.1 operating system.  
 
3.  If we cannot locate a current executable copy of C-KERMIT, 
our lives become somewhat difficult, as we own no C compiler for 
the DPS-6, and the Navy procurement process may have us waiting 
until the millenia to legally obtain one.  
 
4.  Failing procurement of an executable copy, perhaps somebody 
at Columbia University would be kind enough to answer this 
question, "How can we obtain the source code for C-KERMIT that 
will execute on the Honeywell DPS-6?"
 
4.  Similarly, we have need to identify and procure a copy of C-
KERMIT which will execute on the TANDEM NonStop TXP.  Guess which 
two machines we wish to transfer files between in a nonnetworked 
direct asynchronous modem linked environment?
 
5.  Again, my apologies, but any help would be greatly 
appreciated, and will no doubt save you money as taxpayers.
 
                       Very Respectfully,
                           Steve Carr
                          LCDR, SC, USN
 
Navy Management Systems Support Office (Code 42A)
Naval Air Station
Norfolk, Virginia 23511-6694
 
MILNET:  carrs@trout.nosc.mil
MILNET:  navmasso42a@nardacva.arpa
(804) 445-2171, AUTOVON 565-2171
(804) 445-1595, AUTOVON 565-1595 (extension 36)
-------

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 01:31:22 GMT
From:      don@SRI-LEWIS.ARPA (Donald Holman)
To:        comp.protocols.tcp-ip
Subject:   Serial Line address assignment and user authenitcation.


To all,

This mobile host/circuit switched IP discussion seems to crop  up  every
six months or so.  At the risk of re-kindling this fire.  Here's another
perspective on this matter.

DISCLAIMERS

Since neither of us attended the "slip"  discussion  at  Monterey  East,
please correct us if there are any new developments.

This  is  probably  as much of an issue in network management as in link
layer protocols.  Please accept  our  apologies  if  we  posted  to  the
incorrect forum.

INTRODUCTION

Over  the  past  several  months,  there  have been numerous discussions
concerning PC-based IP primarily  tailored  for  academic  and  business
environments.  Unfortunately, the current serial line IP implementations
do not appear  to  be  entirely  suited  for  military  applications  --
specifically,  where a network must respond dynamically to architectural
changes.

The particular architecture which the past discussions have  focused  on
have  been in connecting mobile nodes to pre-specified and fixed network
ports.  Additionally the discussions have centered on the attachment  of
PC's  (e.g.  IBM  PC  class machines) running some variant of SLIP (Rick
Adams, KA9Q, etc..).

There appears to be a more general problem which we would  like  to  see
addressed;  that  of connecting hosts/PC's to a subnet via any available
network port on any PSN.  We envision the  host  would  have  sufficient
processing power to support more sophisticated link layer protocols than
just simple framing.  The discussion below focuses  on  the  ability  to
dial-up  a  PSN,  use  some  network service, disconnect because the PSN
failed, dial-up another PSN, and  gain  immediate  network  access.   Of
course,  the  requirement  is on the ability to gain access via any node
without manual intervention and without excessive bandwidth  consumption
due to routing table updates.

While there are protocols for acquiring a newly connected neighbor, they
do not appear to be entirely suited for large low speed  networks  where
hosts  are  not  statically  connected  to  the network but may randomly
appear at any network port.  What we mean by low speed is the use of  16
kbps  trunks,  and  2.4  kbps  host-to-subnet  links.  This is partially
governed by the requirement to keep telephone line costs low.  The other
is availability during times of conflict.

Ideally  the  situation  which  we  would like to have is to configure a
single host/PSN with the network configuration and be able  to  drop  in
new machines without knowing their addresses, a priori.

Fully  realizing  that  there are many issues at stake, we would like to
concentrate on a particular issue and system concept -- that  of  mobile
PC  nodes  using  dial-up  IP  to  any  one  of a set of ports available
throughout a fairly stable subnet.

The PC's will probably be replaced by high performance  workstations  in
the near future -- but the problem set remains the same. Similarly, this
discussion is not advocating the use of SLIP, X.25 or any  other  serial
line  protocol,  rather  we are attempting to define a systems model for
use in a dynamic network.

BACKGROUND

The environment which we envision using a serial  line  protocol  is  in
connecting  PC's  to  a relatively static backbone network consisting of
packet switches and dedicated nodes providing  resources  such  as  mail
queuing,  computing  services,  distributed databases, etc..  Since, for
our use, this application is in the military arena the line protocol for
connecting into the subnet should be self configuring, be highly robust,
and not cause instabilities within the subnet.


Additionally,  these  PC's will dial into the backbone using voice-grade
commercial/tactical (low bandwidth)  circuits.   Our  focus  is  on  the
problem  of  connecting  mobile PC's to this fairly static subnet.  (For
now we're not going to entertain  any  of  the  complexities  of  subnet
partitioning or self reconfiguration.)

PC's  should  be  able  to  dial  into  any available port at any PSN or
resource server and be able to immediately acquire  available  computing
resources.   The service provided by the subnet to the PC should include
virtual  connection  services  (e.g.  TCP)  and  not  just  message/mail
forwarding (UUCP, CSNET Phonenet)

Circuit  switched  IP  is a related matter but we'll assume for now that
the subnet is linked together using leased-lines and circuit switched IP
applies  only  on the PC to subnet data link.  Under this model the user
is aware of a set of phone numbers or network entry points for accessing
the network.

DEFICIENCIES OF CURRENT APPROACHES

Present  point-to-point  link  layer  implementations either assume that
there is a pre-specified host at the remote end or that some negotiation
will  occur  specifying  who  the remote host is and if the host has the
proper access privileges.  Another method, described by  Bill  Westfield
as  the  Gateway  model,  will  accept  packets  from any IP host and is
managed by sending the appropriate routing updates.  This method can  be
viewed as extending routing mechanisms to the mobile host.

The  problem  with most existing point-to-point links is reconfiguration
of interfaces to accept different source  and  destination  ends.   This
does  not  occur  dynamically and requires user intervention.  With most
point-to-point links one must first specify  a  source  and  destination
interface  address.   Unfortunately,  this  binding of names to physical
devices forces the network to be static in nature.  For example, current
SLIP  implementations,  BBN  PSN's,  and  commercially available gateway
serial interfaces all  require  addresses  to  be  assigned  before  the
interfaces  become active.  Most (if not all) X.25 links require a fixed
X.121 address.

Even if  the  host  operator  was  able  to  reconfigure  the  machine's
interface,  he/she  would  still  need  to  determine what its interface
address should be and what the address of the PSN port is.  For  dynamic
situations  it  would be difficult to manage and distribute addresses at
the host level.  This is particularly true  in  a  military  environment
during times of conflict when the network topology becomes very dynamic.

The  gateway  model  of  determining  remote  addresses and updating the
routing tables may be an answer for small nets.  However, when nets  are
large  and  many  PC's  dial into the network only to exit shortly after
(e.g. as in a tactical arena), the network  may  become  congested  with
routing updates.  The convergence of the routing protocols must be quick
to minimize instabilities.  In general, the ability to support arbitrary
hosts  using  the  gateway  model  is  gained  at  the  risk  of network
instability.  Resources distant from the  host  may  not  be  attainable
until  routing  information  propagates  to  the  server  providing  the
requested service.  With low speed trunking, the network may  do  little
else  than  to update routing tables, especially if the radius was large
and the frequency of host connection/disconnection was high.  (If anyone
has  performed  analytic  or  quantitative  analysis  of this situation,
pointers are greatly appreciated.)

A compromise between the two above methods is to  have  the  calling  PC
identify  itself  and  to  have the PSN port accept variable destination
ends within a given set of addresses.  However, the deficit we see  with
this  approach  is that addresses are still statically bound on the host
end.  Given this approach the PC would be unable to use an access  point
on  a different PSN without incurring routing updates.  Furthermore, the
set of addresses with access point would need to support may be large.

Our experience has been with BBN PSN's, cisco's, Sun  IR  and  DDN  X.25
products,  and  Rick Adam's SLIP.  These require binding of addresses to
interfaces.  If both ends of the interfaces  have  not  been  configured
with the proper addresses, the interfaces will not transport packets.

Current  discussions  have  focused on stable address spaces -- the PC's
have a fixed address, the subnet ports have  fixed  addresses,  and  the
routing updates constitute the transport of these pre-assigned addresses
and their state.  What would be nice is if  there  was  a  protocol  for
having the network assign addresses dynamically having the dial-up hosts
conform automatically to this address.  The idea of not binding  network
addresses  to  either  network  access  points  or to the hosts may have
applicability.

DYNAMIC ADDRESS ASSIGNMENT

A method which may be suitable for the  described  network  architecture
(static  low  speed  backbone  and roving dial-up PC's) but has not seen
much  discussion,  is  dynamic  address  assignment  rather  than  route
updating  or  fixed address assignment.  Under this method a the network
access point is given a pool of addresses which it can  freely  delegate
to  calling PC's and to the PSN ports.  These address pools are assigned
by the subnet administrator at the time of  system  generation  and  are
available  for  assignment.  The PC is required to abide by the assigned
address or risk  having  its  packets  dropped.   The  benefit  of  this
approach  is  that  no  routing  updates  need  occur and authentication
becomes manageable -- away from the  idea  of  authentication  based  on
addresses.   What  is proposed here is that an internet address is bound
to an interface after a calling PC is validated for access, and that the
address is re-used when the calling PC disconnects or the link fails.

This also requires the allocation of a pool of addresses large enough to
support  the  anticipated  number  of  dial-up  hosts.   This  could  be
supported   through   subnetting,   making  the  movement  of  PC  hosts
transparent to the network layer routing protocols.  This approach  will
help  preserve  the  stability  of  the  subnet  in terms of routing and
minimizing network flow changes only to user data packets.

This requires the interfaces to be able to communicate  without  knowing
what its network layer addresses should be.  This shouldn't be a problem
as LAPB already supports this, there are two implicit  addresses  for  a
point-to-point link -- DTE and DCE.

While X.25 is designed to address this issue of calling up a network and
gaining network access, it addresses only the host to subnet  connection
and  not  how  the  subnet  manages  its  external ports or performs the
routing of packets.  This is an issue which we  would  like  to  discuss
with  others.   We  are  sure  the ISO network layer working groups have
worked on this issue and we would be interested  in  hearing  from  them
concerning this subject.

Because  the  address pool is managed by the subnet, the user's need not
be concerned with low level details  about  attaching  to  the  network.
They  need only be concerned if they have appropriate access privileges.
The link to the network will be established automatically.

This dynamic address assignment model assumes that the host computer has
no  services  to  offer  the network, and that the network resources are
used by the PC and not vice versa.  That is, the PC is a strict  client,
and  there is no need to seek out servers on the PC by other users or by
the network.  Additionally, services which the PC will subscribe to  are
offered by the subnet through resource servers which are stable and have
"well-know" addresses.

Since this model assumes a strict  client-server  relationship,  the  PC
will  not  be  providing  any  services  to the network.  It is merely a
consumer.  For the most part, this strict model is  sufficient  when  PC
hosts  are  used.  Again the feasibility of this model is dependent upon
servers which;

	1.) are stable within the network,
	2.) support name/service lookup,
	4.) are capable of validating user accounts/passwords,
	    which as an entity provide a distributed authentication
	    and resource server capabilities. 
	3.) will offer services such as queuing up and retrieving mail,
	    (perhaps running a POP-like protocol), providing disk space,
	    distributed databases, etc..

In  most  networks, there are existing resources which are non-mobile or
their locations are fixed. If the architecture can support a distributed
maintenance of accounts this access and authentication scheme will allow
a user to log into any point in the network and access network services.

As with other approaches, a solid authentication mechanism needs  to  be
established  to  control  network  access.   For  network  management, a
mechanism also needs to  be  developed  to  determine  exactly  who  has
attached and what its new address is.

AUTHENTICATION

Allowing  a PC to arbitrarily log into any point in the network requires
that the network support a  distributed  authentication  mechanism.   To
accomplish  this  the  use  of  distributed  authentication servers will
probably be required.  The authentication servers must:

    1.) maintain, through periodic updates, a table of users and 
	passwords of valid users that are allowed access to the network.  
        (it should be possible to derive this from the network passwd file)
    2.) receive and validate authentication packets from login hosts. 
    3.) allow the authenticated PC user to modify the existing authentication
        password.

When a PC enters the network it passes an authentication packet into the
network port where this packet is received and forwarded to the  nearest
authentication  server  for validation. If authentication is successful,
the PC is  permitted  access  to  the  network.   If  authentication  is
unsuccessful  then  the  network  notifies  the  PC  and  access  is not
permitted and the port reclaimed after several unsuccessful attempts  to
gain access.

After  authentication,  the responsibility for seeking out services will
remain with the PC -- where the services are held, how  "expensive"  the
service is in terms of cost, transmission time, reliability, load, etc..
From a network wide perspective, transcending the layers,  there  should
be  resource/name servers for informing the PC where it can locate files
and other pertinent information.  Through the resource servers,  the  PC
is able to contact other servers for specific information.

Access control could be maintained by the authentication server which is
a  network  layer  authentication   mechanism.    Some   monitoring   of
individuals  currently  logged onto the network may be performed at this
layer to map users to addresses or perhaps to notify recently logged  on
users  of  important  events which may have transpired since last login.
In a truly distributed environment, login into the net will also  result
in  updates  containing resource locations be sent to the PC identifying
where and what kind of resources can be found at the current moment.

ADDITIONAL REQUIREMENTS

In order to support the before mentioned slip access and  authentication
mechanisms  the development of a higher layer protocol must occur. It is
this  protocol  which  will  support  the  passing   of   authentication
information   to   and   from   the  network.  As  well,  a  distributed
authentication-server must be developed which is capable of  maintaining
distributed  account/password file information and authenticating client
requests.

In addition, a higher layer protocol and server must be developed  which
will  support  the concept of an information/resource service. It is the
job of these resource servers to provide information, upon  request,  to
the  PC  indicating at what point in the subnet information such as mail
or data  base  updates  (etc.)  can  be  retrieved  and  what  the  cost
associated with this information might be.

SUMMARY

To summarize the above, we see the requirement for:

	1) Serial line IP protocol for support of dynamic address assignment to
	   minimize routing table updates and address/configuration problems.  

	2) user authentication based upon a distributed authentication server.

	3) resource servers, which are capable of providing information
	   on request to the PC, informing the PC the whereabouts of mail
	   and other services.

There appears to be  many  benefits  to  this  approach  for  the  given
architecture,   and   perhaps   many  drawbacks.   While  this  idea  is
conceptually no different than the idea of  dialing  up  to  your  local
computer  via  a dumb terminal, we leverage the multiplexing features of
existing protocols such as  IP.   This  approach  does  imply  that  the
resources  at  the  host  may  not be used optimally, but for a military
application,  the  need  for  survivability   may   preempt   efficiency
requirements. 

Any comments will be appreciated.

Jointly,

Don Holman
Danny Lee

SRI International.

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jan 88 08:02 5
From:      "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Sun OS 3.4 and subnets
     Hi!

     In regards to my problem of getting subnets working on Sun OS 3.4 
using diskless workstations on one side of a server and a campus 
back-bone ethernet of the other, we're up.

     The credit for getting us up this far goes the Vance Morrison.  We 
got the diskless workstation side up first and THEN turned on the 
ethernet interface to the back-bone.  Now the server can talk to the 
back-bone and the diskless wonders can talk to the server.

     Next problem is that the diskless boxes don't seem to be able to 
reach the back-bone.  We get one of two responses depending on what we 
tell the server.  Ether a diskless  station trying to TELNET to the 
back-bone will come up with 'network unreachable' OR TELNET wil say 
'Trying....' and sit there.  

     We're soooo close but no prize yet.  Any more ideas?  We've tried 
various hand routings on the server but only get one of the above two 
responses.

     Thanks.

Cheers,
Chris Johnson
Northeastern University
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jan 88 08:22:58 EST
From:      Ken Pogran <pogran@ccq.bbn.com>
To:        sundc!potomac!jtn@seismo.css.gov
Cc:        arpaupgrade@bbn.com, tcp-ip@sri-nic.arpa
Subject:   Re: ARPANET UPGRADE
John,

On the contrary!  We have you listed as a host afflicted by the
"Stuck VC" problem, for which a fix was deployed to the "affected
nodes" (it hasn't been distributed net-wide yet).  If you're
still not "on the air", then something's gone wrong that we will
investigate.

It's also not the case that BBN believes that the remaining
problems are all site/host problems.  We're working on several
problems that aren't "show-stoppers", for which we and/or the
sites have developed work-arounds -- the ECU problem mentioned by
Charles Hedrick at Rutgers, for example.  These are problems that
had been put on the back burner while we worked to resolve the 
show-stoppers described in our previous messages.

Ken Pogran
-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 03:44:32 GMT
From:      NJG@CORNELLA.BITNET (Nick Gimbrone)
To:        comp.protocols.tcp-ip
Subject:   Re: seeking experiences with IBM 9370 tcp/ip

>Our IBM types are planning on installing and evaluating an IBM 9370,
>including an Ethernet tcp/ip connection.  We would be interested
>in the experiences of others with the 9370 tcp/ip.  (Is the
>software just the wiscnet stuff?)
The IBM TCP/IP for VM product (5798-FAL, or just FAL for short :-) has
its roots in the Wiscnet package.  BUT (a big but) the code has been
extensively worked on by IBM Yorktown.  The current FAL product is
faster, more stable, and in all around better than Wiscnet ever was.  I
would not make any negative assumptions based upon earlier experiences
with the Wiscnet code.  On the hardware side (the 9370 and its ethernet
controler) I'm afraid I cann't offer any words of wisdom.  For
discussions of FAL software (and related hardware issues) you might
want to join the IBMTCP-L list hosted at CUNYVM.CUNY.EDU (or
CUNYVM.BITNET).
  (I believe you subscribe by sending a one line mail file containing
   'SUB IBMTCP-L <your name>' to LISTSERV@CUNYVM.CUNY.EDU, but I may
   be wrong.)

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 04:20:56 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  A good day for timewarps

Steve,

Great. NCAR is apparently ticking to-date as well. Have you any idea why
I can't barge into the WWVB fuzzy and refertilize its disk?

All stations, be advised reports from our commando unit operating in
Vienna, VA, has just liberated a WWVB clock (which used to tick at
Linkabit). Said clock and commando also sighted leaving Metroliner
Wilmington, DE. There are persistent rumors to effect this clock may
soon tick from U Delaware. This was a very clean operation with the
only casulty a Property Control Officer and a DSSW beancounter or two.

Dave

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 07:57:00 GMT
From:      JOHNSON@nuhub.acs.northeastern.EDU ("I am only an egg.")
To:        comp.protocols.tcp-ip
Subject:   Sun OS 3.4 and subnets


     Hi!

     In regards to my problem of getting subnets working on Sun OS 3.4 
using diskless workstations on one side of a server and a campus 
back-bone ethernet of the other, we're up.

     The credit for getting us up this far goes the Vance Morrison.  We 
got the diskless workstation side up first and THEN turned on the 
ethernet interface to the back-bone.  Now the server can talk to the 
back-bone and the diskless wonders can talk to the server.

     Next problem is that the diskless boxes don't seem to be able to 
reach the back-bone.  We get one of two responses depending on what we 
tell the server.  Ether a diskless  station trying to TELNET to the 
back-bone will come up with 'network unreachable' OR TELNET wil say 
'Trying....' and sit there.  

     We're soooo close but no prize yet.  Any more ideas?  We've tried 
various hand routings on the server but only get one of the above two 
responses.

     Thanks.

Cheers,
Chris Johnson
Northeastern University

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 10:29:28 GMT
From:      jmg@cernvax.UUCP (jmg)
To:        comp.protocols.tcp-ip,comp.lang.c
Subject:   Re: C binding interfaces for TCP/IP

In article <25@vdelta.UUCP> dave@vdelta.UUCP (Dave Arnold) writes:
>Are there efforts underway to standardize a C language interface for TCP/IP?
>I have asked a particular vendor about this for VAX/VMS, and all he said was
>"You get a QIO interface".  Great, so when we migrate to OSI, we will have
>to rewrite all our software.  How does BSD sockets and streams fit into this?

We decided to define a set of routines for using a transport service,
called Common Applications Transport Service (CATS). It was oriented
towards OSI, but has been implemented on top of DECNET also.
If I have understood it correctly it is more oriented towards streams
than sockets, although we think that it could go onto both.
The routines have been put onto various computers and operating systems,
and there is quite a lot of interest: physicists also want to avoid
changing their programs more than necessary.
Of course, the OSI TP4 is not really meant to be used directly by programmers,
and there are thus no defined programming interfaces. However, in the real
world people chase after efficiency, speed etc., which they feel is better
by avoiding such things as presentation and session level.
(if that does not start a religious war then nothing will!)

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 13:16:12 GMT
From:      larry@pdn.UUCP (Larry Swift)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet support in SunOS 3.3

In article <8801182146.AA03342@speed.sun.com> nowicki@SUN.COM (Bill Nowicki) writes:
>Last week there were several incorrect messages to this list about the
>IP subnet support in SunOS releases.  As developer of this software, I
>would like to brave the flames and clear up the misconceptions.

Unfortunately, your messsage didn't offer any help to those having the
problems.  I inferred that you thought the problems were imaginary or
due to ill-informed users.  However, one of Sun's own reps has 
acknowledged some difficulties in the subnet routing area.  Can you
surmise what it is that is causing (at least several people) problems?

Larry Swift                     UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207          Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 13:22:58 GMT
From:      pogran@CCQ.BBN.COM (Ken Pogran)
To:        comp.protocols.tcp-ip
Subject:   Re: ARPANET UPGRADE

John,

On the contrary!  We have you listed as a host afflicted by the
"Stuck VC" problem, for which a fix was deployed to the "affected
nodes" (it hasn't been distributed net-wide yet).  If you're
still not "on the air", then something's gone wrong that we will
investigate.

It's also not the case that BBN believes that the remaining
problems are all site/host problems.  We're working on several
problems that aren't "show-stoppers", for which we and/or the
sites have developed work-arounds -- the ECU problem mentioned by
Charles Hedrick at Rutgers, for example.  These are problems that
had been put on the back burner while we worked to resolve the 
show-stoppers described in our previous messages.

Ken Pogran

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 14:16:53 GMT
From:      sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden)
To:        comp.protocols.tcp-ip
Subject:   SUPDUP for 4.3bsd Unix: request for sources

With all of this talk of SUPDUP, does anyone have an implementation
for 4.3bsd Unix. There was, I recall, a 4.2 implementation, but I
didn't need it, then.

Sean McLinden
Decision Systems Laboratory
University of Pittsburgh

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 14:17:48 GMT
From:      robert@pvab.UUCP (Robert Claeson)
To:        comp.protocols.tcp-ip
Subject:   TLI and Sockets


Is there anything that would make a program running on a System V
Release 3 machine, using TLI, to communicate with a program running
on a machine using Sockets?

-- Robert
-- 
Robert Claeson, System Administrator, PVAB, Box 4040, S-171 04 Solna, Sweden
eunet: robert@pvab
uucp:  sun!enea!pvab!robert

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 14:34:00 GMT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re: Where to find... supdup and tn3270 specs


    Date: Wed, 20 Jan 88 09:37:35 PST
    From: braden@venera.isi.edu

    Some people think SUPDUP is a swell protocol.  Why doesn't one of them
    take the time to write a reasonable protocol RFC on SUPDUP, without
    assuming 36-bit machines.  Then the rest of the Internet world can
    find out how wonderful SUPDUP is.

As MRC said, SUPDUP does not assume 36-bit machines.  Depending on what
level of abstraction you choose to take, the RFC either does or does not
assume 36 bit machines.  What the RFC does is abstract various
quantities into 36 bit words and uses some PDP-10 notation conventions.
That's an abstraction, one of many possible abstractions, and in many
senses just as valid as any other abstraction (e.g., one that assumes
Vaxen or 68000s) one might use to (re)write the RFC with.

Maybe what you are asking for is an appendix which describes how to
pack, unback and interpret the 36-bit quantities for "normal" machines?

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 14:39:17 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re:  A good day for timewarps

Dave, I am disappointed.  Beancounters usually are high priority
and to only take out two of them is not very good field operations :-)

dennis

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 15:47:16 GMT
From:      gross@GATEWAY.MITRE.ORG (Phill Gross)
To:        comp.protocols.tcp-ip
Subject:   Re:  POSIX

There are indeed some very interesting things happening in the POSIX
arena these days and NBS is very involved in many aspects of the work.
If no one from NBS responds to you directly, send me a note and I will
give you a name to contact.

In the meantime, for those who want to find out more basic information,
there is an informative introductory document entitled `POSIX Explored' 
from /usr/group.  The address given in the document is:

	/usr/group
	4655 Old Ironsides Dr. #200
	Santa Clara, CA 95054
	408-986-1645

Phill Gross

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 21:26:00 EST
From:      <enger@bluto.scc.com>
To:        "sundc!potomac!jtn" <sundc!potomac!jtn@seismo.css.gov>
Cc:        <arpaupgrade@bbn.com>,<pogran@ccq.bbn.com>, <tcp-ip@sri-nic.arpa>
Subject:   PSN 7 problems still arise.


Even though patches have been developed, they don't seem to stay
deployed.  I have lost track of the number of times that I have had
to call the NOC to have "the patches" down loaded again.   Perhaps this
"fleeting patch" syndrome is all that afflicts ADS?

Bob Enger

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 16:44:37 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  A good day for timewarps

Dennis,

Yeah, but I sure got funny looks as I hauled the clock and antenna through
Union Station. I just told the doorperson the antenna was a new-model M16
and got wonderful service. It seems to be working okay at the moment, so
its appearance on the net should be eminent (sic).

Dave

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 17:13:37 GMT
From:      lekash@ORVILLE.NAS.NASA.GOV (John Lekashman)
To:        comp.protocols.tcp-ip
Subject:   Re:  Hop problem


	From tcp-ip-RELAY@SRI-NIC.ARPA Thu Jan 21 00:40:29 1988
	Received: Thu, 21 Jan 88 00:40:26 PST by orville.nas.nasa.gov (5.54/1.2)
	Received: Thu, 21 Jan 88 00:41:41 PST by ames-nas.arpa (5.51/1.2)
	Message-Id: <8801210841.AA12538@ames-nas.arpa>
	Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed 20 Jan 88 14:17:55-PST
	Received: from UNMB.BITNET by CUNYVM.CUNY.EDU ; Wed, 20 Jan 88 17:17:52 EST
	Date:     Wed, 20 Jan 88 15:16 MDT
	From: <STGEORGE%UNMB.BITNET@CUNYVM.CUNY.EDU>
	Subject:  Hop problem
	To: tcp-ip@sri-nic.arpa
	X-Original-To:  tcp-ip@sri-nic.arpa
	Status: RO
	
	Can anyone tell me the status of thw work being done to get around the
	limitation of TCP/IP to a hop of 15 nodes? Thanks.
	
Said work is complete, in that the current limit is 255, assuming all
intervening gateways only decrement the time to live by one.
This has always been the state.  Perhaps the particular IP 
you are running initializes the time to live at 15, assuming 
this to be an upper limit.  There is also the existence of 
an implementation of a routing protocol called RIP, which
assumes a distance of 16 is infinite.  Perhaps this is
causing you some problem.  All you need do is correct all
machines to initialize the ttl field to be more than 15,
and you will win.  I doubt seriously if anyone is trying
actively to repair this as a default case.

					john

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 20:14:07 GMT
From:      MRC@PANDA.PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: Where to find... supdup and tn3270 specs

Page 3 of RFC 734, "INITIALIZATION", in the very first paragraph describes
completely how to pack, unpack, and interpret the 36-bit quantities
in terms of 8-bit bytes.  The SUPDUP protocol itself uses 8-bit bytes in
transmission over the network.

I doubt the critics of the SUPDUP RFC have ever bothered to read it; it's
so much easier to criticize based on hearsay and the dread sequence
"PDP-10".
-------

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 20:36:04 GMT
From:      km@emory.uucp (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   SLIP on Annex Box

Does anyone know if the Annex Box does SLIP? I guess it could do it
completely in the box which would seem ideal. Alternately it could let
one of the Unix hosts treat the connection like a tty and handle the
substance.
-- 
Ken Mandelberg      |  {decvax,sun!sunatl,gatech}!emory!km  UUCP
Emory University    |  km@emory                             BITNET
Dept of Math and CS |  km@emory.ARPA                        ARPA,CSNET
Atlanta, GA 30322   |  Phone: (404) 727-7963

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 88 23:47:47 GMT
From:      pogran@ccq.bbn.COM (Ken Pogran)
To:        comp.protocols.tcp-ip
Subject:   Re: ARPANET UPGRADE

John,

With regard to the problem you reported, being unable to
communicate with 1822-connected ARPANET hosts (including
gateways): It turns out that the PSN's "community-of-interest"
word for your host was set incorrectly, which had exactly the
effect you reported: the PSN allowed you to communicate with
other X.25-connected hosts, but prohibited you from communicating
with 1822-connected hosts.  Our troubleshooter reports that we've
corrected the problem, and that one of your folks has confirmed
that you can now communicate normally with 1822-connected hosts.

The "community-of-interest" word is a per-host configuration item
in the PSN; unfortunately we can't tell how it came to be set
wrong.  Most likely it occurred in the (all-too-manual) process
of setting up the PSN 7 configuration items based on the existing
PSN 6 configuration.  Our apologies.

Ken Pogran

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 01:45:54 GMT
From:      narten@PURDUE.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   An even worse week for EGP....

The trouble with bogus networks slipping into the core tables has
apparently returned. Has anyone fingered a culprit?

In my seemingly endless explorations of the EGP code in gated, I have
discovered yet another tidbit. These comments apply directly to egpup
as well, from which gated claims ancestory.

1) Totally bogus nets are slipping into the core tables. By bogus, I
mean neither class A, B or C. When encountered during the processing
of an EGP network reachability update, one cannot determine how many
bytes the address is supposed to be. Gated chokes when it receives
them in updates and tosses the partially processed update.

2) EGP detects the "problem" with the data, and assumes that the
entire packet is bad (even though it installs all the routes up to the
bogus one). After 4 such updates in a row, gated sends a cease command
to the gateway it was peering with, and goes back into neighbor
acquisition state. Meanwhile, any routes you are advertising to the
core get marked ureachable for 60 seconds.

This has happened at our site many (1-2 dozen times) since last
Thursday. (e.g. the problem doesn't seem to be going away).

3) If you are running Kirton's EGP, or an old version of gated, none
of these events will be logged anywhere. In other words, if it is
happening to you, you probably aren't even aware of it.

4) The code in gated, egpup and the BBN core gateways apparently all
allow non class A, B, C nets to slip into updates [which side of the
fence do fuzzballs and vendor gateways sit on??] The problem is no
doubt code of the following type:

if (is_classA_net(net)) then
    /* do class A stuff */
else if (is_classsB_net(net)) then
   /* do class B stuff *
else
   /* must be a class C net */
   /* do class C stuff */
endif   

For egpup users, I strongly urge that the following patch be applied
to rt_egp.c. It will prevent egp from sending out reachability updates
for non-A,B,C nets.

*** rt_egp.c	Thu Jan 21 20:02:20 1988
--- /usr/src/local/etc/egp/rt_egp.c	Mon Nov 10 19:05:38 1986
***************
*** 128,135 ****
  
  		if( in_isa( current_gw)) n_bytes = 3;
  		else if( in_isb( current_gw)) n_bytes = 2;
! 		else if (in_isc( current_gw)) n_bytes = 1;
! 		else return(ERROR);
  		bcopy( (u_char *)&current_gw+4-n_bytes, nrp, n_bytes);
  		nrp += n_bytes;
  
--- 128,134 ----
  
  		if( in_isa( current_gw)) n_bytes = 3;
  		else if( in_isb( current_gw)) n_bytes = 2;
! 		else n_bytes = 1;
  		bcopy( (u_char *)&current_gw+4-n_bytes, nrp, n_bytes);
  		nrp += n_bytes;
  
***************
*** 152,159 ****
  							/* copy net addr */
  	    if( in_isa( net_pt->net)) n_bytes = 1;
  	    else if( in_isb( net_pt->net)) n_bytes = 2;
! 	    else if (in_isc( net_pt->net)) n_bytes = 3;
! 	    else return(ERROR)
  	    bcopy(&net_pt->net, nrp, n_bytes);
  	    nrp += n_bytes;
  	}					/* end for each net */
--- 151,157 ----
  							/* copy net addr */
  	    if( in_isa( net_pt->net)) n_bytes = 1;
  	    else if( in_isb( net_pt->net)) n_bytes = 2;
! 	    else n_bytes = 3;
  	    bcopy(&net_pt->net, nrp, n_bytes);
  	    nrp += n_bytes;
  	}					/* end for each net */

For gated users, the same basic patch applies. Look in the file
rt_egp.c, routine rt_NRnets(). I would supply the patch, but I am
running a beta test version of gated that's different than everyone
elses.

I am skeptical that the above fixes really get at the heart of the
problem. Some of the nets that are appearing apperently don't really
exist, but they are technically valid Internet addresses.

Thomas

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 02:26:00 GMT
From:      enger@BLUTO.SCC.COM
To:        comp.protocols.tcp-ip
Subject:   PSN 7 problems still arise.



Even though patches have been developed, they don't seem to stay
deployed.  I have lost track of the number of times that I have had
to call the NOC to have "the patches" down loaded again.   Perhaps this
"fleeting patch" syndrome is all that afflicts ADS?

Bob Enger

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 02:50:37 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  A good day for timewarps

Scott,

I concur with your feeling that the NCAR fuzzball should be protected from
cycle stealers as much as possible, but maybe you are missing something.
First, application-level services, including NTP, are run at the lowest
priority level in the multi-level scheduler, so that packet-forwarding
functions always take precedence. Furthermore, the memory allocations
are disjoint, so that even relatively large numbers of UDP users do
not impact the resources used by packet-forwarding functions.

Notwithstanding the above, I would very much recommend the use of the
backbone fuzzies to provide time service directly to their Ethernet
population simply to avoid those time-service packets transiting the
seriously overloaded backbone links to other time servers removed from
the backbone. As you know, the fuzzballs are carefully synchronized
to various radio clocks using their local-net routing protocol, so
there is no need for time-service packets between them or for timewatchers
to chime any but the nearest fuzzball as the ethernet flies.

What I think is a much more productive strategy is to suggest to your
timewatchers to avoid the urge to chime any particular fuzzball with
multiple hosts on the same network. Far better to chime with one host
using NTP and then redistribute time locally. It would seem that each
backbone fuzzball could serve as chimee for any or all the nets it
normally serves in its respective configuration. This would avoid
the chimepackets even coming near the overloaded serial lines.

Dave

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 03:19:50 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  An even worse week for EGP....

Thomas,

The fuzzbugs do not currently perform a sanity check on IP net numbers
appearing in EGPspeak or hellospeak messages; however, they do sport
a martian filter that tosses packets with unsane IP addresses should
they appear. You make a good point that the martian filter should
also be expressed in a sanity check for routing data as well.

Today the situation I complained about last Sunday happened again,
with nets 207-something figuring very prominently in the noise. I tried
to catch a MILNET gateway in the act, but without success before the
wickedness evaporated from the core tables.

Dave

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 05:06:35 GMT
From:      morgan@navajo (Bob Morgan)
To:        comp.protocols.tcp-ip
Subject:   Telnet-to-Telenet? (long)

I'm with the Networking Systems organization at Stanford.  We're
investigating possibilities for connecting our campus-wide
TCP/IP/Ethernet-based network (SUNet) to some X.25 networks.  We
envision a gateway box that would have one or more X.25 trunks on one
side and an Ethernet interface on the other.  We've figured out a few
things, found out some other things, and now are casting about for
fellow travelers (or maybe clever entrepreneurs).

(In the following, please excuse if my X.25 terminology isn't correct;
I'm not as familiar with it as I should be.)

We would like to provide the following services:

  * Outgoing terminal connections from SUNet machines to service
providers (such as Dialog) on X.25 PDNs (such as Telenet) (Yes, this
is the long-awaited Telnet-to-Telenet service 8^)

  * Outgoing terminal connections from SUNet machines to various
campus hosts that don't support TCP/IP/Ethernet but do support X.25

  * Incoming terminal connections from X.25 PDNs to SUNet hosts

  * Terminal connections from X.25-only campus hosts to SUNet hosts

There are some problems with setting up something like this, mostly
having to do with trying to connect an anarchic, "free" network
(SUNet/Internet) to metered, pay-as-you-go networks (PDNs).  In
particular:

  * Some campus hosts already have direct PDN (Telenet) lines and
support users who place "collect" calls to those hosts.  PDN charges
are eaten by the host-providing organization, or (in some cases, I
think) charged back to users through host usage charges.  They would
like to continue this sort of service, through this new box.  This
means that we somehow have to a) restrict collect calls to a specific
set of IP hosts, and b) capture the information about connections to
be able to do billing.

  * On the other hand, other hosts that don't want to worry about
collect calls might still like to receive connections from users who
pay their own PDN charges, so these connections should be possible to
any SUNet host.  But we'd just as soon not provide access through our
facilities to the entire Internet from any Telenet PAD, so we'd like
to restrict the IP-side destinations to just Stanford.

  * We expect that outgoing calls (SUNet-to-PDN) will be collect only,
but once again we would prefer that these calls originate only at
Stanford, not anywhere in the Internet.

  * As much as possible, we'd like to insulate users from logging in
six times and entering long strings of numbers to make connections.
For example, I'd like to just say "> telnet dialog" from my Unix
system and have it all happen.  This means that the gateway should
have some ability to translate names and addresses across the two
types of nets.

We're testing a Develcon system which is basically a port selector
with an X.25 card and a Telnet-server/Ethernet card installed in it.
This works fine for making the basic connections, and to some extent
for handling the name translation issue.  But it's very difficult to
make it deal with the access-control (password protection is the prime
method) and cross-net accounting issues.  It's not really their fault,
as it seems to me that no IP terminal server vendor is dealing with
access control in a comprehensive way.

Another approach, of course, is to take a Sun or a VAX with an X.25
board and munge it to do some of these things.  Maybe all it would
take is rewriting Telnet client and server modules to be more picky.
We would, of course, prefer an off-the-shelf solution.  Also, there's
some concern about how well something like this would scale up if the
service became popular.

So:  is anybody doing anything like this?  It sure looks to me like a
market opportunity here, folks.  Suggestions, solutions, flames may be
sent to me and I'll digest and repost, etc.

Thanks,

- RL "Bob" Morgan
  Stanford Networking
  morgan@jessica.stanford.edu

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 05:31:02 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP on Annex Box

I know that Proteon rebundles the Annex server and resells it themselves.
They've done a lot with SLIP, so they would be a reasonable place to ask.
(Jon, are you out there?)

-Philip

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 05:44:08 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: Where to find... supdup and tn3270 specs


        Some people think SUPDUP is a swell protocol.  Why doesn't one of them

Yes, I think supdup is a great protocol.  That is why I asked.  However,
I didn't realize I was opening up Pandora's box when I asked...

        take the time to write a reasonable protocol RFC on SUPDUP, without
        assuming 36-bit machines.  Then the rest of the Internet world can
        find out how wonderful SUPDUP is.

    As MRC said, SUPDUP does not assume 36-bit machines.  Depending on what
    level of abstraction you choose to take, the RFC either does or does not
    assume 36 bit machines.  What the RFC does is abstract various
    quantities into 36 bit words and uses some PDP-10 notation conventions.
    That's an abstraction, one of many possible abstractions, and in many
    senses just as valid as any other abstraction (e.g., one that assumes
    Vaxen or 68000s) one might use to (re)write the RFC with.

Given that is a networking protocol, the most reasonable representation
would be how the bits (bytes, or octets) appear 'on the wire', not how
they pack into a particular machine's word.

In view of the number of RFCs in print, we should know by now how to
express an idea without reverting to assembly language (for any processor,
whether esoteric or commonplace)...

-Philip

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 1988 10:57-EST
From:      CLYNN@G.BBN.COM
To:        narten@PURDUE.EDU
Cc:        egp-people@PARK-STREET.BBN.COM, tcp-ip@SRI-NIC.ARPA
Subject:   Re: An even worse week for EGP....
I also noticed strange network numbers a couple months ago.  When I
ask about it, I was told that the bogus numbers were coming from a
gateway which had a noisy line to the net.  Maybe the protocol being
used didn't have a checksum, maybe it was turned off, maybe it wasn't
"strong enough".  Once the information gets into a table, it would be
propogated.  I didn't get the impression that the problem had a very
high priority; the "only" adverse effect would be to use a slot in
routing tables, and since it was a bogus net, nobody should be using
it, and they should time out.
	I suspect that, given the dynamic and evolving nature of the
Internet, any code which assumes "otherwise <something valid>" will
cause us problems before too long.  E.g., the new internet multicast
addresses, the new IP and TCP options that we would like to create,
etc.

Charlie
-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 11:20:00 EST
From:      <yurcik@nrl-lcp.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        yurcik
Subject:   ACM SIGCOMM Mtg. Washington DC 2/22/88
Following is an announcement for TCP developers and maintainers who
are in the Washington D.C. area or will be visiting the area on 2/22/88.  
This open informal meeting includes a talk and is intended for discussions of 
technical issues and past experiences.   
 	
	
	
	
	                                 DC  SIGCOMM
	                                  NASA/GSFC
	
	                     Association for Computing Machinery
				  Washington, D.C. Chapter
				  Special Interest Group on
				     Data  Communication
					   and the
			       NASA/Goddard Space Flight Center
	
	
			       NETWORK ROUNDTABLE #1/SEMINAR
			       -----------------------------
	
	DATE:		Monday, February 22, 1988
	
	TIME:		1:15 p.m. to 5:00 p.m.
	
	PLACE:		Goddard Space Flight Center
			Building 8 Auditorium
			Greenbelt, MD  20771
	
			Directions: From the Baltimore-Washington Parkway, take 
			the Greenbelt Road/NASA exit.  Turn left onto Greenbelt 
			Rd.;  Goddard's main gate will be on the left at the 
			nth stoplight.
	
	RESERVATIONS:	For security reasons, non-U.S. citizens and foreign 
			nationals wishing to attend should make arrangements 
			in advance through
			their embassy.
	
	CONTACTS:	For additional information, contact Sol Broder, Head, 
			Advanced Data Flow Technology Office at (301)286-7088 
			or Brian Lev at (301)286-9514.
	
	PROGRAM:  
		  1:15-1:30 Greeting/Introduction	Broder/NASA
	            					Gardner/SIGCOMM, Chair
	
		  1:30-2:00 Seminar          		D. Clark/MIT
	
		  2:00-4:00 Roundtable - Site Presentations
		  2:00-2:20 University of Maryland	G. Ricart
		       2:40 George Mason University	B. Peters
		       3:00 GSFC                        S. Broder
		       3:20 MITRE                       Chandler/Cerva
		       3:40 George Washington Univ.	D. Preuss
		       4:00 NRL 			R  Saenger
	
		  4:00-5:00 Discussion of Misc. Technology Concerns,
		            Plans for Future Meetings, Format, Content.
	
	GUEST SPEAKER:	Dr. David Clark, MIT
	
	TOPIC:		"Network Throughput - Where Are the Limits?"
	
	ROUNDTABLE:	Area facility network managers and implmentors will 
			have an opportunity  to share experiences and discuss 
			technology issues.
	

------
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 13:51:43 GMT
From:      mechgam@tness1.UUCP (Gary Mink 713+521-6958)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Adaptors for thinwire to thickwire



3Com has a product called the Multiconnect, a Modular Multiport Repeater.
My product information sheet says, "Repeater Modules provide connections
to Thick Ethernet, Thin Ethernet, Fiber and Twisted Pair..."   The 
Multiconnect can have 15 modules of different types in any combination.
Does anybody have any experience with this unit?


-- 
Gary A. Mink
Southwestern Bell Telephone Co.  (713) 521-6958
mechgam@tness1!uucp
{ihnp4,bellcore,killer,petro}!tness1!mechgam

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 14:11:00 GMT
From:      DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re: Where to find... supdup and tn3270 specs


    Date: Fri, 22 Jan 88 00:44:08 EST
    From: "Philip A. Prindeville" <PAP4@AI.AI.MIT.EDU>

    Given that is a networking protocol, the most reasonable representation
    would be how the bits (bytes, or octets) appear 'on the wire', not how
    they pack into a particular machine's word.

    In view of the number of RFCs in print, we should know by now how to
    express an idea without reverting to assembly language (for any processor,
    whether esoteric or commonplace)...

I think MRC was right.  Have you read the RFC, or are you making attacks
based on hearsay?  There is no, absolutely no, assembly language in the
RFC.  As for your "on the wire" argument, TCP and IP don't even do that.
TCP and IP abstract the bytes into headers which are displayed and
discussed in the RFC as headers, not bytes on a wire.  They describe how
those headers appear on the wire, just as the SUPDUP RFC describes how
the 36 bit quantities appear on the wire.  I'm really trying to avoid
making disparaging remarks about people's inability to convert between
abstractions.

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 15:57:00 GMT
From:      CLYNN@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: An even worse week for EGP....

I also noticed strange network numbers a couple months ago.  When I
ask about it, I was told that the bogus numbers were coming from a
gateway which had a noisy line to the net.  Maybe the protocol being
used didn't have a checksum, maybe it was turned off, maybe it wasn't
"strong enough".  Once the information gets into a table, it would be
propogated.  I didn't get the impression that the problem had a very
high priority; the "only" adverse effect would be to use a slot in
routing tables, and since it was a bogus net, nobody should be using
it, and they should time out.
	I suspect that, given the dynamic and evolving nature of the
Internet, any code which assumes "otherwise <something valid>" will
cause us problems before too long.  E.g., the new internet multicast
addresses, the new IP and TCP options that we would like to create,
etc.

Charlie

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 16:20:00 GMT
From:      yurcik@NRL-LCP.ARPA
To:        comp.protocols.tcp-ip
Subject:   ACM SIGCOMM Mtg. Washington DC 2/22/88

Following is an announcement for TCP developers and maintainers who
are in the Washington D.C. area or will be visiting the area on 2/22/88.  
This open informal meeting includes a talk and is intended for discussions of 
technical issues and past experiences.   
 	
	
	
	
	                                 DC  SIGCOMM
	                                  NASA/GSFC
	
	                     Association for Computing Machinery
				  Washington, D.C. Chapter
				  Special Interest Group on
				     Data  Communication
					   and the
			       NASA/Goddard Space Flight Center
	
	
			       NETWORK ROUNDTABLE #1/SEMINAR
			       -----------------------------
	
	DATE:		Monday, February 22, 1988
	
	TIME:		1:15 p.m. to 5:00 p.m.
	
	PLACE:		Goddard Space Flight Center
			Building 8 Auditorium
			Greenbelt, MD  20771
	
			Directions: From the Baltimore-Washington Parkway, take 
			the Greenbelt Road/NASA exit.  Turn left onto Greenbelt 
			Rd.;  Goddard's main gate will be on the left at the 
			nth stoplight.
	
	RESERVATIONS:	For security reasons, non-U.S. citizens and foreign 
			nationals wishing to attend should make arrangements 
			in advance through
			their embassy.
	
	CONTACTS:	For additional information, contact Sol Broder, Head, 
			Advanced Data Flow Technology Office at (301)286-7088 
			or Brian Lev at (301)286-9514.
	
	PROGRAM:  
		  1:15-1:30 Greeting/Introduction	Broder/NASA
	            					Gardner/SIGCOMM, Chair
	
		  1:30-2:00 Seminar          		D. Clark/MIT
	
		  2:00-4:00 Roundtable - Site Presentations
		  2:00-2:20 University of Maryland	G. Ricart
		       2:40 George Mason University	B. Peters
		       3:00 GSFC                        S. Broder
		       3:20 MITRE                       Chandler/Cerva
		       3:40 George Washington Univ.	D. Preuss
		       4:00 NRL 			R  Saenger
	
		  4:00-5:00 Discussion of Misc. Technology Concerns,
		            Plans for Future Meetings, Format, Content.
	
	GUEST SPEAKER:	Dr. David Clark, MIT
	
	TOPIC:		"Network Throughput - Where Are the Limits?"
	
	ROUNDTABLE:	Area facility network managers and implmentors will 
			have an opportunity  to share experiences and discuss 
			technology issues.
	

------

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 17:05:58 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  An even worse week for EGP....

Dave, Thomas:

Could you be more specific about the 207-something net that is figuring in the
noise.  I understand DIA has been performing some tests for the DoDIIS communi-
ty and could be using MILNET for some of the testing.  What better test data
could you find than unclassified source listings which are stored in directory
[207,7] on DoDIIS IAS if you wanted to test FTP between systems.

Something of a knee-jerk reaction on my part since the device handler and line
interface module software that I deliver to DIA and the DoDIIS community is
normally stored in the following directories:

	[  7,7]	Generation Command Files, Task Images
	[107,7]	Object Modules
	[207,7] Source Listings, Task Image Maps
	[307,7]	Source Modules

I've given you the full list of directories in case any of it might correspond
with the addresses you're seeing.

Merton Campbell Crockett
AN/GYQ-21(V) Program
EATON Corporation
Information Management Systems

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 17:14:08 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re:  Hop problem

Is an initial TTL of 64 large enough these days? (particularly given some of
the things the packet-radio people are talking about - I saw a 30+ hop
routing posted on pc-ip recently).

jbvb

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 18:28:39 GMT
From:      MLY@XX.LCS.MIT.EDU (Richard Mlynarik)
To:        comp.protocols.tcp-ip
Subject:   UN*X SUPDUP

In the directory wheaties.ai.mit.edu:/ps/mly/supdup/
the files supdup.c, supdup.h, supdupd.c, supdup-login.c, Makefile.

The supdup-login file is needed because brain-dead un*x /bin/login
won't pass through the TERMCAP environment variable.  This might
be fixed in 4.3 for all I know.

The implementation in those files is a lot closer to the spec than
the 4.2 implementation by David Brigham upon which it is based.
It is not as featureful as it might be, due to the obvious deficiencies
of un*x compared to obsolete operating systems.
-------

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 18:43:09 GMT
From:      tsudik@MALIBU.USC.EDU (Gene Tsudik)
To:        comp.protocols.tcp-ip
Subject:   (none)

I have been experiencing what maybe a bug (or "feature") of 4.3 IP code
when trying to define new IP options. 
The new option that I've defined doesn't seem to bother IP an any higher-level
protocols when the packets are relatively short. But, as soon as fragmentation
is required, e.g. FTP large file, the connection goes dead. My guess is that
the reassembly is never completed at the receiving end. a

My question is: has anyone been playing with option definition in 4.3 IP and, if
so, has a similar problem occurred? Also, is there an obvious place(s) to look
for bugs when defining options? Any common blunders people experience when doing
that ?

Gene Tsudik
USC Network Lab

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 21:21:14 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  An even worse week for EGP....

Merton,

The typical "207 net" has a second octet whis is close to 255 (decimal),
like 255, 254, 253 and 252. I even tried decoding it in ASCII, but that
didn't parse well. I then went after the NSFNET gateways, since these
dudes now squawk upwards of 120 nets and may expose scaling bugs if any non-core
gateway does; however, these gateways are on ARPANET. I have not yet
uncovered definitive evidence that would implicate MILNET dudes, although
what evidence there is points that way.

Dave

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 88 21:23:51 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  An even worse week for EGP....

Charlie,

THose protocols known to me (EGP, RIP, hellospeak) all have reasonably
competent checksums. At one time GGP had no checksums, but has since
evolved to have them (Mike B, is my head cross-threaded?).

Dave

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 88 00:18:49 GMT
From:      MRC@PANDA.PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: Where to find... supdup and tn3270 specs

Please read the goddamn RFC before flaming any further.  There is NO
"reversion" to assembly language.  SUPDUP was first implemented for a
particular operating system.  It transmitted a few of that operating
system's registers from client to server.  Those registers are 36-bit
quantities.  As transmitted on the wire, each register is 6 bytes,
with the most significant two bits zero in each byte.  The first byte
contains the most signifiant 6 bits, the second the next, ...

The registers themselves are described as 36-bit values.  That is
because that is what they are.  You could think of them as a series
of bytes, but that obscures their original representation.

Furthermore, these registers are dealt with ONCE -- at startup -- in
the entire SUPDUP transaction and are used nevermore.  99.9% of the
time these registers will contain constants wired into the program,
with the possible exception of screen width and height.

The intellectual laziness expressed by certain individuals (who
obviously have not read the RFC beyond a fleeting glimpse) is a prime
example of why the Japanese and the Koreans are taking over America's
markets.
-------

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 88 03:28:32 GMT
From:      mrose@gonzo.twg.COM (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI and Sockets

Perhaps I have misunderstood the question, but...

Sockets and TLI are both local mechanisms used for allowing processes
to talk to the network.  If both are speaking TCP, then you can not
tell, but looking at the network traffic, whether one is using sockets
or TLI or anything else.  However, the two programs which are talking,
one using sockets and the other TLI may be very different.

Now, if you question really was: "I have a program written to use
Berkeley sockets but I want to run it on a SVR3 machine which only
has streams, what can I do?"  Then the answer is that some people
who are "heavy into Streams/TLI" have written libraries on top of
TLI which make it look like sockets.  The inverse operation,
making sockets look like TLI is probably not possible without adding a
bit of functionality to sockets.

/mtr

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 88 05:28:27 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: UN*X SUPDUP


    In the directory wheaties.ai.mit.edu:/ps/mly/supdup/
    the files supdup.c, supdup.h, supdupd.c, supdup-login.c, Makefile.

    The supdup-login file is needed because brain-dead un*x /bin/login
    won't pass through the TERMCAP environment variable.  This might
    be fixed in 4.3 for all I know.

In 4.3BSD, if /bin/login is called with the -p argument, it preserves
the environment it is called with.

    The implementation in those files is a lot closer to the spec than
    the 4.2 implementation by David Brigham upon which it is based.
    It is not as featureful as it might be, due to the obvious deficiencies
    of un*x compared to obsolete operating systems.

Does this version also gobble up column 80 to avoid bizarre wrap modes,
or does it do The Right Thing (whatever that is...)?

-Philip

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 88 23:16:36 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  WWV update

Andre',

You get sixty bits, one per second in each minute, to code everything. Right now each
minute is separate, but coded so you can compare one minute to the next. In
principle, you don't need a checksum, since you have a built-in majority
decoder capability. Heath insists that two frames (minutes) in ten be identical
to achieve lock. You can do much better than this, even without changing the
format, with a little imagination and spare microprocessor cycles.

Dave

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 88 23:20:24 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Time synchronization and distribution plan

Folks,

There is good news for clockwatchers, timewarpers and chron daemons. All radio
clocks known to me are now finally repaired and ticking to standard time.
Also, venerable WWVB ticker dcn1.arpa (aka pogo), which some of you may fondly
remember from years past, has resumed this life. There is even a NTP secondary
time server on the European MILNET which is keeping pretty good time. There
are a half-dozen or so gents who have scrounged up an old PDP11-compatible
system and volunteered additional GOES or WWV servers as well. It may be time
(!) to bring some order to the clockwatching business. A treaty is suggested
in this note.

As in the telephone systems NTP uses a model of stratified clocks and servers.
A primary server is one directly synchronized to a radio clock, so it can keep
accurate time even in the absence of NTP itself. However, from long experience
with such things, the radio clocks sometimes feature scrambled time due radio
propagation conditions or broken logic. Thus, the primary servers ordinarily
run NTP with a couple of their buddies as a sanity check. Should the radio
clock itself become suspect, time synchronization shifts to the NTP peer
group. Secondary servers are synchronized with NTP using special filtering and
deglitching mechanisms ordinarily accurate to a few tens of milliseconds, even
across intransigent gateways.

NTP can be used in either a remote-procedure-call (asymmetric) mode, in which
a client sends a single message to the server and receives the time in reply,
or a distributed (symmetric) mode, in which the protocol runs continuously and
time is continuously compared between the peers and corrected as required. The
asymmetric mode is designed for casual use, such as setting the time and date
when a PC comes up, for example, while the symmetric mode is designed for more
accurate and precise applications, such as transaction timestamping and time
redistribution. This note is concerned only with use of the symmetric mode.

Not everybody can chime with a primary server, since this would eventually
lead to severe congestion and degraded service. Therefore, a system of
hierarchical time servers is suggested. Assume that each of the 400-odd
networks now active has a secondary time server synchronized to one or more
primary servers and providing time service to other hosts in its community. In
order to provide the highest robustness, the secondary server should chime
with more than one primary server, perhaps three, so we are talking about 1200
peer paths. The existing LSI-11 fuzzball gateways can support at least 60 peer
paths each, so some twenty primary servers would be needed. At the moment NTP
chimes one packet each direction per peer per minute, so the aggregate time
traffic works out to about one packet each direction per fuzzball per second.
It is planned to introduce NTP protocol modifications that would reduce this
rate by a factor of ten.

The twenty-odd primary servers should be located at strategic spots designed
to minimize the impact of the NTP traffic itself, yet provide low delay
dispersion for their customers. The existing and planned NSFNET Backbone sites
would seem ideal candidates and, indeed, time-synchronized fuzzballs are
already installed at seven of these sites. Without admitting agenda on how the
time-synchronization capability came to pass or on the likely disposition of
the fuzzballs once the new NSFNET Backbone is deployed, I suggest a nucleus of
timetellers is already in place. Additional timetellers are now ticking on
ARPANET and local nets gatewayed to ARPANET, MILNET and elsewhere.

At the U Delaware campus and at several other campuses known to me, one or
more relatively inexpensive WWV clocks are installed as backups should
connectivity to a primary server be lost for one reason or another. The WWV
clocks are distinctly inferior in accuracy and reliability with respect to the
WWVB and GOES clocks now used at the primary servers; however, as some may
remember, there have been occasions over the last several years when all
primary servers in the experimental system were down and the entire
NTP-speaking Internet was synchronized to a dinky WWV clock on my desk at
home. I suspect several institutions that cherish accurate time will install
GOES, WWVB or even GPS clocks and join the NTP chorus as well, so there may be
in fact no need for an overt program to buy and install additional clocks.

I saved specific recommendations for last. I suggest an appropriate first step
is that those sites with good connectivity to an NSFNET regional system chime
NTP with the NSFNET Backbone fuzzball serving that regional system. Other
sites may wish to choose one or another fuzzball listed below. However, it is
most important to understand that time service is provided by each of these
gizmos on a secondary basis only, is still in an experimental phase and may be
limited or curtailed should it interfere with the primary functions of the
machine.

Speaking for myself and I suspect the other operators listed, we would expect
users to set up their own time-redistribution network, perhaps using the 4.3
bsd ntpd daemon specifically designed for this purpose, and to avoid ganging
up on the servers with many hosts from the same net. We would also expect
users planning long-term use of the servers to express their intent to the
operators and comply with requests to reaffiliate with other servers should
that become necessary. Finally, we are looking for volunteers to install
additional primary servers and join the chorus as well.

Name		Address		Clock	Operator and notes
--------------------------------------------------------------------------
Primary servers
umd1.umd.edu	128.8.10.1	WWVB	Mike Petry (petry@trantor.umd.edu)
					U Maryland (gatewayed to NSFNET
					Backbone, ARPANET PSNs 17 and 20 and
					MILNET PSN 57.
wwvb.isi.edu	128.9.2.129	WWVB	Steve Casner (casner@isi.edu)
					ISI (gatewayed to ARPANET PSN 22)
ncar.nsf.net	128.116.64.3	WWVB	Scott Brim (swb@devvax.tn.cornell.edu)
					NCAR (NSFNET Backbone gateway)
dcn1.arpa	128.4.0.1	WWVB	Dave Mills (mills@udel.edu)
		10.2.0.96		U Delaware (directly connected to
					ARPANET PSN 96)
ford1.arpa	128.5.0.1	GOES	Fred Ball (ball@ford-vax.arpa)
					Ford Research (gatewayed via 9600-bps
					line to ARPANET PSN 111.
Secondary servers (please do NOT chime with these except by permission)
macom1.arpa	192.5.8.1	NTP	Woody Woodburn (woody@macom2.arpa)
		10.0.0.111		Linkabit, Vienna, VA
swamprat.arpa	192.5.8.2	NTP	Woody Woodburn (woody@macom2.arpa)
					Linkabit, Vienna, VA
patch.arpa	26.6.0.2	NTP	Dave Park (dpark@dca-eur.arpa)
					USECOM Stuttgart, FRG
gw.umich.edu	35.1.1.1	NTP	Hans-Werner Braun (hwb@mcr.umich.edu)
					U Michigan (WWV backup)
xyzzy.umich.edu	35.1.1.3	NTP	Hans-Werner Braun (hwb@mcr.umich.edu)
					U Michigan
libra.rice.edu	128.42.1.64	NTP	Paul Milazzo (milazzo@rice.edu)
		10.4.0.62		Rice U
dcn6.arpa	128.4.0.6	NTP	Dave Mills (mills@udel.edu)
					Newark, DE (WWV backup)
sdsc.nsf.net	192.12.207.1	NTP	Scott Brim (swb@devvax.tn.cornell.edu)
					San Diego Supercomputing Center
uiuc.nsf.net	128.174.5.14	NTP	Scott Brim (swb@devvax.tn.cornell.edu)
					National Center for Supercomputing
					Aplications
psc.nsf.net	128.182.1.2	NTP	Scott Brim (swb@devvax.tn.cornell.edu)
					Pittsburg Supercomputing Center
cornell.nsf.net	128.84.238.50	NTP	Scott Brim (swb@devvax.tn.cornell.edu)
					Cornell U (NYSERNET)
jvnc.nsf.net	128.121.50.20	NTP	Scott Brim (swb@devvax.tn.cornell.edu)
					John von Neumann Center (JVNCNET)
nsfnet-gw.umd.edu 128.8.10.6	NTP	Mike Petry (petry@trantor.umd.edu)
					U Maryland (SURANET)

Corrections or additions to this list would be appreciated

Dave

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 88 12:46:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Hop problem

The 30+ packet radio hop was a deliberate attempt at maximizing the number
of nets/hops the packet traversed. I think 64 is still a reasonable maximum.
We should be trying hard to design the system so the maximum hop count is far
less than 64, of course.

Vint

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24 Jan 88 22:24:52 -0500
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        "James B. VanBokkelen" <JBVB@AI.AI.MIT.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM
Subject:   Re: Hop problem
The Internet Protocol Time to Live (TTL) field was introduced as a way of
detecting and supressing loops.  Ideally, a packet would be timed as it passes
from source host through gateways, packet switches, satellite links and to the
destination, and further within the destination while awaiting fragments for
reassembly in the IP layer.  Since clocks are not yet universally syncronized,
the only thing we see being done is decreasing the TTL within each gateway.
The IP spec. states that a gateway must decrease this field by at least 1
(otherwise it could possibly live forever).

Now, when the TTL is viewed as a field decremented by each gateway a packet
passes, it appears to be a hop count field.  Packet radios or packet switches
are actual hops in a network, but do not alter the TTL field, even though we
sometimes saw queueing delays in the Arpanet in the 10-20 second range.

      packet-radio people are talking about ... a 30+ hop routing

I think Phil Karn said something about that path being only about 10 seconds
long.  Also, I expect that the radio hops were not doing gateway functions, so
they did not count the IP TTL field.

mike
-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 88 16:27:41 GMT
From:      jqj@hogg.cc.uoregon.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Time synchronization and distribution plan

As a matter of principal, I don't think it is appropriate to design a
time synchronization system for longterm use as strictly hierarchical.
That makes it too susceptible to Byzantine failures on the parts of
nodes high in the hierarchy, that cause problems for very large
subtrees.  It would make the time synchronization system particularly
inappropriate in a military/tactical environment, for example.
Although one may not like the specific algorithms, I prefer the Cornell
(Schneider, Toueg, etc.) approach, that attempts to achieve consensus
among a set of peers at any level.

For practical purposes, it is probably acceptable to model the system
as a hierarchy of SETS of time servers, each set having 5 to 10
members.  Presumably, algorithms can be chosen to insure that the
probablility of Byzantine failure of the whole SET is acceptably low.
However, this implies that we should design a system in which the
core/primary timeservers expect to be queried not by a large number of
mutually independent secondary servers, but by a large number of
members of sets of secondaries.  For example, we might have a set of
secondaries on a given regional network all of whom attempt to achieve
consensus among themselves but who also all query the primaries as a
time reference.  Note that it implies also that any given secondary
must plan to query several primaries (to detect Byzantine failures in
the primaries).  Correspondingly, it implies more network traffic
unless we are careful in the placement of servers.

I think this suggests at least a 3-level rather than 2-level hierarchy
of time servers, where level 3 is generally individual networks or small
groups of such networks, and level 2 is large (wellconnected) subsets of
the whole Internet.

Comments?

P.S. I would also like to see more thought given to how we should cope
with situations in which the radio timebases are inaccurate or inconsistent.

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 88 20:26:05 GMT
From:      carrs@TROUT.NOSC.MIL (Stephen M. Carr)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell

-------
Ladies/Gentlemen,
 
1.  We are about to lay the keel for networking at this command
and we must devise a game plan for MILNET and local TCP/IP
interconnectivity.
 
2.  Among other incompatibilities, we have some unknowns in the
form of a WANG VS-300, a community within the command that has
procured and started installation of an ARCNET with I believe
Novell Netware, and many Honeywell DPS-6 minicomputers.
 
3.  My objective is to try to implement an IEEE 802.3 Ethernet as
a backbone network gatewayed into a MILNET PSN.  All other
networks in the command would be gatewayed into this backbone
Ethernet.  This backbone Ethernet would have no hosts directly
connected to it, only gateways.  The networks with hosts directly
connected would be subnets.  This is the game plan that Mike
Karels, UC Berkeley suggested to me at the UNIX Berkeley
Networking symposium at Techmart that Advanced Computing
Environments held in August 1987.  I have to believe that he
knows what he is talking about.
 
4.  My problem is that we are complete neophytes when it comes to
TCP/IP internet as well as local networking.  We cannot afford to
spend a lot of taxpayer funds making lots of mistakes trying to
learn what is going on.
 
5.  Unfortunately, we are confronted with several problems.
    a.  The command has a WANG VS-300 which I don't know how we
are going to connect via TCP/IP.  Is there anybody out there that
can tell me if there is a TCP/IP solution out there or in the
wings for a WANG VS-300?  The vendor is promising the moon, but
WANG sales representatives promised me this same moon about 12
months ago.  They are going to brief us on Tuesday, 26 January
1988 with their latest promises.  I would sure appreciate some
straight skinny from any other users out there that have any
experiences with getting a WANG VS-300 singing on the internet!
I would like to go to this meeting armed with comments from this
forum if at all possible.
    b.  Some forces within the command that are concerned with
PCs have procured and are already installing an ARCNET with
Novell Netware.  I don't know much about ARCNET, and I seem to
remember seeing some comment about it about 2 months ago in this
forum.  I see no evidence to indicate to me that you can get the
ARCNET/Novell Netware to interoperate via TCP/IP at the present
time.  Again, any comments from users having experience in trying
to get the ARCNET to sing along with TCP/IP in an internet
environment would be most appreciated.
    c.  We have some 18 or more Honeywell DPS-6s in this command
that we are going to have to internet also.  There are already a
few IEEE 802.3 Ethernets installed on aircraft carriers servicing
the DPS-6 hardware onboard.  My understanding is that this is
actually Bridge Communications Corporation's IEEE 802.3
hardware/software with a Honeywell label on it.  In any event, we
as a CDA (Central Design Agent) must be able to emulate this
Ethernet environment on our aircraft carriers.  Problem!  I
understand that they have implemented XEROX XNS in this IEEE
802.3 environment vice TCP/IP.  Does anybody make a gateway or
protocol converter that will allow Honeywell DPS-6s singing XNS
on an Ethernet to communicate TCP/IP with the internet?
 
6.  We seem to be off to the races with all of the hardware and
software necessary to build our own Tower of Babel.  My objective
is to somehow, some way, see if we cannot get all of this to
interoperate via TCP/IP and the MILNET.
 
7.  Many thanks to the dozen or so folks that responded to my
plea for help on KERMIT for the Honeywell DPS-6!  We did draw
down the object code, but for some reason, the source is not
available.  We seem to be making progress as a result of your
help.  Your immediate response was most appreciated!
 
8.  Any suggestions, comments, or recommended alternatives
regarding our TCP/IP internetworking dilemma will be most
appreciated.
 
                       Very Respectfully,
                           Steve Carr
                          LCDR, SC, USN
 
Navy Management Systems Support Office (Code 42A)
Naval Air Station
Norfolk, Virginia 23511-6694
 
MILNET:  carrs@trout.nosc.mil
MILNET:  navmasso42a@nardacva.arpa
(804) 445-2171, 445-1595 (extension 36)
AUTOVON:  565-2171, 565-1595 (extension 36)
-------

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 88 20:46:15 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Time synchronization and distribution plan

jqj,

While I can understand your concern about Byzantine agreement, there may
never be enough primary servers that everybody can play with very many of
them, so I think we are stuck with a hierarchy, even if we quibble on the
number of strata (to borrow the telephonic term). I am concerned about
broken radio clocks, hosts, networks and leap-seconds, as witness the
experiments I reported in RFCs 956-958 which were repeated recently with
interesting results. I have no problem in organizing subsets of clocks
which might run Byzantine algorithms in order to determine the truthtellers
and falsehood speakers; however, my main concern is the accuracy and
stability of the basic time service itself. I have taken a statistical
approach which attempts to maximize the quality of the data using signal
filtering and smoothing techniques which detect and discard outlyers
due to broken clocks and are based on the assumption that at least half
the clocks are tracking the same random variable and the rest are uniformly
distributed over the observation interval (see RFC-956). These algorithms
have been extensively simulated and tested in prototype implementations
now running and have proved extremely resilient to noisy networks, broken
clocks and jittery gateways but not, I admit, to broken programmers.

Dave

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 88 02:05:00 GMT
From:      W8SDZ@SIMTEL20.ARPA (Keith Petersen)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell

Steve, I saw your note in the TCP/IP newsgroup and I think we have
what you need to run TCP/IP on ARCNET.  The following files are
available via standard anonymous FTP from SIMTEL20:

Filename			Type	 Bytes	 CRC

Directory PD1:<MSDOS.PCIP>
BOOTP.ARC.1			BINARY	 15088  6A80H
DOC.ARC.1			BINARY	622913  53C7H
INCLUDE.ARC.1			BINARY	 38768  D21FH
INSTALL.BAT.1			ASCII	  2354  9BC2H
PCIP-DIS.TXT.1			ASCII	  2334  19ACH
PPP.ARC.1			BINARY	  6768  407BH
README..1			ASCII	  4931  DF58H
ROOT.ARC.1			BINARY	  8494  5070H
SRCCMD.ARC.1			BINARY	228864  F269H
SRCDEV.ARC.1			BINARY	  6768  6298H
SRCLIB.ARC.1			BINARY	331417  C8C3H
TARREAD.EXE.1			BINARY	 17704  D35AH
WATCH.EXE.1			BINARY	 34304  E21FH

The files above are the CMU PCIP package.  In addition to those you
will need the ARCNET-specific files (be careful when extracting as
some member filenames are the same as those in other ARCs).

Filename			Type	 Bytes	 CRC

Directory PD1:<MSDOS.ARCNET-PCIP>
ARCNET.ARC.1			BINARY	 19889  4B5CH
ARCNET-RFC.TXT.1		ASCII	  5622  E04CH
CUSTOM.ARC.1			BINARY	 16061  8391H
INCLUDE.ARC.1			BINARY	  9294  7B81H
INTERNET.ARC.1			BINARY	 17017  A921H

Here is a message from the author of the ARCNET version.  Please
contact him for further details.

Date: Saturday, 9 January 1988  23:46-MST
From: Philip A. Prindeville <PAP4@AI.AI.MIT.EDU>
To:   w8sdz@SIMTEL20.ARPA
Re:   New Release of KA9Q TCP/IP Package

I saw your posting to pcip about ka9q.  I've used simtel20.arpa many
times, and I very much appreciate it's function.  It the same spirit
(I hope), I've done some work on the mit/cmu pc/ip that I think many
people will find use for, including fragmentation and reassembly in
IP, support for ARCnet hardware, and currently a supdup.sys console
driver for ms-dos and multiple connection tcp.

-Philip

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 88 02:55:45 GMT
From:      gt-eedsp!emory!km@gatech.edu  (Ken Mandelberg)
To:        tcp-ip@sri-nic.arpa
Subject:   KA9Q TCP/IP on a Mac?
I just tried running the current release of KA9Q TCP/IP
(fresh off of simtel20) on a Mac. Specifically it was
a Mac Plus with 1 Meg of memory, running System 4.2 and
Finder 6.0.

The TCPIP program comes up with a console window and a 
KA9Q logo and prompt, which immediately line feeds itself
up and off the screen (with no input from the keyboard).
The program is unresponsive and the Mac has to be rebooted.

Any suggestions?
-- 
Ken Mandelberg      |  {decvax,sun!sunatl,gatech}!emory!km  UUCP
Emory University    |  km@emory                             BITNET
Dept of Math and CS |  km@emory.ARPA                        ARPA,CSNET
Atlanta, GA 30322   |  Phone: (404) 727-7963
-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 88 03:24:52 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: Hop problem

The Internet Protocol Time to Live (TTL) field was introduced as a way of
detecting and supressing loops.  Ideally, a packet would be timed as it passes
from source host through gateways, packet switches, satellite links and to the
destination, and further within the destination while awaiting fragments for
reassembly in the IP layer.  Since clocks are not yet universally syncronized,
the only thing we see being done is decreasing the TTL within each gateway.
The IP spec. states that a gateway must decrease this field by at least 1
(otherwise it could possibly live forever).

Now, when the TTL is viewed as a field decremented by each gateway a packet
passes, it appears to be a hop count field.  Packet radios or packet switches
are actual hops in a network, but do not alter the TTL field, even though we
sometimes saw queueing delays in the Arpanet in the 10-20 second range.

      packet-radio people are talking about ... a 30+ hop routing

I think Phil Karn said something about that path being only about 10 seconds
long.  Also, I expect that the radio hops were not doing gateway functions, so
they did not count the IP TTL field.

mike

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 88 03:36:27 GMT
From:      van@LBL-CSAM.ARPA (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   new version of tcpdump available

There's a new version of tcpdump (v1.17) available for anonymous
ftp from internet host lbl-rtsg.arpa (128.3.254.68), compressed
tar file tcpdump.tar.Z.  There are no major changes but several
bug fixes and a couple of new flags.  In addition to the tcpdump
update, a couple of new trace analysis awk scripts have been
added.

This version was compiled -fswitch so it should work on Sun-3s
without a 68881.  And no, the source still isn't available (but
will be soon I hope).

 - Van

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 88 03:54:31 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell


    Date: Sun, 24 Jan 1988  19:05 MST
    Cc: tcp-ip@sri-nic.arpa
    From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>

    [ ... ]
    The files above are the CMU PCIP package.  In addition to those you
    will need the ARCNET-specific files (be careful when extracting as
    some member filenames are the same as those in other ARCs).

    Filename			Type	 Bytes	 CRC

    Directory PD1:<MSDOS.ARCNET-PCIP>
    ARCNET.ARC.1			BINARY	 19889  4B5CH
    ARCNET-RFC.TXT.1			ASCII	  5622  E04CH
    CUSTOM.ARC.1			BINARY	 16061  8391H
    INCLUDE.ARC.1			BINARY	  9294  7B81H
    INTERNET.ARC.1			BINARY	 17017  A921H

I will take this chance to clarify a few things (my fault: I was
too lazy to write a README).  The ".ARC" extension means ARChive,
the format the files are grouped as; previous users of SIMTEL20
will recognize this.  The first two files above are the device
driver for an ARCnet interface (PDI, DATAPOINT, or SMC) and the
accompanying RFC that describes IP over ARCNET.  CUSTOM includes
some generic modifications to support memory (not IO) mapped
devices (which ARCNET IFs tend to be).  INCLUDE and INTERNET
are changes to the standard distribution that offer increased
functionality to IP and ICMP -- some of that functionality was
required to support ARCNET, but is not ARCNET specific.  For
instance, fragmentation/reassembly had to be added to get decent
performance out of ARCNET, but will work equally well with
pronet, ethernet, and token ring.  The files in INCLUDE, INTERNET,
and CUSTOM are meant to replace their counterparts in the CMU
distribution in \INCLUDE, \SRCLIB\INTERNET, and \SRCCMD\CUSTOM
respectively.  You may want to back up these files before
replacing them.

Enjoy,

-Philip

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 88 04:43:55 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell


    [ ... ]
    forum.  I see no evidence to indicate to me that you can get the
    ARCNET/Novell Netware to interoperate via TCP/IP at the present
    time.  Again, any comments from users having experience in trying
    to get the ARCNET to sing along with TCP/IP in an internet
    environment would be most appreciated.

Your assumption about TCP/IP & NETWARE co-existance is correct: they
don't (at this time).  The actual standard for IP over ARCNET is
quite new.  You can get a copy of my draft RFC as "pub/arcnet.rfc"
on the host gmu90x.gmu.edu (via anonymous/ftp).  John Romkey of
FTP Software, Inc. devised a standard LLC level access method for
applications to access a network interface that is not datalink
or hardware dependent (see the PCIP archives for details).  Novell
supports this interface for several network types (including
ethernet), and could be convinced to support it on ARCnet as well
(if you have the bucks to make it worth their while).

I had intended to write such a driver myself, but haven't had time.
Should someone care to provide me with such software, I will make
a version of PCIP to utilize it concurrently with Netware.

Lastly, ARCNET packets do contain sufficient information to
demultiplex IP and Netware protocols, so they can be run over
the same wire.

Good luck in resolving you situation,

-Philip

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Jan 88 11:44:43 EST
From:      Steve Carmody <STC@BROWNVM>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   ip router for appletalk/pc-network (broadband) or token ring
I'm looking for an IP router to connect appletalk (twisted pair network)
to pc-network channel on a broadband system. Such a unit would probably
be built on a PC of some sort. In PC's, PC Network cards
and token ring cards have the same software interface,  so something
that connected appletalk to token ring could probably be
made to work.

Does any one have/know of a router that connects to these two media?
Does anyone have code for a PC that drives IP into any of the
Appletalk cards that are available for PC's?

thanks for any help or information.
-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 88 08:10:45 GMT
From:      macg@alberta.UUCP (Mike MacGregor)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Bulk data transfer



This is my second attempt at posting this:

Does anyone have a bibliography on bulk data transfer protocols handy ?
( Bulk data = at least 50 Mbits, more like 200 Mbits )
How about past experiences/attempts, etc., particularly on LANs ?
Mail direct - I'll summarize for the net if response warrants.


uucp:  macg@alberta                            Innately analog: (403)432-3978
ean:   macg@pembina.alberta.cdn
disclaimer: I'm saving all my opinions for my thesis.

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 88 13:46:29 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Time synchronization and distribution plan

This discussion concerning time synchronization is interesting but I must be
missing the point somewhere.  For the dissemmination (sp) of message traffic
I fail to see why it is important to be synchronized within 1 or 2 milliseconds.

If time is important, such as for real-time ranging data, it would seem that
one should purchase a WWV receiver and interface which ain't all that expen-
sive.  The biggest problem will be clock "jitter" introduced by programmers
like myself who used the JFFO (DECSystem 10) instruction to decode the 48
bit BCD milliseconds since start of year for timestamping real-time data.
The cause of the "jitter" was a side effect of the JFFO instruction which
should have been found immediately except everyone was impressed by an
actual use for the JFFO instruction.

I digressed.  The solution is sites and subnets with "real-time" requirements
should have their own WWV receivers with only "nominal" pinging of the net to
verify the WWV receiver has not failed.  The rest can use their time of day
clocks since time isn't that important.

Merton Campbell Crockett

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 88 15:35:10 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Time synchronization and distribution plan

Merton,

I don't know where you are as the ionosphere flies, but in my corner of this
world I sure would not trust my WWV receiver to stamp my archives. I would
trust my WWVB receiver rather more, except just now even that signal has
dropped below the floor and the clock is almost a second off. I did in
fact suggest exactly the model you mention, using a more-or-less reliable
local radio clock and verifing sanity with nominal pinging of its friends.
Now, about the protocol to accomplish those pings...

I started in this hokey business mostly to support accurate performance
measurement and analysis of the Internet; however, as time ticked on it
became an end in itself and lots of fun as well. Maybe you don't care about
time to the millisecond, but then you probably don't do any computerized
trading, wide-area monitoring and so forth. For example, with the system
now in place I have been able to compare timestamped error reports collected
from several packet switches and merge them into a scenario accurate to
within the flight time of packets between switches.

Last night I killed first one radio clock and then another untill all WWVB
primary radio clocks were disabled. I verified all the primary and secondary
time servers switched their hierarchical allegance until the ultimate backup
WWV clocks at U Michigan and U Delaware kicked in. So far as I could tell,
all time servers maintained synchronization to within a few tens of
milliseconds throughout the experiment. However, in this case all clocks
were observably sane. The next experiment is to insanitize a couple of them
and verify the rest toss them out of the club.

Dave

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 88 16:21:00 GMT
From:      stev@ftp.COM (Stev Knowles)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell

In article <315728.880124.PAP4@AI.AI.MIT.EDU>, PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") writes:
> 
>     [ ... ]
>     forum.  I see no evidence to indicate to me that you can get the
>     ARCNET/Novell Netware to interoperate via TCP/IP at the present
>     time.  Again, any comments from users having experience in trying
> Your assumption about TCP/IP & NETWARE co-existance is correct: they
> don't (at this time).  The actual standard for IP over ARCNET is
> 
> -Philip

sorry, but i was under the impression that Novell offered a card for their
file server (a micom interlan NP-600) that allowed for tcp-ip access from any
novell netware to a tcp-ip ethernet. i am under the impression that they
are running tcp-ip buried inside their own packets, and the file server 
is stripping them out and passing them to the NP600. i have seen this 
work for ethernet, and was under the impression that it worked for all the 
networking schemes that novell supported.

stev knowles
ftp software inc.
617 868 4878

/*
all comments are mine
*/

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 88 18:24:48 GMT
From:      halley!bc@im4u.utexas.edu  (Bill Crews)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TLI and Sockets
In article <349@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes:
>
>Is there anything that would make a program running on a System V
>Release 3 machine, using TLI, to communicate with a program running
>on a machine using Sockets?

Sockets and TLI are *interfaces*, not protocols.  Socket-based and TLI-based
applications intercommunicate all the time with no problem.  In fact, many OSes
on the Internet have neither sockets nor TLI and still intercommunicate.

-bc
-- 
Bill Crews                                   Tandem Computers
bc@halley.UUCP                               Austin, Texas
..!rutgers!im4u!halley!bc                    (512) 244-8350
-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 88 18:27:47 GMT
From:      hassler@nap1.arpa (Barry D. Hassler)
To:        comp.protocols.tcp-ip
Subject:   Re: IP class B and C to X.25 address translation



Its been some time since I sent out my original message  concern-
ing  the subject, and I have received a few responses to my ques-
tion, but noone answered the question I asked (maybe I  asked  it
poorly).

My original question concerned the translation from IP  addresses
to  X.25  addresses for X.25 links, such as those on MILNET (each
answer I received told me about subnetting,  which  I  do  under-
stand).   The X.25 standard used by DDN contains an appendix out-
lining the address translation, but it only  works  properly  for
Class   A  addresses.  The  algorithm  itself  can  be  found  in
NETINFO:X25.DOC.1 on sri-nic.arpa.

The algorithm used is as follows (copied out of X25.DOC, appendix
A):

------------------------------------------------------
                              A-8
A-5 Derivation of DDN  X.25 Addresses

        All DDN hosts are assigned addresses by the Administration.
  The address of a DDN host may be obtained from the Network
  Information Center (NIC), represented as an ASCII text string in
  what  is  called "host table format".  This section describes the
  process by which DDN X.25 addresses in the format described in
  Section 2.1.1 may be derived from addresses in NIC host table
  format.

        A NIC host table address consists of the ASCII text string
  representations of four decimal numbers separated by periods,
  corresponding to the four octets of a thirty-two bit Internet
  address.  The four decimal numbers are referred to in this
  section as "n", "h", "l", and "i."  Thus, a host table address
  may be represented as "n.h.l.i"  Each of these four numbers will
  have either one, two, or three decimal digits and will never have
  a value greater than 255.  For example, in the host table address
  "10.2.0.124", n=10, h=2, l=0, and i=124.  To convert a host table
  address to a DDN X.25 address:

        1.  If h < 64, the host table address corresponds to
            the DDN X.25 physical address

                           ZZZZ F IIIHHZZ (SS)

            where:

                 ZZZZ = 0000
                         as required in Section 2.1.1.1.1;

                 F = 0   because the address is a physical
                         address;

                 III     is a three decimal digit
                         representation of "i", right-adjusted
                         and padded with leading zeros if
                         required;

                 HH      is a two decimal digit representation
                         of "h", right-adjusted and padded
                         with leading zeros if required;,

                 ZZ = 00
                         and

                 (SS)    is optional, as described in Section
                         2.1.1.1.4.




                              A-9
          In the example given above, the host table address
          10.2.0.124 corresponds to the DDN X.25 physical
          address 000001240200.

      2.  If h > 64 or  h  =  64,   the  host   table  address
          corresponds to the DDN X.25 logical address

                      ZZZZ F RRRRRZZ (SS)

          where:

               ZZZZ = 0000
                      as required in Section 2.1.1.1.1;

               F = 1  because the address is a logical
                      address;

               RRRRR  is a five decimal digit
                      representation of the result "r" of
                      the calculation

                                 r = h * 256 + i

                      (note that the decimal representation
                      of "r" will always require five
                      digits);

               ZZ = 00
                      and

               (SS)   is optional, as described in Section
                      2.1.1.1.4.

          Thus,    the host    table   address    10.83.0.207
          corresponds   to  the  DDN  X.25  logical  address
          000012145500.

     In both cases, the "n" and "l"  fields  of  the  host   table
address are not used.

-------------------------------------------------------------
Note that while this algorithm can be used on class B and  C  ad-
dresses,  it  maps  out  to  duplicate X.25 addresses for certain
Class B and C addresses, since it only  takes  into  account  the
second and fourth octets of the address.

Are there any other standards being  used  for  this  translation
that  will provide a one-to-one mapping of both class B and C ad-
dresses to X.25 addresses?  I am running a quickly  growing  net-
work  of  hosts,  and have receiveed several requests already for
X.25 connections to our gateway.  I am very  concered  about  the
address translations for our class B network addresses (subnetted
of course). I use portions of the third octet (depending upon the
size  of  the subnet, and whether or not it needs to be subnetted
further) for the subnetwork number and find that that octet  does
not  enter in the X.25 address at all. Therefore, If I would have
two X.25 hosts behind my gateway with  addresses  129.48.1.1  and
129.48.32.1,   they  would  both  have  the  same  X.25  address:
000011228900.

-BDH

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 88 20:16:36 GMT
From:      clyde!watmath!grand!jwkhong@rutgers.edu  (James W. Hong)
To:        tcp-ip@sri-nic.arpa
Subject:   TCP/IP references
I am currently working on implementing TCP/IP on an experimental distributed
operating system.  I intend to communicate with TCP/IP on BSD 4.3 UNIX
systems.  Could someone direct me to tutorials or references (other than
RFCs)regarding implementation of TCP/IP?

Thanks in advance

James W. Hong
Dept. of Computer Science
University of Waterloo
519-885-1211 x6178
-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 88 23:56:41 GMT
From:      chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   Banyan TCP/IP bridge

Good afternoon,
		Has anyone heard of(or did I just imagine it...) Banyan offeringa TCP/IP software bridge for their PC stuff? I remember reading about the
proposed product but was wondering is it yet released and, if so, what's the
feel of this particular animal?
			Thanks for any comments you may have,
							Chris VandenBerg
							ACC
							(chris@acc-sb-unix.arpa)   

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 88 01:35:00 GMT
From:      Hampton@DOCKMASTER.ARPA ("David R. Hampton")
To:        comp.protocols.tcp-ip
Subject:   BSD and IP options

I ran into similar problems last October when working with options in
4.2 BSD.  I believe I had to patch both the fragmentation and reassenbly
routines to get things running.  The most common problem I found was
references to the size of a 'standard' IP header [sizeof(ipasfrag)],
instead of references to the size of the current datagram's header
[ip->ip_hl*4].  If you need more specifics, drop me a note and I'll look
them up.

David

+--------------------------------------------------------------+
| David R. Hampton                      Ma Bell:(301) 859-4537 |
| Hampton @ Dockmaster.ARPA                                    |
 +--------------------------------------------------------------+

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 88 08:47:27 GMT
From:      garcia@TSCA.ISTC.SRI.COM
To:        comp.protocols.tcp-ip
Subject:   NEW CALL FOR PAPERS--SIGCOMM 88


Enclosd is the call for papers for SIOGCOMM 88.  Please note the new
deadline for paper submission of MARCH 19.  The event will be a
symposium consisting of paper sessions and panel sessions organized in
one track at a time.  We are planning to have the final version of the
proceedings available at the conference (for those of us still waiting
for the SIGCOMM '87 proceedings this could be an added incentive).

Please contact Prof. Landweber at your earliest convenience to arranage 
paper submissions or panel sessions.

JJ
----------

                              CALL FOR PAPERS
                        ACM SIGCOMM '88 SYMPOSIUM
                Communications Architectures and Protocols

                     Stanford University, California
                            August 16-18, 1988

The symposium provides an international forum for the presentation and
discussion of communication network applications and technologies, as
well as recent advances and proposals on communication architectures,
protocols, algorithms, and performance models.  Authors are invited to
submit full papers concerned with both theory and practice.  The areas
of interest for the symposium include, but are not limited to the
following: analysis and design of computer network architectures and
algorithms, innovative results in local area networks,
computer-supported collaborative work, network interconnection and
mixed-media networks, high-speed networks, resource sharing in
distributed systems, distributed operating systems and databases,
protocol specification, verification, and analysis.

Papers should be about 20 double-spaced pages long and should have an
abstract of 100-150 words.  All submitted papers will be reviewed and
will be judged with respect to their quality and relevance.  Authors of
selected papers will be expected to sign an ACM copyright release form.
The Proceedings will be distributed at the symposium and published as a
special issue of SIGCOMM Computer Communication Review.  A few of the
submitted papers will be selected for publication in the ACM
Transactions on Computer Systems.  

Submit 5 copies of each paper to the program chairman: Dr.  Lawrence H.
Landweber, Computer Sciences Department, University of
Wisconsin-Madison, 1210 West Dayton Street, Madison, Wisconsin 53706,
USA; Telephone: (608) 262-1204; EMAIL: lhl@parmesan.wisc.edu.

For more information about the symposium, contact 
Dr. J.J. Garcia-Luna, General Chair, SRI International, 333
Ravenswood Ave., EK 319, Menlo Park, CA 94025, USA; Tel: (415)
859-5647; EMAIL: garcia@tsca.istc.sri.com; telex: 33486.

                         STUDENT PAPER AWARD

Papers submitted by students will enter a student-paper award contest.
Among the accepted papers, a maximum of four outstanding papers will be
awarded (1) full conference registration and (2) a travel grant of
$500.00 US dollars.

                          IMPORTANT DATES

Deadline for paper submission: March 19, 1988 (NEW DEADLINE!)
Notification of acceptance:  April 20, 1988 
Camera-ready manuscript due: May 18, 1988 

                         SYMPOSIUM COMMITTEE

General Chair:  J.J. Garcia-Luna-Aceves, SRI International, USA 
Program Chair:  L.H. Landweber, University of Wisconsin-Madison, USA 
Local Arrangements: E. Feinler, SRI International, USA, and 
                    D. Cheriton, Stanford University, USA
Tutorials Chair: N. Shacham SRI International, USA

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jan 88 14:02:16 EST
From:      Bob Dixon <TS0400%OHSTVMA.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Banyan TCP/IP bridge
As of the latest release of Banyan VINES software, a Banyan server will do
IP routing between any interconnection of Banyan servers and associated
micros. It will pass VINES packets inside IP packets to enable server-to-
server communications, if desired. Micros may be connected via either
token ring or ethernet to the server, and must at present use FTP, inc
software for tcp/ip communications. Banyan is now offering a server license
for FTP software which saves considerably in the $ dept.
 Banyan plans to incorporate the FTP software into the server, making it part
of VINES, and hence more integrated for the user. Also, a gateway between
the Banyan mail system and SMTP is under development.
 Now if only all this were available "today".

                                             Bob Dixon
                                             Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1988 1524-EST
From:      jpcodes@TYCHO.ARPA  (Jim P. Codespote)
To:        tcp-ip at sri-nic.arpa
Subject:   Questions on MIL-STD-1778 (TCP)


     I am trying to implement TCP in Ada.  I am following the Military
Standard 1778 and I am having trouble following some of the events and actions.

My problem is what happens in a "net deliver" in an established state? (9 

     I found that the decision table is switched with the "net deliver" table
in the close wait state.  Assuming I am useing the right table now, what should
happen when;  seq num status is valid, 	
$OA
-------

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1988 1557-EST
From:      jpcodes@TYCHO.ARPA  (Jim P. Codespote)
To:        tcp-ip at sri-nic.arpa
Cc:        jpcodes
Subject:   Questions on MIL-STD-1778 (TCP).

     I am trying to implement  TCP in Ada.  I am following the Military
Standard 1778 and I am having some trouble in understanding it.  My problem
is what happens in a "net deliver" in an established state? (9.4.6.1.5)

     I found that the decision table is switched with the "net deliver"
table in the close wait state.  Assuming I am using the right table now,
what should happen when;  seq num status is valid, rst is on, sec prec
match is yes, syn in window is no, and ack status test2 is none?  Does
this mean only data is being delivered?  If so, why does the standard
say "no action"?  Or, does this mean the only way data gets accepted is
if the segment contains an "ack"?

     Is the standard in error or am I just missing the point?  I would
greatly appreciate any suggestions.  Thank you.


     Please respond at jpcodes@TYCHO.ARPA


  Jim Codespote
-------

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 88 10:57:17 GMT
From:      ihnp4!tapa!larry@ucbvax.Berkeley.EDU  (Larry Pajakowski)
To:        tcp-ip@sri-nic.arpa
Subject:   Whither Prime 63xx TCP/IP
We are looking for TCP/IP and Ethernet support for a Prime 63xx (6355?)
computer.  This is about our last hope else its going to be RS-232.

	Thanks
	Larry Pajakowski
	ihnp4!tapa!larry
-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 88 12:44:08 GMT
From:      backman@interlan.UUCP (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell

>>     [ ... ]
>>     forum.  I see no evidence to indicate to me that you can get the
>>     ARCNET/Novell Netware to interoperate via TCP/IP at the present
>>     time.  Again, any comments from users having experience in trying
>> Your assumption about TCP/IP & NETWARE co-existance is correct: they
>
>sorry, but i was under the impression that Novell offered a card for their
>file server (a micom interlan NP-600) that allowed for tcp-ip access from any
>novell netware to a tcp-ip ethernet. i am under the impression that they
>are running tcp-ip buried inside their own packets, and the file server 
>is stripping them out and passing them to the NP600. i have seen this 


	[]
		Disclaimer - I am prejudiced, this is my product.

	Micom - Interlan is shipping a Netware\TCP gateway.  The gateway
	consists of an NP600 board placed within the file server.  This
	board runs our standard TCP image.  The gateway also consists of
	processes within the file server that act as daemons (FTPD, RWHOD,
	SMTPD, etc.).  An additional process, the NETBIOS listener, is used
	to communicate with workstations.

	Workstations ( up to 31) talk to the file server and ultimately the
	gateway via NETBIOS.  Application programs (FTP, TELNET et. al)
	ported from Bsd 4.3 encapsulate socket calls within NETBIOS NCB's
	and send the socket calls to the gateway where they are passed to
	the NP600.  There are no TCP packets  encapsulated within Netware
	IPX packets, instead socket calls are encapsulated within NETBIOS
	RPC's.

	Any Novell supported subnet can talk to TCP hosts using the gateway.
	I have seen it running on at least 6 different types of media,
	including ARCNET, and assume that it is running on at least another
	6 types.

	For more information, please contact me directly.


						Larry Backman
						Micom - Interlan

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 88 13:05:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Hop problem

Mike,

the "packet radio" referenced was not the DARPA packet radio but the
amateur packet radio. I don't know how those systems handle the TTL
field. The DARPA packet radio system didn't pay any attention to TTL
except at gateways since the packet radio net was "below" the IP 
protocol level. The amateur system, however, probably operates at the IP 
level like some of the more recent combined packet switch/gateways such
as the Proteon 4200, Cisco boxes, and so on.

Vint

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 88 13:09:15 GMT
From:      Staff.Hershman@KL.GBA.NYU.EDU (Ittai Hershman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell


    Date: 25 Jan 88 16:21:00 GMT
    From: spdcc!ftp!stev@husc6.harvard.edu  (Stev Knowles)
    Organization: FTP Software Inc., Cambridge, MA
    Subject: Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell

    > Your assumption about TCP/IP & NETWARE co-existance is correct: they
    > don't (at this time).  The actual standard for IP over ARCNET is
    > 
    > -Philip

    sorry, but i was under the impression that Novell offered a card for their
    file server (a micom interlan NP-600) that allowed for tcp-ip access from any
    novell netware to a tcp-ip ethernet. i am under the impression that they
    are running tcp-ip buried inside their own packets, and the file server 
    is stripping them out and passing them to the NP600. i have seen this 
    work for ethernet, and was under the impression that it worked for all the 
    networking schemes that novell supported.

    stev knowles

The Micom-Interlan TCP Gateway will work with any Novell supported
networking schemes, but does not run TCP directly to the client PCs.
The way it works is that the server contains whatever card is used to
talk to the clients (eg: ethernet, starlan, arcnet (I suppose)), and
additionally an NP600A (with a chip serialized to the TCP Gateway
software).  Communication between client and server is done using the
Novell protocol and then converted to TCP/IP by the server and sent to
the ethernet backbone via the NP600A.

This has the added interesting property that only a single IP number is
needed for up to 32 simultaneous client PCs, making the administration
of "subnets" (I mean it in the sense of a PC lab, or a floor of offices)
much easier.  It is also very cost effective, because you can buy very
cheap networking cards (Starlan in my case) for the client PCs.  On the
negative side, some speed is obviously lost to the gatewaying.

-Ittai
-------

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 88 13:13:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell

NOVELL Netware and TCP/IP have been made to interoperate by Novell.
My understanding of the method is that the file server in the
Novell Netware system also has TCP/IP implemented. A user's PC
forms a connection using Netware to a server process in the
machine that also runs the file server and that process permits
a TCP/IP connection to be formed going to the desired destination.

I do not know any of the details of the software or how one conveys
the desired IP destination to the TCP/IP server. It may behave like
TELNET piggybacking (where you log into a host and TELNET back out
again, specifying where you want to go to the User Telnet).

Vint Cerf

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 88 15:47:26 GMT
From:      morrison@accuvax.nwu.edu.UUCP (Vance Morrison )
To:        comp.protocols.tcp-ip
Subject:   Re: Banyan TCP/IP bridge


Hello,

	Yes Banyan has anounced that it will be offering TCP/IP capabilities
in its PC server.  Unfortuately the product is not out yet.  It was 
originally scheduled for release in late December, but now it looks like
it will be out this April (but don't hold your breath).  

	The TCP/IP capability is part of release 3.0 of Vines and Banyan has
literature describing this and well as other new features of 3.0.  From
what I have been able to discover from my reading, is that Vines has
integrated the TCP/IP protocols into Vines.  This immediately means that Vines
can route IP packets through the Banyan LAN, as well as route Vines packets
across the internet.  

	At present Banyan is not making products that use this new
capability.  Instead it has made deals with others (FTP Software Inc.)
to provide products that will make the TCP capablities useful (namely
telnet, ftp etc).  These user products exist today.  One product that
is conspicuously absent, however is a internet mail bridge that will
link into Banyan's local mail system.  Banyan has provided the hooks 
for doing this, but at present will not release the name of any company
that is working on it.  In its simplest form, this is a simple piece of
software, but without it Banyan's mail system will be cut off from the
rest of the internet, severly limiting its usefulness.

	I have no doubt that such a product will come out, but frankly
it may take a while (> 6 months)


					Vance Morrison
					morrison@accuvax.nwu.edu
					morrison@nuacc.bitnet
					morrison@northwestern.arpa

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 88 17:02:54 GMT
From:      jimp@cognos.uucp (Jim Patterson)
To:        comp.protocols.tcp-ip,comp.lang.c
Subject:   Re: C binding interfaces for TCP/IP

In article <25@vdelta.UUCP> dave@vdelta.UUCP (Dave Arnold) writes:
>Are there efforts underway to standardize a C language interface for TCP/IP?

Sun has developed a definition called RPC (Remote Procedure Call)
which is becoming a defacto standard in some environments. RPC is
designed to support the function-call paradigm across TCP/IP
networks.  Sun has published the protocol to encourage its
implementation on other systems. In conjunction with RPC, Sun has
an excellent protocol called XDR (eXternal Data Representation)
to deal with data conversions between different machine
architectures in a flexible but structured manner.

While I've studied these protocols a bit, I don't have any direct
experience with them. I also don't know if anyone has implemented
them on VAX/VMS systems (but I suspect that this has been done).
You might contact Sun Microsystems to get more information about
RPC and XDR.
-- 
Jim Patterson                              Cognos Incorporated
UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707    
PHONE:(613)738-1440                        3755 Riverside Drive
                                           Ottawa, Ont  K1G 3Z4

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jan 88 0:01:25 EST
From:      Mills@UDEL.EDU
To:        Bob Dixon <TS0400%OHSTVMA.BITNET@cunyvm.cuny.edu>
Cc:        TCP-IP@sri-nic.arpa
Subject:   Re:  Banyan TCP/IP bridge
Bob,

Do you access a Banyon server with a Batcher multiplexor, or is there another
way to giggle the gigabits?

Dave
-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 88 19:02:16 GMT
From:      TS0400@OHSTVMA.BITNET (Bob Dixon)
To:        comp.protocols.tcp-ip
Subject:   Re: Banyan TCP/IP bridge

As of the latest release of Banyan VINES software, a Banyan server will do
IP routing between any interconnection of Banyan servers and associated
micros. It will pass VINES packets inside IP packets to enable server-to-
server communications, if desired. Micros may be connected via either
token ring or ethernet to the server, and must at present use FTP, inc
software for tcp/ip communications. Banyan is now offering a server license
for FTP software which saves considerably in the $ dept.
 Banyan plans to incorporate the FTP software into the server, making it part
of VINES, and hence more integrated for the user. Also, a gateway between
the Banyan mail system and SMTP is under development.
 Now if only all this were available "today".

                                             Bob Dixon
                                             Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 88 19:04:49 GMT
From:      hubcap@gatech.edu  (Mike Marshall)
To:        tcp-ip@sri-nic.arpa
Subject:   pmdf - wollongonkulator
Hello - 

I would appreciate it if anyone who is running WIN/TCP 3.0 and pmdf 2.3
in a VMS environment would be willing to send me a copy of their pmdf.cnf
file. I fooled around with the one here some today, trying to get it to
work a certain way, and I had no luck. I feel like I would have more success
if I had a few examples to go by.

Even if you are not running the exact release levels that we are, I would
appreciate a glance at your pmdf.cnf files...

Thanks all -

-Mike Marshall       hubcap@hubcap.clemson.edu      ...!hubcap!hubcap
-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jan 88 00:14:40 EST
From:      "Philip A. Prindeville" <PAP4@AI.AI.MIT.EDU>
To:        carrs@TROUT.NOSC.MIL
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell
    Date: Mon, 25 Jan 88 10:43:37 CST
    From: timk@ncsa.uiuc.edu (Tim Krauskopf)
    Subject: Re:  TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell

    Our software may be of some help to you and is already paid for by
    various state and federal taxpayers.  It will not be too difficult to
    write an ARCNET driver for the PC version of NCSA Telnet if you can

You can take an existing driver for PCIP and re-write it.  This would be
fairly quick, and save you having to learn a lot about the COM 9026 chip.
I think Keith posted previously about where to get this and the related RFC.

    get just a little help from the company.  Your biggest problem will be
    to find a gateway from ARCNET to Ethernet (802.3) to get out to the IP
    world.  You could use our base to write a simple-minded gateway for an
    AT-class machine and forward all IP to some "smarter" host.

    I know of no other ARCNET TCP/IP gateways. Novell does have a TCP/IP
    [ ... ]

I know of someone who has written an ARCNET driver for KA9Q.  This makes
a fairly decent (albiet low-performance, ~200pkt/sec) gateway.  There
is also a pronet driver floating around, for ARCnet<->pronet...  I'm
not sure about the availability (though it is PD), but if you're
interested, send me mail and I'll put you in touch.

-Philip

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 88 20:24:00 GMT
From:      jpcodes@TYCHO.ARPA (Jim P. Codespote)
To:        comp.protocols.tcp-ip
Subject:   Questions on MIL-STD-1778 (TCP)



     I am trying to implement TCP in Ada.  I am following the Military
Standard 1778 and I am having trouble following some of the events and actions.

My problem is what happens in a "net deliver" in an established state? (9 

     I found that the decision table is switched with the "net deliver" table
in the close wait state.  Assuming I am useing the right table now, what should
happen when;  seq num status is valid, 	
OA
-------

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 88 20:57:00 GMT
From:      jpcodes@TYCHO.ARPA (Jim P. Codespote)
To:        comp.protocols.tcp-ip
Subject:   Questions on MIL-STD-1778 (TCP).


     I am trying to implement  TCP in Ada.  I am following the Military
Standard 1778 and I am having some trouble in understanding it.  My problem
is what happens in a "net deliver" in an established state? (9.4.6.1.5)

     I found that the decision table is switched with the "net deliver"
table in the close wait state.  Assuming I am using the right table now,
what should happen when;  seq num status is valid, rst is on, sec prec
match is yes, syn in window is no, and ack status test2 is none?  Does
this mean only data is being delivered?  If so, why does the standard
say "no action"?  Or, does this mean the only way data gets accepted is
if the segment contains an "ack"?

     Is the standard in error or am I just missing the point?  I would
greatly appreciate any suggestions.  Thank you.


     Please respond at jpcodes@TYCHO.ARPA


  Jim Codespote
-------

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 88 21:00:26 GMT
From:      dan@MITRE-BEDFORD.ARPA (Willhite)
To:        comp.protocols.tcp-ip
Subject:   (none)


We are running a SUN3/60 under SUN UNIX 3.5.  It is on an ethernet LAN connected
by back-to-back gateways to a proprietary LAN.  The proprietary LAN transmits 
TCP/IP utilizing the security option.  From the documentation we have been able 
to uncover, no UNIX implementation utilizes this option.  We have written code 
on The SUNS at the socket level utilizing SUN UNIX without the security options,
but we have determined that they are necessary.  We need to know if there is 
some way, at the socket level, to force SUN UNIX to transmit using security 
options.  Is it also possible to force the option on the system to use top 
secret for all transmissions?

We would also be interested to know if there are any other operating 
environments which DO implement the security option.

Thank you.

Dan
(dan@mitre-bedford.arpa)

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 88 23:02:52 GMT
From:      pogran@ccq.bbn.COM (Ken Pogran)
To:        comp.protocols.tcp-ip
Subject:   Re: IP class B and C to X.25 address translation

Barry,

How about the mapping that Andy Malis suggested in his message of
19 January?

     There is an informal standardization for Class B: the first two
     octets of the IP address are the network number, the third octet
     is treated identically to the second octet of Class A addresses,
     and the fourth octet is treated identically to the fourth octet
     of Class A addresses.  The third octet of Class A addresses is
     dropped completely in Class B addresses.
     
     There is absolutely no standardization for Class C, because there
     are so few local network address bits to play with.  The host
     network software support person for Class C nets must provide his
     or her own mapping between the Class C addresses and X.25
     addresses for that net.  For example, the five most significant
     bits of the fourth octet of the Class C address could be the host
     number, and the three least significant bits the PSN number.  It
     is a compromise between the number of PSNs on the network and the
     maximum number of hosts on a PSN.

We've just put in a small "campus-area" Class B network of C/30
PSNs using this mapping.

If my memory serves me correctly (and it turns out that I'm the
author of the text in the DDN X.25 spec that you quoted -- though
not the originator of the algorithm), an earlier draft of the DDN
X.25 spec contained both Class A and Class B mappings. In review,
it was pointed out to us that since this was a _DDN_ X.25 spec,
and DDN was a Class A network, there was no need for a Class B
mapping in the DDN-specific document.  In retrospect, it would
have been a good idea to put out the Class B mapping as an RFC at
the same time the DDN spec was published!  

I think it's now time to put out that RFC ...

Ken Pogran

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 88 00:03:50 GMT
From:      lyndon@ncc.UUCP (Lyndon Nerenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell

In article <8801242026.AA29303@trout.nosc.mil>, carrs@TROUT.NOSC.MIL (Stephen M. Carr) writes:
>  [...]
> 5.  Unfortunately, we are confronted with several problems.
>     a.  The command has a WANG VS-300 which I don't know how we
> are going to connect via TCP/IP.  Is there anybody out there that
> can tell me if there is a TCP/IP solution out there or in the
> wings for a WANG VS-300?  The vendor is promising the moon, but
> WANG sales representatives promised me this same moon about 12
> months ago.  They are going to brief us on Tuesday, 26 January
> 1988 with their latest promises.  I would sure appreciate some
> straight skinny from any other users out there that have any
> experiences with getting a WANG VS-300 singing on the internet!
> I would like to go to this meeting armed with comments from this
> forum if at all possible.

After having dealt with Wang regarding communications software
on a number of occasions, all I can suggest is that you believe
absolutely NOTHING they say...

I highly doubt Wang will come out with Ethernet at any time. They
have been promising this to us for over two years...

As a result of the above, we decided to purchase their 2780RJE
software to (at least) allow file transfer. As it turns out, their
"IBM Standard 2780 RJE software won't talk to our Convergent
Technologies 2780 RJE package", according to the Wang salesman.
I know the CT software works, but I have been unable to get the
VS65 to talk to it, so I guess (for once) the Wang salesman was
not lying! Of course, I'd really like to know why they didn't tell
us this prior to our purchasing the software (this configuration
was in the spec) ...

I have also been unable to get their X.25 software working in the
same environment. If we could get this to function at least the Wang
users would be able to call out to another host, although this
doesn't even begin to approach the flexibility of having TCP/IP.

We *did* find a solution though. We are scrapping the VS65, and replacing
the workstations with PC/XT's (clones actually) running the Wang WP
under MS-DOS. The clones have a replacement keyboard identical to
the Wang keyboard. The VS65 will be replaced by a Sun 3/280. The
clones will be running PC/NFS, allowing them to share file system
space on the Sun. They can also telnet to any host on the Ethernet
and can ftp files around as well.

The *best* part of all this is the Sun + the PC's + the NFS cards
and all the glue costs 30% less than the VS65 alone...

I know this won't directly solve your problem, but I hope it gives
you (and others) a bit of insight into alternatives to the very
restricted Wang operating environment.

[ Wow, I feel better now :-) ]

--lyndon

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 88 04:38:03 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell


    [ .... ]
    My understanding of the method is that the file server in the
    Novell Netware system also has TCP/IP implemented. A user's PC
    forms a connection using Netware to a server process in the
    machine that also runs the file server and that process permits
    a TCP/IP connection to be formed going to the desired destination.

Well, I meant something more along the lines of each PC being its own
IP host (rather than TCP being a resource a remote server provides [I
hesitate to call the server a translating gateway]) where a user
could have both file service and TCP/IP software (say SMTP), without
the two applications fighting for the interface's interrupt...

-Philip

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 88 07:55:39 GMT
From:      HANK@BARILVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Need help in filling in the gaps

I am trying to compile comparative rate tables for

- the cost of 64kb digital service in various countries
- the cost of a 56/64kb link to the USA or a T1 line to the USA

If you can help me fill in the gaps or have information about a country I
have not included, please send it to me.  Once I have finished the work,
I will repost the final result.

Please reply directly to me and not to the list.

Thanks,
Hank


                   Cost comparison of 64kb digital service
                          in various countries
                   =======================================


Country            5km       10km      200km     500km
----------------+---------+---------+---------+---------+
Austria         |  683.8  | 1025.6  | 4346.2  |  6141   |
Belgium         |  372.5  |  683    | 1652    |  3304   |
Denmark         |  174.6  |  293.9  | 1770.5  |  2139.8 |
France          |  614    |  828.8  | 5241.8  |  6838.6 |
Germany         |  795.2  | 1337.3  | 8385.5  | 11638.6 |
Norway          |  242.2  |  242.2  |  602.5  |   869.6 |
Spain           | 1507.9  | 2356.5  | 4996.9  |  6713.1 |
Sweden          |  332.2  |  387.6  | 2214.8  |  2380.9 |
Switzerland     |  758.8  | 1523.5  | 6604.4  |  8810.3 |
United Kingdom  |  412.6  |  515.3  |  824.3  |  1128.5 |
----------------+---------+---------+---------+---------+
Average         |  589.4  |  919.4  | 3663.9  |  4996.4 |
----------------+---------+---------+---------+---------+

Israel            1823      2136     14011      32761     (<50 lines)
Israel            1077      1077      1077       1077     (>50 lines)

Notes:

1) Rates are in dollars per month.
2) Sources: a) Report #219, "Tariff Analysis - National Digital Services
               at 64kb and 2Mb, Claude Laurens, La Gaude, France,
               December 14th, 1987
            b) Israeli prices based on Sifranet and leased line price
               sheets, Bezek, August 15th, 1987


             International rates for high speed links to the USA
             ===================================================

Country           56/64kb   1.544M
----------------+---------+---------+
UK - MCI        | 4654    |  40540  |
UK - BTI        | 5943    |  45045  |
France          | 6017    |  49557  |
Netherlands     |         |         |
Germany         | 9939    |  86746  |
Belgium         |11500    | 115008  |
Norway          |         |         |
Sweden          |         |         |
Denmark         |         |         |
Japan           |         |         |
Spain           |         |         |
Switerland      | 8823    |         |
Ireland         |         |         |
Israel          |13548    |         |



Notes: 1) All rates are rates for connecting to the east coast in the
          USA.
       2) The rates only reflect half of the cost.  The other half is
          the rate for the link from the United States to the stated
          country
       3) All rates are cost per month in US dollars

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 1988 15:30:13 CST
From:      Link Verstegen@GUNTER-ADAM.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Cc:        LINK@GUNTER-ADAM.ARPA
Subject:   Final Draft of AF LAN Interface/Security Module Specification

	The final draft of the AF LAN Interface/Security Module
Equipment Performance Specification is out for review.  As before,
the document is contained in the file [LAN-EPS]LAN.EPS.1 on the
Gunter-Adam.ARPA.  You can either log into the account and use
kermit or modem to download the file or you can FTP it to your
host.  Again, the account is LAN-EPS and the password is LAN-EPS.

	You can address any comments to LAN-EPS@GUNTER-ADAM.ARPA.
If you have anything you do not wish to share with the rest of the
community, please address them to LINK@GUNTER-ADAM.ARPA.  In either
case, I will promptly respond with the disposition of your comments.

	Of specific interest are the technical issues of using 
Commercial Off The Shelf (COTS) MS-DOS software across a LAN and
the implementation of the security controls.  Any insights on either
portion of the acquisistion are welcomed.  Will it, as proposed,
fit your needs?  The contract award is planned for June 1, 1988, so
we need your comments in the next two weeks or so to get them included.



		    /|                  /|
===================/ |=================/ |===================
 Link N. Verstegen                     Link@Gunter-ADAM.ARPA
 Computer Systems/Network Engineer
 HQ SSC/PRS                               (205)279-5151
 Gunter AFS, AL  36114-6343                AV 446-5151

-------
-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jan 88 14:34:49 EST
From:      Bob Dixon <TS0400%OHSTVMA.BITNET@CUNYVM.CUNY.EDU>
To:        Mills@UDEL.EDU, Bob Dixon <TS0400%OHSTVMA.BITNET@cunyvm.cuny.edu>
Cc:        TCP-IP@sri-nic.arpa
Subject:   Re:  Banyan TCP/IP bridge
Dave,

     I'm not sure I understand your question, but Banyan servers connect to
PC LANs via ethernet, token ring etc. as with any microcomputer net server.
Users on a PC have access to disks on the server by designating them as if
they were local disks on the PC. To deal with the internet, you must have
FTP, Inc software on the PC which provides all the usual tcp/ip services.
The Banyan server just routes the packets as needed. I feel that I am not
understanding what you are getting at. There are no multiplexors, etc
involved.

                                                Bob Dixon
                                                Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jan 88 10:55:39 P
From:      Hank Nussbacher <HANK%BARILVM.BITNET@CNUCE-VM.ARPA>
To:        earntech@cearn, tcp-ip@sri-nic.ARPA, telecom@xx.lcs.mit.edu
Subject:   Need help in filling in the gaps
I am trying to compile comparative rate tables for

- the cost of 64kb digital service in various countries
- the cost of a 56/64kb link to the USA or a T1 line to the USA

If you can help me fill in the gaps or have information about a country I
have not included, please send it to me.  Once I have finished the work,
I will repost the final result.

Please reply directly to me and not to the list.

Thanks,
Hank


                   Cost comparison of 64kb digital service
                          in various countries
                   =======================================


Country            5km       10km      200km     500km
----------------+---------+---------+---------+---------+
Austria         |  683.8  | 1025.6  | 4346.2  |  6141   |
Belgium         |  372.5  |  683    | 1652    |  3304   |
Denmark         |  174.6  |  293.9  | 1770.5  |  2139.8 |
France          |  614    |  828.8  | 5241.8  |  6838.6 |
Germany         |  795.2  | 1337.3  | 8385.5  | 11638.6 |
Norway          |  242.2  |  242.2  |  602.5  |   869.6 |
Spain           | 1507.9  | 2356.5  | 4996.9  |  6713.1 |
Sweden          |  332.2  |  387.6  | 2214.8  |  2380.9 |
Switzerland     |  758.8  | 1523.5  | 6604.4  |  8810.3 |
United Kingdom  |  412.6  |  515.3  |  824.3  |  1128.5 |
----------------+---------+---------+---------+---------+
Average         |  589.4  |  919.4  | 3663.9  |  4996.4 |
----------------+---------+---------+---------+---------+

Israel            1823      2136     14011      32761     (<50 lines)
Israel            1077      1077      1077       1077     (>50 lines)

Notes:

1) Rates are in dollars per month.
2) Sources: a) Report #219, "Tariff Analysis - National Digital Services
               at 64kb and 2Mb, Claude Laurens, La Gaude, France,
               December 14th, 1987
            b) Israeli prices based on Sifranet and leased line price
               sheets, Bezek, August 15th, 1987


             International rates for high speed links to the USA
             ===================================================

Country           56/64kb   1.544M
----------------+---------+---------+
UK - MCI        | 4654    |  40540  |
UK - BTI        | 5943    |  45045  |
France          | 6017    |  49557  |
Netherlands     |         |         |
Germany         | 9939    |  86746  |
Belgium         |11500    | 115008  |
Norway          |         |         |
Sweden          |         |         |
Denmark         |         |         |
Japan           |         |         |
Spain           |         |         |
Switerland      | 8823    |         |
Ireland         |         |         |
Israel          |13548    |         |



Notes: 1) All rates are rates for connecting to the east coast in the
          USA.
       2) The rates only reflect half of the cost.  The other half is
          the rate for the link from the United States to the stated
          country
       3) All rates are cost per month in US dollars
-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 88 14:54:05 GMT
From:      nelson@sun.com  (Russ Nelson)
To:        tcp-ip@sri-nic.arpa
Subject:   booting using tftp
Is anyone out there booting PCs using tftp?  Is it possible to cram tftp
into the 8K that is available on the NI5210 (for example)?

We want to be able to boot machines from anywhere on our network.  Floppies
won't do for three reasons: the license restricts the operating system to a
single machine, users need access to machines that they don't have an
operating system for, and users can't be trusted not to trash floppies.
-- 
------------------------------------------------------------------------------
AT&T: (315)268-6591  BITNET: NELSON@CLUTX  Internet: nelson@clutx.clarkson.edu
GEnie: BH01  Compu$erve: 70441,205
-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 88 16:50:38 GMT
From:      malis@CC5.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: IP class B and C to X.25 address translation

Barry,

To reiterate my earlier message on the subject: for Class B, use
the same algorithm, but replace the Class A second octet with the
Class B third octet; in other words, treat the Class B number's
octets as n1.n2.h.i and use the Class A algorithm.

There is no standard for Class C - you have to roll your own
algorithm by dividing up the last octet into h and i bits.  It's
your choice as to which bits are h and which are i.  Once you've
done that, again follow the Class A algorithm.

Regards,
Andy

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 88 17:04:04 GMT
From:      jonab@CAM.UNISYS.COM (Jonathan P. Biggar)
To:        comp.protocols.tcp-ip
Subject:   Re:  Questions on MIL-STD-1778 (TCP).

>     I found that the decision table is switched with the "net deliver"
>table in the close wait state.  Assuming I am using the right table now,
>what should happen when;  seq num status is valid, rst is on, sec prec
>match is yes, syn in window is no, and ack status test2 is none?  Does
>this mean only data is being delivered?  If so, why does the standard
>say "no action"?  Or, does this mean the only way data gets accepted is
>if the segment contains an "ack"?

You are right about the tables being switched.

For your second question, I am assuming that you really mean rst is off.
(If you do mean rst is on, then the last line of the table should be
used and the connection should be reset and closed.)  In this case
what is happening is that the connection is probably receiving an old
duplicate SYN packet from the other end.  The only packets that do not
have ACK set are an SYN packet generated from an active open request, or
a RST packet in reponse to a SYN-ACK packet received on a closed connection.
Since RST is not on, the only valid packet that can be received here is
a duplicate SYN.  Note that even though this packet may contains a SYN, the
SYN is not in the window because the 'sv.rcv_next' variable was already
incremented past the SYN sequence number by the action procedure record_syn.
The proper response to a packet containing a duplicate SYN is just to ignore
it.

By the way, I have just completed a CRAD contract from DCA to develop
MIL-STD implementations of TCP and IP in Ada.  The code has been tested
for conformance to MIL_STD 1777 and 1778.  I believe that the code
is available for free from DCA.  If you are interested in it, let me know
and I will find out how you can acquire it.

Jon Biggar
jonab@cam.unisys.com

Distributed Architectures Branch
Unisys Defense Systems
Camarillo, CA

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 88 18:16:17 GMT
From:      estrin@rt234.usc.EDU (Deborah L. Estrin)
To:        comp.protocols.tcp-ip
Subject:   Visa paper draft Finally available

A DRAFT of the visa protocol paper mentioned long ago is now ready for
limited distribution.
Those of  you who requested copies via usmail will receive
them shortly. Those who requested copies via email, are asked
to ftp it over to save the mail systems. If this is not possible
for you let me know and i will send email or usmail.

The draft isavailable by anonymous ftp on oberon.usc.edu in pub/draft_visa.tex

It is still a Draft so we recommend that you only look at it if
you are seriously interested in providing us with some feedback
with the understanding that it is not finished and is not intended for broad
distribution.

thank you, Deborah Estrin (and co-authors Jeff Mogul of Digital and
                           Gene Tsudik of USC)

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 88 19:34:49 GMT
From:      TS0400@OHSTVMA.BITNET (Bob Dixon)
To:        comp.protocols.tcp-ip
Subject:   Re:  Banyan TCP/IP bridge

Dave,

     I'm not sure I understand your question, but Banyan servers connect to
PC LANs via ethernet, token ring etc. as with any microcomputer net server.
Users on a PC have access to disks on the server by designating them as if
they were local disks on the PC. To deal with the internet, you must have
FTP, Inc software on the PC which provides all the usual tcp/ip services.
The Banyan server just routes the packets as needed. I feel that I am not
understanding what you are getting at. There are no multiplexors, etc
involved.

                                                Bob Dixon
                                                Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 88 21:30:13 GMT
From:      Link@SRI-NIC.ARPA, Verstegen@GUNTER-ADAM.ARPA
To:        comp.protocols.tcp-ip
Subject:   Final Draft of AF LAN Interface/Security Module Specification


	The final draft of the AF LAN Interface/Security Module
Equipment Performance Specification is out for review.  As before,
the document is contained in the file [LAN-EPS]LAN.EPS.1 on the
Gunter-Adam.ARPA.  You can either log into the account and use
kermit or modem to download the file or you can FTP it to your
host.  Again, the account is LAN-EPS and the password is LAN-EPS.

	You can address any comments to LAN-EPS@GUNTER-ADAM.ARPA.
If you have anything you do not wish to share with the rest of the
community, please address them to LINK@GUNTER-ADAM.ARPA.  In either
case, I will promptly respond with the disposition of your comments.

	Of specific interest are the technical issues of using 
Commercial Off The Shelf (COTS) MS-DOS software across a LAN and
the implementation of the security controls.  Any insights on either
portion of the acquisistion are welcomed.  Will it, as proposed,
fit your needs?  The contract award is planned for June 1, 1988, so
we need your comments in the next two weeks or so to get them included.



		    /|                  /|
===================/ |=================/ |===================
 Link N. Verstegen                     Link@Gunter-ADAM.ARPA
 Computer Systems/Network Engineer
 HQ SSC/PRS                               (205)279-5151
 Gunter AFS, AL  36114-6343                AV 446-5151

-------

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 88 08:52:24 -0500
From:      adrion@SH.CS.NET
To:        iab@isi.edu, npag@udel.edu, steve@note.nsf.gov, tcp-ip@sri-nic.ARPA, csnet-ec@SH.CS.NET
Cc:        adrion@cs-umass.ARPA, cosepup@postgres.Berkeley.EDU
Subject:   Help...looking for network anecdotes
I am on the NAS/COSEPUP Panel on Information Technology and the
Conduct of Science. We are preparing our final report. One of the key
recommendations will be for an expanded and stable internet. We really
need some anecdotes on how networks have enabled scientific research. We
need examples of how new research or breakthroughs are directly attributable
to networks. There are numbers of examples to support our other recommendations,
such as the isolation of cold viruses using supercomputers, how computer
graphics have helped to discover minimal surfaces and aid in the design
of new molecules and organisms, how special purpose architectures have
aided in the real-time analysis of data, etc. We need similar examples
for computer networks, even if they involve only mundane uses
such as EMail.

Any anecdotes will be gratefully accepted. Thanks in advance.

Rick Adrion
-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 88 02:58:15 GMT
From:      tsudik@MALIBU.USC.EDU (Gene Tsudik)
To:        comp.protocols.tcp-ip
Subject:   (none)


Please add the following userid to the mailing list:

anand@cse.usc.edu

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 88 13:21:47 GMT
From:      backman@interlan.UUCP (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell

In article <316966.880127.PAP4@AI.AI.MIT.EDU> PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") writes:
>The TCP is on the server, not on the client.  The server merely presents
>it as resource accessible via IPX.  Because the TCP never really exists on
>the client, it can't be called co-resident.

[]

	Philip, Please get your ts correct.  TCP is on a coprocessor
	resident within the server.  It is advertised to workstations via
	Novell's Service Advertising Protocol (SAP).  It is accessable via
	NETBIOS rather than IPX.


						Larry Backman
						Micom - Interlan

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 88 13:52:24 GMT
From:      adrion@SH.CS.NET
To:        comp.protocols.tcp-ip
Subject:   Help...looking for network anecdotes

I am on the NAS/COSEPUP Panel on Information Technology and the
Conduct of Science. We are preparing our final report. One of the key
recommendations will be for an expanded and stable internet. We really
need some anecdotes on how networks have enabled scientific research. We
need examples of how new research or breakthroughs are directly attributable
to networks. There are numbers of examples to support our other recommendations,
such as the isolation of cold viruses using supercomputers, how computer
graphics have helped to discover minimal surfaces and aid in the design
of new molecules and organisms, how special purpose architectures have
aided in the real-time analysis of data, etc. We need similar examples
for computer networks, even if they involve only mundane uses
such as EMail.

Any anecdotes will be gratefully accepted. Thanks in advance.

Rick Adrion

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 88 19:05:07 EST
From:      Ken Pogran <pogran@ccq.bbn.com>
To:        Robert Allen <robert@spam.istc.sri.com>
Cc:        tcp-ip@sri-nic.arpa, pogran@ccq.bbn.com
Subject:   Re: PSN 7 End-to-End question.
Robert,

One of your questions has an easy answer; the answer to the other
is a lot more complex.

X.25 was chosen to replace 1822 for new IMP connections because
it is an international standard that has broad support among host
vendors.  It's DoD policy to adopt commercial standards whenever
possible.  This says nothing one way or the other, of course,
about the relative technical merits of X.25 and 1822 as access
protocols to a wide-area packet network.

Why was it deemed necessary for an End-to-End protocol in the
network?  Well, first:  the network has ALWAYS had an end-to-end
protocol.  It's not something that's been made a big deal of.
The new end-to-end protocol introduced in PSN 7 is the first
change in this protocol since the relatively early days of the
deployed ARPANET.

The purpose of the end-to-end (EE) protocol is, primarily, to
manage the INTERNAL resources of the network in response to the
demand for services from the network's hosts.  It's called an
end-to-end protocol because it operates between the source PSN
(the PSN to which the host originating a given message is
attached) and the destination PSN (the PSN to which the host
which is the destination of the message is attached).  The EE
functionality of the PSNs of the network is in addition to the
"store-and-forward" functionality that occurs from one PSN to the
next.

The "IMP-to-IMP" protocol accomplishes reliable transmission from
one PSN to the next; the EE protocol manages resource utilization
for a flow of data "across" the network from source to
destination PSN.  It also provides the mechanism by which a PSN
is able to enform a source host about what happened to his
message -- whether it was delivered to the destination (host gets
a RFNM, in 1822 parlance), or not (host gets a Destination Dead,
or Transmission Incomplete, in the event something in the network
failed while the message was in transit).

EE ACKs are on a per-host-message basis, which in an IP world
translates into per-IP-packet.  (Under the "new EE" of PSN 7, EE
ACKS can be aggregated when being sent across the net for
efficiency, but are sorted out at the source PSN for proper
presentation -- via individual RFNMS in 1822, for example -- to
the source host.

In the ARPANET, messages from hosts can be up to (approx) 8K bits
long and are fragmented by the PSN into packets of (approx) 1K
bits.

The EE protocol is employed for all host traffic in the network;
after all, it's used to manage the resources of the network
itself.  Which answers the question of why the EE protocol was
deemed necessary in a network that already has PSN-to-PSN
reliability.

Hope this helped.

Regards,
 Ken Pogran
-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 88 21:56:27 EST
From:      Lew Shepherdson <SIMXT%UOTTAWA.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   TCP/IP for AT&T 3B5 system
Any recommendations for TCP/IP implementations using Ethernet that run
on an AT&T System V Unix system?

Lew Shepherdson
SimXT@UOttawa.Bitnet
-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 88 19:13:51 GMT
From:      robert@spam.istc.sri.COM (Robert Allen)
To:        comp.protocols.tcp-ip
Subject:   PSN 7 End-to-End question.


    Recently I've been thinking about the changes in host connections to 
    the ARPAnet, and some questions have come up I can't answer for myself.
    If anyone can answer these publicly or privately I'd appreciate it.  If
    the questions are to basic for this group any pointers to RFCs which are
    pertinent would be welcome.  Thanks,
	Robert Allen, robert@spam.istc.sri.com
	415-859-2143 (work phone, days)

    ----------------------------------------------------------

    The questions are primarily two: first, why was X.25 chosen as the
    replacement for 1822 for all new IMP connections? second, why was
    it deemed necessary for an End-to-End protocol in the network?

    Regarding the first question: What exactly are the options for X.25
    connections to the ARPAnet?  Is HDLC *or* LAPB acceptable, or only
    HDLC?  Is LAPB deemed necessary for a reliable connection or is HDLC
    sufficient?  Simply stated, are two reliable layers under IP needed
    or is 1 sufficient?


    Regarding the second question: First, I assume that the the ETE protocol
    is IMP-to-IMP.  In the older releases of IMP software I assumed that it
    operated on a reliable link-to-link basis (except in cases of extreme
    problems), in other words, my concept of the IMP model comes from chapter
    5 of the Tannenbaum "Computer Networks" book.  Under the ETE model as I
    understand it, there is an 'ETE ACK' for the packets sent.  Questions
    I have include

	"is the ACK on a per-IP-packet basis or on a per-IMP-packet basis?",

	"if ETE is used on an per-IP-packet basis can fragmentation occur?",

	"is the ETE protocol used on all packets, or just those that request/
	    require it?",

    and of course

	"why was the ETE protocol deemed necessary in a network that already
	    had IMP-to-IMP reliablity (this leads me to believe that ETE is
	    only used for some packets, namely those that require extreme
	    reliability)?"

    Picture:
        host    IMP					IMP	host
	----	----					----	----
	|  |====|  |<---------->NETWORK<--------------->|  |====|  |
 ----    ----					----	----
	   |X.25|~~~~~~~~~~~~~~~~~ETE protocol~~~~~~~~~~~~~|X.25|

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 88 19:22:22 GMT
From:      raj@PURDUE.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Visa paper draft Finally available


    I copied the draft you have. But how do I get the bibliographic references?
    I am interested in them too.

Thanks!!
Raj Yavatkar

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 88 20:38:12 GMT
From:      dino@CDCCENTR.BITNET (Dino Farinacci - Control Data - CDCNET TCP/IP Development)
To:        comp.protocols.tcp-ip
Subject:   PASV support



    Any implementations  out  there,  other  than  BSD  4.3, that
    support FTP PASV/3-party transfers?

Dino Farinacci
Control Data Corp.
Sunnyvale, CA.

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 88 21:49:33 GMT
From:      edward@csvaxa.UUCP (Edward Wilkinson)
To:        comp.protocols.tcp-ip
Subject:   CMU <-> Ultrix tcp/ip ftp crash fixed


Having experienced  a great deal of  frustration  with the  CMU TCP/IP
software, I must  retract some  of  my recent  hasty critisism of  the
package. The result however was that I received a piece of information
from Richard Sharpe in  Australia.  Having acted on his information it
would appear that  some of the problems we  were having between Ultrix
and CMU, and Ultrix and Prime FTP seem to have gone.

Apparently not all  TCP/IP  implementations support   'trailers',  CMU
doesn't  and we believe that  the PRIME implementation doesn't either.
The Ultrix 2.0  implementation  enables  trailers  by  default.   This
crashes the other two implementations quite frequently. By turning off
trailers '/etc/ifconfig ... ... -trailers' we  now seem to be  able to
get the various versions to talk to each other without crashing.

I hope this information will be of assistance to any others  that have
been having similiar problems.
-- 
CSNET/ACSnet/Internet: G.Eustace@massey.ac.nz    New Zealand = GMT+12

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 00:05:07 GMT
From:      pogran@CCQ.BBN.COM (Ken Pogran)
To:        comp.protocols.tcp-ip
Subject:   Re: PSN 7 End-to-End question.

Robert,

One of your questions has an easy answer; the answer to the other
is a lot more complex.

X.25 was chosen to replace 1822 for new IMP connections because
it is an international standard that has broad support among host
vendors.  It's DoD policy to adopt commercial standards whenever
possible.  This says nothing one way or the other, of course,
about the relative technical merits of X.25 and 1822 as access
protocols to a wide-area packet network.

Why was it deemed necessary for an End-to-End protocol in the
network?  Well, first:  the network has ALWAYS had an end-to-end
protocol.  It's not something that's been made a big deal of.
The new end-to-end protocol introduced in PSN 7 is the first
change in this protocol since the relatively early days of the
deployed ARPANET.

The purpose of the end-to-end (EE) protocol is, primarily, to
manage the INTERNAL resources of the network in response to the
demand for services from the network's hosts.  It's called an
end-to-end protocol because it operates between the source PSN
(the PSN to which the host originating a given message is
attached) and the destination PSN (the PSN to which the host
which is the destination of the message is attached).  The EE
functionality of the PSNs of the network is in addition to the
"store-and-forward" functionality that occurs from one PSN to the
next.

The "IMP-to-IMP" protocol accomplishes reliable transmission from
one PSN to the next; the EE protocol manages resource utilization
for a flow of data "across" the network from source to
destination PSN.  It also provides the mechanism by which a PSN
is able to enform a source host about what happened to his
message -- whether it was delivered to the destination (host gets
a RFNM, in 1822 parlance), or not (host gets a Destination Dead,
or Transmission Incomplete, in the event something in the network
failed while the message was in transit).

EE ACKs are on a per-host-message basis, which in an IP world
translates into per-IP-packet.  (Under the "new EE" of PSN 7, EE
ACKS can be aggregated when being sent across the net for
efficiency, but are sorted out at the source PSN for proper
presentation -- via individual RFNMS in 1822, for example -- to
the source host.

In the ARPANET, messages from hosts can be up to (approx) 8K bits
long and are fragmented by the PSN into packets of (approx) 1K
bits.

The EE protocol is employed for all host traffic in the network;
after all, it's used to manage the resources of the network
itself.  Which answers the question of why the EE protocol was
deemed necessary in a network that already has PSN-to-PSN
reliability.

Hope this helped.

Regards,
 Ken Pogran

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 00:06:00 GMT
From:      stevens%antares@ANL-MCS.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re:  Help...looking for network anecdotes

One Network story comes to mind here at Argonne.  We have used the internet
to demonstrate  long haul distributed computing by running one large parallel program
which used a set of parallel processors here in Chicago and a set of parallel
processors at Los Alamos.  This program was computing the solution to one problem
by coordinating the work across the net.   The actual problem was nothing impressive
but it did prove the concept of using resources over the internet.

--Rick Stevens
Manager of Advanced Computing Research Facility
Mathematics and Computer Science

Argonne National Laboratory

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 02:56:27 GMT
From:      SIMXT@UOTTAWA.BITNET (Lew Shepherdson)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for AT&T 3B5 system

Any recommendations for TCP/IP implementations using Ethernet that run
on an AT&T System V Unix system?

Lew Shepherdson
SimXT@UOttawa.Bitnet

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 03:38:18 GMT
From:      guy@gorodish.Sun.COM (Guy Harris)
To:        comp.protocols.tcp-ip,comp.lang.c
Subject:   Re: C binding interfaces for TCP/IP

> Sun has published the protocol to encourage its implementation on other
> systems.

The source code to an implementation of RPC has also been made available.  It
has been posted to "comp.sources.unix" and is included in the User Contributed
Software portion of the 4.3BSD tape; I think we also make it available for the
cost of a tape.

This implementation is basically a C implementation (RPC need not be
implemented in C; some people at The Johns Hopkins Hospital implemented it for
MVS and MUMPS as part of an application they developed, with bindings in COBOL
and MUMPS) for systems providing various 4.2BSD functions such as the socket
calls, "select", "gettimeofday", etc..  It can probably be reimplemented on
UNIX and non-UNIX systems providing equivalent functionality.

It also includes transport interfaces for TCP and UDP.  It is not tied to the
Internet protocols; the Johns Hopkins Hospital version uses XNS Sequenced
Packet Protocol to talk to the IBM mainframe and a homebrew asynchronous serial
line protocol to talk to various other machines.

An client implementation of RPC for the PC under MS-DOS is provided with the
PC-NFS 2.0 product.

> I also don't know if anyone has implemented them on VAX/VMS systems (but I
> suspect that this has been done).

They have been implemented to the extent that at least one NFS server
implementation for VAX/VMS exists; I don't know if an RPC or XDR library is
provided for VAX/VMS that applications can use.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jan 88 8:39:52 EST
From:      Alex McKenzie <mckenzie@LABS-N.BBN.COM>
To:        Robert Allen <robert@SPAM.ISTC.SRI.COM>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  PSN 7 End-to-End question.
Robert,

One addition to Ken Pogran's message: several of the designers of the ARPANET
packet switches made by BBN presented a description of the design issues we
were concerned about, and our approaches to solving them, at the 1975 "AFIPS
National Computer Conference".  Our paper is on pages 161-175 of the
Proceedings.  There is quite a detailed discussion of what we felt were the
appropriate design choices for the Node-Node and Source-Destination
transmission procedures, and the trade-offs between them.  Although I am one of
the authors of the paper, and therefore probably have an exaggerated sense of
its importance, I recommend it to you if you want to understand why the ARPANET
design choices were made as they were.

Regards,
Alex McKenzie, BBN
 
-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jan 88 09:50:45 EST
From:      Ross Patterson <A024012%RUTVM1.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Cc:        Dino Farinacci <DINO@CDCCENTR>
Subject:   Re: PASV support
    Yup.  UCLA's Arpanet Control Program  for IBM MVS systems supports
the 3-party model.  In fact, that's its only form of FTP.  ACP is also
remarketed by  ACC as  ACCES/MVS, by Network  Solutions as  DDN/MVS (I
think), and several others I can't recall.

Ross Patterson
Rutgers University
-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 05:08:12 GMT
From:      schwartz@gondor.cs.psu.edu (Scott E. Schwartz)
To:        comp.protocols.tcp-ip,comp.lang.c
Subject:   Re: C binding interfaces for TCP/IP

In article <2168@cognos.UUCP> jimp@cognos.UUCP (Jim Patterson) writes:
>In article <25@vdelta.UUCP> dave@vdelta.UUCP (Dave Arnold) writes:
>>Are there efforts underway to standardize a C language interface for TCP/IP?
>
>Sun has developed a definition called RPC (Remote Procedure Call)
>which is becoming a defacto standard in some environments. 
 
>Sun has published the protocol to encourage its
>implementation on other systems. In conjunction with RPC, Sun has
>an excellent protocol called XDR (eXternal Data Representation)
>to deal with data conversions between different machine
>architectures in a flexible but structured manner.
 
>You might contact Sun Microsystems to get more information about
>RPC and XDR.

Sun has done more than just publish the protocol definition.  The 
source for the entire thing (at least the 4.3BSD version) is available 
from titan.rice.edu (the sun-spots-digest people) by anonymous ftp.

I recently compiled it all on a VAX/750 with no trouble at all.  Sun
encloses a fun demo called "rstat_svc" which suntools perfmeters can
interrogate to find out load, %cpu, etc.  It all comes with about 100
pages of documentation, too.

By the way, Apollo recently announced some other RPC protocol that 
they would like to become the standard, but I don't know anything 
about it.



-- Scott Schwartz            schwartz@gondor.cs.psu.edu

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 13:39:52 GMT
From:      mckenzie@LABS-N.BBN.COM (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re:  PSN 7 End-to-End question.

Robert,

One addition to Ken Pogran's message: several of the designers of the ARPANET
packet switches made by BBN presented a description of the design issues we
were concerned about, and our approaches to solving them, at the 1975 "AFIPS
National Computer Conference".  Our paper is on pages 161-175 of the
Proceedings.  There is quite a detailed discussion of what we felt were the
appropriate design choices for the Node-Node and Source-Destination
transmission procedures, and the trade-offs between them.  Although I am one of
the authors of the paper, and therefore probably have an exaggerated sense of
its importance, I recommend it to you if you want to understand why the ARPANET
design choices were made as they were.

Regards,
Alex McKenzie, BBN
 

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 14:50:45 GMT
From:      A024012@RUTVM1.BITNET (Ross Patterson)
To:        comp.protocols.tcp-ip
Subject:   Re: PASV support


    Yup.  UCLA's Arpanet Control Program  for IBM MVS systems supports
the 3-party model.  In fact, that's its only form of FTP.  ACP is also
remarketed by  ACC as  ACCES/MVS, by Network  Solutions as  DDN/MVS (I
think), and several others I can't recall.

Ross Patterson
Rutgers University

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 15:58:34 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  booting using tftp


> Is anyone out there booting PCs using tftp?  Is it possible to cram tftp
> into the 8K that is available on the NI5210 (for example)?

Ignore this if you just want an answer to your question.

This is just an anecdote:

Sun put out some strange software early on which, after all was said 
and done, caused some client machines to request a boot from an IBM pc
on another LAN connected via a Sun acting as an IP router. 
This essentially froze the pc (due to numerous ethernet interrupts) not to
mention the client which could not boot.  We put some software in the PC
to send back a junk "vmunix" which shut the client up for a while.

Phil Wood
Los Alamos National Laboratory

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 16:38:00 GMT
From:      SRA@XX.LCS.MIT.EDU (Rob Austein)
To:        comp.protocols.tcp-ip
Subject:   PASV support


    Date: Thursday, 28 January 1988  15:38-EST
    From: dino%CDCCENTR.BITNET@CUNYVM.CUNY.EDU

        Any implementations  out  there,  other  than  BSD  4.3, that
        support FTP PASV/3-party transfers?

The TOPS-20 FTP server supports PASV.  Given the ancestry of FTPSRT, I
assume the TENEX FTP server also supports PASV.  Neither of the two
TOPS-20 user FTP programs supports use of PASV directly, although one
of them (Stanford's) supports a QUOTE command for the fearless types
who are willing to roll their own protocol negotiations.

The ITS FTP server doesn't support PASV.  The ITS user FTP program
claims to support the use of PASV for third party transfers.  I don't
know if anybody has ever actually used this feature or if it works.
The ITS user FTP also supports QUOTE.

--Rob

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 18:09:35 GMT
From:      cheriton@PESCADERO.STANFORD.EDU ("David Cheriton")
To:        comp.protocols.tcp-ip
Subject:   Re: PSN 7 End-to-End question.

Presumably, the EE and Imp-to-imp protocols also consume the INTERNAL
resources of the network while they are doing this managing.  Is there
any evidence to assure us that these protocols are a net performance
win over a simple, lean and mean best-efforts datagram service, which is
all that IP/TCP wants and can use?
  What is the best reference to understand how these protocols manage the
network resources, particularly in dealing with network congestion?
Thanks,
David Cheriton

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 18:11:13 GMT
From:      larry@pdn.UUCP (Larry Swift)
To:        comp.protocols.tcp-ip
Subject:   Re: new version of tcpdump available

In article <8801250336.AA21049@lbl-csam.arpa> van@LBL-CSAM.ARPA (Van Jacobson) writes:
>There's a new version of tcpdump (v1.17) available for anonymous

What does tcpdump do?  Sounds like it might be useful in our environment
(several different machines, including Sun's, all using tcp/ip).

Larry Swift                     UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207          Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 19:32:56 GMT
From:      deschon@VENERA.ISI.EDU (Annette DeSchon)
To:        comp.protocols.tcp-ip
Subject:   Re: PASV support

Dino,

TOPS-20 and 4.3BSD both support PASV; 4.2BSD doesn't.

Please do summarize your findings to the list.

I'm currently working on a background file transfer program (BFTP) that 
is based on third party file transfer.  Therefore, I would be very
interested in hearing about the results of your survey, and possibly 
setting up some tests involving dissimilar FTP/TCP implementations.

--Annette

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 20:18:06 GMT
From:      gwyn@brl-smoke.ARPA (Doug Gwyn )
To:        comp.protocols.tcp-ip,comp.lang.c
Subject:   Re: C binding interfaces for TCP/IP

In article <2168@cognos.UUCP> jimp@cognos.UUCP (Jim Patterson) writes:
>In conjunction with RPC, Sun has
>an excellent protocol called XDR (eXternal Data Representation) ...

I wouldn't call it "excellent".  A few months back, when I needed to
design and implement a package for inter-system data exchange as part
of a large project we're developing, the first thing I thought of was
to adopt XDR for my machine-independent data transfer.  So, I looked
it up in the Sun reference manual and found that it had FAR too much
overhead for my purposes.  I ended up implementing my own scheme that
runs much faster.

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 21:39:51 GMT
From:      andy@ntmtka.UUCP (andy)
To:        comp.protocols.tcp-ip
Subject:   Need Gurwitz paper

I need some help.  I work at Northern Telecom in Minnesota.  I am embarking
on a project to implement Berkeley's socket and protocol stuff into our
version of Unix V.2.  In reading over some literature, I found a reference
to a paper by R. F. Gurwitz entitled "VAX-UNIX Networking Support Project -
Implementation Description."  Can someout out there please tell me how I
can get a copy of this (and other things which may be of assistance to me)?

Please respond by Email.  Thanks.
-- 
| Andrew Prokop                            |                          |
| Northern Telecom, Inc.                   |                          |
| H-200, 9705 Data Park    (612) 932-8758  | Yo no soy marinero       |
| Minnetonka, MN 55343     ems!ntmtka!andy | Soy capitan              |

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 22:37:37 GMT
From:      kaigler@ihlpa.ATT.COM (Kaigler)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP Verification Suite

Hi All,
    I've sent this message before, so if you've seen it, just ignore it, okay.  I'm
relatively new at working with TCP-IP and would like some information.  I'll be     
testing TCP-IP and VAX, UTS, and 3B2 machines and would like to know if there
exists some sort of test tools which would be of some help.  By the way this is
streams based TCP-IP.  Any information would be greatly appreciated.

                                        Ronnie Kaigler
                                        ihlpa!kaigler
			                IH 1B-232
                                        (312) 979-1762

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 22:38:00 GMT
From:      mishkin@apollo.uucp (Nathaniel Mishkin)
To:        comp.protocols.tcp-ip,comp.lang.c
Subject:   Re: C binding interfaces for TCP/IP

In article <3256@psuvax1.psu.edu> schwartz@gondor.cs.psu.edu (Scott E. Schwartz) writes:
>In article <2168@cognos.UUCP> jimp@cognos.UUCP (Jim Patterson) writes:
>>In article <25@vdelta.UUCP> dave@vdelta.UUCP (Dave Arnold) writes:
>>>Are there efforts underway to standardize a C language interface for TCP/IP?
>>
>>Sun has developed a definition called RPC (Remote Procedure Call)
>>which is becoming a defacto standard in some environments. 
 
>>Sun has published the protocol to encourage its
>>implementation on other systems.
>
>By the way, Apollo recently announced some other RPC protocol that 
>they would like to become the standard, but I don't know anything 
>about it.

Apollo's RPC system is called the Network Computing Architecture (NCA).
Apollo's portable implementation of NCA is called the Network Computing
System (NCS).  NCS runs on a BSD and System V Unix variants, VMS, and
MS/DOS.

NCA defines a special-purpose lightweight request/response protocol that
can (and does) run over a variety of datagram (unreliable) services (e.g.
UDP/IP), yet maintains the "at-most-once" call semantic.  (Calls to
procedures declared to be idempotent are supported at slightly lower
cost.) The protocol supports reflecting server exceptions back to clients
and asynchronous interrupts (quits) at the client being passed to a server
process running on the client's behalf.  Fragmentation and reassembly
are performed if the input or output parameters don't fit in a single
datagram.  The reason we went with a special-purpose protocol was to
minimize message exchange overhead and load on server and client.  (We
expect it to not be uncommon for a single server to be contacted by 100s
of clients over, say, a one minute period.  We expect it to not be uncommon
for a single client to want to contact 100 servers over a similar period.)
Also, not all virtual circuit protocols are created equally, making it
hard to write a single package that will run equally well over a variety
of them.

NCA defines a data presentation protocol, the Network Data Representation
(NDR), which operates in what we call a "quasi receiver makes it right"
fashion.  I.e. it supports a fairly rich set of different canonical scalar
data representations which a sender can chose from and a receiver must
convert from (if necessary) upon receiving the data.  Our goal is
that when like machines communicate, no data conversion need occur.

NCA defines a language, the Network Interface Definition Language (NIDL),
that looks like (say) a Modula-2 interface.  (The language also has a
C-like variant, which tries to be in the spirit of ANSI C and C++.)  NCS
includes a compiler for NIDL.  The compiler produces client and server
stubs that interface with the network runtime and handle data conversion
issues.  The NIDL compiler can be used in conjunction with applications
written in Unix "f77" (no small task, I'm afraid), as well as C.  The
NIDL compiler and NCS runtime go to fairly great pains to avoid data
copying and calls to dynamic storage allocation routines.

NIDL has a mechanism for dealing with types not marshallable by the
compiler (e.g. arbitrary data structures like trees, linked lists).  For
each such type, the interface defines a corresponding "transmissible
type"; the interface writer is obliged to write routines (called from
the automatically generated stubs) that convert between the transmissible
and the abstract type.  This scheme has the virtue of being declarative
as far as the interface is concerned -- the interface (and not any
user-written code) precisely specifies what appears "on the wire".

NCA defines and NCS supports a rich, object-oriented binding model
promoting a view of distributed computing that is based on what you want
to do, not where you want it done.  (I know that was buzzspeak, but I
don't want this to go on forever.)  This model is embedded in NIDL, making
it possible to define interfaces and write applications that have no
outward sign of being "remote" or having anything to do with networks,
host names, or network addresses.

Various Apollo projects and products have been implemented using NCS.
These include a replicated object (service) location service, a replicated
user registry (upon which the Unix "getpw" calls are implemented), a
distributed software license checkout system (Network License Server).
Outside Apollo, various projects based on NCS are underway, some at
companies and some at universities.  University of Iowa developed a
simulation system that uses a Alliant FX series minisuper and an Apollo
cooperatively.  An independent implementation of the NCA/RPC protocol
was done at the San Diego Supercomputer Center for their CTSS/Cray
system.

Since someone referred to Sun RPC as a "de facto standard", I feel free
to introduce my (admitedly biased) comment that (a) I don't really see
this as being the case, and (b) NCA/NCS has numerous technical advantages
over Sun RPC.  Sun RPC is widespread because NFS is based on it.  Until
recently, there wasn't an effective interface definition language or
compiler for that language (and the current one has various limitations),
thus making Sun RPC not a terribly attractive system for developing a
variety of large distributed applications.  Correct (i.e. at-most-once)
call semantics require the programmer to know to choose (and to in fact
choose) a proper (i.e. reliable, virtual circuit) underlying transport
(e.g. TCP/IP).  Use of UDP/IP even in the case of idempotent procedures
can cause program failures if at runtime it turns out that the input
or output parameters don't fit into a single UDP datagram.  The Sun RPC
interface definition language (RPCL) obliges all procedures to take one
input parameter and return results via function value (essentially
burdening the application program with the marshalling and unmarshalling
process).

Now I know there's someone who knows (and is going to tell me and the
world) that you can get Sun RPC from Sun (or whoever) for free, and Apollo
is not giving away NCS.  We do have a draft specification of NCA which
we will give away.  (Who knows, we may have to charge the cost of materials
and mailing if we get a ton of requests for it.)  The NCS source code
costs money.  This is not the appropriate forum to go into details about
cost and value, but I will at least say that universities can (under
license) get it for a nominal amount of money.  We hope that binary
versions of NCS will become readily available at low price.  The world
will have to decide whether it wants to pay for it.  We think it's worth
it.

There was a paper describing all this in the Summer 1987 Usenix.  People
can feel free to contact me for more information.
-- 
                    -- Nat Mishkin
                       Apollo Computer Inc.
                       Chelmsford, MA
                       {decvax,mit-eddie,umix}!apollo!mishkin

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 22:55:49 GMT
From:      NIC@SRI-NIC.ARPA (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   ARPANET Upgrade Bulletin Board

At the request of Code B613 of the DDN DCS, the NIC is establishing an
ARPANET PSN 7.0 Upgrade bulletin board.  The information sent to
this bboard will contain weekly status reports concerning problems and
solutions related to the upgrade of ARPANET PSNs to the new end-to-end
protocols.

If you choose to be on the distribution list for this bboard, you will
receive weekly status reports on upgrade developments, problems and
resolutions.  All status reports will be archived in a mail file on
SRI-NIC.ARPA.  Archived reports can either be FTPed using
login="anonymous" and password="guest" or requested through SERVICE,
the NIC's automatic mail service.  The pathname is
NETINFO:ARPA-UPGRADE.MAIL

If you want to be added to the distribution list, please send an
electronic mail request to NIC@SRI-NIC.ARPA.
-------

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 88 22:57:44 GMT
From:      ragge@nada.kth.se (Ragnar Sundblad)
To:        comp.protocols.tcp-ip
Subject:   Re: EtherTalk broadcast invasion

In article <305731.880101.JBVB@AI.AI.MIT.EDU> JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") writes:
>As it stands, I see it as an excelent argument for IP routers in the great
>router vs. bridge debate.  From what you say, it appears that you can't
>have more than 250 MACs using EtherTalk anywhere in your bridged Ether,

Right, you must have a more intelligent bridge. Then you can give the nets
appletalk net numbers.

>and if you have even a hundred, people will notice.  Presumably the 8-bit
>node ID is *really* built-in, even if the 20 broadcasts in less than a
>second aren't?
They save the number for use next time. But they still have to check that
the number is unique.
>Or, do they do it quickly because the defense protocol
>breaks down when two nodes try to defend the same address at the same
>time?
Ha, ha, ha...

1. The mac (II) does not auto-power-on (normally)
2. The broadcast "storm" will not be sent before the user tries to use
   the network. (by printing etc)

	/ragge@nada.kth.se

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 88 00:34:34 GMT
From:      latzko@athos.rutgers.edu (Alex )
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for AT&T 3B5 system

In article <8801290950.AA12258@ucbvax.Berkeley.EDU> SIMXT@UOTTAWA.BITNET (Lew Shepherdson) writes:
>Any recommendations for TCP/IP implementations using Ethernet that run
>on an AT&T System V Unix system?
If you are running a pure ATT SVR2.1 on a 3b5 forget it.  The answer I
have gotten time and time again from ATT is upgrade to a 3b15 and get 
WIN/3B from us.  I have now been waiting almost a year for this
magickal feat to take place.  It is now scheduled for the first 
week in Feb.  

If you have a 3b2 you can get the STREAMS version under 5.3 from ATT.
Unfortunatly, although TWG wrote it they are under an exclusive
marketing contract with ATT.  The 3b2 version I have ( non-STREAMS)
works reasonably well, but it requires a host table and we are a
domain based operation.  Oh well.

Hope this helps.
/S*



>
>Lew Shepherdson
>SimXT@UOttawa.Bitnet

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 88 06:54:30 GMT
From:      ok@quintus.UUCP (Richard A. O'Keefe)
To:        comp.protocols.tcp-ip,comp.lang.c
Subject:   Re: C binding interfaces for TCP/IP

In article <7202@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <2168@cognos.UUCP> jimp@cognos.UUCP (Jim Patterson) writes:
> >In conjunction with RPC, Sun has
> >an excellent protocol called XDR (eXternal Data Representation) ...
> I wouldn't call it "excellent".  A few months back, when I needed to
> ...
> it up in the Sun reference manual and found that it had FAR too much
> overhead for my purposes.  I ended up implementing my own scheme that
> runs much faster.

How can a program run much faster than a PROTOCOL?
The protocol is one thing, the source-code implementation of it that
SUN give away is quite another.
With respect to the protocol, XDR is historically related to Courier,
so there's a fair bit of experience behind the *protocol*.
It may well be a good idea to write one's own implementation of the
protocol, but it is not such a good idea to invent yet another data
conversion protocol.

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 88 06:59:11 GMT
From:      KASHTAN@IU.AI.SRI.COM (David L. Kashtan)
To:        comp.protocols.tcp-ip
Subject:   Re: C binding interfaces for TCP/IP


	>...
	>From: clyde!watmath!utgpu!utzoo!dciem!nrcaer!cognos!jimp@rutgers.edu
	>      (Jim Patterson)
	>Organization: Cognos Inc., Ottawa, Canada
	>Subject: Re: C binding interfaces for TCP/IP
	>...
	>
	>Sun has developed a definition called RPC (Remote Procedure Call)
	>which is becoming a defacto standard in some environments. RPC is
	>...
	>
	>While I've studied these protocols a bit, I don't have any direct
	>experience with them. I also don't know if anyone has implemented
	>them on VAX/VMS systems (but I suspect that this has been done).
	>...
	>Jim Patterson                              Cognos Incorporated
	>...


For those interested in such matters, SRI's MultiNet networking system
for VAX/VMS includes RPC (server and client) and XDR in a user-callable
library.

David
-------

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30-Jan-88 19:12:06 EST
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip,comp.lang.c
Subject:   Re: C binding interfaces for TCP/IP

> Since someone referred to Sun RPC as a "de facto standard"...

Apollo notwithstanding, Sun RPC *is* a de facto standard.  Not because it's
good, but because it was first, and is already widespread.

> ... The world will have to decide whether it wants to pay for it...

*This* part of the world most assuredly isn't going to pay for it until we
see a manufacturer-independent standard, meaning in particular that Apollo
or Sun can't change the rules any time they feel like it.  (Please spare us
the automatic "we would never do that" response.  Having had experience with
the SVID-Of-The-Month Club run by AT&T, we no longer believe it.)
-- 
Those who do not understand Unix are |  Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly.    | {allegra,ihnp4,decvax,utai}!utzoo!henry

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Sun, 31 Jan 88 07:47:35 -0500
From:      Jeffrey C Honig <jch@devvax.tn.cornell.edu>
To:        hi!kurt@hc.dspo.gov (Kurt Zeilenga)
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: selective RIP
>Does any one now of a RIP implementation for BSD UNIX that
>can be selective of the RIP routes it adds to the routing
>tables?  Basically, I would like to have a gateway's (it happens
>to a Sun-3 running SunOS 3.4) RIPper only install routes to
>subnets of a B class address (please not ask why, it's gross :-).
>
>I have a copy of gated (1.3.1.2) but absolutely no documentation
>(except for the code itself).  Can gated do this?  If so, is
>there a newer version?  any documentation?

Yes, gated.1.3.1.2 is the latest version.  Yes, it can do what you want. 
It is available for anonymous FTP from devvax.tn.cornell.edu as
pub/gated/gated.tar and pub/gated/gated.tar.Z (compressed).  And yes,
there is documentation with the distributed version. 

Jeff
-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 88 05:16:53 GMT
From:      david@elroy.Jpl.Nasa.Gov (David Robinson)
To:        comp.protocols.tcp-ip,comp.lang.c
Subject:   Re: C binding interfaces for TCP/IP

In article <2168@cognos.UUCP>, jimp@cognos.uucp (Jim Patterson) writes:
> While I've studied these protocols a bit, I don't have any direct
> experience with them. I also don't know if anyone has implemented
> them on VAX/VMS systems (but I suspect that this has been done).
> You might contact Sun Microsystems to get more information about
> RPC and XDR.

I have ported them to work on VMS running Network Research's FUSION
TCP/IP package.  It was an easy port because the support a BSD
style interface.  I have ported  some RPC based services from Suns
with little difficulty to VMS, problems were mostly with VMS C.

I know of someone who partially ported it to
the VMS Excelan TCP/IP but with considerable difficulty and it didn't
work well because Excelan only provides a VMS QIO interface that is
based on 4.1BSD networking.

-- 
	David Robinson		elroy!david@csvax.caltech.edu     ARPA
				david@elroy.jpl.nasa.gov	  ARPA
				{cit-vax,ames}!elroy!david	  UUCP
Disclaimer: No one listens to me anyway!

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 88 06:15:03 GMT
From:      kurt@hi.unm.edu (Kurt Zeilenga)
To:        comp.protocols.tcp-ip
Subject:   selective RIP

Does any one now of a RIP implementation for BSD UNIX that
can be selective of the RIP routes it adds to the routing
tables?  Basically, I would like to have a gateway's (it happens
to a Sun-3 running SunOS 3.4) RIPper only install routes to
subnets of a B class address (please not ask why, it's gross :-).

I have a copy of gated (1.3.1.2) but absolutely no documentation
(except for the code itself).  Can gated do this?  If so, is
there a newer version?  any documentation?

Your comments and suggestions will be appreciated.
-- 
	Kurt (zeilenga@hc.dspo.gov)

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 88 14:15:59 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on Convergent Workstation

My company, Sirius Systems, Inc., will be releasing TCP/IP for the
Convergent Worstations product line (IWS, AWS, NGen, Megaframe SRP, and
all the Unisys clones) within the next couple of weeks.  We provide SLIP
and Ethernet media support with X.25 coming along in about 3 months. 
TELNET, FTP, and SMTP are provided as part of the package.  The software
permits a workstation to serve as both host and gateway. 

We are look for sites that have a heterogeneous collection of systems
that support TCP/IP.  We want to make sure that we have the bugs worked
out so we would like to find people interested in running our software
in a mixed environment.

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
wb6rqn!brian@flash.bellcore.com

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Feb 88 01:52:09 EST
From:      schoff@uu.psi.com (Martin L. Schoffstall)
To:        uupsi!iuvax.cs.indiana.edu!bronze.ucs.indiana.edu!mckimg@uu.psi.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
Geoffrey,

I think that "fast connections around the world" does not mean that we
have to allow anyone with a modem and terminal to telnet/rlogin into any
host at will on the Internet.  Doesn't compute.

Host security improvement should go on in parallel with access control
improvements.  Functionality has been the prime driving force behind the
success of the Internet and Internet technologies, but is broad
functionality to increasingly diverse user groups.  While the tradition
and flavor of the federal/research/academic Internet will continue to be a 
vital force, it is no longer either the exclusive community nor the primary
driving force in the Internet, in my estimation.  These additions to the
Internet community improve the quality of the fabric, by providing services,
economic support, perspective, and large enough scale to be self sustaining
for the long run.

Instead of insisting that you have the right to ask for service from an
organization that you have no association with, why don't you consider
a service provider that will provide you with the service.


Marty
> 
> 
> I don't mean to flame but... Obviously one of the primary benefits of something
> like the Internet is fast, efficient connections around the world.  Sure, 
> if we wanted to, we could all just have cheapo 1200 baud modems on our desks
> and dial up whatever machine we want to directly.  But that sort of defeats
> the purpose of a high-speed network.
> 
> In other words, the easiest way to improve security is to simply disconnect 
> all the machines on the network from all others.  But then we've got no 
> network eh?  I'm afraid that knee-jerk reactions have long been the hallmark
> of those in charge of computer security.  I realize that it will always be 
> difficult to balance functionality and security, but I also hope that people
> realize that the reason for the network's existence is FUNCTIONALITY.  I for 
> one will certainly work to fight the elimination of dial-up terminal servers
> connected to the internet.  Let's make our hosts more secure and not 
> intentionally cripple the internet.
> 
> 
> Geoffrey McKim				*** Standard disclaimers apply ***
> Indiana University

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 88 22:21:14 GMT
From:      narten@PURDUE.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: PSN 7 End-to-End question.

> Presumably, the EE and Imp-to-imp protocols also consume the INTERNAL
> resources of the network while they are doing this managing.  Is there
> any evidence to assure us that these protocols are a net performance
> win over a simple, lean and mean best-efforts datagram service, which is
> all that IP/TCP wants and can use?

Total "best effort" systems work well only as long as the switches and
communications lines run below maximum capacity. Once maximum capacity
is reached or exceeded, problems arise. Many of them are solvable, but
they must be addressed, and the resulting system may no longer be "lean
and mean".

1) Best effort systems rely totally on hosts for congestion
management. That is, transport protocols are responsible for
congestion control and congestion avoidance.

In practice, existing protocols don't play by those rules. For
instance, only recently (Van Jacobson's work) have TCP implementations
started reacting (in a positive way) to congestion.  UDP based
protocols implement no congestion control at all. I cringe at the
thought of running NFS across the Internet.

2) Without TOS priority, all datagrams are considered equal. Routing
protocols suffer just as much from congestion as other protocols, but
consequences are much more severe.  Nowhere in the Internet (that I
know of) are the datagrams that are used for the exchange of routing
information given precedence over others.

3) As John Nagle describes, congestion collapse is inevitable in
situations where transport protocols send more packets into the
network in response to congestion. Furthermore, I know of no
point-to-point networks that are designed to run steady-state at or
above maximum capacity. They all assume that the network will be
lightly loaded. Some networks (e.g. the ARPANET) take steps that
guarantee this.

4) In order for best effort systems to work well, transport protocols
must practice congestion avoidance. Congestion control deals with
congestion once it exists, congestion avoidance is aimed at keeping
congestion from ever reaching the point where the congestion control
mechanism kicks in. Congestion avoidance aims to run the network at
maximum throughput *AND* minimum delay.

Consider TCP: its window tends to open as far as it can (8 packets at
1/2K each). The network is forced to buffer the entire window of
packets.  If the two endpoints are separated by a slow speed link,
most of the packets will be buffered there. Congestion and delay
increase.  Congestion could be reduced without reducing throughput by
decreasing the size of the window. In reality, TCP won't do anything
unless a packet is dropped, or a source quench is received. A new
mechanism is needed to distinguish between high delays due to
congestion from those due to the transmission media (e.g. satellite
vs. terrestrial links).

Raj Jain's work deserves close study in this regard.

5) In the present Internet, congestion avoidance is a dream. That
pushes congestion control/avoidance into the gateways and physical
networks. In many systems, congestion control simply resorts to
dropping the packet that just arrived that can't be put anywhere. Some
of the issues:

a. Fairness: He who transmits the most packets, gets the most
resources. This discourages well-tuned protocols, and encourages
antisocial behavior.

b. "Fair queuing" schemes limit the resources that a particular class
of packets can allocate. For instance, Dave Mills' selective
preemption scheme limits buffer space according to source IP
addresses.

There are fairness issues here too. All connections and protocols from
the same source are lumped into the same class. Does the "right" thing
happen when a TCP connection competes with a NETBLT connection?

c. Queuing strategies increase rather than decrease the per-packet
overhead. Furthermore, the information used to group datagrams into
classes must be readily available. In the worst case, you have to be
able to parse higher layer packet headers.

d. These queuing strategies rely entirely on local rather than global
information. It may be that 90% rather than 20% of the packets should
be discarded; a link two hops away might be even more congested. 

6) Because of (1) above, physical network designers should give
considerable thought to congestion control/avoidance.

The ARPANET practices congestion avoidance. That is one of the biggest
reasons that one of the oldest networks, based on "old" and "obsolete"
technology still works extremely well in today's environment.  People
should be much more careful in distinguishing between the ARPANET and
the Internet.  For instance, "the ARPANET is congested", usually
really means that the gateways connected to it are congested, or the
Internet routing mechanism has broken down.

My understanding of ARPANET internals is as follows: Before packets
can be sent, an end-to-end VC is opened to to the destination IMP. I
call this type of VC "weak", because it provides VC services, but is
actually implemented as a sliding window protocol (roughly) similar to
TCP.  "Strong" VCs refer to those in which buffers and routes are
preallocated, and packet switches contain state information about the
circuits that pass through them.  Inside the ARPANET, IP packets are
fragmented into small 200+ byte datagrams that are sent through the
network using best effort delivery. The destination IMP reassembles
them and sends back an acknowledgement that advances the window.

The number of packets in the network at any given time for any given
src/dest IMP pair is limited. This essentially limits the total number
of packets in the network at any one time, resulting in one form of
congestion avoidance. Presumably the window size (8 IP packets) has
been chosen based on extensive engineering considerations.

This scheme also raises the same fairness issues described above. For
instance, should (or shouldn't) the gateways at the NSFnet/ARPANET
gateways be able to get more resources than site X?

Of course, total best effort systems have advantages over other
schemes. One is their relative simplicity, and the loose coupling
among gateways and packet switches. Another is the ability of one user
to grab a large percentage of all available network resources.
Although considered a disadvantage if the user is a broken TCP
implementation, it is necessary if a user is to expect good
performance running a well tuned bulk transfer protocol (e.g. NETBLT).

>   What is the best reference to understand how these protocols manage the
> network resources, particularly in dealing with network congestion?
> Thanks,
> David Cheriton

I too am interested in further references, especially those relating
to best effort systems.

Thomas Narten

END OF DOCUMENT