RFC4012 日本語訳
4012 Routing Policy Specification Language next generation (RPSLng).L. Blunk, J. Damas, F. Parent, A. Robachevsky. March 2005. (Format: TXT=35217 bytes) (Updates RFC2725, RFC2622) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Blunkがコメントのために要求するワーキンググループL.をネットワークでつないでください: 4012はネットワークアップデートに値します: 2725、2622J.ダマカテゴリ: 2005年のNCCの行進のときに熟している標準化過程の共同体F.親Hexago A.インターネットシステムRobachevsky
Routing Policy Specification Language next generation (RPSLng)
ルート設定Policy Specification Language次世代(RPSLng)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
このメモはルート設定Policy Specification Language(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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 異なったアドレスファミリー. . . 2 2.1にルーティング方針を指定します。 あいまいさ解決. . . . . . . . . . . . . . . . . . 3 2.2。 afi辞書属性. . . . . . . . . . . . . . 3 2.3。 RPSL辞書拡張子. . . . . . . . . . . . . . . 4 2.4。 IPv6 RPSLが.42.5mp輸入、mp輸出、およびmpデフォルトをタイプする、.42.5、.1 <mpをじっと見る>. . . . . . . . . . . . . . . . . . 6 2.5.2。 <mpフィルタ>. . . . . . . . . . . . . . . . . . 6 2.5.3。 方針例. . . . . . . . . . . . . . . . 7 3route6 Class. . . . . . . . . . . . . . . . . . . . . . . . . 7 4。 拡大.84.1資産がClass. . . . . . . . . . . . . . . . . . . . . . 8 4.2ルートセットClass. . . . . . . . . . . . . . . . . . . . 9であるとサポートするためにClassesを存在するのにアップデートします。
Blunk, et al. Standards Track [Page 1] RFC 4012 RPSLng March 2005
Blunk、他 規格は2005年のRPSLng行進のときにRFC4012を追跡します[1ページ]。
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. フィルタセットClass. . . . . . . . . . . . . . . . . . . . 9 4.4はClass. . . . . . . . . . . . . . . . . . . 9 4.5inet-rtr Class. . . . . . . . . . . . . . . . . . . . . 10 4.6rtr-セットClass. . . . . . . . . . . . . . . . . . . . . 11 5をじっと見て設定します。 RFC2725拡張子. . . . . . . . . . . . . . . . . . . . . 11 5.1。 route6 Objects. . . . . . . . . 13 6の承認モデル。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 13 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 14 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1。 引用規格. . . . . . . . . . . . . . . . . . 14 8.2。 有益な参照. . . . . . . . . . . . . . . . . 14作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 15の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 16
1. Introduction
1. 序論
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].
RFC2622[1]はIPv4ユニキャストルーティング・プロトコルのためにRPSL言語を定義して、RPSL言語自体を広げるのに一連のガイドラインを提供します。 さらに、RPSL言語へのセキュリティ拡大はRFC2725[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 明確にアドレスファミリーの次元にRPSL伸展性を提供します。o Extensionsは既存のツールとプロセスの上の最小量の影響と互換性があった状態で後方であるべきです、IPv6のためのドキュメントルーティング方針とマルチキャストにユーザを許容してください、そして、RPSL o Maintain明快と非のあいまいさを広げることに関するガイドラインのためのRFC2622[1]のセクション10に続いて: RPSL情報はソフトウェアツール情報のo Minimize複製に加えて人間によって使用されます、特に異なったアドレスファミリーのためのルーティング方針が同じであるときに。
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、ユニキャスト| マルチキャスト、IPv6、ユニキャスト| マルチキャスト、)
2. Specifying Routing Policy for Different Address Families
2. 異なったアドレスファミリーにルート設定方針を指定します。
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クラス使用で指定されて、「エクスポートしてください」と「デフォルトとしてください」ということです。 属性。 時々、異なったアドレスファミリーのために方針を区別するのは重要です、マルチキャスト1からのユニキャストルーティング方針と同様に。
Blunk, et al. Standards Track [Page 2] RFC 4012 RPSLng March 2005
Blunk、他 規格は2005年のRPSLng行進のときにRFC4012を追跡します[2ページ]。
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.
これを覚えておく、「インポートしてください」と「エクスポートしてください」と「デフォルトとしてください」 属性は、それとなくIPv4ユニキャスト方針を指定して、以前にRPSLで定義されるように残るでしょう、そして、新しいマルチプロトコル(ストリング「mp」で、前に置かれている)属性を導入するでしょう。 これらの新しい「mp」属性は以下で説明されます。
2.1. Ambiguity Resolution
2.1. あいまいさ解決
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.
1つ以上のマルチプロトコル方針属性かマルチプロトコル方針属性(IPv4ユニキャスト方針を指定するとき)と以前に定義されたIPv4ユニキャスト方針属性の組み合わせで同じのじっと見ることをカバーできます。 これらの場合では、実装はRFC2622[1]のセクション6.4で定義されるように仕様オーダー規則に従うべきです。 あいまいさ、動作を壊して、最初のじっと見る仕様に対応しているのは使用されています。
2.2. The afi Dictionary Attribute
2.2. 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.
アドレスFamily Identifier(<afi>)は与えられたルーティング方針式が評価されるべきであるアドレスファミリーのRPSLリストです。 <afi>はaut-numのクラスで導入された新しいマルチプロトコル属性の中で任意です。 「いずれも」という疑似識別子は、一点に集められたルーティング方針がある、よりコンパクトな方針式を考慮するために定義されます。
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に同等な)はあらゆる(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リストの>は1つ以上のafi値のコンマで切り離されたリストと定義されます。
Blunk, et al. Standards Track [Page 3] RFC 4012 RPSLng March 2005
Blunk、他 規格は2005年のRPSLng行進のときにRFC4012を追跡します[3ページ]。
2.3. RPSL Dictionary Extensions
2.3. RPSL辞書拡張子
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_アドレス」の権利を与えられた新しい事前に定義された辞書タイプはRPSL辞書に追加されます。 RFC3513[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_アドレス、enum[自己])
A new value has been added for the <protocol> dictionary
specification:
MPBGP
新しい価値は<プロトコル>辞書仕様のために高められました: 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+を使用できませんでした。
2.4. IPv6 RPSL Types
2.4. IPv6 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].
このドキュメントはすなわち、3つの新しいIPv6 RPSLタイプ、<ipv6-アドレス>、<ipv6-アドレス接頭語>、および<ipv6-アドレス接頭語範囲>に参照をつけるでしょう。 <ipv6-アドレス>とipv6-アドレス接頭語>がタイプする<はRFC3513[3]のセクション2.2と2.3で定義されます。 <ipv6-アドレス範囲>を前に置いているタイプは<ipv6接頭語>を扱っているタイプに範囲のオペレータを追加します。 範囲のオペレータはRFC2622[1]のセクション2で定義されます。
2.5. mp-import, mp-export, and mp-default
2.5. mp輸入、mp輸出、およびmpデフォルト
Three new policy attributes are introduced in the aut-num Class:
aut-num Classで3つの新しい政策属性を導入します:
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仕様の同等物です。 mp輸入とmp輸出属性に、基本方針仕様と、より強力な構造化された方針仕様の両方があります。
Blunk, et al. Standards Track [Page 4] RFC 4012 RPSLng March 2005
Blunk、他 規格は2005年のRPSLng行進のときにRFC4012を追跡します[4ページ]。
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輸出属性の基本方針仕様は以下の通りです:
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> [;]
属性Value Type mp輸入[<プロトコル-1>について議定書の中で述べます][<プロトコル-2>への]任意です、[afi<afi-リスト>]マルチ<mpじっと見る-1>[動作<動作-1>; <動作-N>]、<から評価されたmpをじっと見るM>[動作<動作-1>; <動作-N>]は<mpフィルタ>を受け入れます。[;]
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輸出[<プロトコル-1>について議定書の中で述べます][<プロトコル-2>への]任意です、[afi<afi-リスト>]マルチ<mpじっと見る-1>[動作<動作-1>; <動作-N>]、<に評価されたmpをじっと見るM>[動作<動作-1>; <動作-N>]は<mpフィルタ>を発表します。[;]
mp-default [afi <afi-list>] to <mp-peering> optional,
[action <action-1>; ... <action-N>;] multi-valued
[networks <mp-filter>]
mpでデフォルトとしてください。[afi<はマルチ評価されていた状態で<mpをじっと見る>に任意の>[動作<動作1>; <動作-N>]をafi記載します。[<mpフィルタ>をネットワークでつなぎます]
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輸出方針を構造化できます。 RFC2622[1]のように、構造化された方針は高度なRPSLユーザだけに推薦されます。 mp輸入の構造化された方針構文は以下で定義されます。 <輸入仲買人>の端のセミコロンは非構造化された方針式で任意である間、構造化された方針式に義務的です。 mp輸出の構造化された方針構文は対称的にmp輸入属性に表されます。 構造化された構文は“except"と「洗練されてください」キーワードの使用で例外と気品を方針に許容します。 さらに、例外と気品は、方針式を特定のアドレスファミリーに制限するために任意の"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.
定義がその後の、または、「滝」の気品と例外を許容することに注意してください。 RFC2622[1]は不当に「入れ子にされた」式にこれらについて言及します。 構文は本当の入れ子にされた式を許容しません。
<import-factor> ::=
from <mp-peering-1> [action <action-1>; ... <action-M>;]
. . .
from <mp-peering-N> [action <action-1>; ... <action-K>;]
accept <mp-filter>;
<輸入仲買人>:、:= <mpじっと見る-1>[動作<動作-1>; <動作M>]、<のmpをじっと見るNの>[動作<動作-1>; <動作K>]から、<mpフィルタ>を受け入れてください。
<import-term> :: = import-factor |
{
<import-factor-1>
<輸入用語>:、: = 輸入仲買人| <輸入要素-1>。
Blunk, et al. Standards Track [Page 5] RFC 4012 RPSLng March 2005
Blunk、他 規格は2005年のRPSLng行進のときにRFC4012を追跡します[5ページ]。
. . .
<import-factor-N>
}
…<輸入要素-N>。
<import-expression> ::= <import-term> |
<import-term> EXCEPT <afi-import-expression> |
<import-term> REFINE <afi-import-expression>
<輸入式>:、:= <輸入用語>。| <afi-輸入式>以外の<輸入用語>。| <輸入用語>は<afi-輸入式>を精製します。
<afi-import-expression> ::= [afi <afi-list>] <import-expression>
<afi-輸入式>:、:= [afi<afi-リスト>]<輸入式>。
mp-import: [protocol <protocol-1>] [into <protocol-2>]
<afi-import-expression>
mp輸入: [<プロトコル-1>について議定書の中で述べます] [<プロトコル-2>への]<afi-輸入式>。
2.5.1. <mp-peering>
2.5.1. <mpをじっと見る>。
<mp-peering> indicates the AS (and the router if present) and is defined as follows:
<mpをじっと見る>がASを示す、(ルータ、現在、)、以下の通り定義されます:
<mp-peering> ::= <as-expression> [<mp-router-expression-1>]
[at <mp-router-expression-2>] | <peering-set-name>
<mpをじっと見る>:、:= 式>[<mpルータ式-1>][<mpルータ式-2>の]としての<。| <のじっと見るのに設定された名前の>。
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番号の上式であり、ASがオペレータAND、ORを使用することでセットする、<mpルータ式>がルータipv4-アドレスかipv6-アドレスと、inet-rtr名と、オペレータAND、ORを使用するrtr-セット名の上の式である。 2進の“EXCEPT"オペレータは、セット引き算オペレータであり、オペレータANDと同じ先行を持っています(それは「AND NOT」組み合わせに意味的に同等です)。 すなわち、「AS65002を除いた(AS65001かAS65002)」は"AS65001"と等しいです。
2.5.2. <mp-filter>
2.5.2. <mpフィルタ>。
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:
RPSLから派生している<mpフィルタ>方針フィルタ式<はRFC2622[1]のセクション5.4で定義された>方針フィルタ式をフィルターにかけます。 <mpフィルタ>は、IPv6接頭語と接頭語範囲の仕様を許容するために<フィルタ>式を広げています。 特に、>式がそうする<mpフィルタのAddress-接頭語Set式はIPv4とIPv6接頭語か接頭語範囲の両方を含んでいます。 そうでなければ、<mpフィルタ>はRPSL<フィルタ>式と同じです。 アドレス接頭語Setsが支柱に同封される、'、''}'。 方針フィルタはセットに目的地アドレス接頭語があるルートのセットに合っています。 例えば:
{ 192.0.2.0/24, 2001:0DB8::/32 }
{ 2001:0DB8:0100::/48^+, 2001:0DB8:0200::/48^64 }
192.0、.2、.0、/24、2001: 0DB8: : /322001:0DB8:0100: : /48^+、2001:0DB8:0200:、: /48^64
Blunk, et al. Standards Track [Page 6] RFC 4012 RPSLng March 2005
Blunk、他 規格は2005年のRPSLng行進のときにRFC4012を追跡します[6ページ]。
2.5.3. Policy Examples
2.5.3. 方針の例
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: AS65534mp輸入: AS65001からのafi any.unicastはfooとして受け入れます。 afi any.unicast、AS65002から、AS65226を受け入れてください;、afi ipv6.unicastAS65003から、受け入れてください、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フィルタ>か無効の<mpをじっと見る>をもたらすかもしれません。 明白であるとの闘争か暗黙宣言がランタイムのときに方針式の評価の間、解決されています。 RPSL評価実装は「いずれでない」<mpフィルタ>の場合で警報を出したがっているかもしれません。 以下のmp輸入政策は<mpに関する例を含んでいます。-「いずれでないも」として評価されるべきである>をフィルターにかけてください:
aut-num: AS65002
mp-import: afi ipv6.unicast from AS65001 accept {192.0.2.0/24}
aut-num: AS65002mp輸入: AS65001からのafi ipv6.unicastは受け入れます。{192.0.2.0/24}
3. route6 Class
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
route6のクラスはルートのクラスのIPv6同等物です。 ルートのクラスのように、route6のクラスに、主要なクラスはroute6と発生源属性組によって指定されます。 route6属性を除いて、route6のクラスはルートのクラスの同じ属性名を共有します。 属性名が同じままで残っていますが、指定する、注入してください、コンポーネント、コンピュータをエクスポートします、穴、そして、mntルート属性はIPv4接頭語とアドレスよりむしろIPv6接頭語とアドレスを指定しなければなりません。 この要件は<ipv6-ルータ式>、<ipv6-フィルタ>、および<ipv6-アドレス接頭語>の仕様で以下に反映されます。 <ipv6-アドレス接頭語>は以前に、定義されました。 <ipv6-フィルタ>は上で例外がある<ipv6-アドレス接頭語だけ>があるのをタイプするセクション2.5.2で定義されるように<mpフィルタ>に関連します。
Blunk, et al. Standards Track [Page 7] RFC 4012 RPSLng March 2005
Blunk、他 規格は2005年のRPSLng行進のときにRFC4012を追跡します[7ページ]。
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-ルータ式>は上で例外がある<ipv6-アドレスだけ>が受入れられるのをタイプするセクション2.5.1で定義されるように<mpルータ式>に関連します。
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]
義務的な状態でValue Type route6<ipv6-アドレス接頭語>を結果と考えてください、とクラスキー(義務的な数の>クラスキーとしての単一に評価された発生源<)がシングル評価した、メンバー、-、<ルートに設定された名義の>の任意の、そして、マルチ評価された<ipv6-ルータで<状態>コンポーネントATOMIC<ipv6-フィルタ>で任意の式の>の…任意の、そして、マルチ貴重な動作<動作>を注入していて、単一に評価されたプロトコル<プロトコル><ipv6-フィルタ>のリスト; . . 式>任意の、または、単一に評価されたaggr-mtd本国行きの、または、外国行きの任意の、そして、単一に評価された<として>式>輸出コンピュータ<ipv6-フィルタとして任意の、そして、単一に評価されたaggr-bndry<は任意で、マルチ評価されていた状態で任意の、そして、マルチ評価されたmnt-ルートが記載する<mntner-名の>の<mntner-名の>の<ipv6接頭語>を扱っている任意の、そして、マルチ評価されたmnt低いリストのリストを掘ります。[<ipv6-アドレス接頭語範囲>のリストかいずれも]
Example:
例:
route6: 2001:0DB8::/32 origin: AS65001
route6: 2001 : 0DB8:、:/32発生源: AS65001
4. Updates to Existing Classes to Support the Extensions
4. 拡大をサポートするためにクラスを存在するのにアップデートします。
4.1. as-set Class
4.1. 資産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]).
資産のクラスは間接的にメンバー属性で直接彼らを記載するか、別の資産を示すか、または審判によるmbrs施設を使用することによって指定されたAutonomous Systems(AS)の1セットを定義します。 より重要に、「ルートセット(例えば、ルートに設定されたクラスのメンバー属性)、[…]資産を予想する文脈では、AS-XはAS-XでASesによって溯源されるルートのセットを定義する」、(RFC2622[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.
したがって、資産のクラスは、1セットのルート接頭語を集めるのに使用されます。(接頭語は特定のアドレスファミリーに制限されるかもしれません)。
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.
既存の資産のクラスは少しの変更も必要としません。 今日インターネットルート設定Registry(IRR)システムで使用中の伝統的なフィルタリングメカニズムを使用することで特定のアドレスファミリーのものである接頭語を得るためにクラスの評価をフィルターにかけなければなりません。
Blunk, et al. Standards Track [Page 8] RFC 4012 RPSLng March 2005
Blunk、他 規格は2005年のRPSLng行進のときにRFC4012を追跡します[8ページ]。
4.2. route-set Class
4.2. ルートセットClass
This class is used to specify a set of route prefixes.
このクラスは、1セットのルート接頭語を指定するのに使用されます。
A new attribute "mp-members:" is defined for this class. This attribute allows the specification of IPv4 or IPv6 address-prefix-ranges.
新しい属性、「mpメンバー:」 このクラスのために、定義されます。 この属性は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>)
Value Type mpメンバーが記載する属性(<ipv4-アドレス接頭語範囲の>の任意の、または、マルチ評価されたか<ipv6-アドレス範囲>を前に置いているか、<ルートに設定された名前の>か<ルートに設定された名前の><範囲オペレータ>)
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メンバー: rs-バーmpメンバー: 2001 : 0DB8:、:/32#v6メンバーmpメンバー: 192.0.2.0/24#v4メンバー
4.3. filter-set Class
4.3. フィルタセット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:
新しさは「以下をmpでフィルターにかけます」。 属性はセットの方針フィルタを定義します。 方針フィルタは1セットのルートに適用されるとこれらのルートの部分集合を返す論理式です。 アップデートされたフィルタで設定されたクラスの関連部分は以下で見せられます:
Attribute Value Type filter-set <object-name> mandatory, single-valued, class key filter <filter> optional, single-valued mp-filter <mp-filter> optional, single-valued
任意で、単一に評価されていた状態で義務的で、単一に評価されたValue Typeのフィルタ<フィルタ>任意の、そして、単一に評価されたmpフィルタ<mpフィルタセット<オブジェクト名>クラスキーフィルタ>を結果と考えてください。
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フィルタ>が上でセクション2.5.2で定義されるところ。 「以下をフィルターにかけてください」 そして、「以下をmpでフィルターにかけてください」 属性は「任意であること」で、タイプに、フィルタセットがこれらの2つの属性の1つを含まなければならないということです。 両方の属性がオブジェクトで定義されるところで実装はインスタンスを拒絶するべきです、そのような1つのフィルタセットの解釈が未定義であるときに。
4.4. peering-set Class
4.4. じっと見セットClass
The peering set class is updated with a "mp-peering:" attribute.
aでじっと見るセット・クラスをアップデートする、「mpじっと見ること:」 結果と考えます。
Attribute Value Type peering-set <object-name> mandatory, single-valued, class key peering <peering> optional, multi-valued mp-peering <mp-peering> optional, multi-valued
任意で、マルチ評価されていた状態でmpをじっと見る任意の、そして、マルチ評価された<mpをじっと見る主要なValue Typeのじっと見セットの<のオブジェクト名の>の義務的で、単一に評価されたクラスのじっと見ている<じっと見ている>>を結果と考えてください。
Blunk, et al. Standards Track [Page 9] RFC 4012 RPSLng March 2005
Blunk、他 規格は2005年のRPSLng行進のときにRFC4012を追跡します[9ページ]。
Example:
例:
peering-set: prng-ebgp-peers mp-peering: AS65002 2001:0DB8::1 at 2001:0DB8::2
じっと見セット: prng-ebgp-同輩mpじっと見ること: AS65002 2001: 0DB8:、:1、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じっと見ること:」 属性は「任意であること」で、タイプに、じっと見セットが少なくともこれらの2つの属性の1つを含まなければならないということです。
4.5. inet-rtr Class
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:
inet-rtrのクラス--「以下を連結すること」にジェネリックインタフェースの定義を許す2つの新しい属性を導入します、以前に中に含まれた情報を含んでいて「ifaddr:」 トンネルに定義を結果と考えて、サポートしてください。 そして、「mpはじっと見る」、(存在の機能性を含んでいて、広げています)「じっと見てください」 結果と考えます。 構文定義、「連結してください」 属性は続きます:
Attribute Value Type
interface <ipv4-address> or <ipv6-address> optional, multi-valued
masklen <mask>
[action <action>]
[tunnel <remote-endpoint-address>,<encapsulation>]
属性Value Typeインタフェース<ipv4-アドレス>、または<ipv6-アドレス>任意の、そして、マルチ評価されたmasklen<マスク>[動作<動作>][トンネル<の遠く離れた終点アドレス>、<カプセル化>]
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).
<の遠く離れた終点アドレス>はトンネルの遠く離れた終点のIPv4かIPv6アドレスを示します。 アドレスファミリーは地方の終点のものに合わなければなりません。 <カプセル化>はトンネルで使用されるカプセル化を指示します、そして、1つがGRE、IPinIPがありますか?(インタフェース文脈から外側の、そして、内側のIPプロトコルバージョンを推論できることに注意してください--例えば、IPv4のIPv6カプセル化はただ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同輩:」 属性は以下で定義されます。 そして、この属性の違い、「じっと見てください」 属性はIPv6アドレスのサポートの包含です。
Blunk, et al. Standards Track [Page 10] RFC 4012 RPSLng March 2005
Blunk、他 規格は2005年のRPSLng行進のときにRFC4012を追跡します[10ページ]。
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.
<プロトコル>がプロトコル名と、<オプション>であるところでは、じっと見るコンマで切り離されたリストがRPSL辞書に提供するように<プロトコル>のためのオプションですか?
4.6. rtr-set Class
4.6. rtr-セットClass
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メンバー:」 この属性がオリジナルを広げている、「メンバー:」 IPv6アドレスの仕様を許容することによって、結果と考えます。 それは以下の通り定義されます:
Attribute Value Type
mp-members list of (<inet-rtr-name> or optional, multi-valued
<rtr-set-name> or
<ipv4-address> or
<ipv6-address>)
Value Type mpメンバーが記載する属性(<inet-rtr名前>、または任意の、そして、マルチ評価された<rtrによって設定された名前の>、<ipv4-アドレス>または<ipv6-アドレス>)
5. RFC 2725 Extensions
5. RFC2725拡張子
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.
RFC2725[2]は方針の保全がルーティング登録に表したアドレスを承認モデルに紹介します。 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の構文は、inet6num、route6、およびaut-numクラスオブジェクトに存在しているとき、IPv6接頭語範囲リストの任意の仕様を許容するように変更されます。 接頭語範囲のこの任意のリストは巻き毛の支柱に同封されたコンマの切り離されたリストです。 aut-numのクラスでは、IPv6接頭語範囲はIPv4接頭語範囲に混ぜられるかもしれません。 また、キーワードは接頭語範囲の代わりに「少しも」使用されるかもしれません。 inet6numとroute6オブジェクトのケースでは、「いずれも」はクラスキーフィールドにおける、接頭語のすべての、より多くの詳細を示します。 aut-numのクラスのために、「いずれも」は文字通りどんな接頭語も意味します。 どんな追加セットの品目も指定されないとき、デフォルトは「いずれも」です。 mnt-ルート属性のためのアップデートされた構文によるaut-numのクラスの簡略化された定義は以下に提示されます。
Blunk, et al. Standards Track [Page 11] RFC 4012 RPSLng March 2005
Blunk、他 規格は2005年のRPSLng行進のときにRFC4012を追跡します[11ページ]。
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]
任意で、マルチ評価されていた状態で義務的な数の>クラスキーとしてのValue Type aut-num<、<mntner-名の>の単一に評価されたmnt-ルートリストを結果と考えてください。[(<ipv6-アドレス接頭語範囲>か<ipv4-アドレス接頭語範囲>)のリストかいずれも]
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がIPv6アドレスのための65002のASが2001の中に前に置く発生源: 0DB8と共にroute6オブジェクトを作成するのを認可します:、:/32^+範囲、およびIPv4のためのAS65002が192.0.2.0/24^+範囲の中に前に置く発生源があるルートオブジェクト。
aut-num: AS65002
mnt-routes: MAINT-AS65001 {2001:0DB8::/32^+, 192.0.2.0/24^+}
aut-num: AS65002 mnt-ルート: MAINT-AS650012001、: 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-ルート属性の中のIPv6接頭語範囲の包含がサポートIPv4だけが前に置くRPSLの既存の実装と衝突するかもしれないのは及びます。 しかしながら、この任意の接頭語範囲リストの実装の知覚された不足を考えて、それは新しい属性タイプを創造するというよりむしろaut-numのクラスとのmnt-ルート属性の既存の定義を広げるのにおいて、より許容できると考えられました。
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
<自由形式>任意の状態でValue Type inet6num<ipv6接頭語>の義務的で、単一に評価されたクラス主要なnetname<netname>義務的で、単一に評価されたdescr<自由形式>義務的で、マルチ評価された国の<国名略号>義務的で、マルチ評価されたアドミンc<nicハンドル>義務的で、マルチ評価された科学技術のc<nicハンドル>を扱っている義務的で、マルチ評価された所見を結果と考えてください; マルチ評価される、義務的で、単一に評価されていた状態で任意の、そして、マルチ評価されたmnt-ルートが記載する<の、よりmntnerな名前の>義務的で、マルチ評価された変えられた<の><日付の>義務的で、マルチ評価されたソース<登録Eメールアドレス名の>の<ipv6-アドレス接頭語範囲>のリストか近くどんなmntの<の、よりmntnerな名前の>任意の、そして、マルチ貴重なリストの<の、よりmntnerな名前の>の<のEメールアドレスの>の任意の、そして、マルチ貴重なmnt低いリストにも通知してください。
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文字のISO3166国名略号識別子であるに違いありません。 <netname>は指定されたIPv6アドレス空間のための英字名です。 それはRPSLの予約された接頭語に制限を持っていません。 RIPE Database Reference Manual[4]からこれらの定義を取ります。
Blunk, et al. Standards Track [Page 12] RFC 4012 RPSLng March 2005
Blunk、他 規格は2005年のRPSLng行進のときにRFC4012を追跡します[12ページ]。
5.1. Authorization Model for route6 Objects
5.1. route6 Objectsのための承認Model
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オブジェクトの削除とアップデートはRFC2725[2]で定義されるように他のオブジェクトと異なっていません。 route6オブジェクトの作成規則はルートオブジェクトのためにRFC2725[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つの認証評価基準を満たさなければなりません。 それはどちらかでroute6オブジェクトかどんな適切なroute6オブジェクトも見つけられないときのinet6numオブジェクトを指定したaut-numオブジェクトで指定された認証に合わなければなりません。
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接頭語で追加を提出します。 aut-numオブジェクトが加えるためにroute6に存在していないなら、追加は拒絶されます。 aut-numが存在しているなら、服従は適切な維持装置に対してチェックされます。 次に、接頭語のために検索します、完全な一致のための1番目と次に、接頭語が指定したほど特定でない最も長い接頭語マッチのためにそれに失敗するとして見て。 この検索が成功すると、それは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.
いったんroute6オブジェクトのaut-numとリストかinet6numを見つけると、これらのオブジェクトから承認を取ります。 mnt-ルート属性によって参照をつけられて、適切な維持装置オブジェクトはいずれでもあります。 1つ以上のmnt-ルート属性がオブジェクトに存在しているなら、近くmntかmnt下側の属性が考えられません。 与えられたオブジェクトのmnt-ルート属性がないとき、最初のmnt下側の属性は使用されています(与えられたオブジェクトがinet6numオブジェクトであり、加えられるのがroute6オブジェクトほど特定でない場合にだけ)。 どんな適切なmnt下側の属性も見つけられないなら、近くmnt属性はその趣意で使用されます。 認証はそれぞれの2個のオブジェクトで承認の1つに合わなければなりません。
6. Security Considerations
6. セキュリティ問題
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.
このドキュメントはRFC2622[1]とRFC2725[2]に拡大について説明します。 拡大はIPv6とマルチキャストに関して前述のドキュメントの限界を扱います。 拡大はどんな新しいセキュリティの機能性や脅威も紹介しません。
Blunk, et al. Standards Track [Page 13] RFC 4012 RPSLng March 2005
Blunk、他 規格は2005年のRPSLng行進のときにRFC4012を追跡します[13ページ]。
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.
拡大は追加担保の脅威を全く導入しませんが、オリジナルのRFC2622[1]RPSL規格が数個の弱い、そして/または、被害を受け易い認証機構を含んでいたことに注意されるべきです: 」 体系から郵送してください。最初に、「(容易にソースEメールアドレススプーフィングでそれをくつがえすことができます)。 2番目に、「地下室-PW」(メールなどの非暗号化されたチャンネルでRPSLオブジェクトを提出するなら、辞書攻撃とパスワードスニフィングを受けることがある)は計画します。 最終的に「なにも」メカニズム。(そのメカニズムはオブジェクトのためにノー・プロテクションを提供します)。
7. Acknowledgements
7. 承認
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.
作者は頻繁な議論でこのドキュメントに貢献したすべての人々に感謝したがっています、特にエカテリーナPetrusha、非常に貴重な議論と提案のために: シェーン・カーとEngin GunduzとマークBlanchetと多くの議論に建設的に参加したデヴィッドKessensとCengiz Alaettinoglu。(そのCengiz Alaettinogluはあらゆる点でそれでも、参照RPSLです)。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[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.、マイヤー、D.、ベイツ、T.、Karrenberg、D.、およびM.テルプストラ、「ルート設定方針仕様言語(RPSL)」、RFC2622(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.とマイヤー、D.とS.マーフィー、「ルート設定方針システムセキュリティ」、RFC2725、1999年12月。
[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[3]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
8.2. Informative References
8.2. 有益な参照
[4] Damas, J. and A. Robachevsky, "RIPE Database Reference Manual",
August 2002.
[4] ダマとJ.とA.Robachevsky、「熟しているデータベースリファレンスマニュアル」、2002年8月。
Blunk, et al. Standards Track [Page 14] RFC 4012 RPSLng March 2005
Blunk、他 規格は2005年のRPSLng行進のときにRFC4012を追跡します[14ページ]。
Authors' Addresses
作者のアドレス
Larry Blunk Merit Network
ラリーBlunk長所ネットワーク
EMail: ljb@merit.edu
メール: ljb@merit.edu
Joao Damas Internet Systems Consortium
ジョアンダマインターネットシステム共同体
EMail: Joao_Damas@isc.org
メール: Joao_Damas@isc.org
Florent Parent Hexago
フローラン親Hexago
EMail: Florent.Parent@hexago.com
メール: Florent.Parent@hexago.com
Andrei Robachevsky RIPE NCC
アンドレイRobachevsky熟しているNCC
EMail: andrei@ripe.net
メール: andrei@ripe.net
Blunk, et al. Standards Track [Page 15] RFC 4012 RPSLng March 2005
Blunk、他 規格は2005年のRPSLng行進のときにRFC4012を追跡します[15ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Blunk, et al. Standards Track [Page 16]
Blunk、他 標準化過程[16ページ]
一覧
スポンサーリンク
