ement with IPv6 interfaces. Therefore, it is important to understand, early on, which systems in the network may be potentially problematic. Furthermore, quite often old hardware equipment has to replaced since the equipment vendor plain refuses to support IPv6 or any new features (excluding critical patches for software errors) on the old hardware. Plan carefully the transition. Based on the survey mentioned above, the system upgrades have to prioritized, scheduled, and the dependency of the systems understood. Start small in the beginning. Practically, the simplest service should be handled first - for example, Internet access with no web acceleration. In addition, it is important to start with a closed user group, or with a trial. When subscribers are participating in a trial, they understand better that the service may not always be of commercial quality, and even may have glitches now and then. In addition, a trial directed towards a technically inclined user group usually also provides more useful feedback than a commercial service would. Small user groups can also be more easily provisioned than a commercial, widely used service, especially if the subscriber provisioning system is not able to support IPv6 at the beginning. Start training early on in the transition project. IPv4 and IPv6 are very similar in many ways, but there are also many differences. Even technically capable engineers do benefit from training, as the knowledge accumulated with IPv4 may prove to be inadequate with IPv6. Training is especially important for customer support people, when the IPv6 service goes mainstream. There are guaranteed to be unexpected problems when the service is commercialized. It is important that customer support agents do know how to solve the problems, or are able to suspect IP-address family issues and know to where they can escalate them. Grow smartly as the service matures. A closed user group trial can mature the service nicely, but may not be adequate to hash out all the problems. Only adequate traffic Dep