Jon Lawrence <jon@lawrence.org.uk> writes:
On Friday 25 June 2004 22:12, David Kessens wrote:
The policy is very clear: 'you need a plan to have 200 customers'.
That's the whole point. The policy says *plan* to make 200 /48 assignments to other organisations within two years. What's the point in that ? anyone can *plan* to make 200 assignments.
It seems that folk have lost site of the motivation for this rule. What we were trying to achieve (and believe we still MUST strive to achive) is a balance between making it straightforward for a serious ISP to get an IPv6 block, but also prevent what is essentially an end site from getting an allocation direct from an RIR. The latter is not scalable long-term and must be prevented in general. The general goal is that any ISP that is seriously looking at deploying IPv6 and/or offering it to their customers should be able to get an allocation. But how do you "measure" the seriousness of this in straightforward, unambiguous ways? And how do you prevent what is essentially an end site from being able to get an allocation because (say) they happen to be a member of RIPE, ARIN, etc.? E.g., if all it takes to get an allocation is be a member, I suspect that some end sites will join _just_ to get an IPv6 address. It is these sorts of things that make it difficult to say "just give a block to anyone that asks," or otherwise remove all barriers to getting an allocation. The intention behind the wording:
d) have a plan for making at least 200 /48 assignments to other organizations within two years.
includes some key things. "other organizations" was intended to ensure that we don't get end sites saying "hey, I've got a global (internal) network, with 200 branch offices (each with a /48). I should qualify for an allocation". And "200" was chosen (somewhat arbitrarily) again to make it clear this wasn't just for a handful of end sites. In order to get good aggregation long term, we need to have ISPs aggregating _many_ end sites, i.e., in the thousands and more. This won't happen anytime soon, but once IPv6 becomes widely deployed, this is the sort aggregation we need. Thus, 200 was picked as a number large enough to indicate that over the long term aggregation of a significant number of end sites is needed. Finally, the 2 years figure was also somewhat arbitrary. I view the goal here as being something like: when IPv6 starts to get seriously deployed, and many end sites are being assigned /48s, at that point it would be appropriate to put some teeth into the "200 customers" figure. But since we aren't there, and don't really have any idea how long it will be before that kind of deployment takes place, we can't really put in a fixed number (and really believe it). Hence, the words "plan" and "two years". The idea here is that this indicates a serious committment to actually getting IPv6 enabled internally and made available to customers. But of course, if there is no customer demand, then the dates need to be pushed out per above. I believe all the RIRs have stated that they have no intention to go after LIRs after 2 years if they haven't actually gotten 200 customers. I suspect that they would start going after LIRs only after discussion within the community indicated that the state of deployment had advanced enough that it was now appropriate to go after deadbeats - LIRs that have allocations, but never really lived up to their obligations to really offer IPv6 service to its customers.
It seems to be a rule for the sake of having a rule - I'm sure there must have been good reasons for bringing it in, perhaps I just don't get it. e.g. An LIR gets an allocation by showing a plan to assign 200 /48's. But after 2 years they've only assigned 50. They would have obeyed the policy even though they failed to achieve the 200 assignments. This says to me that the 200 assignment rule is completely pointless.
Hopefully that explains the motivation behind the current wording. I agree that the current wording has been controversial and could be better. But what I would like to see is that any proposal for change keep the original goals in mind, rather than just say "stupid requirment, get rid of it completely - and don't replace it with anything else". We need to ensure for the long-term that the right balance is maintained between ease of allocation and prudent management of a (limited) public resource. And to be clear, I say "limited" no in the sense of numbers of addresses, but in the number of prefixes that can be effectively managed in the DFZ. Folks don't want just addresses, they also want connectivity to all other end sites. Thomas