ASN Allocation: How Networks Receive Autonomous System Numbers

Quick Answer

A network receives a public Autonomous System Number through the applicable regional registry process. IANA allocates ASN resources to Regional Internet Registries, which assign numbers under their regional policies.

Receiving an ASN establishes a registered routing identifier. It does not automatically provide IP address space, Internet connectivity or an operational BGP deployment.

Four distinctions explain what ASN allocation actually means:

• ASN Assignment ≠ IP Address Allocation
• ASN Registration ≠ Operational BGP Use
• Registered Organization ≠ Every Customer Using the Network
• Technical Need ≠ RIR Eligibility Policy

The useful question is not simply which number a network received, but how that identifier relates to its address resources, registration records and observed routing activity.

Key Takeaways

• Public ASN assignment is coordinated through the Internet number registry system.
• Regional application channels and eligibility policies differ.
• A network’s reason for needing an ASN is separate from the registry’s requirements for issuing one.
• ASN records, IP prefix records and BGP observations describe different relationships.
• Private ASNs support scenarios where global uniqueness is unnecessary.
• Registered ASN holders are not necessarily the organizations operating every service reachable through their networks.
• Routing observations require a source and a timestamp; registration records alone cannot establish current BGP activity.

What Does an ASN Identify?

An Autonomous System Number identifies an autonomous system: a routing domain that presents a coherent routing policy to other networks. An AS can encompass multiple IP prefixes and should not be reduced to “one company” or “one block of addresses.” RFC 1930

A registered organization provides administrative context for the identifier. The autonomous system provides routing context.

For the broader introduction to autonomous systems and their role on the Internet, see What Is an ASN?.

Who Assigns Autonomous System Numbers?

IANA allocates ASN resources to the five Regional Internet Registries: AFRINIC, APNIC, ARIN, LACNIC and RIPE NCC. Those registries distribute numbers to network operators according to applicable regional policies. IANA AS Numbers Registry

The administrative model is:

IANA → RIR → Request / Eligibility → ASN Assignment → Registry Record

This is a conceptual model. It does not mean every applicant follows an identical procedure or deals directly with the RIR at every stage.

Some regions support additional application channels. APNIC policy, for example, allows applicants to request an ASN from APNIC or the relevant National Internet Registry. Other regional processes may involve a sponsoring Local Internet Registry. The applicant should use the channel supported by the applicable registry. APNIC ASN Policy, RIPE NCC ASN Assignment Policy

Allocation, Assignment and Registration

These terms describe related administrative actions:

Regional documents do not always use identical terminology. IANA itself describes RIRs as further allocating or assigning AS numbers. The distinction between administrative distribution and operational use matters more than forcing every source into one vocabulary.

How Does a Network Get an ASN?

A network requests an ASN through its applicable regional process, supplies the required information and completes the registry’s assignment requirements. The exact evidence and administrative arrangements depend on the registry and request type.

A general process has five parts:

1. Define the routing requirement. Identify what the ASN will represent and why the network needs a separate identifier.
2. Identify the applicable registry and request channel. Determine whether the request goes directly to the RIR or through a supported regional intermediary.
3. Submit the required information. This can include organization and contact details, routing plans and technical justification where required.
4. Complete the assignment process. The registry evaluates the request under its current rules and records an approved assignment.
5. Maintain the registration. Keep relevant records and contacts current and follow applicable resource-maintenance requirements.

These steps summarize the administrative task. Network deployment is a separate operational task.

Why Regional Requirements Cannot Be Generalized

Selected policy examples show why there is no universal rule that every ASN applicant must already be multihomed:

Sources checked September 14, 2026: ARIN NRPM §5, APNIC Resource Policies, AFRINIC Consolidated Policy Manual.

These are selected policy distinctions, not complete application checklists. Other administrative conditions can apply, and policy changes can alter the requirements.

Who Needs a Public ASN?

A public ASN is useful when a network needs its own globally unique autonomous-system identity for its routing architecture. Operating a company, website or local network does not automatically create that need.

A network using its provider’s routing arrangements may have no reason to establish a separate public AS. A network implementing an independent external routing policy may have a clear technical reason to do so. RFC 1930

The distinction is:

Technical Need ≠ RIR Eligibility Policy

Technical need explains the architecture. Eligibility determines whether a particular request meets the registry’s current rules. Neither should be inferred solely from the other.

Using BGP also does not automatically mean an organization needs its own public ASN. BGP speakers operate in an AS context, but that context can involve private numbers or an existing autonomous system, depending on the design.

How Do ASN, IP Prefix, Organization and BGP Origin Relate?

ASN, IP prefix, registered organization and observed BGP origin are separate entities connected by evidence. They should not be treated as interchangeable labels.

A useful analysis model is:

ASN → IP Prefix → Registered Organization → Observed BGP Origin

Read the arrows as relationships to investigate, not as an ownership chain or a sequence of automatic assignments.

RDAP defines separate structures for IP network and autonomous-system registration data. Looking up an ASN is therefore not equivalent to looking up the IP resources associated with its routing activity. RFC 9083

The model becomes useful when the answers differ. An ASN record might identify one organization, an IP prefix record another, and the service using an address a third. Those differences require interpretation; they are not automatically errors.

Does Receiving an ASN Provide IP Addresses?

No. An ASN assignment and an IP address allocation are separate resource actions.

A network can receive an ASN without that assignment supplying IPv4 or IPv6 prefixes. Conversely, an organization can use provider-supplied address space without receiving a separate public ASN. Internet number registries distinguish address resources from AS numbers. IANA Number Resources

ASN Assignment ≠ IP Address Allocation

An ASN does not “own” addresses. Appropriate organizations hold or use resources under the relevant registration and operational arrangements.

Can One ASN Originate Multiple Prefixes?

Yes. An autonomous system can originate routes for multiple IP prefixes. A prefix can also have different observed origins over time, or multiple origins in a particular dataset.

RIPEstat explicitly supports a list of originating ASNs for a prefix, including multi-origin cases. That is why a lookup should not assume an immutable one-prefix-to-one-ASN relationship. RIPEstat Prefix Overview

A change in observed origin does not, by itself, establish a transfer of the address resource.

Does ASN Registration Automatically Enable BGP Routing?

No. Registering an ASN does not configure routers, establish external connections or cause other networks to accept routes.

The operational model contains additional components:

ASN + Prefixes + Connectivity + Routing Relationships + Policy + BGP

This is a conceptual list of dependencies, not a guarantee of global reachability.

For a network originating routes, operational preparation includes suitable address resources, appropriate authorization, working connections, routing relationships and a configured routing system. BGP distributes reachability information between participating systems; receiving an ASN does not perform those operations. RFC 4271

ASN Registration ≠ Operational BGP Use

An assigned ASN can exist before deployment begins. It can also remain registered during a period when no originating routes are visible in a selected dataset.

Where Route-Origin Authorization Fits

A Route Origin Authorization specifies an ASN authorized to originate a route for an IP prefix, subject to its prefix-length conditions.

A ROA does not issue the ASN, configure BGP or prove that a route is currently being announced. Assignment, authorization and observation remain distinct processes. RFC 9582

Similarly, a commercial arrangement to use address space does not automatically provide an ASN or establish every required routing arrangement.

What Is the Difference Between Public and Private ASNs?

A public ASN is a globally coordinated identifier assigned for use by an autonomous system. A private ASN comes from a reserved range intended for environments where global uniqueness is unnecessary.

RFC 6996 reserves these inclusive private-use ranges:

• 64512-65534
• 4200000000-4294967294

Private ASNs can be reused in unrelated environments. They are not issued to each user as globally unique public assignments. RFC 6996

Private ASNs are not a complete substitute for a public identifier in global routing. RFC 6996 requires private ASNs to be removed from relevant AS-path attributes before routes are advertised to the global Internet.

Numbers outside the private ranges are not automatically available public ASNs. The IANA registry also contains reserved, documentation and other special-purpose values.

What Is the Difference Between 16-Bit and 32-Bit ASNs?

The original two-octet ASN field supported 16-bit numbers. Four-octet support expanded the number space to 32 bits while providing mechanisms for interoperability with older BGP implementations. RFC 6793

The expanded space includes the original numeric range. A 32-bit ASN is not a different quality of network identity, and the ASN’s size does not determine whether its network carries IPv4 or IPv6.

For written examples and records, ASPLAIN represents an ASN as an ordinary decimal integer. The notation recommendation is documented separately from the protocol extension. RFC 5396

What Is the Difference Between Registry Data and Routing Data?

Registry data describes resource registration. Routing data describes routes observed through a particular collection system. An IP intelligence database adds another layer of sourced or inferred metadata.

These sources answer different questions:

Registration Records Describe Administrative Relationships

An ASN registration can identify the assigned number and associated entities or contacts. An IP network record describes a different resource.

Even when both records display the same organization name, that does not mean every application, hosted service or customer using the network is operated by that organization. RFC 9083

Registered Organization ≠ Every Customer Using the Network

Routing Observations Need a Time and a Viewpoint

A routing dataset can report whether a prefix was observed and which origin ASN or ASNs appeared. The result must be interpreted within the dataset’s collection scope and time.

For example, RIPEstat Prefix Overview documents separate fields for announcement status and originating ASNs. Those observations serve a different purpose from its descriptive resource information. RIPEstat Prefix Overview

If an ASN is absent from the originating routes in a selected snapshot, the supported statement is limited: no originating route was observed there at that time. That does not establish that the ASN is unused everywhere or has no other operational role.

Metadata Labels Are a Third Layer

