RFC4380 日本語訳
4380 Teredo: Tunneling IPv6 over UDP through Network AddressTranslations (NATs). C. Huitema. February 2006. (Format: TXT=132607 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Huitema Request for Comments: 4380 Microsoft Category: Standards Track February 2006
Huitemaがコメントのために要求するワーキンググループC.をネットワークでつないでください: 4380年のマイクロソフトカテゴリ: 標準化過程2006年2月
Teredo: Tunneling IPv6 over UDP
through Network Address Translations (NATs)
船食虫: ネットワークアドレス変換でUDPの上でIPv6にトンネルを堀ります。(NATs)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays". The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such as "6to4".
私たちはここで1IPv4 Network Address Translations(NATs)の後ろに位置するノードがトンネリングパケットでIPv6の接続性をUDPの上として得るのを可能にするサービスを提案します。 私たちは、これを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
1. 序論…3 2. 定義…4 2.1. 船食虫サービス…4 2.2. 船食虫クライアント…4 2.3. 船食虫サーバ…4 2.4. 船食虫リレー…4 2.5. 船食虫IPv6は接頭語を修理します…4 2.6. グローバルな船食虫IPv6は接頭語を修理します…4 2.7. 船食虫UDPポート…4 2.8. 船食虫気泡…4 2.9. 船食虫サービスポート…5 2.10. 船食虫サーバアドレス…5 2.11. 船食虫はアドレスを写像しました、そして、船食虫はポートを写像しました…5 2.12. 船食虫IPv6クライアント接頭語…5
Huitema Standards Track [Page 1] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[1ページ]。
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
2.13. 船食虫ノード識別子…5 2.14. 船食虫IPv6アドレス…5 2.15. 船食虫は間隔をリフレッシュします…5 2.16. 船食虫のセカンダリポート…6 2.17. 船食虫IPv4発見アドレス…6 3. 操作の目標、要件、およびモデルを設計してください…6 3.1. NATの振舞いに関する仮説…6 3.2. 切り札のIPv6プロバイダー…8 3.3. 操作上の要件…9 3.4. 操作のモデル…10 4. 船食虫アドレス…11 5. クライアント、サーバ、およびリレーの仕様…13 5.1. メッセージ形式…13 5.2. 船食虫クライアント仕様…16 5.3. 船食虫サーバ仕様…31 5.4. 船食虫リレー仕様…33 5.5. 自動日没の実装…36 6. さらなる研究、トンネルサービスを実装する船食虫の使用…37 7. セキュリティ問題…38 7.1. NATの穴を開きます…38 7.2. 中央の男性に船食虫サービスを利用して、攻撃してください…39 7.3. Teredoサービスの否定…42 7.4. 非船食虫ノードに対するサービス妨害…43 8. IAB問題…46 8.1. 問題定義…46 8.2. 撤退戦略…47 8.3. 船食虫によって導入されたもろさ…48 8.4. 長期的な解決法のための要件…50 9. IANA問題…50 10. 承認…50 11. 参照…51 11.1. 標準の参照…51 11.2. 有益な参照…52
Huitema Standards Track [Page 2] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[2ページ]。
1. Introduction
1. 序論
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候補ノードがNetwork Address Translator(NAT)デバイスの後ろで隔離されるとき、働いていないということです: NATsが任意のペイロードタイプのトランスミッションを許容するように通常プログラムされません。 それらがそうときにさえ、6to4体系にローカルアドレスを使用できません。 同じ箱の中にNATと6to4ルータ機能があると、6to4はNATで働くでしょう。 NATが6to4ルータ機能を提供するために容易にアップグレードできないとき、比較的頻繁なケースをカバーしたいと思います。
A possible way to solve the problem is to rely on a set of "tunnel brokers". However, there are limits to any solution that is based on such brokers: the quality of service may be limited, since the traffic follows a dogleg route from the source to the broker and then the destination; the broker has to provide sufficient transmission capacity to relay all packets and thus suffers a high cost. For these two reasons, it may be desirable to have solutions that allow for "automatic tunneling", i.e., let the packets follow a direct path to the destination.
問題を解決する可能な方法は1セットの「トンネルのブローカー」を当てにすることです。 しかしながら、そのようなブローカーに基づいているどんなソリューションへの限界もあります: サービスの質は制限されるかもしれません、トラフィックがソースからブローカーと次に、目的地までの急カーブルートに従うので。 ブローカーは、すべてのパケットをリレーできるくらいの送信能力を提供しなければならなくて、その結果、高い費用を受けます。 これらの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.
自動トンネリング要件が本当にNATsの特異性のいくつかと仲たがいしてあります。 直接路を確立するのは、IPv6候補ノードが1NATsによるローカルアドレスに関する翻訳から生じる「グローバルに発送可能な」アドレスを検索できると思います。 また、それは、私たちが多くのNATsが実装する様々な「目的地保護」を迂回させる方法を見つけることができると思います。 このメモでは、私たちはIPv6候補がそれらの「グローバルアドレス」を学んで、接続性を得るためにNATs使用の後ろに「船食虫サーバ」をどのように位置させたか、そして、「船食虫リレー」でネイティブのIPv6ホストとどのようにパケットを交換するか、そして、Teredoネットワークでどうしたらクライアント、サーバ、およびリレーは組織化できるかを説明するつもりです。
The specification is organized as follows. Section 2 contains the definition of the terms used in the memo. Section 3 presents the hypotheses on NAT behavior used in the design, as well as the operational requirements that the design should meet. Section 4 presents the IPv6 address format used by Teredo. Section 5 contains the format of the messages and the specification of the protocol. Section 6 presents guidelines for further work on configured tunnels that would be complementary to the current approach. Section 7 contains a security discussion, section 8 contains a discussion of the Unilateral Self Address Fixing (UNSAF) issues, and section 9 contains IANA considerations.
仕様は以下の通り組織化されます。 セクション2はメモで使用される用語の定義を含みます。 セクション3はデザインに使用されるNATの振舞いのときに仮説を提示します、デザインが満たされるべきであるという操作上の要件と同様に。 セクション4はTeredoによって使用されたIPv6アドレス形式を提示します。 セクション5はメッセージの形式とプロトコルの仕様を含みます。 セクション6は現在のアプローチを補足する構成されたトンネルへのさらなる作業のためのガイドラインを提示します。 セクション7はセキュリティ議論を含みます、そして、セクション8はUnilateral Self Address Fixing(UNSAF)問題の議論を含みます、そして、セクション9はIANA問題を含みます。
Huitema Standards Track [Page 3] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[3ページ]。
2. Definitions
2. 定義
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
This specification uses the following definitions:
この仕様は以下の定義を使用します:
2.1. Teredo Service
2.1. 船食虫サービス
The transmission of IPv6 packets over UDP, as defined in this memo.
このメモで定義されるようなUDPの上のIPv6パケットのトランスミッション。
2.2. Teredo Client
2.2. 船食虫クライアント
A node that has some access to the IPv4 Internet and wants to gain access to the IPv6 Internet.
IPv4インターネットにいくつか近づく手段を持っているノードと獲得する必需品はインターネットにIPv6にアクセスします。
2.3. Teredo Server
2.3. 船食虫サーバ
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の接続性をTeredoクライアントに提供するのにアシスタントとして使用されるノード。
2.4. Teredo Relay
2.4. 船食虫リレー
An IPv6 router that can receive traffic destined to Teredo clients and forward it using the Teredo service.
Teredoサービスを利用することでTeredoクライアントに運命づけられたトラフィックを受けて、それを進めることができるIPv6ルータ。
2.5. Teredo IPv6 Service Prefix
2.5. 船食虫IPv6サービス接頭語
An IPv6 addressing prefix that is used to construct the IPv6 address of Teredo clients.
接頭語がそれであると扱うIPv6は、TeredoクライアントのIPv6アドレスを構成するのに使用されます。
2.6. Global Teredo IPv6 Service Prefix
2.6. グローバルな船食虫IPv6サービス接頭語
An IPv6 addressing prefix whose value is 2001:0000:/32.
接頭語が値であると扱うIPv6は2001:0000:/32です。
2.7. Teredo UDP Port
2.7. 船食虫UDPポート
The UDP port number at which Teredo servers are waiting for packets. The value of this port is 3544.
UDPはTeredoサーバがパケットを待っている数を移植します。 このポートの値は3544です。
2.8. Teredo Bubble
2.8. 船食虫気泡
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パケットです。 ペイロードタイプは[RFC2460]のように59、どんなNext Headerにも用意ができていません。 Teredoクライアントとリレーは、NATにおけるマッピングを作成するために気泡を送るかもしれません。
Huitema Standards Track [Page 4] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[4ページ]。
2.9. Teredo Service Port
2.9. 船食虫サービスポート
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つに取り付けられます。 IPv4アドレスはグローバルに発送可能であるかもしれません、クライアントが1つ以上のNATの後ろに位置しているとき。
2.10. Teredo Server Address
2.10. 船食虫サーバアドレス
The IPv4 address of the Teredo server selected by a particular client.
特定のクライアントによって選択されたTeredoサーバのIPv4アドレス。
2.11. Teredo Mapped Address and Teredo Mapped Port
2.11. 船食虫はアドレスを写像しました、そして、船食虫はポートを写像しました。
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アドレスとUDPに関する翻訳からの結果が移植するクライアントのTeredoサービスのグローバルなIPv4アドレスとUDPポートは、より1時までにNATsを移植します。 クライアントはこのメモで説明されたTeredoプロトコルを通してこれらの値を学びます。
2.12. Teredo IPv6 Client Prefix
2.12. 船食虫IPv6クライアント接頭語
A global scope IPv6 prefix composed of the Teredo IPv6 service prefix and the Teredo server address.
グローバルな範囲IPv6接頭語はTeredo IPv6サービス接頭語とTeredoサーバアドレスで構成されました。
2.13. Teredo Node Identifier
2.13. 船食虫ノード識別子
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.
クライアントがIPv4インターネットにアクセスするNATのタイプを示す旗と同様にUDPポートを含む64ビットの識別子とTeredoサービスでクライアントに連絡できるIPv4アドレス。
2.14. Teredo IPv6 Address
2.14. 船食虫IPv6アドレス
A Teredo IPv6 address obtained by combining a Teredo IPv6 client prefix and a Teredo node identifier.
Teredo IPv6クライアント接頭語とTeredoノード識別子を結合することによって得られたTeredo IPv6アドレス。
2.15. Teredo Refresh Interval
2.15. 船食虫は間隔をリフレッシュします。
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サーバへの経路のNATsの組み合わせに依存します。デフォルトで、クライアントは30秒の間隔値を仮定します。 より長い値はセクション5で説明されるようにローカル・テストで決定するかもしれません。
Huitema Standards Track [Page 5] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[5ページ]。
2.16. Teredo Secondary Port
2.16. 船食虫のセカンダリポート
A UDP port used to send or receive packets in order to determine the appropriate value of the refresh interval, but not used to carry any Teredo traffic.
UDPポートが適切な値を決定するためにパケットを送るか、または受けるのに使用した、しかし、どんなTeredoトラフィックも運ぶのにおいて使用されていなく間隔をリフレッシュしてください。
2.17. Teredo IPv4 Discovery Address
2.17. 船食虫IPv4発見アドレス
An IPv4 multicast address used to discover other Teredo clients on the same IPv4 subnet. The value of this address is 224.0.0.253.
IPv4マルチキャストアドレスは以前は同じIPv4サブネットでよく他のTeredoクライアントを発見していました。 このアドレスの値はそうです。224.0 .0 .253。
3. Design Goals, Requirements, and Model of Operation
3. 操作のデザイン目標、要件、およびモデル
The proposed solution transports IPv6 packets as the payload of UDP packets. This is based on the observation that TCP and UDP are the only protocols guaranteed to cross the majority of NAT devices. Tunneling packets over TCP would be possible, but would result in a poor quality of service; encapsulation over UDP is a better choice.
提案されたソリューションはUDPパケットのペイロードとしてIPv6パケットを輸送します。 NATデバイスの大部分に交差するように保証されて、これはTCPとUDPが唯一のプロトコルであるという観測に基づいています。 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.
私たちのソリューションのデザインは1セットの仮説と振舞いのNATs(「切り札のIPv6プロバイダー」、および操作上の要件のリストを提供する私たちの願望)の観測に基づいています。 それはTeredoサービスが1セットのサーバとリレーで可能にされる操作のモデルをもたらします。
3.1. Hypotheses about NAT Behavior
3.1. NATの振舞いに関する仮説
NAT devices typically incorporate some support for UDP, in order to enable users in the natted domain to use UDP-based applications. The NAT will typically allocate a "mapping" when it sees a UDP packet coming through for which there is not yet an existing mapping. The handling of UDP "sessions" by NAT devices differs by two important parameters, the type and the duration of the mappings.
NATデバイスはUDPの何らかのサポートを通常取り入れます、nattedドメインのユーザがUDPベースのアプリケーションを使用するのを可能にするために。 現れる既存のマッピングがまだないUDPパケットを見るとき、NATは「マッピング」を通常割り当てるでしょう。 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」、「制限された円錐のNAT」、「ポートは円錐のNATを制限したこと」の間で区別されるか、そして、および「左右対称のNAT」で分析されます。 Teredoソリューションは、円錐のNATs、制限された円錐のNATs、またはポートの後ろに位置するクライアントへの接続性が円錐のNATsを制限したのを確実にします。
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の後ろでしばしば失敗するでしょう、彼らの同輩がNATが予想するUDPポートナンバーを予測できないので。
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
左右対称のNATの後ろに位置するクライアントは、彼らがどうにかNATをプログラムできるならTeredoを使用して、各クライアント、例えば、DMZが機能する使用のためにTeredoサービスポートを予約できるだけでしょう。
Huitema Standards Track [Page 6] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[6ページ]。
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。 これは明らかに自動ソリューションのデザイン目標と仲たがいして煩わしい要件です。 しかしながら、文書化の測定キャンペーンと研究は、左右対称のNATsが少なくとも簡単な"非管理"のネットワークでわずかな数の小数であることを示しました。 そのうえ、新しいNATモデルかファームウェアアップグレードが「左右対称」のデザインを避けるように思えます。
Investigations on the performance of [RFC3489] have shown the relative frequency of a particular NAT design, which we might call "port conserving". In this design, the NAT tries to keep the same port number inside and outside, unless the "outside" port number is already in use for another mapping with the same host. Port conserving NAT appear as "cone" or "restricted cone NAT" most of the time, but they will behave as "symmetric NAT" when multiple internal hosts use the same port number to communicate to the same server.
[RFC3489]の性能の調査は特定のNATデザインの相対度数を示しました。(私たちはデザインを「ポート保存」と呼ぶかもしれません)。 このデザインでは、NATは、同じポートナンバーが内外であることを保とうとします、別のマッピングには、「外」のポートナンバーが同じホストと共に既に使用中でない場合。 保存NATが現れるポートは、たいてい「円錐形にする」か、または「円錐のNATを制限しました」が、複数の内部のホストが同じくらい使用すると「左右対称のNAT」が同じサーバに伝えるために数を移植するとき、それらは振る舞うでしょう。
The Teredo design minimizes the risk of encountering the "symmetric" behavior by asking multiple hosts located behind the same NAT to use different Teredo service ports.
Teredoデザインは異なったTeredoサービスポートを使用するように同じNATの後ろに位置する複数のホストに頼むことによって「左右対称」の振舞いに遭遇する危険を最小にします。
Other investigation in the behavior of NAT also outlined the "probabilistic rewrite" behavior. Some brands of NAT will examine all packets for "embedded addresses", IP addresses, and port numbers present in application payloads. They will systematically replace 32-bit values that match a local address by the corresponding mapped address. The Teredo specification includes an "obfuscation" procedure in order to avoid this behavior.
また、NATの振舞いにおける他の調査は「確率的な書き直し」の振舞いについて概説しました。 NATのいくつかのブランドがアプリケーションペイロードにおける現在の「埋め込まれたアドレス」、IPアドレス、およびポートナンバーがないかどうかすべてのパケットを調べるでしょう。 彼らは系統的に対応する写像しているアドレスでローカルアドレスに合っている32ビットの値を取り替えるでしょう。 Teredo仕様は、この振舞いを避けるために「困惑」手順を含んでいます。
Regardless of their types, UDP mappings are not kept forever. The typical algorithm is to remove the mapping if no traffic is observed on the specified port for a "lifetime" period. The Teredo client that wants to maintain a mapping open in the NAT will have to send some "keep alive" traffic before the lifetime expires. For that, it needs an estimate of the "lifetime" parameter used in the NAT. We observed that the implementation of lifetime control can vary in several ways.
彼らのタイプにかかわらず、UDPマッピングはいつまでも、保たれません。典型的なアルゴリズムはトラフィックが全く「生涯」の期間、指定されたポートの上で観測されないならマッピングを取り除くことです。 NATで開くのにマッピングを維持したがっているTeredoクライアントは生涯の前のトラフィックが吐き出すいくつかの「生きているままでいてください」を送らなければならないでしょう。 それのために、それは、NATに「生涯」パラメタの見積りを使用する必要があります。 私たちは、生涯コントロールの実装がいくつかの方法で異なることができるのを観測しました。
Most NATs implement a "minimum lifetime", which is set as a parameter of the implementation. Our observations of various boxes showed that this parameter can vary between about 45 seconds and several minutes.
ほとんどのNATsが「最小の生涯」を実装します。(それは、実装のパラメタとして設定されます)。 私たちの様々な箱の観測は、このパラメタがおよそ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.
多くのNATsでは、トラフィックがないときでさえこの最小限を超えている持続時間のためにマッピングを保つことができます。 私たちは、多くの実装が特別なイベントの未使用のマッピングの「ガーベージコレクション」を実行すると疑います、例えば、マッピングの総合的な数が何らかの限界を超えていると。
Huitema Standards Track [Page 7] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[7ページ]。
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.
接続が釈放されるとき、すなわち、トラフィックが全くしばらく接続に観測されないとき、いくつかのケース、例えば、Integrated Services Digital Network(ISDN)かダイアルアップ接続を管理するNATsでは、マッピングは数分について発表されるでしょう。
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手順は複数のNATsとクライアントの間のクライアントのコミュニケーションにこれらのNATsの「反対側」を確実にするでしょう。 また、クライアントが同じ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]で定義されたプライベート・アドレスであると特に仮定しません。
3.2. IPv6 Provider of Last Resort
3.2. 切り札のIPv6プロバイダー
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.
船食虫は、ノードへの「切り札のIPv6アクセス」にその必要性IPv6の接続性を提供するように設計されていますが、他のIPv6変遷体系のいずれも使用できません。 この設計目標には、いつTeredoを使用するか、そして、どのようにクライアントをプログラムするか、そして、サーバに何を予想したらよいかに関していくつかの結果があります。 別の結果は私たちが、時間内にのTeredo技術が使用されるのをやめる点がわかると予想するということです。
3.2.1. When to Use Teredo
3.2.1. いつ船食虫を使用しますか。
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.
船食虫はNATsを通してIPv6トラフィックを強壮に可能にするように設計されています、そして、丈夫さの価格はオーバーヘッドの十分な量です、気泡のUDPカプセル化とトランスミッションのため。 IPv6インターネットSHOULDに接続したがっているノードは「切り札」オプションとしてTeredoサービスを利用するだけです: それら、SHOULDは、それが局所的に利用可能であるならダイレクトIPv6の接続性を使用するのを好みます、地方のNATで共同見つけられた6to4ルータでそれを提供するか、または構成されたトンネルサービスでそれを提供するなら。 それら、SHOULDは、彼らがグローバルなIPv4アドレスを使用できるならそれほど煩わしくない6to4カプセル化を使用するのを好みます。
3.2.2. Autonomous Deployment
3.2.2. 自動展開
In an IPv6-enabled network, the IPv6 service is configured automatically, by using mechanisms such as IPv6 Stateless Address Autoconfiguration [RFC2462] and Neighbor Discovery [RFC2461]. A design objective is to configure the Teredo service as automatically as possible. In practice, however, it is required that the client learn the IPv4 address of a server that is willing to serve the client; some servers may also require some form of access control.
IPv6によって可能にされたネットワークでは、IPv6サービスは自動的に構成されます、IPv6 Stateless Address Autoconfiguration[RFC2462]やNeighborディスカバリー[RFC2461]などのメカニズムを使用することによって。 設計目標はできるだけ自動的にTeredoサービスを構成することです。 しかしながら、実際には、クライアントがクライアントに役立っても構わないと思っているサーバのIPv4アドレスを学ぶのが必要です。 また、いくつかのサーバが何らかの形式のアクセスコントロールを必要とするかもしれません。
Huitema Standards Track [Page 8] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[8ページ]。
3.2.3. Minimal Load on Servers
3.2.3. サーバに関する最小量の負荷
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クライアントの間の交換のための目的地で選択されたリレーを通してこれらのパケットを交換しなければならないでしょう。
3.2.4. Automatic Sunset
3.2.4. 自動日没
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.
ノードに対するサービスをIPv6に供給するという特定の問題への短期的な解決がNATの後ろで場所を見つけられたので、船食虫は意味されます。 時間がたつにつれて「IPv4NAT」を「IPv6ルータ」に変えることによって問題が決議されると予想されます。 2つの方法の1つでこれができます: 6to4機能を提供するためにNATをアップグレードさせるか、NATによって使用されるインターネット接続をネイティブのIPv6サービスにアップグレードさせて、または次に、NATでIPv6ルータの機能性を加えます。 どちらの場合ではも、前のNATはIPv6ルータとしてそれの後ろのシステムに浮かぶことができます。 これらのシステムは「ルータ通知」を受け始めるでしょう。 彼らは、彼らにはIPv6の接続性があるのに気付いて、Teredoを使用するのを止めるでしょう。
3.3. Operational Requirements
3.3. 操作上の要件
3.3.1. Robustness Requirement
3.3.1. 丈夫さ要件
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の上まで運ばれます。 サーバは、状態がなくなるように設計されています(容易にそれらを模写できることを意味します)。 本当に、私たちは、複数のインターネット位置で模写されたそのような多くのサーバを見つけると予想します。
3.3.2. Minimal Support Cost
3.3.2. 最小量のサポート費用
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
この目的を満たすのは、TeredoアドレスがTeredoクライアントに連絡できるIPv4アドレスとUDPポートを組み込むのを含意します。 これは暗黙の限界を作成します。
Huitema Standards Track [Page 9] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[9ページ]。
stability of the Teredo addresses, which can only remain valid as long as the underlying IPv4 address and UDP port remain valid.
Teredoアドレスの安定性。(基本的なIPv4アドレスとUDPポートが有効なままで残っている限り、アドレスは有効なままで残ることができるだけです)。
3.3.3. Protection against Denial of Service Attacks
3.3.3. サービス不能攻撃に対する保護
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サーバを偽造して、不適当な情報をクライアントに送るサービス不能攻撃に対してサービスを保護しなければなりません。
3.3.4. Protection against Distributed Denial of Service Attacks
3.3.4. 分散DoS攻撃に対する保護
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.
船食虫リレーはIPv6パケットのためのリレーとして作用するでしょう。 攻撃を追跡不可能にして、彼らのアドレスを隠すのにサービス攻撃者の否定で不適切に設計されたパケットリレーは使用できます。 Teredoサービスはそのような誤用に対する適切な保護を含まなければなりません。
3.3.5. Compatibility with Ingress Filtering
3.3.5. イングレスフィルタリングとの互換性
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.
ルータはすなわち、与えられたインタフェースに受け取られたパケットのソースアドレスが「正統であること」をチェックすることによってフィルタリングが接頭語をネットワークでつなぐために属させるそれのトラフィックがネットワーク・インターフェースで予想されるイングレスを実行するかもしれません。 イングレスフィルタリングは推奨案です、著しくサービス不能攻撃の間、証拠を隠すために不正行為者ハッカーによる偽造ソースIPアドレスの使用を阻むとき。 Teredo仕様によって、ネットワークは、イングレスがフィルタリングであるとやむを得ず無効にしてはいけません。
3.4. Model of Operation
3.4. 操作のモデル
The operation of Teredo involves four types of nodes: Teredo clients, Teredo servers, Teredo relays, and "plain" IPv6 nodes.
Teredoの操作は4つのタイプのノードにかかわります: 船食虫クライアント、Teredoサーバ、Teredoリレー、および「明瞭な」IPv6ノード。
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サーバと対話することによって、操業を開始します。 この手順の間、クライアントは、円錐、制限された円錐、または左右対称のNATの後ろにそれがあるかを発見するでしょう。 クライアントが左右対称のNATの後ろに位置していないと、手順はうまくいくでしょう、そして、クライアントは「船食虫アドレス」を構成するでしょう。
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の後ろに位置していないなら、マッピングをNATにインストールする「気泡」の交換でレギュラーのIPv6パケットのトランスミッションに先行しなければなりません。 このドキュメントは直接路に沿ってトランスミッションを可能にするためにTeredoクライアントの間でどう気泡を交換できるかを指定します。
Huitema Standards Track [Page 10] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[10ページ]。
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リレーで明瞭なIPv6ノード(例えば、固有のノードか6to4ノード)とIPv6パケットを交換できます。 船食虫リレーはIPv6インターネットのある部分集合にTeredo接頭語の可到達性の広告を出します: ISPによってセットアップされたリレーはこのISPのIPv6顧客だけに通常役立つでしょう。 サイトのためのリレーセットアップはこのサイトのIPv6ホストに役立つだけでしょう。 デュアルスタックホストは「地方のリレー」を実装するかもしれません、彼らがTeredoホストと共にUDPとIPv4の上でTeredo IPv6アドレスの広告を出す必要はなくてパケットをIPv6に送ることによって直接伝達するのを許容して。
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.
船食虫クライアントはそれぞれのネイティブのIPv6か6to4同輩の最も近くにあるリレーを発見しなければなりません。 彼らはそれらと交信するそれぞれのネイティブのIPv6か6to4同輩のためにこの発見を実行しなければなりません。 だますのを防ぐために、TeredoクライアントはICMPエコー要求をネイティブのホストに送ることによって、リレー発見手順を実行します。 このメッセージは定期的にフォーマットされたIPv6 ICMPパケットです。(それは、TeredoサーバにUDPでカプセルに入れられて、クライアントによって送られます)。 サーバは、IPv6メッセージをdecapsulatesして、意図しているIPv6の目的地にそれを送ります。 エコー要求のペイロードは大きい乱数を含んでいます。 エコー・リプライを同輩はクライアントのIPv6アドレスに送って、標準のIPv6ルーティングメカニズムを通して送ります。それに自然にネイティブか6to4同輩の最も近くにTeredoリレーに届いて、Teredoメカニズムを使用しながら、このリレーで送るでしょう。Teredoクライアントは、リレーで使用されるIPv4アドレスとUDPポートがエコー・リプライを送ると発見して、このIPv4アドレスとポートに送られたUDPパケットでそれらをカプセル化することによって、一層のIPv6パケットを同輩に送るでしょう。 だますのを防ぐために、Teredoクライアントは、エコー・リプライのペイロードが適切な乱数を含むことを確かめます。
The procedures are designed so that the Teredo server only participates in the qualification procedure and in the exchange of bubbles and ICMP echo requests. The Teredo server never carries actual data traffic. There are two rationales for this design: reduce the load on the server in order to enable scaling, and avoid privacy issues that could occur if a Teredo server kept copies of the client's data packets.
手順は、Teredoサーバが資格手順と気泡とICMPエコー要求の交換に参加するだけであるように、設計されています。 Teredoサーバは実際のデータ通信量を決して運びません。 このデザインのための2つの原理があります: スケーリングを可能にするためにサーバで負荷を減少させてください、そして、Teredoサーバがクライアントのデータ・パケットの写しを取っておくなら起こることができるプライバシーの問題を避けてください。
4. Teredo Addresses
4. 船食虫アドレス
The Teredo addresses are composed of 5 components:
Teredoアドレスは5つのコンポーネントで構成されます:
+-------------+-------------+-------+------+-------------+ | Prefix | Server IPv4 | Flags | Port | Client IPv4 | +-------------+-------------+-------+------+-------------+
+-------------+-------------+-------+------+-------------+ | 接頭語| サーバIPv4| 旗| ポート| クライアントIPv4| +-------------+-------------+-------+------+-------------+
- Prefix: the 32-bit Teredo service prefix. - Server IPv4: the IPv4 address of a Teredo server.
- 以下を前に置いてください。 32ビットのTeredoサービス接頭語。 - サーバIPv4: TeredoサーバのIPv4アドレス。
Huitema Standards Track [Page 11] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[11ページ]。
- 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.
- 旗: 1セットのアドレスのタイプを記録する16ビットとNAT。 - ポート: 困惑させるのはクライアントで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ビットのポートナンバーの排他的論理和、および32ビットのアドレスの排他的論理和は16進価値の0xFFFFFFFFと共にこれができます。
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は、「2進の値000から始まるもの以外のすべてのユニキャストアドレスにおいて、Interface IDが長さ64ビットであり、Modified EUI-64形式で組み立てられるのに必要です。」と指定します。 これは旗のコード化を書き取ります、Modified EUI-64IDの最も重要な16ビットの有効値に対応するはずである中間的16ビット:
0 0 0 1
|0 7 8 5
+----+----+----+----+
|Czzz|zzUG|zzzz|zzzz|
+----+----+----+----+
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"は値「非グローバルなユニキャスト識別子を示す0インチ」に設定されるべきです。 - クライアントが、そうでなければ、円錐のNATの後ろに0にはそれがあると信じているなら、ビット「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.)
したがって、Flags分野の2つの現在指定された値があります: 「0×0000」 円錐のビットがあるなら、(すべてのヌル)は0にセットして、円錐のビットがあるなら、「0×8000」は1にセットしました。 (この仕様の今後のバージョンは新しい値を予約されたビットに割り当てるかもしれません。)
In some cases, Teredo nodes use link-local addresses. These addresses contain a link-local prefix (FE80::/64) and a 64-bit identifier, constructed using the same format as presented above. A difference between link-local addresses and global addresses is that the identifiers used in global addresses MUST include a global scope unicast IPv4 address, while the identifiers used in link-local addresses MAY include a private IPv4 address.
いくつかの場合、Teredoノードはリンクローカルのアドレスを使用します。 これらのアドレスはリンクローカルの接頭語(FE80: : /64)と上で提示されるのと同じ形式を使用することで構成された64ビットの識別子を含んでいます。 リンクローカルのアドレスとグローバルなアドレスの違いはグローバルなアドレスで使用される識別子がグローバルな範囲ユニキャストIPv4アドレスを含まなければならないということです、リンクローカルのアドレスで使用される識別子が個人的なIPv4アドレスを含むかもしれませんが。
Huitema Standards Track [Page 12] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[12ページ]。
5. Specification of Clients, Servers, and Relays
5. クライアント、サーバ、およびリレーの仕様
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パケットを待っています。 それは適切なアドレスとポートに応答を送ることによって、要求を処理します。 それは適切なIPv4アドレスとUDPポート、または、TeredoクライアントのネイティブのIPv6同輩にいくつかのTeredo IPv6パケットを送ります。 サーバの正確な働きはセクション5.3で指定されます。
The Teredo relay advertises reachability of the Teredo service prefix over IPv6. The scope of advertisement may be the entire Internet or a smaller subset such as an ISP network or an IPv6 site; it may even be as small as a single host in the case of "local relays". The relay forwards Teredo IPv6 packets to the appropriate IPv4 address and UDP port. The relay behavior is specified in Section 5.4.
TeredoリレーはIPv6の上にTeredoサービス接頭語の可到達性の広告を出します。 広告の範囲は、ISPネットワークかIPv6サイトなどの全体のインターネットか、より小さい部分集合であるかもしれません。 それは「地方のリレー」の場合で独身のホストと同じくらい小さくさえあるかもしれません。 リレーは適切なIPv4アドレスとUDPポートへのパケットをTeredo IPv6に送ります。 リレーの振舞いはセクション5.4で指定されます。
Teredo clients, servers, and relays must implement the sunset procedure defined in Section 5.5.
船食虫クライアント、サーバ、およびリレーはセクション5.5で定義された日没の手順を実装しなければなりません。
5.1. Message Formats
5.1. メッセージ・フォーマット
5.1.1. Teredo IPv6 Packet Encapsulation
5.1.1. 船食虫IPv6パケットカプセル化
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.
船食虫IPv6パケットはUDPパケット[RFC768]としてIPv4[RFC791]の中で伝えられます。 ソース、送付先IPアドレス、およびUDPポートはこのセクションで指定される値を取ります。 パケットは発生源指示で2つの形式、簡単なカプセル化、およびカプセル化の1つに入ることができます。
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 | +------+-----+-------------+
+------+-----+-------------+ | IPv4| UDP| IPv6パケット| +------+-----+-------------+
When relaying some packets received from third parties, the server may insert an origin indication in the first bytes of the UDP payload:
第三者から受け取られたいくつかのパケットをリレーするとき、サーバはUDPペイロードの最初のバイトに発生源指示を挿入するかもしれません:
Huitema Standards Track [Page 13] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[13ページ]。
+------+-----+-------------------+-------------+ | IPv4 | UDP | Origin indication | IPv6 packet | +------+-----+-------------------+-------------+
+------+-----+-------------------+-------------+ | IPv4| UDP| 発生源指示| IPv6パケット| +------+-----+-------------------+-------------+
The origin indication encapsulation is an 8-octet element, with the following content:
発生源指示カプセル化は以下の内容がある8八重奏の要素です:
+--------+--------+-----------------+ | 0x00 | 0x00 | Origin port # | +--------+--------+-----------------+ | Origin IPv4 address | +-----------------------------------+
+--------+--------+-----------------+ | 0×00| 0×00| 発生源ポート#| +--------+--------+-----------------+ | 発生源IPv4アドレス| +-----------------------------------+
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ビットのポートナンバーの排他的論理和、および32ビットのアドレスの排他的論理和は16進価値の0xFFFFFFFFと共にこれができます。
For example, if the original UDP port number was 337 (hexadecimal 0151) and original IPv4 address was 1.2.3.4 (hexadecimal 01020304), the origin indication would contain the value "0000FEAEFEFDFCFB".
例えば、元のUDPポートナンバーが337(16進0151)とオリジナルのIPv4であったなら、アドレスはそうでした。1.2 .3 .4(16進01020304)、発生源指示は値の"0000FEAEFEFDFCFB"を含んでいるでしょう。
When exchanging Router Solicitation (RS) and Router Advertisement (RA) messages between a client and its server, the packets may include an authentication parameter:
クライアントとそのサーバの間でRouter Solicitation(RS)とRouter Advertisement(RA)メッセージを交換するとき、パケットは認証パラメタを含むかもしれません:
+------+-----+----------------+-------------+ | IPv4 | UDP | Authentication | IPv6 packet | +------+-----+----------------+-------------+
+------+-----+----------------+-------------+ | IPv4| UDP| 認証| IPv6パケット| +------+-----+----------------+-------------+
The authentication encapsulation is a variable-length element, containing a client identifier, an authentication value, a nonce value, and a confirmation byte.
認証カプセル化は可変長の要素です、クライアント識別子、認証値、一回だけの値、および確認バイトを含んでいて。
Huitema Standards Track [Page 14] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[14ページ]。
+--------+--------+--------+--------+ | 0x00 | 0x01 | ID-len | AU-len | +--------+--------+--------+--------+ | Client identifier (ID-len | +-----------------+-----------------+ | octets) | Authentication | +-----------------+--------+--------+ | value (AU-len octets) | Nonce | +--------------------------+--------+ | value (8 octets) | +--------------------------+--------+ | | Conf. | +--------------------------+--------+
+--------+--------+--------+--------+ | 0×00| 0×01| ID-len| Au-len| +--------+--------+--------+--------+ | Client identifier (ID-len | +-----------------+-----------------+ | octets) | 認証| +-----------------+--------+--------+ | 値(AU-len八重奏)| 一回だけ| +--------------------------+--------+ | 値(8つの八重奏)| +--------------------------+--------+ | | 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八重奏の一回だけ、および確認バイトは認証値のあとに続いています。
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の両方がヌル値に用意ができることができます。
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 | +------+-----+----------------+--------+-------------+
+------+-----+----------------+--------+-------------+ | IPv4| UDP| 認証| 発生源| IPv6パケット| +------+-----+----------------+--------+-------------+
5.1.2. Maximum Transmission Unit
5.1.2. マキシマム・トランスミッション・ユニット
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パケットがインターネットの上の予測できない経路を移動できるので、このMTUを小型に含むのは最も良いです、IPv4パケット断片化の効果を最小にして、再アセンブリするように。 デフォルトリンクMTUは、MTUがTeredoサーバから供給したホスト、およびリンクのそばで通常、ルータ通知SHOULDの間最低1280バイトのIPv6 MTUサイズに設定される[RFC2460]ように仮定しました。
Huitema Standards Track [Page 15] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[15ページ]。
Teredo implementations SHOULD NOT set the Don't Fragment (DF) bit of the encapsulating IPv4 header.
船食虫実装SHOULD NOTはどんなFragment(DF)も噛み付かなかった要約のIPv4ヘッダーのドンを設定します。
5.2. Teredo Client Specification
5.2. 船食虫クライアント仕様
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が扱う、aサーバ--そのサーバのセカンダリ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.
- 船食虫IPv6が前に置くTeredoサービスポートに関連している船食虫接続性状態(Teredoサービスポートに関連している写像しているアドレスとポートナンバー)(船食虫IPv6アドレスか接頭語から得られたアドレス)はローカルアドレスをリンクします--Teredoサーバとの最後の相互作用の日時(船食虫Refresh Interval)はRefresh Intervalをランダマイズしました--最近のTeredo同輩のリスト。
Before sending any packets, the client must perform the Teredo qualification procedure, which determines the Teredo connectivity status, the mapped address and port number, and the Teredo IPv6 prefix. It should then perform the cone NAT determination procedure, which determines the cone NAT status and may alter the value of the prefix. If the qualification is successful, the client may use the Teredo service port to transmit and receive IPv6 packets, according to the transmission and reception procedures. These procedures use the "list of recent peers". For each peer, the list contains:
どんなパケットも送る前に、クライアントはTeredo資格手順とTeredo IPv6接頭語を実行しなければなりません。(手順はTeredo接続性状態、写像しているアドレス、およびポートナンバーを測定します)。 それは、次に、円錐のNAT決断手順を実行するべきであり、接頭語の値を変更するかもしれません。(手順は円錐のNAT状態を決定します)。 資格がうまくいくなら、クライアントはIPv6パケットを送受信するのにTeredoサービスポートを使用するかもしれません、トランスミッションとレセプション手順によると。 これらの手順は「最近の同輩のリスト」を使用します。 各同輩に関しては、リストは以下を含んでいます。
Huitema Standards Track [Page 16] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[16ページ]。
- 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ポート--写像しているすなわち、信じられたアドレスの状態--最後の一回だけの値は同輩--同輩からの前回のレセプションの日時--最後のトランスミッションの日時まで同輩に発信しました--同輩に伝えられた気泡の数。
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サーバとの最後の相互作用以来この手順を用いる必要性が遅れによる、リフレッシュ、手順がパラメタとしてみなす、「船食虫は間隔をリフレッシュします」。 このパラメタは初めは、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が「ヘアピン」ルーティングができないと、接続性は高められるでしょう、すなわち、別の内部のホストの写像しているアドレスと1人の内部のホストからポートに送られたパケットは向け直すことができません。
5.2.1. Qualification Procedure
5.2.1. 資格手順
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クライアント接頭語を決定することです。 サービスが「初期」の状態にあるとき、手順は始まります、そして、失敗しているなら、それはうまくいく、および「オフライン」の状態の「適切な」状態をもたらします。
Huitema Standards Track [Page 17] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[17ページ]。
/---------\
| 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
/---------\ | 初期| \---------/ | +----+----------+ | ConeBit=1を設定してください。| +----+----------+ | + <。-------------------------------------------+ | | +----+----+ | | 始め| <、-、-、-、-、--+ | +----+----+ | +----------+----+ | | | ConeBit=0を設定してください。| v| +----------+----+ /---------\タイマ| N^|始まります。|-------+ 試み/----------------\はい| \---------/----------------->| ConeBit=1?|---+ | 応答、\----------------/ | | V Vがありません/。---------------\はい/----------\ | ConeBit=1? |-----+ | オフライン| \---------------/ | \----------/ノー| v| /----------\ | | 円錐のNAT| +-----+-----+ \----------/ | 新しいサーバ| +-----+-----+ | +----+----+ | 始め| <、-、-、-、-、--+ +----+----+ | | | v| /---------\タイマ| |始まります。|-------+ N試み/----------\ \---------/------------------->| オフライン| | 応答、\----------/ | V
Huitema Standards Track [Page 18] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[18ページ]。
/------------\ No /---------------\
| Same port? |-------->| Symmetric NAT |
\------------/ \---------------/
| Yes
V
/----------------------\
| Restricted Cone NAT |
\----------------------/
/------------\は/ではありません。---------------\ | 同じポート? |、-、-、-、-、-、-、--、>| 左右対称のNAT| \------------/ \---------------/ | /に対してはい----------------------\ | 制限された円錐の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".
インタフェースが初期化されるとき、システムは最初にRouter Solicitationメッセージを送ることによって、「スタート動作」を実行します、[RFC2461]で定義されるように。 クライアントは、リンクローカルアドレスを選んで、メッセージのIPv6源としてそれを使用します。 アドレスの円錐のビットは1に設定されます(アドレス形式に関してセクション4を見てください)。 RSのIPv6の目的地はオールルータマルチキャストアドレスです。 TeredoサーバのサービスポートからIPv4アドレスとTeredo UDPポートまでUDPの上にパケットを送るでしょう。 接続性状態はその時、「始め」に移行します。
In the starting state, the client waits for a router advertisement from the Teredo server. If no response comes within a time-out T, the client should repeat the start action, by resending the Router Solicitation message. If no response has arrived after N repetitions, the client concludes that it is not behind a cone NAT. It sets the cone bit to 0, and repeats the procedure. If after N other timer expirations and retransmissions there is still no response, the client concludes that it cannot use UDP, and that the Teredo service is not available; the status is set to "Off-line". In accordance with [RFC2461], the default time-out value is set to T=4 seconds, and the maximum number of repetitions is set to N=3.
始めの状態では、クライアントはTeredoサーバからのルータ通知を待ちます。どんな応答もタイムアウトTに含まれないなら、クライアントはスタート動作を繰り返すべきです、Router Solicitationメッセージを再送することによって。 応答が全くN反復の後に到着していないなら、クライアントは、円錐のNATの後ろにそれがないと結論を下します。 それは、円錐のビットを0に設定して、手順を繰り返します。 応答が全くN他のタイマ満期と「再-トランスミッション」の後にまだなければ、クライアントはUDPを使用できないで、Teredoサービスが利用可能でないと結論を下します。 状態は「オフライン」に設定されます。 [RFC2461]に従って、デフォルトタイムアウト価値はT=4秒に設定されます、そして、反復の最大数はN=3に設定されます。
If a response arrives, the client checks that the response contains an origin indication and a valid router advertisement as defined in [RFC2461], that the IPv6 destination address is equal to the link- local address used in the router solicitation, and that the router advertisement contains exactly one advertised Prefix Information option. This prefix should be a valid Teredo IPv6 server prefix: the first 32 bits should contain the global Teredo IPv6 service prefix, and the next 32 bits should contain the server's IPv4 address. If this is the case, the client learns the Teredo mapped address and Teredo mapped port from the origin indication. The IPv6 source address of the Router Advertisement is a link-local server address of the Teredo server. (Responses that are not valid advertisements are simply discarded.)
応答が到着するなら、クライアントは、応答が[RFC2461]で定義されるように発生源指示と有効なルータ通知を含んでいて、IPv6送付先アドレスがルータ懇願に使用されるリンクローカルアドレスと等しく、ルータ通知がまさに1つの広告を出しているPrefix情報オプションを含むのをチェックします。 この接頭語は有効なTeredo IPv6サーバ接頭語であるべきです: 最初の32ビットはグローバルなTeredo IPv6サービス接頭語を含むはずです、そして、次の32ビットはサーバのIPv4アドレスを含むはずです。 これがそうであるなら、クライアントは、Teredoがアドレスを写像して、Teredoが発生源指示からポートを写像したことを学びます。 Router AdvertisementのIPv6ソースアドレスはTeredoサーバのリンクローカルサーバアドレスです。(有効な広告でない応答は単に捨てられます。)
Huitema Standards Track [Page 19] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[19ページ]。
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.)
クライアントがIPv6目的地アドレスセットでRAを1に円錐のビットで受け取ったなら、それは、円錐のNATの後ろにあって、完全に資格があります。 0に設定された円錐のビットでRAを受け取るなら、クライアントは、地方のNATが制限されているか、または左右対称であるかを知りません。 クライアントは、セカンダリIPv4サーバアドレスを選択して、手順、値ゼロのままで残っている円錐のビットを繰り返します。 クライアントが応答を受けないなら、それはそれを検出します。サービスは使用可能ではありません。 クライアントが応答を受けるなら、それは最初の容認された値へのこの2番目の応答で写像しているアドレスと写像しているポートを比較します。 値が異なるなら、クライアントは左右対称のNATを検出します: それはTeredoサービスを利用できません。 値が同じであるなら、クライアントはポートで制限されたか制限された円錐のNATを検出します: クライアントがサービスを利用するのに資格があります。 (船食虫は制限されてポートで制限された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サーバ接頭語と発生源指示から学習されたUDPポートとIPv4アドレスの困惑させられた値を使用することでTeredo IPv6アドレスを造ります。 円錐のビットはそうでなければ、クライアントが円錐のNAT、0の後ろにいるならRA、すなわち、1を受け取るのに使用される値に設定されるべきです。 クライアントは、Teredoサービスを利用し始めることができます。
5.2.2. Secure Qualification
5.2.2. 安全な資格
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.
クライアントは機密保護している資格を実行しなければならないかもしれません。 ルータ懇願メッセージを伝えながら、認証カプセル化をUDPパケットに取り入れるでしょう、そして、クライアントはまさにセクション5.2.1で説明されたアルゴリズムを実行するでしょうが、それは送付者によって提供されたルータ通知を運ぶUDPメッセージでの有効な認証パラメタの存在について確かめるでしょう。
In these packets, the nonce value is chosen by the client, and is repeated in the response from the server; the client identifier is a value with which the client was configured.
これらのパケットでは、一回だけの値は、クライアントによって選ばれていて、サーバから応答で繰り返されます。 クライアント識別子はクライアントが構成された値です。
A first level of protection is provided by just checking that the value of the nonce in the response matches the value initially sent by the client. If they don't match, the packet MUST be discarded. If no other protection is used, the authentication payload does not contain any identifier or authentication field; the ID-len and AU-len fields are set to a null value. When stronger protection is required, the authentication payload contains the identifier and location fields, as explained in the following paragraphs.
応答における、一回だけの値が初めはクライアントによって送られた値に合っているのをただチェックすることによって、最初のレベルの保護を提供します。 彼らが合っていないなら、パケットを捨てなければなりません。 他のどんな保護も使用されていないなら、認証ペイロードはどんな識別子や認証分野も含んでいません。 ID-lenとAU-len分野はヌル値に用意ができています。 より強い保護が必要であるときに、認証ペイロードは以下のパラグラフで説明されるように識別子と位置の分野を含んでいます。
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に設定されます。 サーバによって返されたヌル値は、クライアントのキーがまだ有効であることを示します。 非ヌル値は、クライアントが新しいキーを入手するべきであるのを示します。
Huitema Standards Track [Page 20] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[20ページ]。
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.
- 一回だけの値--確認バイト--それは存在しています--IPv6パケットでの発生源指示カプセル化
The HMAC procedure is applied to the concatenation of these four components, without any additional padding.
HMAC手順は少しも追加詰め物なしでこれらの4つのコンポーネントの連結に適用されます。
5.2.3. Packet Reception
5.2.3. パケットレセプション
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.
Teredoサービスポートの上にUDPパケットを受け取るとき、Teredoクライアントはセクション5.1.1で定義されたパケット符号化規則によってそれがコード化されて、ことによると有効な認証カプセル化によって保護された有効な発生源指示カプセル化と有効なIPv6パケットの有効なIPv6パケットか組み合わせのどちらかを含むのをチェックします。 これがそうでないなら、パケットは静かに捨てられます。
Huitema Standards Track [Page 21] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[21ページ]。
An IPv6 packet is deemed valid if it conforms to [RFC2460]: the protocol identifier should indicate an IPv6 packet and the payload length should be consistent with the length of the UDP datagram in which the packet is encapsulated. In addition, the client should check that the IPv6 destination address correspond to its own Teredo address.
[RFC2460]に従うなら、IPv6パケットは有効であると考えられます: プロトコル識別子は、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データが同輩エントリーに保存された一回だけに合っているなら、パケットを受け入れるべきです。 エントリーの状態は「信じられること」に変わるべきです、そして、エントリーにおける写像している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
3) ソースIPv6アドレスがTeredoアドレスであるなら、クライアントはソースアドレスで写像しているIPv4アドレスと写像しているポートをパケットのソースIPv4アドレスとソースポートにたとえます。 値が合っているなら、クライアントは同輩のリストのIPv6ソースアドレスのための同輩エントリーを作成しなければなりません。 1つが既に存在しているなら、それはエントリーをアップデートするでしょうに。 エントリーにおける写像しているIPv4アドレスと写像しているポートはパケットが受け取られた値に設定されるべきです、そして、状態は「信じられること」に設定されるべきです。 新しいエントリーが作成されるなら、最後のトランスミッション日付は現在の日の30秒前、およびゼロへの気泡の数に決められます。 パケットがaであるなら
Huitema Standards Track [Page 22] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[22ページ]。
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.
泡立ってください、そして、それはこの後処理しながら、捨てられるべきです。 さもなければ、パケットを受け入れるべきです。 すべての場合では、クライアントは、その目的地へ列に並ばせられたどんなパケットも、デキューして、進めなければなりません。
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ディスカバリーAddressであり、ソースアドレスが有効なTeredoアドレスであり、送付先アドレスが「リンクの上のすべてのノード」マルチキャストアドレスであるなら、パケットは地方の発見気泡として扱われるべきです。 どんな地方のエントリーもソースアドレスのために既に存在しなかったなら、新しいものは作成されますが、状態は「信じられないこと」に設定されます。 クライアントSHOULDは地方の発見気泡のソースIPv4アドレスとソースポートに送られたユニキャストTeredo気泡で返答します。 気泡のIPv6ソースアドレスはローカルのTeredo IPv6アドレスに設定されるでしょう。 気泡のIPv6送付先アドレスは地方の発見気泡のIPv6ソースアドレスに設定されるべきです。 (任意のローカルの発見手順を実装しないクライアントが地方の発見気泡を処理しないでしょう。)
5) If the source IPv6 address is a Teredo address, and the mapped IPv4 address and mapped port in the source address do not match the source IPv4 address and source port of the packet, the client checks whether there is an existing "local" entry for that IPv6 address. If there is such an entry, and if the local IPv4 address and local port indicated in that entry match the source IPv4 address and source
5) ソースIPv6アドレスがTeredoアドレスであり、ソースアドレスの写像しているIPv4アドレスと写像しているポートがパケットのソースIPv4アドレスとソースポートに合っていないなら、クライアントは、そのIPv6アドレスのための既存の「地方」のエントリーがあるかどうかチェックします。 そのようなエントリー、そのエントリーで示されたローカルのIPv4アドレスと地方のポートがソースIPv4アドレスに合うか、そして、およびソースがあれば
port of the packet, the client updates the "local" entry, whose status should be set to "trusted". If the packet is a bubble, it should be discarded after this processing; otherwise, the packet should be accepted. In all cases, the client must de-queue and forward any packet queued for that destination.
パケットのポート、「地方」のエントリー、状態が「信じられること」に設定されるべきであるクライアントアップデート。 パケットが気泡であるなら、この後処理しながら、捨てられるべきです。 さもなければ、パケットを受け入れるべきです。 すべての場合では、クライアントは、その目的地へ列に並ばせられたどんなパケットも、デキューして、進めなければなりません。
6) In the other cases, the packet may be accepted, but the client should be conscious that the source address may be spoofed; before processing the packet, the client should perform the "direct IPv6 connectivity test" described in Section 5.2.9.
6) 他の場合では、パケットを受け入れるかもしれませんが、クライアントはソースアドレスが偽造されるかもしれないのを意識があるべきです。 パケットを処理する前に、クライアントはセクション5.2.9で説明された「ダイレクトIPv6接続性テスト」を実行するべきです。
Whatever the IPv4 source address and UDP source port, the client that receives an IPv6 packet MAY send a Teredo bubble towards that target, as specified in Section 5.2.6.
IPv4ソースアドレスとUDPソースポートが何であっても、IPv6パケットを受けるクライアントはその目標に向かってTeredo気泡を送ります、セクション5.2.6で指定されるように。
5.2.4. Packet Transmission
5.2.4. パケット伝送
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
TeredoクライアントがTeredoインタフェースの上にパケットを伝えなければならないとき、それは送付先IPv6アドレスを調べます。 クライアントは最初に、最近のTeredo同輩のリストでこのIPv6アドレスのためのエントリーがあって、エントリーがまだ有効であるかどうかチェックします: 地元の同輩に関連しているエントリーは前回のレセプションがデートするか、そして、その30秒のそれに関連づけられて、リストエントリーが、より少ない時代に有効です。
Huitema Standards Track [Page 23] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[23ページ]。
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.)
現在の時間。 現在の時間からその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アドレスのためのエントリーがあって、「信じられること」にエントリーの状態を設定するなら、エントリーで指定されたIPv4アドレスとUDPポートへのUDPの上にIPv6パケットを送るべきです。 クライアントは同輩エントリーにおける、最後のトランスミッションの日付をアップデートします。
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) 目的地が地元の同輩(すなわち、地方の発見気泡が最後の600秒で受け取られたTeredoアドレス)のTeredo IPv6アドレスであるなら、パケットは列に並ばせられます。 クライアントは、エントリーで指定されたローカルのIPv4アドレスと地方のポートにユニキャストTeredo気泡を発信させて、地方のTeredo気泡をTeredo 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アドレスであるなら、パケットはそのIPv6アドレスから抜粋された写像しているIPv4アドレスと写像しているUDPポートへの移動している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アドレスであるなら、パケットは列に並ばせられます。 クライアントが円錐のNATの後ろに位置していないなら、ダイレクト気泡をTeredoの目的地に送ります、すなわち、目的地の写像しているIPアドレスと写像しているポートに。 すべての場合では、クライアントは間接的な気泡をTeredoの目的地に送ります、サーバアドレスと、そして、TeredoポートへのUDPの上にそれを送って。 クライアントが直接このTeredo同輩から気泡か別のパケットを受けるとき、パケットをデキューして、進めるでしょう。 2秒のタイムアウトの中に気泡を全く受け取らないなら、気泡トランスミッションを3回まで繰り返すべきです。
In cases 4 and 5, before sending a packet over UDP, the client MUST check that the IPv4 destination address is in the format of a global unicast address; if this is not the case, the packet MUST be silently
場合4と5では、UDPの上にパケットを送る前に、クライアントは、グローバルなユニキャストアドレスの形式にはIPv4送付先アドレスがあるのをチェックしなければなりません。 これがそうでないなら、パケットは静かにそうであるに違いありません。
Huitema Standards Track [Page 24] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[24ページ]。
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.)
捨てられる。 (ローカルの発見手順の結果、場合1で非グローバルなユニキャストアドレスに合法的にパケットを送ることができることに注意してください。)
The global unicast address check is designed to thwart a number of possible attacks in which an attacker tries to use a Teredo host to attack either a single local IPv4 target or a set of such targets. For the purpose of this specification, and IPv4 address is deemed to be a global unicast address if it does not belong to or match:
グローバルなユニキャストアドレス検査は、攻撃者がただ一つのローカルのIPv4目標か1セットの目標のどちらかをそのような攻撃するのにTeredoホストを使用しようとする多くの可能な攻撃を阻むように設計されています。 アドレスが考えられるこの仕様、およびIPv4の目的には、以下を属さないか、または合わせないなら、グローバルなユニキャストアドレスになってください。
- the "local" subnet 0.0.0.0/8,
- the "loopback" subnet 127.0.0.0/8,
- the local addressing ranges 10.0.0.0/8,
- the local addressing ranges 172.16.0.0/12,
- the local addressing ranges 192.168.0.0/16,
- the link local block 169.254.0.0/16,
- the block reserved for 6to4 anycast addresses 192.88.99.0/24,
- the multicast address block 224.0.0.0/4,
- the "limited broadcast" destination address 255.255.255.255,
- the directed broadcast addresses corresponding to the subnets to
which the host is attached.
- .0/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--「有限な放送」送付先アドレスのために予約した「地方」のサブネット0.0.0、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の後ろに位置するかのようにすべてのTeredo同輩を扱ってください。」を実行してください。 これは、トラフィックの何らかの増加をもたらしますが、NAT状態の決断がある理由で誤ったなら、信頼性の問題を避けるかもしれません。 また、同じ理由から、クライアントは、場合5でダイレクト気泡をいつも送ると決めるかもしれません、彼らが、非円錐のNATの後ろに位置していると信じないでも。
5.2.5. Maintenance
5.2.5. メインテナンス
The Teredo client must ensure that the mappings that it uses remain valid. It does so by checking that packets are regularly received from the Teredo server.
Teredoクライアントは、それが使用するマッピングが有効なままで残っているのを保証しなければなりません。 パケットがTeredoサーバから定期的に受け取られるのをチェックすることによって、それはそうします。
At regular intervals, the client MUST check the "date and time of the last interaction with the Teredo server" to ensure that at least one packet has been received in the last Randomized Teredo Refresh Interval. If this is not the case, the client SHOULD send a router solicitation message to the server, as specified in Section 5.2.1; the client should use the same value of the cone bit that resulted in the reception of an RA during the qualification procedure.
一定の間隔を置いて、クライアントは、少なくとも1つのパケットが最後のRandomized Teredo Refresh Intervalに受け取られたのを保証するために「Teredoサーバとの最後の相互作用の日時」をチェックしなければなりません。 これがそうでないなら、クライアントSHOULDはルータ懇願メッセージをサーバに送ります、セクション5.2.1で指定されるように。 クライアントは資格手順の間にRAのレセプションをもたらした円錐のビットの同じ価値を使用するべきです。
Huitema Standards Track [Page 25] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[25ページ]。
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.
ルータ通知が受け取られているとき、クライアントSHOULDはセクション5.2.1における指定されるとしての正当性をチェックします。 無効の広告は静かに捨てられます。 広告が有効であるなら、クライアントは、写像しているアドレスとポートが現在のTeredoアドレスに一致しているのをチェックしなければなりません。 これがそうでないなら、マッピングは変化しました。 クライアントは、旧住所が無効であるとマークして、新しいアドレスを使用し始めなければなりません。
5.2.6. Sending Teredo Bubbles
5.2.6. 送付船食虫気泡
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クライアントはパケットレセプションの後か別のTeredoクライアントか、トランスミッション試みの後に気泡を送らなければならないかもしれません、セクション5.2.3と5.2で.4に説明されるように 2種類の気泡があります: 気泡と間接的な気泡を指示してください。(気泡は直接同輩の写像しているIPv4アドレスと写像しているUDPポートに送られます)。(気泡は同輩のTeredoサーバを通して送られます)。
When a Teredo client attempts to send a direct bubble, it extracts the mapped IPv4 address and mapped UDP port from the Teredo IPv6 address of the target. It then checks whether there is already an entry for this IPv6 address in the current list of peers. If there is no entry, the client MUST create a new list entry for the address, setting the last reception date and the last transmission date to 30 seconds before the current date, and the number of bubbles to zero.
Teredoクライアントが、ダイレクト気泡を送るのを試みるとき、それは目標のTeredo IPv6アドレスから写像しているIPv4アドレスと写像しているUDPポートを抜粋します。 そして、それは、同輩の現在のリストにはこのIPv6アドレスのためのエントリーが既にあるかをチェックします。 エントリーが全くなければ、クライアントはアドレス(最後のレセプション日付と最後のトランスミッションが現在の期日、および気泡の数の30秒前にゼロにさかのぼる設定)のための新しいリストエントリーを作成しなければなりません。
When a Teredo client attempts to send an indirect bubble, it extracts the Teredo server IPv4 address from the Teredo prefix of the IPv6 address of the target (different clients may be using different servers); the bubble will be sent to that IPv4 address and the Teredo UDP port.
Teredoクライアントが、間接的な気泡を送るのを試みるとき、目標のIPv6アドレスのTeredo接頭語からTeredoサーバIPv4アドレスを抜粋します(異なったクライアントは異なったサーバを使用しているかもしれません)。 そのIPv4アドレスとTeredo UDPポートに気泡を送るでしょう。
Bubbles may be lost in transit, and it is reasonable to enhance the reliability of the Teredo service by allowing multiple transmissions; however, bubbles will also be lost systematically in certain NAT configurations. In order to strike a balance between reliability and unnecessary retransmissions, we specify the following:
気泡はトランジットで失われるかもしれません、そして、複駆動動力伝達装置を許容することによってTeredoサービスの信頼性を高めるのは妥当です。 しかしながら、また、気泡はあるNAT構成で系統的に失われるでしょう。 信頼性と不要な「再-トランスミッション」の間のバランスをとるために、私たちは以下を指定します:
- The client MUST NOT send a bubble if the last transmission date
and time is less than 2 seconds before the current date and time;
- クライアントは最後のトランスミッション日時が現在の日時の2秒未満前であるなら気泡を送ってはいけません。
- The client MUST NOT send a bubble if it has already sent 4 bubbles
to the peer in the last 300 seconds without receiving a direct
response.
- それが既に最後の300秒に直接的な反応を受けないで同輩への4つの気泡を送ったなら、クライアントは気泡を送ってはいけません。
In the other cases, the client MAY proceed with the transmission of the bubble. When transmitting the bubble, the client MUST update the last transmission date and time to that peer, and must also increment the number of transmitted bubbles.
他の場合では、クライアントは気泡のトランスミッションを続けるかもしれません。 気泡を伝えるとき、クライアントは、最後のトランスミッション日時にその同輩にアップデートしなければならなくて、また、伝えられた気泡の数を増加しなければなりません。
Huitema Standards Track [Page 26] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[26ページ]。
5.2.7. Optional Refresh Interval Determination Procedure
5.2.7. 任意である、間隔決断手順をリフレッシュしてください。
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のセカンダリポートの写像しているアドレスとポートナンバー--セカンダリIPv6が前に置く船食虫はセカンダリポートの上でセカンダリポート--この接頭語から得られた船食虫のセカンダリIPv6アドレス--最後の相互作用の日時と交際しました--最大のTeredo Refresh Interval。 - 候補船食虫は間隔をリフレッシュします。
The secondary connectivity status, mapped address and prefix are determined by running the qualification procedure on the secondary port. When the client uses the interval determination procedure, the qualification procedure MUST be run for the secondary port immediately after running it on the service port. If the secondary qualification fails, the interval determination procedure will not be used, and the interval value will remain to the default value, 30 seconds. If the secondary qualification succeeds, the maximum refresh interval is set to 120 seconds, and the candidate Teredo refresh interval is set to 60 seconds, i.e., twice the Teredo refresh interval. The procedure is then performed at regular intervals, until it concludes:
セカンダリ接続性状態、写像しているアドレス、および接頭語は、資格手順をセカンダリポートに実行することによって、決定します。 クライアントが間隔決断手順を用いるとき、資格手順はサービスポートにそれを実行する直後セカンダリポートのための走行でなければなりません。 セカンダリ資格が失敗すると、間隔決断手順は用いられないでしょう、そして、間隔値はデフォルト値(30秒)のままで残るでしょう。 セカンダリ資格が成功するなら、最大はリフレッシュします。間隔による設定されて、120秒、およびTeredoがリフレッシュする候補にとって、間隔が60秒までセットである、すなわち、Teredoの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のセカンダリ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が候補値に間隔をリフレッシュして、新しさが間隔、または平均をリフレッシュする二度の最小限にa新しい候補価値を設定する、間隔をリフレッシュしてください。そうすれば、最大は間隔をリフレッシュします。
Huitema Standards Track [Page 27] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[27ページ]。
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.
間隔決断手順よりいかなる他の目的にもセカンダリポートを使用してはいけません。 手順が終わるとき、それは閉じられるべきです。
5.2.8. Optional Local Client Discovery Procedure
5.2.8. 任意のローカルのクライアント発見手順
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.
同じNATの後ろに位置しているTeredoクライアントのダイレクトコミュニケーションを可能にするのは望ましいです、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:
SHOULDがTeredo IPv4ディスカバリーAddressによって特定されたIPv4マルチキャストグループに加わるという地方の発見を可能にしたがっているTeredoクライアント。 クライアントSHOULDは、発見気泡がTeredo IPv4ディスカバリーAddressに受け取られるのを待っています。 クライアントSHOULDは無作為に地方の発見気泡をTeredo IPv4ディスカバリーAddressに間隔、一様に分散している200〜300秒送ります。 地方のTeredo気泡には、以下の特性があります:
- IPv4 source address: the IPv4 address of the sender
- IPv4ソースアドレス: IPv4送信者のアドレス
- IPv4 destination address: the Teredo IPv4 Discovery Address
- IPv4送付先アドレス: 船食虫IPv4発見アドレス
- IPv4 ttl: 1
- IPv4 ttl: 1
- UDP source port: the Teredo service port of the sender
- UDPソースポート: 送付者のTeredoサービスポート
- UDP destination port: the Teredo UDP port
- UDP仕向港: Teredo UDPポート
- UDP payload: a minimal IPv6 packet, as follows
- UDPペイロード: 以下の最小量のIPv6パケット
- IPv6 source: the global Teredo IPv6 address of the sender
- IPv6ソース: グローバルなTeredo IPv6送信者のアドレス
- IPv6 destination: the all-nodes on-link multicast address
- IPv6の目的地: リンクに関するオールノードマルチキャストアドレス
Huitema Standards Track [Page 28] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[28ページ]。
- 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ディスカバリーAddressの「リンク専用」マルチキャスト範囲によっても緩和されます。(Addressは、このアドレスに送られたパケットがルータの向こう側に進められないのを含意します)。
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".
気泡を受け入れるなら、クライアントは、気泡のソースIPv6アドレスに関連している写像しているIPv4アドレスと写像しているUDPポートに文通する最近の同輩のリストにはエントリーがあるかをチェックします。 そのようなエントリーがあれば、クライアントは、気泡のIPv4ソースアドレスとUDPソースポートを反映するためにローカルの同輩アドレスとローカルの同輩ポートパラメタをアップデートしなければなりません。 エントリーが全くなければ、クライアントは1つを作成しなければなりません、ローカルの同輩アドレスとローカルの同輩ポートパラメタに気泡の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における指定されるとしてのユニキャスト気泡で返答します。
5.2.9. Direct IPv6 Connectivity Test
5.2.9. ダイレクトIPv6接続性テスト
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
Teredo手順は、TeredoホストとTeredoリレーとのダイレクト接続を可能にするように設計されています。 円錐のNATの後ろに位置する船食虫ホストは直接リレーからパケットを受けるでしょう。 他のTeredoホストはローカルのTeredoサーバを通して第三者のオリジナルのアドレスとUDPポートを学ぶでしょう。これらの場合には、全部で、ソースのIPv6アドレスが偽造されるリスクがあります。
Huitema Standards Track [Page 29] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[29ページ]。
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
意地の悪いパーティーで。 船食虫ホストが2つの決定をしなければならなくて、ローカル処理のためにパケットを受け入れるかどうかと、伝わるかどうかが通じてIPv6アドレスにパケットを促進する、新たに。
learned IPv4 address and UDP port. The basic rule is that the hosts should be generous in what they accept and careful in what they send. Refusing to accept packets due to spoofing concerns would compromise connectivity and should only be done when there is a near certainty that the source address is spoofed. On the other hand, sending packets to the wrong address should be avoided.
学術的IPv4アドレスとUDPポート。 基本的な規則はホストが彼らが受け入れるもので寛大であって、彼らが送るもので慎重であるはずであるということです。 ソースアドレスが偽造されるという近い確実性があるときだけ、接続性に感染して、スプーフィング関心のためパケットを受け入れるのが拒否されるべきです。 他方では、間違ったアドレスにパケットを送るのは避けられるべきです。
When the client wants to send a packet to a native IPv6 node or a 6to4 node, it should check whether a valid peer entry already exists for the IPv6 address of the destination. If this is not the case, the client will pick a random number (a nonce) and format an ICMPv6 Echo Request message whose source is the local Teredo address, whose destination is the address of the IPv6 node, and whose Data field is set to the nonce. (It is recommended to use a random number at least 64 bits long.) The nonce value and the date at which the packet was sent will be documented in a provisional peer entry for the IPV6 destination. The ICMPv6 packet will then be sent encapsulated in a UDP packet destined to the Teredo server IPv4 address and to the Teredo port. The rules of Section 5.2.3 specify how the reply to this packet will be processed.
クライアントが固有のIPv6ノードか6to4ノードにパケットを送りたがっているとき、それは、有効な同輩エントリーが目的地のIPv6アドレスのために既に存在するかどうかチェックするべきです。 これがそうでないなら、クライアントは、(一回だけ)を乱数に選んで、ソースがローカルのTeredoアドレスであり、目的地がIPv6ノードのアドレスであり、Data分野が一回だけに設定されるICMPv6 Echo Requestメッセージを形式に選ぶでしょう。 (長さ少なくとも64ビットの乱数を使用するのはお勧めです。) パケットが送られた一回だけの値と期日はIPV6の目的地のための暫定的な同輩エントリーに記録されるでしょう。 そして、TeredoサーバIPv4アドレスと、そして、Teredoポートに運命づけられたUDPパケットでカプセル化された状態でICMPv6パケットを送るでしょう。 セクション5.2.3の規則はこのパケットに関する回答がどう処理されるかを指定します。
5.2.10. Working around symmetric NAT
5.2.10. 左右対称のNATの周りで働いています。
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[RFC3489]を通してIPv6の接続性を可能にするように設計されています。それは、一般的に呼ばれた「円錐のNAT」であり、「円錐のNATを制限しました」。 いくつかのNATsが意匠相違を使います。 それらはしばしば「左右対称のNAT」と呼ばれます。 地方のNATが左右対称のNATであるときに、セクション5.2.1における資格アルゴリズムは成功しないでしょう。
In many cases, it is possible to work around the limitations of these NATs by explicitly reserving a UDP port for Teredo service on a client, using a function often called "DMZ" in the NAT's manual. This port will become the "service port" used by the Teredo hosts. The implementers of Teredo functions in hosts must make sure that the value of the service port can be explicitly provisioned, so that the user can provision the same value in the host and in the NAT.
多くの場合、これらのNATsの限界の周りでTeredoサービスのためにクライアントの上で明らかにUDPポートを予約することによって働いているのは可能です、しばしばNATのマニュアルの「非武装地帯」と呼ばれる機能を使用して。 このポートはTeredoホストによって使用された「サービスポート」になるでしょう。 ホストでのTeredo機能のimplementersは、明らかにサービスポートの値に食糧を供給することができるのを確実にしなければなりません、ユーザは同じくらいがホストとNATで評価する支給をそうすることができるように
The reservation procedure guarantees that the port mapping will remain the same for all destinations. After the explicit reservation, the qualification algorithm in Section 5.2.1 will succeed, and the Teredo client will behave as if behind a "cone NAT".
予約手順は、ポートマッピングがすべての目的地に同じままで残るのを保証します。 明白な予約の後に、セクション5.2.1における資格アルゴリズムは成功するでしょう、そして、Teredoクライアントはまるで「円錐のNAT」の後ろで振る舞うかのように振る舞うでしょう。
Huitema Standards Track [Page 30] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[30ページ]。
When different clients use Teredo behind a single symmetric NAT, each of these clients must reserve and use a different service port.
異なったクライアントがただ一つの左右対称のNATの後ろでTeredoを使用すると、これらのクライアント各人は、異なったサービスポートを予約して、使用しなければなりません。
5.3. Teredo Server Specification
5.3. 船食虫サーバ仕様
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サーバはTeredo Portで入って来るUDPパケットを待っています、サービスのために選択されたIPv4アドレスを使用して。 さらに、サーバは、異なった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ルータとして機能します。 そういうものとして、それはRouter Solicitationメッセージを受け取るでしょう。(それはセクション5.3.2で説明されるようにRouter Advertisementメッセージでメッセージに応じるでしょう)。 また、それは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気泡、ICMPv6 Echo要求、およびICMPv6 Echo回答をリレーすると予想されますが、他のタイプのIPv6パケットをリレーしないと予想されます。 しかしながら、オペレータは、セクション5.4で説明されるように「船食虫サーバ」と「船食虫リレー」の機能を結合すると決めるかもしれません。
5.3.1. Processing of Teredo IPv6 Packets
5.3.1. 船食虫IPv6パケットの処理
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) UDP内容がセクション5.1.1で定義されるように整形式の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メッセージでもなく、それはSHOULDです。捨てられます。 (また、TeredoサーバがTeredoリレーセクション5.4で説明されるように作動するなら、パケットは処理されるかもしれません。)
3) If the IPv4 source address is not in the format of a global unicast address, the packet MUST be silently discarded (see Section 5.2.4 for a definition of global unicast addresses).
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リンクローカルアドレスであるなら、IPv6送付先アドレスがすべてのルータマルチキャストが扱うリンク地方の範囲である、(FF02:、:2)、パケットはICMPv6 Router Solicitationメッセージを含んでいて、パケットを受け入れなければなりません。 サーバが安全な資格を必要とするなら、それを捨てなければなりません、そして、認証カプセル化は欠けているか、または検証が失敗します。
Huitema Standards Track [Page 31] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[31ページ]。
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ソースポート、パケットSHOULDでは、受け入れてください。
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であるかどうかというこのサーバを通したことではありません、パケットSHOULD。受け入れます。
7) In all other cases, the packet MUST be silently discarded.
7) 他のすべての場合では、静かにパケットを捨てなければなりません。
The Teredo server will then check the IPv6 destination address of the encapsulated IPv6 packet:
次に、Teredoサーバはカプセル化されたIPv6パケットのIPv6送付先アドレスをチェックするでしょう:
If the IPv6 destination address is the link-local scope all routers multicast address (FF02::2), or the link-local address of the server, the Teredo server processes the packet; it may have to process Router Solicitation messages and ICMPv6 Echo Request messages.
IPv6送付先アドレスがすべてのルータマルチキャストが扱うリンク地方の範囲(FF02: : 2)、またはサーバのリンクローカルアドレスであるなら、Teredoサーバはパケットを処理します。 それはRouter SolicitationメッセージとICMPv6 Echo Requestメッセージを処理しなければならないかもしれません。
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 Serverは、グローバルなユニキャストアドレスの形式にはこの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.
- IPv6の目的地から送付先IPv4アドレスを得ます。
- The source IPv4 address is the Teredo server IPv4 address.
- ソースIPv4アドレスはTeredoサーバIPv4アドレスです。
- The destination UDP port is derived from the IPv6 destination.
- IPv6の目的地から目的地UDP港を得ます。
- The source UDP port is set to the Teredo UDP Port.
- ソースUDP港はTeredo UDP Portに設定されます。
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クライアントであるなら、サーバはUDPペイロードの最初のバイトに発生源指示を挿入するべきです、セクション5.1.1で指定されるように。 (クライアントがこのサーバによって役立たれていることを確かめるために、サーバはクライアントのTeredo IPv6アドレスのビット32-63をサーバのIPv4アドレスにたとえます。)
Huitema Standards Track [Page 32] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[32ページ]。
5.3.2. Processing of Router Solicitations
5.3.2. ルータ懇願の処理
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サーバがRouter Solicitationメッセージ(RS、[RFC2461])を受け取るとき、懇願が受けられたIPv4アドレスとUDPポートを保有します。 写像されて、これらはTeredoになります。アドレスとTeredoはクライアントのポートを写像しました。 ルータは、懇願への応答と共に送られる発生源指示カプセル化を構成するのにこれらの値を使用します。
The Teredo server responds to the router solicitation by sending a Router Advertisement message [RFC2461]. The router advertisement MUST advertise the Teredo IPv6 prefix composed from the service
Teredoサーバは、Router Advertisementメッセージ[RFC2461]を送ることによって、ルータ懇願に反応します。 ルータ通知はサービスから構成されたTeredo IPv6接頭語の広告を出さなければなりません。
prefix and the server's IPv4 address. The IPv6 source address should be set to a Teredo link-local server address associated to the local interface; this address is derived from the IPv4 address of the server and from the Teredo port, as specified in Section 4; the cone bit is set to 1. The IPv6 destination address is set to the IPv6 source address of the RS. The Router Advertisement message must be sent over UDP to the Teredo mapped address and Teredo mapped port of the client; the IPv4 source address and UDP source port should be set to the server's IPv4 address and Teredo Port. If the cone bit of the client's IPv6 address is set to 1, the RA must be sent from a different IPv4 source address than the server address over which the RS was received; if the cone bit is set to zero, the response must be sent back from the same address.
接頭語とサーバのIPv4アドレス。 IPv6ソースアドレスは局所界面に関連づけられたTeredoリンクローカルサーバアドレスに設定されるべきです。 このアドレスはサーバのIPv4アドレスとTeredoポートから引き出されます、セクション4で指定されるように。 円錐のビットは1に設定されます。 IPv6送付先アドレスはRSのIPv6ソースアドレスに設定されます。 Router AdvertisementメッセージはTeredoへの移動しているUDPがアドレスを写像して、Teredoがクライアントのポートを写像したということであるに違いありません。 IPv4ソースアドレスとUDPソースポートはサーバのIPv4アドレスとTeredo Portに設定されるべきです。 クライアントのIPv6アドレスの円錐のビットを1に設定するなら、RSが受け取られたサーバアドレスと異なったIPv4ソースアドレスからRAを送らなければなりません。 円錐のビットがゼロに設定されるなら、同じアドレスから応答を返送しなければなりません。
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パケットに挿入しなければなりません。 認証パラメタで使用されるクライアント識別子と一回だけの値は、ルータ懇願で受け取られる同じ識別子と一回だけでなければなりません。 そうでなければ、クライアント識別子がまだ有効であるか、そして、非ヌル値のゼロを合わせるように確認バイトを設定しなければなりません。 認証は計算された使用がクライアント識別子に対応する秘密であったならSHOULDを評価します。
5.4. Teredo Relay Specification
5.4. 船食虫リレー仕様
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
船食虫リレーはIPv6ルーティング・プロトコルを通してTeredoサービスIPv6接頭語の可到達性の広告を出すIPv6ルータです。 (最小量のTeredoリレーは、まさしくローカル・ホストに役立つかもしれなくて、このホストを超えて接頭語の広告を出さないでしょう。) 船食虫リレーはTeredoクライアントに縛られたIPv6パケットを受けるでしょう。 船食虫リレーはできるべきです。
Huitema Standards Track [Page 33] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[33ページ]。
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クライアントでIPv4とUDPを移動しました。 彼らは規則をフィルターにかけながら、適用するかもしれません、例えば、彼らが以前にこれらのTeredoクライアントにトラフィックを送ったなら、Teredoクライアントからパケットを単に受け入れてください。
The receiving and sending rules used by Teredo relays are very similar to those of Teredo clients. Teredo relays must use a Teredo service port to transmit packets to Teredo clients; they must maintain a "list of peers", identical to the list of peers maintained by Teredo clients.
規則がTeredoリレーで使用した受信と発信はTeredoクライアントのものと非常に同様です。 船食虫リレーはTeredoクライアントにパケットを伝えるのにTeredoサービスポートを使用しなければなりません。 彼らはTeredoクライアントによって維持された同輩のリストと同じ「同輩のリスト」を維持しなければなりません。
5.4.1. Transmission by Relays to Teredo Clients
5.4.1. 船食虫クライアントへのリレーによるトランスミッション
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 Relayは、グローバルなユニキャストアドレスの形式にはTeredo IPv6アドレスに埋め込まれたIPv4送付先アドレスがあるのをチェックしなければなりません。 これがそうでないなら、静かにパケットを捨てなければなりません(グローバルなユニキャストアドレスの定義に関してセクション5.2.4を見てください)。
The relay then checks if there is an entry for this IPv6 address in the list of recent Teredo peers, and if the entry is still valid. The relay then performs the following:
そして、リレーは最近のTeredo同輩のリストでこのIPv6アドレスのためのエントリーがあって、エントリーがまだ有効であるかどうかチェックします。 次に、リレーは以下を実行します:
1) If there is an entry for that IPv6 address in the list of peers, and if the status of the entry is set to "trusted", the IPv6 packet should be sent over UDP to the mapped IPv4 address and mapped UDP port of the entry. The relay updates the date of last transmission in the peer entry.
1) 同輩のリストでそのIPv6アドレスのためのエントリーがあって、エントリーの状態が「信じられること」に設定されるなら、IPv6パケットはエントリーの写像しているIPv4アドレスと写像しているUDPポートへの移動しているUDPであるべきです。 リレーは同輩エントリーにおける、最後のトランスミッションの日付をアップデートします。
2) If there is no trusted entry in the list of peers, and if the destination is a Teredo IPv6 address in which the cone bit is set to 1, the packet is sent over UDP to the mapped IPv4 address and mapped UDP port extracted from that IPv6 address.
2) 同輩のリストにおけるエントリーが信じられないで、目的地が円錐のビットが1に設定されるTeredo IPv6アドレスであるなら、パケットはそのIPv6アドレスから抜粋された写像しているIPv4アドレスと写像しているUDPポートへの移動している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
3) 同輩のリストにおけるエントリーが信じられないで、目的地が円錐のビットが0に設定されるTeredo IPv6アドレスであるなら、TeredoリレーはソースアドレスがローカルのIPv6アドレスに設定されて、送付先アドレスがパケットの目的地のTeredo IPv6アドレスに設定される気泡を引き起こします。 Teredoの目的地に対応するサーバアドレスに気泡を送ります。 このIPv6アドレスから気泡か別のパケットを受け取るとき、エントリーは信じられるようになります。 2秒からの時の前にどんなそのようなパケットも受け取らないなら、Teredoリレーは気泡(最大3回)を繰り返すかもしれません。 リレーがこれらの後に気泡を受けないなら
Huitema Standards Track [Page 34] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[34ページ]。
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.
反復であり、同輩のリストからエントリーを取り除きます。 リレーは信頼されていないエントリーに縛られたパケットを列に並ばせるかもしれません。 エントリーが信じられるようになるとき、デキューされて、進められた列に並ばせられたパケットSHOULD。 それら、SHOULD、エントリーが削除されるなら、削除されてください。 サービス不能攻撃、リレーを避けるために、SHOULDはそのような待ち行列における、パケットの数を制限します。
In cases 2 and 3, the Teredo relay should create a peer entry for the IPv6 address; the entry status is marked as trusted in case 2 (cone NAT) and not trusted in case 3. In case 3, if the Teredo relay happens to be located behind a non-cone NAT, it should also send a bubble directly to the mapped IPv4 address and mapped port number of the Teredo destination. This will "open the path" for the return bubble from the Teredo client.
場合2と3では、TeredoリレーはIPv6アドレスのための同輩エントリーを作成するはずです。 エントリー状態は、場合2(円錐のNAT)で信じられるようにマークされて、場合3で信じられません。 また、場合3では、Teredoリレーが非円錐のNATの後ろにたまたま位置するなら、それは直接Teredoの目的地の写像しているIPv4アドレスと写像しているポートナンバーに気泡を送るべきです。 これはTeredoクライアントからのリターン気泡のために「経路を開くでしょう」。
For reliability reasons, relays MAY decide to ignore the value of the cone bit in the flag, and always perform the "case 3", i.e., treat all Teredo peers as if they were located behind a non-cone NAT. This will result in some increase in traffic, but may avoid
信頼性の理由で、リレーは、旗による円錐のビットの価値を無視すると決めて、いつも「3インチをケースに入れてください、そして、すなわち、まるで彼らが非円錐のNATの後ろに位置するかのようにすべてのTeredo同輩を扱ってください」を実行するかもしれません。 これは、トラフィックの何らかの増加をもたらしますが、避けられるかもしれません。
reliability issues if the determination of the NAT status was for some reason erroneous. For the same reason, relays MAY also decide to always send a direct bubble to the mapped IPv4 address and mapped port number of the Teredo destination, even if they do not believe that they are located behind a non-cone NAT.
信頼性の問題はNAT状態の決断がいくつかのためのものであったなら誤った状態で推論します。 また、同じ理由から、リレーは、いつもTeredoの目的地の写像しているIPv4アドレスと写像しているポートナンバーにダイレクト気泡を送ると決めるかもしれません、非円錐のNATの後ろに位置していると信じないでも。
5.4.2. Reception from Teredo Clients
5.4.2. 船食虫クライアントからのレセプション
The Teredo relay may receive packets from Teredo clients; the packets should normally only be sent by clients to which the relay previously transmitted packets, i.e., clients whose IPv6 address is present in the list of peers. Relays, like clients, use the packet reception procedure to maintain the date and time of the last interaction with the Teredo server and the "list of recent peers".
TeredoリレーはTeredoクライアントからパケットを受けるかもしれません。 通常、パケットはリレーが以前にパケットを伝えたクライアントによって送られるだけであるはずです、すなわち、IPv6アドレスが同輩のリストに存在しているクライアント。 クライアントのように、リレーは、Teredoサーバとの最後の相互作用の日時と「最近の同輩のリスト」を維持するのにパケットレセプション手順を用います。
When a UDP packet is received over the Teredo service port, the Teredo relay checks that it contains a valid IPv6 packet as specified in [RFC2460]. If this is not the case, the packet is silently discarded.
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,
そして、Teredoリレーは、最近の同輩のリストにはIPv6ソースアドレスのためのエントリーがあるかを調べます。 これがそうでないなら
Huitema Standards Track [Page 35] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[35ページ]。
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.
パケットは静かに捨てられるかもしれません。 これがそうであるなら、エントリー状態は「信じられること」に設定されます。 リレーは「最後の相互作用の日時」のときに現在の日時までアップデートします。
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アドレスを調べます。 目的地が範囲に属すなら、アドレスがリレー、パケットSHOULDで役立ったIPv6では、受け入れられて目的地に送ってください。 他の場合では、捨てられて、パケットSHOULDは静かにそうです。
5.4.3. Difference between Teredo Relays and Teredo Servers
5.4.3. 船食虫リレーと船食虫サーバの違い
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は組み合わせリレー+サーバではなく、純粋なサーバによって実装された規則を指定するだけです。)
5.5. Implementation of Automatic Sunset
5.5. 自動日没の実装
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クライアント、サーバ、およびリレーで実装されるでしょう。
The Teredo-capable nodes MUST NOT behave as Teredo clients if they already have IPv6 connectivity through any other means, such as native IPv6 connectivity. In particular, nodes that have a global IPv4 address SHOULD obtain connectivity through the 6to4 service rather than through the Teredo service. The classic reason why a node that does not need connectivity would still enable the Teredo service is to guarantee good performance when interacting with Teredo clients; however, a Teredo-capable node that has IPv4 connectivity and that has obtained IPv6 connectivity outside the Teredo service MAY decide to behave as a Teredo relay, and still obtain good performance when interacting with Teredo clients.
彼らにIPv6の接続性が既にいかなる他の手段でもあるなら、TeredoできるノードはTeredoクライアントとして振る舞ってはいけません、固有のIPv6の接続性などのように。 特に、グローバルなIPv4アドレスSHOULDを持っているノードがTeredoサービスでというよりむしろ6to4サービスで接続性を得ます。 接続性を必要としないノードがまだTeredoサービスを可能にしている古典的な理由はTeredoクライアントと対話するとき、望ましい市場成果を保証することです。 しかしながら、Teredoクライアントと対話するとき、IPv4の接続性を持って、Teredoサービスの外でIPv6の接続性を得た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 NATsとIPv6ルータとして振る舞う「デュアル・モード」ゲートウェイなどの彼らのクライアントへの代替のソリューションの有用性に依存します。 ほとんどのTeredoサーバがかなり多くの数年間作動しないと予想されるでしょう。 船食虫リレーにはTeredoサーバと同じ寿命があると予想されます。
Huitema Standards Track [Page 36] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[36ページ]。
6. Further Study, Use of Teredo to Implement a Tunnel Service
6. さらなる研究、トンネルサービスを実装する船食虫の使用
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.
船食虫はサーバに非常に小さいリソースを使用することで提供できる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接頭語を返すことの代わりにサーバがaをグローバルに返すだろう、routable 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クライアントは、この接頭語がグローバルなIPv6接頭語であるのに気付くでしょう、Teredo接頭語のいずれの形でも、そうしません。 クライアントは、その時、それがトンネルモードで作動するべきであると認めるでしょう。 トンネルモードで働いているクライアントははるかに簡単なトランスミッション手順を実行するでしょう: それは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
Teredoクライアントはセクション5.2.5で説明された保守手順を実行しなければならないでしょう。 サーバは、ルータ懇願を受けて、NATでマッピングの再構成から生じることができた写像しているIPv4アドレスと写像しているUDPポートの可能な変化に気付くかもしれません。 そしてであるべきですサーバが、同じIPv6接頭語のクライアントに広告を出し続けるべきである。
Huitema Standards Track [Page 37] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[37ページ]。
update the mapped IPv4 address and mapped UDP port associated to this prefix, if necessary.
必要なら、この接頭語に関連づけられた写像している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へのトンネルモード拡大が発生するべきであるというコンセンサスが全くありません。 このセクションがそのようなサービスの将来の開発者に提案を提供することを意図するだけです。 トンネルモード拡大が同意される前に多くの細部がたぶん詰められなければならないでしょう。
7. Security Considerations
7. セキュリティ問題
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の主な目標はNATの後ろに位置するノードにaをグローバルに提供することです。routable IPv6アドレス。 Teredoノードはインターネット・キー・エクスチェンジ(IKE)、Authentication Header(AH)、またはEncapsulation Security有効搭載量(超能力)[RFC4306、RFC4302、RFC4303]などのIPセキュリティ(IPsec)サービスを利用できます、「IKEでのNAT縦断の交渉」[RFC3947]におけるまだ現在の構成制限なしで。 そういうものとして、私たちは、サービスがネットワークセキュリティに明白な効果を持っていると主張できます。 しかしながら、また、証券分析は私たちが4つのカテゴリで分類できる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つのタイプの問題を批評します、そして、それぞれのそれらのために緩和戦略を提示します。
7.1. Opening a Hole in the NAT
7.1. NATの穴を開きます。
The very purpose of the Teredo service is to make a machine reachable through IPv6. By definition, the machine using the service will give up whatever firewall service was available in the NAT box, however limited this service may be [RFC2993]. The services that listen to the Teredo IPv6 address will become the potential target of attacks from the entire IPv6 Internet. This may sound scary, but there are three mitigating factors.
まさしくそのTeredoサービスの目的はマシンをIPv6を通して届くようにすることです。 定義上、サービスを利用するマシンはNAT箱の中にどんな利用可能であったファイアウォールサービスもやめるでしょう、このサービスがどんなに限られても[RFC2993]。 Teredo IPv6アドレスを聞くサービスは全体のIPv6インターネットからの攻撃の仮想ターゲットになるでしょう。 これは怖く聞こえるかもしれませんが、要素を緩和する3があります。
The first mitigating factor is the possibility to restrict some services to only accept traffic from local neighbors, e.g., using link-local addresses. Teredo does not support communication using link-local addresses. This implies that link-local services will not be accessed through Teredo, and will be restricted to whatever other IPv6 connectivity may be available, e.g., direct traffic with neighbors on the local link, behind the NAT.
最初の緩和要素は地元の隣人からトラフィックを受け入れるだけであるためにいくつかのサービスを制限する可能性です、例えば、使用のリンクローカルのアドレス。 船食虫は、リンクローカルのアドレスを使用することでコミュニケーションをサポートしません。 これは、リンク地方のサービスがTeredoを通してアクセスされないで、いかなる他の利用可能であるかもしれないIPv6の接続性にも制限されるのを含意します、例えば、隣人が地方のリンクの上にいるダイレクトトラフィック、NATの後ろで。
Huitema Standards Track [Page 38] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[38ページ]。
The second mitigating factor is the possible use of a "local firewall" solution, i.e., a piece of software that performs locally the kind of inspection and filtering that is otherwise performed in a perimeter firewall. Using such software is recommended.
要素を緩和する秒が「ローカルのファイアウォール」ソリューションが活用可能性である、すなわち、局所的に点検とそれをフィルターにかける種類を実行するソフトウェア一本は別の方法で周辺ファイアウォールで実行されます。 そのようなソフトウェアを使用するのはお勧めです。
The third mitigating factor is the availability of IP security (IPsec) services such as IKE, AH, or ESP [RFC4306, RFC4302, RFC4303]. Using these services in conjunction with Teredo is a good policy, as it will protect the client from possible attacks in intermediate servers such as the NAT, the Teredo server, or the Teredo relay. (However, these services can be used only if the parties in the communication can negotiate a key, which requires agreeing on some credentials; this is known to be a hard problem.)
3番目の緩和要素はIKE、AH、または超能力[RFC4306、RFC4302、RFC4303]などのIPセキュリティ(IPsec)サービスの有用性です。 Teredoに関連してこれらのサービスを利用するのは、得策です、NAT、Teredoサーバ、またはTeredoリレーなどの中間的サーバにおける可能な攻撃からクライアントを保護するとき。 (しかしながら、コミュニケーションにおけるパーティーがいくつかの資格証明書に同意するのを必要とするキーを交渉できる場合にだけ、これらのサービスを利用できます; これは難問であることが知られています。)
7.2. Using the Teredo Service for a Man-in-the-Middle Attack
7.2. 介入者攻撃に船食虫サービスを利用します。
The goal of the Teredo service is to provide hosts located behind a NAT with a globally reachable IPv6 address. There is a possible class of attacks against this service in which an attacker somehow intercepts the router solicitation, responds with a spoofed router advertisement, and provides a Teredo client with an incorrect address. The attacker may have one of two objectives: it may try to deny service to the Teredo client by providing it with an address that is in fact unreachable, or it may try to insert itself as a relay for all client communications, effectively enabling a variety of "man-in-the-middle" attack.
Teredoサービスの目標はグローバルに届いているIPv6アドレスをNATの後ろに位置するホストに提供することです。 可能なクラスの攻撃は攻撃者がどうにかルータ懇願を妨害して、偽造しているルータ通知で応じて、不正確なアドレスをTeredoクライアントに提供するこのサービスに反対しています。 攻撃者には、2つの目的の1つがあるかもしれません: それが事実上手が届かないアドレスをそれに提供することによって、Teredoクライアントに対するサービスを否定しようとするかもしれませんか、またはすべてのクライアントコミュニケーションのためのリレーとしてそれ自体を挿入しようとするかもしれません、事実上、さまざまな「中央の男性」攻撃を可能にして。
7.2.1. Attacker Spoofing the Teredo Server
7.2.1. 船食虫サーバを偽造する攻撃者
The simple nonce verification procedure described in Section 5.2.2 provides a first level of protection against attacks in which a third party tries to spoof the server. In practice, the nonce procedure can be defeated only if the attacker is "on path".
セクション5.2.2で説明された簡単な一回だけの検証手続は第三者がサーバを偽造しようとする攻撃に対する最初のレベルの保護を提供します。攻撃者が「経路」にいる場合にだけ、実際には、一回だけの手順は破ることができます。
If client and server share a secret and agree on an authentication algorithm, the secure qualification procedure described in Section 5.2.2 provides further protection. To defeat this protection, the attacker could try to obtain a copy of the secret shared between client and server. The most likely way to obtain the shared secret is to listen to the traffic and mount an offline dictionary attack; to protect against this attack, the secret shared between client and server should contain sufficient entropy. (This probably requires some automated procedure for provisioning the shared secret and the algorithm.)
クライアントとサーバが秘密を共有して、認証アルゴリズムに同意するなら、セクション5.2.2で説明された安全な資格手順はさらなる保護を提供します。 この保護を破るために、攻撃者はクライアントとサーバの間で共有された秘密のコピーを入手しようとすることができました。共有秘密キーを得る最もありそうな方法は、トラフィックを聞いて、オフライン辞書攻撃を仕掛けることです。 この攻撃から守るために、秘密はクライアントを平等に割り当てました、そして、サーバは十分なエントロピーを含むべきです。 (これはたぶん共有秘密キーとアルゴリズムに食糧を供給するための何らかの自動化された手順を必要とします。)
If the shared secret contains sufficient entropy, the attacker would have to defeat the one-way function used to compute the authentication value. This specification suggests a default
共有秘密キーが十分なエントロピーを含んでいるなら、攻撃者は認証値を計算するのに使用される一方向関数を破らなければならないでしょう。 この仕様はデフォルトを示します。
Huitema Standards Track [Page 39] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[39ページ]。
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が移植する要求の源をそれ自身のアドレスとポートの1つに置き換えて、変更された要求をサーバに転送します。
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アドレスに注意して、Authenticationカプセル化が正しいことを確かめて、ルータ通知を準備して、それに署名して、入って来るアドレスにそれを送り返します、すなわち、攻撃者。
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が本来中央での男性攻撃であるということです。 Authenticationカプセル化は、カプセル化された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を得るのが位置を「中央では、配置します」。 攻撃を仕掛ける攻撃者がどうしたらクライアントから発するトラフィックを抑圧できなければならなくても、すなわち、サービス能力の否定を持ってください。 攻撃者は、クライアントの間で交換されたトラフィックを観測して、また、ミックスにおけるそれ自身のトラフィックを注入できなければなりません、すなわち、中央の男性容量を持ってください。 概要では、攻撃は非常に取り付けにくいです、そして、「特権の高度」に関する攻撃者のための利得は最小限です。
Huitema Standards Track [Page 40] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[40ページ]。
A similar attack is described in detail in the security section of [RFC3489].
同様の攻撃は[RFC3489]のセキュリティ部で詳細に説明されます。
7.2.2. Attacker Spoofing a Teredo Relay
7.2.2. 船食虫リレーを偽造する攻撃者
An attacker may try to use Teredo either to pass itself for another IPv6 host or to place itself as a man-in-the-middle between a Teredo host and a native IPv6 host. The attacker will mount such attacks by spoofing a Teredo relay, i.e., by convincing the Teredo host that packets bound to the native IPv6 host should be relayed to the IPv4 address of the attacker.
攻撃者は、別のIPv6ホストのためにそれ自体を渡すか、または中央の男性としてTeredoホストとネイティブのIPv6ホストの間にそれ自体を置くのにTeredoを使用しようとするかもしれません。 攻撃者はTeredoリレーを偽造することによって、そのような攻撃を仕掛けるでしょう、すなわち、ネイティブのIPv6ホストに縛られたパケットが攻撃者のIPv4アドレスにリレーされるべきであるとTeredoホストに納得させることによって。
The possibility of the attack derives from the lack of any algorithmic relation between the IPv4 address of a relay and the native IPv6 addresses served by these relay. A Teredo host cannot decide just by looking at the encapsulating IPv4 and UDP header whether or not a relay is legitimate. If a Teredo host decided to simply trust the incoming traffic, it would easily fall prey to a relay-spoofing attack.
攻撃の可能性はリレーのIPv4アドレスとネイティブのIPv6とのどんなアルゴリズムの関係の不足からもこれらのリレーで役立たれるアドレスを引き出します。 Teredoホストは、リレーが正統であるかどうか要約IPv4とUDPヘッダーを見るだけで決めることができません。 Teredoホストが、単に入って来るトラフィックを信じると決めるなら、それは容易にリレーを偽造する攻撃の犠牲となるでしょうに。
The attack is mitigated by the "direct IPv6 connectivity test" specified in Section 5.2.9. The test specifies a relay discovery procedure secured by a nonce. The nonce is transmitted from the Teredo host to the destination through Teredo server, which the client normally trusts. The response arrives through the "natural" relay, i.e., the relay closest to the IPv6 destination. Sending traffic to this relay will place it out of reach of attackers that are not on the direct path between the Teredo host and its IPv6 peer.
攻撃はセクション5.2.9で指定された「ダイレクトIPv6接続性テスト」で緩和されます。 テストは一回だけによって保証されたリレー発見手順を指定します。 一回だけはTeredoサーバを通してTeredoホストから目的地まで伝えられます。通常、クライアントはサーバを信じます。 応答はすなわち、「自然な」リレー、リレーでIPv6の目的地の最も近くに到着します。 このリレーにトラフィックを送ると、それはTeredoホストとそのIPv6同輩の間の直接路にいない攻撃者の届かないところに置かれるでしょう。
End-to-end security protections are required to defend against spoofing attacks if the attacker is on the direct path between the Teredo host and its peer.
攻撃者がTeredoホストとその同輩の間の直接路にいるなら、終わりから終わりへの機密保持が、スプーフィング攻撃に対して防御するのに必要です。
7.2.3. End-to-End Security
7.2.3. 終わりから終わりへのセキュリティ
The most effective line of defense of a Teredo client is probably not to try to secure the Teredo service itself: even if the mapping can be securely obtained, the attacker would still be able to listen to the traffic and send spoofed packets. Rather, the Teredo client should realize that, because it is located behind a NAT, it is in a
Teredoクライアントの最も効果的な防衛線はたぶんTeredoがサービス自体であると機密保護しようとしないことです: しっかりとマッピングを得ることができても、攻撃者は、トラフィックを聞いて、まだ偽造しているパケットを送ることができるでしょう。 むしろ、Teredoクライアントは、NATの後ろに位置しているのでそれがaにあるとわかるべきです。
situation of vulnerability; it should systematically try to encrypt its IPv6 traffic, using IPsec. Even if the IPv4 and UDP headers are vulnerable, the use of IPsec will effectively prevent spoofing and listening of the IPv6 packets by third parties. By providing each client with a global IPv6 address, Teredo enables the use of IPsec
脆弱性の状況。 IPsecを使用して、それは系統的にIPv6トラフィックを暗号化しようとするべきです。 IPv4とUDPヘッダーが被害を受け易くても、事実上、IPsecの使用は、IPv6パケットが第三者に偽造して、聴かれるのを防ぐでしょう。 グローバルなIPv6アドレスを各クライアントに提供することによって、TeredoはIPsecの使用を可能にします。
Huitema Standards Track [Page 41] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[41ページ]。
without the configuration restrictions still present in "Negotiation of NAT-Traversal in the IKE" [RFC3947] and ultimately enhances the security of these clients.
「IKEでのNAT縦断の交渉」[RFC3947]におけるまだ現在の構成制限と結局機能アップのないこれらのクライアントのセキュリティ。
7.3. Denial of the Teredo service
7.3. Teredoサービスの否定
Our analysis outlines five ways to attack the Teredo service. There are countermeasures for each of these attacks.
私たちの分析はTeredoサービスを攻撃する5つの方法を概説します。 それぞれのこれらの攻撃のための対策があります。
7.3.1. Denial of Service by a Rogue Relay
7.3.1. 凶暴なリレーによるサービス妨害
An attack can be mounted on the IPv6 side of the service by setting up a rogue relay and letting that relay advertise a route to the Teredo IPv6 prefix. This is an attack against IPv6 routing, which can also be mitigated by the same kind of procedures used to eliminate spurious route advertisements. Dual-stack nodes that implement "host local" Teredo relays are impervious to this attack.
凶暴なリレーをセットアップして、そのリレーにTeredo IPv6接頭語にルートに広告を出させることによって、サービスIPv6側で攻撃を仕掛けることができます。 これはIPv6ルーティングに対する攻撃です。また、偽りのルート広告を排除するのに用いられた同じ種類の手順でルーティングを緩和できます。 「ホスト地方」のTeredoリレーを実装するデュアルスタックノードはこの攻撃に不浸透性です。
7.3.2. Denial of Service by Server Spoofing
7.3.2. サーバスプーフィングによるサービス妨害
In Section 7.2, we discussed the use of spoofed router advertisements to insert an attacker in the middle of a Teredo conversation. The spoofed router advertisements can also be used to provision a client with an incorrect address, pointing to either a non-existing IPv4 address or the IPv4 address of a third party.
セクション7.2では、私たちは、Teredoの会話の途中に攻撃者を挿入するために偽造しているルータ通知の使用について議論しました。 また、不正確なアドレスをもっているクライアント、非既存のIPv4を示すのが扱うか、またはIPv4が扱う第三者の支給に偽造しているルータ通知を使用できます。
The Teredo client will detect the attack when it fails to receive traffic through the newly acquired IPv6 address. The attack can be mitigated by using the authentication encapsulation.
それが新たに取得されたIPv6アドレスを通ってトラフィックを受けないと、Teredoクライアントは攻撃を検出するでしょう。 認証カプセル化を使用することによって、攻撃を緩和できます。
7.3.3. Denial of Service by Exceeding the Number of Peers
7.3.3. 同輩の数を超えているのによるサービス妨害
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クライアントは最近中古の同輩のキャッシュを管理します。(それは、それをstatefulにします)。 それが多くのTeredo同輩から来るように見えるパケットに応じることを引き起こすことによってクライアントに対して攻撃を開始するのは可能です、その結果、キャッシュを破壊して、事実上、同輩のダイレクトコミュニケーションの使用を否定して。 単に攻撃が持続している限り、効果は持続するでしょう。
7.3.4. Attacks against the Local Discovery Procedure
7.3.4. ローカルの発見手順に対する攻撃
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
サービス攻撃の可能な否定はローカルの同輩発見手順に反対しています、攻撃者が何とか偽造している地方の発見気泡をTeredoクライアントに送ることができるなら。 セクション5.2.8で説明されたチェックはこの攻撃を緩和します。 安全に性能より関心があるクライアントは、ローカルの発見手順を無効にすると決めることができました。 しかしながら、地方の発見は障害があると、結局、サーバを通してローカルのノードの間のトラフィックはリレーされるでしょう。
Huitema Standards Track [Page 42] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[42ページ]。
external to the local network, which has questionable security implications.
企業内情報通信網に、外部です。(それは、疑わしいセキュリティ意味を持っています)。
7.3.5. Attacking the Teredo Servers and Relays
7.3.5. 船食虫サーバとリレーを攻撃します。
It is possible to mount a brute force denial of service attack against the Teredo servers by sending them a very large number of packets. This attack will have to be brute force, since the servers are stateless, and can be designed to process all the packets that are sent on their access line.
非常に多くのパケットをそれらに送ることによってTeredoサーバに対してサービス攻撃の力任せの否定を仕掛けるのは可能です。 この攻撃は力任せにならなければならないでしょう、サーバが状態がなく、それらのアクセス回線に送られるすべてのパケットを処理するように設計される場合があるので。
The brute force attack against the Teredo servers is mitigated if clients are ready to "failover" to another server. Bringing down the servers will, however, force the clients that change servers to renumber their Teredo address.
クライアントが別のサーバへの「フェイルオーバー」に準備ができているなら、Teredoサーバに対するブルートフォースアタックは緩和されます。サーバを降ろすので、しかしながら、サーバを変えるクライアントはそれらのTeredoアドレスにやむを得ず番号を付け替えさせるでしょう。
It is also possible to mount a brute force attack against a Teredo relay. This attack is mitigated if the relay under attack stops announcing the reachability of the Teredo service prefix to the IPv6 network: the traffic will be picked up by the next relay.
また、Teredoリレーに対してブルートフォースアタックを取り付けるのも可能です。 攻撃しているリレーが、Teredoサービス接頭語の可到達性をIPv6ネットワークに発表するのを止めるなら、この攻撃は緩和されます: トラフィックは次のリレーで拾われるでしょう。
An attack similar to that described in Section 7.3.2 can be mounted against a relay. An IPv6 host can send IPv6 packets to a large number of Teredo destinations, forcing the relay to establish state for each of these destinations. Teredo relays can obtain some protection by limiting the range of IPv6 clients that they serve, and by limiting the amount of state used for "new" peers.
リレーに対してセクション7.3.2で説明されたそれと同様の攻撃を仕掛けることができます。 IPv6ホストは多くのTeredoの目的地へのパケットをIPv6に送ることができます、リレーにそれぞれのこれらの目的地に状態を設置させて。 船食虫リレーは、彼らが役立つIPv6クライアントの範囲を制限して、「新しい」同輩に使用される状態の量を制限することによって、何らかの保護を得ることができます。
7.4. Denial of Service against Non-Teredo Nodes
7.4. 非船食虫ノードに対するサービス妨害
There is a widely expressed concern that transition mechanisms such as Teredo can be used to mount denial of service attacks, by injecting traffic at locations where it is not expected. These attacks fall in three categories: using the Teredo servers as a reflector in a denial of service attack, using the Teredo server to carry a denial of service attack against IPv6 nodes, and using the Teredo relays to carry a denial of service attack against IPv4 nodes. The analysis of these attacks follows. A common mitigating factor in all cases is the "regularity" of the Teredo traffic, which contains highly specific patterns such as the Teredo UDP port, or the Teredo IPv6 prefix. In case of attacks, these patterns can be used to quickly install filters and remove the offending traffic.
サービス不能攻撃を仕掛けるのにTeredoなどの変遷メカニズムを使用できるという広く言い表された関心があります、それが予想されない位置でトラフィックを注入することによって。 これらの攻撃は3つのカテゴリで下がります: 反射鏡としてサービス不能攻撃にTeredoサーバを使用して、IPv6ノードに対してサービス不能攻撃を運ぶのにTeredoサーバを使用して、サービスの否定を運ぶのにTeredoリレーを使用するのはIPv4ノードに対して攻撃されます。 これらの攻撃の分析は続きます。 すべてのケースの一般的な緩和要素はTeredoトラフィックかTeredo IPv6接頭語の「規則性」です。(トラフィックはTeredo UDPポートなどの非常に特定のパターンを含みます)。 攻撃の場合には、すばやくフィルタをインストールして、怒っているトラフィックを取り除くのにこれらのパターンを使用できます。
We should also note that none of the listed possibilities offer any noticeable amplification.
また、私たちは、記載された可能性のいずれも少しのめぼしい増幅も提供しないことに注意するべきです。
Huitema Standards Track [Page 43] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[43ページ]。
7.4.1. Laundering DoS attacks from IPv4 to IPv4
7.4.1. IPv4からIPv4までのDoS攻撃を洗濯します。
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つの方法の1つでこれができます。 最初の道はRouter Solicitationを組み立てることです。
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.
メッセージとTeredoサーバにそれを掲示して、IPv4ソースアドレスとして目標の偽造しているアドレスを使用します。 そして、TeredoサーバはRouter広告メッセージを目標に送るでしょう。 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.
[REFLECT]で反射鏡攻撃について議論します。(それは、そのような攻撃に対して様々な緩和のテクニックについて概説します)。 これらの緩和の1つがそれを観測することである、「トラフィックが、反射鏡で[has]が十分な規則性であると生成して、それをあることができる意味論が否定を構成するフィルタリング自体のない犠牲者の近くでだんだん知られた、-、-('傍系の損害')を犠牲者に修理してください、」 Teredoサーバによって反映されたトラフィックはこの条件を満たしています: それはTeredo UDPポートから発するので、明確に認識可能です。 目標自体がTeredoユーザでないなら安全にそれを無視できます。 さらに、サーバによってリレーされたパケットはOrigin指示カプセル化を運ぶでしょう。(それは、攻撃の源を決定するのを助けるでしょう)。
7.4.2. DoS Attacks from IPv4 to IPv6
7.4.2. IPv4からIPv6までのDoS攻撃
An attacker may use the Teredo servers to launch a denial of service attack against an arbitrary IPv6 destination. The attacker will build an IPv6 packet bound for the target and will send that packet to the IPv4 address and UDP port of a Teredo server, to be relayed from there to the target over IPv6.
攻撃者は、任意のIPv6の目的地に対してサービス不能攻撃に着手するのにTeredoサーバを使用するかもしれません。 攻撃者は、IPv6の上でそこから目標までリレーされるために目標に向かっているIPv6パケットを建てて、TeredoサーバのIPv4アドレスとUDPポートにそのパケットを送るでしょう。
The address checks specified in Section 5.3.1 provide some protection against this attack, as they ensure that the IPv6 source address will be consistent with the IPv4 source address and UDP source port used by the attacker: if the attacker cannot spoof the IPv4 source address, the target will be able to determine the origin of the attack.
セクション5.3.1で指定されたアドレス検査はこの攻撃に対する何らかの保護を提供します、IPv6ソースアドレスが攻撃者によって使用されるIPv4ソースアドレスとUDPソースポートと一致するのを確実にするとき: 攻撃者がIPv4ソースアドレスを偽造することができないと、目標は攻撃の発生源を決定できるでしょう。
The address checks ensure that the IPv6 source address of packets forwarded by servers will start with the IPv6 Teredo prefix. This is a mitigating factor, as sites under attack could use this to filter out all packets sourced from that prefix during an attack. This will result in a partial loss of service, as the target will not be able to communicate with legitimate Teredo hosts that use the same prefix.
アドレス検査は、サーバによって進められたパケットのIPv6ソースアドレスがIPv6 Teredo接頭語から始まるのを確実にします。 これは緩和要素です、攻撃の下のサイトが攻撃の間にその接頭語から出典を明示されたすべてのパケットを無視するのにこれを使用できたとき。 これは部分的なサービスの損失をもたらすでしょう、目標が同じ接頭語を使用する正統のTeredoホストとコミュニケートできないとき。
Huitema Standards Track [Page 44] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[44ページ]。
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ホストとのコミュニケーションは再開できるでしょう。
7.4.3. DoS Attacks from IPv6 to IPv4
7.4.3. IPv6からIPv4までのDoS攻撃
An attacker with IPv6 connectivity may use the Teredo relays to launch a denial of service attack against an arbitrary IPv4 destination. The attacker will compose a Teredo IPv6 address using the Teredo prefix, a "cone" flag set to 1, the IPv4 address of the target, and an arbitrary UDP port.
IPv6の接続性をもっている攻撃者は、任意のIPv4の目的地に対してサービス不能攻撃に着手するのにTeredoリレーを使用するかもしれません。 攻撃者は、Teredo接頭語、1に設定された「円錐」旗、目標のIPv4アドレス、および任意のUDPポートを使用することでTeredo IPv6アドレスを構成するでしょう。
In the simplest variation of this attack, the attacker sends IPv6 packets to the Teredo destination using regular IPv6 routing. The packets are picked by the nearest relay, which will forward them to the IPv4 address of the target. In a more elaborate variant, the attacker tricks a Teredo into sending packets to the target, either by sending a first packet with a spoofed IPv6 address and letting the Teredo host reply or by publishing a spoofed IPv6 address in a name service.
この攻撃の最も簡単な変化では、攻撃者は、Teredoの目的地へのパケットをIPv6に通常のIPv6ルーティングを使用することで送ります。 パケットは最も近いリレーで選ばれます。(それは、目標のIPv4アドレスにそれらを送るでしょう)。 より入念な異形では、攻撃者は、Teredoがパケットを目標に送るように偽造しているIPv6アドレスがある最初のパケットを送って、Teredoホストに返答させるか、または名前サービスにおける偽造しているIPv6アドレスを発表することによって、だまします。
There are three types of IPv4 addresses that an attacker may embed in the spoofed Teredo address. It may embed a multicast or broadcast address, an local unicast address, or a global unicast address.
攻撃者が偽造しているTeredoアドレスに埋め込むかもしれない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.
マルチキャストか放送演説と共に、攻撃者はマルチキャストルーティングの増える効果を使用できます。 単一のパケットを送ることによって、多くのホストに影響できます、"smurf"攻撃のなごりの方法で。
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.
ローカルのアドレスを使用することによって、攻撃者は通常、インターネットから届いていないホストに連絡できます、例えば、ホストが個人的なサブネットによるa 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アドレスだけにリレーされることを確かめます。 それらは、サービスか他の攻撃の否定に放送、マルチキャストまたはローカルのアドレスを使用する可能性を排除するように設計されています。 続くことでは、私たちはグローバルに届いているユニキャストアドレスを狙う攻撃を考えるだけです。
Huitema Standards Track [Page 45] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[45ページ]。
The attacks can be targeted at arbitrary UDP ports, such as, for example, the DNS port of a server. The UDP payload must be a well- formed IPv6 packet, and is thus unlikely to be accepted by any well- written UDP service; in most case, the only effect of the attack will be to overload the target with random traffic.
攻撃は任意のUDPポートをターゲットにすることができます、例えば、サーバのDNSポートなどのように。UDPペイロードはよく形成されたIPv6パケットでなければならなく、その結果、どんな上手に書かれたUDPサービスでも受け入れられそうにはありません。 大部分では、ケース、攻撃の唯一の効果は無作為のトラフィックで目標を積みすぎることでしょう。
A special case occurs if the attack is directed to an echo service. The service will echo the packets. Since the echo service sees the request coming from the IPv4 address of the relay, the echo replies will be sent back to the same relay. According to the rules specified in Section 5.4, these packets will be discarded by the Teredo relay. This is not a very efficient attack against the Teredo relays -- establishing a legitimate session with an actual Teredo host would create more traffic.
攻撃がエコーサービスに向けられるなら、特別なケースは現れます。 サービスはパケットを反響するでしょう。 エコーサービスが、要求がリレーのIPv4アドレスから来るのを見るので、同じリレーはエコー・リプライに送り返されるでしょう。 セクション5.4で指定された規則に従って、これらのパケットはTeredoリレーで捨てられるでしょう。 これはTeredoリレーに対する非常に効率的な攻撃ではありません--実際のTeredoホストとの正統のセッションを確立すると、より多くのトラフィックが作成されるでしょう。
The IPv6 packets sent to the target contain the IPv6 address used by the attacker. If ingress filtering is used in the IPv6 network, this
目標に送られたIPv6パケットは攻撃者によって使用されたIPv6アドレスを含んでいます。 イングレスフィルタリングがIPv6ネットワークに使用されるならこれ
address will be hard to spoof. If ingress filtering is not used, the attacker can be traced if the IPv6 routers use a mechanism similar to ICMP Traceback. The ICMP messages will normally be collected by the same relays that forward the traffic from the attacker; the relays can use these messages to identify the source of an ongoing attack. The details of this solution will have to be developed in further research.
アドレスは偽造しにくいようになるでしょう。 IPv6ルータがICMP Tracebackと同様のメカニズムを使用して、イングレスフィルタリングが使用されていないなら、攻撃者をつけることができます。 通常、ICMPメッセージは攻撃者からトラフィックを進めるのと同じリレーで集められるでしょう。 リレーは進行中の攻撃の源を特定するこれらのメッセージを使用できます。 このソリューションの詳細はさらなる研究で開発されなければならないでしょう。
8. IAB Considerations
8. IAB問題
The IAB has studied the problem of "Unilateral Self Address Fixing" (UNSAF), which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism [RFC3424]. Teredo is an example of a protocol that performs this type of function. The IAB has mandated that any protocols developed for this purpose document a specific set of considerations. This section meets those requirements.
IABはクライアントが協力的なプロトコル反射メカニズム[RFC3424]を通した別の分野のNATの反対側に関するアドレスを決定するのを試みる一般的なプロセスである「一方的な自己アドレス修理(UNSAF)」の問題を研究しました。 船食虫はこのタイプの関数を実行するプロトコルに関する例です。 IABは、どんなプロトコルもこの目的ドキュメントのために問題の特定のセットを発展させたのを強制しました。 このセクションはそれらの必要条件を満たします。
8.1. Problem Definition
8.1. 問題定義
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.
彼らの間のNATの存在と6to4リレーのためにTeredoによって解決されていることにおける特定の問題はネイティブにIPv6の接続性を得ることができないで、6to4を利用できないホストへのIPv6の接続性の支給です。
Huitema Standards Track [Page 46] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[46ページ]。
8.2. Exit Strategy
8.2. 撤退戦略
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.
船食虫はそれ自身の内蔵の撤退戦略と共に来ます: 他の手段(6to4かネイティブのIPv6のどちらか)でクライアントがIPv6の接続性を得るとすぐに、それは、Teredoサービスを利用するのをやめることができます。 特に、私たちは、ホームルータの次世代が現在のIPv4NATサービスへの補数にIPv6サービスを提供すると予想します、例えば、ISP、または構成されたか自動であるトンネルサービスを利用することによって得られた接続性をリレーすることによって。
As long as Teredo is used, there will be a need to support Teredo relays so that the remaining Teredo hosts can communicate with native IPv6 hosts. As Teredo usage declines, the traffic load on the relays will decline. Over time, managers will observe a reduced traffic load on their relays and will turn them off, effectively increasing the pressure on the remaining Teredo hosts to upgrade to another form of connectivity.
Teredoが使用されている限り、残っているTeredoホストがネイティブのIPv6ホストとコミュニケートできるようにTeredoにリレーを支える必要があるでしょう。 Teredo用法が減退するのに従って、リレーでのトラヒック負荷は減退するでしょう。 時間がたつにつれて、マネージャは、減少しているトラヒック負荷を彼らのリレーに観測して、それらをオフにするでしょう、事実上、別のフォームの接続性にアップグレードするように残っているTeredoホストへのプレッシャーを増強して。
The exit strategy is facilitated by the nature of Teredo, which provides an IP-level solution. IPv6-aware applications do not have to be updated to use or not use Teredo. The absence of impact on the applications makes it easier to migrate out of Teredo: network connectivity suffices.
撤退戦略はTeredoの自然によって容易にされます。(TeredoはIP-レベル解決法を提供します)。 IPv6意識しているアプリケーションは、使用にアップデートするか、またはTeredoを使用する必要はありません。 アプリケーションの影響の欠如で、Teredoから移行するのは、より簡単になります: ネットワークの接続性は十分です。
There would appear to be reasons why a Teredo implementation might decide to continue usage of the Teredo service even if it already has obtained connectivity by some other means, for example:
例えば、ある他の手段で既に接続性を得たとしても、Teredo実装がTeredoサービスの用法を続けていると決めるかもしれない理由はあるように見えるでしょう:
1. When a client is dual homed, and it wishes to improve the service when communicating with other Teredo hosts that are "nearby" on the IPv4 network. If the client only used its native IPv6 service, the Teredo hosts would be reached only through the relay. By maintaining Teredo, the Teredo hosts can be reached by direct transmission over IPv4.
1. クライアントがいつか、二元的である、家へ帰り、「近くに」IPv4ネットワークの一員である他のTeredoホストとコミュニケートするとき、それはサービスを改良したがっています。 クライアントがネイティブのIPv6サービスを利用するだけであるなら、単にリレーでTeredoホストは連絡されているでしょうに。 Teredoを維持することによって、直線伝動でIPv4の上でTeredoホストに連絡できます。
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
Teredoのデザインはデュアルホーミング理由を緩和します。 Teredo同輩とコミュニケートしたがっているホストは「ホストベースのリレー」を実装することができます。(事実上、それは、無数のTeredoインタフェースです)。 そのようなものとして二元的である、-、家へ帰り、ホストはそれらでTeredoの接続性を得るでしょう。
Huitema Standards Track [Page 47] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[47ページ]。
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カプセル化は重要なオーバーヘッドを導入します。 それはTeredoより少ないサービスを提供する固有の技術のための例外的な事情を取るでしょう。 これらの例外的な事情、または他の予期しない理由が、ホストが固有のIPv6の接続性の有用性にもかかわらず、Teredoサービスを利用し続けるのを引き起こすかもしれません。 しかしながら、これらの事情はまれであって、一時的である傾向があります。 そのうえ、Teredoを使用するプライマリ理由が消え去るなら、人はTeredoリレーが次第にオフにされて、Teredoサービスの品質が次第に下がると予想できます、Teredoサービスを利用する動機を減少させて。
8.3. Brittleness Introduced by Teredo
8.3. 船食虫によって導入されたもろさ
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.
船食虫はいくつかの方法でシステムにもろさを取り入れます: 発見プロセスはUDPに関する彼らの処理に基づくデバイスのある分類を仮定します。 マッピングは、絶え間なくリフレッシュされる必要があります。 そして、構造を扱うのは、一般的なNATの後ろに位置する何人かのホストが互いから手が届かないことを引き起こすかもしれません。
There are many similarities between these points and those introduced by Simple Traversal of the UDP Protocol through NAT (STUN) [RFC3489]; however, Teredo is probably somewhat less brittle than STUN. The reason is that all Teredo packets are sent from the local IPv4 Teredo service port, including discovery, bubbles, and actual encapsulated packets. This is different from STUN, where NAT type detection and binding allocation use different local ports (ephemeral, in both cases).
NAT(STUN)[RFC3489]を通してUDPプロトコルのSimple Traversalによって紹介されたこれらのポイントとものの間には、多くの類似性があります。 しかしながら、TeredoはたぶんSTUNよりいくらかもろくはありません。 理由は地方のIPv4 TeredoサービスポートからすべてのTeredoパケットを送るということです、発見、気泡、および実際のカプセル化されたパケットを含んでいて。 これはSTUNと異なっています(両方の場合のはかない)。そこでは、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.
船食虫は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
NATから割り当てられた結合は、絶え間なくリフレッシュされる必要があります。 以来これらの結合のためのタイムアウトが実装非常に特有である、リフレッシュ、間隔が容易にあるはずがありません。
Huitema Standards Track [Page 48] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[48ページ]。
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.
断固とする。 結合が活発に使用されていないとき、トラフィックを受けますが、入力メッセージ、結合のための待ちにリフレッシュするために、不必要にネットワーク回線容量を消費するでしょう。
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サーバの使用は潜在的セキュリティー攻撃のもう1ポイントを紹介します。 これらの攻撃は、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サーバの使用は失敗のもう1ポイントを紹介します。 クライアントがTeredoサーバの場所を見つけることができないか、またはサーバが失敗で入手できないはずであるなら、TeredoクライアントはIPv6の接続性を得ることができないでしょう。
The communication with non-Teredo hosts relies on the availability of Teredo relays. The Teredo design assumes that there are multiple Teredo relays; the Teredo service will discover the relay closest to the non-Teredo peer. If that relay becomes unavailable, or is misbehaving, communication between the Teredo hosts and the peers close to that relay will fail. This reliability issue is somewhat mitigated by the possibility to deploy many relays, arbitrarily close from the native IPv6 hosts that require connectivity with Teredo peers.
非船食虫ホストとのコミュニケーションはTeredoリレーの有用性を当てにします。 Teredoデザインは、複数のTeredoリレーがあると仮定します。 Teredoサービスは非船食虫同輩の最も近くでリレーを発見するでしょう。 そのリレーが入手できなくなるか、またはふらちな事をしていると、Teredoホストとそのリレーの近くの同輩とのコミュニケーションは失敗するでしょう。 この信頼性の問題は多くのリレーを配布する可能性によっていくらか緩和されます、Teredo同輩がいる接続性を必要とするネイティブの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.
船食虫は適切な操作のためにいくつかの制限をネットワークtopologiesに課します。 同じNATが2人のクライアントとTeredoサーバの間の経路にあると、彼らが同じリンクに接続されるか、または一般的なNATが「hairpinningすることができる」場合にだけ(すなわち、1人のクライアントによって別のものに送られた「ループ」パケット)、特に、これらのクライアントは共同利用できるでしょう。
There are also additional points of brittleness that are worth mentioning:
また、追加ポイントの言及する価値があるもろさがあります:
- Teredo service will not work through NATs of the symmetric variety.
- 船食虫サービスは左右対称のバラエティーの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サーバによります。 これは通常、公共のインターネットです。 NATの後ろにTeredoサーバがそれ自体であると、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).
- 船食虫はそれが提供するIPv6サービスにジターを取り入れます、気泡交換が起こりますが、パケットの列を作りのため。 このジターは否定的に、アプリケーション、特にボイス・オーバー IPなどの潜在の敏感な1つ(VoIP)に影響を与えることができます。
Huitema Standards Track [Page 49] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[49ページ]。
8.4. Requirements for a Long-Term Solution
8.4. 長期的な解決法のための要件
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ルータになるはずです。
9. IANA Considerations
9. IANA問題
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.
このメモは32ビットのTeredo IPv6サービス接頭語を割り当てるために要求をIANAに記録します、セクション2.17の指定されるとしてのセクション2.6、およびTeredo IPv4マルチキャストアドレスで指定されるように。
10. Acknowledgements
10. 承認
Many of the ideas in this memo are the result of discussions between the author and Microsoft colleagues, notably Brian Zill, John Miller, Mohit Talwar, Joseph Davies, and Rick Rashid. Several encapsulation details are inspired from earlier work by Keith Moore. The example in Section 5.1 and a number of security precautions were suggested by Pekka Savola. The local discovery procedure was suggested by Richard Draves and Dave Thaler. The document was reviewed by members of the NGTRANS and V6OPS working groups, including Brian Carpenter, Cyndi Jung, Keith Moore, Thomas Narten, Anssi Porttikivi, Pekka Savola, Eng Soo Guan, and Eiffel Wu. Eric Klein, Karen Nielsen, Francis Dupont, Markku Ala-Vannesluoma, Henrik Levkowetz, and Jonathan Rosenberg provided detailed reviews during the IETF last call.
このメモによる考えの多くが作者と、マイクロソフトの同僚と、著しくブライアンZillと、ジョン・ミラーと、Mohit Talwarと、ジョゼフ・デイヴィースと、リック・ラシードとの議論の結果です。 いくつかのカプセル化の詳細がキース・ムーアによって以前の仕事から奮い立たせられます。 セクション5.1の例と多くの安全対策がペッカSavolaによって勧められました。 ローカルの発見手順はリチャードDravesとデーヴThalerによって勧められました。 ドキュメントはNGTRANSとV6OPSワーキンググループのメンバーによって再検討されました、ブライアンCarpenter、シンディ・ユング、キース・ムーア、トーマスNarten、Anssi Porttikivi、ペッカSavola、エング固安曽於、およびエッフェルウーを含んでいて。 エリッククライン、カレン・ニールセン、フランシス・デュポン、マルックアラー-Vannesluoma、Henrik Levkowetz、およびジョナサン・ローゼンバーグはIETFの間の詳細なレビューに最後の呼び出しを提供しました。
Huitema Standards Track [Page 50] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[50ページ]。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(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.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2461]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2462] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] 大工とB.とK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、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問題」、RFC3424、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とのその使用」、RFC3566、9月2003日
[FIPS-180] "Secure Hash Standard", Computer Systems Laboratory,
National Institute of Standards and Technology, U.S.
Department Of Commerce, May 1993.
[FIPS-180]「安全なハッシュ規格」(コンピュータシステム研究所、米国商務省標準技術局、米国商務省)は1993がそうするかもしれません。
Huitema Standards Track [Page 51] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[51ページ]。
11.2. Informative References
11.2. 有益な参照
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[RFC2993] ハイン、T.、「NATの建築含意」、RFC2993、2000年11月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September
2002.
[RFC3330]IANA、「特別な使用IPv4アドレス」、RFC3330、2002年9月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy.
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[RFC3489] ローゼンバーグ、J.、ワインバーガー、J.、Huitema、C.、およびR.マーイ。 「気絶させてください--ユーザデータグラムの簡単な縦断はネットワークアドレス変換機構(NATs)を通して(UDP)について議定書の中で述べる」RFC3489、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] der Pol、「UnmanagedネットワークのためのIPv6変遷メカニズムの評価」をHuitema、C.、Austein、R.、Satapati、S.、およびR.はバンに積みます、RFC3904、2004年9月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A.、およびV.ボルペ、「IKEでのNAT縦断の交渉」、RFC3947、2005年1月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4302] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[RFC4306] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、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.
[REFLECT]V.パクソン、「分散DoS攻撃のための使用反射鏡の分析」、コンピュータCommunication Review、ACM SIGCOMM、Volume31、Number3、2001年7月(pp38-47)。
Author's Address
作者のアドレス
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
クリスチャンのHuitemaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052-6399
EMail: huitema@microsoft.com
メール: huitema@microsoft.com
Huitema Standards Track [Page 52] RFC 4380 Teredo February 2006
Huitema規格は船食虫2006年2月にRFC4380を追跡します[52ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Huitema Standards Track [Page 53]
Huitema標準化過程[53ページ]
一覧
スポンサーリンク
