Maximum size for current IPv4 allocations
What is the maximum size for current new IPv4 allocations in the RIPE region? Someone told me it is /22, but I need to double check that.
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" Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
In message <YvnywMgx9pxMG6AC@Space.Net>, Gert Doering <gert@space.net> wrote:
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"
OK, but what WAS the policy, way back on, say, June 24th, 2022? Was the policy significantly different 2 months ago?
Hello Ronald, 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 Kind regards, Marco Schmidt Manager Registration Services RIPE NCC
Gert Doering -- NetMaster
In message <301e0ef8-ed15-67d3-d390-7bea8571c7cb@ripe.net>, Marco Schmidt <mschmidt@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 created: 2022-06-24T06:46:34Z 46.21.16.0/21 created: 2022-06-24T06:46:34Z 46.21.28.0/22 created: 2022-06-24T06:46:34Z 77.220.64.0/19 created: 2022-06-23T09:56:04Z 185.155.176.0/22 created: 2022-06-23T09:56:04Z 185.155.184.0/22 created: 2022-06-24T06:46:34Z 193.221.216.0/23 created: 2022-06-24T06:46:33Z 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.
On Aug 15, 2022, at 11:19, Ronald F. Guilmette <rfg@tristatelogic.com> wrote: In message <301e0ef8-ed15-67d3-d390-7bea8571c7cb@ripe.net>, Marco Schmidt <mschmidt@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 created: 2022-06-24T06:46:34Z 46.21.16.0/21 created: 2022-06-24T06:46:34Z 46.21.28.0/22 created: 2022-06-24T06:46:34Z 77.220.64.0/19 created: 2022-06-23T09:56:04Z 185.155.176.0/22 created: 2022-06-23T09:56:04Z 185.155.184.0/22 created: 2022-06-24T06:46:34Z 193.221.216.0/23 created: 2022-06-24T06:46:33Z 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.
There is, those are transfers, check them here https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran...
hi, On Mon, Aug 15, 2022 at 01:41 Bogdan Rotariu <bogdan@rotariu.ro> wrote:
On Aug 15, 2022, at 11:19, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
In message <301e0ef8-ed15-67d3-d390-7bea8571c7cb@ripe.net>,
Marco Schmidt <mschmidt@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 created: 2022-06-24T06:46:34Z 46.21.16.0/21 created: 2022-06-24T06:46:34Z 46.21.28.0/22 created: 2022-06-24T06:46:34Z 77.220.64.0/19 created: 2022-06-23T09:56:04Z 185.155.176.0/22 created: 2022-06-23T09:56:04Z 185.155.184.0/22 created: 2022-06-24T06:46:34Z 193.221.216.0/23 created: 2022-06-24T06:46:33Z 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/tran... --
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.
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@rotariu.ro> wrote:
On Aug 15, 2022, at 11:19, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
In message <301e0ef8-ed15-67d3-d390-7bea8571c7cb@ripe.net>, Marco Schmidt <mschmidt@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/tran... --
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.
In message <19f8c8b6-0590-8903-0e9e-ec6638d1f442@ripe.net>, Marco Schmidt <mschmidt@ripe.net> wrote:
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.
Please elaborate. How does it do that exactly? For example, what does this value tell us about how the block was received? CH-AS5398-20191016
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.
In other words you are saying that 193.222.104.0/23 wasw purchased, correct?
I hope this helps answer your question.
It may, once I understand clearly everything you just said. Regards, rfg
Dear Ronald, On 15/08/2022 12:45, Ronald F. Guilmette wrote:
In message <19f8c8b6-0590-8903-0e9e-ec6638d1f442@ripe.net>, Marco Schmidt <mschmidt@ripe.net> wrote:
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. Please elaborate. How does it do that exactly? For example, what does this value tell us about how the block was received?
CH-AS5398-20191016 The last part of the netname is the date when the resource was allocated by the RIPE NCC, in this example 16 October 2019.
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. In other words you are saying that 193.222.104.0/23 wasw purchased, correct?
If the dates differ, this only indicates that a change of the resource holder took place, either for this range directly or another part of a previously larger address block. Such change can be a policy transfer, a company merger or a network acquisition. The RIPE NCC is not involved in the financial details of such update. Kind regards, Marco Schmidt RIPE NCC
I hope this helps answer your question. It may, once I understand clearly everything you just said.
Regards, rfg
Hi Ronald, As Bogdan mentioned, these seem to be a bunch of intra-RIR transfers. I'm not sure if it has ever been explained why (if it has my apologies for the obliviousness), but any transfer of v4 or v6 seems to "re-create" the RIPE Database object, thus the very recent date. I noticed this recently on an allocation we split up and transferred a part from, the date was set to the day of the transfer on both the old and the new object. If you take a look at the alloclist file[1], or the delegated-latest[2], you can see the original allocation date by the RIPE NCC to the original receiver. RIPEstat also shows a transfer has taken place, which is easy for a quick check. Though, the widget does not show WHO transferred said objects. Cheers, Tyrasuki https://tyrasuki.be F587 F089 1655 A5E0 --- [1]: https://ftp.ripe.net/ripe/stats/membership/alloclist.txt [2]: https://ftp.ripe.net/ripe/stats/delegated-ripencc-latest On 8/15/2022 10:41 AM, Bogdan Rotariu wrote:
On Aug 15, 2022, at 11:19, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
In message <301e0ef8-ed15-67d3-d390-7bea8571c7cb@ripe.net>, Marco Schmidt <mschmidt@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 created: 2022-06-24T06:46:34Z 46.21.16.0/21 created: 2022-06-24T06:46:34Z 46.21.28.0/22 created: 2022-06-24T06:46:34Z 77.220.64.0/19 created: 2022-06-23T09:56:04Z 185.155.176.0/22 created: 2022-06-23T09:56:04Z 185.155.184.0/22 created: 2022-06-24T06:46:34Z 193.221.216.0/23 created: 2022-06-24T06:46:33Z 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.
There is, those are transfers, check them here https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran... <https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/within-ripe-ncc-service-region/ipv4-transfer-statistics>
In message <6449f927-d16e-9938-f2c2-bce8102c2c31@tyrasuki.be>, Tyrasuki <me@tyrasuki.be> wrote:
As Bogdan mentioned, these seem to be a bunch of intra-RIR transfers.
I'm sorry, but I'm not seeing that. What makes you think that this was other than a set of simple intra-company transfers (and NOT a set of inter-RIR transfers)? I just checked the biggest block (77.220.64.0/19) at the URL that people here gave me, and it appears that this came from a company called "Internet One SRL" which appears to be located in Romania. Last time I looked, Romania was still within the RIPE region, so I wonder how you concluded that this was an inter-RIR transfer.
I'm not sure if it has ever been explained why (if it has my apologies for the obliviousness), but any transfer of v4 or v6 seems to "re-create" the RIPE Database object, thus the very recent date.
Worse, I can't get full history (from WHOIS) on the blocks. But I think this (WHOIS full history) problem/issue was discussed awhile back on the DB Working group mailing list, and I think the decision was reached to try to make available fully histories of blocks, even across inter-company transfers. But it seems like maybe that didn't quite get fully implemented yet. Regards, rfg
Intra = within the region Inter = between regions On 8/15/22 11:10 AM, Ronald F. Guilmette wrote:
In message <6449f927-d16e-9938-f2c2-bce8102c2c31@tyrasuki.be>, Tyrasuki <me@tyrasuki.be> wrote:
As Bogdan mentioned, these seem to be a bunch of intra-RIR transfers. I'm sorry, but I'm not seeing that. What makes you think that this was other than a set of***simple intra-company transfers (and NOT a set of inter-RIR transfers)? * I just checked the biggest block (77.220.64.0/19) at the URL that people here gave me, and it appears that this came from a company called "Internet One SRL" which appears to be located in Romania.
Last time I looked, Romania was still within the RIPE region, so I wonder how you concluded that this was an inter-RIR transfer.
I'm not sure if it has ever been explained why (if it has my apologies for the obliviousness), but any transfer of v4 or v6 seems to "re-create" the RIPE Database object, thus the very recent date. Worse, I can't get full history (from WHOIS) on the blocks.
But I think this (WHOIS full history) problem/issue was discussed awhile back on the DB Working group mailing list, and I think the decision was reached to try to make available fully histories of blocks, even across inter-company transfers.
But it seems like maybe that didn't quite get fully implemented yet.
Regards, rfg
-- Mark James ELKINS - Posix Systems - (South) Africa mje@posix.co.za Tel: +27.826010496 <tel:+27826010496> For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za <https://ftth.posix.co.za> Posix SystemsVCARD for MJ Elkins
Hi, I’m out of office till 22 August. Any RIPE Labs related queries can be sent to labs@ripe.net and one of my colleagues will get back to you. Cheers, Alun On 15 Aug 2022, at 10:53, Tyrasuki via address-policy-wg <address-policy-wg@ripe.net> wrote:
Hi Ronald,
As Bogdan mentioned, these seem to be a bunch of intra-RIR transfers.
I'm not sure if it has ever been explained why (if it has my apologies for the obliviousness), but any transfer of v4 or v6 seems to "re-create" the RIPE Database object, thus the very recent date.
I noticed this recently on an allocation we split up and transferred a part from, the date was set to the day of the transfer on both the old and the new object.
If you take a look at the alloclist file[1], or the delegated-latest[2], you can see the original allocation date by the RIPE NCC to the original receiver.
RIPEstat also shows a transfer has taken place, which is easy for a quick check. Though, the widget does not show WHO transferred said objects.
Cheers, Tyrasuki
https://tyrasuki.be F587 F089 1655 A5E0
--- [1]: https://ftp.ripe.net/ripe/stats/membership/alloclist.txt [2]: https://ftp.ripe.net/ripe/stats/delegated-ripencc-latest
On 8/15/2022 10:41 AM, Bogdan Rotariu wrote: On Aug 15, 2022, at 11:19, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
In message <301e0ef8-ed15-67d3-d390-7bea8571c7cb@ripe.net>, Marco Schmidt <mschmidt@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 created: 2022-06-24T06:46:34Z 46.21.16.0/21 created: 2022-06-24T06:46:34Z 46.21.28.0/22 created: 2022-06-24T06:46:34Z 77.220.64.0/19 created: 2022-06-23T09:56:04Z 185.155.176.0/22 created: 2022-06-23T09:56:04Z 185.155.184.0/22 created: 2022-06-24T06:46:34Z 193.221.216.0/23 created: 2022-06-24T06:46:33Z 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. There is, those are transfers, check them here https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran... <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
In message <FB341C02-4E26-43F6-A2B0-F14668717AD1@rotariu.ro>, Bogdan Rotariu <bogdan@rotariu.ro> wrote:
ORG-AS976-RIPE:
31.44.32.0/20 created: 2022-06-24T06:46:34Z 46.21.16.0/21 created: 2022-06-24T06:46:34Z 46.21.28.0/22 created: 2022-06-24T06:46:34Z 77.220.64.0/19 created: 2022-06-23T09:56:04Z 185.155.176.0/22 created: 2022-06-23T09:56:04Z 185.155.184.0/22 created: 2022-06-24T06:46:34Z 193.221.216.0/23 created: 2022-06-24T06:46:33Z 193.222.104.0/23 created: 2022-06-24T06:46:33Z
There is, those are transfers, check them here https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran...
So somebody just bought all of this stuff in June? Regards, rfg
participants (8)
-
Alun Davies -
Bogdan Rotariu -
Elvis Daniel Velea -
Gert Doering -
Marco Schmidt -
Mark Elkins -
Ronald F. Guilmette -
Tyrasuki