RFC 2650
Using RPSL in Practice
RFC 2650: Using RPSL in Practice 💖
okay bestie, this is RFC 2650, published by the Network Working Group in August 1999 🎀 It's an Informational doc, so it's sharing knowledge with the Internet community rather than setting an official standard 🦋 The authors are D. Meyer (Cisco Systems), J. Schmitz (America On-Line), C. Orange (RIPE NCC), M. Prior (Connect), and C. Alaettinoglu (USC/ISI) 👑 The title block doesn't list any RFCs it obsoletes or updates, so it's just doing its own thing ✨
Status of this Memo 📜
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice ©️
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract 🌸
okay so this doc is a tutorial on using the Routing Policy Specification Language (RPSL) to describe routing policies in the Internet Routing Registry (IRR) 🧚 It walks you through specifying different routing policies and configurations with RPSL, registering them in the IRR, and analyzing them with the routing policy analysis tools. One example is generating vendor specific router configurations, which is giving very useful energy 💅
1 Introduction ✨
This document is a tutorial on RPSL, and it's written for an Internet/Network Service Provider (ISP/NSP) engineer who already gets Internet routing but is new to RPSL and the IRR 🦋 For completeness, you're pointed to the RPSL reference document (RFC 2622) [1]. It's also a good idea to keep that doc open while you work through this tutorial 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 🫶
The IRR is a repository of routing policies 🍓 Right now it's made up of five repositories maintained at these sites: the CA*Net registry in Canada, the ANS, CW and RADB registries in the United States of America, and the RIPE registry in Europe 🌈 The five repositories are run independently, but each site exchanges its data with the others regularly, at least once a day and as often as every ten minutes ⭐ CW, CA*Net and ANS are private registries that contain the routing policies of the networks and the customer networks of CW, CA*Net, and ANS respectively 🔒 RADB and RIPE are both public registries, and any ISP can publish their policies in them 🌍
The registries all keep up-to-date copies of one another's data 🤝 At any of the sites, the five registries can be inspected as a set. One should refrain from registering your data in more than one of the registries, because this practice almost invariably leads to inconsistencies in the data 😭 The user trying to interpret the data is left in a confusing (at best) situation 💀 CW, ANS and CA*Net customers are generally required to register their policies in their provider's registry. Others may register policies either at the RIPE or RADB registry, as preferred 🎀
RPSL is based on RIPE-181 [2, 3], a language used to register routing policies and configurations in the IRR 🦋 Operational use of RIPE-181 has shown that it is sometimes difficult (or impossible) to express a routing policy that is used in practice 🙈 RPSL was developed to address these shortcomings and to provide a language that can be further extended as the need arises 🔥 RPSL obsoletes RIPE-181 👑
RPSL constructs are expressed in one or more database "objects" that are registered in one of the registries described above 🧩 Each database object contains some routing policy information and some necessary administrative data 📝 For example, an address prefix routed in the inter-domain mesh is specified in a route object, and the peering policies of an AS are specified in an aut-num object 🌸 The database objects are related to each other by reference. For example, a route object must refer to the aut-num object for the AS in which it is originated 🔗 Implicitly, these relationships define sets of objects, which can be used to specify policies affecting all members 💜 For example, we can specify a policy for all routes of an ISP by referring to the AS number in which the routes are registered to be originated 🧚
When objects are registered in the IRR, they become available for others to query using a whois service 🔍 Figure 1 shows the use of the whois command to get the route object for 128.223.0.0/16. The output of the whois command is the ASCII representation of the route object. The syntax and semantics of the route object are described in Appendix A.3 📖 Registered policies can also be compared with others for consistency, and they can be used to diagnose operational routing problems in the Internet 🕵️♀️
% whois -h whois.ra.net 128.223.0.0/16
route: 128.223.0.0/16
descr: UONet
descr: University of Oregon
descr: Computing Center
descr: Eugene, OR 97403-1212
descr: USA
origin: AS3582
mnt-by: MAINT-AS3582
changed: meyer@ns.uoregon.edu 19960222
source: RADBFigure 1: whois command and a route object. 📸
The RAToolSet [6] is a suite of tools that can be used to analyze the routing registry data 🛠️ It includes tools to configure routers (RtConfig), tools to analyze paths on the Internet (prpath and prtraceroute), and tools to compare, validate and register RPSL objects (roe, aoe and prcheck) 💅
In the following section, we will describe how common routing policies can be expressed in RPSL. The objects themselves are described in Appendix A 🎀 Authoritative information on the IRR objects, however, should be sought in RFC-2622, and authoritative information on general database objects (person, role, and maintainers), and on querying and updating the registry databases, should be sought in RIPE-157 [4] 📚 Section 3.2 describes the use of RtConfig to generate vendor specific router configurations 🦋
2 Specifying Policy in RPSL 🌈
The key purpose of RPSL is to let you specify your routing configuration in the public Internet Routing Registry (IRR), so that you and others can check your policies and announcements for consistency 🫶 Also, while you're setting policies and configuring routers, you take the policies and configurations of others into account 👀
In this section, we begin by showing how some simple peering policies can be expressed in RPSL. Then we build on that to introduce the various database objects you'll need to register policies in the IRR, and to show how more complex policies can be expressed 🧚
2.1 Common Peering Policies 🤝
The peering policies of an AS are registered in an aut-num object that looks something like the one in Figure 2. We'll focus on the semantics of the import and export attributes, where peering policies are expressed. We'll also describe some of the other key attributes in the aut-num object, but the reader should refer to RFC-2622 or to RIPE-157 for the definitive descriptions 📖
aut-num: AS2
as-name: CAT-NET
descr: Catatonic State University
import: from AS1 accept ANY
import: from AS3 accept <^AS3+$>
export: to AS3 announce ANY
export: to AS1 announce AS2 AS3
admin-c: AO36-RIPE
tech-c: CO19-RIPE
mnt-by: OPS4-RIPE
changed: orange@ripe.net
source: RIPEFigure 2: Autonomous System Object 🎀
Now check out Figure 3 (AS4 and AS5 in the figure will be discussed later) 👀 The peering policies in the AS2 aut-num object from Figure 2 are typical for a small service provider that provides connectivity for a customer AS3 and uses AS1 for transit 💖 That is, AS2 only accepts announcements from AS3 that:
- are originated in AS3; and
- have paths composed of only AS3's (^ in
<^AS3+$>means that AS3 is the first member of the path, + means that AS3 occurs one or more times in the path, and $ means that no other AS can be present in the path after AS3) (1).
To AS1, AS2 announces only those routes that originate in their AS or in their customer's AS 🧠
AS1--------AS2--------AS3
| |
| |
AS4--------AS5Figure 3: Some Neighboring ASes. 🗺️
In the example above, "accept ANY" in the import attribute means AS2 will accept any announcements that AS1 sends, and "announce ANY" in the export attribute means any route that AS2 has in its routing table will be passed on to AS3 🌸 Assuming AS1 announces "ANY" to AS2, AS2 is taking full routing from AS1 😤
Note that with this peering arrangement, if AS1 adds or deletes route objects, there's no need to update any of the aut-num objects to keep the full routing policy going. Added (or deleted) route objects implicitly update AS1's and AS2's policies 🪄
While the peering policy in Figure 2 for AS2 is common, in practice many peering agreements are more complex 🧩 Before we look at more examples, though, let's first look at the aut-num object itself. It's just a set of attribute labels and values that can be submitted to one of the registry databases 📝 This particular object is specified as being in (or headed for) the RIPE registry (see the last line in Figure 2). The source should be specified as one of ANS, CANET, CW, RADB, or RIPE, depending on the registry in which the object is maintained 🌍 The source attribute must be specified in every database object 💅
It's also worth noting that this object is "maintained by" OPS4-RIPE (the value of the mnt-by attribute), which references a "mntner" object 🔐 Because the aut-num object may be used for router configuration and other operational purposes, readers need to be able to count on the validity of its contents 🙏 It is therefore required that a mntner be specified in the aut-num and in most other database objects, which means you must create a mntner object before you can register your peering policies 🦋 For brief information on the "mntner" object and object writeability, see Appendix A of this document. For more extensive information on how to set up and use a mntner to protect your database objects, see Section 2.3 of RIPE-157 🔥
2.2 ISP Customer - Transit Provider Policies ✨
okay so it's super common for an ISP to get connectivity from a transit provider that announces all its routes 🌍. The ISP then passes those routes along to its customers so they can reach hosts on the global Internet 💅. Meanwhile, the ISP usually announces its customers' networks up to the transit ISP, which makes them accessible on the global Internet too 🫶. This is the service specified in Figure 2 for AS3.
Okay, look back at Figure 3 🦋. Say AS2 wants to give the same service to AS4. It would be pretty easy to tweak the import and export lines in the aut-num object for AS2 (Figure 2) so they look like Figure 4.
import: from AS1 accept ANY
import: from AS3 accept <^AS3+$>
import: from AS4 accept <^AS4+$>
export: to AS3 announce ANY
export: to AS4 announce ANY
export: to AS1 announce AS2 AS3 AS4Figure 4: Policy for AS3 and AS4 in the AS2 as-num object
These changes are trivial to make, of course 🙄. But as the number of AS2 customers grows, it gets harder to keep track of them and to prevent errors 😭. Also, if AS1 is selective about only accepting routes from AS2's customers via AS2, the aut-num object for AS1 would have to be adjusted to accommodate AS2's new customer.
By using the RPSL "as-set" object, we can simplify this a lot ✨. Figure 5 describes the customers of AS2. Now that we have this set to work with, we can rewrite the policies in Figure 2 as shown in Figure 6.
as-set: AS2:AS-CUSTOMERS
members: AS3 AS4
changed: orange@ripe.net
source: RIPEFigure 5: The as-set object
import: from AS1 accept ANY
import: from AS2:AS-CUSTOMERS accept <^AS2:AS-CUSTOMERS+$>
export: to AS2:AS-CUSTOMERS announce ANY
export: to AS1 announce AS2 AS2:AS-CUSTOMERSFigure 6: Policy in the AS2 aut-num object for all AS2 customers
Now, if the aut-num object for AS1 contains the line:
import: from AS2 accept <^AS2+ AS2:AS-CUSTOMERS*$>then nothing needs to change in the aut-num objects for AS1 or AS2 as the AS2 customer base grows 🎀. The AS numbers for new customers can simply be added to the as-set AS2:AS-CUSTOMERS, and everything works just like it does for the existing customers. Honestly, for readability, scalability and maintainability, this is a far better mechanism compared to adding policy for the customer AS's to the aut-num objects directly 👑. The policy in this example says that AS1 will accept route announcements from AS2 where the first element of the path is AS2, followed by more occurrences of AS2, and then 0 or more occurrences of any AS2 customer (e.g. any member of the as-set AS2:AS-CUSTOMERS).
Alternatively, one may want to limit the routes accepted from a peer, especially if the peer is a customer 🧐. This is recommended for several reasons, such as preventing the improper use of unassigned address space and, of course, malicious use of another organization's address space 💀.
Filtering like this can be expressed in various ways in RPSL 🌸. Suppose the address space 7.7.0.0/16 has been allocated to the ISP managing AS3 for assignment to its customers. AS3 may want to announce part or all of this block on the global Internet. Suppose AS2 wants to be certain that it only accepts announcements from AS3 for address space that has been properly allocated to AS3. AS2 could then modify the AS3 import line in Figure 2 to read:
import: from AS3 accept { 7.7.0.0/16^16-19 }This says that route announcements for this address block will be accepted from AS3 if they are of length up to /19. Of course, this will have to be modified if and when AS3 gets more address space 🙈. Also, it's clear that for an ISP with a growing or changing customer base, this mechanism won't scale well.
route-set: AS2:RS-ROUTES:AS3
members: 7.7.0.0/16^16-19
changed: orange@ripe.net
source: RIPEFigure 7: The route-set object
Luckily, RPSL supports the notion of a "route-set" 🧚. As shown in Figure 7, it can be used to specify the set of routes that will be accepted from a given customer. With this set (and a similar one for AS4), the manager of AS2 can filter on the address space accepted from their customers by modifying the import lines in the AS2 aut-num object, as shown in Figure 8.
import: from AS1 accept ANY
import: from AS3 accept AS2:RS-ROUTES:AS3
import: from AS4 accept AS2:RS-ROUTES:AS4
export: to AS2:AS-CUSTOMERS announce ANY
export: to AS1 announce AS2 AS2:AS-CUSTOMERSFigure 8: Policy in the AS2 aut-num object for address based filtering on AS2 customers
This is only slightly more complex than the example in Figure 6 🦋. Plus, nothing needs to change in the AS2 aut-num object when a customer's address space changes, and this filtering can be supported without any changes to the AS1 aut-num object 🙌. The extra complexity comes from the two route set names being different. Otherwise, we could have combined the two import statements into one. Also, please note that the set names are built hierarchically 🌈. The first AS number says whose sets these are, and the last AS number parameterizes these sets for each peer. RPSL lets you replace the peer's AS number with the keyword PeerAS.
So,
import: from AS3 accept AS2:RS-ROUTES:PeerAS
import: from AS4 accept AS2:RS-ROUTES:PeerAShas the same meaning as the corresponding import statements in Figure 8 ✨. This lets us combine the two import statements into one, as shown in Figure 9.
import: from AS1 accept ANY
import: from AS2:AS-CUSTOMERS accept AS2:RS-ROUTES:PeerAS
export: to AS2:AS-CUSTOMERS announce ANY
export: to AS1 announce AS2 AS2:AS-CUSTOMERSFigure 9: Policy in the AS2 aut-num object using PeerAS
2.3 Including Interfaces in Peering Definitions 🔌
So far, all the peerings in our examples were between ASes. But RPSL can describe peerings in way more detail 🤓. Peerings can be specified between physical routers using IP addresses in the import and export attributes. Figure 10 shows a simple example in which AS1 and AS2 are connected to an exchange point IX. AS1 has only one connection to the exchange point, via a router interface with IP address 7.7.7.1, while AS2 has two different connections, with IP addresses 7.7.7.2 and 7.7.7.3. The first AS can then define its routing policy in more detail by specifying its boundary router 💖.
+--------------------+ +--------------------+
| 7.7.7.1 |-----+ +-----| 7.7.7.2 |
| | | | | |
| AS1 | ======== | AS2 |
| | IX | | |
| | +-----| 7.7.7.3 |
+--------------------+ +--------------------+Figure 10: Including interfaces in peerings definitions
aut-num: AS1
import: from AS2 at 7.7.7.1 accept <^AS2+$>Because AS1 has only one connection to the exchange point in this example, this specification doesn't differ from one where no boundary router is specified 🙃. However, AS1 might want to accept only those announcements from AS2 that come from the router with IP address 7.7.7.2, and ignore those from router 7.7.7.3. AS1 can specify this routing policy like so:
aut-num: AS1
import: from AS2 7.7.7.2 at 7.7.7.1 accept <^AS2+$>By selecting certain pairs of routers in a peering specification, others can be denied 🚫. If no routers are included in a policy clause, it is assumed that the policy applies to all peerings among the ASes involved ✨.
2.4 Describing Simple Backup Connections 🛟
Peerings among ASes aren't limited to one router per AS 🌷. In Figure 10, one of the two connections of AS2 to the exchange point IX might be used as a backup in case the other connection fails. Let's say AS1 wants to use the connection to router 7.7.7.2 of AS2 during regular operations, and router 7.7.7.3 as the backup. In a router configuration, this may be done by setting a local preference. The RPSL equivalent is a corresponding action definition in the peering description. Action definitions are inserted directly before the accept keyword 🎀.
aut-num: AS1
import: from AS2 7.7.7.2 at 7.7.7.1 action pref=10;
from AS2 7.7.7.3 at 7.7.7.1 action pref=20;
accept <^AS2+$>pref is the opposite of local-pref: smaller values are preferred over larger ones 🔄. Actions can also be defined without specifying router IP addresses. If no routers are included in the policy clause, it is assumed that the actions are carried out for all peerings among the ASes involved 💅.
In the previous example, AS1 controls where it sends its traffic and which connection is used as the backup. However, AS2 may also define a backup connection in an export clause 🫶:
aut-num: AS2
export: to AS1 7.7.7.1 at 7.7.7.2 action med=10;
to AS1 7.7.7.1 at 7.7.7.3 action med=20;
announce <^AS2+$>The definition here for AS2 is the symmetric counterpart to the routing policy of AS1. The selection of routing information is done by setting the multi exit discriminator metric med. Honestly, med metrics won't really be used like this in practice 😭; they're more suitable for load balancing, including backups. For more details on med metrics, refer to the BGP-4 RFC [7]. To use the med to achieve load balancing, one often sets it to the "IGP metric". In RPSL, this is specified as:
aut-num: AS2
export: to AS1 action med=igp_cost; announce <^AS2+$>So, both routers will set the med to the IGP metric at that router, causing some routes to be preferred at one router and other routes at the other router 🦋.
2.5 Multi-Home Routing Policies using the community Attribute
okay so RFC 1998 [9] is the one that explains how to use the BGP community attribute for load balancing and backup connections when you're multi-homed 🌈 in this section we do stepwise refinement on one example to see how those policies could be written in RPSL 🫶
The big idea of RFC 1998 is that the community attribute lets a customer set the BGP LOCAL_PREF on a provider's routers 💅 that means the customer can influence the provider's route selection, and it usually works by lowering LOCAL_PREF to mark a backup arrangement 🎀
In our example, AS1 is the provider 👑 and a customer (AS4) is connected to two of AS1's direct customers (AS2 and AS3). We want to show how AS1 could write its policy so that AS4 can tell AS1 which connection it prefers 🦋
AS1's base policy is to only accept routes from customers that are originated by the customer, or by the customer's customers. That looks like this:
aut-num: AS1
import: from AS2
accept (AS2 OR AS4) AND <^AS2+ AS4*$>
import: from AS3
accept (AS3 OR AS4) AND <^AS3+ AS4*$>
import: from AS5
accept AS5 AND <^AS5+$>Note that AS4 is a customer of AS2 and AS3, and AS5 does not have its own customers. 🍓
Now suppose we want to add a rule that says if a customer tags a route with community 1:1, then AS1 will act on it and reduce the BGP LOCAL_PREF by 10 ✨
aut-num: AS1
import: from AS2
action pref=10;
accept (AS2 OR AS4) AND <^AS2+ AS4*$>
AND community.contains(1:1)
import: from AS2
action pref=0;
accept (AS2 OR AS4) AND <^AS2+ AS4*$>
import: from AS3
action pref=10;
accept (AS3 OR AS4) AND <^AS3+ AS4*$>
AND community.contains(1:1)
import: from AS3
action pref=0;
accept (AS3 OR AS4) AND <^AS3+ AS4*$>
import: from AS5
action pref=10;
accept AS5 AND <^AS5+$> AND community.contains(1:1)
import: from AS5
action pref=0;
accept AS5 AND <^AS5+$>Look at that, it's literally the same statement copy-pasted for every peering 😭 that's why RPSL's refine statement is the move. It makes the policy more concise and helps avoid errors as more peerings get added later 🧚
aut-num: AS1
import: {
from AS-ANY
action pref=10;
accept community.contains(1:1);
from AS-ANY
action pref=0;
accept ANY;
} refine {
from AS2 accept (AS2 OR AS4) AND <^AS2+ AS4*$>;
from AS3 accept (AS3 OR AS4) AND <^AS3+ AS4*$>;
from AS5 accept AS5 AND <^AS5+$>;
}Now we can clearly see that any route accepted from a customer that contains community 1:1 has its local preference reduced by 10 🔥
The refinement cleaned things up, but we still have a bunch of individual policies that all mean the same basic provider policy, "from the customer, accept customer routes" 🙈 we can simplify that further with AS sets.
First, we gather all of AS1's customers into a single AS set, AS1:AS-CUSTOMERS. We start the hierarchical set name with AS1 so it doesn't clash with set names other ASes use in the IRR 🎀
as-set: AS1:AS-CUSTOMERS
members: AS2, AS3, AS5We also define one set per customer, listing the AS numbers of that customer's customers 💜
as-set: AS1:AS-CUSTOMERS:AS2
members: AS4
as-set: AS1:AS-CUSTOMERS:AS3
members: AS4
as-set: AS1:AS-CUSTOMERS:AS5
members: # AS5 has no customers yet, so keep blank for nowNow we can use the keyword PeerAS with these AS sets to simplify the policy even more 💖
aut-num: AS1
import: {
from AS-ANY
action pref=10;
accept community.contains(1:1);
from AS-ANY
action pref=0;
accept ANY;
} refine {
from AS1:AS-CUSTOMERS
accept (PeerAS OR AS1:AS-CUSTOMER:PeerAS)
AND <^PeerAS+ AS1:AS-CUSTOMER:PeerAS*$>
}Using PeerAS with AS1:AS-CUSTOMERS is basically the same as looping over the members of AS1:AS-CUSTOMERS and swapping PeerAS for each member of that set 🦋
To show how AS4 could use this policy, here's a policy fragment:
aut-num: AS4
export: to AS2
action community.append(1:1);
announce AS1
export: to AS3
announce AS1So here AS4 is telling AS1 to prefer the routes from AS3 🫶
3 Tools 🛠️
okay tools time 💅 in this section we quickly introduce a few tools you can use to inspect data in the database, figure out optimal routing policies, and enter new data ✨
3.1 The aut-num Object Editor
all the examples from the previous sections can be edited by hand 🙈 you can pull them out one at a time from the IRR using the whois program, edit them, and then hand them back to the registry robots. BUT the RAToolSet [6] has a super nice tool that makes working with aut-num objects way easier: the aut-num object editor, aoe 🌸
The aut-num object editor has a graphical user interface for viewing and manipulating aut-num objects registered at any IRR. You can generate new aut-num objects from templates and submit them to the registries 🍓
You can also compare the routing policy in the databases with real-life peerings 👀 which is why aoe is highly recommended as an interface to the IRR for aut-num objects. More info on aoe is available together with the RAToolSet [6] 💜
3.2 Router Configuration Using RtConfig
RtConfig is a tool developed by the Routing Arbiter project [8] that generates vendor-specific router configurations from the policy data held in the various IRRs ✨ it currently supports Cisco, gated and RSd configuration formats. It's been publicly available since late 1994 and many sites are still using it for router configuration, which is iconic 👑 the next section describes a methodology for generating vendor-specific router configurations using RtConfig (2) 🧚
3.3 Using RtConfig
okay so the general paradigm for using RtConfig goes like this: register policy in an IRR, build an RtConfig source file, then run RtConfig against the source file and the IRR database to create the vendor-specific router configuration for your policy 🎀 the source file has vendor-specific commands AND RtConfig commands. To make one, grab one of your router configuration files and swap the vendor-specific policy commands for RtConfig commands 💖
Commands that start with @RtConfig tell RtConfig to do special operations 🫶 Figure 11 shows an example source file. Here, commands like "@RtConfig import AS3582 198.32.162.1 AS3701 198.32.162.2" tell RtConfig to generate vendor-specific import policies where router 198.32.162.1 in AS3582 imports routes from router 198.32.162.2 in AS3701. The other @RtConfig commands tell RtConfig to use certain names and numbers in its output (check the RtConfig manual [8] for more info) 🌈
Once the source file is ready, RtConfig processes it (the default IRR is the RADB and the default vendor is Cisco, but you can override these with command line options) ⭐ the result of running RtConfig on the Figure 11 source file is shown in Figure 19 in Appendix B 🦋
router bgp 3582
network 128.223.0.0
!
! Start with access-list 100
!
@RtConfig set cisco_access_list_no = 100
!
! NERO
neighbor 198.32.162.2 remote-as 3701
@RtConfig set cisco_map_name = "AS3701-EXPORT"
@RtConfig export AS3582 198.32.162.1 AS3701 198.32.162.2
@RtConfig set cisco_map_name = "AS3701-IMPORT"
@RtConfig import AS3582 198.32.162.1 AS3701 198.32.162.2
!
! WNA/VERIO
neighbor 198.32.162.6 remote-as 2914
@RtConfig set cisco_map_name = "AS2914-EXPORT"
@RtConfig export AS3582 198.32.162.1 AS2914 198.32.162.6
@RtConfig set cisco_map_name = "AS2914-IMPORT"
@RtConfig import AS3582 198.32.162.1 AS2914 198.32.162.6
Figure 11: RtConfig Template FileA RPSL Database Objects ✨
In this appendix we introduce the RPSL objects you need to implement lots of typical Internet routing policies 💖 RFC-2622 and RIPE-157 give the authoritative description of these objects and of the RPSL syntax, but this appendix will often be enough in practice 🌸
The frequently needed objects are:
- maintainer objects (mntner)
- autonomous system number objects (aut-num)
- route objects (route)
- set objects (as-set, route-set)
They're described in the following sections. To make your routing policies and configuration public, these objects should be registered in exactly one of the IRR registries 🎀
In general, you register your info by sending the right objects to the email address for your registry 📧 the email should contain the objects you want registered or modified, separated by empty lines, and start with some kind of authentication details (see below). The registry robot processes your mail and enters new objects, deletes old ones (on request), or makes the requested changes 🫶
You'll get a response that says how your submission went 💅 since emails are handled automatically, the response is usually super fast. BUT remember that a significant number of updates also get submitted to the database (by other robots), so the response time can't be guaranteed 😭 the email addresses for submitting objects to the existing registries are listed in Figure 12 🍓
ANS auto-dbm@ans.net
CANET auto-dbm@canet.net
CW auto-rr@cw.net
RADB auto-dbm@ra.net
RIPE auto-dbm@ripe.net
Figure 12: Email addresses to register policy objects in IRR.Lots of database objects need a maintainer to be specified, so a mntner is usually the first thing you create 🧚 to get it properly authenticated, registry staff add the mntner object manually. After that, all database submissions, deletions and modifications should go through the registry robot 🌈
Each registry can offer extra info and support for users. For the public registries, that support is available from the email addresses in Figure 13 💜
RADB db-admin@ra.net
RIPE ripe-dbm@ripe.net
Figure 13: Support email addresses.If you're using one of the private registries, your service provider should be able to answer your questions ✨
A.1 The Maintainer Object 🔐
okay bestie, the maintainer object is basically the bouncer of the IRR 💅 It brings in some kind of authorization for registrations. It lists various contact persons and describes the security mechanisms that get applied when objects in the IRR are updated. Registering a mntner object is literally step one of creating policies for an AS 🎀 Figure 14 shows one. The maintainer is called MAINT-AS3701. The contact person is the same for admin-c and tech-c stuff, and is referenced by the NIC-handle DMM65. NIC-handles are unique identifiers for persons in registries, so check the registry documentation for more on person objects and how NIC-handles are used 🧚
The example shows two authentication mechanisms: CRYPT-PW and MAIL-FROM. CRYPT-PW takes a password as its argument, and that password is encrypted with the Unix crypt (3) routine. When sending updates, the maintainer adds the field password: <cleartext password> to the beginning of any requests that need to be authenticated 🔑 MAIL-FROM takes a regular expression that covers a set of mail addresses. Only users with any of those mail addresses are authorized to work with objects secured by the corresponding maintainer (3) 💌
The security mechanisms of the mntner object only get applied to objects that reference that specific mntner object. The reference is made by adding the attribute mnt-by to an object, using the name of the mntner object as its value. In Figure 14, MAINT-AS3701 is maintained by itself 🪞
mntner: MAINT-AS3701
descr: Network for Research and Engineering in Oregon
remark: Internal Backbone
admin-c: DMM65
tech-c: DMM65
upd-to: noc@nero.net
auth: CRYPT-PW 949WK1mirBy6c
auth: MAIL-FROM .*@nero.net
notify: noc@nero.net
mnt-by: MAINT-AS3701
changed: meyer@antc.uoregon.edu 970318
source: RADBFigure 14: Maintainer Object
A.2 The Autonomous System Object 🌟
The autonomous system object describes the import and export policies of an AS. Each organization registers an autonomous system object (aut-num) in the IRR for its AS. Figure 15 shows the aut-num for AS3582 (UONET) ✨
The autonomous system object lists contacts (admin-c, tech-c) and is maintained by (mnt-by) MAINT-AS3701, which is the maintainer shown in Figure 14 🔗
The most important attributes of the aut-num object are import and export. The import clause of an aut-num specifies import policies, while the export clause specifies export policies. Together these clauses give a super detailed description of the routing policy of the AS in question. The details are given in section 2 📖
With these clauses, an aut-num object shows its relationship to other autonomous systems by describing its peerings. It also defines a routing entity made up of a group of IP networks that are handled according to the rules in the aut-num object. That's why it's so closely linked to route objects 💕
In this example, AS3582 imports all routes from AS3701 using the keyword ANY. AS3582 imports only internal routes from AS4222, AS5650, and AS1798. The import policy for AS2914 is a little more complex 👀 Since AS2914 provides transit to various other ASes, AS3582 accepts routes with ASPATHs that begin with AS2194, followed by members of AS-WNA. AS-WNA is an as set (see section A.4.1 below) describing those customers that transit AS2914 💅
Since AS3582 is a multi-homed stub AS (i.e., it does not provide transit), its export policy consists simply of "announce AS3582" clauses. That means it announces its internal routes, which are those in route objects where the origin attribute is AS3582 🙌
aut-num: AS3582
as-name: UONET
descr: University of Oregon, Eugene OR
import: from AS3701 accept ANY
import: from AS4222 accept <^AS4222+$>
import: from AS5650 accept <^AS5650+$>
import: from AS2914 accept <^AS2914+ (AS-WNA)*$>
import: from AS1798 accept <^AS1798+$>
export: to AS3701 announce AS3582
export: to AS4222 announce AS3582
export: to AS5650 announce AS3582
export: to AS2914 announce AS3582
export: to AS1798 announce AS3582
admin-c: DMM65
tech-c: DMM65
notify: nethelp@ns.uoregon.edu
mnt-by: MAINT-AS3582
changed: meyer@antc.uoregon.edu 970316
source: RADBFigure 15: Autonomous System Object
The aut-num object forms the basis of a scalable and maintainable router
route: 128.223.0.0/16
origin: AS3582
descr: UONet
descr: University of Oregon
descr: Computing Center
descr: Eugene, OR 97403-1212
descr: USA
mnt-by: MAINT-AS3582
changed: meyer@ns.uoregon.edu 960222
source: RADBFigure 16: Example of a route object
configuration system. For example, if AS3582 originates a new route, it only needs to create a route object for that route with origin AS3582. AS3582 can then build configuration using this route object without changing its aut-num object 🪄
Similarly, if AS3701 originates a new route, it only needs to create a route object for that route with origin AS3701. Both AS3701 and AS3582 can then build configuration using this route object without modifying their aut-num objects 🫶
A.3 The Route Object 🛣️
Unlike aut-num objects, which describe how routing information propagates for an autonomous system as a whole, route objects define single routes from an AS. Figure 16 has an example 🦋
This route object is maintained by MAINT-AS3582 and references AS3582 through the origin attribute. Through that reference it gets grouped together with other routes that have the same origin AS, and becomes part of the routing entity denoted by AS3582. The routing policies can then be defined in the aut-num objects for this group of routes 💜
So route objects give the routes from this AS that get distributed to peer ASes according to the routing policy rules. For any route in the routing tables of the backbone routers, a route object must exist in one of the registries in the IRR. Route objects only need to be registered in the IRR for the routes seen outside your AS 🌍 That set of external routes is usually different from the routes visible inside your AS. One of the big reasons is that external peers don't need any info at all about your internal routing details 🙈 So external routes are generally aggregated combinations of internal routes, with shorter IP prefixes where that applies under the CIDR rules. For a tutorial intro to CIDR, check out the CIDR FAQ [5]. It is strongly recommended that you aggregate your routes as much as possible. That way you minimize the number of routes you inject into the global routing table, and at the same time reduce the number of route objects in the IRR 📉
You can query single route objects with the whois program, and submit objects by mail to the registry robots, but this gets kind of awkward for larger sets 😩 The RAToolSet [6] has several tools that make handling route objects easier 🧰 If you want to read policy data from the IRR and process it with other programs, you might like peval, which is a low level policy evaluation tool. For example, the command
peval -h whois.ra.net AS3582will give you all route objects from AS3582 registered with RADB 📋
A much more sophisticated tool from the RAToolSet for handling route objects interactively is the route object editor, roe 🎨 It has a graphical user interface for viewing and manipulating route objects registered at any IRR. New route objects can be generated from templates and submitted to the registries. You can also compare the route objects in the databases to real-life routes. So roe is highly recommended as an interface to the IRR for route objects 👑 More information on peval and roe is available together with the RAToolSet [6] 💅
A.4 Set Objects 🧁
With routing policies, it's often necessary to reference groups of autonomous systems or routes that have identical properties for a specific policy. To make working with these groups easier, RPSL lets you combine them into set objects. There are two basic predefined types of set objects: as-set and route-set. The RPSL set objects are described below 🫧
A.4.1 AS-SET Object 🌈
Autonomous system set objects (as-set) are used to group autonomous system objects into named sets. An as-set has an RPSL name that starts with "AS-". In the example in Figure 17, an as-set called AS-NERO-PARTNERS is defined, containing AS3701, AS4201, AS3582, AS4222, and AS1798. The as-set is the RPSL replacement for the RIPE-181 as-macro. It has been extended so it can include ASes in the set indirectly, by referencing as set names in the aut-num objects 🔁
AS-SETs are especially useful when specifying policies for groups such as customers, providers, or transit. You're encouraged to register sets for these groups, because you'll most likely treat them alike. You'll probably have a very similar routing policy for all of your customers that have an autonomous system of their own 🤝 You may also discover that this is true for the providers you peer with, and it's really convenient to have the ASes combined in one as-set for which you offer transit. For example, if a transit provider specifies its import policy using its customer's as-set (meaning its import clause for the customer contains the customer's as-set), then that customer can modify the set of ASes that its transit provider accepts from it. Again, this can be done without requiring the customer or the transit provider to modify its aut-num object 🎯
as-set: AS3582:AS-PARTNERS
members: AS3701, AS4201, AS3582, AS4222, AS1798Figure 17: as-set Object
The ASes in the set are simply compiled into a comma-delimited list following the members attribute of the as-set. This list can also contain other AS-SET names 💖
A.4.2. ROUTE-SET Object 🌸
A route-set is a way to give a whole bunch of routes one name, and the syntax is basically the same as the as-set 💅. Its RPSL name starts with "RS-", and its members attribute lists what's in the set. Each value is either an address prefix or the name of another route-set, and those are the members you get.
Figure 18 has some examples. rs-uo holds two prefixes, 128.223.0.0/16 and 198.32.162.0/24. rs-bar is bigger: it has everything in rs-uo plus 128.7.0.0/16. Then there's rs-martians, which is the fun one because it shows off range operators 🍓. 0.0.0.0/0^32 means the length-32 more specifics of 0.0.0.0/0, so basically the host routes. 224.0.0.0/3^+ means the more specifics of 224.0.0.0/3, which are the routes sitting in the multicast address space 🦋. If you want the full list of range operators, go check RFC-2622.
route-set: rs-uo
members: 128.223.0.0/16, 198.32.162.0/24
route-set: rs-bar
members: 128.7.0.0/16, rs-uo
route-set: rs-martians
remarks: routes not accepted from any peer
members: 0.0.0.0/0, # default route
0.0.0.0/0^32, # host routes
224.0.0.0/3^+, # multicast routes
127.0.0.0/8^9-32, . . .Figure 18: route-set Objects ✨
B Output of RtConfig: An Example 🎀
In Figure 19 you can see what RtConfig spits out when you run it on the source file from Figure 11. Iconic output, honestly 👑
router bgp 3582
network 128.223.0.0
!
! NERO
neighbor 198.32.162.2 remote-as 3701
no access-list 100
access-list 100 permit ip 128.223.0.0 0.0.0.0 255.255.0.0 0.0.0.0
access-list 100 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
!
no route-map AS3701-EXPORT
route-map AS3701-EXPORT permit 1
match ip address 100
!
router bgp 3582
neighbor 198.32.162.2 route-map AS3701-EXPORT out
!
no route-map AS3701-IMPORT
route-map AS3701-IMPORT permit 1
set local-preference 1000
!
router bgp 3582
neighbor 198.32.162.2 route-map AS3701-IMPORT in
!
! WNA/VERIO
neighbor 198.32.162.6 remote-as 2914
!
no route-map AS2914-EXPORT
route-map AS2914-EXPORT permit 1
match ip address 100
!
router bgp 3582
neighbor 198.32.162.6 route-map AS2914-EXPORT out
no ip as-path access-list 100
ip as-path access-list 100 permit ^_2914(((_[0-9]+))*_ \
(13|22|97|132|175|668|1914|2905|2914|3361|3381|3791|3937| \
4178|4354|4571|4674|4683|5091|5303|5798|5855|5856|5881|6083 \
|6188|6971|7790|7951|8028))?$
!
no route-map AS2914-IMPORT
route-map AS2914-IMPORT permit 1
match as-path 100
set local-preference 998
!
router bgp 3582
neighbor 198.32.162.6 route-map AS2914-IMPORT inFigure 19: Output of RtConfig 💖
Security Considerations 🔐
This document is a tutorial to RPSL. It doesn't define any protocols or standards that need securing, so there's nothing here to lock down 🫶
Endnotes 📝
(1) The AS-PATH regular expressions are POSIX compliant regular expressions.
(2) Digging into RtConfig's internals is beyond the scope of this document, so we're skipping that bit 🙈
(3) Clearly, neither of these mechanisms is enough for strong authentication or authorization 😭 Other public key authentication mechanisms (like PGP) are available from some of the IRRs, so go look there if you need them.
References 📚
[1] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999.
[2] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P. and M. Terpstra, "Representation of IP Routing Policies in the RIPE database", Technical Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993.
[3] T. Bates, E. Gerich, J. Joncharay, J-M. Jouanigot, D. Karrenberg, M. Terpstra, and J. Yu. Representation of IP Routing Policies in a Routing Registry, Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.
[4] A. M. R. Magee. RIPE NCC Database Documentation. Technical Report RIPE-157, RIPE NCC, Amsterdam, Netherlands, May 1997.
[5] Hank Nussbacher. The CIDR FAQ. Tel Aviv University and IBM Israel. http://www.ibm.net.il/~hank/cidr.html
[6] The RAToolSet. http://www.ra.net/ra/RAToolSet/
[7] Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1654, July 1994.
[8] RtConfig as part of the RAToolSet. http://www.ra.net/ra/RAToolSet/RtConfig.html
[9] Chen, E. and T. Bates, "An Application of the BGP Community Attribute in Multi-Home Routing", RFC 1998, August 1996.
Authors' Addresses 💌
David Meyer Cisco Systems EMail: dmm@cisco.com
Joachim Schmitz America On-Line EMail: SchmitzJo@aol.com
Carol Orange RIPE NCC EMail: orange@spiritone.com
Mark Prior connect.com.au pty ltd EMail: mrp@connect.com.au
Cengiz Alaettinoglu USC/Information Sciences Institute EMail: cengiz@isi.edu
Full Copyright Statement ©
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc2650 1999-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms