Mike Karels (email@example.com)
Mon, 24 Feb 86 19:50:29 -0800
I agree with Noel and others that hosts and gateways have rather
different properties, and that the gateways' role is changing faster
than that of hosts. If there were a specification for a host IP layer
that insulated hosts from all future changes (except, of course, those
required to bring them into compliance initially, and whenever the spec
did finally change), then I would only have to worry about changes
affecting gateways at Berkeley. Until that time, I will have to
continue to support both hosts and gateways. If I were to do each
separately, I would have twice the work. Instead, I have chosen to
extend and correct the gateway support that was in 4.2 and continue to
use "hosts" as gateways. Although there is no spec for what a gateway
has to do, I think that it is quite likely that a 4.3BSD Unix system
would pass most reasonable specs. At the same time, 4.3 is better
at 4.2 at discovering that it is not in a position to act as a gateway
and remaining quiet. (Before the corrections fly, as a result of this
discussion I changed 4.3 not to respond with ICMP unreachables
if it is unable/unwilling to forward packets).
The idea of well-defined interface between hosts and gateways to avoid
future need for changes in the host is attractive. However, such an
interface must be sufficient for optimal use of the network by the
host, resilient to future change in the gateways and other network
underpinnings, and compatible with varying usage of IP-based networks
from isolated LAN's, to single hosts on the Arpanet, to subnetted
and heterogeneous high-speed networks interconnected to one or more
long-haul nets. I find it hard to believe that such a specification
will be sufficiently functional that people will not be forced to extend
it for some situations, but will be sufficiently simple and close
to the current specifications that it will be widely adopted by vendors.
Minor variations, such as multi-homed hosts, require the host
to be much more knowledgeable about its environment. Even Noel,
in complaining of the need to be compatible with the Berkeley routing
protocol and EGP, recognizes that there are limits to the changes that
are possible now. I don't think that compatibility with either
of these is actually necessary. Incidentally, Noel, the unknowing
might take your statement to imply that both of these "unsuitable designs"
originated at Berkeley; we won't take the blame for EGP, nor will we
claim that the "RIP" protocol is suitable for the things that you are
trying to do with it.
An unfortunate fraction of the discussion that resulted from Jeff Schiller's
original note was based on oversimplification or misinformation.
For example, a number of comments mentioned "the broadcast address":
wayward packets sent to the broadcast address should not receive error
indications or be forwarded. Which broadcast address? If the hardware
broadcast address, this can be handled easily on machines that support
only IP and 10Mb/s Ethernet. This is a bit more difficult in the 4.2
architecture, which supports numerous types of network interfaces
as well as multiple protocol families. By the time IP or ICMP
receives the packet, the hardware sender address is not longer around,
and IP/ICMP neither do nor should know how to tell if a hardware
address is a broadcast. On the other hand, if the comments were
directed at handling packets with an IP broadcast address, there
is the problem of determining the sender's notion of a broadcast.
Possibilities on a subnetted net include (as net.host) "ThisNet.0",
"ThisSubnet.0", "ThisNet.ff", "ThisSubnet.ff", "SomeOtherNetOrSubnet.0",
"SomeOtherNetOrSubnet.ff", "0.0" from diskless workstations trying
to find out where they are, and perhaps 32 bits of ones. (4.3 recognizes
and receives all of the above except for the two "SomeOtherNetOrSubnet".
The outgoing broadcast address is the address with a host part of all ones,
but this can be set to use other addresses for compatibility.)
If two packet-forwarders on the same net disagree as to the broadcast
address, chaos will likely ensue. On one of our subnets, each time
a router broadcasts an update, it receives 4 redirects from the 3600's
on the net that don't understand subnet broadcasts.
Another bit of misinformation concerned the Unix insistence on
broadcasting this information. The broadcast "rwho" status updates are
sent by a user-level program ("/etc/rwhod"). It uses no requests,
broadcast or otherwise. If a site doesn't want to run this program,
they need only delete the line invoking it from the system startup file.
The Unix kernel does not demand or provide any network servers or
clients; they are all implemented as user-level processes, and any or
all may be omitted or substituted at any site. This includes the
routing program "routed", which may be used to manage routing
within a set of connected local nets, or which may be omitted
in favor of a default gateway or manually-installed routes.
The use of multicast for such functions as Unix "rwho" status,
routing, ARP requests, etc. is attractive. However, many
of these things are not restricted to networks and hardware
interfaces that support multicast.
By the way, I was interested to hear that the BBN gateways reject
all IP packets sent to the hardware broadcast address. It seems that
one of the "hosts" on the net will have to answer the broadcast
ICMP information requests and network mask requests.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:04 GMT