At the beginning of this book, we promised that you wouldn't have to learn IPv6 to partake in the wonderful Unified Remote Access technology, and that was true. Nevertheless, understanding IPv6 and the transition technologies is not only a chance to prepare for the inevitable day when IPv6 becomes the common standard, it may also come in handy if you have to troubleshoot advanced problems with Unified Remote Access. In addition, if you are required to plan complex environments that integrate Unified Remote Access and other networking solutions, you might find the following information more than useful.
The topics we will cover in this chapter are as follows:
My network's fine, so if it ain't broken, why fix it?
The IPv6 addressing schemes
IPv6 address assignment
IPv6 and name resolution
A little more about DNS
Operating system compatibility
Protocol transition technologies
DNS64 and NAT64
Practical considerations for IPv6 and IPv4
Unified Remote Access and Group Policy
Public Key Infrastructure (PKI)
When the good folks at ARPA developed the protocols that our networks rely upon, they designed the 32-bit IP number system, which back then provided an IP to every single living man, woman, and child on the planet, with almost a billion addresses to spare. One thing they didn't count on was that the definition of a computer and a network would expand so much. Besides the fact that the world population has doubled since then, we all have a computer at home, one at work, a smart phone, and often some tablet stashed around the house somewhere too. It's not unusual to see a home network using 10 or more IP addresses. As a result, the entire range of 4,294,967,296 addresses has long since been allocated years ago, and since then, obtaining a public IP has been relatively hard and expensive.
An interim solution in the form of NAT (Network Address Translation) has been developed, and has been a viable workaround for pretty much everyone, but NAT has its own disadvantages. For one thing, NATing an address changes the headers in packets, and that causes problems with highly secure protocols such as IPsec. It also presents problems to certain application-level protocols such as FTP. Another challenge is performance, as the packet's header changes take time and resources. Ultimately, millions of businesses world wide are using NAT successfully, but one might consider it more of a workaround than a real solution.
IPv6 offers a solution to everything, as well as a design that is thought-out ahead significantly. For one, it allocates 128 bits for addressing, which provides us with an immense number of addresses. The actual number is 3.4×10^38, which gives every human being billions of IPs of his own. In fact, it would be virtually impossible to run out, as we would run out of space on the planet before we run out of addresses.
There are, of course, many other advantages to IPv6 over IPv4, such as built-in IPsec security, built-in address auto-configuration, improved performance for mobile routing, improved performance for routers, and more. We won't go into full details here, but we're sure that if you wanted to know all that, you'll have already found your way into any one of the lovely 600-page books dedicated to IPv6.
You've probably seen various network cards with IPv6 addresses, and after many years of sticking to simple four octet IP addresses, it may be a little intimidating seeing all those zeros and colons. "How the heck am I expected to remember my own IP address, let alone my entire network?",you must be thinking. Well, you probably won't remember as much, but after a few weeks of actually looking at the numbers, you'll start to see patterns, and things will make more sense. Here's an example:
The preceding screenshot is from a simple home client, and even though it should come as no surprise to you if you've been in the IT business for the past few years, the sheer amount of NICs on this computer may throw quite a curve ball. In reality, just the first interface is real, and the other three are virtual network interfaces. These NICs are there specifically to be a part of Unified Remote Access, and soon, you'll learn to love them!
Because the address space for IPv6 is so large, some measures were taken to make the addresses as readable to humans as possible. Had we used the regular 10-digit decimal system, an address would be comprised of 40 digits, which would have been quite crazy. Instead, the IETF
(Internet Engineering Task Force) decided to employ the 16-digit hexadecimal system, which uses the letters A to F in addition to the digits 0 to 9. Hexadecimal notation is common with programming, and is also used in the MAC addresses. You don't
really have to understand it, but do know that using it makes us able to write an IPv6 IP address with only 32 characters, so that's a 20 percent savings right there. For example, an IPv6 address could be
The colon symbol is used simply as a visual separator, just like we use commas when writing long decimal numbers (such as 1,000,000).
To make things even easier, something else that we can do is to cut out some of the zeros. This makes the numbers hard to grasp at first, but when the time comes to type or write the number somewhere, you'll start to appreciate this measure.
The first rule of IPv6 shorthand is that you can omit any leading zeros in a group. This means that if you need to write this:
You can remove the first two zeros in
0010, and the first zero in
0CB0. Naturally, this is not a real address, being half the size, but for our explanation, it will do. The resulting number is:
There, we saved ourselves writing three digits. If we want to apply this to a group of four consecutive zeros, we can, but we still have to leave one zero, so the number:
Will be cut to:
The second rule is that if the number has a large group of consecutive zeros, they can all be cut and replaced with a double colon. For example, the number:
Can be shortened to:
As you can see, we didn't cut out the three zeros in the second group. Those have to stay because they are part of the number
1000 (just like when writing regular decimal numbers, you can cut 010 to 10, but not to 1). Also, if the number has two separate groups of consecutive zeros, only one of them can be cut. In that case, the zeros that you can't completely cut out can still be shortened according to the previous rule. So the number:
Can be cut to:
It's actually easier to expand shortened numbers than compress them. Let's look at the number from the previous screenshot. As you can see, Windows shows them with lower-case, and that's perfectly fine:
Here, two of the groups were abbreviated; so what would be the full number? (Answer at the end of the chapter!)
This is referred to as
interface index. You will see these interface indices on addresses that are link-local addresses, which are addresses that are automatically assigned to each active network interface. These link-local addresses have the same network prefix starting with
FE80, so to make routing possible they get assigned that extra number representing the interface identifier that the operating system assigns to each NIC.
Another thing that's important to know about IPv6 addresses is that each address is split in the middle, with the left part being the network ID and the right part being the host ID. This may come as some relief, as you no longer have to try to figure out which part of the address is the network ID and which is the host ID by using the subnet mask as you often do with IPv4.
Some organizations would still need to split their network into subnets, of course. In such a situation, the network ID (the left half of the address) may be split up further as needed (for example, three out of the four groups being the routing prefix and the fourth being the subnet ID), but that's more relevant to those who are actually upgrading their network to IPv6 and as such is beyond the scope of this book.
With IPv6, these three ways are still available, although we refer to the third as stateless address autoconfiguration or
SLAAC (which also makes this one of the best acronyms in computer history alongside FAQ and SCSI). SLAAC is used when the system assigns itself the link-local address (the one starting with
FE80) that we discussed earlier.
The reality is that most administrators deploying Unified Remote Access (URA) will want to know as little about IPv6 as possible, and would rather not have to even think about messing around with DHCP scopes or subnetting. As luck would have it, you don't really have to, because the fantastic ISATAP mechanism will help you work things out. ISATAP
(Intra-Site Automatic Tunnel Addressing Protocol) is a protocol transition mechanism, which provides a way for computers to communicate, using IPv6 over an IPv4 network, and part of that is an automatic generation of an IPv6 address. The way this works is by Windows creating a virtual network card named
isatap, and assigning itself an IPv6 address that's based on the computer's IPv4 address. This would happen on all your modern desktops and servers (Windows XP, Windows Vista, Windows 7, Windows Mobile, Windows Phone 7, Linux, and even some versions of Cisco IOS). A computer or network device on your network will be designated as an ISATAP Router (more about that later) and your hosts will learn of its existence by querying your DNS server.
As you can see in the following screenshot, this computer assigned itself the ISATAP address of
2002:2f6b:1:1:0:5efe:10.0.0.3. Did you see those dots at the end? Yes! This shows us that the address was generated from the computer's IPv4 address of
10.0.0.3. Easy as pie!
If you prefer, you can ask your ISP to assign you an IPv6 subnet, and then create a DHCP scope from it to assign real addresses, and you could even assign those addresses manually to hosts. You can also work with your ISP to devise an IPv6 address allocation plan, if your network is complex.
We'll say this again, though you don't have to do any of this for the purpose of implementing URA. The reason for this is even though URA clients do use IPv6, the URA server will actually route that traffic and encapsulate it as IPv4 to the hosts on the corporate network. We will discuss this in more detail shortly.
Just like IPv4, IPv6 networking requires name resolution, and luckily, the Windows DNS service has been IPv6 ready for many years. IPv6-ready DNS can store name records for IPv6 resources, which is referred to as AAAA records, or Quad-A records. Modern Windows computers register both their regular addresses and their IPv6 addresses in DNS automatically, and when another computer attempts to resolve it, DNS will default to resolving the IPv6 address. The following screenshot shows the Windows Server 2012 DNS Manager, with several computers registered with both IPv4 and IPv6 addresses.
Since URA clients will be using IPv6 addresses, an IPv6-capable DNS is good to have around, so that when your corporate network computers try to connect to URA clients, DNS will help to resolve the addresses properly. One situation where things are a little more challenging is when an internal server is only capable of IPv4 traffic. This would include older operating systems, such as Windows 95, and certain devices running proprietary operating system or network stacks that haven't been updated.
To address such a situation, where the URA clients need to access an IPv4-only internal resource, the URA server role includes a function referred to as DNS64 (pronounced DNS Six-to-four) as well as another function referred to as NAT64 (pronounced NAT Six-to-four). However, it's important to know that this help can go only in one direction. This means that the IPv4-only internal server won't be able to initiate a connection to the URA client unless it is upgraded to fully support IPv6. The real-world impact of this is typically remote management. If one of your goals is remote management of remote clients, you will have to make sure that you have IPv6 capable servers for this task. Shouldn't be too hard to make this happen, right?
We discussed the special DNS records used for IPv6, and that brings up the question of which DNS server to use. Most organizations that deploy URA would typically all be using Microsoft DNS servers, and the good news is that Microsoft's DNS started supporting IPv6 way back in 2003. This means that even if your domain is a bit older, you're still good to go and don't need to upgrade the DNS. If your environment is using UNIX or Linux, you're going to have to make sure your DNS servers are running BIND version 9 at least, though we're sure you've gone there a long time ago, following the numerous security vulnerabilities discovered in the older versions of BIND.
Another aspect of DNS with regards to URA is the matter of internal vs. external name resolution. Your URA clients will have to be able to correctly resolve the public hostname of your URA server or your server array. While connected to the corporate network, the clients will have to be able to resolve the names of internal servers they need to contact.
If your organization is using the same DNS domain structure on the internal network and on the public internet, referred to as split-brains DNS, it can be tricky because you need to decide if you want URA users to access the published resources externally or internally. In such a case, you need to make sure that as clients move from using the internal DNS server on the corporate network to using the public DNS server that their ISP is hosting, they are still able to resolve all the appropriate URLs, and do so correctly. A problem could happen, for example, if there is a resource that is supposed to be accessible from both the internal network and the public one. Perhaps your SharePoint server is set up this way, or the company's public website may be. In such a situation, you have two options. One is to make a choice and have that resource available either internally or externally (only to the URA users!). The other option is to configure the resource with an alternative internal name.
A very important part of the DNS resolution mechanism for URA clients is the Name Resolution Policy Table
(NRPT). This is a piece of the name resolution mechanism on a URA client that is in charge of controlling how the client resolves internal and external hostnames. This table comes into play when the client is outside of the corporate network, and is used to manage the way name resolution is done on the client. When URA is on, the client needs to be able to resolve internal corporate network names, but still resolve public hostnames on the internet. The public DNS server that the client is configured with is still around, doing its job, and the URA server will be in charge of helping resolve internal hostnames. The NRPT simply tells the client for which network resources it should contact the URA server, and for which it should not. For example, the NRPT might say "For any hostname that ends with
Createhive.com, perform name resolution through the URA server, and for anything else, use the public DNS server you have configured". You will be configuring this later as part of the URA role setup, so we'll examine this with more detail later on, but keep this concept in mind as it's very important.
Pretty much every operating system released in over a decade supports IPv6 and we refer to this as dual stack—both an IPv4 TCP/IP stack and IPv6 TCP/IP stack. You would have probably noticed this in your network interface configuration page:
The reality is that a lot of administrators aren't sure why they need this and disable the IPv6 option on all their computers. This might be some misguided attempt to optimize the network, such as disabling NetBIOS, but in reality, it would be a pretty bad idea. By disabling IPv6, you're limiting the computer's options and so Microsoft recommends keeping this enabled. If you've been doing this for a while, it's time to start thinking how to undo it. The easiest way would probably be by running a script on all hosts via your domain login script. The article available at http://support.microsoft.com/kb/929852 can help you make this happen (though it applies to Windows 2008 servers and onward only).
This is even more important on the URA server itself. If you've implemented disabling IPv6 automatically in any way, make sure your URA server is excluded from this. Without IPv6, the URA server cannot perform its role.
Even though few companies in the United States have switched to IPv6, other countries have been faster to adopt it. The leaders are Japan, China, South Korea, and Australia. To make things easier, Microsoft developed IPv6 support many years ago, and starting with Windows Vista, it was enabled by default.
On older operating systems, IPv6 was available as an extra add-on. In Windows XP, for example, all you have to do to add it is open a command prompt on the client and run the command
netshint ipv6 install. On Windows 2000 computers, you can add IPv6 by installing an add-on pack from http://www.microsoft.com/enus/download/details.aspx?id=21676.
On other operating systems such as MacOS, Linux, and others, IPv6 is supported as well. Macintosh computers have had IPv6 support since Mac OS v10.3 (also known as Panther, released in late 2003). Linux kernels have supported IPv6 since the year 2000, with some code implemented in version 2.1.8 of the kernel, and any distribution using version 2.6 or later should support it fully.
To be clear, the preceding paragraph doesn't mean that these systems can become URA clients; we are only talking about the ability of the operating system to use IPv6, which impacts how it will integrate into the network.
Ultimately, not many organizations are ready for IPv6, and even those that are can't always go ahead full steam, as the costs can be significant. Many models of network hardware such as switches and routers can be upgraded to support it, but quite a few still don't, not to mention various embedded OS devices like vending machines, cash registers, entry control systems, and others. To make things easier, several transition technologies have been developed. We've already mentioned a couple of them, and now is the time to go into more detail and understand a bit about all of them and how they affect your network and deployment plans.
As we said before, ISATAP is a mechanism designed to allow IPv6 capable hosts to communicate over an IPv4 network. This would be useful if your network infrastructure (not referring to the cables, but to routers and the like) is older hardware.
ISATAP has some conceptual similarities to the connection mechanisms used by URA clients, but it is only used on the internal network and has a different purpose. It is designed to allow your URA clients to access IPv6-capable hosts (such as application servers or other computers on the internal network) even though your infrastructure is an IPv4 network. With ISATAP, the IPv6 data is encapsulated inside an IPv4 packet header, so the network infrastructure just passes it along, not knowing what's really inside. Hosts that are able to use ISATAP have a dual stack, meaning that they are configured with both an IPv4 IP address and an IPv6 IP address that is based on the IPv4 address. That IP starts with a standard prefix followed by five address groupings and then the IPv4 address.
To facilitate ISATAP, your network needs an ISATAP Router. This is not a physical router, but a software component that the URA server provides (you can also configure other servers to host this functionality). When you configure the URA role, you have the option of setting up the server as an ISATAP router. You can also configure any Windows server to be one, so you can have your URA server perform this function or configure it on another server.
When ISATAP capable hosts boot up, they will also need to know whether to use ISATAP or not, and for that, they will query the DNS server. In an environment that uses ISATAP, the DNS server would have an entry that will resolve the hostname ISATAP to the IP of the ISATAP router. Clients that are successfully able to resolve this will contact the IP provided, and will get their ISATAP configuration from the ISATAP router.
As an administrator, you have the option of either using ISATAP or not. Like any technology, ISATAP has advantages and disadvantages, and Microsoft does not recommend deploying it, except as a temporary means of enabling IPv6, while the organization prepares for full IPv6 implementation. In Chapter 8, Enhanced Configurations for Infrastructure Servers, we will discuss the advantages and some of the challenges of ISATAP, as well as how to enable this feature or move it to another server. If you want to enable ISATAP right now, follow these steps:
Create an A record named
isatapunder the forward lookup zone of your domain name.
Populate it with the IP of the URA server (if the URA has both an external and internal NIC, use the IP of the internal NIC).
Open Registry Editor on the DNS server.
Navigate your way to
Double-click on the GlobalQueryBlockList value.
Remove the name isatap from the list (it's perfectly normal for it to contain nothing else, but it would probably have wpad as well, which you should leave alone).
Click on OK and exit Registry Editor.
Restart the DNS service or reboot the DNS server.
Well, we have ISATAP to take care of IPv6-capable hosts, but what if we want to access hosts that can't use ISATAP? Older operating systems, such as Windows 2000 and older are not able to use ISATAP—the component is not included in the operating system. This also pertains to many non-Microsoft platforms that you might be running. For them, URA includes two additional services—DNS64 and NAT64, which are discussed in our next topic.
URA clients communicate using IPv6, and so for things to work correctly, any resource they need to communicate to must resolve to an IPv6 IP address. The DNS64 service helps take care of that. DNS64 (pronounced DNS six-to-four), as its name suggests, is in charge of resolving the IP addresses for the URA clients. When a URA client needs to communicate with an internal hostname, the DNS64 component provides an IPv6 address that represents the IPv4-only host.
NAT64 (pronounced NAT six-to-four) performs an action that somewhat resembles what traditional NAT does, but specifically for IPv6 transition. The acronym is the same—Network Address Translation—but where traditional NAT "translates" traffic from public IPs to private IPs and vice-versa, NAT64 translates traffic from IPv6 hosts to IPv4 hosts and vice versa.
As opposed to the mechanisms we described earlier, 6to4 is more of a client-side mechanism. It's designed to allow IPv6-capable hosts, such as your URA clients, to communicate with your URA server over the Internet, significant parts of which are still only IPv4 capable.
For 6to4 to work, the operating system assigns itself an IPv6 address which is based on its IPv4 address. Then, when the computer needs to communicate with another IPv6 host, such as your URA server, the 6to4 component embeds the IPv6 packets in the payload portion of an IPv4 packet with protocol type 41. These IPv4 packets are then sent to the IPv4 address of the URA server, which extracts the IPv6 packet back, and passes it along to the IPv6 stack.
One challenge with 6to4 is the fact that protocol 41 is blocked by default on many networks. If either the client's ISP or the ISP that your corporate network uses blocks this protocol, 6to4 communications won't work. Another potential pain in the neck is that 6to4 cannot work behind a NAT network, because a 6to4 address is generated only when the client has a public IPv4 address (as opposed to ones that are behind a router and have a NAT address). Since home routers, which perform NAT translation, are very common these days, this effectively blocks the 6to4 mechanism. Thankfully, there are additional mechanisms like IP-HTTPS and Teredo, which we'll discuss in the next sections.
The bottom line of this, as far as you are concerned, is that you have little control over this option. When you configure your clients to use URA, some of them will establish their connection using 6to4, but only those that have a public IPv4 address. This means, of course, that only a small portion of your clients will do so. Those which cannot use it will automatically fall back to one of the other mechanisms, which we will discuss next.
For URA clients connecting from the Internet, Teredo is another client-side transition technology, which is the fallback when 6to4 cannot be used. When a URA host is unable to use 6to4, usually because the protocol 41 is blocked, Teredo springs into action. With URA, Teredo is yet another virtual network card (as opposed to the pesky Teredo Navalis clam!), and this is how it looks:
You can also see it in the preceding screenshot, at the bottom of the screen. The Teredo adapter is included with modern Windows computers.
Teredo also encapsulates the IPv6 packets within IPv4, but it uses UDP packets on port 3544 instead of protocol 41. With UDP being more ubiquitous than protocol 41, it's less likely to be blocked by the network infrastructure, and therefore more likely to go through in most networking environments. In addition, Teredo has a special mechanism that allows it to transcend through NAT networking, so it can work even if the client is behind a home router.
On a Teredo client, such as your URA clients, the operating system assigns itself a unique IPv6 address, which is also based on its IPv4 address. The address begins with the prefix
2001:0000, followed by the IP of the Teredo server (
4137:9e76 in the preceding screenshot). The address also has the UDP port mapped on the NAT device (
b4 in the preceding screenshot) and finally, the public IPv4 address of the host (
e7ee:3d10 in the preceding screenshot). This IP is not the IP of the host itself, but the public address that the NAT device uses.
these numbers are obfuscated with a binary inversion of the bits. For example, the externally mapped UDP port is
b4 as shown in the preceding screenshot, but that's actually
FF4B (65355). To calculate the number, if you care to go that deep, launch your Calculator and switch it to the Programmer mode. Then, perform
b4 xor ffff and you will arrive at this result:
The IP of the host is obfuscated similarly.
Once Teredo comes into play, the server performs a discovery process to determine the type of NAT that the client is behind, which helps it determine how to communicate with it reliably. Once this process concludes, the IPv6 traffic is encapsulated and the communication process can continue.
The practical considerations for using Teredo are few, as you have little to do. Just like 6to4 that we mentioned earlier, the user or you have little control over which mechanism is used—it depends on the network infrastructure. If the network blocks protocol 41, 6to4 cannot be used, and the client will automatically fallback to Teredo, and there's nothing you can really do about that (other than, of course, to tell the user to connect to the internet somewhere else, where protocol 41 is not blocked).
Occasionally, Teredo may run into a situation where even it is unusable. This could happen in certain networks where the type of NAT cannot support Teredo, or when UDP port 3544 is blocked by the network infrastructure or ISP. It's pretty rare, but not unheard-of, and in such situations, an affected client will automatically fall back to yet another mechanism, which we will discuss shortly. One thing you can do is manually disable the Teredo interface, and that's something you might need to do as part of troubleshooting. We will discuss troubleshooting URA in Chapter 10, Monitoring and Troubleshooting Unified Remote Access of the book.
IP-HTTPS is the third IPv6 transition mechanism used by URA clients and is the last fallback mechanism in case both 6to4 and Teredo fail to connect. With IP-HTTPS, IPv6 packets are encapsulated inside the HTTPS traffic, which is sent over the TCP/IP port 443. From the three client-side transition mechanisms, IP-HTTPS is the most reliable, because almost no network blocks HTTPS traffic, and so it's virtually impossible for this mechanism not to work (beyond specific misconfiguration or other technical malfunction, of course).
With the previous incarnation of Unified Remote Access (that is, DirectAccess), IP-HTTPS was considered to be a less desirable option, because the addition of the SSL encryption that HTTPS uses was somewhat of an over-kill, as the connection already uses IPsec. Double Encryption is not only redundant, but also costly, as it forces the client and server to work harder to encrypt or decrypt each packet twice. However, with URA, the SSL traffic actually does not encrypt the data (we refer to this as null-encryption), so there's less work for the client and server to do, and this results in better performance. In other words, if you have implemented DirectAccess in the past, and are used to thinking badly of IP-HTTPS, forget about it, as it's no longer an issue. In the following screenshot, you can see the IP-HTTPS virtual NIC in a Windows 7 computer's device manager:
On a client, IP-HTTPS is automatic, and there's nothing for you to configure. On the URA server, you will be required to get a digital certificate, which will be used by the server to prove its own identity to clients. This requires some planning and may be a bit of an effort to get. Also, it can prove costly, if you get it from the more expensive certificate providers. We will discuss this process later, when we will see how to configure the server.
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:
Internal resources limited to IPv4 connectivity
Software that cannot use IPv6
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.
A piece of software called App46 by IVO networks aims to allow IPv4-only applications running on URA clients (as well as Windows 2008 R2 DA clients and UAG DA clients) to communicate with servers on the corporate network (though it doesn't alleviate the Lync VoIP situation). If you have identified IPv4-only software that you need URA clients to use, contact IVO networks to see if it is a suitable solution for you.
If you have a modern Windows network, the concept of Group Policy is probably not new to you. For Unified Remote Access, this mechanism is very important, as it's the main delivery mechanism for URA configuration. While many commercial VPN technologies require you to configure the VPN settings on the client manually (at least to some degree), with URA, all this is taken care of by Group Policy.
To this end, the URA server creates a set of policies in your domain and these are defined for the scope of a special security group (or groups) that you choose. Once members of these groups connect to the domain, they receive an update to their Group Policy, which includes the various settings they require in order to connect. This is an extremely convenient mechanism, as the unpleasant experience of having each user configure his connection is no longer going to be part of your life. It also means that your users won't be able to simply erase their configuration or damage it. In fact, to do so, they will have to work mighty-hard! This is not to say that URA deployment is always problem-free, but at least that part is taken care of.
We will learn how to configure and deploy the policies in Chapter 3, Preparing Group Policy and Certificate Infrastructure. However, if you have never used Group Policy, now would be a good time to pull out those MCITP books (or MCSE, if you're nostalgic) and brush up on that topic. The article available at http://technet.microsoft.com/en-us/library/cc725828(v=WS.10).aspx may also be helpful.
The role of PKI (Public Key Infrastructure) in URA is important to understand. With Windows 2008 R2, it was required to deploy certificates to every computer that needed to be a DirectAccess client, but this is no longer a mandatory requirement today, thanks to a component that proxies Kerberos authentication instead of using a certificate for the IPSec authentication. It's important to note, though, that this component can be used only if all your URA clients are Windows 8 clients. If you will be deploying this to the Windows 7 clients, you will still require this infrastructure, and we will discuss this in more details in the next chapter.
Even if you choose to deploy URA without issuing certificates to clients, there are other certificate requirements. Earlier, we mentioned that one of the IPv4-IPv6 transition technologies is IP-HTTPS. This requires the URA server and client to communicate with SSL, and for that, you will require a certificate. This can be achieved with a self-signed certificate, produced by the URA server as part of the setup, and it even publishes the root certificate through Active Directory so that your clients can trust it with no need for manual intervention.
The certificate used for this purpose is a server certificate and will be presented to the URA client by the URA server as a means of proving its authenticity. If you prefer, you can use a regular certificate, which can be purchased from any of the many commercial certificate providers such as Verisign, Thawte, and Geotrust. Using a public certificate provider for this situation has costs, of course. Another option is to use the Windows Certificate Authority role that's built into every Windows Server product and create a regular certificate at no cost. The challenge with using an "internal" certificate provider like that is the fact that all your URA clients will have to trust it, which means that if it's not integrated into your domain, you will have to find some way to deploy its root certificate to all clients. Another challenge is that a certificate generated by a certificate authority contains a CRL (Certificate Revocation List), which needs to be accessible to the client as part of the connection process. For this to work, you will need to publish the CRL to some publicly accessible website, and that may be somewhat challenging. We will discuss this topic in more details later on, but you can prepare for this by reading up on managing a Windows certificate authority through the article available at http://technet.microsoft.com/en-us/library/cc738069(v=ws.10).aspx.
This chapter introduces quite a bit of jargon and may be a little hard to swallow at first. It should not, however, prevent you from going forward and start dealing with the next steps of deploying URA. In the next chapter, we will discuss planning your deployment, and go through various considerations and scenarios. If you don't feel 100 percent comfortable with all the terms and technologies introduced here, don't worry—you can always come back to it, and after having played with the actual interface of URA a bit, things will make a lot more sense!
Answer to question 1:
Answer to question 2:
The obfuscated IP
e7ee:3d10 is 1110011111101110:0011110100010000in binary. Inverted, it is
1811:C2EF in hex. Now, convert each two hex digits to decimal, to arrive at the IP