On Wednesday, December 20th, 2023 at 18:16, Tore Anderson <tore@fud.no> wrote:
On 20/12/23 17:27, denis walker wrote:
Most of these allocations are /24. So if 4551 of these /24 allocations have no assignments, and the increase in allocations without assignments is only 3536, then we actually have more allocations with assignments than we had before, putting aside the /24 allocation issue. So the trend is downwards. The overall number of allocations without assignments is decreasing.
Hello Denis,
What do you mean when you say «the /24 allocation issue», exactly?
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
Hello, I would like to express my opinion. It is a personal opinion and does not represent any organization. I think that the proposal to include the AGGREGATED-BY-LIR option in IPv4 made is very interesting and correct, but I also think that the opinion expressed by Denis and other members of the working group is completely reasonable. I think we should make a modification that all parties agree on. In my opinion, I think we should ask ourselves what is going on and what are the reasons why information is being recorded in the DB in a non-uniform way. In this sense, I believe that the database shows a series of information that can be used to contact IP address holders, but this information is also used to attack organizations, either by identifying address ranges or by phishing and other types of attacks through the exposed means of contact. And for this reason, it is possible that some members may prefer not to register the information (not following the policy), register "anonymous" end-user ranges as LIR's own, etc. In this sense, I think it would be interesting to make a proposal to modify the policy (before or after the 2023-04 proposal), specifying what can and cannot be done, as well as what is recommended. For example, in IPv4, an assignment may be used for a pool of DSL client addresses, in which case the LIR must be registered as the owner, because there is no defined end user. It is logical that in IPv6, where there is a variable prefix length size, AGGREGATED-BY-LIR is used for this type of registration. On the other hand, in IPv4 the policy requires registering a range assigned to an end user as the users's own, but does not include the options for not including end-user information (if so desired) and thus hiding the information from possible attacks, including the netname, contact addresses, etc. Perhaps the only currently valid option is to register it in the name of the LIR, as has been shown with some DB objects. However, using AGGREGATED-BY-LIR for this purpose, I think (in my opinion) is not the right thing to do. I think that if we do not specify what can and cannot be done the database will end up with information that will only indicate the LIR as the user of the addresses. If we are able to specify the specific use of each state of the inetnum objects that includes the needs of all LIRs, the proposal made by Tore and Jeroen to include AGGREGATED-BY-LIR in IPv4 and thus homogenice the inetnum objects of both protocols will be accepted by the majority. Best regards. kix