Re: Proxy ARP

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 7 Mar 2016 19:43:58 +0900
    From:        Ryota Ozaki <ozaki-r%netbsd.org@localhost>
    Message-ID:  <CAKrYomi9fEaC5BO64Rw==jujXPZaMJQXmVc=U=HX-wtyrZw8VQ%mail.gmail.com@localhost>

  | I agree proxy ARP can be used that case and we can do so with NetBSD,
  | but in that case we also have to set up a machine to receive frames
  | that have the destination of someone's MAC address....

No, that was never the method, and should not be necessary ever when
using arp (there are other use cases for things like that.)   The idea
was just to provide an arp service that announced someone else's MAC
address, once the node making the ARP query received that info it would
send later packets to the MAC address it was told - for which there should
be a system on the net to receive those frames (we do not relay them). It
was used when that other (destination) host simply did not understand ARP,
but otherwise could handle IP just fine.

  | Anyway I'm not sure NetBSD's proxy ARP is intended for the case

In the early days, BSD ARP was most certainly used for that, and NetBSD
comes from that ancestry, and most likely has  remnants of code for that
purpose left in it - whether it still works or not is a different question.

  | and there are users for it.

There might easily be none, as I said, I really cannot imagine a real
host left working these days that supports IP and not ARP, it would have
to be truly ancient and running truly ancient code.

Cases where the host answering the ARP actually wants to receive the
packets to then relay to some other host (whether out some p2p link, or
to a virtual host on the same system makes no difference for this) are
much more common, and much more likely to remain relevant today.

Certainly the integration of ARP into the routing table is (relatively) new,
when the first case above was in actual use, it was not implemented that way.

kre