How to Prepare Your ASN Justification: Complete Documentation Guide

The justification you provide to your Regional Internet Registry (RIR) is the most critical component of your ASN application. A well-prepared justification clearly demonstrates your legitimate need for an ASN, addresses all technical requirements, and significantly increases your approval chances.

This comprehensive guide walks you through preparing a strong ASN justification, providing templates, examples, and best practices that work across all five RIRs. Whether you're applying to RIPE, ARIN, APNIC, LACNIC, or AFRINIC, these guidelines will help you build a compelling case for your ASN request.

Understanding ASN Justification Requirements

Before writing your justification, understand what RIRs are evaluating:

What RIRs Look For

All RIRs assess ASN applications based on RFC 1930 principles:

Key evaluation criteria:

1. Legitimate operational need for independent routing
2. Technical capability to manage BGP routing
3. Clear routing policy that requires an ASN
4. Appropriate infrastructure (IP addresses, upstream connections)
5. Organizational legitimacy and stability

Red flags that trigger rejections:

• Vague or generic justifications
• Learning BGP or "future plans" without concrete details
• Single-homed networks without unique routing policy
• Inability to demonstrate technical capability
• Missing upstream provider verification
• Insufficient IP address resources

RIR-Specific Focus Areas

While all RIRs evaluate similar criteria, emphasis varies:

RIPE NCC focuses on:

• Multi-homing verification (two upstream providers)
• Upstream provider contact verification
• IP address allocation requirements (/24 IPv4 or /48 IPv6)

ARIN emphasizes:

• Flexibility: Multi-homing OR unique routing policy
• Organizational legitimacy
• Projected implementation timeline

APNIC requires:

• Detailed routing policy documentation
• Comprehensive interconnection plans
• RFC 1930 compliance demonstration

LACNIC looks for:

• Interconnection plans (current or within 6 months)
• Detailed routing policy
• Clear timeline for implementation

AFRINIC evaluates:

• Multi-homing OR unique routing policy OR technical need
• Contribution to African Internet infrastructure
• Clear operational justification

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

Essential Documentation Components

Every strong ASN justification includes these core elements:

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 ensure 99.95%
uptime SLA compliance and provider independence.

2. Organization Background

Establish organizational legitimacy and operational context:

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 currently 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 allocations: 203.0.113.0/24 (IPv4 PI), 2001:db8::/48 (IPv6 PI)
- Hosting capacity: 150 physical servers, 2,400+ VMs
- Network capacity: 20 Gbps total connectivity
- BGP-capable routing: Cisco Catalyst 9300 series routers (2x redundant)

4. Multi-homing Justification (If Applicable)

If applying based on multi-homing, provide comprehensive details:

Required information:

• Names of upstream providers
• ASNs of upstream providers
• 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: GTT Communications
- ASN: AS3257
- Contact: noc@gtt.net
- Service: 10 Gbps committed transit
- Connection type: 10GE cross-connect at AMS3

Secondary Transit Provider:
- Provider name: Telia Carrier
- ASN: AS1299
- Contact: noc@teliacarrier.com
- 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 for optimal performance. Historical data shows
each provider experiences 2-4 maintenance windows annually, making multi-
homing essential for SLA compliance.

5. Unique Routing Policy Justification (If Applicable)

If not multi-homing, explain your unique routing requirements:

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 requires announcing the same prefix from multiple ASes, which
   only works with our own AS number for route origin consistency
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 this distributed anycast architecture essential to our CDN
business model.

6. IP Address Resources

Document your current and planned IP address holdings:

Include:

• Current IPv4 allocations/assignments
• Current IPv6 allocations/assignments
• Assignment documentation (RIR allocation notice, PI assignment, etc.)
• Plans for announcing these prefixes
• Growth projections

Example:

Current IP Address Resources:

IPv4:
- Allocation: 203.0.113.0/24 (256 addresses)
- Type: Provider Independent (PI) space
- Assigned by: RIPE NCC
- Assignment date: 2022-03-15
- Assignment ID: EU-ZZ-203-0-113-0
- 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
- Assignment ID: EU-ZZ-2001-0db8
- 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

8. Technical Capability Demonstration

