> To: tech-net@netbsd.org
> Subject: IP_HDRINCL revisited
> From: Jason Thorpe <thorpej@nas.nasa.gov>
> Date: Thu, 21 Jan 1999 13:32:53 -0800
> 
> So, my question is:
> 
> 	(1) Should we bother making the IP_HDRINCL change, and just keep
> 	    the traditional BSD semantics of ip_len in host order, or
> 
> 	(2) If we do change IP_HDRINCL, should we also change rip_input()
> 	    to swap ip_len back into network order before handing it off
> 	    to the socket, so that the byte order will be consistent for
> 	    sending and receiving?
> 
>         -- Jason R. Thorpe <thorpej@nas.nasa.gov>

I hope both input and output are changed to make them consistent.

It reminds me of some relevant issues.
1. ip_len returned from rip_input() is not only in host byte order, but it
also does not reflect the length of the whole IP packet. ipintr() adjusts it
to not include the IP header.

2. With last month's ICMP error patch, a "HTONS(ip->ip_id)" is added
in ip_ouput(). It's got executed for forwarded and raw output packets.
No problem with forwarded packets, but with raw ones that means
IP_HDRINCL expects host byte order ip_id from the user. And if the ip_id
passed by the user is 0, it is swapped twice (there's a "htons(ip_id)" in
rip_output() too).

3. ip_len in ICMP error returned from rip_input() is not in consistent order.
When it's an ICMP redirect message, ip_len is in network byte order, otherwise
if it's an error message like ICMP_UNREACH_PORT, ip_len is in host byte order.
That's because NTOHS(icp->icmp_ip.ip_len) is called when icmp_input() jumps to
"deliver:". It seems higher level routines never use icp->icmp_ip.ip_len.

-Jun