メインコンテンツまでスキップ

RFC 4659 - IPv6 VPN のための BGP-MPLS IP 仮想プライベートネットワーク (VPN) 拡張

  • ステータス: 標準化提案
  • 発行日: 2006年9月
  • ストリーム: IETF
  • 正誤表: 正誤表なし

文書情報​

  • RFC 番号: 4659
  • タイトル: IPv6 VPN のための BGP-MPLS IP 仮想プライベートネットワーク (VPN) 拡張
  • 著者: J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur
  • 日付: 2006年9月
  • カテゴリ: 標準化過程
  • ISSN: 2070-1721

要旨​

この文書は, サービスプロバイダがパケット交換バックボーンを使用して IPv6 顧客に仮想プライベートネットワーク (VPN) サービスを提供する方法を説明する. この方法は, IPv6 をサポートするために"BGP/MPLS IP VPN"方式を再利用し, 必要に応じて拡張する. BGP/MPLS IP VPN では, サービスプロバイダのバックボーン上で IPv4 VPN ルートを配布するために Multiprotocol BGP を使用し, バックボーン上で IPv4 VPN パケットを転送するために MPLS を使用する. 本文書は IPv6 VPN アドレスファミリを定義し, Multiprotocol BGP による対応する IPv6 VPN ルート配布を説明する. また, IPv4 と IPv6 の双方のバックボーン上で IPv6 VPN サービスをサポートし, コアで MPLS, IP-in-IP, Generic Routing Encapsulation (GRE), IPsec 保護トンネルなどの各種トンネル技術を使用する方法を定義する. IPv4 サイトと IPv6 サイトの相互接続は本文書の範囲外である.

このメモの位置付け​

この文書はインターネットコミュニティのためのインターネット標準追跡プロトコルを指定し,改善のための議論と提案を要請しています.このプロトコルの標準化状態と状態については,現在の"インターネット公式プロトコル標準" (STD 1) を参照してください.このメモの配布は制限ありません.

著作権表示​

著作権 (C) インターネット社会 (2006).

目次​

1. はじめに​

この文書は,サービスプロバイダが,IPv6顧客に仮想プライベートネットワークサービスを提供するために,そのパケットスイッチのバックボーンを使用できる方法を説明します.

この方法は, IPv6 をサポートするために [BGP/MPLS-VPN] の方式を再利用し, 必要に応じて拡張する. 特に, 顧客エッジルーター (CE ルーター) が IPv6 ルートをサービスプロバイダのエッジルーター (PE ルーター) に送信する, [BGP/MPLS-VPN] と同じピアモデルを使用する. サービスプロバイダは BGP (Border Gateway Protocol, [BGP, BGP-MP]) を使用し, ある IPv6 VPN に接続された PE ルーター間でその VPN のルートを交換する. 最終的に PE ルーターは, 同じ VPN 内の他の CE ルーターから受け取った IPv6 ルートを各 CE ルーターへ配布する. IPv4 VPN と同様, このピアモデルでは IPv6 VPN 内の CE ルーター同士はピアリングせず, VPN のルーティングアルゴリズムから見えるオーバーレイは存在しない.

この文書は [BGP/MPLS-VPN] で記述されている定義,縮写,およびメカニズムを採用している. 異論が明示されていない限り, [BGP/MPLS-VPN] のメカニズムは適用され,ここで再定義されません.

VPNは,このVPNの各サイトが IPv6 対応で,プロバイダーエッジデバイス (PE) を介して IPv6 インターフェースまたはサブインターフェイスでサービスプロバイダー (SP) のバックボーンに接続された場合, IPv6 VPN と呼ばれる.

サイトは,IPv4対応とIPv6対応の両方である可能性があります. パケットがPEに到着する論理インターフェースはIPバージョンを決定することができます.代替的に,IPv4とIPv6の両方に対して同じ論理インターフェイスを使用することができます.この場合,IPパケットヘッダのバージョンフィールドでパケットごとに検索することでIPバージョンが決定されます.

この文書は,IPv6対応サイトに位置するIPv6ホスト間のIPv6通信の処理のみに関与している.IPv4対応サイトに位置するIPv4ホスト間のIPv4通信の処理は,この文書の範囲外にあり,BGP/MPLS-VPNでカバーされている.IPv4対応サイトに位置するIPv4ホストとIPv6対応サイトに位置するIPv6ホスト間の通信は,この文書の範囲外にある. [BGP/MPLS-VPN]

