IPv6ネットワークでのネットワーク偵察
英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。
日本語訳
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7707 Huawei Technologies
Obsoletes: 5157 T. Chown
Category: Informational Jisc
ISSN: 2070-1721 March 2016
Network Reconnaissance in IPv6 Networks
IPv6ネットワークでのネットワーク偵察
Abstract
概要
IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or fewer unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address-scanning attacks against IPv6 networks; therefore, IPv6 address-scanning attacks have been considered unfeasible. This document formally obsoletes RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address- scanning techniques apply to IPv6 networks and exploring some additional techniques that can be employed for IPv6 network reconnaissance.
IPv6は、IPv4のものよりもはるかに大きなアドレス空間を提供します。 サイズが/ 64のIPv6サブネットは（理論上）約1.844 * 10 ^ 19ホストに対応できるため、サイトに通常65,000または 一意のアドレスが少なくなります。 その結果、IPv6ネットワークに対してアドレススキャン攻撃を実行するには多大な労力が必要になると広く想定されています。 したがって、IPv6アドレススキャン攻撃は実行不可能と見なされています。 このドキュメントは、この仮定を最初に説明したRFC 5157を正式に廃止しました。これは、従来のアドレススキャン手法が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/rfc7707.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7707で入手できます。
Gont & Chown Informational [Page 1] RFC 7707 IPv6 Reconnaissance March 2016 Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements for the Applicability of Network Reconnaissance
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 6
4.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 6
4.1.1. Stateless Address Autoconfiguration (SLAAC) . . . . . 6
4.1.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 11
4.1.3. Manually Configured Addresses . . . . . . . . . . . . 12
4.1.4. IPv6 Addresses Corresponding to
Transition/Coexistence Technologies . . . . . . . . . 14
4.1.5. IPv6 Address Assignment in Real-World Network
Scenarios . . . . . . . . . . . . . . . . . . . . . . 14
4.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 17
4.2.1. Reducing the Subnet ID Search Space . . . . . . . . . 18
4.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 19
4.4. Existing IPv6 Address-Scanning Tools . . . . . . . . . . 20
4.4.1. Remote IPv6 Network Address Scanners . . . . . . . . 20
4.4.2. Local IPv6 Network Address Scanners . . . . . . . . . 21
4.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 21
4.6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 22
5. Alternative Methods to Glean IPv6 Addresses . . . . . . . . . 23
5.1. Leveraging the Domain Name System (DNS) for Network
Reconnaissance . . . . . . . . . . . . . . . . . . . . . 23
5.1.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . 23
5.1.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . 23
5.1.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . 23
5.1.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . 24
5.2. Leveraging Local Name Resolution and Service Discovery
Services . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Public Archives . . . . . . . . . . . . . . . . . . . . . 25
Gont & Chown Informational [Page 2]
RFC 7707 IPv6 Reconnaissance March 2016
5.4. Application Participation . . . . . . . . . . . . . . . . 25
5.5. Inspection of the IPv6 Neighbor Cache and Routing Table . 25
5.6. Inspection of System Configuration and Log Files . . . . 26
5.7. Gleaning Information from Routing Protocols . . . . . . . 26
5.8. Gleaning Information from IP Flow Information Export
(IPFIX) . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.9. Obtaining Network Information with traceroute6 . . . . . 26
5.10. Gleaning Information from Network Devices Using SNMP . . 27
5.11. Obtaining Network Information via Traffic Snooping . . . 27
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Implementation of a Full-Fledged IPv6 Address-
Scanning Tool . . . . . . . . . . . . . . . . . . . 34
A.1. Host-Probing Considerations . . . . . . . . . . . . . . . 34
A.2. Implementation of an IPv6 Local Address-Scanning Tool . . 35
A.3. Implementation of an IPv6 Remote Address-Scanning Tool . 36
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1.はじめに. . . . . . . . . . . . . . . . . . . . . . . . 3
2.規約. . . . . . . . . . . . . . . . . . . . . . . . . 4
3.ネットワーク偵察の適用性の要件
テクニック. . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IPv6アドレススキャン. . . . . . . . . . . . . . . . . . . . 6
4.1. IPv6でのアドレス設定. . . . . . . . . . . . . . 6
4.1.1.ステートレスアドレス自動構成（SLAAC）. . . . . 6
4.1.2. IPv6の動的ホスト構成プロトコル（DHCPv6）11
4.1.3.手動で構成されたアドレス. . . . . . . . . . . 12
4.1.4.対応するIPv6アドレス
移行/共存テクノロジ. . . . . . . . . 14
4.1.5.現実のネットワークにおけるIPv6アドレスの割り当て
シナリオ. . . . . . . . . . . . . . . . . . . . . . 14
4.2.リモートネットワークのIPv6アドレススキャン. . . . . . . . 17
4.2.1.サブネットID検索スペースの削減. . . . . . . . . 18
4.3.ローカルネットワークのIPv6アドレススキャン. . . . . . . . . 19
4.4.既存のIPv6アドレススキャンツール. . . . . . . . . . 20
4.4.1.リモートIPv6ネットワークアドレススキャナー. . . . . . . . 20
4.4.2.ローカルIPv6ネットワークアドレススキャナー. . . . . . . . . 21
4.5.緩和策. . . . . . . . . . . . . . . . . . . . . . . 21
4.6結論. . . . . . . . . . . . . . . . . . . . . . . 22
5. Glean IPv6アドレスの代替方法. . . . . . . . . 23
5.1.ネットワークのドメインネームシステム（DNS）の活用
偵察. . . . . . . . . . . . . . . . . . . . . 23
5.1.1. DNSアドバタイズホスト. . . . . . . . . . . . . . . . 23
5.1.2. DNSゾーン転送. . . . . . . . . . . . . . . . . 23
5.1.3. DNSブルートフォーシング. . . . . . . . . . . . . . . . . . 23
5.1.4. DNSリバースマッピング. . . . . . . . . . . . . . . . 24
5.2.ローカルの名前解決とサービス検出の活用
サービス. . . . . . . . . . . . . . . . . . . . . . . . 24
5.3.公開アーカイブ. . . . . . . . . . . . . . . . . . . . . 25
5.4.アプリケーション参加. . . . . . . . . . . . . . . . 25
5.5. IPv6ネイバーキャッシュとルーティングテーブルの検査. 25
5.6.システム構成とログファイルの検査. . . . 26
5.7.ルーティングプロトコルから情報を収集する. . . . . . . 26
5.8 IPフロー情報エクスポートからの情報の収集
（IPFIX）. . . . . . . . . . . . . . . . . . . . . . . . . 26
5.9. traceroute6によるネットワーク情報の取得. . . . . 26
5.10. SNMPを使用してネットワークデバイスから情報を収集する. . 27
5.11.トラフィックスヌーピングを介したネットワーク情報の取得. . . 27
6.結論. . . . . . . . . . . . . . . . . . . . . . . . . 27
7.セキュリティに関する考慮事項. . . . . . . . . . . . . . . . . . . 27
8.参考資料. . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1.規範的な参照. . . . . . . . . . . . . . . . . . 28
8.2.有益な参照. . . . . . . . . . . . . . . . . 29
付録A.本格的なIPv6アドレスの実装-
スキャンツール. . . . . . . . . . . . . . . . . . . 34
A.1.ホストプロービングの考慮事項. . . . . . . . . . . . . . . 34
A.2. IPv6ローカルアドレススキャンツールの実装. . 35
A.3. IPv6リモートアドレススキャンツールの実装. 36
謝辞. . . . . . . . . . . . . . . . . . . . . . . . 37
著者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction
1.はじめに
The main driver for IPv6 [RFC2460] deployment is its larger address space [CPNI-IPv6]. This larger address space not only allows for an increased number of connected devices but also introduces a number of subtle changes in several aspects of the resulting networks. One of these changes is the reduced host density (the number of hosts divided by the number of addresses) of typical IPv6 subnetworks, when compared to their IPv4 counterparts. [RFC5157] describes how this significantly lower IPv6 host density is likely to make classic network address-scanning attacks less feasible, since even by applying various heuristics, the address space to be scanned remains very large. RFC 5157 goes on to describe some alternative methods for attackers to glean active IPv6 addresses and provides some guidance for administrators and implementors, e.g., not using sequential addresses with DHCPv6.
IPv6 [RFC2460]展開の主な推進力は、より大きなアドレス空間[CPNI-IPv6]です。 このより大きなアドレス空間は、接続されたデバイスの数を増やすだけでなく、結果として得られるネットワークのいくつかの側面にいくつかの微妙な変化をもたらします。 これらの変更の1つは、一般的なIPv6サブネットワークのホスト密度（ホストの数をアドレスの数で割ったもの）が、IPv4と比較して減少していることです。 [RFC5157]は、この大幅に低いIPv6ホスト密度により、従来のネットワークアドレススキャン攻撃の実現性を低下させる可能性があることを説明しています。 RFC 5157はさらに、攻撃者がアクティブなIPv6アドレスを収集するためのいくつかの代替方法を説明し、DHCPv6で連続アドレスを使用しないなど、管理者と実装者にいくつかのガイダンスを提供します。
With the benefit of more than five years of additional IPv6 deployment experience, this document formally obsoletes RFC 5157. It emphasizes that while address-scanning attacks are less feasible, they may, with appropriate heuristics, remain possible. At the time that RFC 5157 was written, observed address-scanning attacks were typically across ports on the addresses of discovered servers; since then, evidence that some classic address scanning is occurring is being witnessed. This text thus updates the analysis on the feasibility of address-scanning attacks in IPv6 networks, and it Gont & Chown Informational [Page 3] RFC 7707 IPv6 Reconnaissance March 2016 explores a number of additional techniques that can be employed for IPv6 network reconnaissance. Practical examples and guidance are also included in the appendices.
5年を超えるIPv6展開の経験を生かして、このドキュメントはRFC 5157を正式に廃止します。 それは、アドレススキャン攻撃は実行可能ではありませんが、適切なヒューリスティックスがあれば、依然として可能性があることを強調しています。 RFC 5157が作成された時点で、観察されたアドレススキャン攻撃は、通常、発見されたサーバーのアドレスのポートを横断していました。 それ以来、いくつかの古典的な住所スキャンが行われている証拠が目撃されています。 したがって、このテキストでは、IPv6ネットワークでのアドレススキャン攻撃の実現可能性に関する分析を更新し、IPv6ネットワークの偵察に使用できる追加のテクニックをいくつか探っています。 実用的な例とガイダンスも付録に含まれています。
On one hand, raising awareness about IPv6 network reconnaissance techniques may allow (in some cases) network and security administrators to prevent or detect such attempts. On the other hand, network reconnaissance is essential for the so-called "penetration tests" typically performed to assess the security of production networks. As a result, we believe the benefits of a thorough discussion of IPv6 network reconnaissance are twofold.
一方では、IPv6ネットワークの偵察技術についての認識を高めることで、（場合によっては）ネットワークおよびセキュリティ管理者がそのような試みを防止または検出できるようになります。 一方、本番ネットワークのセキュリティを評価するために通常実行される、いわゆる「侵入テスト」には、ネットワーク偵察が不可欠です。 その結果、IPv6ネットワークの偵察に関する徹底的な議論の利点は2つあると考えています。
Section 4 analyzes the feasibility of address-scanning attacks (e.g., ping sweeps) in IPv6 networks and explores a number of possible improvements to such techniques. Appendix A describes how the aforementioned analysis can be leveraged to produce address-scanning tools (e.g., for penetration testing purposes). Finally, the rest of this document discusses a number of miscellaneous techniques that could be leveraged for IPv6 network reconnaissance.
セクション4では、IPv6ネットワークでのアドレススキャン攻撃（pingスイープなど）の実現可能性を分析し、そのような技術に対するいくつかの可能な改善点を探ります。 付録Aでは、前述の分析を活用してアドレススキャンツールを作成する方法について説明します（侵入テストの目的など）。 最後に、このドキュメントの残りの部分では、IPv6ネットワークの偵察に活用できるさまざまなさまざまな手法について説明します。
2. Conventions
2.規約
Throughout this document, we consider that bits are numbered from left to right, starting at 0, and that bytes are numbered from left to right, starting at 0.
このドキュメント全体を通して、ビットには0から始まり左から右に番号が付けられ、バイトには0から始まり左から右に番号が付けられていると見なします。
3. Requirements for the Applicability of Network Reconnaissance
Techniques
3.ネットワーク偵察技術の適用性の要件
Throughout this document, a number of network reconnaissance techniques are discussed. Each of these techniques has different requirements on the side of the practitioner, with respect to whether they require local access to the target network and whether they require login access (or similar access credentials) to the system on which the technique is applied.
このドキュメント全体を通して、いくつかのネットワーク偵察テクニックが説明されています。 これらの手法には、ターゲットネットワークへのローカルアクセスが必要かどうか、および手法が適用されるシステムへのログインアクセス（または同様のアクセス資格情報）が必要かどうかに関して、施術者側で異なる要件があります。
The following table tries to summarize the aforementioned requirements and serves as a cross index to the corresponding sections.
次の表は、前述の要件をまとめたもので、対応するセクションへの相互索引として機能します。
Gont & Chown Informational [Page 4]
RFC 7707 IPv6 Reconnaissance March 2016
+---------------------------------------------+----------+----------+
| Technique | Local | Login |
| | access | access |
+---------------------------------------------+----------+----------+
| Remote Address Scanning (Section 4.2) | No | No |
+---------------------------------------------+----------+----------+
| Local Address Scanning (Section 4.3) | Yes | No |
+---------------------------------------------+----------+----------+
| DNS Advertised Hosts (Section 5.1.1) | No | No |
+---------------------------------------------+----------+----------+
| DNS Zone Transfers (Section 5.1.2) | No | No |
+---------------------------------------------+----------+----------+
| DNS Brute Forcing (Section 5.1.3) | No | No |
+---------------------------------------------+----------+----------+
| DNS Reverse Mappings (Section 5.1.4) | No | No |
+---------------------------------------------+----------+----------+
| Leveraging Local Name Resolution and | Yes | No |
| Service Discovery Services (Section 5.2) | | |
+---------------------------------------------+----------+----------+
| Public Archives (Section 5.3) | No | No |
+---------------------------------------------+----------+----------+
| Application Participation (Section 5.4) | No | No |
+---------------------------------------------+----------+----------+
| Inspection of the IPv6 Neighbor Cache and | No | Yes |
| Routing Table (Section 5.5) | | |
+---------------------------------------------+----------+----------+
| Inspecting System Configuration and Log | No | Yes |
| Files (Section 5.6) | | |
+---------------------------------------------+----------+----------+
| Gleaning Information from Routing Protocols | Yes | No |
| (Section 5.7) | | |
+---------------------------------------------+----------+----------+
| Gleaning Information from IP Flow | No | Yes |
| Information Export (IPFIX) (Section 5.8) | | |
+---------------------------------------------+----------+----------+
| Obtaining Network Information with | No | No |
| traceroute6 (Section 5.9) | | |
+---------------------------------------------+----------+----------+
| Gleaning Information from Network Devices | No | Yes |
| Using SNMP (Section 5.10) | | |
+---------------------------------------------+----------+----------+
| Obtaining Network Information via Traffic | Yes | No |
| Snooping (Section 5.11) | | |
+---------------------------------------------+----------+----------+
Table 1: Requirements for the Applicability of
Network Reconnaissance Techniques
表1：ネットワーク偵察技術の適用性の要件
Gont & Chown Informational [Page 5] RFC 7707 IPv6 Reconnaissance March 2016 4. IPv6 Address Scanning
4. IPv6アドレススキャン
This section discusses how traditional address-scanning techniques (e.g., "ping sweeps") apply to IPv6 networks. Section 4.1 provides an essential analysis of how address configuration is performed in IPv6, identifying patterns in IPv6 addresses that can be leveraged to reduce the IPv6 address search space when performing IPv6 address- scanning attacks. Section 4.2 discusses IPv6 address scanning of remote networks. Section 4.3 discusses IPv6 address scanning of local networks. Section 4.4 discusses existing IPv6 address-scanning tools. Section 4.5 provides advice on how to mitigate IPv6 address- scanning attacks. Finally, Appendix A discusses how the insights obtained in the following subsections can be incorporated into a fully fledged IPv6 address-scanning tool.
このセクションでは、従来のアドレススキャン手法（「pingスイープ」など）がIPv6ネットワークにどのように適用されるかについて説明します。 セクション4.1は、IPv6でアドレス構成がどのように実行されるかに関する重要な分析を提供し、IPv6アドレススキャン攻撃を実行するときにIPv6アドレス検索スペースを削減するために活用できるIPv6アドレスのパターンを識別します。 セクション4.2では、リモートネットワークのIPv6アドレススキャンについて説明します。 セクション4.3では、ローカルネットワークのIPv6アドレススキャンについて説明します。 セクション4.4では、既存のIPv6アドレススキャンツールについて説明します。 セクション4.5は、IPv6アドレススキャン攻撃を軽減する方法に関するアドバイスを提供します。 最後に、付録Aでは、以下のサブセクションで得られた洞察を、本格的なIPv6アドレススキャンツールに組み込む方法について説明します。
4.1. Address Configuration in IPv6
4.1。 IPv6でのアドレス構成
IPv6 incorporates two automatic address-configuration mechanisms: Stateless Address Autoconfiguration (SLAAC) [RFC4862] and Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. Support for SLAAC for automatic address configuration is mandatory, while support for DHCPv6 is optional -- however, most current versions of general- purpose operating systems support both. In addition to automatic address configuration, hosts, typically servers, may employ manual configuration, in which all the necessary information is manually entered by the host or network administrator into configuration files at the host.
IPv6には、2つの自動アドレス構成メカニズムが組み込まれています。ステートレスアドレス自動構成（SLAAC）[RFC4862]とIPv6の動的ホスト構成プロトコル（DHCPv6）[RFC3315]です。 DHCPv6のサポートはオプションですが、自動アドレス構成のSLAACのサポートは必須ですが、汎用オペレーティングシステムの最新バージョンのほとんどは両方をサポートしています。 自動アドレス構成に加えて、ホスト（通常はサーバー）は手動構成を使用できます。この構成では、必要なすべての情報がホストまたはネットワーク管理者によってホストの構成ファイルに手動で入力されます。
The following subsections describe each of the possible configuration mechanisms/approaches in more detail.
以下のサブセクションでは、可能な構成メカニズム/アプローチのそれぞれについてより詳細に説明します。
4.1.1. Stateless Address Autoconfiguration (SLAAC)
4.1.1。 ステートレスアドレス自動構成（SLAAC）
The basic idea behind SLAAC is that every host joining a network will send a multicasted solicitation requesting network configuration information, and local routers will respond to the request providing the necessary information. SLAAC employs two different ICMPv6 message types: ICMPv6 Router Solicitation and ICMPv6 Router Advertisement messages. Router Solicitation messages are employed by hosts to query local routers for configuration information, while Router Advertisement messages are employed by local routers to convey the requested information.
SLAACの背後にある基本的な考え方は、ネットワークに参加するすべてのホストがマルチキャスト要請を送信してネットワーク構成情報を要求し、ローカルルーターが要求に応答して必要な情報を提供するというものです。 SLAACは、ICMPv6ルーター要請メッセージとICMPv6ルーターアドバタイズメントメッセージという2つの異なるICMPv6メッセージタイプを採用しています。 ルーター要請メッセージは、ホストがローカルルーターに構成情報を照会するために使用され、ルーターアドバタイズメッセージは、ローカルルーターが要求された情報を伝達するために使用されます。
Gont & Chown Informational [Page 6] RFC 7707 IPv6 Reconnaissance March 2016 Router Advertisement messages convey a plethora of network configuration information, including the IPv6 prefix that should be used for configuring IPv6 addresses on the local network. For each local prefix learned from a Router Advertisement message, an IPv6 address is configured by appending a locally generated Interface Identifier (IID) to the corresponding IPv6 prefix.
ルーターアドバタイズメッセージは、ローカルネットワークでIPv6アドレスを構成するために使用する必要があるIPv6プレフィックスを含む、大量のネットワーク構成情報を伝えます。 ルーターアドバタイズメッセージから学習したローカルプレフィックスごとに、ローカルで生成されたインターフェイス識別子（IID）を対応するIPv6プレフィックスに追加することにより、IPv6アドレスが構成されます。
The following subsections describe currently deployed policies for generating the IIDs used with SLAAC.
以下のサブセクションでは、SLAACで使用されるIIDを生成するために現在展開されているポリシーについて説明します。
4.1.1.1. Interface Identifiers Embedding IEEE Identifiers
4.1.1.1。 IEEE識別子を埋め込むインターフェース識別子
The traditional SLAAC IIDs are based on the link-layer address of the corresponding network interface card. For example, in the case of Ethernet addresses, the IIDs are constructed as follows:
従来のSLAAC IIDは、対応するネットワークインターフェイスカードのリンク層アドレスに基づいています。 たとえば、イーサネットアドレスの場合、IIDは次のように構成されます。
1. The "Universal" bit (bit 6, from left to right) of the address is
set to 1.
1.アドレスの「ユニバーサル」ビット（ビット6、左から右）が1に設定されている。
2. The word 0xfffe is inserted between the Organizationally Unique
Identifier (OUI) and the rest of the Ethernet address.
2.組織的に一意の識別子（OUI）と残りのイーサネットアドレスの間に単語0xfffeが挿入されます。
For example, the Media Access Control (MAC) address 00:1b:38:83:88:3c would lead to the IID 021b:38ff:fe83:883c.
たとえば、メディアアクセスコントロール（MAC）アドレス00：1b：38：83：88：3cは、IID 021b：38ff：fe83：883cになります。
A number of considerations should be made about these identifiers. Firstly, one 16-bit word (bytes 3-4) of the resulting address always has a fixed value (0xfffe), thus reducing the search space for the IID. Secondly, the high-order three bytes of the IID correspond to the OUI of the network interface card vendor. Since not all possible OUIs have been assigned, this further reduces the IID search space. Furthermore, of the assigned OUIs, many could be regarded as corresponding to legacy devices and thus are unlikely to be used for Internet-connected IPv6-enabled systems, yet further reducing the IID search space. Finally, in some scenarios, it could be possible to infer the OUI in use by the target network devices, yet narrowing down the possible IIDs even more.
これらの識別子については、いくつかの考慮事項があります。 第1に、結果のアドレスの1つの16ビットワード（バイト3〜4）は常に固定値（0xfffe）を持つため、IIDの検索スペースが減少します。 次に、IIDの上位3バイトは、ネットワークインターフェイスカードベンダーのOUIに対応しています。 可能なすべてのOUIが割り当てられているわけではないため、これによりIID検索スペースがさらに削減されます。 さらに、割り当てられたOUIの多くは、レガシーデバイスに対応していると見なすことができるため、インターネット接続されたIPv6対応システムに使用される可能性は低く、さらにIID検索スペースが削減されます。 最後に、一部のシナリオでは、ターゲットネットワークデバイスが使用しているOUIを推測しながら、考えられるIIDをさらに絞り込むことができます。
NOTE:
For example, an organization known for being provisioned by vendor
X is likely to have most of the nodes in its organizational
network with OUIs corresponding to vendor X.
注：たとえば、ベンダーXによってプロビジョニングされていることがわかっている組織では、組織ネットワーク内にほとんどのノードがあり、ベンダーXに対応するOUIがあります。
These considerations mean that in some scenarios, the original IID search space of 64 bits may be effectively reduced to 2^24 or n * 2^24 (where "n" is the number of different OUIs assigned to the target vendor).
これらの考慮事項は、一部のシナリオでは、64ビットの元のIID検索スペースが2 ^ 24またはn * 2 ^ 24（「n」はターゲットベンダーに割り当てられた異なるOUIの数）に効果的に削減される可能性があることを意味します。
Gont & Chown Informational [Page 7] RFC 7707 IPv6 Reconnaissance March 2016 Furthermore, if just one host address is detected or known within a subnet, it is not unlikely that, if systems were ordered in a batch, they may have sequential MAC addresses. Additionally, given a MAC address observed in one subnet, sequential or nearby MAC addresses may be seen in other subnets in the same site.
さらに、サブネット内でホストアドレスが1つだけ検出または認識される場合でも、システムがバッチで注文された場合、MACアドレスが連続している可能性があります。 また、1つのサブネットでMACアドレスが確認された場合、同じサイト内の他のサブネットで順次または近くのMACアドレスが表示されることがあります。
NOTE:
[RFC7136] notes that all bits of an IID should be treated as
"opaque" bits. Furthermore, [DEFAULT-IIDS] is currently in the
process of changing the default IID generation scheme to align
with [RFC7217] (as described below in Section 4.1.1.5), such that
IIDs are semantically opaque and do not follow any patterns.
Therefore, the traditional IIDs based on link-layer addresses are
expected to become less common over time.
注：[RFC7136]は、IIDのすべてのビットは「不透明」ビットとして扱われるべきであると述べています。 さらに、[DEFAULT-IIDS]は現在、デフォルトのIID生成スキームを[RFC7217]に合わせて変更する過程にあり（セクション4.1.1.5で説明）、IIDは意味的に不透明であり、どのパターンにも従いません。 したがって、リンク層アドレスに基づく従来のIIDは、時間の経過とともに一般的でなくなると予想されます。
4.1.1.2. Interface Identifiers of Virtualization Technologies
4.1.1.2。 仮想化テクノロジーのインターフェース識別子
IIDs resulting from virtualization technologies can be considered a specific subcase of IIDs embedding IEEE identifiers (please see Section 4.1.1.1): they employ IEEE identifiers, but part of the IID has specific patterns. The following subsections describe IIDs of some popular virtualization technologies.
仮想化技術から生じるIIDは、IEEE識別子を埋め込むIIDの特定のサブケースと見なすことができます（セクション4.1.1.1を参照）：それらはIEEE識別子を使用しますが、IIDの一部には特定のパターンがあります。 次のサブセクションでは、いくつかの一般的な仮想化テクノロジーのIIDについて説明します。
4.1.1.2.1. VirtualBox
4.1.1.2.1。 VirtualBox
All automatically generated MAC addresses in VirtualBox virtual machines employ the OUI 08:00:27 [VBox2011]. This means that all addresses resulting from traditional SLAAC will have an IID of the form a00:27ff:feXX:XXXX, thus effectively reducing the IID search space from 64 bits to 24 bits.
VirtualBox仮想マシンで自動的に生成されたすべてのMACアドレスは、OUI 08:00:27 [VBox2011]を採用しています。 つまり、従来のSLAACから生じるすべてのアドレスは、a00：27ff：feXX：XXXXという形式のIIDを持つため、IID検索スペースが64ビットから24ビットに効果的に削減されます。
4.1.1.2.2. VMware ESX Server
4.1.1.2.2。 VMware ESXサーバー
The VMware ESX server (versions 1.0 to 2.5) provides yet a more interesting example. Automatically generated MAC addresses have the following pattern [vmesx2011]:
VMware ESXサーバー（バージョン1.0から2.5）は、さらに興味深い例を提供します。 自動生成されたMACアドレスのパターンは次のとおりです[vmesx2011]：
1. The OUI is set to 00:05:69.
1. OUIは00:05:69に設定されています。
2. The next 16 bits of the MAC address are set to the same value as
the last 16 bits of the console operating system's primary IPv4
address.
2. MACアドレスの次の16ビットは、コンソールオペレーティングシステムのプライマリIPv4アドレスの最後の16ビットと同じ値に設定されます。
3. The final 8 bits of the MAC address are set to a hash value based
on the name of the virtual machine's configuration file.
3. MACアドレスの最後の8ビットは、仮想マシンの構成ファイルの名前に基づいてハッシュ値に設定されます。
Gont & Chown Informational [Page 8] RFC 7707 IPv6 Reconnaissance March 2016 This means that, assuming the console operating system's primary IPv4 address is known, the IID search space is reduced from 64 bits to 8 bits.
これは、コンソールオペレーティングシステムのプライマリIPv4アドレスがわかっている場合、IID検索スペースが64ビットから8ビットに削減されることを意味します。
On the other hand, manually configured MAC addresses in the VMware ESX server employ the OUI 00:50:56, with the low-order three bytes of the MAC address being in the range 00:00:00-3F:FF:FF (to avoid conflicts with other VMware products). Therefore, even in the case of manually configured MAC addresses, the IID search space is reduced from 64 bits to 22 bits.
一方、VMware ESXサーバーで手動で構成されたMACアドレスはOUI 00:50:56を使用し、MACアドレスの下位3バイトは00：00：00-3F：FF：FF（ 他のVMware製品との競合を回避するため）。 したがって、手動で構成されたMACアドレスの場合でも、IID検索スペースは64ビットから22ビットに削減されます。
4.1.1.2.3. VMware vSphere
4.1.1.2.3。 VMware vSphere
VMware vSphere [vSphere] supports these default MAC address generation algorithms:
VMware vSphere [vSphere]は、次のデフォルトのMACアドレス生成アルゴリズムをサポートしています。
o Generated addresses
生成されたアドレス
* Assigned by the vCenter server
vCenterサーバーにより割り当て
* Assigned by the ESXi host
ESXiホストによって割り当て
o Manually configured addresses
手動で構成されたアドレス
By default, MAC addresses assigned by the vCenter server use the OUI 00:50:56 and have the format 00:50:56:XX:YY:ZZ, where XX is calculated as (0x80 + vCenter Server ID (in the range 0x00-0x3F)), and XX and YY are random two-digit hexadecimal numbers. Thus, the possible IID range is 00:50:56:80:00:00-00:50:56:BF:FF:FF; therefore, the search space for the resulting SLAAC addresses will be 22 bits.
デフォルトでは、vCenterサーバーによって割り当てられたMACアドレスはOUI 00:50:56を使用し、形式は00：50：56：XX：YY：ZZです。ここで、XXは（0x80 + vCenter Server ID（範囲0x00 -0x3F））、およびXXとYYはランダムな2桁の16進数です。 したがって、可能なIID範囲は00：50：56：80：00：00-00：50：56：BF：FF：FFです。 したがって、結果のSLAACアドレスの検索スペースは22ビットになります。
MAC addresses generated by the ESXi host use the OUI 00:0C:29 and have the format 00:0C:29:XX:YY:ZZ, where XX, YY, and ZZ are the last three octets in hexadecimal format of the virtual machine Universally Unique Identifier (UUID) (based on a hash calculated with the UUID of the ESXi physical machine and the path to a configuration file). Thus, the MAC addresses will be in the range 00:0C:29:00:00:00-00:0C:29:FF:FF:FF; therefore, the search space for the resulting SLAAC addresses will be 24 bits.
ESXiホストによって生成されたMACアドレスはOUI 00：0C：29を使用し、形式は00：0C：29：XX：YY：ZZです。ここで、XX、YY、およびZZは仮想マシンの16進形式の最後の3つのオクテットです。 Universally Unique Identifier（UUID）（ESXi物理マシンのUUIDと構成ファイルへのパスで計算されたハッシュに基づく）。 したがって、MACアドレスは00：0C：29：00：00：00-00：0C：29：FF：FF：FFの範囲になります。 したがって、結果のSLAACアドレスの検索スペースは24ビットになります。
Finally, manually configured MAC addresses employ the OUI 00:50:56, with the low-order three bytes being in the range 00:00:00-3F:FF:FF (to avoid conflicts with other VMware products). Therefore, the resulting MAC addresses will be in the range 00:50:56:00:00:00-00:50:56:3F:FF:FF, and the search space for the corresponding SLAAC addresses will be 22 bits.
最後に、手動で構成されたMACアドレスはOUI 00:50:56を使用し、下位3バイトは00：00：00-3F：FF：FFの範囲にあります（他のVMware製品との競合を避けるため）。 したがって、結果のMACアドレスは00：50：56：00：00：00-00：50：56：3F：FF：FFの範囲になり、対応するSLAACアドレスのサーチスペースは22ビットになります。
Gont & Chown Informational [Page 9] RFC 7707 IPv6 Reconnaissance March 2016 4.1.1.3. Temporary Addresses
4.1.1.3。 一時アドレス
Privacy concerns [Gont-DEEPSEC2011] [RFC7721] regarding IIDs embedding IEEE identifiers led to the introduction of "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" [RFC4941], also known as "temporary addresses" or "privacy addresses". Essentially, "temporary addresses" produce random addresses by concatenating a random identifier to the autoconfiguration IPv6 prefix advertised in a Router Advertisement message.
IEEE識別子を埋め込むIIDに関するプライバシーの懸念[Gont-DEEPSEC2011] [RFC7721]により、「IPv6のステートレスアドレス自動構成のプライバシー拡張」[RFC4941]が導入されました。これは、「一時アドレス」または「プライバシーアドレス」とも呼ばれます。 基本的に、「一時アドレス」は、ルーターアドバタイズメッセージでアドバタイズされる自動構成IPv6プレフィックスにランダムな識別子を連結することにより、ランダムアドレスを生成します。
NOTE:
In addition to their unpredictability, these addresses are
typically short-lived, such that even if an attacker were to learn
of one of these addresses, they would be of use for a limited
period of time. A typical implementation may keep a temporary
address preferred for 24 hours, and configured but deprecated for
seven days.
注：これらのアドレスは予測不可能であることに加えて、通常、存続期間が短いため、攻撃者がこれらのアドレスの1つを知ったとしても、限られた期間のみ使用されます。 一般的な実装では、一時アドレスを24時間優先して保持し、7日間は構成するが非推奨にすることができます。
It is important to note that "temporary addresses" are generated in addition to the stable addresses [RFC7721] (such as the traditional SLAAC addresses based on IEEE identifiers): stable SLAAC addresses are meant to be employed for "server-like" inbound communications, while "temporary addresses" are meant to be employed for "client- like" outbound communications. This means that implementation/use of "temporary addresses" does not prevent an attacker from leveraging the predictability of stable SLAAC addresses, since "temporary addresses" are generated in addition to (rather than as a replacement of) the stable SLAAC addresses (such as those derived from IEEE identifiers).
「一時アドレス」は、安定したアドレス[RFC7721]（IEEE識別子に基づく従来のSLAACアドレスなど）に加えて生成されることに注意することが重要です。安定したSLAACアドレスは、「サーバーのような」インバウンド通信に使用されることを意図しています 一方、「一時アドレス」は「クライアントのような」アウトバウンド通信に使用されることを意図しています。 これは、「一時アドレス」が安定したSLAACアドレス（の代わりではなく）に加えて生成されるため、「一時アドレス」の実装/使用は、攻撃者が安定したSLAACアドレスの予測可能性を活用することを妨げないことを意味します（ IEEE識別子から派生したもの）。
The benefit that temporary addresses offer in this context is that they reduce the exposure of the host addresses to any third parties that may observe traffic sent from a host where temporary addresses are enabled and used by default. But, in the absence of firewall protection for the host, its stable SLAAC address remains liable to be scanned from off-site.
このコンテキストで一時アドレスが提供する利点は、一時アドレスがデフォルトで有効にされて使用されているホストから送信されたトラフィックを監視する可能性のある第三者へのホストアドレスの露出を減らすことです。 ただし、ホストにファイアウォール保護がない場合、その安定したSLAACアドレスはオフサイトからスキャンされる可能性が高くなります。
4.1.1.4. Constant, Semantically Opaque IIDs
4.1.1.4。 一定で、意味的に不透明なIID
In order to mitigate the security implications arising from the predictable IPv6 addresses derived from IEEE identifiers, Microsoft Windows produced an alternative scheme for generating "stable addresses" (in replacement of the ones embedding IEEE identifiers). The aforementioned scheme is believed to be an implementation of RFC 4941 [RFC4941], but without regenerating the addresses over time. The resulting IIDs are constant across system bootstraps, and also constant across networks.
IEEE識別子から派生した予測可能なIPv6アドレスから生じるセキュリティへの影響を軽減するために、Microsoft Windowsは「IEEE識別子を埋め込んだアドレスの代わりに」「安定したアドレス」を生成するための代替スキームを作成しました。 前述のスキームは、RFC 4941 [RFC4941]の実装であると考えられていますが、時間の経過とともにアドレスを再生成しません。 結果のIIDは、システムブートストラップ全体で一定であり、ネットワーク全体でも一定です。
Gont & Chown Informational [Page 10] RFC 7707 IPv6 Reconnaissance March 2016 Assuming no flaws in the aforementioned algorithm, this scheme would remove any patterns from the SLAAC addresses.
前述のアルゴリズムに欠陥がないと仮定すると、このスキームはSLAACアドレスからパターンを削除します。
NOTE:
However, since the resulting IIDs are constant across networks,
these addresses may still be leveraged for host-tracking purposes
[RFC7217] [RFC7721].
注：ただし、結果として得られるIIDはネットワーク全体で一定であるため、これらのアドレスはホスト追跡の目的で利用される可能性があります[RFC7217] [RFC7721]。
The benefit of this scheme is thus that the host may be less readily detected by applying heuristics to an address-scanning attack, but, in the absence of concurrent use of temporary addresses, the host is liable to be tracked across visited networks.
したがって、この方式の利点は、アドレススキャン攻撃にヒューリスティックを適用することでホストを簡単に検出できない可能性があることです。ただし、一時アドレスを同時に使用しない場合、ホストは訪問したネットワーク全体で追跡される傾向があります。
4.1.1.5. Stable, Semantically Opaque IIDs
4.1.1.5。 安定した、意味的に不透明なIID
In response to the predictability issues discussed in Section 4.1.1.1 and the privacy issues discussed in [RFC7721], the IETF has standardized (in [RFC7217]) a method for generating IPv6 IIDs to be used with IPv6 SLAAC, such that addresses configured using this method are stable within each subnet, but the IIDs change when hosts move from one subnet to another. The aforementioned method is meant to be an alternative to generating IIDs based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users.
セクション4.1.1.1で説明されている予測可能性の問題と[RFC7721]で説明されているプライバシーの問題に対応して、IETFは（[RFC7217]で）IPv6 SLAACで使用されるIPv6 IIDを生成する方法を標準化しました。 この方法は各サブネット内で安定していますが、ホストがあるサブネットから別のサブネットに移動するとIIDが変わります。 前述の方法は、IEEE識別子に基づいてIIDを生成する代替手段であり、ユーザーのプライバシーを犠牲にすることなく、安定したアドレスの利点を実現できます。
Implementation of this method (in replacement of IIDs based on IEEE identifiers) eliminates any patterns from the IID, thus benefiting user privacy and reducing the ease with which addresses can be scanned.
この方法を実装すると（IEEE識別子に基づくIIDの代わり）、IIDからパターンが削除されるため、ユーザーのプライバシーが保護され、アドレスのスキャンが容易になります。
4.1.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
4.1.2。 IPv6の動的ホスト構成プロトコル（DHCPv6）
DHCPv6 can be employed as a stateful address configuration mechanism, in which a server (the DHCPv6 server) leases IPv6 addresses to IPv6 hosts. As with the IPv4 counterpart, addresses are assigned according to a configuration-defined address range and policy, with some DHCPv6 servers assigning addresses sequentially, from a specific range. In such cases, addresses tend to be predictable.
DHCPv6は、サーバー（DHCPv6サーバー）がIPv6アドレスをIPv6ホストにリースするステートフルアドレス構成メカニズムとして使用できます。 IPv4と同様に、アドレスは構成で定義されたアドレス範囲とポリシーに従って割り当てられ、一部のDHCPv6サーバーは特定の範囲から順次アドレスを割り当てます。 このような場合、アドレスは予測可能になる傾向があります。
NOTE:
For example, if the prefix 2001:db8::/64 is used for assigning
addresses on the local network, the DHCPv6 server might
(sequentially) assign addresses from the range 2001:db8::1 -
2001:db8::100.
注：たとえば、ローカルネットワーク上のアドレスの割り当てにプレフィックス2001：db8 :: / 64が使用されている場合、DHCPv6サーバーは（順次）2001：db8 :: 1-2001：db8 :: 100の範囲からアドレスを割り当てる可能性があります。 。
In most common scenarios, this means that the IID search space will be reduced from the original 64 bits to 8 or 16 bits. [RFC5157] recommended that DHCPv6 instead issue addresses randomly from a large Gont & Chown Informational [Page 11] RFC 7707 IPv6 Reconnaissance March 2016 pool; that advice is repeated here. [IIDS-DHCPv6] specifies an algorithm that can be employed by DHCPv6 servers to produce stable addresses that do not follow any specific pattern, thus resulting in an IID search space of 64 bits.
これは、最も一般的なシナリオでは、IID検索スペースが元の64ビットから8または16ビットに削減されることを意味します。 [RFC5157] DHCPv6が代わりに大きなプールからランダムにアドレスを発行することを推奨しました。 そのアドバイスはここで繰り返されます。 [IIDS-DHCPv6]は、特定のパターンに従わない安定したアドレスを生成するためにDHCPv6サーバーが使用できるアルゴリズムを指定します。これにより、64ビットのIID検索スペースが生成されます。
4.1.3. Manually Configured Addresses
4.1.3。 手動で構成されたアドレス
In some scenarios, node addresses may be manually configured. This is typically the case for IPv6 addresses assigned to routers (since routers do not employ automatic address configuration) but also for servers (since having a stable address that does not depend on the underlying link-layer address is generally desirable).
一部のシナリオでは、ノードアドレスを手動で構成できます。 これは通常、ルーターに割り当てられたIPv6アドレスの場合（ルーターは自動アドレス構成を採用していないため）だけでなく、サーバー（基本的なリンク層アドレスに依存しない安定したアドレスを持つことが一般的に望ましいため）にも当てはまります。
While network administrators are mostly free to select the IID from any value in the range 1 - 2^64, for the sake of simplicity (i.e., ease of remembering), they tend to select addresses with one of the following patterns:
ネットワーク管理者はほとんどの場合、1から2 ^ 64の範囲の任意の値からIIDを自由に選択できますが、簡単にするため（つまり、覚えやすくするため）、次のパターンのいずれかでアドレスを選択する傾向があります。
o low-byte addresses: in which most of the bytes of the IID are set
to 0 (except for the least significant byte)
低バイトアドレス：IIDのほとんどのバイトが0に設定されています（最下位バイトを除く）
o IPv4-based addresses: in which the IID embeds the IPv4 address of
the network interface (as in 2001:db8::192.0.2.1)
IPv4ベースのアドレス：IIDがネットワークインターフェイスのIPv4アドレスを埋め込んでいる（2001：db8 :: 192.0.2.1のように）
o service port addresses: in which the IID embeds the TCP/UDP
service port of the main service running on that node (as in
2001:db8::80 or 2001:db8::25)
サービスポートアドレス：IIDは、そのノードで実行されているメインサービスのTCP / UDPサービスポートを埋め込みます（2001：db8 :: 80または2001：db8 :: 25など）。
o wordy addresses: which encode words (as in 2001:db8::bad:cafe)
単語の多いアドレス：単語をエンコードします（2001：db8 :: bad：cafeなど）。
Each of these patterns is discussed in detail in the following subsections.
これらの各パターンについては、次のサブセクションで詳しく説明します。
4.1.3.1. Low-Byte Addresses
4.1.3.1。 低バイトアドレス
The most common form of low-byte addresses is that in which all the bytes of the IID (except the least significant bytes) are set to zero (as in 2001:db8::1, 2001:db8::2, etc.). However, it is also common to find similar addresses in which the two lowest-order 16-bit words (from the right to left) are set to small numbers (as in 2001::db8::1:10, 2001:db8::2:10, etc.). Yet it is not uncommon to find IPv6 addresses in which the second lowest-order 16-bit word (from right to left) is set to a small value in the range 0x0000:0x00ff, while the lowest-order 16-bit word (from right to left) varies in the range 0x0000:0xffff. It should be noted that all of these address patterns are generally referred to as "low-byte Gont & Chown Informational [Page 12] RFC 7707 IPv6 Reconnaissance March 2016 addresses", even when, strictly speaking, it is not only the lowest- order byte of the IPv6 address that varies from one address to another.
ローバイトアドレスの最も一般的な形式は、IIDのすべてのバイト（最下位バイトを除く）がゼロに設定されている形式です（2001：db8 :: 1、2001：db8 :: 2など）。 。 ただし、（2001 :: db8 :: 1：10、2001：db8：のように）2つの最下位16ビットワード（右から左）が小さい数字に設定されている同様のアドレスを見つけることも一般的です。 ：2：10など）。 しかし、IPv6アドレスを見つけることは珍しいことではありません。右から左へ2番目に低い16ビットワードが0x0000：0x00ffの範囲の小さい値に設定されている一方で、最も低い16ビットワード（から 右から左へ）0x0000：0xffffの範囲で変化します。 厳密に言えば、アドレスごとに異なるのはIPv6アドレスの最下位バイトだけではない場合でも、これらすべてのアドレスパターンは一般に「ローバイトアドレス」と呼ばれます。
In the worst-case scenario, the search space for this pattern is 2^24 (although most systems can be found by searching 2^16 or even 2^8 addresses).
最悪のシナリオでは、このパターンの検索スペースは2 ^ 24です（ただし、ほとんどのシステムは2 ^ 16または2 ^ 8のアドレスを検索することで見つけることができます）。
4.1.3.2. IPv4-Based Addresses
4.1.3.2。 IPv4ベースのアドレス
The most common form of these addresses is that in which an IPv4 address is encoded in the lowest-order 32 bits of the IPv6 address (usually as a result of the address notation of the form 2001:db8::192.0.2.1). However, it is also common for administrators to encode each of the bytes of the IPv4 address in each of the 16-bit words of the IID (as in, e.g., 2001:db8::192:0:2:1).
これらのアドレスの最も一般的な形式は、IPv4アドレスがIPv6アドレスの最下位32ビットでエンコードされる形式です（通常、2001：db8 :: 192.0.2.1形式のアドレス表記の結果として）。 ただし、管理者がIIDの各16ビットワードでIPv4アドレスの各バイトをエンコードすることも一般的です（例：2001：db8 :: 192：0：2：1）。
Therefore, the search space for addresses following this pattern is that of the corresponding IPv4 prefix (or twice the size of that search space if both forms of "IPv4-based addresses" are to be searched).
したがって、このパターンに従うアドレスの検索スペースは、対応するIPv4プレフィックスの検索スペースです（両方の形式の「IPv4ベースのアドレス」を検索する場合は、その検索スペースのサイズの2倍）。
4.1.3.3. Service-Port Addresses
4.1.3.3。 サービスポートアドレス
Addresses following this pattern include the service port (e.g., 80 for HTTP) in the lowest-order byte of the IID and have the rest of the bytes of the IID set to zero. There are a number of variants for this address pattern:
このパターンに従うアドレスには、IIDの最下位バイトにサービスポート（HTTPの場合は80など）が含まれ、IIDの残りのバイトはゼロに設定されています。 このアドレスパターンにはいくつかのバリエーションがあります。
o The lowest-order 16-bit word (from right to left) may contain the
service port, and the second lowest-order 16-bit word (from right
to left) may be set to a number in the range 0x0000-0x00ff (as in,
e.g., 2001:db8::1:80).
最下位16ビットワード（右から左へ）にサービスポートを含めることができ、2番目に最下位16ビットワード（右から左へ）を0x0000〜0x00ff（範囲として たとえば、2001：db8 :: 1：80）。
o The lowest-order 16-bit word (from right to left) may be set to a
value in the range 0x0000-0x00ff, while the second lowest-order
16-bit word (from right to left) may contain the service port (as
in, e.g., 2001:db8::80:1).
最下位の16ビットワード（右から左へ）は0x0000-0x00ffの範囲の値に設定できますが、2番目の最下位16ビットワード（右から左へ）にはサービスポート（ たとえば、2001：db8 :: 80：1）。
o The service port itself might be encoded in decimal or in
hexadecimal notation (e.g., an address embedding the HTTP port
might be 2001:db8::80 or 2001:db8::50) -- with addresses encoding
the service port as a decimal number being more common.
サービスポート自体は、10進数または16進数表記でエンコードされる場合があります（たとえば、HTTPポートを埋め込むアドレスは、2001：db8 :: 80または2001：db8 :: 50になる場合があります）-サービスポートを10進数としてエンコードするアドレス より一般的です。
Considering a maximum of 20 popular service ports, the search space for addresses following this pattern is, in the worst-case scenario, 10 * 2^11.
最大20の人気のあるサービスポートを考慮すると、このパターンに従うアドレスの検索スペースは、最悪の場合、10 * 2 ^ 11です。
Gont & Chown Informational [Page 13] RFC 7707 IPv6 Reconnaissance March 2016 4.1.3.4. Wordy Addresses
4.1.3.4。 Wordy Addresses
Since the IPv6 address notation allows for a number of hexadecimal digits, it is not difficult to encode words into IPv6 addresses (as in, e.g., 2001:db8::bad:cafe).
IPv6アドレス表記では16進数を使用できるため、単語をIPv6アドレスにエンコードすることは難しくありません（例：2001：db8 :: bad：cafe）。
Addresses following this pattern are likely to be explored by means of "dictionary attacks"; therefore, computing the corresponding search space is not straightforward.
このパターンに従うアドレスは、「辞書攻撃」によって探索される可能性があります。 したがって、対応する検索スペースの計算は簡単ではありません。
4.1.4. IPv6 Addresses Corresponding to Transition/Coexistence
Technologies
4.1.4。 移行/共存テクノロジに対応するIPv6アドレス
Some transition/coexistence technologies might be leveraged to reduce the target search space of remote address-scanning attacks, since they specify how the corresponding IPv6 address must be generated. For example, in the case of Teredo [RFC4380], the 64-bit IID is generated from the IPv4 address observed at a Teredo server along with a UDP port number.
一部の移行/共存テクノロジは、対応するIPv6アドレスの生成方法を指定するため、リモートアドレススキャン攻撃のターゲット検索スペースを削減するために利用される場合があります。 たとえば、Teredo [RFC4380]の場合、64ビットIIDは、Teredoサーバーで監視されているIPv4アドレスとUDPポート番号から生成されます。
For obvious reasons, the search space for these addresses will depend on the specific transition/coexistence technology being employed.
明らかな理由により、これらのアドレスの検索スペースは、使用されている特定の遷移/共存テクノロジによって異なります。
4.1.5. IPv6 Address Assignment in Real-World Network Scenarios
4.1.5。 実際のネットワークシナリオでのIPv6アドレスの割り当て
Figures 1, 2, and 3 provide a summary of the results obtained by [Gont-LACSEC2013] when measuring the address patterns employed by web servers, name servers, and mail servers, respectively. Figure 4 provides a rough summary of the results obtained by [Malone2008] for IPv6 routers. Figure 5 provides a summary of the results obtained by [Ford2013] for clients.
図1、2、および3は、Webサーバー、ネームサーバー、およびメールサーバーでそれぞれ採用されているアドレスパターンを測定したときに[Gont-LACSEC2013]によって得られた結果の概要を示しています。 図4は、IPv6ルーターに対して[Malone2008]によって得られた結果の大まかな要約を示しています。 図5は、[Ford2013]によって得られたクライアントの結果の概要を示しています。
Gont & Chown Informational [Page 14]
RFC 7707 IPv6 Reconnaissance March 2016
+---------------+------------+
| Address type | Percentage |
+---------------+------------+
| IEEE-based | 1.44% |
+---------------+------------+
| Embedded-IPv4 | 25.41% |
+---------------+------------+
| Embedded-Port | 3.06% |
+---------------+------------+
| ISATAP | 0.00% |
+---------------+------------+
| Low-byte | 56.88% |
+---------------+------------+
| Byte-pattern | 6.97% |
+---------------+------------+
| Randomized | 6.24% |
+---------------+------------+
Figure 1: Measured Web Server Addresses
図1：測定されたWebサーバーアドレス
+---------------+------------+
| Address type | Percentage |
+---------------+------------+
| IEEE-based | 0.67% |
+---------------+------------+
| Embedded-IPv4 | 22.11% |
+---------------+------------+
| Embedded-Port | 6.48% |
+---------------+------------+
| ISATAP | 0.00% |
+---------------+------------+
| Low-byte | 56.58% |
+---------------+------------+
| Byte-pattern | 11.07% |
+---------------+------------+
| Randomized | 3.09% |
+---------------+------------+
Figure 2: Measured Name Server Addresses
図2：測定されたネームサーバーアドレス
Gont & Chown Informational [Page 15]
RFC 7707 IPv6 Reconnaissance March 2016
+---------------+------------+
| Address type | Percentage |
+---------------+------------+
| IEEE-based | 0.48% |
+---------------+------------+
| Embedded-IPv4 | 4.02% |
+---------------+------------+
| Embedded-Port | 1.07% |
+---------------+------------+
| ISATAP | 0.00% |
+---------------+------------+
| Low-byte | 92.65% |
+---------------+------------+
| Byte-pattern | 1.20% |
+---------------+------------+
| Randomized | 0.59% |
+---------------+------------+
Figure 3: Measured Mail Server Addresses
図3：測定されたメールサーバーアドレス
+--------------+------------+
| Address type | Percentage |
+--------------+------------+
| Low-byte | 70.00% |
+--------------+------------+
| IPv4-based | 5.00% |
+--------------+------------+
| SLAAC | 1.00% |
+--------------+------------+
| Wordy | <1.00% |
+--------------+------------+
| Randomized | <1.00% |
+--------------+------------+
| Teredo | <1.00% |
+--------------+------------+
| Other | <1.00% |
+--------------+------------+
Figure 4: Measured Router Addresses
図4：測定されたルーターアドレス
Gont & Chown Informational [Page 16]
RFC 7707 IPv6 Reconnaissance March 2016
+---------------+------------+
| Address type | Percentage |
+---------------+------------+
| IEEE-based | 7.72% |
+---------------+------------+
| Embedded-IPv4 | 14.31% |
+---------------+------------+
| Embedded-Port | 0.21% |
+---------------+------------+
| ISATAP | 1.06% |
+---------------+------------+
| Randomized | 69.73% |
+---------------+------------+
| Low-byte | 6.23% |
+---------------+------------+
| Byte-pattern | 0.74% |
+---------------+------------+
Figure 5: Measured Client Addresses
図5：測定されたクライアントアドレス
NOTE:
"ISATAP" stands for "Intra-Site Automatic Tunnel Addressing
Protocol" [RFC5214].
注：「ISATAP」は「Intra-Site Automatic Tunnel Addressing Protocol」[RFC5214]の略です。
It should be clear from these measurements that a very high percentage of host and router addresses follow very specific patterns.
これらの測定から、非常に高い割合のホストとルーターのアドレスが非常に特定のパターンに従うことが明らかになります。
Figure 5 shows that while around 70% of clients observed in this measurement appear to be using temporary addresses, a significant number of clients still expose IEEE-based addresses and addresses using embedded IPv4 (thus also revealing IPv4 addresses). Besides, as noted in Section 4.1.1.3, temporary addresses are employed along with stable IPv6 addresses; thus, hosts employing a temporary address may still be the subject of address-scanning attacks that target their stable address(es).
図5は、この測定で観察されたクライアントの約70％が一時アドレスを使用しているように見えますが、かなりの数のクライアントが、IEEEベースのアドレスと埋め込みIPv4を使用するアドレスを公開していることを示しています（したがって、IPv4アドレスも明らかになります）。 さらに、セクション4.1.1.3で述べたように、一時アドレスは安定したIPv6アドレスとともに使用されます。 したがって、一時アドレスを使用するホストは、安定したアドレスをターゲットとするアドレススキャン攻撃の対象になる可能性があります。
[ADDR-ANALYSIS] contains a spatial and temporal analysis of IPv6 addresses corresponding to clients and routers.
[ADDR-ANALYSIS]には、クライアントとルーターに対応するIPv6アドレスの時空間分析が含まれています。
4.2. IPv6 Address Scanning of Remote Networks
4.2。 リモートネットワークのIPv6アドレススキャン
Although attackers have been able to get away with "brute-force" address-scanning attacks in IPv4 networks (thanks to the lesser search space), successfully performing a brute-force address-scanning attack of an entire /64 network would be infeasible. As a result, it is expected that attackers will leverage the IPv6 address patterns discussed in Section 4.1 to reduce the IPv6 address search space.
攻撃者はIPv4ネットワークでの「ブルートフォース」アドレススキャン攻撃を回避できましたが（検索スペースが少ないため）、/ 64ネットワーク全体のブルートフォースアドレススキャン攻撃を成功させることは不可能です。 その結果、攻撃者はセクション4.1で説明したIPv6アドレスパターンを利用してIPv6アドレス検索スペースを削減することが予想されます。
Gont & Chown Informational [Page 17] RFC 7707 IPv6 Reconnaissance March 2016 IPv6 address scanning of remote networks should consider an additional factor not present for the IPv4 case: since the typical IPv6 subnet is a /64, scanning an entire /64 could, in theory, lead to the creation of 2^64 entries in the Neighbor Cache of the last-hop router. Unfortunately, a number of IPv6 implementations have been found to be unable to properly handle a large number of entries in the Neighbor Cache; hence, these address-scanning attacks may have the side effect of resulting in a Denial-of-Service (DoS) attack [CPNI-IPv6] [RFC6583].
リモートネットワークのIPv6アドレススキャンでは、IPv4の場合には存在しない追加の要素を考慮する必要があります。通常のIPv6サブネットは/ 64であるため、/ 64全体をスキャンすると、理論的にはネイバーに2 ^ 64エントリが作成される可能性があります ラストホップルーターのキャッシュ。 残念ながら、多くのIPv6実装では、ネイバーキャッシュ内の多数のエントリを適切に処理できないことが判明しています。 したがって、これらのアドレススキャン攻撃には、サービス拒否（DoS）攻撃[CPNI-IPv6] [RFC6583]を引き起こすという副作用がある可能性があります。
[RFC7421] discusses the "default" /64 boundary for host subnets and the assumptions surrounding it. While there are reports of sites implementing IPv6 subnets of size /112 or smaller to reduce concerns about the above attack, such smaller subnets are likely to make address-scanning attacks more feasible, in addition to encountering the issues with non-/64 host subnets discussed in [RFC7421].
[RFC7421]は、ホストサブネットの「デフォルト」/ 64境界とそれを取り巻く想定について説明しています。 上記の攻撃に関する懸念を軽減するために、サイズが/ 112以下のIPv6サブネットを実装しているサイトの報告がありますが、このような小さなサブネットは、/ 64以外のホストサブネットの問題に加えて、アドレススキャン攻撃をより実行可能にする可能性があります。 [RFC7421]で議論されています。
4.2.1. Reducing the Subnet ID Search Space
4.2.1。 サブネットID検索スペースの削減
When address scanning a remote network, consideration is required to select which subnet IDs to choose. A typical site might have a /48 allocation, which would mean up to 65,000 or so IPv6 /64 subnets to be scanned.
リモートネットワークをアドレススキャンする場合、選択するサブネットIDを選択するための考慮が必要です。 典型的なサイトには/ 48の割り当てがあり、これは最大65,000程度のIPv6 / 64サブネットがスキャンされることを意味します。
However, in the same way the search space for the IID can be reduced, we may also be able to reduce the subnet ID search space in a number of ways, by guessing likely address plan schemes or using any complementary clues that might exist from other sources or observations. For example, there are a number of documents available online (e.g., [RFC5375]) that provide recommendations for the allocation of address space, which address various operational considerations, including Regional Internet Registry (RIR) assignment policy, ability to delegate reverse DNS zones to different servers, ability to aggregate routes efficiently, address space preservation, ability to delegate address assignment within the organization, ability to add/allocate new sites/prefixes to existing entities without updating Access Control Lists (ACLs), and ability to de-aggregate and advertise subspaces via various Autonomous System (AS) interfaces.
ただし、IIDの検索スペースを削減できるのと同じように、可能性のあるアドレス計画スキームを推測したり、他の方法から存在する可能性のある補足的な手掛かりを使用したりすることにより、さまざまな方法でサブネットIDの検索スペースを削減できる可能性があります。 ソースまたは観測。 たとえば、オンラインで利用できるドキュメント（[RFC5375]など）には、アドレス空間の割り当てに関する推奨事項が記載されており、Regional Internet Registry（RIR）割り当てポリシー、リバースDNSゾーンを委任する機能など、さまざまな運用上の考慮事項に対応しています。 さまざまなサーバーへ、ルートを効率的に集約する機能、アドレス空間の維持、組織内のアドレス割り当てを委任する機能、アクセス制御リスト（ACL）を更新せずに既存のエンティティに新しいサイト/プレフィックスを追加/割り当てる機能、および集約解除する機能 さまざまな自律システム（AS）インターフェイスを介してサブスペースをアドバタイズします。
Address plans might include use of subnets that:
アドレス計画には、次のようなサブネットの使用が含まれる場合があります。
o Run from low ID upwards, e.g., 2001:db8:0::/64, 2001:db8:1::/64,
etc.
2001：db8：0 :: / 64、2001：db8：1 :: / 64など、低いIDから上に実行します。
o Use building numbers, in hexadecimal or decimal form.
16進数または10進数形式の建物番号を使用します。
o Use Virtual Local Area Network (VLAN) numbers.
仮想ローカルエリアネットワーク（VLAN）番号を使用します。
Gont & Chown Informational [Page 18]
RFC 7707 IPv6 Reconnaissance March 2016
o Use an IPv4 subnet number in a dual-stack target, e.g., a site
with a /16 for IPv4 might use /24 subnets, and the IPv6 address
plan may reuse the third byte of the IPv4 address as the IPv6
subnet ID.
デュアルスタックターゲットでIPv4サブネット番号を使用します。たとえば、IPv4に/ 16を使用するサイトは/ 24のサブネットを使用し、IPv6アドレスプランはIPv4アドレスの3番目のバイトをIPv6サブネットIDとして再利用します。
o Use the service "color", as defined for service-based prefix
coloring, or semantic prefixes. For example, a site using a
specific coloring for a specific service such as Voice over IP
(VoIP) may reduce the subnet ID search space for those devices.
サービスベースの接頭辞の色付け、またはセマンティック接頭辞に定義されているサービス「色」を使用します。 たとえば、Voice over IP（VoIP）などの特定のサービスに特定の色を使用しているサイトでは、これらのデバイスのサブネットID検索スペースが減少する場合があります。
The net effect is that the address space of an organization may be highly structured, and allocations of individual elements within this structure may be predictable once other elements are known.
正味の効果は、組織のアドレス空間が高度に構造化される可能性があり、この構造内の個々の要素の割り当ては、他の要素が判明すると予測可能になる可能性があることです。
In general, any subnet ID address plan may convey information, or be based on known information, which may in turn be of advantage to an attacker.
一般に、サブネットIDアドレス計画は情報を伝えるか、既知の情報に基づいている可能性があり、これは攻撃者にとって有利になる可能性があります。
4.3. IPv6 Address Scanning of Local Networks
4.3。 ローカルネットワークのIPv6アドレススキャン
IPv6 address scanning in Local Area Networks (LANs) could be considered, to some extent, a completely different problem than that of scanning a remote IPv6 network. The main difference is that use of link-local multicast addresses can relieve the attacker of searching for unicast addresses in a large IPv6 address space.
ローカルエリアネットワーク（LAN）でのIPv6アドレススキャンは、リモートIPv6ネットワークのスキャンとは完全に異なる問題と考えることができます。 主な違いは、リンクローカルマルチキャストアドレスを使用すると、攻撃者が大きなIPv6アドレス空間でユニキャストアドレスを検索する必要がなくなることです。
NOTE:
While a number of other network reconnaissance vectors (such as
network snooping, leveraging Neighbor Discovery traffic, etc.) are
available when scanning a local network, this section focuses only
on address-scanning attacks (a la "ping sweep").
注：他の多くのネットワーク偵察ベクトル（ネットワークスヌーピング、近隣探索トラフィックの活用など） ローカルネットワークをスキャンするときに利用できます。このセクションでは、アドレススキャン攻撃（「pingスイープ」）のみに焦点を当てています。
An attacker can simply send probe packets to the all-nodes link-local multicast address (ff02::1), such that responses are elicited from all local nodes.
攻撃者は、全ノードのリンクローカルマルチキャストアドレス（ff02 :: 1）にプローブパケットを送信するだけで、すべてのローカルノードから応答が引き出される可能性があります。
Since Windows systems (Vista, 7, etc.) do not respond to ICMPv6 Echo Request messages sent to multicast addresses, IPv6 address-scanning tools typically employ a number of additional probe packets to elicit responses from all the local nodes. For example, unrecognized IPv6 options of type 10xxxxxx elicit Internet Control Message Protocol version 6 (ICMPv6) Parameter Problem, code 2, error messages.
Windowsシステム（Vista、7など）以降 マルチキャストアドレスに送信されたICMPv6エコー要求メッセージに応答しない場合、IPv6アドレススキャンツールは通常、いくつかの追加のプローブパケットを使用して、すべてのローカルノードからの応答を引き出します。 たとえば、タイプ10xxxxxxの認識されないIPv6オプションは、インターネット制御メッセージプロトコルバージョン6（ICMPv6）パラメータの問題、コード2、エラーメッセージを引き出します。
Many address-scanning tools discover only IPv6 link-local addresses (rather than, e.g., the global addresses of the target systems): since the probe packets are typically sent with the attacker's IPv6 link-local address, the "victim" nodes send the response packets using the IPv6 link-local address of the corresponding network Gont & Chown Informational [Page 19] RFC 7707 IPv6 Reconnaissance March 2016 interface (as specified by the IPv6 address-selection rules [RFC6724]). However, sending multiple probe packets, with each packet employing source addresses from different prefixes, typically helps to overcome this limitation.
多くのアドレススキャンツールは、IPv6リンクローカルアドレスのみを検出します（たとえば、ターゲットシステムのグローバルアドレスではありません）。通常、プローブパケットは攻撃者のIPv6リンクローカルアドレスで送信されるため、「被害者」ノードは 対応するネットワークインターフェイスのIPv6リンクローカルアドレスを使用した応答パケット（IPv6アドレス選択規則[RFC6724]で指定）。 ただし、複数のプローブパケットを送信し、各パケットで異なるプレフィックスの送信元アドレスを使用すると、通常、この制限を克服するのに役立ちます。
4.4. Existing IPv6 Address-Scanning Tools
4.4。 既存のIPv6アドレススキャンツール
4.4.1. Remote IPv6 Network Address Scanners
4.4.1。 リモートIPv6ネットワークアドレススキャナー
IPv4 address-scanning tools have traditionally carried out their task by probing an entire address range (usually the entire address range comprised by the target subnetwork). One might argue that the reason for which they have been able to get away with such somewhat "rudimentary" techniques is that the scale or challenge of the task is so small in the IPv4 world that a "brute-force" attack is "good enough". However, the scale of the "address-scanning" task is so large in IPv6 that attackers must be very creative to be "good enough". Simply sweeping an entire /64 IPv6 subnet would just not be feasible.
IPv4アドレススキャンツールは、従来、アドレス範囲全体（通常、ターゲットサブネットワークに含まれるアドレス範囲全体）をプローブすることにより、そのタスクを実行してきました。 彼らがそのような「初歩的な」手法を回避できた理由は、タスクの規模または課題がIPv4の世界では非常に小さいため、「ブルートフォース」攻撃が「十分」であると主張する人もいるかもしれません。 」 ただし、IPv6では「アドレススキャン」タスクの規模が非常に大きいため、攻撃者は「十分に優れている」ためには非常に創造的である必要があります。 / 64 IPv6サブネット全体を単純にスイープするだけでは実現不可能です。
Many address-scanning tools do not even support sweeping an IPv6 address range. On the other hand, the alive6 tool from [THC-IPV6] supports sweeping address ranges, thus being able to leverage some patterns found in IPv6 addresses, such as the incremental addresses resulting from some DHCPv6 setups. Finally, the scan6 tool from [IPv6-Toolkit] supports sweeping address ranges and can also leverage all the address patterns described in Section 4.1 of this document.
多くのアドレススキャンツールは、IPv6アドレス範囲のスイープをサポートしていません。 一方、[THC-IPV6]のalive6ツールはアドレス範囲のスイープをサポートしているため、一部のDHCPv6セットアップから生じるインクリメンタルアドレスなど、IPv6アドレスに見られるいくつかのパターンを活用できます。 最後に、[IPv6-Toolkit]のscan6ツールはアドレス範囲のスイープをサポートし、このドキュメントのセクション4.1で説明されているすべてのアドレスパターンを活用することもできます。
Clearly, a limitation of many of the currently available tools for IPv6 address scanning is that they lack an appropriately tuned "heuristics engine" that can help reduce the search space, such that the problem of IPv6 address scanning becomes tractable.
明らかに、現在利用可能なIPv6アドレススキャンツールの多くには、検索スペースの削減に役立つ適切に調整された「ヒューリスティックエンジン」がないため、IPv6アドレススキャンの問題が扱いにくいという制限があります。
It should be noted that IPv6 network monitoring and management tools also need to build and maintain information about the hosts in their network. Such systems can no longer scan internal systems in a reasonable time to build a database of connected systems. Rather, such systems will need more efficient approaches, e.g., by polling network devices for data held about observed IP addresses, MAC addresses, physical ports used, etc. Such an approach can also enhance address accountability, by mapping IPv4 and IPv6 addresses to observed MAC addresses. This of course implies that any access control mechanisms for querying such network devices, e.g., community strings for SNMP, should be set appropriately to avoid an attacker being able to gather address information remotely.
IPv6ネットワークの監視および管理ツールも、ネットワーク内のホストに関する情報を構築および維持する必要があることに注意してください。 そのようなシステムは、接続されたシステムのデータベースを構築するために、妥当な時間内に内部システムをスキャンできなくなりました。 むしろ、そのようなシステムは、たとえば、観測されたIPアドレス、MACアドレス、使用されている物理ポートなどについて保持されているデータについてネットワークデバイスをポーリングするなど、より効率的なアプローチが必要になります。 このようなアプローチでは、IPv4アドレスとIPv6アドレスを監視対象のMACアドレスにマッピングすることで、アドレスアカウンタビリティを強化することもできます。 もちろん、これは、SNMPのコミュニティストリングなどのネットワークデバイスにクエリを実行するためのアクセス制御メカニズムを適切に設定して、攻撃者がリモートでアドレス情報を収集できないようにする必要があることを意味します。
Gont & Chown Informational [Page 20] RFC 7707 IPv6 Reconnaissance March 2016 4.4.2. Local IPv6 Network Address Scanners
4.4.2。 ローカルIPv6ネットワークアドレススキャナー
There are a variety of publicly available local IPv6 network address- scanners:
一般に入手可能なさまざまなローカルIPv6ネットワークアドレススキャナがあります。
o Current versions of nmap [nmap2015] implement this functionality.
nmap [nmap2015]の現在のバージョンは、この機能を実装しています。
o The Hacker's Choice (THC) IPv6 Attack Toolkit [THC-IPV6] includes
a tool (alive6) that implements this functionality.
Hacker's Choice（THC）IPv6 Attack Toolkit [THC-IPV6]には、この機能を実装するツール（alive6）が含まれています。
o SI6 Network's IPv6 Toolkit [IPv6-Toolkit] includes a tool (scan6)
that implements this functionality.
SI6ネットワークのIPv6ツールキット[IPv6-Toolkit]には、この機能を実装するツール（scan6）が含まれています。
4.5. Mitigations
4.5。 緩和
IPv6 address-scanning attacks can be mitigated in a number of ways. A non-exhaustive list of the possible mitigations includes:
IPv6アドレススキャン攻撃は、さまざまな方法で軽減できます。 可能な緩和策の非網羅的なリストには、次のものが含まれます。
o Employing [RFC7217] (stable, semantically opaque IIDs) in
replacement of addresses based on IEEE identifiers, such that any
address patterns are eliminated.
IEEE識別子に基づくアドレスの置き換えに[RFC7217]（安定した、意味的に不透明なIID）を採用することにより、アドレスパターンが排除されます。
o Employing Intrusion Prevention Systems (IPSs) at the perimeter.
境界に侵入防止システム（IPS）を採用。
o Enforcing IPv6 packet filtering where applicable (see, e.g.,
[RFC4890]).
該当する場合はIPv6パケットフィルタリングを適用する（[RFC4890]などを参照）。
o Employing manually configured MAC addresses if virtual machines
are employed and "resistance" to address-scanning attacks is
deemed desirable, such that even if the virtual machines employ
IEEE-derived IIDs, they are generated from non-predictable MAC
addresses.
仮想マシンが使用されている場合は手動で構成されたMACアドレスを使用し、アドレススキャン攻撃に対する「耐性」が望ましいと見なされます。これにより、仮想マシンがIEEE派生のIIDを使用する場合でも、それらは予測不可能なMACアドレスから生成されます。
o Avoiding use of sequential addresses when using DHCPv6. Ideally,
the DHCPv6 server would allocate random addresses from a large
pool (see, e.g., [IIDS-DHCPv6]).
DHCPv6を使用する場合の連続したアドレスの使用を避けます。 理想的には、DHCPv6サーバーは大きなプールからランダムなアドレスを割り当てます（たとえば、[IIDS-DHCPv6]を参照）。
o Using the "default" /64 size IPv6 subnet prefixes.
「デフォルト」の/ 64サイズのIPv6サブネットプレフィックスを使用します。
o In general, avoiding being predictable in the way addresses are
assigned.
一般に、アドレスが割り当てられる方法を予測できないようにします。
It should be noted that some of the aforementioned mitigations are operational, while others depend on the availability of specific protocol features (such as [RFC7217]) on the corresponding nodes.
前述の緩和策の一部は機能しているが、対応するノードでの特定のプロトコル機能（[RFC7217]など）の可用性に依存している点に注意してください。
Gont & Chown Informational [Page 21] RFC 7707 IPv6 Reconnaissance March 2016 Additionally, while some resistance to address-scanning attacks is generally desirable (particularly when lightweight mitigations are available), there are scenarios in which mitigation of some address- scanning vectors is unlikely to be a high priority (if at all possible). And one should always remember that security by obscurity is not a reasonable defense in itself; it may only be one (relatively small) layer in a broader security environment.
さらに、アドレススキャン攻撃に対するある程度の抵抗が一般的に望ましいですが（特に軽量の緩和策が利用可能な場合）、一部のアドレススキャンベクトルの緩和策が高い優先度ではない可能性があるシナリオがあります（可能な場合）。 また、あいまいさによるセキュリティはそれ自体が妥当な防御ではないことを常に覚えておく必要があります。 より広範なセキュリティ環境では、1つの（比較的小さい）レイヤーにすぎません。
Two of the techniques discussed in this document for local address- scanning attacks are those that employ multicasted ICMPv6 Echo Requests and multicasted IPv6 packets containing unsupported options of type 10xxxxxx. These two vectors could be easily mitigated by configuring nodes to not respond to multicasted ICMPv6 Echo Requests (default on Windows systems) and by updating the IPv6 specifications (and/or possibly configuring local nodes) such that multicasted packets never elicit ICMPv6 error messages (even if they contain unsupported options of type 10xxxxxx).
このドキュメントで説明するローカルアドレススキャン攻撃の2つの手法は、マルチキャストICMPv6エコー要求と、サポートされていないタイプ10xxxxxxのオプションを含むマルチキャストIPv6パケットを使用する手法です。 これらの2つのベクトルは、マルチキャストされたICMPv6エコー要求に応答しないようにノードを構成し（Windowsシステムのデフォルト）、IPv6仕様を更新して（および/またはローカルノードを構成して）、マルチキャストされたパケットがICMPv6エラーメッセージを引き出さないようにすることで簡単に軽減できます（ タイプ10xxxxxxのサポートされていないオプションが含まれている場合）。
NOTE:
[SMURF-AMPLIFIER] proposed such an update to the IPv6
specifications.
注：[SMURF-AMPLIFIER]は、IPv6仕様に対するそのような更新を提案しました。
In any case, when it comes to local networks, there are a variety of network reconnaissance vectors. Therefore, even if address-scanning vectors were mitigated, an attacker could still rely on, e.g., protocols employed for the so-called "service discovery protocols" (see Section 5.2) or eventually rely on network snooping as a last resort for network reconnaissance. There is ongoing work in the IETF on extending mDNS, or at least DNS-based service discovery, to work across a whole site, rather than in just a single subnet, which will have associated security implications.
いずれにせよ、ローカルネットワークに関しては、さまざまなネットワーク調査ベクトルがあります。 したがって、アドレススキャンベクトルが緩和されたとしても、攻撃者は、たとえば、いわゆる「サービスディスカバリプロトコル」（セクション5.2を参照）に使用されるプロトコルに依拠したり、最終的にネットワーク偵察の最後の手段としてネットワークスヌーピングに依拠したりする可能性があります。 。 IEDNSでは、単一のサブネットだけでなく、サイト全体で機能するようにmDNSまたは少なくともDNSベースのサービスディスカバリを拡張する作業が進行中です。これには、関連するセキュリティ上の影響があります。
4.6. Conclusions
4.6 結論
In the previous subsections, we have shown why a /64 host subnet may be more vulnerable to address-based scanning than might intuitively be thought and how an attacker might reduce the target search space when performing an address-scanning attack.
前のサブセクションでは、/ 64ホストサブネットが直感的に考えられるよりもアドレスベースのスキャンに対して脆弱である理由と、攻撃者がアドレススキャン攻撃を実行するときにターゲット検索スペースをどのように削減するかを示しました。
We have described a number of mitigations against address-scanning attacks, including the replacement of traditional SLAAC with stable semantically opaque IIDs (which requires support from system vendors). We have also offered some practical guidance in regard to the principle of avoiding predictability in host addressing schemes. Finally, examples of address-scanning approaches and tools are discussed in the appendices.
従来のSLAACを意味的に不透明な安定したIID（システムベンダーのサポートが必要）に置き換えるなど、アドレススキャン攻撃に対するいくつかの緩和策について説明しました。 また、ホストアドレッシングスキームでの予測可能性を回避するという原則に関して、いくつかの実用的なガイダンスを提供しました。 最後に、アドレススキャンアプローチとツールの例を付録で説明します。
Gont & Chown Informational [Page 22] RFC 7707 IPv6 Reconnaissance March 2016 While most early IPv6-enabled networks remain dual stack, they are more likely to be scanned and attacked over IPv4 transport, and one may argue that the IPv6-specific considerations discussed here are not of an immediate concern. However, an early IPv6 deployment within a dual-stack network may be seen by an attacker as a potentially "easier" target if the implementation of security policies is not as strict for IPv6 (for whatever reason). As IPv6-only networks become more common, the above considerations will be of much greater importance.
初期のIPv6対応ネットワークのほとんどはデュアルスタックのままですが、IPv4トランスポートを介してスキャンおよび攻撃される可能性が高く、ここで説明するIPv6固有の考慮事項は当面の問題ではないと主張する人もいます。 ただし、デュアルスタックネットワーク内での初期のIPv6展開は、セキュリティポリシーの実装がIPv6に対してそれほど厳格でない場合（何らかの理由で）、攻撃者にとって潜在的に「より簡単な」ターゲットと見なされる可能性があります。 IPv6のみのネットワークが一般的になるにつれて、上記の考慮事項は非常に重要になります。
5. Alternative Methods to Glean IPv6 Addresses
5.IPv6アドレスを収集する別の方法
The following subsections describe alternative methods by which an attacker might attempt to glean IPv6 addresses for subsequent probing.
以下のサブセクションでは、攻撃者が後続のプローブのためにIPv6アドレスを収集しようとする可能性のある代替方法について説明します。
5.1. Leveraging the Domain Name System (DNS) for Network Reconnaissance
5.1。 ネットワーク偵察のためのドメインネームシステム（DNS）の活用
5.1.1. DNS Advertised Hosts
5.1.1。 DNSアドバタイズされたホスト
Any systems that are "published" in the DNS, e.g., Mail Exchange (MX) relays or web servers, will remain open to probing from the very fact that their IPv6 addresses are publicly available. It is worth noting that where the addresses used at a site follow specific patterns, publishing just one address may lead to an attack upon the other nodes.
DNSで「公開」されているシステム（Mail Exchange（MX）リレーやWebサーバーなど）は、IPv6アドレスが公に利用可能であるという事実から、調査を受け入れることができます。 サイトで使用されるアドレスが特定のパターンに従っている場合、1つのアドレスだけを公開すると、他のノードへの攻撃につながる可能性があることに注意してください。
Additionally, we note that publication of IPv6 addresses in the DNS should not discourage the elimination of IPv6 address patterns: if any address patterns are eliminated from addresses published in the DNS, an attacker may have to rely on performing dictionary-based DNS lookups in order to find all systems in a target network (which is generally less reliable and more time/traffic consuming than mapping nodes with predictable IPv6 addresses).
さらに、DNSでのIPv6アドレスの公開はIPv6アドレスパターンの排除を妨げるべきではないことに注意してください。アドレスパターンがDNSで公開されたアドレスから排除された場合、攻撃者は辞書ベースのDNSルックアップの実行に頼らなければならない場合があります。 ターゲットネットワーク内のすべてのシステムを検索します（これは通常、予測可能なIPv6アドレスでノードをマッピングするよりも信頼性が低く、時間/トラフィックが多くなります）。
5.1.2. DNS Zone Transfers
5.1.2。 DNSゾーン転送
A DNS zone transfer (DNS query type "AXFR") [RFC1034] [RFC1035] can readily provide information about potential attack targets. Restricting zone transfers is thus probably more important for IPv6, even if it is already good practice to restrict them in the IPv4 world.
DNSゾーン転送（DNSクエリタイプ "AXFR"）[RFC1034] [RFC1035]は、潜在的な攻撃対象に関する情報を簡単に提供できます。 したがって、たとえゾーン転送を制限することは、IPv4の世界でそれらを制限することが既に良い習慣であっても、おそらくIPv6にとってより重要です。
5.1.3. DNS Brute Forcing
5.1.3。 DNSブルートフォーシング
Attackers may employ DNS brute-forcing techniques by testing for the presence of DNS AAAA records against commonly used host names.
攻撃者は、一般的に使用されているホスト名に対してDNS AAAAレコードの存在をテストすることにより、DNSブルートフォーシング技術を使用する可能性があります。
Gont & Chown Informational [Page 23] RFC 7707 IPv6 Reconnaissance March 2016 5.1.4. DNS Reverse Mappings
5.1.4。 DNSリバースマッピング
[van-Dijk] describes an interesting technique that employs DNS reverse mappings for network reconnaissance. Essentially, the attacker walks through the "ip6.arpa" zone looking up PTR records, in the hopes of learning the IPv6 addresses of hosts in a given target network (assuming that the reverse mappings have been configured, of course). What is most interesting about this technique is that it can greatly reduce the IPv6 address search space.
[van-Dijk]は、ネットワーク偵察にDNSリバースマッピングを使用する興味深いテクニックについて説明しています。 基本的に、攻撃者は「ip6.arpa」ゾーンをウォークスルーしてPTRレコードを調べ、特定のターゲットネットワーク内のホストのIPv6アドレスを学習することを期待します（もちろん、リバースマッピングが構成されている場合）。 この手法で最も興味深いのは、IPv6アドレス検索スペースを大幅に削減できることです。
Basically, an attacker would walk the ip6.arpa zone corresponding to a target network (e.g., "0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." for "2001:db8:80::/48"), issuing queries for PTR records corresponding to the domain names "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", "1.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", etc. If, say, there were PTR records for any hosts "starting" with the domain name "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." (e.g., the ip6.arpa domain name corresponding to the IPv6 address 2001:db8:80::1), the response would contain an RCODE of 0 (no error). Otherwise, the response would contain an RCODE of 4 (NXDOMAIN). As noted in [van-Dijk], this technique allows for a tremendous reduction in the "IPv6 address" search space.
基本的に、攻撃者はターゲットネットワークに対応するip6.arpaゾーンをウォークします（たとえば、「2001：db8：80 :: / 48」の場合は「0.8.0.0.8.bd0.1.0.0.2.ip6.arpa。」 ）、ドメイン名「0.0.8.0.0.8.bd0.1.0.0.2.ip6.arpa。」、「1.0.8.0.0.8.bd0.1.0.0.2.ip6.arpa。」に対応するPTRレコードのクエリを発行します。 」など たとえば、ドメイン名「0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa」で「始まる」ホストのPTRレコードがあった場合。 （たとえば、IPv6アドレス2001：db8：80 :: 1に対応するip6.arpaドメイン名）、応答には0（エラーなし）のRCODEが含まれます。 それ以外の場合、応答にはRCODE 4（NXDOMAIN）が含まれます。 [van-Dijk]で述べたように、この手法により、「IPv6アドレス」の検索スペースを大幅に削減できます。
NOTE:
Some name servers, incorrectly implementing the DNS protocol,
reply NXDOMAIN instead of NODATA (NOERROR=0 and ANSWER=0) when
encountering a domain without any resource records but that has
child domains, something that is very common in ip6.arpa (these
domains are called ENT for Empty Non-Terminals; see [RFC7719]).
When scanning ip6.arpa, this behavior may slow down or completely
prevent the exploration of ip6.arpa. Nevertheless, since such
behavior is wrong (see [NXDOMAIN-DEF]), one cannot rely on it to
"secure" ip6.arpa against tree walking.
注：一部のネームサーバーは、DNSプロトコルを正しく実装せず、リソースレコードのないドメインに遭遇すると、NODATA（NOERROR = 0およびANSWER = 0）ではなくNXDOMAINを返しますが、子ドメインがあり、ip6.arpa（ これらのドメインは空の非ターミナルのENTと呼ばれます; [RFC7719]を参照してください）。 ip6.arpaをスキャンすると、この動作により速度が低下したり、ip6.arpaの調査が完全に妨げられたりする場合があります。 それにもかかわらず、そのような動作は間違っているため（[NXDOMAIN-DEF]を参照）、ツリーウォーキングに対してip6.arpaを「保護」することはできません。
[IPv6-RDNS] analyzes different approaches and considerations for
ISPs in managing the ip6.arpa zone for IPv6 address space assigned
to many customers, which may affect the technique described in
this section.
[IPv6-RDNS]は、多くの顧客に割り当てられているIPv6アドレス空間のip6.arpaゾーンを管理する際のISPのさまざまなアプローチと考慮事項を分析します。これは、このセクションで説明する手法に影響を与える可能性があります。
5.2. Leveraging Local Name Resolution and Service Discovery Services
5.2。 ローカル名解決とサービスディスカバリサービスの活用
A number of protocols allow for unmanaged local name resolution and service. For example, mDNS [RFC6762] and DNS Service Discovery (DNS- SD) [RFC6763], or Link-Local Multicast Name Resolution (LLMNR) [RFC4795], are examples of such protocols.
いくつかのプロトコルでは、管理されていないローカルの名前解決とサービスが可能です。 たとえば、mDNS [RFC6762]およびDNSサービス検出（DNS- SD）[RFC6763]、またはリンクローカルマルチキャスト名前解決（LLMNR）[RFC4795]は、このようなプロトコルの例です。
Gont & Chown Informational [Page 24]
RFC 7707 IPv6 Reconnaissance March 2016
NOTE:
Besides the Graphical User Interfaces (GUIs) included in products
supporting such protocols, command-line tools such as mdns-scan
[mdns-scan] and mzclient [mzclient] can help discover IPv6 hosts
employing mDNS/DNS-SD.
注：このようなプロトコルをサポートする製品に含まれているグラフィカルユーザーインターフェイス（GUI）のほかに、mdns-scan [mdns-scan]やmzclient [mzclient]などのコマンドラインツールは、mDNS / DNS-SDを使用するIPv6ホストの検出に役立ちます。
5.3. Public Archives
5.3。 公文書館
Public mailing-list archives or Usenet news messages archives may prove to be a useful channel for an attacker, since hostnames and/or IPv6 addresses could be easily obtained by inspection of the (many) "Received from:" or other header lines in the archived email or Usenet news messages.
公開メーリングリストアーカイブまたはUsenetニュースメッセージアーカイブは、ホスト名やIPv6アドレスが（多くの） "Received from："またはその他のヘッダー行の検査によって簡単に取得できるため、攻撃者にとって有用なチャネルであることが判明する可能性があります アーカイブされた電子メールまたはUsenetニュースメッセージ。
5.4. Application Participation
5.4。 アプリケーション参加
Peer-to-peer applications often include some centralized server that coordinates the transfer of data between peers. For example, BitTorrent [BitTorrent] builds swarms of nodes that exchange chunks of files, with a tracker passing information about peers with available chunks of data between the peers. Such applications may offer an attacker a source of peer addresses to probe.
ピアツーピアアプリケーションには、ピア間のデータ転送を調整する集中サーバーが含まれていることがよくあります。 たとえば、BitTorrent [BitTorrent]は、ファイルのチャンクを交換するノードのスウォームを構築し、ピア間で利用可能なデータのチャンクを持つピアに関する情報をトラッカーに渡します。 このようなアプリケーションは、プローブするピアアドレスのソースを攻撃者に提供する可能性があります。
5.5. Inspection of the IPv6 Neighbor Cache and Routing Table
5.5。 IPv6ネイバーキャッシュとルーティングテーブルの検査
Information about other systems connected to the local network might be readily available from the Neighbor Cache [RFC4861] and/or the routing table of any system connected to such network. Source Address Validation Improvement (SAVI) [RFC6620] also builds a cache of IPv6 and link-layer addresses (without actively participating in the Neighbor Discovery packet exchange) and hence is another source of similar information.
ローカルネットワークに接続されている他のシステムに関する情報は、ネイバーキャッシュ[RFC4861]や、そのようなネットワークに接続されているシステムのルーティングテーブルから簡単に入手できる場合があります。 送信元アドレス検証の改善（SAVI）[RFC6620]は、IPv6とリンク層アドレスのキャッシュも構築するため（近隣探索パケット交換に積極的に参加していません）、同様の情報の別の情報源となります。
These data structures could be inspected via either "login" access or SNMP. While this requirement may limit the applicability of this technique, there are a number of scenarios in which this technique might be of use. For example, security audit tools might be provided with the necessary credentials such that the Neighbor Cache and the routing table of all systems for which the tool has "login" or SNMP access can be automatically gleaned. On the other hand, IPv6 worms [V6-WORMS] could leverage this technique for the purpose of spreading on the local network, since they will typically have access to the Neighbor Cache and routing table of an infected system.
これらのデータ構造は、「ログイン」アクセスまたはSNMPを介して検査できます。 この要件により、この手法の適用範囲が制限される場合がありますが、この手法が役立つシナリオがいくつかあります。 たとえば、セキュリティ監査ツールには、ツールが「ログイン」またはSNMPアクセスできるすべてのシステムのネイバーキャッシュとルーティングテーブルを自動的に収集できるように、必要な資格情報が提供される場合があります。 一方、IPv6ワーム[V6-WORMS]は、通常、感染したシステムのネイバーキャッシュとルーティングテーブルにアクセスできるため、ローカルネットワーク上で拡散する目的でこの手法を利用できます。
Section 2.5.1.4 of [OPSEC-IPv6] discusses additional considerations for the inspection of the IPv6 Neighbor Cache.
[OPSEC-IPv6]のセクション2.5.1.4は、IPv6ネイバーキャッシュの検査に関する追加の考慮事項について説明しています。
Gont & Chown Informational [Page 25] RFC 7707 IPv6 Reconnaissance March 2016 5.6. Inspection of System Configuration and Log Files
5.6。 システム構成とログファイルの検査
Nodes are generally configured with the addresses of other important local computers, such as email servers, local file servers, web proxy servers, recursive DNS servers, etc. The /etc/hosts file in UNIX- like systems, Secure Shell (SSH) known_hosts files, or the Microsoft Windows registry are just some examples of places where interesting information about such systems might be found.
ノードは通常、電子メールサーバー、ローカルファイルサーバー、Webプロキシサーバー、再帰DNSサーバーなど、他の重要なローカルコンピューターのアドレスで構成されます。 UNIXライクなシステムの/ etc / hostsファイル、Secure Shell（SSH）known_hostsファイル、またはMicrosoft Windowsレジストリは、そのようなシステムに関する興味深い情報が見つかる可能性がある場所のほんの一例です。
Additionally, system log files (including web server logs, etc.) may also prove to be a useful source for an attacker.
さらに、システムログファイル（Webサーバーログなどを含む） また、攻撃者にとって有用な情報源になる可能性もあります。
While the required credentials to access the aforementioned configuration and log files may limit the applicability of this technique, there are a number of scenarios in which this technique might be of use. For example, security audit tools might be provided with the necessary credentials such that these files can be automatically accessed. On the other hand, IPv6 worms could leverage this technique for the purpose of spreading on the local network, since they will typically have access to these files on an infected system [V6-WORMS].
前述の構成およびログファイルにアクセスするために必要な資格情報は、この手法の適用性を制限する可能性がありますが、この手法が役立つシナリオがいくつかあります。 たとえば、セキュリティ監査ツールには、これらのファイルに自動的にアクセスできるように、必要な資格情報が提供されている場合があります。 一方、IPv6ワームは通常、感染したシステム上のこれらのファイルにアクセスできるため、ローカルネットワーク上で拡散する目的でこの手法を利用する可能性があります[V6-WORMS]。
5.7. Gleaning Information from Routing Protocols
5.7。 ルーティングプロトコルからの情報の収集
Some organizational IPv6 networks employ routing protocols to dynamically maintain routing information. In such an environment, a local attacker could become a passive listener of the routing protocol, to determine other valid subnets/prefixes and some router addresses within that organization [V6-WORMS].
一部の組織IPv6ネットワークでは、ルーティングプロトコルを使用してルーティング情報を動的に維持しています。 このような環境では、ローカルの攻撃者がルーティングプロトコルのパッシブリスナーになり、その組織内の他の有効なサブネット/プレフィックスと一部のルーターアドレスを特定する可能性があります[V6-WORMS]。
5.8. Gleaning Information from IP Flow Information Export (IPFIX)
5.8 IPフロー情報エクスポート（IPFIX）からの情報の収集
IPFIX [RFC7012] can aggregate the flows by source addresses and hence may be leveraged for obtaining a list of "active" IPv6 addresses. Additional discussion of IPFIX can be found in Section 2.5.1.2 of [OPSEC-IPv6].
IPFIX [RFC7012]はソースアドレスごとにフローを集約できるため、「アクティブな」IPv6アドレスのリストを取得するために利用できます。 IPFIXの詳細については、[OPSEC-IPv6]のセクション2.5.1.2を参照してください。
5.9. Obtaining Network Information with traceroute6
5.9。 traceroute6によるネットワーク情報の取得
IPv6 traceroute [traceroute6] and similar tools (such as path6 from [IPv6-Toolkit]) can be employed to find router addresses and valid network prefixes.
IPv6 traceroute [traceroute6]と同様のツール（[IPv6-Toolkit]のpath6など）を使用して、ルーターアドレスと有効なネットワークプレフィックスを見つけることができます。
Gont & Chown Informational [Page 26] RFC 7707 IPv6 Reconnaissance March 2016 5.10. Gleaning Information from Network Devices Using SNMP
5.10。 SNMPを使用してネットワークデバイスから情報を収集する
SNMP can be leveraged to obtain information from a number of data structures such as the Neighbor Cache [RFC4861], the routing table, and the SAVI [RFC6620] cache of IPv6 and link-layer addresses. SNMP access should be secured, such that unauthorized access to the aforementioned information is prevented.
SNMPを利用して、近隣キャッシュ[RFC4861]、ルーティングテーブル、IPv6およびリンク層アドレスのSAVI [RFC6620]キャッシュなど、多くのデータ構造から情報を取得できます。 前述の情報への不正アクセスを防止するために、SNMPアクセスを保護する必要があります。
5.11. Obtaining Network Information via Traffic Snooping
5.11。 トラフィックスヌーピングを介したネットワーク情報の取得
Snooping network traffic can help in discovering active nodes in a number of ways. Firstly, each captured packet will reveal the source and destination of the packet. Secondly, the captured traffic may correspond to network protocols that transfer information such as host or router addresses, network topology information, etc.
ネットワークトラフィックをスヌーピングすると、さまざまな方法でアクティブノードを検出できます。 まず、キャプチャされた各パケットは、パケットの送信元と宛先を明らかにします。 第2に、キャプチャされたトラフィックは、ホストまたはルーターのアドレス、ネットワークトポロジ情報などの情報を転送するネットワークプロトコルに対応する場合があります。
6. Conclusions
6.結論
This document explores the topic of network reconnaissance in IPv6 networks. It analyzes the feasibility of address-scanning attacks in IPv6 networks and shows that the search space for such attacks is typically much smaller than the one traditionally assumed (64 bits).
このドキュメントでは、IPv6ネットワークにおけるネットワーク偵察のトピックについて説明します。 IPv6ネットワークでのアドレススキャン攻撃の実現可能性を分析し、そのような攻撃の検索スペースは通常、従来想定されていたもの（64ビット）よりもはるかに小さいことを示しています。
Additionally, this document explores a plethora of other network reconnaissance techniques, ranging from inspecting the IPv6 Network Cache of an attacker-controlled system to gleaning information about IPv6 addresses from public mailing-list archives or Peer-to-Peer (P2P) protocols.
さらに、このドキュメントでは、攻撃者が制御するシステムのIPv6ネットワークキャッシュの検査から、パブリックメーリングリストアーカイブまたはピアツーピア（P2P）プロトコルからのIPv6アドレスに関する情報の収集に至るまで、他の多くのネットワーク偵察手法について説明します。
We expect traditional address-scanning attacks to become more and more elaborated (i.e., less "brute force"), and other network reconnaissance techniques to be actively explored, as global deployment of IPv6 increases and, more specifically, as more IPv6-only devices are deployed.
IPv6のグローバルな展開が増加するにつれて、より具体的にはIPv6専用デバイスが増えるにつれて、従来のアドレススキャン攻撃がますます巧妙になり（つまり、「ブルートフォース」が減少し）、その他のネットワーク偵察手法が積極的に検討されることが予想されます。 展開されます。
7. Security Considerations
7.セキュリティに関する考慮事項
This document reviews methods by which addresses of hosts within IPv6 subnets can be determined. As such, it raises no new security concerns.
このドキュメントでは、IPv6サブネット内のホストのアドレスを決定する方法について説明します。 したがって、新しいセキュリティ上の問題は発生しません。
Gont & Chown Informational [Page 27] RFC 7707 IPv6 Reconnaissance March 2016 8. References
8.リファレンス
8.1. Normative References
8.1。 規範的な参考文献
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC4380, February 2006,
<http://www.rfc-editor.org/info/rfc4380>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
DOI 10.17487/RFC5214, March 2008,
<http://www.rfc-editor.org/info/rfc5214>.
Gont & Chown Informational [Page 28]
RFC 7707 IPv6 Reconnaissance March 2016
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses",
RFC 6620, DOI 10.17487/RFC6620, May 2012,
<http://www.rfc-editor.org/info/rfc6620>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>.
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
for IP Flow Information Export (IPFIX)", RFC 7012,
DOI 10.17487/RFC7012, September 2013,
<http://www.rfc-editor.org/info/rfc7012>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>.
8.2. Informative References
8.2。 参考情報
[ADDR-ANALYSIS]
Plonka, D. and A. Berger, "Temporal and Spatial
Classification of Active IPv6 Addresses", ACM Internet
Measurement Conference (IMC), Tokyo, Japan, Pages 509-522,
DOI 10.1145/2815675.2815678, October 2015,
<http://conferences2.sigcomm.org/imc/2015/papers/
p509.pdf>.
[BitTorrent]
Wikipedia, "BitTorrent", November 2015,
<https://en.wikipedia.org/w/
index.php?title=BitTorrent&oldid=690381343>.
[CPNI-IPv6]
Gont, F., "Security Assessment of the Internet Protocol
version 6 (IPv6)", UK Centre for the Protection of
National Infrastructure, (available on request).
Gont & Chown Informational [Page 29]
RFC 7707 IPv6 Reconnaissance March 2016
[DEFAULT-IIDS]
Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers",
Work in Progress, draft-ietf-6man-default-iids-10,
February 2016.
[Ford2013] Ford, M., "IPv6 Address Analysis - Privacy In, Transition
Out", May 2013,
<http://www.internetsociety.org/blog/2013/05/
ipv6-address-analysis-privacy-transition-out>.
[Gont-DEEPSEC2011]
Gont, F., "Results of a Security Assessment of the
Internet Protocol version 6 (IPv6)", DEEPSEC
Conference, Vienna, Austria, November 2011,
<http://www.si6networks.com/presentations/deepsec2011/
fgont-deepsec2011-ipv6-security.pdf>.
[Gont-LACSEC2013]
Gont, F., "IPv6 Network Reconnaissance: Theory &
Practice", LACSEC Conference, Medellin, Colombia, May
2013, <http://www.si6networks.com/presentations/lacnic19/
lacsec2013-fgont-ipv6-network-reconnaissance.pdf>.
[IIDS-DHCPv6]
Gont, F. and W. Liu, "A Method for Generating Semantically
Opaque Interface Identifiers with Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", Work in
Progress, draft-ietf-dhc-stable-privacy-addresses-02,
April 2015.
[IPV6-EXT-HEADERS]
Gont, F., Linkova, J., Chown, T., and W. Liu,
"Observations on the Dropping of Packets with IPv6
Extension Headers in the Real World", Work in Progress,
draft-ietf-v6ops-ipv6-ehs-in-real-world-02, December 2015.
[IPv6-RDNS]
Howard, L., "Reverse DNS in IPv6 for Internet Service
Providers", Work in Progress, draft-ietf-dnsop-isp-
ip6rdns-00, October 2015.
[IPv6-Toolkit]
SI6 Networks, "SI6 Networks' IPv6 Toolkit",
<http://www.si6networks.com/tools/ipv6toolkit>.
Gont & Chown Informational [Page 30]
RFC 7707 IPv6 Reconnaissance March 2016
[Malone2008]
Malone, D., "Observations of IPv6 Addresses", Passive and
Active Network Measurement (PAM 2008, LNCS 4979),
DOI 10.1007/978-3-540-79232-1_3, April 2008,
<http://www.maths.tcd.ie/~dwmalone/p/addr-pam08.pdf>.
[mdns-scan]
Poettering, L., "mdns-scan(1) Manual Page",
<http://manpages.ubuntu.com/manpages/precise/man1/
mdns-scan.1.html>.
[mzclient] Bockover, A., "Mono Zeroconf Project -- mzclient command-
line tool",
<http://www.mono-project.com/archived/monozeroconf/>.
[nmap2015] Lyon, Gordon "Fyodor", "Nmap 7.00", November 2015,
<http://insecure.org>.
[NXDOMAIN-DEF]
Bortzmeyer, S. and S. Huque, "NXDOMAIN really means there
is nothing underneath", Work in Progress, draft-ietf-
dnsop-nxdomain-cut-00, December 2015.
[OPSEC-IPv6]
Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
Security Considerations for IPv6 Networks", Work in
Progress, draft-ietf-opsec-v6-07, September 2015.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795,
DOI 10.17487/RFC4795, January 2007,
<http://www.rfc-editor.org/info/rfc4795>.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890,
DOI 10.17487/RFC4890, May 2007,
<http://www.rfc-editor.org/info/rfc4890>.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
RFC 5157, DOI 10.17487/RFC5157, March 2008,
<http://www.rfc-editor.org/info/rfc5157>.
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O.,
and C. Hahn, "IPv6 Unicast Address Assignment
Considerations", RFC 5375, DOI 10.17487/RFC5375, December
2008, <http://www.rfc-editor.org/info/rfc5375>.
Gont & Chown Informational [Page 31]
RFC 7707 IPv6 Reconnaissance March 2016
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583,
DOI 10.17487/RFC6583, March 2012,
<http://www.rfc-editor.org/info/rfc6583>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
Boundary in IPv6 Addressing", RFC 7421,
DOI 10.17487/RFC7421, January 2015,
<http://www.rfc-editor.org/info/rfc7421>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<http://www.rfc-editor.org/info/rfc7721>.
[SMURF-AMPLIFIER]
Gont, F. and W. Liu, "Security Implications of IPv6
Options of Type 10xxxxxx", Work in Progress, draft-gont-
6man-ipv6-smurf-amplifier-03, March 2013.
[THC-IPV6] "THC-IPV6", <http://www.thc.org/thc-ipv6/>.
[traceroute6]
FreeBSD, "FreeBSD System Manager's Manual: traceroute6(8)
manual page", August 2009, <https://www.freebsd.org/cgi/
man.cgi?query=traceroute6>.
[V6-WORMS] Bellovin, S., Cheswick, B., and A. Keromytis, "Worm
propagation strategies in an IPv6 Internet", Vol. 31, No.
1, pp. 70-76, February 2006,
<https://www.cs.columbia.edu/~smb/papers/v6worms.pdf>.
[van-Dijk] van Dijk, P., "Finding v6 hosts by efficiently mapping
ip6.arpa", March 2012, <http://7bits.nl/blog/2012/03/26/
finding-v6-hosts-by-efficiently-mapping-ip6-arpa>.
Gont & Chown Informational [Page 32]
RFC 7707 IPv6 Reconnaissance March 2016
[VBox2011] VirtualBox, "Oracle VM VirtualBox User Manual",
Version 4.1.2, August 2011, <http://www.virtualbox.org>.
[vmesx2011]
VMware, "Setting a static MAC address for a virtual NIC
(219)", VMware Knowledge Base, August 2011,
<http://kb.vmware.com/selfservice/microsites/
search.do?language=en_US&cmd=displayKC&externalId=219>.
[vSphere] VMware, "vSphere Networking", vSphere 5.5, Update 2,
September 2014, <http://pubs.vmware.com/
vsphere-55/topic/com.vmware.ICbase/PDF/
vsphere-esxi-vcenter-server-552-networking-guide.pdf>.
Gont & Chown Informational [Page 33]
RFC 7707 IPv6 Reconnaissance March 2016
Appendix A. Implementation of a Full-Fledged IPv6 Address-Scanning Tool
付録A.本格的なIPv6アドレススキャンツールの実装
This section describes the implementation of a full-fledged IPv6 address-scanning tool. Appendix A.1 discusses the selection of host probes. Appendix A.2 describes the implementation of an IPv6 address scanner for local area networks. Appendix A.3 outlines the implementation of a general (i.e., non-local) IPv6 address scanner.
このセクションでは、本格的なIPv6アドレススキャンツールの実装について説明します。 付録A.1は、ホストプローブの選択について説明しています。 付録A.2は、ローカルエリアネットワーク用のIPv6アドレススキャナーの実装について説明しています。 付録A.3は、一般的な（つまり、非ローカル）IPv6アドレススキャナーの実装の概要を示しています。
A.1. Host-Probing Considerations
A.1。 ホストプロービングの考慮事項
A number of factors should be considered when selecting the probe packet types and the probing rate for an IPv6 address-scanning tool.
IPv6アドレススキャンツールのプローブパケットタイプとプローブレートを選択するときは、いくつかの要素を考慮する必要があります。
Firstly, some hosts (or border firewalls) might be configured to block or rate limit some specific packet types. For example, it is usual for host and router implementations to rate-limit ICMPv6 error traffic. Additionally, some firewalls might be configured to block or rate limit incoming ICMPv6 echo request packets (see, e.g., [RFC4890]).
まず、一部のホスト（または境界ファイアウォール）は、特定のパケットタイプをブロックまたはレート制限するように構成されている場合があります。 たとえば、ホストとルーターの実装では、ICMPv6エラートラフィックをレート制限するのが一般的です。 さらに、一部のファイアウォールは、着信ICMPv6エコー要求パケットをブロックまたはレート制限するように構成されている場合があります（[RFC4890]などを参照）。
NOTE:
As noted earlier in this document, Windows systems simply do not
respond to ICMPv6 echo requests sent to multicast IPv6 addresses.
注：このドキュメントで前述したように、Windowsシステムは、マルチキャストIPv6アドレスに送信されたICMPv6エコー要求に応答しません。
Among the possible probe types are:
可能なプローブタイプは次のとおりです。
o ICMPv6 Echo Request packets (meant to elicit ICMPv6 Echo Replies),
ICMPv6エコー要求パケット（ICMPv6エコー応答を引き出すことを意味する）、
o TCP SYN segments (meant to elicit SYN/ACK or RST segments),
TCP SYNセグメント（SYN / ACKまたはRSTセグメントを引き出すことを意味する）、
o TCP segments that do not contain the ACK bit set (meant to elicit
RST segments),
ACKビットセットを含まないTCPセグメント（RSTセグメントを引き出すため）
o UDP datagrams (meant to elicit a UDP application response or an
ICMPv6 Port Unreachable),
UDPデータグラム（UDPアプリケーション応答またはICMPv6ポート到達不能を引き出すことを意味する）、
o IPv6 packets containing any suitable payload and an unrecognized
extension header (meant to elicit ICMPv6 Parameter Problem error
messages), or
適切なペイロードと認識されない拡張ヘッダーを含むIPv6パケット（ICMPv6パラメーター問題のエラーメッセージを引き出すことを意味する）、または
o IPv6 packets containing any suitable payload and an unrecognized
option of type 10xxxxxx (meant to elicit an ICMPv6 Parameter
Problem error message).
適切なペイロードとタイプ10xxxxxxの認識されないオプションを含むIPv6パケット（ICMPv6パラメータの問題のエラーメッセージが表示されることを意味します）。
Selecting an appropriate probe packet might help conceal the ongoing attack, but it may also be actually necessary if host or network configuration causes certain probe packets to be dropped.
適切なプローブパケットを選択すると、進行中の攻撃を隠すのに役立つ場合がありますが、ホストまたはネットワークの構成によって特定のプローブパケットがドロップされる場合にも実際に必要になることがあります。
Gont & Chown Informational [Page 34] RFC 7707 IPv6 Reconnaissance March 2016 Some address-scanning tools (such as scan6 of [IPv6-Toolkit]) incorporate support for IPv6 extension headers. In some cases, inserting some IPv6 extension headers in the probe packet may allow some filtering policies or monitoring devices to be circumvented. However, it may also result in the probe packets being dropped, as a result of the widespread dropping of IPv6 packets that employ IPv6 extension headers (see [IPV6-EXT-HEADERS]).
一部のアドレススキャンツール（[IPv6-Toolkit]のscan6など）には、IPv6拡張ヘッダーのサポートが組み込まれています。 場合によっては、一部のIPv6拡張ヘッダーをプローブパケットに挿入すると、一部のフィルタリングポリシーまたは監視デバイスを回避できる場合があります。 ただし、IPv6拡張ヘッダー（[IPV6-EXT-HEADERS]を参照）を使用するIPv6パケットが広くドロップされた結果、プローブパケットがドロップされることもあります。
Another factor to consider is the address-probing rate. Clearly, the higher the rate, the smaller the amount of time required to perform the attack. However, the probing rate should not be too high, or else:
考慮すべきもう1つの要素は、アドレスプローブ率です。 明らかに、レートが高いほど、攻撃の実行に必要な時間は短くなります。 ただし、プロービングレートが高すぎないようにする必要があります。
1. the attack might cause network congestion, thus resulting in
packet loss.
1.攻撃によりネットワークの輻輳が発生し、パケット損失が発生する可能性があります。
2. the attack might hit rate limiting, thus resulting in packet
loss.
2.攻撃がレート制限に達し、パケット損失が発生する可能性があります。
3. the attack might reveal underlying problems in Neighbor Discovery
implementations, thus leading to packet loss and possibly even
Denial of Service.
3.攻撃により、近隣探索の実装における根本的な問題が明らかになり、パケット損失、さらにはサービス拒否につながる可能性があります。
Packet loss is undesirable, since it would mean that an "alive" node might remain undetected as a result of a lost probe or response. Such losses could be the result of congestion (in case the attacker is scanning a target network at a rate higher than the target network can handle) or may be the result of rate limiting (as it would be typically the case if ICMPv6 is employed for the probe packets). Finally, as discussed in [CPNI-IPv6] and [RFC6583], some IPv6 router implementations have been found to be unable to perform decent resource management when faced with Neighbor Discovery traffic involving a large number of local nodes. This essentially means that regardless of the type of probe packets, an address-scanning attack might result in a DoS of the target network, with the same (or worse) effects as that of network congestion or rate limiting.
パケット損失は望ましくありません。プローブまたは応答が失われた結果、「生きている」ノードが検出されないままになる可能性があるためです。 このような損失は、輻輳の結果である可能性があります（攻撃者がターゲットネットワークが処理できるレートよりも高いレートでターゲットネットワークをスキャンしている場合）またはレート制限の結果である可能性があります（通常、ICMPv6が プローブパケット）。 最後に、[CPNI-IPv6]と[RFC6583]で説明されているように、一部のIPv6ルーターの実装では、多数のローカルノードを含む近隣探索トラフィックに直面すると、適切なリソース管理を実行できないことが判明しています。 これは基本的に、プローブパケットのタイプに関係なく、アドレススキャン攻撃がターゲットネットワークのDoSを引き起こし、ネットワークの輻輳またはレート制限と同じ（またはより悪い）影響をもたらす可能性があることを意味します。
The specific rates at which each of these issues may come into play vary from one scenario to another and depend on the type of deployed routers/firewalls, configuration parameters, etc.
これらの各問題が発生する具体的な速度は、シナリオごとに異なり、展開されているルーター/ファイアウォールの種類、構成パラメーターなどによって異なります。
A.2. Implementation of an IPv6 Local Address-Scanning Tool
A.2。 IPv6ローカルアドレススキャンツールの実装
scan6 [IPv6-Toolkit] is a full-fledged IPv6 local address-scanning tool, which has proven to be effective and efficient for the discovery of IPv6 hosts on a local network.
scan6 [IPv6-Toolkit]は、本格的なIPv6ローカルアドレススキャンツールであり、ローカルネットワーク上のIPv6ホストの検出に効果的かつ効率的であることが証明されています。
Gont & Chown Informational [Page 35] RFC 7707 IPv6 Reconnaissance March 2016 The scan6 tool operates (roughly) as follows:
scan6ツールは、（おおよそ）次のように動作します。
1. The tool learns the local prefixes used for autoconfiguration and
generates/configures one address for each local prefix (in
addition to a link-local address).
1.ツールは、自動構成に使用されるローカルプレフィックスを学習し、（リンクローカルアドレスに加えて）各ローカルプレフィックスに対して1つのアドレスを生成/構成します。
2. An ICMPv6 Echo Request message destined to the all-nodes on-link
multicast address (ff02::1) is sent from each of the addresses
"configured" in the previous step. Because of the different
source addresses, each probe packet causes the victim nodes to
use different source addresses for the response packets (this
allows the tool to learn virtually all the addresses in use in
the local network segment).
2.全ノードのオンリンクマルチキャストアドレス（ff02 :: 1）宛てのICMPv6エコー要求メッセージが、前の手順で "構成"された各アドレスから送信されます。 送信元アドレスが異なるため、各プローブパケットにより、犠牲ノードは応答パケットに異なる送信元アドレスを使用します（これにより、ツールはローカルネットワークセグメントで使用されている実質的にすべてのアドレスを学習できます）。
3. The same procedure of the previous bullet is performed, but this
time with ICMPv6 packets that contain an unrecognized option of
type 10xxxxxx, such that ICMPv6 Parameter Problem error messages
are elicited. This allows the tool to discover, e.g., Windows
nodes, which otherwise do not respond to multicasted ICMPv6 Echo
Request messages.
3.前の箇条書きと同じ手順が実行されますが、今回は、ICMPv6パラメーターの問題のエラーメッセージが発生するように、タイプ10xxxxxxの認識されないオプションを含むICMPv6パケットが使用されます。 これにより、ツールは、たとえばWindowsノードを検出できます。これがなければ、マルチキャストされたICMPv6エコー要求メッセージに応答しません。
4. Each time a new "alive" address is discovered, the corresponding
IID is combined with all the local prefixes, and the resulting
addresses are probed (with unicasted packets). This can help to
discover other addresses in use on the local network segment,
since the same IID is typically used with all the available
prefixes for the local network.
4.新しい「アライブ」アドレスが検出されるたびに、対応するIIDがすべてのローカルプレフィックスと結合され、結果のアドレスがプローブされます（ユニキャストパケットを使用）。 同じIIDは通常、ローカルネットワークで使用可能なすべてのプレフィックスで使用されるため、これはローカルネットワークセグメントで使用されている他のアドレスを検出するのに役立ちます。
NOTE:
The aforementioned scheme can fail to discover some addresses for
some implementations. For example, Mac OS X employs IPv6
addresses embedding IEEE identifiers (rather than "temporary
addresses") when responding to packets destined to a link-local
multicast address, sourced from an on-link prefix.
注：前述のスキームは、一部の実装では一部のアドレスを検出できない場合があります。 たとえば、Mac OS Xは、「ローカルアドレスではなく」IEEE識別子を埋め込んだIPv6アドレスを使用して、オンリンクプレフィックスから送信された、リンクローカルマルチキャストアドレス宛のパケットに応答します。
A.3. Implementation of an IPv6 Remote Address-Scanning Tool
A.3。 IPv6リモートアドレススキャンツールの実装
An IPv6 remote address-scanning tool could be implemented with the following features:
IPv6リモートアドレススキャンツールは、次の機能で実装できます。
o The tool can be instructed to target specific address ranges
(e.g., 2001:db8::0-10:0-1000).
このツールは、特定のアドレス範囲をターゲットにするように指示できます（例：2001：db8 :: 0-10：0-1000）。
o The tool can be instructed to scan for SLAAC addresses of a
specific vendor, such that only addresses embedding the
corresponding IEEE OUIs are probed.
特定のベンダーのSLAACアドレスをスキャンして、対応するIEEE OUIを埋め込んでいるアドレスのみがプローブされるように、ツールに指示することができます。
Gont & Chown Informational [Page 36]
RFC 7707 IPv6 Reconnaissance March 2016
o The tool can be instructed to scan for SLAAC addresses that employ
a specific IEEE OUI or set of OUIs corresponding to a specific
vector.
このツールは、特定のIEEE OUIまたは特定のベクトルに対応するOUIのセットを使用するSLAACアドレスをスキャンするように指示できます。
o The tool can be instructed to discover virtual machines, such that
a given IPv6 prefix is only scanned for the address patterns
resulting from virtual machines.
このツールは、仮想マシンを検出するように指示できます。これにより、特定のIPv6プレフィックスは、仮想マシンから生じるアドレスパターンについてのみスキャンされます。
o The tool can be instructed to scan for low-byte addresses.
このツールは、低バイトアドレスをスキャンするように指示できます。
o The tool can be instructed to scan for wordy addresses, in which
case the tool selects addresses based on a local dictionary.
ツールは、ワードアドレスをスキャンするように指示できます。その場合、ツールはローカルディクショナリに基づいてアドレスを選択します。
o The tool can be instructed to scan for IPv6 addresses embedding
TCP/UDP service ports, in which case the tool selects addresses
based on a list of well-known service ports.
このツールは、TCP / UDPサービスポートを組み込んだIPv6アドレスをスキャンするように指示できます。その場合、ツールは、既知のサービスポートのリストに基づいてアドレスを選択します。
o The tool can be specified to scan an IPv4 address range in use at
the target network, such that only IPv4-based IPv6 addresses are
scanned.
ツールは、ターゲットネットワークで使用中のIPv4アドレス範囲をスキャンするように指定できます。これにより、IPv4ベースのIPv6アドレスのみがスキャンされます。
The scan6 tool of [IPv6-Toolkit] implements all these techniques/ features. Furthermore, when given a target domain name or sample IPv6 address for a given prefix, the tool will try to infer the address pattern in use at the target network, and reduce the address search space accordingly.
[IPv6-Toolkit]のscan6ツールは、これらのテクニック/機能をすべて実装しています。 さらに、特定のプレフィックスのターゲットドメイン名またはサンプルIPv6アドレスを指定すると、ツールはターゲットネットワークで使用されているアドレスパターンを推測し、それに応じてアドレス検索スペースを削減しようとします。
Acknowledgements The authors would like to thank Ray Hunter, who provided valuable text that was readily incorporated into Section 4.2.1 of this document. The authors would like to thank (in alphabetical order) Ivan Arce, Alissa Cooper, Spencer Dawkins, Stephen Farrell, Wesley George, Marc Heuse, Ray Hunter, Barry Leiba, Libor Polcak, Alvaro Retana, Tomoyuki Sahara, Jan Schaumann, Arturo Servin, and Eric Vyncke for providing valuable comments on earlier draft versions of this document. Fernando Gont would like to thank Jan Zorz of Go6 Lab <http://go6lab.si/> and Jared Mauch of NTT America for providing access to systems and networks that were employed to perform experiments and measurements that helped to improve this document. Additionally, he would like to thank SixXS <https://www.sixxs.net> for providing IPv6 connectivity. Gont & Chown Informational [Page 37] RFC 7707 IPv6 Reconnaissance March 2016 Part of the contents of this document are 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 Daniel Bellomo (UNRC) for his continued support. Authors' Addresses Fernando Gont Huawei Technologies Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: +54 11 4650 8472 Email: fgont@si6networks.com URI: http://www.si6networks.com Tim Chown Jisc Lumen House, Library Avenue Harwell Oxford, Didcot. OX11 0SG United Kingdom Email: tim.chown@jisc.ac.uk Gont & Chown Informational [Page 38]