RFC4760 日本語訳
4760 Multiprotocol Extensions for BGP-4. T. Bates, R. Chandra, D.Katz, Y. Rekhter. January 2007. (Format: TXT=24542 bytes) (Obsoletes RFC2858) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Bates
Request for Comments: 4760 Cisco Systems
Obsoletes: 2858 R. Chandra
Category: Standards Track Sonoa Systems
D. Katz
Y. Rekhter
Juniper Networks
January 2007
ネットワークワーキンググループT.はコメントを求める要求を和らげます: 4760 シスコシステムズは以下を時代遅れにします。 2858年のR.チャンドラカテゴリ: 規格は2007年1月にSonoaシステムD.キャッツY.Rekhter杜松ネットワークを追跡します。
Multiprotocol Extensions for BGP-4
BGP-4のためのMultiprotocol拡張子
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions.
このドキュメントは、複数のNetwork Layerプロトコル(例えば、IPv6、IPX、L3VPNなど)のためのルーティング情報を運ぶのを可能にするために拡大をBGP-4と定義します。 拡大が後方である、コンパチブル、--拡大をサポートするルータは拡大をサポートしないルータで共同利用できます。
Bates, et al. Standards Track [Page 1] RFC 4760 Multiprotocol Extensions for BGP-4 January 2007
ベイツ、他 BGP-2007年1月4日の標準化過程[1ページ]RFC4760Multiprotocol拡張子
1. Introduction
1. 序論
The only three pieces of information carried by BGP-4 [BGP-4] that are IPv4 specific are (a) the NEXT_HOP attribute (expressed as an IPv4 address), (b) AGGREGATOR (contains an IPv4 address), and (c) NLRI (expressed as IPv4 address prefixes). This document assumes that any BGP speaker (including the one that supports multiprotocol capabilities defined in this document) has to have an IPv4 address (which will be used, among other things, in the AGGREGATOR attribute). Therefore, to enable BGP-4 to support routing for multiple Network Layer protocols, the only two things that have to be added to BGP-4 are (a) the ability to associate a particular Network Layer protocol with the next hop information, and (b) the ability to associate a particular Network Layer protocol with NLRI. To identify individual Network Layer protocols associated with the next hop information and semantics of NLRI, this document uses a combination of Address Family, as defined in [IANA-AF], and Subsequent Address Family (as described in this document).
(c) (a) IPv4特有であるのは、ネクスト_HOP属性(IPv4アドレスとして、言い表される)です、(b)AGGREGATOR(IPv4アドレスを含んでいる)ということであるBGP-4[BGP-4]によって運ばれた情報の唯一のスリーピース、およびNLRI(IPv4が接頭語を扱うので、言い表されます)。 このドキュメントは、どんなBGPスピーカー(本書では定義された「マルチ-プロトコル」能力をサポートするものを含んでいる)にもIPv4アドレス(AGGREGATOR属性に特に使用される)がなければならないと仮定します。 したがって、BGP-4が複数のNetwork Layerプロトコル、唯一のためにルーティングをサポートするのを可能にするために、(a) BGP-4に加えられているのが、特定のNetwork Layerを関連づける能力であるということでなければならない2つのものが次のホップ情報、および(b)で特定のNetwork LayerプロトコルをNLRIに関連づける能力について議定書の中で述べます。 NLRIの次のホップ情報と意味論に関連している個々のNetwork Layerプロトコルを特定するのに、このドキュメントはAddress Familyの組み合わせを使用します、[IANA-AF]、およびSubsequent Address Familyで定義されるように(本書では説明されるように)。
One could further observe that the next hop information (the information provided by the NEXT_HOP attribute) is meaningful (and necessary) only in conjunction with the advertisements of reachable destinations - in conjunction with the advertisements of unreachable destinations (withdrawing routes from service), the next hop information is meaningless. This suggests that the advertisement of reachable destinations should be grouped with the advertisement of the next hop to be used for these destinations, and that the advertisement of reachable destinations should be segregated from the advertisement of unreachable destinations.
人は、次のホップ情報(ネクスト_HOP属性によって提供された情報)が単に届いている目的地の広告に関連して重要、そして、(必要)であるとさらに観測できました--手の届かない目的地(サービスからルートを引っ込める)の広告に関連して、次のホップ情報は無意味です。 これは、届いている目的地の広告が次のホップの広告で分類されて、これらの目的地に使用されるべきであり、届いている目的地の広告が手の届かない目的地の広告から隔離されるべきであると示唆します。
To provide backward compatibility, as well as to simplify introduction of the multiprotocol capabilities into BGP-4, this document uses two new attributes, Multiprotocol Reachable NLRI (MP_REACH_NLRI) and Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI). The first one (MP_REACH_NLRI) is used to carry the set of reachable destinations together with the next hop information to be used for forwarding to these destinations. The second one (MP_UNREACH_NLRI) is used to carry the set of unreachable destinations. Both of these attributes are optional and non-transitive. This way, a BGP speaker that doesn't support the multiprotocol capabilities will just ignore the information carried in these attributes and will not pass it to other BGP speakers.
後方の互換性を供給して、「マルチ-プロトコル」能力の導入をBGP-4に簡素化するために、このドキュメントは2つの新しい属性、Multiprotocol Reachable NLRI(_MP REACH_NLRI)、およびMultiprotocol Unreachable NLRI(_MP UNREACH_NLRI)を使用します。 最初のもの(_MP REACH_NLRI)は、推進にこれらの目的地に使用されるために次のホップ情報と共に届いている目的地のセットを運ぶのに使用されます。 2番目のもの(_MP UNREACH_NLRI)は、手の届かない目的地のセットを運ぶのに使用されます。 これらの属性の両方が、任意であって、非遷移的です。 この道、「マルチ-プロトコル」能力をサポートしないBGPスピーカーはただこれらの属性で運ばれた情報を無視して、他のBGPスピーカーにそれを渡さないでしょう。
2. Specification of Requirements
2. 要件の仕様
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Bates, et al. Standards Track [Page 2] RFC 4760 Multiprotocol Extensions for BGP-4 January 2007
ベイツ、他 BGP-2007年1月4日の標準化過程[2ページ]RFC4760Multiprotocol拡張子
3. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14):
3. Multiprotocolの届いているNLRI--MP_は_NLRIに達します(コード14をタイプしてください):
This is an optional non-transitive attribute that can be used for the following purposes:
これは以下の目的に使用できる任意の非他動詞属性です:
(a) to advertise a feasible route to a peer
(a) 可能なルートの同輩に広告を出すために
(b) to permit a router to advertise the Network Layer address of the
router that should be used as the next hop to the destinations
listed in the Network Layer Reachability Information field of the
MP_NLRI attribute.
(b) ルータを可能にするために、次のホップとして目的地に使用されるべきであるルータのNetwork Layerアドレスの広告を出すのはMP_NLRI属性のNetwork Layer Reachability情報分野に記載しました。
The attribute is encoded as shown below:
属性は以下に示すようにコード化されます:
+---------------------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Length of Next Hop Network Address (1 octet) |
+---------------------------------------------------------+
| Network Address of Next Hop (variable) |
+---------------------------------------------------------+
| Reserved (1 octet) |
+---------------------------------------------------------+
| Network Layer Reachability Information (variable) |
+---------------------------------------------------------+
+---------------------------------------------------------+ | アドレスFamily Identifier(2つの八重奏)| +---------------------------------------------------------+ | その後のAddress Family Identifier(1つの八重奏)| +---------------------------------------------------------+ | Next Hop Network Address(1つの八重奏)の長さ| +---------------------------------------------------------+ | 次のホップ(可変)のネットワーク・アドレス| +---------------------------------------------------------+ | 予約されます(1つの八重奏)。| +---------------------------------------------------------+ | ネットワーク層可到達性情報(可変)| +---------------------------------------------------------+
The use and meaning of these fields are as follows:
これらの分野の使用と意味は以下の通りです:
Address Family Identifier (AFI):
アドレスファミリー識別子(AFI):
This field in combination with the Subsequent Address Family
Identifier field identifies the set of Network Layer protocols
to which the address carried in the Next Hop field must belong,
the way in which the address of the next hop is encoded, and
the semantics of the Network Layer Reachability Information
that follows. If the Next Hop is allowed to be from more than
one Network Layer protocol, the encoding of the Next Hop MUST
provide a way to determine its Network Layer protocol.
Subsequent Address Family Identifier分野と組み合わせたこの分野はNext Hop分野で運ばれたアドレスが属しなければならないNetwork Layerプロトコルのセット、次のホップのアドレスがコード化される方法、および従うNetwork Layer Reachability情報の意味論を特定します。 Next Hopが1つ以上のNetwork Layerプロトコルからいることができるなら、Next Hopのコード化はNetwork Layerプロトコルを決定する方法を提供しなければなりません。
Presently defined values for the Address Family Identifier
field are specified in the IANA's Address Family Numbers
registry [IANA-AF].
Address Family Identifier分野への現在定義された値はIANAのAddress Family民数記登録[IANA-AF]で指定されます。
Bates, et al. Standards Track [Page 3] RFC 4760 Multiprotocol Extensions for BGP-4 January 2007
ベイツ、他 BGP-2007年1月4日の標準化過程[3ページ]RFC4760Multiprotocol拡張子
Subsequent Address Family Identifier (SAFI):
その後のアドレスファミリー識別子(サフィ):
This field in combination with the Address Family Identifier
field identifies the set of Network Layer protocols to which
the address carried in the Next Hop must belong, the way in
which the address of the next hop is encoded, and the semantics
of the Network Layer Reachability Information that follows. If
the Next Hop is allowed to be from more than one Network Layer
protocol, the encoding of the Next Hop MUST provide a way to
determine its Network Layer protocol.
Address Family Identifier分野と組み合わせたこの分野はNext Hopで運ばれたアドレスが属しなければならないNetwork Layerプロトコルのセット、次のホップのアドレスがコード化される方法、および従うNetwork Layer Reachability情報の意味論を特定します。 Next Hopが1つ以上のNetwork Layerプロトコルからいることができるなら、Next Hopのコード化はNetwork Layerプロトコルを決定する方法を提供しなければなりません。
Length of Next Hop Network Address:
次のホップネットワーク・アドレスの長さ:
A 1-octet field whose value expresses the length of the
"Network Address of Next Hop" field, measured in octets.
値が八重奏で測定された「次のホップのネットワーク・アドレス」分野の長さを表す1八重奏の分野。
Network Address of Next Hop:
次のホップのアドレスをネットワークでつないでください:
A variable-length field that contains the Network Address of
the next router on the path to the destination system. The
Network Layer protocol associated with the Network Address of
the Next Hop is identified by a combination of <AFI, SAFI>
carried in the attribute.
経路に次のルータのNetwork Addressを目的地システムに保管している可変長の分野。 Next HopのNetwork Addressに関連しているNetwork Layerプロトコルは<AFI(属性で運ばれたサフィ>)の組み合わせで特定されます。
Reserved:
予約される:
A 1 octet field that MUST be set to 0, and SHOULD be ignored
upon receipt.
それが1つの八重奏分野でなければならないことが0、およびSHOULDにセットしました。領収書では、無視されます。
Network Layer Reachability Information (NLRI):
ネットワーク層可到達性情報(NLRI):
A variable length field that lists NLRI for the feasible routes
that are being advertised in this attribute. The semantics of
NLRI is identified by a combination of <AFI, SAFI> carried in
the attribute.
この属性の広告に掲載されている可能なルートにNLRIを記載する可変長フィールド。 NLRIの意味論は属性で運ばれた<AFI、サフィ>の組み合わせで特定されます。
When the Subsequent Address Family Identifier field is set to
one of the values defined in this document, each NLRI is
encoded as specified in the "NLRI encoding" section of this
document.
Subsequent Address Family Identifier分野が本書では定義された値の1つに設定されるとき、各NLRIはこのドキュメントの「NLRIコード化」セクションで指定されるようにコード化されます。
The next hop information carried in the MP_REACH_NLRI path attribute defines the Network Layer address of the router that SHOULD be used as the next hop to the destinations listed in the MP_NLRI attribute in the UPDATE message.
MP_REACH_NLRI経路属性で運ばれた次のホップ情報は次のホップとしてUPDATEメッセージのMP_NLRI属性で記載された目的地に使用されていた状態でSHOULDがあるルータのNetwork Layerアドレスを定義します。
Bates, et al. Standards Track [Page 4] RFC 4760 Multiprotocol Extensions for BGP-4 January 2007
ベイツ、他 BGP-2007年1月4日の標準化過程[4ページ]RFC4760Multiprotocol拡張子
The rules for the next hop information are the same as the rules for the information carried in the NEXT_HOP BGP attribute (see Section 5.1.3 of [BGP-4]).
次のホップ情報のための規則は情報のための規則がネクスト_HOP BGP属性で運ばれたのと(.3セクション5.1[BGP-4]を見てください)同じです。
An UPDATE message that carries the MP_REACH_NLRI MUST also carry the ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP exchanges). Moreover, in IBGP exchanges such a message MUST also carry the LOCAL_PREF attribute.
また、_MP REACH_NLRI MUSTを運ぶUPDATEメッセージはORIGINとAS_PATH属性(EBGPとIBGP交換における)を運びます。 そのうえ、また、IBGP交換では、そのようなメッセージはLOCAL_PREF属性を運ばなければなりません。
An UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute, SHOULD NOT carry the NEXT_HOP attribute. If such a message contains the NEXT_HOP attribute, the BGP speaker that receives the message SHOULD ignore this attribute.
NLRIを全く運ばないUPDATEメッセージ、MP_REACH_NLRI属性でコード化されたものを除いて、SHOULD NOTはネクスト_HOP属性を運びます。 そのようなメッセージがネクスト_HOP属性を含んでいるなら、SHOULDがこの属性を無視するというメッセージを受け取るBGPスピーカーです。
An UPDATE message SHOULD NOT include the same address prefix (of the same <AFI, SAFI>) in more than one of the following fields: WITHDRAWN ROUTES field, Network Reachability Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The processing of an UPDATE message in this form is undefined.
SHOULD NOTが以下の分野の1つ以上に同じアドレス接頭語(同じ<AFI、サフィ>の)を含んでいるというUPDATEメッセージ: WITHDRAWN ROUTES分野、Network Reachability情報分野、REACH_NLRIがさばくMP_、およびUNREACH_NLRIがさばくMP_。 このフォームにおける、UPDATEメッセージの処理は未定義です。
4. Multiprotocol Unreachable NLRI - MP_UNREACH_NLRI (Type Code 15):
4. Multiprotocolの手の届かないNLRI--_MP UNREACH_NLRI(コード15をタイプします):
This is an optional non-transitive attribute that can be used for the purpose of withdrawing multiple unfeasible routes from service.
これはサービスから複数の実行不可能なルートを引っ込める目的に使用できる任意の非他動詞属性です。
The attribute is encoded as shown below:
属性は以下に示すようにコード化されます:
+---------------------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Withdrawn Routes (variable) |
+---------------------------------------------------------+
+---------------------------------------------------------+ | アドレスFamily Identifier(2つの八重奏)| +---------------------------------------------------------+ | その後のAddress Family Identifier(1つの八重奏)| +---------------------------------------------------------+ | よそよそしいルート(可変)| +---------------------------------------------------------+
The use and the meaning of these fields are as follows:
これらの分野の使用と意味は以下の通りです:
Address Family Identifier (AFI):
アドレスファミリー識別子(AFI):
This field in combination with the Subsequent Address Family
Identifier field identifies the set of Network Layer protocols
to which the address carried in the Next Hop field must belong,
the way in which the address of the next hop is encoded, and
the semantics of the Network Layer Reachability Information
that follows. If the Next Hop is allowed to be from more than
one Network Layer protocol, the encoding of the Next Hop MUST
provide a way to determine its Network Layer protocol.
Subsequent Address Family Identifier分野と組み合わせたこの分野はNext Hop分野で運ばれたアドレスが属しなければならないNetwork Layerプロトコルのセット、次のホップのアドレスがコード化される方法、および従うNetwork Layer Reachability情報の意味論を特定します。 Next Hopが1つ以上のNetwork Layerプロトコルからいることができるなら、Next Hopのコード化はNetwork Layerプロトコルを決定する方法を提供しなければなりません。
Bates, et al. Standards Track [Page 5] RFC 4760 Multiprotocol Extensions for BGP-4 January 2007
ベイツ、他 BGP-2007年1月4日の標準化過程[5ページ]RFC4760Multiprotocol拡張子
Presently defined values for the Address Family Identifier
field are specified in the IANA's Address Family Numbers
registry [IANA-AF].
Address Family Identifier分野への現在定義された値はIANAのAddress Family民数記登録[IANA-AF]で指定されます。
Subsequent Address Family Identifier (SAFI):
その後のアドレスファミリー識別子(サフィ):
This field in combination with the Address Family Identifier
field identifies the set of Network Layer protocols to which
the address carried in the Next Hop must belong, the way in
which the address of the next hop is encoded, and the semantics
of the Network Layer Reachability Information that follows. If
the Next Hop is allowed to be from more than one Network Layer
protocol, the encoding of the Next Hop MUST provide a way to
determine its Network Layer protocol.
Address Family Identifier分野と組み合わせたこの分野はNext Hopで運ばれたアドレスが属しなければならないNetwork Layerプロトコルのセット、次のホップのアドレスがコード化される方法、および従うNetwork Layer Reachability情報の意味論を特定します。 Next Hopが1つ以上のNetwork Layerプロトコルからいることができるなら、Next Hopのコード化はNetwork Layerプロトコルを決定する方法を提供しなければなりません。
Withdrawn Routes Network Layer Reachability Information:
よそよそしいルートネットワーク層可到達性情報:
A variable-length field that lists NLRI for the routes that are
being withdrawn from service. The semantics of NLRI is
identified by a combination of <AFI, SAFI> carried in the
attribute.
サービスから引っ込められているルートにNLRIを記載する可変長の分野。 NLRIの意味論は属性で運ばれた<AFI、サフィ>の組み合わせで特定されます。
When the Subsequent Address Family Identifier field is set to
one of the values defined in this document, each NLRI is
encoded as specified in the "NLRI encoding" section of this
document.
Subsequent Address Family Identifier分野が本書では定義された値の1つに設定されるとき、各NLRIはこのドキュメントの「NLRIコード化」セクションで指定されるようにコード化されます。
An UPDATE message that contains the MP_UNREACH_NLRI is not required to carry any other path attributes.
_MP UNREACH_NLRIを含むUPDATEメッセージは、いかなる他の経路属性も運ぶのに必要ではありません。
Bates, et al. Standards Track [Page 6] RFC 4760 Multiprotocol Extensions for BGP-4 January 2007
ベイツ、他 BGP-2007年1月4日の標準化過程[6ページ]RFC4760Multiprotocol拡張子
5. NLRI Encoding
5. NLRIコード化
The Network Layer Reachability information is encoded as one or more 2-tuples of the form <length, prefix>, whose fields are described below:
Network Layer Reachability情報はフォーム<の長さの1 2-tuples、接頭語>としてコード化されます:(>の分野は以下で説明されます)。
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
+---------------------------+ | 長さ(1つの八重奏)| +---------------------------+ | 接頭語(変数)| +---------------------------+
The use and the meaning of these fields are as follows:
これらの分野の使用と意味は以下の通りです:
a) Length:
a) 長さ:
The Length field indicates the length, in bits, of the address
prefix. A length of zero indicates a prefix that matches all (as
specified by the address family) addresses (with prefix, itself,
of zero octets).
Length分野はアドレス接頭語のビットの長さを示します。 ゼロの長さがすべての(アドレスファミリーによって指定されるように)アドレスに合っている接頭語を示す、(接頭語でそれ自体、八重奏がない、)
b) Prefix:
b) 以下を前に置いてください。
The Prefix field contains an address prefix followed by enough
trailing bits to make the end of the field fall on an octet
boundary. Note that the value of trailing bits is irrelevant.
Prefix分野はアドレス接頭語を含んでいます、続いて、分野の端を八重奏境界に落ちさせることができるくらいの引きずっているビットを含みます。 引きずっているビットの価値が無関係であることに注意してください。
6. Subsequent Address Family Identifier
6. その後のアドレスファミリー識別子
This document defines the following values for the Subsequent Address Family Identifier field carried in the MP_REACH_NLRI and MP_UNREACH_NLRI attributes:
このドキュメントはMP_REACH_NLRIとMP_UNREACH_NLRI属性で運ばれたSubsequent Address Family Identifier野原と以下の値を定義します:
1 - Network Layer Reachability Information used for unicast
forwarding
1--ユニキャスト推進に使用されるネットワークLayer Reachability情報
2 - Network Layer Reachability Information used for multicast
forwarding
2--マルチキャスト推進に使用されるネットワークLayer Reachability情報
An implementation MAY support all, some, or none of the Subsequent Address Family Identifier values defined in this document.
実装は本書では定義されたSubsequent Address Family Identifier値のすべて、いくつか、またはいずれもサポートしないかもしれません。
Bates, et al. Standards Track [Page 7] RFC 4760 Multiprotocol Extensions for BGP-4 January 2007
ベイツ、他 BGP-2007年1月4日の標準化過程[7ページ]RFC4760Multiprotocol拡張子
7. Error Handling
7. エラー処理
If a BGP speaker receives from a neighbor an UPDATE message that contains the MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and if the speaker determines that the attribute is incorrect, the speaker MUST delete all the BGP routes received from that neighbor whose AFI/SAFI is the same as the one carried in the incorrect MP_REACH_NLRI or MP_UNREACH_NLRI attribute. For the duration of the BGP session over which the UPDATE message was received, the speaker then SHOULD ignore all the subsequent routes with that AFI/SAFI received over that session.
BGPスピーカーが隣人からUPDATEメッセージを受け取るなら、それはMP_REACH_NLRIかMP_UNREACH_NLRI属性を含んでいます、そして、スピーカーが、属性が不正確であると決心しているなら、スピーカーはAFI/サフィがものが_不正確なMP REACH_NLRIで運ばれたのと同じであるその隣人から受け取られたすべてのBGPルートかUNREACH_NLRIが結果と考えるMP_を削除しなければなりません。 UPDATEメッセージが受け取られたBGPセッションの持続時間のために、スピーカーの当時のSHOULDはそのセッションの間、そのAFI/サフィを受け取っていてすべてのその後のルートを無視します。
In addition, the speaker MAY terminate the BGP session over which the UPDATE message was received. The session SHOULD be terminated with the Notification message code/subcode indicating "UPDATE Message Error"/"Optional Attribute Error".
さらに、スピーカーはUPDATEメッセージが受け取られたBGPセッションを終えるかもしれません。 セッションSHOULD、Notificationメッセージコード/部分符号が「アップデートメッセージ誤り」/「任意のAttribute Error」を示していて、終えられてください。
8. Use of BGP Capability Advertisement
8. BGP能力広告の使用
A BGP speaker that uses Multiprotocol Extensions SHOULD use the Capability Advertisement procedures [BGP-CAP] to determine whether the speaker could use Multiprotocol Extensions with a particular peer.
Multiprotocol Extensions SHOULDを使用するBGPスピーカーは、スピーカーが特定の同輩がいるMultiprotocol Extensionsを使用できたかどうか決定するのに、Capability Advertisement手順[BGP-CAP]を用います。
The fields in the Capabilities Optional Parameter are set as follows. The Capability Code field is set to 1 (which indicates Multiprotocol Extensions capabilities). The Capability Length field is set to 4. The Capability Value field is defined as:
Capabilities Optional Parameterの分野は以下の通り設定されます。 Capability Code分野は1(Multiprotocol Extensions能力を示す)に設定されます。 Capability Length分野は4に設定されます。 Capability Value分野は以下と定義されます。
0 7 15 23 31
+-------+-------+-------+-------+
| AFI | Res. | SAFI |
+-------+-------+-------+-------+
0 7 15 23 31 +-------+-------+-------+-------+ | AFI| Res。 | サフィ| +-------+-------+-------+-------+
The use and meaning of this field is as follow:
この分野の使用と意味が続くようにあります:
AFI - Address Family Identifier (16 bit), encoded the same way as
in the Multiprotocol Extensions
AFI--ずっとMultiprotocol Extensionsのように同じようにコード化されたアドレスFamily Identifier(16ビット)
Res. - Reserved (8 bit) field. SHOULD be set to 0 by the sender
and ignored by the receiver.
Res。 - (8ビット)の予約された分野。 SHOULDは送付者によって0に設定されて、受信機を無視しました。
Note that not setting the field value to 0 may create issues
for a receiver not ignoring the field. In addition, this
definition is problematic if it is ever attempted to redefine
the field.
0への値が作成するかもしれない分野を設定しないと分野が無視ではなく、受信機のために発行されることに注意してください。 さらに、それが今までに分野を再定義するために試みられるなら、この定義は問題が多いです。
Bates, et al. Standards Track [Page 8] RFC 4760 Multiprotocol Extensions for BGP-4 January 2007
ベイツ、他 BGP-2007年1月4日の標準化過程[8ページ]RFC4760Multiprotocol拡張子
SAFI - Subsequent Address Family Identifier (8 bit), encoded the
same way as in the Multiprotocol Extensions.
サフィ--ずっとMultiprotocol Extensionsのように同じようにコード化されたその後のAddress Family Identifier(8ビット)。
A speaker that supports multiple <AFI, SAFI> tuples includes them as multiple Capabilities in the Capabilities Optional Parameter.
複数の<がAFI、サフィ>tuplesであるとサポートするスピーカーはCapabilities Optional Parameterの複数のCapabilitiesとしてそれらを入れます。
To have a bi-directional exchange of routing information for a particular <AFI, SAFI> between a pair of BGP speakers, each such speaker MUST advertise to the other (via the Capability Advertisement mechanism) the capability to support that particular <AFI, SAFI> route.
1組のBGPスピーカーの間に特定の<AFI、サフィ>のためのルーティング情報の双方向の交換を持つために、そのような各スピーカーはその特定の<AFI、サフィ>ルートを支える能力のもう片方(Capability Advertisementメカニズムを通した)に広告を出さなければなりません。
9. IANA Considerations
9. IANA問題
As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI attributes contain the Subsequence Address Family Identifier (SAFI) field. The SAFI name space is defined in this document. The IANA registered and maintains values for the SAFI namespace as follows:
本書では指定されるように、MP_REACH_NLRIとMP_UNREACH_NLRI属性はSubsequence Address Family Identifier(サフィ)分野を含んでいます。 スペースというサフィ名は本書では定義されます。 IANAはサフィ名前空間のための値を以下の通りに示して、維持します:
- SAFI values 1 and 2 are assigned in this document.
- サフィ値1と2は本書では割り当てられます。
- SAFI value 3 is reserved. It was assigned by RFC 2858 for a use
that was never fully implemented, so it is deprecated by this
document.
- サフィ値3は予約されています。 完全に決して実装されたというわけではない使用のためにRFC2858によって割り当てられたので、それはこのドキュメントで推奨しないです。
- SAFI values 5 through 63 are to be assigned by IANA using either
the Standards Action process, defined in [RFC2434], or the Early
IANA Allocation process, defined in [RFC4020].
- サフィ値5〜63は[RFC2434]で定義されたStandards Actionプロセスを使用するIANAか[RFC4020]で定義されたEarly IANA Allocationプロセスによって割り当てられることです。
- SAFI values 67 through 127 are to be assigned by IANA, using the
"First Come First Served" policy, defined in RFC 2434.
- サフィ値67〜127はIANAによって割り当てられることです、RFC2434で定義された「先着順」方針を使用して。
- SAFI values 0 and 255 are reserved.
- サフィ値0と255は予約されています。
- SAFI values 128 through 240 are part of the previous "private
use" range. At the time of approval of this document, the
unused values were provided to IANA by the Routing Area
Director. These unused values, namely, 130, 131, 135 through
139, and 141 through 240, are considered reserved in order to
avoid conflicts.
- サフィ値128〜240は前の「私用」範囲の一部です。 このドキュメントの承認時点で、未使用の値はルート設定AreaディレクターによってIANAに提供されました。 これらの未使用の値、すなわち、130、131、135〜139、および141〜240は、摩擦を避けるために予約されていると考えられます。
- SAFI values 241 through 254 are for "private use", and values in
this range are not to be assigned by IANA.
- サフィ値241〜254は「私用」のためのものです、そして、この範囲の値はIANAによって割り当てられないことです。
Bates, et al. Standards Track [Page 9] RFC 4760 Multiprotocol Extensions for BGP-4 January 2007
ベイツ、他 BGP-2007年1月4日の標準化過程[9ページ]RFC4760Multiprotocol拡張子
10. Comparison with RFC 2858
10. RFC2858との比較
This document makes the use of the next hop information consistent with the information carried in the NEXT_HOP BGP path attribute.
このドキュメントは次のホップの使用をネクスト_HOP BGP経路属性で運ばれる情報と一致した情報にします。
This document removes the definition of SAFI 3 and deprecates SAFI 3.
このドキュメントは、サフィ3の定義を取り除いて、サフィ3を非難します。
This document changes partitioning of the SAFI space. Specifically, in RFC 2858 SAFI values 128 through 240 were part of the "private use" range. This document specifies that of this range, allocations that are currently in use are to be recognized by IANA, and that unused values, namely 130, 131, 135 through 139, and 141 through 240, should be considered reserved.
このドキュメントはサフィのスペースの仕切りを変えます。 明確に、サフィが評価するRFC2858年に、128〜240は「私用」範囲の一部です。 このドキュメントは、未使用の値(すなわち、130、131、135〜139、および141〜240)がこの範囲では、現在使用中の配分がIANAによって認められることであり、予約されていると考えられるべきであると指定します。
This document renames the Number of SNPAs field to Reserved and removes the rest of the SNPA-related information from the MP_REACH_NLRI attribute.
このドキュメントは、MP_REACH_NLRI属性からSNPAsのNumberをReservedへの分野に改名して、SNPA関連の情報の残りを移します。
11. Comparison with RFC 2283
11. RFC2283との比較
This document restricts the MP_REACH_NLRI attribute to carry only a single instance of <AFI, SAFI, Next Hop Information, ...>.
このドキュメントは<AFI、サフィNext Hop情報のただ一つのインスタンスだけを運ぶためにMP_REACH_NLRI属性を制限します… >。
This document restricts the MP_UNREACH_NLRI attribute to carry only a single instance of <AFI, SAFI, ...>.
このドキュメントは、<AFI、サフィ…>のただ一つのインスタンスだけを運ぶためにMP_UNREACH_NLRI属性を制限します。
This document clarifies handling of an UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute.
このドキュメントはNLRIを全く運ばないUPDATEメッセージの取り扱いをはっきりさせます、MP_REACH_NLRI属性でコード化されたものを除いて。
This document clarifies error handling in the presence of MP_REACH_NLRI or MP_UNREACH_NLRI attributes.
このドキュメントは_MP REACH_NLRIの面前でエラー処理かMP_UNREACH_NLRI属性をはっきりさせます。
This document specifies the use of BGP Capabilities Advertisements in conjunction with multi-protocol extensions.
このドキュメントはマルチプロトコル拡大に関連してBGP Capabilities Advertisementsの使用を指定します。
Finally, this document includes the "IANA Consideration" section.
最終的に、このドキュメントは「IANAの考慮」セクションを含んでいます。
12. Security Considerations
12. セキュリティ問題
This extension to BGP does not change the underlying security issues inherent in the existing BGP.
BGPへのこの拡大は既存のBGPの固有である基本的な安全保障問題を変えません。
13. Acknowledgements
13. 承認
The authors would like to thank members of the IDR Working Group for their review and comments.
作者は彼らのレビューとコメントについてIDR作業部会のメンバーに感謝したがっています。
Bates, et al. Standards Track [Page 10] RFC 4760 Multiprotocol Extensions for BGP-4 January 2007
ベイツ、他 BGP-2007年1月4日の標準化過程[10ページ]RFC4760Multiprotocol拡張子
14. Normative References
14. 引用規格
[BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement
with BGP-4", RFC 3392, November 2002.
[BGP-上限] チャンドラとR.とJ.Scudder、「BGP-4インチがある能力広告、RFC3392、2002年11月。」
[BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP-4]Rekhter、Y.、李、T.、およびS.野兎、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC4271 2006年1月。
[IANA-AF] "Address Family Numbers", Reachable from
http://www.iana.org/numbers.html
http://www.iana.org/numbers.html から届いている[IANA-AF]「アドレスファミリーナンバ」
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020, February
2005.
[RFC4020]Kompella、K.とA.ジニン、「標準化過程コード・ポイントの早めのIANA配分」BCP100、2005年2月のRFC4020。
Authors' Addresses
作者のアドレス
Tony Bates Cisco Systems, Inc. EMail: tbates@cisco.com
トニーはシスコシステムズInc.メールを和らげます: tbates@cisco.com
Ravi Chandra Sonoa Systems EMail: rchandra@sonoasystems.com
ラービーチャンドラSonoaシステムはメールされます: rchandra@sonoasystems.com
Dave Katz Juniper Networks, Inc. EMail: dkatz@juniper.net
デーヴキャッツJuniperはInc.メールをネットワークでつなぎます: dkatz@juniper.net
Yakov Rekhter Juniper Networks, Inc. EMail: yakov@juniper.net
ヤコフRekhter JuniperはInc.メールをネットワークでつなぎます: yakov@juniper.net
Bates, et al. Standards Track [Page 11] RFC 4760 Multiprotocol Extensions for BGP-4 January 2007
ベイツ、他 BGP-2007年1月4日の標準化過程[11ページ]RFC4760Multiprotocol拡張子
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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機能のための基金は現在、インターネット協会によって提供されます。
Bates, et al. Standards Track [Page 12]
ベイツ、他 標準化過程[12ページ]
一覧
スポンサーリンク
