How to Choose a Sponsoring LIR for Your ASN: 8 Checks Before You Apply

Before comparing annual prices, confirm that you can explain an independent routing plan, two real external BGP relationships, and the evidence behind them. A lower-priced sponsor cannot make an unready ASN application stronger.

Definition Box: A Sponsoring LIR can administer an ASN application and the related resource relationship, but it cannot substitute for an independent routing policy, genuine BGP relationships, or the customer's own network operation.

Before you compare providers, check the application itself. The ASN application requirements guide covers the network facts, documents, and common gaps to resolve before you begin.

The best Sponsoring LIR is not simply the cheapest one. It is the one that makes its review sequence, operational boundaries, and exit path clear.

Price belongs at the end of this decision, not the beginning. This guide runs eight checks: six on your application, then two on the provider. Complete the first six before using the last two to compare a sponsor.

White-Face Xiaolu checks two independent routing paths and a readiness checklist before looking at price.

Check the network plan and evidence first; price is meaningful only after the application is ready.

Part I — Check your application before comparing providers

Run the six checks below before you evaluate any sponsor. Each ends in one of three states: Ready, Needs clarification, or Stop here.

The order matters. RIPE NCC reviews the stated policy, relationships, and supporting evidence, so the application should read as one coherent case: the policy, the neighbours, and the proof must describe the same operating network.

Check	Ready	Needs clarification	Stop here
1. Independent routing policy	Can explain a concrete routing decision	Reason is vague	No independent need
2. Two BGP relationships	Both are real and explainable	One detail missing	Only one relationship
3. Neighbour records	Location, ASN, role, contact, and connection for each	A field is missing	Cannot identify a neighbour
4. RPSL	Import/export matches the actual design	Needs technical review	Copied or fictional
5. Applicant evidence	Documents and contacts match	Minor evidence gap	Identity or authority is unclear
6. In-region deployment, if applicable	Evidence identifies the deployment	More proof needed	No active network element

Check 1: Does the network need an independent external routing policy?

“We want our own ASN” is not a sufficient reason. RIPE-679, the ASN assignment policy, requires a new external routing policy. In practice, an ASN is justified when it enables a routing decision that your current arrangements cannot express.

A real operational reason is usually one of these:

independent policy toward different external networks, so transit and peering relationships follow different rules;
failover across multiple external BGP relationships, so traffic moves between paths when one fails;
announcing prefixes under your own routing identity rather than through a provider-managed connection;
a real deployment that needs policy control which a single provider-managed connection cannot provide.

The test is whether you can describe an actual routing decision, not a wish. For example: “When the link to neighbour A fails, traffic shifts to neighbour B, and only the prefixes in list X are announced to B.” If you cannot describe one decision the ASN will enable, the application does not yet have a complete story.

A useful self-test is to write the reason in two sentences and remove the jargon. If it still describes a real operational need — failover, separate policy, or your own announcements — the reason is concrete. If nothing remains but ownership or status, it is not yet defined.

Check 2: Are there two real external BGP relationships?

The application needs two external BGP relationships, not necessarily two upstreams. They can be transit or peering that is genuinely relevant to the same network plan, but they must be real and explainable — not invented for a form. RIPE's current application guidance asks for two peer ASNs, working contacts, and the routing policy; the exact supporting evidence can vary by case.

Warning: One ordinary VPS, one provider connection, or two entries describing the same relationship does not create a multihomed network.

The relationships should be genuine and backed by material that matches the case you submit. RIPE NCC may ask for clarification, so describe the relationship as it actually exists. Do not describe an unarranged future relationship as live.

The goal is not to fill two rows in a form. It is to describe one network with two genuine external paths. A relationship that exists only in the application is likely to trigger follow-up questions or be insufficient evidence of a multihomed network.

White-Face Xiaolu tests two physically separate cables leading to two distinct external gateways.

Two independent external paths are more than two names on an application form.

Check 3: Can you identify each BGP neighbour precisely?

For each neighbour, record five details that can survive a question from an engineer reviewing the application:

connection city, data centre, cloud region, or facility;
peer ASN;
transit or relevant-peering role;
working NOC or technical email;
one sentence explaining how it connects to your network.

The table below shows the required format using documentation ASNs only.

Field	Neighbour 1	Neighbour 2
Facility	FRA1 data centre, Frankfurt, DE	FRA2 data centre, Frankfurt, DE
Peer ASN	AS64497 (documentation)	AS64498 (documentation)
Role	Transit	Relevant peering
NOC or technical email	noc@transit-doc.example	peering@peer-doc.example
How it connects to your network	10 Gbps cross-connect at the cage, terminated on the edge router	eBGP session over a private cross-connect to the peer router

