[kbyers]

If your application doesn't work behind an IPv4 NAT box, then your application is broke already. It will likely be broke in IPv6 as well since firewalls are not going away (and many of the same protocols that break because of NAT also break with stateful firewalls).

[pyre]

I'm implying a legacy application that only works with IPv4 addresses, and doesn't work well behind a NAT. I know those are two separate issues, but the transition to IPv6 will likely require those software packages to be rewritten anyways so the idea that it will be broken even on IPv6 is moot because it won't even work on IPv6 as it currently is.

[kbyers]

So the application is broke with IPv4 and NAT, it is broke with IPv6 as it currently is, and somehow in the future it will be able to be re-written in IPv6 and made to work?

Most of the problems that I encounter with NAT and applications deal with protocols that have a control channel and then spawn separate streams frequently which are UDP. H323 is a perfect example. Both ends and the intermediate NAT devices have to understand how to handle the sub-channels.

This problem won't go away with IPv6 as firewalls will still need to understand the sub-flows. Additionally, we will be living in an IPv4 AND IPv6 world with NAT so not only will you likely have to go through an IPv4 NAT you also probably will have to go through a protocol tunneling device for some large set of users.

[count]

Those most likely are not running against the internet as a whole or at random, or they would be screwed already. VPNs and IPv4 networks that exist today won't disappear...

[pyre]

Why wouldn't they? The IPv4 addresses would either be behind some sort of NAT, or they would be IPv4 addresses in IPv6. If the apps can't handle IPv6, then they can't handle IPv4 addresses in IPv6, and they definitely won't be able to communicate with newer hosts that have IPv6 addresses outside of the range of IPv4.