Microsoft Direct Access: Is it Heaven or Hell for IPv6?

I must confess, during the past couple of years I have highlighted the VPN-solution Direct Access (DA) from Microsoft as a killer application for IPv6. I still have hope for this solution, but as I now have had the chance to study the UAG/DA-solution more closely and in practical implementation, I must also highlight some issues for Microsoft to handle.

My conclusion is that using DA today brings difficulties when it comes to an organization that already has, or wants to, deploy native IPv6 internally.

In this post I won’t discuss any pros or cons regarding security issues and if DA is secure enough. This will only focus on implementing with IPv6. I do find DA to be great VPN solution that use IPv6 to automatically transport the client to the office, creating a high “I’m at the office feeling”, almost from wherever you are and have an Internet access. It is easy to use and the client doesn’t need to activate it. It uses the “Network Location Server” to see if you are trying to connect on the internal office network or not. If you’re not, it will activate the VPN.

The IPv6 transport can be a native IPv6, a tunnelled transport via 6to4 or Teredo and the last choice a iphttps (which is https over IPv4). An DA client can therefore often get a VPN-connection to the office since the famous https-port, 443, is most often open in the firewalls.

Microsoft DA can be installed as a feature in Windows 2008 R2 server or as a part of Microsoft Unified Access Gateway, UAG. UAG gives the possibility to use NAT64/DNS64 through which IPv4-only hosts can connect through IPv6. For more details regarding this, please read Microsoft’s document.

Ok, so far so good, but didn’t you mentioned some problems? I sure did, and here is what Microsoft needs to target:

  1. If you install DA as a feature, the built-in firewall in Windows Server 2008 R2 have support for IPv6, but you can only build in- or outbound rules. You can’t get any IPv6 traffic to pass the server.
  2. If you install UAG, the built in firewall disables and instead the Microsoft Forefront Trust Management Gateway installs. But the TMG however doesn’t support IPv6 at all.
(Here there are some Powershell-script that can set some IPv6-firewall rules. But come on Microsoft, it is 2011 today, not 1991.)
  3. Many, many organizations use other firewalls then TMG to protect their infrastructure. The DA/UAG design is mainly for organizations who have a “Microsoft only design”

Below there are two pictures on how to deploy a DA/UAG server. The information is taken from Microsofts “UAG DirectAccess Server Deployment Scenarios”, which in turn can be found on this page:

The pictures explain more about the points 1 to 3 above.

UAG DA server in parallel with your existing firewalls

In this case you have to place your default IPv6 route to the UAG DA server and the Native IPv6 is broken.

UAG DA server placed between two firewalls

In this case the TMG/DA breaks the native IPv6 support since the TMG doesn’t support IPv6. Even if the TMG should support IPv6 there is in hand to point out that this means one more single point of failure in the Internet connection.

So how do we deploy native IPv6 with UAG/DA?

Of course there are other ways to do this but I have found a solution that works fine even if you already have native IPv6 in your organization. [Which by now you of course have done :) ].

DA/UAG demands two network interfaces, one external and one internal interface. The external interface must have two consecutive IPv4 PA/PI for Teredo and 6to4 connectivity, this goes even if you have native IPv6 already.

Disable Teredo and 6to4 Interface in the VPN-clients so only native IPv6 IPSEC and iphttps is enabled. I don’t recommend disabling native IPv6 on the client, perhaps this goes without saying but this is of course since we now are very close to the first RIR IPv4 depletion and native IPv6 therefore must be deployed in many places.

Place the UAG/DA server like the two pictures below. On the first you can filter everything except IPv4 https and you also have only one firewall to manage with rules. In the last example you have two firewalls to manage, which brings a different discussion of pros and cons.

Most important with the above is that none of the setups disturbs the other native IPv6 in the organization.

Place the UAG/DA on two ‘DMZ’

In this solution you have a total control of the traffic to/from the UAG/DA server and only one firewall to manage the in- and outbound traffic. There are some IPv4 and IPv6 routing to take care of and it also demands a DMZ. The DMZ needs to have a PA/PI IPv4 space and, as everyone knows by now, the IPv4 space is soon to be totally depleted. The internal interface in the UAG/DA can also be placed in a L3 IPv6/IPv4 switch where the iphttps-IPv6-prefix is routed. However, You can’t then control the IPv6-traffic to the internal network.

One DMZ for the UAG/DMZ

