[要約] RFC 5549は、IPv6の次ホップを使用してIPv4ネットワークレイヤーの到達性情報を広告するための仕様です。このRFCの目的は、IPv6ネットワークでIPv4ネットワークへの接続を容易にすることです。
Network Working Group F. Le Faucheur
Request for Comments: 5549 E. Rosen
Category: Standards Track Cisco Systems
May 2009
Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop
IPv6の到達可能性情報の広告IPv6次のホップ
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
Multiprotocol BGP (MP-BGP) specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop.
Multiprotocol BGP（MP-BGP）は、次のホップフィールドに掲載されるアドレスが属するネットワーク層プロトコルのセットが、アドレスファミリ識別子（AFI）とその後のアドレスファミリ識別子（SAFI）によって決定されることを指定します。IPv4アドレスファミリの現在のAFI/SAFI定義には、IPv4ネットワークレイヤーリーチ可能性情報（NLRI）またはVPN-IPV4 NLRIを広告する場合、IPv4プロトコルに属する次のホップアドレスを宣伝するための規定のみがあります。このドキュメントは、IPv6プロトコルに属する次のホップアドレスを備えた広告IPv4 NLRIまたはVPN-IPV4 NLRIを許可するために必要な拡張機能を指定します。これは、IPv4 NLRIまたはVPN-IPV4 NLRIの次のホップのアドレスがIPv6プロトコルに属することを可能にするAFI/SAFI定義の拡張を含むことで構成されています。実際には、MP-BGPピアがIPv4 NLRIとVPN-IPV4 NLRIを次のHopで交換できるかどうかを動的に発見できるようにする新しいBGP機能に属します。
Table of Contents
目次
1. Introduction ....................................................2
2. Requirements Language ...........................................4
3. Extension of AFI/SAFI Definitions for the IPv4 Address Family ...4
4. Use of BGP Capability Advertisement .............................5
5. Operations ......................................................7
6. Usage Examples ..................................................7
6.1. IPv4 over IPv6 Core ........................................7
6.2. IPv4 VPN over IPv6 Core ....................................8
7. IANA Considerations .............................................8
8. Security Considerations .........................................8
9. Acknowledgments .................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
Multiprotocol BGP (MP-BGP) [RFC4760] specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). A number of existing AFI/SAFIs allow the Next Hop address to belong to a different address family than the Network Layer Reachability Information (NLRI). For example, the AFI/SAFI <25/65> used (as per [L2VPN-SIG]) in order to perform L2VPN auto-discovery, allows advertising NLRI that contains the identifier of a Virtual Private LAN Service (VPLS) instance or that identifies a particular pool of attachment circuits at a given Provider Edge (PE), while the Next Hop field contains the loopback address of a PE. Similarly, the AFI/SAFI <1/132> (defined in [RFC4684]) in order to advertise Route Target (RT) membership information, allows advertising NLRI that contains such RT membership information, while the Next Hop field contains the address of the advertising router.
Multiprotocol BGP（MP-BGP）[RFC4760]は、次のホップフィールドに掲載されるアドレスが属するネットワーク層プロトコルのセットが、住所ファミリ識別子（AFI）と後続の住所ファミリ識別子（SAFI）によって決定されることを指定しています。。多くの既存のAFI/SAFIを使用すると、次のホップアドレスがネットワークレイヤーリーチビリティ情報（NLRI）とは異なるアドレスファミリーに属します。たとえば、L2VPNオートディスコービリを実行するために（[L2VPN-SIG]に従って）AFI/SAFI <25/65>を使用すると、仮想プライベートLANサービス（VPLS）インスタンスの識別子を含む広告NLRIまたは特定のプロバイダーエッジ（PE）のアタッチメント回路の特定のプールを識別し、次のホップフィールドにはPEのループバックアドレスが含まれています。同様に、AFI/SAFI <1/132>（[RFC4684]で定義）ルートターゲット（RT）メンバーシップ情報を宣伝するために、そのようなRTメンバーシップ情報を含む広告NLRIが許可され、次のホップフィールドには次のホップフィールドには、広告ルーター。
Furthermore, a number of these existing AFI/SAFIs allow the Next Hop to belong to either the IPv4 Network Layer Protocol or the IPv6 Network Layer Protocol, and specify the encoding of the Next Hop information in order to determine which of the protocols the address actually belongs to. For example, [RFC4684] allows the Next Hop address to be either IPv4 or IPv6 and states that the Next Hop field address shall be interpreted as an IPv4 address whenever the length of Next Hop address is 4 octets, and as an IPv6 address whenever the length of the Next Hop address is 16 octets.
さらに、これらの既存のAFI/SAFIの多くを使用すると、次のホップがIPv4ネットワークレイヤープロトコルまたはIPv6ネットワークレイヤープロトコルのいずれかに属し、実際にアドレスのどのプロトコルのどのプロトコルを決定するかを決定するために、次のホップ情報のエンコードを指定できます。属する。たとえば、[RFC4684]を使用すると、次のホップアドレスがIPv4またはIPv6のいずれかであることを許可し、次のホップアドレスの長さが4オクテットの場合は次のホップフィールドアドレスがIPv4アドレスとして解釈されることを述べています。次のホップアドレスの長さは16オクテットです。
There are situations such as those described in [RFC4925] and in [MESH-FMWK] where carriers (or large enterprise networks acting as carrier for their internal resources) may be required to establish connectivity between 'islands' of networks of one address family type across a transit core of a differing address family type. This includes both the case of IPv6 islands across an IPv4 core and the case of IPv4 islands across an IPv6 core. Where Multiprotocol BGP (MP-BGP) is used to advertise the corresponding reachability information, this translates into the requirement for a BGP speaker to advertise Network Layer Reachability Information (NLRI) of a given address family via a Next Hop of a different address family (i.e., IPv6 NLRI with IPv4 Next Hop and IPv4 NLRI with IPv6 Next Hop).
[RFC4925]や[Mesh-FMWK]に記載されている状況があり、キャリア（または内部リソースのキャリアとして機能する大規模なエンタープライズネットワーク）が、1つの住所ファミリタイプのネットワークの「島」間の接続性を確立するために必要な場合があります。異なるアドレスファミリタイプのトランジットコアを越えて。これには、IPv4コアを越えたIPv6島のケースと、IPv6コアを越えたIPv4島のケースの両方が含まれます。マルチプロトコルBGP（MP-BGP）を使用して対応する到達可能性情報を宣伝する場合、これはBGPスピーカーが別のアドレスファミリの次のホップを介して特定のアドレスファミリーのネットワークレイヤーリーチビリティ情報（NLRI）を宣伝する要件につながります（NLRI）つまり、IPv4を備えたIPv6 NLRI NEXT HOPおよびIPv4 NLRIを使用してIPv6次のホップを使用します）。
The current AFI/SAFI definitions for the IPv6 address family assume that the Next Hop address belongs to the IPv6 address family type. Specifically, as per [RFC2545] and [RFC3107], when the <AFI/SAFI> is <2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6 type. As per [RFC4659], when the <AFI/SAFI> is <2/128>, the Next Hop address is assumed to be of IPv6-VPN type.
IPv6アドレスファミリの現在のAFI/SAFI定義は、次のホップアドレスがIPv6アドレスファミリタイプに属していると想定しています。具体的には、[rfc2545]および[rfc3107]に従って、<afi/safi>が<2/1>、<2/2>、または<2/4>の場合、次のホップアドレスはIPv6タイプであると想定されています。[rfc4659]によると、<afi/safi>の場合、次のホップアドレスはIPv6-vpnタイプであると想定されます。
However, [RFC4798] and [RFC4659] specify how an IPv4 address can be encoded inside the Next Hop IPv6 address field when IPv6 NLRI needs to be advertised with an IPv4 Next Hop. [RFC4798] defines how the IPv4-mapped IPv6 address format specified in the IPv6 addressing architecture ([RFC4291]) can be used for that purpose when the <AFI/ SAFI> is <2/1>, <2/2>, or <2/4>. [RFC4659] defines how the IPv4- mapped IPv6 address format as well as a null Route Distinguisher can be used for that purpose when the <AFI/SAFI> is <2/128>. Thus, there are existing solutions for the advertisement of IPv6 NLRI with an IPv4 Next Hop.
ただし、[RFC4798]および[RFC4659]は、IPv6 NLRIを次のホップで宣伝する必要がある場合に、次のHOP IPv6アドレスフィールド内でIPv4アドレスをエンコードする方法を指定します。[RFC4798]は、IPv4アドレスアーキテクチャ（[RFC4291]）で指定されたIPv4-Mapped IPv6アドレス形式（[RFC4291]）をその目的に使用する方法を定義します。<2/4>。[RFC4659]は、<afi/safi> is <2/128>である場合、IPv4-マッピングIPv6アドレス形式とnullルートの違いをどのように使用できるかを定義します。したがって、IPv4 NLRIの広告のための既存のソリューションがあり、IPv4 Next Hopがあります。
Similarly, the current AFI/SAFI definitions for advertisement of IPv4 NLRI or VPN-IPv4 NLRI assume that the Next Hop address belongs to the IPv4 address family type. Specifically, as per [RFC4760] and [RFC3107], when the <AFI/SAFI> is <1/1>, <1/2>, or <1/4>, the Next Hop address is assumed to be of IPv4 type. As per [RFC4364], when the <AFI/SAFI> is <1/128>, the Next Hop address is assumed to be of VPN-IPv4 type. There is clearly no generally applicable method for encoding an IPv6 address inside the IPv4 address field of the Next Hop. Hence, there is currently no specified solution for advertising IPv4 or VPN-IPv4 NLRI with an IPv6 Next Hop.
同様に、IPv4 NLRIまたはVPN-IPV4 NLRIの広告のための現在のAFI/SAFI定義は、次のホップアドレスがIPv4アドレスファミリタイプに属していると仮定します。具体的には、[rfc4760]および[rfc3107]に従って、<afi/safi>が<1/1>、<1/2>、または<1/4>の場合、次のホップアドレスはIPv4タイプであると想定されています。[rfc4364]によると、<afi/safi>が<1/128>の場合、次のホップアドレスはVPN-IPV4タイプであると想定されます。次のホップのIPv4アドレスフィールド内にIPv6アドレスをエンコードするための一般的に適用可能な方法は明らかにありません。したがって、現在、IPv6の次のホップを備えたIPv4またはVPN-IPV4 NLRIを広告するための指定されたソリューションはありません。
This document specifies the extensions necessary to do so. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to belong to either the IPv4 or the IPv6 protocol, the encoding of the Next Hop information in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. The new BGP Capability allows gradual deployment of the new functionality of advertising IPv4 reachability via an IPv6 Next Hop, without any flag day nor any risk of traffic black-holing.
このドキュメントは、そうするために必要な拡張機能を指定します。これは、AFI/SAFI定義の拡張を構成して、IPv4 NLRIまたはVPN-IPV4 NLRIの次のホップのアドレスをIPv4またはIPv6プロトコルのいずれかに属し、次のホップ情報のエンコードを決定するために、次のホップ情報のエンコードを許可することで構成されています。アドレスが実際に属するプロトコルと、MP-BGPピアがIPv4 NLRIとVPN-IPV4 NLRIを次のホップと交換できるかどうかを動的に発見できる新しいBGP機能を使用する新しいBGP機能。新しいBGP機能により、フラグの日やトラフィックのブラックホーリングのリスクなしに、IPv6 Next Hopを介してIPv4の広告の到達可能性の新しい機能を段階的に展開できます。
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]で説明されているように解釈されます。
As mentioned earlier, MP-BGP specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The following current AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 NLRI (<1/1>, <1/2>, <1/4>, and <1/128>) only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol. This document extends the definition of the AFI/SAFI for advertisement of IPv4 NLRI and VPN-IPv4 NLRI to extend the set of network-layer protocols to which the Next Hop address can belong, to include IPv6 in addition to IPv4.
前述のように、MP-BGPは、次のホップフィールドに掲載されるアドレスが属するネットワーク層プロトコルのセットが、アドレスファミリ識別子（AFI）とその後のアドレスファミリー識別子（SAFI）によって決定されることを指定します。次の現在のAFI/SAFI定義は、IPv4 NLRIまたはVPN-IPV4 NLRI（<1/1>、<1/2>、<1/4>、および<1/128>）の次のホップを宣伝するための規定のみを持っていますIPv4プロトコルに属するアドレス。このドキュメントは、IPv4 NLRIおよびVPN-IPV4 NLRIの広告のためのAFI/SAFIの定義を拡張して、次のホップアドレスが属するネットワーク層プロトコルのセットを拡張し、IPv4に加えてIPv6を含めます。
Specifically, this document allows advertising with [RFC4760] of an MP_REACH_NLRI with:
具体的には、このドキュメントでは、MP_REACH_NLRIの[RFC4760]を使用した広告を次のように許可します。
o AFI = 1
o AFI = 1
o SAFI = 1, 2, 4, or 128
o safi = 1、2、4、または128
o Length of Next Hop Address = 16 or 32
o 次のホップアドレスの長さ= 16または32
o Next Hop Address = IPv6 address of next hop (potentially followed by the link-local IPv6 address of the next hop). This field is to be constructed as per Section 3 of [RFC2545].
o 次のホップアドレス=次のホップのIPv6アドレス（次に、次のホップのリンクローカルIPv6アドレスが続く可能性があります）。このフィールドは、[RFC2545]のセクション3に従って構築されます。
o NLRI= NLRI as per current AFI/SAFI definition
o NLRI = NLRI現在のAFI/SAFI定義に従って
This is in addition to the current mode of operation allowing advertisement of NLRI for <AFI/SAFI> of <1/1>, <1/2> and <1/4> with a next hop address of IPv4 type and advertisement of NLRI for <AFI/ SAFI> of <1/128> with a next hop address of VPN-IPv4 type.
これは、<1/1>、<1/2>、<1/4>の<afi/safi>のNLRIの広告を許可する現在の操作モードに加えて、IPv4タイプとNLRIの広告の次のホップアドレスを備えています。VPN-IPV4タイプの次のホップアドレスを備えた<1/128>の<afi/ safi>の場合。
The BGP speaker receiving the advertisement MUST use the Length of Next Hop Address field to determine which network-layer protocol the next hop address belongs to. When the Length of Next Hop Address field is equal to 16 or 32, the next hop address is of type IPv6.
広告を受信するBGPスピーカーは、次のホップアドレスフィールドの長さを使用して、次のホップアドレスが属するネットワーク層プロトコルを決定する必要があります。次のホップアドレスフィールドの長さが16または32に等しい場合、次のホップアドレスはタイプIPv6です。
Note that this method of using the Length of the Next Hop Address field to determine which network-layer protocol the next hop address belongs to (out of the set of protocols allowed by the AFI/SAFI definition) is the same as used in [RFC4684] and [L2VPN-SIG].
次のホップアドレスフィールドの長さを使用して、次のホップアドレスが属するネットワーク層プロトコルを決定するこの方法（AFI/SAFI定義で許可されているプロトコルのセットのうち）は[RFC4684で使用されていると同じであることに注意してください。]および[l2vpn-sig]。
[RFC5492] defines a mechanism to allow two BGP speakers to discover if a particular capability is supported by their BGP peer and thus whether it can be used with that peer. This document defines a new capability that can be advertised using [RFC5492] and that is referred to as the Extended Next Hop Encoding capability. This capability allows BGP speakers to discover whether, for a given NLRI <AFI/SAFI>, a peer supports advertisement with a next hop whose network protocol is determined by the value of the Length of Next Hop Address field, as specified in Section 3.
[RFC5492]は、2人のBGPスピーカーが特定の機能がBGPピアによってサポートされているかどうか、したがってそのピアで使用できるかどうかを発見できるメカニズムを定義します。このドキュメントは、[RFC5492]を使用して宣伝できる新しい機能を定義し、拡張された次のホップエンコード機能と呼ばれます。この機能により、BGPスピーカーは、特定のnlri <afi/safi>について、セクション3で指定されているように、ネットワークプロトコルが次のホップアドレスフィールドの長さの値によって決定される次のホップで広告をサポートするかどうかを発見できます。
A BGP speaker that wishes to advertise to a BGP peer an IPv6 Next Hop for IPv4 NLRI or for VPN-IPv4 NLRI as per this specification MUST use the Capability Advertisement procedures defined in [RFC5492] with the Extended Next Hop Encoding Capability to establish whether its peer supports this for the NLRI AFI/SAFI pair(s) of interest. The fields in the Capabilities Optional Parameter MUST be set as follows:
この仕様に従って、IPv4 NLRIまたはVPN-IPV4 NLRIの次のホップを宣伝したいBGPスピーカーは、[RFC5492]で定義されている機能広告手順を使用して、拡張された次のホップエンコーディング機能を使用して、[RFC5492]で定義された機能広告手順を使用する必要があります。ピアは、これをNLRI AFI/SAFIペア（S）にサポートしています。機能オプションのパラメーターのフィールドは、次のように設定する必要があります。
o The Capability Code field MUST be set to 5 (which indicates the Extended Next Hop Encoding capability).
o 機能コードフィールドは5に設定する必要があります（拡張された次のホップエンコード機能を示します）。
o The Capability Length field is set to a variable value that is the length of the Capability Value field (which follows).
o 機能長さフィールドは、機能値フィールドの長さ（次のとおり）である変数値に設定されます。
o The Capability Value field has the following format:
o 機能値フィールドには、次の形式があります。
+-----------------------------------------------------+
| NLRI AFI - 1 (2 octets) |
+-----------------------------------------------------+
| NLRI SAFI - 1 (2 octets) |
+-----------------------------------------------------+
| Nexthop AFI - 1 (2 octets) |
+-----------------------------------------------------+
| ..... |
+-----------------------------------------------------+
| NLRI AFI - N (2 octets) |
+-----------------------------------------------------+
| NLRI SAFI - N (2 octets) |
+-----------------------------------------------------+
| Nexthop AFI - N (2 octets) |
+-----------------------------------------------------+
where:
ただし：
* each triple <NLRI AFI, NLRI SAFI, Nexthop AFI> indicates that NLRI of <NLRI AFI / NLRI SAFI> may be advertised with a Next Hop address belonging to the network-layer protocol of Nexthop AFI.
* 各トリプル<nlri afi、nlri safi、nexthop afi>は、<nlri afi / nlri safi>のnlriが、Nexthop AFIのネットワーク層プロトコルに属する次のホップアドレスで宣伝される可能性があることを示しています。
* the AFI and SAFI values are defined in the Address Family Identifier and Subsequent Address Family Identifier registries maintained by IANA.
* AFIとSAFIの値は、IANAが維持しているアドレスファミリ識別子およびその後のアドレスファミリ識別子レジストリで定義されています。
Since this document only concerns itself with the advertisement of IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop, this specification only allows the following values in the Capability Value field of the Extended Next Hop Encoding capability:
このドキュメントは、IPv4 NLRIおよびVPN-IPV4 NLRIのIPv6 Next Hopの広告のみに関係しているため、この仕様は、拡張されたNext Hopエンコード機能の機能値フィールドの次の値のみを許可します。
o NLRI AFI = 1 (IPv4)
o nlri afi = 1（ipv4）
o NLRI SAFI = 1, 2, 4, or 128
o nlri safi = 1、2、4、または128
o Nexthop AFI = 2 (IPv6)
o nexthop afi = 2（ipv6）
This specification does not propose that the Extended Next Hop
Encoding capability be used with any other combinations of <NLRI AFI,
NLRI SAFI, Nexthop AFI>. In particular, this specification does not
propose that the Extended Next Hop Encoding capability be used for
NLRI AFI/SAFIs whose definition already allows use of both IPv4 and
IPv6 next hops (e.g., AFI/SAFI = <1/132> as defined in [RFC4684]).
Similarly, it does not propose that the Extended Next Hop Encoding
capability be used for NLRI AFI/SAFIs for which there is already a
solution for advertising a next hop of a different address family
(e.g., AFI/SAFI = <2/1>, <2/2>, or <2/4> with IPv4 Next Hop as per
[RFC4798] and AFI/SAFI = <2/128> with IPv4 Next Hop as per
[RFC4659]).
It is expected that if new AFI/SAFIs are defined in the future, their definition will have provisions (where appropriate) for both IPv4 and IPv6 Next Hops from the onset, with determination based on Length of Next Hop Address field. Thus, new AFI/SAFIs are not expected to make use of the Extended Next Hop Encoding capability.
新しいAFI/SAFISが将来定義されている場合、次のホップアドレスフィールドの長さに基づく決定により、彼らの定義には、IPv4とIPv6の両方の次のホップの規定（必要に応じて）があります。したがって、新しいAFI/SAFISは、拡張された次のホップエンコード機能を利用することは期待されていません。
A BGP speaker MUST only advertise to a BGP peer the IPv4 or VPN-IPv4 NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained via BGP Capability Advertisement that the BGP peer supports the Extended Next Hop Encoding capability for the relevant AFI/SAFI pair.
BGPスピーカーは、BGPスピーカーが最初にBGP機能の広告を介して確認された場合、BGPスピーカーがIPv4またはVPN-IPV4 NLRIをIPv4またはVPN-IPV4 NLRIを使用してBGPピアにのみ宣伝する必要があります。ペア。
The Extended Next Hop Encoding capability provides information about next hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is allowed. It does not influence whether that AFI/SAFI is indeed allowed. Whether a AFI/SAFI can be used between the BGP peers is purely determined through the Multiprotocol Extensions capability defined in [RFC4760].
拡張された次のホップエンコード機能は、AFI/SAFIが許可されていると仮定して、特定のAFI/SAFIの次のホップエンコードに関する情報を提供します。AFI/SAFIが実際に許可されているかどうかは影響しません。BGPピア間でAFI/SAFIを使用できるかどうかは、[RFC4760]で定義されているマルチプロトコル拡張機能を介して純粋に決定されます。
The Extended Next Hop Encoding capability MAY be dynamically updated through the use of the Dynamic Capability capability and associated mechanisms defined in [DYN-CAP].
拡張された次のホップエンコード機能は、[dyn-cap]で定義されている動的機能と関連するメカニズムを使用して動的に更新できます。
By default, if a particular BGP session is running over IPvx (where IPvx is IPv4 or IPv6), and if the BGP speaker sending an update is putting its own address in as the next hop, then the next hop address SHOULD be specified as an IPvx address, using the encoding rules specified in the AFI/SAFI definition of the NLRI being updated. This default behavior may be overridden by policy.
デフォルトでは、特定のBGPセッションがIPVX（IPVXがIPv4またはIPv6）を介して実行されている場合、および更新を送信するBGPスピーカーが次のホップとして独自のアドレスを入れている場合、次のホップアドレスを次のホップアドレスを指定する必要があります。IPVXアドレス、更新されるNLRIのAFI/SAFI定義で指定されたエンコードルールを使用します。このデフォルトの動作は、ポリシーによってオーバーライドされる場合があります。
When a next hop address needs to be passed along unchanged (e.g., as a Route Reflector (RR) would do), its encoding MUST NOT be changed. If a particular RR client cannot handle that encoding (as determined by the BGP Capability Advertisement), then the NLRI in question cannot be distributed to that client. For sound routing in certain scenarios, this will require that all the RR clients be able to handle whatever encodings any of them may generate.
次のホップアドレスを変更せずに渡す必要がある場合（たとえば、ルートリフレクター（RR）が行うように）、そのエンコードを変更してはなりません。特定のRRクライアントがそのエンコードを処理できない場合（BGP機能広告によって決定されているように）、問題のNLRIをそのクライアントに配布することはできません。特定のシナリオでのサウンドルーティングの場合、すべてのRRクライアントが生成する可能性のあるエンコーディングをすべて処理できる必要があります。
The extensions defined in this document may be used as discussed in [MESH-FMWK] for the interconnection of IPV4 islands over an IPv6 backbone. In this application, Address Family Border Routers (AFBRs; as defined in [RFC4925]) advertise IPv4 NLRI in the MP_REACH_NLRI along with an IPv6 Next Hop.
このドキュメントで定義されている拡張機能は、IPv6バックボーン上のIPv4島の相互接続のために[Mesh-FMWK]で説明されているように使用できます。このアプリケーションでは、ファミリーボーダールーター（AFBRS; [RFC4925]で定義されている）をアドレス指定します。MP_REACH_NLRIでIPv4 NLRIを宣伝し、IPv6 Next Hopを宣伝します。
The MP_REACH_NLRI is encoded with:
MP_REACH_NLRIは以下でエンコードされています
o AFI = 1
o AFI = 1
o SAFI = 1
o SAFI = 1
o Length of Next Hop Network Address = 16 (or 32)
o 次のホップネットワークアドレスの長さ= 16（または32）
o Network Address of Next Hop = IPv6 address of Next Hop
o 次のホップのネットワークアドレス=次のホップのIPv6アドレス
o NLRI = IPv4 routes During BGP Capability Advertisement, the PE routers would include the following fields in the Capabilities Optional Parameter:
o NLRI = IPv4ルートBGP機能広告中、PEルーターには、機能オプションのパラメーターに次のフィールドが含まれます。
o Capability Code set to "Extended Next Hop Encoding"
o 「拡張された次のホップエンコード」に設定された機能コード
o Capability Value containing <NLRI AFI=1, NLRI SAFI=1, Nexthop AFI=2>
o <nlri afi = 1、nlri safi = 1、nexthop afi = 2>を含む機能値
The extensions defined in this document may be used for support of IPV4 VPNs over an IPv6 backbone. In this application, PE routers would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6 Next Hop.
このドキュメントで定義されている拡張機能は、IPv6バックボーンを介したIPv4 VPNSのサポートに使用できます。このアプリケーションでは、PEルーターはMP_REACH_NLRIでVPN-IPV4 NLRIをIPv6 Next Hopとともに宣伝します。
The MP_REACH_NLRI is encoded with:
MP_REACH_NLRIは以下でエンコードされています
o AFI = 1
o AFI = 1
o SAFI = 128
o SAFI = 128
o Length of Next Hop Network Address = 16 (or 32)
o 次のホップネットワークアドレスの長さ= 16（または32）
o Network Address of Next Hop = IPv6 address of Next Hop
o 次のホップのネットワークアドレス=次のホップのIPv6アドレス
o NLRI = IPv4-VPN routes
o NLRI = IPv4-VPNルート
During BGP Capability Advertisement, the PE routers would include the following fields in the Capabilities Optional Parameter:
BGP機能広告中に、PEルーターには、機能オプションのパラメーターに次のフィールドが含まれます。
o Capability Code set to "Extended Next Hop Encoding"
o 「拡張された次のホップエンコード」に設定された機能コード
o Capability Value containing <NLRI AFI=1, NLRI SAFI=128, Nexthop AFI=2>
o <nlri afi = 1、nlri safi = 128、nexthop afi = 2>を含む機能値
This document defines, in Section 4, a new Capability Code to indicate the Extended Next Hop Encoding capability in the [RFC5492] Capabilities Optional Parameter. The value for this new Capability Code is 5, which is in the range set aside for allocation using the "IETF Review" policy defined in [RFC5226].
このドキュメントでは、セクション4では、[RFC5492]機能オプションパラメーターの拡張された次のホップエンコード機能を示す新しい機能コードを定義しています。この新しい機能コードの値は5です。これは、[RFC5226]で定義された「IETFレビュー」ポリシーを使用して、割り当てのために確保されている範囲にあります。
This document does not raise any additional security issues beyond those of BGP-4 and the Multiprotocol extensions for BGP-4. The same security mechanisms are applicable.
このドキュメントでは、BGP-4およびBGP-4のマルチプロトコル拡張のセキュリティ問題を超える追加のセキュリティ問題は発生しません。同じセキュリティメカニズムが適用されます。
Although not expected to be the typical case, the IPv6 address used as the BGP Next Hop Address could be an IPv4-mapped IPv6 address (as defined in [RFC4291]). Configuration of the security mechanisms potentially deployed by the network operator (such as security checks on next hop address) need to keep this case in mind also.
典型的なケースであるとは予想されていませんが、BGP Next Hopアドレスとして使用されるIPv6アドレスは、IPv4-Mapped IPv6アドレス（[RFC4291]で定義されています）である可能性があります。ネットワークオペレーターによって潜在的に展開されるセキュリティメカニズムの構成（次のホップアドレスのセキュリティチェックなど）は、このケースも念頭に置く必要があります。
The authors would like to thank Yakov Rekhter, Pranav Mehta, and John Scudder for their contributions to the approach defined in this document.
著者は、この文書で定義されているアプローチへの貢献について、Yakov Rekhter、Pranav Mehta、およびJohn Scudderに感謝したいと思います。
[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月。
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
[RFC2545] Marques、P。and F. Dupont、「IPv6インタードメインルーティングのBGP-4マルチプロトコル拡張の使用」、RFC 2545、1999年3月。
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[RFC3107] Rekhter、Y。およびE. Rosen、「BGP-4でのラベル情報の運搬」、RFC 3107、2001年5月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）」、RFC 4364、2006年2月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、2007年1月。
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, February 2009.
[RFC5492] Scudder、J。およびR. Chandra、「BGP-4による機能広告」、RFC 5492、2009年2月。
[DYN-CAP] Chen, E. and S. Sangli, "Dynamic Capability for BGP-4", Work in Progress, November 2006.
[Dyn-Cap] Chen、E。およびS. Sangli、「BGP-4の動的能力」、2006年11月、Work in Progress。
[L2VPN-SIG] Rosen, E., "Provisioning, Autodiscovery, and Signaling in L2VPNs", Work in Progress, May 2006.
[L2VPN-SIG] Rosen、E。、「L2VPNSでのプロビジョニング、自己発見、およびシグナリング」、2006年5月、進行中の作業。
[MESH-FMWK] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", Work in Progress, February 2009.
[Mesh-Fmwk] Wu、J.、Cui、Y.、Metz、C。、およびE. Rosen、「Softwire Mesh Framework」、Progress、2009年2月。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
[RFC4659] De Clercq、J.、Ooms、D.、Carugi、M。、およびF. Le Faucheur、「BGP-MPLS IP仮想プライベートネットワーク（VPN）IPv6 VPNの拡張」、RFC 4659、2006年9月。
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006.
[RFC4684] Marques、P.、Bonica、R.、Fang、L.、Martini、L.、Raszuk、R.、Patel、K。、およびJ. Guichard、 "境界ゲートウェイプロトコル/マルチプロトコルラベルスイッチングの制約付きルート分布（BGP/MPLS）インターネットプロトコル（IP）仮想プライベートネットワーク（VPNS）」、RFC 4684、2006年11月。
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC4798] de Clercq、J.、Ooms、D.、Prevost、S。、およびF. Le Faucheur、「IPv6プロバイダーエッジルーター（6PE）を使用してIPv6 MPLSを介してIPv6島を接続する」、RFC 4798、2007年2月。
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.
[RFC4925] Li、X.、Dawkins、S.、Ward、D。、およびA. Durand、「Softwire Problem Statement」、RFC 4925、2007年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
Authors' Addresses
著者のアドレス
Francois Le Faucheur Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France
Francois Le Faucheur Cisco Systems Greenside、400 Avenue de Roumanille Sophia Antipolis 06410 France
EMail: flefauch@cisco.com
Eric Rosen Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
エリックローゼンシスコシステム1414マサチューセッツアベニューボックスボロー、マサチューセッツ州01719 USA
EMail: erosen@cisco.com