Network Working Group J. De Clercq
Request for Comments: 4798 Alcatel-Lucent
Category: Standards Track D. Ooms
OneSparrow
S. Prevost
BT
F. Le Faucheur
Cisco
February 2007
Connecting IPv6 Islands over IPv4 MPLS Using
IPv6 Provider Edge Routers (6PE)
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 IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document explains how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud. This approach relies on IPv6 Provider Edge routers (6PE), which are Dual Stack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 reachability information transparently over the core using the Multiprotocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration.
この文書では、IPv4クラウドを-enabledマルチプロトコルラベルスイッチング（MPLS）経由でIPv6の島を相互接続する方法について説明します。このアプローチは、IPv6島へとIPv4のみMPLSを実行するために必要とされるMPLSコアに接続するためにデュアルスタックされたIPv6プロバイダーエッジルータ（6PE）に依存しています。 6PEルータは、IPv4上マルチボーダーゲートウェイプロトコル（MP-BGP）を用いてコア上に透過IPv6の到達可能性情報を交換します。そうすることで、BGPネクストホップフィールドには、その動的に確立のIPv4シグナリングMPLSラベルは、明示的なトンネルの設定せずに使用することができるパス（LSPを）交換よう6PEルータのIPv4アドレスを伝えるために使用されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................4
2. Protocol Overview ...............................................4
3. Transport over IPv4-signaled LSPs and IPv6 Label Binding ........5
4. Crossing Multiple IPv4 Autonomous Systems .......................7
5. Security Considerations ........................................10
6. Acknowledgements ...............................................10
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
There are several approaches for providing IPv6 connectivity over an MPLS core network [RFC4029] including (i) requiring that MPLS networks support setting up IPv6-signaled Label Switched Paths (LSPs) and establish IPv6 connectivity by using those LSPs, (ii) use configured tunneling over IPv4-signaled LSPs, or (iii) use the IPv6 Provider Edge (6PE) approach defined in this document.
そこMPLSコアネットワーク上のIPv6接続性を提供するためのいくつかのアプローチ[RFC4029]を含む（I）MPLSネットワークがサポート設定のIPv6シグナリングラベルパスを交換することを必要とする（LSPは）であり、これらのLSPを使用してIPv6接続を確立し、（ii）の構成使用しますIPv4にシグナリングのLSP上トンネリング、または（III）本文書で定義されたIPv6プロバイダエッジ（6PE）アプローチを使用します。
The 6PE approach is required as an alternative to the use of standard tunnels. It provides a solution for an MPLS environment where all tunnels are established dynamically, thereby addressing environments where the effort to configure and maintain explicitly configured tunnels is not acceptable.
6PEアプローチは、標準的なトンネルの使用に代わるものとして必要とされます。これは、すべてのトンネルは、それによって明示的に設定トンネルを設定し、維持するための努力が許容できない環境に対処し、動的に確立されているMPLS環境のためのソリューションを提供します。
This document specifies operations of the 6PE approach for interconnection of IPv6 islands over an IPv4 MPLS cloud. The approach requires that the edge routers connected to IPv6 islands be Dual Stack Multiprotocol-BGP-speaking routers [RFC4760], while the core routers are only required to run IPv4 MPLS. The approach uses MP-BGP over IPv4, relies on identification of the 6PE routers by their IPv4 address, and uses IPv4-signaled MPLS LSPs that do not require any explicit tunnel configuration.
この文書では、IPv4 MPLSクラウド経由のIPv6島の相互接続のための6PEアプローチの動作を指定します。アプローチは、コアルータは、IPv4のみMPLSを実行するために必要されている間のIPv6アイランドに接続されたエッジルータは、デュアルスタックマルチ-BGP圏ルータ[RFC4760]であることを必要とします。アプローチは、IPv4上MP-BGPを使用し、そのIPv4アドレスによって6PEルータの識別に依存して、任意の明示的なトンネルの設定を必要としないのIPv4シグナリングMPLSのLSPを使用します。
Throughout this document, the terminology of [RFC2460] and [RFC4364] is used.
本明細書を通して、[RFC2460]及び[RFC4364]の用語が使用されます。
In this document an 'IPv6 island' is a network running native IPv6 as per [RFC2460]. A typical example of an IPv6 island would be a customer's IPv6 site connected via its IPv6 Customer Edge (CE) router to one (or more) Dual Stack Provider Edge router(s) of a Service Provider. These IPv6 Provider Edge routers (6PE) are connected to an IPv4 MPLS core network.
この文書では「IPv6の島は」[RFC2460]あたりとしてネイティブIPv6を実行しているネットワークです。 IPv6の島の典型的な例は、サービスプロバイダーの1つ（またはそれ以上）のデュアルスタックプロバイダーエッジルータ（複数可）にそののIPv6カスタマーエッジ（CE）ルータを経由して接続されて、顧客のIPv6サイトになります。これらのIPv6プロバイダーエッジルータ（6PE）のIPv4 MPLSコアネットワークに接続されています。
+--------+
|site A CE---+ +-----------------+
+--------+ | | | +--------+
6PE-+ IPv4 MPLS core +-6PE--CE site C |
+--------+ | | | +--------+
|site B CE---+ +-----------------+
+--------+
IPv6 islands IPv4 cloud IPv6 island
<-------------><---------------------><-------------->
Figure 1
図1
The interconnection method described in this document typically applies to an Internet Service Provider (ISP) that has an IPv4 MPLS network, that is familiar with BGP (possibly already offering BGP/MPLS VPN services), and that wants to offer IPv6 services to some of its customers. However, the ISP may not (yet) want to upgrade its network core to IPv6, nor use only IPv6-over-IPv4 tunneling. With the 6PE approach described here, the provider only has to upgrade some Provider Edge (PE) routers to Dual Stack operations so that they behave as 6PE routers (and route reflectors if those are used for the exchange of IPv6 reachability among 6PE routers) while leaving the IPv4 MPLS core routers untouched. These 6PE routers provide connectivity to IPv6 islands. They may also provide other services simultaneously (IPv4 connectivity, IPv4 L3VPN services, L2VPN services, etc.). Also with the 6PE approach, no tunnels need to be explicitly configured, and no IPv4 headers need to be inserted in front of the IPv6 packets between the customer and provider edge.
この文献に記載の相互接続方法は、典型的には、（おそらくすでにBGP / MPLS VPNサービスを提供）BGPに精通している、IPv4のMPLSネットワークを持っているインターネットサービスプロバイダ（ISP）に適用され、それが一部のへのIPv6サービスを提供したいと考えていその顧客。しかし、ISPは（まだ）IPv6へのネットワークコアをアップグレードしたい、また唯一のIPv6オーバーIPv4トンネリングを使用することはできません。 6PEアプローチはここで説明すると、プロバイダは、（それらが6PEルータ間のIPv6到達可能性の交換のために使用される場合とルートリフレクタ）は、6PEルータとして動作するようにデュアルスタック・オペレーションのいくつかのプロバイダエッジ（PE）ルータをアップグレードするために、一方を有します手つかずのIPv4 MPLSコア・ルータを残します。これらの6PEルータは、IPv6の島々への接続を提供します。彼らはまた、同時に（IPv4接続、IPv4のL3VPNサービス、L2VPNサービス、等）を他のサービスを提供してもよいです。また6PEアプローチで、何トンネルが明示的に設定する必要はなく、何のIPv4ヘッダは、顧客とプロバイダエッジとの間のIPv6パケットの前に挿入する必要はありません。
The ISP obtains IPv6 connectivity to its peers and upstreams using means outside of the scope of this document, and its 6PE routers readvertise it over the IPv4 MPLS core with MP-BGP.
ISPは、この文書の範囲外の手段を使用してピアとアップストリームにIPv6接続を取得し、その6PEルータはMP-BGPとのIPv4 MPLSコアの上にreadvertise。
The interface between the edge router of the IPv6 island (Customer Edge (CE) router) and the 6PE router is a native IPv6 interface which can be physical or logical. A routing protocol (IGP or EGP) may run between the CE router and the 6PE router for the distribution of IPv6 reachability information. Alternatively, static routes and/or a default route may be used on the 6PE router and the CE router to control reachability. An IPv6 island may connect to the provider network over more than one interface.
IPv6の島のエッジルータとの間のインターフェース（カスタマエッジ（CE）ルータ）と6PEルータが物理的または論理的であってもよいネイティブIPv6インタフェースです。ルーティングプロトコル（IGPまたはEGP）は、CEルータとIPv6到達可能性情報を配信する6PEルータ間で実行することができます。あるいは、静的ルートおよび/またはデフォルトルートは、到達可能性を制御する6PEルータとCEルータ上で使用することができます。 IPv6の島は、複数のインタフェースを介して、プロバイダネットワークに接続することができます。
The 6PE approach described in this document can be used for customers that already have an IPv4 service from the network provider and additionally require an IPv6 service, as well as for customers that require only IPv6 connectivity.
この文書に記載され6PEアプローチは既にネットワークプロバイダからのIPv4サービスを有し、さらにIPv6サービスを必要とする顧客のため、ならびにのみIPv6接続を必要とする顧客のために使用することができます。
The scenario is also described in [RFC4029].
シナリオはまた、[RFC4029]に記載されています。
Note that the 6PE approach specified in this document provides global IPv6 reachability. Support of IPv6 VPNs is not within the scope of this document and is addressed in [RFC4659].
この文書で指定6PEのアプローチは、グローバルIPv6到達可能性を提供することに注意してください。 IPv6のVPNのサポートは、この文書の範囲内ではないと[RFC4659]で扱われています。
Deployment of the 6PE approach over an existing IPv4 MPLS cloud does not require an introduction of new mechanisms in the core (other than potentially those described at the end of Section 3 for dealing with dynamic MTU discovery). Configuration and operations of the 6PE approach have a lot of similarities with the configuration and operations of an IPv4 VPN service ([RFC4364]) or IPv6 VPN service ([RFC4659]) over an IPv4 MPLS core because they all use MP-BGP to distribute non-IPv4 reachability information for transport over an IPv4 MPLS Core. However, the configuration and operations of the 6PE approach is somewhat simpler, since it does not involve all the VPN concepts such as Virtual Routing and Forwarding (VRFs) tables.
既存のIPv4 MPLSクラウド上6PEアプローチの展開は（動的MTU発見に対処するための第3節の最後で説明潜在以外の）コアに新しいメカニズムの導入を必要としません。それらはすべて配布するMP-BGPを使用するため6PEアプローチの構成および動作は、IPv4 MPLSコア上のIPv4 VPNサービス（[RFC4364]）またはIPv6 VPNサービス（[RFC4659]）の構成及び動作と多くの類似点を持っていますIPv4のMPLSコア上でのデータ転送を行う非IPv4の到達可能性情報。そのような仮想ルーティング及び転送（VRFの）テーブルなどのすべてのVPNの概念を伴わないので、6PEアプローチの構成および動作は、いくぶん簡単です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Each IPv6 site is connected to at least one Provider Edge router that is located on the border of the IPv4 MPLS cloud. We call such a router a 6PE router. The 6PE router MUST be dual stack IPv4 and IPv6. The 6PE router MUST be configured with at least one IPv4 address on the IPv4 side and at least one IPv6 address on the IPv6 side. The configured IPv4 address needs to be routable in the IPv4 cloud, and there needs to be a label bound via an IPv4 label distribution protocol to this IPv4 route.
各IPv6サイトは、IPv4 MPLSクラウドの境界に配置された少なくとも1つのプロバイダーエッジルータに接続されています。私たちは、6PEルータ、ルータを呼び出します。 6PEルータは、デュアルスタックIPv4およびIPv6でなければなりません。 6PEルータは、IPv4側に少なくとも1つのIPv4アドレスとIPv6側に少なくとも1つのIPv6アドレスを設定する必要があります。構成されたIPv4アドレスは、IPv4クラウドにルーティング可能である必要があり、このIPv4ルートへのIPv4ラベル配布プロトコルを介して結合した標識が必要です。
As a result of this, every considered 6PE router knows which MPLS label to use to send packets to any other 6PE router. Note that an MPLS network offering BGP/MPLS IP VPN services already fulfills these requirements.
その結果、すべての考慮さ6PEルータは、他の6PEルータにパケットを送信するために使用するMPLSラベルを知っています。 BGP / MPLS IP VPNサービスを提供するMPLSネットワークはすでにこれらの要件を満たしていることに注意してください。
No extra routes need to be injected in the IPv4 cloud.
余分なルートは、IPv4クラウドに注入する必要はありません。
We call the 6PE router receiving IPv6 packets from an IPv6 site an ingress 6PE router (relative to these IPv6 packets). We call a 6PE router forwarding IPv6 packets to an IPv6 site an egress 6PE router (relative to these IPv6 packets).
私たちは、IPv6のサイトから入口6PEルータ（これらのIPv6パケットに対して）IPv6パケットを受信6PEルータを呼び出します。私たちは、IPv6サイトへの出口6PEルータ（これらのIPv6パケットに対して）IPv6パケットを転送する6PEルータを呼び出します。
Interconnecting IPv6 islands over an IPv4 MPLS cloud takes place through the following steps:
IPv4のMPLSクラウド経由でIPv6の島を相互接続するには、次の手順で行われます。
1. Exchange IPv6 reachability information among 6PE routers with MP-BGP [RFC2545]:
MP-BGP [RFC2545]で6PEルータ間1.取引所のIPv6到達可能性情報：
The 6PE routers MUST exchange the IPv6 prefixes over MP-BGP sessions as per [RFC2545] running over IPv4. The MP-BGP Address Family Identifier (AFI) used MUST be IPv6 (value 2). In doing so, the 6PE routers convey their IPv4 address as the BGP Next Hop for the advertised IPv6 prefixes. The IPv4 address of the egress 6PE router MUST be encoded as an IPv4-mapped IPv6 address in the BGP Next Hop field. This encoding is consistent with the definition of an IPv4-mapped IPv6 address in [RFC4291] as an "address type used to represent the address of IPv4 nodes as IPv6 addresses". In addition, the 6PE MUST bind a label to the IPv6 prefix as per [RFC3107]. The Subsequence Address Family Identifier (SAFI) used in MP-BGP MUST be the "label" SAFI (value 4) as defined in [RFC3107]. Rationale for this and label allocation policies are discussed in Section 3.
6PEルータは、IPv4オーバー[RFC2545]ランニングに従ってMP-BGPセッション上のIPv6プレフィックスを交換しなければなりません。 MP-BGPファミリー識別子（AFI）をIPv6アドレス（値2）でなければならない使用。そうすることで、6PEルータはアドバタイズされたIPv6プレフィックスのBGPネクストホップとしてのIPv4アドレスを伝えます。出口6PEルータのIPv4アドレスは、BGPネクストホップフィールドにIPv4マップIPv6アドレスとして符号化されなければなりません。この符号化は、「IPv6アドレスとしてIPv4ノードのアドレスを表すために使用されるアドレスタイプ」として、[RFC4291]にIPv4射影IPv6アドレスの定義と一致しています。また、6PEは、[RFC3107]あたりとしてIPv6プレフィックスにラベルをバインドする必要があります。 [RFC3107]で定義されるようにMP-BGPに使用されるサブシーケンスアドレスファミリ識別子（SAFI）は、「ラベル」SAFI（値4）でなければなりません。このラベル割り当てポリシーの根拠は、第3節で議論されています。
2. Transport IPv6 packets from the ingress 6PE router to the egress 6PE router over IPv4-signaled LSPs:
IPv4の-合図のLSPオーバーの出口6PEルータへの入口6PEルータから2.交通IPv6パケット：
The ingress 6PE router MUST forward IPv6 data over the IPv4- signaled LSP towards the egress 6PE router identified by the IPv4 address advertised in the IPv4-mapped IPv6 address of the BGP Next Hop for the corresponding IPv6 prefix.
入口6PEルータはIPv4-上のIPv6データを転送しなければならない対応するIPv6プレフィックスのためのBGPネクストホップのIPv4射影IPv6アドレスでアドバタイズIPv4アドレスによって識別される出口6PEルータに向けてLSPを合図。
As required by the BGP specification [RFC4271], PE routers form a full peering mesh unless Route Reflectors are used.
BGP仕様[RFC4271]によって必要とされるルートリフレクタが使用されない限り、PEルータは、完全なピアメッシュを形成します。
In this approach, the IPv4-mapped IPv6 addresses allow a 6PE router that has to forward an IPv6 packet to automatically determine the IPv4-signaled LSP to use for a particular IPv6 destination by looking at the MP-BGP routing information.
このアプローチでは、IPv4マップIPv6アドレスを自動的にMP-BGPルーティング情報を見て、特定のIPv6宛先に使用するのIPv4-シグナリングLSPを決定するために、IPv6パケットを転送しなければならない6PEルータを可能にします。
The IPv4-signaled LSPs can be established using any existing technique for label setup [RFC3031] (LDP, RSVP-TE, etc.).
IPv4にシグナリングLSPはラベルセットアップ[RFC3031]（LDP、RSVP-TEなど）のための既存の技術を用いて確立することができます。
To ensure interoperability among systems that implement the 6PE approach described in this document, all such systems MUST support tunneling using IPv4-signaled MPLS LSPs established by LDP [RFC3036].
この文書に記載され6PEアプローチを実装するシステム間の相互運用性を確保するために、すべてのそのようなシステムは、LDP [RFC3036]によって確立されたIPv4-シグナリングMPLSのLSPを使用してトンネリングをサポートしなければなりません。
When tunneling IPv6 packets over the IPv4 MPLS backbone, rather than successively prepend an IPv4 header and then perform label imposition based on the IPv4 header, the ingress 6PE Router MUST directly perform label imposition of the IPv6 header without prepending any IPv4 header. The (outer) label imposed MUST correspond to the IPv4- signaled LSP starting on the ingress 6PE Router and ending on the egress 6PE Router.
IPv4のMPLSバックボーン上でIPv6パケットをトンネリングではなく、連続的にIPv4ヘッダを付加した後、IPv4ヘッダに基づいて、ラベル面付けを実行すると、入口6PEルータは、直接任意のIPv4ヘッダを付加することなく、IPv6ヘッダのラベル面付けを実行しなければなりません。課さ（外側の）ラベルはIPv4-に対応しなければならない入口6PEルータで開始し、出口6PEルータで終わるLSPを合図。
While this approach could theoretically operate in some situations using a single level of labels, there are significant advantages in using a second level of labels that are bound to IPv6 prefixes via MP-BGP advertisements in accordance with [RFC3107].
このアプローチは理論的には、ラベルの単一レベルを使用して、いくつかの状況で動作することができるが、[RFC3107]に従って、MP-BGP広告を介してIPv6プレフィックスにバインドされたラベルの第二レベルを使用することに大きな利点があります。
For instance, the use of a second level label allows Penultimate Hop Popping (PHP) on the IPv4 Label Switch Router (LSR) upstream of the egress 6PE router, without any IPv6 capabilities/upgrades on the penultimate router; this is because it still transmits MPLS packets even after the PHP (instead of having to transmit IPv6 packets and encapsulate them appropriately).
例えば、第2レベルのラベルを使用すると、出口6PEルータのIPv4のラベルスイッチルータ上の最後から二番目のホップポッピング（PHP）（LSR）上流のを可能にする任意のIPv6機能無し/最後から二番目のルータのアップグレード。それはまだも（代わりに、IPv6パケットを送信し、それらを適切にカプセル化することの）PHPの後にMPLSパケットを送信するためです。
Also, an existing IPv4-signaled LSP that is using "IPv4 Explicit NULL label" over the last hop (e.g., because that LSP is already being used to transport IPv4 traffic with the Pipe Diff-Serv Tunneling Model as defined in [RFC3270]) could not be used to carry IPv6 with a single label since the "IPv4 Explicit NULL label" cannot be used to carry native IPv6 traffic (see [RFC3032]), while it could be used to carry labeled IPv6 traffic (see [RFC4182]).
（[RFC3270]で定義されるように、そのLSPが既にパイプのDiff-Servのトンネリングモデルを用いたIPv4トラフィックを転送するために使用されているため、例えば）最終ホップ上「のIPv4明示的NULLラベル」を使用しても、既存のIPv4-シグナリングLSP標識されたIPv6トラフィックを運ぶために使用することができるが、「IPv4の明示的NULLラベル」は、（[RFC3032]を参照）ネイティブIPv6トラフィックを運ぶために使用することができないので（[RFC4182]を参照）は、単一の標識でIPv6を運ぶために使用することができませんでした。
This is why a second label MUST be used with the 6PE approach.
第二ラベルが6PEのアプローチで使用されなければならない理由です。
The label bound by MP-BGP to the IPv6 prefix indicates to the egress 6PE Router that the packet is an IPv6 packet. This label advertised by the egress 6PE Router with MP-BGP MAY be an arbitrary label value, which identifies an IPv6 routing context or outgoing interface to send the packet to, or MAY be the IPv6 Explicit Null Label. An ingress 6PE Router MUST be able to accept any such advertised label.
IPv6プレフィックスにMP-BGPによって結合した標識は、パケットがIPv6パケットである、出口6PEルータに示します。 MP-BGPと出口6PEルータによってアドバタイズこのラベルはにパケットを送信するIPv6ルーティングコンテキストまたは発信インターフェイスを識別する任意のラベルの値であってもよく、またはIPv6明示的ヌル標識であり得ます。入口6PEルータは、このような宣伝のラベルを受け入れることができなければなりません。
[RFC2460] requires that every link in the IPv6 Internet have an MTU of 1280 octets or larger. Therefore, on MPLS links that are used for transport of IPv6, as per the 6PE approach, and that do not support link-specific fragmentation and reassembly, the MTU must be configured to at least 1280 octets plus the encapsulation overhead.
[RFC2460]はIPv6インターネット内のすべてのリンクが1280オクテット以上のMTUを持っていることが必要です。したがって、6PEのアプローチに従って、IPv6の輸送のために使用され、そのリンク固有の断片化と再構築をサポートしていないMPLSリンクで、MTUは少なくとも1280オクテットプラスカプセル化のオーバーヘッドに設定する必要があります。
Some IPv6 hosts might be sending packets larger than the MTU available in the IPv4 MPLS core and rely on Path MTU discovery to learn about those links. To simplify MTU discovery operations, one option is for the network administrator to engineer the MTU on the core facing interfaces of the ingress 6PE consistent with the core MTU. ICMP 'Packet Too Big' messages can then be sent back by the ingress 6PE without the corresponding packets ever entering the MPLS core. Otherwise, routers in the IPv4 MPLS network have the option to generate an ICMP "Packet Too Big" message using mechanisms as described in Section 2.3.2, "Tunneling Private Addresses through a Public Backbone" of [RFC3032].
いくつかのIPv6ホストは、IPv4 MPLSコアで利用可能なMTUよりも大きなパケットを送信し、それらのリンクについて学ぶためにパスMTUディスカバリに依存している可能性があります。ネットワーク管理者はコアMTUと一致入口6PEのコア側インターフェイスでMTUを設計するためにMTU発見動作を簡略化するために、一つの選択肢です。 ICMP「パケット過大」メッセージは、対応するパケットは、これまでMPLSコアを入力せずに進入6PEで送り返すことができます。それ以外の場合は、IPv4のMPLSネットワーク内のルータは、[RFC3032]の「公共のバックボーンを通じてプライベートアドレスをトンネリング」セクション2.3.2で説明したようにメカニズムを使用してICMP「パケット過大」メッセージを、生成するオプションがあります。
Note that in the above case, should a core router with an outgoing link with an MTU smaller than 1280 receive an encapsulated IPv6 packet larger than 1280, then the mechanisms of [RFC3032] may result in the "Packet Too Big" message never reaching the sender. This is because, according to [RFC4443], the core router will build an ICMP "Packet Too Big" message filled with the invoking packet up to 1280 bytes, and when forwarding downstream towards the egress PE as per [RFC3032], the MTU of the outgoing link will cause the packet to be dropped. This may cause significant operational problems; the originator of the packets will notice that his data is not getting through, without knowing why and where they are discarded. This issue would only occur if the above recommendation (to configure MTU on MPLS links of at least 1280 octets plus encapsulation overhead) is not adhered to (perhaps by misconfiguration).
1280よりも小さいMTUを持つ発信リンクとコアルータ1280より大きいカプセル化されたIPv6パケットを受信しなければならないような場合に、その後、[RFC3032]のメカニズムは「パケット過大」メッセージが到達決して生じ得ることに留意されたいです送信者。 [RFC4443]によれば、コアルーター1280バイトまで呼び出しパケットで満たさICMP「パケット過大」メッセージを構築する、ため、および[RFC3032]に従って出口PEに向かって下流に転送する際のMTUであります発信リンクは、パケットが廃棄されることになります。これは重大な操作上の問題を引き起こす可能性があります。パケットの発信元は、彼のデータは、なぜ、どこが破棄されている知らずに、通じ取得していないことがわかります。上記の勧告は（少なくとも1280オクテットプラスカプセル化オーバーヘッドのMPLSリンク上でMTUを設定する）場合、この問題は、のみに接着されていない（おそらく設定ミスによって）を発生するであろう。
This section discusses the case where two IPv6 islands are connected to different Autonomous Systems (ASes).
このセクションでは、2つのIPv6アイランドは、異なる自律システム（のAS）に接続されている場合について説明します。
Like in the case of multi-AS backbone operations for IPv4 VPNs described in Section 10 of [RFC4364], three main approaches can be distinguished:
[RFC4364]のセクション10に記載のIPv4 VPNのマルチASバックボーン操作の場合と同様に、三つの主要なアプローチが区別することができます。
a. eBGP redistribution of IPv6 routes from AS to neighboring AS
A。 AS隣接するASからIPv6ルートの再分配のeBGP
This approach is the equivalent for exchange of IPv6 routes to procedure (a) described in Section 10 of [RFC4364] for the exchange of VPN-IPv4 routes.
このアプローチは、VPN-IPv4経路の交換のために[RFC4364]のセクション10（a）に記載された手順とIPv6ルートの交換と等価です。
In this approach, the 6PE routers use IBGP (according to [RFC2545] and [RFC3107] and as described in this document for the single-AS situation) to redistribute labeled IPv6 routes either to an Autonomous System Border Router (ASBR) 6PE router, or to a route reflector of which an ASBR 6PE router is a client. The ASBR then uses eBGP to redistribute the (non-labeled) IPv6 routes to an ASBR in another AS, which in turn distributes them to the 6PE routers in that AS as described earlier in this specification, or perhaps to another ASBR, which in turn distributes them etc.
（シングルAS状況については、この文書に記載されているように[RFC2545]及び[RFC3107]に従うと）このアプローチでは、6PEルータは、いずれかの自律システム境界ルータ（ASBR）6PEルータに標識されたIPv6ルートを再配布するIBGPを使用しますまたはASBR 6PEルータがクライアントとなっているルートリフレクタへ。 ASBRは、その後順番に順番に前にこの明細書に記載のように、またはおそらく別のASBRにその中6PEルータ、それらを配信する別のAS内のASBRに（非標識）IPv6ルートを再配布するのeBGPを使用しなど、それらを配布
There may be one, or multiple, ASBR interconnection(s) across any two ASes. IPv6 needs to be activated on the inter-ASBR links and each ASBR 6PE router has at least one IPv6 address on the interface to that link.
任意の二つのASを横断一つまたは複数、ASBR配線（S）が存在してもよいです。 IPv6は相互ASBRリンク上でアクティブにする必要があり、各ASBR 6PEルータはそのリンクへのインタフェース上に少なくとも1つのIPv6アドレスを持っています。
No inter-AS LSPs are used. There is effectively a separate mesh of LSPs across the 6PE routers within each AS.
いいえAS間LSPは使用されません。各AS内の6PEルータ間のLSPの別々のメッシュが効果的にあります。
In this approach, the ASBR exchanging IPv6 routes may peer over IPv6 or IPv4. The exchange of IPv6 routes MUST be carried out as per [RFC2545].
このアプローチでは、IPv6ルートを交換するASBRは、IPv6又はIPv4の上にピアできます。 IPv6ルートの交換は、[RFC2545]に従って行わなければなりません。
Note that the peering ASBR in the neighboring AS to which the IPv6 routes were distributed with eBGP, should in its turn redistribute these routes to the 6PEs in its AS using IBGP and encoding its own IPv4 address as the IPv4-mapped IPv6 BGP Next Hop.
近隣にピアリングASBRは、そのIPv6ルートをのeBGPと一緒に配布されたように、その順番にIBGPを使用し、IPv4射影IPv6 BGPネクストホップとして、自身のIPv4アドレスを符号化するように、その中に6PEsにこれらのルートを再配布する必要があることに注意してください。
b. eBGP redistribution of labeled IPv6 routes from AS to neighboring AS
B。 ASからAS隣接する標識されたIPv6ルートの再分配のeBGP
This approach is the equivalent for exchange of IPv6 routes to procedure (b) described in Section 10 of [RFC4364] for the exchange of VPN-IPv4 routes.
このアプローチは、（b）は、VPN-IPv4経路の交換のために[RFC4364]のセクション10で記載された手順とIPv6ルートの交換と等価です。
In this approach, the 6PE routers use IBGP (as described earlier in this document for the single-AS situation) to redistribute labeled IPv6 routes either to an Autonomous System Border Router (ASBR) 6PE router, or to a route reflector of which an ASBR 6PE router is a client. The ASBR then uses eBGP to redistribute the labeled IPv6 routes to an ASBR in another AS, which in turn distributes them to the 6PE routers in that AS as described earlier in this specification, or perhaps to another ASBR, which in turn distributes them, etc.
（単一-ASの状況に前にこの文書で説明したように）このアプローチでは、6PEルータは、自律システム境界ルータ（ASBR）6PEルータへの、又はASBRのルートリフレクタのいずれかに標識されたIPv6ルートを再配布するIBGPを使用します6PEルータはクライアントです。 ASBRは、その後順番に前にこの明細書に記載のように、またはおそらく順番にそれらを分配する別のASBRにその中6PEルータなどに配布し、別のAS内のASBRに標識されたIPv6ルートを再配布するのeBGPを使用し。
There may be one, or multiple, ASBR interconnection(s) across any two ASes. IPv6 may or may not be activated on the inter-ASBR links.
任意の二つのASを横断一つまたは複数、ASBR配線（S）が存在してもよいです。 IPv6は、またはインターASBRリンク上で起動してもしなくてもよいです。
This approach requires that there be label switched paths established across ASes. Hence the corresponding considerations described for procedure (b) in Section 10 of [RFC4364] apply equally to this approach for IPv6.
このアプローチは、そこにラベルでのAS間で確立されたパスを切り替えることが必要です。よって[RFC4364]のセクション10における手順（B）に記載の対応する考察は、IPv6のためのこのアプローチにも同様に適用されます。
In this approach, the ASBR exchanging IPv6 routes may peer over IPv4 or IPv6 (in which case IPv6 obviously needs to be activated on the inter-ASBR link). When peering over IPv6, the exchange of labeled IPv6 routes MUST be carried out as per [RFC2545] and [RFC3107]. When peering over IPv4, the exchange of labeled IPv6
このアプローチでは、IPv6ルートを交換するASBRは、（IPv6は明らか間ASBRリンク上で起動する必要がある場合）IPv4またはIPv6上ピアできます。 IPv6の上ピアリング場合、標識されたIPv6ルートの交換は、[RFC2545]及び[RFC3107]に従って行わなければなりません。 IPv4の標識のIPv6の交換を超えるピアリングする場合
routes MUST be carried out as per [RFC2545] and [RFC3107] with encoding of the IPv4 address of the ASBR as an IPv4-mapped IPv6 address in the BGP Next Hop field.
ルートは、BGPネクストホップフィールドにIPv4マップIPv6アドレスとしてASBRのIPv4アドレスの符号化と[RFC2545]及び[RFC3107]に従って行わなければなりません。
c. Multi-hop eBGP redistribution of labeled IPv6 routes between source and destination ASes, with eBGP redistribution of labeled IPv4 routes from AS to neighboring AS.
C。 ASからAS隣接する標識されたIPv4ルートの再分配のeBGPとソースと宛先AS間標識IPv6ルートのマルチホップのeBGP再分配。
This approach is the equivalent for exchange of IPv6 routes to procedure (c) described in Section 10 of [RFC4364] for exchange of VPN-IPv4 routes.
このアプローチは、VPN-IPv4経路の交換のために[RFC4364]のセクション10で記載された手順とIPv6ルートの交換（C）と同等です。
In this approach, IPv6 routes are neither maintained nor distributed by the ASBR routers. The ASBR routers need not be dual stack, but may be IPv4/MPLS-only routers. An ASBR needs to maintain labeled IPv4 /32 routes to the 6PE 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 /32 routes. This results in the creation of an IPv4 label switched path from the ingress 6PE router to the egress 6PE router. Now 6PE routers in different ASes can establish multi-hop eBGP connections to each other over IPv4, and can exchange labeled IPv6 routes (with an IPv4-mapped IPv6 BGP Next Hop) over those connections.
このアプローチでは、IPv6ルートはどちらも維持されていないもASBRルータによって配布します。 ASBRルータは、デュアルスタックである必要はなく、IPv4の/ MPLS-ルータだけかもしれません。 ASBRは、AS内6PEルータへの標識のIPv4 / 32ルートを維持する必要があります。これは、他のASにこれらのルートを配布するのeBGPを使用しています。任意の中継のAS内のASBRはまた、標識されたIPv4 / 32の経路に沿って通過するのeBGPを使用する必要があります。 IPv4のラベルの作成でこの結果は、出口6PEルータへの入口6PEルータからのパスを切り替えます。別のASに今6PEルータは、IPv4上に互いにマルチホップのeBGP接続を確立することができ、それらの接続を介して（IPv4マップIPv6のBGPネクストホップで）標識されたIPv6ルートを交換することができます。
IPv6 need not be activated on the inter-ASBR links.
IPv6は相互ASBRリンク上でアクティブ化する必要はありません。
The considerations described for procedure (c) in Section 10 of [RFC4364] with respect to possible use of multi-hop eBGP connections via route-reflectors in different ASes, as well as with respect to the use of a third label in case the IPv4 /32 routes for the PE routers are NOT made known to the P routers, apply equally to this approach for IPv6.
別のAS内のルートリフレクタを介したマルチホップのeBGP接続の可能な使用に関して[RFC4364]のセクション10の手順（C）に記載の考慮事項、ならびに場合IPv4の第三の標識の使用に関して/ PEルータ32ルートがPルータに知らされず、IPv6のためのこのアプローチにも同様に適用されます。
This approach requires that there be IPv4 label switched paths established across the ASes leading from a packet's ingress 6PE router to its egress 6PE router. Hence the considerations described for procedure (c) in Section 10 of [RFC4364], with respect to LSPs spanning multiple ASes, apply equally to this approach for IPv6.
このアプローチは、IPv4ラベルはその出口の6PEルータにパケットの入口6PEルータから大手のAS間で確立されたパスに切り替えがあることが必要です。したがって複数のASにまたがるのLSPに関して[RFC4364]のセクション10の手順（C）について記載した考察は、IPv6のためのこのアプローチにも同様に適用されます。
Note also that the exchange of IPv6 routes can only start after BGP has created IPv4 connectivity between the ASes.
BGPはAS間のIPv4接続を作成した後にIPv6ルートの交換が唯一始めることができることにも注意してください。
The extensions defined in this document allow BGP to propagate reachability information about IPv6 routes over an MPLS IPv4 core network. As such, no new security issues are raised beyond those that already exist in BGP-4 and use of MP-BGP for IPv6.
この文書で定義された拡張は、BGPは、MPLSのIPv4コア・ネットワーク上のIPv6ルートに関する到達可能性情報を伝播することを可能にします。そのため、新たなセキュリティ問題は、すでにBGP-4とIPv6のMP-BGPの使用に存在するものを超えて発生しません。
The security features of BGP and corresponding security policy defined in the ISP domain are applicable.
BGPやISPドメインで定義された対応するセキュリティポリシーのセキュリティ機能が適用されます。
For the inter-AS distribution of IPv6 routes according to case (a) of Section 4 of this document, no new security issues are raised beyond those that already exist in the use of eBGP for IPv6 [RFC2545].
このドキュメントのセクション4の場合に応じてIPv6ルートの間AS分布（A）のために、新たなセキュリティ問題は、既にのIPv6 [RFC2545]のためのeBGPの使用に存在するものを超えて上昇していません。
For the inter-AS distribution of IPv6 routes according to case (b) and (c) of Section 4 of this document, the procedures require that there be label switched paths established across the AS boundaries. Hence the appropriate trust relationships must exist between and among the set of ASes along the path. Care must be taken to avoid "label spoofing". To this end an ASBR 6PE SHOULD only accept labeled packets from its peer ASBR 6PE if the topmost label is a label that it has explicitly signaled to that peer ASBR 6PE.
AS間のケースに応じてIPv6ルートの分布（b）は、この文書のセクション4の（C）の場合、手順は、ラベルは、ASの境界を越えて確立されたパスが切り替えられることを必要とします。したがって、適切な信頼関係は、間、パスに沿ってのASの組の間に存在しなければなりません。ケアは、「ラベルなりすまし」を避けるようにしなければなりません。最上位ラベルは、それが明示的にそのピアのASBRの6PEに合図しているラベルである場合には、この目的を達成するためにASBR 6PEは、ピアASBR 6PEからラベル付きパケットを受け入れる必要があります。
Note that for the inter-AS distribution of IPv6 routes, according to case (c) of Section 4 of this document, label spoofing may be more difficult to prevent. Indeed, the MPLS label distributed with the IPv6 routes via multi-hop eBGP is directly sent from the egress 6PE to ingress 6PEs in another AS (or through route reflectors). This label is advertised transparently through the AS boundaries. When the egress 6PE that sent the labeled IPv6 routes receives a data packet that has this particular label on top of its stack, it may not be able to verify whether the label was pushed on the stack by an ingress 6PE that is allowed to do so. As such, one AS may be vulnerable to label spoofing in a different AS. The same issue equally applies to the option (c) of Section 10 of [RFC4364]. Just as it is the case for [RFC4364], addressing this particular security issue is for further study.
IPv6ルートのAS間の分布のために、このドキュメントのセクション4の場合（C）によれば、ラベルスプーフィングを防止することがより困難であり得ることに留意されたいです。実際、マルチホップのeBGPを介してIPv6ルートで配布MPLSラベルは、直接別のAS（またはルートリフレクタを介して）に6PEsに進入する出口6PEから送信されます。このラベルは、AS境界を透過的に宣伝されています。標識されたIPv6ルートを送信出口6PEは、そのスタックの最上部に、この特定のラベルを有するデータパケットを受信すると、ラベルがそうすることを許可されている入口6PEによってスタックにプッシュしたかどうかを確認することができないかもしれません。そのため、1 ASは異なるAS内のラベルなりすましに脆弱になることがあります。同じ問題は等しく[RFC4364]のセクション10のオプション（C）に適用されます。それは[RFC4364]の場合と同じように、この特定のセキュリティ問題に対処することは、今後の検討課題です。
We wish to thank Gerard Gastaud and Eric Levy-Abegnoli who contributed to this document. We also wish to thank Tri T. Nguyen, who initiated this document, but unfortunately passed away much too soon. We also thank Pekka Savola for his valuable comments and suggestions.
私たちは、この文書に貢献したジェラール・Gastaudとエリック・レヴィ-Abegnoliに感謝したいです。また、この文書を開始したが、残念ながらあまりにもすぐに亡くなったトライT.グエンを、感謝したいです。我々はまた、彼の貴重な意見や提案のためのペッカSavolaに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
[RFC2545]マルケス、P.およびF.デュポン、RFC 2545 "IPv6のドメイン間ルーティングのためのBGP-4マルチプロトコル拡張機能の使用"、1999年3月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.、およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[RFC3107] Rekhter、Y.、およびE.ローゼン、 "BGP-4でラベル情報を運ぶ"、RFC 3107、2001年5月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]ベイツ、T.、チャンドラ、R.、カッツ、D.、およびY. Rekhter、 "BGP-4のためのマルチプロトコル拡張機能"、RFC 4760、2007年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（MPLS）差別化サービスのサポート」、RFC 3270、2002年5月。
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[RFC4029]リンド、M.、Ksinant、V.、公園、S.、ボドー、A.、およびP. Savola、 "ISPネットワークにIPv6を導入するためのシナリオと分析"、RFC 4029、2005年3月。
[RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS Explicit NULL", RFC 4182, September 2005.
[RFC4182]ローゼン、E.、 "MPLS明示的なNULLの使用の制限を削除"、RFC 4182、2005年9月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン6（IPv6）の仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 4443、2006年3月。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
[RFC4659]デClercq、J.、Ooms、D.、Carugi、M.、およびF.ルFaucheur、 "BGP-MPLS IP仮想プライベートネットワーク（VPN）は、IPv6 VPNのための拡張"、RFC 4659、2006年9月。
Authors' Addresses
著者のアドレス
Jeremy De Clercq Alcatel-Lucent Copernicuslaan 50 Antwerpen 2018 Belgium
ジェレミー・デClercqアルカテル・ルーセントCopernicuslaan 50アントワープベルギー
EMail: jeremy.de_clercq@alcatel-lucent.be
メールアドレス：jeremy.de_clercq@alcatel-lucent.be
Dirk Ooms OneSparrow Belegstraat 13 Antwerpen 2018 Belgium
ディルクOoms OneSparrow Belegstraat 13アントワープベルギー
EMail: dirk@onesparrow.com
メールアドレス：dirk@onesparrow.com
Stuart Prevost BT Room 136 Polaris House, Adastral Park, Martlesham Heath Ipswich Suffolk IP5 3RE England EMail: stuart.prevost@bt.com
スチュアート・プレボBTルーム136ポラリスハウス、Adastral公園、MartleshamヒースイプスウィッチIP5 3REイングランドEメール：stuart.prevost@bt.com
Francois Le Faucheur Cisco Domaine Green Side, 400 Avenue de Roumanille Biot, Sophia Antipolis 06410 France
フランソワ・リーパーシスコフィールドグリーンサイド、400アベニューRoumanilleビオ、ソフィアアンティポリス、フランス06410
EMail: flefauch@cisco.com
メールアドレス：flefauch@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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, THE IETF TRUST 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。