[address-policy-wg] [Ticket#2013020401002158] New on RIPE Labs: 1, 000 /22 Allocated from Last /8

Dear Shane,

> But I thought the whole point of the special policy for the last /8 was
> to support new companies, who did not have a chance to get any reserves?

Correct. 

I see 2 cases:

1. "Old LIRs". They had some IP-space from previos /8. They had some IPs. And
have some networks which were used not very accurate. They can optimize using
IPv4 and didn't request IPv4 from last /24. They can give some IPs for
clients. But I belive 80% of them will request IPv4 from last /8 during 12
month.

2. "New LIRs". Many "Old LIRs" tell to customers that they can give only 1-4
IPs. So in this case companies which need IPs will request them via RIPE as a
new LIRs. 

I think we should push deployment IPv6 and forget about any improvments policy
for IPv4. 

--
Alexey
LeaderTelecom

06.02.2013 16:53 - Shane Kerr написал(а):
 Alexey,

On Tuesday, 2013-02-05 14:11:35 +0400,
LeaderTelecom Ltd. <info at leadertelecom.ru> wrote:
> Dear Shane,
>
> >   That's about 6 years, assuming things stay constant.
> >       2155 / 365.25 = 5.9
>  
> Many companies in fact had reserves, while they thinked about future.

But I thought the whole point of the special policy for the last /8 was
to support new companies, who did not have a chance to get any reserves?

To me, the policy makes no sense otherwise.

> I think the most intresting changes we will see during next 12 month.
> Amount of requests IPv4 from last /8 can rapidly increase (in 2-5
> times).

We see a spike in the number of new LIR which happened almost exactly
at the same time the IPv4 addresses ran out and the "one allocation per
new LIR" policy went into effect:

[1]https://labs.ripe.net/statistics/lirs-with-and-without-ipv6

It looks like people are creating new LIR to circumvent the intent of
the policy - reserving IPv4 space for newcomers.

Cheers,

--
Shane
 


[1] https://labs.ripe.net/statistics/lirs-with-and-without-ipv6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20130206/392857d4/attachment.html>