Prove you can manage BGP routing:

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: Cisco Catalyst 9300-24UX (BGP capable, redundant PSU)
- Secondary router: Cisco Catalyst 9300-24UX (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 (AS3257)
- Initial route announcements and testing
- Verify global route propagation

Week 2:
- Establish BGP sessions with secondary provider (AS1299)
- Configure multi-homing with traffic engineering
- Comprehensive testing of failover scenarios

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.

10. Business Justification

Explain why the ASN is essential to your business:

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 cost of obtaining and operating an ASN (€1,500/year + transit costs)
is justified by eliminating a single SLA violation event.

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 ensure 99.95% uptime SLA
compliance and provider independence.

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 allocations: 203.0.113.0/24 (IPv4 PI), 2001:db8::/48 (IPv6 PI)
- Network capacity: 20 Gbps total transit, 10 Gbps IXP capacity planned
- BGP equipment: Cisco Catalyst 9300 series (2x redundant routers)

Multi-homing Configuration:
Primary Transit Provider:
- Provider: GTT Communications (AS3257)
- Contact: noc@gtt.net
- Service: 10 Gbps transit, 10GE cross-connect at AMS3
- Contract: Signed, service ready for activation

Secondary Transit Provider:
- Provider: Telia Carrier (AS1299)
- Contact: noc@teliacarrier.com
- 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 (RIPE PI assignment EU-ZZ-203-0-113-0, 2022-03-15)
IPv6: 2001:db8::/48 (RIPE PI assignment EU-ZZ-2001-0db8, 2022-03-15)
These provider-independent resources will be announced via BGP to both
upstream providers for optimal routing and redundancy.

Routing Policy:
- Announce /24 IPv4 and /48 IPv6 to both providers with equal AS-PATH
- Accept full BGP table from both providers for optimal routing
- 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 Cisco routing
equipment with comprehensive 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
comprehensive testing before transitioning production traffic. All transit
agreements are signed and infrastructure is ready for immediate deployment.

Business Impact:
The ASN investment (€1,500/year + transit costs) 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 significant 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 (TelecityGroup)
- Trading floor connectivity: London, Frankfurt
- Current IP resources: 198.51.100.0/23 (RIPE PI assignment)
- Network equipment: Juniper MX series routers (N+1 redundancy)

Multi-homing Configuration:
Primary Transit Provider:
- Provider: BT Global Services (AS5400)
- Contact: noc@bt.com
- Service: 1 Gbps dedicated Internet access
- Connection: Direct fiber to LD8 data center

Secondary Transit Provider:
- Provider: Vodafone Business (AS1273)
- Contact: noc@vodafone.com
- 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 (RIPE PI assignment, 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: Comprehensive SNMP/NetFlow with financial-grade SLA monitoring
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 SS2/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 currently deliver 15 Tbps
monthly traffic for 120 customers from 4 European PoPs.

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), 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
   - Cannot be implemented with provider-assigned addresses (different origins)

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: Cannot implement anycast (different origin ASes)
- 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) + NTT (AS2914, 10G transit)
Frankfurt: DE-CIX (10G port) + GTT (AS3257, 10G transit)
London: LINX (10G port) + Telia (AS1299, 10G transit)
Paris: France-IX (1G port) + Cogent (AS174, 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 (RIPE PI, 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.

Common Mistakes to Avoid

Weak Justifications That Get Rejected

1. "We want to learn BGP"

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

✅ CORRECT: "We operate a hosting platform requiring multi-homed connectivity
for SLA compliance. Our team has extensive BGP experience (CCNP certified)
and we have signed transit agreements with two providers (AS3257, AS1299)."

2. Vague future plans

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

✅ CORRECT: "We have signed transit agreements with GTT (AS3257) and Telia
(AS1299) with service activation scheduled for Q2 2025. Contracts and LOAs
available upon request."

3. Single-homed without unique policy

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

✅ CORRECT: "We require anycast routing to announce 203.0.113.0/24 from
multiple geographic locations (Amsterdam, Frankfurt, London) which requires
consistent origin ASN across all announcements. This cannot be achieved with
provider-assigned addressing."

4. Missing technical details

❌ WRONG: "We need an ASN for our network."

✅ CORRECT: "We operate multi-homed hosting infrastructure with:
- Primary transit: GTT AS3257, 10 Gbps, noc@gtt.net
- Secondary transit: Telia AS1299, 10 Gbps, noc@teliacarrier.com
- IP resources: 203.0.113.0/24 (PI), 2001:db8::/48 (PI)
- Equipment: Cisco Catalyst 9300 BGP-capable routers
- Staff: CCNP-certified network engineers"

5. Insufficient infrastructure

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

✅ CORRECT: "We hold RIPE PI allocations: 203.0.113.0/24 (IPv4, assignment
EU-ZZ-203-0-113-0) and 2001:db8::/48 (IPv6, assignment EU-ZZ-2001-0db8),
both assigned 2022-03-15. We will announce these prefixes via BGP to both
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 IP address allocations with assignment IDs
• Specific equipment models and capacities
• Real customer numbers and usage statistics
• Concrete implementation timelines with dates

2. Address Technical Capability

Prove you can manage BGP:

• 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

Help RIR understand why ASN is essential to your business:

• 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
• IP allocation IDs that exist in RIR databases
• 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: Online form with specific fields for upstream providers
• ARIN: Online request with routing policy or multi-homing justification
• APNIC: Detailed routing policy template required
• LACNIC: Interconnection timeline critical
• AFRINIC: Business context and technical justification both important

Using Via-Registry Services for Application Preparation

Via-Registry.com provides expert assistance with ASN justification preparation:

Our services include:

• Justification review and improvement
• Template customization for your specific situation
• Technical documentation preparation
• Upstream provider coordination
• RIR-specific application guidance
• Revision assistance if additional information requested

Benefits:

• Higher approval rates through properly prepared applications
• Faster processing with complete documentation
• Expert guidance on RIR-specific requirements
• Professional presentation of your justification

Get started with our ASN Registration Service for expert application preparation assistance.

Frequently Asked Questions

How long should my ASN justification be?

Length varies by RIR and complexity:

• Minimum: 200-300 words covering essential points
• Typical: 500-800 words for straightforward multi-homing
• Complex cases: 1,000-1,500 words for unique routing policies or special situations

Quality matters more than length. Be thorough but concise.

Do I need letters from my upstream providers?

Requirements vary by RIR:

• RIPE: No formal letters required, but RIR may contact providers to verify
• ARIN: No letters required with streamlined process
• APNIC: Letters of intent helpful but not mandatory
• LACNIC: Contracts or agreements helpful for verification
• AFRINIC: Supporting documentation helpful

Provide contact information so RIR can verify directly.

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

Acceptable approaches:

• Signed contracts: Show agreements are in place with activation pending
• Letters of intent: Provider LOAs indicating willingness to provide BGP service
• Six-month timeline: LACNIC accepts plans within 6 months
• Unique routing policy: ARIN and AFRINIC accept this without multi-homing

Don't apply without concrete plans - "maybe someday" gets rejected.

Can I reapply if my application is rejected?

Yes, after addressing rejection reasons:

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

Most rejections are due to incomplete information rather than fundamental ineligibility.

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?

IPv6-only requests are accepted by all RIRs:

• Emphasize IPv6 infrastructure deployment
• Show IPv6 prefix allocation (/48 minimum typically required)
• Explain IPv6-specific routing needs
• Demonstrate IPv6 capability and commitment

Summary

Preparing a strong ASN justification requires:

Essential components:

• Clear executive summary of your request
• Organization background and legitimacy
• Detailed network infrastructure description
• Multi-homing or unique routing policy explanation
• IP address resource documentation
• Routing policy details
• Technical capability demonstration
• Realistic implementation timeline
• Business justification

Best practices:

• Be specific and concrete with verifiable facts
• Provide complete upstream provider information
• Demonstrate technical capability to manage BGP
• Explain business context and criticality
• Follow RIR-specific formats and requirements
• Avoid generic statements and vague plans

Common mistakes to avoid:

• Vague or generic justifications
• "Learning BGP" as primary reason
• Missing upstream provider verification details
• Insufficient IP address resource documentation
• Lack of technical capability demonstration
• Single-homed without unique routing policy

A well-prepared justification significantly increases approval likelihood and speeds processing time.

Next Steps

Prepare your ASN application:

• Start planning: Review our Complete Guide to ASN Registration
• Understand requirements: See ASN Registration Requirements by RIR
• Learn basics: Read What is an ASN? How BGP Routing Works
• Calculate costs: Review Cost Breakdown: ASN Registration Fees
• Explore use cases: Check ASN Use Cases and Real-World Examples