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)
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.
このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」（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）の新しい簡単な拡張セットを紹介し、インターネットで現在使用されている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
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言語自体を拡張するための一連のガイドラインを提供します。 さらに、RPSL言語のセキュリティ拡張機能はRFC 2725 [2]で指定されています。
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特に、ユーザーがIPv6およびマルチキャストのルーティングポリシーを文書化できるように、アドレスファミリのディメンションにRPSL拡張性を提供します。 o RPSLの拡張に関するガイドラインについては、RFC 2622 [1]のSection 10に従って、拡張機能は既存のツールとプロセスへの影響を最小限に抑えながら下位互換性を保つ必要があります。 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およびマルチキャストサポートの追加により、この仕様で区別する必要がある4つの異なるルーティングポリシー、つまり（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.
現在、ルーティングポリシーは、「import：」、「export：」、および「default：」属性を使用して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]のSection 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.unicast 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-list>は、1つ以上の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].
ネクストホップrp属性で指定されたIPv6アドレスをサポートするために、「ipv6_address」という名前の新しい事前定義済みディクショナリタイプがRPSLディクショナリに追加されます。 このタイプの定義は、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-attribute：＃スタティックルートのネクストホップルーターnext-hop operator =（union ipv4_address、ipv6_address、enum [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 +と呼ばれる）であると理解されています。 プロトコル名のRPSL仕様で「+」文字が許可されていないため、BGP4 +を使用できませんでした。
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-address>、<ipv6-address-prefix>、および<ipv6-address-prefix-range>の3つの新しいIPv6 RPSLタイプを参照します。 <ipv6-address>および<ipv6-address-prefix>タイプは、RFC 3513 [3]のセクション2.2および2.3で定義されています。 <ipv6-address-prefix-range>タイプは、<ipv6-address-prefix>タイプに範囲演算子を追加します。 範囲演算子は、RFC 2622 [1]のセクション2で定義されています。
Three new policy attributes are introduced in the aut-num Class:
3つの新しいポリシー属性がaut-numクラスに導入されました。
mp-import: mp-export: mp-default:
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.
これらの属性には、afi（アドレスファミリ）仕様が組み込まれています。 afiの指定はオプションです。 afi仕様が存在しない場合、ポリシー式はすべてのプロトコルファミリ、つまりipv4.unicast、ipv4.multicast、ipv6.unicast、およびipv6.multicastに適用されると推定されます。 これは、afi仕様「afi any」と同等です。 mp-importおよびmp-export属性には、基本的なポリシー仕様と、より強力な構造化ポリシー仕様の両方があります。
The syntax for the mp-default attribute and the basic policy specification of the mp-import and mp-export attributes is as follows:
mp-default属性の構文と、mp-importおよびmp-export属性の基本ポリシー仕様は次のとおりです。
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-import [protocol <protocol-1>] [into <protocol-2>] optional、[afi <afi-list>] multi-valued from <mp-peering-1> [action <action-1> ; ... <アクション-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>; ... <アクション-N>;] 。 。 <mp-peering-M> [アクション<アクション-1>; ... <action-N>;] <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>;]複数値の[ネットワーク<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-importおよびmp-exportポリシーは構造化できます。 RFC 2622 [1]と同様に、構造化ポリシーは上級RPSLユーザーのみに推奨されます。 mp-import構造化ポリシーの構文は次のとおりです。 <import-factor>の最後のセミコロンは、構造化ポリシー式では必須ですが、非構造化ポリシー式ではオプションです。 mp-export構造化ポリシーの構文は、mp-import属性と対称的に表現されます。 構造化構文では、「except」および「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-term> :: = import-factor | { <import-factor-1>
<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>
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>
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>はルーターipv4-addressesまたはipv6-addresses、inet-rtr名、 および演算子AND、OR、およびEXCEPTを使用した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>式のAddress-Prefix Set式には、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};
}
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.
最後の「例外」は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":
ポリシー式の評価は、その各コンポーネントを評価することにより行われます。 ピアリングセットとフィルターセットの評価は、アドレスファミリによって制約されます。 このような制約により、セット内のアドレスファミリの暗黙的または明示的な定義に応じて、「NOT ANY」<mp-filter>または無効な<mp-peering>が発生する場合があります。 明示的または暗黙的な宣言との競合は、ポリシー式の評価中に実行時に解決されます。 RPSL評価の実装では、「NOT ANY」<mp-filter>の場合に警告を発行することがあります。 次のmp-importポリシーには、「NOT ANY」として評価される必要がある<mp-filter>の例が含まれています。
aut-num: AS65002 mp-import: afi ipv6.unicast from AS65001 accept {192.0.2.0/24}
aut-num：AS65002 mp-import：AS65001からのafi ipv6.unicastは{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 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.
route6クラスは、ルートクラスに相当するIPv6です。 ルートクラスと同様に、route6クラスのクラスキーはroute6とorigin属性のペアによって指定されます。 route6属性を除き、route6クラスは同じ属性名をルートクラスと共有します。 属性名は同じままですが、inject、components、exports-comps、holes、mnt-routes属性は、IPv4プレフィックスとアドレスではなく、IPv6プレフィックスとアドレスを指定する必要があります。 この要件は、以下の<ipv6-router-expression>、<ipv6-filter>、および<ipv6-address-prefix>の仕様に反映されています。 <ipv6-address-prefix>は以前に定義されています。 <ipv6-filter>は、<ipv6-address-prefix>タイプのみが許可されることを除いて、セクション2.5.2で定義された<mp-filter>に関連しています。 同様に、<ipv6-router-expression>は、<ipv6-address>タイプのみが許可されることを除いて、上記のセクション2.5.1で定義されている<mp-router-expression>に関連しています。
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]
属性値タイプroute6 <ipv6-address-prefix>必須、クラスキー、単一値の発信元<as-number>必須、クラスキー、単一値の<route-set-name>のリストのメンバーオプション、複数値 inject [at <ipv6-router-expression>] ...オプション、複数値[action <action>] [upon <condition>]コンポーネント[ATOMIC] [[<ipv6-filter>]オプション、単一値[protocol <プロトコル> <ipv6-filter> ...]] aggr-bndry <as-expression>オプション、単一値aggr-mtdインバウンドまたはアウトバウンドオプション、単一値[<as-expression>] export-comps <ipv6- filter>オプション、<ipv6-address-prefix>の単一値ホールリストオプション、<mntner-name>の複数値mnt-lowerリストオプション、<mntner-name>の複数値mnt-routeリストオプション、multi -valued [{<ipv6-address-prefix-range>のリスト}またはANY]
Example:
例：
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-setを参照するかmbrs-by-ref機能を使用して指定する自律システム（AS）のセットを定義します。 さらに重要なことは、「ルートセット（たとえば、ルートセットクラスのメンバー属性）を期待するコンテキストでは、[...] as-set AS-XはASのASによって発信されるルートのセットを定義します -X "（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クラスは変更する必要がありません。 現在のインターネットルーティングレジストリ（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>)
属性値タイプmp-members list of（<ipv4-address-prefix-range> optional、multi-valued or <ipv6-address-prefix-range> or <route-set-name> or <route-set-name> < 範囲演算子>）
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
ルートセット：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
属性値のタイプfilter-set <object-name>必須、単一値、クラスキーフィルター<filter>オプション、単一値mp-filter <mp-filter>オプション、単一値
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.
ここで、<mp-filter>は上記のセクション2.5.2で定義されています。 「filter：」および「mp-filter：」属性のタイプは「オプション」ですが、フィルターセットにはこれら2つの属性のいずれかが含まれている必要があります。 実装では、両方の属性がオブジェクトで定義されているインスタンスを拒否する必要があります。これは、このようなフィルターセットの解釈が未定義であるためです。
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
属性値タイプpeering-set <object-name>必須、単一値、クラスキーピアリング<peering>オプション、複数値mp-peering <mp-peering>オプション、複数値
Example:
例：
peering-set: prng-ebgp-peers mp-peering: AS65002 2001:0DB8::1 at 2001:0DB8::2
ピアリングセット：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-peering>を使用します。 「peering：」および「mp-peering：」属性のタイプは「オプション」ですが、ピアリングセットにはこれらの2つの属性の少なくとも1つが含まれている必要があります。
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:
2つの新しい属性がinet-rtrクラスに導入されました。「interface：」は、以前に「ifaddr：」属性に含まれていた情報を含む汎用インターフェースの定義と、トンネル定義のサポートを可能にします。 「mp-peer：」は、既存の「peer：」属性の機能を含めて拡張します。 「interface：」属性の構文定義は次のとおりです。
Attribute Value Type interface <ipv4-address> or <ipv6-address> optional, multi-valued masklen <mask> [action <action>] [tunnel <remote-endpoint-address>,<encapsulation>]
属性値タイプinterface <ipv4-address>または<ipv6-address>オプション、複数値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アドレスを示します。 アドレスファミリは、ローカルエンドポイントのアドレスファミリと一致する必要があります。 <encapsulation>は、トンネルで使用されるカプセル化を示し、{GRE、IPinIP}の1つです（外部および内部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：」属性は以下で定義されます。 この属性と「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>
属性値のタイプmp-peer <protocol> <ipv4-address> <options>またはoptional、<protocol> <ipv6-address> <options>または複数値の<protocol> <inet-rtr-name> <options>または< protocol> <rtr-set-name> <options>または<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-setクラスは、新しい属性「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>)
属性値タイプmp-membersリスト（<inet-rtr-name>またはオプション、複数値<rtr-set-name>または<ipv4-address>または<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-routes」属性と「mnt-lower」属性の2つの新しい属性が定義されました。
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」です。 mnt-routes属性の更新された構文を使用したaut-numクラスの短縮された定義を以下に示します。
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]
属性値タイプaut-num <as-number>必須、クラスキー、<mntner-name>の単一値mnt-routesリストオプション、複数値[{list of（<ipv6-address-prefix-range> or ipv4-address-prefix-range>）}または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-routesの使用例です。 この例では、MAINT-65001が2001：0DB8 :: / 32 ^ +の範囲内のIPv6アドレスプレフィックスのオリジンAS 65002を持つroute6オブジェクトを作成し、192.0.2.0 / 24のIPv4プレフィックスのオリジンAS 65002を持つルートオブジェクトを作成することを許可します ^ +範囲。
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-routes属性内にIPv6プレフィックス範囲を含めると、IPv4プレフィックス範囲のみをサポートするRPSLの既存の実装と競合する可能性があることに注意してください。 ただし、このオプションのプレフィックス範囲リストの実装が認識されていないことを考えると、新しい属性タイプを作成するよりも、aut-numクラスのmnt-routes属性の既存の定義を拡張する方がより受け入れられると考えられました。
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
属性値タイプinet6num <ipv6-address-prefix>必須、単一値、クラスキーネット名<netname>必須、単一値descr <自由形式>必須、複数値の国<国コード>必須、複数値 admin-c <nic-handle>必須、複数値tech-c <nic-handle>必須、複数値注釈<free-form>オプション、複数値通知<email-address>オプション、複数値mnt- <mntner-name>の下位リスト、オプション、<mntner-name>の複数値mnt-routesリスト、オプション、複数値[{ipv6-address-prefix-range>}またはANYのリスト]のmnt-byリスト <mntner-name>必須、複数値変更<email-address> <date>必須、複数値ソース<registry-name>必須、単一値
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].
<国コード>は、有効な2文字のISO 3166国コード識別子である必要があります。 <netname>は、指定されたIPv6アドレススペースのシンボル名です。 RPSLの予約済みプレフィックスに制限はありません。 これらの定義は、RIPEデータベースリファレンスマニュアル[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のルートオブジェクトの対応するルールから複製されます。
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オブジェクトが追加されると、送信は2つの認証基準を満たす必要があります。 これは、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が存在する場合、サブミッションは該当するメンテナーと照合されます。 次に、プレフィックスの検索が行われ、最初に完全一致が検索され、次に失敗すると、指定されたプレフィックスよりも具体性の低い最長プレフィックスが検索されます。 この検索が成功すると、1つ以上のroute6オブジェクトが返されます。 追加を成功させるには、これらのroute6オブジェクトの少なくとも1つで、申請が該当するメンテナーと一致する必要があります。 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が見つかると、これらのオブジェクトから許可が取得されます。 適用可能なメンテナーオブジェクトは、mnt-routes属性によって参照されるオブジェクトです。 1つ以上のmnt-routes属性がオブジェクトに存在する場合、mnt-byまたはmnt-lower属性は考慮されません。 指定されたオブジェクトにmnt-routes属性がない場合、最初のmnt-lower属性が使用されます（指定されたオブジェクトがinet6numオブジェクトであり、追加されるroute6オブジェクトよりも具体性が低い場合のみ）。 適用可能なmnt-lower属性が見つからない場合、mnt-by属性がそのオブジェクトに使用されます。 認証は、2つのオブジェクトのそれぞれの許可のいずれかと一致する必要があります。
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標準にはいくつかの脆弱な認証メカニズムが含まれていたことに注意する必要があります。まず、ソース経由で簡単に無効にできる「MAIL-FROM」スキーム メールアドレスのなりすまし; 次に、「CRYPT-PW」スキーム。RPSLオブジェクトが電子メールなどの暗号化されていないチャネルを介して送信された場合、辞書攻撃とパスワードスニッフィングの対象となります。 そして最後に、オブジェクトを保護しない「NONE」メカニズム。
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.
著者は、非常に価値のある議論と提案について、多数の議論、特にエカテリーナペトルシャを通じてこの文書に貢献してくれたすべての人々に感謝します。 、まだ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、 "Routing Policy Specification Language（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、「Routing Policy System Security」、RFC 2725、1999年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、「RIPEデータベースリファレンスマニュアル」、2002年8月。
Authors' Addresses
著者のアドレス
Larry Blunk Merit Network
ラリーブランクメリットネットワーク
EMail: ljb@merit.edu
メール：ljb@merit.edu
Joao Damas Internet Systems Consortium
ジョアンダマスインターネットシステムコンソーシアム
EMail: Joao_Damas@isc.org
メール：Joao_Damas@isc.org
Florent Parent Hexago
フロレントペアレントヘキサゴ
EMail: Florent.Parent@hexago.com
メール：Florent.Parent@hexago.com
Andrei Robachevsky RIPE NCC
アンドレイ・ロバチェフスキーRIPE NCC
EMail: andrei@ripe.net
メール：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事務局に行われたIPR開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（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 Editor機能の資金は、現在インターネット協会によって提供されています。