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

Hi Brian,

* Brian Storey

> Thanks for explaining this particular use case.
> 
> Reading the proposed New Policy Text, it provides the LIR with an
> adminsitrative choice. Whilst I understand this choice, the
> rantionale behind the proposal is to find a reasonable way to fill
> the gap for the Provider Allocations not registered for the specific
> exception documented: "IP addresses used solely for the connection of
> an End User to a service provider... can be registered as part of the
> service provider's internal infrastructure".
> 
> 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.

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:

inetnum:  192.0.2.0 - 192.0.2.192
netname:  BRIAN-ISP
country:  GB
admin-c:  BRIAN-RIPE
tech-c:   BRIAN-RIPE
status:   AGGREGATED-BY-LIR
mnt-by:   BRIAN-MNT
source:   RIPE


The second example concerns the case where the assignments are not
uniform. Let's say your customers operate their own NOCs, so your
starting point instead is having these two assignments:

Customer 1:

inetnum:  192.0.2.0 - 192.0.2.128
netname:  BRIAN-ISP
country:  GB
admin-c:  BRIAN-RIPE
tech-c:   CUST1-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:   CUST2-RIPE
status:   ASSIGNED PA
mnt-by:   BRIAN-MNT
source:   RIPE

Note how the 'tech-c' attribute differs between the two assignments.
That means that not be able to replace them with an 
AGGREGATED-BY-LIR 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.

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.

Tore