[BGP/MPLS-VPN]ではIPv4 VPNルートが分布する方法と同様に,BGPとその拡張子は,IPv6 VPNサイトから同じIPv6 VPNのサイトに接続された他のすべてのPEルーターへのルートを配布するために使用されます.PEsは"VPNルーティングおよび転送テーブル" (VRF) を使用して,各IPv6 VPNのアクセス可能性情報と転送情報を別々に保持します.

IPv4 VPN [BGP/MPLS-VPN]では,各 IPv6 VPN が独自の IPv6 アドレススペースを持つように許可します.つまり,特定のアドレスが異なる VPN の異なるシステムを表す可能性があります.これは,新しいアドレスファミリー,VPN-IPv6 アドレスファミリー,で達成されます. [BGP/MPLS-VPN]

MPLS Label Switched Paths (LSP) で運用するほか,GREトンネル,IP-in-IPトンネル [2547-GRE/IP],L2TPv3トンネル [MPLS-in-L2TPv3],IPsec保護トンネル [2547-IPsec]を含む他のトンネル技術での運用を可能にするため,IPv4 BGP/MPLS VPNソリューションが拡張された.同様の方法で,この文書はMPLS LSP,および他のトンネル技術上のIPv6 VPNサービスのサポートを可能にする.

この文書は,IPv4のバックボーン,およびIPv6のバックボーン上でIPv6 VPNサービスをサポートすることを許可します.サポートされているIPv6 VPNサービスは両方の場合同じです.

この文書で定義された IPv6 VPN ソリューションは以下の利点を提供します.

  • サービスプロバイダーと顧客の両方の観点から,IPv6サイトでサポートできるVPNサービスは,IPv4サイトでサポートできるものと同一です.

  • サービスプロバイダーの観点から,IPv6 VPNサービスの運用は,IPv4 VPNサービスと同じスキル,手順,メカニズムを必要とします.

  • IPv4 VPNと IPv6 VPN サービスの両方が IPv4 カーーンでサポートされている場合,同じMP-BGP ピアリング関係セットと同じPE-PE トンネルマッシュが両方に使用される可能 (MAY)性があります.

  • IPv6 VPN サービスは,コアが IPv4 または IPv6 で実行されているかどうかにかかわらず独立します.これは, IPv4 から IPv6 にコアが移行される前におよび後にサポートされている IPv6 VPN サービスが VPN 顧客にとって区別できないようにするためです.

IPv6 カーンの上で IPv4 VPN サービスをサポートすることは,この文書に含まれていないことに注意してください.

2. VPN-IPv6 アドレスファミリ​

BGP マルチプロトコル エクステンションは,BGP に複数の"アドレスファミリー"からのルートを運ぶことを可能にします. [BGP-MP] で導入されたVPN-IPv4アドレスファミリーに類似する"VPN-IPv6アドレスファミリー"という概念を導入します. [BGP/MPLS-VPN]

VPN-IPv6アドレスは,8オクトの"ルート識別子" (RD) から始まり,16オクトのIPv6アドレスで終了する24オクトの量です.

RDの目的は,共通のIPv6アドレスプレフィックスへの異なるルートを作成することを可能にするのみである.これは [BGP/MPLS-VPN]で定義された RDの目的に類似している.BGP/MPLS-VPNによって可能であるように, RDは同一システムへの複数の異なるルートを作成するために使用できます.これは,同じIPv6部分が異なる RDを持つ異なる2つの異なるVPN-IPv6ルートを作成することによって達成できます.これはプロバイダーのBGPが同一システムへの複数の異なるルートをインストールし,どのパケットがどのルートを使用するか決定するためにポリシーを使用することを可能にします. [BGP/MPLS-VPN]

また,二つのVPNが同じIPv6アドレスプレフィックスを使用すると (効果的に異なる物理システムを表示すると) ,PEsはそれらを異なる RDを使用してユニークなVPN-IPv6アドレスプレフィックスに翻訳します.これは同じアドレスが2つの異なるVPNで使用されている場合,そのアドレスに完全に異なる2つのルート,それぞれVPNに1つをインストールすることが可能であることを保証します.

VPN-IPv6アドレスと IPv6アドレスが異なるアドレスファミリーに属しているため,BGPは決してそれらを比較アドレスとして扱わない.

VRF には,単一の IPv6 アドレスプレフィックスに対して複数の同一コストのVPN-IPv6ルートが含まれる場合があります.パケットの目的地アドレスが VPN-IPv6ルートに対して VRF で一致する場合は,IPv6 部分のみが一致します.

ルーツディスタングシージャーのフォーマットとコーディングは [BGP/MPLS-VPN] で指定されている.

