IPv6 is such a mess that the DoD needs to ensure that when IPv6 is claimed as "supported" by a vendor, that it actually does work. There are plenty of bugs, corner cases, and limitations in what vendors are offering.
This "strong-arming" is not that much different than asking a new car salesman why he is selling GM while personally driving an Audi.
Actually, the IPv6 stacks I've been seeing from Cisco are starting to look pretty good. The protocol, itself, shouldn't cause much in the way of concern for most network engineers. I'm interested to hear if the problems (which were myriad, and painful early on) you ran into in the last 10 years are still present in the more recent stacks from your vendor?
Speaking as a Network Engineer - I actually quite like IPv6. It took about 3+ years for my eyes (and brain) to get used to seeing 128 bit addresses, and remembering them, but I'm pretty good now. I think that's what the article is saying, too - the DoD wants people to start getting used to the protocol so that it doesn't take a crack team to deploy the protocol. As one who interviews network engineers frequently, I have yet to run into more than half a dozen out of 100 (and that's being generous) who could speak coherently about IPv6, and have never run into one who knew something as simple as what a solicited nodes multicast address was (basically the address you use for the IPv6 equivalent of ARP).
So - the technology is getting there, now we need to get the network engineers moving along...
Like Walmart and barcodes, maybe this is the final push that's needed. As for strong-arming, I'd say they have every right to demand suppliers who eat their own dog food. They've got a lot at stake.
Just the other day I was pleasantly surprised to notice my MacBook using IPv6 to stream a song over to my Apple TV (remote speakers). For grins I disabled v6 on the interface to see what would happen. The stream cut out briefly and then resumed over IPv4.
Nice. I am pleased to say that even my TV has a globally-routable IPv6 address. (Unfortunately, I've never actually had physical IPv6 connectivity anywhere, so I always have to VPN to my internal IPv4 network. I have SSH'd from my server with IPv6 connectivity, though, and it worked :)
A globally routable v6 network isn't too hard to do at home with tunnelbroker.net and similar services. A Dlink DIR-825 has enough v6 support to hold up it's end of the tunnel and route a /64. Clients (Mac, Windows, Unix's) 'just work'. Tunnelbroker does the hard part.
Moving a whole enterprise turns out to be remarkably simple. Most OS stacks from the last 5+ years have support for IPv6 - even windows XP allows a pretty straightforward upgrade. Enable the client stacks, Turn it on on your routers, and voila - your enterprise is now IPv6 enabled. Add it to your SSL VPN - IPv6 from home. The Dual-Stack capability really does make it bog simple.
Fix the spec there is no reason it shouldn't be possible to have a package with an ipv4 destination and an ipv6 source (all oses knows about ipv6) except that those who wrote the specs forgot the iron law of software - nothing, no matter how good it is - succeed without being backwards compatible. That's why c++ and Java are a success, but Lisp isn't.
There is one problem. The IPv6-enabled equipment that provides Internet access to the IPv6 sender knows how to route an IPv4 address, but the IPv4 equipment at the recipient's ISP might not know how to route back to the IPv6 source.
This "strong-arming" is not that much different than asking a new car salesman why he is selling GM while personally driving an Audi.