2025-01 New Policy Proposal (ASN assignment criteria revisited)
Dear colleagues, A new RIPE Policy Proposal, 2025-01, "ASN assignment criteria revisited" is now available for discussion. This proposal aims to to simplify requirements for new ASNs, while ensuring that the requirements are enforceable in practice and preventing the exponential exhaustion of 32-bit ASN space. You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2025-01/ As per the RIPE Policy Development Process (PDP), the purpose of the Discussion Phase is to discuss the proposal and provide feedback to the proposers. 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 June 2025. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC
Greetings, I do support this proposal. +1 for simplification :-) Cheers, Carlos On Tue, 6 May 2025, Angela Dall'Ara wrote:
Dear colleagues,
A new RIPE Policy Proposal, 2025-01, "ASN assignment criteria revisited" is now available for discussion.
This proposal aims to to simplify requirements for new ASNs, while ensuring that the requirements are enforceable in practice and preventing the exponential exhaustion of 32-bit ASN space.
You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2025-01/
As per the RIPE Policy Development Process (PDP), the purpose of the Discussion Phase is to discuss the proposal and provide feedback to the proposers.
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 June 2025.
Kind regards,
Angela Dall'Ara Policy Officer RIPE NCC
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Angela Dall'Ara wrote on 06/05/2025 12:50:
We encourage you to review this proposal and send your comments to address-policy-wg@ripe.net before 4 June 2025.
The overall aims look ok, but the proposed policy is (in my opinion) too prescriptive about operational details. As a general comment about policy creation, policy should aim towards stating principles about what-should-be-done, and for the most part should leave the details of how-to-do-it to the procedure manual. There's a bunch of reasons for this, not least being able to deal with procedural abuse, bearing in mind that the implementation time for plugging policy holes is measured in double-digit months or years. Zooming out, the policy is: - first ASN: on request - subsequent ASNs: stated need Can I suggest something based on the following text:
2.0 Assignment Criteria
LIRs and End Users may be issued a first Autonomous System Number (ASN) upon request.
LIRs and End Users may be issued an additional ASN or ASNs if the LIR or End User can provide documented justification for the unique external routing policy for the ASN application. The uniqueness of the routing policy includes the announced prefixes. The LIRs or End Users must demonstrate fulfillment of the criteria for which the application was approved within six months of the ASN being assigned.
The RIPE NCC will assign the AS Number directly to the End User upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR. Autonomous System Numbers may not be sub-assigned. AS Number assignments are subject to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region." NB: prohibition on sub-assignment now made explicit.
Nick
Hi, Agree with Nick. I support this proposal to make first ASN assignment easier to LIR end end-user. Also agree that the new policy text could be more general and not too operational specific. *"any additional ASN must be justified and actively used,"* Rinse On 20-5-2025 14:24, Nick Hilliard wrote:
Angela Dall'Ara wrote on 06/05/2025 12:50:
We encourage you to review this proposal and send your comments to address-policy-wg@ripe.net before 4 June 2025.
The overall aims look ok, but the proposed policy is (in my opinion) too prescriptive about operational details.
As a general comment about policy creation, policy should aim towards stating principles about what-should-be-done, and for the most part should leave the details of how-to-do-it to the procedure manual. There's a bunch of reasons for this, not least being able to deal with procedural abuse, bearing in mind that the implementation time for plugging policy holes is measured in double-digit months or years.
Zooming out, the policy is:
- first ASN: on request - subsequent ASNs: stated need
Can I suggest something based on the following text:
2.0 Assignment Criteria
LIRs and End Users may be issued a first Autonomous System Number (ASN) upon request.
LIRs and End Users may be issued an additional ASN or ASNs if the LIR or End User can provide documented justification for the unique external routing policy for the ASN application. The uniqueness of the routing policy includes the announced prefixes. The LIRs or End Users must demonstrate fulfillment of the criteria for which the application was approved within six months of the ASN being assigned.
The RIPE NCC will assign the AS Number directly to the End User upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR. Autonomous System Numbers may not be sub-assigned. AS Number assignments are subject to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region." NB: prohibition on sub-assignment now made explicit.
Nick
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Dear colleagues, As the discussion phase for this policy proposal continues for one more week, and in agreement with the authors, I would like to invite further input on a specific point that has been discussed previously. The proposal aims to strike a balance by allowing straightforward access to a first ASN while also helping to prevent unnecessary requests for additional ASNs without valid technical justification. Currently, the draft policy states that the first ASN can be assigned without justification, while additional ASNs would depend on the fulfilment of criteria and up-to-date documentation for existing ASNs. This raises a question: if no justification is required for the first ASN, how should it be considered when evaluating subsequent requests? In preparation for the RIPE NCC’s upcoming impact analysis (if the proposer and WG co-chairs would decide to move the proposal to the next phase) and potentially to help the authors for a new version, we would welcome your views on this matter. There are at least two possible approaches: - The first ASN remains exempt from any criteria now or in the future, or - The first ASN is evaluated retrospectively, for example once an additional ASN request is made. Thanks in advance for your input. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC On 21/05/2025 08:57, Rinse Kloek wrote:
Hi,
Agree with Nick. I support this proposal to make first ASN assignment easier to LIR end end-user. Also agree that the new policy text could be more general and not too operational specific. *"any additional ASN must be justified and actively used,"*
Rinse
On 20-5-2025 14:24, Nick Hilliard wrote:
Angela Dall'Ara wrote on 06/05/2025 12:50:
We encourage you to review this proposal and send your comments to address-policy-wg@ripe.net before 4 June 2025.
The overall aims look ok, but the proposed policy is (in my opinion) too prescriptive about operational details.
As a general comment about policy creation, policy should aim towards stating principles about what-should-be-done, and for the most part should leave the details of how-to-do-it to the procedure manual. There's a bunch of reasons for this, not least being able to deal with procedural abuse, bearing in mind that the implementation time for plugging policy holes is measured in double-digit months or years.
Zooming out, the policy is:
- first ASN: on request - subsequent ASNs: stated need
Can I suggest something based on the following text:
2.0 Assignment Criteria
LIRs and End Users may be issued a first Autonomous System Number (ASN) upon request.
LIRs and End Users may be issued an additional ASN or ASNs if the LIR or End User can provide documented justification for the unique external routing policy for the ASN application. The uniqueness of the routing policy includes the announced prefixes. The LIRs or End Users must demonstrate fulfillment of the criteria for which the application was approved within six months of the ASN being assigned.
The RIPE NCC will assign the AS Number directly to the End User upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR. Autonomous System Numbers may not be sub-assigned. AS Number assignments are subject to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region." NB: prohibition on sub-assignment now made explicit.
Nick
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
----- To unsubscribe from this mailing list or change your subscription options, please visit:https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at:https://www.ripe.net/membership/mail/mailman-3-migration/
Hi, "The first ASN remains exempt from any criteria now or in the future" This is the approach i prefer. However, the evaluation of subsequent ASNs can consider if the "first ASN" is/was in use or not, but this shouldn't affect the first ASN's assignment itself. Cheers, Carlos On Wed, 28 May 2025, Marco Schmidt wrote:
Dear colleagues,
As the discussion phase for this policy proposal continues for one more week, and in agreement with the authors, I would like to invite further input on a specific point that has been discussed previously.
The proposal aims to strike a balance by allowing straightforward access to a first ASN while also helping to prevent unnecessary requests for additional ASNs without valid technical justification. Currently, the draft policy states that the first ASN can be assigned without justification, while additional ASNs would depend on the fulfilment of criteria and up-to-date documentation for existing ASNs.
This raises a question: if no justification is required for the first ASN, how should it be considered when evaluating subsequent requests?
In preparation for the RIPE NCC?s upcoming impact analysis (if the proposer and WG co-chairs would decide to move the proposal to the next phase) and potentially to help the authors for a new version, we would welcome your views on this matter. There are at least two possible approaches:
- The first ASN remains exempt from any criteria now or in the future, or
- The first ASN is evaluated retrospectively, for example once an additional ASN request is made.
Thanks in advance for your input.
Kind regards, Marco Schmidt Manager Registration Services RIPE NCC
On 21/05/2025 08:57, Rinse Kloek wrote: Hi,
Agree with Nick. I support this proposal to make first ASN assignment easier to LIR end end-user. Also agree that the new policy text could be more general and not too operational specific. "any additional ASN must be justified and actively used,"
Rinse
On 20-5-2025 14:24, Nick Hilliard wrote: Angela Dall'Ara wrote on 06/05/2025 12:50: We encourage you to review this proposal and send your comments to address-policy-wg@ripe.net before 4 June 2025.
The overall aims look ok, but the proposed policy is (in my opinion) too prescriptive about operational details.
As a general comment about policy creation, policy should aim towards stating principles about what-should-be-done, and for the most part should leave the details of how-to-do-it to the procedure manual. There's a bunch of reasons for this, not least being able to deal with procedural abuse, bearing in mind that the implementation time for plugging policy holes is measured in double-digit months or years.
Zooming out, the policy is:
- first ASN: on request - subsequent ASNs: stated need
Can I suggest something based on the following text:
2.0 Assignment Criteria
LIRs and End Users may be issued a first Autonomous System Number (ASN) upon request.
LIRs and End Users may be issued an additional ASN or ASNs if the LIR or End User can provide documented justification for the unique external routing policy for the ASN application. The uniqueness of the routing policy includes the announced prefixes. The LIRs or End Users must demonstrate fulfillment of the criteria for which the application was approved within six months of the ASN being assigned.
The RIPE NCC will assign the AS Number directly to the End User upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR. Autonomous System Numbers may not be sub-assigned. AS Number assignments are subject to the policies described in the RIPE NCC document entitled ?Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region."
NB: prohibition on sub-assignment now made explicit.
Nick
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address -policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change you r settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Hi, On Wed, May 28, 2025 at 02:50:42PM +0200, Marco Schmidt wrote:
- The first ASN remains exempt from any criteria now or in the future, or
- The first ASN is evaluated retrospectively, for example once an additional ASN request is made.
This is a nontrivial question. Basically it boils down to "so, thanks for your second ASN request, but why are you not using the ASN you already have for it?" - which the policy requires ("different policy"). So if the first ASN is basically unused and/or not visible, "I want to announce 192.0.2.0/24 from the second ASN, and I'm not using the first for anything" is, technically, "a different routing policy". Marco, the way you phrase it ("is evaluated retrospectively") has the ring of "if you ask for a second ASN, and have no good arguments, we take the first one away" - which is not such a good message to send. Maybe something long the lines "for subsequent ASNs, the requestor needs to document why existing ASNs can not be used"? There is some leeway in evaluating, and it might spur the requestor into actually thinking "why can I not use one of the ones I already have?" - writing down a reason often helps in reconsidering what one really wants :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler 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 Sun, Jun 1, 2025 at 4:56 AM Gert Doering <gert@space.net> wrote:
Hi,
On Wed, May 28, 2025 at 02:50:42PM +0200, Marco Schmidt wrote:
- The first ASN remains exempt from any criteria now or in the future, or
- The first ASN is evaluated retrospectively, for example once an additional ASN request is made.
This is a nontrivial question.
Basically it boils down to "so, thanks for your second ASN request, but why are you not using the ASN you already have for it?" - which the policy requires ("different policy"). So if the first ASN is basically unused and/or not visible, "I want to announce 192.0.2.0/24 from the second ASN, and I'm not using the first for anything" is, technically, "a different routing policy".
Marco, the way you phrase it ("is evaluated retrospectively") has the ring of "if you ask for a second ASN, and have no good arguments, we take the first one away" - which is not such a good message to send.
Maybe something long the lines "for subsequent ASNs, the requestor needs to document why existing ASNs can not be used"? There is some leeway in evaluating, and it might spur the requestor into actually thinking "why can I not use one of the ones I already have?" - writing down a reason often helps in reconsidering what one really wants :-)
When requesting an additional ASN, asking how your current ASNs are used doesn't seem unreasonable. Your old ASNs would not be reclaimed if they are not being used. However, the new request should be denied if you already have an unused ASN that could be used instead of requesting an additional ASN. Thanks -- =============================================== David Farmer Email:farmer@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 ===============================================
Hi, On Sun, Jun 01, 2025 at 09:43:31AM -0500, David Farmer wrote:
Maybe something long the lines "for subsequent ASNs, the requestor needs to document why existing ASNs can not be used"? There is some leeway in evaluating, and it might spur the requestor into actually thinking "why can I not use one of the ones I already have?" - writing down a reason often helps in reconsidering what one really wants :-)
When requesting an additional ASN, asking how your current ASNs are used doesn't seem unreasonable. Your old ASNs would not be reclaimed if they are not being used. However, the new request should be denied if you already have an unused ASN that could be used instead of requesting an additional ASN.
This is along the lines I was thinking, so, this would work for me :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, Yes, i also agree with this approach. Regards, Carlos On Sun, 1 Jun 2025, Gert Doering wrote:
Hi,
On Sun, Jun 01, 2025 at 09:43:31AM -0500, David Farmer wrote:
Maybe something long the lines "for subsequent ASNs, the requestor needs to document why existing ASNs can not be used"? There is some leeway in evaluating, and it might spur the requestor into actually thinking "why can I not use one of the ones I already have?" - writing down a reason often helps in reconsidering what one really wants :-)
When requesting an additional ASN, asking how your current ASNs are used doesn't seem unreasonable. Your old ASNs would not be reclaimed if they are not being used. However, the new request should be denied if you already have an unused ASN that could be used instead of requesting an additional ASN.
This is along the lines I was thinking, so, this would work for me :-)
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hello, Thank you for the feedback shared so far. Just to clarify, my intention with the question was not to suggest revoking the initial AS Number assignment, but rather to understand how that initial ASN should be considered in the evaluation of a subsequent request. Based your input received so far, it seems there is support for taking the existing ASN into account when deciding on the provision of an additional ASN. From a resource management perspective, this approach would be reasonable. If the proposal reaches consensus in its current form or a similar version, the RIPE NCC would likely need to take steps to raise awareness about this aspect to avoid confusion or delays during future requests. Some requesters may not expect to provide information about an ASN that was assigned previously without any justification. Thanks again, and please don’t hesitate to let us know if the RIPE NCC can offer any input to help with this proposal discussion. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC On 02/06/2025 09:16, Carlos Friaças via address-policy-wg wrote:
Hi,
Yes, i also agree with this approach.
Regards, Carlos
On Sun, 1 Jun 2025, Gert Doering wrote:
Hi,
On Sun, Jun 01, 2025 at 09:43:31AM -0500, David Farmer wrote:
Maybe something long the lines "for subsequent ASNs, the requestor needs to document why existing ASNs can not be used"? There is some leeway in evaluating, and it might spur the requestor into actually thinking "why can I not use one of the ones I already have?" - writing down a reason often helps in reconsidering what one really wants :-)
When requesting an additional ASN, asking how your current ASNs are used doesn't seem unreasonable. Your old ASNs would not be reclaimed if they are not being used. However, the new request should be denied if you already have an unused ASN that could be used instead of requesting an additional ASN.
This is along the lines I was thinking, so, this would work for me :-)
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Gert Doering wrote on 01/06/2025 16:08:
On Sun, Jun 01, 2025 at 09:43:31AM -0500, David Farmer wrote:
Maybe something long the lines "for subsequent ASNs, the requestor needs to document why existing ASNs can not be used"? There is some leeway in evaluating, and it might spur the requestor into actually thinking "why can I not use one of the ones I already have?" - writing down a reason often helps in reconsidering what one really wants :-) When requesting an additional ASN, asking how your current ASNs are used doesn't seem unreasonable. Your old ASNs would not be reclaimed if they are not being used. However, the new request should be denied if you already have an unused ASN that could be used instead of requesting an additional ASN. This is along the lines I was thinking, so, this would work for me :-)
In theory this is an improvement, but it would also stop organisations from requesting multiple ASNs if they had a legitimate requirement for multiple ASNs. Nick
Good morning, please keep in mind that use cases such as GRX (GSM Roaming Exchange) and of course IXP route servers do exist which require a unique ASN but do not ever show up in the DFZ. Thanks Max On 03 June, 2025 17:59 CEST, Nick Hilliard <nick@foobar.org> wrote: Gert Doering wrote on 01/06/2025 16:08:On Sun, Jun 01, 2025 at 09:43:31AM -0500, David Farmer wrote: Maybe something long the lines "for subsequent ASNs, the requestor needs to document why existing ASNs can not be used"? There is some leeway in evaluating, and it might spur the requestor into actually thinking "why can I not use one of the ones I already have?" - writing down a reason often helps in reconsidering what one really wants :-) When requesting an additional ASN, asking how your current ASNs are used doesn't seem unreasonable. Your old ASNs would not be reclaimed if they are not being used. However, the new request should be denied if you already have an unused ASN that could be used instead of requesting an additional ASN. This is along the lines I was thinking, so, this would work for me :-) In theory this is an improvement, but it would also stop organisations from requesting multiple ASNs if they had a legitimate requirement for multiple ASNs. Nick
Hi, Thank you everyone for your comments. The official discussion phase has concluded We will go through all the comments and recollect out thoughts. There will be a new version of this policy and a new official discussion phase. In the mean time, you are free to continue the (unofficial) discussion in this thread. We will try to include your concerns if we can. Best, Urban
participants (9)
-
Angela Dall'Ara -
Carlos Friaças -
David Farmer -
Gert Doering -
Marco Schmidt -
Max Emig -
Nick Hilliard -
Rinse Kloek -
Urban Suhadolnik