[address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
- Previous message (by thread): [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
- Next message (by thread): [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
APEX NCC ORG
registry at apex.dp.ua
Tue Sep 5 12:57:52 CEST 2023
Thank you, Tore, for your quick feedback and time! Everything became clear now. Great thought and proposal. Have a good day! Regards, APEX NCC ORG. On 9/4/23 14:21, Tore Anderson wrote: > * APEX NCC ORG > >> Hello, Team! >> I read the offer provided: >> https://www.ripe.net/participate/policies/proposals/2023-04 >> 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 > -- Best wishes, APEX NCC ORG -------------------------------- +38(056)-731-99-11, +38(067)-731-99-11, +38(050)-731-99-11, www.trifle.net
- Previous message (by thread): [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
- Next message (by thread): [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]