idnits 2.17.1 draft-ietf-rps-appl-rpsl-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) 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. == There is 1 instance of lines with non-ascii characters in the document. == 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 296 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 402 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 35 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 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...' == (291 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 1998) is 9416 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 (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft David Meyer 3 Expires January 14, 1999 Cisco Systems 4 draft-ietf-rps-appl-rpsl-02.txt Joachim Schmitz 5 DFN-NOC 6 Carol Orange 7 RIPE NCC 8 Cengiz Alaettinoglu 9 USC/ISI 10 July 14, 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-02.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 your 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 3 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 3 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 15). 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 which references a ``mntner'' object. Because the aut-num object may be 204 used for router configuration and other operational purposes, the readers 205 need to be able to count on the validity of its contents. It is therefore 206 required that a mntner be specified in the aut-num and in most other 207 database objects, which means you must create a mntner object before you can 208 register your peering policies. For brief information on the ``mntner'' 209 object and object writeability, see Appendix A of this document. For more 210 extensive information on how to set up and use a mntner to protect your 211 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 at least /19. This of course will 291 have to be modified if and when AS3 gets more address space. Moreover, it 292 is again clear that for an ISP with a growing or changing customer base, 293 this mechanism will not scale well. 295 route-set: AS2:AS3-ROUTES 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:AS3-ROUTES 312 import: from AS4 accept AS2:AS4-ROUTES 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 +--------------------+ +--------------------+ 320 | 7.7.7.1 |-----+ +-----| 7.7.7.2 | 321 | | | | | | 322 | AS1 | ======== | AS2 | 323 | | IX | | | 324 | | +-----| 7.7.7.3 | 325 +--------------------+ +--------------------+ 327 Figure 9: Including interfaces in peerings definitions 329 Note that this is now only slightly more complex than the example in 330 Figure 6. Furthermore, nothing need be changed in the AS2 aut-num object 331 due to address space changes for a customer, and this filtering can be 332 supported without any changes to the AS1 aut-num object. 334 2.3 Including Interfaces in Peering Definitions 336 In the above examples peerings were only given among ASes. However, the 337 peerings may be described in much more detail by RPSL, where peerings can 338 be specified between physical routers using IP addresses in the import and 339 export attributes. Figure 9 shows a simple example in which AS1 and AS2 are 340 connected to an exchange point IX. While AS1 has only one connection to the 341 exchange point via a router interface with IP address 7.7.7.1, AS2 has two 342 different connections with IP address 7.7.7.2 and 7.7.7.3. The first AS 343 may then define its routing policy in more detail by specifying its boundary 344 router. 346 aut-num: AS1 347 import: from AS2 at 7.7.7.1 accept <^AS2$> 348 ... 350 Because AS1 has only one connection to the exchange point in this example, 351 this specification does not differ from that in which no boundary router 352 is specified. However, AS1 might want to choose to accept only those 353 announcements from AS2 which come from the router with IP address 7.7.7.2 354 and disregard those announcements from router 7.7.7.3. AS1 can specify this 355 routing policy as follows: 357 aut-num: AS1 358 import: from AS2 7.7.7.2 at 7.7.7.1 accept <^AS2$> 359 ... 361 By selecting certain pairs of routers in a peering specification, others can 362 be denied. If no routers are included in a policy clause then it is assumed 363 that the policy applies to all peerings among the ASes involved. 365 2.4 Describing Simple Backup Connections 367 The specification of peerings among ASes is not limited to one router for 368 each AS. In figure 9 one of the two connections of AS2 to the exchange point 369 IX might be used as backup in case the other connection fails. Let us 370 assume that AS1 wants to use the connection to router 7.7.7.2 of AS2 during 371 regular operations, and router 7.7.7.3 as backup. In a router configuration 372 this may be done by setting a local preference. The equivalent in RPSL is 373 a corresponding action definition in the peering description. The action 374 definitions are inserted directly before the accept keyword. 376 aut-num: AS1 377 import: from AS2 7.7.7.2 at 7.7.7.1 action pref=10; 378 from AS2 7.7.7.3 at 7.7.7.1 action pref=20; 379 accept <^AS2$> 380 ... 382 Actions may also be defined without specifying IP addresses of routers. If 383 no routers are included in the policy clause then it is asumed that the 384 actions are carried out for all peerings among the ASes involved. 386 In the previous example AS1 controls where it sends its traffic and which 387 connection is used as backup. However, AS2 may also define a backup 388 connection in an export clause: 390 aut-num: AS2 391 export: to AS1 7.7.7.1 at 7.7.7.2 action med=10; 392 to AS1 7.7.7.1 at 7.7.7.3 action med=20; 393 announce <^AS2$> 395 The definition given here for AS2 is the symmetric counterpart to the 396 routing policy of AS1. The selection of routing information is done by 397 setting the multi exit discriminator metric med. Actually, med metrics will 398 not be used in practice like this; they are more suitable for load balancing 399 including backups. For more details on med metrics refer to the BGP-4 400 RFC [7]. To use the med to achieve load balancing, one often sets it to the 401 ``IGP metric''. This is specified in RPSL as: 403 aut-num: AS2 404 export: to AS1 action med=igp; 405 announce <^AS2$> 407 Hence, both routers will set the med to the IGP metric at that router, 408 causing some routes to be preferred at one of the routers and other routes 409 at the other router. 411 2.5 Multi-Home Routing Policies using the community Attribute 413 RFC 1998 [9] describes the use of the BGP community attribute to handle the 414 load balancing and backup connection of multi-homed autonomous systems. In 415 this section, we simply illustrate how those policies are specified in RPSL. 417 AS3561 bases its route selection preference on the community attribute. 418 Other ASes may indirectly affect AS3561's route selection by including the 419 appropriate communities in their route announcements. In our example, AS1 420 is connected to AS2 and AS3 which are both connected to AS3561. AS1 wants 421 AS3561 to prefer the AS2 connection over the AS3 connection. 423 AS3561 prefers the routes with no community attribute followed by the routes 424 with community {3561,90}, followed by the routes with community {3561,80}, 425 and followed by the routes with community {3561,70}. AS1 achieves its 426 policy by adding the community {3561,90} to the routes it exports to AS2, 427 and the community {3561,80} to the routes it exports to AS1. Hence, AS3561 428 will assign a lower preference value to the routes it receives from AS2 429 (note that, in RPSL smaller integers represents higher preferences). This 430 is illustrated in Figure 10. 432 3 Tools 434 In this section, we briefly introduce a number of tools which can be used 435 to inspect data in the database, to determine optimal routing policies, and 436 enter new data. 438 as-set: AS3561:AS-PEERS 439 members: AS2, AS3, . . . 441 aut-num: AS3561 442 import: from AS3561:AS-PEERS 443 action pref = 30; 444 accept community.contains({3561,70}) 445 import: from AS3561:AS-PEERS 446 action pref = 20; 447 accept community.contains({3561,80}) 448 import: from AS3561:AS-PEERS 449 action pref = 10; 450 accept community.contains({3561,90}) 451 import: from AS3561:AS-PEERS 452 action pref = 0; 453 accept ANY 455 aut-num: AS1 456 export: to AS2 action community.={3561,90}; 457 to AS3 action community.={3561,80}; 458 announce AS1 460 Figure 10: Policy example using the community rp-attribute. 462 3.1 The aut-num Object Editor 464 All the examples shown in the previous sections may well be edited by hand. 465 They may be extracted one by one from the IRR using the whois program, 466 edited, and then handed back to the registry robots. However, again the 467 RAToolSet [6] provides a very nice tool which makes working with aut-num 468 objects much easier: the aut-num object editor aoe (please see Figure 11). 470 The aut-num object editor has a graphical user interface to view and 471 manipulate aut-num objects registered at any IRR. New aut-num objects may be 472 generated using templates and submitted ot the registries. Moreover, the 473 routing policy from the databases may be compared to real life peerings. 474 Therefore, aoe is highly recommended as an interface to the IRR for 475 aut-num objects. Further information on aoe is available together with the 476 RAToolSet [6]. 478 3.2 Router Configuration Using RtConfig 480 RtConfig is a tool developed by the Routing Arbiter project [8] to 481 generate vendor specific router configurations from the policy data held 482 in the various IRRs. RtConfig currently supports Cisco, gated and RSd 483 Figure 11: Autonomous System object editor (aoe). 485 configuration formats. RtConfig written in C++, C, lex, and yacc. It 486 has been publicly available since late 1994, and is currently being used 487 by several sites for router configuration. A few of the sites currently 488 using RtConfig include the Routing Arbiter Project (USA), ANS (USA), CA*Net 489 (Canada), IMNet (Japan), VERIO (USA), Oregon-IX (USA), IAfrica (South 490 Africa), Connect (Australia). The next section describes a methodology for 491 generating vendor specific router configurations using RtConfig.(2) 493 3.3 Using RtConfig 495 The general paradigm for using RtConfig involves registering policy in an 496 IRR, building a RtConfig source file, then running running RtConfig against 497 the source file and the IRR database to create vendor specific router 498 ------------------------------ 499 2. Discussion of RtConfig internals is beyond the scope of this document. 501 configuration for the specified policy. The source file will contain vendor 502 specific commands as well as RtConfig commands. To make a source file, pick 503 up one of your router configuration files and replace the vendor specific 504 policy configuration commands with the RtConfig commands. 506 Commands beginning with @RtConfig instruct RtConfig to perform special 507 operations. An example source file is shown in Figure 12. In this 508 example, commands such as ``@RtConfig import AS3582 198.32.162.1/32 AS3701 509 198.32.162.2/32'' instruct RtConfig to generate vendor specific import 510 policies where the router 198.32.162.1 in AS3582 is importing routes from 511 router 198.32.162.2 in AS3701. The other @RtConfig commands instruct the 512 RtConfig to use certain names and numbers in the output that it generates 513 (please refer to RtConfig manual [8] for additional information). 515 router bgp 3582 516 network 128.223.0.0 517 ! 518 ! Start with access-list 100 519 ! 520 @RtConfig set cisco_access_list_no = 100 521 ! 522 ! NERO 523 ! 524 neighbor 198.32.162.2 remote-as 3701 525 @RtConfig set cisco_map_name = "AS3701-EXPORT" 526 @RtConfig export AS3582 198.32.162.1/32 AS3701 198.32.162.2/32 527 @RtConfig set cisco_map_name = "AS3701-IMPORT" 528 @RtConfig import AS3582 198.32.162.1/32 AS3701 198.32.162.2/32 529 ! 530 ! WNA/VERIO 531 ! 532 neighbor 198.32.162.6 remote-as 2914 533 @RtConfig set cisco_map_name = "AS2914-EXPORT" 534 @RtConfig export AS3582 198.32.162.1/32 AS2914 198.32.162.6/32 535 @RtConfig set cisco_map_name = "AS2914-IMPORT" 536 @RtConfig import AS3582 198.32.162.1/32 AS2914 198.32.162.6/32 537 ... 539 Figure 12: RtConfig Template File 541 Once a source file is created, the file is processed by RtConfig (the 542 default IRR is the RADB, and the default vendor is Cisco; however, RtConfig 543 or command line options can be used to override these values). The result 544 of running RtConfig on the source file in Figure 12 is shown in Figure 20 in 545 Appendix B. 547 A RPSL Database Objects 549 In this appendix, we introduce the RPSL objects required to implement many 550 typical Internet routing policies. RFC-2280 and RIPE-157 provide the 551 authoritative description for these objects and for the RPSL syntax, but 552 this appendix will often be sufficient in practice. 554 The frequently needed objects are: 556 o maintainer objects (mntner) 558 o autonomous system number objects (aut-num) 560 o route objects (route) 562 o set objects (as-set, route-set) 564 and they are described in the following sections. To make your routing 565 policies and configuration public, these objects should be registered in 566 exactly one of the IRR registries. 568 In general, you can register your information by sending the appropriate 569 objects to an email address for the registry you use. The email should 570 consist of the objects you want to have registered or modified, separated 571 by empty lines, and preceded by some kind of authentication details (see 572 below). The registry robot processes your mail and enters new objects 573 into the database, deletes old ones (upon request), or makes the requested 574 modifications. 576 You will receive a response indicating the status of your submission. As 577 the emails are handled automatically, the response is generally very fast. 578 However, it should be remembered that a significant number of updates are 579 also sometimes submitted to the database (by other robots), so the response 580 time cannot be guaranteed. The email addresses for submitting objects to 581 the existing registries are listed in Figure 13. 583 ANS auto-dbm@ans.net 584 CANET auto-dbm@canet.net 585 MCI auto-rr@mci.net 586 RADB auto-dbm@radb.ra.net 587 RIPE auto-dbm@ripe.net 589 Figure 13: Email addresses to register policy objects in IRR. 591 Because it is required that a maintainer be specified in many of the 592 database objects, a mntner is usually the first to be created. To have it 593 properly authenticated, a mntner object is added manually by registry staff. 594 Thereafter, all database submissions, deletions and modifications should be 595 done through the registry robot. 597 Each of the registries should can provide additional information and support 598 for users. For the public registries this support is available at: 599 RADB XXXXauto-dbm@radb.ra.net 600 RIPE ripe-dbm@ripe.net 602 If you are using one of the private registries, your service provider should 603 be able to address your questions. 605 A.1 The Maintainer Object 607 The maintainer object is used to introduce some kind of authorization 608 for registrations. It lists various contact persons and describes 609 security mechanisms that will be applied when updating objects in the 610 IRR. Registering a mntner object is the first step in creating policies 611 for an AS. An example is shown in Figure 14. The maintainer is called 612 MAINT-AS3701. The contact person here is the same for administrative 613 (admin-c) and technical (tech-c) issues and is referenced by the NIC-handle 614 DMM65. NIC-handles are unique identifiers for persons in registries. Refer 615 to registry documentation for further details on person objects and usage of 616 NIC-handles. 618 The example shows two authentication mechanisms: CRYPT-PW and MAIL-FROM. 619 CRYPT-PW takes as its argument a password that is encrypted with Unix 620 crypt(3) routine. When sending updates, the maintainer adds the field 621 password: to the beginning of any requests that are to 622 be authenticated. MAIL-FROM takes an argument that is a regular expression 623 which covers a set of mail addresses. Only users with any of these mail 624 addresses are authorized to work with objects secured by the corresponding 625 maintainer(3). 627 The security mechanisms of the mntner object will only be applied on those 628 objects referencing a specific mntner object. The reference is done by 629 adding the attribute mnt-by to an object using the name of the mntner object 630 as its value. In Figure 14, the maintainer MAINT-AS3701 is maintained by 631 itself. 633 ------------------------------ 634 3. Clearly, neither of these mechanisms is sufficient to provide 635 strong authentication or authorization. Other public key (e.g., PGP) 636 authentication mechanisms are available from some of the IRRs. 638 mntner: MAINT-AS3701 639 descr: Network for Research and Engineering in Oregon 640 remark: Internal Backbone 641 admin-c: DMM65 642 tech-c: DMM65 643 upd-to: noc@nero.net 644 auth: CRYPT-PW 949WK1mirBy6c 645 auth: MAIL-FROM .*@nero.net 646 notify: noc@nero.net 647 mnt-by: MAINT-AS3701 648 changed: meyer@antc.uoregon.edu 970318 649 source: RADB 651 Figure 14: Maintainer Object 653 A.2 The Autonomous System Object 655 The autonomous system object describes the import and export policies of an 656 AS. Each organization registers an autonomous system object (aut-num) in the 657 IRR for its AS. Figure 15 shows the aut-num for AS3582 (UONET). 659 The autonomous system object lists contacts (admin-c, tech-c) and is 660 maintained by (mnt-by) MAINT-AS3701 which is the maintainer displayed in 661 Figure 14. 663 The most important attributes of the aut-num object are import and export. 664 The import clause of an aut-num specifies import policies, while the export 665 clause specifies export policies. The corresponding clauses allow a very 666 detailed description of the routing policy of the AS specified. The details 667 are given in section 2. 669 With these clauses, an aut-num object shows its relationship to other 670 autonomous systems by describing its peerings. In addition, it also defines 671 a routing entity comprising a group of IP networks which are handled 672 according to the rules defined in the aut-num object. Therefore, it is 673 closely linked to route objects. 675 In this example, AS3582 imports all routes from AS3701 by using the keyword 676 ANY. AS3582 imports only internal routes from AS4222, AS5650, and AS1798. 677 The import policy for for AS2914 is slightly more complex. Since AS2914 678 provides transit to various other ASes, AS3582 accepts routes with ASPATHs 679 that begin with AS2194 followed by members of AS-WNA, which is an as set 680 (see section A.4.1 below) describing those customers that transit AS2914. 682 Since AS3582 is a multi-homed stub AS (i.e., it does not provide transit), 683 its export policy consists simply of ``announce AS3582'' clauses; that is, 684 announce internal routes of AS3582. These routes are those in route objects 685 where the origin attribute is AS3582. 687 aut-num: AS3582 688 as-name: UONET 689 descr: University of Oregon, Eugene OR 690 import: from AS3701 accept ANY 691 import: from AS4222 accept <^AS4222$> 692 import: from AS5650 accept <^AS5650$> 693 import: from AS2914 accept <^AS2914+ (AS-WNA)*$> 694 import: from AS1798 accept <^AS1798$> 695 export: to AS3701 announce AS3582 696 export: to AS4222 announce AS3582 697 export: to AS5650 announce AS3582 698 export: to AS2914 announce AS3582 699 export: to AS1798 announce AS3582 700 admin-c: DMM65 701 tech-c: DMM65 702 notify: nethelp@ns.uoregon.edu 703 mnt-by: MAINT-AS3582 704 changed: meyer@antc.uoregon.edu 970316 705 source: RADB 707 Figure 15: Autonomous System Object 709 The aut-num object forms the basis of a scalable and maintainable router 710 configuration system. For example, if AS3582 originates a new route, it 711 need only create a route object for that route with origin AS3582. AS3582 712 can now build configuration using this route object without changing its 713 aut-num object. 715 Similarly, if for example, AS3701 originates a new route, it need only 716 create a route object for that route with origin AS3701. Both AS3701 and 717 AS3582 can now build configuration using this route object without modifying 718 its aut-num object. 720 A.3 The Route Object 722 In contrast to aut-num objects which describe propagation of routing 723 information for an autonomous system as a whole, route objects define single 724 routes from an AS. An example is given in Figure 16. 726 This route object is maintained by MAINT-AS3582 and references AS3582 by 727 the origin attribute. By this reference it is grouped together with other 728 route: 128.223.0.0/16 729 descr: UONet 730 descr: University of Oregon 731 descr: Computing Center 732 descr: Eugene, OR 97403-1212 733 descr: USA 734 origin: AS3582 735 mnt-by: MAINT-AS3582 736 changed: meyer@ns.uoregon.edu 960222 737 source: RADB 739 Figure 16: Example of a route object 741 routes of the same origin AS, becoming member of the routing entity denoted 742 by AS3582. The routing policies can then be defined in the aut-num objects 743 for this group of routes. 745 Consequently, the route objects give the routes from this AS which are 746 distributed to peer ASes according to the rules of the routing policy. 747 Therefore, for any route in the routing tables of the backbone routers a 748 route object must exist in one of the registries in IRR. route objects must 749 be registered in the IRR only for the routes seen outside your AS. Normally, 750 this set of external routes is different from the routes internally visible 751 within your AS. One of the major reasons is that external peers need no 752 information at all about your internal routing specifics. Therefore, 753 external routes are in general aggregated combinations of internal routes, 754 having shorter IP prefixes where applicable according to the CIDR rules. 755 Please see the CIDR FAQ [5] for a tutorial introduction to CIDR. It is 756 strongly recommended that you aggregate your routes as much as possible, 757 thereby minimizing the number of routes you inject into the global routing 758 table and at the same time reducing the corresponding number of route 759 objects in the IRR. 761 While you may easily query single route objects using the whois program, and 762 submit objects via mail to the registry robots, this becomes kind of awkward 763 for larger sets. The RAToolSet [6] offers several tools to make handling of 764 route objects easier. If you want to read policy data from the IRR and 765 process it by other programs, you might be interested in using peval which 766 is a low level policy evaluation tool. As an example, the command 768 peval -h radb.ra.net -expand_all AS3582 770 will give you all route objects from AS3582 registered with RADB. 772 A much more sophisticated tool from the RAToolSet to handle route objects 773 interactively is the route object editor roe (please see Figure 17). It has 774 a graphical user interface to view and manipulate route objects registered 775 at any IRR. New route objects may be generated from templates and submitted 776 to the registries. Moreover, the route objects from the databases may be 777 compared to real life routes. Therefore, roe is highly recommended as an 778 interface to the IRR for route objects. Further information on peval and 779 roe is available together with the RAToolSet [6]. 781 Figure 17: route object editor (roe). 783 A.4 Set Objects 785 With routing policies it is often necessary to reference groups of 786 autonomous systems or routes which have identical properties regarding a 787 specific policy. To make working with such groups easier RPSL allows to 788 combine them in set objects. There are two basic types of predefined set 789 objects, as-set, and route-set. The RPSL set objects are described below. 791 A.4.1 AS-SET Object 793 Autonomous system set objects (as-set) are used to group autonomous system 794 objects into named sets. An as-set has an RPSL name that starts with 795 ``AS-''. In the example in Figure 18, an as-set called AS-NERO-PARTNERS and 796 containing AS3701, AS4201, AS3582, AS4222, AS1798 is defined. The as-set 797 is the RPSL replacement for the RIPE-181 as-macro. It has been extended 798 to include ASes in the set indirectly by referencing as set names in the 799 aut-num objects. 801 AS-SETs are particularly useful when specifying policies for groups such 802 as customers, providers, or for transit. You are encouraged to register 803 sets for these groups because it is most likely that you will treat them 804 alike, i.e. you will have a very similar routing policy for all your 805 customers which have an autonomous system of their own. You may as well 806 discover that this is also true for the providers you are peering with, 807 and it is most convenient to have the ASes combined in one as-set for 808 which you offer transit. For example, if a transit provider specifies its 809 import policy using its customer's as-set (i.e., its import clause for the 810 customer contains the customer's as-set), then that customer can modify the 811 set of ASes that its transit provider accepts from it. Again, this can 812 be accomplished without requiring the customer or the transit provider to 813 modify its aut-num object. 815 as-set: AS3582:AS-PARTNERS 816 members: AS3701, AS4201, AS3582, AS4222, AS1798 818 Figure 18: as-set Object 820 The ASes of the set are simply compiled in a comma delimited list following 821 the members attribute of the as-set. This list may also contain other 822 AS-SETs. 824 A.4.2 ROUTE-SET Object 826 A route-set is a way to name a group of routes. The syntax is similar to 827 the as-set. A route-set has an RPSL name that starts with ``RS-''. The 828 members attribute lists the members of the set. The value of a members 829 attribute is a list of address prefixes, or route-set names. The members 830 of the route-set are the address prefixes or the names of other route sets 831 specified. 833 Figure 19 presents some example route-set objects. The set rs-uo contains 834 two address prefixes, namely 128.223.0.0/16 and 198.32.162.0/24. The 835 set rs-bar contains the members of the set rs-uo and the address prefix 836 128.7.0.0/16. 838 route-set: rs-uo 839 members: 128.223.0.0/16, 198.32.162.0/24 841 route-set: rs-bar 842 members: 128.7.0.0/16, rs-uo 844 route-set: AS3582:RS-MARTIANS 845 remarks: routes not accepted from any peer 846 members: 0.0.0.0/0, # default route 847 0.0.0.0/0^32, # host routes 848 224.0.0.0/3^4-32, # multicast routes 849 127.0.0.0/8^9-32, . . . 851 Figure 19: route-set Objects 853 B Output of RtConfig: An Example 855 In Figure 20, you see the result of running RtConfig on the source file in 856 Figure 12. 858 References 860 [1] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. 861 Terpstra, and C. Villamizer: Routing Policy Specification Language 862 (RPSL), RFC 2280. 864 [2] T. Bates, J-M. Jouanigot, D. Karrenberg, P. Lothberg, and M. Terpstra. 865 Representation of IP Routing Policies in the RIPE database, Technical 866 Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993. 868 [3] T. Bates, E. Gerich, J. Joncharay, J-M. Jouanigot, D. Karrenberg, 869 M. Terpstra, and J. Yu. Representation of IP Routing Policies in 870 a Routing Registry, Technical Report ripe-181, RIPE, RIPE NCC, 871 Amsterdam, Netherlands, October 1994. 873 [4] A. M. R. Magee. RIPE NCC Database Documentation. Technical Report 874 RIPE-157, RIPE NCC, Amsterdam, Netherlands, May 1997. 876 [5] Hank Nussbacher. The CIDR FAQ. Tel Aviv University and IBM Israel. 877 http://www.ibm.net.il/~hank/cidr.html 879 [6] The RAToolSet. http://www.ra.net/ra/RAToolSet/ 881 [7] Y. Rekhter adn T. Li. A Border Gateway Protocol 4 (BGP-4). Request for 882 Comment RFC 1654. Network Information Center, July 1994. 884 [8] RtConfig as part of the RAToolSet. 885 http://www.ra.net/ra/RAToolSet/RtConfig.html 887 [9] E. Chen, T. Bates. An Application of the BGP Community Attribute in 888 Multi-Home Routing. RFC 1998. 890 router bgp 3582 891 network 128.223.0.0 892 ! 893 ! NERO 894 ! 895 neighbor 198.32.162.2 remote-as 3701 897 no access-list 100 898 access-list 100 permit ip 128.223.0.0 0.0.0.0 255.255.0.0 0.0.0.0 899 access-list 100 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 900 ! 901 ! 902 no route-map AS3701-EXPORT 903 route-map AS3701-EXPORT permit 1 904 match ip address 100 905 ! 906 router bgp 3582 907 neighbor 198.32.162.2 route-map AS3701-EXPORT out 908 ! 909 ! 910 no route-map AS3701-IMPORT 911 route-map AS3701-IMPORT permit 1 912 set local-preference 1000 913 ! 914 router bgp 3582 915 neighbor 198.32.162.2 route-map AS3701-IMPORT in 916 ! 917 ! WNA/VERIO 918 ! 919 neighbor 198.32.162.6 remote-as 2914 920 ! 921 no route-map AS2914-EXPORT 922 route-map AS2914-EXPORT permit 1 923 match ip address 100 924 ! 925 router bgp 3582 926 neighbor 198.32.162.6 route-map AS2914-EXPORT out 927 no ip as-path access-list 100 928 ip as-path access-list 100 permit ^_2914(((_[0-9]+))*_ \ 929 (13|22|97|132|175|668|1914|2905|2914|3361|3381|3791|3937| \ 930 4178|4354|4571|4674|4683|5091|5303|5798|5855|5856|5881|6083 \ 931 |6188|6971|7790|7951|8028))?$ 932 ! 933 no route-map AS2914-IMPORT 934 route-map AS2914-IMPORT permit 1 935 match as-path 100 936 set local-preference 998 937 ! 938 router bgp 3582 939 neighbor 198.32.162.6 route-map AS2914-IMPORT in 940 ! 942 Figure 20: Output of RtConfig 943