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
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）インターネット協会（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.
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からIPv6への移行フェーズ中IPv4-のみ、デュアルスタック、またはIPv6のみのノードが存在することになります。この文書では、我々は、IPv6専用ノードが通信する必要がないという仮説を作ります
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専用ノード。 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.
関連する問題は、次のセクションで説明されています。ノードはそれぞれ、他の名前を解決できることを保証するためにどのように、ノードは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.
これら二つの質問には、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プレフィックスを構築[ TEREDO]。自動ソリューションのもう一つの典型的な、非常に重要な特徴は、ローカルまたはリモートの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アドレスとしてのみとして安定している、マルチキャストのサポートは通常ありません、そしていくつかの回避策があるが（DNSの逆引きをサポートするための簡単な方法は、多くの場合ありませんおそらく可能）。しかし、自動トンネルは、他の利点を持っています。トンネルサービスとの明確な関係を必要としないため彼らは、明らかに設定が簡単です。彼らは、「パスの最適化」を可能として、彼らはまた、いくつかのケースでは、より効率的かもしれません。
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.
マイクロソフトによるTeredoサービスの早期展開では、リレーがネイティブで提供（または6to4の）自分自身をホストしています。彼らはDNSにあるいはTeredoアドレスを公開することはありませんが、ネイティブまたは6to4ホストは、事実上のネイティブとTeredoホストに「マルチホーム」です。ネイティブホストはTeredoホストと通信する場合、後続のパケットは、「エンドツーエンド」IPv4およびUDP上にトンネリングされている間、最初のパケットは、ネイティブインタフェースを介して交換し、Teredoサーバーによって中継されます。これは、ネットワーク内のリレーのインフラをフィールドすることなく、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.
溶液のこのタイプは、1つのネイティブとTeredoを使用して、一つ、二つの平行のIPv6インターネットの発症の暗黙的なリスクを運ぶ：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エニーキャストアドレス192.88.99.1 [6TO4ANYCAST]によって発見されたいずれかの6to4リレーを通じてパケットを送信します。経験は、これまでの単純なの6to4ルーターは、導入が容易であるということですが、6to4のリレーが不足しています。少なすぎるのリレーがある場合は、これらのリレーは、ボトルネックを作成します。 6to4とネイティブネットワークとの間の通信は、6to4ホスト間の直接通信よりも遅くなります。これは、6to4とネイティブの二つの平行なインターネットの作成、事実上の、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 ISPSが良好な性能を提供し、「パラレルインターネット」症候群を避けるために、リレーをサポートする必要があります。これらの費用は、初期導入フェーズの間に受け入れられるかもしれないが、彼らは確かに無期限にサポートすることはできません。 「暗黙の日没」メカニズムは、遷移の有限の寿命を保証するのに十分ではないかもしれません。
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トラバーサルは任意の遷移技術の一般的な性質であるべきかどうかを尋ねる、またはそれは技術の2種類を開発することは理にかなっているかどうか、いくつかの「NAT可能」といくつかないかもしれません。重要な問題は1つが行き来することができるはずであるNAT箱の種類もあります。一つは、おそらくIPv6固有のNATトラバーサルメカニズムを構築する必要があるかどうかを検討すべきである、またはIPv4トンネリングでのIPv6の何らかの形で既存のIPv4 NATトラバーサルメカニズムを組み合わせることが可能であるかどうか。多くの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トラバーサル技術は、自動トンネルまたは構成されたトンネルを使用するかどうかです。我々は1つが、この問題の両側を主張することができ、前のセクションで見ました。現実には、我々は、おそらく両方を見るということですので、実際には、すでに、自動で設定されたソリューションをそこに配備されています。
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パケットをカプセル化することを含みます。これらのトランスポート技術は、IPv4トンネル内の6to4またはIPv6のに使用される、IPv4からの単純なトンネリングよりも有意に多くのオーバーヘッドを必要とします。たとえば、UDPに基づくソリューションは、NATで「マッピング」を維持するために、パケット「キープアライブ」の頻繁な伝送を必要とします。 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」トンネルの確立を可能にします。他は唯一のTCP、または可能性HTTPを許可するかもしれないが一部のモデルでは、UDPの送信を許可します。
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トラバーサルは、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越え通信を可能にするために、ソリューション、またはクラッジを開発しました。
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を介して自動トンネリングのために必要とされ、1は自動トンネリングソリューションの一部としてSTUN仕様を再利用考えることができました。しかし、自動ソリューションはまた、NAT経由の初期パスを確立するために泡のメカニズムを必要とします。このメカニズムは、STUNには存在しません。 STUNとバブル機構の組み合わせは、特に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.
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の展開のケースAには、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の特性は、単離されたホストがTeredoのまたは代替のトンネリングメカニズムのいずれかを使用して、グローバル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がリンクを/ 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プロキシは、異なる特性（例えば、イーサネットおよびPPPリンク）の複数の物理リンクを/ 64プレフィックスを拡張するために使用することができます。
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).
/ 64サブネットをブリッジまたはNDプロキシを使用して、複数の物理リンクにまたがるように拡張することができます。複数の同様の媒体（主に、イーサネット（登録商標）セグメント）をブリッジする際のブリッジを使用することができます。一方、NDプロキシは/ 64プレフィックス（例えば、上流のPPPリンクとダウンストリームイーサネット）、またはインターフェイスが（プロミスキャスモードにすることができない場合、例えば、上流のメディア間で共有されなければならない場合に使用しなければなりません無線リンク）。
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プロキシメソッドの結果は、手順は一般的に「マルチリンクサブネット」として知られています。この共有は、近隣探索プロトコルの効果があり、そしておそらくまた、「リンクローカルマルチキャスト」に頼るように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が顧客に/ 48を割り当てることが期待されます。ゲートウェイは、自動的に内部リンクこの/ 48から/ 64Sを割り当てるべきです。
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は安全です。ゲートウェイと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からIPv6への移行段階の間、IPv4-のみ、デュアルスタックとIPv6専用ノードが存在することになります。理論的には、IPv4のみとIPv6のみのホストが通信できるように、いくつかの相互接続サービスを提供する必要があるかもしれません。しかし、効率や通信のセキュリティ上望ましくない副作用を持たない翻訳サービスを開発することは困難です。その結果、著者は、デバイスがとの通信を必要とする場合は、することをお勧めします
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のみのホストは、このデバイスは、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で提供されなければならない名前解決サービスの3つのタイプがあります：ローカルIPv6対応ホストは、インターネット上の通信先ホストのIPv6アドレスを取得できるようにする必要があり、彼らはからアクセスしたい場合、彼らは自分のアドレスを公開することができるはずですインターネット、彼らは他のローカルIPv6ホストのIPv6アドレスを取得することができるはずです。これらの三つの問題は、次のセクションで説明されています。 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.
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.
または安定であってもなくてもよいゲートウェイに割り当てられたプレフィックス、およびいずれの場合にも、手動手順で長い16進文字列をコピーすると、エラー傾向がある：安定したアドレスの手動設定は、アンマネージIPv6ネットワークに満足のいくものではありません。
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（DDNS）に基づいた標準溶液の使用を奨励すべきです。
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つの方法がある：一方は、ローカルドメインのDNSサーバにIPv6アドレスを公開することのいずれか、または1つは、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.
ローカルサーバの使用は、彼らがこのサーバに自分のIPv6アドレスを公開するなどDDNSなどのプロトコルを使用すること、その後4.3.1で説明したように、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.
ローカルサーバーを使用する代わりに、DNS要求を解決するために、マルチキャストメカニズムを使用していますLLMNR、です。 LLMNRは、ゲートウェイから任意のサービスを必要とせず、またホストがDDNSを使用することを必要としません。重要な問題は、いくつかのネットワークが唯一例えば、802.11ネットワーク上のマルチキャスト送信がエラーが発生しやすくなり、マルチキャスト伝送のための限定的なサポートを持っているということです。しかし、管理されていないネットワークも近隣探索[NEIGHBOR]にマルチキャストを使用します。 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接続を制限する必要があります。ローカルアプリケーションは、例えば、その最上位ビットローカルサブネットのプレフィックスと一致し、例えば、プレフィックスがローカルルータ広告で「リンク上」と宣伝のみ使用リンクローカルアドレス、またはアドレスに制限することができます。そこのような制限は、「サイトごとの」または「当りリンク」をするかどうかの議論があるが、これは非管理ネットワークは、単一のリンクで構成されている深刻な問題ではありません。
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.
ケース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]などの自動トンネリングメカニズムによって解決することができます。代替的には、設定されたトンネル機構[TUNNELS]の使用であってもよいが、ローカル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.
我々は、IPv6がB、ゲートウェイ上すなわち、プロビジョニングのDHCPv6を通してNDプロキシまたは明示的なプレフィックス委譲のいずれかを使用するIPv6プレフィックスの場合と同様に進行するケースDにアドレッシング期待します。
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からIPv6オーバー」のトンネルの形を開発することです。そこには標準化されたソリューションではありませんし、現在進行中の[DSTM]と仕事と[TSP]がありますが、IETFは、この問題に非常に少しの努力を注いできました。ソリューションは、標準化する必要があります。標準化は、構成の問題をカバーしなければならない、すなわち、どのようにローカルの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と同様である：ゲートウェイはISPによって推奨されるDNSリゾルバのアドレスを取得するためのDHCPv4を使用することを期待することはできません。
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.
構成された、自動トンネルNATトラバーサルのないように[6TO4]など、など[TEREDO]としてNATトラバーサルと自動トンネル：1.ケースAとケースCの要件を満たすために、我々は開発し、または、4トンネリング技術の種類の開発を継続する必要がありますこのような[トンネル、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プロキシ」を実行するための標準化された方法が必要になります。 （明示的なプレフィックス委譲する[PREFIXDHCPV6]を介して達成することができます。）
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接続要件を満たすために、我々は、IPv4からIPv6上トンネリング機構、ならびに関連する構成サービスを標準化する必要があります。
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に記載されています。それに対処する一つの方法は、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.
このメモは、マーガレットワッサーマンのコメント、ペッカSavola、Chirayuパテル、トニーハイン、マルク・ブランシェ、ラルフDroms、ビルゾンマーフェルト、およびフレッドテンプリンの恩恵を受けています。ティム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.のファンデルポール、 "非管理ネットワークのIPv6移行シナリオ"、RFC 3750、2004年4月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]デアリング、S.と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.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[6TO4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
"IPv4の雲を介したIPv6ドメインの接続" [6TO4]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月。
[6TO4ANYCAST] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[6TO4ANYCAST]のHuitema、C.、 "6to4のリレールータのエニーキャストプレフィックス"、RFC 3068、2001年6月。
[TUNNELS] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[TUNNELS]デュラン、A.、ファザーノ、P.、Guardini、I.、およびD.レント、 "IPv6のトンネルブローカー"、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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、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.、RFC 3646、2003年12月の "IPv6のための動的ホスト構成プロトコル（DHCPv6）のためのDNSの設定オプション"。
[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、RFC 3633、2003年12月 "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
[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]ローゼンバーグ、J.、ワインバーガー、J.、のHuitema、C.、およびR.マーイ、 - 2003年3月、RFC 3489 "STUNネットワークを介して、ユーザーデータグラムプロトコル（UDP）の簡単なトラバーサルは、翻訳者（NATのを）アドレス"。
[DNSOPV6] Durand, A., Ihren, J., and P. Savola. "Operational Considerations and Issues with IPv6 DNS", Work in Progress.
【DNSOPV6]デュラン、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.ターレル、 "リンクローカルマルチキャスト名前解決（LLMNR）"、ProgressのWork。
[TSP] Blanchet, M., "IPv6 Tunnel Broker with the Tunnel Setup Protocol(TSP)", Work in Progress.
[TSP]、進行中の作業 "トンネル設定プロトコル（TSP）とのIPv6トンネルブローカ" ブランシェ、M.、。
[DSTM] Bound, J., "Dual Stack Transition Mechanism", Work in Progress.
[DSTM]、J.、「デュアルスタック遷移メカニズム」、進行中で働いて結合しました。
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", Work in Progress.
[TEREDO]のHuitema、C.、 "Teredoの：NATを経由UDP上でトンネリングのIPv6"、進行中の作業。
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
クリスチャンのHuitemaマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052-6399
EMail: huitema@microsoft.com
メールアドレス：huitema@microsoft.com
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
ロブAusteinとインターネットシステムコンソーシアム950憲章通りカリフォルニア州レッドウッドシティー94063 USA
EMail: sra@isc.org
メールアドレス：sra@isc.org
Suresh Satapati Cisco Systems, Inc. San Jose, CA 95134 USA
スレシュSatapatiシスコシステムズ社サンノゼ、CA 95134 USA
EMail: satapati@cisco.com
メールアドレス：satapati@cisco.com
Ronald van der Pol NLnet Labs Kruislaan 419 1098 VA Amsterdam NL
ロナルドのファンデルポールNLnet LabsのKruislaan 419 1098 VAアムステルダムNL
EMail: Ronald.vanderPol@nlnetlabs.nl
メールアドレス：Ronald.vanderPol@nlnetlabs.nl
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the 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.
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機能のための基金は現在、インターネット協会によって提供されます。