How to Register an ASN: RIR Application Walkthrough

An ASN request is a policy review, not a shopping cart. The registry reads your request and asks one question: does this network need a globally unique routing identity that no upstream provider can give it. Everything else in the application exists to answer that question convincingly, and the operators who wait longest are usually the ones who submitted before they had an answer ready.

This walkthrough follows the real order of operations. You build a dossier first, apply in your region, verify the assignment from the outside once it lands, and only then publish the routing objects that peers actually filter on. The last step is recording the number where your team can find it, because the ASN is a resource you will reference for years.

At a Glance: ASN Registration by Region

Fees and thresholds change with every charging scheme, so treat the numbers as 2026 values and confirm them on your registry’s fee page before you budget. The shape of the process is far more stable than the prices.

What the Registry Is Actually Deciding

Every region phrases the test differently, but they all test the same thing: a unique routing policy. A network has one when it exchanges routes with other networks in a way that its upstream provider cannot do on its behalf. Multihoming to two providers counts, peering with another AS without transit in between counts, and operating a network that must be addressed independently from any single carrier counts. A network that is single homed on one provider with no peering intent normally does not qualify.

The second thing the registry checks is that the number is not already in use. Do this before you spend time on the form, because a taken number is not negotiable.

# Does this ASN already belong to someone?
curl --fail --silent --show-error "https://rdap.org/autnum/393216" \
  | jq -r '[.handle, (.name // "no name"), (.port43 // "no port43")] | @tsv'

If the handle resolves to your own organization from a previous assignment, stop and reconcile the old record instead of requesting a second number. If it resolves to a stranger, pick the next candidate.

Build the Dossier Before You Open the Form

The application form is short. The work is in the answers, and assembling them first turns a week of back and forth into a single submission. Four groups of facts carry the whole request.

Keep the routing intent to a paragraph a reviewer can act on. Name the networks you will exchange routes with, say whether those are transit or peering, and state the prefixes you plan to announce. A request that says “we need an ASN to grow” fails the test. A request that says “we will announce 203.0.113.0/24 from AS393216 to two transit providers and the metro exchange route servers” passes it.

The technical plan is where a smaller network often has less than it thinks. If you do not yet own portable address space, say so and describe the space you will request alongside the ASN, because the two are usually evaluated together.

Applying in Your Region

The order of operations is nearly identical everywhere, but who you contract with and what happens between approval and issuance differs.

1. Create the account and organization record. This is the step that silently costs a week when a legal name, address, or point of contact does not match the registration documents. In ARIN this is an ARIN Online account linked to an Organization Identifier; in APNIC it is a member or non member account; in RIPE it is a member or a sponsoring LIR.
2. Submit the request while logged in. ARIN guides you through IP Addresses or ASNs then Request. RIPE, APNIC, LACNIC, and AFRINIC all expose a resource request form once the account exists.
3. Answer correspondence fast. A reviewer will usually ask one or two clarifying questions. A request that bounces back for a missing peering confirmation can lose a week per round.
4. Accept the agreement and pay. This is a separate administrative gate. ARIN issues an invoice and a Registration Services Agreement after approval; RIPE sends a Standard Service Agreement that must be signed by hand; LACNIC assigns only after the fee is paid and the agreement signed.
5. Receive the assignment and confirm it in the registry. The number exists the moment it is issued, but it is not usable until the routing objects around it exist too.

A few regional details are worth knowing before you pick a path. In Brazil and Mexico, LACNIC asks you to go through the national registry, Registro.br or IAR.MX, rather than applying directly. RIPE NCC members have been restricted from acquiring additional LIR accounts since late September 2026, so a new organization should confirm the current position or use a sponsoring LIR. AFRINIC issues ASNs under three policies, the general one, an anycast policy, and a reservation policy for exchange route servers, and the documentation differs between them.

Verify the Assignment From the Outside

Once the registry says yes, prove it from a vantage point that does not depend on the registry portal. The structured view is RDAP, which is what most modern tooling reads when it needs to resolve a public number.

# Confirm the holder, the range, and the issuing registry
curl --fail --silent --show-error "https://rdap.org/autnum/393216" \
  | jq -r '[.handle, (.name // "no name"), (.startAutnum|tostring), (.endAutnum|tostring), (.port43 // "no port43")] | @tsv'

A healthy new assignment looks like this, with your organization in the name column and the expected registry in the last column.

AS393216	ACME NETWORKS	393216	393216	whois.ripe.net

If the name column is blank or shows a registrar rather than your organization, the record is not complete and any peer that filters on registry data will treat your announcements as unverified. Fix the holder record before you configure BGP, not after.

