[要約] RFC 6654は、IPv4インフラストラクチャ上でのIPv6の迅速な展開を可能にするGateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures（GI 6rd）に関する規格です。この規格の目的は、IPv6の導入を簡素化し、IPv4ネットワーク上でのIPv6の展開を促進することです。
Independent Submission T. Tsou
Request for Comments: 6654 Huawei Technologies (USA)
Category: Informational C. Zhou
ISSN: 2070-1721 T. Taylor
Huawei Technologies
Q. Chen
China Telecom
July 2012
Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd)
ゲートウェイが開始するIPv4インフラストラクチャでのIPv6の迅速な導入（GI 6rd）
Abstract
概要
This document proposes an alternative IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) deployment model to that of RFC 5969. The basic 6rd model allows IPv6 hosts to gain access to IPv6 networks across an IPv4 access network using 6-in-4 tunnels. 6rd requires support by a device (the 6rd customer edge, or 6rd-CE) on the customer site, which must also be assigned an IPv4 address. The alternative model described in this document initiates the 6-in-4 tunnels from an operator-owned Gateway collocated with the operator's IPv4 network edge rather than from customer equipment, and hence is termed "Gateway-initiated 6rd" (GI 6rd). The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment. The latter point means less pressure on IPv4 addresses in a high-growth environment.
このドキュメントは、RFC 5969のIPv6展開モデルに代わるIPv6迅速な展開を提案します。基本的な6番目のモデルにより、IPv6ホストは6-in-4トンネルを使用してIPv4アクセスネットワーク全体でIPv6ネットワークにアクセスできます。 6rdには、顧客サイトのデバイス（6rdカスタマーエッジ、または6rd-CE）によるサポートが必要です。これには、IPv4アドレスも割り当てる必要があります。このドキュメントで説明する代替モデルは、顧客の機器からではなく、オペレーターのIPv4ネットワークエッジと同じ場所にあるオペレーター所有のゲートウェイから6-in-4トンネルを開始するため、「ゲートウェイ開始6rd」（GI 6rd）と呼ばれます。このアプローチの利点は、顧客の機器を変更する必要がなく、顧客の機器へのIPv4アドレスの割り当てを回避できることです。後者の点は、高成長環境でのIPv4アドレスへのプレッシャーが少ないことを意味します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6654.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6654で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Problem Statement ...............................................3
3. Proposed Solution ...............................................4
3.1. Prefix Delegation ..........................................5
3.2. Relevant Differences from Basic 6rd ........................6
4. Security Considerations .........................................7
5. Acknowledgements ................................................7
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
6rd [RFC5969] provides a transition tool for connecting IPv6 devices across an IPv4 network to an IPv6 network, at which point the packets can be routed natively. The network topology is shown in Figure 1.
6rd [RFC5969]は、IPv4ネットワークを介してIPv6デバイスをIPv6ネットワークに接続するための移行ツールを提供します。この時点で、パケットはネイティブにルーティングできます。ネットワークトポロジを図1に示します。
+--------------+ +-----------------+ +---------+
| | | | | |
+-----+ +-----+ | Provider +--------+ | |
|IPv6 | | 6rd |__| IPv4 | Border |__| IPv6 |
|Host | | CE | | Network | Router | | Network |
+-----+ +-----+ | +--------+ | |
| Customer LAN | | | | |
+--------------+ +-----------------+ +---------+
Figure 1: 6rd Deployment Topology
図1：6番目の展開トポロジ
In Figure 1, the CE is the customer edge router. It is provisioned with a delegated IPv6 prefix, but it is also configured with an IPv4 address so that it is reachable through the IPv4 network. If a public IPv4 address is provisioned to every customer, it will aggravate the pressure due to the IPv4 address shortage for operators faced with a high rate of growth in the number of broadband subscribers to their network. The use of private addresses with 6rd avoids this particular difficulty but brings other complications.
図1では、CEはカスタマーエッジルータです。委任されたIPv6プレフィックスを使用してプロビジョニングされますが、IPv4ネットワークを介して到達できるように、IPv4アドレスを使用して構成されます。パブリックIPv4アドレスがすべての顧客にプロビジョニングされる場合、ネットワークへのブロードバンドサブスクライバーの数の高率の成長に直面しているオペレーターのIPv4アドレス不足によるプレッシャーを悪化させます。 6rdでプライベートアドレスを使用すると、この特定の問題は回避されますが、他の複雑な問題が発生します。
Consider an operator facing a high subscriber growth rate. As a result of this growth rate, the operator faces pressure on its stock of available public IPv4 addresses. For this reason, the operator is motivated to offer IPv6 access as quickly as possible. Figure 2 shows the sort of network situation envisioned in the present document.
加入者の増加率が高いオペレーターを検討してください。この成長率の結果、事業者は利用可能なパブリックIPv4アドレスの在庫に圧力をかけています。このため、オペレーターはIPv6アクセスを可能な限り迅速に提供する動機があります。図2は、本書で想定されているネットワークの状況を示しています。
+----+ +-------------------+ +----------------+
|Host|\ | | | |
+----+ \_+---+ +----+ Metro +----+ | Backbone |
_|CPE|----| GW | Network | BR |--| Network |
+----+ / +---+ +----+ (IPv4) +----+ | (IPv6) |
|Host|/ | | | |
+----+ +-------------------+ +----------------+
Host = IPv6 customer host device CPE = customer edge device (customer-provided) GW = provider edge device (Gateway) BR = border router (dual stack)
ホスト= IPv6カスタマーホストデバイスCPE =カスタマーエッジデバイス（顧客提供）GW =プロバイダーエッジデバイス（ゲートウェイ）BR =ボーダールーター（デュアルスタック）
Specialized GW and BR functions are described in the next section.
専用のGWおよびBR機能については、次のセクションで説明します。
Figure 2: Typical Network Scenario for IPv6 Transition
図2：IPv6移行の一般的なネットワークシナリオ
The backbone network will be the first part of the operator's network to support IPv6. The metro network is not so easily upgraded to support IPv6, since many devices need to be modified and there may be some impact to existing services. Thus, any means of providing IPv6 access has to minimize the changes required to devices in the metro network.
バックボーンネットワークは、IPv6をサポートする事業者のネットワークの最初の部分になります。多くのデバイスを変更する必要があり、既存のサービスに何らかの影響がある可能性があるため、メトロネットワークはIPv6をサポートするように簡単にアップグレードできません。したがって、IPv6アクセスを提供する手段では、メトロネットワーク内のデバイスに必要な変更を最小限に抑える必要があります。
In contrast to the situation described for basic 6rd [RFC5569], the operator is assumed to have no control over the capabilities of the IP devices on the customer premises. As a result, the operator cannot assume that any of these devices are capable of supporting 6rd.
基本的な6番目の[RFC5569]で説明されている状況とは対照的に、オペレーターは顧客の構内にあるIPデバイスの機能を制御できないと想定されています。その結果、オペレーターはこれらのデバイスのいずれかが6をサポートできると想定することはできません。
If the customer equipment is in bridged mode and IPv6 is deployed to sites via a Service Provider's (SP's) IPv4 network, the IPv6-only host needs an IPv6 address to visit the IPv6 service. In this scenario, 6to4 [RFC3056] or 6rd can be used. However, each IPv6-only host may need one corresponding IPv4 address when using a public IPv4 address in 6to4 or 6rd, which puts great address pressure on the operators.
カスタマー機器がブリッジモードで、IPv6がサービスプロバイダー（SP）のIPv4ネットワーク経由でサイトに展開されている場合、IPv6のみのホストはIPv6サービスにアクセスするためにIPv6アドレスを必要とします。このシナリオでは、6to4 [RFC3056]または6rdを使用できます。ただし、6to4または6rdでパブリックIPv4アドレスを使用する場合、各IPv6のみのホストは対応するIPv4アドレスを1つ必要とする場合があり、オペレーターに大きなアドレスのプレッシャーをかけます。
If the CPE in the above figure is acting in bridging mode, each host behind it needs to be directly assigned an IPv6 prefix so it can access IPv6 services. If the CPE is acting in routing mode, only the CPE needs to be assigned an IPv6 prefix, and it delegates prefixes to the hosts behind it.
上図のCPEがブリッジモードで動作している場合、背後の各ホストにIPv6プレフィックスを直接割り当てて、IPv6サービスにアクセスできるようにする必要があります。 CPEがルーティングモードで動作している場合、CPEにIPv6プレフィックスを割り当てるだけでよく、プレフィックスをその背後にあるホストに委任します。
If the Gateway supports IPv4 only, then an IPv4 address must also be assigned to each host (bridging mode) or to the CPE (routing mode). Both of these cases, but the bridging mode in particular, put pressure on the provider's stock of IPv4 addresses.
ゲートウェイがIPv4のみをサポートしている場合、IPv4アドレスも各ホスト（ブリッジモード）またはCPE（ルーティングモード）に割り当てる必要があります。これらの両方のケース、特にブリッジモードは、プロバイダーのIPv4アドレスのストックに圧力をかけます。
If the Gateway is dual stack, an arrangement may be possible whereby all communication between the Gateway and the customer site uses IPv6 and the need to assign IPv4 addresses to customer devices is avoided. A possible solution is presented in the next section.
ゲートウェイがデュアルスタックの場合、ゲートウェイとカスタマーサイト間のすべての通信でIPv6が使用され、カスタマーデバイスにIPv4アドレスを割り当てる必要がなくなるように配置できる可能性があります。可能な解決策は次のセクションで提示されます。
For basic 6rd [RFC5969], the 6rd CE initiates the 6-in-4 tunnel to the dual-stack border router (i.e., the 6rd Border Relay in 6rd terminology) to carry its IPv6 traffic. To avoid the requirement for customer premises equipment to fulfill this role, it is necessary to move the tunneling function to a network device. This document identifies a functional element, termed the 6rd Gateway, to perform this task. In what follows, the 6rd Gateway and 6rd Border Relay are referred to simply as the Gateway and Border Relay, respectively.
基本的な6rd [RFC5969]の場合、6rd CEは、デュアルスタックボーダールーター（つまり、6番目の用語では6rdボーダーリレー）への6-in-4トンネルを開始して、IPv6トラフィックを伝送します。顧客宅内機器がこの役割を果たすための要件を回避するには、トンネリング機能をネットワークデバイスに移動する必要があります。このドキュメントでは、このタスクを実行するための第6ゲートウェイと呼ばれる機能要素を特定します。以下では、第6ゲートウェイと第6ボーダーリレーを、それぞれ単にゲートウェイとボーダーリレーと呼びます。
The functions of the Gateway are as follows:
ゲートウェイの機能は次のとおりです。
o to generate and allocate Gateway-initiated 6rd delegated prefixes for IPv6-capable customer devices, as described in Section 3.1;
o セクション3.1で説明されているように、IPv6対応の顧客デバイス用にゲートウェイで開始される6番目の委任されたプレフィックスを生成して割り当てる。
o to forward outgoing IPv6 packets through a tunnel to a Border Relay, which extracts and forwards them to an IPv6 network as for 6rd;
o トンネルを介してボーダーリレーに発信IPv6パケットを転送します。ボーダーリレーは、それらを抽出してIPv6ネットワークに転送します。
o to extract incoming IPv6 packets tunneled from the Border Relay and forward them to the correct user device.
o ボーダーリレーからトンネルされた着信IPv6パケットを抽出し、それらを正しいユーザーデバイスに転送します。
In the proposed solution, there is only one tunnel initiated from each Gateway to the Border Relay, which greatly reduces the number of tunnels the Border Relay has to handle. The deployment scenario consistent with the problem statement in Section 2 collocates the Gateway with the IP edge of the access network. This is shown in Figure 2 and is the typical placement of the Broadband Network Gateway (BNG) in a fixed broadband network. By assumption, the metro network beyond the BNG is IPv4. Transport between the customer site and the Gateway is over Layer 2.
提案されたソリューションでは、各ゲートウェイからボーダーリレーに開始されるトンネルは1つだけです。これにより、ボーダーリレーが処理する必要のあるトンネルの数が大幅に削減されます。セクション2の問題ステートメントと一致する展開シナリオでは、ゲートウェイをアクセスネットワークのIPエッジに配置します。これを図2に示します。これは、固定ブロードバンドネットワークにおけるブロードバンドネットワークゲートウェイ（BNG）の一般的な配置です。想定では、BNGを超えるメトロネットワークはIPv4です。カスタマーサイトとゲートウェイ間の転送は、レイヤ2を介して行われます。
The elements of the proposed solution are as follows:
提案されたソリューションの要素は次のとおりです。
o The IPv6 prefix assigned to the customer site contains the compressed IPv4 address of the network-facing side of the Gateway, plus a manually provisioned or Gateway-generated customer site identifier. This is illustrated in Figure 3.
o カスタマーサイトに割り当てられたIPv6プレフィックスには、ゲートウェイのネットワーク側の圧縮IPv4アドレスと、手動でプロビジョニングされた、またはゲートウェイが生成したカスタマーサイト識別子が含まれます。これを図3に示します。
o The Border Relay is able to route incoming IPv6 packets to the correct Gateway by extracting the compressed Gateway address from the IPv6 destination address of the incoming packet, expanding it to a full 32-bit IPv4 address, and setting it as the destination address of the encapsulated packet.
o ボーダーリレーは、着信パケットのIPv6宛先アドレスから圧縮されたゲートウェイアドレスを抽出し、それを完全な32ビットIPv4アドレスに展開し、それをの宛先アドレスとして設定することにより、着信IPv6パケットを正しいゲートウェイにルーティングできます。カプセル化されたパケット。
o The Gateway can route incoming packets to the correct link after decapsulation using a mapping from either the full IPv6 prefix or the customer site identifier extracted from that prefix to the appropriate link.
o ゲートウェイは、完全なIPv6プレフィックスまたはそのプレフィックスから適切なリンクに抽出されたカスタマーサイト識別子のいずれかからのマッピングを使用して、カプセル化解除後に着信パケットを正しいリンクにルーティングできます。
Referring back to Figure 2, prefix assignment to the customer equipment occurs in the normal fashion through the Gateway/IP edge, using either DHCPv6 or Stateless Address Autoconfiguration (SLAAC). Figure 3 illustrates the structure of the assigned prefix, and how the components are derived, within the context of a complete address.
図2を再度参照すると、カスタマー機器へのプレフィックス割り当ては、DHCPv6またはステートレスアドレス自動構成（SLAAC）のいずれかを使用して、ゲートウェイ/ IPエッジを介して通常の方法で行われます。図3は、完全なアドレスのコンテキスト内で、割り当てられたプレフィックスの構造とコンポーネントがどのように派生するかを示しています。
+--------------------+-----------+
| 32-bit Gateway IPv4 address |
+--------------------+-----------+
|<---IPv4MaskLen --->| o bits | Gateway or manually
/ / generated value, unique
Configured / / / for the Gateway
| / / |
| / / V
| V p bits | o bits | n bits |m bits | 64 bits |
+----------------+------------+---------+-------+----------------+
| | Gateway |Customer | | |
| Common prefix | Identifier | Site |subnet | interface ID |
| | | Index | ID | |
+----------------+------------+---------+-------+----------------+
|<------ GI 6rd delegated prefix ------>|
Figure 3: Gateway-Initiated 6rd Address Format for a Customer Site
図3：顧客サイトのゲートウェイ開始の6番目のアドレス形式
The common prefix, i.e., the first p bits of the GI 6rd delegated prefix, is configured in the Gateway. This part of the prefix is common across multiple customers and multiple Gateways. Multiple common prefix values may be used in a network either for service separation or for scalability.
ゲートウェイでは、共通のプレフィックス、つまりGI 6rd委任プレフィックスの最初のpビットが構成されます。プレフィックスのこの部分は、複数の顧客と複数のゲートウェイに共通です。ネットワークでは、サービスの分離またはスケーラビリティのために、複数の一般的なプレフィックス値を使用できます。
The Gateway Identifier is equal to the o low-order bits of the Gateway IPv4 address on the virtual link to the Border Relay. The number of bits o is equal to (32 - IPv4MaskLen), where the latter is the length of the IPv4 prefix from which the Gateway IPv4 addresses are derived. The value of IPv4MaskLen is configured in both the Gateways and the Border Relays.
ゲートウェイ識別子は、ボーダーリレーへの仮想リンク上のゲートウェイIPv4アドレスの下位ビットと同じです。ビット数oは（32-IPv4MaskLen）に等しく、後者は、ゲートウェイIPv4アドレスが派生するIPv4プレフィックスの長さです。 IPv4MaskLenの値は、ゲートウェイとボーダーリレーの両方で構成されます。
The Customer Site Index is effectively a sequence number assigned to an individual customer site served by the Gateway. The value of the index for a given customer site must be unique across the Gateway. The length n of the Customer Site Index is provisioned in the Gateway and must be large enough to accommodate the number of customer sites that the Gateway is expected to serve.
顧客サイトインデックスは、事実上、ゲートウェイが提供する個々の顧客サイトに割り当てられたシーケンス番号です。特定の顧客サイトのインデックスの値は、ゲートウェイ全体で一意である必要があります。カスタマーサイトインデックスの長さnはゲートウェイでプロビジョニングされ、ゲートウェイがサービスを提供すると予想されるカスタマーサイトの数に対応するのに十分な長さである必要があります。
To give a numerical example, consider a 6rd domain containing ten million IPv6-capable customer devices (a rather high number given that 6rd is meant for the early stages of IPv6 deployment). The estimated number of 6rd Gateways needed to serve this domain would be on the order of 3,300, each serving 30,000 customer devices. Assuming best-case compression for the Gateway addresses, the Gateway Identifier field has length o = 12 bits. If 6-in-4 tunneling is being used, this best case is more likely to be achievable than it would be if the IPv4 addresses belonged to the customer devices. The customer device index, which is a more controllable parameter, has length n = 15 bits.
数値の例を示すために、1千万のIPv6対応の顧客デバイスを含む6番目のドメインを考えます（6番目がIPv6展開の初期段階向けであることを考えると、かなり高い数です）。このドメインにサービスを提供するために必要な第6ゲートウェイの推定数は約3,300で、それぞれが30,000の顧客デバイスにサービスを提供します。ゲートウェイアドレスの圧縮が最良の場合を想定すると、ゲートウェイ識別子フィールドの長さはo = 12ビットになります。 6-in-4トンネリングが使用されている場合、このベストケースは、IPv4アドレスが顧客のデバイスに属している場合よりも実現可能性が高くなります。より制御可能なパラメーターであるカスタマーデバイスインデックスの長さはn = 15ビットです。
Overall, these figures suggest that the length p of the common prefix can be 29 bits for a /56 delegated prefix, or 21 bits if /48 delegated prefixes need to be allocated.
全体として、これらの図は、共通のプレフィックスの長さpが/ 56のデリゲートされたプレフィックスの場合は29ビット、または/ 48のデリゲートされたプレフィックスを割り当てる必要がある場合は21ビットになることを示唆しています。
A number of the points in [RFC5969] apply, with the simple substitution of the Gateway for the 6rd CE. When it comes to configuration, the definition of IPv4MaskLen changes, and there are other differences as indicated in the previous section. Since special configuration of customer equipment is not required, the 6rd DHCPv6 option is inapplicable.
[RFC5969]のいくつかのポイントが適用され、ゲートウェイを6rd CEに置き換えるだけです。構成に関しては、IPv4MaskLenの定義が変更され、前のセクションで示したように他の違いがあります。カスタマ機器の特別な構成は必要ないため、6番目のDHCPv6オプションは適用されません。
Since the link for the customer site to the network now extends only as far as the Gateway, Neighbor Unreachability Detection on the part of customer devices is similarly limited in scope.
現在、顧客サイトからネットワークへのリンクはゲートウェイまでしか拡張されていないため、顧客デバイス側の近隣到達不能検出の範囲も同様に制限されています。
No further security considerations are raised in this document to those described in the Security Considerations section of [RFC5969].
このドキュメントでは、[RFC5969]の「セキュリティに関する考慮事項」セクションで説明されているセキュリティに関する考慮事項はこれ以上取り上げられていません。
Thanks to Ole Troan for his technical comments on an early version of this document.
このドキュメントの初期バージョンに関する技術的なコメントを提供してくれたOle Troanに感謝します。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969] Townsley、W.およびO. Troan、「IPv4 Infrastructures on IPv4 Infrastructures（6rd）-Protocol Specification」、RFC 5969、2010年8月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B。およびK.ムーア、「IPv4クラウドを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5569] Despres、R。、「IPv4 Infrastructures on IPv4 Infrastructures（6rd）」、RFC 5569、2010年1月。
Authors' Addresses
著者のアドレス
Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA
Tina Tsou Huawei Technologies（USA）2330 Central Expressway Santa Clara、CA 95050 USA
EMail: Tina.Tsou.Zouting@huawei.com
Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China
Cathy Zhou hu Aは技術禁止の日であり、長いギャング地区は非常に現実的です518129 P.R. China
EMail: cathy.zhou@huawei.com
Tom Taylor Huawei Technologies Ottawa, Ontario Canada
Tom Taylor Huawei Technologiesオタワ、オンタリオ州、カナダ
EMail: tom.taylor.stds@gmail.com
Qi Chen China Telecom 109 Zhongshan Ave. West Tianhe District, Guangzhou 510630 P.R. China
Q ICは非常にチャイナテレコム109 Z爆撃身廊です。西TIは、広州510630地区と一致しています。
EMail: chenqi.0819@gmail.com