How to Get IP Address Space and an ASN: IRINN, APNIC, and BGP Guide

Anil Jalela · Published Nov 15, 2022 · 18 min read

Getting portable IP address space and an Autonomous System Number is partly a registry application and partly a network-engineering commitment. You must prove the organization, document real need, define a routing policy, arrange upstream connectivity, and remain responsible for registration, routing security, abuse contacts, reverse DNS, and annual fees. This guide takes an Indian applicant through IRINN and APNIC, then continues through a safe dual-stack BGP launch.

Start with the operating requirement, not the form. An ASN is useful when your network will be multihomed or must interconnect with another autonomous system under its own routing policy. Portable addresses can reduce renumbering and provider dependence, but a registry delegation does not guarantee that every network will accept or route the prefix.

Know what you are requesting

Internet number resources are delegated for use under policy. Treat the records, fees, and continuing eligibility as operational obligations. Do not describe a delegation as buying permanent property.

Follow the registry hierarchy

IANA coordinates the global number pools and delegates large blocks to five Regional Internet Registries. Network operators normally work with the RIR, National Internet Registry, or Local Internet Registry serving the network's region.

An organization legally present in India can investigate IRINN, India's National Internet Registry, or the applicable APNIC route. IRINN states that an applicant cannot simultaneously be an IRINN and APNIC member for the same purpose, so confirm the correct account structure before paying or transferring resources.

Choose upstream space or portable resources

Run a costed design review before applying. Include routers, two physically meaningful upstream paths, cross-connects, transit commits, DDoS strategy, staff, 24-hour escalation, route monitoring, registry fees, and renewal. The registry fee is rarely the largest cost.

Check IPv4 eligibility and scarcity

APNIC's current published criteria say an organization seeking its first LIR IPv4 allocation must have used a /24 from an upstream or demonstrate immediate need for one, comply with policy for previously held space, and show a detailed plan to use a /23 within one year. Small multihoming criteria cover networks already multihomed or preparing to advertise within six months, with documented utilization.

APNIC states that the maximum direct IPv4 delegation from its final pool is generally /23, or 512 addresses. A network needing more must investigate transfers and the applicable recipient policy. Never build a business plan on the assumption that a larger clean IPv4 block will be directly available.

Example IPv4 utilization evidence for a requested /24

Purpose                         Immediate     Month 12
Router, firewall, and services          18           24
Customer or tenant assignments          46          128
Reserved approved deployments           12           36
Operational headroom                     8           20
Total documented use                    84          208

Attach the addressing plan, customer or deployment evidence,
equipment and upstream contracts, and the assumptions behind growth.

Do not manufacture utilization, count the same endpoint twice, or fill a spreadsheet with unsupported forecasts. Policies allow a registry to request evidence and make a smaller delegation. Information later found false or incomplete can invalidate a delegation.

Plan IPv6 as a production service

IPv6 is not merely an extra pool. APNIC members with an IPv4 allocation can automatically qualify for an appropriately sized IPv6 block, commonly a /32 for an allocation; members with an IPv4 assignment can qualify for a /48. Other requests follow the published allocation or portable-assignment criteria.

Do not delay IPv6 until IPv4 is exhausted. Build dual-stack competence while the network can compare both paths and roll back a single service safely.

Prove that you need an ASN

APNIC currently considers an organization eligible when it is multihomed or needs to interconnect with another autonomous system. An organization may also qualify by showing it will meet the criterion after receiving the ASN or within a reasonably short time. IRINN publishes a closely related expectation around a distinct routing policy.

Example routing-policy summary

Prefix family:        approved IPv4 aggregate and approved IPv6 aggregate
Origin:               assigned public ASN
Upstream A:           primary for selected outbound traffic
Upstream B:           diverse failover and selected inbound preference
Advertisements:       exact approved aggregates only
Inbound acceptance:   default routes or bounded, filtered route set
Protection:           RPKI validation, IRR filters, max-prefix, bogon filters
Failure behavior:     withdraw affected path; retain verified alternate path
Change owner:         named network team and rollback authority

Prepare the Indian IRINN KYC package

Use IRINN's current KYC document rather than assembling a generic bundle. The exact acceptable alternative depends on the entity type. Keep scans readable, names consistent, dates current, and authorization explicit.

Acceptable documents and privacy requirements can change. Download the current IRINN KYC list when starting the application. Do not email Aadhaar, PAN, bank statements, signatures, or corporate documents to an unverified consultant or upload them to a lookalike domain.

Build the technical evidence pack

• legal organization name, registration, location, and authorized contacts;
• network diagram showing sites, routers, firewalls, upstreams, IXPs, address boundaries, and failure domains;
• equipment invoices or purchase evidence supporting the planned deployment;
• signed connectivity, transit, cross-connect, or peering agreements;
• current provider-assigned space and utilization;
• immediate, one-year, and where requested two-year address plan;
• customer or service evidence without exposing unnecessary personal data;
• ASN routing policy, neighboring ASNs, activation schedule, and BGP contacts;
• ISP or telecommunications license when applicable;
• abuse handling, security, NOC, change, and renewal owners.

Use one evidence index with file name, owner, date, claim supported, and sensitivity. A reviewer should be able to trace every address count and topology statement back to a real deployment or signed plan.

Review the case like a registry analyst

A resource request is a manual evidence review, not a shopping-cart order. Read the completed package from the reviewer's side before submission. The legal entity, contacts, network diagram, utilization worksheet, contracts, and requested resources must describe the same organization and deployment.

If one document changes, update the dependent diagram, counts, and narrative before replying. Quietly changing a number in one spreadsheet creates ambiguity and another review cycle. When the registry asks a question, answer the numbered question directly, identify the supporting attachment, and state what changed.

Apply through IRINN

1. Read the live IRINN Get Resources, policy, KYC, fee, and affiliation pages.
2. Confirm that IRINN is the correct registry relationship for the organization and that no conflicting APNIC membership exists.
3. Create organization-controlled applicant, corporate, technical, billing, abuse, and recovery contacts.
4. Complete the current affiliation and resource request form with the exact legal name and truthful technical plan.
5. Submit the requested KYC, authorization, signed affiliation agreement, resource justification, and supporting evidence through the verified channel.
6. Answer clarification questions using the same numbered evidence model. Revise forecasts when facts change.
7. Review the approval scope, prefix, ASN, restrictions, invoice, annual obligations, and contacts before payment.
8. After delegation, verify MyIRINN access and immediately begin the registration and routing-security checklist below.

Do not hard-code a promised five-day or ten-day completion into a customer contract. IRINN reviews documents and justification, and requests can take longer when evidence, contacts, payment, or policy eligibility needs clarification. If the official portal temporarily returns a service-unavailable response, wait and contact the IRINN helpdesk through the official domain; do not move KYC documents to a mirror or third-party form.

Apply directly through APNIC when appropriate

1. Confirm that the organization is legally present or operates a network in the APNIC region.
2. Check the current IPv4, IPv6, and ASN eligibility pages.
3. Prepare corporate and secondary-contact photo identification, business registration, employment or director authorization, recent operating-address evidence, and technical need evidence.
4. Use the official APNIC membership application and keep the tracking details in an organization-owned system.
5. Respond to evaluation questions. APNIC currently publishes an average evaluation time of two to five working days, followed by invoicing and typically one working day for activation after cleared payment.
6. Confirm the approved resource set and fee before paying. Application complexity can change the timing.

The application is not finished when the invoice is paid. Assign at least two authorized account contacts, enable MFA, protect recovery methods, and document who can create ROAs, route objects, reverse zones, and resource requests.

Calculate fees from current sources

Fees are time-sensitive and may include taxes, sign-up charges, annual fees, address-holding calculations, transfer charges, discounts, and ASN rules. Use these examples to understand the model, then obtain a written current calculation.

Unsafe: paying a consultant, broker, or copied bank account before the registry has confirmed the organization, request, invoice, and payment route can expose both money and KYC data. Verify the domain, invoice identifier, registry contact, payee, and change-of-bank-details request through a second trusted channel.

Verify the delegation before announcing anything

# Replace examples only with the prefix and ASN actually delegated to you.
whois -h whois.apnic.net AS64500
whois -h whois.apnic.net 203.0.113.0/24

# RDAP provides structured registry data.
curl -sS https://rdap.apnic.net/autnum/64500
curl -sS https://rdap.apnic.net/ip/203.0.113.0/24

