There is, of course, "support" and support when talking about any feature, whether ipv6 related or not.
Indeed. By that standard, there just is not the required support to run an IPv4 network using Cisco or Juniper equipment so we might as well all go home now.
There are piles more features which just aren't there if you use v6.
All the more reason to start using v6 seriously, in testing labs limited release testing with volunteer guinea pigs. IPv6 will not magically grow all the bells and whistles that 15 years of commercial Internet use has given to IPv4. We need to use it, find the problems and escalate them. And we need to do this *BEFORE* IPv4 runs out in two to three years or else a lot of heads will roll.
I seriously doubt that they would achieve feature parity, not to mind stability parity for these features.
Fortunately, we don't have to run faster than the bear, just faster than the other guy. And we don't have to solve all problems with IPv6, just the ones that we can because IPv4 will still be around. Ideally, we will all be able to adjust things so that we can continue growing the network using IPv6 while all the hardest stuff keeps running on IPv4.
I have talked to them about this, and their opinion is that there is no commercial demand for ipv6, and therefore ipv6 feature parity is on the feature roadmap.
I believe I said something about a gap in the market that some smart startup companies will fill. It's not just network operators who take a risk by burying their heads in the sand.
Open source solutions tend to fare better in this regard. Lots of people may end up using them in a future ipv6 world, but you're not going to end up seeing F500 companies stampeding to replace their current high-end solutions with m0n0wall installations, just because they have more-or-less parity support for ipv4 and ipv6.
No, but you will see startups leveraging the advanced state of open source software to create supported products that an F500 company would purchase. --Michael Dillon