The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Jun-86 15:03:42 EDT
From:      Murray.pa@XEROX.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Adaptive SMTP Timeouts

An idea that we have found very helpful...

Our mailer keeps outgoing mail sorted by host. Hosts are split into two
categories: healthy and sick. While there is work to do on the healthy
queue, the mailer ignores the sick hosts. Whenever the mailer empties
the healthy queue, it tries the host on the front of the sick queue. (If
that fails, it gets moved to the end of the sick queue.) The idea is to
avoid having the mailer bang its head against hosts that are known to be
causing trouble.

Occasionally mail to a host that isn't really very sick takes much
longer that we would like. This happens when the sick queue is very long
and the mailer is busy so the sick queue doesn't turn over very fast. So
far, this hasn't bothered us enough to do anything about it.

Along the same lines, we also keep mail to a host sorted, but not quite
chronologically. Whenever the mailer tries to send a message and fails,
that message gets moved to the end of the queue. Occasionally, this lets
the rest of the mail get through when one particular message is
having/causing troubles.

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Jun-86 15:35:54 EDT
From:      mills@DCN6.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   On Etherbunnies and swamp creatures

Folks,

You may know the Vitalink TransLAN satellite network architecture consists of
a broadcast-type satellite channel connecting a (perhaps large) number of
local Ethernets and forming one grand and glorious global Ethernet. Clever
filtering attempts to keep local traffic off`the broadcast channel, but
Ethernet broadcast-type packets are heard everywhere. The natural, but naive,
urge is to simply splice the channel directly to the local Ethernet, which may
or may not have a path to the Internet, and watch the Etherbunnies pop out.

Hans-Werner Braun at U Michigan has been trying to connect the USAN network,
which uses TransLAN architecture, to the world with a fuzzball gateway. As
could be predicted with any Internet community where local nets and subnets
can join and leave the system willy-nilly without telling anybody about
hosts, gateways or anything, the poor fuzzball quickly drowned in the swamp.
Following is a summary of some of the issues, together with a proposal how
some of them can be resolved.

The biggest swamprat turns out to be pesky broadcasts (rwho, etc.) so beloved
by Unix hosts. One of these splashes on the local cable, probably tossed by a
j-random host on a j-random net half-way across the country with a net number
nobody ever heard before. We all know this is not an uncommon occurance even
without TransLAN.

Now, fuzzballs and probably other swamp creatures can deal with multiple
subnets on the same cable and even multiple nets on the same cable, but can't
pull Etherbunnies from a hat unless told what to do with them. Since
Hans-Werner's fuzzy was 800 miles and two networks downstream from the nearest
EGP-speaking gateway, he simply tossed the packets upstream to that gateway,
which promptly blat an ICMP unreachable back (oops) down a black hole, since
it never heard of the drat net. Well, there were quite a number of these
things, so the EGP gateway (also a fuzzy) hollered mayhem to its log file.

This experience and previous experience with Martians (bogus packets to and/or
from address 127.0.0.0) suggests that it's a mighty bad thing to allow
strictly local creatures, broadcasts or otherwise, to escape their native
swamps. I propose that a filtering mechanism be included in the gateway
requirements specified in RFC-985. The mechanisms amounts to deleting packets
with IP destination addresses falling into certain ranges. A gateway receiving
such a packet would not forward it or return any packet whatsoever in
response. This means no ICMP messages, no ARPs replies or nothin'. If the
gateway is also acting as a local host, it may in fact take action, but only
in a context strictly local to the same network.

Following is a list of these addresses. Some of these are called out in
RFC-960 and designated "reserved." Others are called out in RFC-922 and
elsewhere and designated "local broadcast." The remaining are called out in
RFC-960 and designated "local use." These are intended for use by diskless
things that may come on-cable with incomplete configuration information and
need to determine their particular environment by interaction with a local
agent. The interpretation and use of the address and mask are described in
RFC-950, among other places.

(* = "don't care")   1                   2                   3   
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class/Description	Address			Mask
-----------------	-------			----
A reserved		000.000.000.000		255.000.000.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|* * * * * * * *|* * * * * * * *|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A reserved		127.000.000.000		255.000.000.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1|* * * * * * * *|* * * * * * * *|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A local use		000.000.000.000		128.255.255.255
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-k-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 * * * * * * *|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A local broadcast	000.255.255.255		128.255.255.255
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 * * * * * * *|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B reserved		128.000.000.000		255.255.000.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|* * * * * * * *|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B reserved		191.255.000.000		255.255.000.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 1 1 1 1 1 1|1 1 1 1 1 1 1 1|* * * * * * * *|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B local use		128.000.000.000		192.000.255.255
+-+-+m+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 * * * * * *|* * * * * * * *|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B local broadcast	128.000.255.255		192.000.255.255
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 * * * * * *|* * * * * * * *|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C reserved		192.000.000.000		255.255.255.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C reserved		223.255.255.000		255.255.255.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C local use		192.00p.000.000		224.000.000.255
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 * * * * *|* * * * * * * *|* * * * * * * *|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C local broadcast	192.000.000.255		224.000.000.255
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 * * * * *|* * * * * * * *|* * * * * * * *|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D reserved		224.000.000.000		224.000.000.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 * * * * *|* * * * * * * *|* * * * * * * *|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that the above has no provision for subnets as described in RFC-950.
Assuming the gateway configuration includes the subnet address(es) and
mask(s), one simply adds entries to the above list in the obvious way.

There has been some discussion on how to deal with proliferated broadcasts
by using information implicit in the local-net (subnetwork) address. I believe
on the basis of clarity, simplicity and separation of function that this is
not the right answer.

Dave
-------

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      02-Jun-86 18:45:15-UT
From:      mills@dcn6.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   On Etherbunnies and swamp creatures
Folks,

You may know the Vitalink TransLAN satellite network architecture consists of
a broadcast-type satellite channel connecting a (perhaps large) number of
local Ethernets and forming one grand and glorious global Ethernet. Clever
filtering attempts to keep local traffic off`the broadcast channel, but
Ethernet broadcast-type packets are heard everywhere. The natural, but naive,
urge is to simply splice the channel directly to the local Ethernet, which may
or may not have a path to the Internet, and watch the Etherbunnies pop out.

Hans-Werner Braun at U Michigan has been trying to connect the USAN network,
which uses TransLAN architecture, to the world with a fuzzball gateway. As
could be predicted with any Internet community where local nets and subnets
can join and leave the system willy-nilly without telling anybody about
hosts, gateways or anything, the poor fuzzball quickly drowned in the swamp.
Following is a summary of some of the issues, together with a proposal how
some of them can be resolved.

The biggest swamprat turns out to be pesky broadcasts (rwho, etc.) so beloved
by Unix hosts. One of these splashes on the local cable, probably tossed by a
j-random host on a j-random net half-way across the country with a net number
nobody ever heard before. We all know this is not an uncommon occurance even
without TransLAN.

Now, fuzzballs and probably other swamp creatures can deal with multiple
subnets on the same cable and even multiple nets on the same cable, but can't
pull Etherbunnies from a hat unless told what to do with them. Since
Hans-Werner's fuzzy was 800 miles and two networks downstream from the nearest
EGP-speaking gateway, he simply tossed the packets upstream to that gateway,
which promptly blat an ICMP unreachable back (oops) down a black hole, since
it never heard of the drat net. Well, there were quite a number of these
things, so the EGP gateway (also a fuzzy) hollered mayhem to its log file.

This experience and previous experience with Martians (bogus packets to and/or
from address 127.0.0.0) suggests that it's a mighty bad thing to allow
strictly local creatures, broadcasts or otherwise, to escape their native
swamps. I propose that a filtering mechanism be included in the gateway
requirements specified in RFC-985. The mechanisms amounts to deleting packets
with IP destination addresses falling into certain ranges. A gateway receiving
such a packet would not forward it or return any packet whatsoever in
response. This means no ICMP messages, no ARPs replies or nothin'. If the
gateway is also acting as a local host, it may in fact take action, but only
in a context strictly local to the same network.

Following is a list of these addresses. Some of these are called out in
RFC-960 and designated "reserved." Others are called out in RFC-922 and
elsewhere and designated "local broadcast." The remaining are called out in
RFC-960 and designated "local use." These are intended for use by diskless
things that may come on-cable with incomplete configuration information and
need to determine their particular environment by interaction with a local
agent. The interpretation and use of the address and mask are described in
RFC-950, among other places.

(* = "don't care")   1                   2                   3   
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class/Description	Address			Mask
-----------------	-------			----
A reserved		000.000.000.000		255.000.000.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|* * * * * * * *|* * * * * * * *|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A reserved		127.000.000.000		255.000.000.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1|* * * * * * * *|* * * * * * * *|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A local use		000.000.000.000		128.255.255.255
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-k-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 * * * * * * *|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A local broadcast	000.255.255.255		128.255.255.255
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 * * * * * * *|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B reserved		128.000.000.000		255.255.000.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|* * * * * * * *|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B reserved		191.255.000.000		255.255.000.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 1 1 1 1 1 1|1 1 1 1 1 1 1 1|* * * * * * * *|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B local use		128.000.000.000		192.000.255.255
+-+-+m+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 * * * * * *|* * * * * * * *|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B local broadcast	128.000.255.255		192.000.255.255
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 * * * * * *|* * * * * * * *|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C reserved		192.000.000.000		255.255.255.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C reserved		223.255.255.000		255.255.255.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C local use		192.00p.000.000		224.000.000.255
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 * * * * *|* * * * * * * *|* * * * * * * *|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C local broadcast	192.000.000.255		224.000.000.255
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 * * * * *|* * * * * * * *|* * * * * * * *|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D reserved		224.000.000.000		224.000.000.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 * * * * *|* * * * * * * *|* * * * * * * *|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that the above has no provision for subnets as described in RFC-950.
Assuming the gateway configuration includes the subnet address(es) and
mask(s), one simply adds entries to the above list in the obvious way.

There has been some discussion on how to deal with proliferated broadcasts
by using information implicit in the local-net (subnetwork) address. I believe
on the basis of clarity, simplicity and separation of function that this is
not the right answer.

Dave
-------
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Jun-86 02:20:26 EDT
From:      HEDRICK@RED.RUTGERS.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   more interesting features of 4.2

I have finally found a mechanism that seems to work for getting Suns
to route automatically.  It turns out that you can specify
routing entries that will cause a host to treat destinations on that
network as local.  I.e. it will issue ARP's for them, just as if
they were on the local Ethernet.  The correct form is
   route add 0 <local-host-address>
if you want to set this up as a default.  It turns out that all of
our diskless Sun 3's come up with such a default address
automatically.  We believe that this is due to a bug, but it is a
fairly happy one, from my point of view.  I have modified our
gateway software to be able to handle a network where the hosts
issue ARP's for everyone.  The gateway responds to ARPs for hosts
on the other side of the gateway.  It also responds to ARPs for
hosts on the other side of gateways that don't know about the
convention (giving their Ethernet address, of course, not its own --
this is an ARP-level equivalent of an ICMP redirect).  This strategy
has a number of advantages from my point of view:
  - it requires no action on the part of the user, at least until
	Sun fixes their bug, if it is one.
  - the entry need not have wired-in knowledge of the gateway's
	address.  If we change gateway configurations, this will
	continue to work.
  - if we have more than one gateway, and they talk to each other,
	we can take advantage of their redundancy, since we
	don't have specific routings built into the table.
I'm sure the gateway committee will come up with a more elegant
way to do things, but this looks like the best alternative to the
problem I have been posing for some time.  It involves no
modification to Unix, does not depend upon hosts failing to
validate ICMP redirects, etc.
-------

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Jun-86 10:40:00 EDT
From:      DCP@SCRC-QUABBIN.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Adaptive SMTP Timeouts


    Date: Mon, 2 Jun 86 12:03:42 PDT
    From: Murray.pa@Xerox.COM

    An idea that we have found very helpful...

    Our mailer keeps outgoing mail sorted by host. Hosts are split into two
    categories: healthy and sick. While there is work to do on the healthy
    queue, the mailer ignores the sick hosts. Whenever the mailer empties
    the healthy queue, it tries the host on the front of the sick queue. (If
    that fails, it gets moved to the end of the sick queue.) The idea is to
    avoid having the mailer bang its head against hosts that are known to be
    causing trouble.

We do something like this.  We keep track of up and down hosts, and when
processing mail skip the hosts that are believed down.  Therefore, we
don't concentrate on one particular host (which might drive that host
crazy).  I think we do it this way because one message is often destined
for many hosts.

    Occasionally mail to a host that isn't really very sick takes much
    longer that we would like. This happens when the sick queue is very long
    and the mailer is busy so the sick queue doesn't turn over very fast. So
    far, this hasn't bothered us enough to do anything about it.

Obvious solution: Periodically declare sick hosts up, or slightly more
conservatively, declare the host suitable for a probe.  If it really is
sick, you'll know soon enough.  You only have to do this for one
message.  If it isn't sick, you can requeue the tardy messages.

    Along the same lines, we also keep mail to a host sorted, but not quite
    chronologically. Whenever the mailer tries to send a message and fails,
    that message gets moved to the end of the queue. Occasionally, this lets
    the rest of the mail get through when one particular message is
    having/causing troubles.

When a message is causing troubles, how long does it take a human to
realize it and take corrective action.  If it stayed at the head of the
queue, I can imagine a human would notice sooner by either having no
mail get through at all, or the queue for the troublesome host keeps
growing instead of stays at some "respectable" number.

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Jun-86 14:24:53 EDT
From:      MILLS@USC-ISID.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: more interesting features of 4.2

In response to the message sent  3 Jun 86 02:20:26 EDT from HEDRICK@RED.RUTGERS.EDU

Charles,

I think what you have accomplished is what has been viariously called
the "ARP hack" or "promiscuous redirects." The technique has been proposed
as a convenient way of transition to the subnet scheme proposed in RFC-950
and specified as a requirement in RFC-985. The technique has its own peculiar
hazards and is viewed by some as outright dangerous. Nevertheless, it has
proven useful in cases like yours (and ours). What this all means is that
the Sun implementation could be considered a feature, not a bug.

Dave
-------

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 1986 14:24:53 EDT
From:      MILLS@USC-ISID.ARPA
To:        HEDRICK@RED.RUTGERS.EDU, tcp-ip@SRI-NIC.ARPA
Cc:        MILLS@USC-ISID.ARPA
Subject:   Re: more interesting features of 4.2
In response to the message sent  3 Jun 86 02:20:26 EDT from HEDRICK@RED.RUTGERS.EDU

Charles,

I think what you have accomplished is what has been viariously called
the "ARP hack" or "promiscuous redirects." The technique has been proposed
as a convenient way of transition to the subnet scheme proposed in RFC-950
and specified as a requirement in RFC-985. The technique has its own peculiar
hazards and is viewed by some as outright dangerous. Nevertheless, it has
proven useful in cases like yours (and ours). What this all means is that
the Sun implementation could be considered a feature, not a bug.

Dave
-------
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Jun-86 16:22:33 EDT
From:      jsq@SALLY.UTEXAS.EDU (John Quarterman)
To:        mod.protocols.tcp-ip
Subject:   Re: more interesting features of 4.2

Perhaps there should be an RFC on the ARP hack.

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Jun-86 00:29:17 EDT
From:      JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re: more interesting features of 4.2


	RFC917 by Jeff Mogul talks about it in some length.

	Note that this approach is not advised as a general way to do
routing in the host IP layer since the ARP layer was never designed to
be a path for routing information interchange, and thus has lots of
deficiencies when so used. A socket wrench makes a poor hammer.  Jeff
lists some in his memo; there are others, such as not being able to
handle TOS routing, etc.

	Noel
-------

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Jun-86 04:15:48 EDT
From:      HEDRICK@RED.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   Re: more interesting features of 4.2

