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

Hi Denis,

It would appear to me that your opposition to 2023-04 is largely based
on the premise that it introduces a new possibility for anonymous
assignments, a change which you do not want to see happen. This premise
also appears to underpin many of your musings in your «The bigger
picture» message. I disagree with this premise, as I believe this
possibility is already there in current policy.

Rather than decide to agree to disagree on that point, or endlessly
quarrel about it, I realised that it does not really matter what you or
I believe the policy requirements are - what matters is the RIPE
NCC's understanding of the policy and how they are implementing it. So
I simply asked their Policy Officer (Angela) to clarify this.

Her answers, which I with permission quote in full along with my
questions below, unequivocally confirms that that current policy does
indeed allow assignments to be registered anonymously in the RIPE
database. Hence, your opposition to proposal 2023-04 in this regard
appears to rest on a fundamentally flawed assumption.


   Tore: «The context here is an IPv4 assignment that is not made to an
   individual and that is not used solely for the connection of an End
   User to a service provider.
   
   1. Does current address policy as implemented by the NCC allow an End
   User to delegate/outsource the contact information represented by the
   mandatory "tech-c" and "admin-c" attributes to another entity,
   typically (but not necessarily) the issuing LIR? (There does not appear
   to be any disagreement on this point, but I include this question
   anyway in case we are both wrong.)»
   
   Angela: «Yes, you are correct. An End User is allowed to
   delegate/outsource the contact information represented by the mandatory
   "tech-c" and "admin-c" attributes to another entity, typically (but not
   necessarily) the issuing LIR.»
   
   Tore: «2. Assuming "yes" to question 1, for an assignment where the
   "tech-c" and "admin-c" has been delegated in this manner: Does current
   address policy require the corresponding "inetnum" database object to
   contain some additional contact information, that is not delegated to a
   third party, i.e., it must be refer to a point of contact that is
   handled in-house by the End User him/herself?»
   
   Angela: «The current address policy does not require the corresponding
   "inetnum" database object to contain some additional contact
   information that is not delegated to a third party.
   LIRs can use the “netname” attribute to link assignments to end users
   and their contact details in internal records.
   
   There is a particular case: when the RIPE NCC receives a request for
   assigning an AS number to an End User using a PA assignment, the IPv4
   network to be announced by the requested AS must be registered in an
   “inetnum” object showing the End User’s name. This can be in the
   "descr” attribute or recursively in the "org" object added as
   attribute.»
   
   Tore: «3. Assuming "yes" to question 2, what kind of other contact
   information is required, and in which "inetnum" database attribute(s)
   must it be located? Here are some possible examples off the top of my
   head, would any or all of these satisfy the policy requirement for an
   in-house non-delegated contact information?
     1. A street address
     2. A (snail) mail address
     3. An e-mail address
     4. A fax number
     5. A phone number»
   
   Angela: «The answer to question 2 was “no’, however one way to record
   End Users’ contact details is to create an “org” object to be added as
   optional attribute in the “inetnum” object.
   In “org” objects name, address and email are mandatory.
   In “inetnum” objects the mandatory contact information are “admin-c”
   and “tech-c”.»
   
   Tore: «4. Assuming "yes" to question 2, is it mandatory to identify the
   End User by name, or would it be sufficient with, e.g., a street
   address without an organisation name (assuming there is only a single
   entity located at that address), a post box snail mail address, a
   generic user123 at gmail.com e-mail address, or a phone/fax number that is
   not listed in the white or yellow pages?»
   
   Angela: «The answer to question 2 was “no’,...»
   
   Tore (in a new e-mail): «I will ask you a couple of follow-up questions
   just to make absolutely, 150%, certain I do not misunderstand you and
   end up misrepresenting you to the mailing list:

   1. When you write «LIRs can use the “netname” attribute to link
   assignments to end users and their contact details in internal
   records», this "can" is a MAY, not a MUST, to use IETF lingo? That
   is, the LIR is free to instead use the "inetnum" attribute, i.e.,
   the IP address(es), to link the assignment to the End User in their
   internal record? If that is the case, would it be correct to say
   that the LIR are free to set the "netname" attribute to essentially
   anything, including a meaningless string of random characters?»
   
   Angela: «Your interpretation is correct, the answer is yes to all
   three questions.
   Please also consider that the "netname" is not required to be
   unique, LIRs can use the same one for multiple assignments.»
   
   Tore: «2. When you write «one way to record End Users’ contact
   details is to create an “org” object to be added as optional
   attribute in the “inetnum” object», this is also a MAY, not a MUST?
   That is, the LIR is free to omit the "org" attribute, even though
   the only other contact information contained in the object is the
   (LIR-delegated) "tech-c" and "admin-c" attributes?»
   
   Angela: «Yes, the LIR is free to omit the "org" attribute, even
   though the only other contact information contained in the object is
   the (LIR-delegated) "tech-c" and "admin-c" attributes.
   If the LIR requests an AS number on behalf of an end user to
   announce a PA assignment, then the PA assignment MUST include the
   legal name of the end user in the "descr" attribute or in the '"org"
   object set as "org" attribute in the "inetnum" object.»
   
   Tore: «3. To use a concrete example: Let's say «SuperLIR GmbH»
   delegated 192.0.2.0/25 to the End User «CarFactory GmbH».
   (CarFactory GmbH is not an individual, and the assignment is not
   used solely for the connection to the provider, nor to justify an
   application for an AS number). SuperLIR inserts the following
   minimal database object:
   
   inetnum:  192.0.2.0 - 192.0.2.128
   netname:  ABCDEFGHIJKLMNOPQRSTUVWXYZ
   country:  DE
   admin-c:  SUPERLIR-NOC-RIPE
   tech-c:   SUPERLIR-NOC-RIPE
   status:   ASSIGNED PA
   mnt-by:   SUPERLIR-MNT
   source:   RIPE
   
   In the event of an audit, SuperLIR GmbH will be able to inform the
   RIPE NCC auditors that this object has been delegated to CarFactory
   GmbH.
   
   Is the above registration compliant with current IPv4 address
   policy, or will the auditors demand any kind of changes be made?»
   
   Angela: «The above registration compliant with current IPv4 address
   policy. During an audit we could ask the LIR whether the assignment
   is still in use. It does not matter for the RIPE NCC who is using
   the assignment, as long as the LIR is maintaining the registration
   up to date and is able to contact the end user. This means that if
   the LIR moves the assignment delegation from CarFactory GmbH to
   another end user in the same country for which is acting as "admin-
   c" and "tech-c", the "inetnum" object would still be valid. It is
   the LIR's responsibility to keep their internal records up to date
   accordingly with the new end user.»


