Network Working Group L. Blunk
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
Network Working Group L. Blunk
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)
下一代路由策略规范语言（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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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.
此备忘录为路由策略规范语言（RPSL）引入了一组新的简单扩展，使该语言能够记录当前在Internet中使用的IPv6和多播地址系列的路由策略。
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
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
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
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].
RFC 2622[1]定义了IPv4单播路由协议的RPSL语言，并为扩展RPSL语言本身提供了一系列指南。此外，RFC 2725[2]中规定了RPSL语言的安全扩展。
This document proposes to extend RPSL according to the following goals and requirements:
本文件建议根据以下目标和要求扩展RPSL：
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.
o 在地址族维度中提供RPSL扩展性，特别是允许用户记录IPv6和多播的路由策略。o根据RFC 2622[1]第10节关于扩展RPSL的指南，扩展应向后兼容，对现有工具和流程的影响最小。o保持清晰和不含糊：RPSL信息除软件工具外，还可供人类使用。o最大限度地减少信息重复，特别是当不同地址系列的路由策略相同时。
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}).
在RPSL中添加IPv6和多播支持将导致在本规范中需要区分的四种不同路由策略，即（IPv4{unicast|multicast}，IPv6{unicast|multicast}）。
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.
当前在aut num类中使用“导入：”、“导出：”、“默认：”属性指定路由策略。有时，区分不同地址族的策略以及单播路由策略和多播路由策略很重要。
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.
记住这一点，“import:”、“export:”和“default:”属性隐式指定IPv4单播策略，并将保持先前在RPSL中定义的状态，并且将引入新的多协议（前缀为字符串“mp-”）属性。这些新的“mp-”属性如下所述。
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.
同一对等可以由多个多协议策略属性覆盖，也可以由多协议策略属性（指定IPv4单播策略时）和先前定义的IPv4单播策略属性的组合覆盖。在这些情况下，实现应遵循RFC 2622[1]第6.4节中定义的规范顺序规则。为了消除歧义，使用与第一个对等规范对应的动作。
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.
地址族标识符，<afi>，是一个RPSL地址族列表，其中应计算给定路由策略表达式<afi>在aut num类中引入的新多协议属性中是可选的。定义了一个名为“any”的伪标识符，以允许使用聚合路由策略实现更紧凑的策略表达式。
The possible values for <afi> are as follows:
<afi>的可能值如下：
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)
ipv4.unicast ipv4.multicast ipv4（等效于ipv4.unicast，ipv4.multicast）ipv6.multicast ipv6（等效于ipv6.unicast，ipv6.multicast）any（等效于ipv4，ipv6）any.unicast（等效于ipv4.unicast，ipv6.unicast）any.multicast（等效于ipv4.multicast，ipv6.multicast）
Appearance of these values in an attribute must be preceded by the keyword afi.
属性中这些值的外观必须以关键字afi开头。
An <afi-list> is defined as a comma-separated list of one or more afi values.
<afi列表>定义为一个或多个afi值的逗号分隔列表。
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].
为了支持使用next hop rp属性指定的IPv6地址，将在RPSL字典中添加一个名为“IPv6_地址”的新预定义字典类型。该类型的定义取自RFC 3513[3]第2.2节。
The next-hop rp-attribute is expanded in the dictionary as follows:
下一个跃点rp属性在字典中展开，如下所示：
rp-attribute: # next hop router in a static route next-hop operator=(union ipv4_address, ipv6_address, enum[self])
rp属性：#静态路由中的下一跳路由器下一跳运算符=（联合ipv4_地址、ipv6_地址、枚举[self]）
A new value has been added for the <protocol> dictionary specification: MPBGP
为<protocol>字典规范添加了一个新值：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.
MPBGP被理解为具有多协议扩展的BGP4（通常称为BGP4+）。无法使用BGP4+，因为RPSL规范不允许在协议名称中使用“+”字符。
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].
本文档将引用三种新的IPv6 RPSL类型，即<IPv6地址>、<IPv6地址前缀>、和<IPv6地址前缀范围>。RFC 3513[3]第2.2节和第2.3节定义了<ipv6地址>和<ipv6地址前缀>类型。<ipv6地址前缀范围>类型向<ipv6地址前缀>类型添加范围运算符。RFC 2622[1]第2节定义了范围运算符。
Three new policy attributes are introduced in the aut-num Class:
aut num类中引入了三个新策略属性：
mp-import: mp-export: mp-default:
mp导入：mp导出：mp默认值：
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.
这些属性包含afi（地址系列）规范。请注意，afi规范是可选的。如果不存在afi规范，则假定策略表达式适用于所有协议系列，即ipv4.unicast、ipv4.multicast、ipv6.unicast和ipv6.multicast。这相当于afi规范“afi any”。mp导入和mp导出属性具有基本策略规范和更强大的结构化策略规范。
The syntax for the mp-default attribute and the basic policy specification of the mp-import and mp-export attributes is as follows:
mp导入和mp导出属性的mp default属性和基本策略规范的语法如下：
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> [;]
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-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>]
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.
mp导入和mp导出策略可以结构化。与RFC 2622[1]一样，结构化策略仅推荐给高级RPSL用户。mp导入结构化策略语法定义如下。请注意，<import factor>末尾的分号对于结构化策略表达式是必需的，而对于非结构化策略表达式是可选的。mp导出结构化策略语法与mp导入属性对称表示。结构化语法允许使用“Exception”和“refine”关键字对策略进行例外和优化。此外，例外和改进可以指定可选的“afi”列表，以将策略表达式限制到特定的地址族。
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.
请注意，该定义允许后续或“级联”细化和异常。RFC 2622[1]错误地将这些表达式称为“嵌套”表达式。该语法不允许使用真正的嵌套表达式。
<import-factor> ::=
from <mp-peering-1> [action <action-1>; ... <action-M>;]
. . .
from <mp-peering-N> [action <action-1>; ... <action-K>;]
accept <mp-filter>;
<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-term> :: = import-factor |
{
<import-factor-1>
. . . <import-factor-N> }
. . . <导入因子N>}
<import-expression> ::= <import-term> |
<import-term> EXCEPT <afi-import-expression> |
<import-term> REFINE <afi-import-expression>
<import-expression> ::= <import-term> |
<import-term> EXCEPT <afi-import-expression> |
<import-term> REFINE <afi-import-expression>
<afi-import-expression> ::= [afi <afi-list>] <import-expression>
<afi-import-expression> ::= [afi <afi-list>] <import-expression>
mp-import: [protocol <protocol-1>] [into <protocol-2>]
<afi-import-expression>
mp-import: [protocol <protocol-1>] [into <protocol-2>]
<afi-import-expression>
<mp-peering> indicates the AS (and the router if present) and is defined as follows:
<mp peering>表示AS（以及路由器，如果存在），定义如下：
<mp-peering> ::= <as-expression> [<mp-router-expression-1>]
[at <mp-router-expression-2>] | <peering-set-name>
<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".
其中，<as expression>是使用运算符and、OR和EXCEPT的as编号和as集上的表达式，<mp router expression>是使用运算符and、OR和EXCEPT的路由器ipv4地址或ipv6地址、inet rtr名称和rtr集名称上的表达式。二进制“EXCEPT”运算符是集合减法运算符，其优先级与运算符and相同（在语义上等同于“and NOT”组合）。即，“（AS65001或AS65002）除AS65002外”等于“AS65001”。
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:
<mp filter>策略筛选器表达式源自RFC 2622[1]第5.4节中定义的RPSL<filter>策略筛选器表达式<mp filter>扩展了<filter>表达式，以允许指定IPv6前缀和前缀范围。具体而言，<mp filter>表达式中的地址前缀集表达式可以包括IPv4和IPv6前缀或前缀范围<mp filter>在其他方面与RPSL<filter>表达式相同。地址前缀集用大括号“{”和“}”括起来。策略筛选器匹配目标地址前缀位于该集合中的路由集合。例如：
{ 192.0.2.0/24, 2001:0DB8::/32 }
{ 2001:0DB8:0100::/48^+, 2001:0DB8:0200::/48^64 }
{ 192.0.2.0/24, 2001:0DB8::/32 }
{ 2001:0DB8:0100::/48^+, 2001:0DB8:0200::/48^64 }
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};
}
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.
最后一个“except”仅针对IPv6单播地址族求值，而其他导入表达式则同时针对IPv6和IPv4单播地址族求值。
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":
策略表达式的计算是通过计算其每个组件来完成的。对等集和筛选器集的计算受地址族的约束。根据集合中地址族的隐式或显式定义，此类约束可能导致“非任何”<mp filter>或无效的<mp peering>。与显式或隐式声明的冲突将在运行时策略表达式求值期间解决。RPSL评估实现可能希望在出现“notany”<mp filter>的情况下发出警告。以下mp导入策略包含一个应评估为“非任何”的<mp筛选器>示例：
aut-num: AS65002
mp-import: afi ipv6.unicast from AS65001 accept {192.0.2.0/24}
aut-num: AS65002
mp-import: afi ipv6.unicast from AS65001 accept {192.0.2.0/24}
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
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.
被允许类似地，<ipv6路由器表达式>与上文第2.5.1节中定义的<mp路由器表达式>相关，但仅允许<ipv6地址>类型。
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]
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:
Example:translate error, please retry
route6: 2001:0DB8::/32
origin: AS65001
route6: 2001:0DB8::/32
origin: AS65001
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]).
as set类定义了一组自治系统（as），通过在members属性中直接列出它们来指定，或者通过引用另一个as set或使用mbrs by ref工具间接指定。更重要的是，“在需要路由集（例如，路由集类的members属性）的上下文中，[…]as集as-X定义了as-X中ASE发起的路由集”（RFC 2622[1]第5.3节）。
The as-set class is therefore used to collect a set of route prefixes, which may be restricted to a specific address family.
因此，as set类用于收集一组路由前缀，这些前缀可能仅限于特定的地址族。
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.
现有的as set类不需要任何修改。必须使用当前Internet路由注册（IRR）系统中使用的传统过滤机制对类的计算进行过滤，以获得属于特定地址族的前缀。
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.
为此类定义了一个新属性“mp members:”。此属性允许指定IPv4或IPv6地址前缀范围。
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>)
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
route-set: rs-foo
mp-members: rs-bar
mp-members: 2001:0DB8::/32 # v6 member
mp-members: 192.0.2.0/24 # v4 member
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:
新的“mp filter:”属性定义集合的策略筛选器。策略筛选器是一个逻辑表达式，当应用于一组路由时，它将返回这些路由的子集。更新后的过滤器集类的相关部分如下所示：
Attribute Value Type
filter-set <object-name> mandatory, single-valued, class key
filter <filter> optional, single-valued
mp-filter <mp-filter> optional, single-valued
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.
其中，上文第2.5.2节定义了<mp过滤器>。虽然“filter:”和“mp filter:”属性属于“可选”类型，但筛选器集必须包含这两个属性之一。实现应该拒绝在对象中定义两个属性的实例，因为这样的过滤器集的解释是未定义的。
The peering set class is updated with a "mp-peering:" attribute.
对等集类更新为“mp peering:”属性。
Attribute Value Type
peering-set <object-name> mandatory, single-valued, class key
peering <peering> optional, multi-valued
mp-peering <mp-peering> optional, multi-valued
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
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.
具有上文第2.5.1节中定义的<mp对等>。虽然“对等：”和“mp对等：”属性属于“可选”类型，但对等集必须至少包含这两个属性中的一个。
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:
inet rtr类引入了两个新属性--“interface:”，它允许定义通用接口，包括先前包含在“ifaddr:”属性中的信息，以及对隧道定义的支持；和“mp peer:”，其中包括并扩展了现有“peer:”属性的功能。“接口：”属性的语法定义如下：
Attribute Value Type
interface <ipv4-address> or <ipv6-address> optional, multi-valued
masklen <mask>
[action <action>]
[tunnel <remote-endpoint-address>,<encapsulation>]
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.
该语法允许本机IPv4和IPv6接口定义，以及将隧道定义为虚拟接口。在没有可选的隧道定义的情况下，此属性允许与“ifaddr:”属性相同的功能，但将其扩展为允许IPv6地址。
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).
<remote endpoint address>表示隧道远程端点的IPv4或IPv6地址。地址族必须与本地终结点的地址族匹配<封装>表示隧道中使用的封装，是{GRE，IPinIP}中的一个（注意，外部和内部IP协议版本可以从接口上下文推断出来——例如，IPv6-in-IPv4封装就是IPinIP）。这些路由器的路由策略应在适当的类别中描述（例如，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.
“mp peer:”属性定义如下。此属性与“对等：”属性之间的区别在于包含了对IPv6地址的支持。
Attribute Value Type
mp-peer <protocol> <ipv4-address> <options> or optional,
<protocol> <ipv6-address> <options> or multi-valued
<protocol> <inet-rtr-name> <options> or
<protocol> <rtr-set-name> <options> or
<protocol> <peering-set-name> <options>
Attribute Value Type
mp-peer <protocol> <ipv4-address> <options> or optional,
<protocol> <ipv6-address> <options> or multi-valued
<protocol> <inet-rtr-name> <options> or
<protocol> <rtr-set-name> <options> or
<protocol> <peering-set-name> <options>
where <protocol> is a protocol name, and <options> is a comma-separated list of peering options for <protocol>, as provided in the RPSL dictionary.
其中，<protocol>是协议名，<options>是RPSL字典中提供的<protocol>对等选项的逗号分隔列表。
The rtr-set class is extended with a new attribute, "mp-members:". This attribute extends the original "members:" attribute by allowing the specification of IPv6 addresses. It is defined as follows:
rtr集合类通过一个新属性“mp members:”进行了扩展。此属性通过允许指定IPv6地址来扩展原始的“members:”属性。其定义如下：
Attribute Value Type
mp-members list of (<inet-rtr-name> or optional, multi-valued
<rtr-set-name> or
<ipv4-address> or
<ipv6-address>)
Attribute Value Type
mp-members list of (<inet-rtr-name> or optional, multi-valued
<rtr-set-name> or
<ipv4-address> or
<ipv6-address>)
RFC 2725 [2] introduces an authorization model to address the integrity of policy expressed in routing registries. Two new attributes were defined to support this authorization model: the "mnt-routes" and "mnt-lower" attributes.
RFC 2725[2]引入了一个授权模型，以解决路由注册表中表示的策略的完整性问题。定义了两个新属性以支持此授权模型：“mnt路由”和“mnt较低”属性。
In RPSLng, these attributes are extended to the route6 and inet6num (described below) classes. Further, the syntax of the existing mnt-routes attribute is modified to allow the optional specification of IPv6 prefix range lists when present in inet6num, route6, and aut-num class objects. This optional list of prefix ranges is a comma-separated list enclosed in curly braces. In the aut-num class, the IPv6 prefix ranges may be mixed with IPv4 prefix ranges. The keyword "ANY" may also be used instead of prefix ranges. In the case of inet6num and route6 objects, "ANY" refers to all more specifics of the prefix in the class key field. For the aut-num class, "ANY" literally means any prefix. The default when no additional set items are specified is "ANY". An abbreviated definition of the aut-num class with the updated syntax for the mnt-routes attribute is presented below.
在RPSLng中，这些属性被扩展到route6和inet6num（如下所述）类。此外，修改了现有mnt routes属性的语法，以允许在inet6num、route6和aut num类对象中存在IPv6前缀范围列表的可选规范。前缀范围的可选列表是一个逗号分隔的列表，用大括号括起来。在aut num类中，IPv6前缀范围可能与IPv4前缀范围混合。也可以使用关键字“ANY”代替前缀范围。对于inet6num和route6对象，“ANY”指的是类键字段中前缀的所有更多细节。对于aut num类，“ANY”字面上是指任何前缀。未指定其他集合项时的默认值为“ANY”。下面给出了aut num类的缩写定义以及mnt routes属性的更新语法。
Attribute Value Type
aut-num <as-number> mandatory, class key,
single-valued
mnt-routes list of <mntner-name> optional, multi-valued
[{list of (<ipv6-address-prefix-range> or
<ipv4-address-prefix-range>)} or ANY]
Attribute Value Type
aut-num <as-number> mandatory, class key,
single-valued
mnt-routes list of <mntner-name> optional, multi-valued
[{list of (<ipv6-address-prefix-range> or
<ipv4-address-prefix-range>)} or ANY]
The following is an example of mnt-routes usage. This example authorizes MAINT-65001 to create route6 objects with an origin AS of 65002 for IPv6 address prefixes within the 2001:0DB8::/32^+ range, and route objects with origin AS 65002 for IPv4 prefixes within the 192.0.2.0/24^+ range.
以下是mnt路由使用的示例。此示例授权MAINT-65001为2001:0DB8:：/32^+范围内的IPv6地址前缀创建原点为65002的route6对象，并为192.0.2.0/24^+范围内的IPv4前缀创建原点为65002的route对象。
aut-num: AS65002
mnt-routes: MAINT-AS65001 {2001:0DB8::/32^+, 192.0.2.0/24^+}
aut-num: AS65002
mnt-routes: MAINT-AS65001 {2001:0DB8::/32^+, 192.0.2.0/24^+}
Note, that the inclusion of IPv6 prefix ranges within a mnt-routes attribute in an aut-num object may conflict with existing implementations of RPSL that support only IPv4 prefix ranges. However, given the perceived lack of implementation of this optional prefix range list, it was considered more acceptable to extend the existing definition of the mnt-routes attribute in the aut-num class rather than to create a new attribute type.
请注意，在aut num对象的mnt ROTES属性中包含IPv6前缀范围可能与仅支持IPv4前缀范围的现有RPSL实现冲突。然而，考虑到该可选前缀范围列表的实现不足，扩展aut num类中mnt ROTES属性的现有定义比创建新属性类型更为可取。
Attribute Value Type
inet6num <ipv6-address-prefix> mandatory, single-valued,
class key
netname <netname> mandatory, single-valued
descr <free-form> mandatory, multi-valued
country <country-code> mandatory, multi-valued
admin-c <nic-handle> mandatory, multi-valued
tech-c <nic-handle> mandatory, multi-valued
remarks <free-form> optional, multi-valued
notify <email-address> 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]
mnt-by list of <mntner-name> mandatory, multi-valued
changed <email-address> <date> mandatory, multi-valued
source <registry-name> mandatory, single-valued
Attribute Value Type
inet6num <ipv6-address-prefix> mandatory, single-valued,
class key
netname <netname> mandatory, single-valued
descr <free-form> mandatory, multi-valued
country <country-code> mandatory, multi-valued
admin-c <nic-handle> mandatory, multi-valued
tech-c <nic-handle> mandatory, multi-valued
remarks <free-form> optional, multi-valued
notify <email-address> 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]
mnt-by list of <mntner-name> mandatory, multi-valued
changed <email-address> <date> mandatory, multi-valued
source <registry-name> mandatory, single-valued
The <country-code> must be a valid two-letter ISO 3166 country code identifier. <netname> is a symbolic name for the specified IPv6 address space. It does not have a restriction on RPSL reserved prefixes. These definitions are taken from the RIPE Database Reference Manual [4].
<country code>必须是有效的双字母ISO 3166国家代码标识符<netname>是指定IPv6地址空间的符号名称。它对RPSL保留前缀没有限制。这些定义摘自《成熟数据库参考手册》[4]。
Deletion and update of a route6 object is not different from other objects, as defined in RFC 2725 [2]. Creation rules of a route6 object is replicated here from the corresponding rules for route object in RFC 2725 [2] section 9.9.
route6对象的删除和更新与RFC 2725[2]中定义的其他对象没有区别。route6对象的创建规则从RFC 2725[2]第9.9节中相应的route对象规则复制而来。
When a route6 object is added, the submission must satisfy two authentication criteria. It must match the authentication specified in the aut-num object and that specified in either a route6 object or, if no applicable route6 object is found, an inet6num object.
添加route6对象时，提交必须满足两个身份验证标准。它必须与aut num对象中指定的身份验证和route6对象中指定的身份验证相匹配，如果找不到适用的route6对象，则与inet6num对象中指定的身份验证相匹配。
An addition is submitted with an AS number and IPv6 prefix as its key. If the aut-num object does not exist on a route6 to add, then the addition is rejected. If the aut-num exists, then the submission is checked against the applicable maintainers. A search is then done for the prefix, looking first for an exact match and then, failing that, for the longest prefix match less specific than the prefix specified. If this search succeeds, it will return one or more route6 objects. The submission must match an applicable maintainer in at least one of these route6 objects for the addition to succeed. If the search for a route6 object fails, then a search is performed for an inet6num object that exactly matches the prefix, or for the most specific inet6num less specific than the route6 object submission.
以AS编号和IPv6前缀作为密钥提交添加。如果要添加的route6上不存在aut num对象，则拒绝添加。如果aut num存在，则根据适用的维护人员检查提交。然后对前缀进行搜索，首先查找精确匹配，如果不匹配，则查找比指定前缀更不具体的最长前缀匹配。如果此搜索成功，它将返回一个或多个route6对象。提交必须至少在其中一个route6对象中与适用的维护人员匹配，添加才能成功。如果对route6对象的搜索失败，则会搜索与前缀完全匹配的inet6num对象，或者搜索比route6对象更具体的inet6num对象。
Once the aut-num and either a list of route6 objects or an inet6num is found, the authorization is taken from these objects. The applicable maintainer object is any referenced by the mnt-routes attributes. If one or more mnt-routes attributes are present in an object, the mnt-by or mnt-lower attributes are not considered. In the absence of a mnt-routes attribute in a given object, the first mnt-lower attributes are used (only if the given object is an inet6num object and it is less specific than the route6 object to be added). If no applicable mnt-lower attribute is found, then the mnt-by attributes are used for that object. The authentication must match one of the authorizations in each of the two objects.
一旦找到aut num和route6对象列表或inet6num，就会从这些对象获取授权。适用的maintainer对象是mnt routes属性引用的任何对象。如果对象中存在一个或多个mnt路由属性，则不考虑mnt by或mnt lower属性。在给定对象中没有mnt routes属性的情况下，将使用第一个mnt lower属性（仅当给定对象是inet6num对象且其特定性低于要添加的route6对象时）。如果未找到适用的mnt lower属性，则该对象将使用mnt by属性。身份验证必须与两个对象中的每个对象中的一个授权相匹配。
This document describes extensions to RFC 2622 [1] and RFC 2725 [2]. The extensions address the limitations of the aforementioned documents with respect to IPv6 and multicast. The extensions do not introduce any new security functionality or threats.
本文档描述了对RFC 2622[1]和RFC 2725[2]的扩展。这些扩展解决了上述文档在IPv6和多播方面的局限性。这些扩展没有引入任何新的安全功能或威胁。
Although the extensions introduce no additional security threats, it should be noted that the original RFC 2622 [1] RPSL standard included several weak and/or vulnerable authentication mechanisms: first, the "MAIL-FROM" scheme, which can be easily defeated via source email address spoofing; second, the "CRYPT-PW" scheme, which is subject to dictionary attacks and password sniffing if RPSL objects are submitted via unencrypted channels such as email; and, finally, the "NONE" mechanism, which offers no protection for objects.
虽然这些扩展没有引入额外的安全威胁，但应该注意，原始RFC 2622[1]RPSL标准包括几个弱和/或易受攻击的身份验证机制：首先，“邮件发件人”方案，可以通过源电子邮件地址欺骗轻松击败；第二，“CRYPT-PW”方案，如果RPSL对象是通过电子邮件等未加密渠道提交的，则会受到字典攻击和密码嗅探；最后是“无”机制，它不为对象提供保护。
The authors wish to thank all the people who have contributed to this document through numerous discussions, particularly Ekaterina Petrusha, for highly valuable discussions and suggestions: Shane Kerr, Engin Gunduz, Marc Blanchet, and David Kessens who participated constructively in many discussions and Cengiz Alaettinoglu, who is still the reference in all things RPSL.
作者希望感谢通过多次讨论为本文件做出贡献的所有人，特别是Ekaterina Petrusha，感谢他们提供了非常有价值的讨论和建议：Shane Kerr、Engin Gunduz、Marc Blanchet和David Kessens，他们建设性地参与了许多讨论，并提出了许多建议，他仍然是所有RPSL的参考人。
[1] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999.
[1] Alaettinoglu，C.，Villamizar，C.，Gerich，E.，Kessens，D.，Meyer，D.，Bates，T.，Karrenberg，D.，和M.Terpstra，“路由策略规范语言（RPSL）”，RFC 2622，1999年6月。
[2] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy, "Routing Policy System Security", RFC 2725, December 1999.
[2] Villamizar，C.，Alaettinoglu，C.，Meyer，D.，和S.Murphy，“路由策略系统安全”，RFC 27251999年12月。
[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[3] Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[4] Damas, J. and A. Robachevsky, "RIPE Database Reference Manual", August 2002.
[4] Damas，J.和A.Robachevsky，“成熟数据库参考手册”，2002年8月。
Authors' Addresses
作者地址
Larry Blunk Merit Network
拉里·布伦克价值网络
EMail: ljb@merit.edu
EMail: ljb@merit.edu
Joao Damas Internet Systems Consortium
Joao Damas互联网系统联合会
EMail: Joao_Damas@isc.org
EMail: Joao_Damas@isc.org
Florent Parent Hexago
弗洛伦特亲本六边形
EMail: Florent.Parent@hexago.com
EMail: Florent.Parent@hexago.com
Andrei Robachevsky RIPE NCC
安德烈·罗巴切夫斯基
EMail: andrei@ripe.net
EMail: andrei@ripe.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。