📄 rfc2622.txt
字号:
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -