[ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text

Tue Feb 20 18:41:21 EST 2007

Hi Stephen,

See below, in-line.

Regards,
Jordi

> De: Stephen Sprunk <stephen at sprunk.org>
> Responder a: <stephen at sprunk.org>
> Fecha: Tue, 20 Feb 2007 15:52:22 -0600
> Para: <jordi.palet at consulintel.es>
> CC: ARIN PPML <ppml at arin.net>
> Asunto: Re: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation
> criteria - revised text
> 
> Thus spake "JORDI PALET MARTINEZ" <jordi.palet at consulintel.es>
>> Basically my intend with this proposal is to support those organizations
>> that aren't "knoww ISPs" (as required by section 6.5.1.1.d). This can fall
>> into two categories (but may be there are others that I don't see right
>> now):
>> 1) An organization which want to provide IPv4 and IPv6 services.
>> 
>> 2) An organization which only want to provide IPv6 services.
>> 
>> In both cases, seems to me unnecessary to ask for a slow start with *only*
>> IPv4 to be "known" or have a plan for 200/48 (there may be cases which a
>> smaller number of customers and there is no need to force that
>> organization
>> to use a single upstream and get allocated the address space from that
>> upstream, being forced to stay with that upstream on order to avoid
>> renumbering of its network and customer ones).
> 
> It's hardly "slow start" when we're giving every LIR a /32 to start with.
> That's a lot of addresses.

May be I've not used the "correct" terminology. My "slow-start" is referring
to a few customers (instead of a plan for 200, which can be perfectly
exceeded at the end), not the concept of a reduced block. The size of the
block is not "relevant" to my policy proposal modification.

If we want to enter into that discussion, I think it will be applicable to
all the allocations, and then we need to agree in the "typical" filtering
rule, etc. I think is a much more complicated topic, also because the
increase in the number of routing tables that it can create later on.

I think /32 is still reasonable, and what it seems a "waste" now, is not,
and instead, smaller blocks and the cost in terms of routing entries is a
very bad thing (at least with current routing technologies).

> 
> I also don't think that mere intent (even if documented) is sufficient
> grounds to give an org a globally-routable prefix.  If you wish to debate
> the 200 customer requirement, I'm sure many folks would be open to lowering
> it, but I cannot in any way support a policy change that allows anyone to
> get a /32 just because they buy a couple routers and sign up one or two
> customers.  To do so completely undermines the entire the allocation policy;
> we might as well stop asking for justification entirely and just hand out
> /32s to everyone who fills out the paperwork.

I think we need to be fair in what we do with IPv4 and IPv6. If you compare
the minimum IPv4 allocation, vs. the IPv6 one in % of the total number of
addresses available, may get surprised and the conclusion is that we may
need then to change this for IPv4 :-(

> 
> I also question the commercial viability of an ISP that does not offer IPv4
> services and plans to subsist for 5+ years on less than 200 customers who
> are so small they do not qualify for PI assignments.  Asking the ISP to make
> do with PA space (for the year or two it takes to deplete their VC money) is
> not unreasonable.  And, if they do somehow survive, they will qualify as
> "known" and be able to get an LIR allocation anyways.

I've some examples of IPv4 ISPs which have just a couple of "big" customers,
and for more than 5 years. It works.

They could qualify for PI, but we are talking about ISPs, not enterprises. I
think the PI policy is targeted to non-ISP cases.

> 
> Again, as with the last time you brought this up, I want to see an actual
> example (not a hypothetical) that there does exist a company which meets
> your specifications and has been denied an allocation.  Until then, I will
> remain convinced you are deliberately fabricating a case to demonstrate a
> perceived loophole in ARIN policy and do not have a bona fide concern.

I don't recall the exact name of at least a couple of people that during the
last meeting said "this is my case", but hopefully they are in the list and
can speak up.

I'm convinced this is valid situation and even more, convinced that the
actual policy could be against anti-trust laws, because there is not a valid
technical justification for the "200" limitation. I've checked that this is
the case in Spain with local lawyers, yes another region, but this kind of
laws are typically very similar around the world.

> 
> S
> 
> PS.  I also wonder why someone in Spain cares so much about ARIN policies.
> You're not even proposing the same change here that you proposed in RIPE,
> for that matter, even though the existing policy for both is identical.

I do care about policy everywhere. AND this/a similar (differences are due
to the discussions in each region, but originally all were almost the same)
policy has been submitted in all the regions, including RIPE NCC
(http://www.ripe.net/ripe/policies/proposals/2006-02.html). In AfriNIC and
LACNIC this specific change is not required because they already changed it
LONG time ago, there has not been a significant increase in the number of
allocations, which demonstrates that people will not ask for it if not
really needed, but some people may be stuck and is not fair.

> 
> Stephen Sprunk      "Those people who think they know everything
> CCIE #3723         are a great annoyance to those of us who do."
> K5SSS                                             --Isaac Asimov
> 
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.