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

Hi Tore

Your claims are not correct. Your simple example hides a lot of
detail. I have given a real life example below taken from the database
to illustrate what I mean. My apologies to the resource holder, but it
is a perfect example to illustrate several points.

On Tue, 12 Sept 2023 at 08:51, Tore Anderson <tore at fud.no> wrote:
>
> Hi Brian,
>
> * Brian Storey
>
> > Given the choice provided in the proposal, it seems to me like I
> > could go the other way with this and aggregate everything? The end
> > user allocation size distinction no longer looks to apply and I could
> > interprete that the "purpose" of the whole aggregate is consistent
> > (they are all used to reach "stuff") and therefore chose to not
> > register any end user assigned /29s, 28s, /27s etc.
>
> It depends on whether or not all your assignments are completely
> uniform (apart from the prefix value and length). If they are, you will
> be able to aggregate them.

Your definition of 'completely uniform' seems to only apply to contact
details, as you make clear in the next paragraph. Many assignment
objects currently contain more information than just contact
references. You are making the assumption that the RIPE Database is
still nothing more than an operator's contact database for network
operational issues. In which case all you need is the tech-c.

>
> This means that they need to share a single common point of contact,
> which is often the case for assignments associated with fully managed
> Internet services provided to private individuals and small businesses.
> Such assignments would be possible to aggregate.
>
> If on the other hand they are not uniform (for example if your
> customers operate their own NOCs and therefore have different contact
> information), you will not be able to aggregate them.
>
> I will try to explain by example here as well. Let's say you currently
> have two customer assignments as follows:
>
> Customer 1:
>
> inetnum:  192.0.2.0 - 192.0.2.128
> netname:  BRIAN-ISP
> country:  GB
> admin-c:  BRIAN-RIPE
> tech-c:   BRIAN-RIPE
> status:   ASSIGNED PA
> mnt-by:   BRIAN-MNT
> source:   RIPE
>
> Customer 2:
>
> inetnum:  192.0.2.128 - 192.0.2.192
> netname:  BRIAN-ISP
> country:  GB
> admin-c:  BRIAN-RIPE
> tech-c:   BRIAN-RIPE
> status:   ASSIGNED PA
> mnt-by:   BRIAN-MNT
> source:   RIPE
>
> As you can see, except for the 'inetnum' value, they are completely
> identical. That means you will be able aggregate them into a single
> object:

But your example is a bare bones object.

>
> > Does this not contradict other purposes / objectives of the registry,
> > including the principles of registering public networks or am I
> > missing something?
>
> We do not believe so. As demonstrated above, only highly redundant data
> can be aggregated, so very little actual information lost in the
> process.

In real life lots of information may be lost.

>
> Finally, please keep in mind that AGGREGATED-BY-LIR is not a novel
> idea, it has been around in the IPv6 policy for many many years. If it
> was indeed the case that it contradicted the purposes and/or objectives
> of the registry, someone ought to have noticed and attempted to fix
> that problem by now. That has not happened, as far as we know, which we
> take as a sign that there is no such problem in the first place.

This community has very little appetite to fix things properly if a
quick fix will do or they can live with existing problems. The
constant 'fight' to try to fix many problems with the RIPE Database
illustrates this point very well.

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.

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.

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.

The assignments are all randomly sized. Which is why you have dropped
the inet6num assignment-size attribute for inetnum objects. So if I am
getting abuse from one specific IP address what should I do? I have no
idea 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.

cheers
denis
c0-chair DB-WG


>
> Tore
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/