is 32 bits. A class of Internet Control Message Protocol version 4 (ICMPv4) headers is supported for IPv6 by translation algorithms such as IP/ICMP Translation Algorithm [12]. Specifically it is stated for IP/ICMP Translation Algorithm and NAT64 that there is no attempt to translate IPv4 options. They are silently ignored except when the IPv4 packet contains unexpired source routing options, which then causes the entire packet to be discarded (and an ICMPv4 Destination Unreachable, Source Route Failed may be sent). State on the Network The traditional Internet Service Provider (ISP) model assumes the core network has as little per customer state as possible and the required NAT state is pushed down to the customer network. The less state the better the network equipment scales. CPEs equipped with a NAT from IPv4 to IPv4 (NAT44) made this model possible. Also various logging functions are easier to handle since every customer could still be identified uniquely by the CPE's public IPv4 address. Now there is a possible threat from the ISPs point of view that transition technologies change existing practices and the NAT function has to be placed inside the ISP core network. This would be the outcome when ISPs have to, for example, provide two levels of NAT when they run out of public addresses to number the CPEs [13]. Another example the stateful NAT64 function [14]. These stateful NAT functions may face real scaling issues, not to mention public authority requirements for address translation logging [15]. From a mobile operator point of view the situation is similar. There is the slight differ- ence as 3GPP has systematically refused to standardize and deploy transition/migration solutions that would have UE impact in a sense of new software requirements. The IPv6 transition comes with an additional cost: in order to provide UEs with a connectivity to IPv6 Transition Mechanisms for 3GPP Networks IPv4 Internet from an IPv6-only access technology (such as the Packet Data Network (PDN) Type IPv6 would provide) some mig