On Tue, 2023-05-16 at 02:08 +0200, denis walker wrote: > What is the real reason for this push to dump assignments? I just > don't buy these arguments.
Hi Denis, The reason / rationale is as stated. There is no "real" reason apart from that. Of course, the formal proposal will elaborate further. I do not quite understand what you mean by "dumping assignments". To be clear, our proposal would not invalidate any existing assignments, nor mandate that LIRs change their current practices, whatever they may be. > I know it is an odd thing to consider in this industry, but this is > what computers are good at doing. It is 2023. Everyone is talking > about how AI is going to take control of humanity soon. But the > internet industry cannot automate the syncing of your internal IPAM > with the RIPE Database? I don't think we need to worry about AI yet. > > (...) > > > We don't need to take away reasons, we just need to automate and do > it properly. Requiring LIRs to create automated systems that export their entire IPAM contents to the RIPE database is out of scope for this proposal. However, I would note that this proposal would not in any way prevent LIRs from building and using such systems, should they prefer to do so. > > 3. Policy 6.3 “Network Infrastructure and End User Networks” can be > > interpreted differently for what the right use case is. > > I don't see anything in 6.2 that is open to interpretation or > relevant to the case for dumping assignments. The current policy is clear enough, it is the actual implementation of it that is currently somewhat out of sync. In particular, it says that «IP addresses used ***solely*** for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure». (Emphasis mine.) This mechanism is widely used in IPv4 in a similar way as AGGREGATED- BY-LIR is in IPv6, i.e., by aggregating multiple customer assignments into a single database object. However, any use of the IP address by the customer beyond the «connection to the service provider» purpose, would make this mechanism unavailable to the LIR. Consider for example if a home broadband subscriber sets up a public Minecraft server on their home LAN and exposes it on the public IPv4 address using port forwarding functionality in their home gateway. The policy does strictly speaking mandate a separate assignment to be registered for that single IPv4 address, but this requirement is widely ignored (quite understandably). IPv6's AGGREGATED-BY-LIR, on the other hand, does not have this issue. > > Including the feedback from the previous policy proposal, we are > > thinking about introducing AGGREGATED-BY-LIR status just as in the > > IPv6 policy. In this way, we can aggregate multiple assignments > > into one AGGREGATED-BY-LIR assignment which we think would result > > in improving the above-mentioned points. > > I think it is a bad idea to hide the users of blocks of IP addresses > from the public in a public registry database. This proposal is not about "hiding" anything, at least not something that is not already non-public information (e.g., due to GDPR requirements). This is about aggregating bulk assignments made to multiple end users where the LIRs themselves, not the end users, are the point of contact for any technical queries from third parties, such as abuse reports or information requests from law enforcement agencies. Some typical examples are dynamic pools assigned to home broadband subscribers, cloud VPS instances, and so on. Our view is that the AGGREGATED-BY-LIR status found in the IPv6 policy caters to this use case in a more appropriate way than the IPv4 policy does, and that by "backporting" the mechanism we end up with an improved IPv4 policy and, as an additional bonus, more unified IPvX policies. > With a modern approach to creating the data in the database, there is > no need for AGGREGATED-BY-LIR for either IPv4 or IPv6. Removal of the AGGREGATED-BY-LIR mechanism from the IPv6 policy, and the IPv4 bulk assignment mechanism in 6.2 of the IPv4 policy for that matter, is out of scope for this proposal. However, I will note that it appears that quite a lot (likely the majority) of individual IPv6 assignments made are covered by AGGREGATED-BY-LIR inet6num objects, which suggests to me that the community does indeed see the need for a mechanism that allows them to register bulk assignments as aggregated objects in the database. Tore -- 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
