[要約] RFC 6883は、インターネットコンテンツプロバイダやアプリケーションサービスプロバイダ向けのIPv6ガイダンスです。その目的は、IPv6の導入と運用に関する指針を提供し、インターネットサービスの円滑な提供を支援することです。
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 6883 Univ. of Auckland
Category: Informational S. Jiang
ISSN: 2070-1721 Huawei Technologies Co., Ltd
March 2013
IPv6 Guidance for Internet Content Providers and Application Service Providers
インターネットコンテンツプロバイダーおよびアプリケーションサービスプロバイダー向けのIPv6ガイダンス
Abstract
概要
This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers or to any enterprise network preparing for IPv6 users.
このドキュメントは、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/rfc6883.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6883で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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 ....................................................2
2. General Strategy ................................................3
3. Education and Skills ............................................5
4. Arranging IPv6 Connectivity .....................................6
5. IPv6 Infrastructure .............................................7
5.1. Address and Subnet Assignment ..............................7
5.2. Routing ....................................................8
5.3. DNS ........................................................9
6. Load Balancers .................................................10
7. Proxies ........................................................11
8. Servers ........................................................12
8.1. Network Stack .............................................12
8.2. Application Layer .........................................12
8.3. Logging ...................................................13
8.4. Geolocation ...............................................13
9. Coping with Transition Technologies ............................13
10. Content Delivery Networks .....................................15
11. Business Partners .............................................16
12. Possible Complexities .........................................16
13. Operations and Management .....................................17
14. Security Considerations .......................................18
15. Acknowledgements ..............................................20
16. References ....................................................20
16.1. Normative References .....................................20
16.2. Informative References ...................................22
The deployment of IPv6 [RFC2460] is now in progress, and users without direct IPv4 access are likely to appear in increasing numbers in the coming years. Any provider of content or application services over the Internet will need to arrange for IPv6 access or else risk losing large numbers of potential users. For users who already have dual-stack connectivity, direct IPv6 access might provide more satisfactory performance than indirect access via NAT.
IPv6 [RFC2460]の展開が現在進行中であり、IPv4に直接アクセスできないユーザーが今後数年間で増加する可能性があります。インターネットを介したコンテンツまたはアプリケーションサービスのプロバイダーは、IPv6アクセスを手配する必要があります。そうしないと、多数の潜在的なユーザーを失うリスクがあります。すでにデュアルスタック接続を使用しているユーザーの場合、直接IPv6アクセスは、NATを介した間接アクセスよりも満足できるパフォーマンスを提供する可能性があります。
In this document, we often refer to the users of content or application services as "customers" to clarify the part they play, but this is not intended to limit the scope to commercial sites.
このドキュメントでは、コンテンツまたはアプリケーションサービスのユーザーを「顧客」と呼び、その役割を明確にしますが、これは範囲を商用サイトに限定することを意図したものではありません。
The time for action is now, while the number of IPv6-only customers is small, so that appropriate skills, software, and equipment can be acquired in good time to scale up the IPv6 service as demand increases. An additional advantage of early support for IPv6 customers is that it will reduce the number of customers connecting later via IPv4 "extension" solutions such as double NAT or NAT64 [RFC6146], which will otherwise degrade the user experience.
IPv6のみの顧客の数は少ないので、行動の時が来ました。そのため、適切なスキル、ソフトウェア、および機器を適時に取得して、需要の増加に応じてIPv6サービスを拡張できます。 IPv6顧客の早期サポートの追加の利点は、ダブルNATまたはNAT64 [RFC6146]などのIPv4 "拡張"ソリューションを介して後で接続する顧客の数が減ることです。そうしないと、ユーザーエクスペリエンスが低下します。
Nevertheless, it is important that the introduction of IPv6 service should not make service for IPv4 customers worse. In some circumstances, technologies intended to assist in the transition from IPv4 to IPv6 are known to have negative effects on the user experience. A deployment strategy for IPv6 must avoid these effects as much as possible.
それでもなお、IPv6サービスの導入によってIPv4の顧客に対するサービスが悪化しないようにすることが重要です。状況によっては、IPv4からIPv6への移行を支援することを目的としたテクノロジが、ユーザーエクスペリエンスに悪影響を及ぼすことが知られています。 IPv6の導入戦略では、これらの影響をできるだけ回避する必要があります。
The purpose of this document is to provide guidance and suggestions for Internet Content Providers (ICPs) and Application Service Providers (ASPs) who wish to offer their services to both IPv6 and IPv4 customers but who are currently supporting only IPv4. For simplicity, the term "ICP" is mainly used in the body of this document, but the guidance also applies to ASPs. Any hosting provider whose customers include ICPs or ASPs is also concerned. Many of the points in this document will also apply to enterprise networks that do not classify themselves as ICPs. Any enterprise or department that runs at least one externally accessible server, such as an HTTP server, may also be concerned. Although specific managerial and technical approaches are described, this is not a rule book; each operator will need to make its own plan, tailored to its own services and customers.
このドキュメントの目的は、IPv6とIPv4の両方の顧客にサービスを提供したいが、現在IPv4のみをサポートしているインターネットコンテンツプロバイダー（ICP）とアプリケーションサービスプロバイダー（ASP）にガイダンスと提案を提供することです。簡単にするために、このドキュメントの本文では主に「ICP」という用語を使用していますが、ガイダンスはASPにも適用されます。 ICPまたはASPを顧客とするホスティングプロバイダーも関係します。このドキュメントのポイントの多くは、ICPとして分類されないエンタープライズネットワークにも適用されます。 HTTPサーバーなど、外部からアクセス可能なサーバーを少なくとも1つ実行している企業や部門も関係する可能性があります。特定の管理および技術的なアプローチが説明されていますが、これはルールブックではありません。各事業者は、独自のサービスと顧客に合わせて独自の計画を立てる必要があります。
The most important advice here is to actually have a general strategy. Adding support for a second network-layer protocol is a new experience for most modern organizations, and it cannot be done casually on an unplanned basis. Even if it is impossible to write a precisely dated plan, the intended steps in the process need to be defined well in advance. There is no single blueprint for this. The rest of this document is meant to provide a set of topics to be taken into account in defining the strategy. Other documents about IPv6 deployment, such as [IPv6-NETWORK-DESIGN], should be consulted as well.
ここで最も重要なアドバイスは、実際に一般的な戦略を持つことです。 2番目のネットワーク層プロトコルのサポートを追加することは、ほとんどの現代の組織にとって新しい経験であり、計画外では何気なく行うことはできません。正確な日付の計画を書くことが不可能な場合でも、プロセスの目的のステップは、事前に定義する必要があります。このための単一の青写真はありません。このドキュメントの残りの部分は、戦略を定義する際に考慮すべき一連のトピックを提供することを目的としています。 [IPv6-NETWORK-DESIGN]など、IPv6の展開に関するその他のドキュメントも参照する必要があります。
In determining the urgency of this strategy, it should be noted that the central IPv4 registry (IANA) ran out of spare blocks of IPv4 addresses in February 2011, and the various regional registries are expected to exhaust their reserves over the next one to two years. After this, Internet Service Providers (ISPs) will run out at dates determined by their own customer base. No precise date can be given for when IPv6-only customers will appear in commercially significant numbers, but -- particularly in the case of mobile users -- it may be quite soon. Complacency about this is therefore not an option for any ICP that wishes to grow its customer base over the coming years.
この戦略の緊急性を判断する際には、中央IPv4レジストリ（IANA）が2011年2月にIPv4アドレスのスペアブロックを使い果たし、さまざまな地域レジストリが次の1〜2年で予備を使い果たすと予想されることに注意してください。 。この後、インターネットサービスプロバイダー（ISP）は、独自の顧客ベースによって決定された日付で実行されます。 IPv6のみの顧客が商業的にかなりの数で登場する正確な日付を示すことはできませんが、特にモバイルユーザーの場合は、もうすぐです。したがって、これに関する自己満足は、今後数年間にわたって顧客ベースの拡大を望むICPの選択肢ではありません。
The most common strategy for an ICP is to provide dual-stack services -- both IPv4 and IPv6 on an equal basis -- to cover both existing and future customers. This is the recommended strategy in [RFC6180] for straightforward situations. Some ICPs who already have satisfactory operational experience with IPv6 might consider an IPv6-only strategy, with IPv4 clients being supported by translation or proxy in front of their IPv6 content servers. However, the present document is addressed to ICPs without IPv6 experience, who are likely to prefer the dual-stack model to build on their existing IPv4 service.
ICPの最も一般的な戦略は、デュアルスタックサービス（IPv4とIPv6の両方を同等に）を提供して、既存の顧客と将来の顧客の両方をカバーすることです。これは、単純な状況に対して[RFC6180]で推奨される戦略です。 IPv6での満足な運用経験を既に持っている一部のICPは、IPv6のみの戦略を検討するかもしれません。IPv4クライアントは、IPv6コンテンツサーバーの前で変換またはプロキシによってサポートされています。ただし、現在のドキュメントは、IPv6の経験がないICPを対象としています。このICPは、既存のIPv4サービス上に構築するためにデュアルスタックモデルを好む可能性があります。
Due to the widespread impact of supporting IPv6 everywhere within an environment, it is important to select a focused initial approach based on clear business needs and real technical dependencies.
環境内のあらゆる場所でIPv6をサポートすることの影響が広範囲に及ぶため、明確なビジネスニーズと実際の技術的な依存関係に基づいて、焦点を絞った初期アプローチを選択することが重要です。
Within the dual-stack model, two approaches could be adopted, sometimes referred to as "outside in" and "inside out":
デュアルスタックモデル内では、「アウトサイドイン」と「インサイドアウト」と呼ばれることもある2つのアプローチを採用できます。
o Outside in: Start by providing external users with an IPv6 public access to your services, for example, by running a reverse proxy that handles IPv6 customers (see Section 7 for details). Progressively enable IPv6 internally.
o 外部：IPv6の顧客を処理するリバースプロキシを実行するなど、外部ユーザーにサービスへのIPv6パブリックアクセスを提供することから始めます（詳細はセクション7を参照）。内部でIPv6を段階的に有効にします。
o Inside out: Start by enabling internal networking infrastructure, hosts, and applications to support IPv6. Progressively reveal IPv6 access to external customers.
o 裏返し：まず、内部ネットワークインフラストラクチャ、ホスト、およびアプリケーションがIPv6をサポートできるようにします。外部顧客へのIPv6アクセスを徐々に明らかにします。
Which of these approaches to choose depends on the precise circumstances of the ICP concerned. "Outside in" has the benefit of giving interested customers IPv6 access at an early stage, and thereby gaining precious operational experience, before meticulously updating every piece of equipment and software. For example, if some back-office system that is never exposed to users only supports IPv4, it will not cause delay. "Inside out" has the benefit of completing the implementation of IPv6 as a single project. Any ICP could choose this approach, but it might be most appropriate for a small ICP without complex back-end systems.
これらのアプローチのどれを選択するかは、関係するICPの正確な状況によって異なります。 「アウトサイドイン」には、関心のあるお客様に初期段階でIPv6アクセスを提供し、すべての機器とソフトウェアを細心の注意を払って更新する前に貴重な運用経験を得るという利点があります。たとえば、ユーザーに公開されないバックオフィスシステムがIPv4のみをサポートする場合、遅延は発生しません。 「裏返し」には、IPv6の実装を1つのプロジェクトとして完了するという利点があります。どのICPでもこのアプローチを選択できますが、複雑なバックエンドシステムがない小規模なICPに最適です。
A point that must be considered in the strategy is that some customers will remain IPv4-only for many years, others will have both IPv4 and IPv6 access, and yet others will have only IPv6. Additionally, mobile customers may find themselves switching between IPv4 and IPv6 access as they travel, even within a single session.
戦略で考慮しなければならない点は、一部の顧客は長年にわたってIPv4のみのままであり、他の顧客はIPv4とIPv6の両方のアクセスを持ち、他の顧客はIPv6のみを持つということです。さらに、モバイルのお客様は、1つのセッション内でも、移動中にIPv4アクセスとIPv6アクセスを切り替えることがあります。
Services and applications must be able to deal with this, just as easily as they deal today with a user whose IPv4 address changes (see the discussion of cookies in Section 8.2).
サービスとアプリケーションは、IPv4アドレスが変更されたユーザーを今日扱うのと同じくらい簡単にこれに対処できなければなりません（セクション8.2のCookieの説明を参照）。
Nevertheless, the end goal is to have a network that does not need major changes when at some point in the future it becomes possible to transition to IPv6-only, even if only for some parts of the network. That is, the IPv6 deployment should be designed in such a way as to more or less assume that IPv4 is already absent, so the network will function seamlessly when it is indeed no longer there.
それにもかかわらず、最終的な目標は、将来のある時点で、たとえネットワークの一部であっても、IPv6のみに移行できるようになったときに大きな変更を必要としないネットワークを持つことです。つまり、IPv6の展開は、IPv4がすでに存在しないと多かれ少なかれ想定するように設計する必要があります。これにより、ネットワークは実際には存在しなくてもシームレスに機能します。
An important step in the strategy is to determine from hardware and software suppliers details of their planned dates for providing sufficient IPv6 support, with performance equivalent to IPv4, in their products and services. Relevant specifications such as [RFC6434] and [IPv6-CE-REQS] should be used. Even if complete information cannot be obtained, it is essential to determine which components are on the critical path during successive phases of deployment. This information will make it possible to draw up a logical sequence of events and identify any components that may cause holdups.
戦略の重要なステップは、ハードウェアおよびソフトウェアサプライヤーから、製品およびサービスにおいてIPv4と同等のパフォーマンスで十分なIPv6サポートを提供するための計画日の詳細を決定することです。 [RFC6434]や[IPv6-CE-REQS]などの関連仕様を使用する必要があります。完全な情報を取得できない場合でも、展開の連続フェーズ中にクリティカルパス上にあるコンポーネントを特定することが重要です。この情報により、イベントの論理シーケンスを作成し、停滞を引き起こす可能性のあるコンポーネントを特定することができます。
Some staff may have experience running multiprotocol networks, which were common twenty years ago before the dominance of IPv4. However, IPv6 will be new to them and also to staff brought up only on TCP/IP. It is not enough to have one "IPv6 expert" in a team. On the contrary, everybody who knows about IPv4 needs to know about IPv6, from network architect to help desk responder. Therefore, an early and essential part of the strategy must be education, including practical training, so that all staff acquire a general understanding of IPv6, how it affects basic features such as the DNS, and the relevant practical skills. To take a trivial example, any staff used to dotted-decimal IPv4 addresses need to become familiar with the colon-hexadecimal format used for IPv6.
一部のスタッフは、IPv4が普及する前の20年前に一般的であったマルチプロトコルネットワークの実行経験がある場合があります。ただし、IPv6は彼らにとっても、TCP / IPだけで育ったスタッフにとっても新しいものです。チームに1人の「IPv6エキスパート」がいるだけでは十分ではありません。逆に、IPv4について知っている人は、ネットワークアーキテクトからヘルプデスクレスポンダーまで、IPv6について知る必要があります。したがって、すべてのスタッフがIPv6の一般的な理解、それがDNSなどの基本機能にどのように影響するか、および関連する実践的なスキルを習得できるように、戦略の初期の不可欠な部分は実践的なトレーニングを含む教育である必要があります。簡単な例をとるには、ドット付き10進数のIPv4アドレスに慣れているスタッフは、IPv6に使用されるコロン16進形式に慣れる必要があります。
There is an anecdote of one IPv6 deployment in which prefixes including the letters A to F were avoided by design, to avoid confusing system administrators unfamiliar with hexadecimal notation. This is not a desirable result. There is another anecdote of a help desk responder telling a customer to "disable one-Pv6" in order to solve a problem. It should be a goal to avoid having untrained staff who don't understand hexadecimal or who can't even spell "IPv6".
16進表記に慣れていないシステム管理者を混乱させないために、AからFまでの文字を含むプレフィックスが意図的に回避された1つのIPv6展開の逸話があります。これは望ましい結果ではありません。問題を解決するために「one-Pv6を無効にする」ように顧客に指示するヘルプデスクレスポンダーの別の逸話があります。 16進数を理解していない、または「IPv6」のスペルすらできないトレーニングを受けていないスタッフがいないようにすることが目標です。
It is very useful to have a small laboratory network available for training and self-training in IPv6, where staff may experiment and make mistakes without disturbing the operational IPv4 service. This lab should run both IPv4 and IPv6, to gain experience with a dual-stack environment and new features such as having multiple addresses per interface, and addresses with lifetimes and deprecation.
スタッフがIPv4の運用サービスを妨害することなく実験し、間違いを犯す可能性があるIPv6でのトレーニングとセルフトレーニングに使用できる小規模なラボネットワークがあると非常に便利です。このラボでは、IPv4とIPv6の両方を実行して、デュアルスタック環境の経験と、インターフェイスごとに複数のアドレスを使用するなどの新機能、ライフタイムと非推奨のアドレスを取得する必要があります。
Once staff are trained, they will likely need to support IPv4, IPv6, and dual-stack customers. Rather than having separate internal escalation paths for IPv6, it generally makes sense for questions that may have an IPv6 element to follow normal escalation paths; there should not be an "IPv6 Department" once training is completed.
トレーニングを受けたスタッフは、IPv4、IPv6、およびデュアルスタックの顧客をサポートする必要があるでしょう。 IPv6の個別のエスカレーションパスを用意するのではなく、通常、IPv6要素を含む可能性のある質問が通常のエスカレーションパスをたどるのは理にかなっています。トレーニングが完了したら、「IPv6部門」は存在しないはずです。
A final remark about training is that it should not be given too soon, or it will be forgotten. Training has a definite need to be done "just in time" in order to properly "stick". Training, lab experience, and actual deployment should therefore follow each other immediately. If possible, training should even be combined with actual operational experience.
トレーニングについての最後の発言は、それがあまりにも早く与えられるべきではない、またはそれは忘れられるだろうということです。適切に「固定」するには、トレーニングを「ジャストインタイム」で行う必要があります。したがって、トレーニング、ラボでの経験、および実際の展開は、すぐに互いに従う必要があります。可能であれば、トレーニングは実際の運用経験と組み合わせる必要があります。
There are, in theory, two ways to obtain IPv6 connectivity to the Internet.
理論的には、インターネットへのIPv6接続を取得するには2つの方法があります。
o Native. In this case, the ISP simply provides IPv6 on exactly the same basis as IPv4 -- it will appear at the ICP's border router(s), which must then be configured in dual-stack mode to forward IPv6 packets in both directions. This is by far the better method. An ICP should contact all its ISPs to verify when they will provide native IPv6 support, whether this has any financial implications, and whether the same service level agreement will apply as for IPv4. Any ISP that has no definite plan to offer native IPv6 service should be avoided.
o ネイティブ。この場合、ISPはIPv4とまったく同じ基準でIPv6を提供するだけです-それはICPの境界ルーターに表示され、双方向スタックモードでIPv6パケットを転送するように構成する必要があります。これは断然良い方法です。 ICPは、すべてのISPに連絡して、ネイティブIPv6サポートをいつ提供するか、これが経済的に影響するかどうか、IPv4と同じサービスレベル契約が適用されるかどうかを確認する必要があります。ネイティブIPv6サービスを提供する明確な計画がないISPは避けてください。
o Managed Tunnel. It is possible to configure an IPv6-in-IPv4 tunnel to a remote ISP that offers such a service. A dual-stack router in the ICP's network will act as a tunnel endpoint, or this function could be included in the ICP's border router.
o マネージドトンネル。このようなサービスを提供するリモートISPへのIPv6-in-IPv4トンネルを構成することが可能です。 ICPのネットワーク内のデュアルスタックルーターがトンネルエンドポイントとして機能するか、この機能をICPの境界ルーターに含めることができます。
A managed tunnel is a reasonable way to obtain IPv6 connectivity for initial testing and skills acquisition. However, it introduces an inevitable extra latency compared to native IPv6, giving customers a noticeably worse response time for complex web pages. A tunnel may become a performance bottleneck (especially if offered as a free service) or a target for malicious attack.
マネージドトンネルは、初期テストとスキル習得のためにIPv6接続を取得するための合理的な方法です。ただし、ネイティブIPv6に比べて必然的に余分なレイテンシが発生し、複雑なWebページの応答時間が著しく悪化します。トンネルは、パフォーマンスのボトルネック（特に無料サービスとして提供されている場合）または悪意のある攻撃の標的になる可能性があります。
It is also likely to limit the IPv6 MTU size. In normal circumstances, native IPv6 will provide an MTU size of at least 1500 bytes, but it will almost inevitably be less for a tunnel, possibly as low as 1280 bytes (the minimum MTU allowed for IPv6). Apart from the resulting loss of efficiency, there are cases in which Path MTU Discovery fails and IPv6 fragmentation therefore fails; in this case, the lower tunnel MTU will actually cause connectivity failures for customers.
また、IPv6 MTUサイズを制限する可能性もあります。通常の状況では、ネイティブIPv6は少なくとも1500バイトのMTUサイズを提供しますが、トンネルではほぼ必然的に小さくなり、おそらく1280バイト（IPv6で許可される最小MTU）まで低くなります。結果として生じる効率の損失とは別に、パスMTUディスカバリーが失敗し、IPv6フラグメンテーションが失敗する場合があります。この場合、トンネルのMTUが低いと、実際には顧客に接続障害が発生します。
For these reasons, ICPs are strongly recommended to obtain native IPv6 service before attempting to offer a production-quality service to their customers. Unfortunately, it is impossible to prevent customers from using unmanaged tunnel solutions (see Section 9).
これらの理由から、ICPは、本番品質のサービスを顧客に提供する前に、ネイティブIPv6サービスを取得することを強くお勧めします。残念ながら、お客様が管理されていないトンネルソリューションを使用できないようにすることは不可能です（セクション9を参照）。
Some larger organizations may find themselves needing multiple forms of IPv6 connectivity, for their ICP data centers and for their staff working elsewhere. It is important to obtain IPv6 connectivity for both, as testing and supporting an IPv6-enabled service is challenging for staff without IPv6 connectivity. This may involve short-term alternatives to provide IPv6 connectivity to operations and support staff, such as a managed tunnel or HTTP proxy server with IPv6 connectivity. Note that unmanaged tunnels (such as 6to4 and Teredo) are generally not useful for support staff, as recent client software will avoid them when accessing dual-stack sites.
大規模な組織の中には、ICPデータセンターや他の場所で働くスタッフのために、複数の形式のIPv6接続が必要になる場合があります。 IPv6対応サービスのテストとサポートは、IPv6接続のないスタッフにとって困難であるため、両方のIPv6接続を取得することが重要です。これには、IPv6接続を備えたマネージドトンネルまたはHTTPプロキシサーバーなど、運用およびサポートスタッフにIPv6接続を提供する短期的な代替手段が含まれる場合があります。管理されていないトンネル（6to4やTeredoなど）は、デュアルスタックサイトにアクセスするときに最近のクライアントソフトウェアによって回避されるため、通常、サポートスタッフには役立ちません。
An ICP must first decide whether to apply for its own Provider Independent (PI) address prefix for IPv6. This option is available either from an ISP that acts as a Local Internet Registry or directly from the relevant Regional Internet Registry. The alternative is to obtain a Provider Aggregated (PA) prefix from an ISP. Both solutions are viable in IPv6. However, the scaling properties of the wide-area routing system (BGP-4) mean that the number of PI prefixes should be limited, so only large content providers can justify obtaining a PI prefix and convincing their ISPs to route it. Millions of enterprise networks, including smaller content providers, will use PA prefixes. In this case, a change of ISP would necessitate a change of the corresponding PA prefix, using the procedure outlined in [RFC4192].
ICPはまず、IPv6の独自のプロバイダー独立（PI）アドレスプレフィックスを適用するかどうかを決定する必要があります。このオプションは、ローカルインターネットレジストリとして機能するISPから、または関連する地域インターネットレジストリから直接利用できます。代替手段は、ISPからプロバイダー集約（PA）プレフィックスを取得することです。どちらのソリューションもIPv6で実行可能です。ただし、広域ルーティングシステム（BGP-4）のスケーリングプロパティは、PIプレフィックスの数を制限する必要があることを意味するため、大規模なコンテンツプロバイダーのみがPIプレフィックスを取得し、ISPにルーティングするよう説得することができます。小規模なコンテンツプロバイダーを含む何百万ものエンタープライズネットワークがPAプレフィックスを使用します。この場合、ISPを変更すると、[RFC4192]で概説されている手順を使用して、対応するPAプレフィックスを変更する必要があります。
An ICP that has connections via multiple ISPs but does not have a PI prefix would therefore have multiple PA prefixes, one from each ISP. This would result in multiple IPv6 addresses for the ICP's servers or load balancers. If one address fails due to an ISP malfunction, sessions using that address would be lost. At the time of this writing, there is very limited operational experience with this approach [MULTIHOMING-WITHOUT-NAT].
したがって、複数のISPを介して接続しているが、PIプレフィックスがないICPには、各ISPから1つずつ、複数のPAプレフィックスがあります。これにより、ICPのサーバーまたはロードバランサーに対して複数のIPv6アドレスが発生します。 ISPの誤動作により1つのアドレスに障害が発生した場合、そのアドレスを使用するセッションは失われます。この記事の執筆時点では、このアプローチの運用経験は非常に限られています[MULTIHOMING-WITHOUT-NAT]。
An ICP may also choose to operate a Unique Local Address prefix [RFC4193] for internal traffic only, as described in [RFC4864].
[RFC4864]で説明されているように、ICPは内部トラフィックに対してのみ一意のローカルアドレスプレフィックス[RFC4193]を操作することも選択できます。
Depending on its projected future size, an ICP might choose to obtain /48 PI or PA prefixes (allowing 16 bits of subnet address) or longer PA prefixes, e.g., /56 (allowing 8 bits of subnet address). Clearly, the choice of /48 is more future-proof. Advice on the numbering of subnets may be found in [RFC5375]. An ICP with multiple locations will probably need a prefix per location.
予測される将来のサイズに応じて、ICPは/ 48 PIまたはPAプレフィックス（16ビットのサブネットアドレスを許可）またはより長いPAプレフィックス、たとえば/ 56（8ビットのサブネットアドレスを許可）を取得することを選択する場合があります。明らかに、/ 48を選択する方が将来性があります。サブネットの番号付けに関するアドバイスは[RFC5375]にあります。複数の場所を持つICPでは、場所ごとにプレフィックスが必要になる可能性があります。
An ICP that has its service hosted by a colocation provider, cloud provider, or the like will need to follow the addressing policy of that provider.
コロケーションプロバイダー、クラウドプロバイダーなどによってサービスがホストされているICPは、そのプロバイダーのアドレス指定ポリシーに従う必要があります。
Since IPv6 provides for operating multiple prefixes simultaneously, it is important to check that all relevant tools, such as address management packages, can deal with this. In particular, the possible need to allow for multiple PA prefixes with IPv6, and the possible need to renumber, mean that the common technique of manually assigned static addresses for servers, proxies, or load balancers, with statically defined DNS entries, could be problematic [RFC6866]. An ICP of reasonable size might instead choose to operate DHCPv6 [RFC3315] with standard DNS, to support stateful assignment. In either case, a configuration management system is likely to be used to support stateful and/or on-demand address assignment.
IPv6では複数のプレフィックスを同時に操作できるため、アドレス管理パッケージなどの関連するすべてのツールがこれに対応できることを確認することが重要です。特に、IPv6で複数のPAプレフィックスを可能にする必要がある可能性、および番号を再設定する必要がある可能性は、静的に定義されたDNSエントリを使用して、サーバー、プロキシ、またはロードバランサーに手動で静的アドレスを割り当てる一般的な手法が問題になる可能性があることを意味します[RFC6866]。妥当なサイズのICPは、代わりに標準DNSでDHCPv6 [RFC3315]を操作して、ステートフル割り当てをサポートすることを選択する場合があります。どちらの場合でも、構成管理システムは、ステートフルおよび/またはオンデマンドのアドレス割り当てをサポートするために使用される可能性があります。
Theoretically, it would also be possible to operate an ICP's IPv6 network using only Stateless Address Autoconfiguration [RFC4862], with Dynamic DNS [RFC3007] to publish server addresses for external users.
理論的には、ステートレスアドレス自動構成[RFC4862]のみを使用してICPのIPv6ネットワークを運用し、動的DNS [RFC3007]を使用して外部ユーザーのサーバーアドレスを公開することもできます。
In a dual-stack network, most IPv4 and IPv6 interior routing protocols operate quite independently and in parallel. The common routing protocols, such as OSPFv3 [RFC5340], IS-IS [RFC5308], and even the Routing Information Protocol Next Generation (RIPng) [RFC2080] [RFC2081], all support IPv6. It is worth noting that whereas OSPF and RIP differ significantly between IPv4 and IPv6, IS-IS has the advantage of handling them both in a single instance of the protocol, with the potential for operational simplification in the long term. Some versions of OSPFv3 may also have this advantage [RFC5838]. In any case, for trained staff, there should be no particular difficulty in deploying IPv6 routing without disturbance to IPv4 services. In some cases, firmware upgrades may be needed on some network devices.
デュアルスタックネットワークでは、ほとんどのIPv4およびIPv6内部ルーティングプロトコルは、非常に独立して並行して動作します。 OSPFv3 [RFC5340]、IS-IS [RFC5308]、Routing Information Protocol Next Generation（RIPng）[RFC2080] [RFC2081]などの一般的なルーティングプロトコルはすべて、IPv6をサポートしています。 OSPFとRIPはIPv4とIPv6で大きく異なりますが、IS-ISにはプロトコルの単一インスタンスで両方を処理できるという利点があり、長期的には運用が簡素化される可能性があります。 OSPFv3の一部のバージョンにもこの利点があります[RFC5838]。いずれにせよ、訓練を受けたスタッフにとって、IPv4サービスに支障をきたすことなくIPv6ルーティングを展開することは特に困難ではありません。場合によっては、一部のネットワークデバイスでファームウェアのアップグレードが必要になることがあります。
The performance impact of dual-stack routing needs to be evaluated. In particular, what forwarding performance does the router vendor claim for IPv6? If the forwarding performance is significantly inferior compared to IPv4, will this be an operational problem? Is extra memory or ternary content-addressable memory (TCAM) space needed to accommodate both IPv4 and IPv6 tables? To answer these questions, the ICP will need a projected model for the amount of IPv6 traffic expected initially and its likely rate of increase.
デュアルスタックルーティングのパフォーマンスへの影響を評価する必要があります。特に、ルーターベンダーはIPv6に対してどのような転送パフォーマンスを要求していますか？転送パフォーマンスがIPv4と比較して著しく劣っている場合、これは運用上の問題でしょうか？ IPv4テーブルとIPv6テーブルの両方に対応するために、追加のメモリまたはTernary Content-Addressable Memory（TCAM）スペースが必要ですか？これらの質問に答えるために、ICPは最初に予想されるIPv6トラフィックの量とその増加率の予測モデルが必要になります。
If a site has multiple PA prefixes as mentioned in Section 5.1, complexities in routing configuration will appear. In particular, source-based routing rules might be needed to ensure that outgoing packets are routed to the appropriate border router and ISP link. Normally, a packet sourced from an address assigned by ISP X should not be sent via ISP Y, to avoid ingress filtering by Y [RFC2827] [RFC3704]. Additional considerations may be found in [MULTIHOMING-WITHOUT-NAT]. Note that the prefix translation technique discussed in [RFC6296] does not describe a solution for enterprises that offer publicly available content servers.
セクション5.1で説明したように、サイトに複数のPAプレフィックスがある場合、ルーティング構成が複雑になります。特に、発信パケットが適切な境界ルーターとISPリンクに確実にルーティングされるように、ソースベースのルーティングルールが必要になる場合があります。通常、ISP Xによって割り当てられたアドレスから送信されたパケットは、Yによる進入フィルタリングを回避するために、ISP Yを介して送信するべきではありません[RFC2827] [RFC3704]。追加の考慮事項は、[MULTIHOMING-WITHOUT-NAT]にあります。 [RFC6296]で説明されているプレフィックス変換手法は、公に利用可能なコンテンツサーバーを提供する企業向けのソリューションを説明していないことに注意してください。
Each IPv6 subnet that supports end hosts normally has a /64 prefix, leaving another 64 bits for the interface identifiers of individual hosts. In contrast, a typical IPv4 subnet will have no more than 8 bits for the host identifier, thus limiting the subnet to 256 or fewer hosts. A dual-stack design will typically use the same physical or VLAN subnet topology for IPv4 and IPv6, and therefore the same router topology. In other words, the IPv4 and IPv6 topologies are congruent. This means that the limited subnet size of IPv4 (such as 256 hosts) will be imposed on IPv6, even though the IPv6 prefix will allow many more hosts. It would be theoretically possible to avoid this limitation by implementing a different physical or VLAN subnet topology for IPv6. This is not advisable, as it would result in extremely complex fault diagnosis when something went wrong.
エンドホストをサポートする各IPv6サブネットには通常/ 64プレフィックスがあり、個々のホストのインターフェイス識別子用にさらに64ビットを残します。対照的に、典型的なIPv4サブネットはホスト識別子に8ビットを超えないため、サブネットは256以下のホストに制限されます。デュアルスタック設計では、通常、IPv4とIPv6で同じ物理トポロジまたはVLANサブネットトポロジを使用するため、同じルータートポロジを使用します。つまり、IPv4トポロジとIPv6トポロジは一致しています。これは、IPv6プレフィックスでさらに多くのホストを許可する場合でも、IPv4の制限されたサブネットサイズ（256ホストなど）がIPv6に課されることを意味します。 IPv6に対して別の物理トポロジまたはVLANサブネットトポロジを実装することで、この制限を回避することは理論的には可能です。何か問題が発生した場合、非常に複雑な障害診断が行われるため、これはお勧めできません。
It must be understood that as soon as a AAAA record for a well-known name is published in the DNS, the corresponding server will start to receive IPv6 traffic. Therefore, it is essential that an ICP test thoroughly to ensure that IPv6 works on its servers, load balancers, etc., before adding their AAAA records to DNS. There have been numerous cases of ICPs breaking their sites for all IPv6 users during a roll-out by returning AAAA records for servers improperly configured for IPv6.
既知の名前のAAAAレコードがDNSで公開されるとすぐに、対応するサーバーがIPv6トラフィックの受信を開始することを理解する必要があります。したがって、AAPレコードをDNSに追加する前に、ICPが徹底的にテストして、IPv6がサーバー、ロードバランサーなどで動作することを確認することが不可欠です。 ICPがIPv6用に正しく構成されていないサーバーのAAAAレコードを返すことにより、ロールアウト中にすべてのIPv6ユーザーのサイトを破壊する多くの事例がありました。
Once such tests have succeeded, each externally visible host (or virtual host) that has an A record for its IPv4 address needs a AAAA record [RFC3596] for its IPv6 address, and a reverse entry (in ip6.arpa) if applicable. Note that if CNAME records are in use, the AAAA record must be added alongside the A record at the end of the CNAME chain. It is not possible to have the AAAA record on the same name as used for a CNAME record, as per [RFC1912].
このようなテストが成功すると、IPv4アドレスのAレコードを持つ外部から見える各ホスト（または仮想ホスト）には、IPv6アドレスのAAAAレコード[RFC3596]と、該当する場合は（ip6.arpaの）逆エントリが必要です。 CNAMEレコードを使用している場合は、AAAAレコードをCNAMEチェーンの最後にあるAレコードと一緒に追加する必要があることに注意してください。 [RFC1912]のように、AAAAレコードをCNAMEレコードに使用されているのと同じ名前にすることはできません。
One important detail is that some clients (especially Windows XP) can only resolve DNS names via IPv4, even if they can use IPv6 for application traffic. Also, a dual-stack resolver might attempt to resolve queries for A records via IPv6, or AAAA records via IPv4. It is therefore advisable for all DNS servers to respond to queries via both IPv4 and IPv6.
重要な点の1つは、一部のクライアント（特にWindows XP）は、アプリケーショントラフィックにIPv6を使用できる場合でも、IPv4経由でしかDNS名を解決できないことです。また、デュアルスタックリゾルバーは、IPv6を介したAレコードまたはIPv4を介したAAAAレコードのクエリを解決しようとする場合があります。したがって、すべてのDNSサーバーがIPv4とIPv6の両方を介してクエリに応答することをお勧めします。
Most available load balancers now support IPv6. However, it is important to obtain appropriate assurances from vendors about their IPv6 support, including performance aspects (as discussed for routers in Section 5.2). The update needs to be planned in anticipation of expected traffic growth. It is to be expected that IPv6 traffic will initially be low, i.e., a small but growing percentage of total traffic. For this reason, it might be acceptable to have IPv6 traffic bypass load balancing initially, by publishing a AAAA record for a specific server instead of the load balancer. However, load balancers often also provide for server fail-over, in which case it would be better to implement IPv6 load balancing immediately.
利用可能なほとんどのロードバランサーがIPv6をサポートするようになりました。ただし、IPv6のサポートについて、ベンダーから適切な保証を取得することが重要です（セクション5.2でルーターについて説明したとおり）。アップデートは、予想されるトラフィックの増加を見込んで計画する必要があります。 IPv6トラフィックは最初は低い、つまり、総トラフィックの割合はわずかですが増加することが予想されます。このため、ロードバランサーの代わりに特定のサーバーのAAAAレコードを公開することにより、最初にIPv6トラフィックがロードバランシングをバイパスすることが許容される場合があります。ただし、多くの場合、ロードバランサーはサーバーのフェールオーバーも提供します。この場合、IPv6ロードバランシングをすぐに実装する方が適切です。
The same would apply to Transport Layer Security (TLS) or HTTP proxies used for load-balancing purposes.
同じことが、負荷分散の目的で使用されるトランスポート層セキュリティ（TLS）またはHTTPプロキシにも当てはまります。
An HTTP proxy [RFC2616] can readily be configured to handle incoming connections over IPv6 and to proxy them to a server over IPv4. Therefore, a single proxy can be used as the first step in an outside-in strategy, as shown in the following diagram:
HTTPプロキシ[RFC2616]は、IPv6を介して着信接続を処理し、それらをIPv4を介してサーバーにプロキシするように簡単に構成できます。したがって、次の図に示すように、外部プロキシ戦略の最初のステップとして単一のプロキシを使用できます。
___________________________________________
( )
( IPv6 Clients in the Internet )
(___________________________________________)
|
-------------
| Ingress |
| router |
-------------
____________|_____________
|
-------------
| IPv6 stack|
|-----------|
| HTTP proxy|
|-----------|
| IPv4 stack|
-------------
____________|_____________
|
-------------
| IPv4 stack|
|-----------|
| HTTP |
| server |
-------------
In this case, the AAAA record for the service would provide the IPv6 address of the proxy. This approach will work for any HTTP or HTTPS applications that operate successfully via a proxy, as long as IPv6 load remains low. Additionally, many load-balancer products incorporate such a proxy, in which case this approach would be possible at high load.
この場合、サービスのAAAAレコードはプロキシのIPv6アドレスを提供します。このアプローチは、IPv6の負荷が低いままである限り、プロキシ経由で正常に動作するHTTPまたはHTTPSアプリケーションで機能します。さらに、多くのロードバランサー製品にはこのようなプロキシが組み込まれています。この場合、このアプローチは高負荷時に可能です。
Note that in any proxy scenario, an ICP will need to make sure that both IPv4 and IPv6 addresses are being properly passed to application servers in any relevant HTTP headers and that those application servers are properly handling the IPv6 addresses.
どのプロキシシナリオでも、ICPはIPv4とIPv6の両方のアドレスが関連するHTTPヘッダーでアプリケーションサーバーに適切に渡され、それらのアプリケーションサーバーがIPv6アドレスを適切に処理していることを確認する必要があることに注意してください。
The TCP/IP network stacks in popular operating systems have supported IPv6 for many years. In most cases, it is sufficient to enable IPv6 and possibly DHCPv6; the rest will follow. Servers inside an ICP network will not need to support any transition technologies beyond a simple dual stack, with a possible exception for 6to4 mitigation noted below in Section 9.
一般的なオペレーティングシステムのTCP / IPネットワークスタックは、長年にわたってIPv6をサポートしてきました。ほとんどの場合、IPv6とDHCPv6を有効にするだけで十分です。残りは続きます。 ICPネットワーク内のサーバーは、以下のセクション9に記載されている6to4緩和策の例外を除いて、単純なデュアルスタック以外の移行テクノロジをサポートする必要はありません。
As some operating systems have separate firewall rule sets for IPv4 and IPv6, an ICP should also evaluate those rule sets and ensure that appropriate firewall rules are configured for IPv6. More details are discussed in Section 14.
一部のオペレーティングシステムにはIPv4とIPv6に個別のファイアウォールルールセットがあるため、ICPはそれらのルールセットも評価し、適切なファイアウォールルールがIPv6用に構成されていることを確認する必要があります。詳細については、セクション14で説明します。
Basic HTTP servers have been able to handle an IPv6-enabled network stack for some years, so at the most it will be necessary to update to a more recent software version. The same is true of generic applications such as email protocols. No general statement can be made about other applications, especially proprietary ones, so each ASP will need to make its own determination. As changes to the network layer to introduce IPv6 addresses can ripple through applications, testing of both client and server applications should be performed in IPv4-only, IPv6-only, and dual-stack environments prior to dual-stacking a production environment.
基本的なHTTPサーバーは、IPv6対応のネットワークスタックを数年間処理できるため、せいぜい最新のソフトウェアバージョンに更新する必要があります。電子メールプロトコルなどの一般的なアプリケーションについても同様です。他のアプリケーション、特にプロプライエタリなアプリケーションについては一般的な説明ができないため、各ASPは独自に決定する必要があります。 IPv6アドレスを導入するためのネットワーク層への変更はアプリケーション全体に波及する可能性があるため、本番環境をデュアルスタックする前に、クライアントアプリケーションとサーバーアプリケーションの両方のテストをIPv4のみ、IPv6のみ、およびデュアルスタック環境で実行する必要があります。
One important recommendation here is that all applications should use domain names, which are IP-version-independent, rather than IP addresses. Applications based on middleware platforms that have uniform support for IPv4 and IPv6, for example, Java, may be able to support both IPv4 and IPv6 naturally without additional work. Security certificates should also contain domain names rather than addresses.
ここで重要な推奨事項の1つは、すべてのアプリケーションがIPアドレスではなく、IPバージョンに依存しないドメイン名を使用することです。 IPv4とIPv6を統一的にサポートするミドルウェアプラットフォームに基づくアプリケーション（Javaなど）は、追加の作業を行わなくても、IPv4とIPv6の両方を自然にサポートできる場合があります。セキュリティ証明書には、アドレスではなくドメイン名も含める必要があります。
A specific issue for HTTP-based services is that IP address-based cookie authentication schemes will need to deal with dual-stack clients. Servers might create a cookie for an IPv4 connection or an IPv6 connection, depending on the setup at the client site and on the whims of the client operating system. There is no guarantee that a given client will consistently use the same address family, especially when accessing a collection of sites rather than a single site, such as when cookies are used for federated authentication. If the client is using privacy addresses [RFC4941], the IPv6 address (but usually not its /64 prefix) might change quite frequently. Any cookie mechanism based on 32-bit IPv4 addresses will need significant remodeling.
HTTPベースのサービスに固有の問題は、IPアドレスベースのCookie認証方式がデュアルスタッククライアントを処理する必要があることです。サーバーは、クライアントサイトでの設定とクライアントオペレーティングシステムの気まぐれに応じて、IPv4接続またはIPv6接続のCookieを作成する場合があります。特にフェデレーション認証にCookieが使用されている場合など、単一のサイトではなくサイトのコレクションにアクセスする場合、特定のクライアントが常に同じアドレスファミリを使用するという保証はありません。クライアントがプライバシーアドレス[RFC4941]を使用している場合、IPv6アドレス（通常は/ 64プレフィックスではない）が頻繁に変更される可能性があります。 32ビットIPv4アドレスに基づくCookieメカニズムは、大幅な改造が必要になります。
Generic considerations on application transition are discussed in [RFC4038], but many of them will not apply to the dual-stack ICP scenario. An ICP that creates and maintains its own applications will need to review them for any dependency on IPv4.
アプリケーションの移行に関する一般的な考慮事項は[RFC4038]で説明されていますが、それらの多くはデュアルスタックICPシナリオには適用されません。独自のアプリケーションを作成および保守するICPは、IPv4への依存性についてそれらを確認する必要があります。
The introduction of IPv6 clients will generally also result in IPv6 addresses appearing in the "client ip" field of server logs. It might be convenient to use the same log field to hold a client's IP address, whether it is IPv4 or IPv6. Downstream systems looking at logs and client IP addresses may also need testing to ensure that they can properly handle IPv6 addresses. This includes any of an ICP's databases recording client IP addresses, such as for recording IP addresses of online purchases and comment posters.
IPv6クライアントの導入により、通常、サーバーログの「クライアントIP」フィールドにIPv6アドレスが表示されます。 IPv4であれIPv6であれ、同じログフィールドを使用してクライアントのIPアドレスを保持すると便利な場合があります。ログとクライアントIPアドレスを確認するダウンストリームシステムも、IPv6アドレスを適切に処理できることを確認するためのテストが必要になる場合があります。これには、オンライン購入やコメント投稿者のIPアドレスを記録するためなど、クライアントIPアドレスを記録するICPのデータベースが含まれます。
It is worth noting that accurate traceback from logs to individual customers requires end-to-end address transparency. This is additional motivation for an ICP to support native IPv6 connectivity, since otherwise, IPv6-only customers will inevitably connect via some form of translation mechanism, interfering with traceback.
ログから個々の顧客への正確なトレースバックには、エンドツーエンドのアドレス透過性が必要であることは注目に値します。これは、ICPがネイティブIPv6接続をサポートするための追加の動機です。それ以外の場合、IPv6のみの顧客は、何らかの形式の変換メカニズムを介して接続し、トレースバックを妨害するためです。
Initially, ICPs may observe some weakness in geolocation for IPv6 clients. As time goes on, it is to be assumed that geolocation methods and databases will be updated to fully support IPv6 prefixes. There is no reason they will be more or less accurate in the long term than those available for IPv4. However, we can expect many more clients to be mobile as time goes on, so geolocation based on IP addresses alone may in any case become problematic. A more robust technique such as HTTP-Enabled Location Delivery (HELD) [RFC5985] could be considered.
最初に、ICPはIPv6クライアントの地理位置情報の弱点を観察する可能性があります。時間が経つにつれ、地理位置情報メソッドとデータベースはIPv6プレフィックスを完全にサポートするように更新されると想定されています。それらがIPv4で利用可能なものよりも長期的に多かれ少なかれ正確である理由はありません。ただし、時間の経過とともに、より多くのクライアントがモバイルになることが予想されるため、IPアドレスのみに基づく地理位置情報は、いずれにせよ問題となる可能性があります。 HTTP対応のロケーション配信（HELD）[RFC5985]などのより堅牢な手法を検討できます。
As mentioned above, an ICP should obtain native IPv6 connectivity from its ISPs. In this way, the ICP can avoid most of the complexities of the numerous IPv4-to-IPv6 transition technologies that have been developed; they are all second-best solutions. However, some clients are sure to be using such technologies. An ICP needs to be aware of the operational issues this may cause and how to deal with them.
上記のように、ICPはISPからネイティブIPv6接続を取得する必要があります。このようにして、ICPは、開発された多数のIPv4からIPv6への移行テクノロジの複雑さのほとんどを回避できます。これらはすべて2番目に優れたソリューションです。ただし、一部のクライアントはこのようなテクノロジーを使用しているはずです。 ICPは、これによって引き起こされる可能性のある運用上の問題と、それらの対処方法を認識する必要があります。
In some cases outside the ICP's control, clients might reach a content server via a network-layer translator from IPv6 to IPv4. ICPs who are offering a dual-stack service and providing both A and AAAA records, as recommended in this document, should not normally receive IPv4 traffic from NAT64 translators [RFC6146]. Exceptionally, however, such traffic could arrive via IPv4 from an IPv6-only client whose DNS resolver failed to receive the ICP's AAAA record for some reason. Such traffic would be indistinguishable from regular IPv4-via-NAT traffic.
ICPの制御の及ばない場合には、クライアントはIPv6からIPv4へのネットワーク層トランスレーターを介してコンテンツサーバーに到達する可能性があります。このドキュメントで推奨されているように、デュアルスタックサービスを提供し、AレコードとAAAAレコードの両方を提供するICPは、通常、NAT64トランスレータからIPv4トラフィックを受信するべきではありません[RFC6146]。ただし、例外として、そのようなトラフィックは、何らかの理由でDNSリゾルバーがICPのAAAAレコードを受信できなかったIPv6のみのクライアントからIPv4経由で到着する可能性があります。このようなトラフィックは、通常のIPv4-via-NATトラフィックと区別できません。
Alternatively, ICPs who are offering a dual-stack service might exceptionally receive IPv6 traffic translated from an IPv4-only client that somehow failed to receive the ICP's A record. An ICP could also receive IPv6 traffic with translated prefixes [RFC6296]. These two cases would only be an issue if the ICP was offering any service that depends on the assumption of end-to-end IPv6 address transparency.
または、デュアルスタックサービスを提供しているICPは、ICPのAレコードの受信に失敗したIPv4専用クライアントから変換されたIPv6トラフィックを例外的に受信する可能性があります。 ICPは、変換されたプレフィックスを持つIPv6トラフィックを受信することもできます[RFC6296]。これら2つのケースは、ICPがエンドツーエンドのIPv6アドレスの透過性の想定に依存するサービスを提供している場合にのみ問題になります。
Finally, some traffic might reach an ICP that has been translated twice en route (e.g., from IPv6 to IPv4 and back again). Again, the ICP will be unable to detect this. It is likely that real-time geolocation will be highly inaccurate for such traffic, since it will at best indicate the location of the second translator, which could be very distant from the customer.
最後に、一部のトラフィックは、途中で2度変換されたICPに到達する可能性があります（たとえば、IPv6からIPv4に、またその逆に）。ここでも、ICPはこれを検出できません。リアルタイムのジオロケーションは、顧客から非常に離れている可能性のある2番目のトランスレータの場所を示すため、そのようなトラフィックに対しては非常に不正確である可能性があります。
In other cases, also outside the ICP's control, IPv6 clients may reach the IPv6 Internet via some form of IPv6-in-IPv4 tunnel. In this case, a variety of problems can arise, the most acute of which affect clients connected using the Anycast 6to4 solution [RFC3068]. Advice on how ICPs may mitigate these 6to4 problems is given in Section 4.5. of [RFC6343]. For the benefit of all tunneled clients, it is essential to verify that Path MTU Discovery works correctly (i.e., the relevant ICMPv6 packets are not blocked) and that the server-side TCP implementation correctly supports the Maximum Segment Size (MSS) negotiation mechanism [RFC2923] for IPv6 traffic.
また、ICPの制御外にあるIPv6クライアントが、何らかのIPv6-in-IPv4トンネルを介してIPv6インターネットに到達する場合もあります。この場合、さまざまな問題が発生する可能性があり、その最も深刻な問題は、Anycast 6to4ソリューション[RFC3068]を使用して接続されたクライアントに影響します。 ICPがこれらの6to4問題をどのように軽減できるかについてのアドバイスは、セクション4.5に記載されています。 [RFC6343]の。すべてのトンネルクライアントの利益のために、パスMTUディスカバリが正しく機能すること（つまり、関連するICMPv6パケットがブロックされないこと）、およびサーバー側のTCP実装が最大セグメントサイズ（MSS）ネゴシエーションメカニズムを正しくサポートしていることを確認することが不可欠です[ RFC2923] IPv6トラフィック用。
Some ICPs have implemented an interim solution to mitigate transition problems by limiting the visibility of their AAAA records to users with validated IPv6 connectivity [RFC6589] (known as "DNS whitelisting"). At the time of this writing, this solution seems to be passing out of use, being replaced by "DNS blacklisting" of customer sites known to have problems with IPv6 connectivity. In the reverse direction, it is worth being aware that some ISPs with significant populations of clients with broken IPv6 setups have begun filtering AAAA record lookups by their clients. None of these solutions are appropriate in the long term.
一部のICPは、検証済みのIPv6接続[RFC6589]（ "DNSホワイトリスト"として知られている）を持つユーザーにAAAAレコードの可視性を制限することにより、移行の問題を軽減する暫定的なソリューションを実装しています。この記事の執筆時点では、このソリューションは使用されなくなっており、IPv6接続に問題があることがわかっている顧客サイトの「DNSブラックリスト」に置き換えられています。逆の方向では、IPv6設定が壊れているクライアントが多数存在する一部のISPが、クライアントによるAAAAレコードルックアップのフィルタリングを開始していることに注意してください。これらのソリューションはどれも長期的には適切ではありません。
Another approach taken by some ICPs is to offer IPv6-only support via a specific DNS name, e.g., ipv6.example.com, if the primary service is www.example.com. In this case, ipv6.example.com would have a AAAA record only. This has some value for testing purposes but is otherwise only of interest to hobbyist users willing to type in special URLs.
一部のICPで採用されている別のアプローチは、プライマリサービスがwww.example.comの場合、特定のDNS名（たとえば、ipv6.example.com）を介してIPv6のみのサポートを提供することです。この場合、ipv6.example.comにはAAAAレコードのみが含まれます。これは、テスト目的にはある程度の価値がありますが、特別なURLを入力することを希望する趣味のユーザーのみが関心を持つものです。
There is little an ICP can do to deal with client-side or remote ISP deficiencies in IPv6 support, but it is hoped that the "Happy Eyeballs" [RFC6555] approach will improve the ability for clients to deal with such problems.
ICPがIPv6サポートのクライアント側またはリモートISPの欠陥に対処するためにできることはほとんどありませんが、「Happy Eyeballs」[RFC6555]アプローチがクライアントがそのような問題に対処する能力を改善することが望まれます。
DNS-based techniques for diverting users to Content Delivery Network (CDN) points of presence (POPs) will work for IPv6, if AAAA records as well as A records are provided. In general, the CDN should follow the recommendations of this document, especially by operating a full dual-stack service at each POP. Additionally, each POP will need to handle IPv6 routing exactly like IPv4, for example, running BGP-4+ [RFC4760].
AAAAレコードとAレコードが提供されている場合、ユーザーをコンテンツ配信ネットワーク（CDN）のPOP（Point of Presence）に誘導するDNSベースの手法はIPv6で機能します。一般に、CDNはこのドキュメントの推奨事項に従う必要があります。特に、各POPで完全なデュアルスタックサービスを運用する必要があります。さらに、各POPはIPv4とまったく同じようにIPv6ルーティングを処理する必要があります。たとえば、BGP-4 + [RFC4760]を実行します。
Note that if an ICP supports IPv6 but its external CDN provider does not, its clients will continue to use IPv4 and any IPv6-only clients will have to use a transition solution of some kind. This is not a desirable situation, since the ICP's work to support IPv6 will be wasted.
ICPがIPv6をサポートし、その外部CDNプロバイダーがサポートしない場合、そのクライアントは引き続きIPv4を使用し、IPv6のみのクライアントは何らかの移行ソリューションを使用する必要があることに注意してください。 ICPのIPv6をサポートする作業が無駄になるため、これは望ましい状況ではありません。
An ICP might face a complex situation if its CDN provider supports IPv6 at some POPs but not at others. IPv6-only clients could only be diverted to a POP supporting IPv6. There are also scenarios where a dual-stack client would be diverted to a mixture of IPv4 and IPv6 POPs for different URLs, according to the A and AAAA records provided and the availability of optimizations such as "Happy Eyeballs". A related side effect is that copies of the same content viewed at the same time via IPv4 and IPv6 may be different, due to latency in the underlying data synchronization process used by the CDN. This effect has in fact been observed in the wild for a major social network supporting dual stack. These complications do not affect the viability of relying on a dual-stack CDN, however.
CDPプロバイダーが一部のPOPでIPv6をサポートし、他のPOPではサポートしない場合、ICPは複雑な状況に直面する可能性があります。 IPv6のみのクライアントは、IPv6をサポートするPOPにのみ転送できます。提供されているAレコードとAAAAレコード、および「Happy Eyeballs」などの最適化の可用性に応じて、デュアルスタッククライアントが異なるURLのIPv4 POPとIPv6 POPの混合に転送されるシナリオもあります。関連する副作用として、CDNで使用される基礎となるデータ同期プロセスのレイテンシにより、IPv4とIPv6を介して同時に表示される同じコンテンツのコピーが異なる場合があります。この影響は、デュアルスタックをサポートする主要なソーシャルネットワークで実際に実際に観察されています。ただし、これらの複雑化は、デュアルスタックCDNに依存することの実現可能性には影響しません。
The CDN itself faces related complexity: "As IPv6 rolls out, it's going to roll out in pockets, and that's going to make the routing around congestion points that much more important but also that much harder," stated John Summers of Akamai in 2010 [CDN-UPGRADE].
アカマイのジョンサマーズは、2010年にジョン・サマーズ氏に次のように述べています。 CDN-UPGRADE]。
A converse situation that might arise is that an ICP has not yet started its deployment of IPv6 but finds that its CDN provider already supports IPv6. Then, assuming that the CDN provider announces appropriate AAAA DNS Resource Records, dual-stack and IPv6-only customers will obtain IPv6 access, and the ICP's content may well be delivered to them via IPv6. In normal circumstances, this should create no problems, but it is a situation that the ICP and its support staff need to be aware of. In particular, support staff should be given IPv6 connectivity in order to be able to investigate any problems that might arise (see Section 4).
発生する可能性のある逆の状況は、ICPがまだIPv6の展開を開始していないが、CDNプロバイダーがすでにIPv6をサポートしていることを発見した場合です。次に、CDNプロバイダーが適切なAAAA DNSリソースレコードをアナウンスすると仮定すると、デュアルスタックおよびIPv6のみの顧客はIPv6アクセスを取得し、ICPのコンテンツはIPv6経由で顧客に配信される可能性があります。通常の状況ではこれで問題は発生しませんが、ICPとそのサポートスタッフが認識する必要のある状況です。特に、発生する可能性のある問題を調査できるように、サポートスタッフにはIPv6接続を付与する必要があります（セクション4を参照）。
As noted earlier, it is in an ICP's or ASP's best interests that their users have direct IPv6 connectivity, rather than indirect IPv4 connectivity via double NAT. If the ICP or ASP has a direct business relationship with some of their clients, or with the networks that connect them to their clients, they are advised to coordinate with those partners to ensure that they have a plan to enable IPv6. They should also verify and test that there is first-class IPv6 connectivity end-to-end between the networks concerned. This is especially true for implementations that require IPv6 support in specialized programs or systems in order for the IPv6 support on the ICP/ASP side to be useful.
前述のように、ユーザーがダブルNATを介した間接IPv4接続ではなく、直接IPv6接続を使用することは、ICPまたはASPの最善の利益になります。 ICPまたはASPが一部のクライアントと、またはそれらをクライアントに接続するネットワークと直接ビジネス関係にある場合は、それらのパートナーと調整して、IPv6を有効にする計画があることを確認することをお勧めします。また、関係するネットワーク間にエンドツーエンドのファーストクラスのIPv6接続があることを確認およびテストする必要があります。これは、ICP / ASP側でのIPv6サポートを有効にするために、特別なプログラムまたはシステムでIPv6サポートを必要とする実装に特に当てはまります。
Some additional considerations come into play for some types of complex or distributed sites and applications that an ICP may be delivering. For example, an ICP may have a site spread across many hostnames (not all under their control). Other ICPs may have their sites or applications distributed across multiple locations for availability, scale, or performance.
ICPが提供する可能性のある特定のタイプの複雑なサイトまたは分散サイトおよびアプリケーションには、さらにいくつかの考慮事項があります。たとえば、ICPのサイトが多数のホスト名に分散している場合があります（すべてがホストの制御下にあるわけではありません）。他のICPは、可用性、スケール、またはパフォーマンスのために、サイトまたはアプリケーションを複数の場所に分散させる場合があります。
Many modern web sites and applications now use a collection of resources and applications, some operated by the ICP and others by third parties. While most clients support sites containing a mixture of IPv4-only and dual-stack elements, an ICP should track the IPv6 availability of embedded resources (such as images), as otherwise their site may only be partially functional or may have degraded performance for IPv6-only users.
現在、多くの最新のWebサイトとアプリケーションは、リソースとアプリケーションのコレクションを使用しており、その一部はICPによって運営され、その他はサードパーティによって運営されています。ほとんどのクライアントはIPv4のみの要素とデュアルスタック要素が混在するサイトをサポートしますが、そうでない場合、サイトが部分的にしか機能しないか、IPv6のパフォーマンスが低下する可能性があるため、ICPは埋め込みリソース（画像など）のIPv6の可用性を追跡する必要がありますのみのユーザー。
DNS-based load-balancing techniques for diverting users to servers in multiple POPs will work for IPv6, if the load balancer supports IPv6 and if AAAA records are provided. Depending on the architecture of the load balancer, an ICP may need to operate a full dual-stack service at each POP. With other architectures, it may be acceptable to initially only have IPv6 at a subset of locations. Some architectures will make it preferable for IPv6 routing to mirror IPv4 routing (for example, running BGP-4+ [RFC4760] if appropriate), but this may not always be possible, as IPv6 and IPv4 connectivity can be independent.
ロードバランサーがIPv6をサポートし、AAAAレコードが提供されている場合、ユーザーを複数のPOP内のサーバーに転送するためのDNSベースの負荷分散手法はIPv6で機能します。ロードバランサーのアーキテクチャによっては、ICPが各POPで完全なデュアルスタックサービスを操作する必要がある場合があります。他のアーキテクチャーでは、最初は場所のサブセットにのみIPv6を配置することが許容される場合があります。一部のアーキテクチャでは、IPv6ルーティングがIPv4ルーティングをミラー化することが望ましい（たとえば、必要に応じてBGP-4 + [RFC4760]を実行する）が、IPv6とIPv4の接続が独立している可能性があるため、これが常に可能とは限りません。
Some complexities may arise when a client supporting both IPv4 and IPv6 uses different POPs for each IP version (such as when IPv6 is only available in a subset of locations). There are also scenarios where a dual-stack client would be diverted to a mixture of IPv4 and IPv6 POPs for different URLs, according to the A and AAAA records provided and the availability of optimizations such as "Happy Eyeballs" [RFC6555]. A related side effect is that copies of the same content viewed at the same time via IPv4 and IPv6 may be different, due to latency in the underlying data synchronization process used at the application layer. This effect has in fact been observed in the wild for a major social network supporting dual stack.
IPv4とIPv6の両方をサポートするクライアントがIPバージョンごとに異なるPOPを使用する場合（IPv6がロケーションのサブセットでのみ使用可能な場合など）は、いくつかの複雑さが発生する可能性があります。提供されているAおよびAAAAレコードと、「Happy Eyeballs」[RFC6555]などの最適化の可用性に応じて、デュアルスタッククライアントが異なるURLのIPv4とIPv6 POPの混合に転送されるシナリオもあります。関連する副次作用として、IPv4とIPv6を介して同時に表示される同じコンテンツのコピーは、アプリケーション層で使用される基礎となるデータ同期プロセスでのレイテンシのために異なる場合があります。この影響は、デュアルスタックをサポートする主要なソーシャルネットワークで実際に実際に観察されています。
Even with a single POP, unexpected behavior may arise if a client switches spontaneously between IPv4 and IPv6 as a performance optimization [RFC6555] or if its IPv6 address changes frequently for privacy reasons [RFC4941]. Such changes may affect cookies, geolocation, load balancing, and transactional integrity. Although unexpected changes of client address also occur in an IPv4-only environment, they may be more frequent with IPv6.
単一のPOPでも、クライアントがパフォーマンス最適化[RFC6555]としてIPv4とIPv6の間で自発的に切り替わる場合、またはプライバシー上の理由からそのIPv6アドレスが頻繁に変更される場合[RFC4941]に、予期しない動作が発生する可能性があります。このような変更は、Cookie、ジオロケーション、負荷分散、およびトランザクションの整合性に影響を与える可能性があります。 IPv4のみの環境では、クライアントアドレスの予期しない変更も発生しますが、IPv6の場合はより頻繁に発生する可能性があります。
There is no doubt that, initially, IPv6 deployment will have operational impact, and will also require education and training as mentioned in Section 3. Staff will have to update network elements such as routers, update configurations, provide information to end users, and diagnose new problems. However, for an enterprise network, there is plenty of experience, e.g., on numerous university campuses, showing that dual-stack operation is no harder than IPv4-only in the steady state.
最初はIPv6の導入が運用に影響し、セクション3で説明したように教育とトレーニングも必要になることは間違いありません。スタッフはルーターなどのネットワーク要素を更新し、構成を更新し、エンドユーザーに情報を提供し、診断する必要があります。新しい問題。ただし、エンタープライズネットワークの場合、たとえば多数の大学キャンパスでの経験は豊富であり、デュアルスタック運用は、定常状態ではIPv4のみよりも難しくないことを示しています。
Whatever management, monitoring, and logging are performed for IPv4 are also needed for IPv6. Therefore, all products and tools used for these purposes must be updated to fully support IPv6 management data. It is important to verify that tools have been fully updated to support 128-bit addresses entered and displayed in hexadecimal format [RFC5952]. Since an IPv6 network may operate with more than one IPv6 prefix and therefore more than one address per host, the tools must deal with this as a normal situation. This includes any address management tool in use (see Section 5.1) as well as tools used for creating DHCP and DNS configurations. There is significant overlap here with the tools involved in site renumbering [RFC6879].
IPv4で実行される管理、監視、およびロギングは、IPv6でも必要です。したがって、これらの目的で使用されるすべての製品とツールは、IPv6管理データを完全にサポートするように更新する必要があります。 16進形式で入力および表示された128ビットアドレスをサポートするようにツールが完全に更新されていることを確認することが重要です[RFC5952]。 IPv6ネットワークは複数のIPv6プレフィックス、したがってホストごとに複数のアドレスで動作する可能性があるため、ツールはこれを通常の状況として処理する必要があります。これには、使用中のアドレス管理ツール（セクション5.1を参照）と、DHCPおよびDNS構成の作成に使用されるツールが含まれます。ここでは、サイト番号の付け替えに関連するツール[RFC6879]との重要な重複があります。
At an early stage of IPv6 deployment, it is likely that IPv6 will be mainly managed via IPv4 transport. This allows network management systems to test for dependencies between IPv4 and IPv6 management data. For example, will reports mixing IPv4 and IPv6 addresses display correctly?
IPv6の導入の初期段階では、IPv6は主にIPv4トランスポートを介して管理される可能性があります。これにより、ネットワーク管理システムはIPv4とIPv6の管理データ間の依存関係をテストできます。たとえば、IPv4アドレスとIPv6アドレスが混在するレポートは正しく表示されますか？
In a second phase, IPv6 transport should be used to manage the network. Note that it will also be necessary for an ICP to provide IPv6 connectivity for its operations and support staff, even when working remotely. As far as possible, mutual dependency between IPv4 and IPv6 should be avoided, for both the management data and the transport. Failure of one should not cause a failure of the other. One precaution to avoid this would be for network management systems to be dual-stacked. It would then be possible to use IPv4 connectivity to repair IPv6 configurations, and vice versa.
第2フェーズでは、IPv6トランスポートを使用してネットワークを管理する必要があります。 ICPがリモートで作業している場合でも、運用とサポートスタッフにIPv6接続を提供することも必要になることに注意してください。管理データとトランスポートの両方について、IPv4とIPv6の間の相互依存をできるだけ回避する必要があります。一方が故障しても、もう一方が故障することはありません。これを回避するための予防策の1つは、ネットワーク管理システムをデュアルスタックにすることです。その後、IPv4接続を使用してIPv6構成を修復したり、その逆を行ったりすることができます。
Dual stack, while necessary, does have management scaling and overhead considerations. As noted earlier, the long-term goal is to move to single-stack IPv6, when the network and its customers can support it. This is an additional reason why mutual dependency between the address families should be avoided in the management system in particular; a hidden dependency on IPv4 that had been forgotten for many years would be highly inconvenient. In particular, a management tool that manages IPv6 but itself runs only over IPv4 would prove disastrous on the day that IPv4 is switched off.
デュアルスタックは、必要ですが、管理のスケーリングとオーバーヘッドの考慮事項があります。前述のように、長期的な目標は、ネットワークとその顧客がIPv6をサポートできるようになったときに、シングルスタックIPv6に移行することです。これは、特に管理システムでアドレスファミリ間の相互依存を回避する必要がある追加の理由です。長年忘れられていたIPv4への隠された依存は、非常に不便です。特に、IPv6を管理するが、それ自体がIPv4でのみ実行される管理ツールは、IPv4がオフに切り替えられた日には悲惨な結果となるでしょう。
An ICP should ensure that any end-to-end availability monitoring systems are updated to monitor dual-stacked servers over both IPv4 and IPv6. A particular challenge here may be monitoring systems relying on DNS names, as this may result in monitoring only one of IPv4 or IPv6, resulting in a loss of visibility to failures in network connectivity over either address family.
ICPは、IPv4とIPv6の両方でデュアルスタックサーバーを監視するように、すべてのエンドツーエンドの可用性監視システムを更新する必要があります。ここでの特定の課題は、DNS名に依存するシステムの監視である可能性があります。これにより、IPv4またはIPv6のいずれか1つのみが監視され、いずれかのアドレスファミリを介したネットワーク接続の障害に対する可視性が失われる可能性があります。
As mentioned above, it will also be necessary for an ICP to provide IPv6 connectivity for its operations and support staff, even when working remotely.
上記のとおり、リモートで作業している場合でも、ICPの運用とサポートスタッフにIPv6接続を提供する必要があります。
While many ICPs may still be in the process of experimenting with and configuring IPv6, there is mature malware in the wild that will launch attacks over IPv6. For example, if a AAAA DNS record is added for a hostname, malware using client OS libraries may automatically switch from attacking that hostname over IPv4 to attacking that hostname over IPv6. As a result, it is crucial that firewalls and other network security appliances protecting servers support IPv6 and have rules tested and configured.
多くのICPがまだIPv6の実験と構成の過程にある可能性がありますが、IPv6を介して攻撃を仕掛ける成熟したマルウェアが実在しています。たとえば、AAAA DNSレコードがホスト名に追加された場合、クライアントOSライブラリを使用するマルウェアは、IPv4を介したそのホスト名の攻撃からIPv6を介したそのホスト名の攻撃に自動的に切り替わることがあります。そのため、サーバーを保護するファイアウォールやその他のネットワークセキュリティアプライアンスがIPv6をサポートし、ルールをテストして構成することが重要です。
Security experience with IPv4 should be used as a guide as to the threats that may exist in IPv6, but they should not be assumed to be equally likely nor should they be assumed to be the only threats that could exist in IPv6. However, essentially every threat that exists for IPv4 exists or will exist for IPv6, to a greater or lesser extent. It is essential to update firewalls, intrusion detection systems, denial-of-service precautions, and security auditing technology to fully support IPv6. Needless to say, it is also essential to turn on well-known security mechanisms such as DNS Security and DHCPv6 Authentication. Otherwise, IPv6 will become an attractive target for attackers.
IPv4のセキュリティ経験は、IPv6に存在する可能性のある脅威のガイドとして使用する必要がありますが、IPv6に存在する可能性のある唯一の脅威であると想定したり、それらの可能性を想定したりしないでください。ただし、本質的に、IPv4に存在するすべての脅威は、IPv6にも存在する、または存在する可能性があります。 IPv6を完全にサポートするには、ファイアウォール、侵入検知システム、サービス拒否の予防策、およびセキュリティ監査テクノロジを更新することが不可欠です。言うまでもなく、DNSセキュリティやDHCPv6認証などのよく知られたセキュリティメカニズムを有効にすることも不可欠です。そうでなければ、IPv6は攻撃者にとって魅力的なターゲットになります。
When multiple PA prefixes are in use as mentioned in Section 5.1, firewall rules must allow for all valid prefixes and must be set up to work as intended even if packets are sent via one ISP but return packets arrive via another.
セクション5.1で述べたように複数のPAプレフィックスが使用されている場合、パケットが1つのISP経由で送信され、リターンパケットが別のISP経由で到着した場合でも、ファイアウォールルールはすべての有効なプレフィックスを許可し、意図したとおりに機能するように設定する必要があります。
Performance and memory size aspects of dual-stack firewalls must be considered (as discussed for routers in Section 5.2).
デュアルスタックファイアウォールのパフォーマンスとメモリサイズの側面を考慮する必要があります（セクション5.2でルーターについて説明したとおり）。
In a dual-stack operation, there may be a risk of cross-contamination between the two protocols. For example, a successful IPv4-based denial-of-service attack might also deplete resources needed by the IPv6 service, or vice versa. This risk strengthens the argument that IPv6 security must be up to the same level as IPv4. Risks can also occur with dual-stack Virtual Private Network (VPN) solutions [VPN-LEAKAGES].
デュアルスタック操作では、2つのプロトコル間の相互汚染のリスクがあるかもしれません。たとえば、IPv4ベースのサービス拒否攻撃が成功すると、IPv6サービスに必要なリソースが使い果たされたり、その逆の場合もあります。このリスクは、IPv6のセキュリティがIPv4と同じレベルでなければならないという主張を強化します。デュアルスタック仮想プライベートネットワーク（VPN）ソリューション[VPN-LEAKAGES]でもリスクが発生する可能性があります。
A general overview of techniques to protect an IPv6 network against external attacks is given in [RFC4864]. Assuming that an ICP has native IPv6 connectivity, it is advisable to block incoming IPv6-in-IPv4 tunnel traffic using IPv4 protocol type 41. Outgoing traffic of this kind should be blocked, except for the case noted in Section 4.5 of [RFC6343]. ICMPv6 traffic should only be blocked in accordance with [RFC4890]; in particular, Packet Too Big messages, which are essential for Path MTU Discovery, must not be blocked.
外部攻撃からIPv6ネットワークを保護する手法の一般的な概要は、[RFC4864]で提供されています。 ICPにネイティブIPv6接続があると仮定すると、IPv4プロトコルタイプ41を使用して着信IPv6-in-IPv4トンネルトラフィックをブロックすることをお勧めします。この種類の発信トラフィックは、[RFC6343]のセクション4.5に記載されている場合を除き、ブロックする必要があります。 ICMPv6トラフィックは、[RFC4890]に従ってのみブロックする必要があります。特に、Path MTU Discoveryに不可欠なPacket Too Bigメッセージはブロックしないでください。
Brute-force scanning attacks to discover the existence of hosts are much less likely to succeed for IPv6 than for IPv4 [RFC5157]. However, this should not lull an ICP into a false sense of security, as various naming or addressing conventions can result in IPv6 address space being predictable or guessable. In the extreme case, IPv6 hosts might be configured with interface identifiers that are very easy to guess; for example, hosts or subnets manually numbered with consecutive interface identifiers starting from "1" would be much easier to guess. Such practices should be avoided, and other useful precautions are discussed in [RFC6583]. Also, attackers might find IPv6 addresses in logs, packet traces, DNS records (including reverse records), or elsewhere.
ホストの存在を発見するためのブルートフォーススキャン攻撃は、IPv4よりもIPv6の方が成功する可能性がはるかに低いです[RFC5157]。ただし、これによってICPが誤った安心感に陥ることはありません。これは、さまざまな命名規則またはアドレス規則により、IPv6アドレス空間が予測可能または推測可能になるためです。極端な場合、IPv6ホストは、非常に推測しやすいインターフェイス識別子で構成されている可能性があります。たとえば、「1」から始まる連続したインターフェイス識別子で手動で番号が付けられたホストまたはサブネットは、推測がはるかに簡単になります。そのような慣行は避けられるべきであり、他の有用な予防策は[RFC6583]で議論されています。また、攻撃者はログ、パケットトレース、DNSレコード（リバースレコードを含む）、またはその他の場所でIPv6アドレスを見つける可能性があります。
Protection against rogue Router Advertisements (RA Guard) should also be considered [RFC6105].
不正なルーターアドバタイズ（RAガード）に対する保護も検討する必要があります[RFC6105]。
Transport Layer Security version 1.2 [RFC5246] and its predecessors work correctly with TCP over IPv6, meaning that HTTPS-based security solutions are immediately applicable. The same should apply to any other transport-layer or application-layer security techniques.
トランスポート層セキュリティバージョン1.2 [RFC5246]およびその前身は、TCP over IPv6で正しく動作します。つまり、HTTPSベースのセキュリティソリューションがすぐに適用されます。同じことが他のトランスポート層またはアプリケーション層のセキュリティ技術にも当てはまります。
If an ASP uses IPsec [RFC4301] and the Internet Key Exchange (IKE) protocol [RFC5996] in any way to secure connections with clients, these too are fully applicable to IPv6, but only if the software stack at each end has been appropriately updated.
ASPがIPsec [RFC4301]とインターネットキー交換（IKE）プロトコル[RFC5996]を使用してクライアントとの接続を保護する場合、これらもIPv6に完全に適用できますが、両端のソフトウェアスタックが適切に更新されている場合に限られます。 。
Valuable contributions were made by Erik Kline. Useful comments were received from Tore Anderson, Cameron Byrne, Tassos Chatzithomaoglou, Wesley George, Deng Hui, Joel Jaeggli, Roger Jorgensen, Victor Kuarsingh, Bing Liu, Trent Lloyd, John Mann, Michael Newbery, Erik Nygren, Arturo Servin, Mark Smith, and other participants in the V6OPS working group.
貴重な寄付はErik Klineによって行われました。 Tore Anderson、Cameron Byrne、Tassos Chatzithomaoglou、Wesley George、Deng Hui、Joel Jaeggli、Roger Jorgensen、Victor Kuarsingh、Bing Liu、Trent Lloyd、John Mann、Michael Newbery、Erik Nygren、Arturo Servin、Mark Smith、およびV6OPSワーキンググループの他の参加者。
Brian Carpenter was a visitor at the Computer Laboratory, Cambridge University during part of this work.
ブライアンカーペンターは、この作業の一環として、ケンブリッジ大学のコンピューターラボの訪問者でした。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC2080] Malkin、G。およびR. Minnear、「RIPng for IPv6」、RFC 2080、1997年1月。
[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月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを利用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、2000年5月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「Secure Domain Name System（DNS）Dynamic Update」、RFC 3007、2000年11月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V.、およびM. Souissi、「DNS Extensions to Support IP Version 6」、RFC 3596、2003年10月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F。、およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「BGP-4のマルチプロトコル拡張機能」、RFC 4760、2007年1月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6でのステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、2007年9月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008.
[RFC5308] Hopps、C。、「Routing IPv6 with IS-IS」、RFC 5308、2008年10月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010.
[RFC5838] Lindem、A.、Mirtorabi、S.、Roy、A.、Barnes、M。、およびR. Aggarwal、「Support of Address Families in OSPFv3」、RFC 5838、2010年4月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952] Kawamura、S. and M. Kawashima、 "A Recommendation for IPv6 Address Text Representation"、RFC 5952、August 2010。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985] Barnes、M。、「HTTP-Enabled Location Delivery（HELD）」、RFC 5985、2010年9月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、RFC 5996、2010年9月。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011.
[RFC6434] Jankiewicz、E.、Loughney、J。、およびT. Narten、「IPv6ノードの要件」、RFC 6434、2011年12月。
[CDN-UPGRADE] Marsan, C., "Akamai: Why our IPv6 upgrade is harder than Google's", Network World, September 2010, <http:// www.networkworld.com/news/2010/091610-akamai-ipv6.html>.
[CDN-UPGRADE] Marsan、C。、「Akamai：なぜ私たちのIPv6アップグレードはGoogleよりも難しい」、Network World、2010年9月、<http：// www.networkworld.com/news/2010/091610-akamai-ipv6。 html>。
[IPv6-CE-REQS] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", Work in Progress, October 2012.
[IPv6-CE-REQS] Singh、H.、Beebee、W.、Donley、C。、およびB. Stark、「IPv6カスタマーエッジルーターの基本要件」、作業中、2012年10月。
[IPv6-NETWORK-DESIGN] Matthews, P., "Design Choices for IPv6 Networks", Work in Progress, February 2013.
[IPv6-NETWORK-DESIGN] Matthews、P。、「Design Choices for IPv6 Networks」、Work in Progress、2013年2月。
[MULTIHOMING-WITHOUT-NAT] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, "IPv6 Multihoming without Network Address Translation", Work in Progress, February 2012.
[MULTIHOMING-WITHOUT-NAT] Troan、O.、Ed。、Miles、D.、Matsushima、S.、Okimoto、T.、and D. Wing、 "IPv6 Multihoming without Network Address Translation"、Work in Progress、2012年2月。
[RFC1912] Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, February 1996.
[RFC1912] Barr、D。、「Common DNS Operational and Configuration Errors」、RFC 1912、1996年2月。
[RFC2081] Malkin, G., "RIPng Protocol Applicability Statement", RFC 2081, January 1997.
[RFC2081] Malkin、G。、「RIPng Protocol Applicability Statement」、RFC 2081、1997年1月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923] Lahey、K。、「Path MTU Discoveryに関するTCPの問題」、RFC 2923、2000年9月。
[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月。
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[RFC4038] Shin、M-K。、Hong、Y-G。、Hagino、J.、Savola、P。、およびE. Castro、「IPv6移行のアプリケーションアスペクト」、RFC 4038、2005年3月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]ベイカー、F。、リア、E。、およびR.ドロムス、「フラグデーのないIPv6ネットワークの番号を付け直すための手順」、RFC 4192、2005年9月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864] Van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B。、およびE. Klein、「IPv6のローカルネットワーク保護」、RFC 4864、2007年5月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890] Davies、E。およびJ. Mohacsi、「ファイアウォールでのICMPv6メッセージのフィルタリングに関する推奨事項」、RFC 4890、2007年5月。
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, March 2008.
[RFC5157] Chown、T。、「IPv6のネットワークスキャンへの影響」、RFC 5157、2008年3月。
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., and C. Hahn, "IPv6 Unicast Address Assignment Considerations", RFC 5375, December 2008.
[RFC5375] Van de Velde、G.、Popoviciu、C.、Chown、T.、Bonness、O。、およびC. Hahn、「IPv6ユニキャストアドレス割り当ての考慮事項」、RFC 5375、2008年12月。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.
[RFC6105] Levy-Abegnoli、E.、Van de Velde、G.、Popoviciu、C。、およびJ. Mohacsi、「IPv6 Router Advertisement Guard」、RFC 6105、2011年2月。
[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月。
[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月。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011.
[RFC6296] Wasserman、M。およびF. Baker、「IPv6-to-IPv6 Network Prefix Translation」、RFC 6296、2011年6月。
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
[RFC6343]カーペンター、B。、「6to4展開に関する勧告ガイドライン」、RFC 6343、2011年8月。
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6555] Wing、D。、およびA. Yourtchenko、「Happy Eyeballs：Success with Dual-Stack Hosts」、RFC 6555、2012年4月。
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012.
[RFC6583] Gashinsky、I.、Jaeggli、J。、およびW. Kumari、「Operational Neighbor Discovery Problems」、RFC 6583、2012年3月。
[RFC6589] Livingood, J., "Considerations for Transitioning Content to IPv6", RFC 6589, April 2012.
[RFC6589] Livingood、J。、「コンテンツをIPv6に移行するための考慮事項」、RFC 6589、2012年4月。
[RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks", RFC 6866, February 2013.
[RFC6866] Carpenter、B。およびS. Jiang、「エンタープライズネットワークで静的アドレスを使用してIPv6ホストの番号を再設定するための問題ステートメント」、RFC 6866、2013年2月。
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013.
[RFC6879] Jiang、S.、Liu、B。、およびB. Carpenter、「IPv6 Enterprise Network Renumbering Scenarios、Considerations、and Methods」、RFC 6879、2013年2月。
[VPN-LEAKAGES] Gont, F., "Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks", Work in Progress, December 2012.
[VPN-LEAKAGES] Gont、F。、「デュアルスタックホスト/ネットワークでの仮想プライベートネットワーク（VPN）トラフィックリーク」、作業中、2012年12月。
Authors' Addresses
著者のアドレス
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
ブライアンカーペンターコンピュータサイエンス学部オークランド大学PB 92019オークランド1142ニュージーランド
EMail: brian.e.carpenter@gmail.com
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No. 156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China
S横Jiang hu Aはテクノロジー株式会社ですQ14、hu Aはキャンパス番号156です。i青道路H艾-Dイアン地区、北京100095 P.R.中国
EMail: jiangsheng@huawei.com