Routing Policy Specification Language (RPSL)
obsoleted by
- rfc-2622 — Routing Policy Specification Language (RPSL)
Extracted elements (28)
Hierarchical set names guarantee authorship: anyone can create AS-MCI-CUSTOMERS, but only the entity controlling AS3561 can create AS3561:AS-CUSTOMERS, providing a verifiable binding between a set and its owner.
Policy analysis tools that encounter unknown rp-attributes are permitted to approximate: filter methods may always be treated as matching and action methods as no-ops. Tools may also download code to handle unknown attributes via mechanisms outside RPSL's scope.
RPSL is a replacement for RIPE-181 (RFC-1786), which could not express certain routing policies. Through operational use of RIPE-181, it became apparent that a more generalized language was needed; RPSL addresses those limitations while remaining extensible so new protocols and features can be introduced at any time.
RPSL is explicitly not a router configuration language; it is designed so that router configurations can be generated from it. A global view of routing policy is stored in a single cooperatively maintained distributed database (the IRR) to improve routing integrity.
The 'mbrs-by-ref' mechanism allows route objects registered by listed maintainers to implicitly join a route-set via their 'member-of' attribute, enabling distributed set population without modifying the set object itself. The value ANY makes membership open to all maintainers.
RPSL is designed as a backward-compatible replacement for RIPE-181 (RFC-1786). The import/export/default policy model, peering specification, and object structure are derived from RIPE-181 but generalized. Implementors should consult RIPE-181 for background on underlying principles.
The optional 'protocol <p1> into <p2>' clauses on import/export attributes extend RPSL to non-BGP protocols and support route redistribution between protocols (e.g., BGP4 into OSPF or STATIC into BGP4). Both protocol fields default to the Internet exterior gateway protocol (BGP) if omitted.
If multiple auth attributes are specified on a mntner object, an update request satisfying any one of them is considered authenticated from that maintainer.
RPSL is case insensitive and only characters from the ASCII character set may be used. An object-name must begin with a letter, end with a letter or digit, and consist only of letters, digits, underscore, and hyphen.
When the same peering or route set is covered by multiple policy expressions, the specification-order rule applies: the action of the first matching peering specification is used. Later, more-specific peering entries that are fully subsumed by an earlier entry have no effect.
An address-prefix-range extends an IPv4 prefix with one of four range operators: '^-' (exclusive more-specifics), '^+' (inclusive more-specifics), '^n' (all length-n specifics), or '^n-m' (all specifics of length n through m). Range operators distribute over set members.
An RPSL object is represented as a list of attribute-value pairs, one per line, with the attribute name at column 0 followed by ':' and then the value. An object ends at a blank line. Continuation lines begin with whitespace. Comments start at '#' and run to end-of-line.
AS-path regular expressions are POSIX-compliant over the alphabet of AS numbers, supporting standard operators (*, +, ?, {m}, {m,n}), AS number sets ([...] and [^...]), and the 'same-match' variants (~*, ~+, ~{m,n}) where all occurrences must match the same AS.
Hierarchical set names are sequences of set names and AS numbers separated by colons (e.g., AS1:AS-CUSTOMERS). A set X1:...:Xn can only be created by the maintainer of X1:...:Xn-1, partitioning the name space under the controlling entity.
Policy filters can be: the keyword ANY; an explicit address-prefix set enclosed in braces; a route-set or AS-set name (with optional range operators); or an AS-path regular expression enclosed in '<' and '>'. Composite filters use AND, OR, NOT operators.
Structured import/export policies support EXCEPT and REFINE operators. EXCEPT subtracts: right-hand-side filters are restricted to routes also matched by the left, and left-hand-side filters exclude routes matched by the right. REFINE takes the Cartesian product of peerings with ANDed filters and concatenated actions.
The as-set class defines a named set of AS numbers (name must start with 'as-'). Members can be listed explicitly via 'members' or implicitly via 'mbrs-by-ref'. An AS number in a route-set context implicitly defines the set of routes originated by that AS.
The aut-num class specifies an Autonomous System's routing policy. The 'import' attribute specifies inbound policy (from peerings, optional actions, and an accept filter), the 'export' attribute specifies outbound policy (to peerings, optional actions, and an announce filter), and 'default' specifies default routing.
The dictionary class provides extensibility: it defines rp-attributes (routing policy attributes with strongly typed access methods), typedef (union and list types), and protocol definitions with MANDATORY/OPTIONAL peering options. Tools must fetch the dictionary to recognize new rp-attributes.
The import attribute syntax is: 'from <peering> [action <action>] ... accept <filter>'. A peering can be specified as an AS number with optional router IP addresses ('from AS2 7.7.7.2 at 7.7.7.1') or as AS-expressions and router-expressions using AND, OR, NOT.
The inet-rtr class specifies individual routers, providing router ID, AS number, interface addresses and masks, and peer information. It binds DNS names to IP addresses for use in peering specifications and links routers to their aut-num objects.
The initial RPSL dictionary (object name 'RPSL') defines rp-attributes pref, med, dpa, aspath, community, next-hop, and cost; types community_elm and community_list; and protocols BGP4 (with mandatory asno and optional flap_damp options), OSPF, RIP, IGRP, IS-IS, STATIC, RIPng, DVMRP, PIM-DM, PIM-SM, CBT, and MOSPF.
The 'inject' attribute on a route object specifies when and how a more-specific route causes an aggregate to be generated, with optional 'upon' conditions (HAVE-COMPONENTS, EXCLUDE, and filter expressions) and optional action and router specifications.
The mntner class defines entities authorized to create, delete, and update RPSL objects. Key attributes include 'auth' (authentication scheme: NONE, MAIL-FROM, PGP, or CRYPT-PW), 'upd-to' (notified on unauthorized update attempts), and 'mnt-nfy' (notified on any change).
The route class identifies an interdomain route by the mandatory pair (route, origin): 'route' is the address prefix and 'origin' is the originating AS number. Together these form the class key. An optional 'withdrawn' date attribute signals the prefix is no longer originated.
The route class supports aggregate route specification via attributes: 'components' (filter defining component routes and source protocol), 'aggr-bndry' (AS set defining aggregation boundary), 'aggr-mtd' (aggregation method: INBOUND or outbound with optional AS set), 'export-comps' (filter for re-exporting components), and 'holes' (list of excluded prefixes).
The route-set class defines a named set of address prefixes (name must start with 'rs-'). Membership is specified via the 'members' attribute (explicit prefixes or other route-set names with optional range operators) and/or the 'mbrs-by-ref' attribute (indirect membership via maintainer authorization).
RPSL's security model relies on the mntner class for access control to the IRR database. Authentication schemes include CRYPT-PW (Unix crypt password), PGP (public key), and MAIL-FROM (regex on submitter email address). The scheme NONE provides no authentication. Unauthorized update attempts trigger notification to the upd-to address.