From adallara at ripe.net Tue Oct 4 09:43:54 2022 From: adallara at ripe.net (Angela Dall'Ara) Date: Tue, 4 Oct 2022 09:43:54 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) Message-ID: 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.net before 2 November 2022. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Tue Oct 4 11:33:14 2022 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 4 Oct 2022 11:33:14 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Tue Oct 4 13:53:21 2022 From: sander at steffann.nl (Sander Steffann) Date: Tue, 4 Oct 2022 13:53:21 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: <29086D37-B07B-41E6-9423-B72E19C2F6AA@steffann.nl> 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 From gert at space.net Tue Oct 4 15:05:32 2022 From: gert at space.net (Gert Doering) Date: Tue, 4 Oct 2022 15:05:32 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ripedenis at gmail.com Tue Oct 4 15:25:18 2022 From: ripedenis at gmail.com (denis walker) Date: Tue, 4 Oct 2022 15:25:18 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: <29086D37-B07B-41E6-9423-B72E19C2F6AA@steffann.nl> References: <29086D37-B07B-41E6-9423-B72E19C2F6AA@steffann.nl> Message-ID: 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 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://mailman.ripe.net/ From adallara at ripe.net Tue Oct 4 15:41:11 2022 From: adallara at ripe.net (Angela Dall'Ara) Date: Tue, 4 Oct 2022 15:41:11 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: 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 ? From randy at psg.com Tue Oct 4 17:46:28 2022 From: randy at psg.com (Randy Bush) Date: Tue, 04 Oct 2022 08:46:28 -0700 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: <29086D37-B07B-41E6-9423-B72E19C2F6AA@steffann.nl> Message-ID: > 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 From joao at bondis.org Tue Oct 4 17:57:37 2022 From: joao at bondis.org (Joao Luis Silva Damas) Date: Tue, 4 Oct 2022 17:57:37 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: <29086D37-B07B-41E6-9423-B72E19C2F6AA@steffann.nl> Message-ID: > On 4 Oct 2022, at 15:25, denis walker 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 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 From sander at steffann.nl Tue Oct 4 18:05:28 2022 From: sander at steffann.nl (Sander Steffann) Date: Tue, 4 Oct 2022 18:05:28 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: > Op 4 okt. 2022 om 17:46 heeft Randy Bush 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 From randy at psg.com Tue Oct 4 18:11:14 2022 From: randy at psg.com (Randy Bush) Date: Tue, 04 Oct 2022 09:11:14 -0700 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: >>> 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?? but it is not once in a lifetime. this mind-game of omphaloskepsis repeatedly drags us into the water flowing underground. randy From jerome at ceriz.fr Tue Oct 4 19:56:03 2022 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Tue, 4 Oct 2022 19:56:03 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: <944cb7a9-fcd2-b1e1-9f9a-fb759824adce@ceriz.fr> 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 From jameskennedy001 at gmail.com Thu Oct 6 13:44:51 2022 From: jameskennedy001 at gmail.com (James Kennedy) Date: Thu, 6 Oct 2022 13:44:51 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: <944cb7a9-fcd2-b1e1-9f9a-fb759824adce@ceriz.fr> References: <944cb7a9-fcd2-b1e1-9f9a-fb759824adce@ceriz.fr> Message-ID: 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 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://mailman.ripe.net/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu Oct 6 15:29:09 2022 From: gert at space.net (Gert Doering) Date: Thu, 6 Oct 2022 15:29:09 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: <944cb7a9-fcd2-b1e1-9f9a-fb759824adce@ceriz.fr> Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jlauwers at a2b-internet.com Fri Oct 7 16:18:18 2022 From: jlauwers at a2b-internet.com (Jeroen Lauwers) Date: Fri, 7 Oct 2022 14:18:18 +0000 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: <5F9F97CD-9F97-4645-88AC-C118B43825E2@a2b-internet.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlauwers at a2b-internet.com Fri Oct 7 16:19:41 2022 From: jlauwers at a2b-internet.com (Jeroen Lauwers) Date: Fri, 7 Oct 2022 14:19:41 +0000 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: <29086D37-B07B-41E6-9423-B72E19C2F6AA@steffann.nl> References: <29086D37-B07B-41E6-9423-B72E19C2F6AA@steffann.nl> Message-ID: <8EBCFEC0-AF8E-45A7-B3EE-7D6C047A34E1@a2b-internet.com> 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 From jlauwers at a2b-internet.com Fri Oct 7 16:25:35 2022 From: jlauwers at a2b-internet.com (Jeroen Lauwers) Date: Fri, 7 Oct 2022 14:25:35 +0000 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: <7BB8C9FD-A92F-4BD5-95A0-2A9D47B77C55@a2b-internet.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlauwers at a2b-internet.com Fri Oct 7 16:28:10 2022 From: jlauwers at a2b-internet.com (Jeroen Lauwers) Date: Fri, 7 Oct 2022 14:28:10 +0000 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: <944cb7a9-fcd2-b1e1-9f9a-fb759824adce@ceriz.fr> References: <944cb7a9-fcd2-b1e1-9f9a-fb759824adce@ceriz.fr> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlauwers at a2b-internet.com Fri Oct 7 16:31:35 2022 From: jlauwers at a2b-internet.com (Jeroen Lauwers) Date: Fri, 7 Oct 2022 14:31:35 +0000 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: <29086D37-B07B-41E6-9423-B72E19C2F6AA@steffann.nl> Message-ID: <9BC93F00-CFFA-4F50-9413-D70C3FD85365@a2b-internet.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Fri Oct 7 20:02:50 2022 From: farmer at umn.edu (David Farmer) Date: Fri, 7 Oct 2022 13:02:50 -0500 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: On Tue, Oct 4, 2022 at 2:44 AM Angela Dall'Ara 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.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 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripedenis at gmail.com Sat Oct 8 00:44:44 2022 From: ripedenis at gmail.com (denis walker) Date: Sat, 8 Oct 2022 00:44:44 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: <9BC93F00-CFFA-4F50-9413-D70C3FD85365@a2b-internet.com> References: <29086D37-B07B-41E6-9423-B72E19C2F6AA@steffann.nl> <9BC93F00-CFFA-4F50-9413-D70C3FD85365@a2b-internet.com> Message-ID: 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 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 From jameskennedy001 at gmail.com Sat Oct 8 11:14:29 2022 From: jameskennedy001 at gmail.com (James Kennedy) Date: Sat, 8 Oct 2022 10:14:29 +0100 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: <29086D37-B07B-41E6-9423-B72E19C2F6AA@steffann.nl> <9BC93F00-CFFA-4F50-9413-D70C3FD85365@a2b-internet.com> Message-ID: 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 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 > 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://mailman.ripe.net/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripedenis at gmail.com Mon Oct 10 22:33:56 2022 From: ripedenis at gmail.com (denis walker) Date: Mon, 10 Oct 2022 22:33:56 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: <29086D37-B07B-41E6-9423-B72E19C2F6AA@steffann.nl> <9BC93F00-CFFA-4F50-9413-D70C3FD85365@a2b-internet.com> Message-ID: 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 From mschmidt at ripe.net Tue Oct 11 12:49:36 2022 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 11 Oct 2022 12:49:36 +0200 Subject: [address-policy-wg] Potential Improvements to the Temporary Internet Number Assignment Policies Message-ID: Dear colleagues of the Address Policy Working Group, During the last RIPE Meeting in May, I presented on several observations that the Registration Services department had [1]. After receiving some feedback during the meeting, it was agreed to continue the discussion on the mailing list before RIPE 85. One of the topics discussed was the challenges encountered when dealing with temporary assignment requests. A specific policy allows the RIPE NCC to assign Internet Number resources on a temporary basis for a specific time-limited purpose, such as academic research and experimental purposes, conferences and other types of events. [2] Over the past years, the RIPE NCC has received some requests for academic research that required only a few IPv4 addresses for actual experiments, but within a routable prefix. This created a conflict with the current policy which requires the use of at least 50% of the requested IPv4 address space. With some creativity, the RIPE NCC has been able to approve these requests so far, but this has resulted in unnecessary delays in processing these requests. It is also possible that people have been refraining from submitting a request because of this policy limitation. One possible solution would be to review the current policy and propose a policy change, for example the introduction of a minimum IPv4 assignment size. Does the working group agree that this is an issue that should be discussed and that might require a policy change? Kind regards, Marco Schmidt Manager Registration Services RIPE NCC [1] https://ripe84.ripe.net/archives/video/786/ [2] https://www.ripe.net/publications/docs/ripe-587 From ggm at algebras.org Tue Oct 11 20:56:22 2022 From: ggm at algebras.org (George Michaelson) Date: Wed, 12 Oct 2022 04:56:22 +1000 Subject: [address-policy-wg] Potential Improvements to the Temporary Internet Number Assignment Policies In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022, 20:50 Marco Schmidt, wrote: > > One possible solution would be to review the current policy and propose > a policy change, for example the introduction of a minimum IPv4 > assignment size. > > Does the working group agree that this is an issue that should be > discussed and that might require a policy change? > I value research being done immensely as a downstream consumer of its findings. This stuff helps us decide how to manage addresses in the wide. Noting that I work in an RIR (APNIC) I would welcome a conversation seeking to improve access to routable prefixes by researchers, so we can see good research on BGP, security, routing and network behaviour. I was aware of difficulties for at least one research group in almost all RIR over last year. I think this topic merits discussing. Cheers George -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Wed Oct 12 12:36:21 2022 From: nick at foobar.org (Nick Hilliard) Date: Wed, 12 Oct 2022 11:36:21 +0100 Subject: [address-policy-wg] Potential Improvements to the Temporary Internet Number Assignment Policies In-Reply-To: References: Message-ID: Marco Schmidt wrote on 11/10/2022 11:49: > One possible solution would be to review the current policy and propose > a policy change, for example the introduction of a minimum IPv4 > assignment size. > > Does the working group agree that this is an issue that should be > discussed and that might require a policy change? seems reasonable. Nick From sander at steffann.nl Wed Oct 12 15:42:24 2022 From: sander at steffann.nl (Sander Steffann) Date: Wed, 12 Oct 2022 15:42:24 +0200 Subject: [address-policy-wg] Potential Improvements to the Temporary Internet Number Assignment Policies In-Reply-To: References: Message-ID: <104CFFA4-32B8-4128-9D49-E6F1B72521ED@steffann.nl> Hi, > On 12 Oct 2022, at 12:36, Nick Hilliard wrote: > > Marco Schmidt wrote on 11/10/2022 11:49: >> One possible solution would be to review the current policy and propose a policy change, for example the introduction of a minimum IPv4 assignment size. >> Does the working group agree that this is an issue that should be discussed and that might require a policy change? > > seems reasonable. +1 Sander From Kurt.Kayser at online.de Wed Oct 12 16:20:24 2022 From: Kurt.Kayser at online.de (Kurt Kayser) Date: Wed, 12 Oct 2022 16:20:24 +0200 Subject: [address-policy-wg] Potential Improvements to the Temporary Internet Number Assignment Policies In-Reply-To: <104CFFA4-32B8-4128-9D49-E6F1B72521ED@steffann.nl> References: <104CFFA4-32B8-4128-9D49-E6F1B72521ED@steffann.nl> Message-ID: Hi, I am in favor for this suggestion as well. >> Marco Schmidt wrote on 11/10/2022 11:49: >>> One possible solution would be to review the current policy and propose a policy change, for example the introduction of a minimum IPv4 assignment size. >>> Does the working group agree that this is an issue that should be discussed and that might require a policy change? >> seems reasonable. > +1 > Sander > +1 Kurt From leo at vegoda.org Fri Oct 14 14:45:16 2022 From: leo at vegoda.org (Leo Vegoda) Date: Fri, 14 Oct 2022 05:45:16 -0700 Subject: [address-policy-wg] Draft Address Policy WG Agenda - RIPE 85 Message-ID: Dear Address Policy WG, This is the draft agenda for our sessions in Belgrade at RIPE 85 later this month. Kind regards, Leo (for the co-chairs) Address Policy Working Group Wednesday, 26 October 09:00 - 10:00 (UTC+2) Chaired By: Erik Bais, James Kennedy, Leo Vegoda A. Introduction [5 mins] B. ASO AC Update [10 mins] C. NRO NC Election [10 mins] D. Policy Update followed by Q&A [15 mins] RIPE NCC E. (2022-02) Remove mandatory IPv4 PA assignment registration in the RIPE Database [15 mins] Wednesday, 26 October 10:30 - 11:30 (UTC+2) Chaired By: Erik Bais, James Kennedy, Leo Vegoda F. Registry Services Update Followed by Q&A [15 mins] RIPE NCC G. IPv6 Policy Goals - Review Process (community input sought) [15 mins] H. Temporary IPv4 Assignments - Minimum Assignment Size [10 mins] I. AOB/Open Mic [20 min] From leo at vegoda.org Mon Oct 17 14:20:54 2022 From: leo at vegoda.org (Leo Vegoda) Date: Mon, 17 Oct 2022 05:20:54 -0700 Subject: [address-policy-wg] Draft Address Policy WG Agenda - RIPE 85 In-Reply-To: References: Message-ID: Hi, On Fri, 14 Oct 2022 at 05:45, Leo Vegoda wrote: > > Dear Address Policy WG, > > This is the draft agenda for our sessions in Belgrade at RIPE 85 later > this month. We have an updated draft agenda. The key change is that the election will have been completed before the Address Policy WG starts, so we have extra time for policy discussions. Kind regards, Leo Address Policy Working Group Wednesday, 26 October 09:00 - 10:00 (UTC+2) Chaired By: Erik Bais, James Kennedy, Leo Vegoda A. Introduction [5 mins] B. ASO AC Update [10 mins] C. Policy Update followed by Q&A [15 mins] RIPE NCC D. (2022-02) Remove mandatory IPv4 PA assignment registration in the RIPE Database [15 mins] E. Registry Services Update Followed by Q&A [15 mins] RIPE NCC Wednesday, 26 October 10:30 - 11:30 (UTC+2) Chaired By: Erik Bais, James Kennedy, Leo Vegoda F. IPv6 Policy Goals - Review Process (community input sought) [20 mins] - Where we are - Next steps G. Temporary IPv4 Assignments - Minimum Assignment Size [20 mins] - Do we want to tackle this? - Is anyone prepared to make a policy proposal? H. AOB/Open Mic [20 min] From jameskennedy001 at gmail.com Wed Oct 19 09:37:03 2022 From: jameskennedy001 at gmail.com (James Kennedy) Date: Wed, 19 Oct 2022 09:37:03 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: 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.net> wrote: > > > On Tue, Oct 4, 2022 at 2:44 AM Angela Dall'Ara 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.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://mailman.ripe.net/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Wed Oct 19 14:26:04 2022 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 19 Oct 2022 14:26:04 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: On Wed, Oct 19, 2022 at 9:37 AM James Kennedy 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameskennedy001 at gmail.com Wed Oct 19 15:45:07 2022 From: jameskennedy001 at gmail.com (James Kennedy) Date: Wed, 19 Oct 2022 15:45:07 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: On Wed, Oct 19, 2022 at 2:26 PM Jan Ingvoldstad wrote: > On Wed, Oct 19, 2022 at 9:37 AM James Kennedy > 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] -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Thu Oct 20 17:26:11 2022 From: sander at steffann.nl (Sander Steffann) Date: Thu, 20 Oct 2022 17:26:11 +0200 Subject: [address-policy-wg] [ncc-announce] [news] RIPE NCC Response to Committee of the Verkhovna Rada of Ukraine In-Reply-To: <795202274.69.1666275554335.JavaMail.app-admin@ba-apps-3.ripe.net> References: <795202274.69.1666275554335.JavaMail.app-admin@ba-apps-3.ripe.net> Message-ID: <650DEC56-889C-4C5C-B360-47A424797A76@steffann.nl> Hi Hans Petter, > Today we responded to a request from the Committee of the Verkhovna Rada of Ukraine on Matters of National Security, Defense and Intelligence to discuss measures to protect Internet number resources in Ukraine. We have published this on our website: > https://www.ripe.net/publications/news/announcements/ripe-ncc-response-to-committee-of-the-verkhovna-rada-of-ukraine > > As we note in our response, we will be presenting on this topic in the RIPE NCC Services Working Group at RIPE 85 next week. We encourage anyone with an interest in this topic to join that session. In your response you refer them to the Address Policy Working Group ("On the same day, from 09:00-11:30 UTC+2, the Address Policy Working Group will meet to discuss matters of policy, and we suggest that this would be a good forum to raise these matters.?). I am not sure I agree with that. I think the current situation requires something like a transfer lock that LIRs can voluntarily activate. I remember already talking about that with NCC staff at the Berlin meeting, so the issue was known and a possible solution discussed a long time ago. To be honest I expected that the NCC had long since implemented something like this as an operational procedure. I do not consider something like that a matter for policy. The address policies stay exactly the same, only the operational procedures should change. My personal feeling is that the NCC is taking much too long here, sending the poor ISPs in Ukraine into a lengthy process of having to write a policy that will take even longer to implement, for something that is an operational matter, not a policy one. I urge you to solve this inside the NCC as soon as possible. You do not need this community to write policy on how to protect the RIPE database?s contents from clear and present operational dangers. I?m sure there will be many in this community scrutinising whatever you come up with, and there will be much debate on whether the solution the NCC implemented contains bike sheds in all the right colours, and I guess that is unavoidable in a bottom-up community. But a fast response (which IMHO should have been done months ago) is more important than perfection right now. Please go for ?good enough for now? first. Thank you Sander From leo at vegoda.org Thu Oct 20 18:09:43 2022 From: leo at vegoda.org (Leo Vegoda) Date: Thu, 20 Oct 2022 09:09:43 -0700 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: Hi Jan, On Wed, 19 Oct 2022 at 05:26, Jan Ingvoldstad wrote: > > On Wed, Oct 19, 2022 at 9:37 AM James Kennedy 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 From sander at steffann.nl Thu Oct 20 20:37:57 2022 From: sander at steffann.nl (Sander Steffann) Date: Thu, 20 Oct 2022 20:37:57 +0200 Subject: [address-policy-wg] [ncc-announce] [news] RIPE NCC Response to Committee of the Verkhovna Rada of Ukraine In-Reply-To: <53A0F381-E436-4E25-B89C-DAB826BF35AC@ripe.net> References: <53A0F381-E436-4E25-B89C-DAB826BF35AC@ripe.net> Message-ID: Hi Hans Petter! > I would encourage you to have a look at the article outlining some of the alternatives: > https://labs.ripe.net/author/athina/protecting-resource-holders-in-distressed-areas/ Yeah, I did read that. I just don?t agree with the arguments. > While this might seem like an easy solution on the surface, we cannot help but anticipate situations where this could be abused. For example, we can imagine cases where malicious employees want to prevent an upcoming transfer. Such a solution would also have some administrative challenges, because who is authorised to activate this freeze would need to be specified. Make it the same person who is authorised to open/close an LIR. The NCC already has those contracts. To prevent abuse make it a paper form with signatures over registered mail, or whatever the NCC has in place already. I?d put the authorisation level at the same one as closing the LIR. > Also, we wouldn't be able to adhere to such a requested freeze when companies are bankrupt, liquidated or in case of a legitimate merger and acquisition. Yeah, I agree there is little you can do about those in any circumstance. > In any case, if the period of time for the lock is longer than a couple of days, we would again be very reluctant in implementing this solution without a policy proposal. Why? An LIR explicitly and voluntarily giving up some rights they have under the service agreement is surely a matter between the member and the NCC? The policy stays exactly the same. > I can assure you that we have taken the measures we believe we can within the existing policy. I think adding a disclaimer that allows for making transfers null and void retroactively is a much bigger risk to all involved than a transfer lock would have been. I don?t see how on one hand the NCC can?t verify whether a transfer lock is valid, but can verify with absolute certainty that existing paperwork is null and void. To me it feels more like a ?let someone else figure this out in court? attitude than an actively helpful one. > Looking forward to hearing what the community thinks here at the list or the meeting next week. Me too! I?m only a single voice here, and this is a community! Cheers, Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/octet-stream Size: 833 bytes Desc: not available URL: From greysticky at gmail.com Fri Oct 21 00:04:34 2022 From: greysticky at gmail.com (Serg Galat) Date: Fri, 21 Oct 2022 01:04:34 +0300 Subject: [address-policy-wg] [ncc-announce] [news] RIPE NCC Response to Committee of the Verkhovna Rada of Ukraine In-Reply-To: References: <53A0F381-E436-4E25-B89C-DAB826BF35AC@ripe.net> Message-ID: <36FEB986-97EE-44AF-9B27-0F9F237243D0@gmail.com> > On 20 Oct 2022, at 21:37, Sander Steffann wrote: > > Hi Hans Petter! > >> I would encourage you to have a look at the article outlining some of the alternatives: >> https://labs.ripe.net/author/athina/protecting-resource-holders-in-distressed-areas/ > > Yeah, I did read that. I just don?t agree with the arguments. > >> While this might seem like an easy solution on the surface, we cannot help but anticipate situations where this could be abused. For example, we can imagine cases where malicious employees want to prevent an upcoming transfer. Such a solution would also have some administrative challenges, because who is authorised to activate this freeze would need to be specified. > > Make it the same person who is authorised to open/close an LIR. The NCC already has those contracts. To prevent abuse make it a paper form with signatures over registered mail, or whatever the NCC has in place already. I?d put the authorisation level at the same one as closing the LIR. > >> Also, we wouldn't be able to adhere to such a requested freeze when companies are bankrupt, liquidated or in case of a legitimate merger and acquisition. > > Yeah, I agree there is little you can do about those in any circumstance. > >> In any case, if the period of time for the lock is longer than a couple of days, we would again be very reluctant in implementing this solution without a policy proposal. > > Why? An LIR explicitly and voluntarily giving up some rights they have under the service agreement is surely a matter between the member and the NCC? The policy stays exactly the same. > >> I can assure you that we have taken the measures we believe we can within the existing policy. > > I think adding a disclaimer that allows for making transfers null and void retroactively is a much bigger risk to all involved than a transfer lock would have been. I don?t see how on one hand the NCC can?t verify whether a transfer lock is valid, but can verify with absolute certainty that existing paperwork is null and void. Situation, very often used of russians on occupied territory. LIR owner or authorized person sign transfer while member of his family stay near with gun pointed to their head. Can you imagine something like this? And can you imagine what will happen when "gun owner" will hear transfer impossible because locked by RIPE NCC? Are you think i'm exaggerating? > > To me it feels more like a ?let someone else figure this out in court? attitude than an actively helpful one. > >> Looking forward to hearing what the community thinks here at the list or the meeting next week. > > Me too! I?m only a single voice here, and this is a community! > > Cheers, > Sander > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ ? Serg Galat From nick at foobar.org Sat Oct 22 00:27:43 2022 From: nick at foobar.org (Nick Hilliard) Date: Fri, 21 Oct 2022 23:27:43 +0100 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: <29086D37-B07B-41E6-9423-B72E19C2F6AA@steffann.nl> <9BC93F00-CFFA-4F50-9413-D70C3FD85365@a2b-internet.com> Message-ID: <998423a8-a488-a89a-8a80-51a96c15ea24@foobar.org> 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 From anw at artfiles.de Mon Oct 24 10:04:38 2022 From: anw at artfiles.de (Andreas Worbs) Date: Mon, 24 Oct 2022 10:04:38 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: 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.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.de | Web:http://www.artfiles.de Gesch?ftsf?hrer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From frettled at gmail.com Mon Oct 24 12:50:01 2022 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 24 Oct 2022 12:50:01 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: On Thu, Oct 20, 2022 at 6:10 PM Leo Vegoda wrote: > Hi Jan, > Hi Leo, > > On Wed, 19 Oct 2022 at 05:26, Jan Ingvoldstad 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at vegoda.org Mon Oct 24 13:02:19 2022 From: leo at vegoda.org (Leo Vegoda) Date: Mon, 24 Oct 2022 04:02:19 -0700 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: Hi Jan, On Mon, 24 Oct 2022 at 03:50, Jan Ingvoldstad wrote: >> On Wed, 19 Oct 2022 at 05:26, Jan Ingvoldstad 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 From gert at space.net Mon Oct 24 13:15:38 2022 From: gert at space.net (Gert Doering) Date: Mon, 24 Oct 2022 13:15:38 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From frettled at gmail.com Mon Oct 24 13:43:42 2022 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 24 Oct 2022 13:43:42 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: On Mon, Oct 24, 2022 at 1:02 PM Leo Vegoda wrote: > Hi Jan, > > Hi, Leo! > On Mon, 24 Oct 2022 at 03:50, Jan Ingvoldstad 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at vegoda.org Mon Oct 24 16:25:34 2022 From: leo at vegoda.org (Leo Vegoda) Date: Mon, 24 Oct 2022 07:25:34 -0700 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: Hi Jan, On Mon, 24 Oct 2022 at 04:44, Jan Ingvoldstad wrote: > On Mon, Oct 24, 2022 at 1:02 PM Leo Vegoda wrote: >> On Mon, 24 Oct 2022 at 03:50, Jan Ingvoldstad 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 From ripedenis at gmail.com Mon Oct 24 23:09:53 2022 From: ripedenis at gmail.com (denis walker) Date: Mon, 24 Oct 2022 23:09:53 +0200 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: HI Leo On Mon, 24 Oct 2022 at 16:25, Leo Vegoda wrote: > > Hi Jan, > > On Mon, 24 Oct 2022 at 04:44, Jan Ingvoldstad wrote: > > On Mon, Oct 24, 2022 at 1:02 PM Leo Vegoda wrote: > >> On Mon, 24 Oct 2022 at 03:50, Jan Ingvoldstad 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://mailman.ripe.net/ From matthias.wichtlhuber at de-cix.net Thu Oct 27 10:33:24 2022 From: matthias.wichtlhuber at de-cix.net (Matthias Wichtlhuber) Date: Thu, 27 Oct 2022 08:33:24 +0000 Subject: [address-policy-wg] IXP pool lower boundary of assignments Message-ID: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> Hi address policy WG, Marco pointed out in the WG session, that we should probably start a discussion on the lower boundary of assignments from the IXP pool. I would like to kick off this discussion with this post. When we had the discussion on the current policy in 2019, I posted an analysis of PeeringDB data, which I have updated with data from 2022 now (https://github.com/mwichtlh/address-policy-wg). The comparison of both analyses provides some interesting data points: 1.) The overall number of IXPs is growing fast (951 IXPs up from 672 in 2019 with 1014 peering LANs up from 726 in 2019). To me, this looks more like exponential growth and honestly speaking I doubt the linear projection of depletion in 2029 presented in the WG. I think this will happen earlier. 2.) The updated data clearly shows that the lower boundary of /24 assignments continues to create a lot of waste in terms of IP space, as ~80% of all IXPs would fit into a /25 (including 100% overprovisioning) and roughly 70% of all IXPs would even fit into a /26 (including 100% overprovisioning). Thus, decreasing the assignmemt size is unlikely to cause harm but might be very helpful to extend the lifetime of the pool into the 2030s. Another pro I see here is that lowering the boundary would allow to extend the overall size of the pool, as we could ask RIPE to add IP space dust References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> Message-ID: Hi, > Marco pointed out in the WG session, that we should probably start a discussion on the lower boundary of assignments from the IXP pool. I would like to kick off this discussion with this post. To add to this discussion: I took this to the Connect WG, and the initial feedback I got from there is that they have no problem with reevaluating this every 8 or so years (what seems to be the current rate of use of the IXP pool), and that they would be perfectly happy with not doing anything right now and reevaluating this in 2027 or so. This will be taken to the Connect WG mailing list, so let's keep an eye on that to see whether action is necessary at all. Cheers! Sander From gert at space.net Thu Oct 27 20:59:56 2022 From: gert at space.net (Gert Doering) Date: Thu, 27 Oct 2022 20:59:56 +0200 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> Message-ID: Hi, On Thu, Oct 27, 2022 at 04:23:20PM +0200, Sander Steffann wrote: > To add to this discussion: I took this to the Connect WG, and the > initial feedback I got from there is that they have no problem with > reevaluating this every 8 or so years (what seems to be the current > rate of use of the IXP pool), and that they would be perfectly happy > with not doing anything right now and reevaluating this in 2027 or > so. By then, all the IXP landscape will be DECIX global layer2 anyway, so all we need is a /15 for DECIX, and all the ASes in the world can connect to it. Now, getting that /15 might be a bit complicated... maybe we really need to go for "ipv4 over ipv6 transport", then, like the cloudfolks already do... 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From arnold.nipper at de-cix.net Thu Oct 27 23:21:08 2022 From: arnold.nipper at de-cix.net (Arnold Nipper) Date: Thu, 27 Oct 2022 23:21:08 +0200 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> Message-ID: On 27.10.2022 20:59, Gert Doering wrote: > Hi, > > On Thu, Oct 27, 2022 at 04:23:20PM +0200, Sander Steffann wrote: >> To add to this discussion: I took this to the Connect WG, and the >> initial feedback I got from there is that they have no problem with >> reevaluating this every 8 or so years (what seems to be the current >> rate of use of the IXP pool), and that they would be perfectly happy >> with not doing anything right now and reevaluating this in 2027 or >> so. > > By then, all the IXP landscape will be DECIX global layer2 anyway, > so all we need is a /15 for DECIX, and all the ASes in the world can > connect to it. > I would have expected that you have to add serious content. Looks like you are getting old, too. Arnold Btw.: It's DE-CIX, not DECIX, DEC-IX or any other variation :) -- Arnold Nipper Chief Technology Evangelist and Co-Founder DE-CIX Management GmbH Lindleystra?e 12 | 60314 Frankfurt a.M. | Germany Phone +49 69 1730902 22 | Mobile +49 172 2650958 arnold.nipper at de-cix.net | www.de-cix.net Geschaeftsfuehrer Ivaylo Ivanov und Sebastian Seifert Registergericht AG Koeln HRB 51135 Want to work at DE-CIX: https://de-cix.net/en/about-de-cix/careers From farmer at umn.edu Thu Oct 27 23:58:14 2022 From: farmer at umn.edu (David Farmer) Date: Thu, 27 Oct 2022 16:58:14 -0500 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> Message-ID: On Thu, Oct 27, 2022 at 4:21 PM Arnold Nipper wrote: > > I would have expected that you have to add serious content. Looks like > you are getting old, too. > Hopefully, you find this to be a serious comment; if not, my apologies ahead of time. ARIN has a policy for Reserved Pool Replentishemnet. https://www.arin.net/participate/policy/nrpm/#4-1-7-reserved-pool-replenishment It was ARIN-2019-21; https://www.arin.net/participate/policy/drafts/2019_21/ The basic idea of the policy is to return recovered resources allocated from reserved pools to their respective reserved pool, if they are ever returned, and to have a default action of replenishing the reserved pools when or if they get down to a three-year or less supply. Until then, other recovered resources go to the waiting list. Even then the idea is to only replenish reserved pools to or maintain a running three-year supply in each reserved pool; any resources recovered beyond that would still go to the waiting list. Without this policy, when or if ARIN's reserved pools get low, they would run out unless we had a consensus for a policy to change things at that time to replenish them. However, with this policy, the default action is to replenish the reserved pools when or if they get low. Unless there is consensus at that time to let them run out, requiring policy action at that time. Note ARIN policy has two reserved pools defined in sections 4.4 and 4.10 4.4. Micro-allocation (for Critical Infrastructure, including IXPs) and; 4.10. Dedicated IPv4 Block to Facilitate IPv6 Deployment https://www.arin.net/participate/policy/nrpm/#4-4-micro-allocation https://www.arin.net/participate/policy/nrpm/#4-10-dedicated-ipv4-block-to-facilitate-ipv6-deployment Also, resources from the reserved pool can only be transferred through M&A and not on the open market since they were reserved for special purposes. This may or may not be how the RIPE community wishes to do things, but I thought it would be an option worth considering. Thanks. -- =============================================== David Farmer Email:farmer at umn.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 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kurt.Kayser at online.de Fri Oct 28 00:49:25 2022 From: Kurt.Kayser at online.de (Kurt Kayser) Date: Fri, 28 Oct 2022 00:49:25 +0200 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> Message-ID: <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> Arnold, yes we are all getting older.. > I would have expected that you have to add serious content. Looks like > you are getting old, too. > > > Arnold > Btw.: It's DE-CIX, not DECIX, DEC-IX or any other variation :) DE-CIX - easy to remember, like DE-PEER oder DE-ICE :-) .kurt PS: yes, just having fun :-) From shane at time-travellers.org Sun Oct 30 11:38:07 2022 From: shane at time-travellers.org (Shane Kerr) Date: Sun, 30 Oct 2022 11:38:07 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> Message-ID: <1d4731b2-5563-dc42-d313-fd812b131274@time-travellers.org> Matthias, Thanks for kicking this off! On 27/10/2022 10.33, Matthias Wichtlhuber wrote: > > Marco pointed out in the WG session, that we should probably start a discussion on the lower boundary of assignments from the IXP pool. I would like to kick off this discussion with this post. > > When we had the discussion on the current policy in 2019, I posted an analysis of PeeringDB data, which I have updated with data from 2022 now (https://github.com/mwichtlh/address-policy-wg). The comparison of both analyses provides some interesting data points: > > 1.) The overall number of IXPs is growing fast (951 IXPs up from 672 in 2019 with 1014 peering LANs up from 726 in 2019). To me, this looks more like exponential growth and honestly speaking I doubt the linear projection of depletion in 2029 presented in the WG. I think this will happen earlier. > > 2.) The updated data clearly shows that the lower boundary of /24 assignments continues to create a lot of waste in terms of IP space, as ~80% of all IXPs would fit into a /25 (including 100% overprovisioning) and roughly 70% of all IXPs would even fit into a /26 (including 100% overprovisioning). Thus, decreasing the assignmemt size is unlikely to cause harm but might be very helpful to extend the lifetime of the pool into the 2030s. > > Another pro I see here is that lowering the boundary would allow to extend the overall size of the pool, as we could ask RIPE to add IP space dust > At the same time, we should be well aware that we are only buying time. That's why we should kick off some initiative to test and deploy multi protocol BGP at IXPs (but that is probably a question for the IXP community). My own feeling is that we should not do any of this, and require that IXP's get their IPv4 address space by buying it like everyone else has to do to run their businesses. Or use IPv6 and/or IPv4 space reserved for private use. The IXP policy possibly made sense when it was impossible to meet the RIPE requirements for allocations, and there was concern about conflict-of-interest from IXP getting their space from an LIR. However, for most LIR there is no space from the RIPE NCC no matter how urgent their needs. So there is no longer a concern about conflict of interest. Cheers, -- Shane -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x3732979CF967B306.asc Type: application/pgp-keys Size: 11617 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From matthias.wichtlhuber at de-cix.net Mon Oct 31 09:31:55 2022 From: matthias.wichtlhuber at de-cix.net (Matthias Wichtlhuber) Date: Mon, 31 Oct 2022 08:31:55 +0000 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> , <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> Message-ID: <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> Hi, > On Thu, Oct 27, 2022 at 04:23:20PM +0200, Sander Steffann wrote: To add to this discussion: I took this to the Connect WG, and the initial feedback I got from there is that they have no problem with reevaluating this every 8 or so years (what seems to be the current rate of use of the IXP pool), and that they would be perfectly happy with not doing anything right now and reevaluating this in 2027 or so. This will be taken to the Connect WG mailing list, so let's keep an eye on that to see whether action is necessary at all. As per my analysis, there has been a ~40% increase in IXPs world-wide over the last three years (see my initial mail). Given that number, I don't think we should wait and continue wasting space with too large assignments until 2027. > On Thu, Oct 27, 2022 at 20:59:20PM +0200, Gert D?ring wrote: Now, getting that /15 might be a bit complicated... maybe we really need to go for "ipv4 over ipv6 transport", then, like the cloudfolks already do... Sure, we should go for multihop hop BGP in the future. But (correct me if I'm wrong) this is probably a question for the Euro-IX folks. This will require a major testing effort from the IXP community with all kinds of vendors and route server implementations and we need to develop best practices for that; thus, it makes sense to stretch the existing pool as long as possible. Please note this proposal also affects DE-CIX, because most of our IXPs are not exactly the size of Frankfurt. IMHO, the default assignment should be something like /25. Regards, Matthias -- Dr.-Ing. Matthias Wichtlhuber Senior Researcher ------------------------------ DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt (Germany) phone: +49 69 1730902 141 mobile: +49 171 3836036 fax: +49 69 4056 2716 e-mail: matthias.wichtlhuber at de-cix.net web: www.de-cix.net ------------------------------ DE-CIX Management GmbH Executive Directors: Ivaylo Ivanov and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne ------------------------------ DE-CIX 25th anniversary: Without you the Internet would not be the same! Join us on the journey at https://withoutyou.de-cix.net ________________________________________ Von: address-policy-wg im Auftrag von Kurt Kayser Gesendet: Freitag, 28. Oktober 2022 00:49:25 An: address-policy-wg at ripe.net Cc: Sander Steffann; Arnold Nipper; Gert Doering Betreff: Re: [address-policy-wg] IXP pool lower boundary of assignments Arnold, yes we are all getting older.. > I would have expected that you have to add serious content. Looks like > you are getting old, too. > > > Arnold > Btw.: It's DE-CIX, not DECIX, DEC-IX or any other variation :) DE-CIX - easy to remember, like DE-PEER oder DE-ICE :-) .kurt PS: yes, just having fun :-) -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From matthias.wichtlhuber at de-cix.net Mon Oct 31 09:47:39 2022 From: matthias.wichtlhuber at de-cix.net (Matthias Wichtlhuber) Date: Mon, 31 Oct 2022 08:47:39 +0000 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> , <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de>, <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> Message-ID: Sorry, multi *protocol* BGP, not multi hop ;) -- Dr.-Ing. Matthias Wichtlhuber Senior Researcher ------------------------------ DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt (Germany) phone: +49 69 1730902 141 mobile: +49 171 3836036 fax: +49 69 4056 2716 e-mail: matthias.wichtlhuber at de-cix.net web: www.de-cix.net ------------------------------ DE-CIX Management GmbH Executive Directors: Ivaylo Ivanov and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne ------------------------------ DE-CIX 25th anniversary: Without you the Internet would not be the same! Join us on the journey at https://withoutyou.de-cix.net ________________________________________ Von: Matthias Wichtlhuber Gesendet: Montag, 31. Oktober 2022 09:31:55 An: Kurt Kayser; address-policy-wg at ripe.net Cc: Sander Steffann; Arnold Nipper; Gert Doering Betreff: AW: [address-policy-wg] IXP pool lower boundary of assignments Hi, > On Thu, Oct 27, 2022 at 04:23:20PM +0200, Sander Steffann wrote: To add to this discussion: I took this to the Connect WG, and the initial feedback I got from there is that they have no problem with reevaluating this every 8 or so years (what seems to be the current rate of use of the IXP pool), and that they would be perfectly happy with not doing anything right now and reevaluating this in 2027 or so. This will be taken to the Connect WG mailing list, so let's keep an eye on that to see whether action is necessary at all. As per my analysis, there has been a ~40% increase in IXPs world-wide over the last three years (see my initial mail). Given that number, I don't think we should wait and continue wasting space with too large assignments until 2027. > On Thu, Oct 27, 2022 at 20:59:20PM +0200, Gert D?ring wrote: Now, getting that /15 might be a bit complicated... maybe we really need to go for "ipv4 over ipv6 transport", then, like the cloudfolks already do... Sure, we should go for multihop hop BGP in the future. But (correct me if I'm wrong) this is probably a question for the Euro-IX folks. This will require a major testing effort from the IXP community with all kinds of vendors and route server implementations and we need to develop best practices for that; thus, it makes sense to stretch the existing pool as long as possible. Please note this proposal also affects DE-CIX, because most of our IXPs are not exactly the size of Frankfurt. IMHO, the default assignment should be something like /25. Regards, Matthias -- Dr.-Ing. Matthias Wichtlhuber Senior Researcher ------------------------------ DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt (Germany) phone: +49 69 1730902 141 mobile: +49 171 3836036 fax: +49 69 4056 2716 e-mail: matthias.wichtlhuber at de-cix.net web: www.de-cix.net ------------------------------ DE-CIX Management GmbH Executive Directors: Ivaylo Ivanov and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne ------------------------------ DE-CIX 25th anniversary: Without you the Internet would not be the same! Join us on the journey at https://withoutyou.de-cix.net ________________________________________ Von: address-policy-wg im Auftrag von Kurt Kayser Gesendet: Freitag, 28. Oktober 2022 00:49:25 An: address-policy-wg at ripe.net Cc: Sander Steffann; Arnold Nipper; Gert Doering Betreff: Re: [address-policy-wg] IXP pool lower boundary of assignments Arnold, yes we are all getting older.. > I would have expected that you have to add serious content. Looks like > you are getting old, too. > > > Arnold > Btw.: It's DE-CIX, not DECIX, DEC-IX or any other variation :) DE-CIX - easy to remember, like DE-PEER oder DE-ICE :-) .kurt PS: yes, just having fun :-) -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From tore at fud.no Mon Oct 31 13:18:51 2022 From: tore at fud.no (Tore Anderson) Date: Mon, 31 Oct 2022 13:18:51 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> , <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> Message-ID: <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> * Matthias Wichtlhuber > As per my analysis, there has been a ~40% increase in IXPs world-wide > over the last three years (see my initial mail). Given that number, I > don't think we should wait and continue wasting space with too large > assignments until 2027. I agree, but as I also said back when 2019-05 was being discussed? > IMHO, the default assignment should be something like /25. ?I believe the default (and minimum) should be /29. Lavishing /25s on IXPs with just a handful of members is really not that much better than the /24s we currently give them. If the ISP needs something larger than the default, there is no problem. All it has to do is to ask for a larger assignment, just like today. Tore From tore at fud.no Mon Oct 31 13:49:46 2022 From: tore at fud.no (Tore Anderson) Date: Mon, 31 Oct 2022 13:49:46 +0100 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: Message-ID: <15e9e1d1779bde9d8878ae64876e4f075619c88b.camel@fud.no> * 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 From gert at space.net Mon Oct 31 14:13:51 2022 From: gert at space.net (Gert Doering) Date: Mon, 31 Oct 2022 14:13:51 +0100 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: <15e9e1d1779bde9d8878ae64876e4f075619c88b.camel@fud.no> References: <15e9e1d1779bde9d8878ae64876e4f075619c88b.camel@fud.no> Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tore at fud.no Mon Oct 31 14:41:05 2022 From: tore at fud.no (Tore Anderson) Date: Mon, 31 Oct 2022 14:41:05 +0100 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: References: <15e9e1d1779bde9d8878ae64876e4f075619c88b.camel@fud.no> Message-ID: <08f4bc76c26affeeabbe86734ae536af9432e9ea.camel@fud.no> * 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 From gert at space.net Mon Oct 31 14:44:32 2022 From: gert at space.net (Gert Doering) Date: Mon, 31 Oct 2022 14:44:32 +0100 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: <08f4bc76c26affeeabbe86734ae536af9432e9ea.camel@fud.no> References: <15e9e1d1779bde9d8878ae64876e4f075619c88b.camel@fud.no> <08f4bc76c26affeeabbe86734ae536af9432e9ea.camel@fud.no> Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: