y based on the following five-tuple: source address destination address next header source port number (when available) destination port number (when available). Now if the extension header chain is SO long that the chain and the actual payload (with a potential port information) will not fit into the first fragment, then the firewall has no other choices than to: reassemble the whole packet, which can be a considerable scalability issue for the firewall product and a potential threat for DoS attack against the firewall let fragmented packets through, which can then be a severe security breach just drop all fragments. A straightforward fix for the above would be mandating that the whole extension header chain and the final payload transport protocol header must fit into the first fragment. This would allow building meaningful filtering rules against the five-tuple without the need to reassemble packets in the firewall. Uncommonly long header chains have additional non-security-related issues. Take IPv6 transition tools as an example. A stateful IPv4/IPv6 Network Address Translation (NAT64) [190] needs to have the five-tuple again in order to build the translation state. If the entire header is not present, the NAT64 fails to establish the state and the packets are dropped (assuming that the NAT64 does not reassemble the packets). While we are at IPv6 transition, various tunneling and translation mechanisms are used for transporting IPv6 packets over IPv4 networks [191]. Briefly, when IPv6 is transported over the IPv4, then the specific IPv6 access control and filtering rules may be completely bypassed [192]. A naive solution would be just blocking the known protocol types for IPv6 in IPv4 tunnels (such as 41 for Connection of IPv6 domains via IPv4 clouds (6to4)) but that could block old-fashioned legitimate configured tunnels as well. A better approach would be looking deeper into the packet and verifying from the inner IPv6 packet headers what is actually going on. That is, however, more computationally expensiv