[menog] IPv4 March 2011 depletion
ahmed at tamkien.com
Mon Nov 15 00:41:16 GMT 2010
I agree, March 2011 is likely the latest date. The are six /8s up for grabs and most likely ARIN, RIPE and APNIC will get two each sometime real soon ...
Once the "IPv4 is finished" news everywhere is out we will likely see Vint Cerf doing a lot of interviews on TV to explain what happened to IPv4 (remember his comment that IPv4 was an experiment that never ended ?) and how IPv6 can save the world.
With content providers, less than 0.2% of websites are IPv6 ready, which shows how late most are unless you're following Google, YouTube or Facebook who are v6 ready. Many PC/iPhone/Blackberry/etc. applications are also coded for IPv4 only as we know. This will take a few years to overcome, hence the need to run in a reliable dual-stack mode without consuming IPv4 public addresses by using tunneling techniques.
As for the slideshow, I guess it's easier to explain padding AAAA hex records with regular v4 addresses just to get the message across. Also, NAT64/DNS64 are still IETF drafts, so there is room to improve on them as you mentioned. But NAT64 needs to run on IPv6-only hosts (correct me if I am wrong) as that's its raison détre as well as how the draft standard defines the protocol.
It will be interesting to know how NAT64 clients can be distinguished from non-NAT64 clients in a local network, since a dual-stack client issuing an IPv6 header isn't much different (from the outside) from an IPv6-only client doing the same.
BTW you mention below " if your PC is dual stack and wants to receive literal A records, it should need NAT64" , did you mean "shouldn't need NAT64" ?
All the best,
From: Owen DeLong
Sent: Monday, November 15, 2010 1:30 AM
To: Ahmed Abu-Abed
Cc: 'menog at menog. net'
Subject: [Bulk] Re: [menog] IPv4 March 2011 depletion
On Nov 13, 2010, at 11:51 PM, Ahmed Abu-Abed wrote:
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:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Menog