[要約] RFC 4380は、NATを介したIPv6のUDPトンネリングに関する規格です。目的は、IPv6の普及を促進し、NAT環境下でのIPv6接続を可能にすることです。
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)
Teredo：ネットワークアドレス翻訳（NAT）を介してUDPを介してIPv6をトンネル化する
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).
Copyright（c）The Internet Society（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".
ここでは、1つ以上のIPv4ネットワークアドレス翻訳（NAT）の背後にあるノードを有効にして、UDPを介したトンネリングパケットによってIPv6接続を取得できるサービスを提案します。これを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スキームで使用できません。6to4は、NATおよび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.
問題を解決する可能性のある方法は、一連の「トンネルブローカー」に依存することです。ただし、このようなブローカーに基づいたソリューションには制限があります。トラフィックはソースからブローカー、そして目的地までのドッグレッグルートに従うため、サービスの質が制限される場合があります。ブローカーは、すべてのパケットを中継するのに十分な送信能力を提供する必要があるため、高コストが及ばれます。これらの2つの理由により、「自動トンネリング」を可能にするソリューション、つまりパケットが宛先への直接パスをたどることが望ましい場合があります。
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が実装するさまざまな「目的ごとの保護」をバイパスする方法を見つけることができると仮定します。このメモでは、NATの背後にあるIPv6候補者が「Teredoサーバー」を使用して「グローバルアドレス」を学習し、接続性を取得する方法、「Teredoリレー」を介してネイティブIPv6ホストとパケットを交換する方法、およびクライアント、サーバーを介してどのように交換するかを説明します。また、テレドネットワークでリレーを整理できます。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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インターネットにアクセスし、テレドクライアントに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.
値が2001：0000：/32であるIPv6アドレス指定プレフィックス。
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ノード識別子を組み合わせて取得したTeredo IPv6アドレス。
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ポートは、テレドトラフィックを運ぶためには使用されません。
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サブネットで他のTeredoクライアントを発見するために使用されるIPv4マルチキャストアドレス。このアドレスの値は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.
提案されたソリューションは、IPv6パケットをUDPパケットのペイロードとして輸送します。これは、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の動作に関する仮説と観察のセット、「Last ResortのIPv6プロバイダー」を提供したいという願望、および運用要件のリストに基づいています。これにより、テレドサービスがサーバーとリレーのセットによって有効になる操作モデルになります。
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ベースのアプリケーションを使用できるようにするために、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.
マッピングのタイプは[RFC3489]で分析され、「コーンナット」、「制限付きコーンナット」、「ポート制限コーンナット」、「対称NAT」を区別します。Teredoソリューションは、コーンナット、制限付きコーンナット、または港湾制限コーンナットの後ろにあるクライアントの接続性を保証します。
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を何らかの形でプログラムし、たとえばNATのDMZ関数を使用して各クライアントに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」として動作します。
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の設計は、同じNATの後ろにある複数のホストに異なるTeredoサービスポートを使用するように依頼することにより、「対称」動作に遭遇するリスクを最小限に抑えます。
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 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サービスを「最後のリゾート」オプションとしてのみ使用する必要があります。ローカルで利用可能な場合は、ローカルで利用可能な場合は、ローカルで提供されている場合は、直接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 StatelessアドレスAutoconfiguration [RFC2462]や隣接発見[RFC2461]などのメカニズムを使用して、IPv6サービスが自動的に構成されます。設計目的は、可能な限り自動的に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サービスを提供するという特定の問題の短期的な解決策として意図されています。この問題は、「IPv4 NAT」を「IPv6ルーター」に変換することにより、時間の経過とともに解決されると予想されます。これは、2つの方法のいずれかで実行できます。NATをアップグレードして6to4関数を提供するか、NATがネイティブIPv6サービスに使用するインターネット接続をアップグレードし、NATにIPv6ルーター機能を追加します。どちらの場合でも、前者の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ポートが組み込まれることを意味します。これにより、Teredoアドレスの安定性に暗黙的な制限が作成されます。これは、基礎となるIPv4アドレスとUDPポートが有効なままである限り、有効なままであることができます。
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.
ルーターは、特定のインターフェイスで受信したパケットのソースアドレスが「合法」であることを確認することにより、イングレスフィルタリングを実行できます。つまり、ネットワークインターフェイスでトラフィックが予想されるネットワークプレフィックスに属します。Ingressフィルタリングは、特にサービス拒否攻撃中にトラックをカバーするために、Malfeasant Hackersによる偽造ソースIPアドレスの使用を妨害するため、推奨される練習です。Teredo仕様は、ネットワークにイングレスフィルタリングを無効にすることを強制してはなりません。
The operation of Teredo involves four types of nodes: Teredo clients, Teredo servers, Teredo relays, and "plain" IPv6 nodes.
Teredoの操作には、Teredoクライアント、Teredoサーバー、Teredoリレー、および「プレーン」IPv6ノードの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パケットを受信できる「マッピングアドレスとポート」を埋め込みます。クライアントがコーン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リレーは、Teredoプレフィックスの到達可能性をIPv6インターネットの特定のサブセットに宣伝します。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エコーリクエストを送信することにより、リレー発見手順を実行します。このメッセージは、定期的にフォーマットされたIPv6 ICMPパケットであり、UDPにカプセル化され、クライアントからTeredoサーバーに送信されます。サーバーはIPv6メッセージを脱カプセル化し、意図したIPv6宛先に転送します。エコー要求のペイロードには、大きな乱数が含まれています。エコーの応答は、ピアからクライアントのIPv6アドレスに送信され、標準のIPv6ルーティングメカニズムを介して転送されます。自然にネイティブまたは6to4ピアに最も近いテレドリレーに到達し、テレドメカニズムを使用してこのリレーによって転送されます。Teredoクライアントは、リレーで使用されているIPv4アドレスとUDPポートを発見してECHO応答を送信し、この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サーバーは、実際のデータトラフィックを伴うことはありません。この設計には2つの根拠があります。スケーリングを有効にするためにサーバーの負荷を減らし、Teredoサーバーがクライアントのデータパケットのコピーを保持している場合に発生する可能性のあるプライバシーの問題を回避することです。
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ビットテレドサービスプレフィックス。-Server 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アドレス」の両方が難読化されています。アドレスとポート番号の各ビットは逆になります。これは、16進価値0xffffの排他的または16ビットポート番号、および16進価値0xffffffffの排他的または32ビットアドレスで実行できます。
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」に設定する必要があり、非グロールユニキャスト識別子を示します。 - クライアントがコーンナットの後ろにあると信じている場合は、ビット「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.)
したがって、フラグフィールドには現在指定されている2つの値があります。コーンビットが0に設定されている場合は "0x0000"（すべてnull）、コーンビットが1に設定されている場合は「0x8000」（この仕様のさらにバージョンが割り当てられる場合があります。予約済みビットの新しい値。）
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ノードはLink-Localアドレスを使用します。これらのアドレスには、上記と同じ形式を使用して構築されたリンクローカルプレフィックス（Fe80 ::/64）と64ビット識別子が含まれています。Link-Localアドレスとグローバルアドレスの違いは、グローバルアドレスで使用される識別子にはグローバルスコープUnicast IPv4アドレスを含める必要があり、Link-Localアドレスで使用される識別子にはプライベート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 UDPポートのTeredoリクエストとIPv6パケットを待ちます。適切なアドレスとポートに応答を送信することにより、リクエストを処理します。Teredo IPv6パケットを適切なIPv4アドレスとUDPポート、または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サイトなどの小さなサブセットです。「ローカルリレー」の場合、単一のホストと同じくらい小さいかもしれません。リレーは、Teredo IPv6パケットを適切なIPv4アドレスとUDPポートに転送します。リレーの動作は、セクション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 [RFC791]内でUDPパケット[RFC768]として送信されます。ソースおよび宛先IPアドレスとUDPポートは、このセクションで指定されている値を取得します。パケットは、2つの形式のいずれかで、単純なカプセル化とカプセル化を備えたカプセル化を備えています。
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ポート」の両方が難読化されています。アドレスとポート番号の各ビットは逆になります。これは、16進価値0xffffの排他的または16ビットポート番号、および16進価値0xffffffffの排他的または32ビットアドレスで実行できます。
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（Hexadecimal 0151）であり、元のIPv4アドレスが1.2.3.4（16020303044）の場合、原点指標には値「0000FeefefDFCFB」が含まれます。
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.
認証カプセル化は、クライアント識別子、認証値、NonCE値、および確認バイトを含む可変長要素です。
+--------+--------+--------+--------+
| 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パケットと原点情報の表示カプセル化との区別が可能になります。3番目のオクテットは、クライアント識別子のバイトの長さを示します。4番目のオクテットは、認証値のバイトの長さを示します。認証値の計算は、セクション5.2.2で指定されています。認証値の後には、8オクテットのnonceと確認バイトが続きます。
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 Maximum Transmission Unit（MTU）は、最大の有効なUDPデータグラム（65507バイト）のペイロードと同じ大きさになる可能性があります。ただし、Teredoパケットはインターネット上の予測不可能なパスで移動できるため、IPv4パケットの断片化と再組み立ての効果を最小限に抑えるために、このMTUを小さなサイズに封じ込めることをお勧めします。ホストが想定したデフォルトのリンクMTUと、ルーター広告中にTeredoサーバーが提供するリンクMTUは、通常、1280バイトの最小IPv6 MTUサイズに設定する必要があります[RFC2460]。
Teredo implementations SHOULD NOT set the Don't Fragment (DF) bit of the encapsulating IPv4 header.
Teredoの実装は、IPv4ヘッダーのカプセル化のDont Fragment（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 Serviceポートに関連付けられたTeredo IPv6プレフィックス、-Teredo IPv6アドレスまたはプレフィックスから派生したアドレス、-linkローカルアドレス、 - - Teredoサーバーとの最後の相互作用、-Teredo Refreshインターバル、 - ランダム化された更新間隔、 - 最近のTeredo Peersのリスト。
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接続ステータス、マッピングされたアドレスとポート番号、およびTeredo IPv6プレフィックスが決定されます。その後、コーンNAT決定手順を実行します。これにより、Cone Natステータスが決定され、プレフィックスの値が変更される場合があります。資格が成功した場合、クライアントは、送信および受信手順に従って、Teredoサービスポートを使用してIPv6パケットを送信および受信することができます。これらの手順では、「最近の仲間のリスト」を使用します。各ピアについて、リストには次のものが含まれています。
- 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.
- ピアのIPv6アドレス - マップされたIPv4アドレスとマッピングされたピアのUDPポート - マッピングされたアドレスのステータス、つまり信頼できるかどうか - ピアに送られた最後のNonceの値 - 日付と日付とピアからの最後のレセプションの時間 - ピアへの最後の送信の日付と時刻 - ピアに送信される泡の数。
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 Refreshインターバル」を取ります。このパラメーターは最初は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 Serverの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繰り返しの後に応答が到来していない場合、クライアントはコーンナットの背後にないと結論付けます。コーンビットを0に設定し、手順を繰り返します。他のタイマーの有効期限と再送信の後、まだ応答がない場合、クライアントは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.) 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.)
応答が到来した場合、クライアントは、応答に[RFC2461]で定義されている原点表示と有効なルーター広告が含まれていることを確認します。IPv6宛先アドレスはルーター勧誘で使用されているリンクローカルアドレスに等しく、ルーターがルーターに等しいことを確認します。広告には、広告されたプレフィックス情報オプションが1つだけ含まれています。このプレフィックスは、有効なTeredo IPv6サーバーのプレフィックスである必要があります。最初の32ビットにはグローバルTeredo IPv6サービスプレフィックスが含まれ、次の32ビットにはサーバーのIPv4アドレスが含まれている必要があります。この場合、クライアントはTeredoマッピングアドレスとTeredoマッピングされたポートをOrigin Insicureから学習します。ルーター広告のIPv6ソースアドレスは、TeredoサーバーのLink-Local Serverアドレスです。（有効な広告ではない応答は単に破棄されます。）クライアントが1に設定されたIPv6宛先アドレスにコーンビットを使用してRAを受信した場合、コーンNATの後ろにあり、完全に資格があります。RAがCONEビットを0に設定して受信した場合、クライアントはローカルNATが制限されているか対称かどうかを知りません。クライアントは、セカンダリIPv4サーバーアドレスを選択し、手順を繰り返します。コーンビットは値ゼロまで残ります。クライアントが応答を受け取らない場合、サービスが使用できないことを検出します。クライアントが応答を受信した場合、この2番目の応答でマッピングされたアドレスとマッピングされたポートを最初の受信値に対するマッピングポートを比較します。値が異なる場合、クライアントは対称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から学習されたTeredo IPv6サーバープレフィックスを使用してTeredo IPv6アドレスを構築し、UDPポートとIPv4アドレスの観測値を原点の表示から学習しました。CONEビットは、RAの受信に使用される値に設定する必要があります。つまり、クライアントがコーンNATの後ろにある場合、それ以外の場合は0。クライアントは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.
これらのパケットでは、NonCe値はクライアントによって選択され、サーバーからの応答で繰り返されます。クライアント識別子は、クライアントが構成された値です。
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.
最初のレベルの保護は、応答のNonCEの値がクライアントが最初に送信した値と一致することを確認するだけで提供されます。それらが一致しない場合、パケットを破棄する必要があります。他の保護が使用されない場合、認証ペイロードには識別子または認証フィールドが含まれていません。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に設定されています。サーバーによって返されるヌル値は、クライアントのキーがまだ有効であることを示します。非ヌル値は、クライアントが新しいキーを取得する必要があることを示します。
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.
より強力な認証が提供されると、クライアントとサーバーは、クライアント識別子、共有秘密、および認証アルゴリズムの識別を提供します。伝送の前に、認証値は指定されたアルゴリズムに従って計算されます。受信では、同じアルゴリズムを使用して、受信パケットのコンテンツからターゲット値を計算します。受信者は、2つの値が一致する場合、認証が成功したと判断します。そうでない場合は、パケットを破棄する必要があります。
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.
- NonCe値、-Confirmenationバイト、 - 存在する場合のオリジン表示カプセル化 - IPv6パケット。
The HMAC procedure is applied to the concatenation of these four components, without any additional padding.
HMAC手順は、追加のパディングなしで、これらの4つのコンポーネントの連結に適用されます。
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.
IPv6パケットは[RFC2460]に準拠している場合に有効であるとみなされます。プロトコル識別子はIPv6パケットを示す必要があり、ペイロードの長さは、パケットがカプセル化されているUDPデータグラムの長さと一致する必要があります。さらに、クライアントは、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.
1) ステータスが信頼されているピアのリストにソースIPv6アドレスのエントリがある場合、クライアントは、パケットのソース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) ステータスが信頼されていないピアのリストにソースIPv6アドレスのエントリがある場合、クライアントはパケットがICMPv6エコーの応答であるかどうかを確認します。この場合、返信のICMPv6データがピアエントリに保存されているNonCEと一致する場合、パケットを受け入れる必要があります。エントリのステータスは「信頼」に変更する必要があります。エントリのマップされたIPv4とマッピングポートは、パケットを受信したソースIPv4アドレスとソースポートに設定する必要があります。ピアを更新する必要があります。このIPv6ピア用にキューに留められているパケット（セクション5.2.4で指定）は、新しく学習したIPv4アドレスとUDPポートに転送され、転送する必要があります。
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.
3) ソースIPv6アドレスがTeredoアドレスである場合、クライアントは、ソースアドレスのマッピングされたIPv4アドレスとマッピングされたポートを、パケットのソースIPv4アドレスとソースポートと比較します。値が一致する場合、クライアントはピアのリストにIPv6ソースアドレスのピアエントリを作成する必要があります。すでに存在している場合は、エントリを更新する必要があります。エントリ内のマッピングされた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 Discoveryアドレスである場合、ソースアドレスは有効なTeredoアドレスであり、宛先アドレスが「リンク上のすべてのノード」マルチキャストアドレスである場合、パケットはローカルとして扱う必要があります発見バブル。ソースアドレスのローカルエントリが既に存在していない場合、新しいエントリが作成されますが、そのステータスは「信頼できない」ように設定されています。クライアントは、地元のディスカバリーバブルのソースIPv4アドレスとソースポートに送信されたユニキャストテレドバブルで返信する必要があります。バブルの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ソースポートが何であれ、IPv6パケットを受信するクライアントは、セクション5.2.6で指定されているように、そのターゲットに向かって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パケットはUDPを介してエントリで指定されたIPv4アドレスと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.
2) 宛先がTeredo IPv6アドレスでない場合、パケットがキューに登録され、クライアントはセクション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.
3) 目的地がローカルピアのTeredo IPv6アドレスである場合（つまり、最後の600秒でローカルディスカバリーバブルを受信したTeredoアドレス）、パケットがキューに登録されます。クライアントは、エントリで指定されたローカルIPv4アドレスとローカルポートにユニキャストテレドバブルを送信し、テレドIPv4ディスカバリーアドレスにローカルテレドバブルを送信します。
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.
4) 宛先がコーンビットを1に設定するTeredo IPv6アドレスである場合、パケットはUDPを介してマッピングされたIPv4アドレスに送信され、そのIPv6アドレスから抽出されたマッピングされたUDPポートが送信されます。
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.
5) 宛先がコーンビットが0に設定されているTeredo IPv6アドレスである場合、パケットはキューに掲載されます。クライアントがコーンナットの後ろにない場合、テレドの宛先、つまりマッピングされたIPアドレスと宛先のマッピングポートに直接バブルを送信します。すべての場合において、クライアントは間接的なバブルをTeredoの宛先に送信し、UDPを介してサーバーアドレスとTeredoポートに送信します。このTeredo Peerからクライアントがバブルまたは別のパケットを直接受信すると、パケットが除外され、転送されます。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:
グローバルユニキャストアドレスチェックは、攻撃者がTeredoホストを使用して、単一のローカルIPv4ターゲットまたはそのようなターゲットのセットを攻撃しようとする多くの可能な攻撃を阻止するように設計されています。この仕様の目的のために、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 Anycastアドレスのために予約されているブロック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」を実行することを決定する場合があります。ナット。これにより、トラフィックがいくらか増加しますが、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.
定期的に、クライアントは「Teredoサーバーとの最後の相互作用の日付と時刻」をチェックして、最後のランダム化されたTeredoリフレッシュ間隔で少なくとも1つのパケットが受信されたことを確認する必要があります。そうでない場合は、セクション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クライアントにバブルを送信する必要がある場合があります。バブルには2種類のバブルがあります。これは、マッピングされたIPv4アドレスに直接送信され、ピアのマッピングされたUDPポートと、ピアのテレドサーバーを介して送信される間接的なバブルです。
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クライアントが直接バブルを送信しようとすると、マッピングされたIPv4アドレスを抽出し、ターゲットのTeredo IPv6アドレスからマッピングされた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:
バブルは輸送中に失われる可能性があり、複数の送信を許可することにより、テレドサービスの信頼性を高めることが合理的です。ただし、特定の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セカンダリIPv6プレフィックスは、セカンダリポートに関連付けられています。、 - 最大テレドリフレッシュ間隔。 - 候補のテレドリフレッシュ間隔。
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秒に設定され、候補のテレドリフレッシュ間隔は60秒、つまり、テレドリフレッシュ間隔の2倍に設定されます。その後、手順は、次のようになるまで、定期的に実行されます。
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 Secondary 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の更新間隔を候補値に設定し、新しい候補値を新しい更新間隔の2倍、または更新間隔の平均と最大リフレッシュ間隔に設定します。
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 Discoveryアドレスによって識別されたIPv4マルチキャストグループに参加する必要があります。クライアントは、Teredo IPv4ディスカバリーアドレスで発見バブルが受信されるのを待つ必要があります。クライアントは、200〜300秒の間に均一に分布するランダムな間隔で、Teredo IPv4ディスカバリーアドレスにローカルディスカバリーバブルを送信する必要があります。地元のテレドバブルには次の特性があります。
- 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ソースポート：送信者のテレドサービスポート
- 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.
悪意のあるノードは、疑いを持たない当事者に偽の泡を送る可能性があり、したがってこれらの当事者からのトラフィックを獲得する可能性があるため、ローカルディスカバリーの手順にはサービスの拒否リスクがあります。リスクは、セクション5.2.5で説明されているフィルタリングルール、およびTeredo IPv4ディスカバリーアドレスの「リンクのみ」マルチキャスト範囲によって軽減されます。これは、このアドレスに送信されたパケットがルーター全体に転送されないことを意味します。
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ソースアドレスが適切に形成されたTeredo IPv6アドレスではない、またはIPv4ソースアドレスがローカルIPv4サブネットに属さないすべてのローカルディスカバリーバブルを静かに廃棄する必要があります。クライアントは、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".
バブルが受け入れられた場合、クライアントは、マッピングされたIPv4アドレスに対応し、バブルのソースIPv6アドレスに関連付けられたマッピングされたUDPポートに対応する最近のピアのリストにエントリがあるかどうかを確認します。そのようなエントリがある場合、クライアントはローカルピアアドレスとローカルピアポートパラメーターを更新して、IPv4ソースアドレスとバブルのUDPソースポートを反映する必要があります。エントリがない場合、クライアントはそれを作成する必要があります。ローカルピアアドレスとローカルピアポートパラメーターを設定して、IPv4ソースアドレスとバブルのUDPソースポートを反映する必要があります。現在の日付の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リレーの間の直接的な接続を可能にするように設計されています。Cone 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アドレスに有効なピアエントリが既に存在するかどうかを確認する必要があります。そうでない場合、クライアントは乱数（非CE）を選択し、ICMPV6エコーリクエストメッセージをフォーマットします。ノンセ。（少なくとも64ビットの長さを乱数を使用することをお勧めします。）NonCe値とPacketが送信された日付は、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」と呼ばれます。セクション5.2.1の資格アルゴリズムは、ローカルNATが対称NATである場合、成功しません。
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の資格アルゴリズムが成功し、テレドクライアントは「コーンナット」の背後にあるかのように振る舞います。
When different clients use Teredo behind a single symmetric NAT, each of these clients must reserve and use a different service port.
異なるクライアントが単一の対称NATの背後にテレドを使用する場合、これらの各クライアントは、別のサービスポートを予約して使用する必要があります。
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 Server」と「Teredo Relay」の機能を組み合わせることを決定する場合があります。
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.
1) セクション5.1.1で定義されているように、UDPコンテンツがよく形成されたTeredo IPv6パケットではない場合、パケットは静かに破棄する必要があります。
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.)
2) UDPパケットがTeredoバブルやICMPV6メッセージではない場合は、破棄する必要があります。（セクション5.4で説明されているように、TeredoサーバーもTeredoリレーとして動作する場合、パケットを処理できます。）
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).
3) IPv4ソースアドレスがグローバルユニキャストアドレスの形式でない場合、パケットは静かに破棄する必要があります（グローバルユニキャストアドレスの定義については、セクション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 Link-Localアドレスである場合、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宛先アドレスがLink-Localスコープである場合、すべてのルーターマルチキャストアドレス（FF02 :: 2）、またはサーバーのリンクローカルアドレスがパケットを処理します。ルーターの勧誘メッセージと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 Server 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ペイロードの最初のバイトにオリジン表示を挿入する必要があります。（クライアントがこのサーバーによって提供されていることを確認するために、サーバーはクライアントのTeredo IPv6アドレスのビット32-63をサーバーのIPv4アドレスと比較します。）
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サーバーは、ルーター広告メッセージ[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 Link-Local Serverアドレスに設定する必要があります。このアドレスは、セクション4で指定されているように、サーバーのIPv4アドレスとTeredoポートから派生しています。コーンビットは1に設定されています。IPv6宛先アドレスは、RsのIPv6ソースアドレスに設定されています。ルーター広告メッセージは、UDPを介してTeredoマッピングアドレスとクライアントのTeredoマッピングポートに送信する必要があります。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パケットに有効な認証パラメーターを挿入する必要があります。クライアント識別子と認証パラメーターで使用されるNonCE値は、ルーター勧誘で受信した識別子と同じ識別子と非CEでなければなりません。クライアントの識別子がまだ有効である場合、確認バイトをゼロに設定する必要があり、それ以外の場合は非null値です。認証値は、クライアント識別子に対応する秘密を使用して計算する必要があります。
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サービスポートを使用してPacketを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パケットはUDPを介してマッピングされたIPv4アドレスに送信し、エントリのマッピングされた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に設定されているテレドIPv6アドレスである場合、パケットはUDPを介してマッピングされたIPv4アドレスに送信され、そのIPv6から抽出されたマッピングされたUDPポートが送信されます住所。
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.
3) ピアのリストに信頼できるエントリがない場合、および宛先がコーンビットが0に設定されているテレドIPv6アドレスである場合、テレドリレーは、ソースアドレスがローカルIPv6アドレスに設定され、そのバブルが作成されます。宛先アドレスは、パケットの宛先のTeredo IPv6アドレスに設定されています。バブルは、テレドの宛先に対応するサーバーアドレスに送信されます。このIPv6アドレスからバブルまたは別のパケットが受信されると、エントリは信頼されます。2秒のタイムアウト前にそのようなパケットが受信されない場合、Teredoリレーは最大3回バブルを繰り返す可能性があります。リレーがこれらの繰り返しの後にバブルを受け取らない場合、エントリはピアのリストから削除されます。リレーは、信頼されていないエントリにバインドされたパケットをキューにすることができます。エントリが信頼できるようになったときに、キューに囲まれたパケットを除去し、転送する必要があります。エントリが削除されている場合は、削除する必要があります。サービス拒否攻撃を避けるために、リレーはそのようなキュー内のパケットの数を制限する必要があります。
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では、テレドリレーがたまたま非コーン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」を実行することを決定する場合があります。これにより、トラフィックがいくらか増加しますが、回避する場合があります
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ステータスの決定が何らかの理由で誤っていた場合、信頼性の問題。同じ理由で、リレーは、マッピングされたIPv4アドレスに常に直接バブルを送信し、テレドの目的地のマッピングされたポート番号を送信することもできます。
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 Relayは、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.
TeredoサービスポートでUDPパケットが受信されると、Teredoリレーは[RFC2460]で指定されている有効なIPv6パケットが含まれていることをチェックします。そうでない場合、パケットは静かに破棄されます。
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 Relayは、最近のピアのリストに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アドレスの範囲に属している場合、パケットを受け入れて宛先に転送する必要があります。他の場合、パケットは静かに廃棄する必要があります。
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.
Teredoで利用可能なノードは、ネイティブIPv6接続など、他の手段を介してIPv6接続を既に持っている場合、Teredoクライアントとして動作してはなりません。特に、グローバルIPv4アドレスを持つノードは、Teredoサービスではなく6to4サービスを介して接続を取得する必要があります。接続を必要としないノードが依然として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ディスカッションでは、構成されたトンネルをサービスプロバイダーに使用して、Teredoとより制御されたNATトラバーサルソリューションの両方のソリューションの両方の必要性を概説しました[RFC3904]。このセクションでは、構成されたトンネルサービスもサポートするために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.
Teredoクライアントは、セクション5.2.2で指定されているように、安全な資格手順を使用します。ルーター広告で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プレフィックスであることに気付きます。クライアントは、その時点で、トンネルモードで動作する必要があることを認識します。トンネルモードで動作するクライアントは、はるかにシンプルな送信手順を実行します。Teredoインターフェイスに送信されたパケットは、サーバーのIPv4アドレスとTeredo UDPポートに転送されます。
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で説明されているメンテナンス手順を実行する必要があります。サーバーはルーターの勧誘を受信し、NAT内のマッピングの再構成から生じる可能性のあるマッピングされたIPv4アドレスとマッピングされた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-Traversal "[rfc3947]。そのため、このサービスはネットワークセキュリティにプラスの効果があると主張できます。ただし、セキュリティ分析では、Teredoサービスのマイナス効果も想定する必要があります。これは、ノードを直接IPv6インターネットに接続するセキュリティリスク、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.
最初の緩和因子は、地元の隣人からのトラフィックのみを受け入れるように一部のサービスを制限する可能性です。たとえば、Link-Localアドレスを使用します。Teredoは、Link-Localアドレスを使用した通信をサポートしていません。これは、Link-LocalサービスにTeredoを介してアクセスされないことを意味し、NATの後ろのローカルリンク上の近隣との直接トラフィックなど、他のIPv6接続が利用できるものに制限されることを意味します。
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.
2番目の緩和要因は、「ローカルファイアウォール」ソリューションの使用の可能性、つまり、境界ファイアウォールで実行される検査とフィルタリングの種類をローカルで実行するソフトウェアです。このようなソフトウェアの使用をお勧めします。
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.)
3番目の緩和要因は、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の後ろにあるホストを提供することです。このサービスに対する攻撃の可能なクラスがあります。このサービスでは、攻撃者が何らかの形でルーターの勧誘を傍受し、スプーフィングされたルーター広告で応答し、テレドクライアントに誤ったアドレスを提供します。攻撃者は2つの目的のいずれかを持っている場合があります。実際には到達不可能なアドレスを提供することにより、Teredoクライアントへのサービスを拒否しようとするか、すべてのクライアント通信のリレーとして自分自身を挿入しようとする場合があります。「中間者」の攻撃の。
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で説明されている単純な非CE検証手順は、サードパーティがサーバーをスプーフィングしようとする攻撃に対する最初のレベルの保護を提供します。実際には、攻撃者が「パス上」である場合にのみ、NonCEの手順を打ち負かすことができます。
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) 攻撃者は、リクエストのソース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.
4) サーバーは、パケットが受信されるIPv4アドレス、認証のカプセル化が正しいことを確認し、ルーター広告を準備し、署名し、着信アドレス、つまり攻撃者に送り返すことを確認します。
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自体が中間の攻撃であることです。認証カプセル化は、カプセル化された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.
ただし、この攻撃についてあまり心配しないようにするために、いくつかの緩和要因があります。実際には、攻撃からの利益は、クライアントへのサービスを拒否するか、「中間者」の位置を取得することです。ただし、攻撃を行うには、攻撃者はクライアントから発信されたトラフィックを抑制できる必要があります。つまり、サービス機能の拒否を持つ必要があります。攻撃者はまた、クライアントの間で交換されたトラフィックを観察し、ミックスに独自のトラフィックを注入することもできなければなりません。つまり、中間の容量を持っています。要約すると、攻撃を取り付けるのは非常に困難であり、「特権の上昇」という点での攻撃者の利益は最小限です。
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.
攻撃者は、Teredoを使用して、別のIPv6ホストに自分自身を渡すか、TeredoホストとネイティブIPv6ホストの間の中間者として自分自身を配置しようとすることができます。攻撃者は、Teredoリレーをスプーフィングすることにより、つまり、TeredoホストにネイティブIPv6ホストにバインドされたパケットを攻撃者のIPv4アドレスにリレーすることを納得させることにより、そのような攻撃を実施します。
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接続テスト」によって軽減されます。このテストでは、ノンセによって保護されたリレー発見手順を指定します。NonCEは、クライアントが通常信頼している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.
攻撃者がテレドのホストとそのピアの間の直接的な道にいる場合、スプーフィング攻撃から防御するには、エンドツーエンドのセキュリティ保護が必要です。
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サービス自体を保護しようとしないことです。マッピングを安全に取得できる場合でも、攻撃者はトラフィックを聞いて、スプーフィングされたパケットを送信することができます。むしろ、テレドのクライアントは、それがNATの後ろにあるので、それは
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.
Rogue Relayをセットアップし、そのリレーにTeredo IPv6プレフィックスへのルートを宣伝することにより、攻撃をサービスのIPv6側に取り付けることができます。これは、IPv6ルーティングに対する攻撃であり、スプリアスルート広告を排除するために使用される同じ種類の手順によっても軽減できます。「ホストローカル」テレドリレーを実装するデュアルスタックノードは、この攻撃に不浸透性です。
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.
Teredoクライアントは、新しく取得したIPv6アドレスを介してトラフィックを受け取らなかったときに攻撃を検出します。攻撃は、認証カプセル化を使用して軽減できます。
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のクライアントは、最近中古のピアのキャッシュを管理しているため、ステートフルになります。クライアントが多数のテレドピアから来るように見えるパケットに応答するように誘導することにより、クライアントに対する攻撃を取り付けることができます。したがって、キャッシュを破壊し、ピア間の直接的な通信の使用を効果的に拒否します。効果は、攻撃が維持されている限り続くだけです。
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.
攻撃者がスプーフィングされたローカルディスカバリーバブルをテレドクライアントに送ることができれば、地元のピアディスカバリー手順に対するサービス拒否攻撃の可能性があります。セクション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.
非常に多数のパケットを送信することにより、テレドサーバーに対するブルートフォースのサービス拒否攻撃を取り付けることができます。サーバーはステートレスであり、アクセスラインに送信されるすべてのパケットを処理するように設計できるため、この攻撃はブルートフォースでなければなりません。
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サーバーに対するブルートフォース攻撃は緩和されます。ただし、サーバーを下げることで、サーバーを変更するクライアントにテレドアドレスの変更を強制します。
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.
また、テレドリレーに対するブルートフォース攻撃を取り付けることも可能です。この攻撃は、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ホストは、IPv6パケットを多数のTeredo宛先に送信でき、これらの各宛先の状態を確立するリレーを強制します。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.
テレドなどの移行メカニズムを使用して、予想されていない場所にトラフィックを注入することにより、サービス拒否攻撃の取り付けに使用できるという広く表現された懸念があります。これらの攻撃は、3つのカテゴリに分類されます。Teredoサーバーをサービス拒否攻撃のリフレクターとして使用し、Teredoサーバーを使用してIPv6ノードに対するサービス拒否攻撃を実行し、Teredoリレーを使用してIPv4に対するサービス攻撃の拒否を運ぶノード。これらの攻撃の分析が続きます。すべての場合の一般的な緩和因子は、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サーバーを使用できます。攻撃者は、2つの方法のいずれかでこれを行うことができます。最初の方法は、ルーターの勧誘を構築することです
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サーバーに投稿します。Teredoサーバーは、ターゲットにルーター広告メッセージを送信します。2番目の方法は、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.
リフレクター攻撃は[反射]で議論されており、このような攻撃に対するさまざまな緩和技術の概要を説明します。これらの緩和の1つは、「リフレクターによって生成されたトラフィックは、フィルタリング自体が被害者へのサービスの拒否を構成することなく、被害者の近くで除外できるという十分な規則性とセマンティクスを持っていることを観察することです。）」。Teredoサーバーに反映されるトラフィックは、この状態を満たしています。TeredoUDPポートに由来するため、明らかに認識できます。ターゲット自体が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.
攻撃者は、Teredoサーバーを使用して、任意のIPv6宛先に対するサービス拒否攻撃を開始できます。攻撃者は、ターゲットにバインドされたIPv6パケットを構築し、そのパケットをTeredoサーバーのIPv4アドレスとUDPポートに送信し、そこからIPv6を介してターゲットに中継します。
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.
セクション5.3.1で指定されたアドレスチェックは、IPv6ソースアドレスが攻撃者が使用するIPv4ソースアドレスおよびUDPソースポートと一致することを保証するため、この攻撃に対するある程度の保護を提供します。、ターゲットは攻撃の起源を決定できます。
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プレフィックスから始まることを保証します。これは緩和要因です。これは、攻撃を受けているサイトを使用して、攻撃中にそのプレフィックスから供給されたすべてのパケットを除外できるためです。これにより、ターゲットが同じプレフィックスを使用する合法的なテレドホストと通信できないため、部分的なサービスが失われます。
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接続を備えた攻撃者は、Teredoリレーを使用して、任意のIPv4宛先に対するサービス拒否攻撃を開始する場合があります。攻撃者は、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ルーティングを使用してIPv6パケットをTeredo宛先に送信します。パケットは最寄りのリレーで選ばれ、ターゲットのIPv4アドレスに転送されます。より精巧なバリアントでは、攻撃者はテレドをだまして、スプーフィングされた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.
攻撃者がスプーフィングされたテレドアドレスに埋め込む可能性のある3種類のIPv4アドレスがあります。マルチキャストまたはブロードキャストアドレス、ローカルユニキャストアドレス、またはグローバルユニキャストアドレスを埋め込む場合があります。
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.
攻撃は、たとえばサーバーのDNSポートなど、任意のUDPポートを対象とすることができます。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.
攻撃がエコーサービスに向けられている場合、特別なケースが発生します。このサービスはパケットをエコーします。Echoサービスでは、リレーのIPv4アドレスからのリクエストが表示されるため、エコー応答は同じリレーに送り返されます。セクション5.4で指定されたルールによると、これらのパケットは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は、「一方的なセルフアドレス修正」（UNSAF）の問題を研究しました。これは、クライアントが共同プロトコル反射メカニズムを通じてNATの反対側の別の領域のアドレスを決定しようとする一般的なプロセスです[RFC3424]。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には独自の組み込みの出口戦略が付属しています。クライアントが6to4またはネイティブIPv6のいずれかで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の使用が減少すると、リレーのトラフィック負荷が低下します。時間が経つにつれて、マネージャーはリレーのトラフィック負荷の減少を観察し、それらをオフにし、残りのテレドホストへの圧力を効果的に上げて、別の形式の接続にアップグレードします。
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：Network Connectivityからの移行が容易になります。
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ホストに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. 何らかの理由で、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のピアとのコミュニケーションを希望するホストは、「ホストベースのリレー」を実装できます。そのため、デュアルホームのホストは、テレドを使用する必要があるが、他のデュアルホームのホストがテレドサービスの使用を続けるように誤って奨励することはありません。
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カプセル化は、重要なオーバーヘッドを導入します。ネイティブテクノロジーがテレドよりも低いサービスを提供するには、例外的な状況が必要です。これらの例外的な状況、またはその他の予期しない理由は、ネイティブIPv6接続が利用可能にもかかわらず、ホストがテレドサービスを使用し続けるように誘導する可能性があります。ただし、これらの状況はまれで一時的なものである可能性があります。さらに、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）を介したUDPプロトコルの単純なトラバーサルによって導入された点との間には、多くの類似点があります[RFC3489]。しかし、テレドはおそらくスタンよりもやや脆いです。その理由は、すべてのTeredoパケットが、発見、バブル、実際のカプセル化されたパケットを含むローカルIPv4 Teredoサービスポートから送信されるためです。これは、NATタイプの検出とバインディング割り当てが異なるローカルポート（両方の場合にかけて）を使用しているスタンとは異なります。
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の処理に基づいてデバイスの特定の分類を想定しています（例えば、コーン、保護されたコーン、対称）。これらの金型の1つに収まらないデバイスがある可能性があるため、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ピアとの接続を必要とするネイティブ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:
また、言及する価値のあるbrittlenessの追加ポイントもあります。
- Teredo service will not work through NATs of the symmetric variety.
- Teredo Serviceは、対称品種のNatsを介して機能しません。
- 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サービスにジッターを導入します。このジッターは、Voice over 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問題に対する長期的な解決策のための以下の要件につながりました。IPv4NATサービスを実装するデバイスは、将来的に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.6で指定されているように、32ビットTeredo IPv6サービスプレフィックスとセクション2.17で指定されているTeredo IPv4マルチキャストアドレスを割り当てるという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.
このメモのアイデアの多くは、著者とMicrosoftの同僚、特にBrian Zill、John Miller、Mohit Talwar、Joseph Davies、およびRick Rashidの議論の結果です。いくつかのカプセル化の詳細は、キース・ムーアによる以前の作品からインスピレーションを受けています。セクション5.1および多くのセキュリティ予防措置の例は、Pekka Savolaによって提案されました。地元の発見手順は、リチャード・ドラヴェスとデイブ・タラーによって提案されました。この文書は、ブライアン・カーペンター、シンディ・ジョン、キース・ムーア、トーマス・ナルテン、アンシ・ポルティキビ、ペッカ・サヴォラ、エング・スー・グアン、エッフェル・ウーなど、NGTRANSおよびV6OPSワーキンググループのメンバーによってレビューされました。エリック・クライン、カレン・ニールセン、フランシス・デュポン、マークク・アラ・ヴァンヌスルーマ、ヘンリック・レヴコウェッツ、ジョナサン・ローゼンバーグは、IETFの最後の電話で詳細なレビューを提供しました。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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.、Bellare、M。、およびR. CaNetti、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424] Daigle、L。およびIAB、「ネットワークアドレス翻訳全体の一方的な自己アドレス固定（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月。
[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]「Secure Hash Standard」、Computer Systems Laboratory、国立標準技術研究所、米国商務省、1993年5月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993] Hain、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] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy。「スタン - ネットワークアドレス翻訳者（NAT）を介したユーザーデータグラムプロトコル（UDP）の単純なトラバーサル」、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. van der Pol、「管理されていないネットワークの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. Volpe、「IKEにおけるNat-Traversalの交渉」、RFC 3947、2005年1月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（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. Paxson、「分散型サービス攻撃のためにリフレクターを使用することの分析」、コンピューターコミュニケーションレビュー、ACM Sigcomm、第31巻、2001年7月、pp 38-47。
Author's Address
著者の連絡先
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Christian Huitema Microsoft Corporation One Microsoft Way Redmond、WA 98052-6399
EMail: huitema@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。