An IP intelligence label such as ISP, organization or network type must be interpreted according to the database that supplied it.

A reported organization name should not silently become “the registered ASN holder,” and a reported ASN should not silently become “the current origin verified by a route collector.” The field’s source and meaning matter.

What Can ASN Information Tell You About Proxy Infrastructure?

ASN information can provide network-level context for a proxy IP. It does not independently identify the proxy provider, the customer using the address or the address’s physical location.

A proxy endpoint may sit within a prefix whose observed origin belongs to a hosting or access-network operator serving many customers. The origin’s registered organization and the customer-facing proxy service can therefore be different entities.

The interpretation boundaries are:

• ASN ≠ Proxy Provider
• ASN ≠ Organization Currently Using an IP
• ASN ≠ Physical Location
• ASN ≠ IP Reputation

For the separate question of how address history and other signals influence treatment by websites, see How IP Reputation Works.

Practical Examples

The following examples are conceptual. They are not reports of completed Mango measurements.

Example 1: The Number Is Assigned, but Deployment Is Not Ready

A network receives a public ASN and its registration record becomes available. Its external connectivity and routing configuration are still being prepared.

The administrative process has produced an identifier. No conclusion about operational reachability follows from the registration alone.

The useful next question is which operational dependencies remain incomplete.

Example 2: One Origin, Several Prefixes and Many Customers

A hosting network originates several prefixes. Those prefixes contain services operated by different customers.

The origin ASN provides routing context. Its registration record identifies the organization associated with that ASN, but it does not enumerate every business using the hosted infrastructure.

A customer’s service IP should therefore not be interpreted as proof that the customer holds the ASN.

Example 3: The Observed Origin Changes

A prefix appears with one origin in an earlier routing snapshot and another origin in a later snapshot.

The observation establishes a change in the collected routing data. To understand the change, an analyst separately examines prefix registration, ASN registration and relevant authorization information.

The routing change alone does not prove a sale, lease, resource transfer or unauthorized announcement.

A Reproducible Registry-versus-Routing Comparison

A small comparison can make these distinctions concrete:

1. Select a public ASN and record the source and UTC collection time.
2. Retrieve the ASN’s RIR registration.
3. Identify prefixes associated with the ASN in a named routing dataset.
4. Retrieve each selected prefix’s registration separately.
5. Record observed origins, collection scope and any relevant authorization result.
6. State only the relationships supported by those observations.

A useful output table would contain:

ASN | ASN Registered Entity | Prefix | Prefix Registered Entity | Observed Origin(s) | Source | Timestamp | Limitation

This is a proposed methodology. No results are claimed here, and a small illustrative sample would not establish how all networks operate.

Separate the Resource Record from the Routing Question

Before requesting or investigating an ASN, identify the question you need to answer.

For an application, define the routing requirement and check the relevant registry’s current process. For an investigation, retrieve registration and routing evidence separately.

A number, an organization label and a routing observation become useful when their relationships are explicit.

Final Thoughts

An ASN becomes easier to interpret when every relationship is examined separately: the identifier assigned to the network, the prefixes involved, the organizations recorded against each resource and the routes visible in a particular observation.

That separation helps both applicants and analysts. Applicants can distinguish registration work from deployment work. Analysts can avoid turning a single lookup field into an unsupported claim about ownership, customers or reachability.

Glossary

Frequently asked questions

Here we answered the most frequently asked questions.

Ask a question

Can anyone get a public ASN?

Applicants must use the applicable regional process. Eligibility and administrative requirements differ, so neither automatic approval nor a universal multihoming requirement should be assumed.

Do you need your own public ASN to use BGP?

Not in every architecture. BGP can operate with private ASNs or within an existing autonomous system. The need for a separate public assignment depends on the intended routing role.

Does an ASN include IPv4 or IPv6 addresses?

No. ASN assignment and IP address allocation are separate resource processes. Receiving an ASN does not automatically provide prefixes.

Can one organization have multiple ASNs?

Yes. An organization can operate multiple autonomous systems where its architecture and applicable assignment rules support that arrangement. One organization and one ASN are not universally equivalent.

Can one ASN originate many IP prefixes?

Yes. An ASN can originate routes for multiple prefixes. The prefix registrations and authorization arrangements still need to be considered separately.

Does an ASN registration prove that the network is active?

No. Registration is administrative evidence. Current routing activity requires appropriately scoped routing observations, and absence from one observation is not proof of universal inactivity.

Can a prefix’s origin ASN change without its registration changing?

Yes. Routing and registration are separate layers. An observed origin change does not automatically imply that the registered resource holder changed.

Does a public ASN prove ownership of the advertised addresses?

No. The ASN identifies an autonomous system. Prefix registration, permitted use and routing authorization are separate matters.

Are all non-private ASN values available for public assignment?

No. Other values are reserved or designated for special purposes. The IANA registry distinguishes these categories.