Autonomous System Numbers: Private vs Public

The 4,294,967,296 identifiers available in the 4-byte ASN format dwarf the legacy 16-bit limit. These numerical ranges define hard network boundaries. The Internet Assigned Numbers Authority reserved specific blocks for private use, while public blocks anchor global routing. You can request these resources directly from AFRINIC.

Network operators rely on an Autonomous System Number as a globally unique identifier for groups of IP prefixes that maintain a single routing policy. A 2-byte ASN offers a mere 65,536 possibilities. The transition to 32-bit numbering prevents the collapse of available public addresses. IANA reserved numbers from 64,512 to 65,534 within the older format for private systems communicating with a single provider.

Understanding the architectural differences between private and public ASN types allows engineers to verify network ownership accurately. The application process for AFRINIC members differs sharply from new applicants needing initial capacity. Mastering these formats gives network engineers direct control over traffic management, avoiding the pitfalls of shared routing policies.

The Role of Autonomous System Numbers in Global BGP Routing

ASN Definition: Globally Unique Identifiers for BGP Routing Policies

An Autonomous System Number acts as the distinct tag marking a cluster of IP prefixes governed by one explicit routing policy. This label lets network operators keep internal controls separate while swapping data with peers around the world. The Border Gateway Protocol relies on this unique marker to tell administrative domains apart and apply traffic rules correctly. Such a definition moves past simple counting to describe a real boundary where a single entity chooses the path logic. BGP changed how these independent networks share reachability details long ago. Early 2026 data shows roughly 80,000 active Autonomous Systems in the global BGP routing table, each needing its own number. Private numbers work fine for single-provider links where global uniqueness does not matter. Using a private number stops direct peering at internet exchange points or multi-homed setups entirely. InterLIR helps networks pick the right ASN format for smooth integration with upstream providers and peer networks. The chosen identifier type decides if a network stays isolated or joins the global routing system fully.

Public vs Private ASN Usage Scenarios for Single and Multi-Homed Networks

Topology dictates the ASN format. A private ASN works well for single-homed systems talking only to one upstream provider since these identifiers never travel globally. IANA set aside specific 2-byte ASNs just for this internal use to keep routing tables clean. A public ASN becomes required when an organization must exchange routing info across the wider internet or link to multiple peers. Getting a public ASN usually means showing a need for distinct routing policies like multi-homing. This difference draws a clear line: private ranges handle isolated edge connections while public numbers enable complex mesh topologies. Nearly a vast number of private 4-byte ASNs exist, letting large enterprises build huge internal architectures without eating up scarce global resources. Organizations can define their own network identity inside and outside their walls. Establishing a personal Border Gateway Protocol becomes possible with a public ASN. Direct peering with Internet Exchange Points opens up immediately. Traffic control improves notably for network operators. Flexible network management becomes a reality rather than a goal. IP address portability stands out as a substantial benefit of owning an IP address and ASN.

2-Byte vs 4-Byte ASN Capacity Limits and Global Routing Table Growth

Moving from 16-bit to 32-bit numbering grows the global address space massively. The total pool of 2-byte (16-bit) ASNs offers 65,536 unique identifiers ranging from 0 to 65,535, though reservations shrink the usable public range. The theoretical maximum capacity of the 4-byte (32-bit) ASN numbering scheme hits 4,294,967,296 unique identifiers, spanning from 0 to 4,294,967,295. This huge capacity jump directly supports the observed growth of active systems in the global routing table. Operators must check that all border routers handle four-octet AS numbers to avoid session failures with modern peers. Recent BGP table growth studies confirm cloud services drive demand for distinct routing policies. Legacy equipment unable to parse 32-bit values creates a hard ceiling for network scalability.

Technical Architecture of 2-Byte and 4-Byte ASN Formats

Binary Structure of 2-Byte and 4-Byte ASN Encodings

Let's decode the mathematical foundation behind our network identifiers. A 2-byte ASN operates as a 16-bit integer, capping the total space at 65,536 unique values (0 to 65,535). This limited range faced predicted exhaustion by mid-2011, necessitating the adoption of the 4-byte ASN format. A 4-byte ASN is a 32-bit number providing 4,294,967,296 ASNs (calculated as 2 to the power of 32), ranging from 0 to 4,294,967,295.

