rfc2650.txt

RFC 的详细文档！

Network Working Group                                           D. Meyer
Request for Comments: 2650                                 Cisco Systems
Category: Informational                                       J. Schmitz
                                                         America On-Line
                                                               C. Orange
                                                                RIPE NCC
                                                                M. Prior
                                                                 Connect
                                                         C. Alaettinoglu
                                                                 USC/ISI
                                                             August 1999


                         Using RPSL in Practice

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This document is a tutorial on using the Routing Policy Specification
   Language (RPSL) to describe routing policies in the Internet Routing
   Registry (IRR). We explain how to specify various routing policies
   and configurations using RPSL, how to register these policies in the
   IRR, and how to analyze them using the routing policy analysis tools,
   for example to generate vendor specific router configurations.

1 Introduction

   This document is a tutorial on RPSL and is targeted towards an
   Internet/Network Service Provider (ISP/NSP) engineer who understands
   Internet routing, but is new to RPSL and to the IRR. Readers are
   referred to the RPSL reference document (RFC 2622) [1] for
   completeness.  It is also good to have that document at hand while
   working through this tutorial.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.





Meyer, et al.                Informational                      [Page 1]

RFC 2650                 Using RPSL in Practice              August 1999


   The IRR is a repository of routing policies.  Currently, the IRR
   repository is a set of five repositories maintained at the following
   sites:  the CA*Net registry in Canada, the ANS, CW and RADB
   registries in the United States of America, and the RIPE registry in
   Europe.  The five repositories are run independently.  However, each
   site exchanges its data with the others regularly (at least once a
   day and as often as every ten minutes).  CW, CA*Net and ANS are
   private registries which contain the routing policies of the networks
   and the customer networks of CW, CA*Net, and ANS respectively.  RADB
   and RIPE are both public registries, and any ISP can publish their
   policies in these registries.

   The registries all maintain up-to-date copies of one another's data.
   At any of the sites, the five registries can be inspected as a set.
   One should refrain from registering his/her data in more than one of
   the registries, as this practice leads almost invariably to
   inconsistencies in the data.  The user trying to interpret the data
   is left in a confusing (at best) situation.  CW, ANS and CA*Net
   customers are generally required to register their policies in their
   provider's registry.  Others may register policies either at the RIPE
   or RADB registry, as preferred.

   RPSL is based on RIPE-181 [2, 3], a language used to register routing
   policies and configurations in the IRR. Operational use of RIPE-181
   has shown that it is sometimes difficult (or impossible) to express a
   routing policy which is used in practice.  RPSL has been developed to
   address these shortcomings and to provide a language which can be
   further extended as the need arises.  RPSL obsoletes RIPE-181.

   RPSL constructs are expressed in one or more database "objects" which
   are registered in one of the registries described above.  Each
   database object contains some routing policy information and some
   necessary administrative data.  For example, an address prefix routed
   in the inter-domain mesh is specified in a route object, and the
   peering policies of an AS are specified in an aut-num object.  The
   database objects are related to each other by reference.  For
   example, a route object must refer to the aut-num object for the AS
   in which it is originated.  Implicitly, these relationships define
   sets of objects, which can be used to specify policies effecting all
   members.  For example, we can specify a policy for all routes of an
   ISP, by referring to the AS number in which the routes are registered
   to be originated.

   When objects are registered in the IRR, they become available for
   others to query using a whois service.  Figure 1 illustrates the use
   of the whois command to obtain the route object for 128.223.0.0/16.
   The output of the whois command is the ASCII representation of the
   route object.  The syntax and semantics of the route object are



Meyer, et al.                Informational                      [Page 2]

RFC 2650                 Using RPSL in Practice              August 1999


   described in Appendix A.3.  Registered policies can also be compared
   with others for consistency and they can be used to diagnose
   operational routing problems in the Internet.

      % whois -h whois.ra.net 128.223.0.0/16
        route:       128.223.0.0/16
        descr:       UONet
        descr:       University of Oregon
        descr:       Computing Center
        descr:       Eugene, OR 97403-1212
        descr:       USA
        origin:      AS3582
        mnt-by:      MAINT-AS3582
        changed:     [e-mail] 19960222
        source:      RADB

      Figure 1:  whois command and a route object.

   The RAToolSet [6] is a suite of tools which can be used to analyze
   the routing registry data.  It includes tools to configure routers
   (RtConfig), tools to analyze paths on the Internet (prpath and
   prtraceroute), and tools to compare, validate and register RPSL
   objects (roe, aoe and prcheck).

   In the following section, we will describe how common routing
   policies can be expressed in RPSL. The objects themselves are
   described in Appendix A.  Authoritative information on the IRR
   objects, however, should be sought in RFC-2622, and authoritative
   information on general database objects (person, role, and
   maintainers) and on querying and updating the registry databases,
   should be sought in RIPE-157 [4].  Section 3.2 describes the use of
   RtConfig to generate vendor specific router configurations.

