Dear Address Policy WG,
Rinse and Jordi have agreed to take 2024-02: IPv6 Initial Allocations
/28 to the Review Phase. They clarified the wording in the proposal
text based on the discussion. The RIPE NCC will publish the new
version.
Four people commented on the proposal:
- Jori Vanneste supported the proposal as written.
- Nick Hilliard suggested rewording text explaining that each
organisation can extend only one allocation up to /28.
- Andy Davidson suggested using the word "member" instead of "organisation".
- Gert Doering supported the proposal, however did not see it as “needed”.
The RIPE NCC will publish the impact analysis and the new policy draft
and announce the start of the Review Phase.
You can find all current policy proposals at:
https://www.ripe.net/community/policies/current-proposals/
You can read our Policy Development Process at:
https://www.ripe.net/publications/docs/ripe-781/
Kind regards,
Leo Vegoda, for the Address Policy WG co-chairs
Dear RIPE Working-Group Chairs,
Please find in attachment a summary of the discussions held in March
2025 on the following mailing lists:
// <https://mail.lacnic.net/pipermail/politicas/>//
• AC-DISCUSS (Address Council Coordination) Mailing List
• RIPE Policy Announce Mailing List
• RIPE Address Policy Working Group Mailing List
• AFRINIC Policy Mailing List
• APNIC Policy Mailing List
• ARIN Policy Mailing List
• LACNIC Policy Mailing List
This summary is a joint effort by colleagues from the Registry Services
department, we hope you will find this useful.
Kind regards,
Angela
--
Angela Dall'Ara
Policy Officer
RIPE NCC
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.
