RFC 2280 (rfc2280) - Page 3 of 53
Routing Policy Specification Language (RPSL)
Alternative Format: Original Text Document
RFC 2280 RPSL January 1998 RPSL was designed so that a view of the global routing policy can be contained in a single cooperatively maintained distributed database to improve the integrity of Internet's routing. RPSL is not designed to be a router configuration language. RPSL is designed so that router configurations can be generated from the description of the policy for one autonomous system (aut-num class) combined with the description of a router (inet-rtr class), mainly providing router ID, autonomous system number of the router, interfaces and peers of the router, and combined with a global database mappings from AS sets to ASes (as-set class), and from origin ASes and route sets to route prefixes (route and route-set classes). The accurate population of the RPSL database can help contribute toward such goals as router configurations that protect against accidental (or malicious) distribution of inaccurate routing information, verification of Internet's routing, and aggregation boundaries beyond a single AS. RPSL is object oriented; that is, objects contain pieces of policy and administrative information. These objects are registered in the Internet Routing Registry (IRR) by the authorized organizations. The registration process is beyond the scope of this document. Please refer to [1, 15, 2] for more details on the IRR. In the following sections, we present the classes that are used to define various policy and administrative objects. The "mntner" class defines entities authorized to add, delete and modify a set of objects. The "person" and "role" classes describes technical and administrative contact personnel. Autonomous systems (ASes) are specified using the "aut-num" class. Routes are specified using the "route" class. Sets of ASes and routes can be defined using the "as-set" and "route-set" classes. The "dictionary" class provides the extensibility to the language. The "inet-rtr" class is used to specify routers. Many of these classes were originally defined in earlier documents [4, 11, 14, 10, 3] and have all been enhanced. This document is self-contained. However, the reader is encouraged to read RIPE-181 [5] and the associated documents [11, 14, 10, 3] as they provide significant background as to the motivation and underlying principles behind RIPE-181 and consequently, RPSL. For a tutorial on RPSL, the reader should read the RPSL applications document [2]. 2 RPSL Names, Reserved Words, and Representation Each class has a set of attributes which store a piece of information about the objects of the class. Attributes can be mandatory or optional: A mandatory attribute has to be defined for all objects of Alaettinoglu, et. al. Standards Track



