You are here: Home > Participate > Policy Development > Policy Proposals > Remove Multihoming Requirement for AS Number Assignments

Changes to Remove Multihoming Requirement for AS Number Assignments

Legend (+) Added (-) Deleted
Changed Tag Added Tag Deleted

insert: <b> Summary of Proposal insert: </b>

delete: <p> 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. delete: </p>

The current policy assumes that an Autonomous Systems System and their its peerings are globally visible, and that they are with the Autonomous System being 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 assumptions presumptions 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 these days (observed by the authors authors) is to have applicants the AS applicant fill in as peerings: 1) the AS Number of the actual provider, and 2) a Route Collector route collector with a globally unique AS Number. ASN. The authors believe that there is value in aligning the policy with reality, rather than continuing in the current way, which is current, less transparent. transparent way.

The authors believe that the RIPE NCC is capable of applying expect that the RIPE NCC, when needed, will present an understanding of what constitutes valid use and need (that is shared with the community) and interpreting requests under these terms. aggregated view of AS needs for community consideration. Examples of acceptable technical reasons typical needs would be: delete: <a class="external-link" href="http://tools.ietf.org/html/rfc1930" target="_self" title=""> insert: <a class="external-link" href="https://tools.ietf.org/html/rfc1930" target="_self" title=""> RFC 1930 , RFC 2270 , multihoming, preparing to multihome where the (when second provider is yet to be decided, or as-of-yet undeciced), connecting separately maintained private networks. networks, and private networks where the uniqueness of a private ASN cannot be guaranteed.

insert: <b> Policy Text insert: </b>

[The following text will update section 2.0 in the RIPE Policy Document “ insert: <span> Autonomous System (AS) Number Assignment Policies insert: </span> ", if the proposal reaches consensus.]

insert: <b> a. Current policy text insert: </b>

delete: <h3 style="padding-left: 30px; "> insert: <h4>

insert: <b> 2.0 Assignment Criteria delete: </h3> delete: <p style="padding-left: 30px; "> insert: </b> insert: </h4>

insert: <p>

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 delete: <a class="external-link" href="http://tools.ietf.org/html/rfc1930" target="_self" title=""> insert: <span> RFC 1930 delete: </a> insert: </span> .

delete: <p style="padding-left: 30px; "> insert: <p>

A network must be multihomed in order to qualify for an AS Number.

delete: <p style="padding-left: 30px; "> insert: <p>

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.

delete: <p style="padding-left: 30px; "> insert: <p>

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 “ delete: <a class="external-link" href="http://www.ripe.net/ripe/docs/contract-req" target="_self" title=""> insert: <span> Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region delete: </a> insert: </span> ”.

insert: <b> b. Proposed policy text insert: </b>

delete: <h3 style="padding-left: 30px; "> insert: <h4>

insert: <b> 2.0 Assignment Criteria delete: </h3> delete: <p style="padding-left: 30px; "> insert: </b> insert: </h4>

insert: <p>

A new AS Number should is only be assigned when there is a technical requirement the End User has a need that cannot be satisfied with an existing or private AS Number. delete: </p> delete: <p style="padding-left: 30px; "> RIPE NCC will record, but not evaluate this need. insert: </p>

insert: <p>

To discourage excessive resource consumption, the sum of AS Numbers assigned to a single organisation must not exceed 1,000. insert: </p>

insert: <p>

When requesting an a 16-bit AS Number, the network 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. insert: </p>

insert: <p>

The routing policy of the an Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database.

delete: <p style="padding-left: 30px; "> insert: <p>

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 “ delete: <a class="external-link" href="http://www.ripe.net/ripe/docs/contract-req" target="_self" title=""> insert: <span> Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region delete: </a> insert: </span> ”.

insert: <b> Rationale insert: </b>

delete: <h4> insert: <h3>

insert: <b> a. Arguments supporting the proposal delete: </h4> insert: </b> insert: </h3>

  • In the context of layer-3 MPLS VPN, you may wish to run eBGP on the CE both in the PE's direction and the CustomerLAN's direction. The Service Provider's PE has your regular AS Number, ASN, and every CE in the network could share the same AS Number via use of as-override function and Site of Origin community. However, a private community.  But a Private AS Number might not be a good candidate, as the CustomerLAN may already use that AS Number. The Number.  With the current policy forces you are forced to evaluate CE configuration in each case, which creates creating unnecessary complexity.
  • A network might not be multihomed today, but might want wants to prepare its all infrastructure so it can multihome at a moment's notice, or have some form of mobility in terms of suppliers.
  • The accuracy of the RIPE Database is the most more important concern. than anything. The authors suspect that already today organisations are more focused on deem the value of obtaining a globally unique AS Number ASN higher than providing truthful information to the RIPE NCC regarding their peers. its peers to the RIPE NCC. By simply not requiring potentially falsified information that is potentially falsified, the process's transparency is increased.
delete: <h4> insert: <h3>

insert: <b> b. Arguments opposing the proposal delete: </h4> insert: </b> insert: </h3>

    delete: <li> There is no yearly charge associated with AS Number assignments at the time of writing. A company could start hoarding all available AS Numbers. delete: </li>
  • Could it be that previously aggregated prefixes are unbundled and and, under the new policy policy, the fragments are originated by a set of Autonomous Systems with a single, common upstream?

insert: <b> Authors' remarks insert: </b>

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 The "1,000 ASNs per organisation, or requiring the RIPE NCC to perform an additional review. delete: </p> delete: <p> Because there is no yearly cost associated with the registration of an AS Number, this policy might require steps to 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 small group of entities single organisation from requesting consuming 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. delete: <br /> resources. insert: </p>

insert: <p>

 


insert: <strong> Impact Analysis: insert: </strong>

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 These 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. only.

insert: <strong> A. RIPE NCC's Understanding of the Proposed Policy insert: </strong>

delete: <ol> delete: <li> The proposed policy does not remove the multihoming requirement for AS Number assignments but extends the definition to include other “technical requirements” delete: </li> delete: <li> insert: <p>

The proposed policy asks the RIPE NCC to make a judgement regarding the validity of the “technical requirement” behind assign a new AS Number if an AS Number request delete: </li> delete: <li> The proposed 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. insert: <br />
insert: <br />
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. insert: </p>

insert: <p>

The proposal introduces a limit of 1,000 ASNs that can be assigned to a single organisation. insert: </p>

insert: <p>

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 insert: <a class="external-link" href="../../../docs/closure" target="_self" title=""> deregistration procedure. insert: </a> insert: </p>

insert: <p>

The proposal removes the requirement that the routing policy will allow AS Number assignments to networks which “may be multihomed in the future” delete: </li> delete: <li> The proposed be new and unique. It also makes optional the requirement that the routing policy will allow AS Number assignments to networks which “may want mobility in terms of suppliers” delete: </li> delete: <li> The proposed policy allows the assignment of public ASNs in cases where private ASNs could be used but there is a chance of conflict with a private ASN used in the customer’s LAN   be provided to the RIPE NCC. insert: </p>

insert: <h3>

  delete: </strong> delete: </li> delete: </ol> delete: <h3> B. Impact of Policy on Registry and Addressing System insert: </strong>

delete: <p> delete: <strong> Autonomous System Number (ASN) Consumption: delete: </strong> delete: </p>

An increased consumption of ASNs is a possible outcome if the proposal is accepted. It is hard to project the actual amount, increase, 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. insert: </p>

insert: <p>

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. insert: </p>

insert: <p>

The RIPE NCC would like to highlight a possible effect of two other ongoing proposals 2014-13, " insert: <a class="internal-link" href="resolveuid/5805214ea9f74eef84fe5b0cf9c3e1b8" target="_self" title="" data-val="5805214ea9f74eef84fe5b0cf9c3e1b8" data-linktype="internal"> Allow AS Number Transfers insert: </a> " and 2014-05, " insert: <a class="internal-link" href="resolveuid/20073173d7f84379ae538c4a44bc472a" target="_self" title="" data-val="20073173d7f84379ae538c4a44bc472a" data-linktype="internal"> Policy for Inter-RIR Transfers of Internet Resources insert: </a> ". 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.

insert: <strong> C. Impact of Policy on RIPE NCC Operations/Services  Operations/Services insert: </strong>  

delete: <h4 class=" "> insert: <h4>

insert: <strong> Registration Services: insert: </strong>

delete: <p class=" "> insert: <p class="p1">

Technical Requirements 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. insert: </p>

insert: <p class="p1">

This is due to: insert: </p>

insert: <ul>
    insert: <li>
  • An expected increase in new AS Number requests insert: </li>
  • insert: <li>
  • All new 16-bit AS Number assignments will need to be checked for multihoming nine months after the assignment has been made insert: </li>
  • insert: <li>
  • Additional deregistration of non-multihomed 16-bit AS Number assignments insert: </li>
  • insert: <li>
  • Additional checks to make sure a single organisation does not exceed 1,000 ASNs insert: </li>
  • insert: </ul>
insert: <p class="p1">

insert: <strong> insert: <br />
insert: </strong>
insert: </p>

insert: <p class="p1">

insert: <strong> Multihoming Requirement for 16-bit AS Numbers insert: </strong> insert: </p>

insert: <p class="p1">

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.  insert: </p>

insert: <p class="p1">

The RIPE NCC would like to highlight that the proposed policy does 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. insert: </p>

insert: <p class="p1">

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 remove the be identified, the 16-bit AS Number will be considered as not multihomed. insert: </p>

insert: <p class="p1">

The RIPE NCC will apply the existing deregistration procedure to 16-bit AS Number assignments that fail to meet this requirement. The final deregistration will occur a further three months after the nine-month multihoming requirement for AS Number assignments but extends the definition to include other “technical requirements”. However, the proposed policy does 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 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. delete: </p> delete: <p> 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 multihomed before then. insert: <strong> insert: </strong> insert: </p>

insert: <p class="p1">

insert: <strong> Need Requirement insert: </strong> insert: </p>

insert: <p class="p1">

The proposal asks the RIPE NCC to assign a new AS Number if an AS Number assignment. delete: <br /> delete: <br /> delete: <b> Potential Future Multihoming delete: </b> delete: </p> delete: <p> The proposed policy will allow AS Number assignments to networks that may End User lists not be multihomed today, but might want to prepare its infrastructure so it can multihome at a moment's notice a need that cannot be satisfied with an existing AS Number ”. delete: </p> delete: <p> In The RIPE NCC will not evaluate this need, but will ask that it be provided, 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.  delete: <br /> delete: <br /> delete: <b> Private vs Public AS Number delete: </b> delete: </p> delete: <p> 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.   delete: </p> delete: <p> 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. create statistics to inform the RIPE community.

Billing/Finance Department:

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.

RIPE Database:

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.

insert: <strong> D. insert: </strong> insert: <strong> Legal Impact of Policy insert: </strong>

The proposed policy requires a new AS Number to be assigned when there is a technical requirement that if an End User states a need cannot be satisfied with an existing or private AS Number. delete: </p> delete: <p> Whereas the existing criteria (multihoming) for the assignment of an AS Number are objective, the proposed criteria are subject to 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. insert: </p>

insert: <p>

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. insert: </p>

insert: <p>

The RIPE NCC will also check whether 16-bit AS Numbers fulfill the nine-month multihoming requirement. Again, this is not an evaluation by the RIPE NCC. The RIPE NCC is liable for the evaluations it conducts of the need, but rather compliance with the policy criteria. 16-bit AS Numbers that fail to fulfill this requirement will be deregistered. insert: <br />
insert: <strong> insert: </strong> insert: </p>

insert: <h3>

insert: <strong> E. Implementation insert: </strong> insert: </h3>

insert: <p>

The RIPE NCC estimates that the implementation of this proposal would have a medium impact. Processes, supporting software and would be vulnerable to accusations that it has conducted a bad evaluation in cases where an AS Number request was rejected. delete: </p> delete: <p> Therefore, the RIPE NCC documentation would need to be transparent regarding the technical requirements it considers enough updated to allow the assignment of AS Numbers according to the new policy criteria, and for a request to be approved. delete: </p> delete: <h3> E. Implementation delete: </h3> delete: <p> Before giving a realistic estimation checking 16-bit ASN assignments 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 multihoming. The RIPE NCC 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 develop a process for a request to be approved. delete: </p> the collection and provision of statistics concerning the different needs behind AS Number requests. insert: </p>

How to read this draft document:

This document relates to the policy proposal 2014-03, “ Remove Multihoming Requirement for AS Number Assignments ”. If approved, it will modify ripe-525 . To show you how the new document would be different to the old one, we have highlighted any new text or changes to the existing text.

We indicate changes to existing text in the document like this:

ORIGINAL TEXT

NEW TEXT

The text from the current policy document that will be replaced is displayed here.

The proposed text change will be displayed here.

All other text in the document will not be replaced.

Abstract

This document describes the policies for the assignment of globally unique Autonomous System (AS) Numbers within the RIPE NCC service region. These policies are developed by the RIPE Community following the RIPE Policy Development Process.

Contents

1.0 Definition

2.0 Assignment Criteria

3.0 Returning AS Numbers

4.0 32-bit AS Numbers

5.0 Registration

6.0 References

7.0 Attribution

1.0 Definition

An Autonomous System (AS) is a group of IP networks run by one or more network operators with a single clearly defined routing policy. When exchanging exterior routing information, each AS is identified by a unique number. Exterior routing protocols such as BGP, described in RFC1771 , "A Border Gateway Protocol 4 (BGP-4)", are used to exchange routing information between Autonomous Systems. An AS will normally use some interior gateway protocol to exchange routing information on its internal networks.

2.0 Assignment Criteria

delete: <colgroup>delete: <col width="302" />delete: <col width="329" />delete: </colgroup>insert: <td>insert: </tr>insert: </tbody>insert: </table>
delete: <p> delete: <span> delete: <span> insert: <p class="western">

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 . delete: </span> delete: </span> delete: </p> delete: <p> delete: <span> delete: <span> insert: </p>

insert: <p class="western">

A network must be multihomed in order to qualify for an AS Number. delete: </span> delete: </span> delete: </p> delete: </td> delete: <td> delete: <p> delete: <span> delete: <span> delete: <span class="newdifftext"> delete: <em> 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. delete: </em> delete: </span> delete: <em> delete: <span> delete: </span> delete: </em> delete: </span> delete: </span> delete: </p> delete: </td> delete: </tr> delete: </tbody> delete: </table> delete: <p> delete: <span> delete: <span> insert: </p>

insert: <p class="western">

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. delete: </span> delete: </span> delete: </p> delete: <p> insert: </p>

insert: </td>
insert: <p class="western">

insert: <span class="newdifftext"> insert: <i> A new AS Number is only assigned when the End User has a need that cannot be satisfied with an existing AS Number. RIPE NCC will record, but not evaluate this need. insert: </i> insert: </span> insert: </p>

insert: <p class="western">

insert: <span class="newdifftext"> insert: <i> To discourage excessive resource consumption, the sum of AS Numbers assigned to a single organisation must not exceed 1,000. insert: </i> insert: </span> insert: </p>

insert: <p class="western">

insert: <span class="newdifftext"> insert: <i> When requesting a 16-bit AS Number, the network 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. insert: </i> insert: </span> insert: </p>

insert: <span class="newdifftext"> The routing policy of an Autonomous System should be defined in RPSL in the RIPE Database. insert: </span> insert: </td>
insert: <p class=" ">

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 ”.

3.0 Returning AS Numbers

If an organisation no longer uses the AS Number, it must be returned to the public pool of AS Numbers. The RIPE NCC can then reassign the AS Number to another organisation.

4.0 32-bit AS Numbers

The RIPE NCC assigns 32-bit AS Numbers according to the following timeline:

  • From 1 January 2007 the RIPE NCC will process applications that specifically request 32-bit only AS Numbers (AS Numbers that can not be represented with 16 bits) and assign such AS Numbers as requested by the applicant. In the absence of any specific request for a 32-bit only AS Number, the RIPE NCC will assign a 16-bit AS Number.

  • From 1 January 2009 the RIPE NCC will process applications that specifically request 16-bit AS Numbers and assign such AS Numbers as requested by the applicant. In the absence of any specific request for a 16-bit AS Number, the RIPE NCC will assign a 32-bit only AS Number.

  • From 1 January 2010 the RIPE NCC will cease to make any distinction between 16-bit AS Numbers and 32-bit only AS Numbers, and it will operate AS Number assignments from an undifferentiated 32-bit AS Number allocation pool.

5.0 Registration

The RIPE NCC will register the resources issued in the RIPE Database.

6.0 References

[RFC1771] "A Border Gateway Protocol 4 (BGP-4)" http://www.ietf.org/rfc/rfc1771.txt

[RFC1930] " Guidelines for creation, selection, and registration of an Autonomous System (AS)" http://www.ietf.org/rfc/rfc1930.txt

[RFC2026] "The Internet Standards Process -- Revision 3 IETF Experimental RFC http://www.ietf.org/rfc/rfc2026.txt see Sec. 4.2.1

7.0 Attribution

This document is compiled from policies developed by the RIPE community.

The following people actively contributed by making proposals through the RIPE Policy Development Process:

Nick Hilliard, Geoff Huston

Get Involved

The Address Policy Working Group develops policies relating to the allocation and registration of Internet number resources (IPv4 and IPv6 addresses and ASNs) by the RIPE NCC and its members. Anyone with an interest in Internet numbering issues is welcome to observe, participate and contribute to the WG. To post a message to the list, send an email to address-policy-wg@ripe.net. Please note that only subscribers can post messages.

RIPE Forum

The RIPE Forum is an additional way to participate in RIPE community mailing list discussions using a web-based interface rather than an email client.

Check out the forum

Please contact if you need more information.

Stay up to date!

Follow @PDO_RIPE_NCC on Twitter.