How to Get Your Own ASN: RIPE NCC, LIR, and Requirements

To get your own ASN in the RIPE region, you request an autonomous system number from the RIPE NCC either by becoming a LIR (Local Internet Registry) yourself or, far more commonly, through a sponsoring LIR that submits the request on your behalf. You need a legal identity, a documented routing plan (normally at least two upstream networks), and RIPE database objects that describe your network.

This guide walks through both routes, the paperwork, the multihoming question, and what to do the day the AS number arrives. The same logic applies at other registries (ARIN, APNIC, LACNIC, AFRINIC), but the details below are specific to the RIPE NCC. Always check the current policy text before you apply, because registry rules change.

What an ASN is and why you might want one

An autonomous system number identifies a network with its own routing policy on the public internet. You need one if you want to:

• Announce your own IP prefixes through BGP.
• Connect to two or more upstream providers and control traffic between them.
• Keep your address space when you change providers.
• Peer at an internet exchange or with other networks.

You do not need an ASN just to run a server. If you only want to use IP addresses from a provider, a normal allocation from that provider is enough. An ASN makes sense when you have, or soon will have, your own prefix and a reason to route it independently.

Which registry do you apply to?

ASNs come from the Regional Internet Registry that serves your region:

For the RIPE NCC, the organization requesting resources generally needs to be located in the RIPE NCC service region. If your company is in the US, ARIN is normally the right registry. If you operate in several regions, choose the registry that matches the legal entity that will hold the resource.

Route 1: Become a LIR

A LIR is a member of the RIPE NCC. Becoming one gives you direct access to the RIPE NCC portal, the ability to request resources for yourself and for your customers, and voting rights in the association.

This is a good fit when you are a hosting company, ISP, or carrier that will manage address space for many customers. It also comes with ongoing obligations: membership fees, keeping contact data current, and following RIPE policies. For a single ASN, it is usually more than you need.

Route 2: Use a sponsoring LIR

A sponsoring LIR is an existing LIR that holds resources for an end user. The process looks like this:

1. Find a sponsoring LIR. Many hosting providers and transit networks offer this service. Compare their contract terms, annual fees, and how quickly they respond to RIPE database changes.
2. Sign a contract with the sponsoring LIR. The RIPE NCC requires an agreement between the sponsoring LIR and the end user. The end user is the holder of the resource, but the sponsor is the one the RIPE NCC deals with.
3. Provide your documents and technical details (see below).
4. The sponsoring LIR submits the request to the RIPE NCC through the LIR portal.
5. The RIPE NCC evaluates the request. They may ask follow-up questions about your network or documents.
6. The ASN is assigned and your aut-num object is created in the RIPE database, maintained by a maintainer you control.

Ask the sponsor up front about the exit path. If you later want to move the resource to another sponsor or become a LIR yourself, the process should be clear and documented in the contract.

Documents and information you will need

Exact requirements vary by sponsor, but expect to provide:

• Company registration documents (or ID for an individual, where the sponsor accepts that).
• Identification of an authorized representative.
• Contact details: postal address, email, phone, and an abuse mailbox.
• A technical contact who can maintain the RIPE database objects.
• Your routing plan: which upstreams or exchanges you will connect to, and which prefixes you plan to announce.
• Evidence of upstream intent, such as an order form or confirmation from providers, if the sponsor or RIPE NCC asks for it.
• Signed agreements with the sponsoring LIR.

Prepare these before you contact a sponsor. Incomplete or inconsistent company data is the most common reason a request stalls.

The multihoming question

Historically, RIPE NCC policy tied ASN assignment to multihoming or a unique routing policy. In plain terms: if your network has only one upstream and uses that upstream's routing, you generally do not need an ASN, because your upstream can announce your prefix under its own AS number.

In practice, plan on this:

• Have at least two upstream providers, or an upstream plus an internet exchange, in place or clearly planned.
• Be ready to describe your routing policy: what you announce to whom, and how you want inbound traffic to flow.
• Read the current RIPE ASN assignment policy document before applying, since the wording and the way the RIPE NCC evaluates it can change.

If you are not yet multihomed, being honest about your timeline works better than inventing a setup. A sponsor can often tell you whether your plan is likely to be accepted.

What about IP addresses?

An ASN is only half of the picture. For something to announce, you need a prefix:

• IPv6: You can obtain a provider-independent IPv6 assignment through a sponsoring LIR. A /48 is the smallest prefix that is widely accepted in the global routing table.
• IPv4: The IPv4 pool is exhausted, so new space generally comes through transfers or leasing from another holder. Be careful with leased space: check its history and make sure the lessor can create the RPKI and IRR records for you. The smallest widely routed IPv4 prefix is a /24.

After the ASN is assigned: a checklist

An ASN does nothing until its records are correct. Do these before you start a BGP session.

1. Check your aut-num object

whois -h whois.ripe.net AS64496

A minimal example (using a documentation ASN):

aut-num:   AS64496
as-name:   EXAMPLE-NET
org:       ORG-EXAMPLE1-RIPE
import:    from AS64511 accept ANY
export:    to AS64511 announce AS-EXAMPLE
admin-c:   EX1-RIPE
tech-c:    EX1-RIPE
mnt-by:    EXAMPLE-MNT
source:    RIPE

2. Create route objects

For each prefix you will announce, create a route or route6 object with your ASN as the origin:

route:     192.0.2.0/24
origin:    AS64496
mnt-by:    EXAMPLE-MNT
source:    RIPE

route6:    2001:db8::/32
origin:    AS64496
mnt-by:    EXAMPLE-MNT
source:    RIPE

3. Create an AS-SET

An AS-SET lets upstreams build prefix filters for you and your customers:

as-set:    AS64496:AS-CUSTOMERS
members:   AS64496
mnt-by:    EXAMPLE-MNT
source:    RIPE

4. Publish RPKI ROAs

A Route Origin Authorization says which ASN may originate which prefix. In the RIPE NCC portal, create a ROA for each prefix with the correct maximum length. Keep the max length equal to the length you actually announce, unless you have a reason to do otherwise. A ROA that is too permissive makes hijacks of more-specific prefixes easier.

5. Create a PeeringDB entry

Many networks check PeeringDB before they set up a session. Fill in your ASN, contacts, and policy.

6. Prepare your router or server

Use BIRD, FRRouting, or a hardware router. Filter inbound and outbound routes strictly, enable max-prefix limits, and reject RFC 1918 and bogon space. Generate filters from your upstreams' AS-SETs, for example with bgpq4:

bgpq4 -4 -l AS64511-IN AS64511

Common mistakes and how to fix them

• Applying without any upstream plan. Line up at least a routing plan and preferably an upstream before you apply.
• Mismatched company data. Names and addresses in your contract, ID documents, and RIPE objects should be the same.
• Missing or wrong ROAs. If your ROA does not match your origin ASN or max length, networks that apply route origin validation will drop your announcement. Fix it in the RIPE NCC portal and wait for propagation.
• No route objects. Upstreams that filter on IRR data will reject your prefix until the route object exists.
• Weak maintainer protection. Use a strong authentication method for your mnt-by object. A hijacked maintainer means a hijacked network.
• Announcing too much. Leaking your upstream's routes to another upstream can cause an outage. Use explicit outbound filters.

Using your ASN on a BGP VDS

You do not need your own router hardware to start. On the BGP-enabled VDS service at Nixcon Group LLC, you can announce your own ASN and prefix from a BGP session on the VDS. Nixcon operates AS40368 with POPs in Frankfurt and Fremont, California, and a main data center in Izmir, Turkey. ASN and prefix ownership are checked automatically through RPKI ROAs and the official RIR and IRR records, and your ASN is added to the AS-NIXCON AS-SET. You can choose an announcement without DDoS protection or with it, and you can choose a full routing table or only Nixcon routes.

If you are already multihomed and want mitigation upstream of your own servers, see the DDoS protection and firewall page. You can also check how your prefix looks from different vantage points with the public looking glass.