[要約] RFC 6782は、Wireline Incremental IPv6の要約と目的を提供します。このRFCの目的は、IPv6の導入を容易にするために、既存のIPv4ネットワークに対してIPv6を段階的に導入する方法を提案することです。
Internet Engineering Task Force (IETF) V. Kuarsingh, Ed.
Request for Comments: 6782 Rogers Communications
Category: Informational L. Howard
ISSN: 2070-1721 Time Warner Cable
November 2012
Wireline Incremental IPv6
有線インクリメンタルIPv6
Abstract
概要
Operators worldwide are in various stages of preparing for or deploying IPv6 in their networks. These operators often face difficult challenges related to IPv6 introduction, along with those related to IPv4 run-out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6-dominant environment with long transition periods varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity, utilizing well-defined and commercially available IPv6 transition technologies.
世界中の通信事業者は、ネットワークでIPv6を準備または展開するさまざまな段階にあります。これらのオペレーターは、IPv4のランアウトに関連するものとともに、IPv6の導入に関連する困難な課題に直面することがよくあります。オペレーターは、IPv6接続の同時ニーズを満たし、IPv4アドレスの供給が停滞しているレガシーデバイスのIPv4接続のサポートを継続する必要があります。 IPv6への移行では、ほとんどのネットワークがIPv4のみの環境からIPv6が支配的な環境に移行し、長い移行期間は事業者によって異なります。このドキュメントは、明確に定義された市販のIPv6移行テクノロジを利用して、IPv4接続のレガシーニーズを満たすとともにIPv6を導入するという課題に直面している有線プロバイダーにフレームワークを提供するのに役立ちます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6782.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6782で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Operator Assumptions ............................................4
3. Reasons and Considerations for a Phased Approach ................5
3.1. Relevance of IPv6 and IPv4 .................................6
3.2. IPv4 Resource Challenges ...................................6
3.3. IPv6 Introduction and Operational Maturity .................7
3.4. Service Management .........................................8
3.5. Suboptimal Operation of Transition Technologies ............8
3.6. Future IPv6 Network ........................................9
4. IPv6 Transition Technology Analysis .............................9
4.1. Automatic Tunneling Using 6to4 and Teredo .................10
4.2. Carrier-Grade NAT (NAT444) ................................10
4.3. 6rd .......................................................11
4.4. Native Dual Stack .........................................11
4.5. DS-Lite ...................................................12
4.6. NAT64 .....................................................12
5. IPv6 Transition Phases .........................................13
5.1. Phase 0 - Foundation ......................................13
5.1.1. Phase 0 - Foundation: Training .....................13
5.1.2. Phase 0 - Foundation: System Capabilities ..........14
5.1.3. Phase 0 - Foundation: Routing ......................14
5.1.4. Phase 0 - Foundation: Network Policy and Security ..15
5.1.5. Phase 0 - Foundation: Transition Architecture ......15
5.1.6. Phase 0 - Foundation: Tools and Management .........16
5.2. Phase 1 - Tunneled IPv6 ...................................16
5.2.1. 6rd Deployment Considerations ......................17
5.3. Phase 2 - Native Dual Stack ...............................19
5.3.1. Native Dual Stack Deployment Considerations ........20
5.4. Intermediate Phase for CGN ................................20
5.4.1. CGN Deployment Considerations ......................22
5.5. Phase 3 - IPv6-Only .......................................23
5.5.1. DS-Lite ............................................23
5.5.2. DS-Lite Deployment Considerations ..................24
5.5.3. NAT64 Deployment Considerations ....................25
6. Security Considerations ........................................26
7. Acknowledgements ...............................................26
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................26
This document sets out to help wireline operators in planning their IPv6 deployments while ensuring continued support for IPv6-incapable consumer devices and applications. This document identifies which technologies can be used incrementally to transition from IPv4-only to an IPv6-dominant environment with support for Dual Stack operation. The end state or goal for most operators will be IPv6-only, but the path to this final state will depend heavily on the amount of legacy equipment resident in end networks and management of long-tail IPv4-only content. Although no single plan will work for all operators, options listed herein provide a baseline that can be included in many plans.
このドキュメントは、IPv6非対応のコンシューマデバイスおよびアプリケーションの継続的なサポートを確保しながら、有線オペレーターがIPv6の展開を計画するのに役立つことを目指しています。このドキュメントでは、IPv4のみからデュアルスタック操作をサポートするIPv6が支配的な環境に段階的に移行するために使用できるテクノロジーを特定します。ほとんどのオペレーターの最終状態または目標はIPv6のみですが、この最終状態への道は、エンドネットワークに常駐するレガシー機器の量とロングテールIPv4のみのコンテンツの管理に大きく依存します。単一のプランがすべてのオペレーターに対して機能するわけではありませんが、ここにリストされているオプションは、多くのプランに含めることができるベースラインを提供します。
This document is intended for wireline environments that include cable, DSL, and/or fiber as the access method to the end consumer. This document attempts to follow the principles laid out in [RFC6180], which provides guidance on using IPv6 transition mechanisms. This document will focus on technologies that enable and mature IPv6 within the operator's network, but it will also include a cursory view of IPv4 connectivity continuance. This document will focus on transition technologies that are readily available in off-the-shelf Customer Premises Equipment (CPE) devices and commercially available network equipment.
このドキュメントは、エンドユーザーへのアクセス方法としてケーブル、DSL、および/またはファイバーを含む有線環境を対象としています。このドキュメントは、IPv6移行メカニズムの使用に関するガイダンスを提供する、[RFC6180]で説明されている原則に従うことを試みます。このドキュメントでは、オペレーターのネットワーク内でIPv6を有効にして成熟させるテクノロジーに焦点を当てますが、IPv4接続の継続性についての概要も示します。このドキュメントでは、既製の顧客宅内機器（CPE）デバイスおよび市販のネットワーク機器ですぐに利用できる移行テクノロジに焦点を当てます。
For the purposes of this document, the authors assume the following:
このドキュメントの目的上、著者は次のことを前提としています。
- The operator is considering deploying IPv6 or is in the process of deploying IPv6.
- 事業者はIPv6の導入を検討しているか、IPv6の導入を進めています。
- The operator has a legacy IPv4 subscriber base that will continue to exist for a period of time.
- オペレーターには、一定期間存在し続けるレガシーIPv4サブスクライバーベースがあります。
- The operator will want to minimize the level of disruption to the existing and new subscribers.
- オペレーターは、既存および新規の加入者への混乱のレベルを最小限に抑えたいと思うでしょう。
- The operator may also want to minimize the number of technologies and functions that are needed to mediate any given set of subscribers' flows (overall preference for native IP flows).
- 事業者は、加入者のフローの特定のセット（ネイティブIPフローの全体的な優先順位）を仲介するために必要なテクノロジーと機能の数を最小限に抑えたい場合もあります。
- The operator is able to run Dual Stack in its own core network and is able to transition its own services to support IPv6.
- オペレーターは、独自のコアネットワークでデュアルスタックを実行でき、独自のサービスを移行してIPv6をサポートできます。
Based on these assumptions, an operator will want to utilize technologies that minimize the need to tunnel, translate, or mediate flows to help optimize traffic flow and lower the cost impacts of transition technologies. Transition technology selections should be made to mediate the non-dominant IP family flows and allow native routing (IPv4 and/or IPv6) to forward the dominant traffic whenever possible. This allows the operator to minimize the cost of IPv6 transition technologies by minimizing the transition technology deployment size.
これらの仮定に基づいて、オペレーターは、フローのトンネリング、変換、または仲介の必要性を最小限に抑えて、トラフィックフローを最適化し、移行テクノロジーのコストへの影響を軽減するテクノロジーを利用する必要があります。非支配的なIPファミリフローを仲介し、ネイティブルーティング（IPv4またはIPv6、あるいはその両方）が可能な限り支配的なトラフィックを転送できるように、移行テクノロジを選択する必要があります。これにより、オペレーターは移行テクノロジーの導入サイズを最小限に抑えることで、IPv6移行テクノロジーのコストを最小限に抑えることができます。
An operator may also choose to prefer more IPv6-focused models where the use of transition technologies is based on an effort to enable IPv6 at the base layer as soon as possible. Some operators may want to promote IPv6 early on in the deployment and have IPv6 traffic perform optimally from the outset. This desire would need to be weighed against the cost and support impacts of such a choice and the quality of experience offered to subscribers.
事業者は、移行テクノロジーの使用がベースレイヤーで可能な限り早くIPv6を有効にするための取り組みに基づいている、よりIPv6に焦点を当てたモデルを優先することも選択できます。一部の事業者は、導入の早い段階でIPv6を促進し、IPv6トラフィックを最初から最適に実行させることを望んでいる場合があります。この欲求は、そのような選択のコストとサポートへの影響、および加入者に提供されるエクスペリエンスの質と比較検討する必要があります。
When faced with the challenges described in the introduction, operators may want to consider a phased approach when adding IPv6 to an existing subscriber base. A phased approach allows the operator to add in IPv6 while not ignoring legacy IPv4 connection requirements. Some of the main challenges the operator will face include the following:
概要で説明した課題に直面した場合、オペレーターは、既存の加入者ベースにIPv6を追加するときに段階的なアプローチを検討する必要があります。段階的なアプローチにより、事業者はレガシーIPv4接続要件を無視せずにIPv6を追加できます。オペレーターが直面する主な課題には、以下のものがあります。
- IPv4 exhaustion may occur long before all traffic is able to be delivered over IPv6, necessitating IPv4 address sharing.
- IPv4の枯渇は、すべてのトラフィックをIPv6経由で配信できるようになるずっと前に発生する可能性があり、IPv4アドレスの共有が必要になります。
- IPv6 will pose operational challenges, since some of the software is quite new and has had short run time in large production environments and organizations are also not acclimatized to supporting IPv6 as a service.
- 一部のソフトウェアは非常に新しく、大規模な実稼働環境では実行時間が短いため、IPv6は運用上の課題を引き起こし、組織はサービスとしてのIPv6のサポートに慣れていません。
- Connectivity modes will move from IPv4-only to Dual Stack in the home, changing functional behaviors in the consumer network and increasing support requirements for the operator.
- 接続モードは、IPv4のみから家庭内のデュアルスタックに移行し、コンシューマーネットワークの機能的な動作が変化し、オペレーターのサポート要件が増加します。
- Although IPv6 support on CPEs is a newer phenomenon, there is a strong push by operators and the industry as a whole to enable IPv6 on devices. As demand grows, IPv6 enablement will no longer be optional but will be necessary on CPEs. Documents like [RFC6540] provide useful tools in the short term to help vendors and implementors understand what "IPv6 support" means.
- CPEでのIPv6のサポートは新しい現象ですが、デバイスでIPv6を有効にすることは、事業者および業界全体から強く求められています。需要が増えると、IPv6の有効化はオプションではなくなりますが、CPEでは必要になります。 [RFC6540]のようなドキュメントは、ベンダーや実装者が「IPv6サポート」の意味を理解するのに役立つ便利なツールを短期間に提供します。
These challenges will occur over a period of time, which means that the operator's plans need to address the ever-changing requirements of the network and subscriber demand. Although phases will be presented in this document, not all operators may need to enable each discrete phase. It is possible that characteristics in individual networks may allow certain operators to skip or jump to various phases.
これらの課題は一定期間にわたって発生します。つまり、事業者の計画は、絶えず変化するネットワークの要件と加入者の需要に対処する必要があります。このドキュメントではフェーズについて説明しますが、すべてのオペレーターが各個別フェーズを有効にする必要があるとは限りません。個々のネットワークの特性により、特定のオペレーターがさまざまなフェーズをスキップまたはジャンプできる場合があります。
The delivery of high-quality unencumbered Internet service should be the primary goal for operators. With the imminent exhaustion of IPv4, IPv6 will offer the highest quality of experience in the long term. Even though the operator may be focused on IPv6 delivery, it should be aware that both IPv4 and IPv6 will play a role in the Internet experience during transition. The Internet is made of many interconnecting systems, networks, hardware, software, and content sources -- all of which will support IPv6 at different rates.
高品質で邪魔にならないインターネットサービスの提供は、事業者の主要な目標である必要があります。 IPv4の枯渇が差し迫っているため、IPv6は長期的に最高品質のエクスペリエンスを提供します。事業者がIPv6配信に集中している場合でも、IPv4とIPv6の両方が移行中のインターネットエクスペリエンスに役割を果たすことに注意する必要があります。インターネットは、多くの相互接続システム、ネットワーク、ハードウェア、ソフトウェア、コンテンツソースで構成されています。これらはすべて、さまざまな速度でIPv6をサポートします。
Many subscribers use older operating systems and hardware that support IPv4-only operation. Internet subscribers don't buy IPv4 or IPv6 connections; they buy Internet connections, which demand the need to support both IPv4 and IPv6 for as long as the subscriber's home network demands such support. The operator may be able to leverage one or the other protocol to help bridge connectivity on the operator's network, but the home network will likely demand both IPv4 and IPv6 for some time.
多くの加入者は、IPv4のみの操作をサポートする古いオペレーティングシステムとハードウェアを使用しています。インターネット加入者はIPv4またはIPv6接続を購入しません。彼らはインターネット接続を購入し、加入者のホームネットワークがそのようなサポートを要求する限り、IPv4とIPv6の両方をサポートする必要性を要求します。事業者は、いずれかのプロトコルを利用して事業者のネットワーク上の接続をブリッジするのを助けることができるかもしれませんが、ホームネットワークはおそらくしばらくの間IPv4とIPv6の両方を要求するでしょう。
Since connectivity to IPv4-only endpoints and/or content will remain common, IPv4 resource challenges are of key concern to operators. The lack of new IPv4 addresses for additional devices means that meeting the growth in demand of IPv4 connections in some networks will require address sharing.
IPv4のみのエンドポイントやコンテンツへの接続は引き続き一般的であるため、IPv4リソースの課題は事業者にとって重要な関心事です。追加のデバイス用の新しいIPv4アドレスがないため、一部のネットワークでIPv4接続の需要の増加に対応するには、アドレス共有が必要になります。
Networks are growing at different rates, including those in emerging markets and established networks based on the proliferation of Internet-based services and devices. IPv4 address constraints will likely affect many, if not most, operators at some point, increasing the benefits of IPv6. IPv4 address exhaustion is a consideration when selecting technologies that rely on IPv4 to supply IPv6 services, such as 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures) [RFC5969]. Additionally, if native Dual Stack is considered by the operator, challenges related to IPv4 address exhaustion remain a concern.
ネットワークはさまざまな速度で成長しています。これには、新興市場やインターネットベースのサービスとデバイスの急増に基づく確立されたネットワークなどが含まれます。 IPv4アドレスの制約は、多くの場合ではないにしても多くのオペレーターに影響を及ぼし、IPv6の利点を増大させます。 IPv4アドレスの枯渇は、6rd（IPv4インフラストラクチャでのIPv6の迅速な展開）[RFC5969]など、IPv4に依存してIPv6サービスを提供するテクノロジを選択する場合の考慮事項です。さらに、オペレーターがネイティブデュアルスタックを検討する場合、IPv4アドレスの枯渇に関連する課題が依然として懸念されます。
Some operators may be able to reclaim small amounts of IPv4 addresses through addressing efficiencies in the network, although this will have few lasting benefits to the network and will not meet longer-term connectivity needs. Secondary markets for IPv4 addresses have also begun to arise, but it's not well understood how this will complement overall demand for Internet growth. Address transfers will also be subject to market prices and transfer rules governed by the Regional Registries.
一部の事業者は、ネットワークのアドレッシング効率によって少量のIPv4アドレスを取り戻すことができる場合がありますが、これはネットワークに永続的な利点がほとんどなく、長期の接続ニーズを満たしません。 IPv4アドレスのセカンダリマーケットも登場し始めていますが、これがインターネットの成長に対する全体的な需要をどのように補完するかはよくわかっていません。アドレスの転送は、地域のレジストリによって管理される市場価格および転送ルールの対象にもなります。
The lack of new global IPv4 address allocations will therefore force operators to support some form of IPv4 address sharing and may impact technological options for transition once the operator runs out of new IPv4 addresses for assignment.
したがって、新しいグローバルIPv4アドレス割り当てがないと、オペレーターは何らかの形式のIPv4アドレス共有をサポートする必要があり、オペレーターが割り当て用の新しいIPv4アドレスを使い果たすと、移行の技術オプションに影響を与える可能性があります。
The introduction of IPv6 will require new operational practices. The IPv4 environment we have today was built over many years and matured by experience. Although many of these experiences are transferable from IPv4 to IPv6, new experience and practices specific to IPv6 will be needed.
IPv6の導入には、新しい運用方法が必要です。今日のIPv4環境は長年にわたって構築され、経験によって成熟しています。これらの経験の多くはIPv4からIPv6に移行できますが、IPv6に固有の新しい経験と実践が必要になります。
Engineering and operational staff will need to develop experience with IPv6. Inexperience may lead to early IPv6 deployment instability, and operators should consider this when selecting technologies for initial transition. Operators may not want to subject their mature IPv4 service to a "new IPv6" path initially while it may be going through growing pains. Dual Stack Lite (DS-Lite) [RFC6333] and NAT64 [RFC6146] are both technologies that require IPv6 to support connectivity to IPv4 endpoints or content over an IPv6-only access network.
エンジニアリングおよび運用スタッフは、IPv6の経験を積む必要があります。経験不足は初期のIPv6展開の不安定性につながる可能性があり、オペレーターは初期移行のテクノロジーを選択するときにこれを考慮する必要があります。事業者は、成熟するIPv4サービスを、初期段階で「新しいIPv6」への移行を望まないかもしれませんが、それはますます困難になっているかもしれません。デュアルスタックライト（DS-Lite）[RFC6333]とNAT64 [RFC6146]はどちらも、IPv6のみのアクセスネットワークを介したIPv4エンドポイントまたはコンテンツへの接続をサポートするためにIPv6を必要とするテクノロジーです。
Further, some of these transition technologies are new and require refinement within running code. Deployment experience is required to expose bugs and stabilize software in production environments. Many supporting systems are also under development and have newly developed IPv6 functionality, including vendor implementations of DHCPv6, management tools, monitoring systems, diagnostic systems, and logging, along with other elements.
さらに、これらの移行テクノロジーのいくつかは新しく、実行中のコード内での改良が必要です。運用環境でバグを公開し、ソフトウェアを安定させるには、導入経験が必要です。 DHCPv6のベンダー実装、管理ツール、監視システム、診断システム、ロギング、その他の要素など、多くのサポートシステムも開発中で、IPv6機能が新しく開発されています。
Although the base technological capabilities exist to enable and run IPv6 in most environments, organizational experience is low. Until such time as each key technical member of an operator's organization can identify IPv6 and can understand its relevance to the IP service offering, how it operates, and how to troubleshoot it, the deployment needs to mature and may be subject to events that impact subscribers. This fact should not incline operators to delay their IPv6 deployment but should drive them to deploy IPv6 sooner, to gain much-needed experience before IPv6 is the only viable way to connect new hosts to the network.
ほとんどの環境でIPv6を有効にして実行するための基本的な技術機能は存在しますが、組織での経験は少ないです。オペレーターの組織の主要な技術メンバーがIPv6を識別し、IPサービスオファリングとの関連性、運用方法、およびトラブルシューティング方法を理解できるようになるまでは、展開が成熟している必要があり、サブスクライバーに影響するイベントの影響を受ける可能性があります。 。この事実は、IPv6の展開を遅らせるようにオペレーターに傾けるべきではありませんが、IPv6がネットワークに新しいホストを接続する唯一の実行可能な方法になる前に、待望のエクスペリエンスを得るには、IPv6をより早く展開するようにドライバーを推進する必要があります。
It should also be noted that although many transition technologies may be new, and some code related to access environments may be new, there is a large segment of the networking fabric that has had IPv6 available for a long period of time and has had extended exposure in production. Operators may use this to their advantage by first enabling IPv6 in the core network and then working outward towards the subscriber edge.
多くの移行テクノロジーが新しい可能性があり、アクセス環境に関連する一部のコードが新しい可能性がありますが、長期間にわたってIPv6を使用可能にし、長期間にわたって露出しているネットワーキングファブリックの大部分があることに注意してください。生産中。オペレーターは、最初にコアネットワークでIPv6を有効にしてから、加入者エッジに向かって外側に向かって作業することで、これを活用できます。
Services are managed within most networks and are often based on the gleaning and monitoring of IPv4 addresses assigned to endpoints. Operators will need to address such management tools, troubleshooting methods, and storage facilities (such as databases) to deal with not only new address types containing 128-bit IPv6 addresses [RFC2460] but often both IPv4 and IPv6 at the same time. Examination of address types, and recording delegated prefixes along with single address assignments, will likely require additional development.
サービスはほとんどのネットワーク内で管理され、多くの場合、エンドポイントに割り当てられたIPv4アドレスの収集と監視に基づいています。オペレーターは、128ビットIPv6アドレス[RFC2460]を含む新しいアドレスタイプだけでなく、IPv4とIPv6の両方を同時に扱うために、このような管理ツール、トラブルシューティング方法、およびストレージ機能（データベースなど）に対処する必要があります。アドレスの種類の調査、および委任されたプレフィックスと単一のアドレス割り当ての記録には、追加の開発が必要になる可能性があります。
With any Dual Stack service -- whether native, 6rd-based, DS-Lite, NAT64, or some other service -- two address families may need to be managed simultaneously to help provide the full Internet experience. This would indicate that IPv6 management is not just a simple add-in but needs to be well integrated into the service management infrastructure. In the early transition phases, it's quite likely that many systems will be missed, and that IPv6 services will go unmonitored and impairments will go undetected.
デュアルスタックサービス（ネイティブ、6rdベース、DS-Lite、NAT64、その他のサービス）を使用する場合、完全なインターネットエクスペリエンスを提供するには、2つのアドレスファミリを同時に管理する必要がある場合があります。これは、IPv6管理が単なるアドインではなく、サービス管理インフラストラクチャに適切に統合される必要があることを示しています。初期の移行フェーズでは、多くのシステムが失われ、IPv6サービスが監視されなくなり、障害が検出されなくなる可能性が高くなります。
These issues may be worthy of consideration when selecting technologies that require IPv6 as the base protocol to deliver IPv4 connectivity. Instability of the IPv6 service in such a case would impact IPv4 services.
これらの問題は、IPv4接続を提供するための基本プロトコルとしてIPv6を必要とするテクノロジーを選択する際に検討する価値があります。このような場合にIPv6サービスが不安定になると、IPv4サービスに影響が出ます。
Native delivery of IPv4 and IPv6 provides a solid foundation for delivery of Internet services to subscribers, since native IP paths are well understood and networks are often optimized to send such traffic efficiently. Transition technologies, however, may alter the normal path of traffic or reduce the path MTU, removing many network efficiencies built for native IP flows. Tunneling and translation devices may not be located on the most optimal path in line with the natural traffic flow (based on route computation) and therefore may increase latency. These paths may also introduce additional points of failure.
IPv4およびIPv6のネイティブ配信は、ネイティブIPパスがよく理解されており、ネットワークがそのようなトラフィックを効率的に送信するように最適化されることが多いため、加入者へのインターネットサービス配信の強固な基盤を提供します。ただし、移行テクノロジーは、トラフィックの通常のパスを変更したり、パスのMTUを減らしたりして、ネイティブIPフロー用に構築された多くのネットワーク効率を排除する場合があります。トンネリングおよび変換デバイスは、（ルート計算に基づいて）自然なトラフィックフローに沿った最適なパス上に配置されていない可能性があり、レイテンシが増加する可能性があります。これらのパスは、追加の障害点をもたらす可能性もあります。
Generally, the operator will want to deliver native IPv6 as soon as possible and utilize transition technologies only when required. Transition technologies may be used to provide continued access to IPv4 via tunneling and/or translation or may be used to deliver IPv6 connectivity. The delivery of Internet or internal services should be considered by the operator, since supplying connections using a transition technology will reduce overall performance for the subscriber.
一般的に、事業者はネイティブIPv6をできるだけ早く提供し、必要な場合にのみ移行テクノロジーを利用することを望みます。移行テクノロジーは、トンネリングや変換を介してIPv4への継続的なアクセスを提供するために使用することも、IPv6接続を提供するために使用することもできます。移行テクノロジーを使用して接続を提供すると、加入者の全体的なパフォーマンスが低下するため、インターネットまたは内部サービスの配信は、事業者が検討する必要があります。
When choosing between various transition technologies, operators should consider the benefits and drawbacks of each option. Some technologies, like Carrier-Grade NAT (CGN)/NAT444, utilize many existing addressing and management practices. Other options, such as DS-Lite and NAT64, remove the IPv4 addressing requirement to the subscriber premises device but require IPv6 to be operational and well supported.
さまざまな移行テクノロジーから選択する場合、事業者は各オプションの利点と欠点を考慮する必要があります。 Carrier-Grade NAT（CGN）/ NAT444などの一部のテクノロジーは、既存の多くのアドレッシングおよび管理手法を利用しています。 DS-LiteやNAT64などの他のオプションでは、加入者構内デバイスに対するIPv4アドレッシング要件が削除されますが、IPv6が動作可能で十分にサポートされている必要があります。
An operator should also be aware that longer-term plans may include IPv6-only operation in all or much of the network. The IPv6-only operation may be complemented by technologies such as NAT64 for long-tail IPv4 content reach. This longer-term view may be distant to some but should be considered when planning out networks, addressing, and services. The needs and costs of maintaining two IP stacks will eventually become burdensome, and simplification will be desirable. Operators should plan for this state and not make IPv6 inherently dependent on IPv4, as this would unnecessarily constrain the network.
事業者はまた、長期計画には、ネットワークのすべてまたは大部分でIPv6のみの運用が含まれる可能性があることを認識しておく必要があります。 IPv6のみの操作は、ロングテールIPv4コンテンツに到達するためのNAT64などのテクノロジーによって補完される場合があります。この長期的な見方は、一部の人にとっては遠いかもしれませんが、ネットワーク、アドレス指定、およびサービスを計画するときに考慮する必要があります。 2つのIPスタックを維持するためのニーズとコストは、最終的に負担となり、簡素化が望まれます。オペレーターはこの状態を計画し、IPv6を本質的にIPv4に依存させないでください。これは、ネットワークを不必要に制約するためです。
Other design considerations and guidelines for running an IPv6 network should also be considered by the operator. Guidance on designing an IPv6 network can be found in [IPv6-DESIGN] and [IPv6-ICP-ASP-GUIDANCE].
オペレーターは、IPv6ネットワークを実行するためのその他の設計上の考慮事項とガイドラインも検討する必要があります。 IPv6ネットワークの設計に関するガイダンスは、[IPv6-DESIGN]および[IPv6-ICP-ASP-GUIDANCE]にあります。
Operators should understand the main transition technologies for IPv6 deployment and IPv4 run-out. This document provides a brief description of some of the mainstream and commercially available options. This analysis is focused on the applicability of technologies to deliver residential services and less focused on commercial access, wireless, or infrastructure support.
オペレーターは、IPv6の展開とIPv4のランアウトの主な移行テクノロジーを理解する必要があります。このドキュメントでは、主流で市販されているオプションのいくつかについて簡単に説明します。この分析は、住宅用サービスを提供するテクノロジーの適用性に焦点を当てており、商用アクセス、ワイヤレス、インフラストラクチャのサポートにはあまり焦点を当てていません。
This document focuses on those technologies that are commercially available and in deployment.
このドキュメントでは、市販されており展開中のテクノロジーに焦点を当てています。
Even when operators may not be actively deploying IPv6, automatic mechanisms exist on subscriber operating systems and CPE hardware. Such technologies include 6to4 [RFC3056], which is most commonly used with anycast relays [RFC3068]. Teredo [RFC4380] is also used widely by many Internet hosts.
オペレーターがIPv6を積極的に展開していない場合でも、サブスクライバーのオペレーティングシステムとCPEハードウェアには自動メカニズムが存在します。そのようなテクノロジーには、エニーキャストリレー[RFC3068]で最も一般的に使用される6to4 [RFC3056]が含まれます。 Teredo [RFC4380]は、多くのインターネットホストでも広く使用されています。
Documents such as [RFC6343] have been written to help operators understand observed problems with 6to4 deployments and provide guidelines on how to improve their performance. An operator may want to provide local relays for 6to4 and/or Teredo to help improve the protocol's performance for ambient traffic utilizing these IPv6 connectivity methods. Experiences such as those described in [COMCAST-IPv6-EXPERIENCES] show that local relays have proved beneficial to 6to4 protocol performance.
[RFC6343]などのドキュメントは、オペレーターが6to4配備で観察された問題を理解し、パフォーマンスを改善する方法に関するガイドラインを提供するために作成されています。オペレーターは、6to4またはTeredo、あるいはその両方にローカルリレーを提供して、これらのIPv6接続方法を利用して、環境トラフィックのプロトコルのパフォーマンスを向上させることができます。 [COMCAST-IPv6-EXPERIENCES]で説明されているような経験は、ローカルリレーが6to4プロトコルのパフォーマンスに有益であることが証明されていることを示しています。
Operators should also be aware of breakage cases for 6to4 if non-[RFC1918] addresses are used within CGN/NAT444 zones. Many off-the-shelf CPEs and operating systems may turn on 6to4 without a valid return path to the originating (local) host. This particular use case can occur if any space other than [RFC1918] is used, including Shared Address Space [RFC6598] or space registered to another organization (squat space). The operator can use 6to4 Provider Managed Tunnels (6to4-PMT) [RFC6732] or attempt to block 6to4 operation entirely by blocking the anycast ranges associated with [RFC3068].
[RFC1918]以外のアドレスがCGN / NAT444ゾーン内で使用されている場合、オペレーターは6to4の破損ケースにも注意する必要があります。多くの既製のCPEとオペレーティングシステムは、元の（ローカル）ホストへの有効なリターンパスなしで6to4をオンにする場合があります。この特定の使用例は、共有アドレススペース[RFC6598]や他の組織に登録されているスペース（スクワットスペース）など、[RFC1918]以外のスペースが使用されている場合に発生する可能性があります。オペレーターは、6to4プロバイダー管理トンネル（6to4-PMT）[RFC6732]を使用するか、[RFC3068]に関連付けられたエニーキャスト範囲をブロックすることにより、6to4操作を完全にブロックすることができます。
Carrier-Grade NAT (CGN), specifically as deployed in a NAT444 scenario [CGN-REQS], may prove beneficial for those operators who offer Dual Stack services to subscriber endpoints once they exhaust their pools of IPv4 addresses. CGNs, and address sharing overall, are known to cause certain challenges for the IPv4 service [RFC6269] [NAT444-IMPACTS] but may be necessary, depending on how an operator has chosen to deal with IPv6 transition and legacy IPv4 connectivity requirements.
特にNAT444シナリオ[CGN-REQS]で展開されるキャリアグレードNAT（CGN）は、IPv4アドレスのプールを使い果たすと、サブスクライバーエンドポイントにデュアルスタックサービスを提供するオペレーターにとって有益になる場合があります。 CGNとアドレス共有全体は、IPv4サービス[RFC6269] [NAT444-IMPACTS]に特定の課題を引き起こすことが知られていますが、オペレーターがIPv6移行とレガシーIPv4接続要件への対応を選択した方法によっては、必要になる場合があります。
In a network where IPv4 address availability is low, CGN/NAT444 may provide continued access to IPv4 endpoints. Some of the advantages of using CGN/NAT444 include similarities in provisioning and activation models. IPv4 hosts in a CGN/NAT444 deployment will likely inherit the same addressing and management procedures as legacy IPv4 globally addressed hosts (i.e., DHCPv4, DNS (v4), TFTP, TR-069, etc.).
IPv4アドレスの可用性が低いネットワークでは、CGN / NAT444がIPv4エンドポイントへの継続的なアクセスを提供する場合があります。 CGN / NAT444を使用する利点の一部には、プロビジョニングモデルとアクティベーションモデルの類似点があります。 CGN / NAT444展開のIPv4ホストは、従来のIPv4グローバルアドレス指定ホストと同じアドレッシングおよび管理手順を継承する可能性があります（DHCPv4、DNS（v4）、TFTP、TR-069など）。
6rd [RFC5969] provides a way of offering IPv6 connectivity to subscriber endpoints when native IPv6 addressing on the access network is not yet possible. 6rd provides tunneled connectivity for IPv6 over the existing IPv4 path. As the access edge is upgraded and subscriber premises equipment is replaced, 6rd can be replaced by native IPv6 connectivity. 6rd can be delivered on top of a CGN/ NAT444 deployment, but this would cause all traffic to be subject to some type of transition technology.
6rd [RFC5969]は、アクセスネットワークでネイティブIPv6アドレッシングがまだ可能でない場合に、加入者エンドポイントにIPv6接続を提供する方法を提供します。 6rdは、既存のIPv4パスを介したIPv6のトンネル接続を提供します。アクセスエッジがアップグレードされ、加入者構内機器が交換されると、6rdはネイティブIPv6接続に置き換えることができます。 6rdはCGN / NAT444展開の上に配信できますが、これによりすべてのトラフィックが何らかの種類の移行テクノロジの影響を受ける可能性があります。
6rd may also be advantageous during the early transition period while IPv6 traffic volumes are low. During this period, the operator can gain experience with IPv6 in the core network and improve the operator's peering framework to match those of the IPv4 service. 6rd scales by adding relays to the operator's network. Another advantage of 6rd is that the operator does not need a DHCPv6 address assignment infrastructure and does not need to support IPv6 routing to the CPE to support a delegated prefix (as it's derived from the IPv4 address and other configuration parameters).
IPv6のトラフィック量が少ない間、移行期間の初期には6位が有利になることもあります。この期間中、オペレーターはコアネットワークでIPv6の経験を積み、IPv4サービスのピアリングフレームワークと一致するようにオペレーターのピアリングフレームワークを改善できます。オペレーターのネットワークにリレーを追加することにより、6番目のスケール。 6rdのもう1つの利点は、オペレーターがDHCPv6アドレス割り当てインフラストラクチャを必要とせず、委任されたプレフィックスをサポートするためにCPEへのIPv6ルーティングをサポートする必要がないことです（IPv4アドレスと他の構成パラメーターから派生するため）。
Client support is required for 6rd operation and may not be available on deployed hardware. 6rd deployments may require the subscriber or operator to replace the CPE. 6rd will also require parameter configuration that can be powered by the operator through DHCPv4, manually provisioned on the CPE, or automatically provisioned through some other means. Manual provisioning would likely limit deployment scale.
6番目の操作にはクライアントサポートが必要であり、展開されたハードウェアでは利用できない場合があります。 6番目の展開では、サブスクライバーまたはオペレーターがCPEを交換する必要があります。 6rdには、DHCPv4を介してオペレーターが電力を供給したり、CPEで手動でプロビジョニングしたり、他の方法で自動的にプロビジョニングしたりできるパラメーター構成も必要です。手動プロビジョニングでは、展開の規模が制限される可能性があります。
Native Dual Stack is often referred to as the "gold standard" of IPv6 and IPv4 delivery. It is a method of service delivery that is already used in many existing IPv6 deployments. Native Dual Stack does, however, require that native IPv6 be delivered through the access network to the subscriber premises. This technology option is desirable in many cases and can be used immediately if the access network and subscriber premises equipment support native IPv6.
ネイティブデュアルスタックは、IPv6およびIPv4配信の「ゴールドスタンダード」と呼ばれることがよくあります。これは、多くの既存のIPv6展開ですでに使用されているサービス配信の方法です。ただし、ネイティブデュアルスタックでは、ネイティブIPv6がアクセスネットワークを通じて加入者構内に配信される必要があります。このテクノロジーオプションは多くの場合に望ましいものであり、アクセスネットワークと加入者構内機器がネイティブIPv6をサポートしている場合はすぐに使用できます。
An operator who runs out of IPv4 addresses to assign to subscribers will not be able to provide traditional native Dual Stack connectivity for new subscribers. In Dual Stack deployments where sufficient IPv4 addresses are not available, CGN/NAT444 can be used on the IPv4 path.
IPv4アドレスを使い果たして加入者に割り当てるオペレーターは、新しい加入者に従来のネイティブデュアルスタック接続を提供できません。十分なIPv4アドレスを使用できないデュアルスタック配置では、CGN / NAT444をIPv4パスで使用できます。
Delivering native Dual Stack would require the operator's core and access networks to support IPv6. Other systems, like DHCP, DNS, and diagnostic/management facilities, need to be upgraded to support IPv6 as well. The upgrade of such systems may often be non-trivial and costly.
ネイティブデュアルスタックを提供するには、オペレーターのコアネットワークとアクセスネットワークがIPv6をサポートする必要があります。 DHCP、DNS、診断/管理機能などの他のシステムも、IPv6をサポートするようにアップグレードする必要があります。このようなシステムのアップグレードは、多くの場合、簡単でコストがかかる場合があります。
DS-Lite [RFC6333] is based on a native IPv6 connection model where IPv4 services are supported. DS-Lite provides tunneled connectivity for IPv4 over the IPv6 path between the subscriber's network device and a provider-managed gateway (Address Family Transition Router (AFTR)).
DS-Lite [RFC6333]は、IPv4サービスがサポートされるネイティブIPv6接続モデルに基づいています。 DS-Liteは、加入者のネットワークデバイスとプロバイダーが管理するゲートウェイ（Address Family Transition Router（AFTR））間のIPv6パスを介したIPv4のトンネル接続を提供します。
DS-Lite can only be used where there is a native IPv6 connection between the AFTR and the CPE. This may mean that the technology's use may not be viable during early transition if the core or access network lacks IPv6 support. During the early transition period, a significant amount of content and services may by IPv4-only. Operators may be sensitive to this and may not want the newer IPv6 path to be the only bridge to IPv4 at that time, given the potential impact. The operator may also want to make sure that most of its internal services and a significant amount of external content are available over IPv6 before deploying DS-Lite. The availability of services on IPv6 would help lower the demand on the AFTRs.
DS-Liteは、AFTRとCPEの間にネイティブIPv6接続がある場合にのみ使用できます。これは、コアまたはアクセスネットワークがIPv6サポートを欠いている場合、テクノロジーの使用が移行の初期段階で実行できない可能性があることを意味します。移行の初期段階では、かなりの量のコンテンツとサービスがIPv4のみで提供される可能性があります。オペレーターはこれに敏感であり、潜在的な影響を考えると、その時点で新しいIPv6パスがIPv4への唯一のブリッジになることを望まない場合があります。オペレーターは、DS-Liteを導入する前に、その内部サービスの大部分とかなりの量の外部コンテンツがIPv6を介して利用可能であることを確認することもできます。 IPv6でのサービスの可用性は、AFTRの需要を下げるのに役立ちます。
By sharing IPv4 addresses among multiple endpoints, like CGN/NAT444, DS-Lite can facilitate continued support of legacy IPv4 services even after IPv4 address run-out. There are some functional considerations to take into account with DS-Lite, such as those described in [NAT444-IMPACTS] and in [DSLITE-DEPLOYMENT].
CGN / NAT444などの複数のエンドポイント間でIPv4アドレスを共有することにより、DS-Liteは、IPv4アドレスが不足した後でも、レガシーIPv4サービスの継続的なサポートを促進できます。 [NAT444-IMPACTS]や[DSLITE-DEPLOYMENT]で説明されているような、DS-Liteで考慮すべき機能上の考慮事項がいくつかあります。
DS-Lite requires client support on the CPE to function. The ability to utilize DS-Lite will be dependent on the operator providing DS-Lite-capable CPEs or retail availability of the supported client for subscriber-acquired endpoints.
DS-Liteが機能するには、CPEでのクライアントサポートが必要です。 DS-Liteを利用できるかどうかは、DS-Lite対応のCPEを提供する事業者、またはサブスクライバーが取得したエンドポイントでサポートされるクライアントの小売りの可用性に依存します。
NAT64 [RFC6146] provides the ability to connect IPv6-only connected clients and hosts to IPv4 servers without any tunneling. NAT64 requires that the host and home network support IPv6-only modes of operation. Home networks do not commonly contain equipment that is 100% IPv6-capable. It is also not anticipated that common home networks will be ready for IPv6-only operation for a number of years. However, IPv6-only networking can be deployed by early adopters or highly controlled networks [RFC6586].
NAT64 [RFC6146]は、IPv6のみで接続されたクライアントとホストをトンネリングなしでIPv4サーバーに接続する機能を提供します。 NAT64では、ホストおよびホームネットワークがIPv6のみの動作モードをサポートする必要があります。通常、ホームネットワークには、100％IPv6対応の機器は含まれていません。また、一般的なホームネットワークがIPv6のみの運用に対応できるようになるとは、何年も予想されていません。ただし、IPv6のみのネットワーキングは、アーリーアダプターまたは高度に制御されたネットワーク[RFC6586]によって展開できます。
Viability of NAT64 will increase in wireline networks as consumer equipment is replaced by IPv6-capable versions. There are incentives for operators to move to IPv6-only operation, when feasible; these include the simplicity of a single-stack access network.
消費者向け機器がIPv6対応バージョンに置き換えられるため、NAT64の実行可能性は有線ネットワークで増加します。可能であれば、オペレーターがIPv6のみの運用に移行するインセンティブがあります。これには、シングルスタックアクセスネットワークのシンプルさが含まれます。
The phases described in this document are not provided as a rigid set of steps but are considered a guideline that should be analyzed by operators planning their IPv6 transition. Operators may choose to skip steps based on technological capabilities within their specific networks (residential/corporate, fixed/mobile), their business development perspectives (which may affect the pace of migration towards full IPv6), or a combination thereof.
このドキュメントで説明されているフェーズは、厳密な手順のセットとして提供されていませんが、IPv6移行を計画している事業者が分析する必要があるガイドラインと見なされています。事業者は、特定のネットワーク（住宅/企業、固定/モバイル）内の技術的能力、ビジネス開発の視点（完全なIPv6への移行のペースに影響を与える可能性がある）、またはそれらの組み合わせに基づいて、手順をスキップすることを選択できます。
The phases are based on the expectation that IPv6 traffic volume may initially be low, and operator staff will gain experience with IPv6 over time. As traffic volumes of IPv6 increase, IPv4 traffic volumes will decline (in percentage relative to IPv6), until IPv6 is the dominant address family used. Operators may want to keep the traffic flow for the dominant traffic class (IPv4 vs. IPv6) native to help manage costs related to transition technologies. The cost of using multiple technologies in succession to optimize each stage of the transition should also be compared against the cost of changing and upgrading subscriber connections.
フェーズは、IPv6トラフィック量が最初は少ない可能性があるという予想に基づいており、オペレータースタッフはIPv6の使用経験を時間をかけて得るようになります。 IPv6のトラフィック量が増加すると、IPv6が使用される主要なアドレスファミリになるまで、IPv4トラフィック量は減少します（IPv6に対するパーセンテージ）。事業者は、主要なトラフィッククラス（IPv4対IPv6）のトラフィックフローをネイティブのままにして、移行テクノロジに関連するコストの管理を支援する場合があります。移行の各段階を最適化するために連続して複数のテクノロジーを使用するコストは、サブスクライバー接続の変更およびアップグレードのコストと比較する必要もあります。
Additional guidance and information on utilizing IPv6 transition mechanisms can be found in [RFC6180]. Also, guidance on incremental CGN for IPv6 transition can be found in [RFC6264].
IPv6移行メカニズムの利用に関する追加のガイダンスと情報は、[RFC6180]にあります。また、IPv6移行の増分CGNに関するガイダンスは、[RFC6264]にあります。
Training is one of the most important steps in preparing an organization to support IPv6. Most people have little experience with IPv6, and many do not even have a solid grounding in IPv4. The implementation of IPv6 will likely produce many challenges due to immature code on hardware, and the evolution of many applications and systems to support IPv6. To properly deal with these impending or current challenges, organizations must train their staff on IPv6.
トレーニングは、IPv6をサポートする組織を準備する上で最も重要なステップの1つです。ほとんどの人はIPv6の経験がほとんどなく、多くの人はIPv4の基礎さえ持っていません。 IPv6の実装は、ハードウェアの未成熟なコードと、IPv6をサポートする多くのアプリケーションとシステムの進化により、多くの課題を生み出す可能性があります。これらの差し迫った課題または現在の課題に適切に対処するには、組織はIPv6についてスタッフをトレーニングする必要があります。
Training should also be provided within reasonable timelines from the actual IPv6 deployment. This means the operator needs to plan in advance as it trains the various parts of its organization. New technology and engineering staff often receive little training because of their depth of knowledge but must at least be provided opportunities to read documentation, architectural white papers, and RFCs. Operations personnel who support the network and other systems need to be trained closer to the deployment timeframes so that they immediately use their newfound knowledge before forgetting.
トレーニングは、実際のIPv6展開から妥当なタイムライン内で提供する必要もあります。つまり、組織のさまざまな部分をトレーニングするため、オペレーターは事前に計画を立てる必要があります。新しいテクノロジーとエンジニアリングのスタッフは、知識が深いため、ほとんどトレーニングを受けませんが、少なくともドキュメント、アーキテクチャホワイトペーパー、RFCを読む機会を提供する必要があります。ネットワークやその他のシステムをサポートする運用担当者は、忘れないうちにすぐに新しい知識を使用できるように、展開の時間枠に近いトレーニングを受ける必要があります。
Subscriber support staff would require much more basic but large-scale training, since many organizations have massive call centers to support the subscriber base. Tailored training will also be required for marketing and sales staff to help them understand IPv6 and build it into the product development and sales process.
多くの組織が加入者ベースをサポートする大規模なコールセンターを持っているので、加入者サポートスタッフははるかに基本的ですが大規模なトレーニングを必要とします。マーケティングおよび販売スタッフがIPv6を理解し、製品開発および販売プロセスに組み込むのを支援するために、カスタマイズされたトレーニングも必要になります。
An important component with any IPv6 network architecture and implementation is the assessment of the hardware and operating capabilities of the deployed equipment (and software). The assessment needs to be conducted irrespective of how the operator plans to transition its network. The capabilities of the install base will, however, impact what technologies and modes of operation may be supported and therefore what technologies can be considered for the transition. If some systems do not meet the needs of the operator's IPv6 deployment and/or transition plan, the operator may need to plan for replacement and/or upgrade of those systems.
IPv6ネットワークアーキテクチャと実装の重要なコンポーネントは、展開された機器（およびソフトウェア）のハードウェアと動作機能の評価です。評価は、事業者がネットワークの移行をどのように計画しているかに関係なく行う必要があります。ただし、インストールベースの機能は、サポートされる可能性のあるテクノロジと動作モードに影響を与えるため、移行のためにどのテクノロジを検討できますか。一部のシステムが事業者のIPv6導入および/または移行計画のニーズを満たさない場合、事業者はそれらのシステムの交換および/またはアップグレードを計画する必要がある場合があります。
The network infrastructure will need to be in place to support IPv6. This includes the routed infrastructure, along with addressing principles, routing principles, peering policy, and related network functions. Since IPv6 is quite different from IPv4 in several ways, including the number of addresses that are made available, careful attention to a scalable and manageable architecture is needed. One such change is the notion of a delegated prefix, which deviates from the common single-address phenomenon in IPv4-only deployments. Deploying prefixes per CPE can load the routing tables and require a routing protocol or route gleaning to manage connectivity to the subscriber's network. Delegating prefixes can be of specific importance in access network environments where downstream subscribers often move between access nodes, raising the concern of frequent renumbering and/or managing movement of routed prefixes within the network (common in cable-based networks).
IPv6をサポートするには、ネットワークインフラストラクチャを配置する必要があります。これには、アドレス指定の原則、ルーティングの原則、ピアリングポリシー、および関連するネットワーク機能とともに、ルーティングされたインフラストラクチャが含まれます。 IPv6は、利用可能になるアドレスの数など、いくつかの点でIPv4とはかなり異なるため、スケーラブルで管理しやすいアーキテクチャに注意する必要があります。そのような変更の1つは、委任されたプレフィックスの概念です。これは、IPv4のみの展開における一般的な単一アドレス現象から逸脱しています。 CPEごとにプレフィックスを展開すると、ルーティングテーブルを読み込むことができ、サブスクライバーのネットワークへの接続を管理するためにルーティングプロトコルまたはルートグリーニングが必要になります。プレフィックスの委任は、ダウンストリームサブスクライバーがアクセスノード間を頻繁に移動するアクセスネットワーク環境で特に重要になる場合があり、ネットワーク内でルーティングされたプレフィックスの頻繁な再番号付けや移動の管理が懸念されます（ケーブルベースのネットワークでは一般的です）。
Many, but not all, security policies will map easily from IPv4 to IPv6. Some new policies may be required for issues specific to IPv6 operation. This document does not highlight these specific issues but raises the awareness that they are to be taken into consideration and should be addressed when delivering IPv6 services. Other IETF documents, such as [RFC4942], [RFC6092], and [RFC6169], are excellent resources.
すべてではありませんが、多くのセキュリティポリシーがIPv4からIPv6に簡単にマッピングされます。 IPv6運用に固有の問題には、いくつかの新しいポリシーが必要になる場合があります。このドキュメントでは、これらの特定の問題を強調していませんが、それらは考慮に入れられるべきであり、IPv6サービスを提供するときに対処する必要があることを認識させます。 [RFC4942]、[RFC6092]、[RFC6169]などの他のIETFドキュメントは優れたリソースです。
Operators should plan out their transition architecture in advance (with room for flexibility) to help optimize how they will build out and scale their networks. Should operators consider multiple technologies, like CGN/NAT444, DS-Lite, NAT64, and 6rd, they may want to plan out where network resident equipment may be located and potentially choose locations that can be used for all functional roles (i.e., placement of a NAT44 translator, AFTR, NAT64 gateway, and 6rd relays). Although these functions are not inherently connected, additional management, diagnostic, and monitoring functions can be deployed alongside the transition hardware without the need to distribute these functions to an excessive or divergent number of locations.
事業者は、ネットワークをどのように構築および拡張するかを最適化するために、事前に（柔軟性の余地がある）移行アーキテクチャを計画する必要があります。オペレーターがCGN / NAT444、DS-Lite、NAT64、6rdなどの複数のテクノロジーを検討する場合、ネットワーク常駐機器の配置場所を計画し、すべての機能的な役割（つまり、 NAT44トランスレータ、AFTR、NAT64ゲートウェイ、6番目のリレー）。これらの機能は本質的に接続されていませんが、追加の管理機能、診断機能、および監視機能を移行ハードウェアと一緒に展開できます。これらの機能を過度または異なる場所に分散させる必要はありません。
This approach may also prove beneficial if traffic patterns change rapidly in the future, as operators may need to evolve their transition infrastructure faster than originally anticipated. One such example may be the movement from a CGN/NAT44 model (Dual Stack) to DS-Lite. Since both traffic sets require a translation function (NAT44), synchronized pool management, routing, and management system positioning can allow rapid movement (the technological means to re-provision the subscriber notwithstanding).
オペレーターが当初想定していたよりも早く移行インフラストラクチャを進化させる必要がある可能性があるため、このアプローチは、トラフィックパターンが将来急速に変化する場合にも有益であると証明できます。そのような例の1つは、CGN / NAT44モデル（デュアルスタック）からDS-Liteへの移行です。両方のトラフィックセットに変換機能（NAT44）が必要なため、同期されたプール管理、ルーティング、および管理システムの配置により、迅速な移動が可能になります（それにもかかわらず、加入者を再プロビジョニングする技術的手段）。
Operators should inform their vendors of what technologies they plan to support over the course of the transition to make sure the equipment is suited to support those modes of operation. This is important for both network gear and subscriber premises equipment.
オペレーターは、移行の過程でベンダーがサポートする予定のテクノロジーをベンダーに通知し、機器がこれらの操作モードをサポートするのに適していることを確認する必要があります。これは、ネットワーク機器と加入者構内機器の両方にとって重要です。
Operators should also plan their overall strategy to meet the target needs of an IPv6-only deployment. As traffic moves to IPv6, the benefits of only a single stack on the access network may eventually justify the removal of IPv4 for simplicity. Planning for this eventual model, no matter how far off this may be, will help operators embrace this end state when needed.
オペレーターは、IPv6のみの展開のターゲットニーズを満たすための全体的な戦略も計画する必要があります。トラフィックがIPv6に移動するとき、アクセスネットワーク上の単一スタックのみの利点は、単純化のために最終的にIPv4の削除を正当化するかもしれません。この最終的なモデルの計画は、これがどれほど離れていても、オペレーターが必要なときにこの最終状態を受け入れるのに役立ちます。
The operator should thoroughly analyze all provisioning and management systems to develop requirements for each phase. This will include concepts related to the 128-bit IPv6 address, the notation of an assigned IPv6 prefix (Prefix Delegation), and the ability to detect either or both address families when determining if a subscriber has full Internet service.
オペレーターは、すべてのプロビジョニングおよび管理システムを徹底的に分析して、各フェーズの要件を開発する必要があります。これには、128ビットIPv6アドレス、割り当てられたIPv6プレフィックス（プレフィックス委任）の表記、およびサブスクライバーが完全なインターネットサービスを持っているかどうかを判別するときにアドレスファミリの一方または両方を検出する機能に関連する概念が含まれます。
If an operator stores usage information, this would need to be aggregated to include both IPv4 and IPv6 information as both address families are assigned to the same subscriber. Tools that verify connectivity may need to query the IPv4 and IPv6 addresses.
オペレーターが使用状況情報を保存する場合、両方のアドレスファミリーが同じサブスクライバーに割り当てられるため、IPv4とIPv6の両方の情報を含めるためにこれを集約する必要があります。接続を検証するツールは、IPv4およびIPv6アドレスを照会する必要がある場合があります。
Tunneled access to IPv6 can be regarded as an early-stage transition option by operators. Many network operators can deploy native IPv6 from the access edge to the peering edge fairly quickly but may not be able to offer IPv6 natively to the subscriber edge device. During this period of time, tunneled access to IPv6 is a viable alternative to native IPv6. It is also possible that operators may be rolling out IPv6 natively to the subscriber edge, but the time involved may be long, due to logistics and other factors. Even while carefully rolling out native IPv6, operators can deploy relays for automatic tunneling technologies like 6to4 and Teredo. Where native IPv6 to the access edge is a longer-term project, operators can consider 6rd [RFC5969] as an option to offer in-home IPv6 access. Note that 6to4 and Teredo have different address selection [RFC6724] behaviors than 6rd. Additional guidelines on deploying and supporting 6to4 can be found in [RFC6343].
IPv6へのトンネルアクセスは、事業者にとって初期段階の移行オプションと見なすことができます。多くのネットワークオペレーターは、ネイティブIPv6をアクセスエッジからピアリングエッジにかなり迅速に展開できますが、IPv6をネイティブにサブスクライバーエッジデバイスに提供できない場合があります。この期間中、IPv6へのトンネルアクセスは、ネイティブIPv6の実行可能な代替手段です。事業者がIPv6をネイティブで加入者エッジに展開している可能性もありますが、ロジスティクスやその他の要因により、時間がかかる場合があります。ネイティブIPv6を慎重に展開しているときでも、オペレーターは6to4やTeredoなどの自動トンネリングテクノロジーのリレーを展開できます。アクセスエッジへのネイティブIPv6が長期間のプロジェクトである場合、事業者は6番目の[RFC5969]を家庭内IPv6アクセスを提供するオプションとして検討できます。 6to4とTeredoは、アドレス選択[RFC6724]の動作が6rdとは異なることに注意してください。 6to4の展開とサポートに関する追加のガイドラインは[RFC6343]にあります。
The operator can deploy 6rd relays into the network and scale them as needed to meet the early subscriber needs of IPv6. Since 6rd requires the upgrade or replacement of CPE devices, the operator may want to ensure that the CPE devices support not just 6rd but native Dual Stack and other tunneling technologies, such as DS-Lite, if possible [IPv6-CE-RTR-REQS]. 6rd clients are becoming available in some retail channel products and within the original equipment manufacturer (OEM) market. Retail availability of 6rd is important, since not all operators control or have influence over what equipment is deployed in the consumer home network. The operator can support 6rd access with unmanaged devices using DHCPv4 Option 212 (OPTION_6RD) [RFC5969].
オペレーターは、6番目のリレーをネットワークに導入し、IPv6の初期加入者のニーズを満たすために必要に応じてそれらを拡張できます。 6rdはCPEデバイスのアップグレードまたは交換を必要とするため、オペレーターはCPEデバイスが6rdだけでなくネイティブデュアルスタックおよび可能であればDS-Liteなどの他のトンネリングテクノロジーをサポートすることを確認する必要がある場合があります[IPv6-CE-RTR-REQS ]。 6番目のクライアントは、一部の小売チャネル製品および相手先ブランド供給（OEM）市場で利用できるようになっています。すべての事業者がコンシューマホームネットワークに配備されている機器を制御したり影響を及ぼしたりするわけではないため、6rdの小売りの可用性は重要です。オペレーターは、DHCPv4オプション212（OPTION_6RD）[RFC5969]を使用して、管理対象外のデバイスによる6番目のアクセスをサポートできます。
+--------+ -----
| | / \
Encap IPv6 Flow | 6rd | | IPv6 |
- - -> | Relay | <- > | Net |
+---------+ / | | \ /
| | / +--------+ -----
| 6rd + <----- -----
| | / \
| Client | IPv4 Flow | IPv4 |
| + < - - - - - - - - - - - - - - -> | Net |
| | \ /
+---------+ -----
Figure 1: 6rd Basic Model
図1：6番目の基本モデル
6rd used as an initial transition technology also provides the added benefit of a deterministic IPv6 prefix based on the IPv4 assigned address. Many operational tools are available or have been built to identify what IPv4 (often dynamic) address was assigned to a subscriber CPE. So, a simple tool and/or method can be built to help identify the IPv6 prefix using the knowledge of the assigned IPv4 address.
初期移行テクノロジーとして使用される6rdは、IPv4割り当てアドレスに基づく確定的なIPv6プレフィックスの追加の利点も提供します。多くの運用ツールが利用可能であるか、加入者CPEに割り当てられたIPv4（多くの場合、動的）アドレスを識別するために構築されています。そのため、割り当てられたIPv4アドレスの知識を使用してIPv6プレフィックスを識別するのに役立つ簡単なツールや方法を構築できます。
An operator may choose to not offer internal services over IPv6 if tunneled access to IPv6 is used, since some services generate a large amount of traffic. Such traffic may include video content, like IPTV. By limiting how much traffic is delivered over the 6rd connection (if possible), the operator can avoid costly and complex scaling of the relay infrastructure.
一部のサービスは大量のトラフィックを生成するため、IPv6へのトンネルアクセスが使用される場合、オペレーターはIPv6を介して内部サービスを提供しないことを選択できます。このようなトラフィックには、IPTVなどのビデオコンテンツが含まれる場合があります。 6番目の接続を介して配信されるトラフィックの量を制限することにより（可能な場合）、オペレーターは、コストのかかる複雑なリレーインフラストラクチャのスケーリングを回避できます。
Deploying 6rd can greatly speed up an operator's ability to support IPv6 to the subscriber network if native IPv6 connectivity cannot be supplied. The speed at which 6rd can be deployed is highlighted in [RFC5569].
6rdを導入すると、ネイティブIPv6接続を提供できない場合に、オペレーターが加入者ネットワークに対してIPv6をサポートする能力が大幅にスピードアップします。 [RFC5569]では、6番目を展開できる速度が強調されています。
The first core consideration is deployment models. 6rd requires the CPE (6rd client) to send traffic to a 6rd relay. These relays can share a common anycast address or can use unique addresses. Using an anycast model, the operator can deploy all the 6rd relays using the same IPv4 interior service address. As the load increases on the deployed relays, the operator can deploy more relays into the network. The one drawback is that it may be difficult to manage the traffic volume among additional relays, since all 6rd traffic will find the nearest (in terms of IGP cost) relay. The use of multiple relay addresses can help provide more control but has the disadvantage of being more complex to provision. Subsets of CPEs across the network will require and contain different relay information. An alternative approach is to use a hybrid model using multiple anycast service IP addresses for clusters of 6rd relays, should the operator anticipate massive scaling of the environment. Thus, the operator has multiple vectors by which to scale the service.
最初の中心的な考慮事項は、展開モデルです。 6rdでは、CPE（6rdクライアント）がトラフィックを6rdリレーに送信する必要があります。これらのリレーは、共通のエニーキャストアドレスを共有するか、一意のアドレスを使用できます。エニーキャストモデルを使用すると、オペレーターは同じIPv4内部サービスアドレスを使用してすべての6番目のリレーを展開できます。展開されたリレーの負荷が増加すると、オペレーターはネットワークにより多くのリレーを展開できます。 1つの欠点は、すべての6番目のトラフィックが最も近い（IGPコストの観点から）リレーを見つけるため、追加のリレー間でトラフィック量を管理することが難しい場合があることです。複数のリレーアドレスを使用すると、制御を強化できますが、プロビジョニングが複雑になるという欠点があります。ネットワーク上のCPEのサブセットには、さまざまなリレー情報が必要であり、含まれます。代替のアプローチは、オペレーターが環境の大規模なスケーリングを予測する場合、6番目のリレーのクラスターに複数のエニーキャストサービスIPアドレスを使用するハイブリッドモデルを使用することです。したがって、オペレーターには、サービスをスケーリングするための複数のベクトルがあります。
+--------+
| |
IPv4 Addr.X | 6rd |
- - - > | Relay |
+-----------+ / | |
| Client A | <- - - +--------+
+-----------+
Separate IPv4 Service Addresses
+-----------+
| Client B | < - - +--------+
+-----------+ \ | |
- - - > | 6rd |
IPv4 Addr.Y | Relay |
| |
+--------+
Figure 2: 6rd Multiple IPv4 Service Address Model
図2：6番目の複数IPv4サービスアドレスモデル
+--------+
| |
IPv4 Addr.X | 6rd |
- - - > | Relay |
+-----------+ / | |
| Client A |- - - - +--------+
+-----------+
Common (Anycast) IPv4 Service Addresses
+-----------+
| Client B | - - - +--------+
+-----------+ \ | |
- - - > | 6rd |
IPv4 Addr.X | Relay |
| |
+--------+
Figure 3: 6rd Anycast IPv4 Service Address Model
図3：6番目のエニーキャストIPv4サービスアドレスモデル
Provisioning of the 6rd endpoints is affected by the deployment model chosen (i.e., anycast vs. specific service IP addresses). Using multiple IP addresses may require more planning and management, as subscriber equipment will have different sets of data to be provisioned into the devices. The operator may use DHCPv4, manual provisioning, or other mechanisms to provide parameters to subscriber equipment.
6番目のエンドポイントのプロビジョニングは、選択した導入モデル（つまり、エニーキャストと特定のサービスIPアドレス）の影響を受けます。複数のIPアドレスを使用すると、加入者機器がデバイスにプロビジョニングされる異なるデータセットを持つため、より多くの計画と管理が必要になる場合があります。オペレータはDHCPv4、手動プロビジョニング、またはその他のメカニズムを使用して、加入者機器にパラメータを提供できます。
If the operator manages the CPE, support personnel will need tools able to report the status of the 6rd tunnel. Usage information can be collected on the operator edge, but if source/destination flow details are required, data must be collected after the 6rd relay (the IPv6 side of the connection).
オペレーターがCPEを管理する場合、サポート担当者は6番目のトンネルのステータスを報告できるツールが必要になります。使用状況情報はオペレーターエッジで収集できますが、送信元/宛先フローの詳細が必要な場合は、6番目のリレー（接続のIPv6側）の後でデータを収集する必要があります。
6rd [RFC5969], like any tunneling option, is subject to a reduced MTU, so operators need to plan to manage this type of environment.
6rd [RFC5969]は、他のトンネリングオプションと同様に、MTUが減少する可能性があるため、オペレーターはこのタイプの環境の管理を計画する必要があります。
+---------+ IPv4 Encapsulation +------------+
| +- - - - - - - - - - - + |
| 6rd +----------------------+ 6rd +------------
| | IPv6 Packet | Relay | IPv6 Packet
| Client +----------------------+ +------------
| +- - - - - - - - - - - + | ^
+---------+ ^ +------------+ |
| |
| |
IPv4 (Tools/Mgmt) IPv6 Flow Analysis
Figure 4: 6rd Tools and Flow Management
図4：6番目のツールとフロー管理
Either as a follow-up phase to "tunneled IPv6" or as an initial step, the operator may deploy native IPv6 down to the CPEs. This phase would then allow both IPv6 and IPv4 to be natively accessed by the subscriber home network without translation or tunneling. The native Dual Stack phase can be rolled out across the network while the tunneled IPv6 service remains operational, if used. As areas begin to support native IPv6, subscriber home equipment will generally prefer using the IPv6 addresses derived from the delegated IPv6 prefix versus tunneling options as defined in [RFC6724], such as 6to4 and Teredo. Specific care is needed when moving to native Dual Stack from 6rd, as documented in [6rd-SUNSETTING].
「トンネルIPv6」へのフォローアップフェーズとして、または最初のステップとして、オペレーターはネイティブIPv6をCPEに展開できます。このフェーズでは、IPv6とIPv4の両方に、変換やトンネリングなしで加入者のホームネットワークからネイティブにアクセスできるようになります。ネイティブのデュアルスタックフェーズは、トンネル化されたIPv6サービスが使用されている場合は運用可能なまま、ネットワーク全体に展開できます。エリアがネイティブIPv6をサポートし始めると、加入者のホーム機器は、一般に、委任されたIPv6プレフィックスから派生したIPv6アドレスを使用することを優先します。 [6rd-SUNSETTING]に記載されているように、ネイティブデュアルスタックに6日から移行する場合は、特別な注意が必要です。
Native Dual Stack is the best option at this point in the transition and should be sought as soon as possible. During this phase, the operator can confidently move both internal and external services to IPv6. Since there are no translation devices needed for this mode of operation, it transports both protocols (IPv6 and IPv4) efficiently within the network.
ネイティブデュアルスタックは、移行のこの時点で最適なオプションであり、できるだけ早く模索する必要があります。このフェーズでは、オペレーターは自信を持って内部サービスと外部サービスの両方をIPv6に移行できます。この動作モードに必要な変換デバイスがないため、ネットワーク内で両方のプロトコル（IPv6とIPv4）を効率的に転送します。
Native Dual Stack is a very desirable option for the IPv6 transition, if feasible. The operator must enable IPv6 on the network core and peering edge before attempting to turn on native IPv6 services. Additionally, provisioning and support systems such as DHCPv6, DNS, and other functions that support the subscriber's IPv6 Internet connection need to be in place.
可能であれば、ネイティブデュアルスタックはIPv6移行に非常に望ましいオプションです。オペレーターは、ネイティブIPv6サービスをオンにする前に、ネットワークコアとピアリングエッジでIPv6を有効にする必要があります。さらに、DHCPv6、DNS、および加入者のIPv6インターネット接続をサポートするその他の機能などのプロビジョニングおよびサポートシステムを配備する必要があります。
The operator must treat IPv6 connectivity with the same operational importance as IPv4. A poor IPv6 service may be worse than not offering an IPv6 service at all, as it will negatively impact the subscriber's Internet experience. This may cause users or support personnel to disable IPv6, limiting the subscriber from the benefits of IPv6 connectivity as network performance improves. New code and IPv6 functionality may cause instability at first. The operator will need to monitor, troubleshoot, and resolve issues promptly.
オペレーターは、IPv4と同じ運用上の重要性を持つIPv6接続を処理する必要があります。不十分なIPv6サービスは、加入者のインターネットエクスペリエンスに悪影響を与えるため、IPv6サービスをまったく提供しないよりも悪い場合があります。これにより、ユーザーまたはサポート担当者がIPv6を無効にし、ネットワークパフォーマンスが向上するにつれてIPv6接続の利点からサブスクライバーが制限される可能性があります。新しいコードとIPv6機能は、最初は不安定になる可能性があります。オペレーターは問題を迅速に監視、トラブルシューティング、解決する必要があります。
Prefix assignment and routing are new for common residential services. Prefix assignment is straightforward (DHCPv6 using Identity Associations for Prefix Delegation (IA_PDs)), but installation and propagation of routing information for the prefix, especially during access layer instability, are often poorly understood. The operator should develop processes for renumbering subscribers who move to new access nodes.
プレフィックスの割り当てとルーティングは、一般的な住宅用サービスの新機能です。プレフィックスの割り当ては簡単です（プレフィックス委任（IA_PDs）のIDアソシエーションを使用するDHCPv6）。ただし、特にアクセスレイヤーが不安定な場合のプレフィックスのルーティング情報のインストールと伝達は、よく理解されていません。オペレータは、新しいアクセスノードに移動するサブスクライバの番号を付け直すプロセスを開発する必要があります。
Operators need to keep track of the dynamically assigned IPv4 address along with the IPv6 address and prefix. Any additional dynamic elements, such as auto-generated host names, need to be considered and planned for.
オペレーターは、動的に割り当てられたIPv4アドレスを、IPv6アドレスとプレフィックスとともに追跡する必要があります。自動生成されたホスト名などの追加の動的要素は、検討および計画する必要があります。
Acquiring more IPv4 addresses is already challenging, if not impossible; therefore, address sharing may be required on the IPv4 path of a Dual Stack deployment. The operator may have a preference to move directly to a transition technology such as DS-Lite [RFC6333] or may use Dual Stack with CGN/NAT444 to facilitate IPv4 connections.
IPv4アドレスをさらに取得することは、不可能ではないにしても、すでに困難です。したがって、デュアルスタック展開のIPv4パスでアドレス共有が必要になる場合があります。オペレーターは、DS-Lite [RFC6333]などの移行テクノロジーに直接移行することを希望する場合や、CGN / NAT444でデュアルスタックを使用してIPv4接続を容易にする場合があります。
CGN/NAT444 requires IPv4 addressing between the subscriber premises equipment and the operator's translator; this may be facilitated by shared addresses [RFC6598], private addresses [RFC1918], or another address space. CGN/NAT444 is only recommended to be used alongside IPv6 in a Dual Stack deployment and not on its own. Figure 5 provides a comparative view of a traditional IPv4 path versus one that uses CGN/NAT444.
CGN / NAT444では、加入者構内機器とオペレーターのトランスレーターとの間にIPv4アドレス指定が必要です。これは、共有アドレス[RFC6598]、プライベートアドレス[RFC1918]、または別のアドレススペースによって促進される場合があります。 CGN / NAT444は、単独ではなく、デュアルスタック展開でIPv6と一緒に使用することをお勧めします。図5は、従来のIPv4パスとCGN / NAT444を使用するパスの比較を示しています。
+--------+ -----
| | / \
IPv4 Flow | CGN | | |
- - -> + + < -> | |
+---------+ / | | | |
| CPE | <- - - / +--------+ | IPv4 |
|---------+ | Net |
| |
+---------+ IPv4 Flow | |
| CPE | <- - - - - - - - - - - - - - - > | |
|---------+ \ /
-----
Figure 5: Overlay CGN Deployment
図5：オーバーレイCGNの展開
In the case of native Dual Stack, CGN/NAT444 can be used to assist in extending connectivity for the IPv4 path while the IPv6 path remains native. For endpoints operating in an IPv6+CGN/NAT444 model, the native IPv6 path is available for higher-quality connectivity, helping host operation over the network. At the same time, the CGN path may offer less than optimal performance. These points are also true for DS-Lite.
ネイティブデュアルスタックの場合、CGN / NAT444を使用すると、IPv6パスがネイティブのままでIPv4パスの接続を拡張できます。 IPv6 + CGN / NAT444モデルで動作するエンドポイントの場合、ネイティブIPv6パスを使用して高品質の接続を実現し、ネットワーク上でのホスト操作を支援します。同時に、CGNパスでは最適なパフォーマンスが得られない場合があります。これらの点はDS-Liteにも当てはまります。
+--------+ -----
| | / \
IPv4 Flow | CGN | | IPv4 |
- - -> + + < -> | Net |
+---------+ / | | \ /
| | <- - - / +--------+ -------
| Dual |
| Stack | -----
| CPE | IPv6 Flow / IPv6 \
| | <- - - - - - - - - - - - - - - > | Net |
|---------+ \ /
-----
Figure 6: Dual Stack with CGN
図6：CGNを使用したデュアルスタック
CGN/NAT444 deployments may make use of a number of address options, which include [RFC1918] or Shared Address Space [RFC6598]. It is also possible that operators may use part of their own Regional Internet Registry (RIR) assigned address space for CGN zone addressing if [RFC1918] addresses pose technical challenges in their networks. It is not recommended that operators use 'squat space', as it may pose additional challenges with filtering and policy control [RFC6598].
CGN / NAT444の展開では、[RFC1918]または共有アドレススペース[RFC6598]を含む多数のアドレスオプションを利用できます。 [RFC1918]アドレスがネットワークに技術的な課題をもたらす場合、事業者はCGNゾーンのアドレス指定に独自の地域インターネットレジストリ（RIR）割り当てアドレススペースの一部を使用する可能性もあります。オペレーターが「スクワットスペース」を使用することはお勧めできません。フィルタリングとポリシー制御[RFC6598]で追加の課題が発生する可能性があるためです。
CGN is often considered undesirable by operators but is required in many cases. An operator who needs to deploy CGN capabilities should consider the impacts of the function on the network. CGN is often deployed in addition to running IPv4 services and should not negatively impact the already working native IPv4 service. CGNs will be needed on a small scale at first and will grow to meet the demands based on traffic and connection dynamics of the subscriber, content, and network peers.
CGNは多くの場合、オペレーターにとって望ましくないと考えられていますが、多くの場合必要です。 CGN機能を展開する必要があるオペレーターは、ネットワーク上の機能の影響を考慮する必要があります。 CGNは、IPv4サービスの実行に加えて展開されることが多く、すでに機能しているネイティブIPv4サービスに悪影響を与えることはありません。 CGNは最初は小規模で必要であり、加入者、コンテンツ、およびネットワークピアのトラフィックと接続のダイナミクスに基づいて要求を満たすために拡張されます。
The operator may want to deploy CGNs more centrally at first and then scale the system as needed. This approach can help conserve the costs of the system, limiting the deployed base and scaling it based on actual traffic demand. The operator should use a deployment model and architecture that allow the system to scale as needed.
事業者は、最初にCGNをより集中的に展開し、その後、必要に応じてシステムを拡張することを望む場合があります。このアプローチは、システムのコストを節約し、展開ベースを制限し、実際のトラフィック需要に基づいてスケーリングするのに役立ちます。オペレーターは、システムを必要に応じて拡張できる配置モデルとアーキテクチャを使用する必要があります。
+--------+ -----
| | / \
| CGN | | |
- - -> + + < -> | |
+---------+ / | | | |
| CPE | <- - - / +--------+ | IPv4 |
| | ^ | |
|---------+ | | Net |
+--------+ Centralized | |
+---------+ | | CGN | |
| | | CGN | | |
| CPE | <- > + + <- - - - - - - > | |
|---------+ | | \ /
+--------+ -----
^
|
Distributed CGN
Figure 7: CGN Deployment: Centralized vs. Distributed
図7：CGNの展開：集中型と分散型
The operator may be required to log translation information [CGN-REQS]. This logging may require significant investment in external systems that ingest, aggregate, and report such information [DETERMINISTIC-CGN].
オペレーターは、変換情報をログに記録する必要がある場合があります[CGN-REQS]。このロギングでは、そのような情報を取り込み、集約し、報告する外部システムへの多大な投資が必要になる場合があります[DETERMINISTIC-CGN]。
Since CGN has noticeable impacts on certain applications [NAT444-IMPACTS], operators may deploy CGN only for those subscribers who may be less affected by CGN (if possible).
CGNは特定のアプリケーション[NAT444-IMPACTS]に顕著な影響を与えるため、オペレーターはCGNの影響をあまり受けない可能性のあるサブスクライバーに対してのみCGNを展開できます（可能な場合）。
Once native IPv6 is widely deployed in the network and well supported by tools, staff, and processes, an operator may consider supporting only IPv6 to all or some subscriber endpoints. During this final phase, IPv4 connectivity may or may not need to be supported, depending on the conditions of the network, subscriber demand, and legacy device requirements. If legacy IPv4 connectivity is still demanded (e.g., for older nodes), DS-Lite [RFC6333] may be used to tunnel the traffic. If IPv4 connectivity is not required but access to legacy IPv4 content is, then NAT64 [RFC6144] [RFC6146] can be used.
ネイティブIPv6がネットワークに広く導入され、ツール、スタッフ、およびプロセスによって適切にサポートされると、オペレーターはすべてまたは一部の加入者エンドポイントに対してIPv6のみのサポートを検討する場合があります。この最終フェーズでは、ネットワークの状態、加入者の需要、およびレガシーデバイスの要件に応じて、IPv4接続をサポートする必要がある場合とない場合があります。レガシーIPv4接続が引き続き必要な場合（たとえば、古いノードの場合）、DS-Lite [RFC6333]を使用してトラフィックをトンネリングできます。 IPv4接続は必要ないが、レガシーIPv4コンテンツへのアクセスが必要な場合は、NAT64 [RFC6144] [RFC6146]を使用できます。
DS-Lite allows continued access for the IPv4 subscriber base using address sharing for IPv4 Internet connectivity but with only a single layer of translation, as compared to CGN/NAT444. This mode of operation also removes the need to directly supply subscriber endpoints with an IPv4 address, potentially simplifying the connectivity to the customer (single address family) and supporting IPv6-only addressing to the CPE.
DS-Liteでは、CGN / NAT444と比較して、IPv4インターネット接続のアドレス共有を使用して、IPv4サブスクライバーベースへのアクセスを継続できますが、変換のレイヤーは1つだけです。この操作モードでは、IPv4アドレスをサブスクライバーエンドポイントに直接提供する必要もなくなり、潜在的に顧客（単一アドレスファミリ）への接続が簡略化され、CPEへのIPv6のみのアドレス指定がサポートされます。
The operator can also move Dual Stack endpoints to DS-Lite
retroactively to help optimize the IPv4 address-sharing deployment by
removing the IPv4 address assignment and routing component. To
minimize traffic needing translation, the operator should have
already moved most content to IPv6 before the IPv6-only phase is
implemented.
+--------+ -----
| | / \
Encap IPv4 Flow | AFTR | | IPv4 |
-------+ +---+ Net |
+---------+ / | | \ /
| | / +--------+ -----
| DS-Lite +------- -----
| | / \
| Client | IPv6 Flow | IPv6 |
| +-------------------------------| Net |
| | \ /
+---------+ -----
Figure 8: DS-Lite Basic Model
図8：DS-Lite基本モデル
If the operator had previously decided to enable a CGN/NAT444 deployment, it may be able to co-locate the AFTR and CGN/NAT444 processing functions within a common network location to simplify capacity management and the engineering of flows. This case may be evident in a later transition stage, when an operator chooses to optimize its network and IPv6-only operation is feasible.
オペレーターが以前にCGN / NAT444の展開を有効にすることを決定した場合、AFTRとCGN / NAT444の処理機能を共通のネットワークロケーション内に配置して、容量管理とフローのエンジニアリングを簡素化できる場合があります。このケースは、オペレーターがネットワークを最適化することを選択し、IPv6のみの操作が実行可能な後の移行段階で明らかになる場合があります。
The same deployment considerations associated with native IPv6 deployments apply to DS-Lite and NAT64. IPv4 will now be dependent on IPv6 service quality, so the IPv6 network and services must be running well to ensure a quality experience for the end subscriber. Tools and processes will be needed to manage the encapsulated IPv4 service. If flow analysis is required for IPv4 traffic, this may be enabled at a point beyond the AFTR (after decapsulation) or where DS-Lite-aware equipment is used to process traffic midstream.
ネイティブIPv6の展開に関連する同じ考慮事項がDS-LiteとNAT64に適用されます。 IPv4はIPv6サービスの品質に依存するようになるため、エンドサブスクライバーに高品質のエクスペリエンスを提供するには、IPv6ネットワークとサービスを適切に実行する必要があります。カプセル化されたIPv4サービスを管理するには、ツールとプロセスが必要になります。 IPv4トラフィックにフロー分析が必要な場合、これはAFTR（カプセル化解除後）を超えた時点で、またはDS-Lite対応機器を使用してトラフィックを途中で処理する場合に有効にすることができます。
+---------+ IPv6 Encapsulation +------------+
| + - - - - - - - - - - -+ |
| AFTR +----------------------+ AFTR +------------
| | IPv4 Packet | | IPv4 Packet
| Client +----------------------+ +------------
| + - - - - - - - - - - -+ | ^
+---------+ ^ ^ +------------+ |
| | |
| | |
IPv6 (Tools/Mgmt) | IPv4 Packet Flow Analysis
|
Midstream IPv4 Packet Flow Analysis (Encapsulation Aware)
Figure 9: DS-Lite Tools and Flow Analysis
図9：DS-Liteツールとフロー分析
DS-Lite [RFC6333] also requires client support on the subscriber premises device. The operator must clearly articulate to vendors which technologies will be used at which points, how they interact with each other at the CPE, and how they will be provisioned. As an example, an operator may use 6rd in the outset of the transition, then move to native Dual Stack followed by DS-Lite.
DS-Lite [RFC6333]では、加入者構内デバイスでのクライアントサポートも必要です。事業者は、どのテクノロジーがどの時点で使用されるか、それらがCPEで相互にどのように相互作用するか、どのようにプロビジョニングされるかをベンダーに明確に示す必要があります。例として、オペレーターは移行の最初に6番目を使用し、次にネイティブデュアルスタックに移動してからDS-Liteに移動します。
DS-Lite [RFC6333], like any tunneling option, is subject to a reduced MTU, so operators need to plan to manage this type of environment. Additional considerations for DS-Lite deployments can be found in [DSLITE-DEPLOYMENT].
DS-Lite [RFC6333]は、他のトンネリングオプションと同様に、MTUが削減されるため、オペレーターはこのタイプの環境の管理を計画する必要があります。 DS-Liteの導入に関するその他の考慮事項は、[DSLITE-DEPLOYMENT]にあります。
The deployment of NAT64 assumes that the network assigns an IPv6 address to a network endpoint that is translated to an IPv4 address to provide connectivity to IPv4 Internet services and content. Experiments such as the one described in [RFC6586] highlight issues related to IPv6-only deployments due to legacy IPv4 APIs and IPv4 literals. Many of these issues will be resolved by the eventual removal of this undesirable legacy behavior. Operational deployment models, considerations, and experiences related to NAT64 have been documented in [NAT64-EXPERIENCE].
NAT64の展開では、ネットワークがIPv6アドレスをネットワークエンドポイントに割り当て、IPv4アドレスに変換してIPv4インターネットサービスとコンテンツへの接続を提供することを前提としています。 [RFC6586]で説明されているような実験は、レガシーIPv4 APIとIPv4リテラルによるIPv6のみの展開に関連する問題を明らかにします。これらの問題の多くは、この望ましくないレガシー動作を最終的に削除することで解決されます。 NAT64に関連する運用展開モデル、考慮事項、および経験は、[NAT64-EXPERIENCE]に文書化されています。
+--------+ -----
| | / \
IPv6 Flow | NAT64 | | IPv4 |
-------+ DNS64 +---+ Net |
+---------+ / | | \ /
| | / +--------+ -----
| IPv6 +------- -----
| | / \
| Only | IPv6 Flow | IPv6 |
| +-------------------------------| Net |
| | \ /
+---------+ -----
Figure 10: NAT64/DNS64 Basic Model
図10：NAT64 / DNS64基本モデル
To navigate some of the limitations of NAT64 when dealing with legacy IPv4 applications, the operator may choose to implement 464XLAT [464XLAT] if possible. As support for IPv6 on subscriber equipment and content increases, the efficiency of NAT64 increases by reducing the need to translate traffic. NAT64 deployments would see an overall decline in translator usage as more traffic is promoted to IPv6-to-IPv6 native communication. NAT64 may play an important part in an operator's late-stage transition, as it removes the need to support IPv4 on the access network and provides a solid go-forward networking model.
レガシーIPv4アプリケーションを扱うときにNAT64の制限のいくつかをナビゲートするために、オペレーターは可能であれば464XLAT [464XLAT]を実装することを選択できます。加入者機器およびコンテンツでのIPv6のサポートが増加するにつれて、トラフィックを変換する必要性を減らすことにより、NAT64の効率が向上します。 NAT64の展開では、IPv6からIPv6へのネイティブ通信へのトラフィックが増えるため、トランスレーターの使用が全体的に減少します。 NAT64は、アクセスネットワークでIPv4をサポートする必要をなくし、確実な前進型ネットワークモデルを提供するため、オペレーターの後期段階の移行において重要な役割を果たす可能性があります。
It should be noted, as with any technology that utilizes address sharing, that the IPv4 public pool sizes (IPv4 transport addresses per [RFC6146]) can pose limits to IPv4 server connectivity for the subscriber base. Operators should be aware that some IPv4 growth in the near term is possible, so IPv4 translation pools need to be monitored.
アドレス共有を利用する他のテクノロジーと同様に、IPv4パブリックプールサイズ（[RFC6146]ごとのIPv4トランスポートアドレス）は、加入者ベースのIPv4サーバー接続に制限を課す可能性があることに注意してください。オペレーターは、短期的にはIPv4の成長がある程度可能であることを認識しておく必要があるため、IPv4変換プールを監視する必要があります。
Operators should review the documentation related to the technologies selected for IPv6 transition. In those reviews, operators should understand what security considerations are applicable to the chosen technologies. As an example, [RFC6169] should be reviewed to understand security considerations related to tunneling technologies.
オペレーターは、IPv6移行用に選択されたテクノロジーに関連するドキュメントを確認する必要があります。これらのレビューでは、オペレーターは、選択したテクノロジーに適用可能なセキュリティの考慮事項を理解する必要があります。例として、[RFC6169]を見直して、トンネリング技術に関連するセキュリティの考慮事項を理解する必要があります。
Special thanks to Wes George, Chris Donley, Christian Jacquenet, and John Brzozowski for their extensive review and comments.
Wes George、Chris Donley、Christian Jacquenet、John Brzozowskiの広範なレビューとコメントに特に感謝します。
Thanks to the following people for their textual contributions, guidance, and comments: Jason Weil, Gang Chen, Nik Lavorato, John Cianfarani, Chris Donley, Tina TSOU, Fred Baker, and Randy Bush.
テキストによる貢献、ガイダンス、コメントを提供してくれたJason Weil、Gang Chen、Nik Lavorato、John Cianfarani、Chris Donley、Tina TSOU、Fred Baker、Randy Bushに感謝します。
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, May 2011.
[RFC6180] Arkko、J。およびF. Baker、「IPv6展開中にIPv6移行メカニズムを使用するためのガイドライン」、RFC 6180、2011年5月。
[464XLAT] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", Work in Progress, September 2012.
[464XLAT] Mawatari、M.、Kawashima、M.、and C. Byrne、 "464XLAT：Combination of Stateful and Stateless Translation"、Work in Progress、2012年9月。
[6rd-SUNSETTING] Townsley, W. and A. Cassen, "6rd Sunsetting", Work in Progress, November 2011.
[6rd-SUNSETTING]タウンズリー、W。およびA.カッセン、「6rd Sunsetting」、作業中、2011年11月
[CGN-REQS] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NATs (CGNs)", Work in Progress, August 2012.
[CGN-REQS] Perreault、S.、Ed。、Yamagata、I.、Miyakawa、S.、Nakagawa、A.、and H. Ashida、 "Common requirements for Carrier Grade NATs（CGNs）"、Work in Progress、August 2012。
[COMCAST-IPv6-EXPERIENCES] Brzozowski, J. and C. Griffiths, "Comcast IPv6 Trial/ Deployment Experiences", Work in Progress, October 2011.
[COMCAST-IPv6-EXPERIENCES] Brzozowski、J。およびC. Griffiths、「Comcast IPv6 Trial / Deployment Experiences」、Work in Progress、2011年10月。
[DETERMINISTIC-CGN] Donley, C., Grundemann, C., Sarawat, V., and K. Sundaresan, "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", Work in Progress, July 2012.
[DETERMINISTIC-CGN] Donley、C.、Grundemann、C.、Sarawat、V。、およびK. Sundaresan、「Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments」、Work in Progress、2012年7月。
[DSLITE-DEPLOYMENT] Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M. Boucadair, "Deployment Considerations for Dual-Stack Lite", Work in Progress, August 2012.
[DSLITE-DEPLOYMENT] Lee、Y.、Maglione、R.、Williams、C.、Jacquenet、C。、およびM. Boucadair、「Dual-Stack Liteの導入に関する考慮事項」、Work in Progress、2012年8月。
[IPv6-CE-RTR-REQS] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", Work in Progress, October 2012.
[IPv6-CE-RTR-REQS] Singh、H.、Beebee、W.、Donley、C。、およびB. Stark、「IPv6カスタマーエッジルーターの基本要件」、作業中、2012年10月。
[IPv6-DESIGN] Matthews, P., "Design Guidelines for IPv6 Networks", Work in Progress, October 2012.
[IPv6-DESIGN]マシューズ、P。、「IPv6ネットワークの設計ガイドライン」、作業中、2012年10月。
[IPv6-ICP-ASP-GUIDANCE] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet Content and Application Service Providers", Work in Progress, September 2012.
[IPv6-ICP-ASP-GUIDANCE] Carpenter、B。およびS. Jiang、「インターネットコンテンツおよびアプリケーションサービスプロバイダーのためのIPv6ガイダンス」、進行中の作業、2012年9月。
[NAT444-IMPACTS] Donley, C., Ed., Howard, L., Kuarsingh, V., Berg, J., and J. Doshi, "Assessing the Impact of Carrier-Grade NAT on Network Applications", Work in Progress, October 2012.
[NAT444-IMPACTS] Donley、C.、Ed。、Howard、L.、Kuarsingh、V.、Berg、J.、and J. Doshi、 "Assessing the Impact of Carrier-Grade NAT on Network Applications"、Work in Progress 、2012年10月。
[NAT64-EXPERIENCE] Chen, G., Cao, Z., Byrne, C., Xie, C., and D. Binet, "NAT64 Operational Experiences", Work in Progress, August 2012.
[NAT64-EXPERIENCE] Chen、G.、Cao、Z.、Byrne、C.、Xie、C。、およびD. Binet、「NAT64 Operational Experiences」、Work in Progress、2012年8月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B。およびK.ムーア、「IPv4クラウドを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068] Huitema、C。、「Antocast Prefix for 6to4 Relay Routers」、RFC 3068、2001年6月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema、C。、「Teredo：Tunneling IPv6 over UDP through Network Address Translations（NATs）」、RFC 4380、2006年2月。
[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移行/共存セキュリティの考慮事項」、RFC 4942、2007年9月。
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5569] Despres、R。、「IPv4 Infrastructures on IPv4 Infrastructures（6rd）」、RFC 5569、2010年1月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969] Townsley、W.およびO. Troan、「IPv4 Infrastructures on IPv4 Infrastructures（6rd）-Protocol Specification」、RFC 5969、2010年8月。
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011.
[RFC6092] Woodyatt、J。、「住宅用IPv6インターネットサービスを提供するための顧客宅内機器（CPE）における推奨される単純なセキュリティ機能」、RFC 6092、2011年1月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「Framework for IPv4 / IPv6 Translation」、RFC 6144、2011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、2011年4月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169]クリシュナン、S。、ターラー、D。、およびJ.ホアグランド、「IPトンネリングに関するセキュリティ上の懸念」、RFC 6169、2011年4月。
[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, June 2011.
[RFC6264] Jiang、S.、Guo、D。、およびB. Carpenter、「IPv6移行のための増分キャリアグレードNAT（CGN）」、RFC 6264、2011年6月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]フォード、M。、ブーカデア、M。、デュランド、A。、リーバイス、P。、およびP.ロバーツ、「IPアドレスの共有に関する問題」、RFC 6269、2011年6月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、2011年8月。
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
[RFC6343]カーペンター、B。、「6to4展開に関する勧告ガイドライン」、RFC 6343、2011年8月。
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, April 2012.
[RFC6540] George W.、Donley、C.、Liljenstolpe、C。、およびL. Howard、「すべてのIP対応ノードに必要なIPv6サポート」、BCP 177、RFC 6540、2012年4月。
[RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", RFC 6586, April 2012.
[RFC6586] Arkko、J。およびA. Keranen、「Experiences from an IPv6-Only Network」、RFC 6586、2012年4月。
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012.
[RFC6598] Weil、J.、Kuarsingh、V.、Donley、C.、Liljenstolpe、C。、およびM. Azinger、「IANA-Reserved IPv4 Prefix for Shared Address Space」、BCP 153、RFC 6598、2012年4月。
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724] Thaler、D.、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、2012年9月。
[RFC6732] Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider Managed Tunnels", RFC 6732, September 2012.
[RFC6732] Kuarsingh、V.、Lee、Y。、およびO. Vautrin、「6to4 Provider Managed Tunnels」、RFC 6732、2012年9月。
Authors' Addresses
著者のアドレス
Victor Kuarsingh (editor) Rogers Communications 8200 Dixie Road Brampton, Ontario L6T 0C1 Canada
Victor Kuarsingh（編集者）Rogers Communications 8200 Dixie Roadブランプトンオンタリオ州L6T 0C1カナダ
EMail: victor.kuarsingh@gmail.com
URI: http://www.rogers.com
Lee Howard Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 US
リーハワードタイムワーナーケーブル13820 Sunrise Valley Drive Herndon、VA 20171 US
EMail: lee.howard@twcable.com
URI: http://www.timewarnercable.com