idnits 2.17.1 draft-ietf-rps-appl-rpsl-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 a Security Considerations 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 322 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 426 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 30 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 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 18 has weird spacing: '...ocument is an...' == Line 19 has weird spacing: '... except for ...' == Line 22 has weird spacing: '...ent can be fo...' == Line 23 has weird spacing: '...fts are worki...' == Line 25 has weird spacing: '...t other group...' == (317 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 1999) is 9196 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 940, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 944, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2280 (ref. '1') (Obsoleted by RFC 2622) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 1654 (ref. '7') (Obsoleted by RFC 1771) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 1998 (ref. '9') Summary: 17 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft David Meyer 3 Expires August 21, 1999 Cisco Systems 4 draft-ietf-rps-appl-rpsl-04 Joachim Schmitz 5 DFN-NOC 6 Carol Orange 7 RIPE NCC 8 Mark Prior 9 Connect 10 Cengiz Alaettinoglu 11 USC/ISI 12 February 21, 1999 14 Using RPSL in Practice 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC2026 except for the right to produce 20 derivative works. 22 This document can be found as draft-ietf-rps-appl-rpsl-04 in any standard 23 internet drafts repository. Internet Drafts are working documents of the 24 Internet Engineering Task Force (IETF), its Areas, and its Working Groups. 25 Note that other groups may also distribute working documents as Internet 26 Drafts. 28 Internet Drafts are draft documents valid for a maximum of six months. 29 Internet Drafts may be updated, replaced, or obsoleted by other documents 30 at any time. It is not appropriate to use Internet Drafts as reference 31 material, or to cite them other than as a ``working draft'' or ``work in 32 progress.'' 34 Please check the I-D abstract listing contained in each Internet Draft 35 directory to learn the current status of this or any other Internet Draft. 37 1 Introduction 39 This document is a tutorial on using the Routing Policy Specification 40 Language (RPSL) to describe routing policies in the Internet Routing 41 Registry (IRR). We explain how to specify various routing policies and 42 configurations using RPSL, how to register these policies in the IRR, and 43 how to analyze them using the routing policy analysis tools, for example 44 to generate vendor specific router configurations. This document is 45 targeted towards an Internet/Network Service Provider (ISP/NSP) engineer who 46 understands Internet routing, but is new to RPSL and to the IRR. Readers are 47 referred to the RPSL reference document [1] for completeness. It is also 48 good to have that document at hand while working through this tutorial. 50 The IRR is a repository of routing policies. Currently, the IRR repository 51 is a set of five repositories maintained at the following sites: the CA*Net 52 registry in Canada, the ANS, CW and RADB registries in the United States 53 of America, and the RIPE registry in Europe. The five repositories are 54 run independently. However, each site exchanges its data with the others 55 regularly (at least once a day and as often as every ten minutes). CW, 56 Ca*Net and ANS are private registries which contain the routing policies of 57 the networks and the customer networks of CW, Ca*Net, and ANS respectively. 58 RADB and RIPE are both public registries, and any ISP can publish their 59 policies in these registries. 61 The registries all maintain up-to-date copies of one another's data. At any 62 of the sites, the five registries can be inspected as a set. One should 63 refrain from registering his/her data in more than one of the registries, 64 as this practice leads almost invariably to inconsistencies in the data. 65 The user trying to interpret the data is left in a confusing (at best) 66 situation. CW, ANS and CA*Net customers are generally required to register 67 their policies in their provider's registry. Others may register policies 68 either at the RIPE or RADB registry, as preferred. 70 RPSL is based on RIPE-181 [2, 3], a language used to register routing 71 policies and configurations in the IRR. Operational use of RIPE-181 has 72 shown that it is sometimes difficult (or impossible) to express a routing 73 policy which is used in practice. RPSL has been developed to address these 74 shortcomings and to provide a language which can be further extended as the 75 need arises. RPSL obsoletes RIPE-181. 77 RPSL constructs are expressed in one or more database "objects" which are 78 registered in one of the registries described above. Each database object 79 contains some routing policy information and some necessary administrative 80 data. For example, an address prefix routed in the inter-domain mesh is 81 specified in a route object, and the peering policies of an AS are specified 82 in an aut-num object. The database objects are related to each other by 83 reference. For example, a route object must refer to the aut-num object 84 for the AS in which it is originated. Implicitly, these relationships 85 define sets of objects, which can be used to specify policies effecting all 86 members. For example, we can specify a policy for all routes of an ISP, 87 by referring to the AS number in which the routes are registered to be 88 originated. 90 When objects are registered in the IRR, they become available for others to 91 query using a whois service. Figure 1 illustrates the use of the whois 92 command to obtain the route object for 128.223.0.0/16. The output of the 93 whois command is the ASCII representation of the route object. The syntax 94 and semantics of the route object are described in Appendix A.3. Registered 95 policies can also be compared with others for consistency and they can be 96 used to diagnose operational routing problems in the Internet. 98 % whois -h radb.ra.net 128.223.0.0/16 99 route: 128.223.0.0/16 100 descr: UONet 101 descr: University of Oregon 102 descr: Computing Center 103 descr: Eugene, OR 97403-1212 104 descr: USA 105 origin: AS3582 106 mnt-by: MAINT-AS3582 107 changed: meyer@ns.uoregon.edu 19960222 108 source: RADB 110 Figure 1: whois command and a route object. 112 The RAToolSet [6] is a suite of tools which can be used to analyze the 113 routing registry data. It includes tools to configure routers (RtConfig), 114 tools to analyze paths on the Internet (prpath and prtraceroute), and tools 115 to compare, validate and register RPSL objects (roe, aoe and prcheck). 117 In the following section, we will describe how common routing policies can 118 be expressed in RPSL. The objects themselves are described in Appendix A. 119 Authoritative information on the IRR objects, however, should be sought in 120 RFC-2280, and authoritative information on general database objects (person, 121 role, and maintainers) and on querying and updating the registry databases, 122 should be sought in RIPE-157 [4]. Section 3.2 describes the use of RtConfig 123 to generate vendor specific router configurations. 125 2 Specifying Policy in RPSL 127 The key purpose of RPSL is to allow you to specify your routing 128 configuration in the public Internet Routing Registry (IRR), so that you and 129 others can check your policies and announcements for consistency. Moreover, 130 in the process of setting policies and configuring routers, you take the 131 policies and configurations of others into account. 133 In this section, we begin by showing how some simple peering policies can 134 be expressed in RPSL. We will build on that to introduce various database 135 objects that will be needed in order to register policies in the IRR, and to 136 show how more complex policies can be expressed. 138 2.1 Common Peering Policies 140 The peering policies of an AS are registered in an aut-num object which 141 looks something like that in Figure 2. We will focus on the semantics of 142 the import and export attributes in which peering policies are expressed. 143 We will also describe some of the other key attributes in the aut-num 144 object, but the reader should refer to RFC-2280 or to RIPE-157 for the 145 definitive descriptions. 147 aut-num: AS2 148 as-name: CAT-NET 149 descr: Catatonic State University 150 ... 151 import: from AS1 accept ANY 152 import: from AS3 accept <^AS3$> 153 export: to AS3 announce ANY 154 export: to AS1 announce AS2 AS3 155 ... 156 admin-c: AO36-RIPE 157 tech-c: CO19-RIPE 158 mnt-by: OPS4-RIPE 159 changed: orange@ripe.net 160 source: RIPE 162 Figure 2: Autonomous System Object 164 Now consider Figure 3. The peering policies expressed in the AS2 aut-num 165 object in Figure 2 are typical for a small service provider providing 166 connectivity for a customer AS3 and using AS1 for transit. That is, AS2 167 only accepts announcements from AS3 which: 169 o are originated in AS3; and 171 o have path length 1 (<^AS3$> means that AS3 is the first and last path 172 member)(1). 174 To AS1, AS2 announces only those routes which originate in their AS or in 175 their customer's AS. 177 ------------------------------ 178 1. AS-PATH regular expressions are POSIX compliant regular expressions. 180 AS1--------AS2--------AS3 181 | | 182 | | 183 AS4 AS5 185 Figure 3: Some Neighboring ASes. 187 In the example above, ``accept ANY'' in the import attribute indicates that 188 AS2 will accept any announcements that AS1 sends, and ``announce ANY'' in 189 the export attribute indicates that any route that AS2 has in its routing 190 table will be passed on to AS3. Assuming that AS1 announces ``ANY'' to AS2, 191 AS2 is taking full routing from AS1. 193 Note that with this peering arrangement, if AS1 adds or deletes route 194 objects, there is no need to update any of the aut-num objects to continue 195 the full routing policy. Added (or deleted) route objects will implicitly 196 update AS1's and AS2's policies. 198 While the peering policy specified in Figure 2 for AS2 is common, in 199 practice many peering agreements are more complex. Before we consider more 200 examples, however, let's first consider the aut-num object itself. Note 201 that it is just a set of attribute labels and values which can be submitted 202 to one of the registry databases. This particular object is specified as 203 being in (or headed for) the RIPE registry (see the last line in Figure 2). 204 The source should be specified as one of ANS, CANET, CW, RADB, or RIPE 205 depending on the registry in which the object is maintained. The source 206 attribute must be specified in every database object. 208 It is also worth noting that this object is ``maintained by'' OPS4-RIPE 209 (the value of the mnt-by attribute), which references a ``mntner'' object. 210 Because the aut-num object may be used for router configuration and other 211 operational purposes, the readers need to be able to count on the validity 212 of its contents. It is therefore required that a mntner be specified in 213 the aut-num and in most other database objects, which means you must create 214 a mntner object before you can register your peering policies. For brief 215 information on the ``mntner'' object and object writeability, see Appendix A 216 of this document. For more extensive information on how to set up and use a 217 mntner to protect your database objects, see Section 2.3 of RIPE-157. 219 2.2 ISP Customer - Transit Provider Policies 221 It is not uncommon for an ISP to acquire connectivity from a transit 222 provider which announces all routes to it, which it in turn passes on to its 223 customers to allow them to access hosts on the global Internet. Meanwhile, 224 the ISP will generally announce the routes of its customers networks to the 225 transit ISP, making them accessible on the global Internet. This is the 226 service that is specified in Figure 2 for AS3. 228 Consider again Figure 3. Suppose now that AS2 wants to provide the same 229 service to AS4. Clearly, it would be easy to modify the import and export 230 lines in the aut-num object for AS2 (Figure 2) to those shown in Figure 4. 232 import: from AS1 accept ANY 233 import: from AS3 accept <^AS3$> 234 import: from AS4 accept <^AS4$> 235 export: to AS3 announce ANY 236 export: to AS4 announce ANY 237 export: to AS1 announce AS2 AS3 AS4 239 Figure 4: Policy for AS3 and AS4 in the AS2 as-num object 241 These changes are trivial to make of course, but clearly as the number of 242 AS2 customers grows, it becomes more difficult to keep track of, and to 243 prevent errors. Note also that if AS1 is selective about only accepting 244 routes from the customers of AS2 from AS2, the aut-num object for AS1 would 245 have to be adjusted to accommodate AS2's new customer. 247 By using the RPSL ``as-set'' object, we can simplify this significantly. In 248 Figure 5, we describe the customers of AS2. Having this set to work with, 249 we can now rewrite the policies in Figure 2 as shown in Figure 6. 251 as-set: AS2:AS-CUSTOMERS 252 members: AS3 AS4 253 ... 254 changed: orange@ripe.net 255 source: RIPE 257 Figure 5: The as-set object 259 Note that if the aut-num object for AS1 contains the line: 261 import: from AS2 accept <^AS2+ AS2:AS-CUSTOMERS*$> 263 then no changes will need to be made to the aut-num objects for AS1 or 264 AS2 as the AS2 customer base grows. The AS numbers for new customers can 265 simply be added to the as-set AS2:AS-CUSTOMERS, and everything will work as 266 import: from AS1 accept ANY 267 import: from AS2:AS-CUSTOMERS accept <^AS2:AS-CUSTOMERS$> 268 export: to AS2:AS-CUSTOMERS announce ANY 269 export: to AS1 announce AS2 AS2:AS-CUSTOMERS 271 Figure 6: Policy in the AS2 aut-num object for all AS2 customers 273 for the existing customers. Clearly in terms of readability, scalability 274 and maintainability, this is a far better mechanism when compared to adding 275 policy for the customer AS's to the aut-num objects directly. The policy 276 in this particular example states that AS1 will accept route announcements 277 from AS2 in which the first element of the path is AS2, followed by more 278 occurrences of AS2, and then 0 or more occurrences of any AS2 customer (e.g. 279 any member of the as-set AS2:AS-CUSTOMERS). 281 Alternatively, one may wish to limit the routes one accepts from a peer, 282 especially if the peer is a customer. This is recommended for several 283 reasons, such as preventing the improper use of unassigned address space, 284 and of course malicious use of another organization's address space. 286 Such filtering can be expressed in various ways in RPSL. Suppose the address 287 space 7.7.0.0/16 has been allocated to the ISP managing AS3 for assignment 288 to its customers. AS3 may want to announce part or all of this block on 289 the global Internet. Suppose AS2 wants to be certain that it only accepts 290 announcements from AS3 for address space that has been properly allocated to 291 AS3. AS2 might then modify the AS3 import line in Figure 2 to read: 293 import: from AS3 accept { 7.7.0.0/16^16-19 } 295 which states that route announcements for this address block will be 296 accepted from AS3 if they are of length upto /19. This of course will have 297 to be modified if and when AS3 gets more address space. Moreover, it is 298 again clear that for an ISP with a growing or changing customer base, this 299 mechanism will not scale well. 301 Luckily RPSL supports the notion of a ``route-set'' which, as shown in 302 Figure 7, can be used to specify the set of routes that will be accepted 303 from a given customer. Given this set (and a similar one for AS4), the 304 manager of AS2 can now filter on the address space that will be accepted 305 from their customers by modifying the import lines in the AS2 aut-num object 306 as shown in Figure 8. 308 Note that this is now only slightly more complex than the example in 309 Figure 6. Furthermore, nothing need be changed in the AS2 aut-num object 310 route-set: AS2:RS-ROUTES:AS3 311 members: 7.7.0.0/16^16-19 312 ... 313 changed: orange@ripe.net 314 source: RIPE 316 Figure 7: The route-set object 318 import: from AS1 accept ANY 319 import: from AS3 accept AS2:RS-ROUTES:AS3 320 import: from AS4 accept AS2:RS-ROUTES:AS4 321 export: to AS2:AS-CUSTOMERS announce ANY 322 export: to AS1 announce AS2 AS2:AS-CUSTOMERS 324 Figure 8: Policy in the AS2 aut-num object for address based filtering on 325 AS2 customers 327 due to address space changes for a customer, and this filtering can be 328 supported without any changes to the AS1 aut-num object. The additional 329 complexity is due to the two route set names being different, otherwise we 330 could have combined the two import statements into one. Please note that 331 the set names are constructed hierarchically. The first AS number denotes 332 whose sets these are, and the last AS number parameterize these sets for 333 each peer. RPSL allows the peer's AS number to be replaced by the keyword 334 PeerAS. Hence, 336 import: from AS3 accept AS2:RS-ROUTES:PeerAS 337 import: from AS4 accept AS2:RS-ROUTES:PeerAS 339 has the same meaning as the corresponding import statements in Figure 6. 340 This lets us combine the two import statements into one as shown in 341 Figure 9. 343 2.3 Including Interfaces in Peering Definitions 345 In the above examples peerings were only given among ASes. However, the 346 peerings may be described in much more detail by RPSL, where peerings can 347 import: from AS1 accept ANY 348 import: from AS2:AS-CUSTOMERS accept AS2:RS-ROUTES:PeerAS 349 export: to AS2:AS-CUSTOMERS announce ANY 350 export: to AS1 announce AS2 AS2:AS-CUSTOMERS 352 Figure 9: Policy in the AS2 aut-num object using PeerAS 354 +--------------------+ +--------------------+ 355 | 7.7.7.1 |-----+ +-----| 7.7.7.2 | 356 | | | | | | 357 | AS1 | ======== | AS2 | 358 | | IX | | | 359 | | +-----| 7.7.7.3 | 360 +--------------------+ +--------------------+ 362 Figure 10: Including interfaces in peerings definitions 364 be specified between physical routers using IP addresses in the import and 365 export attributes. Figure 10 shows a simple example in which AS1 and AS2 366 are connected to an exchange point IX. While AS1 has only one connection to 367 the exchange point via a router interface with IP address 7.7.7.1, AS2 has 368 two different connections with IP address 7.7.7.2 and 7.7.7.3. The first AS 369 may then define its routing policy in more detail by specifying its boundary 370 router. 372 aut-num: AS1 373 import: from AS2 at 7.7.7.1 accept <^AS2$> 374 ... 376 Because AS1 has only one connection to the exchange point in this example, 377 this specification does not differ from that in which no boundary router 378 is specified. However, AS1 might want to choose to accept only those 379 announcements from AS2 which come from the router with IP address 7.7.7.2 380 and disregard those announcements from router 7.7.7.3. AS1 can specify this 381 routing policy as follows: 383 aut-num: AS1 384 import: from AS2 7.7.7.2 at 7.7.7.1 accept <^AS2$> 385 ... 387 By selecting certain pairs of routers in a peering specification, others can 388 be denied. If no routers are included in a policy clause then it is assumed 389 that the policy applies to all peerings among the ASes involved. 391 2.4 Describing Simple Backup Connections 393 The specification of peerings among ASes is not limited to one router for 394 each AS. In figure 10 one of the two connections of AS2 to the exchange 395 point IX might be used as backup in case the other connection fails. Let us 396 assume that AS1 wants to use the connection to router 7.7.7.2 of AS2 during 397 regular operations, and router 7.7.7.3 as backup. In a router configuration 398 this may be done by setting a local preference. The equivalent in RPSL is 399 a corresponding action definition in the peering description. The action 400 definitions are inserted directly before the accept keyword. 402 aut-num: AS1 403 import: from AS2 7.7.7.2 at 7.7.7.1 action pref=10; 404 from AS2 7.7.7.3 at 7.7.7.1 action pref=20; 405 accept <^AS2$> 406 ... 408 pref is opposite to local-pref in that the smaller values are preferred over 409 larger values. Actions may also be defined without specifying IP addresses 410 of routers. If no routers are included in the policy clause then it is 411 assumed that the actions are carried out for all peerings among the ASes 412 involved. 414 In the previous example AS1 controls where it sends its traffic and which 415 connection is used as backup. However, AS2 may also define a backup 416 connection in an export clause: 418 aut-num: AS2 419 export: to AS1 7.7.7.1 at 7.7.7.2 action med=10; 420 to AS1 7.7.7.1 at 7.7.7.3 action med=20; 421 announce <^AS2$> 423 The definition given here for AS2 is the symmetric counterpart to the 424 routing policy of AS1. The selection of routing information is done by 425 setting the multi exit discriminator metric med. Actually, med metrics will 426 not be used in practice like this; they are more suitable for load balancing 427 including backups. For more details on med metrics refer to the BGP-4 428 RFC [7]. To use the med to achieve load balancing, one often sets it to the 429 ``IGP metric''. This is specified in RPSL as: 431 aut-num: AS2 432 export: to AS1 action med=igp_cost; announce <^AS2$> 434 Hence, both routers will set the med to the IGP metric at that router, 435 causing some routes to be preferred at one of the routers and other routes 436 at the other router. 438 2.5 Multi-Home Routing Policies using the community Attribute 440 RFC 1998 [9] describes the use of the BGP community attribute to handle the 441 load balancing and backup connection of multi-homed autonomous systems. In 442 this section, we illustrate how those policies are specified in RPSL. 444 AS3561 allows customers to influence it's route selection algorithm by 445 tagging routes with a BGP community. These communities are used to lower 446 the local preference of a route learned from the customer. Other autonomous 447 systems may also indirectly affect AS3561's route selection by including the 448 appropriate communities in their route announcements provided that they are 449 passed to AS3561 via a customer. 451 AS3561 might publicise this policy in their routing policy using the 452 following policy fragment: 454 aut-num: AS3561 455 import: { 456 from AS-ANY 457 action pref=30; 458 accept community.contains(3761:70); 459 from AS-ANY 460 action pref=20; 461 accept community.contains(3761:80); 462 from AS-ANY 463 action pref=10; 464 accept community.contains(3761:90); 465 from AS-ANY 466 action pref=0; 467 accept ANY; 468 } refine { 469 from AS3561:AS-CUSTOMERS 470 accept AS3561:AS-CUSTOMERS:PeerAS 471 AND <^PeerAS+ AS3561:AS-CUSTOMERS:PeerAS*$> 472 } 473 ... 475 as-set: AS3561:AS-CUSTOMERS 476 members: AS2, AS3, ... 478 as-set: AS3561:AS-CUSTOMERS:AS2 479 members: AS2, AS1, AS4, ... 481 as-set: AS3561:AS-CUSTOMERS:AS3 482 members: AS3, AS1, AS5, ... 484 Here a refine statement is used to condense the policy and ensure that the 485 same base policy is applied with the pref changing depending on the presence 486 of a specific BGP community. The base policy makes use of hierarchical 487 naming to group customers and defines both a route and an AS path policy 488 filter. To better understand the policy you could view it as an iteration 489 across the set AS3561:AS-CUSTOMERS. That is, 491 from AS3561:AS-CUSTOMERS 492 accept AS3561:AS-CUSTOMERS:PeerAS 493 AND <^PeerAS+ AS3561:AS-CUSTOMERS:PeerAS*$> 495 is equivalent to: 497 from AS2 498 accept AS3561:AS-CUSTOMERS:AS2 499 AND <^AS2+ AS3561:AS-CUSTOMERS:AS2*$> 500 from AS3 501 accept AS3561:AS-CUSTOMERS:AS3 502 AND <^AS3+ AS3561:AS-CUSTOMERS:AS3*$> 504 where the actual AS replaces PeerAS. Further substitution of the sets 505 yields: 507 from AS2 508 accept ( AS2 OR AS1 OR AS4 OR ... ) 509 AND <^AS2+ (AS2|AS1|AS4|...)*$> 510 from AS3 511 accept ( AS3 OR AS1 OR AS5 OR ... ) 512 AND <^AS3+ (AS3|AS1|AS5|...)*$> 514 To illustrate how this policy might be utilised by a customer consider that 515 in this example AS1 is multihomed to both AS2 and AS3, which are in turn 516 both customers of AS3561. We see from AS3561's policy that routes without 517 a BGP community retain their default local preference while routes tagged 518 with 3561:90 have their local preference reduced by 10, routes tagged with 519 3561:80 are reduced by 20 and routes tagged with 3561:70 are reduced by 30. 520 If AS1 wants AS3561 to prefer the AS2 connection over the AS3 connection, 521 possibly due to the relative performance of the links, then it would use the 522 following policy fragment to add the appropriate community when exporting 523 its routes to AS2 and AS3. 525 aut-num: AS1 526 export: to AS2 action community.append(3761:90); 527 announce AS1 528 export: to AS3 action community.append(3761:80); 529 announce AS1 531 3 Tools 533 In this section, we briefly introduce a number of tools which can be used 534 to inspect data in the database, to determine optimal routing policies, and 535 enter new data. 537 3.1 The aut-num Object Editor 539 All the examples shown in the previous sections may well be edited by hand. 540 They may be extracted one by one from the IRR using the whois program, 541 edited, and then handed back to the registry robots. However, again the 542 RAToolSet [6] provides a very nice tool which makes working with aut-num 543 objects much easier: the aut-num object editor aoe (please see Figure 11). 545 The aut-num object editor has a graphical user interface to view and 546 manipulate aut-num objects registered at any IRR. New aut-num objects may be 547 generated using templates and submitted to the registries. Moreover, the 548 routing policy from the databases may be compared to real life peerings. 549 Therefore, aoe is highly recommended as an interface to the IRR for 550 aut-num objects. Further information on aoe is available together with the 551 RAToolSet [6]. 553 3.2 Router Configuration Using RtConfig 555 RtConfig is a tool developed by the Routing Arbiter project [8] to 556 generate vendor specific router configurations from the policy data held 557 in the various IRRs. RtConfig currently supports Cisco, gated and RSd 558 configuration formats. It has been publicly available since late 1994, 559 and is currently being used by many sites for router configuration. The 560 next section describes a methodology for generating vendor specific router 561 configurations using RtConfig.(2) 563 ------------------------------ 564 2. Discussion of RtConfig internals is beyond the scope of this document. 566 Figure 11: Autonomous System object editor (aoe). 568 3.3 Using RtConfig 570 The general paradigm for using RtConfig involves registering policy in an 571 IRR, building a RtConfig source file, then running running RtConfig against 572 the source file and the IRR database to create vendor specific router 573 configuration for the specified policy. The source file will contain vendor 574 specific commands as well as RtConfig commands. To make a source file, pick 575 up one of your router configuration files and replace the vendor specific 576 policy configuration commands with the RtConfig commands. 578 Commands beginning with @RtConfig instruct RtConfig to perform special 579 operations. An example source file is shown in Figure 12. In this 580 example, commands such as ``@RtConfig import AS3582 198.32.162.1 AS3701 581 198.32.162.2'' instruct RtConfig to generate vendor specific import policies 582 where the router 198.32.162.1 in AS3582 is importing routes from router 583 198.32.162.2 in AS3701. The other @RtConfig commands instruct the RtConfig 584 to use certain names and numbers in the output that it generates (please 585 refer to RtConfig manual [8] for additional information). 587 router bgp 3582 588 network 128.223.0.0 589 ! 590 ! Start with access-list 100 591 ! 592 @RtConfig set cisco_access_list_no = 100 593 ! 594 ! NERO 595 ! 596 neighbor 198.32.162.2 remote-as 3701 597 @RtConfig set cisco_map_name = "AS3701-EXPORT" 598 @RtConfig export AS3582 198.32.162.1 AS3701 198.32.162.2 599 @RtConfig set cisco_map_name = "AS3701-IMPORT" 600 @RtConfig import AS3582 198.32.162.1 AS3701 198.32.162.2 601 ! 602 ! WNA/VERIO 603 ! 604 neighbor 198.32.162.6 remote-as 2914 605 @RtConfig set cisco_map_name = "AS2914-EXPORT" 606 @RtConfig export AS3582 198.32.162.1 AS2914 198.32.162.6 607 @RtConfig set cisco_map_name = "AS2914-IMPORT" 608 @RtConfig import AS3582 198.32.162.1 AS2914 198.32.162.6 609 ... 611 Figure 12: RtConfig Template File 613 Once a source file is created, the file is processed by RtConfig (the 614 default IRR is the RADB, and the default vendor is Cisco; however, command 615 line options can be used to override these values). The result of 616 running RtConfig on the source file in Figure 12 is shown in Figure 20 in 617 Appendix B. 619 A RPSL Database Objects 621 In this appendix, we introduce the RPSL objects required to implement many 622 typical Internet routing policies. RFC-2280 and RIPE-157 provide the 623 authoritative description for these objects and for the RPSL syntax, but 624 this appendix will often be sufficient in practice. 626 The frequently needed objects are: 628 o maintainer objects (mntner) 630 o autonomous system number objects (aut-num) 631 o route objects (route) 633 o set objects (as-set, route-set) 635 and they are described in the following sections. To make your routing 636 policies and configuration public, these objects should be registered in 637 exactly one of the IRR registries. 639 In general, you can register your information by sending the appropriate 640 objects to an email address for the registry you use. The email should 641 consist of the objects you want to have registered or modified, separated 642 by empty lines, and preceded by some kind of authentication details (see 643 below). The registry robot processes your mail and enters new objects 644 into the database, deletes old ones (upon request), or makes the requested 645 modifications. 647 You will receive a response indicating the status of your submission. As 648 the emails are handled automatically, the response is generally very fast. 649 However, it should be remembered that a significant number of updates are 650 also sometimes submitted to the database (by other robots), so the response 651 time cannot be guaranteed. The email addresses for submitting objects to 652 the existing registries are listed in Figure 13. 654 ANS auto-dbm@ans.net 655 CANET auto-dbm@canet.net 656 CW auto-rr@cw.net 657 RADB auto-dbm@radb.ra.net 658 RIPE auto-dbm@ripe.net 660 Figure 13: Email addresses to register policy objects in IRR. 662 Because it is required that a maintainer be specified in many of the 663 database objects, a mntner is usually the first to be created. To have it 664 properly authenticated, a mntner object is added manually by registry staff. 665 Thereafter, all database submissions, deletions and modifications should be 666 done through the registry robot. 668 Each of the registries should can provide additional information and support 669 for users. For the public registries this support is available at: 671 RADB db-admin@radb.ra.net 672 RIPE ripe-dbm@ripe.net 674 If you are using one of the private registries, your service provider should 675 be able to address your questions. 677 A.1 The Maintainer Object 679 The maintainer object is used to introduce some kind of authorization 680 for registrations. It lists various contact persons and describes 681 security mechanisms that will be applied when updating objects in the 682 IRR. Registering a mntner object is the first step in creating policies 683 for an AS. An example is shown in Figure 14. The maintainer is called 684 MAINT-AS3701. The contact person here is the same for administrative 685 (admin-c) and technical (tech-c) issues and is referenced by the NIC-handle 686 DMM65. NIC-handles are unique identifiers for persons in registries. Refer 687 to registry documentation for further details on person objects and usage of 688 NIC-handles. 690 The example shows two authentication mechanisms: CRYPT-PW and MAIL-FROM. 691 CRYPT-PW takes as its argument a password that is encrypted with Unix 692 crypt(3) routine. When sending updates, the maintainer adds the field 693 password: to the beginning of any requests that are to 694 be authenticated. MAIL-FROM takes an argument that is a regular expression 695 which covers a set of mail addresses. Only users with any of these mail 696 addresses are authorized to work with objects secured by the corresponding 697 maintainer(3). 699 The security mechanisms of the mntner object will only be applied on those 700 objects referencing a specific mntner object. The reference is done by 701 adding the attribute mnt-by to an object using the name of the mntner object 702 as its value. In Figure 14, the maintainer MAINT-AS3701 is maintained by 703 itself. 705 A.2 The Autonomous System Object 707 The autonomous system object describes the import and export policies of an 708 AS. Each organization registers an autonomous system object (aut-num) in the 709 IRR for its AS. Figure 15 shows the aut-num for AS3582 (UONET). 711 The autonomous system object lists contacts (admin-c, tech-c) and is 712 maintained by (mnt-by) MAINT-AS3701 which is the maintainer displayed in 713 Figure 14. 715 The most important attributes of the aut-num object are import and export. 716 The import clause of an aut-num specifies import policies, while the export 717 clause specifies export policies. The corresponding clauses allow a very 718 detailed description of the routing policy of the AS specified. The details 719 are given in section 2. 721 ------------------------------ 722 3. Clearly, neither of these mechanisms is sufficient to provide 723 strong authentication or authorization. Other public key (e.g., PGP) 724 authentication mechanisms are available from some of the IRRs. 726 mntner: MAINT-AS3701 727 descr: Network for Research and Engineering in Oregon 728 remark: Internal Backbone 729 admin-c: DMM65 730 tech-c: DMM65 731 upd-to: noc@nero.net 732 auth: CRYPT-PW 949WK1mirBy6c 733 auth: MAIL-FROM .*@nero.net 734 notify: noc@nero.net 735 mnt-by: MAINT-AS3701 736 changed: meyer@antc.uoregon.edu 970318 737 source: RADB 739 Figure 14: Maintainer Object 741 With these clauses, an aut-num object shows its relationship to other 742 autonomous systems by describing its peerings. In addition, it also defines 743 a routing entity comprising a group of IP networks which are handled 744 according to the rules defined in the aut-num object. Therefore, it is 745 closely linked to route objects. 747 In this example, AS3582 imports all routes from AS3701 by using the keyword 748 ANY. AS3582 imports only internal routes from AS4222, AS5650, and AS1798. 749 The import policy for for AS2914 is slightly more complex. Since AS2914 750 provides transit to various other ASes, AS3582 accepts routes with ASPATHs 751 that begin with AS2194 followed by members of AS-WNA, which is an as set 752 (see section A.4.1 below) describing those customers that transit AS2914. 754 Since AS3582 is a multi-homed stub AS (i.e., it does not provide transit), 755 its export policy consists simply of ``announce AS3582'' clauses; that is, 756 announce internal routes of AS3582. These routes are those in route objects 757 where the origin attribute is AS3582. 759 The aut-num object forms the basis of a scalable and maintainable router 760 configuration system. For example, if AS3582 originates a new route, it 761 need only create a route object for that route with origin AS3582. AS3582 762 can now build configuration using this route object without changing its 763 aut-num object. 765 Similarly, if for example, AS3701 originates a new route, it need only 766 create a route object for that route with origin AS3701. Both AS3701 and 767 AS3582 can now build configuration using this route object without modifying 768 its aut-num object. 770 aut-num: AS3582 771 as-name: UONET 772 descr: University of Oregon, Eugene OR 773 import: from AS3701 accept ANY 774 import: from AS4222 accept <^AS4222$> 775 import: from AS5650 accept <^AS5650$> 776 import: from AS2914 accept <^AS2914+ (AS-WNA)*$> 777 import: from AS1798 accept <^AS1798$> 778 export: to AS3701 announce AS3582 779 export: to AS4222 announce AS3582 780 export: to AS5650 announce AS3582 781 export: to AS2914 announce AS3582 782 export: to AS1798 announce AS3582 783 admin-c: DMM65 784 tech-c: DMM65 785 notify: nethelp@ns.uoregon.edu 786 mnt-by: MAINT-AS3582 787 changed: meyer@antc.uoregon.edu 970316 788 source: RADB 790 Figure 15: Autonomous System Object 792 route: 128.223.0.0/16 793 origin: AS3582 794 descr: UONet 795 descr: University of Oregon 796 descr: Computing Center 797 descr: Eugene, OR 97403-1212 798 descr: USA 799 mnt-by: MAINT-AS3582 800 changed: meyer@ns.uoregon.edu 960222 801 source: RADB 803 Figure 16: Example of a route object 805 A.3 The Route Object 807 In contrast to aut-num objects which describe propagation of routing 808 information for an autonomous system as a whole, route objects define single 809 routes from an AS. An example is given in Figure 16. 811 This route object is maintained by MAINT-AS3582 and references AS3582 by 812 the origin attribute. By this reference it is grouped together with other 813 routes of the same origin AS, becoming member of the routing entity denoted 814 by AS3582. The routing policies can then be defined in the aut-num objects 815 for this group of routes. 817 Consequently, the route objects give the routes from this AS which are 818 distributed to peer ASes according to the rules of the routing policy. 819 Therefore, for any route in the routing tables of the backbone routers a 820 route object must exist in one of the registries in IRR. route objects must 821 be registered in the IRR only for the routes seen outside your AS. Normally, 822 this set of external routes is different from the routes internally visible 823 within your AS. One of the major reasons is that external peers need no 824 information at all about your internal routing specifics. Therefore, 825 external routes are in general aggregated combinations of internal routes, 826 having shorter IP prefixes where applicable according to the CIDR rules. 827 Please see the CIDR FAQ [5] for a tutorial introduction to CIDR. It is 828 strongly recommended that you aggregate your routes as much as possible, 829 thereby minimizing the number of routes you inject into the global routing 830 table and at the same time reducing the corresponding number of route 831 objects in the IRR. 833 While you may easily query single route objects using the whois program, and 834 submit objects via mail to the registry robots, this becomes kind of awkward 835 for larger sets. The RAToolSet [6] offers several tools to make handling of 836 route objects easier. If you want to read policy data from the IRR and 837 process it by other programs, you might be interested in using peval which 838 is a low level policy evaluation tool. As an example, the command 840 peval -h radb.ra.net AS3582 842 will give you all route objects from AS3582 registered with RADB. 844 A much more sophisticated tool from the RAToolSet to handle route objects 845 interactively is the route object editor roe (please see Figure 17). It has 846 a graphical user interface to view and manipulate route objects registered 847 at any IRR. New route objects may be generated from templates and submitted 848 to the registries. Moreover, the route objects from the databases may be 849 compared to real life routes. Therefore, roe is highly recommended as an 850 interface to the IRR for route objects. Further information on peval and 851 roe is available together with the RAToolSet [6]. 853 A.4 Set Objects 855 With routing policies it is often necessary to reference groups of 856 autonomous systems or routes which have identical properties regarding a 857 specific policy. To make working with such groups easier RPSL allows to 858 combine them in set objects. There are two basic types of predefined set 859 objects, as-set, and route-set. The RPSL set objects are described below. 861 Figure 17: route object editor (roe). 863 A.4.1 AS-SET Object 865 Autonomous system set objects (as-set) are used to group autonomous system 866 objects into named sets. An as-set has an RPSL name that starts with 867 ``AS-''. In the example in Figure 18, an as-set called AS-NERO-PARTNERS and 868 containing AS3701, AS4201, AS3582, AS4222, AS1798 is defined. The as-set 869 is the RPSL replacement for the RIPE-181 as-macro. It has been extended 870 to include ASes in the set indirectly by referencing as set names in the 871 aut-num objects. 873 AS-SETs are particularly useful when specifying policies for groups such 874 as customers, providers, or for transit. You are encouraged to register 875 sets for these groups because it is most likely that you will treat them 876 alike, i.e. you will have a very similar routing policy for all your 877 customers which have an autonomous system of their own. You may as well 878 discover that this is also true for the providers you are peering with, 879 and it is most convenient to have the ASes combined in one as-set for 880 which you offer transit. For example, if a transit provider specifies its 881 import policy using its customer's as-set (i.e., its import clause for the 882 customer contains the customer's as-set), then that customer can modify the 883 set of ASes that its transit provider accepts from it. Again, this can 884 be accomplished without requiring the customer or the transit provider to 885 modify its aut-num object. 887 as-set: AS3582:AS-PARTNERS 888 members: AS3701, AS4201, AS3582, AS4222, AS1798 890 Figure 18: as-set Object 892 The ASes of the set are simply compiled in a comma delimited list following 893 the members attribute of the as-set. This list may also contain other 894 AS-SET names. 896 A.4.2 ROUTE-SET Object 898 A route-set is a way to name a group of routes. The syntax is similar to 899 the as-set. A route-set has an RPSL name that starts with ``RS-''. The 900 members attribute lists the members of the set. The value of a members 901 attribute is a list of address prefixes, or route-set names. The members 902 of the route-set are the address prefixes or the names of other route sets 903 specified. 905 Figure 19 presents some example route-set objects. The set rs-uo contains 906 two address prefixes, namely 128.223.0.0/16 and 198.32.162.0/24. The 907 set rs-bar contains the members of the set rs-uo and the address prefix 908 128.7.0.0/16. The set rs-martians illustrate the use of range operators. 909 0.0.0.0/0^32 are the length 32 more specifics of 0.0.0.0/0, i.e. the host 910 routes; 224.0.0.0/3^+ are the more specifics of 224.0.0.0/3, i.e. the routes 911 falling into the multicast address space. For more complete list of range 912 operators please refer to RFC-2280. 914 B Output of RtConfig: An Example 916 In Figure 20, you see the result of running RtConfig on the source file in 917 Figure 12. 919 References 921 [1] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. 922 Terpstra, and C. Villamizer: Routing Policy Specification Language 923 (RPSL), RFC 2280. 925 route-set: rs-uo 926 members: 128.223.0.0/16, 198.32.162.0/24 928 route-set: rs-bar 929 members: 128.7.0.0/16, rs-uo 931 route-set: rs-martians 932 remarks: routes not accepted from any peer 933 members: 0.0.0.0/0, # default route 934 0.0.0.0/0^32, # host routes 935 224.0.0.0/3^+, # multicast routes 936 127.0.0.0/8^9-32, . . . 938 Figure 19: route-set Objects 940 [2] T. Bates, J-M. Jouanigot, D. Karrenberg, P. Lothberg, and M. Terpstra. 941 Representation of IP Routing Policies in the RIPE database, Technical 942 Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993. 944 [3] T. Bates, E. Gerich, J. Joncharay, J-M. Jouanigot, D. Karrenberg, 945 M. Terpstra, and J. Yu. Representation of IP Routing Policies in 946 a Routing Registry, Technical Report ripe-181, RIPE, RIPE NCC, 947 Amsterdam, Netherlands, October 1994. 949 [4] A. M. R. Magee. RIPE NCC Database Documentation. Technical Report 950 RIPE-157, RIPE NCC, Amsterdam, Netherlands, May 1997. 952 [5] Hank Nussbacher. The CIDR FAQ. Tel Aviv University and IBM Israel. 953 http://www.ibm.net.il/~hank/cidr.html 955 [6] The RAToolSet. http://www.ra.net/ra/RAToolSet/ 957 [7] Y. Rekhter adn T. Li. A Border Gateway Protocol 4 (BGP-4). Request for 958 Comment RFC 1654. Network Information Center, July 1994. 960 [8] RtConfig as part of the RAToolSet. 961 http://www.ra.net/ra/RAToolSet/RtConfig.html 963 [9] E. Chen, T. Bates. An Application of the BGP Community Attribute in 964 Multi-Home Routing. RFC 1998. 966 router bgp 3582 967 network 128.223.0.0 968 ! 969 ! NERO 970 ! 971 neighbor 198.32.162.2 remote-as 3701 973 no access-list 100 974 access-list 100 permit ip 128.223.0.0 0.0.0.0 255.255.0.0 0.0.0.0 975 access-list 100 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 976 ! 977 ! 978 no route-map AS3701-EXPORT 979 route-map AS3701-EXPORT permit 1 980 match ip address 100 981 ! 982 router bgp 3582 983 neighbor 198.32.162.2 route-map AS3701-EXPORT out 984 ! 985 ! 986 no route-map AS3701-IMPORT 987 route-map AS3701-IMPORT permit 1 988 set local-preference 1000 989 ! 990 router bgp 3582 991 neighbor 198.32.162.2 route-map AS3701-IMPORT in 992 ! 993 ! WNA/VERIO 994 ! 995 neighbor 198.32.162.6 remote-as 2914 996 ! 997 no route-map AS2914-EXPORT 998 route-map AS2914-EXPORT permit 1 999 match ip address 100 1000 ! 1001 router bgp 3582 1002 neighbor 198.32.162.6 route-map AS2914-EXPORT out 1003 no ip as-path access-list 100 1004 ip as-path access-list 100 permit ^_2914(((_[0-9]+))*_ \ 1005 (13|22|97|132|175|668|1914|2905|2914|3361|3381|3791|3937| \ 1006 4178|4354|4571|4674|4683|5091|5303|5798|5855|5856|5881|6083 \ 1007 |6188|6971|7790|7951|8028))?$ 1008 ! 1009 no route-map AS2914-IMPORT 1010 route-map AS2914-IMPORT permit 1 1011 match as-path 100 1012 set local-preference 998 1013 ! 1014 router bgp 3582 1015 neighbor 198.32.162.6 route-map AS2914-IMPORT in 1016 ! 1018 Figure 20: Output of RtConfig