Network Working Group C. Huitema
Request for Comments: 4380 Microsoft
Category: Standards Track February 2006
Teredo: Tunneling IPv6 over UDP
through Network Address Translations (NATs)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays". The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such as "6to4".
ここではUDP上でトンネリングパケットによるIPv6接続を得るために、一の以上のIPv4ネットワークアドレス変換（NATの）後ろに位置するノードをできるサービスを提案しています。私たちは、Teredoサービスこれを呼び出します。サービスを実行すると、「Teredoサーバー」と「のTeredoリレー」の助けを必要とします。 Teredoサーバーはステートレスであり、唯一のTeredoクライアント間のトラフィックのごく一部を管理しなければなりません。 TeredoリレーはTeredoサービスと「ネイティブ」のIPv6インターネットとの間のIPv6ルータとして機能します。リレーはまた、「6to4の」などの他の移行メカニズムを使用してホストとの相互運用性を提供することができます。
Table of Contents
目次
1. Introduction ....................................................3
2. Definitions .....................................................4
2.1. Teredo Service .............................................4
2.2. Teredo Client ..............................................4
2.3. Teredo Server ..............................................4
2.4. Teredo Relay ...............................................4
2.5. Teredo IPv6 Service Prefix .................................4
2.6. Global Teredo IPv6 Service Prefix ..........................4
2.7. Teredo UDP Port ............................................4
2.8. Teredo Bubble ..............................................4
2.9. Teredo Service Port ........................................5
2.10. Teredo Server Address .....................................5
2.11. Teredo Mapped Address and Teredo Mapped Port ..............5
2.12. Teredo IPv6 Client Prefix .................................5
2.13. Teredo Node Identifier ....................................5
2.14. Teredo IPv6 Address .......................................5
2.15. Teredo Refresh Interval ...................................5
2.16. Teredo Secondary Port .....................................6
2.17. Teredo IPv4 Discovery Address .............................6
3. Design Goals, Requirements, and Model of Operation ..............6
3.1. Hypotheses about NAT Behavior ..............................6
3.2. IPv6 Provider of Last Resort ...............................8
3.3. Operational Requirements ...................................9
3.4. Model of Operation ........................................10
4. Teredo Addresses ...............................................11
5. Specification of Clients, Servers, and Relays ..................13
5.1. Message Formats ...........................................13
5.2. Teredo Client Specification ...............................16
5.3. Teredo Server Specification ...............................31
5.4. Teredo Relay Specification ................................33
5.5. Implementation of Automatic Sunset ........................36
6. Further Study, Use of Teredo to Implement a Tunnel Service .....37
7. Security Considerations ........................................38
7.1. Opening a Hole in the NAT .................................38
7.2. Using the Teredo Service for a Man-in-the-Middle Attack ...39
7.3. Denial of the Teredo service ..............................42
7.4. Denial of Service against Non-Teredo Nodes ................43
8. IAB Considerations .............................................46
8.1. Problem Definition ........................................46
8.2. Exit Strategy .............................................47
8.3. Brittleness Introduced by Teredo ..........................48
8.4. Requirements for a Long-Term Solution .....................50
9. IANA Considerations ............................................50
10. Acknowledgements ..............................................50
11. References ....................................................51
11.1. Normative References .....................................51
11.2. Informative References ...................................52
Classic tunneling methods envisaged for IPv6 transition operate by sending IPv6 packets as payload of IPv4 packets; the 6to4 proposal [RFC3056] proposes automatic discovery in this context. A problem with these methods is that they don't work when the IPv6 candidate node is isolated behind a Network Address Translator (NAT) device: NATs are typically not programmed to allow the transmission of arbitrary payload types; even when they are, the local address cannot be used in a 6to4 scheme. 6to4 will work with a NAT if the NAT and 6to4 router functions are in the same box; we want to cover the relatively frequent case when the NAT cannot be readily upgraded to provide a 6to4 router function.
IPv6への移行のために想定される古典的なトンネリング方法は、IPv4パケットのペイロードとしてIPv6パケットを送信することによって動作します。 6to4の提案[RFC3056]は、この文脈で自動検出を提案しています。これらの方法の問題点は、IPv6の候補ノードがネットワークアドレス変換器（NAT）デバイスの背後に隔離されているとき、彼らは動作しないということです：NATのは、一般的に、任意のペイロードタイプの送信を許可するようにプログラムされていません。彼らは場合でも、ローカルアドレスは、6to4スキームで使用することはできません。 NATと6to4ルータ機能は、同じボックスにある場合の6to4 NATで動作します。私たちは、NATが容易に6to4ルーター機能を提供するためにアップグレードすることができない場合に、比較的頻繁にケースをカバーしたいです。
A possible way to solve the problem is to rely on a set of "tunnel brokers". However, there are limits to any solution that is based on such brokers: the quality of service may be limited, since the traffic follows a dogleg route from the source to the broker and then the destination; the broker has to provide sufficient transmission capacity to relay all packets and thus suffers a high cost. For these two reasons, it may be desirable to have solutions that allow for "automatic tunneling", i.e., let the packets follow a direct path to the destination.
この問題を解決するための可能な方法は、「トンネルブローカー」のセットに依存することです。しかしながら、このようなブローカーに基づいているすべてのソリューションには限界がある：トラフィックは、ブローカ、その後ソースから宛先へドッグレッグ経路をたどるので、サービスの質は、限定されてもよいです。ブローカーはすべてのパケットを中継するのに十分な伝送容量を提供しなければならないので、高いコストを被ります。これらの二つの理由から、すなわち、パケットが宛先への直接経路をたどるせ、「自動トンネリング」を可能にするソリューションを有することが望ましいです。
The automatic tunneling requirement is indeed at odds with some of the specificities of NATs. Establishing a direct path supposes that the IPv6 candidate node can retrieve a "globally routable" address that results from the translation of its local address by one or more NATs; it also supposes that we can find a way to bypass the various "per destination protections" that many NATs implement. In this memo, we will explain how IPv6 candidates located behind NATs use "Teredo servers" to learn their "global address" and to obtain connectivity, how they exchange packets with native IPv6 hosts through "Teredo relays", and how clients, servers, and relays can be organized in Teredo networks.
自動トンネリング要件は、NATをの特異性の一部と対立し、確かです。ダイレクトパスを確立することは、IPv6の候補ノードが1つまたは複数のNATによってそのローカルアドレスの変換の結果で、「グローバルにルーティング可能な」アドレスを取得できることを想定します。それはまた、我々は多くのNATを実装することを、様々な「宛先ごとの保護」を回避する方法を見つけることができ想定します。このメモでは、私たちは「のTeredoリレー」を通じてホストし、どのようにクライアント、サーバ、彼らはネイティブIPv6のパケットを交換するか、NATの後方のIPv6候補者が彼らの「グローバルアドレス」を学ぶために、接続を取得するために、「Teredoサーバー」を使用する方法を説明しますリレーで、Teredoネットワークで編成することができます。
The specification is organized as follows. Section 2 contains the definition of the terms used in the memo. Section 3 presents the hypotheses on NAT behavior used in the design, as well as the operational requirements that the design should meet. Section 4 presents the IPv6 address format used by Teredo. Section 5 contains the format of the messages and the specification of the protocol. Section 6 presents guidelines for further work on configured tunnels that would be complementary to the current approach. Section 7 contains a security discussion, section 8 contains a discussion of the Unilateral Self Address Fixing (UNSAF) issues, and section 9 contains IANA considerations.
次のように仕様が編成されています。第2節では、メモで使用される用語の定義が含まれています。第3節では、デザインが満たす必要があり、設計で使用されるNAT行動上の仮説だけでなく、運用要件を提示します。第4節で、Teredoで使用されるIPv6アドレスの形式を提示します。第5節では、メッセージのフォーマットとプロトコルの仕様が含まれています。第6節は、現在のアプローチを補完だろう構成されたトンネルのさらなる作業のためのガイドラインを示します。第7節では、セキュリティの議論は、セクション8は片側自己アドレス固定（UNSAF）問題の議論が含まれている含まれており、セクション9は、IANAの考慮事項が含まれています。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This specification uses the following definitions:
この仕様は、次の定義を使用します。
The transmission of IPv6 packets over UDP, as defined in this memo.
このメモで定義されたUDP、上のIPv6パケットの送信。
A node that has some access to the IPv4 Internet and wants to gain access to the IPv6 Internet.
IPv4インターネットへのいくつかのアクセスを持っており、IPv6インターネットへのアクセスを得るために望んでいるノード。
A node that has access to the IPv4 Internet through a globally routable address, and is used as a helper to provide IPv6 connectivity to Teredo clients.
グローバルにルーティング可能なアドレスを使用してIPv4インターネットへのアクセスを持ち、TeredoクライアントへのIPv6接続を提供するために、ヘルパーとして使用されているノード。
An IPv6 router that can receive traffic destined to Teredo clients and forward it using the Teredo service.
Teredoクライアント宛のトラフィックを受信し、Teredoサービスを使用して、それを転送することができIPv6ルーター。
An IPv6 addressing prefix that is used to construct the IPv6 address of Teredo clients.
TeredoクライアントのIPv6アドレスを構築するために使用されたIPv6アドレス指定の接頭辞。
An IPv6 addressing prefix whose value is 2001:0000:/32.
0000：：/ 32値がIPv6のアドレス指定のプレフィックスは2001です。
The UDP port number at which Teredo servers are waiting for packets. The value of this port is 3544.
Teredoサーバーがパケットを待っている時にUDPポート番号。このポートの値は3544です。
A Teredo bubble is a minimal IPv6 packet, made of an IPv6 header and a null payload. The payload type is set to 59, No Next Header, as per [RFC2460]. The Teredo clients and relays may send bubbles in order to create a mapping in a NAT.
Teredoバブルは、IPv6ヘッダとヌルペイロードからなる、最小のIPv6パケットです。ペイロードタイプが59に設定されている、いいえ次にヘッダ、[RFC2460]の通り。 TeredoクライアントとリレーはNATにマッピングを作成するために、気泡を送信してもよいです。
The port from which the Teredo client sends Teredo packets. This port is attached to one of the client's IPv4 addresses. The IPv4 address may or may not be globally routable, as the client may be located behind one or more NAT.
TeredoクライアントからTeredoパケットを送信するポート。このポートは、クライアントのIPv4アドレスの1つに装着されています。クライアントは、1つまたは複数のNATの背後に配置することができるようIPv4アドレスは、または、グローバルにルーティング可能であってもなくてもよいです。
The IPv4 address of the Teredo server selected by a particular client.
特定のクライアントが選択したTeredoサーバーのIPv4アドレス。
A global IPv4 address and a UDP port that results from the translation of the IPv4 address and UDP port of a client's Teredo service port by one or more NATs. The client learns these values through the Teredo protocol described in this memo.
グローバルIPv4アドレスと1つのまたは複数のNATによってクライアントのTeredoサービスポートのIPv4アドレスとUDPポートの翻訳から得られるUDPポート。クライアントは、このメモで説明するのTeredoプロトコルを介してこれらの値を学習します。
A global scope IPv6 prefix composed of the Teredo IPv6 service prefix and the Teredo server address.
TeredoのIPv6サービスプレフィックスとTeredoサーバーアドレスで構成されるグローバルスコープのIPv6プレフィックス。
A 64-bit identifier that contains the UDP port and IPv4 address at which a client can be reached through the Teredo service, as well as a flag indicating the type of NAT through which the client accesses the IPv4 Internet.
クライアントはTeredoサービスを介して到達可能なUDPポートとIPv4アドレスを含む64ビットの識別子、ならびにクライアントがIPv4インターネットへのアクセスに使用するNATのタイプを示すフラグ。
A Teredo IPv6 address obtained by combining a Teredo IPv6 client prefix and a Teredo node identifier.
TeredoのIPv6アドレスのTeredo IPv6クライアントプレフィックスとTeredoノード識別子を組み合わせることによって得られます。
The interval during which a Teredo IPv6 address is expected to remain valid in the absence of "refresh" traffic. For a client located behind a NAT, the interval depends on configuration parameters of the local NAT, or the combination of NATs in the path to the Teredo server. By default, clients assume an interval value of 30 seconds; a longer value may be determined by local tests, as described in section 5.
TeredoのIPv6アドレスが「リフレッシュ」トラフィックが存在しない場合に有効なままと予想される間隔。 NATの背後にあるクライアントの場合、間隔は設定ローカルNATのパラメータ、またはTeredoサーバーへのパスでのNATの組み合わせに依存します。デフォルトでは、クライアントは、30秒の間隔の値を取ります。セクション5に記載されているように、より長い値は、ローカル試験によって決定することができます。
A UDP port used to send or receive packets in order to determine the appropriate value of the refresh interval, but not used to carry any Teredo traffic.
UDPポートは、リフレッシュ間隔の適切な値を決定するために、パケットを送信または受信するために使用されるが、任意のTeredoトラフィックを運ぶために使用されていません。
An IPv4 multicast address used to discover other Teredo clients on the same IPv4 subnet. The value of this address is 224.0.0.253.
IPv4マルチキャストアドレスが同じIPv4サブネット上の他のTeredoクライアントを発見するために使用します。このアドレスの値は224.0.0.253です。
The proposed solution transports IPv6 packets as the payload of UDP packets. This is based on the observation that TCP and UDP are the only protocols guaranteed to cross the majority of NAT devices. Tunneling packets over TCP would be possible, but would result in a poor quality of service; encapsulation over UDP is a better choice.
提案された解決策は、UDPパケットのペイロードとしてIPv6パケットを転送します。これは、TCPとUDPは、NATデバイスの大部分を横切るように保証のみのプロトコルであることを観察に基づいています。 TCP上のトンネリングパケットは可能でしょうが、サービスの質の悪いことになります。 UDP上のカプセル化は、より良い選択です。
The design of our solution is based on a set of hypotheses and observations on the behavior of NATs, our desire to provide an "IPv6 provider of last resort", and a list of operational requirements. It results in a model of operation in which the Teredo service is enabled by a set of servers and relays.
当社のソリューションの設計はNATのの行動上の仮説と観測値のセットに基づいており、私たちの願いは、「最後のIPv6のプロバイダ」、および運用要件のリストを提供します。これは、Teredoサービスは、サーバおよびリレーのセットで有効にされる動作のモデルになります。
NAT devices typically incorporate some support for UDP, in order to enable users in the natted domain to use UDP-based applications. The NAT will typically allocate a "mapping" when it sees a UDP packet coming through for which there is not yet an existing mapping. The handling of UDP "sessions" by NAT devices differs by two important parameters, the type and the duration of the mappings.
NATデバイスは、通常、UDPベースのアプリケーションを使用するnattedドメイン内のユーザーを有効にするために、UDPのためのいくつかのサポートを組み込みます。 NATは、一般的に、それは既存のマッピングがまだ存在しないとするための貫通くるUDPパケットを見て、「マッピング」を割り当てます。 NATデバイスによるUDP「セッション」の取り扱いは、2つの重要なパラメータ、タイプおよびマッピングの期間によって異なります。
The type of mappings is analyzed in [RFC3489], which distinguishes between "cone NAT", "restricted cone NAT", "port restricted cone NAT" and "symmetric NAT". The Teredo solution ensures connectivity for clients located behind cone NATs, restricted cone NATs, or port-restricted cone NATs.
マッピングのタイプは、「ポート制限付きコーンNAT」と「対称型NAT」、「コーンNAT」を区別する[RFC3489]、「制限付きコーンNAT」で分析されます。 Teredoのソリューションは、コーンNATを、制限された円錐のNAT、またはポート制限コーンNATの後方のクライアントの接続が保証されます。
Transmission of regular IPv6 packets only takes place after an exchange of "bubbles" between the parties. This exchange would often fail for clients behind symmetric NAT, because their peer cannot predict the UDP port number that the NAT expects.
通常のIPv6パケットの送信は唯一の政党間の「泡」の交換の後に行われます。そのピアがNATが期待するUDPポート番号を予測できないため、この交換は、多くの場合、対称型NATの背後のクライアントのために失敗します。
Clients located behind a symmetric NAT will only be able to use Teredo if they can somehow program the NAT and reserve a Teredo service port for each client, for example, using the DMZ functions of the NAT. This is obviously an onerous requirement, at odds with the design goal of an automatic solution. However, measurement campaigns and studies of documentations have shown that, at least in simple "unmanaged" networks, symmetric NATs are a small minority; moreover, it seems that new NAT models or firmware upgrades avoid the "symmetric" design.
対称型NATの背後にあるクライアントは、彼らだけは何とかNATのDMZ機能を使用して、NATをプログラムし、例えば、各クライアントのTeredoサービスポートを予約することができた場合のTeredoを使用することができます。これは、自動ソリューションの設計目標と対立し、明らかに面倒な要件です。しかし、測定キャンペーンおよびドキュメンテーションの研究は、少なくとも、単純な「非管理」のネットワークでは、対称型NATのは少数派であることが示されています。しかも、新しいNATモデルやファームウェアのアップグレードは、「対称」のデザインを避けているようです。
Investigations on the performance of [RFC3489] have shown the relative frequency of a particular NAT design, which we might call "port conserving". In this design, the NAT tries to keep the same port number inside and outside, unless the "outside" port number is already in use for another mapping with the same host. Port conserving NAT appear as "cone" or "restricted cone NAT" most of the time, but they will behave as "symmetric NAT" when multiple internal hosts use the same port number to communicate to the same server.
[RFC3489]の性能に関する研究は、私たちが「ポート節約」と呼ぶかもしれない特定のNATの設計、の相対頻度を示しています。この設計では、NATは、「外部」ポート番号が同じホストで別のマッピングのために既に使用されている場合を除き、内側と外側に同じポート番号を維持しようとします。 NATを節約ポートは、「コーン」または「制限付きコーンNAT」ほとんどの時間として表示されますが、複数の内部ホストが同じサーバーとの通信に同じポート番号を使用するときには、「対称型NAT」として動作します。
The Teredo design minimizes the risk of encountering the "symmetric" behavior by asking multiple hosts located behind the same NAT to use different Teredo service ports.
Teredoのデザインは異なるTeredoサービスポートを使用するには、同じNATの背後にある複数のホストを尋ねることによって、「対称」行動に遭遇するリスクを最小限に抑えることができます。
Other investigation in the behavior of NAT also outlined the "probabilistic rewrite" behavior. Some brands of NAT will examine all packets for "embedded addresses", IP addresses, and port numbers present in application payloads. They will systematically replace 32-bit values that match a local address by the corresponding mapped address. The Teredo specification includes an "obfuscation" procedure in order to avoid this behavior.
NATの動作の他の調査はまた、「確率論リライト」行動を概説しました。 NATのいくつかのブランドは、「埋め込まれたアドレス」、IPアドレス、およびアプリケーションのペイロードに存在するポート番号のすべてのパケットを検査します。彼らは系統的対応するマッピングされたアドレスによりローカルアドレスと一致する32ビット値に置き換えられます。 Teredoの仕様では、この動作を回避するために、「難読化」の手順を含んでいます。
Regardless of their types, UDP mappings are not kept forever. The typical algorithm is to remove the mapping if no traffic is observed on the specified port for a "lifetime" period. The Teredo client that wants to maintain a mapping open in the NAT will have to send some "keep alive" traffic before the lifetime expires. For that, it needs an estimate of the "lifetime" parameter used in the NAT. We observed that the implementation of lifetime control can vary in several ways.
かかわらず、その種類の、UDPマッピングは永久に保持されていません。典型的なアルゴリズムは、トラフィックが「寿命」の期間に指定されたポート上で観察されない場合は、マッピングを削除することです。 NATで開いマッピングを維持しようとTeredoクライアントは、寿命が切れる前に、いくつかのトラフィック「キープアライブ」送信する必要があります。そのために、それはNATで使用される「寿命」パラメータの推定値を必要とします。私たちは、ライフタイムコントロールの実装はいくつかの方法を変えることができることを観察しました。
Most NATs implement a "minimum lifetime", which is set as a parameter of the implementation. Our observations of various boxes showed that this parameter can vary between about 45 seconds and several minutes.
ほとんどのNATは、実装のパラメータとして設定されている「最小寿命」を実装します。様々な箱の我々の観察は、このパラメータは、約45秒から数分の間で変えることができることを示しました。
In many NATs, mappings can be kept for a duration that exceeds this minimum, even in the absence of traffic. We suspect that many implementation perform "garbage collection" of unused mappings on special events, e.g., when the overall number of mappings exceeds some limit.
多くのNATでは、マッピングはさえトラフィックが存在しない場合に、この最小値を超える期間に保つことができます。私たちは、マッピングの全体数は、いくつかの制限を超えたときに、多くの実装では、特別なイベント、例えば、上の未使用のマッピングの「ガベージコレクション」を実行すると思われます。
In some cases, e.g., NATs that manage Integrated Services Digital Network (ISDN) or dial-up connections, the mappings will be released when the connection is released, i.e., when no traffic is observed on the connection for a period of a few minutes.
いくつかのケースでは、例えば、総合デジタル通信網（ISDN）またはダイヤルアップ接続を管理するNAT接続が解放されたときにトラフィックが数分間接続上で観察されていない場合、マッピングは、すなわち、リリースされます。
Any algorithm used to estimate the lifetime of mapping will have to be robust against these variations.
マッピングの寿命を推定するために使用されるすべてのアルゴリズムは、これらの変動に対して堅牢でなければならないだろう。
In some cases, clients are located behind multiple NAT. The Teredo procedures will ensure communications between clients between multiple NATs and clients "on the other side" of these NATs. They will also ensure communication when clients are located in a single subnet behind the same NAT.
いくつかのケースでは、クライアントは複数のNATの背後に配置されています。 Teredoの手順は、これらのNATの「向こう側の」複数のNATとクライアント間のクライアント間の通信を確保します。クライアントが同じNATの背後にある単一のサブネットに配置されているとき、彼らはまた、通信を確保します。
The procedures do not make any hypothesis about the type of IPv4 address used behind a NAT, and in particular do not assume that these are private addresses defined in [RFC1918].
手順は、NATの背後に使用されたIPv4アドレスの種類についての仮説を作らない、特にこれらは、[RFC1918]で定義されたプライベートアドレスであることを前提としていません。
Teredo is designed to provide an "IPv6 access of last resort" to nodes that need IPv6 connectivity but cannot use any of the other IPv6 transition schemes. This design objective has several consequences on when to use Teredo, how to program clients, and what to expect of servers. Another consequence is that we expect to see a point in time at which the Teredo technology ceases to be used.
Teredoのは、IPv6接続を必要とするが、他のIPv6移行スキームのいずれかを使用することはできませんノードへの「最後のIPv6のアクセス」を提供するように設計されています。この設計の目的は、クライアントをプログラムして、サーバーで何を期待するか、のTeredoを使用する際にいくつかの結果をもたらします。他の結果は、我々はTeredoの技術が使用されなくなるた時点を見ることを期待しているです。
Teredo is designed to robustly enable IPv6 traffic through NATs, and the price of robustness is a reasonable amount of overhead, due to UDP encapsulation and transmission of bubbles. Nodes that want to connect to the IPv6 Internet SHOULD only use the Teredo service as a "last resort" option: they SHOULD prefer using direct IPv6 connectivity if it is locally available, if it is provided by a 6to4 router co-located with the local NAT, or if it is provided by a configured tunnel service; and they SHOULD prefer using the less onerous 6to4 encapsulation if they can use a global IPv4 address.
Teredoのは確実にNATを経由IPv6トラフィックを有効にするために設計されており、堅牢性の価格が原因UDPカプセル化と気泡の送信に、オーバーヘッドの合理的な金額です。 IPv6インターネットに接続するノードは唯一の「最後の手段」のオプションとしてTeredoサービスを使用する必要があります。それはローカルと同じ場所に配置6to4ルーターによって提供されている場合、それは、ローカルで利用可能な場合、それらは、直接IPv6接続を使用して好むべきですNAT、またはそれが設定されたトンネルサービスによって提供される場合、彼らはグローバルIPv4アドレスを使用することができれば、彼らは負担の少ない6to4のカプセル化を使用して好むべきです。
In an IPv6-enabled network, the IPv6 service is configured automatically, by using mechanisms such as IPv6 Stateless Address Autoconfiguration [RFC2462] and Neighbor Discovery [RFC2461]. A design objective is to configure the Teredo service as automatically as possible. In practice, however, it is required that the client learn the IPv4 address of a server that is willing to serve the client; some servers may also require some form of access control.
IPv6対応ネットワークでは、IPv6サービスは、IPv6のステートレスアドレス自動設定[RFC2462]と近隣探索[RFC2461]などのメカニズムを使用して、自動的に構成されています。設計目標は、可能な限り自動的Teredoサービスを設定することです。しかし実際には、クライアントは、クライアントにサービスを提供していく所存ですサーバーのIPv4アドレスを学習することが必要とされます。いくつかのサーバは、アクセス制御のいくつかのフォームを必要とするかもしれません。
During the peak of the transition, there will be a requirement to deploy Teredo servers supporting a large number of Teredo clients. Minimizing the load on the server is a good way to facilitate this deployment. To achieve this goal, servers should be as stateless as possible, and they should also not be required to carry any more traffic than necessary. To achieve this objective, we require only that servers enable the packet exchange between clients, but we don't require servers to carry the actual data packets: these packets will have to be exchanged directly between the Teredo clients, or through a destination-selected relay for exchanges between Teredo clients and other IPv6 clients.
トランジションのピーク時には、Teredoクライアントの大規模な数をサポートするのTeredoサーバーを展開する必要があるでしょう。サーバーの負荷を最小限に抑えることにより、この展開を容易にするための良い方法です。この目標を達成するために、サーバは、可能な限りステートレスであるべきであり、彼らはまた、必要以上に多くのトラフィックを運ぶために必要とするべきではありません。この目的を達成するために、我々は、サーバがクライアント間のパケット交換を可能にすることだけが必要ですが、私たちは、実際のデータパケットを運ぶためにサーバを必要としない：これらのパケットはTeredoクライアント間、または先に選択して直接交換する必要がありますTeredoクライアントと他のIPv6クライアント間の交流のために中継します。
Teredo is meant as a short-term solution to the specific problem of providing IPv6 service to nodes located behind a NAT. The problem is expected to be resolved over time by transforming the "IPv4 NAT" into an "IPv6 router". This can be done in one of two ways: upgrading the NAT to provide 6to4 functions or upgrading the Internet connection used by the NAT to a native IPv6 service, and then adding IPv6 router functionality in the NAT. In either case, the former NAT can present itself as an IPv6 router to the systems behind it. These systems will start receiving the "router advertisements"; they will notice that they have IPv6 connectivity and will stop using Teredo.
Teredoのは、NATの背後にあるノードにIPv6サービスを提供する特定の問題への短期的な解決策として意図されています。問題は、「IPv6ルータ」に「IPv4のNAT」を変換することにより、時間をかけて解決することが期待されています。 6to4の機能を提供するために、NATをアップグレードするか、ネイティブIPv6サービスにNATが使用するインターネット接続をアップグレードした後、NATでのIPv6ルーター機能を追加：これは、2つの方法のいずれかで行うことができます。いずれの場合も、元NATは、その背後にあるシステムへのIPv6ルータとしての地位を提示することができます。これらのシステムは、「ルータ広告」を受信を開始します。彼らはIPv6接続を持っているとのTeredoの使用を停止することがわかります。
The Teredo service is designed primarily for robustness: packets are carried over UDP in order to cross as many NAT implementations as possible. The servers are designed to be stateless, which means that they can easily be replicated. We expect indeed to find many such servers replicated at multiple Internet locations.
Teredoサービスは、主に、堅牢性のために設計されています。パケットは、できるだけ多くのNATの実装を横断するために、UDP上で実行されています。サーバは、彼らは簡単に複製することができることを意味し、ステートレスになるように設計されています。私たちは、実際に複数のインターネットの場所に複製し、多くのそのようなサーバを見つけることを期待しています。
The service requires the support of Teredo servers and Teredo relays. In order to facilitate the deployment of these servers and relays, the Teredo procedures are designed to minimize the amount of coordination required between servers and relays.
サービスは、TeredoサーバーとのTeredoリレーのサポートが必要です。これらのサーバおよびリレーの展開を容易にするために、Teredoの手順は、サーバーとリレーの間で必要な調整の量を最小限に抑えるように設計されています。
Meeting this objective implies that the Teredo addresses will incorporate the IPv4 address and UDP port through which a Teredo client can be reached. This creates an implicit limit on the stability of the Teredo addresses, which can only remain valid as long as the underlying IPv4 address and UDP port remain valid.
この目的を満たすことのTeredoアドレスはTeredoクライアントに到達できるIPv4アドレスとUDPポートを組み込むことを意味します。これは、基礎となるIPv4アドレスとUDPポート限りは有効のままとしてのみ有効であり続けることができますのTeredoアドレスの安定性に暗黙の制限を作成します。
The Teredo clients obtain mapped addresses and ports from the Teredo servers. The service must be protected against denial of service attacks in which a third party spoofs a Teredo server and sends improper information to the client.
Teredoクライアントは、Teredoサーバーからマップされたアドレスとポートを取得します。サービスは、第三者がTeredoサーバーを偽装して、クライアントに不適切な情報を送信するサービス拒否攻撃から保護されなければなりません。
Teredo relays will act as a relay for IPv6 packets. Improperly designed packet relays can be used by denial of service attackers to hide their address, making the attack untraceable. The Teredo service must include adequate protection against such misuse.
Teredoリレーは、IPv6パケットのリレーとして機能します。不適切な設計のパケットリレーは、攻撃が追跡不可能作り、自分のアドレスを隠すために、サービス攻撃の拒否によって使用することができます。 Teredoサービスは、このような誤用に対する適切な保護を含める必要があります。
Routers may perform ingress filtering by checking that the source address of the packets received on a given interface is "legitimate", i.e., belongs to network prefixes from which traffic is expected at a network interface. Ingress filtering is a recommended practice, as it thwarts the use of forged source IP addresses by malfeasant hackers, notably to cover their tracks during denial of service attacks. The Teredo specification must not force networks to disable ingress filtering.
ルータは、特定のインターフェイス上で受信されたパケットの送信元アドレスが「正当」であることをチェックすることによって、イングレスフィルタリングを実行することができる、すなわち、トラフィックがネットワークインターフェイスから予想されたプレフィックスをネットワークに属します。それは、特にサービス拒否攻撃の際に自分の曲をカバーするために、malfeasantハッカーによる偽造送信元IPアドレスの使用を阻止してイングレスフィルタリングは、お勧めです。 Teredoの仕様は、入力フィルタリングを無効にするには、ネットワークを強制してはいけません。
The operation of Teredo involves four types of nodes: Teredo clients, Teredo servers, Teredo relays, and "plain" IPv6 nodes.
Teredoクライアント、Teredoサーバー、のTeredoリレー、および「プレーン」のIPv6ノード：Teredoの操作は、ノードの4種類を必要とします。
Teredo clients start operation by interacting with a Teredo server, performing a "qualification procedure". During this procedure, the client will discover whether it is behind a cone, restricted cone, or symmetric NAT. If the client is not located behind a symmetric NAT, the procedure will be successful and the client will configure a "Teredo address".
Teredoクライアントは、「資格の手続き」を行って、Teredoサーバーと相互作用することによって操作を開始します。この手順の間、クライアントは、コーン、制限付きコーン、または対称NATの背後にあるかどうかを発見するでしょう。クライアントが対称型NATの後ろに位置されていない場合は、手順が成功すると、クライアントは、「Teredoアドレス」を設定します。
The Teredo IPv6 address embeds the "mapped address and port" through which the client can receive IPv4/UDP packets encapsulating IPv6 packets. If the client is not located behind a cone NAT, transmission of regular IPv6 packets must be preceded by an exchange of "bubbles" that will install a mapping in the NAT. This document specifies how the bubbles can be exchanged between Teredo clients in order to enable transmission along a direct path.
TeredoのIPv6アドレスは、クライアントがIPv6パケットをカプセル化したIPv4 / UDPパケットを受け取ることができ、それを通して、「マッピングされたアドレスとポートを」埋め込みます。クライアントがcone NATの内側に配置されていない場合は、通常のIPv6パケットの伝送は、NATでマッピングをインストールします「泡」のやり取りが先行されなければなりません。この文書では、気泡が直接経路に沿って伝送を可能にするために、Teredoクライアント間で交換することができるかを指定します。
Teredo clients can exchange IPv6 packets with plain IPv6 nodes (e.g., native nodes or 6to4 nodes) through Teredo relays. Teredo relays advertise reachability of the Teredo prefix to a certain subset of the IPv6 Internet: a relay set up by an ISP will typically serve only the IPv6 customers of this ISP; a relay set-up for a site will only serve the IPv6 hosts of this site. Dual-stack hosts may implement a "local relay", allowing them to communicate directly with Teredo hosts by sending IPv6 packets over UDP and IPv4 without having to advertise a Teredo IPv6 address.
TeredoクライアントからTeredoリレーを介して普通のIPv6ノード（例えば、天然のノードまたはノードの6to4）とIPv6パケットを交換することができます。 Teredoリレーは、IPv6インターネットの特定のサブセットにTeredoのプレフィックスの到達可能性を広告：ISPによって設定されたリレーは、一般的に、このISPのIPv6のみの顧客にサービスを提供します。サイトのリレーのセットアップは、このサイトのIPv6ホストにサービスを提供します。デュアルスタックホストはそれらのTeredo IPv6アドレスをアドバタイズすることなく、UDPとIPv4上にIPv6パケットを送信することによってのTeredoホストと直接通信することを可能にする、「ローカルリレー」を実施することができます。
Teredo clients have to discover the relay that is closest to each native IPv6 or 6to4 peer. They have to perform this discovery for each native IPv6 or 6to4 peer with which they communicate. In order to prevent spoofing, the Teredo clients perform a relay discovery procedure by sending an ICMP echo request to the native host. This message is a regularly formatted IPv6 ICMP packet, which is encapsulated in UDP and sent by the client to its Teredo server; the server decapsulates the IPv6 message and forwards it to the intended IPv6 destination. The payload of the echo request contains a large random number. The echo reply is sent by the peer to the IPv6 address of the client, and is forwarded through standard IPv6 routing mechanisms. It will naturally reach the Teredo relay closest to the native or 6to4 peer, and will be forwarded by this relay using the Teredo mechanisms. The Teredo client will discover the IPv4 address and UDP port used by the relay to send the echo reply, and will send further IPv6 packets to the peer by encapsulating them in UDP packets sent to this IPv4 address and port. In order to prevent spoofing, the Teredo client verifies that the payload of the echo reply contains the proper random number.
Teredoクライアントは、それぞれのネイティブIPv6または6to4のピアに最も近いリレーを発見しなければなりません。彼らは、彼らが通信する各ネイティブIPv6または6to4のピアのために、この発見を実行する必要があります。なりすましを防ぐために、Teredoクライアントは、ネイティブホストにICMPエコー要求を送信することにより、リレー発見手順を実行します。このメッセージはUDPでカプセル化し、そのTeredoサーバーにクライアントによって送信され、定期的にフォーマットされたIPv6 ICMPパケット、です。サーバーは、IPv6メッセージのカプセル化を解除し、意図したIPv6宛先に転送します。エコー要求のペイロードは、大きな乱数が含まれています。エコー応答は、クライアントのIPv6アドレスにピアによって送信され、標準IPv6ルーティングメカニズムを介して転送されます。それは当然のTeredoがネイティブまたは6to4のピアに最も近いリレー達し、Teredoのメカニズムを使用して、このリレーで転送されます。 Teredoクライアントは、エコー応答を送信するためにリレーが使用するIPv4アドレスとUDPポートを発見するでしょうし、このIPv4アドレスとポートに送信されたUDPパケットでそれらをカプセル化することによってピアにさらにIPv6パケットを送信します。なりすましを防ぐために、Teredoクライアントは、エコー応答のペイロードは適切な乱数が含まれていることを確認します。
The procedures are designed so that the Teredo server only participates in the qualification procedure and in the exchange of bubbles and ICMP echo requests. The Teredo server never carries actual data traffic. There are two rationales for this design: reduce the load on the server in order to enable scaling, and avoid privacy issues that could occur if a Teredo server kept copies of the client's data packets.
Teredoサーバーが唯一の資格手続きで、気泡やICMPエコー要求の交換に参加するように手順が設計されています。 Teredoサーバーは、実際のデータトラフィックを運ぶことはありません。スケーリングを有効にし、Teredoサーバーがクライアントのデータパケットのコピーを保管する場合に発生可能性がプライバシーの問題を避けるために、サーバの負荷を軽減：この設計には2つの根拠があります。
The Teredo addresses are composed of 5 components:
Teredoアドレスは5つのコンポーネントで構成されています。
+-------------+-------------+-------+------+-------------+
| Prefix | Server IPv4 | Flags | Port | Client IPv4 |
+-------------+-------------+-------+------+-------------+
- Prefix: the 32-bit Teredo service prefix. - Server IPv4: the IPv4 address of a Teredo server.
- プレフィックス：32ビットのTeredoサービスプレフィックス。 - サーバのIPv4：TeredoサーバーのIPv4アドレス。
- Flags: a set of 16 bits that document type of address and NAT. - Port: the obfuscated "mapped UDP port" of the Teredo service at the client. - Client IPv4: the obfuscated "mapped IPv4 address" of the client.
- フラグ：アドレスとNATの種類を文書化16ビットのセット。 - ポート：クライアントのTeredoサービスの難読化「マッピングされたUDPポート」。 - クライアントのIPv4：クライアントの難読化「マッピングされたIPv4アドレス」。
In this format, both the "mapped UDP port" and "mapped IPv4 address" of the client are obfuscated. Each bit in the address and port number is reversed; this can be done by an exclusive OR of the 16-bit port number with the hexadecimal value 0xFFFF, and an exclusive OR of the 32-bit address with the hexadecimal value 0xFFFFFFFF.
この形式では、両方の「マップされたUDPポート」およびクライアントの「マッピングされたIPv4アドレスは」難読化されています。アドレスとポート番号の各ビットを反転させます。これは、排他的OR進値0xFFFFで、排他的OR進値0xFFFFFFFFの32ビットアドレスの16ビットのポート番号によって行うことができます。
The IPv6 addressing rules specify that "for all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format". This dictates the encoding of the flags, 16 intermediate bits that should correspond to valid values of the most significant 16 bits of a Modified EUI-64 ID:
IPv6のアドレス指定規則は、「すべてのユニキャストアドレスについて、バイナリ値000で始まるものを除いて、インタフェースIDは64ビット長であり、かつ変形EUI-64フォーマットに構築する必要がある」ことを指定します。これは、変形EUI-64 IDの上位16ビットの有効な値に対応すべきフラグ、16中間ビットの符号化を決定します。
0 0 0 1
|0 7 8 5
+----+----+----+----+
|Czzz|zzUG|zzzz|zzzz|
+----+----+----+----+
In this format:
このフォーマットでは：
- The bits "UG" should be set to the value "00", indicating a non-global unicast identifier; - The bit "C" (cone) should be set to 1 if the client believes it is behind a cone NAT, to 0 otherwise; these values determine different server behavior during the qualification procedure, as specified in Section 5.2.1, as well as different bubble processing by clients and relays. - The bits indicated with "z" must be set to zero and ignored on receipt.
- ビット「UG」は、非グローバルユニキャスト識別子を示し、値「00」に設定されるべきです。 - クライアントは、それがそうでなければ0にコーンNATの背後にあると考えている場合はビット「C」（コーン）が1に設定されるべきです。これらの値は、クライアントやリレーにより5.2.1節、ならびに異なるバブル処理で指定され、資格手続きの際に別のサーバの動作を決定します。 - 「Z」で示すビットがゼロに設定され、受信時には無視されなければなりません。
Thus, there are two currently specified values of the Flags field: "0x0000" (all null) if the cone bit is set to 0, and "0x8000" if the cone bit is set to 1. (Further versions of this specification may assign new values to the reserved bits.)
したがって、フラグフィールド二現在指定された値が存在する：コーンビットが1に設定されている場合コーンビットが0に設定されている場合は「0000」（すべてNULL）が、そして「0×8000」（本明細書の別のバージョンは、割り当てることができます予約ビットに新しい値。）
In some cases, Teredo nodes use link-local addresses. These addresses contain a link-local prefix (FE80::/64) and a 64-bit identifier, constructed using the same format as presented above. A difference between link-local addresses and global addresses is that the identifiers used in global addresses MUST include a global scope unicast IPv4 address, while the identifiers used in link-local addresses MAY include a private IPv4 address.
いくつかのケースでは、Teredoのノードは、リンクローカルアドレスを使用します。これらのアドレスがリンクローカルプレフィックス（FE80 :: / 64）と64ビットの識別子を含む、上記のものと同じ形式を使用して構築しました。リンクローカルアドレスとグローバルアドレスとの間の差は、リンクローカルアドレスに使用される識別子は、プライベートIPv4アドレスを含むことがグローバルアドレスに使用される識別子は、グローバルスコープユニキャストIPv4アドレスを含まなければならないことです。
The Teredo service is realized by having clients interact with Teredo servers through the Teredo service protocol. The clients will also receive IPv6 packets through Teredo relays. The client behavior is specified in Section 5.2.
Teredoサービスは、クライアントがTeredoサービスプロトコルを介してTeredoサーバーと対話させることで実現されます。クライアントものTeredoリレー経由でIPv6パケットを受信します。クライアントの動作は、5.2節で指定されています。
The Teredo server is designed to be stateless. It waits for Teredo requests and for IPv6 packets on the Teredo UDP port; it processes the requests by sending a response to the appropriate address and port; it forwards some Teredo IPv6 packets to the appropriate IPv4 address and UDP port, or to native IPv6 peers of Teredo clients. The precise behavior of the server is specified in Section 5.3.
Teredoサーバーはステートレスになるように設計されています。これは、Teredoの要求のためにとのTeredo UDPポート上のIPv6パケットを待ち、それは適切なアドレスとポートへの応答を送信することで要求を処理します。それは、適切なIPv4アドレスとUDPポートへ、またはTeredoクライアントのネイティブIPv6ピアにいくつかのTeredo IPv6パケットを転送します。サーバーの正確な動作は、セクション5.3で指定されています。
The Teredo relay advertises reachability of the Teredo service prefix over IPv6. The scope of advertisement may be the entire Internet or a smaller subset such as an ISP network or an IPv6 site; it may even be as small as a single host in the case of "local relays". The relay forwards Teredo IPv6 packets to the appropriate IPv4 address and UDP port. The relay behavior is specified in Section 5.4.
Teredoリレーは、IPv6経由のTeredoサービスプレフィックスの到達可能性をアドバタイズします。広告の範囲は、インターネット全体またはISPネットワークまたはIPv6サイトなどのより小さなサブセットであってもよいです。それも「地元のリレー」の場合の単一のホストのように小さくすることができます。リレーは、適切なIPv4アドレスとUDPポートへのTeredo IPv6パケットを転送します。リレーの動作は5.4節で指定されています。
Teredo clients, servers, and relays must implement the sunset procedure defined in Section 5.5.
Teredoクライアント、サーバ、およびリレーは、セクション5.5で定義された夕日の手順を実装する必要があります。
Teredo IPv6 packets are transmitted as UDP packets [RFC768] within IPv4 [RFC791]. The source and destination IP addresses and UDP ports take values that are specified in this section. Packets can come in one of two formats, simple encapsulation and encapsulation with origin indication.
TeredoのIPv6パケットは、IPv4の内のUDPパケット[RFC768] [RFC791]として送信されます。送信元と宛先のIPアドレスとUDPポートはこのセクションで指定された値をとります。パケットは二つのフォーマット、原産地表示と簡単なカプセル化とカプセル化の一つに来ることができます。
When simple encapsulation is used, the packet will have a simple format, in which the IPv6 packet is carried as the payload of a UDP datagram:
簡単なカプセル化を使用する場合、パケットは、IPv6パケットがUDPデータグラムのペイロードとして運ばれたシンプルなフォーマットを持っています。
+------+-----+-------------+
| IPv4 | UDP | IPv6 packet |
+------+-----+-------------+
When relaying some packets received from third parties, the server may insert an origin indication in the first bytes of the UDP payload:
第三者から受け取ったいくつかのパケットを中継する場合、サーバは、UDPペイロードの最初のバイトの原点表示を挿入することができます。
+------+-----+-------------------+-------------+
| IPv4 | UDP | Origin indication | IPv6 packet |
+------+-----+-------------------+-------------+
The origin indication encapsulation is an 8-octet element, with the following content:
原点指示カプセル化は、以下の内容で、8オクテットの要素です。
+--------+--------+-----------------+
| 0x00 | 0x00 | Origin port # |
+--------+--------+-----------------+
| Origin IPv4 address |
+-----------------------------------+
The first two octets of the origin indication are set to a null value; this is used to discriminate between the simple encapsulation, in which the first 4 bits of the packet contain the indication of the IPv6 protocol, and the origin indication.
原点指示の最初の2つのオクテットはヌル値に設定されています。これは、パケットの最初の4ビットは、IPv6プロトコルの指示、及び原点指示を含有する単純なカプセル化、区別するために使用されます。
The following 16 bits contain the obfuscated value of the port number from which the packet was received, in network byte order. The next 32 bits contain the obfuscated IPv4 address from which the packet was received, in network byte order. In this format, both the original "IPv4 address" and "UDP port" of the client are obfuscated. Each bit in the address and port number is reversed; this can be done by an exclusive OR of the 16-bit port number with the hexadecimal value 0xFFFF, and an exclusive OR of the 32-bit address with the hexadecimal value 0xFFFFFFFF.
次の16ビットは、パケットがネットワークバイト順に、受信されたポート番号の難読化された値を含みます。次の32ビットは、パケットがネットワークバイト順に、受信された難読化されたIPv4アドレスを含みます。この形式では、オリジナルの「IPv4のアドレス」と、クライアントの「UDPポート」の両方が難読化されています。アドレスとポート番号の各ビットを反転させます。これは、排他的OR進値0xFFFFで、排他的OR進値0xFFFFFFFFの32ビットアドレスの16ビットのポート番号によって行うことができます。
For example, if the original UDP port number was 337 (hexadecimal 0151) and original IPv4 address was 1.2.3.4 (hexadecimal 01020304), the origin indication would contain the value "0000FEAEFEFDFCFB".
例えば、元のUDPポート番号は、337（16進0151）であり、元IPv4アドレスが1.2.3.4（16進数01020304）で、原点指示値「0000FEAEFEFDFCFB」を含むであろう。
When exchanging Router Solicitation (RS) and Router Advertisement (RA) messages between a client and its server, the packets may include an authentication parameter:
クライアントとそのサーバ間のルータ要請（RS）と、ルータ広告（RA）メッセージを交換すると、パケットが認証パラメータを含めることがあります。
+------+-----+----------------+-------------+
| IPv4 | UDP | Authentication | IPv6 packet |
+------+-----+----------------+-------------+
The authentication encapsulation is a variable-length element, containing a client identifier, an authentication value, a nonce value, and a confirmation byte.
認証カプセル化は、クライアント識別子、認証値、ノンス値、及び確認バイトを含む可変長の要素です。
+--------+--------+--------+--------+
| 0x00 | 0x01 | ID-len | AU-len |
+--------+--------+--------+--------+
| Client identifier (ID-len |
+-----------------+-----------------+
| octets) | Authentication |
+-----------------+--------+--------+
| value (AU-len octets) | Nonce |
+--------------------------+--------+
| value (8 octets) |
+--------------------------+--------+
| | Conf. |
+--------------------------+--------+
The first octet of the authentication encapsulation is set to a null value, and the second octet is set to the value 1; this enables differentiation from IPv6 packets and from origin information indication encapsulation. The third octet indicates the length in bytes of the client identifier; the fourth octet indicates the length in bytes of the authentication value. The computation of the authentication value is specified in Section 5.2.2. The authentication value is followed by an 8-octet nonce, and by a confirmation byte.
認証カプセル化の最初のオクテットはヌル値に設定され、第2オクテットは、値1に設定されています。これは、IPv6パケットから、原点情報表示のカプセル化から分化を可能にします。第三のオクテットは、クライアント識別子の長さをバイト単位で示します。 4番目のオクテットは、認証値のバイト単位の長さを示します。認証値の計算は、セクション5.2.2で指定されています。認証値は8オクテットナンスによって、確認バイトが続きます。
Both ID-len and AU-len can be set to null values if the server does not require an explicit authentication of the client.
サーバがクライアントの明示的な認証を必要としない場合はID-LENとAU-LENの両方がnull値に設定することができます。
Authentication and origin indication encapsulations may sometimes be combined, for example, in the RA responses sent by the server. In this case, the authentication encapsulation MUST be the first element in the UDP payload:
認証および原点指示カプセル化は時々サーバから送信されたRAレスポンスに、例えば、組み合わせてもよいです。この場合、認証カプセル化はUDPペイロード内の最初の要素でなければなりません。
+------+-----+----------------+--------+-------------+
| IPv4 | UDP | Authentication | Origin | IPv6 packet |
+------+-----+----------------+--------+-------------+
Since Teredo uses UDP as an underlying transport, a Teredo Maximum Transmission Unit (MTU) could potentially be as large as the payload of the largest valid UDP datagram (65507 bytes). However, since Teredo packets can travel on unpredictable paths over the Internet, it is best to contain this MTU to a small size, in order to minimize the effect of IPv4 packet fragmentation and reassembly. The default link MTU assumed by a host, and the link MTU supplied by a Teredo server during router advertisement SHOULD normally be set to the minimum IPv6 MTU size of 1280 bytes [RFC2460].
Teredoの基礎となるトランスポートとしてUDPを使用するので、Teredoの最大伝送単位（MTU）は、潜在的に有効な最大UDPデータグラム（65507バイト）のペイロードと同じ大きさであってもよいです。 Teredoのパケットがインターネット上で予測不可能なパスに移動することができますので、しかし、それはIPv4パケットの断片化と再構成の影響を最小限に抑えるために、サイズが小さいため、このMTUを含めることをお勧めします。ルータ通知中のTeredoサーバによって供給されるホストが想定デフォルトリンクMTU、リンクMTUは、通常1280バイト[RFC2460]の最小のIPv6 MTUサイズに設定する必要があります。
Teredo implementations SHOULD NOT set the Don't Fragment (DF) bit of the encapsulating IPv4 header.
Teredoの実装はカプセル化IPv4ヘッダーのないフラグメント（DF）ビットを設定しないでください。
Before using the Teredo service, the client must be configured with:
Teredoサービスを使用する前に、クライアントはして設定する必要があります。
- the IPv4 address of a server. - a secondary IPv4 address of that server.
- サーバーのIPv4アドレス。 - そのサーバーのセカンダリIPv4アドレス。
If secure discovery is required, the client must also be configured with:
安全な発見が必要な場合は、クライアントはまたして設定する必要があります。
- a client identifier, - a secret value, shared with the server, - an authentication algorithm, shared with the server.
- クライアント識別子、 - 秘密の値、サーバーと共有、 - 認証アルゴリズム、サーバーと共有。
A Teredo client expects to exchange IPv6 packets through a UDP port, the Teredo service port. To avoid problems when operating behind a "port conserving" NAT, different clients operating behind the same NAT should use different service port numbers. This can be achieved through explicit configuration or, in the absence of configuration, by picking the service port number at random.
Teredoクライアントは、UDPポート、Teredoサービスポート経由でIPv6パケットを交換することを期待しています。 「ポート節約」NATの背後で動作するときの問題を回避するには、同じNATの背後で動作し、クライアントごとにそれぞれ異なるサービスポート番号を使用する必要があります。これは、ランダムにサービスポート番号を選ぶことによって、コンフィギュレーションが存在しない場合に、明示的な設定によって達成またはすることができます。
The client will maintain the following variables that reflect the state of the Teredo service:
クライアントは、Teredoサービスの状態を反映し、次の変数を維持します。
- Teredo connectivity status, - Mapped address and port number associated with the Teredo service port, - Teredo IPv6 prefix associated with the Teredo service port, - Teredo IPv6 address or addresses derived from the prefix, - Link local address, - Date and time of the last interaction with the Teredo server, - Teredo Refresh Interval, - Randomized Refresh Interval, - List of recent Teredo peers.
- Teredoの接続状況、 - Teredoサービスポートに関連付けられたマップされたアドレスとポート番号、 - Teredoサービスポートに関連付けられているTeredoのIPv6プレフィックス、 - 接頭語由来のTeredo IPv6アドレスまたはアドレス、 - リンクローカルアドレス、 - 日付と時刻のTeredoサーバーとの最後の対話、 - Teredoの更新間隔、 - ランダム更新間隔、 - 最近のTeredoピアのリスト。
Before sending any packets, the client must perform the Teredo qualification procedure, which determines the Teredo connectivity status, the mapped address and port number, and the Teredo IPv6 prefix. It should then perform the cone NAT determination procedure, which determines the cone NAT status and may alter the value of the prefix. If the qualification is successful, the client may use the Teredo service port to transmit and receive IPv6 packets, according to the transmission and reception procedures. These procedures use the "list of recent peers". For each peer, the list contains:
すべてのパケットを送信する前に、クライアントからTeredo接続状況、マッピングされたアドレスとポート番号、およびTeredoのIPv6プレフィックスを決定Teredoの資格手続きを実行する必要があります。その後、コーンNAT状態を判断し、接頭辞の値を変更することができるコーンNAT決定手順を実行しなければなりません。資格が成功した場合、クライアントは、送受信手順に従って、IPv6パケットを送受信するTeredoサービスポートを使用してもよいです。これらの手順は、「最近のピアのリスト」を使用します。各ピアのために、リストが含まれています。
- The IPv6 address of the peer, - The mapped IPv4 address and mapped UDP port of the peer, - The status of the mapped address, i.e., trusted or not, - The value of the last nonce sent to the peer, - The date and time of the last reception from the peer, - The date and time of the last transmission to the peer, - The number of bubbles transmitted to the peer.
- マッピングされたIPv4アドレスとピアのマップされたUDPポート、 - - マッピングされたアドレスの状態、すなわち、信頼できるかどうか、 - ピアのIPv6アドレスの最後のナンスの値は、ピアに送信 - 日付をピアから前回の受信の時間 - ピアへの最後の送信の日時、 - ピアに送信された気泡の数。
The list of peers is used to enable the transmission of IPv6 packets by using a "direct path" for the IPv6 packets. The list of peers could grow over time. Clients should implement a list management strategy, for example, deleting the least recently used entries. Clients should make sure that the list has a sufficient size, to avoid unnecessary exchanges of bubbles.
ピアのリストは、IPv6パケットの「直接パス」を用いてIPv6パケットの伝送を可能にするために使用されます。ピアのリストは、時間をかけて成長することができます。クライアントは、最低使用エントリを削除、例えば、リスト管理戦略を実装する必要があります。クライアントは、気泡の不必要な交換を避けるために、リストには十分な大きさを持っていることを確認する必要があります。
The client must regularly perform the maintenance procedure in order to guarantee that the Teredo service port remains usable. The need to use this procedure or not depends on the delay since the last interaction with the Teredo server. The refresh procedure takes as a parameter the "Teredo refresh interval". This parameter is initially set to 30 seconds; it can be updated as a result of the optional "interval determination procedure". The randomized refresh interval is set to a value randomly chosen between 75% and 100% of the refresh interval.
クライアントは、定期的にTeredoサービスポートが使用可能なままであることを保証するために、メンテナンス手順を実行する必要があります。この手順を使用するかする必要がTeredoサーバーとの最後の対話以降の遅延に依存します。リフレッシュ手順は、パラメータ「のTeredo更新間隔」となります。このパラメータは、最初は30秒に設定されています。それは、オプションの「間隔決意手順」の結果として更新することができます。ランダム化されたリフレッシュ間隔をランダムに75％およびリフレッシュ間隔の100％の間で選択された値に設定されています。
In order to avoid triangle routing for stations that are located behind the same NAT, the Teredo clients MAY use the optional local client discovery procedure defined in Section 5.2.8. Using this procedure will also enhance connectivity when the NAT cannot do "hairpin" routing, i.e., cannot redirect a packet sent from one internal host to the mapped address and port of another internal host.
同じNATの背後に配置されているステーションの三角ルーティングを避けるために、Teredoクライアントは、5.2.8項で定義されたオプションのローカルクライアント発見手順を使用するかもしれません。 NATは、すなわち、「ヘアピン」ルーティングを行うことができない場合にも、接続を強化するこの手順を使用して、別の内部ホストのマッピングされたアドレスとポートに一つの内部ホストから送信されたパケットをリダイレクトすることができません。
The purposes of the qualification procedure are to establish the status of the local IPv4 connection and to determine the Teredo IPv6 client prefix of the local Teredo interface. The procedure starts when the service is in the "initial" state, and it results in a "qualified" state if successful, and in an "off-line" state if unsuccessful.
資格手続きの目的は、ローカルIPv4接続の状態を確立するために、地元のTeredoインターフェイスのTeredoのIPv6クライアントのプレフィックスを決定することです。サービスは「初期」状態にあるとき、手順が開始され、成功した場合、および「オフライン」の状態で失敗した場合には、「資格」状態となります。
/---------\
| Initial |
\---------/
|
+----+----------+
| Set ConeBit=1 |
+----+----------+
|
+<-------------------------------------------+
| |
+----+----+ |
| Start |<------+ |
+----+----+ | +----------+----+
| | | Set ConeBit=0 |
v | +----------+----+
/---------\ Timer | N ^
|Starting |-------+ attempts /----------------\Yes|
\---------/----------------->| ConeBit == 1 ? |---+
| Response \----------------/
| | No
V V
/---------------\ Yes /----------\
| ConeBit == 1? |-----+ | Off line |
\---------------/ | \----------/
No | v
| /----------\
| | Cone NAT |
+-----+-----+ \----------/
| New Server|
+-----+-----+
|
+----+----+
| Start |<------+
+----+----+ |
| |
v |
/---------\ Timer |
|Starting |-------+ N attempts /----------\
\---------/------------------->| Off line |
| Response \----------/
|
V
/------------\ No /---------------\
| Same port? |-------->| Symmetric NAT |
\------------/ \---------------/
| Yes
V
/----------------------\
| Restricted Cone NAT |
\----------------------/
Initially, the Teredo connectivity status is set to "Initial".
最初は、Teredoの接続ステータスが「初期」に設定されています。
When the interface is initialized, the system first performs the "start action" by sending a Router Solicitation message, as defined in [RFC2461]. The client picks a link-local address and uses it as the IPv6 source of the message; the cone bit in the address is set to 1 (see Section 4 for the address format); the IPv6 destination of the RS is the all-routers multicast address; the packet will be sent over UDP from the service port to the Teredo server's IPv4 address and Teredo UDP port. The connectivity status moves then to "Starting".
インターフェースが初期化されると、システムは、最初の[RFC2461]で定義されるように、ルータ要請メッセージを送信することによって、「アクションを起動する」を行います。クライアントは、リンクローカルアドレスをピックアップし、メッセージのIPv6送信元として使用します。アドレスにおけるコーンビットが1（アドレス形式については、セクション4を参照）に設定されています。 RSのIPv6宛先は、すべてのルータマルチキャストアドレスです。パケットはTeredoサーバーのIPv4アドレスとTeredo UDPポートにサービスポートからUDPを介して送信されます。接続ステータスは、「起動」し、その後移動します。
In the starting state, the client waits for a router advertisement from the Teredo server. If no response comes within a time-out T, the client should repeat the start action, by resending the Router Solicitation message. If no response has arrived after N repetitions, the client concludes that it is not behind a cone NAT. It sets the cone bit to 0, and repeats the procedure. If after N other timer expirations and retransmissions there is still no response, the client concludes that it cannot use UDP, and that the Teredo service is not available; the status is set to "Off-line". In accordance with [RFC2461], the default time-out value is set to T=4 seconds, and the maximum number of repetitions is set to N=3.
開始状態では、クライアントは、Teredoサーバーからのルータ広告を待ちます。応答がタイムアウトT内に入っていない場合は、クライアントがルータ要請メッセージを再送することで、開始動作を繰り返す必要があります。応答がN回の繰り返しの後に到着していない場合、クライアントは、それがcone NATの背後にはないと結論づけています。これは、0にコーンビットをセットして、手順を繰り返します。 N他のタイマーの有効期限と再送信後もまだ応答がない場合、クライアントはUDPを使用することができないと結論付け、およびTeredoサービスは利用できないこと。ステータスが「オフライン」に設定されています。 [RFC2461]に従って、デフォルトのタイムアウト値は、T = 4秒に設定され、繰り返しの最大数は、N = 3に設定されています。
If a response arrives, the client checks that the response contains an origin indication and a valid router advertisement as defined in [RFC2461], that the IPv6 destination address is equal to the link-local address used in the router solicitation, and that the router advertisement contains exactly one advertised Prefix Information option. This prefix should be a valid Teredo IPv6 server prefix: the first 32 bits should contain the global Teredo IPv6 service prefix, and the next 32 bits should contain the server's IPv4 address. If this is the case, the client learns the Teredo mapped address and Teredo mapped port from the origin indication. The IPv6 source address of the Router Advertisement is a link-local server address of the Teredo server. (Responses that are not valid advertisements are simply discarded.)
応答が到着した場合、クライアントはIPv6宛先アドレスが、ルータ要求に使用されるリンクローカルアドレスに等しく、ルータということを、[RFC2461]で定義されている応答は、原点指標と有効なルータ広告が含まれていることを確認し広告は、1つの広告を出してプレフィックス情報オプションが含まれています。最初の32ビットは、グローバルのTeredoのIPv6サービスプレフィックスが含まれている必要があり、次の32ビットは、サーバのIPv4アドレスが含まれている必要があります。この接頭辞は、有効なのTeredoのIPv6サーバーの接頭辞でなければなりません。この場合は、クライアントで、Teredoアドレスをマッピングし、Teredoの原点表示からポートをマッピングし学習します。ルーターアドバタイズのIPv6送信元アドレスは、Teredoサーバーのリンクローカルサーバーのアドレスです。 （有効な広告ではありませんが、単純に廃棄されている応答。）
If the client has received an RA with the cone bit in the IPv6 destination address set to 1, it is behind a cone NAT and is fully qualified. If the RA is received with the cone bit set to 0, the client does not know whether the local NAT is restricted or symmetric. The client selects the secondary IPv4 server address, and repeats the procedure, the cone bit remaining to the value zero. If the client does not receive a response, it detects that the service is not usable. If the client receives a response, it compares the mapped address and mapped port in this second response to the first received values. If the values are different, the client detects a symmetric NAT: it cannot use the Teredo service. If the values are the same, the client detects a port-restricted or restricted cone NAT: the client is qualified to use the service. (Teredo operates the same way for restricted and port-restricted NAT.)
クライアントが1に設定されたIPv6宛先アドレスにコーンビットでRAを受信した場合には、コーンNATの背後にあり、完全修飾です。 RAは、0に設定コーンビットを受信した場合、クライアントは、ローカルNATが制限または対称されているかどうか分かりません。クライアントは、コーンビットが値ゼロに残り、セカンダリIPv4サーバのアドレスを選択し、手順を繰り返します。クライアントが応答を受信しない場合は、サービスが使用できないことを検出しました。クライアントが応答を受信した場合、それは最初に受信した値に、この第二の応答にマッピングされたアドレスとマッピングされたポートとを比較します。値が異なる場合、クライアントは、対称NATを検出：それはTeredoサービスを使用することはできません。値が同じである場合、クライアントは、ポート制限または制限コーンNATを検出します。クライアントは、サービスを利用する資格があります。 （Teredoは、制限、ポート制限NATのために同じように動作します。）
If the client is qualified, it builds a Teredo IPv6 address using the Teredo IPv6 server prefix learned from the RA and the obfuscated values of the UDP port and IPv4 address learned from the origin indication. The cone bit should be set to the value used to receive the RA, i.e., 1 if the client is behind a cone NAT, 0 otherwise. The client can start using the Teredo service.
クライアントが修飾されている場合、それは元の表示から学んだRAおよびUDPポートとIPv4アドレスの難読化された値から学んだのTeredoのIPv6サーバーの接頭辞を使用してTeredoのIPv6アドレスを構築します。クライアントはコーンNAT、そうでなければ0の背後にある場合コーンビットが1、すなわち、RAを受信するために使用される値に設定されるべきです。クライアントは、Teredoサービスを使い始めることができます。
The client may be required to perform secured qualification. The client will perform exactly the algorithm described in Section 5.2.1, but it will incorporate an authentication encapsulation in the UDP packet carrying the router solicitation message, and it will verify the presence of a valid authentication parameter in the UDP message that carries the router advertisement provided by the sender.
クライアントは、セキュリティで保護された資格を実行するために必要な場合があります。クライアントは、5.2.1項で説明した正確なアルゴリズムを実行しますが、それはルータ要請メッセージを運ぶUDPパケットに認証カプセル化を組み込む予定、それがルータを運ぶUDPメッセージで有効な認証パラメータの存在を確認します送信者によって提供広告。
In these packets, the nonce value is chosen by the client, and is repeated in the response from the server; the client identifier is a value with which the client was configured.
これらのパケットでは、ノンス値はクライアントによって選択され、サーバからの応答で繰り返されます。クライアント識別子は、クライアントが設定されたときの値です。
A first level of protection is provided by just checking that the value of the nonce in the response matches the value initially sent by the client. If they don't match, the packet MUST be discarded. If no other protection is used, the authentication payload does not contain any identifier or authentication field; the ID-len and AU-len fields are set to a null value. When stronger protection is required, the authentication payload contains the identifier and location fields, as explained in the following paragraphs.
保護の最初のレベルはちょうど応答でナンスの値は、最初にクライアントから送信された値と一致することを確認することで提供されます。彼らは一致しない場合、パケットは捨てなければなりません。他の保護が使用されていない場合は、認証ペイロードは任意の識別子または認証フィールドが含まれていません。 ID-LENとAU-LENフィールドはNULL値に設定されています。より強力な保護が必要な場合は、次の段落で説明したように、認証ペイロードは、識別子および位置フィールドを含んでいます。
The confirmation byte is set to 0 by the client. A null value returned by the server indicates that the client's key is still valid; a non-null value indicates that the client should obtain a new key.
確認バイトは、クライアントによって0に設定されています。サーバから返されたNULL値は、クライアントの鍵がまだ有効であることを示しています。 null以外の値は、クライアントが新しいキーを取得する必要があることを示します。
When stronger authentication is provided, the client and the server are provisioned with a client identifier, a shared secret, and the identification of an authentication algorithm. Before transmission, the authentication value is computed according to the specified algorithm; on reception, the same algorithm is used to compute a target value from the content of the receive packet. The receiver deems the authentication successful if the two values match. If they don't, the packet MUST be discarded.
より強力な認証が提供されている場合、クライアントとサーバは、クライアント識別子、共有秘密、および認証アルゴリズムの識別にプロビジョニングされています。送信前に、認証値が指定されたアルゴリズムに従って計算されます。受信時に、同じアルゴリズムは、受信パケットの内容から目標値を計算するために使用されます。二つの値が一致する場合、受信機は、認証が成功したと判断しました。そうでない場合は、パケットは捨てなければなりません。
To maximize interoperability, this specification defines a default algorithm in which the authentication value is computed according the HMAC specification [RFC2104] and the SHA1 function [FIPS-180]. Clients and servers may agree to use HMAC combined with a different function, or to use a different algorithm altogether, such as for example AES-XCBC-MAC-96 [RFC3566].
相互運用性を最大にするために、本明細書は、認証値がHMAC仕様[RFC2104]及びSHA1関数[FIPS-180]に従って計算されたデフォルトのアルゴリズムを定義します。クライアントとサーバーは異なる機能と組み合わせるHMACを使用することに同意することができる、又は例えばAES-XCBC-MAC-96 [RFC3566]と同様に、完全に異なるアルゴリズムを使用します。
The default authentication algorithm is based on the HMAC algorithm according to the following specifications:
デフォルトの認証アルゴリズムは、以下の仕様に応じてHMACアルゴリズムに基づいています。
- the hash function shall be the SHA1 function [FIPS-180]. - the secret value shall be the shared secret with which the client was configured.
- ハッシュ関数はSHA1関数[FIPS-180]でなければなりません。 - 秘密の値は、クライアントが設定されたと共有秘密でなければなりません。
The clear text to be protected includes:
保護されるべき明確なテキストが含まれています：
- the nonce value, - the confirmation byte, - the origin indication encapsulation, if it is present, - the IPv6 packet.
- 一回だけの値、 - 確認バイト、 - 原点表示のカプセル化、それが存在する場合、 - IPv6パケット。
The HMAC procedure is applied to the concatenation of these four components, without any additional padding.
HMAC手順は、任意の追加のパディングすることなく、これらの四つの成分の連結に適用されます。
The Teredo client receives packets over the Teredo interface. The role of the packet reception procedure, besides receiving packets, is to maintain the date and time of the last interaction with the Teredo server and the "list of recent peers".
TeredoクライアントからTeredoインターフェイス上でパケットを受信します。パケット受信手続きの役割は、パケットを受信以外に、Teredoサーバーと「最近のピアのリスト」との最後の対話の日時を維持することです。
When a UDP packet is received over the Teredo service port, the Teredo client checks that it is encoded according to the packet encoding rules defined in Section 5.1.1, and that it contains either a valid IPv6 packet or the combination of a valid origin indication encapsulation and a valid IPv6 packet, possibly protected by a valid authentication encapsulation. If this is not the case, the packet is silently discarded.
UDPパケットはTeredoサービスポートを介して受信された場合、Teredoクライアントは、それが、セクション5.1.1で定義されたパケットの符号化規則に従って符号化されていることを確認し、それが有効なIPv6パケットまたは有効な起源の指示の組み合わせのいずれかを含むことカプセル化と有効なIPv6パケット、おそらく有効な認証カプセル化によって保護されています。そうでない場合、パケットは黙って破棄されます。
An IPv6 packet is deemed valid if it conforms to [RFC2460]: the protocol identifier should indicate an IPv6 packet and the payload length should be consistent with the length of the UDP datagram in which the packet is encapsulated. In addition, the client should check that the IPv6 destination address correspond to its own Teredo address.
それは[RFC2460]に準拠している場合、IPv6パケットが有効であると考えられる：プロトコル識別子は、パケットがカプセル化されたUDPデータグラムの長さと一致しなければならないIPv6パケット及びペイロード長を示すべきです。また、クライアントはIPv6宛先アドレスが自身のTeredoアドレスに対応することを確認する必要があります。
Then, the Teredo client examines the IPv4 source address and UDP port number from which the packet is received. If these values match the IPv4 address of the server and the Teredo port, the client updates the "date and time of the last interaction with the Teredo server" to the current date and time; if an origin indication is present, the client should perform the "direct IPv6 connectivity test" described in Section 5.2.9.
その後、Teredoクライアントがパケットを受信し、そこからのIPv4送信元アドレスとUDPポート番号を調べます。これらの値は、サーバーとのTeredoポートのIPv4アドレスが一致した場合、クライアントは、現在の日付と時刻に「Teredoサーバーとの最後の対話の日付と時刻」を更新します。原産地表示が存在する場合、クライアントは、5.2.9項で説明した「直接IPv6接続テスト」を実行する必要があります。
If the IPv4 source address and UDP port number are different from the IPv4 address of the server and the Teredo port, the client examines the IPv6 source address of the packet:
IPv4ソースアドレスとUDPポート番号は、サーバーとのTeredoポートのIPv4アドレスと異なる場合、クライアントは、パケットのIPv6送信元アドレスを調べます。
1) If there is an entry for the source IPv6 address in the list of peers whose status is trusted, the client compares the mapped IPv4 address and mapped port in the entry with the source IPv4 address and source port of the packet. If the values match, the packet is accepted; the date and time of the last reception from the peer is updated.
状況信頼されるピアのリストにある送信元IPv6アドレスのエントリがある場合は1）、クライアントは、パケットの送信元IPv4アドレスと送信元ポートのエントリにマッピングされたIPv4アドレスとマッピングされたポートを比較します。値が一致した場合、パケットは受け入れられ;ピアからの最後の受信日時が更新されます。
2) If there is an entry for the source IPv6 address in the list of peers whose status is not trusted, the client checks whether the packet is an ICMPv6 echo reply. If this is the case, and if the ICMPv6 data of the reply matches the nonce stored in the peer entry, the packet should be accepted; the status of the entry should be changed to "trusted", the mapped IPv4 and mapped port in the entry should be set to the source IPv4 address and source port from which the packet was received, and the date and time of the last reception from the peer should be updated. Any packet queued for this IPv6 peer (as specified in Section 5.2.4) should be de-queued and forwarded to the newly learned IPv4 address and UDP port.
2）ステータスパケットがICMPv6のエコー応答であるかどうか、クライアントのチェックを信頼されていないピアのリストにある送信元IPv6アドレスのエントリがある場合。この場合は、応答のICMPv6のデータをピア・エントリに格納されたナンスと一致する場合、及び、パケットは受け入れなければなりません。エントリのステータスは、マッピングされたIPv4、「信頼」に変更し、エントリにポートをマッピングされたパケットが受信された送信元IPv4アドレスおよび送信元ポートに設定する必要があり、そして最後から受信日時されるべきですピアは更新する必要があります。デキューし、新たに学習IPv4アドレスとUDPポートに転送する必要があります（5.2.4項で指定されるように）どれでもパケットは、このIPv6のピアのためにキューに入れられました。
3) If the source IPv6 address is a Teredo address, the client compares the mapped IPv4 address and mapped port in the source address with the source IPv4 address and source port of the packet. If the values match, the client MUST create a peer entry for the IPv6 source address in the list of peers; it should update the entry if one already existed; the mapped IPv4 address and mapped port in the entry should be set to the value from which the packet was received, and the status should be set to "trusted". If a new entry is created, the last transmission date is set to 30 seconds before the current date, and the number of bubbles to zero. If the packet is a bubble, it should be discarded after this processing; otherwise, the packet should be accepted. In all cases, the client must de-queue and forward any packet queued for that destination.
送信元IPv6アドレスがTeredoアドレスである場合3）、クライアントは、パケットの送信元IPv4アドレスと送信元ポートと送信元アドレスにマッピングされたIPv4アドレスとマッピングされたポートとを比較します。値が一致した場合、クライアントは、ピアのリストでIPv6送信元アドレスのピアエントリを作成する必要があります。 1がすでに存在していれば、それはエントリを更新する必要があります。エントリにマッピングされたIPv4アドレスとマッピングされたポートがパケットを受信した値に設定する必要があり、状態は「信頼できる」に設定されるべきです。新しいエントリが作成されている場合は、最後の送信日は現在の日付の前に30秒に設定され、泡の数をゼロにしています。パケットがバブルである場合、この処理後に廃棄されなければなりません。それ以外の場合は、パケットが受け入れられなければなりません。すべての場合において、クライアントは、キューを解除し、その先のためにキューに入れられたすべてのパケットを転送する必要があります。
4) If the IPv4 destination address through which the packet was received is the Teredo IPv4 Discovery Address, the source address is a valid Teredo address, and the destination address is the "all nodes on link" multicast address, the packet should be treated as a local discovery bubble. If no local entry already existed for the source address, a new one is created, but its status is set to "not trusted". The client SHOULD reply with a unicast Teredo bubble, sent to the source IPv4 address and source port of the local discovery bubble; the IPv6 source address of the bubble will be set to local Teredo IPv6 address; the IPv6 destination address of the bubble should be set to the IPv6 source address of the local discovery bubble. (Clients that do not implement the optional local discovery procedure will not process local discovery bubbles.)
4）パケットを受信し、それを通してIPv4宛先アドレスのTeredo IPv4の検出アドレスである場合、送信元アドレスが有効Teredoアドレスであり、宛先アドレスが「リンク上のすべてのノード」マルチキャストアドレスであり、パケットは、として扱われるべきですローカル発見バブル。ローカルエントリが既に送信元アドレスのために存在しない場合は、新しいものが作成されますが、そのステータスが「信頼できない」に設定されています。クライアントは、送信元IPv4アドレスとローカル発見バブルの送信元ポートに送信されたユニキャストのTeredoバブル、で応答すべきです。バブルのIPv6送信元アドレスは、ローカルのTeredoのIPv6アドレスに設定されます。バブルのIPv6宛先アドレスは、ローカル発見バブルのIPv6送信元アドレスに設定する必要があります。 （オプションのローカル発見手順を実装していないクライアントは、ローカル発見泡を処理しません。）
5) If the source IPv6 address is a Teredo address, and the mapped IPv4 address and mapped port in the source address do not match the source IPv4 address and source port of the packet, the client checks whether there is an existing "local" entry for that IPv6 address. If there is such an entry, and if the local IPv4 address and local port indicated in that entry match the source IPv4 address and source
5）送信元IPv6アドレスがTeredoアドレスであり、送信元アドレスでマッピングされたIPv4アドレスとマッピングされたポートは、パケットの送信元IPv4アドレスと送信元ポートと一致しない場合は、既存の「ローカル」のエントリがあるかどうか、クライアントをチェックそのIPv6アドレスのために。そのようなエントリが存在する場合、およびローカルIPv4アドレスとローカルポートは、そのエントリの一致に元IPv4アドレスと送信元を示す場合
port of the packet, the client updates the "local" entry, whose status should be set to "trusted". If the packet is a bubble, it should be discarded after this processing; otherwise, the packet should be accepted. In all cases, the client must de-queue and forward any packet queued for that destination.
パケットのポートは、クライアントは、そのステータスが「信頼できる」に設定する必要があり、「ローカル」のエントリーを更新します。パケットがバブルである場合、この処理後に廃棄されなければなりません。それ以外の場合は、パケットが受け入れられなければなりません。すべての場合において、クライアントは、キューを解除し、その先のためにキューに入れられたすべてのパケットを転送する必要があります。
6) In the other cases, the packet may be accepted, but the client should be conscious that the source address may be spoofed; before processing the packet, the client should perform the "direct IPv6 connectivity test" described in Section 5.2.9.
6）他の場合には、パケットは受け入れられるが、クライアントは、送信元アドレスが偽装されてもよいことを意識しなければなりません。パケットを処理する前に、クライアントは、5.2.9項で説明した「直接IPv6接続テスト」を実行する必要があります。
Whatever the IPv4 source address and UDP source port, the client that receives an IPv6 packet MAY send a Teredo bubble towards that target, as specified in Section 5.2.6.
IPv4ソースアドレスとUDPソースポートが何であれ、セクション5.2.6で指定されるように、IPv6パケットを受信したクライアントは、その目標に向けてTeredoバブルを送信することができます。
When a Teredo client has to transmit a packet over a Teredo interface, it examines the destination IPv6 address. The client checks first if there is an entry for this IPv6 address in the list of recent Teredo peers, and if the entry is still valid: an entry associated with a local peer is valid if the last reception date and time associated with that list entry is less that 30 seconds from the current time; an entry associated with a non-local peer is valid if the last reception date and time associated with that list entry is less that 30 seconds from the current time. (Local peer entries can only be present if the client uses the local discovery procedure discussed in Section 5.2.8.)
Teredoクライアントは、Teredoのインターフェイス上でパケットを送信しなければならない場合は、宛先IPv6アドレスを調べます。最後の受信日時がそのリストのエントリに関連付けられている場合、ローカルピアに関連付けられているエントリが有効である：最近のTeredoピアのリストで、このIPv6アドレスのエントリがある場合、そのエントリがまだ有効である場合、クライアントは、最初のチェック現在時刻からあまりその30秒です。そのリストのエントリに関連付けられている最後の受信日時が現在時刻からあまりその30秒であれば非ローカルピアに関連付けられているエントリが有効です。 （クライアントは、5.2.8項で述べたローカル発見手順を使用している場合、ローカルピアエントリにのみ存在することができます。）
The client then performs the following:
次に、クライアントは次のことを実行します。
1) If there is an entry for that IPv6 address in the list of peers, and if the status of the entry is set to "trusted", the IPv6 packet should be sent over UDP to the IPv4 address and UDP port specified in the entry. The client updates the date of last transmission in the peer entry.
1）がピアのリストでそのIPv6アドレスのエントリがあり、エントリのステータスが「信頼できる」に設定されている場合、IPv6パケットがエントリで指定されたIPv4アドレスとUDPポートにUDPを介して送信されるべきであるならば。クライアントは、ピア・エントリ内の最後の送信の日付を更新します。
2) If the destination is not a Teredo IPv6 address, the packet is queued, and the client performs the "direct IPv6 connectivity test" described in Section 5.2.9. The packet will be de-queued and forwarded if this procedure completes successfully. If the direct IPv6 connectivity test fails to complete within a 2-second time-out, it should be repeated up to 3 times.
宛先がTeredoのIPv6アドレスでない場合は2）、パケットがキューイングされ、そしてクライアントは、セクション5.2.9に記載の「直接のIPv6接続性テスト」を行います。この手順が正常に完了した場合にパケットをデキューして転送されます。直接IPv6接続テストは2秒のタイムアウト内に完了しなかった場合、それは3回まで繰り返すべきです。
3) If the destination is the Teredo IPv6 address of a local peer (i.e., a Teredo address from which a local discovery bubble has been received in the last 600 seconds), the packet is queued. The client sends a unicast Teredo bubble to the local IPv4 address and local port specified in the entry, and a local Teredo bubble to the Teredo IPv4 discovery address.
宛先がローカル発見バブルは、最後の600秒で受信されたローカルピア（すなわち、Teredoアドレス）のTeredoのIPv6アドレスである場合3）、パケットがキューイングされます。クライアントは、ローカルIPv4アドレスとエントリに指定されたローカルポート、およびTeredoのIPv4の検出アドレスへのローカルTeredoバブルへのユニキャストTeredoバブルを送信します。
4) If the destination is a Teredo IPv6 address in which the cone bit is set to 1, the packet is sent over UDP to the mapped IPv4 address and mapped UDP port extracted from that IPv6 address.
宛先がコーンビットが1に設定されたTeredoのIPv6アドレスである場合4）、パケットがマッピングされたIPv4アドレスにUDPを介して送信され、マッピングされたUDPポートは、IPv6アドレスから抽出されました。
5) If the destination is a Teredo IPv6 address in which the cone bit is set to 0, the packet is queued. If the client is not located behind a cone NAT, it sends a direct bubble to the Teredo destination, i.e., to the mapped IP address and mapped port of the destination. In all cases, the client sends an indirect bubble to the Teredo destination, sending it over UDP to the server address and to the Teredo port. The packet will be de-queued and forwarded when the client receives a bubble or another packet directly from this Teredo peer. If no bubble is received within a 2-second time-out, the bubble transmission should be repeated up to 3 times.
宛先が円錐ビットが0に設定されているTeredoのIPv6アドレスである場合は5）、パケットがキューイングされます。クライアントがcone NATの内側に配置されていない場合は、マッピングされたIPアドレスに、すなわち、Teredoの宛先に直接泡を送信し、送信先のポートをマッピングされました。すべての場合において、クライアントは、サーバのアドレスへとTeredoのポートにUDP経由で送信、Teredoの先への間接的なバブルを送信します。パケットがデキューし、クライアントがバブルか、このTeredoのピアから直接、別のパケットを受信したときに転送されます。いかなる気泡が2秒のタイムアウト内に受信されない場合、気泡送信は3回まで繰り返されるべきです。
In cases 4 and 5, before sending a packet over UDP, the client MUST check that the IPv4 destination address is in the format of a global unicast address; if this is not the case, the packet MUST be silently discarded. (Note that a packet can legitimately be sent to a non-global unicast address in case 1, as a result of the local discovery procedure.)
ケース4及び5において、UDPを介してパケットを送信する前に、クライアントは、IPv4宛先アドレスがグローバルユニキャストアドレスの形式であることをチェックしなければなりません。そうでない場合、パケットは静かに捨てなければなりません。 （パケットが正当ローカル発見手順の結果として、ケース1内の非グローバルユニキャストアドレスに送信することができることに留意されたいです。）
The global unicast address check is designed to thwart a number of possible attacks in which an attacker tries to use a Teredo host to attack either a single local IPv4 target or a set of such targets. For the purpose of this specification, and IPv4 address is deemed to be a global unicast address if it does not belong to or match:
グローバルユニキャストアドレスチェックは、攻撃者が単一のローカルのIPv4ターゲット又はターゲットのセットのいずれかを攻撃するためのTeredoホストを使用しようとする可能攻撃の数を阻止するように設計されています。この仕様の目的のために、それが属するかが一致しない場合、IPv4アドレスがグローバルユニキャストアドレスであると思われます。
- the "local" subnet 0.0.0.0/8, - the "loopback" subnet 127.0.0.0/8, - the local addressing ranges 10.0.0.0/8, - the local addressing ranges 172.16.0.0/12, - the local addressing ranges 192.168.0.0/16, - the link local block 169.254.0.0/16, - the block reserved for 6to4 anycast addresses 192.88.99.0/24, - the multicast address block 224.0.0.0/4, - the "limited broadcast" destination address 255.255.255.255, - the directed broadcast addresses corresponding to the subnets to which the host is attached.
- 「ローカル」サブネット0.0.0.0/8、 - 「ループバック」サブネット127.0.0.0/8、 - ローカルアドレス指定範囲10.0.0.0/8、 - ローカルアドレス指定範囲172.16.0.0/12、 - ローカルアドレッシング、192.168.0.0/16の範囲 - リンクローカルブロック169.254.0.0/16、 - の6to4エニーキャストアドレス192.88.99.0/24のために予約ブロック、 - マルチキャストアドレスブロック224.0.0.0/4、 - 「限られた放送」宛先を、255.255.255.255に対処 - ダイレクトブロードキャストアドレスはホストが取り付けられたサブネットに対応します。
A list of special-use IPv4 addresses is provided in [RFC3330].
特殊用途のIPv4アドレスのリストは、[RFC3330]に提供されます。
For reliability reasons, clients MAY decide to ignore the value of the cone bit in the flag, skip the "case 4" test and always perform the "case 5", i.e., treat all Teredo peers as if they were located behind non-cone NAT. This will result in some increase in traffic, but may avoid reliability issues if the determination of the NAT status was for some reason erroneous. For the same reason, clients MAY also decide to always send a direct bubble in case 5, even if they do not believe that they are located behind a non-cone NAT.
信頼性の理由から、クライアントは、フラグにコーンビットの値を無視することを決定した「ケース4」のテストをスキップして、常に「ケース5」を実行し、すなわち、それらは非コーンの後ろに位置しているかのように、すべてのTeredoピアを扱うかもしれNAT。これは、トラフィックのいくつかの増加をもたらすだろうが、NAT状態の決意が誤っていくつかの理由のためだった場合は信頼性の問題を回避することができます。同じ理由で、クライアントはまた、彼らは、彼らが非コーンNATの背後に配置されていることを信じていない場合でも、常にケース5に直接泡を送信することもできます。
The Teredo client must ensure that the mappings that it uses remain valid. It does so by checking that packets are regularly received from the Teredo server.
Teredoクライアントは、それが使用するマッピングが有効なままであることを確認する必要があります。これは、パケットが定期的にTeredoサーバーから受信していることを確認することでそれを行います。
At regular intervals, the client MUST check the "date and time of the last interaction with the Teredo server" to ensure that at least one packet has been received in the last Randomized Teredo Refresh Interval. If this is not the case, the client SHOULD send a router solicitation message to the server, as specified in Section 5.2.1; the client should use the same value of the cone bit that resulted in the reception of an RA during the qualification procedure.
定期的に、クライアントは、少なくとも1つのパケットが最後のランダム化のTeredo更新間隔で受信されたことを確認するために、「Teredoサーバーとの最後の対話の日付と時刻」をチェックしなければなりません。そうでない場合は、セクション5.2.1で指定されるように、クライアントは、サーバにルータ要請メッセージを送信する必要があります。クライアントは、認定手続きの際にRAの受信が生じたコーンビットの同じ値を使用する必要があります。
When the router advertisement is received, the client SHOULD check its validity as specified in Section 5.2.1; invalid advertisements are silently discarded. If the advertisement is valid, the client MUST check that the mapped address and port correspond to the current Teredo address. If this is not the case, the mapping has changed; the client must mark the old address as invalid and start using the new address.
ルータ広告を受信した場合は、セクション5.2.1で指定されるように、クライアントはその有効性を確認する必要があります。無効な広告は黙って破棄されます。広告が有効な場合、クライアントは、マップされたアドレスとポートが現在のTeredoアドレスに対応することをチェックしなければなりません。そうでない場合は、マッピングが変更されました。クライアントは無効と古いアドレスをマークし、新しいアドレスを使用して起動する必要があります。
The Teredo client may have to send a bubble towards another Teredo client, either after a packet reception or after a transmission attempt, as explained in Sections 5.2.3 and 5.2.4. There are two kinds of bubbles: direct bubbles, which are sent directly to the mapped IPv4 address and mapped UDP port of the peer, and indirect bubbles, which are sent through the Teredo server of the peer.
Teredoクライアントは、セクション5.2.3と5.2.4で説明したように、いずれかのパケットの受信後、または送信試行の後に、別のTeredoクライアントに向けてバブルを送信する必要があります。ピアのTeredoサーバーを経由して送信されているマップされたIPv4アドレスに直接送信し、ピアのUDPポートをマッピングされている直接泡、および間接的な泡、：気泡の2種類があります。
When a Teredo client attempts to send a direct bubble, it extracts the mapped IPv4 address and mapped UDP port from the Teredo IPv6 address of the target. It then checks whether there is already an entry for this IPv6 address in the current list of peers. If there is no entry, the client MUST create a new list entry for the address, setting the last reception date and the last transmission date to 30 seconds before the current date, and the number of bubbles to zero.
Teredoクライアントが直接泡を送信しようとすると、それは、ターゲットのTeredoのIPv6アドレスからマッピングされたIPv4アドレスとマッピングされたUDPポートを抽出します。その後、ピアの現在のリストで、このIPv6アドレスのエントリがすでに存在するかどうかをチェックします。エントリがない場合、クライアントは、最後の受信日時と現在の日付の前に30秒最後の送信日時、およびゼロへの気泡の数を設定、アドレスの新しいリストのエントリを作成する必要があります。
When a Teredo client attempts to send an indirect bubble, it extracts the Teredo server IPv4 address from the Teredo prefix of the IPv6 address of the target (different clients may be using different servers); the bubble will be sent to that IPv4 address and the Teredo UDP port.
Teredoクライアントが間接的なバブルを送信しようとすると、それは対象のIPv6アドレスのTeredoのプレフィックス（異なるクライアントが異なるサーバを使用している可能性がある）からTeredoサーバーのIPv4アドレスを抽出し、バブルは、IPv4アドレスとTeredo UDPポートに送信されます。
Bubbles may be lost in transit, and it is reasonable to enhance the reliability of the Teredo service by allowing multiple transmissions; however, bubbles will also be lost systematically in certain NAT configurations. In order to strike a balance between reliability and unnecessary retransmissions, we specify the following:
泡が輸送中に失われる可能性があり、そして複数の伝送を可能にすることにより、Teredoサービスの信頼性を向上することが妥当です。しかし、バブルはまた、特定のNAT構成で体系的に失われます。信頼性と不必要な再送信の間のバランスを取るために、私たちは次のように指定します。
- The client MUST NOT send a bubble if the last transmission date and time is less than 2 seconds before the current date and time;
- 前回の送信日時が現在の日付と時刻の前に2秒未満である場合、クライアントは、バブルを送ってはいけません。
- The client MUST NOT send a bubble if it has already sent 4 bubbles to the peer in the last 300 seconds without receiving a direct response.
- それは、すでにダイレクトレスポンスを受信せずに、最後の300秒にピアに4つの気泡を送信した場合、クライアントは、バブルを送ってはいけません。
In the other cases, the client MAY proceed with the transmission of the bubble. When transmitting the bubble, the client MUST update the last transmission date and time to that peer, and must also increment the number of transmitted bubbles.
他の例では、クライアントは、バブルの送信に進むことができます。バブルを送信する場合、クライアントはそのピアへの最後の送信日時を更新しなければならない、とも送信泡の数をインクリメントする必要があります。
In addition to the regular client resources described in the beginning of this section, the refresh interval determination procedure uses an additional UDP port, the Teredo secondary port, and the following variables:
このセクションの冒頭で説明した通常のクライアントのリソースに加えて、リフレッシュ間隔決定手順は、追加のUDPポート、Teredoのセカンダリポート、および以下の変数を使用しています：
- Teredo secondary connectivity status, - Mapped address and port number of the Teredo secondary port, - Teredo secondary IPv6 prefix associated with the secondary port, - Teredo secondary IPv6 address derived from this prefix, - Date and time of the last interaction on the secondary port, - Maximum Teredo Refresh Interval. - Candidate Teredo Refresh Interval.
- Teredoの二次接続状況、 - Teredoのセカンダリポートのマッピングされたアドレスとポート番号、 - セカンダリポートに関連付けられているのTeredo二IPv6プレフィックス、 - このプレフィックス由来のTeredoセカンダリIPv6アドレス、 - 二上の最後の相互作用の日付と時刻ポート、 - 最大のTeredo更新間隔。 - 候補者のTeredo更新間隔。
The secondary connectivity status, mapped address and prefix are determined by running the qualification procedure on the secondary port. When the client uses the interval determination procedure, the qualification procedure MUST be run for the secondary port immediately after running it on the service port. If the secondary qualification fails, the interval determination procedure will not be used, and the interval value will remain to the default value, 30 seconds. If the secondary qualification succeeds, the maximum refresh interval is set to 120 seconds, and the candidate Teredo refresh interval is set to 60 seconds, i.e., twice the Teredo refresh interval. The procedure is then performed at regular intervals, until it concludes:
二次接続のステータス、マッピングされたアドレスとプレフィックスがセカンダリポートに認定手順を実行することによって決定されます。クライアントは、間隔決意プロシージャを使用すると、資格手続きはすぐにサービスポート上でそれを実行した後にセカンダリポートのために実行する必要があります。二次予選に失敗した場合、間隔決意手順が使用されず、間隔値は、デフォルト値、30秒に残ります。二次資格が成功した場合、最大リフレッシュ間隔は120秒に設定されている、とTeredo間隔をリフレッシュ候補、すなわち、二回のTeredo更新間隔、60秒に設定されています。それが終了するまでの手順は、その後、定期的に実行されます。
1) wait until the candidate refresh interval is elapsed after the last interaction on the secondary port.
候補の更新間隔はセカンダリポートの最後の相互作用の後に経過するまでの1）を待ちます。
2) send a Teredo bubble to the Teredo secondary IPv6 address, through the service port.
2）サービスポートを介して、TeredoのセカンダリIPv6アドレスにTeredoバブルを送信します。
3) wait for reception of the bubble on the secondary port. If a timer of 2 seconds elapses without reception, repeat step 2 at most three times. If there is still no reception, the candidate has failed; if there is a reception, the candidate has succeeded.
3）二次ポート上のバブルの受信を待ちます。経過受信せずに2秒のタイマー場合は、最大3回のステップ2を繰り返します。まだ受信がない場合、候補者は失敗しました。受信があれば、候補者は成功しました。
4) if the candidate has succeeded, set the Teredo refresh interval to the candidate value, and set a new candidate value to the minimum of twice the new refresh interval, or the average of the refresh interval and the maximum refresh interval.
候補が成功した場合4）、Teredoの候補値に間隔をリフレッシュし、そして二回新しいリフレッシュ間隔の最小値、またはリフレッシュ間隔の平均値と最大リフレッシュ間隔に新しい候補値を設定します。
5) if the candidate has failed, set the maximum refresh interval to the candidate value. If the current refresh interval is larger than or equal to 75% of the maximum, the determination procedure has concluded; otherwise, set a new candidate value to the average of the refresh interval and the maximum refresh interval.
候補が失敗した場合は5）、候補値の最大リフレッシュ間隔を設定します。現在のリフレッシュ間隔よりも大きいかまたは最大値の75％に等しい場合、決意手順が締結しています。そうでない場合は、リフレッシュ間隔の平均値と最大リフレッシュ間隔に新しい候補値を設定します。
6) if the procedure has not concluded, perform the maintenance procedure on the secondary port, which will reset the date and time of the last interaction on the secondary port, and may result in the allocation of a new Teredo secondary IPv6 address; this would not affect the values of the refresh interval, candidate interval, or maximum refresh interval.
プロシージャが終了していない場合6）、二次ポート上の最後の相互作用の日付と時刻を再設定し、新しいTeredoのセカンダリIPv6アドレスの割り当てをもたらすことができる二次ポートのメンテナンス手順を実行します。これは、リフレッシュ間隔、候補区間、または最大リフレッシュ間隔の値に影響を与えません。
The secondary port MUST NOT be used for any other purpose than the interval determination procedure. It should be closed when the procedure ends.
セカンダリポートは、間隔決意手順以外の目的のために使用してはいけません。手続きが終了したときには閉じる必要があります。
It is desirable to enable direct communication between Teredo clients that are located behind the same NAT, without forcing a systematic relay through a Teredo server. It is hard to design a general solution to this problem, but we can design a partial solution when the Teredo clients are connected through IPv4 to the same link.
Teredoサーバー経由体系的リレーを強制することなく、同じNATの背後にあるTeredoクライアント間の直接通信を可能にすることが望ましいです。この問題に対する一般的なソリューションを設計するのは難しいですが、Teredoクライアントが同じリンクにはIPv4を介して接続されているときに我々は、部分的なソリューションを設計することができます。
A Teredo client who wishes to enable local discovery SHOULD join the IPv4 multicast group identified by Teredo IPv4 Discovery Address. The client SHOULD wait for discovery bubbles to be received on the Teredo IPv4 Discovery Address. The client SHOULD send local discovery bubbles to the Teredo IPv4 Discovery Address at random intervals, uniformly distributed between 200 and 300 seconds. A local Teredo bubble has the following characteristics:
地元の発見を可能にすることを希望するTeredoクライアントからTeredo IPv4の検出アドレスで識別されるIPv4マルチキャストグループに参加すべきです。発見のために待機しなければならないクライアントからTeredo IPv4の検出アドレス上で受信されるように泡。クライアントは一様に200と300秒の間に分布し、ランダムな間隔でのTeredo IPv4の検出アドレスにローカル発見気泡を送るべきです。ローカルTeredoバブルは、次の特徴があります。
- IPv4 source address: the IPv4 address of the sender
- IPv4ソースアドレス：送信者のIPv4アドレス
- IPv4 destination address: the Teredo IPv4 Discovery Address
- IPv4宛先アドレス：TeredoのIPv4の検出アドレス
- IPv4 ttl: 1
- のIPv4 TTL：1
- UDP source port: the Teredo service port of the sender
- UDPソースポート：送信者のTeredoサービスポート
- UDP destination port: the Teredo UDP port
- UDP宛先ポート：TeredoのUDPポート
- UDP payload: a minimal IPv6 packet, as follows
- UDPペイロード：最小限のIPv6パケット、次のように
- IPv6 source: the global Teredo IPv6 address of the sender
- IPv6ソース：送信者のグローバルTeredoのIPv6アドレス
- IPv6 destination: the all-nodes on-link multicast address
- IPv6宛先：すべてのノード上のリンクのマルチキャストアドレス
- IPv6 payload type: 59 (No Next Header, as per [RFC2460])
- IPv6のペイロードタイプ：59（[RFC2460]の通りいいえ次ヘッダ）
- IPv6 payload length: 0
- IPv6のペイロード長：0
- IPv6 hop limit: 1
- IPv6のホップリミット：1
The local discovery procedure carries a denial of service risk, as malevolent nodes could send fake bubbles to unsuspecting parties, and thus capture the traffic originating from these parties. The risk is mitigated by the filtering rules described in Section 5.2.5, and also by "link only" multicast scope of the Teredo IPv4 Discovery Address, which implies that packets sent to this address will not be forwarded across routers.
悪意のあるノードは疑うことを知らない者に偽の気泡を送るため、これらの当事者から発信されたトラフィックをキャプチャすることができてローカル発見手順は、サービスのリスクの拒否を運びます。リスクは、また、このアドレスに送信されたパケットはルータを介して転送されないことを意味するのTeredo IPv4の検出アドレスの「リンクのみ」マルチキャスト範囲によってセクション5.2.5で説明したフィルタリングルールによって緩和されます。
To benefit from the "link only multicast" protection, the clients should silently discard all local discovery bubbles that are received over a unicast address. To further mitigate the denial of service risk, the client MUST silently discard all local discovery bubbles whose IPv6 source address is not a well-formed Teredo IPv6 address, or whose IPv4 source address does not belong to the local IPv4 subnet; the client MAY decide to silently discard all local discovery bubbles whose Teredo IPv6 address do not include the same mapped IPv4 address as its own.
「リンクのみマルチキャスト」からの保護を利用するには、クライアントは黙っユニキャストアドレスを介して受信されたすべてのローカル発見泡を破棄しなければなりません。さらに、サービスのリスクの拒否を軽減するため、クライアントは黙ってそのIPv6ソースアドレスのIPv4送信元アドレスのローカルIPv4サブネットに属していない整形式のTeredo IPv6アドレス、またはではない、すべてのローカル発見泡を捨てなければなりません。クライアントは黙ってそのTeredoのIPv6のアドレス、独自のと同じマッピングされたIPv4アドレスが含まれていないすべてのローカル発見泡を破棄することを決定することができます。
If the bubble is accepted, the client checks whether there is an entry in the list of recent peers that correspond to the mapped IPv4 address and mapped UDP port associated with the source IPv6 address of the bubble. If there is such an entry, the client MUST update the local peer address and local peer port parameters to reflect the IPv4 source address and UDP source port of the bubble. If there is no entry, the client MUST create one, setting the local peer address and local peer port parameters to reflect the IPv4 source address and UDP source port of the bubble, the last reception date to the current date and time, the last transmission date to 30 seconds before the current date, and the number of bubbles to zero. The state of the entry is set to "not trusted".
バブルは、バブルの元IPv6アドレスに関連付けられたマッピングされたIPv4アドレスとマッピングされたUDPポートに対応する最近のピアのリストにエントリがあるかどうか、クライアントのチェックを受け入れている場合。そのようなエントリが存在する場合、クライアントは、バブルのIPv4ソースアドレスとUDPソースポートを反映するようにローカルピアアドレスとローカルピアポートパラメータを更新する必要があります。エントリがない場合、クライアントは、IPv4送信元アドレスとバブルのUDPソースポート、現在の日付と時刻を最後に受信日時、最後の送信を反映するために、ローカルピアアドレスとローカルピアポートのパラメータを設定し、1を作成する必要があります。現在の日付の前に30秒、日付、およびゼロへの気泡の数。エントリの状態を「信頼できない」に設定されています。
Upon reception of a discovery bubble, clients reply with a unicast bubble as specified in Section 5.2.3.
セクション5.2.3で指定されるように発見バブルを受信すると、クライアントは、ユニキャストバブルと返信。
The Teredo procedures are designed to enable direct connections between a Teredo host and a Teredo relay. Teredo hosts located behind a cone NAT will receive packets directly from relays; other Teredo hosts will learn the original addresses and UDP ports of third parties through the local Teredo server. In all of these cases, there is a risk that the IPv6 address of the source will be spoofed by a malevolent party. Teredo hosts must make two decisions, whether to accept the packet for local processing and whether to transmit further packets to the IPv6 address through the newly
Teredoの手順はTeredoホストとTeredoリレーとの間の直接接続を可能にするように設計されています。コーンNATの背後にあるのTeredoホストはリレーから直接パケットを受信します。他のTeredoホストはローカルのTeredoサーバを介して、元のアドレスや第三者のUDPポートを学びます。これらすべての場合には、元のIPv6アドレスが悪意のある当事者がスプーフィングされるおそれがあります。 Teredoホストはローカル処理のためにパケットを受け入れるかどうか、新しくてIPv6アドレスにさらにパケットを送信するかどうか、2つの意思決定を行う必要があります
learned IPv4 address and UDP port. The basic rule is that the hosts should be generous in what they accept and careful in what they send. Refusing to accept packets due to spoofing concerns would compromise connectivity and should only be done when there is a near certainty that the source address is spoofed. On the other hand, sending packets to the wrong address should be avoided.
IPv4アドレスとUDPポートを学びました。基本的なルールは、ホストは、彼らが送る何で彼らが受け入れるものに寛大で、注意しなければならないということです。接続性を危うくするなりすましの懸念に起因するパケットを受け入れることを拒否し、送信元アドレスが詐称されていることをほぼ確実がある場合にのみ行われるべきです。一方、間違ったアドレスにパケットを送信することは避けるべきです。
When the client wants to send a packet to a native IPv6 node or a 6to4 node, it should check whether a valid peer entry already exists for the IPv6 address of the destination. If this is not the case, the client will pick a random number (a nonce) and format an ICMPv6 Echo Request message whose source is the local Teredo address, whose destination is the address of the IPv6 node, and whose Data field is set to the nonce. (It is recommended to use a random number at least 64 bits long.) The nonce value and the date at which the packet was sent will be documented in a provisional peer entry for the IPV6 destination. The ICMPv6 packet will then be sent encapsulated in a UDP packet destined to the Teredo server IPv4 address and to the Teredo port. The rules of Section 5.2.3 specify how the reply to this packet will be processed.
クライアントは、ネイティブIPv6ノードまたは6to4のノードにパケットを送信したい場合は、それが有効なピア・エントリは、すでに先のIPv6アドレスのために存在しているかどうかを確認する必要があります。そうでない場合、クライアントは乱数（ノンス）を選択し、そのソース宛先ローカルTeredoアドレスであり、データフィールドに設定されているIPv6ノードのアドレス、及びあるICMPv6エコー要求メッセージをフォーマットしますナンス。 （少なくとも64ビット長の乱数を使用することが推奨される）ノンス値、パケットが送信された日付は、IPv6宛先の暫定ピアエントリに記載されるであろう。 ICMPv6パケットは、その後のTeredoサーバーのIPv4アドレスにとのTeredoポート宛のUDPパケットにカプセル化送信されます。 5.2.3項の規定は、このパケットへの応答が処理される方法を指定します。
The client procedures are designed to enable IPv6 connectivity through the most common types of NAT, which are commonly called "cone NAT" and "restricted cone NAT" [RFC3489]. Some NATs employ a different design; they are often called "symmetric NAT". The qualification algorithm in Section 5.2.1 will not succeed when the local NAT is a symmetric NAT.
クライアントの手順は、一般に「コーンNAT」と「制限付きコーンNAT」[RFC3489]と呼ばれているNATの最も一般的なタイプを介して、IPv6接続を可能にするために設計されています。いくつかのNATは異なるデザインを採用します。彼らはしばしば、「対称型NAT」と呼ばれています。ローカルNATが対称NATであるとき、セクション5.2.1における資格アルゴリズムは成功しません。
In many cases, it is possible to work around the limitations of these NATs by explicitly reserving a UDP port for Teredo service on a client, using a function often called "DMZ" in the NAT's manual. This port will become the "service port" used by the Teredo hosts. The implementers of Teredo functions in hosts must make sure that the value of the service port can be explicitly provisioned, so that the user can provision the same value in the host and in the NAT.
多くの場合、明示的に、多くの場合、NATのマニュアルの「DMZ」と呼ばれる機能を使用して、クライアント上のTeredoサービスのためのUDPポートを予約することにより、これらのNATの制限を回避することが可能です。このポートで、Teredoホストで使用される「サービスポート」になります。ホストでのTeredoの機能の実装は、サービスポートの値が明示的にプロビジョニングできることを確認する必要があり、ユーザーの缶の提供ホスト内とNATで同じ値となるよう。
The reservation procedure guarantees that the port mapping will remain the same for all destinations. After the explicit reservation, the qualification algorithm in Section 5.2.1 will succeed, and the Teredo client will behave as if behind a "cone NAT".
予約手続きは、ポートマッピングは、すべての宛先に同じままであることを保証します。明示的に予約した後、5.2.1での資格アルゴリズムが成功すると、Teredoクライアントは、「コーンNAT」の背後にあるかのように動作します。
When different clients use Teredo behind a single symmetric NAT, each of these clients must reserve and use a different service port.
異なるクライアントは、単一の対称型NATの背後のTeredoを使用する場合、これらのクライアントのそれぞれは、異なるサービスポートを予約して使用する必要があります。
The Teredo server is designed to be stateless. The Teredo server waits for incoming UDP packets at the Teredo Port, using the IPv4 address that has been selected for the service. In addition, the server is able to receive and transmit some packets using a different IPv4 address and a different port number.
Teredoサーバーはステートレスになるように設計されています。 Teredoサーバーは、サービスのために選択されているIPv4アドレスを使用して、Teredoのポートでの着信UDPパケットを待ちます。また、サーバは、異なるIPv4アドレスと異なるポート番号を使用していくつかのパケットを受信し、送信することができます。
The Teredo server acts as an IPv6 router. As such, it will receive Router Solicitation messages, to which it will respond with Router Advertisement messages as explained in Section 5.3.2. It may also receive other packets, for example, ICMPv6 messages and Teredo bubbles, which are processed according to the IPv6 specification.
TeredoサーバーはIPv6ルータとして動作します。このように、それは、セクション5.3.2で説明したように、それは、ルータ広告メッセージで応答する先の、ルータ要請メッセージを受信します。また、IPv6仕様に従って処理される他のパケット、例えば、ICMPv6メッセージとTeredo気泡を、受け取ることができます。
By default, the routing functions of the Teredo server are limited. Teredo servers are expected to relay Teredo bubbles, ICMPv6 Echo requests, and ICMPv6 Echo replies, but they are not expected to relay other types of IPv6 packets. Operators may, however, decide to combine the functions of "Teredo server" and "Teredo relay", as explained in Section 5.4.
デフォルトでは、Teredoサーバーのルーティング機能が制限されています。 TeredoサーバーはTeredoの泡、ICMPv6エコー要求を中継するために期待され、ICMPv6エコーは返信が、それらは、IPv6パケットの他のタイプを中継することが期待されていないされています。オペレータは、しかし、5.4節で説明したように、「Teredoサーバー」および「Teredoリレー」の機能を組み合わせることを決定することができます。
Before processing the packet, the Teredo server MUST check the validity of the encapsulated IPv6 source address, the IPv4 source address, and the UDP source port:
パケットを処理する前に、Teredoサーバーは、カプセル化されたIPv6送信元アドレス、IPv4ソースアドレス、およびUDPソースポートの有効性をチェックしなければなりません。
1) If the UDP content is not a well-formed Teredo IPv6 packet, as defined in Section 5.1.1, the packet MUST be silently discarded.
UDPの含有量が十分に形成されたTeredoのIPv6パケットでない場合は1）、5.1.1項で定義されるように、パケットは、黙って破棄しなければなりません。
2) If the UDP packet is not a Teredo bubble or an ICMPv6 message, it SHOULD be discarded. (The packet may be processed if the Teredo server also operates as a Teredo relay, as explained in Section 5.4.)
UDPパケットはTeredoバブルまたはICMPv6メッセージでない場合は2）、それは廃棄されるべきです。 （Teredoサーバーはまた、Teredoリレーとして動作する場合は、セクション5.4で説明したように、パケットは、処理されてもよいです。）
3) If the IPv4 source address is not in the format of a global unicast address, the packet MUST be silently discarded (see Section 5.2.4 for a definition of global unicast addresses).
IPv4ソースアドレスがグローバルユニキャストアドレスの形式でない場合3）、パケットは、黙って（グローバルユニキャストアドレスの定義については、セクション5.2.4を参照）を破棄しなければなりません。
4) If the IPv6 source address is an IPv6 link-local address, the IPv6 destination address is the link-local scope all routers multicast address (FF02::2), and the packet contains an ICMPv6 Router Solicitation message, the packet MUST be accepted. It MUST be discarded if the server requires secure qualification and the authentication encapsulation is absent or verification fails.
4）IPv6ソースアドレスは、IPv6リンクローカルアドレスである場合には、IPv6宛先アドレスは、すべてのルータのマルチキャストアドレス（FF02 :: 2）リンクローカルスコープであり、パケットはICMPv6のルータ要請メッセージを含む、パケットでなければなりません受け入れました。サーバがセキュア資格を必要とし、認証カプセル化が存在しないか、検証が失敗した場合にそれを捨てなければなりません。
5) If the IPv6 source address is a Teredo IPv6 address, and if the IPv4 address and UDP port embedded in that address match the IPv4 source address and UDP source port, the packet SHOULD be accepted.
5）IPv6ソースアドレスはTeredoのIPv6アドレスであり、そのアドレスに埋め込まれたIPv4アドレスとUDPポートは、IPv4ソースアドレスとUDPソースポートと一致する場合、パケットは受け入れなければならない場合。
6) If the IPv6 source address is not a Teredo IPv6 address, and if the IPv6 destination address is a Teredo address allocated through this server, the packet SHOULD be accepted.
6）場合IPv6ソースアドレスはTeredoのIPv6アドレスではなく、IPv6宛先アドレスがこのサーバを介して割り当てられたTeredoアドレスである場合、パケットは受け入れられるべきです。
7) In all other cases, the packet MUST be silently discarded.
7）他のすべての場合において、パケットは、黙って破棄しなければなりません。
The Teredo server will then check the IPv6 destination address of the encapsulated IPv6 packet:
Teredoサーバーは、カプセル化されたIPv6パケットのIPv6宛先アドレスをチェックします：
If the IPv6 destination address is the link-local scope all routers multicast address (FF02::2), or the link-local address of the server, the Teredo server processes the packet; it may have to process Router Solicitation messages and ICMPv6 Echo Request messages.
IPv6宛先アドレスがリンクローカルスコープのすべてのルータのマルチキャストアドレス（FF02 :: 2）、またはサーバのリンクローカルアドレスである場合、Teredoサーバーは、パケットを処理します。それは、ルータ要請メッセージとICMPv6エコー要求メッセージを処理する必要があります。
If the destination IPv6 address is not a global scope IPv6 address, the packet MUST NOT be forwarded.
宛先IPv6アドレスがグローバルスコープのIPv6アドレスではない場合、パケットは転送してはなりません。
If the destination address is not a Teredo IPv6 address, the packet should be relayed to the IPv6 Internet using regular IPv6 routing.
宛先アドレスがTeredoのIPv6アドレスではない場合、パケットは通常のIPv6ルーティングを使用してIPv6インターネットに中継する必要があります。
If the IPv6 destination address is a valid Teredo IPv6 address as defined in Section 2.13, the Teredo Server MUST check that the IPv4 address derived from this IPv6 address is in the format of a global unicast address; if this is not the case, the packet MUST be silently discarded.
IPv6宛先アドレスは、セクション2.13で定義されるように有効TeredoのIPv6アドレスである場合は、Teredoサーバーは、このIPv6アドレスに由来するIPv4アドレスがグローバルユニキャストアドレスの形式であることをチェックしなければなりません。そうでない場合、パケットは静かに捨てなければなりません。
If the address is valid, the Teredo server encapsulates the IPv6 packet in a new UDP datagram, in which the following parameters are set:
アドレスが有効である場合は、Teredoサーバーは、次のパラメータが設定されている新しいUDPデータグラムでIPv6パケットをカプセル化：
- The destination IPv4 address is derived from the IPv6 destination.
- 宛先IPv4アドレスは、IPv6宛先に由来します。
- The source IPv4 address is the Teredo server IPv4 address.
- 送信元IPv4アドレスは、TeredoサーバーのIPv4アドレスです。
- The destination UDP port is derived from the IPv6 destination.
- 先UDPポートがIPv6宛先に由来しています。
- The source UDP port is set to the Teredo UDP Port.
- 送信元UDPポートは、TeredoのUDPポートに設定されています。
If the destination IPv6 address is a Teredo client whose address is serviced by this specific server, the server should insert an origin indication in the first bytes of the UDP payload, as specified in Section 5.1.1. (To verify that the client is served by this server, the server compares bits 32-63 of the client's Teredo IPv6 address to the server's IPv4 address.)
宛先IPv6アドレスがアドレスがこの特定のサーバによってサービスされるTeredoクライアントである場合、サーバはセクション5.1.1で指定されるように、UDPペイロードの最初のバイトに原点指示を挿入しなければなりません。 （クライアントは、このサーバーによって提供されていることを確認するには、サーバは、サーバのIPv4アドレスに、クライアントのTeredoのIPv6アドレスのビット32-63を比較します。）
When the Teredo server receives a Router Solicitation message (RS, [RFC2461]), it retains the IPv4 address and UDP port from which the solicitation was received; these become the Teredo mapped address and Teredo mapped port of the client. The router uses these values to compose the origin indication encapsulation that will be sent with the response to the solicitation.
Teredoサーバーは、ルータ要請メッセージ（RS、[RFC2461]）を受信すると、要請が受信されたIPv4アドレスとUDPポートを保持します。これらにより、TeredoアドレスをマッピングされたとのTeredoクライアントのポートをマッピングしになります。ルータは、勧誘に応答して送信されます原産地表示のカプセル化を構成するために、これらの値を使用しています。
The Teredo server responds to the router solicitation by sending a Router Advertisement message [RFC2461]. The router advertisement MUST advertise the Teredo IPv6 prefix composed from the service
Teredoサーバーは、Router Advertisementメッセージ[RFC2461]を送信することにより、ルータ要請に応答します。ルータ通知は、サービスから構成さのTeredoのIPv6プレフィックスを通知しなければなりません
prefix and the server's IPv4 address. The IPv6 source address should be set to a Teredo link-local server address associated to the local interface; this address is derived from the IPv4 address of the server and from the Teredo port, as specified in Section 4; the cone bit is set to 1. The IPv6 destination address is set to the IPv6 source address of the RS. The Router Advertisement message must be sent over UDP to the Teredo mapped address and Teredo mapped port of the client; the IPv4 source address and UDP source port should be set to the server's IPv4 address and Teredo Port. If the cone bit of the client's IPv6 address is set to 1, the RA must be sent from a different IPv4 source address than the server address over which the RS was received; if the cone bit is set to zero, the response must be sent back from the same address.
プレフィックスとサーバのIPv4アドレス。 IPv6ソースアドレスは、ローカルインタフェースに関連のTeredoリンクローカルサーバのアドレスに設定されるべきです。セクション4で指定されるように、このアドレスは、サーバのIPv4アドレスからとTeredoポートから誘導されます。コーンビットが1に設定されているIPv6宛先アドレスは、RSのIPv6送信元アドレスに設定されています。 Router Advertisementメッセージは、アドレスをマッピングされたとのTeredoクライアントのポートをマッピングされたのTeredoにUDPを介して送信する必要があります。 IPv4ソースアドレスとUDPソースポートは、サーバのIPv4アドレスとTeredoのポートに設定する必要があります。クライアントのIPv6アドレスのコーンビットが1に設定されている場合、RAは、RSを受信した上で、サーバーのアドレスとは別のIPv4送信元アドレスから送信する必要があります。コーンビットがゼロに設定されている場合、応答は、同じアドレスから返送されなければなりません。
Before sending the packet, the Teredo server MUST check that the IPv4 destination address is in the format of a global unicast address; if this is not the case, the packet MUST be silently discarded (see Section 5.2.4 for a definition of global unicast addresses).
パケットを送信する前に、Teredoサーバーは、IPv4宛先アドレスがグローバルユニキャストアドレスの形式であることをチェックしなければなりません。そうでない場合、パケットは黙っ（グローバルユニキャストアドレスの定義については5.2.4項を参照）を捨てなければなりません。
If secure qualification is required, the server MUST insert a valid authentication parameter in the UDP packet carrying the router advertisement. The client identifier and the nonce value used in the authentication parameter MUST be the same identifier and nonce as received in the router solicitation. The confirmation byte MUST be set to zero if the client identifier is still valid, and a non-null value otherwise; the authentication value SHOULD be computed using the secret that corresponds to the client identifier.
セキュアな資格が必要な場合は、サーバがルータ広告を運ぶUDPパケットに有効な認証パラメータを挿入しなければなりません。クライアント識別子と認証パラメータに使用されるノンス値はルータ要請で受信されたのと同じ識別子とノンスなければなりません。クライアント識別子がまだ有効であり、そうでない場合はnull以外の値ならば確認バイトをゼロに設定しなければなりません。認証値は、クライアント識別子に対応する秘密鍵を使用して計算されるべきである（SHOULD）。
Teredo relays are IPv6 routers that advertise reachability of the Teredo service IPv6 prefix through the IPv6 routing protocols. (A minimal Teredo relay may serve just a local host, and would not advertise the prefix beyond this host.) Teredo relays will receive IPv6 packets bound to Teredo clients. Teredo relays should be able to receive packets sent over IPv4 and UDP by Teredo clients; they may apply filtering rules, e.g., only accept packets from Teredo clients if they have previously sent traffic to these Teredo clients.
Teredoリレーは、IPv6ルーティングプロトコルを通じてTeredoサービスのIPv6プレフィックスの到達可能性を広告のIPv6ルータです。 （最小限のTeredoリレーは、単にローカルホストを果たすことができるし、このホストを超えてプレフィックスを通知しません。）のTeredoリレーはTeredoクライアントにバインドされたIPv6パケットを受信します。 Teredoリレーは、Teredoクライアントにより、IPv4およびUDPを介して送信されるパケットを受信することができるはずです。彼らは以前にこれらのTeredoクライアントへのトラフィックを送信した場合のみ、Teredoクライアントからのパケットを受け入れる、例えば、フィルタリングルールを適用することができます。
The receiving and sending rules used by Teredo relays are very similar to those of Teredo clients. Teredo relays must use a Teredo service port to transmit packets to Teredo clients; they must maintain a "list of peers", identical to the list of peers maintained by Teredo clients.
Teredoリレーで使用される受信と送信の規則は、Teredoクライアントのものと非常に似ています。 Teredoリレーは、Teredoクライアントにパケットを送信するためにTeredoサービスポートを使用する必要があります。彼らは、Teredoクライアントによって維持ピアのリストと同じで、「ピアのリスト」を維持しなければなりません。
When a Teredo relay has to transmit a packet to a Teredo client, it examines the destination IPv6 address. By definition, the Teredo relays will only send over UDP IPv6 packets whose IPv6 destination address is a valid Teredo IPv6 address.
Teredoリレーは、Teredoクライアントにパケットを送信しなければならない場合は、宛先IPv6アドレスを調べます。定義上、のTeredoリレーのみがIPv6宛先アドレス有効TeredoのIPv6アドレスであるUDP、IPv6パケットを介して送信されます。
Before processing these packets, the Teredo Relay MUST check that the IPv4 destination address embedded in the Teredo IPv6 address is in the format of a global unicast address; if this is not the case, the packet MUST be silently discarded (see Section 5.2.4 for a definition of global unicast addresses).
これらのパケットを処理する前に、TeredoリレーからTeredo IPv6アドレス内に埋め込まれたIPv4宛先アドレスがグローバルユニキャストアドレスの形式であることをチェックしなければなりません。そうでない場合、パケットは黙っ（グローバルユニキャストアドレスの定義については5.2.4項を参照）を捨てなければなりません。
The relay then checks if there is an entry for this IPv6 address in the list of recent Teredo peers, and if the entry is still valid. The relay then performs the following:
最近のTeredoピアのリストで、このIPv6アドレスのエントリがある場合、そのエントリがまだ有効である場合、リレーは、チェックします。リレーは、次を実行します。
1) If there is an entry for that IPv6 address in the list of peers, and if the status of the entry is set to "trusted", the IPv6 packet should be sent over UDP to the mapped IPv4 address and mapped UDP port of the entry. The relay updates the date of last transmission in the peer entry.
1）がピアのリストでそのIPv6アドレスのエントリがあり、エントリのステータスが「信頼できる」に設定されている場合、IPv6パケットがマッピングされたIPv4アドレスとのマッピングされたUDPポートにUDPを介して送信されるべきであるならばエントリ。リレーは、ピアエントリで最後の送信の日付を更新します。
2) If there is no trusted entry in the list of peers, and if the destination is a Teredo IPv6 address in which the cone bit is set to 1, the packet is sent over UDP to the mapped IPv4 address and mapped UDP port extracted from that IPv6 address.
2）ピアのリストに信頼できるエントリがない場合、宛先はコーンビットが1に設定され、パケットがマッピングされたIPv4アドレスにUDPを介して送信し、マッピングされたUDPポートから抽出されたTeredoのIPv6アドレスですかそのIPv6アドレス。
3) If there is no trusted entry in the list of peers, and if the destination is a Teredo IPv6 address in which the cone bit is set to 0, the Teredo relay creates a bubble whose source address is set to a local IPv6 address, and whose destination address is set to the Teredo IPv6 address of the packet's destination. The bubble is sent to the server address corresponding to the Teredo destination. The entry becomes trusted when a bubble or another packet is received from this IPv6 address; if no such packet is received before a time-out of 2 seconds, the Teredo relay may repeat the bubble, up to three times. If the relay fails to receive a bubble after these repetitions, the entry is removed from the list of peers. The relay MAY queue packets bound to untrusted entries; the queued packets SHOULD be de-queued and forwarded when the entry becomes trusted; they SHOULD be deleted if the entry is deleted. To avoid denial of service attacks, the relays SHOULD limit the number of packets in such queues.
ピアのリストに信頼できるエントリがない場合、宛先はコーンビットが0に設定されたTeredoのIPv6アドレスである場合3）、Teredoリレーは、そのソースアドレスローカルIPv6アドレスに設定されている泡を生成しますそして、宛先アドレスがパケットの宛先のTeredoのIPv6アドレスに設定されています。バブルは、Teredoの先に対応するサーバのアドレスに送信されます。バブルまたは他のパケットは、このIPv6アドレスから受信されたときにエントリが信頼になります。そのようなパケットが2秒のタイムアウト前に受信されない場合、Teredoリレーは3回まで、バブルを繰り返します。リレーは、これらの繰り返しの後、バブルの受信に失敗した場合、エントリは、ピアのリストから削除されます。リレーは、信頼されていないエントリにバインドされたパケットを待機させることができます。キューイングされたパケットは、デキューに入れられ、エントリが信頼になったときに転送する必要があります。エントリが削除されている場合、それらは削除する必要があります。サービス拒否（DoS）攻撃を避けるために、リレーは、そのようなキューのパケットの数を制限する必要があります。
In cases 2 and 3, the Teredo relay should create a peer entry for the IPv6 address; the entry status is marked as trusted in case 2 (cone NAT) and not trusted in case 3. In case 3, if the Teredo relay happens to be located behind a non-cone NAT, it should also send a bubble directly to the mapped IPv4 address and mapped port number of the Teredo destination. This will "open the path" for the return bubble from the Teredo client.
ケース2及び3において、Teredoリレーは、IPv6アドレスのピアエントリを作成する必要があります。ケース2（コーンNAT）に信頼され、ケース3はケース3に信頼できないように、エントリのステータスはTeredoリレーは、非コーンNATの背後に位置するように発生した場合、それはまた、マップされた直接バブルを送信する必要があり、マークされていますIPv4アドレスとTeredo先のマッピングされたポート番号。これは、Teredoクライアントからの戻りバブルのための「道を開く」します。
For reliability reasons, relays MAY decide to ignore the value of the cone bit in the flag, and always perform the "case 3", i.e., treat all Teredo peers as if they were located behind a non-cone NAT. This will result in some increase in traffic, but may avoid
信頼性の理由から、リレーはフラグにコーンビットの値を無視し、常に「ケース3」を実行、すなわちを、それらが非コーンNATの後ろに位置しているかのように、すべてのTeredoピアを治療することもできます。これは、トラフィックのいくつかの増加になりますが、回避することができます
reliability issues if the determination of the NAT status was for some reason erroneous. For the same reason, relays MAY also decide to always send a direct bubble to the mapped IPv4 address and mapped port number of the Teredo destination, even if they do not believe that they are located behind a non-cone NAT.
NAT状態の決意が誤っていくつかの理由のためだった場合は信頼性の問題。同じ理由で、リレーはまた、彼らは、彼らが非コーンNATの背後に配置されていることを信じていない場合でも、常にマッピングされたIPv4アドレスとTeredoの先のマップされたポート番号に直接泡を送信することもできます。
The Teredo relay may receive packets from Teredo clients; the packets should normally only be sent by clients to which the relay previously transmitted packets, i.e., clients whose IPv6 address is present in the list of peers. Relays, like clients, use the packet reception procedure to maintain the date and time of the last interaction with the Teredo server and the "list of recent peers".
Teredoリレーは、Teredoクライアントからのパケットを受信することもできます。パケットが正常にのみクライアントによって送信すべき中継先に送信されたパケット、すなわち、そのIPv6のアドレスのピアのリストに存在するクライアント。リレーは、クライアントのように、Teredoサーバーと「最近のピアのリスト」との最後の対話の日付と時刻を維持するために、パケット受信手順を使用します。
When a UDP packet is received over the Teredo service port, the Teredo relay checks that it contains a valid IPv6 packet as specified in [RFC2460]. If this is not the case, the packet is silently discarded.
UDPパケットはTeredoサービスポート経由で受信した場合、それは[RFC2460]で指定された有効なIPv6パケットが含まれているTeredoリレーをチェック。そうでない場合、パケットは黙って破棄されます。
Then, the Teredo relay examines whether the IPv6 source address is a valid Teredo address, and if the mapped IPv4 address and mapped port match the IPv4 source address and port number from which the packet is received. If this is not the case, the packet is silently discarded.
次いで、Teredoリレーは、IPv6ソースアドレスが有効Teredoアドレスであるか否かを調べ、マッピングされたIPv4アドレスであれば、ポートは、パケットが受信されるIPv4ソースアドレスとポート番号と一致してマッピングされました。そうでない場合、パケットは黙って破棄されます。
The Teredo relay then examines whether there is an entry for the IPv6 source address in the list of recent peers. If this is not the case, the packet may be silently discarded. If this is the case, the entry status is set to "trusted"; the relay updates the "date and time of the last interaction" to the current date and time.
Teredoリレーは、最近のピアのリストにおけるIPv6送信元アドレスのエントリがあるかどうかを調べます。そうでない場合、パケットは黙って破棄されることがあります。このような場合は、エントリのステータスが「信頼できる」に設定されています。リレーは、現在の日付と時刻を「最後の相互作用の日付と時刻」を更新します。
Finally, the relay examines the destination IPv6 address. If the destination belongs to a range of IPv6 addresses served by the relay, the packet SHOULD be accepted and forwarded to the destination. In the other cases, the packet SHOULD be silently discarded.
最後に、リレーは、宛先IPv6アドレスを調べます。宛先は、リレーによって提供IPv6アドレスの範囲に属している場合、パケットは受け入れられ、宛先に転送されるべきである（SHOULD）。他の例では、パケットは静かに捨てられるべきです。
Because Teredo servers can relay Teredo packets over IPv6, all Teredo servers must be capable of behaving as Teredo relays. There is, however, no requirement that Teredo relays behave as Teredo servers.
TeredoサーバーがIPv6上でのTeredoパケットを中継することができますので、すべてのTeredoサーバーで、Teredoリレーとして振る舞うことが可能でなければなりません。 TeredoリレーはTeredoサーバーとして動作要件は、しかし、ありません。
The dual role of server and relays implies an additional complexity for the programming of servers: the processing of incoming packets should be a combination of the server processing rules defined in Section 5.3.1, and the relay processing rules defined in Section 5.4.2. (Section 5.3 only specifies the rules implemented by a pure server, not a combination relay+server.)
サーバーとリレーの二重の役割は、サーバのプログラミングのための追加的な複雑さを意味します：着信パケットの処理は、セクション5.3.1、および5.4.2節で定義された中継処理ルールで定義されたサーバ処理ルールの組み合わせでなければなりません。 （セクション5.3は純粋なサーバーではなく、組み合わせリレー+サーバによって実装ルールを指定します。）
Teredo is designed as an interim transition mechanism, and it is important that it should not be used any longer than necessary. The "sunset" procedure will be implemented by Teredo clients, servers, and relays, as specified in this section.
Teredoは、中間遷移機構として設計され、もはや必要以上に使用すべきではないことが重要です。このセクションで指定されている「夕焼け」の手順では、Teredoクライアント、サーバ、およびリレーによって実装されます。
The Teredo-capable nodes MUST NOT behave as Teredo clients if they already have IPv6 connectivity through any other means, such as native IPv6 connectivity. In particular, nodes that have a global IPv4 address SHOULD obtain connectivity through the 6to4 service rather than through the Teredo service. The classic reason why a node that does not need connectivity would still enable the Teredo service is to guarantee good performance when interacting with Teredo clients; however, a Teredo-capable node that has IPv4 connectivity and that has obtained IPv6 connectivity outside the Teredo service MAY decide to behave as a Teredo relay, and still obtain good performance when interacting with Teredo clients.
彼らはすでに、このようなネイティブIPv6接続など他の手段を介して、IPv6接続を持っている場合のTeredo可能なノードは、Teredoクライアントとして動作してはなりません。具体的には、グローバルIPv4アドレスを持つノードは、6to4サービスを介してではなく、Teredoサービスを介して接続を取得する必要があります。接続を必要としないノードがまだTeredoサービスを有効にする理由の古典的な理由は、Teredoクライアントと対話するときに良好な性能を保証することです。しかし、IPv4接続を有し、それはTeredoサービス外のIPv6接続性を得ているのTeredo対応ノードは、Teredoリレーとして動作することを決定し、さらにTeredoクライアントと相互作用するときに良好な性能を得ることができます。
The Teredo servers are expected to participate in the sunset procedure by announcing a date at which they will stop providing the service. This date depends on the availability of alternative solutions to their clients, such as "dual-mode" gateways that behave simultaneously as IPv4 NATs and IPv6 routers. Most Teredo servers will not be expected to operate more than a few years. Teredo relays are expected to have the same life span as Teredo servers.
Teredoサーバーは、それらがサービスの提供を停止するときの日付を発表し日没の手続に参加することが期待されます。この日付は、IPv4のNATのとIPv6ルータとして同時に振る舞う「デュアルモード」のゲートウェイとして顧客への代替ソリューションの可用性に依存します。ほとんどのTeredoサーバーは、数年以上に動作することが期待されることはありません。 TeredoリレーはTeredoサーバーと同じ寿命を有することが期待されます。
Teredo defines a NAT traversal solution that can be provided using very little resource at the server. Ongoing IETF discussions have outlined the need for both a solution like Teredo and a more controlled NAT traversal solution, using configured tunnels to a service provider [RFC3904]. This section provides a tentative analysis of how Teredo could be extended to also support a configured tunnel service.
Teredoは、サーバーで非常に少ないリソースを使用して提供することができるNATトラバーサルソリューションを定義します。進行中のIETF議論は、サービスプロバイダ[RFC3904]に設定されたトンネルを使用して、Teredoのようなソリューションと、より制御NATトラバーサルソリューションの両方の必要性を概説しています。このセクションでは、Teredoのも構成トンネルサービスをサポートするように拡張することができる方法の暫定的な分析を提供します。
It may be possible to design a tunnel server protocol that is compatible with Teredo, in the sense that the same client could be used either in the Teredo service or with a tunnel service. In fact, this could be done by configuring the client with:
同じクライアントがTeredoサービスまたはトンネルサービスのいずれかで使用することができるという意味で、Teredoのと互換性のあるトンネルサーバプロトコルを設計することも可能です。実際には、これは使用してクライアントを構成することによって行うことができます。
- The IPv4 address of a Teredo server that acts as a tunnel broker - A client identifier - A shared secret with that server - An agreed-upon authentication algorithm.
- クライアント識別子 - - そのサーバとの共有秘密 - 合意された認証アルゴリズムトンネルブローカーとして働くTeredoサーバーのIPv4アドレス。
The Teredo client would use the secure qualification procedure, as specified in Section 5.2.2. Instead of returning a Teredo prefix in the router advertisement, the server would return a globally routable IPv6 prefix; this prefix could be permanently assigned to the client, which would provide the client with a stable address. The server would have to keep state, i.e., memorize the association between the prefix assigned to the client and the mapped IPv4 address and mapped UDP port of the client.
5.2.2項に指定されているTeredoクライアントは、セキュアな資格の手順を使用します。代わりに、ルータ広告でのTeredoプレフィックスを返すので、サーバーは、グローバルにルーティング可能なIPv6プレフィックスを返します。この接頭辞は、永続的に安定したアドレスをクライアントに提供するクライアントに割り当てることができます。サーバーは、クライアントに割り当てられたプレフィックスとマッピングされたIPv4アドレスとクライアントのマッピングされたUDPポートとの関連付けを覚え、すなわち、状態を維持しなければなりません。
The Teredo server would advertise reachability of the client prefix to the IPv6 Internet. Any packet bound to that prefix would be transmitted to the mapped IPv4 address and mapped UDP port of the client.
Teredoサーバーは、IPv6インターネットへのクライアントプレフィックスの到達可能性を広告ます。その接頭辞にバインドされた任意のパケットがマッピングされたIPv4アドレスとクライアントのマッピングされたUDPポートに送信されます。
The Teredo client, when it receives the prefix, would notice that this prefix is a global IPv6 prefix, not in the form of a Teredo prefix. The client would at that point recognize that it should operate in tunnel mode. A client that operates in tunnel mode would execute a much simpler transmission procedure: it would forward any packet sent to the Teredo interface to the IPv4 address and Teredo UDP port of the server.
それは接頭辞を受信Teredoクライアントは、この接頭辞がないのTeredoプレフィックスの形で、グローバルIPv6プレフィックスであることに気づくでしょう。クライアントは、その時点で、それはトンネルモードで動作すべきであることを認識するであろう。トンネルモードで動作し、クライアントは、はるかに簡単な送信手順を実行します：それは、サーバのIPv4アドレスとTeredo UDPポートへのTeredoインターフェイスに送信されたすべてのパケットを転送します。
The Teredo client would have to perform the maintenance procedure described in Section 5.2.5. The server would receive the router solicitation, and could notice a possible change of mapped IPv4 address and mapped UDP port that could result from the reconfiguration of the mappings inside the NAT. The server should continue advertising the same IPv6 prefix to the client, and should update the mapped IPv4 address and mapped UDP port associated to this prefix, if necessary.
Teredoクライアントは、5.2.5項で説明したメンテナンス手順を実行する必要があります。サーバは、ルータ要請を受け取ることになる、とマッピングされたIPv4アドレスとNATの内側のマッピングの再構成から生じる可能性がマッピングされたUDPポートの可能性の変化に気づくことができました。サーバーは、クライアントに同じIPv6プレフィックスの広告を出し続けなければならないし、必要であれば、この接頭辞に関連付けられているマッピングされたIPv4アドレスとマッピングされたUDPポートを更新する必要があります。
There is as yet no consensus that a tunnel-mode extension to Teredo should be developed. This section is only intended to provide suggestions to the future developers of such services. Many details would probably have to be worked out before a tunnel-mode extension would be agreed upon.
Teredoへのトンネルモードの拡張を開発しなければならないこととしてまだコンセンサスは存在しません。このセクションでは、唯一のそのようなサービスの将来の開発者に提案を提供することを意図しています。トンネルモードの延長が合意されることになる前に、多くの詳細は、おそらく働いたしなければならないであろう。
The main objective of Teredo is to provide nodes located behind a NAT with a globally routable IPv6 address. The Teredo nodes can use IP security (IPsec) services such as Internet Key Exchange (IKE), Authentication Header (AH), or Encapsulation Security Payload (ESP) [RFC4306, RFC4302, RFC4303], without the configuration restrictions still present in "Negotiation of NAT-Traversal in the IKE" [RFC3947]. As such, we can argue that the service has a positive effect on network security. However, the security analysis must also envisage the negative effects of the Teredo services, which we can group in four categories: security risks of directly connecting a node to the IPv6 Internet, spoofing of Teredo servers to enable a man-in-the-middle attack, potential attacks aimed at denying the Teredo service to a Teredo client, and denial of service attacks against non-Teredo participating nodes that would be enabled by the Teredo service.
Teredoのの主な目的は、グローバルにルーティング可能なIPv6アドレスをNATの背後にあるノードを提供することです。 Teredoのノードは交渉」で、まだ本構成の制限なしに、インターネットキー交換（IKE）、認証ヘッダー（AH）、またはカプセル化セキュリティペイロード（ESP）[RFC4306、RFC4302、RFC4303]のようにIPセキュリティ（IPsec）サービスを使用することができますIKEでのNATトラバーサル」[RFC3947]の。そのため、我々は、サービスがネットワークセキュリティにプラスの効果を持っていると主張することができます。マン・イン・ザ・ミドルを有効にするには、直接IPv6インターネットにノードを接続するセキュリティリスク、Teredoサーバーのなりすまし：しかし、セキュリティ分析は、4つのカテゴリーで私達ができるグループのTeredoサービス、の負の影響を想定しなければなりません攻撃、TeredoクライアントにTeredoサービスを拒否し、非のTeredoに対するサービス拒否攻撃は、Teredoサービスによって有効にされるだろう参加ノードを目的とした潜在的な攻撃。
In the following, we review in detail these four types of issues, and we present mitigating strategies for each of them.
以下では、我々は詳細に問題のこれらの4種類を確認し、我々は彼らのそれぞれについて、軽減戦略を提示します。
The very purpose of the Teredo service is to make a machine reachable through IPv6. By definition, the machine using the service will give up whatever firewall service was available in the NAT box, however limited this service may be [RFC2993]. The services that listen to the Teredo IPv6 address will become the potential target of attacks from the entire IPv6 Internet. This may sound scary, but there are three mitigating factors.
Teredoサービスの非常に目的は、IPv6経由のマシンが到達可能にすることです。定義では、サービスを利用して、マシンはサービスがNATボックスで利用可能だったものは何でもファイアウォールあきらめるだろう、しかし、このサービスは[RFC2993]かもしれ制限されています。 TeredoのIPv6アドレスを聞くサービスは、全体のIPv6インターネットからの攻撃の潜在的なターゲットとなります。これは怖い聞こえるかもしれませんが、3つの問題を緩和する要素があります。
The first mitigating factor is the possibility to restrict some services to only accept traffic from local neighbors, e.g., using link-local addresses. Teredo does not support communication using link-local addresses. This implies that link-local services will not be accessed through Teredo, and will be restricted to whatever other IPv6 connectivity may be available, e.g., direct traffic with neighbors on the local link, behind the NAT.
最初緩和する要素は、リンクローカルアドレスを使用して、例えば、地元の隣人からのトラフィックを受け入れるように、いくつかのサービスを制限する可能性があります。 Teredoは、リンクローカルアドレスを使用して通信をサポートしていません。これは、リンクローカルサービスは、Teredoのを介してアクセスすることはないだろう、と他のIPv6接続が利用できるものは何でもに制限されることを意味し、例えば、NATの背後にあるローカルリンク、上の隣人との直接トラフィック。
The second mitigating factor is the possible use of a "local firewall" solution, i.e., a piece of software that performs locally the kind of inspection and filtering that is otherwise performed in a perimeter firewall. Using such software is recommended.
第二の緩和因子は、「ローカルファイアウォール」溶液の可能な使用である、すなわち、局所的に別段の境界ファイアウォールで実行される検査とフィルタリングの種類を実行するソフトウェアの一部。そのようなソフトウェアを使用することをお勧めします。
The third mitigating factor is the availability of IP security (IPsec) services such as IKE, AH, or ESP [RFC4306, RFC4302, RFC4303]. Using these services in conjunction with Teredo is a good policy, as it will protect the client from possible attacks in intermediate servers such as the NAT, the Teredo server, or the Teredo relay. (However, these services can be used only if the parties in the communication can negotiate a key, which requires agreeing on some credentials; this is known to be a hard problem.)
第三の緩和因子は、IKE、AHまたはESP [RFC4306、RFC4302、RFC4303]としてIPセキュリティ（IPsec）サービスの可用性です。 Teredoのと併せて、これらのサービスを使用すると、それは、そのようなNAT、Teredoサーバー、またはTeredoリレーとして中間サーバで可能な攻撃からクライアントを保護するよう、良い政策です。 （ただし、これらのサービスは、通信における当事者が、いくつかの資格情報について合意する必要がキーを交渉することができた場合にのみ使用することができます。これは難しい問題であることが知られています。）
The goal of the Teredo service is to provide hosts located behind a NAT with a globally reachable IPv6 address. There is a possible class of attacks against this service in which an attacker somehow intercepts the router solicitation, responds with a spoofed router advertisement, and provides a Teredo client with an incorrect address. The attacker may have one of two objectives: it may try to deny service to the Teredo client by providing it with an address that is in fact unreachable, or it may try to insert itself as a relay for all client communications, effectively enabling a variety of "man-in-the-middle" attack.
Teredoサービスの目標は、世界的に到達可能なIPv6アドレスをNATの背後にあるホストを提供することです。攻撃者は何らかの方法で、ルータ要求をインターセプトし、偽装されたルータ通知に応答し、誤ったアドレスでTeredoクライアントを提供するこのサービスに対する攻撃の可能性のあるクラスがあります。それは実際には到達できないアドレスでそれを提供することにより、Teredoクライアントへのサービスを拒否しようとすること、またはそれは、すべてのクライアント通信のためのリレーとしての地位を挿入しようと、効果的にさまざまな可能：攻撃者は、二つの目的の一つであってもよいです"男-in-the-middle" 攻撃の。
The simple nonce verification procedure described in Section 5.2.2 provides a first level of protection against attacks in which a third party tries to spoof the server. In practice, the nonce procedure can be defeated only if the attacker is "on path".
5.2.2項で説明したシンプルなナンス検証手順は、第三者がサーバーを偽装しようとする攻撃に対する保護の最初のレベルを提供します。実際には、ナンス手順は、攻撃者が「パス上に」ある場合にのみ無効にすることができます。
If client and server share a secret and agree on an authentication algorithm, the secure qualification procedure described in Section 5.2.2 provides further protection. To defeat this protection, the attacker could try to obtain a copy of the secret shared between client and server. The most likely way to obtain the shared secret is to listen to the traffic and mount an offline dictionary attack; to protect against this attack, the secret shared between client and server should contain sufficient entropy. (This probably requires some automated procedure for provisioning the shared secret and the algorithm.)
認証アルゴリズム上のクライアントとサーバの共有秘密と同意する場合は、5.2.2項で説明した安全な資格手順は、さらに保護を提供します。この保護を倒すためには、攻撃者がクライアントとサーバの間で共有される秘密のコピーを入手しようとすることができます。共有秘密を得るための最も可能性の高い方法は、トラフィックに耳を傾け、オフライン辞書攻撃をマウントすることです。この攻撃から保護するために、クライアントとサーバの間で共有される秘密は、十分なエントロピーを含まなければなりません。 （これはおそらく共有の秘密アルゴリズムをプロビジョニングするために、いくつかの自動化された手順が必要です。）
If the shared secret contains sufficient entropy, the attacker would have to defeat the one-way function used to compute the authentication value. This specification suggests a default algorithm combining HMAC and MD5. If the protection afforded by MD5 was not deemed sufficient, clients and servers can agree to use a different algorithm, e.g., SHA1.
共有秘密は、十分なエントロピーが含まれている場合、攻撃者は、認証値を計算するのに使用される一方向関数を倒す必要があります。この仕様は、HMACやMD5を組み合わせたデフォルトのアルゴリズムを提案します。 MD5による保護が十分でないと考えた場合、クライアントとサーバは別のアルゴリズム、例えば、SHA1を使用することに同意することができます。
Another way to defeat the protection afforded by the authentication procedure is to mount a complex attack, as follows:
次のように認証手続きによる保護を無効にする別の方法は、複雑な攻撃をマウントすることです：
1) Client prepares router solicitation, including authentication encapsulation.
1）クライアントは、認証のカプセル化を含め、ルータ要請を準備します。
2) Attacker intercepts the solicitation, and somehow manages to prevent it from reaching the server, for example, by mounting a short-duration DoS attack against the server.
2）攻撃者は要請を傍受し、何とかサーバに対して短時間DoS攻撃を実装することによって、例えば、サーバに到達しないように管理します。
3) Attacker replaces the source IPv4 address and source UDP port of the request by one of its own addresses and port, and forwards the modified request to the server.
3）攻撃者は、自身のアドレスとポートのうちの1つによって要求の送信元IPv4アドレスとソースUDPポートを置き換え、そしてサーバーに修正された要求を転送します。
4) Server dutifully notes the IPv4 address from which the packet is received, verifies that the Authentication encapsulation is correct, prepares a router advertisement, signs it, and sends it back to the incoming address, i.e., the attacker.
サーバが忠実パケットが受信されたIPv4アドレスをノート4）、認証カプセル化が正しいことを検証し、標識を、ルータ広告を作成し、攻撃者、即ち、着信アドレスに送り返します。
5) Attacker receives the advertisement, takes note of the mapping, replaces the IPv4 address and UDP port by the original values in the intercepted message, and sends the response to the client.
5）攻撃者は、広告を受信マッピングの注意を要し、傍受メッセージの元の値でIPv4アドレスとUDPポートを置き換えて、クライアントに応答を送信します。
6) Client receives the advertisement, notes that the authentication header is present and is correct, and uses the proposed prefix and the mapped addresses in the origin indication encapsulation.
6）クライアントは、広告を受信する認証ヘッダが存在し、正しく、原点指示カプセル化で提案されているプレフィックスとマッピングされたアドレスを使用していることを指摘しています。
The root cause of the problem is that the NAT is, in itself, a man-in-the-middle attack. The Authentication encapsulation covers the encapsulated IPv6 packet, but does not cover the encapsulating IPv4 header and UDP header. It is very hard to devise an effective authentication scheme, since the attacker does not do anything else than what the NAT legally does!
問題の根本的な原因は、NATは、それ自体が、man-in-the-middle攻撃であるということです。認証カプセル化は、カプセル化されたIPv6パケットを覆うが、カプセル化IPv4ヘッダ及びUDPヘッダをカバーしていません。攻撃者は、NATが合法的に何をするかよりも、何もしませんので、効果的な認証スキームを考案することは非常に難しいです！
However, there are several mitigating factors that lead us to avoid worrying too much about this attack. In practice, the gain from the attack is either to deny service to the client or to obtain a "man-in-the-middle" position. However, in order to mount the attack, the attacker must be able to suppress traffic originating from the client, i.e., have denial of service capability; the attacker must also be able to observe the traffic exchanged between client and inject its own traffic in the mix, i.e., have man-in-the-middle capacity. In summary, the attack is very hard to mount, and the gain for the attacker in terms of "elevation of privilege" is minimal.
しかし、この攻撃についてはあまり心配を避けるために私たちを導く、いくつかの問題を緩和する要素があります。実際には、攻撃からのゲインは、クライアントへのサービスを拒否するか、「のman-in-the-middle」位置を取得するかのいずれかです。しかし、攻撃をマウントするためには、攻撃者がクライアントから発信されたトラフィックを抑制することができなければならない、すなわち、サービス機能の拒否を持っています。攻撃者はまた、すなわち、のman-in-the-middle能力を持って、クライアント間で交換トラフィックを監視することが可能とミックスの中で、自身のトラフィックを注入しなければなりません。要約すると、攻撃はマウントすることは非常に困難であり、「特権の昇格」の観点から、攻撃者のためのゲインは最小となります。
A similar attack is described in detail in the security section of [RFC3489].
同様の攻撃は、[RFC3489]のセキュリティセクションに詳細に記載されています。
An attacker may try to use Teredo either to pass itself for another IPv6 host or to place itself as a man-in-the-middle between a Teredo host and a native IPv6 host. The attacker will mount such attacks by spoofing a Teredo relay, i.e., by convincing the Teredo host that packets bound to the native IPv6 host should be relayed to the IPv4 address of the attacker.
攻撃者は、別のIPv6ホストに対して自身を渡すかのTeredoホストとネイティブIPv6ホスト間のman-in-the-middleとしての地位を配置するためのいずれかのTeredoを使用しようとするかもしれません。攻撃者は、ネイティブIPv6ホストに結合されたパケットが攻撃者のIPv4アドレスに中継しなければならないのTeredoホストを説得することにより、即ち、Teredoリレーを偽装することによって、そのような攻撃をマウントします。
The possibility of the attack derives from the lack of any algorithmic relation between the IPv4 address of a relay and the native IPv6 addresses served by these relay. A Teredo host cannot decide just by looking at the encapsulating IPv4 and UDP header whether or not a relay is legitimate. If a Teredo host decided to simply trust the incoming traffic, it would easily fall prey to a relay-spoofing attack.
攻撃の可能性は、リレーのIPv4アドレスとこれらのリレーが提供するネイティブのIPv6アドレス間のいずれかのアルゴリズムの関係の欠如に由来します。 Teredoホストだけリレーが正当であるか否かをカプセル化IPv4とUDPヘッダを見ることによって決定することができません。 Teredoホストは単に着信トラフィックを信頼することを決定した場合、それは簡単にリレースプーフィング攻撃の餌食になるでしょう。
The attack is mitigated by the "direct IPv6 connectivity test" specified in Section 5.2.9. The test specifies a relay discovery procedure secured by a nonce. The nonce is transmitted from the Teredo host to the destination through Teredo server, which the client normally trusts. The response arrives through the "natural" relay, i.e., the relay closest to the IPv6 destination. Sending traffic to this relay will place it out of reach of attackers that are not on the direct path between the Teredo host and its IPv6 peer.
攻撃は5.2.9項で指定された「直接IPv6接続テスト」によって軽減されます。テストはナンスによって保護リレー発見手順を指定します。ナンスは、クライアントは通常、信頼Teredoサーバー、経由のTeredoホストから宛先に送信されます。応答が「自然な」リレー、すなわち、IPv6宛先に最も近いリレーを介して到着します。このリレーにトラフィックを送信するのTeredoホストとそのIPv6のピア間の直接経路上にない攻撃者の手の届かないところに置きます。
End-to-end security protections are required to defend against spoofing attacks if the attacker is on the direct path between the Teredo host and its peer.
エンドツーエンドのセキュリティ保護は、攻撃者がTeredoホストとそのピア間の直接経路上にある場合は、スプーフィング攻撃を防御するために必要とされています。
The most effective line of defense of a Teredo client is probably not to try to secure the Teredo service itself: even if the mapping can be securely obtained, the attacker would still be able to listen to the traffic and send spoofed packets. Rather, the Teredo client should realize that, because it is located behind a NAT, it is in a
マッピングを確実に得ることができたとしても、攻撃者はまだトラフィックに耳を傾け、偽装されたパケットを送信することができるだろう：Teredoクライアントの防衛の最も効果的なラインは、Teredoサービス自体を確保しようとすることはおそらくありません。むしろ、Teredoクライアントは、それがNATの背後に配置されているので、それがAである、ということを理解すべきです
situation of vulnerability; it should systematically try to encrypt its IPv6 traffic, using IPsec. Even if the IPv4 and UDP headers are vulnerable, the use of IPsec will effectively prevent spoofing and listening of the IPv6 packets by third parties. By providing each client with a global IPv6 address, Teredo enables the use of IPsec without the configuration restrictions still present in "Negotiation of NAT-Traversal in the IKE" [RFC3947] and ultimately enhances the security of these clients.
脆弱性の状況。それが体系的にIPsecを使用して、そのIPv6トラフィックを暗号化するために試してみてください。 IPv4およびUDPヘッダが脆弱である場合であっても、IPsecの使用が効果的に第三者によるIPv6パケットのなりすましやリスニングを防ぐことができます。グローバルIPv6アドレスを使用して、各クライアントを提供することにより、Teredoは「IKEでのNATトラバーサルの交渉」で、まだ本構成の制限[RFC3947]なしのIPsecの使用を可能にし、最終的にこれらのクライアントのセキュリティを強化します。
Our analysis outlines five ways to attack the Teredo service. There are countermeasures for each of these attacks.
我々の分析は、Teredoサービスを攻撃する5つの方法の概要を説明します。これらの攻撃のそれぞれのための対策があります。
An attack can be mounted on the IPv6 side of the service by setting up a rogue relay and letting that relay advertise a route to the Teredo IPv6 prefix. This is an attack against IPv6 routing, which can also be mitigated by the same kind of procedures used to eliminate spurious route advertisements. Dual-stack nodes that implement "host local" Teredo relays are impervious to this attack.
攻撃は、不正なリレーを設定し、そのリレーは、TeredoのIPv6プレフィックスへのルートをアドバタイズさせることにより、サービスのIPv6の側に搭載することができます。これはまた、偽経路広告を排除するために使用される手順と同じ種類によって緩和することができるIPv6ルーティングに対する攻撃です。 Teredoリレーはこの攻撃を通さない「ローカルホスト」を実装デュアルスタックノード。
In Section 7.2, we discussed the use of spoofed router advertisements to insert an attacker in the middle of a Teredo conversation. The spoofed router advertisements can also be used to provision a client with an incorrect address, pointing to either a non-existing IPv4 address or the IPv4 address of a third party.
7.2節では、我々は、Teredoの会話の途中で攻撃を挿入するために偽装されたルータアドバタイズメントの使用を議論しました。偽装されたルータ広告は、非既存のIPv4アドレスまたは第三者のIPv4アドレスのどちらかを指して、誤ったアドレスで提供するクライアントを使用することができます。
The Teredo client will detect the attack when it fails to receive traffic through the newly acquired IPv6 address. The attack can be mitigated by using the authentication encapsulation.
それは新たに取得したIPv6アドレスを介してトラフィックを受信するために失敗した場合、Teredoクライアントは、攻撃を検出します。攻撃は、認証のカプセル化を使用することによって緩和することができます。
A Teredo client manages a cache of recently used peers, which makes it stateful. It is possible to mount an attack against the client by provoking it to respond to packets that appear to come from a large number of Teredo peers, thus trashing the cache and effectively denying the use of direct communication between peers. The effect will last only as long as the attack is sustained.
Teredoクライアントは、それはステートフルになり、最近使用ピアのキャッシュを管理します。したがって、のTeredo多数のピアから来るように見えるパケットに応答して、それを誘発キャッシュを中傷し、効果的にピア間の直接通信の利用を拒否することにより、クライアントに対して攻撃を仕掛けることが可能です。効果は限り攻撃が維持されるよう続きます。
There is a possible denial of service attack against the local peer discovery procedure, if attackers can manage to send spoofed local discovery bubbles to a Teredo client. The checks described in Section 5.2.8 mitigate this attack. Clients who are more interested in security than in performance could decide to disable the local discovery procedure; however, if local discovery is disabled, traffic between local nodes will end up being relayed through a server external to the local network, which has questionable security implications.
攻撃者は、Teredoクライアントに偽装されたローカル発見泡を送信するために管理することができた場合、ローカルピア発見手順に対するサービスの攻撃の可能性否定は、あります。 5.2.8項で説明したチェックは、この攻撃を軽減します。パフォーマンスよりもセキュリティがより興味を持っているクライアントは、ローカル発見手順を無効にすることを決定することもできます。地元の発見が無効になっている場合は、ローカルノード間のトラフィックは、疑わしいセキュリティの意味を持つローカルネットワーク、外部のサーバーを介して中継されることになります。
It is possible to mount a brute force denial of service attack against the Teredo servers by sending them a very large number of packets. This attack will have to be brute force, since the servers are stateless, and can be designed to process all the packets that are sent on their access line.
彼らに、パケットの非常に大きな数を送信することにより、Teredoサーバーに対するサービス攻撃のブルートフォース拒否を搭載することが可能です。この攻撃は、サーバはステートレスなので、ブルートフォースなければならないだろう、と彼らのアクセス回線上で送信されるすべてのパケットを処理するように設計することができます。
The brute force attack against the Teredo servers is mitigated if clients are ready to "failover" to another server. Bringing down the servers will, however, force the clients that change servers to renumber their Teredo address.
クライアントは別のサーバーに「フェイルオーバー」への準備ができている場合はTeredoサーバーに対するブルートフォース攻撃が緩和されます。サーバを停止すると、しかし、彼らのTeredoアドレスの番号を変更するサーバーを変更するクライアントを強制します。
It is also possible to mount a brute force attack against a Teredo relay. This attack is mitigated if the relay under attack stops announcing the reachability of the Teredo service prefix to the IPv6 network: the traffic will be picked up by the next relay.
Teredoリレーに対するブルートフォース攻撃を実装することも可能です。トラフィックは、次の中継によってピックアップされます。攻撃の下のリレーはIPv6ネットワークへのTeredoサービスプレフィックスの到達可能性を発表して停止した場合、この攻撃は軽減されます。
An attack similar to that described in Section 7.3.2 can be mounted against a relay. An IPv6 host can send IPv6 packets to a large number of Teredo destinations, forcing the relay to establish state for each of these destinations. Teredo relays can obtain some protection by limiting the range of IPv6 clients that they serve, and by limiting the amount of state used for "new" peers.
7.3.2で説明したのと同様の攻撃がリレーに対して取り付けることができます。 IPv6ホストは、これらの宛先ごとに状態を確立するために、リレーを強制的に、Teredoの先の数が多いためにIPv6パケットを送信することができます。 Teredoリレーは、と「新」のピアのために使用される状態の量を制限することによって、彼らが奉仕のIPv6クライアントの範囲を制限することによって、いくつかの保護を得ることができます。
There is a widely expressed concern that transition mechanisms such as Teredo can be used to mount denial of service attacks, by injecting traffic at locations where it is not expected. These attacks fall in three categories: using the Teredo servers as a reflector in a denial of service attack, using the Teredo server to carry a denial of service attack against IPv6 nodes, and using the Teredo relays to carry a denial of service attack against IPv4 nodes. The analysis of these attacks follows. A common mitigating factor in all cases is the "regularity" of the Teredo traffic, which contains highly specific patterns such as the Teredo UDP port, or the Teredo IPv6 prefix. In case of attacks, these patterns can be used to quickly install filters and remove the offending traffic.
例えばTeredoのような遷移機構は、それが期待されていない場所でトラフィックを注入することにより、サービス拒否攻撃を実装するために使用することができることは広く発現が懸念されます。これらの攻撃は、次の3つのカテゴリに分類：IPv4のに対してサービス拒否攻撃を運ぶためにIPv6ノードに対するサービス拒否攻撃を運ぶためにTeredoサーバーを使用して、とのTeredoリレーを使用して、サービス拒否攻撃で反射板としてTeredoサーバーを使用してノード。これらの攻撃の分析は、以下の通りです。全ての場合において、共通緩和因子は、TeredoのUDPポート、またはTeredoのIPv6プレフィックスとして非常に特定のパターンが含まれているTeredoトラフィックの「規則」です。攻撃の場合には、これらのパターンはすぐにフィルタをインストールし、問題のあるトラフィックを除去するために使用することができます。
We should also note that none of the listed possibilities offer any noticeable amplification.
また、記載されている可能性のいずれも顕著な増幅を提供しないことに注意してください。
An attacker can use the Teredo servers as reflectors in a denial of service attack aimed at an IPv4 target. The attacker can do this in one of two ways. The first way is to construct a Router Solicitation
攻撃者は、IPv4ターゲットに向けたサービス拒否攻撃で反射器としてTeredoサーバーを使用することができます。攻撃者は、次のいずれかの方法でこれを行うことができます。最初の方法は、ルータ要請を構築することです
message and post it to a Teredo server, using as IPv4 source address the spoofed address of the target; the Teredo server will then send a Router advertisement message to the target. The second way is to construct a Teredo IPv6 address using the Teredo prefix, the address of a selected server, the IPv4 of the target, and an arbitrary UDP port, and to then send packets bound to that address to the selected Teredo server.
IPv4ソースアドレスとしてターゲットのスプーフィングされたアドレスを使用して、TeredoサーバーにそれをメッセージおよびPOST。 Teredoサーバーは、ターゲットへのルータ広告メッセージを送信します。第二の方法は、Teredoのプレフィックス、選択されたサーバのアドレス、ターゲットのIPv4の、任意のUDPポートを使用してTeredoのIPv6アドレスを構成するために、次に選択されたTeredoサーバーにそのアドレスにバインドされたパケットを送信することです。
Reflector attacks are discussed in [REFLECT], which outlines various mitigating techniques against such attacks. One of these mitigations is to observe that "the traffic generated by the reflectors [has] sufficient regularity and semantics that it can be filtered out near the victim without the filtering itself constituting a denial-of-service to the victim ('collateral damage')". The traffic reflected by the Teredo servers meets this condition: it is clearly recognizable, since it originates from the Teredo UDP port; it can be filtered out safely if the target itself is not a Teredo user. In addition, the packets relayed by servers will carry an Origin indication encapsulation, which will help determine the source of the attack.
反射攻撃は、攻撃に対してさまざまな緩和技術を概説れ、[反映]に記載されています。これらの緩和策の一つは、フィルタ自体が被害者へのサービス拒否を構成することなく、被害者の近くに除外することができる十分な規則性と意味論（ 『付随損傷』反射によって生成されるトラフィックは[持っている]」ことを観察することです）」。 Teredoサーバーで反射されたトラフィックは、この条件を満たしている：それはTeredoのUDPポートから発信するので、それは、明確に認識されます。ターゲット自体はTeredoのユーザーではない場合には、安全に除外することができます。また、サーバによって中継されたパケットは、攻撃のソースを判断するのに役立ちます原産地表示のカプセル化を、運ぶでしょう。
An attacker may use the Teredo servers to launch a denial of service attack against an arbitrary IPv6 destination. The attacker will build an IPv6 packet bound for the target and will send that packet to the IPv4 address and UDP port of a Teredo server, to be relayed from there to the target over IPv6.
攻撃者が任意のIPv6宛先に対するサービス拒否攻撃を起動するためにTeredoサーバーを使用することができます。攻撃者がターゲットにバインドされたIPv6パケットを構築しますとIPv6を超えるターゲットにそこから中継する、TeredoサーバーのIPv4アドレスとUDPポートにそのパケットを送信します。
The address checks specified in Section 5.3.1 provide some protection against this attack, as they ensure that the IPv6 source address will be consistent with the IPv4 source address and UDP source port used by the attacker: if the attacker cannot spoof the IPv4 source address, the target will be able to determine the origin of the attack.
攻撃者は、IPv4送信元アドレスを偽装することができない場合：彼らはIPv6ソースアドレスがIPv4送信元アドレスと、攻撃者によって使用されるUDPの送信元ポートと一致することを保証として、5.3.1項で指定されたアドレスのチェックは、この攻撃に対してある程度の保護を提供します、ターゲットは攻撃の発信元を決定することができるであろう。
The address checks ensure that the IPv6 source address of packets forwarded by servers will start with the IPv6 Teredo prefix. This is a mitigating factor, as sites under attack could use this to filter out all packets sourced from that prefix during an attack. This will result in a partial loss of service, as the target will not be able to communicate with legitimate Teredo hosts that use the same prefix.
アドレスのチェックはサーバによって転送されるパケットのIPv6送信元アドレスがIPv6のTeredoプレフィックスで開始されることを確認してください。攻撃の下のサイトが攻撃中にその接頭語から供給されるすべてのパケットをフィルタリングするためにこれを使用することができ、これは、問題を緩和する要因です。ターゲットは、同じ接頭辞を使用する正規のTeredoホストと通信することができなくなり、これは、サービスの部分的な損失をもたらすであろう。
However, the communication with other IPv6 hosts will remain unaffected, and the communication with Teredo hosts will be able to resume when the attack has ceased.
しかし、他のIPv6ホストとの通信には影響を受けません、とのTeredoホストとの通信は、攻撃が終わった時に再開することができるようになります。
An attacker with IPv6 connectivity may use the Teredo relays to launch a denial of service attack against an arbitrary IPv4 destination. The attacker will compose a Teredo IPv6 address using the Teredo prefix, a "cone" flag set to 1, the IPv4 address of the target, and an arbitrary UDP port.
IPv6接続を持つ攻撃者が任意のIPv4宛先に対するサービス拒否攻撃を起動するためのTeredoリレーを使用することができます。攻撃者は、Teredoのプレフィックス、1に設定された「コーン」フラグ、ターゲットのIPv4アドレス、および任意のUDPポートを使用してTeredoのIPv6アドレスを構成します。
In the simplest variation of this attack, the attacker sends IPv6 packets to the Teredo destination using regular IPv6 routing. The packets are picked by the nearest relay, which will forward them to the IPv4 address of the target. In a more elaborate variant, the attacker tricks a Teredo into sending packets to the target, either by sending a first packet with a spoofed IPv6 address and letting the Teredo host reply or by publishing a spoofed IPv6 address in a name service.
この攻撃の最も単純なバリエーションでは、攻撃者が正規のIPv6ルーティングを使用してのTeredo先にIPv6パケットを送信します。パケットは、ターゲットのIPv4アドレスに転送されます最寄りのリレーによって選択されます。より精巧な変種、攻撃者のトリックのTeredoで偽装されたIPv6アドレスを持つ最初のパケットを送信するとのTeredoホスト返事をさせることにより、またはネームサービスで偽装されたIPv6アドレスを公開することにより、いずれか、ターゲットにパケットを送信することに。
There are three types of IPv4 addresses that an attacker may embed in the spoofed Teredo address. It may embed a multicast or broadcast address, an local unicast address, or a global unicast address.
IPv4の3つのタイプがありますが、攻撃者が偽装されたTeredoアドレスに埋め込むことが対処しています。これは、マルチキャストまたはブロードキャストアドレス、ローカルユニキャストアドレス、またはグローバルユニキャストアドレスを埋め込むことがあります。
With multicast or broadcast addresses, the attacker can use the multiplying effect of multicast routing. By sending a single packet, it can affect a large number of hosts, in a way reminiscent of the "smurf" attack.
マルチキャストまたはブロードキャストアドレスを使用すると、攻撃者は、マルチキャストルーティングの乗算効果を使用することができます。単一のパケットを送信することにより、それは「スマーフ」攻撃を連想させる方法で、多数のホストに影響を与えることができます。
By using local addresses, the attacker can reach hosts that are not normally reachable from the Internet, for example, hosts connected to the a Teredo relay by a private subnet. This creates an exposure for, at a minimum, a denial of service attack against these otherwise protected hosts. This is similar to attack variants using source routing to breach a perimeter.
ローカルアドレスを使用することにより、攻撃者は、例えば、プライベートサブネットでTeredoリレーに接続されたホストをインターネットから正常に到達できないホストに到達することができます。これは、最低でも、これらのそれ以外の場合は保護ホストに対してサービス拒否攻撃をするための露光を作成します。これは、周囲を侵害するソースルーティングを使用してバリアントを攻撃に似ています。
The address checks specified in Section 5.2.4, 5.3.1, and 5.4.1 verify that packets are relayed only to a global IPv4 address. They are designed to eliminate the possibility of using broadcast, multicast or local addresses in denial of service or other attacks. In what follows, we will only consider attacks targeting globally reachable unicast addresses.
アドレスセクション5.2.4、5.3.1で指定されたチェック、および5.4.1は、パケットが唯一のグローバルIPv4アドレスに中継されていることを確認してください。これらは、サービスまたは他の妨害攻撃にブロードキャスト、マルチキャストまたはローカルアドレスを使用する可能性を排除するために設計されています。以下では、我々はグローバルにのみ到達可能なユニキャストアドレスを標的に攻撃を検討します。
The attacks can be targeted at arbitrary UDP ports, such as, for example, the DNS port of a server. The UDP payload must be a well-formed IPv6 packet, and is thus unlikely to be accepted by any well-written UDP service; in most case, the only effect of the attack will be to overload the target with random traffic.
攻撃は、例えば、のような任意のUDPポートにてサーバーのDNSポートを標的とすることができます。 UDPペイロードは、十分に形成されたIPv6パケットであり、したがって、任意のよく書かれたUDPサービスによって受け入れられにくいしなければなりません。ほとんどの場合、攻撃の唯一の効果は、ランダムなトラフィックをターゲットをオーバーロードすることになります。
A special case occurs if the attack is directed to an echo service. The service will echo the packets. Since the echo service sees the request coming from the IPv4 address of the relay, the echo replies will be sent back to the same relay. According to the rules specified in Section 5.4, these packets will be discarded by the Teredo relay. This is not a very efficient attack against the Teredo relays -- establishing a legitimate session with an actual Teredo host would create more traffic.
攻撃は、エコーサービスを対象とする場合は特殊なケースが発生します。このサービスは、パケットをエコーします。エコーサービスは、リレーのIPv4アドレスからの要求を見ているので、エコー応答が同じリレーに送り返されます。 5.4節で指定されたルールによると、これらのパケットはTeredoリレーによって破棄されます。より多くのトラフィックを作成し、実際のTeredoホストに正当なセッションを確立する - これで、Teredoリレーに対して非常に効率的な攻撃ではありません。
The IPv6 packets sent to the target contain the IPv6 address used by the attacker. If ingress filtering is used in the IPv6 network, this
ターゲットに送信されたIPv6パケットは、攻撃者によって使用されるIPv6アドレスが含まれています。イングレスフィルタリングは、IPv6ネットワークで使用されている場合、この
address will be hard to spoof. If ingress filtering is not used, the attacker can be traced if the IPv6 routers use a mechanism similar to ICMP Traceback. The ICMP messages will normally be collected by the same relays that forward the traffic from the attacker; the relays can use these messages to identify the source of an ongoing attack. The details of this solution will have to be developed in further research.
アドレスは詐称するのは難しいだろう。イングレスフィルタリングを使用しない場合はIPv6ルータがICMPトレースバックと同様のメカニズムを使用する場合、攻撃者が追跡することができます。 ICMPメッセージは、通常、攻撃者からのトラフィックを転送し、同じリレーによって収集されます。リレーは、進行中の攻撃の発生源を特定するために、これらのメッセージを使用することができます。このソリューションの詳細については、さらなる研究で開発する必要があります。
The IAB has studied the problem of "Unilateral Self Address Fixing" (UNSAF), which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism [RFC3424]. Teredo is an example of a protocol that performs this type of function. The IAB has mandated that any protocols developed for this purpose document a specific set of considerations. This section meets those requirements.
IABは、クライアントが協調プロトコル反射メカニズム[RFC3424]を介してNATの反対側に別の領域にそのアドレスを決定しようとすることによって一般的な方法は「一方的な自己アドレス固定」（UNSAF）の問題を研究しています。 Teredoは関数のこのタイプを行うプロトコルの一例です。 IABは、任意のプロトコルは、この目的の文書の検討事項の特定のセットを開発することを義務付けています。ここでは、これらの要件を満たしています。
From [RFC3424], any UNSAF proposal must provide a precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short-term fix should not be generalized to solve other problems; this is why "short term fixes usually aren't".
[RFC3424]から、任意のUNSAF提案はUNSAF提案で解決されるべき特定の、限定されたスコープの問題の正確な定義を提供しなければなりません。短期的な修正は、他の問題を解決するために一般化すべきではありません。 「短期の修正は通常はない」理由です。
The specific problem being solved by Teredo is the provision of IPv6 connectivity for hosts that cannot obtain IPv6 connectivity natively and cannot make use of 6to4 because of the presence of a NAT between them and the 6to4 relays.
Teredoによって解決されている特定の問題は、ネイティブIPv6接続を得ることができず、なぜならそれらと6to4リレーの間にNATが存在するの6to4を利用することができないホストのためのIPv6接続を提供することです。
From [RFC3424], any UNSAF proposal must provide the description of an exit strategy/transition plan. The better short term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed.
[RFC3424]から、任意のUNSAF提案は、出口戦略/移行計画の説明を提供しなければなりません。より良い短期間フィックスは、適切な技術が展開されると自然に減って使用が表示されますものです。
Teredo comes with its own built-in exit strategy: as soon as a client obtains IPv6 connectivity by other means, either 6to4 or native IPv6, it can cease using the Teredo service. In particular, we expect that the next generation of home routers will provide an IPv6 service in complement to the current IPv4 NAT service, e.g., by relaying connectivity obtained from the ISP, or by using a configured or automatic tunnel service.
Teredoは、独自の組み込みの出口戦略が付属していますとすぐにクライアントが他の手段でIPv6接続を取得して、6to4のまたはネイティブIPv6が、それはTeredoサービスを使用して中止することができます。特に、我々は、ホームルータの次の世代は、例えば、ISPから取得した接続を中継することによって、または構成または自動トンネルサービスを使用して、現在のIPv4 NATサービスを補完するものでIPv6サービスを提供することを期待します。
As long as Teredo is used, there will be a need to support Teredo relays so that the remaining Teredo hosts can communicate with native IPv6 hosts. As Teredo usage declines, the traffic load on the relays will decline. Over time, managers will observe a reduced traffic load on their relays and will turn them off, effectively increasing the pressure on the remaining Teredo hosts to upgrade to another form of connectivity.
限りのTeredoが使用されるように、残りのTeredoホストはネイティブIPv6ホストと通信できるようにのTeredoリレーをサポートする必要があるだろう。 Teredoの使用状況の下落として、リレーのトラフィック負荷が低下します。時間が経つにつれて、管理者はそのリレーの減少トラフィック負荷を観察し、効果的な接続の別の形式にアップグレードするには、残りのTeredoホストへの圧力を高め、それらをオフにします。
The exit strategy is facilitated by the nature of Teredo, which provides an IP-level solution. IPv6-aware applications do not have to be updated to use or not use Teredo. The absence of impact on the applications makes it easier to migrate out of Teredo: network connectivity suffices.
出口戦略は、IPレベルのソリューションを提供するのTeredoの性質によって促進されます。 IPv6に対応したアプリケーションは、使用するかのTeredoを使用しないように更新する必要はありません。アプリケーションへの影響がないことは、簡単のTeredoの外へ移動することができます：ネットワーク接続があればよいです。
There would appear to be reasons why a Teredo implementation might decide to continue usage of the Teredo service even if it already has obtained connectivity by some other means, for example:
Teredoの実装が、それはすでに例えば、いくつかの他の手段で接続を取得している場合でも、Teredoサービスの利用を継続することを決定するかもしれない理由があるように思われます。
1. When a client is dual homed, and it wishes to improve the service when communicating with other Teredo hosts that are "nearby" on the IPv4 network. If the client only used its native IPv6 service, the Teredo hosts would be reached only through the relay. By maintaining Teredo, the Teredo hosts can be reached by direct transmission over IPv4.
1.クライアントがホームデュアルであり、それは、IPv4ネットワーク上で「近く」ある他のTeredoホストと通信するときにサービスを改善したい場合。クライアントが唯一のネイティブのIPv6サービスを使用した場合、のTeredoホストにのみリレーを介して到達することでしょう。 Teredoを維持することによって、のTeredoホストは、IPv4を直接送信することによって到達することができます。
2. If, for some reason, the Teredo link is providing the client with better service than the native IPv6 link, in terms of bandwidth, packet loss, etc.
2. IFが、何らかの理由で、Teredoのリンクは、帯域幅、パケット損失などの面で、ネイティブのIPv6リンクより良いサービスをクライアントに提供しています
The design of Teredo mitigates the dual-homing reason. A host that wishes to communicate with Teredo peers can implement a "host-based relay", which is effectively an unnumbered Teredo interface. As such, the dual-homed host will obtain Teredo connectivity with those hosts that must use Teredo, but will not inadvertently encourage other dual-homed hosts to keep using the Teredo service.
Teredoのデザインは、デュアルホーミング理由を軽減します。 Teredoのピアと通信することを望むホストを効果的に無数のTeredoインターフェースである「ホストベースのリレー」を、実現することができます。そのため、デュアルホームホストにより、Teredoを使用する必要があり、それらのホストとのTeredo接続を取得しますが、不注意Teredoサービスを使用して維持するために、他のデュアルホームホストを奨励しません。
The bubbles and the UDP encapsulation used by Teredo introduce a significant overhead. It would take exceptional circumstances for native technologies to provide a lesser service than Teredo. These exceptional circumstances, or other unforeseen reasons, may induce hosts to keep using the Teredo service despite the availability of native IPv6 connectivity. However, these circumstances are likely to be rare and transient. Moreover, if the primary reason to use Teredo fades away, one can expect that Teredo relays will be progressively turned off and that the quality of the Teredo service will progressively degrade, reducing the motivation to use the Teredo service.
泡とTeredoが使用するUDPカプセル化は大きなオーバーヘッドをご紹介します。ネイティブ技術はTeredoのより低いサービスを提供することは例外的な状況を取るだろう。これらの例外的な状況、またはその他の予期せぬ理由は、ネイティブIPv6接続の利用可能性にもかかわらず、Teredoサービスを使用して維持するためにホストを誘導することができます。しかし、このような状況は稀で、一過性である可能性が高いです。 Teredoを使用する主な理由が消えた場合また、一つで、Teredoリレーが徐々にオフされることとTeredoサービスの品質が徐々にTeredoサービスを使用するためのモチベーションを下げる、劣化することを期待することができます。
From [RFC3424], any UNSAF proposal must provide a discussion of specific issues that may render systems more "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition.
[RFC3424]から、任意のUNSAF提案は、システムがより「脆い」レンダリングする可能性のある特定の問題の議論を提供する必要があります。たとえば、複数のネットワーク層でデータを使用することを含むアプローチは、デバッグの課題を高め、移行することが難しく、より多くの依存関係を作成します。
Teredo introduces brittleness into the system in several ways: the discovery process assumes a certain classification of devices based on their treatment of UDP; the mappings need to be continuously refreshed; and addressing structure may cause some hosts located behind a common NAT to be unreachable from each other.
Teredoは、いくつかの方法でシステムにもろさを紹介：検出プロセスは、UDPの彼らの治療に基づいてデバイスの特定の分類を前提とし、マッピングは、連続的にリフレッシュする必要があります。および構造に対処することは一般的なNATの背後にあるいくつかのホストが相互に到達不能であることを引き起こす可能性があります。
There are many similarities between these points and those introduced by Simple Traversal of the UDP Protocol through NAT (STUN) [RFC3489]; however, Teredo is probably somewhat less brittle than STUN. The reason is that all Teredo packets are sent from the local IPv4 Teredo service port, including discovery, bubbles, and actual encapsulated packets. This is different from STUN, where NAT type detection and binding allocation use different local ports (ephemeral, in both cases).
これらの点やNAT（STUN）[RFC3489]を通じてUDPプロトコルの簡単なトラバーサルによって導入されたものとの間に多くの類似点があります。ただし、TeredoはSTUNよりも、おそらくやや少ない脆いです。その理由は、すべてのTeredoパケットを発見、気泡、及び実際のカプセル化されたパケットを含む、ローカルのIPv4 Teredoサービスポートから送信されることです。これは、NATタイプの検出及び結合割り当ては（どちらの場合も短命）異なるローカルポートを使用するSTUN、異なっています。
Teredo assumes a certain classification of devices based on their treatment of UDP (e.g., cone, protected cone and symmetric). There could be devices that would not fit into one of these molds, and hence would be improperly classified by Teredo.
TeredoはUDPのそれらの治療（例えば、コーン、保護コーンと対称）に基づいて、デバイスの特定の分類を想定しています。これらの金型のいずれかに収まらない、したがって、不適切のTeredoによって分類されるデバイスがあるかもしれません。
The bindings allocated from the NAT need to be continuously refreshed. Since the timeouts for these bindings are very implementation specific, the refresh interval cannot easily be determined. When the binding is not being actively used to receive traffic, but to wait for an incoming message, the binding refresh will needlessly consume network bandwidth.
NATから割り当てられたバインディングは、継続的にリフレッシュする必要があります。これらのバインディングのためのタイムアウトは非常に実装が特定されているので、リフレッシュ間隔を容易に判断することはできません。バインディングがアクティブにトラフィックを受信することが、着信メッセージを待つために使用されていない場合は、バインディングリフレッシュが不必要なネットワーク帯域幅を消費します。
The use of the Teredo server as an additional network element introduces another point of potential security attack. These attacks are largely prevented by the security measures provided by Teredo, but not entirely.
追加のネットワーク要素としてTeredoサーバーの使用は、潜在的なセキュリティ攻撃の別のポイントを紹介します。これらの攻撃は、主にではなく、完全に、Teredoの提供するセキュリティ対策によって阻止されます。
The use of the Teredo server as an additional network element introduces another point of failure. If the client cannot locate a Teredo server, or if the server should be unavailable due to failure, the Teredo client will not be able to obtain IPv6 connectivity.
追加のネットワーク要素としてTeredoサーバーの使用は、故障の別のポイントを紹介します。クライアントはTeredoサーバーが見つからない場合、またはサーバーが障害により使用できなくする必要がある場合は、TeredoクライアントはIPv6接続を取得することができません。
The communication with non-Teredo hosts relies on the availability of Teredo relays. The Teredo design assumes that there are multiple Teredo relays; the Teredo service will discover the relay closest to the non-Teredo peer. If that relay becomes unavailable, or is misbehaving, communication between the Teredo hosts and the peers close to that relay will fail. This reliability issue is somewhat mitigated by the possibility to deploy many relays, arbitrarily close from the native IPv6 hosts that require connectivity with Teredo peers.
非のTeredoホストとの通信に、Teredoリレーの可用性に依存しています。 Teredoの設計では、複数のTeredoリレーがあることを想定しています。 Teredoサービスは非のTeredoピアに最も近いリレーを発見するでしょう。そのリレーが使用できなくなった、または誤動作した場合は、そのリレーに近いのTeredoホストとピアとの間の通信は失敗します。この信頼性の問題は多少のTeredoピアとの接続を必要とネイティブのIPv6ホストから任意に近い多くのリレーを、展開する可能性によって軽減されます。
Teredo imposes some restrictions on the network topologies for proper operation. In particular, if the same NAT is on the path between two clients and the Teredo server, these clients will only be able to interoperate if they are connected to the same link, or if the common NAT is capable of "hairpinning", i.e., "looping" packets sent by one client to another.
Teredoは、適切な動作のためのネットワークトポロジ上のいくつかの制限を課しています。同じNATは、2つのクライアントとTeredoサーバー間のパス上にある場合は特に、これらのクライアントは、彼らだけが同じリンクに接続している場合や、相互運用することができるようになります一般的なNATは、「ヘアピン」が可能である場合、すなわち、別のクライアントから送信された「ループ」パケット。
There are also additional points of brittleness that are worth mentioning:
言及する価値がある脆性の見所もあります。
- Teredo service will not work through NATs of the symmetric variety.
- Teredoサービスは、対称様々なNATを介して動作しません。
- Teredo service depends on the Teredo server running on a network that is a common ancestor to all Teredo clients; typically, this is the public Internet. If the Teredo server is itself behind a NAT, Teredo service will not work to certain peers.
- Teredoサービスは、すべてのTeredoクライアントに共通の祖先であるネットワーク上で実行されているTeredoサーバーに依存します。一般的に、これは公共のインターネットです。 TeredoサーバーがNATの背後自身である場合は、Teredoサービスは、特定のピアに動作しません。
- Teredo introduces jitter into the IPv6 service it provides, due to the queuing of packets while bubble exchanges take place. This jitter can negatively impact applications, particularly latency sensitive ones, such as Voice over IP (VoIP).
- Teredoはバブル交換が行われている間、それが原因のパケットのキューイングに、提供IPv6サービスにジッタを紹介しています。このジッタは負のアプリケーションは、そのようなボイスオーバーIP（VoIP）のように、特に遅延の影響を受けやすいものを、影響を与えることができます。
From [RFC3424], any UNSAF proposal must identify requirements for longer-term, sound technical solutions -- contribute to the process of finding the right longer-term solution.
[RFC3424]から、任意のUNSAF提案は、長期の要件を特定する技術的な解決策を鳴らす必要があります - 右より長期的な解決策を見つけるプロセスに貢献します。
Our experience with Teredo has led to the following requirements for a long-term solution to the NAT problem: the devices that implement the IPv4 NAT services should in the future also become IPv6 routers.
Teredoのでの経験は、NAT問題への長期的な解決策のために、次の要件につながっている：IPv4のNATサービスを実装するデバイスは、将来的にも、IPv6ルータになるはずです。
This memo documents a request to IANA to allocate a 32-bit Teredo IPv6 service prefix, as specified in Section 2.6, and a Teredo IPv4 multicast address, as specified in Section 2.17.
セクション2.17で指定されるように、2.6節、およびTeredoのIPv4マルチキャストアドレスで指定されるように、このメモは、32ビットのTeredo IPv6サービスプレフィックスを割り当てるためのIANAに要求を文書化。
Many of the ideas in this memo are the result of discussions between the author and Microsoft colleagues, notably Brian Zill, John Miller, Mohit Talwar, Joseph Davies, and Rick Rashid. Several encapsulation details are inspired from earlier work by Keith Moore. The example in Section 5.1 and a number of security precautions were suggested by Pekka Savola. The local discovery procedure was suggested by Richard Draves and Dave Thaler. The document was reviewed by members of the NGTRANS and V6OPS working groups, including Brian Carpenter, Cyndi Jung, Keith Moore, Thomas Narten, Anssi Porttikivi, Pekka Savola, Eng Soo Guan, and Eiffel Wu. Eric Klein, Karen Nielsen, Francis Dupont, Markku Ala-Vannesluoma, Henrik Levkowetz, and Jonathan Rosenberg provided detailed reviews during the IETF last call.
このメモでアイディアの多くは、著者とマイクロソフトの同僚、特にブライアンZill、ジョン・ミラー、Mohit Talwar、ジョセフ・デイヴィス、そしてリック・ラシッドとの協議の結果です。いくつかのカプセル化の詳細は、キース・ムーアによる初期の作品からインスピレーションを得ています。 5.1節と安全対策の数の例は、ペッカSavolaによって提案されました。ローカル発見手順は、リチャードDravesとDaveターラーによって示唆されました。文書はNGTRANSのメンバーとブライアン・カーペンター、シンディ・ジョン、キースムーア、トーマスNarten氏、Anssi Porttikivi、ペッカSavola、工スヨン関、およびエッフェル呉含むV6OPSワーキンググループで検討しました。エリック・クライン、カレン・ニールセン、フランシスデュポン、マルックアラ - Vannesluoma、ヘンリックLevkowetz、とジョナサン・ローゼンバーグは、IETFの最後の通話中に詳細なレビューを提供します。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
、RFC 3424、2002年11月、 "ネットワークアドレス変換アクロス一方的な自己アドレス固定するためのIABの考慮事項（UNSAF）" [RFC3424] Daigle氏、L.とIAB、。
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[RFC3566]フランケル、S.およびH.ハーバート、 "AES-XCBC-MAC-96アルゴリズムとIPsecでの使用"、RFC 3566、2003年9月。
[FIPS-180] "Secure Hash Standard", Computer Systems Laboratory, National Institute of Standards and Technology, U.S. Department Of Commerce, May 1993.
[FIPS-180]、コンピュータシステム研究所、国立標準技術研究所、米国商務省が、1993年5月「ハッシュ標準セキュア」。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]ハイン、T.、 "NATの建築的意味"、RFC 2993、2000年11月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330] IANA、 "特殊用途IPv4アドレス"、RFC 3330、2002年9月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy. "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3489]ローゼンバーグ、J.、ワインバーガー、J.、のHuitema、C.、およびR.マーイ。 "STUN - ネットワークを介して、ユーザーデータグラムプロトコル（UDP）の簡単なトラバーサル翻訳者（NATのを）アドレス"、RFC 3489、2003年3月。
[RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks", RFC 3904, September 2004.
[RFC3904]のHuitema、C.、Austeinと、R.、Satapati、S.、およびR.のファンデルポール、 "非管理ネットワークのIPv6移行メカニズムの評価"、RFC 3904、2004年9月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A.、およびV.ボルペ、 "IKEにおけるNATトラバーサルのネゴシエーション"、RFC 3947、2005年1月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[REFLECT] V. Paxson, "An analysis of using reflectors for distributed denial of service attacks", Computer Communication Review, ACM SIGCOMM, Volume 31, Number 3, July 2001, pp 38-47.
V.パクソン、「サービス攻撃の分散拒否のための反射鏡を使用しての分析」、コンピュータコミュニケーションレビュー、ACM SIGCOMM、ボリューム31、ナンバー3、2001年7月、頁38-47を[REFLECT]。
Author's Address
著者のアドレス
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
クリスチャンのHuitemaマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052-6399
EMail: huitema@microsoft.com
メールアドレス：huitema@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。