[要約] 要約：RFC 5770は、ネットワークアドレストランスレータのトラバーサルのための基本的なホスト識別プロトコル（HIP）の拡張に関するものです。 目的：このRFCの目的は、HIPを使用してネットワークアドレストランスレータをトラバースするための拡張機能を提供することです。
Internet Engineering Task Force (IETF) M. Komu
Request for Comments: 5770 HIIT
Category: Experimental T. Henderson
ISSN: 2070-1721 The Boeing Company
H. Tschofenig
Nokia Siemens Networks
J. Melen
A. Keranen, Ed.
Ericsson Research Nomadiclab
April 2010
Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators
ネットワークアドレス翻訳者のトラバーサルのための基本ホストIDプロトコル（HIP）拡張
Abstract
概要
This document specifies extensions to the Host Identity Protocol (HIP) to facilitate Network Address Translator (NAT) traversal. The extensions are based on the use of the Interactive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulating Encapsulating Security Payload (ESP) packets within the User Datagram Protocol (UDP). This document also defines elements of a procedure for NAT traversal, including the optional use of a HIP relay server. With these extensions HIP is able to work in environments that have NATs and provides a generic NAT traversal solution to higher-layer networking applications.
このドキュメントは、ネットワークアドレス翻訳者（NAT）トラバーサルを促進するために、ホストIDプロトコル（HIP）への拡張機能を指定します。拡張機能は、インタラクティブ接続確立（ICE）方法論の使用に基づいており、2つのエンドホスト間の作業パスを発見し、ユーザーデータグラムプロトコル（UDP）内のセキュリティペイロード（ESP）パケットをカプセル化するための標準手法です。このドキュメントでは、HIPリレーサーバーのオプションの使用を含む、NATトラバーサルの手順の要素も定義しています。これらの拡張機能により、HIPはNATを持つ環境で動作し、高層ネットワーキングアプリケーションに一般的なNATトラバーサルソリューションを提供できます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc5770.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5770で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Overview of Operation ...........................................7
4. Protocol Description ............................................8
4.1. Relay Registration .........................................8
4.2. ICE Candidate Gathering ...................................10
4.3. NAT Traversal Mode Negotiation ............................10
4.4. Connectivity Check Pacing Negotiation .....................12
4.5. Base Exchange via HIP Relay Server ........................12
4.6. ICE Connectivity Checks ...................................15
4.7. NAT Keepalives ............................................16
4.8. Base Exchange without ICE Connectivity Checks .............16
4.9. Initiating a Base Exchange Both with and without
UDP Encapsulation .........................................17
4.10. Sending Control Packets after the Base Exchange ..........18
5. Packet Formats .................................................18
5.1. HIP Control Packets .......................................19
5.2. Connectivity Checks .......................................19
5.3. Keepalives ................................................20
5.4. NAT Traversal Mode Parameter ..............................21
5.5. Connectivity Check Transaction Pacing Parameter ...........22
5.6. Relay and Registration Parameters .........................22
5.7. LOCATOR Parameter .........................................23
5.8. RELAY_HMAC Parameter ......................................25
5.9. Registration Types ........................................25
5.10. Notify Packet Types ......................................26
5.11. ESP Data Packets .........................................26
6. Security Considerations ........................................27
6.1. Privacy Considerations ....................................27
6.2. Opportunistic Mode ........................................27
6.3. Base Exchange Replay Protection for HIP Relay Server ......28
6.4. Demuxing Different HIP Associations .......................28
7. IANA Considerations ............................................28
8. Contributors ...................................................29
9. Acknowledgments ................................................29
10. References ....................................................29
10.1. Normative References .....................................29
10.2. Informative References ...................................30
Appendix A. Selecting a Value for Check Pacing ....................32
Appendix B. Base Exchange through a Rendezvous Server .............33
HIP [RFC5201] is defined as a protocol that runs directly over IPv4 or IPv6, and HIP coordinates the setup of ESP security associations [RFC5202] that are also specified to run over IPv4 or IPv6. This approach is known to have problems traversing NATs and other middleboxes [RFC5207]. This document defines HIP extensions for the traversal of both Network Address Translator (NAT) and Network Address and Port Translator (NAPT) middleboxes. The document generally uses the term NAT to refer to these types of middleboxes.
HIP [RFC5201]は、IPv4またはIPv6を直接実行するプロトコルとして定義され、HIPはESPセキュリティ関連[RFC5202]のセットアップを調整します。このアプローチは、NATやその他のミドルボックスを通過する問題があることが知られています[RFC5207]。このドキュメントでは、ネットワークアドレス翻訳者（NAT）とネットワークアドレスおよびポート翻訳者（NAPT）ミドルボックスの両方のトラバーサルのヒップ拡張機能を定義しています。ドキュメントは通常、NATという用語を使用して、これらのタイプのミドルボックスを参照しています。
Currently deployed NAT devices do not operate consistently even though a recommended behavior is described in [RFC4787]. The HIP protocol extensions in this document make as few assumptions as possible about the behavior of the NAT devices so that NAT traversal will work even with legacy NAT devices. The purpose of these extensions is to allow two HIP-enabled hosts to communicate with each other even if one or both of the communicating hosts are in a network that is behind one or more NATs.
現在展開されているNATデバイスは、[RFC4787]で推奨される動作が説明されていても、一貫して動作しません。このドキュメントの股関節プロトコル拡張は、NATトラバーサルがレガシーNATデバイスでも機能するように、NATデバイスの動作について可能な限り少ない仮定を作成します。これらの拡張機能の目的は、1つまたは両方の通信ホストが1つ以上のNATの背後にあるネットワークにある場合でも、2つの股関節対応ホストが互いに通信できるようにすることです。
Using the extensions defined in this document, HIP end-hosts use techniques drawn from the Interactive Connectivity Establishment (ICE) methodology [RFC5245] to find operational paths for the HIP control protocol and for ESP encapsulated data traffic. The hosts test connectivity between different locators and try to discover a direct end-to-end path between them. However, with some legacy NATs, utilizing the shortest path between two end-hosts located behind NATs is not possible without relaying the traffic through a relay, such as a Traversal Using Relay NAT (TURN) server [RFC5128]. Because relaying traffic increases the roundtrip delay and consumes resources from the relay, with the extensions described in this document, hosts try to avoid using the TURN server whenever possible.
このドキュメントで定義されている拡張機能を使用して、ヒップエンドホストは、インタラクティブコネクティビティ確立（ICE）方法論[RFC5245]から描かれた手法を使用して、ヒップ制御プロトコルとESPカプセル化されたデータトラフィックの動作パスを見つけます。ホストは異なるロケーター間の接続性をテストし、それらの間の直接的なエンドツーエンドパスを発見しようとします。ただし、いくつかのレガシーNATでは、NAT（ターン）サーバー[RFC5128]を使用したトラバーサルなど、リレーを介してトラフィックをリレーせずに、NATの背後にある2つのエンドホスト間の最短パスを利用することは不可能です。リレーをリレーすると、往復遅延が増加し、リレーからリソースを消費するため、このドキュメントで説明されている拡張機能は、可能な限りターンサーバーの使用を避けようとします。
HIP has defined a rendezvous server [RFC5204] to allow for mobile HIP hosts to establish a stable point-of-contact in the Internet. This document defines extensions to the rendezvous server that solve the same problems, but for both NATed and non-NATed networks. The extended rendezvous server, called a "HIP relay server", forwards HIP control packets between an Initiator and a Responder, allowing hosts to be located behind NATs. This behavior is in contrast to the HIP rendezvous service that forwards only the initial I1 packet of the base exchange; an approach that is less likely to work in a NATed environment [RFC5128]. Therefore, when using relays to traverse NATs, HIP uses a HIP relay server for the control traffic and a TURN server for the data traffic.
HIPは、モバイル股関節ホストがインターネットで安定した接触を確立できるように、Rendezvousサーバー[RFC5204]を定義しました。このドキュメントでは、同じ問題を解決するが、ネートネットワークと非ネットの両方のネットワークの両方で、endezvousサーバーへの拡張機能を定義しています。「ヒップリレーサーバー」と呼ばれる拡張レンデブーサーバーは、イニシエーターとレスポンダーの間でヒップコントロールパケットを転送し、ホストをNATの後ろに配置できるようにします。この動作は、基本交換の初期I1パケットのみを転送する股関節ランデブーサービスとは対照的です。Nated環境で機能する可能性が低いアプローチ[RFC5128]。したがって、リレーをトラバースNATに使用する場合、HIPは制御トラフィックにヒップリレーサーバーとデータトラフィックにターンサーバーを使用します。
The basis for the connectivity checks is ICE [RFC5245]. [RFC5245] describes ICE as follows:
接続チェックの基礎はICE [RFC5245]です。[RFC5245]は氷を次のように説明しています。
A technique for NAT traversal for UDP-based media streams (though ICE can be extended to handle other transport protocols, such as TCP) established by the offer/answer model. ICE is an extension to the offer/answer model, and works by including a multiplicity of IP addresses and ports in SDP offers and answers, which are then tested for connectivity by peer-to-peer connectivity checks. The IP addresses and ports included in the SDP and the connectivity checks are performed using the revised [Simple Traversal of the UDP Protocol through NAT (STUN)] specification [RFC5389], now renamed to Session Traversal Utilities for NAT.
オファー/回答モデルによって確立されたUDPベースのメディアストリーム（ただし、TCPなどの他の輸送プロトコルを処理するためにICEを拡張できますが）の手法。ICEはオファー/回答モデルの拡張であり、SDPのオファーと回答に多数のIPアドレスとポートを含めることで機能します。これは、ピアツーピア接続のチェックによって接続をテストします。SDPに含まれるIPアドレスとポートと接続チェックは、改訂された[NAT（STUN）を介したUDPプロトコルの単純なトラバーサル]仕様[RFC5389]を使用して実行され、NATのセッショントラバーサルユーティリティに改名されました。
The standard ICE [RFC5245] is specified with SIP in mind and it has some features that are not necessary or suitable as such for other protocols. [MMUSIC-ICE] gives instructions and recommendations on how ICE can be used for other protocols and this document follows those guidelines.
標準のICE [RFC5245]は、SIPを念頭に置いて指定されており、他のプロトコルに必要または適切ではないいくつかの機能があります。[MMUSIC-ICE]は、他のプロトコルにICEを使用する方法についての指示と推奨事項を提供し、このドキュメントはそれらのガイドラインに従っています。
Two HIP hosts that implement this specification communicate their locators to each other in the HIP base exchange. The locators are then paired with the locators of the other endpoint and prioritized according to recommended and local policies. These locator pairs are then tested sequentially by both of the end-hosts. The tests may result in multiple operational pairs but ICE procedures determine a single preferred address pair to be used for subsequent communication.
この仕様を実装する2つのヒップホストは、ヒップベース交換でロケーターを相互に伝えます。その後、ロケーターは他のエンドポイントのロケーターとペアになり、推奨されるローカルポリシーに従って優先順位を付けます。これらのロケーターペアは、両方のエンドホストによって連続的にテストされます。テストでは複数の動作ペアが生じる場合がありますが、ICE手順により、後続の通信に使用される単一の優先アドレスペアが決定されます。
In summary, the extensions in this document define:
要約すると、このドキュメントの拡張機能は次のとおりです。
o UDP encapsulation of HIP packets
o 股関節パケットのUDPカプセル化
o UDP encapsulation of IPsec ESP packets
o IPSEC ESPパケットのUDPカプセル化
o registration extensions for HIP relay services
o ヒップリレーサービスの登録拡張機能
o how the ICE "offer" and "answer" are carried in the base exchange
o 氷がどのように「提供」と「回答」が基本交換で運ばれるか
o interaction with ICE connectivity check messages
o 氷の接続性チェックメッセージとの相互作用
o backwards compatibility issues with rendezvous servers
o Rendezvousサーバーの後方互換性の問題
o a number of optimizations (such as when the ICE connectivity tests can be omitted)
o 多くの最適化（氷の接続テストを省略できる場合など）
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This document borrows terminology from [RFC5201], [RFC5206], [RFC4423], [RFC5245], and [RFC5389]. Additionally, the following terms are used:
この文書は、[RFC5201]、[RFC5206]、[RFC4423]、[RFC5245]、および[RFC5389]から用語を借用しています。さらに、次の用語が使用されます。
Rendezvous server: A host that forwards I1 packets to the Responder.
Rendezvousサーバー：I1パケットをレスポンダーに転送するホスト。
HIP relay server: A host that forwards any kind of HIP control packets between the Initiator and the Responder.
ヒップリレーサーバー：イニシエーターとレスポンダーの間にあらゆる種類のヒップ制御パケットを転送するホスト。
TURN server: A server that forwards data traffic between two end-hosts as defined in [RFC5766].
ターンサーバー：[RFC5766]で定義されている2つのエンドホスト間でデータトラフィックを転送するサーバー。
Locator: As defined in [RFC5206]: "A name that controls how the packet is routed through the network and demultiplexed by the end-host. It may include a concatenation of traditional network addresses such as an IPv6 address and end-to-end identifiers such as an ESP SPI. It may also include transport port numbers or IPv6 Flow Labels as demultiplexing context, or it may simply be a network address."
ロケーター：[RFC5206]で定義されています。ESP SPIなどの識別子。また、輸送ポート番号またはIPv6フローラベルが非gultiplexingコンテキストとして含まれる場合もあれば、単にネットワークアドレスである場合もあります。」
LOCATOR (written in capital letters): Denotes a HIP control packet parameter that bundles multiple locators together.
ロケーター（大文字で書かれている）：複数のロケーターを一緒にバンドルするヒップコントロールパケットパラメーターを示します。
ICE offer: The Initiator's LOCATOR parameter in a HIP I2 control packet.
アイスオファー：HIP I2コントロールパケットのイニシエーターのロケーターパラメーター。
ICE answer: The Responder's LOCATOR parameter in a HIP R2 control packet.
ICE回答：HIP R2コントロールパケットのResponderのロケーターパラメーター。
Transport address: Transport layer port and the corresponding IPv4/v6 address.
輸送アドレス：輸送層ポートと対応するIPv4/V6アドレス。
Candidate: A transport address that is a potential point of contact for receiving data.
候補者：データを受信するための潜在的な連絡先である輸送アドレス。
Host candidate: A candidate obtained by binding to a specific port from an IP address on the host.
ホスト候補：ホストのIPアドレスから特定のポートにバインディングすることで取得した候補者。
Server reflexive candidate: A translated transport address of a host as observed by a HIP relay server or a STUN/TURN server.
サーバー反射候補：ヒップリレーサーバーまたはスタン/ターンサーバーによって観察されたホストの翻訳されたトランスポートアドレス。
Peer reflexive candidate: A translated transport address of a host as observed by its peer.
ピア反射候補：ピアによって観察されたホストの翻訳された輸送住所。
Relayed candidate: A transport address that exists on a TURN server. Packets that arrive at this address are relayed towards the TURN client.
中継候補：ターンサーバーに存在するトランスポートアドレス。このアドレスに到達するパケットは、ターンクライアントに向かって中継されます。
+-------+
| HIP |
+--------+ | Relay | +--------+
| TURN | +-------+ | STUN |
| Server | / \ | Server |
+--------+ / \ +--------+
/ \
/ \
/ \
/ <- Signaling -> \
/ \
+-------+ +-------+
| NAT | | NAT |
+-------+ +-------+
/ \
/ \
+-------+ +-------+
| Init- | | Resp- |
| iator | | onder |
+-------+ +-------+
Figure 1: Example Network Configuration
図1：ネットワーク構成の例
In the example configuration depicted in Figure 1, both Initiator and Responder are behind one or more NATs, and both private networks are connected to the public Internet. To be contacted from behind a NAT, the Responder must be registered with a HIP relay server reachable on the public Internet, and we assume, as a starting point, that the Initiator knows both the Responder's Host Identity Tag (HIT) and the address of one of its relay servers (how the Initiator learns of the Responder's relay server is outside of the scope of this document, but may be through DNS or another name service).
図1に示す構成の例では、イニシエーターとレスポンダーの両方が1つ以上のNATの背後にあり、両方のプライベートネットワークがパブリックインターネットに接続されています。NATの後ろから連絡するには、レスポンダーはパブリックインターネットで到達可能なヒップリレーサーバーに登録する必要があります。出発点として、イニシエーターはレスポンダーのホストIDタグ（ヒット）とアドレスの両方を知っていると仮定します。リレーサーバーの1つ（イニシエーターがResponderのリレーサーバーをどのように学習するかは、このドキュメントの範囲外ですが、DNSまたは別名サービスを介している場合があります）。
The first steps are for both the Initiator and Responder to register with a relay server (need not be the same one) and gather a set of address candidates. The hosts may use TURN and STUN servers for gathering the candidates. Next, the HIP base exchange is carried out by encapsulating the HIP control packets in UDP datagrams and sending them through the Responder's relay server. As part of the base exchange, each HIP host learns of the peer's candidate addresses through the ICE offer/answer procedure embedded in the base exchange.
最初の手順は、イニシエーターとレスポンダーの両方がリレーサーバーに登録し（同じものである必要はない）、アドレス候補のセットを収集することです。ホストは、候補者を収集するためにターンサーバーとスタンサーバーを使用できます。次に、HIPベース交換は、UDPデータグラムのHIPコントロールパケットをカプセル化し、Responderのリレーサーバーを介して送信することにより実行されます。基本交換の一環として、各股関節ホストは、ベース交換に埋め込まれたアイスオファー/回答手順を介して、ピアの候補者のアドレスを学びます。
Once the base exchange is completed, HIP has established a working communication session (for signaling) via a relay server, but the hosts still work to find a better path, preferably without a relay, for the ESP data flow. For this, ICE connectivity checks are carried out until a working pair of addresses is discovered. At the end of the procedure, if successful, the hosts will have enabled a UDP-based flow that traverses both NATs, with the data flowing directly from NAT to NAT or via a TURN server. Further HIP signaling can be sent over the same address/port pair and is demultiplexed from data traffic via a marker in the payload. Finally, NAT keepalives will be sent as needed.
基本交換が完了すると、HIPはリレーサーバーを介してワーキング通信セッション（シグナリング）を確立しましたが、ホストはESPデータフローのために、できればリレーなしでより良いパスを見つけるためにまだ動作します。このため、作業中のアドレスが発見されるまで、氷の接続性チェックが実行されます。手順の最後に、成功した場合、ホストは両方のNATを横断するUDPベースのフローを有効にし、データはNATからNATまたはターンサーバーを介して直接流れます。さらなる股関節シグナル伝達は、同じアドレス/ポートペアで送信でき、ペイロードのマーカーを介してデータトラフィックから非難されます。最後に、必要に応じてNat Keepalivesが送信されます。
If either one of the hosts knows that it is not behind a NAT, hosts can negotiate during the base exchange a different mode of NAT traversal that does not use ICE connectivity checks, but only UDP encapsulation of HIP and ESP. Also, it is possible for the Initiator to simultaneously try a base exchange with and without UDP encapsulation. If a base exchange without UDP encapsulation succeeds, no ICE connectivity checks or UDP encapsulation of ESP are needed.
ホストのいずれかがNATの背後にないことを知っている場合、ホストはベース交換中に氷の接続性チェックを使用せず、股関節とespのUDPカプセル化のみを使用しないNATトラバーサルの異なるモードと交渉できます。また、イニシエーターは、UDPカプセル化の有無にかかわらず、同時にベース交換を試すことができます。UDPカプセル化のない基本交換が成功した場合、氷の接続性チェックやESPのUDPカプセル化は必要ありません。
This section describes the normative behavior of the protocol extension. Examples of packet exchanges are provided for illustration purposes.
このセクションでは、プロトコル拡張の規範的な動作について説明します。パケット交換の例は、イラストの目的で提供されています。
HIP rendezvous servers operate in non-NATed environments and their use is described in [RFC5204]. This section specifies a new middlebox extension, called the HIP relay server, for operating in NATed environments. A HIP relay server forwards HIP control packets between the Initiator and the Responder.
股関節ランデブーサーバーは非ネート環境で動作し、その使用は[RFC5204]で説明されています。このセクションでは、NATED環境で動作するために、HIPリレーサーバーと呼ばれる新しいMiddlebox拡張機能を指定します。ヒップリレーサーバーは、イニシエーターとレスポンダーの間でヒップ制御パケットを転送します。
End-hosts cannot use the HIP relay service for forwarding the ESP data plane. Instead, they use TURN servers [RFC5766].
エンドホストは、ESPデータプレーンを転送するためにヒップリレーサービスを使用できません。代わりに、ターンサーバー[RFC5766]を使用します。
A HIP relay server MUST silently drop packets to a HIP relay client that has not previously registered with the HIP relay. The registration process follows the generic registration extensions defined in [RFC5203] and is illustrated in Figure 2.
ヒップリレーサーバーは、以前にヒップリレーに登録されていなかったヒップリレークライアントにパケットを静かにドロップする必要があります。登録プロセスは、[RFC5203]で定義されている汎用登録拡張機能に従い、図2に示されています。
HIP HIP
Relay Relay
Client Server
| 1. UDP(I1) |
+------------------------------------------------------->|
| |
| 2. UDP(R1(REG_INFO(RELAY_UDP_HIP))) |
|<-------------------------------------------------------+
| |
| 3. UDP(I2(REG_REQ(RELAY_UDP_HIP))) |
+------------------------------------------------------->|
| |
| 4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM)) |
|<-------------------------------------------------------+
| |
Figure 2: Example Registration with a HIP Relay
図2：ヒップリレーの登録の例
In step 1, the relay client (Initiator) starts the registration procedure by sending an I1 packet over UDP. It is RECOMMENDED that the Initiator select a random port number from the ephemeral port range 49152-65535 for initiating a base exchange. Alternatively, a host MAY also use a single fixed port for initiating all outgoing connections. However, the allocated port MUST be maintained until all of the corresponding HIP Associations are closed. It is RECOMMENDED that the HIP relay server listen to incoming connections at UDP port 10500. If some other port number is used, it needs to be known by potential Initiators.
ステップ1では、リレークライアント（イニシエーター）は、UDPを介してi1パケットを送信することにより、登録手順を開始します。イニシエーターは、ベース交換を開始するために、はかないポート範囲49152-65535からランダムなポート番号を選択することをお勧めします。または、ホストは、すべての発信接続を開始するために単一の固定ポートを使用することもできます。ただし、対応するすべての股関節関連が閉じられるまで、割り当てられたポートを維持する必要があります。HIPリレーサーバーは、UDPポート10500で着信接続を聴くことをお勧めします。他のポート番号が使用される場合は、潜在的な開始剤によって知られる必要があります。
In step 2, the HIP relay server (Responder) lists the services that it supports in the R1 packet. The support for HIP-over-UDP relaying is denoted by the Registration Type value RELAY_UDP_HIP (see Section 5.9).
ステップ2では、HIPリレーサーバー（Responder）には、R1パケットでサポートするサービスがリストされています。ヒップオーバー-UDPリレーのサポートは、登録タイプの値relay_udp_hipで示されます（セクション5.9を参照）。
In step 3, the Initiator selects the services for which it registers and lists them in the REG_REQ parameter. The Initiator registers for HIP relay service by listing the RELAY_UDP_HIP value in the request parameter.
ステップ3では、イニシエーターは、REG_REQパラメーターに登録するサービスを選択し、リストします。Initiatatorは、リクエストパラメーターにrelay_udp_hip値をリストすることにより、ヒップリレーサービスのレジスタを登録します。
In step 4, the Responder concludes the registration procedure with an R2 packet and acknowledges the registered services in the REG_RES parameter. The Responder denotes unsuccessful registrations (if any) in the REG_FAILED parameter of R2. The Responder also includes a REG_FROM parameter that contains the transport address of the client as observed by the relay (Server Reflexive candidate). After the registration, the client sends NAT keepalives, as described in Section 4.7, periodically to the relay to keep possible NAT bindings between the client and the relay alive. The relay client maintains the HIP association with the relay server as long as it requires relaying service from it.
ステップ4では、ResponderはR2パケットで登録手順を締め切り、REG_RESパラメーターの登録サービスを確認します。レスポンダーは、R2のREG_FAILEDパラメーターの登録の失敗（ある場合）を示します。Responderには、リレー（サーバー反射候補）で観察されるように、クライアントの輸送アドレスを含むREG_FROMパラメーターも含まれています。登録後、クライアントは、セクション4.7で説明されているように、クライアントとリレーの間の可能なNATバインディングを生き生きとするために、定期的にリレーにNAT Keepaliveを送信します。リレークライアントは、リレーサーバーとのリレーサービスを必要とする限り、リレーサーバーとの股関節関連を維持しています。
If a host is going to use ICE, it needs to gather a set of address candidates. The candidate gathering SHOULD be done as defined in Section 4.1 of [RFC5245]. Candidates need to be gathered for the UDP-encapsulated flow of HIP and ESP traffic. This flow corresponds to one ICE media stream and component. Since ICE component IDs are not needed, they are not explicitly signaled and ID value of 1 SHOULD be used for ICE processing, where needed. The Initiator takes the role of the ICE controlling agent.
ホストがICEを使用する場合、アドレス候補のセットを収集する必要があります。候補者の収集は、[RFC5245]のセクション4.1で定義されているように行う必要があります。候補者は、股関節とESPトラフィックのUDPがカプセル化された流れのために収集する必要があります。このフローは、1つのアイスメディアストリームとコンポーネントに対応します。ICEコンポーネントIDは必要ないため、それらは明示的に信号されておらず、必要に応じて氷加工に1のID値を使用する必要があります。イニシエーターは、氷制御剤の役割を担います。
The candidate gathering can be done at any time, but it needs to be done before sending an I2 or R2 in the base exchange if ICE is to be used for the connectivity checks. It is RECOMMENDED that all three types of candidates (host, server reflexive, and relayed) are gathered to maximize the probability of successful NAT traversal. However, if no TURN server is used, and the host has only a single local IP address to use, the host MAY use the local address as the only host candidate and the address from the REG_FROM parameter discovered during the relay registration as a server reflexive candidate. In this case, no further candidate gathering is needed.
候補者の収集はいつでも行うことができますが、接続性チェックに氷を使用する場合は、ベース交換にI2またはR2を送信する前に行う必要があります。NATトラバーサルの成功の確率を最大化するために、3種類の候補すべて（ホスト、サーバー反射、および中継）を収集することをお勧めします。ただし、ターンサーバーが使用されず、ホストに使用するローカルIPアドレスが1つしかない場合、ホストはローカルアドレスを唯一のホスト候補として使用し、リレー登録中に発見されたreg_fromパラメーターのアドレスをサーバーの反射として使用することができます。候補者。この場合、それ以上の候補者の集まりは必要ありません。
This section describes the usage of a new non-critical parameter type. The presence of the parameter in a HIP base exchange means that the end-host supports NAT traversal extensions described in this document. As the parameter is non-critical (as defined in Section 5.2.1 of [RFC5201]), it can be ignored by an end-host, which means that the host does not support or is not willing to use these extensions.
このセクションでは、新しい非クリティカルパラメータータイプの使用について説明します。股関節ベース交換にパラメーターが存在することは、エンドホストがこのドキュメントで説明されているNATトラバーサルエクステンションをサポートすることを意味します。パラメーターは非批判的であるため（[RFC5201]のセクション5.2.1で定義されているように）、エンドホストでは無視できます。つまり、ホストはこれらの拡張機能をサポートしていないか、使用しないことを意味します。
With registration with a HIP relay, it is usually sufficient to use the UDP-ENCAPSULATION mode of NAT traversal since the relay is assumed to be in public address space. Thus, the relay SHOULD propose the UDP-ENCAPSULATION mode as the preferred or only mode.
股関節リレーに登録すると、リレーは公共の住所スペースにあると想定されるため、NATトラバーサルのUDPエンコール化モードを使用するだけで十分です。したがって、リレーは、UDPエンコール化モードを優先モードまたは唯一のモードとして提案する必要があります。
The NAT traversal mode negotiation in a HIP base exchange is illustrated in Figure 3.
股関節ベース交換におけるNATトラバーサルモードの交渉を図3に示します。
Initiator Responder
| 1. UDP(I1) |
+--------------------------------------------------------------->|
| |
| 2. UDP(R1(.., NAT_TRAVERSAL_MODE(list of modes), ..)) |
|<---------------------------------------------------------------+
| |
| 3. UDP(I2(.., NAT_TRAVERSAL_MODE(selected mode), LOCATOR, ..)) |
+--------------------------------------------------------------->|
| |
| 4. UDP(R2(.., LOCATOR, ..)) |
|<---------------------------------------------------------------+
| |
Figure 3: Negotiation of NAT Traversal Mode
図3：NATトラバーサルモードの交渉
In step 1, the Initiator sends an I1 to the Responder. In step 2, the Responder responds with an R1. The NAT_TRAVERSAL_MODE parameter in R1 contains a list of NAT traversal modes the Responder supports. The modes specified in this document are shown in Table 1 and their values are specified in Section 5.4.
ステップ1では、イニシエーターはI1をレスポンダーに送信します。ステップ2では、レスポンダーはR1で応答します。R1のNAT_TRAVERSAL_MODEパラメーターには、応答者がサポートするNATトラバーサルモードのリストが含まれています。このドキュメントで指定されたモードを表1に示し、その値はセクション5.4に指定されています。
+-------------------+-----------------------------------------------+
| Type | Purpose |
+-------------------+-----------------------------------------------+
| RESERVED | Reserved for future use |
| | |
| UDP-ENCAPSULATION | Use only UDP encapsulation of the HIP |
| | signaling traffic and ESP (no ICE |
| | connectivity checks) |
| | |
| ICE-STUN-UDP | UDP-encapsulated control and data traffic |
| | with ICE-based connectivity checks using STUN |
| | messages |
+-------------------+-----------------------------------------------+
Table 1: NAT Traversal Modes
表1：NATトラバーサルモード
In step 3, the Initiator sends an I2 that includes a NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the Initiator from the list of modes offered by the Responder. If ICE mode was selected, the I2 also includes the "Transport address" locators (as defined in Section 5.7) of the Initiator in a LOCATOR parameter. The locators in I2 are the "ICE offer".
ステップ3では、イニシエーターはNAT_TRAVERSAL_MODEパラメーターを含むI2を送信します。Responderが提供するモードのリストからイニシエーターによって選択されたモードが含まれています。ICEモードが選択された場合、I2には、ロケーターパラメーターの開始者の「輸送アドレス」ロケーター（セクション5.7で定義されている）も含まれています。i2のロケーターは「アイスオファー」です。
In step 4, the Responder concludes the base exchange with an R2 packet. If the Initiator chose ICE NAT traversal mode, the Responder includes a LOCATOR parameter in the R2 packet. The locators in R2, encoded like the locators in I2, are the "ICE answer". If the NAT traversal mode selected by the Initiator is not supported by the Responder, the Responder SHOULD reply with a NOTIFY packet with type NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange.
ステップ4では、ResponderはR2パケットを使用したベース交換を締めくくります。イニシエーターがICE NATトラバーサルモードを選択した場合、レスポンダーにはR2パケットにロケーターパラメーターが含まれています。I2のロケーターのようにエンコードされたR2のロケーターは、「ICE答え」です。イニシエーターによって選択されたNATトラバーサルモードがレスポンダーによってサポートされていない場合、レスポンダーはタイプNO_VALID_NAT_TRAVERSAL_TRAVERSAL_MODE_PARAMETERを使用してNotifyパケットで返信し、基本交換を中止する必要があります。
As explained in [RFC5245], when a NAT traversal mode with connectivity checks is used, new transactions should not be started too fast to avoid congestion and overwhelming the NATs.
[RFC5245]で説明されているように、接続チェックを伴うNATトラバーサルモードが使用される場合、混雑を避けてNATを圧倒するために、新しいトランザクションを速く開始しないでください。
For this purpose, during the base exchange, hosts can negotiate a transaction pacing value, Ta, using a TRANSACTION_PACING parameter in R1 and I2 packets. The parameter contains the minimum time (expressed in milliseconds) the host would wait between two NAT traversal transactions, such as starting a new connectivity check or retrying a previous check. If a host does not include this parameter in the base exchange, a Ta value of 500 ms MUST be used as that host's minimum value. The value that is used by both of the hosts is the higher out of the two offered values.
この目的のために、基本交換中に、ホストはR1およびI2パケットでTransaction_Pacingパラメーターを使用して、トランザクションペーシング値、TAを交渉できます。パラメーターには、新しい接続チェックの開始や以前のチェックの再試行など、2つのNATトラバーサルトランザクションの間でホストが待機する最小時間（ミリ秒で表されます）が含まれます。ホストがベースエクスチェンジにこのパラメーターを含めない場合、500ミリ秒のTA値をそのホストの最小値として使用する必要があります。両方のホストが使用する値は、2つの提供された値のうち高いものです。
Hosts SHOULD NOT use values smaller than 20 ms for the minimum Ta, since such values may not work well with some NATs, as explained in [RFC5245]. The Initiator MUST NOT propose a smaller value than what the Responder offered.
[RFC5245]で説明されているように、そのような値は一部のNATではうまく機能しない可能性があるため、ホストは最小TAに対して20 ms以下の値を使用してはなりません。イニシエーターは、レスポンダーが提供したものよりも小さな値を提案してはなりません。
The minimum Ta value SHOULD be configurable, and if no value is configured, a value of 500 ms MUST be used. Guidelines for selecting a Ta value are given in Appendix A. Currently this feature applies only to the ICE-STUN-UDP NAT traversal mode, but any other mode using connectivity checks SHOULD utilize this feature.
最小TA値は構成可能であり、値が構成されていない場合は、500ミリ秒の値を使用する必要があります。TA値を選択するためのガイドラインは、付録Aに記載されています。現在、この機能はICE-STUN-UDP NATトラバーサルモードにのみ適用されますが、接続性チェックを使用する他のモードはこの機能を利用する必要があります。
This section describes how the Initiator and Responder perform a base exchange through a HIP relay server. The NAT traversal mode negotiation (denoted as NAT_TM in the example) was described in Section 4.3 and is not repeated here. If a relay receives an R1 or I2 packet without the NAT traversal mode parameter, it MUST drop it and SHOULD send a NOTIFY error packet with type NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1/I2.
このセクションでは、イニシエーターとレスポンダーがヒップリレーサーバーを介してベース交換を実行する方法について説明します。NATトラバーサルモードのネゴシエーション（例ではNAT_TMとして示される）は、セクション4.3で説明されており、ここでは繰り返されません。リレーがNATトラバーサルモードパラメーターなしでR1またはI2パケットを受信した場合、それをドロップする必要があり、タイプNO_VALID_NAT_TRAVERSAL_MODE_PARAMETERを使用してNO_VALID_NAT_TRAVERSAL_MODE_PARAMETERをR1/I2の送信者に送信する必要があります。
It is RECOMMENDED that the Initiator send an I1 packet encapsulated in UDP when it is destined to an IPv4 address of the Responder. Respectively, the Responder MUST respond to such an I1 packet with a UDP-encapsulated R1 packet and the rest of the base exchange, I2 and R2, MUST also use UDP encapsulation.
イニシエーターは、ResponderのIPv4アドレスに運命づけられている場合、UDPでカプセル化されたi1パケットを送信することをお勧めします。それぞれ、ResponderはUDPにカプセル化されたR1パケットを使用してそのようなI1パケットに応答する必要があり、Base Exchangeの残りのI2およびR2もUDPカプセル化を使用する必要があります。
Initiator HIP relay Responder
| 1. UDP(I1) | |
+----------------------------->| 2. UDP(I1(RELAY_FROM)) |
| +------------------------------->|
| | |
| | 3. UDP(R1(RELAY_TO, NAT_TM)) |
| 4. UDP(R1(RELAY_TO, NAT_TM)) |<-------------------------------+
|<-----------------------------+ |
| | |
| 5. UDP(I2(LOCATOR, NAT_TM)) | |
+----------------------------->| 6. UDP(I2(LOCATOR, RELAY_FROM, |
| | NAT_TM)) |
| +------------------------------->|
| | |
| | 7. UDP(R2(LOCATOR, RELAY_TO)) |
| 8. UDP(R2(LOCATOR, RELAY_TO))|<-------------------------------+
|<-----------------------------+ |
| | |
Figure 4: Base Exchange via a HIP Relay Server
図4：ヒップリレーサーバーを介したベース交換
In step 1 of Figure 4, the Initiator sends an I1 packet over the transport layer to the HIT of the Responder and IP address and port of the HIP relay server. The source address is one of the locators of the Initiator.
図4のステップ1では、イニシエーターは、輸送層を介してi1パケットを、ヒップリレーサーバーのレスポンダーとIPアドレス、ポートのヒットに送信します。ソースアドレスは、イニシエーターのロケーターの1つです。
In step 2, the HIP relay server receives the I1 packet. If the destination HIT belongs to a registered Responder, the relay processes the packet. Otherwise, the relay MUST drop the packet silently. The relay appends a RELAY_FROM parameter to the I1 packet, which contains the transport source address and port of the I1 as observed by the relay. The relay protects the I1 packet with RELAY_HMAC as described in [RFC5204], except that the parameter type is different (see Section 5.8). The relay changes the source and destination ports and IP addresses of the packet to match the values the Responder used when registering to the relay, i.e., the reverse of the R2 used in the registration. The relay MUST recalculate the transport checksum and forward the packet to the Responder.
ステップ2では、ヒップリレーサーバーがi1パケットを受信します。宛先ヒットが登録されたレスポンダーに属している場合、リレーはパケットを処理します。それ以外の場合、リレーはパケットを静かにドロップする必要があります。リレーは、リレーで観察されたように、i1のトランスポートソースアドレスとポートを含むi1パケットにrelay_fromパラメーターを追加します。リレーは、[RFC5204]で説明されているように、i1パケットをrelay_hmacで保護しますが、パラメータータイプが異なることを除きます（セクション5.8を参照）。リレーは、パケットのソースポートと宛先ポートとIPアドレスを変更して、リレーに登録するときにレスポンダーが使用した値、つまり登録で使用されるR2の逆と一致します。リレーは輸送チェックサムを再計算し、パケットをレスポンダーに転送する必要があります。
In step 3, the Responder receives the I1 packet. The Responder processes it according to the rules in [RFC5201]. In addition, the Responder validates the RELAY_HMAC according to [RFC5204] and silently drops the packet if the validation fails. The Responder replies with an R1 packet to which it includes RELAY_TO and NAT traversal mode parameters. The RELAY_TO parameter MUST contain the same information as the RELAY_FROM parameter, i.e., the Initiator's transport address, but the type of the parameter is different. The RELAY_TO parameter is not integrity protected by the signature of the R1 to allow pre-created R1 packets at the Responder.
ステップ3では、レスポンダーはi1パケットを受け取ります。応答者は、[RFC5201]のルールに従って処理します。さらに、レスポンダーは[RFC5204]に従ってrelay_hmacを検証し、検証が失敗した場合に静かにパケットをドロップします。レスポンダーは、RELAY_TOおよびNATトラバーサルモードパラメーターを含むR1パケットで応答します。relay_toパラメーターには、leray_fromパラメーター、つまりイニシエーターのトランスポートアドレスと同じ情報を含める必要がありますが、パラメーターのタイプは異なります。relay_toパラメーターは、R1の署名によって保護されている整合性ではなく、レスポンダーで事前に作成されたR1パケットを許可します。
In step 4, the relay receives the R1 packet. The relay drops the packet silently if the source HIT belongs to an unregistered host. The relay MAY verify the signature of the R1 packet and drop it if the signature is invalid. Otherwise, the relay rewrites the source address and port, and changes the destination address and port to match RELAY_TO information. Finally, the relay recalculates transport checksum and forwards the packet.
ステップ4では、リレーはR1パケットを受信します。ソースヒットが未登録のホストに属している場合、リレーはパケットを静かにドロップします。リレーは、R1パケットの署名を検証し、署名が無効な場合にドロップする場合があります。それ以外の場合、リレーはソースアドレスとポートを書き換え、宛先アドレスとポートを変更して、relay_to情報を一致させます。最後に、リレーは輸送チェックサムを再計算し、パケットを転送します。
In step 5, the Initiator receives the R1 packet and processes it according to [RFC5201]. The Initiator MAY use the address in the RELAY_TO parameter as a local peer-reflexive candidate for this HIP association if it is different from all known local candidates. The Initiator replies with an I2 packet that uses the destination transport address of R1 as the source address and port. The I2 packet contains a LOCATOR parameter that lists all the ICE candidates (ICE offer) of the Initiator. The candidates are encoded using the format defined in Section 5.7. The I2 packet MUST also contain a NAT traversal mode parameter with the mode the Initiator selected.
ステップ5では、イニシエーターはR1パケットを受信し、[RFC5201]に従って処理します。イニシエーターは、すべての既知のローカル候補とは異なる場合、この股関節関連のローカルピア反射候補として、relay_toパラメーターのアドレスを使用することができます。イニシエーターは、R1の宛先輸送アドレスをソースアドレスとポートとして使用するI2パケットで応答します。I2パケットには、イニシエーターのすべてのICE候補（ICEオファー）をリストするロケーターパラメーターが含まれています。候補者は、セクション5.7で定義された形式を使用してエンコードされます。I2パケットには、イニシエーターが選択したモードを備えたNATトラバーサルモードパラメーターも含める必要があります。
In step 6, the relay receives the I2 packet. The relay appends a RELAY_FROM and a RELAY_HMAC to the I2 packet as explained in step 2.
ステップ6では、リレーはi2パケットを受信します。リレーは、ステップ2で説明されているように、i2パケットにrelay_fromとrelay_hmacを追加します。
In step 7, the Responder receives the I2 packet and processes it according to [RFC5201]. It replies with an R2 packet and includes a RELAY_TO parameter as explained in step 3. The R2 packet includes a LOCATOR parameter that lists all the ICE candidates (ICE answer) of the Responder. The RELAY_TO parameter is protected by the HMAC.
In step 8, the relay processes the R2 as described in step 4. The relay forwards the packet to the Initiator. After the Initiator has received the R2 and processed it successfully, the base exchange is completed.
ステップ8では、リレーはステップ4で説明されているようにR2を処理します。リレーはパケットをイニシエーターに転送します。イニシエーターがR2を受信し、それを正常に処理した後、基本交換が完了します。
Hosts MUST include the address of one or more HIP relay servers (including the one that is being used for the initial signaling) in the LOCATOR parameter in I2/R2 if they intend to use such servers for relaying HIP signaling immediately after the base exchange completes.
ホストには、ベース交換が完了した直後に股関節信号を中継するためにそのようなサーバーを使用する場合は、I2/R2のロケーターパラメーターに1つ以上のヒップリレーサーバー（初期シグナルに使用されているものを含む）のアドレスを含める必要があります。。
The traffic type of these addresses MUST be "HIP signaling" and they MUST NOT be used as ICE candidates. If the HIP relay server locator used for the base exchange is not included in I2/R2 LOCATOR parameters, it SHOULD NOT be used after the base exchange, but further HIP signaling SHOULD use the same path as the data traffic.
これらのアドレスのトラフィックタイプは「股関節シグナリング」でなければならず、氷の候補として使用してはなりません。ベース交換に使用されるヒップリレーサーバーロケーターがI2/R2ロケーターパラメーターに含まれていない場合、ベース交換後は使用しないでください。
If a HIP relay server was used, the Responder completes the base exchange with the R2 packet through the relay. However, the destination address the Initiator and Responder used for the base exchange packets belongs to the HIP relay server. Therefore, that address MUST NOT be used as a destination for ESP traffic. Instead, if a NAT traversal mode with ICE connectivity checks was selected, the Initiator and Responder MUST start the connectivity checks.
ヒップリレーサーバーを使用した場合、レスポンダーはリレーを介してR2パケットとのベース交換を完了します。ただし、宛先アドレスは、ベース交換パケットに使用されるイニシエーターとレスポンダーがヒップリレーサーバーに属します。したがって、そのアドレスは、ESPトラフィックの宛先として使用してはなりません。代わりに、氷の接続チェックを備えたNATトラバーサルモードが選択された場合、イニシエーターとレスポンダーは接続チェックを開始する必要があります。
Creating the checklist for the ICE connectivity checks should be performed as described in Section 5.7 of [RFC5245] bearing in mind that only one media stream and component is needed (so there will be only a single checklist and all candidates should have the same component ID value). The actual connectivity checks MUST be performed as described in Section 7 of [RFC5245]. Regular mode SHOULD be used for the candidate nomination. Section 5.2 defines the details of the STUN control packets. As a result of the ICE connectivity checks, ICE nominates a single transport address pair to be used if an operational address pair was found. The end-hosts MUST use this address pair for the ESP traffic.
アイス接続のチェックリストの作成[RFC5245]のセクション5.7で説明されているように、1つのメディアストリームとコンポーネントのみが必要であることを念頭に置いて実行する必要があります（したがって、単一のチェックリストのみがあり、すべての候補者は同じコンポーネントIDを持つ必要があります。価値）。[RFC5245]のセクション7で説明されているように、実際の接続チェックは実行する必要があります。候補者の指名には通常のモードを使用する必要があります。セクション5.2は、スタン制御パケットの詳細を定義しています。氷の接続性チェックの結果として、ICEは、運用アドレスペアが見つかった場合に使用する単一の輸送アドレスペアを指名します。エンドホストは、ESPトラフィックにこのアドレスペアを使用する必要があります。
The connectivity check messages MUST be paced by the value negotiated during the base exchange as described in Section 4.4. If neither one of the hosts announced a minimum pacing value, a value of 500 ms MUST be used.
セクション4.4で説明されているように、ベース交換中に交渉された値によって接続チェックメッセージはペースを合わせる必要があります。ホストのいずれも最低ペーシング値を発表しなかった場合、500ミリ秒の値を使用する必要があります。
For retransmissions, the retransmission timeout (RTO) value SHOULD be calculated as follows:
再送信の場合、再送信タイムアウト（RTO）値は次のように計算する必要があります。
RTO = MAX (500ms, Ta * (Num-Waiting + Num-In-Progress))
In the RTO formula, Ta is the value used for the connectivity check pacing, Num-Waiting is the number of pairs in the checklist in the "Waiting" state, and Num-In-Progress is the number of pairs in the "In-Progress" state. This is identical to the formula in [RFC5245] if there is only one checklist.
RTOフォーミュラでは、TAは接続チェックペーシングに使用される値であり、Num-Waitingは「待機」状態のチェックリストのペア数であり、Progressの数は「In-In-in-in-progress」の数です。進捗状態。これは、チェックリストが1つしかない場合、[RFC5245]の式と同じです。
If the ICE connectivity checks failed, the hosts MUST NOT send ESP traffic to each other but MAY continue communicating using HIP packets and the locators used for the base exchange. Also, the hosts SHOULD notify each other about the failure with a CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10).
氷の接続のチェックが失敗した場合、ホストはESPトラフィックを相互に送信してはなりませんが、股関節パケットとベース交換に使用されるロケーターを使用して通信し続けることができます。また、ホストは、connectivity_checks_failed通知パケットを使用して障害について互いに通知する必要があります（セクション5.10を参照）。
To prevent NAT states from expiring, communicating hosts send periodic keepalives to each other. HIP relay servers MAY refrain from sending keepalives if it's known that they are not behind a middlebox that requires keepalives. An end-host MUST send keepalives every 15 seconds to refresh the UDP port mapping at the NAT(s) when the control or data channel is idle. To implement failure tolerance, an end-host SHOULD have a shorter keepalive period.
NAT州が期限切れにならないようにするために、ホストを通信することは、互いに定期的なkeepAlivesを送信します。ヒップリレーサーバーは、Keepalivesを必要とするミドルボックスの後ろにいないことがわかっている場合、Keepalivesの送信を控えることができます。エンドホストでは、コントロールまたはデータチャネルがアイドル状態にある場合、NATでUDPポートマッピングを更新するために、15秒ごとにKeepAlivesを送信する必要があります。障害の許容範囲を実装するには、エンドホストにはより短いキープライブ期間が必要です。
The keepalives are STUN Binding Indications if the hosts have agreed on ICE-STUN-UDP NAT traversal mode during the base exchange. Otherwise, HIP NOTIFY packets MAY be used as keepalives.
キープライブは、ベース交換中にホストがICE-STUN-UUDP NATトラバーサルモードに同意した場合、スタンバインディングの適応症です。それ以外の場合、ヒップ通知パケットはKeepaliveとして使用できます。
The communicating hosts MUST send keepalives to each other using the transport locators they agreed to use for data and signaling when they are in the ESTABLISHED state. Also, the Initiator MUST send a NOTIFY packet to the relay to keep the NAT states alive on the path between the Initiator and relay when the Initiator has not received any response to its I1 or I2 from the Responder in 15 seconds.
通信ホストは、確立された状態にあるときにデータとシグナリングに使用することに同意した輸送ロケーターを使用して、お互いにキープライブを送信する必要があります。また、イニシエーターは、イニシエーターとリレーの間のパス上でNAT状態を生かし続けて、イニシエーターが15秒でResponderからI1またはI2への応答を受け取っていない場合、NAT状態をイニシエーターとリレーの間のパス上で存在させるためにリレーに通知パケットを送信する必要があります。
In certain network environments, the ICE connectivity checks can be omitted to reduce initial connection set-up latency because a base exchange acts as an implicit connectivity test itself. For this to work, the Initiator MUST be able to reach the Responder by simply UDP encapsulating HIP and ESP packets sent to the Responder's address. Detecting and configuring this particular scenario is prone to failure unless carefully planned.
特定のネットワーク環境では、基本交換が暗黙的な接続テスト自体として機能するため、初期接続のセットアップレイテンシを減らすために氷の接続チェックを省略できます。これが機能するためには、イニシエーターは、UDPをカプセル化する股関節とESPパケットをレスポンダーのアドレスに送信するだけで、レスポンダーに到達できる必要があります。この特定のシナリオの検出と構成は、慎重に計画されていない限り、失敗する傾向があります。
In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT traversal mode as one of the supported modes in the R1 packet. If the Responder has registered to a HIP relay server, it MUST also include a LOCATOR parameter in R1 that contains a preferred address where the Responder is able to receive UDP-encapsulated ESP and HIP packets. This locator MUST be of type "Transport address", its Traffic type MUST be "both", and it MUST have the "Preferred bit" set (see Table 2). If there is no such locator in R1, the source address of R1 is used as the Responder's preferred address.
このようなシナリオでは、Responderには、R1パケットのサポートされているモードの1つとしてUDPエンコール化NATトラバーサルモードを含めることができます。ResponderがHIPリレーサーバーに登録している場合、ResponderがUDPにカプセル化されたESPおよび股関節パケットを受信できる優先アドレスを含むR1にロケーターパラメーターを含める必要があります。このロケーターはタイプ「輸送アドレス」でなければならず、そのトラフィックタイプは「両方」でなければならず、「優先ビット」セットが必要です（表2を参照）。R1にそのようなロケーターがない場合、R1のソースアドレスはレスポンダーの優先アドレスとして使用されます。
The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder listed it in the supported modes and the Initiator does not wish to use ICE for searching for a more optimal path. In this case, the Initiator sends the I2 with UDP-ENCAPSULATION mode in the NAT traversal mode parameter directly to the Responder's preferred address (i.e., to the preferred locator in R1 or to the address where R1 was received from if there was no preferred locator in R1). The Initiator MAY include locators in I2 but they MUST NOT be taken as ICE candidates, since ICE will not be used for connections with UDP-ENCAPSULATION NAT traversal mode. Instead, if R2 and I2 are received and processed successfully, a security association can be created and UDP-encapsulated ESP can be exchanged between the hosts after the base exchange completes. However, the Responder SHOULD NOT send any ESP to the Initiator's address before it has received data from the Initiator, as specified in Sections 4.4.2. and 6.9 of [RFC5201] and in Sections 3.2.9 and 5.4 of [RFC5206].
Responderがサポートされているモードにリストした場合、イニシエーターはUDPエンコーシングモードを選択でき、イニシエーターはより最適なパスを検索するためにICEを使用したくありません。この場合、イニシエーターは、NATトラバーサルモードパラメーターのI2をUDPエンコール化モードで、Responderの優先アドレスに直接送信します（つまり、R1の優先ロケーターまたは優先ロケーターがなかった場合のR1が受信されたアドレスに送信されます。R1）。イニシエーターにはI2のロケーターが含まれる場合がありますが、氷はUDPエンコーシングNATトラバーサルモードとの接続に使用されないため、ICE候補とみなされてはなりません。代わりに、R2とI2が正常に受信され、処理された場合、ベース交換が完了した後、セキュリティ協会を作成し、ホスト間でUDPにカプセル化されたESPを交換できます。ただし、セクション4.4.2で指定されているように、イニシエーターからデータを受信する前に、ResponderはイニシエーターのアドレスにESPを送信してはなりません。[RFC5201]の6.9および[RFC5206]のセクション3.2.9および5.4。
Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected MUST NOT be sent via a relay, the Responder SHOULD reject such I2 packets and reply with a NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY packet (see Section 5.10).
選択されたUDPエンコール化NATトラバーサルモードを使用したI2パケットをリレーで送信してはならないため、Responderはそのようなi2パケットを拒否し、NO_VALID_NAT_TRAVERSSAL_MODE_PARAMETER PACTET（セクション5.10を参照）で返信する必要があります。
If there is no answer for the I2 packet sent directly to the Responder's preferred address, the Initiator MAY send another I2 via the HIP relay server, but it MUST NOT choose UDP-ENCAPSULATION NAT traversal mode for that I2.
Responderの優先アドレスに直接送信されたi2パケットに対する回答がない場合、イニシエーターはヒップリレーサーバーを介して別のI2を送信する場合がありますが、そのi2のUDPエンコーシングNATトラバーサルモードを選択してはなりません。
The Initiator MAY also try to simultaneously perform a base exchange with the Responder without UDP encapsulation. In such a case, the Initiator sends two I1 packets, one without and one with UDP encapsulation, to the Responder. The Initiator MAY wait for a while before sending the other I1. How long to wait and in which order to send the I1 packets can be decided based on local policy. For retransmissions, the procedure is repeated.
イニシエーターは、UDPカプセル化なしに、同時にレスポンダーとベース交換を実行しようとする場合があります。そのような場合、イニシエーターは2つのi1パケットを送信します。1つはUDPカプセル化のないもの、もう1つはレスポンダーに送信されます。イニシエーターは、他のi1を送信する前にしばらく待つことがあります。どのくらい待つのか、どの順序でi1パケットを送信するかは、ローカルポリシーに基づいて決定できます。再送信の場合、手順が繰り返されます。
The I1 packet without UDP encapsulation may arrive directly, without any relays, at the Responder. When this happens, the procedures in [RFC5201] are followed for the rest of the base exchange. The Initiator may receive multiple R1 packets, with and without UDP encapsulation, from the Responder. However, after receiving a valid R1 and answering it with an I2, further R1 packets that are not retransmits of the original R1 MUST be ignored.
UDPカプセル化なしのI1パケットは、リレーなしで応答者に直接到着する場合があります。これが発生すると、[RFC5201]の手順が残りの基本交換のために追跡されます。イニシエーターは、ResponderからUDPカプセル化の有無にかかわらず、複数のR1パケットを受け取る場合があります。ただし、有効なR1を受信してI2で回答した後、元のR1の再送信ではないR1パケットをさらに無視する必要があります。
The I1 packet without UDP encapsulation may also arrive at a HIP-capable middlebox. When the middlebox is a HIP rendezvous server and the Responder has successfully registered with the rendezvous service, the middlebox follows rendezvous procedures in [RFC5204].
UDPカプセル化のないI1パケットは、股関節に対応するミドルボックスにも到達する場合があります。ミドルボックスが股関節ランデブーサーバーであり、レスポンダーがRendezvousサービスに正常に登録されている場合、Middleboxは[RFC5204]のRendezvous手順に従います。
If the Initiator receives a NAT traversal mode parameter in R1 without UDP encapsulation, the Initiator MAY ignore this parameter and send an I2 without UDP encapsulation and without any selected NAT traversal mode. When the Responder receives the I2 without UDP encapsulation and without NAT traversal mode, it will assume that no NAT traversal mechanism is needed. The packet processing will be done as described in [RFC5201]. The Initiator MAY store the NAT traversal modes for future use, e.g., in case of a mobility or multihoming event that causes NAT traversal to be used during the lifetime of the HIP association.
イニシエーターがUDPカプセル化なしでR1でNATトラバーサルモードパラメーターを受信した場合、イニシエーターはこのパラメーターを無視し、UDPカプセル化なしで選択したNATトラバーサルモードなしでi2を送信する場合があります。ResponderがUDPカプセル化なしでNATトラバーサルモードなしでI2を受信すると、NATトラバーサルメカニズムが必要ないと仮定します。パケット処理は、[RFC5201]で説明されているように行われます。イニシエーターは、将来の使用のためにNATトラバーサルモードを保存することができます。たとえば、股関節協会の存続期間中にNATトラバーサルを使用するモビリティまたはマルチホームイベントの場合。
After the base exchange, the end-hosts MAY send HIP control packets directly to each other using the transport address pair established for a data channel without sending the control packets through the HIP relay server. When a host does not get acknowledgments, e.g., to an UPDATE or CLOSE packet after a timeout based on local policies, the host SHOULD resend the packet through the relay, if it was listed in the LOCATOR parameter in the base exchange.
ベース交換後、エンドホストは、ヒップリレーサーバーを介してコントロールパケットを送信せずにデータチャネルに確立されたトランスポートアドレスペアを使用して、ヒップコントロールパケットを互いに直接送信する場合があります。ホストが承認を取得しない場合、たとえば、ローカルポリシーに基づいたタイムアウト後に更新または閉じるパケットへの承認または閉じます。ホストは、ベース交換のロケーターパラメーターにリストされている場合、リレーを介してパケットを再送信する必要があります。
If control packets are sent through a HIP relay server, the host registered with the relay MUST utilize the RELAY_TO parameter as in the base exchange. The HIP relay server SHOULD forward HIP packets to the registered hosts and forward packets from a registered host to the address in the RELAY_TO parameter. The relay MUST add a RELAY_FROM parameter to the control packets it relays to the registered hosts.
コントロールパケットがヒップリレーサーバーを介して送信される場合、リレーに登録されたホストは、ベース交換のようにleray_toパラメーターを使用する必要があります。HIPリレーサーバーは、登録ホストから登録ホストからrelay_toパラメーターのアドレスに転送されたホストに股関節パケットを転送する必要があります。リレーは、登録ホストにリレーするコントロールパケットにrelay_fromパラメーターを追加する必要があります。
If the HIP relay server is not willing or able to relay a HIP packet, it MAY notify the sender of the packet with MESSAGE_NOT_RELAYED error notification (see Section 5.10).
ヒップリレーサーバーが股関節パケットをリレーする意思がないか、またはリレーすることができない場合、message_not_relayedエラー通知でパケットの送信者に通知する場合があります（セクション5.10を参照）。
The following subsections define the parameter and packet encodings for the HIP, ESP, and ICE connectivity check packets. All values MUST be in network byte order.
次のサブセクションでは、股関節、ESP、およびアイス接続のパケットのパラメーターとパケットエンコーディングを定義します。すべての値は、ネットワークバイトの順序でなければなりません。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bits of zeroes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ HIP Header and Parameters ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of UDP-Encapsulated HIP Control Packets
図5：UDPにカプセル化された股関節制御パケットの形式
HIP control packets are encapsulated in UDP packets as defined in Section 2.2 of [RFC3948], "IKE Header Format for Port 4500", except a different port number is used. Figure 5 illustrates the encapsulation. The UDP header is followed by 32 zero bits that can be used to differentiate HIP control packets from ESP packets. The HIP header and parameters follow the conventions of [RFC5201] with the exception that the HIP header checksum MUST be zero. The HIP header checksum is zero for two reasons. First, the UDP header already contains a checksum. Second, the checksum definition in [RFC5201] includes the IP addresses in the checksum calculation. The NATs unaware of HIP cannot recompute the HIP checksum after changing IP addresses.
股関節制御パケットは、別のポート番号が使用されている場合を除き、[RFC3948]のセクション2.2 [ポート4500のIKEヘッダー形式]で定義されているように、UDPパケットにカプセル化されています。図5は、カプセル化を示しています。UDPヘッダーの後には、ESPパケットからヒップコントロールパケットを区別するために使用できる32ゼロビットが続きます。股関節ヘッダーとパラメーターは、股関節ヘッダーチェックサムがゼロでなければならないことを除いて、[RFC5201]の規則に従います。HIPヘッダーチェックサムは、2つの理由でゼロです。まず、UDPヘッダーにはすでにチェックサムが含まれています。第二に、[RFC5201]のチェックサム定義には、チェックサムの計算にIPアドレスが含まれます。股関節を知らないNATは、IPアドレスを変更した後、股関節チェックサムを再計算することはできません。
A HIP relay server or a Responder without a relay SHOULD listen at UDP port 10500 for incoming UDP-encapsulated HIP control packets. If some other port number is used, it needs to be known by potential Initiators.
リレーのないヒップリレーサーバーまたはレスポンダーは、UDPポート10500で聴覚障害のあるUDPにカプセル化された股関節制御パケットを聞く必要があります。他のポート番号が使用されている場合は、潜在的なイニシエーターによって知られる必要があります。
The connectivity checks are performed using STUN Binding requests as defined in [RFC5245]. This section describes the details of the parameters in the STUN messages.
接続チェックは、[RFC5245]で定義されているスタンバインディングリクエストを使用して実行されます。このセクションでは、スタンメッセージのパラメーターの詳細について説明します。
The Binding requests MUST use STUN short-term credentials with the last 32 bits of the HITs of the Initiator and Responder as the username fragments. The username is formed from the username fragments as defined in Section 7.1.1.3 of [RFC5245]. The 32-bit username fragments are expressed using lowercase hexadecimal ASCII characters. The leading zeroes MUST NOT be omitted so that the username's size is fixed (8 characters); for example, if the local HIT is 2001:15:8ebe:1aa7:42f5:b413:7237:6c0a and the remote HIT is 2001:18:46fa:97c0:ba5:cd77:51:47b, the local username would be 72376c0a and the remote username 0051047b.
バインディングリクエストは、イニシエーターの最後の32ビットとユーザー名フラグメントとしてのレスポンダーで、スタン短期資格情報を使用する必要があります。ユーザー名は、[RFC5245]のセクション7.1.1.3で定義されているユーザー名フラグメントから形成されます。32ビットのユーザー名フラグメントは、小文字の16進ASCII文字を使用して表されます。ユーザー名のサイズが固定されているように（8文字）、主要なゼロを省略してはなりません。たとえば、ローカルヒットが2001：15：8EBE：1AA7：42F5：B413：7237：6C0Aの場合、リモートヒットは2001：18：46FA：BA5：CD77：51：47Bです。およびリモートユーザー名0051047B。
The STUN password is drawn from the Diffie-Hellman (DH) keying material. Drawing of HIP keys is defined in [RFC5201], Section 6.5 and drawing of ESP keys in [RFC5202], Section 7. Correspondingly, the hosts MUST draw symmetric keys for STUN according to [RFC5201], Section 6.5. The hosts draw the STUN key after HIP keys, or after ESP keys if ESP transform was successfully negotiated in the base exchange. Both hosts draw a 128-bit key from the DH keying material, express that in hexadecimal ASCII format using only lowercase letters (resulting in 32 numbers or lowercase letters), and use that as both the local and peer password. [RFC5389] describes how hosts use the password for message integrity of STUN messages.
スタンパスワードは、diffie-hellman（DH）キーイング素材から引き出されます。ヒップキーの描画は、[RFC5201]、セクション6.5、および[RFC5202]のESPキーの描画で定義されています。それに対応して、ホストは[RFC5201]、セクション6.5に従ってスタン用の対称キーを描く必要があります。ホストは、ヒップキーの後、またはESP変換が基本交換で正常に交渉された場合、STUNキーを描きます。両方のホストは、DHキーイング素材から128ビットキーを描き、小文字のみ（32の数字または小文字をもたらす）のみを使用して16進ん性ASCII形式で表現し、ローカルパスワードとピアパスワードの両方として使用します。[RFC5389]は、ホストがスタンメッセージのメッセージ整合性にパスワードを使用する方法を説明しています。
Both the username and password are expressed in ASCII hexadecimal format to prevent the need to run them through SASLPrep as defined in [RFC5389].
[RFC5389]で定義されているように、SASLPREPを使用してそれらを実行する必要性を防ぐために、ユーザー名とパスワードの両方がASCII 16進形式で表されます。
The connectivity checks MUST contain the PRIORITY attribute. They MAY contain the USE-CANDIDATE attribute as defined in Section 7.1.1.1 of [RFC5245].
接続チェックには、優先度属性が含まれている必要があります。[RFC5245]のセクション7.1.1.1で定義されているように、ユースキャンディデート属性が含まれている場合があります。
The Initiator is always in the controlling role during a base exchange. When two hosts are initiating a connection to each other simultaneously, the HIP state machine detects it and assigns the host with the larger HIT as the Responder as explained in Sections 4.4.2 and 6.7 in [RFC5201]. Hence, the ICE-CONTROLLED and ICE-CONTROLLING attributes are not needed to resolve role conflicts. However, the attributes SHOULD be added to the connectivity check messages to ensure interoperability with different ICE stacks, and they can be safely ignored on received connectivity checks.
イニシエーターは、基本交換中に常に制御の役割にあります。2人のホストが同時に互いに接続を開始すると、股関節状態マシンはそれを検出し、[RFC5201]のセクション4.4.2および6.7で説明されているように、レスポンダーとしてホストを割り当てます。したがって、役割の競合を解決するためには、氷制御されたアイス制御属性が必要ありません。ただし、属性を接続チェックメッセージに追加して、異なるアイススタックとの相互運用性を確保する必要があり、受信した接続性チェックでは安全に無視できます。
The keepalives for HIP associations that are created with ICE are STUN Binding Indications, as defined in [RFC5389]. In contrast to the UDP-encapsulated HIP header, the non-ESP-marker between the UDP header and the STUN header is excluded. Keepalives MUST contain the FINGERPRINT STUN attribute but SHOULD NOT contain any other STUN attributes and SHOULD NOT utilize any authentication mechanism. STUN messages are demultiplexed from ESP and HIP control packets using the STUN markers, such as the magic cookie value and the FINGERPRINT attribute.
[RFC5389]で定義されているように、氷で作成された股関節関連の採掘剤はスタン結合の適応症です。UDPがカプセル化された股関節ヘッダーとは対照的に、UDPヘッダーとスタンヘッダーの間の非ESPマーカーは除外されます。KeepAlivesには、指紋スタン属性を含める必要がありますが、他のスタン属性を含めるべきではなく、認証メカニズムを利用してはなりません。スタンメッセージは、Magic Cookie値や指紋属性などのスタンマーカーを使用して、ESPおよびHIPコントロールパケットから脱線します。
Keepalives for HIP associations created without ICE are HIP control packets that have NOTIFY as the packet type. The keepalive NOTIFY packets do not contain any parameters.
氷なしで作成された股関節の関連性のキープライブは、パケットタイプとして通知したヒップ制御パケットです。KeepAlive Notifyパケットには、パラメーターが含まれていません。
The format of the NAT_TRAVERSAL_MODE parameter is similar to the format of the ESP_TRANSFORM parameter in [RFC5202] and is shown in Figure 6. This specification defines traversal mode identifiers UDP-ENCAPSULATION and ICE-STUN-UDP. The identifier RESERVED is reserved for future use. Future specifications may define more traversal modes.
NAT_TRAVERSAL_MODEパラメーターの形式は、[RFC5202]のESP_TRANSFORMパラメーターの形式と類似しており、図6に示されています。この仕様は、トラバーサルモード識別子UDPエンコーシングとICE-SUN-UDPを定義します。識別子は予約されていますが、将来の使用のために予約されています。将来の仕様は、より多くのトラバーサルモードを定義する場合があります。
0 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 | Mode ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #2 | Mode ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 608 Length length in octets, excluding Type, Length, and padding Reserved zero when sent, ignored when received Mode ID defines the proposed or selected NAT traversal mode(s)
タイプ608の長さの長さはオクテットの長さ、タイプ、長さ、およびパディングを除く送信時に予約されたゼロを除く、受信モードIDは提案または選択されたNATトラバーサルモードを定義するときに無視します
The following NAT traversal mode IDs are defined:
次のNATトラバーサルモードIDが定義されています。
ID name Value
RESERVED 0
UDP-ENCAPSULATION 1
ICE-STUN-UDP 2
Figure 6: Format of the NAT_TRAVERSAL_MODE Parameter
図6：NAT_TRAVERSAL_MODEパラメーターの形式
The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE parameter. Conversely, a recipient MUST be prepared to handle received NAT traversal mode parameters that contain more than six Mode IDs by accepting the first six Mode IDs and dropping the rest. The limited number of Mode IDs sets the maximum size of the NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order, most preferred mode(s) first.
NAT_TRAVERSAL_MODEパラメーターの送信者は、1つのNAT_TRAVERSAL_MODEパラメーターに6つのモードID以下があることを確認する必要があります。逆に、受信者は、最初の6モードIDを受け入れて残りをドロップすることにより、6つ以上のモードIDを含む受信したNATトラバーサルモードパラメーターを処理する準備をする必要があります。モードIDの限られた数は、NAT_TRAVERSAL_MODEパラメーターの最大サイズを設定します。モードは優先順序で、最初に最も優先モードである必要があります。
The TRANSACTION_PACING parameter shown in Figure 7 contains only the connectivity check pacing value, expressed in milliseconds, as a 32- bit unsigned integer.
図7に示すTransaction_Pacingパラメーターには、32ビットの署名整数としてミリ秒で表される接続チェックペーシング値のみが含まれています。
0 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Ta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 610 Length 4 Min Ta the minimum connectivity check transaction pacing value the host would use
タイプ610長さ4分TAホストが使用する最小接続チェックトランザクションペース値
Figure 7: Format of the TRANSACTION_PACING Parameter
図7：Transaction_Pacingパラメーターの形式
The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is shown in Figure 8. All parameters are identical except for the type. REG_FROM is the only parameter covered with the signature.
reg_from、relay_from、およびleray_toパラメーターの形式を図8に示します。すべてのパラメーターは、タイプを除いて同一です。reg_fromは、署名で覆われた唯一のパラメーターです。
0 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type REG_FROM: 950 RELAY_FROM: 63998 RELAY_TO: 64002 Length 20 Port transport port number; zero when plain IP is used Protocol IANA assigned, Internet Protocol number. 17 for UDP, 0 for plain IP
タイプREG_FROM：950 Relay_from：63998 reay_to：64002長さ20ポート輸送ポート番号。ゼロプレーンIPが使用されている場合、プロトコルIANAが割り当て、インターネットプロトコル番号。UDPの場合は17、プレーンIPの場合は0
Reserved reserved for future use; zero when sent, ignored when received Address an IPv6 address or an IPv4 address in "IPv4-Mapped IPv6 address" format
将来の使用のために予約された予約。送信時のゼロ「IPv4-MappedIPv6アドレス」形式のIPv6アドレスまたはIPv4アドレスを受信したときに無視されます
Figure 8: Format of the REG_FROM, RELAY_FROM, and RELAY_TO Parameters
図8：reg_from、relay_from、relay_toパラメーターの形式
REG_FROM contains the transport address and protocol from which the HIP relay server sees the registration coming. RELAY_FROM contains the address from which the relayed packet was received by the relay server and the protocol that was used. RELAY_TO contains the same information about the address to which a packet should be forwarded.
REG_FROMには、HIPリレーサーバーが登録が来るのを見るトランスポートアドレスとプロトコルが含まれています。relay_fromには、リレーパケットがリレーサーバーによって受信されたアドレスと使用されたプロトコルが含まれています。relay_toには、パケットを転送するアドレスに関する同じ情報が含まれています。
The generic LOCATOR parameter format is the same as in [RFC5206]. However, presenting ICE candidates requires a new locator type. The generic and NAT-traversal-specific locator parameters are illustrated in Figure 9.
一般的なロケーターパラメーター形式は、[RFC5206]と同じです。ただし、氷の候補を提示するには、新しいロケータータイプが必要です。一般的およびNATトラバーサル固有のロケーターパラメーターを図9に示します。
0 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length| Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Loc Type = 2 | Locator Length| Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Port | Transp. Proto| Kind |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: LOCATOR Parameter
図9：ロケーターパラメーター
The individual fields in the LOCATOR parameter are described in Table 2.
ロケーターパラメーターの個々のフィールドを表2に示します。
+-----------+----------+--------------------------------------------+
| Field | Value(s) | Purpose |
+-----------+----------+--------------------------------------------+
| Type | 193 | Parameter type |
| Length | Variable | Length in octets, excluding Type and |
| | | Length fields and padding |
| Traffic | 0-2 | Is the locator for HIP signaling (1), for |
| Type | | ESP (2), or for both (0) |
| Locator | 2 | "Transport address" locator type |
| Type | | |
| Locator | 7 | Length of the fields after Locator |
| Length | | Lifetime in 4-octet units |
| Reserved | 0 | Reserved for future extensions |
| Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the |
| (P) bit | | Responder can use it for the rest of the |
| | | base exchange, otherwise set to zero |
| Locator | Variable | Locator lifetime in seconds |
| Lifetime | | |
| Transport | Variable | Transport layer port number |
| Port | | |
| Transport | Variable | IANA assigned, transport layer Internet |
| Protocol | | Protocol number. Currently only UDP (17) |
| | | is supported. |
| Kind | Variable | 0 for host, 1 for server reflexive, 2 for |
| | | peer reflexive or 3 for relayed address |
| Priority | Variable | Locator's priority as described in |
| | | [RFC5245] |
| SPI | Variable | Security Parameter Index (SPI) value that |
| | | the host expects to see in incoming ESP |
| | | packets that use this locator |
| Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 |
| | | address" format IPv4 address [RFC4291] |
+-----------+----------+--------------------------------------------+
Table 2: Fields of the LOCATOR Parameter
表2：ロケーターパラメーターのフィールド
The RELAY_HMAC parameter value has the TLV type 65520. It has the same semantics as RVS_HMAC [RFC5204].
relay_hmacパラメーター値には、TLVタイプ65520があります。RVS_HMAC[RFC5204]と同じセマンティクスがあります。
The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain Registration Type [RFC5203] values for HIP relay server registration.
REG_INFO、REG_REQ、REG_RESP、およびREG_FAILEDパラメーターには、HIPリレーサーバー登録の登録タイプ[RFC5203]値が含まれています。
The value for RELAY_UDP_HIP is 2.
relay_udp_hipの値は2です。
A HIP relay server and end-hosts can use NOTIFY packets to signal different error conditions. The new Notify Packet Types [RFC5201] defined in this document are shown below. The Notification Data field for the error notifications SHOULD contain the HIP header of the rejected packet and SHOULD be empty for the CONNECTIVITY_CHECKS_FAILED type.
ヒップリレーサーバーとエンドホストは、通知パケットを使用して、異なるエラー条件を通知することができます。このドキュメントで定義されている新しいNotifyパケットタイプ[RFC5201]を以下に示します。エラー通知の通知データフィールドには、拒否されたパケットの股関節ヘッダーが含まれている必要があり、connectivity_checks_failedタイプの場合は空にする必要があります。
NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ -----
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60
no_valid_nat_traversal_mode_parameter 60
If a HIP relay server does not forward a base exchange packet due to missing NAT traversal mode parameter, or the Initiator selects a NAT traversal mode that the Responder did not expect, the relay or the Responder may send back a NOTIFY error packet with this type.
HIPリレーサーバーがNATトラバーサルモードのパラメーターが欠落しているためベースエクスチェンジパケットを転送しない場合、またはイニシエーターが応答者が予想していなかったNATトラバーサルモードを選択する場合、リレーまたはレスポンダーはこのタイプで通知エラーパケットを送り返すことができます。
CONNECTIVITY_CHECKS_FAILED 61
connectivity_checks_failed 61
Used by the end-hosts to signal that NAT traversal connectivity checks failed and did not produce a working path.
エンドホストで使用して、NATトラバーサル接続のチェックが失敗し、作業経路が生成されなかったことを示すために使用されます。
MESSAGE_NOT_RELAYED 62
message_not_relayed 62
Used by a HIP relay server to signal that is was not able or willing to relay a HIP packet.
ヒップリレーサーバーが信号に使用することは、股関節パケットをリレーすることはできません。
[RFC3948] describes the UDP encapsulation of the IPsec ESP transport and tunnel mode. On the wire, the HIP ESP packets do not differ from the transport mode ESP, and thus the encapsulation of the HIP ESP packets is same as the UDP encapsulation transport mode ESP. However, the (semantic) difference to Bound End-to-End Tunnel (BEET) mode ESP packets used by HIP is that IP header is not used in BEET integrity protection calculation.
[RFC3948]は、IPSEC ESP輸送およびトンネルモードのUDPカプセル化について説明しています。ワイヤーでは、股関節ESPパケットはトランスポートモードESPと違いはありません。したがって、股関節ESPパケットのカプセル化は、UDPカプセル化輸送モードESPと同じです。ただし、ヒップで使用されるバインドエンドツーエンドトンネル（ビート）モードESPパケットへの（セマンティック）違いは、IPヘッダーがビート整合性保護計算で使用されていないことです。
During the HIP base exchange, the two peers exchange parameters that enable them to define a pair of IPsec ESP security associations (SAs) as described in [RFC5202]. When two peers perform a UDP-encapsulated base exchange, they MUST define a pair of IPsec SAs that produces UDP-encapsulated ESP data traffic.
ヒップベース交換中、2つのピア交換パラメーターは、[RFC5202]で説明されているように、IPSEC ESPセキュリティ協会（SAS）のペアを定義できるようにします。2人のピアがUDPにカプセル化された基本交換を実行する場合、UDPにカプセル化されたESPデータトラフィックを生成するIPSEC SAのペアを定義する必要があります。
The management of encryption/authentication protocols and SPIs is defined in [RFC5202]. The UDP encapsulation format and processing of HIP ESP traffic is described in Section 6.1 of [RFC5202].
暗号化/認証プロトコルとSPIの管理は[RFC5202]で定義されています。股関節ESPトラフィックのUDPカプセル化形式と処理は、[RFC5202]のセクション6.1で説明されています。
The locators are in plain text format in favor of inspection at HIP-aware middleboxes in the future. The current document does not specify encrypted versions of LOCATORs, even though it could be beneficial for privacy reasons to avoid disclosing them to middleboxes.
ロケーターは、将来的にはヒップアウェアのミドルボックスでの検査を支持して、平易なテキスト形式です。現在のドキュメントでは、ロケーターの暗号化されたバージョンのバージョンを指定していませんが、プライバシーの理由でそれらをミドルボックスに開示しないようにすることは有益です。
It is also possible that end-users may not want to reveal all locators to each other. For example, tracking the physical location of a multihoming end-host may become easier if it reveals all locators to its peer during a base exchange. Also, revealing host addresses exposes information about the local topology that may not be allowed in all corporate environments. For these two reasons, an end-host may exclude certain host addresses from its LOCATOR parameter. However, such behavior creates non-optimal paths when the hosts are located behind the same NAT. Especially, this could be problematic with a legacy NAT that does not support routing from the private address realm back to itself through the outer address of the NAT. This scenario is referred to as the hairpin problem [RFC5128]. With such a legacy NAT, the only option left would be to use a relayed transport address from a TURN server.
エンドユーザーがすべてのロケーターを互いに見せたくない場合もあります。たとえば、マルチホームのエンドホストの物理的な位置を追跡すると、ベース交換中にすべてのロケーターがピアに表示されると、簡単になる場合があります。また、ホストアドレスを明らかにすると、すべての企業環境で許可されない可能性のあるローカルトポロジに関する情報が公開されます。これら2つの理由により、エンドホストは、ロケーターパラメーターから特定のホストアドレスを除外する場合があります。ただし、そのような動作は、ホストが同じNATの後ろに配置されている場合、非最適パスを作成します。特に、これは、NATの外側のアドレスを介してプライベートアドレスの領域からそれ自体へのルーティングをサポートしていないレガシーNATで問題がある可能性があります。このシナリオは、ヘアピン問題[RFC5128]と呼ばれます。このようなレガシーNATを使用すると、唯一のオプションは、ターンサーバーからの中継輸送アドレスを使用することです。
The use of HIP relay servers and TURN relays can be also useful for privacy purposes. For example, a privacy concerned Responder may reveal only its HIP relay server and Relayed candidates to Initiators. This same mechanism also protects the Responder against Denial-of-Service (DoS) attacks by allowing the Responder to initiate new connections even if its relays would be unavailable due to a DoS attack.
ヒップリレーサーバーとターンリレーの使用は、プライバシーの目的にも役立ちます。たとえば、関係するリスポンダーに関係するプライバシーは、ヒップリレーサーバーのみを明らかにし、候補者をイニシエーターに中継する場合があります。また、この同じメカニズムは、DOS攻撃のためにリレーが利用できなくても、レスポンダーが新しい接続を開始できるようにすることにより、サービス拒否（DOS）攻撃からレスポンダーを保護します。
A HIP relay server should have one address per relay client when a HIP relay is serving more than one relay client and supports opportunistic mode. Otherwise, it cannot be guaranteed that the HIP relay server can deliver the I1 packet to the intended recipient.
ヒップリレーが複数のリレークライアントを提供し、日和見モードをサポートしている場合、ヒップリレーサーバーにはリレークライアントごとに1つのアドレスが必要です。それ以外の場合は、HIPリレーサーバーがI1パケットを意図した受信者に配信できることを保証することはできません。
In certain scenarios, it is possible that an attacker, or two attackers, can replay an earlier base exchange through a HIP relay server by masquerading as the original Initiator and Responder. The attack does not require the attacker(s) to compromise the private key(s) of the attacked host(s). However, for this attack to succeed, the Responder has to be disconnected from the HIP relay server.
特定のシナリオでは、攻撃者、または2人の攻撃者が、元のイニシエーターとレスポンダーを装って、ヒップリレーサーバーを介して以前のベース交換を再生できる可能性があります。攻撃では、攻撃者が攻撃されたホストの秘密鍵を妥協する必要はありません。ただし、この攻撃を成功させるには、レスポンダーをヒップリレーサーバーから切断する必要があります。
The relay can protect itself against replay attacks by becoming involved in the base exchange by introducing nonces that the end-hosts (Initiator and Responder) are required to sign. One way to do this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets as described in [HIP-MIDDLE] and drop the I2 or R2 packets if the corresponding ECHO_RESPONSE_M parameters are not present.
リレーは、エンドホスト（イニシエーターとレスポンダー）が署名する必要があることを導入することにより、基本交換に関与することにより、リプレイ攻撃から身を守ることができます。これを行う1つの方法は、対応するECHO_RESPONSE_Mパラメーターが存在しない場合、[HIP-MIDDLE]で説明されているように、R1およびI2パケットにECHO_REQUEST_MパラメーターをR1およびI2パケットに追加し、I2またはR2パケットをドロップすることです。
Section 5.1 of [RFC3948] describes a security issue for the UDP encapsulation in the standard IP tunnel mode when two hosts behind different NATs have the same private IP address and initiate communication to the same Responder in the public Internet. The Responder cannot distinguish between two hosts, because security associations are based on the same inner IP addresses.
[RFC3948]のセクション5.1は、異なるNATの背後にある2つのホストが同じプライベートIPアドレスを持ち、パブリックインターネットで同じレスポンダーとの通信を開始した場合、標準のIPトンネルモードでのUDPカプセル化のセキュリティ問題について説明します。セキュリティ関連は同じ内部IPアドレスに基づいているため、レスポンダーは2つのホストを区別できません。
This issue does not exist with the UDP encapsulation of HIP ESP transport format because the Responder uses HITs to distinguish between different Initiators.
この問題は、Responderがヒットを使用して異なるイニシエーターを区別するため、HIP ESP輸送形式のUDPカプセル化には存在しません。
This section is to be interpreted according to [RFC5226].
このセクションは、[RFC5226]に従って解釈されます。
This document updates the IANA Registry for HIP Parameter Types [RFC5201] by assigning new HIP Parameter Type values for the new HIP Parameters: RELAY_FROM, RELAY_TO, and REG_FROM (defined in Section 5.6), RELAY_HMAC (defined in Section 5.8), TRANSACTION_PACING (defined in Section 5.5), and NAT_TRAVERSAL_MODE (defined in Section 5.4).
このドキュメントは、新しい股関節パラメータータイプの値を割り当てることにより、股関節パラメータータイプ[RFC5201]のIANAレジストリを更新します：relay_from、relay_to、およびreg_from（セクション5.6で定義）、reay_hmac（セクション5.8で定義）、transaction_pacing（didedineセクション5.5）、およびnat_traversal_mode（セクション5.4で定義）。
This document defines an additional registration type for the HIP Registration Extension [RFC5203] that allows registering with a HIP relay server for relaying service: RELAY_UDP_HIP (defined in Section 5.9).
このドキュメントでは、リレーサービスのHIPリレーサーバーに登録することを可能にする股関節登録拡張拡張機能[RFC5203]の追加の登録タイプを定義します：leray_udp_hip（セクション5.9で定義）。
This document also defines NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER, CONNECTIVITY_CHECKS_FAILED, and MESSAGE_NOT_RELAYED Notify Packet Types [RFC5201] in Section 5.10.
このドキュメントは、no_valid_nat_traversal_mode_parameter、connectivity_checks_failed、およびmessage_not_relayed notify packet型[rfc5201]をセクション5.10に定義します。
The NAT_TRAVERSAL_MODE parameter has 16-bit unsigned integer fields for different modes, for which IANA has created and maintains a new sub-registry entitled "HIP NAT Traversal Modes" under the "Host Identity Protocol (HIP) Parameters". Initial values for the NAT traversal mode registry are given in Section 5.4; future assignments are to be made through IETF Review [RFC5226]. Assignments consist of a NAT traversal mode identifier name and its associated value.
NAT_TRAVERSAL_MODEパラメーターには、さまざまなモード用の16ビットの署名されていない整数フィールドがあり、IANAは「ホストIDプロトコル（HIP）パラメーター」の下で「HIP NAT Traversal Modes」というタイトルの新しいサブレジストリを作成および維持しています。NATトラバーサルモードレジストリの初期値は、セクション5.4に記載されています。将来の割り当ては、IETFレビュー[RFC5226]を通じて行われます。割り当ては、NATトラバーサルモード識別子名とそれに関連する値で構成されています。
This RFC is a product of a design team that also included Marcelo Bagnulo and Philip Matthews, who both have made major contributions to this document.
このRFCは、マルセロ・バグヌロとフィリップ・マシューズも含まれているデザインチームの製品であり、どちらもこの文書に大きな貢献をしています。
Thanks to Jonathan Rosenberg and the rest of the MMUSIC WG folks for the excellent work on ICE. In addition, the authors would like to thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, Vivien Schmitt, and Abhinav Pathak for their contributions and Tobias Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, and Jani Hautakorpi for their comments on this document.
Jonathan Rosenbergと、氷上での優れた作品を提供してくれたMMUSIC WGの残りの人々に感謝します。さらに、著者は、Andrei Gurtov、Simon Schuetz、Martin Stiemerling、Lars Eggert、Vivien Schmitt、Abhinav Pathakの貢献とToemu Koponen、Juhana Mattila、Jeffrey M.、Pekka Nikander、Lauri Silvennoinen、Jukka Ylitalo、Juha Heinanen、Joakim Koskela、Samu Varjonen、Dan Wing、Jani Hautakorpiがこの文書についてのコメントをしてくれました。
Miika Komu has been working in the Networking Research group at Helsinki Institute for Information Technology (HIIT). The work has been funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence Forces, Ericsson and Birdstep in InfraHIP I and II projects.
Miika Komuは、Helsinki Institute for Information Technology（HIIT）のネットワーキング研究グループで働いています。この作業は、Tekes、Telia-Sonera、Elisa、Nokia、Finnish Defense Forces、Ericsson、およびBirdstepによって、IおよびIIプロジェクトによって資金提供されています。
[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月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423] Moskowitz、R。およびP. Nikander、「ホストアイデンティティプロトコル（HIP）アーキテクチャ」、RFC 4423、2006年5月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5202] Jokela、P.、Moskowitz、R。、およびP. Nikander、「ホストIDプロトコル（HIP）を使用したセキュリティペイロード（ESP）輸送形式を使用して」、RFC 5202、2008年4月。
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 5203, April 2008.
[RFC5203] Laganier、J.、Koponen、T。、およびL. Eggert、「Host Identity Protocol（HIP）登録拡張」、RFC 5203、2008年4月。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
[RFC5204] Laganier、J。およびL. Eggert、「ホストアイデンティティプロトコル（HIP）Rendezvous Extension」、RFC 5204、2008年4月。
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206] Nikander、P.、Henderson、T.、Vogt、C。、およびJ. Arkko、「ホストIDプロトコルによるエンドホストモビリティとマルチホミング」、RFC 5206、2008年4月。
[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月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Indecivity（ICE）：オファー/回答プロトコルのネットワークアドレス翻訳者（NAT）トラバーサルのプロトコル」、RFC 5245、2010年4月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NATのセッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。
[RFC5766] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766] Rosenberg、J.、Mahy、R。、およびP. Matthews、「NAT周辺のリレーを使用したトラバーサル：NAT（STUN）のセッショントラバーサルユーティリティへのリレー拡張機能」、RFC 5766、2010年4月。
[HIP-MIDDLE] Heer, T., Wehrle, K., and M. Komu, "End-Host Authentication for HIP Middleboxes", Work in Progress, February 2009.
[Hip-Middle] Heer、T.、Wehrle、K。、およびM. Komu、「HIP Middleboxのエンドホスト認証」、2009年2月の作業。
[MMUSIC-ICE] Rosenberg, J., "Guidelines for Usage of Interactive Connectivity Establishment (ICE) by non Session Initiation Protocol (SIP) Protocols", Work in Progress, July 2008.
[MMUSIC-ICE] Rosenberg、J。、「セッション開始プロトコル（SIP）プロトコルによるインタラクティブ接続確立（ICE）の使用に関するガイドライン」、2008年7月の作業。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、Volpe、V.、Diburro、L。、およびM. Stenberg、「IPSEC ESPパケットのUDPカプセル化」、RFC 3948、2005年1月。
[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月。
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, March 2008.
[RFC5128] Srisuresh、P.、Ford、B。、およびD. Kegel、「ネットワークアドレス翻訳者（NAT）全体のピアツーピア（P2P）通信」、RFC 5128、2008年3月。
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, April 2008.
[RFC5207] Stiemerling、M.、Quittek、J。、およびL. Eggert、「Nat and Firewall Traversal Issus of Host Identity Protocol（HIP）Communication」、RFC 5207、2008年4月。
Selecting a suitable value for the connectivity check transaction pacing is essential for the performance of connectivity check-based NAT traversal. The value should not be so small that the checks cause network congestion or overwhelm the NATs. On the other hand, a pacing value that is too high makes the checks last for a long time, thus increasing the connection setup delay.
接続チェックトランザクションペーシングに適した値を選択することは、接続チェックベースのNATトラバーサルのパフォーマンスに不可欠です。値がそれほど小さいように、チェックがネットワークの混雑を引き起こしたり、NATを圧倒したりすることはありません。一方、ペーシング値が高すぎると、チェックが長く続くため、接続のセットアップ遅延が増加します。
The Ta value may be configured by the user in environments where the network characteristics are known beforehand. However, if the characteristics are not known, it is recommended that the value is adjusted dynamically. In this case, it's recommended that the hosts estimate the round-trip time (RTT) between them and set the minimum Ta value so that only two connectivity check messages are sent on every RTT.
TA値は、ネットワーク特性が事前に既知の環境でユーザーによって構成される場合があります。ただし、特性が不明な場合は、値を動的に調整することをお勧めします。この場合、ホストはそれらの間の往復時間（RTT）を推定し、最小TA値を設定して、すべてのRTTで2つの接続チェックメッセージのみが送信されるようにすることをお勧めします。
One way to estimate the RTT is to use the time it takes for the HIP relay server registration exchange to complete; this would give an estimate on the registering host's access link's RTT. Also, the I1/R1 exchange could be used for estimating the RTT, but since the R1 can be cached in the network, or the relaying service can increase the delay notably, it is not recommended.
RTTを推定する1つの方法は、HIPリレーサーバー登録交換が完了するまでの時間を使用することです。これにより、登録ホストのアクセスリンクのRTTの見積もりが得られます。また、I1/R1交換はRTTの推定に使用できますが、R1をネットワークでキャッシュできるか、リレーサービスが遅延を顕著に増加させる可能性があるため、推奨されません。
When the Initiator looks up the information of the Responder from DNS, it's possible that it discovers a rendezvous server (RVS) record [RFC5204]. In this case, if the Initiator uses NAT traversal methods described in this document, it MAY use its own HIP relay server to forward HIP traffic to the rendezvous server. The Initiator will send the I1 packet using its HIP relay server, which will then forward it to the RVS server of the Responder. In this case, the value of the protocol field in the RELAY_TO parameter MUST be IP since RVS does not support UDP-encapsulated base exchange packets. The Responder will send the R1 packet directly to the Initiator's HIP relay server and the following I2 and R2 packets are also sent directly using the relay.
イニシエーターがDNSからのレスポンダーの情報を調べると、Rendezvousサーバー（RVS）レコード[RFC5204]を発見する可能性があります。この場合、イニシエーターがこのドキュメントで説明されているNATトラバーサルメソッドを使用する場合、独自のヒップリレーサーバーを使用して、Rendezvousサーバーに股関節トラフィックを転送する場合があります。イニシエーターは、HIPリレーサーバーを使用してi1パケットを送信し、それをレスポンダーのRVSサーバーに転送します。この場合、RVSはUDPにカプセル化されたベース交換パケットをサポートしていないため、Relay_TOパラメーターのプロトコルフィールドの値はIPでなければなりません。レスポンダーはR1パケットをイニシエーターのヒップリレーサーバーに直接送信し、次のI2およびR2パケットもリレーを使用して直接送信されます。
In case the Initiator is not able to distinguish which records are RVS address records and which are Responder's address records (e.g., if the DNS server did not support HIP extensions), the Initiator SHOULD first try to contact the Responder directly, without using a HIP relay server. If none of the addresses are reachable, it MAY try them out using its own HIP relay server as described above.
イニシエーターがどのレコードがRVSアドレスレコードであるか、どのレコードがレスポンダーのアドレスレコードであるかを区別できない場合（例：DNSサーバーが股関節拡張機能をサポートしていない場合）リレーサーバー。上記のように、アドレスに到達可能なアドレスがない場合、独自のヒップリレーサーバーを使用して試してみることができます。
Authors' Addresses
著者のアドレス
Miika Komu Helsinki Institute for Information Technology Metsanneidonkuja 4 Espoo Finland Phone: +358503841531 Fax: +35896949768 EMail: miika@iki.fi URI: http://www.hiit.fi/
Miika Komu Helsinki Institute for Information Technology Metsanneidonkuja 4 Espoo Finland電話：358503841531 FAX：35896949768メール：miika@iki.fi URI：http：//www.hiit.fi/
Thomas Henderson The Boeing Company P.O. Box 3707 Seattle, WA USA EMail: thomas.r.henderson@boeing.com
トーマス・ヘンダーソンボーイングカンパニーP.O.ボックス3707シアトル、ワシントン州USAメール：thomas.R.henderson@boeing.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at/
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド電話：358（50）4871445メール：hannes.tschofenig@gmx.net uri：http://www.tschofenig.priv.priv.p
Jan Melen Ericsson Research Nomadiclab Hirsalantie 11 02420 Jorvas Finland Phone: +358 9 2991 EMail: jan.melen@ericsson.com
Jan Melen Ericsson Research Nomadiclab Hirsalantie 11 02420 Jorvas Finland電話：358 9 2991メール：jan.melen@ericsson.com
Ari Keranen (editor) Ericsson Research Nomadiclab Hirsalantie 11 02420 Jorvas Finland Phone: +358 9 2991 EMail: ari.keranen@ericsson.com
Ari Keranen（編集者）Ericsson Research Nomadiclab Hirsalantie 11 02420 Jorvas Finland電話：358 9 2991メール：ari.keranen@ericsson.com