From jerome at ceriz.fr Tue Nov 1 01:38:57 2022 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Tue, 1 Nov 2022 01:38:57 +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: <6f90df2a-fe9b-92d5-11d3-855875df8d2c@ceriz.fr> Tore, Thank you for your honest statement. I feel likewise. Le 31/10/2022 ? 14:41, Tore Anderson a ?crit?: > Playing devil's advocate, I would argue that the moment some broadband > subscriber decides to set up a port forwarding of 443/tcp to some web > server on the LAN where a cake recipe blog is hosted or whatever, the > LIR/ISP is then instantly obligated to create a individualised /32 > assignment for that address. It is neither wanted (would potentially conflicts with EU' GDPR in some ways), nor technically feasible (would create way too much load on the database as we'd all have to update it in realtime). > ? > For IPv6 we use AGGREGATED-BY-LIR for these ranges, and would be nice > to be able to ("legally") do something similar for IPv4. That's what LIR' "Provider Assignments" are for : you stick them up to your BNG's and it never had to do with any individual customers. I'm not sure we have an issue here, it has been best practice and well adopted since I came around? Some zeolots of course did declare each and every B2B customer as to brag about it or offload their hotlines, but that's probably a misinterpretation of current policies. As far as I know it never happened on residential broadband yet. Best Regards, -- J?r?me Nicolle +33 6 19 31 27 14 From tore at fud.no Tue Nov 1 11:25:32 2022 From: tore at fud.no (Tore Anderson) Date: Tue, 01 Nov 2022 11:25:32 +0100 Subject: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database) In-Reply-To: <6f90df2a-fe9b-92d5-11d3-855875df8d2c@ceriz.fr> References: <15e9e1d1779bde9d8878ae64876e4f075619c88b.camel@fud.no> <08f4bc76c26affeeabbe86734ae536af9432e9ea.camel@fud.no> <6f90df2a-fe9b-92d5-11d3-855875df8d2c@ceriz.fr> Message-ID: * J?r?me Nicolle > Thank you for your honest statement. I feel likewise. > > Le 31/10/2022 ? 14:41, Tore Anderson a ?crit?: > > Playing devil's advocate, I would argue that the moment some broadband > > subscriber decides to set up a port forwarding of 443/tcp to some web > > server on the LAN where a cake recipe blog is hosted or whatever, the > > LIR/ISP is then instantly obligated to create a individualised /32 > > assignment for that address. > > It is neither wanted (would potentially conflicts with EU' GDPR in some > ways), nor technically feasible (would create way too much load on the > database as we'd all have to update it in realtime). The policy in question allows the LIR to replace the End User's contact information with its own, in case the End User is an individual. This solves the GDPR issue, but it does not allow for aggregating a pool of such assignments ? unless they are *solely* used for the connection of the End User to the service provider. https://www.ripe.net/publications/docs/ripe-733#62 > > For IPv6 we use AGGREGATED-BY-LIR for these ranges, and would be nice > > to be able to ("legally") do something similar for IPv4. > > That's what LIR' "Provider Assignments" are for : you stick them up to > your BNG's and it never had to do with any individual customers. > > I'm not sure we have an issue here, it has been best practice and well > adopted since I came around? > > Some zeolots of course did declare each and every B2B customer as to > brag about it or offload their hotlines, but that's probably a > misinterpretation of current policies. As far as I know it never > happened on residential broadband yet. Actually, declaring each and every customer assignment in that way is probably the correct and de jure way to following the policy to the letter ? again, unless the assigned addresses in question are all *solely* used for the connection to the service provider. However, given a thousand random broadband customers, you're pretty much certain to find at least one that uses the IPv4 address for something additional, like running a server of some sort. The policy *does* require separate assignments for those (regardless of them being individuals or organisations). Now, as you say, the best practice or de facto interpretation of policy is to simply ignore that requirement because it's not really technically feasible. Yet, https://www.ripe.net/publications/docs/ripe-767#612 suggest that least some LIRs are pedantically following policy to the letter, by ?overassigning? individual /32s. I think, therefore, that it would be good to bring the policy text itself in alignment with the de facto/best practice interpretation most of us follow. 2022-02 in its current form is one way to do that, while backporting IPv6's AGGREGATED-BY-LIR would be another. Tore From matthias.wichtlhuber at de-cix.net Tue Nov 1 11:43:31 2022 From: matthias.wichtlhuber at de-cix.net (Matthias Wichtlhuber) Date: Tue, 1 Nov 2022 10:43:31 +0000 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> , <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net>, <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> Message-ID: While I think a /29 would be too radical (renumbering peering LANs can be a real headache, you don't want to do that more often than needed), a /26 as a default might be a good compromise. 62 usable addresses are still enough for ~70% of all IXes including 100% over provisioning. This would likely stretch the pool well into the 2030s. Other than that, I think the current policy is fine and I wouldn't want to touch any other parts of it. -- 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: Tore Anderson Gesendet: Montag, 31. Oktober 2022 13:18:51 An: Matthias Wichtlhuber; Kurt Kayser; address-policy-wg at ripe.net Cc: Sander Steffann; Arnold Nipper; Gert Doering Betreff: Re: [address-policy-wg] IXP pool lower boundary of assignments * 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 frettled at gmail.com Tue Nov 1 11:46:52 2022 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 1 Nov 2022 11:46:52 +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> <08f4bc76c26affeeabbe86734ae536af9432e9ea.camel@fud.no> <6f90df2a-fe9b-92d5-11d3-855875df8d2c@ceriz.fr> Message-ID: On Tue, Nov 1, 2022 at 11:25 AM Tore Anderson wrote: > > I think, therefore, that it would be good to bring the policy text > itself in alignment with the de facto/best practice interpretation most > of us follow. 2022-02 in its current form is one way to do that, while > backporting IPv6's AGGREGATED-BY-LIR would be another. > > I don't have anything to add really, just my agreement. Thanks, Tore! -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Tue Nov 1 12:18:45 2022 From: tore at fud.no (Tore Anderson) Date: Tue, 01 Nov 2022 12:18:45 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> , <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> ,<61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> Message-ID: * Matthias Wichtlhuber > While I think a /29 would be too radical (renumbering peering LANs > can be a real headache, you don't want to do that more often than > needed), a /26 as a default might be a good compromise. 62 usable > addresses are still enough for ~70% of all IXes including 100% over > provisioning. This would likely stretch the pool well into the 2030s. The IXP pool was created in 2012 (2011-05). In 2019 (2019-05) we went ?whoops, we're burning through it too fast, more is needed?, and doubled its size. In 2022, today, we're again going ?whoops, we're burning through it too fast?, proposing to only slightly change the default assignment value to /25 (or /26). I see a pattern here? How long before the next ?whoops, we're burning through it too fast?? Will we at that point change the default by another bit, going to /26 (or /27)? Renumbering is a headache, but it is doable (it has been done many times before), and the IXP community could certainly create a BCP document on how to best do it ? if one does not exist already. Conditioning new IXPs already from their very infancy that they will need to renumber every time they double in size already (when renumbering is the least painful) is not unreasonable, in my opinion. This requirement is balanced against the preservation of the IXP pool for future and growing IXPs, after all. If a new IXP with three founding members and a small/unrealistic prospect of future growth applies for an IXP assignment, I think the radical approach is to give that IXP something larger than the /29 it actually requires. Doing so will inevitably mean that some other IXP will be told ?sorry, fresh out, no assignment for you? at some point in the future. Tore From matthias.wichtlhuber at de-cix.net Tue Nov 1 14:11:31 2022 From: matthias.wichtlhuber at de-cix.net (Matthias Wichtlhuber) Date: Tue, 1 Nov 2022 13:11:31 +0000 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> , <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> ,<61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> , Message-ID: <7b5f743937f7472fa08a361225fd0427@de-cix.net> Last time we extended the pool, but we did not change the burn rate by setting /24s as the default. You can easily see that in Marco's presentation, the extended pool is currently emptied at a comparable rate as before. If we change the default to /26, that would mean a quarter of the previous burn rate thus quadrupling the lifetime of the pool (if we assume a constant burn rate). I do not see the pattern repeating here. Moreover, I have updated the analysis to include /29s (which I previously cut off). Only ~25% of all IXPs would fit into such a small peering LAN. Setting the default to /29 will likely cripple the growth of IXes. There is also no benefit in retaining these resources if they are needed. https://github.com/mwichtlh/address-policy-wg -- 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: Tore Anderson Gesendet: Dienstag, 1. November 2022 12:18:45 An: Matthias Wichtlhuber; Kurt Kayser; address-policy-wg at ripe.net Cc: Sander Steffann; Arnold Nipper; Gert Doering Betreff: Re: AW: [address-policy-wg] IXP pool lower boundary of assignments * Matthias Wichtlhuber > While I think a /29 would be too radical (renumbering peering LANs > can be a real headache, you don't want to do that more often than > needed), a /26 as a default might be a good compromise. 62 usable > addresses are still enough for ~70% of all IXes including 100% over > provisioning. This would likely stretch the pool well into the 2030s. The IXP pool was created in 2012 (2011-05). In 2019 (2019-05) we went ?whoops, we're burning through it too fast, more is needed?, and doubled its size. In 2022, today, we're again going ?whoops, we're burning through it too fast?, proposing to only slightly change the default assignment value to /25 (or /26). I see a pattern here? How long before the next ?whoops, we're burning through it too fast?? Will we at that point change the default by another bit, going to /26 (or /27)? Renumbering is a headache, but it is doable (it has been done many times before), and the IXP community could certainly create a BCP document on how to best do it ? if one does not exist already. Conditioning new IXPs already from their very infancy that they will need to renumber every time they double in size already (when renumbering is the least painful) is not unreasonable, in my opinion. This requirement is balanced against the preservation of the IXP pool for future and growing IXPs, after all. If a new IXP with three founding members and a small/unrealistic prospect of future growth applies for an IXP assignment, I think the radical approach is to give that IXP something larger than the /29 it actually requires. Doing so will inevitably mean that some other IXP will be told ?sorry, fresh out, no assignment for you? at some point in the future. Tore From tore at fud.no Tue Nov 1 15:48:48 2022 From: tore at fud.no (Tore Anderson) Date: Tue, 01 Nov 2022 15:48:48 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <7b5f743937f7472fa08a361225fd0427@de-cix.net> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> , <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> ,<61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> , <7b5f743937f7472fa08a361225fd0427@de-cix.net> Message-ID: <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> * Matthias Wichtlhuber > Moreover, I have updated the analysis to include /29s (which I > previously cut off). Only ~25% of all IXPs would fit into such a > small peering LAN. Setting the default to /29 will likely cripple the > growth of IXes. There is also no benefit in retaining these resources > if they are needed. > > https://github.com/mwichtlh/address-policy-wg Thank you for updating! It is always nice to have real data to look at. I think I disagree with your use of ?only?. 25% isn't ?only? in my opinion, that's a quite considerable share of the total. If I read your report correctly, the group of IX-es that will manage comfortably with a /29 is in fact the largest group of them all! (Here I do say manage "comfortably" since your report state that it assumes 100% oversubscription, which I take to mean that the IX-es in each bracket can *at least* double their member count without running out of addresses.) Also I don't understand your ?crippling the growth? concern. The 75% if IX-es that need something bigger then a /29, they would of course get something bigger ? just like they do today, if they need something bigger than a /24. Has today's policy, where /24 is the default, ?crippled? any IX from growing past 254 connected members? If not, how exactly would a default /29 policy ?cripple? an IX from growing past 6 members, or a default /28 ?cripple? it from growing past 14 members for that matter? Or to put it another way: if we change the default to /25 or /26 as you propose, wouldn't that change ? in the exact same way as for /29 ? ?cripple the growth? of those IX-es past 126 or 62 connected members? If so, how come that is OK, if it isn't OK for /29? Tore From wolfgang.tremmel at de-cix.net Tue Nov 1 16:31:00 2022 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Tue, 1 Nov 2022 15:31:00 +0000 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> Message-ID: <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> No. But renumbering an IX is *pain*. A lot of pain. You want to avoid that if possible. A /26 allows (given that the IX uses about 2-4 IPs itself) about 60 customers. So according to the numbers, for 70% of the IXes this will never fill up, so no need for renumbering. Depending on how quickly it filled up, you then go either for a /25 or a /24. To sum up: - if you start with a /26 ==> 30% has to renumber - if you start with a /29 ==> 75% has to renumber ---> more pain! Makes sense? best regards Wolfgang > Am 1. Nov 2022 um 15:48 schrieb Tore Anderson : > > If not, how exactly would a default > /29 policy ?cripple? an IX from growing past 6 members, or a default > /28 ?cripple? it from growing past 14 members for that matter? -- Wolfgang Tremmel Phone +49 69 1730902 0 | wolfgang.tremmel at de-cix.net Executive Directors: Ivaylo Ivanov and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net From farmer at umn.edu Tue Nov 1 18:51:16 2022 From: farmer at umn.edu (David Farmer) Date: Tue, 1 Nov 2022 12:51:16 -0500 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> Message-ID: On Tue, Nov 1, 2022 at 10:31 AM Wolfgang Tremmel < wolfgang.tremmel at de-cix.net> wrote: > No. But renumbering an IX is *pain*. A lot of pain. You want to avoid that > if possible. > A /26 allows (given that the IX uses about 2-4 IPs itself) about 60 > customers. > > So according to the numbers, for 70% of the IXes this will never fill up, > so no need for renumbering. > Depending on how quickly it filled up, you then go either for a /25 or a > /24. > > To sum up: > - if you start with a /26 ==> 30% has to renumber > - if you start with a /29 ==> 75% has to renumber ---> more pain! > I think maybe we want something in between; what do /27 and /28 look like? /29 could be forcing too much pain into the system, and /26 probably isn't enough pain in the system. Furthermore, /29 seems a little too small for a reasonable growth cycle before having to renumber. 50% fill of a /29 would be 3 of 6 usable addresses. Meaning many IXes could almost immediately qualify for a larger subnet, and they would have very much time to implement a renumbering process. Whereas with a /28, 50% fill would be 7 of 14 usable addresses. That seems like it would allow for reasonable growth before having to renumber and some runway to actually accomplish the renumbering process. Basically, a /29 is probably too small to be practical. Thanks > > Am 1. Nov 2022 um 15:48 schrieb Tore Anderson : > > > > If not, how exactly would a default > > /29 policy ?cripple? an IX from growing past 6 members, or a default > > /28 ?cripple? it from growing past 14 members for that matter? > > -- > Wolfgang Tremmel > > Phone +49 69 1730902 0 | wolfgang.tremmel at de-cix.net > Executive Directors: Ivaylo Ivanov and Sebastian Seifert | Trade Registry: > AG Cologne, HRB 51135 > DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | > Germany | www.de-cix.net > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://mailman.ripe.net/ > -- =============================================== 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 tore at fud.no Wed Nov 2 09:00:25 2022 From: tore at fud.no (Tore Anderson) Date: Wed, 02 Nov 2022 09:00:25 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> Message-ID: <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> * Wolfgang Tremmel > > No. But renumbering an IX is *pain*. A lot of pain. You want to > > avoid that if possible. > > A /26 allows (given that the IX uses about 2-4 IPs itself) about 60 > > customers. > > > > So according to the numbers, for 70% of the IXes this will never > > fill up, so no need for renumbering. > > Depending on how quickly it filled up, you then go either for a /25 > > or a /24. > > > > To sum up: > > - if you start with a /26 ==> 30% has to renumber > > - if you start with a /29 ==> 75% has to renumber ---> more pain! I do not think that insulating IX-es from possibly having to renumber when they double in size should be something this policy should aim to accomplish. (If it was, we could simply give everyone /22s or larger.) IPv4 is a limited and finite resource ? the goal should be to make it last. Looking at Matthias's graphs, for each new IX that is assigned a /26, there is an about 70% chance of that assignment being wastefully large. Making such assignments will inevitably result in other new IX-es being denied assignments, because there is nothing left, because the space those IX-es *could* have used was given to first IX ??even though the first IX had no need for it. So, all in all, I think that assigning IX-es the amount of space they *actually* need, but no more, and require them to renumber into a larger prefix whenever they double in size is a fair deal, when balanced against avoiding waste and preserving space for future IX-es (and existing growing IX-es for that matter). * David Farmer > I think maybe we want something in between; what?do /27 and /28 look > like? > > /29 could be forcing too much pain into the system, and /26 > probably?isn't enough pain in the system. > > Furthermore, /29 seems?a little too small for a reasonable growth > cycle before having to renumber. 50% fill of a /29 would be 3 of 6 > usable addresses. Meaning many IXes could almost immediately?qualify > for a larger subnet, and they would have very much time to implement > a renumbering process. The policy states that you get what you need to have a 50% utilisation one year from assignment. Thus, in order to get an initial /28 assignment and skip over a default /29, the IX would need to have a realistic plan to have eight members within a year of the founding of the IX (or possibly just six, if the NCC considers the network and broadcast addresses as ?utilised?). That is a *very* low bar to clear. But if IX cannot clear that low bar, I'd say they should not start out with a /28 (or larger) either. https://www.ripe.net/publications/docs/ripe-733#61 > Basically, a /29 is probably too small to be practical.? > Well, according to Mathias's report, 25% of all IX-es would manage just fine with a /29? By the way, last I checked there were a number of unassigned fragments smaller than /24 rotting away in the NCC's inventory, due to there being no policy that allowed for their assignment. IX-es are one of the very few places where those can be used, so they could be all added to the reserved IXP pool and actually do some good there. Tore From farmer at umn.edu Thu Nov 3 22:11:03 2022 From: farmer at umn.edu (David Farmer) Date: Thu, 3 Nov 2022 16:11:03 -0500 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> Message-ID: On Wed, Nov 2, 2022 at 3:00 AM Tore Anderson wrote: > * David Farmer > > > I think maybe we want something in between; what do /27 and /28 look > > like? > > > > /29 could be forcing too much pain into the system, and /26 > > probably isn't enough pain in the system. > > > > Furthermore, /29 seems a little too small for a reasonable growth > > cycle before having to renumber. 50% fill of a /29 would be 3 of 6 > > usable addresses. Meaning many IXes could almost immediately qualify > > for a larger subnet, and they would have very much time to implement > > a renumbering process. > > The policy states that you get what you need to have a 50% utilisation > one year from assignment. > > Thus, in order to get an initial /28 assignment and skip over a default > /29, the IX would need to have a realistic plan to have eight members > within a year of the founding of the IX (or possibly just six, if the > NCC considers the network and broadcast addresses as ?utilised?). > > That is a *very* low bar to clear. > > But if IX cannot clear that low bar, I'd say they should not start out > with a /28 (or larger) either. > > https://www.ripe.net/publications/docs/ripe-733#61 I think the need for a creative writing exercise should be avoided by starting with a /28 as the default, then being very skeptical of optimistic growth projections of unproven IXPs. > Basically, a /29 is probably too small to be practical. > > > > Well, according to Mathias's report, 25% of all IX-es would manage just > fine with a /29? > > By the way, last I checked there were a number of unassigned fragments > smaller than /24 rotting away in the NCC's inventory, due to there > being no policy that allowed for their assignment. IX-es are one of the > very few places where those can be used, so they could be all added to > the reserved IXP pool and actually do some good there. > > Tore > As I see it if an IXP has fewer than three(3) participants it really isn't an IXP. there seem to be quite a few IXPs with less than three(3) participants as required by policy. How is this requirement currently implemented? I would hope RIPE NCC requires at least a letter of intent from three(3) or more participants. So, if an IXP starts with three(3) participants, per policy, with a /29, it is already at 50% full, leaving 3 addresses for growth, and that doesn't include any infrastructure IP addresses, like a route server(s), etc... Therefore, starting at a /28 makes more sense to me. Forcing most IXPs to renumber almost right out of the gate doesn't make much sense to me. Furthermore, starting with a /28 will provide up to 16 times as many IXPs. Obviously, we won't get to that many more IXPs, but 4 or 5 times as many IXPs seems realistic to me. Many IXPs will succeed and grow, consuming more of the reserved pool, but that is a good thing. Finally, maybe there should be a maximum allocation size of /24. An IXP that is successful enough to need more than a /24 probably can afford to go to the marketplace for the additional IPv4 address space it needs. This reserved pool should be there to facilitate new IXPs and get them to a critical mass of suitability. Not to facilitate the growth of the largest IXPs. While the further growth of IXPs is important, once they get to a critical mass, they can probably fend for themselves in the marketplace without relying on a reserved pool. 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 wolfgang.tremmel at de-cix.net Fri Nov 4 10:08:46 2022 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Fri, 4 Nov 2022 09:08:46 +0000 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> Message-ID: If you want to change that you are invited to propose your own policy change. Past has shown that changing one single thing in a policy is way easier than to change a couple of things at once. > On 3. Nov 2022, at 22:11, David Farmer via address-policy-wg wrote: > > Finally, maybe there should be a maximum allocation size of /24. An IXP that is successful enough to need more than a /24 probably can afford to go to the marketplace for the additional IPv4 address space it needs. This reserved pool should be there to facilitate new IXPs and get them to a critical mass of suitability. Not to facilitate the growth of the largest IXPs. -- Wolfgang Tremmel Phone +49 69 1730902 0 | wolfgang.tremmel at de-cix.net Executive Directors: Ivaylo Ivanov and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net From tore at fud.no Fri Nov 4 10:56:14 2022 From: tore at fud.no (Tore Anderson) Date: Fri, 04 Nov 2022 10:56:14 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> Message-ID: * David Farmer > So, if an IXP starts with three(3)?participants, per policy, with a > /29, it is already at 50% full, leaving 3 addresses for growth, and > that doesn't include any infrastructure?IP addresses, like a route > server(s), etc... Exactly, a tiny IXP with three founding members would have enough space to double in size before needing to renumber out of an initial /29. For a slightly larger IXP with six founding members (or four founding members + two route servers and so on), the situation would be exactly the same - it would have enough space to double in size before needing to renumber out of an initial /28. And so on? (BTW: ?founding member??here means ?connects within the first year?) > Therefore, starting at a /28 makes more sense to?me. Forcing most > IXPs to renumber almost right out of the gate doesn't make much sense > to me. It seems that you assume here that all/most IXPs will grow out of an initial /29 and therefore require renumbering ?right out of the gate?. If that was the case, I would not suggest /29 as the default. However, Matthias's numbers seem to suggest otherwise, with plenty of IXPs (~25%) managing just fine with a /29. This does not surprise me all that much. If you set establish IXP in some rural location (in Longyearbyen, let's say), there is an almost zero percent chance there will be more than six members connecting in the foreseeable future because there are so few operators servicing that area. While AMS-IX, DE-CIX, LINX, Netnod and the like are probably what springs to mind when one says ?IX?, it would appear that behemoths like those are exceptionally rare and few in numbers compared to the small ones with just a handful of members, and I think it would be wise to keep that in mind when developing this policy further. Anyway, for the IXPs that *would* grow out of an /29, it's not like renumbering is *that* hard. Current policy grants 180 days to complete the renumbering, and when the IXP is just 4-5-6 members, it would even be doable to just gather everyone on a teleconference call and just do it all together. > Finally, maybe there should be a maximum allocation size of /24. Policy currently has a maximum limit of /22, for what it is worth. So even the behemoth IX-es with up to 1K members are catered to by this policy. I'm fine with that. Tore From farmer at umn.edu Fri Nov 4 21:16:54 2022 From: farmer at umn.edu (David Farmer) Date: Fri, 4 Nov 2022 15:16:54 -0500 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> Message-ID: On Fri, Nov 4, 2022 at 04:56 Tore Anderson wrote: > * David Farmer > > > So, if an IXP starts with three(3) participants, per policy, with a > > /29, it is already at 50% full, leaving 3 addresses for growth, and > > that doesn't include any infrastructure IP addresses, like a route > > server(s), etc... > > Exactly, a tiny IXP with three founding members would have enough space > to double in size before needing to renumber out of an initial /29. > > For a slightly larger IXP with six founding members (or four founding > members + two route servers and so on), the situation would be exactly > the same - it would have enough space to double in size before needing > to renumber out of an initial /28. > > And so on? > > (BTW: ?founding member? here means ?connects within the first year?) > > > Therefore, starting at a /28 makes more sense to me. Forcing most > > IXPs to renumber almost right out of the gate doesn't make much sense > > to me. > > It seems that you assume here that all/most IXPs will grow out of an > initial /29 and therefore require renumbering ?right out of the gate?. I did not say or even imply ?all.? I said "most," maybe a more descriptive quantifier would have been "majority." However, at 75%, "super-majority" is probably an even more accurate term. So, "most" still seems to be an appropriate quantifier in my opinion. Furthermore, looking at the graph on Matthias' GitHub site, even a /28 only covers 40% of IXPs; therefore even with a /28, the majority or most of IPXs, 60%, are still larger than that. You seem to want to optimize for the smallest of the small IXPs, tiny IXPs as you put it. How about we optimize for just plain small IXPs? If those tiniest IXPs, get 14 usable addresses instead of only 6, that doesn't seem like it's that much of a waste. We were giving those tiniest IXPs a /24 or 254 usable addresses until now. How stingy do we have to be? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Sat Nov 5 09:14:42 2022 From: tore at fud.no (Tore Anderson) Date: Sat, 05 Nov 2022 09:14:42 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> Message-ID: <8c242bb074d022d9316c136307896820af581cd2.camel@fud.no> * David Farmer > You seem to want to optimize for the smallest of the small IXPs, tiny > IXPs as you put it. How about we optimize for just plain small IXPs? No, what I want is to optimise equally for all sizes of IX-es. It is the current optimisation of (read: overassignment to) small IX-es I would like to see ended. In other words: an IX with X members should get the smallest /Y prefix that can fit X. That should go equally for any value of X. That is: ?if X=4, then Y=29. ?if X=40, then Y=26. ?if X=400, then Y=23. ?and so forth. If any IX wants to double in size, it would need to renumber exactly once. This would constitute totally fair and equal treatment for all IX-es regardless of size, the way I see it ? and it would be the the exact opposite of ?optimising for the smallest of the small IXPs?. > If those tiniest IXPs, get 14 usable addresses instead of only 6, > that doesn't seem like it's that much of a waste. I doubt the IXPs, that in the future will be denied any assignment whatsoever due to wasteful assignments causing the premature exhaustion of the IXP pool, will see it that way. > We were giving those tiniest IXPs a /24 or 254 usable addresses until > now. How stingy do we have to be? I think we can and should stop *all* waste at this point. We cannot expand the pool like we did in 2019-05, so to make the IXP pool last all we can do is to stop wasting space on IXPs that don't need it, and that does indeed include not giving /28s to IXPs that only need /29s. Giving out /24s by default was IMHO extremely short-sighted, and I did speak out against doing so in the past. I am not therefore not at all surprised that we find ourselves in this situation. Again. Tore From ripe-ml-2022 at ssd.axu.tm Mon Nov 7 11:23:28 2022 From: ripe-ml-2022 at ssd.axu.tm (Aleksi Suhonen) Date: Mon, 7 Nov 2022 12:23:28 +0200 Subject: [address-policy-wg] IXP pool lower boundary of assignments Message-ID: <4fb787ce-fa60-4f03-2bdc-980f8510a86b@ssd.axu.tm> Hello, I feel that /26 is the smallest reasonable subnet size for an IXP, no matter how small the IXP is initially. If it starts growing, it will quickly grow past /27, but might just stay inside the /26. This is based on empirical experience over the decades. I do agree that it would be nice if the vendors took RFC 5549 seriously. A lot of IXPs would be ready to adopt it, if it was an option. It will create some headaches for route server scalability, but perhaps bird3 will fix those... anyway I digress... My two cents, PS. I don't think Tore appreciates how much more difficult it is to renumber an IXP compared to a data centre or an access provider. -- Aleksi Suhonen / TREX () ascii ribbon campaign /\ support plain text e-mail From tore at fud.no Mon Nov 7 13:00:01 2022 From: tore at fud.no (Tore Anderson) Date: Mon, 07 Nov 2022 13:00:01 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <4fb787ce-fa60-4f03-2bdc-980f8510a86b@ssd.axu.tm> References: <4fb787ce-fa60-4f03-2bdc-980f8510a86b@ssd.axu.tm> Message-ID: * Aleksi Suhonen > I feel that /26 is the smallest reasonable subnet size for an IXP, no > matter how small the IXP is initially. If it starts growing, it will > quickly grow past /27, but might just stay inside the /26. This is > based on empirical experience over the decades. Could you please share the actual data on which your ?empirical experience? is founded with the list? Reason I am asking is that the only actual data that has been shared with the list so far is https://github.com/mwichtlh/address-policy-wg/, which appears to disagree with you. Looking at Figure 2 here, it would appear that ?~55% of all IXPs would fit into a /27 including 100% overprovisioning?. In other words, a majority of all IX-es would fit into a subnet smaller than your claimed ?smallest reasonable size? while having ample elbow room ? enough to at least double their current member count. > PS. I don't think Tore appreciates how much more difficult it is to > renumber an IXP compared to a data centre or an access provider. Actually, I do have some real-life experience here as I/AS39029 was part of the NIX renumbering process back in 2017. The whole operation was rather straight-forward and went very smoothly. NIX staff simply informed all members of their new IPs by e-mail and told to migrate within a certain date (different dates for NIX1 and NIX2). Most members opted to have both addresses simultaneously active during the migration period to facilitate hitless migration of traffic to the new addresses without needing to coordinate with each individual peer. NIX is (and was) a mid-sized IX, currently around 60 participants. Based on that experience I have honestly a very hard time believing that renumbering a small IX is ?much more difficult [than renumbering a] data centre or an access provider?. Tore From ripe-wgs at radu-adrian.feurdean.net Mon Nov 7 16:56:14 2022 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 07 Nov 2022 16:56:14 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <4fb787ce-fa60-4f03-2bdc-980f8510a86b@ssd.axu.tm> Message-ID: Hi, On Mon, Nov 7, 2022, at 13:00, Tore Anderson wrote: > Actually, I do have some real-life experience here as I/AS39029 was > part of the NIX renumbering process back in 2017. The whole operation > was rather straight-forward and went very smoothly. NIX staff simply > informed all members of their new IPs by e-mail and told to migrate > within a certain date (different dates for NIX1 and NIX2). Well, this seems to be the customer-side experience, not the IXP-side. Also, what I can see is that responsiveness of NOCs and peering teams of members is only getting worse with time. At France-IX, just changing a netmask (from /23 to /22) - because we have the biggest 3 out of 5 IXPs numbered from PA space - took just under 2 years to complete (23 months to be precise). More than 80% did the change in less than 3 months, but after 12 months we still had a few members that didn't change their config. OK, things end up in a slightly more violent manner with renumbering, but you sill end up with "zombie members", not all of them being small players. /29 is way too small. It's 6 members, and that supposes that you don't have route-servers or any other internal stuff on the peering LAN. Getting from /29 to /25 that's 4 renumberings, and that may well happen within 2 years. You end up being labelled as "unstable" (read "junk" or "toy" IXP). 3 renumberings to get to /26. > NIX is (and was) a mid-sized IX, currently around 60 participants. > Based on that experience I have honestly a very hard time believing > that renumbering a small IX is ?much more difficult [than renumbering > a] data centre or an access provider?. Convincing different distinct parties to do something within a specific timeframe is always difficult. Especially when you have to deal with big companies. Pushing things too hard will only get you losing members..... I do agree that /26 is a decent minimum, and /27 is the strictest acceptable minimum (if there really isn't anything bigger left). ... or getting rid of v4 entirely, which seems to be on nobody's agenda ... -- Radu-Adrian FEURDEAN From ripe at liopen.fr Mon Nov 7 17:18:29 2022 From: ripe at liopen.fr (Denis Fondras - Liopen) Date: Mon, 7 Nov 2022 17:18:29 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <4fb787ce-fa60-4f03-2bdc-980f8510a86b@ssd.axu.tm> Message-ID: Le Mon, Nov 07, 2022 at 04:56:14PM +0100, Radu-Adrian FEURDEAN a ?crit : > Hi, > > On Mon, Nov 7, 2022, at 13:00, Tore Anderson wrote: > > Actually, I do have some real-life experience here as I/AS39029 was > > part of the NIX renumbering process back in 2017. The whole operation > > was rather straight-forward and went very smoothly. NIX staff simply > > informed all members of their new IPs by e-mail and told to migrate > > within a certain date (different dates for NIX1 and NIX2). > > Well, this seems to be the customer-side experience, not the IXP-side. > Also, what I can see is that responsiveness of NOCs and peering teams of members is only getting worse with time. > At France-IX, just changing a netmask (from /23 to /22) - because we have the biggest 3 out of 5 IXPs numbered from PA space - took just under 2 years to complete (23 months to be precise). More than 80% did the change in less than 3 months, but after 12 months we still had a few members that didn't change their config. > OK, things end up in a slightly more violent manner with renumbering, but you sill end up with "zombie members", not all of them being small players. > > /29 is way too small. It's 6 members, and that supposes that you don't have route-servers or any other internal stuff on the peering LAN. Getting from /29 to /25 that's 4 renumberings, and that may well happen within 2 years. You end up being labelled as "unstable" (read "junk" or "toy" IXP). 3 renumberings to get to /26. > > > NIX is (and was) a mid-sized IX, currently around 60 participants. > > Based on that experience I have honestly a very hard time believing > > that renumbering a small IX is ?much more difficult [than renumbering > > a] data centre or an access provider?. > > Convincing different distinct parties to do something within a specific timeframe is always difficult. Especially when you have to deal with big companies. > Pushing things too hard will only get you losing members..... > I do agree that /26 is a decent minimum, and /27 is the strictest acceptable minimum (if there really isn't anything bigger left). > ... or getting rid of v4 entirely, which seems to be on nobody's agenda ... > Thank you very much for your message Radu-Adrian, I was about to send something along the same line :) -- Denis Fondras / Liopen / AuvernIX Mob: +33.761.029.186 From tore at fud.no Mon Nov 7 18:54:55 2022 From: tore at fud.no (Tore Anderson) Date: Mon, 07 Nov 2022 18:54:55 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <4fb787ce-fa60-4f03-2bdc-980f8510a86b@ssd.axu.tm> Message-ID: * Radu-Adrian FEURDEAN > On Mon, Nov 7, 2022, at 13:00, Tore Anderson wrote: > > Actually, I do have some real-life experience here as I/AS39029 was > > part of the NIX renumbering process back in 2017. The whole > > operation was rather straight-forward and went very smoothly. NIX > > staff simply informed all members of their new IPs by e-mail and > > told to migrate within a certain date (different dates for NIX1 and > > NIX2). > > Well, this seems to be the customer-side experience, not the IXP- > side. > Also, what I can see is that responsiveness of NOCs and peering teams > of members is only getting worse with time. > At France-IX, just changing a netmask (from /23 to /22) - because we > have the biggest 3 out of 5 IXPs numbered from PA space - took just > under 2 years to complete (23 months to be precise). More than 80% > did the change in less than 3 months, but after 12 months we still > had a few members that didn't change their config. > OK, things end up in a slightly more violent manner with renumbering, > but you sill end up with "zombie members", not all of them being > small players. First off, note current policy already requires renumbering if your IXP grows out of a /23 and into a /22. Second, current policy already contains a hard deadline of 180 days of complete this renumbering process and return the old prefix. Of course, neither the IX nor the RIPE NCC has the power to log into the router of a ?zombie member? and forcibly remove the old IP address from the ?zombie?'s router. But one cannot (well, should not!) allow unresponsive ?zombie? members to block the completion of the project. So in the case of NIX, a deadline was clearly communicated ahead of time and that was the end of the story. Perhaps there were ?zombies? that did not act within the deadline back then too, I can't recall, but if so they just got left behind at the platform (peering only amongst themselves using old addresses) while the train with all the ?non- zombies? left the station. Such is life. (Hopefully a majority of their peering sessions dropping brought them back to life, but who knows.) > /29 is way too small. It's 6 members, and that supposes that you > don't have route-servers or any other internal stuff on the peering > LAN. Getting from /29 to /25 that's 4 renumberings, and that may well > happen within 2 years. You end up being labelled as "unstable" (read > "junk" or "toy" IXP). 3 renumberings to get to /26. There would not be a requirement for four renumberings within two years, no. Policy states that: ?After one year, utilisation of the new assignment must be at least 50%?. In other words, a growing IX would need to renumber exactly ONCE within the first two years. So your example IX above would be eligible to receive an initial /26, and would be eligible to receive a /25 replacement one year prior to its expected utilisation reaching 64 addresses. It would make zero difference whatsoever to your example whether the default assignment size was set at /29 or /26 or anywhere in between. > > NIX is (and was) a mid-sized IX, currently around 60 participants. > > Based on that experience I have honestly a very hard time believing > > that renumbering a small IX is ?much more difficult [than renumbering > > a] data centre or an access provider?. > > Convincing different distinct parties to do something within a > specific timeframe is always difficult. Especially when you have to > deal with big companies. > Pushing things too hard will only get you losing members..... Well, the RIPE community has clearly laid down a renumbering deadline of 180 days as a condition for getting free prefixes from the IXP pool, this is already in the policy. If the operator of a new IX finds that adhering to this policy is ?pushing things too hard?, then perhaps it would be better if it got itself a vastly oversized prefix from somewhere else instead of from the RIPE NCC. That way, it can forever avoid having to renumber. > ... or getting rid of v4 entirely, which seems to be on nobody's > agenda ... Agreed. For what it is worth, we have for years advertised IPv4 prefixes across IPv6 BGP sessions in our internal networks. It works very well for us, so I see no real reason why it couldn't work on IXPs as well ? assuming universal vendor support. I suppose that is the problem? Tore From marcus at grmpf.org Mon Nov 7 23:48:42 2022 From: marcus at grmpf.org (Marcus Stoegbauer) Date: Mon, 07 Nov 2022 23:48:42 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <8c242bb074d022d9316c136307896820af581cd2.camel@fud.no> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> <8c242bb074d022d9316c136307896820af581cd2.camel@fud.no> Message-ID: <737C3F28-7DAF-4D7B-964C-E75FF086C81C@grmpf.org> On 5 Nov 2022, at 9:14, Tore Anderson wrote: > * David Farmer > >> You seem to want to optimize for the smallest of the small IXPs, tiny >> IXPs as you put it. How about we optimize for just plain small IXPs? > > No, what I want is to optimise equally for all sizes of IX-es. It is > the current optimisation of (read: overassignment to) small IX-es I > would like to see ended. > > In other words: an IX with X members should get the smallest /Y prefix > that can fit X. That should go equally for any value of X. That is: > > ?if X=4, then Y=29. > ?if X=40, then Y=26. > ?if X=400, then Y=23. > > ?and so forth. If any IX wants to double in size, it would need to > renumber exactly once. > > This would constitute totally fair and equal treatment for all IX-es > regardless of size, the way I see it ? and it would be the the exact > opposite of ?optimising for the smallest of the small IXPs?. In the case of IXPs I consider larger assignments up to a certain point as a technical necessity rather than a situation we need to rectify. Handing out /29s to a new IXP IMO puts a large burden on newly founded IXPs (since they would need to renumber earlier) which gives them an unfair disadvantage. This I consider a larger problem than eventually running out of addresses in the pool altogether. My counter argument is twofold: One, it's easier for an IXP to grow from 4 to 8 members than it is to grow from 40 to 80 members, so the likelihood that a very small IXP would need to renumber is larger than for already established IXPs with larger address space. Two, the numbers Matthias supplied are great and we can definitely get some information for this discussion from them. However, they are a snapshot in time. For the argument you are making we would need this data over time, and the question to ask would be "How long does an IXP which fits in a /29 stays in this category?". We cannot get this information from the data, so we shouldn't base assumptions and policy on this. Marcus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 858 bytes Desc: OpenPGP digital signature URL: From matthias.wichtlhuber at de-cix.net Tue Nov 8 09:46:15 2022 From: matthias.wichtlhuber at de-cix.net (Matthias Wichtlhuber) Date: Tue, 8 Nov 2022 08:46:15 +0000 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <737C3F28-7DAF-4D7B-964C-E75FF086C81C@grmpf.org> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> <8c242bb074d022d9316c136307896820af581cd2.camel@fud.no>, <737C3F28-7DAF-4D7B-964C-E75FF086C81C@grmpf.org> Message-ID: <6aa2ce7d1dd84458bace84026803ace4@de-cix.net> Hi Marcus, > Two, the numbers Matthias supplied are great and we can definitely get some information for this discussion from them. > However, they are a snapshot in time. For the argument you are making we would need this data over time, and the > question to ask would be "How long does an IXP which fits in a /29 stays in this category?". We cannot get this > information from the data, so we shouldn't base assumptions and policy on this. Thank you for pointing that out, Marcus. You are totally correct, the analysis does not tell you anything about how fast IXPs grow. Another limitation I would like to add: the data source is peeringDB and there is an unknown amount of ASes that do not add an entry to peeringDB if they join an IXP. Thus I would refrain from defining an extremely tight-knit policy based on this analysis. I don't get the point of the /29 discussion anyways. It is based on the false assumption that we need to stretch the pool to eternity and beyond. We need to stretch the pool until we can test and establish IPv4 over IPv6 peering LANs. A /26 default is perfectly fine for that. 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 Marcus Stoegbauer Gesendet: Montag, 7. November 2022 23:48:42 An: address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] IXP pool lower boundary of assignments On 5 Nov 2022, at 9:14, Tore Anderson wrote: > * David Farmer > >> You seem to want to optimize for the smallest of the small IXPs, tiny >> IXPs as you put it. How about we optimize for just plain small IXPs? > > No, what I want is to optimise equally for all sizes of IX-es. It is > the current optimisation of (read: overassignment to) small IX-es I > would like to see ended. > > In other words: an IX with X members should get the smallest /Y prefix > that can fit X. That should go equally for any value of X. That is: > > ?if X=4, then Y=29. > ?if X=40, then Y=26. > ?if X=400, then Y=23. > > ?and so forth. If any IX wants to double in size, it would need to > renumber exactly once. > > This would constitute totally fair and equal treatment for all IX-es > regardless of size, the way I see it ? and it would be the the exact > opposite of ?optimising for the smallest of the small IXPs?. In the case of IXPs I consider larger assignments up to a certain point as a technical necessity rather than a situation we need to rectify. Handing out /29s to a new IXP IMO puts a large burden on newly founded IXPs (since they would need to renumber earlier) which gives them an unfair disadvantage. This I consider a larger problem than eventually running out of addresses in the pool altogether. My counter argument is twofold: One, it's easier for an IXP to grow from 4 to 8 members than it is to grow from 40 to 80 members, so the likelihood that a very small IXP would need to renumber is larger than for already established IXPs with larger address space. Two, the numbers Matthias supplied are great and we can definitely get some information for this discussion from them. However, they are a snapshot in time. For the argument you are making we would need this data over time, and the question to ask would be "How long does an IXP which fits in a /29 stays in this category?". We cannot get this information from the data, so we shouldn't base assumptions and policy on this. Marcus From frettled at gmail.com Tue Nov 8 10:47:39 2022 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 8 Nov 2022 10:47:39 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <6aa2ce7d1dd84458bace84026803ace4@de-cix.net> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> <8c242bb074d022d9316c136307896820af581cd2.camel@fud.no> <737C3F28-7DAF-4D7B-964C-E75FF086C81C@grmpf.org> <6aa2ce7d1dd84458bace84026803ace4@de-cix.net> Message-ID: On Tue, Nov 8, 2022 at 9:46 AM Matthias Wichtlhuber < matthias.wichtlhuber at de-cix.net> wrote: > > I don't get the point of the /29 discussion anyways. It is based on the > false assumption that we need to stretch the pool to eternity and beyond. > We need to stretch the pool until we can test and establish IPv4 over IPv6 > peering LANs. A /26 default is perfectly fine for that. > What's preventing "us" from testing and establishing this right now? Is it a lack of impending doom? Also, another argument I feel is missing is that 100% overprovisioning seems to be perhaps reasonable at very small sizes, but unreasonable at greater sizes. Room for reasonable growth is not merely about percentages. Over two thirds of current IXPs given the actual growth from 2019 to 2022, fit within a /27 with *some* overprovisioning. Combined with the option to request a greater initial size, I'd argue that *if and only if* the point is to stretch this pool's lifespan, a /27 is both reasonably large as a minimum size, yet not too large. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Tue Nov 8 12:31:41 2022 From: tore at fud.no (Tore Anderson) Date: Tue, 08 Nov 2022 12:31:41 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <737C3F28-7DAF-4D7B-964C-E75FF086C81C@grmpf.org> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> <8c242bb074d022d9316c136307896820af581cd2.camel@fud.no> <737C3F28-7DAF-4D7B-964C-E75FF086C81C@grmpf.org> Message-ID: <5f1adbd29c1c576b6abf0f891cf8ee3a7c65c87a.camel@fud.no> * Marcus Stoegbauer > In the case of IXPs I consider larger assignments up to a certain > point as a technical necessity rather than a situation we need to > rectify. Handing out /29s to a new IXP IMO puts a large burden on > newly founded IXPs (since they would need to renumber earlier) which > gives them an unfair disadvantage. This I consider a larger problem > than eventually running out of addresses in the pool altogether. That's a fair position to have, and if it is indeed now the desire of the IXP community to continue overassigning to IX-es founded in the near future at the cost of not being able to assign anything to IX-es in the further future, then by all means, be my guest. I do note that this does seem somewhat at odds with the stated rationales of proposals 2011-05 and 2019-05, though. > My counter argument is twofold: > > One, it's easier for an IXP to grow from 4 to 8 members than it is to > grow from 40 to 80 members, so the likelihood that a very small IXP > would need to renumber is larger than for already established IXPs > with larger address space. Perhaps so, but do keep in mind that an IX that are expected to grow past 5 members within one year of its founding would not get a /29 to begin with, they would start out with an initial /28 (or bigger). > Two, the numbers Matthias supplied are great and we can definitely > get some information for this discussion from them. However, they are > a snapshot in time. For the argument you are making we would need > this data over time, and the question to ask would be "How long does > an IXP which fits in a /29 stays in this category?". We cannot get > this information from the data, so we shouldn't base assumptions and > policy on this. That is a valid point, and it would indeed be useful to know for how long, on average, an IX stays within a given bracket. However, both the current snapshot and the one back in 2019 showed that small IX-es are overrepresented, with the very smallest (?would fit into a /29 with 100% overprovisioning?) being the most populous bracket by a wide margin. I can think of only two explanations for this: One being that many small IX-es simply do not grow, or at least are growing very slowly, thus staying for a long time within a bracket. The other one is that the rate of new IX-es being founded is accelerating, in other words that the rate of new small IX-es showing up is exceed the rate of recently founded IX-es growing out of their initial brackets. Either way it seems like continuing a policy of overprovisioning would hasten the total exhaustion of the IX pool, which of course is to the detriment of any new IX-es appearing past that point in time. Matthias's report makes the following observation: ?the default policy of assigning /24s has created large amounts of unused space?, which is 100% true. I warned against exactly this against during the discussion of 2019-05, but nobody listened, and so here we are again. Anyway, dealing with this now by adjusting down the minimum assignment size to, say, /26 will not solve this fundamental issue that Matthias observed, we will still be overassigning space, just at a reduced rate. I predict that that if we go for a /26 this time, a few years from now we will end up in the exact same spot as we are today, looking to make further policy adjustments in order to further extend the lifetime of what remains of the IXP pool. Of course, space we will have wasted by overassigning /26s until then will not be reclaimable, just like the space we have already wasted by overassigning /24s until today is not. This wasted space is permanently ?stolen? from the future IX-es. If that is what the IX community wants, then go for it! I do hereby reserve the right to once again say ?I told you so?, though. ;-) Tore From tore at fud.no Tue Nov 8 12:52:48 2022 From: tore at fud.no (Tore Anderson) Date: Tue, 08 Nov 2022 12:52:48 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <6aa2ce7d1dd84458bace84026803ace4@de-cix.net> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> <8c242bb074d022d9316c136307896820af581cd2.camel@fud.no> , <737C3F28-7DAF-4D7B-964C-E75FF086C81C@grmpf.org> <6aa2ce7d1dd84458bace84026803ace4@de-cix.net> Message-ID: * Matthias Wichtlhuber > I don't get the point of the /29 discussion anyways. It is based on > the false assumption that we need to stretch the pool to eternity and > beyond. We need to stretch the pool until we can test and establish > IPv4 over IPv6 peering LANs. A /26 default is perfectly fine for > that. While I do hope you will be proven to be right about that, I am not so optimistic. The industry's track record on being able to migrate away from IPv4 to IPv6 before the exhaustion of the former is not great, to put it mildly. That even goes for the IXP pool specifically: In 2011, we thought a /16 with a default assignment size of /24 would suffice to ?safeguarding future IXPs with IPv4 space?. In 2019, we realised that was too optimistic, doubling the pool size to a /15, keeping the default /24. In 2022, we are again realising that we were too optimistic, leaving the pool size unchanged (for obvious reasons), but aiming to reduce the default size to /26. Perhaps third time's the charm. I do hope so, really, but again - not optimistic. George Santayana's observation comes to mind: ?those who cannot remember the past are condemned to repeat it?. Tore From will at lonap.net Tue Nov 8 14:48:15 2022 From: will at lonap.net (Will Hargrave) Date: Tue, 08 Nov 2022 13:48:15 +0000 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> <8c242bb074d022d9316c136307896820af581cd2.camel@fud.no> <737C3F28-7DAF-4D7B-964C-E75FF086C81C@grmpf.org> <6aa2ce7d1dd84458bace84026803ace4@de-cix.net> Message-ID: On 8 Nov 2022, at 11:52, Tore Anderson wrote: > While I do hope you will be proven to be right about that, I am not so > optimistic. The industry's track record on being able to migrate away > from IPv4 to IPv6 before the exhaustion of the former is not great, to > put it mildly. I am not sure that IXPs have actually tried to migrate away from IPv4. My working assumption has always been that members demand IPv4 addresses to peer with and this requirement would remain whilst we still have an IPv4 Internet. At present if you are a new IXP entrant it will be harder to attract members if you do things in an unusual fashion such as this. It would require change from the very largest operators. If we think router vendors are in a position to reliably support v4 AF over BGP in v6, and actually route this traffic, we should definitely look at it! I welcome thoughts on that (which will inevitably be out-of-scope for a-p-wg). The IXPs would also need to invest in some tooling and testing (e.g. route-server policy changes). > That even goes for the IXP pool specifically: > In 2011, we thought a /16 with a default assignment size of /24 would > suffice to ?safeguarding future IXPs with IPv4 space?. [?] I think this is more due to growth: decentralisation of interconnection away from the big IXs and closer to end-users, which is to be distinguished from growth of existing IXes. On the issue of assignment size, it does seem we can?t go on with assigning more /24s as the minimum. Not sure if there?s a land-grab going on but just today alone another four /24s were handed out to an operator for use in the Nordic region - with two /24s for Norway alone, a country whose largest IX at present contains under sixty AS. That seems wasteful. However I do agree with others that handing out subnets as small as /29s would seem to punish success at an early stage. I think Marcus has already covered that topic well. (Earlier, Tore wrote:) > By the way, last I checked there were a number of unassigned fragments > smaller than /24 rotting away in the NCC's inventory, due to there > being no policy that allowed for their assignment. IX-es are one of the > very few places where those can be used, so they could be all added to > the reserved IXP pool and actually do some good there. How much of this ?space dust? is available? (i.e is it worth the effort?) -- Will Hargrave Technical Director LONAP Ltd From nick at foobar.org Tue Nov 8 14:55:41 2022 From: nick at foobar.org (Nick Hilliard) Date: Tue, 8 Nov 2022 13:55:41 +0000 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> <8c242bb074d022d9316c136307896820af581cd2.camel@fud.no> <737C3F28-7DAF-4D7B-964C-E75FF086C81C@grmpf.org> <6aa2ce7d1dd84458bace84026803ace4@de-cix.net> Message-ID: <8c4cff74-15e5-4d64-ddca-ae05d218b39b@foobar.org> Will Hargrave wrote on 08/11/2022 13:48: > If we think router vendors are in a position to reliably support v4 > AF over BGP in v6, and actually route this traffic this is kinda the problem with RFC 5549, no? I.e. it deals only with signaling rather than transport. So even if it's deployed, the IXP will still need to provide ipv4 addresses for transport purposes. Nick From wolfgang.tremmel at de-cix.net Tue Nov 8 15:10:18 2022 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Tue, 8 Nov 2022 14:10:18 +0000 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <8c4cff74-15e5-4d64-ddca-ae05d218b39b@foobar.org> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> <8c242bb074d022d9316c136307896820af581cd2.camel@fud.no> <737C3F28-7DAF-4D7B-964C-E75FF086C81C@grmpf.org> <6aa2ce7d1dd84458bace84026803ace4@de-cix.net> <8c4cff74-15e5-4d64-ddca-ae05d218b39b@foobar.org> Message-ID: <00F7D847-4904-478B-BE9F-1855358BA550@de-cix.net> RFC5549 is obsolete. Replacement is RFC8950. The idea is that IPv4 prefixes can be advertised via BGP with an IPv6 next-hop address. So, if fully implemented on *all* IXP customers the IXP would not need an IPv4 prefix for the peering LAN any more. You can check yourself if your router implements this, on Cisco do a "show bgp neighbor", - "Extended Nexthop Encoding: advertised" means that your router supports it - "Extended Nexthop Encoding: advertised and received" means your router and your peer supports it best regards Wolfgang > On 8. Nov 2022, at 14:55, Nick Hilliard wrote: > > this is kinda the problem with RFC 5549, no? I.e. it deals only with signaling rather than transport. So even if it's deployed, the IXP will still need to provide ipv4 addresses for transport purposes -- Wolfgang Tremmel Phone +49 69 1730902 0 | wolfgang.tremmel at de-cix.net Executive Directors: Ivaylo Ivanov and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net From tore at fud.no Tue Nov 8 15:10:24 2022 From: tore at fud.no (Tore Anderson) Date: Tue, 08 Nov 2022 15:10:24 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <2ad247bd-d0e3-d68d-a753-0dccba40fc48@online.de> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> <8c242bb074d022d9316c136307896820af581cd2.camel@fud.no> <737C3F28-7DAF-4D7B-964C-E75FF086C81C@grmpf.org> <6aa2ce7d1dd84458bace84026803ace4@de-cix.net> Message-ID: * Will Hargrave > On the issue of assignment size, it does seem we can?t go on with > assigning more /24s as the minimum. Not sure if there?s a land-grab > going on but just today alone another four /24s were handed out to an > operator for use in the Nordic region - with two /24s for Norway > alone, a country whose largest IX at present contains under sixty AS. > That seems wasteful. Being quite familiar with the Norwegian networking community I can assure you that this does indeed seem very wasteful (and so would /26s have been). > (Earlier, Tore wrote:) > > By the way, last I checked there were a number of unassigned > > fragments smaller than /24 rotting away in the NCC's inventory, due > > to there being no policy that allowed for their assignment. IX-es > > are one of the very few places where those can be used, so they > > could be all added to the reserved IXP pool and actually do some > > good there. > > How much of this ?space dust? is available? (i.e is it worth the > effort?) Currently about four thousand addresses, if I'm not mistaken: $ awk '-F|' '$2 == "" && $3 == "ipv4" && $5 < 256 {print; SUM += $5} END {print SUM}' < delegated-ripencc-extended-latest ripencc||ipv4|193.34.196.128|128||reserved ripencc||ipv4|193.34.199.128|128||reserved ripencc||ipv4|193.58.0.48|8||reserved ripencc||ipv4|193.164.232.96|64||reserved ripencc||ipv4|193.164.232.224|32||reserved ripencc||ipv4|193.188.134.128|16||reserved ripencc||ipv4|193.188.134.200|56||reserved ripencc||ipv4|193.192.12.0|128||reserved ripencc||ipv4|193.201.145.128|128||reserved ripencc||ipv4|193.201.147.96|32||reserved ripencc||ipv4|193.201.147.192|32||reserved ripencc||ipv4|193.201.148.128|64||reserved ripencc||ipv4|193.201.149.0|64||reserved ripencc||ipv4|193.201.149.128|64||reserved ripencc||ipv4|193.201.150.192|64||reserved ripencc||ipv4|193.201.151.64|128||reserved ripencc||ipv4|193.201.155.0|128||reserved ripencc||ipv4|193.201.157.128|128||reserved ripencc||ipv4|193.201.159.0|128||reserved ripencc||ipv4|193.218.205.224|32||reserved ripencc||ipv4|193.218.207.64|16||reserved ripencc||ipv4|193.243.183.0|64||reserved ripencc||ipv4|193.243.183.128|64||reserved ripencc||ipv4|194.42.47.0|128||reserved ripencc||ipv4|194.93.123.0|128||reserved ripencc||ipv4|194.117.50.0|128||reserved ripencc||ipv4|194.117.55.0|128||reserved ripencc||ipv4|194.153.153.0|128||reserved ripencc||ipv4|194.153.157.0|128||reserved ripencc||ipv4|194.153.157.160|32||reserved ripencc||ipv4|194.153.158.0|128||reserved ripencc||ipv4|194.153.159.128|128||reserved ripencc||ipv4|194.180.226.0|152||reserved ripencc||ipv4|194.180.226.160|96||reserved ripencc||ipv4|194.246.39.0|96||reserved ripencc||ipv4|194.246.39.192|32||reserved ripencc||ipv4|195.13.37.128|128||reserved ripencc||ipv4|195.35.104.0|32||reserved ripencc||ipv4|195.60.80.0|96||reserved ripencc||ipv4|195.60.81.128|64||reserved ripencc||ipv4|195.60.83.0|64||reserved ripencc||ipv4|195.60.83.128|32||reserved ripencc||ipv4|195.60.84.128|128||reserved ripencc||ipv4|195.60.85.128|128||reserved ripencc||ipv4|195.60.91.128|128||reserved ripencc||ipv4|195.60.92.192|64||reserved ripencc||ipv4|195.60.93.64|64||reserved 4056 Tore From tore at fud.no Tue Nov 8 15:18:32 2022 From: tore at fud.no (Tore Anderson) Date: Tue, 08 Nov 2022 15:18:32 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <8c4cff74-15e5-4d64-ddca-ae05d218b39b@foobar.org> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> <8c242bb074d022d9316c136307896820af581cd2.camel@fud.no> <737C3F28-7DAF-4D7B-964C-E75FF086C81C@grmpf.org> <6aa2ce7d1dd84458bace84026803ace4@de-cix.net> <8c4cff74-15e5-4d64-ddca-ae05d218b39b@foobar.org> Message-ID: <04a17a757ded0682ac15ffce99264c51d9ac9b3e.camel@fud.no> * Nick Hilliard > this is kinda the problem with RFC 5549, no?? I.e. it deals only with > signaling rather than transport. So even if it's deployed, the IXP > will still need to provide ipv4 addresses for transport purposes. Apart from the BGP session itself (which supports multi-AF), the addresses are just needed for resolution of the next-hop layer-2 address. There's no real reason that address needs to be IPv4 and resolved via ARP, it can be resolved just as well with IPv6 ND, as I understand it. For example, on Linux, you can program the FIB in this way: $ ip route add 192.0.2.0/24 via inet6 fe80::1 dev eth0 The 'eth0' interface does not need any IPv4 addresses assigned. Obviously the major router vendors need to build in corresponding capability in their BGP software for IPv6-only IX-es to be a realistic proposition. I have no idea if they have. Tore From arnold.nipper at de-cix.net Tue Nov 8 15:25:24 2022 From: arnold.nipper at de-cix.net (Arnold Nipper) Date: Tue, 8 Nov 2022 15:25:24 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <8c4cff74-15e5-4d64-ddca-ae05d218b39b@foobar.org> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> <8c242bb074d022d9316c136307896820af581cd2.camel@fud.no> <737C3F28-7DAF-4D7B-964C-E75FF086C81C@grmpf.org> <6aa2ce7d1dd84458bace84026803ace4@de-cix.net> <8c4cff74-15e5-4d64-ddca-ae05d218b39b@foobar.org> Message-ID: <296eb405-d3e9-460f-1531-cd192c20215e@de-cix.net> On 08.11.2022 14:55, Nick Hilliard wrote: > Will Hargrave wrote on 08/11/2022 13:48: >> If we think router vendors are in a position to reliably support v4 >> AF over BGP in v6, and actually route this traffic > > this is kinda the problem with RFC 5549, no?? I.e. it deals only with > signaling rather than transport. So even if it's deployed, the IXP will > still need to provide ipv4 addresses for transport purposes. > IMO no. RFC 8950 [0] says ----------------- snip ----------------- 6. Usage Examples 6.1. IPv4 over IPv6 Core The extensions defined in this document may be used as discussed in [RFC5565] for the interconnection of IPv4 islands over an IPv6 backbone. In this application, Address Family Border Routers (AFBRs; as defined in [RFC4925]) advertise IPv4 NLRI in the MP_REACH_NLRI along with an IPv6 next hop ----------------- snap ----------------- The IPv6 backbone is the IXP. All of the participants only must have an IPv6 address. And we have plenty of them. IMO Euro-IX (or IX-F) should set up a WG to look into this. Arnold [0] https://datatracker.ietf.org/doc/rfc8950/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From nick at foobar.org Tue Nov 8 17:38:52 2022 From: nick at foobar.org (Nick Hilliard) Date: Tue, 8 Nov 2022 16:38:52 +0000 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <04a17a757ded0682ac15ffce99264c51d9ac9b3e.camel@fud.no> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> <8c242bb074d022d9316c136307896820af581cd2.camel@fud.no> <737C3F28-7DAF-4D7B-964C-E75FF086C81C@grmpf.org> <6aa2ce7d1dd84458bace84026803ace4@de-cix.net> <8c4cff74-15e5-4d64-ddca-ae05d218b39b@foobar.org> <04a17a757ded0682ac15ffce99264c51d9ac9b3e.camel@fud.no> Message-ID: Tore Anderson wrote on 08/11/2022 14:18: > Apart from the BGP session itself (which supports multi-AF), the > addresses are just needed for resolution of the next-hop layer-2 > address. There's no real reason that address needs to be IPv4 and > resolved via ARP, it can be resolved just as well with IPv6 ND, as I > understand it. > > For example, on Linux, you can program the FIB in this way: > > $ ip route add 192.0.2.0/24 via inet6 fe80::1 dev eth0 > > The 'eth0' interface does not need any IPv4 addresses assigned. Right, ipv4 forwarding using ipv6 next hop resolution. Wow, that's ugly and likely to introduce an entirely new class of low-level forwarding bugs. > Obviously the major router vendors need to build in corresponding > capability in their BGP software for IPv6-only IX-es to be a realistic > proposition. I have no idea if they have. In fairness, this goes well beyond updating a set of capabilities in vendor BGP stacks. Nick From gert at space.net Tue Nov 8 18:12:53 2022 From: gert at space.net (Gert Doering) Date: Tue, 8 Nov 2022 18:12:53 +0100 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: References: <8c242bb074d022d9316c136307896820af581cd2.camel@fud.no> <737C3F28-7DAF-4D7B-964C-E75FF086C81C@grmpf.org> <6aa2ce7d1dd84458bace84026803ace4@de-cix.net> <8c4cff74-15e5-4d64-ddca-ae05d218b39b@foobar.org> <04a17a757ded0682ac15ffce99264c51d9ac9b3e.camel@fud.no> Message-ID: Hi, On Tue, Nov 08, 2022 at 04:38:52PM +0000, Nick Hilliard wrote: > > For example, on Linux, you can program the FIB in this way: > > > > $ ip route add 192.0.2.0/24 via inet6 fe80::1 dev eth0 > > > > The 'eth0' interface does not need any IPv4 addresses assigned. > > Right, ipv4 forwarding using ipv6 next hop resolution. Wow, that's ugly > and likely to introduce an entirely new class of low-level forwarding bugs. Cloud folks want this anyway, for configuring eBGP peers over link-local on p2p ethernets ("neighbour eth3 remote-as 12345"). Quite a few vendors can do this already. It's not that hard, actually, if the FIB is built "with L2 next-hop info right in the data structure" - when populating the FIB, you either do ARP or ND lookups, store the NH MAC + oif, done. Of course, getting support for this in my trusty 6500 won't be easy... (but vendor willing, even that one could learn to do it - this is pure control plane, and data plane punt if no L2 NH is known) Yeah. Multi-decade journey... 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 farmer at umn.edu Tue Nov 8 19:01:13 2022 From: farmer at umn.edu (David Farmer) Date: Tue, 8 Nov 2022 12:01:13 -0600 Subject: [address-policy-wg] IXP pool lower boundary of assignments In-Reply-To: <8c4cff74-15e5-4d64-ddca-ae05d218b39b@foobar.org> References: <1d539f87c83d4fbfb16f47f59c214ff0@de-cix.net> <1e47be646d2d455e91ea8057b8d4d960@de-cix.net> <61fe5eac7edfaef0076456fc3a9ae65a8f7ea029.camel@fud.no> <7b5f743937f7472fa08a361225fd0427@de-cix.net> <0945d0799797cb0fe03991f337e6b81d3d4adbbd.camel@fud.no> <10EC7BB6-A787-4631-85F5-FA0F3B20FD16@de-cix.net> <1443c0d1c02ca866b260e070b8f9eb3d71e16742.camel@fud.no> <8c242bb074d022d9316c136307896820af581cd2.camel@fud.no> <737C3F28-7DAF-4D7B-964C-E75FF086C81C@grmpf.org> <6aa2ce7d1dd84458bace84026803ace4@de-cix.net> <8c4cff74-15e5-4d64-ddca-ae05d218b39b@foobar.org> Message-ID: Actually you want RFC 8950. https://datatracker.ietf.org/doc/html/rfc8950 On Tue, Nov 8, 2022 at 07:55 Nick Hilliard wrote: > Will Hargrave wrote on 08/11/2022 13:48: > > If we think router vendors are in a position to reliably support v4 > > AF over BGP in v6, and actually route this traffic > this is kinda the problem with RFC 5549, no? I.e. it deals only with > signaling rather than transport. So even if it's deployed, the IXP will > still need to provide ipv4 addresses for transport purposes. > > Nick > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://mailman.ripe.net/ > -- =============================================== 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 mschmidt at ripe.net Fri Nov 11 08:29:46 2022 From: mschmidt at ripe.net (Marco Schmidt) Date: Fri, 11 Nov 2022 08:29:46 +0100 Subject: [address-policy-wg] IPv6 Allocation to the RIPE NCC Message-ID: Dear colleagues, The RIPE NCC Arbiters Panel has approved a request for an IPv6 allocation to the RIPE NCC for its internal network based on the RIPE Document ripe-635, "Allocating/Assigning Resources to the RIPE NCC", and the RIPE NCC Document ripe-738, ?IPv6 Address Allocation and Assignment Policy?. You can find the full announcement at: https://www.ripe.net/publications/news/about-ripe-ncc-and-ripe/ipv6-allocation-to-the-ripe-ncc If you have any questions, please send us a message at . Kind regards, Marco Schmidt Manager Registration Services RIPE NCC From edwin.verheul at surf.nl Thu Nov 17 16:23:28 2022 From: edwin.verheul at surf.nl (Edwin Verheul) Date: Thu, 17 Nov 2022 15:23:28 +0000 Subject: [address-policy-wg] Minimum size for IPv4 temporary assignments Message-ID: Dear colleagues of the Address Policy Working Group, During (my first!) RIPE85 there was short discussion about the minimal size for IPv4 temporary assignments in this workgroup. The policy for temporary IPv4 assignments requires you to use 50% of the assigned addresses [1]. This requirement pushes events or experiments into smaller assignments less than /24?s, which are mostly unroutable on the internet. This is mentioned before by Marco Schmidt [2] in October 2022 and Randy Bush [3] in Januari 2022. It looks to me this is a legitimate reason to propose this in a policy change: * Temporary IPv4 assignments ? /24 should NOT subject to the 50% usage requirement; * Only smaller assignments will be handed out if the assignee is explicitly willing to have (sub optimal) unroutable IP space on the internet; * If it is required by the assignee to advertise multiple subnets, the policy should allow to assign multiple /24?s( or a bigger assignment, so the assignee can split and advertise by themselves). Elvis Velea and myself are willing to (co) author this proposal. We will do our best to hand in the proposal by the end of this year. Any thoughts on this? Kind regards, Edwin Verheul SURF AS1103 [1] https://www.ripe.net/publications/docs/ripe-587#utilisation-rates [2] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2022-October/013598.html [3] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2022-January/013438.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at bais.name Thu Nov 24 15:50:02 2022 From: erik at bais.name (Erik Bais) Date: Thu, 24 Nov 2022 14:50:02 +0000 Subject: [address-policy-wg] Minimum size for IPv4 temporary assignments Message-ID: <814B066C-5A5B-40E2-A47A-20E34DFDA6AE@bais.name> Hi Edwin, Thank you on stepping forward on this. And I think that it would make sense to have a discussion on this with a policy proposal on the table. As you mentioned, this has been brought up multiple times already, so it would be good to see if we can get this sorted. It would be nice if the AP-WG members could provide some insight if the would support (or not) a policy proposal as suggested. Regards, Speaking as one of the Co-Chairs, Erik Bais From: address-policy-wg on behalf of Edwin Verheul Date: Thursday, 17 November 2022 at 16:24 To: "address-policy-wg at ripe.net" Subject: [address-policy-wg] Minimum size for IPv4 temporary assignments Dear colleagues of the Address Policy Working Group, During (my first!) RIPE85 there was short discussion about the minimal size for IPv4 temporary assignments in this workgroup. The policy for temporary IPv4 assignments requires you to use 50% of the assigned addresses [1]. This requirement pushes events or experiments into smaller assignments less than /24?s, which are mostly unroutable on the internet. This is mentioned before by Marco Schmidt [2] in October 2022 and Randy Bush [3] in Januari 2022. It looks to me this is a legitimate reason to propose this in a policy change: * Temporary IPv4 assignments ? /24 should NOT subject to the 50% usage requirement; * Only smaller assignments will be handed out if the assignee is explicitly willing to have (sub optimal) unroutable IP space on the internet; * If it is required by the assignee to advertise multiple subnets, the policy should allow to assign multiple /24?s( or a bigger assignment, so the assignee can split and advertise by themselves). Elvis Velea and myself are willing to (co) author this proposal. We will do our best to hand in the proposal by the end of this year. Any thoughts on this? Kind regards, Edwin Verheul SURF AS1103 [1] https://www.ripe.net/publications/docs/ripe-587#utilisation-rates [2] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2022-October/013598.html [3] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2022-January/013438.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at vegoda.org Mon Nov 28 22:51:00 2022 From: leo at vegoda.org (Leo Vegoda) Date: Mon, 28 Nov 2022 13:51:00 -0800 Subject: [address-policy-wg] Draft Address Policy WG Minutes from RIPE 85 Message-ID: Dear WG, The RIPE NCC has now prepared draft minutes of our session at RIPE 85. Please write to this list or inform the co-chairs of any issues or corrections. Kind regards, Leo Vegoda for the Address Policy WG co-chairs RIPE 85 Address Policy WG Minutes Wednesday, 26 October 2022, 09:00-10:00 UTC+1 Chairs: Erik Bais, James Kennedy, Leo Vegoda Scribe: Antony Gollan Status: Draft A. Introduction The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/64-RIPE-85-Address-Policy.pdf The video is available at: https://ripe85.ripe.net/archives/video/898/ There were no changes to the agenda. The minutes from RIPE 84 were approved without changes. B. ASO AC Update James Kennedy, ASO AC The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/72-ASO-AC-Report-RIPE85.pdf The video is available at: https://ripe85.ripe.net/archives/video/901/ James Kennedy gave an update from the ASO AC. Kevin Blumberg from the ARIN region was their new Chair. Kevin had appointed Mike Silber (AFRINIC) and Herve Clement (RIPE) as Vice Chairs. There were no questions. C. Policy Update Followed by Q&A Angela Dall'Ara, RIPE NCC The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/59-RIPE-85-Current-Policy-Topics.pdf The video is available at: https://ripe85.ripe.net/archives/video/902/ Angela ran through open policies in the five RIR service regions. In the RIPE region, there were two: 2022-01: Personal Data in the RIPE Database (Database WG) and 2022-02: Remove mandatory IPv4 PA assignment registration in the RIPE Database (Address Policy WG). Jordi Palet Martinez (online), Moremar, noted all of the APNIC proposals would get a new version soon. D. (2022-02) Remove Mandatory IPv4 PA Assignment Registration in the RIPE Database James Kennedy, Address Policy WG co-chair The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/73-2022-02.pdf The video is available at: https://ripe85.ripe.net/archives/video/905/ James said that the proposer (Jeroen Lauwers) could not be at the meeting and so he would run through the proposal quickly for him. He added that he would be recusing himself as WG co-chair from determining consensus on this proposal. James?s interpretation of the intent of the policy was that it sought to allow LIRs to document only information in the RIPE Database that was needed for operational and administrative purposes, and to reduce workload by not forcing them to maintain duplicate data. Sander Steffann, 6connect, said he agreed that everything visible externally should be documented in the RIPE Database. That was an absolute minimum. However, he thought they already had this ? if it was externally visible there would be a ROUTE object, in which case there would have to be an INETNUM object it pointed to. Erik Bais, Address Policy WG co-chair, said for the allocation there was not. Sander said then he would definitely put that in as a minimum requirement. For the rest, it was a contact database ? so that if something went wrong, people could see who to contact and who was responsible. If the LIR was willingly taking responsibility to be the contact for all its customers, that was a business decision, and they should allow for that. Kurt Kayser (online), speaking on his own behalf, asked if the logic was correct that routed = used, and that it if was not assigned, it was not shown as used. Erik said this played into the comment from Sander. When were they going to say the address space was in use? Was it when there was a valid ROUTE object or when there was a valid assignment? James said, on that point, maybe the ROUTE object was created before being used. But a quarter of all allocations was an interesting number. Elvis Daniel Velea (online), v6escrow, said he supported the intent of the proposal. Assignments should only be registered if required by the End User or if the LIR wanted to delegate some administrative/abuse/routing decisions. Peter Koch, DENIC, said he had been a member of the RIPE Database Requirements Task Force. The TF report made a distinction between the RIPE Database and the RIPE Registry. He thought the differences and commonalities here weren?t reflected in the proposal in a way that would help with making a decision. Further, while the author pointed towards the TF report and its recommendations, he didn?t think the proposal reflected the corresponding recommendation. That was fine, because it didn?t have to, but he wanted to avoid the impression that this was a proposal to implement what the TF recommended. It did make a recommendation on the assignments, following the observation of an asymmetry in terms of depth and volume of usage by various LIRs and, as someone had said on the mailing list, maybe a policy wasn?t the way to change that. Peter made a further observation. The RIPE Chair Team had, after consultation and with the community?s support, offered clarification to the PDP. That clarification had strongly suggested that policy proposals should be the result of in-depth discussion. This proposal seemed to come out of the blue, and so he would urge the chairs to think about their gatekeeping and steering function. Finally, Peter didn?t think this proposal was getting anywhere. Unfortunately, the PDP?s was biased towards stumbling forward, and so he would suggest putting an end to the proposal and considering the problems identified in the subsequent discussion. Erik noted that the intent for creating the proposal was discussed at RIPE 84 in Berlin and the proposal was only created later. Peter said that since Berlin there had been little discussion on the list that would support the general direction of the proposal and the problem statement that needed to be fixed. A couple of people had mentioned their own surprise at seeing the proposal and two or three had said it did not seem to be addressing the problem it sought to fix. James said he thought the proposer had tried to get as much feedback as possible at RIPE 84, but he took Erik?s point that it could have been progressed further on the mailing list. James added that he had been on the Database Requirements TF with Peter and their recommendation had inspired this proposal, but it was definitely not one-to-one. Brian Storey (online), Gamma, asked if the intent of the proposal was to no longer require the registration of any downstream End User PA assignments. James said he could only give his own interpretation. The current policy text said that for any assignments it should be optional. But from the feedback Jeroen had received over the past few weeks, and from his discussions with him, he was taking that into account. So, the intent seemed to have changed since then. Erik said as chairs they had looked at all the comments on the mailing list. If this was moving forward, they would need to have a discussion with Jeroen about whether it was for all assignments or just for the resource holder of the allocation, which would probably make more sense. Kurt said he would split the main purpose of the documentation between customer data (mainly assignments) and network operator related data (such as abuse-c and admin-c). RIPE NCC needed both datasets before but now the (very sensitive GDPR-Data) purposes may allow a different handling. Erik said this was not a GDPR topic. Yes, they were trying to minimise the duplication of data. If the assignments were the same information as the resource holder, then they shouldn?t need to duplicate it. But if you were adding different information with different parties and contacts, then that should still be in the database. At least that was how he read it. Erik and James encouraged people to share their opinions on the mailing list. E. Registry Services Update Followed by Q&A Marco Schmidt, RIPE NCC The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/66-RIPE85-Feeback-from-RS.pdf The recording is available at: https://ripe85.ripe.net/archives/video/907/ Marco gave an update from the RIPE NCC?s Registry Services Department. He had three topics he wanted feedback on: 1. IPv4 Waiting List: they now had about 1,050 LIRs on the waiting list and the estimated wait time was now about two years. There were still multiple-LIRs being created, which disadvantaged newcomers. He asked if the WG wanted to accept this or if they should try to fix it. 2. IPv4 IXP Pool: the addition of a further /16 to the pool for IPv4 IXP assignments had drastically extended its lifetime. They expected this pool to become empty around 2029. He asked if that was enough. 3. Assignment Definition: the policy referred to assignments made to ?downstream networks? but later referred to ?End Users?. He asked if these terms needed further definition by the WG. Shane Kerr, NS1, responded to the question about the IXP pool. This policy had been created so that IXPs wouldn?t have to go to an LIR. Now that they were out of space, he asked why they wouldn?t buy address space like anyone else. Marco said he thought this was about seeing IXPs as critical infrastructure. Shane said everyone thought their own infrastructure was critical. Sander said he?d been around since the beginning of the run-out policies. The fact that they still had some IPv4, even with a waiting list of two years, was an achievement which meant their policies had worked well. By now, they had extended this for so many years and given people many opportunities, but at a certain point they needed to say that they had properly arranged the deck chairs on the Titanic. Regarding IXPs, Sander thought they did have an important role and they should keep a separate pool for that. Maybe they could have a policy that used some of the recovered IPv4 space to top up the pool when it reached a certain level. He suggested they try a proposal that would allow the RIPE NCC to manage this without an intervention from the WG every time. Erik said they would need input from the Connect WG on this policy, and how it saw the prospect of this pool running out in seven years. Sander said he would attend the Connect WG session later that day and raise the topic there. Regarding the definition of assignments, Sander said he could vaguely remember this being discussed a long time ago; they had tried to keep it vague since there were many ways of providing a service to a customer. They had intentionally avoided going into what that service could be, as they would be stuck chasing reality. They did put in that there had to be some relation, and so he thought the RIPE NCC could be a bit stricter, but that would require a very long policy process to define what that meant. Elvis (online), suggested they not get into the leasing discussion. Since forever, LIRs in the RIPE region had assigned either PA or PI to connecting customers or customers that offered all kind of services and the colors of the IPs hadn?t really mattered. Denis Walker, Database WG co-chair, said he had a comment on leasing. What they had now was a situation where someone with spare address space was asking third-party companies to lease it out on their behalf, which might go to an LIR that saw it more as an allocation and assigned it to an End User. None of this could be reflected in the RIPE Database, because this whole structure that was hidden from view. If they were going to allow leasing, they should document it properly. Riccardo Gori, IP4WISP, wanted to go into the definition of LIR. He interpreted this as ?Local Internet Registry? in the same way as an RIR was a regional registry. He didn?t find a strict relation between the LIR and the services that were operated. Often the resources were associated to access offered by an operator to an Internet Service Provider or in a data centre. So, he didn?t see much need to go deeper into the definition of an LIR because it should reflect the fact that, as the comment before said, it should give the right description in the RIPE Database where the resources were being used and who was using them. If this was consistent and correct, then in his opinion it was done. End of first session. F. IPv6 Policy Goals - Review Process (Community Input Sought) [15 minutes] Leo Vegoda, Address Policy WG co-chair The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/81-IPv6_at_RIPE-85.pdf The recording is available at: https://ripe85.ripe.net/archives/video/910/ Leo noted that they?d started a discussion at RIPE 84 to look at the goals of the IPv6 policy, which hadn?t been reviewed for many years. He asked if they wanted to adjust the policy goals, change their order of priority, or introduce new ones. Erik said there had been a lot of updates on this topic since RIPE 84. That didn?t mean that the issues raised were gone. He?d also had a discussion with a Dutch ISP that had quite some issues, because they actually planned to do IPv6 with /48s to their customers, but instead they had to refer back to /56s because they couldn?t get the documentation within a reasonable time period. This meant they had to move ahead with a /29 instead of a /25 or /27. Sander said he was part of the group that discussed all these IPv6 changes and the main thing was a steep jump in requirements and in terms of documentation they needed a full-sized novel. He asked if the RIPE NCC was still reserving three bits of adjacent address space for future growth. Marco confirmed that they were. Sander said he had heard concerns from organisations that they would have to come back and get de-aggregated blocks when they needed to grow later. So this might help to address some of their concerns. This wasn?t in the policy and was an implementation detail ? so maybe to alleviate some of this stress the RIPE NCC could make this a bit more official and tell people that they had a reservation for when they came back in the future. Marco confirmed that they could extend all the way to a /26. Erik said this meant they could take a gradual approach and they could grow into their space. Sander said there was a three-bit reservation. There was an issue with older allocations, as they would be able to extend from a /32 to a /29 as opposed to others who could grow from a /29 to a /27. There might also be the issue of LIRs who opted for a /32 rather than a /29 and unknowingly limited themselves in the future. Leo asked what kind of planning horizon was reasonable from the perspective of a network operator in terms of growing to a larger allocation. He also asked to hear from the RIPE NCC, as they were the ones who would have to go back to IANA if they needed more address space. Sander said currently there was no official planning horizon and the implementation detail was that there was a planning horizon of three bits ? so someone could grow up to eight times as large. He didn?t want to micromanage the RIPE NCC ? maybe they needed to put this in policy or maybe they just needed to inform people what the current operational procedure of the RIPE NCC was. Erik said maybe the LIR could have some kind of first right of refusal ? so they could give the RIPE NCC notice that they were intending to grow in the next three to five years so that the additional bits were not consumed. This could be a lightweight way to do it. Sander asked if this was more of an informational hint rather than a guarantee. Erik said they would still need to do the documentation part. Sander said his first preference would be to round allocation sizes to nibble boundaries. Erik said they couldn?t always, especially if they were running out and would have to go back to IANA and ask for additional allocations ? IANA would ask why. Leo said, from memory, one of the things in the global policy was that reservations were considered use. But that didn?t mean they shouldn?t manage things responsibly. Marco Schmidt, RIPE NCC, said he wanted to confirm for the record that they reserved an additional three bits for every IPv6 allocation. This meant someone with a /29 had a reservation up to a /26, for a /26 up to a /23 and so on. There were a few exceptions, for example historical allocations of a /32 that were extended to a /29 and couldn?t go further, and sometimes those who transferred their allocations were unable to extend, but that was just a sidenote. This approach had been used for a long time and it worked well. They could do more to make sure that people were aware. They did things on a case-by-case basis and sometimes would tell people that they might start with a /29 so they could expand later if they needed to. They could do this in a more consistent and formal way. They weren?t too concerned about going back to IANA ? the /12s they currently received lasted for a long time. Tina Morris, AWS, said nibble boundaries shouldn?t be such a concern. They were using 3% globally of what had been assigned and it was ridiculous to get these micro allocations when the whole point of IPv6 was to make things easier. When you assigned just part of a block, the entire network planning was messed up ? internally you could no longer use nibble boundaries, could no longer make a good organisational plan for your network. The whole point of IPv6 was to make things easier, better, implementable, and if they didn?t make things workable for organisations, then they were blocking the growth of IPv6 networks. Elvis said the RIPE NCC already reserved three bits for larger blocks and so he wondered why they were even having this discussion. The way the RIPE NCC used the sparse allocation mechanism allowed allocations to grow further. Kurt said he would turn it around and define a nibble-boundary routing-obligation to support small IPv6 routing tables. He hated fragmentation and deaggregation. Erik said this came back to the goals of the policy. Obviously, they still thought that deaggregation wasn?t something they could fix in the policy. They encouraged everyone to use BCPs and not announce all their /48s. But if you looked at the IPv6 routing tables, it was 48% /48s at this point. Sander asked if there was interest in him drafting a policy proposal to realign the policies with nibble boundaries. That would mean changing a /29 to a /28 and asking the RIPE NCC to reserve four bits to align it with the /24. Maybe it was time to be more ambitious than to tweak this one bit at a time. He asked for a show of hands [but only saw a couple of hands]. He said he would discuss further with the chairs to see if there was support. Erik said on the next video call that they would have on IPv6 they would invite Sander and Gert to provide additional feedback. They would also invite people from the RIPE NCC to explain what their current operation was and where they stumbled on the current policy, before they made any changes. Daniel Karrenberg, Internet geek, asked why maintaining a low number of prefixes was suddenly such a big problem. They had managed a much bigger number in IPv4. Erik said it was the fact that IPv6 prefixes were longer, and if you started announcing every /29 in /48s, you got an explosion in the routing table, so that?s why aggregation was a topic. Mirjam K?hne, RIPE Chair, said she was happy to see the enthusiasm. She was going to suggest they discuss this on the list before creating a proposal, but she noted that Erik seemed to be suggesting this with the interim call. Erik agreed. Leo said he thought this had been a useful discussion. Before leaping towards a specific thing with nibble boundaries, he thought it would be good to base this in the policy goals. If they could get clear on that, it would help any discussions on the specifics to be more productive, as they would know what they were trying to achieve. Erik said that sounded reasonable. G. Temporary IPv4 Assignments - Minimum Assignment Size Leo Vegoda, Address Policy WG co-chair The video is available at: https://ripe85.ripe.net/archives/video/913/ Leo gave a brief summary of the topic. The RIPE NCC got requests for temporary allocations for academic and research experiments that often only needed a very small number of IPv4 addresses. The policy said that justification was required for experiments in the same way as anything else ? meaning that if you were unable to justify 128 addresses or more, you did not get a /24. The question was whether they needed a minimum allocation size for experiments, and whether this should apply only to academic or research assignments, or if it needed to be a more general thing ? because if you needed to use an assignment it had to be a /24. Elvis (online) said /24 should be the minimum size for temporary assignments, as it was unusable otherwise. Erik asked if they needed to limit this to research or if it should be for more general use. His personal feeling was that it shouldn?t be limited to specific research as the IPv4 policy had a minimum size for allocations and the policies should align. He said they would take this back to the mailing list. Edwin Verheul, SURF, said they liked that the RIPE NCC provided temporary assignments ? they used them for events and were happy with that. One issue was geolocation. He wondered if certain /24s could be limited to certain countries or regions so they didn?t run into limitations in that department. Erik said geolocation was going to be an issue when they ran into leasing or temporary assignments. There might be an option where the RIPE NCC could provide a geofeed. This could feed into the IP databases that were doing geolocation. Otherwise, you could extend the time that the addresses were in use ? it typically took 6-8 weeks before geolocation databases were updated unless you were willing to do the legwork. Marco said he was happy to hear the suggestion that they have a minimum assignment size and he would like to see this discussed further on the mailing list. For the RIPE NCC it was a pain point and everyone thought it should change. Erik said he would try to find someone to create a proposal. Kurt asked if there was any usability guarantee after getting the space back (getting it removed from spam blocklists and so on). Marco said they did pick address space randomly and allowed a certain quarantine time, but they didn?t check how ?tainted? the address space was. They tried to give space that was as clean as possible and he might contact Kurt to hear feedback on how his experience was. Radu-Adrian Feurdean, FranceIX, asked if they should plan to gradually phase out temporary allocations. Surely the message should be that IPv4 was over and IPv6 was the way. Elvis volunteered to author the temporary assignment policy proposal. H. AOB/Open Mic The video is available at: https://ripe85.ripe.net/archives/video/914/ Sander said there was a message on one of the RIPE mailing lists from Hans Petter Holen about Ukraine. This was about protecting the resources of Ukrainian members from being transferred at gunpoint. They had talked about this in Berlin, but it still seemed to be going on. In his response to the Ukrainian Government, Hans Petter had suggested they raise this in the Address Policy WG. He didn?t think protecting members? resources was a policy issue, but he was interested to hear from the WG. Erik said the WG chairs had discussed this issue. It wasn?t unique to Ukraine, whatever they came up with should apply to other areas, such as Palestine, Syria and so on. He added that there had been a suggestion that people have some kind of ability to lock their resources in the LIR Portal. Some kind of country-specific transfer lock was not something he would envision. When looking at art [as a parallel example], this was often stolen in war. What happened was that the owners went to the court after the war and got their property back that way. His personal thinking was that they should focus more on the appeals side rather than finding a policy solution. Max Tulyev, NetAssist, agreed that it should not be handled through policy. He agreed it would be good to have a big red button that would lock transfers for some period of time. A country-specific lock was not an option. He added that there was government corruption within Ukraine and he thought some kind of government approval for transfers should not be used. Erik said that one of the risks he saw ? and he was sorry to state it this way ? was if a gun was pointed at a director of a company or their family. Surely in this case the best response was to process the transfer and get an appeal afterwards. That was the safest option for everybody involved. However, that was his own opinion. Max said they had some statistics that this had already happened in the occupied territories regarding other types of assets (he didn?t know of any cases involving IP resources) and they were killing people after the transfer. Reversing transfers would also open a can of worms as it could be open to abuse. Erik said the process here was similar to cases of art, for example. He added that there would be an update on this topic in the RIPE NCC Services WG. Olena Kushnir, WebPro, said they were a telecommunications provider of critical infrastructure in Ukraine. Of course, they had LIRs that only bought and sold IP addresses, and others who used these resources to provide services. When the war started in Ukraine, businesses that continued to work in the country were afraid that they would be put in danger. Of course they would do everything to save their family and their lives ? but they were also afraid for their business and resources. It was first of all a matter of cyber-security. It was also a considerable amount of money that they could save [in terms of the value of the resources]. They didn?t want influence from government in their business, though she added that they had good dialogue with government through many working groups. She noted that Max said he didn?t know of any cases involving stolen IP addresses ? she referenced the case of FTcom which had transferred addresses to Russian territory. She thought it was good to discuss changes to policy and she was grateful for the opportunity to be present for the discussion. She said they wanted to freeze all transfers until they found some way to protect Ukrainian network operators, because they were also part of the RIPE family. Hans Petter Holen, RIPE NCC, thanked his Ukrainian colleagues for attending the meeting and raising their concerns. What was happening in their country was terrible and he wanted to be clear on that. He noted that Athina would be presenting on this in the RIPE NCC Services WG. They would need input from the community on this and would be listening carefully to all of the input they received. And he reassured them that no matter how they would go forward, the RIPE NCC?s Board was intent on them taking timely action on the matter, so he didn?t think they should let the policy path be prohibitive just because of the timing, as perhaps the board could approve a temporary measure until the policy was ready. Artem Zurkov, no affiliation, said he was a provider from an occupied territory. He thought there should be some kind of public log so that if resources were locked, people would know that there was no ability to unlock them. This could support people?s physical safety if people with guns could see that this was the case. He supported Max?s suggestion that they should have some way for people to lock resources for a period of time. Elvis asked Hans Petter for guidance from the RIPE NCC on what kind of policy interventions would be needed. Hans Petter said the transfer policies said that the RIPE NCC should process transfers, but now they were suggesting that it shouldn?t process some transfers? but the community wanted the RIPE NCC to follow its policies. Clearly this could become complicated. He encouraged people to attend the RIPE NCC Services WG services session later that day to hear more on this. R?diger Volk, no affiliation, said he wanted to raise a different topic. He wondered whether the status field in the delegated extend file as it was defined and operated by the RIPE NCC should get some attention in the Address Policy WG. He noted that ISOC had reported some confusion using the data and, as far as he could tell, there was not really any clear documentation or attention to what was being done in that file. A couple of years ago, people had said this was just some statistics the RIRs were putting out and didn?t have much meaning. At the time of RIPE 75, policy changes in RPKI provided arguments that the delegated extended file actually had to be taken seriously. At RIPE 78, he had reported operational problems with the file, and he thought that if ISOC people, who were quite knowledgeable, were getting confused, then this was something that should be reviewed from a policy point of view. Erik thanked R?diger for his feedback and said this was definitely a discussion they needed to have on the mailing list, so they would need some more feedback from him there. End of second session. From adallara at ripe.net Wed Nov 30 13:53:46 2022 From: adallara at ripe.net (Angela Dall'Ara) Date: Wed, 30 Nov 2022 13:53:46 +0100 Subject: [address-policy-wg] 2022-02 Policy Proposal Withdrawn (Remove mandatory IPv4 PA assignment registration in the RIPE Database) Message-ID: <4e8751f9-0c50-26e6-146c-9796f37510c6@ripe.net> Dear colleagues, The policy proposal 2022-02, "Remove mandatory IPv4 PA assignment registration in the RIPE Database? has been withdrawn. The goal of this proposal was to change the registration of IPv4 assignments from mandatory to optional. The proposal is archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive-policy-proposals/ Reason for withdrawal: The proposer decided to withdraw this proposal, feeling that a new proposal would be more suitable for including the suggestions and feedback provided by the community during the discussion phase. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC