You're looking at an older version: 1
The current (published) version is 2This policy proposal would remove the requirement that a network must be multihomed in order to receive an AS Number assignment from the RIPE NCC.
The current policy assumes that Autonomous Systems and their peerings are globally visible, and that they are multihomed with at least two others. However, there are situations when one requires a globally unique AS Number and one or both of these assumptions are incorrect. Limited visibility is observed in the context of GRX peering, or in a more common case: a network might be its own upstream, which supports reducing the peering requirement from two to one.
A common practice observed by the authors is to have applicants fill in as peerings: 1) the AS Number of the actual provider, and 2) a Route Collector with a globally unique AS Number. The authors believe there is value in aligning the policy with reality, rather than continuing in the current way, which is less transparent.
The authors believe that the RIPE NCC is capable of applying an understanding of what constitutes valid use and need (that is shared with the community) and interpreting requests under these terms. Examples of acceptable technical reasons would be: RFC 1930, RFC 2270, multihoming, preparing to multihome where the second provider is yet to be decided, or connecting separately maintained private networks.
[The following text will update section 2.0 in the RIPE Policy Document “Autonomous System (AS) Number Assignment Policies", if the proposal reaches consensus.]
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 RFC 1930.
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”.
A new AS Number should only be assigned when there is a technical requirement that cannot be satisfied with an existing or private 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 Document “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”.
An open question is whether additional text is needed to ensure the conservation and fair distribution of the remaining 16-bit ASNs, or if all all ASNs should be treated equally as under the current policy. Perhaps this could mean limiting the number of 16-bit ASNs per organisation, or requiring the RIPE NCC to perform an additional review.
Because there is no yearly cost associated with the registration of an AS Number, this policy might require steps to prevent a small group of entities from requesting all available AS Numbers. The policy will necessarily be soft and open to interpretation. The authors foresee less complications if a yearly cost were to be associated with AS Numbers.
Note: In order to provide additional information related to the proposal, details of an impact analysis carried out by the RIPE NCC are documented below. The projections presented in this analysis are based on existing data and should be viewed only as an indication of the possible impact that the policy might have if the proposal is accepted and implemented.
Autonomous System Number (ASN) Consumption:
An increased consumption of ASNs is a possible outcome if the proposal is accepted. It is hard to project the actual amount, as there is no historical data indicating how many organisations did not request an ASN or requested an ASN with incorrect information due to technical requirements not described in the current policy. This increase in consumption concerns especially the RIPE NCC’s pool of 16-bit ASNs, which is almost exhausted.
Fragmentation/Aggregation:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
Technical Requirements
The proposed policy does not remove the multihoming requirement for AS Number assignments but extends the definition to include other “technical requirements”. However, the proposed policy does not specify which “technical requirements” would justify the assignment of a public AS Number. As a consequence, each AS Number request would have to be evaluated on a case-by-case basis, which may result in inconsistent evaluations of requests and potential disputes between LIRs and the RIPE NCC on the basis of whether a request is justified or not.
Based on these reasons, in order to implement this proposed policy, the RIPE NCC would need definite guidance from the RIPE community regarding which specific “technical requirements” would be considered sufficient to justify an AS Number assignment.
Potential Future Multihoming
The proposed policy will allow AS Number assignments to networks that may “not be multihomed today, but might want to prepare its infrastructure so it can multihome at a moment's notice”.
In order to implement this proposal, the RIPE NCC would need definite guidance from the RIPE community regarding the time period allowed for multihoming. The RIPE NCC would also need definite guidance from the RIPE community on whether it is expected to validate multihoming after a certain period.
Private vs Public AS Number
The proposed policy allows the assignment of public ASNs, in cases where private ASNs could be used, when there is a chance of conflict with a private ASN used in the customer’s LAN. This would remove the need for network engineers to evaluate CE configuration in each case. The proposal does not, however, specify whether there must be a technical reason for issuing a public ASN or whether administrative ease is sufficient justification. This may result in inconsistent evaluations and potential disputes between LIRs and the RIPE NCC regarding whether a request is justified or not.
In order to implement this proposal, the RIPE NCC would need definite guidance from the RIPE community regarding what type of justification is required for the assignment of a public ASN in cases where a private ASN could be used.
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
The proposed policy requires a new AS Number to be assigned when there is a technical requirement that cannot be satisfied with an existing or private AS Number.
Whereas the existing criteria (multihoming) for the assignment of an AS Number are objective, the proposed criteria are subject to an evaluation by the RIPE NCC. The RIPE NCC is liable for the evaluations it conducts and would be vulnerable to accusations that it has conducted a bad evaluation in cases where an AS Number request was rejected.
Therefore, the RIPE NCC would need to be transparent regarding the technical requirements it considers enough for a request to be approved.
Before giving a realistic estimation for the implementation, the RIPE NCC requires further guidance from the community on the topics mention above. Once these points have been clarified, existing processes and the request form would need to be updated to facilitate the implementation if the proposal reaches consensus. The RIPE NCC might also need to prepare a procedural document to explain the technical requirements considered sufficient for a request to be approved.