Internet Engineering Task Force (IETF) D. Thaler
Request for Comments: 6081 Microsoft
Updates: 4380 January 2011
Category: Standards Track
ISSN: 2070-1721
Teredo Extensions
Abstract
抽象
This document specifies a set of extensions to the Teredo protocol. These extensions provide additional capabilities to Teredo, including support for more types of Network Address Translations (NATs) and support for more efficient communication.
この文書では、Teredoのプロトコルの拡張セットを指定します。これらの拡張機能は、ネットワークアドレス変換器（NAT）のより多くの種類をサポートし、より効率的なコミュニケーションのサポートなどのTeredoへの追加機能を提供します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6081.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6081で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Symmetric NAT Support Extension . . . . . . . . . . . . . 9
3.2. UPnP-Enabled Symmetric NAT Extension . . . . . . . . . . . 11
3.3. Port-Preserving Symmetric NAT Extension . . . . . . . . . 13
3.4. Sequential Port-Symmetric NAT Extension . . . . . . . . . 14
3.5. Hairpinning Extension . . . . . . . . . . . . . . . . . . 15
3.6. Server Load Reduction Extension . . . . . . . . . . . . . 17
4. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Trailers . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Nonce Trailer . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Alternate Address Trailer . . . . . . . . . . . . . . . . 19
4.4. Neighbor Discovery Option Trailer . . . . . . . . . . . . 20
4.5. Random Port Trailer . . . . . . . . . . . . . . . . . . . 21
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Common Processing . . . . . . . . . . . . . . . . . . . . 22
5.1.1. Refresh Interval . . . . . . . . . . . . . . . . . . . 22
5.1.2. Trailer Processing . . . . . . . . . . . . . . . . . . 23
5.2. Symmetric NAT Support Extension . . . . . . . . . . . . . 23
5.2.1. Abstract Data Model . . . . . . . . . . . . . . . . . 24
5.2.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.3. Initialization . . . . . . . . . . . . . . . . . . . . 24
5.2.4. Message Processing . . . . . . . . . . . . . . . . . . 24
5.3. UPnP-Enabled Symmetric NAT Extension . . . . . . . . . . . 25
5.3.1. Abstract Data Model . . . . . . . . . . . . . . . . . 26
5.3.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.3. Initialization . . . . . . . . . . . . . . . . . . . . 27
5.3.4. Message Processing . . . . . . . . . . . . . . . . . . 28
5.3.5. Shutdown . . . . . . . . . . . . . . . . . . . . . . . 29
5.4. Port-Preserving Symmetric NAT Extension . . . . . . . . . 30
5.4.1. Abstract Data Model . . . . . . . . . . . . . . . . . 30
5.4.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4.3. Initialization . . . . . . . . . . . . . . . . . . . . 32
5.4.4. Message Processing . . . . . . . . . . . . . . . . . . 32
5.5. Sequential Port-Symmetric NAT Extension . . . . . . . . . 35
5.5.1. Abstract Data Model . . . . . . . . . . . . . . . . . 35
5.5.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 36
5.5.3. Initialization . . . . . . . . . . . . . . . . . . . . 37
5.5.4. Message Processing . . . . . . . . . . . . . . . . . . 37
5.6. Hairpinning Extension . . . . . . . . . . . . . . . . . . 39
5.6.1. Abstract Data Model . . . . . . . . . . . . . . . . . 39
5.6.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 39
5.6.3. Initialization . . . . . . . . . . . . . . . . . . . . 39
5.6.4. Message Processing . . . . . . . . . . . . . . . . . . 40
5.7. Server Load Reduction Extension . . . . . . . . . . . . . 41
5.7.1. Abstract Data Model . . . . . . . . . . . . . . . . . 41
5.7.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 41
5.7.3. Initialization . . . . . . . . . . . . . . . . . . . . 42
5.7.4. Message Processing . . . . . . . . . . . . . . . . . . 42
6. Protocol Examples . . . . . . . . . . . . . . . . . . . . . . 42
6.1. Symmetric NAT Support Extension . . . . . . . . . . . . . 42
6.2. UPnP-Enabled Symmetric NAT Extension . . . . . . . . . . . 45
6.3. Port-Preserving Symmetric NAT Extension . . . . . . . . . 47
6.4. Sequential Port-Symmetric NAT Extension . . . . . . . . . 51
6.5. Hairpinning Extension . . . . . . . . . . . . . . . . . . 54
6.6. Server Load Reduction Extension . . . . . . . . . . . . . 57
7. Security Considerations . . . . . . . . . . . . . . . . . . . 58
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
10.1. Normative References . . . . . . . . . . . . . . . . . . . 58
10.2. Informative References . . . . . . . . . . . . . . . . . . 59
This document specifies extensions to the Teredo protocol, as specified in [RFC4380]. These extensions provide additional capabilities to Teredo, including support for more types of Network Address Translations (NATs) and support for more efficient communication.
[RFC4380]で指定されたこの文書は、Teredoのプロトコルに拡張子を指定します。これらの拡張機能は、ネットワークアドレス変換器（NAT）のより多くの種類をサポートし、より効率的なコミュニケーションのサポートなどのTeredoへの追加機能を提供します。
Because this document extends [RFC4380], it uses the following terminology, for consistency with [RFC4380].
このドキュメントは[RFC4380]を拡張しているので、それは[RFC4380]との整合性のために、以下の用語を使用しています。
Address-Restricted NAT: A restricted NAT that accepts packets from an external host's IP address X and port Y if the internal host has sent a packet that is destined to IP address X regardless of the destination port. In the terminology of [RFC4787], this is a NAT with Endpoint-Independent Mapping and Address-Dependent Filtering.
アドレス制限付きNAT：内部ホストはXかかわらず、宛先ポートのIPアドレス宛てのパケットを送信した場合、外部ホストのIPアドレスXとYポートからのパケットを受け入れ制限付きNAT。 [RFC4787]の用語では、これは、エンドポイント非依存性のマッピングとアドレス依存フィルタリングとNATです。
Address-Symmetric NAT: A symmetric NAT that has multiple external IP addresses and that assigns different IP addresses and ports when communicating with different external hosts.
アドレス対称NAT：複数の外部IPアドレスを持っており、異なる外部ホストと通信するときには、異なるIPアドレスとポートを割り当て対称NAT。
Cone NAT: A NAT that maps all requests from the same internal IP address and port to the same external IP address and port. Furthermore, any external host can send a packet to the internal host by sending a packet to the mapped external address and port. In the terminology of [RFC4787], this is a NAT with Endpoint-Independent Mapping and Endpoint-Independent Filtering.
コーンNAT：同じ外部IPアドレスとポートに同一の内部IPアドレスとポートからのすべての要求をマップするNAT。さらに、任意の外部のホストは、マップされた外部アドレスとポートにパケットを送信することにより、内部ホストにパケットを送信することができます。 [RFC4787]の用語では、これは、エンドポイント非依存マッピング、およびエンドポイント非依存フィルタリングとNATです。
Direct Bubble: A Teredo bubble that is sent directly to the IPv4 node whose Teredo address is contained in the Destination field of the IPv6 header, as specified in Section 2.8 of [RFC4380]. The IPv4 Destination Address and UDP Destination Port fields contain a mapped address/port.
直接バブル：[RFC4380]のセクション2.8で指定されるように、そのTeredoのアドレスのIPv6ヘッダの宛先フィールドに含まれるIPv4ノードに直接送信されTeredoバブル。 IPv4宛先アドレスおよびUDP宛先ポートフィールドは、マッピングされたアドレス/ポートが含まれています。
Echo Test: A mechanism to predict the mapped address/port a sequential port-symmetric NAT is using for a client behind it.
エコーテスト：シーケンシャルポート対称NATは、その背後にあるクライアントのために使用されるマッピングされたアドレス/ポートを予測するためのメカニズム。
Hairpinning: A feature that is available in some NATs where two or more hosts are positioned behind a NAT and each of those hosts is assigned a specific external (public) address and port by the NAT. Hairpinning support in a NAT allows these hosts to send a packet to the external address and port that is assigned to one of the other hosts, and the NAT automatically routes the packet back to the correct host. The term hairpinning is derived from the behavior of the packet, which arrives on, and is sent out to, the same NAT interface.
ヘアピン2つの以上のホストがNATの背後に配置され、それらのホストのそれぞれは、NATによって特定の外部（パブリック）アドレスとポートが割り当てられているいくつかのNATで提供された特徴。 NATでサポートをヘアピニングするバック正しいホストにパケットをこれらのホストが他のホストの1つに割り当てられる外部アドレス・ポートにパケットを送信することができ、及びNAT自動的にルーティング。用語のヘアピンは、上到着したパケットの振る舞いに由来し、同じNATインターフェイスに送信されます。
Indirect Bubble: A Teredo bubble that is sent indirectly (via the destination's Teredo server) to another Teredo client, as specified in Section 5.2.4 of [RFC4380].
間接バブル：[RFC4380]のセクション5.2.4で指定されるように、他のTeredoクライアントに（先のTeredoサーバーを介して）間接的に送信されるTeredoバブル。
Local Address/Port: The IPv4 address and UDP port from which a Teredo client sends Teredo packets. The local port is referred to as the Teredo service port in [RFC4380]. The local address of a node may or may not be globally routable because the node can be located behind one or more NATs.
ローカルアドレス/ポート：TeredoクライアントからTeredoパケットを送信するから、IPv4アドレスとUDPポート。ローカルポートは、[RFC4380]でのTeredoサービスポートと呼ばれます。ノードは、1つまたは複数のNATの背後に配置することができるので、ノードのローカルアドレスまたはグローバルにルーティング可能であってもなくてもよいです。
Mapped Address/Port: A global IPv4 address and a UDP port that results from the translation of a node's own local address/port by one or more NATs. The node learns these values through the Teredo protocol as specified in [RFC4380]. For symmetric NATs, the mapped address/port can be different for every peer with which a node tries to communicate.
マップされたアドレス/ポート：グローバルIPv4アドレスと1つのまたは複数のNATにより、ノード自体のローカルアドレス/ポートの翻訳から得られるUDPポート。 [RFC4380]で指定されたノードは、Teredoのプロトコルを介してこれらの値を学習します。対称NATのために、マッピングされたアドレス/ポートは、ノードが通信しようとしているとすべてのピアのために異なっていてもよいです。
Network Address Translation (NAT): The process of converting between IP addresses used within an intranet or other private network and Internet IP addresses.
ネットワークアドレス変換（NAT）：イントラネットまたは他のプライベートネットワークとインターネットのIPアドレス内で使用されるIPアドレスとの間で変換するプロセス。
Nonce: A time-variant random value used in the connection setup phase to prevent message replay and other types of attacks.
ノンス：メッセージリプレイや他のタイプの攻撃を防ぐために、接続設定フェーズで使用される時変ランダムな値。
Peer: A Teredo client with which another Teredo client needs to communicate.
ピア：別のTeredoクライアントが通信する必要のあるTeredoクライアント。
Port-Preserving NAT: A NAT that translates a local address/port to a mapped address/port such that the mapped port has the same value as the local port, as long as that same mapped address/port has not already been used for a different local address/port.
マッピングされたポートがある限り、同じマップされたアドレス/ポートが既に使用されていないとして、ローカルポートと同じ値を有するようにマッピングされたアドレス/ポートへのローカルアドレス/ポートを変換NAT：NATをポート保存異なるローカルアドレス/ポート。
Port-Restricted NAT: A restricted NAT that accepts packets from an external host's IP address X and port Y only if the internal host has sent a packet destined to IP address X and port Y. In the terminology of [RFC4787], this is a NAT with Endpoint-Independent Mapping and Address and Port-Dependent Filtering.
ポート制限付きNAT：内部ホストは、これは、[RFC4787]の用語ではIPアドレスXおよびポートYに宛のパケットを送信した場合にのみ、外部ホストのIPアドレスXおよびポートYからのパケットを受け入れ制限付きNATエンドポイント・独立のマッピングおよびアドレスとポート依存フィルタリングとNAT。
Port-Symmetric NAT: A symmetric NAT that has only a single external IP address and hence only assigns different ports when communicating with different external hosts.
ポート対称NAT：単一の外部IPアドレスを有し、したがって、異なる外部ホストと通信するときにのみ、異なるポートを割り当て対称NAT。
Private Address: An IPv4 address that is not globally routable but is part of the private address space specified in Section 3 of [RFC1918].
プライベート住所：グローバルにルーティング可能ではなく、[RFC1918]のセクション3で指定されたプライベートアドレス空間の一部であるIPv4アドレス。
Public Address: An external global address used by a NAT.
パブリックアドレス：NATで使用される外部グローバルアドレス。
Restricted NAT: A NAT where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike the cone NAT, an external host can send packets to an internal host (by sending a packet to the external mapped address and port) only if the internal host has first sent a packet to the external host. There are two kinds of restricted NATs: address-restricted NATs and port-restricted NATs.
制限付きNAT：同じ内部IPアドレスとポートからのすべての要求が同じ外部IPアドレスとポートにマッピングされているNAT。コーンNATとは異なり、外部ホストが内部ホストは、外部ホストにパケットを最初に送信した場合にのみ（外部マッピングされたアドレスとポートにパケットを送信することによって）、内部ホストにパケットを送信することができます。アドレス制限NATのポート制限NATの：制限付きNATのの2種類があります。
Sequential Port-Symmetric NAT: A port-symmetric NAT that allocates external ports sequentially for every {internal IP address and port, destination IP address and port} tuple. The delta used in the sequential assignment is typically 1 or 2 for most such NATs.
シーケンシャルポート対称NAT：すべてのために順次外部ポートを割り当てるポート対称NAT {内部IPアドレスおよびポート、宛先IPアドレスおよびポート}タプル。逐次割当に使用デルタは、典型的には、ほとんどのそのようなNATのための1又は2です。
Symmetric NAT: A NAT where all requests from the same internal IP address and port and to the same destination IP address and port are mapped to the same external IP address and port. Requests from the same internal IP address and port to a different destination IP address and port may be mapped to a different external IP address and port. Furthermore, a symmetric NAT accepts packets received from an external host's IP address X and port Y only if some internal host has sent packets to IP address X and port Y. In the terminology of [RFC4787], this is a NAT with a mapping behavior of either Address-Dependent Mapping or Address- and Port-Dependent Mapping, and a filtering behavior of either Address-Dependent Filtering or Address-and Port-Dependent Filtering.
対称型NAT：同じ内部IPアドレスとポートから、同じ宛先IPアドレスとポートへのすべての要求が同じ外部IPアドレスとポートにマッピングされているNAT。同じ内部IPアドレスおよびポートとは異なる宛先IPアドレスおよびポートへの要求は、異なる外部IPアドレスおよびポートにマッピングされてもよいです。いくつかの内部ホストは[RFC4787]の用語ではIPアドレスXおよびポートYにパケットを送信した場合にのみ、さらに、対称NATは、外部ホストのIPアドレスXおよびポートYから受信したパケットを受け入れ、これは、マッピング動作とNATでありますアドレス依存マッピングまたはアドレス - とポート依存マッピング、およびアドレス依存フィルタリングまたはアドレスとポート依存フィルタリングのいずれかのフィルタリング動作のいずれかの。
Teredo Bubble: A Teredo control message (specified in Section 2.8 of [RFC4380]) that is used to create a mapping in a NAT. There are two types of Teredo bubbles: direct bubbles and indirect bubbles.
Teredoバブル：NATでマッピングを作成するために使用される（[RFC4380]のセクション2.8で指定された）のTeredo制御メッセージ。直接気泡や間接の泡：Teredoの泡の2種類があります。
Teredo Client: A node that has access to the IPv4 Internet and wants to gain access to the IPv6 Internet using the Teredo protocol.
Teredoクライアント：IPv4インターネットへのアクセスを持っているとのTeredoプロトコルを使用してIPv6インターネットへのアクセスを得るために望んでいるノード。
Teredo IPv6 Address: An IPv6 address of a Teredo client, as specified in Section 2.14 of [RFC4380].
TeredoのIPv6アドレス：TeredoクライアントのIPv6アドレス、[RFC4380]のセクション2.14で指定されています。
Teredo Secondary Server Address: A secondary IPv4 address of a Teredo server with which a Teredo client is configured, as specified in Section 5.2 of [RFC4380].
Teredoのセカンダリサーバーアドレス：[RFC4380]の5.2節で指定されているTeredoクライアントは、設定されているとTeredoサーバーのセカンダリIPv4アドレス。
Teredo Server: A node that has a globally routable address on the IPv4 Internet, and is used as a helper to provide IPv6 connectivity to Teredo clients.
Teredoサーバー：IPv4インターネット上でグローバルにルーティング可能なアドレスを持ち、TeredoクライアントへのIPv6接続を提供するために、ヘルパーとして使用されているノード。
Teredo Server Address: A (primary) IPv4 address of a Teredo server with which a Teredo client is configured, as specified in Section 5.2 of [RFC4380].
Teredoサーバーアドレス：[RFC4380]のセクション5.2で指定されるようにTeredoクライアントが、構成しているTeredoサーバーの（一次）IPv4アドレス。
UPnP-enabled NAT: A NAT that has the UPnP device control protocol enabled, as specified in [UPNPWANIP]. (Note that today, by default, most UPnP-capable NATs have the UPnP device control protocol disabled.)
UPnP対応NAT：[UPNPWANIP]で指定されたUPnPデバイス制御プロトコルが、有効になっているNAT。 （デフォルトでは、ほとんどのUPnP対応のNATを無効UPnPデバイス制御プロトコルを持って、今日のことに注意してください。）
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The Teredo protocol (as specified in [RFC4380]) enables nodes located behind one or more IPv4 NATs to obtain IPv6 connectivity by tunneling packets over UDP.
Teredoのプロトコル（[RFC4380]で指定されるように）は、UDP上トンネリングパケットによってIPv6接続を得るために、一の以上のIPv4 NATの背後に位置するノードを可能にします。
When a node behind a NAT needs to communicate with a peer (i.e., another node) that is behind a NAT, there are four sets of IPv4 address/port pairs of interest:
NATの背後にあるノードがNATの背後にあるピア（すなわち、別のノード）と通信する必要がある場合、関心のIPv4のアドレス/ポートのペア4組があります。
o The node's own IPv4 address/port.
ノード自身のIPv4アドレス/ポートO。
o The external IPv4 address/port to which the node's NAT translates.
ノードのNATは、変換先の外部IPv4アドレス/ポートO。
o The peer's own IPv4 address/port.
ピア自身のIPv4アドレス/ポートO。
o The external IPv4 address/port to which the peer's NAT translates.
ピアのNATは、変換先の外部IPv4アドレス/ポートO。
When the node sends a packet to a peer, the node needs to send it from the node's own IPv4 address/port, destined to the peer's external IPv4 address/port. By the time it arrives at the peer (i.e., after passing through both NATs), the peer will see the same packet as coming from the node's external IPv4 address/port, destined to the peer's own IPv4 address/port.
ノードは、ピアにパケットを送信すると、ノードは、ピアの外部IPv4アドレス/ポート宛の、ノード自身のIPv4アドレス/ポートからそれを送信する必要があります。それは、ピア（すなわち、両方のNATを通過した後）に到達した時点で、ピアは、ピア自身のIPv4アドレス/ポート宛、ノードの外部IPv4アドレス/ポートから同じパケットを見ることができます。
In this document, the term local address/port refers to a Teredo client's own IPv4 address/port, and mapped address/port refers to the external IPv4 address/port to which its NAT translates the local address/port. That is, the mapped address/port is what the IPv4 Internet sees the Teredo client as.
この文書では、用語のローカルアドレス/ポートは、Teredoクライアント自身のIPv4アドレス/ポートを参照し、マッピングされたアドレス/ポートは、そのNATはローカルアドレス/ポートを変換先の外部IPv4アドレス/ポートを指します。これは、マップされたアドレス/ポートは、IPv4インターネットのように、Teredoクライアントを見るものである、です。
A Teredo client running on a node communicates with a Teredo server to discover its mapped address/port. The mapped address/port, along with the Teredo server address, is used to generate an IPv6 address known as a Teredo IPv6 address. This allows any peer that gets the node's IPv6 address to easily determine the external IPv4 address/ port to which to send IPv6 packets encapsulated in IPv4 UDP messages.
ノード上で実行されているTeredoクライアントは、そのマッピングされたアドレス/ポートを発見するTeredoサーバーと通信します。マッピングされたアドレス/ポートは、Teredoサーバーアドレスと共に、TeredoのIPv6アドレスとして知られているIPv6アドレスを生成するために使用されます。これは簡単にはIPv4 UDPメッセージにカプセル化されたIPv6パケットを送信するためにどの外部IPv4アドレス/ポートを決定するために、ノードのIPv6アドレスを取得する任意のピアすることができます。
This document specifies extensions to the Teredo protocol. These Teredo extensions are independent of each other and can be implemented in isolation, except that the UPnP-Symmetric NAT Extension and the Port-Preserving Symmetric NAT Extension both require the Symmetric NAT Support Extension to be implemented. An implementation of this specification can support any combination of the Teredo extensions, subject to the above-mentioned restriction.
この文書では、Teredoのプロトコルへの拡張を指定します。これらのTeredoの拡張機能は、互いに独立しており、UPnPが対称NAT拡張とPort-保存対称NAT拡張の両方が対称NATサポート拡張を実装する必要があることを除いて、アイソレーションで実現することができます。この仕様の実装は、上記制限の対象のTeredo拡張機能の任意の組み合わせをサポートすることができます。
The following matrix outlines the connectivity improvements of some of the extensions outlined in this document.
次の行列は、このドキュメントで概説拡張のいくつかの接続性の改善を概説します。
Destination NAT
| | | | | | Port-| | |
| | | | UPnP | UPnP | pres.| Seq. | |
| | Addr.| Port | Port | Port | Port-| Port-| Port-| Addr
Source NAT| Cone | rest.| rest.| rest.| symm.| symm.| symm.| symm.| symm
----------+------+------+------+------+------+------+------+------+-----
Cone | Yes | Yes | Yes | Yes | SNS | SNS | SNS | SNS | SNS
----------+------+------+------+------+------+------+------+------+-----
Address | Yes | Yes | Yes | Yes | SNS | SNS | SNS | SNS | No
restricted| | | | | | | | |
----------+------+------+------+------+------+------+------+------+-----
Port | Yes | Yes | Yes | Yes | No | SNS+ | SNS+ | No | No
restricted| | | | | | PP | SS | |
----------+------+------+------+------+------+------+------+------+-----
UPnP Port-| Yes | Yes | Yes | Yes | SNS+ | No | No | No | No
restricted| | | | | UPnP | | | |
----------+------+------+------+------+------+------+------+------+-----
UPnP Port | SNS | SNS | No | SNS+ | SNS+ | No | No | No | No
symmetric | | | | UPnP | UPnP | | | |
----------+------+------+------+------+------+------+------+------+-----
Port- | | | SNS | | | SNS | SNS | |
preserving| SNS | SNS | + | No | No | + | + | No | No
Port- | | | PP | | | PP | SS | |
symmetric | | | | | | | | |
----------+------+------+------+------+------+------+------+------+-----
Sequential| | | SNS | | | | | |
Port- | SNS | SNS | + | No | No | No | No | No | No
symmetric | | | SS | | | | | |
----------+------+------+------+------+------+------+------+------+-----
Port- | SNS | SNS | No | No | No | No | No | No | No
symmetric | | | | | | | | |
----------+------+------+------+------+------+------+------+------+-----
Address- | SNS | No | No | No | No | No | No | No | No
symmetric | | | | | | | | |
----------+------+------+------+------+------+------+------+------+-----
Yes = Supported by [RFC4380].
はい= [RFC4380]でサポートされています。
SNS = Supported with the Symmetric NAT Support Extension.
対称型NATサポート拡張をサポートするSNS =。
SNS+UPnP = Supported with the Symmetric NAT Support Extension and UPnP Symmetric NAT Extension.
SNS + UPnPは=対称NATサポートの拡張と、UPnPの対称NAT拡張でサポートされています。
SNS+PP = Supported with the Symmetric NAT Support Extension and Port-Preserving Symmetric NAT Extension.
対称型NATサポートの拡張と、ポート保存対称NAT拡張をサポートするSNS + PP =。
SNS+SS = Supported with the Symmetric NAT Support Extension and Sequential Port-Symmetric NAT Extension.
対称型NATサポートの拡張と、シーケンシャルポート対称NAT拡張をサポートするSNS + SS =。
No = No connectivity.
なし=いいえ接続。
Figure 1: Matrix of Connectivity Improvements for Teredo Extensions
図1：Teredoの拡張機能の接続性の改善のマトリックス
Note that as with [RFC4380], if the qualification process is not successful, Teredo will not be configured with an IPv6 address, and connectivity will function as if Teredo were not present. Similarly, for any combination of NAT types that are not supported by Teredo and the extensions defined herein, the connectivity tests between a client and a peer will fail within a finite period of time, allowing the client to handle this case as with any other type of unreachable destination address (e.g., by trying another address of the destination such as a native IPv4 address).
[RFC4380]と同様に、認定プロセスが成功しなかった場合、TeredoのIPv6アドレスで構成されることはありません、とTeredoが存在しないかのように接続が機能することに留意されたいです。同様に、Teredoの本明細書で定義された拡張機能によってサポートされていないNATタイプの任意の組合せのために、クライアントとピア間の接続テストは、クライアントが任意の他のタイプと同様に、このケースを処理することができ、有限時間内に失敗します到達不能宛先アドレスの（例えば、ネイティブのIPv4アドレスと送信先の別のアドレスを試みることによって）。
The qualification procedure (as specified in Section 5.2.1 of [RFC4380]) is a process that allows a Teredo client to determine the type of NAT that it is behind, in addition to its mapped address/port as seen by its Teredo server. However, Section 5.2.1 of [RFC4380] suggests that if the client learns it is behind a symmetric NAT, the Teredo client should go into an "offline state" where it is not able to use Teredo. The primary reason for doing so is that it is not easy for Teredo clients to connect to each other if either or both of them are positioned behind a symmetric NAT. Because of the way a symmetric NAT works, a peer sees a different mapped address/port in the IPv4/UDP headers of packets coming from a Teredo client than the node's Teredo server sees (and hence appears in the node's Teredo IPv6 address). Consequently, a symmetric NAT does not allow incoming packets from a peer that are addressed to the mapped address/port embedded in the node's Teredo IPv6 address. Thus, the incoming packets are dropped and communication with Teredo clients behind symmetric NATs is not established.
認定手順は、（[RFC4380]のセクション5.2.1で指定されるように）TeredoクライアントがTeredoサーバーによって見られるように、そのマッピングされたアドレス/ポートに加えて、背後にあることをNATのタイプを決定することを可能にするプロセスです。ただし、[RFC4380]のセクション5.2.1は、クライアントが、それは対称NATの背後にある学習した場合、Teredoクライアントは、あるTeredoを使用することができない「オフライン状態」に入る必要があることを示唆しています。そうするための主な理由は、それらのいずれかまたは両方が対称NATの後ろに配置されている場合のTeredoクライアントが相互に接続することは容易ではないということです。対称型NATの仕組みのため、ピアは、ノードのTeredoサーバーを見て（それゆえ、ノードのTeredoのIPv6アドレスに表示されます）よりも、Teredoクライアントから来るパケットのIPv4の/ UDPヘッダに異なるマッピングされたアドレス/ポートを見ているので。したがって、対称NATは、ノードのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートにアドレス指定されたピアからの着信パケットを許可しません。このように、着信パケットはドロップされ、対称的なNATの背後にあるTeredoクライアントとの通信が確立されていません。
With the Symmetric NAT Support Extension, Teredo clients begin to use Teredo even after they detect that they are positioned behind a symmetric NAT.
対称型NATサポート拡張で、Teredoクライアントは、彼らが対称NATの後方に位置していることを検出した後も、Teredoの使用を開始します。
Consider the topology shown in Figure 2. Teredo Client B uses Teredo Server 2 to learn that its mapped address/port is 192.0.2.10:8192, and constructs a Teredo IPv6 address, as specified in Section 4 of [RFC4380]. Hence, c633:6476 is the hexadecimal value of the address of Teredo Server 2 (198.51.100.118), the mapped port is exclusive-OR'ed with 0xffff to form dfff, and the Mapped Address is exclusive-OR'ed with 0xffffffff to form 3fff:fdf5.
図2のTeredoクライアントBに示すトポロジを検討すると、そのマッピングされたアドレス/ポートが192.0.2.10:8192であることを学ぶためにTeredoサーバー2を使用し、[RFC4380]のセクション4で指定されるように、TeredoのIPv6アドレスを構成します。したがって、C633：6476のTeredoサーバー2（198.51.100.118）のアドレスの16進数値であり、マップされたポートは、排他的論理和演算DFFFを形成することが0xFFFFであり、マップされたアドレスは、排他的論理和を0xFFFFFFFFのです3FFF形成：fdf5を。
Teredo Client A uses Teredo Server 1 to learn that its mapped address/port is 192.0.2.1:4096 and, with this extension, constructs a Teredo IPv6 address (as specified in Section 4 of [RFC4380]) even though it learns that it is behind a symmetric NAT. Hence, cb00:7178 is the hexadecimal value of the address of Teredo Server 1 (203.0.113.120), the mapped port is exclusive-OR'ed with 0xffff to form efff, and the Mapped Address is exclusive-OR'ed with 0xffffffff to form 3fff:fdfe.
TeredoクライアントAは、マッピングされたアドレス/ポートを192.0.2.1:4096であることを学ぶためにTeredoサーバー1を使用し、この拡張子で、TeredoのIPv6アドレスを構成する（[RFC4380]のセクション4で指定されるように）それがあることを知っていても対称型NATの背後にあります。したがって、CB00：7178は、マッピングされたポートがEFFF形成することが0xFFFFと排他的論理和演算Teredoサーバー1（203.0.113.120）のアドレスの16進数の値である、マップされたアドレスがに0xFFFFFFFFを用いて排他的論理和演算されます3FFF形成：fdfeを。
The Symmetric NAT Support Extension enables a Teredo client positioned behind a symmetric NAT to communicate with Teredo peers positioned behind a cone or address-restricted NATs as follows, depending on what side initiates the communication.
通信を開始するもの側に応じて、次のように対称型NATサポートの拡張は、円錐またはアドレス制限NATの背後に位置Teredoのピアと通信するために、対称NATの背後に位置Teredoクライアントを可能にします。
--------------------------------------------
/ \
< IPv6 Internet >
\ /
-|----------------------------------------|-
| |
+----------+ +----------+
| Teredo | | Teredo |
| Server 1 | | Server 2 |
+----------+ +----------+
203.0.113.120| 198.51.100.118|
-|----------------------------------------|-
/ \
< IPv4 Internet >
\ /
-|----------------------------------------|-
192.0.2.1| 192.0.2.10|
UDP port 4096| UDP port 8192|
+---------+ +----------+
|Symmetric| |Other type|
| NAT | | of NAT |
+---------+ +----------+
| |
+-----------------+ +-----------------+
| Teredo client A | | Teredo client B |
+-----------------+ +-----------------+
2001:0:cb00:7178:0:efff:3fff:fdfe 2001:0:c633:6476:0:dfff:3fff:fdf5
Teredo Address Teredo Address
Figure 2: Symmetric NAT Example
図2：対称型NATの例
In the first case, assume that a Teredo Client B (B) positioned behind a cone or address-restricted NATs initiates communication with Teredo Client A (A) positioned behind a symmetric NAT. B sends an indirect bubble via A's server (Teredo Server 1) to A, and A responds with a direct bubble. This direct bubble reaches B, because it is positioned behind a cone or address-restricted NAT. However, the mapped address/port in the IPv4/UDP headers of the direct bubble are different from the mapped address/port embedded in A's Teredo IPv6 address. B therefore remembers the mapped address/port of the direct bubble and uses them for future communication with A, and thus communication is established.
最初のケースでは、円錐またはアドレス制限NATの背後に位置TeredoクライアントBの（B）は、対称NATの背後に配置TeredoクライアントA（A）との通信を開始すると仮定する。 BはAにAのサーバー（Teredoサーバー1）を介して間接的にバブルを送り、そしてAは、直接バブルで応答します。それは、コーンまたはアドレス制限NATの背後に配置されているので、この直接のバブルは、Bに到達しました。しかし、直接バブルのIPv4 / UDPヘッダ内のマッピングされたアドレス/ポートAのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートと異なっています。 Bは、したがって、直接バブルのマッピングされたアドレス/ポートを記憶し、Aとの将来の通信のためにそれらを使用し、従って、通信が確立されます。
In the second case, assume that A, positioned behind a symmetric NAT, initiates communication with B, positioned behind a cone or address-restricted NAT. A sends an indirect bubble to B via B's server (Teredo Server 2), and B responds with a direct bubble. This direct bubble is dropped by A's symmetric NAT because the direct bubble is addressed to the mapped address/port embedded in A's Teredo IPv6 address. However, communication can be established by having B respond with an indirect bubble via A's server (Teredo Server 1). Now the scenario is similar to the first case and communication will be established.
第二のケースでは、Aは、対称NATの背後に位置することを前提とし、円錐またはアドレス制限NATの背後に位置Bとの通信を開始します。 AはBのサーバー（Teredoサーバー2）を経由してBに間接的なバブルを送り、そしてBは、直接バブルで応答します。直接気泡がAのTeredoのIPv6アドレスに埋め込まれてマッピングされたアドレス/ポートにアドレス指定されているので、この直接バブルがAの対称型NATによってドロップされます。しかし、通信はAのサーバー（Teredoサーバー1）を介した間接的なバブルとBの応答を持つことによって確立することができます。今シナリオは、最初の場合と同様であり、通信が確立されます。
The UPnP-enabled Symmetric NAT Extension is dependent on the Symmetric NAT Support Extension. Only if Teredo clients have been enabled to acquire a Teredo IPv6 address in spite of being behind a symmetric NAT will this extension help in traversing UPnP-enabled Symmetric NATs.
UPnP対応NAT対称拡張は、対称型NATサポート拡張に依存しています。 Teredoクライアントが対称型NATの後ろにいるのにもかかわらず、TeredoのIPv6アドレスを取得できるようになってきた場合にのみ、意志UPnP対応対称NATのを横断中にこの拡張ヘルプ。
The Symmetric NAT Support Extension enables communication between Teredo clients behind symmetric NATs with Teredo clients behind cone NATs or address-restricted NATs. However, clients behind symmetric NATs can still not communicate with clients behind port-restricted NATs or symmetric NATs.
対称型NATサポート拡張は、コーンのNATまたはアドレス制限NATの背後にあるTeredoクライアントとシンメトリックNATの背後にあるTeredoクライアント間の通信を可能にします。しかし、対称型NATの背後のクライアントは、まだポート制限NATのまたは対称NATの背後のクライアントと通信することはできません。
Referring again to Figure 2 (see Section 3.1), assume that Teredo Client A is positioned behind a symmetric NAT and initiates communication with Client B, which is positioned behind a port-restricted NAT. Client A sends a direct bubble and an indirect bubble to Client B via Client B's server (Teredo Server 2). As per the characteristics of the symmetric NAT, the IPv4 source of the direct bubble contains a different mapped address and/or port than the one embedded in the Teredo server. This direct bubble is dropped because Client B's NAT does not have state to let it pass through, and Client B does not learn the mapped address/port used in the IPv4/ UDP headers. In response to the indirect bubble from Client A, Client B sends a direct bubble destined to the mapped address/port embedded in Client A's Teredo IPv6 address. This direct bubble is dropped because Client A's NAT does not have state to accept packets destined to that mapped address/port. The direct bubble does, however, cause Client B's NAT to set up outgoing state for the mapped address/port embedded in Client A's Teredo IPv6 address.
（セクション3.1を参照）。図2を再び参照すると、TeredoクライアントAが対称NATの背後に位置し、ポート制限付きNATの背後に配置されているクライアントBとの通信を開始していると仮定する。クライアントAは、クライアントBのサーバー（Teredoサーバー2）を介してクライアントBに直接バブルと間接的なバブルを送信します。対称型NATの特性に従って、直接バブルのIPv4ソースはTeredoサーバーに埋め込まれたものとは異なるマッピングされたアドレスおよび/またはポートを含有します。クライアントBのNATは、それを通過させるために状態を持っていないので、この直接バブルがドロップされ、クライアントBは、IPv4 / UDPヘッダに使用マッピングされたアドレス/ポートを学習していません。クライアントAからの間接的なバブルに応じて、クライアントBは、クライアントAのTeredoのIPv6アドレスに埋め込まれてマッピングされたアドレス/ポート宛のダイレクトバブルを送信します。クライアントAのNATは、そのマッピングされたアドレス/ポート宛のパケットを受け入れるように状態を持っていないので、この直接気泡がドロップされます。直接のバブルは、しかし、クライアントAのTeredoのIPv6アドレスに埋め込まれてマッピングされたアドレス/ポートのための発信状態を設定するには、クライアントBのNATを起こすん。
As described in Section 3.1, Client B also sends an indirect bubble that elicits a direct bubble from Client A. Unlike the case in Section 3.1, however, the direct bubble from Client A is dropped as Client B's NAT does not have state for the mapped address/port that Client A's NAT uses. Note that Client B's NAT is port-restricted and hence requires both the mapped address and port to be the same as in its outgoing state, whereas in Section 3.1, Client A's NAT was a cone or address-restricted NAT which only required the mapped address (but not port) to be the same. Thus, communication between Client A and Client B fails. If Client B were behind a symmetric NAT, the problem is further complicated by Client B's NAT using a different outgoing mapped address/port than the one embedded in Client B's Teredo IPv6 address.
セクション3.1で説明したように、クライアントBはまた、3.1節における場合と異なり、クライアントAから直接バブルを誘発する間接的なバブルを送信する、ただし、クライアントAからの直接バブルがマッピングされたために状態を持たないクライアントBのNATとして廃棄されクライアントAのNATが使用するアドレス/ポート。セクション3.1で、クライアントAのNATのみマッピングされたアドレスを必要とした円錐またはアドレス制限NATであったのに対し、そのクライアントBのNATがポート制限され、したがって、その発信状態と同じであることがマッピングされたアドレスとポートの両方を必要とする注（ただし、ポート）と同じであることを。したがって、クライアントAとクライアントBとの間の通信が失敗します。クライアントBは対称NATの後ろにいた場合、問題はさらに、クライアントBのTeredoのIPv6アドレスに埋め込まれたものとは異なる出マッピングされたアドレス/ポートを使用して、クライアントBのNATによって複雑になります。
If a Teredo client is separated from the global Internet by a single UPnP-enabled symmetric or port-restricted NAT, it can communicate with other Teredo clients that are positioned behind a single UPnP-enabled symmetric or port-restricted NAT as follows.
Teredoクライアントは、単一のUPnP対応の対称またはポート制限NATによりグローバルなインターネットから分離されている場合は、次のように単一のUPnP対応の対称またはポート制限付きNATの後ろに配置されている他のTeredoクライアントと通信することができます。
Teredo clients, before communicating with the Teredo server during the qualification procedure, use UPnP to reserve a translation from a local address/port to a mapped-address/port. Therefore, during the qualification procedure, the Teredo server reflects back the reserved mapped address/port, which then is included in the Teredo IPv6 address. The mapping created by UPnP allows the NAT to forward packets destined for the mapped address/port to the local address/ port, independent of the source of the packets. It typically does not, however, cause packets sourced from the local address/port to be translated to have the mapped address/port as the external source and hence continues to function as a symmetric NAT in this respect.
Teredoクライアントは、認定手続きの際にTeredoサーバーと通信する前に、マッピングされたアドレス/ポートにローカルアドレス/ポートからの翻訳を確保するためのUPnPを使用しています。したがって、資格手順中、Teredoサーバーは、その後のTeredo IPv6アドレスに含まれている予約マッピングされたアドレス/ポートを、バック反映します。 UPnPで作成されたマッピングは、NATは、パケットの送信元とは無関係にローカルアドレス/ポートにマッピングされたアドレス/ポート宛てのパケットを転送することを可能にします。典型的には、しかし、ローカルアドレス/ポートから発信原因パケットが外部ソースとしてマッピングされたアドレス/ポートを有するように変換され、従って、この点で対称NATとして機能し続けることができるありません。
Thus, a Teredo client, positioned behind a UPnP-enabled symmetric NAT, can receive a direct bubble sent by any Teredo peer. The Teredo client compares the peer's mapped address/port as seen in the IPv4/ UDP headers with the mapped address/port in the peer's Teredo IPv6 address. If the two mappings are different, the packet was sent by another Teredo client positioned behind a symmetric NAT. The Symmetric NAT Support Extension suggested that the Teredo client use the peer's mapped address/port seen in the IPv4/UDP headers for future communication. However, because symmetric NAT-to-symmetric NAT communication would not have been possible anyway, the Teredo client sends back a direct bubble to the mapped port/address embedded in the peer's Teredo IPv6 address. If the peer is also situated behind a UPnP-enabled NAT, the direct bubble will make it through and communication will be established.
このように、UPnP対応の対称NATの後方に位置Teredoクライアントは、任意のTeredoピアによって送信された直接のバブルを受け取ることができます。ピアのTeredoのIPv6アドレスでマッピングされたアドレス/ポートでのIPv4 / UDPヘッダに見られるように、Teredoクライアントは、ピアのマップされたアドレス/ポートを比較します。 2つのマッピングが異なる場合は、パケットは、対称型NATの背後に位置する他のTeredoクライアントによって送信されました。対称型NATサポート拡張は、Teredoクライアントは、将来の通信のためのIPv4 / UDPヘッダで見ピアのマップされたアドレス/ポートを使用することが示唆されました。対称型NAT-に対称NAT通信がとにかく不可能でしたのでしかし、Teredoクライアントは、ピアのTeredoのIPv6アドレスに埋め込まれてマッピングされたポート/アドレスへの直接バブルを送り返します。ピアはまた、UPnP対応NATの背後に位置されている場合は、直接バブルがそれを通じでしょうとの通信が確立されます。
Even though communication is established between the two Teredo IPv6 addresses, the mappings will be asymmetric in the two directions of data transfer. Specifically, incoming packets will be destined to the reserved mapped address/port that is embedded in the Teredo IPv6 address. Outgoing packets will instead appear to come from a different mapped address/port due to the symmetric NAT behavior.
通信は二つのTeredoのIPv6アドレスとの間で確立されている場合でも、マッピングは、データ転送の二つの方向に非対称となります。具体的には、着信パケットはTeredoのIPv6アドレスに埋め込まれている予約マッピングされたアドレス/ポート宛であろう。発信パケットは、代わりに起因する対称NATの動作に異なるマッピングされたアドレス/ポートから来るように表示されます。
The Port-Preserving Symmetric NAT Extension is dependent on the Symmetric NAT Support Extension (Section 3.1). Only if Teredo clients have been enabled to acquire a Teredo IPv6 address in spite of being behind a symmetric NAT will this extension help in traversing port-preserving symmetric NATs.
ポート・保存対称NAT拡張は、対称型NATサポート拡張（3.1節）に依存しています。 Teredoクライアントは、対称NATの後ろにポート保存対称のNATを通過中になります。この拡張ヘルプいるにもかかわらず、TeredoのIPv6アドレスを取得するために有効になっている場合にのみ。
The Symmetric NAT Support Extension enables communication between Teredo clients behind symmetric NATs with Teredo clients behind cone NATs or address-restricted NATs. However, clients behind symmetric NATs can still not communicate with clients behind port-restricted or symmetric NATs, as described in Section 3.2. Note that the Port-Preserving Symmetric NAT Extension described here is independent of the UPnP-enabled Symmetric NAT Extension, described in Section 3.2.
対称型NATサポート拡張は、コーンのNATまたはアドレス制限NATの背後にあるTeredoクライアントとシンメトリックNATの背後にあるTeredoクライアント間の通信を可能にします。 3.2節で説明したようにしかし、対称型NATの背後のクライアントはまだ、ポート制限型または対称NATの背後のクライアントと通信することはできません。ポート・保存対称NAT拡張は、3.2節で説明したUPnP対応対称NAT拡張、とは独立して、ここで説明したことに注意してください。
If a Teredo client is positioned behind a port-preserving symmetric NAT, the client can communicate with other Teredo clients positioned behind a port-restricted NAT or a port-preserving symmetric NAT as follows.
Teredoクライアントがポート温存対称NATの背後に配置されている場合、クライアントは次のようにポート制限NATまたはポート保存対称NATの背後に位置する他のTeredoクライアントと通信することができます。
Teredo clients compare the mapped port learned during the qualification procedure with their local port to determine if they are positioned behind a port-preserving NAT. If both the mapped port and the local port have the same value, the Teredo client is positioned behind a port-preserving NAT. At the end of the qualification procedure, the Teredo client also knows if it is positioned behind a symmetric NAT, as described in Section 3.1.
Teredoクライアントは、マップされたポートが、彼らはポート保存NATの後ろに配置されているかどうかを判断するために彼らのローカルポートと認定手続き中に学習の比較します。マッピングされたポートとローカルポートの両方が同じ値を持っている場合は、Teredoクライアントは、ポート保存NATの背後に配置されています。 3.1節で説明したようにそれは、対称型NATの背後に配置されている場合は資格手続きの最後に、Teredoクライアントも知っています。
Teredo clients positioned behind port-preserving symmetric NATs can also listen on randomly chosen local ports. If the randomly chosen local port has not been used by the symmetric NAT as a mapped port in a prior port-mapping, the NAT uses the same port number as the mapped port. Thus, the challenge is to get the first direct bubble sent out from the random port to be destined to a valid destination address and port. When the mapped address/port is embedded in the destination's Teredo IPv6 address, this is easy.
ポート保存対称NATの背後に配置さTeredoクライアントはまた、ランダムに選ばれたローカルポートをリッスンすることができます。ランダムに選択されたローカルポートが前ポートマッピングにマップされたポートとして対称NATによって使用されていない場合、NATは、マッピングされたポートと同じポート番号を使用します。したがって、課題は、有効な宛先アドレスとポート宛するランダムポートから送り出された最初の直接のバブルを取得することです。マッピングされたアドレス/ポートが宛先のTeredoのIPv6アドレスに埋め込まれている場合、これは簡単です。
The communication setup is more complicated when the destination Teredo client is also positioned behind a port-preserving symmetric NAT. In such a case, both Teredo clients need to send their first direct bubbles to the correct destination mapped address/port. Thus, the protocol messages, which communicate one Teredo client's random port number to the other Teredo client, must be exchanged indirectly (via Teredo servers). When one Teredo client has access to the other Teredo client's random port number, it can send a direct bubble destined to the mapped address embedded in the destination's Teredo IPv6 address, and the mapped port can be the same as the destination's random port number. If both NATs are port-preserving, port-preserved mappings are created on both NATs and the second direct bubble succeeds in reaching the destination.
先Teredoクライアントは、ポート保存対称NATの背後に配置されている場合の通信設定は複雑です。このような場合には、両方のTeredoクライアントは、正しい宛先マッピングされたアドレス/ポートへの最初の直接気泡を送信する必要があります。このように、他のTeredoクライアントに1つのTeredoクライアントのポート番号をランダムに通信プロトコルメッセージは、（Teredoサーバーを経由して）間接的に交換する必要があります。 1つのTeredoクライアントは、他のTeredoクライアントのランダムなポート番号へのアクセスを持っている場合は、先のTeredoのIPv6アドレスに埋め込まれてマッピングされたアドレス宛のダイレクトバブルを送信することができ、およびマッピングされたポートは、先のランダムなポート番号と同じにすることができます。両方のNATのポート保存されている場合は、ポート、保存状態のマッピングは、両方のNATの上で作成され、第2の直接のバブルは、宛先に到達することに成功しています。
The Sequential Port-Symmetric NAT Extension is dependent on the Symmetric NAT Support Extension (Section 3.1). This extension helps in traversing a sequential port-symmetric NAT only if Teredo clients are enabled to acquire a Teredo IPv6 address even when behind a symmetric NAT.
シーケンシャルポート対称NAT拡張は、対称型NATサポート拡張（3.1節）に依存しています。この拡張は、Teredoクライアントがさえ対称NATの背後にあるTeredoのIPv6アドレスを取得するために有効になっている場合にのみ、シーケンシャルポート対称NATを通過するのに役立ちます。
When the Sequential Port-Symmetric NAT Extension is used, if a Teredo client is positioned behind a sequential port-symmetric NAT, the client can communicate with other Teredo clients that are positioned behind a port-restricted NAT as follows.
シーケンシャルポート対称NAT拡張を使用する場合は、Teredoクライアントは、順次ポート対称NATの後ろに配置されている場合、クライアントは次のようにポート制限NATの後ろに配置されている他のTeredoクライアントと通信することができます。
During qualification, if the client discovers it is behind a symmetric NAT that is not port-preserving, the client assumes by default that it is behind a sequential port-symmetric NAT. This assumption is proactive for the following reasons:
クライアントがポート保存ではありません対称NATの背後にある発見した場合は資格の間に、クライアントは、シーケンシャルポート対称NATの背後にあることをデフォルトで想定しています。この仮定は、以下の理由でプロアクティブです。
o There is no perfect method of discovering whether the client is behind a sequential port-symmetric NAT.
Oクライアントは、順次ポート対称NATの背後にあるかどうかを発見する完璧な方法はありません。
o These kinds of NATs are notorious for changing their behavior. At times, they could be sequential port-symmetric and at other times not.
O NATのこれらの種類は、彼らの行動を変えることで有名です。時には、彼らはシーケンシャルポート対称および他の回ではない可能性があります。
o There is no other solution for symmetric NAT traversal so this is a last resort.
Oので、これは最後の手段である対称型NATトラバーサルのための他の解決策はありません。
Teredo clients positioned behind sequential port-symmetric NATs can also listen on a randomly chosen local port when communicating with a peer. To predict the external port being used for a given peer, the client sends three packets: o Packet 1 is a router solicitation (as specified in Section 5.2.1 of [RFC4380]) sent to the Teredo server address.
ピアとの通信時にシーケンシャルポート対称NATの背後に位置Teredoクライアントはまた、ランダムに選択されたローカルポートをリッスンすることができます。所与のピアのために使用されている外部ポートを予測するために、クライアントは、3つのパケットを送信しますパケット1 O Teredoサーバーアドレスに送信された（[RFC4380]のセクション5.2.1で指定されるように）ルータ要請です。
o Packet 2 is a direct bubble sent to the peer.
Oパケット2は、ピアに送信直接バブルです。
o Packet 3 is a router solicitation sent to the secondary Teredo server address.
Oパケット3は、二次Teredoサーバーのアドレスに送信されたルータ要請です。
As part of the normal Teredo protocol, the Teredo server responds to packets 1 and 3. Based on the information in the responses, the client now knows that Packet 1 was seen as coming from one external port, and Packet 3 was seen as coming from another external port. Assuming the NAT is a sequential port-symmetric NAT, the external port for Packet 2 is estimated (or predicted) to be midway between the external ports for Packets 1 and 3. Note that because other applications might also have been using the NAT between packets 1 and 3, the actual port might not be exactly the midpoint.
通常のTeredoプロトコルの一部として、Teredoサーバーが応答内の情報に基づいて、1と3のパケットに応答し、クライアントは、パケット1は、1つの外部ポートから来たと見られていた、とパケット3はから来てと見られていたことを知っています別の外部ポート。 NATと仮定すると、シーケンシャルポート対称NAT、パケット2のための外部ポート外部パケット1のためのポートと、他のアプリケーションも、パケット間のNATを使用している可能性があるため、ことに留意されたいとの中間であると推定され（または予測）であります1と3、実際のポートは正確に中間点ではないかもしれません。
The Teredo client then communicates the predicted port to its peer, which sends a direct bubble to the communicated port. If the communicated port is indeed the external port for Packet 2, the direct bubble will reach the Teredo client.
Teredoクライアントは、通信ポートへの直接泡を送信ピアに予測ポートを通信します。通信ポートが実際にパケット2用の外部ポートの場合は、直接のバブルは、Teredoクライアントに到達します。
Hairpinning support in a NAT routes packets that are sent from a private (local) address destined to a public (mapped) address of the NAT, back to another private (local) destination address behind the same NAT. If hairpinning support is not available in a NAT, two Teredo clients behind the same NAT are not able to communicate with each other, as specified in Section 8.3 of [RFC4380].
バック同じNATの背後にある別の私立（ローカル）宛先アドレスに、NATのパブリック（マッピングされた）アドレス宛てのプライベート（ローカル）アドレスから送信されたNATルートパケットにサポートをヘアピニング。サポートはヘアピニングはNATで利用できない場合は、同じNATの背後にある2つのTeredoクライアントは、[RFC4380]のセクション8.3で指定されるように、互いに通信することができません。
The Hairpinning Extension enables two clients behind the same NAT to talk to each other when the NAT does not support hairpinning. This process is illustrated in the following diagram.
NATは、ヘアピンをサポートしていないときヘアピニング拡張が同じNATの背後にある2つのクライアントがお互いに話をすることができます。このプロセスは、以下の図に示されています。
--------------------------------------------
/ \
< IPv6 Internet >
\ /
--------------------|-----------------------
|
+----------+
| Teredo |
| Server |
+----------+
203.0.113.120|
--------------------|-----------------------
/ \
< IPv4 Internet >
\ /
--------------------|-----------------------
198.51.100.118|
NAT +-------+
without | NAT |
hairpinning | E |
support +-------+
|
+------------------+--------------------+
192.168.1.0| 192.168.1.1|
UDP port 4095| UDP port 4096|
+---------+ +----------+
| NAT | | NAT |
| F | | G |
+---------+ +----------+
| |
+-----------------+ +-----------------+
| Teredo client A | | Teredo client B |
+-----------------+ +-----------------+
2001:0:cb00:7178:0:f000:39cc:9b89 2001:0:cb00:7178:0:efff:39cc:9b89
Teredo Address Teredo Address
Figure 3: Hairpinning Example
図3：ヘアピニング例
The Teredo Client A (A) includes, as part of its indirect bubble sent to Teredo Client B (B), its local address/port. B, upon receiving the indirect bubble, tries to establish communication by sending direct bubbles to the mapped address/port of A, and also to the local address/port of B.
TeredoクライアントA（A）は、TeredoクライアントのB（B）、そのローカルアドレス/ポートに送信され、その間接的な泡の一部として含まれています。 Bは、間接的なバブルを受信すると、Aのマッピングされたアドレス/ポートへ、またBのローカルアドレス/ポートに直接気泡を送信することによって通信を確立しようとし
If a Teredo client is part of a multi-NAT hierarchy and the NAT to which the Teredo client is connected supports the UPnP protocol (as specified in [UPNPWANIP]), the Teredo client can use UPnP to determine the mapped address/port assigned to it by the NAT. This information can be included along with the local address/port when sending the indirect bubble. The destination Teredo client now tries to establish a connection by sending direct bubbles to the mapped address/port in the Teredo IPv6 address, to the local address/port included in the bubble, and also to the mapped address/port included in the bubble.
（[UPNPWANIP]で指定されるように）TeredoクライアントがマルチNAT階層の一部であり、Teredoクライアントが接続されているNATがUPnPプロトコルをサポートしている場合、Teredoクライアントは、に割り当てられたマッピングされたアドレス/ポートを決定するためのUPnPを使用することができNATによってそれ。間接的なバブルを送信するときにこの情報は、ローカルアドレス/ポートと一緒に含めることができます。先のTeredoクライアントは、ローカルアドレス/ポートがバブルに含まに、また、マッピングされたアドレス/ポートに、TeredoのIPv6アドレスでマッピングされたアドレス/ポートへの直接気泡を送信して接続を確立しようとするバブルに含まれています。
Note that UPnP support is only required if the Teredo clients are behind different NATs in a multi-NAT hierarchy. Without UPnP support, the Hairpinning Extension still allows two hosts behind the same non-hairpinning NAT to communicate using their Teredo IPv6 addresses.
TeredoクライアントがマルチNAT階層の異なるNATの背後にある場合、UPnPサポートがのみ必要であることに注意してください。 UPnPサポートがなければ、ヘアピニング拡張はまだ同じ非ヘアピンのNATの背後にある2つのホストが自分のTeredo IPv6アドレスを使用して通信することができます。
If communication between a Teredo client and a Teredo peer was successfully established but at a later stage was silent for a while, for efficiency, it is best to refresh the mapping state in the NATs that are positioned between them. To refresh the communication between itself and a Teredo peer, a Teredo client needs to solicit a direct bubble response from the Teredo peer. An indirect bubble is sent to solicit a direct bubble response from a Teredo peer, as specified in Section 5.2.4 of [RFC4380]. However, these indirect bubbles increase the load on the Teredo server.
TeredoクライアントとTeredoのピア間の通信が正常に確立が、後の段階でしばらく黙っていたされた場合は、効率のために、それはそれらの間に配置されているNATの中にマッピング状態をリフレッシュするのが最善です。自身とのTeredoピア間の通信を更新するには、TeredoクライアントからTeredoピアからの直接バブル応答を勧誘する必要があります。 [RFC4380]のセクション5.2.4で指定されるように間接的なバブルは、Teredoのピアから直接気泡応答を求めるために送信されます。しかし、これらの間接的な気泡がTeredoサーバーの負荷を増加させます。
The Server Load Reduction Extension allows Teredo clients to send direct bubbles most of the time instead of sending indirect bubbles all of the time in the following way:
サーバー負荷軽減拡張がTeredoクライアントが直接泡を送信することができますほとんどの時間はなく、間接的に送信するには、次のようにすべての時間を泡：
1. When a Teredo client tries to refresh its communication with a Teredo peer, it uses a direct bubble instead of an indirect bubble. However, because direct bubbles do not normally solicit a response, the direct bubble format is extended to be able to solicit a response.
1. Teredoクライアントは、Teredoのピアとの通信をリフレッシュしようとすると、それは代わりに、間接バブルの直接のバブルを使用しています。直接気泡が正常に応答を勧誘していないので、しかし、直接バブルフォーマットは、応答を求めることができるように拡張されます。
2. When a Teredo client receives a direct bubble that is soliciting a response, the Teredo client responds with a direct bubble.
Teredoクライアントが応答を勧誘され、直接バブルを受信した場合2.、Teredoクライアントは、直接バブルで応答します。
3. If attempts to re-establish communication with the help of direct bubbles fail, the Teredo client starts over the process of establishing communication with the Teredo peer, as specified in Section 5.2.4 of [RFC4380].
直接気泡の助けを借りて通信を再確立する試みが失敗した場合は、[RFC4380]のセクション5.2.4で指定されるように3は、Teredoクライアントは、Teredoのピアとの通信を確立する過程にわたって開始します。
All Teredo messages are transported over the User Datagram Protocol (UDP), as specified in Section 3 of [RFC4380].
[RFC4380]のセクション3で指定されているすべてのTeredoのメッセージは、ユーザーデータグラムプロトコル（UDP）の上に輸送されます。
In addition, Section 5.2.3 of [RFC4380] states:
また、[RFC4380]のセクション5.2.3の状態：
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 [sic] to its own Teredo address.
それは[RFC2460]に準拠している場合、IPv6パケットが有効であると考えられる：プロトコル識別子は、パケットがカプセル化されたUDPデータグラムの長さと一致しなければならないIPv6パケット及びペイロード長を示すべきです。また、クライアントは、IPv6宛先アドレスが自身のTeredoアドレスに[原文のまま]対応することを確認しなければなりません。
This document updates the word "consistent" above as follows. The IPv6 payload length is "consistent" with the length of the UDP datagram if the IPv6 packet length (i.e., the Payload Length value in the IPv6 header plus the IPv6 header size) is less than or equal to the UDP payload length (i.e., the Length value in the UDP header minus the UDP header size). This allows the use of trailers after the IPv6 packet, which are defined in the following sections.
このドキュメントは、次のように上記の「一貫した」という言葉を更新します。 IPv6パケットの長さ（すなわち、IPv6ヘッダ内のペイロード長値+ IPv6ヘッダサイズ）よりも小さいか又はUDPペイロード長（すなわち、に等しい場合のIPv6ペイロード長は、UDPデータグラムの長さを有する「一致」でありますUDPヘッダの長さ値マイナスUDPヘッダサイズ）。これは、次のセクションで定義されているIPv6パケット、後のトレーラーを使用することができます。
Teredo packets can carry a variable number of type-length-value (TLV) encoded trailers, of the following format (intended to be similar to the use of IPv6 options defined in [RFC2460] section 4.2):
Teredoパケットは（[RFC2460]セクション4.2で定義されたIPv6オプションの使用と同様であることを意図し）、次の形式のエンコードされたトレイラーを、タイプレングス値（TLV）の可変数を運ぶことができます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (1 byte): 8-bit identifier of the type of trailer.
タイプ（1バイト）：トレーラーのタイプの8ビットの識別子。
Length (1 byte): 8-bit unsigned integer. Length of the Value field of this trailer, in octets.
長さ（1バイト）：8ビットの符号なし整数。オクテットで、このトレーラーの値フィールドの長さ。
Value (variable): Trailer-Type-specific data.
値（変数）：トレーラー型固有のデータ。
The trailer Type identifiers are internally encoded such that their highest-order two bits specify the action that is to be taken if the host does not recognize the trailer Type:
トレーラータイプ識別子は、内部的にその最上位2ビットは、ホストがトレーラーの種類を認識しない場合に実行される処置を指定するようにエンコードされます。
00, 10, 11 - skip over this trailer and continue processing the packet.
00、10、11 - このトレーラーをスキップし、パケットの処理を継続。
01 - discard the packet.
01 - パケットを破棄する。
The Nonce Trailer is used by the Symmetric NAT Support Extension (and therefore the UPnP-enabled Symmetric NAT Extension and Port-Preserving Symmetric NAT Extension also) and the Hairpinning Extension. The Nonce Trailer can be present in both indirect and direct bubbles. The nonce in the Nonce Trailer helps authenticate a Teredo client positioned behind a Symmetric NAT.
ナンストレーラーは、対称型NATサポート拡張（したがって、UPnP対応対称NAT拡張し、またポート・保存対称NAT拡張）とヘアピニング拡張によって使用されます。ナンストレーラーは、間接と直接の両方泡で存在することができます。ナンストレーラーでナンスは、対称型NATの後方に位置Teredoクライアントを認証できます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (1 byte): The Trailer Option type. This field MUST be set to 0x01.
タイプ（1バイト）：トレーラーオプションタイプ。このフィールドは0×01に設定しなければなりません。
Length (1 byte): The length in bytes of the rest of the option. This field MUST be set to 0x04.
長さ（1バイト）：オプションの残りのバイト単位の長さ。このフィールドは、0x04のに設定しなければなりません。
Nonce (4 bytes): The nonce value.
ノンス（4バイト）：ナンス値。
The Alternate Address Trailer is used by the Hairpinning Extension. The Alternate Address Trailer MUST NOT be present in any packets other than indirect bubbles sent by a Teredo client. The Alternate Address Trailer provides another Teredo client positioned behind the same NAT with more address options that it can use to connect.
代替アドレストレーラーはヘアピニング拡張によって使用されます。代替アドレストレーラーのTeredoクライアントから送信された間接的な泡以外のパケット中に存在してはなりません。代替アドレストレーラーは、それが接続に使用することができ、よりアドレスオプションと同じNATの背後にある別のTeredoクライアントを提供します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Alternate Address/Port List (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (1 byte): The Trailer Option type. This field MUST be set to 0x03.
タイプ（1バイト）：トレーラーオプションタイプ。このフィールドは0×03に設定しなければなりません。
Length (1 byte): The length in bytes of the rest of the option. The value of this field MUST be in the range 8 to 26 (i.e., 2 bytes for the Reserved field, and 6 bytes for each entry in the Alternate Address/Port List). This allows for a minimum of one address/port mapping and a maximum of four address/port mappings to be advertised. It SHOULD be at most 14 as a maximum of two address/port mappings can be determined by Teredo: one local address/port and one obtained using UPnP. Because the length of the alternate address/port is 6 bytes, the valid range of values is only 8, 14, 20, and 26.
長さ（1バイト）：オプションの残りのバイト単位の長さ。このフィールドの値は26の範囲8（すなわち、予約フィールドの2バイト、及び代替アドレス/ポート・リスト内の各エントリのために6バイト）でなければなりません。これは、1つのアドレス/ポートマッピングおよびアドバタイズされる4つのアドレス/ポートマッピングの最大値の最小値を可能にします。 2つのアドレス/ポートマッピングの最大のTeredoによって決定することができるように、それはせいぜい14にすべきである：一つのローカルアドレス/ポートとUPnPを使用して得られたもの。代替アドレス/ポートの長さは6バイトであるので、値の有効範囲は、8、14、20、及び26です。
Reserved (2 bytes): This field MUST be set to 0x0000 and ignored on receipt.
予約済み（2バイト）：このフィールドは0x0000に設定して、領収書の上で無視しなければなりません。
Alternate Address/Port List (variable): An array of additional address/port pairs that can be used by other Teredo clients to communicate with the sender. Each alternate address/port entry MUST be formatted as follows:
代替アドレス/ポート・リスト（変数）：送信者と通信するために他のTeredoクライアントで使用できる追加のアドレス/ポートのペアの配列。次のように各代替アドレス/ポート・エントリをフォーマットしなければなりません。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Address (4 bytes): An IPv4 address in network byte order. This field MUST contain a valid unicast address.
IPv4アドレス（4バイト）：ネットワークバイトオーダーでのIPv4アドレス。このフィールドには、有効なユニキャストアドレスを含まなければなりません。
Port (2 bytes): A port number in network byte order. This field MUST NOT be zero.
ポート（2バイト）：ネットワークバイトオーダーでのポート番号。このフィールドはゼロであるはずがありません。
The Neighbor Discovery Option Trailer is used by the Server Load Reduction Extension because it allows direct bubbles to encode an IPv6 Neighbor Solicitation (Section 4.3 of [RFC4861]), in addition to an IPv6 Neighbor Advertisement (Section 4.4 of [RFC4861]). This allows packets to be sent without having to relay them through a Teredo server. The Neighbor Discovery Option Trailer allows the receiver to differentiate between a direct bubble that is soliciting a response versus a regular direct bubble. This allows Teredo clients to use direct bubbles to refresh inactive connections instead of using indirect bubbles.
それは直接気泡がIPv6近隣広告（[RFC4861]のセクション4.4）に加えて、IPv6近隣要請（[RFC4861]のセクション4.3）をコードすることを可能にするため、近隣探索オプショントレーラーは、サーバ負荷低減拡張によって使用されます。これは、パケットがTeredoサーバーを介してそれらを中継することなく送信することができます。近隣探索オプショントレーラーは、受信機が定期的に直接バブルに対するレスポンスを勧誘されている直接バブルを区別することを可能にします。これは、Teredoクライアントではなく、間接的に気泡を使用しての非アクティブな接続をリフレッシュするために直接泡を使用することができます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | DiscoveryType | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (1 byte): The Trailer Option type. This field MUST be set to 0x04.
タイプ（1バイト）：トレーラーオプションタイプ。このフィールドは、0x04のに設定しなければなりません。
Length (1 byte): The length in bytes of the rest of the option. This field MUST be set to 0x04.
長さ（1バイト）：オプションの残りのバイト単位の長さ。このフィールドは、0x04のに設定しなければなりません。
DiscoveryType (1 byte): This field MUST be set to one of the following values:
DiscoveryType（1バイト）：このフィールドは、以下のいずれかの値に設定する必要があります。
TeredoDiscoverySolicitation (0x00): The receiver is requested to respond with a direct bubble of DiscoveryType TeredoDiscoveryAdvertisement.
TeredoDiscoverySolicitationは（$ 00）：受信機はDiscoveryType TeredoDiscoveryAdvertisementの直接的な泡で応答するように要求されます。
TeredoDiscoveryAdvertisement (0x01): The direct bubble is in response to a direct bubble or an indirect bubbles containing DiscoveryType TeredoDiscoverySolicitation.
TeredoDiscoveryAdvertisement（0×01）：直接バブルが直接バブル又はDiscoveryType TeredoDiscoverySolicitationを含む間接気泡に応答します。
Reserved (3 bytes): This field MUST be set to 0x000000 on transmission and ignored on receipt.
（3バイト）予約：このフィールドは、送信に0×000000に設定して、領収書の上で無視しなければなりません。
The Random Port Trailer is used by the Port-Preserving Symmetric NAT Extension in both indirect and direct bubbles.
ランダムポートトレーラーは、間接と直接の両方泡でport-保存対称NAT拡張によって使用されます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Random Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (1 byte): The Trailer Option type. This field MUST be set to 0x05.
タイプ（1バイト）：トレーラーオプションタイプ。このフィールドは、0x05のに設定しなければなりません。
Length (1 byte): The length in bytes of the rest of the option. This field MUST be set to 0x02.
長さ（1バイト）：オプションの残りのバイト単位の長さ。このフィールドは0×02に設定しなければなりません。
Random Port (2 bytes): The external port that the sender predicts that its NAT has assigned it for communication with the destination. This field MUST be specified in network byte order.
ランダムポート（2バイト）：送信者はそのNATは、宛先との通信のためにそれを割り当てたことを予測した外部ポート。このフィールドは、ネットワークバイトオーダーで指定する必要があります。
The behavior in this section applies to multiple extensions.
このセクションの動作は、複数の拡張子に適用されます。
Packets equivalent to those sent for a peer the first time a connection is being established MAY be generated at other implementation-specific times. (For example, an implementation might choose to do so when its Neighbor Cache Entry for the peer is in the PROBE state.)
接続が確立されて初めて、他の実装固有の時間に生成することができるピアのために送られたものと同等のパケット。 （例えば、実装は、ピアのためにその近隣キャッシュエントリはPROBE状態にあるときにそうするように選択できます。）
Section 5.2 of [RFC4380] states:
[RFC4380]のセクション5.2の状態：
The client must regularly perform the maintenance procedure in order to guarantee that the Teredo service port remains usable. The need to use this procedure or not depends on the delay since the last interaction with the Teredo server. The refresh procedure takes as a parameter the "Teredo refresh interval". This parameter is initially set to 30 seconds; it can be updated as a result of the optional "interval determination procedure". The randomized refresh interval is set to a value randomly chosen between 75% and 100% of the refresh interval.
クライアントは、定期的にTeredoサービスポートが使用可能なままであることを保証するために、メンテナンス手順を実行する必要があります。この手順を使用するかする必要がTeredoサーバーとの最後の対話以降の遅延に依存します。リフレッシュ手順は、パラメータ「のTeredo更新間隔」となります。このパラメータは、最初は30秒に設定されています。それは、オプションの「間隔判定手順」の結果として更新することができます。ランダム化されたリフレッシュ間隔をランダムに75％およびリフレッシュ間隔の100％の間で選択された値に設定されています。
This requirement can be problematic when the client is behind a NAT that expires state in less than 30 seconds. The optional interval determination procedure (Section 5.2.7 of [RFC4380]) also does not provide for intervals under 30 seconds. Hence, this document refines the behavior by saying the initial parameter SHOULD be configurable and the default MUST be 30 seconds. An implementation MAY set the randomized refresh interval to a value randomly chosen within an implementation-specific range. Such a range MUST fall within 50% to 150% of the refresh interval.
クライアントが30秒未満で状態を満了したNATの背後にある場合、この要件が問題となる可能性があります。任意間隔決意手順（[RFC4380]のセクション5.2.7）も、30秒以下の間隔を提供しません。したがって、この文書では、最初のパラメータが設定可能であるべきで、デフォルトは30秒でなければならないと言って行動を洗練します。実装は、ランダムに実装固有の範囲内で選択された値にランダム化された更新間隔を設定してもよいです。そのような範囲は、リフレッシュ間隔の150％まで50％内に入らなければなりません。
Section 5.2.5 of [RFC4380] states that:
[RFC4380]のセクション5.2.5と述べています：
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;
定期的に、クライアントは、少なくとも1つのパケットが最後のランダム化のTeredo更新間隔で受信されたことを確認するために、「Teredoサーバーとの最後の対話の日付と時刻」をチェックしなければなりません。そうでない場合は、セクション5.2.1で指定されるように、クライアントは、サーバにルータ要請メッセージを送信する必要があります。
This document refines the behavior as follows. A Teredo client MAY choose to send additional router solicitation messages to the server at other implementation-specific times. (For example, an implementation might choose to do so when its Neighbor Cache Entry for the router is in the PROBE state.)
次のようにこの文書では、振る舞いを洗練します。 Teredoクライアントは、他の実装固有の時間にサーバーに追加のルータ要請メッセージを送信するために選ぶかもしれません。 （ルータのためにその近隣キャッシュエントリはPROBE状態にあるとき、例えば、実装はそうすることを選択するかもしれません。）
A Teredo client MUST process the sequence of trailers in the same order as they appear in the packet. If the Teredo client does not recognize the trailer Type while processing the trailers in the Teredo packet, the client MUST discard the packet if the highest-order bits of the trailer Type contain 01, or else the Teredo client MUST skip past the trailer. A Teredo client MUST stop processing the trailers as soon as a malformed trailer appears in the sequence of trailers in the packet. A trailer is defined as malformed if it has any of the following properties:
彼らは、パケットに現れるようTeredoクライアントは、同じ順序でトレーラーのシーケンスを処理しなければなりません。 Teredoのパケットでトレーラーを処理している間に、Teredoクライアントがトレーラーの種類を認識しない場合、トレーラータイプの最上位ビットは01が含まれている場合、クライアントはパケットを捨てなければなりません、または他のTeredoクライアントは、トレーラーをスキップしなければなりません。 Teredoクライアントはすぐに不正な形式のトレーラーは、パケット内のトレーラーの順に表示されるトレーラーの処理を停止しなければなりません。それは、次のプロパティのいずれかを持っている場合、トレーラは、不正な形式のように定義されます。
o The length in bytes of the remainder of the UDP datagram is less than 2 (the size of the Type and Length fields of a trailer).
O UDPデータグラムの残りのバイト単位の長さは2未満（トレーラーのタイプと長さフィールドのサイズ）です。
o The length in bytes of the remainder of the UDP datagram is less than 2 + the value of the Length field of the trailer.
O UDPデータグラムの残りのバイト長は、トレーラーの長さフィールドの2未満の+値です。
Section 5.2.1 of [RFC4380] advises that no Teredo IPv6 address be configured if the Teredo client is positioned behind a symmetric NAT. For Teredo clients positioned behind symmetric NATs, the mapped address/port used by its NAT when communicating with a Teredo peer is different from the mapped address/port embedded in the Teredo client's Teredo IPv6 address. The Symmetric NAT Support Extension provides a solution to this problem.
[RFC4380]のセクション5.2.1には、Teredoクライアントが対称型NATの背後に配置されている場合は何のTeredoのIPv6アドレスが設定されていないことを助言します。対称NATの背後に配置Teredoクライアントは、Teredoのピアと通信するときに、そのNATによって使用されるマッピングされたアドレス/ポートは、TeredoクライアントのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートと異なっています。対称型NATサポート拡張は、この問題に対する解決策を提供します。
In addition, Section 5.2.9 of [RFC4380] specifies a direct IPv6 connectivity test to determine that the mapped address/port in the Teredo IPv6 address of a peer is not spoofed. It does this through the use of a nonce in ICMPv6 Echo Request and Response messages (which are defined in Section 4 of [RFC4443]). However, the direct IPv6 connectivity test is limited only to communication between Teredo IPv6 addresses and non-Teredo IPv6 addresses. In the following extension, we introduce the use of a nonce in direct and indirect bubbles and provide a mechanism to verify that the mapped address/port are not spoofed.
また、[RFC4380]のセクション5.2.9は、ピアのTeredoのIPv6アドレスにマッピングされたアドレス/ポートがスプーフィングされていないことを決定するために直接IPv6接続テストを指定します。それはICMPv6エコー要求メッセージと応答メッセージでノンスを使用することによってこれを行い（[RFC4443]のセクション4で定義されています）。しかし、直接IPv6接続テストのみのTeredo IPv6アドレス及び非TeredoのIPv6アドレスとの間の通信に限定されます。次の拡張では、我々は、直接および間接的な泡でナンスの使用を導入し、マッピングされたアドレス/ポートが偽装されていないことを検証するメカニズムを提供します。
This extension is optional; an implementation SHOULD support it.
この拡張はオプションです。実装は、それをサポートする必要があります。
This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.
このセクションでは、実装は、このプロトコルに参加するために維持可能なデータ編成の概念モデルを記載しています。説明組織は、プロトコルがどのように動作するかの説明を容易にするために提供されます。この文書では、実装がいる限り彼らの外部の振舞いが本書に記載されたものと一致しているとして、このモデルに準拠することを強制しません。
In addition to the state specified in Section 5.2 of [RFC4380], the following are also required.
[RFC4380]のセクション5.2で指定された状態に加えて、以下も必要です。
Peer Entry: The following additional state is required on a per-peer basis:
ピアエントリ：以下の追加の状態は、ピアごとに必要とされます。
o Nonce Sent: The value of the nonce sent in the last indirect bubble sent to the Teredo peer.
O nonceが送信：Teredoのピアに送信された最後の間接的なバブルで送信されたナンスの値。
o Nonce Received: The value of the nonce received in the last indirect bubble received from the Teredo peer.
Oナンス受付：ナンスの値は、Teredoのピアから受信した最後の間接的なバブルで受け取りました。
No timers are necessary other than those in [RFC4380].
いいえタイマーは[RFC4380]のもの以外必要ありません。
No initialization is necessary other than that specified in [RFC4380].
いいえ初期化は[RFC4380]で指定された以外の必要はありません。
Except as specified in the following sections, the rules for message processing are as specified in [RFC4380].
以下のセクションで指定されている場合を除き、[RFC4380]で指定されるように、メッセージ処理のための規則です。
The rules for when indirect bubbles are sent to a Teredo peer are specified in Section 5.2.6 of [RFC4380]. When a Teredo client sends an indirect bubble, it MUST generate a random 4-byte value and include it in the Nonce field of a Nonce Trailer (Section 4.2) appended to the indirect bubble, and also store it in the Nonce Sent field of its Peer Entry for that Teredo peer.
間接的な気泡がTeredoのピアに送信されたときのための規則は、[RFC4380]のセクション5.2.6で指定されています。 Teredoクライアントが間接バブルを送信するとき、ランダム4バイトの値を生成し、間接的なバブルに付加ノンストレーラー（セクション4.2）のナンスフィールドに含まれ、また、そののノンス送信済みフィールドに格納する必要がありますそのTeredoのピアのピアエントリ。
The rules for when direct bubbles are sent to a Teredo peer are specified in Section 5.2.6 of [RFC4380]. When a Teredo client sends a direct bubble to a peer after receiving an indirect bubble with a Nonce Trailer, it MUST include in the direct bubble a Nonce Trailer with the same nonce value.
直接気泡がTeredoのピアに送信されたときのための規則は、[RFC4380]のセクション5.2.6で指定されています。 Teredoクライアントがナンストレーラーと間接的なバブルを受けた後、ピアに直接泡を送信すると、それが直接バブルに同じノンス値とナンストレーラーを含まなければなりません。
If the Teredo client is about to send a direct bubble before it has received an indirect bubble from the Teredo peer, the Teredo client MUST NOT include a Nonce Trailer.
それはTeredoのピアからの間接的なバブルを受け取る前に、Teredoクライアントが直接バブルを送信しようとしている場合は、Teredoクライアントは、ノンストレーラーを含んではいけません。
The rules for processing an indirect bubble are specified in Section 5.2.3 of [RFC4380]. In addition, when a Teredo client receives an indirect bubble containing a Nonce Trailer, the Teredo client MUST store the nonce in the Nonce Received field of its Peer Entry for that Teredo peer. If an indirect bubble is received without a Nonce Trailer, and the Nonce Received field in the Peer Entry is non-zero, the Nonce Received field SHOULD be set to zero.
間接的なバブルを処理するためのルールは、[RFC4380]のセクション5.2.3で指定されています。 Teredoクライアントは、ノンストレーラーを含む間接的なバブルを受信した場合に加えて、Teredoクライアントは、Teredoのピアのピアエントリのノンス受信電界にnonceを記憶しなければなりません。間接気泡がノンストレーラーなしで受信され、ピアエントリのノンス受信電界がゼロでない場合、ノンスは、フィールドがゼロに設定されるべきである受信しました。
If the mapped address/port of the direct bubble matches the mapped address/port embedded in the source Teredo IPv6 address, the direct bubble MUST be accepted, as specified in Section 5.2.3 of [RFC4380].
直接バブルのマッピングされたアドレス/ポートがソースTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートと一致する場合は、[RFC4380]のセクション5.2.3で指定されるように、直接バブルは、受け入れなければなりません。
In addition, if the mapped address/port does not match the embedded address/port but the direct bubble contains a Nonce Trailer with a nonce that matches the Nonce Sent field of the Teredo peer, the direct bubble MUST be accepted.
マッピングされたアドレス/ポートが埋め込まれたアドレス/ポートと一致しないが、直接バブルのTeredoピアのノンス送信済みフィールドに一致ノンスとノンストレーラーが含まれている場合に加えて、直接バブルを受け入れなければなりません。
If neither of the above conditions is true, the direct bubble MUST be dropped.
上記の条件のいずれにも該当しない場合、直接泡を下げなければなりません。
If the direct bubble is accepted, the Teredo client MUST record the mapped address/port from which the direct bubble is received in the mapped address/port fields of the Teredo peer, as specified in Section 5.2 of [RFC4380].
直接バブルが受け入れられた場合、Teredoクライアントは、[RFC4380]のセクション5.2で指定されるように、直接気泡がTeredoのピアのマップされたアドレス/ポートフィールドで受信されたマッピングされたアドレス/ポートを記録しなければなりません。
The UPnP-enabled Symmetric NAT Extension is optional; an implementation SHOULD support it. This extension has the Symmetric NAT Support Extension (Section 5.2) as a dependency. Any node that implements this extension MUST also implement the Symmetric NAT Support Extension.
UPnP対応NAT対称拡張はオプションです。実装は、それをサポートする必要があります。この拡張は、依存関係として対称NATサポート拡張（5.2節）を持っています。この拡張機能を実装している任意のノードは、対称型NATサポート拡張を実装しなければなりません。
This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.
このセクションでは、実装は、このプロトコルに参加するために維持可能なデータ編成の概念モデルを記載しています。説明組織は、プロトコルがどのように動作するかの説明を容易にするために提供されます。この文書では、実装がいる限り彼らの外部の振舞いが本書に記載されたものと一致しているとして、このモデルに準拠することを強制しません。
This extension extends the abstract data model in Section 5.2.1 by adding the following additional fields.
この拡張は、次の追加フィールドを追加することにより、5.2.1での抽象データモデルを拡張します。
UPnP-Enabled NAT flag: This is a Boolean value, set to TRUE if the NAT positioned in front of the Teredo client is UPnP enabled. The default value of this flag is FALSE.
UPnP対応NATフラグ：Teredoクライアントの前に配置NATがUPnPが有効になっている場合、これはTRUEに設定するブール値です。このフラグのデフォルト値はFALSEです。
UPnP-Mapped Address/Port: The mapped address/port assigned via UPnP to the Teredo client by the UPnP-enabled NAT behind which the Teredo client is positioned. Note that this field has a valid value only if the NAT to which the Teredo client is connected is UPnP enabled. Also, note that if the Teredo client is positioned behind a single NAT only (as opposed to a series of nested NATs), this value is the same as the mapped address/port embedded in its Teredo IPv6 address.
UPnPのマップアドレス/ポート：Teredoクライアントが位置している背後にUPnP対応NATにより、TeredoクライアントへのUPnP経由で割り当てられたマッピングされたアドレス/ポート。 Teredoクライアントが接続しているNATがUPnPが有効になっている場合のみ、このフィールドが有効な値を持っていることに注意してください。また、Teredoクライアントは、単一のNAT（ネストのNATの一連のとは対照的に）の背後に配置されている場合、この値は、そのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートと同じであることに注意してください。
Symmetric NAT flag: This is a Boolean value, set to TRUE if the Teredo client is positioned behind a symmetric NAT.
対称型NATフラグ：これは、Teredoクライアントが対称型NATの背後に配置されている場合はTRUEに設定するブール値です。
Peer Entry: The following state needs to be added on a per-peer basis:
ピア・エントリは、次の状態はピアごとに追加する必要があります。
o Symmetric Peer flag: This is a Boolean value and is TRUE if the Teredo peer is positioned behind a symmetric NAT.
O対称ピアフラグ：これはブール値であるとTeredoピアが、対称NATの背後に配置されている場合はTRUEです。
A Teredo client SHOULD also maintain the following state that is persisted across reboots:
Teredoクライアントも再起動しても保持され、次の状態を維持する必要があります。
o Persisted UPnP-Mapped Port: The mapped port assigned via UPnP to the Teredo client by the UPnP-enabled NAT behind which the Teredo client is positioned. Note that this value is the same as the UPnP-Mapped Port value when both are non-zero. The default value is all zero bytes.
O永続のUPnP-マッピングされたポート：Teredoクライアントが配置されるの後ろにUPnP対応NATにより、TeredoクライアントへのUPnP経由で割り当てられたマッピングされたポート。この値は、両方が非ゼロでのUPnPマッピングポート値と同じであることに留意されたいです。デフォルト値はすべてゼロバイトです。
No timers are necessary other than those in [RFC4380].
いいえタイマーは[RFC4380]のもの以外必要ありません。
Prior to beginning the qualification procedure, the Teredo client MUST first perform the uninitialization procedure specified in Section 5.3.5.1 if the Persisted UPnP-Mapped Port is supported and non-zero.
資格の手続きを開始する前に、Teredoクライアントは、最初の永続のUPnP-マッピングされたポートがサポートされており、ゼロでない場合、セクション5.3.5.1で指定された非初期化手順を実行しなければなりません。
The Teredo client MUST then invoke the AddPortMapping function, as specified in Section 2.4.16 of [UPNPWANIP], with the following parameters:
【UPNPWANIP]のセクション2.4.16に指定されているTeredoクライアントは、次いで、以下のパラメータを用いて、AddPortMapping関数を呼び出す必要があります。
o NewRemoteHost: "" (empty string)
O NewRemoteHost： ""（空の文字列）
o NewExternalPort: Local Port value
O NewExternalPort：ローカルポート値
o NewProtocol: UDP
NewProtocol O：UDP
o NewInternalPort: Local Port value
O NewInternalPort：ローカルポート値
o NewInternalClient: Local Address value
O NewInternalClient：ローカルアドレス値
o NewEnabled: TRUE
O NewEnabled：TRUE
o NewPortMappingDescription: "TEREDO"
O NewPortMappingDescription： "TEREDO"
o NewLeaseDuration: 0
O NewLeaseDuration：0
The successful completion of the AddPortMapping function indicates that the NAT has created a port mapping from the external port of the NAT to the internal port of the Teredo client node. The parameters are specified so that any external host should be able to send packets to the Teredo client by sending packets to the mapped address/port. If the AddPortMapping function fails, the Teredo client MUST continue without using this extension. Otherwise, it MUST proceed as follows.
AddPortMapping機能が正常に完了は、NATがTeredoクライアントノードの内部ポートにNATの外部ポートからのポートマッピングを作成したことを示します。任意の外部ホストがマッピングされたアドレス/ポートにパケットを送信することにより、Teredoクライアントにパケットを送信することができるはずようにパラメータが指定されています。 AddPortMapping関数が失敗した場合、Teredoクライアントは、この拡張機能を使用せずに継続する必要があります。次のようにそれ以外の場合は、続行しなければなりません。
The Teredo client MUST set the UPnP-Mapped Port (and Persisted UPnP-Mapped Port, if supported) to the Local Port value specified in AddPortMapping. The Teredo client MUST then call the GetExternalIPAddress function specified in Section 2.4.18 of [UPNPWANIP]. If the GetExternalIPAddress function fails, the Teredo client SHOULD perform the uninitialization procedure specified in Section 5.3.5.1 and continue without using this extension. If the GetExternalIPAddress function succeeds, the Teredo client MUST proceed as follows.
（サポートされている場合、および永続のUPnP-マッピングされたポート）、TeredoクライアントはAddPortMappingで指定されたローカルポート値にUPnPのマッピングされたポートを設定しなければなりません。 Teredoクライアントは、[UPNPWANIP]のセクション2.4.18で指定GetExternalIPAddress関数を呼び出す必要があります。 GetExternalIPAddress関数が失敗した場合、Teredoクライアントは、セクション5.3.5.1で指定された非初期化手順を実行し、この拡張機能を使用せずに継続する必要があります。 GetExternalIPAddress関数が成功すると、以下のように、Teredoクライアントは続行しなければなりません。
The Teredo client MUST set the UPnP-Mapped Address to the address returned from the GetExternalIPAddress function, and set the UPnP-Enabled NAT flag to TRUE.
TeredoクライアントはアドレスへのUPnPマップアドレスはGetExternalIPAddress関数から返されたセット、およびTRUEにUPnP対応NATフラグを設定しなければなりません。
During the qualification procedure (as specified in Section 5.2.1 of [RFC4380]) when the Teredo client receives a response from the secondary Teredo server, the Teredo client MUST compare the mapped address/port learned from the secondary Teredo server with the mapped address/port associated with the Teredo server. If either the mapped address or the mapped port value is different, the Symmetric NAT flag MUST be set to TRUE.
TeredoクライアントがセカンダリTeredoサーバーからの応答を受信した場合（[RFC4380]のセクション5.2.1で指定されるように）認定手順の間に、Teredoクライアントは、マップされたアドレス/ポートがマッピングされたアドレスとセカンダリTeredoサーバーから学習比較する必要があります/ Teredoサーバーに関連付けられたポート。マッピングされたアドレスまたはマッピングされたポートの値のいずれかが異なる場合、対称NATフラグをTRUEに設定しなければなりません。
After the qualification procedure, the mapped address/port learned from the Teredo server MUST be compared to the UPnP-Mapped Address/ Port. If both are the same, the Teredo client is positioned behind a single NAT and the UPnP-Mapped Address/Port MUST be zeroed out.
資格の手続きの後、マッピングされたアドレス/ポートは、UPnP-マッピングアドレス/ポートと比較されなければならないTeredoサーバーから学びました。両者が同じであれば、Teredoクライアントは、単一のNATの背後に配置されているとUPnPマップアドレス/ポートをゼロにしなければなりません。
Except as specified in the following sections, the rules for message processing are as specified in Section 5.2.3 of [RFC4380].
以下のセクションで指定されている場合を除き、[RFC4380]のセクション5.2.3で指定されるように、メッセージ処理のための規則です。
Except as indicated below, the rules for handling a direct bubble are as specified in Section 5.2.4.4.
以下に示すよう除き、直接泡を処理するための規則は、セクション5.2.4.4で指定されています。
A Teredo client positioned behind a UPnP-enabled NAT (port-restricted NAT as well as symmetric NAT) will receive all packets sent to the mapped address/port embedded in its Teredo IPv6 address. Thus, when a Teredo client receives a direct bubble, it MUST compare the mapped address/port from which the packet was received with the mapped address/port embedded in the Teredo IPv6 address in the source address field of the IPv6 header. If the two are not the same, it indicates that the Teredo peer is positioned behind a symmetric NAT, and it MUST set the Symmetric Peer flag in its Peer Entry.
UPnP対応NAT（ポート制限NATと同様に対称NAT）の後方に位置Teredoクライアントは、そのTeredoのIPv6アドレスに埋め込まれてマッピングされたアドレス/ポートに送信されたすべてのパケットを受信します。 Teredoクライアントが直接バブルを受信した場合従って、そのパケットは、IPv6ヘッダのソースアドレスフィールド内のTeredo IPv6アドレスに埋め込まれたマッピングされたアドレス/ポートで受信されたマッピングされたアドレス/ポートを比較しなければなりません。 2つが同じでない場合、それはTeredoのピアが、対称NATの背後に配置されていることを示し、それはピアエントリに対称ピアフラグを設定しなければなりません。
The rules for sending a direct bubble are specified in Section 5.2.6 of [RFC4380] and Section 5.2.4.2 of this document. These rules are further refined as follows.
直接バブルを送信するためのルールは、[RFC4380]のセクション5.2.6とこのドキュメントのセクション5.2.4.2に規定されています。次のようにこれらのルールは、さらに洗練されています。
If the Teredo client sending the direct bubble meets all of the following criteria:
直接バブルを送信Teredoクライアントは、次の基準のすべてを満たしている場合：
o The Symmetric NAT flag is set to TRUE.
O対称NATフラグがTRUEに設定されています。
o The UPnP-Enabled NAT flag is set to TRUE.
O UPnP対応NATフラグがTRUEに設定されています。
o The UPnP-Mapped Address/Port are set to zero.
UPnPのマップアドレスのO /ポートはゼロに設定されています。
o The peer's Symmetric Peer flag is set to TRUE.
Oピアの対称ピアフラグがTRUEに設定されています。
then the Teredo client MUST send the direct bubble to the mapped address/port embedded in the peer's Teredo IPv6 address.
その後、Teredoクライアントは、ピアのTeredoのIPv6アドレスに埋め込まれてマッピングされたアドレス/ポートへの直接バブルを送らなければなりません。
This is because Symmetric-to-Symmetric and Port-Restricted-to-Symmetric NAT communication between the Teredo client and the peer would have failed anyway. However, by taking a chance that the peer might also be positioned behind a UPnP-enabled NAT just like the Teredo client itself, the Teredo client can try sending the direct bubble to the mapped address/port in the peer's Teredo IPv6 address. If the packet does go through, communication is established.
Teredoクライアントとピア間の対称対対称とポート制限付きツー対称NATの通信がとにかく失敗しただろうからです。しかし、相手もちょうどTeredoクライアント自体のようなUPnP対応NATの後ろに配置されるかもしれないというチャンスを取ることで、Teredoクライアントは、ピアのTeredoのIPv6アドレスにマッピングされたアドレス/ポートへの直接バブルを送信してみてくださいすることができます。パケットが通過しなければ、通信が確立されています。
The rules for sending a data packet are specified in Section 5.2.4 of [RFC4380]. These rules are further refined as follows.
データパケットを送信するためのルールは、[RFC4380]のセクション5.2.4で指定されています。次のようにこれらのルールは、さらに洗練されています。
If the Teredo client sending the data packet meets all of the following criteria:
データパケットを送信Teredoクライアントは、次の基準のすべてを満たしている場合：
o The Symmetric NAT flag is set to TRUE.
O対称NATフラグがTRUEに設定されています。
o The UPnP-Enabled NAT flag is set to TRUE.
O UPnP対応NATフラグがTRUEに設定されています。
o The UPnP-Mapped Address/Port are set to zero.
UPnPのマップアドレスのO /ポートはゼロに設定されています。
o The peer's Symmetric Peer flag is set to TRUE.
Oピアの対称ピアフラグがTRUEに設定されています。
then the Teredo client MUST send the data packet to the mapped address/port embedded in the peer's Teredo IPv6 address.
その後、Teredoクライアントは、ピアのTeredoのIPv6アドレスに埋め込まれてマッピングされたアドレス/ポートへのデータパケットを送らなければなりません。
When Teredo client functionality is being shut down, uninitialization MUST be performed as specified in Section 5.3.5.1.
Teredoクライアント機能がシャットダウンされている場合は、セクション5.3.5.1に指定されているように、初期化解除を実行しなければなりません。
First determine the mapped port as follows. If Persisted UPnP-Mapped Port is supported, use it as the mapped port. Otherwise, use the UPnP-Mapped Port.
次のように最初にマッピングされたポートを決定します。永続のUPnP-マッピングされたポートがサポートされている場合は、マッピングされたポートとして使用します。それ以外の場合は、UPnPのマッピングされたポートを使用します。
If the mapped port is non-zero, the Teredo client MUST call the DeletePortMapping function, as specified in Section 2.4.17 of [UPNPWANIP], with the following parameters:
マッピングされたポートが非ゼロである場合[UPNPWANIP]のセクション2.4.17に指定されるように、Teredoクライアントは、以下のパラメータを用いて、DeletePortMapping関数を呼び出す必要があります。
o NewRemoteHost: "" (empty string)
O NewRemoteHost： ""（空の文字列）
o NewExternalPort: the mapped port
O NewExternalPort：マッピングされたポート
o NewProtocol: UDP
NewProtocol O：UDP
The Port-Preserving Symmetric NAT Extension is optional; an implementation SHOULD support it. This extension has the Symmetric NAT Support Extension (as specified in Section 5.2) as a dependency. Any node that implements this extension MUST also implement the Symmetric NAT Support Extension.
ポート・保存対称NAT拡張はオプションです。実装は、それをサポートする必要があります。依存関係として（5.2節に指定されている）この拡張は、対称型NATサポート拡張を持っています。この拡張機能を実装している任意のノードは、対称型NATサポート拡張を実装しなければなりません。
This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.
このセクションでは、実装は、このプロトコルに参加するために維持可能なデータ編成の概念モデルを記載しています。説明組織は、プロトコルがどのように動作するかの説明を容易にするために提供されます。この文書では、実装がいる限り彼らの外部の振舞いが本書に記載されたものと一致しているとして、このモデルに準拠することを強制しません。
The Port-Preserving Symmetric NAT Extension extends the abstract data model in Section 5.2.1 by adding the following additional fields.
ポート・保存対称NAT拡張には、以下の追加フィールドを追加することにより、5.2.1での抽象データモデルを拡張します。
Port-Preserving NAT flag: This is a Boolean value, set to TRUE if the Teredo client is positioned behind a port-preserving NAT.
NATフラグをポート-保存：これは、Teredoクライアントがポート保存NATの背後に配置されている場合はTRUEに設定するブール値です。
Symmetric NAT flag: This is a Boolean value, set to TRUE if the Teredo client is positioned behind a symmetric NAT.
対称型NATフラグ：これは、Teredoクライアントが対称型NATの背後に配置されている場合はTRUEに設定するブール値です。
Peer Entry: The following fields need to be added on a per-peer basis:
ピアエントリ：次のフィールドは、ピアごとに追加する必要があります。
o Random Port: This field contains the value of the external port that the Teredo client predicts that its NAT has assigned it for communication with the peer. Set to zero by default.
Oランダムポート：このフィールドには、TeredoクライアントがNATがピアとの通信のためにそれを割り当てたことを予測した外部ポートの値が含まれています。デフォルトでゼロに設定してください。
o Peer Random Port: This field contains the value of the random port that the peer is using for communication with this Teredo client. Set to zero by default.
Oランダムポートピア：このフィールドは、ピアが、このTeredoクライアントとの通信に使用されるランダムなポートの値が含まれています。デフォルトでゼロに設定してください。
o Direct Receive on Primary Port: This is a Boolean value, set to TRUE if a packet is received from the Teredo peer on the primary local port. Set to FALSE by default.
Oダイレクトは、プライマリポートで受信：これは、パケットがプライマリローカルポート上のTeredoピアから受信した場合にTRUEに設定するブール値です。デフォルトではfalseに設定してください。
o Direct Receive on Random Port: This is a Boolean value, set to TRUE if a packet is received from the Teredo peer on the Random Port. Set to FALSE by default.
Oダイレクトランダムポートで受信：これは、パケットがランダムポート上のTeredoピアから受信した場合にTRUEに設定するブール値です。デフォルトではfalseに設定してください。
o Connection Refresh Count: This field contains the number of direct bubbles that have been sent to the peer since the last time data was sent to the peer.
O接続のリフレッシュカウント：このフィールドは、データがピアに送信された前回のピアに送信された直接の泡の数が含まれています。
o Last Data Packet Sent Timestamp: This field contains the timestamp of the last data packet sent to the peer. This timestamp is different from the field that stores the data and time of last transmission to the peer (as specified in Section 5.2 of [RFC4380]) because the RFC-defined field is also updated every time a direct bubble is sent.
O最後のデータパケットが送信されたタイムスタンプ：このフィールドは、ピアに送信された最後のデータパケットのタイムスタンプが含まれています。このタイムスタンプはRFCに定義されたフィールドは、直接バブルが送信されるたびに更新されるため、データおよびピアへの最後の送信の時間（[RFC4380]のセクション5.2で指定されるように）格納するフィールドとは異なります。
Other than those in [RFC4380], the Port-Preserving Symmetric NAT Extension requires the following additional timer.
[RFC4380]のもの以外にも、ポート・保存対称NAT拡張は、次の追加のタイマーが必要です。
Peer Refresh Timer: A timer to refresh peer connections through the random port, on which no data has been sent for a while.
リフレッシュタイマピア：データがしばらくの間送信されませんされたランダムなポートを介して、ピア接続をリフレッシュするためにタイマーを。
When the Peer Refresh Timer expires, the Teredo client MUST go through its list of peers and for each peer to which the Teredo client is communicating through the random port, the Teredo client MUST check the Last Data Packet Sent Timestamp to determine if data has been sent to the peer in the last 30 seconds, and check the Connection Refresh Count field to determine if the count has reached the maximum allowed value of 20. If both checks are FALSE, the Teredo client MUST send a direct bubble (as specified in Section 5.4.4.3) to the peer and increment the Connection Refresh Count. This direct bubble is sent as an attempt to keep the port mappings on all the intermediate NATs alive while the application/ user may be temporarily inactive. If on the other hand, data has been sent to the peer in the last 30 seconds, the Connection Refresh Count MUST be reset to zero.
ピアリフレッシュタイマが満了した場合、Teredoクライアントは、ピアのリストを通過し、それぞれのMUST Teredoクライアントがランダムポートを介して通信しているためにどのピア、Teredoクライアントは、最後のデータ・パケットをチェックしなければなりませんデータがされているかどうかを判断するためにタイムスタンプを送信最後の30秒で相手に送信され、両方のチェックがFALSEの場合はカウントが20の最大許容値に達しているかどうかを判断するための接続更新Countフィールドをチェックし、セクションで指定されているように、Teredoクライアントは、（直接泡を送らなければなりませんピアへの5.4.4.3）との接続の更新カウントをインクリメント。この直接的なバブルは、アプリケーション/ユーザーは、一時的に不活性であり得る一方で生きているすべての中間のNATにポートマッピングを維持しようとする試みとして送信されます。一方、データは最後の30秒で相手に送信された場合は、接続更新カウントがゼロにリセットされなければなりません。
The Peer Refresh Timer MUST then be rescheduled to expire in 30 seconds.
ピアリフレッシュタイマを30秒で期限切れになるように再スケジュールされなければなりません。
In addition to the behavior specified in [RFC4380], the Port-Preserving NAT flag and Symmetric NAT flag MUST be set to FALSE when the Teredo client is started. The Peer Refresh Timer MUST be started and scheduled to expire in 30 seconds.
Teredoクライアントの起動時に[RFC4380]で指定された動作に加えて、ポート保存NATフラグと対称NATフラグをfalseに設定する必要があります。ピアリフレッシュタイマを開始し、30秒で終了する予定でなければなりません。
During the qualification procedure (as specified in Section 5.2.1 of [RFC4380]), when the Teredo client receives a response from the Teredo server address, the Teredo client MUST compare the Port value in the origin indication, as specified in Section 5.1.1 of [RFC4380], with the Local Port value. If both values match, the client MUST set the Port-Preserving NAT flag to TRUE.
TeredoクライアントがTeredoサーバーアドレスからの応答を受信すると認定手順（[RFC4380]のセクション5.2.1で指定されるように）中、Teredoクライアントは、セクション5.1で指定されるように、原点指示にポート値を比較しなければなりません。ローカルポート値を使用して、[RFC4380]の1、。両方の値が一致する場合、クライアントはTRUEにポート保存NATフラグを設定しなければなりません。
On receiving a data packet to be transmitted to the Teredo peer (in addition to the rules specified in Section 5.2.4 of [RFC4380]), the Teredo client MUST update the Last Data Packet Sent Timestamp when the packet is actually sent.
Teredoのピアに送信されるデータパケットを受信する（[RFC4380]のセクション5.2.4で指定された規則に加えて）、Teredoクライアントは、最後のデータ・パケットを更新しなければならないパケットが実際に送信されたときにタイムスタンプを送りました。
The rules for sending an indirect bubble are as specified in Section 5.2.4.1 of this document and Section 5.2.6 of [RFC4380]. In addition to those rules, if the Port-Preserving NAT flag is TRUE, the Teredo client MUST do the following:
[RFC4380]この文書およびセクション5.2.6のセクション5.2.4.1で指定された間接バブルを送信するためのルールです。ポート・保存NATフラグがTRUEの場合、それらのルールに加えて、Teredoクライアントには、以下を行う必要があります。
o If the Symmetric NAT flag is set, the Teredo peer is not marked as "trusted" (as specified in Section 5.2 of [RFC4380]), and the Random Port is zero, the Teredo client MUST first select a random port number to use, and then begin listening on that port. Since the NAT is port-preserving, the Teredo client can predict that the external port assigned will be equal to the random port chosen, and hence the Teredo client MUST store the random port chosen in the Random Port field of the Peer Entry.
対称型NATフラグが設定されているO場合は、（[RFC4380]の5.2節で指定）のTeredoピアが「信頼できる」としてマークされていない、とランダムポートがゼロで、Teredoクライアントは、最初に使用するポート番号をランダムに選択する必要があります、その後、そのポートでリッスンを開始します。 NATは、ポート・保存されているので、Teredoクライアントは、割り当てられた外部ポートが選択したランダムなポートに等しくなることを予測することができ、ひいてはTeredoクライアントは、ピアエントリのランダムポート]フィールドで選択されたランダムなポートを保存しなければなりません。
o If the Random Port value is non-zero, the Teredo client MUST append a Random Port Trailer to the indirect bubble.
ランダムポートの値がゼロでない場合、O、Teredoクライアントは、間接的なバブルにランダムなポートトレーラーを追加しなければなりません。
The rules for when direct bubbles are sent to a Teredo peer are as specified in Section 5.2.6 of [RFC4380]. In addition, Section 5.2.4.2 defines rules for enabling communication for clients positioned behind a symmetric NAT. In addition to the rules defined in both the aforementioned sections, if the Port-Preserving NAT flag is TRUE, the following rules apply also.
[RFC4380]のセクション5.2.6で指定されるように直接気泡がTeredoのピアに送信されたときのためのルールです。また、セクション5.2.4.2は、対称NATの背後に位置するクライアントのための通信を可能にするための規則を定義します。ポート保存NATフラグがTRUEの場合、前述のセクションの両方で定義された規則に加えて、以下の規則も適用されます。
If the Symmetric NAT flag is set, and the Teredo peer is not marked as "trusted" (as specified in Section 5.2 of [RFC4380]) the Teredo client MUST send a direct bubble destined to the mapped address/port embedded in the Teredo IPv6 address of the Teredo peer. If the peer Random Port field is non-zero, the Teredo client MUST send another direct bubble from its own random port, destined to the peer random port. The IPv4 destination address MUST be the mapped address embedded in the Teredo IPv6 address. In addition, the Teredo client MUST include the Random Port Trailer (Section 4.5).
対称型NATフラグがセットされ、TeredoのIPv6の中に埋め込まれたマップされたアドレス/ポート宛のダイレクトバブルを送らなければなりませんTeredoクライアント（[RFC4380]の5.2節で指定）のTeredoピアは、「信頼できる」としてマークされていない場合Teredoのピアのアドレス。ピアランダムポートフィールドがゼロでない場合、Teredoクライアントは、ピアのランダムなポート宛の独自のランダムポートから別の直接のバブルを送らなければなりません。 IPv4宛先アドレスがTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレスでなければなりません。また、Teredoクライアントは、ランダムなポートトレーラー（4.5節）を含まなければなりません。
The rules for processing an indirect bubble are as specified in Section 5.2.4.3 of this document and Section 5.2.3 of [RFC4380]. In addition to these rules, if the incoming indirect bubble has a Random Port Trailer, the following additional processing MUST be done.
[RFC4380]この文書およびセクション5.2.3のセクション5.2.4.3で指定された間接バブルを処理するためのルールです。入ってくる間接的なバブルがランダムなポートトレーラーを持っている場合は、これらのルールに加えて、以下の追加の処理が行われなければなりません。
If the Peer Random Port field of the Peer Entry is zero, the Teredo client MUST store the port from the Random Port Trailer in the Peer Random Port field of the Peer Entry.
ピアエントリのピアランダムポート]フィールドがゼロの場合、Teredoクライアントは、ピアエントリのピアランダムPortフィールドにランダムポートトレーラーからポートを保存しなければなりません。
If the Peer Random Port field is non-zero and if either the Peer Random Port field and the new advertised port have the same value, or if active data has been exchanged between the two Teredo clients in the last 30 seconds (that is, "time of last transmission" or "time of last reception", as specified in Section 5.2 of [RFC4380], is set to a time that is less than 30 seconds ago), the new advertised port value MUST be ignored.
「ピアランダムポート]フィールドには、ゼロでないと、ピアランダムポートフィールドと新しいアドバタイズされたポートのいずれかが同じ値を持っている場合、またはアクティブなデータは（最後の30秒で2つのTeredoクライアント間で交換された場合には、ある場合には最後の送信」または 『最後の受信の時間』の時間、[RFC4380]の5.2節で指定されるように、）30秒未満前の時間に設定され、新しい広告を出してポート値は無視されなければなりません。
If the Peer Random Port field is non-zero and the new advertised port value is different from the Peer Random Port value, and it has been more than 30 seconds since the last exchange of data packets between the two Teredo clients, (that is, "time of last transmission" and "time of last reception" are set to a time that is more than 30 seconds ago), the Teredo client SHOULD store the new advertised port value in the Peer Random Port field and, if the Port-Preserving NAT flag is TRUE, then clear the Random Port field, and stop listening on the old random port. This allows communication to be re-established if either side changes the random port that it is using.
ピアランダムポートフィールドが非ゼロであり、新しい広告を出してポートの値がピアランダムなポート値とは異なる、それは2つのTeredoクライアント間のデータパケットの最後の為替以来、30秒以上となっている場合には、（つまり、 「最後の送信の時間」と「最後の受信の時間」）は、30秒以上前の時間に設定されている、Teredoクライアントは、ピアランダムPortフィールドに新しい広告を出してポートの値を格納する必要がありますと、ポート保存場合NATフラグがTRUEである場合、ランダムポート]フィールドをクリアし、古いランダムなポートでリッスンを停止します。これは、どちらの側は、それが使用されるランダムポートを変更した場合、通信が再確立されることを可能にします。
The rules for handling direct bubbles are specified in Section 5.2.4.4 of this document and Section 5.2.3 of [RFC4380]. The rules for whether to accept a direct bubble are extended as follows, when the Port-Preserving NAT flag is TRUE:
直接気泡を処理するためのルールは、このドキュメントと[RFC4380]のセクション5.2.3のセクション5.2.4.4に規定されています。直接バブルを受け入れるかどうかについての規則は、ポート保存NATフラグがTRUEのとき、次のように拡張されています。
o If the direct bubble is received on the primary port and the Teredo peer is not "trusted", the status field of the Teredo client MUST be changed to "trusted" and the Direct Receive on Primary Port flag MUST be set to TRUE. The mapped address/port from which the direct bubble was received MUST be recorded in the mapped address/port fields of the Teredo peer, as specified in Section 5.2 of [RFC4380]. The Teredo client MUST then set the Random Port field in the Peer Entry to zero and stop listening on the old random port.
直接気泡がプライマリポートで受信したとのTeredoピアは「信頼」でない場合、O、Teredoクライアントのステータスフィールドは、「信頼できる」に変更しなければならないとの直接のプライマリポートフラグを受信trueに設定する必要があります。 [RFC4380]のセクション5.2で指定されるように直接気泡が受信されたマッピングされたアドレス/ポートは、Teredoのピアのマップされたアドレス/ポートフィールドに記録されなければなりません。 Teredoクライアントはゼロにピアエントリにランダムポート]フィールドを設定し、古いランダムなポートでリッスンを停止しなければなりません。
o If the direct bubble is received on the primary port, the Teredo peer is "trusted", and the Direct Receive on Primary flag is set to TRUE, the Teredo client MUST compare the mapped address/port of the direct bubble with the mapped address/port of the Peer Entry. If both mappings are the same, the direct bubble MUST be accepted. If the mappings are different and it has been more than 30 seconds since the last packet exchange with the Teredo peer (that is, "time of last transmission" and "time of last reception", as defined in Section 5.2 of [RFC4380], are set to a time that is more than 30 seconds ago), the mapping on the Teredo peer's NAT has changed and communication needs to be re-established. This MUST be done by changing the status of the peer to "not-trusted", setting the Direct Receive on Primary Port flag to FALSE, and sending an indirect bubble to the Teredo peer via its Teredo server.
直接バブルがプライマリポートで受信されている場合は、O、Teredoのピアは「信頼」であり、直接プライマリフラグに受信がTRUEに設定され、Teredoクライアントは、マップされたアドレスに直接バブルのマッピングされたアドレス/ポートを比較する必要があります/ピアエントリのポート。両方のマッピングが同じであれば、直接バブルが受け入れなければなりません。マッピングが異なっており、それはTeredoのピアとの最後のパケット交換のため30秒以上であった場合は[RFC4380]のセクション5.2で定義されるように、（すなわち、「最後の送信の時間」であり、「最終受信時刻」、 30秒以上前である時間）に設定され、TeredoのピアのNATのマッピングが変更され、通信が再確立する必要がありました。これは直接はFALSEにプライマリポートフラグを受信し、そのTeredoサーバー経由でのTeredoピアに間接的なバブルを送信設定「 - 信頼されていない」ために、ピアのステータスを変更することによって行われなければなりません。
o If the direct bubble is received on the primary port, the Teredo peer is "trusted", the Direct Receive on Primary Port flag is set to FALSE, and the Direct Receive on Random Port flag is set to TRUE, the mapped address/port from which the direct bubble is received MUST be stored in the mapped address/port fields of the Peer Entry. The Direct Receive on Primary Port flag MUST be set to TRUE. The Teredo client MUST then set the Random Port field in the Peer Entry to zero and stop listening on the old random port. Finally, the Direct Receive on Random Port flag MUST be set to FALSE.
直接バブルがプライマリポートで受信されている場合は、O、Teredoのピアは、直接には、プライマリポートフラグを受け取る「信頼」であるがFALSEに設定されており、直接はTRUEに設定されているランダムポートフラグに受信され、マッピングされたアドレス/ポート直接バブルが受信されたピアエントリのマッピングされたアドレス/ポートフィールドに格納されなければなりません。直接は、プライマリポートフラグを受信trueに設定する必要があります。 Teredoクライアントはゼロにピアエントリにランダムポート]フィールドを設定し、古いランダムなポートでリッスンを停止しなければなりません。最後に、直接には、ランダムなポートフラグに受信falseに設定する必要があります。
o If the direct bubble is received on the random port and the Teredo peer is not "trusted", the status field of the Teredo client MUST be changed to "trusted" and the Direct Receive on Random Port flag MUST be set to TRUE. The mapped address/port from which the direct bubble was received MUST be recorded in the mapped address/ port fields of the Teredo Peer Entry, as specified in Section 5.2 of [RFC4380].
直接の気泡がランダムポートで受信とのTeredoピアは「信頼」でない場合、O、Teredoクライアントのステータスフィールドは、「信頼できる」に変更する必要がありますし、直接はランダムなポートフラグに受信trueに設定する必要があります。 [RFC4380]のセクション5.2で指定されるように直接気泡が受信されたマッピングされたアドレス/ポートは、Teredoのピアエントリのマッピングされたアドレス/ポートフィールドに記録されなければなりません。
o If the direct bubble is received on the random port, the Teredo peer is "trusted", and the Direct Receive on Primary Port flag is FALSE, the Teredo client MUST compare the mapped address/port in the direct bubble with the mapped address/port in the Peer Entry. If the two mappings are the same, the direct bubble MUST be accepted. If the mappings are different, it implies that the NAT had deleted the mapping and when it reassigned the mapping, a different external port was chosen. In this instance, the Teredo client SHOULD set the Random Port field to zero, stop listening on the old random port, and send an indirect bubble to the Teredo peer as specified in Section 5.4.4.2.
直接のバブルがランダムなポートで受信されている場合は、O、Teredoのピアは「信頼」であり、直接にはプライマリポートフラグがFALSEであるに受信、Teredoクライアントがマッピングされたアドレスに直接泡にマップされたアドレス/ポートを比較する必要があります/ピアエントリでポート。 2つのマッピングが同じであれば、直接バブルが受け入れなければなりません。マッピングが異なっている場合には、NATマッピングを削除していたし、それがマッピングを再割り当てする場合、異なる外部ポートが選ばれたことを意味します。この例では、Teredoクライアントは、ゼロにランダムポート]フィールドを設定し、古いランダムなポートでリッスンを停止し、セクション5.4.4.2に指定されているのTeredoピアに間接的なバブルを送るべきです。
Note that once the Direct Receive on Primary Port flag is TRUE, the client will stop listening on the random port and hence a direct bubble cannot be received on the random port. As a result, this case is intentionally omitted above.
ダイレクトプライマリポートフラグに受け取ったらTRUEであることに注意してください、クライアントはランダムなポートでリッスンを停止しますので、直接のバブルがランダムなポートで受信することはできません。結果として、この場合は、意図的に上記省略されています。
The Sequential Port-Symmetric NAT Extension is optional; an implementation SHOULD support it. This extension has the Symmetric NAT Support Extension (Section 5.2) as a dependency. Any node that implements this extension MUST also implement the Symmetric NAT Support Extension, as well as the Port-Preserving NAT Extension (Section 5.4).
シーケンシャルポート対称NAT拡張はオプションです。実装は、それをサポートする必要があります。この拡張は、依存関係として対称NATサポート拡張（5.2節）を持っています。この拡張機能を実装している任意のノードは、対称型NATサポート拡張を実装するだけでなく、ポート・保存NAT拡張（5.4節）しなければなりません。
This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.
このセクションでは、実装は、このプロトコルに参加するために維持可能なデータ編成の概念モデルを記載しています。説明組織は、プロトコルがどのように動作するかの説明を容易にするために提供されます。この文書では、実装がいる限り彼らの外部の振舞いが本書に記載されたものと一致しているとして、このモデルに準拠することを強制しません。
The Sequential Port-Symmetric NAT Extension extends the abstract data model in Section 5.4.1 by adding the following additional state.
シーケンシャルポート対称NAT拡張は、次の追加状態を追加することによって、セクション5.4.1における抽象データモデルを拡張します。
Peer Entry: The following fields need to be added on a per-peer basis:
ピアエントリ：次のフィールドは、ピアごとに追加する必要があります。
o EchoTestNonce1: The value of the nonce sent as part of the authentication encapsulation, as specified in Section 5.1.1 of [RFC4380], in the router solicitation packet sent to the Teredo server address as part of the Echo Test.
EchoTestNonce1（O）エコーテストの一部としてTeredoサーバーアドレスに送信されたルータ要請パケットに、[RFC4380]のセクション5.1.1で指定されるようにノンス値は、認証のカプセル化の一部として送信されます。
o EchoTestNonce2: The value of the nonce sent as part of the authentication encapsulation in the router solicitation packet sent to the secondary Teredo server address as part of the Echo Test.
EchoTestNonce2○：一回だけの値は、エコーテストの一部として、二次Teredoサーバーアドレスに送信されたルータ要請パケットに認証カプセル化の一部として送信されます。
o EchoTestLowerPort: The value of the external port mapping extracted from the origin indication of the router advertisement received from the Teredo server address as part of the Echo Test. A value of 0 indicates that no such router advertisement has been received.
O EchoTestLowerPort：エコーテストの一部としてTeredoサーバーのアドレスから受信したルータ広告の原点指示から抽出された外部ポートマッピングの値。 0の値は、そのようなルータ広告を受信していないことを示しています。
o EchoTestUpperPort: The value of the external port mapping extracted from the origin indication of the router advertisement received from the secondary Teredo server address as part of the Echo Test. A value of 0 indicates that no such router advertisement has been received.
O EchoTestUpperPort：エコーテストの一部として、二次Teredoサーバーのアドレスから受信したルータ広告の原点指示から抽出された外部ポートマッピングの値。 0の値は、そのようなルータ広告を受信していないことを示しています。
o EchoTestRetryCounter: The number of times an Echo Test has been attempted.
O EchoTestRetryCounter：エコーテストが試みられた回数。
In addition to the timers specified in Section 5.4.2, the following additional timer is required per Peer Entry.
5.4.2節で指定されたタイマーに加えて、以下の追加のタイマーがピアエントリごとに必要です。
Echo Test Failover Timer: A one-shot timer that runs whenever an Echo Test is in progress.
エコーテストフェールオーバーのタイマー：エコーテストが進行中である場合に常に実行されるワンショットタイマ。
The processing of the Peer Refresh Timer Expiry MUST be completed as specified in Section 5.4.2.1. In addition to those rules, the Teredo client MUST set the EchoTestLowerPort, EchoTestUpperPort, and EchoTestRetryCounter to zero.
セクション5.4.2.1で指定されたピアリフレッシュタイマ満了の処理が完了しなければなりません。これらのルールに加えて、TeredoクライアントはゼロにEchoTestLowerPort、EchoTestUpperPort、およびEchoTestRetryCounterを設定しなければなりません。
If the Echo Test Failover Timer expires, the Teredo client MUST do the following.
エコーテストフェールオーバーのタイマーが期限切れになった場合は、Teredoクライアントは、次の操作を実行しなければなりません。
If the value of the EchoTestRetryCounter is two, then the Teredo client MUST send an indirect bubble as specified in Section 5.2.4.1.
EchoTestRetryCounterの値が2である場合、セクション5.2.4.1で指定され、その後、Teredoクライアントは、間接的なバブルを送らなければなりません。
If the value of the EchoTestRetryCounter is one, then the Teredo client MUST start another Echo Test as specified in Section 5.5.4.1.1.
EchoTestRetryCounterの値が1である場合、セクション5.5.4.1.1で指定され、その後、Teredoクライアントは、別のエコーテストを開始する必要があります。
No behavior changes are required beyond what is specified in Section 5.4.3.
いいえ動作の変更は、5.4.3項で指定されている以上必要ありません。
Except as specified in the following sections, the rules for message processing are as specified in Section 5.4.4.
次のセクションで指定されている以外は、セクション5.4.4で指定されるように、メッセージ処理のための規則です。
Whenever [RFC4380] or other extensions specified in this document specify that an indirect bubble is to be sent, the following actions apply at that time instead if the Symmetric NAT flag is TRUE and the Port-Preserving NAT flag is FALSE. Note that any behavior specified by [RFC4380] or other extensions in this document still applies to how indirect bubbles are constructed, but such behavior is done at a later time as specified in Section 5.5.4.4.
たび[RFC4380]や、この文書で指定された他の拡張機能の間接的なバブルが送信されることを指定する対称型NATフラグがTRUEであるとPort-保存NATフラグがFALSEである場合、次のアクションではなく、その時点で適用されます。 [RFC4380]またはこの文書に記載されている他の拡張機能で指定されたすべての行動はまだ気泡が構築されているか、間接的に適用されるが、そのような行動は、セクション5.5.4.4に指定された後に行われることに注意してください。
If the Symmetric NAT flag is TRUE, and the Port-Preserving NAT flag is FALSE, and the Teredo peer is not marked as "trusted" (as specified in Section 5.2 of [RFC4380]), and the Random Port is zero, then the Teredo client MUST select a random port number to use, begin listening on that port, and start an Echo Test as specified below.
対称型NATフラグがTRUEで、かつポート・保存NATフラグがFALSEで、Teredoのピアは、その後、（[RFC4380]の5.2節で指定されるように）「信頼できる」としてマークされ、ランダムポートがゼロであるされていない場合Teredoクライアントは、使用するポート番号をランダムに選択し、そのポートでリッスンを開始し、以下の指定されたエコーテストを開始する必要があります。
To start an Echo Test, the Teredo client MUST send the following three packets from this port:
エコーテストを開始するには、Teredoクライアントは、このポートから、次の3つのパケットを送信する必要があります。
o First, a router solicitation (as specified in Section 5.2.1 of [RFC4380]) MUST be sent to the Teredo server address. The router solicitation MUST include an authentication encapsulation with a randomly generated Nonce field, as specified in Section 5.1.1 of [RFC4380]. The nonce included in the authentication encapsulation MUST then be stored in the EchoTestNonce1 field of the Peer Entry.
Oまず、ルータ要請（[RFC4380]のセクション5.2.1で指定されるように）は、Teredoサーバーのアドレスに送信されなければなりません。 [RFC4380]のセクション5.1.1で指定されるようにルータ要請は、ランダムに生成されたNonceフィールドとの認証カプセル化を含まなければなりません。認証カプセルに含まれるノンスは、ピアエントリのEchoTestNonce1フィールドに格納されなければなりません。
o Second, a direct bubble MUST be sent to the peer.
O第二に、直接バブルはピアに送らなければなりません。
o Third, a router solicitation MUST be sent to the secondary Teredo server address. The router solicitation MUST include an authentication encapsulation with a randomly generated Nonce field, as specified in Section 5.1.1 of [RFC4380]. The nonce included in the authentication encapsulation MUST then be stored in the EchoTestNonce2 field of the Peer Entry.
O第三に、ルータ要請は、二次Teredoサーバーアドレスに送らなければなりません。 [RFC4380]のセクション5.1.1で指定されるようにルータ要請は、ランダムに生成されたNonceフィールドとの認証カプセル化を含まなければなりません。認証カプセルに含まれるノンスは、ピアエントリのEchoTestNonce2フィールドに格納されなければなりません。
The Teredo client MUST then increment the EchoTestRetryCounter and set the Echo Test Failover Timer to expire in a number of seconds equal to EchoTestRetryCounter.
Teredoクライアントは、EchoTestRetryCounterをインクリメントし、EchoTestRetryCounterに等しい秒数で期限切れになるように、エコーテストフェールオーバーのタイマーを設定しなければなりません。
The rules for sending an indirect bubble are as specified in Section 5.2.4.1 of this document and Section 5.2.6 of [RFC4380]. In addition to those rules, if the Symmetric NAT flag is TRUE, and the Port-Preserving NAT flag is FALSE, and the Random Port value is non-zero, then the Teredo client MUST append a Random Port Trailer to the indirect bubble.
[RFC4380]この文書およびセクション5.2.6のセクション5.2.4.1で指定された間接バブルを送信するためのルールです。これらのルールに加えて、場合対称NATフラグがTRUEで、かつポート・保存NATフラグがFALSEで、ランダムなポート値はゼロで、その後、Teredoクライアントが間接的なバブルにランダムなポートトレーラーを追加しなければなりません。
The processing of the direct bubble MUST be completed as specified in Section 5.4.4.5, as if the Port-Preserving NAT flag were TRUE. After the processing is complete, if the Direct Bubble Received on Primary flag is TRUE, and the Echo Test Failover Timer is running, then the Echo Test Failover Timer MUST be canceled and EchoTestLowerPort, EchoTestUpperPort, and EchoTestRetryCounter MUST be set to zero.
ポート・保存NATフラグがTRUEであるかのように、セクション5.4.4.5に指定されている直接バブルの処理が完了しなければなりません。処理が完了した後直接バブルがTRUEであり、エコーテストフェイルオーバタイマが実行されているプライマリフラグを受け取った場合、次にエコーテストフェイルオーバタイマをキャンセルしなければならなくて、EchoTestLowerPort、EchoTestUpperPort、及びEchoTestRetryCounterをゼロに設定しなければなりません。
The rules for processing a router advertisement are as specified in Section 5.2.1 of [RFC4380]. In addition to those rules, if the router advertisement contains an authentication encapsulation, the Teredo client MUST look for a Peer Entry whose EchoTestNonce1 or EchoTestNonce2 field matches the nonce in the authentication encapsulation. If a Peer Entry is found, the Teredo client MUST do the following.
[RFC4380]のセクション5.2.1で指定されるようにルータ通知を処理するためのルールです。ルータ広告が認証カプセル化が含まれている場合、それらのルールに加えて、Teredoクライアントは、そのEchoTestNonce1またはEchoTestNonce2フィールド認証のカプセル化にナンスと一致するピアエントリのために見なければなりません。ピアエントリが見つかった場合、Teredoクライアントは、次の操作を実行しなければなりません。
If the received nonce is equal to EchoTestNonce1 and EchoTestLowerPort is zero, then EchoTestLowerPort MUST be set to the external port mapping extracted from the origin indication of this router advertisement.
受信nonceがEchoTestNonce1に等しく、EchoTestLowerPortがゼロである場合、EchoTestLowerPortこのルータ広告の原点指示から抽出された外部ポートマッピングに設定しなければなりません。
If the received nonce is equal to EchoTestNonce2 and EchoTestUpperPort is zero, then EchoTestUpperPort MUST be set to the external port mapping extracted from the origin indication of this router advertisement.
受信nonceがEchoTestNonce2に等しく、EchoTestUpperPortがゼロである場合、EchoTestUpperPortこのルータ広告の原点指示から抽出された外部ポートマッピングに設定しなければなりません。
If the EchoTestUpperPort and EchoTestLowerPort are now both non-zero, the Teredo client MUST then set the Random Port field of the Peer Entry to (EchoTestUpperPort + EchoTestUpperPort)/2, rounded down, and send an indirect bubble as specified in Section 5.5.4.2.
EchoTestUpperPortとEchoTestLowerPortは今、両方の非ゼロの場合、Teredoクライアントは、その後、（EchoTestUpperPort + EchoTestUpperPort）/ 2にピアエントリのランダムポート]フィールドを設定し切り捨てて、セクション5.5.4.2で指定された間接的なバブルを送らなければなりません。
This extension is optional; an implementation SHOULD support it.
この拡張はオプションです。実装は、それをサポートする必要があります。
This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.
このセクションでは、実装は、このプロトコルに参加するために維持可能なデータ編成の概念モデルを記載しています。説明組織は、プロトコルがどのように動作するかの説明を容易にするために提供されます。この文書では、実装がいる限り彼らの外部の振舞いが本書に記載されたものと一致しているとして、このモデルに準拠することを強制しません。
In addition to the state specified in Section 5.2 of [RFC4380], the following are also required:
[RFC4380]のセクション5.2で指定された状態に加えて、以下も必要です。
UPnP Mapped Address/Port: The mapped address/port assigned via UPnP to the Teredo client by the UPnP-enabled NAT behind which the Teredo client is positioned. This field has a valid value only if the NAT to which the Teredo client is connected is UPnP enabled. In addition, if the Teredo client is positioned behind a single NAT only (as opposed to a series of nested NATs), this value will be the same as the mapped address/port embedded in its Teredo IPv6 address.
Teredoクライアントが配置されるの後ろにUPnP対応NATにより、TeredoクライアントへのUPnP経由で割り当てられたマッピングされたアドレス/ポート：UPnPは、アドレス/ポートをマップされました。このフィールドには、Teredoクライアントが接続しているNATがUPnPが有効になっている場合にのみ有効な値を持っています。 Teredoクライアントが（ネストのNATの一連のとは対照的に）単一のNATの背後に配置されている場合に加えて、この値は、TeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートと同じになります。
Peer Entry: Per-peer state is extended beyond what is described in [RFC4380] by including the following:
ピアエントリ：当たりピア状態は、以下を含むことによって、[RFC4380]に記載されているものを越えて拡張されます。
o Alternate Address/Port list: The list of alternate address/port pairs advertised by the peer.
O代替アドレス/ポートのリスト：ピアによってアドバタイズ代替アドレス/ポートのペアのリスト。
No timers are necessary other than those in [RFC4380].
いいえタイマーは[RFC4380]のもの以外必要ありません。
Behavior is as specified in [RFC4380], with the following additions.
以下の追加で、[RFC4380]で指定されるように動作します。
Prior to beginning the qualification procedure, the Teredo client MUST invoke the AddPortMapping function (as specified in Section 2.4.16 of [UPNPWANIP]) with the parameters specified in Section 5.3.3. If successful, it indicates that the NAT has created a port mapping from the external port of the NAT to the internal port of the Teredo client node. If the AddPortMapping function is successful, the Teredo client MUST store the mapping assigned by the NAT in its UPnP Mapped Address/Port state.
認定手順を開始する前に、Teredoクライアントはセクション5.3.3で指定されたパラメータを用いて（[UPNPWANIP]のセクション2.4.16に指定されるように）AddPortMapping関数を呼び出す必要があります。成功した場合、それはNATがTeredoクライアントノードの内部ポートにNATの外部ポートからのポートマッピングを作成したことを示します。 AddPortMapping関数が成功した場合、Teredoクライアントは、そのUPnPのマッピングアドレス/ポートの状態にNATによって割り当てられたマッピングを保存しなければなりません。
After the qualification procedure, the mapped address/port learned from the Teredo server MUST be compared to the UPnP Mapped Address/ Port. If both are the same, the Teredo client is positioned behind a single NAT and the UPnP Mapped Address/Port MUST be zeroed out.
資格の手続きの後、マッピングされたアドレス/ポートは、UPnPマッピングアドレス/ポートと比較されなければならないTeredoサーバーから学びました。両者が同じであれば、Teredoクライアントは、単一のNATの背後に配置されているとUPnPマッピングアドレス/ポートをゼロにしなければなりません。
The rules for when indirect bubbles are sent to a Teredo peer are as specified in Section 5.2.6 of [RFC4380]. If communication between a Teredo client and a Teredo peer has not been established, the Teredo client MUST include the Alternate Address Trailer in the indirect bubble. The Alternate Address Trailer MUST include the node's local address/port in the Alternate Address/Port list. If the UPnP Mapped Address/Port is non-zero, the Alternate Address Trailer MUST also include it in the list.
[RFC4380]のセクション5.2.6で指定された間接気泡がTeredoのピアに送信されたときのためのルールです。 TeredoクライアントとTeredoのピア間の通信が確立されていない場合は、Teredoクライアントは、間接的なバブルで代替アドレストレーラーを含まなければなりません。代替アドレストレーラーは代替アドレス/ポート・リスト内のノードのローカルアドレス/ポートを含まなければなりません。 UPnPのマッピングアドレス/ポートがゼロでない場合、代替アドレストレーラーもリストに含めなければなりません。
Hairpinning requires "direct IPv6 connectivity tests" (as specified in Section 5.2.9 of [RFC4380]) to succeed before it can accept packets from an IPv4 address and port not embedded in the Teredo IPv6 address. Hence, the indirect bubble MUST also include a Nonce Trailer.
ヘアピニングは、TeredoのIPv6アドレスに埋め込まれていないIPv4アドレスとポートからのパケットを受け入れることができます前に、成功するために（[RFC4380]のセクション5.2.9に指定されている）「直接IPv6接続テスト」を必要とします。このため、間接的なバブルもナンストレーラーを含まなければなりません。
The rules for processing indirect bubbles are as specified in Section 5.2.3 of [RFC4380]. In addition to those rules, when a Teredo client receives an indirect bubble with the Alternate Address Trailer, it SHOULD first verify that the Alternate Address Trailer is correctly formed (as specified in Section 4.3), and drop the bubble if not. Otherwise, it MUST set the Alternate Address/Port list in its Peer Entry to the list in the trailer. The Teredo client, besides sending direct bubbles to the mapped address/port embedded in the Teredo IPv6 address (as specified in Section 5.2.6 of [RFC4380]), MUST also send a direct bubble to each mapped address/port advertised in the Alternate Address Trailer.
[RFC4380]のセクション5.2.3で指定された間接気泡を処理するためのルールです。これらのルールに加えて、Teredoクライアントが代替アドレストレーラーと間接的なバブルを受信したとき、それは最初（4.3節で指定）代替アドレストレーラーが正しく形成されていることを確認する必要があり、そうでない場合、バブルをドロップします。それ以外の場合は、トレーラー内のリストにそのピアエントリに代替アドレス/ポートのリストを設定しなければなりません。 Teredoクライアントは、TeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポート（[RFC4380]のセクション5.2.6で指定されるように）に直接気泡を送信する以外に、また代替でアドバタイズ各マッピングされたアドレス/ポートに直接バブルを送らなければなりませんアドレストレーラー。
In each of the direct bubbles, the Teredo client MUST include a Nonce Trailer with the nonce value received in the indirect bubble.
直接気泡の各々において、Teredoクライアントは、間接バブルで受信したnonce値とノンストレーラーを含まなければなりません。
If the mapped address/port of the direct bubble matches the mapped address/port embedded in the source Teredo IPv6 address, the direct bubble MUST be accepted, as specified in Section 5.2.3 of [RFC4380].
直接バブルのマッピングされたアドレス/ポートがソースTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートと一致する場合は、[RFC4380]のセクション5.2.3で指定されるように、直接バブルは、受け入れなければなりません。
If the mapped address/port does not match the embedded address/port, but the direct bubble contains a Nonce Trailer with a nonce that matches the Nonce Sent field of the Teredo peer, the direct bubble MUST be accepted.
マッピングされたアドレス/ポートが埋め込まれたアドレス/ポートと一致していませんが、直接バブルがTeredoのピアのナンス送信済みフィールドと一致ナンスとナンスのトレーラーが含まれている場合は、直接バブルが受け入れなければなりません。
If neither of the above rules match, the direct bubble MUST be dropped.
上記のルールのいずれもが一致した場合は、直接泡を下げなければなりません。
This extension is optional; an implementation SHOULD support it.
この拡張はオプションです。実装は、それをサポートする必要があります。
This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.
このセクションでは、実装は、このプロトコルに参加するために維持可能なデータ編成の概念モデルを記載しています。説明組織は、プロトコルがどのように動作するかの説明を容易にするために提供されます。この文書では、実装がいる限り彼らの外部の振舞いが本書に記載されたものと一致しているとして、このモデルに準拠することを強制しません。
In addition to the state specified in Section 5.2 of [RFC4380], the following are also required.
[RFC4380]のセクション5.2で指定された状態に加えて、以下も必要です。
Peer Entry: The following state needs to be added on a per-peer basis:
ピア・エントリは、次の状態はピアごとに追加する必要があります。
o Count of Solicitations Transmitted: The number of Solicitation packets sent.
O透過要請の数：送信された要請パケットの数を。
Retransmission Timer: A timer used to retransmit Teredo Neighbor Solicitation packets.
再送信タイマー：Teredoの近隣要請パケットを再送信するために使用されるタイマ。
When the retransmission timer expires, the Teredo client MUST retransmit a direct bubble with a Neighbor Discovery Option Trailer, and increment the Count of Solicitations Transmitted. If the count is less than three, it MUST then reset the timer to expire in two seconds. Otherwise (if the count is now three), it MUST send an indirect bubble to the Teredo peer to re-establish connectivity as if no communication between the Teredo client and the Teredo peer had been established.
再送タイマが満了した場合には、Teredoクライアントは、近隣探索オプショントレーラーとの直接バブルを再送信、および透過要請の件数を増加しなければなりません。カウントが3未満の場合、それはその後、2秒で期限切れになるようにタイマーをリセットする必要があります。 （カウントは今3の場合）それ以外の場合は、TeredoクライアントとTeredoのピア間の通信が確立されていなかったかのように接続を再確立するのTeredoピアに間接的なバブルを送らなければなりません。
No initialization is necessary other than that specified in [RFC4380].
いいえ初期化は[RFC4380]で指定された以外の必要はありません。
Except as specified below, processing is the same as specified in [RFC4380].
以下に指定されている場合を除き、処理は[RFC4380]で指定されたものと同じです。
Upon receiving a data packet to be transmitted to the Teredo peer, the Teredo client MUST determine whether data has been exchanged between the Teredo client and peer in either direction in the last 30 seconds (using the state as specified in Section 5.2 of [RFC4380]). If not, the Teredo client MUST send a direct bubble with a Neighbor Discovery Option Trailer having the DiscoveryType field set to TeredoDiscoverySolicitation. The Count of Solicitations Transmitted field MUST be set to 1. The retransmission timer MUST be set to expire in two seconds.
Teredoのピアに送信されるデータパケットを受信すると、Teredoクライアントは、[RFC4380]のセクション5.2で指定された状態を使用して（データが最後の30秒のいずれかの方向にTeredoクライアントとピアとの間で交換されたかどうかを決定しなければなりません）。そうでない場合、TeredoクライアントはTeredoDiscoverySolicitationに設定DiscoveryTypeフィールドを持つ近隣探索オプショントレーラーと直接バブルを送らなければなりません。要請透過フィールドのカウントは、再送タイマーが2秒で期限切れになるように設定しなければならない1に設定しなければなりません。
The rules for processing direct bubbles are as specified in Section 5.2.3 of [RFC4380]. In addition to those rules, upon receiving a direct bubble containing a Neighbor Discovery Option Trailer with DiscoveryType field set to TeredoDiscoverySolicitation, the Teredo client MUST respond with a direct bubble with the Neighbor Discovery Option Trailer having the DiscoveryType field set to TeredoDiscoveryAdvertisement.
[RFC4380]のセクション5.2.3で指定されるように直接気泡を処理するためのルールです。これらのルールに加えて、TeredoDiscoverySolicitationに設定DiscoveryTypeフィールドと近隣探索オプショントレーラーを含む直接バブルを受信すると、TeredoクライアントはTeredoDiscoveryAdvertisementに設定DiscoveryTypeフィールドを有する近隣探索オプショントレーラーと直接バブルで応答しなければなりません。
The following sections describe several operations as used in common scenarios to illustrate the function of Teredo Extensions.
Teredoの拡張の機能を説明するために一般的なシナリオで使用される以下のセクションでは、いくつかの動作を記述しています。
The following protocol example illustrates the use of the Symmetric NAT Support Extension.
次のプロトコルの例では、対称型NATサポート拡張の使用を示します。
In Figure 2 (Section 3.1), assume that Teredo Client A, which is positioned behind a port-symmetric NAT, wants to communicate with Teredo Client B, which is positioned behind an address-restricted NAT.
図2（セクション3.1）において、ポート対称NATの背後に配置されているTeredoクライアントAが、アドレス制限NATの背後に配置されるのTeredoクライアントBと通信することを望むと仮定する。
The qualification procedure where the Teredo client determines that it is positioned behind a symmetric NAT is exactly the same as that specified in Section 5.2.1 of [RFC4380]. Because of the Symmetric NAT Extension, Client A continues to configure a Teredo IPv6 address even after determining that the Teredo client is positioned behind a symmetric NAT.
Teredoクライアントは、それが対称NATの背後に配置されていると判断認定手順は、[RFC4380]のセクション5.2.1で指定されたものと全く同じです。対称NAT拡張のため、クライアントのAでも、Teredoクライアントが対称型NATの背後に配置されていることを決定した後、TeredoのIPv6アドレスを設定し続けています。
Next the following packet exchange helps Teredo Client A (A) establish communication with Teredo Client B (B).
次のパケット交換横TeredoクライアントA（A）は、TeredoクライアントのB（B）との通信を確立するのに役立ちます。
Teredo Client A's Client B's Teredo
Client Teredo Teredo Client
A NAT Server Server NAT B
| | | | | |
| | | Direct Bubble to B | | |
1 |--------------------------------------------------->| |
| | | | | |
|Indirect Bubble to B via B's Teredo Server| | |
2 |----------------------------------------->|----------------->|
| | | | | |
| | | Direct Bubble to A | | |
| |<--------------------------------------------------| 3
| | | | | |
| | |Indirect Bubble to A via A's Teredo Server|
|<-----------------|<-----------------------------------------| 4
| | | | | |
| | | Direct Bubble to B | | |
5 |------------------------------------------------------------>|
| | | | | |
|Indirect Bubble to B via B's Teredo Server| | |
6 |----------------------------------------->|----------------->|
| | | | | |
| | | Direct Bubble to A | | |
|<------------------------------------------------------------| 7
| | | | | |
Port-Symmetric NAT to Address-Restricted NAT Packet
Exchange
1. A sends a direct bubble (Packet 1) destined to the mapped address/port embedded in B's Teredo IPv6 address. The mapped port in the source field of the packet assigned by Client A's NAT is different from the mapped port embedded in A's Teredo IPv6 address. This is characteristic of the port-symmetric NAT positioned in front of A. The mapped address in the source field of the packet is the same as the mapped address embedded in the Teredo IPv6 address of A.
1. AはBのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポート宛直接バブル（パケット1）を送信します。クライアントAのNATによって割り当てられたパケットの送信元フィールドにマッピングされたポートは、AのTeredoのIPv6アドレスに埋め込まれてマッピングされたポートと異なります。これは、パケットのソースフィールドにマッピングされたアドレスは、AのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレスと同じであるAの前方に位置するポート対称NATの特徴であります
2. The aforementioned direct bubble is dropped by B's NAT because it has not seen an outgoing packet destined to A's mapped IPv4 address.
それはAのマッピングされたIPv4アドレス宛の送信パケットを見ていないので、2前述の直接バブルがBのNATによってドロップされます。
3. A sends an indirect bubble (Packet 2) destined to B via Client B's Teredo server.
3. Aは、クライアントBのTeredoサーバーを経由してBに宛て間接バブル（パケット2）を送信します。
4. The above-mentioned indirect bubble is received by B. B then responds with the following packets. The first packet sent by B is a direct bubble (Packet 3) destined to the mapped address/ port embedded in A's Teredo IPv6 address.
4.上記間接気泡がB. Bによって受信される次のパケットで応答します。 Bによって送信された最初のパケットはAのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポート宛直接バブル（パケット3）です。
5. The above-mentioned direct bubble is dropped by A's NAT because the NAT has not seen any outgoing packet sourced from the mapped address/port embedded in A's Teredo IPv6 address and destined to the mapped address/port embedded in B's Teredo IPv6 address.
NATは、マッピングされたアドレス/ポートAのTeredoのIPv6アドレス内に埋め込まれ及びBのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートを宛先から発信任意の発信パケットを見ていないので、5上記直接バブルは、AのNATによってドロップされます。
6. B also sends an indirect bubble (Packet 4) destined to A via A's Teredo Server.
6. BもAのTeredoサーバーを介し宛間接バブル（パケット4）を送信します。
7. The aforementioned indirect bubble is successfully received by A. A responds to the indirect bubble with its own direct bubble (Packet 5). This direct bubble is exactly the same as the first direct bubble (Packet 1) sent by A.
7.正常A. Aによって受信される前述の間接バブルは、それ自身の直接バブル（パケット5）との間接的なバブルに応答します。この直接バブルは、Aによって送られた最初の直接バブル（パケット1）と全く同じです
8. This time around the aforementioned direct bubble is accepted by B's NAT because the NAT has seen an outgoing packet (Packet 3) sourced from the mapped address/port embedded in B's Teredo IPv6 address and destined to the mapped address/port embedded in A's Teredo IPv6 address. It is important to remember that A's NAT is port-symmetric and therefore varies only the mapped port while the mapped address remains the same. B's NAT is address-restricted and cares only about prior communication with the IPv4 address, not the specific port. At this point, communication in one direction is now possible (B to A, but not vice versa).
NATは、マッピングされたアドレス/ポートBのTeredoのIPv6アドレスに埋め込まれ、Aの中に埋め込まれたマッピングされたアドレス/ポートを宛先から発信発信パケット（パケット3）を見ているので、8前述の直接バブル今回は、BのNATによって受け入れられますTeredoのIPv6アドレス。 AのNATは、ポート対称であるため、マッピングされたアドレスは同じままにのみマッピングされたポートを変化させることを覚えておくことが重要です。 BのNATは、アドレス制限で、IPv4アドレスだけではなく、特定のポートとの事前の通信を気に。この時点で、一方向の通信は、現在（AとBはなく、その逆）ことが可能です。
9. After receiving the direct bubble, B remembers the new mapped address/port that was in the source fields of the direct bubble and uses those for future communication with A instead of the mapped address/port embedded in A's Teredo IPv6 address.
9.直接バブルを受信した後、Bは、直接バブルのソース・フィールド中の新しいマッピングされたアドレス/ポートを記憶し、代わりにAのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートとの将来の通信のためにそれらを使用します。
10. A then times out and resends an indirect bubble (Packet 6) and in response, B sends a direct bubble (Packet 7). This direct bubble is destined to the new learned mapped address/port and hence A's NAT permits the direct bubble through. Communication is now possible in the other direction (client A to B).
10. A、次いでタイムアウトと間接バブル（パケット6）を再送し、応答において、Bは、直接バブル（パケット7）を送信します。この直接バブルは新しい学びマッピングされたアドレス/ポートを宛先としているので、AのNATを通じ、直接バブルを可能にします。通信は、他の方向（BにクライアントA）で可能になりました。
The following protocol example illustrates the use of the UPnP-Enabled Symmetric NAT Extension in addition to the Symmetric NAT Support Extension.
次のプロトコルの例は、対称NATサポートの拡張に加えて、UPnP対応対称NAT拡張の使用を示します。
Assume that Teredo Client A, which is positioned behind a UPnP-enabled port-symmetric NAT, wants to communicate with Teredo Client B, which is also positioned behind a UPnP-Enabled port-symmetric NAT.
UPnP対応ポート対称NATの背後に配置されているTeredoクライアントAは、またUPnP対応ポート対称NATの背後に配置されるのTeredoクライアントBと通信することを望むと仮定する。
Before both clients start their qualification procedure, they use UPnP to reserve port mappings on their respective NATs. The UPnP operations succeed for both the clients and the clients hence know that they are positioned behind UPnP-enabled NATs. After the qualification procedure, both clients have valid Teredo IPv6 addresses because they both support the Symmetric NAT Support Extension. Also, after the qualification procedure both clients will compare their mapped address/port determined through UPnP with the mapped address/port determined through the qualification procedure. Because both will be the same, the clients will zero out their UPnP mapped address/port values and conclude that they are each located behind a single UPnP-enabled NAT.
両方のクライアントがその資格手続きを開始する前に、彼らはそれぞれのNATにポートマッピングを確保するためのUPnPを使用しています。 UPnPの操作は、それらがUPnP対応NATの後ろに配置されていることを知っているので、クライアントとクライアントの両方のために成功します。彼らは両方の対称型NATサポート拡張をサポートするため、資格の手続きの後、両方のクライアントが有効なのTeredo IPv6アドレスを持っています。また、資格手続き後の両方のクライアントは、認定手続きを通じて決定マッピングされたアドレス/ポートでのUPnPを通じて決定そのマッピングされたアドレス/ポートを比較します。両者が同じになりますので、クライアントはUPnPはマッピングされたアドレス/ポート値をゼロにし、それらはそれぞれ単一UPnP対応NATの背後に配置されていると結論します。
The following packet exchange shows Teredo client A (A) establishing communication with Teredo client B (B).
次のパケット交換は、TeredoクライアントのB（B）との通信を確立するのTeredoクライアントA（A）を示しています。
Teredo Client A's Client B's Teredo
Client Teredo Teredo Client
A NAT Server Server NAT B
| | | | | |
| | | Direct Bubble to B | | |
1 |------------------------------------------------------------>|
| | | | | |
|Indirect Bubble to B via B's Teredo Server| | |
2 |----------------------------------------->|----------------->|
| | | | | |
| | | Direct Bubble to A | | |
|<------------------------------------------------------------| 3
| | | | | |
UPnP-enabled Symmetric NAT Packet Exchange
対称型NATパケット交換UPnP対応
1. A sends a direct bubble (Packet 1) to the mapped address/port embedded in B's Teredo IPv6 address. Because A's NAT is a symmetric NAT, the UDP source port field in the packet assigned by A's NAT is different from the mapped port embedded in A's Teredo IPv6 address, but the IPv4 source address of the packet is the same as the mapped address embedded in A's Teredo IPv6 address.
1. AはBのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートに直接バブル（パケット1）を送信します。 AのNATが対称型NATであるため、AのNATによって割り当てられたパケット内のUDPソースポートフィールドには、AのTeredoのIPv6アドレスに埋め込まれたマッピングされたポートとは異なるが、パケットのIPv4ソースアドレスに埋め込まれたマッピングされたアドレスと同じですAのTeredoのIPv6アドレス。
2. The above-mentioned direct bubble is received by B because it is destined for the UPnP mapped address/port of B and hence is let through by the NAT. At this point, B deduces that A is positioned behind a symmetric NAT because the mapped address/port from which the direct bubble is received is different from the mapped address/port that is embedded in A's Teredo IPv6 address. Hence, it remembers that the peer is positioned behind a symmetric NAT so that data packets will be sent to the mapped address/port embedded in A's Teredo IPv6 address, rather than the mapped address/port from which the direct bubble was received. At this point, communication in one direction is now possible (B to A, but not vice versa).
UPnPはBのアドレス/ポートをマッピングし、従って、NATによって通過させているため、それが運命づけられているので、2上記直接バブルはBによって受信されます。この時点で、Bは、直接バブルが受信されたマッピングされたアドレス/ポートAのTeredoのIPv6アドレスに埋め込まれているマップされたアドレス/ポートと異なっているので、Aは対称NATの背後に配置されていることを推定します。したがって、データパケットはAのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートではなく、直接バブルが受信されたマッピングされたアドレス/ポートに送信されるように、ピアが、対称NATの背後に配置されていることを覚えています。この時点で、一方向の通信は、現在（AとBはなく、その逆）ことが可能です。
3. A also sends an indirect bubble (Packet 2) destined to B via B's Teredo Server.
3. AもBのTeredoサーバーを経由してBに宛て間接バブル（パケット2）を送信します。
4. The above indirect bubble is received by B. B then responds with a direct bubble (Packet 3) destined to the mapped address/port embedded in A's Teredo IPv6 address, as in step 2.
4. B. Bによって受信される上記間接バブルは、ステップ2のようにAのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポート、宛て直接バブル（パケット3）で応答します。
5. Because A's NAT is also UPnP enabled, the above-mentioned direct bubble is received by A. A also notices that B is positioned behind a Symmetric NAT because the mapped address/port from which the packet is received is different from the mapped address/port embedded in B's Teredo IPv6 address. Hence, it remembers that the peer is positioned behind a symmetric NAT so that data packets will be sent to the mapped address/port embedded in B's Teredo IPv6 address, rather than the mapped address/port from which the direct bubble was received. At this point, communication is now possible in the other direction (A to B).
AのNATはまた、UPnPは有効になって5ので、上記直接バブルはA. Aで受信された、パケットが受信されたマッピングされたアドレス/ポートがマッピングされたアドレスとは異なるため、BがSymmetric NATの背後に配置されていることを気づいています/ BのTeredoのIPv6アドレスに埋め込まれたポート。したがって、データパケットはBのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートではなく、直接バブルが受信されたマッピングされたアドレス/ポートに送信されるように、ピアが、対称NATの背後に配置されていることを覚えています。この時点で、通信は、他の方向（BとA）で可能になりました。
The following protocol example illustrates the use of the Port-Preserving Symmetric NAT Extension.
次のプロトコルの例では、ポート保存対称NAT拡張の使用を示します。
Assume that Teredo Client A (A), which is positioned behind a port-preserving symmetric NAT, wants to communicate with Teredo Client B (B), which is also positioned behind a port-preserving symmetric NAT.
ポート維持対称NATの背後に配置されているTeredoクライアントA（A）は、また、ポート維持対称NATの背後に配置されているTeredoクライアントのB（B）、と通信することを望むと仮定する。
The following packet exchange explains the configuration setup and communication setup between the two clients.
次のパケット交換は2つのクライアント間のコンフィギュレーション設定と通信設定について説明します。
Teredo Client A's Client B's Teredo
Client Teredo Teredo Client
A NAT Server Server NAT B
| | | | | |
| | | Direct Bubble to B | | |
1 |--------------------------------------------------->| |
| | | | | |
|Indirect Bubble to B via B's Teredo Server| | |
2 |----------------------------------------->|----------------->|
| | | | | |
| | | Direct Bubble to A | | |
| |<--------------------------------------------------| 3
| | | | | |
| | | Direct Bubble to A | | |
| |<--------------------------------------------------| 4
| | | | | |
| | |Indirect Bubble to A via A's Teredo Server|
|<-----------------|<-----------------------------------------| 5
| | | | | |
| | | Direct Bubble to B | | |
6 |--------------------------------------------------->| |
| | | | | |
| | | Direct Bubble to B | | |
7 |------------------------------------------------------------>|
| | | | | |
|Indirect Bubble to B via B's Teredo Server| | |
8 |----------------------------------------->|----------------->|
| | | | | |
| | | Direct Bubble to A | | |
|<------------------------------------------------------------| 9
| | | | | |
Port-Preserving Symmetric NAT Packet Exchange
対称型NATパケット交換をポート保存
1. During the qualification procedure, when the clients receive a response from the Teredo server, they compare the Port value in the Origin indication with the Local Port value. If both values match, the clients set the Port-Preserving NAT flag to TRUE.
クライアントがTeredoサーバーからの応答を受信するとき1.資格手順の間、彼らは、ローカルポート値を持つ原産地表示でポートの値を比較します。両方の値が一致する場合、クライアントはTRUEにポート保存NATフラグを設定します。
2. When the response is received from the secondary Teredo server, the mapped address/port value in the Origin indication is compared with the mapped address/port value learned from the response received from the primary server. If the mappings are different, the Symmetric NAT flag is set to TRUE.
2.応答から学習したマッピングされたアドレス/ポートの値がプライマリサーバから受信した応答が二次Teredoサーバーから受信すると、原点指示にマッピングされたアドレス/ポートの値が比較されます。マッピングが異なる場合は、対称型NATフラグがTRUEに設定されています。
3. It is assumed that for both Clients A and B, the Port-Preserving NAT flag and the Symmetric NAT flag are set to TRUE at the end of the qualification procedure.
3.両方のクライアントAとB、ポート保存NATフラグと対称NATフラグ資格手順の最後にTRUEに設定されているものとします。
4. Before A sends packets to B, A checks to see if it is positioned behind a port-preserving NAT and a symmetric NAT, which in the example, it is. A also checks to see if the peer is "trusted", but it currently is not. Next, A checks if the Random Port is set to non-zero. Since it is still zero, A allocates a new random port, begins listening on it, and stores the value in the Random Port field.
AがBにパケットを送信4.前に、Aは、それがポート保存NAT及び例において、それは対称NATの背後に配置されているかどうかを確認します。また、ピアは「信頼」であるかどうかをチェックし、それが現在ではありません。次に、チェックはランダムポートを非ゼロに設定されている場合。それはまだゼロであるので、Aは、新しいランダムなポートを割り当て、それを聞いて始まり、ランダムポート]フィールドに値を格納します。
5. A sends a direct bubble (Packet 1) from the primary port to the mapped address/port embedded in B's Teredo IPv6 address. This direct bubble does not have a Nonce Trailer or a Random Port Trailer attached to the end.
5. AはBのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートをプライマリポートから直接バブル（パケット1）を送信します。この直接バブルはナンストレーラーや端に取り付けられたランダムなポートトレーラーを持っていません。
6. The aforementioned direct bubble is dropped by B's NAT because the NAT has not seen an outgoing packet destined to A's mapped address.
NATは、Aのマッピングされたアドレス宛ての送信パケットを見ていないので、6前述の直接バブルBのNATによってドロップされます。
7. A sends an indirect bubble (Packet 2) destined to B via client B's Teredo server. This indirect bubble contains two trailers: the Nonce Trailer containing a random nonce, and the Random Port Trailer containing the random port value from the Peer Entry. The nonce used in the Nonce Trailer is also stored in the Nonce Sent field of the Peer Entry.
7. Aは、クライアントBのTeredoサーバーを経由してBに宛てた間接的なバブル（パケット2）を送信します。ランダムなnonceを含むノンストレーラー、およびピアエントリからランダムなポート値を含むランダムポートトレーラー：この間接的なバブルは、二つのトレーラーが含まれています。ノンストレーラーに使用されるナンスはまた、ピアエントリのノンス送信済みフィールドに格納されます。
8. The aforementioned indirect bubble is received by B. B adds the Teredo peer to its peer list. B saves the nonce value from the Nonce Trailer in the Nonce Advertised field of the Peer Entry. B stores the port value from the Random Port Trailer in the Peer Random Port field in the Peer Entry.
8 B. Bによって受信される前述の間接バブルは、そのピアリストへのTeredoピアを付加します。 Bは、ピアエントリのノンスアドバタイズフィールドにノンストレーラーからノンス値を保存します。 Bは、ピアエントリのピアランダムPortフィールドにランダムポートトレーラーからポート値を格納します。
9. B responds by sending the following packets. The first packet sent by B is a direct bubble (Packet 3) destined to the mapped address/port embedded in A's Teredo IPv6 address. This packet is sent from the primary port. It includes the Nonce Trailer with the nonce from the Nonce Advertised field of the Peer Entry.
9. Bは、次のパケットを送信して応答します。 Bによって送信された最初のパケットはAのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポート宛直接バブル（パケット3）です。このパケットは、プライマリポートから送信されます。これは、ピアエントリのナンスアドバタイズフィールドからナンスとナンスのトレーラーが含まれています。
10. The aforementioned direct bubble is dropped by A's NAT because the NAT has not seen any outgoing packet sourced from the mapped address/port embedded in A's Teredo IPv6 address and destined to the mapped address/port embedded in B's Teredo IPv6 address.
NATは、マッピングされたアドレス/ポートAのTeredoのIPv6アドレス内に埋め込まれ及びBのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートを宛先から発信任意の発信パケットを見ていないので、10.前述の直接気泡がAのNATによってドロップされます。
11. B then checks if it is positioned behind a port-restricted NAT or a symmetric NAT. It also checks if the peer has already advertised a random port. In this case, B is positioned behind a port-preserving symmetric NAT and the peer has advertised a random port; hence, it needs to use a random port. It checks if its Random Port field is set to non-zero. Since it is still zero, B allocates a new random port, begins listening on it, and stores it in the Random Port entry of the Peer Entry. B then sends a direct bubble (Packet 4) destined to the mapped address embedded in A's Teredo IPv6 address and the port stored in the Peer Random Port field of the Peer Entry. The direct bubble is sent from its own random port.
11. Bその後チェックそれは、ポート制限付きNATまたは対称NATの背後に配置されている場合。ピアがすでにランダムなポートを宣伝している場合もチェックします。この場合、Bは、ポート維持対称NATの背後に配置され、ピアは、ランダムなポートをアドバタイズしています。したがって、それはランダムなポートを使用する必要があります。そのランダムなポートフィールドが非ゼロに設定されている場合はチェックします。それはまだゼロであるので、Bは、新しいランダムなポートを割り当て、それを聞いて始まり、ピアエントリのランダムなポートエントリに格納します。 Bは、その後、AのTeredoのIPv6アドレスとピアエントリのピアランダムなポートフィールドに格納されているポートに埋め込まれたマッピングされたアドレス宛ての直接バブル（パケット4）を送信します。直接気泡が独自のランダムポートから送信されます。
12. The above direct bubble is dropped by A's NAT because the NAT has not seen any outgoing packet sourced from the mapped address embedded in A's Teredo IPv6 address and random port advertised by A.
12. NATは、AのTeredoのIPv6アドレス及びA.によってアドバタイズランダムポート内に埋め込まれたマッピングされたアドレスから発信任意の発信パケットを見ていないため、上記直接気泡がAのNATによってドロップされます
13. B also sends an indirect bubble (Packet 5) destined to A via A's Teredo Server. This indirect bubble includes a Nonce Trailer and a Random Port Trailer. The Nonce Trailer includes a new randomly generated nonce that is also stored in the Nonce Sent field of the Peer Entry. The Random Port Trailer includes the value in the Random Port field of the Peer Entry.
13. BもAのTeredoサーバーを介し宛間接バブル（パケット5）を送信します。この間接的なバブルは、ナンストレーラーとランダムポートトレーラーが含まれています。ノンストレーラーはまた、ピアエントリのノンス送信済みフィールドに格納される新しいランダムに生成されたノンスを含みます。ランダムなポートトレーラーは、ピアエントリのランダムポート]フィールドに値が含まれています。
14. The aforementioned indirect bubble is successfully received by A. A parses the trailers and stores the nonce contained in the Nonce Trailer in the Nonce Received field of the Peer Entry. A stores the port advertised in the Random Port Trailer in the Random Port field of the Peer Entry.
前述の間接気泡が正常A. Aによって受信される14.トレーラーを解析し、ノンスがピアエントリのフィールドを受信中にノンストレーラーに含まれるnonceを記憶します。ピアエントリのランダムポート]フィールドにランダムポートトレーラーでアドバタイズ店舗ポート。
15. A responds with the following packets in response to the indirect bubble received. The first packet is a direct bubble (Packet 6) sent from the primary port and is destined to the mapped address/port embedded in B's Teredo IPv6 address.
15. Aは、受け取った間接的なバブルに応じて、次のパケットで応答します。最初のパケットは、プライマリポートから送信された直接バブル（パケット6）であり、BのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートを宛先としています。
16. The aforementioned direct bubble again is dropped by B's NAT because the NAT has not seen an outgoing packet with the same 4-tuple as the incoming packet.
NATは、着信パケットと同じ4タプルと発信パケットを見ていないので、16前述の直接バブルが再びBのNATによってドロップされます。
17. The next packet is also a direct bubble (Packet 7) and this one is sent from A's random port. The packet is destined to the mapped address embedded in B's Teredo IPv6 address and the Peer Random Port stored in the Peer Entry.
17.次のパケットは、直接バブル（パケット7）であり、これは、Aの任意のポートから送信されます。パケットは、BのTeredoのIPv6アドレスとピアエントリに保存されているピアのランダムポートに埋め込まれてマッピングされたアドレスを宛先としています。
18. Because both NATs are port-preserving NATs and the random ports have not been used for any other mapping, the aforementioned direct bubble is received by B because B's NAT has seen an outgoing packet (Packet 4) with the same address/port pairs. B stores the address/port from which the direct bubble was received in the mapped address/port fields of the Peer Entry. It changes the status of the peer to "trusted" and sets the
18.両方のNATのポート保存のNATがあり、ランダムポートが他のマッピングに使用されていないため、BのNATは、同じアドレス/ポート対を有する発信パケット（パケット4）を見ているので、前述の直接バブルはBによって受信されます。 Bは、直接気泡がピアエントリのマッピングされたアドレス/ポートフィールドに受信されたアドレス/ポートを格納します。これは、「信頼できる」にピアのステータスを変更して設定します
Direct Receive on Random Port field to TRUE. At this point,
communication in one direction is now possible (B to A, but not
vice versa).
19. Because A still considers B to be "not-trusted", it times out and retransmits an indirect bubble (Packet 8). This packet contains a new nonce as part of the Nonce Trailer and also contains the value of the random port as part of the Random Port Trailer.
19. Aはまだそれはタイムアウトし、Bは「-信頼されていない」ことを考慮し、間接的なバブル（パケット8）を再送信するので。このパケットは、ナンストレーラーの一環として、新たなnonceを含み、またランダムなポートトレーラーの一環として、ランダムなポートの値が含まれています。
20. B receives the aforementioned indirect bubble. The processing of this indirect bubble is similar to the processing of Packet 2. Since B received a direct bubble on its random port, it does not respond with a direct bubble from its primary port. Instead, it responds with a direct bubble (Packet 9) sent from its random port, which is similar to Packet 4 mentioned above.
20. Bは、上記間接バブルを受け取ります。 Bは、そのプライマリポートから直接バブルで応答しない場合、そのランダムなポートに直接バブルを受けているので、この間接的なバブルの処理は、パケット2の処理と同様です。代わりに、上述したパケット4と同様であり、そのランダムポートから送信された直接バブル（パケット9）で応答します。
21. A receives the direct bubble sent by B. A stores the mapped address/port from which the direct bubble was received in mapped address/port fields in the Peer Entry. A changes the status of B to "trusted" and sets the Direct Receive on Random Port field to TRUE. At this point, the communication is now possible in the other direction (A to B).
21. Aは、B A格納直接バブルがピアエントリにマッピングされたアドレス/ポートフィールドに受信されたマッピングされたアドレス/ポートによって送信された直接バブルを受け取ります。 Aは、「信頼できる」とBのステータスを変更し、直接はTRUEにランダムポート]フィールドに受信設定します。この時点で、通信は、他の方向（BとA）で可能になりました。
The following protocol example illustrates the use of the Sequential Port-Symmetric NAT Extension.
次のプロトコルの例では、シーケンシャルポート対称NAT拡張の使用を示します。
Assume that Teredo Client A (A), which is positioned behind a sequential port-symmetric NAT and implements the Sequential Port-Symmetric NAT Extension, wants to communicate with Teredo Client B (B), which is positioned behind a port-restricted NAT that supports the Port-Preserving Port-Symmetric NAT Extension. The following packet exchange explains the configuration setup and communication setup between the two clients.
シーケンシャルポート対称NATの背後に配置され、順次ポート対称NAT拡張が実装されているTeredoクライアントA（A）は、ポート制限付きNATの背後に配置されているTeredoクライアントのB（B）と通信したいと仮定するポート・保存ポート対称NAT拡張をサポートしています。次のパケット交換は2つのクライアント間のコンフィギュレーション設定と通信設定について説明します。
Teredo A's A's B's
Client Primary Secondary Teredo Client
A NAT Server Server Server NAT B
| | | | | | |
| Direct Bubble to B | | | | |
1 |-------------------------------------------------->| |
| | | | | | |
|Router Solicitation | | | | |
2 |------------------->| | | | |
| | | | | | |
|Router Advertisement| | | | |
|<-------------------| 3 | | | |
| | | | | | |
4 | Direct Bubble to B | | | | |
|-------------------------------------------------->| |
| | | | | | |
| Router Solicitation | | | |
5 |---------------------------->| | | |
| | | | | | |
| Router Advertisement | | | |
|<----------------------------| 6 | | |
| | | | | | |
| Indirect Bubble to B via B's Teredo Server | | |
7 |------------------------------------------->|-------------->|
| | | | | | |
| | | | Direct Bubble to A |
| |<-------------------------------------------------| 8
| | | | | | |
| | | | Indirect Bubble to A |
|<-------------------|<--------------------------------------| 9
| | | | | | |
| | | | Direct Bubble to A |
|<-----------------------------------------------------------| 10
| | | | | | |
| Direct Bubble to B | | | |
11 |----------------------------------------------------------->|
Sequential Port-Symmetric NAT Packet Exchange
シーケンシャルポート対称型NATパケット交換
1. During the qualification procedure, when Client A receives a response from the Teredo Server, it compares the Port value in the Origin indication with the Local Port value. Since they are different, it concludes that it is not behind a port-preserving NAT, and so assumes it is behind a sequential port-symmetric NAT.
クライアントAがTeredoサーバーからの応答を受け取る資格手順の間1.は、それがローカルポート値を持つ原産地表示のポート値を比較します。彼らが異なっているので、それはそれは、ポート維持NATの背後ではないと結論付け、そしてそれは、シーケンシャルポート対称NATの背後にある前提としています。
2. When A wants to communicate with B, A starts by sending a direct bubble (Packet 1) from its primary port. This occurs because Client A does not know Client B's NAT type, which could be a cone or address restricted NAT or UPnP-enabled NAT. Because Client A is behind a symmetric NAT, the external port used by A's NAT is a new port. This direct bubble will be dropped by B's NAT since Client B is behind a port-restricted NAT.
2. AはBと通信したい場合、Aは、そのプライマリポートから直接バブル（パケット1）を送信することによって開始します。クライアントAは、NATまたはUPnP対応NAT制限コーンまたはアドレス可能性があり、クライアントBのNATタイプを、知っていないために発生します。クライアントAは対称NATの背後にあるので、AのNATで使用される外部ポートが新しいポートです。クライアントBは、ポート制限NATの背後にあるので、この直接バブルがBのNATによって破棄されます。
3. Because Client A does not know if B is behind a port restricted NAT or some other kind of NAT, Client A proactively opens a new random internal port, say, port 1100.
3.クライアントAは、Bがポートの背後にある場合、NATやNATのいくつかの他の種類を制限し、クライアントAは、積極的に新しいランダム内部ポート、たとえば、ポート1100を開き、知らないので。
A. Client A sends a router solicitation (Packet 2) to its Teredo
Server address from port 1100. The server responds with a
router advertisement (Packet 3).
B. Client A sends a direct bubble (Packet 4) to the peer from port 1100 destined to the port advertised in Client B's Teredo address, say, port 2100. This direct bubble is dropped by Client B's port-restricted NAT.
B.クライアントAこの直接気泡がクライアントBのポート制限NATによってドロップされたポート2100、たとえば、クライアントBのTeredoアドレスでアドバタイズポート宛のポート1100からのピアに直接バブル（パケット4）を送信します。
C. Client A sends a router solicitation (Packet 5) to its secondary Teredo server address from port 1100. The server responds with a router advertisement (Packet 6).
C.クライアントAは、サーバがルータ広告（パケット6）で応答ポート1100からの二次Teredoサーバーアドレスにルータ要請（パケット5）を送信します。
D. On receiving the corresponding router advertisements for Packet 2 and Packet 4, Client A knows that port 1100 maps to, say, port 1200 for Packet 2 and port 1202 for Packet 4.
D.は、パケット2とパケット4のために、対応するルータ広告を受信すると、クライアントAは、そのポートにパケット4のパケット2とポート1202のポート1200、たとえば、1100枚のマップを知っています。
E. Client A then calculates its predicted port used for Packet 2 as the average (rounded down) of 1200 and 1202, i.e., 1201.
E.クライアントAは、その予測されたポート1201、すなわち1200および1202の平均（切り捨て）、などのパケット2のために使用さを算出します。
5. Client A then sends out an indirect bubble (Packet 7). This indirect bubble contains a random port trailer that contains the predicted port, port 1201. This indirect bubble makes it to Client B.
5.クライアントAは、次いで間接バブル（パケット7）を送出します。この間接的なバブルは、この間接的なバブルは、クライアントBにそれを作る予測ポートが含まれているランダムポートトレーラー、ポート1201が含まれています
6. Client B sends out the following bubbles in response to the indirect bubble:
6.クライアントBは、間接的なバブルに応じて、以下の気泡を送り出します：
A. The first direct bubble (Packet 8) is destined for the port
mapping embedded in Client A's Teredo Address. (It has been
observed that some NATs display symmetric NAT behavior for
outgoing packets but cone NAT behavior for incoming packets.
The direct bubble described is likely to succeed if Client
A's NAT displays such a behavior.) Since in this example,
A's NAT is a normal sequential port-symmetric NAT, this
packet is dropped.
B. The second packet is an indirect bubble (Packet 9) sent to Client A without any trailers since Client B is behind a port-restricted NAT.
B.第2のパケットクライアントBは、ポート制限付きNATの背後にあるため、任意のトレーラーなしクライアントAに送信された間接的なバブル（パケット9）です。
C. The next packet will be a direct bubble (Packet 10) sent to port 1201. This packet will make it in to Client A since Client A previously sent an outgoing packet (Packet 4) with the same four tuple. At this point, communication in one direction is now possible (A to B, but not vice versa).
C.は、次のパケットは、クライアントAが以前に同じ4つのタプルと発信パケット（パケット4）を送信するので、このパケットは、クライアントAにそれを行いますポート1201に送信された直接バブル（パケット10）であろう。この時点で、一方向の通信が（ただし、その逆、BのA）ことが可能です。
7. Client A then sends a direct bubble (Packet 11) to Client B when it receives Packet 10. This time, the bubble makes it through to B because it previously sent an outgoing packet (Packet 10) with the same four tuple. At this point, communication is now possible in the other direction (B to A).
7.クライアントAは、それが今回のパケット10を受信した場合、それが以前に同じ4つのタプルと発信パケット（パケット10）を送信したため、気泡がBにそれを介して行うクライアントBに直接バブル（パケット11）を送信します。この時点で、通信は、他の方向（AとB）が今や可能です。
The following protocol example illustrates the use of the Hairpinning Extension.
次のプロトコルの例は、ヘアピニング拡張の使用を示します。
In Figure 3 (Section 3.5), Teredo Client A (A) and Teredo Client B (B) are positioned behind different immediate NATs in a two-layer NAT topology; that is, the outermost NAT (NAT E) is common to both A and B but the immediate NATs that they are connected to are different (A is connected to NAT F while B is connected to NAT G). Further assume that the immediate NATs that A and B are connected to are UPnP-enabled (NAT F and NAT G are UPnP-enabled). We assume that NAT E does not support hairpinning; that is, the NAT does not relay packets originating from the private address space and destined for the public address of the NAT, back to the private address of the NAT.
図3（3.5節）において、TeredoクライアントA（A）とTeredoクライアントB（B）は、2つの層NATトポロジ内の異なる即時NATの背後に配置されています。つまり、最も外側のNAT（NAT E）は、AとBの両方に共通であるが、それらが接続されている即時NATは（BはNAT Gに接続されているAがNAT Fに接続されている）が異なります。さらに、A及びBは、UPnP対応しているに接続されている即時のNATは、（NAT F及びG NATがUPnP対応している）と仮定する。私たちは、NAT Eはヘアピンをサポートしていないことを前提としています。つまり、NATは、バックNATのプライベートアドレスに、プライベートアドレス空間から発信し、NATのパブリックアドレス宛てのパケットを中継しません。
Before starting the qualification procedure, both A and B use UPnP to reserve port mappings on their respective NATs. They observe that the UPnP operation succeeds and both clients obtain valid UPnP Mapped Address/Port values.
資格の手続きを開始する前に、AとBの使用UPnPの両方が、それぞれのNATにポートマッピングを予約します。彼らは、UPnP操作が成功し、両方のクライアントが有効UPnPのマッピングアドレス/ポートの値を取得することを確認します。
Next, both client A and client B implement the qualification procedure where they determine their mapped address/port values, as specified in Section 5.2.1 of [RFC4380].
[RFC4380]のセクション5.2.1で指定されるように次に、クライアントAとクライアントBの両方は、彼らがマップされたアドレス/ポート値を決定する資格手順を実装します。
A and B both compare their UPnP Mapped Address/Port values with the mapped address/port values obtained through the qualification procedure. Because both A and B are part of a two-layer NAT topology, these values will be different. Hence, both A and B continue to hold on to their UPnP Mapped Address/Port.
AおよびBは、両方の認定手順を経て得られたマッピングされたアドレス/ポートの値とそれらのUPnPマップされたアドレス/ポート値を比較します。 AとBの両方を2層NATトポロジの一部であるため、これらの値は異なるであろう。したがって、AとBの両方が彼らのUPnPのマッピングアドレス/ポートを保持し続けます。
The following packet exchange shows client A establishing communication with client B.
次のパケット交換は、クライアントにクライアントBとの通信を確立を示しています
Teredo Teredo Client A's Client B's
Client NAT Client NAT NAT Teredo Teredo
A F B G E Server Server
| | | | | | |
| | Direct Bubble to B | | | |
1 |-------------------------------------->| | |
| | | | | | |
| Indirect Bubble to B via B's Teredo Server |
2 |----------------------------------------------------------->|
| | |<----------------------------------------|
| | | | | | |
| | | Direct Bubble to A | | |
3 | | |------------------->| | |
| | | | | | |
| | | Direct | | | |
| | |Bubble to A| | | |
4 | | |---------->| | | |
| | | | | | |
| | | Direct | | | |
| | |Bubble to A| | | |
5 | | |---------->| | | |
|<-----------------------------| | | |
| | | | | | |
| | | Indirect Bubble to A | |
6 | | |---------------------------->| |
|<-----------------------------------------------| |
| | | | | | |
|Direct Bubble to B| | | | |
7 |----------------->| | | | |
| | | | | | |
Hairpinning-Based Packet Exchange
ヘアピニングベースのパケット交換
1. A sends a direct bubble (Packet 1) to the mapped address/port embedded in B's Teredo IPv6 address.
1. AはBのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートに直接バブル（パケット1）を送信します。
2. The aforementioned direct bubble is dropped by NAT E, because it does not support Hairpinning.
それはヘアピニングをサポートしていないため2.上記の直接のバブルは、NAT Eによってドロップされます。
3. A sends out an indirect bubble (Packet 2) destined to B via B's Teredo Server. In this indirect bubble, A includes an Alternate Address Trailer that includes both the local address/port and the UPnP mapped address/port.
3. AはBのTeredoサーバーを経由してBに宛てた間接的なバブル（パケット2）を送信します。この間接的なバブルでは、Aは、ローカルアドレス/ポートとUPnPの両方を含む代替アドレストレーラーは、アドレス/ポートにマッピングすることを含みます。
4. The aforementioned indirect bubble is received by B. After parsing the Alternate Address Trailer, B has a total of three addresses to communicate with: two from the Alternate Address Trailer and one from the mapped address/port embedded in A's Teredo IPv6 address. B then responds with the following packets. The first packet sent by B is a direct bubble (Packet 3) destined to the mapped address/port embedded in A's Teredo IPv6 address.
AのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポートから代替アドレストレーラーからの二つ一4.前述の間接気泡が代替アドレストレーラーを解析した後にBによって受信され、Bは、と通信する3つのアドレスの合計を有します。 Bは、その後、次のパケットで応答します。 Bによって送信された最初のパケットはAのTeredoのIPv6アドレスに埋め込まれたマッピングされたアドレス/ポート宛直接バブル（パケット3）です。
5. The aforementioned direct bubble will be dropped by the NAT E because it does not support Hairpinning.
それはヘアピニングをサポートしていないため5.前述の直接バブルがNAT Eによって破棄されます。
6. Because the local address/port was the first mapping in the Alternate Address Trailer, the second direct bubble (Packet 4) sent by B is destined to the local address/port.
6.ローカルアドレス/ポートは、代替アドレストレーラー内の最初のマッピングがあったため、Bによって送信された第2の直接バブル（パケット4）ローカルアドレス/ポートを宛先としています。
7. The aforementioned direct bubble is dropped because A and B are positioned behind different NATs and hence have their own private address space. A's local address is not reachable from B.
AとBが異なるNATの後方に位置し、したがって、独自のプライベートアドレス空間を持っているので、7前述の直接バブルがドロップされます。 Aのローカルアドレスは、Bから到達可能ではありません
8. The next direct bubble (Packet 5) is sent by B destined to A's UPnP mapped address/port, which is the second mapping in the Alternate Address Trailer sent by A.
8.次直接バブル（パケット5）はAによって送信された代替アドレストレーラーで第2のマッピングであるAさんのUPnPマッピングされたアドレス/ポート、宛てBによって送信されます
9. The aforementioned direct bubble is received by A because A's UPnP-mapped address is reachable from B. A stores the source address from which the direct bubble was received in the mapped address/port fields of the Peer Entry, as defined in Section 5.2 of [RFC4380]. Also, the mapped address status field (as specified in Section 5.2.3 of [RFC4380]) is changed to "trusted". At this point, communication in one direction (A to B) is now possible, but not vice versa because B has not yet marked A as trusted.
AのUPnPのマッピングされたアドレスが直接気泡がピアエントリのマッピングされたアドレス/ポートフィールドに受信された送信元アドレスがB. A店から到達可能であるため、セクション5.2で定義されるように9.前述の直接バブルは、Aによって受信されます[RFC4380]の。また、マップされたアドレス・ステータス・フィールドは、（[RFC4380]のセクション5.2.3で指定されるように）「信頼できる」に変更されます。この時点で、一方向（BとA）で通信がなく、その逆トラステッドとしてBがまだAとマークされていないため、現在可能です。
10. B also sends an indirect bubble (Packet 6) to A via A's Teredo server. As part of the indirect bubble, B also includes an Alternate Address Trailer, which contains the local address/port and the UPnP mapped address/port of B.
10. BもAのTeredoサーバーを介して間接的に気泡（パケット6）を送信します。間接的な気泡の一部として、Bは、ローカルアドレス/ポートが含まれている代替アドレストレーラーを含み、UPnPはBのアドレス/ポートをマッピングし
11. The aforementioned indirect bubble is received by A. After parsing the Alternate Address Trailer, A adds the two addresses in the Alternate Address Trailer to the Alternate Address List in the Peer Entry. Because the peer's mapping is "trusted" (point 9), A responds with only one direct bubble (Packet 7) that is sent to the mapped address/port stored in the Peer Entry.
11.前述の間接的な気泡が代替アドレストレーラーを解析した後にAによって受信され、Aは、ピアエントリの代替アドレスリストに代替アドレストレーラーに2つのアドレスを追加します。ピアのマッピングは、「信頼できる」（点9）であるため、Aは、ピアエントリに格納されたマッピングされたアドレス/ポートに送信される唯一の直接バブル（パケット7）で応答します。
12. The aforementioned direct bubble is received by B. B records the mapped address/port from which the direct bubble was received in the mapped address/port field in its Peer Entry, and changes the status of the mapped address to "trusted". At this point, communication is now possible in the other direction (B to A).
12.前述の直接バブルはB. Bによって受信される直接バブルは、そのピアエントリにマッピングされたアドレス/ポートフィールドに、受信されたマッピングされたアドレス/ポートを記録し、「信頼できる」にマッピングされたアドレスの状態を変更します。この時点で、通信は、他の方向（AとB）が今や可能です。
The following protocol example illustrates the use of the Server Load Reduction Extension.
次のプロトコルの例では、サーバ負荷軽減拡張の使用を示します。
Assume that Teredo Client A (A) has established communication with Teredo Client B (B). Also, assume that at some later point when no data packets have been exchanged between both clients for more than 30 seconds, the communication needs to be re-established because A wants to send a data packet to B.
TeredoクライアントA（A）は、TeredoクライアントのB（B）との通信を確立していると仮定する。また、AがBにデータパケットを送信したいので、何のデータパケットが30秒以上の両方のクライアント間で交換されていないいくつかの後の時点で、通信を再確立する必要があることを前提としてい
The following packet exchange helps A re-establish communication with B.
次のパケット交換は、Bとの通信を再確立するのに役立ちます
Teredo Client A's Client B's Teredo
Client Teredo Teredo Client
A NAT Server Server NAT B
| | | | | |
| | | Direct Bubble to B | | |
1 |------------------------------------------------------------>|
| | | | | |
| | | Direct Bubble to A | | |
|<------------------------------------------------------------| 2
| | | | | |
Server Load Reduction Packet Exchange
サーバ負荷低減パケット交換
1. A sends a direct bubble (Packet 1) with the Neighbor Discovery Option Trailer, with the DiscoveryType field set to TeredoDiscoverySolicitation.
1. AからTeredo探索要請に設定ディスカバリー・タイプ・フィールドと、近隣探索オプショントレーラーと直接バブル（パケット1）を送信します。
2. If the mapping on either of the NATs has not expired, the direct bubble is received by B. B parses the Neighbor Discovery Option and because the DiscoveryType was set to TeredoDiscoverySolicitation, B responds with a direct bubble (Packet 2). B's direct bubble also contains the Neighbor Discovery Option and the DiscoveryType is set to TeredoDiscoveryAdvertisement.
2.のNATのいずれかにマッピングが満了していない場合、直接バブルはB. Bによって受信される近隣探索オプションを解析しDiscoveryTypeがTeredoDiscoverySolicitationに設定したため、Bは直接バブル（パケット2）で応答します。 Bの直接のバブルも近隣探索オプションが含まれており、DiscoveryTypeはTeredoDiscoveryAdvertisementに設定されています。
3. The aforementioned direct bubble is received by A and at this point, communication between the Teredo clients is re-established.
3.前述の直接バブルがAによって受信され、この時点で、Teredoクライアント間の通信が再確立されます。
Security considerations are the same as those specified in Section 7 of [RFC4380].
セキュリティの考慮事項は、[RFC4380]のセクション7で指定したものと同じです。
In addition, the Hairpinning Extension introduces the possibility of an amplification attack if a malicious user could advertise a large number of port mappings in the Alternate Address Trailer, resulting in a large number of direct bubbles sent in response. Because of this, Section 4.3 explicitly limits the number of addresses that a Teredo client will accept.
悪意のあるユーザが応答で送信されたダイレクト多数の気泡が得られ、代替アドレストレーラーにポートマッピングの多数の広告を出すことができればまた、ヘアピニング拡張は、増幅攻撃の可能性を導入します。このため、4.3節を明示的にTeredoクライアントが受け入れるアドレスの数を制限します。
Because the nonce in the Nonce Trailer is used (as specified in Section 5.2.4.4) to prevent spoofing of bubbles that would result in directing traffic to the wrong place, it is important that the nonce be random so that attackers cannot predict its value. See [RFC4086] for further discussion of randomness requirements.
間違った場所にトラフィックを向けることになる気泡のなりすましを防ぐために（セクション5.2.4.4で指定）ナンストレーラーでnonceが使用されているので、攻撃者がその値を予測することができないようにnonceがランダムであることが重要です。ランダム性の要件のさらなる議論のための[RFC4086]を参照してください。
Thanks to Gurpreet Virdi and Poorna Gaddehosur for technical contributions to this document, and to the V6OPS WG and Jari Arkko for their helpful reviews.
その参考になったレビューのために、この文書に、そしてV6OPS WGとヤリArkkoへの技術的貢献のためGurpreet VirdiとPoorna Gaddehosurに感謝します。
IANA has created a new trailer Type registry. Requests for new trailer Type values are made through Specification Required [RFC5226]. Initial values are listed below.
IANAは新しいトレーラータイプのレジストリを作成しました。新しいトレーラータイプの値に対する要求は、仕様が必要である[RFC5226]を介して行われます。初期値は以下のとおりです。
Trailer Type Usage Reference
------------ --------------------------------- ---------
0x01 Nonce Trailer RFC 6081
0x02 Random Port Trailer RFC 6081
0x03 Alternate Address Trailer RFC 6081
0x04 Neighbor Discovery Option Trailer RFC 6081
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]のHuitema、C.、 "のTeredo：ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器（NAT）"、RFC 4380、2006年2月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[UPNPWANIP] UPnP Forum, "WANIPConnection:1", November 2001, <http://www.upnp.org/standardizeddcps/documents/ UPnP_IGD_WANIPConnection%201.0.pdf>.
[UPNPWANIP] UPnPフォーラム、 "WANIPConnection：1"、2001年11月、<http://www.upnp.org/standardizeddcps/documents/ UPnP_IGD_WANIPConnection％201.0.pdf>。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン6（IPv6）の仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 4443、2006年3月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F.とC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
Author's Address
著者のアドレス
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
デーブターラーマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052 USA
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
電話：+1 425 703 8835 Eメール：dthaler@microsoft.com