From leo at vegoda.org Fri Aug 5 15:39:36 2022 From: leo at vegoda.org (Leo Vegoda) Date: Fri, 5 Aug 2022 06:39:36 -0700 Subject: [address-policy-wg] Address Policy WG Minutes from RIPE 84 Message-ID: Dear WG, The RIPE NCC has now published draft minutes of our session at RIPE 84. Please write to this list or inform the co-chairs of any issues or corrections. https://www.ripe.net/participate/ripe/wg/active-wg/ap/minutes/ripe-84-address-policy-working-group-minutes Video recordings and transcripts are available on https://ripe84.ripe.net Many thanks to Matt Parker for taking the minutes. Kind regards, Leo Vegoda for the Address Policy WG co-chairs From rfg at tristatelogic.com Mon Aug 15 09:10:49 2022 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 15 Aug 2022 00:10:49 -0700 Subject: [address-policy-wg] Maximum size for current IPv4 allocations Message-ID: <334.1660547449@segfault.tristatelogic.com> 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. From gert at space.net Mon Aug 15 09:16:16 2022 From: gert at space.net (Gert Doering) Date: Mon, 15 Aug 2022 09:16:16 +0200 Subject: [address-policy-wg] Maximum size for current IPv4 allocations In-Reply-To: <334.1660547449@segfault.tristatelogic.com> References: <334.1660547449@segfault.tristatelogic.com> Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From rfg at tristatelogic.com Mon Aug 15 09:27:06 2022 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 15 Aug 2022 00:27:06 -0700 Subject: [address-policy-wg] Maximum size for current IPv4 allocations In-Reply-To: Message-ID: <489.1660548426@segfault.tristatelogic.com> In message , Gert Doering 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? From mschmidt at ripe.net Mon Aug 15 09:30:37 2022 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 15 Aug 2022 09:30:37 +0200 Subject: [address-policy-wg] Maximum size for current IPv4 allocations In-Reply-To: References: <334.1660547449@segfault.tristatelogic.com> Message-ID: <301e0ef8-ed15-67d3-d390-7bea8571c7cb@ripe.net> 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 > From rfg at tristatelogic.com Mon Aug 15 10:18:44 2022 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 15 Aug 2022 01:18:44 -0700 Subject: [address-policy-wg] Maximum size for current IPv4 allocations In-Reply-To: <301e0ef8-ed15-67d3-d390-7bea8571c7cb@ripe.net> Message-ID: <870.1660551524@segfault.tristatelogic.com> In message <301e0ef8-ed15-67d3-d390-7bea8571c7cb at ripe.net>, Marco Schmidt 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. From bogdan at rotariu.ro Mon Aug 15 10:41:30 2022 From: bogdan at rotariu.ro (Bogdan Rotariu) Date: Mon, 15 Aug 2022 11:41:30 +0300 Subject: [address-policy-wg] Maximum size for current IPv4 allocations In-Reply-To: <870.1660551524@segfault.tristatelogic.com> References: <870.1660551524@segfault.tristatelogic.com> Message-ID: > On Aug 15, 2022, at 11:19, Ronald F. Guilmette wrote: > ?In message <301e0ef8-ed15-67d3-d390-7bea8571c7cb at ripe.net>, > Marco Schmidt 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/transfer-statistics/within-ripe-ncc-service-region/ipv4-transfer-statistics -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis at v4escrow.net Mon Aug 15 10:45:38 2022 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Mon, 15 Aug 2022 01:45:38 -0700 Subject: [address-policy-wg] Maximum size for current IPv4 allocations In-Reply-To: References: <870.1660551524@segfault.tristatelogic.com> Message-ID: hi, On Mon, Aug 15, 2022 at 01:41 Bogdan Rotariu wrote: > > On Aug 15, 2022, at 11:19, Ronald F. Guilmette > wrote: > > ?In message <301e0ef8-ed15-67d3-d390-7bea8571c7cb at ripe.net>, > > Marco Schmidt 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/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: From me at tyrasuki.be Mon Aug 15 10:53:09 2022 From: me at tyrasuki.be (Tyrasuki) Date: Mon, 15 Aug 2022 10:53:09 +0200 Subject: [address-policy-wg] Maximum size for current IPv4 allocations In-Reply-To: References: <870.1660551524@segfault.tristatelogic.com> Message-ID: <6449f927-d16e-9938-f2c2-bce8102c2c31@tyrasuki.be> 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 >> wrote: >> >> ?In message <301e0ef8-ed15-67d3-d390-7bea8571c7cb at ripe.net>, >> Marco Schmidt 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/transfer-statistics/within-ripe-ncc-service-region/ipv4-transfer-statistics > > From rfg at tristatelogic.com Mon Aug 15 11:01:16 2022 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 15 Aug 2022 02:01:16 -0700 Subject: [address-policy-wg] Maximum size for current IPv4 allocations In-Reply-To: Message-ID: <1200.1660554076@segfault.tristatelogic.com> In message , Bogdan Rotariu 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/transfer-statistics/within-ripe-ncc-service-region/ipv4-transfer-statistics So somebody just bought all of this stuff in June? Regards, rfg From rfg at tristatelogic.com Mon Aug 15 11:10:24 2022 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 15 Aug 2022 02:10:24 -0700 Subject: [address-policy-wg] Maximum size for current IPv4 allocations In-Reply-To: <6449f927-d16e-9938-f2c2-bce8102c2c31@tyrasuki.be> Message-ID: <1269.1660554624@segfault.tristatelogic.com> In message <6449f927-d16e-9938-f2c2-bce8102c2c31 at tyrasuki.be>, Tyrasuki 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 From mje at posix.co.za Mon Aug 15 11:29:52 2022 From: mje at posix.co.za (Mark Elkins) Date: Mon, 15 Aug 2022 11:29:52 +0200 Subject: [address-policy-wg] Maximum size for current IPv4 allocations In-Reply-To: <1269.1660554624@segfault.tristatelogic.com> References: <1269.1660554624@segfault.tristatelogic.com> Message-ID: <376da169-d330-1860-4cb4-0a1c63b29c87@posix.co.za> 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 at tyrasuki.be>, > Tyrasuki 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 at posix.co.za?????? Tel: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za Posix SystemsVCARD for MJ Elkins -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: abessive_logo.jpg Type: image/jpeg Size: 6410 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: QR-MJElkins.png Type: image/png Size: 2163 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xB6FA15470B82C101.asc Type: application/pgp-keys Size: 627 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From mschmidt at ripe.net Mon Aug 15 11:55:24 2022 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 15 Aug 2022 11:55:24 +0200 Subject: [address-policy-wg] Maximum size for current IPv4 allocations In-Reply-To: References: <870.1660551524@segfault.tristatelogic.com> Message-ID: <19f8c8b6-0590-8903-0e9e-ec6638d1f442@ripe.net> 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 wrote: > > >> On Aug 15, 2022, at 11:19, Ronald F. Guilmette >> wrote: >> >> ?In message <301e0ef8-ed15-67d3-d390-7bea8571c7cb at ripe.net>, >> Marco Schmidt 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/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: From rfg at tristatelogic.com Mon Aug 15 12:45:29 2022 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 15 Aug 2022 03:45:29 -0700 Subject: [address-policy-wg] Maximum size for current IPv4 allocations In-Reply-To: <19f8c8b6-0590-8903-0e9e-ec6638d1f442@ripe.net> Message-ID: <2097.1660560329@segfault.tristatelogic.com> In message <19f8c8b6-0590-8903-0e9e-ec6638d1f442 at ripe.net>, Marco Schmidt 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 From mschmidt at ripe.net Mon Aug 15 15:57:17 2022 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 15 Aug 2022 15:57:17 +0200 Subject: [address-policy-wg] Maximum size for current IPv4 allocations In-Reply-To: <2097.1660560329@segfault.tristatelogic.com> References: <2097.1660560329@segfault.tristatelogic.com> Message-ID: Dear Ronald, On 15/08/2022 12:45, Ronald F. Guilmette wrote: > In message <19f8c8b6-0590-8903-0e9e-ec6638d1f442 at ripe.net>, > Marco Schmidt 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 > From adavies at ripe.net Mon Aug 22 07:50:48 2022 From: adavies at ripe.net (Alun Davies) Date: Mon, 22 Aug 2022 07:50:48 +0200 Subject: [address-policy-wg] Maximum size for current IPv4 allocations In-Reply-To: <6449f927-d16e-9938-f2c2-bce8102c2c31@tyrasuki.be> References: <870.1660551524@segfault.tristatelogic.com> <6449f927-d16e-9938-f2c2-bce8102c2c31@tyrasuki.be> Message-ID: <1354E110-22E4-450F-99FF-1552B0D307AC@ripe.net> Hi, I?m out of office till 22 August. Any RIPE Labs related queries can be sent to labs at 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 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 wrote: > > ?In message <301e0ef8-ed15-67d3-d390-7bea8571c7cb at ripe.net>, > Marco Schmidt 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/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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3993 bytes Desc: not available URL: