On Thu, 20 Apr 2006, Stephen Sprunk wrote:
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.
(Actually, the number is somewhere between 15k and 20k but that's beside the point.) The upper limit is around the number of AS numbers, and if it's expanded to 32 bits, at least I start to feel uncomforable... "Umm.. are we sure 64K folks playing around at DFZ isn't enough??? we want 4B instead...????" Remember, it's easy and cheap to have a multihoming setup with two DSL lines...
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.
Come on, arguing that 1K or even 5K is an "excessive fee" for PI prefixes in the context of reliable multihoming setup and services provided seems a bit absurd. I'd agree that if the charge was 100K per year, this could be considered locking out smaller competitors, but (say) 1K is nothing -- that's less than 100 bucks a month! You might even consider a payment like 1K or 2K fair: small ISPs which get exactly the same resources have to pay such in their membership fees. Obviously the end-sites should pay at least the same if they consume the same resources..
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 said 'research', not 'engineering'. The IETF isn't the right vessel for research, though IETF could maybe be consulted on it.
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.
Not necessarily. Doing so would hopefully ensure that it'll be *more* difficult to justify for more than a /48 especially if you have to pay for the extra too (hence less pollution). I.e., we'd need to figure out we have sufficiently strict criteria.
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.
As I said, I wouldn't object to reserving a /44 under those conditions, but I wouldn't require reservation either. One reason for reserving is that we could have the option of changing the policy later if we become wiser (or dumber) and decide that maybe we'll want to be able to deal out aggregatable chunks after all, regardless of the more specific crap that's filling the routing tables right now. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings