In an IPv6 future, how will you solve IPv4 connectivity?

Cameron Byrne cb.list6 at gmail.com
Mon Oct 11 18:57:09 CEST 2010


On Sun, Oct 10, 2010 at 10:15 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
> Hi Roger,
>
>  What amazes me is that practically nobody has answered your question.
>  Every answer so far has been of the "well, you can do this to fix that" but
> they aren't saying what THEY are doing.  Your question wasn't what could I
> do, but what were YOU planning on doing.
>
>  Since practically nobody said "this is what we are going to do" I can only
> conclude that there's a lot of ostriches with heads in the sand and
> that none of the respondents have done any actual IP planning for
> the future.
>


Not an ostrich here, http://groups.google.com/group/tmoipv6beta.
IPv6-only + NAT64 is alive.


>  Anyway, this is what -we- are going to do.
>
>  First of all we will be strongly advertising that we have native
> IPv6 connectivity to our users, particularly during runout, as
> it is likely that there will be news articles and such on this and
> we will take advantage of that.
>
>  When we get near the end of our assignable IPv4 we are going to
> start offering the following end user products:
>
> 1) Public IPv4 only
>
> 2) dual stack public IPv4/IPv6
>
> 3) Private (natted) IPv4 only
>
> 4) Dual stack public IPv6 / private (natted) IPv4
>
>
> #1 will be 5% higher than rack rate.  #2 will be 4% higher
> than rack rate. #3 1%-2% higher than rack rate  #4 will be
> rack rate.
>
> We will then start moving customers into those buckets in small
> groups.  Very likely the first thing to go out will be a flyer
> advertising that we are having to increase prices but we have a
> new program that will allow them to get out of the price raise.
>
> Depending on how this plays out and how customers react we will be adjusting
> those percentages.
>
> Ultimately as time continues to pass we will be CLOSELY observing what
> the competition is doing.  When we see the competition start to charge
> premiums for public IPv4 then we will start jacking up our percentages
> and trying to force more and more people out of the public IPv4.  This
> is the part that worries me, because it is hard to know how much IPv4
> that everyone has in reserve and what their burn rate is.
>
> I really see very little point in fielding a proxy server that will
> allow a IPv6-only customer to surf the IPv4 Internet - if they can
> do IPv6 then they can dual-stack.  I may do this though if we have
> early adopters that demand IPv6 only.
>

I don't believe this is a true statement.  Simply having the ability
to configure an IPv4 address on your system does not mean that you
have an IPv4 address to use.  The point of IPv6-only is that IPv4 is
exhausted.  Given that dual-stack has not seamlessly transitioned us
to IPv6 as it was envisioned 10 years ago, demand for IPv4 will soon
exceed supply. Hence, IPv6-only solutions.

> I also see little point in fielding a proxy that allows IPv4-only to
> surf the IPv6 Internet.  Fielding a proxy like this costs us money
> and it's a given that the major content providers will be dual stacked
> for many years yet.

My customers, cell phone consumers, are generally not interested in
IPv4 or IPv6 or Dual-stack.   They just want it to work.  If I do not
have the IPv4 addresses (public, private, bogon), the service will not
work.

I believe there are 2 separate problems one is in the access network
and one is in the content network.

If the access network is growing (anything mobile, devices in the home
like DVR ...), they need to move to IPv6 as soon as possible since
IPv4 is not growing.  It is a simple business continuity story.  If
the access network is not growing, the business case is less urgent,
but a good idea.

For content providers, they NEED to be dual stack to reach all their
possible eyeballs.  Once again, it is a simple business continuity
story.  Without dual-stack (from a service perspective), you will not
have the best method of reaching all your customers.

Cameron



More information about the ipv6-ops mailing list