Intermediate · IRR, RPSL and AS-SETs · section 3 of 8

RPSL objects and attributes

✓ Lab-tested 17 October 2026 on IRRd 4.5.3, bgpq4 1.9, PostgreSQL 16, Redis 7

IRR data is written in the Routing Policy Specification Language (RPSL, RFC 2622, extended for IPv6 by RFC 4012). Every record is an object: a block of attribute: value lines, separated from the next object by a blank line. The first attribute names the object's class and holds its primary key.

Class	Primary key	What it says
`inetnum` / `inet6num`	Address range	Registration of address space: who holds it, status, contacts. Only in the RIR's own database.
`route` / `route6`	Prefix + `origin`	"This prefix may be originated by this AS." The object filters are built from.
`aut-num`	ASN	An autonomous system: name, contacts, and optionally its routing policy.
`as-set`	Set name	A named group of ASNs and other as-sets, usually a customer cone.
`route-set`	Set name	A named group of prefixes (less common).
`mntner`	Maintainer name	Credentials. Objects name a maintainer in `mnt-by`; only it can change them.
`organisation`, `role`, `person`	Handle	Contacts, referenced by `org:`, `admin-c:`, `tech-c:` and `abuse-c:`.

A few conventions apply to every class:

Repeatable attributes: members:, mnt-by: and import: can appear many times, or hold comma-separated lists.
Continuation lines start with whitespace or +; # starts a comment.
References: admin-c, org and mnt-by hold the keys of other objects, so a whois query can follow them.
source: names the database the object lives in. RIPE and RADB objects with the same key are different objects.

Who may create a route object?

In an authoritative IRR, creating a route object needs authorisation from the maintainer of the address space. On the inetnum, mnt-routes (or mnt-lower/mnt-by) says who may do that. This is what makes the authoritative route object meaningful: the space holder agreed to it.

Address registration, route objects and a maintainer

inetnum:        198.51.100.0 - 198.51.100.255
netname:        EXAMPLE-NET
country:        NL
org:            ORG-EX1-RIPE
admin-c:        EX123-RIPE
tech-c:         EX123-RIPE
abuse-c:        EXAB1-RIPE
status:         ASSIGNED PA
mnt-by:         EXAMPLE-MNT
mnt-routes:     EXAMPLE-MNT
source:         RIPE

route:          198.51.100.0/24
descr:          Example Network
origin:         AS64500
mnt-by:         EXAMPLE-MNT
source:         RIPE

route6:         2001:db8:500::/48
origin:         AS64500
mnt-by:         EXAMPLE-MNT
source:         RIPE

mntner:         EXAMPLE-MNT
admin-c:        EX123-RIPE
upd-to:         noc@example.net
auth:           SSO noc@example.net
mnt-by:         EXAMPLE-MNT
source:         RIPE

Line 1: inetnum keys are ranges, not prefixes: first and last address. This object comes from the RIR's allocation process, not from you.
Lines 5–7: Contacts are references to role/person objects. abuse-c is mandatory in RIPE and is where abuse reports go.
Line 8: status says how the space was handed out, e.g. ALLOCATED PA to a LIR, or ASSIGNED PA to an end user.
Lines 9–10: mnt-by protects this object. mnt-routes names who may create route objects inside this range, which is the authorisation that makes route objects trustworthy.
Lines 13–17: The object filters are built from: this prefix may be originated by AS64500. One route object per announced prefix; a /24 inside a /22 needs its own.
Lines 19–22: route6 is the IPv6 equivalent (RFC 4012). Networks often forget these, so their IPv6 gets filtered.
Lines 24–29: The maintainer. auth: SSO ties changes to RIPE NCC Access accounts, which support two-factor authentication. Avoid password (MD5-PW) auth.

Check your understanding

AS64500 starts announcing a new /24 carved out of its /22, which already has a route object. Its upstream's filters drop the /24. Why?

A route object for the /22 covers every more-specific
There's no route object for the /24 itself
/24 is too long to announce
The inetnum needs to be split first