How to Get an ASN and Announce Your Own IP Prefix With BGP and RPKI

To announce your own IP prefix, get an AS number and address space from your regional internet registry (ARIN, RIPE NCC or APNIC) directly or through a sponsoring LIR, publish IRR route and as-set objects, create a minimal RPKI ROA with no loose maxLength, then bring up an eBGP session with an upstream that exports only your prefixes and imports through filters. Finish by checking from outside, with RIPEstat and an RPKI validator, that the world sees exactly what you meant to send.

This guide goes one level deeper than our post on building your own internet service and community network. For background on the protocol itself, read BGP explained; for the limits of origin validation, read what RPKI route origin validation does not stop; and for the two failure modes you are trying to avoid, read route leak vs hijack.

All addresses and AS numbers below are documentation values (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, 2001:db8::/32, and AS64496 to AS64511). Replace them with your own before you paste anything into a router.

Key takeaways

• You need your own ASN only when you will have your own routing policy, which in practice means being multihomed to two or more networks or peering at an exchange. A single upstream can usually announce your space from its own ASN.
• The three registries differ. ARIN's policy manual says any organisation may be issued one ASN on request. RIPE NCC policy says a network must be multihomed to qualify. APNIC asks that you are multihomed or need to interconnect with another AS.
• IPv4 is scarce everywhere. ARIN's free pool ran out in September 2015 and it now hands out space from a waiting list capped at a /22. RIPE NCC's waiting list gives a new LIR exactly one /24. Most new networks buy IPv4 on the transfer market and get IPv6 directly.
• Upstreams build their filters from IRR data. No route object and as-set, no accepted announcement.
• RFC 9319 (BCP 185) tells operators to publish minimal ROAs and to avoid maxLength unless every more specific prefix it allows is really announced.
• RFC 8212 makes eBGP default deny without explicit import and export policy. FRR and BIRD both follow it, so a session with no filters will come up and exchange nothing.
• Filter on both sides: export only your own prefixes, import with bogon, length, own space and RPKI invalid checks, plus a prefix limit. Set the RFC 9234 BGP role so the OTC attribute can catch leaks.
• Verify from outside with the RIPEstat looking glass and rpki-validation endpoints, then keep watching.

Timeline of the standards and policies you will meet

The rules in this guide arrived over 25 years. Knowing the dates helps when an older router, tutorial or upstream contract assumes an older world.

When do you need your own ASN and address space?

An autonomous system is, in ARIN's words, a group of IP prefixes run by one or more operators "that maintain a single, clearly-defined routing policy". That definition is the test. If your routing policy is the same as your provider's, you do not need an AS. Your provider can announce a block it assigns to you, or even a block you hold, from its own ASN.

You need your own ASN when:

• You are multihomed. You connect to two or more upstreams and want traffic to fail over between them without renumbering. ARIN's policy manual defines multihomed as receiving full time connectivity from more than one ISP with prefixes announced by at least two of them.
• You peer at an internet exchange. Exchange route servers and bilateral peers talk to ASNs, not to customers of other networks.
• You want provider independence. If your addresses come from a provider (provider aggregatable, or PA, space), changing providers means renumbering. Your own provider independent (PI) space or LIR allocation moves with you.
• You run anycast from several locations and providers.
• You are building a small ISP or community network and will have downstream customers of your own.

You probably do not need one when you have one upstream and no plans to change, when a cloud provider's bring your own IP feature only needs a prefix you can authorise with a ROA, or when private addressing behind NAT is enough.

Decision table: PA space, PI space through a sponsor, or your own LIR

What each regional internet registry requires

Registries write policy in public, through community processes, and the text below comes from each registry's own policy pages as fetched for this guide.

ARIN (North America and parts of the Caribbean)

• ASN. Section 5 of ARIN's Number Resource Policy Manual (NRPM) says "Any organization may be issued a single Autonomous System Number (ASN) upon request." Additional ASNs need proof of a unique routing policy or another technical justification. ARIN's ASN page notes that all ASNs should now be treated as 4 byte numbers.
• IPv6 end user space. NRPM 6.5.8 lists ways to qualify for an initial assignment, including having a previously justified IPv4 end user assignment, "Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number", 2,000 IPv6 addresses or 200 /64 subnets in use within 12 months, 13 active sites, or a technical reason why provider space is unsuitable. The default is a /48, with larger nibble aligned blocks by site count: up to 12 sites gets a /44, up to 192 a /40.
• IPv4. NRPM 4.1.8 says ARIN now issues IPv4 (apart from special pools) only from its waiting list. The maximum an organisation can qualify for at any one time is a /22, you can elect to accept as little as a /24, and you cannot apply if you already hold more than a /20 equivalent. Space from the waiting list cannot be transferred for 60 months except through mergers and acquisitions. ARIN also keeps a dedicated /10 under NRPM 4.10 for IPv6 deployment needs such as dual stack DNS servers and translators, issued as a /24.
• Contract. All new ARIN customers sign a Registration Services Agreement.

RIPE NCC (Europe, the Middle East and parts of Central Asia)

• ASN. RIPE-679 says "A network must be multihomed in order to qualify for an AS Number." You must supply your routing policy, written in RPSL as used in the RIPE Database. The RIPE NCC assigns the ASN to the end user "either directly or through a sponsoring LIR". Since 1 January 2010 the RIPE NCC makes no distinction between 16 bit and 32 bit ASNs.
• Membership or sponsor. The RIPE NCC's AS number page says you need a contractual agreement: "you will either need to become a member or find a sponsoring LIR who will submit the request on your behalf."
• IPv6. RIPE-738 gives LIRs that meet the initial criteria a /32 up to a /29 without extra documentation. IPv6 PI assignments have a minimum size of /48 and cannot be sub-assigned to other organisations.
• IPv4. RIPE-826 puts all allocation requests on a first come, first served waiting list with "No guarantees" about waiting time. Each allocation is exactly one /24, and the total any LIR can receive under that policy is a single /24.

