Re: refactoring ip_output() and the L2 _output()

[David Young <dyoung%pobox.com@localhost>]

On Sat, Feb 02, 2013 at 12:17:38AM -0500, Mouse wrote:
> >> I'd like ether_output never, ever to deal with the routing table,
> >> but arpresolve() deals some in routes,
> 
> IMO this is a misfeature - borderline bug - and is responsible for at
> least one other botch.  Back in early March 2012, I went looking to see
> if I could eliminate sin_zero.  This turned out to be "impossible"
> (really meaning "way more work than it was worth to me"), and the
> reason was exactly this: because of the way the ARP code (ab)uses the
> routing table.  I think I wrote up my conclusions and sent them to the
> list...yeah, at least for other values of "the list": I sent my note to
> tech-kern.
> http://mail-index.netbsd.org/tech-kern/2012/03/06/msg012854.html is
> (the archived copy of) my report to the list.
> 
> Arranging for ARP entries to have nothing to do with the (IPv4) routing
> table would be an excellent move, IMO.

It sounds to me like we both favor a move toward greater simplicity
and efficiency.  I'm pretty keen on doing just one table lookup
per packet forwarded.

Insofar as ARP installs routing-table entries using a different key than
a "standard" IPv4 address and mask, if that is what you're saying that
it does, that seems too complicated.

Insofar as looking up an IP host in the routing table produces an L2
header and an output interface---i.e., the total information you need to
forward a packet to that host---that seems most efficient.  If sometimes
ARP is the agent who finds the L2 headers out, inserts the corresponding
host routes into the routing table, and modifies/withdraws the routes as
they expire, that's ok by me.

Do you understand what this sin_srcaddr member of sockaddr_inarp is for?

Dave

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981