サイトがIPv4対応とIPv6対応の場合,同じRDはIPv6アドレスとIPv4アドレスの広告に使用され得る.代替的に,別のRDはIPv4アドレスとIPv6アドレスの広告に使用される.しかし,この仕様の範囲では,IPv4アドレスとIPv6アドレスは常に別々の文脈で扱われ,IPv4-IPv6相互作業の問題や技術について議論されないことに注意してください. (MAY) (MAY)

3. VPN-IPv6 経路配布​

3.1. BGP による PE 間の経路配布​

[BGP/MPLS-VPN]で説明したように,VPNの2つのサイトが同じ自治システムにあるPEsに接続されている場合,PEsはVPNルートを相互に (IPv4) 内的なボーダーゲートウェイプロトコル (iBGP) 接続を通じて配布することができます (MAY).代替的に,各PEには路線反射器へのiBGP接続が可能である.同様に,IPv6VPNルート配分のために,PEsはIPvGP接続を使用して,IPv6VPNの間でiBGP接続を使用することができます.IPv6VPNでは,iBGP接続はIPv4またはIPv6以上である可能性があります.

PE ルータは,IPv6 VPNのIPv6前置物へのアクセス可能性情報をMP-BGP [BGP-MP]を通じて交換し,それによってBGP Next Hopとして自らを発表します.

入手可能性情報とBGP Next Hopアドレスを暗号化するための規則は,次のセクションで規定されています.

3.2. VPN IPv6 NLRI の符号化​

IPv6 VPNルートを配布する際,広告 PEルーターはIPv6 VPNルートとMPLSラベルを割り当て,配布しなければならない (MUST).本質的に,PEルーターはIPv6 VPNルートを配布するのではなく,ラベル付きIPv6 VPNルート [MPLS-BGP]を配布する.広告 PEが特定の広告ラベルを持つパケットを受け取ると,PEはMPLSスタックからこのラベルをポップしてパケットを適切に処理します (すなわち,ラベルに従って直接転送するか,対応するIPv6-VPNコンテキストで検索を実行します).

BGP Multiprotocol Extensions [BGP-MP] は, MP_REACH のネットワーク層到達可能性情報 (NLRI) で IPv6 VPN ルートを広告するために使用される. Address Family Identifier (AFI) および Subsequent Address Family Identifier (SAFI) フィールドは, 次のように設定しなければならない (MUST):

  • AFI: 2; IPv6 用

  • SAFI: 128; MPLS ラベル付き VPN-IPv6 用

NLRIフィールド自体は [MPLS-BGP] で指定されているようにコードされています.この拡張の文脈では,プレフィックスはVPN-IPv6 アドレスファミリーに属しており,したがって8オクテットルート識別子に続いて上記2節で指定された IPv6プレフィックスで構成されています.

3.2.1. BGP Next Hop の符号化​

BGP Next Hop のエンコーディングは,BGP スピーカーの方針は,IPv6 トラフィックが IPv6 トンネル ("IPv6 トラフィックを要求するBGP スピーカー") または IPv4 トンネル ("IPv4 トラフィックを要求するBGP スピーカー") を使用して,BGP Next Hop に転送されることを要求することか否かに依存する.

このポリシー (IPv4トンネルまたはIPv6トンネル上で輸送を要求する) の定義は,ネットワークオペレーターの責任であり,この文書の範囲を超えています.BGPスピーカーがIPv6 (respond IPv4) でIPv6 VPNアクセス可能性情報を交換する間に,このポリシーがIPv4 (respond IPv6) トンネル上で輸送を要求することが可能であることを注意してください.しかし,その場合,いくつかの運用的影響を検討する必要があります.特に,IPv4 (respond IPv4) に影響する検出されていない故障 (respond IPv4) は,IPv4 (respond IPv4) に影響する. IPv6 (IPv4) のデータパスを影響しないため,BGPが検出されないままに,トラフィックがブラックホールになる可能性があります.

このポリシーを制御することは,この文書の範囲を超えており,ユーザの設定に基づいて行うことができます.

3.2.1.1. IPv6 トランスポートを要求する BGP スピーカー​

IPv6 VPN トラフィックが IPv6 トンネル (例えば IPv6 MPLS LSP,IPsec 保護された IPv6 トンネル) を利用して BGP スピーカーに輸送される場合,BGP スピーカーは VPN-IPv6 アドレスを含むNext Hop Network アドレスフィールドを広告します (SHALL)

  • 8オクト RDがゼロに設定され,

  • 16 octet IPv6 アドレスが広告 BGP スピーカーのグローバル IPv6 アドレスに設定されている.