In this case a DMZ with PA/PI IPv4 space is not needed but you have to manage two firewalls, again with the pros and cons of that.


I think Microsoft DA/UAG is a good VPN solution. But Microsoft need to make some changes urgently since the IPv4 is soon to be depleted and to the fact that the boom in IPv6 deployment is already here. I would strongly recommend and welcome a solution from Microsoft where a new native IPv6-interface, like iphttps but with the use of NAT66/DNS66 to solve the “native IPv6 and other firewalls than Microsoft-problem”. Before that is realized I recommend to use Microsoft UAG/DA with caution according to above, so you don’t break the real Ipv6-world.

Written by Torbjörn Eklöv, CTO, Senior Network Architect, DNSSEC/IPv6

7 Must Have Attributes of an IP Address Management System

Exponential growth of networks combined with the complexity introduced by IT initiatives e.g. VoIP, Cloud computing, server virtualization, desktop virtualization, IPv6 and service automation has required network teams to look for tools to automate IP address management (IPAM). Automated IPAM tools allow administrators to allocate subnets, allocate/track/reclaim IP addresses and provide visibility into the networks.

Here are some examples of what a typical IPAM tool can do:

  • Create a subnet for a new branch office
  • Assign a new static IP address to the new printer
  • Reclaim IP addresses as older servers are decommissioned
  • Keep accurate record of IP assignments and associated data e.g. MAC addresses, OS type, switch port connectivity etc.
  • Discover devices on the network and update data
  • Etc.

Most of the organizations use manual spreadsheets and home grown tools to accomplish these activities. At first look any automated IP address management solution seems like a vast improvement over status quo and ease of procurement and pricing become the prime deciding factors. However, as thousands of IPAM users would testify, an automated IP address management system is becoming increasingly critical to most of the IT initiatives. A well thought out IP address management automation solution will likely pave the way for more complex IT initiatives.

Here is a list of seven MUST HAVE attributes of an IP address management system:

1. Discovery and reporting of end devices, infrastructure and linkages between the two

A good IP address management automation solution can capture information in various ways including data import, lease information from DHCP servers and static IP assignments; an automated discovery remains the most useful one. Here are the things to look for when comparing discovery capabilities of various solutions:

  • Richness of discovered data: Does the IPAM system capture attributes like device OS, switch port it is connected to, VLAN etc.
  • Ability to report and view data when needed: Can your IPAM solution generate reports like, all Windows devices running on VLAN 2 connected to switch 4? Can you see all your printers organized by building and the floor they are in? Answers to these types of questions are required when troubleshooting difficult problems.
  • Broad vendor support: This is an often overlooked aspect of discovery. Most IPAM vendors support discovery of Cisco equipment. However, networks contain infrastructure components from multiple networking vendors. Unsupported networking equipment will leave holes in your IPAM database. When making comparison make sure that a broad set of networking vendors’ switches and routers are supported.

2. Single pane of glass view of both physical and virtual infrastructure

Dynamic nature of virtualization and cloud computing environments can impact day to day IT tasks. Specifically, it is hard to track connectivity between virtual machines and the physical network infrastructure. A good IPAM solution is able to track the linkage between the virtual machines and physical infrastructure as they are created, moved and shutdown. Here are some of the actions you will be able to take if your IPAM system provides this information:

  1. Figure out what VMs (and corresponding applications) will be affected if a top of rack switch is brought down for updates
  2. Figure out if a VM is facing performance issues since it just migrated to an ESX server connected to a slower switch port.
  3. Trace network performance issues for a virtual desktop user all the way from the data center to the desktop.

3. Historical connectivity data and reporting

A good IPAM solution maintains historical connection data. This comes in handy when trying to investigate security and compliance issues. Specifically, IPAM system should be able to answer simple questions like, which device had this IP address yesterday? Which devices connected to the datacenter switch4 on the day of security breach? Where all a specific device has been connecting on my corporate network?

4. Visual appeal

A picture is worth a thousand words. This is more so evident when dealing with reports containing thousands of lines on information with devices and all their attributes. A good IPAM solution will provide highly graphical components to provide you insights into network usage, IP address distribution and state of IP addresses, location and connectivity between network infrastructure components etc. Visual elements speed up tasks and decisions.

5. Role based management

