[arin-ppml] The non-deployment of IPv6

[Stephen Sprunk]

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.

IMHO, that is where the ISP's responsibility ends when it comes to
corporate customers.  If the customers want to be stupid and not do
anything with it, that's their choice.  Of course, if the ISP had a
consulting practice, IPv6 readiness would be a great service offering,
but I wouldn't count on too many customers buying it.

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?

> Or is this purely a hardware-upgrade thing?
>   

Only the most obvious part is hardware; the network is a _tiny_ part of
an enterprise's problems.

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.

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
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.

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.

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.

> 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.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20091214/14a67664/attachment.bin>