これは別のVPN-IPv6アドレスが続く可能性があります

  • 8オクト RDがゼロに設定され,

  • 16 octet IPv6 アドレスが広告 BGP スピーカーのリンクローカル IPv6 アドレスに設定されている.

MP_REACH_NLRI属性におけるNext Hopネットワークアドレスフィールドの長さの値は,グローバルアドレスのみが存在する場合,24と,Next Hopフィールドにリンクローカルアドレスも含まれている場合,48に設定されます.

BGP スピーカーがリンクローカルIPv6アドレスのみを使用している場合 (例えば,IPv6 CEがIPv6 PEとピアしている場合,CEがIPv6グローバルアドレスを持っていない場合,およびeBGPピアリングがリンクローカルアドレスで達成されている場合),広告 BGP スピーカーが"未指定アドレス" ([V6ADDR]) を使用してNext Hop Network AddressフィールドでグローバルIPv6アドレスがないことを示します.

リンクローカルアドレスがNext Hopフィールドに記載される場合,広告 BGP スピーカーが [BGP-IPv6] に通路を広告している同級者と共有している場合のみ.

他のすべての場合,BGPスピーカーは,Next Hop Network Addressフィールドの同級者に,次のホップのグローバル IPv6 アドレスをのみ広告する.

その結果,内部ピアへのルートを広告するBGPスピーカーは,次のホップのリンクローカルIPv6アドレスを削除することによって,次のホップのネットワークアドレスフィールドを変更することができます.

BGP Next Hop アドレスフィールドにグローバルIPv6アドレスとリンクローカルIPv6アドレスの両方を含まれている例シナリオは,IPv6VPNサービスは,ラベル付きVPNの再分配による多自動システム (AS) のバックドーンでサポートされている場合です.

共通のIPv6サブネットを共有する異なるASESの自治システム境界ルーター (ASBR) の間のIPv6ルート:その場合,ASBRは,グローバルIPv6アドレスとリンクローカルIPv6アドレスの両方を広告します.

3.2.1.2. IPv4 トランスポートを要求する BGP スピーカー​

IPv6 VPN トラフィックが IPv4 トンネル (例えば IPv4 MPLS LSP,IPsec 保護された IPv4 トンネル) を利用して BGP スピーカーに輸送される場合,BGP スピーカーは VPN-IPv6 アドレスを含むNext Hop Network Address フィールドを同級者に広告します. (SHALL)

  • 8オクト RDがゼロに設定され,

  • 16 octet IPv6 アドレスが広告 BGP スピーカーの IPv4 アドレスを含む IPv4 マップされた IPv6 アドレス [V6ADDR] としてコードされている.この IPv4 アドレスは他の BGP スピーカーでルーテブルである必要があります.

3.3. Route Target​

ルートターゲットの使用は [BGP/MPLS-VPN] で指定され,IPv6 VPN に適用されます.拡張コミュニティ属性のエンコードは [BGP-EXTCOM] で定義されています.

3.4. BGP Capability ネゴシエーション​

2つのPEsがIPv6 VPN NLRIを交換するには,両社がこれらのNLRIを適切に処理できるかどうか確認するために,BGP Capabilities Negotiationを使用しなければならない (MUST).これは,上記 3.2. セクションで指定された AFI と SAFI 値を持つ能力コード 1 (マルチプロトコル BGP) を使用して, [BGP-MP] と [BGP-CAP] で指定されているように行われる.

4. カプセル化​

入力 PE ルータは,対応する目的地 IPv6 VPN 前兆のために BGP Next Hop と識別された Egress PE ルータに向かって,脊椎上のIPv6 VPN データをトンネルする必要があります (MUST).

BGP Next Hop フィールドに含まれる16オクトのIPv6アドレスが IPv4 マップされたIPv6アドレスとしてコード化される場合 (セクション3.2.1.2を参照) 入力 PE は,明示的に他の方法で構成されていない限り,IPv4トンネルを使用しなければならない (MUST). 入力 PE は,明示的な設定を通じて,BGP Next Hop フィールドに含まれる16オクトのIPv6アドレスが IPv4 マップされたIPv6アドレスとしてコード化される場合,明示的にIPv6トンネルの使用を許可することができます (MAY). これは,IPv6トンネルを望んだ特定の展開環境のサポートを可能にするが,IPv4地図化されたIPv6アドレスがグローバルIPv6アドレスではなく,PEsのIPv6アクセス可能性のために使用される場合.

BGP Next Hop フィールドに含まれる16オクトのIPv6アドレスがIPv4マッピングアドレスとしてコード化されていない場合 (セクション 3.2.1.1を参照) 入力 PEはIPv6トンネルを使用しなければならない (MUST).

PEが CE 付属された CE からパケットを受け取ると,その CE に対応する VRF でパケットの IPv6 宛先アドレスを検索します.これにより,VPN-IPv6 経路を見つけることができます.VPN-IPv6 経路には MPLS ラベルと関連 BGP Next Hop が付属します.まず,この MPLS ラベルは,下端ラベルとしてパケットに押されます.その後,このラベル付きパケットは,BGP Next Hop によって識別された出口への輸送のためにトンネルに封装されます.この封装の詳細は,実際のトンネル技術に依存します.

IPv4 VPN [2547-GRE/IP] の MPLS/BGP のように,トンネルを IPv4 トンネルまたは IPv6 トンネル (対応 IPv4 GRE トンネルまたは IPv6 GRE トンネル) でトンネル化を行うとき,ラベル付き IPv6 VPN パケットのエンカプセル化により, [MPLS-in-IP/GRE] で指定されたMPLS-in-IP (対応 MPLS-in-GRE) のエンカプセル化パケットが生成されます. L2TPv3 を使用したトンネル化を行うとき,ラベル付き IPv6 VPN パケットのエンカプセル化により, MPLS-in-L2TPv3 で指定された MPLS-in-L2TPv3 のエンカプセル化パケットが生成されます. [MPLS-in-L2TPv3]

IPv4 VPNのMPLS/BGPと同様に,IPsecセキュアトンネル [2547-IPsec]を使用してトンネルを掘り起こすと,ラベル付きのIPV6 VPNパケットの封装はMPLS-in-IPまたはMPLS-in-GRE封装されたパケット [MPLS-in-IP/GRE]を生成する.IPsec輸送モードは,このIPV4またはGREトンネルをPE入力からPE出口まで保護するために使用されます.

IPv4トンネル (IPsecがセキュアであれ否であれ) を使用してトンネルを掘り起こるとき,Ingress PE Routerは,BGP 次のホップフィールドの IPv4 マップされた IPv6 アドレスフィールドにコードされている IPv4 アドレスを,前付いた IPv4トンネルヘッダの目的地アドレスとして使用する必要があります (MUST).前付いた IPv4トンネルヘッダのソースアドレスとして,そのIPv4 アドレスの1つを使用します.

IPv6トンネル (IPsecがセキュアであれ否であれ) を使用してトンネルを掘り起こるとき,Ingress PE Router は,BGP 次のホップフィールドの IPv6 アドレスフィールドに含まれる IPv6 アドレスを,前付いた IPv6トンネルヘッダの目的地アドレスとして使用する必要があります (MUST).前付いた IPv6トンネルヘッダのソースアドレスとして,その IPv6 アドレスの1つを使用します.

MPLS LSPを使用してトンネルを掘り起こるとき,LSPは,任意のラベル配分技術 (LDP [LDP],RSVP-TE [RSVP-TE],など) を使用して確立することができます.

MPLS LSP を使用してトンネルを掘り起こるとき,入場PEルーターは,ラベル付きのIPv6 VPN パケットのラベルスタックに直接LSPトンネルラベルを押さなければなりません (つまり,IPv4またはIPv6ヘッダを前もって押さずに).この押されたラベルは入場PEルーターから開始して出口PEルーターに終了するLSPに対応します.BGP Next Hopフィールドは出口PEルーターを識別するために使用され,その代わりにスタックに押されるラベルです. BGP Next Hop フィールドの IPv6 アドレスが IPv4 マップされた IPv6 アドレスである場合,埋め込まれた IPv4 アドレスがラベルスタックに押すトンネルラベルを決定します.他の場合,BGP Next Hop フィールドの IPv6 アドレスがラベルスタックに押すトンネルラベルを決定します. (MUST)

このVPNアーキテクチャを実装するシステム間の相互運用性を確保するために,これらのシステムすべてがLDP [LDP]によって確立されたMPLS LSPを使用してトンネルをサポートしなければならない (MUST).

5. アドレスタイプ​

リンクローカルユニキャストアドレスが単一のリンクでの使用のために定義されているため, PE-CEリンクで使用することができますが,IPv6 VPN サイトでアクセス可能性のためにサポートされていません.そして,遠隔の PE にMultiProtocol-Border Gateway Protocol (MP-BGP) を介して広告されません.

グローバルユニキャストアドレスは,IPv6インターネットのどこでもユニークな識別インターフェースとして定義されています.グローバルアドレスはIPv6 VPNサイト内およびその中で一般的に使用されるものと予想されています. IPv6 VPNサイト全体でアクセス可能性のために,明らかにこのIPv6 VPNソリューションによってサポートされ,MP-BGPを通じて遠隔PEsに広告され,グローバル範囲に特別な考慮なしに処理されます.

