[menog] IPv4 March 2011 depletion

[Owen DeLong]

On Nov 13, 2010, at 11:51 PM, Ahmed Abu-Abed wrote:

> Hello everyone,
>  
> The new IPv4 depletion date, at the IANA level, is now March 2011, and only 11 blocks of /8 are left. A few months ago it was predicted as July 2011, but the exponential demand keeps bringing the date forward.
>  
> See counter on http://www.ipv6forum.org/
>  
FWIW, I think it will actually be sooner. I will be surprised if we make it past February and will
not be at all surprised if we do not make it to 2011.
> 
> There is a good presentation on how to deal with IPv6 access AND IPv4 coexistence for ISPs after IPv4-depletion, and it shows that DS-Lite and NAT64 are the only practical options:
> http://www.slideshare.net/IOSHints/nat64-and-dns64-in-30-minutes
>  
This is a reasonably good slide show, but, it does have some issues.

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
to the IPv4 internet.

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. Content
and services which are available on IPv6 bypass the problems associated with both of
these solutions to provide a better user experience.

Please note that IPv6 AAAA records do not contain embedded IPv4 addresses like depicted
in most of these slides even in the transitional technologies. The address would always be
displayed as a group of hex digits except for IPv4 mapped addresses which should never
appear in packet headers or AAAA records (::ffff:192.0.2.133). If you fold 192.0.2.133 into
the IPv6 network 2001:db8:50d8:f3ef::/64, for example, it would come out not as
2001:db8:50d8:f3ef::192.0.2.133, but, as 2001:db8:50d8:f3ef::c000:285.
> DS-Lite client needs to be implemented as a protocol on the CPE. NAT64 has a big catch in that it assumes your PC (or smart mobile host for that matter) is not on dual-stack, i.e. an IPv6-only host, which is a challenge. NAT64 also needs reworking the DNS infrastructure.

This is not necessarily true, but, if your PC is dual stack and wants to receive literal A records,
it should need NAT64 and shouldn't be talking to a NAT64 nameserver.

It is true that if you are running a NAT64 resolver, the resolver will not respond with legitimate
A records for IPv4-only hosts and will instead provide mapped AAAA records.

This is pretty trivial to work around using one of two techniques:

	+	Use different resolvers for NAT64 and non-NAT64 clients.
	+	Provide different views for NAT64 vs. non-NAT64 clients.

Partial NAT64 implementations (hosts that are dual stack for a subset of the IPv4 internet
but don't have global IPv4 connectivity) are a different problem. This configuration should
generally be avoided anyway.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20101114/94859486/attachment.html