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
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）トラバーサルを容易にするために、ホスト識別プロトコル（HIP）への拡張を指定します。拡張は、2つのエンドホスト間の現用パスを発見するためのインタラクティブ接続確立（ICE）の方法論の使用上、およびユーザーデータグラムプロトコル（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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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はまた、IPv4またはIPv6の上で実行するように指定されたESPセキュリティアソシエーション[RFC5202]の設定を調整します。このアプローチは、NATをし、他のミドルボックス[RFC5207]を横断する問題があることが知られています。この文書では、ネットワークアドレス変換（NAT）とネットワークアドレスとポートトランスレータ（NAPT）ミドルボックスの両方のトラバーサルのためのHIP拡張を定義します。文書は、一般的にミドルボックスのこれらのタイプを参照するために長期的な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デバイスでも動作するように、この文書のHIPプロトコル拡張は、NATデバイスの動作についてできるだけ少数の仮定を行います。これらの拡張の目的は、一つまたは通信ホストの両方が1つまたは複数のNATの背後にあるネットワークにあっても、互いに通信するために2つのHIP対応のホストを可能にすることです。
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.
この文書で定義された拡張機能を使用して、HIPのエンドホストは、HIP制御プロトコルおよびESPは、データトラフィックをカプセル化するための動作経路を見つけるためにインタラクティブ接続確立（ICE）の方法論[RFC5245]から引き出された技術を使用します。ホストが異なるロケータ間の接続をテストし、それらの間の直接的なエンド・ツー・エンドのパスを発見してみてください。しかし、いくつかの従来のNATと、NATの背後に位置する2つのエンドホスト間の最短経路を利用することは、リレーNAT（TURN）サーバ[RFC5128]を使用してトラバーサルとして、リレーを介してトラフィックを中継せずには不可能です。トラフィックを中継する往復遅延が増加し、リレーからのリソースを消費するので、このドキュメントで説明する機能拡張で、ホストは、可能な限りTURNサーバーを使用しないようにしてみてください。
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は、インターネットに安定な点の接触を確立するためにモバイルHIPホストを可能にするために、ランデブーサーバ[RFC5204]を定義しています。この文書では、同じ問題を解決ランデブーサーバへの拡張を定義しますが、NAT変換と非NAT変換ネットワークの両方のために。拡張ランデブーサーバは、ホストがNATの背後に配置されることを可能にする、「HIP中継サーバ」、イニシエータとレスポンダとの間の転送HIP制御パケットと呼ばれます。この現象は、塩基交換の唯一の初期I1パケットを転送HIPランデブーサービスとは対照的です。 NAT変換環境[RFC5128]で作業しにくいアプローチ。 NATをトラバースするためにリレーを使用する場合したがって、HIPは、制御トラフィックとデータトラフィックのためのTURNサーバのHIP中継サーバを使用します。
The basis for the connectivity checks is ICE [RFC5245]. [RFC5245] describes ICE as follows:
接続性チェックのための基礎は、ICE [RFC5245]です。次のように[RFC5245]はICEについて説明します。
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.
オファー/アンサーモデルによって確立（ICEは、TCPのような他のトランスポートプロトコルを扱えるように拡張することができますが）UDPベースのメディアストリームのためのNATトラバーサルのための技術。 ICEは、オファー/アンサーモデルに拡張され、その後、ピア・ツー・ピア接続性チェックにより接続について試験するSDPオファーや回答、内のIPアドレスとポートを多数含むことにより動作します。 IPアドレスとポートは、SDPに含まれる接続性チェックは、現在NATのためのセッショントラバーサルユーティリティに改名仕様改訂[NAT（STUN）を介してUDPプロトコルの簡易トラバーサル] [RFC5389]を使用して行われます。
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つのHIPホストはHIP基本交換で互いにそのロケータを伝えます。ロケータは、推奨され、ローカルポリシーに応じて、他のエンドポイントのロケータとペアにし、優先順位付けされています。これらロケータ対は次いでエンドホストの両方によって連続的に試験されます。テストは、複数の動作ペアをもたらすことができるが、ICE手順は、後続の通信に使用する単一の好ましいアドレスのペアを決定します。
In summary, the extensions in this document define:
要約すると、このドキュメントの拡張子が定義されます。
o UDP encapsulation of HIP packets
HIPパケットのUDPカプセル化O
o UDP encapsulation of IPsec ESP packets
IPsecのESPパケットのUDPカプセル化O
o registration extensions for HIP relay services
HIPリレーサービスのためのO登録の拡張
o how the ICE "offer" and "answer" are carried in the base exchange
O ICE「提供」と「答えは」塩基交換で運ばれる方法
o interaction with ICE connectivity check messages
ICEの接続性チェックメッセージとOとの相互作用
o backwards compatibility issues with rendezvous servers
ランデブーサーバとOの後方互換性の問題
o a number of optimizations (such as when the ICE connectivity tests can be omitted)
O（例えば、ICE接続試験を省略することができる場合など）の最適化の数
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
ランデブーサーバー：レスポンダにI1パケットを転送するホスト。
HIP relay server: A host that forwards any kind of HIP control packets between the Initiator and the Responder.
HIP中継サーバー：イニシエータとレスポンダ間のHIP制御パケットのいずれかの種類を転送するホスト。
TURN server: A server that forwards data traffic between two end-hosts as defined in [RFC5766].
TURNサーバ：[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]で定義されたように：「パケットがネットワークを介してルーティングされ、エンドホストにより分離される方法を制御する名前は、このようなIPv6アドレスとエンド・ツー・エンドのような従来のネットワークアドレスの連結を含むことができますこのようESP SPIなどの識別子。また、分波コンテキストとして輸送ポート番号またはIPv6フローラベルを含むことができ、またはそれは単にネットワークアドレスであってもよいです。」
LOCATOR (written in capital letters): Denotes a HIP control packet parameter that bundles multiple locators together.
（大文字で書かれた）LOCATORは：複数のロケータを一緒にバンドルHIP制御パケットのパラメータを示します。
ICE offer: The Initiator's LOCATOR parameter in a HIP I2 control packet.
ICEの提供：HIPのI2制御パケット内のイニシエータのLOCATORパラメタ。
ICE answer: The Responder's LOCATOR parameter in a HIP R2 control packet.
ICEの答え：HIP R2制御パケット内のレスポンダのLOCATORパラメタ。
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.
サーバーの再帰候補：HIP中継サーバーまたはSTUN / TURNサーバによって観察されるようにホストの変換トランスポートアドレス。
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.
中継された候補：TURNサーバー上に存在するトランスポート・アドレス。このアドレスに到着したパケットは、TURNクライアントに向けて中継されます。
+-------+
| 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に示す構成例では、イニシエータとレスポンダの双方は、一の以上のNATの背後にあり、両方のプライベートネットワーク、パブリックインターネットに接続されています。 NATの背後に、Responderが公共のインターネット上で到達可能なHIPリレーサーバに登録する必要があり、私たちはイニシエータがレスポンダのホストアイデンティティタグ（HIT）とのアドレスの両方を知っていること、出発点として、仮定から接触しますその中継サーバの一つが（イニシエータがレスポンダのリレーサーバの学習方法このドキュメントの範囲外ですが、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.
イニシエータとレスポンダの両方が（同じものである必要はありません）は、中継サーバに登録したアドレス候補のセットを収集するための最初のステップです。ホストは、候補者を集めるためTURNとSTUNサーバを使用することができます。次に、HIP基本交換は、UDPデータグラムでHIP制御パケットをカプセル化し、レスポンダのリレーサーバを介してそれらを送信することにより行われます。塩基交換の一環として、各HIPホストは、塩基交換に埋め込まれICEのオファー/アンサー手続きを通じてピアの候補アドレスを学習します。
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データフローのため、好ましくは中継せずに、より良好なパスを見つけるために働きます。アドレスのワーキングペアが発見されるまで、このために、ICE接続性チェックが行われています。手続きの終了時に、成功した場合、ホストはデータがNATまたはTURNサーバーを経由してNATから直接流れると、両方のNATを通過するUDPベースのフローを有効にしています。さらにHIPシグナリングは、同じアドレス/ポートの対を介して送信することができ、ペイロード内のマーカを介してデータトラフィックから分離されます。必要に応じ最後に、NATキープアライブが送信されます。
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の背後ではないことを知っている場合、ホストは、塩基交換時にICEの接続性チェックを使用していないNATトラバーサルが、HIPとESPのUDPカプセル化のみの異なるモードを交渉することができます。イニシエータが同時にUDPカプセル化とない塩基交換をしようとするためにも、それが可能です。 UDPカプセル化せずに塩基交換が成功した場合は、ICEの接続性チェックや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.
HIPランデブーサーバは、非NAT変換の環境で動作し、それらの使用は[RFC5204]に記述されています。このセクションでは、NAT変換の環境で動作するためのHIP中継サーバーと呼ばれる新しいミドル拡張子を指定します。 HIPリレーサーバは、イニシエータとレスポンダ間のHIP制御パケットを転送します。
End-hosts cannot use the HIP relay service for forwarding the ESP data plane. Instead, they use TURN servers [RFC5766].
エンドホストは、ESPデータプレーンを転送するためのHIPリレーサービスを使用することはできません。代わりに、彼らは、TURNサーバ[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.
HIPリレーサーバは黙っ以前HIPリレーに登録されていないHIPリレークライアントにパケットをドロップしなければなりません。登録プロセスは[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：HIPリレーは、実施例の登録
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アソシエーションの全てが閉じられるまでは、割り当てられたポートを維持しなければなりません。 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リレーサーバ（レスポンダ）は、R1パケットでサポートするサービスが一覧表示されます。 HIP-オーバー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パラメータでそれらを示しています。イニシエータは、リクエストパラメータにRELAY_UDP_HIP値をリストすることによって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において、レスポンダは、R2パケットで登録手順を終了し、REG_RESパラメータに登録されたサービスを認識しています。 ResponderはR2のREG_FAILEDパラメータに失敗した登録を（もしあれば）です。 Responderはまた、リレー（サーバ再帰候補）によって観察されるように、クライアントのトランスポートアドレスが含まれているREG_FROMパラメータを含んでいます。クライアントと生きてリレー間の可能なNATバインディングを維持するために定期的にリレーに、4.7節で説明したように登録後、クライアントは、NATキープアライブを送信します。リレークライアントは、それがそこからサービスを中継必要とリレーサーバとのHIPの関連性を維持します。
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で定義されるように、候補収集が行われるべきです。候補者は、HIPおよびESPトラフィックのUDPカプセル化の流れのために収集する必要があります。この流れは、1つのICEのメディアストリームおよびコンポーネントに対応しています。 ICEコンポーネントIDが必要とされないので、明示的にシグナリングされず、1のID値は、必要なICE処理に使用されるべきです。イニシエータは、ICEの制御エージェントの役割を果たしています。
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.
候補収集はいつでも行うことができ、それはICEは接続性チェックのために使用される場合、ベース交換にI2またはR2を送信する前に行われる必要があります。候補者のすべての3つのタイプ（ホスト、再帰サーバー、および中継）が成功したNATトラバーサルの確率を最大化するために集まっていることが推奨されます。ただし、TURNサーバーを使用しない場合、ホストが使用する唯一の単一のローカルIPアドレスを持っている、ホストはホスト候補と再帰サーバとしてリレー登録時に発見された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.
このセクションでは、新しいノンクリティカルなパラメータの型の使用方法を説明します。 HIPベース交換におけるパラメータの存在は、エンドホストは、この文書で説明する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.
HIPリレーへの登録と、通常、リレーはパブリックアドレス空間にあると想定されているのでNATトラバーサルのUDPカプセル化モードを使用することで十分です。したがって、リレーは、好ましいまたは唯一のモードとしてUDPカプセル化モードを提案するべきです。
The NAT traversal mode negotiation in a HIP base exchange is illustrated in Figure 3.
HIP基本交換における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を送信します。これは、レスポンダによって提供されるモードのリストからイニシエータによって選択されたモードが含まれています。 ICEモードを選択した場合、I2もLOCATORパラメータのイニシエータの「トランスポートアドレス」ロケータを（5.7節で定義されている）が含まれています。 I2でのロケータは、「ICEの提供」です。
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において、レスポンダは、R2パケットで塩基交換を終了します。イニシエータは、ICEのNATトラバーサルモードを選択した場合、ResponderはR2パケットでLOCATORパラメータを含んでいます。 I2でのロケータのようにエンコードされたR2でロケータは、「ICEの答え」です。イニシエータによって選択されたNATトラバーサルモードがレスポンダによってサポートされていない場合、レスポンダは、型NO_VALID_NAT_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ミリ秒よりも小さい値を使用しないでください。イニシエータは、レスポンダが提供するものよりも小さい値を提案してはなりません。
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.
このセクションでは、イニシエータとレスポンダは、HIPのリレーサーバを介してベース交換を行う方法を説明します。 （例ではNAT_TMと表記）NATトラバーサルモードネゴシエーションは、4.3節で説明した、ここでは繰り返されていません。リレーは、NATトラバーサルモードパラメータなしでR1かI2パケットを受信した場合、それを削除する必要がありますし、R1 / I2の送信者に型NO_VALID_NAT_TRAVERSAL_MODE_PARAMETERとNOTIFYエラーパケットを送るべきです。
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.
それはレスポンダのIPv4アドレスを宛先としているとき、イニシエータはUDPでカプセル化されたI1パケットを送信することが推奨されます。それぞれ、レスポンダはまた、UDPカプセル化を使用しなければならない、UDPカプセル化R1パケットと塩基交換、I2及びR2の残りの部分とそのようなI1パケットに応答しなければなりません。
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：HIPリレーサーバを経由して基地交換
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では、イニシエータは、HIP中継サーバのレスポンダとIPアドレスとポートのHITへ輸送層上I1パケットを送信します。送信元アドレスは、イニシエータのロケータの一つです。
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において、HIP中継サーバは、I1パケットを受信します。先のHITが登録レスポンダに属している場合、リレーは、パケットを処理します。そうしないと、リレーは静かにパケットをドロップしなければなりません。リレーは、リレーによって観察されるようI1の搬送元アドレスとポートを含んI1パケットにRELAY_FROMパラメータを追加します。 [RFC5204]に記載されているように、中継パラメータタイプ（5.8節を参照）が異なることを除いて、RELAY_HMACとI1パケットを保護します。リレーは、リレーへの登録時にレスポンダが使用される値と一致するパケットの送信元ポートおよび宛先ポート及び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を検証し、検証が失敗した場合サイレントパケットをドロップ。 Responderは、それがRELAY_TOとNATトラバーサルモードパラメータを含んでいるにR1パケットで応答します。 RELAY_TOパラメータは、すなわち、RELAY_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パケットを受信します。ソースHITは、未登録のホストに属している場合、リレーは黙ってパケットをドロップします。リレーは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において、イニシエータは、[RFC5201]に記載R1パケットを受信し、それを処理します。それはすべての既知の地元の候補者と異なる場合、イニシエータは、このHIP協会のローカルピア再帰候補としてRELAY_TOパラメータのアドレスを使用するかもしれません。イニシエータは、送信元アドレスとポートとしてR1の宛先トランスポートアドレスを使用I2パケットで応答します。 I2パケットは、イニシエータのすべてのICE候補（ICEプランを）示していますLOCATORパラメータが含まれています。候補は、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.
ステップ7において、レスポンダは、[RFC5201]に記載I2パケットを受信し、それを処理します。これは、R2のパケットで応答し、3. R2パケットはレスポンダのすべてのICE候補（ICEの答えを）示していますLOCATORパラメータを含んでいる段階で説明したようにRELAY_TOパラメータを含んでいます。 RELAY_TOパラメータは、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.
リレーは、イニシエータにパケットを転送し、ステップ4で説明したようにステップ8において、リレーは、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.
それらはHIPシグナリングを中継するため、このようなサーバを使用する場合のホストベースの交換が完了した直後にI2 / R2でLOCATORパラメタに（初期シグナリングのために使用されているものを含む）は、1つ以上のHIP中継サーバのアドレスを含まなければなりません。
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.
これらのアドレスのトラフィックタイプは、「HIPシグナリング」でなければならないと、彼らはICE候補として使用してはいけません。塩基交換のために使用さHIP中継サーバロケータがI2 / R2ロケータパラメータに含まれていない場合には、塩基交換の後に使用されるべきではなく、さらにHIPシグナリングは、データトラフィックと同じ経路を使用すべきです。
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.
HIP中継サーバーを使用した場合、Responderは、リレーを通じてR2パケットで塩基交換を完了します。しかし、イニシエータとレスポンダは、塩基交換パケットのために使用される宛先アドレスは、HIP中継サーバに属しています。したがって、そのアドレスは、ESPトラフィックの宛先として使用してはいけません。 ICE接続性チェックと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.
ICE接続性チェックのためのチェックリストを作成することのみ1つのメディアストリームおよびコンポーネントが必要とされる心に[RFC5245]ベアリング（セクション5.7に記載のように実施されなければならないので、そこに単一のチェックリストであろうと、すべての候補が同じコンポーネントIDを有していなければなりません値）。 [RFC5245]のセクション7で説明したように、実際の接続性チェックが実行されなければなりません。通常モードは、候補指名のために使用されるべきです。 5.2節は、STUN制御パケットの内容を定義します。 ICE接続性チェックの結果として、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))
RTO = MAX（500msのはTa *（NUM-待機+テンキー進行中））
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は接続性チェックペーシングのために使用される値であり、民ウェイティングは、「待機」状態にあるチェックリストのペアの数であり、民進行中「とのInにおけるペアの数でありますプログレス」状態。唯一のチェックリストがある場合、これは[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).
ICE接続性チェックが失敗した場合は、ホストがお互いにESPトラフィックを送ってはいけませんが、HIPパケットベースの交換に使用するロケータを使用して通信を継続することができます。また、ホストがパケットをNOTIFY 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状態を防ぐために、通信ホストがお互いに定期的にキープアライブを送信します。 HIPの中継サーバは、彼らがキープアライブを必要とミドルの後ろではないことが知られていた場合にキープアライブを送信することを控えることができます。エンドホストは、コントロールまたはデータチャネルがアイドル状態のときにNAT（複数可）でのUDPポートマッピングを更新する15秒ごとにキープアライブを送らなければなりません。耐障害性を実現するために、エンドホストは、短いキープアライブ期間を持つべきである（SHOULD）。
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-UDP NATトラバーサルモードに合意した場合には、キープアライブバインディング適応症をSTUNています。それ以外の場合は、HIP NOTIFYパケットはキープアライブとして使用することができます。
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.
通信ホストは、彼らがESTABLISHED状態にあるときに、データおよびシグナリングのために使用することに合意したトランスポート・ロケータを使用して相互にキープアライブを送信しなければなりません。また、イニシエータは、イニシエータ間のパスに生きているNATの状態を維持し、イニシエータは15秒でレスポンダからそのI1またはI2への応答を受信しなかった場合に中継するための中継にNOTIFYパケットを送らなければなりません。
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.
塩基交換が暗黙接続テスト自体として作用するため、特定のネットワーク環境では、ICE接続性チェックは、最初の接続セットアップ待ち時間を低減するために省略することができます。これが機能するためには、イニシエータは、単にUDPは、レスポンダのアドレスに送信されたHIPと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パケットでサポートされているモードの一つとして、UDPカプセル化NATトラバーサルモードを含むかもしれません。 ResponderがHIP中継サーバーに登録されている場合、それはまた、ResponderはUDPカプセル化ESPやHIPパケットを受信することが可能である優先アドレスが含まれていR1でLOCATORパラメタを含まなければなりません。このロケータは、タイプ「トランスポートアドレス」でなければなりません、そのトラフィックタイプは「両方」でなければならない、そしてそれは、「優先ビット」セット（表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を使用したくありません。この場合、イニシエータは（すなわち、R1における好ましいロケータにあるいは全く優先ロケータがなかった場合はR1がから受け取ったアドレスにレスポンダの優先アドレスに直接NATトラバーサルモードパラメータでUDPカプセル化モードとI2を送信しますR1で）。イニシエータはI2にロケータを含むことができるが、ICEは、UDPカプセル化NATトラバーサルモードとの接続に使用されることはありませんので、彼らは、ICE候補として取られてはなりません。代わりに、R2及びI2を受信し、正常に処理されている場合、セキュリティアソシエーションを作成することができ、塩基交換が完了した後、UDPカプセル化ESPは、ホストとの間で交換することができます。セクション4.4.2で指定され、それは、イニシエータからのデータを受信した前しかし、レスポンダはイニシエータのアドレスに任意のESPを送るべきではありません。そして、[RFC5201]のセクション3.2.9及び6.9と[RFC5206]の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パケットはリレーを介して送信されてはいけませんので、レスポンダは、I2パケットを拒否し、パケットをNOTIFY NO_VALID_NAT_TRAVERSAL_MODE_PARAMETERで応答すべきである（セクション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.
レスポンダの優先アドレスに直接送信されたI2パケットの返答がない場合は、イニシエータは、HIPリレーサーバを介して他の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カプセル化せずにレスポンダで塩基交換を実行しようとするかもしれません。このような場合には、イニシエータがレスポンダに二つI1パケット、ないものとUDPカプセル化されたものを送信します。イニシエータは、他の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]の手順は、塩基交換の残りのために続いています。イニシエータはレスポンダから、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パケットはまた、HIP対応ミドルボックスに到着してもよいです。ミドルボックスは、HIPランデブーサーバであり、レスポンダが正常ランデブーサービスに登録している場合、ミドルボックスは[RFC5204]でランデブー手順に従います。
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トラバーサルは、HIPアソシエーションの寿命の間に使用されるようにするモビリティ又はマルチホーミングイベントの場合には、例えば、将来の使用のために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.
塩基交換の後、エンドホストは、HIP中継サーバを介して制御パケットを送信せず、データチャネルのための確立されたトランスポート・アドレスのペアを使用して互いに直接HIP制御パケットを送信することができます。ホストが確認応答を取得していない場合は、それがベース交換でLOCATORパラメタに記載されていた場合には、例えば、ローカルポリシーに基づいて、タイムアウト後にUPDATEまたはCLOSEパケットに、ホストは、リレーを介してパケットを再送する必要があります。
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.
制御パケットはHIP中継サーバを介して送信された場合、リレーに登録されたホストは、塩基交換のようRELAY_TOパラメータを利用しなければなりません。 HIPリレーサーバはRELAY_TOパラメータのアドレスに登録されたホストから登録されたホストとパケットを転送するHIPパケットを転送する必要があります。リレーは、それが登録されたホストにリレー制御パケットに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).
HIPリレーサーバが喜んまたはHIPパケットを中継することができない場合は、（5.10節を参照）MESSAGE_NOT_RELAYEDエラー通知とパケットの送信者に通知することができます。
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.
以下のサブセクションでは、HIP、ESP、およびICE接続性チェックパケットのためのパラメータとパケットのエンコーディングを定義します。すべての値は、ネットワークバイト順でなければなりません。
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制御パケットのフォーマット
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]、「ポート4500のためのIKEヘッダフォーマット」のセクション2.2で定義されるようにHIP制御パケットがUDPパケットにカプセル化されています。図5は、カプセル化を示しています。 UDPヘッダは、ESPパケットからHIP制御パケットを区別するために使用できる32ビットのゼロが続きます。 HIPヘッダ及びパラメータは、HIPヘッダチェックサムがゼロでなければならないことを除いて、[RFC5201]の規則に従います。 HIPヘッダチェックサムは、2つの理由のためにゼロです。まず、UDPヘッダは、すでにチェックサムが含まれています。第二に、[RFC5201]のチェックサムの定義は、チェックサムの計算にIPアドレスを含みます。 HIPの気づかないNATはIPアドレスを変更した後、HIPのチェックサムを再計算することはできません。
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.
リレーなしでHIPリレーサーバまたはResponderは、着信UDPカプセル化HIP制御パケットのUDPポート10500で聞くべきです。他のいくつかのポート番号が使用されている場合、それは潜在的なイニシエータによって知られている必要があります。
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]で定義されるようにSTUNバインディング要求を使用して行われます。このセクションでは、STUNメッセージ内のパラメータの詳細を説明します。
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ビットでSTUN短期資格情報を使用しなければなりません。 [RFC5245]のセクション7.1.1.3で定義されたユーザ名がユーザ名断片から形成されています。 32ビットのユーザ名フラグメントは小文字の16進のASCII文字を使用して表現されます。ユーザ名のサイズは（8文字）に固定されるように、先行ゼロを省略することはできません。例えば、ローカルHIT 2001である場合：15：8ebe：1aa7：42f5：b413：7237：6c0aと遠隔HITは2001：18：46fa：97c0：BA5：CD77：51：47B、ローカルユーザ名が72376c0aあろうおよびリモートユーザ名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.
STUNパスワードがディフィー・ヘルマン（DH）鍵材料から引き出されます。 HIPキーの描画[RFC5201]で定義され、[RFC5202]セクション6.5およびESPキーの描画、それに対応して第7は、ホストは、[RFC5201]、セクション6.5に従ってSTUNのための対称キーを描画しなければなりません。ホストは、HIPキーの後にSTUNキーを描き、またはESPキーの後にESPが正常に塩基交換で交渉された変換場合。両方のホストは、DH鍵材料から、128ビットの鍵を描く（32個の数字または小文字をもたらす）小文字のみを使用した16進数ASCII形式でそれを発現する、ローカルおよびピア・パスワードの両方としてそれを使用します。 [RFC5389]はホストがSTUNメッセージのメッセージの整合性のためのパスワードを使用する方法について説明します。
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].
接続性チェックは、PRIORITY属性を含まなければなりません。 [RFC5245]のセクション7.1.1.1で定義されている彼らは、USE-CANDIDATE属性を含むかもしれません。
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つのホストが同時に相互に接続を開始している場合、HIP状態マシンはそれを検出して、[RFC5201]のセクション4.4.2および6.7で説明したようにレスポンダとして大きなHITとホストを割り当てます。したがって、ICE-制御され、ICE-制御属性は、ロールの競合を解決する必要はありません。しかし、属性が異なるICEスタックとの相互運用性を確保するために、接続性チェックメッセージに追加する必要があります、そして、彼らは無事に受け取った接続性チェックでは無視することができます。
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]で定義されるようにICEを使用して作成されたHIPの関連付けのためのキープアライブは、バインディング適応症をSTUNれます。 UDPカプセル化HIPヘッダとは対照的に、UDPヘッダとSTUNヘッダとの間に非ESPマーカーは除外されます。キープアライブは、指紋STUN属性が含まれなければならないが、他のSTUN属性を含むべきではないと任意の認証メカニズムを利用すべきではありません。 STUNメッセージは、そのようなマジッククッキー値とFINGERPRINT属性として、STUNマーカーを使用して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.
ICEなしで作成されたHIPアソシエーションのキープアライブは、パケットタイプとしてNOTIFYてきたHIP制御パケットです。キープアライブパケットが任意のパラメータを含まない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パラメータの形式に類似しており、この仕様は、トラバーサルモード識別子UDPカプセル化及びICE-STUN-UDPを定義する図6に示されています。 RESERVED識別子は、将来の使用のために予約されています。将来の仕様は、より多くのトラバーサルモードを定義することもできます。
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を受け付け、残りを滴下し半年以上モードIDを含む受信されたNATトラバーサルモードパラメータを処理するために準備されなければなりません。モードIDの限られた数NAT_TRAVERSAL_MODEパラメータの最大サイズを設定します。モードは、優先順位、最も好ましいモード（S）最初になければなりません。
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、及びRELAY_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 RELAY_TO：64002長さ20ポート転送ポート番号。ゼロプレーンIPが割り当てられたプロトコルIANAを使用する場合、インターネットプロトコル番号。 UDP、IP平野のための0のため17
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
将来の使用のために予約予約済み。ゼロ送信、無視受信したアドレスのIPv6アドレスまたは「IPv4射影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.
ジェネリックLOCATORパラメータフォーマットは、[RFC5206]と同じです。しかし、ICE候補を提示すると、新しいロケータの種類が必要です。汎用及び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：LOCATORパラメータ
The individual fields in the LOCATOR parameter are described in Table 2.
LOCATORパラメータの個々のフィールドは、表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：LOCATORパラメータのフィールド
The RELAY_HMAC parameter value has the TLV type 65520. It has the same semantics as RVS_HMAC [RFC5204].
RELAY_HMACパラメータ値は、それがRVS_HMAC [RFC5204]と同じ意味を有する65520. TLVタイプを有しています。
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パラメータは、登録タイプ[RFC5203] HIPリレーサーバ登録のための値が含まれています。
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.
HIP中継サーバとエンドホストは、異なるエラー状態を通知するNOTIFYパケットを使用することができます。この文書で定義された新しい通知パケットタイプ[RFC5201]は以下の通りです。エラー通知のための通知データフィールドは拒否パケットのHIPヘッダを含むべきであり、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トラバーサルモードパラメータが欠落による塩基交換パケットを転送しない、またはイニシエータはレスポンダは、リレーまたはResponderが、このタイプのエラー通知パケットを返送して期待していなかった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.
ISはHIPパケットを中継することができたり喜んでなかったことを知らせるためにHIPリレーサーバによって使用されます。
[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カプセル化を記載しています。ワイヤ上の、HIP ESPパケットは、トランスポートモードESP異ならないので、HIP ESPパケットのカプセル化は、UDPカプセル化トランスポートモードESPと同じです。しかし、HIPによって使用されるバインドされたエンドツーエンドのトンネル（BEET）モードESPパケットに（セマンティック）の違いは、IPヘッダがBEETの完全性保護の計算に使用されていないということです。
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.
HIP基本交換の間に、それらを可能にする2つのピア交換パラメータは、[RFC5202]に記載されているようにIPsec ESPセキュリティアソシエーション（SA）のペアを定義します。 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]で定義されています。 HIP 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.
ロケータは、将来的にはHIP-意識ミドルボックスでの検査の賛成で、プレーンテキスト形式です。現在のドキュメントには、プライバシー上の理由は、ミドルボックスにそれらを開示することを避けるためにのために、それは有益であり得るにもかかわらず、ロケータの暗号化されたバージョンを指定していません。
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.
エンドユーザーがお互いにすべてのロケータを明らかにしたくないかもしれないということも可能です。それは塩基交換中にそのピアにすべてのロケータを明らかにする場合、例えば、マルチホーミングエンドホストの物理的な位置を追跡することは容易になることができます。また、ホストアドレスを明らかにすることは、すべての企業環境では許可されない場合があり地元のトポロジーについての情報を公開します。これらの二つの理由から、エンドホストは、そのLOCATORパラメータから特定のホストアドレスを除外することができます。ホストが同じNATの背後に配置されている場合しかし、そのような行動は、非最適パスを作成します。特に、これはNATの外側アドレスを介してバック自体にプライベートアドレス領域からのルーティングをサポートしていませんレガシーNATとの問題である可能性があります。このシナリオは、ヘアピンの問題[RFC5128]と呼ぶことにします。こうしたレガシーNATを使用すると、左の唯一のオプションは、TURNサーバーから中継されたトランスポート・アドレスを使用することです。
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.
HIPの中継サーバとTURNリレーの使用は、プライバシーの目的のためにも役立ちます。例えば、プライバシーの懸念レスポンダはイニシエータにのみそのHIPリレーサーバと中継された候補を明らかにすることができます。この同じメカニズムは、Responderがそのリレーが原因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.
HIPリレーが複数のリレーのクライアントにサービスを提供し、日和見モードをサポートしているときHIP中継サーバーは、リレークライアントごとに一つのアドレスを持っている必要があります。それ以外の場合は、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.
特定のシナリオでは、攻撃者、又は二攻撃者は、元のイニシエータとレスポンダになりすましによるHIP中継サーバを介して以前の塩基交換を再生することが可能です。攻撃は、攻撃されたホスト（複数可）の秘密鍵（複数可）を侵害する攻撃（複数可）を必要としません。しかし、成功するためにこの攻撃のために、ResponderはHIP中継サーバーから切断する必要があります。
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つの方法は、[HIP-MIDDLE]に記載されているようにR1及びI2パケットにECHO_REQUEST_Mパラメータを追加し、対応するECHO_RESPONSE_Mパラメータが存在しない場合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.
別のNATの背後にある2つのホストが同じプライベートIPアドレスを持っており、公共のインターネットで同じレスポンダに通信を開始する際に、[RFC3948]のセクション5.1は、標準のIPトンネルモードでのUDPカプセル化のためのセキュリティ上の問題について説明します。セキュリティアソシエーションが同じ内部IPアドレスに基づいているため、Responderは、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).
この文書は、新しいHIPパラメータの新しいHIPパラメータタイプ値を割り当てることによって、HIPパラメータ型[RFC5201]のためのIANAレジストリを更新：RELAY_FROM、RELAY_TO、及びREG_FROM（セクション5.6で定義される）、RELAY_HMAC（セクション5.8で定義される）、TRANSACTION_PACINGは（定義します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).
（セクション5.9で定義される）RELAY_UDP_HIP：この文書は、サービスを中継するHIP中継サーバに登録することができHIP登録拡張[RFC5203]のための追加の登録タイプを定義します。
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は5.10でパケットタイプ[RFC5201]を通知定義します。
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パラメータは、IANAが作成され、「ホストアイデンティティプロトコル（HIP）パラメータ」の下の「HIP NATトラバーサルモード」と題する新しいサブレジストリを維持しているために異なるモード、16ビットの符号なし整数フィールドを持っています。 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は、両方のは、この文書に大きな貢献をしてきたマルセロBagnuloとフィリップ・マシューズが、含ま設計チームの製品です。
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.
ICEの優れた作品のためのジョナサン・ローゼンバーグとMMUSIC WGの人々の残りの部分に感謝します。また、著者はアンドレイGurtov、サイモンSchuetz、マーティンStiemerling、ラースEggertの、ヴィヴィアン・シュミット、そして彼らの貢献のためのAbhinav PathakとトビアスHeerさん、テームKoponen、ジョンMattila、ジェフリーM. Ahrenholz、クリスチャンSlavov、ヤンネLindqvistに感謝したいと思いますこのドキュメントの彼らのコメントについてペッカNikander、ラウリSilvennoinen、ユッカYlitalo、ユハわら、ヨアキムKoskela、Samu Varjonen、ダン・ウィング、及びヤニ・コルピ墓。
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こむには、情報技術のためのヘルシンキ大学（HIIT）でネットワークの研究グループで働いています。仕事はInfraHIP IおよびIIのプロジェクトで技術庁、テリア-Sonera、エリサ、ノキア、フィンランド国防軍、エリクソンとBirdstepのによって資金を供給されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]モスコウィッツ、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]モスコウィッツ、R.、Nikander、P.、Jokela、P.、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、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.、モスコウィッツ、R.、およびP. Nikander、RFC 5202、2008年4月 "ホスト識別プロトコル（HIP）とカプセル化セキュリティペイロード（ESP）トランスポートフォーマットを使用します"。
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 5203, April 2008.
[RFC5203] Laganier、J.、Koponen、T.、およびL.エッゲルト、 "ホストアイデンティティプロトコル（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.エッゲルト、 "ホストアイデンティティプロトコル（HIP）ランデブー拡張"、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.、ヘンダーソン、T.、フォークト、C.、およびJ. Arkko、 "ホストアイデンティティプロトコルとエンドホストモビリティとマルチホーミング"、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]ローゼンバーグ、J.、 "インタラクティブ接続確立（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]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "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]ローゼンバーグ、J.、マーイ、R.、およびP.マシューズ、 "NAT（TURN）の周りトラバーサル使用リレー：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.こむ、 "HIPのMiddleboxesのエンドホスト認証"、進歩、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]ローゼンバーグ、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.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "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.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、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.、フォード、B.、およびD.ケーゲル、2008年3月、RFC 5128 "ネットワーク全体のピア・ツー・ピア（P2P）通信状態が翻訳器（NAT）のアドレス"。
[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.エッゲルト、 "NATおよびホスト識別プロトコル（HIP）コミュニケーションのファイアウォール越えの問題"、RFC 5207、2008年4月。
Appendix A. Selecting a Value for Check Pacing
チェックペーシングの値を選択付録A.
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）を推定し、2つだけ接続性チェックメッセージは、すべてのRTTに送信されるように、最小のTa値を設定することをお勧めします。
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を推定する一つの方法は、それが完了するために、HIPリレーサーバ登録交換にかかる時間を使用することです。これは、登録ホストのアクセスリンクのRTTの推定値を与えるだろう。また、I1 / R1交換はRTTを推定するために使用することができますが、R1は、ネットワーク内にキャッシュすることができ、または中継サービスは、特に遅延を増やすことができるので、それが推奨されていません。
Appendix B. Base Exchange through a Rendezvous Server
ランデブーServerを介し付録B.ベース交換
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からの応答者の情報を検索するとき、それはランデブーサーバ（RVS）レコード[RFC5204]を発見している可能性があります。イニシエータは、この文書で説明するNATトラバーサルメソッドを使用する場合は、この場合には、それはランデブーサーバにHIPトラフィックを転送するために、独自のHIP中継サーバーを使用するかもしれません。イニシエータは、レスポンダのRVSサーバーに転送されますそのHIP中継サーバーを使用して、I1パケットを送信します。 RVSは、UDPカプセル化塩基交換パケットをサポートしていないので、この場合には、RELAY_TOパラメータのプロトコルフィールドの値は、IPでなければなりません。レスポンダは、イニシエータのHIPリレーサーバに直接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アドレスレコードであるレコードを区別することができず、レスポンダのアドレスレコードは、（例えば、HIP拡張をサポートしていませんでしたDNSサーバがあれば）、イニシエータは、最初にHIPを使用せずに、直接レスポンダに連絡してみてくださいリレーサーバ。アドレスのいずれも到達可能でない場合は、上記のように、独自のHIP中継サーバーを使用してそれらを試してみるかもしれません。
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/
+358503841531ファックス：+35896949768 Eメール：miika@iki.fi URI：http://www.hiit.fi/情報技術Metsanneidonkuja 4エスポーフィンランドの携帯電話のためのMiikaこむヘルシンキ研究所
Thomas Henderson The Boeing Company P.O. Box 3707 Seattle, WA USA EMail: thomas.r.henderson@boeing.com
トーマス・ヘンダーソンザ・ボーイング社の私書箱ボックス3707シアトル、WA USA Eメール：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/
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポーフィンランド電話番号：+358（50）4871445 Eメール：Hannes.Tschofenig@gmx.net URI：http://www.tschofenig.priv.at/
Jan Melen Ericsson Research Nomadiclab Hirsalantie 11 02420 Jorvas Finland Phone: +358 9 2991 EMail: jan.melen@ericsson.com
ジャンメレンエリクソン研究Nomadiclab Hirsalantie 11 02420 Jorvasフィンランド電話番号：+358 9 2991 Eメール：jan.melen@ericsson.com
Ari Keranen (editor) Ericsson Research Nomadiclab Hirsalantie 11 02420 Jorvas Finland Phone: +358 9 2991 EMail: ari.keranen@ericsson.com
アリKeranen（エディタ）エリクソン研究Nomadiclab Hirsalantie 11 02420 Jorvasフィンランド電話番号：+358 9 2991 Eメール：ari.keranen@ericsson.com