Martin wrote:
On Tue, Apr 26, 2011 at 5:51 PM, Marcin Kuczera <marcin@leon.pl> wrote:
hello,
Is it possible to discuss ability of getting second IPv6 PA allocation as a LIR without filling first one ? See below.
The reason for such a need is a change of IPv6 PI rules, it is no longer possible to use IPv6 PI as ISP (/128 for subscibers). So, solution is that LIR segment /32 into smaller units an assigning them to their SponsorLIR agreement customers.
However, first /32 IPv6 allocation is in our case advertized as whole by our AS13000. Once some internal policy for suballocations is used, this prefix can not be divided into smaller prefixes.
I doubt this is correct. You mentioned that you had not filled the /32. In other words, there should be /48s left over unallocated internally.
These /48s can be (sub-)allocated to customers (please forgive my flawed internet-numbers-delegation-vocabulary), who are free to announce them over BGP sessions.
It is then up to your customers to find transit providers willing to accept these announcements, which may be helped by them having route6 objects registered.
My question there would be wether larger prefixes then /32 from the pa-ranges would be generally accepted? As far as I understand, that would be a problem.
If they have trouble with connectivity due to AS:es filtering out these long prefixes from IPv6 PA regions, they will have to get their own PA by becoming a LIR member themselves.
Or forcing their customers to apply for PIv6 for their purposes.
For SponsorLIR agreement customers - little ISPs, willing to advertise their i.e. /48 from our /32 without any overlapping prefixes, second /32 IPv6 PA (not advertised as whole by LIRs ASes) would be great... The yet-to-be properly challenged (legacy?) consensus/opinion of this WG is that ISPs must pay to play IPv6. I.e., you must become LIR to be allowed to announce routes into the DFZ.
IPv6 PI (PIv6) is nearly useless, by design: Only customer-less end-users can use PIv6 space today without stepping into a grey zone in the policy documents. I.e., these end-users can't have customers.
There is one other solution. You apply for v6-PI for your own infrastructure and encourage your customers apply for their own pi-space in order to get v6. This is what the non-profit-organization I work for is now going to do (since we cannot afford becoming LIR). Obviously, this blows up the routing table (which I strongly dislike), but policy is clear that this is the only way to continue what we are doing without willingly violating the current policy. IMHO obviously, changing PI policy would be a more elegant solution.
Presumably, the more ISPs that sign up for this Internet tax (the LIR membership fees), the lower it will become (#LIRs is most definitely sub-linearly proportional to the RIPE NCC:s operational costs). It is fairly obvious to me that this attempt to (at least partially) solve a *perceived* network model problem with taxes is not long-term stable in itself.*
Yea, that would be nice. But that will only help eventually, not now.
Personally I'd much prefer if the policies were aligned with reality better, since it would allow us to get rid of the more or less arbitrary policy-interpreting role the IPRA:s at the RIPE NCC has for v6 resources today. This would make the landscape much more honest and just. After all, it's just bits anyway.
I strongly support that!
* This is *the* major source for all this head ache. There is a considerable fear among many AP-WG participants that making IPv6 PI easier to get will (1) lead to an uncontrolled explosion of IPv6 prefixes in the DFZ (2), which hardware will fail to handle (3) and the IPv6(**) internet will break down (4).
I don't really see why suddenly a lot of organizations should come up wanting PIv6. I think the need of PIv6 would be quite compareable to PIv4, and at least nowadays, the PI-Prefixes aren't really that problem as far as I see. And, as pointed out before, the current PIv6 policy can even be interpreted as source of much more v6-routes in the DFZ anyways. regards, Immo