If you have an organization of people with varying levels of skill sets and responsibility, it is important that your IPAM system provide ability to assign roles accordingly. E.g. a helpdesk technician may have privileges to assign static IP addresses in a few specific subnets; a network admin in a branch office may have entire control over the subnets in the branch office; a troubleshooting engineer may only have read-only access to the IPAM connectivity data etc. This capability will go a long way in ensuring that a few expert level administrators are not the only ones dealing with these requests. Additionally, good auditing and rollback capabilities are required to ensure that configuration errors can be tracked and rolled back.

6. DNS/DHCP integrated

A good IPAM solution works closely with the underlying DNS and DHCP systems and receives updates as leases are handed out and DNS records are updated to ensure it has the most up to date information as new devices join the network, DNS records get changed and updated. In the absence of this capability, your IPAM system will not learn of any IP conflicts in your network e.g. someone connects to your network and assigns a static IP address to the device which in fact is part of a DHCP range and could potentially be leased to another device by the DHCP servers, thus causing an IP conflict and connectivity issue.

7. Customizability and integration

An IP address management system does not exist in a vacuum. Typically, IP address management related tasks are part of a larger system and hence IPAM is just part of a workflow. A competent IP address management system should provide easy integration with rest of the IT systems e.g. server provisioning systems, cloud provisioning systems, request tracking systems etc.

Written by Steve Garrison, Vice President of Marketing at Infoblox

Predicting RIPE’s depletion date

This week APNIC delegated their last IPv4 address the conventional way. The remaining pool of IPv4 addresses in the APNIC region will be delegated in small chunks of 1024 addresses. There is in other words nothing left other than breadcrumbs in this region.

In contradiction to my very exact estimate of the IANA depletion date, my tool and the mathematics I have been using failed to predict the APNIC depletion date with good accuracy. The algorithms that I have been using were not very good at predicting how an over 300% increase in demand over the last 2 months affected the depletion date. I would have been better off just using a linear algorithm with the last 2 months of demand as my input.

I must say that I was very surprised how quickly the APNIC pool got depleted. It appears that a “rush to the bank” happened once the members in the region realized that they might not get any additional IPv4 addresses. As the graph below indicates, the APNIC average burn rate went from slightly below 400,000 IPv4 addresses per day prior to the IANA exhaustion to almost 1.2 million IPv4 addresses per day after the IANA pool was depleted…

Read the rest on

Asia Pacific IPv4 Exhausted, Becomes First Region Unable to Meet IPv4 Demand

Asia Pacific Network Information Center (APNIC) today announced it has reached the last block of its available pool of IPv4 addresses. The day is marked as key turning point which initiates a major change in regional delegation policy. From today’s announcement [PDF]:

This event is a key turning point in IPv4 exhaustion for the Asia Pacific, as the remaining IPv4 space will be ‘rationed’ to network operators to be used as essential connectivity with next-generation IPv6 addresses. All new and existing APNIC Members who meet the current allocation criteria will be entitled to a maximum delegation of a /22 (1,024 addresses) of IPv4 space.

APNIC Director General Paul Wilson explained the Asia Pacific region is the first to reach the point of being unable to meet IPv4 demand. This is due to the unprecedented fixed and mobile network growth the region is experiencing.

“Considering the ongoing demand for IP addresses, this date effectively represents IPv4 exhaustion for many of the current operators in the Asia Pacific region,” Wilson said. “From this day onwards, IPv6 is mandatory for building new Internet networks and services.”

Migration to IPv6 still slow reports EURid

Despite widespread reports that IPv4 numbers are running out – and with parts of Asia expected to run out completely later this year – EURid, the eu top level domain registrar, is reporting that the take-up of IPv6 numbers, and the understanding of the security needed, is still relatively low.

Complete info at Info-Security.

Alternative to IPv6 in the Works

The global migration to IPv6 has been slow coming. Even as the last few remaining chunks of IPv4 address space are being allocated, many organizations around the world are just now beginning to look at IPv6. And what they’re finding often isn’t pretty: mediocre application support, security issues, and really long addresses that are hard to rattle off. It has been estimated that a significant move toward IPv6 won’t be seen for at least five years, and IPv6 won’t be on par with its predecessor for at least another ten.

This got some people within the IETF thinking about an alternative to the new protocol. Realizing that the primary goal of IPv6 was to provide an increased address space, they began to reconsider whether an entirely new protocol was really necessary in the first place. Still in its infancy, work is underway on a new IETF draft which ditches IPv6 altogether in favor of a simple extension to its predecessor: IPv4.1.

More on