Hubbry Logo
Autonomous system (Internet)Autonomous system (Internet)Main
Open search
Autonomous system (Internet)
Community hub
Autonomous system (Internet)
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Autonomous system (Internet)
Autonomous system (Internet)
Autonomous system (Internet)
View on Wikipedia
from Wikipedia

An autonomous system (AS) is a collection of connected Internet Protocol (IP) routing prefixes under the control of one or more network operators on behalf of a single administrative entity or domain, that presents a common and clearly defined routing policy to the Internet.[1] Each AS is assigned an autonomous system number (ASN), for use in Border Gateway Protocol (BGP) routing. Autonomous System Numbers are assigned to local Internet registries (LIRs) and end-user organizations by their respective regional Internet registries (RIRs), which in turn receive blocks of ASNs for reassignment from the Internet Assigned Numbers Authority (IANA). The IANA also maintains a registry of ASNs which are reserved for private use (and should therefore not be announced to the global Internet).

Originally, the definition required control by a single entity, typically an Internet service provider (ISP) or a very large organization with independent connections to multiple networks, that adhered to a single and clearly defined routing policy.[2] In March 1996, the newer definition came into use because multiple organizations can run BGP using private AS numbers to an ISP that connects all those organizations to the Internet. Even though there may be multiple autonomous systems supported by the ISP, the Internet only sees the routing policy of the ISP. That ISP must have an officially registered ASN.

Until 2007, AS numbers were defined as 16-bit integers, which allowed for a maximum of 65,536 assignments. Since then,[3] the IANA has begun to also assign 32-bit AS numbers to regional Internet registries. These numbers are written preferably as simple integers, in a notation referred to as "asplain",[4] ranging from 0 to 4,294,967,295 (hexadecimal 0xFFFF FFFF). Or, alternatively, in the form called "asdot+" which looks like x.y, where x and y are 16-bit numbers. Numbers of the form 0.y are exactly the old 16-bit AS numbers. The special 16-bit ASN 23456 ("AS_TRANS")[5] was assigned by IANA as a placeholder for 32-bit ASN values for the case when 32-bit-ASN capable routers ("new BGP speakers") send BGP messages to routers with older BGP software ("old BGP speakers") which do not understand the new 32-bit ASNs.[6]

The first and last ASNs of the original 16-bit integers (0 and 65,535) and the last ASN of the 32-bit numbers (4,294,967,295) are reserved[7][8][9] and should not be used by operators; AS0 is used by all five RIRs to invalidate unallocated space.[10] ASNs 64,496 to 64,511 of the original 16-bit range and 65,536 to 65,551 of the 32-bit range are reserved for use in documentation.[11] ASNs 64,512 to 65,534 of the original 16-bit AS range, and 4,200,000,000 to 4,294,967,294 of the 32-bit range are reserved for Private Use.[12]

The number of unique autonomous networks in the routing system of the Internet exceeded 5,000 in 1999, 30,000 in late 2008, 35,000 in mid-2010, 42,000 in late 2012, 54,000 in mid-2016 and 60,000 in early 2018.[13] By December 2020, the number of allocated ASNs exceeded 100,000. As of 2025, there are roughly 120,000 allocated ASNs.[14]

Assignment

[edit]

AS numbers are assigned in blocks by Internet Assigned Numbers Authority (IANA) to regional Internet registries (RIRs). The appropriate RIR then assigns ASNs to entities within its designated area from the block assigned by IANA. Entities wishing to receive an ASN must complete the application process of their RIR, LIR or upstream service provider[15][16] and be approved before being assigned an ASN. Current IANA ASN assignments to RIRs can be found on the IANA website.[17] RIRs, as part of NRO, can revoke AS numbers as part of their Internet governance abilities.[18]

There are other sources for more specific data:

ASN table

[edit]

A complete table of available 16-bit and 32-bit ASN:[17]

Number Bits Description Reference
0 16 Reserved for RPKI unallocated space invalidation[19] RFC 6483, RFC 7607
1–23455 16 Public ASNs
23456 16 Reserved for AS Pool Transition RFC 6793
23457–64495 16 Public ASNs
64496–64511 16 Reserved for use in documentation and sample code RFC 5398
64512–65534 16 Reserved for private use RFC 1930, RFC 6996
65535 16 Reserved RFC 7300
65536–65551 32 Reserved for use in documentation and sample code RFC 5398, RFC 6793
65552–131071 32 Reserved
131072–4199999999 32 Public 32-bit ASNs
4200000000–4294967294 32 Reserved for private use RFC 6996
4294967295 32 Reserved RFC 7300

