Autonomous System Numbers: 2byte vs 4byte Reality

The global routing table hit 89,497 recorded entries as of January 4, 2026. This number represents a mature architecture currently digesting a massive format shift. We moved from legacy 2-byte identifiers, capped at 65,536 unique values, to a 4-byte space offering billions of addresses. The Internet Engineering Task Force mandated this transition in 2007. While the format distinction has largely vanished in modern software, the operational divide between private and public blocks remains a critical planning variable.

Your network's role dictates its identifier. Multi-homed enterprises and transit providers use these numbers to maintain connectivity when upstream links fail or when data must traverse unassociated networks. Confusing a stub AS configuration with a complex transit role invites routing leaks. Adhering to RFC 1930 and RFC 5396 isn't just about compliance; it's about preventing your infrastructure from becoming a vector for global instability.

The Role of Autonomous System Numbers in Global Routing Architecture

Autonomous System Numbers and Routing Policy Definition

An Autonomous System groups IP prefixes under a single, clearly-defined routing policy. To exchange path vector data with external Internet Service Providers, that system needs a unique identity. The shift from 2-byte to 4-byte identifiers solved the exhaustion crisis, supporting over four billion unique values. Databases show 89,497 assigned entries as of January 4, 2026, but distribution is uneven. Africa holds a tiny fraction of these assignments, concentrating risk where few identities represent vast user bases.

Don't request a number unless your policy demands it. Guidance strictly limits new assignments to cases where distinct policies justify the addition, preventing global table bloat. There is a hidden cost here: the "price" of an ASN includes the operational burden of maintaining that single, clearly-defined routing policy. You need skilled network engineers to manage it. InterLIR enables access to these critical identifiers, ensuring networks participate in global routing without unnecessary complexity.

2-Byte vs 4-Byte ASN Capacity and Ranges

The original 2-byte ASN is a 16-bit identifier. It offers exactly 65,536 unique values, ranging from 0 to 65,535. This finite pool forced strict conservation policies as adoption neared the 16-bit space ceiling. The 4-byte ASN acts as a 32-bit number, providing 4,294,967,296 ASNs, ranging from 0 to 4,294,967,295. The expanded format supports numbers specifically from 131,072 to 4,294,967,294, effectively eliminating exhaustion concerns for new entrants.

The 2-byte space technically suffices for current recorded entries, but the architectural shift prevents future scarcity. Distinctions between 2-byte and 4-byte ASNs are now largely semantic; all ASNs should be considered 4-byte. Delaying this upgrade risks incompatibility with networks mandating the expanded format. The industry treats all modern assignments as 4-byte capable regardless of the specific value.

IANA Reserved Private ASN Blocks for Internal Networks

IANA reserved 1,023 numbers (64,512 to 65,534) for private use within internal networks. These identifiers let organizations run Border Gateway Protocol internally for traffic engineering without exposing routing details to the global internet. Private ranges cannot appear in the global routing table. Their utility is restricted to specific upstream connections or internal segments.

Large enterprises deploy these blocks to manage complex internal topologies while preserving scarce public resources for edge peering. The decision to transition to a 4-byte autonomous system number depends on scale; the reserved private 4-byte block offers a vast pool, reflecting the necessary shift toward scalable architecture. This boundary ensures internal flexibility does not compromise external reachability or consume limited global identity space.

Operational Mechanics of Multi-Homed and Transit Autonomous Systems

Stub, Multi-Homed, and Transit AS Functional Definitions

Topology dictates function. A stub AS connects to a single upstream provider, isolating its internal routing policy from carrying external traffic. Even with private links, they appear as a single endpoint to the global internet infrastructure. A multi-homed AS connects to two or more distinct providers. This redundancy ensures the network maintains its Internet connection should one AS connection fail. Organizations request unique identifiers to control routing within their networks and exchange information with other Internet Service Providers (ISPs).

A transit AS actively forwards packets between unrelated networks, serving as the backbone for global data exchange. ISPs typically operate this model, selling access to the rest of the internet system. The distinction lies in path selection: stubs accept default routes, while transit providers act as a link between two or more other ASes, allowing data to pass through even from unassociated networks. Misconfiguration in a multi-homed setup can accidentally leak routes, turning redundancy into a liability. An Autonomous System is a group of IP prefixes run by network operators maintaining a single, clearly-defined routing policy. Precise functional definition during design prevents costly policy errors in production.

ISP Transit AS Implementation for Customer Network Access

A transit AS bridges customer networks to the broader internet, carrying data across unassociated domains. ISPs offer customers access to other networks and the Internet via transit AS. They use this architecture to grant clients access to external resources via BGP routing sessions that propagate reachability globally. Standard 16-bit ASNs apply a range between 1 and 65,534, providing a finite pool of approximately 65,000 unique identifiers for early internet infrastructure. Operators configure routing policies to define traffic movement between their network and upstream providers.

Public identifiers enable global visibility; private numbers remain restricted to internal segments or specific upstream links. Optimizing IPv4 addressing within these transit frameworks remains necessary as legacy infrastructure persists.

BGP Routing Policy Failures in Multi-Homed Connections