# Check reverse DNS after the reverse zone is delegated.
dig +short -x 203.0.113.10
dig +short -x 2001:db8:1200::10

The addresses and ASNs above are documentation examples and must never be announced to the public Internet. Confirm the exact delegated prefix, origin ASN, organization, status, contacts, maintainer, and route authority in the registry account and public records.

Create route objects and RPKI ROAs

An IRR route object states that an ASN is intended to originate a prefix. An RPKI Route Origin Authorization cryptographically authorizes an origin ASN and maximum prefix length. Upstreams may use both, but one does not replace the other.

Create the ROA before the first public announcement, with the exact origin and the narrowest operationally required maximum length. If only a /24 will be originated, authorizing all more-specifics adds risk without benefit. Stage ASN migrations with overlapping valid authorization only for the approved change window.

Build a safe BGP lab configuration

The following FRR-style fragment is a lab pattern using documentation-only prefixes and private ASNs. It accepts only a default route, advertises only exact approved lab prefixes, and caps received routes. Translate it to the installed software release and provider handoff.

ip prefix-list DEFAULT-V4 seq 5 permit 0.0.0.0/0
ip prefix-list OUR-V4 seq 5 permit 203.0.113.0/24
ipv6 prefix-list DEFAULT-V6 seq 5 permit ::/0
ipv6 prefix-list OUR-V6 seq 5 permit 2001:db8:1200::/48

route-map UPSTREAM-IN-V4 permit 10
 match ip address prefix-list DEFAULT-V4
route-map UPSTREAM-OUT-V4 permit 10
 match ip address prefix-list OUR-V4
route-map UPSTREAM-IN-V6 permit 10
 match ipv6 address prefix-list DEFAULT-V6
route-map UPSTREAM-OUT-V6 permit 10
 match ipv6 address prefix-list OUR-V6

router bgp 65010
 bgp router-id 192.0.2.10
 neighbor 192.0.2.1 remote-as 64501
 neighbor 198.51.100.1 remote-as 64502
 neighbor 2001:db8:1::1 remote-as 64501
 neighbor 2001:db8:2::1 remote-as 64502
 !
 address-family ipv4 unicast
  network 203.0.113.0/24
  neighbor 192.0.2.1 route-map UPSTREAM-IN-V4 in
  neighbor 192.0.2.1 route-map UPSTREAM-OUT-V4 out
  neighbor 192.0.2.1 maximum-prefix 5
  neighbor 198.51.100.1 route-map UPSTREAM-IN-V4 in
  neighbor 198.51.100.1 route-map UPSTREAM-OUT-V4 out
  neighbor 198.51.100.1 maximum-prefix 5
 exit-address-family
 !
 address-family ipv6 unicast
  network 2001:db8:1200::/48
  neighbor 2001:db8:1::1 activate
  neighbor 2001:db8:1::1 route-map UPSTREAM-IN-V6 in
  neighbor 2001:db8:1::1 route-map UPSTREAM-OUT-V6 out
  neighbor 2001:db8:1::1 maximum-prefix 5
  neighbor 2001:db8:2::1 activate
  neighbor 2001:db8:2::1 route-map UPSTREAM-IN-V6 in
  neighbor 2001:db8:2::1 route-map UPSTREAM-OUT-V6 out
  neighbor 2001:db8:2::1 maximum-prefix 5
 exit-address-family

Unsafe: pasting this example into a public router can advertise space you do not control, drop valid routes, or disrupt both uplinks. Documentation prefixes and private ASNs are deliberately non-production. Build the final configuration from the actual delegation and signed provider worksheet, validate syntax offline, use console or out-of-band access, save the existing configuration, schedule a rollback owner, and activate one address family and neighbor at a time.

Validate each control plane layer

# FRR operational checks. Exact output varies by installed release.
vtysh -c 'show bgp summary'
vtysh -c 'show bgp ipv4 unicast neighbors'
vtysh -c 'show bgp ipv6 unicast neighbors'
vtysh -c 'show bgp ipv4 unicast'
vtysh -c 'show bgp ipv6 unicast'

# Confirm the local forwarding and addressing state.
ip -br address
ip -4 route show
ip -6 route show
ss -lntup

