[menog] IPv4 March 2011 depletion

[Owen DeLong]

On Nov 15, 2010, at 2:17 AM, Brian Candler wrote:

> On Sun, Nov 14, 2010 at 03:30:57PM -0800, Owen DeLong wrote:
>>   What it really shows is that regardless of the transition technology in
>>   question, shortly after RIR
>>   runout, eye-ball providers are going to have customers with limited,
>>   degraded, or no access
> 
> ISPs are concerned about keeping their customers happy and paying their
> bills, and they will deploy whatever option achieves that. Options include:
> 
> (1) Customers can be given RFC1918 space behind a regular IPv4 NAT (the
> model which most mobile phone companies use today).
> 
> 98% of customers won't even notice. 1% will consider it to be a security
> benefit.  The remaining 1% will pay more for a premium product with a real
> IP address.
> 
I think your figures are rather optimistic, and, the ISP will still need public
addresses into which they can NAT those customers. Yes, this scales slightly
better than giving each customer a public IP, but, it also has its drawbacks
beyond just the customer satisfaction issues.

> (2) Even when all IP address space has been *allocated*, only a small
> portion of it will be *in use*.
> 
> ISPs will be able to buy additional IP address space from organisations not
> using it, at market rates.  The figure I've heard suggested is a one-off
> charge of $16 per IP address.  This is very cheap compared to the cost of a
> DSLAM or MSAN port, and can easily be absorbed for as long as it stays that
> low.
> 
I think there will be very little space available at $16/address. I hear figures ranging
from $40 to $100/address bandied about regularly. I also think that you
actually underestimate how much is actually in use. I think the most
optimistic projection I have heard is for the market to yield on the order
of 10 /8s, which at the current rate of internet consumption would mean
only a 5 month extension before the market no longer yields addresses
at any price.

> In my opinion, the business realities today are:
> 
> - no sane ISP will flip their *existing* customers over to an IPv6-only
> service (even with NAT64), or any service which requires the customer to
> replace their CPE or their PC.
> 
Sane ISPs will flip their existing customers to dual-stack. This will likely
require replacement of their CPE but not their PC in most cases.

> - if ISPs start selling IPv6-only services to *new* customers, and those
> customers find they won't work with their existing equipment, then they will
> immediately walk to a different ISP.  The customers won't understand the
> underlying technical issues; all they'll understand is that one ISP lets
> them connect to The Internet and another one doesn't.
> 
There will be a brief period where this may be the case. During this period,
the last ISP with available IPv4 space in a given service area will enjoy a
brief advantage. At some point, no ISP will have IPv4 space with which to
accept new customers under these terms.

> Rolling out V6 is therefore a business decision, not a technical one, and
> will be made by business managers.  If delaying V6 gives them an advantage
> in the marketplace, that's what they'll do.  It's a Poker game.
> 
Delaying IPv6 will not give you an advantage in the market place. The only
market advantages come from delaying your runout of IPv4. The less you
deploy IPv6, the less ability you have to manipulate that date.

>>   This is why many of us are saying that the most critical step today is
>>   to get as much of the
>>   public facing services and content on IPv6 as possible as soon as
>>   possible.
> 
> I disagree, because in the absence of a central Internet authority, it's
> unachievable.  There are a few big content providers but millions of small
> ones.  You're also assuming that these content providers will feel compelled
> to turn on V6 to avoid losing eyeballs, when in practice the eyeballs aren't
> moving.
> 
In reality, the eyeballs will move because their ISPs will eventually run out
of alternatives. No, this won't be in February, but, I expect it will likely start
before the end of 2011 and I will be surprised if residential IPv4 service
is available to new subscribers for anything approaching affordable pricing
by the middle of 2012.

The smarter content providers are turning on IPv6 to avoid losing eyeballs.
Eventually, some content providers (especially small ones that are growing)
and ones that don't exist yet will not be able to get IPv4 addresses for new
servers as well.

> Even those content providers who enable V6 are also going to make it
> available on V4 forever(*). Given that 100% of the content will be on V4,
> the critical step is therefore providing usable access to The (V4) Internet
> from V6 users.
> 
The critical step for eyeball service providers will be making the (v4) internet
available to their (v6) users. However, any mechanism for doing so will
cause a degraded user experience vs. content available on native IPv6.

As such, the critical step for content providers is to dual stack their content
and services as quickly as possible. Turns out, this is also helpful to the
eyeball service providers as well, since the more sites are available on
native IPv6 (i.e. dual stacked), the less load it places on their NAT64
or DS-LITE gear. If you are a content provider and are delaying your
IPv6 deployment until you start losing your customers, your competitors
are looking forward to the next couple of years.

As to available on v4 forever, for many web sites, this will not be possible
for even 5 years, let alone 10. Especially for new content sites that do
not exist before, say, September, 2011.

> I can see only one strategy which might work for V6 rollout: the ISP needs to
> provide access circuits with dual-stack RFC1918 NAT44 + V6 with NAT64 (**).
> 

If you are talking about doing this on a per customer basis, it
is absurd. If you have NAT44+IPv6, you don't need NAT64. If you have
IPv6 with NAT64, you don't need RFC-1918 or NAT44.

In fact, mixing the solutions as you describe breaks badly and would be
very harmful.

RFC1918 NAT44+v6 is commonly called DS-LITE.

If you're talking about providing DS-LITE to some customers and
native v6+NAT64 to others, then, that could be done, but, it makes
the administration of the network significantly more costly and
complicated while simultaneously reducing reliability and
scalability.

> This supports the following use cases:
> 1. existing CPE and workstations (V4 only)
Only for a very limited time.

> 2. new V6-only users, which is where you want the growth to be
Eventually, growth will be forced in this direction.

> 3. dual-stack endpoints
No, dual-stack endpoints do not need NAT64 or DS-LITE. They simply
work.
> 
> Note that if this happens, then for a very long time there will be a lot of
> 'accidental' dual-stack endpoints.  Unless you explicitly turn off V4, most
> devices will pick up both V4 and V6 addresses if that's what their network
> offers them.  Furthermore, manufacturers will continue to build devices that
> way for the foreseeable future.
> 
I don't see a problem with this.

> Hence it's critical that NAT64 be able to function alongside NAT44.
> 
Not really. Since a host receiving NAT64 services will never see an A
record returned from its DNS resolver (remember, the NAT64 DNS64
resolver will return AAAAs with mapped addresses for all A records
it receives), the presence of this RFC-1918 IPv4 address on the network
really won't have much effect.

Ideally, IPv4 should be turned off on a network using NAT64, but, it
is not absolutely necessary to do so and the presence of the IPv4
addresses (RFC1918 or otherwise) should be relatively safe to
ignore.


> Regards,
> 
> Brian.
> 
> (*) "Forever" in the context of The Internet is 10 years plus.
> 
> (**) And they will also offer a per-user setting to turn V6 off or on. This
> is because some existing equipment may crash when V6 is presented to it, and
> some users may wish to have under their own control when it is turned on,
> especially existing customers.

Do you have any specific examples of equipment that crashes when presented
with IPv6? I question this claim. Equipment which does not know about IPv6
should safely ignore it like any other unknown protocol.

Owen