From phasani at ripe.net Thu Jul 2 13:36:43 2020 From: phasani at ripe.net (Petrit Hasani) Date: Thu, 2 Jul 2020 13:36:43 +0200 Subject: [address-policy-wg] IPv4 status hierarchies In-Reply-To: References: Message-ID: <5E5F66CA-A7DC-455F-A1D7-0E43D3CCB8C1@ripe.net> 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.html We look forward to hearing from you. Cheers, -- Petrit Hasani Policy Officer RIPE NCC > On 16 Jun 2020, at 15:36, Petrit Hasani 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 > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From npediaditi at ripe.net Wed Jul 22 17:32:21 2020 From: npediaditi at ripe.net (Nikolas Pediaditis) Date: Wed, 22 Jul 2020 17:32:21 +0200 Subject: [address-policy-wg] LACNIC Inter-RIR Transfer Policy Implemented Message-ID: 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-transfers 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/inter-rir-transfers 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 From Kurt.Kayser at bmi.bund.de Thu Jul 23 16:40:38 2020 From: Kurt.Kayser at bmi.bund.de (Kurt.Kayser at bmi.bund.de) Date: Thu, 23 Jul 2020 14:40:38 +0000 Subject: [address-policy-wg] WG: Question regarding RIPE-738 IPv6-Policy Message-ID: <3ee27df791ea4a868b8954649d01936d@bmi.bund.de> 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 at bmi.bund.de Internet: www.bdbos.bund.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu Jul 23 16:53:12 2020 From: gert at space.net (Gert Doering) Date: Thu, 23 Jul 2020 16:53:12 +0200 Subject: [address-policy-wg] WG: Question regarding RIPE-738 IPv6-Policy In-Reply-To: <3ee27df791ea4a868b8954649d01936d@bmi.bund.de> References: <3ee27df791ea4a868b8954649d01936d@bmi.bund.de> Message-ID: <20200723145312.GX2485@Space.Net> Hi Kurt, On Thu, Jul 23, 2020 at 02:40:38PM +0000, Kurt.Kayser at bmi.bund.de wrote: > What is the correct way to calculcate the utilization? Count /56s assigned. /48s count as 256x /56. Look up /56 count in the HD ratio table. The confusing sentence is supposed to convey "we care about efficiency of usage inside the 'allocation' arena", so "/56 or /48 inside the /32 or larger". We do not care about efficiency in the "assigned chunk", so in the /56 we do not care if 1 address was used or 100. (Which is different from IPv4, so it ended up in this - very old - text) Less confusing now? Or did I make it worse? 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 Kurt.Kayser at bmi.bund.de Fri Jul 24 10:37:31 2020 From: Kurt.Kayser at bmi.bund.de (Kurt.Kayser at bmi.bund.de) Date: Fri, 24 Jul 2020 08:37:31 +0000 Subject: [address-policy-wg] WG: Question regarding RIPE-738 IPv6-Policy In-Reply-To: <20200723145312.GX2485@Space.Net> References: <3ee27df791ea4a868b8954649d01936d@bmi.bund.de> <20200723145312.GX2485@Space.Net> Message-ID: <65bbcf63cbb0423fa20e5e3c953d93df@bmi.bund.de> Hello Gert, thanks for clarification. The main sentence that confused me was this in Appendix A: " It is an address allocation utilisation ratio and not an address assignment utilisation ratio." What you now explain still defines a classical "assignment utilization rate" with a limted look up to a /56 granularity. I assume the misinterpretation is the second part which does not require "full subnets", hence again the term "allocation". So there are 3 parts to correctly calculate HD-ratios: 1. IP-Allocation from RIR to LIRs 2. Assignments for true use from LIR to endsites/users/devices - to be counted as /56 or /48 units (as shown as "used" in the LIR portal) 3. All networks below /56 that are assigned are not to be evaluated deeper about efficient usage. Correct? 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 at bmi.bund.de Internet:?www.bdbos.bund.de -----Urspr?ngliche Nachricht----- Von: Gert Doering Gesendet: Donnerstag, 23. Juli 2020 16:53 An: Kayser (Extern), Kurt Cc: address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] WG: Question regarding RIPE-738 IPv6-Policy Hi Kurt, On Thu, Jul 23, 2020 at 02:40:38PM +0000, Kurt.Kayser at bmi.bund.de wrote: > What is the correct way to calculcate the utilization? Count /56s assigned. /48s count as 256x /56. Look up /56 count in the HD ratio table. The confusing sentence is supposed to convey "we care about efficiency of usage inside the 'allocation' arena", so "/56 or /48 inside the /32 or larger". We do not care about efficiency in the "assigned chunk", so in the /56 we do not care if 1 address was used or 100. (Which is different from IPv4, so it ended up in this - very old - text) Less confusing now? Or did I make it worse? 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