2 Specifying Policy in RPSL

   The key purpose of RPSL is to allow you to specify your routing
   configuration in the public Internet Routing Registry (IRR), so that
   you and others can check your policies and announcements for
   consistency.  Moreover, in the process of setting policies and
   configuring routers, you take the policies and configurations of
   others into account.

   In this section, we begin by showing how some simple peering policies
   can be expressed in RPSL. We will build on that to introduce various
   database objects that will be needed in order to register policies in
   the IRR, and to show how more complex policies can be expressed.





Meyer, et al.                Informational                      [Page 3]

RFC 2650                 Using RPSL in Practice              August 1999


2.1 Common Peering Policies

   The peering policies of an AS are registered in an aut-num object
   which looks something like that in Figure 2.  We will focus on the
   semantics of the import and export attributes in which peering
   policies are expressed.  We will also describe some of the other key
   attributes in the aut-num object, but the reader should refer to
   RFC-2622 or to RIPE-157 for the definitive descriptions.

      aut-num:     AS2
      as-name:     CAT-NET
      descr:       Catatonic State University
      import:      from AS1 accept ANY
      import:      from AS3 accept <^AS3+$>
      export:      to AS3 announce ANY
      export:      to AS1 announce AS2 AS3
      admin-c:     AO36-RIPE
      tech-c:      CO19-RIPE
      mnt-by:      OPS4-RIPE
      changed:     [e-mail]
      source:      RIPE

      Figure 2:  Autonomous System Object

   Now consider Figure 3 (AS4 and AS5 in the figure will be discussed
   later).  The peering policies expressed in the AS2 aut-num object in
   Figure 2 are typical for a small service provider providing
   connectivity for a customer AS3 and using AS1 for transit.  That is,
   AS2 only accepts announcements from AS3 which:

   o  are originated in AS3; and

   o  have paths composed of only AS3's (^ in <^AS3+$> means that AS3 is
      the first member of the path, + means that AS3 occurs one or more
      times in the path, and $ means that no other AS can be present in
      the path after AS3) (1).

   To AS1, AS2 announces only those routes which originate in their AS
   or in their customer's AS.

      AS1--------AS2--------AS3
                  |          |
                  |          |
                 AS4--------AS5

      Figure 3:  Some Neighboring ASes.





Meyer, et al.                Informational                      [Page 4]

RFC 2650                 Using RPSL in Practice              August 1999


   In the example above, "accept ANY" in the import attribute indicates
   that AS2 will accept any announcements that AS1 sends, and "announce
   ANY" in the export attribute indicates that any route that AS2 has in
   its routing table will be passed on to AS3.  Assuming that AS1
   announces "ANY" to AS2, AS2 is taking full routing from AS1.

   Note that with this peering arrangement, if AS1 adds or deletes route
   objects, there is no need to update any of the aut-num objects to
   continue the full routing policy.  Added (or deleted) route objects
   will implicitly update AS1's and AS2's policies.

   While the peering policy specified in Figure 2 for AS2 is common, in
   practice many peering agreements are more complex.  Before we
   consider more examples, however, let's first consider the aut-num
   object itself.  Note that it is just a set of attribute labels and
   values which can be submitted to one of the registry databases.  This
   particular object is specified as being in (or headed for) the RIPE
   registry (see the last line in Figure 2).  The source should be
   specified as one of ANS, CANET, CW, RADB, or RIPE depending on the
   registry in which the object is maintained.  The source attribute
   must be specified in every database object.

   It is also worth noting that this object is "maintained by" OPS4-RIPE
   (the value of the mnt-by attribute), which references a "mntner"
   object.  Because the aut-num object may be used for router
   configuration and other operational purposes, the readers need to be
   able to count on the validity of its contents.  It is therefore
   required that a mntner be specified in the aut-num and in most other
   database objects, which means you must create a mntner object before
   you can register your peering policies.  For brief information on the
   "mntner" object and object writeability, see Appendix A of this
   document.  For more extensive information on how to set up and use a
   mntner to protect your database objects, see Section 2.3 of RIPE-157.

