[98153] in North American Network Operators' Group
Re: An Internet IPv6 Transition Plan
daemon@ATHENA.MIT.EDU (David Conrad)
Wed Jul 25 09:13:45 2007
In-Reply-To: <p0624080cc2ccdf65bfb9@[192.168.3.65]>
Cc: North American Noise and Off-topic Gripes <nanog@merit.edu>
From: David Conrad <drc@virtualized.org>
Date: Wed, 25 Jul 2007 14:02:13 +0200
To: John Curran <jcurran@mail.com>
Errors-To: owner-nanog@merit.edu
John,
On Jul 25, 2007, at 1:14 PM, John Curran wrote:
>> All the existing big businesses can operate with what they already
>> have, Google and Yahoo are not going to face any sort of crisis
>> for the foreseeable future. And as I've been saying for a while
>> and Randy put in his presentation, supply and demand will simply
>> cause the cost of having public IPs to go up from zero to
>> something tiny - enough to see IPs being put back into the pool to
>> those who really need them.
> Putting them back into circulation doesn't work unless
> its done in very large chucks to major ISPs. If this isn't
> the model followed, then we will see a lot more routes
> for the equivalent number of new customers. People
> complaining about the ability to carry both IPv6 and
> IPv4 routing need to think carefully about how long
> we'll actually last if the ISP's are injecting thousands
> of unaggregatable routes from recovered address space
> each day.
Been there, done that, got several t-shirts. Longer prefixes _will_
hit the routing system. ISPs will react by (re-)implementing prefix
length filters. Many people will whine.
> Additionally, the run rate for IPv4 usage approximates
> 10 /8 equivalents per year and increasing. Even given
> great legacy recovery, you've only gained a few more
> years and then still have to face the problem.
This assumes consumption patterns remain the same which is, I
believe, naive. In a world where you have to pay non-trivial amounts
for address space utilization, people will only use the address space
they actually need and you'll see even more proliferation of NAT for
client-only services.
Rgds,
-drc
