[要約] RFC 6586は、IPv6-Onlyネットワークの経験に関する報告書であり、IPv6のみを使用するネットワークの実装と運用に関する洞察を提供することを目的としています。
Internet Engineering Task Force (IETF) J. Arkko
Request for Comments: 6586 A. Keranen
Category: Informational Ericsson
ISSN: 2070-1721 April 2012
Experiences from an IPv6-Only Network
IPv6のみのネットワークからの体験
Abstract
概要
This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. The document covers practical experiences as well as roadblocks and opportunities for this type of a network setup. The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design. The document also discusses further work that is needed to make IPv6-only networking applicable in all environments.
このドキュメントでは、NAT64デバイスを介してインターネットのIPv4のみの部分にアクセスして、少数のユーザーをIPv6のみのネットワークに移動した経験について説明します。このドキュメントでは、このタイプのネットワーク設定の実際の経験と障害、および機会について説明します。このドキュメントでは、このようなネットワークを適用できる場所や、ネットワーク設計で考慮すべき点についてもいくつか推奨しています。このドキュメントでは、IPv6のみのネットワークをすべての環境に適用できるようにするために必要なさらなる作業についても説明しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6586.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6586で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Technology and Terminology ......................................4
3. Network Setup ...................................................4
3.1. The IPv6-Only Network ......................................5
3.2. DNS Operation ..............................................6
4. General Experiences .............................................7
5. Experiences with IPv6-Only Networking ...........................9
5.1. Operating Systems ..........................................9
5.2. Programming Languages and APIs ............................10
5.3. Instant Messaging and VoIP ................................11
5.4. Gaming ....................................................12
5.5. Music Services ............................................13
5.6. Appliances ................................................13
5.7. Other Differences .........................................13
6. Experiences with NAT64 .........................................13
6.1. IPv4 Address Literals .....................................14
6.2. Comparison of Web Access via NAT64 to Other Methods .......15
7. Future Work ....................................................15
8. Conclusions and Recommendations ................................16
9. Security Considerations ........................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
Appendix A. Acknowledgments .......................................21
This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. This arrangement has been done with a permanent change in mind rather than as a temporary experiment, involves both office and home users, heterogeneous computing equipment, and varied applications. We have learned both practical details, roadblocks and opportunities, as well as a more general understanding of when such a configuration can be recommended and what should be taken into account in the network design. Note that this memo documents our experiences primarily from 2010. As time goes by, the situation changes with updated software versions, newer products, and so on.
このドキュメントでは、NAT64デバイスを介してインターネットのIPv4のみの部分にアクセスして、少数のユーザーをIPv6のみのネットワークに移動した経験について説明します。この配置は、一時的な実験ではなく永続的な変更を念頭に置いて行われ、オフィスとホームの両方のユーザー、異種コンピューティング機器、およびさまざまなアプリケーションが含まれます。実用的な詳細、障害、および機会の両方を学習し、そのような構成を推奨できるタイミングとネットワーク設計で何を考慮すべきかについてのより一般的な理解を学びました。このメモは主に2010年からの私たちの経験を文書化していることに注意してください。時間が経つにつれ、状況はソフトウェアバージョンの更新や新しい製品などによって変化します。
The networks involved in this setup have been in dual-stack mode for a considerable amount of time, in one case, for over ten years. Our IPv6 connectivity is stable and in constant use with no significant problems. Given that the IETF is working on technology such as NAT64 [RFC6144] and several network providers are discussing the possibility of employing IPv6-only networking, we decided to take our network beyond the "comfort zone" and make sure that we understand the implications of having no IPv4 connectivity at all. This also allowed us to test a NAT64 device that is being developed by Ericsson.
このセットアップに関係するネットワークは、かなりの時間、1つのケースでは10年以上、デュアルスタックモードになっています。当社のIPv6接続は安定しており、重大な問題はなく、常に使用されています。 IETFがNAT64 [RFC6144]などの技術に取り組んでおり、いくつかのネットワークプロバイダーがIPv6のみのネットワーキングを採用する可能性について議論していることを踏まえ、ネットワークを「コンフォートゾーン」を超えて取り上げ、 IPv4接続がまったくありません。これにより、エリクソンが開発中のNAT64デバイスをテストすることもできました。
The main conclusion is that it is possible to employ IPv6-only networking, though there are a number of issues such as lack of IPv6 support in some applications and bugs in untested parts of code. As a result, dual-stack [RFC4213] remains as our recommended model for general purpose networking at this time, but IPv6-only networking can be employed by early adopters or highly controlled networks. The document also suggests actions to make IPv6-only networking applicable in all environments. In particular, resolving problems with a few key applications would have a significant impact for enabling IPv6-only networking for large classes of users and networks. It is important that the Internet community understands these deployment barriers and works to remove them.
主な結論は、一部のアプリケーションでのIPv6サポートの欠如やコードのテストされていない部分のバグなど、多くの問題がありますが、IPv6のみのネットワークを使用することが可能であるということです。その結果、現時点ではデュアルスタック[RFC4213]が汎用ネットワーキングの推奨モデルとして残っていますが、IPv6のみのネットワーキングはアーリーアダプターや高度に制御されたネットワークで使用できます。このドキュメントでは、IPv6のみのネットワークをすべての環境に適用できるようにするためのアクションも提案されています。特に、いくつかの主要なアプリケーションで問題を解決すると、大規模なクラスのユーザーとネットワークでIPv6のみのネットワークを有効にする際に大きな影響があります。インターネットコミュニティがこれらの展開の障壁を理解し、それらを取り除くために取り組むことが重要です。
The rest of this document is organized as follows. Section 2 introduces some relevant technology and terms, Section 3 describes the network setup, Section 4 discusses our general experiences, Section 5 discusses experiences related to having only IPv6 networking available, and Section 6 discusses experiences related to NAT64 use. Finally, Section 7 presents some of our ideas for future work, Section 8 draws conclusions and makes recommendations on when and how one should employ IPv6-only networks, and Section 9 discusses relevant security considerations.
このドキュメントの残りの部分は、次のように構成されています。セクション2は関連するテクノロジーと用語の紹介、セクション3はネットワークの設定、セクション4は一般的な経験、セクション5はIPv6ネットワーキングのみの利用に関連する経験、セクション6はNAT64の使用に関連する経験について説明しています。最後に、セクション7は将来の作業に関するいくつかのアイデアを提示し、セクション8は結論を導き、IPv6のみのネットワークをいつどのように使用すべきかについて推奨を行い、セクション9は関連するセキュリティの考慮事項について説明します。
In this document, the following terms are used. "NAT44" refers to any IPv4-to-IPv4 network address translation algorithm, both "Basic NAT" and "Network Address/Port Translator (NAPT)", as defined by [RFC2663].
このドキュメントでは、次の用語が使用されています。 「NAT44」は、[RFC2663]で定義されている「基本NAT」と「ネットワークアドレス/ポートトランスレータ（NAPT）」の両方のIPv4-to-IPv4ネットワークアドレス変換アルゴリズムを指します。
"Dual-stack" refers to a technique for providing complete support for both Internet protocols -- IPv4 and IPv6 -- in hosts and routers [RFC4213].
「デュアルスタック」とは、ホストとルーターで、IPv4とIPv6の両方のインターネットプロトコルを完全にサポートするための手法を指します[RFC4213]。
"NAT64" refers to a Network Address Translator - Protocol Translator defined in [RFC6144], [RFC6145], [RFC6146], [RFC6052], [RFC6147], and [RFC6384].
「NAT64」は、[RFC6144]、[RFC6145]、[RFC6146]、[RFC6052]、[RFC6147]、および[RFC6384]で定義されたネットワークアドレストランスレータ-プロトコルトランスレータを指します。
We have tested IPv6-only networking in two different network environments: office and home. In both environments, all hosts had normal dual-stack native IPv4 and IPv6 Internet access already in place. The networks were also already employing IPv6 in their servers and DNS records. Similarly, the network was a part of whitelisting arrangement to ensure that IPv6-capable content providers would be able to serve their content to the network over IPv6.
IPv6のみのネットワーキングは、オフィスとホームという2つの異なるネットワーク環境でテストされています。どちらの環境でも、すべてのホストは、通常のデュアルスタックネイティブIPv4およびIPv6インターネットアクセスをすでに備えていました。ネットワークは、すでにサーバーとDNSレコードでIPv6を採用していました。同様に、ネットワークは、IPv6対応のコンテンツプロバイダーがIPv6を介してネットワークにコンテンツを提供できるようにするためのホワイトリスト登録の一部でした。
The office environment has heterogeneous hardware with PCs, laptops, and routers running Linux, BSD, Mac OS X, and Microsoft Windows operating systems. Common uses of the network include email, Secure Shell (SSH), web browsing, and various instant messaging and Voice over IP (VoIP) applications. The hardware in the home environment consists of PCs, laptops, and a number of server, camera, and sensor appliances. The primary operating systems in this environment are Linux and Microsoft Windows operating systems. Common applications include web browsing, streaming, instant messaging and VoIP applications, gaming, file storage, and various home control applications. Both environments employ extensive firewalling practices, and filtering is applied for both IPv4 and IPv6 traffic. However, firewall capabilities, especially with older versions of firewall software, dictate some differences between the filtering applied for IPv4 and IPv6 since some features commonly supported for IPv4 were not yet implemented for IPv6. In addition, in the home environment, the individual devices are directly accessible from the Internet on IPv6 (on select protocols such as SSH) but not on IPv4 due to lack of available public IPv4 addresses.
オフィス環境には、Linux、BSD、Mac OS X、およびMicrosoft Windowsオペレーティングシステムを実行するPC、ラップトップ、およびルーターを備えた異種ハードウェアがあります。ネットワークの一般的な用途には、電子メール、Secure Shell（SSH）、Webブラウジング、さまざまなインスタントメッセージング、Voice over IP（VoIP）アプリケーションなどがあります。家庭環境のハードウェアは、PC、ラップトップ、および多数のサーバー、カメラ、センサーアプライアンスで構成されています。この環境の主要なオペレーティングシステムは、LinuxおよびMicrosoft Windowsオペレーティングシステムです。一般的なアプリケーションには、Webブラウジング、ストリーミング、インスタントメッセージングおよびVoIPアプリケーション、ゲーム、ファイルストレージ、およびさまざまなホームコントロールアプリケーションが含まれます。どちらの環境も広範なファイアウォールプラクティスを採用しており、フィルタリングはIPv4トラフィックとIPv6トラフィックの両方に適用されます。ただし、特に古いバージョンのファイアウォールソフトウェアでのファイアウォール機能では、IPv4に一般的にサポートされている一部の機能がIPv6にまだ実装されていないため、IPv4とIPv6に適用されるフィルタリングにいくつかの違いがあります。さらに、家庭環境では、利用可能なパブリックIPv4アドレスがないため、IPv6（SSHなどの一部のプロトコル）ではインターネットから個々のデバイスに直接アクセスできますが、IPv4ではアクセスできません。
In both environments, volunteers had the possibility to opt-in for the IPv6-only network. The number of users was small: there were roughly five permanent users and a dozen users who had been in the network at least for some amount of time. Each user had to connect to the IPv6-only wired or wireless network and, depending on their software, possibly configure their computer by indicating that there is no IPv4 and/or setting DNS server addresses. The users were also asked to report their experiences back to the organizers.
どちらの環境でも、ボランティアはIPv6のみのネットワークにオプトインする可能性がありました。ユーザーの数は少なかった。およそ5人の永続的なユーザーと、少なくともある程度の期間ネットワークに接続していた12人のユーザーがいた。各ユーザーは、IPv6のみの有線または無線ネットワークに接続する必要があり、ソフトウェアによっては、IPv4がないことを示したり、DNSサーバーアドレスを設定したりして、コンピューターを構成する必要があります。ユーザーはまた、彼らの経験を主催者に報告するよう求められました。
The IPv6-only network was provided as a parallel network on the side of the already existing dual-stack network. It was important to retain the dual-stack network for the benefit of those users who did not decide to opt-in and because we knew that there were some IPv4- only devices in the network. A separate wired access network was created using Virtual Local Area Networks (VLANs). This network had its own IPv6 prefix. A separate wireless network, bridged to the wired network, was also created. In our case, the new wireless network required additional access point hardware in order to accommodate advertising multiple wireless networks. The simple access point model that we employed in these networks did not allow this on a single device, although many other access points support this. All the secondary infrastructure resulted in some additional management burden and cost, however. An added complexity was that the home network already employed two types of infrastructure, one for family members and another one for visitors. In order to duplicate this model for the IPv6-only network, there are now four separate networks, with several access points on each.
IPv6のみのネットワークは、既存のデュアルスタックネットワークの側面に並列ネットワークとして提供されました。オプトインすることを決定しなかったユーザーの利益のために、またネットワーク内にいくつかのIPv4専用デバイスが存在することがわかっていたため、デュアルスタックネットワークを保持することが重要でした。個別の有線アクセスネットワークは、仮想ローカルエリアネットワーク（VLAN）を使用して作成されました。このネットワークには独自のIPv6プレフィックスがありました。有線ネットワークにブリッジされる別のワイヤレスネットワークも作成されました。今回のケースでは、複数のワイヤレスネットワークのアドバタイズに対応するために、新しいワイヤレスネットワークに追加のアクセスポイントハードウェアが必要でした。これらのネットワークで採用したシンプルなアクセスポイントモデルでは、単一のデバイスでこれを行うことはできませんでしたが、他の多くのアクセスポイントがこれをサポートしています。ただし、すべての二次インフラストラクチャにより、管理の負担とコストが追加されました。さらに複雑なのは、ホームネットワークがすでに2種類のインフラストラクチャを採用していることです。1つは家族用で、もう1つは訪問者用です。このモデルをIPv6のみのネットワークに複製するために、4つの個別のネットワークがあり、それぞれにいくつかのアクセスポイントがあります。
A stateful NAT64 [RFC6146] with integrated DNS64 was installed on the edge of the IPv6-only networks. No IPv4 routing or Dynamic Host Configuration Protocol (DHCP) was offered on these networks. The NAT64 device sends Router Advertisements (RAs) [RFC4861] from which the hosts learn the IPv6 prefix and can automatically configure IPv6 addresses for them. Each new IPv6-only network needed one new /64 prefix to be used in these advertisements. In addition, each NAT64 device needed another /64 prefix to be used for the representation of IPv4 destinations in the IPv6-only network. As a result, one IPv6- only network requires /63 of address space. This space was easily available in our networks, as IPv6 allocations are purposefully made in sufficiently large blocks. Additional address space needs can be accommodated from the existing block without registry involvement. Another option would have been to use the Well-Known Prefix [RFC6052] for the representation of IPv4 destinations in the IPv6-only network. In any case, the prefixes have to be listed in the intra-domain routing system so that they can be reached. In one case, the increase from one block to multiple also made it necessary to employ an improved routing configuration. In addition to routing, the new prefixes have to be listed in the appropriate firewall rules.
DNS64が統合されたステートフルNAT64 [RFC6146]がIPv6のみのネットワークのエッジにインストールされました。これらのネットワークでは、IPv4ルーティングまたは動的ホスト構成プロトコル（DHCP）は提供されていません。 NAT64デバイスはルーターアドバタイズ（RA）[RFC4861]を送信します。ホストはそこからIPv6プレフィックスを学習し、IPv6アドレスを自動的に構成できます。新しいIPv6専用ネットワークごとに、これらのアドバタイズで使用する1つの新しい/ 64プレフィックスが必要でした。さらに、各NAT64デバイスには、IPv6のみのネットワークでIPv4宛先を表すために使用する別の/ 64プレフィックスが必要でした。その結果、1つのIPv6のみのネットワークに/ 63のアドレス空間が必要になります。このスペースは、IPv6割り当てが十分に大きなブロックで意図的に行われているため、ネットワークで簡単に利用できました。追加のアドレススペースのニーズは、レジストリに関与することなく、既存のブロックから対応できます。別のオプションは、IPv6のみのネットワークでIPv4宛先を表すために既知のプレフィックス[RFC6052]を使用することでした。いずれの場合も、プレフィックスに到達できるように、プレフィックスをドメイン内ルーティングシステムにリストする必要があります。 1つのケースでは、1つのブロックから複数のブロックへの増加により、改善されたルーティング構成を採用する必要が生じました。ルーティングに加えて、新しいプレフィックスを適切なファイアウォールルールにリストする必要があります。
Setting up NAT64 and DNS64 by themselves is easy and can be done quickly by an experienced network manager. However, when duplicate infrastructure is needed for dual-stack and IPv6-only networks, the additional switches, cables, access points, etc., will take some amount of installation effort. In addition, if whitelisting agreements or IPv6 ISP connectivity is needed, setting these up requires negotiations with external partners.
NAT64とDNS64を自分で設定するのは簡単で、経験豊富なネットワーク管理者がすばやく行うことができます。ただし、デュアルスタックおよびIPv6のみのネットワークに重複するインフラストラクチャが必要な場合は、追加のスイッチ、ケーブル、アクセスポイントなどにより、ある程度のインストール作業が必要になります。さらに、ホワイトリスト契約またはIPv6 ISP接続が必要な場合、これらを設定するには外部パートナーとの交渉が必要です。
Router Advertisements are used to carry DNS Configuration options [RFC6106], listing the DNS64 as the DNS server the hosts should use. In addition, aliases were added to the DNS64 device to allow it to receive packets on the well-known DNS server addresses that Windows operating systems use (fec0:0:0:ffff::1, fec0:0:0:ffff::2, and fec0: 0:0:ffff::3). At a later stage, support for stateless DHCPv6 [RFC3736] was added. We do recommend enabling RFC 6106, well-known addresses, and stateless DHCPv6 in order to maximize the likelihood of different types of IPv6-only hosts being able to use DNS without manual configuration. DNS server discovery was never a problem in dual-stack networks, because DNS servers on the IPv4 side can easily provide IPv6 information (AAAA records) as well. With IPv6-only networking, it becomes crucial that the local DNS server can also be reached via IPv6. In principle, this is exactly the same as needing IPv4-based DNS and DNS discovery in IPv4-only networks. However, in IPv6, the discovery mechanisms are somewhat more complicated because there are several alternative techniques.
ルーター通知は、DNS構成オプション[RFC6106]を伝達するために使用され、ホストが使用するDNSサーバーとしてDNS64をリストします。さらに、Windowsオペレーティングシステムが使用する既知のDNSサーバーアドレス（fec0：0：0：ffff :: 1、fec0：0：0：ffff：:)でパケットを受信できるように、エイリアスがDNS64デバイスに追加されました。 2、およびfec0：0：0：ffff :: 3）。後の段階で、ステートレスDHCPv6 [RFC3736]のサポートが追加されました。手動設定なしでさまざまなタイプのIPv6のみのホストがDNSを使用できる可能性を最大にするために、RFC 6106、既知のアドレス、およびステートレスDHCPv6を有効にすることをお勧めします。 IPv4側のDNSサーバーはIPv6情報（AAAAレコード）も簡単に提供できるため、DNSサーバーの検出がデュアルスタックネットワークで問題になることはありませんでした。 IPv6のみのネットワーキングでは、ローカルDNSサーバーがIPv6経由でも到達できることが重要になります。原則として、これはIPv4のみのネットワークでIPv4ベースのDNSおよびDNS検出が必要な場合とまったく同じです。ただし、IPv6では、いくつかの代替手法があるため、検出メカニズムは多少複雑になります。
When a host served by the DNS64 asks for a domain name that does not have a AAAA (IPv6 address) record, but has an A (IPv4 address) record, a AAAA record is synthesized from the A record (as defined for DNS64 in [RFC6147]) and sent in the DNS response to the host. IP packets sent to this synthesized address are routed via the NAT64, translated to IPv4 by the NAT64, and forwarded to the queried host's IPv4 address; return traffic is translated back from IPv4 to IPv6 and forwarded to the host behind the NAT64 (as described in [RFC6144]). This allows the hosts in the IPv6-only network to contact any host in the IPv4 Internet as long as the hosts in the IPv4 Internet have DNS address records.
DNS64がサービスを提供するホストが、AAAA（IPv6アドレス）レコードはないがA（IPv4アドレス）レコードがあるドメイン名を要求すると、AAAAレコードはAレコードから合成されます（[ RFC6147]）、DNS応答でホストに送信されます。この合成アドレスに送信されたIPパケットは、NAT64を介してルーティングされ、NAT64によってIPv4に変換され、照会されたホストのIPv4アドレスに転送されます。リターントラフィックはIPv4からIPv6に変換され、NAT64の背後にあるホストに転送されます（[RFC6144]で説明されています）。これにより、IPv6のみのネットワーク内のホストは、IPv4インターネット内のホストにDNSアドレスレコードがある限り、IPv4インターネット内の任意のホストに接続できます。
The NAT64 devices have standard dual-stack connectivity and their DNS64 function can use both IPv4 and IPv6 when requesting information from DNS. A destination that has both an A and AAAA records is not treated in any special manner, because the hosts in the IPv6-only network can contact the destination over IPv6. Destinations with only an A record will be given a synthesized AAAA record as explained above. However, in one of our open visitor networks that is sharing the infrastructure with the home network, we needed a special arrangement. Currently, the home network obtains its IPv6 connectivity through a tunnel via the office network, and it is undesirable to allow outsiders using the visitor network to generate traffic through the office network, even if the traffic is just passing by and forwarded to the IPv6 Internet. As a result, in the visitor network, there is a special IPv6-only to IPv4-only configuration where the DNS64 never asks for AAAA records and always generates synthesized records. Therefore, no traffic from the visitor network, even if it is destined to the IPv6 Internet, is routed via the office network, but traffic from the home network can still use the IPv6 connectivity provided by the office network.
NAT64デバイスには標準のデュアルスタック接続があり、そのDNS64機能はDNSから情報を要求するときにIPv4とIPv6の両方を使用できます。 AおよびAAAAレコードの両方を持つ宛先は、IPv6のみのネットワーク内のホストがIPv6経由で宛先に接続できるため、特別な方法で処理されません。 Aレコードのみの宛先には、上記で説明したように合成されたAAAAレコードが与えられます。ただし、インフラストラクチャをホームネットワークと共有しているオープンビジターネットワークの1つでは、特別な手配が必要でした。現在、ホームネットワークは、オフィスネットワークを介してトンネルを介してIPv6接続を取得しており、トラフィックがIPv6インターネットを通過して転送されているだけでも、ビジターネットワークを使用する部外者がオフィスネットワークを介してトラフィックを生成できるようにすることは望ましくありません。 。その結果、ビジターネットワークでは、DNS64がAAAAレコードを要求せず、常に合成レコードを生成する特別なIPv6-onlyからIPv4-onlyの構成があります。したがって、ビジターネットワークからのトラフィックは、IPv6インターネット宛てであっても、オフィスネットワーク経由でルーティングされませんが、ホームネットワークからのトラフィックは、オフィスネットワークによって提供されるIPv6接続を引き続き使用できます。
Note: This configuration may also be useful for other purposes. For instance, one drawback of the standard behavior is that if a destination publishes AAAA records but has bad IPv6 connectivity, the hosts in the IPv6-only network have no fallback. In the dual-stack model, a host can always try IPv4 if the IPv6 connection fails. In the special configuration, IPv6 is only used internally at the site but never across the Internet, eliminating this problem. This is not a recommended mode of operation, but it is interesting to note that it may solve some issues.
注：この構成は、他の目的にも役立つ場合があります。たとえば、標準の動作の1つの欠点は、宛先がAAAAレコードを公開しているがIPv6接続が不良である場合、IPv6のみのネットワークのホストにはフォールバックがないことです。デュアルスタックモデルでは、IPv6接続が失敗した場合、ホストは常にIPv4を試すことができます。特別な構成では、IPv6はサイト内でのみ使用され、インターネット全体では使用されないため、この問題は解消されます。これは推奨される操作モードではありませんが、いくつかの問題を解決できる可能性があることに注意してください。
Note that in NAT64 (unlike in its older variant [RFC4966]) it is possible to decouple the packet translation, IPv6 routing, and DNS64 functions. Since clients are configured to use a DNS64 as their DNS server, there is no need for having an Application Layer Gateway (ALG) on the path sniffing and spoofing DNS packets. This decoupling possibility was implemented by one of our users, as he is outside of our physical network and wants to communicate directly on IPv6 where it is possible without having to go through our central network equipment. His DNS queries go to our DNS64 and to establish communications to an IPv4 destination our central NAT64 is used. If there is a need to translate some packets, these packets find the translator device through normal IPv6 routing means since the synthesized addresses have our NAT64's prefix. However, for non-synthesized IPv6 addresses the packets are routed directly to the destination.
NAT64では（古いバリアント[RFC4966]とは異なり）、パケット変換、IPv6ルーティング、およびDNS64機能を分離できることに注意してください。クライアントはDNSサーバーとしてDNS64を使用するように構成されているため、パス上にアプリケーションレイヤーゲートウェイ（ALG）を配置してDNSパケットを傍受および偽装する必要はありません。この分離の可能性は、ユーザーの1人によって実装されました。彼は私たちの物理ネットワークの外にいて、中央のネットワーク機器を経由せずに可能なIPv6で直接通信したいからです。彼のDNSクエリはDNS64に送信され、IPv4宛先への通信を確立するために中央のNAT64が使用されます。一部のパケットを変換する必要がある場合、合成されたアドレスにはNAT64のプレフィックスが付いているため、これらのパケットは通常のIPv6ルーティング手段を介してトランスレータデバイスを見つけます。ただし、合成されていないIPv6アドレスの場合、パケットは宛先に直接ルーティングされます。
Based on our experiences, it is possible to live (and work) with an IPv6-only network. For instance, at the time of this writing, one of the authors has been in an IPv6-only network for about a year and a half and has had no major problems. Most things work well in the new environment; for example, we have been unable to spot any practical difference in the web browsing (HTTP and HTTPS) experience. Also, email, software upgrades, operating system services, many chat systems, and media streaming work well. On certain Symbian mobile handsets that we tried, all applications work even on an IPv6-only network. In another case, with the Android operating system, all the basic applications worked without problems. In order to make the latter handset architecture support IPv6-only networks, however, a small change was needed in the operating system so that it could discover IPv6-only DNS servers.
私たちの経験に基づいて、IPv6のみのネットワークで生活（および作業）することが可能です。たとえば、この記事の執筆時点では、著者の1人がIPv6のみのネットワークに約1年半滞在しており、大きな問題はありませんでした。ほとんどのことが新しい環境でうまく機能します。たとえば、ウェブブラウジング（HTTPおよびHTTPS）エクスペリエンスの実用的な違いを見つけることはできませんでした。また、メール、ソフトウェアのアップグレード、オペレーティングシステムサービス、多くのチャットシステム、メディアストリーミングも適切に機能します。私たちが試した特定のSymbianモバイルハンドセットでは、すべてのアプリケーションがIPv6のみのネットワーク上でも機能します。別のケースでは、Androidオペレーティングシステムでは、すべての基本的なアプリケーションが問題なく動作しました。ただし、後者のハンドセットアーキテクチャでIPv6のみのネットワークをサポートするには、IPv6のみのDNSサーバーを検出できるように、オペレーティングシステムに小さな変更を加える必要がありました。
However, in general, there is some pain involved and thus IPv6-only networking is not suitable for everyone just yet. Switching IPv4 off does break many things as well. Some of the users in our environment left due to these issues, as they missed some key feature that they needed from their computing environment. These issues fall in several categories:
ただし、一般に、多少の苦痛が伴うため、IPv6のみのネットワーキングはまだすべての人に適しているわけではありません。 IPv4をオフに切り替えると、多くの点で問題が発生します。私たちの環境の一部のユーザーは、これらの問題のために、コンピューティング環境から必要ないくつかの重要な機能を逃したために去りました。これらの問題はいくつかのカテゴリに分類されます。
Bugs
バグ
We saw many issues that can be classified as bugs, likely related to so few people having tried the software in question in an IPv6- only network. For instance, some operating system facilities support IPv6 but have annoying problems that are only uncovered in IPv6-only networking.
バグとして分類できる多くの問題が見られましたが、IPv6のみのネットワークで問題のソフトウェアを試した人が非常に少ないためと考えられます。たとえば、一部のオペレーティングシステムファシリティはIPv6をサポートしていますが、IPv6のみのネットワーキングでしか発見されない厄介な問題があります。
Lack of IPv6 Support
IPv6サポートの欠如
We also saw many applications that do not support IPv6 at all. These range from minor, old tools (such as the Unix dict(1) command) to major applications that are important to our users (such as Skype) and even to entire classes of applications (many games have issues). As our experiment continued, we have seen improvements in some areas, such as gaming.
また、IPv6をまったくサポートしていないアプリケーションも数多く見られました。これらは、マイナーで古いツール（Unix dict（1）コマンドなど）からユーザーにとって重要な主要アプリケーション（Skypeなど）まで、さらにはアプリケーションのクラス全体（多くのゲームで問題があります）までさまざまです。実験を続けると、ゲームなどのいくつかの領域で改善が見られました。
Protocol, Format, and Content Problems
プロトコル、フォーマット、コンテンツの問題
There are many protocols that carry IP addresses in them, and using these protocols through a translator can lead to problems. In our current network setup, we did not employ any ALGs except for FTP [RFC6384]. However, we have observed a number of protocol issues with IPv4 addresses. For instance, some instant messaging services do not work due to this. Finally, content on some web pages may refer to IPv4 address literals (i.e., plain IP addresses instead of host and domain names). This renders some links inaccessible in an IPv6-only network. While this problem is easily quantifiable in measurements, the authors have run into it only a couple of times during real-life web browsing.
IPアドレスを伝送する多くのプロトコルがあり、トランスレータを介してこれらのプロトコルを使用すると問題が発生する可能性があります。現在のネットワーク設定では、FTP [RFC6384]以外のALGは使用していません。ただし、IPv4アドレスに関する多くのプロトコルの問題が確認されています。たとえば、一部のインスタントメッセージングサービスはこれが原因で機能しません。最後に、一部のWebページのコンテンツは、IPv4アドレスリテラル（ホスト名やドメイン名ではなくプレーンIPアドレス）を参照している場合があります。これにより、IPv6のみのネットワークでは一部のリンクにアクセスできなくなります。この問題は測定で簡単に定量化できますが、著者は実際のWebブラウジング中に数回だけ問題に遭遇しました。
Firewall Issues
ファイアウォールの問題
We also saw a number of issues related to lack of features in IPv6 support in firewalls. In particular, while we did not experience any Maximum Transmission Unit (MTU) and fragmentation problems in our networks, there is potential for generating problems, as the support for IPv6 fragment headers is not complete in all firewalls and the NAT64 specifications call for use of the fragment header (even in situations where fragmentation has not yet occurred, e.g., if an IPv4 packet that is not a fragment does not have the Don't Fragment (DF) bit set).
ファイアウォールでのIPv6サポートの機能の欠如に関連する多くの問題も確認しました。特に、ネットワークで最大伝送ユニット（MTU）とフラグメンテーションの問題は発生していませんが、IPv6フラグメントヘッダーのサポートがすべてのファイアウォールで完全ではなく、NAT64仕様での使用が求められているため、問題が発生する可能性がありますフラグメントヘッダー（フラグメント化されていないIPv4パケットにフラグメント化されていない（DF）ビットが設定されていない場合など）。
In general, most of the issues relate to poor testing and lack of IPv6 support in some applications. IPv6 itself and NAT64 did not cause any major issues for us, once our setup and NAT64 software was stable. In general, the authors feel that with the exception of some applications, our experience with translation to reach the IPv4 Internet has been equal to our past experiences with NAT44-based Internet access. While translation implies loss of end-to-end connectivity, in practice, direct connectivity has also not been available to the authors in the IPv4 Internet for a number of years.
一般に、ほとんどの問題は、一部のアプリケーションでの不十分なテストとIPv6サポートの欠如に関連しています。 IPv6自体とNAT64は、セットアップとNAT64ソフトウェアが安定したら、大きな問題を引き起こしませんでした。一般的に、著者は、一部のアプリケーションを除いて、IPv4インターネットに到達するための翻訳の経験は、NAT44ベースのインターネットアクセスのこれまでの経験と同じであると感じています。変換はエンドツーエンドの接続の喪失を意味しますが、実際には、長年にわたってIPv4インターネットの作成者が直接接続を利用することもできませんでした。
It should be noted that the experience with a properly configured set of ALGs and workarounds such as proxies may be different. Some of the problems we encountered can be solved through these means. For instance, a problematic application can be configured to use a proxy that in turn has both IPv4 and IPv6 access.
ALGの適切に構成されたセットとプロキシなどの回避策でのエクスペリエンスは異なる場合があることに注意してください。私たちが遭遇した問題のいくつかは、これらの手段によって解決することができます。たとえば、問題のあるアプリケーションは、IPv4とIPv6の両方のアクセス権を持つプロキシを使用するように構成できます。
The overall experience was as explained above. The remainder of this section discusses specific issues with different operating systems, programming languages, applications, and appliances.
全体的な経験は、上で説明したとおりです。このセクションの残りの部分では、さまざまなオペレーティングシステム、プログラミング言語、アプリケーション、およびアプライアンスの特定の問題について説明します。
Even operating systems have some minor problems with IPv6. For example, in Linux, Router Advertisement (RA) information is not automatically updated when the network changes while the computer is on, and this requires an unnecessary suspend/resume cycle to restore its proper state. We have also had issues with the rdnssd daemon, which first does not come as a default feature in Ubuntu and does not always appear to work reliably. To resolve these issues, we had to configure the network manager to use a specific server address. Later, a new version of the Linux distribution that we used solved these problems, even if some problems still remained. For instance, in the latest Ubuntu Long-Term Support release (10.04), we have experienced that the network manager by default returns to an available IPv4 wireless network even if there is a previously used IPv6-only network available and the IPv4 network has no global connectivity before a web-based login is completed.
オペレーティングシステムでさえ、IPv6でいくつかの小さな問題があります。たとえば、Linuxでは、コンピューターの電源が入っているときにネットワークが変更されてもルーターアドバタイズ（RA）情報は自動的に更新されません。そのため、適切な状態を復元するには、不必要な中断/再開サイクルが必要です。また、rdnssdデーモンにも問題がありました。これは、最初はUbuntuのデフォルト機能として提供されておらず、常に確実に機能するとは限りません。これらの問題を解決するには、特定のサーバーアドレスを使用するようにネットワークマネージャーを構成する必要がありました。その後、使用したLinuxディストリビューションの新しいバージョンにより、いくつかの問題が残っていたとしても、これらの問題は解決されました。たとえば、最新のUbuntu長期サポートリリース（10.04）では、以前に使用されていたIPv6のみのネットワークが利用可能で、IPv4ネットワークにない場合でも、デフォルトでネットワークマネージャーが利用可能なIPv4ワイヤレスネットワークに戻ることがありました。 Webベースのログインが完了する前のグローバル接続。
In Mac OS X (Snow Leopard), the network manager needed to be explicitly told not to expect IPv4. A more annoying issue was that in order to switch between an IPv6-only and IPv4-only network, these settings had to be manually changed, making it undesirable for Mac OS X users to employ IPv6-only networks.
Mac OS X（Snow Leopard）では、ネットワーク管理者はIPv4を期待しないように明示的に指示される必要がありました。さらに厄介な問題は、IPv6のみのネットワークとIPv4のみのネットワークを切り替えるために、これらの設定を手動で変更する必要があり、Mac OS XユーザーがIPv6のみのネットワークを使用することが望ましくないことでした。
Also, on Microsoft Windows 7, we experienced problems when relying on default, well-known DNS server addresses: without manual configuration, the host was unable to use the DNS addresses, even though the system displays them as current DNS server addresses.
また、Microsoft Windows 7では、デフォルトの既知のDNSサーバーアドレスに依存しているときに問題が発生しました。手動で構成しないと、システムが現在のDNSサーバーアドレスとして表示しても、ホストはDNSアドレスを使用できませんでした。
Latest versions of the Android operating system support IPv6 on its wireless LAN interface, but due to lack of DNS discovery mechanisms, this does not work in IPv6-only networks. We corrected this, however, and prototype phones in our networks work well now, even in an IPv6-only environment. This change, DNS Discovery Daemon (DDD) now exists as open source software. Interestingly, all applications that we have tried so far seem to work without problems with IPv6- only connectivity, though no exhaustive testing was done, nor did we try known troublesome applications.
Androidオペレーティングシステムの最新バージョンは、ワイヤレスLANインターフェースでIPv6をサポートしていますが、DNS検出メカニズムがないため、IPv6のみのネットワークでは機能しません。ただし、これを修正し、IPv6のみの環境でも、ネットワーク内のプロトタイプ電話が正常に機能するようになりました。この変更であるDNS Discovery Daemon（DDD）は現在、オープンソースソフトウェアとして存在しています。興味深いことに、これまでに試したすべてのアプリケーションは、IPv6のみの接続では問題なく機能しているようですが、徹底的なテストは行われていません。また、既知の問題のあるアプリケーションも試していません。
While all these operating systems (or their predecessors) have already supported IPv6 for a number of years, these kinds of small glitches seem to imply that they have not been thoroughly tested in networks lacking IPv4 connectivity. At the very least, their usability leaves something to be desired.
これらすべてのオペレーティングシステム（またはそれらの前身）はすでに長年にわたってIPv6をサポートしていますが、この種の小さな不具合は、IPv4接続のないネットワークで完全にテストされていないことを意味するようです。少なくとも、それらのユーザビリティは、望まれるべきものを残しています。
For applications to be able to support IPv6, they need access to the necessary APIs. Luckily, IPv6 seems to be well supported by a majority of the commonly used APIs. The Perl programming language used to be an exception with only partial IPv6 support up to the version 5.14 (released May 14, 2011). This version finally includes full IPv6 support, with that in the core libraries and older modules being updated as well. With previous versions of Perl, while IPv6 socket support is available as an extension module, it may not be possible to install this module without administrative rights. This has also resulted in other networking core libraries (such as FTP and SMTP) not being able to fully support IPv6; thus, many existing Perl programs using network functionality may not work properly in an IPv6-only environment.
アプリケーションがIPv6をサポートできるようにするには、必要なAPIにアクセスする必要があります。幸いにも、IPv6は一般的に使用されるAPIの大部分で十分にサポートされているようです。以前はPerlプログラミング言語は例外でしたが、バージョン5.14（2011年5月14日リリース）まではIPv6の部分的なサポートしかありませんでした。このバージョンにはついにIPv6の完全なサポートが含まれ、コアライブラリと古いモジュールのバージョンも更新されます。以前のバージョンのPerlでは、IPv6ソケットのサポートを拡張モジュールとして使用できますが、管理者権限がないとこのモジュールをインストールできない場合があります。これにより、他のネットワーキングコアライブラリ（FTPやSMTPなど）がIPv6を完全にサポートできなくなりました。したがって、ネットワーク機能を使用する既存の多くのPerlプログラムは、IPv6のみの環境では適切に機能しない可能性があります。
By far, the biggest complaint from our group of users was that Skype stopped working. In some environments, even Skype can be made to work through a proxy configuration, and this was verified in our setting but not used as a permanent solution. More generally, we tested a number of instant messaging applications in an IPv6-only network with NAT64; the test results can be found in Table 1. The versions used in the tests were the latest versions available in the summer of 2010.
ユーザーグループからの最大の不満は、Skypeが機能しなくなったことです。一部の環境では、Skypeでさえプロキシ構成を介して機能させることができ、これは私たちの設定で検証されましたが、永続的なソリューションとしては使用されませんでした。より一般的には、NAT64を使用するIPv6のみのネットワークでいくつかのインスタントメッセージングアプリケーションをテストしました。テスト結果は表1に記載されています。テストで使用されたバージョンは2010年夏に入手可能な最新バージョンでした。
SYSTEM STATUS
システムステータス
Facebook on the web (http) OK Facebook via a client (xmpp) OK Jabber.org chat service (xmpp) OK Gmail chat on the web (http) OK Gmail chat via a client (xmpp) OK Google Talk client NOT OK AIM (AOL) NOT OK ICQ (AOL) NOT OK Skype NOT OK MSN NOT OK Webex NOT OK Sametime OK (NOW)
ウェブ上のFacebook（http）OKクライアント経由のFacebook（xmpp）OK Jabber.orgチャットサービス（xmpp）OKウェブ上のGmailチャット（http）OKクライアント経由のGmailチャット（xmpp）OK GoogleトーククライアントNOT OK AIM（ AOL）NOT OK ICQ（AOL）NOT OK Skype NOT OK MSN NOT OK Webex NOT OK Sametime OK（NOW）
Table 1. Instant Messaging Applications in an IPv6-Only Network
表1. IPv6のみのネットワークのインスタントメッセージングアプリケーション
Packet tracing revealed that the issues in AIM, ICQ, and MSN appear to be related to passing literal IPv4 addresses in the protocol. It remains to be determined whether this can be solved through configuration, proxies, or ALGs. The problem with the Google Talk client is that the software does not support IPv6 connections at this time. We are continuing our tests with additional applications, and we have also seen changes over time. For instance, a new version of Sametime suddenly started working with IPv6-only networks, presumably due to the new version being more careful with the use of DNS names as opposed to IPv4 addresses. One problem in running these tests is to ensure that we can distinguish IPv6 and NAT64 issues from other issues, such as a generic issue on a given operating system platform.
パケットトレースにより、AIM、ICQ、およびMSNの問題が、プロトコルでリテラルIPv4アドレスを渡すことに関連しているように見えることが明らかになりました。これが構成、プロキシ、またはALGによって解決できるかどうかはまだ決定されていません。 Googleトーククライアントの問題は、現時点ではソフトウェアがIPv6接続をサポートしていないことです。追加のアプリケーションを使用してテストを継続しており、時間の経過とともに変化も見られます。たとえば、新しいバージョンのSametimeが突然IPv6のみのネットワークで動作し始めたのは、おそらく新しいバージョンがIPv4アドレスではなくDNS名の使用に注意を払っていたためと考えられます。これらのテストを実行する際の1つの問題は、IPv6およびNAT64の問題を、特定のオペレーティングシステムプラットフォームの一般的な問題などの他の問題と区別できることを確認することです。
Some of these problems are solvable, however. For instance, we used localhost as a proxy for Skype, and then used SSH to tunnel to an external web proxy, bypassing Skype's limitations with regard to connecting to IPv6 destinations or even IPv6 proxies.
ただし、これらの問題のいくつかは解決可能です。たとえば、Skypeのプロキシとしてlocalhostを使用し、SSHを使用して外部のWebプロキシにトンネルし、IPv6宛先またはIPv6プロキシへの接続に関するSkypeの制限をバイパスしました。
Another class of applications that we tried was games. We tried both web-based gaming and standalone gaming applications that have "network", "Internet", or "LAN" gaming modes. The results are shown in Table 2.
私たちが試したもう1つのクラスのアプリケーションはゲームでした。私たちは、「ネットワーク」、「インターネット」、または「LAN」のゲーミングモードを備えたWebベースのゲーミングアプリケーションとスタンドアロンのゲーミングアプリケーションの両方を試しました。結果を表2に示す。
SYSTEM STATUS
システムステータス
Web-based (e.g., armorgames) OK Runescape (on the web) NOT OK Flat out 2 NOT OK Battlefield NOT OK Secondlife NOT OK Guild Wars NOT OK Age of Empires NOT OK Star Wars: Empire at War NOT OK Crysis NOT OK Lord of the Rings: Conquest NOT OK Rome Total War NOT OK Lord of the Rings: Battle for Middle Earth 2 NOT OK
Webベース（例：armorgames）OK Runescape（ウェブ上）NOT OKフラットアウト2 NOT OK戦場NOT OK Secondlife NOT OKギルドウォーズNOT OKエイジオブエンパイアNOT OKスターウォーズ：エンパイアアットウォーNOT OKクライシスNOT OKロードオブリング：征服NOT OKローマ総戦争NOT OKロードオブザリング：中つ国の戦い2 NOT OK
Table 2. Gaming Applications in an IPv6-Only Network
表2. IPv6のみのネットワークにおけるゲームアプリケーション
Most web-based games worked well, as expected from our earlier good general web experience. However, we were also able to find one web-based game that failed to work (Runescape). This particular game is a Java application that fails on an attempt to perform a HTTP GET request. The reason remains unclear, but a likely theory is the use of an IPv4-literal in the application itself.
以前の優れた一般的なWebエクスペリエンスから予想されるように、ほとんどのWebベースのゲームはうまく機能しました。ただし、機能しないWebベースのゲーム（Runescape）を1つ見つけることもできました。この特定のゲームは、HTTP GETリクエストを実行しようとして失敗するJavaアプリケーションです。理由は不明なままですが、理論としては、アプリケーション自体でのIPv4リテラルの使用が考えられます。
The experience with standalone games was far more discouraging. Without exception, all games failed to enable either connections to ongoing games in the Internet or even LAN-based connections to other computers in the same IPv6-only LAN segment. This is somewhat surprising, and the results require further verification. Unfortunately, the games provide no diagnostics about their operation, so it is hard to guess what is going on. It is possible that their networking code employs older APIs that cannot use IPv6 addresses [RFC4038]. The inability to provide any LAN-based connectivity is even more surprising, as this must mean that they are unable to use IPv4 link local connectivity, which should have been available to the devices (IPv4 was not blocked; just that no DHCP answers were provided on IPv4).
スタンドアロンゲームでの経験は、はるかに残念なものでした。例外なく、すべてのゲームは、インターネットで進行中のゲームへの接続、または同じIPv6専用LANセグメント内の他のコンピューターへのLANベースの接続のいずれかを有効にすることに失敗しました。これは多少意外であり、結果にはさらに検証が必要です。残念ながら、ゲームは動作に関する診断を提供しないため、何が起こっているのかを推測することは困難です。それらのネットワークコードがIPv6アドレス[RFC4038]を使用できない古いAPIを採用している可能性があります。 LANベースの接続を提供できないことはさらに驚くべきことです。これは、デバイスで利用可能であったはずのIPv4リンクローカル接続を使用できないことを意味するはずです（IPv4はブロックされませんでした。DHCPの回答が提供されなかっただけです） IPv4で）。
While none of the standalone games we tested in the summer of 2010 were IPv6-capable, the situation improved during the experiment. For instance, a popular online game, World of Warcraft, now has IPv6 support in its latest version and some of the older games that have been re-released as open source (e.g., Quake) have been patched IPv6- capable by the open source community.
2010年の夏にテストしたスタンドアロンゲームはいずれもIPv6対応ではありませんでしたが、実験中に状況は改善しました。たとえば、人気のオンラインゲームであるWorld of Warcraftの最新バージョンではIPv6がサポートされており、オープンソースとして再リリースされた古いゲーム（Quakeなど）には、オープンソースによってIPv6対応のパッチが適用されていますコミュニティ。
Most of the web-based music services appear to work fine, presumably because they employ TCP and HTTP as a transport. One notable exception is Spotify, which requires communication to specific IPv4 addresses. A proxy configuration similar to the one we used for Skype makes it possible to use Spotify as well.
Webベースの音楽サービスのほとんどは、TCPとHTTPをトランスポートとして使用しているためと思われます。注目すべき例外の1つはSpotifyで、特定のIPv4アドレスとの通信が必要です。 Skypeで使用したものと同様のプロキシ構成により、Spotifyも使用できるようになります。
There are also problems with different appliances such as webcams. Many of them do not support IPv6; hence, they will not work in an IPv6-only network. Also, not all firewalls support IPv6. Or even if they do, they may still experience issues with some aspects of IPv6 such as fragments.
Webカメラなどのさまざまなアプライアンスにも問題があります。それらの多くはIPv6をサポートしていません。したがって、IPv6のみのネットワークでは機能しません。また、すべてのファイアウォールがIPv6をサポートしているわけではありません。あるいは、たとえそうであっても、フラグメントなどのIPv6のいくつかの側面で問題が発生する可能性があります。
Some of these issues are easily solved when the appliance works as a server, such as what most webcams and our sensor gateway devices do. We placed the appliance in the IPv4 part of the network (in this case, in private address space), added its name to the local DNS, and simply allowed devices from the IPv6-only network reach it through NAT64.
これらの問題の一部は、アプライアンスがサーバーとして機能する場合に簡単に解決されます。たとえば、ほとんどのWebカメラやセンサーゲートウェイデバイスが行うことなどです。アプライアンスをネットワークのIPv4部分（この場合はプライベートアドレススペース）に配置し、その名前をローカルDNSに追加して、IPv6のみのネットワークから許可されたデバイスがNAT64経由でそれに到達することを許可しました。
One thing that becomes simplified in an IPv6-only network is source address selection [RFC3484]. As there is no IPv4 connectivity, the host only needs to consider its IPv6 source address. For global communications, there is typically just one possible source address.
IPv6のみのネットワークで簡素化される1つのことは、送信元アドレスの選択[RFC3484]です。 IPv4接続がないため、ホストはIPv6送信元アドレスのみを考慮する必要があります。グローバル通信の場合、通常、送信元アドレスは1つだけです。
Some networks that advertise IPv6 addresses in their DNS records in reality have some problems. For instance, a popular short URL forwarding service has advertised a deprecated IPv4-compatible IPv6 address [RFC4291] in its AAAA record, making it impossible for this site to be reached unless either IPv4 or NAT64 translation to an IPv4 destination is used.
実際にDNSレコードでIPv6アドレスをアドバタイズする一部のネットワークには、いくつかの問題があります。たとえば、人気のある短いURL転送サービスは、非推奨のIPv4互換IPv6アドレス[RFC4291]をAAAAレコードでアドバタイズしているため、IPv4宛先へのIPv4またはNAT64変換が使用されない限り、このサイトに到達できません。
After correcting some initial bugs and stability issues, the NAT64 operation itself has been relatively problem-free. There have been no unexplained DNS problems or lost sessions. With the exception of the specific applications mentioned above and IPv4 literals, the user experience has been in line with using IPv4 Internet through a NAT44 device. These failures with the specific applications are clearly very different from the IPv4 experience, however.
いくつかの初期のバグと安定性の問題を修正した後、NAT64操作自体は比較的問題がありませんでした。原因不明のDNS問題やセッションの損失はありませんでした。上記の特定のアプリケーションとIPv4リテラルを除いて、ユーザーエクスペリエンスは、NAT44デバイスを介したIPv4インターネットの使用と一致しています。ただし、特定のアプリケーションでのこれらの障害は、IPv4のエクスペリエンスとは明らかに大きく異なります。
The rest of this section discusses our measurements on specific issues. These tests and measurements were performed during the year 2011 and present a snapshot of the situation on that time. More up-to-date measurement information can be found from various online tools such as [HE-IPv6].
このセクションの残りの部分では、特定の問題に関する測定について説明します。これらのテストと測定は2011年中に行われ、その時の状況のスナップショットを示しています。 [HE-IPv6]などのさまざまなオンラインツールから、より最新の測定情報を見つけることができます。
While browsing in general works, IPv4 literals embedded in the HTML code may break some parts of the web pages when using IPv6-only access. This happens because the DNS64 cannot synthesize AAAA records for the literals since the addresses are not queried from the DNS. Luckily, the IPv4 literals seem to be fairly rarely encountered, at least so that they would be noticed, with regular web surfing. The authors have run into this issue only few times during the entire experiment. Only two of those cases had a practical impact (in YouTube, some of the third-party applications for downloading content did not work and one hotel's web page had a literal link to its reservation system).
ブラウジングは一般的に機能しますが、IPv6のみのアクセスを使用すると、HTMLコードに埋め込まれたIPv4リテラルがWebページの一部を壊す可能性があります。これは、アドレスがDNSから照会されないため、DNS64がリテラルのAAAAレコードを合成できないために発生します。幸いなことに、IPv4リテラルは、少なくとも定期的にWebサーフィンを行っていると気づかれるように、ほとんど見かけないようです。著者は、実験全体を通してこの問題に数回遭遇しました。それらのケースのうち2つだけが実際的な影響を及ぼしました（YouTubeでは、コンテンツをダウンロードするためのサードパーティアプリケーションの一部が機能せず、1つのホテルのWebページに予約システムへの文字通りのリンクがありました）。
We have attempted to measure the likelihood of running into an IPv4 literal in the web. To do this, we took the top 1,000 and 10,000 web sites from the Alexa popular web site list. With 1,000 top sites, 0.2% needed an IPv4 literal to render all components in their top page (e.g., images, videos, JavaScript, and Cascading Style Sheet (CSS) files). With 10,000 top sites, this number increases to 2%.
WebでIPv4リテラルに遭遇する可能性を測定しようとしました。これを行うために、Alexaの人気のあるWebサイトリストから上位1,000および10,000のWebサイトを採用しました。 1,000のトップサイトでは、0.2％がトップページのすべてのコンポーネント（画像、ビデオ、JavaScript、Cascading Style Sheet（CSS）ファイルなど）をレンダリングするためにIPv4リテラルを必要としていました。トップサイトが10,000あるため、この数は2％に増加します。
However, it is not clear what conclusions can be made about this. It is often the case that there are unresolvable or inaccessible components on a web page anyway for various reasons, and to understand the true impact we would have to know how "important" a given page component was. Also, we did not measure the number of links with IPv4 literals on these pages, nor did we attempt to search the site in any thorough manner for these literals.
ただし、これについてどのような結論を下すことができるかは明らかではありません。さまざまな理由でWebページに解決できない、またはアクセスできないコンポーネントがあり、実際の影響を理解するには、特定のページコンポーネントの「重要性」を知る必要があることがよくあります。また、これらのページでIPv4リテラルとのリンクの数を測定したり、これらのリテラルを徹底的に検索したりしていませんでした。
As noted, personal anecdotal evidence says that IPv4 literals are not a big problem. But clearly, cleaning the most important parts of the web from IPv4 literals would be useful. With tools such as the popular web site list, some user pressure, and co-operation from the content providers the most urgent part of the problem could hopefully be solved as a one-time effort. While IPv4 literals still exist in the web, using a suitable HTTP proxy (e.g., [ADD-LITERALS]) can help to cope with them.
前述のように、個人の事例証拠によると、IPv4リテラルは大きな問題ではありません。しかし明らかに、IPv4リテラルからWebの最も重要な部分を削除することは有用です。人気のあるWebサイトのリスト、ユーザーからのプレッシャー、コンテンツプロバイダーからの協力などのツールを使用することで、問題の最も緊急な部分を1回限りの努力で解決できると期待しています。 IPv4リテラルは引き続きWebに存在しますが、適切なHTTPプロキシ（[ADD-LITERALS]など）を使用すると、それらに対処するのに役立ちます。
We also compared how well the web works behind a NAT64 compared to IPv4-only and native IPv6 access. For this purpose, we used wget to go through the same top web site lists as described in Section 6.1, again downloading everything needed to render their front page. The tests were repeated and average failure rate was calculated over all of the runs. Separate tests were conducted with an IPv4-only network, an IPv6-only network, and an IPv6-only network with NAT64.
また、IPv4のみのアクセスとネイティブIPv6アクセスと比較して、NAT64の背後でWebがどのように機能するかを比較しました。この目的のために、セクション6.1で説明したのと同じトップWebサイトリストをwgetを使用して、フロントページのレンダリングに必要なすべてを再度ダウンロードしました。テストを繰り返し、すべての実行にわたって平均故障率を計算しました。 IPv4のみのネットワーク、IPv6のみのネットワーク、およびNAT64を使用したIPv6のみのネットワークで個別のテストが行われました。
When accessed with the IPv4-only network, our tests show that 1.9% of the sites experienced some sort of error or failure. The failure could be that the whole site was not accessible, or just that a single image (e.g., an advertisement banner) was not loaded properly. It should also be noted that access through wget is somewhat different from a regular browser: some web sites refuse to serve content to wget, browsers typically have DNS heuristics to fill in "www." in front of a domain name where needed, and so on. In addition to missing advertisement banners, temporary routing glitches and other mistakes, these differences also help to explain the reason for the high baseline error rate in this test. It should also be noted that variations in wget configuration options produced highly different results, but we believe that the options we settled on bear closest resemblance to real-world browsing.
IPv4のみのネットワークでアクセスしたときのテストでは、1.9％のサイトでなんらかのエラーまたは障害が発生したことが示されています。失敗の原因としては、サイト全体にアクセスできなかったか、1つの画像（広告バナーなど）が正しく読み込まれなかったことが考えられます。また、wgetを介したアクセスは通常のブラウザーとは多少異なることに注意してください。一部のWebサイトはwgetへのコンテンツの提供を拒否し、ブラウザーは通常「www」を入力するDNSヒューリスティックを備えています。必要に応じて、ドメイン名の前など。広告バナーの欠落、一時的なルーティングの不具合、およびその他のミスに加えて、これらの違いは、このテストでベースラインエラー率が高くなる理由を説明するのにも役立ちます。また、wget構成オプションのバリエーションによって結果が大きく異なることにも注意してください。ただし、私たちが解決したオプションは、実際のブラウジングに最も類似していると考えています。
When we tried to access the same sites with native IPv6 (without NAT64), 96% of the sites failed to load correctly. This was as expected, given that most of the Internet content is not available on IPv6. The few exceptions included, for instance, sites managed by Google.
ネイティブIPv6（NAT64なし）で同じサイトにアクセスしようとすると、サイトの96％が正しく読み込まれませんでした。ほとんどのインターネットコンテンツがIPv6で利用できないことを考えると、これは予想どおりでした。いくつかの例外には、たとえば、Googleが管理するサイトが含まれます。
When the sites were accessed from the IPv6-only network via a NAT64 device, the failure rate increased to 2.1%. Most of these failures appear to be due to IPv4 address literals, and the increased failure rate matches that of IPv4 literal occurrence in the same set of top web sites. With the top 10,000 sites, the failure rate with NAT64 increases similarly to our test on IPv4 address literals.
NAT64デバイスを介してIPv6のみのネットワークからサイトにアクセスすると、失敗率は2.1％に増加しました。これらの失敗のほとんどはIPv4アドレスリテラルが原因であると思われ、増加した失敗率は、同じトップWebサイトのセットで発生したIPv4リテラルの発生率と一致します。トップ10,000サイトでは、NAT64での失敗率は、IPv4アドレスリテラルでのテストと同様に増加します。
One important set of measurements remains for future work. It would be useful to understand the effect of DNS64 and NAT64 on response time and end-to-end communication delays. Some users have anecdotal reports of slow web browsing response times, but we have been unable to determine if this was due to the IPv6-only network mechanisms or for some other reason. Measurements on pure DNS response times and packet round-trip delays does not show a significant difference from a NAT44 environment. It would be particularly interesting to measure delays in the context of dual-stack versus NAT64-based IPv6-only networking. When using dual-stack, broken IPv6 connectivity can be repaired by falling back to IPv4 use. With NAT64, this is not always possible as discussed in Section 3.2.
重要な一連の測定値は、今後の作業のために残っています。応答時間とエンドツーエンドの通信遅延に対するDNS64とNAT64の影響を理解することは役に立ちます。一部のユーザーは遅いWebブラウジングの応答時間の事例報告を持っていますが、これがIPv6のみのネットワークメカニズムによるものか、その他の理由によるものかを判断できませんでした。純粋なDNS応答時間とパケット往復遅延の測定では、NAT44環境との大きな違いは示されていません。デュアルスタックとNAT64ベースのIPv6のみのネットワーキングのコンテキストで遅延を測定することは特に興味深いでしょう。デュアルスタックを使用する場合、IPv4の使用にフォールバックすることにより、壊れたIPv6接続を修復できます。 NAT64では、セクション3.2で説明されているように、これが常に可能であるとは限りません。
Also, more programs, especially VoIP and Peer-to-Peer (P2P) applications should be tested with NAT64. In addition, tunneling and mobility protocols should be tested and especially Virtual Private Network (VPN) protocols and applications would deserve more thorough investigation.
また、より多くのプログラム、特にVoIPおよびピアツーピア（P2P）アプリケーションは、NAT64でテストする必要があります。さらに、トンネリングプロトコルとモビリティプロトコルをテストする必要があります。特に、仮想プライベートネットワーク（VPN）プロトコルとアプリケーションは、より綿密な調査に値します。
The main conclusion is that it is possible to employ IPv6-only networking. For large classes of applications, there are no downsides or the downsides are negligible. We have been unable to spot any practical difference in the web browsing experience, for instance. Additionally, IPv6 usage -- be it in dual-stack or IPv6- only form -- comes with inherent advantages, such as enabling direct end-to-end connectivity. In our case, we employed this by enabling direct connectivity to devices in a home network from anywhere in the (IPv6) Internet. There are, however, a number of issues as well, such as lack of IPv6 support in some applications or bugs in untested parts of the code.
主な結論は、IPv6のみのネットワークを採用することが可能であるということです。大きなクラスのアプリケーションの場合、マイナス面はないか、マイナス面は無視できます。たとえば、Webブラウジングエクスペリエンスの実用的な違いを見つけることはできませんでした。さらに、IPv6の使用法（デュアルスタックまたはIPv6のみの形式のどちらでも）には、直接的なエンドツーエンドの接続を可能にするなど、固有の利点があります。私たちのケースでは、これを採用して（IPv6）インターネットのどこからでもホームネットワーク内のデバイスに直接接続できるようにしました。ただし、一部のアプリケーションでのIPv6サポートの欠如やコードのテストされていない部分のバグなど、多くの問題もあります。
Our experience with IPv6-only networking confirms that dual stack should still be our recommended model for general purpose networking at this point in time. However, IPv6-only networking can be employed by early adopters or highly controlled networks. One example of such a controlled network is a mobile network with operator-driven selection of handsets. For instance, on some handsets that we tested, we were unable to see any functional difference between IPv4 and IPv6.
IPv6のみのネットワーキングに関する経験から、現時点では、デュアルスタックが汎用ネットワーキングの推奨モデルであることが確認されています。ただし、IPv6のみのネットワーキングは、アーリーアダプターまたは高度に制御されたネットワークで使用できます。このような制御されたネットワークの1つの例は、オペレーター主導のハンドセットを選択できるモバイルネットワークです。たとえば、テストした一部の携帯電話では、IPv4とIPv6の機能的な違いを確認できませんでした。
Our recommendations apply at the present time. With effort and time, deployment barriers can be removed and IPv6-only networking becomes applicable in all networking situations.
現時点では推奨事項が適用されます。労力と時間をかけることで、導入の障壁を取り除くことができ、IPv6のみのネットワーキングがすべてのネットワーキング状況に適用可能になります。
Some of the improvements are already in process in the form of new products and additional IPv6 support. For instance, we expect that the handset market will have a much higher number of IPv6-capable devices in the near future. However, some of the changes do not come without the community spending additional effort. We have identified a number of actions that should be taken to improve the state of IPv6-only networking. These include the following: DNS Discovery
改善の一部は、新製品と追加のIPv6サポートの形ですでに進行中です。たとえば、携帯電話市場では近い将来、IPv6対応デバイスの数が大幅に増えると予想しています。ただし、変更の一部は、コミュニティが追加の努力を費やさなければ実現しません。 IPv6のみのネットワークの状態を改善するために実行する必要があるいくつかのアクションを特定しました。これには次のものが含まれます。DNS検出
The state of DNS discovery continues to be one of the main barriers for easy adoption of IPv6-only networking. Since DNS discovery is not a problem in dual-stack networking, there has been too little effort in testing and deploying the necessary components. For instance, it would be useful if RA-based DNS discovery came as a standard feature and not as an option in Linux distributions. Our hope is that recent standardization of the RA-based DNS discovery at the IETF will help this happen. Other operating systems face similar issues. The authors believe that at this time, prudent operational practices call for maximizing the number of offered automatic configuration mechanisms on the network side. It might be useful for an IETF document to provide guidance on operating DNS in IPv6-only networks.
DNS検出の状態は、IPv6のみのネットワーキングを容易に採用するための主要な障壁の1つであり続けています。デュアルスタックネットワーキングではDNSの検出は問題ではないため、必要なコンポーネントのテストと展開にはほとんど労力がかかりませんでした。たとえば、RAベースのDNS検出が標準機能として提供され、Linuxディストリビューションのオプションとして提供されない場合に役立ちます。私たちの希望は、IETFでのRAベースのDNS検出の最近の標準化がこれを実現するのに役立つことです。他のオペレーティングシステムでも同様の問題が発生します。著者は、現時点では、慎重な運用慣行により、ネットワーク側で提供される自動構成メカニズムの数を最大化する必要があると考えています。 IETF文書がIPv6のみのネットワークでDNSを操作するためのガイダンスを提供することは有用かもしれません。
Network Managers
ネットワークマネージャー
Other key software components are the various network management and attachment tools in operating systems. These tools generally have the required functionality, but do not always appear to have been tested very extensively on IPv6, or let alone IPv6-only networks. Further work is required here.
他の主要なソフトウェアコンポーネントは、オペレーティングシステムのさまざまなネットワーク管理および接続ツールです。これらのツールは通常、必要な機能を備えていますが、IPv6で非常に広範囲にテストされているとは限りません。IPv6のみのネットワークはもちろんです。ここでさらに作業が必要です。
Firewalls
ファイアウォール
More work is needed to ensure that IPv6 is supported in equal manner in various firewall products.
さまざまなファイアウォール製品でIPv6が同等にサポートされるようにするには、さらに作業が必要です。
Application Support
アプリケーションのサポート
By far, the most important action, at least for our group of users, would be to bring some key applications (e.g., instant messaging and VoIP applications and games) to a state where they can be easily run on IPv6-only networks and behind a NAT64. To facilitate this, application programmers should use IP-version-agnostic APIs so that applications automatically use IPv4 or IPv6 depending on what is available. In some cases, it may also be necessary to add support for new types of ALGs.
これまでのところ、少なくともユーザーグループにとって最も重要なアクションは、いくつかの主要なアプリケーション（たとえば、インスタントメッセージングやVoIPアプリケーションやゲーム）を、IPv6のみのネットワークで背後で簡単に実行できる状態にすることです。 NAT64。これを容易にするために、アプリケーションプログラマはIPバージョンに依存しないAPIを使用して、アプリケーションが利用可能なものに応じてIPv4またはIPv6を自動的に使用するようにする必要があります。場合によっては、新しいタイプのALGのサポートを追加する必要もあります。
IPv4 Literals
IPv4リテラル
The web should be cleaned of IPv4 literals. Also, IPv4 literals should be avoided in application protocol signaling messages.
ウェブからIPv4リテラルを削除する必要があります。また、IPv4リテラルは、アプリケーションプロトコルシグナリングメッセージでは使用しないでください。
Measurements and Analysis
測定と分析
It is also important to continue with testing, measurement, and analysis of which Internet technologies work in IPv6-only networks, to what extent, at what speed, and where the remaining problems are.
また、IPv6のみのネットワークでどのインターネット技術がどの程度、どの程度の速度で、残りの問題がどこにあるかをテスト、測定、および分析することも重要です。
Guidelines
ガイドライン
It is also useful to provide guidance for network administrators and users on how to turn on IPv6-only networking.
IPv6のみのネットワークを有効にする方法について、ネットワーク管理者とユーザーにガイダンスを提供することも役立ちます。
As can be seen from the above list, there are only minor things that can be done through standardization. Most of the effort is practical and centers around improving various implementations.
上記のリストからわかるように、標準化によって実行できることはごくわずかです。取り組みのほとんどは実用的であり、さまざまな実装の改善に集中しています。
By itself, the use of IPv6 instead of IPv4 does not make a big security difference. The main security requirement is that, naturally, network security devices need to be able to deal with IPv6 in these networks. This is already required in all dual-stack networks. As noted, it is important, e.g., to ensure firewall capabilities. Security considerations for NAT64 and DNS64 are discussed in [RFC6146] and [RFC6147].
IPv4の代わりにIPv6を使用しても、セキュリティに大きな違いはありません。主なセキュリティ要件は、当然ながら、ネットワークセキュリティデバイスがこれらのネットワークでIPv6を処理できる必要があることです。これは、すべてのデュアルスタックネットワークですでに必要です。前述のように、ファイアウォール機能を確保することなどが重要です。 NAT64およびDNS64のセキュリティに関する考慮事項は、[RFC6146]および[RFC6147]で説明されています。
In our experience, many of the critical security functions in a network end up being on the dual-stack part of the network anyway. For instance, our mail servers obviously still have to be able to communicate with both the IPv4 and IPv6 Internet, and as a result, they and the associated spam and filtering components are not in the IPv6-only part of the network.
私たちの経験では、いずれにしても、ネットワークの重要なセキュリティ機能の多くは、ネットワークのデュアルスタック部分に存在します。たとえば、メールサーバーは明らかにIPv4とIPv6の両方のインターネットと通信できる必要があるため、それらのサーバーと関連するスパムおよびフィルタリングコンポーネントは、ネットワークのIPv6のみの部分にはありません。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、1999年8月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] Droms、R。、「IPv6用のステートレス動的ホスト構成プロトコル（DHCP）サービス」、RFC 3736、2004年4月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストおよびルーターの基本的な移行メカニズム」、RFC 4213、2005年10月。
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.
[RFC6106] Jeong、J.、Park、S.、Beloeil、L。、およびS. Madanapalli、「DNS構成のIPv6ルーターアドバタイズメントオプション」、RFC 6106、2010年11月。
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[RFC4038] Shin、M-K。、Hong、Y-G。、Hagino、J.、Savola、P。、およびE. Castro、「IPv6移行のアプリケーションアスペクト」、RFC 4038、2005年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
[RFC4966] Aoun、C。およびE. Davies、「ネットワークアドレストランスレータ-プロトコルトランスレータ（NAT-PT）を歴史的なステータスに移行する理由」、RFC 4966、2007年7月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M。、およびX. Li、「IPv4 / IPv6トランスレータのIPv6アドレッシング」、RFC 6052、2010年10月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「Framework for IPv4 / IPv6 Translation」、RFC 6144、2011年4月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「IP / ICMP変換アルゴリズム」、RFC 6145、2011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、2011年4月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P.、I。van Beijnum、「DNS64：DNS Extensions for Network Address Translation to IPv4 Servers to IPv4 Servers」、RFC 6147、2011年4月。
[RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation", RFC 6384, October 2011.
[RFC6384] van Beijnum、I。、「IPv6-to-IPv4変換用のFTPアプリケーション層ゲートウェイ（ALG）」、RFC 6384、2011年10月。
[ADD-LITERALS] Wing, D., "Coping with IP Address Literals in HTTP URIs with IPv6/IPv4 Translators", Work in Progress, March 2010.
[ADD-LITERALS] Wing、D。、「IPv6 / IPv4トランスレーターを使用したHTTP URIでのIPアドレスリテラルの処理」、進行中の作業、2010年3月。
[HE-IPv6] Hurricane Electric, "Global IPv6 Deployment Progress Report", February 2012, <http://bgp.he.net/ipv6-progress-report.cgi>.
[HE-IPv6] Hurricane Electric、「Global IPv6 Deployment Progress Report」、2012年2月、<http://bgp.he.net/ipv6-progress-report.cgi>。
The authors would like to thank the many people who have engaged in discussions around this topic, and particularly the people who were involved in building some of the new tools used in our network, our users who were interested in going where only few had dared to venture before, or people who helped us in this effort. In particular, we would like to thank Martti Kuparinen, Tero Kauppinen, Heikki Mahkonen, Jan Melen, Fredrik Garneij, Christian Gotare, Teemu Rinta-Aho, Petri Jokela, Mikko Sarela, Olli Arkko, Lasse Arkko, and Cameron Byrne. Also, Marcelo Braun, Iljitsch van Beijnum, Miika Komu, and Jouni Korhonen have provided useful discussion and comments on the document.
著者は、このトピックに関する議論に携わってきた多くの人々、特に私たちのネットワークで使用されている新しいツールのいくつかの構築に携わった人々、ほんのわずかしか挑戦しなかったところに行きたいと思っているユーザーに感謝したいと思います。以前に冒険したり、この取り組みで私たちを助けてくれた人々。特に、Martti Kuparinen、Tero Kauppinen、Heikki Mahkonen、Jan Melen、Fredrik Garneij、Christian Gotare、Teemu Rinta-Aho、Petri Jokela、Mikko Sarela、Olli Arkko、Lasse Arkko、Cameron Byrneに感謝します。また、Marcelo Braun、Iljitsch van Beijnum、Miika Komu、Jouni Korhonenは、ドキュメントに関する有益なディスカッションとコメントを提供しています。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson Jorvas 02420 Finland
Jari Arkko Ericsson Jorvas 02420フィンランド
EMail: jari.arkko@piuha.net
Ari Keranen Ericsson Jorvas 02420 Finland
あり けらねん えりｃっそん じょｒゔぁｓ ０２４２０ ふぃんぁんｄ
EMail: ari.keranen@ericsson.com