Multi-homed connections demand careful management to ensure traffic follows the intended path during outages. Operators configure import policies to prefer specific upstream paths, forcing routers to select the correct peer rather than relying on defaults. Mechanisms rely on manipulating the AS path length or applying specific preference values. Without these adjustments, the routing protocol fails to distinguish between available paths effectively. Publishing these policies in the Internet Routing Registry requires adherence to syntax standards set in Requests for Comments (RFCs). Misconfiguration can leave a network up but unreachable from external peers. Complexity spikes when organizations share identifiers across disjointed management domains, complicating consistent export rules.

The administrative burden of maintaining unique policies can be prohibitive without expert guidance. The total number of recorded Autonomous System Number (ASN) entries in global databases reached 89,497 as of January 4, 2026. Assisting organizations in structuring these routing policies helps guarantee failover integrity while optimizing existing IPv4 resources.

Strategic Selection Criteria for Private versus Public ASN Allocation

Defining Private ASN Scope for Internal Routing Policies

Private ASNs function exclusively within networks maintaining a single, clearly-defined routing policy invisible to the global internet. IANA reserved specific blocks: 1,023 numbers in the 2-byte space (64,512–65,534). These identifiers allow operators to run Border Gateway Protocol for traffic engineering without exposing internal topology. Unlike public allocations, private numbers are stripped by upstream providers before routes enter the global routing table.

Private ranges conserve public resources but are restricted to limited situations like internal networks or specific upstream ISP connections. They cannot be visible in the global routing table. Operators must evaluate whether their network architecture will eventually demand direct interconnection. Networks with their own ASN can implement complex traffic engineering and security policies based on their own criteria, while networks without one must rely on the default routing policies of their upstream providers. Private ASNs suit non-transit stub systems or temporary migration states where global reachability is not required.

Mapping Stub and Multi-Homed Topologies to ASN Types

Single-homing scenarios restrict traffic to one upstream provider, allowing operators to apply private ASN ranges without global exposure. These stub AS configurations function effectively within internal boundaries because upstream peers strip non-routable identifiers before advertising routes to the internet infrastructure. Public visibility is unnecessary when a network lacks alternate exit points.

Multi-homed architectures connect to two or more ASes to maintain their Internet connection should one AS connection fail. Unlike private identifiers, public numbers ensure routing policy consistency when a network connects to two or more autonomous systems for redundancy. Acquiring an ASN through a Regional Internet Registry (RIR) grants direct control and a unique identity. Relying on an ISP's ASN often means sharing a routing policy and lacking independent control over path selection. Networks with their own ASN can implement complex traffic engineering and security policies based on their own criteria, while networks without one must rely on the default routing policies of their upstream providers, limiting their ability to optimize data paths.

Private ASNs are technically restricted from appearing in the global routing table, limiting their utility to specific internal or ISP-facing situations.

Selecting a private identifier for a multi-homed setup creates a dependency on upstream filtering logic since private ranges are stripped at the network edge. Operators should validate topology requirements against current BGP configuration capabilities before finalizing resource requests.

Public Transit AS Requirements Versus Private ASN Limits

Transit architectures mandate globally unique identifiers because private ranges lack the visibility required for global BGP routing sessions. A transit AS acts as a link between two or more other ASes, allowing for data to pass through it, even data from unassociated networks. The legacy 16-bit (2-byte) system offers a finite pool of approximately 65,000 unique identifiers (specifically range 1–65,534).

Operators attempting to pass traffic between unassociated networks using reserved numbers face immediate rejection. Upstream peers strip these identifiers before they enter the global routing table. Private ASNs function exclusively within a single administrative domain, rendering them incapable of supporting the complex peering relationships necessary for internet service provision. The fundamental limitation lies in routing policy enforcement; a transit AS must advertise reachability to third parties, a capability restricted to public allocations.

While internal segmentation benefits from the obscurity of reserved blocks, extending this logic to external connectivity breaks the internet infrastructure trust model. A network acting as a bridge for external data must present a verifiable identity to prevent routing leaks. Consequently, the question of whether to use a private ASN resolves strictly to internal topology needs rather than external expansion plans. Organizations requiring global reach must engage their specific Regional Internet Registry to secure valid public resources.

Executing ASN Registration and BGP Configuration Workflows

ARIN Account Prerequisites for ASN Registration

Initiating an ASN request requires a verified ARIN Account Management profile before any resource application begins. This gateway step validates organizational identity, ensuring the entity described in the request matches the legal organization holding the account. Operators must define a single, clearly-set routing plan to satisfy technical assignment criteria.

1. Navigate to the Requesting IP Addresses or ASNs portal entry point.
2. Verify that contact information aligns with the documentation intended for submission.

Accurate initial account setup is vital to avoid processing delays. InterLIR advises verifying all organizational data fields prior to submission. The following resources are available for getting started: ARIN Account Management Requesting IP Addresses or ASNs.

This strict gatekeeping prevents fragmented resource allocation across the global internet infrastructure.

Executing ASN Requests via ARIN Registration Services

Submitting an ASN request begins by defining a unique routing plan or listing two upstream ISPs for multi-homing.

1. Log into the ARIN Account Management portal to verify organizational details.
2. Navigate to the Requesting IP Addresses or ASNs interface to start the application.
3. Provide a projected usage date, as the previous 30-day requirement no longer applies.
4. Reach staff via phone at +1.703.227.0660 or fax at +1.703.997.8844 if urgent assistance is required.

Since the IETF proposed a gradual transition to 4-byte ASNs in 2007, the process has streamlined, but precision remains key.

References

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