<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 21 Nov 2023 at 10:14, Angela Dall'Ara <<a href="mailto:adallara@ripe.net">adallara@ripe.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Dear colleagues,<br>
<br>
Policy proposal 2023-04, “Add AGGREGATED-BY-LIR status for IPv4 PA <br>
assignments”, is now in the Review Phase.<br>
<br>
The goal of this proposal is to introduce the AGGREGATED-BY-LIR status <br>
for IP</blockquote><div><br></div><div>In general, i'm in favour of the proposal, however, it has raised several questions that I think as a community need to address before we can decide on the correct approach.</div><div><br></div><div>What is the purpose of the registrations on assignments in the RipeDB?</div><div><br></div><div>I always understood them as a way of recording who/what was using a piece of address space so that you can contact the right organisation in the case of an issue. In this case, there were explicit carve-outs for blocks of dynamic address space so that the ISP could be contacted to determine who was using that particular piece of address space at a single time.</div><div><br></div><div>Where address space was allocated on a more permanent basis the contact details of the end site would be added so the organisation who was trying to address the problem had a direct route to contact that end network. From a technical point of view, it was useful as a reference to be able to work out if several IP addresses in a subnet had been allocated to the same customer or if there was a wider issue. This means that having the assignment size fixed for each block and included in the RipeDB entry is rather important.</div><div><br></div><div>Over time we have become more concerned about privacy, contact details being shared, and the maintainability of the database. As such when IPv6 entries were added a specific additional label was created AGGREGATED-BY-LIR that allowed an LIR to say this block of address space is allocated to lots of individual organisations, with a boundary of /X please contact us if you need the contact details for them. Part of the reason for this was it gave the network operator to create long-lasting address allocations that were non-dynamic (as opposed to being static) and force them to register every single end user if they were going to try and be efficient in their allocation of addresses.</div><div><br></div><div>For IPv6 I've not seen any issues raised about the creation of this class of address (I did ask earlier but got zero feedback)</div><div><br></div><div>How does this Policy impact this use?</div><div><br></div><div>This policy appears to take the standard approach for IPv6 and apply it to IPv4 (this is a good thing) it will reduce the number of individual entries in the system (neutral) and hopefully increase the accuracy (a good thing) but at the loss of explicitly including the contact details of the end user site and replacing it with a contact for the LIR (neutral). The last step appears to be the most controversial as it stops people from going directly to the source as it were.</div><div><br></div><div>I think the operational impact here is a potential issue, some LIRs are less than stellar in dealing with requests about things listed in the RipeDB (mostly because of spam) so I can see the concern that some have raised about not being able to get hold of people. However that's not a Ripe issue explicitly but rather a function of the world of capitalism (it's free to send an email, let's send lots of emails, we only need a few people to respond to make money...) </div><div><br></div><div>If we want to fix this problem then maybe we need to add a new capability onto the db that allows authenticated users to contact LIRs about their address space (without using the published contact details) in a way that would allow anti-abuse and LEAs to access the information they need, that is very much not something that needs discussion in the WG because were here to talk about address policy.</div><div><br></div><div>This policy is optional...</div><div><br></div><div>I think people have missed this, from my reading an LIR is not prevented from continuing to put entries without marking them as aggregated so from that point of view if you want to continue to include customer details (and you have their consent) you can still do it.</div><div><br></div><div>So with all that said, I think I still support the policy with the caveat about assignment size mentioned earlier</div><div><br></div><div>Thx</div><div><br></div><div>J</div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><br>James Blessing<br>07989 039 476</div></div>