DRAFT ASN assignment critera revisited
Dear Colleagues, Following RIPE 89 Address policy WG, I was asked to prepare a new policy for ASN assignment criteria together with Tobias. We've compared the ASN assignment criteria at other RIRs, current proposals at other RIR and followed various conversations at RIPE community events. After some internal feedback from Alex, Leo and PDO we feel that this draft is ready for the mailing list. I would like to ask all of you for feedback on the proposal and on the text of the proposal. Best, Urban and Tobias _____________________________ Summary of Proposal This policy proposal changes the requirements for ASN assignments. Under the new policy, any organization or LIR (in case of multiple LIR per ASN) may request a single ASN without justification. Additional ASNs can be assigned if the requester provides a unique external routing policy and demonstrates peering with a third party. The proposed changes reflect the reality that the current requirements are unenforceable in practice [1] and that ASNs are no longer a scarce resource since the complete introduction and global acceptance of 32-bit ASNs. The aim of this policy is to simplify requirements for new ASN, while making the requirements enforceable in practice and avoiding exponential burn of 32bit ASN space. [1] - Personal ASN Open House Recap - RIPE NCC - Page 5 https://ripe89.ripe.net/wp-content/uploads/presentations/88-Personal-ASN.pdf <https://ripe89.ripe.net/wp-content/uploads/presentations/88-Personal-ASN.pdf> Policy text: Current policy text *2.0 Assignment Criteria* In order to help decrease global routing complexity, a new AS Number should be used only if a new external routing policy is required, see RFC1930. A network must be multihomed in order to qualify for an AS Number. When requesting an AS Number, the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database. 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. 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”. New policy text *2.0 Assignment Criteria* Any organization OR LIR, in case an organization has more than one LIR, may be issued a single Autonomous System Number (ASN) upon request. Organizations and LIRs may be issued additional ASNs. Requirements for additional ASNs are: * Unique external routing policy of the Autonomous System must be provided. The uniqueness of the routing policy includes the announced prefixes. * Autonomous System must peer with a third party. When requesting an AS Number to be visible in the GRT, the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database. Otherwise, documentation on the non-visible purpose, e.g., a reference to the assigned IXP LAN prefixes, must be provided. Reasonable periodic use cases MAY be allowed. A benefit statement for such MUST be provided. The requester has 6 months after the ASN has been issued to fulfil the criteria for which the application was approved. Approval of an additional ASN MAY depend on fulfilment of criteria and up-to-date documentation on existing ASNs. In case of an ASN visible in the GRT, RIPE NCC confirms that the ASN fulfils the criteria by checking publicly visible state in the GRT. In case of off-GRT ASN, RIPE NCC may ask for operational proof of fulfilling the criteria. Failing to provide sufficient proof is considered as not fulfilling the criteria. 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. 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." Rationale There are valid technical reasons for having a single homed ASN. BGP and RPSL has appeared to be a very robust way of exchanging routing information. Schemes where customer's have their own IP space would benefit by using a dedicated ASN to communicate routing information over BGP. Conservation measures currently implemented are not really helpful anymore. They reduce visibility and make operating and troubleshooting of networks more complex. Arguments supporting the proposal Four octet (32 bit) ASNs were defined in May 2007 in RFC 4893. It has taken several years for routing equipment in general use to catch up, but with 32 bit AS numbers, ASN are not a scarce resource anymore. IANA has assigned 402332 ASN to RIRs which is ~0.01 % of available 32 bit ASN space. While RIRs have assigned only around, 88400 to network operators, which represents ~0,002 % of available 32 bit ASN. Our policies should reflect that, and we should utilize number resources in such a way to help network operators reduce operational complexity and increase visibility for operating and troubleshooting networks. Lastly, the current ASN requirements have appeared to be unenforceable in practice. Many AS start by fulfilling the multihomed requirement, but then turn single-homed over time, while others have never become multihomed in the first place. Half of allocated ASN by RIPE don't fulfil the requirements [1] This proposal removes the requirement for the first Autonomous System Number for an organisation or LIR (in case an organisation has more than one LIR) and introduces a set of requirements that are reasonable, will not deplete the pool of available ASN and be enforceable for RIPE NCC. [1] - Personal ASN Open House Recap - RIPE NCC - Page 5 https://ripe89.ripe.net/wp-content/uploads/presentations/88-Personal-ASN.pdf <https://ripe89.ripe.net/wp-content/uploads/presentations/88-Personal-ASN.pdf> Arguments against the proposal Simplified availability of ASN will result in an increase of Autonomous Systems on the GRT. While depletion of available ASN will not be a problem in the foreseeable future, there could be an increase of complexity of the GRT which will increase the requirements on processing power and memory of network equipment. Counterarguments: * An increase of Autonomous systems might not have as big of effect on hardware requirements as one might think at first. Conservation measures for cases presented in RFC1930 and RFC2280 and others conserve only the AS number, and do not conserve the processing power and memory needed to process the announced prefixes. When a foreign prefix (e.g. PI) as announced (via e.g. private ASN) from an AS (e.g. ISP) it still creates a separate entry in the routing table. * This policy shouldn't cause any significant increase of complexity of GRT, because best practices from RFC1930 were not used. New technologies built on easy availability of AS numbers could exponentially increase the request rate for new AS numbers Counterarguments: * New RIPE NCC fees, particularly "per ASN" fee, mitigates this to some extent. However, current per ASN fee of 50€, would in practice not stop such technology from being developed based on cost alone. On the other hand, an increase of fees would jeopardize small and private ASN end-users. Risk of mass (hundreds or thousands) ASN requests exist. The effect of this policy should be reviewed within a reasonable timeframe after implementing.
hi, excuse, even slower than usual here due to persistent jet lag. assume for the moment that the ncc reg services folk are genetically averse to making judgement calls let they be accused of, i don't know, making judgement calls. so, given a large blob of rpsl, it might help if you would outline the explicit criteria the reg services folk would use to decide if an nth asn is justified? randy
after more coffee :)
so, given a large blob of rpsl, it might help if you would outline the explicit criteria the reg services folk would use to decide if an nth asn is justified?
to maybe be a bit clearer, or at least say it a different way, you seem to have chosen a syntax ( from the 1990s :) but have not made the semantics clear enough that i can understand them. likely my fault, of course. randy
Moin,
to maybe be a bit clearer, or at least say it a different way, you seemto have chosen a syntax ( from the 1990s :) but have not made the semantics clear enough that i can understand them. likely my fault, of course.
That bit actually carried over from the current policy. Interestingly (despite being from the 90s) i do not see 'rpsl' in the text before RIPE-496 (2010); 496 was the first revision of a policy in an effort "aimed at improving the clarity and readability" [1]. So... what do you propose... take RPSL out and replace with more words describing what is inteded? With best regards, Tobias [1] https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/message/MH...
to maybe be a bit clearer, or at least say it a different way, you seemto have chosen a syntax ( from the 1990s :) but have not made the semantics clear enough that i can understand them. likely my fault, of course.
That bit actually carried over from the current policy. Interestingly (despite being from the 90s) i do not see 'rpsl' in the text before RIPE-496 (2010); 496 was the first revision of a policy in an effort "aimed at improving the clarity and readability" [1].
So... what do you propose... take RPSL out and replace with more words describing what is inteded?
i can live with the syntax from the '90s; though it was over-designed for goals it almost never achieved, automating router configuration. but you "have not made the semantics clear enough that i can understand them." please describe the criteria or algorithm the regserv person is to apply to that blob of rpsl which produces the number of asns to be assigned. randy
Moin,
but you "have not made the semantics clear enough that i can understand them."
please describe the criteria or algorithm the regserv person is to apply to that blob of rpsl which produces the number of asns to be assigned.
This part of the text is carried over in verbatim from the current policy. Technically, a new proposal _could_ try to address this by: - Providing further semantics for this specific aspects - Revising the text to not rely on the link to RPSL However, in both cases, we'd scope creep this proposal. With best regards, Tobias
Moin,
then why do we need a new policy? To make one change at a time (+the directly necessary things following from that). In this case: Removal of the dual-homing requirement, because it no longer reflects the operational realities of ASN use.
you like rpsl? RPSL is best when you replace it with ASPA right before delivery.
But I would argue that this change (esp. given that it was introduced by the NCC to 'simplify' things) should be its own proposal, given the complexity it pulls in. With best regards, Tobias
please describe the criteria or algorithm the regserv person is to apply to that blob of rpsl which produces the number of asns to be assigned. This part of the text is carried over in verbatim from the current policy. then why do we need a new policy? To make one change at a time (+the directly necessary things following from that). In this case: Removal of the dual-homing requirement, because it no longer reflects the operational realities of ASN use.
two changes: i suspect (though you have not actually specified) that i now need to publish rpsl revealing my relationships, and you propose to remove the requirement for multi-homing. how does the regserv person tell from the rpsl how many asns your [singly homed] router needs? one, two, 42? are there a bunch of aut-num:s? an as-set:? perhaps my confusion is exacerbated by your choosing to use a data description from the '90s, but want to obsolete RFC 1930. :) but whether a raspberry pi on decix can have 42 asns because it can be described in rpsl is not a hill i particulatly want to climb, let alone die on. my concern is that policies be simple, clear, understandable, and easily implemented by the operator and by the regserv folk. randy
two changes: One change.
i suspect (though you have not actually specified) that i now need to publish rpsl revealing my relationships,
We. Do. Not. The policy _currently_, meaning, as it is published and implemented _right now_, states: "When requesting an AS Number, the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database." This is a change from 2010, implemented by the NCC, to make the policy easier to understand. The proposed change does the following: - Add " to be visible in the GRT" after "When requesting an AS Number", because _technically_ the current policy prohibits any assignment of an ASN that is _not_ used in a GRT visible way, unless you can also provide an RPSL description of that non-visible use. - Add the sentence "Otherwise, documentation on the non-visible purpose, e.g., a reference to the assigned IXP LAN prefixes, must be provided." afterwards, to still require _some_ documentation if you, e.g., want to run an IXP. What you suspect--having to publish RPSL revealing your relationships-- is the case since 2010. That is the reason why we enter (two) ASNs when requesting an ASN. That is the reason why the NCC auto-generates some rather oversimplified RPSL from those two entries. That is the reason why there is a button saying "I want to provide a more complex routing policy in RPSL" when requesting an ASN.
and you propose to remove the requirement for multi-homing. That we do.
how does the regserv person tell from the rpsl how many asns your [singly homed] router needs? one, two, 42? are there a bunch of aut-num:s? an as-set:?
I guess the same way they do now, given that this policy is in place for roughly 15 years. With the additional simplification, that the unique routing policy now explicitly includes the announced prefixes, i.e., if you announce different prefixes and the AS is connected to a third party, that is a rather strong indication: """ - Unique external routing policy of the Autonomous System must be provided. The uniqueness of the routing policy includes the announced prefixes. - Autonomous System must peer with a third party. """
perhaps my confusion is exacerbated by your choosing to use a data description from the '90s, but want to obsolete RFC 1930. :)
See above. We are not 'choosing' this language. We are leaving it in place. And we are not obsoleting RFC1930, given we are not GROW. (Then again, THAT is also not the worst idea. Let me drop an email to that list as well.)
but whether a raspberry pi on decix can have 42 asns because it can be described in rpsl is not a hill i particulatly want to climb, let alone die on.
Yet here we are, standing atop together.
my concern is that policies be simple, clear, understandable, and easily implemented by the operator and by the regserv folk.
I can agree with that. And I can only reiterate that the language you are concerned about has been added by the NCC in 2010 to make the policy more "simple, clear, understandable, and easily implemented by the operator and by the regserv folk"; It is certainly an... interesting... way to simplify, but hey... I'm not judging. With best regards, Tobias
apologies. my bad. i have only asked for experimentals asns in the last forever. and i did not look at current policy. randy
So the only criterion for being granted an ASN is how we announce the IP ranges ie. The routing? There are other valid reasons why a company might need to have different ASNs based on how they manage their network(s) which should be catered for. -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours. From: Urban Suhadolnik via address-policy-wg <address-policy-wg@ripe.net> Date: Saturday, 29 March 2025 at 10:44 To: address-policy-wg@ripe.net <address-policy-wg@ripe.net> Cc: tfiebig@mpi-inf.mpg.de <tfiebig@mpi-inf.mpg.de> Subject: [address-policy-wg] DRAFT ASN assignment critera revisited [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. Dear Colleagues, Following RIPE 89 Address policy WG, I was asked to prepare a new policy for ASN assignment criteria together with Tobias. We've compared the ASN assignment criteria at other RIRs, current proposals at other RIR and followed various conversations at RIPE community events. After some internal feedback from Alex, Leo and PDO we feel that this draft is ready for the mailing list. I would like to ask all of you for feedback on the proposal and on the text of the proposal. Best, Urban and Tobias _____________________________ Summary of Proposal This policy proposal changes the requirements for ASN assignments. Under the new policy, any organization or LIR (in case of multiple LIR per ASN) may request a single ASN without justification. Additional ASNs can be assigned if the requester provides a unique external routing policy and demonstrates peering with a third party. The proposed changes reflect the reality that the current requirements are unenforceable in practice [1] and that ASNs are no longer a scarce resource since the complete introduction and global acceptance of 32-bit ASNs. The aim of this policy is to simplify requirements for new ASN, while making the requirements enforceable in practice and avoiding exponential burn of 32bit ASN space. [1] - Personal ASN Open House Recap - RIPE NCC - Page 5 https://ripe89.ripe.net/wp-content/uploads/presentations/88-Personal-ASN.pdf Policy text: Current policy text 2.0 Assignment Criteria In order to help decrease global routing complexity, a new AS Number should be used only if a new external routing policy is required, see RFC1930. A network must be multihomed in order to qualify for an AS Number. When requesting an AS Number, the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database. 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. 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”. New policy text 2.0 Assignment Criteria Any organization OR LIR, in case an organization has more than one LIR, may be issued a single Autonomous System Number (ASN) upon request. Organizations and LIRs may be issued additional ASNs. Requirements for additional ASNs are: * Unique external routing policy of the Autonomous System must be provided. The uniqueness of the routing policy includes the announced prefixes. * Autonomous System must peer with a third party. When requesting an AS Number to be visible in the GRT, the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database. Otherwise, documentation on the non-visible purpose, e.g., a reference to the assigned IXP LAN prefixes, must be provided. Reasonable periodic use cases MAY be allowed. A benefit statement for such MUST be provided. The requester has 6 months after the ASN has been issued to fulfil the criteria for which the application was approved. Approval of an additional ASN MAY depend on fulfilment of criteria and up-to-date documentation on existing ASNs. In case of an ASN visible in the GRT, RIPE NCC confirms that the ASN fulfils the criteria by checking publicly visible state in the GRT. In case of off-GRT ASN, RIPE NCC may ask for operational proof of fulfilling the criteria. Failing to provide sufficient proof is considered as not fulfilling the criteria. 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. 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." Rationale There are valid technical reasons for having a single homed ASN. BGP and RPSL has appeared to be a very robust way of exchanging routing information. Schemes where customer's have their own IP space would benefit by using a dedicated ASN to communicate routing information over BGP. Conservation measures currently implemented are not really helpful anymore. They reduce visibility and make operating and troubleshooting of networks more complex. Arguments supporting the proposal Four octet (32 bit) ASNs were defined in May 2007 in RFC 4893. It has taken several years for routing equipment in general use to catch up, but with 32 bit AS numbers, ASN are not a scarce resource anymore. IANA has assigned 402332 ASN to RIRs which is ~0.01 % of available 32 bit ASN space. While RIRs have assigned only around, 88400 to network operators, which represents ~0,002 % of available 32 bit ASN. Our policies should reflect that, and we should utilize number resources in such a way to help network operators reduce operational complexity and increase visibility for operating and troubleshooting networks. Lastly, the current ASN requirements have appeared to be unenforceable in practice. Many AS start by fulfilling the multihomed requirement, but then turn single-homed over time, while others have never become multihomed in the first place. Half of allocated ASN by RIPE don't fulfil the requirements [1] This proposal removes the requirement for the first Autonomous System Number for an organisation or LIR (in case an organisation has more than one LIR) and introduces a set of requirements that are reasonable, will not deplete the pool of available ASN and be enforceable for RIPE NCC. [1] - Personal ASN Open House Recap - RIPE NCC - Page 5 https://ripe89.ripe.net/wp-content/uploads/presentations/88-Personal-ASN.pdf Arguments against the proposal Simplified availability of ASN will result in an increase of Autonomous Systems on the GRT. While depletion of available ASN will not be a problem in the foreseeable future, there could be an increase of complexity of the GRT which will increase the requirements on processing power and memory of network equipment. Counterarguments: * An increase of Autonomous systems might not have as big of effect on hardware requirements as one might think at first. Conservation measures for cases presented in RFC1930 and RFC2280 and others conserve only the AS number, and do not conserve the processing power and memory needed to process the announced prefixes. When a foreign prefix (e.g. PI) as announced (via e.g. private ASN) from an AS (e.g. ISP) it still creates a separate entry in the routing table. * This policy shouldn't cause any significant increase of complexity of GRT, because best practices from RFC1930 were not used. New technologies built on easy availability of AS numbers could exponentially increase the request rate for new AS numbers Counterarguments: * New RIPE NCC fees, particularly "per ASN" fee, mitigates this to some extent. However, current per ASN fee of 50€, would in practice not stop such technology from being developed based on cost alone. On the other hand, an increase of fees would jeopardize small and private ASN end-users. Risk of mass (hundreds or thousands) ASN requests exist. The effect of this policy should be reviewed within a reasonable timeframe after implementing.
Hi, On Mon, Mar 31, 2025 at 10:33:30AM +0000, Michele Neylon - Blacknight via address-policy-wg wrote:
There are other valid reasons why a company might need to have different ASNs based on how they manage their network(s) which should be catered for.
This is a bit too handwavy to base policy on. Can you give examples? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, 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
Well we have ASNs for our hosting and others for our fibre / connectivity On 31/03/2025, 11:35, "Gert Doering" <gert@space.net> wrote: Hi, On Mon, Mar 31, 2025 at 10:33:30AM +0000, Michele Neylon - Blacknight via address-policy-wg wrote:
There are other valid reasons why a company might need to have different ASNs based on how they manage their network(s) which should be catered for.
This is a bit too handwavy to base policy on. Can you give examples? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, 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 -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours.
Hi, On Mon, Mar 31, 2025 at 10:39:37AM +0000, Michele Neylon - Blacknight wrote:
Well we have ASNs for our hosting and others for our fibre / connectivity
Isn't that a "routing reason", effectively? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, 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
Gert Not with the way the current text is worded. Regards Michele On 31/03/2025, 11:54, "Gert Doering" <gert@space.net> wrote: Hi, On Mon, Mar 31, 2025 at 10:39:37AM +0000, Michele Neylon - Blacknight wrote:
Well we have ASNs for our hosting and others for our fibre / connectivity
Isn't that a "routing reason", effectively? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, 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 -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours.
Hi, On Mon, Mar 31, 2025 at 10:56:15AM +0000, Michele Neylon - Blacknight wrote:
Not with the way the current text is worded.
Suggest wording that would work for you? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, 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 Michelle,
Not with the way the current text is worded.
I fail to see how the current policy text would prohibit assignment of more than one ASN in the case you describe? I would assume the ASes you listed do in fact announce different prefixes? With best regards, Tobias
They might be, they might not. As currently worded they’d have to, which is not ideal. -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours. From: Tobias Fiebig via address-policy-wg <address-policy-wg@ripe.net> Date: Monday, 31 March 2025 at 15:35 To: address-policy-wg@ripe.net <address-policy-wg@ripe.net> Subject: [address-policy-wg] Re: DRAFT ASN assignment critera revisited [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. Hello Michelle,
Not with the way the current text is worded.
I fail to see how the current policy text would prohibit assignment of more than one ASN in the case you describe? I would assume the ASes you listed do in fact announce different prefixes? With best regards, Tobias ----- 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/
Moin, On Mon, 2025-03-31 at 14:43 +0000, Michele Neylon - Blacknight wrote:
They might be, they might not. As currently worded they’d have to, which is not ideal.
So, you'd argue that it would be better to explicitly allow MOAS? With best regards, Tobias
Hi, Urban, all – You wrote:
Following RIPE 89 Address policy WG, I was asked to prepare a new policy for ASN assignment criteria together with Tobias. […] New policy text 2.0 Assignment Criteria Any organization OR LIR, in case an organization has more than one LIR, may be issued a single Autonomous System Number (ASN) upon request.
Please forgive my elementary question – the request for you to complete this work was not recorded in the draft minutes [0] so I am not sure of the context of this proposed policy change. Is this related to the personal ASN debate (item F)? Could the NCC provide some data on how many ASN request tickets are turned down? Andy [0] https://www.ripe.net/community/wg/active-wg/ap/minutes/ripe-89-address-polic...
Dear Andy and colleagues, On 31/03/2025 14:11, Andy Davidson wrote:
Could the NCC provide some data on how many ASN request tickets are turned down?
I'm happy to answer your question regarding Autonomous System Number (ASN) requests processed by the RIPE NCC. In 2024, the RIPE NCC received 2,563 ASN requests and issued 2,205 ASNs. However, there are a few factors to consider: - Not all requests received in 2024 were approved within the same year, and some ASNs assigned in 2024 were for requests submitted in the previous year. However, these effects likely balance out. - More importantly, the RIPE NCC very rarely turns down requests. Instead, requesters often abandon their requests after we ask for additional information. This can be due to policy-related reasons, compliance issues (e.g., missing registration papers), or simply a change of mind. Since many requesters stop responding, the exact reasons are not known to the RIPE NCC. I just want to clarify that the difference of around 350 between requests and ASN assignments should not be misinterpreted as the number of requests actively turned down by the RIPE NCC. I hope this information is helpful for the discussion. Kind regards, Marco Schmidt Manager Registration Services
On 31 Mar 2025, at 14:32, Marco Schmidt <mschmidt@ripe.net> wrote:
More importantly, the RIPE NCC very rarely turns down requests. Instead, requesters often abandon their requests after we ask for additional information. This can be due to policy-related reasons, compliance issues (e.g., missing registration papers), or simply a change of mind. Since many requesters stop responding, the exact reasons are not known to the RIPE NCC.
Thank you, Marco, for providing this insight which is useful. It strikes me that the goals of the proposal are already met by the policy in place? Surely nothing to fix here? Andy
Moin,
It strikes me that the goals of the proposal are already met by the policy in place? Surely nothing to fix here?
The key-change is the removal of the dual-homing requirement. With best regards, Tobias
Hi, On 31. 03. 2025 18:43, Andy Davidson wrote:
On 31 Mar 2025, at 14:32, Marco Schmidt<mschmidt@ripe.net> wrote:
More importantly, the RIPE NCC very rarely turns down requests. Instead, requesters often abandon their requests after we ask for additional information. This can be due to policy-related reasons, compliance issues (e.g., missing registration papers), or simply a change of mind. Since many requesters stop responding, the exact reasons are not known to the RIPE NCC. Thank you, Marco, for providing this insight which is useful.
It strikes me that the goals of the proposal are already met by the policy in place? Surely nothing to fix here?
It is true that single-homed AS are the norm (in RIPE), but that is not what the policy says. The policy is not enforced and many ASN are acquired by lying in the ASN request (confirmed and practiced by many people) or being very lax on the multihomeing requirement (we are multihomeing this customer to two points in our AS... wink... wink...). The problem with the current policy is that ASN numbers are "freely" available only to people that know that they can lie. Furthermore, the documentation in the RIPE database is not accurate because of this. The intent behind the new text is to acknowledge the current state and recognize that with 32bit ASN this particularly bad. With this proposal, you can request an ASN to for any customer that has a reason to do BGP. This is inspired by the new policy at ARIN. Secondly, RIPE NCC _will not_ tear down any networks. That's why more then 50% of allocated ASN don't follow the policy. The new text attempts to enforce the policy at the next ASN request (or regular audit). Hoping for an update of the RIPE database and other documentation to the current actual status. Your specific use case of a company with diverse branches and not run as a single AS e.g. SpaceX - company network / Starlink - ISP or your example: hosting / ISP, is not possible under current policy and RFC 1930 (on which the current policy is based on). Under new text you can peer directly with your upstream or register a new LIR for the hosting branch and get the first ASN with no questions asked. Best, Urban
On Tue, Apr 01, 2025 at 05:17:54PM +0200, Urban Suhadolnik via address-policy-wg wrote:
On 31. 03. 2025 18:43, Andy Davidson wrote:
On 31 Mar 2025, at 14:32, Marco Schmidt<mschmidt@ripe.net> wrote:
More importantly, the RIPE NCC very rarely turns down requests. Instead, requesters often abandon their requests after we ask for additional information. This can be due to policy-related reasons, compliance issues (e.g., missing registration papers), or simply a change of mind. Since many requesters stop responding, the exact reasons are not known to the RIPE NCC.
Thank you, Marco, for providing this insight which is useful.
It strikes me that the goals of the proposal are already met by the policy in place? Surely nothing to fix here?
It is true that single-homed AS are the norm (in RIPE),
Single-homed ASes are the norm? Says who? I'd like us to discuss this a bit more, because as I understand the technology stack, it is incredibly hard (if not impossible) to externally observe with accuracy whether an AS is single-homed or multi-homed. For example, an AS with 1 private peering partner and 1 upstream provider is multi-homed, but RIPE RIS data most likely won't contain data indicative for this private peering adjacency, in RIPE RIS data you'd likely only see the 1 upstream provider, and wrongly conclude the AS is single-homed. Kind regards, Job
To clarify: I'd consider a lacking ability to externally confirm whether an AS is single-homed or multi-homed an argument in favor of removing the policy requirement for multi-homing. Kind regards, Job
Moin, On Tue, 2025-04-01 at 16:05 +0000, Job Snijders wrote:
To clarify: I'd consider a lacking ability to externally confirm whether an AS is single-homed or multi-homed an argument in favor of removing the policy requirement for multi-homing.
Was just going to say... fully agree with Job there. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl Pronouns: he/him/his
Hi Job, On 1. 04. 2025 18:05, Job Snijders wrote:
To clarify: I'd consider a lacking ability to externally confirm whether an AS is single-homed or multi-homed an argument in favor of removing the policy requirement for multi-homing.
Thanks for the feedback. I think we should use this as an argument. Best, Urban
Hello Andy,
Please forgive my elementary question – the request for you to complete this work was not recorded in the draft minutes [0] so I am not sure of the context of this proposed policy change. Is this related to the personal ASN debate (item F)? Could the NCC provide some data on how many ASN request tickets are turned down?
To provide some context here: The "I was asked" was not an item from the WG, but an informal request some people in the community and the chairs, noting that this might be a relevant matter to work on (given that, in practice, the dual-homing requirement ist not overly well observed in practice anyway). Urban was then encouraged to take charge on this and bring this discussion to the ML, along with a first shot at a draft proposal to get a discussion going. With best regards, Tobias
Hi Andy, Tobias already answered, but I think I should answer personally :) Last few RIPE meetings and other RIPE community events there has been a lot of conversation officially on agenda and unofficially at socials/coffee breaks about ASN requirements and multi-homeing. Few people and co-chairs approached me because I was vocal at the microphone. I accepted and Tobias offered to co-author. We've stayed in touch with Alex and Leo who provided feedback. ...and this is the result :) This is the first time the proposed text has seen the light of day. The proposal has not been sent into official proceedings (yet). We are hoping to get some general feedback and feedback (and effect) on use cases that we have not foreseen. Best, Urban On 31. 03. 2025 14:11, Andy Davidson wrote:
Hi, Urban, all –
You wrote:
Following RIPE 89 Address policy WG, I was asked to prepare a
new policy for ASN assignment criteria together with Tobias.
[…]
New policy text
2.0 Assignment Criteria
Any organization OR LIR, in case an organization has more than
one LIR, may be issued a single Autonomous System Number
(ASN) upon request.
Please forgive my elementary question – the request for you to complete this work was not recorded in the draft minutes [0] so I am not sure of the context of this proposed policy change. Is this related to the personal ASN debate (item F)? Could the NCC provide some data on how many ASN request tickets are turned down?
Andy
[0] https://www.ripe.net/community/wg/active-wg/ap/minutes/ripe-89-address-polic...
----- 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, I've just found a mistake in the text.
* An increase of Autonomous systems might not have as big of effect on hardware requirements as one might think at first. Conservation measures for cases presented in RFC1930 and *RFC2280 *and others conserve only the AS number, and do not conserve the processing power and memory needed to process the announced prefixes. When a foreign prefix (e.g. PI) as announced (via e.g. private ASN) from an AS (e.g. ISP) it still creates a separate entry in the routing table.
Instead, I've meant RFC2270.
* An increase of Autonomous systems might not have as big of effect on hardware requirements as one might think at first. Conservation measures for cases presented in RFC1930 and *RFC2270 *and others conserve only the AS number, and do not conserve the processing power and memory needed to process the announced prefixes. When a foreign prefix (e.g. PI) as announced (via e.g. private ASN) from an AS (e.g. ISP) it still creates a separate entry in the routing table.
Best, Urban
participants (8)
-
Andy Davidson -
Gert Doering -
Job Snijders -
Marco Schmidt -
Michele Neylon - Blacknight -
Randy Bush -
Tobias Fiebig -
Urban Suhadolnik