[要約] RFC 6036は、IPv6展開のための新興サービスプロバイダのシナリオに関するものであり、IPv6の展開に関する具体的なガイドラインを提供することを目的としています。
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 6036 Univ. of Auckland
Category: Informational S. Jiang
ISSN: 2070-1721 Huawei Technologies Co., Ltd
October 2010
Emerging Service Provider Scenarios for IPv6 Deployment
IPv6の展開のための新しいサービスプロバイダーシナリオ
Abstract
概要
This document describes practices and plans that are emerging among Internet Service Providers for the deployment of IPv6 services. They are based on practical experience so far, as well as current plans and requirements, reported in a survey of a number of ISPs carried out in early 2010. This document identifies a number of technology gaps, but it does not make recommendations.
このドキュメントでは、IPv6サービスの展開のためにインターネットサービスプロバイダーの間で出現しているプラクティスと計画について説明します。これらは、2010年初頭に行われた多くのISPの調査で報告されている現在の計画と要件と同様に、これまでのところ実際の経験に基づいています。この文書は、多くのテクノロジーギャップを特定していますが、推奨は行われません。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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）の製品です。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/rfc6036.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6036で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Survey of ISP's Experience, Plans, and Requirements .............4
2.1. Methodology ................................................4
2.2. General Questions about IP Service .........................4
2.3. Requirements for IPv6 Service ..............................5
2.4. Status and Plans for IPv6 Service ..........................5
2.5. IPv6 Technologies ..........................................5
2.6. Effect of Size .............................................6
3. Lessons from Experience and Planning ............................7
4. Gap Analysis ....................................................8
4.1. Product Issues .............................................8
4.2. Protocol Issues ............................................9
4.3. Documentation and General Issues ..........................10
5. Security Considerations ........................................11
6. Acknowledgements ...............................................11
7. Informative References .........................................12
Appendix A. Summary of Replies ....................................14
Appendix B. Questionnaire .........................................19
As is well known, the approaching exhaustion of IPv4 address space will bring about a situation in which Internet Service Providers (ISPs) are faced with a choice between one or more of three major alternatives:
よく知られているように、IPv4アドレススペースの近づいている疲労は、インターネットサービスプロバイダー（ISP）が3つの主要な選択肢の1つ以上の選択に直面する状況をもたらします。
1. Squeeze the use of IPv4 addresses even harder than today, using smaller and smaller address blocks per enterprise customer, and possibly trading address blocks with other ISPs.
1. Enterpriseの顧客ごとに小さくて小さいアドレスブロックを使用して、IPv4アドレスの使用を今日よりもさらに困難にし、おそらく他のISPとのアドレスブロックを取引します。
2. Install multiple layers of Network Address Translation (NAT) [CGN] or share IPv4 addresses by other methods such as address-plus-port mapping [APLUSP], [PRANGE].
2. ネットワークアドレス変換（NAT）[CGN]の複数のレイヤーをインストールするか、アドレスプラスポートマッピング[Aplusp]、[Prange]などの他の方法でIPv4アドレスを共有します。
3. Deploy IPv6 and operate IPv4-IPv6 coexistence and interworking mechanisms.
3. IPv6を展開し、IPv4-IPV6共存とインターワーキングメカニズムを操作します。
This document focuses on alternative (3), while recognizing that many ISPs may be obliged by circumstances to prolong the life of IPv4 by using (1) or (2) while preparing for (3).
このドキュメントは、代替（3）に焦点を当てていますが、（3）の準備中に（1）または（2）を使用してIPv4の寿命を延長する状況によって多くのISPが義務付けられている可能性があることを認識しています。
This document describes IPv6 deployment scenarios already adopted or currently planned by a set of ISPs who responded to a technical questionnaire. Thus, it is a factual record of the responses from those ISPs. It makes no recommendations; the best choice of scenarios will depend on the circumstances of individual ISPs.
このドキュメントでは、技術的なアンケートに回答したISPのセットによって既に採用または現在計画されているIPv6展開シナリオについて説明しています。したがって、それはそれらのISPからの応答の事実上の記録です。推奨はありません。シナリオの最良の選択は、個々のISPの状況に依存します。
We consider various aspects of IPv6 deployment: addressing, routing, DNS, management, and IPv4-IPv6 coexistence and interworking. We do not consider application services in detail, but we do cover general aspects.
IPv6の展開のさまざまな側面を検討します：アドレス指定、ルーティング、DNS、管理、およびIPv4-IPV6共存とインターワーキング。アプリケーションサービスを詳細には検討していませんが、一般的な側面をカバーしています。
The reader is assumed to be familiar with IPv6. The IETF's view of core IPv6 requirements is to be found in [RFC4294] (currently being updated as [NODEREQ]). However, this does not give a complete view of mechanisms an ISP may need to deploy, since it considers the requirements for an individual node, not for a network or service infrastructure as a whole.
読者はIPv6に精通していると想定されています。コアIPv6要件に関するIETFのビューは、[RFC4294]（現在[Nodereq]として更新されている）にあります。ただし、これは、ネットワークまたはサービスインフラストラクチャ全体ではなく、個々のノードの要件を考慮するため、ISPが展開する必要がある可能性のあるメカニズムの完全なビューを提供するものではありません。
[RFC4029] discusses scenarios for introducing IPv6 into ISP networks, as the problem was viewed some years ago. Its end goal is simply a dual-stack ISP backbone. Today's view is that this is insufficient, as it does not allow for interworking between IPv6-only and legacy (IPv4-only) hosts. Indeed, the end goal today might be an IPv6-only ISP backbone, with some form of legacy IPv4 support.
[RFC4029]は、数年前に問題が見られたため、IPv6をISPネットワークに導入するためのシナリオについて説明します。その最終目標は、単にデュアルスタックISPバックボーンです。今日の見解では、IPv6のみとレガシー（IPv4のみ）のホストとの相互作用が許可されていないため、これは不十分であるということです。実際、今日の最終目標は、Legacy IPv4サポートの何らかの形で、IPv6のみのISPバックボーンである可能性があります。
[RFC4779] discusses deployment in broadband access networks such as Cable Television (CATV), Asymmetric Digital Subscriber Line (ADSL), and wireless. [RFC5181], [RFC5121], and [RFC5692] deal specifically with IEEE 802.16 access networks. MPLS-based ISPs may use the IPv6 Provider Edge Router (6PE) [RFC4798] mechanism.
[RFC4779]は、ケーブルテレビ（CATV）、非対称デジタル加入者ライン（ADSL）、ワイヤレスなどのブロードバンドアクセスネットワークの展開について説明します。[RFC5181]、[RFC5121]、および[RFC5692]は、特にIEEE 802.16アクセスネットワークを扱います。MPLSベースのISPは、IPv6プロバイダーエッジルーター（6PE）[RFC4798]メカニズムを使用する場合があります。
[RFC4942] covers IPv6 security issues, especially those that are specific to transition and IPv4-IPv6 coexistence scenarios. [RFC4864] discusses "Local Network Protection", i.e., how the internal structure of an IPv6 site network can be protected. This affects how well an ISP's customers are protected after they deploy IPv6.
[RFC4942]は、IPv6のセキュリティの問題、特に遷移およびIPv4-IPV6共存シナリオに固有の問題をカバーしています。[RFC4864]は、「ローカルネットワーク保護」、つまりIPv6サイトネットワークの内部構造を保護する方法について説明します。これは、ISPの顧客がIPv6を展開した後にどれだけうまく保護されているかに影響します。
Although the basic IPv6 standards have long been stable, it should be noted that considerable work continues in the IETF, particularly to resolve the issue of highly scalable multihoming support for IPv6 sites, and to resolve the problem of IP layer interworking between IPv6-only and IPv4-only hosts. IPv6/IPv4 interworking at the application layers is handled within the original dual-stack model of IPv6 deployment: either one end of an application session will have dual-stack connectivity, or a dual-stack intermediary such as an HTTP proxy or SMTP server will interface to both IPv4-only and IPv6-only hosts or applications.
基本的なIPv6標準は長い間安定していますが、特にIPv6サイトの高度にスケーラブルなマルチホームサポートの問題を解決し、IPv6のみとIPv6のみと間のIPレイヤーインターワーキングの問題を解決するために、IETFでかなりの作業が継続していることに注意する必要があります。IPv4のみのホスト。アプリケーションレイヤーでのIPv6/IPv4インターワーキングは、IPv6展開の元のデュアルスタックモデル内で処理されます。アプリケーションセッションのいずれかの端にはデュアルスタック接続、またはHTTPプロキシまたはSMTPサーバーなどのデュアルスタック仲介IPv4のみおよびIPv6のみのホストまたはアプリケーションの両方へのインターフェース。
[RFC5211] describes an independent view of a possible sequence of events for IPv6 adoption in the Internet as a whole, with direct implications for ISPs. Its main point, perhaps, is that by the year 2012, it will be appropriate to regard IPv4 networks as the legacy solution.
[RFC5211]は、ISPに直接影響を与えるインターネット全体でのIPv6採用のためのイベントの可能性のあるシーケンスの独立した見解を説明しています。その主なポイントは、おそらく、2012年までにIPv4ネットワークをレガシーソリューションと見なすことが適切であることです。
To obtain a view of the IPv6 experience, plans, and requirements of ISPs, a questionnaire was issued by the authors in December 2009 and announced widely to the operational community. We promised to keep the replies strictly confidential and to publish only combined results, without identifying information about individual ISPs in any published results. The raw technical questions are shown in Appendix B, and a detailed summary of the replies is in Appendix A. Note that although the questionnaire was widely announced, those who chose to reply were self-selected and we can make no claim of statistical significance or freedom from bias in the results. In particular, we assume that ISPs with a pre-existing interest in IPv6 are more likely to have replied than others. The results should therefore be interpreted with some care.
ISPのIPv6の経験、計画、および要件の見解を取得するために、2009年12月に著者によってアンケートが発行され、運用コミュニティに広く発表されました。公開された結果で個々のISPに関する情報を特定することなく、応答を厳密に機密保持し、結果のみを統合した結果のみを公開することを約束しました。生の技術的な質問は付録Bに示されており、返信の詳細な概要は付録Aにあります。アンケートは広く発表されているが、返信を選択した人は自己選択であり、統計的有意性を主張することはできないか、または結果のバイアスからの自由。特に、IPv6に既存の関心を持つISPは、他のIPV6よりも応答した可能性が高いと想定しています。したがって、結果はある程度注意して解釈する必要があります。
Thirty-one ISPs replied before the cutoff date for this analysis. 65% of responses were from European ISPs but large operators in North America and Asian/Pacific regions are included. Commercial ISPs operating nationally predominate, with a vast range of size (from 30 customers up to 40 million). Note that some providers chose not to answer about the exact number of customers. Nevertheless, it can be stated that 6 providers each had millions of customers, the next 10 each had more than 10,000 customers, and the remaining 15 each had fewer than 10,000 customers.
この分析のカットオフ日前に31人のISPが返信しました。回答の65％はヨーロッパISPからのものでしたが、北米およびアジア/太平洋地域の大規模なオペレーターが含まれています。全国的に運営されている商業ISPは、膨大な規模の範囲（30人の顧客から4,000万人まで）を備えています。一部のプロバイダーは、顧客の正確な数について回答しないことを選択したことに注意してください。それにもかかわらず、6人のプロバイダーにそれぞれ数百万人の顧客がおり、次の10人にはそれぞれ10,000人以上の顧客がおり、残りの15人は10,000人未満の顧客を抱えていたと述べることができます。
80% of the respondents offer both transit and origin-only service; 29% offer IP multicast service; 80% have multihomed customers.
回答者の80％は、輸送と原産地のみのサービスの両方を提供しています。29％がIPマルチキャストサービスを提供しています。80％にはマルチホームの顧客がいます。
A very wide variety of access technologies is used: xDSL, Data Over Cable Service Interface Specification (DOCSIS), leased line (X.25, Time Division Multiplexer / Plesiochronous Digital Hierarchy (TDM/ PDH), Synchronous Digital Hierarchy (SDH)), ATM, frame relay, dialup, microwave, Fiber To The Premises (FTTP), CDMA, Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Worldwide Interoperability for Microwave Access (WiMAX), Broadband Wireless Access (BWA), WiFi, Ethernet (100M-10G), Ethernet/SDH, MetroEthernet/MPLS. Most ISPs provide Customer Premises Equipment (CPE) to some or all of their customers, but these CPE are often unable to support IPv6.
非常に多種多様なアクセステクノロジーが使用されています：XDSL、ケーブルサービスインターフェイス仕様（DOCSIS）、リースライン（X.25、時分割マルチプレクサー /プレシオクロニスデジタル階層（TDM / PDH）、同期デジタル階層（SDH））、ATM、フレームリレー、ダイヤルアップ、電子レンジ、施設へのファイバー（FTTP）、CDMA、ユニバーサルモバイルテレコミュニケーションシステム（UMTS）、長期進化（LTE）、マイクロ波アクセスの世界的な相互運用性（WIMAX）、ブロードバンドワイヤレスアクセス（BWA）、WiFi、イーサネット（100m-10g）、イーサネット/SDH、メトロエセルネット/MPLS。ほとんどのISPは、顧客の一部またはすべての顧客に顧客施設機器（CPE）を提供していますが、これらのCPEはIPv6をサポートできないことがよくあります。
Estimates of when ISPs will run out of public IPv4 address space for internal use vary widely, between "now" and "never". Public IPv4 address space for customers is mainly expected to run out between 2010 and 2015, but four or five ISPs suggested it will never happen, or at least not in the foreseeable future. About 19% of ISPs offer RFC 1918 space to customers, and about 39% use such addresses internally.
ISPがパブリックIPv4アドレス空間が不足している場合の推定値は、「Now」と「Never」の間で大きく異なります。顧客向けのパブリックIPv4アドレススペースは、主に2010年から2015年の間に実行されると予想されていますが、4つまたは5つのISPは、それが決して起こらないこと、または少なくとも近い将来ではないことを示唆しています。ISPの約19％が顧客にRFC 1918スペースを提供し、約39％がそのような住所を内部で使用しています。
61% of ISPs report that some big customers are requesting IPv6. Predictions for when 10% of customers will require IPv6 range from 2010 to 2017, and for 50% from 2011 to 2020. These ISPs require IPv6 to be a standard service by 2010 to 2015; the most common target date is 2011.
ISPの61％は、一部の大手顧客がIPv6を要求していると報告しています。顧客の10％が2010年から2017年までIPv6の範囲を必要とする場合の予測は、2011年から2020年まで50％の場合は、これらのISPが2010年から2015年までにIPv6を標準サービスにする必要があります。最も一般的な目標日は2011年です。
42% of ISPs already offer IPv6 as a regular service, although, in general, it is used by fewer than 1% of customers. Another 48% of ISPs have IPv6 deployment in progress or planned. These all plan at least beta-test service in 2010. Planned dates for regular service are between 2010 and 2013 (except for one ISP who replied that it depends on the marketing department). When asked when IPv6 will reach 50% of total traffic, the most common answer is 2015.
ISPの42％はすでに通常のサービスとしてIPv6を提供していますが、一般に、顧客の1％未満で使用されています。ISPの別の48％がIPv6の展開が進行中または計画されています。これらはすべて、2010年に少なくともベータテストサービスを計画しています。通常のサービスの計画日は2010年から2013年の間です（マーケティング部門に依存していると答えたISPの1人を除く）。IPv6が総トラフィックの50％に達する時期を尋ねられたとき、最も一般的な答えは2015年です。
Turning to technology choices, the overwhelming choice of approach (94%) is a dual-stack routing backbone, and the reason given is simplicity and cost. 39% run, or plan to run, a 6to4 relay as well, and 16% run or plan a Teredo server. However, 77% of ISPs don't have or plan to have any devices dedicated to IPv6. A different 77% don't see IPv6 as an opportunity to restructure their network topology.
テクノロジーの選択に目を向けると、圧倒的なアプローチの選択（94％）はデュアルスタックルーティングバックボーンであり、与えられた理由はシンプルさとコストです。39％が実行、または実行する予定、6to4リレーも実行され、16％がTeredoサーバーを実行または計画します。ただし、ISPの77％がIPv6専用のデバイスを持っていないか、計画していません。別の77％は、IPv6をネットワークトポロジを再構築する機会と見なしていません。
When asked which types of equipment are unable to support IPv6, the most common answer was CPE (10 mentions). Also mentioned: handsets; Digital Subscriber Line Access Multiplexers (DSLAMs); routers (including several specific models); traffic management boxes; load balancers; VPN boxes; some SIP platforms; management interfaces & systems; firewalls; billing systems. When asked if such devices can be field-upgraded, the answers were gloomy: 5 yes, 4 partially, 10 no, and numerous "don't know" or "hopefully".
どのタイプの機器がIPv6をサポートできないかを尋ねられたとき、最も一般的な答えはCPEでした（10件の言及）。また、携帯電話。デジタルサブスクライバーラインアクセスマルチプレクサ（DSLAMS）;ルーター（いくつかの特定のモデルを含む）;トラフィック管理ボックス。ロードバランサー。VPNボックス;一部のSIPプラットフォーム。管理インターフェイスとシステム;ファイアウォール;請求システム。そのようなデバイスをフィールドアップグレードできるかどうかを尋ねられたとき、答えは悲観的でした。
84% support or plan DNS Authentication, Authorization, Accounting, and Auditing (AAAA) queries over IPv6, and all but one of these include reverse DNS lookup for IPv6.
84％のサポートまたは計画DNS認証、承認、会計、および監査（AAAA）がIPv6を介してクエリを照会し、これらの1つを除くすべてがIPv6の逆DNS検索を含んでいます。
The ISPs surveyed have prefixes ranging from /19 to /48, and have a variety of policies for customer prefixes. Fifteen ISPs offer more than one of /48, /52, /56, /60, or /64. Two offer /56 only, eight offer /48 only. Two wired operators offer /64 only. Mobile operators offer /64 in accordance with 3GPP, but at least one would like to be allowed to offer /128 or /126. Also, as many as 30% of the operators already have IPv6 customers preferring a PI (provider independent) prefix. The methods chosen for prefix delegation to CPEs are manual, DHCPv6[-PD], Stateless Address Autoconfiguration (SLAAC), RADIUS, and Point-to-Point Protocol over Ethernet (PPPoE). However, in fact, the latter two cannot assign a prefix on their own.
調査対象のISPには、 /19〜 /48の範囲の接頭辞があり、顧客のプレフィックスに関するさまざまなポリシーがあります。15のISPは、 /48、 /52、 /56、 /60、または /64のうち2つ以上を提供しています。2つのオファー /56のみ、8つのオファー /48のみ。2つの有線演算子は /64のみを提供します。モバイルオペレーターは3GPPに従って /64を提供しますが、少なくとも1つは /128または /126を提供することを許可したいと考えています。また、オペレーターの30％がすでにPI（プロバイダー独立）プレフィックスを好むIPv6の顧客を既に持っています。CPEへのプレフィックス代表団に選択された方法は、マニュアル、DHCPV6 [-PD]、Stateless Address Autoconfiguration（SLAAC）、RADIUS、およびPOINT-POINT Protocol（PPPOE）です。ただし、実際、後者の2つは自分でプレフィックスを割り当てることはできません。
About 50% of ISPs already operate or plan dual-stack SMTP, Post Office Protocol 3 (POP3), IMAP, and HTTP services. In terms of internal services, it seems that firewalls, intrusion detection, address management, monitoring, and network management tools are also around the 50% mark. However, accounting and billing software is only ready at 23% of ISPs.
ISPの約50％がすでに動作しているか、デュアルスタックSMTP、郵便局プロトコル3（POP3）、IMAP、およびHTTPサービスを計画しています。内部サービスに関しては、ファイアウォール、侵入検知、住所管理、監視、ネットワーク管理ツールも50％のマークであるようです。ただし、会計および請求ソフトウェアは、ISPの23％でのみ準備ができています。
Considering IPv4-IPv6 interworking, 58% of ISPs don't expect to have IPv6-only customers (but mobile operators are certain they will have millions). Five ISPs report customers who explicitly refused to consider IPv6. When asked how long customers will run IPv4-only applications, the most frequent answer is "more than ten years". Only three ISPs state that IPv6-IPv4 interworking at the IP layer is not needed. On the other hand, only three (a different three!) run or plan to run NAT-PT (Protocol Translation). At least 30% plan to run some kind of translator (presumably NAT64/DNS64), but only two felt that a multicast translator was essential. Among those who do not plan a translator, when asked how they plan to connect IPv6-only customers to IPv4-only services, seven rely on dual stack and four have no plan (one said, paraphrasing, "it's their problem").
IPv4-IPV6インターワーキングを考慮すると、ISPの58％はIPv6のみの顧客を抱えているとは予想していません（ただし、モバイルオペレーターは数百万人がいると確信しています）。5人のISPが、IPv6の検討を明示的に拒否した顧客を報告しています。顧客がどのくらいの期間IPv4のみのアプリケーションを実行するかを尋ねられたとき、最も頻繁な答えは「10年以上」です。IPレイヤーでIPv6-IPV4インターワーキングが必要ないと述べているのは3つのISPのみです。一方、NAT-PT（プロトコル翻訳）を実行する3つの（3つの異なる3つ！）のみが実行または計画しています。少なくとも30％が何らかの翻訳者（おそらくNAT64/DNS64）を実行する予定ですが、マルチキャスト翻訳者が不可欠であると感じたのは2人だけでした。翻訳者を計画していない人の中で、IPv6のみの顧客をIPv4のみのサービスに接続する方法を尋ねられたとき、7人はデュアルスタックに依存し、4人には計画がありません（1人は言い換えます、「それは彼らの問題です」）。
Asked about plans for Mobile IPv6 (or Nemo mobile networks), 19% said yes, and 71% said no, with the others uncertain. A detailed analysis shows that of the six ISPs who responded positively, three are large mobile operators (and a fourth mobile operator said no). The other three who responded positively were broadband ISPs ranging from small to very large.
モバイルIPv6（またはNEMOモバイルネットワーク）の計画について尋ねられ、19％がイエスと言っており、71％がNOと答え、他の人は不確実です。詳細な分析では、肯定的に応答した6人のISPのうち、3人が大規模なモバイルオペレーターであることが示されています（および4番目のモバイルオペレーターがNOが言った）。積極的に反応した他の3人は、小さいものから非常に大きなものまでのブロードバンドISPでした。
We examined the data to see whether any other differences would emerge between the very large (millions of customers), medium (at least 10,000), and small (fewer than 10,000) operators. However, the range of answers seems to be broadly similar in all cases. The major exception is that among the six very large operators, one plans to use 6PE and dual-stack lite (DS-lite), and another to use IPv6 on VPN to Provider Edge Router (6VPE), instead of a simple dual stack. The other large operators and all the medium and small operators prefer a simple dual stack.
データを調べて、非常に大きな（数百万人の顧客）、中程度（少なくとも10,000）、および小規模（10,000未満）のオペレーターの間で他の違いが生じるかどうかを確認しました。ただし、回答の範囲は、すべての場合において非常に類似しているようです。主要な例外は、6つの非常に大規模な演算子のうち、1つは6PEおよびデュアルスタックライト（DS-Lite）を使用し、別の非常にデュアルスタックライト（VPNでIPv6を使用して、単純なデュアルスタックの代わりにプロバイダーEdgeルーター（6VPE））を使用することです。他の大規模なオペレーターとすべての中小演算子は、単純なデュアルスタックを好みます。
This section is assembled and paraphrased from general comments made in the various questionnaire responses. Any inconsistencies or contradictions are present in the original data. Comments related to missing features and products have been included in Section 4.
このセクションは、さまざまなアンケートの回答で行われた一般的なコメントから組み立てられ、言い換えられます。矛盾または矛盾はすべて、元のデータに存在します。欠落している機能と製品に関連するコメントは、セクション4に含まれています。
As noted in the summary above, the ISPs that responded overwhelmingly prefer a native dual-stack deployment. Numerous comments mentioned the simplicity of this model and the complexity and sub-optimal routing of tunnel-based solutions. Topology redesign is not generally considered desirable, because congruent IPv4 and IPv6 topology simplifies maintenance and engineering. Nevertheless, 6to4 is considered convenient for cable modem (DOCSIS) users and IPv6 Rapid Deployment (6RD) is considered an attractive model by some. Various operators, but by no means all, also see a need for Teredo. One very large MPLS-based operator prefers 6PE because it avoids an IPv6 IGP and reduces operational costs. This operator also sees IPv4 scarcity addressed by DS-lite [DSLITE] and Carrier Grade NAT, also acting as a catalyst for IPv6. Another very large operator with an existing NAT44 infrastructure plans to use 6VPE [RFC4659] and believes that NAT64 will be similar to NAT44 in support requirements.
上記の概要で述べたように、応答したISPは圧倒的にネイティブのデュアルスタック展開を好みます。このモデルのシンプルさと、トンネルベースのソリューションの複雑さと準最適ルーティングについて多くのコメントが言及されていました。合同IPv4とIPv6トポロジはメンテナンスとエンジニアリングを簡素化するため、トポロジの再設計は一般に望ましいとは見なされません。それにもかかわらず、6to4はケーブルモデム（docsis）ユーザーにとって便利であると考えられており、IPv6 Rapid Deployment（6rd）は一部の魅力的なモデルと見なされます。さまざまなオペレーターですが、決してすべてではなく、テレドの必要性も見られます。MPLSベースの非常に大きなオペレーターの1つは、IPv6 IGPを回避し、運用コストを削減するため、6PEを好みます。また、この演算子は、DS-Lite [DSLite]とキャリアグレードNATによって対処されたIPv4不足を見ており、IPv6の触媒としても機能します。既存のNAT44インフラストラクチャを備えた別の非常に大規模なオペレーターは、6VPE [RFC4659]を使用する予定であり、NAT64はサポート要件でNAT44に似ていると考えています。
Several ISPs observe that IPv6 deployment is technically not hard. The most eloquent statement: "Just do it, bit by bit. It is very much an 'eating the elephant' problem, but at one mouthful at a time, it appears to be surprisingly easy." Other comments paraphrased from the replies are:
いくつかのISPは、IPv6の展開が技術的には難しくないことを観察しています。最も雄弁な声明：「少しずつ、少しずつ。それは非常に「象を食べる」問題ですが、一度に一杯で、驚くほど簡単に思えます。」返信から言い換えられた他のコメントは次のとおりです。
o Despite the known gaps, the tools and toolkits are fairly mature at this point.
o 既知のギャップにもかかわらず、この時点でツールとツールキットはかなり成熟しています。
o Managerial commitment and a systematic approach to analyzing requirements and readiness are essential.
o 要件と準備を分析するための管理的なコミットメントと体系的なアプローチが不可欠です。
o Evangelization remains a must, as it seems that many ISP and IT managers are still unaware of the need for an IPv6 plan, and are inclined to dismiss IPv4 depletion as a false alarm, and also seem unaware that NATs create expensive support requirements.
o 多くのISPとITマネージャーはまだIPv6プランの必要性を知らないように思われるため、福音化は依然として必須であり、IPv4の枯渇を誤報として却下する傾向があり、NATが高価なサポート要件を作成することも知らないようです。
o Without customers wanting IPv6, getting business backing is very hard, and IPv6 security and scale was not a focus for vendors until very recently.
o IPv6を望んでいない顧客がいなければ、ビジネスの支援を得ることは非常に困難であり、IPv6のセキュリティとスケールはごく最近までベンダーにとって焦点ではありませんでした。
o Operators lack real experience with customer usage of IPv6, and the resulting lack of confidence causes delay.
o オペレーターは、IPv6の顧客の使用に関する実際の経験を欠いており、結果として生じる自信の欠如は遅れを引き起こします。
Three further quotations are of interest:
さらに3つの引用が興味深いものです。
"We are planning to move all our management addressing from IPv4 to IPv6 to free up IPv4 addresses."
「IPv4からIPv4アドレスを解放するために、すべての経営陣をIPv4からIPv6に移動することを計画しています。」
"I am actively pushing our larger customers to start testing IPv6 as our development has pretty much stopped as we need some real world testing to be done."
「現実世界のテストを行う必要があるため、開発がほとんど停止しているため、大規模な顧客にIPv6のテストを開始するよう積極的に推進しています。」
"Customer support needs to be aware that IPv6 is being started in your network, or servers. We experienced many IPv6 blocking applications, applications that do not fall back to IPv4, etc. The most difficult part may be to get engineers, sales, customer support personnel to like IPv6."
「カスタマーサポートは、IPv6がネットワークまたはサーバーで開始されていることに注意する必要があります。多くのIPv6ブロッキングアプリケーション、IPv4に戻らないアプリケーションなどを経験しました。最も難しいのは、エンジニア、販売、顧客を獲得することです。IPv6を好む人員をサポートします。」
The survey has shown a certain number of desirable features to be missing, either in relevant specifications, or in many products. This section summarizes those gaps.
この調査では、関連する仕様または多くの製品のいずれかで、一定数の望ましい機能が欠落していることが示されています。このセクションでは、これらのギャップをまとめます。
As noted above, numerous models of various types of product still do not support IPv6:
上記のように、さまざまな種類の製品の多数のモデルがまだIPv6をサポートしていません。
o CPE
o CPE
o Handsets
o 携帯電話
o DSLAMs
o dslams
o Routers
o ルーター
o Traffic management boxes
o トラフィック管理ボックス
o Load balancers
o ロードバランサー
o VPN boxes
o VPNボックス
o SIP and other appliances
o SIPおよびその他の電化製品
o Management interfaces and systems
o 管理インターフェイスとシステム
o Firewalls
o ファイアウォール
o Even where they support IPv6, customer-side firewalls and routers need to operate at 25-100 Mbit/s
o IPv6をサポートする場合でも、顧客側のファイアウォールとルーターは25-100 Mbit/sで動作する必要があります
o Intrusion detection systems
o 侵入検知システム
o Accounting and billing systems
o 会計および請求システム
It is not the purpose of this document to name and shame vendors, but today it is becoming urgent for all products to avoid becoming part of the IPv4 legacy. ISPs stated that they want consistent feature-equivalent support for IPv4 and IPv6 in all equipment and software at reasonable or no extra cost. The problems can be quite subtle: for example, one CPE with "full" IPv6 support does not support IPv6 traffic shaping, so the ISP cannot cap IPv6 traffic to contractual limits.
このドキュメントの目的はベンダーと恥ずかしさの目的ではありませんが、今日ではすべての製品がIPv4レガシーの一部になることを避けるために緊急になっています。ISPは、すべての機器とソフトウェアでIPv4とIPv6の一貫した機能等価サポートを妥当なまたは追加費用なしで必要としていると述べました。問題は非常に微妙な場合があります。たとえば、「フル」IPv6サポートを備えた1つのCPEはIPv6トラフィックの形成をサポートしていないため、ISPはIPv6トラフィックを契約制限に制限することはできません。
Numerous ISPs want a scalable NAT64/DNS64 product.
多くのISPは、スケーラブルなNAT64/DNS64製品を望んでいます。
The need for IPv6 support in "all the best open source tools" was also mentioned.
「すべての最高のオープンソースツール」でのIPv6サポートの必要性も言及されました。
Several ISPs also noted that much commercial applications software does not correctly support IPv6 and that this will cause customer problems. Also, some operating systems are still shipped with IPv6 disabled by default or with features such as IPv4-mapped addresses disabled by default.
また、いくつかのISPは、多くの商用アプリケーションソフトウェアがIPv6を正しくサポートしておらず、これが顧客の問題を引き起こすと述べています。また、一部のオペレーティングシステムは、デフォルトではIPv6が無効になっているか、デフォルトで無効になっているIPv4マップアドレスなどの機能を備えています。
Various needs and issues related mainly to protocols were mentioned:
主にプロトコルに関連するさまざまなニーズと問題が言及されました。
o A specific CPE need is an intelligent prefix sub-delegation mechanism (ease of use issue).
o 特定のCPEニーズは、インテリジェントな接頭辞サブディレージゼーションメカニズム（使いやすさの問題）です。
o "Getting it right" so that a dual-stack client doesn't end up trying to use the wrong transport to reach a site.
o デュアルスタックのクライアントが間違ったトランスポートを使用してサイトに到達しようとしないように、「それを正しく」」。
o "User-side port allocation mechanisms. UPnP IGD and NAT-PMP can be used for IPv4, but nothing exists for IPv6 (yet)." UPnP IGD refers to the Universal Plug and Play Forum's Internet Gateway Device. NAT-PMP is the NAT Port Mapping Protocol.
o 「ユーザー側のポート割り当てメカニズム。UPNPIGDおよびNAT-PMPはIPv4に使用できますが、IPv6には何も存在しません（まだ）。」UPNP IGDは、ユニバーサルプラグアンドプレイフォーラムのインターネットゲートウェイデバイスを指します。NAT-PMPはNATポートマッピングプロトコルです。
Editor's comment: even though port mapping is in principle unnecessary for IPv6, a method of opening ports through firewalls on demand seems necessary.
編集者のコメント：ポートマッピングは原則としてIPv6にとって不要ですが、オンデマンドでファイアウォールを介してポートを開く方法が必要であると思われます。
o Full Router Advertisement (RA) support on LAN side of ADSL CPE.
o ADSL CPEのLAN側でのフルルーター広告（RA）サポート。
o PPPoE and RADIUS support. Specifically, global unicast address assignment for Layer 2 Tunneling Protocol (L2TP) / PPPoE. Currently, the PPPoE client will be assigned a link-local address, requiring a second step (DHCPv6 or SLAAC).
o pppoeおよびradiusサポート。具体的には、レイヤー2トンネリングプロトコル（L2TP） / PPPOEのグローバルユニキャストアドレスの割り当て。現在、PPPOEクライアントにはリンクローカルアドレスが割り当てられ、2番目のステップ（DHCPV6またはSLAAC）が必要です。
o Simple automatic distribution of DNS server details is essential; a DNS server option in RA [RFC5006] is wanted.
o DNSサーバーの詳細の単純な自動配信が不可欠です。RA [RFC5006]のDNSサーバーオプションが必要です。
o ISPs need fully featured DHCPv6, especially since SLAAC does not allow settings to be pushed out (except for RFC 5006).
o ISPは、特にSLAACでは設定をプッシュアウトすることを許可していないため、完全に機能するDHCPV6が必要です（RFC 5006を除く）。
o Firewall systems should not use separate IPv4 and IPv6 rules.
o ファイアウォールシステムは、個別のIPv4およびIPv6ルールを使用しないでください。
o Gaps in infrastructure security for IPv6 management.
o IPv6管理のインフラストラクチャセキュリティのギャップ。
o Gaps in routers' treatment of header options.
o ルーターのヘッダーオプションの処理のギャップ。
o RA-Guard in switches.
o スイッチのRAガード。
o Virtual Router Redundancy Protocol (VRRP) support.
o 仮想ルーター冗長プロトコル（VRRP）サポート。
o PE-CE routing protocols (OSPF and IS-IS).
o PE-CEルーティングプロトコル（OSPFおよびIS-IS）。
o Problems using a single BGP session to exchange routes for both IPv4 and IPv6.
o 単一のBGPセッションを使用して、IPv4とIPv6の両方のルートを交換する問題。
o Consistent IPv6 address display format in outputs and configuration input. Inconsistency breaks a lot of existing tools.
o 一貫したIPv6アドレス出力と構成入力の表示形式。矛盾は多くの既存のツールを破ります。
We also note areas where there was clearly confusion among the ISPs responding, which may denote weaknesses of existing documentation:
また、ISPが応答するISPの間に明らかに混乱があった領域にも注意してください。これは、既存のドキュメントの弱点を示す可能性があります。
o Perhaps due to poor phrasing in the survey questions, some ISPs indicated that they would use PPPoE or RADIUS to assign prefixes to CPEs. In fact, IPv6 PPP only negotiates 64-bit interface identifiers; a full address has to be assigned by another method, and even this does not delegate a prefix to a CPE router. RADIUS alone is also insufficient, as it needs to be combined with another method for full address assignment.
o おそらく、調査の質問での言い回しが悪いため、一部のISPは、PPPOEまたは半径を使用してプレフィックスをCPEに割り当てることを示しました。実際、IPv6 PPPは64ビットインターフェイス識別子のみを交渉します。完全なアドレスを別の方法で割り当てる必要があり、これでさえCPEルーターにプレフィックスを委任しません。RADIUSだけでも不十分です。これは、完全なアドレス割り当てのための別の方法と組み合わせる必要があるためです。
o Although most ISPs see a need for IPv4-IPv6 interworking at the network layer, many of them do not see a need for an ISP to operate the resulting translator. Yet, their customers, whether subscribers or content providers, will be the first to suffer when IPv6-only clients cannot reach IPv4-only services.
o ほとんどのISPは、ネットワークレイヤーでIPV4-IPV6インターワーキングの必要性を考えていますが、それらの多くは、結果の翻訳者を動作させるためにISPが必要とされていません。しかし、サブスクライバーであろうとコンテンツプロバイダーであろうと、IPv6のみのクライアントがIPv4のみのサービスに到達できない場合、彼らの顧客は最初に苦しむことになります。
o Most ISPs seemed to misunderstand the nature of a tunnel broker, even though this is a service that any ISP could consider offering to its subscribers.
o ほとんどのISPは、これがサブスクライバーに提供することを検討できるサービスであるにもかかわらず、トンネルブローカーの性質を誤解しているように見えました。
Global IPv6 connectivity still has issues; for example, ISPs in the Pacific region may have to obtain IPv6 transit via the USA (a situation faced by IPv4 operators in Europe about twenty years ago). Also, there are persistent Path MTU Discovery (PMTUD) issues in various places on the net, and a lack of multicast peering.
グローバルIPv6接続にはまだ問題があります。たとえば、太平洋地域のISPは、米国を介してIPv6トランジットを取得する必要がある場合があります（約20年前にヨーロッパのIPv4オペレーターが直面する状況）。また、ネット上のさまざまな場所に永続的なパスMTUディスカバリー（PMTUD）の問題があり、マルチキャストピアリングが不足しています。
Finally, there was a comment that real deployment case studies must be shown to operators along with multihoming and traffic engineering best practices.
最後に、マルチホームおよび交通工学のベストプラクティスとともに、実際の展開ケーススタディをオペレーターに示さなければならないというコメントがありました。
As a report on a survey, this document creates no security issues in itself. ISPs did not register any general concerns about IPv6 security. However, we note that about half of all firewall and intrusion detection products are still reported not to support IPv6. Some ISPs expressed concern about firewall performance and about the need for separate firewall configurations for IPv4 and IPv6.
調査に関するレポートとして、このドキュメントはそれ自体にセキュリティの問題を作成しません。ISPは、IPv6セキュリティに関する一般的な懸念を登録しませんでした。ただし、すべてのファイアウォールと侵入検知産物の約半分が、IPv6をサポートしていないためにまだ報告されていることに注意してください。一部のISPは、ファイアウォールのパフォーマンスと、IPv4とIPv6の個別のファイアウォール構成の必要性について懸念を表明しました。
We are grateful to all those who answered the questionnaire: Stewart Bamford, Pete Barnwell, Cameron Byrne, Gareth Campling, Kevin Epperson, David Freedman, Wesley George, Steinar Haug, Paul Hoogsteder, Mario Iseli, Christian Jacquenet, Kurt Jaeger, Seiichi Kawamura, Adrian Kennard, Simon Leinen, Riccardo Loselli, Janos Mohacsi, Jon Morby, Michael Newbery, Barry O'Donovan, Al Pooley, Antonio Querubin, Anthony Ryan, Marc Schaeffer, Valeriu Vraciu, Bill Walker, and those who preferred to remain anonymous.
アンケートに答えたすべての人に感謝しています：スチュワート・バンフォード、ピート・バーンウェル、キャメロン・バーン、ガレス・キャンプリング、ケビン・エッパーソン、デビッド・フリードマン、ウェスリー・ジョージ、シュタイナー・ハウグ、ポール・ホーグステダー、マリオ・イゼリ、クリスチャン・ジュケネット、クルト・ジェガー、エイドリアン・ケナード、サイモン・レイネン、リカルド・ロセッリ、ジャノス・モハクシ、ジョン・モービー、マイケル・ニューベリー、バリー・オドノヴァン、アル・プーリー、アントニオ・クルービン、アンソニー・ライアン、マーク・シェーファー、ヴァレリウ・ヴラシウ、ビル・ウォーカー、そしてアノーナスのまま。
The ISPs willing to be named were: AISP, Alphanet, Breedband Delft, Claranet, E4A, Fidonet, Finecom, France Telecom, Hungarnet, Imagine, LavaNet, Level 3 Communications LLC, NEC BIGLOBE, Nepustilnet, Net North West, RoEduNet, SWITCH, Snap, Sprint, Star Technology, T-Mobile USA, Ventelo, and Whole Ltd.
名前を付けようとするISPは、AISP、アルファネット、ブリードバンドデルフト、クララネット、E4A、フィドネット、フィネコム、フランステレコム、ハンガーネット、イマジン、ラバネット、レベル3通信LLC、NEC Biglobe、Nepustilnet、Net North West、Roedunet、Switch、スナップ、スプリント、スターテクノロジー、T-Mobile USA、Ventelo、およびWhole Ltd.
Useful comments and contributions were also made by Shane Amante, Mohamed Boucadair, Mark Smith, and others.
有用なコメントと貢献は、シェーンアマンテ、モハメドブーカデア、マークスミスなどによっても行われました。
This document was produced using the xml2rfc tool [RFC2629].
このドキュメントは、XML2RFCツール[RFC2629]を使用して作成されました。
[APLUSP] Bush, R., "The A+P Approach to the IPv4 Address Shortage", Work in Progress, October 2009.
[Aplusp] Bush、R。、「IPv4アドレス不足に対するA Pアプローチ」、2009年10月、進行中の作業。
[CGN] Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for IP address sharing schemes", Work in Progress, July 2010.
[CGN] Yamagata、I.、Miyakawa、S.、Nakagawa、A。、およびH. Ashida、「IPアドレス共有スキームの一般的な要件」、2010年7月の進行中。
[DSLITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", Work in Progress, August 2010.
[DSLITE] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4 Exhotion後のデュアルスタックLiteブロードバンド展開」、2010年8月の作業。
[NODEREQ] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements RFC 4294-bis", Work in Progress, July 2010.
[Nodereq] Jankiewicz、E.、Loughney、J。、およびT. Narten、「IPv6ノード要件RFC 4294-bis」、2010年7月の作業進行中。
[PRANGE] Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, "IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion: Port Range based IP Architecture", Work in Progress, July 2009.
[Prange] Boucadair、M.、Levis、P.、Bajko、G。、およびT. Savolainen、「IPv4のコンテキストでのIPv4接続アクセス排出：ポートレンジベースのIPアーキテクチャ」、2009年7月の作業。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629] Rose、M。、「XMLを使用したI-DSおよびRFCの書き込み」、RFC 2629、1999年6月。
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[RFC4029] Lind、M.、Ksinant、V.、Park、S.、Baudot、A。、およびP. Savola、「IPv6をISPネットワークに導入するためのシナリオと分析」、RFC 4029、2005年3月。
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006.
[RFC4294] Loughney、J。、「IPv6ノード要件」、RFC 4294、2006年4月。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
[RFC4659] De Clercq、J.、Ooms、D.、Carugi、M。、およびF. Le Faucheur、「BGP-MPLS IP仮想プライベートネットワーク（VPN）IPv6 VPNの拡張」、RFC 4659、2006年9月。
[RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and J. Palet, "ISP IPv6 Deployment Scenarios in Broadband Access Networks", RFC 4779, January 2007.
[RFC4779] Asadullah、S.、Ahmed、A.、Popoviciu、C.、Savola、P。、およびJ. Palet、「Broadband Access NetworksのISP IPv6展開シナリオ」、RFC 4779、2007年1月。
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC4798] de Clercq、J.、Ooms、D.、Prevost、S。、およびF. Le Faucheur、「IPv6プロバイダーエッジルーター（6PE）を使用してIPv4 MPLSを介してIPv6島を接続する」、RFC 4798、2007年2月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864] van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B。、およびE. Klein、「IPv6のローカルネットワーク保護」、RFC 4864、2007年5月。
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ Co-existence Security Considerations", RFC 4942, September 2007.
[RFC4942] Davies、E.、Krishnan、S。、およびP. Savola、「IPv6 Transition/ Co-Existence Security Cansationations」、RFC 4942、2007年9月。
[RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Option for DNS Configuration", RFC 5006, September 2007.
[RFC5006] Jeong、J.、Park、S.、Beloeil、L。、およびS. Madanapalli、「DNS構成のIPv6ルーター広告オプション」、RFC 5006、2007年9月。
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008.
[RFC5121] Patil、B.、Xia、F.、Sarikaya、B.、Choi、Jh。、およびS. Madanapalli、「IEEE 802.16ネットワークを介したIPv6収束崇高を介したIPv6の伝送」、RFC 5121、2008年2月。
[RFC5181] Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, "IPv6 Deployment Scenarios in 802.16 Networks", RFC 5181, May 2008.
[RFC5181] Shin、M-K。、Han、Y-H。、Kim、S-E。、およびD. Premec、「802.16ネットワークのIPv6展開シナリオ」、RFC 5181、2008年5月。
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 2008.
[RFC5211] Curran、J。、「インターネット移行計画」、RFC 5211、2008年7月。
[RFC5692] Jeon, H., Jeong, S., and M. Riegel, "Transmission of IP over Ethernet over IEEE 802.16 Networks", RFC 5692, October 2009.
[RFC5692] Jeon、H.、Jeong、S。、およびM. Riegel、「IEEE 802.16ネットワークを介したイーサネット上のIPの送信」、RFC 5692、2009年10月。
This summarizes the 31 replies received by April 14, 2010. Note that the answers to some questions do not total to 31, due to missing answers or to multiple choices in some cases. The ISPs are distributed as follows:
これは、2010年4月14日までに受け取った31の返信を要約しています。いくつかの質問に対する回答は、回答が欠落しているため、または複数の選択肢があるため、合計31にはならないことに注意してください。ISPは次のように分布しています。
Europe: 20
ヨーロッパ：20
North America: 7
北米：7
Asia/Pacific: 4
アジア/太平洋：4
They can additionally be classified as:
さらに、次のように分類できます。
Commercial: 26
コマーシャル：26
Academic/research: 4
アカデミック/研究：4
Operating internationally: 6
国際的に運営：6
Operating nationally: 25
全国的に運営：25
Basic data about IP service offerings:
IPサービスの提供に関する基本データ：
o Offering both origin-only and transit service: 25
o Originのみと輸送サービスの両方を提供する：25
o Offering no transit: 6
o 輸送なしの提供：6
o Number of private/small office customers (one IPv4 address): a few with zero, then from 30 units up to 40 million
o プライベート/スモールオフィスの顧客の数（1つのIPv4アドレス）：ゼロの少数、30ユニットから4,000万人まで
o Number of corporate customers (block of IPv4 addresses): a few with zero, then from 40 units up to 40000
o 企業顧客の数（IPv4アドレスのブロック）：ゼロの少数、40ユニットから40000まで
o IP multicast service? 9 yes, 22 no
o IPマルチキャストサービス？9はい、22いいえ
o Do any customers require multihoming to multiple ISPs? 25 yes, 6 no
o 複数のISPにマルチホミングを必要とする顧客はいますか？25はい、6いいえ
o Access technologies used: xDSL, DOCSIS, leased line (X.25, TDM/ PDH, SDH), ATM, frame relay, dialup, microwave, FTTP, CDMA, UMTS, LTE, WiMAX, BWA, WiFi, Ethernet (100M-10G), Ether/SONET, Ether/ MPLS, IPv6-in-IPv4 tunnels.
o 使用されるアクセステクノロジー：XDSL、DOCSIS、リースライン（X.25、TDM/ PDH、SDH）、ATM、フレームリレー、ダイヤルアップ、マイクロ波、FTTP、CDMA、UMTS、LTE、WIMAX、BWA、WiFi、イーサネット（100M-10G）、エーテル/ソネット、エーテル/ MPLS、IPv6-in-IPV4トンネル。
Customer Premises Equipment:
顧客宅内機器：
o Do customers use CPE that ISP supplies? 27 yes (10% to 100% of customers), 4 no
o 顧客はISPが供給するCPEを使用していますか？27はい（顧客の10％から100％）、4いいえ
o Does the CPE provided support native IPv6? 17 yes (some), 10 no
o CPEはネイティブIPv6をサポートしていますか？17はい（いくつか）、10いいえ
o (Note that these numbers include answers that apply to tens of millions of mobile handsets.)
o （これらの数値には、数千万人のモバイルハンドセットに適用される回答が含まれていることに注意してください。）
IPv4 Address Space:
IPv4アドレススペース：
o When do you expect to run out of public IPv4 address space inside your own network? Estimates run from "now" to 2020, but 5 ISPs say "never" or "unforeseeable".
o 独自のネットワーク内のパブリックIPv4アドレススペースが不足するのはいつですか？推定値は「Now」から2020年まで実行されますが、5 ISPは「決して」または「予期せぬ」と言います。
o Do you run RFC1918 addresses and NAT within your network? 9 yes; 18 no; 3 others say yes, but only for equipment management or L3VPN.
o ネットワーク内でRFC1918アドレスとNATを実行しますか？9はい;18いいえ;3他の人は「はい」と言いますが、機器管理またはL3VPNのみです。
o What % of IPv4 space is needed for ISP use (not for customers)? 1% to 30% (and 100% for NRENs with PI customers).
o ISPの使用に必要なIPv4スペースの何％が（顧客向けではありません）？1％から30％（PI顧客のNRENSの場合は100％）。
o When do you expect to run out of public IPv4 address space for customers? Answers range from 2010 to 2015; 4 ISPs say it depends on their registry. 4 or 5 give answers suggesting it will never happen.
o 顧客向けの公開IPv4アドレススペースが不足するのはいつですか？回答は2010年から2015年までの範囲です。4 ISPは、それがレジストリに依存すると言います。4または5は、それが決して起こらないことを示唆する答えを与えます。
o Do you offer RFC1918 addresses to customers? 6 yes, 24 no
o 顧客にRFC1918アドレスを提供していますか？6はい、24いいえ
IPv6 Requirements:
IPv6要件：
o Are some big customers requesting IPv6? 19 yes, 12 no
o 一部の大手顧客はIPv6を要求していますか？19はい、12いいえ
o When do you predict 10% and 50% of customers to require IPv6 service? Ignoring unclear answers, answers for 10% range from 2010 to 2017, and for 50% from 2011 to 2020.
o 顧客の10％と50％がIPv6サービスを必要とするのはいつですか？不明確な回答を無視すると、2010年から2017年までの10％の回答、2011年から2020年まで50％。
o When do you require IPv6 to be a standard service available to all customers? Answers range from 2010 to 2015; the most common answer is 2011.
o すべての顧客が利用できる標準サービスになるためにIPv6がいつ必要ですか？回答は2010年から2015年までの範囲です。最も一般的な答えは2011年です。
o When do you predict IPv6 traffic to reach 50% of total traffic? Answers range from 2011 to 2020; the most common answer is 2015.
o IPv6トラフィックはいつ総トラフィックの50％に達すると予測しますか？回答は2011年から2020年までの範囲です。最も一般的な答えは2015年です。
IPv6 Status and Plans:
IPv6ステータスと計画：
o Do you currently offer IPv6 as a regular service? 13 yes, 5 partial, 12 no
o 現在、通常のサービスとしてIPv6を提供していますか？13はい、5部分、12いいえ
o What % of customers currently use IPv6? <1% to 30%; mostly 0 or <1%
o 現在IPv6を使用している顧客は何ですか？<1％から30％。主に0または<1％
o When do you plan to start IPv6 deployment? 12 complete, 12 in progress, 3 in plan, 4 have no plan
o いつIPv6展開を開始する予定ですか？12完了、12の進行中、3つの計画、4つの計画がありません
o When do you plan to offer IPv6 as a special or beta-test service? For all those in progress or with a plan, the answer was either "now" or during 2010.
o IPv6を特別またはベータテストサービスとしていつ提供する予定ですか？進行中または計画を持っているすべての人にとって、答えは「今」または2010年の間でした。
o When do you plan to offer IPv6 as a regular service to all customers? For all those in progress or with a plan, the answer was between "now" and 2013 (except for one ISP who replied that it depends on the marketing department).
o すべての顧客への通常のサービスとしてIPv6をいつ提供する予定ですか？進行中または計画を立てているすべての人にとって、答えは「現在」と2013年の間でした（マーケティング部門に依存すると答えたISPの1人を除く）。
IPv6 Technologies. Note the answers refer to actual deployment or to plans, as the case may be:
IPv6テクノロジー。回答は、実際の展開または計画を指します。
o Which basic IPv6 access method(s) apply?
o どの基本的なIPv6アクセス方法が適用されますか？
* Dual-stack routing backbone: 29 yes, 1 maybe
* デュアルスタックルーティングバックボーン：29はい、1多分
* Separate IPv4 and IPv6 backbones: 2 yes, 1 maybe
* IPv4とIPv6のバックボーンを分離：2はい、1多分
* 6to4 relay: 12 yes
* 6to4リレー：12はい
* Teredo server: 5 yes
* Teredo Server：5はい
* Tunnel broker: Unfortunately this question was unclear and obviously misunderstood by most respondents. Several respondents mentioned that they are getting their own transit connectivity via static tunnels.
* トンネルブローカー：残念ながら、この質問は不明確であり、ほとんどの回答者によって明らかに誤解されていました。数人の回答者は、静的トンネルを介して独自の輸送接続を取得していると述べました。
* Something else: Answers were 6VPE + NAT64/DNS64; PNAT; "considering 6RD"
* 他の何か：回答は6VPE NAT64/DNS64でした。pnat;「6番目を考慮して」
o Please briefly explain the main reasons/issues behind your choice: The best summary of the answers is "dual stack is simplest, why do anything else?".
o 選択の背後にある主な理由/問題を簡単に説明してください。回答の最良の要約は、「デュアルスタックが最も簡単です、なぜ他に何かをするのですか？」です。
o Which types of equipment in your network are unable to support IPv6? The most common answer was CPE (9 mentions). Also mentioned: handsets; DSLAMs; routers (including several specific models); traffic management boxes; load balancers; VPN boxes; some SIP platforms; management interfaces & systems; firewalls; billing systems.
o ネットワーク内のどのタイプの機器がIPv6をサポートできませんか？最も一般的な答えはCPEでした（9件の言及）。また、携帯電話。dslams;ルーター（いくつかの特定のモデルを含む）;トラフィック管理ボックス。ロードバランサー。VPNボックス;一部のSIPプラットフォーム。管理インターフェイスとシステム;ファイアウォール;請求システム。
o Can they be field-upgraded? 5 yes, 4 partially, 10 no and numerous "don't know" or "hopefully"
o フィールドアップグレードできますか？5はい、4部分的に、10いいえ、多数の「わからない」または「うまくいけば」
o Is any equipment 100% dedicated to IPv6? 7 yes, 24 no
o IPv6専用の機器はありますか？7はい、24いいえ
o Is IPv6 an opportunity to restructure your whole topology? 2 yes, 5 partial, 23 no
o IPv6はトポロジ全体を再構築する機会ですか？2はい、5部分、23いいえ
o Do you include support for DNS AAAA queries over IPv6? 21 yes, 5 plan, 4 no
o IPv6を介したDNS AAAAクエリのサポートを含めていますか？21はい、5つの計画、4いいえ
o Do you include support for reverse DNS for IPv6 addresses? 22 yes, 3 plan, 5 no
o IPv6アドレスのリバースDNSのサポートを含めていますか？22はい、3つの計画、5いいえ
o What length(s) of IPv6 prefix do you have or need from the registry? 1 /19, 1 /21 (plus several /32s), 1 /22 1 /30, 3 multiple /32s, 21 /32, 3 /48
o レジストリからは、IPv6プレフィックスの長さ（s）がありますか、それとも必要ですか？1/19、1 /21（プラス数 /32S）、1 /22 1 /30、3倍数 /32S、21 /32、3 /48
o What length(s) of IPv6 prefix are offered to customers? 15 ISPs offer more than one of /48, /52, /56, /60 or /64. 2 offer /56 only, 8 offer /48 only. Two wired operators offer /64 only. Mobile operators offer /64 in accordance with 3GPP, but at least one would like to be allowed to offer /128 or /126.
o IPv6プレフィックスの長さは顧客に提供されますか？15 ISPは、 /48、 /52、 /56、 /60または /64のうち2つ以上を提供しています。2オファー /56のみ、8オファー /48のみ。2つの有線演算子は /64のみを提供します。モバイルオペレーターは3GPPに従って /64を提供しますが、少なくとも1つは /128または /126を提供することを許可したいと考えています。
o Do any customers share their IPv6 prefix among multiple hosts? Unfortunately this question was unclear and obviously misunderstood by most respondents.
o 複数のホストの間でIPv6プレフィックスを共有している顧客はいますか？残念ながら、この質問は不明であり、明らかにほとんどの回答者によって誤解されていました。
o Do any of your customers prefer to use PI IPv6 prefixes? 10 yes, 17 no
o お客様のいずれかがPI IPv6プレフィックスを使用することを好みますか？10はい、17いいえ
o How are IPv6 prefixes delegated to CPEs? 16 manual, 10 DHCPv6[-PD], 8 SLAAC, 8 RADIUS, 2 PPPoE. (Note: RADIUS and PPP cannot in fact delegate prefixes.)
o IPv6プレフィックスはCPESにどのように委任されますか？16マニュアル、10 dhcpv6 [-pd]、8 slaac、8 radius、2 pppoe。（注：radiusとPPPは実際にはプレフィックスを委任できません。）
o Are your SMTP, POP3 and IMAP services dual stack? 10 yes, 6 plan, 13 no
o SMTP、POP3、およびIMAPサービスのデュアルスタックですか？10はい、6つの計画、13いいえ
o Are your HTTP services, including caching and webmail, dual-stack? 9 yes, 1 partial, 4 plan, 15 no
o キャッシュやウェブメールなどのHTTPサービスはデュアルスタックですか？9はい、1部分、4つの計画、15いいえ
o Are any other services dual stack? 11 yes, 2 plan, 11 no o Is each of the following dual stack?
o 他のサービスはデュアルスタックですか？11はい、2つの計画、11いいえo次のデュアルスタックはそれぞれですか？
* Firewalls: 12 yes, 3 partial, 3 plan, 9 no
* ファイアウォール：12はい、3部分、3つの計画、9いいえ
* Intrusion detection: 10 yes, 2 plan, 13 no
* 侵入検出：10はい、2つの計画、13いいえ
* Address management software: 15 yes, 1 plan, 13 no
* アドレス管理ソフトウェア：15はい、1つの計画、13いいえ
* Accounting software: 7 yes, 21 no
* 会計ソフトウェア：7はい、21いいえ
* Monitoring software: 16 yes, 2 partial, 2 plan, 11 no
* 監視ソフトウェア：16はい、2部分、2つの計画、11 no
* Network management tools: 13 yes, 4 partial, 1 plan, 11 no
* ネットワーク管理ツール：13はい、4部分、1つの計画、11 no
o Do you or will you have IPv6-only customers? 13 yes (or maybe), 18 no (or not likely)
o あなたはIPv6のみの顧客を持っていますか？13はい（または多分）、18いいえ（またはそうではない）
o Do you have customers who have explicitly refused to consider IPv6? 5 yes, 23 no
o IPv6の検討を明示的に拒否した顧客はいますか？5はい、23いいえ
o Interworking issues:
o インターワーキングの問題：
* How many years do you expect customers to run any IPv4-only applications? Answers range from 2 years to infinity, most frequent answer is >10 years.
* 顧客がIPv4のみのアプリケーションを実行することを何年期待しますか？回答は2年から無限の範囲で、最も頻繁な回答は10年以上です。
* Is IPv6-IPv4 interworking at the IP layer needed? 16 yes, 9 uncertain, 3 no
* IPレイヤーでのIPv6-IPV4インターワーキングは必要ですか？16はい、9不確か、3いいえ
* Do you include a NAT-PT IPv6/IPv4 translator? 2 yes, 1 plan, 26 no
* NAT-PT IPv6/IPv4翻訳者を含めていますか？2はい、1つの計画、26いいえ
* If yes, does that include DNS translation? 1 plan, 2 no
* はいの場合、それにはDNS翻訳が含まれますか？1つの計画、2いいえ
* If not, do you plan to operate an IPv6/IPv4 translator? 10 plan (NAT64), 8 no, others uncertain
* そうでない場合は、IPv6/IPv4翻訳者を操作する予定ですか？10プラン（NAT64）、8いいえ、他の人は不確かです
* If not, how do you plan to connect IPv6-only customers to IPv4- only services? 7 rely on dual stack; 4 have no plan (one said "their problem")
* そうでない場合、どのようにしてIPv6のみの顧客をIPv4-のみサービスに接続する予定ですか？7デュアルスタックに依存しています。4計画がない（「彼らの問題」と言った）
* If you offer IP multicast, will that need to be translated too? 2 yes, 2 uncertain, 5 no
* IPマルチキャストを提供する場合、それも翻訳する必要がありますか？2はい、2不確か、5いいえ
o Any plans for Mobile IPv6 (or Nemo mobile networks)? 6 yes, 2 uncertain, 22 no
o モバイルIPv6（またはNEMOモバイルネットワーク）の計画はありますか？6はい、2不確実、22いいえ
This appendix reproduces the technical body of the questionnaire that was made available for ISPs to express their requirements, plans, and experience.
この付録は、ISPが要件、計画、および経験を表現するために利用可能になったアンケートの技術機関を再現しています。
I. General questions about IP service
I. IPサービスに関する一般的な質問
1. Do you offer origin-only (stub, end-user) IP service, transit IP service, or both?
1. Originのみの（スタブ、エンドユーザー）IPサービス、トランジットIPサービス、またはその両方を提供していますか？
2. Approximate number of private/small office customers (one IPv4 address)
2. プライベート/スモールオフィスのお客様のおおよその数（1つのIPv4アドレス）
3. Approximate number of corporate customers (block of IPv4 addresses, not included in Q2)
3. おおよその企業顧客の数（Q2に含まれていないIPv4アドレスのブロック）
4. Do you offer IP multicast service?
4. IPマルチキャストサービスを提供していますか？
5. Do any of your customers require multihoming to multiple ISPs?
5. 顧客のいずれかが複数のISPにマルチホミングを必要としていますか？
6. Access technologies used (ADSL,etc.)
6. 使用されるアクセステクノロジー（ADSLなど）
7. Do your customers use CPE that you supply?
7. あなたの顧客はあなたが提供するCPEを使用していますか？
7.1. What % of customers?
7.1. 顧客の何パーセント？
7.2. Does the CPE that you provide support native IPv6?
7.2. ネイティブIPv6をサポートするCPEはありますか？
8. When do you expect to run out of public IPv4 address space inside your own network?
8. 独自のネットワーク内のパブリックIPv4アドレススペースが不足するのはいつですか？
8.1. Do you run private (RFC1918) addresses and NAT within your network (i.e., a second layer of NAT in the case of customers with their own NAT)?
8.1. ネットワーク内でプライベート（RFC1918）アドレスとNATを実行していますか（つまり、NATの場合のNATの2番目のレイヤー）？
8.2. What % of your IPv4 space is needed for your own use (not for customers)?
8.2. あなた自身の使用に必要なIPv4スペースの何％が（顧客向けではありません）？
9. When do you expect to run out of public IPv4 address space for customers?
9. 顧客向けの公開IPv4アドレススペースが不足するのはいつですか？
9.1. Do you offer private (RFC1918) addresses to your customers?
9.1. 顧客にプライベート（RFC1918）アドレスを提供していますか？
II. Questions about requirements for IPv6 service
ii。IPv6サービスの要件に関する質問
10. Are some big customers requesting IPv6?
10. 一部の大手顧客はIPv6を要求していますか？
11. When do you predict 10% and 50% of your customers to require IPv6 service?
11. 顧客の10％と50％がIPv6サービスを必要とするのはいつですか？
12. When do you require IPv6 to be a standard service available to all customers?
12. すべての顧客が利用できる標準サービスになるためにIPv6がいつ必要ですか？
13. When do you predict IPv6 traffic to reach 50% of total traffic?
13. IPv6トラフィックはいつ総トラフィックの50％に達すると予測しますか？
III. Questions about status and plans for IPv6 service
iii。IPv6サービスのステータスと計画に関する質問
14. Do you currently offer IPv6 as a regular service?
14. 現在、通常のサービスとしてIPv6を提供していますか？
14.1. What % of your customers currently use IPv6?
14.1. 現在、顧客の何パーセントがIPv6を使用していますか？
14.2. When do you plan to start IPv6 deployment?
14.2. いつIPv6展開を開始する予定ですか？
14.3. When do you plan to offer IPv6 as a special or beta-test service to customers?
14.3. IPv6を顧客に特別またはベータテストサービスとして提供するのはいつですか？
15. When do you plan to offer IPv6 as a regular service to all customers?
15. すべての顧客への通常のサービスとしてIPv6をいつ提供する予定ですか？
IV. Questions about IPv6 technologies
IV。IPv6テクノロジーに関する質問
16. Which basic IPv6 access method(s) apply:
16. どの基本的なIPv6アクセス方法が適用されますか：
16.1. dual stack routing backbone?
16.1. デュアルスタックルーティングバックボーン？
16.2. separate IPv4 and IPv6 backbones?
16.2. IPv4とIPv6のバックボーンを分離しますか？
16.3. 6to4 relay?
16.3. 6to4リレー？
16.4. Teredo server?
16.4. Teredoサーバー？
16.5. tunnel broker? If so, which one?
16.5. トンネルブローカー？もしそうなら、どれですか？
16.6. Something else? Please briefly describe your method:
16.6. 他に何か？あなたの方法について簡単に説明してください：
16.7. If possible, please briefly explain the main reasons/ issues behind your choice.
16.7. 可能であれば、お好みの背後にある主な理由/問題を簡単に説明してください。
17. Which types of equipment in your network are unable to support IPv6? 17.1. Can they be field-upgraded to support IPv6?
17. ネットワーク内のどのタイプの機器がIPv6をサポートできませんか？17.1。IPv6をサポートするためにフィールドアップグレードできますか？
17.2. Is any equipment 100% dedicated to IPv6?
17.2. IPv6専用の機器はありますか？
18. Is IPv6 an opportunity to restructure your whole topology?
18. IPv6はトポロジ全体を再構築する機会ですか？
19. Do you include support for DNS AAAA queries over IPv6?
19. IPv6を介したDNS AAAAクエリのサポートを含めていますか？
20. Do you include support for reverse DNS for IPv6 addresses?
20. IPv6アドレスのリバースDNSのサポートを含めていますか？
21. What length(s) of IPv6 prefix do you have or need from the registry?
21. レジストリからは、IPv6プレフィックスの長さ（s）がありますか、それとも必要ですか？
22. What length(s) of IPv6 prefix are offered to customers?
22. IPv6プレフィックスの長さは顧客に提供されますか？
22.1. Do any customers share their IPv6 prefix among multiple hosts?
22.1. 複数のホストの間でIPv6プレフィックスを共有している顧客はいますか？
23. Do any of your customers prefer to use PI IPv6 prefixes instead of a prefix from you?
23. 顧客は、あなたからのプレフィックスの代わりにPI IPv6プレフィックスを使用することを好みますか？
24. How are IPv6 prefixes delegated to CPEs? (Manual, PPPoE, RADIUS, DHCPv6, stateless autoconfiguration/RA, etc...)
24. IPv6プレフィックスはCPESにどのように委任されますか？（マニュアル、PPPOE、RADIUS、DHCPV6、Stateless Autoconfiguration/RAなど...）
25. Are your SMTP, POP3 and IMAP services dual-stack?
25. あなたのSMTP、POP3、およびIMAPサービスはデュアルスタックですか？
26. Are your HTTP services, including caching and webmail, dual-stack?
26. キャッシュやウェブメールなどのHTTPサービスはデュアルスタックですか？
27. Are any other services dual-stack?
27. 他のサービスはデュアルスタックですか？
28. Is each of the following dual-stack?
28. それぞれ次のデュアルスタックですか？
28.1. Firewalls
28.1. ファイアウォール
28.2. Intrusion detection
28.2. 侵入検知
28.3. Address management software
28.3. アドレス管理ソフトウェア
28.4. Accounting software
28.4. 会計ソフトウェア
28.5. Monitoring software
28.5. 監視ソフトウェア
28.6. Network management tools
28.6. ネットワーク管理ツール
29. Do you or will you have IPv6-only customers?
29. あなたはIPv6のみの顧客を持っていますか？
30. Do you have customers who have explicitly refused to consider IPv6?
30. IPv6の検討を明示的に拒否した顧客はいますか？
31. How many years do you expect customers to run any IPv4-only applications?
31. 顧客がIPv4のみのアプリケーションを実行することを何年期待しますか？
32. Is IPv6-IPv4 interworking at the IP layer needed?
32. IPレイヤーでのIPv6-IPV4インターワーキングは必要ですか？
33. Do you include a NAT-PT IPv6/IPv4 translator?
33. NAT-PT IPv6/IPv4翻訳者を含めていますか？
33.1. If yes, does that include DNS translation?
33.1. はいの場合、それにはDNS翻訳が含まれますか？
33.2. If not, do you plan to operate an IPv6/IPv4 translator?
33.2. そうでない場合は、IPv6/IPv4翻訳者を操作する予定ですか？
33.3. If not, how do you plan to connect IPv6-only customers to IPv4-only services?
33.3. そうでない場合、IPv6のみの顧客をIPv4のみのサービスに接続する予定ですか？
33.4. If you offer IP multicast, will that need to be translated too?
33.4. IPマルチキャストを提供する場合、それも翻訳する必要がありますか？
34. Any plans for Mobile IPv6 (or Nemo mobile networks)?
34. モバイルIPv6（またはNEMOモバイルネットワーク）の計画はありますか？
35. What features and tools are missing today for IPv6 deployment and operations?
35. IPv6の展開と操作のために、今日はどのような機能とツールが欠けていますか？
36. Any other comments about your IPv6 experience or plans? What went well, what was difficult, etc.
36. IPv6の経験や計画に関する他のコメントはありますか？何がうまくいったのか、何が難しかったかなど
Authors' Addresses
著者のアドレス
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand
ブライアンカーペンターコンピュータサイエンス大学オークランド大学PB 92019オークランド、1142ニュージーランド
EMail: brian.e.carpenter@gmail.com
Sheng Jiang Huawei Technologies Co., Ltd KuiKe Building, No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing P.R. China
Sheng Jiang Huawei Technologies Co.、Ltd Kuike Building、No.9 Xinxi Rd。、Shang-Di Information Industry Base、Hai-Dian District、Beijing P.R. China
EMail: shengjiang@huawei.com