Handlers must process these larger integers carefully, as legacy configurations sometimes display them in dot-notation rather than simple integers. This technical representation adds complexity to management software that lacks full updates. However, the transition is necessary; sticking to 16-bit limits restricts operators to a pool that analysis predicted would run out of available space over a decade ago.

The critical insight here involves binary efficiency versus operational simplicity. Modern BGP implementations, updated by RFC 4893 and RFC 6793, support 4-byte ASNs, though legacy compatibility and "short-form" display issues sometimes make 2-byte ASNs more desirable for specific peering scenarios.

Implementing RFC 6996 Private Ranges in Internal BGP

Operators deploy RFC 6996 reserved blocks to isolate internal routing policies from the global table. This specific configuration prevents private topology details from leaking into public view while maintaining full BGP functionality within the enterprise edge. The mechanism relies on strict adherence to assigned numerical boundaries that routers recognize as non-exportable.

For legacy 16-bit systems, the valid range spans from 64,512 to 65,534. The Internet Assigned Numbers Authority (IANA) has reserved 1,023 numbers (from 64,512 to 65,534) from this range for private use, as documented in RFC 6996. Modern 32-bit architectures apply a vastly larger pool, where IANA has reserved numbers from 4,200,000,000 to 4,294,967,294 for private use. This allocation provides 94,967,295 identifiers, supporting complex internal architectures without consuming scarce public resources.

Optimizing existing resources ensures your network remains stable as global routing complexity increases.

Validation Steps for 4-Byte ASN Compatibility in BGP Sessions

Start your audit by confirming router software parses 32-bit integers without truncating the high-order bits. Modern BGP implementations updated per RFC 6793 handle the expanded space, yet legacy display formats often obscure compatibility failures during initial peering. Operators must verify that BGP sessions negotiate the four-octet capability flag correctly before exchanging routes.

1. Inspect neighbor states to ensure the four-octet AS number capability is advertised and received.
2. Validate that logging systems record the full 32-bit value rather than forcing a legacy 2-byte translation.
3. Despite this shift, a two-tier market persists because specific peering preferences sometimes favor shorter legacy compatibility notation. While 4-byte ASNs are more common due to the exhaustion of older ranges, the perceived value of 2-byte ASNs remains higher due to their legacy compatibility and shorter notation.

Step-by-Step Guide to Requesting an ASN from AFRINIC

AFRINIC Membership Status and ASN Eligibility Rules

Applicants must first determine their standing with the registry to identify the correct application pathway. Non-members cannot directly request resources; they must complete the membership onboarding process to gain access to IP resources. Existing resource holders bypass this step and proceed directly to the MYAFRINIC portal under Resources > AS Numbers. The policy accepts requests from Local Internet Registries, non-LIR members, and non-members located within the service region.

Eligibility strictly follows CPM Section 7.4, requiring proof of multi-homing or a unique routing policy.

1. Navigate to the membership portal if you lack an account.
2. Log in to MYAFRINIC if you are already a member.
3. Submit technical justification for the Autonomous System.

The cost structure often surprises new operators; while there is no standalone purchase price, fees are embedded in annual maintenance. Organizations qualifying as small service providers may pay capped annual fees around $250, which covers administrative overhead. However, the real investment lies in operational justification, as failure to apply the resource can lead to reclamation. Networks must prove they are actively using the ASN for a single, clearly-defined routing policy. This preparation ensures your network identity remains stable and globally reachable.

Navigating the MYAFRINIC Portal for ASN Requests

Existing members initiate requests by logging into the MYAFRINIC portal and selecting Resources > AS Numbers to access the application interface. This direct pathway bypasses general membership onboarding, allowing resource holders to immediately specify their need for a public identifier or an anycast assignment. The system requires applicants to select the correct policy context, such as the specific reserve for IXP route servers found in CPM Section 11.0.

1. Upload a network topology diagram showing connections to at least one upstream provider.
2. Provide authoritative contact details for peers to satisfy the peering confirmation requirement.
3. Submit a countersigned MoU if the request targets an Internet Exchange Point environment.

Operators seeking discounts or specialized anycast ranges must explicitly declare this intent in the initial form to trigger the correct review workflow. A common oversight involves submitting generic routing policies when the portal demands specific route server configurations for IXP applicants.

The evaluation team verifies that the proposed routing policy remains unique and does not conflict with existing allocations. Unlike general IP requests, ASN applications face a strict contractual obligation check before approval. This preparation ensures your organization avoids the delays often seen when documentation arrives piecemeal.

Documentation Checklist to Prevent ASN Application Rejection

Secure your approval by assembling precise peering confirmations before submitting to AFRINIC. Applicants frequently face rejection when upstream providers cannot verify the proposed interconnection details.

1. Gather authoritative corporate contact data for at least one upstream transit provider.
2. Prepare a clear network topology diagram showing connections to multiple systems.
3. Draft a written statement defining your single, clearly defined routing policy.

Operators must prove they interconnect with more than one AS to satisfy eligibility rules. Failure to demonstrate this multi-lateral connectivity suggests the organization does not yet need a globally unique identifier. The "price" of an ASN includes the operational cost of justification, as networks failing to meet utilization criteria face potential resource loss reclamation. Submitting incomplete peering agreements often triggers a request for more information, delaying deployment by weeks.

Public ASN Benefits: Unique Identity and Traffic Control

A public ASN establishes the globally unique identity required to exchange routing information across the global Internet. Unlike private identifiers restricted to single-provider connections, this public format enables operators to implement their own Border Gateway Protocol policies independently. This distinction allows networks to connect directly with Internet Exchange Points without intermediary filtering.

• Define clear routing policies that remain consistent across multiple upstream providers.
• Participate in Internet Exchange Points to reduce latency and transit costs.
• Maintain full traffic control regardless of underlying infrastructure changes.

Possessing a public ASN offers several benefits to network operators, primarily through the establishment of a unique network identity internally and externally. Relying on a private ASN for public-facing services forces dependence on a single upstream carrier's translation. Networks requiring a single, clearly-defined routing policy across multiple connections benefit from the IP address portability and flexible network management that a public ASN provides. Without a public identifier, a network cannot directly exchange routing information with other autonomous systems on the open Internet.

AFRINIC ASN Application Paths for Members and Non-Members

Non-members must complete full membership onboarding before accessing any IP resources, creating an initial administrative step that existing members bypass. Non-AFRINIC resource members wishing to request an ASN must follow the process outlined in 'How to become an AFRINIC Member' to gain membership and access IP resources. Applicants without current holdings follow the "How to become an AFRINIC Member" guide to establish eligibility, whereas current resource holders log directly into the MYAFRINIC portal. These established operators navigate to Resources > AS Numbers to submit requests for first or additional identifiers.

The evaluation process strictly enforces technical criteria, requiring proof that the network will interconnect with more than one autonomous system. AFRINIC assigns AS Numbers based on specific policies, including those for Local Internet Registries (LIRs), non-LIR members, and non-members located in the AFRINIC service region. While costs are often embedded in annual fees rather than standalone purchases, the administrative overhead varies by region and membership tier.

All requests are subject to the Contractual Obligation Check (COC) prior to evaluation. InterLIR recommends preparing topology diagrams and peering confirmations before initiating any portal interaction to ensure the request meets the requirement to interconnect with more than one AS.

AFRINIC Eligibility Verification for LIRs and Non-LIRs

Start your validation by confirming your network sits physically within the AFRINIC service region, as geography dictates registry authority. LIRs and non-LIR members alike must prove they interconnect with more than one autonomous system to satisfy the core routing policy requirement. Non-members face a mandatory membership onboarding step before accessing resources, while existing users simply log into MYAFRINIC to navigate to Resources > AS Numbers.

Applicants must demonstrate a unique routing strategy or technical necessity. AFRINIC operates under specific policies, including provisions for Anycast resource assignments purely for Anycast or GPRS Roaming Exchange (GRX) usage, and Resource Reservations for Internet Exchange Points (IXPs) which reserves a set of 2-byte ASNs for IXP BGP Route Servers. The registry accepts requests from Local Internet Registries (LIRs), non-LIR members, and non-members as detailed in CPM Section 7.4. This strict adherence prevents hoarding and keeps the global routing table efficient. Operators must satisfy the eligibility criteria outlined in the Consolidated Policy Manual, such as the requirement to interconnect with more than one AS, to successfully obtain an assignment.

References

• At the West Africa Peering Forum, in Cotonou, Benin