[UNIQUE-LOCAL]から引用する:"この文書は,グローバルにユニークで,ローカル通信のために意図されたIPv6ユニキャストアドレスフォーマットを定義している.これらのアドレスには,Unique Local IPv6 Unicast Addressesと呼ばれ,この文書ではローカル 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."

この規定に従って,この文書で指定された IPv6 VPN ソリューションにより,Unique Local IPv6 Unicast Address がサポートされています.したがって,そのようなUnique Local IPv6 Address のアクセス可能性はMP-BGP 経由で遠隔の PEs に広告され, Global Unicast アドレスと同様に PEs によって処理されます.

サポートされているアドレスタイプのうち,特定の IPv6 VPN環境でどのアドレスタイプを使用すべきかに関する勧告と考慮は,この文書の範囲を超えています.

6. マルチキャスト​

マルチキャスト操作は,この文書の範囲外です.

7. Carriers' Carrier​

IPv6 VPNは,IPv6 ISPのネットワークであり,独自のピアリング・ルーティングポリシーを持つ場合もある.時には,IPv6 VPNは,IPv6サービスを顧客に提供しているSPのネットワークである場合もある.このようなIPv6 VPNは,IPv6トラフィックに適用されるIPv6トラフィックに適用されるBGP/MPLS-VPNの第9節で説明されているキャリアのキャリアの方法を使用して,別のSPから"キャリアのキャリア"からバックボーンサービスを入手することもできる. IPv4 VPNキャリアのキャリアについて [BGP/MPLS-VPN] で議論されたすべての考慮事項は IPv6 VPNに適用される. [BGP/MPLS-VPN]

8. マルチ AS バックボーン​

[BGP/MPLS-VPN]第10節に記載されている同じ手順が,IPv6 VPNの2つのサイトが異なる自治システムに接続されている状況に対処するために使用され (同等のスケーラビリティ性がある).しかし,いくつかの追加点を注意する必要があります

IPv6 VPN においてこれらの手順を適用する際には,このセクションの残りの部分で詳細に説明されています.

方法 (a):AS (自動システム) 国境ルーターにおけるVRFからVRF接続

このアプローチは,IPv6 VPN に対して[BGP/MPLS-VPN]第10節の手順 (a) に相当する.IPv6 VPN の場合,IPv6 はASBR間のVRF-to-VRF (サブ) インターフェースでアクティブ化する必要があります (MUST).このアプローチでは,ASBRはIPv6ルート交換 (VPN-IPv6ルートとは異なり) し,IPv6またはIPv4上でピアリングを行うことができます.IPv6ルート交換は[BGP-IPv6]に従って行う必要があります.この方法は,AS間のLSPを使用しません.

最後に,この手順で,各ASが本文書で説明されているIPv6VPNの内部AS手順を独立に実装しているため,参加するASはすべて内部でIPv4トンネルまたはIPv6トンネルを使用する場合,または他の参加するASは内部でIPv4トンネルを使用する場合,他のASはIPv6トンネルを使用する場合,

方法 (b): EBGP レーベル付きの VPN-IPv6 ルートのASから隣接するASへの再分配.

このアプローチは,IPv6 VPNでは[BGP/MPLS-VPN]第10節の手順 (b) に相当する.このアプローチでは,ASBRは EBGPを使用して,他のASESのASBRにラベル付きのVPN-IPv4ルートを再配布します.

この方法では, VPN-IPv6 ルートを交換する ASBR は IPv4 または IPv6 上でピアリングできるため, ASBR 間リンクで IPv6 を有効にしてもしなくてもよい (IPv6 上でピアリングする場合は, ASBR 間リンクで IPv6 を有効にする必要がある). ラベル付き VPN-IPv6 ルートの交換は [BGP-IPv6] および [MPLS-BGP] に従って実行しなければならない (MUST). VPN-IPv6 トラフィックを IPv6 トンネルで転送する場合, BGP Next Hop フィールドは IPv6 アドレスを含まなければならない (SHALL). IPv4 トンネルで転送する場合, BGP Next Hop フィールドは IPv4-mapped IPv6 address として符号化された IPv4 アドレスを含まなければならない (SHALL).

このアプローチはAS間LSPの存在を要求する.したがって,BGP/MPLS-VPNの第10節 (b) の手順 (セキュリティ) に記述された対応する (セキュリティ) 考慮事項は,IPv6に対するこのアプローチに適用される. [BGP/MPLS-VPN]

