e. IPv6 filtering [193] in general is easily done wrong and may cause unwanted side effects such as hindering NDP. Are these threats and vulnerabilities issues in 3GPP architecture? They potentially are, and there is really no difference compared to any other (fixed network) IPv6 deployment. Atomic and Overlapping Fragments Last we look into two fragmentation-specific security threats; overlapping fragments [137] and using atomic fragments as a tool to launch other fragmentation and predictable iden- tifier based attacks [194, 195]. IPv6 in 3GPP Networks The IPv6 specification [2] did not specifically prohibit fragments overlapping each other when reassembling packets. That is, the start of a fragment indicated by the fragment offset makes the new fragment overlap parts of the other fragment parts. This can be used to fool firewalls and intrusion detection systems into assuming that the received packet fragments are legitimate where as the final reassembled packet contains some attack vector such as a specially crafted TCP packet. Later it was clarified that overlapping fragments cause all previously received fragments and those still on the fly to be discarded [137]. Atomic fragments are IPv6 packets that contain the fragment header with both fragment offset and 'M'-flag set to zero, that is, there are no other fragments following and the packet, even if it contains a fragment header, is not fragmented. IPv6 allows such packets because of potential IPv6 to IPv4 translation, where the IPv4 side of the network may require fragmenting packets to less than the minimum allowed IPv6 packet size of 1280 octets. An atomic fragment is triggered by an attacker sending a spoofed ICMPv6 Packet Too Big to a victim host containing a next-hop MTU value less than 1280 octets and the spoofed source address set to some third-party host. Now the victim host will (assuming it does not have other counter measures to mimic the spoofing) add a fragment header to every packet it sends to the third-party host. Now the attacker can launc