rfc2650.txt

中、英文RFC文档大全打包下载完全版 .


RFC 2650                 Using RPSL in Practice              August 1999


   Moreover, the routing policy from the databases may be compared to
   real life peerings.  Therefore, aoe is highly recommended as an
   interface to the IRR for aut-num objects.  Further information on aoe
   is available together with the RAToolSet [6].

3.2 Router Configuration Using RtConfig

   RtConfig is a tool developed by the Routing Arbiter project [8] to
   generate vendor specific router configurations from the policy data
   held in the various IRRs.  RtConfig currently supports Cisco, gated
   and RSd configuration formats.  It has been publicly available since
   late 1994, and is currently being used by many sites for router
   configuration.  The next section describes a methodology for
   generating vendor specific router configurations using RtConfig (2).

3.3 Using RtConfig

   The general paradigm for using RtConfig involves registering policy
   in an IRR, building a RtConfig source file, then running running
   RtConfig against the source file and the IRR database to create
   vendor specific router configuration for the specified policy.  The
   source file will contain vendor specific commands as well as RtConfig
   commands.  To make a source file, pick up one of your router
   configuration files and replace the vendor specific policy
   configuration commands with the RtConfig commands.

   Commands beginning with @RtConfig instruct RtConfig to perform
   special operations.  An example source file is shown in Figure 11.
   In this example, commands such as "@RtConfig import AS3582
   198.32.162.1 AS3701 198.32.162.2" instruct RtConfig to generate
   vendor specific import policies where the router 198.32.162.1 in
   AS3582 is importing routes from router 198.32.162.2 in AS3701.  The
   other @RtConfig commands instruct the RtConfig to use certain names
   and numbers in the output that it generates (please refer to RtConfig
   manual [8] for additional information).

   Once a source file is created, the file is processed by RtConfig (the
   default IRR is the RADB, and the default vendor is Cisco; however,
   command line options can be used to override these values).  The
   result of running RtConfig on the source file in Figure 11 is shown
   in Figure 19 in Appendix B.










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


      router    bgp 3582
      network   128.223.0.0
      !
      !       Start with access-list 100
      !
      @RtConfig set cisco_access_list_no = 100
      !
      !       NERO
      neighbor 198.32.162.2 remote-as 3701
      @RtConfig set cisco_map_name = "AS3701-EXPORT"
      @RtConfig export AS3582 198.32.162.1 AS3701 198.32.162.2
      @RtConfig set cisco_map_name = "AS3701-IMPORT"
      @RtConfig import AS3582 198.32.162.1 AS3701 198.32.162.2
      !
      !       WNA/VERIO
      neighbor 198.32.162.6 remote-as 2914
      @RtConfig set cisco_map_name = "AS2914-EXPORT"
      @RtConfig export AS3582 198.32.162.1 AS2914 198.32.162.6
      @RtConfig set cisco_map_name = "AS2914-IMPORT"
      @RtConfig import AS3582 198.32.162.1 AS2914 198.32.162.6

      Figure 11:  RtConfig Template File





























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


A RPSL Database Objects

      In this appendix, we introduce the RPSL objects required to implement many
      typical Internet routing policies.  RFC-2622 and RIPE-157 provide the
      authoritative description for these objects and for the RPSL syntax, but
      this appendix will often be sufficient in practice.

   The frequently needed objects are:

      o  maintainer objects (mntner)

      o  autonomous system number objects (aut-num)

      o  route objects (route)

      o  set objects (as-set, route-set)

   and they are described in the following sections.  To make your
   routing policies and configuration public, these objects should be
   registered in exactly one of the IRR registries.

   In general, you can register your information by sending the
   appropriate objects to an email address for the registry you use.
   The email should consist of the objects you want to have registered
   or modified, separated by empty lines, and preceded by some kind of
   authentication details (see below).  The registry robot processes
   your mail and enters new objects into the database, deletes old ones
   (upon request), or makes the requested modifications.

   You will receive a response indicating the status of your submission.
   As the emails are handled automatically, the response is generally
   very fast.  However, it should be remembered that a significant
   number of updates are also sometimes submitted to the database (by
   other robots), so the response time cannot be guaranteed.  The email
   addresses for submitting objects to the existing registries are
   listed in Figure 12.

               ANS    [e-mail]
               CANET  [e-mail]
               CW     [e-mail]
               RADB   [e-mail]
               RIPE   [e-mail]

      Figure 12:  Email addresses to register policy objects in IRR.







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


   Because it is required that a maintainer be specified in many of the
   database objects, a mntner is usually the first to be created.  To
   have it properly authenticated, a mntner object is added manually by
   registry staff.  Thereafter, all database submissions, deletions and
   modifications should be done through the registry robot.

   Each of the registries can provide additional information and support
   for users.  For the public registries this support is available from
   the email addresses listed in Figure 13.

               RADB  [e-mail]
               RIPE  [e-mail]

            Figure 13:  Support email addresses.

   If you are using one of the private registries, your service provider
   should be able to address your questions.

A.1 The Maintainer Object

   The maintainer object is used to introduce some kind of authorization
   for registrations.  It lists various contact persons and describes
   security mechanisms that will be applied when updating objects in the
   IRR.  Registering a mntner object is the first step in creating
   policies for an AS. An example is shown in Figure 14.  The maintainer
   is called MAINT-AS3701.  The contact person here is the same for
   administrative (admin-c) and technical (tech-c) issues and is
   referenced by the NIC-handle DMM65.  NIC-handles are unique
   identifiers for persons in registries.  Refer to registry
   documentation for further details on person objects and usage of
   NIC-handles.

   The example shows two authentication mechanisms:  CRYPT-PW and MAIL-
   FROM.  CRYPT-PW takes as its argument a password that is encrypted
   with Unix crypt (3) routine.  When sending updates, the maintainer
   adds the field password:  <cleartext password> to the beginning of
   any requests that are to be authenticated.  MAIL-FROM takes an
   argument that is a regular expression which covers a set of mail
   addresses.  Only users with any of these mail addresses are
   authorized to work with objects secured by the corresponding
   maintainer (3).

   The security mechanisms of the mntner object will only be applied on
   those objects referencing a specific mntner object.  The reference is
   done by adding the attribute mnt-by to an object using the name of
   the mntner object as its value.  In Figure 14, the maintainer MAINT-
   AS3701 is maintained by itself.




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


      mntner:      MAINT-AS3701
      descr:       Network for Research and Engineering in Oregon
      remark:      Internal Backbone
      admin-c:     DMM65
      tech-c:      DMM65
      upd-to:      [e-mail]
      auth:        CRYPT-PW  949WK1mirBy6c
      auth:        MAIL-FROM .*@nero.net
      notify:      [e-mail]
      mnt-by:      MAINT-AS3701
      changed:     [e-mail] 970318
      source:      RADB

      Figure 14:  Maintainer Object

A.2 The Autonomous System Object

   The autonomous system object describes the import and export policies
   of an AS. Each organization registers an autonomous system object
   (aut-num) in the IRR for its AS. Figure 15 shows the aut-num for
   AS3582 (UONET).

   The autonomous system object lists contacts (admin-c, tech-c) and is
   maintained by (mnt-by) MAINT-AS3701 which is the maintainer displayed
   in Figure 14.

   The most important attributes of the aut-num object are import and
   export.  The import clause of an aut-num specifies import policies,
   while the export clause specifies export policies.  The corresponding
   clauses allow a very detailed description of the routing policy of
   the AS specified.  The details are given in section 2.

   With these clauses, an aut-num object shows its relationship to other
   autonomous systems by describing its peerings.  In addition, it also
   defines a routing entity comprising a group of IP networks which are
   handled according to the rules defined in the aut-num object.
   Therefore, it is closely linked to route objects.

   In this example, AS3582 imports all routes from AS3701 by using the
   keyword ANY. AS3582 imports only internal routes from AS4222, AS5650,
   and AS1798.  The import policy for for AS2914 is slightly more
   complex.  Since AS2914 provides transit to various other ASes, AS3582
   accepts routes with ASPATHs that begin with AS2194 followed by
   members of AS-WNA, which is an as set (see section A.4.1 below)
   describing those customers that transit AS2914.






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


   Since AS3582 is a multi-homed stub AS (i.e., it does not provide
   transit), its export policy consists simply of "announce AS3582"
   clauses; that is, announce internal routes of AS3582.  These routes
   are those in route objects where the origin attribute is AS3582.

      aut-num:     AS3582
      as-name:     UONET
      descr:       University of Oregon, Eugene OR
      import:      from AS3701 accept ANY
      import:      from AS4222 accept <^AS4222+$>
      import:      from AS5650 accept <^AS5650+$>
      import:      from AS2914 accept <^AS2914+ (AS-WNA)*$>
      import:      from AS1798 accept <^AS1798+$>
      export:      to AS3701 announce AS3582
      export:      to AS4222 announce AS3582
      export:      to AS5650 announce AS3582
      export:      to AS2914 announce AS3582
      export:      to AS1798 announce AS3582
      admin-c:     DMM65
      tech-c:      DMM65
      notify:      [e-mail]
      mnt-by:      MAINT-AS3582
      changed:     [e-mail] 970316
      source:      RADB

      Figure 15:  Autonomous System Object

   The aut-num object forms the basis of a scalable and maintainable
   router

      route:       128.223.0.0/16
      origin:      AS3582
      descr:       UONet
      descr:       University of Oregon
      descr:       Computing Center
      descr:       Eugene, OR 97403-1212
      descr:       USA
      mnt-by:      MAINT-AS3582
      changed:     [e-mail] 960222
      source:      RADB

      Figure 16:  Example of a route object

   configuration system.  For example, if AS3582 originates a new route,
   it need only create a route object for that route with origin AS3582.
   AS3582 can now build configuration using this route object without
   changing its aut-num object.




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


   Similarly, if for example, AS3701 originates a new route, it need
   only create a route object for that route with origin AS3701.  Both
   AS3701 and AS3582 can now build configuration using this route object
   without modifying its aut-num object.

A.3 The Route Object

   In contrast to aut-num objects which describe propagation of routing
   information for an autonomous system as a whole, route objects define
   single routes from an AS. An example is given in Figure 16.

   This route object is maintained by MAINT-AS3582 and references AS3582
   by the origin attribute.  By this reference it is grouped together
   with other routes of the same origin AS, becoming member of the
   routing entity denoted by AS3582.  The routing policies can then be
   defined in the aut-num objects for this group of routes.

   Consequently, the route objects give the routes from this AS which
   are distributed to peer ASes according to the rules of the routing
   policy.  Therefore, for any route in the routing tables of the
   backbone routers a route object must exist in one of the registries
   in IRR. route objects must be registered in the IRR only for the
   routes seen outside your AS. Normally, this set of external routes is
   different from the routes internally visible within your AS. One of
   the major reasons is that external peers need no information at all