[要約] 要約：RFC 7123は、IPv6がIPv4ネットワークに与えるセキュリティ上の影響について説明しています。 目的：IPv6の導入によるセキュリティ上のリスクを理解し、IPv4ネットワークのセキュリティ対策を強化するためのガイドラインを提供する。
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7123 SI6 Networks/UTN-FRH
Category: Informational W. Liu
ISSN: 2070-1721 Huawei Technologies
February 2014
Security Implications of IPv6 on IPv4 Networks
IPv4ネットワークにおけるIPv6のセキュリティへの影響
Abstract
概要
This document discusses the security implications of native IPv6 support and IPv6 transition/coexistence technologies on "IPv4-only" networks and describes possible mitigations for the aforementioned issues.
このドキュメントでは、「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/rfc7123.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7123で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Security Implications of Native IPv6 Support . . . . . . . . 4
2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 4
3. Security Implications of Tunneling Mechanisms . . . . . . . . 5
3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . 6
3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . 7
3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . 8
3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . 9
3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . 9
3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) 11
3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 11
4. Additional Considerations when Filtering IPv6 Traffic . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Summary of Filtering Rules . . . . . . . . . . . . . 18
Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/coexistence technologies by default. Support of IPv6 by all nodes is intended to become best current practice [RFC6540]. Some enterprise networks might, however, choose to delay active use of IPv6.
ほとんどの汎用オペレーティングシステムは、デフォルトでネイティブIPv6 [RFC2460]サポートと多数の移行/共存テクノロジを実装して有効にします。すべてのノードによるIPv6のサポートは、現在のベストプラクティスになることを目的としています[RFC6540]。ただし、一部のエンタープライズネットワークは、IPv6のアクティブな使用を遅らせることを選択する場合があります。
This document describes operational practices to prevent security exposure in enterprise networks resulting from unplanned use of IPv6 on such networks. This document is only applicable to enterprise networks: networks where the network operator is not providing a general-purpose internet, but rather a business-specific network. The solutions proposed here are not practical for home networks, nor are they appropriate for provider networks such as ISPs, mobile providers, WiFi hotspot providers, or any other public internet service.
このドキュメントでは、そのようなネットワークでのIPv6の計画外の使用に起因するエンタープライズネットワークでの機密漏れを防ぐための運用方法について説明します。このドキュメントは、エンタープライズネットワークのみに適用されます。ネットワークオペレーターが汎用インターネットを提供するのではなく、ビジネス固有のネットワークを提供するネットワークです。ここで提案するソリューションは、ホームネットワークには実用的ではなく、ISP、モバイルプロバイダー、WiFiホットスポットプロバイダー、その他のパブリックインターネットサービスなどのプロバイダーネットワークにも適していません。
In scenarios in which IPv6-enabled devices are deployed on enterprise networks that are intended to be IPv4-only, native IPv6 support and/ or IPv6 transition/coexistence technologies could be leveraged by local or remote attackers for a number of (illegitimate) purposes. For example, o A Network Intrusion Detection System (NIDS) might be prepared to detect attack patterns for IPv4 traffic, but might be unable to detect the same attack patterns when a transition/coexistence technology is leveraged for that purpose.
IPv6に対応したデバイスがIPv4専用のエンタープライズネットワークに展開されているシナリオでは、ローカルまたはリモートの攻撃者がネイティブのIPv6サポートやIPv6移行/共存テクノロジをさまざまな（不正な）目的で利用する可能性があります。たとえば、oネットワーク侵入検出システム（NIDS）は、IPv4トラフィックの攻撃パターンを検出するように準備されている場合がありますが、その目的で遷移/共存テクノロジが利用されている場合、同じ攻撃パターンを検出できない場合があります。
o An IPv4 firewall might enforce a specific security policy in IPv4, but might be unable to enforce the same policy in IPv6.
o IPv4ファイアウォールは、IPv4で特定のセキュリティポリシーを実施する場合がありますが、IPv6で同じポリシーを実施できない場合があります。
o A NIDS or firewall might support both IPv4 and IPv6, but might not be configured to enforce on IPv6 traffic the same controls/ policies it enforces on IPv4 traffic.
o NIDSまたはファイアウォールは、IPv4とIPv6の両方をサポートしている可能性がありますが、IPv6トラフィックに、IPv4トラフィックに適用するのと同じ制御/ポリシーを適用するように構成されていない場合があります。
o Some transition/coexistence mechanisms could cause an internal host with otherwise limited IPv4 connectivity to become globally reachable over IPv6, therefore resulting in increased (and possibly unexpected) host exposure.
o 一部の移行/共存メカニズムにより、IPv4接続が制限されている内部ホストがIPv6を介してグローバルに到達可能になり、その結果、ホストの露出が増加する（予期しない可能性がある）可能性があります。
NOTE: Some transition/coexistence mechanisms (notably Teredo) are designed to traverse Network Address Port Translation (NAPT) [RFC2663] devices, allowing incoming IPv6 connections from the Internet to hosts behind the organizational firewall or NAPT (which in many deployments provides a minimum level of protection by only allowing those instances of communication that have been initiated from the internal network).
注：一部の移行/共存メカニズム（特にTeredo）は、ネットワークアドレスポート変換（NAPT）[RFC2663]デバイスを通過するように設計されており、組織のファイアウォールまたはNAPTの背後にあるホストへのインターネットからの着信IPv6接続を許可します（多くの展開で最小内部ネットワークから開始された通信のインスタンスのみを許可することによる保護のレベル）。
o IPv6 support could, either inadvertently or as a result of a deliberate attack, result in Virtual Private Network (VPN) traffic leaks if IPv6-unaware VPN software is employed by dual-stacked hosts [VPN-LEAKS].
o IPv6に対応していないVPNソフトウェアがデュアルスタックホストで使用されている場合、意図せずに、または意図的な攻撃の結果としてIPv6がサポートされ、仮想プライベートネットワーク（VPN）トラフィックリークが発生する可能性があります[VPN-LEAKS]。
In general, most of the aforementioned security implications can be mitigated by enforcing security controls on native IPv6 traffic and on IPv4-tunneled IPv6 traffic. Among such controls, is the enforcement of filtering policies to block undesirable traffic. While IPv6 widespread/global IPv6 deployment has been slower than expected, it is nevertheless happening; and thus, filtering IPv6 traffic (whether native or transition/coexistence) to mitigate IPv6 security implications on IPv4 networks should (generally) only be considered as a temporary measure until IPv6 is deployed.
一般に、前述のセキュリティへの影響のほとんどは、ネイティブIPv6トラフィックとIPv4トンネルIPv6トラフィックにセキュリティ制御を適用することで軽減できます。そのような制御の中には、望ましくないトラフィックをブロックするためのフィルタリングポリシーの適用があります。 IPv6の普及/グローバルなIPv6の展開は予想よりも遅くなっていますが、それでも起こっています。したがって、IPv4トラフィックのフィルタリング（ネイティブまたは移行/共存）は、IPv4ネットワークでのIPv6のセキュリティへの影響を軽減するために、（一般的に）IPv6が展開されるまでの一時的な手段としてのみ考慮されます。
NOTE: The aforementioned security controls should contemplate not only network-based solutions, but also host-based solutions (such as, e.g., personal firewalls).
注：前述のセキュリティ管理策では、ネットワークベースのソリューションだけでなく、ホストベースのソリューション（パーソナルファイアウォールなど）も検討する必要があります。
Most popular operating systems include IPv6 support that is enabled by default. This means that even if a network is expected to be IPv4-only, much of its infrastructure is nevertheless likely to be IPv6-enabled. For example, hosts are likely to have at least link-local IPv6 connectivity, which might be exploited by attackers with access to the local network.
最も一般的なオペレーティングシステムには、デフォルトで有効になっているIPv6サポートが含まれています。これは、ネットワークがIPv4のみであることが期待されている場合でも、インフラストラクチャのほとんどがIPv6対応である可能性が高いことを意味します。たとえば、ホストは少なくともリンクローカルIPv6接続を持っている可能性が高く、これはローカルネットワークにアクセスできる攻撃者によって悪用される可能性があります。
Additionally, unless appropriate measures are taken, an attacker with access to an "IPv4-only" local network could impersonate a local router and cause local hosts to enable their 'non-link-local' IPv6 connectivity (e.g., by sending Router Advertisement messages), possibly circumventing security controls that were enforced only on IPv4 communications.
さらに、適切な対策が講じられていない限り、「IPv4のみ」のローカルネットワークにアクセスできる攻撃者はローカルルーターになりすまし、ローカルホストに「非リンクローカル」IPv6接続を有効にさせる可能性があります（たとえば、ルーターアドバタイズメッセージを送信することにより） ）、IPv4通信にのみ適用されたセキュリティ制御を回避する可能性があります。
NOTE: [THC-IPV6] and [IPv6-Toolkit] include tools that implement this attack vector (along with many others). [Waters2011] provides an example of how this could be achieved using publicly available tools.
注：[THC-IPV6]および[IPv6-Toolkit]には、この攻撃ベクトルを実装するツールが（他の多くのツールとともに）含まれています。 [Waters2011]は、公的に入手可能なツールを使用してこれを実現する方法の例を提供します。
Native IPv6 support could also possibly lead to VPN-traffic leakages when hosts employ VPN software that, not only does not support IPv6, but does nothing about IPv6 traffic. [VPN-LEAKS] describes this issue, along with possible mitigations.
ホストがIPv6をサポートしないだけでなく、IPv6トラフィックについて何もしないVPNソフトウェアを採用している場合、ネイティブIPv6サポートは、VPNトラフィックリークを引き起こす可能性もあります。 [VPN-LEAKS]は、この問題と考えられる緩和策について説明しています。
In general, networks should enforce on native IPv6 traffic the same security policies currently enforced on IPv4 traffic. However, in those networks in which IPv6 has not yet been deployed and enforcing the aforementioned policies is deemed as infeasible, a network administrator might mitigate IPv6-based attack vectors by means of appropriate packet filtering.
一般に、ネットワークはネイティブIPv6トラフィックに、現在IPv4トラフィックに適用されているものと同じセキュリティポリシーを適用する必要があります。ただし、IPv6がまだ展開されておらず、前述のポリシーを適用することが実行不可能であると見なされるネットワークでは、ネットワーク管理者が適切なパケットフィルタリングを使用してIPv6ベースの攻撃ベクトルを軽減する場合があります。
Some layer-2 devices might have the ability to selectively filter packets based on the type of layer-2 payload. When such functionality is available, IPv6 traffic could be blocked at those layer-2 devices by blocking, for example, Ethernet frames with the Protocol Type field set to 0x86dd [IANA-ETHER]. We note, however, that blocking IPv6 at layer-2 might create problems that are difficult to diagnose, inclusive of intentional or incidental use of link-local addressing (as in Multicast DNS/DNS-based Service Discovery [RFC6762] [RFC6763]); sites that enforce such a filtering policy should keep that possibility in mind when debugging the network.
一部のレイヤ2デバイスは、レイヤ2ペイロードのタイプに基づいてパケットを選択的にフィルタリングする機能を備えている場合があります。このような機能が利用可能な場合、たとえばプロトコルタイプフィールドが0x86dd [IANA-ETHER]に設定されたイーサネットフレームをブロックすることにより、それらのレイヤー2デバイスでIPv6トラフィックがブロックされる可能性があります。ただし、レイヤー2でIPv6をブロックすると、意図的または偶発的なリンクローカルアドレス指定の使用を含めて、診断が困難な問題が発生する可能性があることに注意してください（マルチキャストDNS / DNSベースのサービスディスカバリ[RFC6762] [RFC6763]など）。 ;このようなフィルタリングポリシーを適用するサイトは、ネットワークのデバッグ時にその可能性を念頭に置く必要があります。
Attacks based on Stateless Address Autoconfiguration (SLAAC) [RFC3756] can be mitigated with technologies such as Router Advertisement Guard (RA-Guard) [RFC6105] [RA-GRD-IMP]. In a similar way, DHCPv6-based attacks can be mitigated with technologies such as DHCPv6-Shield [SHIELD]. However, both RA-Guard and DHCPv6-Shield are incapable of mitigating attack vectors that employ IPv6 link-local addresses, since configuration of such addresses does not rely on Router Advertisement messages or DHCPv6-server messages.
ステートレスアドレス自動構成（SLAAC）[RFC3756]に基づく攻撃は、ルーターアドバタイズメントガード（RA-Guard）[RFC6105] [RA-GRD-IMP]などのテクノロジーで軽減できます。同様に、DHCPv6ベースの攻撃は、DHCPv6-Shield [SHIELD]などのテクノロジーを使用して軽減できます。ただし、RA-GuardとDHCPv6-Shieldはどちらも、IPv6リンクローカルアドレスを使用する攻撃ベクトルを緩和できません。これらのアドレスの構成は、ルーターアドバタイズメッセージやDHCPv6-serverメッセージに依存しないためです。
Administrators considering the filtering of native IPv6 traffic at layer-3 devices are urged to pay attention to the general considerations for IPv6 traffic filtering discussed in Section 4.
レイヤー3デバイスでのネイティブIPv6トラフィックのフィルタリングを検討している管理者は、セクション4で説明されているIPv6トラフィックフィルタリングの一般的な考慮事項に注意を払うように求められます。
NOTE: If native IPv6 traffic is filtered at layer-2, local IPv6 nodes would only get to configure IPv6 link-local addresses.
注：ネイティブIPv6トラフィックがレイヤー2でフィルタリングされる場合、ローカルIPv6ノードはIPv6リンクローカルアドレスのみを構成できます。
In order to mitigate attacks based on native IPv6 traffic, IPv6 security controls should be enforced on both IPv4 and IPv6 networks. The aforementioned controls might include: deploying IPv6-enabled NIDS, implementing IPv6 firewalling, etc.
ネイティブIPv6トラフィックに基づく攻撃を軽減するには、IPv4とIPv6の両方のネットワークでIPv6セキュリティ制御を実施する必要があります。前述の制御には、IPv6対応NIDSのデプロイ、IPv6ファイアウォールの実装などが含まれます。
NOTE: In some very specific scenarios (e.g., military operations networks) in which only IPv4 service might be desired, a network administrator might want to disable IPv6 support in all the communicating devices.
注：IPv4サービスのみが必要になる非常に特殊なシナリオ（軍事作戦ネットワークなど）では、ネットワーク管理者がすべての通信デバイスでIPv6サポートを無効にする場合があります。
Unless properly managed, tunneling mechanisms might result in negative security implications. For example, they might increase host exposure, might be leveraged to evade security controls, might contain protocol-based vulnerabilities, and/or the corresponding code might contain bugs with security implications.
適切に管理されない限り、トンネリングメカニズムはセキュリティに悪影響を及ぼす可能性があります。たとえば、ホストの露出を増やしたり、セキュリティ制御を回避するために利用されたり、プロトコルベースの脆弱性を含んだり、対応するコードにセキュリティに関連するバグが含まれたりします。
NOTE: [RFC6169] describes the security implications of tunneling mechanisms in detail. Of the plethora of tunneling mechanisms that have so far been standardized and widely implemented, the so-called "automatic tunneling" mechanisms (such as Teredo, Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), and 6to4) are of particular interest from a security standpoint, since they might be employed without prior consent or action of the user or network administrator.
注：[RFC6169]は、トンネリングメカニズムのセキュリティへの影響を詳細に説明しています。これまで標準化され広く実装されてきた大量のトンネリングメカニズムのうち、いわゆる「自動トンネリング」メカニズム（Teredo、サイト内自動トンネルアドレス指定プロトコル（ISATAP）、6to4など）は、ユーザーまたはネットワーク管理者の事前の同意またはアクションなしで使用される可能性があるため、セキュリティの観点。
Tunneling mechanisms should be a concern not only to network administrators that have consciously deployed them, but also to those who have not deployed them, as these mechanisms might be leveraged to bypass their security policies.
これらのメカニズムはセキュリティポリシーを回避するために利用される可能性があるため、トンネリングメカニズムは、意識的にそれらを展開したネットワーク管理者だけでなく、それらを展開していない人にも関係するはずです。
NOTE: [CERT2009] contains some examples of how tunnels can be leveraged to bypass firewall rules.
注：[CERT2009]には、トンネルを活用してファイアウォールルールをバイパスする方法の例がいくつか含まれています。
The aforementioned issues could be mitigated by applying the common security practice of only allowing traffic deemed as "necessary" (i.e., the so-called "default deny" policy). Thus, when such policy is enforced, IPv6 transition/coexistence traffic would be blocked by default and would only be allowed as a result of an explicit decision.
前述の問題は、「必要」と見なされたトラフィックのみを許可するという一般的なセキュリティ手法（いわゆる「デフォルトの拒否」ポリシー）を適用することで軽減できます。したがって、このようなポリシーが適用されると、IPv6移行/共存トラフィックはデフォルトでブロックされ、明示的な決定の結果としてのみ許可されます。
NOTE: It should be noted that this type of policy is usually enforced on a network that is the target of such traffic (such as an enterprise network). IPv6 transition traffic should generally never be filtered, e.g., by an ISP when it is transit traffic.
注：このタイプのポリシーは通常、そのようなトラフィックのターゲットであるネットワーク（エンタープライズネットワークなど）に適用されることに注意してください。 IPv6トランジショントラフィックは、通常、たとえば、トランジットトラフィックの場合、ISPによってフィルタリングされるべきではありません。
In those scenarios in which transition/coexistence traffic is meant to be blocked, it is highly recommended that, in addition to the enforcement of filtering policies at the organizational perimeter, the corresponding transition/coexistence mechanisms be disabled on each node connected to the organizational network. This would not only prevent security breaches resulting from accidental use of these mechanisms, but would also disable this functionality altogether, possibly mitigating vulnerabilities that might be present in the host implementation of these transition/coexistence mechanisms.
移行/共存トラフィックをブロックするシナリオでは、組織の境界でのフィルタリングポリシーの適用に加えて、対応する移行/共存メカニズムを組織ネットワークに接続されている各ノードで無効にすることを強くお勧めします。これにより、これらのメカニズムを誤って使用したことによるセキュリティ違反が防止されるだけでなく、この機能が完全に無効になり、これらの遷移/共存メカニズムのホスト実装に存在する可能性のある脆弱性が緩和される可能性があります。
IPv6-in-IPv4 tunneling mechanisms (such as 6to4 or configured tunnels) can generally be blocked by dropping IPv4 packets that contain a Protocol field set to 41. Security devices such as NIDS might also include signatures that detect such transition/coexistence traffic.
IPv6-in-IPv4トンネリングメカニズム（6to4または設定されたトンネルなど）は、一般に、41に設定されたプロトコルフィールドを含むIPv4パケットをドロップすることによってブロックできます。NIDSなどのセキュリティデバイスには、このような遷移/共存トラフィックを検出するシグネチャも含まれる場合があります。
Administrators considering the filtering of transition/coexistence traffic are urged to pay attention to the general considerations for IPv6 traffic filtering discussed in Section 4.
遷移/共存トラフィックのフィルタリングを検討している管理者は、セクション4で説明されているIPv6トラフィックフィルタリングの一般的な考慮事項に注意を払うことをお勧めします。
We note that this document only covers standardized IPv6 tunneling mechanisms; it does not aim to cover non-standard tunneling mechanisms or tunneling based on IPsec [RFC4301] or on SSL/TLS [RFC5246] [RFC6101].
このドキュメントでは、標準化されたIPv6トンネリングメカニズムのみを対象としています。非標準のトンネリングメカニズムや、IPsec [RFC4301]またはSSL / TLS [RFC5246] [RFC6101]に基づくトンネリングをカバーすることは目的としていません。
Probably the most basic type of tunnel employed for connecting IPv6 "islands" is the so-called "6in4", in which IPv6 packets are encapsulated within IPv4 packets. These tunnels typically result from manual configuration at the two tunnel endpoints.
おそらく、IPv6「アイランド」を接続するために使用される最も基本的なタイプのトンネルは、いわゆる「6in4」で、IPv6パケットがIPv4パケット内にカプセル化されます。これらのトンネルは、通常、2つのトンネルエンドポイントでの手動構成から生じます。
6in4 tunnels can be blocked by blocking IPv4 packets with a Protocol field of 41.
6in4トンネルは、プロトコルフィールドが41のIPv4パケットをブロックすることでブロックできます。
[RFC2529] specifies a mechanism known as 6over4 or 'IPv6 over IPv4' (or colloquially as 'virtual Ethernet'), which comprises a set of mechanisms and policies to allow isolated IPv6 hosts located on physical links with no directly connected IPv6 router to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link.
[RFC2529]は、6over4または 'IPv6 over IPv4'（または通称「仮想イーサネット」）として知られるメカニズムを指定します。これは、直接接続されたIPv6ルーターのない物理リンク上にある分離されたIPv6ホストが仮想ローカルリンクとしてIPv4マルチキャストをサポートするIPv4ドメインを使用して、完全に機能するIPv6ホスト。
NOTE: This transition technology has never been widely deployed because of the low level of deployment of multicast in most networks.
注：ほとんどのネットワークでマルチキャストの導入レベルが低いため、この移行テクノロジーは広く導入されたことはありません。
6over4 encapsulates IPv6 packets in IPv4 packets with their Protocol field set to 41. As a result, simply filtering all IPv4 packets that have a Protocol field equal to 41 will filter 6over4 (along with many other transition technologies).
6over4は、IPv6パケットをIPv4パケットにカプセル化し、プロトコルフィールドを41に設定します。その結果、プロトコルフィールドが41であるすべてのIPv4パケットをフィルターするだけで、6over4が（他の多くの遷移テクノロジと共に）フィルターされます。
A more selective filtering could be enforced such that 6over4 traffic is filtered while other transition traffic is still allowed. Such a filtering policy would block all IPv4 packets that have their Protocol field set to 41, and that have a Destination Address that belongs to the prefix 239.0.0.0/8.
6over4トラフィックがフィルタリングされ、他の遷移トラフィックは引き続き許可されるように、より選択的なフィルタリングを実施できます。このようなフィルタリングポリシーは、プロトコルフィールドが41に設定され、プレフィックス239.0.0.0/8に属する宛先アドレスを持つすべてのIPv4パケットをブロックします。
This filtering policy basically blocks 6over4 Neighbor Discovery traffic directed to multicast addresses, thus preventing SLAAC, address resolution, etc. Additionally, it would prevent the 6over4 multicast addresses from being leveraged for the purpose of network reconnaissance.
このフィルタリングポリシーは、基本的に、マルチキャストアドレスに向けられた6over4近隣探索トラフィックをブロックするため、SLAAC、アドレス解決などが防止されます。さらに、6over4マルチキャストアドレスがネットワーク偵察の目的で利用されるのを防ぎます。
6rd builds upon the mechanisms of 6to4 to enable the rapid deployment of IPv6 on IPv4 infrastructures, while avoiding some downsides of 6to4. Usage of 6rd was originally documented in [RFC5569], and the mechanism was generalized to other access technologies and formally standardized in [RFC5969].
6rdは6to4のメカニズムに基づいて構築されており、6to4のいくつかの欠点を回避しながら、IPv4インフラストラクチャでのIPv6の迅速な展開を可能にします。 6rdの使用法は最初に[RFC5569]で文書化され、メカニズムは他のアクセステクノロジーに一般化され、[RFC5969]で正式に標準化されました。
6rd can be blocked by blocking IPv4 packets with the Protocol field set to 41.
6番目は、プロトコルフィールドを41に設定してIPv4パケットをブロックすることでブロックできます。
6to4 [RFC3056] is an address assignment and router-to-router, host-to-router, and router-to-host automatic tunneling mechanism that is meant to provide IPv6 connectivity between IPv6 sites and hosts across the IPv4 Internet.
6to4 [RFC3056]は、IPv4サイトを介したIPv6サイトとホスト間のIPv6接続を提供することを目的とした、アドレス割り当て、ルーター間、ホスト間、およびルーター間自動トンネリングメカニズムです。
NOTE: The security considerations for 6to4 are discussed in detail in [RFC3964]. [RFC6343] provides advice to network operators about 6to4 (some of which relates to security mitigations).
注：6to4のセキュリティに関する考慮事項は、[RFC3964]で詳細に説明されています。 [RFC6343]は、6to4についてネットワークオペレーターにアドバイスを提供します（そのうちのいくつかはセキュリティ緩和策に関連しています）。
As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, could be easily blocked by filtering IPv4 packets that contain their Protocol field set to 41. This is the most effective way of filtering such traffic.
セクション3で説明したように、6to4を含むすべてのIPv6-in-IPv4トラフィックは、プロトコルフィールドが41に設定されたIPv4パケットをフィルタリングすることで簡単にブロックできます。これは、このようなトラフィックをフィルタリングする最も効果的な方法です。
If 6to4 traffic is meant to be filtered while other IPv6-in-IPv4 traffic is allowed, then more finer-grained filtering rules could be applied. For example, 6to4 traffic could be filtered by applying filtering rules such as:
6to4トラフィックをフィルタリングする一方で、他のIPv6-in-IPv4トラフィックを許可する場合は、より細かいフィルタリングルールを適用できます。たとえば、6to4トラフィックは、次のようなフィルタリングルールを適用することでフィルタリングできます。
o Filter outgoing IPv4 packets that have the Destination Address set to an address that belongs to the prefix 192.88.99.0/24.
o 宛先アドレスがプレフィックス192.88.99.0/24に属するアドレスに設定されている発信IPv4パケットをフィルタリングします。
o Filter incoming IPv4 packets that have the Source Address set to an address that belongs to the prefix 192.88.99.0/24.
o 送信元アドレスがプレフィックス192.88.99.0/24に属するアドレスに設定されている着信IPv4パケットをフィルタリングします。
NOTE: These rules assume that the corresponding nodes employ the "Anycast Prefix for 6to4 Relay Routers" [RFC3068]. It has been suggested that 6to4 relays send their packets with their IPv4 Source Address set to 192.88.99.1.
注：これらのルールは、対応するノードが「6to4リレールーターのエニーキャストプレフィックス」[RFC3068]を採用していることを前提としています。 6to4リレーは、IPv4送信元アドレスを192.88.99.1に設定してパケットを送信することが提案されています。
o Filter outgoing IPv4 packets that have the Destination Address set to the IPv4 address of well-known 6to4 relays.
o 宛先アドレスが既知の6to4リレーのIPv4アドレスに設定されている発信IPv4パケットをフィルタリングします。
o Filter incoming IPv4 packets that have the Source Address set to the IPv4 address of well-known 6to4 relays.
o 送信元アドレスが既知の6to4リレーのIPv4アドレスに設定されている着信IPv4パケットをフィルタリングします。
These last two filtering policies will generally be unnecessary, and possibly infeasible to enforce (given the number of potential 6to4 relays, and the fact that many relays might remain unknown to the network administrator). If anything, they should be applied with the additional requirement that such IPv4 packets have their Protocol field set to 41 to avoid the case where other services available at the same IPv4 address as a 6to4 relay are mistakenly made inaccessible.
これらの最後の2つのフィルタリングポリシーは一般に不要であり、強制することが不可能である可能性があります（潜在的な6to4リレーの数、および多くのリレーがネットワーク管理者に知られていない可能性があるという事実が与えられます）。どちらかと言えば、6to4リレーと同じIPv4アドレスで利用可能な他のサービスに誤ってアクセスできなくなる事態を避けるために、そのようなIPv4パケットのプロトコルフィールドを41に設定するという追加の要件を適用する必要があります。
If the filtering device has capabilities to inspect the payload of IPv4 packets, then the following filtering rules could be enforced:
フィルタリングデバイスにIPv4パケットのペイロードを検査する機能がある場合、次のフィルタリングルールを適用できます。
o Filter outgoing IPv4 packets that have their Protocol field set to 41, and that have an IPv6 Source Address (embedded in the IPv4 payload) that belongs to the prefix 2002::/16.
o プロトコルフィールドが41に設定され、プレフィックス2002 :: / 16に属するIPv6送信元アドレス（IPv4ペイロードに埋め込まれている）を持つ発信IPv4パケットをフィルタリングします。
o Filter incoming IPv4 packets that have their Protocol field set to 41, and that have an IPv6 Destination address (embedded in the IPv4 payload) that belongs to the prefix 2002::/16.
o プロトコルフィールドが41に設定されていて、プレフィックス2002 :: / 16に属するIPv6宛先アドレス（IPv4ペイロードに埋め込まれている）を持つ着信IPv4パケットをフィルタリングします。
ISATAP [RFC5214] is an Intra-site tunneling protocol, and thus it is generally expected that such traffic will not traverse the organizational firewall of an IPv4-only network. Nevertheless, ISATAP can be easily blocked by blocking IPv4 packets with a Protocol field of 41.
ISATAP [RFC5214]はサイト内トンネリングプロトコルであるため、このようなトラフィックはIPv4のみのネットワークの組織のファイアウォールを通過しないことが一般的に予想されます。それでも、プロトコルフィールドが41のIPv4パケットをブロックすることにより、ISATAPを簡単にブロックできます。
The most popular operating system that includes an implementation of ISATAP in the default installation is Microsoft Windows. Microsoft Windows obtains the ISATAP router address by resolving the domain name isatap.<localdomain> to DNS A resource records. Additionally, it tries to learn the ISATAP router address by employing Link-Local Multicast Name Resolution (LLMNR) [RFC4795] to resolve the name "isatap". As a result, blocking ISATAP by preventing hosts from successfully performing name resolution for the aforementioned names and/or by filtering packets with specific IPv4 destination addresses is both difficult and undesirable.
既定のインストールにISATAPの実装を含む最も一般的なオペレーティングシステムは、Microsoft Windowsです。 Microsoft Windowsは、ドメイン名isatap。<localdomain>をDNS Aリソースレコードに解決することにより、ISATAPルーターアドレスを取得します。さらに、リンクローカルマルチキャスト名前解決（LLMNR）[RFC4795]を使用して名前 "isatap"を解決することにより、ISATAPルーターアドレスを学習しようとします。その結果、ホストが前述の名前の名前解決を正常に実行できないようにしたり、特定のIPv4宛先アドレスでパケットをフィルタリングしたりすることによってISATAPをブロックすることは、困難で望ましくありません。
Teredo [RFC4380] is an address assignment and automatic tunneling technology that provides IPv6 connectivity to dual-stack nodes that are behind one or more Network Address Port Translation (NAPT) [RFC2663] devices, by encapsulating IPv6 packets in IPv4-based UDP datagrams. Teredo is meant to be a 'last-resort' IPv6 connectivity technology, to be used only when other technologies such as 6to4 cannot be deployed (e.g., because the edge device has not been assigned a public IPv4 address).
Teredo [RFC4380]は、IPv6パケットをIPv4ベースのUDPデータグラムにカプセル化することにより、1つ以上のネットワークアドレスポート変換（NAPT）[RFC2663]デバイスの背後にあるデュアルスタックノードにIPv6接続を提供するアドレス割り当ておよび自動トンネリングテクノロジーです。 Teredoは「最後の手段」となるIPv6接続テクノロジーであり、6to4などの他のテクノロジーを展開できない場合にのみ使用されます（たとえば、エッジデバイスにパブリックIPv4アドレスが割り当てられていないため）。
As noted in [RFC4380], in order for a Teredo client to configure its Teredo IPv6 address, it must contact a Teredo server through the Teredo service port (UDP port number 3544).
[RFC4380]に記載されているように、TeredoクライアントがTeredo IPv6アドレスを構成するには、Teredoサービスポート（UDPポート番号3544）を介してTeredoサーバーに接続する必要があります。
To prevent the Teredo initialization process from succeeding, and hence prevent the use of Teredo, an organizational firewall could filter outgoing UDP packets with a Destination Port of 3544.
Teredoの初期化プロセスが成功しないように、したがってTeredoを使用できないようにするために、組織のファイアウォールは、宛先ポートが3544の発信UDPパケットをフィルタリングできます。
NOTE: It is clear that such a filtering policy does not prevent an attacker from running its own Teredo server in the public Internet, using a non-standard UDP port for the Teredo service port (i.e., a port number other than 3544).
注：このようなフィルタリングポリシーは、攻撃者がTeredoサービスポートに非標準のUDPポート（つまり、3544以外のポート番号）を使用して、パブリックインターネットで独自のTeredoサーバーを実行することを妨げないことは明らかです。
If the filtering device has capabilities to inspect the payload of IPv4 packets, the following (additional) filtering policy could be enforced:
フィルタリングデバイスにIPv4パケットのペイロードを検査する機能がある場合、次の（追加の）フィルタリングポリシーを適用できます。
o Filter outgoing IPv4/UDP packets that embed an IPv6 packet with the "Version" field set to 6, and an IPv6 Source Address that belongs to the prefix 2001::/32.
o 「バージョン」フィールドが6に設定されたIPv6パケットと、プレフィックス2001 :: / 32に属するIPv6送信元アドレスを埋め込む発信IPv4 / UDPパケットをフィルタリングします。
o Filter incoming IPv4/UDP packets that embed an IPv6 packet with the "Version" field set to 6, and an IPv6 Destination Address that belongs to the prefix 2001::/32.
o 「バージョン」フィールドが6に設定されたIPv6パケットと、プレフィックス2001 :: / 32に属するIPv6宛先アドレスを埋め込んだ着信IPv4 / UDPパケットをフィルタリングします。
NOTE: These two filtering rules could, at least in theory, result in false positives. Additionally, they would generally require the filtering device to reassemble fragments prior to enforcing filtering rules, since the information required to enforce them might be missing in the received fragments (which should be expected if Teredo is being employed for malicious purposes).
注：これらの2つのフィルタリングルールは、少なくとも理論的には、誤検知を引き起こす可能性があります。さらに、受信されたフラグメントにフラグメントを適用するために必要な情報が欠落している可能性があるため（Teredoが悪意のある目的で使用されている場合に予想されるため）、通常、フィルタリングデバイスがフラグメントを再構成してからフィルタリングルールを適用する必要があります。
The most popular operating system that includes an implementation of Teredo in the default installation is Microsoft Windows. Microsoft Windows obtains the Teredo server addresses (primary and secondary) by resolving the domain name teredo.ipv6.microsoft.com into DNS A records. A network administrator might want to prevent Microsoft Windows hosts from obtaining Teredo service by filtering, at the organizational firewall, outgoing UDP datagrams (i.e., IPv4 packets with the Protocol field set to 17) that contain in the IPv4 Destination Address any of the IPv4 addresses that the domain name teredo.ipv6.microsoft.com maps to (or the IPv4 address of any well-known Teredo server). Additionally, the firewall would filter incoming UDP datagrams from any of the IPv4 addresses to which the domain names of well-known Teredo servers (such as teredo.ipv6.microsoft.com) resolve.
Teredoの実装を既定のインストールに含む最も一般的なオペレーティングシステムは、Microsoft Windowsです。 Microsoft Windowsは、ドメイン名teredo.ipv6.microsoft.comをDNS Aレコードに解決することにより、Teredoサーバーアドレス（プライマリおよびセカンダリ）を取得します。ネットワーク管理者は、組織のファイアウォールで、IPv4宛先アドレスにIPv4アドレスのいずれかを含む送信UDPデータグラム（つまり、プロトコルフィールドが17に設定されたIPv4パケット）をフィルタリングすることにより、Microsoft WindowsホストがTeredoサービスを取得できないようにする場合があります。ドメイン名teredo.ipv6.microsoft.comがマップする場所（またはよく知られたTeredoサーバーのIPv4アドレス）。さらに、ファイアウォールは、既知のTeredoサーバー（teredo.ipv6.microsoft.comなど）のドメイン名が解決する任意のIPv4アドレスからの着信UDPデータグラムをフィルターします。
NOTE: As these IPv4 addresses might change over time, an administrator should obtain these addresses when implementing the filtering policy, and should also be prepared to keep this list up to date. The corresponding addresses can be easily obtained from a UNIX host by issuing the command 'dig teredo.ipv6.microsoft.com a' (without quotes), where dig(1) is a free-software tool (part of the "dnsutils" package) produced by the Internet Software Consortium (ISC).
注：これらのIPv4アドレスは時間の経過とともに変化する可能性があるため、管理者はフィルタリングポリシーを実装するときにこれらのアドレスを取得し、このリストを最新の状態に保つ準備をする必要があります。対応するアドレスは、コマンド 'dig teredo.ipv6.microsoft.com a'（引用符なし）を発行することにより、UNIXホストから簡単に取得できます。ここで、dig（1）はフリーソフトウェアツール（「dnsutils」パッケージの一部）です。 ）Internet Software Consortium（ISC）によって作成されました。
It should be noted that even with all these filtering policies in place, a node in the internal network might still be able to communicate with some Teredo clients. That is, it could configure an IPv6 address itself (without even contacting a Teredo server), and it might send Teredo traffic to those peers for which intervention of the host's Teredo server is not required (e.g., Teredo clients behind a cone NAT).
これらのすべてのフィルターポリシーが設定されていても、内部ネットワークのノードは一部のTeredoクライアントと通信できる可能性があることに注意してください。つまり、（Teredoサーバーに接続することなく）IPv6アドレス自体を構成することができ、ホストのTeredoサーバーの介入が不要なピア（たとえば、コーンNATの背後にあるTeredoクライアント）にTeredoトラフィックを送信する可能性があります。
The tunnel broker model enables dynamic configuration of tunnels between a tunnel client and a tunnel server. The tunnel broker provides a control channel for creating, deleting, or updating a tunnel between the tunnel client and the tunnel server. Additionally, the tunnel broker may register the user's IPv6 address and name in the DNS. Once the tunnel is configured, data can flow between the tunnel client and the tunnel server. [RFC3053] describes the tunnel broker model, while [RFC5572] specifies the Tunnel Setup Protocol (TSP), which can be used by clients to communicate with the Tunnel Broker.
トンネルブローカーモデルは、トンネルクライアントとトンネルサーバー間のトンネルの動的構成を可能にします。トンネルブローカーは、トンネルクライアントとトンネルサーバー間のトンネルを作成、削除、または更新するための制御チャネルを提供します。さらに、トンネルブローカーは、ユーザーのIPv6アドレスと名前をDNSに登録する場合があります。トンネルが構成されると、データはトンネルクライアントとトンネルサーバーの間を流れることができます。 [RFC3053]はトンネルブローカーモデルを説明し、[RFC5572]はトンネルセットアッププロトコル（TSP）を指定します。これは、クライアントがトンネルブローカーと通信するために使用できます。
TSP can use either TCP or UDP as the transport protocol. In both cases, TSP uses port number 3653, which has been assigned by the IANA for this purpose. As a result, TSP (the Tunnel Broker control channel) can be blocked by blocking TCP and UDP packets originating from the local network and destined to UDP port 3653 or TCP port 3653. Additionally, the data channel can be blocked by blocking UDP packets originated from the local network and destined to UDP port 3653, and IPv4 packets with a Protocol field set to 41.
TSPは、トランスポートプロトコルとしてTCPまたはUDPを使用できます。どちらの場合も、TSPはこの目的のためにIANAによって割り当てられたポート番号3653を使用します。その結果、ローカルネットワークから発信され、UDPポート3653またはTCPポート3653宛てのTCPおよびUDPパケットをブロックすることにより、TSP（トンネルブローカーコントロールチャネル）をブロックできます。さらに、発信されたUDPパケットをブロックすることにより、データチャネルをブロックできます。ローカルネットワークからUDPポート3653、およびプロトコルフィールドが41に設定されたIPv4パケットを宛先としています。
AYIYA ("Anything In Anything") [AYIYA] allows the tunneling of packets across Network Address Port Translation (NAPT) [RFC2663] devices. While the specification of this tunneling mechanism was never published as an RFC, it is nevertheless widely deployed [SixXS-stats].
AYIYA（ "Anything In Anything"）[AYIYA]は、ネットワークアドレスポート変換（NAPT）[RFC2663]デバイスを介したパケットのトンネリングを許可します。このトンネリングメカニズムの仕様はRFCとして公開されたことはありませんが、広く展開されています[SixXS-stats]。
AYIYA can be blocked by blocking TCP and UDP packets originating from the local network and destined to UDP port 5072 or TCP port 5072.
ローカルネットワークから発信され、UDPポート5072またはTCPポート5072宛てのTCPおよびUDPパケットをブロックすることにより、AYIYAをブロックできます。
IPv6 deployments in the Internet are continually increasing, and some hosts default to preferring IPv6 connectivity whenever it is available. This is likely to cause IPv6-capable hosts to attempt to reach an ever-increasing number of popular destinations via IPv6, even if this IPv6 connectivity relies on a transition technology over an "IPv4-only" network.
インターネットでのIPv6の導入は継続的に増加しており、一部のホストは、利用可能な場合は常にIPv6接続を優先するようにデフォルト設定しています。これにより、このIPv6接続が「IPv4のみ」のネットワークを介した移行テクノロジーに依存している場合でも、IPv6対応のホストは、IPv6を介して増え続ける人気の宛先に到達しようとする可能性があります。
A large source of IPv6 brokenness today comes from nodes that believe that they have functional IPv6 connectivity, but the path to their destination fails somewhere upstream [Anderson2010] [Anderson2011] [Huston2010b] [Huston2012]. Upstream filtering of transition technologies or situations where a misconfigured node attempts to "provide" native IPv6 service on a given network without proper upstream IPv6 connectivity may result in hosts attempting to reach remote nodes via IPv6, and depending on the absence or presence and specific implementation details of "Happy Eyeballs" [RFC6555], there might be a non-trivial timeout period before the host falls back to IPv4 [Huston2010a] [Huston2012].
今日のIPv6の不具合の大きな原因は、IPv6接続が機能していると信じているノードにありますが、宛先へのパスが上流のどこかで失敗しています[Anderson2010] [Anderson2011] [Huston2010b] [Huston2012]。移行テクノロジーのアップストリームフィルタリング、または誤って構成されたノードが適切なアップストリームIPv6接続なしで特定のネットワークでネイティブIPv6サービスを「提供」しようとする状況は、ホストがIPv6を介してリモートノードに到達しようとする場合があり、不在または存在と特定の実装によっては「Happy Eyeballs」[RFC6555]の詳細では、ホストがIPv4 [Huston2010a] [Huston2012]にフォールバックする前に、重要なタイムアウト時間が発生する可能性があります。
For this reason, networks attempting to prevent IPv6 traffic from traversing their devices should consider configuring their local recursive DNS servers to respond to queries for AAAA DNS records with a DNS RCODE of 0 (NOERROR) [RFC1035] or to silently ignore such queries, and should even consider filtering AAAA records at the network ingress point to prevent the internal hosts from attempting their own DNS resolution. This will ensure that hosts that are on an "IPv4-only" network will only receive DNS A records, and they will be unlikely to attempt to use (likely broken) IPv6 connectivity to reach their desired destinations.
このため、IPv6トラフィックがデバイスを通過しないようにするネットワークは、DNS RCODEが0（NOERROR）[RFC1035]のAAAA DNSレコードのクエリに応答するか、そのようなクエリを暗黙的に無視するようにローカル再帰DNSサーバーを構成することを検討する必要があります。は、内部ホストが独自のDNS解決を試行しないように、ネットワーク入力ポイントでAAAAレコードをフィルタリングすることも検討する必要があります。これにより、「IPv4のみ」のネットワーク上にあるホストはDNS Aレコードのみを受信し、IPv6接続を使用して（壊れている可能性が高い）目的の宛先に到達することはほとんどありません。
We note that in scenarios where DNSSEC [RFC4033] is deployed, stripping AAAA records from DNS responses would lead to DNS responses elicited by queries with the DO and CD bits set [RFC4035] to be considered invalid, and hence discarded. This situation is similar to that of DNS64 [RFC6147] in the presence of DNSSEC and should be considered a drawback associated with this approach.
DNSSEC [RFC4033]が展開されているシナリオでは、DNS応答からAAAAレコードを削除すると、DOおよびCDビットが設定されたクエリ[RFC4035]によって引き出されたDNS応答が無効と見なされ、破棄されることに注意してください。この状況は、DNSSECが存在する場合のDNS64 [RFC6147]の状況に似ており、このアプローチに関連する欠点と見なす必要があります。
Additionally, it should be noted that when filtering IPv6 traffic, it is good practice to signal the packet drop to the source node, such that it is able to react to the packet drop in a more appropriate and timely way. For example, a firewall could signal the packet drop by means of an ICMPv6 error message (or TCP [RFC0793] RST segment if appropriate), such that the source node can, e.g., quickly react as described in [RFC5461]. For obvious reasons, if the traffic being filtered is IPv6 transition/coexistence traffic, the signaling packet should be sent by means of the corresponding IPv6 transition/ coexistence technology.
さらに、IPv6トラフィックをフィルタリングするときは、パケットドロップをより適切かつタイムリーに反応できるように、パケットドロップをソースノードに通知することをお勧めします。たとえば、ファイアウォールはICMPv6エラーメッセージ（または適切な場合はTCP [RFC0793] RSTセグメント）を使用してパケットドロップを通知し、[RFC5461]で説明されているようにソースノードがすばやく反応できるようにします。明らかな理由により、フィルタリングされるトラフィックがIPv6移行/共存トラフィックである場合、シグナリングパケットは、対応するIPv6移行/共存テクノロジを使用して送信する必要があります。
This document discusses the security implications of IPv6 on IPv4 networks and describes a number of techniques to mitigate the aforementioned issues. In general, the possible mitigations boil down to enforcing on native IPv6 and IPv6 transition/coexistence traffic the same security policies currently enforced for IPv4 traffic and/or blocking the aforementioned traffic when it is deemed as undesirable.
このドキュメントでは、IPv4ネットワークでのIPv6のセキュリティへの影響について説明し、前述の問題を軽減するためのいくつかの手法について説明します。一般に、可能な緩和策は、ネイティブIPv6とIPv6の移行/共存トラフィックに、現在IPv4トラフィックに適用されているのと同じセキュリティポリシーを適用したり、望ましくないと見なされたときに前述のトラフィックをブロックしたりすることになります。
The authors would like to thank Wes George, who contributed most of the text that comprises Section 4 of this document.
著者は、このドキュメントのセクション4を構成するテキストのほとんどを提供してくれたウェスジョージに感謝します。
The authors would like to thank (in alphabetical order) Ran Atkinson, Brian Carpenter, Stephen Farrell, Guillermo Gont, Joel Jaeggli, Panos Kampanakis, Warren Kumari, Ted Lemon, David Malone, Joseph Salowey, Arturo Servin, Donald Smith, Tina Tsou, and Eric Vyncke for providing valuable comments on earlier versions of this document.
著者は（アルファベット順で）ランアトキンソン、ブライアンカーペンター、スティーブンファレル、ギジェルモゴン、ジョエルジャグリ、パノスカンパナキス、ウォーレンクマリ、テッドレモン、デビッドマローン、ジョセフサロウイ、アルトゥーロサーヴィン、ドナルドスミス、ティナツウ、このドキュメントの以前のバージョンに関する貴重なコメントを提供してくださったEric Vyncke氏。
This document is based on the results of the project "Security Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI). Fernando Gont would like to thank the UK CPNI for their continued support.
このドキュメントは、国立インフラストラクチャ保護センター（CPNI）に代わってフェルナンドゴントが実施したプロジェクト「インターネットプロトコルバージョン6（IPv6）のセキュリティ評価」[CPNI-IPv6]の結果に基づいています。フェルナンドゴントは、英国CPNIの継続的な支援に感謝します。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529] Carpenter、B。およびC. Jung、「明示的なトンネルのないIPv4ドメインを介したIPv6の転送」、RFC 2529、1999年3月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053] Durand、A.、Fasano、P.、Guardini、I。、およびD. Lento、「IPv6 Tunnel Broker」、RFC 3053、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B。およびK.ムーア、「IPv4クラウドを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068] Huitema、C。、「Antocast Prefix for 6to4 Relay Routers」、RFC 3068、2001年6月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのプロトコル変更」、RFC 4035、2005年3月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema、C。、「Teredo：Tunneling IPv6 over UDP through Network Address Translations（NATs）」、RFC 4380、2006年2月。
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007.
[RFC4795] Aboba、B.、Thaler、D。、およびL. Esibov、「Link-local Multicast Name Resolution（LLMNR）」、RFC 4795、2007年1月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214] Templin、F.、Gleeson、T。、およびD. Thaler、「Intra-Site Automatic Tunnel Addressing Protocol（ISATAP）」、RFC 5214、2008年3月。
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5569] Despres、R。、「IPv4 Infrastructures on IPv4 Infrastructures（6rd）」、RFC 5569、2010年1月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969] Townsley、W.およびO. Troan、「IPv4 Infrastructures on IPv4 Infrastructures（6rd）-Protocol Specification」、RFC 5969、2010年8月。
[RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", RFC 5572, February 2010.
[RFC5572] Blanchet、M。、およびF. Parent、「IPv6 Tunnel Broker with the Tunnel Setup Protocol（TSP）」、RFC 5572、2010年2月。
[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.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P.、I。van Beijnum、「DNS64：DNS Extensions for Network Address Translation to IPv4 Servers to IPv4 Servers」、RFC 6147、2011年4月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、1999年8月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756] Nikander、P.、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trust Models and Threats」、RFC 3756、2004年5月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964] Savola、P。およびC. Patel、「6to4のセキュリティに関する考慮事項」、RFC 3964、2004年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.
[RFC 5461]フォント、OF。、「ソフトエラーに対するTCPの反応」、RFC 5461、2009年2月。
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, August 2011.
[RFC6101] Freier、A.、Karlton、P。、およびP. Kocher、「Secure Sockets Layer（SSL）Protocol Version 3.0」、RFC 6101、2011年8月。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.
[RFC6105] Levy-Abegnoli、E.、Van de Velde、G.、Popoviciu、C.、J。Mohacsi、「IPv6 Router Advertisement Guard」、RFC 6105、2011年2月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169]クリシュナン、S。、ターラー、D。、およびJ.ホアグランド、「IPトンネリングに関するセキュリティ上の懸念」、RFC 6169、2011年4月。
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
[RFC6343]カーペンター、B。、「6to4展開に関する勧告ガイドライン」、RFC 6343、2011年8月。
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, April 2012.
[RFC6540] George W.、Donley、C.、Liljenstolpe、C。、およびL. Howard、「すべてのIP対応ノードに必要なIPv6サポート」、BCP 177、RFC 6540、2012年4月。
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6555] Wing、D。およびA. Yourtchenko、「Happy Eyeballs：Success with Dual-Stack Hosts」、RFC 6555、2012年4月。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013.
[RFC6762] Cheshire、S。およびM. Krochmal、「マルチキャストDNS」、RFC 6762、2013年2月。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリ」、RFC 6763、2013年2月。
[RA-GRD-IMP] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", Work in Progress, November 2012.
[RA-GRD-IMP] Gont、F。、「IPv6ルーターアドバタイズメントガード（RA-Guard）の実装に関するアドバイス」、作業中、2012年11月。
[VPN-LEAKS] Gont, F., "Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks", Work in Progress, August 2013.
[VPN-LEAKS] Gont、F。、「デュアルスタックホスト/ネットワークでの仮想プライベートネットワーク（VPN）トラフィックリーク」、Work in Progress、2013年8月。
[SHIELD] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", Work in Progress, October 2013.
[シールド] Gont、F.、Liu、W。、およびG. Van de Velde、「DHCPv6-Shield：Protecting Against Rogue DHCPv6 Servers」、Work in Progress、2013年10月。
[AYIYA] Massar, J., "AYIYA: Anything In Anything", Work in Progress, July 2004.
[AYIYA]マッサーJ。、「AYIYA：Anything In Anything」、進行中の作業、2004年7月。
[IANA-ETHER] IANA, "Ethernet Numbers", <http://www.iana.org/assignments/ethernet-numbers>.
[IANA-ETHER] IANA、「イーサネット番号」、<http://www.iana.org/assignments/ethernet-numbers>。
[CERT2009] Giobbi, R., "Bypassing Firewalls with IPv6 Tunnels", CERT/ CC Blog, April 2009, <http://www.cert.org/blogs/vuls/2009/ 04/bypassing_firewalls_with_ipv6.html>.
[CERT2009] Giobbi、R。、「Bypassing Firewalls with IPv6 Tunnels」、CERT / CC Blog、2009年4月、<http://www.cert.org/blogs/vuls/2009/ 04 / bypassing_firewalls_with_ipv6.html>。
[Huston2010a] Huston, G., "IPv6 Measurements", 2010, <http://www.potaroo.net/stats/1x1/>.
[Huston2010a] Huston、G。、「IPv6 Measurements」、2010、<http://www.potaroo.net/stats/1x1/>。
[Huston2010b] Huston, G., "Flailing IPv6", The ISP Column: A monthly column on things Internet, December 2010, <http://www.potaroo.net/ispcol/2010-12/6to4fail.pdf>.
[Huston2010b] Huston、G。、「Flailing IPv6」、ISPコラム：インターネットに関する月刊コラム、2010年12月、<http://www.potaroo.net/ispcol/2010-12/6to4fail.pdf>。
[Huston2012] Huston, G., "Bemused Eyeballs: Tailoring Dual Stack Applications in a CGN Environment", The ISP Column: A monthly column on things Internet, May 2012, <http://www.potaroo.net/ispcol/2012-05/notquite.pdf>.
[Huston2012] Huston、G。、「Bemused Eyeballs：Tailoring Dual Stack Applications in CGN Environment」、ISPコラム：月刊インターネットに関するコラム、2012年5月、<http://www.potaroo.net/ispcol/2012 -05 / notquite.pdf>。
[Anderson2010] Anderson, T., "Measuring and combating IPv6 brokenness", RIPE 61, Roma, November 2010, <http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
[アンダーソン2010]アンダーソン、T。、「IPv6の破損の測定と対処」、RIPE 61、ローマ、2010年11月、<http://ripe61.ripe.net/presentations/162-ripe61.pdf>。
[Anderson2011] Anderson, T., "IPv6 dual-stack client loss in Norway", 2011, <http://www.fud.no/ipv6/>.
[Anderson2011] Anderson、T.、「ノルウェーにおけるIPv6デュアルスタッククライアントの損失」、2011年、<http://www.fud.no/ipv6/>。
[CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request), .
[CPNI-IPv6] Gont、F。、「インターネットプロトコルバージョン6（IPv6）のセキュリティ評価」、国立国家インフラストラクチャ保護センター（リクエストに応じて利用可能）、
[IPv6-Toolkit] SI6 Networks, "SI6 Networks' IPv6 Toolkit", <http://www.si6networks.com/tools/ipv6toolkit>.
[IPv6-Toolkit] SI6 Networks、「SI6 Networks 'IPv6 Toolkit」、<http://www.si6networks.com/tools/ipv6toolkit>。
[THC-IPV6] The Hacker's Choice, "THC-IPV6 - attacking the IPV6 protocol suite", December 2013, <http://www.thc.org/thc-ipv6/>.
[THC-IPV6] Hacker's Choice、「THC-IPV6-attacking the IPV6 protocol suite」、2013年12月、<http://www.thc.org/thc-ipv6/>。
[Waters2011] Waters, A., "The SLAAC Attack - using IPv6 as a weapon against IPv4", April 2011, <http://wirewatcher.wordpress.com/2011/04/04/ the-slaac-attack-using-ipv6-as-a-weapon-against-ipv4/>.
[Waters2011]ウォーターズ、A。、「SLAAC攻撃-IPv4に対する武器としてIPv6を使用」、2011年4月、<http://wirewatcher.wordpress.com/2011/04/04/ the-slaac-attack-using- ipv6-as-a-weapon-against-ipv4 />。
[SixXS-stats] SixXS, , "SixXS - IPv6 Deployment & Tunnel Broker :: Statistics", 2013, <http://www.sixxs.net/misc/usage/>.
[SixXS-stats] SixXS、、 "SixXS-IPv6 Deployment＆Tunnel Broker :: Statistics"、2013、<http://www.sixxs.net/misc/usage/>。
+-------------+-----------------------------------------------------+
| Technology | Filtering rules |
+-------------+-----------------------------------------------------+
| Native IPv6 | EtherType 0x86DD |
+-------------+-----------------------------------------------------+
| 6in4 | IP proto 41 |
+-------------+-----------------------------------------------------+
| 6over4 | IP proto 41 |
+-------------+-----------------------------------------------------+
| 6rd | IP proto 41 |
+-------------+-----------------------------------------------------+
| 6to4 | IP proto 41 |
+-------------+-----------------------------------------------------+
| ISATAP | IP proto 41 |
+-------------+-----------------------------------------------------+
| Teredo | UDP Dest Port 3544 |
+-------------+-----------------------------------------------------+
| TB with TSP | (IP proto 41) || (UDP Dest Port 3653 || TCP Dest |
| | Port 3653) |
+-------------+-----------------------------------------------------+
| AYIYA | UDP Dest Port 5072 || TCP Dest Port 5072 |
+-------------+-----------------------------------------------------+
Table 1: Summary of filtering rules
表1：フィルタリングルールの概要
NOTE: the table above describes general and simple filtering rules for blocking the corresponding traffic. More finer-grained rules might be available in each of the corresponding sections of this document.
注：上記の表は、対応するトラフィックをブロックするための一般的で単純なフィルタリングルールを示しています。このドキュメントの対応する各セクションで、より詳細なルールを利用できる場合があります。
Authors' Addresses
著者のアドレス
Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
フェルナンドゴンSI6ネットワーク/ UTN-FRHエヴァリストキャリーゴ2644ブエノスアイレス州ハエド1706アルゼンチン
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI: http://www.si6networks.com
Will (Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China
will（Shu成）l IU hu Aはテクノロジー禁止の日であり、長い公正な地区は非常に現実的です518129 P.R. China
EMail: liushucheng@huawei.com