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
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 IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書は、複数のネットワーク層プロトコル（例えば、IPv6の、IPX、L3VPN、等）のためのルーティング情報を搬送することを可能にするために、BGP-4への拡張を定義します。拡張子は、下位互換性がある - の拡張をサポートしていないルータと相互運用できる機能拡張をサポートするルータ。
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).
IPv4の特異的であるBGP-4によって搬送される情報のわずか3個の[BGP-4]は、（a）NEXT_HOP属性（IPv4アドレスとして表される）、（b）は、アグリゲータ（IPv4アドレスが含まれている）、及び（c） NLRI（IPv4アドレスプレフィックスとして表されます）。この文書では、（この文書で定義されたマルチプロトコル機能をサポートしているものを含む）すべてのBGPスピーカーは、（AGGREGATOR属性で、とりわけ、使用される）IPv4アドレスを持つ必要があることを前提としています。したがって、複数のネットワーク層プロトコル、BGP-4に追加されなければならない2つだけのルーティングをサポートするために、BGP-4を有効にしている（A）（次のホップ情報を特定のネットワーク層プロトコルを関連付け、および能力B）NLRIで、特定のネットワーク層プロトコルを関連付ける機能。 NLRIの次ホップ情報及びセマンティクスに関連する個々のネットワーク層プロトコルを識別するために、[IANA-AF]で定義されるように、このドキュメントは、アドレスファミリの組み合わせを使用し、次のアドレスファミリー（この文書に記載されているように）。
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スピーカにそれを渡しません。
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", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
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属性のネットワーク・レイヤ到着可能性情報フィールドに記載された宛先へのネクストホップとして使用されるべきルータのネットワーク層アドレスをアドバタイズするルーターを許可します。
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) |
+---------------------------------------------------------+
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.
次のアドレスファミリ識別子フィールドと組み合わせて、このフィールドには、次のホップフィールドで運ばれたアドレスが属している必要がありますするネットワーク層プロトコルのセット、ネクストホップのアドレスがエンコードされる方法、およびネットワークのセマンティクスを識別します次のレイヤ到達可能性情報。ネクストホップが複数のネットワーク層プロトコルであることが許可されている場合、ネクストホップの符号化は、ネットワーク層プロトコルを決定するための方法を提供しなければなりません。
Presently defined values for the Address Family Identifier field are specified in the IANA's Address Family Numbers registry [IANA-AF].
アドレスファミリ識別子フィールドに現在定義された値は、[IANA-AF] IANAのアドレスファミリ番号レジストリで指定されています。
Subsequent Address Family Identifier (SAFI):
次のアドレスファミリ識別子（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.
アドレスファミリ識別子フィールドと組み合わせて、このフィールドには、次のホップで運ばれたアドレスが属している必要がありますするネットワーク層プロトコルのセット、ネクストホップのアドレスがエンコードされる方法、およびネットワーク層到達可能性のセマンティクスを識別します以下の情報。ネクストホップが複数のネットワーク層プロトコルであることが許可されている場合、ネクストホップの符号化は、ネットワーク層プロトコルを決定するための方法を提供しなければなりません。
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.
デスティネーション・システムへのパス上の次のルータのネットワークアドレスが含まれている可変長フィールド。ネクストホップのネットワークアドレスに関連付けられたネットワーク層プロトコルは、属性で運ば<AFI、SAFI>の組み合わせによって識別されます。
Reserved:
予約：
A 1 octet field that MUST be set to 0, and SHOULD be ignored upon receipt.
0に設定しなければなりません、そして受信時に無視されるべき1つのオクテットフィールド。
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、SAFI>の組み合わせによって識別されます。
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エンコード」セクションで指定されるように符号化されます。
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属性に列挙された宛先へのネクストホップとして使用されるべきルータのネットワーク層アドレスを定義します。
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]).
ネクストホップ情報の規則は（[BGP-4]のセクション5.1.3を参照）NEXT_HOP 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.
MP_REACH_NLRIを運ぶUPDATEメッセージは、（EBGPおよびIBGP交換の両方で）ORIGINとAS_PATH属性を運ばなければなりません。また、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属性でエンコードされたもの以外の、NEXT_HOP属性を運ぶべきではありません。このようなメッセージがNEXT_HOP属性が含まれている場合は、メッセージを受信した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.
WITHDRAWN ROUTES分野、ネットワーク到達可能性情報フィールド、MP_REACH_NLRIフィールド、およびMP_UNREACH_NLRIフィールド：UPDATEメッセージは、次のフィールドの複数で（同じ<AFI、SAFI>の）同じアドレスプレフィックスを含めるべきではありません。この形式のUPDATEメッセージの処理は未定義です。
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 (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.
次のアドレスファミリ識別子フィールドと組み合わせて、このフィールドには、次のホップフィールドで運ばれたアドレスが属している必要がありますするネットワーク層プロトコルのセット、ネクストホップのアドレスがエンコードされる方法、およびネットワークのセマンティクスを識別します次のレイヤ到達可能性情報。ネクストホップが複数のネットワーク層プロトコルであることが許可されている場合、ネクストホップの符号化は、ネットワーク層プロトコルを決定するための方法を提供しなければなりません。
Presently defined values for the Address Family Identifier field are specified in the IANA's Address Family Numbers registry [IANA-AF].
アドレスファミリ識別子フィールドに現在定義された値は、[IANA-AF] IANAのアドレスファミリ番号レジストリで指定されています。
Subsequent Address Family Identifier (SAFI):
次のアドレスファミリ識別子（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.
アドレスファミリ識別子フィールドと組み合わせて、このフィールドには、次のホップで運ばれたアドレスが属している必要がありますするネットワーク層プロトコルのセット、ネクストホップのアドレスがエンコードされる方法、およびネットワーク層到達可能性のセマンティクスを識別します以下の情報。ネクストホップが複数のネットワーク層プロトコルであることが許可されている場合、ネクストホップの符号化は、ネットワーク層プロトコルを決定するための方法を提供しなければなりません。
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、SAFI>の組み合わせによって識別されます。
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エンコード」セクションで指定されるように符号化されます。
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 - ネットワーク層到達可能性情報は、マルチキャスト転送のために使用さ
An implementation MAY support all, some, or none of the Subsequent Address Family Identifier values defined in this document.
実装はすべて、いくつか、またはこのドキュメントで定義された次のアドレスファミリ識別子値のどれをサポートするかもしれません。
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スピーカーが隣人からMP_REACH_NLRIかMP_UNREACH_NLRI属性を含むUPDATEメッセージを受信し、スピーカーは属性が誤っていると判断した場合、スピーカーは、そのAFI / SAFIが同じであるネイバーから受信したすべてのBGPルートを削除する必要がある場合間違ったMP_REACH_NLRIかMP_UNREACH_NLRI属性で運ば1。 UPDATEメッセージを受信した上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".
また、スピーカは、UPDATEメッセージを受信した上BGPセッションを終了することができます。セッションは、「UPDATEメッセージエラー」/「オプション属性エラー」を示す通知メッセージコード/サブコードで終端する必要があります。
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に設定されている能力値フィールドは次のように定義されています。
0 7 15 23 31
+-------+-------+-------+-------+
| AFI | Res. | SAFI |
+-------+-------+-------+-------+
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は、 - アドレスファミリー識別子（16ビット）は、マルチプロトコルの拡張と同様に符号化されました
Res. - Reserved (8 bit) field. SHOULD be set to 0 by the sender and ignored by the receiver.
RES。 - 予約（8ビット）フィールド。送信者によって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.
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> route.
BGPスピーカの対の間に特定の<AFI、SAFI>のためのルーティング情報の双方向の交換を持つように、そのような各スピーカは、その特定の<AFI、サフィをサポートするために、（能力広告機構を介して）他の能力をアドバタイズしなければなりません>ルート。
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属性は、サブシーケンスアドレスファミリ識別子（SAFI）フィールドが含まれています。 SAFIの名前空間は、この文書で定義されています。 IANAが登録され、次のようにSAFI名前空間の値を維持します。
- SAFI values 1 and 2 are assigned in this document.
- SAFI値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.
- SAFI値3は予約されています。これは完全には実装されていませんでした使用のためにRFC 2858によって割り当てられたので、それは、この文書で推奨されていません。
- 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].
- SAFIは[RFC4020]で定義され、[RFC2434]で定義された標準化行動プロセス、または早期IANA割当処理のいずれかを使用してIANAによって割り当てられるべきである5〜63値。
- SAFI values 67 through 127 are to be assigned by IANA, using the "First Come First Served" policy, defined in RFC 2434.
- SAFIは、RFC 2434で定義された「まず最初に配信是非」ポリシーを使用して、127を通る67はIANAによって割り当てられる値。
- SAFI values 0 and 255 are reserved.
- SAFI値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.
- SAFI 240を介して、128は、前「私的使用」の範囲の一部である値。この文書の承認の時には、未使用の値は、ルーティングエリアディレクターによってIANAに提供されました。これらの未使用の値、139を介して、即ち、130、131、135、及び240を介して、141は、衝突を避けるために予約であると考えられます。
- SAFI values 241 through 254 are for "private use", and values in this range are not to be assigned by IANA.
- SAFIは〜254 241は、「私的使用」のためにされている値、およびこの範囲内の値は、IANAによって割り当てられることはありません。
This document makes the use of the next hop information consistent with the information carried in the NEXT_HOP BGP path attribute.
この文書では、NEXT_HOP BGPパス属性で運ばれた情報と一致し、次のホップ情報を利用します。
This document removes the definition of SAFI 3 and deprecates SAFI 3.
この文書では、SAFI 3の定義を削除し、SAFI 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.
この文書では、SAFIスペースのパーティションを変更します。具体的には、RFC 2858にSAFI 240を介して、128が「私的使用」の範囲の一部された値。この文書では、この範囲を、現在使用中の割り当てはIANAによって認識されることを指定し、未使用の値、すなわち130、131、139を介して135、及び240を介して、141は、予約された考慮すべきである。その
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.
この文書では、予約にSNPAsフィールドの数の名前を変更し、MP_REACH_NLRI属性からSNPA関連情報の残りの部分を削除します。
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.
BGPへのこの拡張は、既存のBGPに固有の基本的なセキュリティ問題を変更しません。
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 3392, November 2002.
[BGP-CAP]チャンドラ、R.及びJ.スカダー、 "BGP-4との機能広告"、RFC 3392、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）"、RFC 4271、2006年1月。
[IANA-AF] "Address Family Numbers", Reachable from http://www.iana.org/numbers.html
[IANA-AF] "アドレスファミリ番号"、http://www.iana.org/numbers.htmlから到達可能
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、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問題部に書くためのガイドライン"、BCP 26、RFC 2434、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配分"、BCP 100、RFC 4020、2005年2月。
Authors' Addresses
著者のアドレス
Tony Bates Cisco Systems, Inc. EMail: tbates@cisco.com
トニー・ベイツシスコシステムズ、株式会社Eメール：tbates@cisco.com
Ravi Chandra Sonoa Systems EMail: rchandra@sonoasystems.com
ラヴィチャンドラSonoaシステムズ電子メール：rchandra@sonoasystems.com
Dave Katz Juniper Networks, Inc. EMail: dkatz@juniper.net
デイブ・カッツジュニパーネットワークス、株式会社Eメール：dkatz@juniper.net
Yakov Rekhter Juniper Networks, Inc. EMail: yakov@juniper.net
ヤコフ・レックタージュニパーネットワークス、株式会社Eメール：yakov@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。