[address-policy-wg] Re: how 200 /48's fails the job

Pekka Savola <pekkas at netcore.fi> writes:

> On Tue, 5 Apr 2005 Michael.Dillon at radianz.com wrote:
> ...
> > The 200 new customer limit was meant to be a measure of largeness and
> > seriousness. I think that in today's world, that measure fails to do
> > the job.
> 
> Could you clarify, why do you think "200 customers" fails as a meter for largeness ?
> 
> There are some odder cases like transit only ISPs (which technically could only have very few direct
> organizational customers -- let's assume that those would get the IP space using some other provisions or
> as a matter of interpretation), but apart from that, why exactly is requiring 200 customers unreasonable?

I think Mr. Bartels already made some of these points, but I'll still add
my two (euro)cents to this discussion.

I would think that the concept of lumping all "customers" into a
single class is flawed. I work for a managed hosting provider, and we
currently have POPs in three countries with multiple transit providers
and peerings. Obviously we have our own IPv4 allocation.

However, our focus is on medium-size and large customers, which are
quite unlike residential end-user customers where 200 would be next to
nothing. I doubt we'll have 200 such customers (without creative
accounting, that is) in a while yet, but we are still doing active
business. The current rule effectively prevents us from deploying IPv6
to our customers.

In the long run, I believe that as long as the current policy prevents
hosting companies who serve content to end-users from deploying IPv6,
it removes motivation from the end-user ISPs (who would have no
problem getting the allocation) to actually deploy it to their users.

While routing table growth is a concern, not having (v6) routing table
growth is in my opinion an even larger concern. Therefore my view is
that the arbitrary fixed criterion of having to be "large" (for
whatever value of large) for a v6 allocation should be dispensed with.

-- 
 Valtteri Vuorikoski <vuori at magenta.net>
 MagentaSites Oy