Types

[edit]

Autonomous systems (AS) can be grouped into four categories, depending on their connectivity and operating policy.

  1. multihomed: An AS that maintains connections to more than one other AS. This allows the AS to remain connected to the Internet in the event of a complete failure of one of their connections. However, unlike a transit AS, this type of AS would not allow traffic from one AS to pass through on its way to another AS.
  2. stub: An AS that is connected to only one other AS. This may be an apparent waste of an AS number if the network's routing policy is the same as its upstream AS's. However, the stub AS may have peering with other autonomous systems that is not reflected in public route-view servers. Specific examples include private interconnections in the financial and transportation sectors.
  3. transit: An AS that acts as a router between two ASes is called a transit. Since not all ASes are directly connected with every other AS, a transit AS carries data traffic between one AS to another AS to which it has links.[20]
  4. Internet Exchange Point (IX or IXP): A physical infrastructure through which ISPs or content delivery networks (CDNs) exchange Internet traffic between their networks (autonomous systems). These are often groups of local ISPs that band together to exchange data by splitting the costs of a local networking hub, avoiding the higher costs (and bandwidth charges) of a Transit AS. IXP ASNs are usually transparent. By having presence in an IXP, ASes shorten the transit path to other participating ASes, thereby reducing network latency and improving round-trip delay.[20][21]

AS-SET

[edit]

Autonomous systems can be included in one or more AS-SETs, for example AS-SET of RIPE NCC "AS-12655" has AS1, AS2 and AS3 as its members,[22] but AS1 is also included in other sets in ARIN (AS-INCAPSULA) and APNIC (AS-IMCL). Another AS-SET sources can be RADB, LEVEL3 (tier 1 network now called Lumen Technologies) and also ARIN has ARIN-NONAUTH source of AS-SETs.[23] AS-SETs are created by network operators in an Internet Routing Registry (IRR), like other route objects, and can be included in other AS-SETs and even form cycles.[24][25]

AS-SET names usually start with "AS-", but can also have a hierarchical name. For example, the administrator of AS 64500 may create an AS-SET called "AS64500:AS-UPSTREAMS", to avoid conflict with other similarly named AS-SETs.[26]

AS-SETs are often used to simplify management of published routing policies. A routing policy is published in the IRR using "import" and "export" (or the newer "mp-import" and "mp-export") attributes, which each contain the source or destination AS number and the AS number imported or exported. Instead of single AS numbers, AS-SETs can be referenced in these attributes, which simplifies management of complex routing policies.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Autonomous system (Internet)

View on Grokipedia
from Grokipedia
An autonomous system (AS) is a set of routers and networks under a single technical administration that uses an interior gateway protocol (IGP) and presents a common routing policy to the Internet. These systems form the foundational building blocks of Internet routing, enabling scalable exchange of routing information between distinct administrative domains. Autonomous systems interconnect primarily through the Border Gateway Protocol (BGP), an exterior gateway protocol designed for TCP/IP networks that allows ASes to advertise their reachable IP prefixes and learn routes from other ASes. This inter-domain routing mechanism ensures packets traverse the global Internet efficiently while respecting each AS's policy decisions, such as path selection based on business agreements or traffic engineering needs. Within an AS, internal routing is managed by protocols like OSPF or IS-IS to maintain connectivity among its components. Each AS is identified by a globally unique Autonomous System Number (ASN), which facilitates BGP's operation by tagging routes with their originating AS. Originally 16-bit values providing 65,536 possible ASNs (ranging from 0 to 65,535), the format was expanded to 32 bits in 2007 via RFC 4893 (updated by RFC 6793 in 2012) to support continued Internet growth, now allowing up to 4.29 billion ASNs. The allocates blocks of ASNs to the five Regional Internet Registries (RIRs)—ARIN, , , , and —which further distribute them to organizations based on demonstrated need and regional policies. As of November 2025, over 119,000 ASNs have been delegated worldwide, reflecting the decentralized structure of the with participants ranging from large Internet service providers to small enterprises and content networks. Private ASNs (64512–65534 for 16-bit and certain 32-bit ranges) are reserved for internal use, such as in mergers or confederations, without advertisement to the public . This numbering system underpins the Internet's resilience and policy-driven routing, though it also introduces challenges like route leaks and that require ongoing security measures.

Fundamentals

Definition

An autonomous system (AS) is a collection of connected Internet Protocol (IP) routing prefixes under the control of one or more network operators on the Internet. These routing prefixes consist of lists of IP addresses that define ranges accessible within the network, typically forming contiguous blocks to represent efficient address allocations. Within an AS, the connected prefixes enable internal routing autonomy, allowing operators to manage traffic and policies among their own networks without external interference. Externally, the AS presents a single, common policy to other networks, ensuring consistent advertisement of its and decisions. This policy is announced to the broader via the (BGP), which facilitates inter-AS communication. Entities operating ASes include Internet service providers (ISPs), which manage large-scale connectivity; large organizations and enterprises requiring independent control; and content providers like (AS15169) or (AS8075) that optimize global traffic delivery.

Role in Routing

Autonomous systems (ASes) form the cornerstone of interdomain on the , serving as the primary units through which external routes are advertised and exchanged between distinct administrative domains. The (BGP), defined as the de facto inter-AS protocol, enables ASes to share reachability information for IP prefixes originating from other ASes, allowing routers in one AS to learn paths to destinations in remote ASes. This exchange occurs at the borders of ASes, where BGP speakers establish sessions to propagate reachability information (NLRI), ensuring scalable global connectivity without requiring a centralized authority. A key mechanism in BGP for maintaining routing integrity across ASes is the AS_PATH attribute, which is a well-known mandatory attribute appended to BGP UPDATE messages. This attribute consists of a sequence of AS numbers representing the ASes through which the route advertisement has passed, prepended by the originating AS at each hop. To prevent routing loops, BGP implementations scan the AS_PATH upon receiving an UPDATE; if the local AS number appears anywhere in the path, the route is deemed invalid and excluded from the best-path selection process, as this indicates a potential loop. This loop-detection feature is essential for the stability of interdomain routing, where paths can span thousands of ASes, and ensures that transient misconfigurations do not propagate indefinitely. In contrast to inter-AS routing, which relies on BGP for policy-driven decisions across administrative boundaries, intra-AS routing employs interior gateway protocols (IGPs) such as OSPF to optimize paths within the confines of a single AS. OSPF, a link-state protocol, computes shortest paths based on metrics like link cost inside the AS, distributing information to all internal routers for consistent forwarding. BGP, however, does not assume uniformity in internal routing protocols across ASes and focuses instead on interdomain exchanges, where considerations—such as agreements and transit costs—override simple metrics. This separation allows each AS to maintain internal efficiency while participating in the broader routing fabric. ASes play a pivotal role in policy-based routing, empowering operators to enforce customized routing decisions that reflect commercial and operational priorities. For instance, ASes facilitate traffic engineering by selectively advertising or filtering routes to influence path selection, such as preferring certain peers for cost savings or load balancing outbound traffic across multiple providers. Route filtering at AS borders, often based on prefix lists or community attributes in BGP, enables granular control over which paths are accepted or propagated, mitigating issues like route leaks and supporting security measures. The AS itself represents the granularity of routing policy, where a collection of IP routing prefixes under common administrative control defines the scope for such decisions.

History and Evolution

Origins

