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

Re: [address-policy-wg] IPv4 status hierarchies
by Stephane.Dodeller＠swisscom.com 05 Oct '20

05 Oct '20

Dear Denis, Since the workaround you mention creates entries in the database that do not match in some cases the reality of what has been done (and allowed by the policy), especially during the ALLOCATED-UNSPECIFIED cleanup period, I support the change you mention. Best regards Stéphane Dodeller Swisscom (ch.unisource) Le 05.10.20 16:48, « address-policy-wg au nom de address-policy-wg-request(a)ripe.net » <address-policy-wg-bounces(a)ripe.net au nom de address-policy-wg-request(a)ripe.net> a écrit : Date: Mon, 5 Oct 2020 14:45:44 +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>, Erik Bais <ebais(a)a2b-internet.com> Subject: Re: [address-policy-wg] IPv4 status hierarchies Message-ID: <1260079472.3251832.1601909144595(a)mail.yahoo.com> Content-Type: text/plain; charset="utf-8" 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 108, Issue 2 *************************************************

1 0

New on RIPE Labs: A First for the RIPE NCC - Seizure of the “Right to Registration of IPv4 Addresses” for the Recovery of Money
by Alun Davies 02 Oct '20

02 Oct '20

Dear colleagues, We recently processed our first IPv4 transfer on the basis of a Dutch court order. In this RIPE Labs article, we provide an overview of the case and look at how things will work moving forwards: https://labs.ripe.net/Members/ciaran_byrne/seizure-of-the-right-to-registra… Kind regards, Alun Davies RIPE NCC

1 0

New on RIPE Labs: IPv4 Transfer Markets Misuse: A First Look
by Mirjam Kuehne 17 Aug '20

17 Aug '20

Dear colleagues, In this article Vasileios Giotsas summarises the results of a detailed study of how transferred IPv4 prefixes are misused in the wild by synthesising an array of longitudinal IP blacklists, honeypot data, and AS reputation lists: https://labs.ripe.net/Members/vgiotsas/a-first-look-at-the-misuse-and-abuse… This research was supported by the RIPE NCC Projects Fund. Kind regards, Mirjam Kühne RIPE NCC

2 1

WG: Question regarding RIPE-738 IPv6-Policy
by Kurt.Kayser＠bmi.bund.de 24 Jul '20

24 Jul '20

Dear RIPE members and community, We have come across a question of correct interpretation for "utilization" wthin´the current "IPv6 Address Allocation and Assignment Policy" RIPE-738 document: 5.2.2. Applied HD-Ratio The HD-Ratio value of 0.94 is adopted as indicating an acceptable address utilisation for justifying the allocation of additional address space. Appendix A provides a table showing the number of assignments that are necessary to achieve an acceptable utilisation value for a given address block size. [...] 10. Appendix A: HD-Ratio The utilisation threshold T, expressed as a number of individual /56 prefixes to be allocated from IPv6 prefix P, can be calculated as: T = 2((56-P)*HD) Thus, the utilisation threshold for an LIR requesting subsequent allocation of IPv6 address block is specified as a function of the prefix size and target HD ratio. This utilisation refers to the use of /56s as an efficiency measurement unit, and does not refer to the utilisation of addresses within those End Sites. It is an address allocation utilisation ratio and not an address assignment utilisation ratio. [...] The two underlined sentences seem to contradict each other. For a correct interpretation and calculation of the HD-Ratio/Utilization-Threshold (T) for IPv6-subsequent block eligibility, what is now correct "allocation" or "assignment" ? In the LIR-Portal there is an %-indication for "my own resources" which soley refers to assignments within a specific block. Allocations seem not to be considered. What is the correct way to calculcate the utilization? Best regards, on behalf Kurt Kayser _______________________ Kurt Kayser Konsultation im Auftrag des Referates SK 4 - Konzeption/ Local Internet Registry Bundesanstalt für den Digitalfunk der Behörden und Organisationen mit Sicherheitsaufgaben (BDBOS) Telefon: +49 (0) 1575-2634020 E-Mail: Kurt.Kayser(a)bmi.bund.de<mailto:Kurt.Kayser@bmi.bund.de> Internet: www.bdbos.bund.de<http://www.bmi.bund.de/>

