[要約] RFC 4942は、IPv6の移行/共存に関するセキュリティの考慮事項をまとめたものです。その目的は、IPv6の導入や共存におけるセキュリティリスクを理解し、適切な対策を講じるためのガイドラインを提供することです。
Network Working Group E. Davies
Request for Comments: 4942 Consultant
Category: Informational S. Krishnan
Ericsson
P. Savola
CSC/Funet
September 2007
IPv6 Transition/Coexistence Security Considerations
IPv6の移行/共存セキュリティに関する考慮事項
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
The transition from a pure IPv4 network to a network where IPv4 and IPv6 coexist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment.
純粋なIPv4ネットワークからIPv4とIPv6が共存するネットワークへの移行は、IPv6を展開し、デュアルプロトコルネットワークと関連する遷移メカニズムを操作する際に考慮する必要がある多くの追加のセキュリティ上の考慮事項をもたらします。このドキュメントでは、3つのカテゴリに分類されているさまざまな問題の概要を説明しようとします。OIPv6プロトコル自体による問題、移動メカニズムによる問題、およびIPv6の展開によるOの問題。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Issues Due to IPv6 Protocol . . . . . . . . . . . . . . . . . 4
2.1. IPv6 Protocol-Specific Issues . . . . . . . . . . . . . . 5
2.1.1. Routing Headers and Hosts . . . . . . . . . . . . . . 5
2.1.2. Routing Headers for Mobile IPv6 and Other Purposes . . 6
2.1.3. Site-Scope Multicast Addresses . . . . . . . . . . . . 7
2.1.4. ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 7
2.1.5. Bogus Errored Packets in ICMPv6 Error Messages . . . . 8
2.1.6. Anycast Traffic Identification and Security . . . . . 9
2.1.7. Address Privacy Extensions Interact with DDoS
Defenses . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.8. Dynamic DNS: Stateless Address Autoconfiguration,
Privacy Extensions, and SEND . . . . . . . . . . . . . 10
2.1.9. Extension Headers . . . . . . . . . . . . . . . . . . 11
2.1.10. Fragmentation: Reassembly and Deep Packet
Inspection . . . . . . . . . . . . . . . . . . . . . . 14
2.1.11. Fragmentation Related DoS Attacks . . . . . . . . . . 15
2.1.12. Link-Local Addresses and Securing Neighbor
Discovery . . . . . . . . . . . . . . . . . . . . . . 16
2.1.13. Securing Router Advertisements . . . . . . . . . . . . 17
2.1.14. Host-to-Router Load Sharing . . . . . . . . . . . . . 18
2.1.15. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 18
2.2. IPv4-Mapped IPv6 Addresses . . . . . . . . . . . . . . . . 19
2.3. Increased End-to-End Transparency . . . . . . . . . . . . 20
2.3.1. IPv6 Networks without NATs . . . . . . . . . . . . . . 20
2.3.2. Enterprise Network Security Model for IPv6 . . . . . . 21
2.4. IPv6 in IPv6 Tunnels . . . . . . . . . . . . . . . . . . . 22
3. Issues Due to Transition Mechanisms . . . . . . . . . . . . . 23
3.1. IPv6 Transition/Coexistence Mechanism-Specific Issues . . 23
3.2. Automatic Tunneling and Relays . . . . . . . . . . . . . . 23
3.3. Tunneling IPv6 through IPv4 Networks May Break IPv4
Network Security Assumptions . . . . . . . . . . . . . . . 24
4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . . 26
4.1. Avoiding the Trap of Insecure IPv6 Service Piloting . . . 26
4.2. DNS Server Problems . . . . . . . . . . . . . . . . . . . 28
4.3. Addressing Schemes and Securing Routers . . . . . . . . . 28
4.4. Consequences of Multiple Addresses in IPv6 . . . . . . . . 28
4.5. Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 29
4.5.1. Problems Resulting from ICMPv6 Transparency . . . . . 30
4.6. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 30
4.7. Reduced Functionality Devices . . . . . . . . . . . . . . 31
4.8. Operational Factors when Enabling IPv6 in the Network . . 31
4.9. Security Issues Due to Neighbor Discovery Proxies . . . . 32
5. Security Considerations . . . . . . . . . . . . . . . . . . . 32
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Normative References . . . . . . . . . . . . . . . . . . . 33
7.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. IPv6 Probing/Mapping Considerations . . . . . . . . . 37
Appendix B. IPv6 Privacy Considerations . . . . . . . . . . . . . 38
B.1. Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 38
B.2. Exposing Multiple Devices . . . . . . . . . . . . . . . . 39
B.3. Exposing the Site by a Stable Prefix . . . . . . . . . . . 39
The transition from a pure IPv4 network to a network where IPv4 and IPv6 coexist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network with its associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment.
純粋なIPv4ネットワークからIPv4とIPv6が共存するネットワークへの移行は、IPv6を展開し、関連する遷移メカニズムでデュアルプロトコルネットワークを操作する際に考慮する必要がある多くの追加のセキュリティ上の考慮事項をもたらします。このドキュメントでは、3つのカテゴリに分類されているさまざまな問題の概要を説明しようとします。OIPv6プロトコル自体による問題、移動メカニズムによる問題、およびIPv6の展開によるOの問題。
It is important to understand that deployments are unlikely to be replacing IPv4 with IPv6 (in the short term), but rather will be adding IPv6 to be operated in parallel with IPv4 over a considerable period, so that security issues with transition mechanisms and dual stack networks will be of ongoing concern. This extended transition and coexistence period stems primarily from the scale of the current IPv4 network. It is unreasonable to expect that the many millions of IPv4 nodes will be converted overnight. It is more likely that it will take two or three capital equipment replacement cycles (between nine and 15 years) for IPv6 capabilities to spread through the network, and many services will remain available over IPv4 only for a significant period whilst others will be offered either just on IPv6 or on both protocols. To maintain current levels of service, enterprises and service providers will need to support IPv4 and IPv6 in parallel for some time.
展開がIPv4をIPv6（短期的に）に置き換える可能性は低いが、むしろかなりの期間にわたってIPv4と並行して操作するIPv6を追加することであることを理解することが重要です。ネットワークは継続的に懸念されます。この拡張された遷移と共存期間は、主に現在のIPv4ネットワークのスケールに起因します。何百万ものIPv4ノードが一晩変換されることを期待するのは不合理です。IPv6機能がネットワークに広がるには、2つまたは3つの資本機器交換サイクル（9年から15年）が必要になる可能性が高く、多くのサービスは重要な期間でのみIPv4を介して利用可能なままになりますが、他のサービスはどちらも提供されますIPv6または両方のプロトコルで。現在のレベルのサービスを維持するには、企業とサービスプロバイダーがしばらくの間、IPv4とIPv6を並行してサポートする必要があります。
This document also describes two matters that have been wrongly identified as potential security concerns for IPv6 in the past and explains why they are unlikely to cause problems: considerations about probing/mapping IPv6 addresses (Appendix A) and considerations with respect to privacy in IPv6 (Appendix B).
このドキュメントでは、過去にIPv6の潜在的なセキュリティ上の懸念として誤って特定された2つの問題についても説明し、問題を引き起こす可能性が低い理由を説明しています。IPv6アドレスの調査/マッピングに関する考慮事項（付録A）とIPv6のプライバシーに関する考慮事項（付録B）。
Administrators should be aware that some of the rules suggested in this section could potentially lead to a small amount of legitimate traffic being dropped because the source has made unusual and arguably unreasonable choices when generating the packet. The IPv6 specification [RFC2460] contains a number of areas where choices are available to packet originators that will result in packets that conform to the specification but are unlikely to be the result of a rational packet generation policy for legitimate traffic (e.g., sending a fragmented packet in a much larger than necessary number of small segments). This document highlights choices that could be made by malicious sources with the intention of damaging the target host or network, and suggests rules that try to differentiate specification-conforming packets that are legitimate traffic from conforming packets that may be trying to subvert the specification to cause damage. The differentiation tries to offer a reasonable compromise between securing the network and passing every possible conforming packet. To avoid loss of important traffic, administrators are advised to log packets dropped according to these rules and examine these logs periodically to ensure that they are having the desired effect, and are not excluding traffic inappropriately.
管理者は、このセクションで提案されているルールのいくつかが、パケットを生成する際に異常で間違いなく不合理な選択をしたため、少量の合法的なトラフィックが削除される可能性があることに注意する必要があります。IPv6仕様[RFC2460]には、仕様に準拠しているが正当なトラフィックの合理的なパケット生成ポリシーの結果である可能性が低いパケットをもたらすパケットオリジネーターが選択できる多くの領域が含まれています（例えば、断片化されたものを送信することはありません。必要な数の小さなセグメントよりもはるかに多いパケット）。このドキュメントは、ターゲットホストまたはネットワークを損傷することを目的として悪意のあるソースによって行われる可能性のある選択肢を強調し、仕様を覆そうとしている適合パケットから合法的なトラフィックである仕様を構成するパケットを区別しようとするルールを提案します。ダメージ。差別化は、ネットワークを固定することと、可能なすべての適合パケットを渡すこととの間に合理的な妥協を提供しようとします。重要なトラフィックの損失を回避するために、管理者はこれらのルールに従ってドロップされたログパケットをログにし、これらのログを定期的に調べて、それらが望ましい効果を持っていることを確認し、トラフィックを不適切に除外していないことを確認することをお勧めします。
The built-in flexibility of the IPv6 protocol may also lead to changes in the boundaries between legitimate and malicious traffic as identified by these rules. New options may be introduced in the future, and rules may need to be altered to allow the new capabilities to be (legitimately) exploited by applications. The document therefore recommends that filtering needs to be configurable to allow administrators the flexibility to update rules as new pieces of IPv6 specification are standardized.
IPv6プロトコルの組み込みの柔軟性は、これらのルールで特定されたように、合法的なトラフィックと悪意のあるトラフィックの境界の変化につながる可能性もあります。将来的に新しいオプションが導入される場合があり、新しい機能を（合法的に）アプリケーションで悪用するためにルールを変更する必要がある場合があります。したがって、ドキュメントは、IPv6仕様の新しい部分が標準化されているため、管理者がルールを更新する柔軟性を管理するために、フィルタリングを構成可能にする必要があることを推奨しています。
There are significant differences between the features of IPv6 and IPv4: some of these specification changes may result in potential security issues. Several of these issues have been discussed in separate documents but are summarized here to avoid normative references that may not become RFCs. The following specification-related problems have been identified, but this is not necessarily a complete list.
IPv6とIPv4の機能には大きな違いがあります。これらの仕様の変更の一部は、潜在的なセキュリティの問題をもたらす可能性があります。これらの問題のいくつかは、個別の文書で議論されていますが、RFCにならない可能性のある規範的な参照を避けるためにここにまとめられています。次の仕様関連の問題が特定されていますが、これは必ずしも完全なリストではありません。
All IPv6 nodes must be able to process routing headers [RFC2460]. This RFC can be interpreted, although it is not explicitly stated, to mean that all nodes (including hosts) must have this processing enabled. The "Requirements for Internet Hosts" [RFC1122] permits implementations to perform "local source routing", that is, forwarding a packet with a routing header through the same interface on which it was received: no restrictions are placed on this operation even on hosts. In combination, these rules can result in hosts forwarding received traffic to another node if there are segments left in the Routing Header when it arrives at the host.
すべてのIPv6ノードは、ルーティングヘッダー[RFC2460]を処理できる必要があります。このRFCは、明示的に述べられていませんが、すべてのノード（ホストを含む）がこの処理を有効にする必要があることを意味するため、解釈できます。「インターネットホストの要件」[RFC1122]により、実装は「ローカルソースルーティング」を実行できます。つまり、受信したのと同じインターフェイスを介してルーティングヘッダーを使用してパケットを転送できます。ホストでもこの操作にも制限はありません。。組み合わせて、これらのルールは、ホストに到着したときにルーティングヘッダーにセグメントが残っている場合、ホストが別のノードに受け取ったトラフィックを転送することになります。
A number of potential security issues associated with this behavior have been identified. Some of these issues have been resolved (a separate routing header (Type 2) has been standardized for Mobile IPv6 [RFC3775], and ICMP Traceback has not been standardized), but two issues remain: o Both existing types of routing header can be used to evade access controls based on destination addresses. This could be achieved by sending a packet ostensibly to a publicly accessible host address but with a routing header containing a 'forbidden' address. If the publicly accessible host is processing routing headers, it will forward the packet to the destination address in the routing header that would have been forbidden by the packet filters if the address had been in the destination field when the packet was checked.
この動作に関連する多くの潜在的なセキュリティ問題が特定されています。これらの問題のいくつかは解決されました（別のルーティングヘッダー（タイプ2）はモバイルIPv6 [RFC3775]に標準化されており、ICMPトレースバックは標準化されていません）が、2つの問題は残っています。宛先アドレスに基づいてアクセス制御を回避するため。これは、表面上はパケットを公開されているホストアドレスに送信することで実現できますが、「禁止」アドレスを含むルーティングヘッダーを使用することで実現できます。公開されているホストがルーティングヘッダーを処理している場合、パケットがチェックされたときにアドレスが宛先フィールドにあった場合、パケットフィルターによって禁止されていたルーティングヘッダーの宛先アドレスにパケットを転送します。
o If the packet source address can be spoofed when using a Type 0 routing header, the mechanism described in the previous bullet could be used with any host to mediate an anonymous reflection denial-of-service attack by having any publicly accessible host redirect the attack packets. (This attack cannot use Type 2 routing headers because the packet cannot be forwarded outside the host that processes the routing header, i.e., the original destination of the packet.)
o タイプ0ルーティングヘッダーを使用するときにパケットソースアドレスをスプーフィングできる場合、前の弾丸に記載されているメカニズムをホストと一緒に使用して、匿名の反射拒否攻撃を媒介して、攻撃パケットを公開できるホストをリダイレクトすることにより、サービスの拒否攻撃を媒介できます。。（この攻撃は、ルーティングヘッダー、つまりパケットの元の宛先を処理するホストの外側にパケットを転送できないため、タイプ2ルーティングヘッダーを使用できません。）
To counteract these threats, if a device is enforcing access controls based on destination addresses, it needs to examine both the destination address in the base IPv6 header and any waypoint destinations in a routing header that have not yet been reached by the packet at the point where it is being checked.
これらの脅威に対抗するために、デバイスが宛先アドレスに基づいてアクセス制御を強制している場合、ベースIPv6ヘッダーの宛先アドレスと、ポイントのパケットによってまだ到達していないルーティングヘッダーのウェイポイント宛先の両方を調べる必要があります。チェックされている場所。
Various forms of amplification attack on routers and firewalls using the routing header could be envisaged. A simple form involves repeating the address of a waypoint several times in the routing header. More complex forms could involve alternating waypoint addresses that would result in the packet re-transiting the router or firewall. These attacks can be counteracted by ensuring that routing headers do not contain the same waypoint address more than once, and performing ingress/egress filtering to check that the source address is appropriate to the destination: packets made to reverse their path will fail this test.
ルーティングヘッダーを使用したルーターとファイアウォールに対するさまざまな形式の増幅攻撃が想定される可能性があります。単純なフォームには、ルーティングヘッダーでウェイポイントのアドレスを数回繰り返すことが含まれます。より複雑なフォームには、パケットがルーターまたはファイアウォールを再編成することになるウェイポイントアドレスを交互にすることが含まれます。これらの攻撃は、ルーティングヘッダーに同じWayPointアドレスが複数回含まれていないことを保証し、イングレス/エグレスフィルタリングを実行して、ソースアドレスが宛先に適していることを確認することができます。
In addition to the basic Routing Header (Type 0), which is intended to influence the trajectory of a packet through a network by specifying a sequence of router waypoints, Routing Header (Type 2) has been defined as part of the Mobile IPv6 specifications in [RFC3775]. The Type 2 Routing Header is intended for use by hosts to handle 'interface local' forwarding needed when packets are sent to the care-of address of a mobile node that is away from its home address.
ルーターのウェイポイントのシーケンスを指定することにより、ネットワークを介したパケットの軌跡に影響を与えることを目的とした基本的なルーティングヘッダー（タイプ0）に加えて、ルーティングヘッダー（タイプ2）は、モバイルIPv6仕様の一部として定義されています。[RFC3775]。タイプ2ルーティングヘッダーは、ホストが自宅の住所から離れているモバイルノードのケアアドレスにパケットを送信するときに必要な「インターフェイスローカル」転送を処理するために使用することを目的としています。
It is important that nodes treat the different types of routing header appropriately. It should be possible to apply separate filtering rules to the different types of Routing Header. By design, hosts must process Type 2 Routing Headers to support Mobile IPv6 but routers should not: to avoid the issues in Section 2.1.1, it may be desirable to forbid or limit the processing of Type 0 Routing Headers in hosts and some routers.
ノードがさまざまなタイプのルーティングヘッダーを適切に扱うことが重要です。異なるタイプのルーティングヘッダーに個別のフィルタリングルールを適用することが可能です。設計上、ホストはモバイルIPv6をサポートするためにタイプ2のルーティングヘッダーを処理する必要がありますが、ルーターは次のとおりです。セクション2.1.1の問題を回避するには、ホストおよび一部のルーターのタイプ0ルーティングヘッダーの処理を禁止または制限することが望ましい場合があります。
Routing Headers are an extremely powerful and general capability. Alternative future uses of Routing Headers need to be carefully assessed to ensure that they do not open new avenues of attack that can be exploited.
ルーティングヘッダーは非常に強力で一般的な機能です。ルーティングヘッダーの代替将来の使用を慎重に評価する必要があります。
IPv6 supports multicast addresses with site scope that can potentially allow an attacker to identify certain important resources on the site if misused.
IPv6は、攻撃者が誤用された場合にサイト上の特定の重要なリソースを識別できる可能性があるサイトスコープでマルチキャストアドレスをサポートしています。
Particular examples are the 'all routers' (FF05::2) and 'all Dynamic Host Configuration Protocol (DHCP) servers' (FF05::1:3) addresses defined in [RFC2375]. An attacker that is able to infiltrate a message destined for these addresses on to the site will potentially receive in return information identifying key resources on the site. This information can then be the target of directed attacks ranging from simple flooding to more specific mechanisms designed to subvert the device.
特定の例は、「すべてのルーター」（FF05 :: 2）と「すべての動的ホスト構成プロトコル（DHCP）サーバー」（FF05 :: 1：3）が[RFC2375]で定義されているアドレスです。サイトにこれらのアドレスに任命されたメッセージに潜入できる攻撃者は、サイト上の重要なリソースを特定する返信情報で潜在的に受信します。この情報は、単純な洪水からデバイスを覆すように設計されたより具体的なメカニズムに至るまで、指示された攻撃のターゲットになります。
Some of these addresses have current legitimate uses within a site. The risk can be minimized by ensuring that all firewalls and site boundary routers are configured to drop packets with site-scope destination addresses. Also, nodes should not join multicast groups for which there is no legitimate use on the site, and site routers should be configured to drop packets directed to these unused addresses.
これらのアドレスの一部は、サイト内で現在の合法的な用途を持っています。すべてのファイアウォールとサイト境界ルーターが、サイトスコープの宛先アドレスでパケットをドロップするように構成されていることを保証することにより、リスクを最小限に抑えることができます。また、ノードは、サイトで正当な使用がないマルチキャストグループに参加してはなりません。また、これらの未使用のアドレスに向けられたパケットをドロップするようにサイトルーターを構成する必要があります。
It is possible to launch a Denial-of-Service (DoS) attack using IPv6 that could be amplified by the multicast infrastructure.
マルチキャストインフラストラクチャによって増幅できるIPv6を使用して、サービス拒否（DOS）攻撃を開始することができます。
Unlike ICMP for IPv4, ICMPv6 [RFC4443] allows error notification responses to be sent when certain unprocessable packets are sent to multicast addresses.
IPv4のICMPとは異なり、ICMPV6 [RFC4443]により、特定の処理不可能なパケットがマルチキャストアドレスに送信されると、エラー通知応答を送信できます。
The cases in which responses are sent are:
応答が送信される場合は次のとおりです。
o The received packet is longer than the next link Maximum Transmission Unit (MTU): 'Packet Too Big' responses are needed to support Path MTU Discovery for multicast traffic.
o 受信したパケットは、マルチキャストトラフィックのPATH MTUディスカバリーをサポートするために、次のリンク最大送信ユニット（MTU）よりも長いです。「パケットが大きすぎる」応答が必要です。
o The received packet contains an unrecognized option in a hop-by-hop or destination options extension header with the first two bits of the option type set to binary '10': 'Parameter Problem' responses are intended to inform the source that some or all of the recipients cannot handle the option in question.
o 受信したパケットには、ホップバイホップまたは宛先オプションエクステンションヘッダーの認識されていないオプションが含まれています。受信者の問題は、問題のオプションを処理できません。
If an attacker can craft a suitable packet sent to a multicast destination, it may be possible to elicit multiple responses directed at the victim (the spoofed source of the multicast packet). On the other hand, the use of 'reverse path forwarding' checks (to eliminate loops in multicast forwarding) automatically limits the range of addresses that can be spoofed.
攻撃者がマルチキャストの宛先に送信される適切なパケットを作成できる場合、被害者（マルチキャストパケットのスプーフィングされたソース）に向けられた複数の応答を引き出すことができる場合があります。一方、「逆パス転送」チェックの使用（マルチキャスト転送でループを排除するため）は、スプーフィングできるアドレスの範囲を自動的に制限します。
In practice, an attack using oversize packets is unlikely to cause much amplification unless the attacker is able to carefully tune the packet size to exploit a network with smaller MTU in the edge than the core. Similarly, a packet with an unrecognized hop-by-hop option would be dropped by the first router without resulting in multiple responses. However, a packet with an unrecognized destination option could generate multiple responses.
実際には、特大のパケットを使用した攻撃は、攻撃者がパケットサイズを慎重に調整して、コアよりも小さなMTUのネットワークを悪用することができない限り、多くの増幅を引き起こす可能性は低いです。同様に、認識されていないホップバイホップオプションを備えたパケットは、複数の応答をもたらすことなく、最初のルーターによってドロップされます。ただし、認識されていない宛先オプションを備えたパケットは、複数の応答を生成する可能性があります。
In addition to amplification, this kind of attack would potentially consume large amounts of forwarding state resources in routers on multicast-enabled networks.
増幅に加えて、この種の攻撃により、マルチキャスト対応ネットワーク上のルーター内の州のリソースを大量に転送する可能性があります。
Apart from the spurious load on the network, routers, and hosts, bogus ICMPv6 error messages (types 0 to 127) containing a spoofed errored packet can impact higher-layer protocols when the alleged errored packet is referred to the higher layer at the destination of the ICMPv6 packet [RFC4443]. The potentially damaging effects on TCP connections, and some ways to mitigate the threats, are documented in [ICMP-ATT].
ネットワーク、ルーター、およびホストの偽の負荷とは別に、偽のエラーパケットを含む偽のICMPV6エラーメッセージ（タイプ0〜127）は、疑わしいエラーパケットが高層プロトコルに影響を与える可能性があります。ICMPV6パケット[RFC4443]。TCP接続に対する潜在的な損傷の影響、および脅威を軽減するいくつかの方法は、[ICMP-ATT]で文書化されています。
Specific countermeasures for particular higher-layer protocols are beyond the scope of this document, but firewalls may be able to help counter the threat by inspecting the alleged errored packet embedded in the ICMPv6 error message. Measures to mitigate the threat include: o The receiving host should test that the embedded packet is all or part of a packet that was transmitted by the host.
特定の高層プロトコルの特定の対策はこのドキュメントの範囲を超えていますが、Firewallsは、ICMPv6エラーメッセージに埋め込まれた疑いのあるエラーパケットを検査することにより、脅威に対抗するのに役立つ可能性があります。脅威を軽減するための措置は次のとおりです。o受信ホストは、埋め込まれたパケットがホストによって送信されたパケットのすべてまたは一部であることをテストする必要があります。
o The firewall may be able to test that the embedded packet contains addresses that would have been legitimate (i.e., would have passed ingress/egress filtering) for a packet sent from the receiving host, but the possibility of asymmetric routing of the outgoing and returning packets may prevent this sort of test depending on the topology of the network, the location of the firewall, and whether state synchronization between firewalls is in use.
o ファイアウォールは、埋め込まれたパケットに、受信ホストから送信されたパケットの合法的な（つまり、イングレス/出力フィルタリングに合格した）アドレスが含まれていることをテストできるかもしれませんが、発信およびリターンパケットの非対称ルーティングの可能性があります。ネットワークのトポロジ、ファイアウォールの位置、およびファイアウォール間の状態同期が使用されているかどうかに応じて、この種のテストを防ぐことができます。
o If the firewall is stateful and the test is not prevented by asymmetric routing, the firewall may also be able to check that the embedded packet is all or part of a packet that recently transited the firewall in the opposite direction.
o ファイアウォールがステートフルであり、テストが非対称ルーティングによって防止されない場合、ファイアウォールは、埋め込まれたパケットが最近ファイアウォールを反対方向に通過したパケットのすべてまたは一部であることを確認することもできます。
o Firewalls and destination hosts should be suspicious of ICMPv6 error messages with unnecessarily truncated errored packets (e.g., those that only carry the address fields of the IPv6 base header). The specification of ICMPv6 requires that error messages carry as much of the errored packet as possible (unlike ICMP for IPv4 which requires only a minimum amount of the errored packet) and IPv6 networks must have a guaranteed minimum MTU of 1280 octets. Accordingly, the ICMPv6 message should normally carry all the header fields of the errored packet, together with a significant amount of the payload, in order to allow robust comparison against the outgoing packet.
o ファイアウォールと宛先ホストは、不必要に切り捨てられたエラーパケット（例えば、IPv6ベースヘッダーのアドレスフィールドのみを運ぶもの）を使用したICMPV6エラーメッセージを疑う必要があります。ICMPV6の仕様では、エラーメッセージが可能な限り多くのエラーパケットを持ち運ぶ必要があります（エラーパケットの最小量のみを必要とするIPv4のICMPとは異なります）。したがって、ICMPV6メッセージは通常、発信パケットとの堅牢な比較を可能にするために、エラーパケットのすべてのヘッダーフィールドとかなりの量のペイロードを運ぶ必要があります。
IPv6 introduces the notion of anycast addresses and services. Originally the IPv6 standards disallowed using an anycast address as the source address of a packet. Responses from an anycast server would therefore supply a unicast address for the responding server. To avoid exposing knowledge about the internal structure of the network, it is recommended that anycast servers now take advantage of the ability to return responses with the anycast address as the source address if possible.
IPv6は、Anycastアドレスとサービスの概念を紹介します。もともとは、パケットのソースアドレスとしてanycastアドレスを使用して、IPv6標準が禁止されていました。したがって、Anycastサーバーからの応答は、応答するサーバーにユニキャストアドレスを提供します。ネットワークの内部構造に関する知識を公開することを避けるために、可能であれば、Anycastアドレスを使用して応答を返す機能を利用することができるようになりました。
If the server needs to use a unicast address for any reason, it may be desirable to consider using specialized addresses for anycast servers, which are not used for any other part of the network, to restrict the information exposed. Alternatively, operators may wish to restrict the use of anycast services from outside the domain, thus requiring firewalls to filter anycast requests. For this purpose, firewalls need to know which addresses are being used for anycast services: these addresses are arbitrary and not distinguishable from any other IPv6 unicast address by structure or pattern.
サーバーが何らかの理由でユニキャストアドレスを使用する必要がある場合、ネットワークの他の部分には使用されていないAnycastサーバーに特殊なアドレスを使用して、公開された情報を制限することを検討することが望ましい場合があります。あるいは、オペレーターは、ドメインの外部からAnycastサービスの使用を制限したい場合があるため、AnyCastリクエストをフィルタリングするためにファイアウォールが必要です。この目的のために、ファイアウォールは、どのアドレスがAnycastサービスに使用されているかを知る必要があります。これらのアドレスは任意であり、構造またはパターンによって他のIPv6ユニキャストアドレスと区別できません。
One particular class of anycast addresses that should be given special attention is the set of Subnet-Router anycast addresses defined in "IP Version 6 Addressing Architecture" [RFC4291]. All routers are required to support these addresses for all subnets for which they have interfaces. For most subnets using global unicast addresses, filtering anycast requests to these addresses can be achieved by dropping packets with the lower 64 bits (the Interface Identifier) set to all zeros.
特別な注意を払う必要があるAnyCastアドレスの特定のクラスの1つは、「IPバージョン6アドレス指定アーキテクチャ」[RFC4291]で定義されているサブネットルーターのANYCASTアドレスのセットです。すべてのルーターは、インターフェイスがあるすべてのサブネットのこれらのアドレスをサポートする必要があります。グローバルユニキャストアドレスを使用したほとんどのサブネットの場合、これらのアドレスへのAnycastリクエストのフィルタリングは、すべてのゼロに設定された低い64ビット（インターフェイス識別子）でパケットを削除することで実現できます。
The purpose of the privacy extensions for stateless address autoconfiguration [RFC4941] is to change the interface identifier (and hence the global scope addresses generated from it) from time to time. By varying the addresses used, eavesdroppers and other information collectors find it more difficult to identify which transactions actually relate to a specific node.
Stateless Address Autoconfiguration [RFC4941]のプライバシー拡張機能の目的は、インターフェイス識別子（したがって、それから生成されたグローバルスコープアドレス）を随時変更することです。使用されるアドレスを変更することにより、盗聴者やその他の情報コレクターは、実際に特定のノードに関連するトランザクションを特定するのがより困難です。
A security issue may result from this if the frequency of node address change is sufficiently great to achieve the intended aim of the privacy extensions: with a relatively high rate of change, the observed behavior has some characteristics of a node or nodes involved in a Distributed Denial-of-Service (DDoS) attack. It should be noted, however, that addresses created in this way are topologically correct and that the other characteristics of the traffic may reveal that there is no malicious intent.
ノードアドレスの変更の頻度がプライバシー拡張の目的を達成するのに十分に優れている場合、セキュリティの問題が発生する場合があります。変化率が比較的高い場合、観察された動作には、分散型に関与するノードまたはノードのいくつかの特性があります。サービス拒否（DDOS）攻撃。ただし、この方法で作成されたアドレスは、トポロジー的に正しいものであり、トラフィックの他の特性が悪意のある意図がないことを明らかにする可能性があることに注意する必要があります。
This issue can be addressed in most cases by tuning the rate of change in an appropriate manner.
この問題は、ほとんどの場合、適切な方法で変化率を調整することで対処できます。
Note that even if a node is well behaved, a change in the address could make it harder for a security administrator to define an address-based policy rule (e.g., access control list). However, nodes that employ privacy addresses do not have to use them for all communications.
ノードが適切に動作していても、アドレスの変更により、セキュリティ管理者がアドレスベースのポリシールール（アクセス制御リストなど）を定義することが難しくなる可能性があることに注意してください。ただし、プライバシーアドレスを使用するノードは、すべての通信にそれらを使用する必要はありません。
The introduction of Stateless Address Autoconfiguration (SLAAC) [RFC2462] with IPv6 provides an additional challenge to the security of Dynamic Domain Name System (DDNS). With manual addressing or the use of DHCP, the number of security associations that need to be maintained to secure access to the Domain Name Service (DNS) server is limited, assuming any necessary updates are carried out by the DHCP server. This is true equally for IPv4 and IPv6.
IPv6を使用したStatelesterアドレスAutoconfiguration（SLAAC）[RFC2462]の導入は、動的ドメイン名システム（DDNS）のセキュリティに追加の課題を提供します。手動アドレス指定またはDHCPの使用により、DHCPサーバーによって必要な更新が実行されると仮定して、ドメイン名サービス（DNS）サーバーへのアクセスを保護するために維持する必要があるセキュリティ協会の数が限られています。これは、IPv4とIPv6に等しく当てはまります。
Since SLAAC does not make use of a single and potentially trusted DHCP server, but depends on the node obtaining the address, securing the insertion of updates into DDNS may need a security association between each node and the DDNS server. This is discussed further in [RFC4472].
SLAACは単一の潜在的に信頼できるDHCPサーバーを使用していないが、アドレスを取得するノードに依存するため、DDNSへの更新の挿入を保護するには、各ノードとDDNSサーバーの間にセキュリティ関連が必要になる場合があります。これについては、[RFC4472]でさらに説明します。
Using the Privacy Extensions to SLAAC [RFC4941] may significantly increase the rate of updates of DDNS. Even if a node using the Privacy Extensions does not publish its address for 'forward' lookup (as that would effectively compromise the privacy that it is seeking), it may still need to update the reverse DNS records. If the reverse DNS records are not updated, servers that perform reverse DNS checks will not accept connections from the node and it will not be possible to gain access to IP Security (IPsec) keying material stored in DNS [RFC4025]. If the rate of change needed to achieve real privacy has to be increased (see Section 2.1.7), the update rate for DDNS may be excessive.
プライバシー拡張機能をSLAAC [RFC4941]に使用すると、DDNSの更新率が大幅に増加する場合があります。プライバシー拡張機能を使用してノードが「フォワード」ルックアップのアドレスを公開していなくても（求めているプライバシーを効果的に損なうため）、逆DNSレコードを更新する必要がある場合があります。逆DNSレコードが更新されない場合、逆DNSチェックを実行するサーバーはノードからの接続を受け入れず、DNSに保存されているIPセキュリティ（IPSEC）キーイング材料にアクセスすることはできません[RFC4025]。実際のプライバシーを達成するために必要な変化率を増やす必要がある場合（セクション2.1.7を参照）、DDNの更新率は過剰になる可能性があります。
Similarly, the cryptographically generated addresses used by SEND [RFC3971] are expected to be periodically regenerated in line with recommendations for maximum key lifetimes. This regeneration could also impose a significant extra load on DDNS.
同様に、送信[RFC3971]で使用される暗号化されたアドレスは、最大の主要な寿命の推奨事項に沿って定期的に再生されると予想されます。この再生は、DDNにかなりの余分な負荷を課す可能性があります。
A number of security issues relating to IPv6 Extension headers have been identified. Several of these are a result of ambiguous or incomplete specification in the base IPv6 specification [RFC2460].
IPv6拡張ヘッダーに関連する多くのセキュリティ問題が特定されています。これらのいくつかは、ベースIPv6仕様[RFC2460]における曖昧または不完全な仕様の結果です。
In IPv4, deep packet inspection techniques are used to implement policing and filtering both as part of routers and in middleboxes such as firewalls. Fully extending these techniques to IPv6 would require inspection of all the extension headers in a packet. This is essential to ensure that policy constraints on the use of certain headers and options are enforced and to remove, at the earliest opportunity, packets containing potentially damaging unknown options.
IPv4では、ルーターの一部として、およびファイアウォールなどのミドルボックスの両方としてポリシングとフィルタリングを実装するために、ディープパケット検査技術を使用しています。これらの手法をIPv6に完全に拡張するには、パケット内のすべての拡張ヘッダーを検査する必要があります。これは、特定のヘッダーとオプションの使用に関するポリシーの制約が実施され、潜在的に損害を与える不明なオプションを含む最も早い機会に削除されることを保証するために不可欠です。
This requirement appears to conflict with Section 4 of the IPv6 specification in [RFC2460] which requires that only hop-by-hop options are processed at any node through which the packet passes until the packet reaches the appropriate destination (either the final destination or a routing header waypoint).
この要件は、[RFC2460]のIPv6仕様のセクション4と競合するように見えます。これは、パケットが適切な宛先（最終目的地またはルーティングヘッダーウェイポイント）。
Also, [RFC2460] forbids processing the headers other than in the order in which they appear in the packet.
また、[RFC2460]は、パケットに表示される順序以外のヘッダーの処理を禁止します。
A further ambiguity relates to whether an intermediate node should discard a packet that contains a header or destination option which it does not recognize. If the rules above are followed slavishly, it is not (or may not be) legitimate for the intermediate node to discard the packet because it should not be processing those headers or options.
さらにあいまいさは、中間ノードが認識されていないヘッダーまたは宛先オプションを含むパケットを破棄する必要があるかどうかに関連しています。上記のルールが奴隷的に従っている場合、中間ノードがパケットを破棄することは、それらのヘッダーまたはオプションを処理してはならないため、パケットを破棄することは正当ではありません（またはそうではないかもしれません）。
Therefore, [RFC2460] does not appear to take account of the behavior of middleboxes and other non-final destinations that may be inspecting the packet, and thereby potentially limits the security protection of these boxes. Firewall vendors and administrators may choose to ignore these rules in order to provide enhanced security as this does not appear to have any serious consequences with the currently defined set of extensions. However, administrators should be aware that future extensions might require different treatment.
したがって、[RFC2460]は、パケットを検査している可能性のあるミドルボックスや他の非ファイナルの目的地の動作を考慮していないようであり、それによりこれらのボックスのセキュリティ保護を制限する可能性があります。ファイアウォールベンダーと管理者は、現在定義されている拡張セットに深刻な結果をもたらさないように見えるため、強化されたセキュリティを提供するためにこれらのルールを無視することを選択できます。ただし、管理者は、将来の拡張が異なる治療を必要とする場合があることに注意する必要があります。
There is a further problem for middleboxes that want to examine the transport headers that are located at the end of the IPv6 header chain. In order to locate the transport header or other protocol data unit, the node has to parse the header chain.
IPv6ヘッダーチェーンの端にあるトランスポートヘッダーを調べたいというミドルボックスには、さらなる問題があります。トランスポートヘッダーまたはその他のプロトコルデータユニットを見つけるために、ノードはヘッダーチェーンを解析する必要があります。
The IPv6 specification [RFC2460] does not mandate the use of the Type-Length-Value (TLV) format with a fixed layout for the start of each header although it is used for the majority of headers currently defined. (Only the Type field is guaranteed in size and offset.)
IPv6仕様[RFC2460]は、現在定義されているヘッダーの大部分に使用されていますが、各ヘッダーの開始に固定レイアウトを使用して、タイプ長値（TLV）形式の使用を義務付けません。（タイプフィールドのみがサイズとオフセットで保証されています。）
Therefore, a middlebox cannot guarantee to be able to process header chains that may contain headers defined after the box was manufactured. As discussed further in Section 2.1.9.3, middleboxes ought not to have to know the detailed layout of all header types in use but still need to be able to skip over such headers to find the transport payload start. If this is not possible, it either limits the security policy that can be applied in firewalls or makes it difficult to deploy new extension header types.
したがって、ミドルボックスは、ボックスが製造された後に定義されたヘッダーを含む可能性のあるヘッダーチェーンを処理できることを保証することはできません。セクション2.1.9.3でさらに説明したように、ミドルボックスは、使用中のすべてのヘッダータイプの詳細なレイアウトを知る必要はありませんが、そのようなヘッダーをスキップしてトランスポートペイロードの開始を見つける必要があります。これが不可能な場合、ファイアウォールに適用できるセキュリティポリシーを制限するか、新しい拡張ヘッダータイプの展開を困難にします。
At the time of writing, only the Fragment Header does not fully conform to the TLV format used for other extension headers. In practice, many firewalls reconstruct fragmented packets before performing deep packet inspection, so this divergence is less problematic than it might have been, and is at least partially justified because the full header chain is not present in all fragments.
執筆時点では、フラグメントヘッダーのみが他の拡張ヘッダーに使用されるTLV形式に完全に準拠していません。実際には、多くのファイアウォールは、深いパケット検査を実行する前に断片化されたパケットを再構築するため、この発散はこれまでよりも問題が少なく、完全なヘッダーチェーンがすべてのフラグメントに存在しないため、少なくとも部分的に正当化されます。
Hop-by-hop and destination options may also contain unknown options. However, the options are required to be encoded in TLV format so that intermediate nodes can skip over them during processing, unlike the enclosing extension headers.
ホップバイホップと宛先オプションには、不明なオプションが含まれている場合があります。ただし、囲まれた拡張ヘッダーとは異なり、処理中に中間ノードがスキップできるように、オプションはTLV形式でエンコードする必要があります。
A strict security policy might dictate that packets containing either unknown headers or destination options are discarded by firewalls or other filters. This requires the firewall to process the whole extension header chain, which may be currently in conflict with the IPv6 specification as discussed in Section 2.1.9.1.
厳格なセキュリティポリシーは、未知のヘッダーまたは宛先オプションを含むパケットがファイアウォールまたは他のフィルターによって破棄されることを決定する場合があります。これには、セクション2.1.9.1で説明されているように、現在拡張ヘッダーチェーン全体を処理するためのファイアウォールが必要です。
Even if the firewall does inspect the whole header chain, it may not be sensible to discard packets with items unrecognized by the firewall: the intermediate node has no knowledge of which options and headers are implemented in the destination node and IPv6 has been deliberately designed to be extensible through adding new header options. This poses a dilemma for firewall administrators. On the one hand, admitting packets with 'unknown' options is a security risk, but dropping them may disable a useful new extension. The best compromise appears to be to select firewalls that provide a configurable discard policy based on the types of the extensions. Then, if a new extension is standardized, administrators can reconfigure firewalls to pass packets with legitimate items that they would otherwise not recognize because their hardware or software is not aware of a new definition. Provided that the new extensions conform to the TLV layout followed by current extensions, the firewall would not need detailed knowledge of the function or layout of the extension header.
ファイアウォールがヘッダーチェーン全体を検査したとしても、ファイアウォールによって認識されていないアイテムでパケットを破棄することは賢明ではない場合があります。新しいヘッダーオプションを追加することで拡張可能になります。これは、ファイアウォール管理者にジレンマをもたらします。一方では、「不明な」オプションでパケットを認めることはセキュリティリスクですが、それらを削除すると有用な新しい拡張機能が無効になる場合があります。最良の妥協点は、拡張機能の種類に基づいて構成可能な破棄ポリシーを提供するファイアウォールを選択することです。次に、新しい拡張機能が標準化されている場合、管理者はファイアウォールを再構成して、ハードウェアやソフトウェアが新しい定義を認識していないために認識されない正当なアイテムでパケットを渡すことができます。新しいエクステンションがTLVレイアウトに続いて電流拡張機能に準拠している場合、ファイアウォールは拡張ヘッダーの関数またはレイアウトの詳細な知識を必要としません。
IPv6 does not limit the number of hop-by-hop options that can be present in a hop-by-hop option header, and any option can appear multiple times. The lack of a limit and the provision of extensibility bits that force nodes to ignore classes of options that they do not understand can be used to mount denial-of-service attacks affecting all nodes on a path. A packet with large numbers of unknown hop-by-hop options will be processed at every node through which it is forwarded, consuming significant resources to determine what action should be taken for each option. Current options with the exception of Pad1 and PadN should not appear more than once so that packets with inappropriately repeated options can be dropped. However, keeping track of which options have been seen adds complexity to firewalls and may not apply to future extensions. See Section 2.1.9.3 for a discussion of the advisability of dropping packets with unknown options in firewalls.
IPv6は、ホップバイホップオプションヘッダーに存在できるホップバイホップオプションの数を制限せず、任意のオプションが複数回表示される可能性があります。制限の欠如とノードに強制される拡張性ビットの提供は、彼らが理解していないオプションのクラスを無視するように強制することは、パス上のすべてのノードに影響を与えるサービス拒否攻撃をマウントするために使用できます。多数の未知のホップバイホップオプションを備えたパケットは、転送されるすべてのノードで処理され、各オプションに対してどのようなアクションを実行するかを決定するために重要なリソースを消費します。PAD1とPADNを除く現在のオプションは、不適切に繰り返されるオプションを備えたパケットを削除できるように、複数回表示しないでください。ただし、どのオプションが見られるかを追跡すると、ファイアウォールに複雑さが加わり、将来の拡張機能には適用されない場合があります。ファイアウォールに不明なオプションを備えたパケットをドロップすることの賢明性についての議論については、セクション2.1.9.3を参照してください。
IPv6 allows multiple padding options of arbitrary sizes to be placed in both Hop-by-Hop and Destination option headers.
IPv6を使用すると、任意のサイズの複数のパディングオプションをホップバイホップと宛先オプションヘッダーの両方に配置できます。
PadN options are required to contain zero octets as 'payload'; there is, however, no incentive for receivers to check this. It may therefore be possible to use the 'payload' of padding options as a covert channel. Firewalls and receiving hosts should actively check that PadN only has zero octets in its 'payload'.
ゼロオクテットを「ペイロード」として含めるには、PADNオプションが必要です。ただし、受信者がこれを確認するインセンティブはありません。したがって、パディングオプションの「ペイロード」を秘密のチャネルとして使用することが可能かもしれません。ファイアウォールと受信ホストは、PADNが「ペイロード」にゼロオクテットしかないことを積極的に確認する必要があります。
There is no legitimate reason for padding beyond the next eight octet boundary since the whole option header is aligned on an eight-octet boundary but cannot be guaranteed to be on a 16 (or higher power of two)-octet boundary. The IPv6 specification allows multiple Pad1 and PadN options to be combined in any way that the source chooses to make up the required padding. Reasonable design choices would appear to be using however many Pad1 options (i.e., zero octets) are needed or using a single PadN option of the required size (from two up to seven octets). Administrators should consider at least logging unusual padding patterns, and may consider dropping packets that contain unusual patterns if they are certain of expected source behavior.
オプションヘッダー全体が8オクテットの境界に揃っているが、16（または2つのより高い電力）オクテット境界にあることを保証することはできないため、次の8オクテットの境界を越えてパディングする正当な理由はありません。IPv6仕様により、ソースが必要なパディングを構成することを選択する方法で、複数のPAD1とPADNオプションを組み合わせることができます。合理的な設計の選択肢は、多くのPAD1オプション（つまり、ゼロオクテット）が必要であるか、必要なサイズの単一のPADNオプション（2つの最大7オクテットから）を使用しているように見えます。管理者は、少なくとも異常なパディングパターンを記録することを検討する必要があり、予想されるソース動作を確信している場合は、異常なパターンを含むパケットをドロップすることを検討する場合があります。
The IPv6 router alert option specifies a hop-by-hop option that, if present, signals the router to take a closer look at the packet. This can be used for denial-of-service attacks. By sending a large number of packets containing a router alert option, an attacker can deplete the processor cycles on the routers available to legitimate traffic.
IPv6ルーターアラートオプションは、存在する場合、ルーターを通知してパケットを詳しく調べるホップバイホップオプションを指定します。これは、サービス拒否攻撃に使用できます。ルーターアラートオプションを含む多数のパケットを送信することにより、攻撃者は合法的なトラフィックで利用可能なルーターのプロセッササイクルを枯渇させる可能性があります。
The current specifications of IPv6 in [RFC2460] do not mandate any minimum packet size for the fragments of a packet before the last one, except for the need to carry the unfragmentable part in all fragments.
[RFC2460]のIPv6の現在の仕様は、すべてのフラグメントに不正確な部分を運ぶ必要性を除いて、最後のパケットのフラグメントの最小パケットサイズの最小パケットサイズを義務付けません。
The unfragmentable part does not include the transport port numbers, so it is possible that the first fragment does not contain sufficient information to carry out deep packet inspection involving the port numbers.
不正確な部分には輸送ポート番号が含まれていないため、最初のフラグメントには、ポート番号を含む深いパケット検査を実行するのに十分な情報が含まれていない可能性があります。
Packets with overlapping fragments are considered to be a major security risk, but the reassembly rules for fragmented packets in [RFC2460] do not mandate behavior that would minimize the effects of overlapping fragments.
オーバーラップフラグメントを備えたパケットは主要なセキュリティリスクであると見なされますが、[RFC2460]の断片化されたパケットの再組み立てルールは、オーバーラップフラグメントの効果を最小限に抑える動作を義務付けません。
In order to ensure that deep packet inspection can be carried out correctly on fragmented packets, many firewalls and other nodes that use deep packet inspection will collect the fragments and reassemble the packet before examining it. Depending on the implementation of packet reassembly and the treatment of packet fragments in these nodes, the specification issues mentioned potentially leave IPv6 open to the sort of attacks described in [RFC1858] and [RFC3128] for IPv4.
断片化されたパケットで深いパケット検査を正しく実行できるようにするために、ディープパケット検査を使用する多くのファイアウォールやその他のノードは、断片を収集し、パケットを調べる前に再組み立てします。パケットの再組み立ての実装とこれらのノード内のパケットフラグメントの処理に応じて、言及された仕様の問題は、IPv4の[RFC1858]および[RFC3128]に記載されている攻撃の種類にIPv6を開いたままにする可能性があります。
The following steps can be taken to mitigate these threats:
これらの脅威を軽減するために、次の手順をとることができます。
o Although permitted in [RFC2460], there is no reason for a source to generate overlapping packet fragments, and overlaps could be prohibited in a future revision of the protocol specification. Firewalls should drop all packets with overlapped fragments: certain implementations both in firewalls and other nodes already drop such packets.
o [RFC2460]で許可されていますが、ソースが重複するパケットフラグメントを生成する理由はありません。また、プロトコル仕様の将来の改訂ではオーバーラップが禁止される可能性があります。ファイアウォールは、オーバーラップフラグメントですべてのパケットをドロップする必要があります。ファイアウォールと他のノードの両方で特定の実装はすでにそのようなパケットをドロップします。
o Specifying a minimum size for packet fragments does not help in the same way as it does for IPv4 because IPv6 extension headers can be made to appear very long: an attacker could insert one or more undefined destination options with long lengths and the 'ignore if unknown' bit set. Given the guaranteed minimum MTU of IPv6, it seems reasonable that hosts should be able to ensure that the transport port numbers are in the first fragment in almost all cases and that deep packet inspection should be very suspicious of first fragments that do not contain them (see also the discussion of fragment sizes in Section 2.1.11).
o パケットフラグメントの最小サイズを指定することは、IPv6拡張ヘッダーを非常に長く表示できるため、IPv4の場合と同じように役立ちません。攻撃者は、長さの長さで1つ以上の未定義の宛先オプションを挿入でき、「不明の場合は無視する」'ビットセット。IPv6の最小MTUが保証されていることを考えると、ホストがほとんどすべての場合に輸送ポート番号が最初のフラグメントにあることを保証できるはずであり、深いパケット検査は、それらを含む最初のフラグメントを非常に疑っている必要があると思われます（セクション2.1.11のフラグメントサイズの説明も参照してください。
Packet reassembly in IPv6 hosts also opens up the possibility of various fragment-related security attacks. Some of these are analogous to attacks identified for IPv4. Of particular concern is a DoS attack based on sending large numbers of small fragments without a terminating last fragment that would potentially overload the reconstruction buffers and consume large amounts of CPU resources.
IPv6ホストのパケット再組み立ては、さまざまなフラグメント関連のセキュリティ攻撃の可能性も開きます。これらのいくつかは、IPv4で特定された攻撃に類似しています。特に懸念されるのは、再構築バッファーに過負荷をかけ、大量のCPUリソースを消費する可能性のある最後のフラグメントを終了することなく、多数の小さなフラグメントを送信することに基づくDOS攻撃です。
Mandating the size of packet fragments could reduce the impact of this kind of attack by limiting the rate at which fragments could arrive and limiting the number of fragments that need to be processed, but this is not currently specified by the IPv6 standard. In practice, reasonable design choices in protocol stacks are likely to either maximize the size of all fragments except the final one using the path MTU (most likely choice), or distribute the data evenly in the required minimum number of fragments. In either case, the smallest non-final fragment would be at least half the guaranteed minimum MTU (640 octets) -- the worst case arises when a payload is just too large for a single packet and is divided approximately equally between two packets. Administrators should consider configuring firewalls and hosts to drop non-final fragments smaller than 640 octets.
パケットフラグメントのサイズを義務付けることは、フラグメントが到着する速度を制限し、処理する必要があるフラグメントの数を制限することにより、この種の攻撃の影響を減らすことができますが、これは現在IPv6標準では指定されていません。実際には、プロトコルスタックの合理的な設計の選択は、パスMTUを使用して最後のフラグメントを除くすべてのフラグメントのサイズを最大化する（最も可能性の高い選択）か、必要な最小フラグメント数でデータを均等に配布する可能性があります。どちらの場合でも、最小の非ファイナルフラグメントは、保証された最小MTU（640オクテット）の少なくとも半分の半分になります。最悪の場合は、ペイロードが1つのパケットに対して大きすぎて2つのパケット間でほぼ等しく分割されている場合に発生します。管理者は、ファイアウォールとホストを構成するように、640オクテットよりも小さい非ファイナルフラグメントを削除することを検討する必要があります。
All IPv6 nodes are required to configure a link-local address on each interface. This address is used to communicate with other nodes directly connected to the link accessed via the interface, especially during the neighbor discovery and autoconfiguration processes. Link-local addresses are fundamental to the operation of the Neighbor Discovery Protocol (NDP) [RFC2461] and Stateless Address Autoconfiguration (SLAAC) [RFC2462]. NDP also provides the functionality of associating link-layer and IP addresses provided by the Address Resolution Protocol (ARP) in IPv4 networks.
すべてのIPv6ノードは、各インターフェイスでリンクローカルアドレスを構成するために必要です。このアドレスは、特に近隣発見およびオートコンフィギュレーションプロセス中に、インターフェイスを介してアクセスされたリンクに直接接続された他のノードと通信するために使用されます。リンクローカルアドレスは、Neighbor Discovery Protocol（NDP）[RFC2461]およびStateless Address Autoconfiguration（SLAAC）[RFC2462]の操作の基本です。NDPは、IPv4ネットワークのアドレス解像度プロトコル（ARP）によって提供されるリンク層とIPアドレスの関連付けの機能も提供します。
The standard version of NDP is subject to a number of security threats related to ARP spoofing attacks on IPv4. These threats are documented in [RFC3756], and mechanisms to combat them are specified in SEcure Neighbor Discovery (SEND) [RFC3971]. SEND is an optional mechanism that is particularly applicable to wireless and other environments where it is difficult to physically secure the link.
NDPの標準バージョンは、IPv4に対するARPスプーフィング攻撃に関連する多くのセキュリティ脅威の対象となります。これらの脅威は[RFC3756]に文書化されており、それらと戦うメカニズムは、安全な隣接発見（SEND）[RFC3971]で指定されています。Sendは、リンクを物理的に保護することが困難なワイヤレスおよびその他の環境に特に適用できるオプションのメカニズムです。
Because the link-local address can, by default, be acquired without external intervention or control, it allows an attacker to commence communication on the link without needing to acquire information about the address prefixes in use or communicate with any authorities on the link. This feature gives a malicious node the opportunity to mount an attack on any other node that is attached to this link; this vulnerability exists in addition to possible direct attacks on NDP. Link-local addresses may also facilitate the unauthorized use of the link bandwidth ('bandwidth theft') to communicate with another unauthorized node on the same link.
リンクローカルアドレスは、デフォルトで外部の介入または制御なしで取得できるため、攻撃者は、使用中のアドレスのプレフィックスに関する情報を取得したり、リンク上の当局と通信したりすることなく、リンクでの通信を開始できます。この機能により、悪意のあるノードがこのリンクに添付されている他のノードに攻撃を取り付ける機会を提供します。この脆弱性は、NDPに対する直接的な攻撃の可能性に加えて存在します。リンクローカルアドレスは、リンク帯域幅（「帯域幅の盗難」）の不正使用を容易にして、同じリンク上の別の不正なノードと通信する可能性があります。
The vulnerabilities of IPv6 link-local addresses in NDP can be mitigated in several ways. A general solution will require
NDPにおけるIPv6 Link-Localアドレスの脆弱性は、いくつかの方法で軽減できます。一般的なソリューションが必要です
o authenticating the link-layer connectivity, for example, by using IEEE 802.1X functionality [IEEE.802-1X] or physical security, and
o たとえば、IEEE 802.1x機能[IEEE.802-1x]または物理的セキュリティを使用して、リンク層の接続性を認証し、
o using SEcure Neighbor Discovery (SEND) to create a cryptographically generated link-local address (as described in [RFC3971]) that is tied to the authenticated link-layer address.
o Secure Neighbor Discovery（送信）を使用して、認証されたリンク層アドレスに関連付けられた暗号化されたリンクローカルアドレス（[RFC3971]で説明されている）を作成します。
This solution would be particularly appropriate in wireless LAN deployments where it is difficult to physically secure the infrastructure, but it may not be considered necessary in wired environments where the physical infrastructure can be kept secure by other means.
このソリューションは、インフラストラクチャを物理的に保護することが困難なワイヤレスLAN展開で特に適切ですが、物理インフラストラクチャを他の手段で安全に保つことができる有線環境では必要とは見なされない場合があります。
Limiting the potentiality for abuse of link-local addresses in general packet exchanges is more problematic because there may be circumstances, such as isolated networks, where usage is appropriate and discrimination between use and abuse requires complex filtering rules which have to be implemented on hosts. The risk of misuse may be deemed too small compared with the effort needed to control it, but special attention should be paid to tunnel end-points (see 2.4, 3.2, and 3.3).
一般的なパケット交換におけるリンクローカルアドレスの乱用の可能性を制限することは、使用が適切であり、使用と乱用の差別が必要な孤立したネットワークなどの状況がある可能性があるため、より問題があります。誤用のリスクは、それを制御するために必要な努力と比較して小さすぎると見なされる場合がありますが、トンネルのエンドポイントに特別な注意を払う必要があります（2.4、3.2、および3.3を参照）。
Any filtering has to be provided by a host-based or bridging firewall. In general, link-local addresses are expected to be used by applications that are written to deal with specific interfaces and links. Typically these applications are used for control and management. A node which is attached to multiple links has to deal with the potentially overlapping link-local address spaces associated with these links. IPv6 provides for this through zone identifiers that are used to discriminate between the different address scopes [RFC4007] and the scope identifier that can be associated with a socket address structure [RFC3493]. Most users are unfamiliar with these issues and general purpose applications are not intended to handle this kind of discrimination. link-local addresses are not normally used with the Domain Name System (DNS), and DNS cannot supply zone identifiers. If it is considered necessary to prevent the use of link-local addresses by means other than control and management protocols, administrators may wish to consider limiting the protocols that can be used with link-local addresses. At a minimum, ICMPv6 and any intra-domain routing protocol in use (such as Open Shortest Path First (OSPF) or Routing Information Protocol (RIP)) need to be allowed, but other protocols may also be needed. RIP illustrates the complexity of the filtering problem: its messages are encapsulated as User Datagram Protocol (UDP) payloads, and filtering needs to distinguish RIP messages addressed to UDP port 521 from other UDP messages.
ホストベースまたはブリッジングファイアウォールによってフィルタリングを提供する必要があります。一般に、Link-Localアドレスは、特定のインターフェイスとリンクを扱うために書かれたアプリケーションで使用されることが期待されています。通常、これらのアプリケーションは制御と管理に使用されます。複数のリンクに接続されているノードは、これらのリンクに関連する潜在的に重複するリンクローカルアドレススペースを処理する必要があります。IPv6は、異なるアドレススコープ[RFC4007]とソケットアドレス構造[RFC3493]に関連付けられるスコープ識別子を区別するために使用されるゾーン識別子を介して提供します。ほとんどのユーザーはこれらの問題に不慣れであり、汎用アプリケーションはこの種の差別を処理することを意図していません。Link-Localアドレスは通常、ドメイン名システム（DNS）で使用されず、DNSはゾーン識別子を供給できません。コントロールおよび管理プロトコル以外の手段でリンクローカルアドレスの使用を防ぐ必要があると考えられている場合、管理者はリンクローカルアドレスで使用できるプロトコルの制限を検討することをお勧めします。少なくとも、ICMPV6および使用中のドメイン内ルーティングプロトコル（最初のオープンパス（OSPF）やルーティング情報プロトコル（RIP）など）を許可する必要がありますが、他のプロトコルも必要になる場合があります。RIPは、フィルタリングの問題の複雑さを示しています。そのメッセージは、ユーザーデータグラムプロトコル（UDP）ペイロードとしてカプセル化されており、フィルタリングはUDPポート521にアドレス指定されたRIPメッセージを他のUDPメッセージと区別する必要があります。
As part of the Neighbor Discovery process, routers on a link advertise their capabilities in Router Advertisement messages. The version of NDP defined in [RFC2461] does not protect the integrity of these messages or validate the assertions made in the messages with the result that any node that connects to the link can maliciously claim to offer routing services that it will not fulfill, and advertise inappropriate prefixes and parameters. These threats have been documented in [RFC3756].
Neighbor Discoveryプロセスの一環として、リンク上のルーターはルーター広告メッセージに機能を宣伝しています。[RFC2461]で定義されているNDPのバージョンは、これらのメッセージの整合性を保護したり、リンクに接続するノードがいかなるノードも、それが満たされないルーティングサービスを提供すると悪意を持って主張できる結果とともに、メッセージで行われたアサーションを検証したり、不適切なプレフィックスとパラメーターを宣伝します。これらの脅威は[RFC3756]に記録されています。
A malicious node may also be able to carry out a DoS attack by deprecating an established valid prefix (by advertising it with a zero lifetime). Similar DoS attacks are possible if the optional Router Selection mechanism is implemented as described in the security considerations of [RFC4191].
悪意のあるノードは、確立された有効なプレフィックスを廃止することにより（ゼロの寿命で宣伝することにより）DOS攻撃を実行することもできます。[RFC4191]のセキュリティに関する考慮事項で説明されているように、オプションのルーター選択メカニズムが実装されている場合、同様のDOS攻撃が可能です。
SEND [RFC3971] can be used to provide verification that routers are authorized to provide the services they advertise through a certificate-based mechanism. This capability of SEND is also particularly appropriate for wireless environments where clients are reliant on the assertions of the routers rather than a physically secured connection.
[RFC3971]を使用して、ルーターが証明書ベースのメカニズムを通じて宣伝するサービスを提供することを許可されていることを確認することができます。この送信の機能は、クライアントが物理的に保護された接続ではなく、ルーターのアサーションに依存しているワイヤレス環境にも特に適しています。
If a host deploys the optional host-to-router load-sharing mechanism [RFC4311], a malicious application could carry out a DoS attack on one or more of the load-sharing routers if the application is able to use knowledge of the load-sharing algorithm to synthesize traffic that subverts the load-sharing algorithm and directs a large volume of bogus traffic towards a subset of the routers. The likelihood of such an attack can be reduced if the implementation uses a sufficiently sophisticated load sharing algorithm as described in the security considerations of [RFC4311].
ホストがオプションのホストからルーターへの負荷シェアリングメカニズム[RFC4311]を展開した場合、悪意のあるアプリケーションは、アプリケーションがロードの知識を使用できる場合、1つ以上の負荷分担ルーターに対するDOS攻撃を実行できます。アルゴリズムを共有して、負荷シェアリングアルゴリズムを破壊し、大量の偽トラフィックをルーターのサブセットに向けて誘導するトラフィックを合成します。[RFC4311]のセキュリティに関する考慮事項で説明されているように、実装が十分に洗練された負荷共有アルゴリズムを使用すると、このような攻撃の可能性を減らすことができます。
Mobile IPv6 offers significantly enhanced security compared with Mobile IPv4 especially when using optimized routing and care-of addresses. Return routability checks are used to provide relatively robust assurance that the different addresses that a mobile node uses as it moves through the network do indeed all refer to the same node. The threats and solutions are described in [RFC3775], and a more extensive discussion of the security aspects of the design can be found in [RFC4225].
モバイルIPv6は、特に最適化されたルーティングとケアオブアドレスを使用する場合、モバイルIPv4と比較して大幅に強化されたセキュリティを提供します。Returnabability Checksは、ネットワークを介して移動するときにモバイルノードが使用するさまざまなアドレスが実際に同じノードを参照するという比較的堅牢な保証を提供するために使用されます。脅威と解決策は[RFC3775]で説明されており、設計のセキュリティの側面に関するより広範な議論は[RFC4225]にあります。
The Home Address option specified in early versions of Mobile IPv6 would have allowed a trivial source spoofing attack: hosts were required to substitute the source address of incoming packets with the address in the option, thereby potentially evading checks on the packet source address. The version of Mobile IPv6 as standardized in
モバイルIPv6の初期バージョンで指定されたホームアドレスオプションは、些細なソーススプーフィング攻撃を許可していました。ホストは、入ってくるパケットのソースアドレスをオプションのアドレスに置き換える必要があり、それによりパケットソースアドレスのチェックを回避する可能性があります。標準化されたモバイルIPv6のバージョン
[RFC3775] has removed this issue by ensuring that the Home Address destination option is only processed if there is a corresponding binding cache entry and securing Binding Update messages.
[RFC3775]は、対応するバインディングキャッシュエントリがある場合にのみホームアドレスの宛先オプションが処理され、バインディングアップデートメッセージが保護されていることを確認することにより、この問題を削除しました。
A number of pre-standard implementations of Mobile IPv6 were available that implemented this obsolete and insecure option: care should be taken to avoid running such obsolete systems.
この時代遅れで不安定なオプションを実装したモバイルIPv6の多くの標準以前の実装が利用可能でした。そのような時代遅れのシステムの実行を避けるために注意する必要があります。
Overloaded functionality is always a double-edged sword: it may yield some deployment benefits, but often also incurs the price that comes with ambiguity.
過負荷の機能は常に両刃の剣です。展開の利点が生じる可能性がありますが、多くの場合、あいまいさが伴う価格も発生します。
One example of such is IPv4-mapped IPv6 addresses (::ffff/96): a representation of an IPv4 address as an IPv6 address inside an operating system as defined in [RFC3493]. Since the original specification, the use of IPv4-mapped addresses has been extended to a transition mechanism, Stateless IP/ICMP Translation algorithm (SIIT) [RFC2765], where they are potentially used in the addresses of packets on the wire.
そのような例の1つは、[RFC3493]で定義されているように、オペレーティングシステム内のIPv4アドレスとしてのIPv4アドレスの表現です。元の仕様以来、IPv4マップアドレスの使用は遷移メカニズム、ステートレスIP/ICMP翻訳アルゴリズム（SIIT）[RFC2765]に拡張され、ワイヤー上のパケットのアドレスで使用される可能性があります。
Therefore, it becomes difficult to unambiguously discern whether an IPv4 mapped address is really an IPv4 address represented in the IPv6 address format (basic API behavior) *or* an IPv6 address received from the wire (which may be subject to address forgery, etc.). (SIIT behavior). The security issues that arise from the ambiguous behavior when IPv4-mapped addresses are used on the wire include:
したがって、IPv4マッピングアドレスが実際にIPv6アドレス形式（基本API動作）に表されるIPv4アドレスであるかどうかを明確に識別することが困難になります *または *ワイヤから受信したIPv6アドレス（アドレスフォーファリーなどの対象となる場合があります。）。（SIITの動作）。ipv4マップされたアドレスがワイヤーで使用されるときに曖昧な動作から生じるセキュリティの問題は次のとおりです。
o If an attacker transmits an IPv6 packet with ::ffff:127.0.0.1 in the IPv6 source address field, he might be able to bypass a node's access controls by deceiving applications into believing that the packet is from the node itself (specifically, the IPv4 loopback address, 127.0.0.1). The same attack might be performed using the node's IPv4 interface address instead.
o 攻撃者がIPv6パケットを:: ffff：127.0.0.1でIPv6ソースアドレスフィールドで送信した場合、パケットがノード自体からであると信じるアプリケーションを欺くことにより、ノードのアクセス制御をバイパスできる場合があります（具体的には、IPV44ループバックアドレス、127.0.0.1）。代わりに、ノードのIPv4インターフェイスアドレスを使用して同じ攻撃が実行される場合があります。
o If an attacker transmits an IPv6 packet with IPv4-mapped addresses in the IPv6 destination address field corresponding to IPv4 addresses inside a site's security perimeter (e.g., ::ffff: 10.1.1.1), he might be able to bypass IPv4 packet filtering rules and traverse a site's firewall.
o 攻撃者が、サイトのセキュリティ境界内のIPv6宛先アドレスフィールドにIPv4マップアドレスを含むIPv6パケットを送信する場合（例：:: FFFF：10.1.1.1）、IPv4パケットフィルタリングルールをバイパスできる場合があります。サイトのファイアウォールを横断します。
o If an attacker transmits an IPv6 packet with IPv4-mapped addresses in the IPv6 source and destination fields to a protocol that swaps IPv6 source and destination addresses, he might be able to use a node as a proxy for certain types of attacks. For example, this might be used to construct broadcast multiplication and proxy TCP port scan attacks.
o 攻撃者がIPv6ソースフィールドと宛先フィールドにIPv4マップのアドレスを含むIPv6パケットをIPv6ソースと宛先アドレスを交換するプロトコルに送信すると、特定のタイプの攻撃のプロキシとしてノードを使用できる場合があります。たとえば、これはブロードキャスト乗算とプロキシTCPポートスキャン攻撃の構築に使用される場合があります。
In addition, special cases like these, while giving deployment benefits in some areas, require a considerable amount of code complexity (e.g., in the implementations of bind() system calls and reverse DNS lookups) that is probably undesirable but can be managed in this case.
さらに、これらのような特別なケースは、一部の領域で展開の利点を与えながら、おそらく望ましくないが、これで管理できる、かなりの量のコードの複雑さを必要とします（例：Bind（）システム呼び出しおよび逆DNSルックアップの実装）場合。
In practice, although the packet translation mechanisms of SIIT are specified for use in "Network Address Translator - Protocol Translator (NAT-PT)" [RFC2766], NAT-PT uses a mechanism different from IPv4-mapped IPv6 addresses for communicating embedded IPv4 addresses in IPv6 addresses. Also, SIIT is not recommended for use as a standalone transition mechanism. Given the issues that have been identified, it seems appropriate that mapped addresses should not be used on the wire. However, changing application behavior by deprecating the use of mapped addresses in the operating system interface would have significant impact on application porting methods as described in [RFC4038], and it is expected that IPv4- mapped IPv6 addresses will continue to be used within the API to aid application portability.
実際には、SIITのパケット翻訳メカニズムは「ネットワークアドレス翻訳者 - プロトコル翻訳者（NAT-PT）」[RFC2766]で使用するために指定されていますが、NAT-PTは、埋め込まれたIPV4アドレスを通信するためのIPv4-Mapped IPv6アドレスとは異なるメカニズムを使用します。IPv6アドレス。また、SIITは、スタンドアロン遷移メカニズムとして使用することをお勧めしません。特定された問題を考えると、マッピングされたアドレスをワイヤーで使用しないでください。ただし、[RFC4038]で説明されているように、オペレーティングシステムインターフェイスでマッピングされたアドレスの使用を非難することにより、アプリケーションのマッピングされたアドレスを使用することでアプリケーションの動作を変更すると、アプリケーションの移植方法に大きな影響があり、IPv4マッピングIPv6アドレスはAPI内で引き続き使用されると予想されます。アプリケーションの移植性を支援するため。
Using the basic API behavior has some security implications in that it adds additional complexity to address-based access controls. The main issue that arises is that an IPv6 (AF_INET6) socket will accept IPv4 packets even if the node has no IPv4 (AF_INET) sockets open. This has to be taken into account by application developers and may allow a malicious IPv4 peer to access a service even if there are no open IPv4 sockets. This violates the security principle of "least surprise".
基本的なAPI動作を使用すると、アドレスベースのアクセス制御に追加の複雑さを追加するという点で、いくつかのセキュリティに影響があります。発生する主な問題は、ノードにIPv4（AF_INET）ソケットが開いていない場合でも、IPv6（AF_INET6）ソケットがIPv4パケットを受け入れることです。これはアプリケーション開発者によって考慮される必要があり、オープンなIPv4ソケットがない場合でも、悪意のあるIPv4ピアがサービスにアクセスできるようにする場合があります。これは、「最も驚きの少ない」というセキュリティの原則に違反します。
One of the major design aims of IPv6 has been to maintain the original IP architectural concept of end-to-end transparency. Transparency can help foster technological innovation in areas such as peer-to-peer communication, but maintaining the security of the network at the same time requires some modifications in the network architecture. Ultimately, it is also likely to need changes in the security model as compared with the norms for IPv4 networks.
IPv6の主要な設計目的の1つは、エンドツーエンドの透明性の元のIPアーキテクチャの概念を維持することでした。透明性は、ピアツーピア通信などの分野での技術革新を促進するのに役立ちますが、ネットワークのセキュリティを同時に維持するには、ネットワークアーキテクチャのいくつかの変更が必要です。最終的には、IPv4ネットワークの基準と比較して、セキュリティモデルの変更が必要になる可能性があります。
The necessity of introducing Network Address Translators (NATs) into IPv4 networks, resulting from a shortage of IPv4 addresses, has removed the end-to-end transparency of most IPv4 connections: the use of IPv6 would restore this transparency. However, the use of NATs, and the associated private addressing schemes, has become inappropriately linked to the provision of security in enterprise networks. The restored end-to-end transparency of IPv6 networks can therefore be seen as a threat by poorly informed enterprise network managers. Some seem to want to limit the end-to-end capabilities of IPv6, for example by deploying private, local addressing and translators, even when it is not necessary because of the abundance of IPv6 addresses.
IPv4アドレスの不足に起因するネットワークアドレス翻訳者（NAT）をIPv4ネットワークに導入する必要性は、ほとんどのIPv4接続のエンドツーエンドの透明性を削除しました。IPv6の使用はこの透明度を回復します。ただし、NATの使用、および関連するプライベートアドレス指定スキームは、エンタープライズネットワークでのセキュリティの提供に不適切にリンクされています。したがって、IPv6ネットワークの復元されたエンドツーエンドの透明性は、十分な情報に基づいたエンタープライズネットワークマネージャーによる脅威と見なすことができます。たとえば、IPv6アドレスが豊富であるために必要でない場合でも、プライベート、ローカルアドレス指定、翻訳者を展開することにより、IPv6のエンドツーエンドの機能を制限したいと思う人もいます。
Recommendations for designing an IPv6 network to meet the perceived security and connectivity requirements implicit in the current usage of IPv4 NATs whilst maintaining the advantages of IPv6 end-to-end transparency are described in "IP Version 6 Network Architecture Protection" [RFC4864].
IPv6ネットワークを設計するための推奨事項IPv4 NATの現在の使用に暗黙のセキュリティおよび接続要件を満たし、IPv6のエンドツーエンドの透明性の利点を維持しながら、「IPバージョン6ネットワークアーキテクチャ保護」[RFC4864]に記載されています。
The favored model for enterprise network security in IPv4 stresses the use of a security perimeter policed by autonomous firewalls and incorporating the NATs. Both perimeter firewalls and NATs introduce asymmetry and reduce the transparency of communications through these perimeters. The symmetric bidirectionality and transparency that are extolled as virtues of IPv6 may seem to be at odds with this model. Consequently, network managers may even see them as undesirable attributes, in conflict with their need to control threats to and attacks on the networks they administer.
IPv4におけるエンタープライズネットワークセキュリティの好まれるモデルは、自律的なファイアウォールによって警察され、NATを組み込むセキュリティ境界線の使用を強調しています。周囲のファイアウォールとNATの両方が非対称性を導入し、これらの境界を介して通信の透明度を低下させます。IPv6の美徳として称賛される対称的な双方向性と透明性は、このモデルと対立しているように見えるかもしれません。その結果、ネットワークマネージャーは、それらが管理するネットワークに対する脅威と攻撃を制御する必要性と対立する、望ましくない属性と見なすことさえあります。
It is worth noting that IPv6 does not *require* end-to-end connectivity. It merely provides end-to-end addressability; the connectivity can still be controlled using firewalls (or other mechanisms), and it is indeed wise to do so.
IPv6がエンドツーエンドの接続を *必要としないことは注目に値します。エンドツーエンドのアドレス指定を提供するだけです。接続性は、ファイアウォール（またはその他のメカニズム）を使用して依然として制御できます。これを行うのが賢明です。
A number of matters indicate that IPv6 networks should migrate towards an improved security model, which will increase the overall security of the network while at the same time facilitating end-to-end communication:
多くの問題は、IPv6ネットワークが改善されたセキュリティモデルに移行する必要があることを示しています。これにより、ネットワークの全体的なセキュリティが増加し、同時にエンドツーエンドのコミュニケーションが促進されます。
o Increased usage of end-to-end security especially at the network layer. IPv6 mandates the provision of IPsec capability in all nodes, and increasing usage of end-to-end security is a challenge to current autonomous firewalls that are unable to perform deep packet inspection on encrypted packets. It is also incompatible with NATs because they modify the packets, even when packets are only authenticated rather than encrypted.
o 特にネットワークレイヤーでのエンドツーエンドセキュリティの使用の増加。IPv6は、すべてのノードでのIPSEC機能の提供を義務付けており、エンドツーエンドセキュリティの使用の増加は、暗号化されたパケットで深いパケット検査を実行できない現在の自律ファイアウォールにとって課題です。また、パケットが暗号化されているのではなく認証されている場合でも、パケットを変更するため、NATとは互換性がありません。
o Acknowledgement that over-reliance on the perimeter model is potentially dangerous. An attacker who can penetrate today's perimeters will have free rein within the perimeter, in many cases. Also a successful attack will generally allow the attacker to capture information or resources and make use of them.
o 境界モデルへの過剰依存は潜在的に危険であるという認識。今日の境界線に侵入できる攻撃者は、多くの場合、周囲内で自由な手綱を持っています。また、攻撃を成功させることで、攻撃者は情報やリソースをキャプチャし、それらを利用することができます。
o Development of mechanisms such as 'Trusted Computing' [TCGARCH] that will increase the level of trust that network managers are able to place on hosts.
o ネットワークマネージャーがホストに配置できる信頼のレベルを高める「信頼されたコンピューティング」[TCGARCH]などのメカニズムの開発。
o Development of centralized security policy repositories and secure distribution mechanisms that, in conjunction with trusted hosts, will allow network managers to place more reliance on security mechanisms at the end-points. The mechanisms are likely to include end-node firewalling and intrusion detection systems as well as secure protocols that allow end-points to influence the behavior of perimeter security devices.
o
o Review of the role of perimeter devices with increased emphasis on intrusion detection, and network resource protection and coordination to thwart distributed denial-of-service attacks.
o 侵入検知に重点を置いた境界デバイスの役割のレビュー、および分布拒否攻撃を阻止するためのネットワークリソースの保護と調整。
Several of the technologies required to support an enhanced security model are still under development, including secure protocols to allow end-points to control firewalls: the complete security model utilizing these technologies is now emerging but still requires some development.
強化されたセキュリティモデルをサポートするために必要ないくつかのテクノロジーは、エンドポイントがファイアウォールを制御できるようにするための安全なプロトコルを含む、まだ開発中です。これらのテクノロジーを利用する完全なセキュリティモデルは現在出現していますが、それでもいくつかの開発が必要です。
In the meantime, initial deployments will need to make use of similar firewalling and intrusion detection techniques to IPv4 that may limit end-to-end transparency temporarily, but should be prepared to use the new security model as it develops and avoid the use of NATs by the use of the architectural techniques described in [RFC4864]. In particular, using NAT-PT [RFC2766] as a general purpose transition mechanism should be avoided as it is likely to limit the exploitation of end-to-end security and other IPv6 capabilities in the future as explained in [RFC4966].
それまでの間、初期展開は、一時的にエンドツーエンドの透明性を制限する可能性のあるIPv4に同様のファイアウォールと侵入検出技術を使用する必要がありますが、NATの使用と使用を避けるときに新しいセキュリティモデルを使用する準備をする必要があります。[RFC4864]に記載されている建築技術の使用により。特に、[RFC4966]で説明されているように、将来のエンドツーエンドのセキュリティおよびその他のIPv6機能の活用を制限する可能性が高いため、一般的な目的遷移メカニズムとしてNAT-PT [RFC2766]を使用することは避けるべきです。
IPv6 in IPv6 tunnels can be used to circumvent security checks, so it is essential to filter packets both at tunnel ingress and egress points (the encapsulator and decapsulator) to ensure that both the inner and outer addresses are acceptable, and the tunnel is not being used to carry inappropriate traffic. [RFC3964], which is primarily about the 6to4 transition tunneling mechanism (see Section 3.1), contains useful discussions of possible attacks and ways to counteract these threats.
IPv6のIPv6トンネルを使用してセキュリティチェックを回避できるため、トンネルイングレスポイントと出口ポイント（エンコイプレーターと脱カプセレータ）の両方でパケットをフィルタリングして、内側のアドレスと外側のアドレスが許容され、トンネルはそうではありません。不適切なトラフィックを運ぶために使用されます。[RFC3964]は、主に6to4遷移トンネリングメカニズムに関するものであり（セクション3.1を参照）、これらの脅威に対抗するための攻撃の可能性と方法の有用な議論が含まれています。
The more complicated the IPv6 transition/coexistence becomes, the greater the danger that security issues will be introduced either
IPv6遷移/共存が複雑になるほど、セキュリティの問題が導入される危険性が大きくなります
o in the mechanisms themselves,
o メカニズム自体では、
o in the interaction between mechanisms, or
o メカニズム間の相互作用、または
o by introducing unsecured paths through multiple mechanisms.
o 複数のメカニズムを介して無担保パスを導入することにより。
These issues may or may not be readily apparent. Hence, it would be desirable to keep the mechanisms simple (as few in number as possible and built from pieces as small as possible) to simplify analysis.
これらの問題は、容易に明らかになる場合とそうでない場合があります。したがって、分析を簡素化するために、メカニズムを単純に保つことが望ましいでしょう（可能な限り少数であり、可能な限り小さい断片から構築されます）。
One case where such security issues have been analyzed in detail is the 6to4 tunneling mechanism [RFC3964].
このようなセキュリティの問題が詳細に分析されている1つのケースは、6to4トンネルメカニズム[RFC3964]です。
As tunneling has been proposed as a model for several more cases than are currently being used, its security properties should be analyzed in more detail. There are some generic dangers to tunneling:
トンネリングは、現在使用されているよりも多くのケースのモデルとして提案されているため、そのセキュリティプロパティをより詳細に分析する必要があります。トンネリングには一般的な危険があります。
o It may be easier to avoid ingress filtering checks.
o イングレスフィルタリングチェックを避ける方が簡単かもしれません。
o It is possible to attack the tunnel interface: several IPv6 security mechanisms depend on checking that Hop Limit equals 255 on receipt and that link-local addresses are used. Sending such packets to the tunnel interface is much easier than gaining access to a physical segment and sending them there.
o トンネルインターフェイスを攻撃することが可能です。いくつかのIPv6セキュリティメカニズムは、ホップ制限が受領で255に等しいこと、およびリンクローカルアドレスが使用されることを確認することに依存します。このようなパケットをトンネルインターフェースに送信することは、物理セグメントへのアクセスを取得してそこに送信するよりもはるかに簡単です。
o Automatic tunneling mechanisms are typically particularly dangerous as there is no pre-configured association between end points. Accordingly, at the receiving end of the tunnel, packets have to be accepted and decapsulated from any source. Consequently, special care should be taken when specifying automatic tunneling techniques.
o 自動トンネルメカニズムは、エンドポイント間に事前に構成された関連性がないため、通常、特に危険です。したがって、トンネルの受信側では、パケットを受け入れ、任意のソースから脱カプセル化する必要があります。したがって、自動トンネリング技術を指定する際には、特別な注意が必要です。
Two mechanisms have been specified that use automatic tunneling and are intended for use outside a single domain. These mechanisms encapsulate the IPv6 packet directly in an IPv4 packet in the case of 6to4 [RFC3056] or in an IPv4 UDP packet in the case of Teredo [RFC4380]. In each case, packets can be sent and received by any similarly equipped nodes in the IPv4 Internet.
自動トンネリングを使用し、単一のドメイン外で使用することを目的とした2つのメカニズムが指定されています。これらのメカニズムは、6to4 [RFC3056]の場合またはTeredo [RFC4380]の場合のIPv4 UDPパケットのIPv4パケットでIPv6パケットを直接カプセル化します。いずれの場合も、IPv4インターネットの同様に装備されたノードによってパケットを送信および受信できます。
As mentioned in Section 3.1, a major vulnerability in such approaches is that receiving nodes must allow decapsulation of traffic sourced from anywhere in the Internet. This kind of decapsulation function must be extremely well secured because of the wide range of potential sources.
セクション3.1で述べたように、このようなアプローチの主要な脆弱性は、ノードを受信することで、インターネットのどこからでも供給されたトラフィックの脱カプセル化を許可する必要があることです。この種の脱カプセル化関数は、潜在的なソースの幅広い範囲のため、非常によく安全にする必要があります。
An even more difficult problem is how these mechanisms are able to establish communication with native IPv6 nodes or between the automatic tunneling mechanisms: such connectivity requires the use of some kind of "relay". These relays could be deployed in various locations such as:
さらに困難な問題は、これらのメカニズムがネイティブIPv6ノードとの通信をどのように確立できるか、または自動トンネリングメカニズム間でどのようにできるかということです。そのような接続には、何らかの「リレー」の使用が必要です。これらのリレーは、次のようなさまざまな場所に展開できます。
o all native IPv6 nodes,
o すべてのネイティブIPv6ノード、
o native IPv6 sites,
o ネイティブIPv6サイト、
o in IPv6-enabled ISPs, or
o IPv6対応ISPSで、または
o just somewhere in the Internet.
o インターネットのどこか。
Given that a relay needs to trust all the sources (e.g., in the 6to4 case, all 6to4 routers) that are sending it traffic, there are issues in achieving this trust and at the same time scaling the relay system to avoid overloading a small number of relays.
リレーはすべてのソース（たとえば、6to4ケース、6to4ルーターすべて）を信頼する必要があることを考えると、この信頼を達成すると同時にリレーシステムをスケーリングして、少数の過負荷を避けるために問題があります。リレーの。
As authentication of such a relay service is very difficult to achieve, and particularly so in some of the possible deployment models, relays provide a potential vehicle for address spoofing, (reflected) denial-of-service attacks, and other threats.
このようなリレーサービスの認証は達成するのが非常に困難であり、特にいくつかの展開モデルの一部では、リレーは住所のスプーフィング、（反映された）サービス拒否攻撃、およびその他の脅威の潜在的な手段を提供します。
Threats related to 6to4 and measures to combat them are discussed in [RFC3964]. [RFC4380] incorporates extensive discussion of the threats to Teredo and measures to combat them.
6to4に関連する脅威とそれらと戦うための措置については、[RFC3964]で議論されています。[RFC4380]は、テレドに対する脅威とそれらと戦うための措置についての広範な議論を組み込んでいます。
NATs and firewalls have been deployed extensively in the IPv4 Internet, as discussed in Section 2.3. Operators who deploy them typically have some security/operational requirements in mind (e.g., a desire to block inbound connection attempts), which may or may not be misguided.
セクション2.3で説明したように、NATとファイアウォールはIPv4インターネットに広く展開されています。それらを展開するオペレーターは、通常、セキュリティ/運用要件を念頭に置いています（たとえば、インバウンド接続の試みをブロックしたいという欲求）。
The addition of tunneling can change the security model that such deployments are seeking to enforce. IPv6-over-IPv4 tunneling using protocol 41 is typically either explicitly allowed, or disallowed implicitly. Tunneling IPv6 over IPv4 encapsulated in UDP constitutes a more difficult problem as UDP must usually be allowed to pass through NATs and firewalls. Consequently, using UDP implies the ability to punch holes in NATs and firewalls although, depending on the implementation, this ability may be limited or only achieved in a stateful manner. In practice, the mechanisms have been explicitly designed to traverse both NATs and firewalls in a similar fashion.
トンネリングの追加は、そのような展開が実施しようとしているセキュリティモデルを変更する可能性があります。Protocol 41を使用したIPv6-Over-IPV4トンネルは、通常、明示的に許可されるか、暗黙的に許可されます。UDPにカプセル化されたIPv4を介したTunneling IPv6は、通常、NATとファイアウォールを通過することを許可する必要があるため、より困難な問題を構成します。その結果、UDPを使用すると、NATとファイアウォールの穴をパンチする能力が意味されますが、実装に応じて、この能力は限られているか、ステートフルな方法でのみ達成される場合があります。実際には、このメカニズムは、同様の方法でNATとファイアウォールの両方を横断するように明示的に設計されています。
One possible view is that the use of tunneling is especially questionable in home and SOHO (small office/home office) environments where the level of expertise in network administration is typically not very high; in these environments, the hosts may not be as tightly managed as in others (e.g., network services might be enabled unnecessarily), leading to possible security break-ins or other vulnerabilities.
考えられる見方の1つは、トンネリングの使用は、ネットワーク管理の専門知識のレベルが一般的にそれほど高くない自宅とソーホー（小さなオフィス/ホームオフィス）環境で特に疑わしいということです。これらの環境では、ホストは他の環境ほど緊密に管理されていない場合があります（たとえば、ネットワークサービスは不必要に有効になる可能性があります）。
Holes allowing tunneled traffic through NATs and firewalls can be punched both intentionally and unintentionally. In cases where the administrator or user makes an explicit decision to create the hole, this is less of a problem, although (for example) some enterprises might want to block IPv6 tunneling explicitly if employees were able to create such holes without reference to administrators. On the other hand, if a hole is punched transparently, it is likely that a proportion of users will not understand the consequences: this will very probably result in a serious threat sooner or later.
NATとファイアウォールを通るトンネリングトラフィックを可能にする穴は、意図的かつ意図せずにパンチできます。管理者またはユーザーがホールを作成するという明示的な決定を下す場合、これは問題ではありませんが、（たとえば）一部の企業は、従業員が管理者に言及せずにそのようなホールを作成できた場合、IPv6トンネルを明示的にブロックしたい場合があります。一方、穴が透過的にパンチされている場合、ユーザーの一部が結果を理解しない可能性があります。これは、おそらく遅かれ早かれ深刻な脅威につながるでしょう。
When deploying tunneling solutions, especially tunneling solutions that are automatic and/or can be enabled easily by users who do not understand the consequences, care should be taken not to compromise the security assumptions held by the users.
トンネルソリューション、特に結果を理解していないユーザーが簡単に有効にできるトンネリングソリューションを展開する場合、ユーザーが保持しているセキュリティの仮定を妥協しないように注意する必要があります。
For example, NAT traversal should not be performed by default unless there is a firewall producing a similar by-default security policy to that provided by IPv4 NAT. IPv6-in-IPv4 (protocol 41) tunneling is less of a problem, as it is easier to block if necessary; however, if the host is protected in IPv4, the IPv6 side should be protected as well.
たとえば、NATトラバーサルは、IPv4 NATが提供するものと同様のバイデフォルトセキュリティポリシーを生成するファイアウォールがない限り、デフォルトで実行されないでください。IPv6-in-IPV4（プロトコル41）トンネリングは、必要に応じてブロックしやすいため、問題はそれほど多くありません。ただし、ホストがIPv4で保護されている場合、IPv6側も保護する必要があります。
As is shown in Appendix A, it is relatively easy to determine the IPv6 address corresponding to an IPv4 address in tunneling deployments. It is therefore vital NOT to rely on "security by obscurity", i.e., assuming that nobody is able to guess or determine the IPv6 address of the host especially when using automatic tunneling transition mechanisms.
付録Aに示すように、トンネルの展開のIPv4アドレスに対応するIPv6アドレスを決定するのは比較的簡単です。したがって、「あいまいさによるセキュリティ」に依存しないことが重要です。つまり、特に自動トンネリング遷移メカニズムを使用する場合、ホストのIPv6アドレスを推測または決定できないと仮定することが重要です。
The network architecture must provide separate IPv4 and IPv6 firewalls with tunneled IPv6 traffic arriving encapsulated in IPv4 packets routed through the IPv4 firewall before being decapsulated, and then through the IPv6 firewall as shown in Figure 1.
ネットワークアーキテクチャは、IPv4ファイアウォールとIPv4ファイアウォールを個別に提供する必要があります。TunneledIPv6ファイアウォールは、脱カプセル化される前にIPv4ファイアウォールをルーティングし、次に図1に示すようにIPv6ファイアウォールを介してルーティングされたIPv4パケットにカプセル化されたトンネル付きIPv6トラフィックを提供する必要があります。
+--------+ +--------+ +--------+
Site | Native | IPv6 |v6 in v4| IPv4 | Native | Public
Network <--->| IPv6 |<---->| Tunnel |<---->| IPv4 |<---> Internet
|Firewall| |Endpoint| |Firewall|
+--------+ +--------+ +--------+
Figure 1: Tunneled Traffic and Firewalls
図1：トンネルトラフィックとファイアウォール
Because IPv6 is a new service for many networks, network managers will often opt to make a pilot deployment in a part of the network to gain experience and understand the problems as well as the benefits that may result from a full production quality IPv6 service.
IPv6は多くのネットワークの新しいサービスであるため、ネットワークマネージャーは、多くの場合、ネットワークの一部でパイロットの展開を行い、経験を積み、問題と完全な生産品質のIPv6サービスから生じる可能性のある利点を理解することを選択します。
Unless IPv6 service piloting is done in a manner that is as secure as possible, there is a risk that if security in the pilot does not match up to what is achievable with current IPv4 production service, the comparison can adversely impact the overall assessment of the IPv6 pilot deployment. This may result in a decision to delay or even avoid deploying an IPv6 production service. For example, hosts and routers might not be protected by IPv6 firewalls, even if the corresponding IPv4 service is fully protected by firewalls. The use of tunneling transition mechanisms (see Section 3.3) and the interaction with virtual private networks also need careful attention to ensure that site security is maintained. This is particularly critical where IPv6 capabilities are turned on by default in new equipment or new releases of operating systems: network managers may not be fully aware of the security exposure that this creates.
IPv6サービスパイロットが可能な限り安全な方法で行われない限り、パイロットのセキュリティが現在のIPv4生産サービスで達成可能なものと一致しない場合、比較はIPv6パイロット展開。これにより、IPv6生産サービスの展開を遅らせるか、避けることを決定する可能性があります。たとえば、対応するIPv4サービスがファイアウォールによって完全に保護されている場合でも、ホストとルーターはIPv6ファイアウォールによって保護されない場合があります。トンネリング遷移メカニズムの使用（セクション3.3を参照）と仮想プライベートネットワークとの相互作用も、サイトのセキュリティが維持されるように注意する必要があります。これは、新しい機器またはオペレーティングシステムの新しいリリースでデフォルトでIPv6機能がオンになっている場合に特に重要です。ネットワークマネージャーは、これが作成するセキュリティエクスポージャーを完全に認識していない場合があります。
In some cases, a perceived lack of availability of IPv6 firewalls and other security capabilities, such as intrusion detection systems may have led network managers to resist any kind of IPv6 service deployment. These problems may be partly due to the relatively slow development and deployment of IPv6-capable security equipment, but the major problems appear to have been a lack of information, and more importantly a lack of documented operational experience on which managers can draw. In actual fact, at the time of writing, there are a significant number of alternative IPv6 packet filters and firewalls already in existence that could be used to provide sufficient access controls.
場合によっては、IPv6ファイアウォールや侵入検知システムなどのその他のセキュリティ機能の可用性の欠如が認識されているため、ネットワークマネージャーがあらゆる種類のIPv6サービスの展開に抵抗するようになった可能性があります。これらの問題は、IPv6対応セキュリティ機器の開発と展開が比較的遅くなっていることが原因である可能性がありますが、主要な問題は情報の不足であり、さらに重要なことに、マネージャーが描くことができる文書化された運用体験の不足であるように見えます。実際、執筆時点では、十分なアクセス制御を提供するために使用できる代替IPv6パケットフィルターとファイアウォールが既に存在しています。
However, there are a small number of areas where the available equipment and capabilities may still be a barrier to secure deployment as of the time of writing: o 'Personal firewalls' with support for IPv6 and intended for use on hosts are not yet widely available.
ただし、利用可能な機器と機能が、執筆時点で展開を確保する障壁である可能性がある少数の領域があります。IPv6をサポートし、ホストでの使用を目的としたo 'パーソナルファイアウォール'はまだ広く利用できません。
o Enterprise firewalls are at an early stage of development and may not provide the full range of capabilities needed to implement the necessary IPv6 filtering rules. Network managers often expect the same devices that support and are used for IPv4 today to also become IPv6-capable -- even though this is not really required and the equipment may not have the requisite hardware capabilities to support fast packet filtering for IPv6. Suggestions for the appropriate deployment of firewalls are given in Section 3.3 -- as will be seen from this section, it is usually desirable that the firewalls are in separate boxes, and there is no necessity for them to be same the model of equipment.
o エンタープライズファイアウォールは開発の初期段階にあり、必要なIPv6フィルタリングルールを実装するために必要なすべての機能を提供しない場合があります。ネットワークマネージャーは、多くの場合、IPv4にも使用され、IPv6対応になるのと同じデバイスを期待しています。ファイアウォールの適切な展開の提案はセクション3.3に記載されています。このセクションから見られるように、通常、ファイアウォールが別々のボックスにあることが望ましいことがあり、それらが機器のモデルと同じであることは必要ありません。
o A lesser factor may be that some design decisions in the IPv6 protocol make it more difficult for firewalls to be implemented and work in all cases, and to be fully future-proof (e.g., when new extension headers are used) as discussed in Section 2.1.9. It is significantly more difficult for intermediate nodes to process the IPv6 header chains than IPv4 packets.
o より低い要因は、IPv6プロトコルのいくつかの設計上の決定により、ファイアウォールが実装され、すべての場合に機能することをより困難にし、セクション2.1で説明したように、完全に将来のプルーフ（たとえば、新しい拡張ヘッダーが使用される場合）であることです。.9。中間ノードがIPv4パケットよりもIPv6ヘッダーチェーンを処理することは非常に困難です。
o Adequate Intrusion Detection Systems (IDS) are more difficult to construct for IPv6. IDSs are now beginning to become available but the pattern-based mechanisms used for IPv4 may not be the most appropriate for long-term development of these systems as end-to-end encryption becomes more prevalent. Future systems may be more reliant on traffic flow pattern recognition.
o 適切な侵入検知システム（IDS）は、IPv6の構築がより困難です。IDSは現在利用可能になり始めていますが、IPv4に使用されるパターンベースのメカニズムは、エンドツーエンドの暗号化がより一般的になるため、これらのシステムの長期開発に最も適していない場合があります。将来のシステムは、トラフィックフローパターン認識に依存する可能性があります。
o Implementations of high availability capabilities supporting IPv6 are also in short supply. In particular, development of the IPv6 version of the Virtual Router Redundancy Protocol (VRRP) [VRRP] has lagged the development of the main IPv6 protocol although alternatives may be available for some environments.
o IPv6をサポートする高可用性機能の実装も不足しています。特に、仮想ルーター冗長プロトコル（VRRP）[VRRP]のIPv6バージョンの開発により、メインIPv6プロトコルの開発が遅れていますが、代替品は一部の環境で利用できます。
In all these areas, developments are ongoing and they should not be considered a long-term bar to the deployment of IPv6 either as a pilot or production service. The necessary tools are now available to make a secure IPv6 deployment, and with careful selection of components and design of the network architecture, a successful pilot or production IPv6 service can be deployed. Recommendations for secure deployment and appropriate management of IPv6 networks can be found in the documentation archives of the European Union 6net project [SIXNET] and in the Deployment Guide published by the IPv6 Promotion Council of Japan [JpIPv6DC].
これらすべての分野で、開発が進行中であり、パイロットまたは生産サービスとしてIPv6の展開の長期的な棒と見なされるべきではありません。必要なツールが安全なIPv6展開を行うために利用可能になりました。コンポーネントの慎重な選択とネットワークアーキテクチャの設計により、パイロットまたは生産のIPv6サービスを成功させることができます。IPv6ネットワークの安全な展開と適切な管理に関する推奨事項は、欧州連合6NETプロジェクトのドキュメントアーカイブ[Sivnet]および日本のIPv6プロモーション評議会[JPIPv6DC]が発行した展開ガイドにあります。
Some DNS server implementations have flaws that severely affect DNS queries for IPv6 addresses as discussed in [RFC4074]. These flaws can be used for DoS attacks affecting both IPv4 and IPv6 by inducing caching DNS servers to believe that a domain is broken and causing the server to block access to all requests for the domain for a precautionary period.
一部のDNSサーバーの実装には、[RFC4074]で説明されているように、IPv6アドレスのDNSクエリに深刻な影響を与える欠陥があります。これらの欠陥は、DNSサーバーをキャッシュするようにドメインが壊れていると信じることにより、IPv4とIPv6の両方に影響を与えるDOS攻撃に使用できます。
Whilst in general terms brute force scanning of IPv6 subnets is essentially impossible due to the enormously larger address space of IPv6 and the 64-bit interface identifiers (see Appendix A), this will be obviated if administrators do not take advantage of the large space to use unguessable interface identifiers.
IPv6サブネットのブルートフォーススキャンは一般的に不可能ですが、IPv6と64ビットインターフェイス識別子のアドレススペースが非常に大きいため（付録Aを参照）、管理者が大きなスペースを利用しないと、これは解消されます。非適切なインターフェイス識別子を使用します。
Because of the unmemorability of complete IPv6 addresses, there is a temptation for administrators to use small integers as interface identifiers when manually configuring them, as might happen on point-to-point links or when provisioning complete addresses from a DHCPv6 server. Such allocations make it easy for an attacker to find active nodes that they can then port scan.
完全なIPv6アドレスの感情がないため、ポイントツーポイントリンクで発生する可能性がある場合、またはDHCPV6サーバーから完全なアドレスをプロビジョニングするときに、手動で構成するときに、管理者がインターフェイス識別子として小さな整数を使用する誘惑があります。このような割り当てにより、攻撃者はスキャンできるアクティブなノードを簡単に見つけます。
To make use of the larger address space properly, administrators should be very careful when entering IPv6 addresses in their configurations (e.g., access control lists), since numerical IPv6 addresses are more prone to human error than IPv4 due to their length and unmemorability.
より大きなアドレススペースを適切に使用するには、数値IPv6アドレスは長さと感動性のためにIPv4よりもヒューマンエラーが発生しやすいため、構成にIPv6アドレスを入力するとき（アクセス制御リストなど）、管理者は非常に注意する必要があります。
It is also essential to ensure that the management interfaces of routers are well secured (e.g., allowing remote access using Secure Shell (SSH) only and ensuring that local craft interfaces have non-default passwords) as the router will usually contain a significant cache of neighbor addresses in its neighbor cache.
また、ルーターの管理インターフェイスが十分に保護されていることを確認することも不可欠です（たとえば、セキュアシェル（SSH）のみを使用してリモートアクセスを許可し、ローカルクラフトインターフェイスに非デフォルトパスワードを持つようにすることもできます）。隣人は近隣キャッシュにアドレスを与えます。
One positive consequence of IPv6 is that nodes that do not require global access can communicate locally just by the use of a link-local address (if very local access is sufficient) or across the site by using a Unique Local Address (ULA). In either case it is easy to ensure that access outside the assigned domain of activity can be controlled by simple filters (which should be the default for link-locals). However, the security hazards of using link-local addresses for general purposes, as documented in Section 2.1.12, should be borne in mind.
IPv6の肯定的な結果の1つは、グローバルアクセスを必要としないノードが、リンクローカルアドレス（非常にローカルアクセスが十分である場合）またはユニークなローカルアドレス（ULA）を使用してサイト全体でローカルに通信できることです。どちらの場合でも、割り当てられたアクティビティドメインの外側のアクセスが簡単なフィルターで制御できるようにすることは簡単です（これはリンクロカルのデフォルトである必要があります）。ただし、セクション2.1.12に記載されているように、一般的な目的でLink-Localアドレスを使用することのセキュリティの危険は、留意する必要があります。
On the other hand, the possibility that a node or interface can have multiple global scope addresses makes access control filtering (both on ingress and egress) more complex and requires higher maintenance levels. Vendors and network administrators need to be aware that multiple addresses are the norm rather than the exception in IPv6: when building and selecting tools for security and management, a highly desirable feature is the ability to be able to 'tokenize' access control lists and configurations in general to cater for multiple addresses and/or address prefixes.
一方、ノードまたはインターフェイスが複数のグローバルスコープアドレスを持つことができる可能性により、アクセス制御フィルタリング（イングレスと出口の両方）により複雑になり、より高いメンテナンスレベルが必要です。ベンダーとネットワーク管理者は、IPv6の例外ではなく複数のアドレスが標準であることに注意する必要があります。セキュリティと管理のためのツールを構築および選択するとき、非常に望ましい機能は、アクセス制御リストと構成を「トークン」することができることです。一般に、複数のアドレスやアドレスのプレフィックスに対応します。
The addresses could be from the same network prefix (for example, privacy mechanisms [RFC4941] will periodically create new addresses taken from the same prefix, and two or more of these may be active at the same time), or from different prefixes (for example, when a network is multihomed, when for management purposes a node belongs to several subnets on the same link or is implementing anycast services). In all these cases, it is possible that a single host could be using several different addresses with different prefixes and/or different interface identifiers. It is desirable that the security administrator be able to identify that the same host is behind all these addresses.
アドレスは同じネットワークプレフィックスからのものである可能性があります（たとえば、プライバシーメカニズム[RFC4941]は、同じプレフィックスから撮影した新しいアドレスを定期的に作成し、2つ以上が同時にアクティブになる場合があります）、または異なるプレフィックス（たとえば、ネットワークがマルチホームされている場合、管理目的でノードが同じリンク上のいくつかのサブネットに属したり、Anycastサービスを実装しています）。これらすべての場合、単一のホストは、異なるプレフィックスおよび/または異なるインターフェイス識別子を持ついくつかの異なるアドレスを使用している可能性があります。セキュリティ管理者が、同じホストがこれらすべてのアドレスの背後にあることを特定できることが望ましいです。
Some network administrators may find the mutability of addresses when privacy mechanisms are used in their network to be undesirable because of the current difficulties in maintaining access control lists and knowing the origin of traffic. In general, disabling the use of privacy addresses is only possible if the full stateful DHCPv6 mechanism [RFC3315] is used to allocate IPv6 addresses and DHCPv6 requests for privacy addresses are not honored.
一部のネットワーク管理者は、アクセス制御リストを維持し、トラフィックの起源を把握することが現在の困難であるため、ネットワークでプライバシーメカニズムが使用されていない場合にアドレスの変動を発見する場合があります。一般に、プライバシーアドレスの使用を無効にすることは、完全なStateful DHCPV6メカニズム[RFC3315]を使用してIPv6アドレスを割り当てるために使用され、プライバシーアドレスのDHCPV6リクエストが尊重されない場合にのみ可能です。
In IPv4 it is commonly accepted that some filtering of ICMP packets by firewalls is essential to maintain security. Because of the extended use that is made of ICMPv6 [RFC2461] with a multitude of functions, the simple set of dropping rules that are usually applied in IPv4 need to be significantly developed for IPv6. The blanket dropping of all ICMP messages that is used in some very strict environments is simply not possible for IPv6.
IPv4では、ファイアウォールによるICMPパケットの一部のフィルタリングがセキュリティを維持するために不可欠であることが一般的に受け入れられています。多数の機能を備えたICMPv6 [RFC2461]で作られた拡張使用のため、IPv4で通常適用されるドロップルールの単純なセットは、IPv6に大幅に開発する必要があります。いくつかの非常に厳しい環境で使用されるすべてのICMPメッセージのブランケットドロップは、IPv6では単に不可能です。
In an IPv6 firewall, policy needs to allow some messages through the firewall but also has to permit certain messages to and from the firewall, especially those with link-local sources on links to which the firewall is attached. These messages must be permitted to ensure that Neighbor Discovery [RFC2462], Multicast Listener Discovery ([RFC2710], [RFC3810]), and Stateless Address Configuration [RFC4443] work as expected.
IPv6ファイアウォールでは、ポリシーはファイアウォールを介していくつかのメッセージを許可する必要がありますが、ファイアウォール、特にファイアウォールが添付されているリンクにリンクローカルソースを持つ特定のメッセージを許可する必要があります。これらのメッセージは、近隣発見[RFC2462]、マルチキャストリスナーディスカバリー（[RFC2710]、[RFC3810]）、およびステートレスアドレス構成[RFC4443]が予想どおりに機能するようにするために許可する必要があります。
Recommendations for filtering ICMPv6 messages can be found in [RFC4890].
ICMPV6メッセージのフィルタリングに関する推奨事項は、[RFC4890]に記載されています。
As described in Section 4.5, certain ICMPv6 error packets need to be passed through a firewall in both directions. This means that some ICMPv6 error packets can be exchanged between inside and outside without any filtering.
セクション4.5で説明したように、特定のICMPV6エラーパケットは、両方向のファイアウォールを通過する必要があります。これは、一部のICMPV6エラーパケットを、フィルタリングなしで内側と外側の間で交換できることを意味します。
Using this feature, malicious users can communicate between the inside and outside of a firewall, thus bypassing the administrator's inspection (proxy, firewall, etc.). For example, it might be possible to carry out a covert conversation through the payload of ICMPv6 error messages or to tunnel inappropriate encapsulated IP packets in ICMPv6 error messages. This problem can be alleviated by filtering ICMPv6 errors using a stateful packet inspection mechanism to ensure that the packet carried as a payload is associated with legitimate traffic to or from the protected network.
この機能を使用して、悪意のあるユーザーはファイアウォールの内側と外側の間で通信し、管理者の検査（代理、ファイアウォールなど）をバイパスできます。たとえば、ICMPV6エラーメッセージのペイロードを介して秘密の会話を実行したり、ICMPV6エラーメッセージで不適切なカプセル化されたIPパケットをトンネルすることが可能かもしれません。この問題は、ステートフルなパケット検査メカニズムを使用してICMPV6エラーをフィルタリングして、ペイロードとして運ばれたパケットが保護されたネットワークとの間の正当なトラフィックに関連付けられていることを確認することで軽減できます。
IPsec provides security to end-to-end communications at the network layer (layer 3). The security features available include access control, connectionless integrity, data origin authentication, protection against replay attacks, confidentiality, and limited traffic flow confidentiality (see [RFC4301] Section 2.1). IPv6 mandates the implementation of IPsec in all conforming nodes, making the usage of IPsec to secure end-to-end communication possible in a way that is generally not available to IPv4.
IPSECは、ネットワークレイヤーでエンドツーエンドの通信にセキュリティを提供します（レイヤー3）。利用可能なセキュリティ機能には、アクセス制御、コネクションレスの整合性、データ起源の認証、リプレイ攻撃に対する保護、機密性、および限られたトラフィックフローの機密性が含まれます（[RFC4301]セクション2.1を参照）。IPv6は、すべての適合ノードにIPSECの実装を義務付け、IPV4が一般的に利用できない方法でエンドツーエンドの通信を確保するためにIPSECを使用することを行います。
To secure IPv6 end-to-end communications, IPsec transport mode would generally be the solution of choice. However, use of these IPsec security features can result in novel problems for network administrators and decrease the effectiveness of perimeter firewalls because of the increased prevalence of encrypted packets on which the firewalls cannot perform deep packet inspection and filtering.
IPv6エンドツーエンド通信を保護するために、IPSECトランスポートモードは一般に選択の解決策になります。ただし、これらのIPSECセキュリティ機能を使用すると、ネットワーク管理者に新しい問題が発生し、ファイアウォールが深いパケット検査とフィルタリングを実行できない暗号化されたパケットの有病率が増加するため、周囲のファイアウォールの有効性を低下させる可能性があります。
One example of such problems is the lack of security solutions in the middlebox, including effective content-filtering, ability to provide DoS prevention based on the expected TCP protocol behavior, and intrusion detection. Future solutions to this problem are discussed in Section 2.3.2. Another example is an IPsec-based DoS (e.g., sending malformed ESP/AH packets) that can be especially detrimental to software-based IPsec implementations.
このような問題の1つの例は、効果的なコンテンツフィルタリング、予想されるTCPプロトコル動作に基づいてDOS予防を提供する能力、侵入検知など、ミドルボックスにセキュリティソリューションの欠如です。この問題の将来の解決策については、セクション2.3.2で説明します。もう1つの例は、ソフトウェアベースのIPSEC実装に特に有害な場合があるIPSECベースのDOS（例えば、奇形のESP/AHパケットの送信）です。
With the deployment of IPv6 we can expect the attachment of a very large number of new IPv6-enabled devices with scarce resources and low computing capacity. The resource limitations are generally because of a market requirement for cost reduction. Although the [RFC4294] specifies some mandatory security capabilities for every conformant node, these do not include functions required for a node to be able to protect itself. Accordingly, some such devices may not be able even to perform the minimum set of functions required to protect themselves (e.g., 'personal' firewall, automatic firmware update, enough CPU power to endure DoS attacks). This means a different security scheme may be necessary for such reduced functionality devices.
IPv6の展開により、リソースが不足し、コンピューティング能力が低い非常に多数の新しいIPv6対応デバイスが添付されることが期待できます。リソースの制限は、一般に、コスト削減のための市場要件のためです。[RFC4294]は、すべての適合ノードにいくつかの必須セキュリティ機能を指定しますが、これらにはノードが自分自身を保護できるように必要な機能は含まれません。したがって、そのようなデバイスの中には、自分自身を保護するために必要な最小の機能セットを実行することさえできない場合があります（たとえば、「個人」ファイアウォール、自動ファームウェアアップデート、DOS攻撃に耐えるのに十分なCPUパワー）。これは、このような機能デバイスを削減するには、異なるセキュリティスキームが必要になる場合があることを意味します。
There are a number of reasons that make it essential to take particular care when enabling IPv6 in the network equipment:
ネットワーク機器でIPv6を有効にする際に、特に注意することを不可欠にする多くの理由があります。
Initially, IPv6-enabled router software may be less mature than current IPv4-only implementations, and there is less experience with configuring IPv6 routing, which can result in disruptions to the IPv6 routing environment and (IPv6) network outages.
当初、IPv6対応のルーターソフトウェアは、現在のIPv4のみの実装よりも成熟度が低く、IPv6ルーティングの構成に関する経験が少なくなり、IPv6ルーティング環境と（IPv6）ネットワークの停止が混乱する可能性があります。
IPv6 processing may not happen at (near) line speed (or at a comparable performance level to IPv4 in the same equipment). A high level of IPv6 traffic (even legitimate, e.g., Network News Transport Protocol, NNTP) could easily overload IPv6 processing especially when it is software-based without the hardware support typical in high-end routers. This may potentially have deleterious knock-on effects on IPv4 processing, affecting availability of both services. Accordingly, if people don't feel confident enough in the IPv6 capabilities of their equipment, they will be reluctant to enable it in their "production" networks.
IPv6処理は、（近くの）ライン速度（または同じ機器のIPv4に匹敵するパフォーマンスレベル）で発生しない場合があります。高レベルのIPv6トラフィック（正当な、たとえばネットワークニューストランスポートプロトコル、NNTPなど）は、特にハイエンドルーターに典型的なハードウェアサポートがないソフトウェアベースの場合、IPv6処理を簡単に過負荷にする可能性があります。これは、IPv4処理に有害なノックオン効果があり、両方のサービスの可用性に影響を与える可能性があります。したがって、人々が自分の機器のIPv6機能に十分に自信を持っていない場合、彼らは「生産」ネットワークでそれを有効にすることに消極的になります。
Sometimes essential features may be missing from early releases of vendors' software; an example is provision of software enabling IPv6 telnet/SSH access (e.g., to the configuration application of a router), but without the ability to turn it off or limit access to it!
ベンダーのソフトウェアの早期リリースから不可欠な機能が欠落している場合があります。例としては、IPv6 Telnet/SSHアクセスを可能にするソフトウェアの提供（例：ルーターの構成アプリケーションへ）ですが、それをオフにしたり、アクセスを制限したりする機能はありません。
Sometimes the default IPv6 configuration is insecure. For example, in one vendor's implementation, if you have restricted IPv4 telnet to only a few hosts in the configuration, you need to be aware that IPv6 telnet will be automatically enabled, that the configuration commands used previously do not block IPv6 telnet, that IPv6 telnet is open to the world by default, and that you have to use a separate command to also lock down the IPv6 telnet access.
デフォルトのIPv6構成が不安定な場合があります。たとえば、1つのベンダーの実装では、IPv4 Telnetを構成内の少数のホストのみに制限している場合、IPv6 Telnetが自動的に有効になること、以前に使用された構成コマンドがIPv6 Telnetをブロックしないこと、IPv6がTelnetはデフォルトで世界に開放されており、IPv6 Telnetアクセスもロックダウンするために別のコマンドを使用する必要があることです。
Many operator networks have to run interior routing protocols for both IPv4 and IPv6. It is possible to run them both in one routing protocol, or have two separate routing protocols; either approach has its tradeoffs [RFC4029]. If multiple routing protocols are used, one should note that this causes double the amount of processing when links flap or recalculation is otherwise needed -- which might more easily overload the router's CPU, causing slightly slower convergence time.
多くのオペレーターネットワークは、IPv4とIPv6の両方に対してインテリアルーティングプロトコルを実行する必要があります。それらを1つのルーティングプロトコルで実行するか、2つの個別のルーティングプロトコルを持つことができます。どちらのアプローチにもトレードオフがあります[RFC4029]。複数のルーティングプロトコルが使用される場合、リンクフラップまたは再計算が必要な場合に処理量が2倍になることに注意する必要があります。
In order to span a single subnet over multiple physical links, a new experimental capability is being trialed in IPv6 to proxy Neighbor Discovery messages. A node with this capability will be called an NDProxy (see [RFC4389]). NDProxies are susceptible to the same security issues as those faced by hosts using unsecured Neighbor Discovery or ARP. These proxies may process unsecured messages, and update the neighbor cache as a result of such processing, thus allowing a malicious node to divert or hijack traffic. This may undermine the advantages of using SEND [RFC3971].
複数の物理リンクに単一のサブネットを渡すために、IPv6で新しい実験機能が[近隣]ディスカバリーメッセージをプロキシに試行されています。この機能を備えたノードは、NDProxyと呼ばれます（[RFC4389]を参照）。NDProxiesは、無担保の隣人発見またはARPを使用してホストが直面しているものと同じセキュリティ問題を受けやすいです。これらのプロキシは、無担保メッセージを処理し、そのような処理の結果としてネイバーキャッシュを更新する可能性があるため、悪意のあるノードがトラフィックをそらしたりハイジャックしたりできます。これは、送信[RFC3971]を使用することの利点を損なう可能性があります。
If a form of NDProxy is standardized, SEND will need to be extended to support this capability.
ndproxyの形式が標準化されている場合、この機能をサポートするために送信を拡張する必要があります。
This memo attempts to give an overview of security considerations of the different aspects of IPv6, particularly as they relate to the transition to a network in which IPv4- and IPv6-based communications need to coexist.
このメモは、IPv6のさまざまな側面のセキュリティ上の考慮事項の概要を説明しようとします。特に、IPv4-およびIPv6ベースの通信が共存する必要があるネットワークへの移行に関連しているためです。
This document draws together the work of many people who have contributed security-related documents to the IPV6 and V6OPS working groups. Alain Durand, Alain Baudot, Luc Beloeil, Sharon Chisholm, Tim Chown, Lars Eggert, Andras Kis-Szabo, Vishwas Manral, Janos Mohacsi, Mark Smith, Alvaro Vives, and Margaret Wassermann provided feedback to improve this document. Satoshi Kondo, Shinsuke Suzuki, and Alvaro Vives provided additional inputs in cooperation with the Deployment Working Group of the Japanese IPv6 Promotion Council and the Euro6IX IST co-funded project, together with inputs from Jordi Palet, Brian Carpenter, and Peter Bieringer. Michael Wittsend and Michael Cole discussed issues relating to probing/mapping and privacy. Craig Metz and Jun-ichiro itojun Hagino did the original work identifying the problems of using IPv4-mapped IPv6 addresses on the wire. Vishwas Manral made further investigations of the impact of tiny fragments on IPv6 security. Francis Dupont raised the issues relating to IPv6 Privacy Addresses. Finally, Pekka Savola wrote a number of documents on aspects IPv6 security which have been subsumed into this work. His document on "Firewalling Considerations for IPv6" (October 2003) originally identified many of the issues with the base IPv6 specification which are documented here.
このドキュメントは、IPv6およびV6OPSワーキンググループにセキュリティ関連のドキュメントを提供した多くの人々の作業をまとめています。アラン・デュランド、アラン・ボーダット、ルック・ベロエイル、シャロン・チショルム、ティム・チャウン、ラース・エガート、アンドラス・キス・スザボ、ヴィシュワス・マンラル、ジャノス・モハクシ、マーク・スミス、アルバロ・ヴィヴィヴ、マーガレット・ワスサルマンは、この文書を改善するためのフィードバックを提供しました。佐藤島、鈴木島、およびアルバロ・ヴィブスは、ジョルディ・パレット、ブライアン・カーペンター、ピーター・ビリアンジャーからのインプットとともに、日本のIPv6プロモーション評議会およびEuro6ix ISTの共同資産プロジェクトの展開ワーキンググループと協力して追加のインプットを提供しました。Michael WittsendとMichael Coleは、調査/マッピングとプライバシーに関する問題について議論しました。Craig MetzとJun-Ithiro Itojun Haginoは、ワイヤーでIPv4-Mapped IPv6アドレスを使用する問題を特定する元の作業を行いました。Vishwas Manralは、IPv6セキュリティに対する小さな断片の影響についてさらに調査しました。フランシス・デュポンは、IPv6プライバシーアドレスに関連する問題を提起しました。最後に、Pekka Savolaは、この作業に包まれているIPv6セキュリティの側面に関する多くのドキュメントを書きました。「IPv6のファイアウォールに関する考慮事項」（2003年10月）に関する彼のドキュメントでは、ここで文書化されている基本IPv6仕様に関する多くの問題を特定しました。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[RFC2375] Hinden、R。およびS. Deering、「IPv6マルチキャストアドレスの割り当て」、RFC 2375、1998年7月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964] Savola、P。およびC. Patel、「6to4のセキュリティ上の考慮事項」、RFC 3964、2004年12月。
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
[RFC4007] Deering、S.、Haberman、B.、Jinmei、T.、Nordmark、E。、およびB. Zill、「IPv6スコープアドレスアーキテクチャ」、RFC 4007、2005年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema、C。、「Teredo：ネットワークアドレス翻訳（NAT）を介してUDPを介してIPv6をトンネル化する」、RFC 4380、2006年2月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）、RFC 4443、2006年3月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 4941、2007年9月。
[FNAT] Bellovin, S., "Technique for Counting NATted Hosts", Proc. Second Internet Measurement Workshop , November 2002, <http://www.research.att.com/~smb/papers/fnat.pdf>.
[FNAT] Bellovin、S。、「Natted Hostsをカウントするためのテクニック」、Proc。2番目のインターネット測定ワークショップ、2002年11月、<http://www.research.att.com/~smb/papers/fnat.pdf>。
[ICMP-ATT] Gont, F., "ICMP attacks against TCP", Work in Progress, May 2007.
[ICMP-ATT] Gont、F。、「TCPに対するICMP攻撃」、2007年5月、進行中の作業。
[IEEE.802-1X] Institute of Electrical and Electronics Engineers, "Port-Based Network Access Control", IEEE Standard for Local and Metropolitan Area Networks 802.1X-2004, December 2004.
[IEEE.802-1X]電気および電子機器エンジニアの研究所、「港湾ベースのネットワークアクセス制御」、2004年12月、地元および大都市圏ネットワーク802.1x-2004のIEEE標準。
[JpIPv6DC] Deployment WG, "IPv6 Deployment Guideline (2005 Edition)", IPv6 Promotion Council (Japan) Deployment Working Group, 2005, <http://www.v6pc.jp/>.
[JPIPV6DC]展開WG、「IPv6展開ガイドライン（2005年版）」、IPv6プロモーション評議会（日本）展開ワーキンググループ、2005、<http://www.v6pc.jp/>。
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858] Ziemba、G.、Reed、D。、およびP. Traina、「IPフラグメントフィルタリングのセキュリティ上の考慮事項」、RFC 1858、1995年10月。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765] Nordmark、E。、「Stateless IP/ICMP翻訳アルゴリズム（SIIT）」、RFC 2765、2000年2月。
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766] Tsirtsis、G。およびP. Srisuresh、「ネットワークアドレス翻訳 - プロトコル翻訳（NAT -PT）」、RFC 2766、2000年2月。
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3128] Miller、I。、「小さなフラグメント攻撃のバリアントに対する保護（RFC 1858）」、RFC 3128、2001年6月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J。、およびW. Stevens、「IPv6の基本ソケットインターフェイス拡張」、RFC 3493、2003年2月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756] Nikander、P.、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trustモデルと脅威」、RFC 3756、2004年5月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, March 2005.
[RFC4025]リチャードソン、M。、「DNSにIPSECキーイング材料を保存する方法」、RFC 4025、2005年3月。
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[RFC4029] Lind、M.、Ksinant、V.、Park、S.、Baudot、A。、およびP. Savola、「IPv6をISPネットワークに導入するためのシナリオと分析」、RFC 4029、2005年3月。
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[RFC4038] Shin、M-K。、Hong、Y-G。、Hagino、J.、Savola、P。、およびE. Castro、「IPv6遷移のアプリケーションの側面」、RFC 4038、2005年3月。
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
[RFC4074] Morishita、Y。およびT. Jinmei、「IPv6アドレスのDNSクエリに対する一般的な不正行為」、RFC 4074、2005年5月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191] Draves、R。およびD. Thaler、「デフォルトのルーターの設定とより固有のルート」、RFC 4191、2005年11月。
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[RFC4225] Nikander、P.、Arkko、J.、Aura、T.、Montenegro、G。、およびE. Nordmark、「モバイルIPバージョン6ルート最適化セキュリティデザイン背景」、RFC 4225、2005年12月。
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006.
[RFC4294] Loughney、J。、「IPv6ノード要件」、RFC 4294、2006年4月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, November 2005.
[RFC4311] Hinden、R。およびD. Thaler、「IPv6ホストからルーターへの負荷共有」、RFC 4311、2005年11月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389] Thaler、D.、Talwar、M。、およびC. Patel、「Neighbor Discovery Proxies（ND Proxy）」、RFC 4389、2006年4月。
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, April 2006.
[RFC4472] Durand、A.、Ihren、J。、およびP. Savola、「IPv6 DNSに関する運用上の考慮事項と問題」、RFC 4472、2006年4月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864] van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B。、およびE. Klein、「IPv6のローカルネットワーク保護」、RFC 4864、2007年5月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890] Davies、E。およびJ. Mohacsi、「ファイアウォールでICMPV6メッセージをフィルタリングするための推奨」、RFC 4890、2007年5月。
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Historic Status", RFC 4966, July 2007.
[RFC4966] Aoun、C。およびE. Davies、「Nat-PTを歴史的地位に移す理由」、RFC 4966、2007年7月。
[SCAN-IMP] Chown, T., "IPv6 Implications for Network Scanning", Work in Progress, March 2007.
[Scan-Imp] Chown、T。、「ネットワークスキャンへのIPv6の影響」、2007年3月、進行中の作業。
[SIXNET] 6Net, "Large Scale International IPv6 Pilot Network", EU Information Society Technologies Project , 2005, <http://www.6net.org/>.
[Sivnet] 6NET、「大規模な国際IPv6パイロットネットワーク」、EU Information Society Technologies Project、2005、<http://www.6net.org/>。
[TCGARCH] The Trusted Computing Group, "TCG Specification Architecture Overview", April 2004, <https:// www.trustedcomputinggroup.org/groups/ TCG_1_0_Architecture_Overview.pdf>.
[TCGARCH]信頼できるコンピューティンググループ、「TCG仕様アーキテクチャの概要」、2004年4月、<https：// www.trustedcomputinggroup.org/groups/ tcg_1_0_architecture_overview.pdf>。
[VRRP] Hinden, R. and J. Cruz, "Virtual Router Redundancy Protocol for IPv6", Work in Progress, March 2007.
[VRRP] Hinden、R。およびJ. Cruz、「IPv6の仮想ルーター冗長プロトコル」、2007年3月、進行中の作業。
Appendix A. IPv6 Probing/Mapping Considerations
付録A. IPv6プロービング/マッピングの考慮事項
One school of thought wanted the IPv6 numbering topology (either at network or node level) to match IPv4 as exactly as possible, whereas others see IPv6 as giving more flexibility to the address plans, not wanting to constrain the design of IPv6 addressing. Mirroring the address plans is now generally seen as a security threat because an IPv6 deployment may have different security properties from IPv4.
ある考え方は、IPv6番号のトポロジ（ネットワークまたはノードレベルのいずれか）がIPv4を可能な限り一致させることを望んでいましたが、IPv6はアドレス計画により柔軟性を与え、IPv6アドレスの設計を制約したくないと考えています。アドレスプランのミラーリングは、IPv6の展開にはIPv4とは異なるセキュリティプロパティがあるため、一般にセキュリティの脅威と見なされています。
Given the relatively immature state of IPv6 network security, if an attacker knows the IPv4 address of the node and believes it to be dual-stacked with IPv4 and IPv6, he might want to try to probe the corresponding IPv6 address, based on the assumption that the security defenses might be lower. This might be the case particularly for nodes which are behind a NAT in IPv4, but globally addressable in IPv6. Naturally, this is not a concern if similar and adequate security policies are in place.
IPv6ネットワークセキュリティの比較的未熟な状態を考えると、攻撃者がノードのIPv4アドレスを知っており、IPv4とIPv6でデュアルスタックしていると信じている場合、彼は対応するIPv6アドレスをプローブしようとするかもしれません。セキュリティ防御は低いかもしれません。これは、特にIPv4のNATの背後にあるノードに当てはまるかもしれませんが、IPv6でグローバルにアドレス指定できます。当然のことながら、これは、類似の適切なセキュリティポリシーが整っているかどうかの懸念ではありません。
On the other hand, brute-force scanning or probing of addresses is computationally infeasible due to the large search space of interface identifiers on most IPv6 subnets (somewhat less than 64 bits wide, depending on how identifiers are chosen), always provided that identifiers are chosen at random out of the available space, as discussed in [SCAN-IMP].
一方、ほとんどのIPv6サブネットのインターフェイス識別子の大きな検索スペース（識別子の選択方法によっては64ビット未満）のため、ブルートフォーススキャンまたはアドレスの調査は計算上無効です。[Scan-Imp]で説明されているように、利用可能なスペースからランダムに選択されます。
For example, automatic tunneling mechanisms typically use deterministic methods for generating IPv6 addresses, so probing/ port-scanning an IPv6 node is simplified. The IPv4 address is embedded at least in 6to4, Teredo, and ISATAP addresses. Additionally, it is possible (in the case of 6to4 in particular) to learn the address behind the prefix; for example, Microsoft 6to4 implementation uses the address 2002:V4ADDR::V4ADDR while older Linux and FreeBSD implementations default to 2002:V4ADDR::1. This could also be used as one way to identify an implementation and hence target any specific weaknesses.
たとえば、自動トンネリングメカニズムは通常、IPv6アドレスを生成するために決定論的方法を使用するため、IPv6ノードの調査/ポートスキャンは簡素化されます。IPv4アドレスは、少なくとも6to4、Teredo、およびISATAPアドレスで埋め込まれています。さらに、（特に6to4の場合）プレフィックスの背後にあるアドレスを学習することが可能です。たとえば、Microsoft 6to4実装では、アドレス2002：V4ADDR :: V4ADDRを使用しますが、古いLinuxとFreeBSDの実装はデフォルトで2002：V4ADDR :: 1です。これは、実装を識別する1つの方法として使用するため、特定の弱点をターゲットにすることもできます。
One proposal has been to randomize the addresses or subnet identifier in the address of the 6to4 router. This does not really help, as the 6to4 router (whether a host or a router) will return an ICMPv6 Hop Limit Exceeded message, revealing the IP address. Hosts behind the 6to4 router can use methods such as privacy addresses [RFC4941] to conceal themselves, provided that they are not meant to be reachable by sessions started from elsewhere; they would still require a globally accessible static address if they wish to receive communications initiated elsewhere.
1つの提案は、6to4ルーターのアドレスのアドレスまたはサブネット識別子をランダム化することでした。6to4ルーター（ホストまたはルーターであろうと）がICMPv6ホップ制限を返すと、IPアドレスが表示されるため、これは実際には役立ちません。6to4ルーターの背後にあるホストは、プライバシーアドレス[RFC4941]などのメソッドを使用して、他の場所から開始されたセッションで到達できることを意図していない場合があります。他の場所で開始されたコミュニケーションを受けたい場合は、グローバルにアクセス可能な静的アドレスが必要になります。
To conclude, it seems that when an automatic tunneling mechanism is being used, given an IPv4 address, the corresponding IPv6 address could possibly be guessed with relative ease. This has significant implications if the IPv6 security policy is less adequate than that for IPv4.
結論として、IPv4アドレスを考慮して、自動トンネルメカニズムを使用すると、対応するIPv6アドレスが比較的簡単に推測される可能性があるようです。これは、IPv6セキュリティポリシーがIPv4のセキュリティポリシーよりも適していない場合、重要な意味を持ちます。
The generation of IPv6 addresses from MAC addresses potentially allows the behavior of users to be tracked in a way which may infringe their privacy. [RFC4941] specifies mechanisms which can be used to reduce the risk of infringement. It has also been claimed that IPv6 harms the privacy of the user, either by exposing the MAC address, or by exposing the number of nodes connected to a site.
MACアドレスからのIPv6アドレスの生成により、ユーザーの動作がプライバシーを侵害する可能性のある方法で追跡できる可能性があります。[RFC4941]は、侵害のリスクを減らすために使用できるメカニズムを指定します。また、IPv6は、Macアドレスを公開するか、サイトに接続されているノードの数を公開することにより、ユーザーのプライバシーに害を及ぼすと主張されています。
Additional discussion of privacy issues can be found in [RFC4864].
プライバシーの問題に関する追加の議論は[RFC4864]にあります。
Using stateless address autoconfiguration results in the MAC address being incorporated in an EUI64 that exposes the model of network card. The concern has been that a user might not want to expose the details of the system to outsiders, e.g., fearing a resulting burglary if a thief identifies expensive equipment from the vendor identifier embedded in MAC addresses, or allowing the type of equipment in use to be identified, thus facilitating an attack on specific security weaknesses.
Stateless Addressの使用Autoconfigurationの結果、MACアドレスがネットワークカードのモデルを公開するEUI64に組み込まれています。懸念は、ユーザーがシステムの詳細を部外者に公開したくないかもしれないということです。たとえば、泥棒がMACアドレスに埋め込まれたベンダー識別子から高価な機器を識別したり、使用している機器の種類を使用したりした場合、結果として生じる強盗を恐れます。特定されるため、特定のセキュリティの弱点に対する攻撃を促進します。
In most cases, this seems completely unfounded. First, such an address must be learned somehow -- this is a non-trivial process; the addresses are visible, e.g., in Web site access logs, but the chances that a random Web site owner is collecting this kind of information (or whether it would be of any use) are quite slim. Being able to eavesdrop the traffic to learn such addresses (e.g., by the compromise of DSL (Digital Subscriber Line) or Cable modem physical media) seems also quite far-fetched. Further, using statically configured interface identifiers or privacy addresses [RFC4941] for such purposes is straightforward if worried about the risk. Second, the burglar would have to be able to map the IP address to the physical location; typically this would only be possible with information from the private customer database of the Internet Service Provider (ISP) and, for large sites, the administrative records of the site, although some physical address information may be available from the WHOIS database of Internet registries.
ほとんどの場合、これは完全に根拠がないようです。第一に、そのようなアドレスはどういうわけか学習する必要があります - これは自明ではないプロセスです。アドレスは、たとえば、Webサイトのアクセスログに表示されますが、ランダムなWebサイトの所有者がこの種の情報（または使用するかどうか）を収集している可能性は非常にスリムです。そのようなアドレスを学習するためにトラフィックを盗聴できること（例：DSL（デジタル加入者ライン）またはケーブルモデム物理メディアの妥協によって）も非常に大げさなようです。さらに、このような目的のために、静的に構成されたインターフェイス識別子またはプライバシーアドレスアドレス[RFC4941]を使用することは、リスクを心配する場合は簡単です。第二に、強盗はIPアドレスを物理的な場所にマッピングできる必要があります。通常、これは、インターネットサービスプロバイダー（ISP）のプライベートカスタマーデータベースからの情報でのみ可能です。また、大規模なサイトの場合、サイトの管理記録がありますが、インターネットレジストリのWOHISデータベースから物理的なアドレス情報が入手できます。
Another concern that has been aired involves the user wanting to conceal the presence of a large number of computers or other devices connected to a network; NAT can "hide" all this equipment behind a single address, but it is not perfect either [FNAT].
放映されているもう1つの懸念は、ユーザーがネットワークに接続されている多数のコンピューターまたは他のデバイスの存在を隠したいことです。Natは、このすべての機器を単一のアドレスの後ろに「非表示」することができますが、[FNAT]も完璧ではありません。
One practical reason why some administrators may find this desirable is being able to thwart certain ISPs' business models. These models require payment based on the number of connected computers, rather than the connectivity as a whole.
一部の管理者がこれが望ましいと感じるかもしれない実際の理由の1つは、特定のISPのビジネスモデルを阻止できることです。これらのモデルは、接続性全体ではなく、接続されたコンピューターの数に基づいて支払いを必要とします。
Similar feasibility issues as described above apply. To a degree, the number of machines present could be obscured by the sufficiently frequent reuse of privacy addresses [RFC4941] -- that is, if during a short period, dozens of generated addresses seem to be in use, it's difficult to estimate whether they are generated by just one host or multiple hosts.
上記の同様の実現可能性の問題が適用されます。ある程度、存在するマシンの数は、プライバシーアドレスの十分に頻繁に再利用される[RFC4941]によって不明瞭になる可能性があります。つまり、短期間に生成されたアドレスが使用されているように見える場合、それらを推定することは困難です。1つのホストまたは複数のホストによって生成されます。
When an ISP provides IPv6 connectivity to its customers, including home or consumer users, it delegates a fixed global routing prefix (usually a /48) to them. This is in contrast to the typical IPv4 situation where home users typically receive a dynamically allocated address that may be stable only for a period of hours.
ISPが在宅ユーザーや消費者ユーザーを含む顧客にIPv6接続を提供する場合、固定されたグローバルルーティングプレフィックス（通常はA /48）を委任します。これは、通常、ホームユーザーが数時間だけ安定する可能性のある動的に割り当てられたアドレスを受信する典型的なIPv4状況とは対照的です。
Due to this fixed allocation, it is easier to correlate the global routing prefix to a network site. With consumer users, this correlation leads to a privacy issue, since a site is often equivalent to an individual or a family in such a case. Consequently some users might be concerned about being able to be tracked based on their /48 allocation if it is static [RFC4941]. On the other hand, many users may find having a static allocation desirable as it allows them to offer services hosted in their network more easily.
この固定割り当てにより、グローバルルーティングのプレフィックスをネットワークサイトと相関させる方が簡単です。消費者ユーザーの場合、この相関はプライバシーの問題につながります。これは、そのような場合のサイトが個人または家族に相当することが多いためです。その結果、一部のユーザーは、静的[RFC4941]の場合、 /48の割り当てに基づいて追跡できることを心配する可能性があります。一方、多くのユーザーは、ネットワークでホストされているサービスをより簡単に提供できるため、静的割り当てが望ましいと感じるかもしれません。
This situation is not affected even if a user changes his/her interface ID or subnet ID, because malicious users can still discover this binding. On larger sites, the situation can be mitigated by using "untraceable" IPv6 addresses as described in [RFC4864], and it is possible that in the future ISPs might be prepared to offer untraceable addresses to their consumer customers to minimize the privacy issues.
悪意のあるユーザーがこのバインディングを発見できるため、ユーザーがインターフェイスIDまたはサブネットIDを変更しても、この状況は影響を受けません。大規模なサイトでは、[RFC4864]に記載されている「追跡不可能な」IPv6アドレスを使用することで状況を軽減できます。また、将来、ISPが消費者の顧客にプライバシーの問題を最小限に抑えるために追跡不可能なアドレスを提供する準備ができている可能性があります。
This privacy issue is common to both IPv4 and IPv6 and is inherent in the use of IP addresses as both identifiers for node interfaces and locators for the nodes.
このプライバシーの問題は、IPv4とIPv6の両方に共通しており、ノードインターフェイスの識別子とノードのロケーターの両方としてIPアドレスの使用に固有のものです。
Authors' Addresses
著者のアドレス
Elwyn B. Davies Consultant Soham, Cambs UK
Elwyn B. DaviesコンサルタントSoham、Cambs UK
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC H4P 2N2 Canada
Suresh Krishnan Ericsson 8400 Decarie Blvd.マウントロイヤルの町、QC H4P 2N2カナダ
Phone: +1 514-345-7900
EMail: suresh.krishnan@ericsson.com
Pekka Savola CSC/Funet
Pekka Savola CSC/FUNET
EMail: psavola@funet.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。