In light of the above, I hope that you will reconsider your opposing
arguments and either withdraw them or restate them in a way that does
not rely on this incorrect assumption. Anticipating this, I will only
address your remaining points that are not based on the
misunderstanding that 2023-04 opens up for anonymous assignments.


> It should not be permitted to aggregate a single assignment to a
> single End User.

While I agree that "aggregating" a single assignment seems like a
pointless practice, I do not quite see why it is necessary to introduce
policy language to ban it.

It is, as I understand it, possible to use AGGREGATED-BY-LIR with an
assignment-size identical to the prefix length in the inet6num
attribute today, but I cannot find a single example of this being done.
(Presumably because it is pointless to do so.)

It is also possible today to "aggregate" a single IPv4 assignment under
the «solely for connection» exception. Whether or not that has been
done is impossible for me to say, but even if it has I fail to
understand why it would constitute an actual problem.

I am not being totally dismissive towards adding a condition à la «an
object with status AGGREGATED-BY-LIR must contain at least two
individual assignments» to the proposal, but I would first like to
better understand the reasons why you feel this is a necessity.

> But the IPv6 policy also includes this:
> "When more than a /48 is assigned to an organisation, it must be
> registered in the database as a separate object with status
> 'ASSIGNED'."
> I don't see your equivalent of this copied from the IPv6 policy into
> your new IPv4 policy. Maybe more than a /24 might be an equivalent in
> IPv4 terms. You refer to 'that specific sentence' so casually, yet
> this is the main element of the current IPv4 assignment policy.
> Dropping this sentence is a major change to the assignment policy.
> This has far more consequences than just adding an optional
> construct.

In IPv6, /48 is the limit beyond which extra documentation requirements
("need basis") kicks in. Assignments /48 or longer can be freely made
by an LIR without any supporting documentation, and this is presumably
why such assignments can be freely registered under a single
AGGREGATED-BY-LIR object. In other words, assignments shorter than /48
has more stringent documentation requirements, and therefore also more
stringent registration requirements.

See https://www.ripe.net/publications/docs/ripe-738#assignments_shorter

As there is no "need basis" for assignments in IPv4 regardless of size,
there simply is no equivalent value, not /24 nor anything else. (Well,
I suppose you could say that /0 is the equivalent value.)

> 

> > > > Note that this is not really much different than what you have
> > > > to do today for abuse coming from customer assignments that are
> > > > «registered as part of the service provider's internal
> > > > infrastructure», cf. ripe-708 section 6.2.
> 
> Doesn't that suggest they are DSL customers with a single IP address?

No, it does not say anything about the number of addresses in the
assignment nor the layer-1 technology used. It is very common for
point-to-point links (the example given in section 6.2) to be assigned
/31 or /30. If the service provider and/or the customer is using a
first-hop redundancy protocol such as VRRP, it is necessary to assign a
/29 or larger.

In any case, there is no technological reason nor any policy limitation
that would prevent a service provider from assigning a preposterously
large prefix to a point-to-point link, like a /16, let's say.

> Assuming an LIR has chosen to use this new 'optional' status value.
> As many LIRs already have aggregated their DSL customers and tagged
> them as such in remarks attributes, why should they change it?

We do not expect the RIPE NCC to start a mass migration project as a
result of this policy proposal. It is our intention that assignments
made under the old policy would be grandfathered in, similar to how you
still see many objects with the obsoleted INFRA-AW tag remain in the
database today. LIRs would of course be free to change the status value
at any point, should they want to do so.

> 
> If it has this new aggregated status you still don't know if it is a
> block of maybe 1000 DSL customers of a collection of randomly sized
> assignments to End Users. You still need the free text remarks to
> avoid confusion.

You do not know that today, either, when it comes to aggregated
assignments made under the «solely for the connection» exception in
current IPv4 policy.

Such objects do not contain an assignment-size attribute, nor does
policy demand that all individual assignments contained within are of a
specific and uniform prefix length. Therefore, such assignments may
contain a hodgepodge of DSL customers, FTTH customers, business
customers, connected with or without VRRP, and so on. This would
continue to be permitted with AGGREGATED-BY-LIR.

Tore