TTP). These protocols, in addition to being able to use the IPv6 network layer, often need the ability to manage IPv6 address literals. Effectively all middleware protocols need updates due to IPv6. Last of the major parts of operating systems that require IPv6 changes are chipset drivers. The implications may be more significant, as is the case with drivers related interfacing 3GPP chipsets, or to a lesser extent when interfacing Ethernet-type networks. If the drivers happen to be the place that implements header compression algorithms, such as RoHC, then the implications are more significant. If nothing else, the chipset drivers need proper testing with IPv6. Even if it would seem that there are no address family dependencies, there may be: we have witnessed cases where power optimization functions caused problems for IPv6, as the optimizations assumed that only IPv4 was being used. Implications for Applications Depending on the API used by an application, and the class of the application, changes may be needed to support IPv6. If an application is using an address family aware API, it must be updated to support IPv6. Luckily, nowadays ordinary applications commonly use address family agnostic APIs (see Section 3.9.2) and hence can avoid changes. The applications requiring changes, independent of the API they use, are the ones that pass IP address literals as part of their protocol payload (see Section 3.9.3). Often, the protocol standards used by such applications, such as SIP and File Transfer Protocol Deploying IPv6 in 3GPP Networks (FTP), also need, or have needed, to be updated for IPv6. We have touched on this topic in more detail in Section 3.10. Implications for Chipsets For the longest time a significant hindrance for UEs' IPv6 support was the lack of support on wireless chipsets - on modems. For people familiar with Ethernet-based technologies this may seem strange, as in the Ethernet framing the IPv6 support has been there for such a long time already. In 3GPP the PDN Connection type and additional p