[arin-ppml] How hard is it to transition to IPv6?

Jeff Young young at jsyoung.net
Fri Mar 27 19:07:39 EDT 2009


I can see two ways this can go.  I could easily envision a world where
NAT proliferates and becomes the defacto for every connection to the
Internet.  For instance, although the solutions involve IPv6, many of  
the
solutions before the IETF that hope to make IPv4 and IPv6 compatible
are based on NAT.

IPv6 is by no means necessary, it may be the solution we prefer, the  
less
complicated solution, the long term solution but it is by no means
necessary.  v6 will happen if and only if the user community believes it
is the easiest way to go forward.  We've met the enemy and he is us.

We face a few undeniable truths:

- IPv4 allocations will run out in the next few years.
- ISP's will be immediately and adversely affected.  They will be  
forced to
  make their networks support both v6 and v4, some will resort to NAT
  on their edges...but allow native v6 to flow.  IPv6-only hosts will  
be a reality.
- Established large organizations, small organizations, and consumers  
will
  be less affected.

The other way this can go is IPv6.  Unfortunately IPv6 advocates have
been crying "transition" (i.e. "wolf") for so long that IPv6 has a  
developed
a negative stigma.  In the face of exhaustion, I think we need to  
separate
the problem into its pieces and be pragmatic.

ISP's can either embrace v6 or start a process of reclamation and  
renumbering.
That process will likely involve as many lawyers as network  
engineers.  I
favor v6 :-).  ISP's need to support v4 and v6 -- they'll only get  
large enough
allocations to grow via v6 in the future.  I wouldn't gamble the  
growth of my
business on reclamation and NAT.

For large enterprise, I've lobbied in favor of v6.  At present,  
however, I've
only lobbied that the F500 only upgrade their content delivery (e.g.  
outward-
facing services like web, VPN, DNS,  and so on) to dual stack.

By crying "transition" in the past, we've turned off the F500 crowd to  
v6.
Established F500 networks don't need to "transition,"  they need to  
make their
services available to the coming group of v6 only hosts.  I think this  
is what Google is
doing now, they're more content provider than ISP.  Large enterprises  
can transition
the rest of their networks later and the rest of their software later,  
if ever.  To
suggest that "Google says we can do it in 18 months" won't really fly  
in large
enterprise (outside Boeing, or Bechtel, or...).

On the consumer side, my impression is that we're ahead of the game.
much of the newest gear supports v6 (in fact, early experiments like  
Teredo in
Vista and v6 tunneling in Apple Airports supported it to a fault).   
The OS's
support it well enough.

My point is, first, ISPs don't have much of a choice.  Second, if we  
are going to
lobby anyone to transition, it should be content providers.  We should  
be
suggesting that they migrate to their outward-facing services to dual- 
stack.
We should be pointing out that Google is migrating because they are a  
content
provider, not an ISP.  Anything behind the outward-facing services can  
remain
IPv4 (indefinitely).

Third, on the consumer side we need to focus on ways that v6 happens  
without
consumer involvement.  If v6 is a success we'll just wake up one  
morning to find
that IPv6 traffic just begins to grow.  No one will have "accepted"  
it.  The DNS will
return v6 and v4 addresses to hosts that are dual stack, v6 will be  
preferred and if a
path exists the content will flow v6.

jy
On Mar 27, 2009, at 4:59 PM, <michael.dillon at bt.com> wrote:

>> Google has shown with the source code and programmers you can
>> fix the software in ~18 months.  That's good news, isn't it?
>> If we can all drive home the requirements to the vendors it
>> seems like there is plenty of time to get stuff fixed and
>> deployed before it is an issue.
>
> Bingo!
>
> People are wasting their breath complaining here. They should be  
> beating
> down their vendors doors to fix the IPv6 problem, and if it is  
> equipment
> bought within the last couple of years and the vendors down't have it
> high enough priority with delivery promised in the next 18 months,  
> then
> they should immediately take those vendors to court and sue for  
> damages.
> Get back all the money you paid, any costs of switching out the crap
> equipment for another brand that can (or will) handle IPv6, plus
> damages.
>
> Lots of companies have been negligent, both hardware/software vendors
> and network operators. Of course there is still enough time to recover
> from these mistakes if a company makes it a priority and sets some  
> firm
> internal targets, but if one of your suppliers is not willing to make
> firm promisies, then take them to court and tear them to shreds now
> before they go bankrupt. Fact is that when IPv6 takes off it will be a
> flurry of activity and a lot of that will be companies moving away  
> from
> suppliers who do not have enough IPv6 support. That will drive some
> companies into bankruptcy. That's just the way the economy works and  
> in
> my personal opinion it is better for the economy to drive those
> companies into bankruptcy sooner rather than later.
>
> The time has come for everyone to stop denial and admit that
> circumstances are forcing us to deploy IPv6 regardless of whether it  
> has
> the kind of business case that we prefer. If senior management is not
> past the denial stage and into the action stage then they are
> incompetent. Enough network operators have already moved into the  
> action
> stage as well as companies like Google. It is clear that IPv6  
> deployment
> is the way forward out of this addressing mess.
>
> --Michael Dillon
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>




More information about the ARIN-PPML mailing list