On Wednesday, December 20th, 2023 at 18:16, Tore Anderson <[email protected]> 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

-- 

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

Reply via email to