[arin-ppml] The non-deployment of IPv6

[Owen DeLong]

On Dec 14, 2009, at 9:15 PM, Stephen Sprunk wrote:

> Steve Bertrand wrote:
>> I'm trying to envision the problem from your perspective. I'd like to
>> ask this:
>>
>> What, if anything, would your ISP be able to do to help you at least
>> begin the transition/implementation?
>>
>> Is there anything that an ISP could do differently other than just be
>> 'IPv6 enabled'?
>
> That is a necessary first step.  It's hard for an ISP to convince  
> their
> customers to enable IPv6 when most ISPs won't even sell them IPv6
> connectivity or, if they sell it, can't actually deliver it.
>
> After that?  Enable IPv6 on every customer circuit and assign every
> customer an IPv6 PA prefix, without waiting for them to ask for  
> one.  If
> they have a PI prefix in v4, send them directions on how to get one  
> in v6.
>
Bad idea... Notify them that the PA prefix is available for the  
asking: good.
Assign it whether they want it or not: bad.

The latter will simply lead to cruft in the database and other issues.
>
> A much more important step for ISPs is getting the _eyeballs_ on v6,
> whether native, 6to4, or Teredo.  There are hundreds of millions of  
> home
> and SOHO users out there that need no more than a CPE software  
> update to
> get on v6.  Realistically, how are you going to convince _anyone_ that
> they need to v6-enable their content when none of the eyeballs can do
> v6?  OTOH, how much convincing will you need to do when market stats
> show 90%+ of eyeballs have v6?
>
Because in 3 years, none of the new eyeballs will be able to do anything
but IPv6?  Getting the content providers dual-stacked is far more  
critical
than getting the eyeballs moved forward.  If the content is dual- 
stacked,
then, the eyeballs will follow fairly automatically in a few years,  
or, when
they start to care about content that is IPv6 only.  Either way,  
that's a
much easier problem (albeit larger in scope) to solve.
>
> As Chris pointed out, there's a lot of old OSes out there.  Win2k?
> Heck, I know places that are still running Win95/98/NT4, OS/2,  
> NetWare,
> etc.  Just getting all the OSes upgraded to something that can do IPv6
> will be a multi-year project in some places.
>
OTOH, do those hosts running 95/98/NT4 or OS/2, etc. actually matter  
about
getting dual-stacked?  Do they actually access the internet?  Chances
are not much or they wouldn't still be functional since there are  
relatively
well known and widely exploited holes available after end-of-life for
security updates in most cases.

> Next, after the OSes are up to date, you have to go through every  
> single
> software package used anywhere in the entire company (officially or
> not), checking whether or not it can handle v6--and what features
> silently stop working (a _serious_ problem).  This may mean an upgrade

Only if you're turning off IPv4.  In general, if the software can't  
handle IPv6,
it doesn't break just because you add IPv6 to the box. I suppose there's
a small chance that an application could be coded so badly that it  
somehow
does, but, it's hard to fathom how.

> to a newer version, with all the attendant testing, documentation,
> change management, training, etc.  Maybe the vendor has gone out of
> business, doesn't sell that product anymore, doesn't have a v6-capable
> version yet, or wants outrageous fees for the upgrade.  Maybe you have
> to find an entirely new product or rewrite some in-house custom app-- 
> if
> you even still have the source code for it.  Now repeat that several
> hundred (or thousand) times.
>
For getting the application to run on IPv6 in order to be able to turn  
off
IPv4, sure.  Outside of that, not so much.

> Consider that it took the better part of a decade for enterprises to
> switch from SNA, IPX, AppleTalk, Vines, XNS, DECnet, etc. to IPv4--and
> all they had running on their networks back then were file and print
> sharing and some dumb terminal emulators.  The problem is orders of
> magnitude worse now.
>
Yes and no.

> Realistically, the only way the "transition" is going to happen is to
> convince them to buy new firewalls that can do NAT64 and let them
> continue on in their RFC1918-isolated bliss.  And, really, as long as
> their v4-only internal and DMZ hosts can talk to the v6 Internet
> somehow, isn't that good enough for now?  You do not need to look  
> behind
> the curtain, Dorothy.
>
There's two different transitions being discussed here, and, we need  
to be
more accurate about how we talk about them.  I think much of the  
enterprise
resistance stems from the misuse of the words transition or migration to
describe the first step.  The first step is dual-stacking.  Dual- 
stacking should
be relatively painless and should not require a great deal of  
application
testing, etc. Yes, removal of IPv4 will be painful and take time.  The  
good
news is that the first test cases for that will be new hosts after IPv4
addresses are no longer available with the possibility of using IPv4
NAT as a fallback to back-stop that issue initially while the native
IPv6 issues are resolved.  Once the IPv6-only new hosts are working
fine without needing IPv4, then, we can look at removing IPv4 from
the remaining dual-stack hosts and finally the network infrastructure.

So, let's focus on getting existing services dual-stacked, then worry  
about
the next steps.

>> I'm thinking purely from the perspective of having IPv6 ROUTING
>> available. The desktop/server is not what I'm concerned about at this
>> point. I just want to know what can be done differently so that the
>> backbone of the enterprise can communicate via v6, and when the PCs  
>> are
>> upgraded, they have a network ready to talk on.
>>
>
> Solving the easiest part of the problem and calling it a day doesn't  
> do
> much good.
>
Yes and no.  Solving that part of the problem does a lot of good.   
Calling
it a day when you get to that point, however, is problematic.  It's a  
good
and necessary first step.

The equally necessary next step is to get existing services dual- 
stacked.

Dual-stacking desktops can come MUCH later and be done on a much
more piecemeal basis. So, the good news is that the hardest part of the
problem is easily left for last and can be done in small bites over a  
much
longer time horizon.


Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20091215/b3ba23ff/attachment.htm>