From adallara at ripe.net Mon Jan 9 11:40:24 2023 From: adallara at ripe.net (Angela Dall'Ara) Date: Mon, 9 Jan 2023 11:40:24 +0100 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) Message-ID: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> Dear colleagues, A new RIPE Policy Proposal, 2023-01, "Reducing IXP IPv4 assignment default size to a /26" is now available for discussion. The goal of this proposal is to extend the lifetime of the IXP IPv4 address pool and to motivate IXPs to implement the exchange of IPv4 routing information over IPv6. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2023-01 As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781 We encourage you to review this proposal and send your comments to address-policy-wg at ripe.net before 7 February 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC From ripe-wgs at radu-adrian.feurdean.net Wed Jan 11 12:14:42 2023 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 11 Jan 2023 12:14:42 +0100 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> Message-ID: Hello, Would somebody from NCC be able to clarify how would the wording "must return the existing assignment (or existing PI used as an IXP peering LAN)" (proposed text 6.1.4 and 6.1.5) be interpreted/implemented for the case of IXPs that use ASSIGNED PA space for the peering LAN. OK, it's the same wording that already exists in the current policy, but a clarification is welcome. Otherwise the proposal seems reasonable. On Mon, Jan 9, 2023, at 11:40, Angela Dall'Ara wrote: > Dear colleagues, > > A new RIPE Policy Proposal, 2023-01, "Reducing IXP IPv4 assignment > default size to a /26" > is now available for discussion. > > The goal of this proposal is to extend the lifetime of the IXP IPv4 > address pool and to motivate IXPs to implement the exchange of IPv4 > routing information over IPv6. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2023-01 > > As per the RIPE Policy Development Process (PDP), the purpose of this > four-week Discussion Phase is to discuss the proposal and provide > feedback to the proposer. > > At the end of the Discussion Phase, the proposer, with the agreement of > the WG Chairs, will decide how to proceed with the proposal. > > The PDP document can be found at: > https://www.ripe.net/publications/docs/ripe-781 > > We encourage you to review this proposal and send your comments to > address-policy-wg at ripe.net before 7 February 2023. > > > Kind regards, > > Angela Dall'Ara > Policy Officer > RIPE NCC > > > -- > > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://mailman.ripe.net/ -- Radu-Adrian FEURDEAN From mschmidt at ripe.net Wed Jan 11 15:18:54 2023 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 11 Jan 2023 15:18:54 +0100 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> Message-ID: Dear Radu, I'm happy to provide some clarification. The current IPv4 IXP policy states "Once they require a larger assignment, they must return their current one (or existing PI used as an IXP peering LAN)" [1] It is the RIPE NCC's understanding that this condition applies to IXP assignments provided under this policy and to older regular PI assignments if they were provided exclusively for IXP peering LANs. Other IP ranges that might be used for IXP services, such as parts of an IPv4 allocation (ASSIGNED PA), do not fall under this condition. As you mentioned, the proposed new wording on this topic is very similar, and the RIPE NCC would apply the same understanding if this proposal would become a RIPE policy. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC [1] https://www.ripe.net/publications/docs/ripe-733#61 On 11/01/2023 12:14, Radu-Adrian FEURDEAN wrote: > Hello, > > Would somebody from NCC be able to clarify how would the wording "must return the existing assignment (or existing PI used as an IXP peering LAN)" (proposed text 6.1.4 and 6.1.5) be interpreted/implemented for the case of IXPs that use ASSIGNED PA space for the peering LAN. OK, it's the same wording that already exists in the current policy, but a clarification is welcome. > > Otherwise the proposal seems reasonable. > > On Mon, Jan 9, 2023, at 11:40, Angela Dall'Ara wrote: >> Dear colleagues, >> >> A new RIPE Policy Proposal, 2023-01, "Reducing IXP IPv4 assignment >> default size to a /26" >> is now available for discussion. >> >> The goal of this proposal is to extend the lifetime of the IXP IPv4 >> address pool and to motivate IXPs to implement the exchange of IPv4 >> routing information over IPv6. >> >> You can find the full proposal at: >> https://www.ripe.net/participate/policies/proposals/2023-01 >> >> As per the RIPE Policy Development Process (PDP), the purpose of this >> four-week Discussion Phase is to discuss the proposal and provide >> feedback to the proposer. >> >> At the end of the Discussion Phase, the proposer, with the agreement of >> the WG Chairs, will decide how to proceed with the proposal. >> >> The PDP document can be found at: >> https://www.ripe.net/publications/docs/ripe-781 >> >> We encourage you to review this proposal and send your comments to >> address-policy-wg at ripe.net before 7 February 2023. >> >> >> Kind regards, >> >> Angela Dall'Ara >> Policy Officer >> RIPE NCC >> >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or >> change your subscription options, please visit: >> https://mailman.ripe.net/ From ripe-wgs at radu-adrian.feurdean.net Wed Jan 11 15:41:15 2023 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 11 Jan 2023 15:41:15 +0100 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> Message-ID: <361687ff-767d-400f-917c-c76f33d263ce@app.fastmail.com> On Wed, Jan 11, 2023, at 15:18, Marco Schmidt wrote: > Other IP ranges that might be used for IXP services, such as parts of an > IPv4 allocation (ASSIGNED PA), do not fall under this condition. So when the time comes (and provided the other conditions are met) it would be possible to request a /23 in grow an IXP currently using a /24 "ASSIGNED PA", with nothing to return to the NCC (the rest of the allocation being in use). Is that correct ? -- Radu-Adrian FEURDEAN From farmer at umn.edu Wed Jan 11 20:08:18 2023 From: farmer at umn.edu (David Farmer) Date: Wed, 11 Jan 2023 13:08:18 -0600 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> Message-ID: Does the NCC's reverse DNS delegation tooling allow for a DNS delegation of a prefix longer than a /24, as discussed in RFC 2137? While not insurmountable, delegating prefixes longer than a /24 will complicate the reverse DNS for IXPs receiving these longer prefixes. At a minimum, this should be called out in the proposal, ensuring the community considers the issue. Thanks On Mon, Jan 9, 2023 at 6:29 AM Angela Dall'Ara wrote: > Dear colleagues, > > A new RIPE Policy Proposal, 2023-01, "Reducing IXP IPv4 assignment > default size to a /26" > is now available for discussion. > > The goal of this proposal is to extend the lifetime of the IXP IPv4 > address pool and to motivate IXPs to implement the exchange of IPv4 > routing information over IPv6. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2023-01 > > As per the RIPE Policy Development Process (PDP), the purpose of this > four-week Discussion Phase is to discuss the proposal and provide > feedback to the proposer. > > At the end of the Discussion Phase, the proposer, with the agreement of > the WG Chairs, will decide how to proceed with the proposal. > > The PDP document can be found at: > https://www.ripe.net/publications/docs/ripe-781 > > We encourage you to review this proposal and send your comments to > address-policy-wg at ripe.net before 7 February 2023. > > > Kind regards, > > Angela Dall'Ara > Policy Officer > RIPE NCC > > > -- > > 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 farmer at umn.edu Wed Jan 11 20:11:53 2023 From: farmer at umn.edu (David Farmer) Date: Wed, 11 Jan 2023 13:11:53 -0600 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> Message-ID: Whoops, that should be RFC 2317, sorry. On Wed, Jan 11, 2023 at 1:08 PM David Farmer wrote: > Does the NCC's reverse DNS delegation tooling allow for a DNS delegation > of a prefix longer than a /24, as discussed in RFC 2137? > > While not insurmountable, delegating prefixes longer than a /24 will > complicate the reverse DNS for IXPs receiving these longer prefixes. > > At a minimum, this should be called out in the proposal, ensuring the > community considers the issue. > > Thanks > > On Mon, Jan 9, 2023 at 6:29 AM Angela Dall'Ara wrote: > >> Dear colleagues, >> >> A new RIPE Policy Proposal, 2023-01, "Reducing IXP IPv4 assignment >> default size to a /26" >> is now available for discussion. >> >> The goal of this proposal is to extend the lifetime of the IXP IPv4 >> address pool and to motivate IXPs to implement the exchange of IPv4 >> routing information over IPv6. >> >> You can find the full proposal at: >> https://www.ripe.net/participate/policies/proposals/2023-01 >> >> As per the RIPE Policy Development Process (PDP), the purpose of this >> four-week Discussion Phase is to discuss the proposal and provide >> feedback to the proposer. >> >> At the end of the Discussion Phase, the proposer, with the agreement of >> the WG Chairs, will decide how to proceed with the proposal. >> >> The PDP document can be found at: >> https://www.ripe.net/publications/docs/ripe-781 >> >> We encourage you to review this proposal and send your comments to >> address-policy-wg at ripe.net before 7 February 2023. >> >> >> Kind regards, >> >> Angela Dall'Ara >> Policy Officer >> RIPE NCC >> >> >> -- >> >> 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 > =============================================== > -- =============================================== 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 job at sobornost.net Wed Jan 11 20:19:47 2023 From: job at sobornost.net (Job Snijders) Date: Wed, 11 Jan 2023 19:19:47 +0000 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> Message-ID: Dear David, On Wed, Jan 11, 2023 at 01:08:18PM -0600, David Farmer via address-policy-wg wrote: > Does the NCC's reverse DNS delegation tooling allow for a DNS > delegation of a prefix longer than a /24? Yes. See https://apps.db.ripe.net/docs/entire-documentation-(HTML)#description-of-the-domain-object "For IPv4 addresses, a dash is allowed in the fourth octet of the reverse address. This allows for reverse DNS delegations for address space that doesn't fall on octet boundaries as specified in RFC 2317. A dash is not allowed in any other octet." Example: To set up Reverse DNS for this IPv4 address range: 10.2.1.6 - 10.2.1.25 using the dash notation, the zone name becomes "6-25.1.2.10.in-addr.arpa" Kind regards, Job From mschmidt at ripe.net Thu Jan 12 13:36:24 2023 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 12 Jan 2023 13:36:24 +0100 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <361687ff-767d-400f-917c-c76f33d263ce@app.fastmail.com> References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> <361687ff-767d-400f-917c-c76f33d263ce@app.fastmail.com> Message-ID: <79bf9bb9-7111-bdd8-a617-8f46f011c2e8@ripe.net> Dear Radu, Yes, that is correct. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC On 11/01/2023 15:41, Radu-Adrian FEURDEAN wrote: > On Wed, Jan 11, 2023, at 15:18, Marco Schmidt wrote: >> Other IP ranges that might be used for IXP services, such as parts of an >> IPv4 allocation (ASSIGNED PA), do not fall under this condition. > So when the time comes (and provided the other conditions are met) it would be possible to request a /23 in grow an IXP currently using a /24 "ASSIGNED PA", with nothing to return to the NCC (the rest of the allocation being in use). > > Is that correct ? > From tore at fud.no Mon Jan 16 09:51:32 2023 From: tore at fud.no (Tore Anderson) Date: Mon, 16 Jan 2023 09:51:32 +0100 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> Message-ID: * Angela Dall'Ara > A new RIPE Policy Proposal, 2023-01, "Reducing IXP IPv4 assignment > default size to a /26" > is now available for discussion. > > The goal of this proposal is to extend the lifetime of the IXP IPv4 > address pool and to motivate IXPs to implement the exchange of IPv4 > routing information over IPv6. Hi, This proposal is a step in the right direction, although I feel it should have gone further. I've already elaborated on why in the ?IXP pool lower boundary of assignments? thread, so I don't seek to re-hash that whole thread, but for the record I'll repeat the gist of it in the formal proposal thread: Since IPv4 is a finite resource that needs to last "forever", it seems wasteful to willfully assign too large prefixes to IXPs that do not need them. According to https://github.com/mwichtlh/address-policy-wg, a /26 would be excessively large for a majority of IXPs. I would rather see a policy that did not specify a default size at all, but rather instructed the NCC to right-size each assignment according to the "at least 50% utilisation after a year" rule. Note that this should not be considered an objection to this proposal, as I mentioned before it is a step in the right direction, after all. With that out of the way, I have a few questions/comments: 1) Regarding ?New IXPs will be initially assigned a /26 by default. Upon request, a /25 can be assigned initially.?If the initial assignment has been utilised by at least 50%, IXPs can request the assignment of a /24?: This is somewhat difficult to decipher. Does it mean that: a) a new IXP can simply ask for an initial /25 and receive it, no questions asked? b) an existing IXP that has used 50% of an initial /26 will be able to upgrade straight to a /24, i.e., bypassing a /25? (Or even %50-of- /27?/24, in an unlikely but not impossible corner case.) To improve clarity, I would suggest not to mix the conditions for new IXPs / initial assignments with the conditions for already existing IXPs that seek to upgrade a previous assignment. 2) Regarding ?Assignments strictly larger than a /24 will only be made to IXPs that offer the exchange of IPv4 routing information over IPv6 at their route servers?: a) What is the purpose / meaning of the word ?strictly? here? I assume it is there for a reason, but removing it does not seem to me to change the meaning of the sentence in any way (but then again, I am not a native English speaker). b) Depending on whether one considers an assignment from the NCC to the IXPs as to be a continuous state or as a one-time event, this may cause an instant obligation on current holders of larger-than-/24 IXP prefixes to implement IPv4-over-IPv6 routing in their route servers. Is that the intention? Tore From tore at fud.no Mon Jan 16 11:09:58 2023 From: tore at fud.no (Tore Anderson) Date: Mon, 16 Jan 2023 11:09:58 +0100 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> Message-ID: <739cacc6f9fae370b959b073e5fa758680a5ebf4.camel@fud.no> Forgot to mention one thing, see below. (I am quoting my entire previous message so both can be replied to in-line at once.) * Tore Anderson > * Angela Dall'Ara > > > A new RIPE Policy Proposal, 2023-01, "Reducing IXP IPv4 assignment > > default size to a /26" > > is now available for discussion. > > > > The goal of this proposal is to extend the lifetime of the IXP IPv4 > > address pool and to motivate IXPs to implement the exchange of IPv4 > > routing information over IPv6. > > Hi, > > This proposal is a step in the right direction, although I feel it > should have gone further. I've already elaborated on why in the ?IXP > pool lower boundary of assignments? thread, so I don't seek to re-hash > that whole thread, but for the record I'll repeat the gist of it in the > formal proposal thread: > > Since IPv4 is a finite resource that needs to last "forever", it seems > wasteful to willfully assign too large prefixes to IXPs that do not > need them. According to https://github.com/mwichtlh/address-policy-wg, > a /26 would be excessively large for a majority of IXPs. > > I would rather see a policy that did not specify a default size at all, > but rather instructed the NCC to right-size each assignment according > to the "at least 50% utilisation after a year" rule. > > Note that this should not be considered an objection to this proposal, > as I mentioned before it is a step in the right direction, after all. > > With that out of the way, I have a few questions/comments: > > 1) Regarding ?New IXPs will be initially assigned a /26 by default. > Upon request, a /25 can be assigned initially.?If the initial > assignment has been utilised by at least 50%, IXPs can request the > assignment of a /24?: > > This is somewhat difficult to decipher. Does it mean that: > > a) a new IXP can simply ask for an initial /25 and receive it, no > questions asked? > b) an existing IXP that has used 50% of an initial /26 will be able to > upgrade straight to a /24, i.e., bypassing a /25? (Or even %50-of- > /27?/24, in an unlikely but not impossible corner case.) > > To improve clarity, I would suggest not to mix the conditions for new > IXPs / initial assignments with the conditions for already existing > IXPs that seek to upgrade a previous assignment. > > > 2) Regarding ?Assignments strictly larger than a /24 will only be made > to IXPs that offer the exchange of IPv4 routing information over IPv6 > at their route servers?: > > a) What is the purpose / meaning of the word ?strictly? here? I assume > it is there for a reason, but removing it does not seem to me to change > the meaning of the sentence in any way (but then again, I am not a > native English speaker). > > b) Depending on whether one considers an assignment from the NCC to the > IXPs as to be a continuous state or as a one-time event, this may cause > an instant obligation on current holders of larger-than-/24 IXP > prefixes to implement IPv4-over-IPv6 routing in their route servers. Is > that the intention? 3) Regarding ?On request or once there are no more available assignments of /26 (or larger), assignments can be made down to /27.?: I suggest this proposal adds the current (and future) non-assignable ?space dust? (prefixes smaller than /24) in the NCC's inventory to the IXP pool. Considering that IXPs is one of the few use cases where this ?space dust? is useful, and that this proposal opens up for assignments of such small prefixes from the IXP pool, it seems logical to open up for the similar use of the small prefixes currently not part of the IXP pool as well. However, when we are at at a point in time where the IXP pool is completely empty except for such ?space dust?, why restrict the assignment size to /27? It seems to me that if we have reached a point in time where the only thing remaining in the IXP pool is ?space dust? smaller than /27, and there is a small new IXP that could make use of, say, a /28, I see no reason to deny the IXP receiving that assignment. Therefore I suggest replacing ?assignments can be made down to /27? with ?smaller assignments can be made? or something along those lines. Tore From wolfgang.tremmel at de-cix.net Mon Jan 16 14:16:59 2023 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Mon, 16 Jan 2023 13:16:59 +0000 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <739cacc6f9fae370b959b073e5fa758680a5ebf4.camel@fud.no> References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> <739cacc6f9fae370b959b073e5fa758680a5ebf4.camel@fud.no> Message-ID: Let me answer a few points with my co-author and "I work for an IXP" hat on: > On 16. Jan 2023, at 11:09, Tore Anderson wrote: > >> >> I would rather see a policy that did not specify a default size at all, >> but rather instructed the NCC to right-size each assignment according >> to the "at least 50% utilisation after a year" rule. The /26 is a compromise between "make it useful" and "make it small enough". Our idea was that new IXPs sometimes over-estimate their future success (-> "make the default small") and sometimes grow faster than expected (-> "jump directly to a /24"). But initially a /26 seems to be just right. And we wanted a number in this policy. Otherwise too many "just give me a /24 because I am an IXP" requests, also if someone plans a new IXP they know what they get and can plan accordingly. >> >> >> >> a) a new IXP can simply ask for an initial /25 and receive it, no >> questions asked? yes. But if a new IXP requests an initial /25 they at least have done some homework about what to expect. And I expect that homework to be shown to the RIPE NCC to get the /25. >> b) an existing IXP that has used 50% of an initial /26 will be able to >> upgrade straight to a /24, i.e., bypassing a /25? (Or even %50-of- >> /27?/24, in an unlikely but not impossible corner case.) Also yes. If the IXP grows really fast, they can go directly to a /24. Why? Renumbering an IXP is pain. A lot of pain. I (personally) have run renumbering projects or participated in renumbering projects multiple times. >> >> >> 2) Regarding ?Assignments strictly larger than a /24 will only be made >> to IXPs that offer the exchange of IPv4 routing information over IPv6 >> at their route servers?: >> >> a) What is the purpose / meaning of the word ?strictly? here? I assume >> it is there for a reason, but removing it does not seem to me to change >> the meaning of the sentence in any way (but then again, I am not a >> native English speaker). idea is: strictly larger > larger >= >> >> b) Depending on whether one considers an assignment from the NCC to the >> IXPs as to be a continuous state or as a one-time event, this may cause >> an instant obligation on current holders of larger-than-/24 IXP >> prefixes to implement IPv4-over-IPv6 routing in their route servers. Is >> that the intention? No, the policy only applies to new >/24 assignments > > > However, when we are at at a point in time where the IXP pool is > completely empty except for such ?space dust?, why restrict the > assignment size to /27? It seems to me that if we have reached a point > in time where the only thing remaining in the IXP pool is ?space dust? > smaller than /27, and there is a small new IXP that could make use of, > say, a /28, I see no reason to deny the IXP receiving that assignment. IMHO a /28 is not useful for an IXP. Or what I consider to be an IXP. It allows for 14 IPv4 connections, so *if* that IXP does some monitoring and route servers, 11 IPs are free for customers. And no growth is possible. We can do that once the pool is empty in another policy change IMHO. best regards Wolfgang -- 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 Mon Jan 16 14:47:17 2023 From: tore at fud.no (Tore Anderson) Date: Mon, 16 Jan 2023 14:47:17 +0100 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> <739cacc6f9fae370b959b073e5fa758680a5ebf4.camel@fud.no> Message-ID: <64971db45b8fccd0ac987577b6b93a737cd439ce.camel@fud.no> * Wolfgang Tremmel > > > > > a) a new IXP can simply ask for an initial /25 and receive it, no > > > questions asked? > > yes. But if a new IXP requests an initial /25 they at least have done > some homework about what to expect. And I expect that homework to be > shown to the RIPE NCC to get the /25. What makes you expect any "homework" to be shown to the RIPE NCC, if the policy says they can have the /25, no questions asked? The policy needs to explicitly state that such "homework" is necessary if that is what you want. > > > b) an existing IXP that has used 50% of an initial /26 will be able to > > > upgrade straight to a /24, i.e., bypassing a /25? (Or even %50-of- > > > /27?/24, in an unlikely but not impossible corner case.) > > Also yes. If the IXP grows really fast, they can go directly to a > /24. Why? Renumbering an IXP is pain. A lot of pain. I? (personally) > have run renumbering projects or participated in renumbering projects > multiple times. Wouldn't that mean that the policy can be gamed? Procedure: 1. Request and receive an initial /27 (permitted by new section 8) 2. Reach 50% utilisation (12 members + 2 RSes + net/bcast addrs) 3. Request and receive a replacement /24 This "land-grabbing" IXP has now gotten its hands on a /24 while only at 6.25% utilisation. Nothing in the proposed policy will prevent this from happening, as far as I can tell. Should it? > > > 2) Regarding ?Assignments strictly larger than a /24 will only be made > > > to IXPs that offer the exchange of IPv4 routing information over IPv6 > > > at their route servers?: > > > > > > a) What is the purpose / meaning of the word ?strictly? here? I assume > > > it is there for a reason, but removing it does not seem to me to change > > > the meaning of the sentence in any way (but then again, I am not a > > > native English speaker). > > idea is: > strictly larger > > larger >= Hm. I do believe ?larger? means ">", not ">=". Maybe a native speaker could confirm. If so, ?strictly??could and should be dropped as it only serves to add confusion. > > However, when we are at at a point in time where the IXP pool is > > completely empty except for such ?space dust?, why restrict the > > assignment size to /27? It seems to me that if we have reached a point > > in time where the only thing remaining in the IXP pool is ?space dust? > > smaller than /27, and there is a small new IXP that could make use of, > > say, a /28, I see no reason to deny the IXP receiving that assignment. > > IMHO a /28 is not useful for an IXP. Or what I consider to be an IXP. According to https://github.com/mwichtlh/address-policy-wg about 40% of all IXPs would fit in a /28 ?with 50% oversubscription?, and about 55% all IXPs would fit in a /28 with no oversubscription. I therefore think you might consider adjusting your perception of what an IXP is. Alternatively we would need to consider the supporting data for this proposal bogus. In any case, if the requesting new IXP gets offered a /28 (as that is all that is available at that point), it is of course free to decline. There is no harm in having the NCC make the offer, is there? > We can do that once the pool is empty in another policy change IMHO. Why wait? What is the harm in doing it now? Tore From matthias.wichtlhuber at de-cix.net Tue Jan 17 13:25:02 2023 From: matthias.wichtlhuber at de-cix.net (Matthias Wichtlhuber) Date: Tue, 17 Jan 2023 12:25:02 +0000 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <64971db45b8fccd0ac987577b6b93a737cd439ce.camel@fud.no> References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> <739cacc6f9fae370b959b073e5fa758680a5ebf4.camel@fud.no> , <64971db45b8fccd0ac987577b6b93a737cd439ce.camel@fud.no> Message-ID: <6e5f9581bb4043a687cef205a2bda748@de-cix.net> Hi, regarding 6.1(4) - (default is /26, /25 is handed out upon request): The idea behind this part of the proposal is that there are two kinds of IXPs, one that is founded due to the need to interconnect a few networks in a specific region and no intent of growth and one that is operated with the explicit intent to grow and generate business. IXPs can decide on their plans on their own and do an appropriate selection of their initial assignment. regarding 6.1 (7) - (assignments down to /27): I agree that the policy can be gamed by asking for a /27 and jumping to a /24; we might consider to restrict this part to only handing out /27s once the IXP pool is depleted, but not upon request. I doubt RIPE has handed out any /27 assignments upon request anyways; maybe someone from RIPE can look into this? regarding the general point of lower bound of assignments and your comment: > Alternatively we would need to consider the supporting data for this proposal bogus. As I have stated a couple of times in the previous discussions, the data in PeeringDB can only provide a lower bound of connections per IXP; nevertheless it remains the best dataset we currently have. Thus the decision will have to be a mix of listening to experienced people from the IXP community and the results of the analysis. I think a /26 is a good compromise here. 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 Tore Anderson Gesendet: Montag, 16. Januar 2023 14:47:17 An: RIPE Address Policy Working Group Betreff: Re: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) * Wolfgang Tremmel > > > > > a) a new IXP can simply ask for an initial /25 and receive it, no > > > questions asked? > > yes. But if a new IXP requests an initial /25 they at least have done > some homework about what to expect. And I expect that homework to be > shown to the RIPE NCC to get the /25. What makes you expect any "homework" to be shown to the RIPE NCC, if the policy says they can have the /25, no questions asked? The policy needs to explicitly state that such "homework" is necessary if that is what you want. > > > b) an existing IXP that has used 50% of an initial /26 will be able to > > > upgrade straight to a /24, i.e., bypassing a /25? (Or even %50-of- > > > /27?/24, in an unlikely but not impossible corner case.) > > Also yes. If the IXP grows really fast, they can go directly to a > /24. Why? Renumbering an IXP is pain. A lot of pain. I (personally) > have run renumbering projects or participated in renumbering projects > multiple times. Wouldn't that mean that the policy can be gamed? Procedure: 1. Request and receive an initial /27 (permitted by new section 8) 2. Reach 50% utilisation (12 members + 2 RSes + net/bcast addrs) 3. Request and receive a replacement /24 This "land-grabbing" IXP has now gotten its hands on a /24 while only at 6.25% utilisation. Nothing in the proposed policy will prevent this from happening, as far as I can tell. Should it? > > > 2) Regarding ?Assignments strictly larger than a /24 will only be made > > > to IXPs that offer the exchange of IPv4 routing information over IPv6 > > > at their route servers?: > > > > > > a) What is the purpose / meaning of the word ?strictly? here? I assume > > > it is there for a reason, but removing it does not seem to me to change > > > the meaning of the sentence in any way (but then again, I am not a > > > native English speaker). > > idea is: > strictly larger > > larger >= Hm. I do believe ?larger? means ">", not ">=". Maybe a native speaker could confirm. If so, ?strictly? could and should be dropped as it only serves to add confusion. > > However, when we are at at a point in time where the IXP pool is > > completely empty except for such ?space dust?, why restrict the > > assignment size to /27? It seems to me that if we have reached a point > > in time where the only thing remaining in the IXP pool is ?space dust? > > smaller than /27, and there is a small new IXP that could make use of, > > say, a /28, I see no reason to deny the IXP receiving that assignment. > > IMHO a /28 is not useful for an IXP. Or what I consider to be an IXP. According to https://github.com/mwichtlh/address-policy-wg about 40% of all IXPs would fit in a /28 ?with 50% oversubscription?, and about 55% all IXPs would fit in a /28 with no oversubscription. I therefore think you might consider adjusting your perception of what an IXP is. Alternatively we would need to consider the supporting data for this proposal bogus. In any case, if the requesting new IXP gets offered a /28 (as that is all that is available at that point), it is of course free to decline. There is no harm in having the NCC make the offer, is there? > We can do that once the pool is empty in another policy change IMHO. Why wait? What is the harm in doing it now? Tore -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From tore at fud.no Tue Jan 17 14:54:31 2023 From: tore at fud.no (Tore Anderson) Date: Tue, 17 Jan 2023 14:54:31 +0100 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <6e5f9581bb4043a687cef205a2bda748@de-cix.net> References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> <739cacc6f9fae370b959b073e5fa758680a5ebf4.camel@fud.no> ,<64971db45b8fccd0ac987577b6b93a737cd439ce.camel@fud.no> <6e5f9581bb4043a687cef205a2bda748@de-cix.net> Message-ID: * Matthias Wichtlhuber > regarding 6.1(4) - (default is /26, /25 is handed out upon request): > > The idea behind this part of the proposal is that there are two kinds > of IXPs, one that is founded due to the need to interconnect a few > networks in a specific region and no intent of growth and one that is > operated with the explicit intent to grow and generate business. IXPs > can decide on their plans on their own and do an appropriate > selection of their initial assignment. That places a big trust in the new IXPs to not ask for a /25 if they do not need it. To me, that seems naive - there are strong incentives for new IXPs to ask for as much as possible regardless of actual need. You point them out in the proposal yourself: avoid and/or postponing future renumbering and IPv4 purchases. A similar situation exist in IPv6. LIRs can freely choose initial allocations in the range /29../32. I bet the vast majority of new LIRs do not need anything larger than /32 (they definitively do not have to worry about renumbering or IPv6 purchases), yet in 2022 the numbers were: 1035 /29 allocations 3 /30 allocations 0 /31 allocations 64 /32 allocations So 94% chose the biggest they could get. That's human nature for you. Under the proposed policy I bet you will see the same thing happening, most IXPs will ask for /25s. (I sure would, if I was to start an IXP. There is simply no reason not to.) > regarding 6.1 (7) - (assignments down to /27): > > I agree that the policy can be gamed by asking for a /27 and jumping > to a /24; we might consider to restrict this part to only handing out > /27s once the IXP pool is depleted, but not upon request. I doubt > RIPE has handed out any /27 assignments upon request anyways; maybe > someone from RIPE can look into this? For what it is worth there are currently 32 /27 assignments in the delegated file (52 assignments /27 and smaller), but none of them are from the IXP pool. (They could still be used by IXPs though.) In fact, there are exactly 0 assignments smaller than /24 made from the IXP pool, even though the policy allows for this. This makes me even more convinced that IXPs will generally chose to take the largest prefix policy allows them to. > regarding the general point of lower bound of assignments and your > comment: > > > Alternatively we would need to consider the supporting data for > > this proposal bogus. > > As I have stated a couple of times in the previous discussions, the > data in PeeringDB can only provide a lower bound of connections per > IXP; nevertheless it remains the best dataset we currently have. Thus > the decision will have to be a mix of listening to experienced people > from the IXP community and the results of the analysis. I think a /26 > is a good compromise here. I was not trying to restart that part of the discussion. We can agree to disagree on whether or not /26 is a good value, and leave it at that. (It's better than /24, we can agree on that.) However, this comment was made in the context of my proposal of adding the ?IPv4 space dust? to the IXP pool, for use when the pool runs out of /26s. The NCC inventory currently contains 47+ blocks in the range /29../25 that *would* have been perfectly usable for assignment to IXPs, but they can not be assigned to IXPs under this policy because they are not part of the specially designated /15 IXP pool. I say let's add them, so they actually can do some good, instead of rotting away in the NCC inventory. This ?IPv4 space dust? also includes some prefixes smaller than /27, which would not be assignable under the proposed policy even if had added the ?IPv4 space dust? to the IXP pool. However, there *are* small IXPs that could potentially have used these. There are multiple examples just here in Norway: Trondheim IX: 5 members Bergen IX: 6 members Troms? IX: 3 members Stavanger IX: 8 members Source: https://www.nix.no/who-is-connected/ (bottom of page) All of them would make do with a /28, and three out of four would make do with a /29. I would further note that these are not newly started IXPs experiencing rapid growth, they are well established. In my opinion, denying a small IXP similar to these the opportunity to receive a small assignment ? especially when such small prefixes are the only ones left in the NCC's inventory ? just because some folks from DE-CIX do not ?consider [it] to be an IXP? just seems cruel. I do not see any harm whatsoever in allowing their assignment. Tore From leo at vegoda.org Thu Jan 26 19:14:00 2023 From: leo at vegoda.org (Leo Vegoda) Date: Thu, 26 Jan 2023 10:14:00 -0800 Subject: [address-policy-wg] IPv6 policy - prioritisation and outcomes discussion webinar Message-ID: At RIPE 85 we continued a review of the IPv6 policy that began at RIPE 83. Several areas for improvement were agreed. We promised to host an inter-sessional webinar to discuss priorities and the outcomes to work towards. The identified areas for improvement include: - Better guidance on documentation requirements for large allocations - Simpler language for the HD-ratio - Make it easier for small networks to assign a few addresses to other organisations - Ensure allocations always fall on a nibble boundary If you wants to help us set priorities and define the outcomes the community needs you are welcome to join. Monday, 20 February 2023 at 13:00 UTC (14:00 CET). Join Zoom Meeting https://ripe.zoom.us/j/94307989734?pwd=YytnQm53SjJEWUtKemxQM3dGcjZmQT09 Meeting ID: 943 0798 9734 Passcode: 339420 Leo Vegoda for the Address Policy WG co-chairs