- address-policy-wg - mailman.ripe.net

Address Assignment Practices in IPv4 and IPv6
by Stephen D. Strowes 21 Jan '21

21 Jan '21

Hi all, We've published a study on the stability of IPv4/IPv6 assignments in domestic ISPs, and the size of the IPv6 prefixes that networks typically assign to subscribers. We look at this from two different angles: what can we measure from RIPE Atlas, and what do operators state in the RIPE Database? In particular, understanding the size of IPv6 delegated prefixes is important for applications such as host reputation & blocklists, geolocation, and research on network measurement. The RIPE Database offers the community a way to share information on their prefix delegations, and deserves some attention! Read more here: https://labs.ripe.net/Members/stephen_strowes/address-assignment-practices-… Cheers, S.

1 0

RIPE 81 Address Policy WG Draft Minutes
by Angela Dall'Ara 14 Dec '20

14 Dec '20

Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 81 have now been published: https://www.ripe.net/participate/ripe/wg/active-wg/ap/minutes/ripe-81-addre… Please let us know of any corrections or amendments. Kind regards, Angela Dall'Ara RIPE NCC Policy Officer

1 0

NWI-4 - role of status: field in multivalued status context -- Last call
by ripedenis＠yahoo.co.uk 17 Nov '20

17 Nov '20

Hi Lee With the current data model it is not possible to have two independent objects with the same primary key. Creating 2 smaller objects is a work around. Having 2 status attributes is another work around. The question is, which work around is preferable? cheersdenis co-chair DB-WG On Tuesday, 17 November 2020, 14:25:35 CET, Howard, Lee <leehoward(a)hilcostreambank.com> wrote: That sounds like it would be confusing to me. I’d want to see both the allocation to the LIR and the assignment to the end user independently. Lee From: address-policy-wg <address-policy-wg-bounces(a)ripe.net>On Behalf Of ripedenis--- via address-policy-wg Sent: Monday, November 16, 2020 7:57 AM To: address-policy-wg(a)ripe.net Subject: [address-policy-wg] NWI-4 - role of status: field in multivalued status context -- Last call Colleagues We have not had enough comment on this to make a decision if any change is needed. So can we have a last round of comment to decide if this is a sufficiently important issue to make a change or if we just close this action item? In brief: when assigning a whole allocation should we be able to give the INET(6)NUM object 2 status values to reflect it being both an allocation and an assignment, rather than splitting it into two smaller assignment objects? cheers denis co-chair DB-WG On Monday, 5 October 2020, 16:48:34 CEST, ripedenis--- via address-policy-wg <address-policy-wg(a)ripe.net> wrote: Colleagues I was about to post this to the DB-WG but it may be more appropriate to include it as part of this discussion... Yet another 4 year old NWI that needs to be progressed or closed. The details are here: https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005242.html In summary it concerns the assignment of a whole allocation. Because the range is the primary key (pkey) in the database you cannot have an allocation object and an assignment object with the same pkey. A common work around is to split the allocation and make two assignments. The suggestion is to allow "status:" to be a multiple attribute. This could be done quite easily and constrained in it's use by business rules in the database software. So the syntax could be changed in INET(6)NUM objects to: status: [mandatory] [multiple] [ ] The business rules could make this multiple option only allowed in very limited situations. For example if an INETNUM object has 'status: ALLOCATED PA' it could be possible to add a second value 'status: ASSIGNED PA' or 'status: SUB-ALLLOCATED PA'. If the status in an INET6NUM object is 'status: ALLOCATED-BY-RIR' it could be possible to add a second value 'status: ALLOCATED-BY-LIR' or 'status: ASSIGNED'. The business rules could prevent any other multiple status values. The "descr:" attribute is already multiple so it can describe both the allocation and the assignment. Is this still considered to be an issue? cheers denis co-chair DB-WG On Monday, 5 October 2020, 16:13:53 CEST, Erik Bais <ebais(a)a2b-internet.com> wrote: Dear WG, I want to bring the following email and questions of our PDO - Petrit Hasani to your attention that might have slipped over the vacation period. Please have a look at this discussion again and provide input if you can. Regards, Erik Bais Co-chair AP-WG. ( on behalf of the AP-WG Chair collective ) On 02/07/2020, 13:36, "address-policy-wg on behalf of Petrit Hasani" <address-policy-wg-bounces(a)ripe.net on behalf of phasani(a)ripe.net> wrote: Dear colleagues, Thank you to everyone who responded to our earlier questions on the intent of the policy regarding IPv4 status hierarchies. While this was helpful, it would be great if we could have input from a wider group of people: - Should inetnums with these statuses be allowed to be created inside one another? - Should there be a limit on the minimum size of a sub-allocation? - Do we need a policy update? https://www.ripe.net/ripe/mail/archives/address-policy-wg/2020-June/013195.… We look forward to hearing from you. Cheers, -- Petrit Hasani Policy Officer RIPE NCC > On 16 Jun 2020, at 15:36, Petrit Hasani <phasani(a)ripe.net> wrote: > > Dear colleagues, > > We are reviewing IPv4 status hierarchies in the RIPE Database (looking at objects with the same status as their less-specifics). > > Some cases are clear - "ASSIGNED PA" shouldn't be allowed under "ASSIGNED PA", for example. Other statuses might need a closer look and we would like guidance from this working group. > > The RIPE Database does not currently have any limitations on creating inetnums that have the status "SUB-ALLOCATED PA" or "LIR-PARTITIONED PA" under inetnums with the same status. This often results in chains of inetnums that have the same status, sometimes ending with the sub-allocation of a single IP address. > > Although this might not seem useful at first glance, there might be practical uses for a few levels of sub-allocation. For example, a global company could give sub-allocations to its national branches, which make smaller sub-allocations to their multiple daughter companies. These daughter companies could then create and maintain assignments for their actual networks. > > However, this is not allowed under a strict reading of the policy, as only the LIR itself can make sub-allocations, and these must be used for assignments. > > Section 5.3 "Sub-allocations" of the IPv4 Address Allocation and Assignment Policies (ripe-733) states: > > "Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". > > [...] > > LIRs may make sub-allocations to multiple downstream network operators." > > https://www.ripe.net/publications/docs/ripe-733#54 > > Before making any changes, we want to be sure that we understand the intent of the policy and what the community wants us to do. Thus, we would like to hear from the Address Policy Working Group: > > - Should inetnums with these statuses be allowed to be created inside one another? > - Should there be a limit on the minimum size of a sub-allocation? > - Do we need a policy update? > > We look forward to your guidance. > > Kind regards, > -- > Petrit Hasani > Policy Officer > RIPE NCC > > > > >

