This 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 an Autonomous System and its Autonomous Systems and their peerings are globally visible, with the Autonomous System being and that they are multihomed with at least two others. However, there are situations when one requires a globally unique AS Number is required and one or both of these presumptions 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 these days (observed by the authors) observed by the authors is to have the AS applicant applicants fill in as peerings: 1) the AS Number of the actual provider, and 2) a route collector Route Collector with a globally unique ASN. AS Number. The authors believe that there is value in aligning the policy with reality, rather than continuing in the
current, less transparent way.The authors expect current way, which is less transparent.The authors believe
[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. 1930 Link: http://tools.ietf.org/html/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 “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. Region Link: http://www.ripe.net/ripe/docs/contract-req ”.
A new AS Number is only assigned when the End User has a need should only be assigned when there is a technical requirement that cannot be satisfied with an existing
AS Number. RIPE NCC will record, but not evaluate this need.
To discourage excessive resource consumption, the sum of AS Numbers assigned to a single organisation must not exceed 1,000.
When requesting a 16-bitnetwork must be multihomed within nine months of the assignment. Failure to multihome within this timeframe will result in deregistration of the assignment. A 32-bit AS Number is exempt from the multihoming requirement.The
routing policy of an Autonomous SystemThe 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 “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. Region Link: http://www.ripe.net/ripe/docs/contract-req ”.
The "1,000 ASNs per organisation" anti-hoarding number is based on the following: at the moment of writing, the largest amount of ASNs a single organisation has is 100. Setting the number at ten times the current maximum usage will allow for growth but prevent a single organisation from consuming all resources.
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. These projections The projections presented in this analysis are based on existing data and should be viewed only as an indication only. of the possible impact that the policy might have if the proposal is accepted and implemented.
The proposed policy asks the RIPE NCC to assign a new AS Number if an End User has a need that cannot be satisfied with an existing one. It also requires that the RIPE NCC record this need but not evaluate it.
It will be the End User that decides if this need is technically reasonable. The RIPE NCC will have no mandate to review the End User’s decision.
The proposal introduces a limit of 1,000 ASNs that can be assigned to a single organisation.
The proposal adds a special requirement that 16-bit ASNs must be multihomed within nine months of their assignment. Failure to comply with this requirement will result in deregistration of the resource. The RIPE NCC will apply the existing deregistration procedure. Link: /docs/closure
The proposal removes the requirement that the routing policy be new and unique. It also makes optional the requirement that the routing policy be provided to the RIPE NCC.
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 increase, amount, as there is no historical data indicating how many organisations did not request an ASN, ASN or requested an ASN with incorrect information due to technical requirements not described in the current policy.
This potential increase in consumption concerns especially the RIPE NCC’s pool of 16-bit ASNs, which is almost exhausted. The proposal tries to mitigate this risk by requiring that 16-bit ASNs be multihomed after nine months.
The RIPE NCC would like to highlight a possible effect of two other ongoing proposals 2014-13, "Allow AS Number Transfers Link: /membership/policies/proposals/2014-13/ " and 2014-05, "Policy for Inter-RIR Transfers of Internet Resources Link: /membership/policies/proposals/2014-05/ ". If these proposals are accepted, ASNs could be transferred at any time after they have been assigned. The proposed nine-month requirement might therefore not be enough to prevent the 16-bit ASN pool from depleting faster than expected.
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.
Amount of Requests and Workload
The RIPE NCC expects AS Number assignment requests to increase due to the more relaxed criteria. Despite the removal of the need evaluation by the RIPE NCC, it is expected that the overall workload will be higher.
This is due to:
Multihoming Requirement for 16-bit AS Numbers
The proposal requires that 16-bit ASNs be multihomed within nine months from the date they are assigned. The RIPE NCC would need to validate this to ensure compliance with the policy. This requirement would only apply to assignments made after the proposal was implemented.
The RIPE NCC would like to highlight that the proposed policy would allow 16-bit ASNs to be requested for any need that cannot be satisfied with an existing AS Number, yet also requires that they be multihomed within nine months. To avoid surprises, the RIPE NCC will therefore warn End Users requesting 16-bit ASNs for reasons other than multihoming that they must be multihomed within nine months.
After nine months the RIPE NCC will perform a multihoming check by looking first at the number of peering partners visible in the global routing table. If this doesn’t show at least two peering partners, the RIPE NCC will follow up with the resource holder to see if the AS Number is being used for local peering. If at least two peering partners can still not be identified, the 16-bit AS Number will be considered as not multihomed.
The RIPE NCC will apply the existing deregistration procedure to 16-bitTechnical Requirements
that fail to meet this requirement. The final deregistration will occur a further three months after the nine-month multihoming check is conducted. Following the failed check, the RIPE NCC will notify End Users that their assignment will be deregistered in three months if it is not multihomed before then.
Need Requirement
The proposal asks the RIPE NCC to assign a new AS Number if an End User lists “a need that cannot be satisfied with an existing AS Number”. The RIPE NCC will not evaluate this need, but will ask that it be provided,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 if an End User states a need when there is a technical requirement that cannot be satisfied with an existing
AS Number. The RIPE NCC will not evaluate this need. The RIPE NCC will also no longer require the routing policy of the Autonomous System to be submitted.
The RIPE NCC will, however, evaluate whether this request complies with the other policy criteria. In particular, the RIPE NCC will check whether the request exceeds the 1,000 ASN limit as set by the policy.
The RIPE NCC will also check whether 16-bit AS Numbers fulfill the nine-month multihoming requirement. Again, this is not an evaluation of the need, but rather compliance with the policy criteria. 16-bit AS Numbers that fail to fulfill this requirement will be deregistered.
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.