2 2

LACNIC Inter-RIR Transfer Policy Implemented
by Nikolas Pediaditis 22 Jul '20

22 Jul '20

Dear colleagues, Yesterday, LACNIC announced that they have implemented their inter-RIR transfer policy: https://www.lacnic.net/4711/2/lacnic/lacnic-starts-processing-inter-rir-tra… This means that IPv4 addresses can now be transferred between organisations in the RIPE NCC and LACNIC regions (IPv6 and AS Numbers are excluded from LACNIC's inter-RIR transfer policy). You can find more information on inter-RIR transfers on our website: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/int… It's worth noting that an inter-RIR transfer request should always start with the offering party via the "source" RIR that the resources are currently registered with. Kind regards, Nikolas Pediaditis Registration Services & Policy Development Manager RIPE NCC

1 0

RIPE 79 Address Policy WG Draft Minutes
by Petrit Hasani 10 Jun '20

10 Jun '20

Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 79 have now been published: https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-79-address-policy-… Please let us know of any corrections or amendments. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC

3 2

RIPE 80 Address Policy WG Draft Minutes
by Petrit Hasani 09 Jun '20

09 Jun '20

Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 80 have now been published: https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-80-address-policy-… Please let us know of any corrections or amendments. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC

1 0

RIPE 80 Address Policy WG Draft Minutes
by Petrit Hasani 09 Jun '20

09 Jun '20

Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 80 have now been published: https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-80-address-policy-… Please let us know of any corrections or amendments. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC

1 0

Post on List
by Clear Writing Solutions 29 May '20

29 May '20

clearwriting123(a)gmail.com

1 0

Re: [address-policy-wg] policy compliance dashboard
by Michele Neylon - Blacknight 14 May '20

14 May '20

Lack of response to who? The NCC? What benefit is this meant to bring? I'd assume the NCC would already know about members who aren't paying their bills or otherwise in breach of contractual obligations. Members who "care" will probably deal with issues and those who don't care won't start caring, so I'm struggling to see what value this brings Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com https://blacknight.blog / http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, R93 X265,Ireland Company No.: 370845 On 13/05/2020, 10:41, "address-policy-wg on behalf of JORDI PALET MARTINEZ via address-policy-wg" <address-policy-wg-bounces(a)ripe.net on behalf of address-policy-wg(a)ripe.net> wrote: After my comment in the Addressing Policy meeting, I decided to go ahead with this email, maybe it can a provocation for some inputs in the open mic ... Note that this text is from my AFRINIC proposal (to make it quick now), so disregard parts that may not correctly matches the RIPE NCC situation and may be some of the things are already done here. Text: ***** "The Policy Compliance Dashboard” shows to each member its status of policy compliance, collected by means of a periodical review, automated as much as possible. The dashboard will show all possible details to match the policies and RSA, such as: * Contractual obligations (such as status of payments or documents). * Lack of response from the member. * Unused or unannounced resources (where mandatory). * Unavailable or outdated Whois information. * Lack of maintenance of the reverse delegation. * Forbidden sub-assignments (from PI assignments). * Unauthorized transfers. * Tracking of repeated and/or continued policy violations. The dashboard automation will need to be accommodated along policies evolves thru the PDP, in order to display new details. The dashboard will automatically send notifications of the status of compliance to members, after each review or dashboard update. Reminders will be periodically sent in case of any lack of compliance. In this case, warnings will be also sent to the staff. ***** I've also the feeling that it may be more appropriate for Services WG, so copied as well. Any thoughts? 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.

2 2