Request for Comments: 4012 Merit Network
Updates: 2725, 2622 J. Damas
Category: Standards Track Internet Systems Consortium
F. Parent
Hexago
A. Robachevsky
RIPE NCC
March 2005
Routing Policy Specification Language next generation (RPSLng)
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 (2005).
Abstract
This memo introduces a new set of simple extensions to the Routing
Policy Specification Language (RPSL), enabling the language to
document routing policies for the IPv6 and multicast address families
currently used in the Internet.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specifying routing policy for different address families . . . 2
2.1. Ambiguity Resolution . . . . . . . . . . . . . . . . . . 3
2.2. The afi dictionary attribute . . . . . . . . . . . . . . 3
2.3. RPSL dictionary extensions . . . . . . . . . . . . . . . 4
2.4. IPv6 RPSL types . . . . . . . . . . . . . . . . . . . . 4
2.5. mp-import, mp-export, and mp-default . . . . . . . . . . 4
2.5.1. <mp-peering> . . . . . . . . . . . . . . . . . . 6
2.5.2. <mp-filter> . . . . . . . . . . . . . . . . . . 6
2.5.3. Policy examples . . . . . . . . . . . . . . . . 7
3. route6 Class . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Updates to existing Classes to support the extensions . . . . 8
4.1. as-set Class . . . . . . . . . . . . . . . . . . . . . . 8
4.2. route-set Class . . . . . . . . . . . . . . . . . . . . 9
4.3. filter-set Class . . . . . . . . . . . . . . . . . . . . 9
4.4. peering-set Class . . . . . . . . . . . . . . . . . . . 9
4.5. inet-rtr Class . . . . . . . . . . . . . . . . . . . . . 10
4.6. rtr-set Class . . . . . . . . . . . . . . . . . . . . . 11
5. RFC 2725 Extensions . . . . . . . . . . . . . . . . . . . . . 11
5.1. Authorization model for route6 Objects . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
1. Introduction
RFC 2622 [1] defines the RPSL language for the IPv4 unicast routing
protocols and provides a series of guidelines for extending the RPSL
language itself. Additionally, security extensions to the RPSL
language are specified in RFC 2725 [2].
This document proposes to extend RPSL according to the following
goals and requirements:
o Provide RPSL extensibility in the dimension of address families,
specifically, to allow users to document routing policy for IPv6
and multicast.
o Extensions should be backward compatible with minimal impact on
existing tools and processes, following Section 10 of RFC 2622 [1]
for guidelines on extending RPSL.
o Maintain clarity and non-ambiguity: RPSL information is used by
humans in addition to software tools.
o Minimize duplication of information, particularly when routing
policies for different address families are the same.
The addition of IPv6 and multicast support to RPSL leads to four
distinct routing policies that need to be distinguished in this
specification, namely, (IPv4 {unicast|multicast}, IPv6
{unicast|multicast}).
2. Specifying Routing Policy for Different Address Families
Routing policy is currently specified in the aut-num class using
"import:", "export:", and "default:" attributes. Sometimes it is
important to distinguish policy for different address families, as
well as a unicast routing policy from a multicast one.
Although the syntax of the existing import, export, and default
attributes could be extended, this would present backward
compatibility issues and could undermine clarity in the expressions.
Keeping this in mind, the "import:", "export:", and "default:"
attributes implicitly specify IPv4 unicast policy and will remain as
previously defined in RPSL, and new multi-protocol (prefixed with the
string "mp-") attributes will be introduced. These new "mp-"
attributes are described below.
2.1. Ambiguity Resolution
The same peering can be covered by more than one multi-protocol
policy attribute or by a combination of multi-protocol policy
attributes (when specifying IPv4 unicast policy) and the previously
defined IPv4 unicast policy attributes. In these cases,
implementations should follow the specification-order rule as defined
in Section 6.4 of RFC 2622 [1]. To break the ambiguity, the action
corresponding to the first peering specification is used.
2.2. The afi Dictionary Attribute
This section introduces a new dictionary attribute:
Address Family Identifier, <afi>, is an RPSL list of address families
for which a given routing policy expression should be evaluated.
<afi> is optional within the new multi-protocol attributes introduced
in the aut-num class. A pseudo identifier named "any" is defined to
allow for more compact policy expressions with converged routing
policy.
The possible values for <afi> are as follows:
ipv4.unicast
ipv4.multicast
ipv4 (equivalent to ipv4.unicast, ipv4.multicast)
ipv6.unicast
ipv6.multicast
ipv6 (equivalent to ipv6.unicast, ipv6.multicast)
any (equivalent to ipv4, ipv6)
any.unicast (equivalent to ipv4.unicast, ipv6.unicast)
any.multicast (equivalent to ipv4.multicast, ipv6.multicast)
Appearance of these values in an attribute must be preceded by the
keyword afi.
An <afi-list> is defined as a comma-separated list of one or more afi
values.
2.3. RPSL Dictionary Extensions
In order to support IPv6 addresses specified with the next-hop rp-
attribute, a new predefined dictionary type entitled "ipv6_address"
is added to the RPSL dictionary. The definition of this type is
taken from Section 2.2 of RFC 3513 [3].
The next-hop rp-attribute is expanded in the dictionary as follows:
rp-attribute: # next hop router in a static route
next-hop
operator=(union ipv4_address, ipv6_address, enum[self])
A new value has been added for the <protocol> dictionary
specification:
MPBGP
MPBGP is understood to be BGP4 with multi-protocol extensions (often
referred to as BGP4+). BGP4+ could not be used, as the ’+’ character
is not allowed by the RPSL specification in protocol names.
2.4. IPv6 RPSL Types
This document will reference three new IPv6 RPSL types, namely,
<ipv6-address>, <ipv6-address-prefix>, and <ipv6-address-prefix-
range>. The <ipv6-address> and <ipv6-address-prefix> types are
defined in Sections 2.2 and 2.3 of RFC 3513 [3]. The <ipv6-address-
prefix-range> type adds a range operator to the <ipv6-address-prefix>
type. The range operator is defined in Section 2 of RFC 2622 [1].
2.5. mp-import, mp-export, and mp-default
Three new policy attributes are introduced in the aut-num Class:
mp-import:
mp-export:
mp-default:
These attributes incorporate the afi (address-family) specification.
Note that the afi specification is optional. If no afi specification
is present, the policy expression is presumed to apply to all
protocol families, namely, ipv4.unicast, ipv4.multicast,
ipv6.unicast, and ipv6.multicast. This is the equivalent of the afi
specification "afi any". The mp-import and mp-export attributes have
both a basic policy specification and a more powerful structured
policy specification.
The syntax for the mp-default attribute and the basic policy
specification of the mp-import and mp-export attributes is as
follows:
Attribute Value Type
mp-import [protocol <protocol-1>] [into <protocol-2>] optional,
[afi <afi-list>] multi-valued
from <mp-peering-1> [action <action-1>; ... <action-N>;]
. . .
from <mp-peering-M> [action <action-1>; ... <action-N>;]
accept <mp-filter> [;]
mp-export [protocol <protocol-1>] [into <protocol-2>] optional,
[afi <afi-list>] multi-valued
to <mp-peering-1> [action <action-1>; ... <action-N>;]
. . .
to <mp-peering-M> [action <action-1>; ... <action-N>;]
announce <mp-filter> [;]
mp-default [afi <afi-list>] to <mp-peering> optional,
[action <action-1>; ... <action-N>;] multi-valued
[networks <mp-filter>]
The mp-import and mp-export policies can be structured. As with RFC
2622 [1], structured policies are recommended only to advanced RPSL
users. The mp-import structured policy syntax is defined below.
Please note the semicolon at the end of an <import-factor> is
mandatory for structured policy expressions, while being optional on
non-structured policy expressions. The mp-export structured policy
syntax is expressed symmetrically to the mp-import attribute. The
structured syntax allows exceptions and refinements to policies by
use of the "except" and "refine" keywords. Further, the exceptions
and refinements may specify an optional "afi" list to restrict the
policy expression to particular address families.
Note that the definition allows subsequent or "cascading" refinements
and exceptions. RFC 2622 [1] incorrectly refers to these as "nested"
expressions. The syntax does not allow true nested expressions.
<import-factor> ::=
from <mp-peering-1> [action <action-1>; ... <action-M>;]
. . .
from <mp-peering-N> [action <action-1>; ... <action-K>;]
accept <mp-filter>;
<import-term> :: = import-factor |
{
<import-factor-1>
. . .
<import-factor-N>
}
<import-expression> ::= <import-term> |
<import-term> EXCEPT <afi-import-expression> |
<import-term> REFINE <afi-import-expression>
<afi-import-expression> ::= [afi <afi-list>] <import-expression>
mp-import: [protocol <protocol-1>] [into <protocol-2>]
<afi-import-expression>
2.5.1. <mp-peering>
<mp-peering> indicates the AS (and the router if present) and is
defined as follows:
<mp-peering> ::= <as-expression> [<mp-router-expression-1>]
[at <mp-router-expression-2>] | <peering-set-name>
where <as-expression> is an expression over AS numbers and AS sets
using operators AND, OR, and EXCEPT, and <mp-router-expression> is an
expression over router ipv4-addresses or ipv6-addresses, inet-rtr
names, and rtr-set names using operators AND, OR, and EXCEPT. The
binary "EXCEPT" operator is the set subtraction operator and has the
same precedence as the operator AND (it is semantically equivalent to
"AND NOT" combination). That is, "(AS65001 OR AS65002) EXCEPT
AS65002" equals "AS65001".
2.5.2. <mp-filter>
The <mp-filter> policy filter expression is derived from the RPSL
<filter> policy filter expression defined in section 5.4 of RFC 2622
[1]. <mp-filter> extends the <filter> expression to allow the
specification of IPv6 prefixes and prefix ranges. In particular, an
Address-Prefix Set expression in an <mp-filter> expression may
include both IPv4 and IPv6 prefixes or prefix ranges. <mp-filter> is
otherwise identical to the RPSL <filter> expression. Address-Prefix
Sets are enclosed in braces, ’{’ and ’}’. The policy filter matches
the set of routes whose destination address-prefix is in the set.
For example:
{ 192.0.2.0/24, 2001:0DB8::/32 }
{ 2001:0DB8:0100::/48^+, 2001:0DB8:0200::/48^64 }
2.5.3. Policy Examples
The address family may be specified in subsequent refine or except
policy expressions and is valid only within the policy expression
that contains it.
Therefore, in the example
aut-num: AS65534
mp-import: afi any.unicast from AS65001 accept as-foo;
except afi any.unicast {
from AS65002 accept AS65226;
} except afi ipv6.unicast {
from AS65003 accept {2001:0DB8::/32};
}
the last "except" is evaluated only for the IPv6 unicast address
family, while other import-expressions are evaluated for both the
IPv6 and IPv4 unicast address families.
The evaluation of a policy expression is done by evaluating each of
its components. Evaluation of peering-sets and filter-sets is
constrained by the address family. Such constraints may result in a
"NOT ANY" <mp-filter> or invalid <mp-peering> depending on implicit
or explicit definitions of the address family in the set. Conflicts
with explicit or implicit declarations are resolved at runtime during
the evaluation of a policy expression. An RPSL evaluation
implementation may wish to issue a warning in the case of a "NOT ANY"
<mp-filter>. The following mp-import policy contains an example of
an <mp-filter> that should be evaluated as "NOT ANY":
aut-num: AS65002
mp-import: afi ipv6.unicast from AS65001 accept {192.0.2.0/24}
3. route6 Class
The route6 class is the IPv6 equivalent of the route class. As with
the route class, the class key for the route6 class is specified by
the route6 and origin attribute pair. Other than the route6
attribute, the route6 class shares the same attribute names with the
route class. Although the attribute names remain identical, the
inject, components, exports-comps, holes, and mnt-routes attributes
must specify IPv6 prefixes and addresses rather than IPv4 prefixes
and addresses. This requirement is reflected by the specification of
<ipv6-router-expression>, <ipv6-filter>, and <ipv6-address-prefix>
below. <ipv6-address-prefix> has been previously defined. <ipv6-
filter> is related to <mp-filter> as defined above in Section 2.5.2,
with the exception that only <ipv6-address-prefix> types are
permitted. Similarly, <ipv6-router-expression> is related to
<mp-router-expression> as defined above in Section 2.5.1 with the
exception that only <ipv6-address> types are permitted.
Attribute Value Type
route6 <ipv6-address-prefix> mandatory, class key,
single-valued
origin <as-number> mandatory, class key,
single-valued
member-of list of <route-set-name> optional, multi-valued
inject [at <ipv6-router-expression>] ... optional, multi-valued
[action <action>]
[upon <condition>]
components [ATOMIC] [[<ipv6-filter>] optional, single-valued
[protocol <protocol> <ipv6-filter> ...]]
aggr-bndry <as-expression> optional, single-valued
aggr-mtd inbound or outbound optional, single-valued
[<as-expression>]
export-comps <ipv6-filter> optional, single-valued
holes list of <ipv6-address-prefix> optional, multi-valued
mnt-lower list of <mntner-name> optional, multi-valued
mnt-routes list of <mntner-name> optional, multi-valued
[{list of <ipv6-address-prefix-range>} or ANY]
Example:
route6: 2001:0DB8::/32
origin: AS65001
4. Updates to Existing Classes to Support the Extensions
4.1. as-set Class
The as-set class defines a set of Autonomous Systems (AS), specified
either directly by listing them in the members attribute or
indirectly by referring to another as-set or using the mbrs-by-ref
facility. More importantly, "In a context that expects a route set
(e.g., members attribute of the route-set class), [...] an as-set
AS-X defines the set of routes that are originated by the ASes in
AS-X", (section 5.3 of RFC 2622 [1]).
The as-set class is therefore used to collect a set of route
prefixes, which may be restricted to a specific address family.
The existing as-set class does not need any modifications. The
evaluation of the class must be filtered to obtain prefixes belonging
to a particular address family using the traditional filtering
mechanism in use in Internet Routing Registry (IRR) systems today.
4.2. route-set Class
This class is used to specify a set of route prefixes.
A new attribute "mp-members:" is defined for this class. This
attribute allows the specification of IPv4 or IPv6
address-prefix-ranges.
Attribute Value Type
mp-members list of (<ipv4-address-prefix-range> optional, multi-valued
or <ipv6-address-prefix-range>
or <route-set-name>
or <route-set-name><range-operator>)
Example:
route-set: rs-foo
mp-members: rs-bar
mp-members: 2001:0DB8::/32 # v6 member
mp-members: 192.0.2.0/24 # v4 member
4.3. filter-set Class
The new "mp-filter:" attribute defines the set’s policy filter. A
policy filter is a logical expression that when applied to a set of
routes returns a subset of these routes. The relevant parts of the
updated filter-set class are shown below:
Attribute Value Type
filter-set <object-name> mandatory, single-valued, class key
filter <filter> optional, single-valued
mp-filter <mp-filter> optional, single-valued
Where <mp-filter> is defined above in Section 2.5.2. While the
"filter:" and "mp-filter:" attributes are of type "optional", a
filter-set must contain one of these two attributes. Implementations
should reject instances where both attributes are defined in an
object, as the interpretation of such a filter-set is undefined.
4.4. peering-set Class
The peering set class is updated with a "mp-peering:" attribute.
Attribute Value Type
peering-set <object-name> mandatory, single-valued, class key
peering <peering> optional, multi-valued
mp-peering <mp-peering> optional, multi-valued
Example:
peering-set: prng-ebgp-peers
mp-peering: AS65002 2001:0DB8::1 at 2001:0DB8::2
With <mp-peering> defined as above in Section 2.5.1. While the
"peering:" and "mp-peering:" attributes are of type "optional", a
peering-set must contain at least one of these two attributes.
4.5. inet-rtr Class
Two new attributes are introduced to the inet-rtr class --
"interface:", which allows the definition of generic interfaces,
including the information previously contained in the "ifaddr:"
attribute, as well as support for tunnel definitions; and "mp-
peer:", which includes and extends the functionality of the existing
"peer:" attribute. The syntax definition for the "interface:"
attribute follows:
Attribute Value Type
interface <ipv4-address> or <ipv6-address> optional, multi-valued
masklen <mask>
[action <action>]
[tunnel <remote-endpoint-address>,<encapsulation>]
The syntax allows native IPv4 and IPv6 interface definitions, as well
as the definition of tunnels as virtual interfaces. Without the
optional tunnel definition, this attribute allows the same
functionality as the "ifaddr:" attribute but extends it to allow IPv6
addresses.
If the interface is a tunnel, the syntax is as follows:
<remote-endpoint-address> indicates the IPv4 or IPv6 address of the
remote endpoint of the tunnel. The address family must match that of
the local endpoint. <encapsulation> denotes the encapsulation used
in the tunnel and is one of {GRE,IPinIP} (note that the outer and
inner IP protocol versions can be deduced from the interface context
-- for example, IPv6-in-IPv4 encapsulation is just IPinIP). Routing
policies for these routers should be described in the appropriate
classes (e.g., aut-num).
The "mp-peer:" attribute is defined below. The difference between
this attribute and the "peer:" attribute is the inclusion of support
for IPv6 addresses.
Attribute Value Type