One Year On: IPv4 Exhaust

Sun Sep 25 17:34:33 UTC 2016

On Sunday, September 25, 2016, Paul Thornton <paul at prt.org> wrote:

>
> On 25/09/2016 17:29, Ca By wrote:
>
> For your use case , would ipv6 solve anything?
>>
>> Think it is fair to say big content and big eyeballs have moved to IPv6
>> (notable exceptions exist)
>>
>> http://www.internetsociety.org/deploy360/blog/2016/08/facebo
>> ok-akamai-pass-major-milestone-over-50-ipv6-from-us-mobile-networks/
>>
>
> Yes of course.  Let's make the assumption that these people are happily v6
> enabled but need to support v4 for the foreseeable future.
>
> Take, for example, large hosting environments.  NAT isn't an option, nor
> is v6 only at this point.  For them, the only option to provide unique v4
> addresses for customers is to purchase it.
>
> We may be in luck, and the v6 tipping point happens before the transfer
> market runs out of reasonably-priced supply, and our hypothetical example
> above can default to v6 only.  If that happens, fantastic - but I'm not
> sure I'd bet on it, even given the improved v6 takeup in the past year or
> two.
>
> Paul.
>

I think how this will work out is that IPv4 becomes decoupled from hosting
/ cloud, and those IPv4 service have to be shared via L7 load balancing and
/ or CDN that has ipv4.

 Meaning hosts have ipv6 and need to subscribe to "ipv4 as a service "

I think the big networks are sharding based on ip protocol. Here is stack
for ipv4 (decling use), here is a stack for ipv6 (increasing use, over 50%
of all traffic in many cases today, especially mobile)

The idea of dual stack probably wont last long. The service is available as
dual stack, but the back end is real ipv6 and magic hack ipv4.

Just $0.02 on trajectory