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 <[email protected]> wrote:
On Aug 15, 2022, at 11:19, Ronald F. Guilmette
<[email protected]> wrote:
In message <[email protected]>,
Marco Schmidt <[email protected]> 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://lists.ripe.net/mailman/listinfo/address-policy-wg
--
This message was sent from a mobile device. Some typos may be possible.
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/address-policy-wg
