How to Prepare Your ASN Justification: Complete Documentation Guide

An ASN justification tells the registry why your network needs its own routing policy. At the RIPE NCC it comes down to two things: proof that the network is multihomed and the routing policy you will run, written in RPSL (ripe-679). ARIN issues a first ASN on request; APNIC and LACNIC ask for an interconnection need you can name; AFRINIC accepts that or a unique routing policy.

The templates below follow the RIPE NCC request and note where the other registries differ. For the whole process, from documents to assignment, see how to get an ASN.

What Do RIRs Require in an ASN Justification?

What RIRs Look For

The RIPE NCC's ASN policy (ripe-679) follows RFC 1930: a new AS number is for a network that needs its own external routing policy. In practice each registry turns that into one or two tests: multihoming or an interconnection need, and a routing policy you can write down. Nothing in any RIR policy asks for staff certifications, business cases or SLA history.

Red flags at the RIPE NCC:

• A single-homed network
• Peers that do not answer the RIPE NCC
• No routing policy
• No prefix to announce

RIR-Specific Focus Areas

Registry	What it checks	Source
RIPE NCC	The network must be multihomed and the routing policy stated, in RPSL. The LIR Portal request form asks for at least two peering partners, each with ASN and contact e-mail, plus the prefix you will announce. End Users file through a sponsoring LIR or under a direct RIPE NCC contract	ripe-679 section 2.0
ARIN	Any organization may be issued a single ASN upon request; additional ASNs need a unique routing policy or other technical justification. The requester must be a business entity legally formed in the ARIN region	NRPM section 5
APNIC	The network is currently multihomed, or has a need to interconnect with another AS, now or shortly after the assignment	APNIC-127 section 10.1
LACNIC	A need to interconnect with other independent ASes now or within six months; routing policy, peer ASNs and prefixes to be announced; LACNIC may revoke an ASN still unused after that	Policy Manual section 3
AFRINIC	Resource member; interconnects with more than one AS, or shows a unique routing policy or technical need, now or within six months. Multihoming has not been required since 29 May 2020	CPM section 7.2

Multihoming is still required in September 2026. Proposal 2026-01 would drop the test for a holder's first ASN when it holds a prefix assigned or allocated directly by the RIPE NCC. It was still in drafting after its Discussion Phase closed on 5 August 2026 (2026-01); the earlier proposal 2025-01 was withdrawn on 6 July 2026. Under 2026-01, additional ASNs would keep the multihoming test.

For detailed requirements by RIR, see our ASN Registration Requirements by RIR guide.

What Goes Into an ASN Justification?

A RIPE NCC request needs items 4, 6 and 7 below. The rest answers follow-up questions and is where other registries put more weight.

1. Executive Summary

A brief (2-3 sentence) overview of your request:

Template:

[Organization name] requests an Autonomous System Number to implement
[multi-homing/unique routing policy] for [business purpose]. We operate
[network type] serving [customer base/purpose] and require independent
routing capability through BGP to [specific technical objective].

Example:

TechHost Europe Ltd requests an Autonomous System Number to implement
multi-homed connectivity for our hosting infrastructure. We operate
a cloud hosting platform serving 500+ business customers across Europe
and require independent routing capability through BGP to meet our 99.95%
uptime SLA and stay independent of any single provider.

2. Organization Background

At the RIPE NCC, legitimacy is checked through documents, not prose. Natural persons prove identity, legal persons show registration papers, and every signing party is screened against EU and Dutch sanctions lists (ripe-863). The background paragraph below is for a registry or sponsoring LIR that asks a follow-up question.

Include:

• Legal entity name and registration details
• Business activities and services
• Geographic scope of operations
• Number of customers or users served
• Years in operation
• Technical staff capabilities

Example:

TechHost Europe Ltd is a registered company (UK Company No. 12345678)
established in 2018, providing cloud hosting and managed services to
enterprise customers across the European market. We serve 520 active
business customers with 2,400+ virtual servers under management.
Our technical team includes five certified network engineers (CCNP, JNCIA)
with extensive BGP and routing experience.

3. Network Infrastructure Description

Detail your current and planned network architecture:

Include:

• Data center locations
• Network topology overview
• Current IP address holdings
• Server/equipment infrastructure
• Bandwidth capacity
• Geographic presence

Example:

Our network infrastructure includes:
- Primary data center: Amsterdam (AMS3 colocation facility)
- Secondary data center: Frankfurt (FR5 colocation facility)
- Current IP resources: 203.0.113.0/24 (IPv4 PI, received by transfer), 2001:db8::/48 (IPv6 PI)
- Hosting capacity: 150 physical servers, 2,400+ VMs
- Network capacity: 20 Gbps total connectivity
- BGP-capable routing: two redundant edge routers with full-table capacity

4. Multi-homing Justification (If Applicable)

If applying on multihoming, give these details:

Required information:

• Names of upstream providers
• ASNs of upstream providers
• Confirmation that each upstream ASN is live and routed (check with the ASN lookup tool)
• Contact information for provider NOCs
• Bandwidth and service details
• Reason for choosing multi-homing
• Expected implementation timeline

Template:

Multi-homing Configuration:

Primary Transit Provider:
- Provider name: [Provider A]
- ASN: AS[number]
- Contact: [NOC email]
- Service: [bandwidth] committed transit
- Connection type: [10GE cross-connect/etc.]

Secondary Transit Provider:
- Provider name: [Provider B]
- ASN: AS[number]
- Contact: [NOC email]
- Service: [bandwidth] committed transit
- Connection type: [10GE cross-connect/etc.]

Multi-homing rationale:
[Explain why multi-homing is necessary for your operations]

Example:

Multi-homing Configuration:

Primary Transit Provider:
- Provider name: Transit A
- ASN: AS64496
- Contact: noc@transit-a.example
- Service: 10 Gbps committed transit
- Connection type: 10GE cross-connect at AMS3

Secondary Transit Provider:
- Provider name: Transit B
- ASN: AS64497
- Contact: noc@transit-b.example
- Service: 10 Gbps committed transit
- Connection type: 10GE cross-connect at AMS3

Multi-homing rationale:
Our hosting platform SLA guarantees 99.95% uptime to enterprise customers
with financial penalties for violations. Multi-homing through independent
providers eliminates single points of failure in transit connectivity,
ensures automatic failover during provider outages, and enables load
balancing across providers. Historical data shows each provider
experiences 2-4 maintenance windows annually, so a second provider is
needed to meet the SLA.

5. Unique Routing Policy Justification (AFRINIC, or Additional ASNs at ARIN)

The RIPE NCC does not accept this route: its policy requires multihoming whatever the routing policy (ripe-679). AFRINIC accepts a unique routing policy or technical need instead of interconnection, and ARIN asks for one only for a second or further ASN. If you file in the RIPE region with one upstream, add the second upstream first.

Required elements:

• Specific routing policy that requires an ASN
• Technical explanation of why alternative approaches are insufficient
• How the ASN enables your business objectives
• Implementation details

Example (Anycast CDN):

Unique Routing Policy Justification:

We operate a content delivery network with points of presence in Amsterdam,
Frankfurt, Paris, and London. Our service requires anycast implementation
where identical IPv4 prefixes (203.0.113.0/24) are announced from multiple
locations simultaneously. Traffic automatically routes to the geographically
nearest PoP based on BGP routing metrics.

This routing policy requires an ASN because:
1. Anycast announces the same prefix from several locations. Our own AS
   number keeps one origin AS behind every announcement, so a single ROA
   covers all PoPs
2. Each PoP establishes independent BGP sessions with local IXPs and transit
   providers using our ASN for path identification
3. We implement location-specific BGP communities for traffic engineering
   that cannot be achieved through provider-assigned addressing
4. Our customers require consistent ASN visibility across all PoPs for
   routing validation and RPKI implementation

Alternative approaches (provider-assigned addressing, single-homed connections)
cannot support the distributed anycast architecture our CDN business model
depends on.

6. IP Address Resources

Document your current and planned IP address holdings:

Include:

• Current IPv4 allocations/assignments
• Current IPv6 allocations/assignments
• Where each prefix is registered (RIPE Database object, transfer record, lease contract)
• Plans for announcing these prefixes
• Growth projections

Example:

Current IP Address Resources:

IPv4:
- Prefix: 203.0.113.0/24 (256 addresses)
- Type: Provider Independent (PI) space, received by transfer under ripe-807 in 2024
- Registered in the RIPE Database, netname EXAMPLE-NET
- Current utilization: 220/256 (86%)
- Announcement plan: Full /24 announced to both upstream providers

IPv6:
- Allocation: 2001:db8::/48
- Type: Provider Independent (PI) space
- Assigned by: RIPE NCC
- Assignment date: 2022-03-15
- Registered in the RIPE Database, netname EXAMPLE-NET6
- Current utilization: 150 /64 subnets active
- Announcement plan: /48 announced to both upstream providers

We require an ASN to announce these provider-independent allocations through
our multi-homed BGP configuration.

7. Routing Policy Details

Describe your intended BGP routing strategy:

Include:

• Route announcement plans
• Route filtering policies
• BGP communities usage
• Traffic engineering approach
• Failover behavior
• Peering plans (if applicable)

Example:

Routing Policy:

Route Announcements:
- IPv4: 203.0.113.0/24 announced with identical AS-PATH to both providers
- IPv6: 2001:db8::/48 announced with identical AS-PATH to both providers
- No more-specific prefixes announced under normal circumstances

Route Filtering:
- Accept default route + full table from both providers
- Filter bogon prefixes, private address space, and AS paths >10 hops
- Implement RPKI validation for received routes (drop invalid)

Traffic Engineering:
- Use BGP local preference for primary/backup provider selection
- Implement AS-PATH prepending for inbound traffic steering during maintenance
- Deploy BGP communities for provider-specific route control:
  * 64500:100 - Announce to primary provider only
  * 64500:200 - Announce to secondary provider only
  * 64500:999 - Blackhole traffic (DDoS mitigation)

Failover Behavior:
- Automatic failover through BGP convergence (<60 seconds)
- Health monitoring triggers manual traffic steering if needed
- Maintain BGP sessions to both providers continuously

Future Peering:
- Plan to join AMS-IX within 6 months
- Considering DE-CIX for Frankfurt PoP
- Open peering policy for settlement-free peers

The RIPE NCC asks for the routing policy "defined in RPSL language, as used in the RIPE Database" (ripe-679). For a two-upstream network that is a handful of lines:

aut-num:    AS64510
as-name:    EXAMPLE-AS
import:     from AS64496 accept ANY
export:     to AS64496 announce AS64510
import:     from AS64497 accept ANY
export:     to AS64497 announce AS64510
mp-import:  afi ipv6.unicast from AS64496 accept ANY
mp-export:  afi ipv6.unicast to AS64496 announce AS64510
mp-import:  afi ipv6.unicast from AS64497 accept ANY
mp-export:  afi ipv6.unicast to AS64497 announce AS64510

The RIPE NCC creates the aut-num object when it assigns the number; these lines are what the policy asks you to state in the request.

8. Technical Capability Demonstration

No RIR policy requires this section. Keep it short and use it when a registry or sponsoring LIR asks a follow-up question about operations:

Include:

• Staff qualifications and certifications
• Equipment specifications
• Monitoring and management tools
• Operational procedures
• Support arrangements

Example:

Technical Capability:

Network Engineering Team:
- Lead Network Engineer: 8 years experience, CCIE #45678
- Senior Network Engineer: 5 years experience, CCNP, JNCIA
- Network Engineer (2): CCNA certified, BGP experience
- 24/7 NOC: Outsourced to [Provider], BGP-trained staff

Equipment:
- Primary router: edge router 1 (full BGP table, redundant PSU)
- Secondary router: edge router 2 (full redundancy)
- Configuration: VRRP for first-hop redundancy, iBGP between routers

Monitoring:
- BGP session monitoring: LibreNMS with BGP alerting
- Route monitoring: RIPE RIS, Hurricane Electric BGP Toolkit
- Uptime monitoring: Pingdom, UptimeRobot (external)
- Internal monitoring: Prometheus + Grafana

Operational Procedures:
- Documented BGP configuration procedures
- Change management process with peer review
- Incident response procedures
- Regular BGP configuration backups

9. Implementation Timeline

Provide realistic timeline for ASN utilization:

Example:

Implementation Timeline:

Immediate (upon ASN assignment):
- Update router configurations with assigned ASN
- Create route objects in RIPE IRR
- Configure ROAs for RPKI

Week 1:
- Establish BGP sessions with primary provider (AS64496)
- Initial route announcements and testing
- Verify global route propagation

Week 2:
- Establish BGP sessions with secondary provider (AS64497)
- Configure multi-homing with traffic engineering
- Failover tests

Week 3-4:
- Transition customer traffic to multi-homed configuration
- Monitor route stability and performance
- Fine-tune traffic engineering based on observed patterns

We have already secured transit agreements with both providers and
configured all necessary infrastructure. ASN implementation will occur
immediately upon assignment.

Once the number is assigned, create the route objects and RPKI ROAs before the first announcement, and publish an ASPA object naming your upstreams from the RIPE NCC RPKI Dashboard, where ASPA has been in production since December 2025. Announce promptly: the RIPE NCC contacts holders of unannounced ASNs and returns a number still unused after three months (AS number clean-up).

10. Business Justification

No RIR policy requires a business case. If you include one, keep it to the facts a follow-up question would need:

Example:

Business Justification:

Our hosting platform SLA guarantees require 99.95% monthly uptime. Analysis
of our previous 24 months shows:
- 4 upstream provider outages (avg 2.3 hours each)
- 2 DDoS attacks affecting routing
- 1 provider bankruptcy causing 48-hour transition period

These incidents resulted in:
- €85,000 in SLA penalty payments to customers
- Loss of 3 major enterprise accounts
- Damage to reputation and customer confidence

Multi-homing with our own ASN will:
- Eliminate single provider dependency (immediate failover)
- Enable DDoS mitigation through traffic engineering
- Provide provider independence for business continuity
- Reduce future SLA violation risk by estimated 90%
- Improve competitive positioning for enterprise customers requiring
  redundant infrastructure

The ASN costs €130 per year through a sponsoring LIR, plus transit. A single
SLA violation event costs more than that.

Complete Justification Examples

Example 1: Hosting Provider Multi-homing

ASN Justification - TechHost Europe Ltd

Executive Summary:
TechHost Europe Ltd requests an Autonomous System Number to implement
multi-homed connectivity for our cloud hosting infrastructure. We operate
a European hosting platform serving 500+ business customers and require
independent routing capability through BGP to meet our 99.95% uptime SLA
and stay independent of any single provider.

Organization Background:
TechHost Europe Ltd (UK Company No. 12345678) is an established hosting
provider founded in 2018. We provide cloud hosting, managed services, and
dedicated server infrastructure to enterprise customers across Europe.
Our current customer base includes 520 active accounts operating 2,400+
virtual servers under our management.

Network Infrastructure:
- Primary data center: AMS3, Amsterdam (40 racks, 150 physical servers)
- Secondary data center: FR5, Frankfurt (20 racks, 60 physical servers)
- Current IP resources: 203.0.113.0/24 (IPv4 PI, received by transfer), 2001:db8::/48 (IPv6 PI)
- Network capacity: 20 Gbps total transit, 10 Gbps IXP capacity planned
- BGP equipment: two redundant edge routers with full-table capacity

Multi-homing Configuration:
Primary Transit Provider:
- Provider: Transit A (AS64496)
- Contact: noc@transit-a.example
- Service: 10 Gbps transit, 10GE cross-connect at AMS3
- Contract: Signed, service ready for activation

Secondary Transit Provider:
- Provider: Transit B (AS64497)
- Contact: noc@transit-b.example
- Service: 10 Gbps transit, 10GE cross-connect at AMS3
- Contract: Signed, service ready for activation

Justification for Multi-homing:
Our SLA guarantees 99.95% monthly uptime with financial penalties for
violations. Historical analysis shows 4 upstream provider outages in
24 months (averaging 2.3 hours each), resulting in €85,000 in SLA penalties
and loss of 3 major accounts. Multi-homing eliminates single provider
dependency, enables automatic failover, and ensures SLA compliance.

IP Address Resources:
IPv4: 203.0.113.0/24 (PI, received by transfer under ripe-807 in 2024)
IPv6: 2001:db8::/48 (RIPE NCC PI assignment, 2022-03-15)
These provider-independent resources will be announced via BGP to both
upstream providers for redundancy.

