Multihoming not required for ASN

1. Summary of the problem being addressed by this proposal

When the first ASN assignment policy was originally designed, the main concern was that 16 bits is a limited address space (RFC1930, section 9).

The conservative approach of RFC1930, is no longer an issue considering the 32-bits ASN‘s (RFC6793). For instance, if each of the five RIRs were to assign 100 AS Numbers a day, 365 days a year, it would take over 20,000 years to fill up the 32-bit space.

Furthermore, when initial ASN policies were developed, the reliability of networks was not so good as today and it was making sense to make sure for an ASN holder to be “physically” multihomed.

However, today this is not necessarily a reasonable requirement, and even in some cases, some networks may require an ASN while not willing to be physically multihomed (because of the cost or remote locations that have only a single link/upstream, etc.) and their SLA requirements don’t need that redundancy. However, they are peering with different ASs (for example by means of an IX), which commonly is considered multihoming as well.

Furthermore, in some cases, upstream providers may request an ASN, not accepting a private one, and this must be a valid reason as a justification for obtaining it, because AFRINIC, neither the community have a way to force those upstream providers to change their requirements, despite being wrong. They take their own business and operational decisions.

The deployment of IPv6 also increased the need for organizations which are not ISPs, to obtain IPv6 PI in order to have stable addresses, and in that situation, ideally, they should announce their PI space with their own ASN. In most cases, they don’t have to be multihomed.

The proposal still indicates that sites that don’t need unique ASNs, should use private ones (64,512 - 65,535 and 4,200,000,000 - 4,294,967,294), as per RFC1930 and RFC6996, by just referencing the relevant RFCs, so the policy don’t need to be updated if IETF updates them.

2.Summary of how this proposal addresses the problem

In addition to tidying up the actual text, as there are some repetitions in the CPM Section 7 (ASN), the proposed text ensures that organizations which have their own routing policy and need to interconnect with other organizations, can actually do it.

“Interconnect” is used here with the commonly understood meaning of establishing a connection between two (administratively) separate networks.

3.Proposal

Delete actual section 7.1 and the paragraph before it, renumber all the others, and amend actual 7.4 (Eligibility), as follows.

Current	Proposed
7.0 ASN This section contains policies and guidelines concerning requesting, assigning and registering AS (Autonomous System) numbers in the AFRINIC region. 7.1 Introduction AFRINIC (the African Network Information Center) is the regional Internet Registry for Africa and part of the Indian Ocean region (Seychelles, Mauritius, Madagascar, Comoros). It is responsible for distributing public Internet address space and related resources (including Autonomous System Numbers) in the region and coordinating the development and implementation of the policies to manage those resources. The policies described in this document have been developed by the Internet community through a consensus process facilitated by AFRINIC. They are to be implemented by AFRINIC. 7.2 Scope This document describes the policies relating to the distribution, management, and use of Autonomous System (AS) numbers in the AFRINIC service region. These policies apply to IPv4 and IPv6 networks. Policies of other regions other than the AFRINIC service region are outside the scope of this document. 7.3 Definitions …	7.0 ASN This section contains the policies relating to the distribution, management, and use of Autonomous System (AS) numbers in the AFRINIC service region. 7.1 Definitions [Retain under here all text from the current CPM 7.3]
7.4 Eligibility for an AS Number assignment It is important to determine which sites require unique AS Numbers and which do not require a unique AS Number should use one or more of the AS Numbers reserved for private use. Those numbers are: 64512 through 65535 (RFC1930). In order to qualify for an AS number, the requesting organization must fulfill the following requirements: 7.4.1 A unique routing policy (its policy differs from its border gateway peers). 7.4.2 A multi-homed site. 7.4.3 An organization will also be eligible if it can demonstrate that it will meet the above criteria upon receiving an ASN (or within a reasonably short time thereafter). 7.4.4 Be an AFRINIC member in a good standing (End-User or LIR type) All requests for ASNs under these criteria will be evaluated using the guidelines described in RFC1930 "Guidelines for the creation, selection and registration of an Autonomous System (AS).	7.2 Eligibility for an AS Number assignment It is important to determine which sites require unique AS Numbers. Sites which do not require a unique AS Number should use one or more of the AS Numbers reserved for private use (RFC1930, RFC6996). In order to qualify for an AS number, the requesting organization must be an AFRINIC resource member and fulfill any of the following requirements: 7.2.1 Interconnect (including peering) with more than one AS. 7.2.2 Show a unique routing policy or demonstrate a technical need for a coordinated globally unique ASN. An organization will also be eligible if it can demonstrate that it will meet the above criteria upon receiving an ASN (or within the following six months).

4.References

ARIN and LACNIC don’t require multihoming. An equivalent proposal reached consensus in APNIC47 and has been implemented already. RIPE requires it, but accepts “peering” as multihoming.

https://www.arin.net/policy/nrpm.html#five

https://www.lacnic.net/683/2/lacnic/

https://www.apnic.net/community/policy/proposals/prop-128

4. Revision History

Date	Details
27 February 2019	Version 1: AFPUB-2019-ASN-001-DRAFT01 Initial Draft Posted to rpd
10 April 2019	Version 2: AFPUB-2019-ASN-001-DRAFT02 * Clarifications on updated RFCs (32-bits ASNs) * Text accommodated to list discussion * Resolved issues as per impact analysis
3rd November 2019	Version 3: AFPUB-2019-ASN-001-DRAFT03 * Clarifications and follow up comments from the last meeting.
25th November 2019	Version 4: AFPUB-2019-ASN-001-DRAFT04 * Editorial nits * Small changes as per the recent list discussion

×