RIPE NCC resources end to end: ASN, PI/PA space, route objects, ROA and RPKI

Getting an ASN is the easy part. What decides whether your prefix is reachable is a chain of database objects and cryptographic attestations, most of which are maintained by hand and almost all of which fail silently. This walks the chain end to end, in the order you actually build it.

The group's own resources are the concrete example throughout: AS203136 announces 185.143.176.0/22, covered by a valid ROA with maxLength /22, multi-homed to three upstreams.

The chain, end to end#

1. LIR membership with RIPE NCC, or a sponsoring LIR if you only need PI resources.
2. Number resources — an ASN, IPv4 and IPv6 space.
3. RIPE Database objects — aut-num, inetnum/inet6num, route/route6, as-set, all protected by an mntner.
4. IRR filters — your upstreams build prefix filters from those objects. If the object is missing, the prefix is dropped before BGP policy ever sees it.
5. RPKI — a ROA cryptographically binds prefix to origin ASN. Networks doing Route Origin Validation drop what contradicts it.
6. Route Origin Validation on your own routers — so you are protected too, not just protecting others.

Every link is independently capable of taking you off the internet.

ASN and address space#

An ASN request needs a routing policy: which networks you will peer with, and evidence that you are (or will be) multi-homed. A single-homed network does not need an ASN and will be told so.

Address space splits into two kinds, and the distinction matters more than people expect:

• PA (Provider Aggregatable) is allocated to an LIR. The LIR assigns sub-blocks to customers, and those assignments return when the customer leaves. This is what an ISP normally holds.
• PI (Provider Independent) is assigned to an end user and stays with them across provider changes. It requires a sponsoring LIR to maintain the relationship, and it carries stricter rules on what it may be used for and how it may be transferred.

IPv4 is effectively exhausted at the RIR level; new allocations come from a recovered-address pool under a waiting-list policy, and they are small. Plan on IPv6 as the growth path and IPv4 as a scarce resource to be conserved — this is not idealism, it is what the allocation policy makes practically true. Read the current policy text before assuming anything about sizes or timelines; it changes.

The database objects that gate your routing#

mntner#

Everything else is protected by a maintainer object. Its authentication is what stops a third party editing your records — and its neglect is why abandoned objects persist for years. Use strong authentication and make sure more than one person in the organisation can use it, because a maintainer nobody can authenticate against is a resource nobody can correct.

aut-num#

Documents the AS and its routing policy in RPSL:

aut-num:        AS203136
as-name:        EXAMPLE-AS
import:         from AS65001 accept ANY
export:         to AS65001 announce AS-EXAMPLE
import:         from AS65002 accept ANY
export:         to AS65002 announce AS-EXAMPLE
admin-c:        EXPL-RIPE
tech-c:         EXPL-RIPE
mnt-by:         EXAMPLE-MNT
source:         RIPE

Some upstreams read this; many do not. Keep it correct anyway — it is the documentation of record when someone is debugging why your traffic goes where it goes.

route and route6#

This is the object that actually matters day to day. It authorises an origin AS to announce a prefix, and it is what IRR-based prefix filters are built from:

route:          185.143.176.0/22
descr:          EXAMPLE network
origin:         AS203136
mnt-by:         EXAMPLE-MNT
source:         RIPE

No route object means no entry in your upstream's generated filter, which means your announcement is discarded. This is the single most common reason a newly announced prefix is invisible from half the internet while the BGP session itself looks perfectly healthy.

as-set#

If you have downstream customers with their own ASNs, your upstreams filter you by an as-set, not by a single AS:

as-set:         AS203136:AS-CUSTOMERS
descr:          Customers of AS203136
members:        AS203136
members:        AS64500
mnt-by:         EXAMPLE-MNT
source:         RIPE

Use the hierarchical form (AS203136:AS-CUSTOMERS) rather than a flat name. Hierarchical set names are owned by the ASN that prefixes them, which removes both the ambiguity and the land-grab problem of flat names.

Your upstreams turn all of this into filters, typically with bgpq4:

# IPv4 prefix filter for a customer, Junos format
bgpq4 -Jl CUSTOMER-V4 AS203136:AS-CUSTOMERS

# IPv6, Cisco format
bgpq4 -6 -l CUSTOMER-V6 AS203136:AS-CUSTOMERS

