RFC4659 日本語訳
4659 BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN.J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur. September 2006. (Format: TXT=42090 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
De Clercqがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4659年のアルカテルカテゴリ: 規格はF.Le Faucheurシスコシステムズ2006年9月にD.オームスOneSparrow M.Carugiノーテルネットワークを追跡します。
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN
IPv6 VPNのためのBGP-MPLS 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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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".
このドキュメントはService ProviderがIPv6顧客のために兵士のNetwork(VPN)サービスをVirtualに供給するのにパケットで切り換えられたバックボーンを使用するかもしれないメソッドを説明します。 このメソッドが再利用する、必要であるところに広がっている、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バックボーンでありMPLSを含んでいて、コアの上で様々なトンネリングのテクニックを使用するために、IPにおけるIP、Genericルート設定Encapsulation(GRE)、およびIPsecは保護しました。このドキュメントがサポートのIPv6 VPNサービスオーバーの両方を定義する、トンネル。 このドキュメントの範囲の外にIPv4サイトとIPv6サイトの間の織り込むことがあります。
De Clercq, et al. Standards Track [Page 1] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[1ページ]。
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
1. 序論…2 2. VPN-IPv6はファミリーに演説します…4 3. VPN-IPv6は分配を発送します…5 3.1. BGPは分配をPEsに発送してください…5 3.2. VPN IPv6 NLRIコード化…6 3.2.1. BGP Next Hopコード化…6 3.2.1.1. IPv6輸送を要求するBGP議長…7 3.2.1.2. IPv4輸送を要求するBGP議長…8 3.3. 目標を発送してください…8 3.4. BGP能力交渉…8 4. カプセル化…8 5. タイプに演説してください…10 6. マルチキャスト…11 7. キャリアズキャリア…11 8. マルチ、バックボーン…11 9. VPNからインターネットにアクセスします…13 10. 管理VPN…14 11. セキュリティ問題…14 12. サービスの品質…15 13. スケーラビリティ…15 14. IANA問題…15 15. 承認…15 16. 参照…16 16.1. 標準の参照…16 16.2. 有益な参照…16
1. Introduction
1. 序論
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.
このドキュメントはService ProviderがIPv6顧客のために兵士のNetworkサービスをVirtualに供給するのにパケットで切り換えられたバックボーンを使用するかもしれないメソッドを説明します。
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]。 特に、このメソッドは顧客の縁のルータ(「CEルータ」)がService Providerの縁のルータ(「PEルータ」)にそれらのIPv6ルートを送る[BGP/MPLS-VPN]と同じ「同輩モデル」を使用します。 そして、BGP(「ボーダ・ゲイトウェイ・プロトコル」、[BGP、BGP-MP])は、そのIPv6 VPNに付けられているPEルータの中で特定のIPv6 VPNのルートを交換するのにService Providerによって使用されます。 結局、PEルータはそのVPNの他のCEルータから特定のVPNのCEルータにIPv6ルートを分配します。 IPv4 VPNsのように、この「同輩モデル」の主要な特性は(IPv6)VPNの中の(IPv6)CEルータが互いと共にじっと見ないということです。 (IPv6)VPNのルーティング・アルゴリズムに目に見えるどんな「オーバレイ」もありません。
De Clercq, et al. Standards Track [Page 2] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[2ページ]。
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であり、IPv6インタフェースの上で関連しているかService Provider(SP)バックボーンへのProvider Edgeデバイス(PE)を通したサブインタフェースのネイティブであることの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パケットのヘッダーのバージョン分野の1パケットあたり1つのルックアップが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.
同じようにIPv4 VPNルートが[BGP/MPLS-VPN]でどう分配されるかに、BGPとその拡張子は、IPv6 VPNサイトから同じIPv6 VPNのサイトに関連づけられた他のすべてのPEルータまでルートを分配するのに使用されます。 PEsは、別々に可到達性情報とそれぞれのIPv6 VPNの推進情報を保守するのに、「VPNルート設定とForwardingテーブル」(VRFs)を使用します。
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アドレス空間を持たせます。(それは、与えられたアドレスが異なったVPNsの異系統を指示するかもしれないことを意味します)。 これは新しいアドレスファミリーを通して達成されます、VPN-IPv6 Address Family、[BGP/MPLS-VPN]で定義されたIPへのRoute Distinguisherがそれのprependsを扱うVPN-IPv4アドレスファミリーのものと同様のファッションで。
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 Label Switched Paths(LSPs)の上の操作に加えて、他のトンネリングのテクニックの上の操作を許すためにIPv4 BGP/MPLS VPNソリューションを広げてあります、GREトンネルを含んでいて、IPにおけるIPトンネル[2547-GRE/IP]、L2TPv3トンネル[L2TPv3のMPLS]、そして、IPsecはトンネル[2547-IPsec]を保護しました。 同じように、このドキュメントは他のトンネリングのテクニックと同じくらい良いIPv6 VPNサービスオーバーMPLS LSPsのサポートを許します。
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.
このドキュメントはIPv6バックボーンと同じくらい良いIPv4バックボーンをIPv6 VPNサービスオーバーのサポートに許容します。 サービスがサポートしたIPv6 VPNはどちらの場合も、同じです。
De Clercq, et al. Standards Track [Page 3] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[3ページ]。
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 Service Provider見解と顧客見解の両方から、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 Service Provider見解から、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 VPNsとIPv6 VPNサービスの両方がIPv4コアの上でサポートされるところでは、関係と同じ単一のPE-PEトンネルが網の目にかけるMP-BGPのじっと見ることの同じただ一つのセットは両方に使用されるかもしれません。
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 コアがIPv4かIPv6を実行するかどうかからIPv6 VPNサービスは独立しています。 これは、VPN顧客にとって、コアの移行の前後にIPv4からIPv6までサポートされたIPv6 VPNサービスが「非-区別可能」なためのそうです。
Note that supporting IPv4 VPN services over an IPv6 core is not covered by this document.
IPv6コアの上のサービスをIPv4 VPNにサポートするのがこのドキュメントでカバーされていないことに注意してください。
2. The VPN-IPv6 Address Family
2. VPN-IPv6アドレスファミリー
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 Multiprotocol Extensions[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八重奏の「ルートDistinguisher」(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の目的は1つが一般的なIPv6アドレス接頭語に異なったルートを作成するのを唯一許容することです。(接頭語は[BGP/MPLS-VPN]で定義されたRDの目的と同様です)。 同様に、それが[BGP/MPLS-VPN]単位で可能であるので、複数の異なったルートを全く同じシステムに作成するのにRDを使用できます。 同じIPv6部分の、しかし、異なったRDsを持っている2つの異なったVPN-IPv6ルートを作成することによって、これを達成できます。 これは、プロバイダーのBGPが複数の異なったルートを同じシステムにインストールするのを許容して、方針がどのパケットがどのルートを使用するかを決めるのに使用されるのを許容します。
De Clercq, et al. Standards Track [Page 4] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[4ページ]。
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.
また、2VPNsが同じIPv6アドレス接頭語を使用するなら(事実上、異なった物理的なシステムを指示して)、PEsは、異なったRDsを使用することでユニークなVPN-IPv6アドレス接頭語にこれらを翻訳するでしょうに。 これは、そのアドレス(各VPNあたり1つ)に2つの完全に異なったルートをインストールするために同じアドレスが今までに2異なったVPNsで使用されるなら、可能であることを確実にします。
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ルートがあるかもしれません。 パケットの送付先アドレスがVRFでVPN-IPv6ルートに取り組まされるとき、IPv6部分だけが実際に合わせられています。
The Route Distinguisher format and encoding is as specified in [BGP/MPLS-VPN].
Route Distinguisher形式とコード化が[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できて、同じRD MAYであるときには、IPv6アドレスとIPv4アドレスの広告に使用されてください。 あるいはまた、異なったRD MAY、IPv4アドレスとIPv6アドレスの広告には、使用されてください。 しかしながら、IPv4アドレスとIPv6アドレスが別々の関係でこの仕様の範囲では、いつも扱われて、問題とテクニックを織り込むIPv4-IPv6について全く議論しないことに注意してください。
3. VPN-IPv6 Route Distribution
3. VPN-IPv6ルート分配
3.1. Route Distribution Among PEs by BGP
3.1. BGPによるPEsの中のルート分配
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つのサイトが同じAutonomous SystemにあるPEsに付くなら、PEsはそれらの間の(IPv4)内部のボーダ・ゲイトウェイ・プロトコル(iBGP)接続によってVPNルートを互いに分配できます。 あるいはまた、各PEは反射鏡を発送するiBGP接続を持つことができます。 同様に、PEsはIPv6 VPNルート分配に、彼らの間でiBGP接続を使用するか、またはルート反射鏡にiBGP接続を使用できます。 IPv6 VPNに関しては、IPv4の上、または、IPv6の上にiBGP接続があるかもしれません。
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]、BGP Next HopがIPv6としてIPv6 VPNsに前に置いて、その結果、自分たちで発表するような可到達性情報を通したPEルータ交換。
The rules for encoding the reachability information and the BGP Next Hop address are specified in the following sections.
可到達性情報とBGP Next Hopアドレスをコード化するための規則は以下のセクションで指定されます。
De Clercq, et al. Standards Track [Page 5] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[5ページ]。
3.2. VPN IPv6 NLRI Encoding
3.2. VPN IPv6 NLRIコード化
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ルータは、IPv6 VPNルートがあるMPLSラベルを割り当てて、分配しなければなりません。 本質的には、PEルータはIPv6 VPNルートではなく、Labeled 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 Multiprotocol Extensions[BGP-MP]は、MP_REACH Network Layer Reachability情報(NLRI)にIPv6 VPNルートの広告を出すのに使用されます。 以下の通りAddress Family Identifier(AFI)とSubsequent Address Family Identifier(サフィ)分野を設定しなければなりません:
- AFI: 2; for IPv6
- AFI: 2; IPv6のために
- SAFI: 128; for MPLS labeled VPN-IPv6
- サフィ: 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 Address Familyに属して、その結果、上のセクション2の指定されるとしてのIPv6接頭語があとに続いた8八重奏のRoute Distinguisherから成ります。
3.2.1. BGP Next Hop encoding
3.2.1. BGP Next Hopコード化
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のコード化はIPv6 VPNトラフィックが(「IPv6輸送を要求するBGPスピーカー」)にトンネルを堀りながらIPv6を使用するか、または(「IPv4輸送を要求するBGPスピーカー」)にトンネルを堀りながらIPv4を使用することでそのBGP Next Hopに輸送されるよう要求するかどうかにBGPスピーカーの方針がことであるよります。
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トンネリングの上の輸送を要求する)の定義は、ネットワーク・オペレータの責任であり、このドキュメントの範囲を超えています。 その方針がIPv4の上の輸送を要求するのが、可能であることに注意してください。(resp。 IPv6) BGPスピーカーがIPv6 VPN可到達性情報をIPv6の上と交換している間、トンネルを堀ること。(resp。 IPv4). しかしながら、その場合、多くの操作上の含意は考える価値があります。 特にIPv4に影響する非検出された欠点(resp。 IPv6) データ経路にトンネルを堀って、IPv6に影響しません。(resp。 IPv4) データ経路はBGPで非検出されていたままで残ることができました。(順番に、BGPはトラフィックの黒い穴をもたらすかもしれません)。
Control of this policy is beyond the scope of this document and may be based on user configuration.
この方針のコントロールは、このドキュメントの範囲を超えていて、ユーザ構成に基づくかもしれません。
De Clercq, et al. Standards Track [Page 6] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[6ページ]。
3.2.1.1. BGP Speaker Requesting IPv6 Transport
3.2.1.1. IPv6輸送を要求するBGP議長
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 LSPs、IPsecによって保護されたIPv6はトンネルを堀ります)ことであるときに、BGPスピーカーSHALLはVPN-IPv6アドレスを含むNext Hop Network Address分野の広告を出します。
- whose 8-octet RD is set to zero, and
- そしてRDがゼロに合わせるように8八重奏に用意ができている。
- whose 16-octet IPv6 address is set to the global IPv6 address of
the advertising BGP speaker.
- 16八重奏のIPv6アドレスは広告BGPスピーカーのグローバルなIPv6アドレスに設定されます。
This is potentially followed by another VPN-IPv6 address
別のVPN-IPv6アドレスは潜在的にこれのあとに続いています。
- whose 8-octet RD is set to zero, and
- そしてRDがゼロに合わせるように8八重奏に用意ができている。
- whose 16-octet IPv6 address is set to the link-local IPv6
address of the advertising BGP speaker.
- 16八重奏のIPv6アドレスは広告BGPスピーカーのリンクローカルの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.
グローバルアドレスだけが存在していて、48に設定されるとき、また、Next Hop分野に含まれていて、リンクローカルアドレスが設定されるなら、MP_REACH_NLRI属性における、Next Hop Network Address分野のLengthの値は24に設定されるものとします。
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スピーカーがリンク地元のIPv6アドレス(例えばIPv6 CEがCEには少しのIPv6グローバルアドレスもなくて、eBGPのじっと見ることがリンクローカルのアドレスの上で達成されるIPv6 PEと共にじっと見る場合で)だけを使用することでじっと見るなら、「不特定のアドレス」([V6ADDR])は、Next Hop Network Address分野でのグローバルなIPv6アドレスの欠如を示すのに広告BGPスピーカーによって使用されます。
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].
そして、リンクローカルアドレスがNext Hop分野に含まれているものとする、広告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だけが扱う次のホップのNext Hop Network Address野原の中の同輩に広告を出すものとします。
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スピーカーは、次のホップのリンクローカルのIPv6アドレスを取り除くことによって、Next Hop分野のNetwork Addressを変更するかもしれません。
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アドレスとリンクのローカルのIPv6アドレスの両方がBGP Next Hopアドレス・フィールドに含まれているものとする例のシナリオはIPv6 VPNサービスがマルチAutonomous System(AS)バックボーンの上で再分配でどこでサポートされるかがVPNをラベルしたということです。
De Clercq, et al. Standards Track [Page 7] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[7ページ]。
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は異なったASes共有のAutonomous System Border Routers(ASBR)の間で一般的なIPv6サブネットを発送します: その場合、グローバルなIPv6アドレスとリンクローカルのIPv6アドレスの両方がASBRsによって広告を出されるものとします。
3.2.1.2. BGP Speaker Requesting IPv4 Transport
3.2.1.2. IPv4輸送を要求するBGP議長
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トンネリングを使用することでBGPスピーカーに輸送される(例えば、IPv4 MPLS LSPs、IPsecによって保護されたIPv4はトンネルを堀ります)ことであるときに、BGPスピーカーSHALLはVPN-IPv6アドレスを含むNext Hop Network Address分野の同輩に広告を出します:
- whose 8-octet RD is set to zero, and
- そしてRDがゼロに合わせるように8八重奏に用意ができている。
- 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.
- 広告BGPスピーカーのIPv4アドレスを含んでいて、16八重奏のIPv6アドレスはIPv4によって写像されたIPv6アドレス[V6ADDR]としてコード化されます。 このIPv4アドレスはもう片方のBGP議長で発送可能であるに違いありません。
3.3. Route Target
3.3. ルート目標
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]で定義されます。
3.4. BGP Capability Negotiation
3.4. BGP能力交渉
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.
2PEsにおいてIPv6 VPN NLRIsとラベルされた交換に整然とします、彼らは彼らの両方が適切にそのようなNLRIsを処理できるのを保証するのにBGP Capabilities Negotiationを使用しなければなりません。 [BGP-MP]と[BGP-CAP]で指定されるようにこれをします、能力コード1(multiprotocol BGP)を使用することによって、上で指定されるとしてのAFIとサフィ値で、セクション3.2で。
4. Encapsulation
4. カプセル化
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.
イングレスPE Routerはバックボーンの上で対応する目的地IPv6 VPN接頭語のためのBGP Next Hopとして特定されたEgress PEルータに向かってIPv6 VPNデータにトンネルを堀らなければなりません。
De Clercq, et al. Standards Track [Page 8] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[8ページ]。
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.
セクション3.2を見てください。IPv6アドレスがBGP Next Hop分野に保管していた16八重奏がIPv4によって写像されたIPv6アドレスとしてコード化される、(.1 .2)、イングレスPE MUSTは別の方法でするために明らかに構成されない場合トンネルを堀りながら、IPv4を使用します。 IPv4がIPv6アドレスを写像したのでIPv6アドレスがBGP Next Hop分野に保管していた16八重奏がコード化されるとき、イングレスPE MAYは明白な構成を通して任意にIPv6トンネリングの使用を許します。 これは、IPv6トンネリングが望まれていますが、IPv4によって写像されたIPv6アドレスが起こる特定の展開環境のサポートがGlobal 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.
セクション3.2を見てください。IPv6アドレスがBGP Next Hop分野に保管していた16八重奏がIPv4によって写像されたアドレスとしてコード化されない、(.1 .1)、イングレスPE MUSTはトンネルを堀りながら、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 Next Hopがあるでしょう。 まず最初に、この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トンネルを使用し終わっているか、そして、IPv6がトンネルを堀るのでIPv4 VPNs[2547-GRE/IP]のためのMPLS/BGPと共に(resp。 IPv4 GREトンネルかIPv6 GREトンネル), IPにおけるMPLSのラベルされたIPv6 VPNパケット結果のカプセル化(resp。 GREのMPLS) [IPにおけるMPLS/GRE]の指定されるとしてのパケットであるとカプセル化されます。 トンネリングがL2TPv3を使用し終わっていると、ラベルされたIPv6 VPNパケットのカプセル化は中のMPLS L2TPv3によってカプセル化されたパケットをもたらします、[L2TPv3のMPLS]で指定されるように。
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.
トンネリングがトンネル[2547-IPsec]であることが固定されたIPsecを使用し終わっていると、ラベルされたIPv6 VPNパケットのカプセル化がIPv4 VPNsのためのMPLS/BGPのように中のMPLS IPをもたらす、-、または、カプセル化されたGREのMPLSパケット[IPにおけるMPLS/GRE]。 IPsec Transport Modeは、イングレスPEから出口PEまでこのIPv4かGREトンネルを固定するのに使用されます。
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 Routerは目的地としての次のホップ分野が扱うprepended IPv4トンネリングヘッダーのBGPのIPv4によって写像されたIPv6アドレス・フィールドでコード化されるIPv4アドレスを使用しなければなりません。 それはprepended IPv4トンネリングヘッダーのソースアドレスとしてIPv4アドレスの1つを使用します。
De Clercq, et al. Standards Track [Page 9] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[9ページ]。
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 Routerは目的地としての次のホップ分野が扱うprepended IPv6トンネリングヘッダーのBGPのIPv6アドレス・フィールドに保管されているIPv6アドレスを使用しなければなりません。 それはprepended IPv6トンネリングヘッダーのソースアドレスとしてIPv6アドレスの1つを使用します。
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 LSPsを使用し終わっていると、どんなラベル分配技法(自由民主党[自由民主党]、RSVP-TE[RSVP-TE]など)も使用することでLSPsを設立できます。
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 LSPsを使用し終わっていると、イングレスPE Routerは直接ラベルされたIPv6 VPNパケット(すなわち、どんなIPv4やIPv6ヘッダーもprependingすることのない)のラベルスタックにLSPトンネルラベルを押さなければなりません。 この押されたラベルはイングレスPE Routerを始動して、出口PE Routerで終わるLSPに対応しています。 BGP Next Hop分野は順番に出口PEルータを特定するのが使用されます。スタックに押されるべきラベル。 BGP Next Hop分野の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がアーキテクチャであると実装するシステムの中で相互運用性を確実にするために、自由民主党[自由民主党]によって設立されたMPLS LSPsを使用して、そのようなすべてのシステムがトンネリングをサポートしなければなりません。
5. Address Types
5. アドレスタイプ
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.
Linkローカルのユニキャストアドレスが単一のリンクだけにおける使用のために定義されるので、ものがPE-CEリンクの上に使用されるかもしれませんが、それらを可到達性のためにIPv6 VPN Sitesの向こう側にサポートしないで、またリモートPEsへのMultiProtocol-ボーダ・ゲイトウェイ・プロトコル(MP-BGP)で決して広告を出しません。
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 Sites以内とIPv6 VPN Sitesの向こう側にグローバルなアドレスによって一般的に使用されると予想されます。 それらは、可到達性のためにIPv6 VPN Sitesの向こう側にこのIPv6 VPNソリューションによって明らかにサポートされて、MP-BGPを通してリモートPEsに広告を出して、少しも特定の問題なしで自己のグローバルな範囲に処理されます。
De Clercq, et al. Standards Track [Page 10] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[10ページ]。
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 IPv6 Unicast Addressesと呼ばれて、本書ではLocal 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."
また、[UNIQUE-LOCAL]はセクション4.7で言います: 「適切なルートがセットアップされるなら、相互サイトVirtual兵士のNetworks(VPN)にローカルのIPv6アドレスを使用できます。」 アドレスがユニークであるので、これらのVPNsは確かと翻訳の必要性なしで働くでしょう。 「彼らには、個々のサイトが番号を付け替えられるか、または合併されているなら、働き続けている追加特性があります。」
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.
これに従って、Unique Local IPv6 Unicast AddressesはIPv6 VPN Sitesの向こう側に本書では可到達性に指定されたIPv6 VPNソリューションによってサポートされます。 したがって、そのようなUnique Local IPv6 Addressesへの可到達性は、リモートPEsへのMP-BGPを通して広告を出して、Global Unicastアドレスと同様に、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環境で使用されるべきであるか推薦と問題はこのドキュメントの範囲を超えています。
6. Multicast
6. マルチキャスト
Multicast operations are outside the scope of this document.
このドキュメントの範囲の外にマルチキャスト操作があります。
7. Carriers' Carriers
7. キャリアズキャリア
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は実際にそれ自身のじっと見るのとルーティング方針があるIPv6ISPのネットワークであるかもしれません。 それ自身の顧客にとって時々、IPv6 VPNは順番にサービスをVPNに提供しているSPのネットワークであるかもしれません。 また、別のSP、「キャリヤーのキャリヤー」からこれらのようなIPv6 VPNsはバックボーンサービスを得ることができます、[BGP/MPLS-VPN]のセクション9で説明されますが、IPv6トラフィックに適用されたCarriersのCarrierメソッドを使用して。 IPv4 VPN CarriersのCarrierのために[BGP/MPLS-VPN]で議論したすべての問題がIPv6 VPNに申し込みます、PEとCEの間のMPLS(ラベル分配を含んでいる)の使用がIPv4ルートの代わりにIPv6ルートに関係させる例外で。
8. Multi-AS Backbones
8. マルチ、バックボーン
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
IPv6 VPNの2つのサイトが異なったAutonomous Systemsにつなげられる状況を扱うのに[BGP/MPLS-VPN]のセクション10で説明された同じ手順は用いることができます(同じスケーラビリティの特性を持ってください)。しかしながら、追加数ポイントは注意されるべきです。
De Clercq, et al. Standards Track [Page 11] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[11ページ]。
when applying these procedures for IPv6 VPNs; these are further described in the remainder of this section.
IPv6 VPNsのためにこれらの手順を適用するとき。 これらはこのセクションの残りでさらに説明されます。
Approach (a): VRF-to-VRF connections at the AS (Autonomous System) border routers.
アプローチ(a): VRFからVRFとのAS(自治のSystem)での接続はルータに接しています。
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の手順(a)へのIPv6 VPNsのための同等物です。 IPv6 VPNsの場合では、IPv6は、相互ASBR VRFからVRFへの(潜水艦)インタフェースで動かされる必要があります。 このアプローチでは、ASBRsはIPv6ルート(VPN-IPv6ルートと対照的に)を交換して、IPv6の上、または、IPv4の上をじっと見るかもしれません。 [BGP-IPv6]に従ってIPv6ルートの交換を行わなければなりません。 このメソッドは相互AS LSPsを使用しません。
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.
最終的に、あらゆるASが本書では説明されたIPv6 VPNsのために独自にイントラ-AS手順を実装するのでこの手順で、参加しているASesがすべて、内部的にIPv4トンネリング、またはIPv6トンネリングを使用するかもしれないことに注意してください。 または、あるいはまた、他のものがIPv6トンネリングを使用している間、いくつかの参加ASesが内部的にIPv4トンネリングを使用するかもしれません。
Approach (b): EBGP redistribution of labeled VPN-IPv6 routes from AS to neighboring AS.
アプローチ(b): ラベルされたVPN-IPv6ルートのASによる隣接する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の手順(b)へのIPv6 VPNsのための同等物です。 このアプローチと共に、ASBRsは、ラベルされたVPN-IPv4ルートを他のASesのASBRsに再配付するのにEBGPを使用します。
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リンクの上に動くかもしれません。 [BGP-IPv6]と[MPLS-BGP]に従ってラベルされたVPN-IPv6ルートの交換を行わなければなりません。 VPN-IPv6トラフィックがIPv6トンネリングを使用することで輸送されることであるときに、BGP Next Hop Field SHALLはIPv6アドレスを含んでいます。 VPN-IPv6トラフィックがIPv4トンネリングを使用することで輸送されることであるときに、BGP Next Hop Field SHALLはIPv4によって写像された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.
このアプローチはそこでそれを必要とします。相互AS LSPsになってください。 そういうものとして、[BGP/MPLS-VPN]のセクション10の手順(b)のために説明された対応する(セキュリティ)問題は等しくIPv6のためのこのアプローチに適用されます。
De Clercq, et al. Standards Track [Page 12] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[12ページ]。
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.
最終的に、あらゆるASが本書では説明されたIPv6 VPNsのために独自にイントラ-AS手順を実装するのでこの手順で、参加しているASesがすべて、手順(a)なら、内部的にIPv4トンネリングかIPv6トンネリングを使用するかもしれないことに注意してください。 あるいはまた、他のものがIPv6トンネリングを使用している間、いくつかの参加ASesが内部的にIPv4トンネリングを使用するかもしれません。
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): ラベルされたVPN-IPv6のマルチホップEBGP再分配はソースと目的地の間でASesを発送します、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-IPv6ルートの交換に、このアプローチはVPN- IPv4ルートの交換のために[BGP/MPLS-VPN]のセクション10の手順(c)に同等です。
This approach requires that the participating ASes either all use IPv4 tunneling or all use IPv6 tunneling.
このアプローチは、参加しているASesがすべて、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の中でラベルされたIPv4(または、IPv6)ルートをPEルータに維持する必要があります。 それは、他のASesにこれらのルートを分配するのにEBGPを使用します。 また、どんなトランジットASesにおけるASBRsも、ラベルされたIPv4(または、IPv6)ルートを回すのにEBGPを使用しなければならないでしょう。 これはイングレスPEルータから出口PEルータまでのIPv4(または、IPv6)ラベルスイッチ経路の作成をもたらします。 今、異なったASesのPEルータは、IPv4かIPv6の上でマルチホップEBGP接続を互いに確立できて、それらのEBGP接続の上とラベルされたVPN-IPv6ルートを交換できます。 IPv4トンネリングが使用されているとき、IPv6トンネリングが使用されていてIPv4によって写像されたIPv6アドレスであるときに、これらの分配されたVPN-IPv6ルートのBGP Next Hop分野が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番目のラベルの活用可能性、および倍数にかかるLSPsに関して、ASesは等しくこのIPv6 VPNアプローチに適用します。
9. Accessing the Internet from a VPN
9. 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.
IPv6 VPNsの文脈とグローバルなIPv6インターネットでIPv4 VPNからグローバルなIPv4インターネットにアクセスする[BGP/MPLS-VPN]によって提案されたメソッドは使用できます。 しかしながら、サイトであってSPバックボーン、およびそれを横断するグローバルなIPv6インターネットの必要性のために運命づけられたIPv6 VPNからのIPv6パケットであるならこれが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アドレスの使用を必要とします。
De Clercq, et al. Standards Track [Page 13] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[13ページ]。
In particular, Unique Local IPv6 addresses cannot be used for IPv6 Internet access.
特に、IPv6インターネット・アクセスにUnique Local IPv6アドレスを使用できません。
10. Management VPN
10. 管理VPN
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.
Service ProviderがIPv6 VPNサイトのCEを管理するところでは、Service Providerは、管理ツールとそのような管理目的のためのCEとのコミュニケーションにIPv4を使用するのを選ぶかもしれません。 その場合、顧客IPv4サイトが実際にCE(IPv6サイトに加えた)につなげられるかどうかにかかわらず、事実上、CEはIPv6 VPNに属すことに加えたIPv4 VPNの一部(すなわち、CEはIPv6に加えてIPv4をサポートするVRFに取り付けられる)です。 [BGP/MPLS-VPN]に提示された管理ツールが複数のVPNsから異なったVPNsのCEsの向こう側に望まれない可到達性を許容しないでそのような管理されたCEsとコミュニケートできるのをどう保証するかに関する問題はCEが付くVRFのIPv4の可到達性に適切です。
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.
Service ProviderがIPv6 VPNサイトのCEを管理するところでは、Service Providerは、管理ツールとそのような管理目的のためのCEとのコミュニケーションにIPv6を使用するのを選ぶかもしれません。 [BGP/MPLS-VPN]に提示された管理ツールが複数のVPNsから異なったVPNsのCEsの向こう側に望まれない可到達性を許容しないでそのような管理されたCEsとコミュニケートできるのをどう保証するかに関する問題はその時、CEが付くVRFのIPv6の可到達性に適切です。
11. Security Considerations
11. セキュリティ問題
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.
本書ではIPv6 VPNsを提供するために説明された拡大は[BGP/MPLS-VPN]で説明されたアプローチと全く同じアプローチを使用します。 そういうものとして、同じセキュリティ問題は[BGP/MPLS-VPN](セクション13)で説明されるようにあいさつでData Planeセキュリティ、Control Planeセキュリティ、PE、およびPデバイスセキュリティに適用されます。
De Clercq, et al. Standards Track [Page 14] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[14ページ]。
12. Quality of Service
12. サービスの質
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 VPNsのために議論したすべてのQoSメカニズムがIPv4とIPv6(Diffserv、Intserv、MPLS Traffic Engineering)のために同様に動作するので、[BGP/MPLS-VPN]で議論したQoS問題は等しくIPv6 VPNsに適切です。(IPv4トンネリングかIPv6トンネリングがバックボーンに使用されるか否かに関係なく、これは成立します。)
13. Scalability
13. スケーラビリティ
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 VPNsのためにまとめられたそれぞれのスケーラビリティ問題は等しくIPv6 VPNsに適切です。
14. IANA Considerations
14. IANA問題
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.
このドキュメントは、アドレスファミリー本書では定義される「アドレスとラベルされたVPN-IPv6」を表すためにBGP SAFI(その後のAddress Family Identifier)値128に伴うBGP AFI(アドレスFamily Identifier)価値2の使用を指定します(セクション3.2を見ます)。
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.
AFI価値2のIPv6の使用が同じくらい現在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.
サフィ価値128の「MPLSによってラベルされたVPNアドレス」の使用が同じくらい現在IANA登録「続きアドレスファミリー識別子」で指定されるので、IANAはそれに関して少しの行動も取る必要はありません。
15. Acknowledgements
15. 承認
We would like to thank Gerard Gastaud and Eric Levy-Abegnoli, who contributed to this document.
ジェラードGastaudとエリックLevy-Abegnoliに感謝申し上げます。(Levy-Abegnoliはこのドキュメントに貢献しました)。
In Memoriam
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からのこのドキュメントへの有価約因を承諾したがっています。
De Clercq, et al. Standards Track [Page 15] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[15ページ]。
16. References
16. 参照
16.1. Normative References
16.1. 引用規格
[BGP/MPLS-VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4364, February 2006.
[BGP/MPLS-VPN]ローゼンとE.とY.Rekhter、「BGP/MPLS IP仮想私設網(VPNs)」、RFC4364 2006年2月。
[BGP-EXTCOM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP
Extended Communities Attribute", RFC 4360, February
2006.
[BGP-EXTCOM] サーングリとS.とタッパン、D.とY.Rekhter、「BGPは共同体属性を広げた」RFC4360、2006年2月。
[BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June
2000.
[BGP-MP]ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.キャッツ、「BGP-4インチのためのMultiprotocol拡張子、RFC2858、2000年6月。」
[IPv6] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460, December
1998.
[IPv6]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[MPLS-BGP] Rekhter, Y. and E. Rosen, "Carrying Label
Information in BGP-4", RFC 3107, May 2001.
「BGP-4インチ、RFC3107、2001年5月にラベル情報を運ぶ」[MPLS-BGP]Rekhter、Y.、およびE.ローゼン。
[BGP-CAP] Chandra, R. and J. Scudder, "Capabilities
Advertisement with BGP-4", RFC 3392, November 2002.
[BGP-上限] チャンドラとR.とJ.Scudder、「BGP-4インチがある能力広告、RFC3392、2002年11月。」
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette,
A., and B. Thomas, "LDP Specification", RFC 3036,
January 2001.
[自由民主党] アンデションとL.とDoolanとP.とフェルドマンとN.とFredette、A.とB.トーマス、「自由民主党仕様」、RFC3036、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]マルケスとP.とF.デュポン、「BGP-4 Multiprotocol拡張子のIPv6相互ドメインルート設定の使用」、RFC2545、1999年3月。
16.2. Informative References
16.2. 有益な参照
[V6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[V6ADDR] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
[UNIQUE-LOCAL] Hinden, R. and B. Haberman, "Unique Local IPv6
Unicast Addresses", RFC 4193, October 2005.
[ユニークに地方の] HindenとR.とB.ハーバーマン、「ユニークなローカルのIPv6ユニキャストアドレス」、RFC4193、2005年10月。
[2547-GRE/IP] Rekhter and Rosen, "Use of PE-PE GRE or IP in
RFC2547 VPNs", Work in Progress.
「RFC2547 VPNsのPE-PE GREかIPの使用」という[2547-GRE/IP]のRekhterとローゼンは進行中で働いています。
[2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use
of PE-PE IPsec in RFC2547 VPNs", Work in Progress,
August 2005.
[2547-IPsec] ローゼン、De Clercq、Paridaens、T'Joens、「RFC2547 VPNsにおけるPE-PE IPsecの使用」というSargorは進歩、2005年8月に働いています。
De Clercq, et al. Standards Track [Page 16] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[16ページ]。
[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.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、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.
[IPにおけるMPLS/GRE] オースター、T.、Rekhter、Y.、およびE.ローゼン、「IPか一般ルーティングのカプセル化(GRE)でMPLSをカプセル化します」、RFC4023(2005年3月)。
[MPLS-in-L2TPv3] Townsley, M., et al., "Encapsulation of MPLS over
Layer-2 Tunneling Protocol Version 3", Work in
Progress, February 2006.
[L2TPv3のMPLS] Townsley、M.、他、「プロトコルバージョンにトンネルを堀る層-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.、李、T.、およびS.野兎、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC4271 2006年1月。
Authors' Addresses
作者のアドレス
Jeremy De Clercq Alcatel Copernicuslaan 50, 2018 Antwerpen, Belgium
ジェレミーDe ClercqアルカテルCopernicuslaan50、2018アントウェルペン(ベルギー)
EMail: jeremy.de_clercq@alcatel.be
メール: jeremy.de_clercq@alcatel.be
Dirk Ooms OneSparrow Belegstraat 13, 2018 Antwerpen, Belgium
DirkオームスOneSparrow Belegstraat13、2018アントウェルペン(ベルギー)
EMail: dirk@onesparrow.com
メール: dirk@onesparrow.com
Marco Carugi Nortel Networks S.A. Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT 78928 YVELINES Cedex 9 - France
マルコCarugiノーテルNetworks S.A.Parc d'activites deマニー-レスJeunes Bois CHATEAUFORT78928イブリーヌCedex9--フランス
EMail: marco.carugi@nortel.com
メール: 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
フランソアLe FaucheurシスコシステムズInc.Village d'EntrepriseグリーンSide--Batiment T3 400、アベニューdeルーマニーユ06410・Biot-ソフィア・Antipolisフランス
EMail: flefauch@cisco.com
メール: flefauch@cisco.com
De Clercq, et al. Standards Track [Page 17] RFC 4659 BGP-MPLS IP VPN Extension for IPv6 VPN September 2006
De Clercq、他 規格は2006年9月にIPv6 VPNのためにRFC4659BGP-MPLS IP VPN拡張子を追跡します[17ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
De Clercq, et al. Standards Track [Page 18]
De Clercq、他 標準化過程[18ページ]
一覧
スポンサーリンク
