Provided A non-obvious reason against tunneling based approaches is the lack of 3GPP's bearers to differentiate tunneled traffic. This restriction comes from the Traffic Flow Templates (TFTs), which define rules for filtering traffic to different connections (e.g., between Primary and Secondary PDP Contexts). The TFT has rules only for the outermost headers (see Sections 4.1.1 and 4.4.7), and hence QoS differentiation cannot be provided based on the content of the tunneled header. Deep Packet Inspection (DPI) Costs A feature that 3GPP networks sometimes need for various reasons, such as for service enrichment or for traffic forwarding reasons, is a DPI. The DPI is not part of the 3GPP Deploying IPv6 in 3GPP Networks standards, but its existence is well recognized. Tunneling significant amounts of data would require more resources from DPI systems, and hence is unfavored - even if tech- nically DPI can look at the tunneled packets. MTU Implications Even today the MTU that can be provided for the PDN Connections is usually less than 1500 bytes, as the 3GPP network tunnels the user-plane packets over network segments that typically have 1500-byte MTUs. Adding any tunneling protocol would make the MTU smaller, and while that is not significant, it is still a waste. In some cases the tunneling also causes fragmentation and reassembly at the tunnel endpoints, and hence increases resource consumption and the risk of packet losses. In other cases, tunnel endpoints must generate ICMP Packet Too Big messages of the tunneled protocol address family type, when receiving Packet Too Big messages within the address family used for tunneling (e.g. in the IPv6-over-IPv4 case, if the tunnel endpoint receives an ICMPv4 Packet Too Big message, it may need to generate Internet Control Message Protocol version 6 (ICMPv6) Packet Too Big message) [2]. Added Complexities and Deployment Challenges Last but not least, getting tunneling implementations to a large number of different UEs, including the numerous Terminal Equipments (TEs) of S