Unintended consequences of 2023-04
Colleagues The proposers of 2023-04 assured the community that their motivation was purely to provide aggregation, an optional, minor, inconsequential feature that did not change anything else. So if their minds were focused purely on aggregation, as they have told us and we must accept that without question, then it is reasonable to expect that they put a lot of effort into getting all the details and implications of aggregation correct. Unfortunately they seem to have missed quite a lot of details and consequences. Nothing much was said throughout the whole discussion, nor in the policy proposal itself, about where AGGREGATED-BY-LIR fits in relation to other status values. Nothing was said about the semantics of the RIPE Database. So, as it has not been explicitly stated what types of address space can be created more specific to an aggregation, we can have partitions, sub-allocations and assignments. The assignments can either be directly under the aggregation or from any of the multiple, same level or hierarchical levels of sub-allocations. There can be quite a complex structure of address space more specific to an aggregation, but you may never know because none of it needs to be documented in the RIPE Database. The boundaries of aggregations have not been defined. So they can overlap the boundaries of assignments that do not have objects in the database. If objects are created in the database, the software will not allow any overlapping objects to be created. Objects must be fully contained within the boundaries of a less specific object. But now that objects do not need to be created and they are not of a fixed size, you can do whatever you want. This can be by mistake or intentional. So resource holders can now delete all assignments from an allocation and create two equal sized aggregation objects. If the boundaries of the aggregations overlap the existing assignments it doesn't matter as long as you delete the assignment objects first. Nothing prohibits the creation of sub-allocations within an aggregation. The definition simply says "This address space has been assigned...". It does not state that the assignment must be only one level more specific to the aggregation. So you can create as complex a structure as you wish with multiple sub-allocations in a hierarchy and multiple sub-allocations on the same level within the hierarchy, as long as it ends with an assignment. Then you have satisfied the condition that "This address space has been assigned". You think that is bad...it gets worse... Previously it was not permitted to sub-assign. So you could not create an assignment more specific to an existing assignment. Now this is permitted. The policy says: "The creation of an inetnum object with a status of "ASSIGNED PA" or "ASSIGNED PI" is only possible if there is no less specific or more specific inetnum object with an "ASSIGNED" status." How many times have I said "words matter"!!! And still no one listens. This rule relates to 'objects' in the RIPE Database. It does NOT refer to 'assignments'. Previously it meant the same as an assignment could only exist if there was an assignment 'object' in the database. Now we do not need to create assignment objects in the database. Now you can create hierarchies of multiple assignments as deep as you like, provided no more than one of those assignments is represented in the database by an assignment object. Now some will say that we all 'know what it means' and people will respect the 'spirit' of the policy. IPv4 runout proved that 'spirit' and 'intent' are meaningless. All that matters is what is actually written in the policy and how those words can be literally interpreted. Before runout, the 'intent' was to keep the last bits of IPv4 for new entrants into the industry who intended to provide LIR services and needed that little bit of IPv4 for their infrastructure. That intent was never written into the policy, so it was heavily ignored by everyone. Existing members, financial investors and the RIPE NCC. It turned into a land grab for free address space for profit. So the only thing that matters is the actual words in the policy. Sub-assignment to any level is now permitted. You think that is bad...it gets even worse... We can now have duplicate and overlapping assignments to multiple End Users. There is no requirement for resource holders to have state of the art IPAM systems. A notebook on an office desk is perfectly valid. The same address block could be assigned to multiple End Users. Or two address blocks with an overlap. This could be accidental or intentional. Previously, you had to create the assignment objects in the database for an assignment to be valid. The database software prevented duplicate or overlapping assignments. Now you don't need to create these objects so there is no final check to prevent mistakes or deliberate intent. I don't know much about how internet technical operations work, so I am just going to put some thoughts here. People with more knowledge than I have can consider these scenarios to see if it is a problem. Suppose overlapping assignments are given to two End Users. Suppose they each only use the first few addresses of their respective assignments. Then only one is using the overlapping addresses. Can the LIR know for sure which End User is actually using those overlapping addresses? If not, then if some criminal activity occurs with those addresses, who committed the crime? We have also created a situation now where people with criminal intent can construct hierarchies of data that would hide the End User for a long period of time. Based on a comment by Europol that a court order can take months to get the information, we are looking at possibly delaying the identification of an End User by a couple of years. I won't describe how this can be done here. I don't want to give an instruction manual to criminals. I will explain it to Europol when I see them at RIPE 88. Looking at different parts of the address policy, there are other concerns now. (Yes I know this is the DB-WG and some people will use this to deflect attention away from the message by attacking the messenger. A frequently used tactic. But as I said over there, on the other list, not everything fits perfectly within the bounds of one WG. There is considerable overlap between Database and Address Policy.) 3.0 Goals of the Internet Registry System Because of the issue of duplicate and overlapping assignments mentioned above, two of the 4 goals of the Internet Registry System can no longer be guaranteed. 3.1 Uniqueness: this can no longer be maintained if it is possible to assign the same addresses to multiple End Users. 3.4 Registration: the public registry no longer contains sufficient detail to ensure uniqueness. 4.0 Registration Requirements The level of detail in the RIPE Database is no longer sufficient to ensure uniqueness. "Only allocations and assignments registered in the RIPE Database are considered valid." It is no longer possible to validate assignments that are aggregated. So this requirement no longer has any meaning. 6.3 Validity of an Assignment "An assignment is valid as long as the original criteria on which it was based remain valid and it is properly registered in the RIPE Database." Again because of the lack of detail about assignments within an aggregation is is not possible to determine if an assignment is valid. Although with or without aggregation, I am not sure what this 'validity' means in the real world. Was it to show if an IP address is actually assigned to an End User or maybe it is unused address space that has been hijacked? I have no idea how the 'original criteria' for an assignment is documented in the RIPE Database registry or any changes to that original criteria. Is this another example or registration rules that we have lost the meaning of? You can fix all this wording if you want, but in the end it makes no difference. Previously the policy said all resource holders MUST document assignments in the database. Some chose not to do that, even though it was mandatory. It seems the community has accepted that some resource holders refused to comply with mandatory policy. The RIPE NCC had no power to enforce the policy, other than the nuclear option of closure. One of the arguments for 2023-04 was that if we dilute the registration requirements, maybe a few more resource holders will choose to comply with the policy. If you make new rules about aggregation, some will choose to ignore them. Before we could see who chose to ignore the registration of assignments. Now we will have no idea who is ignoring any new rules. It's all hidden inside the aggregations. The proposers frequently referred to IPv6 and kept telling us how wonderful everything was 'over there'. So I had a look and not everything is rosy in the IPv6 garden. Let's look at some numbers. There are 16,144 /29 allocation objects. 11,246 of them have no more specific objects (i.e. nothing underneath the /29). That is about 70% of all the allocated IPv6 is either not in use or nothing has been registered about usage. If it is not in use, that is a huge stockpile of unused IPv6 address space. Why is it out there at all if no one is using it? If a lot of it is in use, even if it is only one assignment for the LIRs infrastructure, then it is a huge rejection of the registration policy to register nothing in the RIPE Database. So which one is it? A massive stockpile of unused address space or large scale refusal to register anything? There are only 4,898 /29 allocations that have any more specifics. Of these, 370 of them have 2 /30's with status (ALLOCATED-BY-LIR or AGGREGATED-BY-LIR) with *nothing* more specific below the /30's. That is about 7.6% of the registered in use IPv6 that tells us nothing about End Users. Of the 370 objects, 88 of them have two sub-allocations (ALLOCATED-BY-LIR) with no more specifics. So they don't even register any aggregations. I checked a number of these sub-allocation objects randomly and not one of them even had a mnt-lower. So the sub-allocation holder can't even create any aggregations or assignments. I also found a batch of them allocated to the same resource holder where both the /30 objects have been deleted in the last couple of weeks since these numbers were generated. The proposers of 2023-04 claimed IPv6 to be a beacon of perfection and used that to argue that nothing will go wrong with adding aggregation to IPv4. From my brief look at IPv6 all I see is a lot of very dodgy looking data with little information. I suspect that will become the reality for IPv4... So this optional, minor, inconsequential feature seems to have changed quite a lot. Is it worth all this for aggregation? I suspect many people will consider it worth it to make assignments optional. cheers denis co-chair DB-WG ======================================================== DISCLAIMER Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. ========================================================
Dear colleagues, I wanted to address a couple of Denis’s points here. First, for readers who are curious about how the RIPE NCC implements policy for End User contact details in the RIPE Database, I would like to note that I recently posted about this topic on the Address Policy Working Group mailing list. You can read this post at: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2024-May/014046.ht... Additionally, I will soon publish a RIPE Labs article about IPv6 usage. While this article will not look at specific entries in the RIPE Database, it will give some explanation about the low numbers of specific objects in allocations. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC On 08/05/2024 06:53, denis walker via db-wg wrote:
Colleagues
The proposers of 2023-04 assured the community that their motivation was purely to provide aggregation, an optional, minor, inconsequential feature that did not change anything else. So if their minds were focused purely on aggregation, as they have told us and we must accept that without question, then it is reasonable to expect that they put a lot of effort into getting all the details and implications of aggregation correct. Unfortunately they seem to have missed quite a lot of details and consequences.
Nothing much was said throughout the whole discussion, nor in the policy proposal itself, about where AGGREGATED-BY-LIR fits in relation to other status values. Nothing was said about the semantics of the RIPE Database. So, as it has not been explicitly stated what types of address space can be created more specific to an aggregation, we can have partitions, sub-allocations and assignments. The assignments can either be directly under the aggregation or from any of the multiple, same level or hierarchical levels of sub-allocations. There can be quite a complex structure of address space more specific to an aggregation, but you may never know because none of it needs to be documented in the RIPE Database.
The boundaries of aggregations have not been defined. So they can overlap the boundaries of assignments that do not have objects in the database. If objects are created in the database, the software will not allow any overlapping objects to be created. Objects must be fully contained within the boundaries of a less specific object. But now that objects do not need to be created and they are not of a fixed size, you can do whatever you want. This can be by mistake or intentional. So resource holders can now delete all assignments from an allocation and create two equal sized aggregation objects. If the boundaries of the aggregations overlap the existing assignments it doesn't matter as long as you delete the assignment objects first.
Nothing prohibits the creation of sub-allocations within an aggregation. The definition simply says "This address space has been assigned...". It does not state that the assignment must be only one level more specific to the aggregation. So you can create as complex a structure as you wish with multiple sub-allocations in a hierarchy and multiple sub-allocations on the same level within the hierarchy, as long as it ends with an assignment. Then you have satisfied the condition that "This address space has been assigned".
You think that is bad...it gets worse...
Previously it was not permitted to sub-assign. So you could not create an assignment more specific to an existing assignment. Now this is permitted. The policy says: "The creation of an inetnum object with a status of "ASSIGNED PA" or "ASSIGNED PI" is only possible if there is no less specific or more specific inetnum object with an "ASSIGNED" status." How many times have I said "words matter"!!! And still no one listens. This rule relates to 'objects' in the RIPE Database. It does NOT refer to 'assignments'. Previously it meant the same as an assignment could only exist if there was an assignment 'object' in the database. Now we do not need to create assignment objects in the database. Now you can create hierarchies of multiple assignments as deep as you like, provided no more than one of those assignments is represented in the database by an assignment object.
Now some will say that we all 'know what it means' and people will respect the 'spirit' of the policy. IPv4 runout proved that 'spirit' and 'intent' are meaningless. All that matters is what is actually written in the policy and how those words can be literally interpreted. Before runout, the 'intent' was to keep the last bits of IPv4 for new entrants into the industry who intended to provide LIR services and needed that little bit of IPv4 for their infrastructure. That intent was never written into the policy, so it was heavily ignored by everyone. Existing members, financial investors and the RIPE NCC. It turned into a land grab for free address space for profit. So the only thing that matters is the actual words in the policy. Sub-assignment to any level is now permitted.
You think that is bad...it gets even worse...
We can now have duplicate and overlapping assignments to multiple End Users. There is no requirement for resource holders to have state of the art IPAM systems. A notebook on an office desk is perfectly valid. The same address block could be assigned to multiple End Users. Or two address blocks with an overlap. This could be accidental or intentional. Previously, you had to create the assignment objects in the database for an assignment to be valid. The database software prevented duplicate or overlapping assignments. Now you don't need to create these objects so there is no final check to prevent mistakes or deliberate intent.
I don't know much about how internet technical operations work, so I am just going to put some thoughts here. People with more knowledge than I have can consider these scenarios to see if it is a problem. Suppose overlapping assignments are given to two End Users. Suppose they each only use the first few addresses of their respective assignments. Then only one is using the overlapping addresses. Can the LIR know for sure which End User is actually using those overlapping addresses? If not, then if some criminal activity occurs with those addresses, who committed the crime?
We have also created a situation now where people with criminal intent can construct hierarchies of data that would hide the End User for a long period of time. Based on a comment by Europol that a court order can take months to get the information, we are looking at possibly delaying the identification of an End User by a couple of years. I won't describe how this can be done here. I don't want to give an instruction manual to criminals. I will explain it to Europol when I see them at RIPE 88.
Looking at different parts of the address policy, there are other concerns now. (Yes I know this is the DB-WG and some people will use this to deflect attention away from the message by attacking the messenger. A frequently used tactic. But as I said over there, on the other list, not everything fits perfectly within the bounds of one WG. There is considerable overlap between Database and Address Policy.)
3.0 Goals of the Internet Registry System Because of the issue of duplicate and overlapping assignments mentioned above, two of the 4 goals of the Internet Registry System can no longer be guaranteed. 3.1 Uniqueness: this can no longer be maintained if it is possible to assign the same addresses to multiple End Users. 3.4 Registration: the public registry no longer contains sufficient detail to ensure uniqueness.
4.0 Registration Requirements The level of detail in the RIPE Database is no longer sufficient to ensure uniqueness. "Only allocations and assignments registered in the RIPE Database are considered valid." It is no longer possible to validate assignments that are aggregated. So this requirement no longer has any meaning.
6.3 Validity of an Assignment "An assignment is valid as long as the original criteria on which it was based remain valid and it is properly registered in the RIPE Database." Again because of the lack of detail about assignments within an aggregation is is not possible to determine if an assignment is valid. Although with or without aggregation, I am not sure what this 'validity' means in the real world. Was it to show if an IP address is actually assigned to an End User or maybe it is unused address space that has been hijacked? I have no idea how the 'original criteria' for an assignment is documented in the RIPE Database registry or any changes to that original criteria. Is this another example or registration rules that we have lost the meaning of?
You can fix all this wording if you want, but in the end it makes no difference. Previously the policy said all resource holders MUST document assignments in the database. Some chose not to do that, even though it was mandatory. It seems the community has accepted that some resource holders refused to comply with mandatory policy. The RIPE NCC had no power to enforce the policy, other than the nuclear option of closure. One of the arguments for 2023-04 was that if we dilute the registration requirements, maybe a few more resource holders will choose to comply with the policy. If you make new rules about aggregation, some will choose to ignore them. Before we could see who chose to ignore the registration of assignments. Now we will have no idea who is ignoring any new rules. It's all hidden inside the aggregations.
The proposers frequently referred to IPv6 and kept telling us how wonderful everything was 'over there'. So I had a look and not everything is rosy in the IPv6 garden. Let's look at some numbers.
There are 16,144 /29 allocation objects. 11,246 of them have no more specific objects (i.e. nothing underneath the /29). That is about 70% of all the allocated IPv6 is either not in use or nothing has been registered about usage. If it is not in use, that is a huge stockpile of unused IPv6 address space. Why is it out there at all if no one is using it? If a lot of it is in use, even if it is only one assignment for the LIRs infrastructure, then it is a huge rejection of the registration policy to register nothing in the RIPE Database. So which one is it? A massive stockpile of unused address space or large scale refusal to register anything?
There are only 4,898 /29 allocations that have any more specifics. Of these, 370 of them have 2 /30's with status (ALLOCATED-BY-LIR or AGGREGATED-BY-LIR) with *nothing* more specific below the /30's. That is about 7.6% of the registered in use IPv6 that tells us nothing about End Users. Of the 370 objects, 88 of them have two sub-allocations (ALLOCATED-BY-LIR) with no more specifics. So they don't even register any aggregations. I checked a number of these sub-allocation objects randomly and not one of them even had a mnt-lower. So the sub-allocation holder can't even create any aggregations or assignments. I also found a batch of them allocated to the same resource holder where both the /30 objects have been deleted in the last couple of weeks since these numbers were generated.
The proposers of 2023-04 claimed IPv6 to be a beacon of perfection and used that to argue that nothing will go wrong with adding aggregation to IPv4. From my brief look at IPv6 all I see is a lot of very dodgy looking data with little information. I suspect that will become the reality for IPv4...
So this optional, minor, inconsequential feature seems to have changed quite a lot. Is it worth all this for aggregation? I suspect many people will consider it worth it to make assignments optional.
cheers denis co-chair DB-WG
======================================================== DISCLAIMER Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. ========================================================
participants (2)
-
denis walker -
Marco Schmidt