1 0

NWI-4 - role of status: field in multivalued status context
by Stephane.Dodeller＠swisscom.com 17 Nov '20

17 Nov '20

Hello Denis, In my opinion, not having the feature forces us to implement the workaround you mention, which hurts data quality because it causes our entries not to reflect the reality of our allocations anymore. So the proposed feature is, in my opinion, needed. Best regards Stéphane Dodeller ---------------------------------------------------------------------- Message: 1 Date: Mon, 16 Nov 2020 12:57:02 +0000 (UTC) From: "ripedenis(a)yahoo.co.uk" <ripedenis(a)yahoo.co.uk> To: "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> Subject: [address-policy-wg] NWI-4 - role of status: field in multivalued status context -- Last call Message-ID: <1444964547.10532158.1605531422218(a)mail.yahoo.com> Content-Type: text/plain; charset="utf-8" Colleagues We have not had enough comment on this to make a decision if any change is needed. So can we have a last round of comment to decide if this is a sufficiently important issue to make a change or if we just close this action item? In brief: when assigning a whole allocation should we be able to give the INET(6)NUM object 2 status values to reflect it being both an allocation and an assignment, rather than splitting it into two smaller assignment objects? cheersdenis co-chair DB-WG On Monday, 5 October 2020, 16:48:34 CEST, ripedenis--- via address-policy-wg <address-policy-wg(a)ripe.net> wrote: Colleagues I was about to post this to the DB-WG but it may be more appropriate to include it as part of this discussion... Yet another 4 year old NWI that needs to be progressed or closed. The details are here:https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.… In summary it concerns the assignment of a whole allocation. Because the range is the primary key (pkey) in the database you cannot have an allocation object and an assignment object with the same pkey. A common work around is to split the allocation and make two assignments. The suggestion is to allow "status:" to be a multiple attribute. This could be done quite easily and constrained in it's use by business rules in the database software. So the syntax could be changed in INET(6)NUM objects to:status:? ? ? ? ?[mandatory]? [multiple]? ? ?[ ] The business rules could make this multiple option only allowed in very limited situations. For example if an INETNUM object has 'status: ALLOCATED PA' it could be possible to add a second value 'status: ASSIGNED PA' or 'status: SUB-ALLLOCATED PA'. If the status in an INET6NUM object is 'status: ALLOCATED-BY-RIR' it could be possible to add a second value 'status: ALLOCATED-BY-LIR' or 'status: ASSIGNED'. The business rules could prevent any other multiple status values. The "descr:" attribute is already multiple so it can describe both the allocation and the assignment. Is this still considered to be an issue? cheersdenis co-chair DB-WG On Monday, 5 October 2020, 16:13:53 CEST, Erik Bais <ebais(a)a2b-internet.com> wrote: Dear WG,? I want to bring the following email and questions of our PDO - Petrit Hasani to your attention that might have slipped over the vacation period.? Please have a look at this discussion again and provide input if you can.? Regards, Erik Bais Co-chair AP-WG. ( on behalf of the AP-WG Chair collective ) ?On 02/07/2020, 13:36, "address-policy-wg on behalf of Petrit Hasani" <address-policy-wg-bounces(a)ripe.net on behalf of phasani(a)ripe.net> wrote: ? ? Dear colleagues, ? ? ? ? Thank you to everyone who responded to our earlier questions on the intent of the policy regarding IPv4 status hierarchies. ? ? ? ? While this was helpful, it would be great if we could have input from a wider group of people: ? ? ? ? - Should inetnums with these statuses be allowed to be created inside one another? ? ? - Should there be a limit on the minimum size of a sub-allocation? ? ? - Do we need a policy update? ? ? ? ? https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.… ? ? ? ? We look forward to hearing from you. ? ? ? ? Cheers, ? ? -- ? ? Petrit Hasani ? ? Policy Officer ? ? RIPE NCC ? ? ? ? ? ? ? ? ? ? ? ? > On 16 Jun 2020, at 15:36, Petrit Hasani <phasani(a)ripe.net> wrote: ? ? > ? ? > Dear colleagues, ? ? > ? ? > We are reviewing IPv4 status hierarchies in the RIPE Database (looking at objects with the same status as their less-specifics). ? ? > ? ? > Some cases are clear - "ASSIGNED PA" shouldn't be allowed under "ASSIGNED PA", for example. Other statuses might need a closer look and we would like guidance from this working group. ? ? > ? ? > The RIPE Database does not currently have any limitations on creating inetnums that have the status "SUB-ALLOCATED PA" or "LIR-PARTITIONED PA" under inetnums with the same status. This often results in chains of inetnums that have the same status, sometimes ending with the sub-allocation of a single IP address. ? ? > ? ? > Although this might not seem useful at first glance, there might be practical uses for a few levels of sub-allocation. For example, a global company could give sub-allocations to its national branches, which make smaller sub-allocations to their multiple daughter companies. These daughter companies could then create and maintain assignments for their actual networks. ? ? > ? ? > However, this is not allowed under a strict reading of the policy, as only the LIR itself can make sub-allocations, and these must be used for assignments. ? ? > ? ? > Section 5.3 "Sub-allocations" of the IPv4 Address Allocation and Assignment Policies (ripe-733) states: ? ? > ? ? > "Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". ? ? > ? ? > [...] ? ? > ? ? > LIRs may make sub-allocations to multiple downstream network operators." ? ? > ? ? > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.… ? ? > ? ? > Before making any changes, we want to be sure that we understand the intent of the policy and what the community wants us to do. Thus, we would like to hear from the Address Policy Working Group: ? ? > ? ? > - Should inetnums with these statuses be allowed to be created inside one another? ? ? > - Should there be a limit on the minimum size of a sub-allocation? ? ? > - Do we need a policy update? ? ? > ? ? > We look forward to your guidance. ? ? > ? ? > Kind regards, ? ? > -- ? ? > Petrit Hasani ? ? > Policy Officer ? ? > RIPE NCC ? ? > ? ? > ? ? > ? ? > ? ? > ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.rip…> End of address-policy-wg Digest, Vol 109, Issue 1 *************************************************