The concept of an autonomous system (AS) in the emerged during the late 1970s and early as part of the 's evolution, driven by the need to interconnect disparate networks under separate administrative authorities while maintaining independent routing policies. Initially, the ARPANET relied on a core of gateway routers managed centrally, but as satellite networks and regional systems proliferated, the (EGP) was developed to facilitate communication between these entities. EGP, first specified in RFC 827 in 1982, defined an AS as a collection of gateways and networks under unified administrative control, enabling reachability exchanges without imposing a global routing hierarchy. This approach addressed the limitations of earlier protocols like the Gateway-to-Gateway Protocol (GGP), allowing the ARPANET to scale by treating peripheral networks as "stub" ASes connected to a core AS. The establishment of the NSFNET backbone in 1986 further propelled the AS model's adoption, as it connected supercomputer centers and regional networks into a cohesive . Under NSF sponsorship, the Merit Network implemented EGP for inter-domain , partitioning the growing into multiple ASes to manage policy-based decisions and prevent loops across administratively distinct domains. Each regional backbone was assigned an AS number, with the NSFNET itself operating as a distinct AS to coordinate , marking a shift from ARPANET's monolithic structure to a federated system of entities. This configuration supported the 's expansion beyond military and research use, emphasizing autonomy to accommodate diverse operational policies. In 1989, the Internet Engineering Task Force (IETF) formalized the AS concept through key publications, adapting Open Systems Interconnection (OSI) routing frameworks to the multi-provider Internet environment. RFC 1136, authored by Marshall T. Rose, introduced administrative domains as equivalents to ASes, providing a model for scalable routing across independent providers by distinguishing interior (intra-AS) from exterior (inter-AS) mechanisms. Concurrently, RFC 1105 specified Border Gateway Protocol version 1 (BGP-1), developed by Yakov Rekhter and Kirk Lougheed within IETF efforts, as an advanced inter-AS routing protocol succeeding EGP's limitations in handling complex topologies. These contributions, emerging from IETF working groups on inter-domain routing, solidified AS autonomy as a foundational principle for the Internet's decentralized architecture. BGP served as the enabling protocol for AS interactions, propagating reachability information while respecting administrative boundaries.

ASN Development

The initial 16-bit Autonomous System Number (ASN) space, ranging from 0 to 65,535, was defined in early (BGP) specifications, such as RFC 1771, which established ASNs as 16-bit integers for use in path attributes like AS_PATH. This limited namespace supported the Internet's routing needs in the 1990s but faced projected exhaustion in the 2000s due to accelerating network growth and increasing demand for unique identifiers. By the early 2000s, analyses indicated that consumption rates would deplete the pool by the end of the decade if trends continued, prompting proactive planning for expansion. To avert routing disruptions, the (IETF) standardized 32-bit ASNs in RFC 4893 (2007), extending the addressable range to over 4 billion numbers (0 to 4,294,967,295) while maintaining with existing 16-bit infrastructure through transitional mechanisms like the AS4_PATH attribute. Deployment commenced that year, with Regional Internet Registries (RIRs) such as the beginning to assign 32-bit ASNs by default to organizations requesting them, though adoption was gradual as network operators upgraded BGP implementations. Full operational enablement in BGP-4 followed with RFC 6793 (2012), which updated core protocol elements—including AS_PATH, AS4_PATH, and aggregator attributes—to natively handle four-octet ASNs, obsoleting interim workarounds and ensuring seamless global propagation of extended paths. The critical turning point arrived in 2011, when the 16-bit ASN pool reached exhaustion, compelling all RIRs to mandate 32-bit assignments for new allocations and accelerating vendor support across the ecosystem. This event underscored the pressures from expansion, particularly the surge in multihomed networks—where end-user organizations connect to multiple Internet Service Providers (ISPs) for and load balancing—each necessitating a distinct ASN to advertise independent routing policies. Such configurations, once rare, became commonplace at the network edge, amplifying ASN consumption beyond initial forecasts. As of November 2025, the expanded 32-bit namespace sustains over 119,000 allocated ASNs across all RIRs, with approximately 85,000 actively advertising routes in the global BGP table, demonstrating the scalability achieved through these developments amid ongoing proliferation.

Numbering and Assignment

ASN Structure

