cost of dual-stack vs cost of v6-only [Re: IPv6 on SOHO routers?]

From: David Conrad <drc@virtualized.org>
Date: Thu, 13 Mar 2008 09:48:43 -0700
Sender: owner-nanog@merit.edu

Jamie,

> MS, Apple, Linux, *BSD are ALL dual stack out of the box currently.

The fact that the kernel may support IPv6 does not mean that IPv6 is
actually usable (as events at NANOG, APRICOT, and the IETF have
shown). There are lots of bits and pieces that are necessary for mere
mortals to actually use IPv6.

> The core is IPv6/dual stack capable, even if it's not enabled
> everywhere,

I'm told by some folks who run core networks for a living that while
the routers may sling IPv6 packets as fast or faster than IPv4, doing
so with ACLs, filter lists, statistics, monitoring, etc., is lacking.
What's worse, the vendors aren't spinning the ASICs (which I'm told
have a 2 to 3 year lead time from design to being shipped) necessary
to do everything core routers are expected to do for IPv6 yet.

> and a large chunk of Asia and Europe are running IPv6 right now.

I keep hearing this, but could you indicate what parts of Asia and
Europe are running IPv6 right now? I'm aware, for example, that NTT
is using IPv6 for their FLETS service, but that is an internal
transport service not connected to the Internet. I'm unaware (but
would be very interested in hearing about) any service in Asia or
Europe that is seeing significant IPv6 traffic.

> The US Govt. is under mandate to transition to v6 by the end of the
> year.

I thought parts of the USG were under a mandate to be "IPv6
capable" (whatever that means) by this summer. If there is a mandate
to be running IPv6 within the USG by the end of the year, people are
going to have to get very, very busy very, very quickly.

> The
> only bits that are missing right now are the routers and switches at
> the
> edge, and support from transit providers,

My understanding is that there are lots of bits and pieces that are
missing in the infrastructure, but that's almost irrelevant. What is
_really_ missing is content accessible over IPv6 as it results in the
chicken-or-egg problem: without content, few customers will request
IPv6. Without customer requests for IPv6, it's hard to make the
business case to deploy the infrastructure to support it. Without
infrastructure to support IPv6, it's hard to make the business case to
deploy content on top of IPv6.

> and if they're going to keep
> supplying the Fed with gear and connectivity, at least one major
> player
> in those areas of the NA market is going to HAVE to make it happen.

Remember GOSIP?

Oh, boy, do I remember GOSIP. Deja vu, in too many ways.

Just to clarify, the current mandates for US government IPv6
implementation is quite constrained.

1. For some time computer equipment/software had to be IPv6 capable. No
definition of 'capable' and the usual weasel words so that it's not
really hard to ge around, but it move IPv6 up the check-list quite a
ways.

2. The implementation mandate is restricted to government 'backbone'
networks. That really means that US Government network providers which
connect government facilities need to be capable of running IPv6. Not
end systems, LANS, or any networks within a single facility.

This means DREN, DISA, DOJ, DOI, DOE, etc. networks need to support
IPv6, but networks at a laboratory or military base don't and no end
systems or servers need to do IPv6. It is possible that an infrstructure
support service like DNS, at least for addresses in the external nets,
will need IPv6 support, but not facility servers.

It is likely (nearly certain) that the requirements for IPv6 will expand
to cover facility networks and end systems, but it is not clear that
they will actually require IPv6 user, just capability, though this is
also considered as likely.