最後に,この手順と同様に,手順 (a) においても,この文書で説明されているIPv6 VPNの内部AS手順を各ASが独立して実施しているため,参加するASはすべて内部でIPv4トンネルまたはIPv6トンネルを使用することが可能であることを注意してください.

方法 (c):ソースと目的 ASsの間にラベル付き VPN-IPv6 ルートの Multihop EBGP 再配分,ASから隣接するASにラベル付き IPv4または IPv6 ルートの EBGP 再配分.

このアプローチは,VPN-IPv6ルート交換に対して, [BGP/MPLS-VPN]第10節の手順 (c) に相当する.

このアプローチでは,参加するASは全て IPv4トンネルを使用するか,すべて IPv6トンネルを使用することを要求します.

このアプローチでは,VPN-IPv6ルートがASBRルーターによって維持されず,配布されることもありません.ASBRルーターはダブルスタックである必要はありません.ASBRは,ASAS内のPEルーターへのラベル付き IPv4 (または IPv6) ルートを維持する必要があります.このルートを他のASに配布するためにEBGPを使用します.いかなるトランジットASESでもASBRは,ラベル付き IPv4 (または IPv6) ルートに沿って EBGP を使用する必要があります.これは,入力 PEルーターから出出口 PEルーターまでの IPv4 (または IPv6) ラベルスイッチパスを作成します. 現在,異なる ASESのPEルーターは,IPv4またはIPv6で複数のホップ EBGP接続を相互に確立し,それらのEBGP接続でラベル付きのVPN-IPv6ルート交換することができます.これらの分散型VPN-IPv6ルートのBGP Next HopフィールドはIPv6トンネルを使用する場合IPv6アドレスまたはIPv4トンネルを使用する場合IPv4地図化されたIPv6アドレスを含むことに注意してください.

[BGP/MPLS-VPN]の第10節の手順 (c) に記載されている考慮事項は,ルート反射器の使用の可能性,第三のラベルの使用の可能性,および複数の ASsをカバーする LSPに関して,この IPv6 VPNアプローチに適用されます.

9. VPN からのインターネットアクセス​

IPv4 VPNからグローバルIPv4インターネットにアクセスするためにBGP/MPLS-VPNが提案した方法は,IPv6VPNとグローバルIPv6インターネットの文脈で使用できます.しかし,IPv6VPNサイトからIPv6パケットがIPv6インターネットに目的としている場合は,SPバックドーンを通過する必要があります.そして,これはIPv4のみバックドーンである場合は,これらのパケットはIPv4バックドーンを通過する必要があります. [BGP/MPLS-VPN]

明らかに,VPNの文脈の外では, IPv6 VPNからIPv6インターネットへのアクセスには,グローバルIPv6アドレスを使用する必要があります.

特に,IPv6インターネットアクセスには,Unique Local IPv6 アドレスが使用できない.

10. 管理 VPN​

[BGP/MPLS-VPN]の第12節に議論されている管理上の考察は,IPv6 VPNの管理に適用されます.

サービスプロバイダがIPv6 VPNサイトのCEを管理する場合には,サービスプロバイダは管理ツールとCE間の通信のためにIPv4を使用することを選択することができます.その場合,顧客IPv4サイトが実際にCEに接続されているかどうかに関係なく (IPv6サイトに加えて),CEはIPv6VPNに属するだけでなく,IPv4VPNの一部である (すなわち,CEはIPv6に加えて IPv4をサポートするVRFに接続されている). [BGP/MPLS-VPN]で提示された,管理ツールが複数のVPNから管理されたこれらのCEと通信できるようにするための検討は,CEが接続するVRFのIPv4アクセス可能性に適用される.

サービスプロバイダがIPv6VPNサイトのCEを管理する場合には,サービスプロバイダは管理ツールとCE間の通信のためにIPv6を使用することを選択することができる.管理ツールが複数のVPNから管理されたCEと通信できるようにするための方法について,CEが接続するVRFのIPv6アクセス可能性に適用される. [BGP/MPLS-VPN]

11. セキュリティに関する考慮事項​

この文書で定義された拡張は,MP-BGP が IPv6 VPN ルートに関するアクセス可能性情報を広めるようにします.

BGP を使用した IPv6 アクセス可能性情報の輸送のためのセキュリティ上の考慮事項は,RFC2545 第5節で議論されており,同文書で説明されている拡張に適用されます.

