Page 317 - From GMS to LTE

Long Term Evolution (LTE) and LTE-Advanced Pro 303

In practice the process takes around two seconds, which is slightly more than the IPv4
DHCP process. One could argue that this takes far too long, as in other places optimiza-
tions are standardized to remove a few additional milliseconds of already lightning‐fast
connection processes. Perhaps this is because IPv6 connection management was
designed at a time when devices were mostly sitting on desks and were permanently
connected to only a single network where a second more or less did not matter. For
compatibility reasons, IPv6 tethering to a mobile phone has taken over the process as it
was initially designed so there is no difference.

4.17.4 IPv6‐Only Connectivity
In the previous sections how to establish a dual‐stack IPv4 + IPv6 context was
described. The long‐term goal, however, is to completely replace IPv4 connectivity
with IPv6 connectivity, i.e. only IPv6 connectivity is requested during the attach
process to the cellular network. As the majority of services on the Internet are still
only reachable over IPv4, a cellular network operator needs to deploy an IPv4 to
IPv6 translation service in the network, referred to as Network Address Translation
6 to 4 (NAT64). IETF RFC 6052 contains the implementation details [32]. In prac-
tice this works as follows:
When a mobile device asks the DNS server located at the edge of the cellular net-
work behind the SGi interface to resolve a domain name to an IP address and only an
IPv4 address is available for the domain name, the server creates and maps an IPv6
address on the fly and returns it to the mobile device. This is referred to as DNS64.
To the mobile device it looks like the service is reachable over IPv6. Packets to this
IPv6 address are then routed by the network to an IPv4v6 gateway that exchanges the
IPv6 header for an IPv4 header and forwards the packet to the IPv4‐only service on
the Internet. In the opposite direction this gateway exchanges the IPv4 header of an
incoming packet with an IPv6 header and forwards the packet to the mobile device.
While this procedure requires a DNS server in the network that can map IPv4 to
IPv6 addresses and an IPv4v6 gateway, the procedure is completely transparent to
the mobile device.
One reason why IPv6‐only connectivity in mobile networks is not widely deployed so
far is that some mobile applications were designed in such a way as to specifically
require IPv4 connectivity, e.g. by hard‐coding the IP address into the application. The
number of such applications has significantly reduced over the years not least because
some mobile operating systems have deprecated and removed Application Programming
Interfaces (APIs) that lets an application choose IPv4 or IPv6 connectivity. Instead, only
APIs that are IP‐version agnostic are now available. For cases in which IPv6, for what-
ever reason, is not an option, the 464XLAT service has been standardized in RFC 6877
[33]. In addition to NAT64 in the network, this service adds a service on the mobile
device that terminates an IPv4 connection directly on the mobile device and forwards
all IPv4 packets as IPv6 packets to the translation router in the network. There, the IPv6
packets are converted to IPv4 packets again and routed to the destination. In the
opposite direction the procedure is reversed. This way, an application on a device that
requires IPv4 connectivity can still be used in an IPv6‐only cellular network environ-
ment. In practice Android supports 464XLAT and a few network operators such as
T‐Mobile in the US use it in practice [34].