Autonomous System Numbers (ASNs) are assigned as unsigned values to uniquely identify autonomous systems on the . Originally designed as 16-bit numbers, ASNs range from 0 to 65,535, providing a total of possible values. To address the exhaustion of the 16-bit space, ASNs were extended to 32 bits in 2007, allowing values from 0 to and vastly increasing the available pool. Certain ranges within the ASN space are reserved for specific purposes by the (IANA), including private use, , and special operational needs. For 16-bit ASNs, the range 64,512 to 65,534 is designated for private use, enabling internal network configurations without global conflicts. The value 0 and 65,535 are reserved to prevent their use in production environments. purposes utilize 64,496 to 65,511, and for 32-bit ASNs, the range is 65,536 to 65,551, allowing example ASNs in technical specifications without real-world allocation. For 32-bit ASNs, private use extends to 4,200,000,000 to 4,294,967,294, while 4,294,967,295 remains reserved. IANA also assigns special-purpose ASNs for operational utilities, such as 112, which is dedicated to the AS112 project for sinking misdirected DNS queries related to private IP addresses via anycast deployment. Another notable special use is 23,456, reserved as AS_TRANS for transitioning between 16-bit and 32-bit ASN representations in BGP. In the Border Gateway Protocol (BGP), ASNs are encoded in binary format within attributes like AS_PATH to propagate routing information. Traditional BGP implementations use a 16-bit (2-byte) field for each ASN in the AS_PATH attribute. To support 32-bit ASNs, BGP was extended with a capability negotiation mechanism; capable peers exchange 4-byte (32-bit) representations, often using the AS4_PATH attribute as a parallel structure to the legacy AS_PATH during the transition period. The following table summarizes the major ASN ranges and their purposes:
ASN RangeBit LengthPurposeReference
016-bitReservedRFC 7300
1 - 64,49516-bitPublic assignmentsIANA AS Registry
64,496 - 64,51116-bitDocumentationRFC 5398
65,536 - 65,55132-bitDocumentationRFC 5398
64,512 - 65,53416-bitPrivate useRFC 6996
65,53516-bitReservedRFC 7300
65,536 - 4,199,999,99932-bitPublic assignmentsIANA AS Registry
4,200,000,000 - 4,294,967,29432-bitPrivate useRFC 6996
4,294,967,29532-bitReservedRFC 7300
112BothAS112 project (anycast sink)RFC 7534
23,456BothAS_TRANS (32-bit transition)RFC 6793

Allocation Process

The Internet Assigned Numbers Authority (IANA) serves as the top-level coordinator for the global allocation of Autonomous System Numbers (ASNs), delegating blocks of these numbers to the five Regional Internet Registries (RIRs): the American Registry for Internet Numbers (ARIN), RIPE Network Coordination Centre (RIPE NCC), Asia-Pacific Network Information Centre (APNIC), Latin America and Caribbean Network Information Centre (LACNIC), and African Network Information Centre (AFRINIC). IANA allocates these blocks in units of 1024 ASNs to an RIR when at least 80% of its previously allocated block has been assigned or allocated, or when the RIR's available pool is insufficient to cover its projected needs for the next two months, based on a six-month average usage rate. Each RIR receives initial blocks upon establishment, with subsequent allocations sized to meet at least 12 months of projected demand, though smaller blocks may be requested if justified. At the RIR level, ASNs are assigned to end users and Internet service providers based on regional policies that emphasize demonstrated need, particularly for multi-homing to multiple upstream providers for , load balancing, or performance reasons. To qualify, applicants must typically justify their request with details of planned interconnections to at least two independent networks, along with supporting such as network diagrams or agreements; single-homing scenarios generally do not warrant a ASN assignment. Some RIRs impose wait periods or review processes to manage demand, with ARIN, for instance, providing initial review within two business days and issuing approved ASNs within two business days. The assignment process begins with an applicant submitting a formal request to their serving RIR via online forms or , providing organizational details, technical justification, and proof of holdings. The RIR reviews the submission for compliance with criteria, potentially requesting additional information or conducting audits; upon approval, the smallest available block—typically a single ASN—is assigned from the RIR's pool, with registration details published in the relevant database. As of 2025, all allocations and assignments utilize 32-bit ASNs exclusively, following the exhaustion of the 16-bit space in 2011, with no distinction made between formats; considerations are fully integrated, where ASNs support BGP routing for deployments without separate justification beyond overall multi-homing needs. Public ASNs, which are globally unique and routed on the public , contrast with private ASNs used internally within a single organization's networks.

Types and Configurations

ASN Variants