1 0

IPv4 status hierarchies
by Petrit Hasani 16 Nov '20

16 Nov '20

Dear colleagues, We are reviewing IPv4 status hierarchies in the RIPE Database (looking at objects with the same status as their less-specifics). Some cases are clear - "ASSIGNED PA" shouldn't be allowed under "ASSIGNED PA", for example. Other statuses might need a closer look and we would like guidance from this working group. The RIPE Database does not currently have any limitations on creating inetnums that have the status "SUB-ALLOCATED PA" or "LIR-PARTITIONED PA" under inetnums with the same status. This often results in chains of inetnums that have the same status, sometimes ending with the sub-allocation of a single IP address. Although this might not seem useful at first glance, there might be practical uses for a few levels of sub-allocation. For example, a global company could give sub-allocations to its national branches, which make smaller sub-allocations to their multiple daughter companies. These daughter companies could then create and maintain assignments for their actual networks. However, this is not allowed under a strict reading of the policy, as only the LIR itself can make sub-allocations, and these must be used for assignments. Section 5.3 "Sub-allocations" of the IPv4 Address Allocation and Assignment Policies (ripe-733) states: "Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". [...] LIRs may make sub-allocations to multiple downstream network operators." https://www.ripe.net/publications/docs/ripe-733#54 Before making any changes, we want to be sure that we understand the intent of the policy and what the community wants us to do. Thus, we would like to hear from the Address Policy Working Group: - Should inetnums with these statuses be allowed to be created inside one another? - Should there be a limit on the minimum size of a sub-allocation? - Do we need a policy update? We look forward to your guidance. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC

5 7

stockpiling IPv6
by JORDI PALET MARTINEZ 28 Oct '20

28 Oct '20

Hi all, After Nikolas presentation today, I've been thinking on possible ways to resolve this, so before sending a possible policy proposal, I think it deserves some discussion. The intent of the proposal 2018-01 (https://www.ripe.net/participate/policies/proposals/2018-01), was to align the IPv4 and IPv6 policies in the matter of an LIR vs organization. We must remind that the allocation/assignment of resources is based on justified need. And yes, we have a lot of IPv6 space, but it is really justified and the same organization, having different LIRs, can use it as a trick for stockpiling if there is not such justified need? In IPv4 this is not "a problem" because we don't have more space. Well ... not exactly true ... some organizations could have used "the trick" to get more IPv4 space by creating multiple LIRs. In other regions, I think this is not a problem because the cost of the membership is not per "LIR" (flat rate in RIPE NCC), but based on the size of the allocation/assignment. So, because IPv6 is not a scarce resource, it seems there is no incentive to pay more for getting more if you're not really using it. However, in RIPE NCC, if you created several LIRs for getting more IPv4 allocations, *even if you don't use/need it* you can get (and thus stockpile) IPv6 *at no extra cost*. I clearly think this is not a good thing. It seems to me that the problem lies in section 5.1.1. Initial allocation criteria, and exactly here: b) have a plan for making sub-allocations to other organisations and/or End Site assignments within two years. So, is the problem that "a plan" is not sufficient if it is not "verified" and the "bad guys" know that the chances for having it verified are too small? Do we need some text about "recovery if not announced and used" ? Other ideas? Remember that the problem is not only about scarcity. This extra space may be used "intermittently" for bad or even criminal activities and we have a responsibility on that as a community. Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

16 25

Policy Reciprocity
by Taiwo Oyewande 22 Oct '20

22 Oct '20