2.2 ISP Customer - Transit Provider Policies

   It is not uncommon for an ISP to acquire connectivity from a transit
   provider which announces all routes to it, which it in turn passes on
   to its customers to allow them to access hosts on the global
   Internet.  Meanwhile, the ISP will generally announce the routes of
   its customers networks to the transit ISP, making them accessible on
   the global Internet.  This is the service that is specified in Figure
   2 for AS3.

   Consider again Figure 3.  Suppose now that AS2 wants to provide the
   same service to AS4.  Clearly, it would be easy to modify the import
   and export lines in the aut-num object for AS2 (Figure 2) to those
   shown in Figure 4.



Meyer, et al.                Informational                      [Page 5]

RFC 2650                 Using RPSL in Practice              August 1999


      import:      from AS1 accept ANY
      import:      from AS3 accept <^AS3+$>
      import:      from AS4 accept <^AS4+$>
      export:      to AS3 announce ANY
      export:      to AS4 announce ANY
      export:      to AS1 announce AS2 AS3 AS4

      Figure 4:  Policy for AS3 and AS4 in the AS2 as-num object

   These changes are trivial to make of course, but clearly as the
   number of AS2 customers grows, it becomes more difficult to keep
   track of, and to prevent errors.  Note also that if AS1 is selective
   about only accepting routes from the customers of AS2 from AS2, the
   aut-num object for AS1 would have to be adjusted to accommodate AS2's
   new customer.

   By using the RPSL "as-set" object, we can simplify this
   significantly.  In Figure 5, we describe the customers of AS2.
   Having this set to work with, we can now rewrite the policies in
   Figure 2 as shown in Figure 6.

      as-set:      AS2:AS-CUSTOMERS
      members:     AS3 AS4
      changed:     [e-mail]
      source:      RIPE

      Figure 5:  The as-set object

      import:      from AS1 accept ANY
      import:      from AS2:AS-CUSTOMERS accept <^AS2:AS-CUSTOMERS+$>
      export:      to AS2:AS-CUSTOMERS announce ANY
      export:      to AS1 announce AS2 AS2:AS-CUSTOMERS

      Figure 6:  Policy in the AS2 aut-num object for all AS2 customers

   Note that if the aut-num object for AS1 contains the line:

      import:      from AS2 accept <^AS2+ AS2:AS-CUSTOMERS*$>

   then no changes will need to be made to the aut-num objects for AS1
   or AS2 as the AS2 customer base grows.  The AS numbers for new
   customers can simply be added to the as-set AS2:AS-CUSTOMERS, and
   everything will work as for the existing customers.  Clearly in terms
   of readability, scalability and maintainability, this is a far better
   mechanism when compared to adding policy for the customer AS's to the
   aut-num objects directly.  The policy in this particular example
   states that AS1 will accept route announcements from AS2 in which the
   first element of the path is AS2, followed by more occurrences of



Meyer, et al.                Informational                      [Page 6]

RFC 2650                 Using RPSL in Practice              August 1999


   AS2, and then 0 or more occurrences of any AS2 customer (e.g.  any
   member of the as-set AS2:AS-CUSTOMERS).

   Alternatively, one may wish to limit the routes one accepts from a
   peer, especially if the peer is a customer.  This is recommended for
   several reasons, such as preventing the improper use of unassigned
   address space, and of course malicious use of another organization's
   address space.

   Such filtering can be expressed in various ways in RPSL. Suppose the
   address space 7.7.0.0/16 has been allocated to the ISP managing AS3
   for assignment to its customers.  AS3 may want to announce part or
   all of this block on the global Internet.  Suppose AS2 wants to be
   certain that it only accepts announcements from AS3 for address space
   that has been properly allocated to AS3.  AS2 might then modify the
   AS3 import line in Figure 2 to read:

      import:      from AS3 accept { 7.7.0.0/16^16-19 }

   which states that route announcements for this address block will be
   accepted from AS3 if they are of length upto /19.  This of course
   will have to be modified if and when AS3 gets more address space.
   Moreover, it is again clear that for an ISP with a growing or