Classify the number the same way a tool would. The private ranges are not routable on the public internet, and a network that accidentally announces from one will be filtered everywhere.

# Private 16 bit, private 32 bit, reserved, or public
asn=393216
if   [ "$asn" -ge 64512 ] && [ "$asn" -le 65534 ]; then echo "private-16"
elif [ "$asn" -ge 4200000000 ] && [ "$asn" -le 4294967294 ]; then echo "private-32"
elif [ "$asn" -eq 0 ] || [ "$asn" -eq 23456 ] || [ "$asn" -eq 4294967295 ] \
  || { [ "$asn" -ge 64496 ] && [ "$asn" -le 64511 ]; } \
  || { [ "$asn" -ge 65536 ] && [ "$asn" -le 131071 ]; }; then echo "reserved"
else echo "public"
fi

Publish the Routing Objects Peers Filter On

The ASN alone changes nothing about what the internet sees. Peers accept your routes based on two published statements, the route objects in the Internet Routing Registry and the Route Origin Authorizations in RPKI. The sequence matters, because a ROA that arrives before the route exists is fine, but a route that arrives before either does is treated as unverified.

Create the IRR objects in the same registry your peers query, and check that they are visible from a public mirror.

# Confirm the route objects your ASN is authorized to originate
whois -h whois.radb.net -- "-i origin AS393216" | grep -E '^(route|route6):'

route:          203.0.113.0/24
route6:         2001:db8:100::/48

Then create the ROA and check the validation state from an RPKI validator. A local Routinator exposes the validity of a single announcement on one endpoint.

curl --fail --silent --show-error \
  "http://localhost:8323/api/v1/validity/AS393216/203.0.113.0/24" \
  | jq -r '.validated_routes[0].validity.state'

valid

valid is the only state that confirms your own announcement matches your published intent. not-found usually means the ROA is missing or still propagating, and invalid means the ROA exists but disagrees with what you are announcing, which is the state that gets a route filtered at networks enforcing origin validation.

The same discipline applies to reverse DNS and abuse contacts. Delegation for your prefix belongs to you now, and external parties will look it up.

dig +short -x 203.0.113.1

If that returns nothing, or returns a name owned by your old provider, create the PTR record yourself before customers depend on the address.

Why Requests Stall

Most delays come from a short list of causes, and each one has a fix you can apply before submitting.

The pattern in that list is that the registry is rarely the slow part. The slow parts are internal: a legal entity that has never been created in the registry, a peering agreement that was never signed, and a payment routed through a process that takes two weeks.

Record the ASN Where the Next Change Will Find It

An ASN is a long lived identifier that a future engineer will need during a provider migration, an audit, or an incident. Store it with the same care as an IP block, and store the relationship to the sites that announce it and the providers that carry it, because those relationships are what a provider change actually touches. In an inventory that models the number together with its registry, its sites, and its providers, an IP address management record gives the next person the full context instead of a bare number.

If you already keep your inventory in Obelinf, the record is a couple of calls. Create the registry entry first, then the ASN that references it.

export OBELINF_API_KEY="your_read_write_key"
export OBELINF_ORG="acme-netops"

RIR_ID=$(curl --fail --silent --show-error -X POST \
  -H "Authorization: Bearer ${OBELINF_API_KEY}" \
  -H "Content-Type: application/json" \
  "https://api.obelinf.com/${OBELINF_ORG}/rirs" \
  -d '{"name":"RIPE NCC","slug":"ripe-ncc","description":"Sponsoring LIR: Example Hosting"}' \
  | jq -r '.rir.id')

curl --fail --silent --show-error -X POST \
  -H "Authorization: Bearer ${OBELINF_API_KEY}" \
  -H "Content-Type: application/json" \
  "https://api.obelinf.com/${OBELINF_ORG}/asns" \
  -d "{\"asn\":393216,\"name\":\"ACME NETWORKS\",\"status\":\"active\",\"rir_id\":\"${RIR_ID}\"}" \
  | jq -r '[.asn.asdot, .asn.class, (.asn.rir_id // "none")] | @tsv'

The returned class tells you immediately whether you stored a public number or a private one, and asdot gives you the notation to type into a router, which differs from the integer only for a 32 bit assignment. Attach the sites and providers while the assignment is fresh, and the record is complete before the first BGP session is even configured.

The first concrete step is small. Log in to your registry’s portal today and confirm that your organization can actually request resources, because the account setup is the one part that is entirely in your own hands and the one that most often adds a week to a process everyone expects to take three days.