Hello, I am a co-author of the Resource Transfer Policy, which is the inter-RIR transfer proposal that has just reached consensus within Afrinic, and we are reaching out to you so as to inquire about its reciprocity with RIPE. Your assessment and analysis about this matter would highly be appreciated. Please find below the proposal for your reference. [ Resource Transfer Policy Authors: Anthony Ubah & Taiwo Oyewande Submission date: 21/09/2020 Version: 2.0 Amends: CPM 5.7 1. Summary of the problem being addressed by this proposal The current policy fails to support a two-way Inter-RIR policy, thereby hindering smooth business operation, development, and growth in the region. This proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. This proposal outlines a model in which AFRINIC can freely transfer number resources to/from other regions, i.e. RIPE NCC, APNIC, ARIN and LACNIC. This includes both IPv4 addresses and AS numbers. 2. Summary of how this proposal addresses the problem With the exhaustion of IPv4, several regions have adopted a transfer policy to accommodate the shortage of resources. Number resources are allowed to transfer within the region itself, as well as with other regions. Such practice is effective and necessary when we are facing a shortage of resources. This helps facilitate business operations while reducing prices. Such Inter-RIR transfer, however, is not yet established in AFRINIC. This hinders business operation and development within the African region. The current proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. Before moving to illustrate how this new mechanism works, let’s take a quick look at the situation of the current Consolidated Policy Manual: In Consolidated Policy Manual updated on 22 Feb 2019, only “IPv4 resources transfer within the AFRINIC region” is mentioned. Regarding resource transfer to other regions, only the following is mentioned: 5.5.1.1.3 If an LIR plans to exchange or transfer address space, it needs to contact AFRINIC so that the changes are properly registered. The LIR remains responsible for all the allocations registered in the AFRINIC database until they have been transferred to another LIR or returned to AFRINIC. LIR's must ensure that all policies are applied. The lack of a clear guideline of resource transfer is detrimental to the continent’s development. It makes business operation difficult and it also hinders new business from establishing in the region. Also, as Inter RIR policy is enforced in other regions, it is important that AFRINIC keeps up with other RIRs to ensure smooth operation and coordination. 3. Proposal CPM 5.7 will be modified by this proposal as follows: 5.7 IPv4 Resources resource transfer Like the other Regional Internet Registries, AFRINIC will soon exhaust its IPv4 pool. In order to meet the needs of late resource requestors, a transfer policy for IPv4 resources within and outside the region is needed. The goal of this policy is to define conditions under which transfers must occur. The policy solves the issue of an African organization needing IPv4 number resources after the exhaustion of the AFRINIC IPv4 pool or when AFRINIC can no longer satisfy the needs of such an organization. 5.7.1 Summary of the policy This policy applies to any transfer request raised by a resource holder for resource transfer to and from the AFRINIC region. 5.7.2 IPv4 resources to be transferred - must be from an existing AFRINIC or any RIR member's account or from a Legacy Resource Holder. 5.7.3. Conditions on the source of the transfer 5.7.3.1 The source must be the current and rightful holder of the IPv4 address resources registered with any RIR , and shall not be involved in any disputes as to those resources' status. 5.7.3.2 Source entities are not eligible to receive any further IPv4 allocations or assignments from AFRINIC for a period of twelve (12) months after a transfer is approved. Incoming transferred resource cannot be transferred again for a period of twelve(12) months. 5.7.3.3 There is no upper limit regarding the amount of transfer, allocation and assignment of IPv4 number resources a source entity can receive as long as the transfer request is carried out under a mutual agreement between the source and the recipient. 5.7.4. Conditions on the recipient of the transfer 5.7.4.1 A transfer from another RIR to AFRINIC requires a need-based evaluation. AFRINIC must approve the recipient's need for the IPv4 number resources. In order for an organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resource needs before AFRINIC. That is to say, the organization must justify and demonstrate before AFRINIC its initial/additional allocation/assignment usage, as applicable, according to the policies in force. A transfer from AFRINIC to another RIR must follow the relevant policies. 5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy holders in any region 5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources.] We are looking forward to hearing from you. Regards, Taiwo O

13 24

Assignments have legacy status, not IP addresses themselves
by David Farmer 21 Oct '20

21 Oct '20

The concept that the legacy status applies independently to resources or IP addresses, separate from their assignment to a resource holder, seems incorrect. The legacy status applies to the assignment of resources to a resource holder before the creation of the RIRs, but not to the resources or the IP addresses themselves. All IPv4 addresses were created at the same time. When they were assigned for use differs; therefore, when they were assigned for use and to whom they are assigned for use is what matters. When addresses are transferred to a different organization, a new assignment is made, or in other words, they are reassigned. And it seems proper that the new assignment no longer has the legacy status, as they are now assigned to a different organization. When a merger or acquisition occurs, we also call that a transfer, but it is a transfer to a new version of the same organization, not to a different organization. In this case, it seems propers that the assignment maintains its legacy status, as the same organization, just a different version of the same organization, continues to hold the assignment. The legacy status is important and is not a mistake because, as a community, we believe it is important to maintain the uniqueness of the assignments made before the creation of the RIRs. However, at least in my opinion, it is a mistake to believe that the legacy status applies to IP addresses independent of who holds the assignment. Thank you. -- =============================================== David Farmer Email:farmer@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 ===============================================

2 2

Re: [address-policy-wg] FW: Policy Reciprocity
by JORDI PALET MARTINEZ 19 Oct '20

19 Oct '20

