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
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とIPv6の混在がIPv6を導入し、デュアルプロトコルネットワークと関連付けられた遷移機構を操作する際に考慮される必要があり、余分なセキュリティ問題の数をもたらし、ネットワークに純粋IPv4ネットワークからの移行。移行メカニズム、およびIPv6の導入に起因するOの問題に起因する問題O、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とIPv6の混在は、IPv6の導入とそれに関連する遷移機構をデュアルプロトコル・ネットワークを操作する際に考慮される必要がある余分なセキュリティ問題の数をもたらし、ネットワークに純粋IPv4ネットワークからの移行。移行メカニズム、およびIPv6の導入に起因するOの問題に起因する問題O、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.
展開は（短期的に）IPv6でのIPv4を交換されそうにないことを理解することが重要それをあるのではなく、かなりの期間にわたってIPv4のと並行して動作するようにIPv6を追加する予定、移行メカニズムとデュアルスタックとなるようにセキュリティ上の問題ネットワークは、継続的な関心事となります。この拡張移行と共存期間は、主に、現在のIPv4ネットワークの規模に由来します。 IPv4ノードの数百万が一晩に変換されることを期待するのは無理があります。 IPv6の機能は、ネットワークを介して広がるすることが（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では、プライバシーに関して/マッピングIPv6アドレス（付録A）および注意事項を探査についての考慮事項：この文書はまた、誤って過去にIPv6のための潜在的なセキュリティ上の懸念として識別し、それらが問題を引き起こす可能性が低い理由を説明された2つの事項について説明し付録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を宛先アドレスに基づいてアクセス制御を回避します。これは、一般にアクセス可能なホストアドレスに表向きは、パケットを送信することではなく「禁じられた」アドレスを含むルーティングヘッダを達成することができました。公的にアクセス可能なホストがルーティングヘッダを処理している場合、それは、パケットが確認した時にアドレスが宛先フィールドにあった場合は、パケットフィルタにより禁止されていたであろうルーティングヘッダの宛先アドレスにパケットを転送します。
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.)
タイプ0ルーティングヘッダを使用するときにパケットの送信元アドレスを偽装することができれば、O、前項で説明した機構は、任意の公的にアクセス可能なホストが攻撃をリダイレクト有することにより、サービス拒否攻撃匿名反射を媒介する任意のホストで使用することができパケット。 （パケットがルーティングヘッダ、すなわち、パケットの元の宛先を処理するホストの外に転送することができないので、この攻撃は、タイプ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.
ルーティングヘッダを使用して、ルータやファイアウォールで増幅攻撃の様々な形態を想定することができます。単純な形態は、ルーティングヘッダにウェイポイントのアドレスを複数回繰り返すことを含みます。より複雑なフォームは、パケットの再移行ルーターやファイアウォールにつながるウェイポイントのアドレスを交互に関与し得ます。自分の道を逆に作られたパケットは、このテストを失敗します。これらの攻撃は、ルーティングヘッダが複数回同じウェイポイントのアドレスが含まれていないことを確実にすること、および送信元アドレスが宛先に適切であることを確認するために入口/出口フィルタリングを行うことで相殺することができます。
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.
[RFC2375]で定義されたアドレス：特定の例としては、 'すべてのルータ'（FF05 :: 2）と「すべての動的ホスト構成プロトコル（DHCP）サーバの（3 FF05 :: 1）です。サイトにこれらのアドレス宛てのメッセージを浸透させることが可能である攻撃者がサイト上で重要なリソースを特定するリターン情報に届きます。この情報は、単純なフラッディングからデバイスを破壊するように設計された複数の特定の機構に至るまで導か攻撃の標的とすることができます。
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受信したパケットが長く、次のリンクの最大伝送ユニット（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.
受信されたパケットは、バイナリ「10」に設定オプションタイプの最初の2ビットとホップバイホップもしくは宛先オプション拡張ヘッダ内の認識できないオプションが含まれている○：「パラメータ問題の回答を一部又はソースに通知することが意図されています受信者のすべては、問題のオプションを取り扱うことができません。
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を持つネットワークを利用することができる場合を除き多くの増幅を引き起こしにくいです。同様に、未認識のホップバイホップオプションを持つパケットは、複数の応答を生じさせることなく、第1のルータによって廃棄されるであろう。しかし、認識されていない宛先オプションを持つパケットは、複数の応答を生成することができます。
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.
特定の上位層プロトコルのための特定の対策は、この文書の範囲を超えているが、ファイアウォールは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のの仕様は、エラーメッセージができるだけエラーが発生したパケットの多くを運ぶ必要とし、IPv6ネットワーク（最低限のエラーが発生したパケットの量を必要とIPv4のICMPとは異なり）1280オクテットの最低保証MTUを持っている必要があります。したがって、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は、エニーキャストアドレスおよびサービスの概念を導入しています。もともとIPv6の標準規格は、パケットの送信元アドレスとしてエニーキャストアドレスを使用して許可されていません。エニーキャストサーバからの応答は、従って、応答サーバのユニキャストアドレスを供給することになります。ネットワークの内部構造についての知識を公開しないためには、エニーキャストサーバが可能になりました場合、送信元アドレスとしてエニーキャストアドレスを持つ応答を返す機能を利用することをお勧めします。
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.
サーバーが何らかの理由でユニキャストアドレスを使用する必要がある場合、露出情報を制限するために、ネットワークの他の部分に使用されていないエニーキャストサーバ、に特化したアドレスを使用することを検討することが望ましい場合があります。あるいは、オペレータは、このようにエニーキャスト要求をフィルタリングするためのファイアウォールを必要とする、ドメイン外からエニーキャストサービスの使用を制限することを望むかもしれません。この目的のために、ファイアウォールはアドレスがエニーキャストサービスに使用されているかを知る必要があります。これらのアドレスは、任意の構造またはパターンによって他の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.
特別な注意を与えられるべきであるエニーキャストアドレスの一つの特定のクラスは、「IPバージョン6アドレッシング体系」[RFC4291]で定義されたサブネットルータエニーキャストアドレスのセットです。すべてのルータは、それらがインタフェースを持っているすべてのサブネットのためにこれらのアドレスをサポートするために必要とされています。グローバルユニキャストアドレスを使用して、ほとんどのサブネットのために、これらのアドレスのフィルタリングエニーキャスト要求はすべてゼロに設定下位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.
ステートレスアドレス自動設定[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.
ノードが行儀されている場合でも、アドレスの変更は、（例えば、アクセス制御リスト）アドレスベースのポリシールールを定義するために、セキュリティ管理者のために困難にそれを作ることができることに注意してください。しかし、プライバシーのアドレスを使用したノードは、すべての通信のためにそれらを使用する必要はありません。
2.1.8. Dynamic DNS: Stateless Address Autoconfiguration, Privacy Extensions, and SEND
2.1.8. ダイナミックDNS：ステートレスアドレス自動設定、プライバシーの拡張機能、および、SEND
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でステートレスアドレス自動設定（SLAAC）の導入[RFC2462]は、ダイナミックドメインネームシステム（DDNS）のセキュリティへの追加的な挑戦を提供します。アドレッシング手動またはDHCPを使用すると、ドメインネームサービス（DNS）サーバーへのアクセスを確保するために維持する必要があるセキュリティアソシエーションの数が必要な更新がDHCPサーバーによって行われていると仮定すると、制限されています。これは、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チェックを実行するサーバーでは、ノードからの接続を受け入れることはありません、IPセキュリティ（IPsec）のDNS [RFC4025]に保存されている鍵材料へのアクセスを得るすることはできません。実際のプライバシーを達成するために必要な変化の割合が増加する必要がある場合（2.1.7項を参照）、DDNSの更新率が過剰になることがあります。
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.
同様に、SEND [RFC3971]によって使用される暗号化生成アドレスは定期的に最大のキー寿命のための勧告に沿って再生することが期待されます。この再生もDDNSに重要な余分な負荷をかけることができます。
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).
この要求は、ホップバイホップオプションは、パケットが適切な宛先（最終宛先またはAのいずれかに到達するまでパケットが通過する任意のノードで処理されることを必要とする[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）形式を使用することを強制しません。 （のみTypeフィールドのサイズが保証され、オフセットされています。）
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で論じたようにIPv6仕様と競合現在かもしれ全体拡張ヘッダチェーンを処理するためにファイアウォールを必要とします。
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.
ファイアウォールが全体ヘッダーチェーンを調べる場合でも、ファイアウォールによって認識できないアイテムを持つパケットを廃棄するように賢明ではないかもしれない：中間ノードはオプションとヘッダは、宛先ノードに実装されており、IPv6が意図的に設計されたの知識を有していません新しいヘッダ・オプションを追加することを介して拡張可能です。これは、ファイアウォール管理者のためのジレンマをもたらします。一方で、「不明」オプションを使用してパケットを認めることは、セキュリティ上のリスクであるが、それらをドロップすると便利な新しい拡張機能を無効にすることができます。最良の妥協は、拡張子の種類に基づいて構成廃棄ポリシーを提供し、ファイアウォールを選択するように見えます。新しい拡張機能が標準化されている場合次に、管理者は、ハードウェアまたはソフトウェアが新しい定義を認識していないので、彼らがそう認識しない正当なアイテムでパケットを渡すために、ファイアウォールを再設定することができます。新しい拡張機能は、現在の拡張が続く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は、ホップバイホップオプションヘッダに存在することができるホップバイホップオプションの数を限定するものではなく、任意のオプションが複数回現れることができます。制限の欠如と、彼らは理解していないオプションのクラスを無視するようにノードを強制拡張ビットの提供は、パス上のすべてのノードに影響を与えるサービス拒否攻撃をマウントするために使用することができます。未知のホップバイホップオプションの大量のパケットは、各オプションのために実行するアクションを決定するためにかなりの資源を消費し、それが転送されて、すべてのノードで処理されます。不適切な繰り返しオプションを持つパケットを廃棄することができるようにパッド1とパッドNを除いて、現在のオプションが複数回表示されません。しかし、選択肢が見られているのを追跡することは、ファイアウォールが複雑にし、将来の拡張には適用されない場合があります。ファイアウォールで不明なオプションを使用してパケットをドロップの可否に関する議論については、セクション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'.
パッドNオプションは、「ペイロード」としてゼロオクテットを含むように要求されています。受信機がこれをチェックするためのインセンティブは、しかし、ありません。したがって、隠れチャネルとしてパディングオプションの「ペイロード」を使用することも可能です。ファイアウォールと受信ホストは、積極的にパッドNだけその「ペイロード」でゼロオクテットを持っていることを確認する必要があります。
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オクテット境界上に整列されているが、-octet境界16（二の又はより高いパワー）であることを保証することができないので、次の8つのオクテット境界を越えてパディングのための正当な理由はありません。 IPv6仕様は、複数のパッド1およびパッドNオプションは、ソースが必要なパディングを構成するために選択した任意の方法で合成することが可能になります。合理的な設計上の選択肢が必要とされているが、多くのパッド1のオプション（すなわち、ゼロオクテット）を使用して、または（2〜7までのオクテットから）必要なサイズの単一パッドNオプションを使用しているように思われます。管理者は、少なくとも、ロギング珍しいパディングパターンを考慮しなければならない、と彼らは期待されるソースの動作の確実な場合の異常なパターンを含むパケットをドロップ検討することができます。
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.
[RFC2460]で許可がO、重複パケットのフラグメントを生成するソースの理由はありません、そして重複は、プロトコル仕様の将来の改訂に禁止することができます。ファイアウォールは重複フラグメントとすべてのパケットをドロップする必要があります。特定の実装では、両方のファイアウォールおよび他のノードに既にそのようなパケットをドロップ。
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の場合と同じ方法で解決しない：攻撃者があれば、長い長さの一の以上の未定義の宛先オプションを挿入し、「無視することができ不明」ビットがセット。最低保証の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（最も可能性の高い選択肢）を使用して、最終的な1以外のすべての断片の大きさを最大化し、又はその断片のに必要な最小数で均等にデータを分散するかのいずれか可能性があります。いずれの場合においても、最小の非最終的な断片は、少なくとも半分の保証最小MTU（640オクテット）であろう - ペイロードが単一のパケットのためにあまりにも大であり、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ノードは、各インターフェイスにリンクローカルアドレスを設定する必要があります。このアドレスは、特に近隣探索と自動プロセスの間、直接インタフェースを介してアクセスリンクに接続された他のノードと通信するために使用されます。リンクローカルアドレスは、近隣探索プロトコル（NDP）[RFC2461]とステートレスアドレス自動設定（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リンクローカルアドレスの脆弱性は、いくつかの方法で緩和することができます。一般的な解決策を必要とします
o authenticating the link-layer connectivity, for example, by using IEEE 802.1X functionality [IEEE.802-1X] or physical security, and
IEEE 802.1X機能[IEEE.802-1X]または物理的なセキュリティを使用することにより、例えば、リンク層接続性を認証O、及び
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.
暗号生成されたリンクローカルアドレスを作成するために、セキュア近隣探索（SEND）を用いてO（[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.
任意のフィルタリングは、ホストベースまたはブリッジングファイアウォールによって提供されなければなりません。一般に、リンクローカルアドレスは、特定のインタフェースとリンクに対処するために書かれているアプリケーションによって使用されることが期待されています。通常、これらのアプリケーションを制御および管理のために使用されています。複数のリンクに取り付けられているノードは、これらのリンクに関連付けられている潜在的に重複するリンクローカルアドレス空間に対処しなければなりません。 IPv6は異なるアドレススコープ[RFC4007]とソケットアドレス構造[RFC3493]に関連付けることができるスコープ識別子を区別するために使用されるゾーン識別子を介してこれを提供します。ほとんどのユーザーは、これらの問題に慣れていないと、汎用アプリケーションは、差別のこの種を処理するために意図されていません。リンクローカルアドレスは通常、ドメインネームシステム（DNS）で使用されていない、とDNSゾーン識別子を供給することはできません。制御および管理プロトコル以外の手段によってリンクローカルアドレスの使用を防止するために必要と考えられる場合は、管理者がリンクローカルアドレスで使用できるプロトコルを制限することを検討してしたいことがあります。最低でも、ICMPv6の及び（例えば、オープンショーテストパスファースト（OSPF）またはルーティング情報プロトコル（RIP）として）使用されている任意のドメイン内ルーティングプロトコルを許可する必要があるが、他のプロトコルも必要とされ得ます。そのメッセージは、ユーザーデータグラムプロトコル（UDP）ペイロードとしてカプセル化され、フィルタリングはRIPメッセージが他のUDPメッセージからUDPポート521宛区別する必要がある：RIPは、フィルタリングの問題の複雑さを示しています。
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].
近隣探索プロセスの一環として、リンク上のルータは、ルータ広告メッセージでその機能をアドバタイズします。 [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]は、ルータが、彼らは証明書ベースのメカニズムを介して宣伝するサービスを提供するために許可された検証を提供するために使用することができます送信します。 SENDのこの機能は、クライアントがルータの主張ではなく、物理的にセキュアな接続に依存している無線環境のためにも特に適しています。
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と比較して有意に強化されたセキュリティを提供しています。リターンルータビリティチェックは、それがネットワーク経由で移動するモバイルノードが使用する異なるアドレスが実際にすべて同じノードを参照しないことに、比較的強固な保証を提供するために使用されています。脅威とソリューションは、[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.
[RFC3493]で定義されるように、オペレーティングシステム内のIPv6アドレスとしてIPv4アドレスの表現：そのようなものの一例は、IPv4射影IPv6アドレス（:: FFFF / 96）です。元の仕様ので、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アドレス*実際のIPv6アドレス形式（基本APIの動作）で表されるIPv4アドレスであるか*マッピングされたかどうかを見分けることが困難になります）。 （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.
攻撃者がで:: FFFF IPv6パケットを送信した場合○：IPv6ソースアドレスフィールドに127.0.0.1を、彼は、パケットが、具体的ノード自体（からのものであることを信じるように欺くアプリケーションによって、ノードのアクセス制御をバイパスすることができるかもしれません、 IPv4のループバックアドレス、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.
攻撃者は、サイトのセキュリティ境界（例えば、:: FFFF：10.1.1.1）内のIPv4アドレスに対応するIPv6宛先アドレスフィールドにIPv4射影アドレスを持つIPv6パケットを送信した場合は、O、彼は、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.
攻撃者がIPv6ソースアドレスと宛先アドレスを交換プロトコルへのIPv6送信元および宛先フィールドでIPv4マップアドレスを持つIPv6パケットを送信する場合は、O、彼は攻撃の特定の種類のプロキシとしてノードを使用することができるかもしれません。たとえば、これは放送乗算とプロキシ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.
また、これらのような特別な場合には、一部の地域で展開恩恵を与えながら、コードの複雑さのかなりの量を必要とする（例えば、結合の実装で（）システムコールと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マップIPv6の異なる機構を使用して埋め込まれたIPv4アドレスを通信するためのアドレス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の動作を使用すると、アドレスベースのアクセスコントロールに追加の複雑さを加えることで、いくつかのセキュリティへの影響を持っています。生じる主な問題は、IPv6（AF_INET6）ソケットは、ノードが開いて何のIPv4（AF_INET）ソケットを持っていない場合でも、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のの主要な設計目標の一つは、エンドツーエンドの透明性の元の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アドレスの不足に起因する、IPv4ネットワークに翻訳器（NAT）のアドレス導入の必要性は、ほとんどの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.
このようなネットワーク管理者がホストに配置することができる信頼のレベルを増加させる「トラステッド・コンピューティング」[TCGARCH]などのメカニズムのO開発。
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は、セキュリティチェックを回避するために使用することができ、トンネルがされていません不適切なトラフィックを運ぶために使用されます。 6to4の遷移トンネリングメカニズムについて主にある[RFC3964]は、（セクション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].
このようなセキュリティ上の問題を詳細に分析された一つの場合は、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]の場合におけるIPv4パケットまたはTeredoの[RFC4380]の場合にはIPv4 UDPパケットに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,
すべてのネイティブのIPv6ノードO、
o native IPv6 sites,
OネイティブIPv6サイト、
o in IPv6-enabled ISPs, or
IPv6対応のISPで、O、または
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]はTeredoのへの脅威とそれらに対抗するための措置の広範な議論が組み込まれています。
3.3. Tunneling IPv6 through IPv4 Networks May Break IPv4 Network Security Assumptions
3.3. IPv4ネットワーク経由トンネリングIPv6は、IPv4のネットワークセキュリティ前提条件を破損する可能性が
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.
トンネリングの添加は、このような展開が強制しようとしているセキュリティモデルを変更することができます。プロトコル41を使用したIPv6オーバーIPv4トンネリングは、典型的には、明示的に許可され、または暗黙的に拒否されます。 UDPは、通常のNATやファイアウォールを通過させなければならないようにUDPにカプセル化されたIPv4上トンネリングIPv6は、より困難な問題となります。結果として、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.
一つの可能なビューは、トンネリングを使用すると、ネットワーク管理の専門知識のレベルは、典型的には非常に高いものではない家庭やSOHO（スモールオフィス/ホームオフィス）環境では特に疑問があるということです。これらの環境では、ホストがしっかりとして可能なセキュリティブレークインや他の脆弱性につながる、（例えば、ネットワークサービスが不必要に有効かもしれない）他の人のように管理することはできません。
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.
IPv4のNATで提供されるのと同様のことで、デフォルトのセキュリティポリシーを生成するファイアウォールがある場合を除き例えば、NATトラバーサルがデフォルトで実行されるべきではありません。必要に応じて遮断することが容易であるようにIPv6の型の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.
ネットワークアーキテクチャを図1に示すように、トンネリングIPv6トラフィックをデカプセル化される前のIPv4ファイアウォールを介してルーティングされたIPv4パケットにカプセル化し、次に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フィルタリングルールを実装するために必要な機能の完全な範囲を提供することはできません。ネットワーク管理者は、多くの場合、サポートし、また、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ネットワークの適切な管理のための推奨事項は、欧州連合（EU）6netプロジェクト[SIXNET]の文書のアーカイブで、日本[JpIPv6DC]のIPv6普及・高度化推進協議会が公表展開ガイドに記載されています。
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アドレスのunmemorabilityの、それらを手動で設定する際のポイントツーポイントリンク上で起こるかもしれないとして、または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アドレスを入力するときに、数値のIPv6アドレスは、それらの長さとunmemorabilityにはIPv4よりヒューマンエラーになりやすいですので、適切に大きなアドレス空間を利用するために、管理者は、非常に注意しなければなりません。
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.
ルータは通常の重要なキャッシュが含まれていますように、ルータの管理インターフェイスは、（リモートアクセスのみのSecure Shell（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の一つのポジティブな結果は、グローバルなアクセスを必要としないノードは、ユニークローカルアドレス（ULA）を使用して、サイト全体（非常にローカルアクセスが十分であれば）だけでリンクローカルアドレスを使用することにより、ローカル通信したりできるということです。いずれの場合も、（リンク地元の人々のためにデフォルトでなければなりません）簡単なフィルタによって制御することができるアクティビティの割り当てられたドメイン外のアクセスを確保することは容易です。しかし、一般的な目的のためにリンクローカルアドレスを使用して、セキュリティの危険性は、2.1.12項に記載されているように、心に留めておくべきです。
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種以上が同時にアクティブであってもよい）、または異なるプレフィックスから（のための管理目的のためのノード）が同じリンク上の複数のサブネットに属するか、またはエニーキャストサービスを実施している場合、ネットワークは、マルチホーム例えば、。これらすべてのケースでは、単一のホストが異なるプレフィックスおよび/または異なるインタフェース識別子と、いくつかの異なるアドレスを使用している可能性があります。セキュリティ管理者が同じホストはすべてのこれらのアドレスの後ろにあることを識別することができることが望ましいです。
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.
プライバシーのメカニズムがあるため、アクセス制御リストを維持し、トラフィックの発信元を知ることに、現在の困難のため望ましくないことが彼らのネットワークで使用されている場合、一部のネットワーク管理者はアドレスの可変性を見つけることができます。フルステートフル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は、IPv4の一般的に利用できないように可能なエンド・ツー・エンドの通信を確保するためのIPsecの使用を作り、すべての適合ノードの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.
このような問題の一例は、有効なコンテンツフィルタリング、予想されるTCPプロトコルの動作に基づいて、DoS攻撃の防止を提供する能力、および侵入検知などミドルにおけるセキュリティソリューションの欠如です。この問題への今後の解決策は、セクション2.3.2で説明されています。別の例では、ソフトウェアベースのIPsec実装に特に有害であり得る（奇形ESP / AHパケットを送信例えば、）IPsecベースのDoSあります。
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構成は安全ではありません。あなたが設定で唯一の少数のホストにはIPv4のTelnetを制限している場合たとえば、あるベンダーの実装では、あなたが以前に使用したコンフィギュレーションコマンドは、そのIPv6をのIPv6 Telnetをブロックしないこと、のIPv6 Telnetが自動的に有効にされることを認識する必要があります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つのルーティングプロトコルでそれらの両方を実行するか、または二つの別々のルーティングプロトコルを有することが可能です。いずれのアプローチは、そのトレードオフ[RFC4029]を持っています。より簡単にわずかに遅い収束時間を引き起こし、ルータのCPUが過負荷状態にあります - 複数のルーティングプロトコルを使用する場合は、一つは、これはフラップまたは再計算をリンクする際にそれ以外に必要とされる処理の重量を引き起こすことに注意してください。
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の形式が標準化されている場合は、SENDはこの機能をサポートするように拡張する必要があります。
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.
このメモは、それらがIPv4-およびIPv6ベースの通信が共存する必要があるネットワークへの移行に関連し、特にとして、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ワーキンググループにセキュリティ関連の文書に貢献してきた多くの人々の仕事を一緒に描画します。アラン・デュラン、アランボドー、リュックBeloeilの、シャロン・チザム、ティムのchown、ラースEggertの、アンドラーシュキシュ・サボー、Vishwas Manral、ヤーノシュMohacsi、マーク・スミス、アルバロビベス、マーガレットワッセルマンは、このドキュメントを改善するためのフィードバックを提供します。聡近藤、伸介鈴木、そしてアルバロビベスは一緒ジョルディPalet、ブライアン・カーペンター、そしてピーターBieringerからの入力で、日本のIPv6普及・高度化推進協議会の展開作業部会と協力し、Euro6IX IST共同出資プロジェクトに追加の入力を提供します。マイケルWittsendとマイケル・コールは、プロービング/マッピングやプライバシーに関する問題を議論しました。萩野いとぢゅんクレイグメスおよびJun-一郎は、ワイヤ上でIPv4マッピングされたIPv6アドレスを使用することの問題を特定するオリジナル作業を行いました。 Vishwas Manralは、IPv6のセキュリティ上の小さな破片の影響のさらなる調査を行いました。フランシス・デュポンは、IPv6プライバシーアドレスに関連する問題を提起しました。最後に、ペッカSavolaは、この作品に包含されている側面のIPv6セキュリティ上のドキュメントの数を書きました。 「IPv6のファイアーウォールの考慮事項」（2003年10月）の彼の文書は、もともとここに文書化されているベースのIPv6仕様の問題の多くを同定しました。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、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.デアリング、 "IPv6のマルチキャストアドレスの割り当て"、RFC 2375、1998年7月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、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.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "IPv6のためのマルチキャストリスナー発見（MLD）"、RFC 2710、1999年10月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、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.
"IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）" [RFC3810]ヴィーダ、R.とL.コスタ、RFC 3810、2004年6月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964] Savola、P.とC.パテル、 "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]デアリング、S.、ハーバーマン、B.、神明、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.デアリング、 "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：ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器（NAT）"、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]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン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.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、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ホストをカウントするための技術"、PROC。第二に、インターネット測定ワークショップ、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]電気電子技術者協会、「ポートベースのネットワークアクセスコントロール」、地方のIEEE Standardとメトロポリタンエリアネットワーク802.1X-2004、2004年12月。
[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.、リード、D.、およびP. Trainaの、 "IPフラグメントフィルタリングのためのセキュリティの考慮事項"、RFC 1858、1995年10月。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765] Nordmarkと、E.、 "ステートレス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]、RFC 3128、2001年6月・ミラー、I.、 "タイニーフラグメント攻撃（RFC 1858）のバリアントに対する保護"。
[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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、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]ギリガン、R.、トムソン、S.、バウンド、J.、マッキャン、J.、およびW.スティーブンス、 "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.、ケンプ、J.、およびE. Nordmarkと、 "IPv6近隣探索（ND）信頼モデルと脅威"、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.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（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]リンド、M.、Ksinant、V.、公園、S.、ボドー、A.、およびP. Savola、 "ISPネットワークにIPv6を導入するためのシナリオと分析"、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]シン、M-K。、香港、Y-G。、萩野、J.、Savola、P.、およびE.カストロ、 "IPv6移行のアプリケーション側面"、RFC 4038、2005年3月。
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
[RFC4074]森下、Y.とT.神明、 "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.ターラー、 "デフォルトルータの設定と、より詳細なルート"、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.、オーラ、T.、モンテネグロ、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]ケント、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.ターラー、 "IPv6ホストツールーター負荷分散"、RFC 4311、2005年11月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389]ターラー、D.、Talwar、M.、およびC.パテル、 "近隣探索プロキシ（NDプロキシ）"、RFC 4389、2006年4月。
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, April 2006.
[RFC4472]デュラン、A.、Ihren、J.、およびP. Savola、RFC 4472 "IPv6のDNSで運用考慮事項と課題"、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]ヴァン・デ・ヴェルデ、G.、ハイン、T.、Droms、R.、大工、B.、およびE.クライン、 "IPv6のローカルネットワークの保護"、RFC 4864、2007年5月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890]デイヴィス、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]アウン、C.およびE.デイヴィス、RFC 4966、2007年7月、 "歴史的な状態にNAT-PTを移動する理由"。
[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/>.
[SIXNET] 6Net、 "大規模な国際IPv6のパイロット・ネットワーク"、EU情報社会技術プロジェクト、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.クルス、 "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アドレスのデザインを制約する望んでいない、アドレス計画に柔軟性を与えるとしてIPv6を見るのに対し、できるだけ正確IPv4のに合わせて、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.
攻撃者はノードのIPv4アドレスを知っているし、それがIPv4とIPv6のデュアルスタックであることを信じている場合は、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].
一方、アドレスのブルートフォーススキャンまたはプローブが原因（識別子が選択される方法に応じて多種多少未満で64ビット）が最もIPv6のサブネット上のインタフェース識別子の大きいサーチスペースに計算上実行不可能であり、常に識別子であることを条件とします[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の場合）が可能です。 V4ADDR :: 1：2002に古いLinuxとFreeBSDの実装のデフォルトながらV4ADDR :: V4ADDR：例えば、マイクロソフトの6to4実装は、アドレス2002を使用しています。これはまた、実装を識別し、したがって、任意の特定の弱点を標的とする一つの方法として使用することができます。
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.
一つの提案は、6to4ルーターのアドレスにアドレスやサブネット識別子をランダム化することでした。これは本当に（ホストまたはルータがいるかどうか）IPアドレスを明らかにし、ICMPv6のホップ制限超過メッセージを返します6to4ルーターとして、助けにはなりません。 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の場合よりも小さい適切である場合、これは重要な意味を持っています。
Appendix B. IPv6 Privacy Considerations
付録B. IPv6のプライバシーに関する注意事項
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]で見つけることができます。
B.1. Exposing MAC Addresses
B.1。 MACアドレスを公開
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.
ネットワークカードのモデルを公開EUI64に組み込まれているMACアドレスにステートレスアドレス自動設定の結果を使用します。懸念は、泥棒が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）のプライベート顧客データベースからの情報で可能となり、いくつかの物理アドレス情報は、インターネットレジストリのWHOISデータベースから入手できるかもしれないが、サイトの管理記録、。
B.2. Exposing Multiple Devices
B.2。複数のデバイスを公開
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].
放映されたもう一つの懸念は、コンピュータやネットワークに接続された他の多数のデバイスの存在を隠すしたいユーザーを必要とします。 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.
一部の管理者は、これが望ましいかもしれない理由の一つの実用的な理由は、特定の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]の十分に頻繁に再利用によって隠される可能性が - であれば、短い期間の間に、ある、生成されたアドレスの数十が使用中であるように見える、それは彼らかどうかを推定することは困難ですただ一つのホストまたは複数のホストによって生成されます。
B.3. Exposing the Site by a Stable Prefix
B.3。安定した接頭辞でサイトを公開
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接続を提供する場合、その代表者の固定グローバルルーティングプレフィクス（通常/ 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
エルウィンB.デイヴィスコンサルタントソーハム、Cambsの英国
Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com
電話：+44 7889 488 335 Eメール：elwynd@dial.pipex.com
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC H4P 2N2 Canada
スレシュクリシュナンエリクソン8400 Decarie大通りマウントロイヤル、QC H4P 2N2カナダの町
Phone: +1 514-345-7900 EMail: suresh.krishnan@ericsson.com
電話：+1 514-345-7900電子メール：suresh.krishnan@ericsson.com
Pekka Savola CSC/Funet
ペッカSavola CSC / Funet
EMail: psavola@funet.fi
メールアドレス：psavola@funet.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。