Automatic next header deduction

[Qeeker]

Add automatic upper layer protocol deduction for fields like type in Ethernet. This commits add support of this feature for Ethernet, IPv4 and IPv6 (including IPv6 extension headers).

[mike01]

There is a problem with the automatic type-assignment which is the ambiguity of the "upper type" <-> "type value" relation. On ethernet->ip this is no problem but as soon as this reaches tcp there is no way to derive if e.g. "tcp_pkt + http_pkt" means tcp port 80, 8080, 8008 or what more ports http is associated to. One could say protocol designers messed up at this point but this is another topic. I'll park this at auto_next_header branch.

[Qeeker]

I know there is no way how to derive TCP port from L7 but it also doesn't make sense. TCP/UDP ports are L4 addresses which pointing to the concrete application running on the end node (those values do not represent upper layer protocol). You can fill whatever you want into L4 addresses and you still get valid packet. But if you fill wrongly Ethernet type (or Protocol field in IP) you'll create invalid packet. Only one reason for incorrect values in those fields are testing purposes (which is still possible with those patches). Correct values for L4 addresses are responsibility of the user but fields like checksums, length or "type" fields IMO should be filled automatically.

[mike01]

Well indeed filling into L4 addresses whatever you like is possible and creating e.g. an HTTP server running on port 42 and creating a connection to it is as easy at it can be. But the the same works with e.g. L3 packets like IP and putting in an upper layer type like "myspecial_l4_protocol" having a non standardized value of 213. The packet will arrive when sending over the Network but there won't be many using it as it's not standardized. Regarding L4 it can be assumed people are implementing their applications using port/service combinations as registered at IANA (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml). Whatever..I think there is some solution to resolve the L4 port<->service ambiguity which will be included in one of the following releases and introduce auto-setting layer types.