<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 13, 2010, at 11:51 PM, Ahmed Abu-Abed wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px" id="MailContainerBody" leftmargin="0" topmargin="0" canvastabstop="true" name="Compose message area">
<div><font face="Calibri">Hello everyone,</font></div>
<div><font face="Calibri"></font> </div>
<div><font face="Calibri">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. </font></div>
<div><font face="Calibri"></font> </div>
<div><font face="Calibri">See counter on <a title="http://www.ipv6forum.org/
CTRL + Click to follow link" href="http://www.ipv6forum.org/">http://www.ipv6forum.org/</a></font></div>
<div><font face="Calibri"></font> </div></div></blockquote>FWIW, I think it will actually be sooner. I will be surprised if we make it past February and will</div><div>not be at all surprised if we do not make it to 2011.</div><div><blockquote type="cite"><div style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px" id="MailContainerBody" leftmargin="0" topmargin="0" canvastabstop="true" name="Compose message area"><div><font face="Calibri"><br></font></div><div><font face="Calibri">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:</font></div>
<div><font face="Calibri"><a title="http://www.slideshare.net/IOSHints/nat64-and-dns64-in-30-minutes
CTRL + Click to follow link" href="http://www.slideshare.net/IOSHints/nat64-and-dns64-in-30-minutes">http://www.slideshare.net/IOSHints/nat64-and-dns64-in-30-minutes</a></font></div>
<div><font face="Calibri"></font> </div>
<div></div></div></blockquote>This is a reasonably good slide show, but, it does have some issues.</div><div><br></div><div>What it really shows is that regardless of the transition technology in question, shortly after RIR</div><div>runout, eye-ball providers are going to have customers with limited, degraded, or no access</div><div>to the IPv4 internet.</div><div><br></div><div>This is why many of us are saying that the most critical step today is to get as much of the</div><div>public facing services and content on IPv6 as possible as soon as possible. Content</div><div>and services which are available on IPv6 bypass the problems associated with both of</div><div>these solutions to provide a better user experience.</div><div><br></div><div>Please note that IPv6 AAAA records do not contain embedded IPv4 addresses like depicted</div><div>in most of these slides even in the transitional technologies. The address would always be</div><div>displayed as a group of hex digits except for IPv4 mapped addresses which should never</div><div>appear in packet headers or AAAA records (::ffff:192.0.2.133). If you fold 192.0.2.133 into</div><div>the IPv6 network 2001:db8:50d8:f3ef::/64, for example, it would come out not as</div><div>2001:db8:50d8:f3ef::192.0.2.133, but, as 2001:db8:50d8:f3ef::c000:285.</div><div><blockquote type="cite"><div style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px" id="MailContainerBody" leftmargin="0" topmargin="0" canvastabstop="true" name="Compose message area"><div><font face="Calibri">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 <em>not</em> on dual-stack, i.e. an
IPv6-only host, which is a challenge. NAT64 also needs reworking the DNS
infrastructure.</font></div>
<div><font face="Calibri"></font></div></div></blockquote><div><br></div>This is not necessarily true, but, if your PC is dual stack and wants to receive literal A records,</div><div>it should need NAT64 and shouldn't be talking to a NAT64 nameserver.</div><div><br></div><div>It is true that if you are running a NAT64 resolver, the resolver will not respond with legitimate</div><div>A records for IPv4-only hosts and will instead provide mapped AAAA records.</div><div><br></div><div>This is pretty trivial to work around using one of two techniques:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>+<span class="Apple-tab-span" style="white-space:pre"> </span>Use different resolvers for NAT64 and non-NAT64 clients.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>+<span class="Apple-tab-span" style="white-space:pre"> </span>Provide different views for NAT64 vs. non-NAT64 clients.</div><div><br></div><div>Partial NAT64 implementations (hosts that are dual stack for a subset of the IPv4 internet</div><div>but don't have global IPv4 connectivity) are a different problem. This configuration should</div><div>generally be avoided anyway.</div><div><br></div><div>Owen</div><div><br></div></body></html>