rfc2280.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                     C. Alaettinoglu
Request for Comments: 2280             USC/Information Sciences Institute
Category: Standards Track                                        T. Bates
                                                            Cisco Systems
                                                                E. Gerich
                                                          At Home Network
                                                            D. Karrenberg
                                                                     RIPE
                                                                 D. Meyer
                                                     University of Oregon
                                                              M. Terpstra
                                                             Bay Networks
                                                            C. Villamizar
                                                                      ANS
                                                             January 1998

              Routing Policy Specification Language (RPSL)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

   Table of Contents

   1 Introduction                                                     2
   2 RPSL Names, Reserved Words, and Representation                   3
   3 Contact Information                                              6
     3.1 mntner Class  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2 person Class  . . . . . . . . . . . . . . . . . . . . . . .  8
     3.3 role Class  . . . . . . . . . . . . . . . . . . . . . . . .  9
   4 route Class                                                     10
   5 Set Classes                                                     12
     5.1 route-set Class . . . . . . . . . . . . . . . . . . . . . . 12
     5.2 as-set Class  . . . . . . . . . . . . . . . . . . . . . . . 14
     5.3 Predefined Set Objects  . . . . . . . . . . . . . . . . . . 15
     5.4 Hierarchical Set Names  . . . . . . . . . . . . . . . . . . 15
   6 aut-num Class                                                   16
     6.1 import Attribute:  Import Policy Specification  . . . . . . 16
       6.1.1 Peering Specification . . . . . . . . . . . . . . . . . 17
       6.1.2 Action Specification  . . . . . . . . . . . . . . . . . 19



Alaettinoglu, et. al.       Standards Track                     [Page 1]

RFC 2280                          RPSL                      January 1998


       6.1.3 Filter Specification  . . . . . . . . . . . . . . . . . 20
       6.1.4 Example Policy Expressions  . . . . . . . . . . . . . . 24
     6.2 export Attribute:  Export Policy Specification  . . . . . . 24
      6.3 Other Routing  Protocols, Multi-Protocol Routing
       Protocols, and Injecting Routes Between Protocols   . . . . . 25
     6.4 Ambiguity Resolution  . . . . . . . . . . . . . . . . . . . 26
     6.5 default Attribute:  Default Policy Specification  . . . . . 28
     6.6 Structured Policy Specification . . . . . . . . . . . . . . 29
   7 dictionary Class                                                33
     7.1 Initial RPSL Dictionary and Example Policy Actions
      and Filters  . . . . . . . . . . . . . . . . . . . . . . . . . 36
   8 Advanced route Class                                            41
     8.1 Specifying Aggregate Routes . . . . . . . . . . . . . . . . 41
       8.1.1 Interaction with policies in aut-num class  . . . . . . 45
       8.1.2 Ambiguity resolution with overlapping aggregates  . . . 46
     8.2 Specifying Static Routes  . . . . . . . . . . . . . . . . . 47
   9 inet-rtr Class                                                  48
   10 Security Considerations                                        49
   11 Acknowledgements                                               50
   A Routing Registry Sites                                          51
   B Authors' Addresses                                              52
   C Full Copyright Statement                                        53

1 Introduction

   This memo is the reference document for the Routing Policy
   Specification Language (RPSL). RPSL allows a network operator to be
   able to specify routing policies at various levels in the Internet
   hierarchy; for example at the Autonomous System (AS) level.  At the
   same time, policies can be specified with sufficient detail in RPSL
   so that low level router configurations can be generated from them.
   RPSL is extensible; new routing protocols and new protocol features
   can be introduced at any time.

   RPSL is a replacement for the current Internet policy specification
   language known as RIPE-181 [4] or RFC-1786 [5].  RIPE-81 [6] was the
   first language deployed in the Internet for specifying routing
   policies.  It was later replaced by RIPE-181 [4].  Through
   operational use of RIPE-181 it has become apparent that certain
   policies cannot be specified and a need for an enhanced and more
   generalized language is needed.  RPSL addresses RIPE-181's
   limitations.









