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