[address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04

Hi Denis,

On Fri, 2023-12-15 at 14:20 +0100, denis walker wrote:


> We have been through all these arguments before, but it is the review
> phase now so they need to be repeated.

Indeed. We will now restate our responses too, as required by the PDP.
That said, there are no new arguments presented, so anyone reading this
should feel free to skip the rest of this message.

> On Thu, 14 Dec 2023 at 16:34, Tore Anderson <tore at fud.no> wrote:
> > 
> > «As of August 2023, there were 19,221 PA allocations without any child
> > PA assignments held by 10,052 LIRs (…) Since the RIPE Database
> > Requirements Task Force published their report in May 2021, the PA
> > allocations without any child assignment have grown by 18.4 percent.»
> 
> 18.4% of 19,221 is 3536. How many /24 allocations were made in that
> time period that quite likely don't have assignments?

We will ask the RIPE NCC to provide the working group with the updated
statistics you request here.
> 

> > We hypothesise that this trend is least partially caused by LIRs
> > considering that registering all assignments individually is too
> > labour-intensive and not worth the effort, especially in highly dynamic
> > environments where individual (but otherwise identical) assignments
> > rapidly come and go.
> 
> Pure speculation without any numbers.

We have no hard data that prove (or disprove) this hypothesis, that is
true. We have not surveyed the LIRs in question to ask them why they
opt not to register assignments. That said, as we do have quite a bit
of experience as LIR hostmasters (including working with highly dynamic
network environments), we would prefer to call the hypothesis an
educated guess, rather than pure speculation.

> But what you are suggesting is that some LIRs don't consider it worth
> the effort to comply with RIPE policy and don't want to get involved
> in discussions to change the policy.

Regrettably, yes.

> I don't agree with your proposal but at least you are trying to
> change something you don't agree with.

We do appreciate you recognising that.

> As for the labour intensity, we know the answer to that, but no one
> will even talk about updating the 25 - 30 year old RIPE Database
> design, data model and technology...

We don't doubt that updating the RIPE database design, data model and
technology is a good idea, but we believe this question falls outside
of the scope of proposal 2023-04 (and the AP-WG charter entirely).

> As for 2023-04 increasing the level of End User assignment coverage,
> this is pure fantasy. In theory you could perhaps argue that the
> 'coverage' has increased if many LIRs create aggregated objects and
> claim that many assignments have been made from within that block.

If a WHOIS lookup of an IPv4 address that today will return an
ALLOCATED PA object (even though it is in fact assigned and in use) but
after the implementation of 2023-04 will return an AGGREGATED-BY-LIR
object, then we consider that the assignment coverage has increased.

> But the End User details will be completely lost within that
> amorphous block.

We believe this concern has been addressed in the following message,
under the heading «Does 2023-04 change the contact registration
requirements for assignments?».

https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013913.html

> Not even the assignment boundaries can be deduced.

As mentioned in the proposal text itself, we did not see any
independent justification for making the assignment-size attribute
mandatory in IPv4, as its use in the calculation of the HD-ratio in
IPv6 is not applicable.

That said, if you or anyone else in the working group can identify and
clearly articulate an independent justification for making the
assignment-size attribute mandatory in IPv4 too, then we will certainly
give that due consideration and possibly amend the proposal
accordingly.

> Many other LIRs may well anonymize their future or even already
> existing assignments by removing all references to the End User's
> identity and contact details. This may be done at the request of the
> End User. Or it may be done because the LIR has adopted a policy of
> not entering any details of their customers (End Users) into a public
> database. I have spoken to LIRs who have made it clear that it is
> already their policy regardless of current RIPE address policy
> requirements. They consider it commercially sensitive data.

We believe these concerns have been addressed in the following message,
under the heading «Does 2023-04 change the contact registration
requirements for assignments?».

https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013913.html

> There are technical solutions to mitigate this but again no one will
> talk about the database.

We assume you refer to improving the RIPE database technology here,
which we have answered earlier on in this message.
> 

> > 2023-04 would provide these LIRs a less labour-intensive option to
> > register such assignments. Whether or not they would avail themselves
> > of the new option is of course an open question, but it seems clear
> > that something has to be done if the current trend towards less
> > assignment coverage in the database is to be reversed.
> 
> Less labour intensive by dumping the detail. This is about
> eliminating a problem rather than solving the problem, again because
> no one will talk about technical solutions. You cannot define a trend
> based on two measurement points. I agree something does need to be
> done to get more LIRs complying with RIPE policies. But changing the
> registration rules so that more people appear to follow them is not
> the way forward.

We believe the concerns about «dumping the detail» and «changing the
registration rules» have been addressed in the following message, under
the heading «Does 2023-04 change the contact registration requirements
for assignments?».

https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013913.html

As for the «technical solutions» part, we assume you refer to improving
the RIPE database technology, which we have answered earlier in this
message.

> > 
> > Taking into account the current policies and procedures, we suspect
> > that the information about the End Users that LEAs can obtain
> > directly from the RIPE database is inserted there voluntarily in
> > the first place.
> 
> Or because some LIRs have correctly interpreted the current policy.

We do not believe that interpretation to be correct, as noted in the
following message, under the heading «Does 2023-04 change the contact
registration requirements for assignments?».

https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013913.html

> 
> It is a good idea to align the IPv4 and IPv6 systems of registration
> 'where appropriate'.

Agreed.

> But maybe copy and paste without due consideration is not the best
> way to do it.

We believe we have given this due consideration prior to submitting the
proposal. We have looked at how AGGREGATED-BY-LIR is being used in IPv6
(it appears to be popular amongst LIRs as there are almost 60k such
objects in the database) and contrasted this with how there is an
ongoing challenge with LIRs not registering their IPv4 assignments at
all (cf. ripe-767 section 6.1.2).

We truly believe AGGREGATED-BY-LIR strikes a good balance here,
otherwise we would not have submitted our proposal.

> There are differences. In those "many years" of aggregating IPv6
> assignments not much of the internet was using IPv6. So it is not a
> valid argument to say there have been no problems with aggregating
> IPv6 over those "many years" so it must be OK. As more of the
> internet moves to IPv6, maybe we will start to see the problems that
> have been insignificant in the past.

IPv6 is extensively used nowadays, yet so far we have not seen anyone
describing any problems caused by AGGREGATED-BY-LIR in IPv6 (much less
attempt to fix them). If there truly were any problems with IPv6
AGGREGATED-BY-LIR, we would have expected them to manifest by now.

We have not seen any reason to expect that IPv4 AGGREGATED-BY-LIR would
be any more (or less) problematic than IPv6 AGGREGATED-BY-LIR.

> Maybe we will need to expand the IPv6 registration of assignments to
> match the current IPv4 policy.

That is certainly something the community could do if it wanted. That
would not be our preferred approach, though, as we fear this might
import the problem of LIRs not registering assignments (cf. ripe-767
section 6.1.2) from IPv4 into IPv6, do nothing to help with the labour
intensiveness of keeping the RIPE database up to date in highly dynamic
environments (rather it would introduce or aggravate that problem in
IPv6), as well as leave us with a major headache about what to do with
the ~60k invalidated AGGREGATED-BY-LIR inet6num objects.

> Again there are technical solutions here that no one will talk about.

We assume you refer to improving the RIPE database technology here,
which we have answered earlier on in this message.

Best regards,
Jeroen and Tore