Run that command against your own as-set. Whatever comes out is what your upstream will accept — and if a prefix is missing from that output, no amount of BGP configuration will make it work.

From IRR to RPKI#

IRR objects say "this origin claims this prefix". RPKI says "the resource holder cryptographically authorised this origin for this prefix". The second is verifiable without trusting the database's access control, which is why validation is increasingly enforced.

A ROA has three fields: the prefix, the origin ASN, and maxLength. It produces one of three validation states for any announcement:

• Valid — a ROA covers the prefix, the origin matches, and the length is within maxLength.
• Invalid — a ROA covers the prefix but the origin or the length disagrees. This is the dangerous state: Invalid is actively dropped by validating networks.
• NotFound — no ROA covers the prefix. Still accepted almost everywhere, but that is slowly changing.

The maxLength decision#

maxLength says how specific an announcement may be while remaining Valid. It is the field people get wrong in both directions:

• Too loose (for example maxLength /24 on a /22 you never deaggregate) authorises six more-specifics you never announce — two /23s and four /24s. An attacker announcing one of them from your ASN produces a Valid hijack that beats your aggregate by longest-prefix-match.
• Too tight blocks legitimate operational deaggregation. The group's ROA for 185.143.176.0/22 uses maxLength /22 — the conservative choice. It means any more-specific announcement is Invalid until the ROA is changed first.

Create ROAs in the RIPE NCC portal, where the NCC operates the certificate authority on your behalf. Give relying parties time to fetch the new set before you rely on it; validators refresh on a schedule, not instantly.

Turning on Route Origin Validation#

Publishing ROAs protects other people from mistakes about your prefixes. Validating protects you from mistakes about theirs. You need a relying-party validator — Routinator, rpki-client, Fort or OctoRPKI — feeding your routers over RTR (RFC 8210).

FRR:

rpki
 rpki polling_period 300
 rpki cache 10.0.0.10 3323 preference 1
 exit
!
route-map UPSTREAM-IN deny 5
 match rpki invalid
!
route-map UPSTREAM-IN permit 10
 set local-preference 100

Junos:

routing-options {
    validation {
        group RPKI {
            session 10.0.0.10 {
                port 3323;
                local-address 10.0.0.1;
            }
        }
    }
}
policy-options {
    policy-statement rpki-validation {
        term invalid {
            from {
                protocol bgp;
                validation-database invalid;
            }
            then reject;
        }
        term valid {
            from {
                protocol bgp;
                validation-database valid;
            }
            then {
                validation-state valid;
                accept;
            }
        }
    }
}

Run at least two validator instances. A router whose only RTR session is down falls back to treating everything as NotFound, which is a fail-open you should choose deliberately rather than discover.

Verifying from the outside#

Never trust your own configuration as evidence. Check what the rest of the world sees:

# does the route object exist, and with which origin?
whois -h whois.ripe.net -- '-T route 185.143.176.0/22'

# the aut-num and its policy
whois -h whois.ripe.net AS203136

# what your validator actually holds
routinator vrps | grep 185.143.176.0

# what filters your upstream will generate for you
bgpq4 -Jl TEST AS203136:AS-CUSTOMERS

Add RIPEstat for the registry and RPKI validation view, RIPE RIS and public looking glasses for what is actually propagating, and a route collector view to confirm the origin AS seen in the wild is the one in your ROA.

The mistakes that take a prefix off the internet#

• No route object. Upstream filters drop the prefix; the BGP session is up, and everything looks fine on your side.
• Route object with a stale origin. After an ASN change or a customer migration, the object still names the old AS. IRR filters silently exclude it.
• ROA created, announcement not updated. Or the reverse: announcing a more-specific before widening maxLength, producing an Invalid that validating networks drop. This is the failure mode we see most often, and it looks exactly like a partial outage.
• Flat as-set names. Two organisations using the same unqualified set name, and filters that include prefixes neither of them intended.
• Unmaintainable mntner. Nobody left in the company can authenticate against it, so no object can be corrected when it needs to be — usually discovered during an incident.
• Validators publishing but not validating. ROAs exist, routers do no ROV, and the network is protected against nothing.

Once the registry side is correct, the operational side — moving traffic between those upstreams — is covered in BGP traffic engineering with flow data.