I'd rather use a socket wrench as a hammer than my bare hands.  I'm
eagerly awaiting the gateway group's proposals, and their implementation
by all of the vendors supplying systems that we use. Until then,
ARP-based routing is something that I can do that will work, and that
does not abuse any standards too badly.  I don't intend it to be for
routing information interchange in the general sense.  The gateways will
use other protocols among themselves. What I need is a way to get
information from the gateways to the hosts.

I just reread the relevant section of 917, and in fact Mogul says that
ARP-based subnetting is a reasonable strategy.  His only criticism,
other than the fact that it can only be implemented if you have
broadcasts (which of course we do), is that there may be trouble
recovering if a gateway goes down.  In fact it is no more difficult to
recover from gateway failure using ARP-based routing than using any
other scheme.  When a connection is about to time out, the system should
attempt to recompute the route.  It is just as easy to purge the ARP
entry and issue another ARP as to purge the routing entry and do
whatever you would normally do to find another routing at that level. In
fact 4.2 does neither.  But it does time out ARP entries, so eventually
it will correct routings when ARP are being used to discover routes.
Most alternative methods don't do even this well.

I am assuming that our gateways will talk to each other, and arrange it
so that the right gateway responds.  That is, if one gateway goes down,
and there is another route, the backup gateway will begin responding to
ARP requests.  In fact that gateway technology we are using (Stanford's)
has this ability.

Note that I have gone one step beyond the ARP-based subnetting described
in RFC 917, in that I also use ARP's to identify routes to hosts outside
our class B network.  We currently have 3 different gateways to 
the outside world.  One handles a single class C network.  One handles
a class B network and a class C network.  The third is our Arpanet
gateway, to which we send all other traffic.  As the supercomputer
network and other NSF-sponsored networking develop, we are likely to
start moving traffic for certain other Universities from the Arpanet
to one of the other networks.  We do not want to have to change routing
tables in every host when we make such a change.

What is TOS routing?
-------

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 1986 11:49:30 PDT
From:      POSTEL@USC-ISIB.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   re: ARP Hacks & Interesting things in ....

Hi.

People interested in ARP hacks should check this obscure memo by some
guy, it is RFC-925.

--jon.
-------
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Jun-86 09:38:35 EDT
From:      jsq@SALLY.UTEXAS.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: more interesting features of 4.2

Right.  I had assumed RFC917 was completely superseded when RFC950
came out, but I see it still has quite a bit of useful information in it.

The ARP hack has many deficiencies, as you point out, but many of us
don't have much choice since we have systems to which we don't have
the source and for which the vendor has not yet implemented subnets
(e.g., TOPS-20, Silicon Graphics, Integrated Solutions, Bridge, Sun,
VMS, Ridge, etc. ad nauseum).

Perhaps the MIT ICMP host redirect method is the better interim solution.
Does anyone have anything more to add on that than what's in RFC917?

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 1986 1256-PDT (Wednesday)
From:      Jeff Mogul <mogul@su-navajo.arpa>
To:        Charles Hedrick <HEDRICK@RED.RUTGERS.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: more interesting features of 4.2 ("ARP Hack")
	I just reread the relevant section of 917, and in fact Mogul says that
	ARP-based subnetting is a reasonable strategy.

Actually, about the nicest thing I said about it is that it is "somewhat
unsatisfactory."  I certainly did not intend this to be an excuse for
IP vendors who aren't willing/able to get their acts together.  Granted,
this is less annoying than those hosts which spray broadcasts all over
everything, or those that try to act as gateways when they aren't
supposed to, but it really isn't that hard to get this right.

I also (now) regret the term "ARP-based subnetting", for its implication
that ARP is in any way central to the use of subnets.  I don't have a
perfect term, but something like "ARP-compatible subnetting" or
"subnet-extended ARP" would be less misleading.

I sure wish people who design widely-used IP implementations would
test their bright ideas on the Internet community before shipping
half a million workstations.

-Jeff

P.S.: Noel, you warned me.
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Jun-86 11:06:38 EDT
From:      narten@PURDUE.EDU ("Thomas Narten")
To:        mod.protocols.tcp-ip
Subject:   Re: more interesting features of 4.2

>But [UNIX] does time out ARP entries, so eventually it will correct
>routings when ARP are being used to discover routes.

This is not always true. ARP entries that are not referenced for X
minutes (20 for us) are deleted. This is not the same thing as saying
IP to Ethernet mappings that aren't valid get deleted. If you continue
to try to send to a host, the ARP entry continues to get referenced and
will not time out at all. Hence, it is not clear that having paths
through multiple gateways to the same destination will always be used
the way one expects if the currently used gateway crashes.

Thomas

----------

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Jun-86 14:15:01 EDT
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: more interesting features of 4.2

In response to the message sent  4 Jun 86 04:15:48 EDT from HEDRICK@RED.RUTGERS.EDU

Charles,

I'm not sure who you mean by the "gateway group." The old Gateway Algorithms
and Data Structures (GADS) Task Force, which I chaired, has been dissolved and
precipitated into the Internet Engineering (INENG) Task Force, Chaired by
Mike Corrigan, and the Internet Architecture (INARC) Task FOrce, which I
chair. THe INENG is concerned about relatively near-term (a couple of
years) issues, while the INARC is looking further out. Both of these task
forces are concerned about gateways, among many other issues.

The NSF Network Technical Advisory Group (NTAG), which serves as advisor to
NSF staff on network issues in general, including gateways for the explosively
growing NSF Internet community, created an ad-hoc subcommittee to establish
a first cut at Internet gateway requirements in general and the NSF community
in particular. That subcommittee, also chaired by me, produced in close
cooperation with the Internet Activities Board, chaired by Dave Clark,
a working document that was published as RFC-985. You can see there is no
single "gateway group," but a number of committees and task forces very
much concerned with the issues being discussed here. The chairs mentioned
above watch this list and others for developing issues and consider them
carefully when constructing agendae and moderating meeting discussion.
Nevertheless, the issues wandering around here on gateway routing, ARP,
redirects and cranky Unix systems are incredibly complicated, easily
misunderstood and highly flame-able.

Speaking for myself and the above committees, we would very much like to
harden the model proposed in RFC-985, especially in the technical details
involved with multi-net cables, host-gateway routing, address resolution,
redirects and so forth on Ethernets, TransLANs and similar technologies.
If you have specific questions or comments you think unsuitable for this list,
you are welcome to jiggle my chain or the others mentioned in RFC-985.

Dave
-------

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Jun-86 14:49:30 EDT
From:      POSTEL@USC-ISIB.ARPA
To:        mod.protocols.tcp-ip
Subject:   re: ARP Hacks & Interesting things in ....


Hi.

People interested in ARP hacks should check this obscure memo by some
guy, it is RFC-925.

--jon.
-------

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Jun-86 15:56:00 EDT
From:      mogul@SU-NAVAJO.ARPA (Jeff Mogul)
To:        mod.protocols.tcp-ip
Subject:   Re: more interesting features of 4.2 ("ARP Hack")


	I just reread the relevant section of 917, and in fact Mogul says that
	ARP-based subnetting is a reasonable strategy.

Actually, about the nicest thing I said about it is that it is "somewhat
unsatisfactory."  I certainly did not intend this to be an excuse for
IP vendors who aren't willing/able to get their acts together.  Granted,
this is less annoying than those hosts which spray broadcasts all over
everything, or those that try to act as gateways when they aren't
supposed to, but it really isn't that hard to get this right.

I also (now) regret the term "ARP-based subnetting", for its implication
that ARP is in any way central to the use of subnets.  I don't have a
perfect term, but something like "ARP-compatible subnetting" or
"subnet-extended ARP" would be less misleading.

I sure wish people who design widely-used IP implementations would
test their bright ideas on the Internet community before shipping
half a million workstations.

-Jeff

P.S.: Noel, you warned me.

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Jun-86 17:56:00 EDT
From:      SRA@XX.LCS.MIT.EDU (Rob Austein)
To:        mod.protocols.tcp-ip
Subject:   Contact names, WKS RRs, redesigning known universe

(This is going to TCP-IP because the discussion started there.  Any
 followup should be conducted on NAMEDROPPERS, I think.)

I'd like to (belatedly) second Joe Weening's suggestion that we use
the domain system to supply a contact name service.

If we were designing the Internet from scratch, I'd say to use
Chaosnet style contact names, which are a big win.  But we're not
designing from scratch.

Using the domain system would solve two distinct problems that have
arisen lately.  One is the contact-names problem under discussion on
TCP-IP, the other is the inadaquacy of the current IN WKS RR format
(see NAMEDROPPERS archives for details).

Here's my proposed RR formats

<service>.<domain-name>	 IN	SERV	<ip-address> <port>
<service>.<domain-name>	 CH	SERV	<chaos-address>

<Service> is the service name (contact name analog).  Domain name is
the name of the host supporting it.  <Ip-address> and <chaos-address>
are as in A RRs (note that <chaos-address is two fields, see
NAMEDROPPERS archives).  <port> is a 16 bit port number.  Chaosnet
doesn't need this, since chaosnet has contact names, but it would be
nice to be able to have a WKS analog for Chaosnet.

The address fields are there for the same reason as in the WKS RR;
some host might offer different services on different network
interfaces.  I'm not convinced this is reasonable, but it was
considered necessary in the original WKS format.  We might want to add
a <ip-protocol-number> field to the IN class format, same logic (the
analog for Chaosnet would be another text string)

Examples:

SMTP.XX.LCS.MIT.EDU	IN SERV		10.0.0.44	25
TFTP.XX.LCS.MIT.EDU	IN SERV		10.0.0.44	69
FILE.XX.LCS.MIT.EDU	CH SERV		MIT.EDU		2420
TIME.XX.LCS.MIT.EDU	CH SERV		MIT.EDU		2420

or (with protocols ids)

SMTP.XX.LCS.MIT.EDU	IN SERV		10.0.0.44	6	25
TFTP.XX.LCS.MIT.EDU	IN SERV		10.0.0.44	17	69
FILE.XX.LCS.MIT.EDU	CH SERV		MIT.EDU		2420	CHANNEL
TIME.XX.LCS.MIT.EDU	CH SERV		MIT.EDU		2420	SIMPLE

We might also want to put RRs for all the standard services (ie, the
ones known to the protocol czar) in at the root node.  This would be
useful for people who want to code with a contact name approach, and
shouldn't be too much overhead.

Queries like {IN SERV *.XX.LCS.MIT.EDU} should work fine and give a
series of RRs listing all funny IP protocols supported by XX.

I think this proposal solves serveral problems without creating any
new ones.  It is not the optimal solution to the contact name problem,
but it will work and uses existing technology.

Comments?

--Rob

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Jun-86 00:11:33 EDT
From:      JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re: more interesting features of 4.2


	The so-called 'MIT ICMP' thing is not a change to the spec,
merely one of way doing things of the ways allowed by the spec. There
really isn't a lot to say beyond what's in RFC917.
	The 'ARP hack' is necessary for some machines since the
per-host ICMP thing doesn't work if the source host doesn't realize
that the destination is on another wire.

	Noel
-------

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Jun-86 00:14:06 EDT
From:      dan@NGP.UTEXAS.EDU (Dan Reynolds)
To:        mod.protocols.tcp-ip
Subject:   4.2 TCP question

A question on 4.2 BSD TCP: what is the proper response to a "keep-alive"
packet for which the receiving TCP can find no TCB? According to the
RFC, the correct response is to generate a segment bearing an RST and
formulate the SEG.SEQ and SEG.ACK so as to make them acceptable.

My TCP implementation did exactly that. However, the 4.2 TCP on the other
end blithely continued to send segments to the non-existent TCB in complete
defiance of the RST's. Does anyone know why (more precisely, has anyone
seen this type of behavior before)?

Dan Reynolds <dan@ngp.utexas.edu>
Computation Center
The University of Texas at Austin
Austin, TX 78712

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Jun-86 14:53:00 EDT
From:      Vinograd@MIT-MULTICS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: tn3270

Greg:

As you know, we sucessfully ported an early version of tn3270 to a Sun,
and now support the terminal negociation both for our client and server
telnet.  We would like to update our copy with the latest version.  How
can I arrange to get the latest source ?

We are also trying to move the current version to a Masscomp, and are
having problems interfacing to the Masscomp window system, in full
screen mode.  Do you know of anyone who has done such a port, name/phone
number or EM address would be most useful.

Thanks in advance

Dave Vinograd (Spartacus)

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Jun-86 17:18:12 EDT
From:      robert@SRI-SPAM.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   tcp on SUN computers.


Hello there,

	I have a question regarding the implementation of TCP
used on the SUN computers.  Specifically the question concerns
version 2.2 of SUN UNIX, but will no doubt extend to their later
(and earlier) releases.

	The question follows;

	I have had occasion to use non-blocking sockets (TCP links)
as a link across the Internet between 2 or more SUNs.  Empirically,
I have discovered that there is a limit of 2048 bytes which can
be written in a single non-blocking write.  Anything more than
that and an error is returned "EMSGSIZE", which indicates that
the internal buffer is only 2048 bytes.  Note that if I use
blocking sockets, the size is unlimited.  There is also a limit
of 4096 bytes total which can be held "in the pipe", before the
receiving side of the socket must do a read to clear the internal
buffers.
	In a Client/Server relationship, the server will read
the bytes which the client writes into the socket.  I've noticed
that with non-blocking sockets where greater than 2K bytes can
be written, that continuous calls to recv() or read() by the server
will return 2K byte chunks.  This leads me to believe that the
SUN implementation can only handle a max of 2K byte transfers, and
with only two of these before a read must be done.  I've talked
with SUN tech support and they tell me that this 'seems to be'
the case, although without talking directly to an engineer I could
not get a good idea of why this is.
	Finally, my question is this.  Why is there a 2K limit, and
can it be changed, perhaps with a kernal reconfiguration?  It seems
to me that putting such a limit on the sockets is a poor implementation
for that layer, which should not restrict data size.  Shouldn't
such 'packetizing' be done at a lower layer than what sockets are
the entry point to?  Or are sockets actually a lower layer interface
than I think?

	Any comments, pointers, or commiserations would be greatly
appreciated.

					Robert Allen

					(415) 859-2143,

					robert@sri-spam.ARPA

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Jun-86 21:22:32 EDT
From:      root@BU-CS.BU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  tcp on SUN computers.


There are two questions in your query,

1.> ...Finally, my question is this.  Why is there a 2K limit, and
>can it be changed, perhaps with a kernal reconfiguration?  

It almost certainly can be changed given sources, perhaps it can be
changed otherwise or perhaps that is a suggestion that might be
reasonable for binary sites. Perhaps for performance reasons it
doesn't make sense to change this (what is a better number and why?
Simply that it would make it easier for you to ignore the fact that
you are doing non-blocking I/O is not a great reason.)

2.> It seems
>to me that putting such a limit on the sockets is a poor implementation
>for that layer, which should not restrict data size.  Shouldn't
>such 'packetizing' be done at a lower layer than what sockets are
>the entry point to?  Or are sockets actually a lower layer interface
>than I think?

This is a different question. Most importantly you state that this
occurs only with non-blocking I/O.

In the first place, this is not 'packetizing'. You provided 2K bytes
and it received 2K bytes (and made it available to your consumer
process.) The fact that they are both the same size is neither a
coincidence nor a fault of the implementation. Something like packetizing
might be implied had you read less than 2K and found the difference
thrown off the floor (I guess, not sure there is any way this term
can be worked into this conversation sensibly.)

At some point a resource runs out, there is no way around that. On
blocking (normal mode) I/O this results in a the process being blocked
and waiting until resources are available. When you requested non-blocking
I/O the system still had to do *something* when resources ran out (as
I said, exactly how much of this resource should be allocated to a given
process is an entirely different question.) What would you suggest it
do? Ignore your I/O? Do it "anyhow"? Block you "anyhow"? I think it
is doing the right thing (telling you immediately that I/O is not possible
right now.)

