On Tue, Feb 15, 2011 at 09:42:04PM +0100, Sander Steffann wrote:
The problem here is that the extra route has a global cost for everyone.
Just as every LIR PA block is at the global cost of everyone.
Correct. The idea is that one LIR PA block covers lots of customers. It's a matter of scalability...
An "enterprise" becoming LIR to get their /32-no-questions-asked as effective PI doesn't aggregate any customers as well. With that argument, you have to avoid non-ISPs becoming LIRs as well.
No surprised that non-LIRs are so much underrepresented in RIR policy processes. It's basically a hopeless position to take.
It certainly is not. A few years ago the was no IPv6 PI policy, and now we have one.
Yes, but why? Not to do customers a favour, but the LIRs realized that IPv6 migration won't really happen unless they give the relevant content players PI for their operations. Which induces a lot of operational headache and cost primarily on the ISP side. "Enterprises" are already used to NATting their day away - ISPs not. What I see coming is that ULA + NAT will be vast IPv6 reality. Thanks that the IPv6 end-to-end promise is killed off again via restrictive policies made by ISPs for ISPs.
- They already provide access services with IPv4 PI space According to the current policy they should become an LIR and get PA space.
So just "make them pay a penalty". They are not aggregating customers, so no good reason for PA other than artificial hurdle.
If we (=working group) decide that there should be IPv6 PI for these or other purposes, let's discuss that. This is a working group.
A working group with almost zero lobby for non-LIRs. Don't start fights you cannot win.
If you want to see something changed: write a proposal and it will be discussed!
Yes, between folks who have zero business interest for such a proposal to pass. See above - a fight you cannot win. Non-LIRs aren't organized enough to have any effective influence on RIR policy development process. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0