Re: Proxy ARP

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

On Fri, Feb 26, 2016 at 6:15 AM, Christos Zoulas <christos%astron.com@localhost> wrote:
> In article <rmi1t80v9gl.fsf%fnord.ir.bbn.com@localhost>,
> Greg Troxel  <gdt%ir.bbn.com@localhost> wrote:
>>-=-=-=-=-=-
>>
>>
>>Roy Marples <roy%marples.name@localhost> writes:
>>
>>>
>>> So there exists two implementations in userland, one of which at least
>>> is in pkgsrc.
>>> Could we remove this feature from arp itself and the kernel to trim it
>>> down some? Or is the need still there?
>>
>>How much would we save in the kernel?  This feels like only a few lines
>>of code, and it would remove a feature that some still use that dates
>>back to at least 4.2BSD.
>>
>>I think it's still necessary (Joerg's VM example is the modern analog of
>>old dialup), and the basic few flags, slight behavior change seems
>>pretty straighforward.
>>
>>Are the programs more about answering for arbitrary addresses, vs
>>publishing arp for specific hosts?   Are they needed on NetBSD, for some
>>other use case, or are they portable  for other systems too?  Do they
>>use bpf?
>
> I don't even understand what is the proposal for removing code in
> the kernel? Don't set SIN_PROXY? It does not seem like a worthwhile goal.

Less features, easier to keep the system work correctly and keep
backward compatibility :)

Anyway if we separate nexthop caches from the routing table, each cache
doesn't have a route so we stop relying on SIN_PROXY (a flag for a route)
and instead we have to have another way to provide the same feature.
(LLE_PUB, which comes from FreeBSD, will be used in my plan.)

I worry about how we provide proxy ARP for the "pub" case; if we separate
nexthop caches, creating a route by arp -s is not so much appropriate...

  ozaki-r