How to Get an ASN

Choose the registry and membership route

The registry is determined by where you operate: ARIN, RIPE NCC, APNIC, LACNIC, or AFRINIC.

Then decide how you hold the resource.

Direct membership. You become a member or account holder of the registry, hold the ASN yourself, and pay the registry directly. More administration and more control, and the resource is unambiguously yours.

Sponsoring LIR. In the RIPE region, an existing LIR sponsors your resource. Lower setup cost and less paperwork, at the price of a dependency: if the relationship ends, the sponsorship has to move. Fine for smaller networks, worth thinking about if the ASN is central to your business.

APNIC has a similar arrangement through NIRs in some economies. ARIN issues directly to organisations without a sponsorship model.

Fees vary by registry and change; check the current schedule rather than relying on figures you were quoted before.

Gather the supporting information

Every registry wants roughly the same things. Collecting them before starting avoids a round trip that costs days.

• Legal entity details — registration documents, address, and an authorised signatory
• The ASNs you will connect to — usually two, with a contact at each who can confirm
• A description of your routing policy — why you cannot use an upstream’s ASN, in a couple of paragraphs
• The address space you will announce — held already or being acquired in parallel
• Technical and administrative contacts — people, with monitored mailboxes

The peering confirmations are the item that takes longest, because they depend on someone else replying. Ask your upstreams for them at the same time you start the membership process, not afterwards.

Submit the request

Through the registry’s portal: ARIN Online, the RIPE NCC portal via your LIR or sponsor, MyAPNIC, and equivalents elsewhere.

Answer follow-up questions quickly. Registry staff generally respond within a few business days, and each unanswered clarification adds a full cycle to the timeline. Being specific about the second upstream — who, when, what circuit — resolves most queries before they are asked.

Expect a 4-byte ASN. The 16-bit space is exhausted and has been for years. Every current BGP implementation handles them; only genuinely old equipment and some IRR tooling display them awkwardly.

Create the registry objects

Once issued, the ASN exists but describes nothing. Two object types make it usable.

aut-num describes the AS: its name, contacts, and optionally its routing policy in RPSL. Some registries create a skeleton for you; fill in the contacts regardless, since this is where people look when they need to reach you about routing.

route objects authorise a specific prefix to be originated by a specific ASN. Without one, upstreams that build filters from IRR data will not accept your announcement — and most do. Create a route object for every prefix you will announce, in the IRR database your upstreams use.

Getting these right before the first announcement saves a debugging session where the prefix is visible from some networks and not others.

Set up RPKI, IRR and PeeringDB

Three things to do before announcing anything.

Sign ROAs. A Route Origin Authorisation cryptographically states which ASN may originate which prefix. All five registries offer hosted RPKI through their portals, which makes this a form to fill in rather than a system to run. A growing share of the internet drops RPKI-invalid announcements, so an unsigned prefix is increasingly a partially reachable prefix.

Check the max-length field. Setting it longer than you actually announce leaves room for a more-specific hijack; setting it shorter than your announcement invalidates your own route.

Register IRR objects as above, in the database your upstreams query. RPKI and IRR are complementary — most networks check both, and being valid in only one still gets you filtered somewhere.

Create a PeeringDB record. It is where other networks look to find your peering locations, contacts, and traffic profile. Peering requests are routinely declined for networks that are not listed, on the reasonable basis that an unlisted network is harder to work with.