[要約] RFC 6081は、Teredo拡張機能に関する仕様であり、IPv6ネットワークへのアクセスを提供するTeredoトンネリングプロトコルの機能を拡張するためのものです。目的は、Teredoの機能を向上させ、IPv6ネットワークへの接続性を向上させることです。
Internet Engineering Task Force (IETF) D. Thaler
Request for Comments: 6081 Microsoft
Updates: 4380 January 2011
Category: Standards Track
ISSN: 2070-1721
Teredo Extensions
Teredo拡張機能
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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：外部ホストのIPアドレスxからパケットを受け入れる制限されたNATおよび内部ホストが、宛先ポートに関係なくIPアドレスXに運命づけられているパケットを送信した場合。[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アドレスを持つ対称NAT、異なる外部ホストと通信するときに異なるIPアドレスとポートを割り当てる。
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.
CONE 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で指定されているように、IPv6ヘッダーの宛先フィールドにTeredoアドレスが含まれているIPv4ノードに直接送信されるテレドバブル。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でのヘアピニングサポートにより、これらのホストは他のホストのいずれかに割り当てられた外部アドレスとポートにパケットを送信でき、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で指定されているように、間接的に（目的地のテレドサーバーを介して）別のテレドクライアントに間接的に送信されるテレドバブル。
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.
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.
NONCE：メッセージのリプレイやその他のタイプの攻撃を防ぐために、接続セットアップフェーズで使用される時間変数ランダム値。
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が、マッピングされたポートがローカルポートと同じ値を持つように、同じマッピングされたアドレス/ポートがまだ使用されていない限り、ローカルポートと同じ値を持つ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：外部ホストのIPアドレスXおよびポートYからパケットを受け入れる制限されたNAT。内部ホストが[RFC4787]の用語でIPアドレスXとポートYに向けたパケットを送信した場合にのみ、これはエンドポイントに依存しないマッピングとアドレス、ポート依存フィルタリングを備えた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：すべての{内部IPアドレスとポート、宛先IPアドレスとポート}タプルごとに外部ポートを順番に割り当てるポート対称NAT。シーケンシャル割り当てで使用されるデルタは、通常、ほとんどの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アドレスとポートにマッピングされます。同じ内部IPアドレスとポートから異なる宛先IPアドレスとポートへの要求は、別の外部IPアドレスとポートにマッピングできます。さらに、対称NATは、外部ホストのIPアドレスXおよびポートYから受信したパケットを受け入れます。内部ホストが[RFC4787]の用語で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 Bubble：Teredoコントロールメッセージ（[RFC4380]のセクション2.8で指定）は、NATでマッピングを作成するために使用されます。テレドバブルには、直接泡と間接的な泡の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アドレス：[RFC4380]のセクション2.14で指定されているように、TeredoクライアントのIPv6アドレス。
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 Server：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]で指定されているように）は、1つ以上のIPv4 NATの背後にあるノードを有効にして、UDPを介したトンネリングパケットによってIPv6接続を取得できます。
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.
o ノード独自のIPv4アドレス/ポート。
o The external IPv4 address/port to which the node's NAT translates.
o ノードのNATが翻訳する外部IPv4アドレス/ポート。
o The peer's own IPv4 address/port.
o ピア自身のIPv4アドレス/ポート。
o The external IPv4 address/port to which the peer's NAT translates.
o ピアのNATが翻訳する外部IPv4アドレス/ポート。
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サーバーと通信して、マッピングされたアドレス/ポートを発見します。Mappedアドレス/ポートは、Teredoサーバーアドレスとともに、Teredo IPv6アドレスとして知られるIPv6アドレスを生成するために使用されます。これにより、ノードのIPv6アドレスを取得するピアが、IPv4 UDPメッセージにカプセル化されたIPv6パケットを送信する外部IPv4アドレス/ポートを簡単に決定できるようになります。
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拡張とポートプレゼンティング対称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.
SNS =対称NATサポートエクステンションでサポートされています。
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.
SNS PP =対称NATサポート拡張およびポート浸漬対称NAT拡張でサポートされています。
SNS+SS = Supported with the Symmetric NAT Support Extension and Sequential Port-Symmetric NAT Extension.
SNS SS =対称NATサポート拡張およびシーケンシャルポート対称NAT拡張でサポートされています。
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クライアントが対称NATの後ろに配置されている場合、Teredoクライアントが互いに接続するのは簡単ではないことです。対称NATの仕組みにより、ピアは、ノードのTeredoサーバーが見ているよりも、Teredoクライアントから来るIPv4/UDPヘッダーのマッピングされたアドレス/ポートを表示します（したがって、ノードのTeredo IPv6アドレスに表示されます）。その結果、対称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に示すトポロジを考えてみましょう。TeredoClientBは、Teredo Server 2を使用して、マッピングされたアドレス/ポートが192.0.2.10:8192であることを知り、[RFC4380]のセクション4で指定されているように、テレドIPv6アドレスを構築します。したがって、C633：6476はTeredo Server 2（198.51.100.118）のアドレスの16進数であり、マッピングされたポートは0xFFFFで排他的であるか、DFFFを形成し、マッピングされたアドレスは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 Client AはTeredo Server 1を使用して、マッピングされたアドレス/ポートが192.0.2.1:4096であることを知り、この拡張機能を使用すると、Teredo IPv6アドレスを構築します（[RFC4380]のセクション4で指定されているように）。対称ナットの後ろ。したがって、CB00：7178はTeredo Server 1（203.0.113.120）のアドレスの16進数であり、マッピングされたポートは0xffffで排他的であるか、EFFFを形成し、マッピングされたアドレスは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の後ろに配置されたテレドクライアントは、通信を開始する側に応じて、次のようにコーンまたは住所制限NATの後ろに配置されたテレドピアと通信できます。
--------------------------------------------
/ \
< 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の後ろに配置されたテレドクライアントB（b）が、対称NATの背後にあるテレドクライアントA（a）とのコミュニケーションを開始すると仮定します。Bは、Aのサーバー（Teredo Server 1）を介して間接的なバブルをAに送信し、Aは直接バブルで応答します。この直接バブルはBに達します。これは、コーンまたはアドレス制限NATの後ろに配置されているためです。ただし、直接バブルのIPv4/UDPヘッダーのマッピングされたアドレス/ポートは、AのTeredo IPv6アドレスに埋め込まれたマッピングされたアドレス/ポートとは異なります。したがって、bは直接バブルのマッピングされたアドレス/ポートを覚えており、それらとの将来のコミュニケーションのためにそれらを使用するため、通信が確立されます。
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.
2番目のケースでは、対称NATの背後に位置するAがBとの通信を開始し、コーンまたはアドレス制限NATの後ろに配置すると仮定します。Aは、Bのサーバー（Teredo Server 2）を介して間接的なバブルをBに送信し、Bは直接バブルで応答します。この直接バブルは、AのTeredo IPv6アドレスに埋め込まれたマッピングされたアドレス/ポートに直接バブルがアドレス指定されるため、Aの対称NATによってドロップされます。ただし、Aのサーバーを介して間接的なバブルでBを応答させることにより、通信を確立できます（Teredo Server 1）。これで、シナリオは最初のケースに似ており、コミュニケーションが確立されます。
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の背後にあるテレドクライアントとの通信が可能になります。ただし、対称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.
図2（セクション3.1を参照）を再度参照すると、TeredoクライアントAが対称NATの背後に配置されていると仮定し、ポート制限NATの背後に位置するクライアントBとの通信を開始します。クライアントAは、クライアントBのサーバー（Teredo Server 2）を介して、直接バブルと間接バブルをクライアントBに送信します。対称NATの特性に従って、直接バブルのIPv4ソースには、Teredoサーバーに埋め込まれたものとは異なるマッピングアドレスおよび/またはポートが含まれています。クライアントBのNATには通過させる状態がなく、クライアントBにはIPv4/ UDPヘッダーで使用されているマッピングされたアドレス/ポートが学習されないため、この直接バブルがドロップされます。クライアントAからの間接的なバブルに応じて、クライアントBは、クライアントAのTeredo IPv6アドレスに埋め込まれたマッピングされたアドレス/ポートに向けられた直接バブルを送信します。クライアントAのNATには、そのマッピングされたアドレス/ポートに向けられたパケットを受け入れる状態がないため、この直接バブルは削除されます。ただし、直接バブルにより、クライアントBのNATは、クライアントAのTeredo IPv6アドレスに埋め込まれたマップされたアドレス/ポートの発信状態を設定します。
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はクライアントAから直接バブルを誘発する間接的なバブルも送信します。ただし、セクション3.1のケースとは異なり、クライアントAからの直接バブルはクライアントBのNATがマッピングされていないためにドロップされます。クライアントAのNATが使用するアドレス/ポート。クライアントBのNATはポート制限されているため、マッピングされたアドレスとポートの両方が発信状態と同じであることに注意してください。一方、セクション3.1では、クライアントAのNATはマッピングされたアドレスのみを必要とするコーンまたはアドレス制限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クライアントは、IPv4/UDPヘッダーに見られるピアのマッピングアドレス/ポートを、ピアのTeredo IPv6アドレスのマップされたアドレス/ポートと比較します。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.
2つのTeredo IPv6アドレス間で通信が確立されていますが、マッピングはデータ転送の2つの方向で非対称になります。具体的には、着信パケットは、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の背後にあるにもかかわらずTeredo IPv6アドレスを取得できるようになった場合にのみ、この拡張機能は、ポートプレゼンの対称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 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の背後にあるテレドクライアントとの通信が可能になります。ただし、対称NATの背後にあるクライアントは、セクション3.2で説明されているように、ポート制限または対称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の後ろに配置されます。資格手順の終わりに、Teredoクライアントは、セクション3.1で説明されているように、対称NATの背後に配置されているかどうかも知っています。
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の後ろに位置するテレドクライアントは、ランダムに選択したローカルポートでも聴くことができます。ランダムに選択されたローカルポートが、対称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クライアントは、最初の直接バブルを正しい宛先マッピングアドレス/ポートに送信する必要があります。したがって、1つのTeredoクライアントのランダムなポート番号を他のTeredoクライアントに通知するプロトコルメッセージは、間接的に交換する必要があります（Teredoサーバーを介して）。ある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）。この拡張機能は、対称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の後ろに位置するテレドクライアントは、ピアと通信するときにランダムに選択されたローカルポートで聞くこともできます。特定のピアに使用されている外部ポートを予測するために、クライアントは3つのパケットを送信します。Oパケット1は、テレドサーバーアドレスに送信されるルーター勧誘（[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は、セカンダリテレドサーバーアドレスに送信されるルーターの勧誘です。
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と3の外部ポート間の中間にあると推定されます（または予測されます）。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でヘアピニングサポートが利用できない場合、[RFC4380]のセクション8.3で指定されているように、同じNATの背後にある2人のテレドクライアントが互いに通信できません。
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.
Teredoクライアントがマルチナット階層の一部であり、Teredoクライアントが接続されているNATがUPNPプロトコル（[UPNPWANIP]で指定されている）をサポートする場合、TeredoクライアントはUPNPを使用して、に割り当てられたマッピングアドレス/ポートを決定できます。それはナットによって。この情報は、間接バブルを送信する際にローカルアドレス/ポートとともに含めることができます。宛先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.
UPNPサポートは、Teredoクライアントがマルチナット階層の異なるNATの背後にいる場合にのみ必要であることに注意してください。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のマッピング状態を更新するのが最善です。それ自体とテレドピアとの間のコミュニケーションを更新するには、テレドのクライアントは、テレドピアからの直接的なバブル応答を求める必要があります。[RFC4380]のセクション5.2.4で指定されているように、テレドピアからの直接的なバブル応答を求めるために、間接的なバブルが送信されます。ただし、これらの間接的なバブルは、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.
2. Teredoクライアントが応答を求めている直接的なバブルを受け取ると、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].
3. 直接バブルの助けを借りてコミュニケーションを再確立しようとする場合、テレドクライアントは、[RFC4380]のセクション5.2.4で指定されているように、テレドピアとのコミュニケーションを確立するプロセスを介して開始します。
All Teredo messages are transported over the User Datagram Protocol (UDP), as specified in Section 3 of [RFC4380].
すべてのTeredoメッセージは、[RFC4380]のセクション3で指定されているように、ユーザーデータグラムプロトコル（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.
IPv6パケットは、[RFC2460]に適合する場合に有効であるとみなされます。プロトコル識別子はIPv6パケットを示す必要があり、ペイロードの長さはパケットがカプセル化されているUDPデータグラムの長さと一致する必要があります。さらに、クライアントは、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パケットは、次の形式の可変数のタイプレングス値（TLV）エンコードされたトレーラーを運ぶことができます（[RFC2460]セクション4.2で定義されているIPv6オプションの使用に似ています）：
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: 00, 10, 11 - skip over this trailer and continue processing the packet.
トレーラータイプの識別子は内部エンコードされているため、最高の2ビットが、ホストがトレーラーの種類を認識しない場合に使用するアクションを指定するようになります：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.
NonCeトレーラーは、対称NATサポート拡張拡張（したがって、UPNP対象対称NAT拡張およびポートプレゼンティング対称NAT拡張）とヘアピニング拡張機能も使用されます。NonCeトレーラーは、間接的な気泡と直接バブルの両方に存在できます。NonCeトレーラーのNonCEは、対称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バイト）：トレーラーオプションタイプ。このフィールドは0x01に設定する必要があります。
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.
nonce（4バイト）：nonce値。
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.
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バイト）：オプションの残りの残りのバイトの長さ。このフィールドの値は、8〜26の範囲にある必要があります（つまり、予約済みフィールドに2バイト、代替アドレス/ポートリストの各エントリの6バイト）。これにより、最低1つのアドレス/ポートマッピングと、宣伝される最大4つのアドレス/ポートマッピングが可能になります。最大2つのアドレス/ポートマッピングはTeredoで決定できるため、最大14である必要があります。1つはローカルアドレス/ポートを使用し、1つは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サーバーを介してそれらを中継することなくパケットを送信できます。Neighbor Discovery Option Trailerを使用すると、レシーバーは、通常の直接バブルに対して応答を求めている直接バブルを区別できます。これにより、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（0x00）：受信機は、discoveryType teredodiscoveryAdvertisementの直接バブルで応答するように要求されます。
TeredoDiscoveryAdvertisement (0x01): The direct bubble is in response to a direct bubble or an indirect bubbles containing DiscoveryType TeredoDiscoverySolicitation.
teredodiscoveryadisement（0x01）：直接バブルは、直接バブルまたは発見型テレドディズコバビリソリエーションを含む間接的なバブルに対応しています。
Reserved (3 bytes): This field MUST be set to 0x000000 on transmission and ignored on receipt.
予約済み（3バイト）：このフィールドは、送信時に0x000000に設定し、受領時に無視する必要があります。
The Random Port Trailer is used by the Port-Preserving Symmetric NAT Extension in both indirect and direct bubbles.
ランダムポートトレーラーは、間接バブルと直接バブルの両方で、ポートプレゼント対称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バイト）：オプションの残りの残りのバイトの長さ。このフィールドは0x02に設定する必要があります。
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.)
他の実装固有の時間に接続が確立されるのは、初めてピアに送られたパケットに相当するパケットです。（たとえば、ピアの近隣キャッシュエントリがプローブ状態にある場合、実装がそうすることを選択する場合があります。）
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 Refreshインターバル」を取ります。このパラメーターは最初は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秒である必要があると言うことにより、動作を改良します。実装により、ランダム化された更新間隔を実装固有の範囲内でランダムに選択した値に設定する場合があります。このような範囲は、リフレッシュ間隔の50％から150％以内でなければなりません。
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;
定期的に、クライアントは「Teredoサーバーとの最後の相互作用の日付と時刻」をチェックして、最後のランダム化されたTeredo Refresh間隔で少なくとも1つのパケットが受信されたことを確認する必要があります。そうでない場合、セクション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クライアントは、他の実装固有の時間に追加のルーター勧誘メッセージをサーバーに送信することを選択できます。（たとえば、ルーターの近隣キャッシュエントリがプローブ状態にある場合、実装がそうすることを選択する場合があります。）
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は、直接IPv6接続テストを指定して、ピアのTeredo IPv6アドレスのマッピングされたアドレス/ポートがスプーフィングされていないことを判断します。これは、ICMPV6エコーリクエストと応答メッセージ（[RFC443]のセクション4で定義されている）でNonCEを使用して行います。ただし、直接IPv6接続テストは、Teredo IPv6アドレスと非テレドIPv6アドレス間の通信のみに限定されます。次の拡張機能では、直接および間接バブルでNonCEの使用を導入し、マッピングされたアドレス/ポートがスプーフィングされていないことを確認するメカニズムを提供します。
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 Peerに送信された最後の間接的なバブルで送信されたNonceの値。
o Nonce Received: The value of the nonce received in the last indirect bubble received from the Teredo peer.
o NONCEを受け取った：テレドピアから受け取った最後の間接的なバブルで受け取ったノンセの価値。
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.
間接的なバブルがテレドピアに送られた場合の規則は、[RFC4380]のセクション5.2.6で指定されています。Teredoのクライアントが間接的なバブルを送信する場合、ランダムな4バイト値を生成し、間接的なバブルに追加されたNonCEトレーラー（セクション4.2）のNonCEフィールド（セクション4.2）に含める必要があり、そのnonCE送信フィールドにも保存する必要があります。そのテレドピアのピアエントリ。
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.
直接バブルがテレドピアに送信される場合の規則は、[RFC4380]のセクション5.2.6で指定されています。Teredoのクライアントが、NonCeトレーラーで間接的なバブルを受け取った後に直接バブルをピアに送信する場合、同じNonCe値を持つNonCe Trailerを直接バブルに含める必要があります。
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 Peerから間接的なバブルを受け取る前に直接バブルを送信しようとしている場合、TeredoクライアントはNonCeトレーラーを含めてはなりません。
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クライアントがNonCEトレーラーを含む間接的なバブルを受信する場合、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.
さらに、マッピングされたアドレス/ポートが埋め込みアドレス/ポートと一致しないが、直接バブルには、テレドピアのノンセ送信フィールドに一致するノンセを備えたノンセトレーラーが含まれている場合、直接バブルを受け入れる必要があります。
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で指定されているように、テレドピアのマップされたアドレス/ポートフィールドで直接バブルが受信されるマッピングされたアドレス/ポートを記録する必要があります。
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に設定されたブール値です。このフラグのデフォルト値は偽です。
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マップアドレス/ポート：UPNP対応のNATによってTeredoクライアントにAUPNPを介して割り当てられたマッピングされたアドレス/ポートは、Teredoクライアントが配置されています。このフィールドには、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 対称ピアフラグ：これはブール値であり、テレドピアが対称NATの後ろに配置されている場合に当てはまります。
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マップポート：UPNPを介してTEREDOクライアントに割り当てられたマッピングされたポートは、Teredoクライアントが配置されているUPNP対応のNATによってASTEREDOクライアントに割り当てられています。この値は、両方がゼロではない場合、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クライアントは、まず、セクション5.3.5.1で指定されたUNINITALIALIZALIATION手順を実行する必要があります。
The Teredo client MUST then invoke the AddPortMapping function, as specified in Section 2.4.16 of [UPNPWANIP], with the following parameters:
Teredoクライアントは、[UPNPWANIP]のセクション2.4.16で指定されているように、次のパラメーターを使用して、AddPortMapping関数を呼び出す必要があります。
o NewRemoteHost: "" (empty string)
o NewRemoteHost： ""（空の文字列）
o NewExternalPort: Local Port value
o NewExternalport：ローカルポート値
o NewProtocol: UDP
o NewProtocol：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 NewLeaduration：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がNATの外部ポートからTeredoクライアントノードの内部ポートへのポートマッピングを作成したことを示しています。パラメーターは、外部ホストがマッピングされたアドレス/ポートにパケットを送信して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.
Teredoクライアントは、AddportMappingで指定されたローカルポート値にUPNPマップポート（サポートされている場合は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クライアントは、getExternalIpAddress関数から返されたアドレスにUPNPマップアドレスを設定し、UPNP対応のNATフラグをTRUEに設定する必要があります。
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.
資格手順（[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.
資格手順の後、Teredoサーバーから学習したマッピングされたアドレス/ポートをUPNPマップアドレス/ポートと比較する必要があります。両方が同じ場合、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 IPv6アドレスに埋め込まれたマップされたアドレス/ポートに送信されるすべてのパケットを受け取ります。したがって、Teredoクライアントが直接バブルを受信する場合、IPv6ヘッダーのソースアドレスフィールドのTeredo IPv6アドレスに埋め込まれたマップされたアドレス/ポートでパケットが受信されたマッピングされたアドレス/ポートを比較する必要があります。2つが同じでない場合、テレドピアが対称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.
o UPNPマップされたアドレス/ポートはゼロに設定されています。
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クライアントは、Peerの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.
o UPNPマップされたアドレス/ポートはゼロに設定されています。
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:
マッピングされたポートがゼロ以外の場合、Teredoクライアントは、[UPNPWANIP]のセクション2.4.17で指定されているように、次のパラメーターを使用して、DeleTePortMapping関数を呼び出す必要があります。
o NewRemoteHost: "" (empty string)
o NewRemoteHost： ""（空の文字列）
o NewExternalPort: the mapped port
o newExternalport：マッピングされたポート
o NewProtocol: UDP
o NewProtocol：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拡張はオプションです。実装はそれをサポートする必要があります。この拡張機能には、依存関係として対称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.
このセクションでは、このプロトコルに参加するために実装が維持する可能性のあるデータ組織の概念モデルについて説明します。記述された組織は、プロトコルの動作の説明を促進するために提供されます。このドキュメントでは、外部の動作がこのドキュメントで説明されているものと一致している限り、実装がこのモデルに付着することを義務付けていません。
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.
ポートプレゼンティングナットフラグ：これはブール値です。Teredoクライアントがポートプレゼンティングナットの後ろに配置されている場合、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 Peerからパケットが受信された場合に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クライアントはピアのリストを調べて、Teredoクライアントがランダムポートを介して通信しているピアごとに、Teredoクライアントは最後のデータパケット送信されたタイムスタンプをチェックしてデータがあるかどうかを判断する必要があります。過去30秒でピアに送信し、接続更新フィールドをチェックして、カウントが20の最大許容値に達したかどうかを判断します。両方のチェックが偽の場合、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.
[RFC4380]で指定された動作に加えて、Teredoクライアントが開始されたときに、港湾給与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.
資格手順（[RFC4380]のセクション5.2.1で指定）中に、TeredoクライアントがTeredoサーバーアドレスから応答を受信する場合、Teredoクライアントはセクション5.1で指定されているように、原点表示のポート値を比較する必要があります。[RFC4380]の1、ローカルポート値。両方の値が一致する場合、クライアントはポート予約済みのNATフラグをtrueに設定する必要があります。
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 Peerに送信されるデータパケットを受信すると（[RFC4380] 5.2.4セクション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:
間接バブルを送信するためのルールは、このドキュメントのセクション5.2.4.1および[RFC4380]のセクション5.2.6で指定されているとおりです。これらのルールに加えて、港湾給与のNATフラグが真実である場合、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.
o 対称NATフラグが設定されている場合、テレドピアは「[RFC4380]のセクション5.2で指定されているように）「信頼性」としてマークされておらず、ランダムポートはゼロです。そして、そのポートで聞き始めます。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で指定されているとおりです。さらに、セクション5.2.4.2は、対称NATの背後に位置するクライアントの通信を有効にするためのルールを定義します。前述の両方のセクションで定義されているルールに加えて、港湾給与のNATフラグが真である場合、次のルールも適用されます。
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フラグが設定され、テレドピアが「信頼」としてマークされていない場合（[RFC4380]のセクション5.2で指定されているように）、テレドクライアントは、テレドIPv6に埋め込まれたマッピングされたアドレス/ポートに導かれた直接バブルを送信する必要があります。テレドピアの住所。ピアランダムポートフィールドがゼロでない場合、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.
間接バブルを処理するためのルールは、このドキュメントのセクション5.2.4.3および[RFC4380]のセクション5.2.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クライアントは、ピアエントリのピアランダムポートフィールドにランダムポートトレーラーからポートを保存する必要があります。
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クライアントは、Peerランダムポートフィールドに新しい広告ポート値を保存する必要があります。NATフラグは真実で、ランダムポートフィールドをクリアし、古いランダムポートでリスニングを停止します。これにより、いずれかの側が使用しているランダムポートが変更された場合、通信を再確立できます。
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:
直接バブルを処理するためのルールは、このドキュメントのセクション5.2.4.4および[RFC4380]のセクション5.2.3で指定されています。直接バブルを受け入れるかどうかのルールは、港湾給与のNATフラグが真である場合、次のように拡張されます。
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.
o プライマリポートで直接バブルが受信され、テレドピアが「信頼」されていない場合、テレドクライアントのステータスフィールドを「信頼」に変更する必要があり、プライマリポートフラグの直接受信を真に設定する必要があります。[RFC4380]のセクション5.2で指定されているように、Teredo Peerのマップされたアドレス/ポートフィールドに直接バブルを受信したマッピングアドレス/ポートを記録する必要があります。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 直接バブルがプライマリポートで受信された場合、テレドピアは「信頼」であり、プライマリフラグの直接受信がTrueに設定されている場合、Teredoクライアントは、直接バブルのマップされたアドレス/ポートとマッピングされたアドレス/ポートを比較する必要があります/ピアエントリのポート。両方のマッピングが同じ場合、直接バブルを受け入れる必要があります。マッピングが異なっており、Teredo Peerとの最後のパケット交換から30秒以上経過している場合（つまり、[RFC4380]のセクション5.2で定義されているように、「最後の伝送の時間」と「最後の受信の時間」、「最後の受信の時間」、30秒以上前の時間に設定されています）、Teredo PeerのNATのマッピングは変更され、コミュニケーションを再確立する必要があります。これは、ピアのステータスを「トラストされていない」に変更し、プライマリポートフラグの直接受信を偽に設定し、テレドサーバーを介してテレドピアに間接的なバブルを送信することによって行う必要があります。
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 直接バブルがプライマリポートで受信された場合、テレドピアは「信頼」され、プライマリポートフラグの直接受信がfalsに設定され、ランダムなポートフラグの直接受信が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].
o 直接バブルがランダムポートで受信され、Teredoピアが「信頼」されていない場合、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 Peerは「信頼」であり、プライマリポートフラグの直接受信が偽である場合、Teredoクライアントは、マップされたアドレス/ポートのマップされたアドレス/ポートをマップされたアドレス/ポートと比較する必要があります。ピアエントリで。2つのマッピングが同じ場合、直接バブルを受け入れる必要があります。マッピングが異なる場合、NATがマッピングを削除し、マッピングを再割り当てしたときに別の外部ポートが選択されたことを意味します。この例では、Teredoクライアントは、ランダムポートフィールドをゼロに設定し、古いランダムポートでのリスニングを停止し、セクション5.4.4.2で指定されているようにテレドピアに間接的なバブルを送信する必要があります。
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.
プライマリポートフラグの直接受信が真実になると、クライアントはランダムポートでのリスニングを停止するため、ランダムポートで直接バブルを受信できないことに注意してください。その結果、このケースは意図的に上記で省略されています。
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.
o EchotestNonce1：[RFC4380]のセクション5.1.1で指定されている認証カプセル化の一部として送信されたNonCEの値は、Echoテストの一部としてTeredo Serverアドレスに送信されたルーター勧誘パケットで指定されています。
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.
o EchotestNonce2：エコーテストの一部としてセカンダリテレドサーバーアドレスに送信されたルーター勧誘パケットの認証カプセル化の一部として送信されるノンセの値。
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：ECHOテストの一部として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：エコーテストの一部として、セカンダリテレドサーバーアドレスから受け取ったルーター広告の原点表示から抽出された外部ポートマッピングの値。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.
エコテストレットカウンターの値が2の場合、テレドクライアントはセクション5.2.4.1で指定されているように間接的なバブルを送信する必要があります。
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.
エコテストレットカウンターの値が1つの場合、Teredoクライアントはセクション5.5.4.1.1で指定されているように別のエコーテストを開始する必要があります。
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フラグが真であり、ポートを摂取するNATフラグが間違っている場合、その時点で次のアクションが適用されます。[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フラグが真であり、ポートを差し引いたNATフラグが偽で、テレドピアが「信頼」としてマークされていない場合（[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 第三に、ルーターの勧誘をセカンダリテレドサーバーアドレスに送信する必要があります。ルーターの勧誘には、[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クライアントは、エコテストレトリカウンターを増加させ、エコーテストフェールオーバータイマーをエコテストレトリカウンターに等しい数秒で期限切れに設定する必要があります。
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.
間接バブルを送信するためのルールは、このドキュメントのセクション5.2.4.1および[RFC4380]のセクション5.2.6で指定されているとおりです。これらのルールに加えて、対称NATフラグが真であり、ポートを圧縮するNATフラグが偽で、ランダムポート値がゼロである場合、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フラグが真であるかのように、セクション5.4.4.5で指定されているように完了する必要があります。処理が完了した後、プライマリフラグで受信した直接バブルが真であり、エコーテストフェイルオーバータイマーが実行されている場合、エコーテストフェイルオーバータイマーをキャンセルし、エコテストラワーポート、エコテストレッパーポート、およびエコテストレットカウンターをゼロに設定する必要があります。
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フィールドが認証カプセル化のNONCEと一致するピアエントリを探す必要があります。ピアエントリが見つかった場合、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.
UPNPマッピングアドレス/ポート：UPNPを介してTeredoクライアントに割り当てられたマップされたアドレス/ポートは、Teredoクライアントが配置されているUPNP対応NATによってTeredoクライアントに割り当てられています。このフィールドには、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で指定されたパラメーターを使用して、AddPortMapping関数（[UPNPWANIP]のセクション2.4.16で指定）を呼び出す必要があります。成功した場合、NATがNATの外部ポートからTeredoクライアントノードの内部ポートへのポートマッピングを作成したことを示しています。AddPortMapping関数が成功した場合、Teredoクライアントは、NATが割り当てたマッピングをUPNPマッピングアドレス/ポート状態に保存する必要があります。
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.
資格手順の後、Teredoサーバーから学習したマップされたアドレス/ポートをUPNPマッピングアドレス/ポートと比較する必要があります。両方が同じ場合、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クライアントは間接的なバブルに代替アドレストレーラーを含める必要があります。代替アドレストレーラーには、代替アドレス/ポートリストにノードのローカルアドレス/ポートを含める必要があります。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.
ヘアピニングでは、「直接IPv6接続テスト」（[RFC4380]のセクション5.2.9で指定されているように）が必要です。IPv4アドレスからパケットを受け入れ、テレドIPv6アドレスに埋め込まれていないポートを受け入れる前に成功する必要があります。したがって、間接的なバブルには、非CEトレーラーも含める必要があります。
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値を持つ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.
マッピングされたアドレス/ポートが埋め込みアドレス/ポートと一致しないが、直接バブルには、テレドピアのノンセ送信フィールドに一致するノンセを備えたノンセトレーラーが含まれている場合、直接バブルを受け入れる必要があります。
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 Neighbor Solicitationパケットを再送信するために使用されるタイマー。
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つになった場合）、テレドのピアに間接的なバブルを送信して、テレドクライアントとテレドピアの間の通信が確立されていないかのように接続を再確立する必要があります。
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 Peerに送信されるデータパケットを受信すると、Teredoクライアントは、Teredoクライアントとピアの間でデータが過去30秒でどちらの方向に交換されているかを判断する必要があります（[RFC4380]のセクション5.2で指定されている状態を使用して）。そうでない場合、Teredoクライアントは、DiscoveryTypeフィールドがテレドディスコリソリテーションに設定された隣接するオプショントレーラーを使用して直接バブルを送信する必要があります。勧誘フィールドのカウントは、1に設定する必要があります。再送信タイマーは、2秒で期限切れに設定する必要があります。
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で指定されているとおりです。これらのルールに加えて、discoveryTypeフィールドをテレドディスコリソリテーションに設定したDiscoveryTypeフィールドを備えた近隣ディスカバリーオプショントレーラーを含む直接バブルを受信すると、Teredoクライアントは、DiscoveryTypeフィールドをTeredodiscoveryAdvertisementementに設定したNeighbor Discoveryオプショントレーラーで直接バブルで応答する必要があります。
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).
次に、次のパケット交換は、（an）テレドクライアント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
アドレス制限されたNATパケット交換へのポート対称NAT
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アドレスに埋め込まれたマッピングされたポートとは異なります。これは、パケットのソースフィールドのマッピングされたアドレスの前に配置されたポート対称NATの特徴です。AのテレドIPv6アドレスに埋め込まれたマップされたアドレスと同じです。
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.
2. 前述の直接バブルは、AのマッピングされたIPv4アドレスに向けられた発信パケットを見ていないため、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.
5. 上記の直接バブルは、AのTeredo IPv6アドレスに埋め込まれ、BのTeredo IPv6アドレスに埋め込まれたマッピングされたアドレス/ポートに埋め込まれたマッピングアドレス/ポートから供給された発信パケットを見ていないため、AのNATによってドロップされます。
6. B also sends an indirect bubble (Packet 4) destined to A via A's Teredo Server.
6. Bは、AのViaの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).
8. 今回は、前述の直接バブル周辺のBのNATによって受け入れられています。これは、NATがBのTeredo IPv6アドレスに埋め込まれ、AのTeredo IPv6に埋め込まれたマッピングされたアドレス/ポートに埋め込まれたマップされたアドレス/ポートから供給された発信パケット（パケット3）を見たため、受け入れられています。住所。AのNATはポート対称であり、したがってマッピングされたポートのみが変化し、マッピングされたアドレスが同じままであることを覚えておくことが重要です。BのNATはアドレス制限であり、特定のポートではなく、IPv4アドレスとの事前の通信のみを気にしています。この時点で、一方向での通信が可能になりました（BからA、しかしその逆ではありません）。
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アドレスに埋め込まれたマッピングされたアドレス/ポートの代わりにAとの将来の通信にそれらを使用します。
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は直接バブルを許可します。コミュニケーションが他の方向に可能になりました（クライアントAからB）。
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.
両方のクライアントが資格手順を開始する前に、UPNPを使用してそれぞれのNATのポートマッピングを予約します。したがって、UPNPの運用は、クライアントとクライアントの両方で成功しているため、UPNP対応NATの後ろに配置されていることがわかります。資格手順の後、両方のクライアントが有効なTeredo IPv6アドレスを持っています。両方とも対称NATサポート拡張をサポートするためです。また、資格手順の後、両方のクライアントは、UPNPを介して決定されたマッピングされたアドレス/ポートを、資格手順を通じて決定されたマッピングされたアドレス/ポートを比較します。どちらも同じであるため、クライアントはUPNPマッピングアドレス/ポート値をゼロにし、それぞれが単一のUPNP対応NATの後ろにあると結論付けます。
The following packet exchange shows Teredo client A (A) establishing communication with Teredo client B (B).
次のパケット交換は、Teredoクライアントが（an）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
| | | | | |
UPnP-enabled Symmetric NAT Packet Exchange
UPNP対応対称NATパケット交換
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).
2. 上記の直接バブルはBによって受信されます。これは、BのUPNPマッピングアドレス/ポート用に運命づけられているため、NATによって通過するためです。この時点で、bは、直接バブルが受信されるマッピングされたアドレス/ポートがAのTeredo IPv6アドレスに埋め込まれているマッピングされたアドレス/ポートとは異なるため、Aが対称NATの背後に配置されることを推測します。したがって、ピアは対称NATの後ろに配置されているため、直接バブルが受信されたマッピングされたアドレス/ポートではなく、AのTeredo IPv6アドレスに埋め込まれたマップされたアドレス/ポートにデータパケットが送信されることを覚えています。この時点で、一方向での通信が可能になりました（BからA、しかしその逆ではありません）。
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によって受信されます。次に、ステップ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).
5. AのNATもUPNPを有効にしているため、上記の直接バブルはAによって受信されます。Aは、パケットが受信されるマッピングされたアドレス/ポートがマッピングされたアドレス/ポートとは異なるため、Bが対称NATの背後に配置されていることにも気付きます。BのTeredo IPv6アドレスに埋め込まれています。したがって、ピアは対称NATの後ろに配置されているため、直接バブルが受信されたマップされたアドレス/ポートではなく、BのTeredo IPv6アドレスに埋め込まれたマップされたアドレス/ポートにデータパケットが送信されることを覚えています。この時点で、コミュニケーションが他の方向（AからB）で可能になりました。
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.
1. 資格手順中に、クライアントがTeredoサーバーから応答を受け取ると、Originの表示のポート値をローカルポート値と比較します。両方の値が一致した場合、クライアントはポートを圧縮するNATフラグをtrueに設定します。
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. 応答がセカンダリテレドサーバーから受信されると、オリジン表示のマッピングされたアドレス/ポート値は、プライマリサーバーから受信した応答から学習したマップされたアドレス/ポート値と比較されます。マッピングが異なる場合、対称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.
4. aがパケットをBに送信する前に、港湾給与NATと対称NATの後ろに配置されているかどうかを確認するためにチェックします。また、ピアが「信頼されている」かどうかを確認しますが、現在はそうではありません。次に、ランダムポートがゼロ以外に設定されているかどうかを確認します。まだゼロであるため、新しいランダムポートを割り当て、リスニングを開始し、ランダムポートフィールドに値を保存します。
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.
6. NATはAのマッピングされたアドレスに運命づけられた発信パケットを見ていないため、前述の直接バブルは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を含むNonCEトレーラーと、ピアエントリからのランダムポート値を含むランダムポートトレーラーの2つのトレーラーが含まれています。NONCEトレーラーで使用されているNonCEは、ピアエントリの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は、テレドピアをピアリストに追加します。Bは、ピアエントリのNonCe宣伝されたフィールドのNonCEトレーラーからNonCE値を保存します。bピアエントリのピアランダムポートフィールドにランダムポートトレーラーからポート値を保存します。
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）です。このパケットはプライマリポートから送信されます。これには、ピアエントリのNonCe宣伝されたフィールドからのNonCEを備えたNonCEトレーラーが含まれています。
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.
10. 前述の直接バブルは、AのTeredo IPv6アドレスに埋め込まれ、BのTeredo IPv6アドレスに埋め込まれたマッピングされたアドレス/ポートに埋め込まれたマッピングアドレス/ポートから供給された発信パケットを見ていないため、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. AのTeredo IPv6アドレスに埋め込まれたマッピングされたアドレスとA.によって宣伝されたランダムポートからNATが供給された発信パケットを見ていないため、上記の直接バブルは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のViaのTeredoサーバーに向けられた間接的なバブル（パケット5）も送信します。この間接的なバブルには、ノンセトレーラーとランダムポートトレーラーが含まれています。NONCEトレーラーには、ピアエントリのNONCE送信フィールドにも保存されている新しいランダムに生成されたノンセが含まれています。ランダムポートトレーラーには、ピアエントリのランダムポートフィールドに値が含まれています。
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.
14. 前述の間接的なバブルは、Aに正常に受信されます。Aはトレーラーを解析し、ピアエントリのノンセの受信フィールドのノンセトレーラーに含まれるノンセを保存します。ピアエントリのランダムポートフィールドにあるランダムポートトレーラーに宣伝されているポートが保管されています。
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.
16. NATが着信パケットと同じ4タプルを持つ発信パケットを見ていないため、前述の直接バブルは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 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).
18. どちらのNATがポート圧力NATであり、ランダムポートは他のマッピングに使用されていないため、BのNATには同じアドレス/ポートペアを持つ発信パケット（パケット4）が見られたため、前述の直接バブルはBによって受信されます。Bは、ピアエントリのマップされたアドレス/ポートフィールドに直接バブルが受信されたアドレス/ポートを保存します。ピアのステータスを「信頼」に変更し、ランダムポートフィールドで直接受信をtrueに設定します。この時点で、一方向での通信が可能になりました（BからA、しかしその逆ではありません）。
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トレーラーの一部として新しい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は、前述の間接的なバブルを受け取ります。この間接バブルの処理は、パケット2の処理に似ています。Bはランダムポートで直接バブルを受けたため、主要なポートから直接バブルで応答しません。代わりに、ランダムポートから送信された直接バブル（パケット9）で応答します。これは、上記のパケット4に似ています。
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. Bが送信した直接バブルを受信します。Aは、ピアエントリのマップされたアドレス/ポートフィールドで直接バブルが受信されたマップされたアドレス/ポートを保存します。aはBのステータスを「信頼性」に変更し、ランダムポートフィールドで直接受信をtrueに設定します。この時点で、コミュニケーションが他の方向（AからB）で可能になりました。
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.
TeredoクライアントA（a）は、シーケンシャルポート対称NATの背後に配置され、シーケンシャルポート対称NAT拡張機能を実装していると仮定し、テレドクライアント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.
1. 資格手順中に、クライアントAがTeredoサーバーから応答を受信すると、原点表示のポート値をローカルポート値と比較します。それらは異なっているため、港湾給与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がクライアントBのNATタイプを知らないために発生します。クライアントBのNATタイプは、制限付きNATまたはUPNP対応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を積極的に開きます。
4. Client A then performs its Echo Test as follows:
4. クライアントAは次のようにエコーテストを実行します。
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).
A.クライアントAは、ポート1100からTeredoサーバーアドレスにルーター勧誘（パケット2）を送信します。サーバーはルーター広告（パケット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のテレドアドレス（たとえば、ポート2100）に宣伝されているポートに向けられたポート1100のピアに直接バブル（パケット4）を送信します。この直接バブルは、クライアントBのポート制限NATによって削除されます。
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は、ポート1100からルーター勧誘（パケット5）をセカンダリテレドサーバーアドレスに送信します。サーバーはルーター広告（パケット6）で応答します。
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は、ポート1100がパケット2のポート1200とパケット4のポート1202をマップすることを知っています。
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は、パケット2に使用される予測ポートを1200および1202の平均（丸みを帯びた）、つまり1201として計算します。
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）を送信します。この間接的なバブルには、予測されたポート、ポート1201を含むランダムポートトレーラーが含まれています。この間接的なバブルは、クライアントBになります。
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.
A.最初の直接バブル（パケット8）は、クライアントAのTeredoアドレスに埋め込まれたポートマッピングに向けられています。（一部のNATは、発信パケットの対称NATの動作を表示するが、着信パケットのコーンNATの動作を表示することが観察されています。説明した直接バブルは、クライアントAのNATがそのような動作を表示すると成功する可能性があります。）この例では、AのNATはAです。通常のシーケンシャルポート対称NAT、このパケットは削除されます。
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.次のパケットは、ポート1201に送信される直接バブル（パケット10）です。このパケットは、クライアントA以前に同じ4タプルで発信パケット（パケット4）を送信したため、クライアントAに導入されます。この時点で、一方向での通信が可能になりました（AからB、しかしその逆ではありません）。
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を受け取ったときにクライアントBに直接バブル（パケット11）を送信します。今回は、以前に同じ4タプルで発信パケット（パケット10）を送信したため、バブルがBに到達します。この時点で、コミュニケーションが他の方向（BからA）で可能になりました。
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）では、テレドクライアントA（a）およびテレドクライアントB（b）は、2層NATトポロジの異なる即時NATの後ろに配置されています。つまり、最も外側のNAT（NAT E）はAとBの両方に共通していますが、接続されている直接のNATは異なります（AはNAT Fに接続され、BはNAT Gに接続されます）。さらに、aとbが接続されている直接的なNATがUPNP対応であると仮定します（NAT FとNAT Gは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].
次に、クライアントAとクライアントBの両方が、[RFC4380]のセクション5.2.1で指定されているように、マッピングされたアドレス/ポート値を決定する資格手順を実装します。
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.
4. 前述の間接的なバブルは、Bによって受信されます。代替アドレストレーラーを解析した後、Bには合計3つのアドレスがあります。代替アドレストレーラーの2つ、1つはAのTeredo IPv6アドレスに埋め込まれています。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.
7. 前述の直接バブルは、AとBが異なるNATの背後に配置されているため、独自のプライベートアドレススペースを持っているため、ドロップされます。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のUPNPマッピングアドレス/ポートに運命づけられたBによって送信されます。これは、Aが送信した代替アドレストレーラーの2番目のマッピングです。
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.
9. 前述の直接バブルは、AのUPNPマップアドレスがBから到達できるため、Aによって受信されます。RFC4380]。また、マッピングされたアドレスステータスフィールド（[RFC4380]のセクション5.2.3で指定）は「信頼性」に変更されます。この時点で、一方向（a〜b）での通信が可能になりましたが、bがまだ信頼できるとマークしていないため、逆はありません。
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は、間接的なバブル（パケット6）をA ViaのTeredoサーバーに送信します。間接バブルの一部として、Bには、ローカルアドレス/ポートとBのUPNPマッピングアドレス/ポートが含まれる代替アドレストレーラーも含まれています。
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によって受信されます。代替アドレストレーラーを解析した後、代替アドレストレーラーの2つのアドレスをピアエントリの代替アドレスリストに追加します。ピアのマッピングは「信頼」であるため（ポイント9）、ピアエントリに保存されているマッピングされたアドレス/ポートに送信される直接バブル（パケット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は、ピアエントリのマップされたアドレス/ポートフィールドで直接バブルが受信されたマップされたアドレス/ポートを記録し、マッピングされたアドレスのステータスを「信頼性」に変更します。この時点で、コミュニケーションが他の方向（BからA）で可能になりました。
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）とのコミュニケーションを確立したと仮定します。また、両方のクライアント間で30秒以上のデータパケットが交換されていない場合の後の時点で、データパケットをBに送信したいため、通信を再確立する必要があると仮定します。
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は、DiscoveryTypeフィールドがTeredodiscoversolicititationに設定された、Neighbor Discoveryオプショントレーラーで直接バブル（パケット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によって受信されます。Bは隣接発見オプションを解析し、発見タイプがテレドディスコビバリシュリテーションに設定されたため、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で指定されているように）使用されているため、間違った場所にトラフィックを向けるバブルのスプーフィングを防ぐため、攻撃者がその価値を予測できないようにノンセがランダムであることが重要です。ランダム性要件の詳細については、[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.
この文書に技術的な貢献をしてくれたGurpreet VirdiとPoorna Gaddehosur、およびV6ops WGとJari Arkkoの有益なレビューに感謝します。
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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 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：ネットワークアドレス翻訳（NAT）を介してUDPを介したIPv6のトンネル」、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.、Simpson、W。、およびH. Soliman、「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] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、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] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン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. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。
Author's Address
著者の連絡先
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Dave Thaler Microsoft Corporation One Microsoft Way Redmond、WA 98052 USA
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com