[要約] RFC 4760は、BGP-4に対するマルチプロトコル拡張の仕様を定めたものです。このRFCの目的は、BGP-4を使用して異なるプロトコル間での経路情報の交換を可能にすることです。
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
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）The IETF Trust（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.
このドキュメントでは、BGP-4への拡張機能を定義して、複数のネットワークレイヤープロトコル（IPv6、IPX、L3VPNなど）のルーティング情報を運ぶことができます。拡張機能は後方互換です - 拡張機能をサポートするルーターは、拡張機能をサポートしないルーターと相互運用できます。
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 [BGP-4]によって運ばれる唯一の3つの情報は、NLRI（IPv4アドレスプレフィックスとして表されます）。このドキュメントでは、BGPスピーカー（このドキュメントで定義されているマルチプロトコル機能をサポートするものを含む）がIPv4アドレス（特にアグリゲーター属性で使用される）が必要であると想定しています。したがって、BGP-4が複数のネットワークレイヤープロトコルのルーティングをサポートできるようにするために、BGP-4に追加する必要がある2つのことは（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）は、これらの目的地への転送に使用される次のホップ情報とともに、リーチ可能な目的地のセットを運ぶために使用されます。2番目のもの（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]で説明されているように解釈されます。
3. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14):
3. 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属性の宣伝することを許可します。
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のアドレスファミリ番号レジストリ[IANA-AF]で指定されています。
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.
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パス属性に掲載された次のホップ情報は、更新メッセージの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]).
次のホップ情報のルールは、next_hop bgp属性に掲載された情報のルールと同じです（[BGP-4]のセクション5.1.3を参照）。
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を運ぶ更新メッセージには、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.
MP_REACH_NLRI属性にエンコードされたもの以外の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.
更新メッセージには、同じアドレスのプレフィックス（同じ<afi、safi>）を次の1つ以上のフィールドに含めるべきではありません。撤回ルートフィールド、ネットワークリーチ可能性情報フィールド、mp_reach_nlriフィールド、mp_unreach_nlriフィールド。この形式の更新メッセージの処理は未定義です。
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) |
+---------------------------------------------------------+
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のアドレスファミリ番号レジストリ[IANA-AF]で指定されています。
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.
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.
後続のアドレスファミリ識別子フィールドが、このドキュメントで定義されている値の1つに設定されると、各NLRIは、このドキュメントの「NLRIエンコード」セクションで指定されているようにエンコードされます。
An UPDATE message that contains the MP_UNREACH_NLRI is not required to carry any other path attributes.
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
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属性を含む更新メッセージを受信し、スピーカーが属性が間違っていると判断した場合、スピーカーは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に設定されています。機能値フィールドは次のように定義されています。
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.
フィールド値を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> route.
特定の<afi、safi>のBGPスピーカー間のルーティング情報の双方向交換を行うには、そのようなスピーカーはそれぞれ他のスピーカーに（機能広告メカニズムを介して）その特定の<afi、safiをサポートする機能を宣伝する必要があります。>ルート。
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 Value 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値5〜63は、[RFC2434]で定義されている標準アクションプロセス、または[RFC4020]で定義されている初期のIANA割り当てプロセスのいずれかを使用して、IANAによって割り当てられます。
- SAFI values 67 through 127 are to be assigned by IANA, using the "First Come First Served" policy, defined in RFC 2434.
- Safi Values 67から127は、RFC 2434で定義されている「First Come First Servent」ポリシーを使用して、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値128〜240は、以前の「プライベート使用」範囲の一部です。この文書の承認時に、ルーティングエリアディレクターによって未使用の値が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.
- SAFI値241〜254は「私的使用」用であり、この範囲の値は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.
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, ...>.
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.
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] Chandra、R。およびJ. Scudder、「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.、Li、T。、およびS. Hares、「A Border Gateway Protocol 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Zinin、「標準の初期の配分追跡コードポイント」、BCP 100、RFC 4020、2005年2月。
Authors' Addresses
著者のアドレス
Tony Bates Cisco Systems, Inc. EMail: tbates@cisco.com
Tony Bates Cisco Systems、Inc。メール：tbates@cisco.com
Ravi Chandra Sonoa Systems EMail: rchandra@sonoasystems.com
Dave Katz Juniper Networks, Inc. EMail: dkatz@juniper.net
Dave Katz Juniper Networks、Inc。メール：dkatz@juniper.net
Yakov Rekhter Juniper Networks, Inc. EMail: yakov@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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.