RFC 2622: Routing Policy Specification Language (RPSL)
- C. Alaettinoglu,
- C. Villamizar,
- E. Gerich,
- D. Kessens,
- D. Meyer,
- T. Bates,
- D. Karrenberg,
- M. Terpstra
Proposed Standard
Network Working Group C. Alaettinoglu Request for Comments: 2622 USC/Information Sciences Institute Obsoletes: 2280 C. Villamizar Category: Standards Track Avici Systems E. Gerich At Home Network D. Kessens Qwest Communications D. Meyer University of Oregon T. Bates Cisco Systems D. Karrenberg RIPE NCC M. Terpstra Bay Networks June 1999 Routing Policy Specification Language (RPSL) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. Alaettinoglu, et al. Standards Track [Page 1]
RFC 2622 RPSL June 1999 Table of Contents 1 Introduction 3 2 RPSL Names, Reserved Words, and Representation 4 3 Contact Information 7 3.1 mntner Class . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 person Class . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 role Class . . . . . . . . . . . . . . . . . . . . . . . . . 11 4 route Class 12 5 Set Classes 13 5.1 as-set Class . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2 route-set Class. . . . . . . . . . . . . . . . . . . . . . . 15 5.3 Predefined Set Objects . . . . . . . . . . . . . . . . . . . 17 5.4 Filters and filter-set Class . . . . . . . . . . . . . . . . 17 5.5 rtr-set Class. . . . . . . . . . . . . . . . . . . . . . . . 22 5.6 Peerings and peering-set Class . . . . . . . . . . . . . . . 24 6 aut-num Class 27 6.1 import Attribute: Import Policy Specification . . . . . . . 27 6.1.1 Action Specification . . . . . . . . . . . . . . . . . . 28 6.2 export Attribute: Export Policy Specification . . . . . . . 29 6.3 Other Routing Protocols, Multi-Protocol Routing Protocols, and Injecting Routes Between Protocols . . . . . . . . . . . . 29 6.4 Ambiguity Resolution . . . . . . . . . . . . . . . . . . . . 31 6.5 default Attribute: Default Policy Specification . . . . . . 33 6.6 Structured Policy Specification. . . . . . . . . . . . . . . 33 7 dictionary Class 37 7.1 Initial RPSL Dictionary and Example Policy Actions and Filters. . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 8 Advanced route Class 45 8.1 Specifying Aggregate Routes. . . . . . . . . . . . . . . . . 45 8.1.1Interaction with policies in aut-num class. . . . . . . . 49 8.1.2Ambiguity resolution with overlapping aggregates. . . . . 50 8.2 Specifying Static Routes . . . . . . . . . . . . . . . . . . 52 9 inet-rtr Class 52 10 Extending RPSL 54 10.1 Extensions by changing the dictionary class . . . . . . . . 54 10.2 Extensions by adding new attributes to existing classes . . 55 10.3 Extensions by adding new classes . . . . . . . . . . . . . 55 10.4 Extensions by changing the syntax of existing RPSL attributes. . . . . . . . . . . . . . . . . . . . . . . . . . 55 11 Security Considerations 56 12 Acknowledgements 56 References 56 A Routing Registry Sites 59 B Grammar Rules 59 C Changes from RFC 2280 67 D Authors' Addresses 68 Full Copyright Statement 69 Alaettinoglu, et al. Standards Track [Page 2]
RFC 2622 RPSL June 1999 1 Introduction This memo is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. RPSL is a replacement for the current Internet policy specification language known as RIPE-181 [6] or RFC-1786 [7]. RIPE-81 [8] was the first language deployed in the Internet for specifying routing policies. It was later replaced by RIPE-181 [6]. Through operational use of RIPE-181 it has become apparent that certain policies cannot be specified and a need for an enhanced and more generalized language is needed. RPSL addresses RIPE-181's limitations. 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, 17, 4] 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 Alaettinoglu, et al. Standards Track [Page 3]
RFC 2622 RPSL June 1999 "route" class. Sets of objects can be defined using the "as-set", "route-set", "filter-set", "peering-set", and "rtr-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 [6, 13, 16, 12, 5] and have all been enhanced. This document is self-contained. However, the reader is encouraged to read RIPE-181 [7] and the associated documents [13, 16, 12, 5] 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 [4]. 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 the class; optional attributes can be skipped. Attributes can also be single or multiple valued. Each object is uniquely identified by a set of attributes, referred to as the class "key". The value of an attribute has a type. The following types are most widely used. Note that RPSL is case insensitive and only the characters from the ASCII character set can be used. <object-name> Many objects in RPSL have a name. An <object-name> is made up of letters, digits, the character underscore "_", and the character hyphen "-"; the first character of a name must be a letter, and the last character of a name must be a letter or a digit. The following words are reserved by RPSL, and they can not be used as names: any as-any rs-any peeras and or not atomic from to at action accept announce except refine networks into inbound outbound Names starting with certain prefixes are reserved for certain object types. Names starting with "as-" are reserved for as set names. Names starting with "rs-" are reserved for route set names. Names starting with "rtrs-" are reserved for router set names. Names starting with "fltr-" are reserved for filter set names. Names starting with "prng-" are reserved for peering set names. Alaettinoglu, et al. Standards Track [Page 4]
RFC 2622 RPSL June 1999 <as-number> An AS number x is represented as the string "ASx". That is, the AS 226 is represented as AS226. <ipv4-address> An IPv4 address is represented as a sequence of four integers in the range from 0 to 255 separated by the character dot ".". For example, 128.9.128.5 represents a valid IPv4 address. In the rest of this document, we may refer to IPv4 addresses as IP addresses. <address-prefix> An address prefix is represented as an IPv4 address followed by the character slash "/" followed by an integer in the range from 0 to 32. The following are valid address prefixes: 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the following address prefixes are invalid: 0/0, 128.9/16 since 0 or 128.9 are not strings containing four integers. <address-prefix-range> An address prefix range is an address prefix followed by an optional range operator. The range operators are: ^- is the exclusive more specifics operator; it stands for the more specifics of the address prefix excluding the address prefix itself. For example, 128.9.0.0/16^- contains all the more specifics of 128.9.0.0/16 excluding 128.9.0.0/16. ^+ is the inclusive more specifics operator; it stands for the more specifics of the address prefix including the address prefix itself. For example, 5.0.0.0/8^+ contains all the more specifics of 5.0.0.0/8 including 5.0.0.0/8. ^n where n is an integer, stands for all the length n specifics of the address prefix. For example, 30.0.0.0/8^16 contains all the more specifics of 30.0.0.0/8 which are of length 16 such as 30.9.0.0/16. ^n-m where n and m are integers, stands for all the length n to length m specifics of the address prefix. For example, 30.0.0.0/8^24-32 contains all the more specifics of 30.0.0.0/8 which are of length 24 to 32 such as 30.9.9.96/28. Range operators can also be applied to address prefix sets. In this case, they distribute over the members of the set. For example, for a route-set (defined later) rs-foo, rs-foo^+ contains all the inclusive more specifics of all the prefixes in rs-foo. It is an error to follow a range operator with another one (e.g. 30.0.0.0/8^24-28^+ is an error). However, a range operator can be applied to an address prefix set that has address prefix ranges in it (e.g. {30.0.0.0/8^24-28}^27-30 is not an error). In this case, the Alaettinoglu, et al. Standards Track [Page 5]
RFC 2622 RPSL June 1999 outer operator ^n-m distributes over the inner operator ^k-l and becomes the operator ^max(n,k)-m if m is greater than or equal to max(n,k), or otherwise, the prefix is deleted from the set. Note that the operator ^n is equivalent to ^n-n; prefix/l^+ is equivalent to prefix/l^l-32; prefix/l^- is equivalent to prefix/l^(l+1)-32; {prefix/l^n-m}^+ is equivalent to {prefix/l^n-32}; and {prefix/l^n- m}^- is equivalent to {prefix/l^(n+1)-32}. For example, {128.9.0.0/16^+}^- == {128.9.0.0/16^-} {128.9.0.0/16^-}^+ == {128.9.0.0/16^-} {128.9.0.0/16^17}^24 == {128.9.0.0/16^24} {128.9.0.0/16^20-24}^26-28 == {128.9.0.0/16^26-28} {128.9.0.0/16^20-24}^22-28 == {128.9.0.0/16^22-28} {128.9.0.0/16^20-24}^18-28 == {128.9.0.0/16^20-28} {128.9.0.0/16^20-24}^18-22 == {128.9.0.0/16^20-22} {128.9.0.0/16^20-24}^18-19 == {} <date> A date is represented as an eight digit integer of the form YYYYMMDD where YYYY represents the year, MM represents the month of the year (01 through 12), and DD represents the day of the month (01 through 31). All dates are in UTC unless otherwise specified. For example, June 24, 1996 is represented as 19960624. <email-address>is as described in RFC-822 [10]. <dns-name>is as described in RFC-1034 [17]. <nic-handle> is a uniquely assigned identifier word used by routing, address allocation, and other registries to unambiguously refer to contact information. Person and role classes map NIC handles to actual person names, and contact information. <free-form>is a sequence of ASCII characters. <X-name> is a name of an object of type X. That is <mntner-name> is a name of a mntner object. <registry-name> is a name of an IRR registry. The routing registries are listed in Appendix A. A value of an attribute may also be a list of one of these types. A list is represented by separating the list members by commas ",". For example, "AS1, AS2, AS3, AS4" is a list of AS numbers. Note that being list valued and being multiple valued are orthogonal. A multiple valued attribute has more than one value, each of which may or may not be a list. On the other hand a single valued attribute may have a list value. Alaettinoglu, et al. Standards Track [Page 6]
RFC 2622 RPSL June 1999 An RPSL object is textually represented as a list of attribute-value pairs. Each attribute-value pair is written on a separate line. The attribute name starts at column 0, followed by character ":" and followed by the value of the attribute. The attribute which has the same name as the object's class should be specified first. The object's representation ends when a blank line is encountered. An attribute's value can be split over multiple lines, by having a space, a tab or a plus ('+') character as the first character of the continuation lines. The character "+" for line continuation allows attribute values to contain blank lines. More spaces may optionally be used after the continuation character to increase readability. The order of attribute-value pairs is significant. An object's description may contain comments. A comment can be anywhere in an object's definition, it starts at the first "#" character on a line and ends at the first end-of-line character. White space characters can be used to improve readability. An integer can be specified using (1) the C programming language notation (e.g. 1, 12345); (2) sequence of four 1-octet integers (in the range from 0 to 255) separated by the character dot "." (e.g. 1.1.1.1, 255.255.0.0), in this case a 4-octet integer is formed by concatenating these 1-octet integers in the most significant to least significant order; (3) sequence of two 2-octet integers (in the range from 0 to 65535) separated by the character colon ":" (e.g. 3561:70, 3582:10), in this case a 4-octet integer is formed by concatenating these 2-octet integers in the most significant to least significant order. 3 Contact Information The mntner, person and role classes, admin-c, tech-c, mnt-by, changed, and source attributes of all classes describe contact information. The mntner class also specifies authenticaiton information required to create, delete and update other objects. These classes do not specify routing policies and each registry may have different or additional requirements on them. Here we present the common denominator for completeness which is the RIPE database implementation [16]. Please consult your routing registry for the latest specification of these classes and attributes. The "Routing Policy System Security" document [20] describes the authenticaiton and authorization model in more detail. 3.1 mntner Class The mntner class specifies authenticaiton information required to create, delete and update RPSL objects. A provider, before he/she can create RPSL objects, first needs to create a mntner object. The Alaettinoglu, et al. Standards Track [Page 7]
RFC 2622 RPSL June 1999 attributes of the mntner class are shown in Figure 1. The mntner class was first described in [13]. The mntner attribute is mandatory and is the class key. Its value is an RPSL name. The auth attribute specifies the scheme that will be used to identify and authenticate update requests from this maintainer. It has the following syntax: auth: <scheme-id> <auth-info> E.g. auth: NONE Attribute Value Type mntner <object-name> mandatory, single-valued, class key descr <free-form> mandatory, single-valued auth see description in text mandatory, multi-valued upd-to <email-address> mandatory, multi-valued mnt-nfy <email-address> optional, multi-valued tech-c <nic-handle> mandatory, multi-valued admin-c <nic-handle> optional, multi-valued remarks <free-form> optional, multi-valued notify <email-address> optional, multi-valued mnt-by list of <mntner-name> mandatory, multi-valued changed <email-address> <date> mandatory, multi-valued source <registry-name> mandatory, single-valued Figure 1: mntner Class Attributes auth: CRYPT-PW dhjsdfhruewf auth: MAIL-FROM .*@ripe\.net The <scheme-id>'s currently defined are: NONE, MAIL-FROM, PGP-KEY and CRYPT-PW. The <auth-info> is additional information required by a particular scheme: in the case of MAIL-FROM, it is a regular expression matching valid email addresses; in the case of CRYPT-PW, it is a password in UNIX crypt format; and in the case of PGP-KEY, it is a pointer to key-certif object [22] containing the PGP public key of the user. If multiple auth attributes are specified, an update request satisfying any one of them is authenticated to be from the maintainer. The upd-to attribute is an email address. On an unauthorized update attempt of an object maintained by this maintainer, an email message will be sent to this address. The mnt-nfy attribute is an email address. A notification message will be forwarded to this email Alaettinoglu, et al. Standards Track [Page 8]
RFC 2622 RPSL June 1999 address whenever an object maintained by this maintainer is added, changed or deleted. The descr attribute is a short, free-form textual description of the object. The tech-c attribute is a technical contact NIC handle. This is someone to be contacted for technical problems such as misconfiguration. The admin-c attribute is an administrative contact NIC handle. The remarks attribute is a free text explanation or clarification. The notify attribute is an email address to which notifications of changes to this object should be sent. The mnt-by attribute is a list of mntner object names. The authorization for changes to this object is governed by any of the maintainer objects referenced. The changed attribute documents who last changed this object, and when this change was made. Its syntax has the following form: changed: <email-address> <YYYYMMDD> E.g. changed: johndoe@terabit-labs.nn 19900401 The <email-address> identifies the person who made the last change. <YYYYMMDD> is the date of the change. The source attribute specifies the registry where the object is registered. Figure 2 shows an example mntner object. In the example, UNIX crypt format password authentication is used. mntner: RIPE-NCC-MNT descr: RIPE-NCC Maintainer admin-c: DK58 tech-c: OPS4-RIPE upd-to: ops@ripe.net mnt-nfy: ops-fyi@ripe.net auth: CRYPT-PW lz1A7/JnfkTtI mnt-by: RIPE-NCC-MNT changed: ripe-dbm@ripe.net 19970820 source: RIPE Figure 2: An example mntner object. The descr, tech-c, admin-c, remarks, notify, mnt-by, changed and source attributes are attributes of all RPSL classes. Their syntax, semantics, and mandatory, optional, multi-valued, or single-valued status are the same for for all RPSL classes. Only exception to this is the admin-c attribute which is mandatory for the aut-num class. We do not further discuss them in other sections. Alaettinoglu, et al. Standards Track [Page 9]
RFC 2622 RPSL June 1999 3.2 person Class A person class is used to describe information about people. Even though it does not describe routing policy, we still describe it here briefly since many policy objects make reference to person objects. The person class was first described in [15]. The attributes of the person class are shown in Figure 3. The person attribute is the full name of the person. The phone and the fax-no attributes have the following syntax: phone: +<country-code> <city> <subscriber> [ext. <extension>] E.g.: phone: +31 20 12334676 Attribute Value Type person <free-form> mandatory, single-valued nic-hdl <nic-handle> mandatory, single-valued, class key address <free-form> mandatory, multi-valued phone see description in text mandatory, multi-valued fax-no same as phone optional, multi-valued e-mail <email-address> mandatory, multi-valued Figure 3: person Class Attributes phone: +44 123 987654 ext. 4711 Figure 4 shows an example person object. person: Daniel Karrenberg address: RIPE Network Coordination Centre (NCC) address: Singel 258 address: NL-1016 AB Amsterdam address: Netherlands phone: +31 20 535 4444 fax-no: +31 20 535 4445 e-mail: Daniel.Karrenberg@ripe.net nic-hdl: DK58 changed: Daniel.Karrenberg@ripe.net 19970616 source: RIPE Figure 4: An example person object. Alaettinoglu, et al. Standards Track [Page 10]
RFC 2622 RPSL June 1999