Given the discussions in Part 1 of this series, all further articles assume that we are using (or talking about) UAG DirectAccess and not native DirectAccess.
One of the first decisions when beginning a DirectAccess (DA) design, or deployment, is to consider the intranet IPv6 connectivity model as discussed here. This decision is often greatly biased by the existing network configuration and infrastructure in use. However, it is likely that the DirectAccess implementation is the first project that may have raised the question of intranet IPv6 addressing. This is probably something you have been aware of with the introduction of the IPv6 protocol stack in modern Windows client/server operating systems, but often it becomes “…something else to learn about when I have more time…”
Intranet IPv6 Addressing Strategy
Given the choices available, it is likely that ISATAP-based IPv6 connectivity will be the optimum solution; or only viable option available for environments running IPv4-only networks. This is especially true for environments that cannot support the native IPv6 needs at the networking hardware and/or routing layers.
However, as good as ISATAP is, it is not a pure or final solution and is designed as a transitional step in an overall IPv6 deployment plan.
From what I have read, an alternative approach for an IPv6 deployment is to use Dual Stacks as opposed to Tunnelling technology (like ISATAP) where hosts are configured with both IPv4 and IPv6 addresses at the same time. The dual stack approach is relatively easy to configure, pretty flexible and often simpler to implement than encapsulation or tunnelling technologies. This approach also seems to remove the following ISATAP limitations:
- The client OS needs to support ISATAP, fine for Windows, but maybe not everything else.
- For a client OS that does support ISATAP, we introduce an ISATAP device/adapter which can break or require troubleshooting.
- Typical of all tunnelling technologies, tunnel entry and exit points need to perform additional work (encapsulation) and potentially become single points of failure for IPv6 communications.
- The use of ISATAP is not always desirable in environments where Network Intruder Detection Systems (NIDS) are present.
Not wanting to make things too easy, I started to think about considerations for deploying IPv6 on intranet systems as a pre-cursor to our actual DA implementation. We are going to have to do this one day I thought, so why not start sooner rather than later! It would also force my ascent of the Ipv6 learning curve to begin a little earlier than I predicated :)
The end result of this planning would be to allow me to define the correct IPv6 prefixes in Prefix Configuration section of the UAG DA wizard.
Based upon Ben Bernstein’s blog entry available here there would seem to be only two real options when looking at a suitable intranet addressing strategy as part of an overall DA deployment:
- Option 1: Obtain Global Unicast IPv6 addresses from my ISP
- Option 2: Utilise the IPv6 6to4 addressing format based upon our own public IPv4 address space
After contacting our ISP, it (finally) became apparent that Option 1 was not achievable at this time for any of our Internet connections, which made the choice pretty easy ;)
So, how do we go about creating a suitable 6to4 addressing structure for our environment?
Creating the IPv6 Address Structure
First, the complicated bit…
All 6to4 addressing begins with ‘2002:’ and this is defined within the first 16bits of the IPv6 128bit address. The next 32bits are defined based upon a hexadecimal representation of one of the IPv4 public IP addresses assigned to the UAG external interface. The next 16bits are used to represent the subnet ID. The remaining 64bits are used to represent the host address. This can be summarised as follows:
:[Public IPv4 Address in Hex]:[Subnet ID]:[Host Address]
So, let’s make this a bit more real (and hopefully easier) by using a specific example lab environment as shown below:
As can be seen, our first public IP address is 18.104.22.168. If we separate this into specific octets we get:
If we now convert each of the numbers in square brackets into hexadecimal we get:
[0b]   
So our 6to4 address now becomes:
:[0b96]::[Subnet ID]:[Host Address]
To make things a little easier, you can also use Excel to generate the hexadecimal version of the public IPv4 address using the following formula:
=DEC2HEX(((VALUE(LEFT(A2, FIND(".", A2)-1)))*256^3)+((VALUE(MID(A2, FIND(".", A2)+1, FIND(".", A2, FIND(".", A2)+1)-FIND(".", A2)-1)))*256^2)+((VALUE(MID(A2, FIND(".", A2, FIND(".", A2)+1)+1, FIND(".", A2, FIND(".", A2, FIND(".", A2)+1)+1)-FIND(".", A2, FIND(".", A2)+1)-1)))*256)+(VALUE(RIGHT(A2, LEN(A2)-FIND(".", A1, FIND(".", A2, FIND(".", A2)+1)+1)))),8)
where A2 is the cell containing the IPv4 address in a standard A.B.C.D format. This can be seen in Excel below:
Therefore, we now have the first 48 bits (16bit 6to4 Prefix+32bit IPv4 Address) of our 128 bit IPv6 address and now need to decide how we choose, or generate, the remaining 80 bits.
In general, we have two options:
- Manual address configuration
- Automatic address configuration
These are discussed below.
Manual Address Configuration
Although it is not ideal for scalability reasons, it is possible to manually configure hosts with static IPv6 address using the above 6to4 format. However, IPv6 routers do need to be manually configured for IPv6 addresses and routing behaviour. Therefore, if you plan to utilise native IPv6 intranet addressing, UAG needs to be configured with a manual IPv6 address before you begin using the UAG DA wizard. It is also necessary for UAG to be configured with an IPv6 address to ensure the DA wizard provides the option to enter IPv6 prefix information for a native IPv6 environment, as opposed to automating the ISATAP deployment and bypassing the prefix configuration step. More information on this is provided here.
Given the above formatting, we need to decide on how to define the last 80 bits of the address; which equates to:
[Subnet ID]:[Host Address]
In theory, you can choose whatever you want; or you could use the following example approach to define IPv6 addresses using a logical, repeatable process. This allows for mapping between IPv4 and IPv6 addresses on the same host, which can be handy for manually defined addresses.
Microsoft seems to favour the use of 8000 for the subnet ID in most documented examples, so I see no reason to differ:
[Subnet ID] = 
[Host Address] = [Host IPv4 Address in Hex]
So, for an internal host with an IP address of 172.16.5.102 this becomes:
which in full (uncompressed form) becomes the following IPv6 address:
or more simply (including the use of double colon zero compression formatting) this becomes:
With the address defined, we can now configure the actual IPv6 properties of the Windows intranet host as follows:
|Please Note: Based upon the examples I have seen, it is normally recommended to configure a single UAG server with a native IPv6 address of :[Public IPv4 Address in Hex]:[Subnet ID]::1 so in our example this address would become 2002:b96:4:8000::1|
Automatic Address Configuration
An IPv6 host that is not a router can be automatically configured using one of the following two methods:
- Method 1: Stateless address auto configuration with IPv6 router discovery
- Method 2: Stateful address auto configuration with DHCPv6
With method 1 (stateless), the IPv6 host builds its IPv6 address based on the Router Advertisement sent by the IPv6 router attached to the same network segment that the IPv6 host is connected to. This method is often enabled by default.
With method 2 (stateful), an IPv6 host can receive subnet prefixes, host addresses and other configuration parameters via DHCP. Even if not specifically assigning IPv6 host addresses, a common use of DHCPv6 for Windows-based IPv6 hosts is to automatically configure the IPv6 addresses of DNS servers, which are not configured through the Router Advertisement (method 1).
|Please Note: Before moving onto specific examples of UAG server configuration for address auto configuration, it should be understood that these examples assume that UAG has already been configured for DirectAccess and is configured with a static IPv6 address on the UAG internal interface. Details on the actual UAG DirectAccess setup will be provided in Part 3 of this series.|
Configuring UAG for Method 1
Assuming you have a pretty simple network (like our test lab) it is possible to configure the IPv6 router element of the UAG server itself to provide the necessary router advertisements needed for method 1.
|Please Note: I am currently unsure as to the Microsoft supportability of this configuration on a UAG server, but I have tested it in both lab and production environments to good effect.|
So, router advertisements can be achieved using the following commands on the UAG server:
netsh interface ipv6 set interface “Internal Network” advertise=enabled
netsh interface ipv6 set interface “Internal Network” managedaddress=disabled
Advanced Note: The first command configures the UAG IPv6 router to send router advertisements needed for stateless address auto configuration. The second netsh command sets the ‘M’ flag to 0 (zero) as discussed here.
In theory, any IPv6 router can be configured this way, but as this article is related to UAG DA, we can use this for our example.
The last element we need to configure is the route entry on UAG to advertise the correct prefix for stateless IPv6 host addressing for ‘on-link’ hosts (off-subnet hosts will need additional consideration). This can be achieved using the following commands on the UAG server:
netsh interface ipv6 add route 2002:b96:4:8000::/64 “Internal Network” publish=yes
or if the route is already present:
netsh interface ipv6 set route 2002:b96:4:8000::/64 “Internal Network” publish=yes
where 2002:b96:4:8000::/64 represents the prefix to be used for stateless auto configuration addresses.
This will essentially provide the first 64bits of the IPv6 host address to match the chosen IPv6 prefix. The remaining 64 bits will then be defined automatically.
So, with the above configuration applied, all IPv6 capable hosts (with auto configuration enabled) should begin receiving automatic addressing with the following format:
2002:b96:4:8000::[Randomly Generated 64 bit Hex Value]
for example, like this:
|Please Note: I cannot find any specific guidance on defining 6to4 based IPv6 addresses for Domain Controllers and DNS Servers, but it would seem sensible to define these server roles with manually defined static IPv6 addresses. Alternatively, they could be assigned using DHCPv6, but leased to a reoccurring (pseudo-static) address every time with the use of DHCPv6 reservations.|
Configuring UAG for Method 2
An IPv6 host performs stateless address auto configuration automatically. However, if you prefer to assign IPv6 host addresses using DHCP (method 2) you can use the following commands (instead of the above) on the UAG server:
netsh interface ipv6 set interface “Internal Network” advertise=enabled
netsh interface ipv6 set interface “Internal Network” managedaddress=enabled
netsh interface ipv6 set interface “Internal Network” otherstateful=enabled
|Advanced Note: The first command configures the UAG IPv6 router to send router advertisements needed for stateless address auto configuration. The second netsh command sets the ‘M’ flag to 1 (one); and the third netsh command sets the ‘O’ flag to 1 (one) as discussed here.|
Addresses will then be assigned as per the scope/options configuration of the DHCPv6 server. More information on DHCPv6 be found here.
Limitations of Using an IPv6 6to4 Addressing Format
The key downside to using a 6to4 based approach is that your intranet IPv6 addressing structure will be intrinsically linked to your public IPv4 address space. Consequently, if you change ISP and move to a new IPv4 address space, you will likely need to amend your internal IPv6 addressing accordingly. This is obviously far from ideal and this is why using Global unicast IPv6 addresses is the optimum and most future proof option when planning for a native IPv6 intranet. This assumes that your ISP supports providing an IPv6 prefix that is!
Please Note: The automatic ISATAP model deployed using Forefront UAG for IPv4-only networks is also based upon the use of a public IPv4 address dependencies. Therefore, it also suffers the same limitations defined above if the public IPv4 addresses are changed.
Finally, it should also be considered that if you begin using 6to4 or ISATAP based addressing initially, you will ultimately need to change everything once you can obtain a Global unicast IPv6 range from your ISP. That is the consequence of early adoption folks! ;)
Preparing for UAG DirectAccess with Native IPv6
Returning to our original need to define the correct IPv6 prefixes in the Prefix Configuration section of the UAG DA wizard and how to define appropriate intranet IPv6 addresses for our environment, we now have:
Intranet IPv6 Addresses:
2002:b96:4:8000::[Manual or Automatic 64 bit Hex Value]
where the definition of manual or automatic hex values is based on the chosen manual or automatic address assignment models (method 1 or method 2) discussed above.
UAG Internal Interface IPv6 Address:
So, hopefully this (now rather long and a bit complicated) article has helped provide some guidance on using UAG DirectAccess with native IPv6 addressing, as opposed to the more common ISATAP-based IPv6 connectivity approach. I can obviously see the benefits of using ISATAP, but I also like the approach of using this Dual Stack model for a slightly more elegant approach that moves the intranet a little close to the pure IPv6 intranet of the future.
In the next article we will begin looking at the actual UAG DirectAccess deployment, aptly titled The Path to DirectAccess - Part 3: Putting it All Together, which uses the IPv6 information derived/presented within this article.
See you soon!