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

Martin wrote:
> 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20110501/a52d8ba7/attachment.sig>