[address-policy-wg] Maximum size for current IPv4 allocations

Dear Ronald,

As of November 2019 the RIPE NCC only provides /24 IPv4 allocations to 
LIRs that have not previously received an IPv4 allocation from us. As 
Elvis clarified, the examples you listed are the results of resource 
transfers.

The “netname:” attribute of an INETNUM object in the RIPE Database 
indicates whether an IPv4 allocation was received directly from the RIPE 
NCC or via a transfer. It includes the date on which that range was 
provided by the RIPE NCC, also for smaller ranges that are part of a 
previously bigger range. If the date in the “netname:” and the date on 
which the object was created differ, you can deduce that the range 
concerned was not allocated directly by the RIPE NCC.

I hope this helps answer your question.

Kind regards,
Marco Schmidt
RIPE NCC

On 15/08/2022 10:45, Elvis Daniel Velea wrote:
> hi,
>
> On Mon, Aug 15, 2022 at 01:41 Bogdan Rotariu <bogdan at rotariu.ro> wrote:
>
>
>>     On Aug 15, 2022, at 11:19, Ronald F. Guilmette
>>     <rfg at tristatelogic.com> wrote:
>>
>>     In message <301e0ef8-ed15-67d3-d390-7bea8571c7cb at ripe.net>,
>>     Marco Schmidt <mschmidt at ripe.net> wrote:
>>
>>>     On 15/08/2022 09:16, Gert Doering wrote:
>>>>     Hi,
>>>>
>>>>     On Mon, Aug 15, 2022 at 12:10:49AM -0700, Ronald F. Guilmette
>>>>     wrote:
>>>>>     What is the maximum size for current new IPv4 allocations in
>>>>>     the RIPE
>>>>>     region?
>>>>     /24  "if there is something to distribute at all"
>>>
>>>     Just to confirm what Gert said.
>>>
>>>     For more information please feel free to check our website about
>>>     IPv4
>>>     https://www.ripe.net/manage-ips-and-asns/ipv4
>>>
>>>     as well the underlying RIPE policy which was published in
>>>     November 2019
>>>     https://www.ripe.net/publications/docs/ripe-733#51
>>
>>     Thank you for the confirmation. Unfortunately, I remain rather
>>     mystified
>>     by how the following IPv4 blocks, and the current RIPE WHOIS
>>     records that
>>     pertain to them, comport with what you and Gert have just now
>>     told me.
>>     Perhaps there is something that I am missing (?)
>>
>>     ORG-AS976-RIPE:
>>
>>     31.44.32.0/20 <http://31.44.32.0/20>      created:
>>     2022-06-24T06:46:34Z
>>     46.21.16.0/21 <http://46.21.16.0/21>      created:
>>     2022-06-24T06:46:34Z
>>     46.21.28.0/22 <http://46.21.28.0/22>      created:
>>     2022-06-24T06:46:34Z
>>     77.220.64.0/19 <http://77.220.64.0/19>     created:
>>     2022-06-23T09:56:04Z
>>     185.155.176.0/22 <http://185.155.176.0/22>   created:
>>     2022-06-23T09:56:04Z
>>     185.155.184.0/22 <http://185.155.184.0/22>   created:
>>     2022-06-24T06:46:34Z
>>     193.221.216.0/23 <http://193.221.216.0/23>   created:
>>     2022-06-24T06:46:33Z
>>     193.222.104.0/23 <http://193.222.104.0/23>   created:
>>     2022-06-24T06:46:33Z
>>
>>
>>     Regards,
>>     rfg
>>
>>
>>     P.S.  I would still be concerned, although perhaps a bit less
>>     concerned, if
>>     this organisation had not elected to place a fradulent and
>>     non-existant
>>     comnpany name into its public WHOIS organisation: record.  I
>>     would however
>>     still remain befuddled by how this organisation managed to be
>>     assigned
>>     some 72 times as much IPv4 address space as anybody else could
>>     get, all
>>     apparently less than 2 months ago.
>>
>>     But there must be a reasoable explanation, I suppose.
>
>
> when the RIPE NCC processes a transfer and needs to split a block, all 
> the smaller blocks that are transferred from the original large block 
> will have the date of the transfer as creation date
>
> /elvis
>
>>
>
>     There is, those are transfers, check them here
>     https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/within-ripe-ncc-service-region/ipv4-transfer-statistics
>     -- 
>
>     To unsubscribe from this mailing list, get a password reminder, or
>     change your subscription options, please visit:
>     https://mailman.ripe.net/
>
> -- 
> This message was sent from a mobile device. Some typos may be possible.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20220815/b8ce699d/attachment.html>