この文書で説明されている IPv6 VPN を提供するための拡張は, [BGP/MPLS-VPN] で説明されているアプローチと同じアプローチを使用している.したがって,データプランセキュリティ,コントロールプランセキュリティ,および [BGP/MPLS-VPN] 第13節で説明されているPEおよびPデバイスセキュリティに関して,同じセキュリティ考慮事項が適用されます.

12. サービス品質​

[BGP/MPLS-VPN]の第14節で議論されている IPv4 VPNのQoSメカニズムはすべて IPv4と IPv6 (Diffserv, Intserv, MPLS Traffic Engineering) に同じ方法で動作しているため, [BGP/MPLS-VPN]で議論されているQoS考慮事項は IPv6 VPNにも同様に適用されます (これは, IPv4トンネルまたは IPv6トンネルが脊髄で使用されているかどうかにも当てはまります).

13. スケーラビリティ​

[BGP/MPLS-VPN]の第15節でIPv4 VPNについて概要されているスケーラビリティの考慮事項は,IPv6 VPNにも同様に適用されます.

14. IANA に関する考慮事項​

この文書では,この文書で定義されている"VPN-IPv6 ラベル付きアドレス"アドレスファミリーを表すために,BGP AFI (アドレスファミリー識別子) 値2とBGP SAFI (後続アドレスファミリー識別子) 値128の使用を指定します.

IPv6 に対する AFI 値 2 の使用は,現在 IANA レジストリ"アドレスファミリー識別子"で指定されているため,IANA はそれに関していかなる措置も講じない.

"MPLSラベル付きのVPNアドレス"のSAFI値128の使用は,現在,IANA登録"後続アドレスファミリー識別子"で指定されているため,IANAはそれに関していかなる措置も講じない.

15. 謝辞​

この文書に貢献したジェラルド・ガスタウとエリック・レヴィ・アベグノリに感謝します

追悼​

筆者は,この文書にTri T. Nguyenが,突然の病気で2002年4月に亡くなった貴重な貢献を認識したい.

16. 参考文献​

16.1. 規範的参考文献​

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

  • [BGP-EXTCOM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.

  • [BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

  • [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

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

  • [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.

  • [LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.

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

16.2. 参考情報​

  • [V6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

  • [UNIQUE-LOCAL] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.

  • [2547-GRE/IP] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547 VPNs", Work in Progress.

  • [2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use of PE-PE IPsec in RFC2547 VPNs", Work in Progress, August 2005.

  • [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.

  • [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-L2TPv3] Townsley, M., et al., "Encapsulation of MPLS over Layer-2 Tunneling Protocol Version 3", Work in Progress, February 2006.

  • [BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

著者の連絡先​

Jeremy De Clercq
Alcatel
Copernicuslaan 50, 2018 Antwerpen, Belgium

EMail: [email protected]

Dirk Ooms
OneSparrow
Belegstraat 13, 2018 Antwerpen, Belgium

EMail: [email protected]

Marco Carugi
Nortel Networks S.A.
Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT
78928 YVELINES Cedex 9 - France

EMail: [email protected]

Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot-Sophia Antipolis
France

EMail: [email protected]

完全な著作権表示​

著作権 (C) インターネット社会 (2006).

この文書は,BCP 78に含まれる権利,ライセンスおよび制限の対象であり,その文書に規定されている場合を除き,著者はすべての権利を維持します.

本文書と,本文書に含まれる情報は"AS IS"の基礎で提供され,この文書の提供者,その代理人または支援者 (もしそうなら) の組織,インターネット社会およびインターネットエンジニアリングタスクフォースは,この文書の利用が,いかなる権利やいかなる利益や利益の保証も侵害しないという保証を含む,またはその保証に限定されないすべての保証を断言します.

知的財産​

IETFは,本文書で記述された技術の実装または使用に関連していると主張される知的財産権またはその他の権利の有効性または範囲に関する立場を立たない.また,そのような権利に基づくライセンスが利用可能または利用可能でない程度については,そのような権利を特定するために独立した努力をしたとは言っていない.RFC文書における権利に関する手続きに関する情報は,BCP 78およびBCP 79で確認できます.

IETF事務局に IPRの公開のコピーを,利用可能となるライセンスに関する保証や,この仕様の実施者または利用者によるそのような所有権の行使のための一般ライセンスまたは許可を取得しようとする結果を,IETFのオンラインIPRレポジトリ http://www.ietf.org/iprで入手できます.

IETFは,この規格の実施に必要な技術に関する著作権,特許,特許申請,その他の所有権について,関心のある方々にご注意を喚起するよう要請します.

謝辞​

RFC エディタ機能の資金提供は,IETFの行政支援活動 (IASA) によって提供されます.

に最終更新