[address-policy-wg] getting second IPv6 PA as a LIR

Marcin,

On Tue, Apr 26, 2011 at 5:51 PM, Marcin Kuczera <marcin at 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.html
http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00164.html
http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00069.html
http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00039.html


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.