You are here: Home > Participate > Join a Discussion > RIPE Forum
This mailing list interface will be retired once we upgrade our mailing list system. Click here to use the new RIPE NCC Forum.

Address Policy Working Group

Threaded
Collapse

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

User Image

Angela Dall'Ara

2022-10-04 09:43:54 CET

RIPE NCC staff member

Dear colleagues,

A new RIPE Policy Proposal, 2022-02, "Remove mandatory IPv4 PA 
assignment registration in the RIPE Database"

is now available for discussion.

This goal of this proposal is to change the registration of IPv4 
assignments from mandatory to optional.

You can find the full proposal at:

https://www.ripe.net/participate/policies/proposals/2022-02 


As per the RIPE Policy Development Process (PDP), the purpose of this 
four-week Discussion Phase is to discuss the proposal and provide 
feedback to the proposer.

At the end of the Discussion Phase, the proposer, with the agreement of 
the WG Chairs, will decide how to proceed with the proposal.

The PDP document can be found at:

https://www.ripe.net/publications/docs/ripe-781 


We encourage you to review this proposal and send your comments to

address-policy-wg _at_ ripe _dot_ net before 2 November 2022.

Kind regards,

Angela Dall'Ara

Policy Officer

RIPE NCC

Jan Ingvoldstad

2022-10-04 11:33:14 CET

Thanks for publishing this proposal.

I don't see how this proposal solves the issues it claims it is introduced
to solve. It rather seems to guarantee that information in the database
will increasingly become stale.

To break it down by rationale:

"One of the main reasons for registering IPv4 PA assignments was that LIRs
could show their use of IPv4 and thus justify the request for an additional
IPv4 allocation from the RIPE NCC. However, this requirement has become
obsolete since the RIPE NCC ran out of IPv4 addresses in 2019."

This merely means that this particular reason is no longer relevant for
IPv4 addresses.

"The application of IPv4 assignment registration policies in the RIPE
Database is inconsistent. Some resource holders flood the database with
tiny assignments (e.g. assignments for individual IP addresses), while many
others do not register any assignments."

This proposal does nothing to resolve the perceived database inconsistency,
there is no proposed cleanup of current database entries.

"This proposal is in line with the data consistency and data minimisation
principles (as defined in the DBTF report [3]:

   - Data stored in the RIPE Database should be adequate, relevant, and
   limited to only what is necessary.
   - It is recommended that resource registration requirements are applied
   consistently."

This proposal does not adequately describe this.

"Reduce the risk of LIRs registering personal data in the public database
for no longer beneficial administrative/policy reasons."

This is a red herring. If this was the goal of a proposal, why not propose
minimizing the amount of personal data, by e.g. restricting the use and
publication of personal names and personal e-mail addresses?

"More flexibility: LIRs can choose for themselves which information they
think is necessary to document and which is not, making it easier to adapt
to different situations."

This appears to be the core and only real argument for the proposal.

As the proposal stands, I am against it.
-- 
Jan
User Image

Sander Steffann

2022-10-04 13:53:21 CET

Hi,

>> To break it down by rationale:
>> 
>> "One of the main reasons for registering IPv4 PA assignments was that LIRs could show their use of IPv4 and thus justify the request for an additional IPv4 allocation from the RIPE NCC. However, this requirement has become obsolete since the RIPE NCC ran out of IPv4 addresses in 2019."
> 
> This merely means that this particular reason is no longer relevant for IPv4 addresses.

Justifying getting more PA Allocations was never the reason to document PA Assignments in the RIPE database. Its purpose is to document who to contact for administrative and technical issues concerning the IP addresses. Being able to use that data to verify that IP addresses are actually in use before allocating more was just a useful side effect.

I therefore oppose this rationale. I know that organisations are lazy and only properly document assignments when they want the benefits for themselves (i.e. getting another allocation). I think there is a more important decision to make here: do we still want this level of documentation for operational purposes?

If we don’t want/need this level of documentation anymore then sure, remove the mandatory PA assignment registration in the RIPE DB. But in that case rewrite the proposal to make that very explicit. Removing the requirement using the wrong arguments is misleading. Call it what it is.

Cheers,
Sander


User Image

Gert Doering

2022-10-04 15:05:32 CET

Hi,

On Tue, Oct 04, 2022 at 09:43:54AM +0200, Angela Dall'Ara wrote:
> A new RIPE Policy Proposal, 2022-02, "Remove mandatory IPv4 PA 
> assignment registration in the RIPE Database"
> 
> is now available for discussion.

This seems to be very similar to the pre-proposal sent by Jeroen in May,
which did not meet overwhelming support.  Like, I was highly sceptical,
and had a sub-discussion with James about the suspected intent, and
nobody spoke up in favour of going this way.

This formal proposal has some changes to the pre-proposal, but I can
still not support the motivation - one of the fundamental pillars of
RIPE address policy is "documentation", so argueing with, quote,
"unnecessary efforts by LIRs to register IPv4 prefixes and by the RIPE
NCC to ensure that LIRs complied with the policy" will meet very strong
resistance from side.

If we want to do away with registration requirements because we think
that knowing the holder of an address block is less important nowadays,
then say so.  But "the inconvenience of following the policy" is a very
bad reason to do away with it. 

The second rationale is "there is too much stuff in the DB that should
not be there" - since this was put in voluntarily by over-eager LIRs
(as it seems), I (still!) do not see how changing the registration from
"mandatory" to "voluntary" would change that.

I think having a BCP document that explains to LIRs what the community
expects to see in the RIPE DB ("for a netblock that has /32s assigned
to private end users, documenting the block only is considered better 
than having end user data in the RIPE DB", and stuff like that) is a 
much more useful way forward with perceived inconsistency between the
way LIRs handle the existing lack of guidance in this respect.


Technically, the "new policy text" wouldn't work the way it is written
- it says "Registration is the final step in making an allocation", but
the sentence before that says "... not mandatory".  Now what?

Also, "New Policy Text" brings a new section 3.0 after 4.0 :-)


Ceterum censeo: I still oppose this.

Gert Doering
        -- LIR admin, responsible for DB objects and end user assignments
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

denis walker

2022-10-04 15:25:18 CET

Colleagues

I have many things to say about this proposal but I will start with a
response to Sander's concern.

On Tue, 4 Oct 2022 at 13:53, Sander Steffann <sander _at_ steffann _dot_ nl> wrote:
>
> Hi,
>
> >> To break it down by rationale:
> >>
> >> "One of the main reasons for registering IPv4 PA assignments was that LIRs could show their use of IPv4 and thus justify the request for an additional IPv4 allocation from the RIPE NCC. However, this requirement has become obsolete since the RIPE NCC ran out of IPv4 addresses in 2019."
> >
> > This merely means that this particular reason is no longer relevant for IPv4 addresses.
>
> Justifying getting more PA Allocations was never the reason to document PA Assignments in the RIPE database. Its purpose is to document who to contact for administrative and technical issues concerning the IP addresses. Being able to use that data to verify that IP addresses are actually in use before allocating more was just a useful side effect.
>
> I therefore oppose this rationale. I know that organisations are lazy and only properly document assignments when they want the benefits for themselves (i.e. getting another allocation). I think there is a more important decision to make here: do we still want this level of documentation for operational purposes?

Again we are back to asking the question, "What is the purpose of the
RIPE Database in 2022?". I know this is like the elephant in the room.
I know most people look the other way every time I mention this topic.
BUT it is so fundamental to many discussions we are having. For
example, is the database still purely (or even primarily) only for
'operational purposes'? A term used so often that, like so many other
terms used in this industry, is not even defined anywhere. Is using
the content of the RIPE Database to stop the use of an IP address for
criminal  activity an 'operational purpose'. If someone is operating a
network using a block of IP addresses and abusing other users of the
internet, then surely knowing who is using that block of addresses and
being able to contact them has 'operational' value.

As Sander said, knowing how much of an allocation is in use was a side
effect of this policy. Knowing who is operating a network on a block
of addresses, and being able to contact them, is the real purpose of
this policy requirement to document assignments. If we allow LIRs to
choose what info to add to the database, those LIRs that knowingly
provide resources and services to abusive end users will obviously
choose not to document it. That may be used as a selling feature to
abusive end users, to obscure and delay their identification. Whilst
most LIRs take abuse seriously we all know there are some that don't.

I oppose this proposal.

cheers
denis
co-chair DB-WG

>
> If we don’t want/need this level of documentation anymore then sure, remove the mandatory PA assignment registration in the RIPE DB. But in that case rewrite the proposal to make that very explicit. Removing the requirement using the wrong arguments is misleading. Call it what it is.
>
> Cheers,
> Sander
>
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg

User Image

Angela Dall'Ara

2022-10-04 15:41:11 CET

RIPE NCC staff member

Hi Gert,

Thank you for your observation.
The paragraph numbering has been corrected.

Kind regards,
Angela

Angela Dall'Ara
Policy Officer
RIPE NCC

On 04/10/2022 15:05, Gert Doering wrote:
> Also, "New Policy Text" brings a new section 3.0 after 4.0 😄


User Image

Randy Bush

2022-10-04 17:46:28 CET

> Again we are back to asking the question, "What is the purpose of the
> RIPE Database in 2022?".

in this case, same as it ever was.  same as it ever was.

randy

User Image

João Luis Silva Damas

2022-10-04 17:57:37 CET

> On 4 Oct 2022, at 15:25, denis walker <ripedenis _at_ gmail _dot_ com> wrote:
> 
> Colleagues
> 
> I have many things to say about this proposal but I will start with a
> response to Sander's concern.
> 
> On Tue, 4 Oct 2022 at 13:53, Sander Steffann <sander _at_ steffann _dot_ nl> wrote:
>> 
>> Hi,
>> 
>>>> To break it down by rationale:
>>>> 
>>>> "One of the main reasons for registering IPv4 PA assignments was that LIRs could show their use of IPv4 and thus justify the request for an additional IPv4 allocation from the RIPE NCC. However, this requirement has become obsolete since the RIPE NCC ran out of IPv4 addresses in 2019."
>>> 
>>> This merely means that this particular reason is no longer relevant for IPv4 addresses.
>> 
>> Justifying getting more PA Allocations was never the reason to document PA Assignments in the RIPE database. Its purpose is to document who to contact for administrative and technical issues concerning the IP addresses. Being able to use that data to verify that IP addresses are actually in use before allocating more was just a useful side effect.
>> 
>> I therefore oppose this rationale. I know that organisations are lazy and only properly document assignments when they want the benefits for themselves (i.e. getting another allocation). I think there is a more important decision to make here: do we still want this level of documentation for operational purposes?
> 
> Again we are back to asking the question, "What is the purpose of the
> RIPE Database in 2022?”

My guess is that the fact the initial query protocol was called WHOIS and not WHATIS or even WHEREIS might be a good hint.

Joao



User Image

Sander Steffann

2022-10-04 18:05:28 CET

> Op 4 okt. 2022 om 17:46 heeft Randy Bush <randy _at_ psg _dot_ com> het volgende geschreven:
> 
> 
>> 
>> Again we are back to asking the question, "What is the purpose of the
>> RIPE Database in 2022?".
> 
> in this case, same as it ever was.  same as it ever was.

And you may ask yourself “what is this RIPE database?”

;)
Sander



