[address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"

Jon Lawrence <jon at 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