I think this was simply necessitated by allowing the user to specify
non-blocking I/O, there is no fundamental difference between this and
blocking I/O except the reason you felt it was "unlimited" in the latter
case was only because the system took the responsibility for making you
wait, as soon as you requested non-blocking I/O you stated that you
wished to take that responsibility on yourself (ie. you probably had
something else to do while waiting.)

>Robert Allen

	-Barry Shein, Boston University

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Jun-86 22:16:23 EDT
From:      mike@BRL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  tcp on SUN computers.

Sockets themselves buffer a limited amount of data.  The size of this socket
buffering varries, depending on the type of socket (ie, pipe, TCP, UDP,
etc).

The system-wide default for TCP and UDP can be changed in 4.2 and 4.3 VAX
UNIX systems by using ADB to poke the kernel variables tcp_sendspace and
tcp_recvspace and udp_sendspace and udp_recvspace.  These variables become
parameters to the soreserve() routine each time a connection is opened.

Note that in 4.2 the maximum size is 31k, in 4.3 it is 64k-1.  These values
are stored in the socket structure in SHORT ints; in 4.2 if the sign bit
comes on, the world will break, thus the 31k limit rather than 32k or 64k-1.
These variables can not casually be increased to LONG ints, because that
would cause the socket struct not to fit into an MBUF, which is currently
necessary, if a tad inelegant.  31k of buffering on each end is, in fact,
quite reasonable.

Also note that in 4.3 there is a parameter to the setsockopt() sys-call that
can be used to adjust these values on a per-connection basis, rather than
having to change the system-wide defaults.  For those of you that have
this, this is the preferred method of increasing buffering.

