Re: Proxy ARP

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

Hi all,

Thank you for answering my questions!

Before replying individual mails I would like to explain some background
of my questions (I should write this in the first place obviously) and
some results of the survey by myself.

I'm working on separting nexthop caches(*). The change is likely to break
the proxy arp easily so I want to know about the feature well to not break
it and hopefully write some tests for it (I already wrote some but they're
not enough).

(*) http://wiki.netbsd.org/projects/project/nexthop_cache/

And here is what I investigated about why "pub proxy" was introduced
(I'm maybe wrong):

Originally there was only "pub" option; an added arp entry (a route)
acts like a ARP responder for a someone behind it (really?). (It has
a network route with /32 netmask.) If there is the same route entry
when a "pub" arp entry is added, the arp entry is automatically
changed into a something shadow route (SIN_PROXY avoids conflict
pre-existing one). A typical case is that there is a point-to-point
route (e.g., for ppp). The arp entry acts only a proxy for the
point-to-point destination; it doesn't provide a valid route. It worked
but at some point, the automatic change failed to work for some reason
(by some changes in the kernel?) and "pub proxy" option was added;
it forcibly sets SIN_PROXY to an arp entry (a route).

(FreeBSD and OpenBSD haven't introduced "pub proxy" option. Mac OS X
has it I guess because it was derived from NetBSD source code that
already added the option (I'm not sure though).)

In the context of separting nexthop caches, a "pub proxy" ARP entry
is easy to provide because what it should do is just to response to
ARP requests for the ARP entry. OTOH, "pub" one involves a network
route so I'm not sure how to deal with it after separting nexthop
caches because an ARP entry won't be a route anymore.

Anyway I'll reply your replies individually later,
  ozaki-r