Checking interest in the community for changing IPv4 assignments policy
Hi Everyone, Now RIPE 86 is around the corner Tore and I would like to check if there is any interest in changing the way of making assignments in the IPv4 policy. At this moment we got 3 major points coming repetitively back from the community. 1. The current policy asks for a lot of repetitive work in making these assignments and it would be nice if, with a policy change, a lot of this repetitive work could be taken away. 2. There is a lot of under and over-assigning in the RIPE DB where a policy change would be beneficial to take some of the reasons away for this. 3. Policy 6.3 “Network Infrastructure and End User Networks” can be interpreted differently for what the right use case is. 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. We would like to check what the community thinks about this plan and if there is enough positive feedback we would like to make a concept proposal from it and present this at RIPE86. Kind regards, Jeroen
Hi Jeroen What is the real reason for this push to dump assignments? I just don't buy these arguments. On Mon, 15 May 2023 at 21:41, Jeroen Lauwers <jlauwers@a2b-internet.com> wrote:
Hi Everyone,
Now RIPE 86 is around the corner Tore and I would like to check if there is any interest in changing the way of making assignments in the IPv4 policy. At this moment we got 3 major points coming repetitively back from the community.
1. The current policy asks for a lot of repetitive work in making these assignments and it would be nice if, with a policy change, a lot of this repetitive work could be taken away.
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.
2. There is a lot of under and over-assigning in the RIPE DB where a policy change would be beneficial to take some of the reasons away for this.
We don't need to take away reasons, we just need to automate and do it properly.
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.
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. With a modern approach to creating the data in the database, there is no need for AGGREGATED-BY-LIR for either IPv4 or IPv6. The RIPE Database is not just for the benefit of resource holders, it is a public registry. I don't care if we have 10m assignments, 20m assignments as IPv6 gathers momentum. With automated data generation it is not a problem to create the correct data and keep it up to date. With a good query interface anyone interested in information about one IP address can easily and quickly find it. The other 20m entries are not a problem. There is also the issue of responsibility and liability. All resource holders (members) have signed an SSA. In that agreement they accept legal responsibility and liability for any and all usage of their allocated address space. With an updated, automated data generation process the RIPE Database will publicly show the correct details for who this responsibility and liability has been delegated to. Anyone pursuing a civil action or any LEA pursuing a criminal action can apply that action to the most specific user of the address space in question. If you hide the details of the end users, they only have the resource holders details. But as the resource holder has legally accepted full responsibility and liability for any and all usage of this address space, I see no reason why an LEA can't take action against the resource holder for any criminal activity involving their allocated address space. Why would they bother to get court orders in multiple languages and legal jurisdictions to find the end user details when they know who has accepted responsibility and liability...the resource holder. If you hide all your end user details, don't be surprised if you are held accountable. I have also heard the argument that many resource holders don't want to publish details of their customers for fear of another resource holder trying to offer them a better deal. In the IPv4 world there is so little address space available there is not much chance of anyone taking your customers away. Your bigger customers may not want to renumber anyway. But if this is a genuine concern to lots of resource holders, why not add a clause to the SSA forbidding members from direct marketing other member's customers? I see no benefits and lots of downsides to dumping assignments. cheers denis co-chair DB-WG
We would like to check what the community thinks about this plan and if there is enough positive feedback we would like to make a concept proposal from it and present this at RIPE86.
Kind regards,
Jeroen --
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
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
participants (3)
-
denis walker -
Jeroen Lauwers -
Tore Anderson