Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!uwmcsd1!ig!agate!ucbvax!QUABBIN.SCRC.SYMBOLICS.COM!DCP
From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: a proposed modification to ARP
Message-ID: <19880727152537.7.DCP@SWAN.SCRC.Symbolics.COM>
Date: 27 Jul 88 15:25:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 66


    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.