<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>my web 0.2 website &#187; ipv6</title>
	<atom:link href="http://www.andyd.net/category/ipv6/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.andyd.net</link>
	<description>Andy Davidson\&#039;s tech blog</description>
	<lastBuildDate>Wed, 08 Jun 2011 14:10:34 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
		<item>
		<title>Happy World IPv6 Day</title>
		<link>http://www.andyd.net/2011/happy-world-ipv6-day/</link>
		<comments>http://www.andyd.net/2011/happy-world-ipv6-day/#comments</comments>
		<pubDate>Wed, 08 Jun 2011 11:07:32 +0000</pubDate>
		<dc:creator>andy</dc:creator>
				<category><![CDATA[ipv6]]></category>

		<guid isPermaLink="false">http://www.andyd.net/?p=293</guid>
		<description><![CDATA[<p>www.andyd.net is now IPv6 enabled!  To coincide with the Internet Society&#8217;s &#8220;<a href="http://www.worldipv6day.org" onclick="javascript:urchinTracker ('/outbound/article/www.worldipv6day.org');">World IPv6 Day</a>&#8220;, this website has IPv6 as well as IPv4 connectivity.</p>
<p>However, unlike many of the participants, I will be leaving the v6 support on after midnight.  Other participants, including Facebook, Google, Yahoo, Microsoft, and scores more who have turned on IPv6 support today, are expected to disable it again at midnight tonight, and then paw through the pages of statistics they have collected during the course of the day.  It is hoped that the statistics will prove IPv6 is safe, and the experiment can be repeated &#8211; perhaps with permanent adoption next time.</p>
<p>IPv6 is essential to the growth of the internet.  The old method of assigning addresses &#8211; IPv4 &#8211; permitted for up to around four billion hosts on the internet.  This is not enough to assign an IP address to everyone who wants to use the internet, so a larger address pool (known as IPv6) was created.  To maximise the audience for your website, it is important to today serve the site via IPv4 <em>and</em> IPv6.  Many web hosts have enabled IPv6 today, ask yours for their IPv6 status.  If they have not enabled IPv6, explain that you will move your business if they do not enable IPv6.</p>
<p>I work for Hurricane Electric, the world&#8217;s largest IPv6 backbone, with over 1,500 connections to other IPv6 networks.  We offer IPv6 hosting, and connectivity to many thousands of IPv4 and IPv6 networks.  We also offer IPv6 consultancy and professional services &#8211; so if you are looking for training, advice, or some hands on help completing your IPv6 migration, then <a href="http://www.andyd.net/contact/" >why not get in touch</a> with me?  If you are looking for a free method to get some v6 consultancy for your office or lab, then consider our <a href="http://www.tunnelbroker.net/" onclick="javascript:urchinTracker ('/outbound/article/www.tunnelbroker.net');">Tunnelbroker</a> service, which lets you tunnel IPv6 over your existing IPv4 connection.</p>
<p></p>
<p></p>
]]></description>
		<wfw:commentRss>http://www.andyd.net/2011/happy-world-ipv6-day/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>IP Drought begins today in Asia-Pacific</title>
		<link>http://www.andyd.net/2011/ip-drought-begins-today-in-asia-pacific/</link>
		<comments>http://www.andyd.net/2011/ip-drought-begins-today-in-asia-pacific/#comments</comments>
		<pubDate>Thu, 14 Apr 2011 09:52:09 +0000</pubDate>
		<dc:creator>andy</dc:creator>
				<category><![CDATA[Sys Admin]]></category>
		<category><![CDATA[The 'net]]></category>
		<category><![CDATA[bgp]]></category>
		<category><![CDATA[ecommerce]]></category>
		<category><![CDATA[ipv6]]></category>

		<guid isPermaLink="false">http://www.andyd.net/?p=287</guid>
		<description><![CDATA[<p>That&#8217;s it &#8211; the Asia Pacific region is the first to run out of IPv4 addresses.</p>
<p>This happened following an <a href="http://mailman.nanog.org/pipermail/nanog/2011-April/035233.html" onclick="javascript:urchinTracker ('/outbound/article/mailman.nanog.org');">assignment</a> of around half a million addresses to support the users at the Chinanet Fujian Province Network.</p>
<p>The pool of available addresses to the region including some of the world&#8217;s largest populations, such as China, India, Indonesia, and some of the world&#8217;s largest economies, such as Japan and Australia, has depleted to such low levels, that the registry responsible for distribution of these addresses will now ration them, such that any ISP requesting space will be given a single block of 1,024 addresses, on a single occasion only.</p>
<p>This is enough space to allow the ISP only to host NAT or ipv4 to ipv6 translation technologies.  It is not enough to address a large content infrastructure, hosting environment, or internet access customer-base.</p>
<p>The rules of the game have today changed for 50% of the world&#8217;s population, and they will change in Europe too in a few short months too.  If you do not have an IPv6 plan, then this is your new significant business risk &#8211; how will users with v6 only connections reach your content?  And if this is through a translation mechanism, how will you ensure quality, or that your end-to-end protocols (like voice, video, etc.) will work ?</p>
<p>Get in touch to continue the conversation!</p>
<p></p>
<p></p>
]]></description>
		<wfw:commentRss>http://www.andyd.net/2011/ip-drought-begins-today-in-asia-pacific/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Can you fill all of the Great Lakes with M&amp;M sized /64s?</title>
		<link>http://www.andyd.net/2010/can-you-fill-great-lakes-with-mm-sized-64s/</link>
		<comments>http://www.andyd.net/2010/can-you-fill-great-lakes-with-mm-sized-64s/#comments</comments>
		<pubDate>Tue, 26 Jan 2010 19:23:24 +0000</pubDate>
		<dc:creator>andy</dc:creator>
				<category><![CDATA[Sys Admin]]></category>
		<category><![CDATA[ipv6]]></category>
		<category><![CDATA[networking]]></category>

		<guid isPermaLink="false">http://www.andyd.net/?p=180</guid>
		<description><![CDATA[<p>Posted to my blog at the request of <a href="http://www.lentil.org/" onclick="javascript:urchinTracker ('/outbound/article/www.lentil.org');">RobL </a>!</p>
<p>On Nanog, <a href="http://www.delong.com/" onclick="javascript:urchinTracker ('/outbound/article/www.delong.com');">Owen DeLong </a>and Larry Sheldon were discussing the relative size of the IPv6 address space:</p>
<pre>&gt;&gt; 64 bits is enough networks that if each network was an almond M&amp;M,
&gt;&gt; you would be able to fill all of the great lakes with M&amp;Ms before you
&gt;&gt; ran out of /64s.
&gt; Did somebody once say something like that about Class C addresses?
</pre>
<p>Well, this seemed like a challenge for <em><u>Maths</u></em>, and the answer is:</p>
<p>No.  There are only 2,097,152 Class C networks.</p>
<p>Assuming all M&amp;Ms are spheroids of uniform oblate nature, radius major axis=6mm, minor axis=3mm.  <a href="http://en.wikipedia.org/wiki/Spheroid#Volume" onclick="javascript:urchinTracker ('/outbound/article/en.wikipedia.org');">Volume is (4/3)Pi (Major<sup>2</sup>) Minor</a></p>
<p>They will be poured into a great lake of your choice, and we will assume random close packing (agitation mechanisms are probably best discussed off-list) and <a href="http://en.wikipedia.org/wiki/Random_close_pack" onclick="javascript:urchinTracker ('/outbound/article/en.wikipedia.org');">a (generous, but this Wikipedia article insists) void fraction of 32%.</a></p>
<p>Volume of m&amp;m = 0.452cm<sup>3</sup>, occupies 0.665cm<sup>3</sup>.</p>
<p>Lake Erie is 484km<sup>3</sup> &#8211; See: <a href="http://www.epa.gov/glnpo/factsheet.html" onclick="javascript:urchinTracker ('/outbound/article/www.epa.gov');">http://www.epa.gov/glnpo/factsheet.html</a></p>
<p>1 km<sup>3</sup> = 1,000,000,000,000,000 cm<sup>3</sup></p>
<p>484,000,000,000,000,000 * 0.665 = 321,860,000,000,000,000 m&amp;ms needed to<br />
fill this lake.</p>
<p>There are 4,294,967,296 /64s in my own /32 allocation.  If we only ever use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952 /64s.  This is enough to fill over seven Lake Eries.  The total amount<br />
of ipv6 address space is exponentially larger still &#8211; I have just looked at 2000::/3 in these maths.</p>
<p>THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG.</p>
<p><strong> Can we please now just go ahead and roll out some ipv6 services? <strong></strong></strong></p>
<p></p>
<p></p>
]]></description>
		<wfw:commentRss>http://www.andyd.net/2010/can-you-fill-great-lakes-with-mm-sized-64s/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>2010 will be a bad year for ipv4</title>
		<link>http://www.andyd.net/2010/2010-will-be-a-bad-year-for-ipv4/</link>
		<comments>http://www.andyd.net/2010/2010-will-be-a-bad-year-for-ipv4/#comments</comments>
		<pubDate>Mon, 25 Jan 2010 20:08:28 +0000</pubDate>
		<dc:creator>andy</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[Sys Admin]]></category>
		<category><![CDATA[The 'net]]></category>
		<category><![CDATA[ecommerce]]></category>
		<category><![CDATA[ipv6]]></category>
		<category><![CDATA[networking]]></category>
		<category><![CDATA[telecoms]]></category>

		<guid isPermaLink="false">http://www.andyd.net/?p=178</guid>
		<description><![CDATA[<p>We are now at the end of January, but IPv4, the Internet&#8217;s core addressing protocol still has a nasty hangover, and all signs are pointing to 2010 being a bad year for the protocol.</p>
<p>Since January 1st, a few key milestones have passed, indicating how urgent the IPv4 rundown problem has become. Firms that rely on internet connectivity must take urgent action in light of the events:</p>
<ul>
<li>The allocation last week of two further /8s (blocks of IPv4 addresses with the same number before the first dot) to APNIC mean that for the first time, less than <a href="http://www.nro.net/media/less-than-10-percent-ipv4-addresses-remain-unallocated.html" onclick="javascript:urchinTracker ('/outbound/article/www.nro.net');">just ten percent of the IPv4 unallocated pool is available </a>to be assigned.  At current utilisation rates, this pool will be exhausted in only 600 days.  Of course, the internet could stop growing, but all signs point away from this&#8230;</li>
<li>The allocation of 1.0.0.0/8 is the assignment of the first really &#8216;dirty&#8217; block of addresses, signalling that we really are in the run-down period.  Bad network design decisions in the past have meant that networks have &#8216;borrowed&#8217; the use of addresses starting 1. for &#8216;internal use only&#8217; or special applications on their network.  This means that organisations assigned address space starting &#8217;1&#8242; may well have partial connectivity even though they are rightfully assigned the space.  Examples are the <a href="http://www.zapzone.com.my/faq.php#u7" onclick="javascript:urchinTracker ('/outbound/article/www.zapzone.com.my');">braindead hotspot operators who take addresses like 1.1.1.1 </a>to trigger hotspot logout, but a handful of examples appear across this address range.</li>
<li>RIPE NCC, the organisation who assign addresses to networks in and around Europe have this month implemented their &#8216;run down&#8217; policy which will mean that organisations requesting space will only be able to cater for their <a href="http://www.ripe.net/ripe/policies/proposals/2009-03.html" onclick="javascript:urchinTracker ('/outbound/article/www.ripe.net');">growth requirements for a very short amount of time</a>.  This is to evenly spread the inevitable misery across the ISP community.</li>
</ul>
<p>RIPE members should thoroughly audit their address space so that they can ensure that their records are accurate, because RIPE are more likely to ensure that address space is assigned to your end users in line with the community&#8217;s policies.  ISPs and services providers who need help can contact me for further information or specific assistance.</p>
<p>Organisations who rely on internet connectivity for their products should ensure their providers have an IPv6 migration plan in place.  Otherwise end-to-end connectivity for your home or office is unlikely to be something you can enjoy looking beyond the runout period.  Companies hosting network services, for example a website, should enquire what their host&#8217;s IPv6 plans are, and start to enable their services via v6.</p>
<p>There is real traction to ensure v6 support appears in both the hardware and services you need to connect to the internet.  It is easier today than before to find help making your services available via v6.  The alternatives &#8211; patchy connectivity via nested stacks of ipv4 islands, or no more end-to-end connectivity (so that your internet service is a walled garden), have much worse consequencies than learning to roll v6.</p>
<p>Engineers know the facts by now and have no excuse.  For more information, see the RIPE NCC&#8217;s information site, <a href="http://www.ipv6actnow.org/" onclick="javascript:urchinTracker ('/outbound/article/www.ipv6actnow.org');">ipv6actnow</a>.</p>
<p></p>
<p></p>
]]></description>
		<wfw:commentRss>http://www.andyd.net/2010/2010-will-be-a-bad-year-for-ipv4/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>IPv6 Track at NANOG</title>
		<link>http://www.andyd.net/2009/ipv6-track-at-nanog/</link>
		<comments>http://www.andyd.net/2009/ipv6-track-at-nanog/#comments</comments>
		<pubDate>Mon, 15 Jun 2009 16:16:45 +0000</pubDate>
		<dc:creator>andy</dc:creator>
				<category><![CDATA[The 'net]]></category>
		<category><![CDATA[bgp]]></category>
		<category><![CDATA[ecommerce]]></category>
		<category><![CDATA[ipv6]]></category>
		<category><![CDATA[networking]]></category>
		<category><![CDATA[peering]]></category>
		<category><![CDATA[telecoms]]></category>

		<guid isPermaLink="false">http://www.andyd.net/?p=154</guid>
		<description><![CDATA[<p>Greetings from Philadelphia!  I am <a href="http://www.nanog.org/streaming.php" onclick="javascript:urchinTracker ('/outbound/article/www.nanog.org');">presenting as part of the IPv6 at NANOG46 (click here for info of how to watch)</a> at 9:30PM UK time today, or <a href="http://www.andyd.net/media/talks/v6-enterprise-black.pdf" >download the IPv6 for Enterprises presentation here</a>, or <a href="http://www.nanog.org/meetings/nanog46/abstracts.php?pt=MTM3NCZuYW5vZzQ2&amp;nm=nanog46" onclick="javascript:urchinTracker ('/outbound/article/www.nanog.org');">see information about the other speakers here</a>..</p>
<p>The messages are clear and simple.  Working now to get ready for the IPv6 transition will be less expensive and lower risk than waiting for IPv4 starvation to hurt.  I interviewed some key enterprises about their specific grumbles but the great news is that most are transitional and already people are working on fixing them.</p>
<p></p>
<p></p>
]]></description>
		<wfw:commentRss>http://www.andyd.net/2009/ipv6-track-at-nanog/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>IPv4 Run-out policies in Europe</title>
		<link>http://www.andyd.net/2009/ipv4-run-out-policies-in-europe/</link>
		<comments>http://www.andyd.net/2009/ipv4-run-out-policies-in-europe/#comments</comments>
		<pubDate>Thu, 23 Apr 2009 19:09:25 +0000</pubDate>
		<dc:creator>andy</dc:creator>
				<category><![CDATA[The 'net]]></category>
		<category><![CDATA[bgp]]></category>
		<category><![CDATA[ipv6]]></category>
		<category><![CDATA[networking]]></category>
		<category><![CDATA[non-tech]]></category>

		<guid isPermaLink="false">http://www.andyd.net/?p=151</guid>
		<description><![CDATA[<p>There are a few policy suggestions pushing their way through the RIPE policy development process which discuss how the final remaining IPv4 addresses should be given to end users in the European region.</p>
<p>They all show that the effects of scarsity of IP addresses will be felt before the final few addresses become assigned to end users.  All consumers of addresses will feel constrained, which means all businesses trading online, whether they are a traditional ISP, a growing e-commerce shop, or a datacentre/hosting firm.  The policies under consideration are :</p>
<ul>
<li>2008-06 &#8211; Both new and existing organisations requesting IPV4 addresses shall be given addresses only to support transitioning technologies (i.e. infrastructure services which enable access to IPv6 addressed resources.)  They will only be given one block of IPv4 addresses, and this shall be the smallest possible range of addresses as decided by the community at large.  This is the only range of addresses which shall be given to the end user, even if their needs justify more.</li>
<li>2009-03 &#8211; From summer 2010, any organisation shall only be given enough new addresses to cater for anticipated need for nine months.  By summer 2011, this will change to three months.  Organisations (registries and end users) MUST have used more than half of their address space within six months of assignment or allocation.</li>
<li>2009-04 &#8211; Organisations must demonstrate that they are implementing an IPv6 transition policy (RFC5211) in order to be given IPv4 addresses.  Allocations from the RIPE NCC will be /27 (32 addresses for the entire registry, e.g. ISP)</li>
</ul>
<p>This also means that the effects of black market trading in address space will be seen before the &#8216;anticipated&#8217; IPv4 dry date in 2011.  There are no magic bullets, you (and your customers, suppliers, and partners) need deep pockets, decades worth of existing resources, or an ipv6 transition plan.  The only sensible option is to plan your v6 deployment today.</p>
<p></p>
<p></p>
]]></description>
		<wfw:commentRss>http://www.andyd.net/2009/ipv4-run-out-policies-in-europe/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>18 months? And google are nimble?</title>
		<link>http://www.andyd.net/2009/18-months-and-google-are-nimble/</link>
		<comments>http://www.andyd.net/2009/18-months-and-google-are-nimble/#comments</comments>
		<pubDate>Sun, 29 Mar 2009 10:55:03 +0000</pubDate>
		<dc:creator>andy</dc:creator>
				<category><![CDATA[The 'net]]></category>
		<category><![CDATA[bgp]]></category>
		<category><![CDATA[ecommerce]]></category>
		<category><![CDATA[ipv6]]></category>
		<category><![CDATA[networking]]></category>

		<guid isPermaLink="false">http://www.andyd.net/?p=144</guid>
		<description><![CDATA[<p>Google recently announced that they&#8217;d done a <a href="http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html" onclick="javascript:urchinTracker ('/outbound/article/www.networkworld.com');">front-to-back implementation of IPv6, using engineers&#8217; spare time, in 18 months</a>.  Cue well over 100 <a href="http://tech.slashdot.org/article.pl?sid=09/03/26/1753259" onclick="javascript:urchinTracker ('/outbound/article/tech.slashdot.org');">comments on slashdot</a> claiming that this goes to show how hard implementing any sort of v6 service is at all, given it takes a company known for hiring smart people as long as 18 months.</p>
<p>I decided to put the timetable to the test.  On Wednesday at 2:30PM uk time, I applied for a /32.  One hour later, we were allocated 2a02:c30::/32.  I straight away assigned a /48 for our network infrastruture, and another for our production hosting lan, another for our development hosting lan.  From these /48s, several /64s were reserved, one for router loopbacks, another for point to point links, more for individual hosting applications.  An hour later, this was implemented on our network &#8211; routers had loopbacks, and a v6 IGP was up and running, and working.  I filed a ticket with our upstreams, and the first announcement was turned up minutes later &#8211; check <a href="http://www.ris.ripe.net/perl-risapp/prefixdashboard.html?prefix=2a02%3Ac30%3A%3A%2F32"title="BGPlay for 2a02:c30::/32"  onclick="javascript:urchinTracker ('/outbound/article/www.ris.ripe.net');">BGPlay</a> for exact times.  Around 2 hours after making our application to RIPE, we were participants on the IPv6 internet.</p>
<p>Now this is not a front-to-back implementation, but in just two hours we had something to hand over to our systems teams for testing and training.  <em>If you rely on the internet for your business, this is the stage you need to get to urgently</em>.  In fact, by close of play Wednesday, some of our simpler services were already running dual stack, and additionally we are now running Dual-stack for DNS &#8211; Nominet having the simplest method for adding ipv6 glue.</p>
<p>Full disclosure: In reality our v6 rollout started months ago, by monitoring advice on operational mailing lists, attending v6 seminars, and in fact we had been engaged in the rollout of ipv6 on several customer networks to date, so this rollout was not frightening for us.</p>
<p>We are now in the position that we can integrate IPv6 addressing as part of every configuration refresh or maintenance on our services, so that v6 is rolled out in a controlled, monitored, and careful manner.  By moving now, we have bought ourselves time &#8211; a luxury, and firms waiting longer to start their v6 rollout will have a harder time, with the whole migration feeling like a &#8216;y2k bug&#8217;.</p>
<p></p>
<p></p>
]]></description>
		<wfw:commentRss>http://www.andyd.net/2009/18-months-and-google-are-nimble/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>IPv6 Tooling talk</title>
		<link>http://www.andyd.net/2009/ipv6-tooling-talk/</link>
		<comments>http://www.andyd.net/2009/ipv6-tooling-talk/#comments</comments>
		<pubDate>Fri, 13 Mar 2009 13:34:42 +0000</pubDate>
		<dc:creator>andy</dc:creator>
				<category><![CDATA[The 'net]]></category>
		<category><![CDATA[ipv6]]></category>
		<category><![CDATA[networking]]></category>
		<category><![CDATA[telecoms]]></category>

		<guid isPermaLink="false">http://www.andyd.net/?p=134</guid>
		<description><![CDATA[<p>At 3pm I&#8217;ll deliver this lightning talk to the LINX IPv6 Specialist Techical Workshop 2009 on <a href="www.andyd.net/media/talks/ipv6_tooling.pdf">IPv6 Tooling</a>.</p>
<p>It covers :</p>
<ul>
<li>Provisioning tools/notes</li>
<li>SNMP</li>
<li>NetFlow notes</li>
<li>Scripting notes</li>
</ul>
<p></p>
<p></p>
]]></description>
		<wfw:commentRss>http://www.andyd.net/2009/ipv6-tooling-talk/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>2011 &#8211; An addressing odyssey. Preparing enterprise for IPv6.</title>
		<link>http://www.andyd.net/2008/2011-an-addressing-odyssey-preparing-enterprise-for-ipv6/</link>
		<comments>http://www.andyd.net/2008/2011-an-addressing-odyssey-preparing-enterprise-for-ipv6/#comments</comments>
		<pubDate>Thu, 04 Dec 2008 23:11:05 +0000</pubDate>
		<dc:creator>andy</dc:creator>
				<category><![CDATA[Sys Admin]]></category>
		<category><![CDATA[The 'net]]></category>
		<category><![CDATA[ecommerce]]></category>
		<category><![CDATA[ipv6]]></category>
		<category><![CDATA[networking]]></category>
		<category><![CDATA[non-tech]]></category>
		<category><![CDATA[peering]]></category>
		<category><![CDATA[telecoms]]></category>
		<category><![CDATA[voip]]></category>

		<guid isPermaLink="false">http://www.andyd.net/index.php/2008/12/04/2011-an-addressing-odyssey-preparing-enterprise-for-ipv6/</guid>
		<description><![CDATA[<p>Yesterday I gave a talk to Sheffield GeekUp on <a href="http://www.andyd.net/media/talks/2011-addressing-odyssey.pdf" >preparing enterprises for IPv6</a> [download].  The premise of the talk was :</p>
<ul>
<li>IPv4 addresses are scarse, and at current consumption rates, the IANA pool of free v4 addresses will be gone at the start of 2011.</li>
<li>This starts a &#8220;Post IPv4 world&#8221; where the IPv4 internet continues to function as before (certainly initially), but obtaining new addresses becomes harder and expensive.  This inhibits expansion of existing firms, and new entrants to the market.</li>
<li>Address trading is likely to lead to a larger routing table, meaning that failure-recovery times increase, and the risk of blackholes on the internet increases.</li>
<li>Large broadband providers may not have enough v4 addresses to give one address per customer.  This means protocol translation techniques need to be used, which break the end to end model.  We rely on the end to end model when innovating new services on the internet.</li>
<li>If services and consumers gradually roll v4 and v6 (dual stack), the negative impact of markets for addresses, routing problems, and translation can be mitigated.</li>
<li>Service providers are enabling v6 in the core.  Enterprises need to move next in order to get the world v6 ready.</li>
</ul>
<p>The advice I gave was :</p>
<ul>
<li>Today&#8217;s market leaders are already learning v6 lessons in their labs, (e.g. ipv6.google.com).  They are doing this to help them retain market leadership.  If you want to retain your market position, start labbing your applications and service provision with v6.</li>
<li>Write a policy stating all new purchases of infrastructure and services need to be from providers with v6 support, or a well defined v6 road map.  In other words, make v6 a &#8220;life cycle upgrade&#8221;.</li>
<li>Share information, and learn information from your industry peers.</li>
<li>I also listed some advice to developers with regard to v4 and v6 differences.</li>
<li>I then delivered a very quick primer to those who have not seen v6 deployed before.</li>
</ul>
<p>My hope is that this talk is improved upon and delivered internationally to enterprises.</p>
<p></p>
<p></p>
]]></description>
		<wfw:commentRss>http://www.andyd.net/2008/2011-an-addressing-odyssey-preparing-enterprise-for-ipv6/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
	</channel>
</rss>