Autonomous System Numbers (ASNs) are classified into variants based on their scope of use, uniqueness, and role in protocols such as BGP. These variants ensure efficient management of information while preventing conflicts in global and internal network environments. The primary categories include public ASNs for Internet-wide , private ASNs for non-global networks, and documentation ASNs for illustrative purposes. Public ASNs are globally unique identifiers allocated to autonomous systems that engage in inter-domain across the public . They are essential for establishing peering and transit relationships between different ASes, allowing the exchange of information via BGP. These ASNs are assigned by Regional Internet Registries (RIRs), such as ARIN, , and , which receive blocks from IANA. For 16-bit ASNs, the public range spans 1 to 64495, while 32-bit public ASNs cover 65552 to 4,199,999,999, excluding reserved blocks. Private ASNs, also known as Private Use ASNs, are not globally unique and are reserved exclusively for internal network deployments, such as within enterprise MPLS VPNs or data centers, where they facilitate BGP sessions without impacting the public . These ASNs must be stripped or filtered from AS_PATH attributes in BGP updates before advertisement to external peers to avoid loops or conflicts. The designated ranges are 64512 to 65534 for 16-bit ASNs (providing 1,023 numbers) and 4,200,000,000 to 4,294,967,294 for 32-bit ASNs (offering 94,967,295 numbers). Operational guidelines recommend that EBGP implementations support 32-bit ASN extensions as per RFC 6793 to handle these in mixed environments. Documentation ASNs are specifically reserved for use in technical specifications, RFCs, textbooks, and sample to illustrate network configurations without risking collisions with production ASNs. They are not permitted in operational networks and BGP implementations should reject peering attempts using these numbers. The allocated blocks consist of 64496 to 64511 for 16-bit ASNs and 65536 to 65551 for 32-bit ASNs, each providing 16 contiguous numbers suitable for examples involving multiple AS interactions.

AS-SETs

An AS-SET is a registry object defined in the Internet Routing Registries (IRRs) maintained by Regional Internet Registries (RIRs), used to group one or more Autonomous System Numbers (ASNs) or other AS-SETs into a named collection for specifying policies. This object facilitates the management of interdomain by allowing operators to reference a single set name rather than listing individual ASNs, enhancing efficiency in policy definitions stored in databases. In (BGP) configurations, AS-SETs are applied within prefix-lists or AS-path lists (ACLs) to filter and authorize route announcements from peered autonomous systems. For instance, in Routing Policy Specification Language (RPSL) route objects, an AS-SET can define the originating or neighboring ASes from which prefixes are accepted or exported, enabling automated generation of inbound and outbound filters to enforce agreements. This usage ensures that only routes from trusted AS groups propagate, reducing the risk of accepting unauthorized announcements. AS-SETs are created and managed through RPSL submissions to RIR databases, such as those operated by , , or ARIN, where the object includes mandatory attributes like the set name (starting with "AS-") and a members list that can reference individual ASNs or nested sets. Hierarchical AS-SETs, authenticated by the originating ASN holder, support structures like AS-CONE, which encompasses an ASN and all its downstream customer ASes, allowing dynamic inclusion of subordinate networks without manual updates. Only hierarchical names are now permitted for new creations in many RIRs to enforce ownership verification and prevent unauthorized modifications. At Internet Exchange Points (IXPs), route servers commonly leverage AS-SETs to enforce multilateral policies, where members register their AS-SETs containing advertised ASes, enabling the route server to filter announcements and distribute only validated routes among participants. This practice provides security benefits by supporting IRR-based validation of route origins, helping to mitigate BGP prefix hijacks and leaks through pre-configured filters that reject non-matching AS paths.

Operational Concepts

AS Types

