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
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サービスの展開のためのインターネット・サービス・プロバイダーの間で浮上している慣行や計画を説明しています。彼らは、これまでの実務経験に基づいて、同様のISPの数の調査で報告された現在の計画と要件は、2010年初めに行わこの文書では、技術のギャップの数を特定し、それは勧告を行いませんされています。
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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）は三の大の選択肢の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.の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. [CGN】ネットワークアドレス変換（NAT）の複数の層をインストールするか、そのようなアドレスプラスポートマッピングなどの他の方法[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).
多くのISPは、（3）の準備をしながら、（1）又は（2）を使用することで、IPv4の寿命を延ばすために状況によって義務付けされてもよいことを認識しながら、この文書では、（3）代替的に焦点を当てています。
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.
この文書は、IPv6の展開シナリオがすでに採用したり、現在の技術的なアンケートに答えたのISPの集合によって計画について説明します。したがって、これらの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.
アドレッシング、ルーティング、DNS、管理、およびIPv4にIPv6の共存と相互動作：我々は、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]は、問題が何年か前に見られていたとして、ISPのネットワークにIPv6を導入するためのシナリオについて説明します。その最終目標は、単にデュアルスタックISPのバックボーンです。今日のビューは、IPv6のみとレガシー（IPv4のみ）ホスト間でそれがインターワーキングを許可しないよう、これは、不十分であるということです。確かに、最終目標は、今日では、従来の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サイトのネットワークの内部構造がどのように保護することができ、「ローカルネットワーク保護」について説明します。これは、彼らがIPv6を展開した後、ISPの顧客が保護されてどれだけ影響します。
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のみの間のIPレイヤインターワーキングの問題を解決するために、IETFに続くことに留意すべきであるとIPv4のみのホスト。そのようなHTTPプロキシまたはSMTPサーバれるように、アプリケーション・セッションのいずれか一方の端部は、デュアルスタック接続、またはデュアルスタックの中間になります：アプリケーション層でのIPv6 / IPv4のインターワーキングは、IPv6展開のオリジナルデュアルスタックモデル内で処理されます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が他よりも答えている可能性が高いことを前提としています。従って、結果は、いくつかの注意を払って解釈されるべきです。
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人の顧客からの4000万まで）サイズの広大な範囲で、優勢。一部のプロバイダは、顧客の正確な数についてはお答えしないことを選択したことに注意してください。それにもかかわらず、6つのプロバイダそれぞれが数百万の顧客を持っていたと言うことができ、次の10はそれぞれ、1万人の以上の顧客を有しており、残りの15は、それぞれ未満万人の顧客を持っていました。
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）無線LAN、イーサネット（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
ISPは内部使用のためのパブリックIPv4アドレス空間を使い果たしますときの推定値は、「今」と「決して」の間で、大きく異なります。顧客のためのパブリックIPv4アドレス空間は、主との間で実行することが予想されます
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.
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範囲を必要とし、これらのISPがIPv6が2015から2010によって標準サービスであることを必要と2011年から2020年に50％になるときの予測。最も一般的な目標期限は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.
一般的に、それは顧客の1％未満で使用されている、けれどものISPの42％はすでに、定期的なサービスとしてIPv6を提供します。 ISPの別の48％は、進行中または計画中のIPv6の展開を持っています。定期的なサービスのための2010年計画の日付でこれらのすべての計画、少なくともベータテストサービスは、2010年と2013年の間に（それがマーケティング部門に依存していることを答えた1つのISPを除く）です。 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言及）でした。また、言及した：携帯電話;デジタル加入者線アクセスマルチプレクサ（DSLAMの）; （いくつかの特定のモデルを含む）、ルータ;トラフィック管理の箱。ロードバランサ。 VPNボックス。いくつかのSIPプラットフォーム。管理インターフェース・システム。ファイアウォール;課金システム。このような装置は、フィールドアップグレードが可能かどうかを尋ねられたとき、答えは悲観的だった：5はい、4部分的に、10いいえ、および多数は「うまくいけば」「知りません」または。
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％サポートまたはIPv6上DNS認証、許可、アカウンティング、および監査（AAAA）クエリを計画し、これらのいずれかが、すべては、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までの範囲のプレフィックスを持っており、顧客のプレフィックスのための政策の多様性を持っています。十五社のISP以上/ 48のいずれか、/ 52、/ 56、/ 60、または/ 64を提供します。二つのオファー/ 56のみ、8つのオファー/ 48のみ。二つの有線事業者はのみ/ 64を提供します。携帯電話事業者は、3GPPに従って/ 64を提供していますが、少なくとも一つは/ 128または/ 126を提供するために許可されたいです。また、事業者の多くは30％がすでにPI（プロバイダに依存しない）プレフィックスを好むのIPv6顧客を持っています。 CPEにプレフィックス委譲のために選択された方法は、手動のDHCPv6 [-PD]、ステートレスアドレス自動設定（SLAAC）、RADIUS、およびイーサネット上のポイントツーポイントプロトコル（PPPoEの）です。しかし、実際には、後者の二つは、自分のプレフィックスを割り当てることはできません。
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のみの顧客を持つことを期待していない（ただし、携帯電話事業者は、彼らが何百万を持っています確信しています）。ファイブISPは、明示的にIPv6を検討することを拒否した顧客を報告しています。 IPv4のみのアプリケーションを実行する方法を長い間お客様に尋ねたところ、最も多かっ答えは「十年以上」です。 3つだけのISPは、IPレイヤでのIPv6-IPv4のインターワーキングが必要とされていないと述べています。一方、3つだけは、（異なる3！）を実行するか、NAT-PT（プロトコル変換）を実行する予定。翻訳者のいくつかの種類（おそらくNAT64 / DNS64）を実行するには、少なくとも30％の計画、2つだけは、マルチキャスト翻訳者が必要不可欠だと感じました。彼らはIPv4のみのサービスにIPv6のみの顧客を接続する予定か尋ねられたとき、トランスレータを計画していない人のうち、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（またはニモモバイルネットワーク）のための計画について尋ねられ、19％はそう言って、71％が不確実な他の人と、ノーと言いました。詳細な分析は、正に応答し6つのISPの三大携帯電話事業者である（及び第四のモバイルオペレータがない前記）ことを示しています。肯定的に答え、他の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の代わりに、単純なデュアルスタックで、プロバイダーエッジルータ（6VPE）にVPN上でIPv6を使用する6PEとデュアルスタックライト（DS-LITE）、および別のものを使用することを計画していることです。他の大規模事業者とすべての中小事業者は、単純なデュアルスタックを好みます。
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）のために便利と考えられています。様々な事業者が、決してすべてで、また、Teredoのための必要性を参照してください。それはIPv6のIGPを回避し、運用コストを削減するため、1つの非常に大規模なMPLSベースのオペレータは、6PEを好みます。この演算子はまた、IPv6のための触媒として作用して、DS-liteの[DSLite専用]とキャリアグレードNATによって対処のIPv4不足を見ています。既存の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.
多くのISPおよびIT管理者は、まだIPv6の計画の必要性に気づいていない、と誤警報とIPv4の枯渇を閉じ傾斜しており、また、NATのは、高価なサポート要件を作成することを気づいていないように見えるようだとO福音宣教は、必見のまま。
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から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 Routers
Oルータ
o Traffic management boxes
Oトラフィック管理ボックス
o Load balancers
O負荷バランサ
o VPN boxes
OのVPNボックス
o SIP and other appliances
SIPおよび他の機器O
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
彼らはIPv6をサポートしているOであっても、顧客側のファイアウォールやルータは、25〜100メガビット/秒で動作する必要があります
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のための一貫性のある機能と同等のサポートをしたいと述べました。問題は非常に微妙なことができます：ISPは、契約上の制限にIPv6トラフィックをキャップすることはできませんので、例えば、「完全な」IPv6をサポートした1つのCPEは、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をサポートしていないことと、これは顧客の問題を引き起こすだろうと指摘しました。また、一部のオペレーティングシステムでは、まだ、デフォルトで、あるいはデフォルトでは無効にIPv4マップアドレスなどの機能を無効にしたIPv6に同梱されています。
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.
「ユーザ側ポート割り当てメカニズム。のUPnP IGDと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.
ADSLのCPEのLAN側のO全ルータ広告（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).
PPPoEおよびRADIUSのサポート、O。具体的には、レイヤ2トンネリングプロトコル（L2TP）/ PPPoEのグローバルユニキャストアドレスの割り当て。現在、PPPoEクライアントは、第二工程（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が設定（RFC 5006を除く）に押し出さすることはできません、特に以来、フル機能のDHCPv6を必要としています。
o Firewall systems should not use separate IPv4 and IPv6 rules.
Oファイアウォールのシステムは、独立したIPv4とIPv6のルールを使用しないでください。
o Gaps in infrastructure security for IPv6 management.
IPv6の管理のためのインフラストラクチャのセキュリティにおけるOギャップ。
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問題は、IPv4とIPv6の両方のためのルートを交換するために、単一のBGPセッションを使用します。
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、の間で混乱があった領域の点に注意してください。
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は、彼らがのCPEにプレフィックスを割り当てるためにPPPoEまたはRADIUSを使用することが示されました。実際には、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.
ほとんどのISPは、ネットワーク層でのIPv4-IPv6のインターワーキングの必要性を参照してくださいoをするが、それらの多くは、得られたトランスレータを動作させるための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が、これはどの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は、米国（約20年前にヨーロッパでのIPv4事業者が直面している状況）を経由してIPv6のトランジットを取得する必要があります。また、永続的なパス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.
私たちは、アンケートに答えたすべての人に感謝しています：スチュワートバンフォード、ピート・バーンウェル、キャメロン・バーン、ガレスCampling、ケビンEpperson、デビッド・フリードマン、ウェズリー・ジョージ、Steinarハウグ、ポールHoogsteder、マリオIseli、クリスチャンJacquenet、クルト・イェーガー、誠一川村、エイドリアン・ケナード、サイモンLeinen、リッカルドLoselli、ヤーノシュMohacsi、ジョンMorby、マイケル・ニューベリー、バリーO'Donovan、アルプーリー、アントニオQuerubin、アンソニー・ライアン、マーク・シェーファー、Valeriu Vraciu、ビル・ウォーカー、と匿名を好ま人々。
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、Alphanet、Breedbandデルフト、Claranet、E4A、からFidonet、Finecom、フランステレコム、Hungarnet、想像し、LavaNet、レベル3コミュニケーションズLLC、NECビッグローブ、Nepustilnet、ネット北西、RoEduNet、SWITCH、スナップ、スプリント、スターテクノロジー、TモバイルUSA、Ventelo、全体株式会社
Useful comments and contributions were also made by Shane Amante, Mohamed Boucadair, Mark Smith, and others.
有益なコメントと貢献もシェーンAmante、モハメドBoucadair、マーク・スミス、そして他の人によって作られました。
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]ブッシュ、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]山形、I.、宮川、S.、中川、A.、およびH.芦田、 "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専用]デュラン、A.、Droms、R.、Woodyatt、J.、およびY.リー、 "デュアルスタックLiteのブロードバンドの展開に続いてIPv4の枯渇"、進歩、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 - ビス"、進歩、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.、リーバイス、P.、Bajko、G.、およびT. Savolainenの、 "IPアドレス枯渇問題のコンテキストにおけるIPv4の接続アクセス：ポート範囲ベースのIPアーキテクチャ"、進歩、2009年7月での作業。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629]ローズ、M.、 "ライティングI-DSおよびXMLを使用している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]リンド、M.、Ksinant、V.、公園、S.、ボドー、A.、およびP. Savola、 "ISPネットワークにIPv6を導入するためのシナリオと分析"、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]デClercq、J.、Ooms、D.、Carugi、M.、およびF.ル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.、アハメド、A.、Popoviciu、C.、Savola、P.、およびJ. Palet、 "ブロードバンドアクセスネットワークにおける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]デClercq、J.、Ooms、D.、プレボ、S.、およびF.ルFaucheur、 "IPv6のプロバイダエッジルータを使用したIPv4 MPLS上のIPv6諸島接続（6PE）"、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]ヴァン・デ・ヴェルデ、G.、ハイン、T.、Droms、R.、大工、B.、およびE.クライン、 "IPv6のローカルネットワークの保護"、RFC 4864、2007年5月。
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ Co-existence Security Considerations", RFC 4942, September 2007.
[RFC4942]デイヴィス、E.、クリシュナン、S.、およびP. Savola、 "IPv6移行/共存のセキュリティの考慮事項"、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]チョン、J.、公園、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]パティル、B.、夏、F.、Sarikaya、B.、チェ、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]新、M-K。、ハン、Y-H。、キム、S-E。、およびD. Premec、 "802.16ネットワークにおけるIPv6の展開シナリオ"、RFC 5181、2008年5月。
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 2008.
[RFC5211]カラン、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]チョン、H.、チョン、S.、およびM.リーゲル、 "IEEE 802.16ネットワーク経由イーサネット上のIPの送信"、RFC 5692、2009年10月。
Appendix A. Summary of Replies
回答の付録A.概要
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:
これは、4月14日によって受信された31件の回答をまとめたもので、いくつかの質問に対する回答が見つからないため、答えに場合によっては複数の選択肢に、31に合計していないことを2010年に注意してください。次のように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
25：原点のみとトランジットサービスの両方を提供するO
o Offering no transit: 6
何の輸送を提供していない○：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台から最大40百万、その後、ゼロの数
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
IPマルチキャストサービスO？ 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、無線LAN、イーサネット（100M- 10G）、エーテル/ SONET、エーテル/ MPLS、IPv6のインIPv4トンネル。
Customer Premises Equipment:
顧客宅内機器：
o Do customers use CPE that ISP supplies? 27 yes (10% to 100% of customers), 4 no
O顧客はCPE ISP用品を使用していますか？ 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アドレス空間の不足に期待していますか？見積もりは、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のIPv4スペースの何％が（ない顧客のための）ISPの使用のために必要とされていますか？ 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するときは、IPv6サービスを必要とする10％のお客様の50％を予測していますか？ 2010 2017から10パーセントの範囲のための答えを不明確答えを無視し、2020年から2011年から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するときは、総トラフィックの50％に到達するためにIPv6トラフィックを予測していますか？回答は、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は進行中で、計画、4の3は予定はありません
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を提供する予定ですか？進行中または計画を持つすべての人のために、答えは「今」と（それがマーケティング部門に依存していることを答えた1つのISPを除く）2013年の間でした。
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サーバー：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; 「検討6RD」
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言及）でした。また、言及した：携帯電話; DSLAM; （いくつかの特定のモデルを含む）、ルータ;トラフィック管理の箱。ロードバランサ。 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専用の任意の機器が100％か？ 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プレフィックスのどのような長さを有していたり、レジストリから必要ですか？ / 19 1、1月21日（数/ 32Sプラス）、1/22 1/30 3多重/ 32S 21/32、48分の3
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プレフィックスのどのような長さ（S）は、顧客に提供されていますか？ 15のISPは/ 48、/ 52、/ 56、/ 60または/ 64の複数を提供します。 2オファー/ 56だけ、8オファー/ 48のみ。二つの有線事業者はのみ/ 64を提供します。携帯電話事業者は、3GPPに従って/ 64を提供していますが、少なくとも一つは/ 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のプレフィックスは、CPEのに委任されていますか？ 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なし
* Network management tools: 13 yes, 4 partial, 1 plan, 11 no
*ネットワーク管理ツール：13はい、4部分、1つの計画、11なし
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")
*そうでない場合は、どのようにあなただけのサービスをIPv4-するIPv6のみの顧客を接続する予定ですか？ 7デュアルスタックに依存しています。 4予定はありません（1が言った、「彼らの問題」）
* 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
モバイルIPv6（またはニモモバイルネットワーク）のための任意の計画は、O？ 6はい、2不確か、22なし
Appendix B. Questionnaire
付録B.アンケート
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
IPサービスについてI.一般的な質問
1. Do you offer origin-only (stub, end-user) IP service, transit IP service, or both?
1.あなたは、原点専用（スタブ、エンドユーザー）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おおよその数（IPv4アドレスのブロック、Q2には含まれません）
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.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アドレス空間の不足に期待していますか？
II. Questions about requirements for IPv6 service
II。 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を必要としますか？
III. Questions about status and plans for IPv6 service
III。 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.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.どのタイプは、IPv6をサポートすることができませんか？
21. What length(s) of IPv6 prefix do you have or need from the registry?
21.あなたはIPv6プレフィックスのどのような長さを有していたり、レジストリから必要ですか？
22.1. Do any customers share their IPv6 prefix among multiple
hosts?
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プレフィックスは、CPEのに委任されていますか？ （マニュアル、PPPoEの、RADIUS、DHCPv6の、ステートレス自動設定/ RA、等...）
26. Are your HTTP services, including caching and webmail, dual-stack?
26.キャッシングとウェブメール、デュアルスタックを含め、あなたのHTTPサービスはありますか？
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のみのアプリケーションを実行するために期待していますか？
33.3. If not, how do you plan to connect IPv6-only customers to IPv4-only services?
33.3. そうでない場合、どのようにあなたは、IPv4のみのサービスにIPv6のみの顧客を接続する予定ですか？
33.4. If you offer IP multicast, will that need to be translated too?
33.4. あなたがIPマルチキャストを提供する場合は、その必要性はあまりにも翻訳されるのでしょうか？
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
メールアドレス：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
Sは、クロス江HU A技術の共同です。、L TDK UI KEビル、ラインRDで9番X。、シャン-DI情報産業基地、時間の愛-Dイアン地区、北京中華人民共和国
EMail: shengjiang@huawei.com
メールアドレス：shengjiang@huawei.com