RFC3904 日本語訳
3904 Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks.C. Huitema, R. Austein, S. Satapati, R. van der Pol. September 2004. (Format: TXT=46844 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Huitemaがコメントのために要求するワーキンググループC.をネットワークでつないでください: 3904年のマイクロソフトカテゴリ: 情報のR.のシスコシステムズInc.R.バンder Pol NLnet Labs Austein ISC S.Satapati2004年9月
Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks
UnmanagedネットワークのためのIPv6変遷メカニズムの評価
Status of this Memo
この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).
Copyright(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までの変遷にかかわる問題を分析します。 Unmanagedネットワークはホームネットワークか小さい企業内ネットワークに通常対応しています。 仲間論文は外でこれらのネットワークの様々な変遷シナリオで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
1. 序論… 2 2. トンネリングソリューションの評価… 3 2.1. 自動で構成されたソリューションを比較します… 3 2.1.1. 自動Tunnelsの経路最適化… 4 2.1.2. 自動トンネルとリレー… 4 2.1.3. いくつかの平行なIPv6インターネットのリスク… 5 2.1.4. 変遷技術の寿命… 6 2.2. NAT縦断の費用と恩恵… 6 2.2.1. NAT縦断の費用… 7 2.2.2. NATのタイプ… 7 2.2.3. 既存のメカニズムの再利用… 8 2.3. 変遷メカニズムの開発… 8
Huitema, et al. Informational [Page 1] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[1ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
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
3. 会って、要件をケースに入れてください… 9 3.1. 接続性メカニズムの評価… 9 3.2. セキュリティ問題は中にAをケースに入れます… 9 4. ミーティングケースB Requirements… 10 4.1. 接続性… 10 4.1.1. 倍数にかかるためにサブネットを広げるのはリンクされます… 10 4.1.2. 明白な接頭語委譲… 11 4.1.3. 推薦… 11 4.2. IPv4だけとIPv6できるノード. 11 4.3とのコミュニケーション。 IPv6アドレスへの名前の解決… 12 4.3.1. DNSレゾルバのアドレスに食糧を供給します… 12 4.3.2. IPv6アドレスをインターネットに発表します… 12 4.3.3. ローカル・ホストのIPv6アドレスを決議します… 13 4.3.4. 名前解決のための推薦… 13 4.4. 場合Bにおけるセキュリティ問題… 14 5. ミーティングケースC要件… 14 5.1. 接続性… 14 6. ケースD必要条件を満たします… 14 6.1. IPv6アドレシング要件… 15 6.2. IPv4接続性要件… 15 6.3. 要件を命名します… 15 7. 推薦… 15 8. セキュリティ問題… 16 9. 承認… 16 10. 参照… 16 11. 作者のアドレス… 18 12. 完全な著作権宣言文… 19
1. Introduction
1. 序論
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からIPv6までの過渡期の間、IPv4だけ、デュアルスタック、またはIPv6だけノードがあるでしょう。 本書では、私たちは交信する必要性ではなく、IPv6だけノードがそうするという仮説を作ります。
Huitema, et al. Informational [Page 2] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[2ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
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.
かかわった問題は次のセクションで説明されます。 この分析は2つのタイプの要件について概説します: すなわち、IPパケットと、要件を命名するすなわち、ノードが互いの名前を決議できるのをどう保証するかをノードが交換できるのをどう保証するかという接続性要件。 接続性要件は、しばしばソリューションにトンネルを堀るのを必要とします。 私たちは様々なトンネリングソリューションの評価にこのメモの最初のセクションをささげます。
2. Evaluation of Tunneling Solutions
2. トンネリングソリューションの評価
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では、非管理されたネットワークはIPv6サービスを得ることができません、少なくともネイティブです、ISPから。 これらの場合では、何らかの形式のトンネルを通して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つの広いクラスに分割します。 それぞれのこれらのクラスには、特定の利点と危険があります。(私たちは現在、危険を開発するつもりです)。
2.1. Comparing Automatic and Configured Solutions
2.1. 自動で構成されたソリューションを比較します。
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]かアドレスとポートナンバーの組み合わせ[TEREDO]にあらかじめ定義された接頭語を結合することによって、IPv6アドレスかIPv6接頭語を築き上げます。 自動ソリューションの別の典型的で非常に重要な特性は彼らが、IPv6のためにサポートかインフラストラクチャの最少量で地方の、または、リモートなISPで働くことを目指すということです。
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.
構成されたソリューションでは、ホストかルータが、明らかに定義された「トンネルルータ」で「構成されたトンネル」をセットアップするためにトンネリングサービスにそれ自体を特定します。 実際の構成の量は手動で構成された静的なトンネルからダイナミックな「トンネルのブローカー」の構成だけ、またはトンネルルータの完全に自動である発見さえ必要とするトンネルサービスに異なるかもしれません。
Huitema, et al. Informational [Page 3] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[3ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
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がルックアップであるとサポートするどんな簡単な方法もしばしばあるというわけではありません(いくつかの回避策がたぶん可能ですが)。 しかしながら、自動トンネルには、他の利点があります。 トンネルサービスとの明白な関係の必要は全くないので、それらは明らかにより構成しやすいです。 また、彼らが「経路最適化」を考慮するので、いくつかの場合、それらも、より効率的であるかもしれません。
2.1.1. Path Optimization in Automatic Tunnels
2.1.1. 自動Tunnelsの経路最適化
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はすなわち、クライアントの近くと、ほとんどクライアントとその同輩の間の直接路にトンネルエンドポイントを置くことができます。
2.1.2. Automatic Tunnels and Relays
2.1.2. 自動トンネルとリレー
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
経路最適化好意に関連する経済学議論はISPの協力にかかわらず地方のISPか自動トンネリングによって提供されたトンネルを構成しました。 しかしながら、自動ソリューションは、リレーがインターネット中で構成されるのを必要とします。 自動トンネルサービスで接続性を得たホストが「ネイティブ」のホストかaが構成したaホスト使用で交信したいなら
Huitema, et al. Informational [Page 4] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[4ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
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.
トンネルを堀ってください、リレーサービスを利用するのが必要であり、だれかが、そのサービスを提供して、代価を払わなければならないでしょう。 私たちはこれらのリレーの展開のために経済上の考慮から逃げることができません。
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.
しかしながら、私たちは、異なった自動トンネリングのテクニックには異なった展開状態があることに注意するべきです。
2.1.3. The Risk of Several Parallel IPv6 Internets
2.1.3. いくつかの平行なIPv6インターネットのリスク
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)のホストによって自分たちで提供されます。 ネイティブか6to4ホストがデファクトである、「マルチ、家へ帰り、」 ネイティブとTeredoホストには、彼らですが、そうでなければ、DNSのTeredoアドレスを決して発表しないでください。 ネイティブのホストが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.
このタイプの解決は1ネイティブのTeredo、2展開している平行なIPv6 Internets、および1使用Teredoの暗黙の危険を伴います: Teredoだけホストとコミュニケートするために、ネイティブのIPv6ホストはTeredoインタフェースを実装しなければなりません。 利用可能であるときに、Teredo実装はいつもネイティブの経路を好むことによって、この危険を緩和しようとしますが、本当の緩和は、ネイティブのホストが変遷技術を実装する必要はないのを必要とします。 これはIPv6ISPから協力を必要とします。(ならなければならないリレーを支えるのにISPが)。 本当にTeredo技術から顧客を隔離したがっているIPv6ISPは、固有の接続性と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
6to4ネットワークと固有のネットワークとのコミュニケーションは異なった構造を使用します。 コミュニケーションの各方向には2個のリレー、1があります。 ネイティブのホストはすなわち、最も近い6to4ルータ、最も厳密なルータ広告によるパケットに2002を送ります:、:/16はIPv6を通して経路指定テーブルを前に置きます。 または6to4ネットワークが明らかに構成される6to4リレーでパケットを送る。
Huitema, et al. Informational [Page 5] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[5ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
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 anycastアドレス192.88.99.1[6TO4ANYCAST]を通して発見されます。 今までのところの経験は簡単な6to4ルータは配布しやすいのですが、6to4リレーが不十分であるということです。 リレーがわずかしかあり過ぎるというわけではないと、これらのリレーはボトルネックを作成するでしょう。 6to4と固有のネットワークとのコミュニケーションは6to4ホストのダイレクトコミュニケーションよりさらに遅くなるでしょう。 これはどうにか「マルチホーム」へのネイティブのホストのための誘因を6to4、2事実上の作成平行なInternets、6to4、およびネイティブに作成するでしょう。 6to4リレーの十分な展開がある場合にだけ、この危険は緩和されるでしょう。
The configured tunnel solutions do not carry this type of risk.
構成されたトンネルソリューションはこのタイプの危険を伴いません。
2.1.4. Lifespan of Transition Technologies
2.1.4. 変遷技術の寿命
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は望ましい市場成果を提供するためにリレーを支えて、「平行なインターネット」シンドロームを避けなければなりません。 これらのコストは初期の展開段階の間許容できるかもしれませんが、確かに、無期限にそれらをサポートすることができません。 「暗黙の日没」メカニズムは、変遷の有限寿命を保証するために十分でないかもしれません。
2.2. Cost and Benefits of NAT Traversal
2.2. NAT縦断の費用と恩恵
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 NATsの後ろに位置するでしょう。 変遷に参加するために、これらのホストは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
私たちは、NAT縦断が何か変遷技術のジェネリックの特性であるべきであるかどうかかそれともそれが2つのタイプの技術、いくつかの「できるNAT」、およびいくつかを開発する意味になるかどうか尋ねるかもしれません。 重要な質問はまた、NAT箱1の種類もどれにできるべきであるかということです。
Huitema, et al. Informational [Page 6] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[6ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
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.
横断します。 また、IPv6の特定のNAT縦断メカニズムを造るのが必要であるかどうか、または既存のIPv4NAT縦断メカニズムをIPv4のトンネルを堀るIPv6の何らかのフォームに結合するのが可能であるかどうかたぶん考えるべきです。 多くのIPv4NAT縦断メカニズムがあります。 したがって、特にそれらが既に複雑であるときに、これらが再発明を必要とするかどうか尋ねるかもしれません。
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縦断技術が自動トンネルか構成されたトンネルを使用するべきであるかどうかということです。 私たちは、前項で人がこの問題の両側について論争できるのを見ました。 事実上、既に配布している自動で構成されたソリューションがあるので、現実は私たちがたぶん両方を見るということです。
2.2.1. Cost of NAT Traversal
2.2.1. 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縦断技術は、NATを横断するのが知られているトランスポート・プロトコルでパケットをIPv6にカプセルに入れることを伴います、UDPやTCPのように。 これらの輸送技術はIPv4トンネルで6to4かIPv6で使用されるIPv4の上の簡単なトンネリングよりかなり多くのオーバーヘッドを必要とします。 例えば、UDPに基づくソリューションはNATにおける「マッピング」を維持するために「生きているままでいてください」というパケットの頻繁なトランスミッションを必要とします。 TCPに基づくソリューションはそのようなメカニズムを必要としないかもしれませんが、それらは「待ち行列ブロッキングのヘッド」の危険を被ります。(それは、不十分な性能で翻訳されるかもしれません)。 性能の違いを考えて、2つのタイプの変遷技術を考えるのは理解できます、最も良い性能をNATを横断して、いくつか目的とすることができる数人。
2.2.2. Types of NAT
2.2.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の「almost all」のモデルをカバーするソリューションを見つけるのは望ましいです。
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を許容するだけであるかもしれません。
Huitema, et al. Informational [Page 7] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[7ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
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の上で多くのアプリケーション、例えば、ネットワークでつながれたゲームまたは声によって必要とされます。 経験は、最新の「ホームルータ」がこれらのアプリケーションをサポートするように設計されているのを示します。 いくつかの縁の場合では、自動ソリューションはホームルータにおける、ポートの明白な構成を必要とするでしょう、いわゆる「非武装地帯」機能を使用して。 しかしながら、これらの機能は「非管理されたネットワーク」シナリオで使用しにくいです。
2.2.3. Reuse of Existing Mechanisms
2.2.3. 既存のメカニズムの再利用
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.
仮想の兵士のNetworksは、VPNクライアントとVPNサーバの間のトンネルをインストールすることによって、設立されます。 これらのトンネルは、今日IPv4を運ぶように設計されますが、多くの場合、容易にIPv6を運ぶかもしれません。 例えば、提案されたIETF規格(L2TP)はIPv4と同様にIPv6をカプセル化することができる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を通したUDP協会の設立を容易にするように設計されたプロトコルです、NATの後ろのノードにそれらの「外部」のアドレスを発見させることによって。 同じ機能が自動トンネリングにNATを通して必要でした、そして、人はSTUN仕様を再利用するのが、自動トンネリングソリューションの一部であるとみなすことができました。 しかしながら、また、自動ソリューションは、NATを通して初期の経路を証明するために気泡のメカニズムを必要とします。 このメカニズムはSTUNに存在していません。 STUNの組み合わせと気泡メカニズムには自動トンネリングのためにNATを通して明確に設計されたソリューションより技術的な利点があるのは、明確ではありません。
2.3. Development of Transition Mechanisms
2.3. 変遷メカニズムの開発
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の向こう側の構成されたトンネル。 - NATの向こう側の自動トンネル。
Huitema, et al. Informational [Page 8] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[8ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
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.
船食虫は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ルックアップメカニズムで増大する必要があるかもしれません、構成されたトンネルソリューションが自動サービス構成メカニズムの利益を得るでしょうが。
3. Meeting Case A Requirements
3. 会って、要件をケースに入れてください。
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で働いているメカニズムがどうこの必要条件を出迎えるかを評価します。 私たちは、次に、「残っている穴」を考えて、特定の開発を推薦します。
3.1. Evaluation of Connectivity Mechanisms
3.1. 接続性メカニズムの評価
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のような自動ソリューションはNATの後ろでIPv6の接続性をホストに提供するための良いフィットであるように見えます、IPv6展開の場合Aで。 サービスは、サーバを配布する費用を最小にするように設計されています。サーバは「サポートインフラストラクチャ」の費用を最小にする要件に合っています。
3.2. Security Considerations in Case A
3.2. 場合Aにおけるセキュリティ問題
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
ケースAの特性は孤立しているホストがグローバルなIPv6の接続性を取得するということです、Teredoか代替のトンネリングメカニズムのどちらかを使用して。 注意しないなら、ローカル・ホストに役立つと予想されるだけであるいくつかのアプリケーションとサービスを世界的なインターネットに暴露するリスクがあります、例えばNATの後ろに位置するもの
Huitema, et al. Informational [Page 9] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[9ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
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.
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縦断プロトコルのデザインとリレーのための展開ガイドで扱われて、緩和されるべきです。
4. Meeting Case B Requirements
4. ミーティングケースB要件
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ホストとのコミュニケーションの潜在的必要性を研究して、デュアルスタックアプローチが望ましいと結論を下します。
4.1. Connectivity
4.1. 接続性
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接頭語の広告を出しているなら、ノースダコタプロキシかブリッジの使用でそのようなリンクを広げることができます。
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).
また、異なった特性(例えば、イーサネットとPPPリンク)の複数の物理的なリンクに/64接頭語を広げるのにノースダコタプロキシを使用できます。
4.1.1. Extending a Subnet to Span Multiple Links
4.1.1. 複数のリンクにかかるためにサブネットを広げています。
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サブネットを広げることができます。 複数の同様のメディアが(主にイーサネットセグメント)であるとブリッジするとき、ブリッジを使用できます。 他方では、メディア(例えば、上流のPPPリンクと川下のイーサネット)の向こう側に/64接頭語を共有しなければならなくて、無差別なモード(例えば、上流のワイヤレスのリンク)にインタフェースを入れることができないなら、ノースダコタプロキシを使用しなければなりません。
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
ISPから非管理されたネットワークのすべてまでわたるようにただ一つのサブネットを広げるのは推薦されません、そして、利用可能であるときに、接頭語委譲は使用されるべきです。 しかしながら、時々、それは避けられません。 コネ
Huitema, et al. Informational [Page 10] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[10ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
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.
追加、時々、非管理されたネットワークでサブネットを広げるのが必要です、ゲートウェイの「顧客側」で、そして、ルーティングを使用することでトポロジーを変えるのはあまりに多くの専門的技術を必要とするかもしれません。
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.
ノースダコタプロキシメソッドは数個のリンク(一般に、「マルチリンクサブネット」として知られている手順)の上に同じ接頭語の共有をもたらします。 この共有は隣人発見プロトコルの上と、そして、ことによると「リンクの地方のマルチキャスト」を当てにするLLMNR[LLMNR]などの他のプロトコルの上でも手答えがあります。 これらの効果は、慎重に研究される必要があります。
4.1.2. Explicit Prefix Delegation
4.1.2. 明白な接頭語委譲
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を顧客に割り当てると予想されます。 ゲートウェイは64年代を内部のリンクへのこの/48から/に自動的に割り当てるはずです。
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認証を管理する実際的な詳細は、分析される必要があります。
4.1.3. Recommendation
4.1.3. 推薦
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.
ノースダコタプロキシとDHCPメソッドはアプリケーションの補足的なドメインを持っているように見えます。 ノースダコタプロキシはリンクの「非公式の共有」によく対応する簡単なメソッドです、明白な委譲が強い運営管理コントロールを提供しますが。 両方のメソッドは開発を必要とします: ノースダコタプロキシのための隣人発見との相互作用を指定してください。 明白な委譲のための安全ガイドラインを提供してください。
4.2. Communication Between IPv4-only and IPv6-capable Nodes
4.2. IPv4だけとIPv6できるノードとのコミュニケーション
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だけホストが交信できるようにいくつかのインタコネクトサービスを提供する必要があるかもしれません。 しかしながら、効率かコミュニケーションのセキュリティに求められていない副作用を持っていない翻訳サービスを開発しにくいです。 結果として、デバイスがコミュニケーションを必要とするなら、作者はそれを推薦します。
Huitema, et al. Informational [Page 11] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[11ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
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ホストとコミュニケートするだけであることを意図するものです。
4.3. Resolution of Names to IPv6 Addresses
4.3. 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アドレスを得ることができるべきです。 これらの3つの問題が次のセクションで説明されます。 IPv6 DNSの操作上の問題と問題は[DNSOPV6]で分析されます。
4.3.1. Provisioning the Address of a DNS Resolver
4.3.1. DNSレゾルバのアドレスに食糧を供給します。
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ソリューションはゲートウェイとデュアルスタックホストのために習慣でも十分でしょう。 AAAA記録を含んでいて、IPv4の上でアクセスされたDNSサーバが任意の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作業部会で見られています。
4.3.2. Publishing IPv6 Addresses to the Internet
4.3.2. IPv6アドレスをインターネットに発表します。
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ホストがaを同様にする、今日の3つの可能なソリューションの1つを使用することにおける問題、:(それらはそれを解決します)。
* 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プロトコルを使用する動的設定。 * 臨時のプロトコルを使用する動的設定。
Huitema, et al. Informational [Page 12] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[12ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
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.
安定したアドレスの手動の構成はunmanaged 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はDynamic DNS(DDNS)に基づく標準液の使用を奨励するはずです。
4.3.3. Resolving the IPv6 Addresses of Local Hosts
4.3.3. ローカル・ホストのIPv6アドレスを決議します。
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アドレスを発表するかもしれませんか、または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などのプロトコルを使用します。ローカルサーバの使用は、IPv6の有能なホストがこのサーバを発見するのを必要とします、説明されるように4.3、.1、習慣、アドレスが.1がゲートウェイのアドレスがそれ自体であったならしばしば望んでいる4.3で発見して、その結果ローカルサーバがそうする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です。(そのLLMNRは、DNS要求を決議するのにマルチキャストメカニズムを使用します)。 LLMNRは、ゲートウェイから少しのサービスも必要としないで、またまた、ホストがDDNSを使用するのを必要としません。 重大な問題がいくつかのネットワークだけがマルチキャスト送信のサポートを制限したということである、例えば、802.11ネットワークにおけるマルチキャスト送信は誤り傾向があります。 しかしながら、また、非管理されたネットワークは隣人発見[NEIGHBOR]にマルチキャストを使用します。 ノースダコタとLLMNRの要件は同様です。 また、リンク技術がノースダコタの使用をサポートするなら、それはLLMNRの使用を可能にすることができます。
4.3.4. Recommendations for Name Resolution
4.3.4. 名前解決のための推薦
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は急速にそのプロトコルの標準化に続くはずです。
Huitema, et al. Informational [Page 13] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[13ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
4.4. Security Considerations in Case B
4.4. 場合Bにおけるセキュリティ問題
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の接続性を世界的なインターネットを作動させるように明確に設計されているそれらのアプリケーションだけに制限するべきです。 例えば局所塗布はリンクローカルのアドレス、または最上位ビットが地方のサブネットの接頭語に合っているアドレスを使用するだけであるために制限される場合がありました、例えば「リンク」のようにローカルルータ広告の広告に掲載された接頭語。 そのような制限が「サイト」であるべきであるかどうかあたりの討論か「リンク」がありますが、非管理されたネットワークが単一のリンクで構成されるとき、これは重大な問題ではありません。
5. Meeting Case C Requirements
5. ミーティングケースC要件
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.
違いがISPがデュアルスタックでないということであり、ケースCは、Bをケースに入れるために非常に同様です。 その結果、ゲートウェイは、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インターネットとのダイレクト接続と共に。 このホストはゲートウェイと同じトンネリングメカニズムを使用できるでしょう。
5.1. Connectivity
5.1. 接続性
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".
6to4[6TO4]などの自動トンネリングメカニズムはケースCの要件を解決できます。 代替手段は構成されたトンネルの使用がメカニズム[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実装はユーザが特定のリレーを利用できる設定オプションを含むべきです。
6. Meeting the Case D Requirements
6. ケースD必要条件を満たします。
In case D, the ISP only provides IPv6 services.
場合Dでは、ISPはサービスをIPv6に供給するだけです。
Huitema, et al. Informational [Page 14] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[14ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
6.1. IPv6 Addressing Requirements
6.1. 要件を扱う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.
私たちはゲートウェイの上で支給へのDHCPv6を通したノースダコタプロキシか明白な接頭語委譲のどちらかがIPv6接頭語であるとケースBに同様に続かせるケースD、すなわち、使用で扱うIPv6を予想します。
6.2. IPv4 Connectivity Requirements
6.2. IPv4接続性要件
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だけサービスにアクセスしていたがっているかもしれません。 デュアルスタックノードのために非管理されたネットワークでこれをする適切な方法は「IPv6"トンネリングの上のIPv4」のフォームを発生することです。 標準液が全くありません、そして、IETFは非常に小さい取り組みをこの問題にささげました、[DSTM]と[TSP]との進行中の仕事がありますが。 ソリューションは、標準化される必要があります。 標準化はすなわち、支給に、地方のIPv4のアドレスをもっているIPv4の有能なホストがどうサーバにトンネルを堀るかという構成問題をカバーしなければならないでしょう。
6.3. Naming Requirements
6.3. 要件を命名します。
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.
命名要件は1つの違いでBをケースに入れるために同様です: ゲートウェイは、ISPによって推薦されたDNSレゾルバのアドレスを得るのにDHCPv4を使用することを期待できません。
7. Recommendations
7. 推薦
After a careful analysis of the possible solutions, we can list a set of recommendations for the V6OPS working group:
可能なソリューションの慎重な分析の後に、私たちはV6OPSワーキンググループのために1セットの推薦を記載できます:
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縦断がある自動トンネル)はトンネルが[Tunnels、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」必要条件を満たすために、私たちは「ノースダコタプロキシ」を実行する標準化された方法を必要とするでしょう、ことによると「マルチリンクサブネット」仕様の一部として。 ([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の規格化を続ける必要があります。 ([DNSDHCPV6]を通してDNSパラメタの食糧を供給することを達成できます。)
Huitema, et al. Informational [Page 15] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[15ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
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を標準化する必要があります、関連構成サービスと同様に。
8. Security Considerations
8. セキュリティ問題
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.
いくつかの変遷技術がリレーを必要とします。 不適切に設計されたプロトコルか不適切に管理されたリレーが攻撃のためにインターネットのサービスに対して新しい大通りを開くかもしれないという関心があります。 この問題は、変遷技術のデザインとリレーのための展開ガイドで扱われて、緩和されるべきです。
9. Acknowledgements
9. 承認
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パテル、トニー・ハイン、マークBlanchet、ラルフDroms、ビル・ゾンマーフェルト、およびフレッド・テンプリンのコメントの利益を得ました。 ティムChownはトンネリング要件仕事のための多くの分析を提供しました。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[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.バンder Pol、「UnmanagedはIPv6変遷シナリオをネットワークでつなぐ」RFC3750(2004年4月)。
Huitema, et al. Informational [Page 16] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[16ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[NEIGHBOR] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[隣人]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[6TO4] Carpenter, B. and K. Moore, "Connection of IPv6
Domains via IPv4 Clouds", RFC 3056, February 2001.
[6TO4] 大工とB.とK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、2001年2月。
[6TO4ANYCAST] Huitema, C., "An Anycast Prefix for 6to4 Relay
Routers", RFC 3068, June 2001.
[6TO4ANYCAST] Huitema、C.、「6to4リレールータのためのAnycast接頭語」、RFC3068、2001年6月。
[TUNNELS] Durand, A., Fasano, P., Guardini, I., and D. Lento,
"IPv6 Tunnel Broker", RFC 3053, January 2001.
[トンネル] ジュランドとA.とファザーノとP.とグァルディーニ、I.とレントのD.「IPv6トンネルのブローカー」、RFC3053、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.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、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)のためのDynamic Host Configuration ProtocolのためのDNS Configurationオプション」、RFC3646、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、「Dynamic Host Configuration Protocol(DHCP)バージョン6インチIPv6 Prefix Options、RFC3633、2003年12月。」
10.2. Informative References
10.2. 有益な参照
[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.
[気絶させます] ローゼンバーグ、J.、ワインバーガー、J.、Huitema、C.、およびR.マーイ、「気絶させてください--ネットワークアドレス変換機構(NATs)を通したユーザー・データグラム・プロトコル(UDP)の簡単な縦断」、RFC3489、2003年3月。
[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.
L.とAboba、B.とD.ターレル、「Linklocalマルチキャスト名前解決(LLMNR)」という[LLMNR]Esibovは進行中で働いています。
[TSP] Blanchet, M., "IPv6 Tunnel Broker with the Tunnel
Setup Protocol(TSP)", Work in Progress.
M.、「トンネルセットアッププロトコル(ティースプーンフル)をもっているIPv6トンネルのブローカー」という[ティースプーンフル]Blanchetは進行中で働いています。
[DSTM] Bound, J., "Dual Stack Transition Mechanism", Work in
Progress.
[DSTM]はバウンドしていて、J.、「デュアルスタック変遷メカニズム」が進行中で働いています。
Huitema, et al. Informational [Page 17] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[17ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs", Work in Progress.
[船食虫]Huitema、C.、「船食虫:」 「NATsを通してUDPの上でIPv6にトンネルを堀っ」て、進行中で働いてください。
11. Authors' Addresses
11. 作者のアドレス
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
クリスチャンのHuitemaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052-6399
EMail: huitema@microsoft.com
メール: huitema@microsoft.com
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
ロブAusteinインターネットSystems共同体950憲章通りカリフォルニア94063レッドウッドシティー(米国)
EMail: sra@isc.org
メール: sra@isc.org
Suresh Satapati Cisco Systems, Inc. San Jose, CA 95134 USA
Suresh SatapatiシスコシステムズInc.カリフォルニア95134サンノゼ(米国)
EMail: satapati@cisco.com
メール: satapati@cisco.com
Ronald van der Pol NLnet Labs Kruislaan 419 1098 VA Amsterdam NL
ロナルドバンder Pol NLnet Labs Kruislaan419 1098ヴァージニアアムステルダムNL
EMail: Ronald.vanderPol@nlnetlabs.nl
メール: Ronald.vanderPol@nlnetlabs.nl
Huitema, et al. Informational [Page 18] RFC 3904 Unmanaged Networks Transition Tools September 2004
Huitema、他 情報[18ページ]のRFC3904Unmanagedは2004年9月に変遷ツールをネットワークでつなぎます。
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Huitema, et al. Informational [Page 19]
Huitema、他 情報[19ページ]
一覧
スポンサーリンク