Autonomous systems (ASes) are classified primarily based on their connectivity patterns and roles in Internet routing, which determine how they exchange traffic via the (BGP). This classification includes stub ASes, multihomed ASes, and transit ASes, each serving distinct functions in the global network topology. A stub AS connects to only one upstream provider AS and announces its own IP prefixes to the but does not permit transit traffic—meaning it neither carries nor forwards traffic between other external ASes. These ASes represent endpoint networks, such as enterprise or content provider networks, that rely on their single upstream for all external connectivity. In contrast, a multihomed AS maintains connections to multiple upstream provider ASes to achieve and load balancing, while still refraining from providing transit services to other ASes. This setup enhances reliability by allowing if one upstream fails, but the AS originates only its own prefixes and uses the multiple links solely for its outbound and inbound traffic. Transit ASes, often operated by Internet service providers (ISPs), provide connectivity between other ASes by carrying both local traffic and transit traffic destined for external networks. They act as carriers in the hierarchy, enabling across the network; for example, Tier 1 ISPs like those operated by major global backbones form the uppermost layer without paying for transit themselves. ASes can also be categorized as edge or core based on their position in the topology: edge ASes (including most stubs and multihomed) connect primarily to core ASes and handle local or customer traffic, while core ASes (transit providers) interconnect the broader Internet. Sibling ASes, which are multiple ASes under common administrative control, often function as edge or core variants to enable advanced traffic engineering or policy separation within the same organization. Anycast ASes support distributed services by announcing the same IP prefixes from multiple geographic locations, typically within a single AS or coordinated sibling ASes, to optimize latency and resilience for applications like DNS resolution. As of 2025, the comprises approximately 77,500 ASes, with the majority—around 84%—classified as stub or multihomed edge ASes that do not provide transit. Transit ASes number about 12,200, forming the backbone of global , while the default-free zone, where routers maintain full BGP tables without defaults, is primarily sustained by these transit providers and select large multihomed ASes; Tier 1 networks, numbering around 19, anchor this zone by directly without upstream dependencies.

Peering and Transit

Peering refers to the settlement-free interconnection between two autonomous systems (ASes) that allows the mutual exchange of traffic without monetary compensation, typically occurring at Internet exchange points (IXPs) or through private interconnects. This arrangement is predicated on the principle of roughly equal traffic volumes exchanged between the networks, ensuring mutual benefit and cost sharing. For instance, networks establish peering sessions using the Border Gateway Protocol (BGP) to directly route traffic destined for each other's customers or content, bypassing third-party intermediaries. In contrast, transit is a paid connectivity service where one AS purchases access from a transit provider to reach the broader . The customer AS pays the transit provider, often on a metered basis using the 95th percentile billing method per megabit per second, in exchange for the provider advertising the customer's routes globally and delivering inbound traffic. This model enables smaller or regional ASes to connect to the full without maintaining extensive direct interconnections, with the transit provider handling to upstream networks and beyond. The distinction between settlement-free peering and paid transit models hinges on economic and operational criteria, including traffic ratios and route announcement policies. agreements commonly require traffic ratios not exceeding 2:1 or 3:1 inbound to outbound to maintain balance, preventing one network from subsidizing the other's costs disproportionately. Additionally, policies often restrict route announcements to the AS's own prefixes and those of its direct customers, avoiding the propagation of default routes or third-party that could turn into de facto transit. Tier 1 ASes, such as those operated by major providers like Level 3 (now Lumen) and , exemplify mutual among themselves, forming a global backbone where they exchange settlement-free due to their comparable scale and no need for upstream connectivity. These interconnection models significantly influence Internet performance and economics. reduces latency by enabling direct paths, often outperforming transit routes in 91% of AS paths due to fewer and lower delays, while also lowering costs by avoiding transit fees. Transit, while ensuring comprehensive , can introduce higher latency and expenses from multiple intermediaries. Both enhance resilience: diversifies paths to mitigate single-provider failures, and transit provides redundant global access, contributing to the Internet's overall . Peering and transit play a pivotal role in shaping the Internet's AS topology, often characterized as a "bow-tie" structure with a dense core of Tier 1 transit ASes that mutually peer to interconnect the network, flanked by incoming and outgoing peripheral ASes connected via paid transit. This core, comprising a small number of providers, handles the majority of global traffic exchange, enabling efficient scaling while peripherals rely on transit for access. As of 2025, trends show accelerated growth in direct arrangements driven by providers and content delivery networks (CDNs), reducing dependency on traditional transit. Enterprises and content-heavy ASes, such as those for and Google , increasingly establish private with cloud interconnects like AWS Direct Connect to bypass ISPs, optimizing latency and cutting egress costs amid rising demands from AI and streaming. IXPs facilitate this shift by supporting remote and cloud-specific , further flattening the .

