 infrastructure including AAA, and DHCP servers. If the operator is using this kind of infrastructure to manage IP address allocation, the infrastructure has to be upgraded to support IPv6 as well. In addition, the operator must obtain its own IPv6 address block from the local RIR. In addition, the services themselves have to be transitioned. For Internet access service, it should be obvious that the operator must make sure it has IPv6 capable upstream Internet IPv6 Transition Mechanisms for 3GPP Networks access. This is a relatively straightforward nowadays in most countries. Upgrading the operator's own services may, however, be more difficult, depending on the platform used to create the services, and the age of the platform. However, sometimes it may be possible to put a protocol translator (i.e. a NAT64) in front of an old service, and that way prolong the life of an older service platform. Some operators also run an infrastructure to enhance Internet or web access, and to monitor the traffic usage. This service infrastructure has sometimes been created over the years of operation, and may prove difficult to upgrade. However, if the operator wishes to use the same or similar infrastructure, the infrastructure has to be upgraded or replaced, or a new infrastructure for IPv6 access has to be created. 5.5.3 Tools to Divide Subscribers Per IP Capability Moving a large number of subscribers to IPv6 might not be something that happens overnight or is even close to trivial to provision and roll out. There are some known (not necessarily best) practices on how to start moving subscribers in reasonable blocks into IPv6 enabled service offering. We will present principles for some approaches. They all, more or less, circulate around provisioning tricks that are doable using APNs. We have left out various provisioning 'tricks' that concentrate on overwriting APN names based on various vendor-specific means, like charging characteristics (configured in the subscription profile), International Mobile Subscriber Identity 