Some people (Mary, that’s you) got quite a laugh about my comment that Microsoft had relied on networking vendors to provide NAT64/DNS64 support.  So I thought I’d expand on that, show why it didn’t seem like an unreasonable thing to do, and demonstrate the perils of relying on standards before they are fully baked.

Microsoft has been a strong and early proponent of IPv6 and indeed the DirectAccess technology is based on IPv6.  Of course there is a set of IPv4 to IPv6 transition technologies defined that allow DirectAccess to function in either a mixed or entirely IPv4 world.  When DirectAccess was being developed one such technology was NAT-PT.  NAT-PT had been implemented by Cisco (and perhaps others) quite some time before DirectAccess came to market.  In fact this Cisco documentation suggests support going as far back as 2002.  With NAT-PT available to most of its enterprise customers purely by configuring their existing network equipment, Microsoft chose not to provide its own NAT-PT implementation as part of Windows Server 2008 R2 (where DirectAccess was introduced).

Unfortunately it turned out that NAT-PT had serious flaws and a pair of new networking proposals was hatched to replace it, NAT64 and DNS64.  So when Microsoft launched DirectAccess you had NAT-PT in the market and work on NAT64/DNS64 specs nearing completion.  Very quickly a catch-22 developed.  Customers working on DirectAccess rollouts were told to use Cisco’s documented NAT-PT support, but when they talked to Cisco technical support they were told that was a very bad idea.  Although Cisco technically supported NAT-PT they had effectively deprecated it (and with no NAT64/DNS64 support in sight).  No customer was willing to go against Cisco’s advice, and no alternative was available from Microsoft.  DirectAccess deployment was blocked for nearly every customer scenario.  And that forced the UAG team to put in a crash effort to add NAT64/DNS64 support to UAG 2010 as I wrote about yesterday.

So Microsoft’s reliance on network vendors wasn’t blind faith, the key networking vendor already had the requisite technology in the market and available to the Microsoft customer base at the time the DirectAccess planning was done.  But as happens occasionally, things change.

This situation demonstrates the risks of relying on proposed, draft, and immature standards when doing actual implementations. Particularly in networking, which is inherently about having multiple implementations interoperating in real-time, until a standard is fully baked and tested with multiple implementations the risk of discovering fatal flaws is high.

This is why sometimes you may find a vendor, particularly a bigger one, slow on the trigger of implementing new “standards”.  Often the standard hasn’t actually finished the standardization process, and even if it has it may have dependencies on other incomplete standards or conditions that have yet to be met.  A company concerned about “getting it right” may choose not to be first and put their customers through unnecessary disruption later.  Twenty years ago that was always the right decision.  But since the advent of the Internet gave so many a “first mover advantage” it’s become much more debatable on if you should wait or just go ahead and implement something despite its incomplete and potentially seriously flawed nature.