[ppml] Just say *NO* to PI space -- or how to make it less destructive

[Stephen Sprunk]

Thus spake "Pekka Savola" <pekkas at netcore.fi>
> On Thu, 20 Apr 2006, Scott Leibrand wrote:
>>>   1. Each assignment must be accompanied by a recurring fee (at least
>>> 1000-2000 USD/EUR a year, preferably 5000+).  This is peanuts
>>> (compared to other costs) to anyone who actually needs this
>>> multihoming solution.  However, this ensures at least some minimum
>>> usage barrier ("those who don't really need this can use different
>>> multihoming solutions"), and recovery of the resources back to RIR
>>> after the company has gone bankrupt or no longer needs the addresses.
>>> If you don't know where to put the extra money, donate it to ISOC or
>>> something.

I think that the multihoming requirement will be enough to keep the number 
of assignments reasonable; if you look at the actual number of non-transit 
ASNs in the v4 table, it's not all that large.  If we assume one PIv6 prefix 
per non-transit ASN, which is the goal, we're looking at under 10k routes 
from the ARIN region.

>> As has been discussed at ARIN, this is a good way to get the
>> government to declare the RIR a monopoly engaging in anticompetitive
>> behavior.  I for one don't want that.
>
> I don't think that follows, but unless ARIN legal counsel or someone
> who is a real lawyer has made a statement here, I'm not sure how
> seriously to take this.  Pointer to such official legal counsel would
> be appreciated.
>
> That is, ARIN has every right to require, for example, that everyone
> getting a prefix is (for instance) a member of ARIN, and charging for
> the membership should be OK.

I'd want a lawyer to sign off on it.  You're talking about deliberately 
charging an excessive fee to make it more difficult for smaller companies to 
compete with larger ones.  That has the appearance of an industry cartel 
creating artificial barriers to lock their smaller competitors out of the 
market, and the FTC generally doesn't like that.

Then again, IANAL.

> RIRs run on non-profit principle, but nothing precludes them from
> increasing the expenses, e.g., for donations to make the internet a
> better place,

That's an interesting thought, but siphoning off fees for other purposes (no 
matter how noble or popular) is a slippery slope.  Let's keep the RIRs 
focused on what they were created for and on a cost-recovery basis, and 
members who want to donate to ISOC or other groups can do so.

> setting a foundation for multihoming research to actually SOLVE this
> problem, etc.etc.

In theory, we already have a group tasked with that: the IETF.  Are you 
proposing that RIRs start developing protocols outside the IETF?  Or funding 
people to work full-time in the IETF on problems pertinent to RIRs?  Again, 
this is a slippery slope and distracts from the RIRs' purpose.

I definitely encourage the folks that are against PIv6 to work on better 
solutions, but IMHO the RIRs are not the correct vehicle or forum for that. 
ARIN is already treading on thin ice by rejecting the IETF's addressing 
plan.

>>>   2. one-size-fits-all assignments, period.  You get a /48 or /32 (I
>>> don't have much preference here), but you must not be able to justify
>>> for larger space.  This is to avoid the organization from getting a
>>> larger block and chopping it into smaller pieces and polluting the
>>> global routing table with more specifics which would get past prefix
>>> length filters.
>>
>> With the current ARIN policy proposal, you'd get a /48, with a /44
>> reserved for growth.  Would you advocate giving everyone a /44 up front
>> instead?  Or something else?  I don't have too much preference here, 
>> FWIW.
>
> I wouldn't object to reserving a /44 just in case, but make no
> provisions (at this point) for applying more.  If someone needs more
> than /48, it needs to justify another one, and get a separate /48
> (with its own reserved /44).

So instead of giving an org a /47, which _could_ be advertised as a single 
route, you'd prefer to give them two /48s, which _must_ be advertised as two 
routes?  That seems to increase routing table pollution, not reduce it.

Also, what's the point of reserving a /44, or worse multiple /44s, if we're 
only going to let people use a /48?  That seems to defeat the purpose of 
having a reserved block.

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin