In some email I received from Ted Lemon, sie wrote:
> 
> 
> > ... I just  searched the source tree. The only user-level code I found
> > that uses IP_HDRINCL is traceroute and mrouted, both of which pass
> > in zero for ip_off, and pass in ip_len in native byte order.
> 
> This sounds like an ad-hoc result rather than a design decision.
> IMHO, for consistency this interface should be the same as all other
> IP network interfaces - that is, the data should be swapped by the
> user, not by the kernel.

The point here is that the kernel does it now, anyway, for its own reasons,
not because of IP_HDRINCL or anything else.  It does net->host byte
reordering early in ipintr() and then later in ip_output() does host->net
byte reordering so that it isn't necessary to mess around all the time
just to get the right byte order in comparisons.  I'm pretty sure it is
like that for performance reasons.  (There are probably corrections made in
other places like icmp_error() routines which copy the IP header).

So, if you require the user to convert to network byte order, then
rip_output() is going to have to convert back to host byte order to make
sure that the packet actually gets out through ip_output().  I can't
see any gain in performance from this.  Yes, this situation is an anomoly
when compared to how other bits work, but IMHO, it is better this way.

One other point to consider.  If NetBSD is going to change this just to
make it appear a better design, it'll be yet another thorn in the side
of programs which try to work on generic BSD-style systems.  One slowly
gets tired of `isms'...I don't see how current NetBSD users will benefit
from this change.

Darren