On Fri, Jun 15, 2007 at 04:54:26PM -0400, Steven M. Bellovin wrote:
> On Fri, 15 Jun 2007 22:17:16 +0200
> Manuel Bouyer <bouyer@antioche.eu.org> wrote:
> 
> > On Fri, Jun 15, 2007 at 10:11:44PM +0200, Gert Doering wrote:
> > > Hi,
> > > 
> > > On Fri, Jun 15, 2007 at 10:02:02PM +0200, Gert Doering wrote:
> > > > > > If it's a pure internal point-to-point link, you could save
> > > > > > the effort of maintaining ARP entries (either setting them up
> > > > > > statically, or actually running the ARP protocol).  Less
> > > > > > overhead...
> > > > > 
> > > > On Fri, Jun 15, 2007 at 09:38:51PM +0200, Manuel Bouyer wrote:
> > > > > No. You still need to send something in the ethernet header,
> > > > > that will be properly received by the hardware engine on the
> > > > > other end.
> > > > 
> > > > "ff:ff:ff:ff:ff:ff"
> > > 
> > > Ah.  I smell a misunderstanding here - I wasn't talking about
> > > "packet overhead" but about "processing overhead" due to ARP
> > > handling.
> > > 
> > > The packet format cannot change, of course, but it could carry the
> > > broadcast MAC as destination address.
> > 
> > Sure. But the ARP handling overhead should be very small, as you have
> > to lookup the route in the routing table anyway. When arp is needed
> > the entry is already in the cache. Intead of a lookup in the cache
> > you'd need a test to see if the interface is in p2p more or not. And
> > a similar test in the receive path, which would not be needed
> > otherwise.
> > 
> Right.  And I believe that packets sent to a broadcast address are
> received by the sender, too, on some NICs.  This is even more overhead.

_And_ packets being received as broadcast/multicast are flagged as
broadcast/multicast, and are dropped later, if their IP address is a
unicast one.

At least last I looked, which has been a few years.

	-is