2023-01 - New Version Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)
Dear colleagues, RIPE policy proposal 2023-01, "Reducing IXP IPv4 assignment default size to a /26" is now available for discussion again. The goal of this proposal is to reduce the default size of IPv4 assignments for IXPs from a /24 to /26 and clarifies the return of the assignments previously issued for their IXP peering LAN. Following the last round of discussion, this proposal has been updated and it is now at version 2.0. The main difference from version 1.0 is that IXPs are not required to implement the exchange of IPv4 routing information over IPv6 before requesting an assignment larger than a /24. 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 proposers, 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@ripe.net before 4 April 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC
Hi All, I would like to express my support to this proposal. It doesn't seem to tackle recovering IXP assignments made to orgs which are not really operating as IXPs, but is definitely a step in a positive direction. Best Regards, Carlos On Mon, 6 Mar 2023, Angela Dall'Ara wrote:
Dear colleagues,
RIPE policy proposal 2023-01, "Reducing IXP IPv4 assignment default size to a /26" is now available for discussion again.
The goal of this proposal is to reduce the default size of IPv4 assignments for IXPs from a /24 to /26 and clarifies the return of the assignments previously issued for their IXP peering LAN.
Following the last round of discussion, this proposal has been updated and it is now at version 2.0. The main difference from version 1.0 is that IXPs are not required to implement the exchange of IPv4 routing information over IPv6 before requesting an assignment larger than a /24.
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 proposers, 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@ripe.net before 4 April 2023.
Kind regards,
Angela Dall'Ara Policy Officer RIPE NCC
Hi, On Wed, Apr 26, 2023 at 09:13:16AM +0100, Carlos Friaças via address-policy-wg wrote:
It doesn't seem to tackle recovering IXP assignments made to orgs which are not really operating as IXPs, but is definitely a step in a positive direction.
"not operating as IXP" is something that normal RS procedures should cover ("you were given an address block that is exclusive for IXPs, so please return if you are not running one"). "not *really* operating as IXP" is usually open for long discussions... gert -- 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
On Wed, 26 Apr 2023, Gert Doering wrote:
"not *really* operating as IXP" is usually open for long discussions...
Agree. I won't go there, as i don't want to draft a new proposal :-))) Cheers, Carlos
gert -- 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
Angela Dall'Ara wrote on 06/03/2023 10:43:
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.
two issues: - I can't work out what the proposed new section 7 is saying. - there are a bunch of problematic edge cases associated with section 5. E.g. what happens if an IXP has a /23 and has 254 IP addresses used after 1Y? They will be obliged to downgrade to a /24, according to the current text. Also I don't know what a special circumstance is. The problems in section 5 can be fixed easily, but it depends on how the authors want to handle assignment upgrades / renumberings. I'd suggest either dropping the 1Y utilisation requirement to e.g. 40%, or else that if you reach e.g. 80% current usage, you qualify to receive an assignment of 2x the current, up to /22. Those figures are plucked out of the air btw. The point with them is that they are not 50%, which is obviously a magic number when the natural increase of assignment size would be to double the size of the block. Nick
Hi Nick,
I can't work out what the proposed new section 7 is saying.
This paragraph only has an editorial change, it is already present in the current policy. It covers the time threshold for returning space: after 180 days of disuse or from a new assignment received as per points 4 and 5.
there are a bunch of problematic edge cases associated with section 5. E.g. what happens if an IXP has a /23 and has 254 IP addresses used after 1Y? They will be obliged to downgrade to a /24, according to the current text. Also I don't know what a special circumstance is.
The problems in section 5 can be fixed easily, but it depends on how the authors want to handle assignment upgrades / renumberings. I'd suggest either dropping the 1Y utilisation requirement to e.g. 40%, or else that if you reach e.g. 80% current usage, you qualify to receive an assignment of 2x the current, up to /22. Those figures are plucked out of the air btw. The point with them is that they are not 50%, which is obviously a magic number when the natural increase of assignment size would be to double the size of the block.
The goal of this part is to minimize renumberings while avoiding greedy requests. Dropping the one year requirement to 40% is reasonable if you think 50% is too harsh ("magic numbers"). We can incorporate this change. Regarding the "special circumstances": this was already present in the current policy. I guess it is intended to give RIPE a little leeway to react to unforeseen circumstances. Kind regards, Matthias -- Dr.-Ing. Matthias Wichtlhuber Team Lead Research and Development ------------------------------ 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@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 ________________________________________ Von: address-policy-wg <address-policy-wg-bounces@ripe.net> im Auftrag von Nick Hilliard <nick@foobar.org> Gesendet: Mittwoch, 26. April 2023 16:59:59 An: Angela Dall'Ara Cc: address-policy-wg@ripe.net Betreff: Re: [address-policy-wg] 2023-01 - New Version Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) Angela Dall'Ara wrote on 06/03/2023 10:43: 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. two issues: - I can't work out what the proposed new section 7 is saying. - there are a bunch of problematic edge cases associated with section 5. E.g. what happens if an IXP has a /23 and has 254 IP addresses used after 1Y? They will be obliged to downgrade to a /24, according to the current text. Also I don't know what a special circumstance is. The problems in section 5 can be fixed easily, but it depends on how the authors want to handle assignment upgrades / renumberings. I'd suggest either dropping the 1Y utilisation requirement to e.g. 40%, or else that if you reach e.g. 80% current usage, you qualify to receive an assignment of 2x the current, up to /22. Those figures are plucked out of the air btw. The point with them is that they are not 50%, which is obviously a magic number when the natural increase of assignment size would be to double the size of the block. Nick
On Thu, 2023-05-04 at 06:21 +0000, Matthias Wichtlhuber via address- policy-wg wrote:
The problems in section 5 can be fixed easily, but it depends on how the authors want to handle assignment upgrades / renumberings. I'd suggest either dropping the 1Y utilisation requirement to e.g. 40%, or else that if you reach e.g. 80% current usage, you qualify to receive an assignment of 2x the current, up to /22. Those figures are plucked out of the air btw. The point with them is that they are not 50%, which is obviously a magic number when the natural increase of assignment size would be to double the size of the block.
The goal of this part is to minimize renumberings while avoiding greedy requests. Dropping the one year requirement to 40% is reasonable if you think 50% is too harsh ("magic numbers"). We can incorporate this change.
I believe that what Nick was getting at was that 50% is "magic" in the sense that it creates a problem: * a /24 has 254 usable addresses. * a /23 has 510 usable addresses -> half of that is 255. So, suppose you have used 230 addresses out of your /24. You apply for and get a /23 and happily renumber. Then, after one year, you have used 254 addresses. This is less than half of the /23 (510/2 = 255), so according to the rules you'd have to downgrade back to a /24 again. You can now no longer grow, unless you immediately apply for a /23 again. So we either live with this "bug" and trust that whoever has to perform evaluation is "reasonable", or we find a numbers that don't cause these kind of edge cases. Cheers, Steven
Dear colleagues, Reading the comments on this list, I would like to provide some clarification. If the proposal is accepted, it would only change the initial assignment size and offer the option to "jump" directly to a /24 when at least 33 addresses are in use. The utilisation requirements for IXPs requesting assignments larger than a /24 would remain unchanged. When receiving requests for more than a /24, the RIPE NCC checks that the IXP will need more than 50% of the assignment within one year. If their growth rate is too slow and we expect that it will take more than a year to exceed that utilisation threshold, we suggest that they postpone their request. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC On 08/05/2023 15:56, Steven Bakker via address-policy-wg wrote:
On Thu, 2023-05-04 at 06:21 +0000, Matthias Wichtlhuber via address- policy-wg wrote:
The problems in section 5 can be fixed easily, but it depends on how the authors want to handle assignment upgrades / renumberings. I'd suggest either dropping the 1Y utilisation requirement to e.g. 40%, or else that if you reach e.g. 80% current usage, you qualify to receive an assignment of 2x the current, up to /22. Those figures are plucked out of the air btw. The point with them is that they are not 50%, which is obviously a magic number when the natural increase of assignment size would be to double the size of the block. The goal of this part is to minimize renumberings while avoiding greedy requests. Dropping the one year requirement to 40% is reasonable if you think 50% is too harsh ("magic numbers"). We can incorporate this change. I believe that what Nick was getting at was that 50% is "magic" in the sense that it creates a problem:
* a /24 has 254 usable addresses. * a /23 has 510 usable addresses -> half of that is 255.
So, suppose you have used 230 addresses out of your /24. You apply for and get a /23 and happily renumber.
Then, after one year, you have used 254 addresses. This is less than half of the /23 (510/2 = 255), so according to the rules you'd have to downgrade back to a /24 again. You can now no longer grow, unless you immediately apply for a /23 again.
So we either live with this "bug" and trust that whoever has to perform evaluation is "reasonable", or we find a numbers that don't cause these kind of edge cases.
Cheers, Steven
Hi, I just want to quickly pop in and say that I really agree with Nick in wanting to avoid these "magic numbers". I do not know which numbers would be appropriate, but probably somewhere around 40-45% (instead of 50%). -Cynthia On Wed, Apr 26, 2023 at 5:04 PM Nick Hilliard <nick@foobar.org> wrote:
Angela Dall'Ara wrote on 06/03/2023 10:43:
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.
two issues:
- I can't work out what the proposed new section 7 is saying. - there are a bunch of problematic edge cases associated with section 5. E.g. what happens if an IXP has a /23 and has 254 IP addresses used after 1Y? They will be obliged to downgrade to a /24, according to the current text. Also I don't know what a special circumstance is.
The problems in section 5 can be fixed easily, but it depends on how the authors want to handle assignment upgrades / renumberings. I'd suggest either dropping the 1Y utilisation requirement to e.g. 40%, or else that if you reach e.g. 80% current usage, you qualify to receive an assignment of 2x the current, up to /22. Those figures are plucked out of the air btw. The point with them is that they are not 50%, which is obviously a magic number when the natural increase of assignment size would be to double the size of the block.
Nick
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
participants (8)
-
Angela Dall'Ara -
Carlos Friaças -
Cynthia Revström -
Gert Doering -
Marco Schmidt -
Matthias Wichtlhuber -
Nick Hilliard -
Steven Bakker