L3 forward

[martintopholm]

First patch will add support for resending mtu messages to designated L3 peers. Second patch will add a direction filter to pcap, so only inboud packets are considered.

[majek]

Ok, I don't mind this PR in spirit. But I do mind the implementation.
a) can you move the implementation details (memcpy!) out of the main file. maybe net.c?
b) the same for other things, maybe utils.c is a beter place
c) Please document it in the README
d) I'm not a fan of linked lists implemented manaully, I probably would go for a fixed-sized array (with some assumption that you will have at most, say 32 entries, ie: simplicity, just one free() instead of a loop in the end). But it's not a big deal.
e) getaddrinfo should definitely be abstracted in net.c
f) I'm not sure what's the IP_TTL / IPV6_UNICAST_HOPS about. Can you explain why this is needed?

So basically - more and nicer abstractions please.

The PCAP_D_IN part could be merged right away, so please pull these 4 lines to a separate PR.
(Correction, I'll cherry-pick this commit)

Finally, I think the same stuff can be achieved with iptables TEE module:

... -t mangle -A PREROUTING -i eth0 -j TEE --gateway 2001:db8::1

Am I right?

[martintopholm]

Ad a), b), and e) I assume this refers to almost the entire changeset. I'll pluck it out and put it in net.c. Would an interface such as make_peerlist(), free_peerlist(), sendto_peerlist() seem appropriate or were you thinking something different? As far as I understand your concern is main.c knowing about network objects such as sockaddrs (apart from low level stuff in handle_packet), right? Ad c) I don't know why I missed updating the README, that is an oversight. Would you like a man-page contribution as well or do you consider them overrated? Ad d) I generally object to fixed size arrays, but if you think it prettier it will be done. Ad f) While changing and checking the source addresses should prevent loops among the different peers, best practice is to decrease TTL when forwarding packets. This will also prevent storms in case of misconfigurations. Regarding the TEE module, it will only work on the local network (meaning layer two). In the layer three the redirected gateway would just send it back again.

[martintopholm]

I have tried to work in the requested changes in the recent push to the l3-forward branch.