[要約] RFC 3904は、IPv6の移行メカニズムを評価するためのガイドラインです。このRFCの目的は、管理されていないネットワークでのIPv6移行の効果的な方法を提供することです。
Network Working Group C. Huitema
Request for Comments: 3904 Microsoft
Category: Informational R. Austein
ISC
S. Satapati
Cisco Systems, Inc.
R. van der Pol
NLnet Labs
September 2004
Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks
管理されていないネットワークのIPv6遷移メカニズムの評価
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document analyzes issues involved in the transition of "unmanaged networks" from IPv4 to IPv6. Unmanaged networks typically correspond to home networks or small office networks. A companion paper analyzes out the requirements for mechanisms needed in various transition scenarios of these networks to IPv6. Starting from this analysis, we evaluate the suitability of mechanisms that have already been specified, proposed, or deployed.
このドキュメントは、IPv4からIPv6への「管理されていないネットワーク」の移行に伴う問題を分析します。通常、管理されていないネットワークは、通常、ホームネットワークまたは小規模なオフィスネットワークに対応しています。コンパニオンペーパーは、これらのネットワークのIPv6へのさまざまな遷移シナリオで必要なメカニズムの要件を分析します。この分析から始めて、すでに指定、提案、または展開されているメカニズムの適合性を評価します。
Table of Contents:
目次：
1. Introduction ................................................. 2
2. Evaluation of Tunneling Solutions ............................ 3
2.1. Comparing Automatic and Configured Solutions ........... 3
2.1.1. Path Optimization in Automatic Tunnels ......... 4
2.1.2. Automatic Tunnels and Relays ................... 4
2.1.3. The Risk of Several Parallel IPv6 Internets .... 5
2.1.4. Lifespan of Transition Technologies ............ 6
2.2. Cost and Benefits of NAT Traversal ..................... 6
2.2.1. Cost of NAT Traversal .......................... 7
2.2.2. Types of NAT ................................... 7
2.2.3. Reuse of Existing Mechanisms ................... 8
2.3. Development of Transition Mechanisms ................... 8
3. Meeting Case A Requirements .................................. 9
3.1. Evaluation of Connectivity Mechanisms .................. 9
3.2. Security Considerations in Case A ...................... 9
4. Meeting case B Requirements .................................. 10
4.1. Connectivity ........................................... 10
4.1.1. Extending a Subnet to Span Multiple Links ...... 10
4.1.2. Explicit Prefix Delegation ..................... 11
4.1.3. Recommendation ................................. 11
4.2. Communication Between IPv4-only and IPv6-Capable Nodes . 11
4.3. Resolution of Names to IPv6 Addresses .................. 12
4.3.1. Provisioning the Address of a DNS Resolver ..... 12
4.3.2. Publishing IPv6 Addresses to the Internet ...... 12
4.3.3. Resolving the IPv6 Addresses of Local Hosts .... 13
4.3.4. Recommendations for Name Resolution ............ 13
4.4. Security Considerations in Case B ...................... 14
5. Meeting Case C Requirements .................................. 14
5.1. Connectivity ........................................... 14
6. Meeting the Case D Requirements .............................. 14
6.1. IPv6 Addressing Requirements ........................... 15
6.2. IPv4 Connectivity Requirements ........................ 15
6.3. Naming Requirements .................................... 15
7. Recommendations .............................................. 15
8. Security Considerations ...................................... 16
9. Acknowledgements ............................................. 16
10. References ................................................... 16
11. Authors' Addresses ........................................... 18
12. Full Copyright Statement ..................................... 19
This document analyzes the issues involved in the transition from IPv4 to IPv6 [IPV6]. In a companion paper [UNMANREQ] we defined the "unmanaged networks", which typically correspond to home networks or small office networks, and the requirements for transition mechanisms in various scenarios of transition to IPv6.
この文書は、IPv4からIPv6 [IPv6]への移行に伴う問題を分析します。コンパニオンペーパー[Unmanreq]では、通常、ホームネットワークまたは小オフィスネットワークに対応する「管理されていないネットワーク」と、IPv6への移行シナリオの移行メカニズムの要件を定義しました。
The requirements for unmanaged networks are expressed by analyzing four classes of applications: local, client, peer to peer, and servers, and are considering four cases of deployment. These are:
管理されていないネットワークの要件は、ローカル、クライアント、ピアツーピア、サーバーの4つのクラスのアプリケーションを分析することで表現され、4つの展開ケースを検討しています。これらは：
A) a gateway which does not provide IPv6 at all; B) a dual-stack gateway connected to a dual-stack ISP; C) a dual-stack gateway connected to an IPv4-only ISP; and D) a gateway connected to an IPv6-only ISP.
a）IPv6をまったく提供しないゲートウェイ。b）デュアルスタックISPに接続されたデュアルスタックゲートウェイ。c）IPv4のみのISPに接続されたデュアルスタックゲートウェイ。d）IPv6のみのISPに接続されたゲートウェイ。
During the transition phase from IPv4 to IPv6 there will be IPv4- only, dual-stack, or IPv6-only nodes. In this document, we make the hypothesis that the IPv6-only nodes do not need to communicate with IPv4-only nodes; devices that want to communicate with both IPv4 and IPv6 nodes are expected to implement both IPv4 and IPv6, i.e., be dual-stack.
IPv4からIPv6への遷移フェーズでは、IPv4-のみ、デュアルスタック、またはIPv6のみのノードがあります。このドキュメントでは、IPv6のみのノードがIPv4のみのノードと通信する必要がないという仮説を立てます。IPv4ノードとIPv6ノードの両方と通信したいデバイスは、IPv4とIPv6の両方、つまりデュアルスタックであることが期待されます。
The issues involved are described in the next sections. This analysis outlines two types of requirements: connectivity requirements, i.e., how to ensure that nodes can exchange IP packets, and naming requirements, i.e., how to ensure that nodes can resolve each-other's names. The connectivity requirements often require tunneling solutions. We devote the first section of this memo to an evaluation of various tunneling solutions.
関係する問題については、次のセクションで説明します。この分析では、2つのタイプの要件の概要を説明します。つまり、ノードがIPパケットを交換できるようにする方法、つまり、ノードがそれぞれの名前を解決できるようにする方法です。接続性の要件には、多くの場合、トンネリングソリューションが必要です。このメモの最初のセクションを、さまざまなトンネリングソリューションの評価に捧げます。
In the case A and case C scenarios described in [UNMANREQ], the unmanaged network cannot obtain IPv6 service, at least natively, from its ISP. In these cases, the IPv6 service will have to be provided through some form of tunnel. There have been multiple proposals on different ways to tunnel IPv6 through an IPv4 service. We believe that these proposals can be categorized according to two important properties:
[Unmanreq]で説明されているケースAおよびケースCシナリオでは、管理されていないネットワークは、少なくともISPからIPv6サービスを取得できません。これらの場合、IPv6サービスは何らかの形のトンネルを通じて提供する必要があります。IPv4サービスを介してIPv6をトンネルするさまざまな方法について複数の提案がありました。これらの提案は、2つの重要なプロパティに従って分類できると考えています。
* Is the deployment automatic, or does it require explicit configuration or service provisioning?
* 展開は自動的ですか、それとも明示的な構成またはサービスのプロビジョニングが必要ですか？
* Does the proposal allow for the traversal of a NAT?
* この提案は、NATのトラバーサルを許可していますか？
These two questions divide the solution space into four broad classes. Each of these classes has specific advantages and risks, which we will now develop.
これらの2つの質問は、ソリューションスペースを4つの広範なクラスに分割します。これらの各クラスには、特定の利点とリスクがあり、これが開発されます。
It is possible to broadly classify tunneling solutions as either "automatic" or "configured". In an automatic solution, a host or a router builds an IPv6 address or an IPv6 prefix by combining a pre-defined prefix with some local attribute, such as a local IPv4 address [6TO4] or the combination of an address and a port number [TEREDO]. Another typical and very important characteristic of an automatic solution is they aim to work with a minimal amount of support or infrastructure for IPv6 in the local or remote ISPs.
トンネリングソリューションを「自動」または「構成」のいずれかとして広く分類することができます。自動ソリューションでは、ホストまたはルーターが、事前定義されたプレフィックスとローカルIPv4アドレス[6TO4]やアドレスとポート番号の組み合わせなどのローカル属性を組み合わせることにより、IPv6アドレスまたはIPv6プレフィックスを構築します。テレド]。自動ソリューションのもう1つの典型的で非常に重要な特徴は、ローカルまたはリモートISPのIPv6の最小限のサポートまたはインフラストラクチャで作業することを目指していることです。
In a configured solution, a host or a router identifies itself to a tunneling service to set up a "configured tunnel" with an explicitly defined "tunnel router". The amount of actual configuration may vary from manually configured static tunnels to dynamic tunnel services requiring only the configuration of a "tunnel broker", or even a completely automatic discovery of the tunnel router.
構成されたソリューションでは、ホストまたはルーターがトンネルサービスに識別し、明示的に定義された「トンネルルーター」を備えた「構成されたトンネル」をセットアップします。実際の構成の量は、手動で構成された静的トンネルから、「トンネルブローカー」の構成のみを必要とする動的なトンネルサービスまで、またはトンネルルーターの完全に自動的な発見までさまざまです。
Configured tunnels have many advantages over automatic tunnels. The client is explicitly identified and can obtain a stable IPv6 address. The service provider is also well identified and can be held responsible for the quality of the service. It is possible to route multicast packets over the established tunnel. There is a clear address delegation path, which enables easy support for reverse DNS lookups.
構成されたトンネルには、自動トンネルよりも多くの利点があります。クライアントは明示的に識別され、安定したIPv6アドレスを取得できます。サービスプロバイダーもよく特定されており、サービスの品質について責任を負うことができます。マルチキャストパケットを確立されたトンネルにルーティングすることができます。逆のDNSルックアップを簡単にサポートできる明確なアドレス委任パスがあります。
Automatic tunnels generally cannot provide the same level of service. The IPv6 address is only as stable as the underlying IPv4 address, the quality of service depends on relays operated by third parties, there is typically no support for multicast, and there is often no easy way to support reverse DNS lookups (although some workarounds are probably possible). However, automatic tunnels have other advantages. They are obviously easier to configure, since there is no need for an explicit relation with a tunnel service. They may also be more efficient in some cases, as they allow for "path optimization".
通常、自動トンネルは同じレベルのサービスを提供することはできません。IPv6アドレスは、基礎となるIPv4アドレスと同じくらい安定しているだけで、サービスの品質はサードパーティによって動作するリレーに依存します。通常、マルチキャストをサポートすることはありません。おそらく可能です）。ただし、自動トンネルには他の利点があります。トンネルサービスとの明示的な関係は必要ないため、明らかに構成が簡単です。また、「パス最適化」を可能にするため、場合によってはより効率的になる場合があります。
In automatic tunnels like [TEREDO] and [6TO4], the bulk of the traffic between two nodes using the same technology is exchanged on a direct path between the endpoints, using the IPv4 services to which the endpoints already subscribe. By contrast, the configured tunnel servers carry all the traffic exchanged by the tunnel client.
[Teredo]や[6to4]などの自動トンネルでは、同じ技術を使用して2つのノード間のトラフィックの大部分が、エンドポイントがすでに購読しているIPv4サービスを使用して、エンドポイント間の直接的なパスで交換されます。対照的に、構成されたトンネルサーバーは、トンネルクライアントによって交換されるすべてのトラフィックを運びます。
Path optimization is not a big issue if the tunnel server is close to the client on the natural path between the client and its peers. However, if the tunnel server is operated by a third party, this third party will have to bear the cost of provisioning the bandwidth used by the client. The associated costs can be significant.
トンネルサーバーがクライアントとそのピアの間の自然なパスでクライアントに近い場合、パスの最適化は大きな問題ではありません。ただし、トンネルサーバーが第三者によって操作されている場合、この第三者は、クライアントが使用する帯域幅をプロビジョニングするコストを負担する必要があります。関連するコストは大きくなる可能性があります。
These costs are largely absent when the tunnels are configured by the same ISP that provides the IPv4 service. The ISP can place the tunnel end-points close to the client, i.e., mostly on the direct path between the client and its peers.
これらのコストは、トンネルがIPv4サービスを提供するのと同じISPによって構成されている場合、ほとんど存在しません。ISPは、トンネルのエンドポイントをクライアントの近くに配置できます。つまり、主にクライアントとそのピアの間の直接的なパスに配置できます。
The economics arguments related to path optimization favor either configured tunnels provided by the local ISP or automatic tunneling regardless of the co-operation of ISPs. However, automatic solutions require that relays be configured throughout the Internet. If a host that obtained connectivity through an automatic tunnel service wants to communicate with a "native" host or with a host using a configured tunnel, it will need to use a relay service, and someone will have to provide and pay for that service. We cannot escape economic considerations for the deployment of these relays.
パスの最適化に関連する経済学の議論は、ISPの協力に関係なく、ローカルISPによって提供される構成されたトンネルまたは自動トンネルのいずれかを支持します。ただし、自動ソリューションでは、リレーをインターネット全体で構成する必要があります。自動トンネルサービスを介して接続を取得したホストが「ネイティブ」ホストまたは構成されたトンネルを使用してホストと通信する必要がある場合、リレーサービスを使用する必要があり、誰かがそのサービスを提供して支払う必要があります。これらのリレーの展開に関する経済的考慮事項から逃れることはできません。
It is desirable to locate these relays close to the "native host". During the transition period, the native ISPs have an interest in providing a relay service for use by their native subscribers. Their subscribers will enjoy better connectivity, and will therefore be happier. Providing the service does not result in much extra bandwidth requirement: the packets are exchanged between the local subscribers and the Internet; they are simply using a v6-v4 path instead of a v6-v6 path. (The native ISPs do not have an incentive to provide relays for general use; they are expected to restrict access to these relays to their customers.)
これらのリレーを「ネイティブホスト」の近くに見つけることが望ましいです。移行期間中、ネイティブISPは、ネイティブの加入者が使用するリレーサービスを提供することに関心があります。彼らの加入者はより良い接続性を享受するので、より幸せになります。このサービスを提供しても、それほど余分な帯域幅要件はありません。パケットは、ローカル加入者とインターネットの間で交換されます。彼らは、V6-V6パスの代わりにV6-V4パスを単に使用しています。（ネイティブISPには、一般的な使用のためのリレーを提供するインセンティブがありません。これらのリレーへのアクセスを顧客へのアクセスを制限することが期待されています。）
We should note however that different automatic tunneling techniques have different deployment conditions.
ただし、異なる自動トンネリング技術の展開条件は異なることに注意してください。
In an early deployment of the Teredo service by Microsoft, the relays are provided by the native (or 6to4) hosts themselves. The native or 6to4 hosts are de-facto "multi-homed" to native and Teredo hosts, although they never publish a Teredo address in the DNS or otherwise. When a native host communicates with a Teredo host, the first packets are exchanged through the native interface and relayed by the Teredo server, while the subsequent packets are tunneled "end-to-end" over IPv4 and UDP. This enables deployment of Teredo without having to field an infrastructure of relays in the network.
MicrosoftによるTeredoサービスの早期展開では、リレーはネイティブ（または6to4）ホストによって提供されます。ネイティブまたは6to4のホストは、DNSまたはその他のテレドアドレスを公開することはありませんが、ネイティブおよびテレドのホストにデファクト「マルチホーム」です。ネイティブホストがTeredoホストと通信すると、最初のパケットはネイティブインターフェイスを介して交換され、Teredoサーバーによって中継されますが、後続のパケットはIPv4およびUDPで「エンドツーエンド」をトンネル化されます。これにより、ネットワーク内のリレーのインフラストラクチャをフィールドに入れることなく、Teredoの展開が可能になります。
This type of solution carries the implicit risk of developing two parallel IPv6 Internets, one native and one using Teredo: in order to communicate with a Teredo-only host, a native IPv6 host has to implement a Teredo interface. The Teredo implementations try to mitigate this risk by always preferring native paths when available, but a true mitigation requires that native hosts do not have to implement the transition technology. This requires cooperation from the IPv6 ISP, who will have to support the relays. An IPv6 ISP that really wants to isolate its customers from the Teredo technology can do that by providing native connectivity and a Teredo relay. The ISP's customers will not need to implement their own relay.
このタイプのソリューションは、2つの並列IPv6インターネットを開発するという暗黙のリスクを伴います。1つはネイティブとテレドを使用して1つを使用します。Teredoのみのホストと通信するために、ネイティブIPv6ホストはTeredoインターフェイスを実装する必要があります。Teredoの実装は、利用可能な場合は常にネイティブパスを好むことにより、このリスクを軽減しようとしますが、真の緩和では、ネイティブホストが移行技術を実装する必要がないことが必要です。これには、リレーをサポートする必要があるIPv6 ISPからの協力が必要です。Teredoテクノロジーから顧客を隔離したいIPv6 ISPは、ネイティブの接続とTeredoリレーを提供することでそれを行うことができます。ISPの顧客は、独自のリレーを実装する必要はありません。
Communication between 6to4 networks and native networks uses a different structure. There are two relays, one for each direction of communication. The native host sends its packets through the nearest 6to4 router, i.e., the closest router advertising the 2002::/16 prefix through the IPv6 routing tables; the 6to4 network sends its packet through a 6to4 relay that is either explicitly configured or discovered through the 6to4 anycast address 192.88.99.1 [6TO4ANYCAST]. The experience so far is that simple 6to4 routers are easy to deploy, but 6to4 relays are scarce. If there are too few relays, these relays will create a bottleneck. The communications between 6to4 and native networks will be slower than the direct communications between 6to4 hosts. This will create an incentive for native hosts to somehow "multi-home" to 6to4, de facto creating two parallel Internets, 6to4 and native. This risk will only be mitigated if there is a sufficient deployment of 6to4 relays.
6to4ネットワークとネイティブネットワーク間の通信は、異なる構造を使用します。2つのリレーがあります。1つは通信方向です。ネイティブホストは、最寄りの6to4ルーター、つまりIPv6ルーティングテーブルを介して2002年::/16プレフィックスを宣伝する最も近いルーターを介してパケットを送信します。6to4ネットワークは、6to4 Anycastアドレス192.88.99.1 [6to4anycast]を介して明示的に構成または検出された6to4リレーを介してパケットを送信します。これまでの経験は、単純な6to4ルーターが展開しやすいことですが、6to4リレーは不足しています。リレーが少なすぎる場合、これらのリレーはボトルネックを作成します。6to4とネイティブネットワーク間の通信は、6〜4ホスト間の直接通信よりも遅くなります。これにより、ネイティブホストが何らかの形で6to4に「マルチホーム」にインセンティブを作成し、2つの並列インターネット、6to4とネイティブを作成します。このリスクは、6to4リレーの十分な展開がある場合にのみ軽減されます。
The configured tunnel solutions do not carry this type of risk.
構成されたトンネルソリューションは、このタイプのリスクを負いません。
A related issue is the lifespan of the transition solutions. Since automatic tunneling technologies enable an automatic deployment, there is a risk that some hosts never migrate out of the transition. The risk is arguably less for explicit tunnels: the ISPs who provide the tunnels have an incentive to replace them with a native solution as soon as possible.
関連する問題は、遷移ソリューションの寿命です。自動トンネリング技術は自動展開を可能にするため、一部のホストが移行から移行しないリスクがあります。明示的なトンネルのリスクは間違いなく少ないです。トンネルを提供するISPは、できるだけ早くネイティブソリューションに置き換えるインセンティブを持っています。
Many implementations of automatic transition technologies incorporate an "implicit sunset" mechanism: the hosts will not configure a transition technology address if they have native connectivity; the address selection mechanisms will prefer native addresses when available. The transition technologies will stop being used eventually, when native connectivity has been deployed everywhere. However, the "implicit sunset" mechanism does not provide any hard guarantee that transition will be complete at a certain date.
自動遷移技術の多くの実装には、「暗黙の日没」メカニズムが組み込まれています。ホストは、ネイティブ接続がある場合、遷移テクノロジーアドレスを構成しません。アドレス選択メカニズムは、利用可能な場合、ネイティブアドレスを好みます。ネイティブ接続がどこにでも展開されている場合、遷移テクノロジーは最終的に使用されるのを止めます。ただし、「暗黙の日没」メカニズムは、特定の日付で遷移が完了するという厳しい保証を提供しません。
Yet, the support of transition technologies has a cost for the entire network: native IPv6 ISPS have to support relays in order to provide good performance and avoid the "parallel Internet" syndrome. These costs may be acceptable during an initial deployment phase, but they can certainly not be supported for an indefinite period. The "implicit sunset" mechanisms may not be sufficient to guarantee a finite lifespan of the transition.
しかし、トランジションテクノロジーのサポートには、ネットワーク全体にコストがかかります。ネイティブIPv6 ISPは、優れたパフォーマンスを提供し、「並列インターネット」症候群を回避するためにリレーをサポートする必要があります。これらのコストは、最初の展開段階で受け入れられる可能性がありますが、無期限にサポートされることはありません。「暗黙の夕日」メカニズムは、遷移の有限寿命を保証するのに十分ではないかもしれません。
During the transition, some hosts will be located behind IPv4 NATs. In order to participate in the transition, these hosts will have to use a tunneling mechanism designed to traverse NAT.
移行中、一部のホストはIPv4 NATの後ろに配置されます。移行に参加するために、これらのホストはNATを横断するように設計されたトンネルメカニズムを使用する必要があります。
We may ask whether NAT traversal should be a generic property of any transition technology, or whether it makes sense to develop two types of technologies, some "NAT capable" and some not. An important question is also which kinds of NAT boxes one should be able to traverse. One should probably also consider whether it is necessary to build an IPv6 specific NAT traversal mechanism, or whether it is possible to combine an existing IPv4 NAT traversal mechanism with some form of IPv6 in IPv4 tunneling. There are many IPv4 NAT traversal mechanisms; thus one may ask whether these need re-invention, especially when they are already complex.
NAT Traversalが移行技術の一般的な特性であるべきか、それとも2種類のテクノロジーを開発することが理にかなっているかどうかを尋ねることができます。また、重要な質問は、どの種類のNATボックスを通過できるかです。また、IPv6固有のNATトラバーサルメカニズムを構築する必要があるかどうか、または既存のIPv4 NATトラバーサルメカニズムとIPv4トンネリングの何らかの形のIPv6を組み合わせることができるかどうかを検討する必要があります。多くのIPv4 NATトラバーサルメカニズムがあります。したがって、特にすでに複雑な場合、これらが再発明が必要かどうかを尋ねることができます。
A related question is whether the NAT traversal technology should use automatic tunnels or configured tunnels. We saw in the previous section that one can argue both sides of this issue. In fact, there are already deployed automatic and configured solutions, so the reality is that we will probably see both.
関連する質問は、NATトラバーサル技術が自動トンネルまたは構成されたトンネルを使用する必要があるかどうかです。前のセクションで、この問題の両側を議論できることを見ました。実際、すでに展開されている自動および構成されたソリューションが展開されているため、現実には、おそらく両方が表示されるということです。
NAT traversal technologies generally involve encapsulating IPv6 packets inside a transport protocol that is known to traverse NAT, such as UDP or TCP. These transport technologies require significantly more overhead than the simple tunneling over IPv4 used in 6to4 or in IPv6 in IPv4 tunnels. For example, solutions based on UDP require the frequent transmission of "keep alive" packets to maintain a "mapping" in the NAT; solutions based on TCP may not require such a mechanism, but they incur the risk of "head of queue blocking", which may translate in poor performance. Given the difference in performance, it makes sense to consider two types of transition technologies, some capable of traversing NAT and some aiming at the best performance.
NATトラバーサルテクノロジーには、一般に、UDPやTCPなどのNATを横断することが知られているトランスポートプロトコル内のIPv6パケットのカプセル化が含まれます。これらの輸送技術は、6to4またはIPv4トンネルのIPv6で使用されるIPv4を介した単純なトンネルよりも、大幅に多くのオーバーヘッドを必要とします。たとえば、UDPに基づくソリューションでは、NATの「マッピング」を維持するために「Keep Alive」パケットを頻繁に送信する必要があります。TCPに基づくソリューションはそのようなメカニズムを必要としないかもしれませんが、「キューの責任者の責任者」のリスクがあり、パフォーマンスの低下に翻訳される可能性があります。パフォーマンスの違いを考えると、2種類の移行技術を検討することは理にかなっています。これは、NATを通過することができるものと、最高のパフォーマンスを目指すものです。
There are many kinds of NAT on the market. Different models implement different strategies for address and port allocations, and different types of timers. It is desirable to find solutions that cover "almost all" models of NAT.
市場には多くの種類のNATがあります。異なるモデルは、アドレスとポートの割り当て、およびさまざまなタイプのタイマーのためにさまざまな戦略を実装しています。NATの「ほぼすべての」モデルをカバーするソリューションを見つけることが望ましい。
A configured tunnel solution will generally make fewer hypotheses on the behavior of the NAT than an automatic solution. The configured solutions only need to establish a connection between an internal node and a server; this communication pattern is supported by pretty much all NAT configurations. The variability will come from the type of transport protocols that the NAT supports, especially when the NAT also implements "firewall" functions. Some models will allow establishment of a single "protocol 41" tunnel, while some may prevent this type of transmission. Some models will allow UDP transmission, while other may only allow TCP, or possibly HTTP.
構成されたトンネルソリューションは、一般に、自動ソリューションよりもNATの動作に関する仮説が少なくなります。構成されたソリューションは、内部ノードとサーバーの間の接続を確立するだけでよいです。この通信パターンは、ほとんどすべてのNAT構成によってサポートされています。変動性は、特にNATが「ファイアウォール」機能を実装する場合、NATがサポートする輸送プロトコルの種類から生じます。一部のモデルでは、単一の「プロトコル41」トンネルを確立することができますが、一部のモデルはこのタイプの伝送を防ぐことができます。一部のモデルではUDP伝送を許可しますが、他のモデルはTCP、または場合によってはHTTPのみを許可する場合があります。
The automatic solutions have to rely on a "lowest common denominator" that is likely to be accepted by most models of NAT. In practice, this common denominator is UDP. UDP based NAT traversal is required by many applications, e.g., networked games or voice over IP. The experience shows that most recent "home routers" are designed to support these applications. In some edge cases, the automatic solutions will require explicit configuration of a port in the home router, using the so-called "DMZ" functions; however, these functions are hard to use in an "unmanaged network" scenario.
自動ソリューションは、NATのほとんどのモデルで受け入れられる可能性が高い「最も低い一般的な分母」に依存する必要があります。実際には、この一般的な分母はUDPです。UDPベースのNATトラバーサルは、多くのアプリケーション、たとえばネットワーク化されたゲームやVoice over IPで必要です。このエクスペリエンスは、最新の「ホームルーター」がこれらのアプリケーションをサポートするように設計されていることを示しています。一部のエッジの場合、自動ソリューションでは、いわゆる「DMZ」関数を使用して、ホームルーターのポートの明示的な構成が必要です。ただし、これらの機能は、「管理されていないネットワーク」シナリオで使用するのが困難です。
NAT traversal is not a problem for IPv6 alone. Many IPv4 applications have developed solutions, or kludges, to enable communication across a NAT.
NATトラバーサルは、IPv6だけでは問題ではありません。多くのIPv4アプリケーションは、NAT間の通信を可能にするためにソリューションまたはKludgesを開発しました。
Virtual Private Networks are established by installing tunnels between VPN clients and VPN servers. These tunnels are designed today to carry IPv4, but in many cases could easily carry IPv6. For example, the proposed IETF standard, L2TP, includes a PPP layer that can encapsulate IPv6 as well as IPv4. Several NAT models are explicitly designed to pass VPN traffic, and several VPN solutions have special provisions to traverse NAT. When we study the establishment of configured tunnels through NAT, it makes a lot of sense to consider existing VPN solutions.
仮想プライベートネットワークは、VPNクライアントとVPNサーバーの間にトンネルをインストールすることにより確立されます。これらのトンネルは現在、IPv4を運ぶように設計されていますが、多くの場合、IPv6を簡単に運ぶことができます。たとえば、提案されているIETF標準L2TPには、IPv6とIPv4をカプセル化できるPPPレイヤーが含まれています。いくつかのNATモデルは、VPNトラフィックに合格するように明示的に設計されており、いくつかのVPNソリューションにはNATを横断するための特別な規定があります。NATを介して構成されたトンネルの確立を研究するとき、既存のVPNソリューションを検討することは非常に理にかなっています。
[STUN] is a protocol designed to facilitate the establishment of UDP associations through NAT, by letting nodes behind NAT discover their "external" address. The same function is required for automatic tunneling through NAT, and one could consider reusing the STUN specification as part of an automatic tunneling solution. However, the automatic solutions also require a mechanism of bubbles to establish the initial path through a NAT. This mechanism is not present in STUN. It is not clear that a combination of STUN and a bubble mechanism would have a technical advantage over a solution specifically designed for automatic tunneling through NAT.
[Stun]は、NATの背後にノードが「外部」アドレスを発見できるようにすることにより、NATを介したUDP関連の確立を促進するように設計されたプロトコルです。NATを介した自動トンネリングにも同じ関数が必要であり、自動トンネルソリューションの一部としてSTUN仕様を再利用することを検討できます。ただし、自動ソリューションには、NATを通る初期パスを確立するための気泡のメカニズムも必要です。このメカニズムはスタンには存在しません。スタンとバブルメカニズムの組み合わせが、NATを介した自動トンネルのために特別に設計されたソリューションよりも技術的な利点があることは明らかではありません。
The previous sections make the case for the development of four transition mechanism, covering the following 4 configurations:
以前のセクションでは、次の4つの構成をカバーする4つの遷移メカニズムの開発をお勧めします。
- Configured tunnel over IPv4 in the absence of NAT; - Automatic tunnel over IPv4 in the absence of NAT; - Configured tunnel across a NAT; - Automatic tunnel across a NAT.
- NATの非存在下でIPv4上に構成されたトンネル。-NATがない場合のIPv4上の自動トンネル。-NATを横切るトンネルを構成しました。 - ナットを横切る自動トンネル。
Teredo is an example of an already designed solution for automatic tunnels across a NAT; 6to4 is an example of a solution for automatic tunnels over IPv4 in the absence of NAT.
Teredoは、NATを横切る自動トンネル用にすでに設計されたソリューションの例です。6to4は、NATの非存在下でのIPv4を介した自動トンネルのソリューションの例です。
All solutions should be designed to meet generic requirements such as security, scalability, support for reverse name lookup, or simple management. In particular, automatic tunneling solutions may need to be augmented with a special purpose reverse DNS lookup mechanism, while configured tunnel solutions would benefit from an automatic service configuration mechanism.
すべてのソリューションは、セキュリティ、スケーラビリティ、リバースネームルックアップのサポート、または単純な管理などの一般的な要件を満たすように設計する必要があります。特に、特別な目的の逆DNSルックアップメカニズムで自動トンネリングソリューションを増強する必要がある場合がありますが、構成されたトンネルソリューションは自動サービス構成メカニズムの恩恵を受けるでしょう。
In case A, isolated hosts need to acquire some form of connectivity. In this section, we first evaluate how mechanisms already defined or being worked on in the IETF meet this requirement. We then consider the "remaining holes" and recommend specific developments.
ケースAでは、孤立したホストは何らかの形の接続を獲得する必要があります。このセクションでは、最初に、IETFでメカニズムが既に定義されているか、この要件を満たしているかを評価します。次に、「残りの穴」を検討し、特定の開発を推奨します。
In case A, IPv6 capable hosts seek IPv6 connectivity in order to communicate with applications in the global IPv6 Internet. The connectivity requirement can be met using either configured tunnels or automatic tunnels.
ケースAでは、IPv6の有能なホストは、グローバルIPv6インターネットのアプリケーションと通信するためにIPv6接続を求めています。接続要件は、構成されたトンネルまたは自動トンネルのいずれかを使用して満たすことができます。
If the host is located behind a NAT, the tunneling technology should be designed to traverse NAT; tunneling technologies that do not support NAT traversal can obviously be used if the host is not located behind a NAT.
ホストがNATの後ろにある場合、トンネル技術はNATを横断するように設計する必要があります。NATトラバーサルをサポートしないトンネル技術は、ホストがNATの後ろに配置されていない場合、明らかに使用できます。
When the local ISP is willing to provide a configured tunnel solution, we should make it easy for the host in case A to use it. The requirements for such a service will be presented in another document.
ローカルISPが構成されたトンネルソリューションを喜んで提供する場合、ホストがAの使用を容易にする必要があります。このようなサービスの要件は、別のドキュメントで提示されます。
An automatic solution like Teredo appears to be a good fit for providing IPv6 connectivity to hosts behind NAT, in case A of IPv6 deployment. The service is designed for minimizing the cost of deploying the server, which matches the requirement of minimizing the cost of the "supporting infrastructure".
Teredoのような自動ソリューションは、IPv6の展開の場合に備えて、NATの背後にあるホストにIPv6接続を提供するのに適していると思われます。このサービスは、「サポートインフラストラクチャ」のコストを最小限に抑える要件に一致するサーバーの展開コストを最小限に抑えるために設計されています。
A characteristic of case A is that an isolated host acquires global IPv6 connectivity, using either Teredo or an alternative tunneling mechanism. If no precaution is taken, there is a risk of exposing to the global Internet some applications and services that are only expected to serve local hosts, e.g., those located behind the NAT when a NAT is present. Developers and administrators should make sure that the global IPv6 connectivity is restricted to only those applications that are expressly designed for global Internet connectivity. The users should be able to configure which applications get IPv6 connectivity to the Internet and which should not.
ケースAの特徴は、分離されたホストがテレドまたは代替トンネリングメカニズムのいずれかを使用して、グローバルなIPv6接続を取得することです。予防措置が講じられていない場合、グローバルインターネットに、地元のホストにのみサービスを提供することが期待されるアプリケーションやサービス、たとえばNATが存在するときにNATの後ろにあるアプリケーションやサービスを公開するリスクがあります。開発者と管理者は、グローバルIPv6接続が、グローバルなインターネット接続用に明示的に設計されたアプリケーションのみに制限されていることを確認する必要があります。ユーザーは、どのアプリケーションがインターネットへのIPv6接続を取得し、それをすべきではないアプリケーションを構成できる必要があります。
Any solution to the NAT traversal problem is likely to involve relays. There are concerns that improperly designed protocols or improperly managed relays could open new avenues for attacks against Internet services. This issue should be addressed and mitigated in the design of the NAT traversal protocols and in the deployment guides for relays.
NATトラバーサル問題の解決策は、リレーを含む可能性があります。不適切に設計されたプロトコルまたは不適切に管理されたリレーが、インターネットサービスに対する攻撃のための新しい道を開く可能性があるという懸念があります。この問題は、NATトラバーサルプロトコルの設計およびリレーの展開ガイドで対処し、軽減する必要があります。
In case B, we assume that the gateway and the ISP are both dual-stack. The hosts on the local network may be IPv4-only, dual-stack, or IPv6-only. The main requirements are: prefix delegation and name resolution. We also study the potential need for communication between IPv4 and IPv6 hosts, and conclude that a dual-stack approach is preferable.
ケースBでは、ゲートウェイとISPが両方ともデュアルスタックであると仮定します。ローカルネットワークのホストは、IPv4のみ、デュアルスタック、またはIPv6のみです。主な要件は、プレフィックス委任と名前解決です。また、IPv4ホストとIPv6ホスト間の通信の潜在的なニーズを調査し、デュアルスタックアプローチが望ましいと結論付けています。
The gateway must be able to acquire an IPv6 prefix, delegated by the ISP. This can be done through explicit prefix delegation (e.g., [DHCPV6, PREFIXDHCPV6]), or if the ISP is advertising a /64 prefix on the link, such a link can be extended by the use of an ND proxy or a bridge.
ゲートウェイは、ISPによって委任されたIPv6プレフィックスを取得できる必要があります。これは、明示的なプレフィックス委任（例：[dhcpv6、prefixdhcpv6]）を介して行うことができます。または、ISPがリンクにA /64プレフィックスを宣伝している場合、そのようなリンクはNDプロキシまたはブリッジを使用して拡張できます。
An ND proxy can also be used to extend a /64 prefix to multiple physical links of different properties (e.g., an Ethernet and a PPP link).
NDプロキシを使用して、A /64プレフィックスを異なるプロパティの複数の物理リンク（イーサネットやPPPリンクなど）に拡張することもできます。
A /64 subnet can be extended to span multiple physical links using a bridge or ND proxy. Bridges can be used when bridging multiple similar media (mainly, Ethernet segments). On the other hand, an ND proxy must be used if a /64 prefix has to be shared across media (e.g., an upstream PPP link and a downstream Ethernet), or if an interface cannot be put into promiscuous mode (e.g., an upstream wireless link).
A /64サブネットは、ブリッジまたはNDプロキシを使用して複数の物理リンクにまたがるように拡張できます。複数の類似メディア（主にイーサネットセグメント）を橋渡しするときに、ブリッジを使用できます。一方、A /64プレフィックスをメディア間で共有する必要がある場合（例：上流のPPPリンクとダウンストリームイーサネット）、またはインターフェイスを無差別モードに配置できない場合（例えば、アップストリームに配置できない場合は、NDプロキシを使用する必要があります。ワイヤレスリンク）。
Extending a single subnet to span from the ISP to all of the unmanaged network is not recommended, and prefix delegation should be used when available. However, sometimes it is unavoidable. In addition, sometimes it's necessary to extend a subnet in the unmanaged network, at the "customer-side" of the gateway, and changing the topology using routing might require too much expertise.
ISPからすべての管理されていないネットワークにスパンするために単一のサブネットを拡張することは推奨されず、利用可能な場合はプレフィックス委任を使用する必要があります。ただし、避けられないこともあります。さらに、ゲートウェイの「顧客側」に、管理されていないネットワークにサブネットを拡張する必要がある場合があり、ルーティングを使用してトポロジを変更するには、専門知識があまりにも多く必要になる場合があります。
The ND proxy method results in the sharing of the same prefix over several links, a procedure generally known as "multi-link subnet". This sharing has effects on neighbor discovery protocols, and possibly also on other protocols such as LLMNR [LLMNR] that rely on "link local multicast". These effects need to be carefully studied.
NDプロキシメソッドの結果、いくつかのリンクで同じプレフィックスが共有されます。これは、一般に「マルチリンクサブネット」として知られています。この共有は、近隣発見プロトコルに影響を及ぼし、場合によっては「Link Local Multicast」に依存するLLMNR [LLMNR]などの他のプロトコルにも影響します。これらの効果は慎重に研究する必要があります。
Several networks have already started using an explicit prefix delegation mechanism using DHCPv6. In this mechanism, the gateway uses a DHCP request to obtain an adequate prefix from a DHCP server managed by the Internet Service Provider. The DHCP request is expected to carry proper identification of the gateway, which enables the ISP to implement prefix delegation policies. It is expected that the ISP assigns a /48 to the customer. The gateway should automatically assign /64s out of this /48 to its internal links.
いくつかのネットワークは、DHCPV6を使用した明示的なプレフィックス委任メカニズムの使用をすでに開始しています。このメカニズムでは、ゲートウェイはDHCP要求を使用して、インターネットサービスプロバイダーが管理するDHCPサーバーから適切なプレフィックスを取得します。DHCP要求は、ISPがプレフィックス委任ポリシーを実装できるようにするゲートウェイの適切な識別を実施することが期待されています。ISPはA /48を顧客に割り当てることが期待されています。ゲートウェイは、この /48から /64を内部リンクに自動的に割り当てる必要があります。
DHCP is insecure unless authentication is used. This may be a particular problem if the link between gateway and ISP is shared by multiple subscribers. DHCP specification includes authentication options, but the operational procedures for managing the keys and methods for sharing the required information between the customer and the ISP are unclear. To be secure in such an environment in practice, the practical details of managing the DHCP authentication need to be analyzed.
認証を使用しない限り、DHCPは安全ではありません。これは、GatewayとISPの間のリンクが複数の加入者によって共有されている場合、特定の問題になる可能性があります。DHCP仕様には認証オプションが含まれていますが、顧客とISPの間で必要な情報を共有するためにキーと方法を管理するための運用手順は不明です。このような環境で確保するには、DHCP認証の管理の実際の詳細を分析する必要があります。
The ND proxy and DHCP methods appear to have complementary domains of application. ND proxy is a simple method that corresponds well to the "informal sharing" of a link, while explicit delegation provides strong administrative control. Both methods require development: specify the interaction with neighbor discovery for ND proxy; provide security guidelines for explicit delegation.
NDプロキシおよびDHCPメソッドには、アプリケーションの補完的なドメインがあるように見えます。NDプロキシは、リンクの「非公式の共有」によく対応する単純な方法であり、明示的な委任は強力な管理管理を提供します。どちらの方法でも開発が必要です。NDプロキシの近隣発見との相互作用を指定します。明示的な代表団のセキュリティガイドラインを提供します。
During the transition phase from IPv4 to IPv6, there will be IPv4- only, dual-stack, and IPv6-only nodes. In theory, there may be a need to provide some interconnection services so that IPv4-only and IPv6-only hosts can communicate. However, it is hard to develop a translation service that does not have unwanted side effects on the efficiency or the security of communications. As a consequence, the authors recommend that, if a device requires communication with IPv4-only hosts, this device implements an IPv4 stack. The only devices that should have IPv6-only connectivity are those that are intended to only communicate with IPv6 hosts.
IPv4からIPv6への遷移フェーズでは、IPv4-のみ、デュアルスタック、IPv6のみのノードがあります。理論的には、IPv4のみのホストとIPv6のみのホストが通信できるように、相互接続サービスを提供する必要があるかもしれません。ただし、コミュニケーションの効率やセキュリティに望ましくない副作用がない翻訳サービスを開発することは困難です。結果として、著者は、デバイスがIPv4のみのホストとの通信を必要とする場合、このデバイスがIPv4スタックを実装することを推奨しています。IPv6のみの接続性を持つ必要があるデバイスは、IPv6ホストとのみ通信することを目的としたデバイスです。
There are three types of name resolution services that should be provided in case B: local IPv6 capable hosts must be able to obtain the IPv6 addresses of correspondent hosts on the Internet, they should be able to publish their address if they want to be accessed from the Internet, and they should be able to obtain the IPv6 address of other local IPv6 hosts. These three problems are described in the next sections. Operational considerations and issues with IPv6 DNS are analyzed in [DNSOPV6].
ケースBで提供される必要のある名前解像度サービスには、ローカルIPv6対応ホストがインターネット上の特派員ホストのIPv6アドレスを取得できる必要があります。インターネット、そして彼らは他のローカルIPv6ホストのIPv6アドレスを取得できるはずです。これらの3つの問題については、次のセクションで説明します。IPv6 DNSの運用上の考慮事項と問題は、[DNSOPV6]で分析されます。
In an unmanaged environment, IPv4 hosts usually obtain the address of the local DNS resolver through DHCPv4; the DHCPv4 service is generally provided by the gateway. The gateway will also use DHCPv4 to obtain the address of a suitable resolver from the local Internet service provider.
管理されていない環境では、IPv4ホストは通常、DHCPV4を介してローカルDNSリゾルバーのアドレスを取得します。DHCPV4サービスは通常、ゲートウェイによって提供されます。また、ゲートウェイはDHCPV4を使用して、ローカルインターネットサービスプロバイダーから適切なリゾルバーのアドレスを取得します。
The DHCPv4 solution will suffice in practice for the gateway and also for the dual-stack hosts. There is evidence that DNS servers accessed over IPv4 can serve arbitrary DNS records, including AAAA records.
DHCPV4ソリューションでは、ゲートウェイとデュアルスタックホストにも実際に十分です。IPv4を介してアクセスされたDNSサーバーがAAAAレコードを含む任意のDNSレコードを提供できるという証拠があります。
Just using DHCPv4 will not be an adequate solution for IPv6-only local hosts. The DHCP working group has defined how to use (stateless) DHCPv6 to obtain the address of the DNS server [DNSDHCPV6]. DHCPv6 and several other possibilities are being looked at in the DNSOP Working Group.
DHCPV4を使用するだけでは、IPv6のみのローカルホストにとって適切なソリューションではありません。DHCPワーキンググループは、DNSサーバー[DNSDHCPV6]のアドレスを取得するために（ステートレス）DHCPV6の使用方法を定義しています。DHCPV6および他のいくつかの可能性がDNSOPワーキンググループで検討されています。
IPv6 capable hosts may be willing to provide services accessible from the global Internet. They will thus need to publish their address in a server that is publicly available. IPv4 hosts in unmanaged networks have a similar problem today, which they solve using one of three possible solutions:
IPv6の有能なホストは、グローバルなインターネットからアクセス可能なサービスを喜んで提供する場合があります。したがって、彼らは公開されているサーバーでアドレスを公開する必要があります。管理されていないネットワークのIPv4ホストは、今日も同様の問題を抱えており、3つの可能なソリューションのいずれかを使用して解決します。
* Manual configuration of a stable address in a DNS server;
* Dynamic configuration using the standard dynamic DNS protocol;
* Dynamic configuration using an ad hoc protocol.
* DNSサーバー内の安定したアドレスの手動構成。
*標準の動的DNSプロトコルを使用した動的構成。
*アドホックプロトコルを使用した動的構成。
Manual configuration of stable addresses is not satisfactory in an unmanaged IPv6 network: the prefix allocated to the gateway may or may not be stable, and in any case, copying long hexadecimal strings through a manual procedure is error prone.
安定したアドレスの手動構成は、管理されていないIPv6ネットワークでは満足のいくものではありません。ゲートウェイに割り当てられたプレフィックスは安定している場合と安定していない場合があり、いずれにせよ、手動手順を通じて長い16進列の文字列をコピーするとエラーが発生します。
Dynamic configuration using the same type of ad hoc protocols that are common today is indeed possible, but the IETF should encourage the use of standard solutions based on Dynamic DNS (DDNS).
今日一般的な同じタイプのアドホックプロトコルを使用した動的構成は実際に可能ですが、IETFは動的DNS（DDN）に基づく標準ソリューションの使用を促進する必要があります。
There are two possible ways of resolving the IPv6 addresses of local hosts: one may either publish the IPv6 addresses in a DNS server for the local domain, or one may use a peer-to-peer address resolution protocol such as LLMNR.
ローカルホストのIPv6アドレスを解決する方法は2つあります。1つは、ローカルドメイン用のDNSサーバーでIPv6アドレスを公開するか、LLMNRなどのピアツーピアアドレス解像度プロトコルを使用することができます。
When a DNS server is used, this server could in theory be located anywhere on the Internet. There is however a very strong argument for using a local server, which will remain reachable even if the network connectivity is down.
DNSサーバーを使用すると、このサーバーは理論上、インターネット上のどこにでも配置できます。ただし、ローカルサーバーを使用するための非常に強力な議論があります。これは、ネットワーク接続が低下していても到達可能なままです。
The use of a local server requires that IPv6 capable hosts discover this server, as explained in 4.3.1, and then that they use a protocol such as DDNS to publish their IPv6 addresses to this server. In practice, the DNS address discovered in 4.3.1 will often be the address of the gateway itself, and the local server will thus be the gateway.
ローカルサーバーを使用するには、4.3.1で説明されているように、IPv6対応ホストがこのサーバーを発見し、DDNSなどのプロトコルを使用してIPv6アドレスをこのサーバーに公開する必要があります。実際には、4.3.1で発見されたDNSアドレスは、多くの場合、ゲートウェイ自体のアドレスとなり、ローカルサーバーはゲートウェイになります。
An alternative to using a local server is LLMNR, which uses a multicast mechanism to resolve DNS requests. LLMNR does not require any service from the gateway, and also does not require that hosts use DDNS. An important problem is that some networks only have limited support for multicast transmission, for example, multicast transmission on 802.11 network is error prone. However, unmanaged networks also use multicast for neighbor discovery [NEIGHBOR]; the requirements of ND and LLMNR are similar; if a link technology supports use of ND, it can also enable use of LLMNR.
ローカルサーバーの使用に代わるものはLLMNRです。これは、マルチキャストメカニズムを使用してDNS要求を解決します。LLMNRはゲートウェイからのサービスを必要とせず、ホストがDDNを使用することも必要ありません。重要な問題は、一部のネットワークがマルチキャスト伝送のサポートしか限られていないことです。たとえば、802.11ネットワークのマルチキャスト伝送はエラーが発生しやすいことです。ただし、管理されていないネットワークは、マルチキャストに近隣発見にも使用されます[近隣]。NDとLLMNRの要件は類似しています。リンクテクノロジーがNDの使用をサポートする場合、LLMNRの使用を可能にすることもできます。
The IETF should quickly provide a recommended procedure for provisioning the DNS resolver in IPv6-only hosts.
IETFは、IPv6のみのホストでDNSリゾルバーをプロビジョニングするための推奨手順をすばやく提供する必要があります。
The most plausible candidate for local name resolution appears to be LLMNR; the IETF should quickly proceed to the standardization of that protocol.
ローカル名の解像度の最ももっともらしい候補は、LLMNRのようです。IETFは、そのプロトコルの標準化にすばやく進める必要があります。
The case B solutions provide global IPv6 connectivity to the local hosts. Removing the limit to connectivity imposed by NAT is both a feature and a risk. Implementations should carefully limit global IPv6 connectivity to only those applications that are specifically designed to operate on the global Internet. Local applications, for example, could be restricted to only use link-local addresses, or addresses whose most significant bits match the prefix of the local subnet, e.g., a prefix advertised as "on link" in a local router advertisement. There is a debate as to whether such restrictions should be "per-site" or "per-link", but this is not a serious issue when an unmanaged network is composed of a single link.
ケースBソリューションは、ローカルホストにグローバルなIPv6接続を提供します。NATによって課される接続の制限を削除することは、機能とリスクの両方です。実装は、グローバルIPv6接続を慎重に制限し、グローバルインターネットで動作するように特別に設計されたアプリケーションのみに制限されます。たとえば、ローカルアプリケーションは、Link-Localアドレスのみを使用することに制限される場合があります。または、最も重要なビットがローカルサブネットのプレフィックスに一致するアドレス、たとえばローカルルーター広告で「オンリンク」として宣伝されている接頭辞です。そのような制限が「一度」であるか「リンクごと」であるべきかについては議論がありますが、これは、管理されていないネットワークが単一のリンクで構成されている場合、深刻な問題ではありません。
Case C is very similar to case B, the difference being that the ISP is not dual-stack. The gateway must thus use some form of tunneling mechanism to obtain IPv6 connectivity, and an address prefix.
ケースCはケースBと非常に似ており、違いはISPがデュアルスタックではないことです。したがって、ゲートウェイは、何らかの形のトンネルメカニズムを使用して、IPv6接続とアドレスプレフィックスを取得する必要があります。
A simplified form of case B is a single host with a global IPv4 address, i.e., with a direct connection to the IPv4 Internet. This host will be able to use the same tunneling mechanisms as a gateway.
ケースBの単純化された形式は、グローバルIPv4アドレス、つまりIPv4インターネットに直接接続する単一のホストです。このホストは、ゲートウェイと同じトンネルメカニズムを使用できます。
Connectivity in case C requires some form of tunneling of IPv6 over IPv4. The various tunneling solutions are discussed in section 2.
Case Cの接続性Cには、IPv4を介したIPv6の何らかの形態のトンネルが必要です。さまざまなトンネリングソリューションについて説明します。セクション2で説明します。
The requirements of case C can be solved by an automatic tunneling mechanism such as 6to4 [6TO4]. An alternative may be the use of a configured tunnels mechanism [TUNNELS], but as the local ISP is not IPv6-enabled, this may not be feasible. The practical conclusion of our analysis is that "upgraded gateways" will probably support the 6to4 technology, and will have an optional configuration option for "configured tunnels".
ケースCの要件は、6to4 [6to4]などの自動トンネルメカニズムによって解決できます。別の方法は、構成されたトンネルメカニズム[トンネル]の使用ですが、ローカルISPはIPv6対応ではないため、これは実行可能ではない場合があります。分析の実際的な結論は、「アップグレードされたゲートウェイ」がおそらく6to4テクノロジーをサポートし、「構成されたトンネル」のオプションの構成オプションがあることです。
The tunnel broker technology should be augmented to include support for some form of automatic configuration.
トンネルブローカー技術は、何らかの形の自動構成のサポートを含めるように拡張する必要があります。
Due to concerns with potential overload of public 6to4 relays, the 6to4 implementations should include a configuration option that allows the user to take advantage of specific relays.
パブリック6to4リレーの潜在的な過負荷に関する懸念により、6to4実装には、ユーザーが特定のリレーを利用できるようにする構成オプションを含める必要があります。
In case D, the ISP only provides IPv6 services.
ケースDでは、ISPはIPv6サービスのみを提供します。
We expect IPv6 addressing in case D to proceed similarly to case B, i.e., use either an ND proxy or explicit prefix delegation through DHCPv6 to provision an IPv6 prefix on the gateway.
ケースDにアドレス指定するIPv6がケースBに同様に進行することを期待しています。つまり、DHCPV6を介したNDプロキシまたは明示的なプレフィックス委任のいずれかを使用して、ゲートウェイにIPv6プレフィックスを提供します。
Local IPv4 capable hosts may still want to access IPv4-only services. The proper way to do this for dual-stack nodes in the unmanaged network is to develop a form of "IPv4 over IPv6" tunneling. There are no standardized solutions and the IETF has devoted very little effort to this issue, although there is ongoing work with [DSTM] and [TSP]. A solution needs to be standardized. The standardization will have to cover configuration issues, i.e., how to provision the IPv4 capable hosts with the address of the local IPv4 tunnel servers.
ローカルIPv4の有能なホストは、IPv4のみのサービスにアクセスしたい場合があります。管理されていないネットワークでデュアルスタックノードに対してこれを行う適切な方法は、「IPv4 over IPv6」トンネルの形式を開発することです。標準化されたソリューションはなく、IETFは[DSTM]および[TSP]で進行中の作業がありますが、この問題にほとんど努力していません。ソリューションを標準化する必要があります。標準化は、構成の問題をカバーする必要があります。つまり、IPv4対応ホストにローカルIPv4トンネルサーバーのアドレスをプロビジョニングする方法です。
Naming requirements are similar to case B, with one difference: the gateway cannot expect to use DHCPv4 to obtain the address of the DNS resolver recommended by the ISP.
命名要件はケースBに似ており、1つの違いがあります。ゲートウェイは、DHCPV4を使用してISPが推奨するDNSリゾルバーのアドレスを取得することを期待できません。
After a careful analysis of the possible solutions, we can list a set of recommendations for the V6OPS working group:
可能なソリューションを慎重に分析した後、V6OPSワーキンググループの一連の推奨事項をリストできます。
1. To meet case A and case C requirements, we need to develop, or continue to develop, four types of tunneling technologies: automatic tunnels without NAT traversal such as [6TO4], automatic tunnels with NAT traversal such as [TEREDO], configured tunnels without NAT traversal such as [TUNNELS, TSP], and configured tunnels with NAT traversal.
1. ケースAおよびケースCの要件を満たすには、4種類のトンネル技術を開発または開発し続ける必要があります。[6TO4]などのNATトラバーサルのない自動トンネル、[Teredo]などのNATトラバーサルを持つ自動トンネル、構成されたトンネルなしで構成されたトンネル[トンネル、TSP]などのNATトラバーサル、およびNATトラバーサルでトンネルを構成しました。
2. To facilitate the use of configured tunnels, we need a standardized way for hosts or gateways to discover the tunnel server or tunnel broker that may have been configured by the local ISP.
2. 構成されたトンネルの使用を容易にするには、ホストまたはゲートウェイがローカルISPによって構成された可能性のあるトンネルサーバーまたはトンネルブローカーを発見するための標準化された方法が必要です。
3. To meet case B "informal prefix sharing" requirements, we would need a standardized way to perform "ND proxy", possibly as part of a "multi-link subnet" specification. (The explicit prefix delegation can be accomplished through [PREFIXDHCPV6].)
3. ケースBの「非公式のプレフィックス共有」要件を満たすには、おそらく「マルチリンクサブネット」仕様の一部として、「ndプロキシ」を実行する標準化された方法が必要です。（明示的な接頭辞委任は、[refixdhcpv6]を通じて達成できます。）
4. To meet case B naming requirements, we need to proceed with the standardization of LLMNR. (The provisioning of DNS parameters can be accomplished through [DNSDHCPV6].)
4. ケースBの命名要件を満たすには、LLMNRの標準化を進める必要があります。（DNSパラメーターのプロビジョニングは[dnsdhcpv6]を通じて実現できます。）
5. To meet case D IPv4 connectivity requirement, we need to standardize an IPv4 over IPv6 tunneling mechanism, as well as the associated configuration services.
5. ケースD IPv4接続要件を満たすには、IPv6トンネルメカニズムを介してIPv4を標準化するだけでなく、関連する構成サービスも標準化する必要があります。
This memo describes the general requirements for transition mechanisms. Specific security issues should be studied and addressed during the development of the specific mechanisms.
このメモは、遷移メカニズムの一般的な要件を説明しています。特定のメカニズムの開発中に、特定のセキュリティの問題を研究および対処する必要があります。
When hosts which have been behind a NAT are exposed to IPv6, the security assumptions may change radically. This is mentioned in sections 3.2 and 4.4. One way to cope with that is to have a default firewall with a NAT-like access configuration; however, any such firewall configuration should allow for easy authorization of those applications that actually need global connectivity. One might also restrict applications which can benefit from global IPv6 connectivity on the nodes.
NATの背後にあるホストがIPv6にさらされると、セキュリティの仮定が根本的に変化する場合があります。これは、セクション3.2および4.4で言及されています。それに対処する1つの方法は、NATのようなアクセス構成を備えたデフォルトのファイアウォールを持つことです。ただし、このようなファイアウォールの構成により、実際にグローバルな接続が必要なアプリケーションの容易な承認が可能になるはずです。また、ノード上のグローバルIPv6接続の恩恵を受ける可能性のあるアプリケーションを制限する場合があります。
Security policies should be consistent between IPv4 and IPv6. A policy which prevents use of v6 while allowing v4 will discourage migration to v6 without significantly improving security. Developers and administrators should make sure that global Internet connectivity through either IPv4 or IPv6 is restricted to only those applications that are expressly designed for global Internet connectivity.
セキュリティポリシーは、IPv4とIPv6の間で一貫している必要があります。V4を許可しながらV6の使用を防ぐポリシーは、セキュリティを大幅に改善することなくV6への移行を思いとどまらせます。開発者と管理者は、IPv4またはIPv6を介したグローバルなインターネット接続が、グローバルなインターネット接続用に明示的に設計されたアプリケーションのみに制限されていることを確認する必要があります。
Several transition technologies require relays. There are concerns that improperly designed protocols or improperly managed relays could open new avenues for attacks against Internet services. This issue should be addressed and mitigated in the design of the transition technologies and in the deployment guides for relays.
いくつかの遷移技術にはリレーが必要です。不適切に設計されたプロトコルまたは不適切に管理されたリレーが、インターネットサービスに対する攻撃のための新しい道を開く可能性があるという懸念があります。この問題は、遷移技術の設計とリレーの展開ガイドで対処し、軽減する必要があります。
This memo has benefited from the comments of Margaret Wasserman, Pekka Savola, Chirayu Patel, Tony Hain, Marc Blanchet, Ralph Droms, Bill Sommerfeld, and Fred Templin. Tim Chown provided a lot of the analysis for the tunneling requirements work.
このメモは、マーガレット・ワッサーマン、ペッカ・サヴォラ、チラユ・パテル、トニー・ハイン、マーク・ブランシェット、ラルフ・ドロム、ビル・ソマーフェルド、フレッド・テンプリンのコメントから恩恵を受けています。Tim Chownは、トンネリング要件の作業の多くの分析を提供しました。
[UNMANREQ] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April 2004.
[Unmanreq] Huitema、C.、Austein、R.、Satapati、S。、およびR. van der Pol、「管理されていないネットワークIPv6トランジションシナリオ」、RFC 3750、2004年4月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[NEIGHBOR] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[Neighbor] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[6TO4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[6to4] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[6TO4ANYCAST] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[6to4anycast] Huitema、C。、「6to4リレールーターのAnycastプレフィックス」、RFC 3068、2001年6月。
[TUNNELS] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[Tunnels] Durand、A.、Fasano、P.、Guardini、I。、およびD. Lento、「IPv6 Tunnel Broker」、RFC 3053、2001年1月。
[DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[Dhcpv6] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[DNSDHCPV6] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[DNSDHCPV6] DROMS、R。、「IPv6（DHCPV6）の動的ホスト構成プロトコルのDNS構成オプション」、RFC 3646、2003年12月。
[PREFIXDHCPV6] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[PrefixDhcpv6] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[Stun] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「Stun-ネットワークアドレス翻訳者（NAT）を介したユーザーデータグラムプロトコル（UDP）の単純なトラバーサル」、RFC 3489、2003年3月。
[DNSOPV6] Durand, A., Ihren, J., and P. Savola. "Operational Considerations and Issues with IPv6 DNS", Work in Progress.
[Dnsopv6] Durand、A.、Ihren、J。、およびP. Savola。「IPv6 DNSに関する運用上の考慮事項と問題」は、進行中の作業です。
[LLMNR] Esibov, L., Aboba, B., and D. Thaler, "Linklocal Multicast Name Resolution (LLMNR)", Work in Progress.
[LLMNR] Esibov、L.、Aboba、B。、およびD. Thaler、「Linklocal Multicast Name Resolution（LLMNR）」、進行中の作業。
[TSP] Blanchet, M., "IPv6 Tunnel Broker with the Tunnel Setup Protocol(TSP)", Work in Progress.
[TSP] Blanchet、M。、「Tunnel Setup Protocol（TSP）を備えたIPv6トンネルブローカー」、進行中の作業。
[DSTM] Bound, J., "Dual Stack Transition Mechanism", Work in Progress.
[DSTM] Bound、J。、「デュアルスタック遷移メカニズム」、進行中の作業。
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", Work in Progress.
[Teredo] Huitema、C。、「Teredo：UDPを介してIPv6をトンネル化する」、進行中の作業。
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Christian Huitema Microsoft Corporation One Microsoft Way Redmond、WA 98052-6399
EMail: huitema@microsoft.com
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
ロブオーストインインターネットシステムコンソーシアム950チャーターストリートレッドウッドシティ、カリフォルニア94063 USA
EMail: sra@isc.org
Suresh Satapati Cisco Systems, Inc. San Jose, CA 95134 USA
Suresh Satapati Cisco Systems、Inc。San Jose、CA 95134 USA
EMail: satapati@cisco.com
Ronald van der Pol NLnet Labs Kruislaan 419 1098 VA Amsterdam NL
Ronald van der pol nlnet labs Kruislaan 419 1098 Va Amsterdam NL
EMail: Ronald.vanderPol@nlnetlabs.nl
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
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/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。IETFドキュメントの権利に関するIETFの手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。