Documentation ASNs show the format only. Your entries must name real networks you can verify. If you cannot produce all five details for a neighbour, that neighbour is not ready.

Check 4: Can your RPSL policy describe reality?

Routing Policy Specification Language (RPSL) is how you state what the network will do. Two terms cover most of what an ASN application needs:

import — what the network accepts from a neighbour;
export — what it announces to that neighbour.

The minimal two-neighbour example below uses documentation ASNs only. It shows relationship structure, nothing more.

aut-num:        AS64496
as-name:        EXAMPLE-NET

import:         from AS64497 accept ANY
export:         to AS64497 announce AS64496

import:         from AS64498 accept ANY
export:         to AS64498 announce AS64496

The example demonstrates a relationship. It is not a copy-paste routing policy or router configuration.

If the import and export lines conflict with the neighbours you listed or with the stated use, an engineer cannot tell what you intend. The policy must match the actual design. Replace the documentation ASNs, filters, and announcement objects with the real plan before submitting. For the surrounding account records — organisation, role, person, and maintainer objects — follow the RIPE NCC setup guide rather than setting them up from memory.

The RPSL policy above is not itself a route or route6 object. After allocation, you may need separate IRR route or route6 records for the prefixes you announce; responsibility depends on the resource holder, maintainers, and upstream policy. What Is an IRR Route Object? explains the difference. IRR maintenance and BGP operation sit outside SKNK's standard sponsorship service boundary — see the Terms of Service.

White-Face Xiaolu aligns a simple routing plan with the two physical cables it represents.

A routing policy is useful only when its stated paths match the network you will actually operate.

Check 5: Can the applicant prove who it is and who can act for it?

The practical readiness points are short and concrete:

registered-company or registered-sole-trader evidence;
matching legal name, registration number, and registered address;
an authorised signatory;
administrative and technical contacts;
a monitored email address for follow-up questions.

Keep the division of labour clear. RIPE NCC assesses policy and resource eligibility. Your sponsor also needs enough evidence to verify the applicant and submit the case correctly. A company name, address, or signatory that does not match across documents — or a contact email nobody answers — is the kind of detail that produces follow-up questions. Keep the legal name, registered address, and contact details consistent across every document you provide.

Check 6: If the applicant is outside the RIPE NCC service region, can it show an in-region active network element?

This check applies only when the applicant entity is outside the RIPE NCC service region. When it does apply, the ASN must be used on active network infrastructure inside the region. Be ready to explain:

where the ASN will be used in the service region;
what active infrastructure exists there;
how it connects to transit or peers;
what evidence supports that claim.

Useful evidence can include an IP Transit or BGP service agreement, a colocation agreement, or a BGP-capable server or service that explicitly permits use of the customer ASN. The material should identify the provider, ASN, location, service type, applicant relationship, and service period. Current material — such as a valid contract or renewal commitment plus a recent invoice — is normally more persuasive than one historic bill.

Do not assume the two BGP relationships must themselves be geographically located in the RIPE region. The policy question is whether the ASN will be used on active infrastructure there, not where every upstream is located. Do not treat evidence as a guarantee: eligibility and final review are case-specific.

If this check applies, treat deployment material as part of the application from the start rather than an afterthought. It is what turns an outside-region case into one an engineer can follow.

Stop condition: sanctions and authority

If the applicant, beneficiary, owner, or controller may be subject to applicable sanctions — or if signing authority is unclear — do not treat the self-check as complete. Resolve it through the secure application process.

Part II — Use the readiness answers to compare Sponsoring LIRs

Once the six readiness checks are answered, price becomes meaningful. The remaining questions are not simply “How much?” but “How does this provider handle the facts I cannot safely guess?” The questions it asks and the boundaries it publishes reveal what it actually verifies and supports.

Disclosure: SKNK is a Sponsoring LIR. The SKNK pages linked below are included so you can check SKNK against the same standards used for any other provider.

Check 7: Does the provider clearly explain when it reviews the case and what evidence it needs?

A credible provider should ask about the things you just checked:

the independent routing-policy reason;
the two BGP relationships;
the RPSL policy;
the applicant's identity and evidence;
deployment evidence where applicable;
any gaps that need resolving before submission.