I don't know at which SUN version the 4.3 capabilities will emerge, but
almost certainly not in SUN 2.x (but I don't actually know).

	Best,
	 -Mike Muuss

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Jun 86 22:16:23 EDT
From:      Mike Muuss <mike@BRL.ARPA>
To:        Robert Allen <robert@sri-spam.arpa>
Cc:        tcp-ip@sri-nic.arpa, unix-wizards@BRL.ARPA
Subject:   Re:  tcp on SUN computers.
Sockets themselves buffer a limited amount of data.  The size of this socket
buffering varries, depending on the type of socket (ie, pipe, TCP, UDP,
etc).

The system-wide default for TCP and UDP can be changed in 4.2 and 4.3 VAX
UNIX systems by using ADB to poke the kernel variables tcp_sendspace and
tcp_recvspace and udp_sendspace and udp_recvspace.  These variables become
parameters to the soreserve() routine each time a connection is opened.

Note that in 4.2 the maximum size is 31k, in 4.3 it is 64k-1.  These values
are stored in the socket structure in SHORT ints; in 4.2 if the sign bit
comes on, the world will break, thus the 31k limit rather than 32k or 64k-1.
These variables can not casually be increased to LONG ints, because that
would cause the socket struct not to fit into an MBUF, which is currently
necessary, if a tad inelegant.  31k of buffering on each end is, in fact,
quite reasonable.

Also note that in 4.3 there is a parameter to the setsockopt() sys-call that
can be used to adjust these values on a per-connection basis, rather than
having to change the system-wide defaults.  For those of you that have
this, this is the preferred method of increasing buffering.

I don't know at which SUN version the 4.3 capabilities will emerge, but
almost certainly not in SUN 2.x (but I don't actually know).

	Best,
	 -Mike Muuss
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Jun-86 03:21:52 EDT
From:      BLARSON@USC-ECLB.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   problems reaching cu20b

I frequently have problems trying to get files from cu20b.columbia.edu
using ftp from either usc-eclb.arpa (milnet) or usc-oberon.arpa
(arpanet).  Tops-20 ftp (usc-eclb.arpa) gives the message "connection
rejected for unknown reason" and 4.2bsd ftp (usc-oberon.arpa) gives
the message "network unreachable".   (This is the second night in a row
this week, and I have had similar problems before.)  I have also had
many mail messages returned with "system unreachable" after three days
through both usc-ecl.arpa (milnet) and usc-eclc.arpa. (arpanet)  (both
Tops-20)

Apparently cu20b.columbia.edu (also a tops-20 machine) has no problems
sending mail to us, we get the info-kermit digest regularly.  Neither
the local postmaster or the info-kermit people seem to know a reason
for this problem.

Where is the proper place to report this type of problem?

Are other people experiencing it to?

Mail can be gotten through by routing via other systems.  (I used to
use columbia.arpa, but it no longer understands the % hack and I
haven't figured out out to specify an @host1:user@host2 address to
tops-20 mm.)  For ftp, I just keep trying until it decides to work.

Bob Larson <Blarson@Usc-Ecl.Arpa>
-------

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Fri 6 Jun 86 07:53:39-PDT
From:      Karl Auerbach <AUERBACH@SRI-CSL.ARPA>
To:        robert@SRI-SPAM.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, AUERBACH@SRI-CSL.ARPA
Subject:   Re: tcp on SUN computers.
This may be incorrect, but I have heard that 4.2/4.3 based TCP
implementations set the push flag for every user write.  This
somewhat transforms the TCP stream into packets as viewed by the
receiver.

I'm sure someone out there knows whether this is true or not.

			--karl--  (Karl Auerbach, Epilogue Technology Corp.)
			auerbach@sri-csl.arpa
-------
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Jun-86 10:53:39 EDT
From:      AUERBACH@SRI-CSL.ARPA (Karl Auerbach)
To:        mod.protocols.tcp-ip
Subject:   Re: tcp on SUN computers.

This may be incorrect, but I have heard that 4.2/4.3 based TCP
implementations set the push flag for every user write.  This
somewhat transforms the TCP stream into packets as viewed by the
receiver.

I'm sure someone out there knows whether this is true or not.

			--karl--  (Karl Auerbach, Epilogue Technology Corp.)
			auerbach@sri-csl.arpa
-------

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Jun-86 13:33:59 EDT
From:      minshall%ucbopal@UCBVAX.BERKELEY.EDU (Greg Minshall)
To:        mod.protocols.tcp-ip
Subject:   Re: tn3270

Dave,
	You can do an anonymous ftp to ucbarpa, cwd to pub, and pick up
tn3270tar.  This version is as of last December, but I only know of one change
since then (and it wasn't major).

	I'm currently working on a PC version, but maybe I will be able to
stop for a bit and package up the current version for you.

Greg

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Jun-86 14:34:32 EDT
From:      melohn%sluggo@SUN.COM (Bill Melohn)
To:        mod.protocols.tcp-ip
Subject:   Re:  problems reaching cu20b

Chances are good that the network which cu20b is on has fallen out of
the limited size EGP reachablity table that you (or more likely your
core gateway) use. This appears to happen to our non-backbone network
every once in a while.  The solution is to get more powerful core
gateways that implement EGP and provide more space for the ever
increasing numbers of non-backbone internet networks. If access to cu20b
is really important to your site, you might consider adding the entry
for the columbia gateway to ECLx's INTERNET.GATEWAYS file. That way you
will not have to ask your core gateway how to get to cu20b.  

Bill

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7-Jun-86 00:20:42 EDT
From:      mills@DCN6.ARPA
To:        mod.protocols.tcp-ip
Subject:   Here's clocking at you

Folks,

I know this must be Summer because our radio clocks are drowning in ionspheric
ooze, which sloshes deeper as the days grow long. Yesterday our WWVB clock on
popular fuzzball timeteller DCN1.ARPA picked up a hot bit which added 256 days
to the day of year and turned its timecode-conversion routine into a hash
function. The resulting random bits presented to timecallers broke a bunch of
code scattered all over the Internet, or at least that's what I concluded once
the phones stopped ringing.

When I manually disabled the broken clock, our clever backup algorithm, put in
last year at this time when the ions grew dim, promptly chose the WWV clock on
DCN6.ARPA. But that was bust too, so the algorithm chose as the next backup
the GOES clock on FORD1.ARPA and finally got it right. It turns out this
sequence of events is not uncommon at this time of year; however, before you
pull your clock plugs, be advised there are two more backups, the WWVB clock
on UMD1.ARPA and the WWV clock on GW.UMICH.EDU. I guess you could say we have
a magnificent, redundant algorithm which reliably delivers the wrong time.

This latest problem should not recur, since I sloshed ample bugspray on the
conversion routine to nip blatant timecode lies, but little lies (like the
wrong year) are known from experience to be just as bad. Therefore, I sieze
the opportunity first to apologize for all those broken message timestamps,
file dates and accounting programs that bogged yesterday and then to appeal
for more players of the Network Time Protocol (RFC-958) game, which may be the
best polygraph.

Dave
-------

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      07-Jun-86 03:56:37-UT
From:      mills@dcn6.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   Here's clocking at you
Folks,

I know this must be Summer because our radio clocks are drowning in ionspheric
ooze, which sloshes deeper as the days grow long. Yesterday our WWVB clock on
popular fuzzball timeteller DCN1.ARPA picked up a hot bit which added 256 days
to the day of year and turned its timecode-conversion routine into a hash
function. The resulting random bits presented to timecallers broke a bunch of
code scattered all over the Internet, or at least that's what I concluded once
the phones stopped ringing.

When I manually disabled the broken clock, our clever backup algorithm, put in
last year at this time when the ions grew dim, promptly chose the WWV clock on
DCN6.ARPA. But that was bust too, so the algorithm chose as the next backup
the GOES clock on FORD1.ARPA and finally got it right. It turns out this
sequence of events is not uncommon at this time of year; however, before you
pull your clock plugs, be advised there are two more backups, the WWVB clock
on UMD1.ARPA and the WWV clock on GW.UMICH.EDU. I guess you could say we have
a magnificent, redundant algorithm which reliably delivers the wrong time.

This latest problem should not recur, since I sloshed ample bugspray on the
conversion routine to nip blatant timecode lies, but little lies (like the
wrong year) are known from experience to be just as bad. Therefore, I sieze
the opportunity first to apologize for all those broken message timestamps,
file dates and accounting programs that bogged yesterday and then to appeal
for more players of the Network Time Protocol (RFC-958) game, which may be the
best polygraph.

Dave
-------
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1986 23:03:43 PDT
From:      Stephen Casner <Casner@USC-ISIB.ARPA>
To:        Mike Muuss <mike@BRL.ARPA>
Cc:        Robert Allen <robert@SRI-SPAM.ARPA>, tcp-ip@SRI-NIC.ARPA, unix-wizards@BRL.ARPA, Casner@USC-ISIB.ARPA
Subject:   Re:  tcp on SUN computers.
I have found that with Sun release 2.0 "the world will break" if I patch
tcp_sendspace and tcp_recvspace to be only 16K, not 32K.  At 15K it works,
but 16K crashes.  I would like very much to get up to 31K because we need
that much for efficient use of the Wideband Satellite Network.  Any clue
as to how I might get there?

						-- Steve Casner
-------
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Jun-86 02:03:43 EDT
From:      Casner@USC-ISIB.ARPA (Stephen Casner)
To:        mod.protocols.tcp-ip
Subject:   Re:  tcp on SUN computers.

I have found that with Sun release 2.0 "the world will break" if I patch
tcp_sendspace and tcp_recvspace to be only 16K, not 32K.  At 15K it works,
but 16K crashes.  I would like very much to get up to 31K because we need
that much for efficient use of the Wideband Satellite Network.  Any clue
as to how I might get there?

						-- Steve Casner
-------

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1986 13:01:28 PDT
From:      Stephen Casner <Casner@USC-ISIB.ARPA>
To:        nowicki%rose@SUN.COM (Bill Nowicki)
Cc:        Casner@USC-ISIB.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: tcp on SUN computers.
I borrowed the quote about the world breaking from Mike Muuss.  What I
meant by it was that with tcp_sendspace and tcp_recvspace patched to
16K in a 2.0 kernel, the system crashed during the process of booting.
I don't remember the details of the crash, but I believe it was a panic
or the like.

I'd like very much to have my machine upgraded to 3.x, but first we have
to buy more memory => more swap space => no user file space => more NFS
space...
						-- Steve Casner
-------
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Jun-86 14:51:02 EDT
From:      nowicki%rose@SUN.COM (Bill Nowicki)
To:        mod.protocols.tcp-ip
Subject:   Re: tcp on SUN computers.


	I have found that with Sun release 2.0 "the world will break"
	if I patch tcp_sendspace and tcp_recvspace to be only 16K, not
	32K.  At 15K it works, but 16K crashes.

Please clarify what you mean by "world will break".  Last week I did
some tests and tried various sizes like 16K and 32K without any
"crashes".  There is a severe performance problem if one side has a
large recvspace and the other has a sendspace that is less than or
equal to one quarter of the recvspace. The "silly window syndrome
avoidance feature" then takes effect, and you can send only five times
the sendspace per second.  For example, if a machine with increased
recvspace (8K) sends to a machine with the default sendspace of 2K,
then throghput is 10Kbytes/second, about twenty times slower than 2K
sending to 2K!  This is probably true for 4.2 in general, but have
not tried the 4.3BSD SWSA code.

Note that my experiments are using Sun-3s running 3.x -- you should
upgrade from 2.x as soon as you can, since 3.x has several of the 4.2BSD
bugs removed.

	-- Bill Nowicki
	   Sun Micsrosystems

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Jun-86 16:01:28 EDT
From:      Casner@USC-ISIB.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: tcp on SUN computers.

I borrowed the quote about the world breaking from Mike Muuss.  What I
meant by it was that with tcp_sendspace and tcp_recvspace patched to
16K in a 2.0 kernel, the system crashed during the process of booting.
I don't remember the details of the crash, but I believe it was a panic
or the like.

I'd like very much to have my machine upgraded to 3.x, but first we have
to buy more memory => more swap space => no user file space => more NFS
space...
						-- Steve Casner
-------

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Jun-86 18:47:30 EDT
From:      matt@oddjob.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: more interesting features of 4.2


	It turns out that you can specify routing entries that
	will cause a host to treat destinations on that network
	as local.  I.e. it will issue ARP's for them, just as if
	they were on the local Ethernet.  The correct form is
	   route add 0 <local-host-address>
	if you want to set this up as a default.

I tried "route add usan-net oddjob 0" some time ago, trying to
access the USAN satellite net through our VitaLink box.  This
works to NCAR (where all hosts' addresses are on usan-net) if
they do the corresponding operation on their end.  The trouble
comes when you want to specify that a host on the other net is a
gateway to yet another net.  The route-adding code insists that
you can't do it.

I then wrote a pseudo-interface driver which claims an interface
address of "oddjob" (192.5.73.2) but a broadcast address of
"usan-net" (192.17.4.0).  This works OK (I'm still using it),
but still has some drawbacks.  One is that the other end (U of I
at Urbana in this case) would have to put up a similar pseudo-
interface on their gateway to usan-net before their networks and
our networks are fully connected.  Another is that broadcasts
such as RIP packets sent to usan-net generate ICMP messages from
other hosts on the local net here.

I don't think any arrangement will really work satisfactorily if
it has bridges connecting nets with different IP numbers.

		Matt Crawford

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Jun-86 09:11:10 EDT
From:      louden@MITRE-GATEWAY.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   RFC 986 Questions

I have a few questions about RFC 986.

First, I have a LAN that is both connected to a PDN and the
ARPANET.  Which addressing method do I use?

Second, what does TCP do for a pseudo header (It contains the IP addresses)
when there are no IP address in X.121 across a PDN?

This may be a can of worms better addressed by saying you use all ISO or
all DoD but not both mixed.

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 1986  9:11:10 EDT (Wednesday)
From:      T. Michael Louden (MS W422) <louden@mitre-gateway.arpa>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        louden@mitre-gateway
Subject:   RFC 986 Questions
I have a few questions about RFC 986.

First, I have a LAN that is both connected to a PDN and the
ARPANET.  Which addressing method do I use?

Second, what does TCP do for a pseudo header (It contains the IP addresses)
when there are no IP address in X.121 across a PDN?

This may be a can of worms better addressed by saying you use all ISO or
all DoD but not both mixed.
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Jun-86 10:34:49 EDT
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: more interesting features of 4.2

In response to the message sent  Tue, 10 Jun 86 17:47:30 cdt from  "Matt Crawford" <crawford@anl-mcs.arpa>

Matt,

USAN (192.17.4) is currently gatewayed to ARPANET via a fuzzball at
U Michigan on an experimental basis. The fuzzball gateway is gimmicked
with an incredible routing algorithm that provides connectivity for all
the j-random networks babbling on the USAN channel, as well as many
other networks that seem to be passing by from time to time. The
gimmicks include "promiscuous" ARP, dynamic logical-address translation
and multiple delay-based routing algorithms sharing the same cable. While
the experiment is somewhat of a lashup at present, the experience gained
seems to indicate that it would be practical to evolve a working standard
for multiplexing broadcast channels with arbitrary routing plexes. Whether
you want to do that on a performance basis may be another matter.

The experience with showers of redirects and unreachables in this environment
was what led to my suggestion a few days back on a standard filtering algorithm
for Internet gateways.

Hans-Werner Braun (hwb@gw-umich.edu) did most of the brain-punishing work
in evolving the techniques and making the fuzzball gateway play on USAN.

Dave
-------

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Jun-86 12:34:18 EDT
From:      HEDRICK@RED.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   how to handle Vitalink networks

We have an equivalent of your Vitalink network, using Applitek bridges.
We make sure that one gateways off that network does "promiscuous ARP".
This is a generalization of the "ARP hack" that has long been used for
subnetting.  It generalizes it by having the gateways accept an ARP for
absolutely any address at all.  If they are the appropriate gateway,
they respond with their Ethernet  address.  If not, they respond with
the Ethernet address of the correct gateway.  (If you have several
gateways that do this, you can modify the code so that a gateway
does not respond for another gateway if the second is known to be
capable of responding for itself.)  This is the ARP equivalent of an
ICMP redirect.  Note that you only need one such gateway on a network,
since it can hand out the Ethernet addresses of the other gateways. This
is the only technique we can think of that can handle complex networks
built with systems like the Vitalink and Applitek.  (I do not approve of
such bridges, but I can't prevent people from buying them, so I've had
to come up with a way to live with them.)
-------

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Jun-86 17:23:00 EDT
From:      stanonik@NPRDC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   4.3bsd/subnetting

Now that subnetting (and subnet arp support) is available,
some questions arise about using it, particularly about making
the transition to subnets.

The local network (class B) currently consists of a main cable
to which every host is directly attached.  Because subnetting
was anticipated, addresses were assigned in a subnet fashion;
ie, the third byte (intended to become the subnet number)
grouped machines.  That however seems to cause a problem for
the transition to subnets.  To any subnet branching off the main
cable, the addresses of those not yet capable of subnetting
make the main cable look like a collection of subnets.  Yuck!
4.3bsd doesn't seem to allow more than one subnet per interface
(cable), so many of those hosts will be unreachable.  A nice(?)
solution would be to continue to treat the main cable as unsubnetted
(netmask 0xffff0000) and only route to it packets not bound
for known subnets, but 4.3bsd doesn't seem to do this.

Have we overlooked some routing trick, or must everyone remaining
on the main cable change addresses to one subnet number?

Thanks,

Ron Stanonik
stanonik@nprdc.arpa

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Jun-86 22:46:56 EDT
From:      mike@BRL.ARPA (Mike Muuss)
To:        mod.protocols.tcp-ip
Subject:   Re:  tcp on SUN computers.

Well, I guess for SUN 2.0, the magic number must be 16k-1.
At least this is an improvement :-)
	-M

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Jun 86 22:46:56 EDT
From:      Mike Muuss <mike@BRL.ARPA>
To:        Stephen Casner <Casner@usc-isib.arpa>
Cc:        Mike Muuss <mike@BRL.ARPA>, Robert Allen <robert@sri-spam.arpa>, tcp-ip@sri-nic.arpa, unix-wizards@BRL.ARPA, Casner@usc-isib.arpa
Subject:   Re:  tcp on SUN computers.
Well, I guess for SUN 2.0, the magic number must be 16k-1.
At least this is an improvement :-)
	-M
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Jun-86 22:50:38 EDT
From:      hwb@GW.UMICH.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: RFC986 questions

Let me make a few comments about some of the reasons behind RFC986. The 
question of mixing or not mixing protocols is an important one, though
not really, or at least only to some extend, the issue here.

What needs to be accomplished is that existing network backbones can
be utilized for ISO protocols, which includes the ISO CLNS. It
probably does not make too much sense to have, e.g., an Arpanet and an
ISO-Arpanet existing and being disjoint at the same time. Not even
on an iterim base.  It therefore becomes necessary to utilize existing
backbones (good examples here are the Arpanet and the upcoming NSFnet)
for both protocol suites, especially since these suites do not differ
that much from each other anyway.
 
RFC985 points out quite nicely that Ethernets are some kind of lowest
common denominator to which most hosts can connect. We can probably safely
assume that most gateways drop their traffic onto a local Ethernet.
If, e.g., two gateways, which are attached to the Arpanet would talk
both IP and the ISO-CLNS, while eventually utilizing the same routing
data base local to the gateway, people could talk the ISO-CLNS accross
the country. It would not matter at all what runs on top of ISOgrams
in this case. Further routing through subsequent gateways within the
local net would obviously be a local issue here. These (sub)gateways 
would have to understand both 'gram protocols, too, and, e.g., could
distinguish between them according to different Ethernet type fields
seen on the Ethernet.

RFC986 is a draft only and probably needs further refinements so that
and Internet standard could emerge which could be given to the implementors
of gateways. Suggestions for these refinements would be welcome.
 
A small committee chaired by Phil Gross (Mitre) was furthermore tasked
with coming up with suggestions for possible scenarios for RFC986, which
will (hopefully) result in a subsequent RFC. Input for this would be
appreciated, too.
 
	-- Hans-Werner
-------

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Jun-86 23:05:52 EDT
From:      JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re: 4.3bsd/subnetting


	I don't think there's any easy way to do this if you can't make your
4.3 gateway accept more than one IP address for a single interface. I guess
you've considered the obvious brute-force solutions like putting N different
interfaces in your gateway machine, or getting another class B network and
making that the subnetted net.

	Being able to assign a single physical net several logical net numbers
makes renumbering things really painless; you don't have to have a massive
flag day. That's such a useful capability for a gateway to have that I'm
surprised 4.3 is missing it; are you sure there's no way to do it? Maybe
someone should or has added it to 4.3.
	Of course, the difficulty factor of doing this will really depend on
how the insides of the 4.3 IP layer are arranged. I can tell you from
experience in the C Gateway that some places you really have to work at it to
make things work with multiple addresses per interface. Consider sending out
routing packets (you can't use the all 1's broadcast address since people may
get routing packets intended for the other logical net), checking for incoming
broadcast packets, etc!

	Noel
-------

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      12-Jun-86 01:30:08-UT
From:      hwb@gw.umich.edu
To:        Louden@Mitre-Gateway.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA, HWB@GW.UMICH.EDU
Subject:   Re: RFC986 questions
Let me make a few comments about some of the reasons behind RFC986. The 
question of mixing or not mixing protocols is an important one, though
not really, or at least only to some extend, the issue here.

What needs to be accomplished is that existing network backbones can
be utilized for ISO protocols, which includes the ISO CLNS. It
probably does not make too much sense to have, e.g., an Arpanet and an
ISO-Arpanet existing and being disjoint at the same time. Not even
on an iterim base.  It therefore becomes necessary to utilize existing
backbones (good examples here are the Arpanet and the upcoming NSFnet)
for both protocol suites, especially since these suites do not differ
that much from each other anyway.
 
RFC985 points out quite nicely that Ethernets are some kind of lowest
common denominator to which most hosts can connect. We can probably safely
assume that most gateways drop their traffic onto a local Ethernet.
If, e.g., two gateways, which are attached to the Arpanet would talk
both IP and the ISO-CLNS, while eventually utilizing the same routing
data base local to the gateway, people could talk the ISO-CLNS accross
the country. It would not matter at all what runs on top of ISOgrams
in this case. Further routing through subsequent gateways within the
local net would obviously be a local issue here. These (sub)gateways 
would have to understand both 'gram protocols, too, and, e.g., could
distinguish between them according to different Ethernet type fields
seen on the Ethernet.

RFC986 is a draft only and probably needs further refinements so that
and Internet standard could emerge which could be given to the implementors
of gateways. Suggestions for these refinements would be welcome.
 
A small committee chaired by Phil Gross (Mitre) was furthermore tasked
with coming up with suggestions for possible scenarios for RFC986, which
will (hopefully) result in a subsequent RFC. Input for this would be
appreciated, too.
 
	-- Hans-Werner
-------
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Jun-86 08:10:17 EDT
From:      louden@MITRE-GATEWAY.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: RFC986 questions


If the goal is to allow both ISO and DoD on the ARPANET, why not use
the same link level and different net levels?

This would be compatable with both protocols since X.25 is in both.
Connecting the two worlds can then be done at the applications level
by application gateways that understand what is needed, such as X.400 to SMTP.

The issue of gateways can be handled by implementing both DoD and ISO
net level protocols and selecting the one that makes sense for a packet, such
as checking version number is correct.

This method works in a well defined way (all the protocols are spec.ed)
and does not require the large development effort to be wasted on a tempory
patch until a complete transition is made.

Note that changing to ISO net layer requires all hosts to modify their software
even if they will be replaced before the network converts fully to ISO.
Dual mode operation would only require gateways connection dual mode networks
to be modified.  This sounds cheeper to me.

To my knowledge there are at least 3 organizations working on this solution.
The largest and best funded is the NBS effort to develop a standard application
gateway.  This has been discussed at the NBS ISO workshops.

...
Sorry I cannot reply directly to you because we are using a BBN C70 with the
standard release software.  This does not support domain addresses other
than .ARPA.  BBN says they will fix as soon as they can but it is an
example of the problems in requiring a conversion in existing protocols.
It sometimes takes more time and money than you have.

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 1986  8:10:17 EDT (Thursday)
From:      T. Michael Louden (MS W422) <louden@mitre-gateway.arpa>
To:        louden@mitre-gateway.arpa
Cc:        tcp-ip@SRI-NIC.ARPA, louden@MITRE
Subject:   Re: RFC986 questions

If the goal is to allow both ISO and DoD on the ARPANET, why not use
the same link level and different net levels?

This would be compatable with both protocols since X.25 is in both.
Connecting the two worlds can then be done at the applications level
by application gateways that understand what is needed, such as X.400 to SMTP.

The issue of gateways can be handled by implementing both DoD and ISO
net level protocols and selecting the one that makes sense for a packet, such
as checking version number is correct.

This method works in a well defined way (all the protocols are spec.ed)
and does not require the large development effort to be wasted on a tempory
patch until a complete transition is made.

Note that changing to ISO net layer requires all hosts to modify their software
even if they will be replaced before the network converts fully to ISO.
Dual mode operation would only require gateways connection dual mode networks
to be modified.  This sounds cheeper to me.

To my knowledge there are at least 3 organizations working on this solution.
The largest and best funded is the NBS effort to develop a standard application
gateway.  This has been discussed at the NBS ISO workshops.

...
Sorry I cannot reply directly to you because we are using a BBN C70 with the
standard release software.  This does not support domain addresses other
than .ARPA.  BBN says they will fix as soon as they can but it is an
example of the problems in requiring a conversion in existing protocols.
It sometimes takes more time and money than you have.
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Jun-86 10:53:53 EDT
From:      hwb@GW.UMICH.EDU
To:        mod.protocols.tcp-ip
Subject:   Re: RFC986 questions

I think we are really talking about the same thing (utilizing the same link
layer). Please re-read my previous message. The issue here is *routing*
and not so much how protocols get used. The need for application gateways
for the interim is definitely implied in here.
 
	-- Hans-Werner
 
PS: NBS and ISO folks (among others) reviewed the RFC986 before it got published.
-------

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Jun-86 12:51:14 EDT
From:      leong@PO1.ANDREW.CMU.EDU (John Leong)
To:        mod.protocols.tcp-ip
Subject:   rfc983

Having been involved with the ISO Transport Protocol definition a few years
ago (started when it still an ECMA draft spec and a very very prelimary draft
ISO spec from the Tokyo or was it Berlin meeting), it was very interesting to
read the RFC983 "ISO Transport Services on Top of the TCP".

I am afraid the RFC is very much NOT in the spirite of things. 

Every (newer) ISO protocol specification must be accompanied by a service specification.
The primitives defined in the service specification is intended solely for explaination
of the service offered by the protocol. Like the OSI reference model (from which
it is derived),  it is not an implementation guide. Furthermore, the primitives
defines LOCAL INTERFACE and not PROTOCOL. Actually if you look at protocols
for every layer, (e.g. Session) the service primitives and terminology (straight
out of OSI) such as SAP's looks virtually identical. 

The actual service implementation at the interface is very dependent on the
local operating system environment. Hence Connection Request, Connection Confirmation,
Connection Indication etc. are manifested differently in an UNIX 4.2 socket
environment from that of an VMS-VAX or whatever other operating system environment.


It is definitely not the intent to have the primivites encoded and transported
in a peer-to-peer fashion as a protocol. In that case, a service specification
have to be defined for this "new" protocol and we quickly get into a recursion-with-no-exit
situation!!!

In general, it is important for one to produce good generic protocol interface
design so that a particluar protocol implementation or even the protocol itself
can easily be replaced without affecting the code in the upper or lower layer.
A well designed generic interface can be used for every layer although the data
structure associated with a primitive will most likely to be different. The
UNIX 4.2 socket mechanism is a good start.

One final note, for people who is really interested in implementation of the
Transport and Session Protocols, the best set of documentation I have seen (besides
the offical specification) can be obtained from :

National Bureau of Standards, @*
Institute for Computer Sciences and Technology, @*
Center for Computer Systems Engineering, @*
Systems and NetworkArchitecture Division

The set is produced under contract by BBN back in 1980/81. It contains service
specification, protocol specification, as well as implementation guide including
wonderful pseudo codes. While the Transport Protocol spec is not 100% ISO spec,
it is 99% close.

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Jun-86 16:38:28 EDT
From:      louden@MITRE-GATEWAY.ARPA (T. Michael Louden, MS W422)
To:        mod.protocols.tcp-ip
Subject:   RE: RFC986 Questions

So the RFC is for addressing in an ISO stack on the ARPA style net.
That makes more sense to me.  Thanks for the clearification!

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 1986 16:38:28 EDT (Thursday)
From:      T. Michael Louden (MS W422) <louden@mitre-gateway.arpa>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        louden@mitre-gateway.arpa
Subject:   RE: RFC986 Questions
So the RFC is for addressing in an ISO stack on the ARPA style net.
That makes more sense to me.  Thanks for the clearification!

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      12-Jun-86 14:01:31-UT
From:      hwb@gw.umich.edu
To:        louden@mitre-gateway.arpa
Cc:        tcp-ip@sri-nic.arpa, hwb@GW.UMICH.EDU
Subject:   Re: RFC986 questions
I think we are really talking about the same thing (utilizing the same link
layer). Please re-read my previous message. The issue here is *routing*
and not so much how protocols get used. The need for application gateways
for the interim is definitely implied in here.
 
	-- Hans-Werner
 
PS: NBS and ISO folks (among others) reviewed the RFC986 before it got published.
-------
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Jun-86 21:03:22 EDT
From:      mrose@nrtc-gremlin.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: rfc983


    As one of the authors of the RFC, I feel I should clear up some
    misconceptions you have regarding it.

    At no point in rfc983 is it said how to implement the interface to
    the TSAP.  What is said is how you can build such an interface on
    top of the TCP.  That is, given the abstract service definitions for
    the TP, instructions are given as to how one can map those onto the
    services provided by the TCP.  From our perspective, a proper
    implementation of rfc983 exhibits the following properties:  

	- it has the TSAP interface that you want on your host
	- it uses the protocol defined in the rfc

    We have such an implementation for Berkeley 4.2 UNIX.  I imagine
    that an implementation for TOPS-20 would look entirely different,
    both in actual internal code (the protocol engine) and in the
    interface code (subroutine library).  The same goes for VAX/VMS,
    obviously.  But, they would all speak the same protocol (as defined
    in rfc983). 

    Perhaps the problem here, is that it appears to you that rfc983
    specifies an "ISO protocol".  This is certainly not our intention.
    the rfc specifies a DDN-style protocol which provides ISO
    services.  It is the intent of rfc983 to permit standard ISO
    protocols to run on top of the TCP.  It is not the intent to build
    ISO-like protocols for the ARPA Internet.  

    I completely agree with your statement that:  

	 "In general, it is important for one to produce good generic
	 protocol interface design so that a particular protocol
	 implementation or even the protocol itself can easily be
	 replaced without affecting the code in the upper or lower
	 layer."  

    But I fail to see how rfc983 violates this concern.  Quite the
    contrary:  rfc983 rips out the ISO TP internals and substitutes
    calls to the services provided by the TCP!

/mtr

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14-Jun-86 23:02:46 EDT
From:      roy@phri.UUCP (Roy Smith)
To:        mod.protocols.tcp-ip
Subject:   Fuzzball hosts


	Sorry if this is a naive question, but exectly what is a "fuzzball
host"?  I've seen the term any number of times, but it's never quite been
made clear what it is.  Does it mean something specific, or is it just a
general derogatory term?

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15-Jun-86 16:27:00 EDT
From:      DCP@SCRC-QUABBIN.ARPA (David C. Plummer)
To:        mod.protocols.tcp-ip
Subject:   Data after a FIN


    Date: Mon, 14 Apr 86 09:46  EST
    From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>

    We are noticing several hosts (e.g., UTAH-CS) that are sending a FIN,
    then sending data, and finally a second FIN.  Technically, The spec
    says this should happen and the data should be discarded.  What I want
    to know is
     - Who is doing this (I suspect 4.3BSD)?  and
     - Why?  and
     - Why doesn't anybody else know about it?
    I was under the impression this list was a clearing-house for ideas, but
    have absolutely no recollection of this being discussed.


This is still the case and here is some analysis.  In and Out refer to
the packet direction from my local machine.  My local machine is called
FIREBIRD and is at address 192.10.41.161 and will be notated F below (to
save space).  UTAH-CS is at address 10.0.0.4 and will be notated U.  The
number after the dash is the port number; 79 is the NAME protocol.  I've
deleted the window-size field (they were always large enough for all
data) and the time-recorded field (it all happened within 4 seconds).
A,P,S and F stand for Ack, Push, Syn and Fin, respectively.  Commentary
included (commentary is below the segment it is commenting on).

    Out     S  F-1069->U-79 Seq=1915863851.  Len=1 
I ask for a connection.
    In   A  S  U-79->F-1069 Seq=1982144000. Ack=1915863852.  Len=1 
Utah responds with a SYN and ACKs my SYN.
    Out  A     F-1069->U-79 Seq=1915863852. Ack=1982144001.  Len=0 
I ack Utah's SYN.
    Out  AP    F-1069->U-79 Seq=1915863852. Ack=1982144001.  Len=2 
I send a newline (which is what the name protocol wants).
    In   A     U-79->F-1069 Seq=1982144001. Ack=1915863854.  Len=0 
Utah ACKs my data.
    In   A     U-79->F-1069 Seq=1982144001. Ack=1915863854.  Len=512 
Utah sends me 512 bytes of data.
    In   AP    U-79->F-1069 Seq=1982144513. Ack=1915863854.  Len=16 
Utah sends me some more data.
    In   A   F U-79->F-1069 Seq=1982144529. Ack=1915863854.  Len=1 
Utah sends me a FIN.  All of this is in order.
    Out  A     F-1069->U-79 Seq=1915863854. Ack=1982144530.  Len=0 
I acknowledge all of Utah's DATA and the FIN.
    In   A   F U-79->F-1069 Seq=1982144530. Ack=1915863854.  Len=1 
>> Utah sends me another FIN beyond the one it already sent me!
    Out  A   F F-1069->U-79 Seq=1915863854. Ack=1982144530.  Len=1 
After the user process gobbles the data, it closes the connection.  This
acknowledges Utah's FIN (again) and asserts my own FIN.
    In   A     U-79->F-1069 Seq=1982144001. Ack=1915863854.  Len=512 
Utah sends the first segment of data again(!) and ACKs my request, but
not my FIN.  [This may be a packet sequencing manifestation and can
probably be ignored.]
    Out  A     F-1069->U-79 Seq=1915863855. Ack=1982144530.  Len=0 
I again ACK Utah's FIN.
    In   A     U-79->F-1069 Seq=1982144530. Ack=1915863855.  Len=0 
Utah finally ACKs my FIN and the connection is closed.

Why is Utah sending a double FIN?  Is anybody out there listening?  I
had no response from my query two months ago.

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Jun-86 03:10:09 EDT
From:      rms@ACC-SB-UNIX.ARPA (Ron Stoughton)
To:        mod.protocols.tcp-ip
Subject:   PSN 6.0 Battle Scars


There have been some inquiries lately regarding the inter-operability
of X.25 with 1822 using PSN 6.0 in Standard mode.  I believe a
subsequent reply stated that PSN 6.0 supports such inter-operability.
Recent testing we have done at customer sites has confirmed this, but
some problems appear to exist in the PSN 6.0 software.  A couple of
these are described below in an effort to assist users attempting to
connect to MILNET using Standard mode X.25.  We would appreciate
hearing from anyone experiencing similar problems since debugging of
such can be very time consuming.

Battle #1:

This configuration consisted of our IBM MVS host in Columbia connected
to the same IMP as our VAX running 4.2 BSD Unix.  The VAX system was
connected via an ACC IF-11/HDH interface running HDH (1822-J) packet
mode at 19.2K bps.  The IBM system was connected via an ACC IF-370/DDN
interface running X.25 Standard at 57.6K bps.  The problem occurred when
attempting to log onto the IBM system from a VAX terminal using Telnet
and manifested itself has a permanent hang condition during the logon
sequence.  The hang occurred when the IBM system sent a long message
prompting for input.  This message was sent across the X.25 interface
as a 2-packet sequence (128-byte packet size) and was sent across the
HDH interface as a 3-packet sequence (leader packet plus two data
packets).  However, the middle packet was 134 bytes in length which
is a violation of the HDH protocol which specifies a middle packet
length in the range of 2 to 126 bytes.  This oversize packet was
dutifully discarded by the HDH interface, thus causing a subsequent
retransmission by TCP which repeated the error.

Battle #2:

This configuration consisted of an IBM VM host located at the Navy
Yard (NARDAC) connected to a PSN 6.0 IMP via an ACC IF-370/DDN
interface running X.25 Standard at 9.6K bps.  It was discovered
that FTPing the host table from the NIC took an extraordinarily long
time (it actually appeared to be hung) and caused X.25 packet-level
errors at our interface.  However, transferring the same file from
our IBM host in Columbia completed as expected and without error.
In this case our IBM host in Columbia was connected via an ACC
IF-370/1822 interface running distant host 1822 across a 9.6K bps
ECU connection to the PSN 5.0 IMP at NIH.  The NIC is connected to
its local MILNET PSN 5.0 IMP via a BBN 1822 interface running in
local or distant mode.  Being a local IMP connection, the NIC interface
will run at the asynchronous speed of the C/30's 1822 interface.  We
investigated this further with a Chameleon X.25 Data Analyzer and
found the PSN 6.0 IMP was transmitting several IP datagrams
concatenated together into a single X.25 packet sequence (i.e., the
M-bit was set for several [how about 14?] successive X.25 packets).
Each full-size (576-byte) IP datagram was also truncated to two
128-byte X.25 packets.  In other words, the sequence of packets was:

	Packet 	Content

	1	TCP/IP Header [Datagram n,   Len=576], Data, M=1
	2	Data, M=1
	3	TCP/IP Header [Datagram n+1, Len=576], Data, M=1 
	4	Data, M=1
	5	TCP/IP Header [Datagram n+2, Len=576], Data, M=1 
	6	Data, M=1
	7	TCP/IP Header [Datagram n+3, Len=576], Data, M=1 
	8	Data, M=1
	9	TCP/IP Header [Datagram n+4, Len=576], Data, M=1 
	10	Data, M=1
	.	.
	.	.
	.	.

The proper sequence should have been:

	Packet	Content

	1	TCP/IP Header [Datagram n,   Len=576], Data, M=1
	2	Data, M=1
	3	Data, M=1
	4	Data, M=1
	5	Data, M=0
	6	TCP/IP Header [Datagram n+1, Len=576], Data, M=1
	7	Data, M=1
	8	Data, M=1
	9	Data, M=1
	10	Data, M=0
	.	.
	.	.
	.	.

The above two problems are similar in that they both occur at the
packet level and the data source is much faster than the data sink.
However, since one occurs in HDH and the other in X.25, I don't
expect they are related.

Battle #3

We are still investigating this problem, but some preliminary info
may be of interest to the community.  We have multiple sites connected
with identical IF-370/DDN interfaces to PSN 6.0 IMPs.  All but one
are running without problems except as noted above.  The exception is
1ISG which is unable to run at all due to the IMP rejecting our call
request packets.  The indication from the IMP is that our precedence
facility code is being administratively disallowed.  Both ACC and BBN
have compared the configuration parameters of the various IMPs and
found them to be the same.  In order to eliminate our hardware as the
culprit, we canned some X.25 sequences on the Chameleon and fired them
at the IMP to see what it would do.  As expected, it accepted call
requests as long as they didn't contain the precedence facility.  One
would conclude that there is an obvious difference in the configuration
of the IMP port to which we are attached, but so far it has eluded BBN.

Anyone with similar X.25 battle stories is encouraged to share them
with the tcp/ip community so that we don't debug the same problem
multiple times.

			Ron Stoughton
			RMS@ACC-SB-UNIX.ARPA

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1986 12:57:49 PDT
From:      POSTEL@USC-ISIB.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   ISI moves to EDU domain


The Domain Name System has been developed to improve the maintenance
and access of host name data.  It is now ready for implementation, and
policies have been adopted for converting all ARPA hosts to this system.
These policies require that the general nature of an organization which
supports a host be reflected in the host's name, i.e., Educational (EDU),
Commercial (COM), or Military (MIL).  ISI is classified as Educational
and will thus be in the EDU domain.  Note that the policies also require 
that the ARPA domain be phased out.

The official ISI host names will be changed on Sunday, June 29th. The 
new name for USC-ISIB.ARPA will be B.ISI.EDU.  The old official name, 
USC-ISIB.ARPA, will continue to be a nickname; however, old nicknames 
such as USC-ISIB and ISIB will be phased out over the next few months.
Please begin notifying users who send you mail using these old nicknames
that they should begin using the new official name to avoid mail delivery
failures after the nicknames are invalid.  In addition, it is important
that all mailing list files be modified to use the new official names
(i.e., user@B.ISI.EDU).

The other primary ISI hosts below will also be adopting the new domain
style names:

        Current Host Name       New Official Name
        =================       =================
        USC-ISI.ARPA            A.ISI.EDU
        USC-ISIC.APRA           C.ISI.EDU
        USC-ISID.ARPA           D.ISI.EDU
        USC-ISIE.ARPA           E.ISI.EDU
        USC-ISIF.ARPA           F.ISI.EDU
        ISI-VAXA.ARPA           VAXA.ISI.EDU
        ISI-VENERA.ARPA         VENERA.ISI.EDU
        ADA-VAX.ARPA            ADA-VAX.ISI.EDU

If you have questions regarding this issue, please contact ACTION@ISI
for assistance.


Vicki Gordon
ISI Host Administrator
-------
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Jun-86 15:57:49 EDT
From:      POSTEL@USC-ISIB.ARPA
To:        mod.protocols.tcp-ip
Subject:   ISI moves to EDU domain



The Domain Name System has been developed to improve the maintenance
and access of host name data.  It is now ready for implementation, and
policies have been adopted for converting all ARPA hosts to this system.
These policies require that the general nature of an organization which
supports a host be reflected in the host's name, i.e., Educational (EDU),
Commercial (COM), or Military (MIL).  ISI is classified as Educational
and will thus be in the EDU domain.  Note that the policies also require 
that the ARPA domain be phased out.

The official ISI host names will be changed on Sunday, June 29th. The 
new name for USC-ISIB.ARPA will be B.ISI.EDU.  The old official name, 
USC-ISIB.ARPA, will continue to be a nickname; however, old nicknames 
such as USC-ISIB and ISIB will be phased out over the next few months.
Please begin notifying users who send you mail using these old nicknames
that they should begin using the new official name to avoid mail delivery
failures after the nicknames are invalid.  In addition, it is important
that all mailing list files be modified to use the new official names
(i.e., user@B.ISI.EDU).

The other primary ISI hosts below will also be adopting the new domain
style names:

        Current Host Name       New Official Name
        =================       =================
        USC-ISI.ARPA            A.ISI.EDU
        USC-ISIC.APRA           C.ISI.EDU
        USC-ISID.ARPA           D.ISI.EDU
        USC-ISIE.ARPA           E.ISI.EDU
        USC-ISIF.ARPA           F.ISI.EDU
        ISI-VAXA.ARPA           VAXA.ISI.EDU
        ISI-VENERA.ARPA         VENERA.ISI.EDU
        ADA-VAX.ARPA            ADA-VAX.ISI.EDU

If you have questions regarding this issue, please contact ACTION@ISI
for assistance.


Vicki Gordon
ISI Host Administrator
-------

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Jun-86 13:38:38 EDT
From:      abe@ASC.PURDUE.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Information needed on available core gateway machines

I am interested in obtaining information on the available machines
that can be used as core gateways.  I am aware of the BBN Butterfly,
but of not much more.  Please reply by mail.

Vic Abell, Purdue University Computing Center, abe@asc.purdue.edu
					       ...!pur-ee!pucc-j!abe

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Jun-86 19:24:00 EDT
From:      johnsson@DECWRL.DEC.COM (Richard Johnsson)
To:        mod.protocols.tcp-ip
Subject:   EGP trouble

I have recently noticed (I can't say if it recently happened :-) that
my EGP process is having disagreements with the EGP core gateways on
MILNET. I seem to acquire a neighbor and load the routes from it. A few
minutes later the EGP process reports bad checksums and after three
minutes drops the neighbor and switches to the other one.

Needless to say this is causing us some grief as the routes keeping
coming and going every few minutes. I have several questions:

1. Is there something funny going with the EGP core on MILNET?

2. Are there EGP core gateways on MILNET other than AERONET-GW and
   BBN-MINET-A-GW?

3. Is there newer/better EGP code for BSD Unix systems than what I have?
   I'm running Paul Kirton's EGP User Process with documentation dated
   23-Aug-84 which I fetched (I believe from ISI) in September 1984.

Richard Johnsson <johnsson@decwrl.dec.com>

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Jun-86 07:30:43 EDT
From:      mullen@nrl-css.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: EGP trouble

In reference to yesterday's message from johnsson@decwrl.DEC.COM,
we recently started seeing the same thing here at NRL-CSS.ARPA.
We're unable to get beyond MILNET most of the time.

Could we perhaps have an acknowledgement that someone appropriate
is looking into the problem?  I've reported it to hostmaster@nic
and milnetmgr@ddn1, but I'm not sure those are the right people
to notify.

Thanks.

	Preston Mullen
	Computer Science and Systems Branch (Code 7590)
	Naval Research Laboratory
	Washington DC 20375-5000
	202 767-3507

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Jun-86 10:13:39 EDT
From:      brescia@BBNCCV.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: EGP trouble (gateway problems..)


     Could we perhaps have an acknowledgement that someone appropriate
     is looking into the problem?  I've reported it to hostmaster@nic
     and milnetmgr@ddn1, but I'm not sure those are the right people
     to notify.

When there's a problem with the core gateway system, or you suspect gateway
routing, you should call the NOC (Network Operations Center) at 800-492-4992
(or in Massachusetts, 617-497-2900).  Be prepared to name names (or net
addresses) of unreachable nets or hosts.

The tcp-ip mailing list is a bit slow for reporting current operational
problems.

BBN gateway people are looking into the lack of routing info or EGP
availablity.  The first info is that both BBN-MINET-A-GW (26.1.0.40) and
AERONET-GW (26.8.0.65) have been up continuously on MILNET since Monday 13:30
(minet) and Tuesday 18:17 (aero).  The third EGP gateway at YUMA-GW
(26.3.0.75) has been down since Wednesday 0900 while the site is changing
power service.

	Mike Brescia
	617-497-3662

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 86 10:13:39 EDT (Thu)
From:      Mike Brescia <brescia@BBNCCV.ARPA>
To:        Preston Mullen <mullen@nrl-css.ARPA>
Cc:        tcp-ip@sri-nic.ARPA, hoey@nrl-aic.ARPA, brescia@BBNCCV.ARPA milnetmgr@ddn1.ARPA, hostmaster@sri-nic.ARPA
Subject:   Re: EGP trouble (gateway problems..)
     Could we perhaps have an acknowledgement that someone appropriate
     is looking into the problem?  I've reported it to hostmaster@nic
     and milnetmgr@ddn1, but I'm not sure those are the right people
     to notify.

When there's a problem with the core gateway system, or you suspect gateway
routing, you should call the NOC (Network Operations Center) at 800-492-4992
(or in Massachusetts, 617-497-2900).  Be prepared to name names (or net
addresses) of unreachable nets or hosts.

The tcp-ip mailing list is a bit slow for reporting current operational
problems.

BBN gateway people are looking into the lack of routing info or EGP
availablity.  The first info is that both BBN-MINET-A-GW (26.1.0.40) and
AERONET-GW (26.8.0.65) have been up continuously on MILNET since Monday 13:30
(minet) and Tuesday 18:17 (aero).  The third EGP gateway at YUMA-GW
(26.3.0.75) has been down since Wednesday 0900 while the site is changing
power service.

	Mike Brescia
	617-497-3662
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Jun-86 13:15:00 EDT
From:      johnsson@DECWRL.DEC.COM (Richard Johnsson)
To:        mod.protocols.tcp-ip
Subject:   Re: EGP trouble

On a suggestion from bruce@Think.COM I changed MAXPACKETSIZE from 576
to 1006 and things got a lot better. No more checksum complaints and
I'm able to hang on to my neighbor once acquired.

In looking at a trace of the routing activity, there seems to be a lot
of bouncing around. Several networks I checked on get new metrics about
every 4 minutes. Usually the gateway remains the same but the metric
bounces between 4 and 5 or 5 and 6.

Although my immediate problem is solved, it looks like things are still
not completely healthy.

Richard

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Jun-86 13:37:22 EDT
From:      bnsw@MITRE-BEDFORD.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: EGP trouble


Due to the havoc EGP has been doing with routing info and the user confusion
factor, I have turned off EGP.  We are a Milnet site with a subnet.  I also
noticed that we received additional routing info for our subnet that
identified bbn-milnet-gw,arpa-milnet-gw,sri-milnet-gw,sac-milnet-gw, and
isi-milnet-gw as gateways to our subnet.  This is useless info from our side
and is not removed after the EGP bad checksums/cease of core gateway when the
other routes are zapped.  (just to provide more info for solving the
problem...)

Can a status report be sent out to this distro list when the problem has
been fixed?  I haven't seen any help.

Thanks,
Barbara Seeber-Wagner

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Jun-86 15:43:24 EDT
From:      karels@MONET.BERKELEY.EDU (Mike Karels)
To:        mod.protocols.tcp-ip
Subject:   Re: EGP trouble

It sounds as if the milnet has re-discovered a bug in Kirton's egp.
The same thing happened on the arpanet some months ago; I think
it was discussed on egp-people.  The problem was that routing packets
grew larger than the receive buffer, resulting in truncated packets
that won't checksum.  The simple "fix" is to increase the definition
MAXPACKETSIZE to a "large" value; I used 2048, then added code
to detect truncation.

I have a handful of other bug fixes and tracing hooks for Kirton's egp,
but some of it isn't very well tested.  Also, it includes minor
modifications for 4.3BSD, which now leaves the IP header on ICMP packets
as it does for other raw IP protocols.  I can make these changes available
when it's cleaned up a bit.

		Mike

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Jun-86 15:50:00 EDT
From:      DCP@QUABBIN.SCRC.Symbolics.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   [Lepreau@UTAH-20.ARPA: Re: Data after a FIN]

FYI,
		     ==============================
Date: Mon 16 Jun 86 18:50:25-MDT
From: Jay Lepreau <Lepreau@UTAH-20.ARPA>
Subject: Re: Data after a FIN
To: DCP@SCRC-QUABBIN.ARPA
In-Reply-To: <860615162744.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <12215395290.10.LEPREAU@UTAH-20.ARPA>

Mike Karels says this has been fixed in the final 4.3 tape,
which has been cut.  I followed up on this before, I thought
I told you about it.
You can forward this on to the list if Mike doesn't respond
himself in a little while.
-------

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Jun-86 16:22:03 EDT
From:      brescia@BBNCCV.ARPA (Mike Brescia)
To:        mod.protocols.tcp-ip
Subject:   Re: EGP trouble


EGP Checksums?  There was a problem with this in February, and a fix announced
March 3, in the egp-people list (EGP-PEOPLE@bbnccv).

---- begin bug fix message ----

To: egp-people@BBNCCV.ARPA
Cc: tmallory@BBNCCV.ARPA
Subject: EGP Checksum errors
Date: 03 Mar 86 17:29:23 EST (Mon)
From: tmallory@BBNCCV.ARPA

Most, if not all, users of the Kirton EGP code on the Arpanet have seen
bad EGP checksum errors in recent weeks.  The immediate source of the 
problem seems to be the following line(located with grep):

defs.h:#define MAXPACKETSIZE 576

....

For now, redefining MAXPACKETSIZE to 1006 should take care of the
immediate problem for Arpanet and Milnet sites ...

---- end of bug fix message


If your site is running EGP and you are not now receiving the EGP-PEOPLE
(egp-people@bbnccv) mailing list, I invite you to register your local
distribution list (e.g. egp-people@your-site) or yourself for the list.  Send
a note to egp-people-request@bbnccv.

	Mike

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 86 16:22:03 EDT (Thu)
From:      Mike Brescia <brescia@BBNCCV.ARPA>
To:        Barbara Seeber-Wagner <bnsw@mitre-bedford.ARPA>
Cc:        johnsson@decwrl.dec.com, tcp-ip@sri-nic.ARPA, brescia@BBNCCV.ARPA
Subject:   Re: EGP trouble

EGP Checksums?  There was a problem with this in February, and a fix announced
March 3, in the egp-people list (EGP-PEOPLE@bbnccv).

---- begin bug fix message ----

To: egp-people@BBNCCV.ARPA
Cc: tmallory@BBNCCV.ARPA
Subject: EGP Checksum errors
Date: 03 Mar 86 17:29:23 EST (Mon)
From: tmallory@BBNCCV.ARPA

Most, if not all, users of the Kirton EGP code on the Arpanet have seen
bad EGP checksum errors in recent weeks.  The immediate source of the 
problem seems to be the following line(located with grep):

defs.h:#define MAXPACKETSIZE 576

....

For now, redefining MAXPACKETSIZE to 1006 should take care of the
immediate problem for Arpanet and Milnet sites ...

---- end of bug fix message


If your site is running EGP and you are not now receiving the EGP-PEOPLE
(egp-people@bbnccv) mailing list, I invite you to register your local
distribution list (e.g. egp-people@your-site) or yourself for the list.  Send
a note to egp-people-request@bbnccv.

	Mike
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Jun-86 05:20:24 EDT
From:      Murray.pa@XEROX.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   IEEE and Ethernet

Not really IP or TCP, but probably interesting to many people on this
list...

IEEE 803.? recently agreed on a whole bunch of fine print for the specs
for Ethernet repeaters, including fiber extensions. (There were major
problems with the repeater handwaving in the blue book. Basically, it
wouldn't work right if you were unlucky and you tried to push all the
length limits.) If you need more info and can't get it through IEEE, I
think I can find a local contact.

As of January 1, 1986, Ethernet host numbers are now being assigned by
the IEEE rather than Xerox. Any requests mailed to the Xerox address in
the back of the blue book will get forwarded to the IEEE. (and delayed
or...) The person to contact is Vince Condello at (212) 705-7092.

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Jun-86 14:40:00 EDT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   IEEE and Ethernet


    Date: Fri, 20 Jun 86 02:20:24 PDT
    From: Murray.pa@Xerox.COM

    Not really IP or TCP, but probably interesting to many people on this
    list...

    IEEE 803.? recently agreed on a whole bunch of fine print for the specs
    for Ethernet repeaters, including fiber extensions. (There were major
    problems with the repeater handwaving in the blue book. Basically, it
    wouldn't work right if you were unlucky and you tried to push all the
    length limits.) If you need more info and can't get it through IEEE, I
    think I can find a local contact.

    As of January 1, 1986, Ethernet host numbers are now being assigned by
    the IEEE rather than Xerox. Any requests mailed to the Xerox address in
    the back of the blue book will get forwarded to the IEEE. (and delayed
    or...) The person to contact is Vince Condello at (212) 705-7092.

I assume this applies to the protocol field as well?

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Jun-86 12:33:23 EDT
From:      JNC@XX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: IEEE and Ethernet


	The IEEE has flushed the protocol field (at least inside the
Ethernet header) completely. They don't manage it, since they don't
believe in it. The IEEE guy said to call Xerox.

	Noel
-------

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Jun-86 15:37:00 EDT
From:      DCP@QUABBIN.SCRC.Symbolics.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Zero window probe opinion

According to the spec, a segment that is not in the window is considered
"unacceptable" and elicits an ACK (with zero segment text).  This allows
one to probe a zero window with the next sequence number out of the
window (in case the window is open, but the segments conveying that
informatin were lost).  In theory, an implementation is allowed to
completely ignore the window and it will work, but that is anti-social.

My question: Is it considered "correct" to probe a zero window with only
one byte, or is it still polite to probe it with some larger number that
presumably fits in one segment (e.g., 1400+ on Ethernets)?

[BTW, the first time I tried to send this message, I got this
non-completion reply:
    Unable to deliver letter to the following recipient:
      tcp-ip@SRI-NIC.ARPA: SMTP error from SRI-NIC: 500 Syntax error or field too long: MAIL From: <DCP@STONY-BROOK.SCRC.Symbolics.COM>
]

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Jun-86 16:34:05 EDT
From:      Murray.pa@XEROX.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: IEEE and Ethernet

"I assume this applies to the protocol field as well?"

The IEEE doesn't think anybody needs a protocol field. They use that
word for the packet length.  Thus I doubt very much if they are
interested in assigning values. I don't know for sure though.

Most of the existing protocol values were "grandfathered" in because
they are invalid lengths. The official 802 position is that they don't
care what consenting adults do with packets having invalid lengths.
(There is probably a footnote along that line in the specs.) 

The only protocol field values that weren't big/lucky enough to get
grandfathered this way are used for Pup. A pair of alternates have been
assigned. The switchover is painful. Most places have ignored it. I
think the Ethernet driver for the latest VMS now rejects old Pups. That
doesn't make the switchover any easier, but it might make it happen
sooner.

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Jun-86 17:55:54 EDT
From:      braden@USC-ISIB.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: tn3270

Greg:

I just noticed the following in your README file for tn3270:
	
	It would be nice if the other TCP/IP on IBM (the UCLA code for MVS, and
	Spartacus code for VM) talked the same 3270-over-telnet protocol.

The UCLA MVS code has talked the "same 3270-over-telnet protocol" for several
years now.  You obviously never asked.

Bob Braden

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Jun-86 19:18:03 EDT
From:      medin@ORION.ARPA (Milo S. Medin, NASA ARC Code ED)
To:        mod.protocols.tcp-ip
Subject:   Re: tn3270


I use tn3270 to talk to our VM/CMS system using Spartacus KNET, and it
works fine...

					Milo

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Jun-86 20:40:45 EDT
From:      garcia%sri-azteca@sri-tsc (J. Joaquin Garcia-Luna)
To:        mod.protocols.tcp-ip
Subject:   SIGCOMM '86 SYMPOSIUM

The following information may be of interest to you all.

JJ
----------

ACM SIGCOMM '86 SYMPOSIUM.  Stowe, Vermont; April 5, 6 & 7.  The
symposium features 45 papers chosen from over 120 submissions.  Bob
Kahn is the keynote speaker (Developing an Advanced Communications
Infrastructure).  Carl Sunshine (network interconnection and gateways)
and Najah Naffah (distributed message systems) are the two tutorial
speakers.  The topics of the paper sessions include: local area
networks, voice/data integration, protocol engineering, network
algorithms, performance analysis, security and access control, and
design and analysis of transport-level protocols including TCP. 

Of particular interest to the tcp-ip list may be the sessions "Modeling
of Transport Protocols" (chair: Mike Ferguson) and "Protocols for
Interprocess Communication" (chair: Bob Braden).  One of the two
winners of ACM SIGCOMM 86's student paper award contest is L. Zhang
for her paper "Why TCP Timers Don't Work Well." 

For more information about symposium and tutorials, and preferred
registration, contact Jose Garcia-Luna before July 20, 1986.  Postal
address: SRI International, 333 Ravenswood Ave., Menlo Park, CA 94025;
Tel: (415) 859-5647 or (415)859-6366; Telex: 334486; ARPANET:
garcia@sri-tsc.  Else, contact Prof. Frank Vanecek, SIGCOMM '86,
Norwich University, Dewey Hall, Northfield, Vermont 05663, USA; Tel:
(802)485-5011.

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Jun-86 20:43:58 EDT
From:      garcia%sri-azteca@sri-tsc (J. Joaquin Garcia-Luna)
To:        mod.protocols.tcp-ip
Subject:   #2 SIGCOMM '86 SYMPOSIUM

I blew it in the date for SIGCOMM 86. It is August 5, 6 and 7 '86.
JJ
----------

The following information may be of interest to you all.

JJ
----------

ACM SIGCOMM '86 SYMPOSIUM.  Stowe, Vermont; AUGUST 5, 6 & 7.  The
symposium features 45 papers chosen from over 120 submissions.  Bob
Kahn is the keynote speaker (Developing an Advanced Communications
Infrastructure).  Carl Sunshine (network interconnection and gateways)
and Najah Naffah (distributed message systems) are the two tutorial
speakers.  The topics of the paper sessions include: local area
networks, voice/data integration, protocol engineering, network
algorithms, performance analysis, security and access control, and
design and analysis of transport-level protocols including TCP. 

Of particular interest to the tcp-ip list may be the sessions "Modeling
of Transport Protocols" (chair: Mike Ferguson) and "Protocols for
Interprocess Communication" (chair: Bob Braden).  One of the two
winners of ACM SIGCOMM 86's student paper award contest is L. Zhang
for her paper "Why TCP Timers Don't Work Well." 

For more information about symposium and tutorials, and preferred
registration, contact Jose Garcia-Luna before July 20, 1986.  Postal
address: SRI International, 333 Ravenswood Ave., Menlo Park, CA 94025;
Tel: (415) 859-5647 or (415)859-6366; Telex: 334486; ARPANET:
garcia@sri-tsc.  Else, contact Prof. Frank Vanecek, SIGCOMM '86,
Norwich University, Dewey Hall, Northfield, Vermont 05663, USA; Tel:
(802)485-5011.

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Jun-86 22:52:00 EDT
From:      DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer)
To:        mod.protocols.tcp-ip
Subject:   Re: IEEE and Ethernet


    Date: Tue, 24 Jun 86 13:34:05 PDT
    From: Murray.pa@Xerox.COM

    "I assume this applies to the protocol field as well?"

    The IEEE doesn't think anybody needs a protocol field. They use that
    word for the packet length.  Thus I doubt very much if they are
    interested in assigning values. I don't know for sure though.

    Most of the existing protocol values were "grandfathered" in because
    they are invalid lengths. The official 802 position is that they don't
    care what consenting adults do with packets having invalid lengths.
    (There is probably a footnote along that line in the specs.) 

    The only protocol field values that weren't big/lucky enough to get
    grandfathered this way are used for Pup. A pair of alternates have been
    assigned. The switchover is painful. Most places have ignored it. I
    think the Ethernet driver for the latest VMS now rejects old Pups. That
    doesn't make the switchover any easier, but it might make it happen
    sooner.

OK, my ignorance is showing.  Given that what used to be the protocol
field is now the length, how does one determine what layer (protocol)
the packet is really for?  I assume there is still a 16 bit field
SOMEPLACE.  Who assigns those numbers?

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Jun-86 13:31:00 EDT
From:      art@ACC.ARPA
To:        mod.protocols.tcp-ip
Subject:   RE: IEEE 802.3

>     "I assume this applies to the protocol field as well?"
> 
>     The IEEE doesn't think anybody needs a protocol field. They use that
>     word for the packet length.  Thus I doubt very much if they are
>     interested in assigning values. I don't know for sure though.
> 
> 	...
> 
> OK, my ignorance is showing.  Given that what used to be the protocol
> field is now the length, how does one determine what layer (protocol)
> the packet is really for?  I assume there is still a 16 bit field
> SOMEPLACE.  Who assigns those numbers?

IEEE 802 divides link level services into two sublayers, Media Access
Control (MAC) and Logical Link Control (LLC).  Different MAC layers
are defined for various LAN types, 802.3 for CSMA/CD (ethernet), 802.4
Token Bus (used by MAP), and 802.5 Token Ring (the IBM ring).
All MAC layers share a common LLC (802.2) which is supposed to provide
a link level service which is independent of LAN type.
The addressing of the next higher level user (protocol) has been
moved into the LLC protocol header.  The 802.3 MAC level header is
nearly identical to the old ethernet header with the exception of the
protocol field becoming a length field.  LLC identifies its users
through Link Service Access Points (LSAPs in ISOease).  LSAPs are
8 bit quantities with two of those bits reserved for indicating
single/multi recipient addressing and local/global SAP administration.
This leaves room for 64 standard protocol identifiers.  IEEE has
assigned values for ISO IP and DARPA IP, but none for ARP.  This
has generated a lot of activity from the folks trying to convert
TCP/IP/Ethernet systems to 802.3.  There is a proposal to use a
reserved LSAP value to identify an expanded LLC header with more
addressing space.
				<Art@ACC.ARPA>

------

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Jun-86 16:11:48 EDT
From:      glenn@LL-XN.ARPA (Glenn Adams)
To:        mod.protocols.tcp-ip
Subject:   FTP Problems


In reviewing the current FTP specification (RFC959) I uncovered what seems
to be a discrepancy.  In the examples in Appendix II, on page 63,
a response code of 200 is shown as the response to a CWD command.
However, under the list of Command-Reply Sequences on page 50,
CWD is shown to only accept a 250 response code.  Since I interpret
a CWD command as being excluded from the File System functional
category, I assume that the response code of 200 is correct.  Especially
since CDUP as a special case of CWD does use 200.

My motivation for reviewing the spec was a failure that occurred
between a Symbolics LISPM Rel 6.1 FTP Client and a UNIX 4.3BSD FTP Server.
The UNIX server gives a positive response code of 200 for the DELE
command among others.  The Symbolics FTP server accepts only a 250 positive
response code.  On the other hand, the UNIX FTP client ignores the
response code completely.  I suspect that the UNIX implementation is
incorrect in not responding with the proper code; whereas, the Symbolics
implementation is too conservative in the response codes accepted.

--Glenn Adams

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Jun-86 10:29:56 EDT
From:      cassel@DEWEY.UDEL.EDU (Boots Cassel)
To:        mod.protocols.tcp-ip
Subject:   ip model


	Is anyone working on or aware of modelling efforts at the ip level?
The IP packet queuing algorithm is of particular interest, but any modelling
efforts at that level would be welcome.  Thanks.

Boots Cassel
cassel@dewey.udel.EDU

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Jun-86 11:18:00 EDT
From:      bierma@NPRDC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: tn3270

The UNIX "tn3270" program works just fine connecting to the Spartacus Knet
code for VM also.  I use it all the time to connect to our 4341.

--Larry		ARPA: bierma@nprdc.arpa
		UUCP: {decvax,ucbvax,ihnp4}!sdcsvax!sdics!nprdc!bierma
		PSTN: (619) 225-2161

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Jun-86 11:38:57 EDT
From:      news@cdx39.UUCP
To:        mod.protocols.tcp-ip
Subject:   Test of path to mod.protocols.tcp-ip

This is a test to see if we can reach the moderator for mod.protocols.tcp-ip
via the path:
	rclex!harvard!tcp-ip@sri-nic.arpa
Please let me know if this works.

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Jun-86 13:09:18 EDT
From:      POSTEL@USC-ISIB.ARPA
To:        mod.protocols.tcp-ip
Subject:   re: IEEE and Ethernet


David:

Opening another can of worms ...

In IEEE 802 the thing most similar to the Ethernet type is called a
"service access point" or SAP, but it is only 8 bits and two of those
are wasted on some other general coding, so there are only 64 SAPs to
assign.  So after assigning one to identify ISO-IP and one to identify
DOD-IP, the IEEE 802 committee decided that there weren't enough and
refused to assign a SAP to identify ARP.  There is some committee work
in progress to come up with an extended SAP field.

--jon.
-------

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Jun-86 13:29:40 EDT
From:      jas@BRUBECK.PROTEON.COM
To:        mod.protocols.tcp-ip
Subject:   Re: Re: IEEE and Ethernet

The protocol numbers are in the 802.2 data link control header, which
is standard for 802.3, 802.4, and 802.5. They are one byte, and are
incredibly stricly regulated. Basically, they're only available
to established international standards. There is a (they're called SAPs)
for TCP/IP, but that was considered an EXCEPTION to the rule, as TCP/IP
is not promulgated by an international standards body.

The only allocated SAPs are: ISO IP and TCP/IP. Half of them are
"unadministered", IBM has de-facto taken a group for SNA.

You'll notice that ARP is not listed. A group of us are trying to
work on this issue.

(I can provide more gruesome details of the list, if desired.)
-------

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Jun-86 16:18:00 EDT
From:      DCP@QUABBIN.SCRC.Symbolics.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Re: IEEE and Ethernet


    Date: Thu, 26 Jun 86 13:29:40 EDT
    From: jas@brubeck.proteon.com

    The protocol numbers are in the 802.2 data link control header, which
    is standard for 802.3, 802.4, and 802.5. They are one byte, and are
    incredibly stricly regulated. Basically, they're only available
    to established international standards. There is a (they're called SAPs)
    for TCP/IP, but that was considered an EXCEPTION to the rule, as TCP/IP
    is not promulgated by an international standards body.

    The only allocated SAPs are: ISO IP and TCP/IP. Half of them are
    "unadministered", IBM has de-facto taken a group for SNA.

    You'll notice that ARP is not listed. A group of us are trying to
    work on this issue.

    (I can provide more gruesome details of the list, if desired.)

I seem to remember seeing some mention of this fly by in the past, but
took little notice.  Oh well, if they want to be snob-headed and try to
surpress vendor protocols (what about people who want to run PUP,
CHAOS, XNS, DECnet) as well as supress research into protocols (i.e.,
how to avoid collision of an "unadministered" number between people
developing new protocols that would take 4 years to become ISO anyway),
I guess it's time to hope the aliens are coming and will put some sense
into them.

Sorry for the long, run-on sentence, flame.  This might be a reasonable
thing for tightly controlled comercial products, but comercial products
don't pop up out of thin air, they need time for experimentation and
development.

Aren't they also snobbish enough not to need ARP?  Don't you just "send
it" and it "magically" gets there?

I just realized what's ticking me off.  This whole nonsense is a
parallel with puritanical religions.  It does not have any room for
person freedom (e.g., elbow room for new protocols) and it doesn't have
any concept of social responsibility (e.g., maybe <insert favorite hot
topic> isn't such a good idea, but AT THIS TIME IN THIS SOCIETY it is a
necessary evil).  Time to nail a grievance to somebody's door?

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Jun-86 17:17:58 EDT
From:      bjp@MITRE-BEDFORD.ARPA
To:        mod.protocols.tcp-ip
Subject:   New Version of ULANA Specifications


A new version of the ULANA Specifications is available on the host,
ulana.  Directions on how to get here:

	ftp to mitre-b-ulana.arpa
	user: guest
	password: anonymous
	pathname: /usr/newusr/guest/ulana.specs
	internet address: 192.12.120.30


Please send all correspondence to bjp@mitre-bedford.arpa, as that is where
I receive all my mail.  All comments should be sent to this address, as well.


					Sincerely,
					bj Pease

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Jun-86 17:31:18 EDT
From:      leong@ANDREW.CMU.EDU (John Leong)
To:        mod.protocols.tcp-ip
Subject:   ARP on IBM token ring



For running IP on the IBM token ring, one has to handle ARP quite carefully
(besides boring thing like SAP number as applicable to all LAN's using the 802.2
layer).


The IBM token ring is sort of defined in the official 802.5 spec. What is missing
in that definition is the bridge. Unlike Ethernet, inter-ring bridge is very
much part of the IBM token ring since a basic ring will only support 260 stations
due to potential jitter problem. (Bridge differs from a repeater in that it
will store and forward if necessary). While IBM has contributed the Bridge design
to IEEE, it was not included in the final spec.


The IBM ring bridge works very different from the DEC LANbridge which is totally
transparant to station software. The IBM bridge use source routing. In a simplified
form, when a station does any broadcast, the bridge will forward the broadcast
packet. it will also tag its ID in the Route Information Field of the packet.
The Route Information Field, RIF, is considered as part of the MAC layer and
below the LLC layer. When the broadcast packet gets to the other end, the receiving
station will know the path. (The same thing applies to a special MAC frame called
"resolve"). 


In the case of ARP, the recieving station must store the RIF in its ARP table
since subsequent (non-broadcast) communication will have to be done with source
routing : i.e. including the RIF field in the MAC header. The ARP reply must
also incude the RIF as part of the hardware address so the ARP sender can source
route its packet.


This has at least two implications :


(a) The hardware address of the ARP cache has to be a variable length (subject
to a maximum : there is a maximum length for the RIF field).


(b) There needs to be closer interfacing between the driver and the ARP layer
since the driver must pass up the whole MAC header to the ARP handler so that
the RIF field can be extracted.


Personally, I think DEC's approach makes life much more easier. However, I think
future revision of ARP specification for the 802 LAN's should take the above
into consideration.


John Leong

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Jun-86 20:47:56 EDT
From:      minshall%ucbopal@UCBVAX.BERKELEY.EDU (Greg Minshall)
To:        mod.protocols.tcp-ip
Subject:   Re: tn3270

Bob,
	Guilty as charged.  I never asked if you did.  My inherent
view of the world (especially where anything blue is concerned) is cynical.

	Thanks for pointing out my error.  By the way, I am also informed
(though I have never verified it) that Spartacus also supports this mode
of connecting.  So, tn3270 can talk to IBM hosts running Spartacus, Wiscnet
(whatever IBM calls it), or the UCLA code (including the ACC front end,
I believe).  Someday I'll change the README file.

Greg

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Jun-86 09:54:00 EDT
From:      Vinograd@MIT-MULTICS.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: tn3270

Might also note that KNET clients negociate with KNET servers ala
tn3270, so IBM to IBM is in full screen mode.  This is true both for the
VM product, as well as the MVS product.  And the negociation is based on
the users' terminal so all models are supported, not just MOD2.

Dave Vinograd

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Jun-86 17:58:28 EDT
From:      louie@TRANTOR.UMD.EDU (Louis A. Mamakos)
To:        mod.protocols.tcp-ip
Subject:   Re: Re: IEEE and Ethernet

It is because of things like this that standardization bodies have bad
reputations.  You can definitly smell a standard written by committee, 
with each member's own hidden agenda slipped in somewhere.

This will delay acceptance and conversion from the DEC-Intel-XEROX 
Ethernet standard quite a while, at least around here.  If it works,
why break it?

Standards are great; everyone should have one of their own.

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

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Jun-86 19:46:00 EDT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   re: IEEE and Ethernet


    Date: 26 Jun 1986 10:09:18 PDT
    From: POSTEL@USC-ISIB.ARPA


    David:

    Opening another can of worms ...

    In IEEE 802 the thing most similar to the Ethernet type is called a
    "service access point" or SAP, but it is only 8 bits and two of those
    are wasted on some other general coding, so there are only 64 SAPs to
    assign.  So after assigning one to identify ISO-IP and one to identify
    DOD-IP, the IEEE 802 committee decided that there weren't enough and
    refused to assign a SAP to identify ARP.  There is some committee work
    in progress to come up with an extended SAP field.

    --jon.
    -------

[I'm probably sounding like a big flamer...]  It really amazes me that
people are trying to squeeze 300 options into 20 bits.  This isn't the
1960s anymore.  Just a few weeks ago a megabit ram chip costs $35.
That's the equivalent of TWO, count'em, TWO PDP-11 (non-memory mapped)
address spaces (2^16 bytes each).  I recall hearing rumors about various
namespace/domain proposals (the X, Y and Z proposals?) that tried to do
similar bit cramming.

IT ISN'T WORTH IT, folks.  Maybe somebody should seriously suggest that
IEEE 802 be scrapped and something more rational and less
wasn't-invented-here be made to put in its place.

Would Henry Nussbacher, if he is still out there, please resend the
article he sent on 31 March 1985.  It is a great story about the Mericos
and the Eups on the planet Urth about trains with rubber-coatetd wheels.
I don't remember what the analogy was then (probably the TP4 debate),
but it is very fitting to the current situation.

PS, I am still having mail troubles.  These might be problems on our
end.  If so, tell me.  If not, fix your end.

Unable to deliver letter to the following recipients:
  POSTEL@USC-ISIB.ARPA: SMTP error from USC-ISIB: 501 Error in path -DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM
  TCP-IP@SRI-NIC.ARPA: Unknown response from host SRI-NIC:  (expecting 220).

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Jun-86 20:11:52 EDT
From:      MRC@SIMTEL20.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   failed mail from DCP

The problem is in the SMTP sender at the Symbolics end.  There is a
bogus space after "MAIL From:" before the "<" that begins the return
path.  RFC 821 is quite specific about where spaces are expected and
where they are not expected.  You cannot say "MAIL FROM: <FOO@BAR>",
you must say "MAIL FROM:<FOO@BAR>".

TOPS-20 isn't the only SMTP server that is fussy about this.  Even some
Unix-based servers insist upon compliance to the spec here.

-------

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Jun-86 20:18:00 EDT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Re: IEEE and Ethernet


    Date: Fri, 27 Jun 86 17:58:28 EDT
    From: Louis A. Mamakos <louie@trantor.UMD.EDU>

    It is because of things like this that standardization bodies have bad
    reputations.  You can definitly smell a standard written by committee, 
    with each member's own hidden agenda slipped in somewhere.

A somewhat constructive question: Is it written down what the Charter
and Goals of the 802 standards committee is?  Is "to allow flexibility
for experimentation" one of the goals?  If not, then there are several
organizations that will not be able to use 802 because they need the
ability to experiment (and get work done, since non-ISO things are (by
their definition) experimental).  If so, I think they need to be
informed they are not addressing this goal.

    This will delay acceptance and conversion from the DEC-Intel-XEROX 
    Ethernet standard quite a while, at least around here.  If it works,
    why break it?

    Standards are great; everyone should have one of their own.

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

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Jun-86 20:24:00 EDT
From:      DCP@QUABBIN.SCRC.Symbolics.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Re: IEEE and Ethernet


    Date: Fri, 27 Jun 86 17:58:28 EDT
    From: Louis A. Mamakos <louie@trantor.UMD.EDU>

    It is because of things like this that standardization bodies have bad
    reputations.  You can definitly smell a standard written by committee, 
    with each member's own hidden agenda slipped in somewhere.

A somewhat constructive question: Is it written down what the Charter
and Goals of the 802 standards committee is?  Is "to allow flexibility
for experimentation" one of the goals?  If not, then there are several
organizations that will not be able to use 802 because they need the
ability to experiment (and get work done, since non-ISO things are (by
their definition) experimental).  If so, I think they need to be
informed they are not addressing this goal.

BTW, the reason I wrote ARP the way I did is because I KNEW there was
more than one protocol in the world, and that there would be more.  (It
was a bit easy, because I was trying to solve the same problem for two
different protocols (CHAOS and IP).)  I also knew the protocols had
different length addresses, and thus the protocol-address-length field.
I also knew that Ethernet was the only hardware medium.  Thus the
hardware-type field.  I knew that addresses on different hardwares had
different lengths, thus the hardware-address-length field.  I knew that
this would solve the GENERAL problem stated in the first three
paragraphs (Introduction, The Problem, and Motivation).  I know the real
world is more diverse and more interesting than a one track (collective)
mind. 

    This will delay acceptance and conversion from the DEC-Intel-XEROX 
    Ethernet standard quite a while, at least around here.  If it works,
    why break it?

    Standards are great; everyone should have one of their own.

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

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Jun-86 21:02:04 EDT
From:      HOSTMASTER@SRI-NIC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   [HOSTMASTER@SRI-NIC.ARPA: Ohosts.txt file]


This message is forwarded as a reminder to all.
                ---------------

Mail-From: SUE created at 18-Jun-86 16:44:39
Date: Wed 18 Jun 86 16:44:39-PDT
From: HOSTMASTER@SRI-NIC.ARPA
Subject: Ohosts.txt file
Sender: SUE@SRI-NIC.ARPA
To: Host-table-distribution: ;
cc: HOSTMASTER@SRI-NIC.ARPA
Reply-To: HOSTMASTER@SRI-NIC.ARPA
Message-ID: <12215907606.34.SUE@SRI-NIC.ARPA>

Dear network host table user:

As of 1 July 1986, the DDN Network Information Center will no longer
provide the OLD-STYLE host table, NETINFO:OHOSTS.TXT, and its
accompanying binary file, NETINFO:OHOSTS3.BIN.  These are the files
that contain old non-domain style host names.  According to DDN
Management Bulletin 22, dated 16 March 1984, all hosts on ARPANET and
MILNET were to have acquired new domain-style names by 21 March 1984
by adding ".ARPA" to the end of their names.  To aid in the
transition, the NIC has been providing both old and new style tables
for over two years.  After having surveryed all network sites several
times, we have determined that very few hosts will be affected by the
removal of these old-style tables.

PLEASE NOTE: The NIC will continue to provide the official DoD host
table NETINFO:HOSTS.TXT, and its accompanying binary file,
NETINFO:HOSTS3.BIN.  The official host table will be maintained
indefinitely until a full transition to the domain system by all DDN
subscribers is completed.

Please address any questions or comments to HOSTMASTER@SRI-NIC.ARPA.


				Sue Romano
				DDN Network Information Center
-------
-------

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Jun-86 08:29:46 EDT
From:      mo@SEISMO.CSS.GOV (Mike O'Dell)
To:        mod.protocols.tcp-ip
Subject:   IEEE-ISO Brain Death

It is clear the dreaded ISOOSI virus rotted the brain tissue
of the IEEE committee, but why not solve the problem simply...

(1) ARP is basically part of the mechanism for encapsulating
IP datagrams on a local network.

(2) There is a LSAP (or whatever) assigned for the DOD-IP suite.

So.....

Just change the "official" IP encapsulation to start with a 16-bit
TYPE field, followed by whatever is defined by that field.  With that,
you can get ARP, you can get IP, you can get experimental protocols,
you can get on with your life in spite of the crufty IEEE spec.

Problems?? It breaks things.  Well, so does their change.  And it is
early in the upheaval cycle.

The other alternative is to get an LSAP defined for an EXTENSIBLE
structure, with a field, and an Official Assigner.  That has far
more geopolitical problems than getting IP implementers to use
the "sanctioned" IP encapsulation, but is desirable for more
global reasons.  Anyway, this approach would solve our problem, and
move its administration back into a universe with lower entropy
and more reality.

	-Mike O'Dell

(I guess this is really a "secret" OLD ETHERNET type disguised
as DOD-IP.  So be it.  Someone has to be clever around here.
It sure ain't the people designing standards.)

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Jun-86 11:56:10 EDT
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   re: IEEE and Ethernet

In response to the message sent  Fri, 27 Jun 86 19:46 EDT from DCP@QUABBIN.SCRC.Symbolics.COM

David,

Your recollection may be blamed on the Professor Finnegan Papers. Danny Cohen
of ISI is curator of that museum.

Dave
-------

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Jun-86 13:32:15 EDT
From:      LYNCH@USC-ISIB.ARPA (Dan Lynch)
To:        mod.protocols.tcp-ip
Subject:   Re: IEEE-ISO Brain Death

Mike (and others),  This nasty little issue of living in a world
not defined by us is one that can be meaningfully addressed at
the TCP/IP Vendors Workshop at the end of August.  At one
time we will have in one room over 100 different TCP/IP implementation
teams.  WE can discuss not just the technical issues of the best way to
cope with our bretheren in the ISO world, but how to make changes
that are not disastrously disruptive to the customers in the field.
(The most recent problem has been with subnetting and how it gets
incorporated smoothly in the field.   With over 100 different vendors
it is impossible to coordinate release dates for protocol upgrades.)

Meanwhile, perhaps some readers of this list have some experience 
running ISO IP as well as DoD IP on the same Ethernet and can reveal how 
they have dealt with it thus far.

Dan
-------

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Jun-86 22:35:26 EDT
From:      HEDRICK@RED.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   Re: Re: IEEE and Ethernet

Do anyone know if there are plans to do a real 803.x implementation
of IP, i.e. one that uses the type field as a length?  One would
suppose that the first vendor to do this would lose big, since no
other implementation would talk to it.  I would think a more natural
approach would be for IP, PUP, etc., to continue using the type
field as a type.  Then if we see a packet with a value that is in
the range of legal 803 lengths, we treat it as if it specified a
type of ISO.
-------

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Jun-86 22:49:13 EDT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        mod.protocols.tcp-ip
Subject:   Re:  [HOSTMASTER@SRI-NIC.ARPA: Ohosts.txt file]



I trust you are also going to remove the non-domained aliases
from hosts.txt also.

I removed the alias "seismo" about a month ago. It was fascinating
seeing how many things broke on other sites.

The non-domained aliases should clearly be taken out of hosts.txt.
(Otherwise pretending we are running with domains is a joke.)

---rick

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29-Jun-86 17:40:19 EDT
From:      MRC@SIMTEL20.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   HOSTS.TXT

Here's another vote to remove the non-domained aliases from HOSTS.TXT.
I'd like to see each host have a maximum of two names; the current
domain name form (which should appear on all mail) and for a while the
old ".ARPA" form.  There is no excuse for any host which doesn't play
the mail game to have more than one name (let's abolish TAC nicknames!).

I would also like to propose that "NIC" be made a new top-level entity,
and that the current SRI-NIC.ARPA machine be renamed simply "NIC"
instead of something like "NIC.SRI.COM".  The NIC is at SRI because
SRI has the contract to run it, but in the (probably unlikely) event
that SRI loses the contract there will still need to be a NIC.
-------

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29-Jun-86 19:29:02 EDT
From:      jordan@TITAN.ARC.NASA.GOV.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  HOSTS.TXT

I agree with Mark and Rick -- the non-domained aliases are just a sad
excuse for not doing the right thing. I'm not sure, however about the
restriction to two names -- some hosts have extra names for their plain
domain name (ucbvax.Berkeley.EDU -> Berkeley.EDU, etc.) ...

As for SRI-NIC.ARPA -> NIC, maybe it should be NIC.ORG, since the NIC
(the organisation, not the machine) may in the future have more than
one machine (maybe PCs or whatever) under their control. I agree,
however, that it should not be in SRI's namespace.

A question though ... my reading of RFC921 doesn't make it at all clear
about the MILNET's obligation in all of this. I understand that DDN-PMO
has yet to establish a schedule for the *implementation* part of the
Domain system, but what about the naming part of it? It seems to say
that the MILNET is on the same schedule for changing to "domained
names" (which could, by definition, include .ARPA) ...

If you change to .ARPA, you can certainly change to one of the other
top-level domains, and we can be through with .ARPA once and for all.
I was under the impression that the main problem was mailers, etc. that
didn't understand "addresses with dots" ... certainly .ARPA has a dot.

Is there in fact a requirement for the MILNET sites to join one of the
non-dot-arpa top-level domains? I thought I remembered reading
somewhere that part of the requirements for getting a domain is to
provide nameservice for it (whether or not *you* use the server for
address resolution I think is the crux of the "We don't care; we don't
have to -- We're MILNET" argument).

Why are new sites getting non-domained addresses?

Also, to echo Mark, what about these TACs?

/jordan

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Jun-86 07:59:00 EDT
From:      STJOHNS@SRI-NIC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  HOSTS.TXT

We  on  the  MILNET side of the house have been waiting patiently
for those on the research side of the house to work out  all  the
bugs  in  the  domain  system.   And  there  are  BUGS...  err...
"service deficiencies".  You will be pleased to  know  that  this
subject  is  the major topic for the next meeting of the Internet
Engineering Task Force.  This  should  result  in  fallout  which
should shove the MILNET towards the domain system.

Mike StJohns

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Jun-86 09:42:00 EDT
From:      joseph@SAPSUCKER.SCRC.SYMBOLICS.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   failed mail from DCP


    Date: Fri 27 Jun 86 18:11:52-MDT
    From: Mark Crispin <MRC@SIMTEL20.ARPA>

    The problem is in the SMTP sender at the Symbolics end.  There is a
    bogus space after "MAIL From:" before the "<" that begins the return
    path.  RFC 821 is quite specific about where spaces are expected and
    where they are not expected.  You cannot say "MAIL FROM: <FOO@BAR>",
    you must say "MAIL FROM:<FOO@BAR>".

Quite correct.  I fixed this last Monday or so.  If you're still seeing this
bogus space, please let me know the originating host at the "Symbolics end"
so that I can find out why someone's running outdated software on it.

    TOPS-20 isn't the only SMTP server that is fussy about this.  Even some
    Unix-based servers insist upon compliance to the spec here.

Someone at a 4.2bsd site told me this "enforcement" took the form of many,
many sendmail processes going into hard loops, pushing the load average up
around 13 and chewing up more than 90% of the machine.  The loopy processes
have to be shot.  He wasn't happy about it.

-- joseph

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Jun-86 09:53:00 EDT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   failed mail from DCP


    Date: Mon, 30 Jun 86 09:42 EDT
    From: Joseph R Goldstone <joseph@SAPSUCKER.SCRC.Symbolics.COM>

	TOPS-20 isn't the only SMTP server that is fussy about this.  Even some
	Unix-based servers insist upon compliance to the spec here.

    Someone at a 4.2bsd site told me this "enforcement" took the form of many,
    many sendmail processes going into hard loops, pushing the load average up
    around 13 and chewing up more than 90% of the machine.  The loopy processes
    have to be shot.  He wasn't happy about it.

(-: What a great way to bring down a Unix! :-)  I assume he was less
happy about the Unix software than he was about ours.  Malformed data
should elicit responses about malformed data.  TOPS-20 did the right
thing.

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Jun-86 11:23:00 EDT
From:      Palter@SCRC-YUKON.ARPA (Gary M. Palter)
To:        mod.protocols.tcp-ip
Subject:   failed mail from DCP


    Date: Fri 27 Jun 86 18:11:52-MDT
    From: Mark Crispin <MRC@SIMTEL20.ARPA>

    The problem is in the SMTP sender at the Symbolics end.  There is a
    bogus space after "MAIL From:" before the "<" that begins the return
    path.  RFC 821 is quite specific about where spaces are expected and
    where they are not expected.  You cannot say "MAIL FROM: <FOO@BAR>",
    you must say "MAIL FROM:<FOO@BAR>".

    TOPS-20 isn't the only SMTP server that is fussy about this.  Even some
    Unix-based servers insist upon compliance to the spec here.

    -------

We fixed our mailer last week. 

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Jun-86 14:46:31 EDT
From:      craig@LOKI.BBN.COM (Craig Partridge)
To:        mod.protocols.tcp-ip
Subject:   what to call the NIC


    There is already a top level domain for network support centers, NET.
CS.NET is the domain for CSNET CIC support hosts.  I'd argue the NIC
should be something like NIC.DDN.NET  (similar arguments can be made
for the hosts at the NOC).

Craig Partridge
CSNET Technical Staff

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Jun-86 15:15:50 EDT
From:      MILLS@D.ISI.EDU
To:        mod.protocols.tcp-ip
Subject:   Defective citation

Folks,

My thanks to Jon Postel, who pointed out my error in the author of thestory
about the train with rubber tires. The story I was thinking of is called
"Local Transportation in Surfcove," which can be found among the essays
of Prof. J. Finnegan. Danny Cohen has collected many of these in his
anthology "The World According to Finnegan." The story there concerns a
train, sure enough, but not with rubber tires. My apologies to Prof. Finnegan
and to Oceanview University, which some say can be found among the towers of
Marina del Rey.

Dave
-------

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Jun-86 18:06:08 EDT
From:      hemphill@NRL-AIC.ARPA (Gavin Hemphill)
To:        mod.protocols.tcp-ip
Subject:   Am I imagining things?


	Sorry about the previous empty message -- fumble fingers strikes again.

	Is it my imagination or are other people experiencing problems as
well.  I have noticed lately that I can't FTP files bigger than 20 or 30 KB.
The symptoms are that after 6 or 7 minutes (clock time) the FTP connections
(to wherever from nrl-aic) break, there are no messages or indications from
the remote server just the "ftp>" prompt.  Secondary to this when I try to
open a new connection to the same host I'll get the "host unreachable" message,
but if I telnet to any other host -- and from there FTP or telnet to my
original destination I can get through, and after backing out of that a direct
FTP will again get through.  Anybody else had similar problems?  If so, any
pointers would be appreciated.
	G++

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Jun-86 21:22:01 EDT
From:      mark@cbosgd.att.com (Mark Horton)
To:        mod.protocols.tcp-ip
Subject:   Re:  HOSTS.TXT

>I'm not sure, however about the
>restriction to two names -- some hosts have extra names for their plain
>domain name (ucbvax.Berkeley.EDU -> Berkeley.EDU, etc.) ...
>
>As for SRI-NIC.ARPA -> NIC, maybe it should be NIC.ORG,

It seems to me these are two examples of the same problem: a host
which is organizationally three layers down in the tree, but which
has responsibility for a higher level domain (Berkeley.EDU in the
first case, ROOT in the second.)  As such, I think the folks who run
the machine should decide where to put the primary name (and I understand
the NIC has chosen NIC.SRI.COM) with appropriate nicknames.  Thus, the
root (and also COM, EDU, and GOV) are in effect nicknames for the NIC.
Whether they choose to support them as explicit nicknames is again
up to them.

	Mark

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Jun-86 22:54:39 EDT
From:      MRC@SIMTEL20.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Am I imagining things?

Gavin -

     You aren't the first person to have complained about this.  I investigated
it as a TOPS-20 problem but then I got reports that it happened in FTP transfers
that didn't involve any TOPS-20 systems.  I wish I knew what was the problem.

-- Mark --
-------

END OF DOCUMENT