[address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hi Tore,

Thanks for explaining this particular use case.

Reading the proposed New Policy Text, it provides the LIR with an adminsitrative choice. Whilst I understand this choice, the rantionale behind the proposal is to find a reasonable way to fill the gap for the Provider Allocations not registered for the specific exception documented: "IP addresses used solely for the connection of an End User to a service provider... can be registered as part of the service provider's internal infrastructure".

Given the choice provided in the proposal, it seems to me like I could go the other way with this and aggregate everything? The end user allocation size distinction no longer looks to apply and I could interprete that the "purpose" of the whole aggregate is consistent (they are all used to reach "stuff") and therefore chose to not register any end user assigned /29s, 28s, /27s etc. 

Does this not contradict other purposes / objectives of the registry, including the principles of registering public networks or am I missing something?

Many thanks,
Brian 

-----Original Message-----
From: address-policy-wg <address-policy-wg-bounces at ripe.net> On Behalf Of Tore Anderson
Sent: Monday, September 4, 2023 12:22 PM
To: Andrii Syrovatko <andrey_syrovatko at trifle.net>; address-policy-wg at ripe.net; adallara at ripe.net
Cc: APEX NCC ORG <registry at apex.dp.ua>; Trifle NOC <noc at trifle.net>
Subject: Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

* APEX NCC ORG

> Hello, Team!
> I read the offer provided:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ripe.net%2Fparticipate%2Fpolicies%2Fproposals%2F2023-04&data=05%7C01%7
> Cbrian.storey%40gamma.co.uk%7C3a23e9f95d904f83274a08dbad391d6b%7C743a5
> d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C638294233043320645%7CUnknown%7CT
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C3000%7C%7C%7C&sdata=9dEJGnNWdlapbyyzjM5qgJvn%2BB6G%2BGp6jjmu
> %2FcDzZPY%3D&reserved=0
> three times.
> However, I still don't understand the real reason for introducing the 
> AGGREGATED-BY-LIR status The text of the proposal contains only 
> general provisions.
> Can you provide a more detailed description and examples?

Hi Andrii!

There are several possible examples, but let me give you just one:

Let's say you're a small cloud VPS provider in the business of leasing out virtual machines to small businesses and private individuals. Your cloud management software dynamically assigns IPv4 addresses out of
192.0.2.0/24 to customers, so you have for example:

192.0.2.1/32 = assigned to Alice's first VM - used for a web server
192.0.2.2/32 = assigned to Bob - used for a Minecraft server
192.0.2.3/32 = assigned to Bob's hair salon business = web server
192.0.2.4/32 = assigned to Alice's second VM - mail server

…and so on.

Current policy requires you to register four individual INETNUM assignments of size /32 for the above four virtual machines.

However, due to the GDPR requirements, you usually cannot put Alice's and Bob's names or contact info into the RIPE database, so instead you typically substitute your own (this is allowed by policy).

That means you have now four individual INETNUMs with identical contact information (your own). You need to add or remove these /32 INETNUMs as customer VMs come and go. You can automate this, but it is a pointless exercise in any case.

To avoid this, we propose allowing you to create a single INETNUM that covers the entire 192.0.2.0 - 192.0.2.255 range, just like you can already do with any IPv6 assignments made to the same VMs. This aggregated object will cover all customer VMs in your cloud infrastructure, present and future, and makes it so that you don't have to send a RIPE database update every time a customer VM is provisioned or discontinued.

Tore

-- 

To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Faddress-policy-wg&data=05%7C01%7Cbrian.storey%40gamma.co.uk%7C3a23e9f95d904f83274a08dbad391d6b%7C743a5d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C638294233043320645%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jtDVwO2J07Os87Tt9U%2BLQ0eg2T%2FDFsDrknEX9fBy41k%3D&reserved=0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4577 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20230911/d0276064/attachment.p7s>