More important than the questions is the process. The provider should clearly explain when it reviews the case, what evidence it needs, and how it handles gaps before submitting to RIPE NCC. On a typical sponsored application, the sequence is: order, provide materials, sign the agreement, pay, then the sponsor reviews and submits; RIPE NCC then conducts its own independent review. How It Works describes that sequence for SKNK.

Ask how gaps are handled. Will the provider tell you before you order which documents an outside-region case will require? Will it explain what happens if RIPE NCC asks for clarification? A provider that promises approval without examining the network plan is not reducing risk; it is moving unanswered questions later in the process.

Check 8: Does the provider clearly state responsibility, evidence, and lifecycle?

The boundaries should be written down before you pay. The comparison below lists the questions and what a clear answer should tell you.

Question	A clear answer should tell you
Who handles application administration?	What the LIR does during submission and review
Who operates BGP?	Sponsorship alone does not include BGP configuration; any managed-routing service must be separately defined in writing
Who manages PA-prefix ROAs?	The exact authority and change path
Who handles IRR records?	Whether this is included, excluded, or separately agreed
What happens at renewal or exit?	ASN sponsorship process, PA-prefix withdrawal, and renumbering implications
Where can claims be checked?	Public policies, source pages, legal identity, and resource information

The expensive surprises are rarely the advertised fee itself. They are discovering after payment that BGP operation was never included, that the ROA for a PA prefix is controlled by an authority you cannot reach, or that the prefix cannot move when you change sponsor. Written boundaries are not about finding the provider with the most favourable answer; they are about finding one whose answer is verifiable.

Before you decide, review:

Resource ownership & lifecycle — what happens at renewal, cancellation, and sponsor change;
Pricing — what the fee includes and where the service boundaries are;
How It Works — the order, review, and submission process.

White-Face Xiaolu checks a key, resource boxes, and a cable leading through an open exit gate.

A clear service boundary names who controls each resource and what must happen when the relationship ends.

Part III — One-page decision worksheet

Use this worksheet in any conversation with a sponsor. A “Needs clarification” row is not a failure; it is the exact question to ask in writing before you commit.

Question	Ready	Needs clarification	Stop before ordering
Independent routing policy	Can explain it concretely	Too vague	No independent need
Two BGP relationships	Both are real and documented	One detail missing	Only one relationship
RPSL	Matches actual design	Needs technical review	Copied or fictional
Applicant evidence	Documents and contacts match	Minor evidence gap	Identity or authority is unclear
In-region deployment, if applicable	Evidence identifies deployment	More proof needed	No active network element
Provider process	Explains when and how it reviews the case	Scope is unclear	Promises guaranteed approval
Responsibility	BGP, ROA, and IRR boundaries are written	Some terms are unclear	Claims conflict
Lifecycle	Renewal and exit are documented	Need contractual clarification	No written exit path

If any row lands in “Stop before ordering”, fix that item before you pay. If any row is “Needs clarification”, put that question to the provider in writing.

FAQ

Do I need two upstream providers?

No. The application needs two real external BGP relationships. They can be transit or relevant peering, provided they belong to the same network plan and are real and explainable. Splitting one provider connection into two entries does not create multihoming.

Can one BGP VPS be enough?

An ordinary VPS with one connection does not create multihoming, and it does not substitute for an independent routing policy. A BGP-capable VPS can still be useful evidence when the service explicitly provides a BGP session, permits announcements with your ASN, and its documents identify the ASN, location, and service period. You still need a genuine second relationship.

Does a “Ready” self-check result mean RIPE NCC will approve the application?

No. The self-check finds common gaps; final eligibility, due diligence, and RIPE NCC review are case-specific. A “Ready” result means the application is in a defensible state, not that approval is guaranteed.

Does a Sponsoring LIR configure my BGP?

Sponsorship alone does not include BGP configuration. SKNK's standard sponsorship does not include BGP or routing operations; any managed-routing service should be separately scoped in writing. You choose the upstreams and peers, and you operate BGP yourself.

Can I take the IPv6 /48 with me if I change sponsor?

A PA /48 does not move with the ASN. The prefix is assigned from the sponsor's LIR allocation, so changing sponsor normally means withdrawal and renumbering. If portability matters, ask about provider-independent (PI) space separately before you commit.

In one sentence

Choose a Sponsoring LIR only after you can explain your network, prove the application facts, and verify that the provider's responsibilities and exit path are written down.

Check my application readiness → ASN application requirements

After completing the checklist: Start a secure ASN + IPv6 application → Start the order flow

Sources

Review these sources when policy or service terms change.