[要約] RFC 4659は、IPv6 VPNのためのBGP-MPLS IP仮想プライベートネットワーク（VPN）拡張に関する仕様です。このRFCの目的は、IPv6ネットワーク上での仮想プライベートネットワークの拡張を可能にするためのプロトコルを提供することです。
Network Working Group J. De Clercq
Request for Comments: 4659 Alcatel
Category: Standards Track D. Ooms
OneSparrow
M. Carugi
Nortel Networks
F. Le Faucheur
Cisco Systems
September 2006
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN
BGP-MPLS IPv6VPNのIP仮想プライベートネットワーク（VPN）拡張機能
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method for support of IPv6. In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4 VPN routes over the service provider backbone, and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in "Multiprotocol BGP".
このドキュメントでは、サービスプロバイダーがパケットスイッチのバックボーンを使用して、IPv6の顧客に仮想プライベートネットワーク（VPN）サービスを提供できる方法について説明します。この方法は、IPv6をサポートするための「BGP/MPLS IP VPN」メソッドを再利用し、必要に応じて拡張します。BGP/MPLS IP VPNでは、「Multiprotocol BGP」は、サービスプロバイダーのバックボーン上にIPv4 VPNルートを配布するために使用され、MPLSはバックボーン上にIPv4 VPNパケットを転送するために使用されます。このドキュメントは、IPv6 VPNアドレスファミリを定義し、「MultiProtocol BGP」の対応するIPv6 VPNルート分布について説明します。
This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and for using various tunneling techniques over the core, including MPLS, IP-in-IP, Generic Routing Encapsulation (GRE) and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document.
このドキュメントでは、IPv4とIPv6バックボーンの両方でIPv6 VPNサービスのサポートを定義し、MPLS、IP-in-IP、汎用ルーティングカプセル化（GRE）、IPSEC保護トンネルなど、コア上でさまざまなトンネリング技術を使用するために定義されています。IPv4サイトとIPv6サイトの間の相互作用は、このドキュメントの範囲外です。
Table of Contents
目次
1. Introduction ....................................................2
2. The VPN-IPv6 Address Family .....................................4
3. VPN-IPv6 Route Distribution .....................................5
3.1. Route Distribution Among PEs by BGP ........................5
3.2. VPN IPv6 NLRI Encoding .....................................6
3.2.1. BGP Next Hop encoding ...............................6
3.2.1.1. BGP Speaker Requesting IPv6 Transport ......7
3.2.1.2. BGP Speaker Requesting IPv4 Transport ......8
3.3. Route Target ...............................................8
3.4. BGP Capability Negotiation .................................8
4. Encapsulation ...................................................8
5. Address Types ..................................................10
6. Multicast ......................................................11
7. Carriers' Carriers .............................................11
8. Multi-AS Backbones .............................................11
9. Accessing the Internet from a VPN ..............................13
10. Management VPN ................................................14
11. Security Considerations .......................................14
12. Quality of Service ............................................15
13. Scalability ...................................................15
14. IANA Considerations ...........................................15
15. Acknowledgements ..............................................15
16. References ....................................................16
16.1. Normative References .....................................16
16.2. Informative References ...................................16
This document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network services for its IPv6 customers.
このドキュメントでは、サービスプロバイダーがパケットスイッチのバックボーンを使用して、IPv6の顧客に仮想プライベートネットワークサービスを提供できる方法について説明します。
This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method [BGP/MPLS-VPN] for support of IPv6. In particular, this method uses the same "peer model" as [BGP/MPLS-VPN], in which the customers' edge routers ("CE routers") send their IPv6 routes to the Service Provider's edge routers ("PE routers"). BGP ("Border Gateway Protocol", [BGP, BGP-MP]) is then used by the Service Provider to exchange the routes of a particular IPv6 VPN among the PE routers that are attached to that IPv6 VPN. Eventually, the PE routers distribute, to the CE routers in a particular VPN, the IPv6 routes from other CE routers in that VPN. As with IPv4 VPNs, a key characteristic of this "peer model" is that the (IPv6) CE routers within an (IPv6) VPN do not peer with each other; there is no "overlay" visible to the (IPv6) VPN's routing algorithm.
このメソッドは、IPv6のサポートのために「BGP/MPLS IP VPN」メソッド[BGP/MPLS-VPN]を再利用し、拡張します。特に、この方法は[BGP/MPLS-VPN]と同じ「ピアモデル」を使用します。この方法では、顧客のエッジルーター（「CEルーター」）がIPv6ルートをサービスプロバイダーのエッジルーター（「PEルーター」）に送信します。。BGP（ "Border Gateway Protocol"、[BGP、BGP-MP]）は、サービスプロバイダーによって使用され、そのIPv6 VPNに接続されているPEルーター間で特定のIPv6 VPNのルートを交換します。最終的に、PEルーターは、特定のVPNのCEルーターに分布し、そのVPNの他のCEルーターからIPv6ルーターをルートします。IPv4 VPNSと同様に、この「ピアモデル」の重要な特徴は、（IPv6）VPN内の（IPv6）CEルーターが互いにピアをしないことです。（IPv6）VPNのルーティングアルゴリズムに表示される「オーバーレイ」はありません。
This document adopts the definitions, acronyms, and mechanisms described in [BGP/MPLS-VPN]. Unless it is stated otherwise, the mechanisms of [BGP/MPLS-VPN] apply and will not be re-described here.
このドキュメントは、[BGP/MPLS-VPN]で説明されている定義、頭字語、およびメカニズムを採用しています。特に明記しない限り、[BGP/MPLS-VPN]のメカニズムが適用され、ここでは再記述されません。
A VPN is said to be an IPv6 VPN when each site of this VPN is IPv6 capable and is natively connected over an IPv6 interface or sub-interface to the Service Provider (SP) backbone via a Provider Edge device (PE).
VPNは、このVPNの各サイトがIPv6対応であり、Provider Edgeデバイス（PE）を介してサービスプロバイダー（SP）バックボーンにIPv6インターフェイスまたはサブインターフェイスを介してネイティブに接続されている場合、IPv6 VPNと言われます。
A site may be both IPv4 capable and IPv6 capable. The logical interface on which packets arrive at the PE may determine the IP version. Alternatively, the same logical interface may be used for both IPv4 and IPv6, in which case a per-packet lookup at the Version field of the IP packet header determines the IP version.
サイトは、IPv4対応とIPv6の両方に存在する場合があります。パケットがPEに到着する論理インターフェイスは、IPバージョンを決定する場合があります。あるいは、IPv4とIPv6の両方に同じ論理インターフェイスを使用する場合があります。この場合、IPパケットヘッダーのバージョンフィールドでのパケットごとの検索がIPバージョンを決定します。
This document only concerns itself with handling of IPv6 communication between IPv6 hosts located on IPv6-capable sites. Handling of IPv4 communication between IPv4 hosts located on IPv4- capable sites is outside the scope of this document and is covered in [BGP/MPLS-VPN]. Communication between an IPv4 host located in an IPv4- capable site and an IPv6 host located in an IPv6-capable site is outside the scope of this document.
このドキュメントは、IPv6対応サイトにあるIPv6ホスト間のIPv6通信の取り扱いにのみ関係しています。IPv4-有能なサイトにあるIPv4ホスト間のIPv4通信の処理は、このドキュメントの範囲外であり、[BGP/MPLS-VPN]でカバーされています。IPv4-対応のサイトにあるIPv4ホストとIPv6対応サイトにあるIPv6ホスト間の通信は、このドキュメントの範囲外です。
In a similar manner to how IPv4 VPN routes are distributed in [BGP/MPLS-VPN], BGP and its extensions are used to distribute routes from an IPv6 VPN site to all the other PE routers connected to a site of the same IPv6 VPN. PEs use "VPN Routing and Forwarding tables" (VRFs) to maintain the reachability information and forwarding information of each IPv6 VPN separately.
[BGP/MPLS-VPN]にIPv4 VPNルートがどのように分布するかと同様の方法で、BGPとその拡張機能を使用して、IPv6 VPNサイトから同じIPv6 VPNのサイトに接続された他のすべてのPEルーターにルートを配布します。PEは「VPNルーティングテーブルと転送テーブル」（VRFS）を使用して、各IPv6 VPNの到達可能性情報と転送情報を個別に維持します。
As is done for IPv4 VPNs [BGP/MPLS-VPN], we allow each IPv6 VPN to have its own IPv6 address space, which means that a given address may denote different systems in different VPNs. This is achieved via a new address family, the VPN-IPv6 Address Family, in a fashion similar to that of the VPN-IPv4 address family, defined in [BGP/MPLS-VPN], which prepends a Route Distinguisher to the IP address.
IPv4 VPNS [BGP/MPLS-VPN]で行われているように、各IPv6 VPNが独自のIPv6アドレススペースを持つことを許可します。つまり、特定のアドレスは異なるVPNの異なるシステムを示す場合があります。これは、新しいアドレスファミリーであるVPN-IPv6アドレスファミリーを介して達成されます。これは、[BGP/MPLS-VPN]で定義されているVPN-IPv4アドレスファミリーと同様の方法で、ルートの区別器をIPアドレスに前提としています。
In addition to its operation over MPLS Label Switched Paths (LSPs), the IPv4 BGP/MPLS VPN solution has been extended to allow operation over other tunneling techniques, including GRE tunnels, IP-in-IP tunnels [2547-GRE/IP], L2TPv3 tunnels [MPLS-in-L2TPv3], and IPsec protected tunnels [2547-IPsec]. In a similar manner, this document allows support of an IPv6 VPN service over MPLS LSPs, as well as over other tunneling techniques.
MPLSラベルスイッチ付きパス（LSP）の動作に加えて、IPv4 BGP/MPLS VPNソリューションが拡張され、GREトンネル、IP-in-IPトンネル[2547-GRE/IP]などの他のトンネル技術に対する動作が可能になりました。L2TPV3トンネル[MPLS-in-L2TPV3]、およびIPSEC保護トンネル[2547-IPSEC]。同様に、このドキュメントは、MPLS LSP、および他のトンネリング技術よりもIPv6 VPNサービスをサポートできます。
This document allows support for an IPv6 VPN service over an IPv4 backbone, as well as over an IPv6 backbone. The IPv6 VPN service supported is identical in both cases.
このドキュメントにより、IPv4バックボーンとIPv6バックボーンを介したIPv6 VPNサービスをサポートできます。サポートされているIPv6 VPNサービスは、どちらの場合も同一です。
The IPv6 VPN solution defined in this document offers the following benefits:
このドキュメントで定義されているIPv6 VPNソリューションは、次の利点を提供します。
o From both the Service Provider perspective and the customer perspective, the VPN service that can be supported for IPv6 sites is identical to the one that can be supported for IPv4 sites.
o サービスプロバイダーの観点と顧客の観点から、IPv6サイトでサポートできるVPNサービスは、IPv4サイトでサポートできるものと同じです。
o From the Service Provider perspective, operations of the IPv6 VPN service require the exact same skills, procedures, and mechanisms as those for the IPv4 VPN service.
o サービスプロバイダーの観点から、IPv6 VPNサービスの操作には、IPv4 VPNサービスのスキル、手順、およびメカニズムがまったく同じスキル、手順、およびメカニズムが必要です。
o Where both IPv4 VPNs and IPv6 VPN services are supported over an IPv4 core, the same single set of MP-BGP peering relationships and the same single PE-PE tunnel mesh MAY be used for both.
o IPv4 VPNとIPv6 VPNサービスの両方がIPv4コアでサポートされている場合、同じ単一のMP-BGPピアリング関係と同じシングルPE-PEトンネルメッシュの両方に使用される場合があります。
o The IPv6 VPN service is independent of whether the core runs IPv4 or IPv6. This is so that the IPv6 VPN service supported before and after a migration of the core from IPv4 to IPv6 is undistinguishable to the VPN customer.
o IPv6 VPNサービスは、CoreがIPv4またはIPv6を実行するかどうかに依存しません。これは、IPv4からIPv4へのコアの移行の前後にサポートされているIPv6 VPNサービスが、VPN顧客にとって見分けがつかないことです。
Note that supporting IPv4 VPN services over an IPv6 core is not covered by this document.
IPv6コアを介したIPv4 VPNサービスのサポートは、このドキュメントではカバーされていないことに注意してください。
The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes from multiple "address families". We introduce the notion of the "VPN-IPv6 address family", which is similar to the VPN-IPv4 address family introduced in [BGP/MPLS-VPN].
BGPマルチプロトコル拡張[BGP-MP]により、BGPは複数の「アドレスファミリ」からルートを運ぶことができます。[BGP/MPLS-VPN]で導入されたVPN-IPV4アドレスファミリに似た「VPN-IPV6アドレスファミリー」の概念を紹介します。
A VPN-IPv6 address is a 24-octet quantity, beginning with an 8-octet "Route Distinguisher" (RD) and ending with a 16-octet IPv6 address.
VPN-IPV6アドレスは24オクテット数量で、8オクテットの「ルート違い」（RD）から始まり、16オクテットIPv6アドレスで終了します。
The purpose of the RD is solely to allow one to create distinct routes to a common IPv6 address prefix, which is similar to the purpose of the RD defined in [BGP/MPLS-VPN]. In the same way as it is possible per [BGP/MPLS-VPN], the RD can be used to create multiple different routes to the very same system. This can be achieved by creating two different VPN-IPv6 routes that have the same IPv6 part but different RDs. This allows the provider's BGP to install multiple different routes to the same system and allows policy to be used to decide which packets use which route.
RDの目的は、[BGP/MPLS-VPN]で定義されているRDの目的に似た一般的なIPv6アドレスプレフィックスへの異なるルートを作成できるようにすることです。[BGP/MPLS-VPN]ごとに可能であるのと同じように、RDを使用して、まったく同じシステムに複数の異なるルートを作成できます。これは、同じIPv6部品を持つが異なるRDSを持つ2つの異なるVPN-IPV6ルートを作成することで実現できます。これにより、プロバイダーのBGPは同じシステムに複数の異なるルートをインストールでき、ポリシーを使用してどのパケットを使用するかを決定できます。
Also, if two VPNs were to use the same IPv6 address prefix (effectively denoting different physical systems), the PEs would translate these into unique VPN-IPv6 address prefixes using different RDs. This ensures that if the same address is ever used in two different VPNs, it is possible to install two completely different routes to that address, one for each VPN.
また、2つのVPNが同じIPv6アドレスプレフィックスを使用した場合（異なる物理システムを効果的に示す）、PESはこれらを異なるRDSを使用して一意のVPN-IPV6アドレスプレフィックスに変換します。これにより、同じアドレスが2つの異なるVPNで使用される場合、そのアドレスに2つの完全に異なるルートをインストールすることができます。
Since VPN-IPv6 addresses and IPv6 addresses belong to different address families, BGP never treats them as comparable addresses.
VPN-IPV6アドレスとIPv6アドレスは、異なるアドレスファミリに属しているため、BGPはそれらを同等のアドレスとして扱うことはありません。
A VRF may have multiple equal-cost VPN-IPv6 routes for a single IPv6 address prefix. When a packet's destination address is matched in a VRF against a VPN-IPv6 route, only the IPv6 part is actually matched.
VRFには、単一のIPv6アドレスプレフィックスの複数の等しいコストVPN-IPV6ルートがある場合があります。パケットの宛先アドレスがVPN-IPV6ルートに対してVRFで一致する場合、IPv6部品のみが実際に一致します。
The Route Distinguisher format and encoding is as specified in [BGP/MPLS-VPN].
ルートの区別形式とエンコードは、[BGP/MPLS-VPN]で指定されているとおりです。
When a site is IPv4 capable and IPv6 capable, the same RD MAY be used for the advertisement of IPv6 addresses and IPv4 addresses. Alternatively, a different RD MAY be used for the advertisement of the IPv4 addresses and of the IPv6 addresses. Note, however, that in the scope of this specification, IPv4 addresses and IPv6 addresses will always be handled in separate contexts, and that no IPv4-IPv6 interworking issues and techniques will be discussed.
サイトがIPv4対応でIPv6の有能である場合、IPv6アドレスとIPv4アドレスの広告には同じRDが使用される場合があります。あるいは、IPv4アドレスとIPv6アドレスの広告には、別のRDが使用される場合があります。ただし、この仕様の範囲では、IPv4アドレスとIPv6アドレスは常に別々のコンテキストで処理され、IPv4-IPv6インターワーキングの問題と手法は議論されないことに注意してください。
As described in [BGP/MPLS-VPN], if two sites of a VPN attach to PEs that are in the same Autonomous System, the PEs can distribute VPN routes to each other by means of an (IPv4) internal Border Gateway Protocol (iBGP) connection between them. Alternatively, each PE can have iBGP connections to route reflectors. Similarly, for IPv6 VPN route distribution, PEs can use iBGP connections between them or use iBGP connections to route reflectors. For IPv6 VPN, the iBGP connections MAY be over IPv4 or over IPv6.
[BGP/MPLS-VPN]で説明されているように、VPNの2つの部位が同じ自律システムにあるPESに付着する場合、PESはAN（IPv4）内部境界ゲートウェイプロトコル（IBGP）によってVPNルートを互いに配布できます。）それらの間の接続。あるいは、各PEは、ルートリフレクターへのIBGP接続を持つことができます。同様に、IPv6 VPNルート分布の場合、PESはそれらの間のIBGP接続を使用するか、IBGP接続を使用してリフレクターをルーティングできます。IPv6 VPNの場合、IBGP接続はIPv4またはIPv6を超えている場合があります。
The PE routers exchange, via MP-BGP [BGP-MP], reachability information for the IPv6 prefixes in the IPv6 VPNs and thereby announce themselves as the BGP Next Hop.
MP-BGP [BGP-MP]を介したPEルーターの交換は、IPv6 VPNのIPv6プレフィックスのリーチ可能性情報を発表し、それによりBGP Next Hopとしての自己発表を行います。
The rules for encoding the reachability information and the BGP Next Hop address are specified in the following sections.
Reachability情報とBGP Next Hopアドレスをエンコードするためのルールは、次のセクションで指定されています。
When distributing IPv6 VPN routes, the advertising PE router MUST assign and distribute MPLS labels with the IPv6 VPN routes. Essentially, PE routers do not distribute IPv6 VPN routes, but Labeled IPv6 VPN routes [MPLS-BGP]. When the advertising PE then receives a packet that has this particular advertised label, the PE will pop this label from the MPLS stack and process the packet appropriately (i.e., forward it directly according to the label or perform a lookup in the corresponding IPv6-VPN context).
IPv6 VPNルートを配布する場合、広告PEルーターはMPLSラベルをIPv6 VPNルートに割り当てて配布する必要があります。基本的に、PEルーターはIPv6 VPNルートを配布するのではなく、IPv6 VPNルート[MPLS-BGP]とラベル付けされています。広告PEがこの特定の広告ラベルを持つパケットを受信すると、PEはMPLSスタックからこのラベルをポップし、パケットを適切に処理します（つまり、ラベルに従って直接転送するか、対応するIPv6-VPNのルックアップを実行しますコンテクスト）。
The BGP Multiprotocol Extensions [BGP-MP] are used to advertise the IPv6 VPN routes in the MP_REACH Network Layer Reachability Information (NLRI). The Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI) fields MUST be set as follows:
BGPマルチプロトコル拡張[BGP-MP]は、MP_REACHネットワークレイヤーリーチビリティ情報（NLRI）のIPv6 VPNルートを宣伝するために使用されます。アドレスファミリ識別子（AFI）および後続のアドレスファミリ識別子（SAFI）フィールドは、次のように設定する必要があります。
- AFI: 2; for IPv6
- AFI：2;IPv6の場合
- SAFI: 128; for MPLS labeled VPN-IPv6
- SAFI：128;VPN-IPV6というラベルのMPLSの場合
The NLRI field itself is encoded as specified in [MPLS-BGP]. In the context of this extension, the prefix belongs to the VPN-IPv6 Address Family and thus consists of an 8-octet Route Distinguisher followed by an IPv6 prefix as specified in Section 2, above.
NLRIフィールド自体は、[MPLS-BGP]で指定されているようにエンコードされています。この拡張機能のコンテキストでは、プレフィックスはVPN-IPV6アドレスファミリーに属し、したがって、上記のセクション2で指定されているように、8-OCTETルートの区別器で構成されます。
The encoding of the BGP Next Hop depends on whether the policy of the BGP speaker is to request that IPv6 VPN traffic be transported to that BGP Next Hop using IPv6 tunneling ("BGP speaker requesting IPv6 transport") or using IPv4 tunneling ("BGP speaker requesting IPv4 transport").
BGP Next Hopのエンコードは、BGPスピーカーのポリシーがIPv6 VPNトラフィックをIPv6トンネリング（「IPv6トランスポートを要求するBGPスピーカー」）を使用してそのBGP Next Hopに輸送するか、IPv4トンネリングを使用するかどうかを要求するかどうかによって異なります。IPv4トランスポートの要求 "）。
Definition of this policy (to request transport over IPv4 tunneling or IPv6 tunneling) is the responsibility of the network operator and is beyond the scope of this document. Note that it is possible for that policy to request transport over IPv4 (resp. IPv6) tunneling while the BGP speakers exchange IPv6 VPN reachability information over IPv6 (resp. IPv4). However, in that case, a number of operational implications are worth considering. In particular, an undetected fault affecting the IPv4 (resp. IPv6) tunneling data path and not affecting the IPv6 (resp. IPv4) data path could remain undetected by BGP, which in turn may result in black-holing of traffic.
このポリシーの定義（IPv4トンネリングまたはIPv6トンネリングを介した輸送を要求するため）は、ネットワークオペレーターの責任であり、このドキュメントの範囲を超えています。BGPスピーカーがIPv6（Resp。IPv4）を介してIPv6 VPN Reachability情報を交換しながら、そのポリシーがIPv4（Resp。IPv6）トンネリングを介した輸送を要求することが可能であることに注意してください。ただし、その場合、多くの運用上の影響を検討する価値があります。特に、IPv4（Resp。IPv6）トンネルデータパスに影響を与える検出されない障害は、IPv6（Resp。IPv4）データパスに影響を与えない可能性があり、BGPによって検出されないままになり、トラフィックが黒く穴を開ける可能性があります。
Control of this policy is beyond the scope of this document and may be based on user configuration.
このポリシーの制御は、このドキュメントの範囲を超えており、ユーザー構成に基づいている場合があります。
When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv6 tunneling (e.g., IPv6 MPLS LSPs, IPsec-protected IPv6 tunnels), the BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address
IPv6 VPNトラフィックがIPv6トンネリングを使用してBGPスピーカーに輸送される場合（例：IPv6 MPLS LSP、IPSEC保護IPv6トンネルなど）、BGPスピーカーはVPN-IPV6アドレスを含む次のホップネットワークアドレスフィールドを宣伝するものとします。
- whose 8-octet RD is set to zero, and
- その8-OCTET RDはゼロに設定されています
- whose 16-octet IPv6 address is set to the global IPv6 address of the advertising BGP speaker.
- その16-OCTET IPv6アドレスは、広告BGPスピーカーのグローバルIPv6アドレスに設定されています。
This is potentially followed by another VPN-IPv6 address
これに続いて、別のVPN-IPV6アドレスが続きます
- whose 8-octet RD is set to zero, and
- その8-OCTET RDはゼロに設定されています
- whose 16-octet IPv6 address is set to the link-local IPv6 address of the advertising BGP speaker.
- その16-OCTET IPv6アドレスは、広告BGPスピーカーのLink-Local IPv6アドレスに設定されています。
The value of the Length of the Next Hop Network Address field in the MP_REACH_NLRI attribute shall be set to 24 when only a global address is present, and to 48 if a link-local address is also included in the Next Hop field.
MP_REACH_NLRI属性の次のホップネットワークアドレスフィールドの長さの値は、グローバルアドレスのみが存在する場合は24に設定され、次のホップフィールドにリンクローカルアドレスも含まれている場合は48に設定します。
If the BGP speakers peer using only their link-local IPv6 address (for example, in the case where an IPv6 CE peers with an IPv6 PE, where the CE does not have any IPv6 global address, and where eBGP peering is achieved over the link-local addresses), the "unspecified address" ([V6ADDR]) is used by the advertising BGP speaker to indicate the absence of the global IPv6 address in the Next Hop Network Address field.
BGPスピーカーは、Link-Local IPv6アドレスのみを使用してピアをピアします（たとえば、IPv6 CEがIPv6 PEを持つPEERS、CEにIPv6グローバルアドレスがない場合、およびEBGPピアリングがリンク上で達成される場合-localアドレス）、「不特定のアドレス」（[V6ADDR]）は、広告BGPスピーカーによって使用され、次のホップネットワークアドレスアドレスフィールドにグローバルIPv6アドレスが存在しないことを示します。
The link-local address shall be included in the Next Hop field if and only if the advertising BGP speaker shares a common subnet with the peer the route is being advertised to [BGP-IPv6].
Link-Localアドレスは、広告BGPスピーカーがピアと共通のサブネットを共有している場合にのみ、[BGP-IPV6]に広告されている場合にのみ、次のホップフィールドに含まれます。
In all other cases, a BGP speaker shall advertise to its peer in the Next Hop Network Address field only the global IPv6 address of the next hop.
他のすべての場合において、BGPスピーカーは、次のホップネットワークアドレスフィールドで、次のホップのグローバルIPv6アドレスのみにピアに宣伝するものとします。
As a consequence, a BGP speaker that advertises a route to an internal peer may modify the Network Address of Next Hop field by removing the link-local IPv6 address of the next hop.
結果として、内部ピアへのルートを宣伝するBGPスピーカーは、次のホップのLink-Local IPv6アドレスを削除することにより、次のホップフィールドのネットワークアドレスを変更する場合があります。
An example scenario where both the global IPv6 address and the link-local IPv6 address shall be included in the BGP Next Hop address field is that where the IPv6 VPN service is supported over a multi-Autonomous System (AS) backbone with redistribution of labeled VPN- IPv6 routes between Autonomous System Border Routers (ASBR) of different ASes sharing a common IPv6 subnet: in that case, both the global IPv6 address and the link-local IPv6 address shall be advertised by the ASBRs.
グローバルIPv6アドレスとLink-Local IPv6アドレスの両方がBGP Next Hopアドレスフィールドに含まれる例のシナリオは、標識VPNの再配布を備えたマルチ自律システム（AS）バックボーンでIPv6 VPNサービスがサポートされる場合です。-IPv6共通のIPv6サブネットを共有するさまざまなASEの自律システムボーダールーター（ASBR）間のルート：その場合、グローバルIPv6アドレスとLink-Local IPv6アドレスの両方がASBRSによって宣伝されます。
When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv4 tunneling (e.g., IPv4 MPLS LSPs, IPsec-protected IPv4 tunnels), the BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:
IPv6 VPNトラフィックがIPv4トンネリング（IPv4 MPLS LSP、IPSEC保護IPv4トンネルなど）を使用してBGPスピーカーに輸送される場合、BGPスピーカーは、VPN-IPV6アドレスを含む次のホップネットワークアドレスフィールドを宣伝するものとします。：
- whose 8-octet RD is set to zero, and
- その8-OCTET RDはゼロに設定されています
- whose 16-octet IPv6 address is encoded as an IPv4-mapped IPv6 address [V6ADDR] containing the IPv4 address of the advertising BGP speaker. This IPv4 address must be routable by the other BGP Speaker.
- 16-OCTET IPv6アドレスは、広告BGPスピーカーのIPv4アドレスを含むIPv4マップIPv6アドレス[V6ADDR]としてエンコードされています。このIPv4アドレスは、他のBGPスピーカーがルーティング可能でなければなりません。
The use of route target is specified in [BGP/MPLS-VPN] and applies to IPv6 VPNs. Encoding of the extended community attribute is defined in [BGP-EXTCOM].
ルートターゲットの使用は[BGP/MPLS-VPN]で指定され、IPv6 VPNSに適用されます。拡張されたコミュニティ属性のエンコードは、[BGP-Extcom]で定義されています。
In order for two PEs to exchange labeled IPv6 VPN NLRIs, they MUST use BGP Capabilities Negotiation to ensure that they both are capable of properly processing such NLRIs. This is done as specified in [BGP-MP] and [BGP-CAP], by using capability code 1 (multiprotocol BGP), with AFI and SAFI values as specified above, in Section 3.2.
2つのPESがラベルのIPv6 VPN NLRIを交換するためには、BGP機能の交渉を使用して、どちらもそのようなNLRIを適切に処理できるようにする必要があります。これは、[BGP-MP]および[BGP-CAP]で指定されているように、機能コード1（MultiProtoCol BGP）を使用して、上記のAFI値とSAFI値をセクション3.2で使用します。
The ingress PE Router MUST tunnel IPv6 VPN data over the backbone towards the Egress PE router identified as the BGP Next Hop for the corresponding destination IPv6 VPN prefix.
Ingress PEルーターは、バックボーンを介してIPv6 VPNデータをトンネルにして、BGP次のホップとして識別された出力PEルーターに向かって、対応する宛先IPv6 VPNプレフィックスのホップに向かう必要があります。
When the 16-octet IPv6 address contained in the BGP Next Hop field is encoded as an IPv4-mapped IPv6 address (see Section 3.2.1.2), the ingress PE MUST use IPv4 tunneling unless explicitly configured to do otherwise. The ingress PE MAY optionally allow, through explicit configuration, the use of IPv6 tunneling when the 16-octet IPv6 address contained in the BGP Next Hop field is encoded as an IPv4- mapped IPv6 address. This would allow support of particular deployment environments where IPv6 tunneling is desired but where IPv4-mapped IPv6 addresses happen to be used for IPv6 reachability of the PEs instead of Global IPv6 addresses.
BGP Next Hopフィールドに含まれる16-OCTET IPv6アドレスがIPv4-Mapped IPv6アドレスとしてエンコードされている場合（セクション3.2.1.2を参照）、Ingress PEは、明示的に設定されていない限り、IPv4トンネリングを使用する必要があります。Ingress PEは、明示的な構成を通じて、BGP Next Hopフィールドに含まれる16-OCTET IPv6アドレスがIPv4マッピングIPv6アドレスとしてエンコードされた場合に、IPv6トンネリングの使用をオプションで許可する場合があります。これにより、IPv6トンネリングが望まれている特定の展開環境のサポートが可能になりますが、IPv4-Mapped IPv6アドレスがグローバルIPv6アドレスの代わりにPESのIPv6の到達可能性に使用される場合があります。
When the 16-octet IPv6 address contained in the BGP Next Hop field is not encoded as an IPv4-mapped address (see Section 3.2.1.1), the ingress PE MUST use IPv6 tunneling.
BGP Next Hopフィールドに含まれる16-OCTET IPv6アドレスがIPv4マップアドレスとしてエンコードされていない場合（セクション3.2.1.1を参照）、Ingress PEはIPv6トンネリングを使用する必要があります。
When a PE receives a packet from an attached CE, it looks up the packet's IPv6 destination address in the VRF corresponding to that CE. This enables it to find a VPN-IPv6 route. The VPN-IPv6 route will have an associated MPLS label and an associated BGP Next Hop. First, this MPLS label is pushed on the packet as the bottom label. Then, this labeled packet is encapsulated into the tunnel for transport to the egress PE identified by the BGP Next Hop. Details of this encapsulation depend on the actual tunneling technique, as follows:
PEが添付のCEからパケットを受信すると、そのCEに対応するVRFのパケットのIPv6宛先アドレスを調べます。これにより、VPN-IPV6ルートを見つけることができます。VPN-IPV6ルートには、関連するMPLSラベルと関連するBGP次のホップがあります。まず、このMPLSラベルは、ボトムラベルとしてパケットに押し付けられます。次に、このラベルの付いたパケットは、BGP Next Hopによって識別された出力PEへの輸送のためにトンネルにカプセル化されます。このカプセル化の詳細は、次のように実際のトンネリング手法に依存します。
As with MPLS/BGP for IPv4 VPNs [2547-GRE/IP], when tunneling is done using IPv4 tunnels or IPv6 tunnels (resp. IPv4 GRE tunnels or IPv6 GRE tunnels), encapsulation of the labeled IPv6 VPN packet results in an MPLS-in-IP (resp. MPLS-in-GRE) encapsulated packet as specified in [MPLS-in-IP/GRE]. When tunneling is done using L2TPv3, encapsulation of the labeled IPv6 VPN packet results in an MPLS-in-L2TPv3- encapsulated packet, as specified in [MPLS-in-L2TPv3].
IPv4 VPNS [2547-GRE/IP]のMPLS/BGPと同様に、TunnelingがIPv4トンネルまたはIPv6トンネル（IPv4 GREトンネルまたはIPv6 GREトンネル）を使用してトンネリングが行われた場合、MPLSでの標識IPv6 VPNパケットのカプセル化IN-IP（Resp。MPLS-in-GRE）カプセル化されたパケット[MPLS-in-IP/GRE]で指定されています。L2TPV3を使用してトンネリングが行われると、[MPLS-in-L2TPV3]で指定されているように、標識IPv6 VPNパケットのカプセル化により、MPLS-in-L2TPV3-カプセル化パケットが得られます。
As with MPLS/BGP for IPv4 VPNs, when tunneling is done using an IPsec secured tunnel [2547-IPsec], encapsulation of the labeled IPv6 VPN packet results in an MPLS-in-IP- or MPLS-in-GRE-encapsulated packet [MPLS-in-IP/GRE]. The IPsec Transport Mode is used to secure this IPv4 or GRE tunnel from ingress PE to egress PE.
IPv4 VPNSのMPLS/BGPと同様に、トンネルがIPSECセキュリティトンネル[2547-IPSEC]を使用して行われた場合、標識IPv6 VPNパケットのカプセル化は、MPLS-IP-IN-IPまたはGRE-IN-GR-Ingapsulated Packet [mpls-in-ip/gre]。IPSEC輸送モードは、このIPv4またはGREトンネルをイングレスPEから出力PEに固定するために使用されます。
When tunneling is done using IPv4 tunnels (whether IPsec secured or not), the Ingress PE Router MUST use the IPv4 address that is encoded in the IPv4-mapped IPv6 address field of the BGP next hop field as the destination address of the prepended IPv4 tunneling header. It uses one of its IPv4 addresses as the source address of the prepended IPv4 tunneling header.
IPv4トンネルを使用してトンネリングが完了した場合（IPSECが保護されているかどうか）、Ingress PEルーターは、BGPのIPv4アドレスフィールドでエンコードされているIPv4アドレスを使用して、BGPの次のホップフィールドフィールドにプリグメントされたIPv4トンネリングの宛先アドレスとして使用する必要があります。ヘッダ。IPv4アドレスの1つを、Prearended IPv4 Tunnelingヘッダーのソースアドレスとして使用します。
When tunneling is done using IPv6 tunnels (whether IPsec secured or not), the Ingress PE Router MUST use the IPv6 address that is contained in the IPv6 address field of the BGP next hop field as the destination address of the prepended IPv6 tunneling header. It uses one of its IPv6 addresses as the source address of the prepended IPv6 tunneling header.
IPv6トンネルを使用してトンネリングが完了した場合（IPSECが保護されているかどうか）、Ingress PEルーターは、BGP Next HopフィールドのIPv6アドレスフィールドに、準備付きIPv6トンネルヘッダーの宛先アドレスとして含まれるIPv6アドレスを使用する必要があります。IPv6アドレスの1つを、Prearended IPv6 Tunnelingヘッダーのソースアドレスとして使用します。
When tunneling is done using MPLS LSPs, the LSPs can be established using any label distribution technique (LDP [LDP], RSVP-TE [RSVP-TE], etc.).
MPLS LSPを使用してトンネリングが行われると、LSPは任意のラベル分布技術（LDP [LDP]、RSVP-TE [RSVP-TE]など）を使用して確立できます。
When tunneling is done using MPLS LSPs, the ingress PE Router MUST directly push the LSP tunnel label on the label stack of the labeled IPv6 VPN packet (i.e., without prepending any IPv4 or IPv6 header). This pushed label corresponds to the LSP starting on the ingress PE Router and ending on the egress PE Router. The BGP Next Hop field is used to identify the egress PE router and in turn the label to be pushed on the stack. When the IPv6 address in the BGP Next Hop field is an IPv4-mapped IPv6 address, the embedded IPv4 address will determine the tunnel label to push on the label stack. In any other case, the IPv6 address in the BGP Next Hop field will determine the tunnel label to push on the label stack.
MPLS LSPを使用してトンネルが行われる場合、Ingress PEルーターは、ラベル付きIPv6 VPNパケットのラベルスタックにLSPトンネルラベルを直接プッシュする必要があります（つまり、IPv4またはIPv6ヘッダーを準備せずに）。このプッシュされたラベルは、イングレスPEルーターから始まり、出力PEルーターで終了するLSPに対応します。BGP Next Hopフィールドは、出力PEルーターを識別するために使用され、順番にスタックに押し出されるラベルが識別されます。BGPの次のホップフィールドのIPv6アドレスがIPv4マップIPv6アドレスである場合、埋め込まれたIPv4アドレスは、ラベルスタックをプッシュするトンネルラベルを決定します。他の場合、BGP Next HopフィールドのIPv6アドレスは、ラベルスタックをプッシュするトンネルラベルを決定します。
To ensure interoperability among systems that implement this VPN architecture, all such systems MUST support tunneling using MPLS LSPs established by LDP [LDP].
このVPNアーキテクチャを実装するシステム間の相互運用性を確保するために、そのようなシステムはすべて、LDP [LDP]によって確立されたMPLS LSPを使用したトンネリングをサポートする必要があります。
Since Link-local unicast addresses are defined for use on a single link only, those may be used on the PE-CE link, but they are not supported for reachability across IPv6 VPN Sites and are never advertised via MultiProtocol-Border Gateway Protocol (MP-BGP) to remote PEs.
リンクローカルユニキャストアドレスは単一のリンクでのみ使用するために定義されているため、それらはPE-CEリンクで使用できますが、IPv6 VPNサイト全体でのリーチ性のためにサポートされておらず、MultiProtocol-Border Gateway Protocol（MPを介して宣伝されることはありません。-bgp）リモートPEへ。
Global unicast addresses are defined as uniquely identifying interfaces anywhere in the IPv6 Internet. Global addresses are expected to be commonly used within and across IPv6 VPN Sites. They are obviously supported by this IPv6 VPN solution for reachability across IPv6 VPN Sites and advertised via MP-BGP to remote PEs and are processed without any specific considerations to their global scope.
グローバルユニキャストアドレスは、IPv6インターネットのどこにでもユニークに識別されるインターフェイスとして定義されます。グローバルアドレスは、IPv6 VPNサイト内および内外で一般的に使用されると予想されます。これらは、IPv6 VPNサイト全体の到達可能性のためにこのIPv6 VPNソリューションによって明らかにサポートされており、MP-BGPを介してリモートPEに宣伝されており、グローバル範囲に特定の考慮事項なしで処理されます。
Quoting from [UNIQUE-LOCAL]: "This document defines an IPv6 unicast address format that is globally unique and is intended for local communications [IPv6]. These addresses are called Unique Local IPv6 Unicast Addresses and are abbreviated in this document as Local IPv6 addresses. They are not expected to be routable on the global Internet. They are routable inside of a more limited area such as a site. They may also be routed between a limited set of sites."
[ユニークローカル]から引用：「このドキュメントは、グローバルに一意であり、ローカル通信を目的としたIPv6ユニキャストアドレス形式を定義します[IPv6]。。彼らはグローバルなインターネット上でルーティング可能であるとは期待されていません。サイトなど、より限られた領域内でルーティング可能です。また、限られたサイトのセット間でルーティングされる場合があります。」
[UNIQUE-LOCAL] also says in its Section 4.7: "Local IPv6 addresses can be used for inter-site Virtual Private Networks (VPN) if appropriate routes are set up. Because the addresses are unique these VPNs will work reliably and without the need for translation. They have the additional property that they will continue to work if the individual sites are renumbered or merged."
[ユニークローカル]は、セクション4.7にも述べています。「適切なルートがセットアップされている場合、ローカルIPv6アドレスは、サイト間仮想プライベートネットワーク（VPN）に使用できます。翻訳のために。彼らは、個々のサイトが変更または融合されている場合、彼らが引き続き機能するという追加のプロパティを持っています。」
In accordance with this, Unique Local IPv6 Unicast Addresses are supported by the IPv6 VPN solution specified in this document for reachability across IPv6 VPN Sites. Hence, reachability to such Unique Local IPv6 Addresses may be advertised via MP-BGP to remote PEs and processed by PEs in the same way as Global Unicast addresses.
これに従って、一意のローカルIPv6ユニキャストアドレスは、IPv6 VPNサイト全体で到達可能性についてこのドキュメントで指定されたIPv6 VPNソリューションによってサポートされています。したがって、このような一意のローカルIPv6アドレスへの到達可能性は、MP-BGPを介してリモートPEに宣伝され、グローバルユニキャストアドレスと同じ方法でPESによって処理される場合があります。
Recommendations and considerations for which of these supported address types should be used in given IPv6 VPN environments are beyond the scope of this document.
これらのサポートされているアドレスタイプのうち、IPv6 VPN環境がこのドキュメントの範囲を超えていることについての推奨事項と考慮事項。
Multicast operations are outside the scope of this document.
マルチキャスト操作は、このドキュメントの範囲外です。
Sometimes, an IPv6 VPN may actually be the network of an IPv6 ISP, with its own peering and routing policies. Sometimes, an IPv6 VPN may be the network of an SP that is offering VPN services in turn to its own customers. IPv6 VPNs like these can also obtain backbone service from another SP, the "Carrier's Carrier", using the Carriers' Carrier method described in Section 9 of [BGP/MPLS-VPN] but applied to IPv6 traffic. All the considerations discussed in [BGP/MPLS-VPN] for IPv4 VPN Carriers' Carrier apply for IPv6 VPN, with the exception that the use of MPLS (including label distribution) between the PE and the CE pertains to IPv6 routes instead of IPv4 routes.
場合によっては、IPv6 VPNが実際にIPv6 ISPのネットワークであり、独自のピアリングおよびルーティングポリシーを備えている場合があります。場合によっては、IPv6 VPNがVPNサービスを自社の顧客に提供しているSPのネットワークである場合があります。このようなIPv6 VPNは、[BGP/MPLS-VPN]のセクション9で説明されているキャリアのキャリア法を使用して、別のSP、「キャリアのキャリア」からバックボーンサービスを取得することもできますが、IPv6トラフィックに適用されます。IPv4 VPNキャリアのキャリアについて[BGP/MPLS-VPN]で議論されたすべての考慮事項は、PEとCE間のMPLS（ラベル分布を含む）の使用がIPv4ルートの代わりにIPv6ルートに関連することを除いて、IPv6 VPNに適用されます。。
The same procedures described in Section 10 of [BGP/MPLS-VPN] can be used (and have the same scalability properties) to address the situation where two sites of an IPv6 VPN are connected to different Autonomous Systems. However, some additional points should be noted when applying these procedures for IPv6 VPNs; these are further described in the remainder of this section.
[BGP/MPLS-VPN]のセクション10で説明されているのと同じ手順を使用して（および同じスケーラビリティプロパティを持つことができます）、IPv6 VPNの2つのサイトが異なる自律システムに接続されている状況に対処できます。ただし、これらの手順をIPv6 VPNSに適用する場合、いくつかの追加ポイントに注意する必要があります。これらについては、このセクションの残りの部分でさらに説明します。
Approach (a): VRF-to-VRF connections at the AS (Autonomous System) border routers.
アプローチ（A）：AS（自律システム）境界ルーターでのVRFからVRF接続。
This approach is the equivalent for IPv6 VPNs to procedure (a) in Section 10 of [BGP/MPLS-VPN]. In the case of IPv6 VPNs, IPv6 needs to be activated on the inter-ASBR VRF-to-VRF (sub)interfaces. In this approach, the ASBRs exchange IPv6 routes (as opposed to VPN-IPv6 routes) and may peer over IPv6 or over IPv4. The exchange of IPv6 routes MUST be carried out as per [BGP-IPv6]. This method does not use inter-AS LSPs.
このアプローチは、[BGP/MPLS-VPN]のセクション10のIPv6 VPNS（a）に相当するものです。IPv6 VPNSの場合、IPv6はASBR間VRF-to-VRF（Sub）インターフェイスでアクティブ化する必要があります。このアプローチでは、ASBRSは（VPN-IPV6ルートとは対照的に）IPv6を交換し、IPv6またはIPv4を介して覗くことがあります。IPv6ルートの交換は、[BGP-IPV6]に従って実行する必要があります。この方法では、inter-as LSPを使用しません。
Finally, note that with this procedure, since every AS independently implements the intra-AS procedures for IPv6 VPNs described in this document, the participating ASes may all internally use IPv4 tunneling, or IPv6 tunneling; or alternatively, some participating ASes may internally use IPv4 tunneling while others use IPv6 tunneling.
最後に、この手順では、このドキュメントに記載されているIPv6 VPNのAS Inter-AS手順を独立して実装するため、参加ASESはすべてIPv4トンネルまたはIPv6トンネリングをすべて内部で使用できることに注意してください。あるいは、一部の参加ASESはIPv4トンネルを内部的に使用し、他のASEはIPv6トンネリングを使用する場合があります。
Approach (b): EBGP redistribution of labeled VPN-IPv6 routes from AS to neighboring AS.
アプローチ（B）：ASから隣接するASからのラベル付きVPN-IPV6ルートのEBGP再分布。
This approach is the equivalent for IPv6 VPNs to procedure (b) in Section 10 of [BGP/MPLS-VPN]. With this approach, the ASBRs use EBGP to redistribute labeled VPN-IPv4 routes to ASBRs in other ASes.
このアプローチは、[BGP/MPLS-VPN]のセクション10のIPv6 VPNS（b）に相当するものです。このアプローチにより、ASBRはEBGPを使用して、ラベル付きVPN-IPV4ルートを他のASEのASBRに再配布します。
In this approach, IPv6 may or may not be activated on the inter-ASBR links since the ASBRs exchanging VPN-IPv6 routes may peer over IPv4 or IPv6 (in which case, IPv6 obviously needs to be activated on the inter-ASBR link). The exchange of labeled VPN-IPv6 routes MUST be carried out as per [BGP-IPv6] and [MPLS-BGP]. When the VPN-IPv6 traffic is to be transported using IPv6 tunneling, the BGP Next Hop Field SHALL contain an IPv6 address. When the VPN-IPv6 traffic is to be transported using IPv4 tunneling, the BGP Next Hop Field SHALL contain an IPv4 address encoded as an IPv4-mapped IPv6 address.
このアプローチでは、VPN-IPV6ルートを交換するASBRSがIPv4またはIPv6を介してピアを覗く可能性があるため、IPv6がASBR間リンクでアクティブになっている場合とそうでない場合があります（この場合、IPv6は明らかにASBRリンクでアクティブ化する必要があります）。標識されたVPN-IPV6ルートの交換は、[BGP-IPV6]および[MPLS-BGP]に従って実行する必要があります。VPN-IPV6トラフィックをIPv6トンネリングを使用して輸送する場合、BGP Next HopフィールドにはIPv6アドレスが含まれます。VPN-IPV6トラフィックをIPv4トンネリングを使用して輸送する場合、BGP Next Hopフィールドには、IPv4-Mapped IPv6アドレスとしてエンコードされたIPv4アドレスが含まれます。
This approach requires that there be inter-AS LSPs. As such, the corresponding (security) considerations described for procedure (b) in Section 10 of [BGP/MPLS-VPN] apply equally to this approach for IPv6.
このアプローチでは、lsps間であることが必要です。そのため、[BGP/MPLS-VPN]のセクション10の手順（b）で説明されている対応する（セキュリティ）考慮事項は、IPv6のこのアプローチに等しく適用されます。
Finally, note that with this procedure, as with procedure (a), since every AS independently implements the intra-AS procedures for IPv6 VPNs described in this document, the participating ASes may all internally use IPv4 tunneling or IPv6 tunneling; alternatively, some participating ASes may internally use IPv4 tunneling while others use IPv6 tunneling.
最後に、この手順（a）と同様に、この手順では、このドキュメントで説明されているIPv6 VPNのAS Intra-AS手順を独立して実装するため、参加するASEはすべてIPv4トンネルまたはIPv6トンネリングをすべて使用する可能性があることに注意してください。あるいは、参加しているASの一部はIPv4トンネリングを内部的に使用し、他のASEはIPv6トンネリングを使用する場合があります。
Approach (c): Multihop EBGP redistribution of labeled VPN-IPv6 routes between source and destination ASes, with EBGP redistribution of labeled IPv4 or IPv6 routes from AS to neighboring AS.
アプローチ（c）：ソースASと宛先ASEの間の標識VPN-IPV6ルートのマルチホップEBGPの再分布。ASから隣接するASから標識されたIPv4またはIPv6ルートのEBGP再分布。
This approach is equivalent for exchange of VPN-IPv6 routes to procedure (c) in Section 10 of [BGP/MPLS-VPN] for exchange of VPN-IPv4 routes.
このアプローチは、VPN-IPV4ルートの交換のための[BGP/MPLS-VPN]のセクション10の手順（C）とのVPN-IPV6ルートの交換（C）と同等です。
This approach requires that the participating ASes either all use IPv4 tunneling or all use IPv6 tunneling.
このアプローチでは、参加するASEがすべてIPv4トンネリングを使用するか、すべてIPv6トンネリングを使用する必要があります。
In this approach, VPN-IPv6 routes are neither maintained nor distributed by the ASBR routers. The ASBR routers need not be dual stack. An ASBR needs to maintain labeled IPv4 (or IPv6) routes to the PE routers within its AS. It uses EBGP to distribute these routes to other ASes. ASBRs in any transit ASes will also have to use EBGP to pass along the labeled IPv4 (or IPv6) routes. This results in the creation of an IPv4 (or IPv6) label switch path from ingress PE router to egress PE router. Now, PE routers in different ASes can establish multi-hop EBGP connections to each other over IPv4 or IPv6 and can exchange labeled VPN-IPv6 routes over those EBGP connections. Note that the BGP Next Hop field of these distributed VPN-IPv6 routes will contain an IPv6 address when IPv6 tunneling is used or an IPv4-mapped IPv6 address when IPv4 tunneling is used.
このアプローチでは、VPN-IPV6ルートはASBRルーターによって維持も分布もありません。ASBRルーターはデュアルスタックである必要はありません。ASBRは、AS内のPEルーターへのラベル付きIPv4（またはIPv6）ルートを維持する必要があります。EBGPを使用して、これらのルートを他のASEに分配します。任意の輸送ASESのASBRは、EBGPを使用して、ラベル付きのIPv4（またはIPv6）ルートを渡す必要があります。これにより、IPv4（またはIPv6）ラベルスイッチパスがイングレスPEルーターからPEルーターを出力するようになります。これで、異なるASEのPEルーターは、IPv4またはIPv6を介して互いにマルチホップEBGP接続を確立し、これらのEBGP接続でラベル付けされたVPN-IPV6ルートを交換できます。これらの分散型VPN-IPV6ルートのBGP次のホップフィールドには、IPv6トンネリングが使用されるときはIPv6アドレス、またはIPv4トンネリングを使用するときのIPv4マップIPv6アドレスを含むことに注意してください。
The considerations described for procedure (c) in Section 10 of [BGP/MPLS-VPN] with respect to possible use of route-reflectors, with respect to possible use of a third label, and with respect to LSPs spanning multiple ASes apply equally to this IPv6 VPN approach.
[BGP/MPLS-VPN]のセクション10の手順（c）について説明した考慮事項は、ルート反射器の使用の可能性に関して、3番目のラベルの使用の可能性に関して、および複数のASEにまたがるLSPに関して等しく適用されることに関してこのIPv6 VPNアプローチ。
The methods proposed by [BGP/MPLS-VPN] to access the global IPv4 Internet from an IPv4 VPN can be used in the context of IPv6 VPNs and the global IPv6 Internet. Note, however, that if the IPv6 packets from IPv6 VPN sites and destined for the global IPv6 Internet need to traverse the SP backbone, and that if this is an IPv4 only backbone, these packets must be tunneled through that IPv4 backbone.
[BGP/MPLS-VPN]によって提案された方法は、IPv4 VPNからグローバルIPv4インターネットにアクセスするためにIPv6 VPNSおよびグローバルIPv6インターネットのコンテキストで使用できます。ただし、IPv6 VPNサイトからのIPv6パケットとグローバルIPv6インターネット用に運命づけられている場合は、SPバックボーンを横断する必要があり、これがIPv4のみのバックボーンである場合、これらのパケットはそのIPv4バックボーンを通してトンネルを取る必要があることに注意してください。
Clearly, as is the case outside the VPN context, access to the IPv6 Internet from an IPv6 VPN requires the use of global IPv6 addresses.
明らかに、VPNコンテキストの外側の場合と同様に、IPv6 VPNからのIPv6インターネットへのアクセスには、グローバルIPv6アドレスの使用が必要です。
In particular, Unique Local IPv6 addresses cannot be used for IPv6 Internet access.
特に、IPv6インターネットアクセスには、一意のローカルIPv6アドレスを使用することはできません。
The management considerations discussed in Section 12 of [BGP/MPLS-VPN] apply to the management of IPv6 VPNs.
[BGP/MPLS-VPN]のセクション12で説明されている管理上の考慮事項は、IPv6 VPNSの管理に適用されます。
Where the Service Provider manages the CE of the IPv6 VPN site, the Service Provider may elect to use IPv4 for communication between the management tool and the CE for such management purposes. In that case, regardless of whether a customer IPv4 site is actually connected to the CE (in addition to the IPv6 site), the CE is effectively part of an IPv4 VPN in addition to belonging to an IPv6 VPN (i.e., the CE is attached to a VRF that supports IPv4 in addition to IPv6). Considerations presented in [BGP/MPLS-VPN], on how to ensure that the management tool can communicate with such managed CEs from multiple VPNs without allowing undesired reachability across CEs of different VPNs, are applicable to the IPv4 reachability of the VRF to which the CE attaches.
サービスプロバイダーがIPv6 VPNサイトのCEを管理する場合、サービスプロバイダーは、そのような管理目的で、管理ツールとCE間の通信にIPv4を使用することを選択できます。その場合、顧客IPv4サイトが実際にCEに接続されているかどうかにかかわらず（IPv6サイトに加えて）、CEはIPv6 VPNに属することに加えてIPv4 VPNの一部です（つまり、CEは添付されています。IPv6に加えてIPv4をサポートするVRFに）。[BGP/MPLS-VPN]で提示された考慮事項は、異なるVPNのCESにわたって望ましくない到達可能性を許可することなく、管理ツールが複数のVPNからそのような管理されたCEと通信できるようにする方法について、VRFのIPv4の到達可能性に適用可能です。CEアタッチング。
Where the Service Provider manages the CE of the IPv6 VPN site, the Service Provider may elect to use IPv6 for communication between the management tool and the CE for such management purposes. Considerations presented in [BGP/MPLS-VPN], on how to ensure that the management tool can communicate with such managed CEs from multiple VPNs without allowing undesired reachability across CEs of different VPNs, are then applicable to the IPv6 reachability of the VRF to which the CE attaches.
サービスプロバイダーがIPv6 VPNサイトのCEを管理する場合、サービスプロバイダーは、そのような管理目的で、管理ツールとCE間の通信にIPv6を使用することを選択できます。[BGP/MPLS-VPN]で提示された考慮事項、管理ツールが異なるVPNのCESにわたって望ましくない到達可能性を許可することなく、複数のVPNからそのような管理されたCEと通信できるようにする方法は、VRFのIPv6リーチビリティに適用可能です。CEが添付されます。
The extensions defined in this document allow MP-BGP to propagate reachability information about IPv6 VPN routes.
このドキュメントで定義されている拡張機能により、MP-BGPはIPv6 VPNルートに関する到達可能性情報を伝播できます。
Security considerations for the transport of IPv6 reachability information using BGP are discussed in RFC2545, Section 5, and are equally applicable for the extensions described in this document.
BGPを使用したIPv6リーチビリティ情報の輸送に関するセキュリティ上の考慮事項は、RFC2545、セクション5で説明されており、このドキュメントで説明されている拡張機能に等しく適用できます。
The extensions described in this document for offering IPv6 VPNs use the exact same approach as the approach described in [BGP/MPLS-VPN]. As such, the same security considerations apply with regards to Data Plane security, Control Plane security, and PE and P device security as described in [BGP/MPLS-VPN], Section 13.
このドキュメントで説明する拡張機能は、[BGP/MPLS-VPN]で説明されているアプローチとまったく同じアプローチを使用します。そのため、[BGP/MPLS-VPN]、セクション13で説明されているように、データプレーンのセキュリティ、制御プレーンのセキュリティ、およびPEおよびPデバイスのセキュリティに関して、同じセキュリティ上の考慮事項が適用されます。
Since all the QoS mechanisms discussed for IPv4 VPNs in Section 14 of [BGP/MPLS-VPN] operate in the same way for IPv4 and IPv6 (Diffserv, Intserv, MPLS Traffic Engineering), the QoS considerations discussed in [BGP/MPLS-VPN] are equally applicable to IPv6 VPNs (and this holds whether IPv4 tunneling or IPv6 tunneling is used in the backbone.)
[BGP/MPLS-VPN]のセクション14でIPv4 VPNについて説明したすべてのQoSメカニズムは、IPv4とIPv6（diffserv、intserv、MPLSトラフィックエンジニアリング）で同じように動作するため、[QOSの考慮事項は[BGP/MPLS-VPNで説明されています。]はIPv6 VPNSに等しく適用できます（これにより、IPv4トンネリングまたはIPv6トンネリングがバックボーンで使用されているかどうかが保持されます）。
Each of the scalability considerations summarized for IPv4 VPNs in Section 15 of [BGP/MPLS-VPN] is equally applicable to IPv6 VPNs.
[BGP/MPLS-VPN]のセクション15のIPv4 VPNについて要約された各スケーラビリティの考慮事項は、IPv6 VPNに等しく適用できます。
This document specifies (see Section 3.2) the use of the BGP AFI (Address Family Identifier) value 2, along with the BGP SAFI (Subsequent Address Family Identifier) value 128, to represent the address family "VPN-IPv6 Labeled Addresses", which is defined in this document.
このドキュメントは、BGP AFI（アドレスファミリ識別子）値2の使用を指定します（BGP SAFI（後続の家族識別子）値128とともに、住所ファミリ「VPN-IPV6ラベル付きアドレス」を表します。このドキュメントで定義されています。
The use of AFI value 2 for IPv6 is as currently specified in the IANA registry "Address Family Identifier", so IANA need not take any action with respect to it.
IPv6のAFI値2の使用は、IANAレジストリ「アドレスファミリー識別子」で現在指定されているとおりであるため、IANAはそれに関して何の措置を講じていません。
The use of SAFI value 128 for "MPLS-labeled VPN address" is as currently specified in the IANA registry "Subsequence Address Family Identifier", so IANA need not take any action with respect to it.
「MPLS標識VPNアドレス」にSAFI値128の使用は、現在IANAレジストリ「サブシーケンスアドレスファミリ識別子」で指定されているとおりです。
We would like to thank Gerard Gastaud and Eric Levy-Abegnoli, who contributed to this document.
この文書に貢献したGerard GastaudとEric Levy-Abegnoliに感謝します。
In Memoriam
追悼で
The authors would like to acknowledge the valuable contribution to this document from Tri T. Nguyen, who passed away in April 2002 after a sudden illness.
著者は、2002年4月に突然の病気の後に亡くなったTri T. Nguyenからのこの文書への貴重な貢献を認めたいと考えています。
[BGP/MPLS-VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[BGP/MPLS-VPN] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、RFC 4364、2006年2月。
[BGP-EXTCOM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[BGP-Extcom] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP Extended Communities Attribute」、RFC 4360、2006年2月。
[BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[BGP-MP] Bates、T.、Rekhter、Y.、Chandra、R。、およびD. Katz、「BGP-4のマルチプロトコル拡張」、RFC 2858、2000年6月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[MPLS-BGP] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[MPLS-BGP] Rekhter、Y。およびE. Rosen、「BGP-4でのラベル情報の運搬」、RFC 3107、2001年5月。
[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月。
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[LDP] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。、およびB. Thomas、「LDP仕様」、RFC 3036、2001年1月。
[BGP-IPv6] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
[BGP-IPV6] Marques、P。and F. Dupont、「IPv6インタードメインルーティングのBGP-4マルチプロトコル拡張の使用」、RFC 2545、1999年3月。
[V6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[V6ADDR] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[UNIQUE-LOCAL] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[ユニークローカル]ヒンデン、R。およびB.ハーバーマン、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、2005年10月。
[2547-GRE/IP] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547 VPNs", Work in Progress.
[2547-GRE/IP] Rekhter and Rosen、「RFC2547 VPNSでのPE-PE GREまたはIPの使用」、進行中の作業。
[2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use of PE-PE IPsec in RFC2547 VPNs", Work in Progress, August 2005.
[2547-IPSEC] Rosen、De Clercq、Paridaens、T'Joens、Sargor、「RFC2547 VPNSでのPE-PE IPSECの使用」、2005年8月の進行中。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP-TE] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSPトンネルのRSVPへの拡張"、RFC 3209、2001年12月。
[MPLS-in-IP/GRE] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[MPLS-in-IP/GRE] Worster、T.、Rekhter、Y。、およびE. Rosen、「IPまたは汎用ルーティングカプセル化（GRE）のMPLのカプセル化」、RFC 4023、2005年3月。
[MPLS-in-L2TPv3] Townsley, M., et al., "Encapsulation of MPLS over Layer-2 Tunneling Protocol Version 3", Work in Progress, February 2006.
[MPLS-in-L2TPV3] Townsley、M.、et al。、「レイヤー-2トンネルプロトコルバージョン3を介したMPLSのカプセル化」、2006年2月、作業進行中。
[BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
Authors' Addresses
著者のアドレス
Jeremy De Clercq Alcatel Copernicuslaan 50, 2018 Antwerpen, Belgium
Jeremy de Clercq Alcatel Copernicuslaan 50、2018 Antwerpen、ベルギー
EMail: jeremy.de_clercq@alcatel.be
Dirk Ooms OneSparrow Belegstraat 13, 2018 Antwerpen, Belgium
Dirk Ooms OnesParrow Belegstraat 13、2018 Antwerpen、ベルギー
EMail: dirk@onesparrow.com
Marco Carugi Nortel Networks S.A. Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT 78928 YVELINES Cedex 9 - France
Marco Carugi Nortel Networks S.A. Parc d'magny -les Jeunes Bois Chateaufort 78928 Yvelines Cedex 9-フランス
EMail: marco.carugi@nortel.com
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis France
Francois Le Faucheur Cisco Systems、Inc。Village D'Entreprise Green Side -Batiment T3 400、Avenue de Roumanille 06410 Biot -Sophia Antipolis France
EMail: flefauch@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。