References

  1. https://datatracker.ietf.org/doc/html/rfc1930
  2. https://www.iana.org/assignments/as-numbers
  3. https://www.arin.net/resources/guide/asn/
  4. https://www.ripe.net/manage-ips-and-asns/as-numbers/
  5. https://www-public.telecom-sudparis.eu/~maigron/rir-stats/rir-delegations/world/world-asn-by-number.html
  6. https://datatracker.ietf.org/doc/html/rfc6996
  7. http://web.mit.edu/6.033/2017/wwwdocs/papers/InterdomainRouting.pdf
  8. https://www.ripe.net/publications/docs/ripe-496/
  9. https://www.cloudflare.com/learning/network-layer/what-is-an-autonomous-system/
  10. https://glossary.zerogap.ai/AS-autonomous-system
  11. https://www.ipxo.com/blog/what-is-asn/
  12. https://datatracker.ietf.org/doc/html/rfc4271
  13. https://datatracker.ietf.org/doc/html/rfc3272
  14. https://autonomy.work/portfolio/opening-the-internet/
  15. https://www.rfc-editor.org/rfc/rfc823.html
  16. https://www.nsf.gov/impacts/internet
  17. https://www.ntp.org/reflib/papers/bone.pdf
  18. https://datatracker.ietf.org/doc/html/rfc1093
  19. https://datatracker.ietf.org/doc/html/rfc1136
  20. https://labs.ripe.net/author/dfk/16-bit-asn-exhaustion-some-data/
  21. https://archive.nanog.org/meetings/nanog28/presentations/huston.pdf
  22. https://labs.ripe.net/author/mirjam/assigning-32-bit-asns/
  23. https://datatracker.ietf.org/doc/html/rfc6793
  24. https://www.potaroo.net/ispcol/2005-08/
  25. https://labs.apnic.net/presentations/store/2005-09-07-asns.pdf
  26. https://www.nro.net/wp-content/uploads/NRO-Number-Resource-Status-Report-Q3-2025-FINAL.pdf
  27. https://bgp.potaroo.net/iso3166/ascc.html
  28. https://www.rfc-editor.org/rfc/rfc5398
  29. https://www.iana.org/assignments/iana-as-numbers-special-registry
  30. https://www.icann.org/resources/pages/global-policy-asn-blocks-2010-09-21-en
  31. https://www.arin.net/participate/policy/nrpm/
  32. https://www.ripe.net/publications/docs/ripe-679/
  33. https://www.apnic.net/community/policy/resources
  34. https://www.arin.net/resources/guide/request/
  35. https://www.rfc-editor.org/rfc/rfc5398.html
  36. https://datatracker.ietf.org/doc/html/rfc2622
  37. https://www.apnic.net/manage-ip/using-whois/guide/as-set/
  38. https://www.radb.net/support/informational/object-types.html
  39. https://docs.db.ripe.net/Set-Objects
  40. https://manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/
  41. https://manrs.org/2020/08/how-to-secure-routing-in-the-ixp-route-servers-infrastructure/
  42. https://www.incibe.es/en/incibe-cert/blog/enhancing-internet-security-irr-protection-against-incorrect-route-advertisements
  43. https://book.systemsapproach.org/scaling/global.html
  44. https://macronetservices.com/who-are-the-leading-global-tier-1-isps/
  45. https://www.usenix.org/system/files/woot25-schulmann.pdf
  46. https://blog.apnic.net/2023/03/21/improving-the-inference-of-sibling-autonomous-systems/
  47. https://blog.lacnic.net/en/anycast-internet-optimization-and-resilience/
  48. https://www.potaroo.net/ispcol/2025-06/daybgp.html
  49. https://www.kentik.com/kentipedia/what-is-internet-peering/
  50. https://www.thousandeyes.com/learning/techtorials/transit-provider
  51. https://www.caida.org/catalog/papers/2010_framework_peering_agreements/framework_peering_agreements.pdf
  52. https://www.gtt.net/us-en/resources/techtorials/what-are-the-benefits-of-working-with-a-tier-1-isp/
  53. https://www2.cs.arizona.edu/~bzhang/paper/05-ccr-topology.pdf
  54. https://www.de-cix.net/en/resources/white-papers/when-to-peer-and-when-to-use-transit
  55. https://www.kentik.com/kentipedia/ip-transit-vs-peering/
  56. https://arxiv.org/pdf/1201.0834
  57. https://netintel.co/2025/08/01/the-great-peering-shift-why-enterprises-are-bypassing-traditional-isps/
  58. https://macronetservices.com/tier-1-isps-a-comprehensive-guide-to-global-internet-connectivity/
Add your contribution
Related Hubs
User Avatar
No comments yet.