Post-Exhaustion-phase "punishment" for early adopters

Fri Feb 4 19:11:02 UTC 2011

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 4, 2011, at 10:47 AM, Heinrich Strauss wrote:
> So once the "early" adopters migrate their networks to IPv6, there is no business need to maintain the IPv4 allocation and that will be returned to the free pool, since Business would see it as an unnecessary cost.

However, doing enough of a migration to be able to actually free up the IPv4 addresses, in advance of the devices using them dying of old age or being naturally cycled out, also imposes a cost, and likely a high one relative to the RIR maintenance fees, so it's my guess that the rate of IPv4 returns may not be too fast.

> This would seem to counteract the forced move to IPv6, since, once the early adopters move their services exclusively to IPv6 (or maintaining very small IPv4 blocks), there would be plenty of IPv4 space for the late adopters to request.

If you look at the actual numbers involved, I think you'll find that the "plenty" would actually be quite small and in quite small chunks, relative to what the industry could use, if they weren't trying to get over to v6.  So I doubt it will have that much effect.

> Has it been stated by all RIRs that IPv4 blocks are unallocatable once the exhaustion phase kicks in? Or is there another mechanism to ensure that we don't hand out the space being handed back once IPv6 is the norm?

No, and in fact, I believe all the RIRs will probably do a reasonably brisk business in reclamation and reallocation, albeit in ever smaller blocks.  One way to think about it is that there's no particular reason to think that the rate of increase in the number of IPv4 prefixes in the global BGP routing table will slack off, therefore those prefixes will each simply be smaller and smaller, over time.  More or less.

Speaking not particularly with my ARIN-board-hat-on,

                                -Bill

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk1MT0YACgkQGvQy4xTRsBH3RwCgpfo6JbOC8aYnsCu3h5B9++6u
qA4AoJVds96Ua9dvqx2RDUw9qBZcyOQK
=aMk8
-----END PGP SIGNATURE-----