As we've said quite a few times already, you can fully deploy URA with little to no knowledge of IPv6, because all the above technologies are designed to be almost completely automatic. By default, modern operating systems are ready for IPv6, as well as the transition mechanisms, so you don't have to configure anything. When you configure the URA role, the server will install and configure all the transition technology components, and the only thing you need to do is set the DNS record, as we described earlier. On your clients, there's little to do either, as a standard Windows client contains all the components you need. This isn't to say that deploying URA will be easy—you have quite a way ahead of you, but once you configure that and deploy to clients by using Group Policy, you will have virtually nothing else to worry about.

Many people prefer to learn just the bare minimum they need to survive and deploy something, and if you're one of them, you might prefer to put all this new terminology aside. However, it is important to keep in mind that these technologies are here to help you. By being there, in all their complexity, they provide your users with the kind of automation and redundancy that will let you and your support personnel sleep better at night.

As we mentioned earlier, one challenge that you might be looking at is working with resources on your network that are limited to IPv4 only. This applies to the following:

For internal resources that cannot use IPv6, we mentioned DNS64 and NAT64, which will allow your URA clients to access them anyway, by translating this traffic. However, the reverse is not possible, and if you want some remote management server to connect to your URA clients and perform some action on them, it will have to fully support IPv6. If it does not, your only option is to upgrade the server.

A more common situation is one where the URA clients use some kind of software that isn't IPv6 compatible. One common example is Lync 2010, which cannot be used over a URA connection. The current Lync 2013 works over IPv6, but in order for voice and video calls to work, the round trip time between Lync 2013 client and server should be less than 50 ms. The limitation is because of the way SIP (Session Initiation Protocol) works for voice communications, and at the time of writing, affects virtually any voice over Internet Protocol (VoIP) software on the market.

This doesn't mean that you cannot use Lync 2010 or other VoIP on a URA client, just that the traffic cannot be configured to go through the URA tunnel. Instead, you will have to publish your VoIP server on the public Internet, just like you would do if you didn't have URA. Then, configure the Lync application on client computers to use the public server to establish the voice sessions, and things should work out well.