Network Working Group P. Savola
Request for Comments: 3964 CSC/FUNET
Category: Informational C. Patel
All Play, No Work
December 2004
Security Considerations for 6to4
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems.
IPv6の暫定機構の6to4（RFC3056）は、IPv6ネットワークを相互接続するために、自動のIPv6オーバーIPv4トンネリングを使用します。アーキテクチャは、受け入れ、IPv4インターネット内の任意のノードからIPv4プロトコル-41（「IPv6の型のIPv4」）トラフィックをデカプセル化の6to4ルータとの6to4リレールータを含みます。この特性は、セキュリティ上の脅威、サービスの主拒否の数を可能にします。また、ノードがIPv6アドレスを偽装することが容易になります。この文書では、より詳細にこれらの問題を議論し、問題を軽減するための機能強化を示唆しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . . 4
2.1. From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . . 4
2.2. From Native to 6to4 . . . . . . . . . . . . . . . . . . 5
2.3. From 6to4 to Native . . . . . . . . . . . . . . . . . . 5
2.4. Other Models . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. BGP between 6to4 Routers and Relays . . . . . . 6
2.4.2. 6to4 as an Optimization Method . . . . . . . . . 7
2.4.3. 6to4 as Tunnel End-Point Addressing Mechanism . . 8
3. Functionalities of 6to4 Network Components . . . . . . . . . . 9
3.1. 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . 9
3.2. 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . 10
4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Attacks on 6to4 Networks . . . . . . . . . . . . . . . . 12
4.1.1. Attacks with ND Messages . . . . . . . . . . . . 13
4.1.2. Spoofing Traffic to 6to4 Nodes . . . . . . . . . 14
4.1.3. Reflecting Traffic to 6to4 Nodes . . . . . . . . 17
4.1.4. Local IPv4 Broadcast Attack . . . . . . . . . . 19
4.2. Attacks on Native IPv6 Internet . . . . . . . . . . . . 20
4.2.1. Attacks with ND Messages . . . . . . . . . . . . 21
4.2.2. Spoofing Traffic to Native IPv6 Nodes. . . . . . 21
4.2.3. Reflecting Traffic to Native IPv6 Nodes . . . . 23
4.2.4. Local IPv4 Broadcast Attack . . . . . . . . . . 24
4.2.5. Theft of Service . . . . . . . . . . . . . . . . 25
4.2.6. Relay Operators Seen as Source of Abuse . . . . 26
4.3. Attacks on IPv4 Internet . . . . . . . . . . . . . . . . 28
4.4. Summary of the Attacks . . . . . . . . . . . . . . . . . 28
5. Implementing Proper Security Checks in 6to4 . . . . . . . . . 30
5.1. Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . 31
5.2. Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . 31
5.3. IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . 32
5.3.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . 32
5.3.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . 33
5.3.3. Optional Ingress Filtering . . . . . . . . . . . 33
5.3.4. Notes about the Checks . . . . . . . . . . . . . 33
6. Issues in 6to4 Implementation and Use . . . . . . . . . . . . 34
6.1. Implementation Considerations with Automatic Tunnels . . 34
6.2. A Different Model for 6to4 Deployment . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 41
The IPv6 interim mechanism "6to4" [1] specifies automatic IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds by embedding the tunnel IPv4 address in the IPv6 6to4 prefix.
IPv6の暫定機構「の6to4」[1]のIPv6プレフィックスの6to4トンネルIPv4アドレスを埋め込むことによって単離されたIPv6雲を相互接続するために、自動のIPv6オーバーIPv4トンネリングを指定します。
Two characteristics of the 6to4 mechanism introduce most of the security considerations:
6to4の機構の二つの特徴は、セキュリティ上の考慮事項のほとんどをご紹介します：
1. All 6to4 routers must accept and decapsulate IPv4 packets from every other 6to4 router, and from 6to4 relays.
1.すべての6to4ルーターは、他のすべての6to4ルーターから、と6to4リレーからIPv4パケットを受け入れ、デカプセル化しなければなりません。
As the 6to4 router must accept traffic from any other 6to4 router or relay, a certain requirement for trust is implied, and there are no strict constraints on what the IPv6 packet may contain. Thus, addresses within the IPv4 and IPv6 headers may be spoofed, and this leads to various types of threats, including different flavors of Denial of Service attacks.
6to4ルーターは、他の6to4ルーターまたはリレーからのトラフィックを受け入れなければならないとして、信頼のための一定の要件が暗示され、IPv6パケットが含まれているかもしれないものには厳しい制約がありません。このように、IPv4およびIPv6ヘッダ内のアドレスを詐称することができ、これは、サービス妨害攻撃の異なる味など、脅威の様々な種類につながります。
The 6to4 specification outlined a few security considerations and rules but was ambiguous as to their exact requirement level. Moreover, the description of the considerations was rather short, and some of them have proven difficult to understand or impossible to implement.
6to4の仕様では、いくつかのセキュリティ上の考慮事項と規則を概説が、その正確な要求レベルに曖昧なでした。また、注意事項の説明はかなり短いものだった、そのうちのいくつかは、実装が理解することは困難または不可能であることが判明しました。
This document analyzes the 6to4 security issues in more detail and outlines some enhancements and caveats.
この文書では、より詳細に6to4のセキュリティ上の問題を分析し、いくつかの機能強化および注意事項の概要を説明します。
Sections 2 and 3 are more or less introductory, rehashing how 6to4 is used today based on the 6to4 specification, so that it is easier to understand how security could be affected. Section 4 provides a threat analysis for implementations that already implement most of the security checks. Section 5 describes the optimal decapsulation/encapsulation rules for 6to4 implementations, and Section 6 provides further discussion on a few issues that have proven difficult to implement. Appendix A outlines a few possible trivial attack scenarios in which very little or no security has been implemented.
セキュリティが影響を受ける可能性があるかを理解しやすくなるように、第2条及び3は、6to4の仕様に基づいて、現在使用されているどのように6to4の焼き直し、多かれ少なかれ入門です。第4章では、既にセキュリティチェックのほとんどを実装する実装のための脅威分析を提供します。第5節では、6to4の実装に最適なカプセル化解除/カプセル化ルールを説明し、そして第6節では実施が困難であることが証明されたいくつかの問題についてさらなる議論を提供します。付録Aは、非常にほとんど、あるいはまったくセキュリティが実装されたいくつかの可能な些細な攻撃シナリオの概要を説明します。
For the sake of simplicity, in this document, the native Internet is assumed to encompass IPv6 networks formed by using other transition mechanisms (e.g., RFC 2893 [4]), as these mechanisms cannot talk directly to the 6to4 network.
簡略化のため、この文書では、ネイティブインターネットを他の遷移機構を用いて形成されたIPv6ネットワークを包含するものとする（例えば、RFC 2893 [4]）、これらのメカニズムは、6to4ネットワークに直接話すことができないように。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[2]。
Throughout this memo, IPv4 addresses from blocks 7.0.0.0/24, 8.0.0.0/24, and 9.0.0.0/24 are used for demonstrative purposes, to represent global IPv4 addresses that have no relation to each other. This approach was chosen instead of just using addresses from 192.0.2.0/24 [5] for two reasons: to use addresses whose 6to4 mapping is glaringly obvious, and to make it obvious that the IPv4 addresses of different 6to4 gateways need not have any relation to each other.
このメモを通じて、IPv4がブロック7.0.0.0/24、8.0.0.0/24からアドレス、9.0.0.0/24は互いに関係のないグローバルIPv4アドレスを表すために、例証目的のために使用されます。その6to4のマッピング紛れも明らかであるアドレスを使用して、異なるの6to4ゲートウェイのIPv4アドレスは、任意の関係を有する必要はないということが明白にするために：このアプローチでは、[5]二つの理由192.0.2.0/24からちょうど使用してアドレスの代わりに選ばれましたお互いに。
Note that when one communicates between 6to4 and native domains, the 6to4 relays that will be used in the two directions are very likely different; routing is highly asymmetric. Because of this, it is not feasible to limit relays from which 6to4 routers may accept traffic.
1は6to4のとネイティブドメイン間で通信する場合、二つの方向で使用されるの6to4リレーは非常に可能性が異なっていることに注意してください。ルーティングは非常に非対称です。このため、は、6to4ルータがトラフィックを受け入れる可能性があるからリレーを制限することは不可能です。
The first three subsections introduce the most common forms of 6to4 operation. Other models are presented in the fourth subsection.
最初の3つのサブセクションは、6to4操作の最も一般的な形態をご紹介します。他のモデルは、第四項に提示されています。
6to4 domains always exchange 6to4 traffic directly via IPv4 tunneling; the endpoint address V4ADDR is derived from 6to4 prefix 2002:V4ADDR::/48 of the destination.
6to4のドメインは、常にIPv4トンネリングを経由して直接の6to4トラフィックを交換します。 V4ADDR先の:: / 48：エンドポイントアドレスV4ADDRは6to4の接頭辞2002に由来しています。
.--------. _----_ .--------.
| 6to4 | _( IPv4 )_ | 6to4 |
| router | <====> ( Internet ) <===> | router |
'--------' (_ _) '--------'
^ '----' ^
| Direct tunneling over IPv4 |
V V
.--------. .-------.
| 6to4 | | 6to4 |
| host | | host |
'--------' '--------'
Figure 1
図1
It is required that every 6to4 router consider every other 6to4 router it wants to talk to be "on-link" (with IPv4 as the link-layer).
すべての6to4ルーターは、それが（リンク層としてはIPv4で）「オンリンク」であることを話したいすべての他の6to4ルーターを検討することが必要とされます。
When native domains send traffic to 6to4 prefix 2002:V4ADDR::/48, it will be routed to the topologically nearest advertising 6to4 relay (advertising route to 2002::/16). The 6to4 relay will tunnel the traffic over IPv4 to the corresponding IPv4 address V4ADDR.
ネイティブドメインを6to4プレフィックス2002にトラフィックを送信する場合：V4ADDR :: / 48、それは（2002 :: / 16に広告ルート）位相幾何学的に最も近い広告6to4リレーにルーティングされます。 6to4リレーは、対応のIPv4アドレスV4ADDRへのIPv4上のトンネルトラフィックをします。
Note that IPv4 address 9.0.0.1 here is just an example of a global IPv4 address, and it is assigned to the 6to4 router's pseudo-interface.
ここでは、IPv4アドレス9.0.0.1は、グローバルIPv4アドレスの一例であり、そしてそれは、6to4ルーターの疑似インターフェイスに割り当てられていることに注意してください。
Closest to
"Native IPv6 node"
.--------. _----_ .------------. .--------.
| Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 |
| IPv6 | -> ( Internet ) --> | router | =========> | router |
| node | (_ _) '------------' 9.0.0.1 '--------'
'--------' '----' dst_v6=2002:0900:0001::1 |
V
.-------.
| 6to4 |
| host |
'--------'
Figure 2
図2
6to4 domains send traffic to native domains by tunneling it over IPv4 to their configured 6to4 relay router, or the closest one found by using 6to4 IPv4 Anycast [3]. The relay will decapsulate the packet and forward it to native IPv6 Internet, as would any other IPv6 packet.
6to4のドメインは、それらの構成6to4リレールータ、又は[3]の6to4 IPv4のエニーキャストを使用して見つかった最も近いものへのIPv4の上にトンネリングすることによってネイティブドメインにトラフィックを送信します。リレーは、パケットをデカプセル化して、他のIPv6パケットと同じように、ネイティブIPv6インターネットに転送されます。
Note that the destination IPv6 address in the packet is a non-6to4 address and is assumed to be 2001:db8::1 in the example.
DB8 :: 1の例では：パケットの宛先IPv6アドレスが非6to4アドレスであると2001年であると仮定されることに留意されたいです。
Configured
-or-
found by IPv4 Anycast
.--------. _----_ .------------. .--------.
| Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 |
| Client | <- ( Internet ) <-- | router | <========= | router |
'--------' (_ _) '------------' 192.88.99.1'--------'
2001:db8::1 '----' (or configured) ^
|
.-------.
| 6to4 |
| client |
'--------'
Figure 3
図3
These are more or less special cases of 6to4 operations. In later chapters, unless otherwise stated, only the most generally used models (above) will be considered.
これらは、6to4操作の多かれ少なかれ特殊なケースです。後の章では、特に断らない限り、唯一の最も一般的に使用されるモデルは、（上記の）考えます。
Section 5.2.2.2 in [1] presents a model where, instead of static configuration, BGP [6] is used between 6to4 relay routers and 6to4 routers (for outgoing relay selection only).
[1]のセクション5.2.2.2ではなく、静的な構成で、[6] BGPは、6to4リレールータと（発信中継選択のみ）の6to4ルータの間で使用され、モデルを提示します。
Going further than [1], if the 6to4 router established a BGP session between all the possible 6to4 relays and advertised its /48 prefix to them, the traffic from non-6to4 sites would always come from a "known" relay. Alternatively, the 6to4 relays might advertise the more specific 6to4 routes between 6to4 relays.
6to4ルーターは、すべての可能性の6to4リレー間のBGPセッションを確立し、それらにその/ 48のプレフィックスを広告している場合、[1]、非6to4サイトからのトラフィックは、常に「既知」のリレーから来るよりもさらに行きます。また、の6to4リレーは、6to4リレー間のより特定の6to4ルートをアドバタイズすることがあります。
Both of these approaches are obviously infeasible due to scalability issues.
これらのアプローチの両方が明らかに起因するスケーラビリティの問題に実行不可能です。
Neither of these models are known to be used at the time of writing; this is probably because parties that need 6to4 are not able to run BGP, and because setting up these sessions would be much more work for relay operators.
これらのモデルのどちらも、書き込み時に使用されることが知られています。 6to4のを必要とする当事者がBGPを実行することができませんので、これらのセッションを設定すると、リレー事業者のためのより多くの仕事になるので、これはおそらくです。
Some sites seem to use 6to4 as an IPv6 connectivity "optimization method"; that is, they also have non-6to4 addresses on their nodes and border routers but also employ 6to4 to reach 6to4 sites.
いくつかのサイトがIPv6接続「最適化法」としての6to4を使用するように見えます。つまり、彼らはまた、自分のノードと境界ルータ上の非の6to4アドレスを持っているだけでなく、6to4のサイトに到達するための6to4を採用します。
This is typically done to be able to reach 6to4 destinations by direct tunneling without using relays at all.
これは、典型的にはすべてのリレーを使用せずに、直接トンネリングにより6to4の宛先に到達することができるようにするために行われます。
These sites also publish both 6to4 and non-6to4 addresses in DNS to affect inbound connections. If the source host's default address selection [7] works properly, 6to4 sources will use 6to4 addresses to reach the site and non-6to4 nodes use non-6to4 addresses. If this behavior of foreign nodes can be assumed, the security threats to such sites can be significantly simplified.
これらのサイトはまた、着信接続に影響を与えるためにDNSでの6to4と6to4以外の両方のアドレスを公開します。 [7]元ホストのデフォルトのアドレス選択が正常に動作する場合は、6to4のソースは、サイトと6to4以外のノードは非の6to4アドレスを使用到達するための6to4アドレスを使用します。外国のノードのこの動作が想定できる場合は、そのようなサイトへのセキュリティ脅威を大幅に簡略化することができます。
6to4 addresses can also be used only as an IPv6-in-IPv4 tunnel endpoint addressing and routing mechanism.
6to4のアドレスは、IPv6のみ型のIPv4トンネルエンドポイントアドレス指定およびルーティングメカニズムとしても使用することができます。
An example of this is interconnecting 10 branch offices where nodes use non-6to4 addresses. Only the offices' border routers need to be aware of 6to4, and use 6to4 addresses solely for addressing the tunnels between different branch offices. An example is provided in the figure below.
この例は、ノードが非6to4のアドレスを使用して10軒の支店を相互接続されています。オフィスは境界ルータは、6to4に注意する必要がある、ともっぱら異なる支店間のトンネルに対処するための6to4アドレスを使用します。例を以下の図に提供されます。
2001:db8:0:10::/60 2001:db8:0:20::/60
.--------. .--------.
( Branch 1 ) ( Branch 2 )
'--------' '--------'
| |
.--------. _----_ .--------.
| 6to4 | _( IPv4 )_ | 6to4 |
| router | <====> ( Internet ) <===> | router |
'--------' (_ _) '--------'
9.0.0.1 '----' 8.0.0.2
^^
||
vv
.--------.
| 6to4 | 7.0.0.3
| router |
'--------'
| 2001:db8::/48
.-----------.
( Main Office )
'-----------'
^
|
v
_----_
_( IPv6 )_
( Internet )
(_ _)
'----'
Figure 4
図4
In the figure, the main office sets up two routes:
図では、本社には二つの経路を設定します：
2001:db8:0:10::/60 -> 2002:0900:0001::1
2001：DB8：0：10 :: / 60 - > 2002：0900：0001 :: 1
2001:db8:0:20::/60 -> 2002:0800:0002::1
2001：DB8：0：20 :: / 60 - > 2002：0800：0002 :: 1
And a branch office sets up two routes as well:
そして、支社は、同様に二つの経路を設定します：
2001:db8:0:20::/60 -> 2002:0800:0002::1
2001：DB8：0：20 :: / 60 - > 2002：0800：0002 :: 1
default -> 2002:0700:0003::1
デフォルト - > 2002：0700：0003 :: 1
Thus, the IPv4 Internet is treated as an NBMA link-layer for interconnecting 6to4-enabled sites; with explicit routes, 6to4 addressing need not be used in routers other than the 6to4 edge routers. However, note that if a branch office sends a packet to any 6to4 destination, it will not go through the main office, as the 6to4 2002::/16 route overrides the default route.
したがって、IPv4インターネットは、6to4対応のサイトを相互接続するためのNBMAリンク層として扱われます。明示的なルートで、アドレッシングの6to4の6to4エッジルータ以外のルータで使用される必要はありません。しかし、ブランチオフィスはどんな6to4の宛先にパケットを送信する場合、それは6to4の2002 :: / 16ルートがデフォルトルートを上書きして、メインオフィスを通過しないことに注意してください。
This approach may make addressing and routing slightly easier in some circumstances.
このアプローチは、アドレッシングといくつかの状況では、わずかに簡単にルーティングすることがあります。
This section summarizes the main functionalities of the 6to4 network components (6to4 routers, and 6to4 relays) and the security checks they must do. The pseudo-code for the security checks is provided in Section 5.
このセクションでは、6to4ネットワークコンポーネント（の6to4ルーター、および6to4のリレー）と、彼らがしなければならないセキュリティチェックの主な機能をまとめたもの。セキュリティチェックのための擬似コードは、セクション5に設けられています。
This section summarizes the main functions of the various components of a 6to4 network: 6to4 relay routers and 6to4 routers. Refer to Section 1.1 of RFC 3056 [1] for 6to4-related definitions.
6to4リレールータとの6to4ルータ：このセクションでは、6to4ネットワークの様々な構成要素の主な機能をまとめたものです。 6to4の関連定義は、RFC 3056 [1]のセクション1.1を参照。
The 6to4 routers act as the border routers of a 6to4 domain. It does not have a native global IPv6 address except in certain special cases. Since the specification [1] uses the term "6to4 router", this memo does the same; however, note that in this definition, we also include a single host with a 6to4 pseudo-interface, which doesn't otherwise act as a router. The main functions of the 6to4 router are as follows:
6to4ルーターは、6to4ドメインの境界ルータとして動作します。それは、ある特別な場合を除き、ネイティブのグローバルIPv6アドレスを持っていません。 [1]仕様は、「6to4ルーター」の用語を用いているので、このメモは同じん。しかし、この定義では、我々はまた、それ以外のルータとして機能しない6to4擬似インタフェースを持つ単一のホストが含まれることに注意してください。次のように6to4ルーターの主な機能は以下のとおりです。
o Provide IPv6 connectivity to local clients and routers.
OローカルクライアントおよびルータにIPv6接続を提供します。
o Tunnel packets sent to foreign 6to4 addresses to the destination 6to4 router using IPv4.
Oトンネルパケットは、IPv4を使用して宛先の6to4ルーターに外国の6to4アドレスに送信されました。
o Forward packets sent to locally configured 6to4 addresses to the 6to4 network.
Oフォワードパケットは、6to4ネットワークにローカルに設定された6to4のアドレスに送信されました。
o Tunnel packets sent to non-6to4 addresses to the configured/ closest-by-anycast 6to4 relay router.
構成された/最も近いバイエニーキャスト6to4リレールータに非6to4のアドレスに送信されたOトンネルパケット。
o Decapsulate directly received IPv4 packets from foreign 6to4 addresses.
Oデカプセル化は、直接外国の6to4アドレスからIPv4パケットを受信しました。
o Decapsulate IPv4 packets received via the relay closest to the native IPv6 sources. Note that it is not easily distinguishable whether the packet was received from a 6to4 relay router or from a spoofing third party.
Oデカプセル化IPv4パケットは、ネイティブIPv6ソースに最も近いリレーを介して受信しました。パケットが6to4リレールータからまたはなりすまし第三者から受信されたかどうか、それは容易に区別はないことに注意してください。
The 6to4 router should also perform security checks on traffic that it receives from other 6to4 relays, or 6to4 routers, or from within the 6to4 site. These checks include the following:
6to4ルーターはまた、他の6to4リレー、またはの6to4ルーターから、または6to4サイト内から受信したトラフィックにセキュリティチェックを実行する必要があります。これらのチェックは、次のものがあります。
o Disallow traffic that has private, broadcast or certain specific reserved IPv4 addresses (see Section 5.3.1 for details) in tunnels, or the matching 6to4 prefixes.
O民間放送があり、トラフィックを禁止したり、特定の特定は、トンネル内でIPv4アドレス（詳細については、5.3.1項を参照）、または一致の6to4プレフィックスを禁じます。
o Disallow traffic from 6to4 routers in which the IPv4 tunnel source address does not match the 6to4 prefix. (Note that the pseudo-interface must pick the IPv4 address corresponding to the prefix when encapsulating, or problems may ensue, e.g., on multi-interface routers.)
O IPv4トンネルの送信元アドレスを6to4プレフィックスと一致しないでの6to4ルータからのトラフィックを許可しません。 （カプセル化するときに擬似インタフェースはプレフィックスに対応するIPv4アドレスを選択しなければならない、または問題がマルチインタフェースルータで、例えば、続いて起こることができることに留意されたいです。）
o Disallow traffic in which the destination IPv6 address is not a global address; in particular, link-local addresses, mapped addresses, and such should not be used.
O宛先IPv6アドレスがグローバルアドレスではないとしたトラフィックを許可しません。特に、リンクローカルアドレスに、アドレスをマッピングし、そのようなを使用すべきではありません。
o Disallow traffic transmission to other 6to4 domains through 6to4 relay router or via some third party 6to4 router. (To avoid transmission to the relay router, the pseudo-interface prefix length must be configured correctly to /16. Further, to avoid the traffic being discarded, 6to4 source addresses must always correspond to the IPv4 address encapsulating the traffic.)
O 6to4リレールータを介して、あるいはいくつかのサードパーティの6to4ルーターを介して他の6to4のドメインへのトラフィックの送信を許可しません。 （中継ルータへの送信を回避するために、擬似インタフェースプレフィックス長が/ 16に正しく設定されなければならない。また、廃棄されるトラフィックを回避するために、6to4のソースアドレスは常にトラフィックをカプセル化するIPv4アドレスに対応しなければなりません。）
o Discard traffic received from other 6to4 domains via a 6to4 relay router.
O破棄トラフィックが6to4リレールータを介して他の6to4ドメインから受信しました。
o Discard traffic received for prefixes other than one's own 6to4 prefix(es).
O破棄トラフィックが自分の6to4の接頭語（es）以外のプレフィックスのために受け取りました。
The 6to4 relay router acts as a relay between all 6to4 domains and native IPv6 networks; more specifically, it
すべての6to4ドメインとネイティブIPv6ネットワークとの間の中継として6to4リレールータ作用します。具体的には、それ
o advertises the reachability of the 2002::/16 prefix to native IPv6 routing, thus receiving traffic to all 6to4 addresses from the closest native IPv6 nodes,
Oは、このように最も近いネイティブのIPv6ノードからすべての6to4アドレスへのトラフィックを受信し、ネイティブのIPv6ルーティングに2002 :: / 16プレフィックスの到達可能性をアドバタイズし、
o advertises (if RFC 3068 [3] is implemented) the reachability of IPv4 "6to4 relay anycast prefix" (192.88.99.0/24) to IPv4 routing, thus receiving some tunneled traffic to native IPv6 nodes from 6to4 routers.
Oアドバタイズ（RFC 3068 [3]は実装されている場合）、IPv4ルーティングへのIPv4「の6to4リレーエニキャスト接頭辞」（192.88.99.0/24）の到達可能性、こうしての6to4ルータからネイティブIPv6ノードにいくつかのトンネルトラフィックを受信します。
o decapsulates and forwards packets received from 6to4 addresses through tunneling, by using normal IPv6 routing, and
Oデカプセル化転送パケットは、通常のIPv6ルーティングを使用することによって、トンネルを介しての6to4アドレスから受信し、及び
o tunnels packets received through normal IPv6 routing from native addresses that are destined for 2002::/16 to the corresponding 6to4 router.
Oトンネルパケットは、対応する6to4ルーター2002 :: / 16宛てのネイティブアドレスから通常のIPv6ルーティングを介して受信しました。
The 6to4 relay should also perform security checks on traffic that it receives from 6to4 routers, or from native IPv6 nodes. These checks are as follows:
6to4リレーはまた、6to4のルータから、またはネイティブのIPv6ノードから受信したトラフィックにセキュリティチェックを実行する必要があります。次のようにこれらのチェックは、以下のとおりです。
o Disallow traffic that has private, broadcast, or certain specific reserved IPv4 addresses in tunnels, or in the matching 6to4 prefixes.
Oプライベート、放送、またはある特定のは、トンネル内、または一致の6to4プレフィックスにIPv4アドレスを予約したトラフィックを許可しません。
o Disallow traffic from 6to4 routers in which the IPv4 tunnel source address does not match the 6to4 prefix. (Note that the pseudo-interface must pick the IPv4 address corresponding to the prefix when encapsulating, or problems may ensue, e.g., on multi-interface routers.)
O IPv4トンネルの送信元アドレスを6to4プレフィックスと一致しないでの6to4ルータからのトラフィックを許可しません。 （カプセル化するときに擬似インタフェースはプレフィックスに対応するIPv4アドレスを選択しなければならない、または問題がマルチインタフェースルータで、例えば、続いて起こることができることに留意されたいです。）
o Disallow traffic in which the destination IPv6 address is not a global address; in particular, link-local addresses, mapped addresses, and such should not be used.
O宛先IPv6アドレスがグローバルアドレスではないとしたトラフィックを許可しません。特に、リンクローカルアドレスに、アドレスをマッピングし、そのようなを使用すべきではありません。
o Discard traffic received from 6to4 routers with the destination as a 6to4 prefix.
O破棄トラフィックは、6to4プレフィックスとして先での6to4ルーターから受信しました。
This section discusses attacks against the 6to4 network or attacks
caused by the 6to4 network. The threats are discussed in light of
the 6to4 deployment models defined in Section 2.
There are three general types of threats:
脅威の3つの一般的なタイプがあります。
1. Denial-of-Service (DoS) attacks, in which a malicious node prevents communication between the node under attack and other nodes.
悪意のあるノードが攻撃、他のノードの下のノード間の通信を阻止する1サービス拒否（DoS）攻撃、。
2. Reflection Denial-of-Service (DoS) attacks, in which a malicious node reflects the traffic off unsuspecting nodes to a particular node (node under attack) in order to prevent communication between the node under attack and other nodes.
悪意のあるノードが攻撃、他のノードの下のノード間の通信を防止するために、特定のノード（攻撃下ノード）に疑いを持たないノードオフトラフィックを反映する2反射サービス拒否（DoS）攻撃、。
3. Service theft, in which a malicious node/site/operator may make unauthorized use of service.
悪意のあるノード/サイト/オペレータがサービスの不正使用を行うことのできる3.サービスの盗難、。
6to4 also provides a means for a "meta-threat", traffic laundering, in which some other attack is channeled through the third parties to make tracing the real origin of the attack more difficult. This is used in conjunction with other threats, whether specific to 6to4 or not.
6to4のもいくつかの他の攻撃がより困難な攻撃の本当の起源を追跡するために第三者に通された「メタ脅威」、交通ロンダリング、のための手段を提供します。これは、6to4のかいないのかどうか、特定のその他の脅威、と組み合わせて使用されています。
At this point it is important to reiterate that the attacks are possible because
この時点で、攻撃が原因で可能であることを改めて表明することは重要です
1. 6to4 routers have to consider all 6to4 relays, and other 6to4 routers, as "on-link",
1.の6to4ルーターは、「オンリンク」として、すべての6to4リレー、および他の6to4ルーターを考慮する必要があり、
3. it has been discovered that at least a couple of major 6to4 implementations do not implement all the security checks.
3.主要な6to4の実装の少なくともカップルは、すべてのセキュリティチェックを実装していないことが発見されました。
The attacks' descriptions are classified based on the target of the attack:
攻撃の記述は、攻撃の対象に基づいて分類されています。
Note that one of the mitigation methods listed for various attacks is based on the premise that 6to4 relays could have a feature limiting traffic to/from specific 6to4 sites. At the time of this writing, this feature is speculative, and more work needs to be done to determine the logistics.
様々な攻撃のためにリストされている緩和方法の一つは、6to4のリレーが/から特定の6to4サイトへのトラフィックを制限する機能を持つことができることを前提に基づいていることに注意してください。この記事の執筆時点では、この機能は投機的で、そしてより多くの仕事は、物流を決定するために行われる必要があります。
This section describes attacks against 6to4 networks. Attacks that leverage 6to4 networks, but for which the ultimate victim is elsewhere (e.g., a native IPv6 user, an IPv4 user), are described later in the memo.
このセクションでは、6to4ネットワークに対する攻撃について説明します。攻撃その活用の6to4ネットワークが、最終的な被害者が他の場所であるため（例えば、ネイティブIPv6ユーザのIPv4ユーザ）は、後でメモに記載されています。
6to4 relays and routers are IPv4 nodes, and there is no way for any 6to4 router to confirm the identity of the IPv4 node from which it receives traffic -- whether from a legitimate 6to4 relay or some other node. A 6to4 router has to process traffic from all IPv4 nodes. Malicious IPv4 nodes can exploit this property and attack nodes within the 6to4 network.
6to4リレールータは、IPv4ノードであり、それがトラフィックを受信し、そこからIPv4ノードの同一性を確認するために任意の6to4ルータの方法はありません - か正当な6to4リレーまたはいくつかの他のノードから。 6to4ルーターは、すべてのIPv4ノードからのトラフィックを処理しなければなりません。悪質なIPv4ノードは、6to4ネットワーク内でこのプロパティと攻撃ノードを利用することができます。
It is possible to conduct a variety of attacks on the 6to4 nodes. These attacks are as follows:
6to4ノード上のさまざまな攻撃を行うことが可能です。次のようにこれらの攻撃は、次のとおりです。
ATTACK DESCRIPTION
ATTACK説明
Since the 6to4 router assumes that all the other 6to4 routers and 6to4 relays are "on-link", it is possible to attack the 6to4 router by using ND messages from any node in the IPv4 network, unless a prior trust relationship has been established.
6to4ルーターは、他のすべてのの6to4ルーターと6to4リレーは、「オンリンク」であることを前提としていますので、前に信頼関係が確立されていない限り、IPv4ネットワーク内の任意のノードからのNDメッセージを使って、6to4ルーターを攻撃することが可能です。
The attacks target the 6to4 pseudo-interface. As long as the 6to4 addresses are not used in the source or destination address, the security checks specified by 6to4 take no stance on these packets. Typically they use link-local addresses.
攻撃は、6to4擬似インタフェースをターゲットにしています。限りの6to4アドレスが送信元または宛先アドレスに使用されていないとして、6to4ので指定されたセキュリティチェックは、これらのパケットにはスタンスを取りません。典型的には、それらは、リンクローカルアドレスを使用します。
For example, an attack could be a Route Advertisement or Neighbor Advertisement message crafted specifically to cause havoc; the addresses in such a packet could resemble to the following:
例えば、攻撃はルートの通知や混乱が発生するように特別に細工近隣広告メッセージである可能性があります。そのようなパケットのアドレスは次のように似ていることができます：
src_v6 = fe80::2 (forged address) dst_v6 = fe80::1 (valid or invalid address) src_v4 = 8.0.0.1 (valid or forged address) dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
src_v6 = FE80 :: 2（偽造アドレス）dst_v6 = FE80 :: 1（有効または無効なアドレス）src_v4 = 8.0.0.1（有効または偽造アドレス）dst_v4 = 9.0.0.2（有効なアドレスと一致dst_v6）
These attacks are exacerbated if the implementation supports more tunneling mechanisms than 6to4 (or configured tunneling) because it is impossible to disambiguate such mechanisms, making it difficult to enable strict security checks (see Section 6.1).
実装は6to4の（または設定さトンネリング）よりも多くのトンネリングメカニズムをサポートしている場合、そのようなメカニズムを明確にすることは不可能であるため、これらの攻撃は、それが困難な厳重なセキュリティチェックを（6.1節を参照）を有効にすること、さらに悪化しています。
The Neighbor Discovery threats (Redirect DoS, or DoS) are described in [8]. Note that all attacks may not be applicable, as the 6to4
近隣探索の脅威（リダイレクトDOS、またはDoS攻撃）は、[8]に記載されています。 6to4のように、すべての攻撃が適用されない場合があります
pseudo-interface is assumed not to have a link-layer address (Section 3.8 RFC 2893 [4]). However, note that the 6to4 router can be either a router or host from the Neighbor Discovery perspective.
擬似インタフェースがリンク層アドレスを持たないと仮定される（セクション3.8 RFC 2893 [4]）。しかし、6to4ルーターは、近隣探索の観点から、ルータまたはホストのいずれかであることに注意してください。
THREAT ANALYSIS AND MITIGATION METHODS
脅威分析と軽減方法
The attacks can be mitigated by using any of the following methods:
攻撃は、次のいずれかの方法を使用することによって軽減することができます。
o The usage of ND messages could be prohibited. This implies that all packets using addresses of scope link-local will be silently discarded. Section 3.1 of RFC 3056 [1] leaves scope for future uses of link-local address. This method has its pitfalls: It would prohibit any sort of ND message and thus close the doors on development and use of other ND options. Whether this is a significant problem is another thing.
O NDメッセージの使用を禁止することができます。これは、スコープのリンクローカルのアドレスを使用して、すべてのパケットが静かに捨てられることを意味します。 RFC 3056のセクション3.1には、[1]リンクローカルアドレスの将来の使用のためのスコープを残します。このメソッドは、その落とし穴があります：それはNDメッセージの任意の並べ替えを禁止するため、他のNDオプションの開発と使用上のドアを閉めます。これは重大な問題であるかどうかは別のものです。
o The 6to4 pseudo-interface could be insulated from the other interfaces, particularly the other tunnel interfaces (if any), for example by using a separate neighbor cache.
O 6to4擬似インタフェースは、別個の近隣キャッシュを使用することによって、例えば、（もしあれば）、他のインターフェイスから特に他のトンネルインターフェイスを絶縁することができます。
o If ND messages are needed, either IPsec [4] or an extension of SEND could be used [9] to secure packet exchange using the link-local address; vanilla SEND would not work, as the link-layer does not have an address -- and IPsec would be rather complex.
O NDメッセージが必要な場合、いずれかのIPsec [4]又はSENDの拡張は、リンクローカルアドレスを用いてパケット交換を確保する[9]に使用することができます。リンク層アドレスを持っていないようバニラSENDは、動作しないでしょう - とIPsecはかなり複雑になります。
COMPARISON TO SITUATION WITHOUT 6to4
6to4のWITHOUT状況を比較
Even though rather simply fixed, this attack is not new as such; the same is possible by using automatic tunneling [4] or configured tunneling (if one is able to spoof source IPv4 address to that of the tunnel end-point).
むしろ、単に固定にもかかわらず、この攻撃は、次のような新しいものではありません。同じことが、[4]または構成トンネリング（一方は、トンネルエンドポイントのものに送信元IPv4アドレスを偽装することが可能である場合）、自動トンネリングを使用することにより可能です。
However, as 6to4 provides open decapsulation, and automatic tunneling is being deprecated [10], 6to4 provides an easy means, which would not exist without it.
[10]の6to4が開いデカプセル化を提供し、自動トンネリングは廃止されているようしかし、6to4のは、それなしでは存在しない簡単な手段を提供します。
ATTACK DESCRIPTION
ATTACK説明
The attacker - a malicious IPv4 or IPv6 node - can send packets that are difficult to trace (e.g., due to spoofing or going through a relay) to a 6to4 node. This can be used e.g., to accomplish a DoS attack.
攻撃 - 悪意のあるIPv4またはIPv6ノードが - の6to4ノードに（によるなりすましやリレーを経由する、例えば）トレースすることが困難であるパケットを送信することができます。これは、DoS攻撃を達成するために、例えば使用することができます。
The IPv6 and IPv4 addresses of the packets will be similar to the following: src_v6 = 2001:db8::1 (forged address) dst_v6 = 2002:0900:0002::1 (valid address) src_v4 = 8.0.0.1 (valid or forged address) dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
パケットのIPv6とIPv4のアドレスは次のようになります。src_v6 = 2001：DB8 :: 1（偽造アドレス）dst_v6 = 2002：0900：0002 :: 1（有効なアドレス）src_v4 = 8.0.0.1（有効または鍛造アドレス）dst_v4 = 9.0.0.2（有効なアドレスは、dst_v6に一致します）
For attacks launched from a native IPv6 node, the src_v4 will be the address of the relay through which the traffic will reach the 6to4 node. From IPv4 nodes, src_v4 can be either a spoofed source address or the real one.
ネイティブのIPv6ノードから打ち上げ攻撃のために、src_v4は、トラフィックを6to4ノードに到達し、それを通してリレーのアドレスになります。 IPv4ノードから、src_v4は、スプーフィングされたソースアドレスまたは本物のいずれかであり得ます。
The 6to4 router receives these packets from 8.0.0.1, decapsulates them, discards the IPv4 header containing the source address 8.0.0.1, and processes them as normal (the attacker has guessed or obtained "dst_v6" by using one of a number of techniques).
6to4ルーターは、それらをデカプセル化ソースアドレス8.0.0.1を含むIPv4ヘッダを破棄し、8.0.0.1からこれらのパケットを受信し、（攻撃者は推測または多数の技術のいずれかを使用して「dst_v6」を取得している）は、通常のようにそれらを処理します。
This is a DoS attack on 6to4 nodes.
これは、6to4ノード上のDoS攻撃です。
This attack is similar to those shown in [11].
この攻撃は、[11]に示されるものと同様です。
EXTENSIONS
EXTENSIONS
Replies to the traffic will be directed to the src_v6 address, resulting in 6to4 nodes participating in a reflection DoS. This attack is described in more detail in Section 4.2.3. The replies (e.g., TCP SYN ACK, TCP RST, ICMPv6 Echo Reply, input sent to UDP echo service, ICMPv6 Destination Unreachable) are sent to the victim (src_v6), above. All the traces from the original attacker (src_v4) have been discarded. These return packets will go through a relay.
トラフィックへの応答は、反射DoS攻撃に参加した6to4ノードで、その結果、src_v6アドレスに向けられます。この攻撃は、4.2.3項で詳細に記載されています。応答（例えば、TCP SYN ACK、TCP RST、ICMPv6エコー応答、UDPエコーサービス、ICMPv6の宛先到達不能に送信された入力）は、上記、被害者（src_v6）に送られます。元アタッカー（src_v4）からのすべてのトレースは破棄されました。これらの戻りパケットは、リレーを通過します。
Certain 6to4 networks may have a trivial ACL (Access Control List) based firewall that allows traffic to pass through if it comes from particular source(s). Such a firewalling mechanism can be bypassed by address spoofing. This attack can therefore be used for trivial ACL avoidance as well. These attacks might be hampered because the replies from the 6to4 node to the spoofed address will be lost.
特定の6to4ネットワークは、それが特定のソース（S）から来る場合、トラフィックを通過させる些細なACL（アクセス制御リスト）ベースのファイアウォールを有することができます。このようなファイアウォール・メカニズムは、アドレススプーフィングによってバイパスすることができます。この攻撃は、そのためにも些細なACLの回避のために使用することができます。偽装されたアドレスへの6to4ノードからの応答が失われるので、これらの攻撃は妨げられている可能性があります。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
脅威分析とソリューション/緩和方法
The Denial-of-Service attack based on traffic spoofing is not new; the only twists come from the fact that traces of an attack are more easily lost, and that spoofing the IPv6 address is possible even to those who are unable to do so in their current networks. The 6to4 router typically does not log IPv4 addresses (as they would be treated as L2 addresses), and thus the source of the attack (if launched from an IPv4 node) is lost. Because traces to the src_v4 address are easily lost, these attacks can also be launched from IPv4 nodes whose connections are ingress-filtered.
トラフィックスプーフィングに基づいたサービス拒否攻撃は新しいものではありません。唯一のねじれは、攻撃の痕跡がより簡単に失われているという事実から来て、IPv6アドレスを偽装することも、彼らの現在のネットワークで行うことができない人に可能です。 6to4ルーターは、（それらがL2アドレスとして扱われるように）は、典型的にはIPv4アドレスをログに記録しないので、（IPv4ノードから起動する場合）、攻撃のソースが失われます。 src_v4アドレスへのトレースが簡単に失われているため、これらの攻撃はまた、その接続に進入フィルタリングされているIPv4ノードから起動することができます。
However, often this is not a real factor, as usually the attackers are just zombies and real attackers may not even care whether the unspoofed source address is discovered.
通常、攻撃者はただのゾンビであり、実際の攻撃がさえunspoofed送信元アドレスが発見されているかどうかを気にしないかもしれないしかし、多くの場合、これは、本当の要因ではありません。
Malicious native IPv6 nodes could be caught easily if ingress filtering was enabled everywhere in the IPv6 Internet.
イングレスフィルタリングがIPv6インターネットでどこでも有効になっていた場合、悪質なネイティブのIPv6ノードを簡単にキャッチすることができます。
These attacks are easy to perform, but the extent of harm is limited:
これらの攻撃は、実行するのは簡単ですが、被害の程度は限られています：
o For every packet sent, at most one reply packet is generated: there is no amplification factor.
送信されたすべてのパケットのためにO、最大1つの応答パケットが生成されます。何の増幅率はありません。
o Attack packets, if initiated from an IPv6 node, will pass through choke point(s), namely a 6to4 relay; in addition to physical limitations, these could implement some form of 6to4-site-specific traffic limiting.
IPv6ノードから開始された場合にO攻撃パケットは、チョークポイント（複数可）、すなわち6to4リレーを通過します。物理的な制限に加えて、これらは、6to4-サイト固有のトラフィックを制限するいくつかのフォームを実装することができます。
On the other hand, a variety of factors can make the attacks serious:
一方、様々な要因は、攻撃が深刻なことができます。
o The attacker may have the ability to choose the relay, and he might employ the ones best suited for the attacks. Also, many relays use 192.88.99.1 [3] as the source address, making tracing even more difficult (also see Section 4.2.6).
oを攻撃者がリレーを選択する能力を有していてもよく、そして、彼は攻撃のために最も適したものを採用するかもしれません。また、多くのリレーは（セクション4.2.6を参照）、さらに困難トレースすること、送信元アドレスとして[3] 192.88.99.1を使用します。
o The relay's IPv4 address may be used as a source address for these attacks, potentially causing a lot of complaints or other actions, as the relay might seem to be the source of the attack (see Section 4.2.6 for more).
リレーが攻撃（詳細については、セクション4.2.6を参照）のソースのように見えるかもしれないとして、OリレーのIPv4アドレスは、潜在的な苦情や他のアクションの多くを引き起こし、これらの攻撃の送信元アドレスとして使用することができます。
Some of the mitigation methods for such attacks are as follows:
次のような攻撃の緩和方法のいくつかは、次のとおりです。
1. Ingress filtering in the native IPv6 networks to prevent packets with spoofed IPv6 sources from being transmitted. This would, thus, make it easy to identify the source of the attack. Unfortunately, it would depend on significant (or even complete) ingress filtering everywhere in other networks; while this is highly desirable, it may not be feasible.
ネイティブIPv6ネットワークにおける1イングレスフィルタリングは、送信されてからのなりすましのIPv6ソースとパケットを防止します。これは、このように、それは簡単に攻撃の発信元を特定することになるだろう。残念ながら、それは他のネットワークでどこでも重要な（あるいは完全に）入力フィルタリングに依存するであろう。これは非常に望ましいが、それは実現可能ではないかもしれません。
2. Security checks in the 6to4 relay. The 6to4 relay must drop traffic (from the IPv6 Internet) that has 6to4 addresses as source address; see Section 5 for more detail. This has very little cost.
6to4リレー2.セキュリティチェック。 6to4リレーは、送信元アドレスとしての6to4アドレスを持っている（IPv6インターネットからの）トラフィックをドロップする必要があります。詳細については、セクション5を参照してください。これは非常に少ない費用を持っています。
However, these mitigation methods do not address the case of an IPv4 node sending encapsulated IPv6 packets.
しかしながら、これらの軽減方法は、カプセル化されたIPv6パケットを送信するIPv4ノードのケースに対処していません。
No simple way to prevent such attacks exists, and longer-term solutions, such as ingress filtering [12] or itrace [13], would have
そのようなイングレスフィルタリング[12]又はITRACEような攻撃が存在し、長期的な解決策を防止する簡単な方法[13]、持っていないであろう
to be deployed in both IPv6 and IPv4 networks to help identify the source of the attacks. A total penetration is likely impossible. (Note that itrace work has been discontinued, as of this writing in July 2004.)
攻撃の発生源を特定するために、IPv6とIPv4の両方のネットワークで展開されます。総浸透はおそらく不可能です。 （ITRACE作業は2004年7月にこれを書いている時点では、中止されていることに注意してください）
COMPARISON TO SITUATION WITHOUT 6to4
6to4のWITHOUT状況を比較
Traffic spoofing is not a new phenomenon in IPv4 or IPv6. 6to4 just makes it easier: Anyone can, regardless of ingress filtering, spoof a native IPv6 address to a 6to4 node, even if "maximal security" would be implemented and deployed. Losing trails is also easier.
トラフィックスプーフィングはIPv4またはIPv6の新しい現象ではありません。 「最大のセキュリティは、」実装され、展開されるだろう場合でも、誰でも、関係なく、イングレスフィルタリングの、6to4のノードへのネイティブIPv6アドレスを偽装することができます：6to4のちょうどそれが容易になります。トレイルを失うことも簡単です。
Therefore, depending on how much one assumes ingress filtering is deployed for IPv4 and IPv6, this could be considered either a very serious issue or close to irrelevant compared to the IP spoofing capabilities without 6to4.
したがって、1はイングレスフィルタリングがIPv4とIPv6のために配備されていると仮定し、どのくらいに応じて、これは、6to4のないIPスプーフィング能力に比べていずれかの非常に深刻な問題または無関係に近いと考えられます。
ATTACK DESCRIPTION
ATTACK説明
Spoofed traffic (as described in Section 4.2.2) may be sent to native IPv6 nodes to perform a reflection attack against 6to4 nodes.
スプーフィングされたトラフィック（セクション4.2.2で説明したように）の6to4ノードに対する反射攻撃を実行するためにネイティブのIPv6ノードに送信することができます。
The spoofed traffic is sent to a native IPv6 node, either from an IPv4 node (through a 6to4 relay) or from a native IPv6 node (unless ingress filtering has been deployed). With the former, the sent packets would resemble the following:
（イングレスフィルタリングが配備されていない限り）偽装トラフィックは、IPv4ノードから（6to4リレーを介して）、またはネイティブのIPv6ノードのいずれかから、ネイティブIPv6ノードに送信されます。元と、送信されたパケットは次のようになります。
src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node) dst_v6 = 2002:0900:0002::1 (valid address) src_v4 = 8.0.0.1 (valid or invalid address) dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
src_v6 = 2002：1234：1234 :: 1（ターゲットの6to4ノードの偽造アドレス）dst_v6 = 2002：0900：0002 :: 1（有効なアドレス）src_v4 = 8.0.0.1（有効または無効なアドレス）dst_v4 = 9.0.0.2（有効なアドレスは、）dst_v6一致しました
Note that an attack through the relay is prevented if the relay implements proper decapsulation security checks (see Section 5 for details) unless the IPv4 node can spoof the source address to match src_v6. Similarly, the attack from native IPv6 nodes could be prevented by global ingress filtering deployment.
IPv4ノードがsrc_v6と一致する送信元アドレスを偽装することができない限り、リレーは、適切なカプセル化解除セキュリティチェックを（詳細については、セクション5を参照）を実装している場合、リレーを介して攻撃が防止されることに留意されたいです。同様に、ネイティブIPv6ノードからの攻撃は、グローバルイングレスフィルタリングの導入により防止することができます。
These attacks can be initiated by native IPv6, IPv4, or 6to4 nodes.
これらの攻撃は、ネイティブのIPv6、IPv4の、またはの6to4ノードによって開始することができます。
EXTENSIONS
EXTENSIONS
A distributed Reflection DoS can be performed if a large number of nodes are involved in sending spoofed traffic with the same src_v6.
多数のノードが同じsrc_v6でスプーフィングされたトラフィックを送信することに関与している場合は分布反射DoS攻撃を行うことができます。
Malicious 6to4 nodes can also (try to) initiate this attack by bouncing traffic off 6to4 nodes in other 6to4 sites. However, this attack may not be possible, as the 6to4 router (in the site from which the attack is launched) will filter packets with forged source addresses (with security checks mentioned in Section 5).
悪意のあるの6to4ノードも（しよう）他の6to4サイト内の6to4ノードオフトラフィックをバウンスさせることによって、この攻撃を開始することができます。 （攻撃が開始され、そこからサイト内）6to4ルーターは、（第5節で述べたセキュリティチェックで）偽造送信元アドレスを持つパケットをフィルタリングしますしかし、この攻撃は、できない場合があります。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
脅威分析とソリューション/緩和方法
In this case, the reverse traffic comprises replies to the messages received by the 6to4 nodes. The attacker has less control on the packet type, and this would inhibit certain types of attacks. For example, flooding a 6to4 node with TCP SYN packets will not be possible (but e.g., a SYN-ACK or RST would be).
この場合、逆方向トラフィックは、6to4ノードによって受信されたメッセージへの返信を含みます。攻撃者は、パケットタイプにはあまりコントロールを持っており、これは、あるタイプの攻撃を阻害するであろう。例えば、TCP SYNパケットとの6to4ノードをフラッディングすることはできません（ただし、例えば、SYN-ACKまたはRSTがあろう）。
These attacks may be mitigated in various ways:
これらの攻撃は、さまざまな方法で軽減することができます。
o Implementation of ingress filtering by the IPv4 service providers. This would prevent forging of the src_v4 address and help in closing down on the culprit IPv4 nodes. Note that it will be difficult to shut down the attack if a large number of IPv4 nodes are involved.
IPv4サービスプロバイダによって入力フィルタリングのOの実装。これはsrc_v4アドレスの鍛造を防ぎ、犯人IPv4ノード上の閉鎖に役立つだろう。 IPv4ノードが多数含まれている場合、攻撃をシャットダウンすることは困難になることに注意してください。
These attacks may be also be stopped at the 6to4 sites if the culprit src_v4 address is identified, and if it is constant, by filtering traffic from this address. Note that it would be difficult to implement this method if appropriate logging were not done by the 6to4 router or if a large number of 6to4 nodes, and/or a large number of IPv4 nodes were participating in the attack.
犯人src_v4アドレスが識別された場合、これらの攻撃もの6to4サイトで停止することができる、そしてそれは、このアドレスからのトラフィックをフィルタリングすることにより、一定の場合。適切なログが6to4ルーターまたは6to4の多数のノードた場合に行われていなかった、および/またはIPv4ノードの大多数が攻撃に参加した場合には、このメソッドを実装することは困難であることに注意してください。
Unfortunately, because many IPv4 service providers don't implement ingress filtering, for whatever reasons, this may not be a satisfactory solution.
多くのIPv4サービスプロバイダがイングレスフィルタリングを実装していないので、残念ながら、どのような理由のために、これは満足のいく解決策ではないかもしれません。
o Implementation of ingress filtering by all IPv6 service providers would eliminate this attack, because src_v6 could not be spoofed as a 6to4 address. However, expecting this to happen may not be practical.
src_v6は6to4アドレスとして詐称することができませんでしたので、OすべてのIPv6サービスプロバイダによって入力フィルタリングの実装は、この攻撃を排除するであろう。しかし、これが起こることを期待することは現実的ではないかもしれません。
o Proper implementation of security checks (see Section 5) both at the 6to4 relays and routers would eliminate an attack launched from an IPv4 node, except when the IPv4 source address was also spoofed -- but then the attacker would have been able to attack the ultimate destination directly.
セキュリティチェックの適切な実装O（5節を参照）の両方の6to4リレールータのIPv4ソースアドレスも偽装された場合を除き、IPv4ノードから打ち上げ攻撃を排除するであろう - しかし、その後、攻撃者は攻撃することができただろう直接最終目的地。
o Rate limiting traffic at the 6to4 relays. In a scenario where most of the traffic is passing through few 6to4 relays, these relays can implement traffic rate-limiting features and rate-limit the traffic from 6to4 sites.
Oレートは、6to4リレーでトラフィックを制限します。トラフィックのほとんどが少数の6to4リレーを通過しているシナリオでは、これらのリレーは、トラフィックレート制限機能やレート制限6to4サイトからのトラフィックを実装することができます。
COMPARISON TO SITUATION WITHOUT 6to4
6to4のWITHOUT状況を比較
This particular attack can be mitigated by proper implementation of security checks (which is quite straightforward) and ingress filtering; when ingress filtering is not implemented, it is typically easier to attack directly than through reflection -- unless "traffic laundering" is an explicit goal of the attack. Therefore, this attack does not seem very serious.
この特定の攻撃は（非常に簡単である）セキュリティチェックの適切な実装とイングレスフィルタリングによって軽減することができます。イングレスフィルタリングが実装されていないとき、一般的に反射を通じてより直接的に攻撃する方が簡単です - 「交通ロンダリング」は攻撃の明確な目標である場合を除きます。したがって、この攻撃は非常に深刻ないないようです。
ATTACK DESCRIPTION
ATTACK説明
This threat is applicable if the 6to4 router does not check whether the IPv4 address to which it tries to send encapsulated IPv6 packets is a local broadcast address or a multicast address.
6to4ルーターは、それがカプセル化されたIPv6パケットを送信しようとするIPv4アドレスがローカルブロードキャストアドレスまたはマルチキャストアドレスであるかどうかをチェックしない場合は、この脅威は適用されます。
This threat is described in the specification [1], and implementing the checks eliminates this threat. However, as checks have not been widely implemented, the threat is included here for completeness.
この脅威は、[1]の明細書に記載し、検査を実施することは、この脅威を排除しています。チェックが広く実装されていないようしかし、脅威は完全を期すためにここに含まれています。
There practically two kinds of attacks: when a local 6to4 user tries to send packets to the address corresponding to the broadcast address, and when someone is able to do so remotely.
攻撃のあり、実質的に2種類：ローカルの6to4ユーザーは、ブロードキャストアドレスに対応するアドレスにパケットを送信しよう、と誰かがリモートでそれを行うことが可能であるとき。
In the first option, assume that 9.0.0.255 is the 6to4 router's broadcast address. After receiving the packet with a destination address like "2002:0900:00ff::bbbb" from a local 6to4 node, if the router doesn't check the destination address for subnet broadcast, it would send the encapsulated protocol-41 packet to 9.0.0.255. This would be received by all nodes in the subnet, and the responses would be directed to the 6to4 router.
最初のオプションでは、9.0.0.255は、6to4ルーターのブロードキャストアドレスであることを前提としています。 「：0900：2002 00FF :: BBBB」のような宛先アドレスを持つパケットを受信した後、ルータはサブネットブロードキャストの宛先アドレスをチェックしない場合は、ローカルの6to4ノードから、それが9.0にカプセル化されたプロトコル-41パケットを送信します.0.255。これは、サブネット内のすべてのノードによって受信されるだろう、と応答が6to4ルーターに向けられます。
Malicious sites may also embed forged 6to4 addresses in the DNS, use of which by a 6to4 node would result in a local broadcast by the 6to4 router. One way to perform this attack would be to send an HTML mail containing a link to an invalid URL (for example, http://[2002:0900:00ff::bbbb]/index.html) to all users in a 6to4 technology based network. Opening of the mail simultaneously would result in a broadcast storm.
悪質なサイトはまた、DNSに偽造の6to4アドレスを埋め込むこと、の6to4ノードによっての使用は、6to4ルーターによってローカル放送につながります。この攻撃を実行するための一つの方法は、6to4技術のすべてのユーザーに（例えば、http://[2002:0900:00ff::bbbb]/index.html）無効なURLへのリンクを含むHTMLメールを送信することであろうベースのネットワーク。メールのオープニングは、同時にブロードキャストストームをもたらすであろう。
The second kind of attack is more complex: The attack can be initiated by IPv4 nodes not belonging to the local network as long as they can send traffic with invalid (for example 2002:0900:00ff::bbbb) source address. The 6to4 router has to respond to the traffic by sending ICMPv6 packets back to the source, (e.g., Hop Limit Exceeded or Destination Unreachable). The packet would be as follows: src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router) dst_v6 = 2002:0800:0001::0001 (valid non-existent address)
攻撃の第二種は、より複雑です：攻撃がIPv4ので開始することができ、彼らが無効（例2002：0900：00FF :: BBBB）でトラフィックを送信することができます限り、ローカルネットワークに属していないするノードの送信元アドレス。 6to4ルーターは、元に戻すのICMPv6パケットを送信することにより、トラフィックに対応するために持っている、（例えば、ホップ制限を超過または宛先到達不能）。次のようにパケットは次のようになります。0800：：= 2002 src_v6 00FF :: BBBB（ルータのアドレスをブロードキャスト）dst_v6 = 2002：0800：0001を:: 0001（有効実在しないアドレス）
This is a DoS attack.
これは、DoS攻撃です。
EXTENSIONS
EXTENSIONS
The attacks could also be directed at non-local broadcast addresses, but these would be so-called "IPv4 directed broadcasts", which have (luckily enough) already been extensively blocked in the Internet.
攻撃はまた、非ローカルブロードキャストアドレスに向けられる可能性があり、これらは、いわゆるされるだろう、すでに広くインターネットでブロックされている、（幸いに）「IPv4がブロードキャストを向けます」。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
脅威分析とソリューション/緩和方法
The attack is based on the premise that the 6to4 router has to send a packet that embeds an invalid IPv4 address to an IPv6 address. Such an attack is easily thwarted by ensuring that the 6to4 router does not transmit packets to invalid IPv4 addresses. Specifically, traffic should not be sent to broadcast or multicast IPv4 addresses.
攻撃は6to4ルーターがIPv6アドレスに無効なIPv4アドレスを埋め込んで、パケットを送信する必要があることを前提としています。このような攻撃は簡単に6to4ルーターは、IPv4アドレスを無効なパケットを送信しないことを確実にすることによって阻止されます。具体的には、トラフィックは、ブロードキャストやマルチキャストのIPv4アドレスに送るべきではありません。
COMPARISON TO SITUATION WITHOUT 6to4
6to4のWITHOUT状況を比較
The first threat is similar to what is already possible with IPv4, but IPv6 does not have broadcast addresses.
最初の脅威はすでにIPv4の持つ可能性あるものに似ていますが、IPv6は、ブロードキャストアドレスを持っていません。
The second, a more complex threat, is, similarly, also available in IPv4.
第二の、より複雑な脅威は、IPv4のも、同様に、利用可能です。
In consequence, the security does not seem to be significantly worse than with IPv4, and even that is restricted to the site(s) with 6to4 implementations that haven't been secured as described in Section 5.
その結果、セキュリティは、IPv4と比べて大幅に悪化していないようだ、とさえそれは第5節で説明したように保護されていない6to4の実装とサイト（複数可）に制限されています。
This section describes attacks against native IPv6 Internet that somehow leverage 6to4 architecture. Attacks against 6to4 nodes were described in the previous section.
このセクションでは、何らかの形での6to4アーキテクチャを活用ネイティブIPv6インターネットへの攻撃について説明します。 6to4のノードに対する攻撃は、前のセクションで説明しました。
6to4 and IPv4 nodes can access native IPv6 nodes through the 6to4 relay routers. Thus, the 6to4 relays play a crucial role in any attack on native IPv6 nodes by IPv4 nodes or 6to4 nodes.
6to4とIPv4ノードは、6to4リレールータを介してネイティブIPv6ノードにアクセスすることができます。したがって、6to4のリレーは、IPv4ノードまたは6to4のノードによって、ネイティブのIPv6ノード上の任意の攻撃に重要な役割を果たしています。
6to4 relays have only one significant security check they must perform for general safety: When decapsulating IPv4 packets, they check that 2002:V4ADDR::/48 and V4ADDR match in the source address. If this is not done, several threats become more serious; in the following analysis, it is assumed that such checks are implemented.
6to4のリレーは、彼らは一般的な安全性のために実行しなければならない唯一の重要なセキュリティチェックがあります。送信元アドレスにV4ADDR :: / 48とV4ADDR試合：IPv4パケットをデカプセル化するとき、彼らは2002年をチェック。これを行わない場合、いくつかの脅威が深刻化。以下の分析では、そのようなチェックが実施されているものとします。
6to4 relay should not relay packets between 6to4 addresses. In particular, packets decapsulated from 6to4 routers should not be encapsulated toward 6to4 routers, as described in Section 5. Similarly, packets with 6to4 source and destination addresses sent from IPv6 nodes should not be relayed. It is not clear whether this kind of check is typically implemented. The attacks described below assume that such checks are not implemented.
6to4リレーは、6to4アドレス間のパケットを中継するべきではありません。同様に、IPv6ノードから送信された6to4送信元および宛先アドレスを持つパケットが中継されるべきでないセクション5に記載されているように、特に、6to4のルータからデカプセル化パケットは、6to4のルータに向けてカプセル化されるべきではありません。チェックのこの種は、一般的に実装されているかどうかは明らかではありません。以下の攻撃は、そのようなチェックが実装されていないことを前提としています。
These attacks are the same as those employed against 6to4 routers, as described in Section 4.1.1.
これらの攻撃は、セクション4.1.1で説明したように、6to4のルータに対して使用したものと同じです。
ATTACK DESCRIPTION
ATTACK説明
The attacker - a malicious IPv4 or 6to4 node - can send packets with a spoofed (or not spoofed) 6to4 source address to a native IPv6 node to accomplish a DoS attack.
攻撃 - 悪意のあるIPv4かの6to4ノードが - DoS攻撃を達成するために、ネイティブのIPv6ノードに偽装（またはしないなりすまし）の6to4ソースアドレスを持つパケットを送信することができます。
The threat is similar to that involving 6to4 routers, as described in Section 4.1.2.
4.1.2項で説明したような脅威は、その関与の6to4ルーターに似ています。
The difference here is that the attack is initiated by IPv4 or 6to4 nodes. The source IPv6 address may or may not be spoofed. Note that, as mentioned above, the relay is assumed to correlate the source IPv4 address with the address embedded in the source IPv6 address during decapsulation. A side effect is that all spoofed traffic will have a 6to4 source address.
ここでの違いは、攻撃がIPv4かの6to4ノードによって開始されていることです。元IPv6アドレスが偽装されたりしてもしなくてもよいです。上述したように、リレーはデカプセル化の際に送信元IPv6アドレスに埋め込まれたアドレスを送信元IPv4アドレスを相関させるために想定されることに留意されたいです。副作用はすべて偽装されたトラフィックを6to4送信元アドレスを持っているということです。
EXTENSIONS
EXTENSIONS
Spoofed traffic may also be sent to native IPv6 nodes either by other native IPv6 nodes, by 6to4 nodes, or by malicious IPv4 nodes to conduct Reflection DoS on either native IPv6 nodes or 6to4 nodes.
スプーフィングされたトラフィックはまた、ネイティブのIPv6ノードまたは6to4のノードのいずれかの反射DoS攻撃を行うための6to4ノードによって、または悪意のあるIPv4ノードによって、他のネイティブIPv6ノードネイティブIPv6ノードのいずれかによって送信されてもよいです。
Certain native IPv6 networks may have a trivial ACL (Access Control List) based firewall that allows traffic to pass through if it comes from particular source(s). Such a firewalling mechanism can be bypassed by address spoofing. This attack can therefore be used for trivial ACL avoidance as well. These attacks might be hampered by lost replies from the 6to4 node to the spoofed address.
特定のネイティブIPv6ネットワークは、それが特定のソース（S）から来る場合、トラフィックを通過させる些細なACL（アクセス制御リスト）ベースのファイアウォールを有することができます。このようなファイアウォール・メカニズムは、アドレススプーフィングによってバイパスすることができます。この攻撃は、そのためにも些細なACLの回避のために使用することができます。これらの攻撃は、偽装されたアドレスへの6to4ノードから失われた回答によって妨害される可能性があります。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
脅威分析とソリューション/緩和方法
The Denial-of-Service attack based on traffic spoofing is not new; the only twist is that traces of an attack are more easily lost. The 6to4 relay typically does not log IPv4 addresses (as they would be treated as L2 addresses), and thus the source of the attack (if launched from an IPv4 node) is lost. Because traces to the src_v4 address are easily lost, these attacks can also be launched from IPv4 nodes whose connections are ingress-filtered.
トラフィックスプーフィングに基づいたサービス拒否攻撃は新しいものではありません。唯一のねじれは、攻撃の痕跡をより容易に失われているということです。 （それらはL2アドレスとして扱われるように）6to4リレーは、典型的には、IPv4アドレスをログに記録しないので、（IPv4ノードから起動する場合）、攻撃のソースが失われます。 src_v4アドレスへのトレースが簡単に失われているため、これらの攻撃はまた、その接続に進入フィルタリングされているIPv4ノードから起動することができます。
These attacks might not be easy to perform and might be hampered because of the following:
これらの攻撃は実行することは容易ではないかもしれませんし、次の理由により妨げられる可能性があります。
o It might be difficult to launch such attacks from 6to4 nodes because even if the 6to4 routers allow spoofing of the source IPv6 address, the 6to4 relay would check whether the source V4ADDR is the same as the one embedded in the source IPv6 address. Thus, 6to4 nodes will be forced to use the correct IPv6 prefix while launching an attack, making it easy to close such attacks.
6to4ルーターは、送信元IPv6アドレスのスプーフィングを許可した場合でも、6to4リレーは、ソースV4ADDRは、ソースIPv6アドレスに埋め込まれたものと同じであるかどうかをチェックしますので、O 6to4ノードから、このような攻撃を開始するのは難しいかもしれません。したがって、6to4のノードは、それが簡単にこのような攻撃を閉じるようになって、攻撃を開始しながら、正しいIPv6プレフィックスを使用するように強制されます。
o Packets may pass through choke point(s), namely a 6to4 relay. In addition to physical limitations, there could be some sort of traffic rate limiting mechanisms that may be implemented, and these could tone down the attack.
Oパケットは、チョークポイント（複数可）、すなわち6to4リレーを通過することができます。物理的な制限に加えて、実装されてもよいし、これらが攻撃をトーンダウンできトラフィックレート制限メカニズムのいくつかの並べ替えがあるかもしれません。
o For every packet sent, at most one reply packet is generated: There is no amplification factor.
送信されたすべてのパケットのためにO、最大1つの応答パケットが生成されます。何の増幅率はありません。
Some of the mitigation methods for such attacks are as follows:
次のような攻撃の緩和方法のいくつかは、次のとおりです。
1. Ingress filtering in the IPv4 Internet to prevent packets with a spoofed IPv4 source from being transmitted. As the relay checks that the 6to4 address embeds the IPv4 address, no spoofing can be achieved unless IPv4 addresses can be spoofed. However, this would probably be an unfeasible requirement.
送信されてからのスプーフィングされたIPv4ソースとパケットを防ぐために、IPv4インターネット1.侵入フィルタ。 IPv4アドレスを偽装することができない限り、6to4アドレスは、IPv4アドレスを埋め込む中継チェックとして、何のスプーフィングを達成することができません。しかし、これはおそらく実現不可能な要件になります。
2. Security checks in the 6to4 relay. The 6to4 relay must drop traffic (from 6to4 nodes, or IPv4 nodes) with non-6to4 addresses as the source address, or for which the source IPv4 address does not match the address embedded in the source IPv6 address.
6to4リレー2.セキュリティチェック。 6to4リレーは、送信元IPv4アドレスが送信元IPv6アドレスに埋め込まれたアドレスと一致しない送信元アドレスとして、またはそのための非6to4のアドレスを持つ（6to4のノード、またはIPv4ノードからの）トラフィックをドロップしなければなりません。
COMPARISON TO SITUATION WITHOUT 6to4
6to4のWITHOUT状況を比較
Compared to Section 4.1.2, which describes more serious threats, this threat appears to be slightly more manageable. If the relays perform proper decapsulation checks, the spoofing can only be achieved, to a 6to4 source address, when the IPv4 address is spoofable as well.
より深刻な脅威を説明し、4.1.2項と比較すると、この脅威は、わずかにより管理であるように思われます。リレーが適切デカプセル化チェックを実行する場合、スプーフィングは、IPv4アドレスが同様に偽造される可能性があり6to4の送信元アドレスに、達成することができます。
ATTACK DESCRIPTION
ATTACK説明
These reflection attacks are similar to that involving 6to4 routers, as described in Section 4.1.3. Traffic may be reflected off native IPv6 nodes, or off 6to4 nodes. The attack can be initiated by one of the following:
4.1.3項で説明したように、これらの反射攻撃は、その関与の6to4ルーターに似ています。トラフィックは、ネイティブのIPv6ノード、またはオフの6to4ノードから反射されてもよいです。攻撃は、次のいずれかによって開始することができます。
o Native IPv6 nodes. These nodes can send invalid traffic with spoofed native IPv6 addresses to valid 6to4 nodes. Replies from the 6to4 nodes are part of a reflection attack.
ネイティブIPv6ノードO。これらのノードは、有効なの6to4ノードに偽装されたネイティブのIPv6アドレスで無効なトラフィックを送信することができます。 6to4のノードからの応答が反射攻撃の一部です。
o IPv4 nodes. These nodes can send traffic with native IPv6 source addresses (encapsulated by the IPv4 node itself into a protocol-41 packet) to 6to4 nodes. Replies from the 6to4 nodes are part of a reflection attack.
IPv4ノードO。これらのノードは、6to4ノードに（プロトコル41パケットにIPv4ノード自体によってカプセル化された）ネイティブIPv6ソースアドレスでトラフィックを送信することができます。 6to4のノードからの応答が反射攻撃の一部です。
o 6to4 nodes. These nodes can perform attacks similar to those by IPv4 nodes, but this would require spoofing of the source address at the 6to4 site before encapsulation, which is likely to be difficult.
6to4のノードO。これらのノードは、IPv4ノードでのものと同様の攻撃を行うことができますが、これは困難である可能性が高いカプセル化の前に、6to4サイトでの送信元アドレスのスプーフィングを必要とします。
When launched from a native IPv6 node, the traffic goes through 6to4 relays twice, both before and after the reflection; when launched from a 6to4/IPv4 node, the traffic goes through a relay only after the reflection.
ネイティブのIPv6ノードから起動すると、トラフィックが反射する前と後の両方、二回の6to4リレーを経由します。 6to4 / IPv4ノードから起動する場合、トラフィックのみを反射してリレーを通過します。
EXTENSIONS
EXTENSIONS
A distributed reflection DoS can be performed if a large number of native IPv6 nodes or IPv4/6to4 nodes are involved in sending spoofed traffic with the same source IPv6 address.
ネイティブIPv6ノードまたはの6to4のIPv4 /多数のノードが同一の送信元IPv6アドレスを偽装されたトラフィックを送信することに関与している場合は分布反射DoS攻撃を行うことができます。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
脅威分析とソリューション/緩和方法
Some of the mitigation methods for such attacks are as follows:
次のような攻撃の緩和方法のいくつかは、次のとおりです。
1. Attacks from the native IPv6 nodes could be stopped by implementing ingress filtering in the IPv6 Internet; hopefully this will become commonplace, but past experience of IPv4 ingress filtering deployment (or lack thereof) does not promise much.
ネイティブのIPv6ノードから1攻撃は、IPv6インターネットにイングレスフィルタリングを実行することによって停止することができます。うまくいけば、これは一般的になるだろうが、（またはその欠如）のIPv4イングレスフィルタリング導入の過去の経験はあまり約束していません。
2. Two measures are needed to stop or mitigate the attacks from IPv4 nodes: 1) Implementing ingress filtering in the IPv4 internet, and 2) logging IPv4 source addresses in the 6to4 router.
1）IPv4インターネットで入力フィルタリングを実装すると、6to4ルーターで2）ログのIPv4送信元アドレス：2つの対策が停止またはIPv4ノードからの攻撃を緩和するために必要とされています。
3. Attacks from 6to4 nodes in other sites can be stopped if the 6to4 routers in those sites implement egress filtering. This could be done by those sites, but the sites that are most likely to be abused are typically also those most likely to neglect installing appropriate filtering at their edges.
これらのサイトでの6to4ルータが出口フィルタを実装する場合、他のサイトでの6to4ノードから3.攻撃を停止させることができます。これは、それらのサイトで行うことができるが、悪用される可能性が最も高いサイトも、典型的には、その縁で適切なフィルタをインストール無視するそれらの可能性が最も高いです。
4. The traffic passes through one or two relays, and traffic rate limiting in the 6to4 relays might help tone down the reflection attack.
4.トラフィックは、1つのまたは2つのリレーを通過、と6to4リレーに制限トラフィックレートは、反射攻撃ダウントーンを助けるかもしれません。
COMPARISON TO SITUATION WITHOUT 6to4
6to4のWITHOUT状況を比較
Even though there are means to mitigate it, the attack is still rather efficient, especially when used by native IPv6 nodes with spoofed addresses. Using 6to4 relays and routers could easily take down the 6to4 relay system and/or provide an easy means for traffic laundering. However, if the attack is intended to DoS the victim, this can be achieved more smoothly by doing it directly (as the source address spoofing was available as well).
それを軽減するための手段があるにもかかわらず、攻撃は偽装されたアドレスを持つネイティブのIPv6ノードによって使用される場合は特に、まだかなり効率的です。 6to4のリレーやルータを使用すると、簡単に6to4リレーシステムをダウンおよび/またはトラフィックロンダリングのための容易な手段を提供することができます。 （送信元アドレススプーフィングが同様に利用可能であったとして）しかし、攻撃がDoS攻撃の犠牲に意図されている場合、これは直接それをすることによって、よりスムーズに実現することができます。
Therefore, the threat to the availability and stability of the 6to4 relay system itself seems to be higher than to the native IPv6 Internet.
したがって、6to4リレーシステム自体の可用性と安定に対する脅威はネイティブIPv6インターネットへのより高いように思えます。
This attack is similar to the ones employed against 6to4 routers, as described in Section 4.1.4. There are slight differences with regard to the source of the attacks. This attack can be initiated by:
この攻撃は、セクション4.1.4で説明したように、6to4のルータに対して使用したものと同様です。攻撃のソースに関しては若干の違いがあります。この攻撃は、によって開始することができます。
o native IPv6 nodes that may send traffic to the relay's subnet broadcast address, and
リレーのサブネットブロードキャストアドレスにトラフィックを送信することができ、ネイティブのIPv6ノードO、および
o IPv4 nodes that may send traffic with a spoofed source IP address (to be the relay's broadcast address) to elicit replies (e.g., ICMPv6 Hop Limit Exceeded) from the 6to4 relay to its local nodes.
O応答を誘発する（リレーのブロードキャストアドレスであると）、スプーフィングされた送信元IPアドレスにトラフィックを送信することができるIPv4ノードは、ローカルノードに6to4リレーから（例えば、ICMPv6のホップ制限を超えて）。
The first approach is more dangerous than those in Section 4.1.4 because it can be initiated by any IPv6 node (allowed to use the relay); the approach is not limited to local users.
それは（リレーを使用することを許可）任意のIPv6ノードによって開始することができるので、第1のアプローチは、4.1.4項のものよりも危険です。アプローチは、ローカルのユーザーに限定されるものではありません。
The second approach is trickier and not really useful. For it to succeed, the relay would have to accept native source addresses over the 6to4 pseudo-interface (we did not assume this check was implemented), as if coming from another relay, triggering an ICMPv6 message to the relay's local IPv4 subnet. The former method is more lucrative.
第2のアプローチは、トリッキーと本当に便利ではありません。それが成功するためには、リレーは、リレーのローカルIPv4サブネットにICMPv6メッセージをトリガする、他の中継から来たかのように、（私たちは、このチェックが実施されたと仮定していなかった）6to4擬似インタフェースを介してネイティブの送信元アドレスを受け入れなければならないでしょう。前者の方法がより有利です。
EXTENSIONS
EXTENSIONS
None.
無し。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
脅威分析とソリューション/緩和方法
The threat is restricted to the relay's local subnet and is fixed by tightening the 6to4 security checks.
脅威は、リレーのローカルサブネットに制限されていると6to4のセキュリティチェックを締め付けて固定されています。
COMPARISON TO SITUATION WITHOUT 6to4
6to4のWITHOUT状況を比較
This scenario is caused by 6to4, but fortunately the issue is not serious.
このシナリオでは、6to4によって引き起こされるが、幸い問題は深刻ではありません。
ATTACK DESCRIPTION
ATTACK説明
The 6to4 relay administrators would often want to use some policy to limit the use of the relay to specific 6to4 sites and/or specific IPv6 sites.
6to4リレー管理者は、多くの場合、特定の6to4サイトおよび/または特定のIPv6サイトへのリレーの使用を制限するために、いくつかのポリシーを使用するとよいでしょう。
The policy control is usually enacted by applying restrictions to where the routing information for 2002::/16 and/or 192.188.99.0/24 (if the anycast address used [3]) will spread.
ポリシー制御は、通常、（エニーキャストアドレスが使用される場合[3]）2002のルーティング情報:: / 16および/または192.188.99.0/24が拡散する場所に制約を適用することによって制定されます。
Some users may be able to use the service regardless of these controls, by
一部のユーザーはにより、これらのコントロールに関係なくサービスを利用することができるかもしれ
o configuring the address of the relay using its IPv4 address instead of 192.88.99.1, or
そのIPv4アドレスを使用してリレーのアドレスを設定する代わりに、192.88.99.1、またはO
o using the routing header to route IPv6 packets to reach specific 6to4 relays. (Other routing tricks, such as using static routes, may also be used.)
特定の6to4リレーに到達するルートIPv6パケットのルーティングヘッダを使用して、O。 （そのような静的ルートを使用するなど、他のルーティングトリックを使用してもよいです。）
EXTENSIONS
EXTENSIONS
None.
無し。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
脅威分析とソリューション/緩和方法
Attempts to use the relay's IPv4 address instead of 192.88.99.1 can be mitigated in the following ways:
代わりに192.88.99.1のリレーのIPv4アドレスを使用しようとすると、次の方法で軽減することができます。
1. IPv4 domains should prevent use of the actual IPv4 address of the relay instead of 192.88.99.1.
1. IPv4のドメインではなく、192.88.99.1のリレーの実際のIPv4アドレスを使用することを防ぐべきです。
2. Usage of access lists in the 6to4 relay to limit access. This is only feasible if the number of IP networks the relay is supposed to serve is relatively low.
アクセスを制限する6to4リレーでのアクセスリストの2用法。リレーがサービスを提供することになっているIPネットワークの数が比較的低い場合にのみ実現可能です。
3. The 6to4 relay should filter out arriving tunneled packets with protocol 41 (IPv6) that do not have 192.88.99.1 as the destination address.
3. 6to4リレーは、宛先アドレスとして192.88.99.1を持っていないプロトコル41（IPv6）のでトンネリングされたパケットを到着除外する必要があります。
The other threat, of using routing tricks in the IPv6 networks to reach the 6to4 relay, has similar solutions:
6to4リレーに到達するためにIPv6ネットワークにルーティングトリックを使用して他の脅威は、同様のソリューションを持っています：
2. Filtering out the packets with a routing header (although this may have other implications).
2.（これは他の意味を有していてもよいが）ルーティングヘッダを持つパケットをフィルタリングします。
3. Monitoring the source addresses going through the relay to detect, e.g., peers setting up static routes.
3.例えば、ピアが静的ルートを設定、検出するためにリレーを経由する送信元アドレスを監視します。
Routing Header is not specific to 6to4. The main thing one could do with it here would be to select the relay. Some generic threats about routing header use are described in [11].
ルーティングヘッダは、6to4に固有ではありません。 1は、ここでそれを行うことができます主なものは、リレーを選択することであろう。ルーティングヘッダの使用に関するいくつかの一般的な脅威は、[11]に記載されています。
As this threat does not have implications for anything other than the organization providing 6to4 relay, it is not analyzed any further.
この脅威は、6to4リレーを提供する組織以外に影響を持っていないとして、それがどのさらに分析されていません。
COMPARISON TO SITUATION WITHOUT 6to4
6to4のWITHOUT状況を比較
These threats are specific to 6to4 relays (or in general anycast services) and do not exist in networks without 6to4.
これらの脅威は、6to4リレー（または一般的なエニーキャストサービスにおける）に固有のものと6to4せずにネットワークに存在しません。
ATTACK DESCRIPTION
ATTACK説明
Several attacks use 6to4 relays to anonymize the traffic; this often results in packets being tunneled from the relay to a supposedly-6to4 site.
いくつかの攻撃は、トラフィックを匿名化するための6to4リレーを使用します。これは、多くの場合、おそらく-の6to4サイトにリレーからトンネルされるパケットになります。
However, as was pointed out in Section 4.2, the IPv4 source address used by the relay could, on a cursory look, be seen as the source of these "protocol-41" attacks.
4.2節で指摘されたとしてしかし、リレーが使用するIPv4ソースアドレスは、ザッ表情に、これらの「プロトコル-41」攻撃のソースとして見ることができます。
This could cause a number of concerns for the operators deploying 6to4 relay service, including the following:
これは、次のような6to4リレーサービスを、導入する事業者のための問題の数を引き起こす可能性があります：
o being contacted a lot (via email, phone, fax, or lawyers) on suspected "abuse",
Oの疑い「虐待」の（電子メール、電話、ファックス、または弁護士経由で）多くのことを接触させ、
o having the whole IPv4 address range rejected as a source of abuse or spam, causing outage to other operations as well, or
O、乱用またはスパムのソースとして拒否全IPv4アドレス範囲を有するだけでなく他の動作に障害を引き起こす、または
o causing the whole IPv4 address range to be blacklisted in some "spammer databases", if the relay were used for those purposes.
リレーは、これらの目的のために使用された場合、全IPv4アドレス範囲は、いくつかの「スパム送信者データベース」にブラックリストする原因O。
This threat seems slightly similar to the outburst of SMTP abuse caused by open relays but is more generic.
この脅威は、オープンリレーによって引き起こされるSMTP虐待の爆発に少し似ているようだが、より汎用的です。
EXTENSIONS
EXTENSIONS
None.
無し。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
脅威分析とソリューション/緩和方法
This problem can be avoided (or, really, "made someone else's problem") by using the 6to4 anycast address in 192.88.99.0/24 as the source address. Blacklisting or rejecting this should not cause problems to the other operations.
この問題を回避することができる送信元アドレスとして192.88.99.0/24での6to4エニキャストアドレスを使用して、（実際に、または、「他の誰かの問題を作りました」）。ブラックリストまたはこれを拒否すると、他の操作に問題が発生することはありません。
Further, when someone files complaints to the owner of 192.88.99.0/24, depending on which registry they are querying, they might get, for example:
誰かが、彼らが照会されているレジストリに依存192.88.99.0/24の所有者に苦情を、ファイルときまた、彼らは例えば、受け取ることがあります。
o knowledge that this is a special IANA address block, with no real contact person,
これが本当の担当者で、特別なIANAのアドレスブロックであることをO知識、
o knowledge that this is a special address block for RFC 3068, or
これはRFC 3068のための特別なアドレスブロックであることをO知識、または
o knowledge that this is a special address block for RFC 3068, and that there are multiple entries by relay operators in the database.
これは、RFC 3068のための特別なアドレス・ブロックであること、およびデータベースの中継オペレータによって複数のエントリがあることO知識。
Any of these, at least when processed by a human, should show that the 6to4 relay is in fact innocent. Of course, this could result in reports going to the closest anycast 6to4 relay as well, which had nothing to do with the incident.
これらのいずれかが、人間によって処理され、少なくともとき、6to4リレーが実際に無実であることを示す必要があります。もちろん、これは事件とは何の関係もなかっただけでなく、最も近いエニーキャスト6to4リレーに行くの報告、につながる可能性があります。
However, the widespread usage of 192.88.99.1 as the source address may make it more difficult to disambiguate the relays, which might be a useful feature for debugging purposes.
しかし、送信元アドレスとして192.88.99.1の広範囲の使用はデバッグ目的のために有用な機能であるかもしれない、それはより困難リレーを明確にすることがあります。
COMPARISON TO SITUATION WITHOUT 6to4
6to4のWITHOUT状況を比較
This threat is caused by 6to4 deployment but can be avoided, at least in the short-term, by using 192.88.99.1 as the source address.
この脅威は、6to4展開によって引き起こされるが、送信元アドレスとして192.88.99.1を使用することにより、少なくとも短期的に回避することができます。
There are two types of attacks on the IPv4 internet - spoofed traffic, and reflection. These can be initiated by native IPv6 nodes, 6to4 nodes, and IPv4 nodes.
偽装されたトラフィック、および反射 - IPv4インターネット上の攻撃の2種類があります。これらは、ネイティブのIPv6ノード、6to4のノード、およびIPv4ノードによって開始することができます。
Attacks initiated by IPv4 nodes that send spoofed traffic, which would not use the 6to4 infrastructure, are considered out of the scope of this document. 6to4 infrastructure may be used in reflection attacks initiated by IPv4 nodes.
6to4のインフラストラクチャを使用することはありません偽装されたトラフィックを、送信IPv4ノードによって開始された攻撃は、このドキュメントの範囲外と考えられています。 6to4のインフラストラクチャは、IPv4ノードによって開始された反射攻撃に使用することができます。
It is difficult for these attacks to be effective, as the traffic sent out will be IPv6-in-IPv4. Such traffic will be rejected by most IPv4 nodes unless they have implemented some sort of IPv6-in-IPv4 tunneling.
これらの攻撃を効果的にするために送出されたトラフィックがIPv6-IPv4の中-になりますように、それは、困難です。彼らは、IPv6インのIPv4トンネリングのいくつかの並べ替えを実装していない限り、このようなトラフィックは、ほとんどのIPv4ノードによって拒否されます。
Columns:
コラム：
o Section number. The section that describes the attack.
Oセクション番号。攻撃を説明するセクション。
o Attack name.
お あったｃｋ なめ。
o Initiator. The node that initiates the attack.
イニシエータO。攻撃を開始したノード。
* I_4 - IPv4 node
* I_4 - IPv4ノード
* I_6 - native IPv6 node
* I_6 - ネイティブのIPv6ノード
* 6to4 - 6to4 node
*の6to4 - 6to4のノード
* * - All of the above
* * - 上記のすべて
o Victim. The victim node
O被害者。犠牲者ノード
* I_4 - IPv4 node
* I_4 - IPv4ノード
* I_6 - native IPv6 node
* I_6 - ネイティブのIPv6ノード
* 6to4 - 6to4 node
*の6to4 - 6to4のノード
* Relay - 6to4 relay
*リレー - 6to4リレー
* Router - 6to4 router
*ルータ - の6to4ルーター
o ToA. Type of Attack
お とあ。 Ｔｙぺ おｆ あったｃｋ
* D - DoS
* D - DoS攻撃
* R - Reflection DoS
* R - リフレクションDoS攻撃
* T - Theft of Service
* T - サービスの盗難
o Fix. Specified who is responsible for fixing the attack.
O修正。攻撃を固定する責任者を指定しました。
* 6 - The 6to4 developer and/or operator can completely mitigate this attack.
* 6 - 6to4の開発者および/またはオペレータは完全にこの攻撃を軽減することができます。
* 6* - The 6to4 developer and/or operator can partially mitigate this attack.
* 6 * - 6to4の開発者および/またはオペレータは、部分的にこの攻撃を軽減することができます。
* E - This threat cannot be fixed by the 6to4 developer or the 6to4 operator.
* E - この脅威は、6to4開発者や6to4のオペレーターによって固定することができません。
Summary of attacks on a 6to4 network:
6to4のネットワークへの攻撃の概要：
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.1 | Attacks with ND | I_4 | Router | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.2 | Spoofing Traffic | I_4,I_6 | 6to4 | D | E |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.3 | Reflection Attacks | * | 6to4 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.4 | Local IPv4 Broadcast | * | Router | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
Figure 9
図9
Summary of attacks on the native IPv6 internet:
ネイティブのIPv6インターネットへの攻撃の概要：
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.1 | Attacks with ND | I_4 | Relay | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.2 | Spoofing Traffic | I_4,6to4| I_6 | D | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.3 | Reflection Attacks | * | I_6 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.4 | Local IPv4 Broadcast | * | Relay | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.5 | Theft of Service | 6to4 | Relay | T | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.6 | Relay Operators ... | - | - | D | 1) |
+-------+----------------------+---------+----------+-----+-----+
Figure 10
図10
Notes:
ノート：
1) This attack is a side-effect of the other attacks and thus does not have any Initiator, Victim, and Fix. It is a Denial of Service attack not on the network but on the organization in-charge of the relay.
1）この攻撃は、他の攻撃の副作用であり、したがって、任意のイニシエータ、犠牲者を持って、そして修正されません。それはありませんが、ネットワーク上での充電リレーの組織上のDoS攻撃です。
Summary of attacks on IPv4 internet:
IPv4インターネット上の攻撃の概要：
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.3 | Spoofing Traffic | * | I_4 | D | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.3 | Reflection Attacks | * | I_4 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
Figure 11
図11
This section describes several ways to implement the security checks required or implied by the specification [1] or augmented by this memo. These do not, in general, protect against most of the threats listed above in the "Threat Analysis" section. They are only prerequisites for a relatively safe and simple 6to4 implementation.
このセクションでは、仕様で要求または暗示セキュリティチェックを実施するいくつかの方法を記載している[1]又はこのメモによって補強します。これらは、一般的には、「脅威分析」セクションでは、上記の脅威のほとんどは保護されません。彼らは比較的安全かつ簡単6to4の実装のための唯一の前提条件です。
Note that, in general, the 6to4 router or relay does not know whether it is acting as a router or relay. It would be possible to include a toggle to specify the behaviour, to be used when, e.g., the interface is brought up, but as of February 2004, no implementations were known to do that. Therefore, the checks are described as that which works independently of whether the node is a router or relay.
一般的には、6to4ルーターやリレーは、それがルータまたはリレーとして機能しているかどうかわからない、ということに注意してください。例えば、インタフェースが育てている際に、使用される、動作を指定するトグルを含めることが可能であろうが、2004年2月の時点で、何の実装は、それを行うことが知られていませんでした。したがって、チェックノードは、ルータまたはリレーであるかどうかとは無関係に動作するものとして記載されています。
The checks described in this section are to be performed when encapsulating IPv6 into IPv4.
このセクションで説明されている検査は、IPv4内IPv6をカプセル化するときに実行されます。
The encapsulation rules are mainly designed to keep implementors from "shooting themselves in the foot." For example, the source address check would verify that the packet will be acceptable to the decapsulator, or the sanity checks would ensure that addresses derived from private addresses are not used (which would be equally unacceptable).
カプセル化規則は、主からの実装を保つように設計されている「足で自分自身を撮影します。」例えば、ソースアドレスチェックは、パケットがカプセル開放装置に受け入れられるか、または健全性チェックが（等しく受け入れられないであろう）のプライベートアドレスに由来するアドレスが使用されないことを確実にすることを確認します。
src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below) else drop
if prefix (src_v6) == 2002::/16
ipv4 address embedded in src_v6 MUST match src_v4
else if prefix (dst_v6) == 2002::/16
dst_v4 SHOULD NOT be assigned to the router
else
drop
/* we somehow got a native-native ipv6 packet */
fi
accept
The checks described in this section are to be performed when decapsulating IPv4 into IPv6. They will be performed in both the 6to4 router and relay.
このセクションで説明されている検査は、IPv6にはIPv4をデカプセル化する際に実行されます。彼らは、6to4ルーターとリレーの両方で実行されます。
src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop src_v6 and dst_v6 MUST pass ipv6-sanity checks, else drop if prefix (dst_v6) == 2002::/16 ipv4 address embedded in dst_v6 MUST match dst_v4 if prefix (src_v6) == 2002::/16 ipv4 address embedded in src_v6 MUST match src_v4 dst_v4 SHOULD be assigned to the router fi elif prefix (src_v6) == 2002::/16 ipv4 address embedded in src_v6 MUST match src_v4 dst_v4 SHOULD be assigned to the router (see notes below)
src_v4とdst_v4は=プレフィックス（src_v6）場合dst_v6に埋め込まれたプレフィックス（dst_v6）== 2002 :: / 16のIPv4アドレスがdst_v4と一致する必要がある場合は他のドロップsrc_v6とdst_v6は、他のドロップのIPv6-健全性チェックに合格する必要があり、IPv4に健全性チェックに合格しなければなりませんsrc_v4 dst_v4と一致しなければならないsrc_v6に埋め込ま= 2002 :: / 16のIPv4アドレスは、ルータに割り当てられるべきsrc_v4 dst_v4と一致しなければならないルータのfi ELIFプレフィックス（src_v6）== 2002 :: / 16のIPv4アドレスsrc_v6に埋め込まに割り当てられるべきです（ ）下記の注意事項を参照してください
else
drop
/* the we somehow got a native-native ipv6 packet */
fi
accept
The encapsulation and decapsulation checks include certain sanity checks for both IPv4 and IPv6. These are described here in detail.
カプセル化及びデカプセル化チェックがIPv4とIPv6の両方のための特定の健全性チェックを含みます。これらは、ここでは詳細に記載されています。
IPv4 address MUST be a global unicast address, as required by the 6to4 specification. The disallowed addresses include those defined in [14], and others widely used and known not to be global. These are
6to4の仕様によって要求されるように、IPv4アドレスは、グローバルユニキャストアドレスでなければなりません。禁止アドレスは[14]で定義されたもの、そして広く使用され、グローバルではないことが知られている他のものが挙げられます。これらは
o 0.0.0.0/8 (the system has no address assigned yet)
0.0.0.0/8 O（システムがまだ割り当てられたアドレスを持っていません）
o 10.0.0.0/8 (private)
O 10.0.0.0/8（プライベート）
o 127.0.0.0/8 (loopback)
ああ127.0.0.0/8（ループバック）
o 172.16.0.0/12 (private)
O 172.16.0.0/12（プライベート）
o 192.168.0.0/16 (private)
O 192.168.0.0/16（プライベート）
o 169.254.0.0/16 (IANA Assigned DHCP link-local)
O 169.254.0.0/16（IANA割り当てDHCPリンクローカル）
o 224.0.0.0/4 (multicast)
O 224.0.0.0/4（マルチキャスト）
o 240.0.0.0/4 (reserved and broadcast)
O 240.0.0.0/4（予約およびブロードキャスト）
In addition, the address MUST NOT be any of the system's broadcast addresses. This is especially important if the implementation is made so that it can
また、アドレスは、システムのブロードキャストアドレスのいずれかであってはなりません。実装が行われた場合、これは特に重要であることができるように、
o receive and process encapsulated IPv4 packets arriving at its broadcast addresses, or
O受信および処理は、そのブロードキャストアドレスに到着するIPv4パケットをカプセル化し、または
o send encapsulated IPv4 packets to one of its broadcast addresses.
Oそのブロードキャスト・アドレスの1つにカプセル化されたIPv4パケットを送信します。
IPv6 address MUST NOT be
IPv6アドレスはしているはずがありません
o 0::/16 (compatible, mapped addresses, loopback, unspecified, ...)
0 :: / 16（互換性、マッピングされたアドレス、ループバック、不特定、...）
o fe80::/10 (link-local)
O FE80 :: / 10（リンクローカル）
o fec0::/10 (site-local)
FEC0 :: / 10（サイトローカル）
o ff00::/8 (any multicast)
O FF00 :: / 8（任意マルチキャスト）
Note: Only link-local multicast would be strictly required, but it is believed that multicast with 6to4 will not be feasible, so it has been disallowed as well.
注：のみリンクローカルマルチキャストは厳密に必要とされるであろうが、6to4のでマルチキャストが実現可能ではないだろうと考えられているので、それは同様に禁止されています。
In addition, it MUST be checked that equivalent 2002:V4ADDR::/48 checks, where V4ADDR is any of the above IPv4 addresses, will not be passed.
また、それは同等の2002ことをチェックしなければなりません：V4ADDRは、上記のIPv4アドレスのいずれかであるV4ADDR :: / 48をチェックし、渡されません。
In addition, the implementation in the 6to4 router may perform some form of ingress filtering (e.g., Unicast Reverse Path Forwarding checks). For example, if the 6to4 router has multiple interfaces, of which some are "internal", receiving either IPv4 or IPv6 packets with source address belonging to any of these internal networks from the Internet might be disallowed.
また、6to4ルーターにおける実装がイングレスフィルタリング（例えば、ユニキャストリバースパス転送チェック）のいくつかのフォームを実行することができます。 6to4ルーターは、インターネットからこれらの内部ネットワークのいずれかに属する送信元アドレスを持つパケットが許可されるかもしれないIPv4またはIPv6のいずれかを受け、一部が「内部」である複数のインターフェースを有する場合、例えば。
If these checks are implemented and enabled by default, it's recommended that there be a toggle to disable them if needed.
これらのチェックが実装され、デフォルトで有効になっている場合は、必要な場合は、それらを無効にするトグルがあることをお勧めします。
The rule "dst_v4 SHOULD be assigned to the router" is not needed if the 6to4 router implementation only accepts and processes encapsulated IPv4 packets arriving to its unicast IPv4 addresses, and when the destination address is known to be a local broadcast address, it does not try to encapsulate and send packets to it. (See Sections 4.1.4 and 4.2.4 about this threat.)
6to4ルーターの実装のみ受け入れ、プロセスがそのユニキャストIPv4アドレスに到着したIPv4パケットをカプセル化し、宛先アドレスがローカルブロードキャストアドレスであることが知られているとき、そうでない場合は、「dst_v4はルータに割り当てられるべきである」ルールは必要ありませんカプセル化し、それにパケットを送信しようとします。 （この脅威についてのセクション4.1.4と4.2.4を参照してください。）
Some checks, especially the IPv4/IPv6 Sanity Checks, could be at least partially implementable with system-level access lists, if one would like to avoid placing too many restrictions in the 6to4 implementation itself. This depends on how many hooks are in place for the access lists. In practice, it seems that this could not be done effectively enough unless the access list mechanism is able to parse the encapsulated packets.
1を6to4実装自体にあまりにも多くの制限を置く避けたい場合にはいくつかのチェック、特にはIPv4 / IPv6の健全性チェックは、システムレベルのアクセスリストと少なくとも部分的に実施可能である可能性があります。これは、アクセスリストのために整備されているどのように多くのフックに依存します。実際には、アクセスリストメカニズムがカプセル化されたパケットを解析することができない限り、これは効果的に十分に行うことができませんでしたようです。
This section tries to give an overview of some of the problems 6to4 implementations face, and the kind of generic problems the 6to4 users could come up with.
このセクションでは、6to4実装が直面する問題のいくつかの概要、および6to4のユーザーが思い付くことができ、一般的な問題のようなものを与えることをしようとします。
There is a problem with multiple transition mechanisms if strict security checks are implemented. This may vary a bit from implementation to implementation.
厳密なセキュリティチェックが実装されている場合、複数の移行メカニズムに問題があります。これは、実装から実装へのビットを変えることができます。
Consider three mechanisms using automatic tunneling: 6to4, ISATAP [15], and Automatic Tunneling using Compatible Addresses [4] (currently removed [10] but typically still supported). All of these use IP-IP (protocol 41) [16] IPv4 encapsulation with, more or less, a pseudo-interface.
[4]（現在除去[10]が、典型的には、まだサポートされている）互換アドレスを使用した6to4、ISATAP [15]、および自動トンネリング三つ自動トンネリングを使用して機構を考えます。これらの全ては、IP-IP（プロトコル41）は、多かれ少なかれ、擬似インタフェースを有する[16]のIPv4カプセル化を使用します。
When a router, which has any two of these enabled, receives an IPv4 encapsulated IPv6 packet
これらのいずれか2つを持っているルータは、有効にすると、IPv4のは、IPv6パケットをカプセル化された受信
src_v6 = 2001:db8::1 dst_v6 = 2002:1010:1010::2 src_v4 = 10.0.0.1 dst_v4 = 20.20.20.20
srts_vsh = 2001：DB8 :: 1 dst_vsh = 2002：1010：1010 :: 2 srts_vch = 10.0.0.1 dst_vch = 20.20.20.20
What can it do? How should it decide which transition mechanism this belongs to; there is no "transition mechanism number" in the IPv6 or IPv4 header to signify this. (This can also be viewed as a flexibility benefit.)
それは何ができますか？それはどのようにこれが属する移行メカニズムを決める必要があります。これを表すためのIPv6又はIPv4のヘッダには「遷移機構番号」は存在しません。 （これはまた、柔軟性の利点と見なすことができます。）
Without any kind of security checks (in any of the implemented methods), these often just "work", as the mechanisms aren't differentiated but handled in "one big lump".
（実装のいずれかの方法で）セキュリティチェックのいずれかの種類がなければ、これらはしばしば単に「仕事」、メカニズムは「一つの大きな塊」で分化が、処理されませんよう。
Configured tunneling [4] does not suffer from this, as it is point-to-point and based on src_v6/dst_v6 pairs of both IPv4 and IPv6 addresses, so the tunnel interface can be logically deduced.
それは、ポイントツーポイントであり、IPv4およびIPv6アドレスの両方のsrc_v6 / dst_v6ペアに基づくので、トンネルインターフェイスが論理的に推定することができるように構成されたトンネルは、[4]、これを受けません。
Solutions for this include 1) not using more than one automatic tunneling mechanism in a node and 2) binding different mechanisms to different IPv4 addresses.
これに対する解決策は、ノード内に複数の自動トンネリングメカニズムを使用し、2）異なるIPv4アドレスとは異なるメカニズムを結合しない）1を含みます。
Even though this was already discussed in Section 4.1.2, it bears some additional elaboration, as it was the only problem that cannot be even partially solved using the current deployment model. There are some mitigation methods.
これは、既に4.1.2項で説明したにもかかわらず、それは部分的にも現在の展開モデルを使用して解決することができない唯一の問題だったとして、それは、いくつかの追加の精緻化を負いません。いくつかの緩和方法があります。
6to4 routers receive traffic from non-6to4 ("native") sources via 6to4 relays. 6to4 routers have no way of matching the IPv4 source address of the relay with the non-6to4 IPv6 address of the source. Consequently, anyone can spoof any non-6to4 IPv6 address by sending traffic, encapsulated, directly to 6to4 routers.
6to4ルーターは、6to4リレーを経由して非の6to4（「ネイティブ」）のソースからのトラフィックを受信します。 6to4のルータは、送信元の非の6to4のIPv6アドレスとリレーのIPv4ソースアドレスを一致させる方法がありません。その結果、誰もが直接の6to4ルータに、カプセル化され、トラフィックを送信することにより、任意の6to4以外のIPv6アドレスを偽装することができます。
It could be possible to turn the deployment assumptions of 6to4 around a bit to eliminate some threats caused by untrusted 6to4 relays:
信頼できないの6to4リレーによって引き起こされるいくつかの脅威を排除するために少し周りの6to4の展開の前提条件をオンにすることも可能かもしれません。
o Every dual-stack site (or even ISP) would be required to have its own 6to4 relay. (This assumes that IPv6-only is so far away that 6to4 would be retired by that point.) That is, there would not be third-party relays, and 2002::/16 and 192.88.99.0/24 routes would not need to be advertised globally.
Oすべてのデュアルスタックサイト（あるいはISP）は、独自の6to4リレーを持つことが必要とされるであろう。 （これはIPv6のみの6to4は、その時点で引退するだろうと遠く離れていることを前提としています。）つまり、そこにサードパーティ製のリレーではないでしょう、と2002 :: / 16と192.88.99.0/24ルートはする必要はありません世界的に宣伝します。
o The security implications of 6to4 use could be pushed back to the level of trust inside the site or ISP (or their acceptable use policies). This is something that the sites and ISPs should already be familiar with already.
O 6to4の使用のセキュリティへの影響は、サイトやISP（またはその利用規定）内部の信頼のレベルに押し戻すことができます。これは、サイトやISPはすでに、すでに精通している必要があり何かです。
However, this presents a number of problems:
しかし、これは多くの問題を提示します：
This model would shift most of the burden of supporting 6to4 to IPv6 sites that don't employ or use 6to4 at all, i.e., "those who deploy proper native dual-stack." It could be argued that the deployment pain should be borne by 6to4 users, not by the others.
採用または全てでの6to4を使用していないIPv6サイトへの6to4をサポートするの負担のほとんどをシフトするこのモデルは、すなわち、「適切なネイティブデュアルスタックを展開する人。」展開の痛みが6to4のユーザーが、ない他の人が負担すべきであると主張することができます。
The main advantage of 6to4 is easy deployment and free relays. This would require that everyone the 6to4 sites wish to communicate with implement these measures.
6to4のの主な利点は、容易な展開と自由のリレーです。これは、6to4サイトがこれらの措置の実施と通信したいという誰もが必要となります。
The model would not fix the "relay spoofing problem", unless everybody also deployed 6to4 addresses on the nodes (alongside with native addresses, if necessary), which would in turn change 6to4 to operate without relays completely.
（必要であれば、ネイティブのアドレスと一緒に）誰もがまたノード上の6to4アドレスを展開しない限り、モデルがターンチェンジの6to4で完全中継しなくても動作するように思われる、「リレーなりすましの問題を」解決しないでしょう。
This document discusses security considerations of 6to4.
この文書では、6to4のセキュリティ上の考慮事項について説明します。
Even if proper checks are implemented, there are a large number of different security threats; these threats are analyzed in Section 4.
適切なチェックが実装されている場合でも、異なるセキュリティ脅威の数が多いです。これらの脅威は、第4節で分析されています。
There are mainly four classes of potential problem sources:
潜在的な問題の発生源の4つのクラスが主にあります。
1. 6to4 routers not being able to identify whether relays are legitimate
1.の6to4ルーターはリレーが正当であるかどうかを識別することができません
2. Wrong or impartially implemented 6to4 router or relay security checks
2.間違ったか、公平に実装さ6to4ルーターやリレーセキュリティチェック
3. 6to4 architecture used to participate in DoS or reflected DoS attacks or made to participate in "packet laundering", i.e., making another attack harder to trace
3. 6to4のアーキテクチャDoS攻撃に参加するために使用されるか、またはDoS攻撃を反射またはトレースに難しく、別の攻撃を行う、「パケット・ロンダリング」、すなわちに参加するために作られました
4. 6to4 relays being subject to "administrative abuse" e.g., theft of service or being seen as a source of abuse.
例えば、「管理乱用」、サービスの盗難を受けること又は乱用の源として見られる4の6to4リレー。
The first is the toughest problem, still under research. The second can be fixed by ensuring the correctness of implementations; this is important. The third is also a very difficult problem, impossible to solve completely; therefore it is important to be able to analyze whether this results in a significant increase of threats. The fourth problem seems to have feasible solutions.
最初は、まだ研究の下、過酷な問題です。第二は、実装の正しさを保証することによって固定することができます。これは重要。第三は、また完全に解決することができない非常に困難な問題です。したがって、脅威の大幅な増大をもたらすかどうかを分析できることが重要です。第4の問題点は、実現可能な解決策を持っているようです。
These are analyzed in detail in "Threat Analysis", in Section 4.
これらは、第4節では、「脅威分析」で詳細に分析されています。
Some issues were first brought up by Itojun Hagino in [17], and Alain Durand introduced one specific problem at IETF51 in August 2001 (though there was some discussion on the list prior to that); these two gave the authors the push to start looking into the details of securing 6to4.
いくつかの問題は、最初の[17]にいとぢゅん萩野に育てられ、そして（その前に、リスト上のいくつかの議論があったが）アラン・デュランは2001年8月にIETF51に一つの特定の問題を紹介しました。これら二つは、著者に6to4の確保の詳細に見て開始するプッシュを与えました。
Alexey Kuznetsov brought up the implementation problem with IPv6 martian checks. Christian Huitema formulated the rules that rely on 6to4 relays using only anycast. Keith Moore brought up the point about reduced flexibility. Brian Carpenter, Tony Hain, and Vladislav Yasevich are acknowledged for lengthy discussions. Alain Durand reminded the authors about relay spoofing problems. Brian Carpenter reminded the authors about the BGP-based 6to4 router model. Christian Huitema gave a push for a more complete threat analysis. Itojun Hagino spelled out the operators' fears about 6to4 relay abuse. Rob Austein brought up the idea of a different 6to4 deployment model.
アレクセイ・クズネツォフは、IPv6火星のチェックを実装上の問題を育てました。クリスチャンのHuitemaはエニーキャストを使用した6to4リレーに依存しているルールを策定しました。キース・ムーアは減少し、柔軟性についてポイントを育てました。ブライアン・カーペンター、トニーハイン、およびウラジスラフYasevichは長い議論のために認められています。アラン・デュランは、リレーなりすましの問題について作者に思い出させました。ブライアン・カーペンターは、BGPベースの6to4ルーターモデルについて作者に思い出させました。クリスチャンのHuitemaは、より完全な脅威分析のためにプッシュを与えました。いとぢゅん萩野は6to4リレー虐待に関する事業者の不安をスペルアウト。ロブAusteinとは異なる6to4の展開モデルのアイデアを育てました。
In the latter phase, discussions with Christian Huitema, Brian Carpenter, and Alain Durand were helpful when improving the document.
ドキュメントを改善したときに、後者の段階では、クリスチャンのHuitema、ブライアン・カーペンター、アラン・デュランとの議論は有用でした。
David Malone, Iljitsch van Beijnum, and Tim Chown gave feedback on the document.
デビッド・マローン、IljitschバンBeijnum、そしてティムchownコマンドは、ドキュメントに関するフィードバックを与えました。
[1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[1]カーペンター、B.およびK.ムーア、 "IPv4の雲を介したIPv6ドメインの接続"、RFC 3056、2001年2月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[3]のHuitema、C.、 "6to4のリレールータのエニーキャストプレフィックス"、RFC 3068、2001年6月を。
[4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[4]ギリガン、R.およびE. Nordmarkと、 "IPv6ホストとルータの移行メカニズム"、RFC 2893、2000年8月。
[5] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[5] IANA、 "特殊用途IPv4アドレス"、RFC 3330、2002年9月を。
[6] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[6] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[7] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[7] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[8] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[8] Nikander、P.、ケンプ、J.、およびE. Nordmarkと、 "IPv6近隣探索（ND）信頼モデルと脅威"、RFC 3756、2004年5月。
[9] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", Work in Progress, July 2004.
[9] Arkko、J.、ケンプ、J.、ゾンマーフェルト、B.、Zill、B.、およびP. Nikanderを、進行、2004年7月ワーク "近隣探索を（送信）セキュア"。
[10] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", Work in Progress, September 2004.
[10] Nordmarkと、E.とR.ギリガン、「IPv6ホストとルータのための基本的な移行メカニズム」、進歩、2004年9月での作業。
[11] Savola, P., "Security of IPv6 Routing Header and Home Address Options", Work in Progress, March 2002.
[11] Savola、P.、「IPv6ルーティングヘッダのセキュリティとホームアドレスオプション」、進歩、2002年3月での作業。
[12] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[12]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス拒否攻撃を破り"、BCP 38、RFC 2827、2000年5月。
[13] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback Messages", Work in Progress, February 2003.
[13] Bellovin氏、S.、リーチ、M.及びT.テイラー、 "ICMPトレースバックメッセージ"、進歩、2003年2月ワーク。
[14] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[14]ベイカー、F.、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
[15] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Work in Progress, May 2004.
[15]テンプリン、F.、グリーソン、T.、Talwar、M.とD.ターラー、 "プロトコル（ISATAP）をアドレス指定、サイト内の自動トンネル"、進歩、2004年5月での作業。
[16] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[16]シンプソン、W.、 "IPトンネリングでIP"、RFC 1853、1995年10月。
[17] Hagino, J., "Possible abuse against IPv6 transition technologies", Work in Progress, July 2000.
[17]萩野、J.、 "IPv6移行テクノロジに対する可能な虐待"、進歩、2000年7月の作業。
Appendix A. Some Trivial Attack Scenarios Outlined
いくつかの些細な攻撃シナリオを概説付録A.
Here, a few trivial attack scenarios are outlined -- ones that are prevented by implementing checks listed in [1] or in section 6.
ここで、いくつかの些細な攻撃シナリオが概説されている - [1]またはセクション6に記載されているチェックを実行することによって防止されるもの。
When two 6to4 routers send traffic to each others' domains, the packet sent by RA to RB resembles the following:
2つの6to4ルータがお互いのドメインにトラフィックを送信すると、RBにRAによって送信されたパケットは次のようになります。
src_v6 = 2002:0800:0001::aaaa dst_v6 = 2002:0800:0002::bbbb src_v4 = 8.0.0.1 (added when encapsulated to IPv4) dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)
src_v6 = 2002：0800：0001 :: AAAA dst_v6 = 2002：0800：0002 :: BBBB src_v4 = 8.0.0.1（追加のIPv4にカプセル化された場合）dst_v4 = 8.0.0.2（追加のIPv4にカプセル化された場合）
When the packet is received by IPv4 stack on RB, it will be decapsulated so that only src_v6 and dst_v6 remain, as originally sent by RA:
パケットはRB上のIPv4スタックによって受信された場合のみsrc_v6とdst_v6が残るように、もともとRAによって送信されたとして、それは、カプセル化が解除されます。
src_v6 = 2002:0800:0001::aaaa dst_v6 = 2002:0800:0002::bbbb
src_v6 = 2002：0800：0001 :: AAAAのdst_v6 = 2002：0800：0002 :: BBBB
As every other node is just one hop away (IPv6-wise) and the link-layer (IPv4) addresses are lost, this may open many possibilities for misuse.
他のすべてのノードがちょうど1ホップ（IPv6の単位）であり、リンク層（IPv4）のアドレスが失われたように、これは誤用のために多くの可能性を開くことができます。
As an example, unidirectional IPv6 spoofing is made trivial because nobody can check (without delving into IP-IP packets) whether the encapsulated IPv6 addresses were authentic. (With native IPv6, this can be done by, e.g., RPF-like mechanisms or access lists in upstream routers.)
誰もが、カプセル化されたIPv6アドレスが真正であるかどうか（IP-IPパケットに踏み込んなし）を確認することができないので、一例として、一方向のIPv6スプーフィングは自明なります。 （ネイティブIPv6では、これは上流のルータに、例えば、RPF状機構またはアクセスリストによって行うことができます。）
src_v6 = 2002:1234:5678::aaaa (forged) dst_v6 = 2002:0800:0002::bbbb src_v4 = 8.0.0.1 (added when encapsulated to IPv4) dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)
src_v6 = 2002：1234：5678 :: AAAA（鍛造）dst_v6 = 2002：0800：0002 :: BBBB src_v4 = 8.0.0.1（追加のIPv4にカプセル化された場合）dst_v4 = 8.0.0.2（追加のIPv4にカプセル化された場合）
A similar attack with "src" being the native address is made possible, even with the security checks, by having the sender node pretend to be a 6to4 relay router.
「SRC」は、天然のアドレスであることと同様の攻撃は、6to4リレールータのふりをしてもセキュリティチェックで、送信側ノードを持つことによって、可能になります。
More worries come into the picture if, e.g.,
より多くの悩みは、例えば、場合映像に入って来ます、
src_v6 = ::ffff:[some trusted IPv4 in a private network] src_v6/dst_v6 = ::ffff:127.0.0.1 src_v6/dst_v6 = ::1 src_v6/dst_v6 = ...
src_v6 = :: FFFF：[プライベートネットワーク内のいくつかの信頼できるのIPv4] src_v6 / dst_v6 = :: FFFF：127.0.0.1 src_v6 / dst_v6 = :: 1 src_v6 / dst_v6 = ...
Some implementations might have been careful enough to design the stack so as to avoid the incoming (or reply) packets going to IPv4 packet processing through special addresses (e.g., IPv4-mapped addresses), but who can say for all ...
一部の実装では、特殊なアドレス（例えば、IPv4マップアドレス）を介してIPv4パケットの処理に行くの着信（または応答）パケットを避けるためにスタックを設計するために十分気をつけていたかもしれませんが、すべてのために言うことができる人...
Authors' Addresses
著者のアドレス
Pekka Savola CSC/FUNET Espoo Finland
ペッカSavola CSC / FUNETエスポーフィンランド
EMail: psavola@funet.fi
メールアドレス：psavola@funet.fi
Chirayu Patel All Play, No Work 185, Defence Colony Bangalore, Karnataka 560038 India
Chirayuパテルすべてのプレイ、ノーワーク185、防衛コロニーカルナータカ州バンガロール560038インド
Phone: +91-98452-88078 EMail: chirayu@chirayu.org URI: http://www.chirayu.org
電話：+ 91-98452-88078メールアドレス：chirayu@chirayu.org URI：http://www.chirayu.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。