[要約] RFC 7381は、企業におけるIPv6の展開に関するガイドラインであり、IPv6の導入と運用に関するベストプラクティスを提供することを目的としています。
Internet Engineering Task Force (IETF) K. Chittimaneni
Request for Comments: 7381 Dropbox, Inc.
Category: Informational T. Chown
ISSN: 2070-1721 University of Southampton
L. Howard
Time Warner Cable
V. Kuarsingh
Dyn, Inc.
Y. Pouffary
Hewlett Packard
E. Vyncke
Cisco Systems
October 2014
Enterprise IPv6 Deployment Guidelines
エンタープライズIPv6導入ガイドライン
Abstract
概要
Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers and have reasons for different priorities. The overall problem for many administrators will be to offer Internet-facing services over IPv6 while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual-stack network environment and eventually an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies.
世界中のエンタープライズネットワーク管理者は、IPv6をネットワークに準備または導入するさまざまな段階にあります。管理者はインターネットアクセスプロバイダーのオペレーターとは異なる課題に直面し、優先順位が異なる理由があります。多くの管理者にとっての全体的な問題は、IPv4のサポートを継続し、エンタープライズITネットワーク内にIPv6アクセスを導入しながら、IPv6を介してインターネット向けサービスを提供することです。全体的な移行により、ほとんどのネットワークがIPv4のみの環境からデュアルスタックネットワーク環境になり、最終的にはIPv6のみの動作モードになります。このドキュメントは、IPv6サポート戦略を検討する際にこれらの課題の多くに直面する可能性があるエンタープライズネットワークアーキテクトまたは管理者にフレームワークを提供するのに役立ちます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7381.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7381で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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
1.1. Enterprise Assumptions . . . . . . . . . . . . . . . . . 5
1.2. IPv4-Only Considerations . . . . . . . . . . . . . . . . 5
1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 6
2. Preparation and Assessment Phase . . . . . . . . . . . . . . 7
2.1. Program Planning . . . . . . . . . . . . . . . . . . . . 7
2.2. Inventory Phase . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Network Infrastructure Readiness Assessment . . . . . 8
2.2.2. Application Readiness Assessment . . . . . . . . . . 9
2.2.3. Importance of Readiness Validation and Testing . . . 9
2.3. Training . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4. Security Policy . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. IPv6 Is No More Secure Than IPv4 . . . . . . . . . . 10
2.4.2. Similarities between IPv6 and IPv4 Security . . . . . 11
2.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 11
2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6. Address Plan . . . . . . . . . . . . . . . . . . . . . . 14
2.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . 16
3. External Phase . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 20
3.4. Servers and Applications . . . . . . . . . . . . . . . . 20
3.5. Network Prefix Translation for IPv6 . . . . . . . . . . . 21
4. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Security . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Network Infrastructure . . . . . . . . . . . . . . . . . 22
4.3. End-User Devices . . . . . . . . . . . . . . . . . . . . 23
4.4. Corporate Systems . . . . . . . . . . . . . . . . . . . . 24
5. IPv6 Only . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Considerations for Specific Enterprises . . . . . . . . . . . 26
6.1. Content Delivery Networks . . . . . . . . . . . . . . . . 26
6.2. Data Center Virtualization . . . . . . . . . . . . . . . 26
6.3. University Campus Networks . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Informative References . . . . . . . . . . . . . . . . . . . 28
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
An enterprise network is defined in [RFC4057] as a network that has multiple internal links, one or more router connections to one or more providers, and is actively managed by a network operations entity (the "administrator", whether a single person or a department of administrators). Administrators generally support an internal network, consisting of users' workstations; personal computers; mobile devices; other computing devices and related peripherals; a server network, consisting of accounting and business application servers; and an external network, consisting of Internet-accessible services such as web servers, email servers, VPN systems, and customer applications. This document is intended as guidance for enterprise network architects and administrators in planning their IPv6 deployments.
企業ネットワークは、[RFC4057]で、複数の内部リンク、1つ以上のプロバイダーへの1つ以上のルーター接続を持ち、ネットワーク運用エンティティ（「管理者」、1人または管理者部門）。管理者は通常、ユーザーのワークステーションで構成される内部ネットワークをサポートします。パソコン;モバイルデバイス;他のコンピューティングデバイスおよび関連周辺機器。会計サーバーとビジネスアプリケーションサーバーで構成されるサーバーネットワーク。さらに、外部ネットワーク。インターネットアクセス可能なサービス（ウェブサーバー、メールサーバー、VPNシステム、顧客アプリケーションなど）で構成されます。このドキュメントは、エンタープライズネットワークアーキテクトと管理者がIPv6の展開を計画する際のガイダンスとして作成されました。
The business reasons for spending time, effort, and money on IPv6 will be unique to each enterprise. The most common drivers are due to the fact that when Internet service providers, including mobile wireless carriers, run out of IPv4 addresses, they will provide native IPv6 and non-native IPv4. The non-native IPv4 service may be NAT64, NAT444, Dual-Stack Lite (DS-Lite), Mapping of Address and Port using Translation (MAP-T), Mapping of Address and Port using Encapsulation (MAP-E), or other transition technologies. Compared to tunneled or translated service, native traffic typically performs better and more reliably than non-native. For example, for client networks trying to reach enterprise networks, the IPv6 experience will be better than the transitional IPv4 if the enterprise deploys IPv6 in its public-facing services. The native IPv6 network path should also be simpler to manage and, if necessary, troubleshoot. Further, enterprises doing business in growing parts of the world may find IPv6 growing faster there, where again potential new customers, employees, and partners are using IPv6. It is thus in the enterprise's interest to deploy native IPv6 at the very least in its public-facing services but ultimately across the majority or all of its scope.
IPv6に時間、労力、お金を費やすビジネス上の理由は、企業ごとに異なります。最も一般的な原因は、モバイルワイヤレスキャリアを含むインターネットサービスプロバイダーがIPv4アドレスを使い果たすと、ネイティブIPv6と非ネイティブIPv4を提供することになるためです。非ネイティブIPv4サービスは、NAT64、NAT444、Dual-Stack Lite（DS-Lite）、変換を使用したアドレスとポートのマッピング（MAP-T）、カプセル化を使用したアドレスとポートのマッピング（MAP-E）などです。移行テクノロジー。トンネル化または変換されたサービスと比較して、ネイティブトラフィックは通常、非ネイティブトラフィックよりも優れた信頼性の高いパフォーマンスを発揮します。たとえば、企業ネットワークに到達しようとするクライアントネットワークの場合、企業がパブリックサービスにIPv6を導入すれば、IPv6エクスペリエンスは過渡的なIPv4よりも優れています。ネイティブIPv6ネットワークパスも管理が簡単で、必要に応じてトラブルシューティングを行う必要があります。さらに、世界の成長地域でビジネスを行っている企業は、IPv6が急速に成長していることに気づく可能性があります。したがって、ネイティブIPv6を少なくとも公衆向けサービスにデプロイすることは企業の利益になりますが、最終的にはそのスコープの大部分またはすべてに適用されます。
The text in this document provides specific guidance for enterprise networks and complements other related work in the IETF, including [IPv6-DESIGN] and [RFC5375].
このドキュメントのテキストは、エンタープライズネットワークの具体的なガイダンスを提供し、[IPv6-DESIGN]や[RFC5375]など、IETFの他の関連作業を補完します。
For the purpose of this document, we assume the following:
このドキュメントでは、次のことを前提としています。
o The administrator is considering deploying IPv6 (but see Section 1.2 below).
o 管理者はIPv6の導入を検討しています（ただし、以下のセクション1.2を参照）。
o The administrator has existing IPv4 networks and devices that will continue to operate and be supported.
o 管理者は、運用を継続してサポートされる既存のIPv4ネットワークとデバイスを持っています。
o The administrator will want to minimize the level of disruption to the users and services by minimizing the number of technologies and functions that are needed to mediate any given application. In other words, provide native IP wherever possible.
o 管理者は、特定のアプリケーションを仲介するために必要なテクノロジーと機能の数を最小限に抑えることにより、ユーザーとサービスへの混乱のレベルを最小限に抑えたいと考えます。つまり、可能な限りネイティブIPを提供します。
Based on these assumptions, an administrator will want to use technologies that minimize the number of flows being tunneled, translated, or intercepted at any given time. The administrator will choose transition technologies or strategies that both allow most traffic to be native and manage non-native traffic. This will allow the administrator to minimize the cost of IPv6 transition technologies by containing the number and scale of transition systems.
これらの仮定に基づいて、管理者は、ある時点でトンネリング、変換、またはインターセプトされるフローの数を最小限に抑えるテクノロジーを使用する必要があります。管理者は、ほとんどのトラフィックをネイティブにして、非ネイティブトラフィックを管理できる移行テクノロジまたは戦略を選択します。これにより、管理者は移行システムの数と規模を含めることで、IPv6移行テクノロジのコストを最小限に抑えることができます。
Tunnels used for IPv6/IPv4 transition are expected as near-/mid-term mechanisms, while IPv6 tunneling will be used for many long-term operational purposes such as security, routing control, mobility, multihoming, traffic engineering, etc. We refer to the former class of tunnels as "transition tunnels".
IPv6 / IPv4移行に使用されるトンネルは、短期/中期メカニズムとして期待されていますが、IPv6トンネリングは、セキュリティ、ルーティング制御、モビリティ、マルチホーミング、トラフィックエンジニアリングなど、多くの長期的な運用目的で使用されます。 「遷移トンネル」としての以前のクラスのトンネル。
As described in [RFC6302], administrators should take certain steps even if they are not considering IPv6. Specifically, Internet-facing servers should log the source port number, timestamp (from a reliable source), and the transport protocol. This will allow investigation of malefactors behind address-sharing technologies such as NAT444, MAP, or DS Lite. Such logs should be protected for integrity, safeguarded for privacy, and periodically purged within applicable regulations for log retention.
[RFC6302]で説明されているように、管理者はIPv6を考慮していない場合でも、特定の手順を実行する必要があります。具体的には、インターネットに面するサーバーは、ソースポート番号、タイムスタンプ（信頼できるソースからの）、およびトランスポートプロトコルをログに記録する必要があります。これにより、NAT444、MAP、DS Liteなどのアドレス共有テクノロジーの背後にある悪意のある要素を調査できます。このようなログは、整合性のために保護し、プライバシーを保護し、ログの保持に関する該当する規制内で定期的に消去する必要があります。
Other IPv6 considerations may impact ostensibly IPv4-only networks, e.g., [RFC6104] describes the rogue IPv6 Router Advertisement (RA) problem, which may cause problems in IPv4-only networks where IPv6 is enabled in end systems on that network. Further discussion of the security implications of IPv6 in IPv4-only networks can be found in [RFC7123].
その他のIPv6の考慮事項は、見かけ上IPv4のみのネットワークに影響を与える可能性があります。たとえば、[RFC6104]は、IPv6がそのネットワークのエンドシステムで有効になっているIPv4のみのネットワークで問題を引き起こす可能性のある不正なIPv6ルーターアドバタイズ（RA）の問題を説明しています。 IPv4のみのネットワークにおけるIPv6のセキュリティへの影響の詳細については、[RFC7123]を参照してください。
Given the challenges of transitioning user workstations, corporate systems, and Internet-facing servers, a phased approach allows incremental deployment of IPv6, based on the administrator's own determination of priorities. This document outlines suggested phases: a Preparation and Assessment Phase, an Internal Phase, and an External Phase. The Preparation Phase is highly recommended to all administrators, as it will save errors and complexity in later phases. Each administrator must decide whether to begin with an External Phase (enabling IPv6 for Internet-facing systems, as recommended in [RFC5211]) or an Internal Phase (enabling IPv6 for internal interconnections first).
ユーザーワークステーション、企業システム、およびインターネットに直接接続されたサーバーを移行するという課題があるため、段階的なアプローチでは、管理者が独自に決定した優先順位に基づいて、IPv6を段階的に展開できます。このドキュメントでは、提案されたフェーズの概要を説明します。準備および評価フェーズ、内部フェーズ、および外部フェーズです。準備フェーズは、後のフェーズでのエラーと複雑さを軽減するため、すべての管理者に強く推奨されます。各管理者は、外部フェーズ（[RFC5211]で推奨されているように、インターネットに直接接続されたシステムでIPv6を有効にする）と内部フェーズ（最初に内部相互接続でIPv6を有効にする）のどちらから始めるかを決定する必要があります。
Each scenario is likely to be different to some extent, but we can highlight some considerations:
各シナリオはある程度異なる可能性がありますが、いくつかの考慮事項を強調できます。
o In many cases, customers outside the network will have IPv6 before the internal enterprise network. For these customers, IPv6 may well perform better, especially for certain applications, than translated or tunneled IPv4, so the administrator may want to prioritize the External Phase such that those customers have the simplest and most robust connectivity to the enterprise, or at least its external-facing elements.
o 多くの場合、ネットワークの外部の顧客は、内部のエンタープライズネットワークの前にIPv6を使用します。これらのお客様の場合、IPv6は、特に特定のアプリケーションでは、変換またはトンネル化されたIPv4よりも優れたパフォーマンスを発揮する可能性があります。そのため、管理者は外部フェーズを優先して、企業への接続が最も簡単で最も堅牢になるようにするか、少なくとも外向きの要素。
o Employees who access internal systems by VPN may find that their ISPs provide translated IPv4, which does not support the required VPN protocols. In these cases, the administrator may want to prioritize the External Phase and any other remotely accessible internal systems. It is worth noting that a number of emerging VPN solutions provide dual-stack connectivity; thus, a VPN service may be useful for employees in IPv4-only access networks to access IPv6 resources in the enterprise network (much like many public tunnel broker services, but specifically for the enterprise). Some security considerations are described in [RFC7359].
o VPN経由で内部システムにアクセスする従業員は、ISPが必要なVPNプロトコルをサポートしない変換されたIPv4を提供していることに気付く場合があります。このような場合、管理者は、外部フェーズと他のリモートアクセス可能な内部システムを優先することができます。注目に値するのは、多くの新しいVPNソリューションがデュアルスタック接続を提供していることです。したがって、VPNサービスは、IPv4のみのアクセスネットワークの従業員が企業ネットワークのIPv6リソースにアクセスするのに役立ちます（多くのパブリックトンネルブローカーサービスと同様ですが、特に企業向けです）。 [RFC7359]には、セキュリティに関するいくつかの考慮事項が記載されています。
o Internet-facing servers cannot be managed over IPv6 unless the management systems are IPv6 capable. These might be Network Management Systems (NMS), monitoring systems, or just remote management desktops. Thus, in some cases, the Internet-facing systems are dependent on IPv6-capable internal networks. However, dual-stack Internet-facing systems can still be managed over IPv4.
o 管理システムがIPv6対応でない場合、インターネットに直接接続されたサーバーはIPv6を介して管理できません。これらは、ネットワーク管理システム（NMS）、監視システム、または単なるリモート管理デスクトップです。したがって、場合によっては、インターネットに面するシステムはIPv6対応の内部ネットワークに依存しています。ただし、デュアルスタックのインターネットに面するシステムは、IPv4を介して管理できます。
o Virtual Machines (VMs) may enable a faster rollout once initial system deployment is complete. Management of VMs over IPv6 is still dependent on the management software supporting IPv6.
o 仮想マシン（VM）は、最初のシステム導入が完了すると、より迅速なロールアウトを可能にする場合があります。 IPv6を介したVMの管理は、IPv6をサポートする管理ソフトウェアに依存しています。
o IPv6 is enabled by default on all modern operating systems, so it may be more urgent to manage and have visibility on the internal traffic. It is important to manage IPv6 for security purposes, even in an ostensibly IPv4-only network, as described in [RFC7123].
o 最新のすべてのオペレーティングシステムでは、IPv6がデフォルトで有効になっているため、内部トラフィックを管理して可視化することがより緊急になる可能性があります。 [RFC7123]で説明されているように、表面上はIPv4のみのネットワークであっても、セキュリティ上の目的でIPv6を管理することが重要です。
o In many cases, the corporate accounting, payroll, human resource, and other internal systems may only need to be reachable from the internal network, so they may be a lower priority. As enterprises require their vendors to support IPv6, more internal applications will support IPv6 by default, and it can be expected that eventually new applications will only support IPv6. The inventory, as described in Section 2.2, will help determine the systems' readiness, as well as the readiness of the supporting network elements and security, which will be a consideration in prioritization of these corporate systems.
o 多くの場合、企業の会計、給与計算、人事、およびその他の内部システムは、内部ネットワークから到達可能である必要があるだけなので、優先度は低くなります。企業はベンダーにIPv6のサポートを要求するため、デフォルトでより多くの内部アプリケーションがIPv6をサポートし、最終的に新しいアプリケーションはIPv6のみをサポートすることが期待できます。セクション2.2で説明されているインベントリは、システムの準備状況、およびこれらの企業システムの優先順位付けにおける考慮事項となるサポートネットワーク要素とセキュリティの準備状況を判断するのに役立ちます。
o Some large organizations (even when using private IPv4 addresses [RFC1918]) are facing IPv4 address exhaustion because of the internal network growth (for example, the vast number of VMs) or because of the acquisition of other companies that often raise private IPv4 address overlapping issues.
o 一部の大規模組織（プライベートIPv4アドレス[RFC1918]を使用している場合でも）は、内部ネットワークの増大（たとえば、VMの膨大な数）またはプライベートIPv4アドレスの重複を頻繁に発生させる他の企業の買収により、IPv4アドレスの枯渇に直面しています問題。
o IPv6 restores end-to-end transparency even for internal applications (of course security policies must still be enforced). When two organizations or networks merge [RFC6879], the unique addressing of IPv6 can make the merger much easier and faster. A merger may, therefore, prioritize IPv6 for the affected systems.
o IPv6は、内部アプリケーションの場合でもエンドツーエンドの透過性を復元します（もちろん、セキュリティポリシーを引き続き適用する必要があります）。 2つの組織またはネットワークがマージする場合[RFC6879]、IPv6の一意のアドレス指定により、マージがより簡単かつ高速になります。したがって、合併により、影響を受けるシステムのIPv6が優先される場合があります。
These considerations are in conflict; each administrator must prioritize according to their company's conditions. It is worth noting that the reasons given in "A Large Corporate User's View of IPng", described in [RFC1687], for reluctance to deploy have largely been satisfied or overcome in the intervening years.
これらの考慮事項は矛盾しています。各管理者は、会社の条件に従って優先順位を付ける必要があります。 [RFC1687]で説明されている「大企業のIPngに対する大企業の見解」で示されている、導入を躊躇する理由は、ここ数年で大部分が満足または克服されてきたことは注目に値します。
Since enabling IPv6 is a change to the most fundamental Internet Protocol, and since there are so many interdependencies, having a professional project manager organize the work is highly recommended. In addition, an executive sponsor should be involved in determining the goals of enabling IPv6 (which will establish the order of the phases) and should receive regular updates.
IPv6を有効にすることは最も基本的なインターネットプロトコルへの変更であり、相互依存関係が非常に多いため、専門のプロジェクトマネージャーに作業の整理を依頼することを強くお勧めします。さらに、エグゼクティブスポンサーは、IPv6を有効にする目標（フェーズの順序を確立する）の決定に関与し、定期的な更新を受け取る必要があります。
It may be necessary to complete the Preparation Phase before determining whether to prioritize the Internal or External Phase, since needs and readiness assessments are part of that phase. For a large enterprise, it may take several iterations to really understand the level of effort required. Depending on the required schedule, it may be useful to roll IPv6 projects into other architectural upgrades -- this can be an excellent way to improve the network and reduce costs. However, by increasing the scope of projects, the schedule is often affected. For instance, a major systems upgrade may take a year to complete, where just patching existing systems may take only a few months.
ニーズと準備の評価はそのフェーズの一部であるため、内部フェーズと外部フェーズのどちらを優先するかを決定する前に、準備フェーズを完了する必要がある場合があります。大企業の場合、必要な作業のレベルを実際に理解するには数回の反復が必要になる場合があります。必要なスケジュールによっては、IPv6プロジェクトを他のアーキテクチャーのアップグレードに組み込むと役立つ場合があります。これは、ネットワークを改善してコストを削減するための優れた方法です。ただし、プロジェクトの範囲を拡大することにより、スケジュールが影響を受けることがよくあります。たとえば、メジャーシステムのアップグレードが完了するまでに1年かかる場合があり、既存のシステムにパッチを適用するだけで数か月かかる場合があります。
The deployment of IPv6 will not generally stop all other technology work. Once IPv6 has been identified as an important initiative, all projects, both new and in progress, will need to be reviewed to ensure IPv6 support.
IPv6の導入は、一般的に他のすべてのテクノロジー作業を停止するわけではありません。 IPv6が重要なイニシアチブとして識別されたら、IPv6のサポートを確実にするために、新規および進行中のすべてのプロジェクトを確認する必要があります。
It is normal for assessments to continue in some areas while execution of the project begins in other areas. This is fine, as long as recommendations in other parts of this document are considered, especially regarding security (for instance, one should not deploy IPv6 on a system before security has been evaluated).
プロジェクトの実行が他の領域で始まる間、評価が一部の領域で継続するのは正常です。このドキュメントの他の部分の推奨事項、特にセキュリティについて検討している限り、これは問題ありません（たとえば、セキュリティが評価される前にシステムにIPv6を展開しないでください）。
To comprehend the scope of the Inventory Phase, we recommend dividing the problem space in two: network infrastructure readiness and applications readiness.
インベントリフェーズの範囲を理解するには、問題の領域を2つに分割することをお勧めします。ネットワークインフラストラクチャの準備とアプリケーションの準備です。
The goal of this assessment is to identify the level of IPv6 readiness of network equipment. This will identify the effort required to move to an infrastructure that supports IPv6 with the same functional service capabilities as the existing IPv4 network. This may also require a feature comparison and gap analysis between IPv4 and IPv6 functionality on the network equipment and software. IPv6 support will require testing; features often work differently in vendors' labs than production networks. Some devices and software will require IPv4 support for IPv6 to work.
この評価の目的は、ネットワーク機器のIPv6対応のレベルを特定することです。これにより、既存のIPv4ネットワークと同じ機能的なサービス機能を備えたIPv6をサポートするインフラストラクチャに移行するために必要な作業が特定されます。これには、ネットワーク機器とソフトウェアのIPv4機能とIPv6機能の機能比較とギャップ分析も必要になる場合があります。 IPv6サポートにはテストが必要です。多くの場合、機能はベンダーのラボと実稼働ネットワークで異なる動作をします。一部のデバイスとソフトウェアは、IPv6が機能するためにIPv4サポートを必要とします。
The inventory will show which network devices are already capable, which devices can be made IPv6 ready with a code/firmware upgrade, and which devices will need to be replaced. The data collection consists of a network discovery to gain an understanding of the topology and inventory network infrastructure equipment and code versions with information gathered from static files and IP address management, DNS, and DHCP tools.
インベントリには、すでに対応しているネットワークデバイス、コード/ファームウェアのアップグレードでIPv6対応にすることができるデバイス、および交換が必要なデバイスが表示されます。データ収集は、静的ファイルとIPアドレス管理、DNS、およびDHCPツールから収集された情報を使用して、トポロジとインベントリネットワークインフラストラクチャ機器およびコードバージョンを理解するためのネットワーク探索で構成されます。
Since IPv6 might already be present in the environment, through default configurations or VPNs, an infrastructure assessment (at minimum) is essential to evaluate potential security risks.
IPv6は環境に既に存在している可能性があるため、デフォルトの構成またはVPNを通じて、潜在的なセキュリティリスクを評価するには、インフラストラクチャの評価（少なくとも）が不可欠です。
Just like network equipment, application software needs to support IPv6. This includes OS, firmware, middleware, and applications (including internally developed applications). Vendors will typically handle IPv6 enablement of off-the-shelf products, but often enterprises need to request this support from vendors. For internally developed applications, it is the responsibility of the enterprise to enable them for IPv6. Analyzing how a given application communicates over the network will dictate the steps required to support IPv6. Applications should avoid instructions specific to a given IP address family. Any applications that use APIs, such as the C language, that expose the IP version specifically, need to be modified to also work with IPv6.
ネットワーク機器と同様に、アプリケーションソフトウェアもIPv6をサポートする必要があります。これには、OS、ファームウェア、ミドルウェア、およびアプリケーション（内部で開発されたアプリケーションを含む）が含まれます。ベンダーは通常、既製の製品のIPv6対応を処理しますが、多くの場合、企業はベンダーにこのサポートを要求する必要があります。内部で開発されたアプリケーションの場合、IPv6を有効にするのは企業の責任です。特定のアプリケーションがネットワークを介して通信する方法を分析すると、IPv6をサポートするために必要な手順が決まります。アプリケーションは、特定のIPアドレスファミリに固有の指示を避ける必要があります。特にIPバージョンを公開するC言語などのAPIを使用するアプリケーションは、IPv6でも動作するように変更する必要があります。
There are two ways to IPv6-enable applications. The first approach is to have separate logic for IPv4 and IPv6, thus leaving the IPv4 code path mainly untouched. This approach causes the least disruption to the existing IPv4 logic flow, but introduces more complexity, since the application now has to deal with two logic loops with complex race conditions and error recovery mechanisms between these two logic loops. The second approach is to create a combined IPv4/IPv6 logic, which ensures operation regardless of the IP version used on the network. Knowing whether a given implementation will use IPv4 or IPv6 in a given deployment is a matter of some art; see Source Address Selection [RFC6724] and Happy Eyeballs [RFC6555]. It is generally recommended that the application developer use industry IPv6-porting tools to locate the code that needs to be updated. Some discussion of IPv6 application porting issues can be found in [RFC4038].
アプリケーションをIPv6対応にするには2つの方法があります。最初のアプローチは、IPv4とIPv6に別々のロジックを持たせることです。これにより、IPv4コードパスは主に変更されません。このアプローチは、既存のIPv4ロジックフローへの影響を最小限に抑えますが、アプリケーションが2つのロジックループを処理する必要があるため、複雑さが増します。 2番目のアプローチは、IPv4 / IPv6ロジックの組み合わせを作成することです。これにより、ネットワークで使用されているIPバージョンに関係なく動作が保証されます。特定の実装が特定の展開でIPv4を使用するかIPv6を使用するかを知ることは、いくつかの技術の問題です。送信元アドレスの選択[RFC6724]およびHappy Eyeballs [RFC6555]を参照してください。通常、アプリケーション開発者は業界のIPv6移植ツールを使用して、更新が必要なコードを見つけることをお勧めします。 IPv6アプリケーションの移植の問題に関する議論は、[RFC4038]にあります。
Lastly, IPv6 introduces a completely new way of addressing endpoints, which can have ramifications at the network layer all the way up to the applications. So to minimize disruption during the transition phase, we recommend complete functionality, scalability, and security testing to understand how IPv6 impacts the services and networking infrastructure.
最後に、IPv6は、エンドポイントをアドレッシングするまったく新しい方法を導入します。これにより、アプリケーションに至るまで、ネットワーク層に影響を与える可能性があります。したがって、移行フェーズ中の混乱を最小限に抑えるために、IPv6がサービスとネットワークインフラストラクチャにどのように影響するかを理解するために、完全な機能、拡張性、およびセキュリティテストをお勧めします。
Many organizations falter in IPv6 deployment because of a perceived training gap. Training is important for those who work with addresses regularly, as with anyone whose work is changing. Better knowledge of the reasons IPv6 is being deployed will help inform the assessment of who needs training and what training they need.
多くの組織は、認識されたトレーニングのギャップのために、IPv6の展開に行き詰まっています。トレーニングは、仕事が変わる人と同様に、住所を定期的に扱う人にとって重要です。 IPv6が導入されている理由についてのより良い知識は、誰がトレーニングを必要としているか、どのようなトレーニングが必要かを評価するのに役立ちます。
It is obvious that IPv6 networks should be deployed in a secure way. The industry has learned a lot about network security with IPv4, so network operators should leverage this knowledge and expertise when deploying IPv6. IPv6 is not so different than IPv4: it is a connectionless network protocol using the same lower-layer service and delivering the same service to the upper layer. Therefore, the security issues and mitigation techniques are mostly identical with the same exceptions that are described further.
IPv6ネットワークを安全な方法で展開する必要があることは明らかです。業界はIPv4を使用したネットワークセキュリティについて多くのことを学んでいるため、ネットワークオペレーターはIPv6を導入するときにこの知識と専門知識を活用する必要があります。 IPv6はIPv4とそれほど違いはありません。同じ下位層サービスを使用し、同じサービスを上位層に配信するコネクションレス型ネットワークプロトコルです。したがって、セキュリティの問題と軽減手法はほとんど同じですが、後で説明する例外は同じです。
Some people believe that IPv6 is inherently more secure than IPv4 because it is new. Nothing can be more wrong. Indeed, being a new protocol means that bugs in the implementations have yet to be discovered and fixed and that few people have the operational security expertise needed to operate securely an IPv6 network. This lack of operational expertise is the biggest threat when deploying IPv6: the importance of training is to be stressed again.
一部の人々は、IPv6は新しいため、本質的にIPv4よりも安全であると信じています。これ以上問題はありません。実際、新しいプロトコルであることは、実装のバグがまだ発見および修正されていないこと、およびIPv6ネットワークを安全に運用するために必要な運用セキュリティの専門知識を持っている人がほとんどいないことを意味します。この運用上の専門知識の欠如は、IPv6を展開する際の最大の脅威です。トレーニングの重要性が再び強調されます。
One security myth is that, thanks to its huge address space, a network cannot be scanned by enumerating all IPv6 addresses in a /64 LAN; hence, a malevolent person cannot find a victim. [RFC5157] describes some alternate techniques to find potential targets on a network, for example, enumerating all DNS names in a zone. Additional advice in this area is also given in [HOST-SCANNING].
セキュリティの神話の1つは、その巨大なアドレス空間のおかげで、/ 64 LAN内のすべてのIPv6アドレスを列挙してネットワークをスキャンすることはできないということです。したがって、悪意のある人は犠牲者を見つけることができません。 [RFC5157]は、ゾーン内のすべてのDNS名を列挙するなど、ネットワーク上の潜在的なターゲットを見つけるためのいくつかの代替手法について説明しています。この領域に関する追加のアドバイスは、[ホストスキャン]でも提供されます。
Another security myth is that IPv6 is more secure because it mandates the use of IPsec everywhere. While the original IPv6 specifications may have implied this, [RFC6434] clearly states that IPsec support is not mandatory. Moreover, if all the intra-enterprise traffic is encrypted, both malefactors and security tools that rely on payload inspection (Intrusion Prevention System (IPS), firewall, Access Control List (ACL), IP Flow Information Export (IPFIX) ([RFC7011] and [RFC7012]), etc.) will be affected. Therefore, IPsec is as useful in IPv6 as in IPv4 (for example, to establish a VPN overlay over a non-trusted network or to reserve for some specific applications).
もう1つのセキュリティの神話は、IPv6はどこでもIPsecの使用を義務付けているため、より安全であるということです。元のIPv6仕様はこれを暗示していたかもしれませんが、[RFC6434]はIPsecサポートが必須ではないことを明確に述べています。さらに、すべての企業内トラフィックが暗号化されている場合、悪意のある要素とペイロード検査に依存するセキュリティツール（侵入防止システム（IPS）、ファイアウォール、アクセス制御リスト（ACL）、IPフロー情報エクスポート（IPFIX）（[RFC7011] [RFC7012]）など）が影響を受けます。したがって、IPsecはIPv4と同様にIPv6でも役立ちます（たとえば、信頼されていないネットワーク上でVPNオーバーレイを確立したり、特定のアプリケーション用に予約したりするため）。
The last security myth is that amplification attacks (such as [SMURF]) do not exist in IPv6 because there is no more broadcast. Alas, this is not true as ICMP error (in some cases) or information messages can be generated by routers and hosts when forwarding or receiving a multicast message (see Section 2.4 of [RFC4443]). Therefore, the generation and the forwarding rate of ICMPv6 messages must be limited as in IPv4.
最後のセキュリティ神話は、ブロードキャストがないため、IPv6では増幅攻撃（[SMURF]など）は存在しないというものです。悲しいかな、ICMPエラー（場合によって）またはマルチキャストメッセージの転送または受信時にルーターやホストによって情報メッセージが生成される可能性があるため、これは当てはまりません（[RFC4443]のセクション2.4を参照）。したがって、ICMPv6メッセージの生成と転送レートは、IPv4の場合と同様に制限する必要があります。
It should be noted that in a dual-stack network, the security implementation for both IPv4 and IPv6 needs to be considered, in addition to security considerations related to the interaction of (and transition between) the two, while they coexist.
デュアルスタックネットワークでは、IPv4とIPv6の共存（およびそれらの間の遷移）に関連するセキュリティの考慮事項に加えて、IPv4とIPv6の両方のセキュリティ実装を考慮する必要があることに注意してください。
As mentioned earlier, IPv6 is quite similar to IPv4; therefore, several attacks apply for both protocol families, including:
前述のように、IPv6はIPv4と非常によく似ています。したがって、次のようないくつかの攻撃が両方のプロトコルファミリに適用されます。
o Application layer attacks: such as cross-site scripting or SQL injection
o アプリケーション層攻撃：クロスサイトスクリプティングやSQLインジェクションなど
o Rogue device: such as a rogue Wi-Fi access point
o 不正なデバイス：不正なWi-Fiアクセスポイントなど
o Flooding and all traffic-based denial of services (including the use of control plane policing for IPv6 traffic: see [RFC6192])
o フラッディングとすべてのトラフィックベースのサービス拒否（IPv6トラフィックのコントロールプレーンポリシングの使用を含む：[RFC6192]を参照）
A specific case of congruence is IPv6 Unique Local Addresses (ULAs) [RFC4193] and IPv4 private addressing [RFC1918], which do not provide any security by 'magic'. In both cases, the edge router must apply strict filters to block those private addresses from entering and, just as importantly, leaving the network. This filtering can be done by the enterprise or by the ISP, but the cautious administrator will prefer to do it in the enterprise.
一致の特定のケースは、IPv6固有ローカルアドレス（ULA）[RFC4193]とIPv4プライベートアドレス指定[RFC1918]であり、これらは「マジック」によるセキュリティを提供しません。どちらの場合も、エッジルーターは厳密なフィルターを適用して、これらのプライベートアドレスがネットワークに出入りしないようにブロックする必要があります。このフィルタリングは、企業またはISPが行うことができますが、慎重な管理者は企業で行うことを好みます。
IPv6 addresses can be spoofed as easily as IPv4 addresses, and there are packets with bogon IPv6 addresses (see [CYMRU]). Anti-bogon filtering must be done in the data and routing planes. It can be done by the enterprise or by the ISP, or both, but again the cautious administrator will prefer to do it in the enterprise.
IPv6アドレスは、IPv4アドレスと同じくらい簡単に偽装でき、bogon IPv6アドレスを持つパケットがあります（[CYMRU]を参照）。アンチボゴンフィルタリングは、データプレーンとルーティングプレーンで実行する必要があります。これは、企業またはISP、あるいはその両方で行うことができますが、慎重な管理者は企業で行うことを好むでしょう。
Even if IPv6 is similar to IPv4, there are some differences that create some IPv6-only vulnerabilities or issues. We give examples of such differences in this section.
IPv6がIPv4に類似している場合でも、IPv6のみの脆弱性または問題を引き起こすいくつかの違いがあります。このセクションでは、このような違いの例を示します。
Privacy extension addresses [RFC4941] are usually used to protect individual privacy by periodically changing the interface identifier part of the IPv6 address to avoid tracking a host by its otherwise always identical and unique 64-bit Extended Unique Identifier (EUI-64) based on Media Access Control (MAC). While this presents a real advantage on the Internet, moderated by the fact that the prefix part remains the same, it complicates the task of following an audit trail when a security officer or network operator wants to trace back a log entry to a host in their network because when the tracing is done, the searched IPv6 address could have disappeared from the network. Therefore, the use of privacy extension addresses usually requires additional monitoring and logging of the binding of the IPv6 address to a data-link layer address (see also the monitoring section in [IPv6-SECURITY], Section 2.5). Some early enterprise deployments have taken the approach of using tools that harvest IP/MAC address mappings from switch and router devices to provide address accountability; this approach has been shown to work, though it can involve gathering significantly more address data than in equivalent IPv4 networks. An alternative is to try to prevent the use of privacy extension addresses by enforcing the use of DHCPv6, such that hosts only get addresses assigned by a DHCPv6 server. This can be done by configuring routers to set the M bit in RAs, combined with all advertised prefixes being included without the A bit set (to prevent the use of stateless autoconfiguration). Of course, this technique requires that all hosts support stateful DHCPv6. It is important to note that not all operating systems exhibit the same behavior when processing RAs with the M bit set. The varying OS behavior is related to the lack of prescriptive definition around the A, M, and O bits within the Neighbor Discovery Protocol (NDP). [DHCPv6-SLAAC-PROBLEM] provides a much more detailed analysis on the interaction of the M bit and DHCPv6.
プライバシー拡張アドレス[RFC4941]は通常、IPv6アドレスのインターフェイス識別子部分を定期的に変更して個々のプライバシーを保護し、メディアに基づく常に同一で一意の64ビット拡張一意識別子（EUI-64）によるホストの追跡を回避しますアクセス制御（MAC）。これはインターネットでは実際の利点となりますが、プレフィックス部分は同じままであるという事実によって緩和されますが、セキュリティ担当者またはネットワークオペレーターがログエントリをホストのトレースエントリに追跡したい場合、監査証跡をたどるタスクが複雑になります。トレースが完了すると、検索されたIPv6アドレスがネットワークから消えた可能性があるためです。したがって、プライバシー拡張アドレスを使用するには、通常、IPv6アドレスのデータリンク層アドレスへのバインディングの追加の監視とロギングが必要です（[IPv6-SECURITY]の監視セクション、セクション2.5も参照）。一部の初期のエンタープライズ展開では、スイッチおよびルーターデバイスからIP / MACアドレスマッピングを取得するツールを使用してアドレスアカウンタビリティを提供するアプローチを採用しています。このアプローチは機能することが示されていますが、同等のIPv4ネットワークよりもはるかに多くのアドレスデータを収集する必要があります。代替手段は、ホストがDHCPv6サーバーによって割り当てられたアドレスのみを取得するように、DHCPv6の使用を強制することにより、プライバシー拡張アドレスの使用を防止しようとすることです。これは、RAでMビットを設定するようにルーターを構成し、（ステートレス自動構成の使用を防止するために）Aビットを設定せずに含まれているすべてのアドバタイズされたプレフィックスと組み合わせて行うことができます。もちろん、この手法では、すべてのホストがステートフルDHCPv6をサポートする必要があります。 Mビットが設定されたRAを処理するときに、すべてのオペレーティングシステムが同じ動作を示すわけではないことに注意することが重要です。さまざまなOSの動作は、近隣探索プロトコル（NDP）内のA、M、およびOビットに関する規定の欠如に関連しています。 [DHCPv6-SLAAC-PROBLEM]は、MビットとDHCPv6の相互作用に関するより詳細な分析を提供します。
Extension headers complicate the task of stateless packet filters such as ACLs. If ACLs are used to enforce a security policy, then the enterprise must verify whether its ACLs (but also stateful firewalls) are able to process extension headers (this means understand them enough to parse them to find the upper-layer payloads) and to block unwanted extension headers (e.g., to implement [RFC5095]). This topic is discussed further in [RFC7045].
拡張ヘッダーは、ACLなどのステートレスパケットフィルターのタスクを複雑にします。 ACLを使用してセキュリティポリシーを適用する場合、企業はACL（ステートフルファイアウォールも含む）が拡張ヘッダーを処理できるかどうか（つまり、それらを理解して上位層のペイロードを見つけるためにそれらを解析できるかどうか）を確認し、ブロックする必要があります。不要な拡張ヘッダー（[RFC5095]の実装など）。このトピックは[RFC7045]でさらに議論されています。
Fragmentation is different in IPv6 because it is done only by the source host and never during a forwarding operation. This means that ICMPv6 packet-too-big messages must be allowed to pass through the network and not be filtered [RFC4890]. Fragments can also be used to evade some security mechanisms such as RA-Guard [RFC6105]. See also [RFC5722] and [RFC7113].
断片化は、送信元ホストによってのみ行われ、転送操作中には行われないため、IPv6では異なります。これは、ICMPv6パケットが大きすぎるメッセージは、ネットワークを通過することを許可され、フィルタリングされない必要があることを意味します[RFC4890]。フラグメントは、RA-Guard [RFC6105]などの一部のセキュリティメカニズムを回避するためにも使用できます。 [RFC5722]と[RFC7113]も参照してください。
One of the biggest differences between IPv4 and IPv6 is the introduction of NDP [RFC4861], which includes a variety of important IPv6 protocol functions, including those provided in IPv4 by the Address Resolution Protocol (ARP) [RFC0826]. NDP runs over ICMPv6 (which as stated above means that security policies must allow some ICMPv6 messages to pass, as described in RFC 4890), but has the same lack of security as, for example, ARP, in that there is no inherent message authentication. While Secure Neighbor Discovery (SEND) [RFC3971] and Cryptographically Generated Addresses (CGAs) [RFC3972] have been defined, they are not widely implemented). The threat model for RAs within the NDP suite is similar to that of DHCPv4 (and DHCPv6), in that a rogue host could be either a rogue router or a rogue DHCP server. An IPv4 network can be made more secure with the help of DHCPv4 snooping in edge switches, and likewise RA snooping can improve IPv6 network security (in IPv4-only networks as well). Thus, enterprises using such techniques for IPv4 should use the equivalent techniques for IPv6, including RA-Guard [RFC6105] and all work in progress from the Source Address Validation Improvement (SAVI) WG, e.g., [RFC6959], which is similar to the protection given by dynamic ARP monitoring in IPv4. Other DoS vulnerabilities are related to NDP cache exhaustion, and mitigation techniques can be found in ([RFC6583]).
IPv4とIPv6の最大の違いの1つは、NDP [RFC4861]の導入です。これには、アドレス解決プロトコル（ARP）[RFC0826]によってIPv4で提供される機能を含む、さまざまな重要なIPv6プロトコル機能が含まれます。 NDPはICMPv6で実行されます（これは、前述のように、RFC 4890で説明されているように、セキュリティポリシーが一部のICMPv6メッセージの通過を許可する必要があることを意味します）が、固有のメッセージ認証がないという点で、たとえばARPと同じようにセキュリティが不足しています。 Secure Neighbor Discovery（SEND）[RFC3971]およびCryptographically Generated Addresss（CGA）[RFC3972]が定義されていますが、広く実装されていません）。 NDPスイート内のRAの脅威モデルは、DHCPv4（およびDHCPv6）の脅威モデルと類似しており、不正なホストが不正なルーターまたは不正なDHCPサーバーのいずれかである可能性があります。エッジスイッチのDHCPv4スヌーピングを使用してIPv4ネットワークをより安全にすることができます。同様に、RAスヌーピングはIPv6ネットワークセキュリティを向上させることができます（IPv4のみのネットワークでも）。したがって、IPv4にこのような手法を使用している企業は、RA-Guard [RFC6105]を含むIPv6と同等の手法を使用する必要があります。また、[RFC6959]など、ソースアドレス検証改善（SAVI）WGから進行中のすべての作業は、 IPv4の動的ARP監視によって提供される保護。その他のDoS脆弱性はNDPキャッシュの枯渇に関連しており、緩和技術は（[RFC6583]）にあります。
As stated previously, running a dual-stack network doubles the attack exposure as a malevolent person has now two attack vectors: IPv4 and IPv6. This simply means that all routers and hosts operating in a dual-stack environment with both protocol families enabled (even if by default) must have a congruent security policy for both protocol versions. For example, permit TCP ports 80 and 443 to all web servers and deny all other ports to the same servers must be implemented both for IPv4 and IPv6. It is thus important that the tools available to administrators readily support such behavior.
前に述べたように、悪意のある人物がIPv4とIPv6の2つの攻撃ベクトルを持っているため、デュアルスタックネットワークを実行すると攻撃の危険性が2倍になります。これは単に、両方のプロトコルファミリが有効になっているデュアルスタック環境で動作しているすべてのルーターとホスト（既定の場合でも）が、両方のプロトコルバージョンに対応するセキュリティポリシーを持っている必要があることを意味します。たとえば、TCPポート80および443をすべてのWebサーバーに許可し、同じサーバーへの他のすべてのポートを拒否することは、IPv4とIPv6の両方に実装する必要があります。したがって、管理者が利用できるツールがそのような動作を容易にサポートすることが重要です。
An important design choice to be made is what IGP is to use inside the network. A variety of IGPs (IS-IS, OSPFv3, and Routing Information Protocol Next Generation (RIPng)) support IPv6 today, and picking one over the other is a design choice that will be dictated mostly by existing operational policies in an enterprise network. As mentioned earlier, it would be beneficial to maintain operational parity between IPv4 and IPv6; therefore, it might make sense to continue using the same protocol family that is being used for IPv4. For example, in a network using OSPFv2 for IPv4, it might make sense to use OSPFv3 for IPv6. It is important to note that although OSPFv3 is similar to OSPFv2, they are not the same. On the other hand, some organizations may chose to run different routing protocols for different IP versions. For example, one may chose to run OSPFv2 for IPv4 and IS-IS for IPv6. An important design question to consider here is whether to support one IGP or two different IGPs in the longer term. [IPv6-DESIGN] presents advice on the design choices
IGPがネットワーク内で何を使用するかは、重要な設計上の選択です。現在、さまざまなIGP（IS-IS、OSPFv3、Routing Information Protocol Next Generation（RIPng））がIPv6をサポートしており、どちらを選択するかは、主にエンタープライズネットワークの既存の運用ポリシーによって決定される設計上の選択です。前述のように、IPv4とIPv6の間で運用上の同等性を維持することは有益です。したがって、IPv4で使用されているのと同じプロトコルファミリを引き続き使用することは理にかなっています。たとえば、IPv4にOSPFv2を使用しているネットワークでは、IPv6にOSPFv3を使用することが理にかなっている場合があります。 OSPFv3はOSPFv2に似ていますが、同じではないことに注意することが重要です。一方、組織によっては、IPバージョンごとに異なるルーティングプロトコルを実行することを選択する場合があります。たとえば、IPv4の場合はOSPFv2、IPv6の場合はIS-ISを実行することを選択できます。ここで考慮すべき重要な設計上の問題は、長期的に1つのIGPをサポートするか、2つの異なるIGPをサポートするかです。 [IPv6-DESIGN]は設計の選択に関するアドバイスを提示します
that arise when considering IGPs and discusses the advantages and disadvantages to different approaches in detail.
IGPを検討するときに発生し、さまざまなアプローチの利点と欠点を詳細に説明します。
The most common problem encountered in IPv6 networking is in applying the same principles of conservation that are so important in IPv4. IPv6 addresses do not need to be assigned conservatively. In fact, a single, larger allocation is considered more conservative than multiple non-contiguous small blocks because a single block occupies only a single entry in a routing table. The advice in [RFC5375] is still sound and is recommended to the reader. If considering ULAs, give careful thought to how well it is supported, especially in multiple address and multicast scenarios, and assess the strength of the requirement for ULA. [ULA-USAGE] provides much more detailed analysis and recommendations on the usage of ULAs.
IPv6ネットワーキングで遭遇する最も一般的な問題は、IPv4で非常に重要な保全の同じ原則を適用することです。 IPv6アドレスは、保守的に割り当てる必要はありません。実際、1つのブロックはルーティングテーブル内の1つのエントリしか占有しないため、1つの大きな割り当ては、連続しない複数の小さなブロックよりも保守的であると見なされます。 [RFC5375]のアドバイスはまだ健全であり、読者に推奨されます。 ULAを検討する場合は、特に複数のアドレスとマルチキャストのシナリオで、ULAがどの程度サポートされているかを慎重に検討し、ULAの要件の強さを評価してください。 [ULA-USAGE]は、ULAの使用に関するより詳細な分析と推奨事項を提供します。
The enterprise administrator will want to evaluate whether the enterprise will request address space from a Local Internet Registry (LIR) such as an ISP; a Regional Internet Registry (RIR) such as AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC; or a National Internet Registry (NIR) operated in some countries. The normal allocation is Provider-Aggregated (PA) address space from the enterprise's ISP, but use of PA space implies renumbering when changing providers. Instead, an enterprise may request Provider-Independent (PI) space; this may involve an additional fee, but the enterprise may then be better able to be multihomed using that prefix and will avoid a renumbering process when changing ISPs (though it should be noted that renumbering caused by outgrowing the space, merger, or other internal reason would still not be avoided with PI space).
エンタープライズ管理者は、エンタープライズがISPなどのローカルインターネットレジストリ（LIR）からアドレススペースを要求するかどうかを評価する必要があります。 AfriNIC、APNIC、ARIN、LACNIC、RIPE-NCCなどの地域インターネットレジストリ（RIR）。または一部の国で運営されているNational Internet Registry（NIR）。通常の割り当ては、企業のISPからのプロバイダー集約（PA）アドレス空間ですが、PA空間を使用すると、プロバイダーを変更するときに番号が付け直されます。代わりに、企業はプロバイダーに依存しない（PI）スペースを要求できます。これには追加料金がかかる場合がありますが、企業はそのプレフィックスを使用してマルチホーム化をより適切に行うことができ、ISPを変更するときに番号の付け直しプロセスを回避します（ただし、番号の付け直しは、スペースの拡大、合併、またはその他の内部的な理由により発生することに注意してください） PIスペースではまだ回避されません）。
The type of address selected (PI vs. PA) should be congruent with the routing needs of the enterprise. The selection of address type will determine if an operator will need to apply new routing techniques and may limit future flexibility. There is no right answer, but the needs of the External Phase may affect what address type is selected.
選択したアドレスのタイプ（PIとPA）は、企業のルーティングのニーズに一致している必要があります。アドレスタイプの選択により、オペレーターが新しいルーティング手法を適用する必要があるかどうかが決まり、将来の柔軟性が制限される可能性があります。正解はありませんが、外部フェーズのニーズによって、選択されるアドレスの種類が影響を受ける場合があります。
Each network location or site will need a prefix assignment. Depending on the type of site/location, various prefix sizes may be used. In general, historical guidance suggests that each site should get at least a /48, as documented in RFC 5375 and [RFC6177]. In addition to allowing for simple planning, this can allow a site to use its prefix for local connectivity, should the need arise, and if the local ISP supports it.
各ネットワークの場所またはサイトには、プレフィックスの割り当てが必要です。サイト/ロケーションのタイプに応じて、さまざまなプレフィックスサイズを使用できます。一般に、歴史的なガイダンスでは、RFC 5375および[RFC6177]で文書化されているように、各サイトは少なくとも/ 48を取得する必要があると示唆しています。これにより、単純な計画が可能になるだけでなく、必要に応じて、ローカルISPがサポートする場合に、サイトがローカル接続にそのプレフィックスを使用できるようになります。
When assigning addresses to end systems, the enterprise may use manually configured addresses (common on servers) or Stateless Address Autoconfiguration (SLAAC) or DHCPv6 for client systems.
エンドシステムにアドレスを割り当てる場合、企業は手動で構成されたアドレス（サーバーでは一般的）またはクライアントシステムにステートレスアドレス自動構成（SLAAC）またはDHCPv6を使用できます。
Early IPv6 enterprise deployments have used SLAAC both for its simplicity and the time DHCPv6 has taken to mature. However, DHCPv6 is now very mature; thus, workstations managed by an enterprise may use stateful DHCPv6 for addressing on corporate LAN segments. DHCPv6 allows for the additional configuration options often employed by enterprise administrators, and by using stateful DHCPv6, administrators correlating system logs know which system had which address at any given time. Such an accountability model is familiar from IPv4 management, though DHCPv6 hosts are identified by a DHCP Unique Identifier (DUID) rather than a MAC address. For equivalent accountability with SLAAC (and potentially privacy addresses), a monitoring system that harvests IP/MAC mappings from switch and router equipment could be used.
初期のIPv6エンタープライズ展開では、SLAACは、その単純さとDHCPv6が成熟するまでの時間の両方のために使用されていました。ただし、DHCPv6は現在非常に成熟しています。したがって、企業が管理するワークステーションは、企業LANセグメントのアドレス指定にステートフルDHCPv6を使用できます。 DHCPv6は、エンタープライズ管理者がよく使用する追加の構成オプションを可能にします。ステートフルDHCPv6を使用することにより、システムログを関連付ける管理者は、どのシステムにどのアドレスがどの時点であったかを認識します。 DHCPv6ホストはMACアドレスではなくDHCP一意識別子（DUID）によって識別されますが、そのようなアカウンタビリティモデルはIPv4管理からよく知られています。 SLAAC（および場合によってはプライバシーアドレス）と同等の説明責任を果たすために、スイッチおよびルーター機器からIP / MACマッピングを取得する監視システムを使用できます。
A common deployment consideration for any enterprise network is how to get host DNS records updated. Commonly, either the host will send DNS updates or the DHCP server will update records. If there is sufficient trust between the hosts and the DNS server, the hosts may update (and the enterprise may use SLAAC for addressing). Otherwise, the DHCPv6 server can be configured to update the DNS server. Note that an enterprise network with this more controlled environment will need to disable SLAAC on network segments and force end hosts to use DHCPv6 only.
エンタープライズネットワークの一般的な展開に関する考慮事項は、ホストDNSレコードを更新する方法です。通常、ホストはDNS更新を送信するか、DHCPサーバーがレコードを更新します。ホストとDNSサーバーの間に十分な信頼がある場合、ホストが更新される場合があります（企業はアドレス指定にSLAACを使用する場合があります）。それ以外の場合は、DNSサーバーを更新するようにDHCPv6サーバーを構成できます。このより制御された環境を持つエンタープライズネットワークでは、ネットワークセグメントでSLAACを無効にし、エンドホストがDHCPv6のみを使用するようにする必要があることに注意してください。
In the data center or server room, assume a /64 per VLAN. This applies even if each individual system is on a separate VLAN. In a /48 assignment, typical for a site, there are then still 65,535 /64 blocks. Some administrators reserve a /64 but configure a small subnet, such as /112, /126, or /127, to prevent rogue devices from attaching and getting numbers; an alternative is to monitor traffic for surprising addresses or Neighbor Discovery (ND) tables for new entries. Addresses are either configured manually on the server or reserved on a DHCPv6 server, which may also synchronize forward and reverse DNS (though see [RFC6866] for considerations on static addressing). SLAAC is not recommended for servers because of the need to synchronize RA timers with DNS Times to Live (TTLs) so that the DNS entry expires at the same time as the address.
データセンターまたはサーバールームでは、VLANごとに/ 64を想定しています。これは、個々のシステムが個別のVLAN上にある場合でも当てはまります。サイトに一般的な/ 48割り当てでは、65,535 / 64ブロックがまだあります。一部の管理者は/ 64を予約していますが、/ 112、/ 126、/ 127などの小さなサブネットを構成して、不正なデバイスが接続して番号を取得するのを防ぎます。別の方法は、新しいエントリの意外なアドレスまたは近隣探索（ND）テーブルのトラフィックを監視することです。アドレスは、サーバーで手動で構成するか、DHCPv6サーバーで予約します。DHCPv6サーバーは、フォワードDNSとリバースDNSを同期させることもできます（ただし、静的アドレッシングに関する考慮事項については、[RFC6866]を参照してください）。 DNSエントリがアドレスと同時に期限切れになるようにRAタイマーをDNS存続時間（TTL）と同期する必要があるため、SLAACはサーバーにはお勧めしません。
All user access networks should be a /64. Point-to-point links where NDP is not used may also utilize a /127 (see [RFC6164]).
すべてのユーザーアクセスネットワークは/ 64である必要があります。 NDPが使用されていないポイントツーポイントリンクは、/ 127も利用できます（[RFC6164]を参照）。
Plan to aggregate at every layer of network hierarchy. There is no need for variable length subnet mask (VLSM) [RFC1817] in IPv6, and addressing plans based on conservation of addresses are shortsighted. Use of prefixes longer then /64 on network segments will break common IPv6 functions such as SLAAC [RFC4862]. Where multiple VLANs or other Layer 2 domains converge, allow some room for expansion. Renumbering due to outgrowing the network plan is a nuisance, so allow room within it. Generally, plan to grow to about twice the current size that can be accommodated; where rapid growth is planned, allow for twice that growth. Also, if DNS (or reverse DNS) authority may be delegated to others in the enterprise, assignments need to be on nibble boundaries (that is, on a multiple of 4 bits, such as /64, /60, /56, ..., /48, /44), to ensure that delegated zones align with assigned prefixes.
ネットワーク階層のすべての層で集約することを計画します。 IPv6では可変長サブネットマスク（VLSM）[RFC1817]は必要なく、アドレスの保存に基づくアドレス指定計画は近視眼的です。ネットワークセグメントで/ 64よりも長いプレフィックスを使用すると、SLAAC [RFC4862]などの一般的なIPv6機能が無効になります。複数のVLANまたは他のレイヤー2ドメインが収束する場合は、拡張の余地を残してください。ネットワークプランの拡張による番号の付け直しは煩わしいので、その中に余裕を持たせてください。一般に、現在のサイズの約2倍に対応できるように拡張することを計画します。急速な成長が計画されている場合は、その2倍の成長を見込んでください。また、DNS（または逆DNS）権限が企業内の他のユーザーに委任される可能性がある場合、割り当てはニブル境界（つまり、/ 64、/ 60、/ 56などの4ビットの倍数）にある必要があります。 。、/ 48、/ 44）、委任されたゾーンが割り当てられたプレフィックスと一致するようにします。
If using ULAs, it is important to note that AAAA and PTR records for ULAs are not recommended to be installed in the global DNS. Similarly, reverse (address-to-name) queries for ULA must not be sent to name servers outside of the organization, due to the load that such queries would create for the authoritative name servers for the ip6.arpa zone. For more details, please refer to Section 4.4 of [RFC4193].
ULAを使用する場合、ULAのAAAAおよびPTRレコードをグローバルDNSにインストールすることは推奨されないことに注意することが重要です。同様に、ULAのリバース（アドレスから名前）クエリは、ip6.arpaゾーンの権限のあるネームサーバーに対して負荷がかかるため、組織外のネームサーバーに送信しないでください。詳細については、[RFC4193]のセクション4.4を参照してください。
Enterprise networks are increasingly including virtual networks where a single, physical node may host many virtualized addressable devices. It is imperative that the addressing plans assigned to these virtual networks and devices be consistent and non-overlapping with the addresses assigned to real networks and nodes. For example, a virtual network established within an isolated lab environment may, at a later time, become attached to the production enterprise network.
エンタープライズネットワークには、単一の物理ノードが多くの仮想化されたアドレス指定可能なデバイスをホストする仮想ネットワークがますます含まれています。これらの仮想ネットワークとデバイスに割り当てられたアドレス指定計画は、実際のネットワークとノードに割り当てられたアドレスと一貫しており、重複しないことが不可欠です。たとえば、分離されたラボ環境内で確立された仮想ネットワークは、後で本番環境のエンタープライズネットワークに接続される可能性があります。
Enterprises will often have a number of operational tools and support systems that are used to provision, monitor, manage, and diagnose the network and systems within their environment. These tools and systems will need to be assessed for compatibility with IPv6. The compatibility may be related to the addressing and connectivity of various devices as well as IPv6 awareness of the tools and processing logic.
多くの場合、企業には、環境内のネットワークとシステムのプロビジョニング、監視、管理、および診断に使用される多数の運用ツールとサポートシステムがあります。これらのツールとシステムは、IPv6との互換性について評価する必要があります。互換性は、さまざまなデバイスのアドレス指定と接続、およびツールと処理ロジックのIPv6認識に関連している可能性があります。
The tools within the organization fall into two general categories: those that focus on managing the network and those that are focused on managing systems and applications on the network. In either instance, the tools will run on platforms that may or may not be capable of operating in an IPv6 network. This lack in functionality may be related to operating system version or based on some hardware constraint. Those systems that are found to be incapable of utilizing an IPv6 connection, or which are dependent on an IPv4 stack, may need to be replaced or upgraded.
組織内のツールは2つの一般的なカテゴリに分類されます。ネットワークの管理に重点を置くツールと、ネットワーク上のシステムとアプリケーションの管理に重点を置くツールです。どちらの場合でも、ツールは、IPv6ネットワークで動作できるかどうかに関係なく、プラットフォームで実行されます。この機能の欠如は、オペレーティングシステムのバージョンに関連しているか、ハードウェアの制約に基づいている可能性があります。 IPv6接続を利用できないことが判明したシステム、またはIPv4スタックに依存しているシステムは、交換またはアップグレードする必要がある場合があります。
In addition to devices working on an IPv6 network natively, or via a transition tunnel, many tools and support systems may require additional software updates to be IPv6 aware or even a hardware upgrade (usually for additional memory, IPv6 addresses are larger and for a while, IPv4 and IPv6 addresses will coexist in the tool). This awareness may include the ability to manage IPv6 elements and/or applications in addition to the ability to store and utilize IPv6 addresses.
IPv6ネットワークでネイティブに、または移行トンネルを介して動作するデバイスに加えて、多くのツールとサポートシステムでは、IPv6に対応するために追加のソフトウェアの更新、またはハードウェアのアップグレードさえ必要になる場合があります（通常、追加のメモリの場合、IPv6アドレスはより大きく、しばらくの間） 、IPv4およびIPv6アドレスはツール内で共存します）。この認識には、IPv6アドレスを保存および利用する機能に加えて、IPv6要素やアプリケーションを管理する機能が含まれる場合があります。
Considerations when assessing the tools and support systems may include the fact that IPv6 addresses are significantly larger than IPv4, requiring data stores to support the increased size. Such issues are among those discussed in [RFC5952]. Many organizations may also run dual-stack networks; therefore, the tools need to not only support IPv6 operation but may also need to support the monitoring, management, and intersection with both IPv6 and IPv4 simultaneously. It is important to note that managing IPv6 is not just constrained to using large IPv6 addresses, but also that IPv6 interfaces and nodes are likely to use two or more addresses as part of normal operation. Updating management systems to deal with these additional nuances will likely consume time and considerable effort.
ツールとサポートシステムを評価する際の考慮事項には、IPv6アドレスがIPv4よりも大幅に大きいため、増加したサイズをサポートするためにデータストアが必要であるという事実が含まれる場合があります。このような問題は、[RFC5952]で説明されている問題の1つです。多くの組織がデュアルスタックネットワークを実行している場合もあります。したがって、ツールはIPv6の運用をサポートするだけでなく、監視、管理、およびIPv6とIPv4の両方との交差を同時にサポートする必要がある場合があります。 IPv6の管理は大きなIPv6アドレスの使用に制限されるだけでなく、IPv6インターフェースとノードは通常の操作の一部として2つ以上のアドレスを使用する可能性があることに注意することが重要です。これらの追加のニュアンスに対処するために管理システムを更新すると、時間とかなりの労力が費やされる可能性があります。
For networking systems, like node management systems, it is not always necessary to support local IPv6 addressing and connectivity. Operations such as SNMP MIB polling can occur over IPv4 transport while seeking responses related to IPv6 information. Where this may seem advantageous to some, it should be noted that without local IPv6 connectivity, the management system may not be able to perform all expected functions -- such as reachability and service checks.
ノード管理システムのようなネットワーキングシステムの場合、ローカルIPv6アドレッシングと接続をサポートする必要は必ずしもありません。 SNMP MIBポーリングなどの操作は、IPv6情報に関連する応答をシークしながら、IPv4トランスポート上で発生する可能性があります。一部のユーザーにとってこれが有利に思えるかもしれませんが、ローカルIPv6接続がないと、管理システムは、到達可能性やサービスチェックなど、予想されるすべての機能を実行できない可能性があることに注意してください。
Organizations should be aware that changes to older IPv4-only SNMP MIB specifications have been made by the IETF and are related to legacy operation in [RFC2096] and [RFC2011]. Updated specifications are now available in [RFC4292] and [RFC4293] that modified the older MIB framework to be IP protocol agnostic, supporting both IPv4 and IPv6. Polling systems will need to be upgraded to support these updates as well as the end stations, which are polled.
組織は、古いIPv4のみのSNMP MIB仕様に対する変更がIETFによって行われ、[RFC2096]および[RFC2011]のレガシー操作に関連していることを認識しておく必要があります。 [RFC4292]と[RFC4293]で更新された仕様が利用可能になり、古いMIBフレームワークがIPプロトコルにとらわれず、IPv4とIPv6の両方をサポートするように変更されました。これらのアップデートと、ポーリングされるエンドステーションをサポートするには、ポーリングシステムをアップグレードする必要があります。
The External Phase for enterprise IPv6 adoption covers topics that deal with how an organization connects its infrastructure to the external world. These external connections may be toward the Internet at large or to other networks. The External Phase covers connectivity, security and monitoring of various elements, and outward-facing or accessible services.
エンタープライズIPv6導入の外部フェーズでは、組織がインフラストラクチャを外部の世界に接続する方法を扱うトピックを扱います。これらの外部接続は、インターネット全体または他のネットワークに対するものです。外部フェーズでは、さまざまな要素の接続、セキュリティ、監視、および外部に面したサービスやアクセス可能なサービスを扱います。
The enterprise will need to work with one or more service providers to gain connectivity to the Internet or transport service infrastructure such as a BGP/MPLS IP VPN as described in [RFC4364] and [RFC4659]. One significant factor that will guide how an organization may need to communicate with the outside world will involve the use of PI and/or PA IPv6 space.
企業は、[RFC4364]と[RFC4659]で説明されているように、BGP / MPLS IP VPNなどのインターネットまたはトランスポートサービスインフラストラクチャに接続するために、1つ以上のサービスプロバイダーと協力する必要があります。組織が外の世界とどのように通信する必要があるかを導く重要な要素の1つは、PIおよび/またはPA IPv6スペースの使用に関係します。
Enterprises should be aware that, depending on which address type they selected (PI vs. PA) in their planning phase, they may need to implement new routing functions and/or behaviors to support their connectivity to the ISP. In the case of PI, the upstream ISP may offer options to route the prefix (typically a /48) on the enterprise's behalf and update the relevant routing databases. Otherwise, the enterprise may need to perform this task on their own and use BGP to inject the prefix into the global BGP system.
企業は、計画段階で選択したアドレスの種類（PIとPA）に応じて、ISPへの接続をサポートするために新しいルーティング機能や動作を実装する必要がある場合があることに注意する必要があります。 PIの場合、上流のISPは、企業に代わってプレフィックス（通常は/ 48）をルーティングし、関連するルーティングデータベースを更新するオプションを提供します。そうでない場合、企業はこのタスクを自分で実行し、BGPを使用してプレフィックスをグローバルBGPシステムに挿入する必要がある場合があります。
Note that the rules set by the RIRs for an enterprise acquiring PI address space have changed over time. For example, in the European region, the RIPE-NCC no longer requires an enterprise to be multihomed to be eligible for an IPv6 PI allocation. Requests can be made directly or via a LIR. It is possible that the rules may change again and may vary between RIRs.
企業がPIアドレス空間を取得するためにRIRによって設定されたルールは、時間の経過とともに変化していることに注意してください。たとえば、ヨーロッパ地域では、RIPE-NCCはIPv6 PI割り当ての対象となるために企業がマルチホームである必要がなくなりました。リクエストは直接またはLIR経由で行うことができます。ルールが再度変更され、RIR間で異なる可能性があります。
When seeking IPv6 connectivity to a service provider, native IPv6 connectivity is preferred since it provides the most robust and efficient form of connectivity. If native IPv6 connectivity is not possible due to technical or business limitations, the enterprise may utilize readily available transition tunnel IPv6 connectivity. There are IPv6 transit providers that provide robust tunneled IPv6 connectivity that can operate over IPv4 networks. It is important to understand the transition-tunnel mechanism used and to consider that it will have higher latency than native IPv4 or IPv6, and may have other problems, e.g., related to MTUs.
サービスプロバイダーへのIPv6接続を求める場合、ネイティブのIPv6接続が最も堅牢で効率的な形式の接続を提供するので、ネイティブIPv6接続が推奨されます。技術的またはビジネス上の制限のためにネイティブIPv6接続が不可能な場合、企業はすぐに利用できる移行トンネルIPv6接続を利用することがあります。 IPv4ネットワーク上で動作できる堅牢なトンネルIPv6接続を提供するIPv6トランジットプロバイダーがあります。使用される遷移トンネルメカニズムを理解し、ネイティブIPv4またはIPv6よりもレイテンシが高く、MTUなどの他の問題が発生する可能性があることを考慮することが重要です。
It is important to evaluate MTU considerations when adding IPv6 to an existing IPv4 network. It is generally desirable to have the IPv6 and IPv4 MTU congruent to simplify operations (so the two address families behave similarly, that is, as expected). If the enterprise uses transition tunnels inside or externally for IPv6 connectivity, then modification of the MTU on hosts/routers may be needed as mid-stream fragmentation is no longer supported in IPv6. It is preferred that Path MTU Discovery (pMTUD) be used to optimize the MTU, so erroneous filtering of the related ICMPv6 message types should be monitored. Adjusting the MTU may be the only option if undesirable upstream ICMPv6 filtering cannot be removed.
既存のIPv4ネットワークにIPv6を追加するときは、MTUの考慮事項を評価することが重要です。運用を簡素化するために、IPv6とIPv4のMTUを一致させることが一般的に望ましいです（そのため、2つのアドレスファミリは同様に、つまり期待どおりに動作します）。企業がIPv6接続の内部または外部でトランジショントンネルを使用する場合、IPv6ではミッドストリームフラグメンテーションがサポートされなくなったため、ホスト/ルーターのMTUの変更が必要になる場合があります。 Path MTU Discovery（pMTUD）を使用してMTUを最適化することをお勧めします。そのため、関連するICMPv6メッセージタイプの誤ったフィルタリングを監視する必要があります。望ましくない上流のICMPv6フィルタリングを削除できない場合は、MTUの調整が唯一のオプションとなる場合があります。
The most important part of security for external IPv6 deployment is filtering and monitoring. Filtering can be done by stateless ACLs or a stateful firewall. The security policies must be consistent for IPv4 and IPv6 (or else the attacker will use the less-protected protocol stack), except that certain ICMPv6 messages must be allowed through and to the filtering device (see [RFC4890]):
外部IPv6展開のセキュリティの最も重要な部分は、フィルタリングと監視です。フィルタリングは、ステートレスACLまたはステートフルファイアウォールによって実行できます。セキュリティポリシーはIPv4とIPv6で一貫している必要があります（そうでない場合、攻撃者はより保護されていないプロトコルスタックを使用します）。ただし、特定のICMPv6メッセージがフィルタリングデバイスを通過できるようにする必要があります（[RFC4890]を参照）。
o Packet Too Big: essential to allow Path MTU discovery to work
o 大きすぎるパケット：パスMTUディスカバリーが機能するために不可欠
o Parameter Problem
o パラメータの問題
o Time Exceeded
o 時間超過
In addition, NDP messages (including Neighbor Solicitation, RAs, etc.) are required for local hosts.
さらに、ローカルホストにはNDPメッセージ（近隣要請、RAなどを含む）が必要です。
It could also be safer to block all fragments where the transport layer header is not in the first fragment to avoid attacks as described in [RFC5722]. Some filtering devices allow this filtering. Ingress filters and firewalls should follow [RFC5095] in handling routing extension header type 0, dropping the packet and sending ICMPv6 Parameter Problem, unless Segments Left = 0 (in which case, ignore the header).
[RFC5722]で説明されているように、攻撃を回避するために、トランスポート層ヘッダーが最初のフラグメントにないすべてのフラグメントをブロックする方が安全な場合もあります。一部のフィルタリングデバイスでは、このフィルタリングが可能です。入力フィルターとファイアウォールは、[RFC5095]に従ってルーティング拡張ヘッダータイプ0を処理し、パケットをドロップしてICMPv6パラメーター問題を送信する必要があります。
If an IPS is used for IPv4 traffic, then an IPS should also be used for IPv6 traffic. In general, make sure IPv6 security is at least as good as IPv4. This also includes all email content protection (anti-spam, content filtering, data leakage prevention, etc.).
IPv4トラフィックにIPSを使用する場合は、IPv6トラフィックにもIPSを使用する必要があります。一般に、IPv6セキュリティが少なくともIPv4と同等であることを確認してください。これには、すべての電子メールコンテンツ保護（スパム対策、コンテンツフィルタリング、データ漏洩防止など）も含まれます。
The edge router must also implement anti-spoofing techniques based on [RFC2827] (also known as BCP 38).
エッジルーターは、[RFC2827]（BCP 38とも呼ばれる）に基づくスプーフィング対策技術も実装する必要があります。
In order to protect the networking devices, it is advised to implement control plane policing as per [RFC6192].
ネットワーキングデバイスを保護するために、[RFC6192]のようにコントロールプレーンポリシングを実装することをお勧めします。
The potential NDP cache exhaustion attack (see [RFC6583]) can be mitigated by two techniques:
潜在的なNDPキャッシュ枯渇攻撃（[RFC6583]を参照）は、次の2つの手法で軽減できます。
o Good NDP implementation with memory utilization limits as well as rate limiters and prioritization of requests.
o メモリ使用率制限、レートリミッター、および要求の優先順位付けを備えた優れたNDP実装。
o Or, as the external deployment usually involves just a couple of exposed statically configured IPv6 addresses (virtual addresses of web, email, and DNS servers), then it is straightforward to build an ingress ACL allowing traffic for those addresses and denying traffic to any other addresses. This actually prevents the attack as a packet for a random destination will be dropped and will never trigger a neighbor resolution.
oまたは、外部展開には通常、公開された静的に構成されたIPv6アドレス（ウェブ、メール、DNSサーバーの仮想アドレス）のほんの一部しか含まれていないため、これらのアドレスのトラフィックを許可し、任意のトラフィックを拒否する入力ACLを構築するのは簡単です他のアドレス。これにより、ランダムな宛先のパケットがドロップされ、ネイバー解決がトリガーされることはないため、実際には攻撃が防止されます。
Monitoring the use of the Internet connectivity should be done for IPv6 as it is done for IPv4. This includes the use of IPFIX [RFC7012] to report abnormal traffic patterns (such as port scanning, SYN flooding, and related IP source addresses) from monitoring tools and evaluating data read from SNMP MIBs [RFC4293] (some of which also enable the detection of abnormal bandwidth utilization) and syslogs (finding server and system errors). Where NetFlow is used, Version 9 is required for IPv6 support. Monitoring systems should be able to examine IPv6 traffic, use IPv6 for connectivity, and record IPv6 addresses, and any log parsing tools and reporting need to support IPv6. Some of this data can be sensitive (including personally identifiable information) and care in securing it should be taken, with periodic purges. Integrity protection on logs and sources of log data is also important to detect unusual behavior (misconfigurations or attacks). Logs may be used in investigations, which depend on trustworthy data sources (tamper resistant).
インターネット接続の使用の監視は、IPv4の場合と同様にIPv6でも行う必要があります。これには、監視ツールからの異常なトラフィックパターン（ポートスキャン、SYNフラッディング、関連するIP送信元アドレスなど）を報告するためのIPFIX [RFC7012]の使用と、SNMP MIB [RFC4293]から読み取られたデータの評価が含まれます（一部は検出も可能にします）異常な帯域幅使用率）およびsyslog（サーバーおよびシステムエラーの検出）。 NetFlowを使用する場合、IPv6をサポートするにはバージョン9が必要です。監視システムは、IPv6トラフィックを検査し、接続にIPv6を使用し、IPv6アドレスを記録し、IPv6をサポートするために必要なログ解析ツールとレポート機能が必要です。このデータの一部は機密情報（個人を特定できる情報を含む）になる可能性があり、定期的なパージを行うことで、データの保護に注意する必要があります。ログとログデータのソースの整合性保護は、異常な動作（設定ミスや攻撃）を検出するためにも重要です。ログは、信頼できるデータソース（改ざん防止）に依存する調査で使用される場合があります。
In addition, monitoring of external services (such as web sites) should be made address specific, so that people are notified when either the IPv4 or IPv6 version of a site fails.
さらに、外部サービス（Webサイトなど）の監視をアドレス固有にして、サイトのIPv4またはIPv6バージョンのいずれかが失敗したときに通知されるようにする必要があります。
The path to the servers accessed from the Internet usually involves security devices (firewall and IPS), server load balancing (SLB), and real physical servers. The latter stage is also multi-tiered for scalability and security between presentation and data storage. The ideal transition is to enable native dual stack on all devices; but as part of the phased approach, operators have used the following techniques with success:
インターネットからアクセスされるサーバーへのパスには、通常、セキュリティデバイス（ファイアウォールおよびIPS）、サーバーロードバランシング（SLB）、および実際の物理サーバーが含まれます。後者のステージも、プレゼンテーションとデータストレージ間のスケーラビリティとセキュリティのために多層化されています。理想的な移行は、すべてのデバイスでネイティブデュアルスタックを有効にすることです。しかし、段階的アプローチの一環として、オペレーターは次の手法を使用して成功しました。
o Use a network device to apply NAT64 and basically translate an inbound TCP connection (or any other transport protocol) over IPv6 into a TCP connection over IPv4. This is the easiest to deploy as the path is mostly unchanged, but it hides all IPv6 remote users behind a single IPv4 address, which leads to several audit trail and security issues (see [RFC6302]).
o ネットワークデバイスを使用してNAT64を適用し、基本的にIPv6を介した着信TCP接続（またはその他のトランスポートプロトコル）をIPv4を介したTCP接続に変換します。パスはほとんど変更されないため、これは最も簡単に展開できますが、すべてのIPv6リモートユーザーを単一のIPv4アドレスの背後に隠し、いくつかの監査証跡とセキュリティの問題を引き起こします（[RFC6302]を参照）。
o Use the server load balancer, which acts as an application proxy to do this translation. Compared to the NAT64, it has the potential benefit of going through the security devices as native IPv6 (so more audit and trace abilities) and is also able to insert an HTTP X-Forward-For header that contains the remote IPv6 address. The latter feature allows for logging and rate limiting on the real servers based on the IPV6 address even if those servers run only IPv4.
oこの変換を行うアプリケーションプロキシとして機能するサーバーロードバランサーを使用します。 NAT64と比較して、ネイティブIPv6としてセキュリティデバイスを通過できるという利点があります（監査機能とトレース機能が多い）。また、リモートIPv6アドレスを含むHTTP X-Forward-Forヘッダーを挿入できます。後者の機能では、サーバーがIPv4のみを実行している場合でも、IPV6アドレスに基づいて実サーバーでのロギングとレート制限が可能です。
In either of these cases, care should be taken to secure logs for privacy reasons and to periodically purge them.
これらのいずれの場合でも、プライバシー上の理由からログを保護し、ログを定期的に削除するように注意する必要があります。
Network Prefix Translation for IPv6, or NPTv6 as described in [RFC6296], provides a framework to utilize prefix ranges within the internal network that are separate (address independent) from the assigned prefix from the upstream provider or registry. As mentioned above, while NPTv6 has potential use cases in IPv6 networks, the implications of its deployment need to be fully understood, particularly where any applications might embed IPv6 addresses in their payloads.
[RFC6296]で説明されているIPv6のネットワークプレフィックス変換、またはNPTv6は、上流のプロバイダーまたはレジストリから割り当てられたプレフィックスとは別の（アドレスに依存しない）内部ネットワーク内のプレフィックス範囲を利用するフレームワークを提供します。上記のように、NPTv6にはIPv6ネットワークでの潜在的な使用例がありますが、特にアプリケーションがペイロードにIPv6アドレスを埋め込む可能性がある場合、その配備の影響を完全に理解する必要があります。
Use of NPTv6 can be chosen independently from how addresses are assigned and routed within the internal network, how prefixes are routed towards the Internet, or whether PA or PI addresses are used.
NPTv6の使用は、内部ネットワーク内でのアドレスの割り当て方法とルーティング方法、インターネットへのプレフィックスのルーティング方法、またはPAアドレスとPIアドレスのどちらを使用するかとは無関係に選択できます。
This phase deals with the delivery of IPv6 to the internal user-facing side of the Information Technology (IT) infrastructure, which comprises various components such as network devices (routers, switches, etc.), end-user devices and peripherals (workstations, printers, etc.), and internal corporate systems.
このフェーズでは、ネットワークデバイス（ルーター、スイッチなど）、エンドユーザーデバイス、および周辺機器（ワークステーションなど）のさまざまなコンポーネントで構成される、情報技術（IT）インフラストラクチャの内部ユーザー側へのIPv6の配信を扱います。プリンターなど）、社内のシステム。
An important design paradigm to consider during this phase is "dual stack when you can, tunnel when you must". Dual stacking allows a more robust, production-quality IPv6 network than is typically facilitated by internal use of transition tunnels that are harder to troubleshoot and support, and that may introduce scalability and performance issues. Of course, tunnels may still be used in production networks, but their use needs to be carefully considered, e.g., where the transition tunnel may be run through a security or filtering device. Tunnels do also provide a means to experiment with IPv6 and gain some operational experience with the protocol. [RFC4213] describes various transition mechanisms in more detail. [RFC6964] suggests operational guidance when using Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) tunnels [RFC5214], though we would recommend use of dual stack wherever possible.
このフェーズで考慮すべき重要な設計パラダイムは、「可能な場合はデュアルスタック、必要な場合はトンネル」です。デュアルスタッキングにより、トラブルシューティングとサポートが困難であり、スケーラビリティとパフォーマンスの問題を引き起こす可能性のある遷移トンネルの内部使用によって通常促進されるよりも、堅牢で生産品質のIPv6ネットワークが可能になります。もちろん、トンネルはまだ本番ネットワークで使用されている可能性がありますが、たとえば、トランジショントンネルがセキュリティまたはフィルタリングデバイスを介して実行される可能性がある場合は、その使用を慎重に検討する必要があります。トンネルは、IPv6を実験してプロトコルの運用経験を積む手段も提供します。 [RFC4213]は、さまざまな移行メカニズムをより詳細に説明しています。 [RFC6964]は、サイト内自動トンネルアドレスプロトコル（ISATAP）トンネル[RFC5214]を使用する場合の運用ガイダンスを提案していますが、可能な限りデュアルスタックを使用することをお勧めします。
IPv6 must be deployed in a secure way. This means that all existing IPv4 security policies must be extended to support IPv6; IPv6 security policies will be the IPv6 equivalent of the existing IPv4 ones (taking into account the difference for ICMPv6 [RFC4890]). As in IPv4, security policies for IPv6 will be enforced by firewalls, ACL, IPS, VPN, and so on.
IPv6は安全な方法で展開する必要があります。つまり、IPv6をサポートするには、既存のすべてのIPv4セキュリティポリシーを拡張する必要があります。 IPv6セキュリティポリシーは、既存のIPv4ポリシーと同等のIPv6になります（ICMPv6 [RFC4890]の違いを考慮に入れて）。 IPv4と同様に、IPv6のセキュリティポリシーはファイアウォール、ACL、IPS、VPNなどによって適用されます。
Privacy extension addresses [RFC4941] raise a challenge for an audit trail as explained in Section 2.4.3 of this document. The enterprise may choose to attempt to enforce use of DHCPv6 or deploy monitoring tools that harvest accountability data from switches and routers (thus making the assumption that devices may use any addresses inside the network).
プライバシー拡張アドレス[RFC4941]は、このドキュメントのセクション2.4.3で説明されているように、監査証跡の課題を提起します。企業は、DHCPv6の使用を強制するか、スイッチとルーターからアカウンタビリティデータを収集する監視ツールを展開することを選択できます（したがって、デバイスはネットワーク内の任意のアドレスを使用できると想定しています）。
One major issue is threats against ND. This means, for example, that the internal network at the access layer (where hosts connect to the network over wired or wireless) should implement RA-Guard [RFC6105] and the techniques being specified by the SAVI WG [RFC6959]; see also Section 2.4.3 of this document for more information.
主要な問題の1つは、NDに対する脅威です。これは、たとえば、アクセスレイヤーの内部ネットワーク（ホストが有線または無線でネットワークに接続する場所）がRA-Guard [RFC6105]とSAVI WG [RFC6959]で指定されている手法を実装する必要があることを意味します。詳細については、このドキュメントのセクション2.4.3も参照してください。
The typical enterprise network infrastructure comprises a combination of the following network elements -- wired access switches, wireless access points, and routers (although it is fairly common to find hardware that collapses switching and routing functionality into a single device). Basic wired access switches and access points operate only at the physical and link layers and don't really have any special IPv6 considerations other than being able to support IPv6 addresses themselves for management purposes. In many instances, these devices possess a lot more intelligence than simply switching packets. For example, some of these devices help assist with link-layer security by incorporating features such as ARP inspection and DHCP snooping, or they may help limit where multicast floods by using IGMP (or, in the case of IPv6, Multicast Listener Discovery (MLD)) snooping.
一般的なエンタープライズネットワークインフラストラクチャは、有線アクセススイッチ、ワイヤレスアクセスポイント、ルーターなどのネットワーク要素の組み合わせで構成されています（スイッチングとルーティングの機能を単一のデバイスに集約するハードウェアを見つけることはかなり一般的です）。基本的な有線アクセススイッチとアクセスポイントは物理層とリンク層でのみ動作し、IPv6アドレス自体を管理目的でサポートできること以外は、IPv6に関する特別な考慮事項はありません。多くの場合、これらのデバイスは単にパケットを交換するよりもはるかに多くのインテリジェンスを備えています。たとえば、これらのデバイスの一部は、ARPインスペクションやDHCPスヌーピングなどの機能を組み込むことでリンク層セキュリティの支援に役立ち、IGMP（または、IPv6の場合はマルチキャストリスナーディスカバリー（MLD ）） 詮索する。
Another important consideration in enterprise networks is first-hop router redundancy. This directly ties into network reachability from an end host's point of view. IPv6 ND [RFC4861] provides a node with the capability to maintain a list of available routers on the link, in order to be able to switch to a backup path should the primary be unreachable. By default, ND will detect a router failure in 38 seconds and cycle onto the next default router listed in its cache. While this feature provides a basic level of first-hop router redundancy, most enterprise IPv4 networks are designed to fail over much faster. Although this delay can be improved by adjusting the default timers, care must be taken to protect against transient failures and to account for increased traffic on the link. Another option in which to provide robust first-hop redundancy is to use the Virtual Router Redundancy Protocol Version 3 (VRRPv3) for IPv6 [RFC5798]. This protocol provides a much faster switchover to an alternate default router than default ND parameters. Using VRRPv3, a backup router can take over for a failed default router in around three seconds (using VRRPv3 default parameters). This is done without any interaction with the hosts and a minimum amount of VRRP traffic.
エンタープライズネットワークにおけるもう1つの重要な考慮事項は、ファーストホップルーターの冗長性です。これは、エンドホストの観点から、ネットワークの到達可能性に直接結びついています。 IPv6 ND [RFC4861]は、プライマリに到達できない場合にバックアップパスに切り替えることができるように、リンクで利用可能なルーターのリストを維持する機能をノードに提供します。デフォルトでは、NDはルーターの障害を38秒で検出し、キャッシュにリストされている次のデフォルトルーターに循環します。この機能はファーストホップルーターの基本レベルの冗長性を提供しますが、ほとんどのエンタープライズIPv4ネットワークはフェイルオーバーがはるかに速くなるように設計されています。この遅延は、デフォルトのタイマーを調整することで改善できますが、一時的な障害から保護し、リンク上のトラフィックの増加に対処するように注意する必要があります。堅牢なファーストホップ冗長性を提供する別のオプションは、IPv6の仮想ルーター冗長プロトコルバージョン3（VRRPv3）を使用することです[RFC5798]。このプロトコルは、デフォルトのNDパラメータよりもはるかに高速な代替デフォルトルータへのスイッチオーバーを提供します。 VRRPv3を使用すると、障害が発生したデフォルトルータをバックアップルータが約3秒で引き継ぐことができます（VRRPv3デフォルトパラメータを使用）。これは、ホストとの対話や最小量のVRRPトラフィックなしで行われます。
Last but not least, one of the most important design choices to make while deploying IPv6 on the internal network is whether to use SLAAC [RFC4862], the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315], or a combination thereof. Each option has advantages and disadvantages, and the choice will ultimately depend on the operational policies that guide each enterprise's network design. For example, if an enterprise is looking for ease of use, rapid deployment, and less administrative overhead, then SLAAC makes more sense for workstations. Manual or DHCPv6 assignments are still needed for servers, as described in the Address Plan and External Phase sections of this document; see Sections 2.6 and 3, respectively. However, if the operational policies call for precise control over IP address assignment for auditing, then DHCPv6 may be preferred. DHCPv6 also allows you to tie into DNS systems for host entry updates and gives you the ability to send other options and information to clients. It is worth noting that in general operation, RAs are still needed in DHCPv6 networks, as there is no DHCPv6 Default Gateway option. Similarly, DHCPv6 is needed in RA networks for other configuration information, e.g., NTP servers or, in the absence of support for DNS resolvers in RAs [RFC6106], DNS resolver information.
最後に重要なことですが、内部ネットワークにIPv6を展開するときに行う最も重要な設計選択の1つは、SLAAC [RFC4862]、IPv6の動的ホスト構成プロトコル（DHCPv6）[RFC3315]、またはそれらの組み合わせを使用するかどうかです。各オプションには長所と短所があり、選択は最終的には各企業のネットワーク設計を導く運用ポリシーに依存します。たとえば、企業が使いやすさ、迅速な展開、および管理オーバーヘッドの削減を求めている場合、SLAACはワークステーションに適しています。このドキュメントのアドレス計画と外部フェーズのセクションで説明されているように、サーバーには手動またはDHCPv6の割り当てが引き続き必要です。セクション2.6および3をそれぞれ参照してください。ただし、運用ポリシーで監査のためにIPアドレスの割り当てを正確に制御する必要がある場合は、DHCPv6を使用することをお勧めします。 DHCPv6を使用すると、ホストエントリの更新のためにDNSシステムに接続し、他のオプションや情報をクライアントに送信することができます。 DHCPv6デフォルトゲートウェイオプションがないため、一般的な運用ではDHCPv6ネットワークでRAが必要であることは注目に値します。同様に、DHCPネットワークは、その他の構成情報（NTPサーバーなど）のためにRAネットワークで必要です。また、RA [RFC6106]でDNSリゾルバーがサポートされていない場合は、DNSリゾルバー情報が必要です。
Most operating systems (OSes) that are loaded on workstations and laptops in a typical enterprise support IPv6 today. However, there are various out-of-the-box nuances that one should be mindful about. For example, the default behavior of OSes vary; some may have IPv6 turned off by default, some may only have certain features such as privacy extensions to IPv6 addresses (RFC 4941) turned off, while others have IPv6 fully enabled. Further, even when IPv6 is enabled, the choice of which address is used may be subject to source address selection (RFC 6724) and Happy Eyeballs (RFC 6555). Therefore, it is advised that enterprises investigate the default behavior of their installed OS base and account for it during the Inventory Phases of their IPv6 preparations. Furthermore, some OSes may have some transition tunneling mechanisms turned on by default, and in such cases, it is recommended to administratively shut down such interfaces unless required.
一般的な企業のワークステーションやラップトップに搭載されているほとんどのオペレーティングシステム（OS）は、現在IPv6をサポートしています。ただし、気を付けなければならない、すぐに使用できるさまざまなニュアンスがあります。たとえば、OSのデフォルトの動作はさまざまです。 IPv6がデフォルトでオフになっているものもあれば、IPv6アドレスへのプライバシー拡張（RFC 4941）がオフになっているなどの特定の機能しかないものもあれば、IPv6が完全に有効になっているものもあります。さらに、IPv6が有効になっている場合でも、どのアドレスを使用するかの選択は、送信元アドレスの選択（RFC 6724）およびHappy Eyeballs（RFC 6555）の影響を受ける場合があります。したがって、企業は、インストールされているOSベースのデフォルトの動作を調査し、IPv6準備のインベントリフェーズ中にそれを説明することをお勧めします。さらに、OSによってはデフォルトで遷移トンネリングメカニズムがオンになっている場合があります。そのような場合は、必要でない限り、そのようなインターフェイスを管理上シャットダウンすることをお勧めします。
It is important to note that it is recommended that IPv6 be deployed at the network and system infrastructure level before it is rolled out to end-user devices; ensure IPv6 is running and routed on the wire, and secure and correctly monitored, before exposing IPv6 to end users.
エンドユーザーデバイスに展開する前に、IPv6をネットワークおよびシステムインフラストラクチャレベルで展開することをお勧めします。エンドユーザーにIPv6を公開する前に、IPv6が実行されてネットワーク上でルーティングされ、安全で正しく監視されていることを確認します。
Smartphones and tablets are significant IPv6-capable platforms, depending on the support of the carrier's data network.
スマートフォンとタブレットは、キャリアのデータネットワークのサポートに応じて、重要なIPv6対応プラットフォームです。
IPv6 support for peripherals varies. Much like servers, printers are generally configured with a static address (or DHCP reservation) so clients can discover them reliably.
周辺機器のIPv6サポートはさまざまです。サーバーと同様に、プリンターは通常、静的アドレス（またはDHCP予約）で構成されているため、クライアントは確実にそれらを検出できます。
No IPv6 deployment will be successful without ensuring that all the corporate systems that an enterprise uses as part of its IT infrastructure support IPv6. Examples of such systems include, but are not limited to, email, video conferencing, telephony (VoIP), DNS, RADIUS, etc. All these systems must have their own detailed IPv6 rollout plan in conjunction with the network IPv6 rollout. It is important to note that DNS is one of the main anchors in an enterprise deployment, since most end hosts decide whether or not to use IPv6 depending on the presence of IPv6 AAAA records in a reply to a DNS query. It is recommended that system administrators selectively turn on AAAA records for various systems as and when they are IPv6 enabled; care must be taken though to ensure all services running on that host name are IPv6 enabled before adding the AAAA record. Care with web proxies is advised; a mismatch in the level of IPv6 support between the client, proxy, and server can cause communication problems. All monitoring and reporting tools across the enterprise will need to be modified to support IPv6.
企業がITインフラストラクチャの一部として使用するすべての企業システムがIPv6をサポートしていることを確認しない限り、IPv6の展開は成功しません。そのようなシステムの例には、電子メール、ビデオ会議、テレフォニー（VoIP）、DNS、RADIUSなどが含まれますが、これらに限定されません。これらすべてのシステムには、ネットワークIPv6ロールアウトと併せて独自の詳細なIPv6ロールアウト計画が必要です。 DNSはエンタープライズ展開における主要なアンカーの1つであることに注意してください。ほとんどのエンドホストは、DNSクエリへの応答にIPv6 AAAAレコードが存在するかどうかに応じてIPv6を使用するかどうかを決定するためです。システム管理者は、さまざまなシステムのIPv6が有効になっているときに、AAAAレコードを選択的にオンにすることをお勧めします。ただし、AAAAレコードを追加する前に、そのホスト名で実行されているすべてのサービスでIPv6が有効になっていることを確認する必要があります。 Webプロキシでのケアをお勧めします。クライアント、プロキシ、サーバー間のIPv6サポートのレベルが一致しないと、通信の問題が発生する可能性があります。企業全体のすべての監視およびレポートツールは、IPv6をサポートするように変更する必要があります。
Early IPv6 enterprise deployments have generally taken a dual-stack approach to enabling IPv6, i.e., the existing IPv4 services have not been turned off. Although IPv4 and IPv6 networks will coexist for a long time, the long-term enterprise network roadmap should include steps to simplify engineering and operations by deprecating IPv4 from the dual-stack network. In some extreme cases, deploying dual-stack networks may not even be a viable option for very large enterprises due to the address space described in RFC 1918 not being large enough to support the network's growth. In such cases, deploying IPv6-only networks might be the only choice available to sustain network growth. In other cases, there may be elements of an otherwise dual-stack network that may be run in IPv6 only.
初期のIPv6エンタープライズ展開では、IPv6を有効にするために一般にデュアルスタックアプローチが採用されていました。つまり、既存のIPv4サービスはオフにされていません。 IPv4とIPv6ネットワークは長期間共存しますが、長期的なエンタープライズネットワークロードマップには、デュアルスタックネットワークからIPv4を廃止することにより、エンジニアリングと運用を簡素化する手順を含める必要があります。極端な場合には、RFC 1918に記載されているアドレス空間がネットワークの成長をサポートするのに十分な大きさではないため、デュアルスタックネットワークの導入は、非常に大規模な企業にとっては実行可能なオプションではない場合もあります。このような場合、IPv6のみのネットワークを展開することが、ネットワークの成長を維持するために利用できる唯一の選択肢となる可能性があります。他の場合では、IPv6のみで実行できるデュアルスタックネットワークの要素が存在する場合があります。
If nodes in the network don't need to talk to an IPv4-only node, then deploying IPv6-only networks should be straightforward. However, most nodes will need to communicate with some IPv4-only nodes; an IPv6-only node may, therefore, require a translation mechanism. As [RFC6144] points out, it is important to look at address translation as a transition strategy towards running an IPv6-only network.
ネットワーク内のノードがIPv4のみのノードと通信する必要がない場合、IPv6のみのネットワークの導入は簡単です。ただし、ほとんどのノードは一部のIPv4専用ノードと通信する必要があります。したがって、IPv6のみのノードには変換メカニズムが必要な場合があります。 [RFC6144]が指摘するように、IPv6のみのネットワークを実行するための移行戦略としてアドレス変換を検討することが重要です。
There are various stateless and stateful IPv4/IPv6 translation methods available today that help IPv6-to-IPv4 communication. RFC 6144 provides a framework for IPv4/IPv6 translation and describes in detail various scenarios in which such translation mechanisms could be used. [RFC6145] describes stateless address translation. In this mode, a specific IPv6 address range will represent IPv4 systems (IPv4-converted addresses), and the IPv6 systems have addresses (IPv4-translatable addresses) that can be algorithmically mapped to a subset of the service provider's IPv4 addresses. NAT64 [RFC6146] describes stateful address translation. As the name suggests, the translation state is maintained between IPv4 address/port pairs and IPv6 address/port pairs, enabling IPv6 systems to open sessions with IPv4 systems. DNS64 [RFC6147] describes a mechanism for synthesizing AAAA resource records (RRs) from A RRs. Together, RFCs 6146 and RFC 6147 provide a viable method for an IPv6-only client to initiate communications to an IPv4-only server. As described in Enterprise Assumptions, Section 1.1, the administrator will usually want most traffic or flows to be native and only translate as needed.
IPv6からIPv4への通信を支援する、現在利用可能なさまざまなステートレスおよびステートフルIPv4 / IPv6変換方法があります。 RFC 6144は、IPv4 / IPv6変換のフレームワークを提供し、そのような変換メカニズムを使用できるさまざまなシナリオを詳細に説明しています。 [RFC6145]は、ステートレスアドレス変換について説明しています。このモードでは、特定のIPv6アドレス範囲はIPv4システム（IPv4変換アドレス）を表し、IPv6システムにはサービスプロバイダーのIPv4アドレスのサブセットにアルゴリズムでマッピングできるアドレス（IPv4変換可能アドレス）があります。 NAT64 [RFC6146]は、ステートフルアドレス変換について説明しています。名前が示すように、変換状態はIPv4アドレス/ポートのペアとIPv6アドレス/ポートのペアの間で維持されるため、IPv6システムはIPv4システムとのセッションを開くことができます。 DNS64 [RFC6147]は、A RRからAAAAリソースレコード（RR）を合成するメカニズムについて説明しています。 RFC 6146とRFC 6147は共に、IPv6のみのクライアントがIPv4のみのサーバーへの通信を開始するための実行可能な方法を提供します。 Enterprise Assumptions、Section 1.1で説明されているように、管理者は通常、ほとんどのトラフィックまたはフローをネイティブにして、必要な場合にのみ変換することを望みます。
The address translation mechanisms for the stateless and stateful translations are defined in [RFC6052]. It is important to note that both of these mechanisms have limitations as to which protocols they support. For example, RFC 6146 only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic only. The classic problems of IPv4 NAT also apply, e.g., handling IP literals in application payloads. The ultimate choice of which translation mechanism to chose will be dictated mostly by existing operational policies pertaining to application support, logging requirements, etc.
ステートレスおよびステートフル変換のアドレス変換メカニズムは、[RFC6052]で定義されています。これらのメカニズムはどちらも、サポートするプロトコルに関して制限があることに注意することが重要です。たとえば、RFC 6146は、ステートフルNAT64がTCP、UDP、およびICMPトラフィックのみを伝送するユニキャストパケットを変換する方法のみを定義しています。 IPv4 NATの古典的な問題、たとえばアプリケーションペイロードでのIPリテラルの処理も当てはまります。どの変換メカニズムを選択するかの最終的な選択は、主に、アプリケーションサポート、ロギング要件などに関連する既存の運用ポリシーによって決まります。
There is additional work being done in the area of address translation to enhance and/or optimize current mechanisms. For example, [DIVI] describes limitations with the current stateless translation, such as IPv4 address sharing and application layer gateway (ALG) problems, and presents the concept and implementation of dual-stateless IPv4/IPv6 translation (dIVI) to address those issues.
現在のメカニズムを強化または最適化するために、アドレス変換の領域で追加の作業が行われています。たとえば、[DIVI]は、IPv4アドレス共有やアプリケーションレイヤーゲートウェイ（ALG）の問題など、現在のステートレス変換の制限について説明し、これらの問題に対処するためのデュアルステートレスIPv4 / IPv6変換（dIVI）の概念と実装を示しています。
It is worth noting that for IPv6-only access networks that use technologies such as NAT64, the more content providers (and enterprises) that make their content available over IPv6, the less the requirement to apply NAT64 to traffic leaving the access network. This particular point is important for enterprises that may start their IPv6 deployment well into the global IPv6 transition. As time progresses, and given the current growth in availability of IPv6 content, IPv6-only operation using NAT64 to manage some flows will become less expensive to run versus the traditional NAT44 deployments since only IPv6-to-IPv4 flows need translation. [RFC6883] provides guidance and suggestions for Internet Content Providers and Application Service Providers in this context.
NAT64などのテクノロジーを使用するIPv6のみのアクセスネットワークでは、IPv6を介してコンテンツを利用できるようにするコンテンツプロバイダー（および企業）が多いほど、アクセスネットワークから出るトラフィックにNAT64を適用する必要性が少なくなることに注意してください。この特定のポイントは、グローバルなIPv6移行に向けてIPv6の展開を開始できる企業にとって重要です。時間が経過し、IPv6コンテンツの可用性が現在向上しているため、NAT64を使用して一部のフローを管理するIPv6のみの操作は、IPv6からIPv4へのフローのみを変換する必要があるため、従来のNAT44展開と比べて実行コストが低くなります。 [RFC6883]は、このコンテキストでのインターネットコンテンツプロバイダーとアプリケーションサービスプロバイダー向けのガイダンスと提案を提供します。
Enterprises should also be aware that networks may be subject to future convergence with other networks (i.e., mergers, acquisitions, etc.). An enterprise considering IPv6-only operation may need to be aware that additional transition technologies and/or connectivity strategies may be required depending on the level of IPv6 readiness and deployment in the merging networking.
企業はまた、ネットワークが他のネットワークとの将来の統合（つまり、合併、買収など）の影響を受ける可能性があることを認識しておく必要があります。 IPv6のみの運用を検討している企業は、IPv6の準備のレベルとマージするネットワークでの展開に応じて、追加の移行テクノロジや接続戦略が必要になる場合があることに注意する必要があります。
Some guidance for Internet Content and Application Service Providers can be found in [RFC6883], which includes a dedicated section on Content Delivery Networks (CDNs). An enterprise that relies on a CDN to deliver a 'better' e-commerce experience needs to ensure that their CDN provider also supports IPv4/IPv6 traffic selection so that they can ensure 'best' access to the content. A CDN could enable external IPv6 content delivery even if the enterprise provides that content over IPv4.
インターネットコンテンツおよびアプリケーションサービスプロバイダー向けのガイダンスは、[RFC6883]にあり、コンテンツ配信ネットワーク（CDN）に関する専用セクションが含まれています。 CDNを使用して「より良い」電子商取引体験を提供する企業は、CDNプロバイダーがIPv4 / IPv6トラフィック選択もサポートしていることを確認して、コンテンツへの「最良の」アクセスを確保できるようにする必要があります。企業がIPv4を介してコンテンツを提供している場合でも、CDNは外部IPv6コンテンツ配信を可能にすることができます。
IPv6 Data Center considerations are described in [IPv6-DC].
IPv6データセンターの考慮事項は、[IPv6-DC]で説明されています。
A number of campus networks around the world have made some initial IPv6 deployments. This has been encouraged by their National Research and Education Network (NREN) backbones, having made IPv6 available natively since the early 2000's. Universities are a natural place for IPv6 deployment to be considered at an early stage, perhaps compared to other enterprises, as they are involved by their very nature in research and education.
世界中の多くのキャンパスネットワークで、初期IPv6導入がいくつか行われています。これは、2000年代初頭以来、IPv6をネイティブで利用可能にしてきた彼らのNational Research and Education Network（NREN）バックボーンによって奨励されています。大学は、研究や教育に非常に本質的に関与しているため、おそらく他の企業と比較して、IPv6の導入を早い段階で検討するのに自然な場所です。
Campus networks can deploy IPv6 at their own pace; there is no need to deploy IPv6 across the entire enterprise from day one. Rather, specific projects can be identified for an initial deployment that are both deep enough to give the university experience but small enough to be a realistic first step. There are generally three areas in which such deployments are currently made.
キャンパスネットワークは、独自のペースでIPv6を展開できます。初日から企業全体にIPv6を導入する必要はありません。むしろ、特定のプロジェクトを特定して、最初の展開で、大学での経験を提供するのに十分な深さでありながら、現実的な最初のステップになるのに十分なほど小さいプロジェクトを特定できます。現在、このような展開が行われている領域は一般に3つあります。
In particular, those initial areas commonly approached are:
特に、一般的にアプローチされる初期領域は次のとおりです。
o External-facing services. Typically, the campus web presence and commonly also external-facing DNS and mail exchange (MX) services. This ensures early IPv6-only adopters elsewhere can access the campus services as simply and as robustly as possible.
o 外部向けサービス。通常、キャンパスのWebプレゼンスと、一般に外部向けのDNSおよびメール交換（MX）サービスも含まれます。これにより、他の場所にある初期のIPv6のみの採用者がキャンパスサービスにできるだけ簡単かつ確実にアクセスできるようになります。
o Computer science department. This is where IPv6-related research and/or teaching is most likely to occur, and where many of the next generation of network engineers are studying, so enabling some or all of the campus computer science department network is a sensible first step.
o コンピュータサイエンス部門。これは、IPv6関連の研究や教育が発生する可能性が最も高い場所であり、次世代のネットワークエンジニアの多くが研究しているため、キャンパスコンピュータサイエンス部門のネットワークの一部またはすべてを有効にすることは、賢明な最初のステップです。
o The eduroam wireless network. Eduroam [EDUROAM] is the de facto wireless roaming system for academic networks and uses authentication based on 802.1X, which is agnostic to the IP version used (unlike web-redirection gateway systems). Making a campus' eduroam network dual stack is a very viable early step.
o eduroamワイヤレスネットワーク。 Eduroam [EDUROAM]は、アカデミックネットワーク用の事実上のワイヤレスローミングシステムであり、（Webリダイレクトゲートウェイシステムとは異なり）使用するIPバージョンに依存しない802.1Xに基づく認証を使用します。キャンパスのeduroamネットワークをデュアルスタックにすることは、非常に実行可能な早い段階です。
The general IPv6 deployment model in a campus enterprise will still follow the general principles described in this document. While the above early stage projects are commonly followed, these still require the campus to acquire IPv6 connectivity and address space from their NREN (or other provider in some parts of the world) and to enable IPv6 on the wire on at least part of the core of the campus network. This implies a requirement to have an initial address plan, and to ensure appropriate monitoring and security measures are in place, as described elsewhere in this document.
キャンパスエンタープライズの一般的なIPv6展開モデルは、このドキュメントで説明されている一般的な原則に従います。上記の初期段階のプロジェクトは一般的に行われますが、これらのプロジェクトでは、キャンパスがNREN（または世界の一部の地域の他のプロバイダー）からIPv6接続とアドレス空間を取得し、コアの少なくとも一部で有線のIPv6を有効にする必要がありますキャンパスネットワークの。これは、このドキュメントの他の場所で説明されているように、初期アドレス計画を持ち、適切な監視とセキュリティ対策が実施されていることを確認する要件を意味します。
Campuses that have deployed to date do not use ULAs, nor do they use NPTv6. In general, campuses have very stable PA-based address allocations from their NRENs (or their equivalent). However, campus enterprises may consider applying for IPv6 PI; some have already done so. The discussions earlier in this text about PA vs. PI still apply.
これまでに展開されたキャンパスはULAを使用せず、NPTv6も使用しません。一般に、キャンパスには、NREN（または同等のもの）からのPAベースの非常に安定したアドレス割り当てがあります。ただし、キャンパス企業はIPv6 PIの申請を検討する場合があります。一部はすでにそうしています。このテキストの前半で説明したPAとPIについての議論はまだ当てはまります。
Finally, campuses may be more likely than many other enterprises to run multicast applications, such as IP TV or live lecture or seminar streaming, so they may wish to consider support for specific IPv6 multicast functionality, e.g., the Embedded Rendezvous Point (Embedded-RP) [RFC3956] in routers and MLDv1 and MLDv2 snooping in switches.
最後に、キャンパスは他の多くの企業よりもIP TVやライブ講義やセミナーのストリーミングなどのマルチキャストアプリケーションを実行する可能性が高いため、特定のIPv6マルチキャスト機能、たとえばEmbedded Rendezvous Point（Embedded-RP）のサポートを検討したい場合があります。 ）[RFC3956]ルーター、MLDv1およびMLDv2スイッチでスヌーピング。
This document has multiple security sections detailing with how to securely deploy an IPv6 network within an enterprise network.
このドキュメントには、エンタープライズネットワーク内にIPv6ネットワークを安全に展開する方法を詳しく説明する複数のセキュリティセクションがあります。
[CYMRU] Team CYMRU Community Services, "THE BOGON REFERENCE", Version 7, April 2012, <http://www.team-cymru.org/Services/Bogons/>.
[CYMRU]チームCYMRUコミュニティサービス、「THE BOGON REFERENCE」、バージョン7、2012年4月、<http://www.team-cymru.org/Services/Bogons/>。
[DHCPv6-SLAAC-PROBLEM] Liu, B. and R. Bonica, "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", Work in Progress, draft-liu-bonica-dhcpv6-slaac-problem-02, September 2013.
[DHCPv6-SLAAC-PROBLEM] Liu、B。およびR. Bonica、「DHCPv6 / SLAACアドレス構成の相互作用の問題に関する声明」、作業中、draft-liu-bonica-dhcpv6-slaac-problem-02、2013年9月。
[DIVI] Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual-Stateless IPv4/IPv6 Translation", Work in Progress, draft-xli-behave-divi-06, January 2014.
[DIVI] Bao、C.、Li、X.、Zhai、Y.、W。Shang、「dIVI：Dual-Stateless IPv4 / IPv6 Translation」、Work in Progress、draft-xli-behave-divi-06、1月2014。
[EDUROAM] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam architecture for network roaming", Work in Progress, draft-wierenga-ietf-eduroam-04, August 2014.
[EDUROAM] Wierenga、K.、Winter、S。、およびT. Wolniewicz、「ネットワークローミング用のeduroamアーキテクチャ」、Work in Progress、draft-wierenga-ietf-eduroam-04、2014年8月。
[HOST-SCANNING] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", Work in Progress, draft-ietf-opsec-ipv6-host-scanning-04, June 2014.
[HOST-SCANNING] Gont、F。およびT. Chown、「IPv6ネットワークでのネットワーク偵察」、作業中、draft-ietf-opsec-ipv6-host-scanning-04、2014年6月。
[IPv6-DC] Lopez, D., Chen, Z., Tsou, T., Zhou, C., and A. Servin, "IPv6 Operational Guidelines for Datacenters", Work in Progress, draft-ietf-v6ops-dc-ipv6-01, February 2014.
[IPv6-DC] Lopez、D.、Chen、Z.、Tsou、T.、Zhou、C。、およびA. Servin、「IPv6データセンターの運用ガイドライン」、作業中、draft-ietf-v6ops-dc- ipv6-01、2014年2月。
[IPv6-DESIGN] Matthews, P. and V. Kuarsingh, "Design Choices for IPv6 Networks", Work in Progress, draft-ietf-v6ops-design-choices-02, September 2014.
[IPv6-DESIGN] Matthews、P。およびV. Kuarsingh、「IPv6ネットワークの設計の選択」、作業中、draft-ietf-v6ops-design-choices-02、2014年9月。
[IPv6-SECURITY] Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Security Considerations for IPv6 Networks", Work in Progress, draft-ietf-opsec-v6-04, October 2013.
[IPv6-SECURITY] Chittimaneni、K.、Kaeo、M。、およびE. Vyncke、「IPv6ネットワークの運用上のセキュリティの考慮事項」、作業中、draft-ietf-opsec-v6-04、2013年10月。
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC0826] Plummer、D。、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスをイーサネットハードウェアで送信するための48ビットイーサネットアドレスに変換する」、STD 37、RFC 826、1982年11月、<http：//www.rfc- editor.org/info/rfc826>。
[RFC1687] Fleischman, E., "A Large Corporate User's View of IPng", RFC 1687, August 1994, <http://www.rfc-editor.org/info/rfc1687>.
[RFC1687] Fleischman、E.、 "A Large Corporate User's View of IPng"、RFC 1687、August 1994、<http://www.rfc-editor.org/info/rfc1687>。
[RFC1817] Rekhter, Y., "CIDR and Classful Routing", RFC 1817, August 1995, <http://www.rfc-editor.org/info/rfc1817>.
[RFC1817] Rekhter、Y。、「CIDR and Classful Routing」、RFC 1817、1995年8月、<http://www.rfc-editor.org/info/rfc1817>。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月、<http：// www.rfc-editor.org/info/rfc1918>。
[RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for the Internet Protocol using SMIv2", RFC 2011, November 1996, <http://www.rfc-editor.org/info/rfc2011>.
[RFC2011] McCloghrie、K。、「SNMPv2 Management Information Base for the Internet Protocol using SMIv2」、RFC 2011、1996年11月、<http://www.rfc-editor.org/info/rfc2011>。
[RFC2096] Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1997, <http://www.rfc-editor.org/info/rfc2096>.
[RFC2096]ベイカー、F。、「IP転送テーブルMIB」、RFC 2096、1997年1月、<http://www.rfc-editor.org/info/rfc2096>。
[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, <http://www.rfc-editor.org/info/rfc2827>.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを使用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、2000年5月、<http：//www.rfc-editor。 org / info / rfc2827>。
[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, <http://www.rfc-editor.org/info/rfc3315>.
[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 、<http://www.rfc-editor.org/info/rfc3315>。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004, <http://www.rfc-editor.org/info/rfc3956>.
[RFC3956] Savola、P。およびB. Haberman、「IPv6マルチキャストアドレスへのランデブーポイント（RP）アドレスの埋め込み」、RFC 3956、2004年11月、<http://www.rfc-editor.org/info/rfc3956 >。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005, <http://www.rfc-editor.org/info/rfc3971>.
[RFC3971] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「SEcure Neighbor Discovery（SEND）」、RFC 3971、2005年3月、<http://www.rfc-editor.org / info / rfc3971>。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005, <http://www.rfc-editor.org/info/rfc3972>.
[RFC3972] Aura、T。、「Cryptographically Generated Addresses（CGA）」、RFC 3972、2005年3月、<http://www.rfc-editor.org/info/rfc3972>。
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005, <http://www.rfc-editor.org/info/rfc4038>.
[RFC4038] Shin、MK。、Hong、YG。、Hagino、J.、Savola、P。、およびE. Castro、「IPv6移行のアプリケーションの側面」、RFC 4038、2005年3月、<http：//www.rfc -editor.org/info/rfc4038>。
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005, <http://www.rfc-editor.org/info/rfc4057>.
[RFC4057] Bound、J。、「IPv6 Enterprise Network Scenarios」、RFC 4057、2005年6月、<http://www.rfc-editor.org/info/rfc4057>。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、2005年10月、<http://www.rfc-editor.org/info/rfc4193>。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005, <http://www.rfc-editor.org/info/rfc4213>.
[RFC4213]ノードマーク、E。およびR.ギリガン、「IPv6ホストおよびルーターの基本的な移行メカニズム」、RFC 4213、2005年10月、<http://www.rfc-editor.org/info/rfc4213>。
[RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 2006, <http://www.rfc-editor.org/info/rfc4292>.
[RFC4292] Haberman、B。、「IP Forwarding Table MIB」、RFC 4292、2006年4月、<http://www.rfc-editor.org/info/rfc4292>。
[RFC4293] Routhier, S., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006, <http://www.rfc-editor.org/info/rfc4293>.
[RFC4293] Routhier、S.、「インターネットプロトコル（IP）の管理情報ベース」、RFC 4293、2006年4月、<http://www.rfc-editor.org/info/rfc4293>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364] Rosen、E.およびY. Rekhter、「BGP / MPLS IP Virtual Private Networks（VPNs）」、RFC 4364、2006年2月、<http://www.rfc-editor.org/info/rfc4364>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPv6）」、RFC 4443、2006年3月、<http：// www .rfc-editor.org / info / rfc4443>。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006, <http://www.rfc-editor.org/info/rfc4659>.
[RFC4659] De Clercq、J.、Ooms、D.、Carugi、M。、およびF. Le Faucheur、「BGP-MPLS IP Virtual Private Network（VPN）Extension for IPv6 VPN」、RFC 4659、2006年9月、<http ：//www.rfc-editor.org/info/rfc4659>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月、<http：//www.rfc- editor.org/info/rfc4861>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月、<http://www.rfc-editor.org/info/rfc4862>。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007, <http://www.rfc-editor.org/info/rfc4890>.
[RFC4890] Davies、E。およびJ. Mohacsi、「ファイアウォールでのICMPv6メッセージのフィルタリングに関する推奨事項」、RFC 4890、2007年5月、<http://www.rfc-editor.org/info/rfc4890>。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007, <http://www.rfc-editor.org/info/rfc4941>.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6でのステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、2007年9月、<http://www.rfc-editor.org/info/ rfc4941>。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007, <http://www.rfc-editor.org/info/rfc5095>.
[RFC5095] Abley、J.、Savola、P。、およびG. Neville-Neil、「Deprecation of Type 0 Routing Headers in IPv6」、RFC 5095、2007年12月、<http://www.rfc-editor.org/ info / rfc5095>。
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, March 2008, <http://www.rfc-editor.org/info/rfc5157>.
[RFC5157] Chown、T。、「IPv6のネットワークスキャンへの影響」、RFC 5157、2008年3月、<http://www.rfc-editor.org/info/rfc5157>。
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 2008, <http://www.rfc-editor.org/info/rfc5211>.
[RFC5211] Curran、J。、「An Internet Transition Plan」、RFC 5211、2008年7月、<http://www.rfc-editor.org/info/rfc5211>。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008, <http://www.rfc-editor.org/info/rfc5214>.
[RFC5214] Templin、F.、Gleeson、T。、およびD. Thaler、「Intra-Site Automatic Tunnel Addressing Protocol（ISATAP）」、RFC 5214、2008年3月、<http://www.rfc-editor.org/ info / rfc5214>。
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., and C. Hahn, "IPv6 Unicast Address Assignment Considerations", RFC 5375, December 2008, <http://www.rfc-editor.org/info/rfc5375>.
[RFC5375] Van de Velde、G.、Popoviciu、C.、Chown、T.、Bonness、O。、およびC. Hahn、「IPv6ユニキャストアドレス割り当ての考慮事項」、RFC 5375、2008年12月、<http：// www .rfc-editor.org / info / rfc5375>。
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009, <http://www.rfc-editor.org/info/rfc5722>.
[RFC5722] Krishnan、S。、「Handling of Overlapping IPv6 Fragments」、RFC 5722、2009年12月、<http://www.rfc-editor.org/info/rfc5722>。
[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010, <http://www.rfc-editor.org/info/rfc5798>.
[RFC5798] Nadas、S。、「IPv4およびIPv6の仮想ルーター冗長プロトコル（VRRP）バージョン3」、RFC 5798、2010年3月、<http://www.rfc-editor.org/info/rfc5798>。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>.
[RFC5952] Kawamura、S. and M. Kawashima、 "A Recommendation for IPv6 Address Text Representation"、RFC 5952、August 2010、<http://www.rfc-editor.org/info/rfc5952>。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>.
[RFC6052] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M。、およびX. Li、「IPv4 / IPv6トランスレータのIPv6アドレッシング」、RFC 6052、2010年10月、<http：// www .rfc-editor.org / info / rfc6052>。
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011, <http://www.rfc-editor.org/info/rfc6104>.
[RFC6104] Chown、T。およびS. Venaas、「Rogue IPv6 Router Advertisement Problem Statement」、RFC 6104、2011年2月、<http://www.rfc-editor.org/info/rfc6104>。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011, <http://www.rfc-editor.org/info/rfc6105>.
[RFC6105] Levy-Abegnoli、E.、Van de Velde、G.、Popoviciu、C。、およびJ. Mohacsi、「IPv6 Router Advertisement Guard」、RFC 6105、2011年2月、<http：//www.rfc-editor .org / info / rfc6105>。
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010, <http://www.rfc-editor.org/info/rfc6106>.
[RFC6106] Jeong、J.、Park、S.、Beloeil、L。、およびS. Madanapalli、「DNS構成のIPv6ルーターアドバタイズメントオプション」、RFC 6106、2010年11月、<http：//www.rfc-editor。 org / info / rfc6106>。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011, <http://www.rfc-editor.org/info/rfc6144>.
[RFC6144] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「Framework for IPv4 / IPv6 Translation」、RFC 6144、2011年4月、<http://www.rfc-editor.org / info / rfc6144>。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011, <http://www.rfc-editor.org/info/rfc6145>.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「IP / ICMP変換アルゴリズム」、RFC 6145、2011年4月、<http://www.rfc-editor.org/info/rfc6145>。
[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, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「ステートフルNAT64：IPv6クライアントからIPv4サーバーへのネットワークアドレスおよびプロトコル変換」、RFC 6146、2011年4月、<http：//www.rfc -editor.org/info/rfc6146>。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011, <http://www.rfc-editor.org/info/rfc6147>.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P.、I。van Beijnum、「DNS64：DNS Extensions for Network Address Translation to IPv6 Clients to IPv4 Servers」、RFC 6147、2011年4月、<http： //www.rfc-editor.org/info/rfc6147>。
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-Router Links", RFC 6164, April 2011, <http://www.rfc-editor.org/info/rfc6164>.
[RFC6164]河野雅夫、ニッサン、B。、ブッシュ、R。、松崎、Y。、コリッティ、L。、およびT.ナルテン、「ルーター間リンクでの127ビットIPv6プレフィックスの使用」、RFC 6164、 2011年4月、<http://www.rfc-editor.org/info/rfc6164>。
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, March 2011, <http://www.rfc-editor.org/info/rfc6177>.
[RFC6177] Narten、T.、Huston、G。、およびL. Roberts、「エンドサイトへのIPv6アドレスの割り当て」、BCP 157、RFC 6177、2011年3月、<http://www.rfc-editor.org/info / rfc6177>。
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, March 2011, <http://www.rfc-editor.org/info/rfc6192>.
[RFC6192] Dugal、D.、Pignataro、C。、およびR. Dunn、「Protecting the Router Control Plane」、RFC 6192、2011年3月、<http://www.rfc-editor.org/info/rfc6192>。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011, <http://www.rfc-editor.org/info/rfc6296>.
[RFC6296] Wasserman、M。およびF. Baker、「IPv6-to-IPv6 Network Prefix Translation」、RFC 6296、2011年6月、<http://www.rfc-editor.org/info/rfc6296>。
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011, <http://www.rfc-editor.org/info/rfc6302>.
[RFC6302] Durand、A.、Gashinsky、I.、Lee、D。、およびS. Sheppard、「インターネットに面したサーバーのログに関する推奨事項」、BCP 162、RFC 6302、2011年6月、<http：//www.rfc -editor.org/info/rfc6302>。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011, <http://www.rfc-editor.org/info/rfc6434>.
[RFC6434] Jankiewicz、E.、Loughney、J。、およびT. Narten、「IPv6ノードの要件」、RFC 6434、2011年12月、<http://www.rfc-editor.org/info/rfc6434>。
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012, <http://www.rfc-editor.org/info/rfc6555>.
[RFC6555] Wing、D。およびA. Yourtchenko、「Happy Eyeballs：Success with Dual-Stack Hosts」、RFC 6555、2012年4月、<http://www.rfc-editor.org/info/rfc6555>。
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012, <http://www.rfc-editor.org/info/rfc6583>.
[RFC6583] Gashinsky、I.、Jaeggli、J。、およびW. Kumari、「Operational Neighbor Discovery Problems」、RFC 6583、2012年3月、<http://www.rfc-editor.org/info/rfc6583>。
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724] Thaler、D.、Draves、R.、Matsumoto、A。、およびT. Chown、「Default Protocol Selection for Internet Protocol Version 6（IPv6）」、RFC 6724、2012年9月、<http：// www。 rfc-editor.org/info/rfc6724>。
[RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks", RFC 6866, February 2013, <http://www.rfc-editor.org/info/rfc6866>.
[RFC6866] Carpenter、B。およびS. Jiang、「エンタープライズネットワークで静的アドレスを使用してIPv6ホストの番号を再設定するための問題ステートメント」、RFC 6866、2013年2月、<http://www.rfc-editor.org/info/rfc6866> 。
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013, <http://www.rfc-editor.org/info/rfc6879>.
[RFC6879] Jiang、S.、Liu、B。、およびB. Carpenter、「IPv6 Enterprise Network Renumbering Scenarios、Considerations、and Methods」、RFC 6879、2013年2月、<http://www.rfc-editor.org/ info / rfc6879>。
[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet Content Providers and Application Service Providers", RFC 6883, March 2013, <http://www.rfc-editor.org/info/rfc6883>.
[RFC6883] Carpenter、B。およびS. Jiang、「IPv6 Guidance for Internet Content Providers and Application Service Providers」、RFC 6883、2013年3月、<http://www.rfc-editor.org/info/rfc6883>。
[RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address Validation Improvement (SAVI) Threat Scope", RFC 6959, May 2013, <http://www.rfc-editor.org/info/rfc6959>.
[RFC6959]マクファーソン、D。、ベイカー、F。、およびJ.ハルパーン、「Source Address Validation Improvement（SAVI）Threat Scope」、RFC 6959、2013年5月、<http://www.rfc-editor.org/info / rfc6959>。
[RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 6964, May 2013, <http://www.rfc-editor.org/rfc/rfc6964.txt>.
[RFC6964] Templin、F。、「サイト内自動トンネルアドレスプロトコル（ISATAP）を使用したIPv4サイトでのIPv6展開の運用ガイダンス」、RFC 6964、2013年5月、<http://www.rfc-editor.org/ rfc / rfc6964.txt>。
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013, <http://www.rfc-editor.org/info/rfc7011>.
[RFC7011] Claise、B.、Trammell、B。、およびP. Aitken、「フロー情報交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、STD 77、RFC 7011、2013年9月、<http： //www.rfc-editor.org/info/rfc7011>。
[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013, <http://www.rfc-editor.org/info/rfc7012>.
[RFC7012] Claise、B。およびB. Trammell、「IP Flow Information Export（IPFIX）の情報モデル」、RFC 7012、2013年9月、<http://www.rfc-editor.org/info/rfc7012>。
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, December 2013, <http://www.rfc-editor.org/info/rfc7045>.
[RFC7045] Carpenter、B。およびS. Jiang、「IPv6拡張ヘッダーの送信と処理」、RFC 7045、2013年12月、<http://www.rfc-editor.org/info/rfc7045>。
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, February 2014, <http://www.rfc-editor.org/info/rfc7113>.
[RFC7113] Gont、F。、「IPv6ルーターアドバタイズメントガード（RA-Guard）の実装に関するアドバイス」、RFC 7113、2014年2月、<http://www.rfc-editor.org/info/rfc7113>。
[RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on IPv4 Networks", RFC 7123, February 2014, <http://www.rfc-editor.org/info/rfc7123>.
[RFC7123] Gont、F。およびW. Liu、「IPv4ネットワーク上のIPv6のセキュリティへの影響」、RFC 7123、2014年2月、<http://www.rfc-editor.org/info/rfc7123>。
[RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359, August 2014, <http://www.rfc-editor.org/info/rfc7359>.
[RFC7359] Gont、F。、「デュアルスタックホスト/ネットワークにおけるレイヤ3仮想プライベートネットワーク（VPN）トンネルトラフィックリーケージ」、RFC 7359、2014年8月、<http://www.rfc-editor.org/info/ rfc7359>。
[SMURF] The Cert Division of the Software Engineering Institute, "Smurf IP Denial-of-Service Attacks", CERT Advisory CA-1998-01, March 2000, <http://www.cert.org/advisories/CA-1998-01.html>.
[SMURF] Software Engineering InstituteのCert Division、「Smurf IP Denial-of-Service Attacks」、CERT Advisory CA-1998-01、2000年3月、<http://www.cert.org/advisories/CA-1998 -01.html>。
[ULA-USAGE] Liu, B. and S. Jiang, "Considerations of Using Unique Local Addresses", Work in Progress, draft-ietf-v6ops-ula-usage-recommendations-03, July 2014.
[ULA-USAGE] Liu、B。およびS. Jiang、「一意のローカルアドレスの使用に関する考慮事項」、作業中、draft-ietf-v6ops-ula-usage-recommendations-03、2014年7月。
Acknowledgements
謝辞
The authors would like to thank Robert Sparks, Steve Hanna, Tom Taylor, Brian Haberman, Stephen Farrell, Chris Grundemann, Ray Hunter, Kathleen Moriarty, Benoit Claise, Brian Carpenter, Tina Tsou, Christian Jacquenet, and Fred Templin for their substantial comments and contributions.
著者は、Robert Sparks、Steve Hanna、Tom Taylor、Brian Haberman、Stephen Farrell、Chris Grundemann、Ray Hunter、Cathleen Moriarty、Benoit Claise、Brian Carpenter、Tina Tsou、Christian Jacquenet、およびFred Templinに多大なコメントと貢献。
Authors' Addresses
著者のアドレス
Kiran K. Chittimaneni Dropbox, Inc. 185 Berry Street, Suite 400 San Francisco, CA 94107 United States EMail: kk@dropbox.com
Kiran K. Chittimaneni Dropbox、Inc. 185 Berry Street、Suite 400 San Francisco、CA 94107 United Statesメール：kk@dropbox.com
Tim Chown University of Southampton Highfield Southampton, Hampshire SO17 1BJ United Kingdom EMail: tjc@ecs.soton.ac.uk
Tim Chown University of Southampton Highfieldサウサンプトン、ハンプシャーSO17 1BJイギリスEメール：tjc@ecs.soton.ac.uk
Lee Howard Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 United States Phone: +1 703 345 3513 EMail: lee.howard@twcable.com
Lee Howard Time Warner Cable 13820 Sunrise Valley Drive Herndon、VA 20171 United States電話：+1 703 345 3513メール：lee.howard@twcable.com
Victor Kuarsingh Dyn, Inc. 150 Dow Street Manchester, NH United States EMail: victor@jvknet.com
Victor Kuarsingh Dyn、Inc. 150 Dow Streetマンチェスター、NHアメリカ合衆国メール：victor@jvknet.com
Yanick Pouffary Hewlett Packard 950 Route Des Colles Sophia-Antipolis 06901 France EMail: Yanick.Pouffary@hp.com
Yanick Pouffary Hewlett Packard 950 Route Des Colles Sophia-Antipolis 06901 Franceメール：Yanick.Pouffary@hp.com
Eric Vyncke Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium Phone: +32 2 778 4677 EMail: evyncke@cisco.com
Eric Vyncke Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium電話：+32 2 778 4677電子メール：evyncke@cisco.com