2026-01 New Policy Proposal (Simplify assignment of first ASN)
Dear colleagues, A new RIPE Policy Proposal, 2026-01 "Simplify assignment of first ASN" is now available for discussion. This proposal aims to remove the needs assessment for the first AS Number requested by holders of an IP address prefix assigned or allocated directly by the RIPE NCC. You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2026-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 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@ripe.net before 5 August 2026. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC
On Tue, 7 Jul 2026 at 14:19, Angela Dall'Ara <adallara@ripe.net> wrote:
You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2026-01
This seems like a sensible change to the policy, Thx J -- James Blessing 07989 039 476
+1 i support this change as written. For rationale i agree with Fredy On 7/7/26 3:37 PM, Fredy Künzler wrote:
+1
Please support this propsal, that inventing fake multihoming has an end.
-- Fredy Künzler
Am 07.07.2026 um 15:25 schrieb boggits <boggits@gmail.com>:
On Tue, 7 Jul 2026 at 14:19, Angela Dall'Ara <adallara@ripe.net> wrote:
You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2026-01
This seems like a sensible change to the policy,
Thx
J --
James Blessing 07989 039 476 ----- 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/
On Tue, Jul 07, 2026 at 03:37:58PM +0200, Fredy Künzler wrote:
Please support this propsal, that inventing fake multihoming has an end.
Agreed. But I'd prefer if we keep this one sentence from the old policy: """ 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. """ Rationale for keeping the sentence: even if it is one's first ASN, and even if that first AS also is single-homed (or not), it is helpful to have the routing policy for that AS documented in the RIPE DB. Entire new policy text: """ Legitimate holders of an IP address prefix assigned or allocated directly by the RIPE NCC, may be assigned their first AS Number without providing a needs justification. Additional AS Numbers may only be assigned when a new external routing policy is required for a multihomed network. 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. """ Removing needs justification does not equate removal of documentation obligation. Kind regards, Job
On 7 Jul 2026, at 16:01, Job Snijders via address-policy-wg <address-policy-wg@ripe.net> wrote:
On Tue, Jul 07, 2026 at 03:37:58PM +0200, Fredy Künzler wrote:
Please support this propsal, that inventing fake multihoming has an end.
Agreed.
But I'd prefer if we keep this one sentence from the old policy:
+1 on Job's variant of the proposal. Maybe an additional "MUST also configure ASPA" could be added? The 'arguments opposing' states: "This could speed up the equipment replacement cycle for networks that maintain a view of all other networks." Which is through all networks worldwide that are default-free. This while primarily transit providing networks, that want to have customers, will benefit, though mostly in the "using a registered globally unique ASN" versus "pick a private-space 32-bit ASN, use that, masq that" thus enables customer mobility, and if they can find a secondary transit, move to that transit. This new freedom also avoids having new ASNs take 'free' transit or from a VM, where one prepend everything, but never use the traffic, solely to comply with the current rules. The language of "prefix assigned or allocated directly by the RIPE NCC" is great, as that avoids RIPE NCC ASNs being requested for prefixes in RIPE space, but used for other RIRs that do not have this ASN registration "freedom". Regards, Jeroen
Anno domini 2026 Job Snijders via address-policy-wg scripsit:
On Tue, Jul 07, 2026 at 03:37:58PM +0200, Fredy Künzler wrote:
Please support this propsal, that inventing fake multihoming has an end.
Agreed.
But I'd prefer if we keep this one sentence from the old policy:
""" 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. """
Rationale for keeping the sentence: even if it is one's first ASN, and even if that first AS also is single-homed (or not), it is helpful to have the routing policy for that AS documented in the RIPE DB.
+1 to the proposal with Job's addendum. Best Max
Hi, On Tue, Jul 07, 2026 at 02:01:16PM +0000, Job Snijders via address-policy-wg wrote:
Removing needs justification does not equate removal of documentation obligation.
*like* 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.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
I also support this as written
On 7. Jul 2026, at 15:37, Fredy Künzler <kuenzler@init7.net> wrote:
+1
Please support this propsal, that inventing fake multihoming has an end.
-- Fredy Künzler
Am 07.07.2026 um 15:25 schrieb boggits <boggits@gmail.com>:
On Tue, 7 Jul 2026 at 14:19, Angela Dall'Ara <adallara@ripe.net> wrote:
You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2026-01
-- Wolfgang Tremmel Phone +49 69 1730902 0 | wolfgang.tremmel@de-cix.net DE-CIX Management GmbH Executive Directors: Ivaylo Ivanov, Alexander Hüsch Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne
Hi, Before I jump on the enthusiastic +1 wagon could the author(s) please share some info that I was unable to find? I am trying to asses how big is the problem this policy change is trying to solve. My understanding is that the new policy text applies specifically to holders of prefixes received directly from RIPE NCC. That can only be PI (End-User) or PA (LIRs). Are there a lot of ASN requests rejected for a LIR's first ASN or for End-Users that just received a PI prefix? Among the arguments supporting the proposal there is mentioned: "Removing the needs assessment from initial ASN assignments is likely to make new BGP based products available to single-homed customers." Could you provide a few examples of BGP based products that are currently not but would become available to the single homed customers? Note that BGP is meant to do stuff like, you know, decide where packets go (control plane). If there are no alternative routes for packets to go there are no decisions to make. The multihoming requirement can be achieved to the same provider under the current unchanged policy if multiple links exist. Thanks! PS. Some random info from the IANA website: the monthly ASN assignment averages for the 5 RIRs are ripencc=247, lacnic=62, arin=125, apnic=88, afrinic=14. Would the author(s) be interested in simplifying the ASN assignment policies in the other regions aswell so that everybody can benefit from the new BGP based products? On 7/7/2026 4:19 PM, Angela Dall'Ara wrote:
Dear colleagues,
A new RIPE Policy Proposal, 2026-01 "Simplify assignment of first ASN" is now available for discussion.
This proposal aims to remove the needs assessment for the first AS Number requested by holders of an IP address prefix assigned or allocated directly by the RIPE NCC.
You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2026-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 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@ripe.net before 5 August 2026.
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/
Legitimate holders of an IP address prefix assigned or allocated directly by the RIPE NCC, may be assigned their first AS Number without providing a needs justification.
There's a lot more to unpack in this sentence than is immediately obvious. 1. Should this not be "allocated or assigned directly by the RIPE NCC"? What's the intent here? Is it that this should only apply to addressing resources which ultimately come from the RIPE NCC? 2. is the intent of this policy to be one-easily-obtainable-asn-per-lir, or one-easily-obtainable-asn-per-organisation, or one-easily-obtainable-asn-per-organisation-group. I.e. what happens if you have a group of companies and each company within the group has their own IP assignment in that group? Is it really the intention to allow each individual company / LIR to get their own asn before asking questions? Nick
Dear Address Policy WG, Thanks for all the feedback so far. We're responding to everything in this one message, which we hope is useful. We're happy to adjust the text to require the publication of a documented routing policy for ASNs assigned without a needs assessment. There are two drivers for this proposal. One is to reduce administration and the other is to encourage honesty. The first driver meant we agreed to limit the scope to addresses issued by the RIPE NCC as they have to check that the legitimacy of addresses issued by other registries anyway and at that point you're already in a manual process. And while we're not personally aware of many ASN requests being rejected by the RIPE NCC, we want to remove a policy requirement that might have encouraged some organisations to lie. We believe that there's real value in reinforcing the expectation of honesty. We agree that there is a risk that an entity controlling other entities could use this policy to try to get multiple ASNs. To some extent that risk already exists with the current policy. The key difference is the extra administrative friction. We expect the RIPE NCC would notice this kind of issue and report back to the community on this list or at their regular slot during RIPE meetings. The community could then advise the RIPE NCC on its implementation desires or choose to propose an amendment to address a specific issue. We're not trying to tell product and business managers what offers they should develop. But we recognise that fewer constraints on innovation are likely to unleash new products. We probably won't propose this policy elsewhere. It's possible that it could be copied by people active in other communities. A part of making the proposal is allowing indefinite publication and waiving some rights. People active in other RIR communities are free to copy this proposal if they'd like to. Best wishes, Urban and Leo
Hi all, I support the policy proposal only without the RSPL requirement. It is parsed by virtually no machine (I know one consumer, MSK-IX), cumbersome, not always clear or detailed enough and would prefer ASPA going forward, but this is just another layer of bureaucracy on top of the simplification. Thanks Max Emig
Dear Urban and Leo, Thanks for the informative response. On 7/8/2026 11:37 AM, Leo Vegoda wrote: [...]>
There are two drivers for this proposal. One is to reduce administration and the other is to encourage honesty. The first driver meant we agreed to limit the scope to addresses issued by the RIPE NCC as they have to check that the legitimacy of addresses issued by other registries anyway and at that point you're already in a manual process. And while we're not personally aware of many ASN requests being rejected by the RIPE NCC, we want to remove a policy requirement that might have encouraged some organisations to lie. We believe that there's real value in reinforcing the expectation of honesty.
If first assignments are not actually being rejected for new LIRs or End-Users, then the problem this proposal is trying to solve might not even exist. A human will still process the request even if no multihoming is required; I don't think the RIPE NCC is going full auto on dispensing integers. And if the goal is simply to end the fake-multihoming that several people have welcomed the end of, that can be achieved by removing one sentence from the current policy: "A network must be multihomed in order to qualify for an AS Number." That would be a considerably smaller change than the proposed rewrite, and I would +1 that. Applying only that small change would also keep the RIPE NCC region from diverging unnecessarily from the other RIRs, which is more in line with the coordinated registry system the NRO (of which the RIPE NCC is a member) exists to promote: "Providing and promoting a coordinated Internet number registry system." The RIPE NCC already has the most relaxed integer dispensing among the RIRs. Per the averages in my previous email, RIPE NCC hands out roughly twice as many ASNs as ARIN, with some of that coming from other regions that prefer our online shop for integers for its simplicity and fewest questions asked. As of today the out-of-region ASN registrations are: ripencc=1776, apnic=209, arin=96, lacnic=2, afrinic=0, so it is already a fairly successful cross-region online shop for integers, and I am not convinced it needs more simplification. [...]
We're not trying to tell product and business managers what offers they should develop. But we recognise that fewer constraints on innovation are likely to unleash new products.
So these new BGP based products do not exist yet, and will either be invented or not, independently of whether this policy passes. By the same reasoning, another paragraph could be added to the supporting arguments stating that both providers and customers could win the lottery in countries within the RIPE NCC service region, followed by "this is a good thing" to authoritatively qualify it as good. Both statements are equally speculative and neither belongs in the rationale. Radu
+1, Radu! Géza, old dog On Wed, Jul 8, 2026 at 3:26 PM Radu Anghel via address-policy-wg < address-policy-wg@ripe.net> wrote:
Dear Urban and Leo,
Thanks for the informative response.
On 7/8/2026 11:37 AM, Leo Vegoda wrote: [...]>
There are two drivers for this proposal. One is to reduce administration and the other is to encourage honesty. The first driver meant we agreed to limit the scope to addresses issued by the RIPE NCC as they have to check that the legitimacy of addresses issued by other registries anyway and at that point you're already in a manual process. And while we're not personally aware of many ASN requests being rejected by the RIPE NCC, we want to remove a policy requirement that might have encouraged some organisations to lie. We believe that there's real value in reinforcing the expectation of honesty.
If first assignments are not actually being rejected for new LIRs or End-Users, then the problem this proposal is trying to solve might not even exist. A human will still process the request even if no multihoming is required; I don't think the RIPE NCC is going full auto on dispensing integers.
And if the goal is simply to end the fake-multihoming that several people have welcomed the end of, that can be achieved by removing one sentence from the current policy:
"A network must be multihomed in order to qualify for an AS Number."
That would be a considerably smaller change than the proposed rewrite, and I would +1 that.
Applying only that small change would also keep the RIPE NCC region from diverging unnecessarily from the other RIRs, which is more in line with the coordinated registry system the NRO (of which the RIPE NCC is a member) exists to promote: "Providing and promoting a coordinated Internet number registry system."
The RIPE NCC already has the most relaxed integer dispensing among the RIRs. Per the averages in my previous email, RIPE NCC hands out roughly twice as many ASNs as ARIN, with some of that coming from other regions that prefer our online shop for integers for its simplicity and fewest questions asked. As of today the out-of-region ASN registrations are: ripencc=1776, apnic=209, arin=96, lacnic=2, afrinic=0, so it is already a fairly successful cross-region online shop for integers, and I am not convinced it needs more simplification.
[...]
We're not trying to tell product and business managers what offers they
should develop. But we recognise that fewer constraints on innovation are likely to unleash new products.
So these new BGP based products do not exist yet, and will either be invented or not, independently of whether this policy passes. By the same reasoning, another paragraph could be added to the supporting arguments stating that both providers and customers could win the lottery in countries within the RIPE NCC service region, followed by "this is a good thing" to authoritatively qualify it as good. Both statements are equally speculative and neither belongs in the rationale.
Radu ----- 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, I have read the proposal, presenting - in the "Arguments opposing the proposal" paragraph - the speeding up of the equipment replacement cycle as the only negative consequence of an increase in AS Numbers. I would like to point out that we, and I am sure many other security organizations, heavily use ASNs as one of the ways to classify networks, attach reputation to them, group them in clusters. We inspect all the ASNs coming alive and make some evaluations that contribute to their reputation, such as "can their website be located?", "can their geographical location be easily located?", "are they corporate data available or hidden?", "do they use PTRs?", "who are they upstreams?", etc. The fact is that there is a large fraction of new ASNs that get allocated to rather shady entities, not to mention full cybercrime hosts. It is fully clear that avoiding this is impossible as cybercrime is part of the ecosystem we live in. Yet, RIPE NCC is at present the RIR with the highest rate of new allocations, and I admit that we are watching with a little apprehension at the further increase of the rate that may arise if this change is approved. In short, the number of routed ASNs does not have an impact only on machines. An ASN represents an administrative entity controlling the routing policy of a collection of IP prefixes, and as such it constitutes a little associated analysis cost for whoever needs to monitor the behavior of these entities for the good of the internet. I humbly suggest that this point is somehow added among the "arguments opposing the proposal". Having said that, we will deal with whatever the outcome will be and possibly expand our resources if needed. Kind regards, Natale M Bianchi Spamhaus Project On Tue, Jul 07, 2026 at 03:19:13PM +0200, Angela Dall'Ara wrote:
Dear colleagues,
A new RIPE Policy Proposal, 2026-01 "Simplify assignment of first ASN" is now available for discussion.
This proposal aims to remove the needs assessment for the first AS Number requested by holders of an IP address prefix assigned or allocated directly by the RIPE NCC.
You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2026-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 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@ripe.net before 5 August 2026.
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/
+1 Natale Maria Bianchi via address-policy-wg <address-policy-wg@ripe.net> ezt írta (időpont: 2026. júl. 10., P 18:23):
Dear colleagues,
I have read the proposal, presenting - in the "Arguments opposing the proposal" paragraph - the speeding up of the equipment replacement cycle as the only negative consequence of an increase in AS Numbers.
I would like to point out that we, and I am sure many other security organizations, heavily use ASNs as one of the ways to classify networks, attach reputation to them, group them in clusters. We inspect all the ASNs coming alive and make some evaluations that contribute to their reputation, such as "can their website be located?", "can their geographical location be easily located?", "are they corporate data available or hidden?", "do they use PTRs?", "who are they upstreams?", etc.
The fact is that there is a large fraction of new ASNs that get allocated to rather shady entities, not to mention full cybercrime hosts. It is fully clear that avoiding this is impossible as cybercrime is part of the ecosystem we live in. Yet, RIPE NCC is at present the RIR with the highest rate of new allocations, and I admit that we are watching with a little apprehension at the further increase of the rate that may arise if this change is approved.
In short, the number of routed ASNs does not have an impact only on machines. An ASN represents an administrative entity controlling the routing policy of a collection of IP prefixes, and as such it constitutes a little associated analysis cost for whoever needs to monitor the behavior of these entities for the good of the internet.
I humbly suggest that this point is somehow added among the "arguments opposing the proposal". Having said that, we will deal with whatever the outcome will be and possibly expand our resources if needed.
Kind regards,
Natale M Bianchi Spamhaus Project
On Tue, Jul 07, 2026 at 03:19:13PM +0200, Angela Dall'Ara wrote:
Dear colleagues,
A new RIPE Policy Proposal, 2026-01 "Simplify assignment of first ASN" is now available for discussion.
This proposal aims to remove the needs assessment for the first AS Number requested by holders of an IP address prefix assigned or allocated directly by the RIPE NCC.
You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2026-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 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@ripe.net before 5 August 2026.
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/
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/
participants (15)
-
Angela Dall'Ara -
boggits -
Fredy Künzler -
Gert Doering -
Jeroen Massar -
Job Snijders -
Leo Vegoda -
Maximilian Wilhelm -
Natale Maria Bianchi -
Nick Hilliard -
Radu Anghel -
ripe-lists＠sebastian-graf.at -
ripe＠emigm.ax -
Turchanyi Geza -
Wolfgang Tremmel