User Image

Randy Bush

2022-10-04 18:11:14 CET

>>> Again we are back to asking the question, "What is the purpose of
>>> the RIPE Database in 2022?".
>> in this case, same as it ever was.  same as it ever was.
> And you may ask yourself $B!H(Bwhat is this RIPE database?$B!I(B

but it is not once in a lifetime.  this mind-game of omphaloskepsis
repeatedly drags us into the water flowing underground.

randy

User Image

Jérôme Nicolle

2022-10-04 19:56:03 CET

Hell all,

I'm thorned on this one.

While I fully understand RIPE NCC' willingness reduce the administrative 
burden on something that's supposed to be deprecated, we all know that 
the scarcity will introduce new challenges against fraudulent use of 
address space. If not with a fully documented assignments' database, we 
would loose a tool to mitigate abuse.

On the other hand, let's be realistic, only a very few of us document 
assignments in full, and in a way that's not actually bloating the database.

As far as I'm concerned, I see two scenarios :

- An ISP who wants to distinguish its infrastructure from its customers
- A more general provider delegating prefixes routed from other ASNs.

The second case is clearly closed : to get a route object, the INETNUM 
has to be specified.

On the former though, I know of some large ISPs moving customers behing 
CGNs using former infrastructure space and didn't declare it within the 
database. It's a nightmare when trying to enforce aggressive anti-spam 
policies.

Does it matter ? I think not.

I'd like to postpone this proposal until we get reports on clear cases 
and arguments to alleviate the administrative burden and cleanse the 
database, if any stands. The current policy being not uphold to the best 
standards doesn't seem to me as a meaningful reason to lighten what 
_should_ be our responsibility.

Best regards,

-- 
Jérôme Nicolle
+33 6 19 31 27 14

User Image

James Kennedy

2022-10-06 13:44:51 CET

Hello,

Just want to summarize my thoughts as a member of, but not speaking on
behalf of, the Database Requirements Task Force. APWG co-chair hat off.
Resulting report from the TF’s work is available here, including purposes
of the database, requirements, and resulting recommendations:
https://www.ripe.net/publications/docs/ripe-767

- I don’t read this policy proposal as a revolution to solve all RIPE
database issues. It's more a timely pruning exercise of policy that is and
has been extremely inconsistently applied (and comprehended?) by users of
the database. Clean-ups of existing data is not in scope.
- Whether or not it was an original intention, documenting assignments in
the database absolutely became *the* key functional mechanism for
justifying additional IPv4 PA space from the RIPE NCC. That very real and
very important function is now obsolete.
- Registering assignments would still be possible and is recommended in
this proposal “especially when LIRs want to sub-allocate or assign to
another entity (sub-allocated PA/assignments) parts of the IPv4 resources
they hold”. Indeed contact information for administrative and technical
matters was reported by the TF as a baseline requirement for the database.
Note LIR contact details are already in the database for every IP resource
they hold, and they could share different info for separate\more specific
networks if they so choose. No change there. However, *those who do not
want to* would not be forced by policy to pump additional inetnum objects
into a public database that the community has complained about already
containing much unreliable info (paraphrasing from multiple feedback). Are
those orgs and individuals really likely to keep such data accurate and
up-to-date?
- Re: GDBR, forcing IPv4 holders to create and maintain less entries can
only have a positive (albeit probably negligible) effect on personal data
in the database imho.
- Re: Abuse, good point and important topic. Open question – considering
orgs could still register assignments, how would this proposal have any
practical effect on potential abuse or fraudulent use of IP space?

Re: next steps – does the APWG see any value in exploring this topic
further in its current or any other form?

Regards,
James


On Tue, Oct 4, 2022 at 7:56 PM Jérôme Nicolle <jerome _at_ ceriz _dot_ fr> wrote:

> Hell all,
>
> I'm thorned on this one.
>
> While I fully understand RIPE NCC' willingness reduce the administrative
> burden on something that's supposed to be deprecated, we all know that
> the scarcity will introduce new challenges against fraudulent use of
> address space. If not with a fully documented assignments' database, we
> would loose a tool to mitigate abuse.
>
> On the other hand, let's be realistic, only a very few of us document
> assignments in full, and in a way that's not actually bloating the
> database.
>
> As far as I'm concerned, I see two scenarios :
>
> - An ISP who wants to distinguish its infrastructure from its customers
> - A more general provider delegating prefixes routed from other ASNs.
>
> The second case is clearly closed : to get a route object, the INETNUM
> has to be specified.
>
> On the former though, I know of some large ISPs moving customers behing
> CGNs using former infrastructure space and didn't declare it within the
> database. It's a nightmare when trying to enforce aggressive anti-spam
> policies.
>
> Does it matter ? I think not.
>
> I'd like to postpone this proposal until we get reports on clear cases
> and arguments to alleviate the administrative burden and cleanse the
> database, if any stands. The current policy being not uphold to the best
> standards doesn't seem to me as a meaningful reason to lighten what
> _should_ be our responsibility.
>
> Best regards,
>
> --
> Jérôme Nicolle
> +33 6 19 31 27 14
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change
> your subscription options, please visit:
> https://lists.ripe.net/mailman/listinfo/address-policy-wg
>
User Image

Gert Doering

2022-10-06 15:29:09 CET

Hi,

On Thu, Oct 06, 2022 at 01:44:51PM +0200, James Kennedy wrote:
> Re: next steps ??? does the APWG see any value in exploring this topic
> further in its current or any other form?

Speaking as an individual member of the APWG: not in this form, not
with the line of arguments and justification given in this proposal.

Let's agree on a problem statement first.  "We no longer need to
ask for more v4 space" is not a very compelling one.

My take on "if the problem statement is that different LIRs fill the
RIPE DB with data of very different granularity, and this is oh so
inconsistent!" is still that this is not a problem policy changes will
solve (unless you disallow registering ANY assignments, and remove
ALL existing objects = consistency) but that might be better tackled
by a BCP document, explaining to LIRs what "the community" expects them
to do.

It will still not magically fix different mindsets - or vastly different
customer bases - between LIRs, but at least for those that *are* seeking
for guidance ("should I register individual /32s, or preferably only the
whole block, and if yes, why?") we can create some.

Gert Doering
        -- LIR admin
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
User Image

Jeroen Lauwers

2022-10-07 16:18:18 CET

Hi Jan,

Thanks for your input.

I don't see how this proposal solves the issues it claims it is introduced to solve. It rather seems to guarantee that information in the database will increasingly become stale.

This policy proposal is technically only about inetnum objects and how far the LIR needs to specify (sub-)allocations in the RIPE DB. All the other information for abuse e.g. is already mentioned in the RIPE Database Terms and Conditions in article 6.2 and also Abuse Contact Management in the RIPE Database policy. Also if the LIR doesn’t need to spend time creating unnecessary objects they are probably more willing and also have more time to focus on the information that is more relevant.

Also, the new address policy says the following even when something similar is also mentioned in the Terms and Condition and in the Abuse Contact policy

"LIRs are responsible for the address space that they received by the RIPE NCC and must ensure that the registration data (range, contact information, status, etc.) in the database is maintained correct at all times and that operations such as abuse handling can be performed efficiently."

 So when an LIR not updates the information and let it get stale, they would handle against the policy.


"One of the main reasons for registering IPv4 PA assignments was that LIRs could show their use of IPv4 and thus justify the request for an additional IPv4 allocation from the RIPE NCC. However, this requirement has become obsolete since the RIPE NCC ran out of IPv4 addresses in 2019."

This merely means that this particular reason is no longer relevant for IPv4 addresses.

"The application of IPv4 assignment registration policies in the RIPE Database is inconsistent. Some resource holders flood the database with tiny assignments (e.g. assignments for individual IP addresses), while many others do not register any assignments."

This proposal does nothing to resolve the perceived database inconsistency, there is no proposed cleanup of current database entries.

"This proposal is in line with the data consistency and data minimisation principles (as defined in the DBTF report [3]:

  *   Data stored in the RIPE Database should be adequate, relevant, and limited to only what is necessary.
  *   It is recommended that resource registration requirements are applied consistently."

This proposal does not adequately describe this.

What your thinking is missing or could be improved to adequately describe it?


"Reduce the risk of LIRs registering personal data in the public database for no longer beneficial administrative/policy reasons."

This is a red herring. If this was the goal of a proposal, why not propose minimizing the amount of personal data, by e.g. restricting the use and publication of personal names and personal e-mail addresses?

"More flexibility: LIRs can choose for themselves which information they think is necessary to document and which is not, making it easier to adapt to different situations."

This appears to be the core and only real argument for the proposal.

The core reason is indeed for more flexibility for the LIR. But I think it is also good to note the side benefits/drawbacks of changing the policy for a complete picture.

Kind regards,

Jeroen

User Image

Jeroen Lauwers

2022-10-07 16:19:41 CET

Hi Sander,

Thanks for your point of view.

> Justifying getting more PA Allocations was never the reason to document PA Assignments in the RIPE database. Its purpose is to document who to contact for administrative and technical issues concerning the IP addresses. Being able to use that data to verify that IP addresses are actually in use before allocating more was just a useful side effect.

I agree that it is a side effect of the main goal. But I see that as the only reason why this current policy is still standing. That is why a big part of the policy proposal is about this and not to mislead people. 

> I therefore oppose this rationale. I know that organisations are lazy and only properly document assignments when they want the benefits for themselves (i.e. getting another allocation). I think there is a more important decision to make here: do we still want this level of documentation for operational purposes?
> 
> If we don’t want/need this level of documentation anymore then sure, remove the mandatory PA assignment registration in the RIPE DB. But in that case rewrite the proposal to make that very explicit. Removing the requirement using the wrong arguments is misleading. Call it what it is.


The main goal of the policy is to update it on the current situation and what is already happening in practice and to give more freedom to the LIR to decide how far in detail they want to register their (sub-)allocations in the RIPE DB. Of course, there needs to be always enough information for sufficient information gathering for things like abuse. This is already written down in the RIPE Database Terms and Conditions and the Abuse Contact Management in the RIPE Database policy. Getting another allocation is not possible anymore for IPv4.  

There are a lot of different situations imaginable with all their specific needs for the level of information. This you already can see back in the findings of the Database taskforce. So the question is do we want to update the policy to the current situation and still fill in enough information for abuse e.g. or do we want to enforce the current situation back to the policy? 

Feel free to let me know if the policy needs to be improved to show/explain better the goal of it. 

Kind regards,

Jeroen 


User Image

Jeroen Lauwers

2022-10-07 16:25:35 CET

Hi Gert,

Thank you also for your feedback.

This seems to be very similar to the pre-proposal sent by Jeroen in May,
which did not meet overwhelming support.  Like, I was highly sceptical,
and had a sub-discussion with James about the suspected intent, and
nobody spoke up in favour of going this way.

I tried to update the policy on the feedback that was given by the few people on the mailing list and at RIPE84.  What I understand as feedback was there shouldn’t be a difference in own usage or if it is used by a third party and the /25 problem is a database issue.

This formal proposal has some changes to the pre-proposal, but I can
still not support the motivation - one of the fundamental pillars of
RIPE address policy is "documentation", so argueing with, quote,
"unnecessary efforts by LIRs to register IPv4 prefixes and by the RIPE
NCC to ensure that LIRs complied with the policy" will meet very strong
resistance from side.

The proposal tries to aim for the extra work that needs to be done for making allocations in the RIPE DB. So it is just about the allocations and not about other information in the RIPE DB. I can imagine now you point it out, that the word choice could meet strong resistance. Would you maybe have an alternative for it?

If we want to do away with registration requirements because we think
that knowing the holder of an address block is less important nowadays,
then say so.  But "the inconvenience of following the policy" is a very
bad reason to do away with it.

Nowhere is concluded that knowing the holder of an address block is less important nowadays. In the end, the final responsibility is still at the LIR whereby this information is already in the database added by RIPE NCC itself. Next of that, it is still obligated (as the Terms and Conditions/Abuse Contact Management in the RIPE Database policy specifies) to put in enough information for efficient abuse handling for example. Also, the inconsistencies show that in practice not all information is added like the rules are telling. So at the moment, the policy is out of sync in comparison with what happens in reality. We have three options for this situation.
- One way we stronger enforce the current rules.
- The second one is to not do anything and keep the rules out of sync in comparison with reality.
- Or we can change the policy to what is already in real life happening

In my opinion, I think in this case it would be better to go for the 3rd option. It is better to focus on important information like the right contact information than if someone didn’t specify enough information about how their IPv4 prefix reservation is for their network.

Also, I think the bigger majority of the LIRs are more than willing to put enough information in the database to make sure everyone can get the information they need like in the case of abuse. LIRs that outsource the IP space to third parties also benefit from having the right information. What is left is a really small group of LIRs that don't keep to the rules. With this policy change, I don’t see any difference in effect in comparison with writing down the wrong information. Next of that, this is only about inetnum objects and not about contact information.

The second rationale is "there is too much stuff in the DB that should
not be there" - since this was put in voluntarily by over-eager LIRs
(as it seems), I (still!) do not see how changing the registration from
"mandatory" to "voluntary" would change that.

With changing from mandatory to voluntary we make sure that the LIR doesn’t get obligated to fill in repetitive information.


I think having a BCP document that explains to LIRs what the community
expects to see in the RIPE DB ("for a netblock that has /32s assigned
to private end users, documenting the block only is considered better
than having end user data in the RIPE DB", and stuff like that) is a
much more useful way forward with perceived inconsistency between the
way LIRs handle the existing lack of guidance in this respect.

A BCP would maybe help indeed. But even with the courses and certifications that are already available, there are still LIRs that don’t follow this guideline and find a more suitable way for them to document stuff. I don’t think that stronger enforcement is the right way of pushing LIRs to follow rules exactly that are for them not practical. Also, I think no one is waiting for the extra resources RIPE NCC would need to enforce this.

Personally, I think there is enough space to create the freedom for the LIR to choose what is suited best for the LIR itself. So there is space for changing the rules to what is already happening in practice. We can also try to think about a lot of situations different LIRs are facing and create a ton of rules for it with exceptions and all other stuff. But I think that just a guideline to "document what is needed” for inetnum objects is much more practical and saves everyone a bunch of overhead.

Technically, the "new policy text" wouldn't work the way it is written
- it says "Registration is the final step in making an allocation", but
the sentence before that says "... not mandatory".  Now what?

Also when the policy changes is still the registration the final step. The only difference is that the LIR can choose what to register for inetnum objects. But in the end, the IP block is already registered by RIPE NCC in the database, and also the right contact information still needs to be filled in.

Kind regards,

Jeroen

User Image

Jeroen Lauwers

2022-10-07 16:28:10 CET

Hi Jérôme,


While I fully understand RIPE NCC' willingness reduce the administrative burden on something that's supposed to be deprecated, we all know that the scarcity will introduce new challenges against fraudulent use of address space. If not with a fully documented assignments' database, we would loose a tool to mitigate abuse.

I don't think we would miss a tool against abuse after the policy change. LIRs would be still obligated by the Terms and Conditions as also Abuse Contact Management in the RIPE Database policy, to fill in enough information for sufficient contact handling and an abuse contact. Just to be sure this is extra specified in the new address policy that there needs to be enough good information to have sufficient abuse handling.


I'd like to postpone this proposal until we get reports on clear cases and arguments to alleviate the administrative burden and cleanse the database, if any stands. The current policy being not uphold to the best standards doesn't seem to me as a meaningful reason to lighten what _should_ be our responsibility.

Yeah, you can see it in the way that LIRs are not following the best standards or you can see it in the way that best standards are not suitable for every LIR. Personally, I think most of the LIRs don’t follow it, is because of that the best standards are not suitable for them.

Kind regards,

Jeroen
User Image

Jeroen Lauwers

2022-10-07 16:31:35 CET

Hi Denis,

Again we are back to asking the question, "What is the purpose of the
RIPE Database in 2022?". I know this is like the elephant in the room.
I know most people look the other way every time I mention this topic.

This policy proposal is not about the goal of the database itl is just about how far we obligate LIRs in filling in information for inetnum objects and how much freedom we give the LIR to decide it by themself. So technically the goal of the database stays the same.

BUT it is so fundamental to many discussions we are having. For
example, is the database still purely (or even primarily) only for
'operational purposes'? A term used so often that, like so many other
terms used in this industry, is not even defined anywhere. Is using
the content of the RIPE Database to stop the use of an IP address for
criminal  activity an 'operational purpose'. If someone is operating a
network using a block of IP addresses and abusing other users of the
internet, then surely knowing who is using that block of addresses and
being able to contact them has 'operational' value.

For sure we always need to keep this in mind. And I think it would be a good subject to discuss in the database working group. But so far I don’t see any reasons to be insecure about this after changing this policy.


As Sander said, knowing how much of an allocation is in use was a side
effect of this policy. Knowing who is operating a network on a block
of addresses, and being able to contact them, is the real purpose of
this policy requirement to document assignments. If we allow LIRs to
choose what info to add to the database, those LIRs that knowingly
provide resources and services to abusive end users will obviously
choose not to document it. That may be used as a selling feature to
abusive end users, to obscure and delay their identification. Whilst
most LIRs take abuse seriously we all know there are some that don't.

You are totally right. That is why this is only about inetnum objects. The LIR gets still obligated by the terms and conditions to fill in enough information for contacting efficient the maintainer as also By the Abuse Contact Management in the RIPE Database policy for having an abuse contact.

Kind regards,

Jeroen
User Image

David Farmer

2022-10-07 20:02:50 CET

On Tue, Oct 4, 2022 at 2:44 AM Angela Dall'Ara <adallara _at_ ripe _dot_ net> wrote:

>
> Dear colleagues,
>
>
>
> A new RIPE Policy Proposal, 2022-02, "Remove mandatory IPv4 PA assignment
> registration in the RIPE Database"
>
> is now available for discussion.
>
>
>
> This goal of this proposal is to change the registration of IPv4
> assignments from mandatory to optional.
>

The registration of IPv4 PA assignments should not be completely
optional. Using the word "optional" implies to me that the decision to
register an assignment or not is completely at the discretion of the LIR,
and I don't believe that is appropriate. LIRs should have an obligation to
register PA assignments if the registration is requested by the customer
who receives the assignment and/or if the assignment will be visible
outside the LIR's network, such as in the global route table. However,
registration of assignments not requested by the customer or that are not
visible outside the LIR's network should be at the LIR's discretion.

Thanks

-- 
===============================================
David Farmer               Email:farmer _at_ umn _dot_ edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

denis walker

2022-10-08 00:44:44 CET

Hi Jeroen

Your terminology is very confusing. You talk only about allocations
and sub-allocations and keep referring to INETNUMs. You never once
mention assignments. So my first question is what exactly is it that
you want to be optional?

The current policy says:

3.0 Goals of the Internet Registry System
...4.Registration: The provision of a public registry documenting
address space allocations and assignments must exist. This is
necessary to ensure uniqueness and to provide information for Internet
troubleshooting at all levels.
----
4.0 Registration Requirements
All assignments and allocations must be registered in the RIPE
Database. This is necessary to ensure uniqueness and to support
network operations.
----
6.2 Network Infrastructure and End User Networks
...When an End User has a network using public address space this must
be registered separately with the contact details of the End User.
----

The message from the current policy is very clear. End Users operating
public networks must be documented in the RIPE Database. There are two
historical reasons given, uniqueness AND network operations. You have
focused your argument on the fact that uniqueness of allocations is no
longer needed. But you have ignored the other stated reason. Using the
database to contact network operators for troubleshooting is one of
the original purposes of the database. So if you now want this
information to be optional and entered if an LIR feels like it, you
need to justify why internet troubleshooting is no longer necessary at
an End User network level.

When we talk about the purposes of the database we are not talking
about the purposes of the database as a container. We mean the
purposes of the data contained within the database. Over time this
data in the RIPE Database about End Users has been used, for example,
by LEAs and other investigators to identify the users as well as for
internet operational problem solving.

The Database Task Force acknowledged in their report (ripe-767) that
there are now different stakeholders who use the RIPE Database for
different reasons:

2. The Difference between the RIPE Database and the RIPE Registry
The information disclosed in the RIPE Database aims to facilitate
cooperation and coordination between network operators and other
stakeholders for a variety of operational tasks, including
troubleshooting and preventing outages.
---
3. Why are we reviewing the RIPE Database functionality now?
The RIPE Database provides essential information to members of the
RIPE community, which helps them to keep individual networks and the
overall Internet running in their region. Many stakeholders depend on
the accuracy and availability of the data stored in the database to do
their job properly, especially regarding cybersecurity. Some database
users, such as ISPs or IXPs, have been part of the RIPE community for
years, while others are relatively new, such as Law Enforcement
Agencies (LEAs) or regulators. These user groups have different needs
and expectations regarding the database
---
5.1 Data accuracy
The data added to the database should be accurate to ensure uniqueness
of Internet number resources and to provide reliable registration
information to all parties involved in network operations. For
example, contact details or information about a specific assignment
should be accurate to facilitate contact with and identification of
the organisation holding the assignment.
---
6.4 Purpose: Facilitating Internet operations and coordination
The RIPE Database should facilitate communication and cooperation
among stakeholders for the following reasons:
-Operational issues such as measuring or troubleshooting networks
-Handling abuse cases, supporting the handling of cyber incidents and
supporting LEA investigations
---

Unfortunately, the Task Force did not attempt to identify most of
these 'other' stakeholders or what data they need or why. So we are
left in a position where it has been acknowledged that many different
stakeholders exist that need data currently provided by the public IP
address registry, but who or what is unknown. There may well now be
stakeholders with very legitimate reasons for needing accurate
assignment data. Until we know more about these stakeholders we cannot
make informed decisions about the content of the database. But the
Task Force then went on to make a recommendation about assignments
based on the rationale "A core reason for registration of IPv4 PA
assignments was to justify an LIR’s need for additional IPv4 allocated
address space. However, since the RIPE NCC ran out of IPv4 in 2019,
this policy has been rendered obsolete." Just as you are doing in this
proposal, they conveniently ignored the main reason(s) for documenting
assignments and focused on one obsolete reason.

The Task Force recommendation was "that as resource holders have full
responsibility over the registration of their IPv4 PA assignment(s),
they are free to make assignments or not." Which is also the basis of
your proposal. The people entering data into a public IP address
registry are not necessarily the ones who should be able to decide
what data must be contained in the registry. You need to consider the
requirements of different aspects of the industry and even the needs
of the wider (public) community (the stakeholders).

I do not think we are currently in a position to make an informed
decision on this Task Force recommendation or your policy proposal.

cheers
denis
co-chair DB-WG


On Fri, 7 Oct 2022 at 16:31, Jeroen Lauwers <jlauwers _at_ a2b-internet _dot_ com> wrote:
>
> Hi Denis,
>
> Again we are back to asking the question, "What is the purpose of the
> RIPE Database in 2022?". I know this is like the elephant in the room.
> I know most people look the other way every time I mention this topic.
>
>
> This policy proposal is not about the goal of the database itl is just about how far we obligate LIRs in filling in information for inetnum objects and how much freedom we give the LIR to decide it by themself. So technically the goal of the database stays the same.
>
> BUT it is so fundamental to many discussions we are having. For
> example, is the database still purely (or even primarily) only for
> 'operational purposes'? A term used so often that, like so many other
> terms used in this industry, is not even defined anywhere. Is using
> the content of the RIPE Database to stop the use of an IP address for
> criminal  activity an 'operational purpose'. If someone is operating a
> network using a block of IP addresses and abusing other users of the
> internet, then surely knowing who is using that block of addresses and
> being able to contact them has 'operational' value.
>
>
> For sure we always need to keep this in mind. And I think it would be a good subject to discuss in the database working group. But so far I don’t see any reasons to be insecure about this after changing this policy.
>
>
> As Sander said, knowing how much of an allocation is in use was a side
> effect of this policy. Knowing who is operating a network on a block
> of addresses, and being able to contact them, is the real purpose of
> this policy requirement to document assignments. If we allow LIRs to
> choose what info to add to the database, those LIRs that knowingly
> provide resources and services to abusive end users will obviously
> choose not to document it. That may be used as a selling feature to
> abusive end users, to obscure and delay their identification. Whilst
> most LIRs take abuse seriously we all know there are some that don't.
>
>
> You are totally right. That is why this is only about inetnum objects. The LIR gets still obligated by the terms and conditions to fill in enough information for contacting efficient the maintainer as also By the Abuse Contact Management in the RIPE Database policy for having an abuse contact.
>
> Kind regards,
>
> Jeroen

User Image

James Kennedy

2022-10-08 11:14:29 CET

Denis,

Thanks for repeating your position. Once again. It is already noted.

> Unfortunately, the Task Force did not attempt to identify most of these
'other' stakeholders or what data they need or why. So […]

You are wrong, Denis. The task force did in fact consider all stakeholders
that we could possibly think of, and their needs for the database. We
decided not to create and publish a definitive list of stakeholders in our
report because, well, who are we to decide who qualifies or not as a
legitimate stakeholder of the RIPE database in 2021? Should such a list be
reviewed annually to be kept up-to-date and accurate? Should there also be
an accompanying list of their (changing) individual requirements
maintained, and why? Who should do all that work, how? Looking forward to
reading your list :)

In the meantime, rather than perpetually navel gaze or crusade for a new
RIPE database, the scope of this proposal - and focus of this discussion -
is the potential change of address policy that states holders of PA IPv4
'must' register assignments in the database to 'should' register
assignments. For the reasons outlined in the proposal, which to me
personally read clear and reasonable.

We would love to hear what others in the working group think about this
policy proposal. The more people we have sharing their thoughts, the better
and healthier for the working group!

Regards,
James

On Fri, Oct 7, 2022 at 11:45 PM denis walker <ripedenis _at_ gmail _dot_ com> wrote:

> Hi Jeroen
>
> Your terminology is very confusing. You talk only about allocations
> and sub-allocations and keep referring to INETNUMs. You never once
> mention assignments. So my first question is what exactly is it that
> you want to be optional?
>
> The current policy says:
>
> 3.0 Goals of the Internet Registry System
> ...4.Registration: The provision of a public registry documenting
> address space allocations and assignments must exist. This is
> necessary to ensure uniqueness and to provide information for Internet
> troubleshooting at all levels.
> ----
> 4.0 Registration Requirements
> All assignments and allocations must be registered in the RIPE
> Database. This is necessary to ensure uniqueness and to support
> network operations.
> ----
> 6.2 Network Infrastructure and End User Networks
> ...When an End User has a network using public address space this must
> be registered separately with the contact details of the End User.
> ----
>
> The message from the current policy is very clear. End Users operating
> public networks must be documented in the RIPE Database. There are two
> historical reasons given, uniqueness AND network operations. You have
> focused your argument on the fact that uniqueness of allocations is no
> longer needed. But you have ignored the other stated reason. Using the
> database to contact network operators for troubleshooting is one of
> the original purposes of the database. So if you now want this
> information to be optional and entered if an LIR feels like it, you
> need to justify why internet troubleshooting is no longer necessary at
> an End User network level.
>
> When we talk about the purposes of the database we are not talking
> about the purposes of the database as a container. We mean the
> purposes of the data contained within the database. Over time this
> data in the RIPE Database about End Users has been used, for example,
> by LEAs and other investigators to identify the users as well as for
> internet operational problem solving.
>
> The Database Task Force acknowledged in their report (ripe-767) that
> there are now different stakeholders who use the RIPE Database for
> different reasons:
>
> 2. The Difference between the RIPE Database and the RIPE Registry
> The information disclosed in the RIPE Database aims to facilitate
> cooperation and coordination between network operators and other
> stakeholders for a variety of operational tasks, including
> troubleshooting and preventing outages.
> ---
> 3. Why are we reviewing the RIPE Database functionality now?
> The RIPE Database provides essential information to members of the
> RIPE community, which helps them to keep individual networks and the
> overall Internet running in their region. Many stakeholders depend on
> the accuracy and availability of the data stored in the database to do
> their job properly, especially regarding cybersecurity. Some database
> users, such as ISPs or IXPs, have been part of the RIPE community for
> years, while others are relatively new, such as Law Enforcement
> Agencies (LEAs) or regulators. These user groups have different needs
> and expectations regarding the database
> ---
> 5.1 Data accuracy
> The data added to the database should be accurate to ensure uniqueness
> of Internet number resources and to provide reliable registration
> information to all parties involved in network operations. For
> example, contact details or information about a specific assignment
> should be accurate to facilitate contact with and identification of
> the organisation holding the assignment.
> ---
> 6.4 Purpose: Facilitating Internet operations and coordination
> The RIPE Database should facilitate communication and cooperation
> among stakeholders for the following reasons:
> -Operational issues such as measuring or troubleshooting networks
> -Handling abuse cases, supporting the handling of cyber incidents and
> supporting LEA investigations
> ---
>
> Unfortunately, the Task Force did not attempt to identify most of
> these 'other' stakeholders or what data they need or why. So we are
> left in a position where it has been acknowledged that many different
> stakeholders exist that need data currently provided by the public IP
> address registry, but who or what is unknown. There may well now be
> stakeholders with very legitimate reasons for needing accurate
> assignment data. Until we know more about these stakeholders we cannot
> make informed decisions about the content of the database. But the
> Task Force then went on to make a recommendation about assignments
> based on the rationale "A core reason for registration of IPv4 PA
> assignments was to justify an LIR’s need for additional IPv4 allocated
> address space. However, since the RIPE NCC ran out of IPv4 in 2019,
> this policy has been rendered obsolete." Just as you are doing in this
> proposal, they conveniently ignored the main reason(s) for documenting
> assignments and focused on one obsolete reason.
>
> The Task Force recommendation was "that as resource holders have full
> responsibility over the registration of their IPv4 PA assignment(s),
> they are free to make assignments or not." Which is also the basis of
> your proposal. The people entering data into a public IP address
> registry are not necessarily the ones who should be able to decide
> what data must be contained in the registry. You need to consider the
> requirements of different aspects of the industry and even the needs
> of the wider (public) community (the stakeholders).
>
> I do not think we are currently in a position to make an informed
> decision on this Task Force recommendation or your policy proposal.
>
> cheers
> denis
> co-chair DB-WG
>
>
> On Fri, 7 Oct 2022 at 16:31, Jeroen Lauwers <jlauwers _at_ a2b-internet _dot_ com>
> wrote:
> >
> > Hi Denis,
> >
> > Again we are back to asking the question, "What is the purpose of the
> > RIPE Database in 2022?". I know this is like the elephant in the room.
> > I know most people look the other way every time I mention this topic.
> >
> >
> > This policy proposal is not about the goal of the database itl is just
> about how far we obligate LIRs in filling in information for inetnum
> objects and how much freedom we give the LIR to decide it by themself. So
> technically the goal of the database stays the same.
> >
> > BUT it is so fundamental to many discussions we are having. For
> > example, is the database still purely (or even primarily) only for
> > 'operational purposes'? A term used so often that, like so many other
> > terms used in this industry, is not even defined anywhere. Is using
> > the content of the RIPE Database to stop the use of an IP address for
> > criminal  activity an 'operational purpose'. If someone is operating a
> > network using a block of IP addresses and abusing other users of the
> > internet, then surely knowing who is using that block of addresses and
> > being able to contact them has 'operational' value.
> >
> >
> > For sure we always need to keep this in mind. And I think it would be a
> good subject to discuss in the database working group. But so far I don’t
> see any reasons to be insecure about this after changing this policy.
> >
> >
> > As Sander said, knowing how much of an allocation is in use was a side
> > effect of this policy. Knowing who is operating a network on a block
> > of addresses, and being able to contact them, is the real purpose of
> > this policy requirement to document assignments. If we allow LIRs to
> > choose what info to add to the database, those LIRs that knowingly
> > provide resources and services to abusive end users will obviously
> > choose not to document it. That may be used as a selling feature to
> > abusive end users, to obscure and delay their identification. Whilst
> > most LIRs take abuse seriously we all know there are some that don't.
> >
> >
> > You are totally right. That is why this is only about inetnum objects.
> The LIR gets still obligated by the terms and conditions to fill in enough
> information for contacting efficient the maintainer as also By the Abuse
> Contact Management in the RIPE Database policy for having an abuse contact.
> >
> > Kind regards,
> >
> > Jeroen
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change
> your subscription options, please visit:
> https://lists.ripe.net/mailman/listinfo/address-policy-wg
>

denis walker

2022-10-10 22:33:56 CET

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

User Image

James Kennedy

2022-10-19 09:37:03 CET

Hello,

I agree with David. After further thought, I believe the registration of PA
Assignments that are used by entities other than the holding LIR should
remain *mandatory*. For reasons of transparency and well, to know who is
using the IP space.

But I still believe there would be benefit in changing the registration
policy of LIR infrastructure Assignments to *optional*. Why? Primarily to:
a. Reduce data duplication. The LIR’s tech and admin contact info is
already contained in the parent PA Allocation (and also in several other
LIR objects).
b. Support data accuracy. Anecdotal but from my experience of managing
multiple LIRs of different sizes and their address space over the years, I
know that simply having less objects to maintain in the RIPE database makes
it easier, and more likely, for the LIR admin to keep their data
up-to-date.

Interesting stats (thanks Ed!):
- Total IPv4 PA Allocations in the database today = 60,587
- Allocations without any Assignment = 18,157 (30% of total)
- 14,744 of those 18,157 childless Allocations have a covering route object
Under current policy, the LIRs should register 14,744 - 29,488 additional
Assignment inetnums in the RIPE database. What value would that bring?

I also like Gert’s suggestion to better educate LIRs about what the
community expects of them – incl. database registration – in a BCP
document. Both efforts can help improve data management in the RIPE
Database going forward.

Regards,
James


On Fri, Oct 7, 2022 at 8:03 PM David Farmer via address-policy-wg <
address-policy-wg _at_ ripe _dot_ net> wrote:

>
>
> On Tue, Oct 4, 2022 at 2:44 AM Angela Dall'Ara <adallara _at_ ripe _dot_ net> wrote:
>
>>
>> Dear colleagues,
>>
>>
>>
>> A new RIPE Policy Proposal, 2022-02, "Remove mandatory IPv4 PA assignment
>> registration in the RIPE Database"
>>
>> is now available for discussion.
>>
>>
>>
>> This goal of this proposal is to change the registration of IPv4
>> assignments from mandatory to optional.
>>
>
> The registration of IPv4 PA assignments should not be completely
> optional. Using the word "optional" implies to me that the decision to
> register an assignment or not is completely at the discretion of the LIR,
> and I don't believe that is appropriate. LIRs should have an obligation to
> register PA assignments if the registration is requested by the customer
> who receives the assignment and/or if the assignment will be visible
> outside the LIR's network, such as in the global route table. However,
> registration of assignments not requested by the customer or that are not
> visible outside the LIR's network should be at the LIR's discretion.
>
> Thanks
>
> --
> ===============================================
> David Farmer               Email:farmer _at_ umn _dot_ edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change
> your subscription options, please visit:
> https://lists.ripe.net/mailman/listinfo/address-policy-wg
>

Jan Ingvoldstad

2022-10-19 14:26:04 CET

On Wed, Oct 19, 2022 at 9:37 AM James Kennedy <jameskennedy001 _at_ gmail _dot_ com>
wrote:

>
> Under current policy, the LIRs should register 14,744 - 29,488 additional
> Assignment inetnums in the RIPE database. What value would that bring?
>

It brings value in resolving technical issues and IP address abuse issues,
e.g. contacting the correct party when a compromised server participates in
DDoS, spamming/phishing, etc.

Contacting the LIR only vaguely makes sense, it's like contacting the
domain registrar because someone is sending phishing mail from gmail.com.
In other words, mostly completely useless.

Additionally, introducing this policy change without also doing something
about historical records, seems pointless.

See also previous comments from myself, Gert, Denis, and so on.

If you have questions regarding our varying takes on this issue, please
ask! It's easier to discuss when it's clearer that we're reading each other
clearly.
-- 
Jan
User Image

James Kennedy

2022-10-19 15:45:07 CET

On Wed, Oct 19, 2022 at 2:26 PM Jan Ingvoldstad <frettled _at_ gmail _dot_ com> wrote:

> On Wed, Oct 19, 2022 at 9:37 AM James Kennedy <jameskennedy001 _at_ gmail _dot_ com>
> wrote:
>
>>
>> Under current policy, the LIRs should register 14,744 - 29,488 additional
>> Assignment inetnums in the RIPE database. What value would that bring?
>>
>
> It brings value in resolving technical issues and IP address abuse issues,
> e.g. contacting the correct party when a compromised server participates in
> DDoS, spamming/phishing, etc.
>
> Contacting the LIR only vaguely makes sense, it's like contacting the
> domain registrar because someone is sending phishing mail from gmail.com.
> In other words, mostly completely useless.
>

Understood and agreed if those details are different then they absolutely
should be registered in an assignment. Which the LIR could still do in the
scenario I mentioned. But the LIR could also decide not to register if the
infra assignment would simply duplicate their existing data. Which many
LIRs already do.

Anyway, I don’t intend on pushing the river or repeating my perspective
further. Just wanted to share my two cents :)

Regards,
James
[community member, apwg co-chair hat off]
User Image

Leo Vegoda

2022-10-20 18:09:43 CET

Hi Jan,

On Wed, 19 Oct 2022 at 05:26, Jan Ingvoldstad <frettled _at_ gmail _dot_ com> wrote:
>
> On Wed, Oct 19, 2022 at 9:37 AM James Kennedy <jameskennedy001 _at_ gmail _dot_ com> wrote:
>>
>>
>> Under current policy, the LIRs should register 14,744 - 29,488 additional Assignment inetnums in the RIPE database. What value would that bring?
>
>
> It brings value in resolving technical issues and IP address abuse issues, e.g. contacting the correct party when a compromised server participates in DDoS, spamming/phishing, etc.
>
> Contacting the LIR only vaguely makes sense, it's like contacting the domain registrar because someone is sending phishing mail from gmail.com. In other words, mostly completely useless.

Can you please expand on this? People without your experience might
not understand the processes you are referring to. Can you explain the
problems that users need to resolve and the value that registration of
small assignments in the database brings?

> Additionally, introducing this policy change without also doing something about historical records, seems pointless.

Can you expand on this, too?

Many thanks,

Leo Vegoda, Address Policy WG co-chair

Nick Hilliard

2022-10-22 00:27:43 CET

denis walker wrote on 10/10/2022 21:33:
> 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

Denis,

rfc7020 is an informational rfc, not BCP or Standards Track. I.e. it is 
intended to be descriptive rather than prescriptive.  If the RIPE 
Community wants to change how assignments are documented, it can do this.

Nick

User Image

Andreas Worbs

2022-10-24 10:04:38 CET

As many arguments were already mentioned and i think we need to know who 
is responsible for ressource, i strongly oppose this proposal.


Am 04.10.22 um 09:43 schrieb Angela Dall'Ara:
>
> Dear colleagues,
>
> A new RIPE Policy Proposal, 2022-02, "Remove mandatory IPv4 PA 
> assignment registration in the RIPE Database"
>
> is now available for discussion.
>
> This goal of this proposal is to change the registration of IPv4 
> assignments from mandatory to optional.
>
> You can find the full proposal at:
>
> https://www.ripe.net/participate/policies/proposals/2022-02 
> 
>
> As per the RIPE Policy Development Process (PDP), the purpose of this 
> four-week Discussion Phase is to discuss the proposal and provide 
> feedback to the proposer.
>
> At the end of the Discussion Phase, the proposer, with the agreement 
> of the WG Chairs, will decide how to proceed with the proposal.
>
> The PDP document can be found at:
>
> https://www.ripe.net/publications/docs/ripe-781 
> 
>
> We encourage you to review this proposal and send your comments to
>
> address-policy-wg _at_ ripe _dot_ net before 2 November 2022.
>
> Kind regards,
>
> Angela Dall'Ara
> Policy Officer
> RIPE NCC
>
>
-- 
Mit freundlichem Gruß

Artfiles New Media GmbH

Andreas Worbs


Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg
Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95
E-Mail:support _at_ artfiles _dot_ de  | Web:http://www.artfiles.de
Geschäftsführer: Harald Oltmanns | Tim Evers
Eingetragen im Handelsregister Hamburg - HRB 81478

Jan Ingvoldstad

2022-10-24 12:50:01 CET

On Thu, Oct 20, 2022 at 6:10 PM Leo Vegoda <leo _at_ vegoda _dot_ org> wrote:

> Hi Jan,
>

Hi Leo,


>
> On Wed, 19 Oct 2022 at 05:26, Jan Ingvoldstad <frettled _at_ gmail _dot_ com> wrote:
> >
> > Contacting the LIR only vaguely makes sense, it's like contacting the
> domain registrar because someone is sending phishing mail from gmail.com.
> In other words, mostly completely useless.
>
> Can you please expand on this? People without your experience might
> not understand the processes you are referring to. Can you explain the
> problems that users need to resolve and the value that registration of
> small assignments in the database brings?
>

Okay. Let's say that there is an ongoing phishing campaign. A CERT or abuse
department investigates, finds that IP address A.B.C.D is hosting malicious
content.

Currently, abuse departments can then use a locally installed whois tool to
query ARIN, RIPE etc. whois databases to find out what the presumed correct
contact point is, both for the purpose of disabling the phishing campaign.

However, if the contact point is a LIR, instead of the end user, this means
that the LIR's abuse department gets all the complaints and police
contacts, increasing workload and delaying action, if any is taken at all.

In phishing and other kinds of IP-traceable abuse, time is of the essence,
so accurate and direct contact information for the party responsible is
vital.

It is therefore better to have a database of contact points with some
errors in it, than a database that, over time, is designed to become
useless.


> > Additionally, introducing this policy change without also doing
> something about historical records, seems pointless.
>
> Can you expand on this, too?
>

If small assignments, for whatever value of "small", do not have value and
are only causing extra work, the obvious thing to do is to purge the
database of these records as well.

However, there is no proposal to do so, and that means that this policy
proposal only suggests making very modest changes in how the database is
managed, with dubious benefits.

-- 
Jan
User Image

Leo Vegoda

2022-10-24 13:02:19 CET

Hi Jan,

On Mon, 24 Oct 2022 at 03:50, Jan Ingvoldstad <frettled _at_ gmail _dot_ com> wrote:
>> On Wed, 19 Oct 2022 at 05:26, Jan Ingvoldstad <frettled _at_ gmail _dot_ com> wrote:
>> >
>> > Contacting the LIR only vaguely makes sense, it's like contacting the domain registrar because someone is sending phishing mail from gmail.com. In other words, mostly completely useless.
>>
>> Can you please expand on this? People without your experience might
>> not understand the processes you are referring to. Can you explain the
>> problems that users need to resolve and the value that registration of
>> small assignments in the database brings?
>
>
> Okay. Let's say that there is an ongoing phishing campaign. A CERT or abuse department investigates, finds that IP address A.B.C.D is hosting malicious content.
>
> Currently, abuse departments can then use a locally installed whois tool to query ARIN, RIPE etc. whois databases to find out what the presumed correct contact point is, both for the purpose of disabling the phishing campaign.
>
> However, if the contact point is a LIR, instead of the end user, this means that the LIR's abuse department gets all the complaints and police contacts, increasing workload and delaying action, if any is taken at all.
>
> In phishing and other kinds of IP-traceable abuse, time is of the essence, so accurate and direct contact information for the party responsible is vital.
>
> It is therefore better to have a database of contact points with some errors in it, than a database that, over time, is designed to become useless.

Does this approach rely on the registered user knowing about their
network and Internet connection? What happens when everything was
installed by an external contractor?

>> > Additionally, introducing this policy change without also doing something about historical records, seems pointless.
>>
>> Can you expand on this, too?
>
>
> If small assignments, for whatever value of "small", do not have value and are only causing extra work, the obvious thing to do is to purge the database of these records as well.
>
> However, there is no proposal to do so, and that means that this policy proposal only suggests making very modest changes in how the database is managed, with dubious benefits.

As I read the proposal, it is intended to allow LIRs to prune the
records they believe do not add value. It would enable discretion,
rather than blind obedience. Is that a negative? If so, why?

Kind regards,

Leo Vegoda, Address Policy WG co-chair

User Image

Gert Doering

2022-10-24 13:15:38 CET

Hi,

On Mon, Oct 24, 2022 at 04:02:19AM -0700, Leo Vegoda wrote:
> As I read the proposal, it is intended to allow LIRs to prune the
> records they believe do not add value. It would enable discretion,
> rather than blind obedience. Is that a negative? If so, why?

This puts an enormous amount of trust on the LIR, of which we have
manythousands, in all sorts of experience and responsibility levels.

If I, as a LIR contact, choose to decide "this is only work for me, it
adds no value for me", I can use that argument to put no records at all
whatsoever into the RIPE DB, no?

... which would be absolutely contrary to one of the fundamental pillars
of address policy "registration where the addresses are".

Gert Doering
        -- LIR admin, and lazy at that
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

Jan Ingvoldstad

2022-10-24 13:43:42 CET

On Mon, Oct 24, 2022 at 1:02 PM Leo Vegoda <leo _at_ vegoda _dot_ org> wrote:

> Hi Jan,
>
> Hi, Leo!


> On Mon, 24 Oct 2022 at 03:50, Jan Ingvoldstad <frettled _at_ gmail _dot_ com> wrote:
> Does this approach rely on the registered user knowing about their
> network and Internet connection? What happens when everything was
> installed by an external contractor?
>

I'm sorry, I don't understand. What does who installed a network have to do
with this?

You get in touch with an abuse contact, which is supposed to be whoever is
responsible for handling abuse complaints for a network address.

If a contractor's email address is somehow in there, then the contractor
should know that their email address is listed as abuse contact, and when
someone gets in touch about abusive content/behaviour hosted at A.B.C.D,
either do something about it, or forward to the correct contact point.

The same goes for any other scenario.


> As I read the proposal, it is intended to allow LIRs to prune the
> records they believe do not add value. It would enable discretion,
> rather than blind obedience. Is that a negative? If so, why?
>

This is putting the cart before the horse. The proposal should argue why
this is a positive.

-- 
Jan
User Image

Leo Vegoda

2022-10-24 16:25:34 CET

Hi Jan,

On Mon, 24 Oct 2022 at 04:44, Jan Ingvoldstad <frettled _at_ gmail _dot_ com> wrote:
> On Mon, Oct 24, 2022 at 1:02 PM Leo Vegoda <leo _at_ vegoda _dot_ org> wrote:
>> On Mon, 24 Oct 2022 at 03:50, Jan Ingvoldstad <frettled _at_ gmail _dot_ com> wrote:
>> Does this approach rely on the registered user knowing about their
>> network and Internet connection? What happens when everything was
>> installed by an external contractor?
>
> I'm sorry, I don't understand. What does who installed a network have to do with this?
>
> You get in touch with an abuse contact, which is supposed to be whoever is responsible for handling abuse complaints for a network address.
>
> If a contractor's email address is somehow in there, then the contractor should know that their email address is listed as abuse contact, and when someone gets in touch about abusive content/behaviour hosted at A.B.C.D, either do something about it, or forward to the correct contact point.
>
> The same goes for any other scenario.

I am trying to understand the difference between an assignment that
lists a company name but has all the contact information pointing at
the LIR and just relying on the contact data in the allocation. Is
there any difference?

>> As I read the proposal, it is intended to allow LIRs to prune the
>> records they believe do not add value. It would enable discretion,
>> rather than blind obedience. Is that a negative? If so, why?
>
>
> This is putting the cart before the horse. The proposal should argue why this is a positive.

You are right. The obligation is on the proposal. But it is often
helpful to look at the complete picture when evaluating a proposal.

Kind regards,

Leo Vegoda, Address Policy WG co-chair

denis walker

2022-10-24 23:09:53 CET

HI Leo

On Mon, 24 Oct 2022 at 16:25, Leo Vegoda <leo _at_ vegoda _dot_ org> wrote:
>
> Hi Jan,
>
> On Mon, 24 Oct 2022 at 04:44, Jan Ingvoldstad <frettled _at_ gmail _dot_ com> wrote:
> > On Mon, Oct 24, 2022 at 1:02 PM Leo Vegoda <leo _at_ vegoda _dot_ org> wrote:
> >> On Mon, 24 Oct 2022 at 03:50, Jan Ingvoldstad <frettled _at_ gmail _dot_ com> wrote:
> >> Does this approach rely on the registered user knowing about their
> >> network and Internet connection? What happens when everything was
> >> installed by an external contractor?
> >
> > I'm sorry, I don't understand. What does who installed a network have to do with this?
> >
> > You get in touch with an abuse contact, which is supposed to be whoever is responsible for handling abuse complaints for a network address.
> >
> > If a contractor's email address is somehow in there, then the contractor should know that their email address is listed as abuse contact, and when someone gets in touch about abusive content/behaviour hosted at A.B.C.D, either do something about it, or forward to the correct contact point.
> >
> > The same goes for any other scenario.
>
> I am trying to understand the difference between an assignment that
> lists a company name but has all the contact information pointing at
> the LIR and just relying on the contact data in the allocation. Is
> there any difference?

Yes. It is not only about contacting but also identifying. It seems to
be an 'accepted practice' to list the name and address of the 'holder'
of the assignment in the "descr:" attribute. This is regardless of who
an operator might contact for network or abuse issues.

cheers
denis

>
> >> As I read the proposal, it is intended to allow LIRs to prune the
> >> records they believe do not add value. It would enable discretion,
> >> rather than blind obedience. Is that a negative? If so, why?
> >
> >
> > This is putting the cart before the horse. The proposal should argue why this is a positive.
>
> You are right. The obligation is on the proposal. But it is often
> helpful to look at the complete picture when evaluating a proposal.
>
> Kind regards,
>
> Leo Vegoda, Address Policy WG co-chair
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg

User Image

Tore Anderson

2022-10-31 13:49:46 CET

* Gert Doering

> On Mon, Oct 24, 2022 at 04:02:19AM -0700, Leo Vegoda wrote:
> > As I read the proposal, it is intended to allow LIRs to prune the
> > records they believe do not add value. It would enable discretion,
> > rather than blind obedience. Is that a negative? If so, why?
> 
> This puts an enormous amount of trust on the LIR, of which we have
> manythousands, in all sorts of experience and responsibility levels.
> 
> If I, as a LIR contact, choose to decide "this is only work for me, it
> adds no value for me", I can use that argument to put no records at all
> whatsoever into the RIPE DB, no?
> 
> ... which would be absolutely contrary to one of the fundamental pillars
> of address policy "registration where the addresses are".

I never quite understood why we appear to be totally OK with not
requiring each individual IPv6 customer assignment to be registered in
the database, while we continue to require it for IPv4.

In IPv6, LIRs may create an status:AGGREGATED-BY-LIR inet6num,
essentially saying something like «in this block there are a gazillion
end users, and I am the tech/abuse contact for all of them».

In IPv4, there is no such option. The LIR is required by policy to
create a gazillion individual status:ASSIGNED inetnums instead, all
containing the exact same contact info. These do not add any value
though, they're just a PITA to maintain.

Is there any particular reason why we can't simply "backport"
status:AGGREGATED-BY-LIR to IPv4?

Tore

User Image

Gert Doering

2022-10-31 14:13:51 CET

Hi,

On Mon, Oct 31, 2022 at 01:49:46PM +0100, Tore Anderson wrote:
> I never quite understood why we appear to be totally OK with not
> requiring each individual IPv6 customer assignment to be registered in
> the database, while we continue to require it for IPv4.

For pool assignments (dynamic IP addresses handed out to dial-in
customers), we as a LIR just registered them as ASSIGNED PA assigned
to ourselves (and "back then" these assignments fell under the
INFRA-AW clause).

But for "static assignments", I think policy never permitted this.

> In IPv6, LIRs may create an status:AGGREGATED-BY-LIR inet6num,
> essentially saying something like «in this block there are a gazillion
> end users, and I am the tech/abuse contact for all of them».
> 
> In IPv4, there is no such option. The LIR is required by policy to
> create a gazillion individual status:ASSIGNED inetnums instead, all
> containing the exact same contact info. These do not add any value
> though, they're just a PITA to maintain.
> 
> Is there any particular reason why we can't simply "backport"
> status:AGGREGATED-BY-LIR to IPv4?

The way you word it for IPv6 seems to make sense for IPv4 as well - so
yes, this sounds like a good idea to cover the "these addresses are
assigned, but there is no interesting contact info here" aspect, and
at the same time making IPv4 and IPv6 policy less different.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
User Image

Tore Anderson

2022-10-31 14:41:05 CET

* Gert Doering

> On Mon, Oct 31, 2022 at 01:49:46PM +0100, Tore Anderson wrote:
> > I never quite understood why we appear to be totally OK with not
> > requiring each individual IPv6 customer assignment to be registered in
> > the database, while we continue to require it for IPv4.
> 
> For pool assignments (dynamic IP addresses handed out to dial-in
> customers), we as a LIR just registered them as ASSIGNED PA assigned
> to ourselves (and "back then" these assignments fell under the
> INFRA-AW clause).
> 
> But for "static assignments", I think policy never permitted this.

Not sure about the history, but the current version of this "loophole"
is quite narrowly defined in the current policy (section 6.2):

«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.»

While it does not differentiate between dynamic and static assignments,
do note the use of work «solely».

Playing devil's advocate, I would argue that the moment some broadband
subscriber decides to set up a port forwarding of 443/tcp to some web
server on the LAN where a cake recipe blog is hosted or whatever, the
LIR/ISP is then instantly obligated to create a individualised /32
assignment for that address.

Cloud providers such as myself are clearly not covered by the loophole.
Our customers can freely create and destroy VPSes with shorter
lifetimes that your average fruit fly, yet to follow policy we are
required to create and destroy the IPv4 /32 assignments in the same
rate. I'll admit it, we don't. While we don't expect to get in trouble
over this intentional policy violation, it does irk me quite a bit
because we do prefer to play by the rules.

For IPv6 we use AGGREGATED-BY-LIR for these ranges, and would be nice
to be able to ("legally") do something similar for IPv4.

Tore



User Image

Gert Doering

2022-10-31 14:44:32 CET

Hi,

On Mon, Oct 31, 2022 at 02:41:05PM +0100, Tore Anderson wrote:
> Not sure about the history, but the current version of this "loophole"
> is quite narrowly defined in the current policy (section 6.2):
> 
> «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.»
> 
> While it does not differentiate between dynamic and static assignments,
> do note the use of work «solely».

Indeed.  That's the thing, p2p links, which ended up being "okayish"
for "end user get a single /32, on the link, and nothing more".

[..]
> For IPv6 we use AGGREGATED-BY-LIR for these ranges, and would be nice
> to be able to ("legally") do something similar for IPv4.

I'd say "at least two members of the WG see this as a valid problem
statement, so a policy proposal might be called for" :-)

(The "should we have competing proposals for the same document active
at the same time" discussion is left to the WG chairs, of course)

Gert Doering
        -- LIR admin
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
User Image

Jérôme Nicolle

2022-11-01 01:38:57 CET

Tore,

Thank you for your honest statement. I feel likewise.

Le 31/10/2022 à 14:41, Tore Anderson a écrit :
> Playing devil's advocate, I would argue that the moment some broadband
> subscriber decides to set up a port forwarding of 443/tcp to some web
> server on the LAN where a cake recipe blog is hosted or whatever, the
> LIR/ISP is then instantly obligated to create a individualised /32
> assignment for that address.

It is neither wanted (would potentially conflicts with EU' GDPR in some 
ways), nor technically feasible (would create way too much load on the 
database as we'd all have to update it in realtime).

> …

> For IPv6 we use AGGREGATED-BY-LIR for these ranges, and would be nice
> to be able to ("legally") do something similar for IPv4.

That's what LIR' "Provider Assignments" are for : you stick them up to 
your BNG's and it never had to do with any individual customers.

I'm not sure we have an issue here, it has been best practice and well 
adopted since I came around…

Some zeolots of course did declare each and every B2B customer as to 
brag about it or offload their hotlines, but that's probably a 
misinterpretation of current policies. As far as I know it never 
happened on residential broadband yet.


Best Regards,

-- 
Jérôme Nicolle
+33 6 19 31 27 14

User Image

Tore Anderson

2022-11-01 11:25:32 CET

* Jérôme Nicolle

> Thank you for your honest statement. I feel likewise.
> 
> Le 31/10/2022 à 14:41, Tore Anderson a écrit :
> > Playing devil's advocate, I would argue that the moment some broadband
> > subscriber decides to set up a port forwarding of 443/tcp to some web
> > server on the LAN where a cake recipe blog is hosted or whatever, the
> > LIR/ISP is then instantly obligated to create a individualised /32
> > assignment for that address.
> 
> It is neither wanted (would potentially conflicts with EU' GDPR in some 
> ways), nor technically feasible (would create way too much load on the 
> database as we'd all have to update it in realtime).

The policy in question allows the LIR to replace the End User's contact
information with its own, in case the End User is an individual. This
solves the GDPR issue, but it does not allow for aggregating a pool of
such assignments – unless they are *solely* used for the connection of
the End User to the service provider.

https://www.ripe.net/publications/docs/ripe-733#62

> > For IPv6 we use AGGREGATED-BY-LIR for these ranges, and would be nice
> > to be able to ("legally") do something similar for IPv4.
> 
> That's what LIR' "Provider Assignments" are for : you stick them up to 
> your BNG's and it never had to do with any individual customers.
> 
> I'm not sure we have an issue here, it has been best practice and well 
> adopted since I came around…
> 
> Some zeolots of course did declare each and every B2B customer as to 
> brag about it or offload their hotlines, but that's probably a 
> misinterpretation of current policies. As far as I know it never 
> happened on residential broadband yet.

Actually, declaring each and every customer assignment in that way is
probably the correct and de jure way to following the policy to the
letter – again, unless the assigned addresses in question are all
*solely* used for the connection to the service provider.

However, given a thousand random broadband customers, you're pretty
much certain to find at least one that uses the IPv4 address for
something additional, like running a server of some sort. The policy
*does* require separate assignments for those (regardless of them being
individuals or organisations).

Now, as you say, the best practice or de facto interpretation of policy
is to simply ignore that requirement because it's not really
technically feasible.

Yet, https://www.ripe.net/publications/docs/ripe-767#612 suggest that
least some LIRs are pedantically following policy to the letter, by
«overassigning» individual /32s.

I think, therefore, that it would be good to bring the policy text
itself in alignment with the de facto/best practice interpretation most
of us follow. 2022-02 in its current form is one way to do that, while
backporting IPv6's AGGREGATED-BY-LIR would be another.

Tore

Jan Ingvoldstad

2022-11-01 11:46:52 CET

On Tue, Nov 1, 2022 at 11:25 AM Tore Anderson <tore _at_ fud _dot_ no> wrote:

>
> I think, therefore, that it would be good to bring the policy text
> itself in alignment with the de facto/best practice interpretation most
> of us follow. 2022-02 in its current form is one way to do that, while
> backporting IPv6's AGGREGATED-BY-LIR would be another.
>
>
I don't have anything to add really, just my agreement. Thanks, Tore!

-- 
Jan