[要約] RFC 9099 - Operational Security Considerations for IPv6 Networks についての要約は、IPv6ネットワークの運用におけるセキュリティ上の考慮事項を提供することです。目的は、IPv6導入時に遭遇する可能性のあるセキュリティリスクを理解し、対策を講じるためのガイドラインを提供することにあります。利用場面は、IPv6ネットワークの設計、実装、運用を行うITプロフェッショナルやセキュリティ担当者にとって参考となります。
Internet Engineering Task Force (IETF) É. Vyncke
Request for Comments: 9099 Cisco
Category: Informational K. Chittimaneni
ISSN: 2070-1721
M. Kaeo
Double Shot Security
E. Rey
ERNW
August 2021
Operational Security Considerations for IPv6 Networks
IPv6ネットワークのための運用セキュリティ上の考慮事項
Abstract
概要
Knowledge and experience on how to operate IPv4 networks securely is available, whether the operator is an Internet Service Provider (ISP) or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes security issues in the protocol, but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices.
オペレータがインターネットサービスプロバイダ（ISP）またはエンタープライズ内部ネットワークであるかどうかにかかわらず、IPv4ネットワークを安全に利用できるようにしてください。しかし、IPv6はいくつかの新しいセキュリティ上の課題を提示します。RFC 4942はプロトコル内のセキュリティ問題を説明していますが、ネットワークマネージャはまた、特定の選択肢の利点や短所を列挙する、より実用的で操作志向の文書を必要としています。
This document analyzes the operational security issues associated with several types of networks and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise networks, service provider networks, or managed residential networks.
この文書は、いくつかのタイプのネットワークに関連する運用セキュリティ上の問題を分析し、技術的および手続き型の緩和技術を提案します。この文書は、エンタープライズネットワーク、サービスプロバイダネットワーク、または管理された住宅ネットワークなどの管理対象ネットワークにのみ適用されます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9099.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https：//www.rfc-editor.org/info/rfc9099で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Applicability Statement
1.2. Requirements Language
2. Generic Security Considerations
2.1. Addressing
2.1.1. Use of ULAs
2.1.2. Point-to-Point Links
2.1.3. Loopback Addresses
2.1.4. Stable Addresses
2.1.5. Temporary Addresses for SLAAC
2.1.6. DHCP Considerations
2.1.7. DNS Considerations
2.1.8. Using a /64 per Host
2.1.9. Privacy Consideration of Addresses
2.2. Extension Headers
2.2.1. Order and Repetition of Extension Headers
2.2.2. Hop-by-Hop Options Header
2.2.3. Fragment Header
2.2.4. IP Security Extension Header
2.3. Link-Layer Security
2.3.1. Neighbor Solicitation Rate-Limiting
2.3.2. Router and Neighbor Advertisements Filtering
2.3.3. Securing DHCP
2.3.4. 3GPP Link-Layer Security
2.3.5. Impact of Multicast Traffic
2.3.6. SEND and CGA
2.4. Control Plane Security
2.4.1. Control Protocols
2.4.2. Management Protocols
2.4.3. Packet Exceptions
2.5. Routing Security
2.5.1. BGP Security
2.5.2. Authenticating OSPFv3 Neighbors
2.5.3. Securing Routing Updates
2.5.4. Route Filtering
2.6. Logging/Monitoring
2.6.1. Data Sources
2.6.2. Use of Collected Data
2.6.3. Summary
2.7. Transition/Coexistence Technologies
2.7.1. Dual Stack
2.7.2. Encapsulation Mechanisms
2.7.3. Translation Mechanisms
2.8. General Device Hardening
3. Enterprises-Specific Security Considerations
3.1. External Security Considerations
3.2. Internal Security Considerations
4. Service Provider Security Considerations
4.1. BGP
4.1.1. Remote Triggered Black Hole Filtering
4.2. Transition/Coexistence Mechanism
4.3. Lawful Intercept
5. Residential Users Security Considerations
6. Further Reading
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
Running an IPv6 network is new for most operators not only because they are not yet used to large-scale IPv6 networks but also because there are subtle but critical and important differences between IPv4 and IPv6, especially with respect to security. For example, all Layer 2 (L2) interactions are now done using the Neighbor Discovery Protocol (NDP) [RFC4861] rather than the Address Resolution Protocol [RFC0826]. Also, there is no Network Address Port Translation (NAPT) defined in [RFC2663] for IPv6 even if [RFC6296] specifies an IPv6-to-IPv6 Network Prefix Translation (NPTv6), which is a 1-to-1 mapping of IPv6 addresses. Another important difference is that IPv6 is extensible with the use of extension headers.
IPv6ネットワークの実行は、ほとんどの演算子が大規模なIPv6ネットワークに使用されていないだけでなく、特にセキュリティに関して、IPv4とIPv6の間に重要で重要で重要な違いがあるからでも、ほとんどの演算子にとって新しいものです。たとえば、アドレス解決プロトコル[RFC0826]ではなく、すべてのレイヤ2（L2）のインタラクションが隣接発見プロトコル（NDP）[RFC4861]を使用して行われました。また、[RFC6296]がIPv6対IPv6ネットワークプレフィックス変換（NPTv6）を指定しても、IPv6の[RFC2663]で定義されているネットワークアドレスポート変換（NAPT）はありません。これはIPv6アドレスの1対1のマッピングです。。もう1つの重要な違いは、IPv6が拡張ヘッダーを使用して拡張可能です。
IPv6 networks are deployed using a variety of techniques, each of which have their own specific security concerns.
IPv6ネットワークはさまざまなテクニックを使用して展開されており、それぞれが独自の特定のセキュリティ上の懸念を持っています。
This document complements [RFC4942] by listing security issues when operating a network (including various transition technologies). It also provides operational deployment experiences where warranted.
このドキュメントは、ネットワークを操作するとき（さまざまな遷移技術を含む）セキュリティの問題をリストすることによって[RFC4942]を補完します。また、保証されている運用展開体験を提供します。
This document is applicable to managed networks, i.e., when the network is operated by the user organization itself. Indeed, many of the recommended mitigation techniques must be configured with detailed knowledge of the network (which are the default routers, the switch trunk ports, etc.). This covers Service Providers (SPs), enterprise networks, and some knowledgeable home-user-managed residential networks. This applicability statement especially applies to Sections 2.3 and 2.5.4.
この文書は、管理対象ネットワーク、すなわちネットワークがユーザ組織自体によって操作されるときに適用可能である。実際、推奨される緩和技術の多くは、ネットワークの詳細な知識（デフォルトのルータ、スイッチトランクポートなど）で構成する必要があります。これはサービスプロバイダ（SPS）、エンタープライズネットワーク、そしていくつかの知識のあるホームユーザー管理された住宅ネットワークをカバーしています。この適用範囲は特にセクション2.3と2.5.4に適用されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
IPv6 address allocations and overall architecture are important parts of securing IPv6. Initial designs, even if intended to be temporary, tend to last much longer than expected. Although IPv6 was initially thought to make renumbering easy, in practice, it may be extremely difficult to renumber without a proper IP Address Management (IPAM) system. [RFC7010] introduces the mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements associated with IPv6 renumbering.
IPv6アドレス割り当てと全体のアーキテクチャは、IPv6を保護するための重要な部分です。初期設計は、たとえ一時的なものであることを意図していても、予想よりもはるかに長く続く傾向があります。IPv6は最初は簡単に変更を簡単にすると考えられていましたが、実際には、適切なIPアドレス管理（IPAM）システムなしで番号を変更することが非常に困難です。[RFC7010]は、IPv6サイトの参照番号に利用できるメカニズムを紹介し、IPv6の番号変更に関連した明示的な問題と要件の大部分をカバーしようとします。
A key task for a successful IPv6 deployment is to prepare an addressing plan. Because an abundance of address space is available, structuring an address plan around both services and geographic locations allows address space to become a basis for more structured security policies to permit or deny services between geographic regions. [RFC6177] documents some operational considerations of using different prefix sizes for address assignments at end sites.
IPv6展開を成功させるための重要なタスクは、アドレス指定計画を作成することです。アドレス空間の豊富さが利用可能であるため、サービスと地理的な場所の両方の周囲にアドレスプランを構築することで、アドレススペースがより構造化されたセキュリティポリシーの基礎となり、地理的な地域間のサービスを許可または拒否します。[RFC6177]最終サイトでのアドレス割り当てのための異なるプレフィックスサイズを使用するいくつかの運用上の考慮事項を文書化してください。
A common question is whether companies should use Provider-Independent (PI) or Provider-Aggregated (PA) space [RFC7381], but, from a security perspective, there is little difference. However, one aspect to keep in mind is who has administrative ownership of the address space and who is technically responsible if/when there is a need to enforce restrictions on routability of the space, e.g., due to malicious criminal activity originating from it. Relying on PA address space may also increase the perceived need for address translation techniques, such as NPTv6; thereby, the complexity of the operations, including the security operations, is augmented.
一般的な問題は、企業がプロバイダーに依存しない（PI）またはプロバイダ集約（PA）スペース[RFC7381]を使用すべきかどうかですが、セキュリティの観点からは違いはほとんどありません。しかしながら、心を維持するための1つの側面は、誰がアドレス空間の管理上所有権を持っていて、例えば、空間の経路化の制限を執行する必要がある場合、例えば、それから発生する悪意のある犯罪行為のために必要なのかを知っているか。PAアドレス空間に頼ることはまた、NPTv6のようなアドレス変換技術に対する知覚された必要性を高めることができる。これにより、セキュリティ操作を含む操作の複雑さが拡張される。
In [RFC7934], it is recommended that IPv6 network deployments provide multiple IPv6 addresses from each prefix to general-purpose hosts, and it specifically does not recommend limiting a host to only one IPv6 address per prefix. It also recommends that the network give the host the ability to use new addresses without requiring explicit requests (for example, by using Stateless Address Autoconfiguration (SLAAC)). Privacy extensions, as of [RFC8981], constitute one of the main scenarios where hosts are expected to generate multiple addresses from the same prefix, and having multiple IPv6 addresses per interface is a major change compared to the unique IPv4 address per interface for hosts (secondary IPv4 addresses are not common), especially for audits (see Section 2.6.2.3).
[RFC7934]では、IPv6ネットワーク展開は各接頭辞から汎用ホストに複数のIPv6アドレスを提供することをお勧めします。また、ネットワークに明示的な要求を必要とせずに（たとえば、Stateless Address Autoconfiguration（SLAAC）を使用することによって）ホストに新しいアドレスを使用する機能があることをお勧めします。Privacy Extensions、[RFC8981]のように、ホストが同じ接頭辞から複数のアドレスを生成すると予想される主なシナリオの1つを構成し、インターフェイスごとに複数のIPv6アドレスを持つことは、ホスト用のインターフェイスごとの固有のIPv4アドレスと比較して大きな変更です。特に監査のためのセカンダリIPv4アドレスは一般的ではありません（2.6.2.3項を参照）。
Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios where interfaces are not globally reachable, despite being routed within a domain. They formally have global scope, but [RFC4193] specifies that they must be filtered at domain boundaries. ULAs are different from the addresses described in [RFC1918] and have different use cases. One use of ULAs is described in [RFC4864]; another one is for internal communication stability in networks where external connectivity may come and go (e.g., some ISPs provide ULAs in home networks connected via a cable modem). It should further be kept in mind that ULA /48s from the fd00::/8 space (L=1) MUST be generated with a pseudorandom algorithm, per Section 3.2.1 of [RFC4193].
一意のローカルアドレス（ULAS）[RFC4193]は、ドメイン内でルーティングされるにもかかわらず、インターフェイスがグローバルに到達できないシナリオを対象としています。それらは正式にグローバルスコープを持ちますが、[RFC4193]はドメイン境界でフィルタリングされなければならないことを指定します。ULAは[RFC1918]に記載されているアドレスとは異なり、ユースケースが異なります。ULAの1つの使用は[RFC4864]に記載されています。もう1つは、外部接続性が発生して行く可能性があるネットワークにおける内部通信安定性（例えば、いくつかのISPは、ケーブルモデムを介して接続されたホームネットワーク内のULAを提供する）である。FD00 :: / 8スペース（L = 1）からのULA / 48S（L = 1）のURA / 48Sは、[RFC4193]のセクション3.2.1あたりの疑似ランダムアルゴリズムで生成されなければならないことをさらに留意する必要があります。
Section 5.1 of [RFC6164] specifies the rationale of using /127 for inter-router, point-to-point links to prevent the ping-pong issue between routers not correctly implementing [RFC4443], and it also prevents a denial-of-service (DoS) attack on the Neighbor Cache. The previous recommendation of [RFC3627] has been obsoleted and marked Historic by [RFC6547].
[RFC6164]のセクション5.1は、ルータ間のPing-Pongの推論を正しく実装していない状態でのPing-Pongの問題を防ぐためのポイントツーポイントリンクを指定し、サービス拒否を防ぎます。（DOS）隣接キャッシュへの攻撃。[RFC3627]の以前の推奨事項は、[RFC6547]によって廃止され、歴史的なマークが付けられています。
Some environments are also using link-local addressing for point-to-point links. While this practice could further reduce the attack surface of infrastructure devices, the operational disadvantages also need to be carefully considered; see [RFC7404].
一部の環境は、ポイントツーポイントリンクのリンクローカルアドレッシングを使用しています。この慣習はインフラストラクチャデバイスの攻撃面をさらに減らすことができますが、操作上の不利益も慎重に検討する必要があります。[RFC7404]を参照してください。
Many operators reserve a /64 block for all loopback addresses in their infrastructure and allocate a /128 out of this reserved /64 prefix for each loopback interface. This practice facilitates configuration of Access Control List (ACL) rules to enforce a security policy for those loopback addresses.
多くの演算子は、インフラストラクチャ内のすべてのループバックアドレスに対してA / 64ブロックを予約し、各ループバックインターフェイスについてこの予約済み/ 64プレフィックスから/ 128を割り当てます。この方法は、それらのループバックアドレスのセキュリティポリシーを強制するためのアクセス制御リスト（ACL）規則の構成を容易にします。
When considering how to assign stable addresses for nodes (either by static configuration or by pre-provisioned DHCPv6 lease (Section 2.1.6)), it is necessary to take into consideration the effectiveness of perimeter security in a given environment.
（静的構成または事前プロビジョニングされたDHCPv6リース（セクション2.1.6）によって）ノードに安定したアドレスを割り当てる方法を考慮すると、特定の環境における周辺セキュリティの有効性を考慮する必要があります。
There is a trade-off between ease of operation (where some portions of the IPv6 address could be easily recognizable for operational debugging and troubleshooting) versus the risk of trivial scanning used for reconnaissance. [SCANNING] shows that there are scientifically based mechanisms that make scanning for IPv6-reachable nodes more feasible than expected; see [RFC7707].
操作の容易さ（IPv6アドレスの一部が運用デバッグおよびトラブルシューティングのために簡単に認識できる場所）と偵察に使用される些細なスキャンのリスクとの間にトレードオフがあります。[スキャン]は、IPv6到達可能なノードのスキャンを予想されるよりも実現可能な科学的にベースのメカニズムがあることを示しています。[RFC7707]を参照してください。
Stable addresses also allow easy enforcement of a security policy at the perimeter based on IPv6 addresses. For example, Manufacturer Usage Description (MUD) [RFC8520] is a mechanism where the perimeter defense can retrieve the security policy template based on the type of internal device and apply the right security policy based on the device's IPv6 address.
安定したアドレスはまた、IPv6アドレスに基づいて周辺計でセキュリティポリシーを簡単に強制することを可能にします。たとえば、製造元の使用状況説明（MUD）[RFC8520]は、内部デバイスの種類に基づいて、周辺ディフェンスがセキュリティポリシーテンプレートを取得し、デバイスのIPv6アドレスに基づいて正しいセキュリティポリシーを適用できるメカニズムです。
The use of well-known IPv6 addresses (such as ff02::1 for all link-local nodes) or the use of commonly repeated addresses could make it easy to figure out which devices are name servers, routers, or other critical devices; even a simple traceroute will expose most of the routers on a path. There are many scanning techniques possible and operators should not rely on the 'impossible to find because my address is random' paradigm (a.k.a. "security by obscurity") even if it is common practice to have the stable addresses randomly distributed across /64 subnets and to always use DNS (as IPv6 addresses are hard for human brains to remember).
よく知られているIPv6アドレス（すべてのリンクローカルノードの場合はFF02 :: 1など）の使用または一般的に繰り返されるアドレスの使用は、どのデバイスがネームサーバー、ルーター、またはその他の重要なデバイスであるかを理解することを容易にする可能性があります。単純なTracerouteでさえ、パス上のほとんどのルータを公開します。可能な限り多くのスキャン技術があるため、オペレータは、安定したアドレスをランダムに分散させた場合でも、安定したアドレスをランダムに分散させることが一般的である場合でも、オペレータが「私のアドレスがランダムな」パラダイムであるために依存してはいけません。常にDNSを使用するには（IPv6アドレスが人間の脳に覚えておくのは難しいです）。
While, in some environments, obfuscating addresses could be considered an added benefit, it should not preclude enforcement of perimeter rules. Stable addresses following some logical allocation scheme may ease the operation (as simplicity always helps security).
一部の環境では、難読化アドレスは追加の利点と見なすことができ、それは境界規則の執行を妨げるべきではありません。いくつかの論理割り当て方式に続く安定したアドレスは、操作を容易にすることができる（単純さが常にセキュリティを助ける）。
Typical deployments will have a mix of stable and non-stable addresses; the stable addresses being either predictable (e.g., ::25 for a mail server) or obfuscated (i.e., appearing as a random 64-bit number).
典型的な展開は、安定した住所と安定した住所と非安定住所の組み合わせを持っています。安定したアドレスは、予測可能（例えば、メールサーバの場合は:: 25）、または難読化されている（すなわち、ランダム64ビット数として現れる）。
Historically, Stateless Address Autoconfiguration (SLAAC) makes up the globally unique IPv6 address based on an automatically generated 64-bit interface identifier (IID) based on the 64-bit Extended Unique Identifier (EUI-64) Media Access Control (MAC) address combined with the /64 prefix (received in the Prefix Information Option (PIO) of the Router Advertisement (RA)). The EUI-64 address is generated from the stable 48-bit MAC address and does not change even if the host moves to another network; this is of course bad for privacy, as a host can be traced from network (home) to network (office or Wi-Fi in hotels). [RFC8064] recommends against the use of EUI-64 addresses, and it must be noted that most host operating systems do not use EUI-64 addresses anymore and rely on either [RFC8981] or [RFC8064].
歴史的には、ステートレスアドレスの自動設定（SLAAC）は、64ビット拡張固有識別子（EUI-64）メディアアクセス制御（MAC）アドレスに基づいて、自動的に生成された64ビットインターフェイス識別子（IID）に基づいてグローバルに一意のIPv6アドレスを占めています。/ 64プレフィックス（Router Advertisement（RA）のプレフィックス情報オプション（PIO）で受信されます）。EUI-64アドレスは安定した48ビットMACアドレスから生成され、ホストが別のネットワークに移動しても変わりません。ホストがネットワーク（HOME）からネットワーク（HOMEのOfficeまたはWi-Fiのホテル）まで追跡できるため、これはもちろん、プライバシーのためには悪いです。[RFC8064] EUI-64アドレスを使用することをお勧めします。ほとんどのホストオペレーティングシステムはもうEUI-64アドレスを使用しないと[RFC8981]または[RFC8064]に依存していることに注意してください。
Randomly generating an interface ID, as described in [RFC8981], is part of SLAAC with so-called privacy extension addresses and is used to address some privacy concerns. Privacy extension addresses, a.k.a. temporary addresses, may help to mitigate the correlation of activities of a node within the same network and may also reduce the attack exposure window. But using privacy extension addresses as described in [RFC8981] might prevent the operator from building host-specific access control lists (ACLs). These privacy extension addresses could also be used to obfuscate some malevolent activities, and specific user attribution/accountability procedures should be put in place, as described in Section 2.6.
[RFC8981]に記載されているように、インターフェイスIDをランダムに生成することは、いわゆるプライバシー拡張アドレスを持つSLAACの一部であり、いくつかのプライバシーに関する懸念に対処するために使用されます。プライバシー拡張アドレス、A.K.A.一時アドレスは、同じネットワーク内のノードの活動の相関関係を軽減するのに役立ち、攻撃露光ウィンドウも減少させる可能性があります。しかし、[RFC8981]に記載されているようにプライバシー拡張アドレスを使用すると、オペレータがホスト固有のアクセス制御リスト（ACL）を構築するのを防ぐことができます。これらのプライバシー拡張アドレスは、いくつかの悪意のあるアクティビティを難読化するために使用され、セクション2.6で説明されているように、特定のユーザー属性/説明責任手順を整備する必要があります。
[RFC8064] combined with the address generation mechanism of [RFC7217] specifies another way to generate an address while still keeping the same IID for each network prefix; this allows SLAAC nodes to always have the same stable IPv6 address on a specific network while having different IPv6 addresses on different networks.
[RFC8064] [RFC7217]のアドレス生成メカニズムと組み合わされて、ネットワークプレフィックスごとに同じIIDを維持しながらアドレスを生成するための別の方法を指定します。これにより、SLAACノードは、異なるネットワーク上で異なるIPv6アドレスを持ちながら、特定のネットワーク上で常に同じ安定したIPv6アドレスを持つことができます。
In some specific use cases where user accountability is more important than user privacy, network operators may consider disabling SLAAC and relying only on DHCPv6; however, not all operating systems support DHCPv6, so some hosts will not get any IPv6 connectivity. Disabling SLAAC and privacy extension addresses can be done for most operating systems by sending RA messages with a hint to get addresses via DHCPv6 by setting the M-bit and disabling SLAAC by resetting all A-bits in all PIOs. However, attackers could still find ways to bypass this mechanism if it is not enforced at the switch/router level.
ユーザーの説明責任がユーザーのプライバシーよりも重要な特定のユースケースでは、ネットワーク事業者はSLAACを無効にし、DHCPv6のみに頼ることを検討することができます。ただし、すべてのオペレーティングシステムがDHCPv6をサポートするわけではないため、一部のホストはIPv6接続を取得しません。SLAACおよびプライバシーの拡張アドレスを無効にすると、すべてのAビットをすべてのPIOのすべてのAビットをリセットしてMビットと無効にすることで、SLAACを無効にすることで、DHCPv6を介してアドレスを取得するためにRAメッセージを送信することによって、ほとんどのオペレーティングシステムに対して行うことができます。ただし、攻撃者は、スイッチ/ルータレベルで強制されていない場合は、このメカニズムをバイパスする方法を見つけることができます。
However, in scenarios where anonymity is a strong desire (protecting user privacy is more important than user attribution), privacy extension addresses should be used. When mechanisms recommended by [RFC8064] are available, the stable privacy address is probably a good balance between privacy (among different networks) and security/ user attribution (within a network).
ただし、匿名性が強い欲求であるシナリオでは（ユーザーのプライバシーを保護することはユーザー属性よりも重要です）、プライバシー拡張アドレスを使用する必要があります。[RFC8064]が推奨されるメカニズムが利用可能な場合、安定したプライバシーアドレスはおそらく（さまざまなネットワーク間で）プライバシーとセキュリティ/ユーザー属性の間のバランスが良いです（ネットワーク内）。
Some environments use DHCPv6 to provision addresses and other parameters in order to ensure auditability and traceability (see Section 2.6.1.5 for the limitations of DHCPv6 for auditability).
一部の環境は、監査性とトレーサビリティを確保するためにアドレスやその他のパラメータをプロビジョニングするためにDHCPv6を使用します（監査可能性のためのDHCPv6の制限については、セクション2.6.1.5を参照）。
A main security concern is the ability to detect and counteract rogue DHCP servers (Section 2.3.3). It must be noted that, as opposed to DHCPv4, DHCPv6 can lease several IPv6 addresses per client. For DHCPv4, the lease is bound to the 'client identifier', which may contain a hardware address or another type of identifier, such as a DNS name. For DHCPv6, the lease is bound to the client DHCP Unique Identifier (DUID), which may or may not be bound to the client L2 address. [RFC7824] describes the privacy issues associated with the use of DHCPv6 by Internet users. The anonymity profiles [RFC7844] are designed for clients that wish to remain anonymous to the visited network. [RFC7707] recommends that DHCPv6 servers issue addresses randomly from a large pool.
主なセキュリティ上の関心事は、Rogue DHCPサーバーを検出したり、相殺する機能です（セクション2.3.3）。DHCPv4とは対照的に、DHCPv6はクライアントごとに複数のIPv6アドレスをリースできることに注意してください。DHCPv4の場合、リースは「クライアント識別子」にバインドされており、これはハードウェアアドレスまたはDNS名などの別のタイプの識別子を含むことがあります。DHCPv6の場合、リースはクライアントDHCP一意の識別子（DUID）にバインドされています。これは、クライアントL2アドレスにバインドされている可能性があります。[RFC7824]インターネットユーザーによるDHCPv6の使用に関連するプライバシーの問題について説明します。匿名性プロファイル[RFC7844]は、訪問先ネットワークに匿名を維持したいクライアント用に設計されています。[RFC7707] DHCPv6サーバーが大きなプールからランダムにアドレスを発行することをお勧めします。
While the security concerns of DNS are not fundamentally different between IPv4 and IPv6, there are specific considerations in DNS64 [RFC6147] environments that need to be understood. Specifically, the interactions and the potential of interference with DNSSEC [RFC4033] implementation need to be understood -- these are pointed out in more detail in Section 2.7.3.2.
DNSのセキュリティ上の関心がIPv4とIPv6の間では根本的に異ならないが、理解する必要があるDNS64 [RFC6147]環境では具体的な考慮事項があります。具体的には、DNSSEC [RFC4033]実装との相互作用と干渉の可能性を理解する必要があります。これらは2.7.3.2項でさらに詳細に指摘されています。
An interesting approach is using a /64 per host, as proposed in [RFC8273], especially in a shared environment. This allows for easier user attribution (typically based on the host MAC address), as its /64 prefix is stable, even if applications within the host can change their IPv6 address within this /64 prefix.
特に共有環境では、[RFC8273]で提案されているように、興味深いアプローチは1ホストあたり/ 64を使用しています。これにより、ホスト内のアプリケーションがこの/ 64プレフィックス内のIPv6アドレスを変更できる場合でも、その/ 64の接頭辞が安定しているため、ユーザー属性（通常はホストMACアドレスに基づく）を容易にすることができます。
This can also be useful for the generation of ACLs once individual systems (e.g., admin workstations) have their own prefixes.
これは、個々のシステム（例えば管理ワークステーション）が独自のプレフィックスを持つと、ACLの生成にも役立ちます。
In addition to the security aspects of IPv6 addresses, there are also privacy considerations: mainly because they are of global scope and visible globally. [RFC7721] goes into more detail on the privacy considerations for IPv6 addresses by comparing the manually configured IPv6 address, DHCPv6, and SLAAC.
IPv6アドレスのセキュリティ側面に加えて、プライバシーに関する考慮事項もあります。主にグローバルな範囲であり、グローバルに表示されているためです。[RFC7721]手動で構成されたIPv6アドレス、DHCPv6、およびSLAACを比較することによって、IPv6アドレスのプライバシーに関する考慮事項について詳しく説明します。
Extension headers are an important difference between IPv4 and IPv6. In IPv4-based packets, it's trivial to find the upper-layer protocol type and protocol header, while, in IPv6, it is more complex since the extension header chain must be parsed completely (even if not processed) in order to find the upper-layer protocol header. IANA has closed the existing empty "Next Header Types" registry to new entries and is redirecting its users to the "IPv6 Extension Header Types" registry, per [RFC7045].
拡張ヘッダーはIPv4とIPv6の間の重要な違いです。IPv4ベースのパケットでは、上位レイヤープロトコルタイプとプロトコルヘッダーを見つけるのが簡単ですが、IPv6では、拡張ヘッダーチェーンを完全に（処理されていなくても）上位を見つけるために（処理されていなくても）より複雑です。 - レイヤプロトコルヘッダ。IANAは、既存の空の「次のヘッダータイプ」レジストリを新しいエントリに閉じ、そのユーザーを[RFC7045]ごとに「IPv6拡張ヘッダータイプ」レジストリにリダイレクトしています。
Extension headers have also become a very controversial topic since forwarding nodes that discard packets containing extension headers are known to cause connectivity failures and deployment problems [RFC7872]. Understanding the role of various extension headers is important, and this section enumerates the ones that need careful consideration.
拡張ヘッダーを含むパケットを破棄するノードを接続障害や展開の問題を引き起こすことが知られているので、拡張ヘッダーは非常に物議を醸しているトピックにもなりましたが、[RFC7872]。さまざまな拡張ヘッダの役割を理解することが重要であり、このセクションは慎重な検討を必要とするものを列挙します。
A clarification on how intermediate nodes should handle packets with existing or future extension headers is found in [RFC7045]. The uniform TLV format to be used for defining future extension headers is described in [RFC6564]. Sections 5.2 and 5.3 of [RFC8504] provide more information on the processing of extension headers by IPv6 nodes.
中間ノードが既存または将来の拡張ヘッダを持つパケットをどのように処理するかについての説明は、[RFC7045]にあります。将来の拡張ヘッダを定義するために使用される均一なTLVフォーマットは、[RFC6564]に記載されている。[RFC8504]のセクション5.2および5.3は、IPv6ノードによる拡張ヘッダーの処理に関する詳細情報を提供します。
Vendors of filtering solutions and operations personnel responsible for implementing packet filtering rules should be aware that the 'Next Header' field in an IPv6 header can both point to an IPv6 extension header or to an upper-layer protocol header. This has to be considered when designing the user interface of filtering solutions or during the creation of filtering rule sets.
パケットフィルタリングルールの実装を担当するフィルタリングソリューションとオペレーション要因のベンダーIPv6ヘッダーの「次のヘッダー」フィールドは、IPv6拡張ヘッダーまたは上位層プロトコルヘッダーの両方を指すことができます。これは、フィルタリングソリューションのユーザーインターフェイスを設計する場合、またはフィルタリングルールセットの作成中に考慮されます。
[IPV6-EH-FILTERING] discusses filtering rules for those extension headers at transit routers.
[IPv6-EHフィルタリング]トランジットルータの拡張ヘッダーのフィルタリングルールについて説明します。
While [RFC8200] recommends the order and the maximum repetition of extension headers, at the time of writing, there are still IPv6 implementations that support an order of headers that is not recommended (such as Encapsulating Security Payload (ESP) before routing) or an illegal repetition of headers (such as multiple routing headers). The same applies for options contained in the extension headers (see [IPV6-EH-PARSING]). In some cases, it has led to nodes crashing when receiving or forwarding wrongly formatted packets.
[RFC8200]は、書き込み時に拡張ヘッダーの注文と最大繰り返しを推奨しますが、推奨されていないヘッダーの順序をサポートするIPv6実装（ルーティング前のセキュリティペイロード（ESP）など）またはヘッダーの違法な繰り返し（複数のルーティングヘッダーなど）。拡張ヘッダーに含まれるオプションについても同じことが当てはまります（[IPv6-EH-PARSING]を参照）。場合によっては、誤ってフォーマットされたパケットを受信または転送するときにノードがクラッシュするようになりました。
A firewall or edge device should be used to enforce the recommended order and the maximum occurrences of extension headers by dropping nonconforming packets.
ファイアウォールまたはエッジデバイスを使用して、不適合パケットをドロップすることで、拡張ヘッダーの推奨順序と最大発生を強制する必要があります。
In the previous IPv6 specification [RFC2460], the hop-by-hop options header, when present in an IPv6 packet, forced all nodes to inspect and possibly process this header. This enabled denial-of-service attacks as most, if not all, routers cannot process this type of packet in hardware; they have to process these packets in software and, hence, this task competes with other software tasks, such as handling the control and management plane processing.
前のIPv6仕様[RFC2460]では、Hop-By-HopオプションヘッダーがIPv6パケットに存在する場合は、すべてのノードを調べてこのヘッダーを処理して処理します。これにより、サービス拒否攻撃がほとんどの場合、すべてがハードウェアでこのタイプのパケットを処理できないルータは、ルータがこのタイプのパケットを処理できません。これらのパケットをソフトウェアで処理する必要があります。したがって、このタスクは、制御と管理プレーン処理の処理など、他のソフトウェアタスクと競合します。
Section 4.3 of [RFC8200], the current Internet Standard for IPv6, has taken this attack vector into account and made the processing of hop-by-hop options headers by intermediate routers explicitly configurable.
IPv6の現在のインターネット規格である[RFC8200]のセクション4.3は、この攻撃ベクトルを考慮に入れており、中間ルータによるホップバイホップオプションヘッダーの処理を明示的に設定可能にしました。
The fragment header is used by the source (and only the source) when it has to fragment packets. [RFC7112] and Section 4.5 of [RFC8200] explain why it is important that:
フラグメントヘッダーは、パケットをフラグメント化する必要がある場合にソース（およびソースのみ）によって使用されます。[RFC7112]および[RFC8200]のセクション4.5は、なぜ重要なのかを説明します。
* Firewall and security devices should drop first fragments that do not contain the entire IPv6 header chain (including the transport-layer header).
* ファイアウォールとセキュリティデバイスは、IPv6ヘッダーチェーン全体（トランスポート層ヘッダーを含む）を含まない最初のフラグメントを削除する必要があります。
* Destination nodes should discard first fragments that do not contain the entire IPv6 header chain (including the transport-layer header).
* 宛先ノードは、IPv6ヘッダーチェーン全体（トランスポート層ヘッダーを含む）を含まない最初のフラグメントを破棄する必要があります。
If those requirements are not met, stateless filtering could be bypassed by a hostile party. [RFC6980] applies a stricter rule to NDP by enforcing the drop of fragmented NDP packets (except for "Certification Path Advertisement" messages, as noted in section Section 2.3.2.1). [RFC7113] describes how the RA-Guard function described in [RFC6105] should behave in the presence of fragmented RA packets.
これらの要件が満たされていない場合、ステートレスフィルタリングは敵対的なパーティーによってバイパスされる可能性があります。[RFC6980]断片化されたNDPパケットのドロップを強制することで、NDPにSLICTERルールを適用します（「認証パス広告」メッセージを除く（セクション2.3.2.1に記載されているように）。[RFC7113] [RFC6105]で説明されているRA-Guard機能が、断片化されたRAパケットの存在下でどのように動作するかを説明します。
The IPsec [RFC4301] extension headers (Authentication Header (AH) [RFC4302] and ESP [RFC4303]) are required if IPsec is to be utilized for network-level security. Previously, IPv6 mandated implementation of IPsec, but [RFC6434] updated that recommendation by making support of the IPsec architecture [RFC4301] a 'SHOULD' for all IPv6 nodes that are also retained in the latest IPv6 Nodes Requirement standard [RFC8504].
IPSecがネットワークレベルのセキュリティに利用される場合は、IPsec [RFC4301]拡張ヘッダー（認証ヘッダー（AH）[RFC4302]、ESP [RFC4303]）が必要です。以前は、IPv6のIPSecの実装が義務付けられていますが、[RFC6434]は、最新のIPv6ノード要件標準[RFC8504]に保持されているすべてのIPv6ノードの場合は、IPSecアーキテクチャ[RFC4301]をサポートすることによる推奨事項を更新しました。
IPv6 relies heavily on NDP [RFC4861] to perform a variety of link operations, such as discovering other nodes on the link, resolving their link-layer addresses, and finding routers on the link. If not secured, NDP is vulnerable to various attacks, such as router/ neighbor message spoofing, redirect attacks, Duplicate Address Detection (DAD) DoS attacks, etc. Many of these security threats to NDP have been documented in "IPv6 Neighbor Discovery (ND) Trust Models and Threats" [RFC3756] and in "Operational Neighbor Discovery Problems" [RFC6583].
IPv6はNDP [RFC4861]に大きく依存しており、リンク上の他のノードを発見したり、リンク層のアドレスの解決、リンク上のルータの検索など、さまざまなリンク操作を実行します。保護されていない場合、NDPは、ルータ/ネイバーメッセージのなりすまし、リダイレクト攻撃、複製アドレス検出（DAD）DOS攻撃などのさまざまな攻撃に対して脆弱です.NDPへのこれらのセキュリティ上の脅威の多くは、「IPv6隣接発見（ND」に文書化されています。···「RFC3756」と「運用上の発見問題」[RFC6583]。
Most of the issues are only applicable when the attacker is on the same link, but NDP also has security issues when the attacker is off link; see Section 2.3.1 below.
ほとんどの問題は、攻撃者が同じリンク上にある場合にのみ適用されますが、攻撃者がリンクオフのときにNDPもセキュリティ上の問題を抱えています。下記の2.3.1項を参照してください。
NDP can be vulnerable to remote DoS attacks, for example, when a router is forced to perform address resolution for a large number of unassigned addresses, i.e., when a prefix is scanned by an attacker in a fast manner. This can keep new devices from joining the network or render the last-hop router ineffective due to high CPU usage. Easy mitigative steps include rate limiting Neighbor Solicitations, restricting the amount of state reserved for unresolved solicitations, and cleverly managing the cache/timer.
NDPは、例えば、ルータが多数の未割り当てアドレスのアドレス解像度、すなわちプレフィックスが攻撃者によって迅速にスキャンされたときに、リモートDOS攻撃に対して脆弱である可能性がある。これにより、新しいデバイスがネットワークに参加すること、または最後のホップルータが高いCPU使用率のために効果がないことを防ぐことができます。簡単な脆弱な手順には、隣接勧誘の契約が含まれており、未解決義務用の状態の額を制限し、キャッシュ/タイマーを巧妙に管理します。
[RFC6583] discusses the potential for off-link DoS in detail and suggests implementation improvements and operational mitigation techniques that may be used to mitigate or alleviate the impact of such attacks. Here are some feasible mitigation options that can be employed by network operators today:
[RFC6583]は、オフリンクDOSの可能性を詳細に説明し、そのような攻撃の影響を軽減または軽減するために使用される可能性がある実施の改善および運用緩和技術を提案する。これは今日ネットワーク事業者によって採用され得るいくつかの実現可能な緩和オプションです。
* Ingress filtering of unused addresses by ACL. These require stable configuration of the addresses, e.g., allocating the addresses out of a /120 and using a specific ACL to only allow traffic to this /120 (of course, the actual hosts are configured with a /64 prefix for the link).
* ACLによる未使用アドレスの入力フィルタリングこれらはアドレスの安定した構成、例えば、A / 120からアドレスを割り当て、そしてこの/ 120へのトラフィックを許可するための特定のACLを使用して（もちろん、実際のホストはリンクのための/ 64プレフィックスで構成されています）。
* Tuning of NDP process (where supported), e.g., enforcing limits on data structures, such as the number of Neighbor Cache entries in 'incomplete' state (e.g., 256 incomplete entries per interface) or the rate of NA per interface (e.g., 100 NA per second).
* NDPプロセスのチューニング（サポートされている場合）、たとえば、「インターフェイスごとに256個の不完全なエントリごとに256個の不完全なエントリ）やインターフェイスごとのNAのレートなどのデータ構造の制限を強制する（例：100）。1秒あたりのNA）。
* Using a /127 on a point-to-point link, per [RFC6164].
* [RFC6164]ごとに、ポイントツーポイントリンクでA / 127を使用する。
* Using only link-local addresses on links where there are only routers; see [RFC7404].
* ルータだけがあるリンク上のリンクローカルアドレスのみを使用する。[RFC7404]を参照してください。
Router Advertisement spoofing is a well-known, on-link attack vector and has been extensively documented. The presence of rogue RAs, either unintentional or malicious, can cause partial or complete failure of operation of hosts on an IPv6 link. For example, a node can select an incorrect router address, which can then be used for an on-path attack, or the node can assume wrong prefixes to be used for SLAAC. [RFC6104] summarizes the scenarios in which rogue RAs may be observed and presents a list of possible solutions to the problem. [RFC6105] (RA-Guard) describes a solution framework for the rogue RA problem where network segments are designed around switching devices that are capable of identifying invalid RAs and blocking them before the attack packets actually reach the target nodes.
ルータ通知スプーフィングは、よく知られている、リンク上の攻撃ベクトルであると広く報告されています。意図しないまたは悪意のあるいずれかの不正RAS、の存在は、IPv6リンク上のホストの動作の部分的または完全な故障を引き起こす可能性があります。例えば、ノードはSLAACのために使用されるように、その後のパス攻撃に使用することができ、またはノードが間違った接頭辞を想定することができ、誤ったルータアドレスを、選択することができます。[RFC6104]は不正RASが問題に対する可能な解決策のリストを観察し、提示することが可能なシナリオを要約します。[RFC6105]（RA-ガード）は、ネットワークセグメントが無効のRAを識別し、攻撃パケットが実際にターゲットノードに到達する前に遮断することが可能なスイッチング素子を中心に設計された不正RA問題に対するソリューションフレームワークを記述する。
However, several evasion techniques that circumvent the protection provided by RA-Guard have surfaced. A key challenge to this mitigation technique is introduced by IPv6 fragmentation. Attackers can conceal their attack by fragmenting their packets into multiple fragments such that the switching device that is responsible for blocking invalid RAs cannot find all the necessary information to perform packet filtering of the same packet. [RFC7113] describes such evasion techniques and provides advice to RA-Guard implementers such that the aforementioned evasion vectors can be eliminated.
しかしながら、RAガードによって提供される保護を回避するいくつかの回避技術が表面的になった。この緩和技術への重要な課題は、IPv6フラグメンテーションによって導入されています。攻撃者は、無効なRASをブロックする責任を負うスイッチングデバイスが同じパケットのパケットフィルタリングを実行するために必要なすべての情報を見つけることができないように、それらのパケットを複数のフラグメントに断片化することによって彼らの攻撃を隠すことができます。[RFC7113]そのような回避技術を説明し、前述の回避ベクトルを排除することができるようにRA - Guardの実施者に助言を提供する。
Given that the IPv6 Fragmentation Header can be leveraged to circumvent some implementations of RA-Guard, [RFC6980] updates [RFC4861] such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, except "Certification Path Advertisement", thus allowing for simple and effective measures to counter fragmented NDP attacks.
IPv6フラグメンテーションヘッダーをRA-Guardのいくつかの実装を回避するためにレバレッジすることができることを考えると、[RFC6980] [RFC4861]は、IPv6フラグメンテーションヘッダーの使用がすべてのネイバー検出メッセージで禁じられています。断片化されたNDP攻撃に対抗するためのシンプルで効果的な対策のため。
The Source Address Validation Improvements (savi) Working Group has worked on other ways to mitigate the effects of such attacks. [RFC7513] helps in creating bindings between a source IP address assigned to DHCPv4 [RFC2131] or DHCPv6 [RFC8415] and a binding anchor [RFC7039] on a SAVI device. Also, [RFC6620] describes how to glean similar bindings when DHCP is not used. The bindings can be used to filter packets generated on the local link with forged source IP addresses.
送信元アドレス検証の改善（SAVI）ワーキンググループは、そのような攻撃の影響を軽減するために他の方法で働きました。[RFC7513] SAVIデバイス上のDHCPv4 [RFC2131]またはDHCPv6 [RFC8415]に割り当てられている送信元IPアドレスとバインディングアンカー[RFC7039]との間のバインドを作成するのに役立ちます。また、[RFC6620] DHCPが使用されていないときに類似のバインディングをGLEANする方法について説明します。バインディングを使用して、ローカルリンクで生成されたパケットを鍛造ソースIPアドレスとフィルタリングできます。
Isolating hosts for the NDP traffic can be done by using a /64 per host, refer to Section 2.1.8, as NDP is only relevant within a /64 on-link prefix; 3GPP (Section 2.3.4) uses a similar mechanism.
NDPトラフィックのホストを分離することは、ホストごとにA / 64を使用して行うことができます.NDPは/ 64のオンリンクプレフィックス内にのみ関連しているため、2.1.8項を参照してください。3GPP（セクション2.3.4）も同様のメカニズムを使用しています。
A more drastic technique to prevent all NDP attacks is based on isolation of all hosts with specific configurations. In such a scenario, hosts (i.e., all nodes that are not routers) are unable to send data-link layer frames to other hosts; therefore, no host-to-host attacks can happen. This specific setup can be established on some switches or Wi-Fi access points. This is not always feasible when hosts need to communicate with other hosts in the same subnet, e.g., for access to file shares.
すべてのNDP攻撃を防ぐためのより劇的な技術は、特定の構成を持つすべてのホストの分離に基づいています。そのようなシナリオでは、ホスト（すなわち、ルータではないすべてのノード）は、データリンクレイヤフレームを他のホストに送信することができない。したがって、ホスト間の攻撃は起こりません。この特定のセットアップは、いくつかのスイッチまたはWi-Fiアクセスポイントで確立できます。ホストが同じサブネット内の他のホストと通信する必要がある場合、例えばファイル共有にアクセスする必要がある場合、これは必ずしも実行可能ではありません。
It is still recommended that RA-Guard and SAVI be employed as a first line of defense against common attack vectors, including misconfigured hosts. This recommendation also applies when DHCPv6 is used, as RA messages are used to discover the default router(s) and for on-link prefix determination. This line of defense is most effective when incomplete fragments are dropped by routers and L2 switches, as described in Section 2.2.3. The generated log should also be analyzed to identify and act on violations.
誤った構成のホストを含む一般的な攻撃ベクトルに対する防御の最初の国防総省として、RA-GuardとSAVIを採用することをお勧めします。この推奨事項は、RAメッセージがデフォルトのルータを検出し、オンリンクプレフィックスの決定のために使用されるため、DHCPv6が使用されるときにも適用されます。この防御の行は、セクション2.2.3で説明されているように、不完全なフラグメントがルータおよびL2スイッチによって削除された場合に最も効果的です。生成されたログはまた、違反を識別して行動するために分析されるべきです。
Network operators should be aware that RA-Guard and SAVI do not work as expected or could even be harmful in specific network configurations (notably when there could be multiple routers).
ネットワーク事業者は、RA-GuardとSaviが予想どおりに機能しないか、特定のネットワーク構成に有害な場合でも、（特に複数のルーターがある可能性がある場合）に注意してください。
Enabling RA-Guard by default in managed networks (e.g., Wi-Fi networks, enterprise campus networks, etc.) should be strongly considered except for specific use cases, such as in the presence of homenet devices emitting router advertisements.
管理対象ネットワーク（例えば、Wi-Fiネットワーク、エンタープライズキャンパスネットワークなど）のデフォルトでRA-Guardを有効にするルータ広告を発行するHomeNetデバイスの存在下など、特定のユースケースを除き、強く考慮されるべきです。
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described in [RFC8415], enables DHCP servers to pass configuration parameters, such as IPv6 network addresses and other configuration information, to IPv6 nodes. DHCP plays an important role in most large networks by providing robust stateful configuration in the context of automated system provisioning.
[RFC8415]で説明されているように、IPv6（DHCPv6）の動的ホスト構成プロトコルは、DHCPサーバーがIPv6ネットワークアドレスやその他の構成情報などの構成パラメータをIPv6ノードに渡すことができます。DHCPは、自動化システムプロビジョニングのコンテキストで堅牢なステートフル構成を提供することによって、ほとんどの大規模ネットワークで重要な役割を果たします。
The two most common threats to DHCP clients come from malicious (a.k.a. rogue) or unintentionally misconfigured DHCP servers. In these scenarios, a malicious DHCP server is established with the intent of providing incorrect configuration information to the clients to cause a denial-of-service attack or to mount an on-path attack. While unintentional, a misconfigured DHCP server can have the same impact. Additional threats against DHCP are discussed in the security considerations section of [RFC8415].
DHCPクライアントに対する2つの最も一般的な脅威は、悪意のある（A.K.A.Rogue）または意図せずに誤って設定されていないDHCPサーバーから来ています。これらのシナリオでは、誤った設定情報をクライアントに提供して、サービス拒否攻撃を引き起こすか、またはオンパス攻撃をマウントするという意図があるという意図があります。意図しないDHCPサーバーが同じ影響を与える可能性があります。DHCPに対する追加の脅威は、[RFC8415]の[セキュリティ上の考慮事項]セクションで説明されています。
DHCPv6-Shield [RFC7610] specifies a mechanism for protecting connected DHCPv6 clients against rogue DHCPv6 servers. This mechanism is based on DHCPv6 packet filtering at the L2 device, i.e., the administrator specifies the interfaces connected to DHCPv6 servers. However, extension headers could be leveraged to bypass DHCPv6-Shield unless [RFC7112] is enforced.
DHCPv6-Shield [RFC7610]ローグDHCPv6サーバーに対して接続されたDHCPv6クライアントを保護するためのメカニズムを指定します。このメカニズムは、L2デバイスでのDHCPv6パケットフィルタリング、すなわち管理者はDHCPv6サーバーに接続されているインターフェイスを指定します。ただし、[RFC7112]を強制しない限り、拡張ヘッダーはDHCPV6シールドをバイパスするように活用できます。
It is recommended to use DHCPv6-Shield and to analyze the corresponding log messages.
DHCPv6シールドを使用し、対応するログメッセージを分析することをお勧めします。
The 3GPP link is a point-to-point-like link that has no link-layer address. This implies there can only be one end host (the mobile handset) and the first-hop router (i.e., a Gateway GPRS Support Node (GGSN) or a Packet Data Network Gateway (PGW)) on that link. The GGSN/PGW never configures a non-link-local address on the link using the advertised /64 prefix on it; see Section 2.1.8. The advertised prefix must not be used for on-link determination. There is no need for address resolution on the 3GPP link, since there are no link-layer addresses. Furthermore, the GGSN/PGW assigns a prefix that is unique within each 3GPP link that uses IPv6 Stateless Address Autoconfiguration. This avoids the necessity to perform DAD at the network level for every address generated by the mobile host. The GGSN/PGW always provides an IID to the cellular host for the purpose of configuring the link-local address and ensures the uniqueness of the IID on the link (i.e., no collisions between its own link-local address and the mobile host's address).
3GPPリンクは、リンク層アドレスを持たないポイントツーポイントのようなリンクです。これは、そのリンク上の1つのエンドホスト（モバイルハンドセット）と第1ホップルータ（すなわち、ゲートウェイGPRSサポートノード（GGSN）またはパケットデータネットワークゲートウェイ（PGW））しかないことを意味する。 GGSN / PGWは、アドバタイズされた/ 64のプレフィックスを使用してリンク上のリンク上のローカルアドレスを設定しません。セクション2.1.8を参照してください。アドバタイズされた接頭辞は、オンリンクの決定には使用してはいけません。リンク層アドレスがないため、3GPPリンクのアドレス解決は必要ありません。さらに、GGSN / PGWは、IPv6ステートレスアドレスの自動設定を使用する各3GPPリンク内で一意のプレフィックスを割り当てます。これにより、モバイルホストによって生成されたアドレスごとにネットワークレベルでDADを実行する必要が回避されます。 GGSN / PGWは、リンクローカルアドレスを構成する目的で常にセルラーホストにIIDを提供し、リンク上のIIDの一意性を保証します（つまり、それ自身のリンクローカルアドレスとモバイルホストのアドレスの間の衝突なし）。 。
The 3GPP link model itself mitigates most of the known NDP-related DoS attacks. In practice, the GGSN/PGW only needs to route all traffic to the mobile host that falls under the prefix assigned to it. As there is also a single host on the 3GPP link, there is no need to defend that IPv6 address.
3GPPリンクモデル自体は、ほとんどの既知のNDP関連のDOS攻撃を軽減します。実際には、GGSN / PGWは、それに割り当てられた接頭辞の下にあるすべてのトラフィックをモバイルホストにルーティングするだけで済みます。3GPPリンク上に単一のホストもあるので、そのIPv6アドレスを守る必要はありません。
See Section 5 of [RFC6459] for a more detailed discussion on the 3GPP link model, NDP, and the address configuration details. In some mobile networks, DHCPv6 and DHCP Prefix Delegation (DHCP-PD) are also used.
3GPP Link Model、NDP、およびアドレス構成の詳細については、[RFC6459]のセクション5を参照してください。一部のモバイルネットワークでは、DHCPv6およびDHCPプレフィックス委任（DHCP-PD）も使用されています。
IPv6 uses multicast extensively for signaling messages on the local link to avoid broadcast messages for on-the-wire efficiency.
IPv6は、ローカルリンク上のシグナリングメッセージのために広範囲にマルチキャストを使用して、ブロードキャストメッセージを避けるために、ブロードキャストメッセージを無線で使用します。
The use of multicast has some side effects on wireless networks, such as a negative impact on battery life of smartphones and other battery-operated devices that are connected to such networks. [RFC7772] and [RFC6775] (for specific wireless networks) discuss methods to rate-limit RAs and other ND messages on wireless networks in order to address this issue.
マルチキャストの使用は、スマートフォンのバッテリ寿命やそのようなネットワークに接続されている他の電池式の装置の影響など、無線ネットワークにある副作用を持っています。[RFC7772]と[RFC6775]（特定の無線ネットワークの場合）この問題に対処するために、無線ネットワーク上のRASおよび他のNDメッセージをレート制限する方法について説明します。
The use of link-layer multicast addresses (e.g., ff02::1 for the all nodes link-local multicast address) could also be misused for an amplification attack. Imagine a hostile node sending an ICMPv6 ECHO_REQUEST to ff02::1 with a spoofed source address, then all link-local nodes will reply with ICMPv6 ECHO_REPLY packets to the source address. This could be a DoS attack for the address owner. This attack is purely local to the L2 network, as packets with a link-local destination are never forwarded by an IPv6 router.
リンク層マルチキャストアドレス（例えば、全ノードリンク - ローカルマルチキャストアドレスについてのFF02 :: 1）の使用は、増幅攻撃にも誤用され得る。偽造された送信元アドレスを使用して、ICMPv6 ECHO_REQUESTをFF02 :: 1に送信する敵対ノードを想像してみてください。これはアドレスの所有者のためのDOS攻撃かもしれません。この攻撃は、リンクローカル宛先のパケットがIPv6ルータによって転送されないため、L2ネットワークに対して純粋にローカルです。
This is the reason why large Wi-Fi network deployments often limit the use of link-layer multicast, either from or to the uplink of the Wi-Fi access point, i.e., Wi-Fi stations are prevented to send link-local multicast to their direct neighboring Wi-Fi stations; this policy also blocks service discovery via Multicast DNS (mDNS) [RFC6762] and Link-Local Multicast Name Resolution (LLMNR) [RFC4795].
これが、大規模なWi-Fiネットワーク展開が、Wi-Fiアクセスポイントのアップリンクから、すなわちWi-FiステーションのリンクまたはWi-Fiステーションのいずれかのリンク層マルチキャストの使用を必要としている理由です。すなわち、Wi-Fiステーションがリンクローカルマルチキャストを直接隣接するWi-Fiステーション。このポリシーは、マルチキャストDNS（MDNS）[RFC6762]とリンクローカルマルチキャスト名解決（LLMNR）[RFC4795]を介してサービス検出をブロックします。
SEcure Neighbor Discovery (SEND), as described in [RFC3971], is a mechanism that was designed to secure ND messages. This approach involves the use of new NDP options to carry public-key-based signatures. Cryptographically Generated Addresses (CGA), as described in [RFC3972], are used to ensure that the sender of a Neighbor Discovery message is the actual "owner" of the claimed IPv6 address. A new NDP option, the CGA option, was introduced and is used to carry the public key and associated parameters. Another NDP option, the RSA Signature option, is used to protect all messages relating to neighbor and router discovery.
[RFC3971]に記載されているように、セキュアネイバーディスカバリ（SEND）は、NDメッセージを保護するように設計されたメカニズムです。このアプローチは、公開鍵ベースの署名を持つための新しいNDPオプションの使用を含みます。[RFC3972]で説明されているように、暗号的に生成されたアドレス（CGA）は、近隣探索メッセージの送信者が特許請求されたIPv6アドレスの実際の「所有者」であることを確認するために使用されます。新しいNDPオプションであるCGAオプションが導入され、公開鍵と関連パラメータを運ぶために使用されます。別のNDPオプション、RSAシグネチャオプションは、ネイバーおよびルーターの検出に関するすべてのメッセージを保護するために使用されます。
SEND protects against:
保護者からの送信：
* Neighbor Solicitation/Advertisement Spoofing
* 隣接勧誘/広告スプーフィング
* Neighbor Unreachability Detection Failure
* 近隣の到達不可能な検出失敗
* Duplicate Address Detection DoS Attack
* DUPLICATEアドレス検出DOS攻撃
* Router Solicitation and Advertisement Attacks
* ルーターの勧誘と広告攻撃
* Replay Attacks
* リプレイ攻撃
* Neighbor Discovery DoS Attacks
* 近隣探索DOS攻撃
SEND does NOT:
送信は：
* protect statically configured addresses
* 静的に設定されたアドレスを保護します
* protect addresses configured using fixed identifiers (i.e., EUI-64)
* 固定識別子を使用して構成されたアドレスを保護する（すなわち、EUI-64）
* provide confidentiality for NDP communications
* NDP通信の機密性を提供します
* compensate for an unsecured link -- SEND does not require that the addresses on the link and Neighbor Advertisements correspond
* 無担保リンクの補償 - 送信は、リンクおよびネイバー広告のアドレスが対応する必要はありません
However, at this time and over a decade since their original specifications, CGA and SEND do not have support from widely deployed IPv6 devices; hence, their usefulness is limited and should not be relied upon.
しかし、現時点では、元の仕様以降、CGAとSendは広く展開されたIPv6デバイスからのサポートを持っていません。したがって、それらの有用性は限られており、信頼されるべきではありません。
[RFC6192] defines the router control plane and provides detailed guidance to secure it for IPv4 and IPv6 networks. This definition is repeated here for the reader's convenience. Please note that the definition is completely protocol-version agnostic (most of this section applies to IPv6 in the same way as to IPv4).
[RFC6192]ルータコントロールプレーンを定義し、IPv4ネットワークとIPv6ネットワーク用に固定するための詳細なガイダンスを提供します。この定義は読者の利便性についてここで繰り返されます。定義は完全にプロトコルバージョンのagnosticです（このセクションのほとんどはIPv4と同じ方法でIPv6に適用されます）。
| Preamble: IPv6 control plane security is vastly congruent with
| its IPv4 equivalent, with the exception of OSPFv3
| authentication (Section 2.4.1) and some packet exceptions (see
| Section 2.4.3) that are specific to IPv6.
Modern router architecture design maintains a strict separation of forwarding and router control plane hardware and software. The router control plane supports routing and management functions. It is generally described as the router architecture hardware and software components for handling packets destined to the device itself as well as building and sending packets originated locally on the device. The forwarding plane is typically described as the router architecture hardware and software components responsible for receiving a packet on an incoming interface, performing a lookup to identify the packet's IP next hop and best outgoing interface towards the destination, and forwarding the packet through the appropriate outgoing interface.
現代のルータアーキテクチャデザインは、転送とルータの制御プレーンハードウェアとソフトウェアの厳密な分離を維持しています。ルータコントロールプレーンは、ルーティングおよび管理機能をサポートしています。それは一般的に、装置自体宛てのパケットを処理するためのルータアーキテクチャハードウェアおよびソフトウェアコンポーネントとして説明されており、デバイス上でローカルに発信されたパケットを構築および送信する。転送面は通常、着信インターフェース上のパケットを受信する責任があるルータアーキテクチャハードウェアおよびソフトウェアコンポーネントとして説明され、プロパティのIPネクストホップおよび宛先への最良の発信インターフェースを識別し、適切な発信を通してパケットを転送するためのルックアップを実行します。インターフェース。
While the forwarding plane is usually implemented in high-speed hardware, the control plane is implemented by a generic processor (referred to as the routing processor (RP)) and cannot process packets at a high rate. Hence, this processor can be attacked by flooding its input queue with more packets than it can process. The control plane processor is then unable to process valid control packets and the router can lose IGP or BGP adjacencies, which can cause a severe network disruption.
転送面は通常高速ハードウェアで実装されているが、制御プレーンは一般的なプロセッサ（ルーティングプロセッサ（RP）と呼ばれる）によって実装され、高いレートでパケットを処理することができない。したがって、このプロセッサは、その入力キューを処理できるよりも多くのパケットをフラッディングすることによって攻撃することができます。制御プレーンプロセッサは有効な制御パケットを処理できず、ルータはIGPまたはBGP隣接関係を失う可能性があり、これにより、重大なネットワークの中断が発生する可能性があります。
[RFC6192] provides detailed guidance to protect the router control plane in IPv6 networks. The rest of this section contains simplified guidance.
[RFC6192] IPv6ネットワークのルータコントロールプレーンを保護するための詳細なガイダンスを提供します。このセクションの残りの部分には、単純化されたガイダンスが含まれています。
The mitigation techniques are:
緩和技術は次のとおりです。
* to drop illegitimate or potentially harmful control packets before they are queued to the RP (this can be done by a forwarding plane ACL) and
* RPにキューに入れられる前に違法または潜在的に有害なコントロールパケットを落とすこと（これは転送プレーンACLによって行うことができます）
* to rate-limit the remaining packets to a rate that the RP can sustain. Protocol-specific protection should also be done (for example, a spoofed OSPFv3 packet could trigger the execution of the Dijkstra algorithm; therefore, the frequency of Dijkstra calculations should also be rate limited).
* 残りのパケットをRPが維持できる割合に制限する。プロトコル固有の保護も実行する必要があります（たとえば、偽装されたOSPFv3パケットはDijkstraアルゴリズムの実行をトリガーする可能性があります。したがって、Dijkstra計算の周波数もレート制限）。
This section will consider several classes of control packets:
このセクションでは、いくつかのクラスのコントロールパケットについて検討します。
Control protocols: routing protocols, such as OSPFv3, BGP, Routing Information Protocol Next Generation (RIPng), and, by extension, NDP and ICMP
制御プロトコル：OSPFv3、BGP、ルーティング情報プロトコル（RIPNG）、および拡張子、NDP、ICMPによるルーティングプロトコル
Management protocols: Secure Shell (SSH), SNMP, Network Configuration Protocol (NETCONF), RESTCONF, IP Flow Information Export (IPFIX), etc.
管理プロトコル：Secure Shell（SSH）、SNMP、ネットワーク構成プロトコル（NETCONF）、RESTCONF、IPフロー情報エクスポート（IPFIX）など
Packet exceptions: normal data packets that require a specific processing, such as generating a packet-too-big ICMP message or processing the hop-by-hop options header
パケットの例外：パケット - ビッグICMPメッセージの生成やホップバイホップオプションヘッダの処理など、特定の処理を必要とする通常のデータパケット
This class includes OSPFv3, BGP, NDP, and ICMP.
このクラスには、OSPFv3、BGP、NDP、およびICMPが含まれています。
An ingress ACL to be applied on all the router interfaces for packets to be processed by the RP should be configured to:
RPによって処理されるパケットのすべてのルータインターフェイスに適用される入力ACLは、次のように構成されています。
* drop OSPFv3 (identified by Next-Header being 89) and RIPng (identified by UDP port 521) packets from a non-link-local address (except for OSPFv3 virtual links)
* link-localアドレスからのospfv3（Next-Headerである89）とRIPNG（UDPポート521によって識別されます）パケット（OSPFv3仮想リンクを除く）
* allow BGP (identified by TCP port 179) packets from all BGP neighbors and drop the others
* BGP（TCPポート179によって識別された）すべてのBGPネイバーからのパケットを許可し、他のものをドロップする
* allow all ICMP packets (transit and to the router interfaces)
* すべてのICMPパケット（TransitとRouter Interfaces）を許可する
Note: Dropping OSPFv3 packets that are authenticated by IPsec could be impossible on some routers that are unable to parse the IPsec ESP or AH extension headers during ACL classification.
注：IPsecによって認証されているOSPFv3パケットのドロップは、ACL分類中にIPsec ESPまたはAH拡張ヘッダーを解析できないいくつかのルーターでは不可能になる可能性があります。
Rate-limiting of the valid packets should be done; see [RFC8541] for a side benefit for OSPv3. The exact configuration will depend on the available resources of the router (CPU, Ternary Content-Addressable Memory (TCAM), etc.).
有効なパケットのレート制限を行う必要があります。OSPv3のサイドメモリーについては[RFC8541]を参照してください。正確な設定は、ルータの利用可能なリソース（CPU、3中間コンテンツアドレス指定可能メモリ（TCAMなど）によって異なります。
This class includes SSH, SNMP, RESTCONF, NETCONF, gRPC Remote Procedure Calls (gRPC), syslog, NTP, etc.
このクラスには、SSH、SNMP、RESTCONF、NETCONF、GRPCリモートプロシージャコール（GRPC）、SYSLOG、NTPなどが含まれています。
An ingress ACL to be applied on all the router interfaces (or at ingress interfaces of the security perimeter or by using specific features of the platform) should be configured for packets destined to the RP, such as:
すべてのルータインターフェイス（またはセキュリティ周辺の入力インタフェースまたはプラットフォームの特定の機能を使用して）に適用される入力ACLは、次のようなRP宛てのパケットに対して設定する必要があります。
* drop packets destined to the routers, except those belonging to protocols that are used (for example, permit TCP 22 and drop all others when only SSH is used) and
* 使用されるプロトコルに属するものを除くルータ宛てのドロップパケットをドロップします（たとえば、TCP 22を許可し、SSHのみ使用されている場合は他のすべてのものをドロップします）。
* drop packets where the source does not match the security policy (for example, if SSH connections should only be originated from the Network Operation Center (NOC), then the ACL should permit TCP port 22 packets only from the NOC prefix).
* ソースがセキュリティポリシーと一致しないパケットをドロップします（たとえば、SSH接続がネットワークオペレーションセンター（NOCからのみ発信される場合）、ACLはTCPポート22のパケットをNOCプレフィックスからのみパケット）を許可する必要があります。
Rate-limiting of valid packets should be done. The exact configuration will depend on the available router resources.
有効なパケットのレート制限を行う必要があります。正確な設定は、利用可能なルータリソースによって異なります。
This class covers multiple cases where a data plane packet is punted to the route processor because it requires specific processing:
このクラスは、データプレーンパケットが特定の処理を必要とするため、データプレーンパケットがルートプロセッサにパントされている複数のケースをカバーしています。
* generation of an ICMP packet-too-big message when a data plane packet cannot be forwarded because it is too large (required to discover the Path MTU);
* データプレーンパケットが大きすぎるため転送できない場合（パスMTUを発見するには必要とする）場合のICMPパケット - ビッグメッセージの生成。
* generation of an ICMP hop-limit-expired message when a data plane packet cannot be forwarded because its hop-limit field has reached 0 (also used by the traceroute utility);
* データプレーンパケットが転送できない場合のICMPホップ制限期限切れメッセージ（Tracerouteユーティリティによっても使用されます）。
* generation of an ICMP destination-unreachable message when a data plane packet cannot be forwarded for any reason;
* データプレーンパケットが何らかの理由で転送できない場合のICMP宛先 - 到達不能メッセージの生成。
* processing of the hop-by-hop options header; new implementations follow Section 4.3 of [RFC8200] where this processing is optional; or
* ホップバイホップオプションヘッダの処理。この処理がオプションである[RFC8200]のセクション4.3の新しい実装に従う。また
* more specific to some router implementations, an oversized extension header chain that cannot be processed by the hardware and cannot force the packet to be punted to the RP.
* いくつかのルータの実装に具体的には、ハードウェアによって処理できず、パケットをRPに強制的に強制することができない特大拡張ヘッダーチェーン。
On some routers, not everything can be done by the specialized data plane hardware that requires some packets to be 'punted' to the generic RP. This could include, for example, the processing of a long extension header chain in order to apply an ACL based on Layer 4 information. [RFC6980] and more generally [RFC7112] highlight the security implications of oversized extension header chains on routers and update the original IPv6 specifications [RFC2460] such that the first fragment of a packet is required to contain the entire IPv6 header chain. Those changes are incorporated in the IPv6 standard [RFC8200].
いくつかのルータでは、いくつかのパケットを一般的なRPに「パントされた」と必要とする特殊なデータプレーンハードウェアによってすべてが行われることができます。これは、例えば、レイヤ4情報に基づいてACLを適用するために、長い拡張ヘッダチェーンの処理を含むことができる。[RFC6980]およびより一般的に[RFC7112]ルータ上の特大拡張ヘッダーチェーンのセキュリティの影響を強調し、オリジナルのIPv6仕様[RFC2460]を更新し、パケットの最初のフラグメントがIPv6ヘッダーチェーン全体を含むことが必要です。これらの変更はIPv6規格[RFC8200]に組み込まれています。
An ingress ACL cannot mitigate a control plane attack using these packet exceptions. The only protection for the RP is to rate-limit those packet exceptions that are forwarded to the RP. This means that some data plane packets will be dropped without an ICMP message sent to the source, which may delay Path MTU Discovery and cause drops.
入力ACLは、これらのパケット例外を使用してコントロールプレーン攻撃を軽減できません。RPの唯一の保護は、RPに転送されるパケットの例外をRate-制限することです。これは、ICMPメッセージが送信元に送信されずに一部のデータプレーンパケットがドロップされ、パスMTUの検出と原因が遅れる可能性があります。
In addition to limiting the rate of data plane packets queued to the RP, it is also important to rate-limit the generation of ICMP messages. This is important both to preserve RP resources and also to prevent an amplification attack using the router as a reflector. It is worth noting that some platforms implement this rate-limiting in hardware. Of course, a consequence of not generating an ICMP message will break some IPv6 mechanisms, such as Path MTU Discovery or a simple traceroute.
RPにキューに入れられたデータプレーンパケットのレートを制限することに加えて、ICMPメッセージの生成を率を制限することも重要です。これは、RPリソースを保存し、またリフレクタとしてルータを使用した増幅攻撃を防ぐためにも重要です。一部のプラットフォームがハードウェアでこのレート制限を実装することは注目に値します。もちろん、ICMPメッセージを生成していないという結果は、PATH MTUの検出や単純なTracerouteなどのIPv6メカニズムを破るでしょう。
| Preamble: IPv6 routing security is congruent with IPv4 routing
| security, with the exception of OSPv3 neighbor authentication
| (see Section 2.5.2).
Routing security in general can be broadly divided into three sections:
一般的なルーティングセキュリティは、3つのセクションに広く分けられます。
1. authenticating neighbors/peers
1. 隣人/仲間の認証
2. securing routing updates between peers
2. ピア間のルーティング更新を確保する
3. route filtering
3. ルートフィルタリング
[RFC5082] is also applicable to IPv6 and can ensure that routing protocol packets are coming from the local network; it must also be noted that in IPv6 all interior gateway protocols use link-local addresses.
[RFC5082]はIPv6にも適用され、ルーティングプロトコルパケットがローカルネットワークから来ていることを確認できます。IPv6では、すべてのインテリアゲートウェイプロトコルがリンクローカルアドレスを使用することに注意してください。
As for IPv4, it is recommended to enable a routing protocol only on interfaces where it is required.
IPv4に関しては、それが必要なインターフェイス上でのみルーティングプロトコルを有効にすることをお勧めします。
As BGP is identical for IPv4 and IPv6 and as [RFC7454] covers all the security aspects for BGP in detail, [RFC7454] is also applicable to IPv6.
BGPがIPv4とIPv6と同じで、[RFC7454]は、BGPのすべてのセキュリティ側面を詳細に説明しています。[RFC7454]はIPv6にも適用されます。
OSPFv3 can rely on IPsec to fulfill the authentication function. Operators should note that IPsec support is not standard on all routing platforms. In some cases, this requires specialized hardware that offloads crypto over to dedicated Application-Specific Integrated Circuits (ASICs) or enhanced software images (both of which often come with added financial cost) to provide such functionality. An added detail is to determine whether OSPFv3 IPsec implementations use AH or ESP-NULL for integrity protection. In early implementations, all OSPFv3 IPsec configurations relied on AH since the details weren't specified in [RFC5340]. However, the document that specifically describes how IPsec should be implemented for OSPFv3 [RFC4552] states that "implementations MUST support ESP[- NULL] and MAY support AH" since it follows the overall IPsec standards wording. OSPFv3 can also use normal ESP to encrypt the OSPFv3 payload to provide confidentiality for the routing information.
OSPFv3は認証機能を満たすためにIPsecに頼ることができます。演算子は、IPsecサポートがすべてのルーティングプラットフォームで標準ではないことに注意してください。場合によっては、この機能を提供するために、専用のアプリケーション固有の集積回路（ASIC）または強化ソフトウェアイメージに暗号化をオフロードする特別なハードウェアが必要です。詳細は、ospfv3 ipsec実装が整合性保護のためにAHまたはESP-NULLを使用するかどうかを判断することです。初期の実装では、[RFC5340]で詳細が指定されていないため、すべてのOSPFv3 IPsec構成がAHに依存していました。ただし、OSPFv3 [RFC4552]にIPSecを実装する方法を具体的に説明する文書は、「実装はESP [ - NULLをサポートし、AHをサポートし、AHをサポートしています。）は、全体的なIPSec規格の表現に従っています。OSPFv3は、通常のESPを使用してOSPFv3ペイロードを暗号化してルーティング情報の機密性を提供することもできます。
[RFC7166] changes OSPFv3 reliance on IPsec by appending an authentication trailer to the end of the OSPFv3 packets. It does not authenticate the specific originator of an OSPFv3 packet; rather, it allows a router to confirm that the packet has been issued by a router that had access to the shared authentication key.
[RFC7166] OSPFv3パケットの末尾に認証トレーラーを追加することで、IPSecにospfv3依存を変更します。OSPFv3パケットの特定の発信者を認証しません。むしろ、それは、共有認証キーにアクセスしたルータによってパケットが発行されたことをルータが確認することを可能にする。
With all authentication mechanisms, operators should confirm that implementations can support rekeying mechanisms that do not cause outages. There have been instances where any rekeying causes outages; therefore, the trade-off between utilizing this functionality needs to be weighed against the protection it provides. [RFC4107] documents some guidelines for crypto keys management.
すべての認証メカニズムを使用すると、演算子は、停止しないで実装が再確認メカニズムをサポートできることを確認する必要があります。Rekeyingが停止を引き起こす場合がありました。したがって、この機能を利用している間のトレードオフは、それが提供する保護に対して秤量する必要があります。[RFC4107]暗号鍵管理のためのいくつかのガイドライン。
IPv6 initially mandated the provisioning of IPsec capability in all nodes. However, in the updated IPv6 Nodes Requirement standard [RFC8504], IPsec is a 'SHOULD' and not a 'MUST' implementation. Theoretically, it is possible that all communication between two IPv6 nodes, especially routers exchanging routing information, is encrypted using IPsec. However, in practice, deploying IPsec is not always feasible given hardware and software limitations of the various platforms deployed.
IPv6は最初はすべてのノードでIPsec機能のプロビジョニングを義務付けました。ただし、更新されたIPv6ノードの要件標準[RFC8504]では、IPsecは「必須」の実装ではありません。理論的には、2つのIPv6ノード間のすべての通信、特にルーティング情報を交換するルータは、IPSecを使用して暗号化されている可能性があります。ただし、実際には、IPSecをデプロイすることは、展開されたさまざまなプラットフォームのハードウェアとソフトウェアの制限が与えられた場合は、必ずしも実行可能ではありません。
Many routing protocols support the use of cryptography to protect the routing updates; the use of this protection is recommended. [RFC8177] is a YANG data model for key chains that includes rekeying functionality.
ルーティング更新を保護するための暗号化の使用をサポートしています。この保護の使用をお勧めします。[RFC8177]は、機能を取り除くことを含むキーチェーンのYangデータモデルです。
Route filtering policies will be different depending on whether they pertain to edge route filtering or internal route filtering. At a minimum, the IPv6 routing policy, as it pertains to routing between different administrative domains, should aim to maintain parity with IPv4 from a policy perspective, for example:
ルートフィルタリングポリシーは、エッジルートフィルタリングまたは内部ルートフィルタリングに関連するかどうかによって異なります。最低限、異なる管理ドメイン間のルーティングに関連するIPv6ルーティングポリシーは、ポリシーの観点からIPv4とパリティを維持することを目的としています。
* filter internal-use IPv6 addresses that are not globally routable at the perimeter;
* 境界線でグローバルにルーティング可能でないIPv6アドレスをフィルタリングします。
* discard routes for bogon [CYMRU] and reserved space (see [RFC8190]); and
* Bogon [Cymru]と予約スペースの廃棄ルートを廃棄します（[RFC8190]参照）。と
* configure ingress route filters that validate route origin, prefix ownership, etc., through the use of various routing databases, e.g., [RADB]. [RFC8210] formally validates the origin Autonomous Systems (ASes) of BGP announcements.
* ルートの原点、プレフィックスの所有権などを検証する入力ルートフィルタを、さまざまなルーティングデータベース、例えば[RADB]を使用して設定します。[RFC8210] BGPアナウンスメントの起源自律システム（ASES）を正式に検証します。
Some good guidance can be found at [RFC7454].
[RFC7454]にはいくつかの良いガイダンスがあります。
A valid routing table can also be used to apply network ingress filtering (see [RFC2827]).
有効なルーティングテーブルを使用してネットワーク入力フィルタリングを適用することもできます（[RFC2827]参照）。
In order to perform forensic research in the cases of a security incident or detecting abnormal behavior, network operators should log multiple pieces of information. In some cases, this requires a frequent poll of devices via a Network Management Station.
セキュリティの事件の場合や異常な行動の検出の場合に法医学的研究を行うためには、ネットワーク事業者は複数の情報を記録する必要があります。場合によっては、これにはネットワーク管理ステーションを介してデバイスの頻繁なポーリングが必要です。
This logging should include but is not limited to:
このロギングには含まれるべきですが、これらに限定されません。
* logs of all applications using the network (including user space and kernel space) when available (for example, web servers that the network operator manages);
* 利用可能なときにネットワーク（ユーザスペースとカーネルスペースを含む）を使用しているすべてのアプリケーションのログ（例えば、ネットワークオペレータが管理するWebサーバ）。
* data from IP Flow Information Export [RFC7011], also known as IPFIX;
* IPFフロー情報エクスポート[RFC7011]からのデータもIPFIXとも呼ばれます。
* data from various SNMP MIBs [RFC4293] or YANG data via RESTCONF [RFC8040] or NETCONF [RFC6241];
* RESTCONF [RFC8040]またはNETCONF [RFC6241]を介した様々なSNMP MIBS [RFC4293]またはYANGデータのデータ。
* historical data of Neighbor Cache entries;
* ネイバーキャッシュエントリの履歴データ
* stateful DHCPv6 [RFC8415] lease cache, especially when a relay agent [RFC6221] is used;
* ステートフルDHCPv6 [RFC8415]特に中継エージェント[RFC6221]を使用した場合のリースキャッシュ。
* Source Address Validation Improvement (SAVI) [RFC7039] events, especially the binding of an IPv6 address to a MAC address and a specific switch or router interface;
* 送信元アドレス検証改善（SAVI）[RFC7039]イベント、特にIPv6アドレスのMACアドレスと特定のスイッチまたはルータインタフェースへのバインディング。
* firewall ACL logs;
* ファイアウォールACLログ。
* authentication server logs; and
* 認証サーバーのログと
* RADIUS [RFC2866] accounting records.
* RADIUS [RFC2866]会計レコード。
Please note that there are privacy issues or regulations related to how these logs are collected, stored, used, and safely discarded. Operators are urged to check their country legislation (e.g., General Data Protection Regulation [GDPR] in the European Union).
これらのログがどのように収集され、保存、使用、および安全に破棄されるかに関するプライバシーの問題または規制があります。オペレータは、欧州連合における国法（例えば、一般的なデータ保護規制[GDPR]）をチェックするよう促されています。
All those pieces of information can be used for:
これらの情報をすべて使用できます。
* forensic (Section 2.6.2.1) investigations: who did what and when?
* Forensic（セクション2.6.2.1）調査：いつ何をしたのですか。
* correlation (Section 2.6.2.3): which IP addresses were used by a specific node (assuming the use of privacy extensions addresses [RFC8981])?
* 相関（セクション2.6.2.3）：特定のノードで使用されたIPアドレスが使用された（Privacy Extensionsのアドレスの使用を想定して[RFC8981]）。
* inventory (Section 2.6.2.2): which IPv6 nodes are on my network?
* インベントリ（2.6.2.2項）：ネットワーク上にどのIPv6ノードがありますか？
* abnormal behavior detection (Section 2.6.2.4): unusual traffic patterns are often the symptoms of an abnormal behavior, which is in turn a potential attack (denial of service, network scan, a node being part of a botnet, etc.).
* 異常挙動検出（2.6.2.4項）：異常なトラフィックパターンは、潜在的な攻撃（サービス拒否、ネットワークスキャン、ボットネットの一部であるノードなど）の症状が多い。
This section lists the most important sources of data that are useful for operational security.
このセクションでは、運用セキュリティに役立つ最も重要なデータ源を示します。
Those logs are usually text files where the remote IPv6 address is stored in cleartext (not binary). This can complicate the processing since one IPv6 address, for example, 2001:db8::1, can be written in multiple ways, such as:
これらのログは通常、リモートIPv6アドレスがClearTextに格納されているテキストファイルです（バイナリではありません）。1つのIPv6アドレス（たとえば、2001：DB8 :: 1）が次のような複数の方法で書くことができるため、これは処理を複雑にすることができます。
* 2001:DB8::1 (in uppercase),
* 2001：DB8 :: 1（大文字で）
* 2001:0db8::0001 (with leading 0), and
* many other ways, including the reverse DNS mapping into a Fully Qualified Domain Name (FQDN) (which should not be trusted).
* 逆DNSマッピングを完全修飾ドメイン名（FQDN）に含める他の多くの方法（信頼できるものはありません）。
[RFC5952] explains this problem in detail and recommends the use of a single canonical format. This document recommends the use of canonical format [RFC5952] for IPv6 addresses in all possible cases. If the existing application cannot log using the canonical format, then it is recommended to use an external post-processing program in order to canonicalize all IPv6 addresses.
[RFC5952]この問題について詳しく説明し、単一の標準形式を使用することをお勧めします。このドキュメントでは、すべての可能な場合にIPv6アドレスのための正規形式[RFC5952]を使用することをお勧めします。既存のアプリケーションが正規フォーマットを使用してログに記録できない場合は、すべてのIPv6アドレスを正確化するために外部後処理プログラムを使用することをお勧めします。
IPFIX [RFC7012] defines some data elements that are useful for security:
IPFIX [RFC7012]セキュリティに役立ついくつかのデータ要素を定義します。
* nextHeaderIPv6, sourceIPv6Address, and destinationIPv6Address
* NexTheaderIPv6、SourceIPv6Address、およびDestinationIPv6Address.
* sourceMacAddress and destinationMacAddress
* SourceMacaddressとDestinationMacaddress.
The IP version is the ipVersion element defined in [IANA-IPFIX].
IPバージョンは[IANA-IPFIX]で定義されているIPVersion要素です。
Moreover, IPFIX is very efficient in terms of data handling and transport. It can also aggregate flows by a key, such as sourceMacAddress, in order to have aggregated data associated with a specific sourceMacAddress. This memo recommends the use of IPFIX and aggregation on nextHeaderIPv6, sourceIPv6Address, and sourceMacAddress.
さらに、IPFIXはデータ処理とトランスポートの点で非常に効率的です。特定のSourceMacAddressに関連付けられている集計データを持つために、SourceMacAddressなどのキーによってフローを集計することもできます。このメモは、NexTheaderIPv6、SourceIpv6Address、およびSourceMacAddressでIPFIXと集約を使用することを推奨します。
2.6.1.3. SNMP MIB and NETCONF/RESTCONF YANG Modules Data by IPv6 Routers
2.6.1.3. IPv6ルータによるSNMP MIBとNETCONF / RETCONF YANGモジュールデータ
[RFC4293] defines a Management Information Base (MIB) for the two address families of IP. This memo recommends the use of:
[RFC4293] IPの2つのアドレスファミリーの管理情報ベース（MIB）を定義します。このメモは以下の使用を推奨しています。
* ipIfStatsTable table, which collects traffic counters per interface, and
* IPIFStattableテーブル。インターフェイスごとにトラフィックカウンタを収集します。
* ipNetToPhysicalTable table, which is the content of the Neighbor Cache, i.e., the mapping between IPv6 and data-link layer addresses.
* IpnetTophysicalTableテーブル。隣接キャッシュの内容、すなわちIPv6とデータリンク層アドレス間のマッピングである。
There are also YANG modules relating to the two IP address families and that can be used with [RFC6241] and [RFC8040]. This memo recommends the use of:
2つのIPアドレスファミリに関連するYANGモジュールもあり、[RFC6241]と[RFC8040]で使用できます。このメモは以下の使用を推奨しています。
* interfaces-state/interface/statistics from ietf-interfaces@2018-02-20.yang [RFC8343], which contains counters for interfaces, and
* インターフェース - IETF-interfaces @ 2018-02-20.yang [RFC8343]の統計/統計情報。
* ipv6/neighbor from ietf-ip@2018-02-22.yang [RFC8344], which is the content of the Neighbor Cache, i.e., the mapping between IPv6 and data-link layer addresses.
* IETF-IP @ 2018-02-22.yang [RFC8344]からのIPv6 / neights。これは、隣接キャッシュの内容、すなわちIPv6とデータリンクレイヤアドレスの間のマッピングです。
The Neighbor Cache of routers contains all mappings between IPv6 addresses and data-link layer addresses. There are multiple ways to collect the current entries in the Neighbor Cache, notably, but not limited to:
ルータの隣接キャッシュには、IPv6アドレスとデータリンクレイヤアドレス間のすべてのマッピングが含まれています。隣接キャッシュ内の現在のエントリを収集する方法が複数ありますが、これに限定されません。
* using the SNMP MIB (Section 2.6.1.3), as explained above;
* 上述したように、SNMP MIB（2.6.1.3項）を使用する。
* using streaming telemetry or NETCONF [RFC6241] and RESTCONF [RFC8040] to collect the operational state of the Neighbor Cache; and
* 隣接キャッシュの動作状態を収集するには、ストリーミングテレメトリまたはNetConf [RFC6241]とRESTCONF [RFC8040]を使用します。と
* connecting over a secure management channel (such as SSH) and explicitly requesting a Neighbor Cache dump via the Command-Line Interface (CLI) or another monitoring mechanism.
* セキュア管理チャネル（SSHなど）を介して接続し、コマンドラインインターフェイス（CLI）または他の監視メカニズムを介してネイバーキャッシュダンプを明示的に要求します。
The Neighbor Cache is highly dynamic, as mappings are added when a new IPv6 address appears on the network. This could be quite frequently with privacy extension addresses [RFC8981] or when they are removed when the state goes from UNREACH to removed (the default time for a removal per Neighbor Unreachability Detection [RFC4861] algorithm is 38 seconds for a host using Windows 7). This means that the content of the Neighbor Cache must be fetched periodically at an interval that does not exhaust the router resources and still provides valuable information (the suggested value is 30 seconds, but this should be verified in the actual deployment) and stored for later use.
マッピングがネットワーク上に表示されたときにマッピングが追加されるため、ネイバーキャッシュは非常に動的です。これはプライバシー拡張アドレスでかなり頻繁に存在する可能性があります（RFC8981]（RFC8981]、またはUnreachから削除されたときに削除されたときに削除されたとき（Windows 7を使用したホストのデフォルトの時間は38秒です）。つまり、ルータのリソースを使い果たさない間隔で隣接キャッシュの内容を定期的にフェッチする必要があり、依然として貴重な情報が30秒ですが、これは実際の展開で検証され、後で保存されます。使用する。
This is an important source of information because it is trivial (on a switch not using the SAVI [RFC7039] algorithm) to defeat the mapping between data-link layer address and an IPv6 address. Put another way, having access to the current and past content of the Neighbor Cache has a paramount value for the forensic and audit trails. It should also be noted that, in certain threat models, this information is also deemed valuable and could itself be a target.
データリンク層アドレスとIPv6アドレスの間のマッピングを無効にするために（Savi [RFC7039]アルゴリズムを使用していないスイッチ）であるため、これは重要な情報源です。隣接キャッシュの現在および過去の内容にアクセスする別の方法で、フォレンジックおよび監査証跡のパラマウント値があります。また、特定の脅威モデルでは、この情報も貴重であると見なされ、それ自体がターゲットになる可能性があることに注意してください。
When using one /64 per host (Section 2.1.8) or DHCP-PD, it is sufficient to keep the history of the allocated prefixes when combined with strict source address prefix enforcement on the routers and L2 switches to prevent IPv6 spoofing.
ホストごとに1/64（セクション2.1.8）またはDHCP-PDを使用する場合は、ルータおよびL2スイッチの厳密なソースアドレスプレフィックスの適用と組み合わせると、割り当てられたプレフィックスの履歴を保持して、IPv6スプーフィングを防ぐのに十分です。
In some networks, IPv6 addresses/prefixes are managed by a stateful DHCPv6 server [RFC8415] that leases IPv6 addresses/prefixes to clients. It is indeed quite similar to DHCP for IPv4, so it can be tempting to use this DHCP lease file to discover the mapping between IPv6 addresses/prefixes and data-link layer addresses, as is commonly used in IPv4 networking.
一部のネットワークでは、IPv6アドレス/プレフィックスは、IPv6アドレス/プレフィックスをクライアントにリースするステートフルDHCPv6サーバー[RFC8415]によって管理されます。IPv4ネットワークで一般的に使用されているように、このDHCPリースファイルを使用して、このDHCPリースファイルを使用して、IPv4ネットワーキングで一般的に使用されているように、このDHCPリースファイルを使用することを魅力的である可能性があります。
It is not so easy in the IPv6 networks, because not all nodes will use DHCPv6 (there are nodes that can only do stateless autoconfiguration) and also because DHCPv6 clients are identified not by their hardware-client address, as in IPv4, but by a DHCP Unique Identifier (DUID). The DUID can have several formats: the data-link layer address, the data-link layer address prepended with time information, or even an opaque number that requires correlation with another data source to be usable for operational security. Moreover, when the DUID is based on the data-link address, this address can be of any client interface (such as the wireless interface, while the client actually uses its wired interface to connect to the network).
IPv6ネットワークではそれほど簡単ではありません。すべてのノードがDHCPv6を使用するわけではありません（ステートレス自動設定のみを実行できるノードがあります）、またIPv4のように、DHCPv6クライアントがハードウェアクライアントアドレスではなく、DHCP一意の識別子（DUID）。DUIDには、データリンク層アドレス、データリンク層アドレス、時間情報が付いているデータリンク層アドレス、あるいは動作セキュリティのために使用可能になる別のデータソースとの相関が必要な不透明な数でさえあります。さらに、DUIDがデータリンクアドレスに基づいている場合、このアドレスは任意のクライアントインターフェース（ワイヤレスインタフェースなど、実際には実際に有線インタフェースをネットワークに接続する）であり得る。
If a lightweight DHCP relay agent [RFC6221] is used in a L2 switch, then the DHCP servers also receive the interface ID information, which could be saved in order to identify the interface on which the switch received a specific leased IPv6 address. Also, if a 'normal' (not lightweight) relay agent adds the data-link layer address in the option for Relay Agent Remote-ID [RFC4649] [RFC6939], then the DHCPv6 server can keep track of the data-link and leased IPv6 addresses.
L2スイッチで軽量DHCPリレーエージェント[RFC6221]が使用されている場合、DHCPサーバーはインターフェイスID情報を受信します。これは、スイッチが特定のリースIPv6アドレスを受信したインターフェイスを識別するために保存できます。また、「通常の」（軽量ではない）リレーエージェントが、リレーエージェントのリモートID [RFC4649] [RFC4649] [RFC6939]のオプションでデータリンクレイヤアドレスを追加した場合、DHCPv6サーバーはデータリンクを追跡してリースされています。IPv6アドレス。
In short, the DHCPv6 lease file is less interesting than lease files for IPv4 networks. If possible, it is recommended to use DHCPv6 servers that keep the relayed data-link layer address in addition to the DUID in the lease file, as those servers have the equivalent information to IPv4 DHCP servers.
つまり、DHCPv6リースファイルは、IPv4ネットワーク用のリースファイルよりもおもしろいです。可能であれば、リースファイル内のDUIDに加えて中継データリンク層アドレスを保持するDHCPv6サーバーを使用することをお勧めします。これらのサーバーはIPv4 DHCPサーバーと同等の情報を持っています。
The mapping between the data-link layer address and the IPv6 address can be secured by deploying switches implementing the SAVI [RFC7513] mechanisms. Of course, this also requires that the data-link layer address be protected by using a L2 mechanism, such as [IEEE-802.1X].
データリンク層アドレスとIPv6アドレスとの間のマッピングは、SAVI [RFC7513]メカニズムを実装するスイッチを展開することによって保護することができます。もちろん、これはまた、[IEEE-802.1x]のようなL2機構を使用してデータリンク層アドレスを保護する必要がある。
For interfaces where the user is authenticated via a RADIUS [RFC2866] server, and if RADIUS accounting is enabled, then the RADIUS server receives accounting Acct-Status-Type records at the start and at the end of the connection, which include all IPv6 (and IPv4) addresses used by the user. This technique can be used notably for Wi-Fi networks with Wi-Fi Protected Access (WPA) or other IEEE 802.1X [IEEE-802.1X] wired interfaces on an Ethernet switch.
RADIUS [RFC2866]サーバーを介してユーザーが認証されているインターフェイスの場合は、RADIUS Accountingが有効になっている場合、RADIUSサーバーは、すべてのIPv6を含む接続の開始および最後にあるアカウンティングacct-status-typeレコードを受け取ります。ユーザーが使用するアドレスとIPv4）アドレス。この技術は、Wi-Fi保護アクセス（WPA）または他のIEEE 802.1X [IEEE-802.1X]のWired NetworksがイーサネットスイッチのWi-Fiネットワークに使用できます。
There are other data sources for log information that must be collected (as currently collected in IPv4 networks):
収集する必要があるログ情報のための他のデータソースがあります（現在IPv4ネットワークで収集されている）。
* historical mappings of IPv6 addresses to users of remote access VPN and
* リモートアクセスVPNのユーザーへのIPv6アドレスの履歴マッピング
* historical mappings of MAC addresses to switch ports in a wired network.
* 有線ネットワーク内のポートを切り替えるためのMACアドレスの履歴マッピング。
This section leverages the data collected, as described in Section 2.6.1, in order to achieve several security benefits. Section 9.1 of [RFC7934] contains more details about host tracking.
このセクションは、セクション2.6.1で説明されているように、いくつかのセキュリティ上の利点を達成するために、収集されたデータを活用します。[RFC7934]のセクション9.1には、ホスト追跡に関する詳細が含まれています。
The forensic use case is when the network operator must locate an IPv6 address (and the associated port, access point/switch, or VPN tunnel) that was present in the network at a certain time or is currently in the network.
法医学的ユースケースは、ネットワーク事業者がネットワーク内に存在していたIPv6アドレス（および関連するポート、アクセスポイント/スイッチ、またはVPNトンネル）を特定の時間に見つけなければならないか、現在ネットワーク内にある場合です。
To locate an IPv6 address in an enterprise network where the operator has control over all resources, the source of information can be the Neighbor Cache, or, if not found, the DHCP lease file. Then, the procedure is:
オペレータがすべてのリソースを制御しているエンタープライズネットワーク内のIPv6アドレスを見つけるには、情報のソースはネイバーキャッシュ、または見つからない場合はDHCPリースファイルを作成できます。その後、手順は次のとおりです。
1. based on the IPv6 prefix of the IPv6 address; find one or more routers that are used to reach this prefix (assuming that anti-spoofing mechanisms are used), perhaps based on an IPAM.
1. IPv6アドレスのIPv6プレフィックスに基づく。このプレフィックスに到達するために使用される1つ以上のルーター（スプーフィング防止メカニズムが使用されていると仮定して）、おそらくiPAMに基づいています。
2. based on this limited set of routers, on the incident time, and on the IPv6 address; retrieve the data-link address from the live Neighbor Cache, from the historical Neighbor Cache data, or from SAVI events, or retrieve the data-link address from the DHCP lease file (Section 2.6.1.5).
2. この限られたルータのセットに基づいて、インシデントタイム、およびIPv6アドレスについて。ライブネイバーキャッシュからデータリンクアドレスを、履歴ネイバーキャッシュデータ、またはSAVIイベントから、またはDHCPリースファイルからデータリンクアドレスを取得する（セクション2.6.1.5）。
3. based on the data-link layer address; look up the switch interface associated with the data-link layer address. In the case of wireless LAN with RADIUS accounting (see Section 2.6.1.6), the RADIUS log has the mapping between the user identification and the MAC address. If a Configuration Management Database (CMDB) is used, then it can be used to map the data-link layer address to a switch port.
3. データリンク層アドレスに基づく。データリンクレイヤアドレスに関連付けられているスイッチインターフェイスを調べます。RADIUSアカウンティングを備えた無線LANの場合（セクション2.6.1.6を参照）、RADIUSログには、ユーザー識別とMACアドレスの間のマッピングがあります。構成管理データベース（CMDB）が使用されている場合は、データリンク層アドレスをスイッチポートにマッピングするために使用できます。
At the end of the process, the interface of the host originating or the subscriber identity associated with the activity in question has been determined.
プロセスの最後に、問題のアクティビティに関連するホスト発信元または加入者IDのインターフェースが決定されました。
To identify the subscriber of an IPv6 address in a residential Internet Service Provider, the starting point is the DHCP-PD leased prefix covering the IPv6 address; this prefix can often be linked to a subscriber via the RADIUS log. Alternatively, the Forwarding Information Base (FIB) of the Cable Modem Termination System (CMTS) or Broadband Network Gateway (BNG) indicates the Customer Premises Equipment (CPE) of the subscriber and the RADIUS log can be used to retrieve the actual subscriber.
住宅インターネットサービスプロバイダでIPv6アドレスの加入者を識別するために、開始点はIPv6アドレスをカバーするDHCP-PDリースプレフィックスです。この接頭辞は、RADIUSログを介して加入者にリンクされることがよくあります。あるいは、ケーブルモデム終端システム（CMTS）またはブロードバンドネットワークゲートウェイ（BNG）の転送情報ベース（FIB）は、加入者の顧客宅内機器（CPE）を示し、RADIUSログを使用して実際の加入者を検索することができる。
More generally, a mix of the above techniques can be used in most, if not all, networks.
より一般的には、すべてのネットワークではないにしても、上記の技法の組み合わせをほとんどの場合でも使用することができる。
[RFC7707] describes the difficulties for an attacker to scan an IPv6 network due to the vast number of IPv6 addresses per link (and why in some cases it can still be done). While the huge addressing space can sometimes be perceived as a 'protection', it also makes the inventory task difficult in an IPv6 network while it was trivial to do in an IPv4 network (a simple enumeration of all IPv4 addresses, followed by a ping and a TCP/UDP port scan). Getting an inventory of all connected devices is of prime importance for a secure network operation.
[RFC7707]リンクごとに膨大な数のIPv6アドレスがあるため、攻撃者がIPv6ネットワークをスキャンするのが困難であることを説明しています（そして場合によってはそれがまだ行われることがあるのか）。巨大なアドレス指定スペースは「保護」として認識されることがありますが、IPv4ネットワークではIPv6ネットワークで在庫タスクを困難にします（すべてのIPv4アドレスの簡単な列挙、続いてPINGとそれに続くTCP / UDPポートスキャン）。接続されているすべてのデバイスのインベントリを取得することは、安全なネットワーク操作にとって重要です。
There are many ways to do an inventory of an IPv6 network.
IPv6ネットワークのインベントリを実行する方法はたくさんあります。
The first technique is to use passive inspection, such as IPFIX. Using exported IPFIX information and extracting the list of all IPv6 source addresses allows finding all IPv6 nodes that sent packets through a router. This is very efficient but, alas, will not discover silent nodes that never transmitted packets traversing the IPFIX target router. Also, it must be noted that link-local addresses will never be discovered by this means.
最初の技術は、IPFIXなどのパッシブ検査を使用することです。エクスポートされたIPFIX情報を使用し、すべてのIPv6の送信元アドレスのリストを抽出することで、ルータを介してパケットを送信したすべてのIPv6ノードを見つけることができます。これは非常に効率的ですが、ALAは、IPFIXターゲットルータを横切るパケットを送信したことがないサイレントノードを検出しません。また、リンクローカルアドレスがこの手段によって発見されたことがないことに注意してください。
The second way is again to use the collected Neighbor Cache content to find all IPv6 addresses in the cache. This process will also discover all link-local addresses. See Section 2.6.1.4.
2番目の方法は、収集されたネイバーキャッシュコンテンツを使用して、キャッシュ内のすべてのIPv6アドレスを見つけることです。このプロセスは、すべてのリンクローカルアドレスも検出されます。2.6.1.4項を参照してください。
Another way that works only for a local network consists of sending an ICMP ECHO_REQUEST to the link-local multicast address ff02::1, which addresses all IPv6 nodes on the network. All nodes should reply to this ECHO_REQUEST, per [RFC4443].
ローカルネットワークにのみ機能するもう1つの方法は、ICMP ECHO_REQUESTをリンクローカルマルチキャストアドレスFF02 :: 1に送信することで構成されています。これは、ネットワーク上のすべてのIPv6ノードをアドレス指定します。すべてのノードは、[RFC4443]ごとに、このECHO_REQUESTに返信する必要があります。
Other techniques involve obtaining data from DNS, parsing log files, and leveraging service discovery, such as mDNS [RFC6762] [RFC6763].
その他の技術は、DNS、ログファイルの解析、およびMDNS [RFC6762] [RFC6763]などのサービス検出を活用することを含みます。
Enumerating DNS zones, especially looking at reverse DNS records and CNAMEs, is another common method employed by various tools. As already mentioned in [RFC7707], this allows an attacker to prune the IPv6 reverse DNS tree and hence enumerate it in a feasible time. Furthermore, authoritative servers that allow zone transfers (i.e., Authoritative Transfers (AXFRs)) may be a further information source. An interesting research paper has analyzed the entropy in various IPv6 addresses: see [ENTROPYIP].
特に逆方向DNSレコードとCNAMEを見るDNSゾーンの列挙は、さまざまなツールによって採用されている別の一般的な方法です。[RFC7707]で述べたように、これにより、攻撃者はIPv6の逆DNSツリーを整理し、それ故に実行可能な時間内に列挙します。さらに、ゾーン転送を可能にする権威あるサーバ（すなわち、権威ある転送（AXFR））は、さらなる情報源であり得る。興味深い研究論文は、さまざまなIPv6アドレスのエントロピーを分析しました：[EntropyIP]を参照してください。
In an IPv4 network, it is easy to correlate multiple logs, for example, to find events related to a specific IPv4 address. A simple Unix grep command is enough to scan through multiple text-based files and extract all lines relevant to a specific IPv4 address.
IPv4ネットワークでは、特定のIPv4アドレスに関連するイベントを見つけるために、複数のログを相関させることは簡単です。単純なUNIX grepコマンドは、複数のテキストベースのファイルをスキャンし、特定のIPv4アドレスに関連するすべての行を抽出するのに十分です。
In an IPv6 network, this is slightly more difficult because different character strings can express the same IPv6 address. Therefore, the simple Unix grep command cannot be used. Moreover, an IPv6 node can have multiple IPv6 addresses.
IPv6ネットワークでは、異なる文字列は同じIPv6アドレスを表現できるため、これはわずかに困難です。したがって、単純なUNIX grepコマンドは使用できません。さらに、IPv6ノードは複数のIPv6アドレスを持つことができます。
In order to do correlation in IPv6-related logs, it is advised to have all logs in a format with only canonical IPv6 addresses [RFC5952]. Then, the current (or historical) Neighbor Cache data set must be searched to find the data-link layer address of the IPv6 address. Next, the current and historical Neighbor Cache data sets must be searched for all IPv6 addresses associated with this data-link layer address to derive the search set. The last step is to search in all log files (containing only IPv6 addresses in canonical format) for any IPv6 addresses in the search set.
IPv6関連のログで相関をするために、すべてのログを正規のIPv6アドレスのみの形式でフォーマットにすることをお勧めします[RFC5952]。その後、IPv6アドレスのデータリンクレイヤアドレスを見つけるために、現在の（または履歴）ネイバーキャッシュデータセットを検索する必要があります。次に、このデータリンク層アドレスに関連付けられているすべてのIPv6アドレスについて、現在および履歴側のキャッシュデータセットを検索する必要があります。最後のステップは、検索セット内のIPv6アドレスについて、すべてのログファイル（正規形式のIPv6アドレスのみを含む）で検索することです。
Moreover, [RFC7934] recommends using multiple IPv6 addresses per prefix, so the correlation must also be done among those multiple IPv6 addresses, for example, by discovering all IPv6 addresses associated with the same MAC address and interface in the NDP cache (Section 2.6.1.4).
さらに、[RFC7934]はプレフィックスごとに複数のIPv6アドレスを使用することをお勧めしますので、たとえば、NDPキャッシュ内の同じMACアドレスとインターフェイスに関連付けられているすべてのIPv6アドレスを検出することによって、それらの複数のIPv6アドレスの間でも行わなければなりません（セクション2.6。1.4）。
Abnormal behavior (such as network scanning, spamming, DoS) can be detected in the same way as in an IPv4 network:
異常な動作（ネットワークスキャン、スパム、DOSなど）は、IPv4ネットワークと同じ方法で検出できます。
* a sudden increase of traffic detected by interface counter (SNMP) or by aggregated traffic from IPFIX records [RFC7012],
* インタフェースカウンタ（SNMP）（SNMP）によって検出されたトラフィックの突然の増加、またはIPFIXレコード[RFC7012]からの集約トラフィックによって
* rapid growth of ND cache size, or
* NDキャッシュサイズの急成長、または
* change in traffic pattern (number of connections per second, number of connections per host, etc.) observed with the use of IPFIX [RFC7012].
* IPFIX [RFC7012]を使用して観察されたトラフィックパターンの変更（1秒あたりの接続数、ホストごとの接続数など）。
While some data sources (IPFIX, MIB, switch Content Addressable Memory (CAM) tables, logs, etc.) used in IPv4 are also used in the secure operation of an IPv6 network, the DHCPv6 lease file is less reliable and the Neighbor Cache is of prime importance.
IPv4で使用されているデータソース（IPFIX、MIB、スイッチ内容のアドレス指定可能メモリ（CAM）テーブル、ログなど）もIPv6ネットワークの安全な操作で使用されているが、DHCPv6リースファイルは信頼性が低く、ネイバーキャッシュは主に重要です。
The fact that there are multiple ways to express the same IPv6 address in a character string renders the use of filters mandatory when correlation must be done.
文字列に同じIPv6アドレスを表現する方法が複数あるという事実は、相関が行われなければならない場合にはフィルタの使用を必須にします。
As it is expected that some networks will not run in a pure IPv6-only mode, the different transition mechanisms must be deployed and operated in a secure way. This section proposes operational guidelines for the most-known and deployed transition techniques. [RFC4942] also contains security considerations for transition or coexistence scenarios.
いくつかのネットワークが純粋なIPv6専用モードで実行されないことが予想されるので、異なる遷移メカニズムは安全な方法で展開および操作されなければなりません。このセクションでは、最も既知の展開された遷移技術のための運用上のガイドラインを提案します。[RFC4942]遷移または共存シナリオのセキュリティ上の考慮事項も含まれています。
Dual stack is often the first deployment choice for network operators. Dual stacking the network offers some advantages over other transition mechanisms. Firstly, the impact on existing IPv4 operations is reduced. Secondly, in the absence of tunnels or address translation, the IPv4 and IPv6 traffic are native (easier to observe and secure) and should have the same network processing (network path, quality of service, etc.). Dual stack enables a gradual termination of the IPv4 operations when the IPv6 network is ready for prime time. On the other hand, the operators have to manage two network stacks with the added complexities.
デュアルスタックは、ネットワーク事業者のための最初の展開選択であることがよくあります。デュアルスタッキングネットワークは、他の遷移メカニズムに対していくつかの利点を提供します。まず、既存のIPv4操作への影響が減少します。第二に、トンネルまたはアドレス変換がない場合、IPv4およびIPv6トラフィックはネイティブ（監視して安全な方が簡単です）で、同じネットワーク処理（ネットワークパス、サービス品質など）を持つ必要があります。デュアルスタックは、IPv6ネットワークがプライムタイムの準備ができているときにIPv4操作を徐々に終了することを可能にします。一方、オペレータは追加の複雑さを持つ2つのネットワークスタックを管理する必要があります。
From an operational security perspective, this now means that the network operator has twice the exposure. One needs to think about protecting both protocols now. At a minimum, the IPv6 portion of a dual-stacked network should be consistent with IPv4 from a security policy point of view. Typically, the following methods are employed to protect IPv4 networks at the edge or security perimeter:
運用セキュリティの観点からは、これはネットワークオペレータが露出の2倍の露出を持つことを意味します。今すぐ両方のプロトコルを保護することについて考える必要があります。最低限、デュアルスタックネットワークのIPv6部分は、セキュリティポリシーのビューからIPv4と一致する必要があります。典型的には、エッジまたはセキュリティ境界でIPv4ネットワークを保護するために以下の方法が使用されている。
* ACLs to permit or deny traffic,
* トラフィックを許可または拒否するACL
* firewalls with stateful packet inspection, and
* ステートフルパケット検査を備えたファイアウォール、および
* application firewalls inspecting the application flows.
* アプリケーションのファイアウォールアプリケーションフローを検査します。
It is recommended that these ACLs and/or firewalls be additionally configured to protect IPv6 communications. The enforced IPv6 security must be congruent with the IPv4 security policy; otherwise, the attacker will use the protocol version that has the more relaxed security policy. Maintaining the congruence between security policies can be challenging (especially over time); it is recommended to use a firewall or an ACL manager that is dual stack, i.e., a system that can apply a single ACL entry to a mixed group of IPv4 and IPv6 addresses.
IPv6通信を保護するために、これらのACLおよび/またはファイアウォールを追加構成することをお勧めします。IPv6セキュリティを強制する必要があります.IPv4セキュリティポリシーと一致している必要があります。それ以外の場合、攻撃者は、リラックスしたセキュリティポリシーを持つプロトコルバージョンを使用します。セキュリティポリシー間の合同を維持することは困難になる可能性があります（特に経時的に）。デュアルスタックであるファイアウォールまたはACLマネージャ、すなわち、単一のACLエントリをIPv4およびIPv6アドレスの混合グループに適用できるシステムを使用することをお勧めします。
Application firewalls work at the application layer and are oblivious to the IP version, i.e., they work as well for IPv6 as for IPv4 and the same application security policy will work for both protocol versions.
アプリケーションファイアウォールはアプリケーションレイヤで動作し、IPv6がIPv4の場合と同様に機能するIPv6が動作し、同じアプリケーションセキュリティポリシーが両方のプロトコルバージョンで機能します。
Also, given the end-to-end connectivity that IPv6 provides, it is recommended that hosts be fortified against threats. General device hardening guidelines are provided in Section 2.8.
また、IPv6が提供するエンドツーエンドの接続性を考えると、ホストは脅威に対して強化することをお勧めします。一般的な装置硬化ガイドラインはセクション2.8で提供されています。
For many years, all host operating systems have IPv6 enabled by default, so it is possible even in an 'IPv4-only' network to attack L2-adjacent victims via their IPv6 link-local address or via a global IPv6 address when the attacker provides rogue RAs or a rogue DHCPv6 service.
長年にわたり、すべてのホストオペレーティングシステムにはデフォルトでIPv6が有効になっているため、IPv6リンクローカルアドレスまたは攻撃者が提供するときにグローバルIPv6アドレスを介してL2隣接する被害者を攻撃することが可能です。ローグRASまたは不正なDHCPv6サービス。
[RFC7123] discusses the security implications of native IPv6 support and IPv6 transition/coexistence technologies on 'IPv4-only' networks and describes possible mitigations for the aforementioned issues.
[RFC7123]は、「IPv4専用」ネットワーク上のネイティブIPv6サポートとIPv6遷移/共存技術のセキュリティの意味を説明し、前述の問題について可能な軽減を説明しています。
There are many tunnels used for specific use cases. Except when protected by IPsec [RFC4301] or alternative tunnel encryption methods, all those tunnels have a number of security issues, as described in [RFC6169]:
特定のユースケースに使用されるトンネルがたくさんあります。IPsec [RFC4301]または代替トンネル暗号化メソッドで保護されている場合は、[RFC6169]で説明されているように、これらのトンネルすべてのセキュリティ問題にはいくつかのセキュリティ問題があります。
tunnel injection: A malevolent actor knowing a few pieces of information (for example, the tunnel endpoints and the encapsulation protocol) can forge a packet that looks like a legitimate and valid encapsulated packet that will gladly be accepted by the destination tunnel endpoint. This is a specific case of spoofing.
トンネル注入：いくつかの情報を知っている悪意のある俳優（例えば、トンネルエンドポイントおよびカプセル化プロトコル）は、宛先トンネルエンドポイントによって喜んで受け入れられる正当かつ有効なカプセル化パケットのようなパケットを鍛造することができる。これはスプーフィングの特定のケースです。
traffic interception: No confidentiality is provided by the tunnel protocols (without the use of IPsec or alternative encryption methods); therefore, anybody on the tunnel path can intercept the traffic and have access to the cleartext IPv6 packet. Combined with the absence of authentication, an on-path attack can also be mounted.
交通傍受：トンネルプロトコルによって機密性がありません（IPSecまたは代替暗号化方法を使用せずに）。したがって、トンネルパス上の誰でもトラフィックを傍受し、ClearText IPv6パケットにアクセスできます。認証がないと組み合わせると、オンパス攻撃もマウントできます。
service theft: As there is no authorization, even an unauthorized user can use a tunnel relay for free (this is a specific case of tunnel injection).
サービスの盗難：許可がないため、不正なユーザーでさえ無料でトンネルリレーを使用できます（これは、タンネル注入の特定の場合です）。
reflection attack: Another specific use case of tunnel injection where the attacker injects packets with an IPv4 destination address not matching the IPv6 address causing the first tunnel endpoint to re-encapsulate the packet to the destination. Hence, the final IPv4 destination will not see the original IPv4 address but only the IPv4 address of the relay router.
反射攻撃：攻撃者がIPv4アドレスと一致しないパケットをIPv6アドレスと一致させないパケットをインジェクタに注入して、パケットを宛先に再カプセル化させるトンネルインジェクションの別の特定のユースケース。したがって、最終的なIPv4宛先は元のIPv4アドレスを表示しませんが、リレールータのIPv4アドレスだけです。
bypassing security policy: If a firewall or an Intrusion Prevention System (IPS) is on the path of the tunnel, then it may neither inspect nor detect malevolent IPv6 traffic transmitted over the tunnel.
セキュリティポリシーを迂回する：ファイアウォールまたは侵入防止システム（IPS）がトンネルのパス上にある場合、それはトンネルを介して送信された悪意のあるIPv6トラフィックを検査も検出しない可能性があります。
To mitigate the bypassing of security policies, it is often recommended to block all automatic tunnels in default OS configuration (if they are not required) by denying IPv4 packets matching:
セキュリティポリシーのバイパスを軽減するために、IPv4パケットのマッチングを拒否することで、デフォルトのOS構成（必要ではない場合）ですべての自動トンネルをブロックすることを推奨します。
IP protocol 41: This will block Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (Section 2.7.2.2), 6to4 (Section 2.7.2.7), 6rd (Section 2.7.2.3), and 6in4 (Section 2.7.2.1) tunnels.
IPプロトコル41：これは、サイト内自動トンネルアドレス指定プロトコル（ISATAP）（セクション2.7.2.2）、6to4（セクション2.7.2.7）、6（セクション2.7.2.3）、および6 In4（セクション2.7.2.1）トンネルをブロックします。
IP protocol 47: This will block GRE (Section 2.7.2.1) tunnels.
IPプロトコル47：これはGRE（セクション2.7.2.1）トンネルをブロックします。
UDP port 3544: This will block the default encapsulation of Teredo (Section 2.7.2.8) tunnels.
UDPポート3544：これにより、TEREDO（2.7.2.8）トンネルのデフォルトのカプセル化がブロックされます。
Ingress filtering [RFC2827] should also be applied on all tunnel endpoints, if applicable, to prevent IPv6 address spoofing.
Inpress Filtering [RFC2827]は、IPv6アドレスのスプーフィングを防ぐために、すべてのトンネルエンドポイントにも適用される必要があります。
The reflection attack cited above should also be prevented by using an IPv6 ACL preventing the hair pinning of the traffic.
上記で引用した反射攻撃も、交通の髪のピン止めを防ぐためにIPv6 ACLを使用することで防止する必要があります。
As several of the tunnel techniques share the same encapsulation (i.e., IPv4 protocol 41) and embed the IPv4 address in the IPv6 address, there are a set of well-known looping attacks described in [RFC6324]. This RFC also proposes mitigation techniques.
いくつかのトンネル技術が同じカプセル化（すなわち、IPv4プロトコル41）を共有し、IPv6アドレスにIPv4アドレスを埋め込むので、[RFC6324]に記載されている既知のループ攻撃の一組がある。このRFCはまた緩和技術を提案する。
Site-to-site static tunnels are described in [RFC2529] and in GRE [RFC2784]. As the IPv4 endpoints are statically configured and are not dynamic, they are slightly more secure (bidirectional service theft is mostly impossible), but traffic interception and tunnel injection are still possible. Therefore, the use of IPsec [RFC4301] in transport mode to protect the encapsulated IPv4 packets is recommended for those tunnels. Alternatively, IPsec in tunnel mode can be used to transport IPv6 traffic over an untrusted IPv4 network.
サイト間スタティックトンネルは[RFC2529]およびGRE [RFC2784]に記載されています。IPv4エンドポイントは静的に設定されており、動的ではないので、それらはわずかに安全です（双方向サービスの盗難はほとんど不可能です）、トラフィック遮断とトンネル注入は依然として可能です。したがって、カプセル化されたIPv4パケットを保護するためにトランスポートモードでIPSec [RFC4301]を使用することをお勧めします。あるいは、トンネルモードのIPSecを使用して、信頼できないIPv4ネットワークを介してIPv6トラフィックを転送できます。
ISATAP tunnels [RFC5214] are mainly used within a single administrative domain and to connect a single IPv6 host to the IPv6 network. This often implies that those systems are usually managed by a single entity; therefore, audit trail and strict anti-spoofing are usually possible, and this raises the overall security. Even if ISATAP is no more often used, its security issues are relevant, per [KRISTOFF].
ISATAP TUNNELS [RFC5214]は主に単一の管理ドメイン内で使用され、単一のIPv6ホストをIPv6ネットワークに接続します。これは、それらのシステムが通常単一のエンティティによって管理されることを意味します。したがって、監査証跡と厳格なスプーフィング防止が可能になり、これは全体的なセキュリティを上げます。ISATAPがこれ以上使用されていない場合でも、そのセキュリティ上の問題は[クリストオフ]あたりに関連しています。
Special care must be taken to avoid a looping attack by implementing the measures of [RFC6324] and [RFC6964] (especially in Section 3.6).
[RFC6324]と[RFC6964]（特にセクション3.6）の尺度を実装することで、ループ攻撃を回避するために特別な注意を払う必要があります。
IPsec [RFC4301] in transport or tunnel mode can be used to secure the IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and prevent service theft.
トランスポートまたはトンネルモードのIPSec [RFC4301]は、IPv4のISATAPトラフィックを保護してIPv6トラフィックの機密性を提供し、サービスの盗難を防ぐために使用できます。
While 6rd tunnels share the same encapsulation as 6to4 tunnels (Section 2.7.2.7), they are designed to be used within a single SP domain; in other words, they are deployed in a more constrained environment (e.g., anti-spoofing, protocol 41 filtering at the edge) than 6to4 tunnels and have few security issues other than lack of confidentiality. The security considerations in Section 12 of [RFC5969] describes how to secure 6rd tunnels.
6RDトンネルは6to4トンネルと同じカプセル化を共有します（セクション2.7.2.7）、それらは単一のSPドメイン内で使用されるように設計されています。言い換えれば、それらは、6to4トンネルよりも、より厳密な環境（例えば、スプーフィング防止、エッジでフィルタリングされたプロトコル41）に展開され、機密性の欠如以外のセキュリティ問題がほとんどない。[RFC5969]のセクション12のセキュリティ上の考慮事項は、6番目のトンネルを保護する方法について説明します。
IPsec [RFC4301] for the transported IPv6 traffic can be used if confidentiality is important.
機密性が重要な場合は、輸送されたIPv6トラフィックのIPSec [RFC4301]を使用できます。
Organizations using MPLS in their core can also use IPv6 Provider Edge (6PE) [RFC4798] and IPv6 Virtual Private Extension (6VPE) [RFC4659] to enable IPv6 access over MPLS. As 6PE and 6VPE are really similar to BGP/MPLS IP VPNs described in [RFC4364], the security properties of these networks are also similar to those described in [RFC4381] (please note that this RFC may resemble a published IETF work, but it is not based on an IETF review and the IETF disclaims any knowledge of the fitness of this RFC for any purpose). They rely on:
MPLSを使用した組織は、IPv6 Provider Edge（6pe）[RFC4798]（6pe）[RFC4798]（6VPE）[RFC4659]を使用して、MPLSを介したIPv6アクセスを有効にすることもできます。6PEと6VPEは[RFC4364]で説明されているBGP / MPLS IP VPNと実際に似ていますが、これらのネットワークのセキュリティプロパティも[RFC4381]に記載されているものと同様です（このRFCは公開されたIETFの作業に似ている場合があります。IETFレビューに基づいていないため、IETFは任意の目的のためにこのRFCの適合性に関する知識を否認します）。彼らは頼っています：
* address space, routing, and traffic separation with the help of VRFs (only applicable to 6VPE);
* VRFSの助けを借りてアドレス・スペース、ルーティング、およびトラフィック分離（6VPEにのみ適用されます）。
* hiding the IPv4 core, hence, removing all attacks against P-routers; and
* したがって、IPv4コアを非表示にして、Pルータに対するすべての攻撃を削除します。と
* securing the routing protocol between Customer Edge (CE) and Provider Edge (PE); in the case of 6PE and 6VPE, link-local addresses (see [RFC7404]) can be used, and, as these addresses cannot be reached from outside of the link, the security of 6PE and 6VPE is even higher than an IPv4 BGP/MPLS IP VPN.
* 顧客エッジ（CE）とプロバイダエッジ（PE）の間のルーティングプロトコルを保護する。6peと6vpeの場合、リンクローカルアドレス（[RFC7404]参照）を使用することができ、これらのアドレスをリンクの外側から到達できないため、6peと6vpeのセキュリティはIPv4 BGP /よりもさらに高くなります。MPLS IP VPN。
LDPv6 itself does not induce new risks; see [RFC7552].
LDPv6自体は新しいリスクを誘発しません。[RFC7552]を参照してください。
Dual-Stack Lite (DS-Lite) is also a translation mechanism and is therefore analyzed further (Section 2.7.3.3) in this document, as it includes IPv4 NAPT.
デュアルスタックLite（DS-Lite）も翻訳メカニズムであり、したがって、IPv4 NAPTを含むため、この文書ではさらに（セクション2.7.3.3）分析しています。
With the encapsulation and translation versions of Mapping of Address and Port (MAP) -- abbreviated MAP-E [RFC7597] and MAP-T [RFC7599] -- the access network is purely an IPv6 network, and MAP protocols are used to provide IPv4 hosts on the subscriber network access to IPv4 hosts on the Internet. The subscriber router does stateful operations in order to map all internal IPv4 addresses and Layer 4 ports to the IPv4 address and the set of Layer 4 ports received through the MAP configuration process. The SP equipment always does stateless operations (either decapsulation or stateless translation). Therefore, as opposed to Section 2.7.3.3, there is no state exhaustion DoS attack against the SP equipment because there is no state and there is no operation caused by a new Layer 4 connection (no logging operation).
アドレスとポート（MAP）のマッピングのカプセル化および翻訳バージョンで - 省略形MAP-E [RFC7597]とMAP-T [RFC7599] - アクセスネットワークは純粋にIPv6ネットワークであり、MAPプロトコルはIPv4を提供するために使用されます。インターネット上のIPv4ホストへの加入者ネットワーク上のホスト。サブスクライバルータは、すべての内部IPv4アドレスとレイヤ4ポートを、マップ構成プロセスで受信したIPv4アドレスとレイヤ4ポートのセットにマッピングするためにステートフルな操作を実行します。SP装置は常にステートレス操作（カプセル化またはステートレス翻訳）を行います。したがって、セクション2.7.3.3とは対照的に、状態がないため、SP機器に対する状態排出DOS攻撃はありません。これは、新しいレイヤ4接続による操作がない（ログ操作なし）。
The SP MAP equipment should implement all the security considerations of [RFC7597], notably ensuring that the mapping of the IPv4 address and port are consistent with the configuration. As MAP has a predictable IPv4 address and port mapping, the audit logs are easier to use, as there is a clear mapping between the IPv6 address and the IPv4 address and ports.
SPマップ機器は、[RFC7597]のすべてのセキュリティ上の考慮事項を実装しており、特にIPv4アドレスとポートのマッピングが設定と一致していることを確認してください。MAPに予測可能なIPv4アドレスとポートマッピングがあるので、IPv6アドレスとIPv4アドレスとポートの間にクリアマッピングがあるため、監査ログは使いやすくなります。
In [RFC3056], 6to4 tunnels require a public-routable IPv4 address in order to work correctly. They can be used to provide either single IPv6 host connectivity to the IPv6 Internet or multiple IPv6 networks connectivity to the IPv6 Internet. The 6to4 relay was historically the anycast address defined in [RFC3068], which has been deprecated by [RFC7526] and is no longer used by recent Operating Systems. Some security considerations are explained in [RFC3964].
[RFC3056]では、6to4トンネルに正しく機能するために公共のIPv4アドレスが必要です。それらは、IPv6インターネットまたはIPv6インターネットへの複数のIPv6ネットワーク接続に単一のIPv6ホスト接続を提供するために使用できます。6to4リレーは、[RFC3068]で定義されている[RFC3068]で定義されているAnycastアドレスで、[RFC7526]では、最近のオペレーティング・システムで使用されなくなりました。セキュリティ上の考慮事項は、[RFC3964]で説明されています。
[RFC6343] points out that if an operator provides well-managed servers and relays for 6to4, nonencapsulated IPv6 packets will pass through well-defined points (the native IPv6 interfaces of those servers and relays) at which security mechanisms may be applied. Client usage of 6to4 by default is now discouraged, and significant precautions are needed to avoid operational problems.
[RFC6343]オペレータが6to4のために十分に管理されたサーバーとリレーを提供する場合、非カプセル化されていないIPv6パケットは、セキュリティメカニズムが適用される可能性がある明確な点（それらのサーバーとリレーのネイティブIPv6インタフェース）を通過します。デフォルトで6to4のクライアントの使用法は今推奨されていません。操作上の問題を回避するために大切な予防策が必要です。
Teredo tunnels [RFC4380] are mainly used in a residential environment because Teredo easily traverses an IPv4 NAPT device thanks to its UDP encapsulation. Teredo tunnels connect a single host to the IPv6 Internet. Teredo shares the same issues as other tunnels: no authentication, no confidentiality, possible spoofing, and reflection attacks.
Teredo Tunnels [RFC4380]は主に住宅環境で使用されているため、TeredoはUDPカプセル化のおかげでIPv4 NAPTデバイスを簡単に走行できます。Teredo Tunnels単一のホストをIPv6インターネットに接続します。Teredoは他のトンネルと同じ問題を共有しています：認証、機密性、スプーフィング、そして反射攻撃はありません。
IPsec [RFC4301] for the transported IPv6 traffic is recommended.
転送されたIPv6トラフィックのIPSec [RFC4301]をお勧めします。
The biggest threat to Teredo is probably for an IPv4-only network, as Teredo has been designed to easily traverse IPv4 NAT-PT devices, which are quite often co-located with a stateful firewall. Therefore, if the stateful IPv4 firewall allows unrestricted UDP outbound and accepts the return UDP traffic, then Teredo actually punches a hole in this firewall for all IPv6 traffic to and from the Internet. Host policies can be deployed to block Teredo in an IPv4-only network in order to avoid this firewall bypass. On the IPv4 firewall, all outbound UDPs should be blocked except for the commonly used services (e.g., port 53 for DNS, port 123 for NTP, port 443 for QUIC, port 500 for Internet Key Exchange Protocol (IKE), port 3478 for Session Traversal Utilities for NAT (STUN), etc.).
TeredoがIPv4の唯一のネットワークであるため、TeredoがIPv4の唯一のネットワークがあるため、ステートフルファイアウォールと非常に頻繁に配置されているため、おそらくIPv4専用のネットワークがあります。したがって、ステートフルIPv4ファイアウォールが無制限のUDPアウトバウンドを許可し、UDPトラフィックの返信を受け入れると、テレディオは実際にこのファイアウォールの穴をインターネットとの間でパンチします。このファイアウォールバイパスを回避するために、IPv4専用ネットワークでTeredoをブロックするようにホストポリシーを展開できます。IPv4ファイアウォールでは、一般的に使用されているサービス（DNSのポート53、NTPのポート123、QUIC用のポート123、Inter Inter Exchange Protocol for Internet Port 500のポート53、Port 500）、セッションのためのポート3478を除いてブロックする必要があります。NAT（STUN）などのトラバーサルユーティリティ）。
Teredo is now hardly ever used and no longer enabled by default in most environments so it is less of a threat; however, special consideration must be made in cases when devices with older or operating systems that have not been updated may be present and by default were running Teredo.
Teredoは、ほとんどの環境ではデフォルトで使用されていなくなりました。ただし、更新されていない古いまたはオペレーティングシステムを持つデバイスが存在し、デフォルトでデフォルトがTeredoが実行されていた場合には、特別な考慮事項を考慮する必要があります。
Translation mechanisms between IPv4 and IPv6 networks are alternate coexistence strategies while networks transition to IPv6. While a framework is described in [RFC6144], the specific security considerations are documented with each individual mechanism. For the most part, they specifically mention interference with IPsec or DNSSEC deployments, how to mitigate spoofed traffic, and what some effective filtering strategies may be.
IPv4ネットワークとIPv6ネットワーク間の翻訳メカニズムは、IPv6への移行中の代替の共存戦略です。フレームワークが[RFC6144]に記述されている間、特定のセキュリティ上の考慮事項は各メカニズムごとに文書化されています。ほとんどの場合、それらは、IPSecまたはDNSSEC展開、偽装されたトラフィックを軽減する方法、およびいくつかの効果的なフィルタリング戦略をどのように推測するかについて説明します。
While not really a transition mechanism to IPv6, this section also includes the discussion about the use of heavy IPv4-to-IPv4 network addresses and port translation to prolong the life of IPv4-only networks.
IPv6への移行メカニズムではありませんが、このセクションでは、IPv4専用ネットワークの寿命を延ばすための重いIPv4からIPv4ネットワークアドレスとポート翻訳の使用に関する議論も含まれています。
Carrier-Grade NAT (CGN), also called NAT444 CGN or Large-Scale NAT (LSN) or SP NAT, is described in [RFC6264] and is utilized as an interim measure to extend the use of IPv4 in a large service provider network until the provider can deploy an effective IPv6 solution. [RFC6598] requested a specific IANA-allocated /10 IPv4 address block to be used as address space shared by all access networks using CGN. This has been allocated as 100.64.0.0/10.
NAT444 CGNまたは大規模NAT（LSN）またはSP NATとも呼ばれるキャリアグレードNAT（CGN）は、[RFC6264]に記載されており、大規模サービスプロバイダネットワークにおけるIPv4の使用を拡張するための中間尺度として利用される。プロバイダは効果的なIPv6ソリューションを展開できます。[RFC6598] CGNを使用して、すべてのアクセスネットワークによって共有されるアドレス・スペースとして使用される特定のIANA割り当て/ 10 IPv4アドレス・ブロックを要求しました。これは100.64.0.0/10として割り当てられています。
Section 13 of [RFC6269] lists some specific security-related issues caused by large-scale address sharing. The Security Considerations section of [RFC6598] also lists some specific mitigation techniques for potential misuse of shared address space. Some law enforcement agencies have identified CGN as impeding their cybercrime investigations (for example, see the Europol press release on CGN [europol-cgn]). Many translation techniques (NAT64, DS-Lite, etc.) have the same security issues as CGN when one part of the connection is IPv4 only.
[RFC6269]のセクション13は、大規模アドレス共有によって引き起こされた特定のセキュリティ関連の問題をいくつか示します。[RFC6598]の[セキュリティ上の考慮事項]セクションでは、共有アドレス空間の潜在的な誤用のためのいくつかの特定の緩和技術もリストされています。いくつかの法執行機関は、それらのサイバー犯罪研究を妨げるとCGNを特定した（例えば、CGN [Europol-CGN]上のEuropolプレスリリースを参照）。接続の一部がIPv4のみの場合、多くの翻訳技術（NAT64、DS-Liteなど）がCGNと同じセキュリティ上の問題を抱えています。
[RFC6302] has recommendations for Internet-facing servers to also log the source TCP or UDP ports of incoming connections in an attempt to help identify the users behind such a CGN.
[RFC6302]インターネット向けサーバーには、そのようなCGNの背後にあるユーザーを識別するために、着信接続の送信元TCPまたはUDPポートをログに記録します。
[RFC7422] suggests the use of deterministic address mapping in order to reduce logging requirements for CGN. The idea is to have a known algorithm for mapping the internal subscriber to/from public TCP and UDP ports.
[RFC7422] CGNのロギング要件を減らすために、決定論的アドレスマッピングの使用を示唆しています。このアイデアは、内部加入者をパブリックTCPおよびUDPポートとの間でマッピングするための既知のアルゴリズムを持つことです。
[RFC6888] lists common requirements for CGNs. [RFC6967] analyzes some solutions to enforce policies on misbehaving nodes when address sharing is used. [RFC7857] also updates the NAT behavioral requirements.
[RFC6888] CGNの一般的な要件を示します。[RFC6967]アドレスの共有が使用されているときに、不正なノードでポリシーを強制するためのソリューションを分析します。[RFC7857] NATの行動要件を更新します。
Stateful NAT64 translation [RFC6146] allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used in conjunction with DNS64 [RFC6147], a mechanism that synthesizes AAAA records from existing A records. There is also a stateless NAT64 [RFC7915], which has similar security aspects but with the added benefit of being stateless and is thereby less prone to a state exhaustion attack.
ステートフルNAT64翻訳[RFC6146] IPv6専用クライアントは、ユニキャストUDP、TCP、またはICMPを使用してIPv4サーバーに連絡してください。既存のレコードからAAAAレコードを合成するメカニズムであるDNS64 [RFC6147]と組み合わせて使用できます。ステートレスNAT64 [RFC7915]があります。これは、同様のセキュリティ面を持っているが、ステートレスであり、それによって州の枯渇攻撃に起動しやすい。
The Security Consideration sections of [RFC6146] and [RFC6147] list the comprehensive issues; in Section 8 of [RFC6147], there are some considerations on the interaction between NAT64 and DNSSEC. A specific issue with the use of NAT64 is that it will interfere with most IPsec deployments unless UDP encapsulation is used.
[RFC6146]と[RFC6147]のセキュリティ検討セクションは、包括的な問題を挙げています。[RFC6147]のセクション8では、NAT64とDNSSECの間の相互作用について考慮しています。NAT64を使用する具体的な問題は、UDPカプセル化が使用されていない限り、ほとんどのIPSec展開を妨げることです。
Another translation mechanism relying on a combination of stateful and stateless translation, 464XLAT [RFC6877], can be used to do a host-local translation from IPv4 to IPv6 and a network provider translation from IPv6 to IPv4, i.e., giving IPv4-only application access to an IPv4-only server over an IPv6-only network. 464XLAT shares the same security considerations as NAT64 and DNS64; however, it can be used without DNS64, avoiding the DNSSEC implications.
ステートフルとステートレス変換464xlat [RFC6877]の組み合わせに頼るもう1つの翻訳メカニズムは、IPv4からIPv6へのホストローカル変換、およびIPv6からIPv4へのネットワークプロバイダー変換、つまりIPv4の唯一のアプリケーションアクセスを提供するために使用できます。IPv6専用ネットワーク経由でIPv4専用サーバーに。464xlatは、NAT64とDNS64と同じセキュリティ上の考慮事項を共有しています。ただし、DNS64なしで使用できるため、DNSSECの影響を避けることができます。
Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that enables a service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4-in-IPv6) and IPv4 NAPT.
デュアルスタックライト（DS-Lite）[RFC6333]は、2つの有名なテクノロジを組み合わせることで、サービスプロバイダが顧客間のIPv4アドレスを共有できる遷移技術です.IP（IPv4-in-IPv6）とIPv4 NAPT。
Security considerations, with respect to DS-Lite, mainly revolve around logging data, preventing DoS attacks from rogue devices (as the Address Family Translation Router (AFTR) [RFC6333] function is stateful), and restricting service offered by the AFTR only to registered customers.
セキュリティ上の考慮事項は、主にロギングデータを中心に回復し、ローグデバイスからのDOS攻撃を防止し、（アドレスファミリ変換ルータ（AFTR）[RFC6333]機能がステートフル）、およびAFTRによって提供される制限サービスのみ顧客。
Section 11 of [RFC6333] and Section 2 of [RFC7785] describe important security issues associated with this technology.
[RFC6333]のセクション11と[RFC7785]のセクション2は、この技術に関連した重要なセキュリティ問題を説明しています。
With almost all devices being IPv6 enabled by default and with many endpoints having IPv6 connectivity to the Internet, it is critical to also harden those devices against attacks over IPv6.
ほとんどすべてのデバイスがデフォルトでIPv6で、インターネットへのIPv6接続を持つ多くのエンドポイントがあるため、IPv6に対する攻撃に対してそれらのデバイスを硬化させることが重要です。
The same techniques used to protect devices against attacks over IPv4 should be used for IPv6 and should include but are not limited to:
IPv4を介した攻撃からデバイスを保護するために使用されるのと同じ技術をIPv6に使用する必要があり、以下を含める必要があります。
* restricting device access to authorized individuals;
* 許可された個人へのデバイスアクセスを制限する。
* monitoring and auditing access to the device;
* デバイスへの監視と監査。
* turning off any unused services on the end node
* エンドノードで未使用のサービスをオフにする
* understanding which IPv6 addresses are being used to source traffic and changing defaults if necessary;
* どのIPv6アドレスがトラフィックのソーストラフィックに使用されているかを理解し、必要に応じてデフォルトを変更します。
* using cryptographically protected protocols for device management (Secure Copy Protocol (SCP), SNMPv3, SSH, TLS, etc.);
* デバイス管理（Secure Copy Protocol（SCP）、SNMPv3、SSH、TLSなど）の暗号化保護プロトコルを使用する。
* using host firewall capabilities to control traffic that gets processed by upper-layer protocols;
* ホストファイアウォール機能を使用して、上位レイヤプロトコルによって処理されるトラフィックを制御します。
* applying firmware, OS, and application patches/upgrades to the devices in a timely manner;
* ファームウェア、OS、およびアプリケーションのパッチを適用する/デバイスへのアップグレードを適時にデバイスに適用します。
* using multifactor credentials to authenticate to devices; and
* デバイスへの認証にMultiFactorの資格情報を使用する。と
* using virus scanners to detect malicious programs.
* 悪意のあるプログラムを検出するためにウイルススキャナを使用する。
Enterprises [RFC7381] generally have robust network security policies in place to protect existing IPv4 networks. These policies have been distilled from years of experiential knowledge of securing IPv4 networks. At the very least, it is recommended that enterprise networks have parity between their security policies for both protocol versions. This section also applies to the enterprise part of all SP networks, i.e., the part of the network where the SP employees are connected.
企業[RFC7381]既存のIPv4ネットワークを保護するための堅牢なネットワークセキュリティポリシーが適所に堅牢なネットワークセキュリティポリシーを持っています。これらの方針は、IPv4ネットワークを確保するという経験的な知識の年から蒸留されました。少なくとも、企業ネットワークには両方のプロトコルバージョンのセキュリティポリシーの間にパリティがあることが推奨されます。このセクションはまた、すべてのSPネットワークの企業部分、すなわちSP従業員が接続されているネットワークの一部にも当てはまる。
Security considerations in the enterprise can be broadly categorized into two groups: external and internal.
企業内のセキュリティ上の考慮事項は、広く2つのグループに分類できます。外部と内部。
The external aspect deals with providing security at the edge or perimeter of the enterprise network where it meets the service provider's network. This is commonly achieved by enforcing a security policy, either by implementing dedicated firewalls with stateful packet inspection or a router with ACLs. A common default IPv4 policy on firewalls that could easily be ported to IPv6 is to allow all traffic outbound while only allowing specific traffic, such as established sessions, inbound (see [RFC6092]). Section 3.2 of [RFC7381] also provides similar recommendations.
外部アスペクトは、サービスプロバイダのネットワークを満たすエンタープライズネットワークのエッジまたは周囲にセキュリティを提供することを扱います。これは、ステートフルパケット検査またはACLを持つルータを使用して専用のファイアウォールを実装することによって、セキュリティポリシーを強制することによって一般的に達成されます。IPv6に簡単に移植できるファイアウォール上の一般的なデフォルトのIPv4ポリシーは、確立されたセッションなどの特定のトラフィックを許可しながらすべてのトラフィックのアウトバウンドを許可することです（[RFC6092]を参照）。[RFC7381]のセクション3.2も同様の推奨事項を提供します。
Here are a few more things that could enhance the default policy:
デフォルトのポリシーを強化することができるいくつかのもう少しです。
* Filter internal-use IPv6 addresses at the perimeter; this will also mitigate the vulnerabilities listed in [RFC7359].
* 境界線での内部使用IPv6アドレスをフィルタリングします。これにより、[RFC7359]に記載されている脆弱性も軽減されます。
* Discard packets from and to bogon and reserved space; see [CYMRU] and [RFC8190].
* Bogonと予約スペースからパケットを廃棄します。[Cymru]と[RFC8190]を参照してください。
* Accept certain ICMPv6 messages to allow proper operation of ND and Path MTU Discovery (PMTUD); see [RFC4890] or [REY_PF] for hosts.
* NDとパスMTUの発見（PMTUD）の適切な動作を可能にするために特定のICMPv6メッセージを受け入れます。ホストの[RFC4890]または[REY_PF]を参照してください。
* Based on the use of the network, filter specific extension headers by accepting only the required ones (permit list approach), such as ESP, AH, and not forgetting the required transport layers: ICMP, TCP, UDP, etc. This filtering should be done where applicable at the edge and possibly inside the perimeter; see [IPV6-EH-FILTERING].
* ネットワークの使用に基づいて、ESP、ああ、必要なトランスポート層を忘れずに必要なものだけを受け入れて、特定の拡張ヘッダーをフィルタリングし、ICMP、TCP、UDPなどを忘れないでください。このフィルタリングはエッジで該当する場合は該当する場合は境界内の内側にあります。[IPv6-EHフィルタリング]を参照してください。
* Filter packets having an illegal IPv6 header chain at the perimeter (and, if possible, inside the network as well); see Section 2.2.
* 周囲に違法なIPv6ヘッダーチェーンを持つフィルタパケット（そして可能であれば、ネットワーク内でも、ネットワーク内で）。セクション2.2を参照してください。
* Filter unneeded services at the perimeter.
* 境界で不要なサービスをフィルタリングします。
* Implement ingress and egress anti-spoofing in the forwarding and control planes; see [RFC2827] and [RFC3704].
* 転送面と制御プレーンに入射防止スプーフィング防止を実装します。[RFC2827]と[RFC3704]を参照してください。
* Implement appropriate rate-limiters and control plane policers based on traffic baselines.
* トラフィックベースラインに基づいて適切なレートリミッタとコントロールプレーンポリサーを実装します。
Having global IPv6 addresses on all the enterprise sites is different than in IPv4, where [RFC1918] addresses are often used internally and not routed over the Internet. [RFC7359] and [WEBER_VPN] explain that without careful design, there could be IPv6 leakages from Layer 3 VPNs.
すべてのエンタープライズサイトでグローバルIPv6アドレスを持つことはIPv4とは異なります。ここで、[RFC1918]アドレスは内部的に内部的に使用され、インターネットを介してルーティングされません。[RFC7359]と[WEBER_VPN]は、慎重な設計なしで、レイヤ3 VPNからIPv6リークが発生する可能性があります。
The internal aspect deals with providing security inside the perimeter of the network, including end hosts. Internal networks of enterprises are often different, e.g., University campus, wireless guest access, etc., so there is no "one size fits all" recommendation.
内部アスペクトは、エンドホストを含むネットワークの周囲内のセキュリティを提供することを扱います。企業の内部ネットワークは、さまざまな、例えば大学のキャンパス、ワイヤレスゲストアクセスなどです。そのため、「1サイズはすべてのサイズにフィット」の推奨事項はありません。
The most significant concerns here are related to Neighbor Discovery. At the network level, it is recommended that all security considerations discussed in Section 2.3 be reviewed carefully and the recommendations be considered in-depth as well. Section 4.1 of [RFC7381] also provides some recommendations.
ここで最も重要な懸念は、隣接発見に関連しています。ネットワークレベルでは、セクション2.3で議論されたすべてのセキュリティ上の考慮事項を慎重にレビューし、推奨事項も詳細と見なされることをお勧めします。[RFC7381]のセクション4.1もいくつかの推奨事項を提供します。
As mentioned in Section 2.7.2, care must be taken when running automated IPv6-in-IPv4 tunnels.
2.7.2項で述べたように、自動化されたIPv6-in-IPv4トンネルを実行するときは注意が必要です。
When site-to-site VPNs are used, it should be kept in mind that, given the global scope of IPv6 global addresses as opposed to the common use of IPv4 private address space [RFC1918], sites might be able to communicate with each other over the Internet even when the VPN mechanism is not available. Hence, no traffic encryption is performed and traffic could be injected from the Internet into the site; see [WEBER_VPN]. It is recommended to filter at Internet connection(s) packets having a source or destination address belonging to the site internal prefix or prefixes; this should be done for ingress and egress traffic.
サイト間のVPNが使用されている場合は、IPv4プライベートアドレス・スペース[RFC1918]の一般的な使用とは対照的に、IPv6グローバルアドレスのグローバルスコープを考えると、サイトは互いに通信できる可能性があることに注意してください。VPNメカニズムが利用できない場合でもインターネット上で。したがって、トラフィック暗号化は実行されず、インターネットからサイトへのトラフィックを注入することはできませんでした。[WEBER_VPN]を参照してください。サイト内部プレフィックスまたはプレフィックスに属するソースアドレスまたは宛先アドレスを持つインターネット接続でフィルタリングすることをお勧めします。これは、入力トラフィックと出力トラフィックのために行われるべきです。
Hosts need to be hardened directly through security policy to protect against security threats. The host firewall default capabilities have to be clearly understood. In some cases, third-party firewalls have no IPv6 support, whereas the native firewall installed by default has IPv6 support. General device hardening guidelines are provided in Section 2.8.
セキュリティの脅威から保護するために、ホストはセキュリティポリシーを通じて直接強化する必要があります。ホストファイアウォールのデフォルト機能を明確に理解する必要があります。場合によっては、サードパーティのファイアウォールにはIPv6サポートがありませんが、デフォルトでインストールされているネイティブファイアウォールにはIPv6サポートがあります。一般的な装置硬化ガイドラインはセクション2.8で提供されています。
It should also be noted that many hosts still use IPv4 for transporting logs for RADIUS, DIAMETER, TACACS+, syslog, etc. Operators cannot rely on an IPv6-only security policy to secure such protocols that are still using IPv4.
また、RADIUS、Diameter、TACACS、SYSLOGなどのログを転送するためのIPv4を使用していることも、演算子はIPv6のみのセキュリティポリシーに依存することは依然としてIPv4を使用しているプロトコルを保護することはできません。
The threats and mitigation techniques are identical between IPv4 and IPv6. Broadly speaking, they are:
脅威と緩和技術はIPv4とIPv6の間で同じです。大まかに言って、彼らは次のとおりです。
* authenticating the TCP session;
* TCPセッションの認証
* TTL security (which becomes hop-limit security in IPv6), as in [RFC5082];
* [RFC5082]のように、TTLセキュリティ（IPv6のホップリミットセキュリティとなる）。
* bogon AS filtering; see [CYMRU]; and
* フィルタリングとしてのボゴン。[Cymru]を参照してください。と
* prefix filtering.
* プレフィックスフィルタリング。
These are explained in more detail in Section 2.5. Also, the recommendations of [RFC7454] should be considered.
これらについては、セクション2.5で詳しく説明します。また、[RFC7454]の推奨事項を考慮する必要があります。
A Remote Triggered Black Hole (RTBH) [RFC5635] works identically in IPv4 and IPv6. IANA has allocated the 100::/64 prefix to be used as the discard prefix [RFC6666].
リモートトリガーブラックホール（RTBH）[RFC5635]はIPv4とIPv6でも同じ動作です。IANAは、廃棄プレフィックス[RFC6666]として使用する100 :: / 64プレフィックスを割り当てました。
SPs will typically use transition mechanisms, such as 6rd, 6PE, MAP, and NAT64, which have been analyzed in the transition and coexistence (Section 2.7).
SPSは通常、遷移と共存で分析されている6番目、6pe、Map、Nat64などの遷移メカニズムを使用します（セクション2.7）。
The lawful intercept requirements are similar for IPv6 and IPv4 architectures and will be subject to the laws enforced in different geographic regions. The local issues with each jurisdiction can make this challenging and both corporate legal and privacy personnel should be involved in discussions pertaining to what information gets logged and with regard to the respective log retention policies for this information.
合法的な傍受要件は、IPv6およびIPv4アーキテクチャーに似ており、さまざまな地理的地域で実施される法律の対象となります。各管轄区域に関する現地の問題は、この困難な課題と企業の法的職員とプライバシー担当者の両方が、この情報のそれぞれのログ保持ポリシーに関して、どの情報に関連する議論に関与するべきである。
The target of interception will usually be a residential subscriber (e.g., his/her PPP session, physical line, or CPE MAC address). In the absence of IPv6 NAT on the CPE, IPv6 has the possibility to allow for intercepting the traffic from a single host (i.e., a /128 target) rather than the whole set of hosts of a subscriber (which could be a /48, /60, or /64).
傍受のターゲットは通常、住宅の加入者（例えば、彼/彼女のPPPセッション、物理回線、またはCPE MACアドレス）であろう。CPE上のIPv6 NATがない場合、IPv6は、加入者のホスト全体ではなく、単一のホスト（すなわち、A / 128ターゲット）からのトラフィックを傍受することを可能にする可能性を有する（これは/ 48になる可能性がある。/ 60、または/ 64）。
In contrast, in mobile environments, since the 3GPP specifications allocate a /64 per device, it may be sufficient to intercept traffic from the /64 rather than specific /128s (since each time the device establishes a data connection, it gets a new IID).
対照的に、モバイル環境では、3GPP仕様がデバイスごとに/ 64を割り当てるため、特定/ 128Sではなく/ 64からのトラフィックを傍受するのに十分かもしれません（デバイスがデータ接続を確立するたびに新しいIIDが取得されるたびに）。
The IETF Home Networking (homenet) Working Group is working on standards and guidelines for IPv6 residential networks; this obviously includes operational security considerations, but this is still a work in progress. [RFC8520] is an interesting approach on how firewalls could retrieve and apply specific security policies to some residential devices.
IETFホームネットワーク（HomeNet）ワーキンググループは、IPv6住宅ネットワークの標準とガイドラインに取り組んでいます。これは明らかに運用上のセキュリティ上の考慮事項を含みますが、これはまだ進行中の作業です。[RFC8520]は、ファイアウォールが特定のセキュリティポリシーをいくつかの住宅デバイスにどのように検索して適用できるかについての興味深いアプローチです。
Some residential users have less experience and knowledge about security or networking than experimented operators. As most of the recent hosts (e.g., smartphones and tablets) have IPv6 enabled by default, IPv6 security is important for those users. Even with an IPv4-only ISP, those users can get IPv6 Internet access with the help of Teredo (Section 2.7.2.8) tunnels. Several peer-to-peer programs support IPv6, and those programs can initiate a Teredo tunnel through an IPv4 residential gateway, with the consequence of making the internal host reachable from any IPv6 host on the Internet. Therefore, it is recommended that all host security products (including personal firewalls) are configured with a dual-stack security policy.
いくつかの住宅ユーザは、実験演算子よりもセキュリティまたはネットワーキングに関する経験や知識を持っています。最近のホスト（例えばスマートフォンおよびタブレット）のほとんどがデフォルトでIPv6を有効にしているため、IPv6セキュリティはそれらのユーザーにとって重要です。IPv4専用のISPでさえ、それらのユーザーはTeredo（セクション2.7.2.8）トンネルの助けを借りてIPv6インターネットアクセスを取得できます。いくつかのピアツーピアプログラムがIPv6をサポートし、それらのプログラムはIPv4の住宅ゲートウェイを介してTeredoトンネルを開始することができ、インターネット上のIPv6ホストから内部ホストを到達可能にすることができます。したがって、すべてのホストセキュリティ製品（パーソナルファイアウォールを含む）がデュアルスタックセキュリティポリシーで構成されていることをお勧めします。
If the residential CPE has IPv6 connectivity, [RFC7084] defines the requirements of an IPv6 CPE and does not take a position on the debate of default IPv6 security policy, as defined in [RFC6092]:
Residential CPEにIPv6接続がある場合、[RFC7084]はIPv6 CPEの要件を定義し、[RFC6092]で定義されているように、デフォルトのIPv6セキュリティポリシーの議論上の位置を取らない。
outbound only: Allowing all internally initiated connections and blocking all externally initiated ones, which is a common default security policy enforced by IPv4 residential gateway doing NAPT, but it also breaks the end-to-end reachability promise of IPv6. [RFC6092] lists several recommendations to design such a CPE.
アウトバウンドのみ：すべての内部開始された接続を許可し、すべての外部開始されたものをブロックすることは、NAPTを実行しているIPv4 Residential Gatewayによって強制された一般的なデフォルトのセキュリティポリシーですが、IPv6のエンドツーエンドの到達可能性の約束も壊れます。[RFC6092]そのようなCPEを設計するためのいくつかの推奨事項をリストします。
open/transparent: Allowing all internally and externally initiated connections, therefore, restoring the end-to-end nature of the Internet for IPv6 traffic but having a different security policy for IPv6 than for IPv4.
開閉：すべての内部および外部から開始された接続を許可しているため、IPv6トラフィックのインターネットのエンドツーエンドの性質を復元しますが、IPv4よりもIPv6のセキュリティポリシーが異なります。
REC-49 states that a choice must be given to the user to select one of those two policies [RFC6092].
REC-49は、それらの2つのポリシー[RFC6092]のいずれかを選択するためにユーザーに選択を与えなければならないことを示します。
There are several documents that describe in more detail the security of an IPv6 network; these documents are not written by the IETF and some of them are dated but are listed here for the reader's convenience:
IPv6ネットワークのセキュリティをより詳細に説明する文書がいくつかあります。これらの文書はIETFによって書かれておらず、それらのいくつかは日付が付けられていますが、読者の利便性のためにここにリストされています。
* Guidelines for the Secure Deployment of IPv6 [NIST]
* IPv6の安全な展開のためのガイドライン[NIST]
* North American IPv6 Task Force Technology Report - IPv6 Security Technology Paper [NAv6TF_Security]
* 北米IPv6タスクフォース技術レポート - IPv6セキュリティテクノロジーペーパー[NAV6TF_SECURITIOL]
* IPv6 Security [IPv6_Security_Book]
* IPv6セキュリティ[IPv6_Security_book]
This memo attempts to give an overview of security considerations of operating an IPv6 network both for an IPv6-only network and for networks utilizing the most widely deployed IPv4/IPv6 coexistence strategies.
このメモは、IPv6専用ネットワークの両方と最も広く展開されたIPv4 / IPv6共存戦略を利用したネットワークの両方のIPv6ネットワークの操作のセキュリティ上の考慮事項の概要を説明します。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] The'th、S.およびR.hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https：//www.rfc-editor.org/ info / rfc8200>。
[CYMRU] Team Cymru, "The Bogon Reference", <https://team-cymru.com/community-services/bogon-reference/>.
[Cymru]チームCymru、「Bogon Reference」、<https：//team-cymru.com/community-services/bogon-reference/>。
[ENTROPYIP] Foremski, P., Plonka, D., and A. Berger, "Entropy/IP: Uncovering Structure in IPv6 Addresses", November 2016, <http://www.entropy-ip.com/>.
[EntropyIP] Foremski、P.、Plonka、D.、およびA. Berger、「エントロピー/ IP：IPv6アドレスの構造体の発見」、2016年11月、<http://www.entropy-it.com/>。
[europol-cgn] Europol, "Are you sharing the same IP address as a criminal? Law enforcement call for the end of Carrier Grade Nat (CGN) to increase accountability online", October 2017, <https://www.europol.europa.eu/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn-to-increase-accountability-online>.
[Europol-CGN] Europol、あなたは刑事訴訟と同じIPアドレスを共有していますか？2017年10月、<https：//www.europol。europa.eu/newsroom/news/are-you-Sharing-Same-IP-Address-Criminal-law-eNifut-call-for-end-of-carrier-grade-nat-cgn-to-increase-accountibility-online>。
[GDPR] European Union, "Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)", Official Journal of the European Union, April 2016, <https://eur-lex.europa.eu/eli/reg/2016/679/oj>.
[GDPR]欧州連合、欧州議会の「規制（EU）2016/679欧州議会の議事録、2016年4月27日の審議会、2016年4月27日、個人データの処理とそのようなデータの自由な動きについての自然人の保護Directive 95/46 / EC（一般データ保護規制） "、2016年4月、2016年4月、<https：//eur-lex.europa.eu/eli/reg/2016/679/oj>。
[IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", <http://www.iana.org/assignments/ipfix>.
[IANA-IPFIX] IANA、「IPフロー情報エクスポート（IPFIX）エンティティ」、<http://www.iana.org/ashignments/ipfix>。
[IEEE-802.1X] IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Port-Based Network Access Control", IEEE Std 802.1X-2020, February 2020.
[IEEE-802.1X] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE規格 - ポートベースネットワークアクセス制御」、IEEE STD 802.1X-2020、2020年2月。
[IPV6-EH-FILTERING] Gont, F. and W. Liu, "Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers", Work in Progress, Internet-Draft, draft-ietf-opsec-ipv6-eh-filtering-08, 3 June 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-eh-filtering-08>.
[IPv6-EHフィルタリング] Gont、F.およびW. Liu、「TransitルータでのIPv6拡張ヘッダを含むIPv6パケットのフィルタリングに関する推奨事項」、進行中、インターネットドラフト、romft-ietf-opsec-ipv6-eh-filtering-08,2021、<https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-hiltering-08>
[IPV6-EH-PARSING] Kampanakis, P., "Implementation Guidelines for parsing IPv6 Extension Headers", Work in Progress, Internet-Draft, draft-kampanakis-6man-ipv6-eh-parsing-01, 5 August 2014, <https://datatracker.ietf.org/doc/html/draft-kampanakis-6man-ipv6-eh-parsing-01>.
[IPv6-EH-PARSING]カンパナキス、P.、「IPv6拡張ヘッダーの解析のための実施ガイドライン」、進行中の作業、インターネットドラフト、ドラフト - カンパナキス-6man-IPv6-EH-PARSING-01,01,58月5日、<HTTPS：///datatracker.ietf.org/doc/html/draft-kampanakis-6man-ipv6-eh- parsing-01>
[IPv6_Security_Book] Hogg, S. and É. Vyncke, "IPv6 Security", CiscoPress, ISBN 1587055945, December 2008.
[IPv6_Security_book] HOGG、S、É。Vyncke、「IPv6セキュリティ」、CiscoPress、ISBN 1587055945、2008年12月。
[KRISTOFF] Kristoff, J., Ghasemisharif, M., Kanich, C., and J. Polakis, "Plight at the End of the Tunnel: Legacy IPv6 Transition Mechanisms in the Wild", March 2021, <https://dataplane.org/jtk/publications/kgkp-pam-21.pdf>.
[Kristoff]クリストフ、J.、Ghasemisharif、M.、Kanich、C.、およびJ.Polakis、「トンネル終了時の窮状：野生のレガシーIPv6遷移メカニズム」、2021年3月、<https：//データプレーン.ORG / JTK /出版物/ KGKP-PAM-21.pdf>。
[NAv6TF_Security] Kaeo, M., Green, D., Bound, J., and Y. Pouffary, "North American IPv6 Task Force (NAv6TF) Technology Report "IPv6 Security Technology Paper", July 2006, <http://www.ipv6forum.com/dl/white/ NAv6TF_Security_Report.pdf>.
[Nav6TF_SECURITY] KAEO、M.、Green、D、D.、BUINT、J.、Y。PUFFARY、「北米IPv6タスクフォース（NAV6TF）テクノロジー」「IPv6セキュリティテクノロジーペーパー」、2006年7月、<http：// Www.ipv6forum.com / dl / white / nav6tf_security_report.pdf>。
[NIST] Frankel, S., Graveman, R., Pearce, J., and M. Rooks, "Guidelines for the Secure Deployment of IPv6", December 2010, <http://csrc.nist.gov/publications/nistpubs/800-119/ sp800-119.pdf>.
[NIST] Frankel、S.、Graveman、R.、Pearce、J.、およびM.Rooks、2010年12月、2010年12月、<http://csrc.nist.gov/publications/nistpubs/ 800-119 / SP800-119.pdf>。
[RADB] Merit Network, Inc., "RADb: The Internet Routing Registry", <https://www.radb.net/>.
[RADB]メリットネットワーク、Inc。、「RADB：インターネットルーティングレジストリ」、<https://www.radb.net/>。
[REY_PF] Rey, E., "Local Packet Filtering with IPv6", July 2017, <https://labs.ripe.net/Members/enno_rey/local-packet-filtering-with-ipv6>.
[REY_PF] REY、E。、「IPv6によるローカルパケットフィルタリング」、2017年7月、<https：//labs.rep.net/members/enno_rey/local-packet-filtering-with-ipv6>。
[RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <https://www.rfc-editor.org/info/rfc826>.
[RFC0826] Plummer、D.、「イーサネット・アドレス解決プロトコル：またはネットワークプロトコル・アドレスをイーサネット・ハードウェア上での送信・イーサネット・アドレスの変換」、STD 37、RFC 826、DOI 10.17487 / RFC0826、1982年11月、<https：//www.rfc-editor.org/info/rfc826>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、DE GROUT、GJ、およびE. Lear、「プライベートインターネットの住所配分」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<https://www.rfc-editor.org/info/rfc1918>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2131] DROMS、R.、「動的ホスト構成プロトコル」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<https：//www.rfc-editor.org/info/rfc2131>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2460]「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<https://www.rfc-editor.org/info/RFC2460>。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, DOI 10.17487/RFC2529, March 1999, <https://www.rfc-editor.org/info/rfc2529>.
[RFC2529] Carpenter、B.およびC. Jung、「明示的トンネルなしのIPv4ドメイン上のIPv6の送信」、RFC 2529、DOI 10.17487 / RFC2529、1999年3月、<https：//www.rfc-editor.org/info/RFC2529>。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <https://www.rfc-editor.org/info/rfc2663>.
[RFC2663] SRISERSH、P.およびM.OLSREGE、「IPネットワークアドレストランスレータ（NAT）用語と考慮事項」、RFC 2663、DOI 10.17487 / RFC2663、1999年8月、<https：//www.rfc-editor.org/info/ RFC2663>。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D.、およびP. Traina、「ジェネリックルーティングカプセル化（GRE）」、RFC 2784、DOI 10.17487 / RFC2784、2000年3月、<HTTPS//www.rfc-editor.org/info/rfc2784>。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC2827] Ferguson、P.およびD. Senie、「ネットワーク入力フィルタリング：IP送信元アドレスのなりすましを採用するサービス拒否の拒否」、BCP 38、RFC 2827、DOI 10.17487 / RFC2827、2000年5月、<https：// www.rfc-editor.org / info / rfc2827>。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000, <https://www.rfc-editor.org/info/rfc2866>.
[RFC2866] RFC 2866、RFC 2866、DOI 10.17487 / RFC2866、2000年6月、<https://www.rfc-editor.org/info/rfc2866>。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001, <https://www.rfc-editor.org/info/rfc3056>.
[RFC3056] Carpenter、B.およびK.Moore、「IPv4雲を介したIPv6ドメインの接続」、RFC 3056、DOI 10.17487 / RFC3056、2001年2月、<https：//www.rfc-editor.org/info/rfc3056>。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, DOI 10.17487/RFC3068, June 2001, <https://www.rfc-editor.org/info/rfc3068>.
[RFC3068] Huitema、C.、「6to4リレールータ用エニーキャストプレフィックス」、RFC 3068、DOI 10.17487 / RFC3068、2001年6月、<https://www.rfc-editor.org/info/rfc3068>。
[RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers Considered Harmful", RFC 3627, DOI 10.17487/RFC3627, September 2003, <https://www.rfc-editor.org/info/rfc3627>.
[RFC3627] Savola、P.、「有害検討されたルーター間の/ 127プレフィックス長」、RFC 3627、DOI 10.17487 / RFC3627、2003年9月、<https：//www.rfc-editor.org/info/rfc3627>。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC3704] Baker、F.およびP.Savola、「マルチホームネットワークのための入口フィルタリング」、BCP 84、RFC 3704、DOI 10.17487 / RFC3704、2004年3月、<https：//www.rfc-editor.org/info/rfc3704>。
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, DOI 10.17487/RFC3756, May 2004, <https://www.rfc-editor.org/info/rfc3756>.
[RFC3756] Nikander、P.、ED。、KEMPF、J.、およびE. Nordmark、「IPv6 Noiby Discovery（ND）信託モデルと脅威」、RFC 3756、DOI 10.17487 / RFC3756、2004年5月、<https：//www.rfc-editor.org/info/rfc3756>。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, DOI 10.17487/RFC3964, December 2004, <https://www.rfc-editor.org/info/rfc3964>.
[RFC3964] Savola、P.およびC. Patel、「6to4」、RFC 3964、DOI 10.17487 / RFC3964、2004年12月、<https：//www.rfc-editor.org/info/rfc3964>。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <https://www.rfc-editor.org/info/rfc3971>.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B.、P.Nikander、「Secure Neight Discovery（Send）」、RFC 3971、DOI 10.17487 / RFC3971、2005年3月、<HTTPS：//www.rfc-editor.org/info/rfc3971>。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, <https://www.rfc-editor.org/info/rfc3972>.
[RFC3972] Aura、T.、「暗号的に生成されたアドレス（CGA）」、RFC 3972、DOI 10.17487 / RFC3972、2005年3月、<https：//www.rfc-editor.org/info/rfc3972>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ紹介および要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https：//www.rfc-editor.org/info/rfc4033>。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC4107] Bellovin、S.およびR. Housley、「暗号鍵管理のためのガイドライン」、BCP 107、RFC 4107、DOI 10.17487 / RFC4107、2005年6月、<https://www.rfc-editor.org/info/rfc4107>。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden、R.およびB.B.Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<https：//www.rfc-editor.org/info/rfc4193>。
[RFC4293] Routhier, S., Ed., "Management Information Base for the Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, April 2006, <https://www.rfc-editor.org/info/rfc4293>.
[RFC4293] Routhier、S、ED。、「インターネットプロトコルの管理情報ベース（IP）」、RFC 4293、DOI 10.17487 / RFC4293、2006年4月、<https：//www.rfc-editor.org/info/RFC4293>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S.およびK.SEO、「インターネットプロトコルのためのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<https：//www.rfc-editor.org/info/rfc4301>。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>.
[RFC4302] Kent、S.、「IP認証ヘッダー」、RFC 4302、DOI 10.17487 / RFC4302、2005年12月、<https：//www.rfc-editor.org/info/rfc4302>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<https：//www.rfc-editor.org/info/rfc4303>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364] Rosen、E.およびY.Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPNS）"、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<https：//www.rfc-editor.org/info/ RFC4364>。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006, <https://www.rfc-editor.org/info/rfc4380>.
[RFC4380] Huitema、C.、 "Teredo：ネットワークアドレス翻訳（NAT）"、RFC 4380、DOI 10.17487 / RFC4380、2006年2月、<https://www.rfc-editor.org/info/RFC4380>。
[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4381, DOI 10.17487/RFC4381, February 2006, <https://www.rfc-editor.org/info/rfc4381>.
[RFC4381] BEHRINGER、M。、「BGP / MPLS IP仮想プライベートネットワーク（VPNS / MPLS IP仮想プライベートネットワーク（VPNS）」、RFC 4381、DOI 10.17487 / RFC4381、2006年2月、<https：//www.rfc-editor.org/情報/ RFC4381>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Theering、S.およびM.Gupta、Internet Protocol Version 6（IPv6）仕様のICMPv6（ICMPv6）、STD 89、RFC 4443、DOI 10.17487 /RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, <https://www.rfc-editor.org/info/rfc4552>.
[RFC4552] Gupta、M.およびN.Melam、「OSPFv3の認証/機密保持」、RFC 4552、DOI 10.17487 / RFC4552、2006年6月、<https：//www.rfc-editor.org/info/rfc4552>。
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, DOI 10.17487/RFC4649, August 2006, <https://www.rfc-editor.org/info/rfc4649>.
[RFC4649] Volz、B.、「IPv6の動的ホスト構成プロトコル（DHCPv6）リレーエージェントリモートIDオプション」、RFC 4649、DOI 10.17487 / RFC4649、2006年8月、<https://www.rfc-editor.org/情報/ RFC4649>。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, <https://www.rfc-editor.org/info/rfc4659>.
[RFC4659] DE CLERCQ、J.、OOM、D.、COLUGI、M.、およびF.LE FAUCHEUR、IPV6 VPNの「BGP-MPLS IP仮想プライベートネットワーク（VPN）拡張子」、RFC 4659、DOI 10.17487 / RFC4659、2006年9月、<https：//www.rfc-editor.org/info/rfc4659>。
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, DOI 10.17487/RFC4795, January 2007, <https://www.rfc-editor.org/info/rfc4795>.
[RFC4795] Aboba、B.、Thaler、D.、およびL. Esibov、「Link-Localマルチキャスト名解決（LLMNR）」、RFC 4795、DOI 10.17487 / RFC4795、2007年1月、<https：///www.rfc-editor.org/info/rfc4795>。
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, DOI 10.17487/RFC4798, February 2007, <https://www.rfc-editor.org/info/rfc4798>.
[RFC4798] DE CLERCQ、J.、OOM、D.、Prevost、S.、およびF.Le Faucheur、「IPv6プロバイダーエッジルーター（6PE）を使用したIPv4 MPLS（6PE）」、RFC 4798、DOI 10.17487 / RFC47982007年2月、<https：//www.rfc-editor.org/info/rfc4798>。
[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, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W.、およびH. Soliman、「IPバージョン6（IPv6）の隣接発見（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：//www.rfc-editor.org/info/rfc4861>。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, DOI 10.17487/RFC4864, May 2007, <https://www.rfc-editor.org/info/rfc4864>.
[RFC4864] van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B.、およびE.Klein、「IPv6のローカルネットワーク保護」、RFC 4864、DOI 10.17487 / RFC4864、2007年5月、<https://www.rfc-editor.org/info/rfc4864>。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, DOI 10.17487/RFC4890, May 2007, <https://www.rfc-editor.org/info/rfc4890>.
[RFC4890] Davies、E.およびJ.Mohacsi、「ファイアウォールのICMPv6メッセージをフィルタリングするための推奨事項」、RFC 4890、DOI 10.17487 / RFC4890、2007年5月、<https：//ww.rfc-editor.org/info/rfc4890>。
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ Co-existence Security Considerations", RFC 4942, DOI 10.17487/RFC4942, September 2007, <https://www.rfc-editor.org/info/rfc4942>.
[RFC4942]デイビー、E.、Krishnan、S.、およびP.Savola、「IPv6移行/共存セキュリティ上の考慮事項」、RFC 4942、DOI 10.17487 / RFC4942、2007年9月、<https：//www.rfc-編集者.ORG / INFO / RFC4942>。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <https://www.rfc-editor.org/info/rfc5082>.
[RFC5082] Gill、V.、Heasley、J.、Meyer、D.、Savola、P.、Ed。、およびC. Pignataro、C. Pignataro、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 5082、DOI 10.17487 / RFC5082、2007年10月、<https：//www.rfc-editor.org/info/rfc5082>。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, DOI 10.17487/RFC5214, March 2008, <https://www.rfc-editor.org/info/rfc5214>.
[RFC5214] Templin、F.、Gleeson、T.、D.Thaler、「サイト内自動トンネルアドレッシングプロトコル（ISATAP）」、RFC 5214、DOI 10.17487 / RFC5214、2008年3月、<https：//www.rfc-editor.org/info/rfc5214>。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J.、およびA. Lindem、RFC 5340、DOI 10.17487 / RFC5340、2008年7月、<https：///www.rfc-編集者.org / info / rfc5340>。
[RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)", RFC 5635, DOI 10.17487/RFC5635, August 2009, <https://www.rfc-editor.org/info/rfc5635>.
[RFC5635] Kumari、W.およびD. McPherson、「ユニキャストリバースパスフォワーディング（URPF）」、RFC 5635、DOI 10.17487 / RFC5635、2009年8月、<https：//www.rfc-編集者。ORG / INFO / RFC5635>。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.
[RFC5952]川村、S.およびM.川島、「IPv6アドレステキスト表現の推奨事項」、RFC 5952、DOI 10.17487 / RFC5952、2010年8月、<https：//www.rfc-editor.org/info/rfc5952>。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, DOI 10.17487/RFC5969, August 2010, <https://www.rfc-editor.org/info/rfc5969>.
[RFC5969] TownSley、W.およびO. Troan、「IPv4インフラストラクチャ（6RD） - プロトコル仕様のIPv6迅速な展開」、RFC 5969、DOI 10.17487 / RFC5969、2010年8月、<https：///www.rfc-編集者。ORG / INFO / RFC5969>。
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, <https://www.rfc-editor.org/info/rfc6092>.
[RFC6092] Woodyatt、J.、ED。、「顧客宅内機器の推奨単純なセキュリティ機能」、RFC 6092、RFC 6092、DOI 10.17487 / RFC6092、2011年1月、<https：//www.rfc-editor.org/info/rfc6092>。
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, DOI 10.17487/RFC6104, February 2011, <https://www.rfc-editor.org/info/rfc6104>.
[RFC6104] Chown、T.およびS. Venaas、RFC 6104、DOI 10.17487 / RFC6104、2011年2月、<https：//www.rfc-editor.org/info/rfc6104>。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 10.17487/RFC6105, February 2011, <https://www.rfc-editor.org/info/rfc6105>.
[RFC6105] Levy-Abningoli、E.、Van de Velde、G.、Popviciu、C.、およびJ.Mohacsi、「IPv6ルータ広告ガード」、RFC 6105、DOI 10.17487 / RFC6105、2011年2月、<https：//www.rfc-editor.org/info/rfc6105>。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, April 2011, <https://www.rfc-editor.org/info/rfc6144>.
[RFC6144] Baker、F.、Li、X.、BAO、C、およびK。Yin、「IPv4 / IPv6翻訳のためのフレームワーク」、RFC 6144、DOI 10.17487 / RFC6144、2011年4月、<https：// www。rfc-editor.org/info/rfc6144>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P.、I。van Beijnum、 "IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳"、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<https：//www.rfc-editor.org/info/rfc6146>。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, <https://www.rfc-editor.org/info/rfc6147>.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P.、およびI。van Beijnum、「DNS64：IPv6クライアントからIPv4サーバーへのネットワークアドレス翻訳のためのDNS拡張」、RFC 6147、DOI 10.17487 / RFC6147、4月2011年、<https://www.rfc-editor.org/info/rfc6147>。
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, <https://www.rfc-editor.org/info/rfc6164>.
[RFC6164] Kohno、M.、Nitzan、B.、Bush、R.、Matsuzaki、Y。、Colitti、L.、およびT.Narten、「ルータ間リンクの127ビットIPv6プレフィックスの使用」、RFC 6164、DOI 10.17487 / RFC6164、2011年4月、<https：//www.rfc-editor.org/info/rfc6164>。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, DOI 10.17487/RFC6169, April 2011, <https://www.rfc-editor.org/info/rfc6169>.
[RFC6169] Krishnan、S.、Thaler、D.、J.Hoagland、「IPトンネリングに関するセキュリティ上の懸念」、RFC 6169、DOI 10.17487 / RFC6169、2011年4月、<https：//www.rfc-editor.org/情報/ RFC6169>。
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, DOI 10.17487/RFC6177, March 2011, <https://www.rfc-editor.org/info/rfc6177>.
[RFC6177] Narten、T.、Huston、G.、およびL. Roberts、「End SitesへのIPv6アドレス割り当て」、BCP 157、RFC 6177、DOI 10.17487 / RFC6177、2011年3月、<https：///www.rfc-Editor.org/info/rfc6177>。
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, March 2011, <https://www.rfc-editor.org/info/rfc6192>.
[RFC6192]ダグナル、D.、Pignataro、C.、R.Dunn、「ルーターコントロールプレーンの保護」、RFC 6192、DOI 10.17487 / RFC6192、2011年3月、<https：//www.rfc-editor.org/情報/ RFC6192>。
[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, DOI 10.17487/RFC6221, May 2011, <https://www.rfc-editor.org/info/rfc6221>.
[RFC6221]マイル、D.、ED。、Ooghe、S.、Dec、W.、Krishnan、S.、およびA. Kavanagh、 "Lightweight DHCPV6リレーエージェント"、RFC 6221、DOI 10.17487 / RFC6221、<https://www.rfc-editor.org/info/rfc6221>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241]、R.Bjorklund、M.、Ed。、Schoenwaelder、J.、Ed。、およびA. Bierman、ED。、「ネットワーク構成プロトコル（NetConf）」、RFC 6241、DOI 10.17487 /RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, DOI 10.17487/RFC6264, June 2011, <https://www.rfc-editor.org/info/rfc6264>.
[RFC6264] Jiang、S.、Guo、D.、B. Carpenter、「IPv6遷移用のインクリメンタルキャリアグレードNAT（CGN）」、RFC 6264、DOI 10.17487 / RFC6264、2011年6月、<https：// Www.rfc-editor.org / info / rfc6264>。
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <https://www.rfc-editor.org/info/rfc6269>.
[RFC6269]フォード、M、ED。、Boucadair、M.、Durand、A.、Levis、P.、およびP. Roberts、RFC 6269、DOI 10.17487 / RFC6269、2011年6月、<https://www.rfc-editor.org/info/rfc6269>。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, <https://www.rfc-editor.org/info/rfc6296>.
[RFC6296] Wasserman、M.およびF. Baker、 "IPv6-to-ipv6ネットワークプレフィックス翻訳"、RFC 6296、DOI 10.17487 / RFC6296、2011年6月、<https://www.rfc-editor.org/info/rfc6296>。
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011, <https://www.rfc-editor.org/info/rfc6302>.
[RFC6302] Durand、A.、Gashinsky、I.、Lee、D.、およびS. Sheppard、BCP 162、RFC 6302、DOI 10.17487 / RFC6302、2011年6月、<https：//www.rfc-editor.org/info/rfc6302>。
[RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011, <https://www.rfc-editor.org/info/rfc6324>.
[RFC6324] nakable、G.およびF.F. F. Templin、「IPv6自動トンネルを使用したルーティングループ攻撃：問題ステートメントと提案された軽減」、RFC 6324、DOI 10.17487 / RFC6324、2011年8月、<https：//ww.rfc-編集者。ORG / INFO / RFC6324>。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, <https://www.rfc-editor.org/info/rfc6333>.
[RFC6333] Durand、A.、DROM、R.、Woodyatt、J.、およびY。Lee、「IPv4排除のデュアルスタックLiteブロードバンド展開」、RFC 6333、DOI 10.17487 / RFC6333、2011年8月、<https：//www.rfc-editor.org/info/rfc6333>。
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, DOI 10.17487/RFC6343, August 2011, <https://www.rfc-editor.org/info/rfc6343>.
[RFC6343] Carpenter、B、「6to 4展開のためのアドバイザリーガイドライン」、RFC 6343、DOI 10.17487 / RFC6343、2011年8月、<https：//www.rfc-editor.org/info/rfc6343>。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2011, <https://www.rfc-editor.org/info/rfc6434>.
[RFC6434] Jankiewicz、E.、Loughney、J.、およびT.Narten、 "IPv6ノード要件"、RFC 6434、DOI 10.17487 / RFC6434、2011年12月、<https：//ww.rfc-editor.org/info/RFC6434>。
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, DOI 10.17487/RFC6459, January 2012, <https://www.rfc-editor.org/info/rfc6459>.
[RFC6459] Korhonen、J.、Ed。、Soininen、J.、Patil、B.、Savolainen、T.、Bajko、G.、K.Iisakkila、「3世代パートナーシッププロジェクト（3GPP）進化パケットシステム（3GPP）のIPv6eps） "、RFC 6459、DOI 10.17487 / RFC6459、2012年1月、<https：//www.rfc-editor.org/info/rfc6459>。
[RFC6547] George, W., "RFC 3627 to Historic Status", RFC 6547, DOI 10.17487/RFC6547, February 2012, <https://www.rfc-editor.org/info/rfc6547>.
[RFC6547]ジョージ、W。、「RFC 3627から歴史的ステータスへ」、RFC 6547、DOI 10.17487 / RFC6547、2012年2月、<https：//www.rfc-editor.org/info/rfc6547>。
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, "A Uniform Format for IPv6 Extension Headers", RFC 6564, DOI 10.17487/RFC6564, April 2012, <https://www.rfc-editor.org/info/rfc6564>.
[RFC6564] Krishnan、S.、Woodyatt、J.、Kline、E.、Hoagland、J.、およびM.Bhatia、「IPv6拡張ヘッダーの統一フォーマット」、RFC 6564、DOI 10.17487 / RFC6564、2012年4月、<https://www.rfc-editor.org/info/rfc6564>。
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, DOI 10.17487/RFC6583, March 2012, <https://www.rfc-editor.org/info/rfc6583>.
[RFC6583] Gashinsky、I.、Jaeggli、J.、およびW.Kumari、「オペレーショナルディスカバリーの問題」、RFC 6583、DOI 10.17487 / RFC6583、2012年3月、<https：//www.rfc-editor.org/info/ RFC6583>。
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2012, <https://www.rfc-editor.org/info/rfc6598>.
[RFC6598] Weil、J.、Kuarsingh、V.、Donley、C.、Liljenstolpe、C.、およびM. Azinger、「IANA-Reserved IPv4プレフィックス」、BCP 153、RFC 6598、DOI 10.17487 / RFC6598、2012年4月、<https://www.rfc-editor.org/info/rfc6598>。
[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, <https://www.rfc-editor.org/info/rfc6620>.
[RFC6620] Nordmark、E.、Bagnulo、M.、およびE. Levy-Abngro、「FCFS SAVI：ローカルに割り当てられたIPv6アドレスの最初のサービス、初めての送信元アドレス検証改善」、RFC 6620、DOI 10.17487 / RFC6620、2012年5月、<https：//www.rfc-editor.org/info/rfc6620>。
[RFC6666] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", RFC 6666, DOI 10.17487/RFC6666, August 2012, <https://www.rfc-editor.org/info/rfc6666>.
[RFC6666] Hilliard、N.およびD. Freedman、「IPv6用の廃棄プレフィックス」、RFC 6666、DOI 10.17487 / RFC6666、<https：//www.rfc-editor.org/info/rfc6666>。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762] Cheshire、S.およびM. Krochmal、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<https：//www.rfc-editor.org/info/rfc6762>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S.およびM. Krochmal、「DNSベースのサービス発見」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<https：//www.rfc-editor.org/info/rfc6763>。
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <https://www.rfc-editor.org/info/rfc6775>.
[RFC6775] Shelby、Z.、ED。、Chakrabarti、S.、Nordmark、E.、およびC. Bormann、「低電力無線パーソナルエリアネットワークにおけるIPv6の近隣探索最適化（6lowpans）」、RFC 6775、DOI 10.17487/ RFC6775、2012年11月、<https：//www.rfc-editor.org/info/rfc6775>。
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <https://www.rfc-editor.org/info/rfc6877>.
[RFC6877] Mawatari、M.、Kawashima、M.、Byrne、 "464xlat：ステートフルとステートレス翻訳の組み合わせ"、RFC 6877、DOI 10.17487 / RFC6877、2013年4月、<https：//www.rfc-編集者.org / info / rfc6877>。
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, <https://www.rfc-editor.org/info/rfc6888>.
[RFC6888]ペロー、S.編、山形、I.、宮川、S.、中川、A.、およびH.芦田、"キャリアグレードNATのための共通要件（CGNを）"、BCP127、RFC6888、DOI10.17487/RFC6888、2013年4月、<https://www.rfc-editor.org/info/rfc6888>。
[RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, May 2013, <https://www.rfc-editor.org/info/rfc6939>.
[RFC6939] Halwasia、G.、Bhandari、S.、およびW. Dec、RFC 6939、RFC 6939、DOI 10.17487 / RFC6939、2013年5月、<https：//www.rfc-編集者.org / info / rfc6939>。
[RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 6964, DOI 10.17487/RFC6964, May 2013, <https://www.rfc-editor.org/info/rfc6964>.
[RFC6964] Templin、F.、「サイト内自動トンネルアドレッシングプロトコル（ISATAP）」、RFC 6964、DOI 10.17487 / RFC6964、2013年5月、<https：///www.rfcを使用したIPv6サイトでのIPv6展開のための操作ガイダンス-editor.org/info/rfc6964>。
[RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments", RFC 6967, DOI 10.17487/RFC6967, June 2013, <https://www.rfc-editor.org/info/rfc6967>.
[RFC6967] Boucadair、M.、Touch、J.、Levis、P.、およびR. Penno、「共有アドレス展開におけるホスト識別子（host_id）を明らかにするための潜在的な解決策の分析」、RFC 6967、DOI 10.17487 / RFC69672013年6月、<https：//www.rfc-editor.org/info/rfc6967>。
[RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", RFC 6980, DOI 10.17487/RFC6980, August 2013, <https://www.rfc-editor.org/info/rfc6980>.
[RFC6980] Gont、F。、「IPv6隣接ディスカバリーによるIPv6フラグメンテーションのセキュリティの意味」、RFC 6980、DOI 10.17487 / RFC6980、2013年8月、<https：//www.rfc-editor.org/info/rfc6980>。
[RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, DOI 10.17487/RFC7010, September 2013, <https://www.rfc-editor.org/info/rfc7010>.
[RFC7010] Liu、B.、Jiang、S.、Carpenter、B.、Venaas、S.、およびW. George、「IPv6サイトの番号：gap分析」、RFC 7010、DOI 10.17487 / RFC7010、2013年9月、<https：//www.rfc-editor.org/info/rfc7010>。
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.
[RFC7011] Claise、B、ED。、Trammell、B.、Ed。、およびP.Aitken、「フロー情報交換のIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、STD 77、RFC 7011、DOI 10.17487 / RFC7011、2013年9月、<https：//www.rfc-editor.org/info/rfc7011>。
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, <https://www.rfc-editor.org/info/rfc7012>.
[RFC7012]クリーズ、B、ED。B. Trammell、ED。、「IPフロー情報の輸出（IPFIX）の情報モデル」、RFC 7012、DOI 10.17487 / RFC7012、2013年9月、<https://www.rfc-editor.org/info/rfc7012>。
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, October 2013, <https://www.rfc-editor.org/info/rfc7039>.
[RFC7039] Wu、J.、Bi、J.、Bagnulo、M.、Baker、F.、およびC. Vogt、Ed。、「Source Address検証改善（SAVI）フレームワーク」、RFC 7039、DOI 10.17487 / RFC7039、2013年10月、<https://www.rfc-editor.org/info/rfc7039>。
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, December 2013, <https://www.rfc-editor.org/info/rfc7045>.
[RFC7045] Carpenter、B.およびS. Jiang、「IPv6拡張ヘッダーの送信および処理」、RFC 7045、DOI 10.17487 / RFC7045、2013年12月、<https：//www.rfc-editor.org/info/rfc7045>。
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <https://www.rfc-editor.org/info/rfc7084>.
[RFC7084] Singh、H.、Beebee、W.、Donley、C.、およびB. Stark、「IPv6カスタマーエッジルータの基本要件」、RFC 7084、DOI 10.17487 / RFC7084、2013年11月、<https：// www.rfc-editor.org / info / rfc7084>。
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", RFC 7112, DOI 10.17487/RFC7112, January 2014, <https://www.rfc-editor.org/info/rfc7112>.
[RFC7112] Gont、F.、Manral、V.およびR. Bonica、「特大IPv6ヘッダーチェーンの意味」、RFC 7112、DOI 10.17487 / RFC7112、2014年1月、<https：//www.rfc-editor.org/ info / rfc7112>。
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, DOI 10.17487/RFC7113, February 2014, <https://www.rfc-editor.org/info/rfc7113>.
[RFC7113] Gont、F.、「IPv6ルータ広告ガード（RA-Guard）の実装アドバイス」、RFC 7113、DOI 10.17487 / RFC7113、2014年2月、<https：//www.rfc-editor.org/info/rfc7113>。
[RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on IPv4 Networks", RFC 7123, DOI 10.17487/RFC7123, February 2014, <https://www.rfc-editor.org/info/rfc7123>.
[RFC7123] Gont、F.およびW.IU、「IPv4ネットワーク上のIPv6のセキュリティの意味」、RFC 7123、DOI 10.17487 / RFC7123、2014年2月、<https：//www.rfc-editor.org/info/rfc7123>。
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, DOI 10.17487/RFC7166, March 2014, <https://www.rfc-editor.org/info/rfc7166>.
[RFC7166] Bhatia、M.、Manral、V.およびA. Lindem、RFC 7166、DOI 10.17487 / RFC7166、2014年3月、<https：//www.rfc-editor.org/情報/ RFC7166>。
[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, <https://www.rfc-editor.org/info/rfc7217>.
[RFC7217] Gont、F. "IPv6ステートレスアドレス自動設定（SLAAC）"、RFC 7217、DOI 10.17487 / RFC7217、2014年4月、<https://ww.rfc-editor.org/ info / rfc7217>。
[RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359, DOI 10.17487/RFC7359, August 2014, <https://www.rfc-editor.org/info/rfc7359>.
[RFC7359] Gont、F.、「レイヤ3仮想プライベートネットワーク（VPN）トンネルトラフィックリーク」、RFC 7359、DOI 10.17487 / RFC7359、2014年8月、<https：//www.rfc-編集者.ORG / INFO / RFC7359>。
[RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, <https://www.rfc-editor.org/info/rfc7381>.
[RFC7381] Chittimaneni、K.、Chown、T.、Howard、L.、Kuarsingh、V.、Poufary、Y.、およびE.Vyncke、E.Vyncke、RFC 7381、DOI 10.17487 / RFC7381、2014年10月<https：//www.rfc-editor.org/info/rfc7381>。
[RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local Addressing inside an IPv6 Network", RFC 7404, DOI 10.17487/RFC7404, November 2014, <https://www.rfc-editor.org/info/rfc7404>.
[RFC7404] Behringer、M.およびE.Vyncke、「IPv6ネットワーク内のリンクローカルアドレッシングのみを使用する」、RFC 7404、DOI 10.17487 / RFC7404、2014年11月、<https：//www.rfc-editor.org/info/ RFC7404>。
[RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments", RFC 7422, DOI 10.17487/RFC7422, December 2014, <https://www.rfc-editor.org/info/rfc7422>.
[RFC7422] Donley、C.、Grundemann、C.、Sarawat、V.、Sundaresan、K.、およびO. Vautrin、「キャリアグレードのNAT展開におけるログを縮小するための決定論的アドレスマッピング」、RFC 7422、DOI 10.17487 / RFC74222014年12月、<https://www.rfc-editor.org/info/rfc7422>。
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, <https://www.rfc-editor.org/info/rfc7454>.
[RFC7454] Durand、J.、Pepelnjak、I.、G. Douering、 "BGP操作およびセキュリティ"、BCP 194、RFC 7454、DOI 10.17487 / RFC7454、2015年2月、<https：///www.rfc-編集者。ORG / INFO / RFC7454>。
[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address Validation Improvement (SAVI) Solution for DHCP", RFC 7513, DOI 10.17487/RFC7513, May 2015, <https://www.rfc-editor.org/info/rfc7513>.
[RFC7513] Bi、J.、Wu、J.、Yao、G.、およびF. Baker、「DHCPの送信元アドレス検証改善（SAVI）ソリューション」、RFC 7513、DOI 10.17487 / RFC7513、2015年5月、<https：//www.rfc-editor.org/info/rfc7513>。
[RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast Prefix for 6to4 Relay Routers", BCP 196, RFC 7526, DOI 10.17487/RFC7526, May 2015, <https://www.rfc-editor.org/info/rfc7526>.
[RFC7526] Troan、O.およびB. Carpenter、ED。、「6to4リレールーターのエニーキャストプレフィックスの非推奨」、BCP 196、RFC 7526、DOI 10.17487 / RFC7526、2015年5月、<https：///www.rfc-編集者.org / info / rfc7526>。
[RFC7552] Asati, R., Pignataro, C., Raza, K., Manral, V., and R. Papneja, "Updates to LDP for IPv6", RFC 7552, DOI 10.17487/RFC7552, June 2015, <https://www.rfc-editor.org/info/rfc7552>.
[RFC7552] ASATI、R.、Pignataro、C、Raza、K.、Manral、V.、R.Papneja、「IPv6用LDPの更新」、RFC 7552、DOI 10.17487 / RFC7552、2015年6月、<HTTPS：//www.rfc-editor.org/info/rfc7552>。
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, <https://www.rfc-editor.org/info/rfc7597>.
[RFC7597] Troan、O.、ED、DEC、W、LI、X、BAO、C、松島、S、村上、T.、およびT.Taylor、「アドレスとポートのマッピング」カプセル化（MAP-E） "、RFC 7597、DOI 10.17487 / RFC7597、2015年7月、<https://www.rfc-editor.org/info/rfc7597>。
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015, <https://www.rfc-editor.org/info/rfc7599>.
[RFC7599] Li、X.、BaO、C、DEC、W。、TROAN、O、松島、S。村上、「翻訳（MAP-T）」を使用したアドレスとポートのマッピング、RFC 7599、DOI 10.17487 / RFC7599、2015年7月、<https：//www.rfc-editor.org/info/rfc7599>。
[RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers", BCP 199, RFC 7610, DOI 10.17487/RFC7610, August 2015, <https://www.rfc-editor.org/info/rfc7610>.
[RFC7610] Gont、F.、Liu、W.およびG. van de Velde、 "DHCPV6-Shield：Rogue DHCPV6サーバーから保護する"、BCP 199、RFC 7610、DOI 10.17487 / RFC7610、2015年8月、<https：//www.rfc-editor.org/info/rfc7610>。
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, <https://www.rfc-editor.org/info/rfc7707>.
[RFC7707] Gont、F.およびT. Chown、「IPv6ネットワークにおけるネットワーク偵察」、RFC 7707、DOI 10.17487 / RFC7707、2016年3月、<https：//www.rfc-editor.org/info/rfc7707>。
[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, <https://www.rfc-editor.org/info/rfc7721>.
[RFC7721] Cooper、A.、Gont、F.、およびD.Thaler、「IPv6アドレス生成メカニズムのためのセキュリティとプライバシーに関する考察」、RFC 7721、DOI 10.17487 / RFC7721、2016年3月、<https：///www.rfc-Editor.org/info/rfc7721>。
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy Consumption of Router Advertisements", BCP 202, RFC 7772, DOI 10.17487/RFC7772, February 2016, <https://www.rfc-editor.org/info/rfc7772>.
[RFC7772] yourtchenko、A.およびL. Colitti、「ルータ広告のエネルギー消費量の削減」、BCP 202、RFC 7772、DOI 10.17487 / RFC7772、2016年2月、<https：//www.rfc-editor.org/info/RFC7772>。
[RFC7785] Vinapamula, S. and M. Boucadair, "Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite", RFC 7785, DOI 10.17487/RFC7785, February 2016, <https://www.rfc-editor.org/info/rfc7785>.
[RFC7785] vinapamula、S.およびM. Boucadair、「ソフトワイヤデュアルスタックライトのコンテキストにおけるプレフィックスバインディングのための推奨事項」、RFC 7785、DOI 10.17487 / RFC7785、2016年2月、<https：//www.rfc-編集者。ORG / INFO / RFC7785>。
[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy Considerations for DHCPv6", RFC 7824, DOI 10.17487/RFC7824, May 2016, <https://www.rfc-editor.org/info/rfc7824>.
[RFC7824] Krishnan、S.、Mrugalski、T.、およびS. Jiang、「DHCPv6のプライバシーに関する考察」、RFC 7824、DOI 10.17487 / RFC7824、2016年5月、<https：//www.rfc-editor.org/info/ RFC7824>。
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <https://www.rfc-editor.org/info/rfc7844>.
[RFC7844] Huitema、C.、Mrugalski、T.、およびKrishnan、「DHCPクライアントの匿名性プロファイル」、RFC 7844、DOI 10.17487 / RFC7844、2016年5月、<https：//www.rfc-editor.org/情報/ RFC7844>。
[RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, S., and K. Naito, "Updates to Network Address Translation (NAT) Behavioral Requirements", BCP 127, RFC 7857, DOI 10.17487/RFC7857, April 2016, <https://www.rfc-editor.org/info/rfc7857>.
[RFC7857] Penno、R.、PerreAll、S.、Boucadair、M.、Ed。、Sivakumar、S.、およびK。Naito、「ネットワークアドレス翻訳（NAT）行動要件の更新」、BCP 127、RFC 7857、DOI 10.17487 / RFC7857、2016年4月、<https://www.rfc-editor.org/info/rfc7857>。
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, <https://www.rfc-editor.org/info/rfc7872>.
[RFC7872]ゴント、F、Linkova、J.、Chown、T.、およびW. Liu、RFC 7872、DOI 10.17487 / RFC7872、2016年6月<https：//www.rfc-editor.org/info/rfc7872>。
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016, <https://www.rfc-editor.org/info/rfc7915>.
[RFC7915] BAO、C、LI、X、Baker、F.、Anderson、T.、F.F.Gont、「IP / ICMP翻訳アルゴリズム」、RFC 7915、DOI 10.17487 / RFC7915、2016年6月、<https：//www.rfc-editor.org/info/rfc7915>。
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, "Host Address Availability Recommendations", BCP 204, RFC 7934, DOI 10.17487/RFC7934, July 2016, <https://www.rfc-editor.org/info/rfc7934>.
[RFC7934] Colitti、L.、Cerf、V.、Cheshire、S.、およびD.Schinazi、「ホストアドレス在庫状況推奨事項」、BCP 204、RFC 7934、DOI 10.17487 / RFC7934、2016年7月、<HTTPS：// WWW.rfc-editor.org / info / rfc7934>。
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040] Bierman、A.、Bjorklund、M.、K。Watsen、 "Restconf Protoction"、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https：//www.rfc-editor.org/info/rfc8040>。
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, <https://www.rfc-editor.org/info/rfc8064>.
[RFC8064]ゴント、F.、Cooper、A.、Thaler、D.、およびW. Liu、「安定したIPv6インタフェース識別子に関する推奨」、RFC 8064、DOI 10.17487 / RFC8064、2017年2月、<https：// www。rfc-editor.org/info/rfc8064>。
[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key Chains", RFC 8177, DOI 10.17487/RFC8177, June 2017, <https://www.rfc-editor.org/info/rfc8177>.
[RFC8177] Lindem、A.、ED。、QU、Y、Yeung、D.、Chang、I。、およびJ.Zhang、RFC 8177、DOI 10.17487 / RFC8177、2017年6月<https：//www.rfc-editor.org/info/rfc8177>。
[RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, "Updates to the Special-Purpose IP Address Registries", BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, <https://www.rfc-editor.org/info/rfc8190>.
[RFC8190]ボニャ、R.、綿、M.、Haberman、B.、およびL. Vegoda、「特殊目的IPアドレス登録への更新」、BCP 153、RFC 8190、DOI 10.17487 / RFC8190、2017年6月、<https://www.rfc-editor.org/info/rfc8190>。
[RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, <https://www.rfc-editor.org/info/rfc8210>.
[RFC8210] Bush、R.およびR.Austein、 "リソース公開鍵インフラストラクチャ（RPKI）へ、RFC 8210、DOI 10.17487 / RFC8210、2017年9月、<https：//www.rfc-編集者.org / info / rfc8210>。
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, <https://www.rfc-editor.org/info/rfc8273>.
[RFC8273] Brzozowski、J.およびG. van de Velde、「ホストごとのユニークなIPv6プレフィックス」、RFC 8273、DOI 10.17487 / RFC8273、2017年12月、<https://www.rfc-editor.org/info/rfc8273>。
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.
[RFC8343] Bjorklund、M.、「インタフェース管理のためのYangデータモデル」、RFC 8343、DOI 10.17487 / RFC8343、2018年3月、<https://www.rfc-editor.org/info/rfc8343>。
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, <https://www.rfc-editor.org/info/rfc8344>.
[RFC8344] Bjorklund、M.、「IP管理のためのYangデータモデル」、RFC 8344、DOI 10.17487 / RFC8344、2018年3月、<https：//www.rfc-editor.org/info/rfc8344>。
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415] Mrugalski、T.、Sodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S.、Lemon、T.、T.Winters、「IPv6用動的ホスト構成プロトコル」（DHCPv6） "、RFC 8415、DOI 10.17487 / RFC8415、2018年11月、<https：//www.rfc-editor.org/info/rfc8415>。
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[RFC8504] Chown、T.、Loughney、J.、およびT.Winters、「IPv6ノード要件」、BCP 220、RFC 8504、DOI 10.17487 / RFC8504、2019年1月、<https：//www.rfc-editor.org/ info / rfc8504>。
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage Description Specification", RFC 8520, DOI 10.17487/RFC8520, March 2019, <https://www.rfc-editor.org/info/rfc8520>.
[RFC8520] Lear、E.、Droms、R。、RFC 8520、DOI 10.17487 / RFC8520、2019年3月、<https://www.rfc-editor.org/info/ RFC8520>。
[RFC8541] Litkowski, S., Decraene, B., and M. Horneffer, "Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops", RFC 8541, DOI 10.17487/RFC8541, March 2019, <https://www.rfc-editor.org/info/rfc8541>.
[RFC8541] Litkowski、S.、Decraene、B.、およびM.Horneffer、「最短経路の最初の（SPF）トリガーのIGPマイクロループの遅延戦略の影響」、RFC 8541、DOI 10.17487 / RFC8541、2019年3月、<https://www.rfc-editor.org/info/rfc8541>。
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, <https://www.rfc-editor.org/info/rfc8981>.
[RFC8981] Gont、F.、Krishnan、S.、Narten、T.、およびR. Draves、「IPv6のステートレスアドレス自動設定のための一時アドレス拡張機能」、RFC 8981、DOI 10.17487 / RFC8981、2021年2月、<https：//www.rfc-editor.org/info/rfc8981>。
[SCANNING] Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great Void - Smarter scanning for IPv6", February 2012, <http://www.caida.org/workshops/isma/1202/slides/ aims1202_rbarnes.pdf>.
[スキャン] Barnes、R.、Altmann、R.、D. Kerr、2012年2月、2012年2月、<http://www.caida.org/workshops/imsa/1202/スライド/ aims1202_rbarnes.pdf>。
[WEBER_VPN] Weber, J., "Dynamic IPv6 Prefix - Problems and VPNs", March 2018, <https://blog.webernetz.net/wp-content/uploads/2018/03/TR18-Johannes-Weber-Dynamic-IPv6- Prefix-Problems-and-VPNs.pdf>.
[WEBER_VPN]ウェーバー、J.、「動的IPv6プレフィックス - 問題とVPNS」、2018年3月、<https://blog.webernetz.net/wp-content/uploads/2018/03/tr18-johannes-werber-dynamic-IPv6- prefix-ageser-and-vpns.pdf>。
Acknowledgements
謝辞
The authors would like to thank the following people for their useful comments (in alphabetical order): Mikael Abrahamsson, Fred Baker, Mustafa Suha Botsali, Mohamed Boucadair, Brian Carpenter, Tim Chown, Lorenzo Colitti, Roman Danyliw (IESG Review), Markus de Bruen, Lars Eggert (IESG review), Tobias Fiebig, Fernando Gont, Jeffry Handal, Lee Howard, Benjamin Kaduk (IESG review), Panos Kampanakis, Erik Kline, Jouni Korhonen, Warren Kumari (IESG review), Ted Lemon, Mark Lentczner, Acee Lindem (and his detailed nits), Jen Linkova (and her detailed review), Gyan S. Mishra (the Document Shepherd), Jordi Palet, Alvaro Retana (IESG review), Zaheduzzaman Sarker (IESG review), Bob Sleigh, Donald Smith, Tarko Tikan, Ole Troan, and Bernie Volz.
著者らは彼らの有用なコメントのために以下の人々に感謝したいと思います（アルファベット順で）：Mikael Abrahamsson、Fred Baker、Mustafa Suha Botsali、Mohamed Boucadair、Brian Carpenter、Tim Chown、Lorenzo Colitti、Roman Danyliw（IESGレビュー）Bruen、Lars Neghert（IESGレビュー）、Tobias Fiebig、Fernando、Jeffry Handal、Lee Howard、Benjamin Kaduk（IESGレビュー）、Panos Kampanakis、Erik Kline、Jouni Korhonen、Warren Kumari（IESGレビュー）、TEDレモン、マークLentczner、Acee Lindem（そして彼の詳細なニット）、Jen Linkova（そして彼女の詳細レビュー）、Gyan S. Mishra（ドキュメント羊飼い）、Jordi Palet、Alvaro retana（IESGレビュー）、Zaheduzzaman Sarker（IESGレビュー）、Bob Sleigh、Donald Smith、Tarko Tikan、Ole Troan、Bernie Volz。
Authors' Addresses
著者の住所
Éric Vyncke Cisco De Kleetlaan 6a 1831 Diegem Belgium
ÉricVyncke Cisco de Kleetlaan 6a 1831 Diegem Belgium
Phone: +32 2 778 4677
Email: evyncke@cisco.com
Kiran Kumar Chittimaneni
キランクマールチットマネーニ
Email: kk.chittimaneni@gmail.com
Merike Kaeo Double Shot Security 3518 Fremont Ave N 363 Seattle, 98103 United States of America
メリビーカエオダブルショットセキュリティ3518フリーモントアベニュー363シアトル,,,,,298103アメリカ
Phone: +12066696394
Email: merike@doubleshotsecurity.com
Enno Rey ERNW Carl-Bosch-Str. 4 69115 Heidelberg Baden-Wuertemberg Germany
Enno Rey Ernw Carl-Bosch-Str。4 69115 Heidelberg Baden-Wuertembergドイツ
Phone: +49 6221 480390
Email: erey@ernw.de