On 9/9/15 6:51 PM, Tom Herbert wrote:
It is NAT since you are changing the source address and modifying the transport protocol checksum below IP and transport layer. There are a bunch of side effects that you would need to consider. This is creating custom APIs changing the semantics of address selection, and also creates inconsistency between how addresses may be selected between a connected and unconnected sockets. Consider that ip_local_out_sk calls netfilter NF_INET_LOCAL_OUT hook before dst->output, so then netfilter would start seeing packets with zero source address???
understood.
A lot of design in the stack is predicated on inet_select_addr returning the source address to use for sending a packet. This should always return a reasonable address as an invariant, if someone wishes to rewrite addresses at a lower layer that's fine, but that should be defined as a NAT operation. If a device wants to weigh in on address selection then we can define an ndo function for that as I mentioned before.
I am floating an idea internally that re-implements how VRF impacts the stack. It's 4.4 material and essentially adds dev_xxxx() / ndo functions for the intrusions. With net-next closed no since throwing them out yet and Nikolay always has good comments on my wild ass ideas.
David -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
