Tom,A permanently unused address does not contribute to the Internet community; any reservation of the remaining addresses must have a deliberate purpose, and have clear criteria for when and how they will be used.
It may be true that a /8 is allocated within a few months at the current rate of consumption, but it still enables connection of 16 million people (or more with NAT) to the Internet. While I agree that 16 million is a very small proportion of the population in a region with 2 - 3 billion people, it is still 16 million people nevertheless.
So, in a scenario where IPv6 is not available universally within 10 years for some reason (which I hope will not be the case), what would be valid reasons for making those 16 million people wait for connectivity? That is, what would justify reserving addresses for later use rather than allocating them in 2011?
To my mind, the only reasonable cause to reserve addresses would be if there were an expectation that the ratio <connected services:IPv4 address> would greatly increase in coming years - that is, address reservation might be worthwhile if we could reasonably believe that instead of using one /8 to connect 16 million people in 2011, we could use it to connect 160 million in 2016, or 1.6 billion in 2021. (I don't know how such ratio growth might be achieved - it might be through something like facilitation of IPv6 deployment (say, 1 IPv4 address is used with 1000 IPv6 services), or through improved NATing, etc.)
If no improvement in <service:address> ratio is expected, then it will only ever be 16 million people (or whatever current NATing allows) that can be connected, irrespective of when those connections happen.
So, my problems with prop-062 from the perspective of the above points are:- It seems likely to incidentally rather than deliberately reserve addresses, without criteria for final usage; - Its premise seems to be based on equally sharing the pain of IPv4 exhaustion, rather than identifying how limiting distribution could provide true management across IPv4 exhaustion and IPv6 implementation, leading to improved Internet connectivity in the entire Asia-Pacific region across this time.
A suggestion for an alternative proposal might be one where future IPv4 allocations would only be made if it could be demonstrated by the requester that 1 IPv4 address would support connectivity for X hosts, where X is a number which may not be achievable with today's technology, but could be reasonably foreseen to be possible in 5 years' time or so (whether this be through IPv6-to-IPv4 translation, NAT or other means).
Regards, David At 07:36 PM 28/07/2008, Tom Vest wrote:
Given the stakes involved, and the eminently plausible outcome that some small quantity of IPv4 may continue to be both non-substitutable and non-optional for independent operations for a very long time to come -- much longer than ten years -- AND the fact that there will noway to remedy the situation if your assumptions about the time-to- tipping point turn out to be mistaken, wouldn't it be prudent to planin a way that preserves as much flexibility as possible for an unknown future? As Randy noted, the run rate for sub-/8s is often measured in days... Is it really worth continuing on a course that everyone knows is destined to end for a few days more, at the price of giving up much freedom to adjust to unknown/changing circumstances in the future? No reductio ad absurdum reactions please -- the price of this policy as written is a few lost *days* of status quo allocation activity, nothing more. TV On Jul 28, 2008, at 8:31 AM, David Woodgate wrote:Thanks, Geoff - this is useful information for the discussion. It seems to confirm that the likelihood of getting to 8,000 LIRs in the next 10 years is very unlikely. (And I suspect that not all of the 4,403 LIRs to whom allocations have been made by APNIC would be active now.) Regards, David At 03:13 PM 28/07/2008, Geoff Huston wrote:David Woodgate said the following on 22/7/08 14:10:My main problem is that prop-062 seems to risk locking up the majority of the last /8, and therefore does not share it at all, let alone in a fair and equitable fashion.I don't see how it is locking up the majority of the final /8. Would you please explain this.prop-062 allows for 16,000+ LIRs to each get a minimum /22 allocation. As discussed in a previous email, it seems hard to justify even 4,000 LIRs over the next few years; I'd suggest that 8,000 LIRs in the Asia-Pacific seems unlikely within 10 years. That would seem to leave up to 8,000-12,000 * /22s unclaimed for a long time. But - if I'm reading it correctly - prop-062 doesn't seem to suggest that anything else would be done with this unclaimed space, and therefore it won't be used during that time; that is, the space is "locked up" and unused.you make the claim that:"it seems hard to justify even 4,000 LIRs over the next few years; I'd suggest that 8,000 LIRs in the Asia-Pacific seems unlikely within 10 yearsHere's some historical data that may be useful in the context of this particular aspect of the discussion APNIC publish an "extended" version of the daily stats file (ftp://ftp.apnic.net/pub/stats/apnic/delegated-apnic-extended- latest") The last field in each row is a code for the end entity recipient of the address allocation or assignment, or approximately "LIR" in your terminology. Now there is some small uncertainty in the figures as at times the NIR code is used instead, but overall heres the Ipv4 allocation record for APNIC since 2000, based on the numbers in that published file year new repeat cumulative count 2000 94 432 2856 2001 86 430 2942 2002 83 339 3025 2003 115 425 3140 2004 120 570 3260 2005 216 617 3476 2006 253 786 3729 2007 394 745 4123 2008 280 429 4403 i.e. in 2007 APNIC made 394 IPv4 address allocations to "new" LIRs and 745 allocations to LIRs who had already previously received an address allocation. Overall APNIC appears to have made allocations / assignments to 4,403 LIRs since its inception, and some 1,547 new LIRs have been recorded since 1 Jan 2000 (i.e the last 8.5 years) regards, Geoff* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy at lists dot apnic dot net http://mailman.apnic.net/mailman/listinfo/sig-policy