Hi Erik, Regarding your response on reciprocity: If we do that in AFRINIC, then, there is no reciprocity with ARIN, which is the bigger “donor”. I already tried several models, for both LACNIC and AFRINIC, and they didn’t work out. Finally, making a full reciprocal proposal in LACNIC worked and it was implemented already since last July. I also included a “security belt” in the AFRINIC proposal so the board can “control” if anything is going wrong by six consecutive months, to stop the policy … the community was happy initially with that, but later on, there were to other competitive proposals that make the people unhappy again … Point 5.7.4.3 is broken, the idea was “incoming transferred legacy resources will no longer be regarded as legacy”, because that’s what we have now already for intra-RIR (and this policy motifies that to become intra and inter). Regards, Jordi @jordipalet El 19/10/20 15:52, "address-policy-wg en nombre de Erik Bais" <address-policy-wg-bounces(a)ripe.net en nombre de ebais(a)a2b-internet.com> escribió: Hi Petrit & Taiwo, Petrit, could you have a look at the following question from Taiwo in regards to the Afrinic policy proposal reciprocity with the current RIPE Transfer Policy. To Taiwo, <personal view> Personally I would argue if reciprocity should be desired for the Afrinic region, as long as AFRINIC still holds IP numbers to be handed out. I personally would prefer the AFRINIC inter-rir transfer policy to be incoming from other RIR’s only, to avoid the AFRINIC space to be removed from the region. ( As I think Afrinic would need them more to develop its own inter regional growth. ) Am I correct to assume that Afrinic at the current distribution rate would have about 30 months of IP space left ? So perhaps opening the bi-directional inter-rir transfers, could start once the AFRINIC region actually has no space left in its free pool. </end personal view> In the RIPE region, there is a 24 month transfer limitation on the resource that was transferred itself, there is no further limitation on either the leaving (source) or receiving (target) entity to engage in other transactions. On the point : Ø 5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy holders in any region The AFRINIC legal team might have to look if this is phrased correctly, as you can’t (shouldn’t be able ) to move Afrinic Allocated space to a Legacy space holder.. Afrinic allocated space should only be able to move to any of the other RIR members. Not directly to a Legacy holder. Legacy space registered in the Afrinic region could go to any organisation, regardless if they are a RIR member. There might be other contractual requirements required in the receiving RIR.. as the RIPE legacy policy would explain for the RIPE region. I can see the intention, but that is not what the policy states. (or how I read it..) And on point : Ø 5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources.] If you would remove the word incoming, it would provide a more bi-directional way of looking at it, from an AFRINIC perspective. And still leave it to the receiving RIR to apply their own Legacy ‘policy’ Regards, Erik Bais Co-chair of AP-WG https://www.ripe.net/publications/docs/ripe-682 - RIPE Transfer policy ( including intra and inter-rir transfers ) https://www.ripe.net/publications/docs/ripe-639 - RIPE NCC Services to Legacy Internet Resource Holders ( aka the RIPE Legacy services policy ) https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services… ( Services provided based on the type of contractual agreement with the RIPE NCC ) From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> on behalf of Taiwo Oyewande <taiwo.oyewande88(a)gmail.com> Date: Friday 16 October 2020 at 13:35 To: "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> Cc: Anthony Ubah <ubah.tonyiyke(a)gmail.com> Subject: [address-policy-wg] Policy Reciprocity Hello, I am a co-author of the Resource Transfer Policy, which is the inter-RIR transfer proposal that has just reached consensus within Afrinic, and we are reaching out to you so as to inquire about its reciprocity with RIPE. Your assessment and analysis about this matter would highly be appreciated. Please find below the proposal for your reference. [ Resource Transfer Policy Authors: Anthony Ubah & Taiwo Oyewande Submission date: 21/09/2020 Version: 2.0 Amends: CPM 5.7 1. Summary of the problem being addressed by this proposal The current policy fails to support a two-way Inter-RIR policy, thereby hindering smooth business operation, development, and growth in the region. This proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. This proposal outlines a model in which AFRINIC can freely transfer number resources to/from other regions, i.e. RIPE NCC, APNIC, ARIN and LACNIC. This includes both IPv4 addresses and AS numbers. 2. Summary of how this proposal addresses the problem With the exhaustion of IPv4, several regions have adopted a transfer policy to accommodate the shortage of resources. Number resources are allowed to transfer within the region itself, as well as with other regions. Such practice is effective and necessary when we are facing a shortage of resources. This helps facilitate business operations while reducing prices. Such Inter-RIR transfer, however, is not yet established in AFRINIC. This hinders business operation and development within the African region. The current proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. Before moving to illustrate how this new mechanism works, let’s take a quick look at the situation of the current Consolidated Policy Manual: In Consolidated Policy Manual updated on 22 Feb 2019, only “IPv4 resources transfer within the AFRINIC region” is mentioned. Regarding resource transfer to other regions, only the following is mentioned: 5.5.1.1.3 If an LIR plans to exchange or transfer address space, it needs to contact AFRINIC so that the changes are properly registered. The LIR remains responsible for all the allocations registered in the AFRINIC database until they have been transferred to another LIR or returned to AFRINIC. LIR's must ensure that all policies are applied. The lack of a clear guideline of resource transfer is detrimental to the continent’s development. It makes business operation difficult and it also hinders new business from establishing in the region. Also, as Inter RIR policy is enforced in other regions, it is important that AFRINIC keeps up with other RIRs to ensure smooth operation and coordination. 3. Proposal CPM 5.7 will be modified by this proposal as follows: 5.7 IPv4 Resources resource transfer Like the other Regional Internet Registries, AFRINIC will soon exhaust its IPv4 pool. In order to meet the needs of late resource requestors, a transfer policy for IPv4 resources within and outside the region is needed. The goal of this policy is to define conditions under which transfers must occur. The policy solves the issue of an African organization needing IPv4 number resources after the exhaustion of the AFRINIC IPv4 pool or when AFRINIC can no longer satisfy the needs of such an organization. 5.7.1 Summary of the policy This policy applies to any transfer request raised by a resource holder for resource transfer to and from the AFRINIC region. 5.7.2 IPv4 resources to be transferred - must be from an existing AFRINIC or any RIR member's account or from a Legacy Resource Holder. 5.7.3. Conditions on the source of the transfer 5.7.3.1 The source must be the current and rightful holder of the IPv4 address resources registered with any RIR , and shall not be involved in any disputes as to those resources' status. 5.7.3.2 Source entities are not eligible to receive any further IPv4 allocations or assignments from AFRINIC for a period of twelve (12) months after a transfer is approved. Incoming transferred resource cannot be transferred again for a period of twelve(12) months. 5.7.3.3 There is no upper limit regarding the amount of transfer, allocation and assignment of IPv4 number resources a source entity can receive as long as the transfer request is carried out under a mutual agreement between the source and the recipient. 5.7.4. Conditions on the recipient of the transfer 5.7.4.1 A transfer from another RIR to AFRINIC requires a need-based evaluation. AFRINIC must approve the recipient's need for the IPv4 number resources. In order for an organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resource needs before AFRINIC. That is to say, the organization must justify and demonstrate before AFRINIC its initial/additional allocation/assignment usage, as applicable, according to the policies in force. A transfer from AFRINIC to another RIR must follow the relevant policies. 5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy holders in any region 5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources.] We are looking forward to hearing from you. Regards, Taiwo O ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

1 0

Draft Agenda RIPE81 - virtual AP-WG
by Erik Bais 12 Oct '20

12 Oct '20

Dear working group, dear RIPE meeting folks, Below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in online on the following time slot: Wednesday, Oct 28, 10:00 - 10:45 As we only have 1 time slot, we have a packed agenda. We don’t have any open policy discussions atm, however if you have any Address Policy related policy suggestions, feel free to reach out to us. Besides the usual PDO/RIR & Registration services updates, we will also have a presentation from the RIPE NCC legal team about the topic: Seizure of the “Right to Registration of IPv4 Addresses” for the Recovery of Money. As WG Chairs we thought it would be a good topic to discuss in the AP-WG. So make sure you are present for the session. Regards, Gert Döring & Erik Bais, APWG chairs ---------------------------------------------------------------------- Wednesday, 10:00-10:45 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics – Petrit Hasani – RIPE NCC PDO - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE 80 - brief overview of new proposals (if any) C. Feedback from NCC Registration Service - Nikolas Pediaditis (+ discussion with the group) D. Presentation about the Seizure of the “Right to Registration of IPv4 Addresses” - Ciaran Byrne ( Legal Counsel of the RIPE NCC ) Z. AOB

1 0