jqj@HOGG.CC.UOREGON.EDU (07/10/88)
Abstract: ARP on Ethernet should use an Ethernet multicast address rather than the Ethernet broadcast address. As MAC-level bridges become more common and cheaper, the average size of a single logical Ethernet (the span of an Ethernet broadcast packet) is growing, as is the average number of machines on the Ethernet. Not all of these machines speak IP; DECnet, Novell IPX, XNS IDP, and several other protocols are extremely popular. Politeness dictates that one protocol not get in another's way. I think IP hosts should be grateful, for example, that DEC uses Multicast rather than broadcast for most DECnet "broadcasts", and hence that the typical IP-only host doesn't have to do any work to throw away DECnet traffic it doesn't care about. We aren't so polite -- we pollute the cable with ARP packets and IP broadcasts. As the networks get bigger, the cost of using broadcasts rises at least geometrically. Doing away with IP broadcasts might be hard. We don't yet understand the issues of IP multicast well enough to make it a required part of IP, but will probably end up with some fairly complex IP multicast; this suggests that we not hastily adopt a simple scheme that is not sufficiently general. ARP, though, would be easy. I propose that a well-known Ethernet multicast address be reserved for ARP, and that it be used instead of the broadcast address. For backwards compatibility with existing implementations, presumably a multicast ARP that failed to generate a reply after a reasonable time would trigger an ARP to the broadcast address. Note that the imminent publication of a "how to be a perfect host" RFC makes this a propitious time for such an extension to the ARP spec. As a side benefit of moving ARP to multicast, one could then have an extended Ethernet with bridges that refused to pass broadcast packets, but that still looked to ARP and hence IP like one big network (note that IP does *not* require that IP broadcasts reliably get to all hosts on a network, or even require that IP broadcast be implemented. The one application I care about that uses IP broadcast, RIP, can easily be made to cope with a partial-broadcast Ethernet since the number of gateways << number of hosts). Breaking a big Ethernet into smaller broadcast domains clearly further reduces the problem of Ethernet broadcasts on an extended Ethernet. Comments?
deering@PESCADERO.STANFORD.EDU (Steve Deering) (07/11/88)
I agree completely with the suggestion of using Ethernet multicast,
instead of broadcast, for ARP. Not only would it reduce the unnecessary
interrupt load on non-IP hosts, but it might also allow some IP hosts
to disable reception of Ethernet broadcasts (which is possible with
some Ethernet interfaces), thus avoiding everyone else's broadcast
pollution.
Whenever I have suggested this in the past, someone has always raised
the point that not all Ethernet interfaces are capable of receiving
specific multicast address. However, every interface that I have
encountered provides at least the capability of receiving ALL
multicasts; there may be interfaces in the PC world that don't even
do that -- they could get by with the broadcast-on-retransmission
scheme that you proposed for backwards compatibility. Modern
Ethernet chips, such as the LANCE and the Intel chip, do provide
the necessary multicast support, as must any interface that is
expected to support DECnet or the new ISO protocols.
I suggest that different Ethernet multicast addresses be used for
ARP-for-IP, ARP-for-CHAOS, etc., to improve the precision of the
multicast.
A more radical suggestion for improving the precision (for which I cannot
claim credit -- I regret that I have forgotten who suggested it to me) is
to allocate a block of Ethernet addresses for ARP-for-IP, and define a
mapping function from IP address into Ethernet address within the block.
For example, say a block of Ethernet multicast addresses of the form
A-B-C-?-?-? were set aside for this purpose. The IP address w.x.y.z
could be defined to map to the Ethernet address A-B-C-x-y-z. A host
wishing to resolve the address of w.x.y.z would send its ARP request to
A-B-C-x-y-z. Only those hosts whose IP addresses end in x.y.z would
need to listen to that Ethernet multicast address.
Doing away with IP broadcasts might be hard. We don't yet understand
the issues of IP multicast well enough to make it a required part of
IP, but will probably end up with some fairly complex IP multicast;
this suggests that we not hastily adopt a simple scheme that is not
sufficiently general.
In RFC-1054, I propose an IP multicasting scheme that could immediately
replace all current uses of IP broadcast on directly-connected networks.
Of course I am biased, but I believe that the host requirements
specified in that RFC are not very complex -- the real complexity lies
in the multicast routers, which are not necessary for multicasting to
immediate neighbors only. As for its generality, I would welcome any
and all comments on the proposed scheme. The End-to-End Protocols task
force is promoting RFC-1054 as a possible Internet standard; if anyone
is unhappy with the proposal, they should speak up now.
Steve Deeringnarten@cs.purdue.EDU (Thomas Narten) (07/11/88)
Is broadcast traffic associated with ARP responsible for so much
traffic that it must be stamped out? Or is it the case that tuning
existing implementations so as not to time out entries so fast, etc.
would suffice?
For instance:
A typical implementation of ARP sends out an ARP request whenever a
packet is destined for a host that has no entry in the local ARP
cache. If a particular machine is down, many hosts start ARPing for
it simultaneously. Moreover, if the machine is heavily used (a file
server for instance) many useless broadcasts are sent out. On our
local nets, ARP traffic is pretty minimal as long as all machines are
up. When one goes down however, ARPs increase dramatically.
Incidentally, NFS is the worst offender at generating many consecutive
ARPs (TCP backs off and eventually gives up).
Adding an additional HOST_DEAD state to the ARP tables could be used
to handle these cases; ARPs for dead hosts would be limited to no more
than one every minute or so. A sophisticated algorithm would arp very
frequently initially, but use a backoff to increase the delay between
successive ARPs as the number of consecutive non-responses increases.
This scheme also has the beneficial side effect of allowing IP to
return ICMP host unreachables for dead machines.
4.3 BSD ARP times out unaccessed cache entries every 20 minutes. Is
there any good reason not to increase the value to several hours or
longer? Broadcasts are expensive and memory is cheap.
--
Thomas Narten
narten@cs.purdue.edu or {ucbvax,decvax,ihnp4}!purdue!nartensmb@ulysses.homer.nj.att.com (Steven Bellovin) (07/11/88)
A more interesting question is how to force hosts to discard ARP entries for dead machines. Currently, most implementations keep the ARP entry for some time interval after the last transmission to a host, not the last reception from it. Thus, if a host goes down because of a broken Ethernet board, some of its partners will retain the old (and now bogus) address for hours, if contact attempts are sufficiently frequent. Some better solution is needed, perhaps akin to the way 4.3bsd quashes a cached route when the round-trip time gets too long. It's hard to see a good way to do that without violating layering, though.
dab@ALLSPICE.LCS.MIT.EDU (07/11/88)
> 4.3 BSD ARP times out unaccessed cache entries every 20 minutes. Is > there any good reason not to increase the value to several hours or > longer? Broadcasts are expensive and memory is cheap. If 4.3 still has the bug where it doesn't update its ARP entry for an IP address everytime it receives an ARP from that IP address, then those of us who occasionally change ethernet interfaces would rather see this time shortened than increased. Except for this, I think an ARP timeout of many hours is reasonable. David Bridgham
jas@proteon.COM (John A. Shriver) (07/11/88)
I think that moving the ARP boradcast to a Ethernet Multicast address still assumes too much on the part of our overworked Ethernet interfaces. There are still interfaces that have no multicast filter, only mutlicast on/off (SEEQ chip, used on 3C501). There are interfaces with a severely limited number of multicast filters (the ones that don't use hash tables). There are interfaces whose performance plummets when you enable any multicast address, because they do a linear search of the table on every packet. All of these interfaces will have a much more difficult existence if we change ARP to use a multicast. The ones that have only on/off will be even more burdened, not only will they receive ARP (and rwho), now they will receive all the DECnet routing traffic they never wanted to hear. This will keep their single receive buffer constantly full of rubbish, so that the real traffic will never get in. ARP is in a lot of PROMs now, and PROMs are "forever". It's probably too late. People have too much invested in PROMs and interfaces to try changing ARP. I think that in most networks, more broadcast traffic is routing than is ARP. RIP, rwho, ruptime, et. al. are the problem, not ARP. Lets not design (or ad-hoc, as Berkeley did) ANY more physical broadcast protocols. From now on, we use multicast. Does DCA want to shell out the $1000 to IEEE for an address block? That will get us 2^24 multicast addresses of the IP community.
daver@hpindda.HP.COM (Dave Richards) (07/12/88)
> Adding an additional HOST_DEAD state to the ARP tables could be used > to handle these cases; ARPs for dead hosts would be limited to no more > than one every minute or so. A sophisticated algorithm would arp very > frequently initially, but use a backoff to increase the delay between > successive ARPs as the number of consecutive non-responses increases. > This scheme also has the beneficial side effect of allowing IP to > return ICMP host unreachables for dead machines. I like this idea. LAN traces of our local network have illustrated that such a "state" is quite necessary. NFS and TCP traffic for down hosts generates sooo many ARPs, it's an nightmare. > 4.3 BSD ARP times out unaccessed cache entries every 20 minutes. Is > there any good reason not to increase the value to several hours or > longer? Broadcasts are expensive and memory is cheap. A number is just a number. But... 20 minutes isn't that short a time-period, with respect to most LANs. Also, directed ARP requests for cache entries being timeed-out, is one way of easing the burden on the network, ehile sllowing the cache entry to die in a moderate period of time. Dave Richards
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (07/12/88)
The CMU router has an implementation of ARP which deals with ARP and dead hosts very effectively. We use two timers and a counter instead of the usual implementation with one timer. The first timer is like that in BSD UNIX. Every time an arp cache entry is referenced, the timer is reset to some "large" value. If the timer goes off (because no packets were SENT to the host), the entry is removed. I think Berkeley uses 5 minutes for this timeout and we use 20 minutes. Because of our additional timer and counter, this could easily be hours (days). Our other timer and counter work as follows. When an arp entry is refreshed (created/updated), the second timer is reset to some "small" timeout, say two minutes, and the counter is reset to zero. If the timer goes off (because no ARP requests or replies were RECEIVED from the host), the timer is reset and the counter is incremented. If the counter is less than a small constant such as two, a point-to-point ARP request is sent directly to the host (i.e. it is NOT broadcast). If the host is still alive, it will answer it causing the timer to be reset and the counter to be reset. If the host is dead, changed it's ethernet address, moved, etc. it will NOT reply, causing the timer to go off again. If the retransmission counter ever reaches two (for example), the entry is removed. In this way, arp entries are continuously (but slowly) tested for accuracy, and the router is very resilient to ARP or hardware problems. We rarely see a bad ARP entry persist for more than a few minutes. Drew
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (07/12/88)
I'm not sure if you are really suggesting using 2^24 multicast addresses or not. While quite precise, it would probably be be overkill. Considering that many (most?) of the ethernet chips which support more than 1 multicast address actually support 64, a good compromise between only 1 address and 2^24 addresses might be to reserve 64. Some sort of fast hashing function could be used to map an IP address to one of 64 buckets. This probably rules out the hashing function (CRC's) used by many of the chips themselves. How hard is it to get lots of multicast addresses? Is it possible to buy 2^24 addresses? Drew
map@GAAK.LCS.MIT.EDU (Michael A. Patton) (07/13/88)
In Re: > Date: Mon, 11 Jul 88 21:36:30 -0400 (EDT) > From: Drew Daniel Perkins <ddp+@andrew.cmu.edu> > > I'm not sure if you are really suggesting using 2^24 multicast addresses or > not. While quite precise, it would probably be be overkill. I'm pretty sure that's what he had in mind, it's the obvious number (see below). It may be overkill, but it doesn't hurt anything and helps the "bother as few hosts as possible" philosophy of the original message, in general only the intended host will actually have to process each ARP "broadcast". > ... Considering that many (most?) of > the ethernet chips which support more than 1 multicast address > actually support 64, a good compromise between only 1 address and > 2^24 addresses might be to reserve 64. But the point was that each host only needs to listen to ONE of these addresses, the one it's IP address maps into, any ARPs sent to the others would be ignored. With this algorithm you get the hardware to do the ignoring, saving on CPU time and interrupt overhead, possibly even on context switches. > ... Some sort of fast hashing > function could be used to map an IP address to one of 64 buckets. > This probably rules out the hashing function (CRC's) used by many > of the chips themselves. How hard is it to get lots of multicast > addresses? Is it possible to buy 2^24 addresses? It isn't possible to buy fewer than 2^24, that's the smallest package available :-) When you buy Ethernet addresses, you buy a 24 bit prefix, and you get to assign the other 24 bits as you see fit. This seems like exactly the kind of scheme that fits this well. > Drew Mike
deering@pescadero.stanford.EDU (Steve Deering) (07/15/88)
[This message seems not have made it out to the tcp-ip list, so this is a retransmission. Sorry if anyone gets a duplicate. -- Steve] From Thomas Narten: Is broadcast traffic associated with ARP responsible for so much traffic that it must be stamped out? ... ARP has often been responsible for broadcast storms, which some people would like to stamp out. Moving it to from broadcast to multicast would reduce the number of potential victims of a storm (especially if using an address hashing scheme, as I proposed). Even when ARP is behaving itself, there is a pollution argument against using broadcast: no single (well-behaved) broadcast application causes a significant burden on uninterested hosts, but as the number of broadcast applications continues to grow, and the number of hosts running those applications on a single (possibly bridged-)LAN continues to grow, the cumulative burden becomes serious. To control it, you have to try to stop as many offenders as possible. It seems to me that the cost of cleaning up this pollution is almost negligible, unlike the cost of cleaning up coal-burning factories or semiconductor fabrication facilities or cars. Just replace one 48-bit address with another, and set your multicast filter accordingly. But, as John Shriver points out: ... There are still interfaces that have no multicast filter, only mutlicast on/off (SEEQ chip, used on 3C501). There are interfaces with a severely limited number of multicast filters (the ones that don't use hash tables). There are interfaces whose performance plummets when you enable any multicast address, because they do a linear search of the table on every packet. That's unfortunate, but does that mean everybody with a decent filter has to continue to suffer? If the users of a particular interface find that accepting all multicasts is too burdensome, they can continue to accept only broadcasts, as long we specify that ARP retransmissions be sent as broadcasts, and the retransmission interval is reasonably short. Furthermore, the lack of a decent filter does not prevent them from *sending* multicast ARP requests. I don't think that we should let the weaknesses of these obsolete interfaces prevent us from moving forward, especially given that we can accomodate them well enough until they are replaced. ... The ones that have only on/off will be even more burdened, not only will they receive ARP (and rwho), now they will receive all the DECnet routing traffic they never wanted to hear. This will keep their single receive buffer constantly full of rubbish, so that the real traffic will never get in. But it's OK to make the DECnet hosts receive all the IP rubbish they never wanted to hear? ARP is in a lot of PROMs now, and PROMs are "forever". It's probably too late. People have too much invested in PROMs and interfaces to try changing ARP. As pointed out, old implementations would continue to work. ... Does DCA want to shell out the $1000 to IEEE for an address block? That will get us 2^24 multicast addresses [for] the IP community. It has already been done. 2^23 of them have been allocated to IP multicast (see RFC-1054). The other half are reserved by the Internet Numbers Czar for possible future uses, of which ARP might conceivably be one. From Drew Daniel Perkins: I'm not sure if you are really suggesting using 2^24 multicast addresses or not. While quite precise, it would probably be be overkill. Considering that many (most?) of the ethernet chips which support more than 1 multicast address actually support 64, a good compromise between only 1 address and 2^24 addresses might be to reserve 64. ... You are right, you can hash to as many or as few addresses as you want, but I don't understand what the size of an address filter has to do with it -- each host need listen to only one multicast address for ARP, the one to which its own IP address hashes (unless the host has more than one IP address assigned to a single interface). The algorithm I suggested gives a perfect hash and is trivial to implement. 2^24 is actually the unit of allocation of multicast addresses from the IEEE; as John Shriver mentioned, such a block of addresses costs $1000. (What a numbers racket!) Alternatively, you could apply to the Numbers Czar for a smaller block -- only .006 cents an address :-) By the way, if you decide to use only a single Ethernet multicast address for ARP, I suggest that you use 01-00-5E-00-00-01. That is the Ethernet address that corresponds to the IP multicast address 224.0.0.1, to which all multicast-capable IP hosts are expected to listen. Might as well conserve filter slots, where possible. Steve
DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) (07/15/88)
Date: 12 Jul 1988 21:25-PDT
From: Steve Deering <deering@pescadero.stanford.edu>
By the way, if you decide to use only a single Ethernet multicast
address for ARP, I suggest that you use 01-00-5E-00-00-01. That is
the Ethernet address that corresponds to the IP multicast address
224.0.0.1, to which all multicast-capable IP hosts are expected to
listen. Might as well conserve filter slots, where possible.
I just barfed up my breakfast. Have they stopped teaching modularity
and functional boundaries in computer science classes?jas@proteon.COM (John A. Shriver) (07/16/88)
This entire discussion of ARP and using a multicast address has one assumption that has not been raised. The idea is to send the first ARP request as a Multicast, and then send retransmissions as Broadcast. This assumes that the ARP implementation in question is stateful, and has retransmissions. Not all ARP implementations meet this criteria. Of course, these implementations could always send to the broadcast.
deering@PESCADERO.STANFORD.EDU (Steve Deering) (07/16/88)
From me:
By the way, if you decide to use only a single Ethernet multicast
address for ARP, I suggest that you use 01-00-5E-00-00-01. That is
the Ethernet address that corresponds to the IP multicast address
224.0.0.1, to which all multicast-capable IP hosts are expected to
listen. Might as well conserve filter slots, where possible.
From David Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>:
I just barfed up my breakfast. Have they stopped teaching modularity
and functional boundaries in computer science classes?
Have they stopped teaching civility in kindergarten?
From jqj@hogg.cc.uoregon.EDU:
I'm not sure I agree. I'd like to keep ARP conceptually distinct from
IP, so as long as ARP is also used for Chaos and potentially for other
protocols, it would be desirable to have one more multicast address just
for it. ...
Sorry, I was less clear than I should have been. I was referring to the
use of ARP for IP addresses, as I mentioned in my first message. Clearly,
ARP for Chaos addresses should use a different multicast address, given
that the set of hosts running Chaos is not necessarily the same as the set
of hosts running IP.
The idea is that one Ethernet multicast address identifies the set of
all local hosts running IP. Any application that wishes to send to that
particular set of hosts should use that address, regardless of ether-type
or higher-level protocol (just as the unicast Ethernet address used to
reach a single host does not depend on the higher-level protocol [with the
unfortunate exception of DECnet]). Currently, both IP broadcast and ARP
use the same address, FF-FF-FF-FF-FF-FF, which identifies a larger set of
hosts than necessary; I have suggested a more accurate address to use.
In fewer words, link-level addressing is orthogonal to protocol type.
Of course, ARP-for-IP *could* use a different multicast address than that
used for the IP all-hosts group, but they would identify exactly the same
set of hosts. Given that most current Ethernet interfaces have a small,
fixed number of multicast filter slots or hash buckets, it's worthwhile
to avoid the redundancy.
(On the other hand, if you adopt the address hashing scheme we have been
discussing, the sets of ARP targets will differ from the set of all IP
hosts, so different multicast addresses are appropriate. In return for
using up another filter slot, you get many fewer unnecessary interrupts.)
When this same topic came up a year or so ago, David Plummer (the gentleman
with the vomit on his lap) objected to using multicast for ARP-for-IP, on
the grounds that ARP was independent of IP and should not need to know
anything specific to IP. (I regret that I no longer have a copy of his
message from that discussion; I'm sure he will correct me if I am
misrepresenting his objection.) In my view, the hardware-level destination
address is simply another parameter to ARP, just like the hardware and
protocol addresses that go in the ARP fields.
Steve Deeringjmg@cernvax.UUCP (jmg) (07/18/88)
In article <8807131426.AA04434@gaak.LCS.MIT.EDU> map@GAAK.LCS.MIT.EDU (Michael A. Patton) writes: >It isn't possible to buy fewer than 2^24, that's the smallest package >available :-) When you buy Ethernet addresses, you buy a 24 bit >prefix, and you get to assign the other 24 bits as you see fit. This >seems like exactly the kind of scheme that fits this well. When we asked for, and got, our own Ethernet addresses (from Xerox) we got just 4096, i.e. the last three bytes only were free for us. Of course, we are not a major manufacturer, but only a small-time producer of a few home-built controllers. I have no idea whether there are other possibilities! -- _ _ o | __ | jmg@cernvax.uucp | | | | _ / \ _ __ _ __ _| jmg@cernvax.bitnet | | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. DD, CERN, | | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland
jmg@cernvax.UUCP (jmg) (07/18/88)
Of course, I meant the last three nibbles (12 bits total), not bytes, in the follow-up which I just sent. -- _ _ o | __ | jmg@cernvax.uucp | | | | _ / \ _ __ _ __ _| jmg@cernvax.bitnet | | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. DD, CERN, | | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland
jas@proteon.COM (John A. Shriver) (07/18/88)
> I just barfed up my breakfast. Have they stopped teaching modularity > and functional boundaries in computer science classes? ARP is one of the quintessentially elegant protocols. An enormous amount of power is provided for a very simple implmentation. Let's keep it that way. Let's also remember that ARP runs on 5 networks other than Ethernet (Experimental Ethernet, AX.25, ProNET, Chaosnet, and ARCNET) that don't have multicast, only broadcast. Of course I could be a real killjoy and note that ARP won't be needed on ISO networks, routers will send you redirects instead.
Dave_Katz@UM.CC.UMICH.EDU (07/19/88)
>Of course I could be a real killjoy and note that ARP won't be needed >on ISO networks, routers will send you redirects instead. Address resolution is normally done by the ES-IS protocol, ISO 9542. Hosts (ESs) and routers (ISs) periodically multicast Hellos to one another, providing the net-subnet mapping (NSAP-SNPA in the parlance). Hosts can listen to the other hosts' ES hellos if desired, thus learning the mapping directly; otherwise they can bounce the packets off of a router and get a redirect. The packet overhead of redirects vs. ARP is the same, and there are a couple of advantages to the ISO approach. First, no broadcasts are necessary to resolve the address (and hosts only have to listen to IS multicasts and thus aren't bothered by other hosts' address resolution). Second, it is unnecessary to hold on to the data packet while the address is being resolved, which reduces implementation complexity and other fuzzy issues (how long to hold onto the packet before giving up?). For isolated nets with no routers, hosts multicast data packets with unresolved net addresses to other hosts (essentially a broadcast since there are only hosts on the wire), and the destination host sends an ES hello directly to the sender for future reference. Dave Katz Merit/NSFnet
cire@CLASH.CISCO.COM (07/20/88)
>> Date: Mon, 18 Jul 88 11:02:26 EDT >> From: jas@proteon.com (John A. Shriver) >> To: DCP@quabbin.scrc.symbolics.com >> Cc: tcp-ip@sri-nic.arpa >> Subject: a proposed modification to ARP >> Status: O >> >> ARP is one of the quintessentially elegant protocols. An enormous >> amount of power is provided for a very simple implmentation. Let's >> keep it that way. Here here. I also have a question. If ARP was built to use multicasts wouldn't that just replace one problem with another one? The hosts on the network would have to be properly configured to use an appropriate multicast or group of multicasts. How well will this interoperate with other vendor's implementations? Is all this worth it? -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941
DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) (07/27/88)
Date: Tue, 19 Jul 88 12:33:09 PDT
From: cire@clash.cisco.com
>> Date: Mon, 18 Jul 88 11:02:26 EDT
>> From: jas@proteon.com (John A. Shriver)
>>
>> ARP is one of the quintessentially elegant protocols. An enormous
>> amount of power is provided for a very simple implmentation. Let's
>> keep it that way.
Here here. I also have a question. If ARP was built to use
multicasts wouldn't that just replace one problem with another
one? The hosts on the network would have to be properly configured
to use an appropriate multicast or group of multicasts. How well
will this interoperate with other vendor's implementations? Is
all this worth it?
I speak here as the author of ARP to give some historical perspective on
the issue at hand. When ARP was developed (6 years ago), the world was
a lot different than it is today. Proteon barely existed, if it existed
at all. Sun wasn't. I don't think IBM had introduced their PC yet, and
it certainly didn't have networking at the time. I think 4.2bsd hadn't
come out yet, and it's TCP was still in flux. For that matter, I think
the ARPAnet was still running NCP. Ethernet cards were available for
PDP11s (remember them?) from Interlan and 3Com, and for MultiBus from
Interlan. There may have been others, but that was about it. VMEBus
was probably in committee. Multicast addresses were defined in the
spec, but there were no hints how to use them, or what capabilities
boards should provide for multicast (e.g., in the way of specifying
individual or group addresses to listen for). Due to all of this,
networks were a lot smaller.
Times have changed. Personal computers and personal workstations are
now commonplace. The Ethernet spec was revised. A lot more companies
and products exist. TCP/IP is incorporated into a lot of systems (e.g.,
4.3bsd). A lot of different Ethernet interfaces exist. They all have
various forms of address filtering capabilities, both for multicasting
and normal addresses (e.g., I understand many PC cards require the PC to
get interrupted and do the address filtering in software!). Networks
are a LOT LOT bigger and broadcasts are on people's mind, whether it's a
real problem or not.
In hindsight, it was a mistake not to have a checksum. There were a few
other things that could have been done better that various of us have
noticed and learned over the years. Multicast was just not a
consideration, partly because occaisional broadcasts didn't seem like
they would be a problem (perhaps a mistake) and partly because multicast
was so ill-defined. One of the people helping me with the protocol may
have suggested multicasting; I can't remember. Adding state to (or
suggesting state for) ARP was not even thought of, probably because the
protocol works without state and state may have been discarded because
it added (seeminly) unneeded complexity.
I have nothing against somebody figuring out how to effectively use
multicast and/or suggested state algorithms. I think people do have to
consider the following things:
- Existing implementations must not break. It's too hard to get
vendors to change things on a flag day.
- Don't unnecessarily link ARP with IP. I barfed because that's what
it looked like somebody was suggesting. The xx-xx-xx-xx-yy-yy
multicast address suggestion where xx-xx-xx-xx means ARP and yy-yy is
the protocol being ARPed for seems reasonable.
ARP was designed to be protocol-independent and hardware-independent.
Please keep it that way.henry@utzoo.uucp (Henry Spencer) (08/03/88)
In article <19880727152537.7.DCP@SWAN.SCRC.Symbolics.COM> DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) writes: >... Networks >are a LOT LOT bigger and broadcasts are on people's mind, whether it's a >real problem or not. Actually, it has always seemed to me that ARP -- the mapping between physical addresses and logical ones, so to speak -- was the one place where use of local broadcast was proper and defensible. I personally would put ARP last on the list of broadcast problems to be fixed, and a number of other things much higher. I have trouble believing that ARP by itself, if it were the only use of broadcast, would be a real problem. Is it really so? -- MSDOS is not dead, it just | Henry Spencer at U of Toronto Zoology smells that way. | uunet!mnetor!utzoo!henry henry@zoo.toronto.edu
bdale@hpcsrc.HP.COM (Bdale Garbee) (08/03/88)
>Let's also remember that ARP runs on 5 networks other than Ethernet >(Experimental Ethernet, AX.25, ProNET, Chaosnet, and ARCNET) Not to mention Amateur Radio AX.25 ala the KA9Q package.