Colleagues During the discussion in the DB-WG session this morning there was a question about sub-allocations. It was asked if it could be possible to identify when resources have been sub-allocated. Hans Petter said it would be possible to give some indication of this. Well, sorry, but NO. Thanks to 2023-04 it is no longer possible to identify sub-allocations. I believe most people were so focused on making assignments optional, no one gave any thought to the consequences of making the simple technical change of adding the status value 'aggregated-by-lir'. As I pointed out in an email some months ago, this has broken the database in many ways. An LIR with an allocation can now simply split that allocation in half and create two objects with status 'aggregated-by-lir'. The boundary between the two aggregations does not even need to match the boundaries of any more specific ranges. There are NO rules about using this status. Absolutely nothing else more specific to these aggregations needs to be documented in the RIPE Database, in any public domain or notified to the RIPE NCC. The LIR may make a sub-allocation of, say, a /24 below one of these aggregations. Or maybe below both of them, crossing the boundary. You will never know what they have done. That sub-allocation holder may sub-allocate again. They can even sub-allocate the whole sub-allocation. Because you do not need to create objects in the database, there is no reason why the whole range cannot be sub-allocated. There are no rules!!! The same block can be sub-allocated 100 times in a long chain of downstream customers. There are no rules!!! Even if there were rules, they would not be enforceable as no one can 'see' what is being done with these addresses. Finally the whole block could be assigned to an End User. This has serious consequences to rights enforcers and law enforcement trying to find that End User. They will never be found. As things stand, because none of the details of this chain of downstream customers is public information, court orders will be needed to identify each layer. In practice this means 100 sequential court orders, each one identifying the next link in the chain. This could zig zag across multiple countries, multiple legal jurisdictions, in multiple languages.The LIR does not know who the End User is. They only know who they sub-allocated to. Only the last link in the sub-allocation chain knows who the End User is. This situation was created by 2023-04 and a lack of attention to detail. We cannot allow this situation to continue. I would suggest we create/amend a policy so that when an LIR is served a court order to identify the (End) User of an IP address, the obligation is on the LIR to internally follow any such chain of sub-allocations, whether it is 1 or 100, to identify the End User. cheers denis ======================================================== 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. ========================================================
Hi, On Thu, Oct 31, 2024 at 01:24:45PM +0100, denis walker wrote:
An LIR with an allocation can now simply split that allocation in half and create two objects with status 'aggregated-by-lir'. The boundary between the two aggregations does not even need to match the boundaries of any more specific ranges. There are NO rules about using this status. Absolutely nothing else more specific to these aggregations needs to be documented in the RIPE Database, in any public domain or notified to the RIPE NCC. The LIR may make a sub-allocation of, say, a /24 below one of these aggregations. Or maybe below both of them, crossing the boundary.
Denis, you are talking nonsense. There are very clear rules what can be under AGGREGATED-BY-LIR (namely, ASSIGNED, with the same contact data). Not SUB-ALLOCATED. Also, this is fully irrelevant. If a LIR refuses to publish relevant information (even if they are obliged to do so by policy), having more or less technical mechanisms in the DB is not going to make any difference. *Also*, please do accept that you were in the rough at consensus building, and stop using every single opportunity you have to complain about 2023-04. Ship has sailed. You are not adding signal to any noise. If you want to contribute in a positive way, join ranks in the planned "have a very close look at Status: values and their use" project (as discussed in the APWG slot, Remco's presentation). thanks, Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Gert On Thu, 31 Oct 2024 at 15:23, Gert Doering <gert@space.net> wrote:
Hi,
On Thu, Oct 31, 2024 at 01:24:45PM +0100, denis walker wrote:
An LIR with an allocation can now simply split that allocation in half and create two objects with status 'aggregated-by-lir'. The boundary between the two aggregations does not even need to match the boundaries of any more specific ranges. There are NO rules about using this status. Absolutely nothing else more specific to these aggregations needs to be documented in the RIPE Database, in any public domain or notified to the RIPE NCC. The LIR may make a sub-allocation of, say, a /24 below one of these aggregations. Or maybe below both of them, crossing the boundary.
Denis, you are talking nonsense. There are very clear rules what can be under AGGREGATED-BY-LIR (namely, ASSIGNED, with the same contact data). Not SUB-ALLOCATED.
Where are these rules? cheers denis
Also, this is fully irrelevant. If a LIR refuses to publish relevant information (even if they are obliged to do so by policy), having more or less technical mechanisms in the DB is not going to make any difference.
*Also*, please do accept that you were in the rough at consensus building, and stop using every single opportunity you have to complain about 2023-04. Ship has sailed. You are not adding signal to any noise.
If you want to contribute in a positive way, join ranks in the planned "have a very close look at Status: values and their use" project (as discussed in the APWG slot, Remco's presentation).
thanks,
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, On Thu, Oct 31, 2024 at 04:59:34PM +0100, denis walker wrote:
On Thu, 31 Oct 2024 at 15:23, Gert Doering <gert@space.net> wrote:
On Thu, Oct 31, 2024 at 01:24:45PM +0100, denis walker wrote:
An LIR with an allocation can now simply split that allocation in half and create two objects with status 'aggregated-by-lir'. The boundary between the two aggregations does not even need to match the boundaries of any more specific ranges. There are NO rules about using this status. Absolutely nothing else more specific to these aggregations needs to be documented in the RIPE Database, in any public domain or notified to the RIPE NCC. The LIR may make a sub-allocation of, say, a /24 below one of these aggregations. Or maybe below both of them, crossing the boundary.
Denis, you are talking nonsense. There are very clear rules what can be under AGGREGATED-BY-LIR (namely, ASSIGNED, with the same contact data). Not SUB-ALLOCATED.
Where are these rules?
The policy proposal that introduced AGGREGATED-BY-LIR was very clear on the circumstances where it can be used. I'm fairly sure you know whether these have made it to policy text, so asking me to go chasing the details would be wasting my time. But you missed the two major points in my e-mail: please accept that you have been considered to be in the rough on 2023-04 and stop complaining. If you want to actually *change* the situation (like, having more detailed documentation, rules, requirements), your approach is not the way to achieve anyhting. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Thu, 31 Oct 2024 at 17:04, Gert Doering <gert@space.net> wrote: [...]
Where are these rules?
The policy proposal that introduced AGGREGATED-BY-LIR was very clear on the circumstances where it can be used. I'm fairly sure you know whether these have made it to policy text, so asking me to go chasing the details would be wasting my time.
It's worth including the policy text in this discussion: "6.2 Network Infrastructure and End User Networks When an LIR holding an IPv4 address allocation makes IPv4 address assignments, it must register these assignments in the RIPE Database. These registrations can either be made as individual assignments or by inserting an object with a status value of 'AGGREGATED-BY-LIR'. 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'." https://www.ripe.net/publications/docs/ripe-826/
But you missed the two major points in my e-mail: please accept that you have been considered to be in the rough on 2023-04 and stop complaining. If you want to actually *change* the situation (like, having more detailed documentation, rules, requirements), your approach is not the way to achieve anyhting.
Yes. Policy is mutable. If 'AGGREGATED-BY-LIR' does not work then the community can get rid of it. But we have less than a year of experience with it so far. We can ask the RIPE NCC to report on its use. Kind regards, Leo Vegoda, for the co-chairs
On Thu, 31 Oct 2024 at 17:41, Leo Vegoda <leo@vegoda.org> wrote:
Leo Vegoda, for the co-chairs
I mean the Address Policy WG co-chairs and not the Database GW co-chairs. My mistake. Sorry!
Hi Leo On Thu, 31 Oct 2024 at 17:41, Leo Vegoda <leo@vegoda.org> wrote:
Yes. Policy is mutable. If 'AGGREGATED-BY-LIR' does not work then the community can get rid of it. But we have less than a year of experience with it so far. We can ask the RIPE NCC to report on its use.
A very revealing comment. Yes you can get rid of an "optional, minor, inconsequential feature that changes nothing" as it was described by the policy proposers. Some people said at the time they had no objection to it, but didn't see any use for it. What you cannot (easily) reverse is making assignments optional. I still believe that, for many people involved in that discussion, this was what their minds were focused on. Now that has been achieved, perhaps few if any people care what happens with aggregation... I have never said that assignments must remain in the RIPE Database for eternity. But it was such a major change to the RIPE Database, with so much impact on many stakeholders, we should have had a full and open discussion on that specific topic and reached a consensus. Then we could have discussed aggregation type features. But it was slipped in through the back door. Hidden behind the words 'that changes nothing'. Even when I exploded that myth, we still didn't have a proper discussion on such a major change. (Just like brexit again.) The discussion at RIPE 87 was totally inconclusive and as Gert said at the end of that talk, there were more questions that needed to be answered. But they were never answered. This is why I am still aggrieved by 2023-04. We pushed through a minor change that some people considered pointless, and now we acknowledge could be reversed. But on the back of that, we made the biggest (irreversible?) change to the RIPE Database as a public registry since it was created as an operator's contact list, even though most people admitted we didn't understand much of the data contained therein. We still don't have an understanding of what this public registry is in the 2020s. We only, collectively and partially, remember what it was in the 1990s. cheers denis
Kind regards,
Leo Vegoda, for the co-chairs
Hi Denis, If you want to continue this discussion, I urge you to bring it over to the Address Policy WG list. This policy was proposed and discussed in that Working Group. It also found consensus there. It got eight months of discussion and the text was revised based on community feedback. The mail archive shows that we had almost 200 messages on the subject: https://mailman.ripe.net/archives/search?mlist=address-policy-wg%40ripe.net&q=2023-04 Public processes with significant discussion and revised drafts are not 'back door' processes. Kind regards, Leo Vegoda On Thu, 31 Oct 2024 at 19:52, denis walker <ripedenis@gmail.com> wrote:
Hi Leo
On Thu, 31 Oct 2024 at 17:41, Leo Vegoda <leo@vegoda.org> wrote:
Yes. Policy is mutable. If 'AGGREGATED-BY-LIR' does not work then the community can get rid of it. But we have less than a year of experience with it so far. We can ask the RIPE NCC to report on its use.
A very revealing comment. Yes you can get rid of an "optional, minor, inconsequential feature that changes nothing" as it was described by the policy proposers. Some people said at the time they had no objection to it, but didn't see any use for it. What you cannot (easily) reverse is making assignments optional. I still believe that, for many people involved in that discussion, this was what their minds were focused on. Now that has been achieved, perhaps few if any people care what happens with aggregation...
I have never said that assignments must remain in the RIPE Database for eternity. But it was such a major change to the RIPE Database, with so much impact on many stakeholders, we should have had a full and open discussion on that specific topic and reached a consensus. Then we could have discussed aggregation type features. But it was slipped in through the back door. Hidden behind the words 'that changes nothing'. Even when I exploded that myth, we still didn't have a proper discussion on such a major change. (Just like brexit again.) The discussion at RIPE 87 was totally inconclusive and as Gert said at the end of that talk, there were more questions that needed to be answered. But they were never answered. This is why I am still aggrieved by 2023-04. We pushed through a minor change that some people considered pointless, and now we acknowledge could be reversed. But on the back of that, we made the biggest (irreversible?) change to the RIPE Database as a public registry since it was created as an operator's contact list, even though most people admitted we didn't understand much of the data contained therein. We still don't have an understanding of what this public registry is in the 2020s. We only, collectively and partially, remember what it was in the 1990s.
cheers denis
Kind regards,
Leo Vegoda, for the co-chairs
On Thu, 31 Oct 2024 at 17:04, Gert Doering <gert@space.net> wrote:
Hi,
On Thu, Oct 31, 2024 at 04:59:34PM +0100, denis walker wrote:
On Thu, 31 Oct 2024 at 15:23, Gert Doering <gert@space.net> wrote:
On Thu, Oct 31, 2024 at 01:24:45PM +0100, denis walker wrote:
An LIR with an allocation can now simply split that allocation in half and create two objects with status 'aggregated-by-lir'. The boundary between the two aggregations does not even need to match the boundaries of any more specific ranges. There are NO rules about using this status. Absolutely nothing else more specific to these aggregations needs to be documented in the RIPE Database, in any public domain or notified to the RIPE NCC. The LIR may make a sub-allocation of, say, a /24 below one of these aggregations. Or maybe below both of them, crossing the boundary.
Denis, you are talking nonsense. There are very clear rules what can be under AGGREGATED-BY-LIR (namely, ASSIGNED, with the same contact data). Not SUB-ALLOCATED.
Where are these rules?
The policy proposal that introduced AGGREGATED-BY-LIR was very clear on the circumstances where it can be used.
The proposal text is irrelevant when it comes to actual policy. But in any case it wasn't clear. In fact it was very misleading.
I'm fairly sure you know whether these have made it to policy text, so asking me to go chasing the details would be wasting my time.
I will save you the time and I won't bore you with an analysis of the actual policy text. But the policy text does not prohibit a hierarchy like this: allocated pa aggregated-by-lir sub-allocated pa sub-allocated pa assigned pa It can be argued they all use the LIR's contact details and purpose has never been publicly documented anywhere.
But you missed the two major points in my e-mail: please accept that you have been considered to be in the rough on 2023-04 and stop complaining.
I was in the rough with the brexit referendum. The outcome and the implementation still have negative consequences. I do accept that both brexit and 2023-04 were declared by consensus. In both cases by a very small number/percentage of people.
If you want to actually *change* the situation (like, having more detailed documentation, rules, requirements), your approach is not the way to achieve anyhting.
The only way to (partially) fix what it broke is by another policy change to build in clear rules on hierarchical structure. In the past such detail was handled by the business rules built into the database software, based to some extent on the RIPE NCC's understanding of what was intended. Sometimes the NCC asked for clarification from the community and built that into the software rules. But software rules cannot be applied to what is not there. We are now talking about potential 'hidden' data structures. With no clear rules on the hierarchy in the policy text and the option to hide the structure you have set up, there is no public scrutiny of what people may do. When law enforcement is chasing the End User along a chain of sub-allocations, they can all argue they are policy compliant. Even if we fix the policy text and prohibit sub-allocations more specific to aggregations, it still doesn't stop anyone from creating an invalid hierarchy that will go unnoticed for a long time as it is hidden from public view. RIPE policy is not law. The address space can be revoked for policy violation. But that doesn't help to find a criminal End User. Probably none of the intermediates with the sub-allocations have commited a crime. They just violated RIPE policy. When the whole hierarchy had to be documented in the RIPE Database you would be able to jump straight to the End User or the one less specific sub-allocation holder. If that data was incorrect, whoever entered it could be accused of helping a criminal to evade justice. Which may be a crime. It has been argued we are doing nothing different to what we have done for a long time with IPv6. But I believe most crime is still done using IPv4 addresses. So it is a different situation. There is no doubt that aggregation of IPv4 addresses has created some problems, especially for law enforcement and rights enforcers. As an audience speaker said this morning, the EU/EC is looking at legislation. We ignore these issues at our peril... cheers denis
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (3)
-
denis walker -
Gert Doering -
Leo Vegoda