<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.7600.16671"></HEAD>
<BODY
style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; WORD-WRAP: break-word; PADDING-TOP: 15px; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space"
id=MailContainerBody leftMargin=0 topMargin=0 CanvasTabStop="true"
name="Compose message area">
<DIV><FONT face=Calibri>Hi Owen,</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>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 ... </FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>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.</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>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.</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>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, </FONT><FONT face=Calibri>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. </FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>
<DIV><FONT face=Calibri>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.</FONT></DIV></FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>BTW you mention below "<FONT
face="Times New Roman"> if your PC is dual stack and wants to receive literal A
records, </FONT>it should need NAT64" , did you mean "shouldn't need
NAT64" ?</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>All the best,</FONT></DIV>
<DIV><FONT face=Calibri>-Ahmed</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri></FONT><FONT face=Calibri></FONT><FONT
face=Calibri></FONT><FONT face=Calibri></FONT><BR></DIV>
<DIV style="FONT: 10pt Tahoma">
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A title=owend@he.net
href="mailto:owend@he.net">Owen DeLong</A> </DIV>
<DIV><B>Sent:</B> Monday, November 15, 2010 1:30 AM</DIV>
<DIV><B>To:</B> <A
title="mailto:ahmed@tamkien.com CTRL + Click to follow link"
href="mailto:ahmed@tamkien.com">Ahmed Abu-Abed</A> </DIV>
<DIV><B>Cc:</B> <A
title="mailto:'menog@menog. net' CTRL + Click to follow link"
href="mailto:'menog@menog. net'">'menog@menog. net'</A> </DIV>
<DIV><B>Subject:</B> [Bulk] Re: [menog] IPv4 March 2011
depletion</DIV></DIV></DIV>
<DIV><FONT face=Calibri></FONT><FONT face=Calibri></FONT><BR></DIV><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 name="Compose message area" leftmargin="0" topmargin="0"
canvastabstop="true">
<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 name="Compose message area" leftmargin="0" topmargin="0"
canvastabstop="true">
<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><FONT face=Calibri></FONT><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 name="Compose message area" leftmargin="0" topmargin="0"
canvastabstop="true">
<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 style="WHITE-SPACE: pre" class=Apple-tab-span></SPAN>+<SPAN
style="WHITE-SPACE: pre" class=Apple-tab-span> </SPAN>Use different resolvers
for NAT64 and non-NAT64 clients.</DIV>
<DIV><SPAN style="WHITE-SPACE: pre" class=Apple-tab-span></SPAN>+<SPAN
style="WHITE-SPACE: pre" class=Apple-tab-span> </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>