# External tests must come from networks outside your ASN.
dig A service.example.net @1.1.1.1
dig AAAA service.example.net @1.1.1.1
curl -4 --connect-timeout 10 https://service.example.net/health
curl -6 --connect-timeout 10 https://service.example.net/health

# Compare public registry data with the approved records.
whois -h whois.apnic.net AS64500
whois -h whois.apnic.net 203.0.113.0/24

A BGP Established state proves only that a session is up. Verify received routes, advertised routes, RPKI state, IRR objects, visibility through independent collectors, forward and reverse DNS, IPv4 and IPv6 service health, and traffic on both paths.

Run a controlled production turn-up

1. Freeze the approved prefixes, ASN, contacts, provider worksheets, and rollback conditions.
2. Confirm registry records, route objects, ROAs, reverse zones, and upstream filters.
3. Back up router, firewall, DNS, IPAM, monitoring, and service configuration.
4. Establish one session without advertising the production prefix. Validate received policy and limits.
5. Advertise one approved aggregate through one upstream at low service risk.
6. Check global visibility, RPKI validity, return path, latency, loss, MTU, and service health.
7. Activate the second upstream and verify intended inbound and outbound behavior.
8. Test one controlled failure at a time: session shutdown, circuit failure, router maintenance, and route withdrawal.
9. Enable the IPv6 service path with the same firewall, DNS, monitoring, and rollback discipline.
10. Close the change only after external validation and an observation period.

Troubleshoot common failures

Keep the resources healthy after launch

• review corporate, technical, billing, NOC, and abuse contacts every quarter;
• renew registry affiliation and provider agreements before their deadlines;
• monitor route visibility, origin changes, RPKI validity, hijack alerts, and route leaks;
• reconcile IPAM, Whois assignments, customer records, DNS, and actual utilization;
• rotate registry and router access, require MFA, and review privileged users;
• test both upstream paths and the out-of-band management path;
• update ROAs and route objects before an authorized ASN or prefix change;
• maintain an abuse mailbox, response process, evidence retention policy, and escalation rota;
• return or transfer resources through policy when the qualifying need or organization changes.

Use the right path in four practical scenarios

A small office with one broadband provider

Use provider-assigned addressing unless a specific portable-assignment policy applies. An ASN adds cost and complexity without creating redundancy.

An Indian ISP serving subscribers

Confirm licensing and IRINN affiliation category, prepare customer utilization and assignment policy, design IPv6 from the start, and document two upstream or interconnection relationships. Build Whois, reverse DNS, abuse, RPKI, and renewal ownership before the first customer route.

A hosting company adding a second transit provider

Document current provider space, the portable-prefix need, customer growth, both transit orders, routing policy, DDoS plan, and staged renumbering. Do not announce a new prefix until the ROA, route object, provider filters, DNS, and service tests agree.

An enterprise connecting to an IXP

Confirm that the IXP and peers require or justify an ASN, distinguish peering LAN addresses from public service prefixes, define import and export policy, and limit announcements to authorized aggregates. Keep private interconnection routes out of the public table.

Completion checklist

• The organization chose the correct RIR, NIR, or upstream path.
• IPv4, IPv6, and ASN requests each have current policy evidence.
• Legal identity, address, authorization, billing, and technical documents are complete and protected.
• Utilization numbers trace to a real addressing plan and deployment evidence.
• Two upstreams or interconnections, routing policy, equipment, staff, monitoring, and rollback are documented.
• Current written fees and renewal obligations are approved by the budget owner.
• Whois, IRR, RPKI, reverse DNS, provider filters, and abuse contacts are ready before announcement.
• IPv4 and IPv6 are tested externally, including controlled path failure.
• Quarterly contact, authorization, routing, utilization, and renewal reviews have named owners.

Primary references

• IANA Number Resources and the five-RIR model
• IRINN Get Resources and fee information
• IRINN KYC Documents List
• IRINN affiliation and resource FAQ
• APNIC application process and documentation checklist
• APNIC IPv4 eligibility
• APNIC IPv6 eligibility
• APNIC ASN eligibility
• APNIC IPv4 exhaustion and current delegation limit
• APNIC current fees and examples
• APNIC reverse DNS, route object, and ROA guides
• APNIC Internet Number Resource Policies