On 27/02/2010 06:20, Kevin Oberman wrote:
I'm sorry, but some people are spending too much time denying history. IPv6 has been largely ready for YEARS. Less than five years ago a lot of engineers were declaring IPv6 dead and telling people that double and triple NAT was the way of the future. It's only been over the past two years that a clear majority of the networks seemed to agree that IPv6 was the way out of the mess. (I know some are still in denial.)
Certainly, ipv6 is as popular in some quarters as global warming at a GOP convention.
Let's face reality. We have met the enemy and he is us. (Apologies to Walt Kelly.) We, the network engineers simply kept ignoring IPv6 for years after it was available.
It's not just the engineers. The problem is completely systemic to our culture. We live in a world where the planning window is the next financial quarter. If something doesn't make money during that period, then most organisations won't bother doing anything with it. And while some bits of ipv6 have been "ready" for years (icmp ping, for example), lots of other things haven't. There is a huge feature disparity in most networking equipment that I use. I still can't monitor my ipv6 BGP sessions because bgp4-mib2 hasn't been standardised. When I try to configure my firewall using the point-n-drool GUI which most people will use, it displays a friendly dialog box saying that my ipv6 configuration commands have been ignored. How many enterprise network admins are going to bother configuring ipv6 if their only configuration interface doesn't support it? The RA vs DHCPv6 debacle lingers on (and anyone who tries to claim that this isn't a debacle is living in cuckoo land), making what was supposed to be the simplest, easiest part of ipv6 a configuration mess involving multiple protocols. But the root cause is that proper ipv6 deployment costs money, and while lots of us have ipv6 deployed in our core, that's probably the easiest and cheapest part of our organisations to deploy it. After that, there's still provisioning systems, support/troubleshooting, multiple protocol stack security issues, and so forth. This is where the real deployment costs time and resources. Nick