[address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hello Denis,

Let me start off by clearing up a misunderstanding:

My brief example did not mean to convey that non-uniform contact
information is the only thing that could make a set of objects non-
uniform and thus unsuitable for AGGREGATED-BY-LIR.

Rather, the exact opposite was the intended meaning - which is that
almost any attribute can make a set of objects non-uniform. The tech-c
attribute was only used an example to demonstrate this.

With that out of the way, my answers to your remaining points follow
in-line:

* denis walker

> Now let's look at a real life example.
> 
> whois -rBm 195.238.192.0 - 195.238.223.255
> 
> The first thing to note is that the admin-c and tech-c values are the
> same in all the more specific assignments. Even the mnt-by is the
> same, although you make no mention if that is a blokker for
> aggregation or not. So by your definition these are 'completely
> uniform' objects and can be aggregated.

As I clarified above, these objects are in my view *not* uniform, as
they have distinct netname, descr and country attributes (possibly
others I missed too, I only skimmed through them quickly).

The LIR in question clearly has a policy of publishing the street
address of each assignee in the descr attribute. That is totally fine,
and will continue to be totally fine after 2023-04 is implemented, but
it makes their objects unsuitable for aggregation.

> You will also note that all these objects contain optional descr
> attributes. These attributes contain name and address details of the
> end user. That is important information for many stakeholder groups
> using the RIPE Database public registry. That detail will be lost in
> an aggregation. Given that current policy requires these assignments
> to be registered in the public registry, many users do include this
> detail. Now we all know the RIPE Database design and technology is
> very old and it does currently require some effort to manage this
> data. (A problem that all users have noticed but no one has attempted
> to fix.) Given a 'short cut' option, human nature suggests people
> will use it, even if it is not the right thing to do for a public
> registry. So aggregating across the whole database, may result in a
> massive amount of detail being lost from the public registry.

It is important to note that the information you mention as "important"
here - the assignee's address - is (as you rightly point out) optional
to include. An LIR is under no obligation to publish this information,
and the inetnum object does not even contain an attribute dedicated to
it.

(While the organisation object has mandatory org-name and address
attributes, the org attribute is optional in inetnum objects.)

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.

> Also note that there are gaps in the more specific assignments for
> this allocation. For example 195.238.193.224 - 195.238.193.255 is not
> assigned. Can your aggregated objects span these gaps? If so then we
> lose sight of what address space is in use or available. It may no
> longer be needed for further allocations but people do still use that
> information.

Yes, just as in IPv6, aggregated objects can span gaps. This is
essential, as the primary use case targeted by AGGREGATED-BY-LIR is
automated assignment pools with a high churn rate (e.g., a dynamic DHCP
pool).

In such environments, the .1, .2 and .3 addresses might be assigned
before .2 might get de-assigned again - all within seconds, with no
operator involvement. We believe it is not necessary to reflect this
high level of granularity and rapid churn rate in the RIPE database.

> The assignments are all randomly sized. Which is why you have dropped
> the inet6num assignment-size attribute for inetnum objects. So if I
> amgetting abuse from one specific IP address what should I do? I have
> noidea from the aggregated block what the block size is that includes
> this one IP address. Is there any other way to find this information,
> maybe from routing details? If not, should I block and blacklist the
> entire aggregated block? That could affect hundreds, maybe even
> thousands, of users in some cases. This is not a problem with IPv6 as
> you know the size of the block containing that address.

My personal recommendation would be to block the specific IP address
you are receiving abusive traffic from and send a complaint to the
abuse-c for the inetnum in question.

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. 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.

Tore