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

["Kevin Oberman" <oberman () es net>]

> From: David Conrad <drc () virtualized org>
> Date: Thu, 13 Mar 2008 09:48:43 -0700
> Sender: owner-nanog () merit edu
>
>
> Jamie,
>
> On Mar 13, 2008, at 8:42 AM, Jamie Bowden wrote:
> > 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.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman () es net                       Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

Attachment: _bin
Description: