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
        

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.

著作権(C)2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。

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.

マルチプロトコル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ピアを動的に彼らがIPv6ネクストホップでのIPv4 NLRIとVPN-IPv4のNLRIを交換することができるかどうかを発見することができ、新しい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
        
1. Introduction
1. はじめに

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.

マルチプロトコルBGP(MP-BGP)[RFC4760]はネクストホップフィールドで運ばれたアドレスが属していてもよいいるネットワーク層プロトコルのセットは、アドレスファミリ識別子(AFI)と次のアドレスファミリ識別子(SAFI)によって決定されることを指定します。既存のAFI / SAFIsの数は、ネクストホップアドレスがネットワーク層到達可能性情報(NLRI)とは異なるアドレスファミリに属する​​ことができます。例えば、AFI / SAFI <65分の25> L2VPNの自動検出を実行するために([L2VPN-SIG]通り)を用い、広告NLRIは、仮想プライベートLANサービス(VPLS)インスタンスの、またはその識別子が含まれることができネクストホップフィールドがPEのループバックアドレスを含むが、所与のプロバイダエッジ(PE)に接続回線の特定のプールを識別する。同様に、AFI / SAFI <132分の1>ネクストホップフィールドは、アドレスを含むが広告NLRIは、例えばRTメンバーシップ情報を含むことができ、ルートターゲット(RT)会員情報をアドバタイズするために、([RFC4684]で定義されます)広告ルータ。

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 / SAFIsの数がネクストホップがIPv4ネットワークレイヤプロトコルまたはIPv6ネットワーク層プロトコルのいずれかに属し、実際にどのプロトコルのアドレスを決定するためにネクストホップ情報の符号化を指定することができ属する。例えば、[RFC4684]はネクストホップアドレスはIPv4またはIPv6のいずれかであることを可能にし、ネクストホップアドレスの長さが4つのオクテットであり、IPv6アドレスとしてたびたびネクストホップフィールドのアドレスは、IPv4アドレスとして解釈されなければならないと述べていますネクストホップアドレスの長さが16オクテットです。

There are situations such as those described in [RFC4925] and in [MESH-FMWK] where carriers (or large enterprise networks acting as

このような[RFC4925]およびキャリア(または大規模な企業ネットワークのように作用する[MESH-FMWK]に記載されているような状況があります

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).

その内部リソースのためのキャリア)が異なるアドレスファミリータイプのトランジットコア全体で一つのアドレスファミリータイプのネットワークの "島の間の接続を確立するために必要な場合があります。これは、IPv4コアを横切ってのIPv6島の場合とIPv6コアを横切ってのIPv4アイランドの場合の両方を含みます。マルチプロトコルBGP(MP-BGP)は、対応する到達可能性情報を宣伝するために使用される場合、これは別のアドレスファミリのネクストホップ(経て与えられたアドレスファミリのネットワーク層到達可能性情報(NLRI)をアドバタイズするBGPスピーカーのための要件に変換しますすなわち、IPv6のネクストホップを持つIPv4のネクストホップとIPv4 NLRIとIPv6のNLRI)。

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> <2/128>は、ネクストホップアドレスは、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は、IPv4ネクストホップでアドバタイズする必要がある場合、IPv4アドレスは、ネクストホップのIPv6アドレスフィールド内符号化することができる方法を指定します。 [RFC4798] <2/1>、<2/2>とき<AFI / SAFI>のIPv6アドレス体系([RFC4291])で指定されたIPv4射影IPv6アドレスのフォーマットは、その目的のために使用することができる方法を定義し、又は<2/4>。 [RFC4659]は<AFI / SAFIが> <2/128>である場合IPv4- IPv6アドレス形式ならびにルート識別子は、その目的のために使用することができるヌルにマッピング方法を定義します。このように、IPv4のネクストホップとIPv6のNLRIの広告のための既存のソリューションがあります。

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.

この文書では、そうするために必要な拡張子を指定します。これは、IPv4 NLRIまたはVPN-IPv4のNLRIの次のホップのアドレスを決定するために、IPv4またはIPv6プロトコル、ネクストホップ情報の符号化のいずれかに属することができるようにAFI / SAFI定義の拡張を含みますプロトコルは、アドレスが実際に属し、MP-BGPピアがダイナミックに彼らがIPv6ネクストホップでのIPv4 NLRIとVPN-IPv4のNLRIを交換することができるかどうかを発見することができ、新しいBGP能力。新しいBGP機能は、任意のフラグの日でも、トラフィックのブラックホール化 - のいずれかのリスクなしに、IPv6のネクストホップを経由して広告のIPv4到達可能性の新機能の漸進的な導入を可能にします。

2. Requirements Language
2.必要な言語

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. Extension of AFI/SAFI Definitions for the IPv4 Address Family
IPv4アドレスファミリ用AFI / SAFI定義3.拡張

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)によって決定されます。 IPv4のNLRIまたはVPN-IPv4のNLRIのための次の現在のAFI / SAFI定義(<1/1>、<1/2>、<1/4>、および<1/128>)だけ次のホップを宣伝するための規定を持っていますIPv4プロトコルに属しているアドレス。この文書は、IPv4に加えてIPv6を含むように、ネクストホップアドレスが所属することができているネットワーク層プロトコルのセットを拡張するためのIPv4 NLRIとVPN-IPv4のNLRIの広告のためのAFI / SAFIの定義を拡張します。

Specifically, this document allows advertising with [RFC4760] of an MP_REACH_NLRI with:

具体的には、この文書は、MP_REACH_NLRIとの[RFC4760]で広告ができます。

o AFI = 1

AFI = 1

o SAFI = 1, 2, 4, or 128

SAFI = 1、2、4、または128 O

o Length of Next Hop Address = 16 or 32

ネクストホップアドレス= 16または32のO長

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

NLRI = NLRI O現在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.

これは、NLRIのネクストホップのIPv4タイプのアドレスと広告との<AFI / SAFI> <1/1>、<1/2>と<1/4>ため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].

[RFC4684で使用される次ホップアドレスは、(AFI / SAFI定義によって許可されたプロトコルのセットから)に属するネットワーク層プロトコルを決定するために次ホップアドレスフィールドの長さを使用して、この方法が同じであることに注意してください]と[L2VPN-SIG]。

4. Use of BGP Capability Advertisement
BGP能力広告の4.

[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]は、特定の機能が、それはそのピアで使用することができるかどうか、したがって、それらのBGPピアによって支持されている場合2つの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のIPv6ネクストホップピアBGPに宣伝したいBGPスピーカは、そのかどうかを確立するために拡張ネクストホップエンコード能力を有する[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、ネクストホップAFI>は<NLRI AFI / NLRI SAFI>のNLRIをネクストホップアドレスは、ネクストホップ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:

IPv6のネクストホップとのIPv4 NLRIとVPN-IPv4のNLRIの広告この文書は唯一の懸念自体ので、この仕様は、拡張ネクストホップエンコード能力の能力値フィールドで次の値を可能にします。

o NLRI AFI = 1 (IPv4)

NLRI AFI = 1(IPv4)の

o NLRI SAFI = 1, 2, 4, or 128

O NLRI SAFI = 1、2、4、または128

o Nexthop AFI = 2 (IPv6)

ネクストホップAFI = 2(IPv6)のO

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]).

この仕様は、拡張ネクストホップエンコーディング機能が<NLRI AFI、NLRI SAFI、ネクストホップAFI>の任意の他の組み合わせで使用することを提案していません。特に、本明細書では拡張ネクストホップエンコード能力は、その定義は既に定義した通りでIPv4とIPv6の両方の次のホップ(例えば、AFI / SAFI = <132分の1>の使用を可能にNLRI AFI / SAFIsに使用されることを提案していません[ RFC4684])。同様に、それは別のアドレスファミリー(例えば、AFI / SAFI = <2/1>、の次のホップを宣伝するためのソリューションがすでに存在しているため、拡張ネクストホップエンコーディング機能がNLRI AFI / SAFIsを使用することを提案していません<2/2>または<2/4>のIPv4ネクストホップとのIPv4ネクストホップと[RFC4798]及びAFI / SAFI = <2/128>の通りの通り[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ピアは、関連AFI / SAFIの拡張ネクストホップエンコーディング機能をサポートしていることをIPv6のネクストホップと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が実際に許可されるかどうかは影響しません。 AFI / SAFIは、BGPピアとの間で使用することができるかどうかを純粋に[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]で定義されたメカニズムを動的能力機能を使用することによって更新され、関連していてもよいです。

5. Operations
5.操作

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セッションは、更新を送信するBGPスピーカは、次ホップとして、自身のアドレスを入れている場合、次ホップアドレスとして指定されるべきである(IPvxはIPv4またはIPv6である)IPvx上で実行されている場合NLRIのAFI / SAFI定義で指定された符号化規則を用いIPvxアドレスは、更新されます。このデフォルトの動作は、ポリシーによって上書きされることがあります。

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クライアントはそれらのいずれかが発生することができる符号化方式において何でも扱うことができることが必要になります。

6. Usage Examples
6.使用例
6.1. IPv4 over IPv6 Core
6.1. IPv6のコア以上のIPv4

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.

[MESH-FMWK]で説明したように、この文書で定義された拡張機能は、IPv6バックボーン上IPV4アイランドの相互接続のために使用することができます。このアプリケーションでは、家族の境界ルータアドレス(AFBRsと、[RFC4925]で定義されるように)のIPv6ネクストホップとともにMP_REACH_NLRI内のIPv4 NLRIをアドバタイズ。

The MP_REACH_NLRI is encoded with:

MP_REACH_NLRIを用いて符号化されています。

o AFI = 1

AFI = 1

o SAFI = 1

クリア= 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

ネクストホップのネクストホップ= IPv6アドレスのOネットワークアドレス

o NLRI = IPv4 routes

O NLRI = IPv4ルート

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=1, Nexthop AFI=2>

<= 1 NLRI AFI、NLRI SAFI = 1、ネクストホップAFI = 2>を含むO能力値

6.2. IPv4 VPN over IPv6 Core
6.2. IPv6のコア以上のIPv4 VPN

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 VPNのサポートのために使用することができます。このアプリケーションでは、PEルータは、IPv6ネクストホップとともにMP_REACH_NLRIでVPN-IPv4のNLRIを広告することになります。

The MP_REACH_NLRI is encoded with:

MP_REACH_NLRIを用いて符号化されています。

o AFI = 1

AFI = 1

o SAFI = 128

クリア= 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

ネクストホップのネクストホップ= IPv6アドレスのOネットワークアドレス

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>

<= 1 NLRI AFI、NLRI SAFI = 128、ネクストホップAFI = 2>を含むO能力値

7. IANA Considerations
7. IANAの考慮事項

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].

この文書は、新しい能力コードは[RFC5492]能力任意パラメータで拡張ネクストホップエンコーディング機能を示すために、第4節では、定義されています。この新しい機能コードの値は、[RFC5226]で定義された「IETFレビュー」ポリシーを使用して、割り当てのために取っておか範囲にある、5です。

8. Security Considerations
8.セキュリティの考慮事項

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ネクストホップアドレスとして使用されるIPv6アドレスは、IPv4マップIPv6アドレスとすることができる([RFC4291]で定義されるように)。潜在的(なネクストホップアドレスのセキュリティチェックなど)ネットワークオペレータによって展開されたセキュリティ・メカニズムの構成も念頭に置いてこのケースを維持する必要があります。

9. Acknowledgments
9.謝辞

The authors would like to thank Yakov Rekhter, Pranav Mehta, and John Scudder for their contributions to the approach defined in this document.

著者は、この文書で定義されたアプローチへの貢献のためにヤコフ・レックター、Pranavメータ、およびジョン・スカダーに感謝したいと思います。

10. References
10.参考文献
10.1. Normative References
10.1. 引用規格

[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月。

[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.

[RFC2545]マルケス、P.およびF.デュポン、RFC 2545 "IPv6のドメイン間ルーティングのためのBGP-4マルチプロトコル拡張機能の使用"、1999年3月。

[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.

[RFC3107] Rekhter、Y.、およびE.ローゼン、 "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.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.

[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク(VPN)"、RFC 4364、2006年2月。

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.

[RFC4760]ベイツ、T.、チャンドラ、R.、カッツ、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]スカダー、J.及びR.チャンドラ、 "BGP-4との機能広告"、RFC 5492、2009年2月。

10.2. Informative References
10.2. 参考文献

[DYN-CAP] Chen, E. and S. Sangli, "Dynamic Capability for BGP-4", Work in Progress, November 2006.

[DYN-CAP]チェン、E.およびS.サングリ、 "BGP-4のためのダイナミックな能力"、進歩、2006年11月に作業。

[L2VPN-SIG] Rosen, E., "Provisioning, Autodiscovery, and Signaling in L2VPNs", Work in Progress, May 2006.

[L2VPN-SIG]ローゼン、E.、 "プロビジョニング、自動検出、およびのL2VPNにシグナリング"、進歩、2006年5月での作業。

[MESH-FMWK] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", Work in Progress, February 2009.

[MESH-FMWK]呉、J.、キュイ、Y.、メス、C.、およびE.ローゼン、 "Softwireメッシュフレームワーク"、進歩、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]デClercq、J.、Ooms、D.、Carugi、M.、およびF.ル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]マルケス、P.、Bonica、R.、牙、L.、マティーニ、L.、Raszuk、R.、パテル、K.、およびJ.ギシャール、「ボーダーゲートウェイプロトコル/マルチプロトコルラベルスイッチングのための制約経路配信(BGP / MPLS)インターネット・プロトコル(IP)、仮想プライベートネットワーク(VPN)」、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]デClercq、J.、Ooms、D.、プレボ、S.、およびF.ルFaucheur、 "IPv6のプロバイダエッジルータを使用したIPv4 MPLS上のIPv6諸島接続(6PE)"、RFC 4798、2007年2月。

[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.

[RFC4925]のLi、X.、ドーキンス、S.、ウォード、D.、およびA.デュラン、 "Softwire問題文"、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

フランソワ・リーパーシスコシステムズグリーンサイド、400アベニューRoumanille 06410ソフィアアンティポリスフランス

EMail: flefauch@cisco.com

メールアドレス:flefauch@cisco.com

Eric Rosen Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA

エリック・ローゼンシスコシステムズ1414年マサチューセッツアベニューボックスボロー、MA 01719 USA

EMail: erosen@cisco.com

メールアドレス:erosen@cisco.com