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
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.
著作権（C）インターネット協会（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]のルーティング情報を搬送することが可能です。この文書は、複数のネットワーク層プロトコル（例えば、IPv6の、IPXなど）のためのルーティング情報を搬送することを可能にするために、BGP-4への拡張を定義します。拡張子は、下位互換性がある - の拡張をサポートしていないルータと相互運用できる機能拡張をサポートするルータ。
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].
3つのだけのIPv4特異的であるBGP-4によって搬送される情報である（A）（IPv4アドレスとして表される）NEXT_HOP属性は、（b）は、アグリゲータ（IPv4アドレスが含まれている）、及び（c）NLRI（IPv4のように表現アドレスプレフィックス）。この文書では、（この文書で定義されたマルチプロトコル機能をサポートしているものを含む）すべてのBGPスピーカーは、（AGGREGATOR属性で、とりわけ、使用される）IPv4アドレスを持つ必要があることを前提としています。したがって、ある（a）は、次のホップ情報を特定のネットワーク層プロトコルを関連付ける機能、および（b複数のネットワーク層のためのBGP-4に追加されなければならない2人のだけのことをプロトコルルーティングをサポートするために、BGP-4を有効にします）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）は、これらの宛先に転送するために使用される次のホップ情報と一緒に届いている目的地のセットを運ぶために使用されます。第1（MP_UNREACH_NLRI）が到達不能な目的地のセットを運ぶために使用されます。これらの属性の両方は別売と非推移しています。この方法は、マルチプロトコル機能をサポートしていないBGPスピーカは、ちょうどこれらの属性で運ばれた情報を無視し、他のBGPスピーカにそれを渡しません。
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）は、指定されたルータが、ローカルシステム内に存在する添付のサブネットワークポイント（SNPAs）の一部またはすべてを報告することを可能にします
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).
このフィールドは、次のネットワークアドレスに関連付けられたネットワーク層プロトコルのアイデンティティを運びます。現在、このフィールドの定義された値は、（アドレスファミリ番号のセクションを参照してください）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.
次のフィールドにリストされる別個SNPAsの数が含まれている1つのオクテットフィールド。値0はSNPAsこの属性にリストされていないことを示すために使用されてもよいです。
Length of Nth SNPA:
N番目の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:
ネクストホップのN番目の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をリストし可変長フィールド。次のアドレスファミリ識別子フィールドは、この文書で定義された値のいずれかに設定されている場合、各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パス属性で運ばネクストホップ情報は、UPDATEメッセージにMP_NLRI属性に記載された宛先へのネクストホップとして使用されるべき境界ルータのネットワーク層アドレスを定義します。外部ピアにMP_REACH_NLRI属性を広告する場合、ルータは、属性の次ホップ成分に独自のインタフェースアドレスのいずれかを使用することができ、経路は株式をネクストホップアドレスと共通のサブネットをアドバタイズしているため、外部ピアを提供しました。これを「第1党」ネクストホップとして知られています。 BGPスピーカは、外部ピアに次ホップ成分の任意の内部ピア・ルータのインタフェースを宣伝することができ、経路は、次ホップアドレスと共通のサブネットアドバタイズ共有されているために、外部ピアを提供しました。これは、「第三者」ネクストホップ情報として知られています。 BGPスピーカは、次のホップ成分の任意の外部ピアルータを宣伝することができ、この境界ルータのネットワーク層アドレスが外部ピアから学習したことを提供、および外部のピアがルートは次のと株式に共通のサブネットを宣伝されていますホップアドレス。これは、「第三者」のネクストホップ情報の二番目の形式です。
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を運ぶUPDATEメッセージは、（EBGPおよびIBGP交換の両方で）ORIGINとAS_PATH属性を運ばなければなりません。また、IBGP交換にそのようなメッセージは、LOCAL_PREF属性を運ばなければなりません。そのようなメッセージは、外部ピアから受信された場合、ローカルシステムは、メッセージを送信したよりAS_PATH属性にAS左端ピアの自律システム番号と等しいかどうかをチェックしなければなりません。それ以外の場合は、ローカルシステムは、エラーコードUPDATEメッセージエラーと通知メッセージ、および不正な形式の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.
何NLRIを担持していない更新メッセージは、MP_REACH_NLRI属性でエンコードされた以外の、NEXT_HOP属性を運ぶべきではありません。このようなメッセージがNEXT_HOP属性が含まれている場合は、メッセージを受信したBGPスピーカはこの属性を無視しなければなりません。
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に関連したネットワーク層プロトコルのアイデンティティを運びます。現在、このフィールドの定義された値は、（アドレスファミリ番号のセクションを参照してください）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をリストし可変長フィールド。次のアドレスファミリ識別子フィールドは、この文書で定義された値のいずれかに設定されている場合、各NLRIは、この文書の「NLRIエンコード」セクションで指定されるように符号化されます。
An UPDATE message that contains the MP_UNREACH_NLRI is not required to carry any other path attributes.
MP_UNREACH_NLRIが含まれているUPDATEメッセージは、他のパス属性を運ぶために必要とされていません。
The Network Layer Reachability information is encoded as one or more 2-tuples of the form <length, prefix>, whose fields are described below:
ネットワーク層到達可能性情報は、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).
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フィールドは、オクテット境界上のフィールドの秋の終わりを作るのに十分な末尾のビットに続くアドレスプレフィックスが含まれています。後続のビットの値は無関係であることに留意されたいです。
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属性が含まれているUpdateメッセージを受信し、スピーカーは属性が誤っていると判断し、スピーカーは、そのAFI / SAFIが同じであるネイバーから受信したすべてのBGPルートを削除する必要がある場合間違ったMP_REACH_NLRIかMP_UNREACH_NLRI属性で運ば1。更新メッセージを受信した上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.
サフィ - 次のアドレスファミリー識別子（8ビット）、マルチプロトコル拡張と同様に符号化されました。
A speaker that supports multiple <AFI, SAFI> tuples includes them as multiple Capabilities in the Capabilities Optional Parameter.
複数の<AFI、SAFI>タプルをサポートしていますスピーカーは、彼らに能力任意パラメータのように複数の機能が含まれています。
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.
BGPスピーカの対の間に特定の<AFI、SAFI>のためのルーティング情報の双方向の交換を持つように、そのような各スピーカは、その特定の<AFI、サフィをサポートするために、（能力広告機構を介して）他の能力をアドバタイズする必要があります>ルート。
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
この文書で指定されているように、MPL_REACH_NLRIとMP_UNREACH_NLRI属性は、サブシーケンスアドレスファミリ識別子（SAFI）フィールドが含まれています。 SAFIの名前空間は、次のようにIANAがSAFI名前空間の値を維持し、登録します第9節で定義されています。 SAFI値0は予約されています。 SAFIは、1~2の値、および3は、この文書に割り当てられています。 SAFI 63を介して4サフィ「がまず最初に来る使用し、127スルー64はIANAによって割り当てられる値は、RFC 2434で定義された「IETFコンセンサス」ポリシーを使用して、IANAによって割り当てられる値
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.
役立った 『私的使用」RFC 2434 SAFIで定義されたポリシーは、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を運ばないUPDATEメッセージの取り扱いを明確にしています。
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]チャンドラ、R.及びJ.スカダー、 "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.李、 "ボーダーゲートウェイプロトコル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]ポステル、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]ポステル、J.およびJ. K.レイノルズ、 "割り当て番号"、STD 2、RFC 1700、1994年10月（またhttp://www.iana.org/iana/assignments.html参照）
Tony Bates Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
トニー・ベイツシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134
EMail: tbates@cisco.com
メールアドレス：tbates@cisco.com
Ravi Chandra Redback Networks Inc. 350, Holger Way San Jose, CA 95134
ラヴィチャンドラレッドバックネットワークス350、ホルガー・ウェイサンノゼ、CA 95134
EMail: rchandra@redback.com
メールアドレス：rchandra@redback.com
Dave Katz Juniper Networks, Inc. 3260 Jay St. Santa Clara, CA 95054
デイブ・カッツジュニパーネットワークス株式会社3260ジェイ・セントサンタクララ、CA 95054
EMail: dkatz@jnx.com
メールアドレス：dkatz@jnx.com
Yakov Rekhter Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
ヤコフ・レックターシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134
EMail: yakov@cisco.com
メールアドレス：yakov@cisco.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。