Hi Denis,
This is where the implications get interesting. Each of the objects in the example I gave is in itself individually aggregatable. There is nothing in your policy proposal that says an aggregate must cover multiple assignments to multiple End Users. You say: "In case of an audit, the LIR must be able to present statistics showing the number of individual assignments made in all objects with a status of 'AGGREGATED-BY-LIR."
Yes, this requirement is copied verbatim from the IPv6 policy.
So the number 1 is valid. You don't require the block size of the individual assignments to be specified in the audit. So that 1 could be the same size as the aggregate or a single IP address.
Correct, just as in the IPv6 policy. Though I fail to see the point in "aggregating" only a single assignment.
For every one of the assignments in this example allocation you can change the status to AGGREGATED-BY-LIR and remove all the identification and contact information for the actual end user. Your proposal has dropped the requirement: "When an End User has a network using public address space this must be registered separately with the contact details of the End User."
Correct, as we are copying the wording from the IPv6 policy, which does not contain that specific sentence.
It is not specified in the current policy if those contact details must be the tech-c/admin-c or the address of the company. So the objects in my example comply with the current policy.
We might have to agree to disagree on this one, but to me it seems clear that the mandatory contact details referred to by policy *are* admin-c and tech-c, nothing more, nothing less. This follows from the inetnum object template, where admin-c/tech-c are the only mandatory attributes that relates to contact information. In your examples, the LIR included street addresses of the assignees in the unstructured descr fields. This is essentially useless for trying to get in touch with someone about solving operational problems - I mean, when was the last time you physically travelled to someone's office or sent them snailmail in order to troubleshoot a network issue? When reading the requirement to register the End User's contact details with the goal of registration stated in section 3.0.4 of the policy in mind - «to ensure uniqueness and **to provide information for Internet troubleshooting at all levels**» (emphasis mine) - it seems clear to me that the mandatory contact information referred to by policy must be more immediate and long-distance forms of contact, such as 'phone' in a person object or 'e-mail' from a role object. These are mandatory attributes, and can be used as tech-c/admin-c in inetnum objects, which are also mandatory. Thus, the registration goal and requirement in the policy and the chain of mandatory attributes in the RIPE database ties together very nicely in a structured, machine-readable and logical way: inet[6]num→tech/admin-c→person→phone, alternatively: inet[6]num→tech/admin-c→role→e-mail.
With the current policy only when an End User is a natural person can you replace the contact details with that of the LIR. With your policy ANY or even ALL End Users can replace their contact details with that of the LIR by changing the status to AGGREGATED-BY-LIR. In theory every ASSIGNED PA object in the RIPE Database can become an AGGREGATED-BY-LIR object with only LIR contact details. Now that won't happen as a lot of responsible End Users will want their contact details in the database for network problem resolution.
Well, it depends. Is the LIR' NOC the correct point of contact for network problem resolution, i.e., is there already a single value used for tech-c and admin-c across a set of adjacent assignments? If yes, then the LIR could aggregate those objects. If no, e.g., if the End Users operate their own NOCs, then those objects can not be aggregated. This is of course all the same as in the IPv6 policy today.
But we all know there are LIRs who provide services to spammers and othe abusers, knowingly or otherwise. You can be sure these End Users' details will disappear from the database.
Are you certain that updated and working contact information of spammers and abusers are correctly registered in the RIPE database today? (Rhetorical question, no answer sought.)
Thus the LIR in question already has a 'short cut' option available to them, should they feel managing the assignees' address information in the RIPE database is too burdensome - they can simply chose to not include that information in the first place.
I want to emphasise that this policy proposal does not grant them this option, it is already there today.
This again is misleading. The LIR CANNOT do what you suggest with the current policy. The current policy says: "When an End User has a network using public address space this must be registered separately with the contact details of the End User." As I said above, It is not specified if those contact details must be the tech-c/admin-c or the address of the company. In the example I gave the admin-c/tech-c are the details of the LIR. But they comply with the policy by including the address of the companies. They are the End User contact details. If they chose to remove this optional information then they no longer comply with current policy. But you drop this policy condition. Therefore with your policy proposal you allow them to remove this optional info and still comply with the policy. Netname is just a string of LIR defined characters and does not need to be unique. So they can all be set to the same string. Country is also LIR defined and generally meaningless so they can all be set to the same pointless value. So your proposal allows this LIR to make all these assignments 'the same' and replace them all with a single AGGREGATED-BY-LIR object. This is a very significant change to the public registry. With this proposal ANY set of data can be anonymised. There is no longer any requirement for End Users running public networks to be identifiable or contactable.
This IS an option granted by this proposal that is NOT there today.
Here are three randomly selected assignments that demonstrates how this option is there today: inetnum: 213.174.234.0 - 213.174.234.31 inetnum: 62.213.192.208 - 62.213.192.223 inetnum: 213.162.203.0 - 213.162.203.255 All of them have netnames à la «LIRNAME-CUSTOMER-NUMBER-1234», strongly suggesting this is a downstream assignment to a specific customer and not made to the LIRs own infrastructure or DHCP pools, and the only thing resembling contact information are the admin-c and tech-c attributes, which refer to the LIR itself.
I can see a follow up question to the DB-WG, "How do I aggregate a whole allocation?" Which may well replace the current question, "How do I assign a whole allocation?" The consequence of this proposal is the same as a previous suggestion to make assignments optional. Both allow for the mass anonymisation of End Users.
This possibility, as demonstrated above, is already there today - both in the IPv4 and IPv6 policies.
Are you suggesting that abusers generally work with single IP addresses, rather than cycling through a block of addresses?
Not really, but I would rather suggest that spammers and abusers are not likely to faithfully and correctly publish their assignments and contact information in the RIPE database in the first place. If you are building your anti-spam/abuse methodology on the assumption that otherwise bad actors are behaving as good actors when it comes to maintaining the RIPE database, I don't think that methodology would work very well.
From the proposal: «As of August 2023, there were 19,221 PA allocations without any child PA assignments held by 10,052 LIRs». What do you do, exactly, if you start receiving abusive traffic from any of these ranges?
Note that this is not really much different than what you have to do today for abuse coming from customer assignments that are «registered as part of the service provider's internal infrastructure», cf. ripe-708 section 6.2.
Just a note that ripe-708 was the address policy of 2018. There have been 5 updates since then.
My mistake, a Google-snafu there. That particular sentence is unchanged as of ripe-804, though, so the points stands.
That said, AGGREGATED-BY-LIR would here have made it clear that the abusive address is indeed assigned to a downstream customer and is not part of the service provider's internal infrastructure.
Take a look at these two examples of real data: 82.116.118.0 - 82.116.119.255 88.149.40.0 - 88.149.40.255
One is listed in a remarks as "dynamic DSL address pool" and the other as "DHCP Customers". They are already aggregated. What do we gain by changing the status on these objects from ASSIGNED PA to AGGREGATED-BY-LIR? Suppose one LIR changes the status and the other does not. As you said it is optional. Nothing changes for either LIR in terms of what they must create, modify or delete in the database. They are already aggregates. What can a casual viewer of this data in the database deduce from these two new objects with different status values? Without parsing the remarks they cannot deduce anything. Either could be a single End User or multiple End Users. The status doesn't distinguish either option. Why do we need a new status value? We end up with two values that are completely interchangeable with no way to interpret their different meanings without parsing remarks.
If you are a machine, and not a human, free-text remarks such as "dynamic DSL address pool" are essentially meaningless. They are optional too, the LIRs could easily have omitted them. If they had, it would have impossible to tell whether those addresses had been assigned to one or more downstream customers or if they had been assigned to the LIR itself. Furthermore, there is a chance that at least one of the customers in those pools are using his or her assigned address for some purpose like running a MineCraft server, let's say. If, so, that single IP customer assignment is no longer «used solely for the connection of an End User to a service provider» and would need to registered as a separate assignment. Everybody ignores that requirement, of course, because otherwise the result would have been complete and utter mayhem. Nevertheless, it is a de jure policy violation. AGGREGATED-BY-LIR solves that.
The bottom line is that this new status value adds no new benefit, but can be seriously mis-used to cause considerable damage to the RIPE Database as a public registry. It WILL be misused by those operating public networks who wish to keep their details hidden from public view.
We do not propose to do anything that hasn't already been done in the IPv6 policy and database for years and years and years, and the sky has not fallen. The End Users that want anonymity for whatever reason have ample opportunity to remain anonymous today, even while staying policy compliant (not that bad actors would care about that). Finally, there *is* a benefit to this proposal, an actual itch we're trying to scratch, specifically where there are many identical small assignments being made and removed in a rapid and automated fashion, to End Users that don't operate their own NOCs. I've mentioned the cloud VPS provider example before here. Tore