idnits 2.17.1 draft-ietf-rps-rpsl-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 583 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 819 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 116 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1496: '... MANDATORY | OPTIONAL (<...' RFC 2119 keyword, line 1498: '... MANDATORY | OPTIONAL (<...' RFC 2119 keyword, line 1500: '...otocol; MANDATORY and OPTIONAL are...' RFC 2119 keyword, line 1579: '... OPTIONAL flap_damp()...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 22 has weird spacing: '... Draft is t...' == Line 23 has weird spacing: '...be able to...' == Line 24 has weird spacing: '...cies at vario...' == Line 25 has weird spacing: '...l. At the s...' == Line 26 has weird spacing: '...ecified with ...' == (578 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 30, 1997) is 9739 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 1566, but not defined == Missing Reference: '65535' is mentioned on line 1566, but not defined == Missing Reference: '4294967200' is mentioned on line 1533, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-06) exists of draft-ietf-rps-appl-rpsl-00 ** Downref: Normative reference to an Informational draft: draft-ietf-rps-appl-rpsl (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 1786 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: A later version (-07) exists of draft-ietf-ipngwg-ipv6-tunnel-04 ** Obsolete normative reference: RFC 822 (ref. '11') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2065 (ref. '12') (Obsoleted by RFC 2535) -- Possible downref: Non-RFC (?) normative reference: ref. '13' ** Obsolete normative reference: RFC 1933 (ref. '14') (Obsoleted by RFC 2893) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '15') ** Downref: Normative reference to an Experimental draft: draft-harney-gkmp-arch (ref. '16') -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' == Outdated reference: A later version (-05) exists of draft-ietf-mboned-admin-ip-space-01 == Outdated reference: A later version (-11) exists of draft-ietf-idmr-dvmrp-v3-03 ** Downref: Normative reference to an Informational draft: draft-ietf-idmr-dvmrp-v3 (ref. '25') -- Possible downref: Non-RFC (?) normative reference: ref. '26' -- Possible downref: Non-RFC (?) normative reference: ref. '27' ** Obsolete normative reference: RFC 1771 (ref. '28') (Obsoleted by RFC 4271) ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. '29') Summary: 22 errors (**), 0 flaws (~~), 17 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Cengiz Alaettinoglu 3 Expires January 30, 1998 USC/ISI 4 draft-ietf-rps-rpsl-03.txt Tony Bates 5 Cisco Systems 6 Elise Gerich 7 At Home Network 8 Daniel Karrenberg 9 RIPE 10 David Meyer 11 University of Oregon 12 Marten Terpstra 13 Bay Networks 14 Curtis Villamizer 15 ANS 16 July 30, 1997 18 Routing Policy Specification Language (RPSL) 20 Status of this Memo 22 This Internet Draft is the reference document for the Routing Policy 23 Specification Language (RPSL). RPSL allows a network operator to be able to 24 specify routing policies at various levels in the Internet hierarchy; for 25 example at the Autonomous System (AS) level. At the same time, policies 26 can be specified with sufficient detail in RPSL so that low level router 27 configurations can be generated from them. RPSL is extensible; new routing 28 protocols and new protocol features can be introduced at any time. 30 This document is an Internet Draft, and can be found as draft-ietf-rps-rpsl- 31 03.txt in any standard internet drafts repository. Internet Drafts are 32 working documents of the Internet Engineering Task Force (IETF), its Areas, 33 and its Working Groups. Note that other groups may also distribute working 34 documents as Internet Drafts. 36 Internet Drafts are draft documents valid for a maximum of six months. 37 Internet Drafts may be updated, replaced, or obsoleted by other documents 38 at any time. It is not appropriate to use Internet Drafts as reference 39 material, or to cite them other than as a ``working draft'' or ``work in 40 progress.'' 42 Please check the I-D abstract listing contained in each Internet Draft 43 directory to learn the current status of this or any other Internet Draft. 45 Contents 47 1 Introduction 4 49 2 RPSL Names, Reserved Words, and Representation 5 51 3 mntner Class 6 53 4 person Class 8 55 5 route Class 9 57 6 Set Classes 10 59 6.1 route-set Class . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 6.2 as-set Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 6.3 Predefined Set Objects . . . . . . . . . . . . . . . . . . . . . . 13 65 6.4 Hierarchical Set Names . . . . . . . . . . . . . . . . . . . . . . 13 67 7 aut-num Class 14 69 7.1 import Attribute: Import Policy Specification . . . . . . . . . . . 14 71 7.1.1Peering Specification . . . . . . . . . . . . . . . . . . . . . 15 73 7.1.2Action Specification . . . . . . . . . . . . . . . . . . . . . . 17 75 7.1.3Filter Specification . . . . . . . . . . . . . . . . . . . . . . 17 77 7.1.4Example Policy Expressions . . . . . . . . . . . . . . . . . . . 21 79 7.2 export Attribute: Export Policy Specification . . . . . . . . . . . 21 81 7.3 Other Routing Protocols, Multi-Protocol Routing Protocols, and 82 Injecting Routes Between Protocols . . . . . . . . . . . . . . . . . 22 84 7.4 Ambiguity Resolution . . . . . . . . . . . . . . . . . . . . . . . 23 86 7.5 default Attribute: Default Policy Specification . . . . . . . . . . 25 88 7.6 Structured Policy Specification . . . . . . . . . . . . . . . . . . 26 90 8 dictionary Class 30 91 8.1 Initial RPSL Dictionary and Example Policy Actions and Filters . . 33 93 9 Advanced route Class 37 95 9.1 Specifying Static Routes . . . . . . . . . . . . . . . . . . . . . 37 97 9.2 Specifying Aggregate Routes . . . . . . . . . . . . . . . . . . . . 38 99 10inet-rtr Class 39 101 11inet-tunnel Class and Specifying Tunnels 41 103 12Security Consideration 42 105 13Acknowledgements 44 107 A Routing Registry Sites 46 109 B Authors' Addresses 46 110 1 Introduction 112 This Internet Draft is the reference document for the Routing Policy 113 Specification Language (RPSL). RPSL allows a network operator to be able to 114 specify routing policies at various levels in the Internet hierarchy; for 115 example at the Autonomous System (AS) level. At the same time, policies 116 can be specified with sufficient detail in RPSL so that low level router 117 configurations can be generated from them. RPSL is extensible; new routing 118 protocols and new protocol features can be introduced at any time. 120 RPSL is a replacement for the current Internet de-facto standard routing 121 policy specification language known as RIPE-181 [6] or RFC-1786 [7]. 122 RIPE-81 [8] was the first language deployed in the Internet for specifying 123 routing policies. It was later replaced by RIPE-181 [6]. 125 Through operational use of RIPE-181 it has become apparent that certain 126 policies cannot be specified and a need for an enhanced and more generalized 127 language is needed. RPSL addresses RIPE-181's limitations. RPSL is object 128 oriented; that is, objects contain pieces of policy and administrative 129 information. These objects are registered in the Internet Routing Registry 130 (IRR) by the authorized organizations. The registration process is beyond 131 the scope of this document. Please refer to [2, 21, 4] for more details on 132 the IRR. 134 RPSL was designed so that a view of the global routing policy can be 135 contained in a single cooperatively maintained distributed database to 136 improve the integrety of Internet's routing. RPSL is not designed to 137 be a router configuration language. RPSL is designed so that router 138 configurations can be generated from the description of the policy for one 139 automomous system (see aut-num class) combined with the description of a 140 router (see inet-rtr class), mainly providing router ID, autonomous system 141 number of the router, interfaces and peers of the router, and combined 142 with a global database mappings AS sets to ASes (see as-set class), origin 143 ASes and route sets to route prefixes. (see route and route-set classes), 144 The accurate population of the RPSL database can help contribute toward 145 such goals as router configurations which protect against accidental (or 146 malicious) distribution of inaccurate routing information and contribute 147 toward the verification of Internet's routing and aggregation boundaries 148 beyond a single AS. 150 In the following sections, we present the classes that are used to define 151 various policy and administrative objects. The "mntner" class defines 152 entities authorized to add, delete and modify a set of objects. The 153 "person" class describes technical and administrative contact personnel. 154 Autonomous systems (ASes) are specified using the "aut-num" class. Routes 155 are specified using the "route" class. Sets of ASes and routes can be 156 defined using the "as-set" and "route-set" classes. The "dictionary" 157 class provides the extensibility to the language. The "inet-rtr" class 158 is used to specify routers. Tunnels are specified using "inet-tunnel" 159 class. Many of these classes were originally defined in earlier documents 160 [6, 18, 20, 17, 5] and have all been enhanced. 162 This document is self-contained. However, the reader is encouraged to read 163 RIPE-181 [7] and the associated documents [18, 20, 17, 5] as they provide 164 significant background as to the motivation and underlying principles behind 165 RIPE-181 and consequently, RPSL. They further cover the basic concept of 166 the Internet Routing Registry (IRR) [2, 21, 4], the data repository for 167 storing global RPSL based routing policies and a fundamental component in 168 the application of RPSL. For a tutorial on RPSL, the reader should read the 169 RPSL applications document [4]. 171 2 RPSL Names, Reserved Words, and Representation 173 Each class has a set of attributes which store a piece of information about 174 the objects of the class. Attributes can be mandatory or optional: A 175 mandatory attribute has to be defined for all objects of the class; optional 176 attributes can be skipped. Attributes can also be single or multiple 177 valued. Each object is uniquely identified by a set of attributes, referred 178 to as the class ``key''. 180 The value of an attribute has a type. The following types are most widely 181 used. Note that RPSL is case insensitive. 183 Many objects in RPSL have a name. An is made 184 up of letters, digits, the character underscore ``_'', and the character 185 hyphen ``-''; the first character of a name must be a letter, and the 186 last character of a name must be a letter or a digit. The following 187 words are reserved by RPSL, and they can not be used as names: 189 any as-any rs-any peeras 190 and or not 191 atomic from to at action accept announce except refine 192 networks into 194 Names starting with certain prefixes are reserved for certain object 195 types. Names starting with ``as-'' are reserved for as set names. 196 Names starting with ``rs-'' are reserved for route set names. 198 An AS number x is represented as the string ``ASx''. That is, 199 the AS 226 is represented as AS226. 201 An IPv4 address is represented as a sequence of four integers 202 in the range from 0 to 255 separated by the character dot ``.''. For 203 example, 128.9.128.5 represents a valid IPv4 address. In the rest of 204 this document, we may refer to IPv4 addresses as IP addresses. 206 An address prefix is represented as an IPv4 address 207 followed by the character slash ``/'' followed by an integer in the 208 range from 0 to 32. The following are valid address prefixes: 209 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the following address 210 prefixes are invalid: 0/0, 128.9/16 since 0 or 128.9 are not strings 211 containing four integers. 213 A date is represented as an eight digit integer of the form YYYYMMDD 214 where YYYY represents the year, MM represents the month of the year (01 215 through 12), and DD represents the day of the month (01 through 31). 216 For example, June 24, 1996 is represented as 19960624. 218 is as described in RFC-822[11]. 220 is as described in RFC-1034[23]. 222 is either a full name of a person or a uniquely assigned 223 NIC-handle. Its syntax has the following form: 225 [] 226 | 228 E.g. 229 John E Doe 230 JED31 232 A NIC handle is an identifier used by routing, address allocation, and 233 other registries to unambiguously refer to people. 235 is a sequence of ASCII characters. 237 is a name of an object of type X. That is is a name 238 of an mntner object. 240 is a name of an IRR registry. The routing registries are 241 listed in Appendix A. 243 A value of an attribute may also be a lists of one of these types. A list 244 is represented by separating the list members by commas ``,''. For example, 245 ``AS1, AS2, AS3, AS4'' is a list of AS numbers. Note that being list valued 246 and being multiple valued are orthogonal. A multiple valued attribute has 247 more than one value each of which may or may not be a list depending on 248 the attribute. On the other hand a single valued attribute may have a list 249 value. 251 An RPSL object is textually represented as a list of attribute-value pairs. 252 Each attribute-value pair is written on a separate line. The attribute name 253 starts at column 0, followed by character ``:'' and followed by the value 254 of the attribute. The object's representation ends when a blank line is 255 encountered. An attribute's value can be split over multiple lines, by 256 starting the continuation lines with a white-space (`` '' or tab) character. 257 The order of attribute-value pairs is significant. 259 An object's description may contain comments. A comment can be anywhere in 260 an object's definition, it starts at the first ``#'' character on a line and 261 ends at the first end-of-line character. White space characters can be used 262 to improve readability. 264 3 mntner Class 266 The mntner class defines entities that can create, delete and update RPSL 267 objects. A provider, before he/she can create any RPSL object, first needs 268 to create a mntner object. The attributes of the mntner class are shown in 269 Figure 1. The mntner class was first described in [18]. 271 Attribute Value Type 272 mntner mandatory, single-valued, class key 273 descr mandatory, single-valued 274 auth see description in text mandatory, multi-valued 275 upd-to mandatory, multi-valued 276 mnt-nfy optional, multi-valued 277 tech-c mandatory, multi-valued 278 admin-c mandatory, multi-valued 279 remarks optional, multi-valued 280 notify optional, multi-valued 281 mnt-by list of mandatory, multi-valued 282 changed mandatory, multi-valued 283 source mandatory, single-valued 285 Figure 1: mntner Class Attributes 287 The mntner attribute is mandatory and is the class key attribute. Its value 288 is an RPSL name. The auth attribute specifies the scheme that will be used 289 to identify and authenticate update requests from this maintainer. It has 290 the following syntax: 292 auth: 294 E.g. 295 auth: NONE 296 auth: CRYPT-PW dhjsdfhruewf 297 auth: MAIL-FROM .*@ripe\.net 299 The 's currently defined are: NONE, MAIL-FROM, PGP and CRYPT-PW. 300 The is additional information required by a particular scheme: 301 in the case of MAIL-FROM, it is a regular expression matching valid email 302 addresses; in the case of CRYPT-PW, it is a password in UNIX crypt format; 303 and in the case of PGP, it is a PGP public key. If multiple auth attributes 304 are specified, an update request satisfying any one of them is authenticated 305 to be from the maintainer. 307 The upd-to attribute is an email address. On an unauthorized update 308 attempt of an object maintained by this maintainer, an email message will 309 be sent to this address. The mnt-nfy attribute is an email address. A 310 notification message will be forwarded to this email address whenever an 311 object maintained by this maintainer is added, changed or deleted. 313 The descr attribute is a short, free-form textual description of the object. 314 The tech-c attribute is a technical contact person. This is someone to 315 be contacted for technical problems such as misconfiguration. The admin-c 316 attribute is an administrative contact person. The remarks attribute is a 317 free text explanation or clarification. The notify attribute is an email 318 address to which notifications of changes to this object should be sent. 319 The mnt-by attribute is a list of mntner object names. The authorization 320 for changes to this object is governed by any of the maintainer objects 321 referenced. The changed attribute documents who last changed this object, 322 and when this change was made. Its syntax has the following form: 324 changed: 326 E.g. 327 changed: johndoe@terabit-labs.nn 19900401 329 The identifies the person who made the last change. 330 is the date of the change. The source attribute specifies the 331 registry where the object is registered. 333 The descr, tech-c, admin-c, remarks, notify, mnt-by, changed and source 334 attributes are attributes of all RPSL classes. Their syntax, semantics, and 335 mandatory, optional, multi-valued, or single-valued status are the same for 336 for all classes. We do not further discuss them in other sections. 338 4 person Class 340 A person class is used to describe information about people. Even though it 341 does not describe routing policy, we still describe it here briefly since 342 many policy objects make reference to person objects. The person class was 343 first described in [20]. 345 The attributes of the person class are shown in Figure 2. The person 346 attribute is the full name of the person. The phone and the fax-no 347 attributes have the following syntax: 349 phone: + [ext. ] 351 E.g.: 352 phone: +31 20 12334676 353 phone: +44 123 987654 ext. 4711 355 Attribute Value Type 356 person mandatory, single-valued, class key 357 address mandatory, multi-valued 358 phone see description in text mandatory, multi-valued 359 fax-no same as phone optional, multi-valued 360 e-mail mandatory, multi-valued 361 nic-hdl see description in text optional, single-valued 363 Figure 2: person Class Attributes 365 5 route Class 367 Each interAS route (also referred to as an interdomain route) originated by 368 an AS is specified using a route object. The attributes of the route class 369 are shown in Figure 3. The route attribute is the address prefix of the 370 route and the origin attribute is the AS number of the AS that originates 371 the route into the interAS routing system. The route and origin attribute 372 pair is the class key. 374 The Figure 4 shows examples of four route objects. Note that the last two 375 route objects have the same address prefix, namely 128.8.0.0/16. However, 376 they are different route objects since they are originated by different ASes 377 (i.e. they have different keys). 379 The withdrawn attribute, if present, signifies that the originator AS no 380 longer originates this address prefix in the Internet. Its value is a date 381 indicating the date of withdrawal. In Figure 4, the last route object is 382 withdrawn (i.e. no longer originated by AS2) on June 24, 1996. 384 Attribute Value Type 385 route mandatory, single-valued, class key 386 origin mandatory, single-valued, class key 387 withdrawn optional, single-valued 388 member-of list of optional, single-valued 389 see Section 6 390 inject-at see Section 9 optional, multi-valued 391 aggr-by see Section 9 optional, single-valued 392 export-comps see Section 9 optional, single-valued 393 holes see Section 9 optional, single-valued 395 Figure 3: route Class Attributes 397 route: 128.9.0.0/16 398 origin: AS226 400 route: 128.99.0.0/16 401 origin: AS226 403 route: 128.8.0.0/16 404 origin: AS1 406 route: 128.8.0.0/16 407 origin: AS2 408 withdrawn: 19960624 410 Figure 4: Route Objects 412 6 Set Classes 414 To specify policies, it is often useful to define sets of objects. For 415 this purpose we define two classes: route-set and as-set. These classes 416 define a named set. The members of these sets can be specified by either 417 explicitly listing them in the set object's definition, or implicitly by 418 having route and aut-num objects refer to the set name in their definitions, 419 or a combination of both methods. 421 6.1 route-set Class 423 The attributes of the route-set class are shown in Figure 5. The route-set 424 attribute defines the name of the set. It is an RPSL name that starts with 425 ``rs-''. The members attribute lists the members of the set. The members 426 attribute is a list of address prefixes or other route-set names. 428 Attribute Value Type 429 route-set mandatory, single-valued, 430 class key 431 members list of or optional, single-valued 432 433 mbrs-by-ref list of optional, single-valued 435 Figure 5: route-set Class Attributes 437 Figure 6 presents some example route-set objects. The set rs-foo contains 438 two address prefixes, namely 128.9.0.0/16 and 128.9.0.0/16. The set rs-bar 439 contains the members of the set rs-foo and the address prefix 128.7.0.0/16. 440 The set rs-empty contains no members. 442 route-set: rs-foo 443 members: 128.9.0.0/16, 128.9.0.0/24 445 route-set: rs-bar 446 members: 128.7.0.0/16, rs-foo 448 route-set: rs-empty 450 Figure 6: route-set Objects 452 An address prefix or a route-set name in a members attribute can be 453 optionally followed by an operator '^-', '^+', '^n', or '^n-m' where n and 454 m are integers. ^- operator is the exclusive more specifics operator; it 455 stands for the more specifics of the address prefix excluding the address 456 prefix itself. ^+ operator is the inclusive more specifics operator; it 457 stands for the more specifics of the address prefix including the address 458 prefix itself. ^n operator, stands for all the length n specifics of the 459 address prefix. ^n-m operator, stands for all the length n to length m 460 specifics of the address prefix. For example, the following set 462 route-set: rs-bar 463 members: 5.0.0.0/8^+, 128.9.0.0/16^-, 464 30.0.0.0/8^16, 30.0.0.0/8^24-32, rs-foo^+ 466 contains all the more specifics of 5.0.0.0/8 including 5.0.0.0/8, all 467 the more specifics of 128.9.0.0/16 excluding 128.9.0.0/16, all the more 468 specifics of 30.0.0.0/8 which are of length 16 such as 30.9.0.0/16, all 469 the more specifics of 30.0.0.0/8 which are of length 24 to 32 such as 470 30.9.9.96/28, and all the more specifics of address prefixes in route set 471 rs-foo. 473 The mbrs-by-ref attribute is a list of maintainer names or the keyword ANY. 474 If this attribute is used, the route set also includes address prefixes 475 whose route objects are registered by one of these maintainers and whose 476 member-of attribute refers to the name of this route set. If the value of a 477 mbrs-by-ref attribute is ANY, any route object referring to the route set 478 name is a member. If the mbrs-by-ref attribute is missing, only the address 479 prefixes listed in the members attribute are members of the set. Note that, 480 if a prefix is already listed explicitly as a member of a route set, the 481 route object for that prefix does not need to contain a member-of attribute. 483 route-set: rs-foo 484 mbrs-by-ref: MNTR-ME, MNTR-YOU 486 route-set: rs-bar 487 members: 128.7.0.0/16 488 mbrs-by-ref: MNTR-YOU 490 route: 128.9.0.0/16 491 origin: AS1 492 member-of: rs-foo 493 mnt-by: MNTR-ME 495 route: 128.8.0.0/16 496 origin: AS2 497 member-of: rs-foo, rs-bar 498 mnt-by: MNTR-YOU 500 Figure 7: route-set objects. 502 Figure 7 presents example route-set objects that use the mbrs-by-ref 503 attribute. The set rs-foo contains two address prefixes, namely 504 128.8.0.0/16 and 128.9.0.0/16 since the route objects for 128.8.0.0/16 and 505 128.9.0.0/16 refer to the set name rs-foo in their member-of attribute. The 506 set rs-bar contains the address prefixes 128.7.0.0/16 and 128.8.0.0/16. The 507 route 128.7.0.0/16 is explicitly listed in the members attribute of rs-bar, 508 and the route object for 128.8.0.0/16 refer to the set name rs-bar in its 509 member-of attribute. 511 Note that, if an address prefix is listed in a members attribute of a route 512 set, it is a member of that route set. The route object corresponding to 513 this address prefix does not need to contain a member-of attribute referring 514 to this set name. The member-of attribute of the route class is an 515 additional mechanism for specifying the members indirectly. 517 6.2 as-set Class 519 The attributes of the as-set class are shown in Figure 8. The as-set 520 attribute defines the name of the set. It is an RPSL name that starts with 521 ``as-''. The members attribute lists the members of the set. The members 522 attribute is a list of AS numbers, or other as-set names. 524 Attribute Value Type 525 as-set mandatory, single-valued, 526 class key 527 members list of or optional, single-valued 528 529 mbrs-by-ref list of optional, single-valued 531 Figure 8: as-set Class Attributes 533 Figure 9 presents two as-set objects. The set as-foo contains two ASes, 534 namely AS1 and AS2. The set as-bar contains the members of the set as-foo 535 and AS3, that is it contains AS1, AS2, AS3. 537 as-set: as-foo as-set: as-bar 538 members: AS1, AS2 members: AS3, as-foo 540 Figure 9: as-set objects. 542 The mbrs-by-ref attribute is a list of maintainer names or the keyword ANY. 543 If this attribute is used, the AS set also includes ASes whose aut-num 544 objects are registered by one of these maintainers and whose member-of 545 attribute refers to the name of this AS set. If the value of a mbrs-by-ref 546 attribute is ANY, any AS object referring to the AS set is a member of the 547 set. If the mbrs-by-ref attribute is missing, only the ASes listed in the 548 members attribute are members of the set. 550 as-set: as-foo 551 members: AS1, AS2 552 mbrs-by-ref: MNTR-ME 554 aut-num: AS3 aut-num: AS4 555 member-of: as-foo member-of: as-foo 556 mnt-by: MNTR-ME mnt-by: MNTR-OTHER 558 Figure 10: as-set objects. 560 Figure 10 presents an example as-set object that uses the mbrs-by-ref 561 attribute. The set as-foo contains AS1, AS2 and AS3. AS4 is not a member 562 of the set as-foo even though the aut-num object references as-foo. This is 563 because MNTR-OTHER is not listed in the as-foo's mbrs-by-ref attribute. 565 6.3 Predefined Set Objects 567 In a context that expects a route set (e.g. members attribute of the 568 route-set class), an AS number ASx defines the set of routes that are 569 originated by ASx; and an as-set AS-X defines the set of routes that are 570 originated by the ASes in AS-X. A route p is said to be originated by ASx if 571 there is a route object for p with ASx as the value of the origin attribute. 572 For example, in Figure 11, the route set rs-special contains 128.9.0.0/16, 573 routes of AS1 and AS2, and routes of the ASes in AS set AS-FOO. 575 route-set: rs-special 576 members: 128.9.0.0/16, AS1, AS2, AS-FOO 578 Figure 11: Use of AS numbers and AS sets in route sets. 580 The keyword rs-any defines the set of all routes registered in IRR. The 581 keyword as-any defines the set of all ASes registered in IRR. 583 6.4 Hierarchical Set Names 585 Set names can be hierarchical. A hierarchical set name is a sequence of set 586 names and AS numbers separated by colons ``:''. For example, the following 587 names are valid: AS1:AS-CUSTOMERS, AS1:RS-EXCEPTIONS, AS1:RS-EXPORT:AS2, 588 RS-EXCEPTIONS:RS-BOGUS. All components of an hierarchical set name which are 589 not AS numbers should start with ``as-'' or ``rs-'' for as sets and route 590 sets respectively. 592 A set object with name X1:...:Xn-1:Xn can only be created by the maintainer 593 of the object with name X1:...:Xn-1. That is, only the maintainer of AS1 594 can create a set with name AS1:AS-FOO; and only the maintainer of AS1:AS-FOO 595 can create a set with name AS1:AS-FOO:AS-BAR. 597 7 aut-num Class 599 ASes are specified using the aut-num class. The attributes of the aut-num 600 class are shown in Figure 12. The value of the aut-num attribute is the 601 AS number of the AS described by this object. The as-name attribute is 602 a symbolic name (in RPSL name syntax) of the AS. The import, export and 603 default routing policies of the AS are specified using import, export and 604 default attributes respectively. 606 Attribute Value Type 607 aut-num mandatory, single-valued, class key 608 as-name mandatory, single-valued 609 member-of list of optional, single-valued 610 import see Section 7.1 optional, multi valued 611 export see Section 7.2 optional, multi valued 612 default see Section 7.5 optional, multi valued 614 Figure 12: aut-num Class Attributes 616 7.1 import Attribute: Import Policy Specification 618 ---------------------- ---------------------- 619 | 7.7.7.1 |-------| |-------| 7.7.7.2 | 620 | | ======== | | 621 | AS1 | EX1 |-------| 7.7.7.3 AS2 | 622 | | | | 623 | 9.9.9.1 |------ ------| 9.9.9.2 | 624 ---------------------- | | ---------------------- 625 =========== 626 | EX2 627 ---------------------- | 628 | 9.9.9.3 |--------- 629 | | 630 | AS3 | 631 ---------------------- 633 Figure 13: Example topology consisting of three ASes, AS1, AS2, and AS3; 634 two exchange points, EX1 and EX2; and six routers. 636 A typical interconnection of ASes is shown in Figure 13. In this example 637 topology, there are three ASes, AS1, AS2, and AS3; two exchange points, 638 EX1 and EX2; and six routers. Routers connected to the same exchange 639 point peer with each other, i.e. open a connection for exchanging routing 640 information. Each router would export a subset of the routes it has to its 641 peer routers. Peer routers would import a subset of these routes. A router 642 while importing routes would set some route attributes. For example, AS1 643 can assign higher preference values to the routes it imports from AS2 so 644 that it prefers AS2 over AS3. While exporting routes, a router may also 645 set some route attributes in order to affect route selection by its peers. 646 For example, AS2 may set the MULTI-EXIT-DISCRIMINATOR BGP attribute so that 647 AS1 prefers to use the router 9.9.9.2. Most interAS policies are specified 648 by specifying what route subsets can be imported or exported, and how the 649 various route attributes are set and used. 651 In RPSL, an import policy is divided into import policy expressions. Each 652 import policy expression is specified using an import attribute. The import 653 attribute has the following syntax (we will extend this syntax later in 654 Sections 7.3 and 7.6): 656 import: from [action ] 657 . . . 658 from [action ] 659 accept 661 The action specification is optional. The semantics of an import attribute 662 is as follows: the set of routes that are matched by are imported 663 from all the peers specified in ; while importing routes at 664 , is executed. 666 E.g. 667 aut-num: AS1 668 import: from AS2 action pref = 1; accept { 128.9.0.0/16 } 670 This example states that the route 128.9.0.0/16 is accepted from AS2 with 671 preference 1. In the next few subsections, we will describe how peerings, 672 actions and filters are specified. 674 7.1.1 Peering Specification 676 Our example above used an AS number to specify peerings. The peerings 677 can be specified at different granularities. The syntax of a peering 678 specification is as follows: 680 [] [at ] 681 | [at ] 683 where and are IP addresses of routers, 684 is an AS number, and is an AS set name. must 685 be the AS number of . Both and 686 are optional. We first describe the semantics using the first form. 687 If both and are specified, this peering 688 specification identifies only the peering between these two routers. If 689 only is specified, this peering specification identifies 690 all the peerings between and any of its peer routers in 691 . If only is specified, this peering specification 692 identifies all the peerings between any router in the local AS and 693 . If neither nor is specified, 694 this peering specification identifies all the peerings between any router in 695 the local AS and any router in . If the form is used, the 696 peering specification identifies all the peerings between and 697 any of its peer routers in one of the ASes in . If 698 is not specified, the peering specification identifies all the peerings 699 between any router in the local AS and any of its peer routers in one of the 700 ASes in . 702 We next give examples. Consider the topology of Figure 13 where AS1 has 703 two routers 7.7.7.1 and 9.9.9.1; AS2 has three routers 7.7.7.2, 7.7.7.3 and 704 9.9.9.2; AS3 has one router 9.9.9.3. 7.7.7.1, 7.7.7.2 and 7.7.7.3 peer with 705 each other; 9.9.9.1, 9.9.9.2 and 9.9.9.3 peer with each other. In example 706 (1) below 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2. 708 (1) aut-num: AS1 709 import: from AS2 7.7.7.2 at 7.7.7.1 accept { 128.9.0.0/16 } 711 (2) aut-num: AS1 712 import: from AS2 at 7.7.7.1 accept { 128.9.0.0/16 } 714 (3) aut-num: AS1 715 import: from AS2 accept { 128.9.0.0/16 } 717 (4) as-set: AS-FOO 718 members: AS2, AS3 720 aut-num: AS1 721 import: from AS-FOO at 9.9.9.1 accept { 128.9.0.0/16 } 723 (5) aut-num: AS1 724 import: from AS-FOO accept { 128.9.0.0/16 } 726 (6) aut-num: AS1 727 import: from AS2 at 9.9.9.1 accept { 128.9.0.0/16 } 728 import: from AS3 at 9.9.9.1 accept { 128.9.0.0/16 } 730 (7) aut-num: AS1 731 import: from AS2 accept { 128.9.0.0/16 } 732 import: from AS3 accept { 128.9.0.0/16 } 734 In example (2), 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2 and 7.7.7.3. In 735 example (3), 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2 and 7.7.7.3, and 736 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2. In example (4), 9.9.9.1 imports 737 128.9.0.0/16 from 9.9.9.2 and 9.9.9.3. In example (5), 9.9.9.1 imports 738 128.9.0.0/16 from 9.9.9.2 and 9.9.9.3, and 7.7.7.1 imports 128.9.0.0/16 from 739 7.7.7.2 and 7.7.7.3. The example (4) and (5) are equivalent to examples (6) 740 and (7) respectively. 742 7.1.2 Action Specification 744 Policy actions in RPSL set or modify route attributes, such as assigning a 745 preference to a route, adding a community to the community attribute, or 746 setting the MULTI-EXIT-DISCRIMINATOR attribute. Policy actions can also 747 instruct routers to perform special operations, such as route flap damping. 749 The routing policy attributes whose values can be modified in policy actions 750 are specified in the RPSL dictionary. Please refer to Section 8 for a list 751 of these attributes. Each action in RPSL is terminated by the character 752 ';'. It is possible to form composite policy actions by listing them one 753 after the other. In a composite policy action, the actions are executed 754 left to right. For example, 756 aut-num: AS1 757 import: from AS2 758 action pref = 10; med = 0; community.append(10250, {3561,10}); 759 accept { 128.9.0.0/16 } 761 sets pref to 10, med to 0, and then appends 10250 and {3561,10} to the 762 community attribute. 764 7.1.3 Filter Specification 766 A policy filter is a logical expression which when applied to a set of 767 routes returns a subset of these routes. We say that the policy filter 768 matches the subset returned. The policy filter can match routes using any 769 route attribute, such as the destination address prefix (or NLRI), AS-path, 770 or community attributes. 772 The following policy filters can be used to select a subset of routes: 774 ANY 775 The filter-keyword ANY matches all routes. 777 Address-Prefix Set 778 This is an explicit list of address prefixes enclosed in braces '{' and 779 '}'. The policy filter matches the set of routes whose destination 780 address-prefix is in the set. For example: 782 { 0.0.0.0/0 } 783 { 128.9.0.0/16, 128.8.0.0/16, 128.7.128.0/17, 5.0.0.0/8 } 784 { } 786 An address prefix can be optionally followed by an operator '^-', '^+', 787 '^n', or '^n-m' where n and m are integers. ^- operator is the 788 exclusive more specifics operator; it stands for the more specifics of 789 the address prefix excluding the address prefix itself. ^+ operator is 790 the inclusive more specifics operator; it stands for the more specifics 791 of the address prefix including the address prefix itself. ^n operator, 792 stands for all the length n specifics of the address prefix. ^n-m 793 operator, stands for all the length n to length m specifics of the 794 address prefix. For example, the set 796 { 5.0.0.0/8^+, 128.9.0.0/16^-, 30.0.0.0/8^16, 30.0.0.0/8^24- 797 32 } 799 contains all the more specifics of 5.0.0.0/8 including 5.0.0.0/8, all 800 the more specifics of 128.9.0.0/16 excluding 128.9.0.0/16, all the more 801 specifics of 30.0.0.0/8 which are of length 16 such as 30.9.0.0/16, and 802 all the more specifics of 30.0.0.0/8 which are of length 24 to 32 such 803 as 30.9.9.96/28. 805 Route Set Name 806 A route set name matches the set of routes that are members of the set. 807 A route set name may be a name of a route-set object, an AS number, or a 808 name of an as-set object (AS numbers and as-set names implicitly define 809 route sets; please see Section 6.3). For example: 811 aut-num: AS1 812 import: from AS2 action pref = 1; accept AS2 813 import: from AS2 action pref = 1; accept AS-FOO 814 import: from AS2 action pref = 1; accept RS-FOO 816 The keyword PeerAS can be used instead of the AS number of the peer AS. 817 PeerAS is particularly useful when the peering is specified using an AS 818 set. For example: 820 as-set: AS-FOO 821 members: AS2 AS3 823 aut-num: AS1 824 import: from AS-FOO action pref = 1; accept PeerAS 826 is same as: 828 aut-num: AS1 829 import: from AS2 action pref = 1; accept AS2 830 import: from AS3 action pref = 1; accept AS3 832 A route set name can also be followed by one of the operators '^-', 833 '^+', '^n' or '^n-m'. These operators are distributive over the route 834 sets. For example, { 5.0.0.0/8, 6.0.0.0/8 }^+ equals { 5.0.0.0/8^+, 835 6.0.0.0/8^+ }, and AS1^- equals all the exclusive more specifics of 836 routes originated by AS1. 838 AS Path Regular Expressions 839 An AS-path regular expression can be used as a policy filter by 840 enclosing the expression in `<' and `>'. An AS-path policy filter 841 matches the set of routes which traverses a sequence of ASes matched 842 by the AS-path regular expression. A router can check this using the 843 AS_PATH attribute in the Border Gateway Protocol [28], or the RD_PATH 844 attribute in the Inter-Domain Routing Protocol[26]. 846 AS-path Regular Expressions are POSIX compliant regular expressions over 847 the alphabet of AS numbers. The regular expression constructs are as 848 follows: 850 ASN where ASN is an AS number. ASN matches the AS-path that is 851 of length 1 and contains the corresponding AS number (e.g. 852 AS-path regular expression AS1 matches the AS-path ``1''). 854 The keyword PeerAS can be used instead of the AS number of 855 the peer AS. 857 AS-set where AS-set is an AS set name. AS-set matches the AS-paths 858 that is matched by one of the ASes in the AS-set. 860 . matches the AS-paths matched by any AS number. 862 [...] is an AS number set. It matches the AS-paths matched by the 863 AS numbers listed between the brackets. The AS numbers in 864 the set are separated by white space characters. If a `-' 865 is used between two AS numbers in this set, all AS numbers 866 between the two AS numbers are included in the set. If 867 an as-set name is listed, all AS numbers in the as-set are 868 included. 870 [^...] is a complemented AS number set. It matches any AS-path which 871 is not matched by the AS numbers in the set. 873 ^ Matches the empty string at the beginning of an AS-path. 875 $ Matches the empty string at the end of an AS-path. 877 We next list the regular expression operators in the decreasing order of 878 evaluation. These operators are left associative, i.e. performed left 879 to right. 881 Unary postfix operators * + ? 882 For a regular expression A, A* matches zero or more 883 occurrences of A; A+ matches one or more occurrences of A; 884 A? matches zero or one occurrence of A. 886 Binary catenation operator 887 This is an implicit operator and exists between two 888 regular expressions A and B when no other explicit 889 operator is specified. The resulting expression A B 890 matches an AS-path if A matches some prefix of the AS-path 891 and B matches the rest of the AS-path. 893 Binary alternative (or) operator | 894 For a regular expressions A and B, A | B matches any 895 AS-path that is matched by A or B. 897 Parenthesis can be used to override the default order of evaluation. 898 White spaces can be used to increase readability. 900 The following are examples of AS-path filters: 902 903 <^AS1> 904 905 <^AS1 AS2 AS3$> 906 <^AS1 .* AS2$>. 908 The first example matches any route whose AS-path contains AS3, the 909 second matches routes whose AS-path starts with AS1, the third matches 910 routes whose AS-path ends with AS2, the fourth matches routes whose 911 AS-path is exactly ``1 2 3'', and the fifth matches routes whose AS-path 912 starts with AS1 and ends in AS2 with any number of AS numbers in 913 between. 915 Composite Policy Filters 917 The following operators (in decreasing order of evaluation) can be used to 918 form composite policy filters: 920 NOT Given a policy filter x, NOT x matches the set of routes that are not 921 matched by x. That is it is the negation of policy filter x. 923 AND Given two policy filters x and y, x AND y matches the intersection of 924 the routes that are matched by x and that are matched by y. 926 OR Given two policy filters x and y, x OR y matches the union of the routes 927 that are matched by x and that are matched by y. 929 Note that an OR operator can be implicit, that is `x y' is equivalent to `x 930 OR y'. 932 E.g. 933 NOT {128.9.0.0/16, 128.8.0.0/16} 934 AS226 AS227 OR AS228 935 AS226 AND NOT {128.9.0.0/16} 936 AS226 AND {0.0.0.0/0^0-18} 938 The first example matches any route except 128.9.0.0/16 and 128.8.0.0/16. 939 The second example matches the routes of AS226, AS227 and AS228. The third 940 example matches the routes of AS226 except 128.9.0.0/16. The fourth example 941 matches the routes of AS226 whose length are shorter than 19. 943 Policy filters can also use the values of other attributes for comparison. 944 The attributes whose values can be used in policy filters are specified in 945 the RPSL dictionary. Please refer to Section 8 for details. An example 946 using the the BGP community attribute is shown below: 948 aut-num: AS1 949 export: to AS2 announce AS1 AND NOT community.contains(NO_EXPORT) 951 Filters using the routing policy attributes defined in the dictionary are 952 evaluated before evaluating the operators AND, OR and NOT. 954 7.1.4 Example Policy Expressions 956 aut-num: AS1 957 import: from AS2 action pref = 1; 958 from AS3 action pref = 2; 959 accept AS4 961 The above example states that AS4's routes are accepted from AS2 with 962 preference 1, and from AS3 with preference 2 (routes with lower integer 963 preference values are preferred over routes with higher integer preference 964 values). 966 aut-num: AS1 967 import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; 968 from AS2 action pref = 2; 969 accept AS4 971 The above example states that AS4's routes are accepted from AS2 on peering 972 7.7.7.1-7.7.7.2 with preference 1, and on any other peering with AS2 with 973 preference 2. 975 7.2 export Attribute: Export Policy Specification 977 Similarly, an export policy expression is specified using an export 978 attribute. The export attribute has the following syntax: 980 export: to [action ] 981 . . . 982 to [action ] 983 announce 985 The action specification is optional. The semantics of an export attribute 986 is as follows: the set of routes that are matched by are 987 exported to all the peers specified in ; while exporting routes at 988 , is executed. 990 E.g. 991 aut-num: AS1 992 export: to AS2 action med = 5; community .= 70; 993 announce AS4 995 In this example, AS4's routes are announced to AS2 with the med attribute's 996 value set to 5 and community 70 added to the community list. 998 Example: 1000 aut-num: AS1 1001 export: to AS-FOO announce ANY 1003 In this example, AS1 announces all of its routes to the ASes in the set 1004 AS-FOO. 1006 7.3 Other Routing Protocols, Multi-Protocol Routing Protocols, and Injecting 1007 Routes Between Protocols 1009 The syntax of the import and export attributes are indeed the following: 1011 import: [protocol ] [into ] 1012 from [action ] 1013 . . . 1014 from [action ] 1015 accept 1016 export: [protocol ] [into ] 1017 to [action ] 1018 . . . 1019 to [action ] 1020 announce 1022 Where the optional protocol specifications can be used for specifying 1023 policies for other routing protocols, or for injecting routes of one 1024 protocol into another protocol, or for multi-protocol routing policies. The 1025 valid protocol names are defined in the dictionary. The 1026 is the name of the protocol whose routes are being exchanged. The 1027 is the name of the protocol which is receiving these routes. 1028 Both and default to the Internet Exterior Gateway 1029 Protocol, currently BGP. 1031 In the following example, all interAS routes are injected into RIP. 1033 aut-num: AS1 1034 import: from AS2 accept AS2 1035 export: protocol BGP4 into RIP 1036 to AS1 announce ANY 1038 In the following example, AS1 accepts AS2's routes including any more 1039 specifics of AS2's routes, but does not inject these extra more specific 1040 routes into OSPF. 1042 aut-num: AS1 1043 import: from AS2 accept AS2^+ 1044 export: protocol BGP4 into OSPF 1045 to AS1 announce AS2 1047 In the following example, AS1 injects its static routes (routes which are 1048 members of the set AS1:RS-STATIC-ROUTES) to the interAS routing protocol and 1049 appends AS1 twice to their AS paths. 1051 aut-num: AS1 1052 import: protocol STATIC into BGP4 1053 from AS1 action aspath.prepend(AS1, AS1); 1054 accept AS1:RS-STATIC-ROUTES 1056 In the following example, AS1 imports different set of unicast routes for 1057 multicast reverse path forwarding from AS2: 1059 aut-num: AS1 1060 import: from AS2 accept AS2 1061 import: protocol IDMR 1062 from AS2 accept AS2:RS-RPF-ROUTES 1064 7.4 Ambiguity Resolution 1066 It is possible that the same peering can be covered by more that one peering 1067 specification in a policy expression. For example: 1069 aut-num: AS1 1070 import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 2; 1071 from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; 1072 accept AS4 1074 This is not an error, though definitely not desirable. To break the 1075 ambiguity, the action corresponding to the first peering specification is 1076 used. That is the routes are accepted with preference 2. We call this rule 1077 as the specification-order rule. 1079 Consider the example: 1081 aut-num: AS1 1082 import: from AS2 action pref = 2; 1083 from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; dpa = 5; 1084 accept AS4 1086 where both peering specifications cover the peering 7.7.7.1-7.7.7.2, though 1087 the second one covers it more specifically. The specification order rule 1088 still applies, and only the action ``pref = 2'' is executed. In fact, the 1089 second peering-action pair has no use since the first peering-action pair 1090 always covers it. If the intended policy was to accept these routes with 1091 preference 1 on this particular peering and with preference 2 in all other 1092 peerings, the user should have specified: 1094 aut-num: AS1 1095 import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; dpa = 5; 1096 from AS2 action pref = 2; 1097 accept AS4 1099 It is also possible that more than one policy expression can cover the same 1100 set of routes for the same peering. For example: 1102 aut-num: AS1 1103 import: from AS2 action pref = 2; accept AS4 1104 import: from AS2 action pref = 1; accept AS4 1106 In this case, the specification-order rule is still used. That is, AS4's 1107 routes are accepted from AS2 with preference 2. If the filters were 1108 overlapping but not exactly the same: 1110 aut-num: AS1 1111 import: from AS2 action pref = 2; accept AS4 1112 import: from AS2 action pref = 1; accept AS4 OR AS5 1114 the AS4's routes are accepted from AS2 with preference 2 and however AS5's 1115 routes are also accepted, but with preference 1. 1117 We next give the general specification order rule for the benefit of the 1118 RPSL implementors. Consider two policy expressions: 1120 aut-num: AS1 1121 import: from peerings-1 action action-1 accept filter-1 1122 import: from peerings-2 action action-2 accept filter-2 1124 The above policy expressions are equivalent to the following three 1125 expressions where there is no overlap: 1127 aut-num: AS1 1128 import: from peerings-1 action action-1 accept filter-1 1129 import: from peerings-3 action action-2 accept filter-2 AND NOT filter-1 1130 import: from peerings-4 action action-2 accept filter-2 1132 where peerings-3 are those that are covered by both peerings-1 and 1133 peerings-2, and peerings-4 are those that are covered by peerings-2 but not 1134 by peerings-1 (``filter-2 AND NOT filter-1'' matches the routes that are 1135 matched by filter-2 but not by filter-1). 1137 Example: 1139 aut-num: AS1 1140 import: from AS2 7.7.7.2 at 7.7.7.1 1141 action pref = 2; 1142 accept {128.9.0.0/16} 1143 import: from AS2 1144 action pref = 1; 1145 accept {128.9.0.0/16, 75.0.0.0/8} 1147 Lets consider two peerings with AS2, 7.7.7.1-7.7.7.2 and 9.9.9.1-9.9.9.2. 1148 Both policy expressions cover 7.7.7.1-7.7.7.2. On this peering, the route 1149 128.9.0.0/16 is accepted with preference 2, and the route 75.0.0.0/8 is 1150 accepted with preference 1. The peering 9.9.9.1-9.9.9.2 is only covered by 1151 the second policy expressions. Hence, both the route 128.9.0.0/16 and the 1152 route 75.0.0.0/8 are accepted with preference 1 on peering 9.9.9.1-9.9.9.2. 1154 7.5 default Attribute: Default Policy Specification 1156 Default routing policies are specified using the default attribute. The 1157 default attribute has the following syntax: 1159 default: to [action ] [networks ] 1161 The and specifications are optional. The semantics 1162 are as follows: The specification indicates the AS (and the 1163 router if present) is being defaulted to; the specification, 1164 if present, indicates various attributes of defaulting, for example a 1165 relative preference if multiple defaults are specified; and the 1166 specifications, if present, is a policy filter. A router chooses a default 1167 router from the routes in its routing table that matches this . 1169 In the following example, AS1 defaults to AS2 for routing. 1171 aut-num: AS1 1172 default: to AS2 1174 In the following example, router 7.7.7.1 in AS1 defaults to router 7.7.7.2 1175 in AS2. 1177 aut-num: AS1 1178 default: to AS2 7.7.7.2 at 7.7.7.1 1180 In the following example, AS1 defaults to AS2 and AS3, but prefers AS2 over 1181 AS3. 1183 aut-num: AS1 1184 default: to AS2 action pref = 1; 1185 default: to AS3 action pref = 2; 1187 In the following example, AS1 defaults to AS2 and uses 128.9.0.0/16 as the 1188 default network. 1190 aut-num: AS1 1191 default: to AS2 networks { 128.9.0.0/16 } 1193 7.6 Structured Policy Specification 1195 The import and export policies can be structured. We only reccomend 1196 structured policies to advanced RPSL users. Please feel free to skip this 1197 section. 1199 The BNF for a structured policy specification is the following: 1201 ::= from [action ] 1202 . . . 1203 from [action ] 1204 accept ; 1206 ::= | 1207 LEFT-BRACE 1208 1209 . . . 1210 1211 RIGHT-BRACE 1213 ::= | 1214 EXCEPT | 1215 REFINE 1217 import: [protocol ] [into ] 1218 1220 Please note the semicolon at the end of an . If the policy 1221 specification is not structured (as in all the examples in other sections), 1222 this semicolon is optional. The syntax and semantics for an 1223 is already defined in Section 7.1. 1225 An is either a sequence of 's enclosed within 1226 matching braces (i.e. `{' and `}') or just a single . The 1227 semantics of an is the union of 's using the 1228 specification order rule. An is either a single 1229 or an followed by one of the keywords "except" 1230 and "refine", followed by another . Note that our 1231 definition allows nested expressions. Hence there can be exceptions to 1232 exceptions, refinements to refinements, or even refinements to exceptions, 1233 and so on. 1235 The semantics for the except operator is as follows: The result of 1236 an except operation is another . The resulting policy set 1237 contains the policies of the right hand side but their filters are modified 1238 to only include the routes also matched by a filter on the left hand side. 1239 The policies of the left hand side are included afterwards and their filters 1240 are modified to exclude the routes matched by the filters of the right hand 1241 side. Please note that the filters are modified during this process but the 1242 actions are copied verbatim. When there are multiple levels of nesting, the 1243 operations (both except and refine) are performed right to left. 1245 Consider the following example: 1247 import: from AS1 action pref = 1; accept as-foo; 1248 except { 1249 from AS2 action pref = 2; accept AS226; 1250 except { 1251 from AS3 action pref = 3; accept {128.9.0.0/16}; 1252 } 1253 } 1255 where the route 128.9.0.0/16 is originated by AS226, and AS226 is a member 1256 of the as set as-foo. In this example, the route 128.9.0.0/16 is accepted 1257 from AS3, any other route (not 128.9.0.0/16) originated by AS226 is accepted 1258 from AS2, and any other ASes' routes in as-foo is accepted from AS1. 1260 We can come to the same conclusion using the algebra defined above. 1261 Consider the inner exception specification: 1263 from AS2 action pref = 2; accept AS226; 1264 except { 1265 from AS3 action pref = 3; accept {128.9.0.0/16}; 1266 } 1268 is equivalent to 1270 { 1271 from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16}; 1272 from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16}; 1273 } 1275 Hence, the original expression is equivalent to: 1277 import: from AS1 action pref = 1; accept as-foo; 1278 except { 1279 from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16}; 1280 from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16}; 1281 } 1283 which is equivalent to 1285 import: { 1286 from AS3 action pref = 3; 1287 accept as-foo AND AS226 AND {128.9.0.0/16}; 1288 from AS2 action pref = 2; 1289 accept as-foo AND AS226 AND NOT {128.9.0.0/16}; 1290 from AS1 action pref = 1; 1291 accept as-foo AND NOT 1292 (AS226 AND NOT {128.9.0.0/16} OR AS226 AND {128.9.0.0/16}); 1293 } 1295 Since AS226 is in as-foo and 128.9.0.0/16 is in AS226, it simplifies to: 1297 import: { 1298 from AS3 action pref = 3; accept {128.9.0.0/16}; 1299 from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16}; 1300 from AS1 action pref = 1; accept as-foo AND NOT AS226; 1301 } 1303 In the case of the refine operator, the resulting set is constructed by 1304 taking the cartasian product of the two sides as follows: for each policy l 1305 in the left hand side and for each policy r in the right hand side, the 1306 peerings of the resulting policy are the peerings common to both r and l; 1307 the filter of the resulting policy is the intersection of l's filter and r's 1308 filter; and action of the resulting policy is l's action followed by r's 1309 action. If there are no common peerings, or if the intersection of filters 1310 is empty, a resulting policy is not generated. 1312 Consider the following example: 1314 import: { from AS-ANY action pref = 1; accept community.contains({3560,10}); 1315 from AS-ANY action pref = 2; ac- 1316 cept community.contains({3560,20}); 1317 } refine { 1318 from AS1 accept AS1; 1319 from AS2 accept AS2; 1320 from AS3 accept AS3; 1321 } 1323 Here, any route with community {3560,10} is assigned a preference of 1 and 1324 any route with community {3560,20} is assigned a preference of 2 regardless 1325 of whom they are imported from. However, only AS1's routes are imported 1326 from AS1, and only AS2's routes are imported from AS2, and only AS3's routes 1327 are imported form AS3, and no routes are imported from any other AS. We can 1328 reach the same conclusion using the above algebra. That is, our example is 1329 equivalent to: 1331 import: { 1332 from AS1 action pref = 1; accept community.contains({3560,10}) AND AS1; 1333 from AS1 action pref = 2; accept community.contains({3560,20}) AND AS1; 1334 from AS2 action pref = 1; accept community.contains({3560,10}) AND AS2; 1335 from AS2 action pref = 2; accept community.contains({3560,20}) AND AS2; 1336 from AS3 action pref = 1; accept community.contains({3560,10}) AND AS3; 1337 from AS3 action pref = 2; accept community.contains({3560,20}) AND AS3; 1338 } 1340 Note that the common peerings between ``from AS1'' and ``from AS-ANY'' are 1341 those peerings in ``from AS1''. Even though we do not formally define 1342 ``common peerings'', it is straight forward to deduce the definition from 1343 the definitions of peerings (please see Section 7.1.1). 1345 Consider the following example: 1347 import: { 1348 from AS-ANY action med = 0; accept {0.0.0.0/0^0-16}; 1349 } refine { 1350 from AS1 at 7.7.7.1 action pref = 1; accept AS1; 1351 from AS1 action pref = 2; accept AS1; 1353 } 1355 where only routes of length 0 to 16 are accepted and med's value is set to 0 1356 to disable med's effect for all peerings; In addition, from AS1 only AS1's 1357 routes are imported, and AS1's routes imported at 7.7.7.1 are preferred over 1358 other peerings. This is equivalent to: 1360 import: { 1361 from AS1 at 7.7.7.1 action med=0; pref=1; accept {0.0.0.0/0^0- 1362 16} AND AS1; 1363 from AS1 action med=0; pref=2; accept {0.0.0.0/0^0- 1364 16} AND AS1; 1365 } 1367 The above syntax and semantics also apply equally to structured export 1368 policies with ``from'' replaced with ``to'' and ``accept'' is replaced with 1369 ``announce''. 1371 8 dictionary Class 1373 The dictionary class provides extensibility to RPSL. Dictionary objects 1374 define routing policy attributes, types, and routing protocols. Routing 1375 policy attributes, henceforth called rp-attributes, may correspond to actual 1376 protocol attributes, such as the BGP path attributes (e.g. community, dpa, 1377 and AS-path), or they may correspond to router features (e.g. BGP route flap 1378 damping). As new protocols, new protocol attributes, or new router features 1379 are introduced, the dictionary object is updated to include appropriate 1380 rp-attribute and protocol definitions. 1382 An rp-attribute is an abstract class; that is their data representation is 1383 not available. Instead, they are accessed through access methods. For 1384 example, the rp-attribute for the BGP AS-path attribute is called aspath; 1385 and it has an access method called prepend which stuffs extra AS numbers to 1386 the AS-path attributes. Access methods can take arguments. Arguments are 1387 strongly typed. For example, the method prepend above takes AS numbers as 1388 argument. 1390 Once an rp-attribute is defined in the dictionary, it can be used to 1391 describe policy filters and actions. Policy analysis tools are required 1392 to fetch the dictionary object and recognize newly defined rp-attributes, 1393 types, and protocols. The analysis tools may approximate policy analyses 1394 on rp-attributes that they do not understand: a filter method may always 1395 match, and an action method may always perform no-operation. Analysis tools 1396 may even download code to perform appropriate operations using mechanisms 1397 outside the scope of RPSL. 1399 We next describe the syntax and semantics of the dictionary class. This 1400 description is not essential for understanding dictionary objects (but it is 1401 essential for creating one). Please feel free to skip to the RPSL Initial 1402 Dictionary subsection (Section 8.1). 1404 The attributes of the dictionary class are shown in Figure 14. The 1405 dictionary attribute is the name of the dictionary object, obeying the RPSL 1406 naming rules. There can be many dictionary objects, however there is always 1407 one well-known dictionary object ``RPSL''. All tools use this dictionary by 1408 default. 1410 Attribute Value Type 1411 dictionary mandatory, single-valued, class key 1412 rp-attribute see description in text optional, multi valued 1413 typedef see description in text optional, multi valued 1414 protocol see description in text optional, multi valued 1415 encapsulation see Section 11 optional, multi valued 1417 Figure 14: dictionary Class Attributes 1419 The rp-attribute attribute has the following syntax: 1421 rp-attribute: 1422 (, ..., [, "..."]) 1423 ... 1424 (, ..., [, "..."]) 1426 where is the name of the rp-attribute; and is the name of 1427 an access method for the rp-attribute, taking Ni arguments where the j-th 1428 argument is of type . A method name is either an RPSL name or one 1429 of the operators defined in Figure 15. The operator methods can take only 1430 one argument. 1432 operator= operator== 1433 operator<<= operator< 1434 operator>>= operator> 1435 operator+= operator>= 1436 operator-= operator<= 1437 operator*= operator!= 1438 operator/= operator() 1439 operator.= operator[] 1441 Figure 15: Operators 1443 An rp-attribute can have many methods defined for it. Some of the methods 1444 may even have the same name, in which case their arguments are of different 1445 types. If the argument list is followed by ``...'', the method takes a 1446 variable number of arguments. In this case, the actual arguments after the 1447 Nth argument are of type . 1449 Arguments are strongly typed. A type of an argument can be one of the 1450 predefined types or one of the dictionary defined types. The predefined 1451 type names are listed in Figure 16. The integer and the real types can be 1452 followed by a lower and an upper bound to specify the set of valid values 1453 of the argument. The range specification is optional. We use the ANSI C 1454 language conventions for representing integer, real and string values. The 1455 enum type is followed by a list of RPSL names which are the valid values of 1456 the type. The boolean type can take the values true or false. as_number, 1457 ip_address, address_prefix and dns_name types are as in Section 2. filter 1458 type is a policy filter as in Section 7. 1460 integer[lower, upper] as_number 1461 real[lower, upper] ipv4_address 1462 enum[name, name, ...] address_prefix 1463 string dns_name 1464 boolean filter 1465 rpsl_word as_set_name 1466 free_text route_set_name 1467 email 1469 Figure 16: Predefined Types 1471 The typedef attribute specifies a dictionary defined type. Its syntax is as 1472 follows: 1474 typedef: ... 1476 where is the name of the type being defined and is another 1477 type name, either predefined or dictionary defined. The type defined by a 1478 typedef is either of the types 1 through N (analogous to unions in C[19]). 1480 A dictionary defined type can also be a list type, specified as: 1482 list [:] of 1484 where the list elements are of and the list contains at least 1485 and at most elements. The size specification is 1486 optional. In this case, there is no restriction in the number of list 1487 elements. A value of a list type is represented as a sequence of elements 1488 separated by the character ``,'' and enclosed by the characters ``{'' and 1489 ``}''. 1491 A protocol attribute of the dictionary class defines a protocol and a set 1492 of peering options for that protocol (which are used in inet-rtr class in 1493 Section 10). Its syntax is as follows: 1495 protocol: 1496 MANDATORY | OPTIONAL (, ..., [, "..."]) 1497 ... 1498 MANDATORY | OPTIONAL (, ..., [, "..."]) 1500 where is the name of the protocol; MANDATORY and OPTIONAL are 1501 keywords; and is a peering option for this protocol, taking Ni 1502 many arguments. The syntax and semantics of the arguments are as in the 1503 rp-attribute. If the keyword MANDATORY is used the option is mandatory and 1504 needs to be specified for each peering of this protocol. If the keyword 1505 OPTIONAL is used the option can be skipped. 1507 The encapsulation attribute defines a valid encapsulation name for 1508 inet-tunnel objects. Please refer to Section 11 for details. 1510 8.1 Initial RPSL Dictionary and Example Policy Actions and Filters 1512 dictionary: RPSL 1513 rp-attribute: # preference, smaller values represent higher preferences 1514 pref 1515 operator=(integer[0, 65535]) 1516 rp-attribute: # BGP multi_exit_discriminator attribute 1517 med 1518 operator=(integer[0, 65535]) 1519 # to set med to the IGP metric: med = igp_cost; 1520 operator=(enum[igp_cost]) 1521 rp-attribute: # BGP destination preference attribute (dpa) 1522 dpa 1523 operator=(integer[0, 65535]) 1524 rp-attribute: # BGP aspath attribute 1525 aspath 1526 # prepends AS numbers from last to first order 1527 prepend(as_number, ...) 1528 typedef: # a community value in RPSL is either 1529 # - a 4 byte integer 1530 # - internet, no_export, no_advertise (see RFC-1997) 1531 # - two 2-byte integers to be concatanated eg. {3561,70} 1532 community_elm 1533 integer[1, 4294967200], 1534 enum[internet, no_export, no_advertise] 1535 list[2:2] of integer[0, 65535] 1536 typedef: # list of community values { 40, no_export, {3561,70}} 1537 community_list 1538 list of community_elm 1539 rp-attribute: # BGP community attribute 1540 community 1541 # set to a list of communities 1542 operator=(community_list) 1543 # order independent equality comparison 1544 operator==(community_list) 1545 # append community values 1546 operator.=(community_elm) 1547 append(community_elm, ...) 1548 # delete community values 1549 delete(community_elm, ...) 1550 # a filter: true if one of community values is contained 1551 contains(community_elm, ...) 1552 # shortcut to contains: community(no_export, {3561,70}) 1553 operator()(community_elm, ...) 1554 rp-attribute: # next hop router in a static route 1555 next-hop 1556 operator=(ipv4_address) # a router address 1557 operator=(enum[self]) # router's own address 1558 rp-attribute: # cost of a static route 1559 cost 1560 operator=(integer[0, 65535]) 1561 rp-attribute: # IP time-to-live, useful for tunnels 1562 ttlscope 1563 operator=(integer[0, 65535]) 1564 rp-attribute: # A DVMRP metric, useful for tunnels 1565 dvmrp-metric 1566 operator=(integer[0, 65535]) 1567 rp-attribute: # for admin scoped multicast 1568 boundary 1569 operator=(list of address_prefix) 1570 encapsulation: IPinIP 1571 encapsulation: IPMOBILITY 1572 encapsulation: DVMRP 1573 encapsulation: GRE 1574 encapsulation: IPv6 1575 protocol: BGP4 1576 # as number of the peer router 1577 MANDATORY asno(as_number) 1578 # enable flap damping 1579 OPTIONAL flap_damp() 1580 protocol: OSPF 1581 protocol: RIP 1582 protocol: IGRP 1583 protocol: IS-IS 1584 protocol: STATIC 1585 protocol: RIPng 1586 protocol: DVMRP 1587 protocol: PIM-DM 1588 protocol: PIM-SM 1589 protocol: CBT 1590 protocol: MOSPF 1592 Figure 17: RPSL Dictionary 1594 The Figure 17 shows the initial RPSL dictionary. It has eight 1595 rp-attributes: pref to assign local preference to the routes accepted; 1596 med to assign a value to the MULTI_EXIT_DISCRIMINATOR BGP attribute; dpa to 1597 assign a value to the DPA BGP attribute; aspath to prepend a value to the 1598 AS_PATH BGP attribute; community to assign a value to or to check the value 1599 of the community BGP attribute; next-hop to assign next hop routers to 1600 static routes; and cost to assign a cost to static routes. The dictionary 1601 defines two types: community_elm and community_list. community_elm type 1602 is either a 4-byte unsigned integer, or one of the keywords no_export or 1603 no_advertise (defined in [9]), or a list of two 2-byte unsigned integers 1604 in which case the two integers are concatenated to form a 4-byte integer. 1605 (The last form is often used in the Internet to partition the community 1606 space. A provider uses its AS number as the first two bytes, and assigns a 1607 semantics of its choice to the last two bytes.) The rp-attributes ttlscope, 1608 dvmrp-metric, boundary are for specifying tunnel characteristics and are 1609 described in Section 11. 1611 The initial dictionary (Figure 17) defines only options for the Border 1612 Gateway Protocol: asno and flap_damp. The mandatory asno option is the AS 1613 number of the peer router. The optional flap_damp option instructs the 1614 router to damp route flaps when importing routes from the peer router. 1616 The initial dictionary (Figure 17) defines the following encapsulation 1617 types: IPinIP [29], IPMOBILITY [24], DVMRP [25], GRE [15], and IPv6 1618 [10]. 1620 Policy Actions and Filters Using RP-Attributes 1622 The syntax of a policy action or a filter using an rp-attribute x is as 1623 follows: 1625 x.method(arguments) 1626 x ``op'' argument 1628 where method is a method and ``op'' is an operator method of the 1629 rp-attribute x. If an operator method is used in specifying a composite 1630 policy filter, it evaluates earlier than the composite policy filter 1631 operators (i.e. AND, OR, NOT, and implicit or operator). 1633 The pref rp-attribute can be assigned a positive integer as follows: 1635 pref = 10; 1637 The med rp-attribute can be assigned either a positive integer or the word 1638 ``igp_cost'' as follows: 1640 med = 0; 1641 med = igp_cost; 1643 The dpa rp-attribute can be assigned a positive integer as follows: 1645 dpa = 100; 1647 The BGP community attribute is list-valued, that is it is a list of 1648 4-byte integers each representing a ``community''. The following examples 1649 demonstrate how to add communities to this rp-attribute: 1651 community .= 100; 1652 community .= NO_EXPORT; 1653 community .= {3561,10}; 1655 In the last case, a 4-byte integer is constructed where the more significant 1656 two bytes equal 3561 and the less significant two bytes equal 10. The 1657 following examples demonstrate how to delete communities from the community 1658 rp-attribute: 1660 community.delete(100, NO_EXPORT, {3561,10}); 1662 Filters that use the community rp-attribute can be defined as demonstrated 1663 by the following examples: 1665 community.contains(100, NO_EXPORT, {3561,10}); 1667 The community rp-attribute can be set to a list of communities as follows: 1669 community = {100, NO_EXPORT, {3561,10}, 200}; 1670 community = {}; 1672 In this first case, the community rp-attribute contains the communities 1673 100, NO_EXPORT, {3561,10}, and 200. In the latter case, the community 1674 rp-attribute is cleared. The community rp-attribute can be compared against 1675 a list of communities as follows: 1677 community == {100, NO_EXPORT, {3561,10}, 200}; 1679 To influence the route selection, the BGP as_path rp-attribute can be made 1680 longer by prepending AS numbers to it as follows: 1682 aspath.prepend(AS1); 1683 aspath.prepend(AS1, AS1, AS1); 1685 The following examples are invalid: 1687 med = -50; # -50 is not in the range 1688 med = igp; # igp is not one of the enum values 1689 med.assign(10); # method assign is not defined 1690 community.append({AS3561,20}); # the first argument should be 3561 1692 Figure 18 shows a more advanced example using the rp-attribute community. 1693 In this example, AS3561 bases its route selection preference on the 1694 community attribute. Other ASes may indirectly affect AS3561's route 1695 selection by including the appropriate communities in their route 1696 announcements. 1698 9 Advanced route Class 1700 9.1 Specifying Static Routes 1702 The attribute inject-at can be used to specify static routes. Its syntax is 1703 as follows: 1705 aut-num: AS1 1706 export: to AS2 action community.={3561,90}; 1707 to AS3 action community.={3561,80}; 1708 announce AS1 1710 as-set: AS3561:AS-PEERS 1711 members: AS2, AS3 1713 aut-num: AS3561 1714 import: from AS3561:AS-PEERS 1715 action pref = 10; 1716 accept community.contains({3561,90}) 1717 import: from AS3561:AS-PEERS 1718 action pref = 20; 1719 accept community.contains({3561,80}) 1720 import: from AS3561:AS-PEERS 1721 action pref = 20; 1722 accept community.contains({3561,70}) 1723 import: from AS3561:AS-PEERS 1724 action pref = 0; 1725 accept ANY 1727 Figure 18: Policy example using the community rp-attribute. 1729 inject-at: [action ] 1731 where is an IP address of a router and is as in the 1732 aut-num class. executes the and injects the route to the 1733 interAS routing system. may set certain route attributes such as a 1734 next-hop router or a cost. 1736 In the following example, the router 7.7.7.1 injects the route 128.7.0.0/16. 1737 The next-hop routers (in this example, there are two next-hop routers) for 1738 this route are 7.7.7.2 and 7.7.7.3 and the route has a cost of 10 over 1739 7.7.7.2 and 20 over 7.7.7.3. 1741 route: 128.7.0.0/16 1742 origin: AS1 1743 inject-at: 7.7.7.1 action next-hop = 7.7.7.2; cost = 10; 1744 inject-at: 7.7.7.1 action next-hop = 7.7.7.3; cost = 20; 1746 9.2 Specifying Aggregate Routes 1748 The attributes aggr-by, inject-at, export-comps, and holes are used for 1749 specifying aggregate routes [13]. 1751 The aggr-by attribute defines what component routes are used to form the 1752 aggregate. Its syntax is as follows: 1754 aggr-by: [atomic] 1756 A router in the origin AS forms the aggregate route if there is at least one 1757 route in its routing table that matches . If the keyword ATOMIC 1758 is specified, the aggregation is done atomically, otherwise the BGP path 1759 attributes of the matching routes are used to form the BGP path attributes 1760 of the aggregate route. For example, if atomic aggregation is done, the 1761 aggregate route would have an AS-path that starts from the aggregating 1762 AS [13]. Otherwise, the aggregate route would have an AS-path containing 1763 AS-sets formed from the AS-paths of the matching routes. 1765 Figure 19 shows some example aggregate route objects. The aggregate 1766 128.9.0.0/16 is generated if there is a route that matches the filter 1767 ``128.9.0.0/16^- AND <^AS226>'' (this filter matches more specifics of 1768 128.9.0.0/16 that are received form AS226). The BGP path attributes of 1769 the matching routes are used to form the BGP path attributes of the 1770 route 128.9.0.0/16. Similarly, the aggregate 128.8.0.0/16 is generated if 1771 there is a route that matches the filter ``128.8.0.0/16^- AND <^AS226>''. 1772 However, its path attributes are generated using the atomic aggregation 1773 rules [13]. The aggregate 128.7.0.0/16 is always and atomically generated 1774 since the policy filter ``ANY'' matches any route in the routing table. 1776 The inject-at attribute lists the routers in the originating AS that inject 1777 this route to the interAS routing system. That is, these routers are 1778 configured to perform the aggregation. If the inject-at attribute is 1779 missing, all routers in the originating AS perform the aggregation. The 1780 route 128.7.0.0/16 in Figure 19 is injected by routers 7.7.7.1 and 9.9.9.1 1781 in AS1. 1783 When a set of routes are aggregated, the intent is to export only the 1784 aggregate route and suppress the exporting of the component routes to the 1785 outside world. However, to satisfy certain policy and topology constraints 1786 (e.g. a multi-homed component), it is often required to export some of 1787 the components. The export-comps attribute equals an RPSL filter that 1788 matches the routes that need to be exported to the neighboring ASes. If 1789 this attribute is missing, no component route needs to be exported to the 1790 neighboring ASes. The export-comps attribute can only be specified if 1791 an aggr-by attribute is specified for the route object. The component 1792 128.7.9.0/24 of route 128.7.0.0/16 in Figure 19 needs to be exported to 1793 other ASes. 1795 route: 128.9.0.0/16 1796 origin: AS1 1797 aggr-by: {128.9.0.0/16^-} AND <^AS226> 1799 route: 128.8.0.0/16 1800 origin: AS1 1801 aggr-by: ATOMIC {128.8.0.0/16^-} AND <^AS226> 1803 route: 128.7.0.0/16 1804 origin: AS1 1805 aggr-by: ATOMIC ANY 1806 inject-at: 7.7.7.1 1807 inject-at: 9.9.9.1 1808 export-comps: {128.7.9.0/24} 1810 Figure 19: Aggregate route objects. 1812 The holes attribute lists the component address prefixes which are not 1813 reachable through the aggregate route (perhaps that part of the address 1814 space is unallocated). Figure 20 shows a route object whose two components, 1815 namely 128.9.0.0/16 and 128.7.0.0/16, are not reachable via the aggregate. 1816 That is, if a data packet destined to a host in 128.9.0.0/16 is sent to AS1, 1817 AS1 can not deliver it to its final destination (i.e. it is black-holed). 1819 route: 128.0.0.0/12 1820 origin: AS1 1821 aggr-by: {128.0.0.0/12^-} 1822 holes: 128.7.0.0/16, 128.9.0.0/16 1824 Figure 20: The route 128.0.0.0/12 does not lead to destinations in 1825 128.9.0.0/16. 1827 10 inet-rtr Class 1829 Routers are specified using the inet-rtr class. The attributes of the 1830 inet-rtr class are shown in Figure 21. The inet-rtr attribute is a valid 1831 DNS name of the router described. Each alias attribute, if present, is a 1832 canonical DNS name for the router. The local-as attribute specifies the AS 1833 number of the AS which owns/operates this router. 1835 The value of an ifaddr attribute has the following syntax: 1837 masklen 1839 Attribute Value Type 1840 inet-rtr mandatory, single-valued, class key 1841 alias optional, multi-valued 1842 local-as mandatory, single-valued 1843 ifaddr see description in text mandatory, multi-valued 1844 peer see description in text optional, multi-valued 1846 Figure 21: inet-rtr Class Attributes 1848 [tunnel ] 1849 [action ] 1851 The IP address and the mask length are mandatory for each interface. If 1852 the interface is a tunnel, and if there is an inet-tunnel object describing 1853 the tunnel, the tunnel's name can also be specified. (An example inet-rtr 1854 object with tunnels is presented in Section 11.) Optionally an action can 1855 be specified to set other parameters of this interface. 1857 Figure 22 presents an example inet-rtr object. The name of the router is 1858 ``amsterdam.ripe.net''. ``amsterdam1.ripe.net'' is a canonical name for the 1859 router. The router is connected to 4 networks. Its IP addresses and mask 1860 lengths in those networks are specified in the ifaddr attributes. 1862 inet-rtr: Amsterdam.ripe.net 1863 alias: amsterdam1.ripe.net 1864 local-as: AS3333 1865 ifaddr: 192.87.45.190 masklen 24 1866 ifaddr: 192.87.4.28 masklen 24 1867 ifaddr: 193.0.0.222 masklen 27 1868 ifaddr: 193.0.0.158 masklen 27 1869 peer: BGP4 192.87.45.195 asno(AS3334), flap_damp() 1871 Figure 22: inet-rtr Objects 1873 Each peer attribute, if present, specifies a protocol peering with another 1874 router. The value of a peer attribute has the following syntax: 1876 1878 where is a protocol name, is the IP address of the 1879 peer router, and is a comma separated list of peering options 1880 for . Possible protocol names and attributes are defined in the 1881 dictionary (please see Section 8). In the above example, the router has 1882 a BGP peering with the router 192.87.45.195 in AS3334 and turns the flap 1883 damping on when importing routes from this router. 1885 11 inet-tunnel Class and Specifying Tunnels 1887 Tunneling is a fundamental networking technology that is used in a variety 1888 circumstances. A common use of tunneling is to incrementally deploy a new 1889 network layer protocol. The approach is to encapsulate ("tunnel") the new 1890 protocol through the existing network layer protocol, usually IP. Examples 1891 of this approach include include the multicast backbone [3], where multicast 1892 packets are encapsulated in IP packets using protocol 4 (IP in IP), and IPv6 1893 backbone [1], where IPv6 packets are encapsulated in IP packets using IP 1894 protocol 41 [14]. 1896 Another use of tunneling is to force congruence between the existing (IP 1897 unicast) topology and some new topology. Due the special requirements of IP 1898 multicast routing, the MBONE is also an example of this use of tunneling. 1900 This section describes general tunneling specification in RPSL. Both 1901 point-to-point and point-to-multipoint tunnels of encapsulation types, 1902 including DVMRP, GRE, and IPv6, are supported. In addition to the 1903 encapsulation, a protocol to run inside the tunnel can also be specified. 1905 Tunnels are specified using the inet-tunnel class. The attributes of the 1906 inet-tunnel class are shown in Figure 23. The inet-tunnel attribute is a 1907 valid RPSL name for the tunnel described. The tunnel-source attribute is 1908 the IP address of the source end point of the tunnel. The inet-tunnel and 1909 the tunnel-source attributes form the class key. That is, a point-to-point 1910 tunnel is specified using two tunnel object, one for each end point of the 1911 tunnel. The tunnel-sink attribute is the IP address of other end points of 1912 the tunnel. If the tunnel is a multi-point tunnel, multiple tunnel-sink 1913 attributes can be used to list each end point. The tunnel-encap attribute 1914 is an encapsulation name. Valid encapsulation names are defined in the 1915 dictionary and include IPinIP [29], IPMOBILITY [24], DVMRP [25], GRE [15], 1916 and IPv6 [10]. The tunnel-protocol attribute is a protocol name to run 1917 "inside" the tunnel. Valid protocol names are defined in the dictionary 1918 and include BGP, RIPng, DVMRP. See [27] for an application that uses BGP 1919 tunneled in GRE. The tunnel-mcast-tree attribute is used to describe the 1920 multicast tree construction mechanism used on the tunnel. Examples include 1921 PIM-DM and PIM-SM. 1923 The tunnel-in and tunnel-out attributes have the following format: 1925 tunnel-in: from [action ] accept 1926 tunnel-out: to [action ] announce 1928 Attribute Value Type 1929 inet-tunnel mandatory, single-valued, class key 1930 tunnel-source mandatory, single valued, class key 1931 tunnel-sink mandatory, multi-valued, class key 1932 tunnel-encap mandatory, single-valued 1933 tunnel-protocol mandatory, single valued 1934 tunnel-mcast-tree optional, single valued 1935 tunnel-in see description in text mandatory, multi-valued 1936 tunnel-out see description in text mandatory, multi-valued 1938 Figure 23: inet-tunnel Class Attributes 1940 where and are as in the aut-num class. The possible 1941 actions are defined in the dictionary and include 1943 ttlscope The minimum IP time-to-live required for a packet to be forwarded 1944 to the specified endpoint (in the case of multipoint tunnels, there may 1945 be per endpoint scopes). 1947 boundary A boundary attribute describes an administratively defined class 1948 of packets that will not be forwarded through the tunnel [22]. 1950 dvmrp-metric A DVMRP metric. 1952 These attributes are particularly relevant to multicast routing. Attributes 1953 for other tunnels can later be defined in the dictionary. The 1954 specifications describe filters that are appropriate for the tunnel's 1955 routing protocol. In the case of DVMRP, the filter specification can be the 1956 list of network prefixes accepted or advertised. 1958 Figure 24 has two examples of tunnel objects. In the first example, the 1959 router eugene-isp.nero.net has two tunnels: a DVMRP tunnel to dec3800- 1960 2-fddi-0.SanFrancisco.mci.net and a GRE tunnel to eugene-isp.nero.net. 1961 The DVMRP tunnel object is called MBONE-TUNNEL-EUG. eugene-isp.nero.net 1962 will accept any routes and forward packets to the DVMRP tunnel if the 1963 packet's time-to-live is greater than or equal to 64. In addition, 1964 eugene-isp.nero.net will not pass any packets that match the administrative 1965 scope boundary filter (in this case, 239.254.0.0/16). The GRE tunnel is 1966 named GRE-TUNNEL-EUG. 1968 12 Security Consideration 1970 This document describes RPSL, a language for expressing routing policies. 1971 As such, it does not itself have (or need) a security architecture. 1973 inet-rtr: eugene-isp.nero.net 1974 loacalas: AS4600 1975 ifaddr: 166.48.14.6 masklen 30 tunnel MBONE-TUNNEL-EUG 1976 ifaddr: 166.48.14.6 masklen 30 tunnel GRE-TUNNEL-EUG 1977 admin-c: DMM65 1978 tech-c: DMM65 1979 notify: nethelp@ns.uoregon.edu 1980 mnt-by: MAINT-AS3582 1981 changed: meyer@ns.uoregon.edu 961122 1982 source: RADB 1984 inet-tunnel: MBONE-TUNNEL-EUG 1985 tunnel-source: 166.48.14.6 # eugene-isp.nero.net 1986 tunnel-sink: 204.70.158.61 # dec3800-2-fddi-0.SanFrancisco.mci.net 1987 tunnel-encap: DVMRP 1988 tunnel-protocol: DVMRP 1989 tunnel-in: from 204.70.158.61 accept ANY 1990 tunnel-out: to 204.70.158.61 1991 action 1992 ttlscope=64; 1993 boundary={239.254.0.0/16}; 1994 dvmrp-metric=1; 1995 announce AS-NERO-TRANSIT 1996 ... 1998 inet-tunnel: GRE-TUNNEL-EUG 1999 tunnel-source: 166.48.14.6 2000 tunnel-sink: 206.42.19.240 2001 tunnel-protocol: DVMRP 2002 tunnel-mcast-tree: PIM-DM 2003 tunnel-encap: GRE 2004 tunnel-in: from 206.42.19.240 accept ANY 2005 tunnel-out: to 206.42.19.240 2006 action 2007 ttlscope=64; 2008 announce ANY 2009 ... 2011 Figure 24: inet-tunnel Objects 2013 However, any registry that implements this language should provide a 2014 mechanism for: 2016 1. Data Integrity and Origin Authentication. Both data origin and 2017 integrity can be provided by associating cryptographically generated 2018 digital signatures with each object in a IRR. There may be a single 2019 private key that signs for all objects associated with a given 2020 MAINTAINER object, or there may be finer grained control. As is common, 2021 it is expected that an implementation will keep the MAINTAINER private 2022 key off-line and it will be used to re-sign all objects for a given 2023 MAINTAINER. 2025 2. Public Key Distribution. It is expected that any IRR implemeting RPSL 2026 will use the Group Key Management Protocol (GKMP) [16]. The IETF IP 2027 Security Working Group is actively working on GKMP extensions to the 2028 standards-track ISAKMP key management protocol being developed in the 2029 same working group. 2031 3. Transaction Security. When a user is querying a registry for policy 2032 objects, to eliminate snooping and to eliminate third parties injecting 2033 objects, the server and the client may optionally use authentication and 2034 encryption techniques [12]. 2036 13 Acknowledgements 2038 We would like to thank Jessica Yu, Randy Bush, Alan Barrett, David 2039 Kessens, Bill Manning, Sue Hares, Ramesh Govindan, Kannan Varadhan, Satish 2040 Kumar, Craig Labovitz, Rusty Eddy, David J. LeRoy, David Whipple, Jon 2041 Postel, Deborah Estrin, Elliot Schwartz, Joachim Schmitz, Mark Prior, Tony 2042 Przygienda, David Woodgate, and the participants of the IETF RPS Working 2043 Group for various comments and suggestions. 2045 References 2047 [1] 6BONE. See http://www-6bone.lbl.gov/6bone/. 2049 [2] Internet 2050 Routing Registry. Procedures. http://www.ra.net/RADB.tools.docs/, 2051 http://www.ripe.net/db/doc.html. 2053 [3] MBONE. See http://www.best.com/ prince/techinfo/misc.html. 2055 [4] C. Alaettinouglu, D. Meyer, and J. Schmitz. Application of Routing 2056 Policy Specification Language (RPSL) on the Internet. Internet Draft 2057 draft-ietf-rps-appl-rpsl-00.ps, March 1997. Work in progress. 2059 [5] T. Bates. Specifying an `Internet Router' in the Routing Registry. 2060 Technical Report RIPE-122, RIPE, RIPE NCC, Amsterdam, Netherlands, 2061 October 1994. 2063 [6] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, 2064 M. Terpstra, and J. Yu. Representation of IP Routing Policies 2065 in a Routing Registry. Technical Report ripe-181, RIPE, RIPE NCC, 2066 Amsterdam, Netherlands, October 1994. 2068 [7] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, 2069 M. Terpstra, and J. Yu. Representation of IP Routing Policies in 2070 a Routing Registry. Technical Report RFC-1786, Network Information 2071 Center, March 1995. 2073 [8] T. Bates, J-M. Jouanigot, D. Karrenberg, P. Lothberg, and M. Terpstra. 2074 Representation of IP Routing Policies in the RIPE Database. Technical 2075 Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993. 2077 [9] R. Chandra, P. Traina, and T. Li. BGP Communities Attribute. Request 2078 for Comment RFC-1997, Network Information Center, August 1996. 2080 [10] A. Conta and S. Deering. Generic Packet Tunneling in IPv6. Technical 2081 Report draft-ietf-ipngwg-ipv6-tunnel-04.txt, October 1996. 2083 [11] D. Crocker. Standard for the format of ARPA Internet text messages. 2084 Request for Comment RFC-822, Network Information Center, August 1982. 2086 [12] D. Eastlake and C. Kaufman. Domain Name System Security Extensions. 2087 Technical Report RFC2065, January 1997. 2089 [13] V. Fuller, T. Li, J. Yu, and K. Varadhan. Classless Inter-Domain 2090 Routing (CIDR): an Address Assignment and Aggregation Strategy, 1993. 2092 [14] R. Gilligan and E. Nordmark. Transition Mechanisms for IPv6 Hosts and 2093 Routers. Technical Report RFC1933, April 1996. 2095 [15] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing 2096 Encapsulation (GRE). Technical Report RFC1701, October 1994. 2098 [16] H. Harney. Group Key Management Protocol (GKMP). Technical Report 2099 draft-harney-gkmp-arch-01.txt, draft-harney-gkmp-spec-01.txt, August 2100 1996. Informational RFC publication is pending. 2102 [17] D. Karrenberg and T. Bates. Description of Inter-AS Networks in the 2103 RIPE Routing Registry. Technical Report RIPE-104, RIPE, RIPE NCC, 2104 Amsterdam, Netherlands, December 1993. 2106 [18] D. Karrenberg and M. Terpstra. Authorisation and Notification of 2107 Changes in the RIPE Database. Technical Report ripe-120, RIPE, RIPE 2108 NCC, Amsterdam, Netherlands, October 1994. 2110 [19] B. W. Kernighan and D. M. Ritchie. The C Programming Language. 2111 Prentice-Hall, 1978. 2113 [20] A. Lord and M. Terpstra. RIPE Database Template for Networks 2114 and Persons. Technical Report ripe-119, RIPE, RIPE NCC, Amsterdam, 2115 Netherlands, October 1994. 2117 [21] A. M. R. Magee. RIPE NCC Database Documentation. Technical Report 2118 RIPE-157, RIPE, RIPE NCC, Amsterdam, Netherlands, May 1997. 2120 [22] D. Meyer. Administratively Scoped IP Multicast. Technical Report 2121 draft-ietf-mboned-admin-ip-space-01.txt, December 1996. 2123 [23] P. V. Mockapetris. Domain names - concepts and facilities. Request for 2124 Comment RFC-1034, Network Information Center, November 1987. 2126 [24] C. Perkins. Minimal Encapsulation within IP. Technical Report RFC2004, 2127 October 1996. 2129 [25] T. Pusateri. Distance Vector Multicast Routing Protocol. Technical 2130 Report draft-ietf-idmr-dvmrp-v3-03, September 1996. 2132 [26] Y. Rekhter. Inter-Domain Routing Protocol (IDRP). Journal of 2133 Internetworking Research and Experience, 4:61--80, 1993. 2135 [27] Y. Rekhter. Auto route injection with tunnelling, October 1996. NANOG, 2136 See http://www.academ.com/nanog/oct1996/multihome.html. 2138 [28] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4). Request for 2139 Comment RFC-1771, Network Information Center, March 1995. 2141 [29] W. Simpson. IP in IP Tunneling. Technical Report RFC1853, October 2142 1995. 2144 A Routing Registry Sites 2146 The set of routing registries as of November 1996 are RIPE, RADB, CANet, MCI 2147 and ANS. You may contact one of these registries to find out the current 2148 list of registries. 2150 B Authors' Addresses 2152 Cengiz Alaettinoglu 2153 USC Information Sciences Institute 2154 4676 Admiralty Way, Suite 1001 2155 Marina del Rey, CA 90292 2156 email: cengiz@isi.edu 2158 Tony Bates 2159 Cisco Systems, Inc. 2160 170 West Tasman Drive 2161 San Jose, CA 95134 2162 email: tbates@cisco.com 2163 Elise Gerich 2164 At Home Network 2165 385 Ravendale Drive 2166 Mountain View, CA 94043 2167 email: epg@home.net 2169 Daniel Karrenberg 2170 RIPE Network Coordination Centre (NCC) 2171 Kruislaan 409 2172 NL-1098 SJ Amsterdam 2173 Netherlands 2174 email: dfk@ripe.net 2176 David Meyer 2177 University of Oregon 2178 Eugene, OR 97403 2179 email: meyer@antc.uoregon.edu 2181 Marten Terpstra 2182 c/o Bay Networks, Inc. 2183 2 Federal St 2184 Billerica MA 01821 2185 email: marten@BayNetworks.com 2187 Curtis Villamizar 2188 ANS 2189 email: curtis@ans.net