Routing Policy:
- Announce /24 IPv4 and /48 IPv6 to both providers with equal AS-PATH
- Accept full BGP table from both providers for best-path selection
- Implement BGP communities for traffic engineering
- Use AS-PATH prepending for inbound traffic steering
- Deploy RPKI with ROAs for all prefixes
- Automatic failover via BGP convergence (<60 seconds)

Technical Capability:
Our team includes 5 network engineers (CCIE, CCNP, CCNA qualified) with
extensive BGP experience. We operate enterprise-grade routing equipment
with monitoring (LibreNMS, RIPE RIS). We maintain documented procedures
for BGP management and 24/7 NOC operations.

Implementation Timeline:
Upon ASN assignment, BGP sessions will be established within 2 weeks with
failover tests before transitioning production traffic. All transit
agreements are signed and infrastructure is ready for immediate deployment.

Business Impact:
The ASN (€130 per year through a sponsoring LIR, plus transit) is justified
by eliminating future SLA violations, preventing customer losses, and
enabling our European expansion strategy. Our business model requires
provider-independent routing for competitive positioning in the enterprise
hosting market.

We respectfully request approval of this ASN application to support our
operational requirements and business objectives.

Example 2: Enterprise Multi-homing

ASN Justification - GlobalFinance Bank

Executive Summary:
GlobalFinance Bank requests an Autonomous System Number to implement
multi-homed Internet connectivity for business-critical trading and
online banking operations. We require independent routing control to
ensure continuous service availability and meet financial regulatory
requirements for infrastructure resilience.

Organization Background:
GlobalFinance Bank is a regulated financial institution (FCA Registration
No. 123456) operating in the UK since 1985. We provide retail and commercial
banking services to 250,000 customers with online banking and
trading platform operations. Our technical infrastructure team includes
15 network engineers managing global connectivity.

Network Infrastructure:
- Primary data center: London Docklands (Equinix LD8)
- Disaster recovery site: Manchester colocation
- Trading floor connectivity: London, Frankfurt
- Current IP resources: 198.51.100.0/23 (IPv4 PI, received by transfer)
- Network equipment: Juniper MX series routers (N+1 redundancy)

Multi-homing Configuration:
Primary Transit Provider:
- Provider: Transit A (AS64496)
- Contact: noc@transit-a.example
- Service: 1 Gbps dedicated Internet access
- Connection: Direct fiber to LD8 data center

Secondary Transit Provider:
- Provider: Transit B (AS64497)
- Contact: noc@transit-b.example
- Service: 1 Gbps dedicated Internet access
- Connection: Direct fiber to LD8 data center (diverse path verified)

Justification for Multi-homing:
Financial regulatory requirements (PRA, FCA) mandate infrastructure
resilience for systemically important institutions. Our online banking
platform serves 180,000 active digital customers, and our trading platform
handles £250M daily volume. Any connectivity outage results in:
- Regulatory compliance violations
- Trading disruption (avg £1.2M revenue impact per hour)
- Reputational damage to brand
- Customer confidence erosion

Multi-homing with independent ASN provides:
- Automatic failover for continuous operations
- Provider independence for risk management
- Load balancing for performance optimization
- Compliance with regulatory infrastructure requirements

IP Address Resources:
IPv4: 198.51.100.0/23 (IPv4 PI, received by transfer, 512 addresses)
IPv6: 2001:db8:1::/48 (RIPE PI assignment)
Used for: Online banking platform, trading systems, public-facing services
Announcement: Full /23 and /48 announced via both providers

Routing Policy:
- Conservative routing: accept default + financial sector prefixes only
- Strict security: RPKI validation, bogon filtering, AS-PATH validation
- Traffic engineering: prefer primary provider (AS-PATH prepending on backup)
- Automated failover: health monitoring triggers BGP route withdrawal
- Security communities: DDoS blackholing capability via both providers

Technical Capability:
Network Operations team: 15 engineers (multiple CCIEs, financial sector exp.)
Equipment: Juniper MX960 routers (production-grade, redundant)
Monitoring: SNMP and NetFlow monitoring with SLA reporting
Procedures: ITIL-compliant change management, 24/7/365 NOC operations
Security: Regular penetration testing, security audits, incident response

Regulatory Compliance:
This ASN implementation supports compliance with:
- PRA Supervisory Statement SS1/21 (operational resilience)
- FCA operational resilience requirements
- BIS cyber security framework
- Internal risk management policies

Implementation Timeline:
Week 1-2: ASN configuration, IRR/RPKI setup
Week 3-4: BGP session establishment, extensive testing
Week 5-6: Gradual traffic migration with monitoring
Week 7+: Full production operation, continuous monitoring

We request approval of this ASN application to support our regulatory
compliance obligations and ensure continuous service availability for
critical banking operations.

Example 3: CDN with Unique Routing Policy

ASN Justification - FastEdge CDN

Executive Summary:
FastEdge CDN requests an Autonomous System Number to implement anycast
routing for our content delivery network with points of presence across
Europe. Our unique routing policy requires simultaneous announcement of
identical prefixes from multiple geographic locations, which cannot be
achieved through traditional provider-assigned addressing.

Organization Background:
FastEdge CDN (Netherlands B.V. No. 87654321) operates a content delivery
network serving media companies, e-commerce platforms, and high-traffic
websites across Europe. Founded in 2020, we serve 120 customers from four
European PoPs with a combined peak of 40 Gbps.

Network Infrastructure:
Points of Presence:
- Amsterdam: AMS-IX member, 20 Gbps capacity
- Frankfurt: DE-CIX member, 20 Gbps capacity
- London: LINX member, 10 Gbps capacity
- Paris: France-IX member, 10 Gbps capacity

Current IP resources: 203.0.113.0/24 (IPv4 PI, by transfer), 2001:db8::/44 (IPv6 PI)
Equipment: Juniper QFX5100 switches, Linux-based edge servers (200+ total)

Unique Routing Policy Justification:
Our CDN service requires anycast implementation where identical IP prefixes
are announced from all four PoP locations simultaneously. This routing
architecture is impossible without our own ASN because:

1. Anycast Requirements:
   - Same /24 prefix (203.0.113.0/24) announced from 4 different locations
   - Users automatically route to nearest PoP based on BGP metrics
   - Requires consistent origin ASN across all announcements for validation
   - With provider addressing, each provider would originate the prefix from its own AS

2. Geographic Load Distribution:
   - BGP routing directs users to geographically closest PoP
   - Each PoP independently establishes BGP sessions with IXPs and transits
   - Implements location-specific BGP communities for traffic engineering
   - Uses selective announcement (announce in Europe, not globally) via communities

3. DDoS Mitigation:
   - Distributed traffic absorption across 4 locations during attacks
   - Selective PoP withdrawal via BGP for attack isolation
   - Cannot be achieved with single-origin provider addressing

4. Customer Requirements:
   - Enterprise customers require RPKI validation (needs consistent ASN)
   - Monitoring and analytics based on ASN visibility
   - SLA reporting requires single ASN identification

Alternative approaches considered and rejected:
- Provider addressing: each provider would originate the prefix from its own AS, so no single ROA is possible
- Multiple ASNs: Breaks anycast model, increases complexity
- Single PoP: Defeats entire CDN business model and value proposition

This unique routing policy is fundamental to our CDN business model and
cannot be achieved through any alternative addressing approach.

Current Connectivity:
Amsterdam: AMS-IX (10G port) + Transit A (AS64496, 10G transit)
Frankfurt: DE-CIX (10G port) + Transit B (AS64497, 10G transit)
London: LINX (10G port) + Transit C (AS64498, 10G transit)
Paris: France-IX (1G port) + Transit D (AS64499, 10G transit)

Routing Policy Details:
- Announce 203.0.113.0/24 from all 4 PoPs with local ASN
- No more-specific announcements (maintain /24 boundary)
- Implement BGP communities for regional preference:
  * 64500:1000 - Amsterdam region preference
  * 64500:2000 - Frankfurt region preference
  * 64500:3000 - London region preference
  * 64500:4000 - Paris region preference
- Accept default route from transits, full table from IXPs
- Implement RPKI with ROAs for /24 prefix