APNIC (Asia Pacific)

• ASN. APNIC's eligibility page says an organisation qualifies if it is currently multihomed or "has the need to interconnect with another AS", or will meet one of those soon after receiving the ASN. Requests are judged against RFC 1930.
• IPv4 for small multihomed networks. You qualify if you are multihomed, are using at least a /24 from an upstream and intend to multihome, or intend to multihome and advertise the prefixes within six months. You must show you can use 25 percent of the requested space immediately and 50 percent within a year.
• IPv6. APNIC's page says members with an IPv4 allocation are eligible for a /32 of IPv6, and members with an IPv4 assignment for a /48.

Side by side

LACNIC and AFRINIC run the other two regions on similar principles. Check their own policy manuals if you operate there; this guide does not cover them.

IPv4 vs IPv6, sponsoring LIRs and transfers, with official fees

IPv6 is the easy half. Every registry above will give a qualifying network enough IPv6 for years of growth, and fees for small holdings are modest. IPv4 is the hard half. The waiting lists are slow and small, so most new networks either accept a /24 when it eventually arrives or buy one on the transfer market. Each registry has a transfer policy with its own fees and holding periods; read it before you sign anything with a broker.

A /24 is the practical minimum. RFC 7454 notes that, as documented by the RIPE community, "IPv4 prefixes longer than /24 and IPv6 prefixes longer than /48 are generally neither announced nor accepted in the Internet." Plan for a /24 and a /48 at least.

ARIN fees (effective 1 January 2026)

ARIN charges one annual Registration Services Plan fee, sized by your largest holding category. Fees are in US dollars, non-refundable and may rise by up to 5 percent a year. ARIN's fee page also says a new fee schedule takes effect on 1 January 2027, so check it before you budget for next year.

ARIN currently has a temporary waiver that lets a 3X-Small organisation hold up to a /36 of IPv6 and stay in 3X-Small. ARIN says it expires on 31 December 2026. Transaction fees include $50 to create an organisation, $500 from the source for each specified transfer, and a recipient transfer processing fee of $187.50 for a /24.

Worked example, ARIN. A new organisation creates its Org ID ($50), receives a /24 by specified transfer (recipient fee $187.50; the seller pays the $500 source fee), and gets one ASN and a /48. Every holding sits in 3X-Small, so the annual fee is $275. First year registry costs: $50 + $187.50 + $275 = $512.50, before the price of the IPv4 block itself, which ARIN does not set.

RIPE NCC fees (2026 and the 2027 scheme)

RIPE-867, the Charging Scheme 2027, published on 11 September 2026, gives both years side by side:

The EUR 75 and EUR 50 charges for sponsored resources are billed to the sponsoring LIR. What the sponsor charges you on top is its own commercial decision.

Worked example, RIPE NCC. Becoming an LIR in early 2027 costs EUR 1,000 sign-up plus EUR 1,894 annual fee, with the first ASN included: EUR 2,894 in year one and EUR 1,894 each year after, at 2027 rates. The sponsored route costs the sponsor EUR 75 for a PI assignment plus EUR 50 for the ASN in 2026 terms, and whatever margin the sponsor adds. An LIR gets an IPv6 allocation of /32 to /29 and can join the IPv4 waiting list for one /24; a PI holder gets a /48 or larger and no waiting list access as an end user.

APNIC fees

APNIC charges a one off sign-up fee of AUD 500 plus an annual membership fee calculated from address holdings. Its own example table for a new member with a /24 of IPv4 and a /48 of IPv6 shows an annual fee of AUD 1,295 in 2026, rising to AUD 1,356 in 2027. For a /24 and a /32 it shows AUD 2,256 in 2026. Each account gets two ASNs free of charge; beyond that, APNIC charges an AUD 500 allocation fee and AUD 100 a year per ASN.

The formula is published too: annual fee = base fee multiplied by the bit factor raised to the number of address bits. For 2026 APNIC lists a member base fee of AUD 1,295 and a bit factor of 1.320.

Worked example, APNIC. A new member with one ASN, a /24 and a /48 pays AUD 500 + AUD 1,295 = AUD 1,795 in year one at 2026 rates, and AUD 1,356 the year after at 2027 rates. The ASN is within the two free ones.

Before you start: what to have ready

Gather these before you open any registry portal. Missing items are the usual reason a request stalls.

1. Legal entity details that match your registration documents exactly.
2. Two upstreams, or one upstream and an exchange, with letters of intent or contracts if your registry asks for multihoming evidence.
3. A routing policy in a sentence or two: who you import from, what you export to whom. RIPE NCC wants it in RPSL.
4. An addressing plan: which /24 or /48 goes where, and which prefixes you will actually announce.
5. Role contacts: an admin, a technical and an abuse contact with a mailbox someone reads. MANRS asks that operational queries get a reply within 72 hours.
6. A router that runs a current, supported BGP daemon (BIRD or FRRouting in this guide), with enough memory for the table you plan to take.
7. An RPKI relying party (validator) you can run on the router or next to it, speaking the RPKI to Router protocol.

Step 1: request the ASN and address space

The portals differ but the flow is the same everywhere:

1. Create your organisation record (ARIN Org ID, RIPE NCC organisation object via your LIR or sponsor, APNIC member account).
2. Request the ASN with your multihoming evidence and routing policy.
3. Request IPv6 in the same session; it is rarely refused for a qualifying network.
4. Request or transfer IPv4. Join the waiting list if your registry has one, and in parallel arrange a transfer if you need space this year.
5. Pay and sign. ARIN invoices the RSP fee when the first request is approved. RIPE NCC and APNIC invoice on membership or through your sponsor.
6. Set up maintainers and two factor authentication on your registry account before you create any routing objects. Whoever controls this account controls your ROAs.

When the ASN arrives, confirm it in whois:

# Replace with your real ASN and prefix
whois AS64500
whois 203.0.113.0
whois 2001:db8:1000::

Step 2: create IRR objects (aut-num, route, route6, as-set)

Internet Routing Registries hold Routing Policy Specification Language (RPSL) objects that describe who may originate what. ARIN's IRR page explains that ISPs use registry data to build access lists that permit or deny routes. MANRS Action 4 asks every operator to "publicly document their intended routing announcements" and to maintain at least one as-set that "can be used by automatic tools to generate prefix filters".

That last point is why IRR matters for a new AS. Your upstream will most likely build its import filter for your session by expanding your as-set into ASNs, looking up every route and route6 object whose origin is one of those ASNs, and turning the result into a prefix list. If your route object is missing, your announcement is dropped at the first hop, quietly.

Register objects in the IRR run by your registry. Third party IRRs accept objects with weaker checks, which is why ARIN describes its authenticated IRR as reducing risk where "IRR route objects can be created in third-party IRR databases".

Example objects in the RIPE Database format

aut-num:     AS64500
as-name:     EXAMPLE-NET
descr:       Example Net, two upstreams
import:      from AS64496 accept ANY
import:      from AS64511 accept ANY
export:      to AS64496 announce AS64500:AS-EXAMPLE
export:      to AS64511 announce AS64500:AS-EXAMPLE
admin-c:     EXA1-RIPE
tech-c:      EXA1-RIPE
mnt-by:      EXAMPLE-MNT
source:      RIPE

as-set:      AS64500:AS-EXAMPLE
descr:       Everything AS64500 announces to upstreams
members:     AS64500
admin-c:     EXA1-RIPE
tech-c:      EXA1-RIPE
mnt-by:      EXAMPLE-MNT
source:      RIPE

route:       203.0.113.0/24
descr:       Example Net IPv4
origin:      AS64500
mnt-by:      EXAMPLE-MNT
source:      RIPE

route6:      2001:db8:1000::/48
descr:       Example Net IPv6
origin:      AS64500
mnt-by:      EXAMPLE-MNT
source:      RIPE

Notes on these objects:

• The RIPE Database documentation lists route: and origin: as mandatory primary keys of a route object, with mnt-by: and source: also mandatory.
• In the RIPE Database the mnt-by: of an aut-num can authorise creation of route objects originated by that AS when no mnt-routes: is set. Understand which maintainer can create what before you hand credentials to a contractor.
• Use a hierarchical as-set name (AS64500:AS-EXAMPLE). It is tied to your ASN, so nobody else can register it.
• Only list ASNs you actually provide transit for. A stub network's as-set contains only its own ASN.

Using ARIN's IRR and the IRR Auto-Manager

ARIN's IRR is part of ARIN Online, with a web interface and a REST API. When you create ROAs in ARIN Online, the IRR Auto-Manager, on by default for each Org ID, creates a matching route object for each origin and prefix pair. ARIN notes that auto-managed route objects "will not consider the maxLength value and use the prefix entry only", citing RFC 9319. You can still create more specific objects by hand.

Check what your upstream will see

bgpq4 is an open source tool that expands an as-set from an IRR server into prefix lists. Run it yourself against your own as-set to see what an upstream's automation will produce:

# IPv4 prefix list for your as-set, in BIRD format, named AS64500_V4
bgpq4 -h whois.radb.net -b -l AS64500_V4 AS64500:AS-EXAMPLE

# IPv6, aggregated where possible
bgpq4 -h whois.radb.net -6 -A -l AS64500_V6 AS64500:AS-EXAMPLE

# JSON, handy for diffing in CI
bgpq4 -h whois.radb.net -j -l AS64500_V4 AS64500:AS-EXAMPLE

The bgpq4 README documents -b for BIRD output, -6 for IPv6, -A to aggregate, -j for JSON, -l to name the list and -h to choose the IRR server. If the output is empty, fix the registry before you call your upstream.

Step 3: create RPKI ROAs, and what maxLength should be

A Route Origin Authorisation is a signed statement that an AS may originate a prefix. ARIN describes it as "a cryptographically signed object that states which Autonomous System Number (ASN) is authorized to originate a particular IP address prefix or set of prefixes". Routers that do origin validation, per RFC 6811, sort every route into three states:

RIPEstat splits Invalid into two reasons that are useful when debugging: invalid_asn (a covering ROA exists for a different ASN) and invalid_length (the announcement is longer than the ROA's maximum length).

Creating ROAs in each portal

• ARIN: in ARIN Online, open Routing Security, then Manage RPKI for your Org ID, and create a ROA with an origin AS, a prefix and a max length. ARIN keeps a 365 day change log of new and modified ROAs and no longer allows duplicate or overlapping ROAs, since ROAs now renew automatically.
• RIPE NCC: log in to the RPKI dashboard with a RIPE NCC Access account tied to your LIR, create a hosted CA if you have not, and add ROA configurations. The dashboard also has alert configuration. PI and legacy holders follow a separate getting started guide. RIPE notes that the origin AS on a ROA "does not need to be held by that CA", which is how you authorise a provider to originate your space.
• APNIC: ROAs are managed in MyAPNIC with the hosted RPKI service.

Hosted RPKI means the registry runs the certificate authority and holds the keys. Delegated RPKI means you run your own CA software and publication point. For a new single site network, hosted is simpler and has fewer ways to fail.

What maxLength should be

RFC 9319 is direct: "Operators SHOULD use minimal ROAs whenever possible", and "In general, operators SHOULD avoid using the maxLength attribute in their ROAs". A minimal ROA lists only the prefixes the AS actually originates. The reason is forged origin hijacks: if your ROA for a /22 allows maxLength 24, an attacker who prepends your ASN to a path can announce one of your /24s and it will validate, and the more specific route wins on longest match everywhere.

The exception RFC 9319 allows is when every more specific prefix that maxLength permits is actually announced by the AS.

Worked example 1: one /24, one origin. You hold 203.0.113.0/24 and announce it as a /24. Create one ROA: prefix 203.0.113.0/24, origin AS64500, max length 24. Nothing more specific will validate.

Worked example 2: a /22 split for traffic engineering. You hold 198.51.100.0/22 (imagine it is real) and announce the /22 from both upstreams, plus 198.51.100.0/24 only via upstream A. Do not create one ROA with max length 24; that would make all four /24s valid, three of which you never announce. Create two entries: the /22 with max length 22 and the single /24 with max length 24. If you later announce all four /24s, a single /22 max length 24 entry becomes minimal and acceptable.

Worked example 3: IPv6 /48 with a /44 holding. You hold 2001:db8:1000::/44 and announce two /48s, 2001:db8:1000::/48 and 2001:db8:1001::/48. A /44 ROA with max length 48 would authorise 16 /48s, and you announce two. Create two ROAs, one per /48, each with max length 48. That keeps 14 /48s unannounceable by anyone who spoofs your origin.

Worked example 4: an on demand mitigation provider. If a scrubbing service originates your /24 from its own ASN during an attack, create a separate ROA for that /24 with the provider's ASN as origin, max length 24. Do not widen your own ROA. RFC 9319 gives the same pattern: one ROA per originating AS.

Create ROAs before your first announcement. If a ROA for another AS already covers your prefix (common with transferred space whose old holder still has one), your announcement will be Invalid from the start. Check with RIPEstat, shown in Step 6, and ask the registry or previous holder to remove stale ROAs.

Step 4: set up the BGP session on BIRD or FRRouting

Agree these with your upstream in writing: their ASN, both sides' session addresses, which address families, whether you want a full table, a default route or both, the authentication method, the maximum number of prefixes each side will send, and the communities they support. Tell them your as-set name so their filter is built from it.

RFC 7454 lists what both sides should filter. On your side, as a leaf network:

• Outbound: announce only your own prefixes. Never re-announce what you learned from one upstream to another; that is the classic route leak.
• Inbound: reject non routable prefixes (bogons), routes that are too specific (longer than /24 or /48), your own prefixes coming back at you, and the default route unless you asked for it.
• Maximum prefixes: from an upstream that sends a full table, RFC 7454 recommends a limit higher than the number of routes in the internet, to protect router memory. From a peer, a limit lower than the full table so the session drops if they leak everything at you.
• Session protection: RFC 7454 recommends TCP-AO over TCP MD5 where your equipment supports it, and GTSM (TTL security) for directly connected sessions.

RFC 8212 means none of this is optional. A BGP speaker following it will not consider routes from an eBGP peer "if no explicit Import Policy has been applied", and will not send routes without an explicit export policy.

Running an RPKI validator

Both daemons fetch validated ROA payloads from a relying party over the RPKI to Router (RTR) protocol, which FRR's documentation says is defined in RFC 6810. Run an open source relying party on the router host or a nearby server, ideally two for redundancy, and point the daemon at it. The examples use 127.0.0.1 port 3323 as an example address; use whatever your validator listens on.

BIRD 2 configuration

The BIRD 2 user's guide (version 2.16.1 at the time of writing) documents everything used here. Its BGP section notes that "Due to RFC 8212, external BGP protocol requires explicit configuration of import and export policies", so you must write filters.

# /etc/bird/bird.conf  (BIRD 2)
log syslog all;
router id 198.51.100.2;

define OUR_ASN      = 64500;
define UPSTREAM_ASN = 64496;

# Prefixes we originate, exact match only
define OUR_V4 = [ 203.0.113.0/24 ];
define OUR_V6 = [ 2001:db8:1000::/48 ];

# Our space and anything inside it, for inbound rejection
define OUR_V4_ALL = [ 203.0.113.0/24+ ];
define OUR_V6_ALL = [ 2001:db8:1000::/48+ ];

# Bogons. In production also add 192.0.2.0/24+, 198.51.100.0/24+,
# 203.0.113.0/24+ and 2001:db8::/32+ ; they are left out here only
# because this example uses them.
define BOGONS_V4 = [ 0.0.0.0/8+, 10.0.0.0/8+, 100.64.0.0/10+,
                     127.0.0.0/8+, 169.254.0.0/16+, 172.16.0.0/12+,
                     192.168.0.0/16+, 198.18.0.0/15+, 224.0.0.0/4+,
                     240.0.0.0/4+ ];
define BOGONS_V6 = [ ::/8+, fc00::/7+, fe80::/10+, ff00::/8+ ];

roa4 table r4;
roa6 table r6;

protocol device { }

protocol rpki validator1 {
  roa4 { table r4; };
  roa6 { table r6; };
  remote 127.0.0.1 port 3323;   # your validator's RTR address
  retry keep 90;
  refresh keep 900;
  expire keep 7200;
}

# Originate our prefixes from static routes that never forward
protocol static static_v4 {
  ipv4;
  route 203.0.113.0/24 blackhole;
}
protocol static static_v6 {
  ipv6;
  route 2001:db8:1000::/48 blackhole;
}

filter upstream_in_v4 {
  if net.len > 24 then reject;
  if net ~ BOGONS_V4 then reject;
  if net ~ OUR_V4_ALL then reject;
  if bgp_path.first != UPSTREAM_ASN then reject;
  if roa_check(r4, net, bgp_path.last) = ROA_INVALID then reject;
  accept;
}

filter upstream_in_v6 {
  if net.len > 48 then reject;
  if net ~ BOGONS_V6 then reject;
  if net ~ OUR_V6_ALL then reject;
  if bgp_path.first != UPSTREAM_ASN then reject;
  if roa_check(r6, net, bgp_path.last) = ROA_INVALID then reject;
  accept;
}

filter upstream_out_v4 {
  if (net ~ OUR_V4) && (source = RTS_STATIC) then accept;
  reject;
}

filter upstream_out_v6 {
  if (net ~ OUR_V6) && (source = RTS_STATIC) then accept;
  reject;
}

protocol bgp upstream1_v4 {
  description "Upstream 1 IPv4";
  local 198.51.100.2 as OUR_ASN;
  neighbor 198.51.100.1 as UPSTREAM_ASN;
  local role customer;          # RFC 9234
  password "agreed-with-upstream";
  ipv4 {
    import filter upstream_in_v4;
    export filter upstream_out_v4;
    receive limit 2000000 action warn;  # set from your upstream's guidance
  };
}

protocol bgp upstream1_v6 {
  description "Upstream 1 IPv6";
  local 2001:db8:ffff::2 as OUR_ASN;
  neighbor 2001:db8:ffff::1 as UPSTREAM_ASN;
  local role customer;
  password "agreed-with-upstream";
  ipv6 {
    import filter upstream_in_v6;
    export filter upstream_out_v6;
    receive limit 500000 action warn;
  };
}

What each piece does, according to BIRD's documentation:

• roa_check(table, net, bgp_path.last) returns ROA_UNKNOWN, ROA_VALID or ROA_INVALID. BIRD says a result is invalid "if there is either matching ROA with a different ASN, or any covering ROA with shorter maximal prefix length". The three argument form is equivalent to the short form roa_check(r4), which BIRD says is faster.
• protocol rpki loads ROAs from the cache into the roa4 and roa6 tables. The documented example uses retry keep, refresh keep and expire timers; BIRD's own example warns not to use its public test validator in production.
• local role customer turns on RFC 9234 roles. BIRD lists the role names provider, rs_server, rs_client, customer and peer, and says filtering is done "with the help of the OTC attribute". Add require roles if your upstream supports roles and you want the session to refuse to start without them.
• receive limit and import limit take action warn, block, restart or disable. BIRD notes the receive limit protects routing tables from overflow. Start with warn, watch the logs, then decide.
• The numbers in receive limit above are placeholders. Set them from your upstream's guidance and your router's memory, and review them as the table grows, as RFC 7454 advises.

Apply and inspect:

sudo birdc configure check
sudo birdc configure
sudo birdc show protocols all upstream1_v4
sudo birdc show route export upstream1_v4     # must list only 203.0.113.0/24
sudo birdc show route export upstream1_v6     # must list only 2001:db8:1000::/48
sudo birdc show route table r4 count          # ROAs loaded from the validator

FRRouting configuration

FRR's documentation says bgp ebgp-requires-policy is "enabled by default for the traditional configuration" and that "Without the incoming filter, no routes will be accepted. Without the outgoing filter, no routes will be announced." RPKI needs the frr-rpki-rtrlib package and the -M rpki module option in /etc/frr/daemons.

# /etc/frr/daemons (excerpt)
bgpd=yes
bgpd_options="   -A 127.0.0.1 -M rpki"

! /etc/frr/frr.conf
frr defaults traditional
hostname edge1
!
ip prefix-list OUR-V4 seq 10 permit 203.0.113.0/24
ipv6 prefix-list OUR-V6 seq 10 permit 2001:db8:1000::/48
!
! Inbound IPv4: bogons, our own space, too specific, then the rest
ip prefix-list UP-IN-V4 seq 5   deny 0.0.0.0/8 le 32
ip prefix-list UP-IN-V4 seq 10  deny 10.0.0.0/8 le 32
ip prefix-list UP-IN-V4 seq 15  deny 100.64.0.0/10 le 32
ip prefix-list UP-IN-V4 seq 20  deny 127.0.0.0/8 le 32
ip prefix-list UP-IN-V4 seq 25  deny 169.254.0.0/16 le 32
ip prefix-list UP-IN-V4 seq 30  deny 172.16.0.0/12 le 32
ip prefix-list UP-IN-V4 seq 35  deny 192.168.0.0/16 le 32
ip prefix-list UP-IN-V4 seq 40  deny 198.18.0.0/15 le 32
ip prefix-list UP-IN-V4 seq 45  deny 224.0.0.0/3 le 32
ip prefix-list UP-IN-V4 seq 80  deny 203.0.113.0/24 le 32
ip prefix-list UP-IN-V4 seq 90  deny 0.0.0.0/0 ge 25
ip prefix-list UP-IN-V4 seq 100 permit 0.0.0.0/0 le 24
!
ipv6 prefix-list UP-IN-V6 seq 5   deny fc00::/7 le 128
ipv6 prefix-list UP-IN-V6 seq 10  deny fe80::/10 le 128
ipv6 prefix-list UP-IN-V6 seq 15  deny ff00::/8 le 128
ipv6 prefix-list UP-IN-V6 seq 80  deny 2001:db8:1000::/48 le 128
ipv6 prefix-list UP-IN-V6 seq 90  deny ::/0 ge 49
ipv6 prefix-list UP-IN-V6 seq 100 permit 2000::/3 le 48
!
route-map UP-IN-V4 deny 10
 match rpki invalid
route-map UP-IN-V4 permit 20
 match ip address prefix-list UP-IN-V4
!
route-map UP-IN-V6 deny 10
 match rpki invalid
route-map UP-IN-V6 permit 20
 match ipv6 address prefix-list UP-IN-V6
!
route-map UP-OUT-V4 permit 10
 match ip address prefix-list OUR-V4
route-map UP-OUT-V6 permit 10
 match ipv6 address prefix-list OUR-V6
!
rpki
 rpki polling_period 300
 rpki cache tcp 127.0.0.1 3323 preference 1
exit
!
ip route 203.0.113.0/24 blackhole
ipv6 route 2001:db8:1000::/48 blackhole
!
router bgp 64500
 bgp router-id 198.51.100.2
 no bgp default ipv4-unicast
 neighbor 198.51.100.1 remote-as 64496
 neighbor 198.51.100.1 description upstream1-v4
 neighbor 198.51.100.1 local-role customer
 neighbor 198.51.100.1 password agreed-with-upstream
 neighbor 2001:db8:ffff::1 remote-as 64496
 neighbor 2001:db8:ffff::1 description upstream1-v6
 neighbor 2001:db8:ffff::1 local-role customer
 neighbor 2001:db8:ffff::1 password agreed-with-upstream
 !
 address-family ipv4 unicast
  network 203.0.113.0/24
  neighbor 198.51.100.1 activate
  neighbor 198.51.100.1 route-map UP-IN-V4 in
  neighbor 198.51.100.1 route-map UP-OUT-V4 out
  neighbor 198.51.100.1 maximum-prefix 2000000
 exit-address-family
 !
 address-family ipv6 unicast
  network 2001:db8:1000::/48
  neighbor 2001:db8:ffff::1 activate
  neighbor 2001:db8:ffff::1 route-map UP-IN-V6 in
  neighbor 2001:db8:ffff::1 route-map UP-OUT-V6 out
  neighbor 2001:db8:ffff::1 maximum-prefix 500000
 exit-address-family
exit

Points from FRR's documentation worth knowing:

• "By default, enabling RPKI does not change best path selection. In particular, invalid prefixes will still be considered". You must drop invalids yourself, which the match rpki invalid deny clause does.
• If no RPKI cache can be reached after a timeout, FRR processes routes without origin validation and keeps retrying. neighbor PEER rpki strict holds the BGP session down until the cache is connected, if you prefer failing closed.
• The polling_period default is 300 seconds and the expire interval default 7200 seconds.
• neighbor PEER local-role takes provider, rs-server, rs-client, customer or peer. Correct pairs are provider with customer, peer with peer, and route server with route server client. A mismatch sends an OPEN Roles Mismatch notification. FRR marks routes from a provider, route server or peer with OTC, and "Routes with this attribute can only be sent to your neighbor if your local-role is provider or rs-server".
• FRR documents neighbor PEER maximum-prefix NUMBER as tearing the session down when exceeded, and says a prefix list is "generally preferable" for policy. Keep both: the prefix list for policy, the limit as a circuit breaker set well above what the upstream should send. Some FRR versions also offer a threshold or warning only form; check your version's reference before relying on it.
• Older FRR releases used a slightly different rpki cache syntax. Match the commands to the documentation for the version you install.

Apply and inspect:

sudo systemctl restart frr
sudo vtysh -c 'show bgp summary'
sudo vtysh -c 'show bgp ipv4 unicast neighbors 198.51.100.1 advertised-routes'
sudo vtysh -c 'show bgp ipv6 unicast neighbors 2001:db8:ffff::1 advertised-routes'
sudo vtysh -c 'show rpki cache-server'
sudo vtysh -c 'show bgp neighbor 198.51.100.1' | grep -i role

The advertised routes output must show your prefixes and nothing else. If it shows anything you learned from the upstream, stop and fix the export policy before you add a second upstream.

Adding the second upstream

Copy the session with the second provider's ASN and addresses, and keep the export filter identical. The most common way a new multihomed AS causes a route leak is by exporting routes learned from upstream A to upstream B. With exact match export filters, that cannot happen by accident. In BIRD the source = RTS_STATIC condition adds a second guard; in FRR the export prefix list does the same job.

BIRD and FRR at a glance

BIRD documents ASPA checks against what it calls the "(draft)" ASPA specification. ASPA validates the AS path, not just the origin, and is worth watching, but treat it as optional and evolving until it is published as a standard.

Step 5: source address validation (BCP 38) on your edge

RPKI and prefix filters protect the control plane. BCP 38 (RFC 2827, May 2000) protects the data plane: do not let packets leave your network with source addresses you do not own. NIST SP 800-189 recommends source address validation with access lists and unicast reverse path forwarding as part of DDoS mitigation.

On a Linux router running BIRD or FRR, a simple egress rule on the upstream facing interface does most of the work:

# nftables: drop traffic to upstreams whose source is not ours
sudo nft add table inet edge
sudo nft add chain inet edge egress '{ type filter hook forward priority 0; policy accept; }'
sudo nft add rule inet edge egress oifname "upstream1" ip saddr != 203.0.113.0/24 drop
sudo nft add rule inet edge egress oifname "upstream1" ip6 saddr != 2001:db8:1000::/48 drop

# Reverse path filtering on the customer facing side (strict mode = 1)
sudo sysctl -w net.ipv4.conf.customers.rp_filter=1

Strict reverse path filtering breaks asymmetric routing, so use it on single homed customer and access interfaces, not on the multihomed upstream side. MANRS points operators to the CAIDA Spoofer software to test whether your network can still send forged source packets.

Step 6: verify your announcement from outside

Your router saying it sent a route proves little. Check what other networks received.

RIPEstat looking glass and RPKI validation

RIPEstat's looking glass endpoint returns, for each RIPE NCC route collector, the BGP peers that see a prefix and their paths. Its rpki-validation endpoint returns the validity of a prefix and origin pair, looked up against the Routinator validator according to RIPEstat's documentation.

# Who sees the prefix, and with what AS path?
curl -s "https://stat.ripe.net/data/looking-glass/data.json?resource=203.0.113.0/24" \
  | jq '.data.rrcs[] | {rrc, location, peers: [.peers[].as_path] | unique}'

# Is our announcement RPKI valid?
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=64500&prefix=203.0.113.0/24" \
  | jq '.data.status'

The status should be valid. If it is invalid_asn, a ROA for another origin covers your prefix. If it is invalid_length, you are announcing something longer than your ROA allows. If it is unknown, your ROA has not been published yet or has not reached validators.

Check the IRR from outside too

# Route objects registered with your ASN as origin, RIPE Database
whois -h whois.ripe.net -i origin AS64500

# What your as-set expands to, as an upstream's tooling will see it
bgpq4 -h whois.radb.net -l CHECK AS64500:AS-EXAMPLE

Other checks

• Public looking glasses run by your upstreams and by exchanges show what they hold in their tables. Use two or three in different regions.
• Traceroute from outside to an address inside your prefix, using a measurement network or a friend's server, confirms traffic actually arrives.
• Your own validator's API or logs should show your ROA as a validated ROA payload.
• Monitoring. Subscribe to the registry's RPKI alerts (the RIPE NCC dashboard has alert configuration) and to a BGP monitoring service that warns when your prefix appears with an unexpected origin or path.

MANRS actions and what they ask of a new network

MANRS, Mutually Agreed Norms for Routing Security, publishes a short list of actions for network operators. The program page groups them as:

The detailed actions document on manrs.org, as fetched for this guide, marks Filtering, Coordination and Global Information as compulsory and Anti-spoofing as recommended, and says Action 4 can be met with IRR or with RPKI. Check the current program requirements on manrs.org before you apply, since the program has been revised over time. Action 3 asks for a NOC contact that replies within 72 hours and recommends a dedicated abuse contact.

Common mistakes

• Announcing before the ROA exists, or with an old ROA in place. Transferred space often carries a stale ROA from the previous holder. Your first announcement is then Invalid and dropped by validating networks.
• A loose maxLength. A /22 with max length 24 makes three unannounced /24s valid for anyone who forges your origin. Publish minimal ROAs, as RFC 9319 says.
• No route object, or one in the wrong IRR. Your upstream's filter is built from IRR data. If the object is missing, or only exists in a registry they do not use, your prefix will not pass.
• An as-set that lists ASNs you do not serve. It widens every upstream's filter for you and makes leaks easier.
• Re-exporting upstream routes. Exporting with a policy like "accept all" or a filter that matches by community alone sends one upstream's routes to the other. This is a route leak.
• No inbound filter on a full table. A leak or hijack elsewhere lands in your table and your traffic follows it.
• Disabling RFC 8212 behaviour to make the session work. If the session shows no prefixes, write the policy; do not switch the safety off.
• Accepting your own prefixes from outside. If someone else announces a more specific of your space and you accept it, your own traffic can be drawn away.
• Prefix limits that tear the session down at the wrong moment. Set limits from the upstream's real numbers and review them; start in warning mode.
• Single validator, no monitoring. If the only validator dies, FRR falls back to processing without validation, and BIRD keeps the last data until it expires. Run two, and alert on stale data.
• Registry account without two factor authentication. The person who can log in can delete your ROAs and route objects.
• Forgetting reverse DNS and abuse contacts. Not a routing failure, but networks that cannot reach you will filter you instead.

FAQ

Do I need my own ASN to use my own IP addresses?

No. An upstream can announce your PI space or allocation from its own ASN, provided your ROA names its ASN as origin. You need your own ASN when you have a routing policy of your own, which in practice means multihoming or peering at an exchange.

How much does it cost to get an ASN?

At ARIN, an organisation holding one to three ASNs, up to a /24 and up to a /40 pays the 3X-Small fee of $275 a year (fees effective 1 January 2026), plus $50 to create the organisation. At the RIPE NCC, the 2027 scheme includes the first ASN in the EUR 1,894 LIR fee, and a new LIR also pays a EUR 1,000 sign-up fee; sponsored ASNs cost the sponsor EUR 50 a year. At APNIC, two ASNs are free with membership, which costs AUD 500 to join plus an annual fee based on address holdings.

Can I get IPv4 addresses directly from a registry in 2026?

Only slowly. ARIN serves new IPv4 from a waiting list, at most a /22 per organisation, with a 60 month transfer lock. The RIPE NCC gives each LIR one /24 from its waiting list with no guaranteed wait. Many new networks buy a /24 on the transfer market and use each registry's transfer process.

What is the smallest prefix I can announce on the internet?

A /24 for IPv4 and a /48 for IPv6. RFC 7454 records that longer prefixes are generally neither announced nor accepted. Anything smaller will be filtered by most networks.

What should maxLength be in my ROA?

Equal to the prefix length in almost every case. RFC 9319 says operators should use minimal ROAs and avoid maxLength unless every more specific prefix it allows is actually announced by that AS.

What is the difference between an IRR route object and an RPKI ROA?

A route object is a database record in RPSL that upstreams use to build prefix filters. A ROA is a cryptographically signed object that routers use for origin validation. You need both today: upstreams build filters from IRR, and validating networks drop RPKI invalids.

Why does my BGP session come up but send and receive no routes?

Because of RFC 8212. BIRD requires explicit import and export policy on eBGP, and FRR's bgp ebgp-requires-policy is on by default with traditional defaults. Add filters and the routes will flow.

Is BIRD or FRRouting better for a small AS?

Both are mature open source BGP daemons that implement RFC 8212, RPKI validation and RFC 9234 roles. BIRD expresses policy in its own filter language; FRR uses prefix lists and route maps in a familiar command line style. Pick the one your team can read and review confidently.

What is a sponsoring LIR?

In the RIPE NCC region, an end user who is not a member can get an ASN and PI space through an existing LIR that holds the contract and submits requests on their behalf. The RIPE NCC charges the sponsor per resource, and the sponsor sets its own price to you.

Does RPKI stop all BGP hijacks?

No. Origin validation checks only the origin AS. A forged path that ends in your ASN still validates, which is why minimal ROAs matter, and route leaks with a correct origin pass too. RFC 9234 roles and ASPA address parts of that gap. Our post on what RPKI route origin validation does not stop goes deeper.

Where Safeguard fits, and where it does not

Safeguard does not request ASNs, manage ROAs or IRR objects, configure routers, monitor BGP or validate RPKI. Everything above is done in your registry portal, your BGP daemon and your validator. The honest link is the software. BIRD, FRRouting, RPKI relying parties, bgpq4, the Linux kernel and the scripts that generate your prefix lists are open source components with their own vulnerabilities and fixed versions. If you keep router configs, filter generation scripts or container images for your validator in a repository, Safeguard can scan that repository, the image or its SBOM, show which projects carry a given component version and match versions against vulnerability data. It cannot tell you what your router has announced.

A network edge is also a software supply chain: the daemon that speaks BGP, the validator that feeds it ROAs and the automation that writes its filters are all built from open source dependencies that get rebuilt and redeployed. The fit with routing itself is indirect, but keeping those components on fixed versions is part of running an AS safely.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos touch BGP, ROAs or registry objects. They show the software side of running an AS: the repositories and images behind your router, validator and filter automation.

This is a real Safeguard CLI session: install, open the interactive terminal, ask it to fix a lodash CVE, and approve each command as it edits package.json and runs npm install and npm test, with nothing pushed. If your prefix list generator or looking glass dashboard lives in a repository, the same flow is how you would find and fix a vulnerable dependency in it, approving every command yourself.

Click through it at your own pace, or open it full screen.

This demo sets up the Safeguard runner on your own machine, approves it with a device code, and runs a scan from the terminal. On a management host next to your edge routers, the same runner can scan the repository that holds your BIRD or FRR configs and automation, or an SBOM of the validator image you deploy.

Click through it at your own pace, or open it full screen.

Here Claude connects to the Safeguard MCP server with OAuth, and you choose which Safeguard tools Claude may use. That helps when you want to ask, in plain language, which of your projects carry a given version of a routing daemon or library, while keeping the assistant's access limited to the tools you picked.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard or read the CLI documentation.

Quick check

Sources

• Autonomous System Numbers, ARIN
• Number Resource Policy Manual, ARIN
• Fee Schedule, ARIN
• IPv4 Waiting List, ARIN
• Internet Routing Registry (IRR), ARIN
• Route Origin Authorizations (ROAs), ARIN
• Request an AS Number, RIPE NCC
• RIPE-679, Autonomous System (AS) Number Assignment Policies
• RIPE-738, IPv6 Address Allocation and Assignment Policy
• RIPE-826, IPv4 Address Allocation and Assignment Policies
• RIPE-867, RIPE NCC Charging Scheme 2027
• Using the Hosted Certification Authority, RIPE NCC
• Descriptions of Primary Objects, RIPE Database documentation
• Get IP addresses and ASN, APNIC
• How much does it cost?, APNIC
• RFC 2827, Network Ingress Filtering (BCP 38)
• RFC 4271, A Border Gateway Protocol 4 (BGP-4)
• RFC 6480, An Infrastructure to Support Secure Internet Routing
• RFC 6811, BGP Prefix Origin Validation
• RFC 7454, BGP Operations and Security (BCP 194)
• RFC 8212, Default External BGP Route Propagation Behavior without Policies
• RFC 9234, Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages
• RFC 9319, The Use of maxLength in the RPKI (BCP 185)
• BIRD 2 User's Guide: Protocols
• BIRD 2 User's Guide: Filters
• BIRD 2 User's Guide: Configuration, channel limits
• BGP, FRRouting documentation
• bgpq4 README, bgp/bgpq4 on GitHub
• rpki-validation endpoint, RIPEstat Data API
• looking-glass endpoint, RIPEstat Data API
• Network Operators program, MANRS
• MANRS Network Operators Actions
• NIST SP 800-189, Resilient Interdomain Traffic Exchange: BGP Security and DDoS Mitigation

Last reviewed: 23 October 2026. Registry fees and policies change every year; check your registry's current fee schedule and policy manual before you apply.