Alaettinoglu, et. al.       Standards Track                     [Page 2]

RFC 2280                          RPSL                      January 1998


   RPSL was designed so that a view of the global routing policy can be
   contained in a single cooperatively maintained distributed database
   to improve the integrity of Internet's routing.  RPSL is not designed
   to be a router configuration language.  RPSL is designed so that
   router configurations can be generated from the description of the
   policy for one autonomous system (aut-num class) combined with the
   description of a router (inet-rtr class), mainly providing router ID,
   autonomous system number of the router, interfaces and peers of the
   router, and combined with a global database mappings from AS sets to
   ASes (as-set class), and from origin ASes and route sets to route
   prefixes (route and route-set classes).  The accurate population of
   the RPSL database can help contribute toward such goals as router
   configurations that protect against accidental (or malicious)
   distribution of inaccurate routing information, verification of
   Internet's routing, and aggregation boundaries beyond a single AS.

   RPSL is object oriented; that is, objects contain pieces of policy
   and administrative information.  These objects are registered in the
   Internet Routing Registry (IRR) by the authorized organizations.  The
   registration process is beyond the scope of this document.  Please
   refer to [1, 15, 2] for more details on the IRR.

   In the following sections, we present the classes that are used to
   define various policy and administrative objects.  The "mntner" class
   defines entities authorized to add, delete and modify a set of
   objects.  The "person" and "role" classes describes technical and
   administrative contact personnel.  Autonomous systems (ASes) are
   specified using the "aut-num" class.  Routes are specified using the
   "route" class.  Sets of ASes and routes can be defined using the
   "as-set" and "route-set" classes.  The "dictionary" class provides
   the extensibility to the language.  The "inet-rtr" class is used to
   specify routers.  Many of these classes were originally defined in
   earlier documents [4, 11, 14, 10, 3] and have all been enhanced.

   This document is self-contained.  However, the reader is encouraged
   to read RIPE-181 [5] and the associated documents [11, 14, 10, 3] as
   they provide significant background as to the motivation and
   underlying principles behind RIPE-181 and consequently, RPSL. For a
   tutorial on RPSL, the reader should read the RPSL applications
   document [2].

2 RPSL Names, Reserved Words, and Representation

   Each class has a set of attributes which store a piece of information
   about the objects of the class.  Attributes can be mandatory or
   optional: A mandatory attribute has to be defined for all objects of





Alaettinoglu, et. al.       Standards Track                     [Page 3]

RFC 2280                          RPSL                      January 1998


   the class; optional attributes can be skipped.  Attributes can also
   be single or multiple valued.  Each object is uniquely identified by
   a set of attributes, referred to as the class "key".

   The value of an attribute has a type.  The following types are most
   widely used.  Note that RPSL is case insensitive and only the
   characters from the ASCII character set can be used.

   <object-name>Many objects in RPSL have a name.  An <object-name>
       is made up of letters, digits, the character underscore "_", and
       the character hyphen "-"; the first character of a name must be a
       letter, and the last character of a name must be a letter or a
       digit.  The following words are reserved by RPSL, and they can
       not be used as names:

             any as-any rs-any peeras
             and or not
             atomic from to at action accept announce except refine
             networks into inbound outbound

       Names starting with certain prefixes are reserved for certain
       object types.  Names starting with "as-" are reserved for as set
       names.  Names starting with "rs-" are reserved for route set
       names.

   <as-number>An AS number x is represented as the string "ASx".  That
       is, the AS 226 is represented as AS226.

   <ipv4-address>An IPv4 address is represented as a sequence of four
       integers in the range from 0 to 255 separated by the character
       dot ".".  For example, 128.9.128.5 represents a valid IPv4
       address.  In the rest of this document, we may refer to IPv4
       addresses as IP addresses.

   <address-prefix>An address prefix is represented as an IPv4
       address followed by the character slash "/" followed by an
       integer in the range from 0 to 32.  The following are valid
       address prefixes: 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and
       the following address prefixes are invalid: 0/0, 128.9/16 since 0
       or 128.9 are not strings containing four integers.

   <address-prefix-range>An address prefix range is an address
       prefix followed by one of the following range operators:








Alaettinoglu, et. al.       Standards Track                     [Page 4]

RFC 2280                          RPSL                      January 1998


       ^- is the exclusive more specifics operator; it stands
           for the more specifics of the address prefix excluding the
           address prefix itself.  For example, 128.9.0.0/16^- contains
           all the more specifics of 128.9.0.0/16 excluding
           128.9.0.0/16.

       ^+ is the inclusive more specifics operator; it stands
           for the more specifics of the address prefix including the
           address prefix itself.  For example, 5.0.0.0/8^+ contains all
           the more specifics of 5.0.0.0/8 including 5.0.0.0/8.

       ^n where n is an integer, stands for all the length n specifics
           of the address prefix.  For example, 30.0.0.0/8^16 contains
           all the more specifics of 30.0.0.0/8 which are of length 16
           such as 30.9.0.0/16.

       ^n-m where n and m are integers, stands for all the length n to
           length m specifics of the address prefix.  For example,
           30.0.0.0/8^24-32 contains all the more specifics of
           30.0.0.0/8 which are of length 24 to 32 such as 30.9.9.96/28.

       Range operators can also be applied to address prefix sets.  In
       this case, they distribute over the members of the set.  For
       example, for a route-set (defined later) rs-foo, rs-foo^+
       contains all the inclusive more specifics of all the prefixes in
       rs-foo.

   <date>A date is represented as an eight digit integer of the
       form YYYYMMDD where YYYY represents the year, MM represents the
       month of the year (01 through 12), and DD represents the day of
       the month (01 through 31).  For example, June 24, 1996 is
       represented as 19960624.

   <email-address>is as described in RFC-822[8].

   <dns-name>is as described in RFC-1034[16].

   <nic-handle>is a uniquely assigned identifier[13] used by routing,
       address allocation, and other registries to unambiguously refer
       to contact information.  person and role classes map NIC handles
       to actual person names, and contact information.

   <free-form>is a sequence of ASCII characters.

   <X-name>is a name of an object of type X. That is <mntner-name>
       is a name of a mntner object.





Alaettinoglu, et. al.       Standards Track                     [Page 5]

RFC 2280                          RPSL                      January 1998


   <registry-name>is a name of an IRR registry.  The routing
       registries are listed in Appendix A.

   A value of an attribute may also be a list of one of these types.  A
   list is represented by separating the list members by commas ",".
   For example, "AS1, AS2, AS3, AS4" is a list of AS numbers.  Note that
   being list valued and being multiple valued are orthogonal.  A
   multiple valued attribute has more than one value, each of which may
   or may not be a list.  On the other hand a single valued attribute
   may have a list value.

   An RPSL object is textually represented as a list of attribute-value
   pairs.  Each attribute-value pair is written on a separate line.  The
   attribute name starts at column 0, followed by character ":" and
   followed by the value of the attribute.  The object's representation
   ends when a blank line is encountered.  An attribute's value can be
   split over multiple lines, by starting the continuation lines with a
   white-space (" " or tab) character.  The order of attribute-value
   pairs is significant.

   An object's description may contain comments.  A comment can be
   anywhere in an object's definition, it starts at the first "#"
   character on a line and ends at the first end-of-line character.
   White space characters can be used to improve readability.

3 Contact Information

   The mntner, person and role classes, admin-c, tech-c, mnt-by,
   changed, and source attributes of all classes describe contact
   information.  The mntner class also specifies what entities can
   create, delete and update other objects.  These classes do not
   specify routing policies and each registry may have different or
   additional requirements on them.  Here we present the common
   denominator for completeness which is the RIPE database
   implementation[15].  Please consult your routing registry for the
   latest specification of these classes and attributes.

3.1 mntner Class

   The mntner class defines entities that can create, delete and update
   RPSL objects.  A provider, before he/she can create RPSL objects,
   first needs to create a mntner object.  The attributes of the mntner
   class are shown in Figure 1.  The mntner class was first described in
   [11].