idnits 2.17.1 draft-ietf-rps-rpsl-02.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-04-19) 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 551 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 805 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 109 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 1461: '... MANDATORY | OPTIONAL ((' 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 1513, but not defined == Missing Reference: '65535' is mentioned on line 1513, but not defined == Missing Reference: '4294967200' is mentioned on line 1488, 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' == 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. '24') -- Possible downref: Non-RFC (?) normative reference: ref. '25' -- Possible downref: Non-RFC (?) normative reference: ref. '26' ** Obsolete normative reference: RFC 1654 (ref. '27') (Obsoleted by RFC 1771) ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. '28') Summary: 22 errors (**), 0 flaws (~~), 17 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Cengiz Alaettinoglu 3 Expires October 23, 1997 USC/ISI 4 draft-ietf-rps-rpsl-02.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 April 23, 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 02.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 3 49 2 RPSL Names, Reserved Words, and Representation 4 51 3 mntner Class 6 53 4 person Class 7 55 5 route Class 8 57 6 Set Classes 9 59 6.1 route-set Class . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 6.2 as-set Class . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 6.3 Predefined Set Objects . . . . . . . . . . . . . . . . . . . . . . 12 65 6.4 Hierarchical Set Names . . . . . . . . . . . . . . . . . . . . . . 12 67 7 aut-num Class 13 69 7.1 import Attribute: Import Policy Specification . . . . . . . . . . 13 71 7.1.1Peering Specification . . . . . . . . . . . . . . . . . . . . . 14 73 7.1.2Action Specification . . . . . . . . . . . . . . . . . . . . . . 16 75 7.1.3Filter Specification . . . . . . . . . . . . . . . . . . . . . . 16 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 38 95 9.1 Specifying Static Routes . . . . . . . . . . . . . . . . . . . . . 38 97 9.2 Specifying Aggregate Routes . . . . . . . . . . . . . . . . . . . . 39 99 10inet-rtr Class 41 101 11inet-tunnel Class and Specifying Tunnels 42 103 12Security Consideration 45 105 13Acknowledgements 45 107 A Routing Registry Sites 47 109 B Authors' Addresses 47 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] and [4] for more details on 132 the IRR. 134 In the following sections, we present the classes that are used to define 135 various policy and administrative objects. The "mntner" class defines 136 entities authorized to add, delete and modify a set of objects. The 137 "person" class describes technical and administrative contact personnel. 138 Autonomous systems (ASes) are specified using the "aut-num" class. Routes 139 are specified using the "route" class. Sets of ASes and routes can be 140 defined using the "as-set" and "route-set" classes. The "dictionary" 141 class provides the extensibility to the language. The "inet-rtr" class 142 is used to specify routers. Tunnels are specified using "inet-tunnel" 143 class. Many of these classes were originally defined in earlier documents 144 [6, 18, 20, 17, 5] and have all been enhanced. 146 This document is self-contained. However, the reader is encouraged to read 147 RIPE-181 [7] and the associated documents [18, 20, 17, 5] as they provide 148 significant background as to the motivation and underlying principles behind 149 RIPE-181 and consequently, RPSL. They further cover the basic concept of the 150 Internet Routing Registry (IRR) [2, 4], the data repository for storing 151 global RPSL based routing policies and a fundamental component in the 152 application of RPSL. For a tutorial on RPSL, the reader should read the RPSL 153 applications document [4]. 155 2 RPSL Names, Reserved Words, and Representation 157 Each class has a set of attributes which store a piece of information about 158 the objects of the class. Attributes can be mandatory or optional: A 159 mandatory attribute has to be defined for all objects of the class; optional 160 attributes can be skipped. Attributes can also be single or multiple 161 valued. Each object is uniquely identified by a set of attributes, referred 162 to as the class ``key''. 164 The value of an attribute has a type. The following types are most widely 165 used. Note that RPSL is case insensitive. 167 Many objects in RPSL have a name. An is made 168 up of letters, digits, the character underscore ``_'', and the character 169 hyphen ``-''; the first character of a name must be a letter, and the 170 last character of a name must be a letter or a digit. The following 171 words are reserved by RPSL, and they can not be used as names: 173 any as-any rs-any peeras 174 and or not 175 atomic from to at action accept announce except refine 176 networks into 178 Names starting with certain prefixes are reserved for certain object 179 types. Names starting with ``as-'' are reserved for as set names. 180 Names starting with ``rs-'' are reserved for route set names. 182 An AS number x is represented as the string ``ASx''. That is, 183 the AS 226 is represented as AS226. 185 An IPv4 address is represented as a sequence of four integers 186 in the range from 0 to 255 separated by the character dot ``.''. For 187 example, 128.9.128.5 represents a valid IPv4 address. In the rest of 188 this document, we may refer to IPv4 addresses as IP addresses. 190 An address prefix is represented as an IPv4 address 191 followed by the character slash ``/'' followed by an integer in the 192 range from 0 to 32. The following are valid address prefixes: 193 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the following address 194 prefixes are invalid: 0/0, 128.9/16 since 0 or 128.9 are not strings 195 containing four integers. 197 A date is represented as an eight digit integer of the form YYYYMMDD 198 where YYYY represents the year, MM represents the month of the year (01 199 through 12), and DD represents the day of the month (01 through 31). 200 For example, June 24, 1996 is represented as 19960624. 202 is as described in RFC-822[11]. 204 is as described in RFC-1034[22]. 206 is either a full name of a person or a uniquely assigned 207 NIC-handle. Its syntax has the following form: 209 [] 210 | 212 E.g. 213 John E Doe 214 JED31 216 A NIC handle is an identifier used by routing, address allocation, and 217 other registries to unambiguously refer to people. 219 is a sequence of ASCII characters. 221 is a name of an object of type X. That is is a name of an mntner object. 224 is a name of an IRR registry. The routing registries are 225 listed in Appendix A. 227 A value of an attribute may also be a lists of one of these types. A list 228 is represented by separating the list members by commas ``,''. For example, 229 ``AS1, AS2, AS3, AS4'' is a list of AS numbers. Note that being list valued 230 and being multiple valued are orthogonal. A multiple valued attribute has 231 more than one value each of which may or may not be a list depending on 232 the attribute. On the other hand a single valued attribute may have a list 233 value. 235 An RPSL object is textually represented as a list of attribute-value pairs. 236 Each attribute-value pair is written on a separate line. The attribute name 237 starts at column 0, followed by character ``:'' and followed by the value 238 of the attribute. The object's representation ends when a blank line is 239 encountered. An attribute's value can be split over multiple lines, by 240 starting the continuation lines with a white-space (`` '' or tab) character. 241 The order of attribute-value pairs is significant. 243 An object's description may contain comments. A comment can be anywhere in 244 an object's definition, it starts at the first ``#'' character on a line and 245 ends at the first end-of-line character. White space characters can be used 246 to improve readability. 248 3 mntner Class 250 The mntner class defines entities that can create, delete and update RPSL 251 objects. A provider, before he/she can create any RPSL object, first needs 252 to create a mntner object. The attributes of the mntner class are shown in 253 Figure 1. A more complete description of mntner class can be found in [18]. 254 Here, we summarize the mntner class for completeness. 256 Attribute Value Type 257 mntner mandatory, single-valued, class key 258 descr mandatory, single-valued 259 auth see description in text mandatory, multi-valued 260 upd-to mandatory, multi-valued 261 mnt-nfy optional, multi-valued 262 tech-c mandatory, multi-valued 263 admin-c mandatory, multi-valued 264 remarks optional, multi-valued 265 notify optional, multi-valued 266 mnt-by mandatory, multi-valued 267 changed mandatory, multi-valued 268 source mandatory, single-valued 270 Figure 1: mntner Class Attributes 272 The mntner attribute is mandatory and is the class key attribute. Its value 273 is an RPSL name. The auth attribute specifies the scheme that will be used 274 to identify and authenticate update requests from this maintainer. It has 275 the following syntax: 277 auth: 279 E.g. 280 auth: NONE 281 auth: CRYPT-PW dhjsdfhruewf 282 auth: MAIL-FROM .*@ripe\.net 284 The 's currently defined are: NONE, MAIL-FROM, PGP and CRYPT-PW. 285 The is additional information required by a particular scheme: 286 in the case of MAIL-FROM, it is a regular expression matching valid email 287 addresses; in the case of CRYPT-PW, it is a password in UNIX crypt format; 288 and in the case of PGP, it is a PGP public key. If multiple auth attributes 289 are specified, an update request satisfying any one of them is authenticated 290 to be from the maintainer. 292 The upd-to attribute is an email address. On an unauthorized update 293 attempt of an object maintained by this maintainer, an email message will 294 be sent to this address. The mnt-nfy attribute is an email address. A 295 notification message will be forwarded to this email address whenever an 296 object maintained by this maintainer is added, changed or deleted. 298 The descr attribute is a short, free-form textual description of the object. 299 The tech-c attribute is a technical contact person. This is someone to 300 be contacted for technical problems such as misconfiguration. The admin-c 301 attribute is an administrative contact person. The remarks attribute is a 302 free text explanation or clarification. The notify attribute is an email 303 address to which notifications of changes to this object should be sent. 304 The mnt-by attribute is a mntner object name. The authorization for changes 305 to this object is governed by that maintainer object. The changed attribute 306 documents who last changed this object, and when this change was made. Its 307 syntax has the following form: 309 changed: 311 E.g. 312 changed: johndoe@terabit-labs.nn 19900401 314 The identifies the person who made the last change. 315 is the date of the change. The source attribute specifies the 316 registry where the object is registered. 318 The descr, tech-c, admin-c, remarks, notify, mnt-by, changed and source 319 attributes are attributes of all RPSL classes. Their syntax, semantics, and 320 mandatory, optional, multi-valued, or single-valued status are the same for 321 for all classes. We do not further discuss them in other sections. 323 4 person Class 325 A person class is used to describe information about people. Even though it 326 does not describe routing policy, we still describe it here briefly since 327 many policy objects make reference to person objects. The details of the 328 person class can be found in Reference [20]. 330 The attributes of the person class are shown in Figure 2. The person 331 attribute is the full name of the person. The phone and the fax-no 332 attributes have the following syntax: 334 phone: + [ext. ] 336 E.g.: 337 phone: +31 20 12334676 338 phone: +44 123 987654 ext. 4711 340 Attribute Value Type 341 person mandatory, single-valued, class key 342 address mandatory, multi-valued 343 phone see description in text mandatory, multi-valued 344 fax-no same as phone optional, multi-valued 345 e-mail mandatory, multi-valued 346 nic-hdl see description in text optional, single-valued 348 Figure 2: person Class Attributes 350 5 route Class 352 Each interAS route originated by an AS is specified using a route object. 353 The attributes of the route class are shown in Figure 3. The route 354 attribute is the address prefix of the route and the origin attribute is 355 the AS number of the AS that originates the route into the interAS routing 356 system. The route and origin attribute pair is the class key. 358 Attribute Value Type 359 route mandatory, single-valued, class key 360 origin mandatory, single-valued, class key 361 withdrawn optional, single-valued 362 member-of optional, single-valued 363 see Section 6 364 inject-at see Section 9 optional, multi-valued 365 aggr-by see Section 9 optional, single-valued 366 export-comps see Section 9 optional, single-valued 367 holes see Section 9 optional, single-valued 369 Figure 3: route Class Attributes 371 The Figure 4 shows examples of four route objects. Note that the last two 372 route objects have the same address prefix, namely 128.8.0.0/16. However, 373 they are different route objects since they are originated by different ASes 374 (i.e. they have different keys). 376 The withdrawn attribute, if present, signifies that the originator AS no 377 longer originates this address prefix in the Internet. Its value is a date 378 indicating the date of withdrawal. In Figure 4, the last route object is 379 withdrawn (i.e. no longer originated by AS2) on June 24, 1996. 381 route: 128.9.0.0/16 382 origin: AS226 384 route: 128.99.0.0/16 385 origin: AS226 387 route: 128.8.0.0/16 388 origin: AS1 390 route: 128.8.0.0/16 391 origin: AS2 392 withdrawn: 19960624 394 Figure 4: Route Objects 396 6 Set Classes 398 To specify policies, it is often useful to define sets of objects. For 399 this purpose we define two classes: route-set and as-set. These classes 400 define a named set. The members of these sets can be specified by either 401 explicitly listing them in the set object's definition, or implicitly by 402 having route and aut-num objects refer to the set name in their definitions, 403 or a combination of both methods. 405 6.1 route-set Class 407 The attributes of the route-set class are shown in Figure 5. The route-set 408 attribute defines the name of the set. It is an RPSL name that starts with 409 ``rs-''. The members attribute lists the members of the set. The members 410 attribute is a list of address prefixes or other route-set names. 412 Attribute Value Type 413 route-set mandatory, single-valued, 414 class key 415 members list of or optional, single-valued 416 417 members-by-referral list of optional, single-valued 419 Figure 5: route-set Class Attributes 421 Figure 6 presents some example route-set objects. The set rs-foo contains 422 two address prefixes, namely 128.9.0.0/16 and 128.9.0.0/16. The set rs-bar 423 contains the members of the set rs-foo and the address prefix 128.7.0.0/16. 424 The set rs-empty contains no members. 426 route-set: rs-foo 427 members: 128.9.0.0/16, 128.9.0.0/24 429 route-set: rs-bar 430 members: 128.7.0.0/16, rs-foo 432 route-set: rs-empty 434 Figure 6: route-set Objects 436 The members-by-referral attribute is a list of maintainer names or the 437 keyword ANY. If this attribute is used, the route set also includes address 438 prefixes whose route objects are registered by one of these maintainers and 439 whose member-of attribute refers to the name of this route set. If the 440 value of a members-by-referral attribute is ANY, any route object referring 441 to the route set name is a member. If the members-by-referral attribute 442 is missing, only the address prefixes listed in the members attribute are 443 members of the set. 445 route-set: rs-foo 446 members-by-referral: MNTR-ME, MNTR-YOU 448 route-set: rs-bar 449 members: 128.7.0.0/16 450 members-by-referral: MNTR-YOU 452 route: 128.9.0.0/16 453 origin: AS1 454 member-of: rs-foo 455 mnt-by: MNTR-ME 457 route: 128.8.0.0/16 458 origin: AS2 459 member-of: rs-foo, rs-bar 460 mnt-by: MNTR-YOU 462 Figure 7: route-set objects. 464 Figure 7 presents example route-set objects that use the members-by-referral 465 attribute. The set rs-foo contains two address prefixes, namely 466 128.8.0.0/16 and 128.9.0.0/16 since the route objects for 128.8.0.0/16 and 467 128.9.0.0/16 refer to the set name rs-foo in their member-of attribute. The 468 set rs-bar contains the address prefixes 128.7.0.0/16 and 128.8.0.0/16. The 469 route 128.7.0.0/16 is explicitly listed in the members attribute of rs-bar, 470 and the route object for 128.8.0.0/16 refer to the set name rs-bar in its 471 member-of attribute. 473 Note that, if an address prefix is listed in a members attribute of a route 474 set, it is a member of that route set. The route object corresponding to 475 this address prefix does not need to contain a member-of attribute referring 476 to this set name. The member-of attribute of the route class is an 477 additional mechanism for specifying the members indirectly. 479 6.2 as-set Class 481 The attributes of the as-set class are shown in Figure 8. The as-set 482 attribute defines the name of the set. It is an RPSL name that starts with 483 ``as-''. The members attribute lists the members of the set. The members 484 attribute is a list of AS numbers, or other as-set names. 486 Attribute Value Type 487 as-set mandatory, single-valued, 488 class key 489 members list of or optional, single-valued 490 491 members-by-referral list of optional, single-valued 493 Figure 8: as-set Class Attributes 495 Figure 9 presents two as-set objects. The set as-foo contains two ASes, 496 namely AS1 and AS2. The set as-bar contains the members of the set as-foo 497 and AS3, that is it contains AS1, AS2, AS3. 499 as-set: as-foo as-set: as-bar 500 members: AS1, AS2 members: AS3, as-foo 502 Figure 9: as-set objects. 504 The members-by-referral attribute is a list of maintainer names or the 505 keyword ANY. If this attribute is used, the AS set also includes ASes 506 whose aut-num objects are registered by one of these maintainers and whose 507 member-of attribute refers to the name of this AS set. If the value of a 508 members-by-referral attribute is ANY, any AS object referring to the AS set 509 is a member of the set. If the members-by-referral attribute is missing, 510 only the ASes listed in the members attribute are members of the set. 512 Figure 10 presents an example as-set object that uses the members-by- 513 referral attribute. The set as-foo contains AS1, AS2 and AS3. AS4 is not a 514 as-set: as-foo 515 members: AS1, AS2 516 members-by-referral: MNTR-ME 518 aut-num: AS3 aut-num: AS4 519 member-of: as-foo member-of: as-foo 520 mnt-by: MNTR-ME mnt-by: MNTR-OTHER 522 Figure 10: as-set objects. 524 member of the set as-foo even though the aut-num object references as-foo. 525 This is because MNTR-OTHER is not listed in the as-foo's members-by-referral 526 attribute. 528 6.3 Predefined Set Objects 530 In a context that expects a route set (e.g. members attribute of the 531 route-set class), an AS number ASx defines the set of routes that are 532 originated by ASx; and an as-set AS-X defines the set of routes that are 533 originated by the ASes in AS-X. A route p is said to be originated by ASx if 534 there is a route object for p with ASx as the value of the origin attribute. 535 For example, in Figure 11, the route set rs-special contains 128.9.0.0/16, 536 routes of AS1 and AS2, and routes of the ASes in AS set AS-FOO. 538 route-set: rs-special 539 members: 128.9.0.0/16, AS1, AS2, AS-FOO 541 Figure 11: Use of AS numbers and AS sets in route sets. 543 The keyword rs-any defines the set of all routes registered in IRR. The 544 keyword as-any defines the set of all ASes registered in IRR. 546 6.4 Hierarchical Set Names 548 Set names can be hierarchical. A hierarchical set name is a sequence of set 549 names and AS numbers separated by colons ``:''. For example, the following 550 names are valid: AS1:AS-CUSTOMERS, AS1:RS-EXCEPTIONS, AS1:RS-EXPORT:AS2, 551 RS-EXCEPTIONS:RS-BOGUS. All set names in an hierarchical as-set name should 552 start with ``as-''; and all set names in an hierarchical route-set name 553 should start with ``rs-''. 555 A set object with name X1:...:Xn-1:Xn can only be created by the maintainer 556 of the object with name X1:...:Xn-1. That is, only the maintainer of AS1 557 can create a set with name AS1:AS-FOO; and only the maintainer of AS1:AS-FOO 558 can create a set with name AS1:AS-FOO:AS-BAR. 560 7 aut-num Class 562 ASes are specified using the aut-num class. The attributes of the aut-num 563 class are shown in Figure 12. The value of the aut-num attribute is the 564 AS number of the AS described by this object. The as-name attribute is 565 a symbolic name (in RPSL name syntax) of the AS. The import, export and 566 default routing policies of the AS are specified using import, export and 567 default attributes respectively. 569 Attribute Value Type 570 aut-num mandatory, single-valued, class key 571 as-name mandatory, single-valued 572 member-of optional, single-valued 573 import see Section 7.1 optional, multi valued 574 export see Section 7.2 optional, multi valued 575 default see Section 7.5 optional, multi valued 577 Figure 12: aut-num Class Attributes 579 7.1 import Attribute: Import Policy Specification 581 A typical interconnection of ASes is shown in Figure 13. In this example 582 topology, there are three ASes, AS1, AS2, and AS3; two exchange points, 583 EX1 and EX2; and six routers. Routers connected to the same exchange 584 point peer with each other, i.e. open a connection for exchanging routing 585 information. Each router would export a subset of the routes it has to its 586 peer routers. Peer routers would import a subset of these routes. A router 587 while importing routes would set some route attributes. For example, AS1 588 can assign higher preference values to the routes it imports from AS2 so 589 that it prefers AS2 over AS3. While exporting routes, a router may also 590 set some route attributes in order to affect route selection by its peers. 591 For example, AS2 may set the MULTI-EXIT-DISCRIMINATOR BGP attribute so that 592 AS1 prefers to use the router 9.9.9.2. Most interAS policies are specified 593 by specifying what route subsets can be imported or exported, and how the 594 various route attributes are set and used. 596 In RPSL, an import policy is divided into import policy expressions. Each 597 import policy expression is specified using an import attribute. The import 598 attribute has the following syntax (we will extend this syntax later in 599 Sections 7.3 and 7.6): 601 ---------------------- ---------------------- 602 | 7.7.7.1 |-------| |-------| 7.7.7.2 | 603 | | ======== | | 604 | AS1 | EX1 |-------| 7.7.7.3 AS2 | 605 | | | | 606 | 9.9.9.1 |------ ------| 9.9.9.2 | 607 ---------------------- | | ---------------------- 608 =========== 609 | EX2 610 ---------------------- | 611 | 9.9.9.3 |--------- 612 | | 613 | AS3 | 614 ---------------------- 616 Figure 13: Example topology consisting of three ASes, AS1, AS2, and AS3; 617 two exchange points, EX1 and EX2; and six routers. 619 import: from [action ] 620 . . . 621 from [action ] 622 accept 624 The action specification is optional. The semantics of an import attribute 625 is as follows: the set of routes that are matched by are imported 626 from all the peers specified in ; while importing routes at 627 , is executed. 629 E.g. 630 aut-num: AS1 631 import: from AS2 action pref = 1; accept { 128.9.0.0/16 } 633 This example states that the route 128.9.0.0/16 is accepted from AS2 with 634 preference 1. In the next few subsections, we will describe how peerings, 635 actions and filters are specified. 637 7.1.1 Peering Specification 639 Our example above used an AS number to specify peerings. The peerings 640 can be specified at different granularities. The syntax of a peering 641 specification is as follows: 643 [] [at ] 644 | [at ] 646 where and are IP addresses of routers, 647 is an AS number, and is an AS set name. must 648 be the AS number of . Both and 649 are optional. We first describe the semantics using the first form. 650 If both and are specified, this peering 651 specification identifies only the peering between these two routers. If 652 only is specified, this peering specification identifies 653 all the peerings between and any of its peer routers in 654 . If only is specified, this peering specification 655 identifies all the peerings between any router in the local AS and 656 . If neither nor is specified, 657 this peering specification identifies all the peerings between any router in 658 the local AS and any router in . If the form is used, the 659 peering specification identifies all the peerings between and 660 any of its peer routers in one of the ASes in . If 661 is not specified, the peering specification identifies all the peerings 662 between any router in the local AS and any of its peer routers in one of the 663 ASes in . 665 We next give examples. Consider the topology of Figure 13 where AS1 has 666 two routers 7.7.7.1 and 9.9.9.1; AS2 has three routers 7.7.7.2, 7.7.7.3 and 667 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 668 each other; 9.9.9.1, 9.9.9.2 and 9.9.9.3 peer with each other. In example 669 (1) below 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2. 671 (1) aut-num: AS1 672 import: from AS2 7.7.7.2 at 7.7.7.1 accept { 128.9.0.0/16 } 674 (2) aut-num: AS1 675 import: from AS2 at 7.7.7.1 accept { 128.9.0.0/16 } 677 (3) aut-num: AS1 678 import: from AS2 accept { 128.9.0.0/16 } 680 (4) as-set: AS-FOO 681 members: AS2, AS3 683 aut-num: AS1 684 import: from AS-FOO at 9.9.9.1 accept { 128.9.0.0/16 } 686 (5) aut-num: AS1 687 import: from AS-FOO accept { 128.9.0.0/16 } 689 (6) aut-num: AS1 690 import: from AS2 at 9.9.9.1 accept { 128.9.0.0/16 } 691 import: from AS3 at 9.9.9.1 accept { 128.9.0.0/16 } 693 (7) aut-num: AS1 694 import: from AS2 accept { 128.9.0.0/16 } 695 import: from AS3 accept { 128.9.0.0/16 } 697 In example (2), 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2 and 7.7.7.3. In 698 example (3), 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2 and 7.7.7.3, and 699 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2. In example (4), 9.9.9.1 imports 700 128.9.0.0/16 from 9.9.9.2 and 9.9.9.3. In example (5), 9.9.9.1 imports 701 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 702 7.7.7.2 and 7.7.7.3. The example (4) and (5) are equivalent to examples (6) 703 and (7) respectively. 705 7.1.2 Action Specification 707 Policy actions in RPSL set or modify route attributes, such as assigning a 708 preference to a route, adding a community to the community attribute, or 709 setting the MULTI-EXIT-DISCRIMINATOR attribute. Policy actions can also 710 instruct routers to perform special operations, such as route flap damping. 712 The routing policy attributes whose values can be modified in policy actions 713 are specified in the RPSL dictionary. Please refer to Section 8 for a list 714 of these attributes. Each action in RPSL is terminated by the character 715 ';'. It is possible to form composite policy actions by listing them one 716 after the other. In a composite policy action, the actions are executed 717 left to right. For example, 719 aut-num: AS1 720 import: from AS2 721 action pref = 10; med = 0; community.append(10250, {3561,10}); 722 accept { 128.9.0.0/16 } 724 sets pref to 10, and then med to 0. 726 7.1.3 Filter Specification 728 A policy filter is a logical expression which when applied to a set of 729 routes returns a subset of these routes. We say that the policy filter 730 matches the subset returned. The policy filter can match routes using any 731 route attribute, such as the destination address prefix (or NLRI), AS-path, 732 or community attributes. 734 The following policy filters can be used to select a subset of routes: 736 ANY 737 The filter-keyword ANY matches all routes. 739 Address-Prefix Set 740 This is an explicit list of address prefixes enclosed in braces '{' and 741 '}'. The policy filter matches the set of routes whose destination 742 address-prefix is in the set. For example: 744 { 0.0.0.0/0 } 745 { 128.9.0.0/16, 128.8.0.0/16, 128.7.128.0/17, 5.0.0.0/8 } 746 { } 748 An address prefix can be optionally followed by an operator '^-', '^+', 749 '^n', or '^n-m' where n and m are integers. ^- operator is the 750 exclusive more specifics operator; it stands for the more specifics of 751 the address prefix excluding the address prefix itself. ^+ operator is 752 the inclusive more specifics operator; it stands for the more specifics 753 of the address prefix including the address prefix itself. ^n operator, 754 stands for all the length n specifics of the address prefix. ^n-m 755 operator, stands for all the length n to length m specifics of the 756 address prefix. For example, the set 758 { 5.0.0.0/8^+, 128.9.0.0/16^-, 30.0.0.0/8^16, 30.0.0.0/8^24-32 } 760 contains all the more specifics of 5.0.0.0/8 including 5.0.0.0/8, all 761 the more specifics of 128.9.0.0/16 excluding 128.9.0.0/16, all the more 762 specifics of 30.0.0.0/8 which are of length 16 such as 30.9.0.0/16, and 763 all the more specifics of 30.0.0.0/8 which are of length 24 to 32 such 764 as 30.9.9.96/28. 766 Route Set Name 767 A route set name matches the set of routes that are members of the set. 768 A route set name may be a name of a route-set object, an AS number, or a 769 name of an as-set object (AS numbers and as-set names implicitly define 770 route sets; please see Section 6.3). For example: 772 aut-num: AS1 773 import: from AS2 action pref = 1; accept AS2 774 import: from AS2 action pref = 1; accept AS-FOO 775 import: from AS2 action pref = 1; accept RS-FOO 777 The keyword PeerAS can be used instead of the AS number of the peer AS. 778 PeerAS is particularly useful when the peering is specified using an AS 779 set. For example: 781 as-set: AS-FOO 782 members: AS2 AS3 784 aut-num: AS1 785 import: from AS-FOO action pref = 1; accept PeerAS 787 is same as: 789 aut-num: AS1 790 import: from AS2 action pref = 1; accept AS2 791 import: from AS3 action pref = 1; accept AS3 793 A route set name can also be followed by one of the operators '^-', 794 '^+', '^n' or '^n-m'. These operators are distributive over the route 795 sets. For example, { 5.0.0.0/8, 6.0.0.0/8 }^+ equals { 5.0.0.0/8^+, 796 6.0.0.0/8^+ }, and AS1^- equals all the exclusive more specifics of 797 routes originated by AS1. 799 AS Path Regular Expressions 800 An AS-path regular expression can be used as a policy filter by 801 enclosing the expression in `<' and `>'. An AS-path policy filter 802 matches the set of routes which traverses a sequence of ASes matched 803 by the AS-path regular expression. A router can check this using the 804 AS_PATH attribute in the Border Gateway Protocol [27], or the RD_PATH 805 attribute in the Inter-Domain Routing Protocol[25]. 807 AS-path Regular Expressions are POSIX compliant regular expressions over 808 the alphabet of AS numbers. The regular expression constructs are as 809 follows: 811 ASN where ASN is an AS number. ASN matches the AS-path that is 812 of length 1 and contains the corresponding AS number (e.g. 813 AS-path regular expression AS1 matches the AS-path ``1''). 815 The keyword PeerAS can be used instead of the AS number of 816 the peer AS. 818 AS-set where AS-set is an AS set name. AS-set matches the AS-paths 819 that is matched by one of the ASes in the AS-set. 821 . matches the AS-paths matched by any AS number. 823 [...] is an AS number set. It matches the AS-paths matched by the 824 AS numbers listed between the brackets. The AS numbers in 825 the set are separated by white space characters. If a `-' 826 is used between two AS numbers in this set, all AS numbers 827 between the two AS numbers are included in the set. If 828 an as-set name is listed, all AS numbers in the as-set are 829 included. 831 [^...] is a complemented AS number set. It matches any AS-path which 832 is not matched by the AS numbers in the set. 834 ^ Matches the empty string at the beginning of an AS-path. 836 $ Matches the empty string at the end of an AS-path. 838 We next list the regular expression operators in the decreasing order of 839 evaluation. These operators are left associative, i.e. performed left 840 to right. 842 Unary postfix operators * + ? 843 For a regular expression A, A* matches zero or more 844 occurrences of A; A+ matches one or more occurrences of A; 845 A? matches zero or one occurrence of A. 847 Binary catenation operator 848 This is an implicit operator and exists between two 849 regular expressions A and B when no other explicit 850 operator is specified. The resulting expression A B 851 matches an AS-path if A matches some prefix of the AS-path 852 and B matches the rest of the AS-path. 854 Binary alternative (or) operator | 855 For a regular expressions A and B, A | B matches any 856 AS-path that is matched by A or B. 858 Parenthesis can be used to override the default order of evaluation. 859 White spaces can be used to increase readability. 861 The following are examples of AS-path filters: 863 864 <^AS1> 865 866 <^AS1 AS2 AS3$> 867 <^AS1 .* AS2$>. 869 The first example matches any route whose AS-path contains AS3, the 870 second matches routes whose AS-path starts with AS1, the third matches 871 routes whose AS-path ends with AS2, the fourth matches routes whose 872 AS-path is exactly ``1 2 3'', and the fifth matches routes whose AS-path 873 starts with AS1 and ends in AS2 with any number of AS numbers in 874 between. 876 Composite Policy Filters 878 The following operators (in decreasing order of evaluation) can be used to 879 form composite policy filters: 881 NOT Given a policy filter x, NOT x matches the set of routes that are not 882 matched by x. That is it is the negation of policy filter x. 884 AND Given two policy filters x and y, x AND y matches the intersection of 885 the routes that are matched by x and that are matched by y. 887 OR Given two policy filters x and y, x OR y matches the union of the routes 888 that are matched by x and that are matched by y. 890 Note that an OR operator can be implicit, that is `x y' is equivalent to `x 891 OR y'. 893 E.g. 894 NOT {128.9.0.0/16, 128.8.0.0/16} 895 AS226 AS227 OR AS228 896 AS226 AND NOT {128.9.0.0/16} 897 AS226 AND {0.0.0.0/0^0-18} 899 The first example matches any route except 128.9.0.0/16 and 128.8.0.0/16. 900 The second example matches the routes of AS226, AS227 and AS228. The third 901 example matches the routes of AS226 except 128.9.0.0/16. The fourth example 902 matches the routes of AS226 whose length are shorter than 19. 904 Policy filters can also use the values of other attributes for comparison. 905 The attributes whose values can be used in policy filters are specified in 906 the RPSL dictionary. Please refer to Section 8 for details. An example 907 using the the BGP community attribute is shown below: 909 aut-num: AS1 910 export: to AS2 announce AS1 AND NOT community.contains(NO_EXPORT) 912 Filters using the routing policy attributes defined in the dictionary are 913 evaluated before evaluating the operators AND, OR and NOT. 915 7.1.4 Example Policy Expressions 917 aut-num: AS1 918 import: from AS2 action pref = 1; 919 from AS3 action pref = 2; 920 accept AS4 922 The above example states that AS4's routes are accepted from AS2 with 923 preference 1, and from AS3 with preference 2 (routes with lower integer 924 preference values are preferred over routes with higher integer preference 925 values). 927 aut-num: AS1 928 import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; 929 from AS2 action pref = 2; 930 accept AS4 932 The above example states that AS4's routes are accepted from AS2 on peering 933 7.7.7.1-7.7.7.2 with preference 1, and on any other peering with AS2 with 934 preference 2. 936 7.2 export Attribute: Export Policy Specification 938 Similarly, an export policy expression is specified using an export 939 attribute. The export attribute has the following syntax: 941 export: to [action ] 942 . . . 943 to [action ] 944 announce 946 The action specification is optional. The semantics of an export attribute 947 is as follows: the set of routes that are matched by are 948 exported to all the peers specified in ; while exporting routes at 949 , is executed. 951 E.g. 952 aut-num: AS1 953 export: to AS2 action med = 5; community .= 70; 954 announce AS4 956 In this example, AS4's routes are announced to AS2 with the med attribute's 957 value set to 5 and community 70 added to the community list. 959 Example: 961 aut-num: AS1 962 export: to AS-FOO announce ANY 964 In this example, AS1 announces all of its routes to the ASes in the set 965 AS-FOO. 967 7.3 Other Routing Protocols, Multi-Protocol Routing Protocols, and Injecting 968 Routes Between Protocols 970 The syntax of the import and export attributes are indeed the following: 972 import: [protocol ] [into ] 973 from [action ] 974 . . . 975 from [action ] 976 accept 977 export: [protocol ] [into ] 978 to [action ] 979 . . . 980 to [action ] 981 announce 983 Where the optional protocol specifications can be used for specifying 984 policies for other routing protocols, or for injecting routes of one 985 protocol into another protocol, or for multi-protocol routing policies. The 986 valid protocol names are defined in the dictionary. The 987 is the name of the protocol whose routes are being exchanged. The 988 is the name of the protocol which is receiving these routes. 989 Both and default to the Internet Exterior Gateway 990 Protocol, currently BGP. 992 In the following example, all interAS routes are injected into RIP. 994 aut-num: AS1 995 import: from AS2 accept AS2 996 export: protocol BGP into RIP 997 to AS1 announce ANY 999 In the following example, AS1 accepts AS2's routes including any more 1000 specifics of AS2's routes, but does not inject these extra more specific 1001 routes into OSPF. 1003 aut-num: AS1 1004 import: from AS2 accept AS2^+ 1005 export: protocol BGP into OSPF 1006 to AS1 announce AS2 1008 In the following example, AS1 injects its static routes (routes which are 1009 members of the set AS1:RS-STATIC-ROUTES) to the interAS routing protocol and 1010 appends AS1 twice to their AS paths. 1012 aut-num: AS1 1013 import: protocol STATIC into BGP 1014 from AS1 action aspath.prepend(AS1, AS1); 1015 accept AS1:RS-STATIC-ROUTES 1017 In the following example, AS1 imports different set of unicast routes for 1018 multicast reverse path forwarding from AS2: 1020 aut-num: AS1 1021 import: from AS2 accept AS2 1022 import: protocol IDMR 1023 from AS2 accept AS2:RS-RPF-ROUTES 1025 7.4 Ambiguity Resolution 1027 It is possible that the same peering can be covered by more that one peering 1028 specification in a policy expression. For example: 1030 aut-num: AS1 1031 import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 2; 1032 from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; 1033 accept AS4 1035 This is not an error, though definitely not desirable. To break the 1036 ambiguity, the action corresponding to the first peering specification is 1037 used. That is the routes are accepted with preference 2. We call this rule 1038 as the specification-order rule. 1040 Consider the example: 1042 aut-num: AS1 1043 import: from AS2 action pref = 2; 1044 from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; dpa = 5; 1045 accept AS4 1047 where both peering specifications cover the peering 7.7.7.1-7.7.7.2, though 1048 the second one covers it more specifically. The specification order rule 1049 still applies, and only the action ``pref = 2'' is executed. In fact, the 1050 second peering-action pair has no use since the first peering-action pair 1051 always covers it. If the intended policy was to accept these routes with 1052 preference 1 on this particular peering and with preference 2 in all other 1053 peerings, the user should have specified: 1055 aut-num: AS1 1056 import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; dpa = 5; 1057 from AS2 action pref = 2; 1058 accept AS4 1060 It is also possible that more than one policy expression can cover the same 1061 set of routes for the same peering. For example: 1063 aut-num: AS1 1064 import: from AS2 action pref = 2; accept AS4 1065 import: from AS2 action pref = 1; accept AS4 1067 In this case, the specification-order rule is still used. That is, AS4's 1068 routes are accepted from AS2 with preference 2. If the filters were 1069 overlapping but not exactly the same: 1071 aut-num: AS1 1072 import: from AS2 action pref = 2; accept AS4 1073 import: from AS2 action pref = 1; accept AS4 OR AS5 1075 the AS4's routes are accepted from AS2 with preference 2 and however AS5's 1076 routes are also accepted, but with preference 1. 1078 We next give the general specification order rule for the benefit of the 1079 RPSL implementors. Consider two policy expressions: 1081 aut-num: AS1 1082 import: from peerings-1 action action-1 accept filter-1 1083 import: from peerings-2 action action-2 accept filter-2 1085 The above policy expressions are equivalent to the following three 1086 expressions where there is no overlap: 1088 aut-num: AS1 1089 import: from peerings-1 action action-1 accept filter-1 1090 import: from peerings-3 action action-2 accept filter-2 AND NOT filter-1 1091 import: from peerings-4 action action-2 accept filter-2 1093 where peerings-3 are those that are covered by both peerings-1 and 1094 peerings-2, and peerings-4 are those that are covered by peerings-2 but not 1095 by peerings-1 (``filter-2 AND NOT filter-1'' matches the routes that are 1096 matched by filter-2 but not by filter-1). 1098 Example: 1100 aut-num: AS1 1101 import: from AS2 7.7.7.2 at 7.7.7.1 1102 action pref = 2; 1103 accept {128.9.0.0/16} 1104 import: from AS2 1105 action pref = 1; 1106 accept {128.9.0.0/16, 75.0.0.0/8} 1108 Lets consider two peerings with AS2, 7.7.7.1-7.7.7.2 and 9.9.9.1-9.9.9.2. 1109 Both policy expressions cover 7.7.7.1-7.7.7.2. On this peering, the route 1110 128.9.0.0/16 is accepted with preference 2, and the route 75.0.0.0/8 is 1111 accepted with preference 1. The peering 9.9.9.1-9.9.9.2 is only covered by 1112 the second policy expressions. Hence, both the route 128.9.0.0/16 and the 1113 route 75.0.0.0/8 are accepted with preference 1 on peering 9.9.9.1-9.9.9.2. 1115 7.5 default Attribute: Default Policy Specification 1117 Default routing policies are specified using the default attribute. The 1118 default attribute has the following syntax: 1120 default: to [action ] [networks ] 1122 The and specifications are optional. The semantics 1123 are as follows: The specification indicates the AS (and the 1124 router if present) is being defaulted to; the specification, 1125 if present, indicates various attributes of defaulting, for example a 1126 relative preference if multiple defaults are specified; and the 1127 specifications, if present, is a policy filter. A router chooses a default 1128 router from the routes in its routing table that matches this . 1130 In the following example, AS1 defaults to AS2 for routing. 1132 aut-num: AS1 1133 default: to AS2 1135 In the following example, router 7.7.7.1 in AS1 defaults to router 7.7.7.2 1136 in AS2. 1138 aut-num: AS1 1139 default: to AS2 7.7.7.2 at 7.7.7.1 1141 In the following example, AS1 defaults to AS2 and AS3, but prefers AS2 over 1142 AS3. 1144 aut-num: AS1 1145 default: to AS2 action pref = 1; 1146 default: to AS3 action pref = 2; 1148 In the following example, AS1 defaults to AS2 and uses 128.9.0.0/16 as the 1149 default network. 1151 aut-num: AS1 1152 default: to AS2 networks { 128.9.0.0/16 } 1154 7.6 Structured Policy Specification 1156 The import and export policies can be structured. We only reccomend 1157 structured policies to advanced RPSL users. Please feel free to skip this 1158 section. 1160 The BNF for a structured policy specification is the following: 1162 ::= | 1163 from [action ] 1164 . . . 1165 from [action ] 1166 accept ; 1168 ::= | 1169 LEFT-BRACE 1170 1171 . . . 1172 1173 RIGHT-BRACE 1175 ::= | 1176 EXCEPT | 1177 REFINE 1179 Please note the semicolon at the end of an . The syntax and 1180 semantics for an is already defined in Section 7.1. 1182 An is either a sequence of 's enclosed within 1183 matching braces (i.e. `{' and `}') or just a single . The 1184 semantics of an is the union of 's using the 1185 specification order rule. Here is an example of an : 1187 { 1188 from AS1 accept AS1; 1189 from AS2 accept AS2; 1190 } 1192 where AS1's routes are imported from AS1 and AS2's routes are imported from 1193 AS2. A nice way to view an is as a set of import policies. 1195 An is either an or two 's 1196 separated by keywords "except" or "refine". Without going into semantics, 1197 for example: 1199 { 1200 from AS1 accept AS1; 1201 from AS2 accept AS2; 1202 } except { 1203 from AS3 accept {128.9.0.0/16}; 1204 } 1206 is an . A nice way to view except and refine keywords 1207 is as policy-set operators. To provide nesting, an 1208 is also an . Hence there can be exceptions to exceptions, 1209 refinements to refinements, or even refinements to exceptions, and so on. 1211 The semantics for the except policy-set operator is as follows: The result 1212 of an except operation is another . The resulting policy set 1213 contains the policies of the right hand set unmodified. The policies of the 1214 left hand set are also contained but their filters are modified to exclude 1215 the filters of the right hand set. That is, the policies in the right hand 1216 set are exceptions to the policies in the left hand set. When there are 1217 multiple levels of nesting, the operations (both except and refine) are 1218 performed right to left. 1220 We next modify the syntax of the import attribute to: 1222 import: [protocol ] [into ] 1223 1225 If the in an import attribute is not structured, i.e. 1226 contains a single , the semicolon after it can be omitted. 1228 Consider the following example: 1230 import: from AS1 accept as-foo; 1231 except { 1232 from AS2 accept AS226; 1233 except { 1234 from AS3 accept {128.9.0.0/16}; 1235 } 1236 } 1238 where the route 128.9.0.0/16 is originated by AS226, and AS226 is a member 1239 of the as set as-foo. In this example, the route 128.9.0.0/16 is accepted 1240 from AS3, any other route (not 128.9.0.0/16) originated by AS226 is accepted 1241 from AS2, and any other ASes' routes in as-foo is accepted from AS1. 1243 We can come to the same conclusion using the algebra defined above. 1244 Consider the inner exception specification: 1246 from AS2 accept AS226; 1247 except { 1248 from AS3 accept {128.9.0.0/16}; 1249 } 1251 is equivalent to 1253 { 1254 from AS3 accept {128.9.0.0/16}; 1255 from AS2 accept AS226 AND NOT {128.9.0.0/16}; 1256 } 1258 Hence, the original expression is equivalent to: 1260 import: from AS1 accept as-foo; 1261 except { 1262 from AS3 accept {128.9.0.0/16}; 1263 from AS2 accept AS226 AND NOT {128.9.0.0/16}; 1264 } 1266 which is equivalent to 1268 import: { 1269 from AS3 accept {128.9.0.0/16}; 1270 from AS2 accept AS226 AND NOT {128.9.0.0/16}; 1271 from AS1 accept as-foo AND NOT 1272 (AS226 AND NOT {128.9.0.0/16} OR {128.9.0.0/16}); 1273 } 1275 In the case of the refine policy-set operator, the resulting set is 1276 constructed by taking the cartasian product of the two sets as follows: for 1277 each policy l in the left hand set and for each policy r in the right hand 1278 set, the peerings of the resulting policy are the peerings common to both r 1279 and l; the filter of the resulting policy is the intersection of l's filter 1280 and r's filter; and action of the resulting policy is l's action followed 1281 by r's action. If there are no common peerings, or if the intersection of 1282 filters is empty, a resulting policy is not generated. 1284 Consider the following example: 1286 import: { from AS-ANY action pref = 1; accept community.contains({3560,10}); 1287 from AS-ANY action pref = 2; accept community.contains({3560,20}); 1288 } refine { 1289 from AS1 accept AS1; 1290 from AS2 accept AS2; 1291 from AS3 accept AS3; 1292 } 1294 Here, any route with community {3560,10} is assigned a preference of 1 and 1295 any route with community {3560,20} is assigned a preference of 2 regardless 1296 of whom they are imported from. However, only AS1's routes are imported 1297 from AS1, and only AS2's routes are imported from AS2, and only AS3's routes 1298 are imported form AS3, and no routes are imported from any other AS. We can 1299 reach the same conclusion using the above algebra. That is, our example is 1300 equivalent to: 1302 import: { 1303 from AS1 action pref = 1; accept community.contains({3560,10}) AND AS1; 1304 from AS1 action pref = 2; accept community.contains({3560,20}) AND AS1; 1305 from AS2 action pref = 1; accept community.contains({3560,10}) AND AS2; 1306 from AS2 action pref = 2; accept community.contains({3560,20}) AND AS2; 1307 from AS3 action pref = 1; accept community.contains({3560,10}) AND AS3; 1308 from AS3 action pref = 2; accept community.contains({3560,20}) AND AS3; 1309 } 1311 Note that the common peerings between ``from AS1'' and ``from AS-ANY'' are 1312 those peerings in ``from AS1''. Even though we do not formally define 1313 ``common peerings'', it is straight forward to deduce the definition from 1314 the definitions of peerings (please see Section 7.1.1). 1316 Consider the following example: 1318 import: { 1319 from AS-ANY action med = 0; accept {0.0.0.0/0^0-16}; 1320 } refine { 1321 from AS1 at 7.7.7.1 action pref = 1; accept AS1; 1322 from AS1 action pref = 2; accept AS1; 1323 } 1325 where only routes of length 0 to 16 are accepted and med's value is set to 0 1326 to disable med's effect for all peerings; In addition, from AS1 only AS1's 1327 routes are imported, and AS1's routes imported at 7.7.7.1 are preferred over 1328 other peerings. This is equivalent to: 1330 import: { 1331 from AS1 at 7.7.7.1 action med=0; pref=1; accept {0.0.0.0/0^0-16} AND AS1; 1332 from AS1 action med=0; pref=2; accept {0.0.0.0/0^0-16} AND AS1; 1333 } 1335 The above syntax and semantics also apply equally to structured export 1336 policies with ``from'' replaced with ``to'' and ``accept'' is replaced with 1337 ``announce''. 1339 8 dictionary Class 1341 The dictionary class provides extensibility to RPSL. Dictionary objects 1342 define routing policy attributes, types, and routing protocols. Routing 1343 policy attributes, henceforth called rp-attributes, may correspond to actual 1344 protocol attributes, such as the BGP path attributes (e.g. community, dpa, 1345 and AS-path), or they may correspond to router features (e.g. BGP route flap 1346 damping). As new protocols, new protocol attributes, or new router features 1347 are introduced, the dictionary object is updated to include appropriate 1348 rp-attribute and protocol definitions. 1350 An rp-attribute is an abstract class; that is their data representation is 1351 not available. Instead, they are accessed through access methods. For 1352 example, the rp-attribute for the BGP AS-path attribute is called aspath; 1353 and it has an access method called prepend which stuffs extra AS numbers to 1354 the AS-path attributes. Access methods can take arguments. Arguments are 1355 strongly typed. For example, the method prepend above takes AS numbers as 1356 argument. 1358 Once an rp-attribute is defined in the dictionary, it can be used to 1359 describe policy filters and actions. Policy analysis tools are required 1360 to fetch the dictionary object and recognize newly defined rp-attributes, 1361 types, and protocols. The analysis tools may approximate policy analyses 1362 on rp-attributes that they do not understand: a filter method may always 1363 match, and an action method may always perform no-operation. Analysis tools 1364 may even download code to perform appropriate operations using mechanisms 1365 outside the scope of RPSL. 1367 We next describe the syntax and semantics of the dictionary class. This 1368 description is not essential for understanding dictionary objects (but it is 1369 essential for creating one). Please feel free to skip to the RPSL Initial 1370 Dictionary subsection (Section 8.1). 1372 The attributes of the dictionary class are shown in Figure 14. The 1373 dictionary attribute is the name of the dictionary object, obeying the RPSL 1374 naming rules. There can be many dictionary objects, however there is always 1375 one well-known dictionary object ``RPSL''. All tools use this dictionary by 1376 default. 1378 Attribute Value Type 1379 dictionary mandatory, single-valued, class key 1380 rp-attribute see description in text optional, multi valued 1381 typedef see description in text optional, multi valued 1382 protocol see description in text optional, multi valued 1383 encapsulation see Section 11 optional, multi valued 1385 Figure 14: dictionary Class Attributes 1387 The rp-attribute attribute has the following syntax: 1389 rp-attribute: 1390 (, ..., [, "..."]) 1391 ... 1392 (, ..., [, "..."]) 1394 where is the name of the rp-attribute; and is the name of 1395 an access method for the rp-attribute, taking Ni arguments where the j-th 1396 argument is of type . A method name is either an RPSL name or one 1397 of the operators defined in Figure 15. The operator methods can take only 1398 one argument. 1400 operator= operator== 1401 operator<<= operator< 1402 operator>>= operator> 1403 operator+= operator>= 1404 operator-= operator<= 1405 operator*= 1406 operator/= 1407 operator.= 1409 Figure 15: Operators 1411 An rp-attribute can have many methods defined for it. Some of the methods 1412 may even have the same name, in which case their arguments are of different 1413 types. If the argument list is followed by ``...'', the method takes a 1414 variable number of arguments. In this case, the actual arguments after the 1415 Nth argument are of type . 1417 Arguments are strongly typed. A type of an argument can be one of the 1418 predefined types or one of the dictionary defined types. The predefined 1419 type names are listed in Figure 16. The integer and the real types can be 1420 followed by a lower and an upper bound to specify the set of valid values 1421 of the argument. The range specification is optional. We use the ANSI C 1422 language conventions for representing integer, real and string values. The 1423 enum type is followed by a list of RPSL names which are the valid values of 1424 the type. The boolean type can take the values true or false. as_number, 1425 ip_address, address_prefix and dns_name types are as in Section 2. filter 1426 type is a policy filter as in Section 7. 1428 integer[lower, upper] as_number 1429 real[lower, upper] ipv4_address 1430 enum[name, name, ...] address_prefix 1431 string dns_name 1432 boolean filter 1434 Figure 16: Predefined Types 1436 The typedef attribute specifies a dictionary defined type. Its syntax is as 1437 follows: 1439 typedef: ... 1441 where is the name of the type being defined and is another 1442 type name, either predefined or dictionary defined. The type defined by a 1443 typedef is either of the types 1 through N (analogous to unions in C[19]). 1445 A dictionary defined type can also be a list type, specified as: 1447 list [:] of 1449 where the list elements are of and the list contains at least 1450 and at most elements. The size specification is 1451 optional. In this case, there is no restriction in the number of list 1452 elements. A value of a list type is represented as a sequence of elements 1453 separated by the character ``,'' and enclosed by the characters ``{'' and 1454 ``}''. 1456 A protocol attribute of the dictionary class defines a protocol and a set 1457 of peering options for that protocol (which are used in inet-rtr class in 1458 Section 10). Its syntax is as follows: 1460 protocol: 1461 MANDATORY | OPTIONAL (, ..., [, "..."]) 1462 ... 1463 MANDATORY | OPTIONAL (, ..., [, "..."]) 1465 where is the name of the protocol; MANDATORY and OPTIONAL are 1466 keywords; and is a peering option for this protocol, taking Ni 1467 many arguments. The syntax and semantics of the arguments are as in the 1468 rp-attribute. If the keyword MANDATORY is used the option is mandatory and 1469 needs to be specified for each peering of this protocol. If the keyword 1470 OPTIONAL is used the option can be skipped. 1472 The encapsulation attribute defines a valid encapsulation name for 1473 inet-tunnel objects. Please refer to Section 11 for details. 1475 8.1 Initial RPSL Dictionary and Example Policy Actions and Filters 1476 dictionary: RPSL 1477 rp-attribute: pref # preference, smaller values represent higher preferences 1478 operator=(integer[0, 65535]) # assign an integer 1479 rp-attribute: med # BGP multi_exit_discriminator attribute 1480 operator=(integer[0, 65535]) # assign an integer 1481 operator=(enum[igp_cost]) # assign the IGP metric 1482 rp-attribute: dpa # BGP destination preference attribute (dpa) 1483 operator=(integer[0, 65535]) # assign an integer 1484 rp-attribute: aspath # BGP aspath attribute 1485 prepend(as_number, ...) # prepend the AS numbers 1486 # from last to first order 1487 typedef: community_elm # needed for the community attribute 1488 integer[1, 4294967200], # 4 byte community value 1489 enum[internet, no_export, no_advertise] # defined in RFC 1997 1490 list[2:2] of integer[0, 65535] # construct a 4 byte integer 1491 # by concating two 2-byte integers 1492 typedef: community_list # needed for the community attribute 1493 list of community_elm 1494 rp-attribute: community # BGP community attribute 1495 operator=(community_list) # assign a list of communities 1496 operator==(community_list) # true if equals the argument 1497 # order independent comparison 1498 operator.=(community_elm) # append just one community 1499 append(community_elm, ...) # append the listed communities 1500 delete(community_elm, ...) # delete the listed communities 1501 contains(community_elm, ...) # true if one of comms is contained 1502 rp-attribute: flap_damp # flap_damping router feature 1503 enable() # enable flap_damping 1504 disable() # disable flap_damping 1505 rp-attribute: next-hop # next hop router in a static route 1506 operator=(ipv4_address) # assign a router address 1507 operator=(enum[self]) # assign router's own address 1508 rp-attribute: cost # cost of a static route 1509 operator=(integer[0, 65535]) # assign an integer 1510 rp-attribute: ttlscope # IP time-to-live, useful for tunnels 1511 operator=(integer[0, 65535]) # assign an integer 1512 rp-attribute: dvmrp-metric # A DVMRP metric, useful for tunnels 1513 operator=(integer[0, 65535]) # assign an integer 1514 rp-attribute: boundary # for admin scoped multicast 1515 operator=(list of address_prefix) # assign address regions 1517 Figure 17: RPSL Dictionary (cont.) 1519 The Figure 18 shows the initial RPSL dictionary. It has eight 1520 rp-attributes: pref to assign local preference to the routes accepted; 1521 med to assign a value to the MULTI_EXIT_DISCRIMINATOR BGP attribute; dpa to 1522 encapsulation: IPinIP 1523 encapsulation: IPMOBILITY 1524 encapsulation: DVMRP 1525 encapsulation: GRE 1526 encapsulation: IPv6 1527 protocol: BGP # Border Gateway Protocol 1528 MANDATORY asno(as_number) # as number of the peer router 1529 OPTIONAL flap_damp() # enable flap damping 1530 protocol: OSPF 1531 protocol: RIP 1532 protocol: IGRP 1533 protocol: IS-IS 1534 protocol: STATIC 1535 protocol: RIPv6 1536 protocol: DVMRP 1537 protocol: PIM-DM 1538 protocol: PIM-SM 1539 protocol: CBT 1540 protocol: MOSPF 1542 Figure 18: RPSL Dictionary 1544 assign a value to the DPA BGP attribute; aspath to prepend a value to the 1545 AS_PATH BGP attribute; community to assign a value to or to check the value 1546 of the community BGP attribute; flap_damp to enable or disable routing flap 1547 damping feature of the routers; next-hop to assign next hop routers to 1548 static routes; and cost to assign a cost to static routes. The dictionary 1549 defines two types: community_elm and community_list. community_elm type 1550 is either a 4-byte unsigned integer, or one of the keywords no_export or 1551 no_advertise (defined in [9]), or a list of two 2-byte unsigned integers 1552 in which case the two integers are concatenated to form a 4-byte integer. 1553 (The last form is often used in the Internet to partition the community 1554 space. A provider uses its AS number as the first two bytes, and assigns a 1555 semantics of its choice to the last two bytes.) The rp-attributes ttlscope, 1556 dvmrp-metric, boundary are for specifying tunnel characteristics and are 1557 described in Section 11. 1559 The initial dictionary (Figure 18) defines only options for the Border 1560 Gateway Protocol: asno and flap_damp. The mandatory asno option is the AS 1561 number of the peer router. The optional flap_damp option instructs the 1562 router to damp route flaps when importing routes from the peer router. 1564 The initial dictionary (Figure 18) defines the following encapsulation 1565 types: IPinIP [28], IPMOBILITY [23], DVMRP [24], GRE [15], and IPv6 1566 [10]. 1568 Policy Actions and Filters Using RP-Attributes 1570 The syntax of a policy action or a filter using an rp-attribute x is as 1571 follows: 1573 x.method(arguments) 1574 x ``op'' argument 1576 where method is a method and ``op'' is an operator method of the 1577 rp-attribute x. If an operator method is used in specifying a composite 1578 policy filter, it evaluates earlier than the composite policy filter 1579 operators (i.e. AND, OR, NOT, and implicit or operator). 1581 The pref rp-attribute can be assigned a positive integer as follows: 1583 pref = 10; 1585 The med rp-attribute can be assigned either a positive integer or the word 1586 ``igp_cost'' as follows: 1588 med = 0; 1589 med = igp_cost; 1591 The dpa rp-attribute can be assigned a positive integer as follows: 1593 dpa = 100; 1595 The BGP community attribute is list-valued, that is it is a list of 1596 4-byte integers each representing a ``community''. The following examples 1597 demonstrate how to add communities to this rp-attribute: 1599 community .= 100; 1600 community .= NO_EXPORT; 1601 community .= {3561,10}; 1603 In the last case, a 4-byte integer is constructed where the more significant 1604 two bytes equal 3561 and the less significant two bytes equal 10. The 1605 following examples demonstrate how to delete communities from the community 1606 rp-attribute: 1608 community.delete(100, NO_EXPORT, {3561,10}); 1610 Filters that use the community rp-attribute can be defined as demonstrated 1611 by the following examples: 1613 community.contains(100, NO_EXPORT, {3561,10}); 1615 The community rp-attribute can be set to a list of communities as follows: 1617 community = {100, NO_EXPORT, {3561,10}, 200}; 1618 community = {}; 1620 In this first case, the community rp-attribute contains the communities 1621 100, NO_EXPORT, {3561,10}, and 200. In the latter case, the community 1622 rp-attribute is cleared. The community rp-attribute can be compared against 1623 a list of communities as follows: 1625 community == {100, NO_EXPORT, {3561,10}, 200}; 1627 To influence the route selection, the BGP as_path rp-attribute can be made 1628 longer by prepending AS numbers to it as follows: 1630 aspath.prepend(AS1); 1631 aspath.prepend(AS1, AS1, AS1); 1633 Flap damping can be turned on or off as follows: 1635 flap_damp.enable(); 1636 flap_damp.disable(); 1638 The following examples are invalid: 1640 med = -50; # -50 is not in the range 1641 med = igp; # igp is not one of the enum values 1642 med.assign(10); # method assign is not defined 1643 community.append({AS3561,20}); # the first argument should be 3561 1645 Figure 19 shows a more advanced example using the rp-attribute community. 1646 In this example, AS3561 bases its route selection preference on the 1647 community attribute. Other ASes may indirectly affect AS3561's route 1648 selection by including the appropriate communities in their route 1649 announcements. 1651 aut-num: AS1 1652 export: to AS2 action community.={3561,10}; 1653 to AS3 action community.={3561,20}; 1654 announce AS1 1656 as-set: AS3561:AS-PEERS 1657 members: AS2, AS3 1659 aut-num: AS3561 1660 import: from AS3561:AS-PEERS 1661 action pref = 10; 1662 accept community.contains({3561,10}) 1663 import: from AS3561:AS-PEERS 1664 action pref = 20; 1665 accept community.contains({3561,20}) 1666 import: from AS3561:AS-PEERS 1667 action pref = 30; 1668 accept ANY 1670 Figure 19: Policy example using the community rp-attribute. 1672 9 Advanced route Class 1674 9.1 Specifying Static Routes 1676 The attribute inject-at can be used to specify static routes. Its syntax is 1677 as follows: 1679 inject-at: [action ] 1681 where is an IP address of a router and is as in the 1682 aut-num class. executes the and injects the route to the 1683 interAS routing system. may set certain route attributes such as a 1684 next-hop router or a cost. 1686 In the following example, the router 7.7.7.1 injects the route 128.7.0.0/16. 1687 The next-hop routers (in this example, there are two next-hop routers) for 1688 this route are 7.7.7.2 and 7.7.7.3 and the route has a cost of 10 over 1689 7.7.7.2 and 20 over 7.7.7.3. 1691 route: 128.7.0.0/16 1692 origin: AS1 1693 inject-at: 7.7.7.1 action next-hop = 7.7.7.2; cost = 10; 1694 inject-at: 7.7.7.1 action next-hop = 7.7.7.3; cost = 20; 1696 9.2 Specifying Aggregate Routes 1698 The attributes aggr-by, inject-at, export-comps, and holes are used for 1699 specifying aggregate routes [13]. 1701 The aggr-by attribute defines what component routes are used to form the 1702 aggregate. Its syntax is as follows: 1704 aggr-by: [atomic] 1706 A router in the origin AS forms the aggregate route if there is at least one 1707 route in its routing table that matches . If the keyword ATOMIC 1708 is specified, the aggregation is done atomically, otherwise the BGP path 1709 attributes of the matching routes are used to form the BGP path attributes 1710 of the aggregate route. For example, if atomic aggregation is done, the 1711 aggregate route would have an AS-path that starts from the aggregating 1712 AS [13]. Otherwise, the aggregate route would have an AS-path containing 1713 AS-sets formed from the AS-paths of the matching routes. 1715 Figure 20 shows some example aggregate route objects. The aggregate 1716 128.9.0.0/16 is generated if there is a route that matches the filter 1717 ``128.9.0.0/16^- AND <^AS226>'' (this filter matches more specifics of 1718 128.9.0.0/16 that are received form AS226). The BGP path attributes of 1719 the matching routes are used to form the BGP path attributes of the 1720 route 128.9.0.0/16. Similarly, the aggregate 128.8.0.0/16 is generated if 1721 there is a route that matches the filter ``128.8.0.0/16^- AND <^AS226>''. 1722 However, its path attributes are generated using the atomic aggregation 1723 rules [13]. The aggregate 128.7.0.0/16 is always and atomically generated 1724 since the policy filter ``ANY'' matches any route in the routing table. 1726 The inject-at attribute lists the routers in the originating AS that inject 1727 this route to the interAS routing system. That is, these routers are 1728 configured to perform the aggregation. If the inject-at attribute is 1729 missing, all routers in the originating AS perform the aggregation. The 1730 route 128.7.0.0/16 in Figure 20 is injected by routers 7.7.7.1 and 9.9.9.1 1731 in AS1. 1733 When a set of routes are aggregated, the intent is to export only the 1734 aggregate route and suppress the exporting of the component routes to the 1735 route: 128.9.0.0/16 1736 origin: AS1 1737 aggr-by: {128.9.0.0/16^-} AND <^AS226> 1739 route: 128.8.0.0/16 1740 origin: AS1 1741 aggr-by: ATOMIC {128.8.0.0/16^-} AND <^AS226> 1743 route: 128.7.0.0/16 1744 origin: AS1 1745 aggr-by: ATOMIC ANY 1746 inject-at: 7.7.7.1 1747 inject-at: 9.9.9.1 1748 export-comps: {128.7.9.0/24} 1750 Figure 20: Aggregate route objects. 1752 outside world. However, to satisfy certain policy and topology constraints 1753 (e.g. a multi-homed component), it is often required to export some of 1754 the components. The export-comps attribute equals an RPSL filter that 1755 matches the routes that need to be exported to the neighboring ASes. If 1756 this attribute is missing, no component route needs to be exported to the 1757 neighboring ASes. The export-comps attribute can only be specified if 1758 an aggr-by attribute is specified for the route object. The component 1759 128.7.9.0/24 of route 128.7.0.0/16 in Figure 20 needs to be exported to 1760 other ASes. 1762 The holes attribute lists the component address prefixes which are not 1763 reachable through the aggregate route (perhaps that part of the address 1764 space is unallocated). Figure 21 shows a route object whose two components, 1765 namely 128.9.0.0/16 and 128.7.0.0/16, are not reachable via the aggregate. 1766 That is, if a data packet destined to a host in 128.9.0.0/16 is sent to AS1, 1767 AS1 can not deliver it to its final destination (i.e. it is black-holed). 1769 route: 128.0.0.0/12 1770 origin: AS1 1771 aggr-by: {128.0.0.0/12^-} 1772 holes: 128.7.0.0/16, 128.9.0.0/16 1774 Figure 21: The route 128.0.0.0/12 does not lead to destinations in 1775 128.9.0.0/16. 1777 10 inet-rtr Class 1779 Routers are specified using the inet-rtr class. The attributes of the 1780 inet-rtr class are shown in Figure 22. The inet-rtr attribute is a valid 1781 DNS name of the router described. Each alias attribute, if present, is a 1782 canonical DNS name for the router. The local-as attribute specifies the AS 1783 number of the AS which owns/operates this router. 1785 Attribute Value Type 1786 inet-rtr mandatory, single-valued, class key 1787 alias optional, multi-valued 1788 local-as mandatory, single-valued 1789 ifaddr see description in text mandatory, multi-valued 1790 peer see description in text optional, multi-valued 1792 Figure 22: inet-rtr Class Attributes 1794 The value of an ifaddr attribute has the following syntax: 1796 masklen 1797 [tunnel ] 1798 [action ] 1800 The IP address and the mask length are mandatory for each interface. If 1801 the interface is a tunnel, and if there is an inet-tunnel object describing 1802 the tunnel, the tunnel's name can also be specified. (An example inet-rtr 1803 object with tunnels is presented in Section 11.) Optionally an action can 1804 be specified to set other parameters of this interface. 1806 Figure 23 presents an example inet-rtr object. The name of the router is 1807 ``amsterdam.ripe.net''. ``amsterdam1.ripe.net'' is a canonical name for the 1808 router. The router is connected to 4 networks. Its IP addresses and mask 1809 lengths in those networks are specified in the ifaddr attributes. 1811 Each peer attribute, if present, specifies a protocol peering with another 1812 router. The value of a peer attribute has the following syntax: 1814 1816 where is a protocol name, is the IP address of the 1817 peer router, and is a comma separated list of peering options 1818 for . Possible protocol names and attributes are defined in the 1819 dictionary (please see Section 8). In the above example, the router has 1820 inet-rtr: Amsterdam.ripe.net 1821 alias: amsterdam1.ripe.net 1822 localas: AS3333 1823 ifaddr: 192.87.45.190 masklen 24 1824 ifaddr: 192.87.4.28 masklen 24 1825 ifaddr: 193.0.0.222 masklen 27 1826 ifaddr: 193.0.0.158 masklen 27 1827 peer: BGP 192.87.45.195 asno(AS3334), flap_damp() 1829 Figure 23: inet-rtr Objects 1831 a BGP peering with the router 192.87.45.195 in AS3334 and turns the flap 1832 damping on when importing routes from this router. 1834 11 inet-tunnel Class and Specifying Tunnels 1836 Tunneling is a fundamental networking technology that is used in a variety 1837 circumstances. A common use of tunneling is to incrementally deploy a new 1838 network layer protocol. The approach is to encapsulate ("tunnel") the new 1839 protocol through the existing network layer protocol, usually IP. Examples 1840 of this approach include include the multicast backbone [3], where multicast 1841 packets are encapsulated in IP packets using protocol 4 (IP in IP), and IPv6 1842 backbone [1], where IPv6 packets are encapsulated in IP packets using IP 1843 protocol 41 [14]. 1845 Another use of tunneling is to force congruence between the existing (IP 1846 unicast) topology and some new topology. Due the special requirements of IP 1847 multicast routing, the MBONE is also an example of this use of tunneling. 1849 This section describes general tunneling specification in RPSL. Both 1850 point-to-point and point-to-multipoint tunnels of encapsulation types, 1851 including DVMRP, GRE, and IPv6, are supported. In addition to the 1852 encapsulation, a protocol to run inside the tunnel can also be specified. 1854 Tunnels are specified using the inet-tunnel class. The attributes of the 1855 inet-tunnel class are shown in Figure 24. The inet-tunnel attribute is a 1856 valid RPSL name for the tunnel described. The tunnel-source attribute is 1857 the IP address of the source end point of the tunnel. The inet-tunnel and 1858 the tunnel-source attributes form the class key. That is, a point-to-point 1859 tunnel is specified using two tunnel object, one for each end point of the 1860 tunnel. The tunnel-sink attribute is the IP address of other end points of 1861 the tunnel. If the tunnel is a multi-point tunnel, multiple tunnel-sink 1862 attributes can be used to list each end point. The tunnel-encap attribute 1863 is an encapsulation name. Valid encapsulation names are defined in the 1864 dictionary and include IPinIP [28], IPMOBILITY [23], DVMRP [24], GRE [15], 1865 and IPv6 [10]. The tunnel-protocol attribute is a protocol name to run 1866 "inside" the tunnel. Valid protocol names are defined in the dictionary 1867 and include BGP, RIPv6, DVMRP. See [26] for an application that uses BGP 1868 tunneled in GRE. The tunnel-mcast-tree attribute is used to describe the 1869 multicast tree construction mechanism used on the tunnel. Examples include 1870 PIM-DM and PIM-SM. 1872 Attribute Value Type 1873 inet-tunnel mandatory, single-valued, class key 1874 tunnel-source mandatory, single valued, class key 1875 tunnel-sink mandatory, multi-valued, class key 1876 tunnel-encap mandatory, single-valued 1877 tunnel-protocol mandatory, single valued 1878 tunnel-mcast-tree optional, single valued 1879 tunnel-in see description in text mandatory, multi-valued 1880 tunnel-out see description in text mandatory, multi-valued 1881 Figure 24: inet-tunnel Class Attributes 1883 The tunnel-in and tunnel-out attributes have the following format: 1885 tunnel-in: from [action ] accept 1886 tunnel-out: to [action ] announce 1888 where and are as in the aut-num class. The possible 1889 actions are defined in the dictionary and include 1891 ttlscope The minimum IP time-to-live required for a packet to be forwarded 1892 to the specified endpoint (in the case of multipoint tunnels, there may 1893 be per endpoint scopes). 1895 boundary A boundary attribute describes an administratively defined class 1896 of packets that will not be forwarded through the tunnel [21]. 1898 dvmrp-metric A DVMRP metric. 1900 These attributes are particularly relevant to multicast routing. Attributes 1901 for other tunnels can later be defined in the dictionary. The 1902 specifications describe filters that are appropriate for the tunnel's 1903 routing protocol. In the case of DVMRP, the filter specification can be the 1904 list of network prefixes accepted or advertised. 1906 Figure 25 has two examples of tunnel objects. In the first example, the 1907 router eugene-isp.nero.net has two tunnels: a DVMRP tunnel to dec3800- 1908 2-fddi-0.SanFrancisco.mci.net and a GRE tunnel to eugene-isp.nero.net. 1909 The DVMRP tunnel object is called MBONE-TUNNEL-EUG. eugene-isp.nero.net 1910 will accept any routes and forward packets to the DVMRP tunnel if the 1911 packet's time-to-live is greater than or equal to 64. In addition, 1912 eugene-isp.nero.net will not pass any packets that match the administrative 1913 scope boundary filter (in this case, 239.254.0.0/16). The GRE tunnel is 1914 named GRE-TUNNEL-EUG. 1916 inet-rtr: eugene-isp.nero.net 1917 loacalas: AS4600 1918 ifaddr: 166.48.14.6 masklen 30 tunnel MBONE-TUNNEL-EUG 1919 ifaddr: 166.48.14.6 masklen 30 tunnel GRE-TUNNEL-EUG 1920 admin-c: DMM65 1921 tech-c: DMM65 1922 notify: nethelp@ns.uoregon.edu 1923 mnt-by: MAINT-AS3582 1924 changed: meyer@ns.uoregon.edu 961122 1925 source: RADB 1927 inet-tunnel: MBONE-TUNNEL-EUG 1928 tunnel-source: 166.48.14.6 # eugene-isp.nero.net 1929 tunnel-sink: 204.70.158.61 # dec3800-2-fddi-0.SanFrancisco.mci.net 1930 tunnel-encap: DVMRP 1931 tunnel-protocol: DVMRP 1932 tunnel-in: from 204.70.158.61 accept ANY 1933 tunnel-out: to 204.70.158.61 1934 action 1935 ttlscope=64; 1936 boundary={239.254.0.0/16}; 1937 dvmrp-metric=1; 1938 announce AS-NERO-TRANSIT 1939 ... 1941 inet-tunnel: GRE-TUNNEL-EUG 1942 tunnel-source: 166.48.14.6 1943 tunnel-sink: 206.42.19.240 1944 tunnel-protocol: DVMRP 1945 tunnel-mcast-tree: PIM-DM 1946 tunnel-encap: GRE 1947 tunnel-in: from 206.42.19.240 accept ANY 1948 tunnel-out: to 206.42.19.240 1949 action 1950 ttlscope=64; 1951 announce ANY 1952 ... 1954 Figure 25: inet-tunnel Objects 1956 12 Security Consideration 1958 This document describes RPSL, a language for expressing routing policies. 1959 As such, it does not itself have (or need) a security architecture. 1960 However, any registry that implements this language should provide a 1961 mechanism for: 1963 1. Data Integrity and Origin Authentication. Both data origin and 1964 integrity can be provided by associating cryptographically generated 1965 digital signatures with each object in a IRR. There may be a single 1966 private key that signs for all objects associated with a given 1967 MAINTAINER object, or there may be finer grained control. As is common, 1968 it is expected that an implementation will keep the MAINTAINER private 1969 key off-line and it will be used to re-sign all objects for a given 1970 MAINTAINER. 1972 2. Public Key Distribution. It is expected that any IRR implemeting RPSL 1973 will use the Group Key Management Protocol (GKMP) [16]. The IETF IP 1974 Security Working Group is actively working on GKMP extensions to the 1975 standards-track ISAKMP key management protocol being developed in the 1976 same working group. 1978 3. Transaction Security. When a user is querying a registry for policy 1979 objects, to eliminate snooping and to eliminate third parties injecting 1980 objects, the server and the client may optionally use authentication and 1981 encryption techniques [12]. 1983 13 Acknowledgements 1985 We would like to thank Jessica Yu, Randy Bush, Alan Barrett, David Kessens, 1986 Bill Manning, Sue Hares, Ramesh Govindan, Kannan Varadhan, Satish Kumar, 1987 Craig Labovitz, Rusty Eddy, David J. LeRoy, David Whipple, Jon Postel, 1988 Deborah Estrin, Elliot Schwartz, Joachim Schmitz, and the participants of 1989 the IETF RPS Working Group for various comments and suggestions. 1991 References 1993 [1] 6BONE. See http://www-6bone.lbl.gov/6bone/. 1995 [2] Internet 1996 Routing Registry. Procedures. http://www.ra.net/RADB.tools.docs/, 1997 http://www.ripe.net/db/doc.html. 1999 [3] MBONE. See http://www.best.com/ prince/techinfo/misc.html. 2001 [4] C. Alaettinouglu, D. Meyer, and J. Schmitz. Application of Routing 2002 Policy Specification Language (RPSL) on the Internet. Internet Draft 2003 draft-ietf-rps-appl-rpsl-00.ps, March 1997. Work in progress. 2005 [5] T. Bates. Specifying an `Internet Router' in the Routing Registry. 2006 Technical Report RIPE-122, RIPE, RIPE NCC, Amsterdam, Netherlands, 2007 October 1994. 2009 [6] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, 2010 M. Terpstra, and J. Yu. Representation of IP Routing Policies 2011 in a Routing Registry. Technical Report ripe-181, RIPE, RIPE NCC, 2012 Amsterdam, Netherlands, October 1994. 2014 [7] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, 2015 M. Terpstra, and J. Yu. Representation of IP Routing Policies in a 2016 Routing Registry. Technical Report RFC-1786, March 1995. 2018 [8] T. Bates, J-M. Jouanigot, D. Karrenberg, P. Lothberg, and M. Terpstra. 2019 Representation of IP Routing Policies in the RIPE Database. Technical 2020 Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993. 2022 [9] R. Chandra, P. Traina, and T. Li. BGP Communities Attribute. Request 2023 for Comment RFC-1997, Network Information Center, August 1996. 2025 [10] A. Conta and S. Deering. Generic Packet Tunneling in IPv6. Technical 2026 Report draft-ietf-ipngwg-ipv6-tunnel-04.txt, October 1996. 2028 [11] D. Crocker. Standard for the format of ARPA Internet text messages. 2029 Request for Comment RFC-822, Network Information Center, August 1982. 2031 [12] D. Eastlake and C. Kaufman. Domain Name System Security Extensions. 2032 Technical Report RFC2065, January 1997. 2034 [13] V. Fuller, T. Li, J. Yu, and K. Varadhan. Classless Inter-Domain 2035 Routing (CIDR): an Address Assignment and Aggregation Strategy, 1993. 2037 [14] R. Gilligan and E. Nordmark. Transition Mechanisms for IPv6 Hosts and 2038 Routers. Technical Report RFC1933, April 1996. 2040 [15] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing 2041 Encapsulation (GRE). Technical Report RFC1701, October 1994. 2043 [16] H. Harney. Group Key Management Protocol (GKMP). Technical Report 2044 draft-harney-gkmp-arch-01.txt, draft-harney-gkmp-spec-01.txt, August 2045 1996. Informational RFC publication is pending. 2047 [17] D. Karrenberg and T. Bates. Description of Inter-AS Networks in the 2048 RIPE Routing Registry. Technical Report RIPE-104, RIPE, RIPE NCC, 2049 Amsterdam, Netherlands, December 1993. 2051 [18] D. Karrenberg and M. Terpstra. Authorisation and Notification of 2052 Changes in the RIPE Database. Technical Report ripe-120, RIPE, RIPE 2053 NCC, Amsterdam, Netherlands, October 1994. 2055 [19] B. W. Kernighan and D. M. Ritchie. The C Programming Language. 2056 Prentice-Hall, 1978. 2058 [20] A. Lord and M. Terpstra. RIPE Database Template for Networks 2059 and Persons. Technical Report ripe-119, RIPE, RIPE NCC, Amsterdam, 2060 Netherlands, October 1994. 2062 [21] D. Meyer. Administratively Scoped IP Multicast. Technical Report 2063 draft-ietf-mboned-admin-ip-space-01.txt, December 1996. 2065 [22] P. V. Mockapetris. Domain names - concepts and facilities. Request for 2066 Comment RFC-1034, Network Information Center, November 1987. 2068 [23] C. Perkins. Minimal Encapsulation within IP. Technical Report RFC2004, 2069 October 1996. 2071 [24] T. Pusateri. Distance Vector Multicast Routing Protocol. Technical 2072 Report draft-ietf-idmr-dvmrp-v3-03, September 1996. 2074 [25] Y. Rekhter. Inter-Domain Routing Protocol (IDRP). Journal of 2075 Internetworking Research and Experience, 4:61--80, 1993. 2077 [26] Y. Rekhter. Auto route injection with tunnelling, October 1996. NANOG, 2078 See http://www.academ.com/nanog/oct1996/multihome.html. 2080 [27] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4). Request for 2081 Comment RFC-1654, Network Information Center, July 1994. 2083 [28] W. Simpson. IP in IP Tunneling. Technical Report RFC1853, October 2084 1995. 2086 A Routing Registry Sites 2088 The set of routing registries as of November 1996 are RIPE, RADB, CANet, MCI 2089 and ANS. You may contact one of these registries to find out the current 2090 list of registries. 2092 B Authors' Addresses 2094 Cengiz Alaettinoglu 2095 USC Information Sciences Institute 2096 4676 Admiralty Way, Suite 1001 2097 Marina del Rey, CA 90292 2098 email: cengiz@isi.edu 2100 Tony Bates 2101 Cisco Systems, Inc. 2102 170 West Tasman Drive 2103 San Jose, CA 95134 2104 email: tbates@cisco.com 2106 Elise Gerich 2107 At Home Network 2108 385 Ravendale Drive 2109 Mountain View, CA 94043 2110 email: epg@home.net 2112 Daniel Karrenberg 2113 RIPE Network Coordination Centre (NCC) 2114 Kruislaan 409 2115 NL-1098 SJ Amsterdam 2116 Netherlands 2117 email: dfk@ripe.net 2119 David Meyer 2120 University of Oregon 2121 Eugene, OR 97403 2122 email: meyer@antc.uoregon.edu 2124 Marten Terpstra 2125 c/o Bay Networks, Inc. 2126 2 Federal St 2127 Billerica MA 01821 2128 email: marten@BayNetworks.com 2130 Curtis Villamizar 2131 ANS 2132 email: curtis@ans.net