U.S. military strong-arming IT industry on IPv6 | Hacker News Reader

U.S. military strong-arming IT industry on IPv6

networkworld.com

41 pointsm3mb3r22 comments

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...

Dan Bernstein outlines why it has been so difficult to transition to IPv6:

http://cr.yp.to/djbdns/ipv6mess.html

...and that appears to be from 2002! :(

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.

If the US military can save us from depleting IP addresses maybe they'll save us from running out of oil, too.

Damn... It seems to take a government agency to keep the world spinning.

Solar power humvees won't happen very soon.

But the US military is one of the World's largest oil consumers.

He's probably referring to DoD-funded research efforts like this: http://www.google.com/search?q=algae+oil+dod

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 :)

Oh well, at least I'm cooler than my friends :)

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.

To move a whole enterprise is hard.

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.

Hats off to a man who SSHs his own TV though an IPv6 connection.

Why would you want a naked routable TV sitting on the global network, instead of your firewalled LAN?

I do have a firewall in front of it. And running on the box itself.

Sounds like arm twisting, but does anyone have an alternative plan?

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 no reason it shouldn't be possible to have a packet with an ipv4 destination and an ipv6 source

This is now possible with NAT64, but it requires a translator box and somebody has to pay for that.

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.

They would have to replace the equipment anyway

...which kind of defeats the point of backward compatibility, doesn't it?

Um, Lisp was invented in 1958. What exactly was it supposed to be backwards-compatible with?

Reply on news.ycombinator.com