[address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)

Colleagues

Over the weekend I re-read rfc7020 The Internet Numbers Registry
System, from August 2013
https://www.rfc-editor.org/rfc/rfc7020
>From the Abstract:
This document provides information about the current Internet Numbers
Registry System used in the distribution of globally unique Internet
Protocol (IP) address space and autonomous system (AS) numbers.

Now when I say I read something, that usually means I studied it. What
matters with most documents in this industry is the detail, not the
headings. The DB Task Force made references to rfc7020 in their
report. They said "The need to maintain an accurate public record of
Internet number resource holders is common to all Regional Internet
Registries (RIRs). This is outlined in RFC 7020". They went on to use
this to justify the need to publish details in the RIPE Database about
allocations made by the RIPE NCC to resource holders.

Now this is where detail matters and the Task Force missed an
important detail in rfc7020. In RIPE policy and terminology, we
allocate resources from the RIPE NCC to a resource holder (LIR). The
resource holder then assigns resources to end users. However, in
rfc7020 there is no distinction between allocate and assign. It refers
to a hierarchy of allocations from IANA all the way down to an end
user. This is clearly illustrated in the definition in rfc7020 of an
LIR:

  Local IRs
  ...LIRs perform IP address allocation services for their customers,
typically ISPs, end users, or child LIRs (also known as "sub-LIRs").

So throughout the whole rfc7020 document, all references to allocate
or allocation include what we understand in the RIPE region to mean
both allocate and assign, as well as allocation and assignment. That
means all the goals, principles and comments in rfc7020 apply equally
to our allocations and assignments.

In rfc7020 it specifies some goals including:

  2.  Goals
  Internet number resources are currently distributed according to the
following (non-exclusive) goals:
  ...
  3)  Registration Accuracy: A core requirement of the Internet
Numbers Registry System is to maintain a registry of allocations to
ensure uniqueness and to provide accurate registration information of
those allocations in order to meet a variety of operational
requirements. Uniqueness ensures that IP addresses and AS numbers are
not allocated to more than one party at the same time.

The Task Force took this to mean what we consider as allocations to
LIRs. But this also means what we consider as assignments to end
users. So registering our assignments in the RIPE Database is a "core
requirement of the Internet Numbers Registry System".

rfc7020 goes on to say:

  3.  Internet Numbers Registry System Structure
  The Internet Registry (IR) hierarchy was established to provide for
the allocation of IP addresses and AS numbers with consideration to
the above goals.  This hierarchy is rooted in the Internet Assigned
Numbers Authority (IANA) address allocation function, which serves a
set of "Regional Internet Registries" (RIRs); the RIRs then serve a
set of "Local Internet Registries" (LIRs) and other customers.  LIRs
in turn serve their respective number resource consumers (which may be
themselves, their customers, "sub-LIRs", etc.)

It concludes with:

  7.  Security Considerations
  It is generally recognized that accuracy and public availability of
Internet registry data is often an essential component in researching
and resolving security and operational issues on the Internet.

The bottom line is that we cannot make assignments optional unless we
either disregard rfc7020 or we propose to the IETF an update to
rfc7020 by removing a large proportion of the current registration
data from the goals and core requirements. In fact we should now
reconsider the way we register IPv6 assignments in the RIPE Database.
rfc7020 makes no distinction between number systems.

cheers
denis
co-chair DB-WG