IP Address Resources:
IPv4: 203.0.113.0/24 (IPv4 PI, by transfer, anycast use)
IPv6: 2001:db8::/44 (RIPE PI, /48 per PoP anycast)
Current utilization: 200/256 IPv4 addresses (78%)
Growth: Plan for /23 within 24 months

Technical Capability:
Network team: 8 engineers (CCNP, JNCIE certifications)
Equipment: Juniper QFX5100 (BGP-capable, redundant at each PoP)
Monitoring: Custom BGP monitoring + Route server + RIPE Atlas probes
Automation: Ansible-based BGP configuration management
Operations: 24/7 NOC monitoring all BGP sessions

Implementation Timeline:
Week 1: Configure ASN on all PoP routers
Week 2: Establish BGP sessions at all IXPs and with transits
Week 3: Begin route announcements with careful monitoring
Week 4: Full production anycast operation
All infrastructure and BGP connectivity contracts are in place.

Business Impact:
Our entire CDN business model depends on anycast routing. Without an ASN,
we cannot deliver our core service offering. The investment in ASN and
multi-location connectivity (€150K annually) is fundamental to our €2M
annual revenue business model.

We respectfully request approval of this ASN application to enable our
anycast CDN infrastructure.

The figures in these examples assume a sponsored ASN: €130 per year through a sponsoring LIR (as of September 2026), €50 of which is the RIPE NCC fee at cost. Holding the ASN as a RIPE NCC member instead costs €1,800 per year plus €50 per ASN under the RIPE NCC Charging Scheme 2026 (ripe-848), and €1,894 with one ASN included from 2027 (ripe-867, adopted May 2026).

Common Mistakes to Avoid

Weak Justifications That Get Rejected

1. A motive with no network behind it

Weak: "We want to obtain an ASN to learn BGP routing and gain experience
with Internet routing protocols."

Stronger: "We run a homelab with a VPS at two providers (AS64496, AS64497)
and will announce 2001:db8:100::/48 to both. Both providers have confirmed
BGP sessions; invoices are attached."

To practise BGP without a public ASN, use the private ASN ranges or join dn42. Both count as learning; neither needs a registry request.

2. Vague future plans

Weak: "We might need multi-homing in the future as our business grows."

Stronger: "We have signed transit agreements with Transit A (AS64496) and
Transit B (AS64497) with service activation within 30 days of the ASN
assignment. Contracts and letters of intent are available on request."

3. Single-homed without unique policy

Weak: "We have one upstream provider but want our own ASN for independence."

Stronger: "We will announce 203.0.113.0/24 from Amsterdam, Frankfurt and
London, with transit from AS64496 and AS64497 and peering at two IXPs. Each
site has a second upstream, so the network is multihomed at every location."

4. Missing technical details

Weak: "We need an ASN for our network."

Stronger: "We operate multi-homed hosting infrastructure with:
- Primary transit: Transit A AS64496, 10 Gbps, noc@transit-a.example
- Secondary transit: Transit B AS64497, 10 Gbps, noc@transit-b.example
- IP resources: 203.0.113.0/24 (PI, by transfer), 2001:db8::/48 (PI)
- Equipment: two edge routers holding full BGP tables
- Staff: CCNP-certified network engineers"

5. Insufficient infrastructure

Weak: "We plan to get IP addresses after receiving our ASN."

Stronger: "We hold 2001:db8::/48 (IPv6 PI, assigned by the RIPE NCC) and
203.0.113.0/24 (IPv4 PI, received by transfer), both registered in the RIPE
Database. We will announce both prefixes to our two upstream providers."

Best Practices for Strong Justifications

1. Be Specific and Concrete

Use real data, specific numbers, and verifiable facts:

• Named upstream providers with ASNs and contact information
• Actual prefixes with the RIPE Database objects that register them
• Specific equipment models and capacities
• Real customer numbers and usage statistics
• Concrete implementation timelines with dates

2. Address Technical Capability

If a registry or sponsoring LIR asks how you will run BGP, answer with:

• Staff qualifications and certifications
• Equipment specifications (model numbers, capabilities)
• Monitoring and management tools in use
• Documented operational procedures
• Support arrangements (24/7 NOC, escalation procedures)

3. Explain Business Context

Business context is optional at every RIR. Where you add it, stick to facts:

• SLA requirements and penalties
• Regulatory compliance needs
• Customer demands and expectations
• Competitive positioning
• Revenue impact of downtime

4. Provide Verifiable Information

Make it easy for RIR to verify your claims:

• Upstream provider contacts that will respond to RIR verification
• Prefixes that exist in the RIR database
• Company registration numbers that can be verified
• Specific contracts or agreements (mention availability upon request)

5. Follow RIR-Specific Formats

Each RIR has preferred application formats:

• RIPE NCC: LIR Portal request, filed by your sponsoring LIR or under a direct contract; peers, prefix and routing policy in RPSL
• ARIN: ARIN Online request; a first ASN is issued on request, additional ones need a unique routing policy
• APNIC: MyAPNIC request; multihomed or an interconnection need, now or shortly after assignment
• LACNIC: routing policy, peer ASNs and prefixes to be announced; interconnection within six months
• AFRINIC: resource membership; interconnection with more than one AS, or a unique routing policy or technical need, within six months

Filing a RIPE NCC ASN Request Through Us

In the RIPE region, we file the ASN request as your sponsoring LIR. You give us your two upstreams, the prefix you will announce (or add a leased /48 or an IPv6 PI /48 at the order step) and the provider contracts or invoices. Individuals need a government ID, organisations a recent registration document. Individuals can hold an ASN in their own name.

The ASN costs €130 per year (€80 our fee plus the €50 RIPE NCC fee at cost, as of September 2026), or €234 for two years prepaid. Your ASN is typically live in 1 to 2 business days once your file is complete, RIPE NCC processing included. The order form is on the ASN registration page. Sponsor prices across the market are listed in the ASN sponsorship price comparison.

Frequently Asked Questions

How long should my ASN justification be?

At the RIPE NCC there is no essay field. The request is two peers with contact e-mails, the prefix you will announce and your routing policy in RPSL. A short paragraph on what the network does helps when the RIPE NCC asks a follow-up question. At the other registries, one page covering the items above is enough.

Do I need letters from my upstream providers?

The RIPE NCC request form asks for each peer's ASN and a contact e-mail; through us, you upload provider contracts or invoices instead of letters. ARIN needs nothing for a first ASN. APNIC, LACNIC and AFRINIC want the interconnection plan on paper: a signed contract or a letter of intent from the provider does the job.

What if I don't have multi-homing yet?

A signed transit contract with activation pending counts at every registry; so does a letter of intent from the provider. LACNIC and AFRINIC accept a plan that completes within six months, APNIC one that completes shortly after assignment. ARIN issues a first ASN on request (NRPM 5). AFRINIC accepts a unique routing policy or technical need instead of multihoming (CPM 7.2); the RIPE NCC does not. Without a concrete plan, the request stalls.

Can I reapply if my application is rejected?

Yes. Address the reasons given, then file again:

1. Review feedback carefully
2. Address specific deficiencies cited
3. Gather additional documentation as needed
4. Resubmit with improved justification

Should I include network diagrams?

Network diagrams can strengthen your application:

• Include if they clearly illustrate your multi-homing setup
• Show BGP session relationships and routing architecture
• Keep simple and focused on relevant topology
• Not required by most RIRs but can help clarify complex configurations

How do I justify IPv6-only ASN requests?

No ASN policy in the five regions ties the ASN to IPv4. What matters is a prefix to announce: an IPv6 PI assignment from the RIPE NCC is a /48 at minimum (ripe-738 section 7.1), and a leased /48 works the same way in the request. If you have no prefix yet, our order form adds a leased /48 or an IPv6 PI /48 to the ASN request.

Summary

At the RIPE NCC, the request succeeds or stalls on two facts: two named upstreams that will confirm the session, and a routing policy you can state in RPSL. Collect the provider contracts or invoices before you file. Leave business cases and staff CVs for a follow-up question. If your network is single-homed today, add the second upstream first; the policy has no workaround.

Next Steps

Prepare your ASN application:

• Learn basics: Read What is an ASN (Autonomous System Number)? Understanding BGP Routing
• Calculate costs: Review ASN Registration Cost Breakdown (2026): Complete Fee Analysis Across All RIRs
• Explore use cases: Check ASN Use Cases and Real-World Examples