[address-policy-wg] Checking interest in the community for changing IPv4 assignments policy

On Tue, 2023-05-16 at 02:08 +0200, denis walker wrote:

> What is the real reason for this push to dump assignments? I just
> don't buy these arguments.

Hi Denis,

The reason / rationale is as stated. There is no "real" reason apart
from that. Of course, the formal proposal will elaborate further.

I do not quite understand what you mean by "dumping assignments". To be
clear, our proposal would not invalidate any existing assignments, nor
mandate that LIRs change their current practices, whatever they may be.

> I know it is an odd thing to consider in this industry, but this is
> what computers are good at doing. It is 2023. Everyone is talking
> about how AI is going to take control of humanity soon. But the
> internet industry cannot automate the syncing of your internal IPAM
> with the RIPE Database? I don't think we need to worry about AI yet.
> > 
(...)
> 

> 
> We don't need to take away reasons, we just need to automate and do
> it properly.

Requiring LIRs to create automated systems that export their entire
IPAM contents to the RIPE database is out of scope for this proposal.

However, I would note that this proposal would not in any way prevent
LIRs from building and using such systems, should they prefer to do so.

> > 3. Policy 6.3 “Network Infrastructure and End User Networks” can be
> > interpreted differently for what the right use case is.
> 
> I don't see anything in 6.2 that is open to interpretation or
> relevant to the case for dumping assignments.

The current policy is clear enough, it is the actual implementation of
it that is currently somewhat out of sync.

In particular, it says that «IP addresses used ***solely*** for the
connection of an End User to a service provider (e.g. point-to-point
links) are considered part of the service provider's infrastructure.
These addresses do not have to be registered with the End User's
contact details but can be registered as part of the service provider's
internal infrastructure». (Emphasis mine.)

This mechanism is widely used in IPv4 in a similar way as AGGREGATED-
BY-LIR is in IPv6, i.e., by aggregating multiple customer assignments
into a single database object.

However, any use of the IP address by the customer beyond the
«connection to the service provider» purpose, would make this mechanism
unavailable to the LIR. Consider for example if a home broadband
subscriber sets up a public Minecraft server on their home LAN and
exposes it on the public IPv4 address using port forwarding
functionality in their home gateway. The policy does strictly speaking
mandate a separate assignment to be registered for that single IPv4
address, but this requirement is widely ignored (quite understandably).

IPv6's AGGREGATED-BY-LIR, on the other hand, does not have this issue.

> > Including the feedback from the previous policy proposal, we are
> > thinking about introducing AGGREGATED-BY-LIR status just as in the
> > IPv6 policy. In this way, we can aggregate multiple assignments
> > into one AGGREGATED-BY-LIR assignment which we think would result
> > in improving the above-mentioned points.
> 
> I think it is a bad idea to hide the users of blocks of IP addresses
> from the public in a public registry database. 

This proposal is not about "hiding" anything, at least not something
that is not already non-public information (e.g., due to GDPR
requirements). This is about aggregating bulk assignments made to
multiple end users where the LIRs themselves, not the end users, are
the point of contact for any technical queries from third parties, such
as abuse reports or information requests from law enforcement agencies.

Some typical examples are dynamic pools assigned to home broadband
subscribers, cloud VPS instances, and so on.

Our view is that the AGGREGATED-BY-LIR status found in the IPv6 policy
caters to this use case in a more appropriate way than the IPv4 policy
does, and that by "backporting" the mechanism we end up with an
improved IPv4 policy and, as an additional bonus, more unified IPvX
policies.

> With a modern approach to creating the data in the database, there is
> no need for AGGREGATED-BY-LIR for either IPv4 or IPv6.

Removal of the AGGREGATED-BY-LIR mechanism from the IPv6 policy, and
the IPv4 bulk assignment mechanism in 6.2 of the IPv4 policy for that
matter, is out of scope for this proposal.

However, I will note that it appears that quite a lot (likely the
majority) of individual IPv6 assignments made are covered by
AGGREGATED-BY-LIR inet6num objects, which suggests to me that the
community does indeed see the need for a mechanism that allows them to
register bulk assignments as aggregated objects in the database.

Tore