rfc2622.txt

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

Network Working Group                                   C. Alaettinoglu
Request for Comments: 2622           USC/Information Sciences Institute
Obsoletes: 2280                                           C. Villamizar
Category: Standards Track                                 Avici Systems
                                                              E. Gerich
                                                        At Home Network
                                                             D. Kessens
                                                   Qwest Communications
                                                               D. Meyer
                                                   University of Oregon
                                                               T. Bates
                                                          Cisco Systems
                                                          D. Karrenberg
                                                               RIPE NCC
                                                            M. Terpstra
                                                           Bay Networks
                                                              June 1999


              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 (1999).  All Rights Reserved.

Abstract

   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.









Alaettinoglu, et al.        Standards Track                     [Page 1]

RFC 2622                          RPSL                         June 1999


Table of Contents

   1 Introduction                                                      3
   2 RPSL Names, Reserved Words, and Representation                    4
   3 Contact Information                                               7
     3.1 mntner Class . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2 person Class . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.3 role Class . . . . . . . . . . . . . . . . . . . . . . . . . 11
   4 route Class                                                      12
   5 Set Classes                                                      13
     5.1 as-set Class . . . . . . . . . . . . . . . . . . . . . . . . 14
     5.2 route-set Class. . . . . . . . . . . . . . . . . . . . . . . 15
     5.3 Predefined Set Objects . . . . . . . . . . . . . . . . . . . 17
     5.4 Filters and filter-set Class . . . . . . . . . . . . . . . . 17
     5.5 rtr-set Class. . . . . . . . . . . . . . . . . . . . . . . . 22
     5.6 Peerings and peering-set Class . . . . . . . . . . . . . . . 24
   6 aut-num Class                                                    27
     6.1 import Attribute:  Import Policy Specification . . . . . . . 27
       6.1.1 Action Specification . . . . . . . . . . . . . . . . . . 28
     6.2 export Attribute:  Export Policy Specification . . . . . . . 29
      6.3 Other Routing Protocols, Multi-Protocol Routing Protocols,
       and Injecting Routes Between Protocols . . . . . . . . . . . . 29
     6.4 Ambiguity Resolution . . . . . . . . . . . . . . . . . . . . 31
     6.5 default Attribute: Default Policy Specification  . . . . . . 33
     6.6 Structured Policy Specification. . . . . . . . . . . . . . . 33
   7 dictionary Class                                                 37
     7.1 Initial RPSL Dictionary and Example Policy Actions and
       Filters. . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
   8 Advanced route Class                                             45
     8.1 Specifying Aggregate Routes. . . . . . . . . . . . . . . . . 45
       8.1.1Interaction with policies in aut-num class. . . . . . . . 49
       8.1.2Ambiguity resolution with overlapping aggregates. . . . . 50
     8.2 Specifying Static Routes . . . . . . . . . . . . . . . . . . 52
   9 inet-rtr Class                                                   52
   10 Extending RPSL                                                  54
     10.1 Extensions by changing the dictionary class . . . . . . . . 54
     10.2 Extensions by adding new attributes to existing classes . . 55
     10.3 Extensions by adding new classes  . . . . . . . . . . . . . 55
     10.4 Extensions by changing the syntax of existing RPSL
        attributes. . . . . . . . . . . . . . . . . . . . . . . . . . 55
   11 Security Considerations                                         56
   12 Acknowledgements                                                56
   References                                                         56
   A Routing Registry Sites                                           59
   B Grammar Rules                                                    59
   C Changes from RFC 2280                                            67
   D Authors' Addresses                                               68
   Full Copyright Statement                                           69



Alaettinoglu, et al.        Standards Track                     [Page 2]

RFC 2622                          RPSL                         June 1999


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 [6] or RFC-1786 [7].  RIPE-81 [8] was the
   first language deployed in the Internet for specifying routing
   policies.  It was later replaced by RIPE-181 [6].  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.

   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, 17, 4] 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



Alaettinoglu, et al.        Standards Track                     [Page 3]

RFC 2622                          RPSL                         June 1999


   "route" class.  Sets of objects can be defined using the "as-set",
   "route-set", "filter-set", "peering-set", and "rtr-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 [6, 13, 16, 12, 5] and
   have all been enhanced.

   This document is self-contained.  However, the reader is encouraged
   to read RIPE-181 [7] and the associated documents [13, 16, 12, 5] 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 [4].

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
   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.  Names starting with "rtrs-" are reserved for router set
      names.  Names starting with "fltr-" are reserved for filter set
      names.  Names starting with "prng-" are reserved for peering set
      names.




Alaettinoglu, et al.        Standards Track                     [Page 4]

RFC 2622                          RPSL                         June 1999


   <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 an optional range operator.  The range operators are:

   ^- 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.

   It is an error to follow a range operator with another one (e.g.
   30.0.0.0/8^24-28^+ is an error).  However, a range operator can be
   applied to an address prefix set that has address prefix ranges in it
   (e.g. {30.0.0.0/8^24-28}^27-30 is not an error).  In this case, the



Alaettinoglu, et al.        Standards Track                     [Page 5]

RFC 2622                          RPSL                         June 1999


   outer operator ^n-m distributes over the inner operator ^k-l and
   becomes the operator ^max(n,k)-m if m is greater than or equal to
   max(n,k), or otherwise, the prefix is deleted from the set.  Note
   that the operator ^n is equivalent to ^n-n; prefix/l^+ is equivalent
   to prefix/l^l-32; prefix/l^- is equivalent to prefix/l^(l+1)-32;
   {prefix/l^n-m}^+ is equivalent to {prefix/l^n-32}; and {prefix/l^n-
   m}^- is equivalent to {prefix/l^(n+1)-32}.  For example,

                {128.9.0.0/16^+}^-     == {128.9.0.0/16^-}
                {128.9.0.0/16^-}^+     == {128.9.0.0/16^-}
                {128.9.0.0/16^17}^24   == {128.9.0.0/16^24}
                {128.9.0.0/16^20-24}^26-28 == {128.9.0.0/16^26-28}
                {128.9.0.0/16^20-24}^22-28 == {128.9.0.0/16^22-28}
                {128.9.0.0/16^20-24}^18-28 == {128.9.0.0/16^20-28}
                {128.9.0.0/16^20-24}^18-22 == {128.9.0.0/16^20-22}
                {128.9.0.0/16^20-24}^18-19 == {}

   <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).  All dates are in UTC unless otherwise
      specified.  For example, June 24, 1996 is represented as 19960624.

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

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

   <nic-handle> is a uniquely assigned identifier word 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.

   <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.



Alaettinoglu, et al.        Standards Track                     [Page 6]

RFC 2622                          RPSL                         June 1999


   An RPSL object is textually represented as a list of attribute-value