Marcin, 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. 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.
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. So, essentially, PIv6 is usable by either normal private persons, or businesses who do not use their PIv6 space for any business purposes (none, I think). 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.* If you think what I've described above sounds strange, read up on the AP-WG list archives. This and related topics have been discussed in the following threads at considerable lengths this year alone: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00205.... http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00164.... http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00069.... http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00039.... 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. Regards, Martin * 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). As you can see, (1, 2, 3, 4) are several issues that all deserve to be further researched IMO. ** And possibly IPv4 too, if both networks are physically over-layered on the same network gear. Continued expansion of prefixes is going to occur both in IPv4 and in IPv6 until there are no more "buyers". The biggest difference between these prefixes coming from unallocated space (IPv6) or from existing allocated space seeing its "usage-density" increased (IPv4) is that IPv6 is cheaper. At some point, it is going to be cheaper to become a IPv6 LIR than get even a small IPv4 block, and the problem remains just as unsolved then as it is now.