[要約] RFC 2858は、BGP-4のマルチプロトコル拡張に関する仕様であり、異なるプロトコル間の経路情報交換を可能にする。目的は、BGP-4の機能を拡張し、インターネットの経路選択における柔軟性と効率性を向上させること。
Network Working Group T. Bates
Request for Comments: 2858 Y. Rekhter
Obsoletes: 2283 Cisco Systems
Category: Standards Track R. Chandra
Redback Networks Inc
D. Katz
Juniper Networks
June 2000
Multiprotocol Extensions for BGP-4
BGP-4のマルチプロトコル拡張
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions.
現在、BGP-4 [BGP-4]は、IPv4 [IPv4]に対してのみルーティング情報を運ぶことができます。このドキュメントでは、BGP-4への拡張機能を定義して、複数のネットワークレイヤープロトコル（IPv6、IPXなどなど）のルーティング情報を運ぶことができます。拡張機能は後方互換です - 拡張機能をサポートするルーターは、拡張機能をサポートしないルーターと相互運用できます。
This document obsoletes RFC 2283.
このドキュメントは、RFC 2283を廃止します。
The only three pieces of information carried by 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 associated a particular Network Layer protocol with NLRI. To identify individual Network Layer protocols this document uses Address Family, as defined in [RFC1700].
IPv4固有のBGP-4によって運ばれる唯一の3つの情報は、（a）next_hop属性（IPv4アドレスとして表現）、（b）アグリゲーター（IPv4アドレスを含む）、および（c）NLRI（IPv4として表現されています。アドレスプレフィックス）。このドキュメントでは、BGPスピーカー（このドキュメントで定義されているマルチプロトコル機能をサポートするものを含む）がIPv4アドレス（特にアグリゲーター属性で使用される）が必要であると想定しています。したがって、BGP-4が複数のネットワークレイヤープロトコルのルーティングをサポートできるようにするために、BGP-4に追加する必要がある2つのものは（a）特定のネットワークレイヤープロトコルを次のホップ情報と関連付ける機能です（b）特定のネットワークレイヤープロトコルをNLRIに関連付ける機能。個々のネットワークレイヤープロトコルを識別するために、このドキュメントは[RFC1700]で定義されているアドレスファミリを使用します。
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.
さらに、次のホップ情報（Next_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つの新しい属性、マルチプロトコルリーチ可能なNLRI（MP_REACH_NLRI）、およびマルチプロトコル継続性NLRI（MP_UNREACH_NLRI）を使用します。最初のもの（MP_REACH_NLRI）は、これらの目的地への転送に使用される次のホップ情報とともに、リーチ可能な目的地のセットを運ぶために使用されます。2番目のもの（MP_UNREACH_NLRI）は、到達不可能な目的地のセットを運ぶために使用されます。これらの属性はどちらもオプションであり、非転換です。このようにして、マルチプロトコル機能をサポートしていないBGPスピーカーは、これらの属性にある情報を無視し、他のBGPスピーカーに渡すことはありません。
2. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14):
2. Multiprotocol Reachable NLRI -MP_REACH_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) ルーターが、ネットワークレイヤーリーチビリティ情報フィールドに次のホップとして使用されるルーターのネットワークレイヤーアドレスをMP_NLRI属性のフィールドに宣伝できるようにします。
(c) to allow a given router to report some or all of the Subnetwork Points of Attachment (SNPAs) that exist within the local system
(c) 特定のルーターが、ローカルシステム内に存在するアタッチメントのサブネットワークポイント（SNPA）の一部またはすべてを報告できるようにするには
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) |
+---------------------------------------------------------+
| Number of SNPAs (1 octet) |
+---------------------------------------------------------+
| Length of first SNPA(1 octet) |
+---------------------------------------------------------+
| First SNPA (variable) |
+---------------------------------------------------------+
| Length of second SNPA (1 octet) |
+---------------------------------------------------------+
| Second SNPA (variable) |
+---------------------------------------------------------+
| ... |
+---------------------------------------------------------+
| Length of Last SNPA (1 octet) |
+---------------------------------------------------------+
| Last SNPA (variable) |
+---------------------------------------------------------+
| Network Layer Reachability Information (variable) |
+---------------------------------------------------------+
The use and meaning of these fields are as follows:
これらのフィールドの使用と意味は次のとおりです。
Address Family Identifier:
住所ファミリ識別子：
This field carries the identity of the Network Layer protocol associated with the Network Address that follows. Presently defined values for this field are specified in RFC 1700 (see the Address Family Numbers section).
このフィールドは、次のネットワークアドレスに関連付けられたネットワークレイヤープロトコルのIDを担います。このフィールドの現在定義されている値は、RFC 1700で指定されています（アドレスファミリ番号セクションを参照）。
Subsequent Address Family Identifier:
後続の住所ファミリ識別子：
This field provides additional information about the type of the Network Layer Reachability Information carried in the attribute.
このフィールドは、属性に掲載されたネットワークレイヤーリーチ可能性情報のタイプに関する追加情報を提供します。
Length of Next Hop Network Address:
次のホップネットワークアドレスの長さ：
A 1 octet field whose value expresses the length of the "Network Address of Next Hop" field as 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
宛先システムへのパス上の次のルーターのネットワークアドレスを含む可変長フィールド
Number of SNPAs:
スナップの数：
A 1 octet field which contains the number of distinct SNPAs to be listed in the following fields. The value 0 may be used to indicate that no SNPAs are listed in this attribute.
次のフィールドにリストされる個別のSNPAの数を含む1オクテットフィールド。値0を使用して、この属性にSNPAがリストされていないことを示すことができます。
Length of Nth SNPA:
NTH SNPAの長さ：
A 1 octet field whose value expresses the length of the "Nth SNPA of Next Hop" field as measured in semi-octets
セミクテットで測定されているように、値が「次のホップのn番目のSNPA」フィールドの長さを値と表現する1オクテットフィールド
Nth SNPA of Next Hop:
次のホップのnth snpa：
A variable length field that contains an SNPA of the router whose Network Address is contained in the "Network Address of Next Hop" field. The field length is an integral number of octets in length, namely the rounded-up integer value of one half the SNPA length expressed in semi-octets; if the SNPA contains an odd number of semi-octets, a value in this field will be padded with a trailing all-zero semi-octet.
ネットワークアドレスが「ネクストホップのネットワークアドレス」フィールドに含まれているルーターのSNPAを含む可変長フィールド。フィールドの長さは、長さのオクテットの積分数、すなわち、丸められた整数値の半分の丸められた整数値の半分の長さで発現されているSNPAの長さの半分です。SNPAに奇数のセミククテットが含まれている場合、このフィールドの値には、後続の全ゼロセミオクテットがパッドにされます。
Network Layer Reachability Information:
ネットワークレイヤーの到達可能性情報：
A variable length field that lists NLRI for the feasible routes that are being advertised in this attribute. 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.
この属性で宣伝されている実行可能なルートのNLRIをリストする可変長さフィールド。後続のアドレスファミリ識別子フィールドが、このドキュメントで定義されている値の1つに設定されると、各NLRIは、このドキュメントの「NLRIエンコード」セクションで指定されているようにエンコードされます。
The next hop information carried in the MP_REACH_NLRI path attribute defines the Network Layer address of the border router that should be used as the next hop to the destinations listed in the MP_NLRI attribute in the UPDATE message. When advertising a MP_REACH_NLRI attribute to an external peer, a router may use one of its own interface addresses in the next hop component of the attribute, provided the external peer to which the route is being advertised shares a common subnet with the next hop address. This is known as a "first party" next hop. A BGP speaker can advertise to an external peer an interface of any internal peer router in the next hop component, provided the external peer to which the route is being advertised shares a common subnet with the next hop address. This is known as a "third party" next hop information. A BGP speaker can advertise any external peer router in the next hop component, provided that the Network Layer address of this border router was learned from an external peer, and the external peer to which the route is being advertised shares a common subnet with the next hop address. This is a second form of "third party" next hop information.
MP_REACH_NLRIパス属性に掲載された次のホップ情報は、更新メッセージのMP_NLRI属性にリストされている宛先の次のホップとして使用する必要があるボーダールーターのネットワークレイヤーアドレスを定義します。MP_REACH_NLRI属性を外部ピアに宣伝する場合、ルーターが属性の次のホップコンポーネントで独自のインターフェイスアドレスのいずれかを使用する場合があります。これは「ファーストパーティー」次のホップとして知られています。BGPスピーカーは、次のホップコンポーネントの内部ピアルーターのインターフェイスを外部ピアに宣伝できます。これは、「サードパーティ」の次のホップ情報として知られています。BGPスピーカーは、このボーダールーターのネットワークレイヤーアドレスが外部ピアから学習され、ルートが宣伝されている外部ピアが次のサブネットと共通のサブネットを共有している場合、BGPスピーカーは次のホップコンポーネントで任意の外部ピアルーターを宣伝できます。ホップアドレス。これは、「サードパーティ」の次のホップ情報の2番目の形式です。
Normally the next hop information is chosen such that the shortest available path will be taken. A BGP speaker must be able to support disabling advertisement of third party next hop information to handle imperfectly bridged media or for reasons of policy.
通常、次のホップ情報が選択され、最短のパスが取られるようになります。BGPスピーカーは、サードパーティの次のホップ情報の広告の無効化をサポートして、不完全に橋渡しされたメディアまたはポリシーの理由で処理することをサポートできる必要があります。
A BGP speaker must never advertise an address of a peer to that peer as a next hop, for a route that the speaker is originating. A BGP speaker must never install a route with itself as the next hop.
BGPスピーカーは、スピーカーが生まれているルートについては、次のホップとしてピアのアドレスをそのピアに宣伝しないでください。BGPスピーカーは、次のホップとしてそれ自体のルートを決してインストールしてはなりません。
When a BGP speaker advertises the route to an internal peer, the advertising speaker should not modify the next hop information associated with the route. When a BGP speaker receives the route via an internal link, it may forward packets to the next hop address if the address contained in the attribute is on a common subnet with the local and remote BGP speakers.
BGPスピーカーが内部ピアへのルートを宣伝する場合、広告スピーカーはルートに関連付けられた次のホップ情報を変更してはなりません。BGPスピーカーが内部リンクを介してルートを受信すると、属性に含まれるアドレスがローカルおよびリモートBGPスピーカーの共通サブネット上にある場合、次のホップアドレスにパケットを転送できます。
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. If such a message is received from an external peer, the local system shall check whether the leftmost AS in the AS_PATH attribute is equal to the autonomous system number of the peer than sent the message. If that is not the case, the local system shall send the NOTIFICATION message with Error Code UPDATE Message Error, and the Error Subcode set to Malformed AS_PATH.
MP_REACH_NLRIを運ぶ更新メッセージには、OriginとAS_Path属性（EBGPとIBGP交換の両方）も搭載する必要があります。さらに、IBGP交換では、そのようなメッセージはLocal_Pref属性も運ぶ必要があります。そのようなメッセージが外部ピアから受信された場合、ローカルシステムは、AS_PATH属性のような左端がメッセージを送信するよりもピアの自律システム番号に等しいかどうかを確認するものとします。そうでない場合、ローカルシステムは、エラーコード更新メッセージエラーを使用して通知メッセージを送信し、エラーサブコードがAS_PATHの奇形に設定されます。
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.
MP_REACH_NLRI属性にエンコードされたもの以外のNLRIを持たないアップデートメッセージは、Next_Hop属性を運ぶべきではありません。そのようなメッセージにNext_hop属性が含まれている場合、メッセージを受信するBGPスピーカーはこの属性を無視する必要があります。
3. Multiprotocol Unreachable NLRI - MP_UNREACH_NLRI (Type Code 15):
3. 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) |
+---------------------------------------------------------+
The use and the meaning of these fields are as follows:
これらのフィールドの使用と意味は次のとおりです。
Address Family Identifier:
住所ファミリ識別子：
This field carries the identity of the Network Layer protocol associated with the NLRI that follows. Presently defined values for this field are specified in RFC 1700 (see the Address Family Numbers section).
このフィールドは、次のNLRIに関連付けられたネットワークレイヤープロトコルのIDを担います。このフィールドの現在定義されている値は、RFC 1700で指定されています（アドレスファミリ番号セクションを参照）。
Subsequent Address Family Identifier:
後続の住所ファミリ識別子：
This field provides additional information about the type of the Network Layer Reachability Information carried in the attribute.
このフィールドは、属性に掲載されたネットワークレイヤーリーチ可能性情報のタイプに関する追加情報を提供します。
Withdrawn Routes:
撤回したルート：
A variable length field that lists NLRI for the routes that are being withdrawn from service. 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.
サービスから撤回されているルートのNLRIをリストする可変長さフィールド。後続のアドレスファミリ識別子フィールドが、このドキュメントで定義されている値の1つに設定されると、各NLRIは、このドキュメントの「NLRIエンコード」セクションで指定されているようにエンコードされます。
An UPDATE message that contains the MP_UNREACH_NLRI is not required to carry any other path attributes.
MP_UNREACH_NLRIを含む更新メッセージは、他のパス属性を運ぶ必要はありません。
The Network Layer Reachability information is encoded as one or more 2-tuples of the form <length, prefix>, whose fields are described below:
ネットワークレイヤーの到達可能性情報は、フォーム<length、prefix>の1つまたは複数の2タプルとしてエンコードされます。そのフィールドは以下に説明します。
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
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).
長さフィールドは、アドレスプレフィックスのビットの長さを示します。ゼロの長さは、すべて（アドレスファミリで指定されている）すべてのアドレス（接頭辞、それ自体、ゼロオクテット）に一致するプレフィックスを示します。
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.
プレフィックスフィールドには、アドレスプレフィックスに続いて、フィールドの終わりをオクテットの境界に落とすのに十分なトレーリングビットが含まれます。トレーリングビットの値は無関係であることに注意してください。
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属性で運ばれる後続のアドレスファミリ識別子フィールドの次の値を定義します。
1 - Network Layer Reachability Information used for unicast forwarding
1-ユニキャストの転送に使用されるネットワークレイヤーリーチ可能性情報
2 - Network Layer Reachability Information used for multicast forwarding
2-マルチキャストの転送に使用されるネットワークレイヤーリーチ性情報
3 - Network Layer Reachability Information used for both unicast and multicast forwarding
3-ユニキャストとマルチキャストの両方の転送に使用されるネットワークレイヤーリーチ可能性情報
If a BGP speaker receives from a neighbor an Update message that contains the MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and 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スピーカーが隣人からMP_REACH_NLRIまたはMP_UNREACH_NLRI属性を含む更新メッセージを受信し、スピーカーが属性が間違っていると判断した場合、スピーカーはAFI/SAFIが同じ隣人から受け取ったすべてのBGPルートを削除する必要があります。誤ったMP_REACH_NLRIまたはMP_UNREACH_NLRI属性に入れられたもの。更新メッセージが受信されたBGPセッションの期間中、スピーカーはそのセッションで受け取ったAFI/SAFIでその後のすべてのルートを無視する必要があります。
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".
さらに、スピーカーは、更新メッセージが受信された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.
マルチプロトコル拡張機能を使用するBGPスピーカーは、機能広告手順[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:
機能オプションのパラメーターのフィールドは、次のように設定されています。機能コードフィールドは1に設定されています（マルチプロトコル拡張機能を示します）。機能の長さフィールドは4に設定されています。機能値フィールドは次のように定義されています。
The use and meaning of this field is as follow:
このフィールドの使用と意味は次のとおりです。
0 7 15 23 31
+-------+-------+-------+-------+
| AFI | Res. | SAFI |
+-------+-------+-------+-------+
AFI - Address Family Identifier (16 bit), encoded the same way as in the Multiprotocol Extensions
AFI-マルチプロトコル拡張機能と同じようにエンコードされたファミリ識別子（16ビット）
Res. - Reserved (8 bit) field. Should be set to 0 by the sender and ignored by the receiver.
res。 - 予約済み（8ビット）フィールド。送信者によって0に設定され、受信機によって無視される必要があります。
SAFI - Subsequent Address Family Identifier (8 bit), encoded the same way as in the Multiprotocol Extensions.
SAFI-その後のアドレスファミリ識別子（8ビット）は、マルチプロトコル拡張機能と同じ方法でエンコードされています。
A speaker that supports multiple <AFI, SAFI> tuples includes them as multiple Capabilities in the Capabilities Optional Parameter.
複数の<AFI、Safi> Tulpleをサポートするスピーカーには、機能オプションのパラメーターに複数の機能として含まれています。
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> routes.
特定の<afi、safi>のBGPスピーカー間のルーティング情報の双方向交換を行うには、そのようなスピーカーはそれぞれ他のスピーカーに（機能広告メカニズムを介して）その特定の<afi、safiをサポートする機能を宣伝する必要があります。>ルート。
As specified in this document, the MPL_REACH_NLRI and MP_UNREACH_NLRI attributes contain the Subsequence Address Family Identifier (SAFI) field. The SAFI name space is defined in Section 9. The IANA will maintain and register values for the SAFI namespace as follows. SAFI value 0 is reserved. SAFI values 1, 2, and 3 are assigned in this document. SAFI values 4 through 63 are to be assigned by IANA using the "IETF Consensus" policy defined in RFC 2434. SAFI values 64 through 127 are to be assigned by IANA, using the "First Come First Served" policy defined in RFC 2434. SAFI values 128 through 255 are for "private use", and values in this range are not to be assigned by IANA.
このドキュメントで指定されているように、MPL_REACH_NLRIおよびMP_UNREACH_NLRI属性には、サブシーケンスアドレスファミリ識別子（SAFI）フィールドが含まれています。SAFI名のスペースはセクション9で定義されています。IANAは、次のようにSAFI名空間の値を維持および登録します。SAFI値0は予約されています。SAFI値1、2、および3は、このドキュメントに割り当てられています。SAFI値4〜63は、RFC 2434で定義された「IETFコンセンサス」ポリシーを使用してIANAによって割り当てられます。SAFI値64から127は、RFC 2434で定義された「First Come First Serve」ポリシーを使用してIANAによって割り当てられます。値128〜255は「プライベート使用」用であり、この範囲の値はIANAによって割り当てられません。
This document restricts the MP_REACH_NLRI attribute to carry only a single instance of <AFI, SAFI, Next Hop Information, ...>.
このドキュメントは、MP_REACH_NLRI属性を制限して、<AFI、SAFI、次のホップ情報の単一インスタンスのみを搭載しています...>。
This document restricts the MP_UNREACH_NLRI attribute to carry only a single instance of <AFI, SAFI, ...>.
このドキュメントは、MP_UNREACH_NLRI属性を制限して、<afi、safi、...>の単一インスタンスのみを携帯しています。
This document clarifies handling of an UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute.
このドキュメントでは、MP_REACH_NLRI属性にエンコードされたもの以外の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機能広告の使用を指定しています。
Finally, this document includes the "IANA Consideration" Section.
最後に、このドキュメントには「IANA考慮事項」セクションが含まれています。
This extension to BGP does not change the underlying security issues inherent in the existing BGP [Heffernan].
BGPへのこの拡張は、既存のBGP [Heffernan]に固有の根本的なセキュリティ問題を変更しません。
The authors would like to thank members of the IDR Working Group for their review and comments.
著者は、IDRワーキンググループのメンバーのレビューとコメントに感謝したいと思います。
[BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 2842, May 2000.
[BGP-CAP] Chandra、R。およびJ. Scudder、「BGP-4による機能広告」、RFC 2842、2000年5月。
[BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[BGP-4] Rekhter、Y。およびT. Li、「Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[Heffernan] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[Heffernan] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IPv4] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1700] Postel, J. and J. K. Reynolds, "Assigned Numbers", STD 2, RFC 1700, October 1994. (see also http://www.iana.org/iana/assignments.html)
[RFC1700] Postel、J。およびJ. K. Reynolds、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。
Tony Bates Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Tony Bates Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134
EMail: tbates@cisco.com
Ravi Chandra Redback Networks Inc. 350, Holger Way San Jose, CA 95134
Ravi Chandra Redback Networks Inc. 350、Holger Way San Jose、CA 95134
EMail: rchandra@redback.com
Dave Katz Juniper Networks, Inc. 3260 Jay St. Santa Clara, CA 95054
Dave Katz Juniper Networks、Inc。3260 Jay St. Santa Clara、CA 95054
EMail: dkatz@jnx.com
Yakov Rekhter Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Yakov Rekhter Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134
EMail: yakov@cisco.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。