explicit end host to DNS(64) server signaling using EDNSO option [35]. In the absence of the protocol level solution a practical approach to solving the problem would be configuring a split view into the DNS server. In order for this to work, IPv4-only and dual-stack capable end hosts must configure their own prefixes from a different prefix than IPv6-only end hosts. Then a simple Access Control List (ACL) matching against source prefixes can be used to select appropriate DNS server internal behavior. There are still cases where views do not work as hoped. For instance, in 3GPP network deployments the same APN can be provisioned for both IPv4-only UEs, IPv6-only UEs, and dual-stack UEs. If the APN uses exactly the same IPv6 prefix pool for all IPv6 subscribers, then the DNS view solution will also fail. However, implementing proper IP pool management in the Authentication, Authorization and Accounting (AAA) backend and using PDP/PDN Type as a selector for a correct IPv6 prefix pool, then DNS views can also be made to work. Internet Systems Consortium (ISC) Bind DNS server open source software starting from version 9.8.0 would support the required DNS64 and view configurations. Early trial deployments of NAT64 technology have already provided initial operational experience [36]. High availability is a real concern in large scale deployments. However, as in any stateful network nodes, it may not be trivial to move the state to the secondary nodes when the primary dies, unless hot standby solutions are used. The same also applies to NAT64. Another operational concern is traceability that is increasingly demanded by authorities for various reasons. As in any NAT solution, the connection traceability solu- tions might produce unbearable volumes of log data. Solutions such as predefined ports ranges and such may help but are not necessarily the final solutions. NAT64 Discovery While NAT64 and DNS64 work well for applications that are able to utilize IPv6, some issues remain. Specifically, if an IPv6-enabled application