|
|
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.2RFC917 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.2The 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/subnettingI 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]