idnits 2.17.1 draft-ietf-rps-appl-rpsl-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) 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. ** 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 312 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 413 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 33 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances 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 19 has weird spacing: '...tribute worki...' == Line 24 has weird spacing: '...e. It is no...' == Line 25 has weird spacing: '...to cite them ...' == Line 28 has weird spacing: '...e check the I...' == Line 33 has weird spacing: '...ocument is a...' == (307 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 (November 18, 1998) is 9281 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) ** 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 (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft David Meyer 3 Expires May 18, 1999 Cisco Systems 4 draft-ietf-rps-appl-rpsl-03.txt Joachim Schmitz 5 DFN-NOC 6 Carol Orange 7 RIPE NCC 8 Cengiz Alaettinoglu 9 USC/ISI 10 November 18, 1998 12 Using RPSL in Practice 14 Status of this Memo 16 This document is an Internet Draft, and can be found as draft-ietf-rps-appl- 17 rpsl-03.txt in any standard internet drafts repository. Internet Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. Note that other groups may also distribute working 20 documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six months. 23 Internet Drafts may be updated, replaced, or obsoleted by other documents 24 at any time. It is not appropriate to use Internet Drafts as reference 25 material, or to cite them other than as a ``working draft'' or ``work in 26 progress.'' 28 Please check the I-D abstract listing contained in each Internet Draft 29 directory to learn the current status of this or any other Internet Draft. 31 1 Introduction 33 This document is a tutorial on using the Routing Policy Specification 34 Language (RPSL) to describe routing policies in the Internet Routing 35 Registry (IRR). We explain how to specify various routing policies and 36 configurations using RPSL, how to register these policies in the IRR, and 37 how to analyze them using the routing policy analysis tools, for example 38 to generate vendor specific router configurations. This document is 39 targeted towards an Internet/Network Service Provider (ISP/NSP) engineer who 40 understands Internet routing, but is new to RPSL and to the IRR. Readers are 41 referred to the RPSL reference document [1] for completeness. It is also 42 good to have that document at hand while working through this tutorial. 44 The IRR is a repository of routing policies. Currently, the IRR repository 45 is a set of five repositories maintained at the following sites: the CA*Net 46 registry in Canada, the ANS, MCI and RADB registries in the United States 47 of America, and the RIPE registry in Europe. The five repositories are 48 run independently. However, each site exchanges its data with the others 49 regularly (at least once a day and as often as every ten minutes). MCI, 50 Ca*Net and ANS are private registries which contain the routing policies of 51 the networks and the customer networks of MCI, Ca*Net, and ANS respectively. 52 RADB and RIPE are both public registries, and any ISP can publish their 53 policies in these registries. 55 The registries all maintain up-to-date copies of one another's data. At any 56 of the sites, the five registries can be inspected as a set. One should 57 refrain from registering his/her data in more than one of the registries, 58 as this practice leads almost invariably to inconsistencies in the data. 59 The user trying to interpret the data is left in a confusing (at best) 60 situation. MCI, ANS and CA*Net customers are generally required to register 61 their policies in their provider's registry. Others may register policies 62 either at the RIPE or RADB registry, as preferred. 64 RPSL is based on RIPE-181 [2, 3], a language used to register routing 65 policies and configurations in the IRR. Operational use of RIPE-181 has 66 shown that it is sometimes difficult (or impossible) to express a routing 67 policy which is used in practice. RPSL has been developed to address these 68 shortcomings and to provide a language which can be further extended as the 69 need arises. RPSL obsoletes RIPE-181 [2, 3]. 71 RPSL constructs are expressed in one or more database "objects" which are 72 registered in one of the registries described above. Each database object 73 contains some routing policy information and some necessary administrative 74 data. For example, an address prefix routed in the inter-domain mesh is 75 specified in a route object, and the peering policies of an AS are specified 76 in an aut-num object. The database objects are related to each other by 77 reference. For example, a route object must refer to the aut-num object 78 for the AS in which it is originated. Implicitly, these relationships 79 define sets of objects, which can be used to specify policies effecting all 80 members. For example, we can specify a policy for all routes of an ISP, 81 by referring to the AS number in which the routes are registered to be 82 originated. 84 When objects are registered in the IRR, they become available for others to 85 query using a whois service. Figure 1 illustrates the use of the whois 86 command to obtain the route object for 128.223.0.0/16. The output of the 87 whois command is the ASCII representation of the route object. The syntax 88 and semantics of the route object are described in Appendix A.3. Registered 89 policies can also be compared with others for consistency and they can be 90 used to diagnose operational routing problems in the Internet. 92 The RAToolSet [6] is a suite of tools which can be used to analyze the 93 routing registry data. It includes tools to configure routers (RtConfig), 94 tools to analyse paths on the Internet (prpath and prtraceroute), and tools 95 % whois -h radb.ra.net 128.223.0.0/16 96 route: 128.223.0.0/16 97 descr: UONet 98 descr: University of Oregon 99 descr: Computing Center 100 descr: Eugene, OR 97403-1212 101 descr: USA 102 origin: AS3582 103 mnt-by: MAINT-AS3582 104 changed: meyer@ns.uoregon.edu 19960222 105 source: RADB 107 Figure 1: whois command and a route object. 109 to compare, validate and register RPSL objects (roe, aoe and prcheck). 111 In the following section, we will describe how common routing policies can 112 be expressed in RPSL. The objects themselves are described in Appendix A. 113 Authoritative information on the IRR objects, however, should be sought in 114 RFC-2280, and authoritative information on general database objects (person, 115 role, and maintainers) and on querying and updating the registry databases, 116 should be sought in RIPE-157 [4]. Section 3.2 describes the use of RtConfig 117 to generate vendor specific router configurations. 119 2 Specifying Policy in RPSL 121 The key purpose of RPSL is to allow you to specify your routing 122 configuration in the public Internet Routing Registry (IRR), so that you and 123 others can check your policies and announcements for consistency. Moreover, 124 in the process of setting policies and configuring routers, you take the 125 policies and configurations of others into account. 127 In this section, we begin by showing how some simple peering policies can 128 be expressed in RPSL. We will build on that to introduce various database 129 objects that will be needed in order to register policies in the IRR, and to 130 show how more complex policies and be expressed. 132 2.1 Common Peering Policies 134 The peering policies of an AS are registered in an aut-num object which 135 looks something like that in Figure 2. We will focus on the semantics of 136 the import and export attributes in which peering policies are expressed. 137 We will also describe some of the other key attributes in the aut-num 138 object, but the reader should refer to RFC-2280 or to RIPE-157 for the 139 definitive descriptions. 141 aut-num: AS2 142 as-name: CAT-NET 143 descr: Catatonic State University 144 ... 145 import: from AS1 accept ANY 146 import: from AS3 accept <^AS3$> 147 export: to AS3 announce ANY 148 export: to AS1 announce AS2 AS3 149 ... 150 admin-c: AO36-RIPE 151 tech-c: CO19-RIPE 152 mnt-by: OPS4-RIPE 153 changed: orange@ripe.net 154 source: RIPE 156 Figure 2: Autonomous System Object 158 Now consider Figure 3. The peering policies expressed in the AS2 aut-num 159 object in Figure 2 are typical for a small service provider providing 160 connectivity for a customer AS3 and using AS1 for transit. That is, AS2 161 only accepts announcements from AS3 which: 163 o are originated in AS3; and 165 o have path length 1 (<^AS3$> means that AS3 is the first and last path 166 member)(1). 168 To AS1, AS2 announces only those routes which originate in their AS or in 169 their customer's AS. 171 In the example above, ``accept ANY'' in the import attribute indicates that 172 AS2 will accept any announcements that AS1 sends, and ``announce ANY'' in 173 the export attribute indicates that any route that AS2 has in its routing 174 table will be passed on to AS3. Assuming that AS1 announces ``ANY'' to AS2, 175 AS2 is taking full routing from AS1. 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 Note that with this peering arrangement, if AS1 adds or deletes route 188 objects, there is no need to update any of the aut-num objects to continue 189 the full routing policy. Added (or deleted) route objects will implicitly 190 update AS1's and AS2's policies. 192 While the peering policy specified in Figure 2 for AS2 is common, in 193 practice many peering agreements are more complex. Before we consider more 194 examples, however, let's first consider the aut-num object itself. Note 195 that it is just a set of attribute labels and values which can be submitted 196 to one of the registry databases. This particular object is specified as 197 being in (or headed for) the RIPE registry (see the last line in Figure 2). 198 The source should be specified as one of ANS, CANET, MCI, RADB, or RIPE 199 depending on the registry in which the object is maintained. The source 200 attribute must be specified in every database object. 202 It is also worth noting that this object is ``maintained by'' OPS4-RIPE 203 (the value of the mnt-by attribute), which references a ``mntner'' object. 204 Because the aut-num object may be used for router configuration and other 205 operational purposes, the readers need to be able to count on the validity 206 of its contents. It is therefore required that a mntner be specified in 207 the aut-num and in most other database objects, which means you must create 208 a mntner object before you can register your peering policies. For brief 209 information on the ``mntner'' object and object writeability, see Appendix A 210 of this document. For more extensive information on how to set up and use a 211 mntner to protect your database objects, see Section 2.3 of RIPE-157. 213 2.2 ISP Customer - Transit Provider Policies 215 It is not uncommon for an ISP to acquire connectivity from a transit 216 provider which announces all routes to it, which it in turn passes on to its 217 customers to allow them to access hosts on the global Internet. Meanwhile, 218 the ISP will generally announce the routes of its customers networks to the 219 transit ISP, making them accessible on the global Internet. This is the 220 service that is specified in Figure 2 for AS3. 222 Consider again Figure 3. Suppose now that AS2 wants to provide the same 223 service to AS4. Clearly, it would be easy to modify the import and export 224 lines in the aut-num object for AS2 (Figure 2) to those shown in Figure 4. 226 import: from AS1 accept ANY 227 import: from AS3 accept <^AS3$> 228 import: from AS4 accept <^AS4$> 229 export: to AS3 announce ANY 230 export: to AS4 announce ANY 231 export: to AS1 announce AS2 AS3 AS4 233 Figure 4: Policy for AS3 and AS4 in the AS2 as-num object 235 These changes are trivial to make of course, but clearly as the number of 236 AS2 customers grows, it becomes more difficult to keep track of, and to 237 prevent errors. Note also that if AS1 is selective about only accepting 238 routes from the customers of AS2 from AS2, the aut-num object for AS1 would 239 have to be adjusted to accomadate AS2's new customer. 241 By using the RPSL ``as-set'' object, we can simplify this significantly. In 242 Figure 5, we describe the customers of AS2. Having this set to work with, 243 we can now rewrite the policies in Figure 2 as shown in Figure 6. 245 as-set: AS2:AS-CUSTOMERS 246 members: AS3 AS4 247 ... 248 changed: orange@ripe.net 249 source: RIPE 251 Figure 5: The as-set object 253 import: from AS1 accept ANY 254 import: from AS2:AS-CUSTOMERS accept <^AS2:AS-CUSTOMERS$> 255 export: to AS2:AS-CUSTOMERS announce ANY 256 export: to AS1 announce AS2 AS2:AS-CUSTOMERS 258 Figure 6: Policy in the AS2 aut-num object for all AS2 customers 260 Note that if the aut-num object for AS1 contains the line: 262 import: from AS2 accept <^AS2+ AS2:AS-CUSTOMERS*$> 264 then no changes will need to be made to the aut-num objects for AS1 or 265 AS2 as the AS2 customer base grows. The AS numbers for new customers can 266 simply be added to the as-set AS2:AS-CUSTOMERS, and everything will work as 267 for the existing customers. Clearly in terms of readability, scalability 268 and maintainability, this is a far better mechanism when compared to adding 269 policy for the customer AS's to the aut-num objects directly. The policy 270 in this particular example states that AS1 will accept route announcements 271 from AS2 in which the first element of the path is AS2, followed by more 272 occurrences of AS2, and then 0 or more occurrences of any AS2 customer (e.g. 273 any member of the as-set AS2:AS-CUSTOMERS). 275 Alternatively, one may wish to limit the routes one accepts from a peer, 276 especially if the peer is a customer. This is recommended for several 277 reasons, such as preventing the improper use of unassigned address space, 278 and of course malicious use of another organization's address space. 280 Such filtering can be expressed in various ways in RPSL. Suppose the address 281 space 7.7.0.0/16 has been allocated to the ISP managing AS3 for assignment 282 to its customers. AS3 may want to announce part or all of this block on 283 the global Internet. Suppose AS2 wants to be certain that it only accepts 284 announcements from AS3 for address space that has been properly allocated to 285 AS3. AS2 might then modify the AS3 import line in Figure 2 to read: 287 import: from AS3 accept { 7.7.0.0/16^16-19 } 289 which states that route announcements for this address block will be 290 accepted from AS3 if they are of length upto /19. This of course will have 291 to be modified if and when AS3 gets more address space. Moreover, it is 292 again clear that for an ISP with a growing or changing customer base, this 293 mechanism will not scale well. 295 route-set: AS2:RS-ROUTES:AS3 296 members: 7.7.0.0/16^16-19 297 ... 298 changed: orange@ripe.net 299 source: RIPE 301 Figure 7: The route-set object 303 Luckily RPSL supports the notion of a ``route-set'' which, as shown in 304 Figure 7, can be used to specify the set of routes that will be accepted 305 from a given customer. Given this set (and a similar one for AS4), the 306 manager of AS2 can now filter on the address space that will be accepted 307 from their customers by modifying the import lines in the AS2 aut-num object 308 as shown in Figure 8. 310 import: from AS1 accept ANY 311 import: from AS3 accept AS2:RS-ROUTES:AS3 312 import: from AS4 accept AS2:RS-ROUTES:AS4 313 export: to AS2:AS-CUSTOMERS announce ANY 314 export: to AS1 announce AS2 AS2:AS-CUSTOMERS 316 Figure 8: Policy in the AS2 aut-num object for address based filtering on 317 AS2 customers 319 Note that this is now only slightly more complex than the example in 320 Figure 6. Furthermore, nothing need be changed in the AS2 aut-num object 321 due to address space changes for a customer, and this filtering can be 322 supported without any changes to the AS1 aut-num object. The additional 323 complexity is due to the two route set names being different, otherwise we 324 could have combined the two import statements into one. Please note that 325 the set names are constructed hierarchically. The first AS number denotes 326 whose sets these are, and the last AS number parameterize these sets for 327 each peer. RPSL allows the peer's AS number to be replaced by the keyword 328 PeerAS. Hence, 330 import: from AS3 accept AS2:RS-ROUTES:PeerAS 331 import: from AS4 accept AS2:RS-ROUTES:PeerAS 333 has the same meaning as the corresponding import statements in Figure 6. 334 This lets us combine the two import statements into one as shown in 335 Figure 9. 337 import: from AS1 accept ANY 338 import: from AS2:AS-CUSTOMERS accept AS2:RS-ROUTES:PeerAS 339 export: to AS2:AS-CUSTOMERS announce ANY 340 export: to AS1 announce AS2 AS2:AS-CUSTOMERS 342 Figure 9: Policy in the AS2 aut-num object using PeerAS 344 2.3 Including Interfaces in Peering Definitions 346 In the above examples peerings were only given among ASes. However, the 347 peerings may be described in much more detail by RPSL, where peerings can 348 +--------------------+ +--------------------+ 349 | 7.7.7.1 |-----+ +-----| 7.7.7.2 | 350 | | | | | | 351 | AS1 | ======== | AS2 | 352 | | IX | | | 353 | | +-----| 7.7.7.3 | 354 +--------------------+ +--------------------+ 356 Figure 10: Including interfaces in peerings definitions 358 be specified between physical routers using IP addresses in the import and 359 export attributes. Figure 10 shows a simple example in which AS1 and AS2 360 are connected to an exchange point IX. While AS1 has only one connection to 361 the exchange point via a router interface with IP address 7.7.7.1, AS2 has 362 two different connections with IP address 7.7.7.2 and 7.7.7.3. The first AS 363 may then define its routing policy in more detail by specifying its boundary 364 router. 366 aut-num: AS1 367 import: from AS2 at 7.7.7.1 accept <^AS2$> 368 ... 370 Because AS1 has only one connection to the exchange point in this example, 371 this specification does not differ from that in which no boundary router 372 is specified. However, AS1 might want to choose to accept only those 373 announcements from AS2 which come from the router with IP address 7.7.7.2 374 and disregard those announcements from router 7.7.7.3. AS1 can specify this 375 routing policy as follows: 377 aut-num: AS1 378 import: from AS2 7.7.7.2 at 7.7.7.1 accept <^AS2$> 379 ... 381 By selecting certain pairs of routers in a peering specification, others can 382 be denied. If no routers are included in a policy clause then it is assumed 383 that the policy applies to all peerings among the ASes involved. 385 2.4 Describing Simple Backup Connections 387 The specification of peerings among ASes is not limited to one router for 388 each AS. In figure 10 one of the two connections of AS2 to the exchange 389 point IX might be used as backup in case the other connection fails. Let us 390 assume that AS1 wants to use the connection to router 7.7.7.2 of AS2 during 391 regular operations, and router 7.7.7.3 as backup. In a router configuration 392 this may be done by setting a local preference. The equivalent in RPSL is 393 a corresponding action definition in the peering description. The action 394 definitions are inserted directly before the accept keyword. 396 aut-num: AS1 397 import: from AS2 7.7.7.2 at 7.7.7.1 action pref=10; 398 from AS2 7.7.7.3 at 7.7.7.1 action pref=20; 399 accept <^AS2$> 400 ... 402 pref is different than local-pref in that the smaller values are preferred 403 over larger values. Actions may also be defined without specifying IP 404 addresses of routers. If no routers are included in the policy clause then 405 it is asumed that the actions are carried out for all peerings among the 406 ASes involved. 408 In the previous example AS1 controls where it sends its traffic and which 409 connection is used as backup. However, AS2 may also define a backup 410 connection in an export clause: 412 aut-num: AS2 413 export: to AS1 7.7.7.1 at 7.7.7.2 action med=10; 414 to AS1 7.7.7.1 at 7.7.7.3 action med=20; 415 announce <^AS2$> 417 The definition given here for AS2 is the symmetric counterpart to the 418 routing policy of AS1. The selection of routing information is done by 419 setting the multi exit discriminator metric med. Actually, med metrics will 420 not be used in practice like this; they are more suitable for load balancing 421 including backups. For more details on med metrics refer to the BGP-4 422 RFC [7]. To use the med to achieve load balancing, one often sets it to the 423 ``IGP metric''. This is specified in RPSL as: 425 aut-num: AS2 426 export: to AS1 action med=igp_cost; announce <^AS2$> 428 Hence, both routers will set the med to the IGP metric at that router, 429 causing some routes to be preferred at one of the routers and other routes 430 at the other router. 432 2.5 Multi-Home Routing Policies using the community Attribute 434 RFC 1998 [9] describes the use of the BGP community attribute to handle the 435 load balancing and backup connection of multi-homed autonomous systems. In 436 this section, we simply illustrate how those policies are specified in RPSL. 438 AS3561 bases its route selection preference on the community attribute. 439 Other ASes may indirectly affect AS3561's route selection by including the 440 appropriate communities in their route announcements. In our example, AS1 441 is connected to AS2 and AS3 which are both connected to AS3561. AS1 wants 442 AS3561 to prefer the AS2 connection over the AS3 connection. 444 AS3561 prefers the routes with no community attribute followed by the routes 445 with community 3561:90, followed by the routes with community 3561:80, and 446 followed by the routes with community 3561:70. AS1 achieves its policy 447 by adding the community 3561:90 to the routes it exports to AS2, and the 448 community 3561:80 to the routes it exports to AS1. Hence, AS3561 will 449 assign a lower preference value to the routes it receives from AS2 (note 450 that, in RPSL smaller integers represents higher preferences). This is 451 illustrated in Figure 11. 453 as-set: AS3561:AS-PEERS 454 members: AS2, AS3, . . . 456 aut-num: AS3561 457 import: from AS3561:AS-PEERS action pref=30; accept community(3561:70) 458 import: from AS3561:AS-PEERS action pref=20; accept community(3561:80) 459 import: from AS3561:AS-PEERS action pref=10; accept community(3561:90) 460 import: from AS3561:AS-PEERS action pref=0; accept ANY 462 aut-num: AS1 463 export: to AS2 action community.={3561,90}; 464 to AS3 action community.={3561,80}; 465 announce AS1 467 Figure 11: Policy example using the community rp-attribute. 469 3 Tools 471 In this section, we briefly introduce a number of tools which can be used 472 to inspect data in the database, to determine optimal routing policies, and 473 enter new data. 475 3.1 The aut-num Object Editor 477 All the examples shown in the previous sections may well be edited by hand. 478 They may be extracted one by one from the IRR using the whois program, 479 edited, and then handed back to the registry robots. However, again the 480 RAToolSet [6] provides a very nice tool which makes working with aut-num 481 objects much easier: the aut-num object editor aoe (please see Figure 12). 483 Figure 12: Autonomous System object editor (aoe). 485 The aut-num object editor has a graphical user interface to view and 486 manipulate aut-num objects registered at any IRR. New aut-num objects may be 487 generated using templates and submitted to the registries. Moreover, the 488 routing policy from the databases may be compared to real life peerings. 489 Therefore, aoe is highly recommended as an interface to the IRR for 490 aut-num objects. Further information on aoe is available together with the 491 RAToolSet [6]. 493 3.2 Router Configuration Using RtConfig 495 RtConfig is a tool developed by the Routing Arbiter project [8] to 496 generate vendor specific router configurations from the policy data held 497 in the various IRRs. RtConfig currently supports Cisco, gated and RSd 498 configuration formats. It has been publicly available since late 1994, 499 and is currently being used by many sites for router configuration. The 500 next section describes a methodology for generating vendor specific router 501 configurations using RtConfig.(2) 503 3.3 Using RtConfig 505 The general paradigm for using RtConfig involves registering policy in an 506 IRR, building a RtConfig source file, then running running RtConfig against 507 the source file and the IRR database to create vendor specific router 508 configuration for the specified policy. The source file will contain vendor 509 specific commands as well as RtConfig commands. To make a source file, pick 510 up one of your router configuration files and replace the vendor specific 511 policy configuration commands with the RtConfig commands. 513 Commands beginning with @RtConfig instruct RtConfig to perform special 514 operations. An example source file is shown in Figure 13. In this 515 example, commands such as ``@RtConfig import AS3582 198.32.162.1 AS3701 516 198.32.162.2'' instruct RtConfig to generate vendor specific import policies 517 where the router 198.32.162.1 in AS3582 is importing routes from router 518 198.32.162.2 in AS3701. The other @RtConfig commands instruct the RtConfig 519 to use certain names and numbers in the output that it generates (please 520 refer to RtConfig manual [8] for additional information). 522 Once a source file is created, the file is processed by RtConfig (the 523 default IRR is the RADB, and the default vendor is Cisco; however, command 524 line options can be used to override these values). The result of 525 running RtConfig on the source file in Figure 13 is shown in Figure 21 in 526 Appendix B. 528 A RPSL Database Objects 530 In this appendix, we introduce the RPSL objects required to implement many 531 typical Internet routing policies. RFC-2280 and RIPE-157 provide the 532 authoritative description for these objects and for the RPSL syntax, but 533 this appendix will often be sufficient in practice. 535 ------------------------------ 536 2. Discussion of RtConfig internals is beyond the scope of this document. 538 router bgp 3582 539 network 128.223.0.0 540 ! 541 ! Start with access-list 100 542 ! 543 @RtConfig set cisco_access_list_no = 100 544 ! 545 ! NERO 546 ! 547 neighbor 198.32.162.2 remote-as 3701 548 @RtConfig set cisco_map_name = "AS3701-EXPORT" 549 @RtConfig export AS3582 198.32.162.1 AS3701 198.32.162.2 550 @RtConfig set cisco_map_name = "AS3701-IMPORT" 551 @RtConfig import AS3582 198.32.162.1 AS3701 198.32.162.2 552 ! 553 ! WNA/VERIO 554 ! 555 neighbor 198.32.162.6 remote-as 2914 556 @RtConfig set cisco_map_name = "AS2914-EXPORT" 557 @RtConfig export AS3582 198.32.162.1 AS2914 198.32.162.6 558 @RtConfig set cisco_map_name = "AS2914-IMPORT" 559 @RtConfig import AS3582 198.32.162.1 AS2914 198.32.162.6 560 ... 562 Figure 13: RtConfig Template File 564 The frequently needed objects are: 566 o maintainer objects (mntner) 568 o autonomous system number objects (aut-num) 570 o route objects (route) 572 o set objects (as-set, route-set) 574 and they are described in the following sections. To make your routing 575 policies and configuration public, these objects should be registered in 576 exactly one of the IRR registries. 578 In general, you can register your information by sending the appropriate 579 objects to an email address for the registry you use. The email should 580 consist of the objects you want to have registered or modified, separated 581 by empty lines, and preceded by some kind of authentication details (see 582 below). The registry robot processes your mail and enters new objects 583 into the database, deletes old ones (upon request), or makes the requested 584 modifications. 586 You will receive a response indicating the status of your submission. As 587 the emails are handled automatically, the response is generally very fast. 588 However, it should be remembered that a significant number of updates are 589 also sometimes submitted to the database (by other robots), so the response 590 time cannot be guaranteed. The email addresses for submitting objects to 591 the existing registries are listed in Figure 14. 593 ANS auto-dbm@ans.net 594 CANET auto-dbm@canet.net 595 MCI auto-rr@mci.net 596 RADB auto-dbm@radb.ra.net 597 RIPE auto-dbm@ripe.net 599 Figure 14: Email addresses to register policy objects in IRR. 601 Because it is required that a maintainer be specified in many of the 602 database objects, a mntner is usually the first to be created. To have it 603 properly authenticated, a mntner object is added manually by registry staff. 604 Thereafter, all database submissions, deletions and modifications should be 605 done through the registry robot. 607 Each of the registries should can provide additional information and support 608 for users. For the public registries this support is available at: 609 RADB db-admin@radb.ra.net 610 RIPE ripe-dbm@ripe.net 612 If you are using one of the private registries, your service provider should 613 be able to address your questions. 615 A.1 The Maintainer Object 617 The maintainer object is used to introduce some kind of authorization 618 for registrations. It lists various contact persons and describes 619 security mechanisms that will be applied when updating objects in the 620 IRR. Registering a mntner object is the first step in creating policies 621 for an AS. An example is shown in Figure 15. The maintainer is called 622 MAINT-AS3701. The contact person here is the same for administrative 623 (admin-c) and technical (tech-c) issues and is referenced by the NIC-handle 624 DMM65. NIC-handles are unique identifiers for persons in registries. Refer 625 to registry documentation for further details on person objects and usage of 626 NIC-handles. 628 The example shows two authentication mechanisms: CRYPT-PW and MAIL-FROM. 629 CRYPT-PW takes as its argument a password that is encrypted with Unix 630 crypt(3) routine. When sending updates, the maintainer adds the field 631 password: to the beginning of any requests that are to 632 be authenticated. MAIL-FROM takes an argument that is a regular expression 633 which covers a set of mail addresses. Only users with any of these mail 634 addresses are authorized to work with objects secured by the corresponding 635 maintainer(3). 637 The security mechanisms of the mntner object will only be applied on those 638 objects referencing a specific mntner object. The reference is done by 639 adding the attribute mnt-by to an object using the name of the mntner object 640 as its value. In Figure 15, the maintainer MAINT-AS3701 is maintained by 641 itself. 643 mntner: MAINT-AS3701 644 descr: Network for Research and Engineering in Oregon 645 remark: Internal Backbone 646 admin-c: DMM65 647 tech-c: DMM65 648 upd-to: noc@nero.net 649 auth: CRYPT-PW 949WK1mirBy6c 650 auth: MAIL-FROM .*@nero.net 651 notify: noc@nero.net 652 mnt-by: MAINT-AS3701 653 changed: meyer@antc.uoregon.edu 970318 654 source: RADB 656 Figure 15: Maintainer Object 658 A.2 The Autonomous System Object 660 The autonomous system object describes the import and export policies of an 661 AS. Each organization registers an autonomous system object (aut-num) in the 662 IRR for its AS. Figure 16 shows the aut-num for AS3582 (UONET). 664 The autonomous system object lists contacts (admin-c, tech-c) and is 665 maintained by (mnt-by) MAINT-AS3701 which is the maintainer displayed in 666 Figure 15. 668 The most important attributes of the aut-num object are import and export. 669 The import clause of an aut-num specifies import policies, while the export 671 ------------------------------ 672 3. Clearly, neither of these mechanisms is sufficient to provide 673 strong authentication or authorization. Other public key (e.g., PGP) 674 authentication mechanisms are available from some of the IRRs. 676 clause specifies export policies. The corresponding clauses allow a very 677 detailed description of the routing policy of the AS specified. The details 678 are given in section 2. 680 With these clauses, an aut-num object shows its relationship to other 681 autonomous systems by describing its peerings. In addition, it also defines 682 a routing entity comprising a group of IP networks which are handled 683 according to the rules defined in the aut-num object. Therefore, it is 684 closely linked to route objects. 686 In this example, AS3582 imports all routes from AS3701 by using the keyword 687 ANY. AS3582 imports only internal routes from AS4222, AS5650, and AS1798. 688 The import policy for for AS2914 is slightly more complex. Since AS2914 689 provides transit to various other ASes, AS3582 accepts routes with ASPATHs 690 that begin with AS2194 followed by members of AS-WNA, which is an as set 691 (see section A.4.1 below) describing those customers that transit AS2914. 693 Since AS3582 is a multi-homed stub AS (i.e., it does not provide transit), 694 its export policy consists simply of ``announce AS3582'' clauses; that is, 695 announce internal routes of AS3582. These routes are those in route objects 696 where the origin attribute is AS3582. 698 aut-num: AS3582 699 as-name: UONET 700 descr: University of Oregon, Eugene OR 701 import: from AS3701 accept ANY 702 import: from AS4222 accept <^AS4222$> 703 import: from AS5650 accept <^AS5650$> 704 import: from AS2914 accept <^AS2914+ (AS-WNA)*$> 705 import: from AS1798 accept <^AS1798$> 706 export: to AS3701 announce AS3582 707 export: to AS4222 announce AS3582 708 export: to AS5650 announce AS3582 709 export: to AS2914 announce AS3582 710 export: to AS1798 announce AS3582 711 admin-c: DMM65 712 tech-c: DMM65 713 notify: nethelp@ns.uoregon.edu 714 mnt-by: MAINT-AS3582 715 changed: meyer@antc.uoregon.edu 970316 716 source: RADB 718 Figure 16: Autonomous System Object 720 The aut-num object forms the basis of a scalable and maintainable router 721 configuration system. For example, if AS3582 originates a new route, it 722 need only create a route object for that route with origin AS3582. AS3582 723 route: 128.223.0.0/16 724 origin: AS3582 725 descr: UONet 726 descr: University of Oregon 727 descr: Computing Center 728 descr: Eugene, OR 97403-1212 729 descr: USA 730 mnt-by: MAINT-AS3582 731 changed: meyer@ns.uoregon.edu 960222 732 source: RADB 734 Figure 17: Example of a route object 736 can now build configuration using this route object without changing its 737 aut-num object. 739 Similarly, if for example, AS3701 originates a new route, it need only 740 create a route object for that route with origin AS3701. Both AS3701 and 741 AS3582 can now build configuration using this route object without modifying 742 its aut-num object. 744 A.3 The Route Object 746 In contrast to aut-num objects which describe propagation of routing 747 information for an autonomous system as a whole, route objects define single 748 routes from an AS. An example is given in Figure 17. 750 This route object is maintained by MAINT-AS3582 and references AS3582 by 751 the origin attribute. By this reference it is grouped together with other 752 routes of the same origin AS, becoming member of the routing entity denoted 753 by AS3582. The routing policies can then be defined in the aut-num objects 754 for this group of routes. 756 Consequently, the route objects give the routes from this AS which are 757 distributed to peer ASes according to the rules of the routing policy. 758 Therefore, for any route in the routing tables of the backbone routers a 759 route object must exist in one of the registries in IRR. route objects must 760 be registered in the IRR only for the routes seen outside your AS. Normally, 761 this set of external routes is different from the routes internally visible 762 within your AS. One of the major reasons is that external peers need no 763 information at all about your internal routing specifics. Therefore, 764 external routes are in general aggregated combinations of internal routes, 765 having shorter IP prefixes where applicable according to the CIDR rules. 766 Please see the CIDR FAQ [5] for a tutorial introduction to CIDR. It is 767 strongly recommended that you aggregate your routes as much as possible, 768 thereby minimizing the number of routes you inject into the global routing 769 table and at the same time reducing the corresponding number of route 770 objects in the IRR. 772 While you may easily query single route objects using the whois program, and 773 submit objects via mail to the registry robots, this becomes kind of awkward 774 for larger sets. The RAToolSet [6] offers several tools to make handling of 775 route objects easier. If you want to read policy data from the IRR and 776 process it by other programs, you might be interested in using peval which 777 is a low level policy evaluation tool. As an example, the command 779 peval -h radb.ra.net AS3582 781 will give you all route objects from AS3582 registered with RADB. 783 A much more sophisticated tool from the RAToolSet to handle route objects 784 interactively is the route object editor roe (please see Figure 18). It has 785 a graphical user interface to view and manipulate route objects registered 786 at any IRR. New route objects may be generated from templates and submitted 787 to the registries. Moreover, the route objects from the databases may be 788 compared to real life routes. Therefore, roe is highly recommended as an 789 interface to the IRR for route objects. Further information on peval and 790 roe is available together with the RAToolSet [6]. 792 A.4 Set Objects 794 With routing policies it is often necessary to reference groups of 795 autonomous systems or routes which have identical properties regarding a 796 specific policy. To make working with such groups easier RPSL allows to 797 combine them in set objects. There are two basic types of predefined set 798 objects, as-set, and route-set. The RPSL set objects are described below. 800 A.4.1 AS-SET Object 802 Autonomous system set objects (as-set) are used to group autonomous system 803 objects into named sets. An as-set has an RPSL name that starts with 804 ``AS-''. In the example in Figure 19, an as-set called AS-NERO-PARTNERS and 805 containing AS3701, AS4201, AS3582, AS4222, AS1798 is defined. The as-set 806 is the RPSL replacement for the RIPE-181 as-macro. It has been extended 807 to include ASes in the set indirectly by referencing as set names in the 808 aut-num objects. 810 AS-SETs are particularly useful when specifying policies for groups such 811 as customers, providers, or for transit. You are encouraged to register 812 sets for these groups because it is most likely that you will treat them 813 alike, i.e. you will have a very similar routing policy for all your 814 Figure 18: route object editor (roe). 816 customers which have an autonomous system of their own. You may as well 817 discover that this is also true for the providers you are peering with, 818 and it is most convenient to have the ASes combined in one as-set for 819 which you offer transit. For example, if a transit provider specifies its 820 import policy using its customer's as-set (i.e., its import clause for the 821 customer contains the customer's as-set), then that customer can modify the 822 set of ASes that its transit provider accepts from it. Again, this can 823 be accomplished without requiring the customer or the transit provider to 824 modify its aut-num object. 826 as-set: AS3582:AS-PARTNERS 827 members: AS3701, AS4201, AS3582, AS4222, AS1798 829 Figure 19: as-set Object 831 The ASes of the set are simply compiled in a comma delimited list following 832 the members attribute of the as-set. This list may also contain other 833 AS-SET names. 835 A.4.2 ROUTE-SET Object 837 A route-set is a way to name a group of routes. The syntax is similar to 838 the as-set. A route-set has an RPSL name that starts with ``RS-''. The 839 members attribute lists the members of the set. The value of a members 840 attribute is a list of address prefixes, or route-set names. The members 841 of the route-set are the address prefixes or the names of other route sets 842 specified. 844 Figure 20 presents some example route-set objects. The set rs-uo contains 845 two address prefixes, namely 128.223.0.0/16 and 198.32.162.0/24. The 846 set rs-bar contains the members of the set rs-uo and the address prefix 847 128.7.0.0/16. The set rs-martians illustrate the use of range operators. 848 0.0.0.0/0^32 are the length 32 more specifics of 0.0.0.0/0, i.e. the host 849 routes; 224.0.0.0/3^+ are the more specifics of 224.0.0.0/3, i.e. the routes 850 falling into the multicast address space. For more complete list of range 851 operators please refer to RFC-2280. 853 route-set: rs-uo 854 members: 128.223.0.0/16, 198.32.162.0/24 856 route-set: rs-bar 857 members: 128.7.0.0/16, rs-uo 859 route-set: rs-martians 860 remarks: routes not accepted from any peer 861 members: 0.0.0.0/0, # default route 862 0.0.0.0/0^32, # host routes 863 224.0.0.0/3^+, # multicast routes 864 127.0.0.0/8^9-32, . . . 866 Figure 20: route-set Objects 868 B Output of RtConfig: An Example 870 In Figure 21, you see the result of running RtConfig on the source file in 871 Figure 13. 873 References 875 [1] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. 876 Terpstra, and C. Villamizer: Routing Policy Specification Language 877 (RPSL), RFC 2280. 879 [2] T. Bates, J-M. Jouanigot, D. Karrenberg, P. Lothberg, and M. Terpstra. 880 Representation of IP Routing Policies in the RIPE database, Technical 881 Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993. 883 [3] T. Bates, E. Gerich, J. Joncharay, J-M. Jouanigot, D. Karrenberg, 884 M. Terpstra, and J. Yu. Representation of IP Routing Policies in 885 a Routing Registry, Technical Report ripe-181, RIPE, RIPE NCC, 886 Amsterdam, Netherlands, October 1994. 888 [4] A. M. R. Magee. RIPE NCC Database Documentation. Technical Report 889 RIPE-157, RIPE NCC, Amsterdam, Netherlands, May 1997. 891 [5] Hank Nussbacher. The CIDR FAQ. Tel Aviv University and IBM Israel. 892 http://www.ibm.net.il/~hank/cidr.html 894 [6] The RAToolSet. http://www.ra.net/ra/RAToolSet/ 896 [7] Y. Rekhter adn T. Li. A Border Gateway Protocol 4 (BGP-4). Request for 897 Comment RFC 1654. Network Information Center, July 1994. 899 [8] RtConfig as part of the RAToolSet. 900 http://www.ra.net/ra/RAToolSet/RtConfig.html 902 [9] E. Chen, T. Bates. An Application of the BGP Community Attribute in 903 Multi-Home Routing. RFC 1998. 905 router bgp 3582 906 network 128.223.0.0 907 ! 908 ! NERO 909 ! 910 neighbor 198.32.162.2 remote-as 3701 912 no access-list 100 913 access-list 100 permit ip 128.223.0.0 0.0.0.0 255.255.0.0 0.0.0.0 914 access-list 100 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 915 ! 916 ! 917 no route-map AS3701-EXPORT 918 route-map AS3701-EXPORT permit 1 919 match ip address 100 920 ! 921 router bgp 3582 922 neighbor 198.32.162.2 route-map AS3701-EXPORT out 923 ! 924 ! 925 no route-map AS3701-IMPORT 926 route-map AS3701-IMPORT permit 1 927 set local-preference 1000 928 ! 929 router bgp 3582 930 neighbor 198.32.162.2 route-map AS3701-IMPORT in 931 ! 932 ! WNA/VERIO 933 ! 934 neighbor 198.32.162.6 remote-as 2914 935 ! 936 no route-map AS2914-EXPORT 937 route-map AS2914-EXPORT permit 1 938 match ip address 100 939 ! 940 router bgp 3582 941 neighbor 198.32.162.6 route-map AS2914-EXPORT out 942 no ip as-path access-list 100 943 ip as-path access-list 100 permit ^_2914(((_[0-9]+))*_ \ 944 (13|22|97|132|175|668|1914|2905|2914|3361|3381|3791|3937| \ 945 4178|4354|4571|4674|4683|5091|5303|5798|5855|5856|5881|6083 \ 946 |6188|6971|7790|7951|8028))?$ 947 ! 948 no route-map AS2914-IMPORT 949 route-map AS2914-IMPORT permit 1 950 match as-path 100 951 set local-preference 998 952 ! 953 router bgp 3582 954 neighbor 198.32.162.6 route-map AS2914-IMPORT in 955 ! 957 Figure 21: Output of RtConfig