[要約] RFC 9028は、ホスト識別プロトコル（HIP）のためのネイティブNATトラバーサルモードを定義しています。この文書の目的は、NATを越えてHIP通信を可能にする手法を提供することです。主に、プライベートネットワーク間やインターネット上でのセキュアなデバイス間通信に利用されます。
Internet Engineering Task Force (IETF) A. Keränen
Request for Comments: 9028 J. Melén
Category: Experimental M. Komu, Ed.
ISSN: 2070-1721 Ericsson
July 2021
Native NAT Traversal Mode for the Host Identity Protocol
ホストIDプロトコルのネイティブNATトラバーサルモード
Abstract
概要
This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages instead of ICE for all NAT traversal procedures due to the kernel-space dependencies of HIP.
このドキュメントは、ホストIDプロトコル（HIP）の新しいネットワークアドレストランスレータ（NAT）トラバーサルモードを指定します。新しいモードは、Interactive Connectivity Instracent（ICE）方法論とUDPトラフィックのUDPカプセル化に基づいています。以前に指定されたモードとの主な違いは、股関節のカーネル空間依存性のために、すべてのNATトラバーサル手順について氷の代わりにHIPメッセージを使用することです。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットコミュニティの実験的プロトコルを定義しています。この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9028.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9028で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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ドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Overview of Operation
4. Protocol Description
4.1. Relay Registration
4.2. Transport Address Candidate Gathering at the Relay Client
4.3. NAT Traversal Mode Negotiation
4.4. Connectivity Check Pacing Negotiation
4.5. Base Exchange via Control Relay Server
4.6. Connectivity Checks
4.6.1. Connectivity Check Procedure
4.6.2. Rules for Connectivity Checks
4.6.3. Rules for Concluding Connectivity Checks
4.7. NAT Traversal Optimizations
4.7.1. Minimal NAT Traversal Support
4.7.2. Base Exchange without Connectivity Checks
4.7.3. Initiating a Base Exchange Both with and without UDP
Encapsulation
4.8. Sending Control Packets after the Base Exchange
4.9. Mobility Handover Procedure
4.10. NAT Keepalives
4.11. Closing Procedure
4.12. Relaying Considerations
4.12.1. Forwarding Rules and Permissions
4.12.2. HIP Data Relay and Relaying of Control Packets
4.12.3. Handling Conflicting SPI Values
5. Packet Formats
5.1. HIP Control Packets
5.2. Connectivity Checks
5.3. Keepalives
5.4. NAT Traversal Mode Parameter
5.5. Connectivity Check Transaction Pacing Parameter
5.6. Relay and Registration Parameters
5.7. LOCATOR_SET Parameter
5.8. RELAY_HMAC Parameter
5.9. Registration Types
5.10. Notify Packet Types
5.11. ESP Data Packets
5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters
5.13. PEER_PERMISSION Parameter
5.14. HIP Connectivity Check Packets
5.15. NOMINATE Parameter
6. IAB Considerations
7. Security Considerations
7.1. Privacy Considerations
7.2. Opportunistic Mode
7.3. Base Exchange Replay Protection for Control Relay Server
7.4. Demultiplexing Different HIP Associations
7.5. Reuse of Ports at the Data Relay Server
7.6. Amplification Attacks
7.7. Attacks against Connectivity Checks and Candidate Gathering
7.8. Cross-Protocol Attacks
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Selecting a Value for Check Pacing
Appendix B. Differences with Respect to ICE
Appendix C. Differences to Base Exchange and UPDATE Procedures
Appendix D. Multihoming Considerations
Appendix E. DNS Considerations
Acknowledgments
Contributors
Authors' Addresses
The Host Identity Protocol (HIP) [RFC7401] is specified to run directly on top of IPv4 or IPv6. However, many middleboxes found in the Internet, such as NATs and firewalls, often allow only UDP or TCP traffic to pass [RFC5207]. Also, NATs usually require the host behind a NAT to create a forwarding state in the NAT before other hosts outside of the NAT can contact the host behind the NAT. To overcome this problem, different methods, commonly referred to as NAT traversal techniques, have been developed.
ホストIDプロトコル（HIP）[RFC7401]は、IPv4またはIPv6の上に直接実行するように指定されています。ただし、NATやファイアウォールなどのインターネットで見つかった多くのミドルボックスは、UDPまたはTCPトラフィックのみが[RFC5207]に渡すことがよくあります。また、NATSの背後にあるホストは、NATの外側の他のホストがNATの背後にあるホストに連絡できる前に、NATの背後にあるホストを必要とします。この問題を克服するために、一般にNATトラバーサル技術と呼ばれるさまざまな方法が開発されてきた。
As one solution, the HIP experiment report [RFC6538] mentions Teredo-based NAT traversal for HIP and related Encapsulating Security Payload (ESP) traffic (with double tunneling overhead). Another solution is specified in [RFC5770], which will be referred to as "Legacy ICE-HIP" in this document. The experimental Legacy ICE-HIP specification combines the Interactive Connectivity Establishment (ICE) protocol (originally [RFC5245]) with HIP so that basically, ICE is responsible for NAT traversal and connectivity testing, while HIP is responsible for end-host authentication and IPsec key management. The resulting protocol uses HIP, Session Traversal Utilities for NAT (STUN), and ESP messages tunneled over a single UDP flow. The benefit of using ICE and its STUN / Traversal Using Relays around NAT (TURN) messaging formats is that one can reuse the NAT traversal infrastructure already available in the Internet, such as STUN and TURN servers. Also, some middleboxes may be STUN aware and may be able to do something "smart" when they see STUN being used for NAT traversal.
1つの解決策として、HIP実験報告書[RFC6538]は、HIPおよび関連するカプセル化セキュリティペイロード（ESP）トラフィックのためのTeredoベースのNATトラバース（Double Tunnelingオーバーヘッド）を指す。この文書の「レガシーアイスヒップ」と呼ばれる[RFC5770]に別の解決策が指定されています。実験レガシーアイスヒップ仕様は、基本的に、ICEがNATトラバーサルと接続性テストを担当しているように、股関節を介してインタラクティブ接続確立（ICE）プロトコル（RFC5245]）を組み合わせています。管理。結果のプロトコルは、NAT（STUN）、およびESPメッセージのためのHIP、Session Traversalユーティリティを使用し、ESPメッセージは単一のUDPフローを介してトンネリングされます。 NAT（ターン）メッセージングフォーマット周辺のリレーを使用してICEとそのSTUN /トラバースを使用することの利点は、STUNサーバーなどのインターネットですでに利用可能なNATトラバーサルインフラストラクチャを再利用できることです。また、いくつかのミドルボックスはSTUNを意識している可能性があり、STUNがNATトラバーサルに使用されているのを見たときに「スマート」をすることができるかもしれません。
HIP poses a unique challenge to using standard ICE, not only due to kernel-space dependencies of HIP, but also due to its close integration with kernel-space IPsec; and, while [RFC5770] provides a technically workable path, HIP incurs unacceptable performance drawbacks for kernel-space implementations. Also, implementing and integrating a full ICE/STUN/TURN protocol stack as specified in Legacy ICE-HIP results in a considerable amount of effort and code, which could be avoided by reusing and extending HIP messages and state machines for the same purpose. Thus, this document specifies an alternative NAT traversal mode referred to as "Native ICE-HIP" that employs the HIP messaging format instead of STUN or TURN for the connectivity checks, keepalives, and data relaying. Native ICE-HIP also specifies how mobility management works in the context of NAT traversal, which is missing from the Legacy ICE-HIP specification. The native specification is also based on HIPv2, whereas the legacy specification is based on HIPv1. The differences to Legacy ICE-HIP are further elaborated in Appendix B.
HIPは、股関節のカーネル空間依存性だけでなく、カーネル空間IPsecとの密接な統合のために、標準氷を使用するためのユニークな課題をもたらします。そして、[RFC5770]は技術的に作動可能な経路を提供しながら、HIPはカーネル空間実装のための許容できない性能欠点を招きます。また、レガシーアイスヒップに指定されているフルアイス/スタン/ターンプロトコルスタックを実装して統合すると、かなりの量の努力とコードが得られます。したがって、このドキュメントは、STUNの代わりにHIPメッセージングフォーマットを使用する代替のNATトラバーサルモードを指定し、接続性チェック、キープアライブ、およびデータ中継のためにターンする。ネイティブアイスヒップはまた、Legacy Ice-HIP仕様から欠落しているNATトラバーサルのコンテキストでどのように機能するかを指定します。ネイティブ仕様はHIPv2に基づいていますが、レガシー仕様はHIPv1に基づいています。従来のアイスヒップとの違いは、付録Bでさらに詳しく説明されています。
Similar to Legacy ICE-HIP, this specification builds on the HIP registration extensions [RFC8003] and the base exchange procedure [RFC7401] and its closing procedures; therefore, the reader is recommended to get familiar with the relevant specifications. In a nutshell, the registration extensions allow a HIP Initiator (usually a "client" host) to ask for specific services from a HIP Responder (usually a "server" host). The registration parameters are included in a base exchange, which is essentially a four-way Diffie-Hellman key exchange authenticated using the public keys of the end hosts. When the hosts negotiate support for ESP [RFC7402] during the base exchange, they can deliver ESP-protected application payload to each other. When either of the hosts moves and changes its IP address, the two hosts re-establish connectivity using the mobility extensions [RFC8046]. The reader is also recommended to get familiar with the mobility extensions; basically, the process is a three-way procedure where the mobile host first announces its new location to the peer; then, the peer tests for connectivity (the so-called return routability check); and then, the mobile host must respond to the announcement in order to activate its new location. This specification builds on the mobility procedures, but modifies them to be compatible with ICE. The differences in the mobility extensions are specified in Appendix C. It is worth noting that multihoming support as specified in [RFC8047] is left for further study.
レガシーアイスヒップと同様に、この仕様は、HIP登録拡張[RFC8003]と基本交換手順[RFC7401]とその閉鎖手順について説明します。したがって、リーダーは関連する仕様に精通していることをお勧めします。一言では、登録拡張機能により、HIPイニシエータ（通常はクライアントの "ホスト）がHIPレスポンダ（通常は"サーバー "ホスト）から特定のサービスを要求できます。登録パラメータは基本交換に含まれており、これは本質的にエンドホストの公開鍵を使用して認証された4方向Diffie-Hellman鍵交換である。ホストが基本交換中にESP [RFC7402]のサポートを交渉すると、ESP保護アプリケーションペイロードを互いに配信できます。いずれかのホストがそのIPアドレスを移動して変更すると、2つのホストは、Mobility Extensions [RFC8046]を使用して接続を再確立します。読者はモビリティの拡張に精通していることも推奨されます。基本的に、このプロセスは、モバイルホストが最初にピアへの新しい場所を発表する3方向の手順です。その後、ピアテスト（いわゆるリターンルーテーブルチェック）。そして、その新しい場所を有効にするために、モバイルホストはアナウンスに応答する必要があります。この仕様はモビリティ手順に基づいていますが、iceと互換性があるように変更します。モビリティ拡張機能の違いは付録Cで指定されています。
This specification builds heavily on the ICE methodology, so it is recommended that the reader is familiar with the ICE specification [RFC8445] (especially the overview). However, Native ICE-HIP does not implement all the features in ICE; hence, the different features of ICE are cross referenced using [RFC2119] terminology for clarity. Appendix B explains the differences to ICE, and it is recommended that the reader read this section in addition to the ICE specification.
この仕様はICE方法論に大きく構築されているので、読者はICE仕様[RFC8445]（特に概要）に精通していることをお勧めします。ただし、ネイティブのアイスヒップは氷のすべての機能を実装していません。したがって、氷のさまざまな機能は、明確にするために[RFC2119]の用語を使用して交差参照されています。付録Bの違いについて説明し、ICE仕様に加えてリーダーがこのセクションを読んでいることをお勧めします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document borrows terminology from [RFC5770], [RFC7401], [RFC8046], [RFC9063], [RFC8445], and [RFC8489]. The following terms recur in the text:
この文書は[RFC5770]、[RFC7401]、[RFC8046]、[RFC9063]、[RFC8445]、[RFC8489]から用語を借りています。次の用語はテキストに復旧します。
ICE: Interactive Connectivity Establishment (ICE) protocol as specified in [RFC8445].
ICE：[RFC8445]で指定されているICEACTIVE接続確立（ICE）プロトコル。
Legacy ICE-HIP: Refers to the "Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators" as specified in [RFC5770]. The protocol specified in this document offers an alternative to Legacy ICE-HIP.
Legacy Ice-Hip：[RFC5770]で指定されているように、「ネットワークアドレストランスレータのトラバースの基本ホストIDプロトコル（HIP）拡張」を指します。このドキュメントで指定されているプロトコルは、レガシーアイスヒップに代わるものを提供します。
Native ICE-HIP: The protocol specified in this document (Native NAT Traversal Mode for HIP).
ネイティブアイスヒップ：この文書で指定されたプロトコル（HIPのネイティブNATトラバーサルモード）。
Initiator: The host that initiates the base exchange using I1 message [RFC7401].
イニシエータ：I1メッセージ[RFC7401]を使用して基本交換を開始するホスト。
Responder: The host that receives the I1 packet from the Initiator [RFC7401].
Responder：イニシエータ[RFC7401]からI1パケットを受信したホスト。
Control Relay Server A registrar host that forwards any kind of HIP control plane packets between the Initiator and the Responder. This host is critical because it relays the locators between the Initiator and the Responder so that they can try to establish a direct communication path with each other. This host is used to replace HIP Rendezvous Servers [RFC8004] for hosts operating in private address realms. In the Legacy ICE-HIP specification [RFC5770], this host is denoted as "HIP Relay Server".
Control Relay Serverイニシエータとレスポンダ間の任意の種類のHIP制御プレーンパケットを転送するレジストラホスト。このホストは、イニシエータとレスポンダ間のロケータをリレーするため、互いに直接通信経路を確立しようとすることができるため、このホストは重要です。このホストは、プライベートアドレスレルムで動作するホストのHIP Rendezvousサーバー[RFC8004]を置き換えるために使用されます。Legacy Ice-Hip Specification [RFC5770]では、このホストは「HIPリレーサーバー」と表記されています。
Control Relay Client: A requester host that registers to a Control Relay Server requesting it to forward control plane traffic (i.e., HIP control messages). In the Legacy ICE-HIP specification [RFC5770], this is denoted as "HIP Relay Client".
Control Relayクライアント：コントロールプレーントラフィックを転送するように要求するコントロールリレーサーバーに登録するリクエスタホスト（すなわち、HIP制御メッセージ）。レガシーアイスヒップ仕様[RFC5770]では、これは「HIPリレークライアント」と表記されています。
Data Relay Server: A new entity introduced in this document; a registrar host that forwards HIP related data plane packets, such as Encapsulating Security Payload (ESP) [RFC7402], between two hosts. This host implements similar functionality as TURN servers.
データリレーサーバー：この文書で導入された新しいエンティティ。2つのホスト間で、セキュリティペイロード（ESP）[RFC7402]をカプセル化するなど、HIP関連データプレーンパケットを転送するレジストラホスト。このホストはターンサーバーと同様の機能を実装しています。
Data Relay Client: A requester host that registers to a Data Relay Server requesting it to forward data plane traffic (e.g. ESP traffic). This functionality is a new and introduced in this document.
Data Relayクライアント：データプレーントラフィック（例えばESPトラフィック）を転送するように要求するデータリレーサーバーに登録する要求者ホスト。この機能はこの文書で新しくて導入されています。
Locator: As defined in [RFC8046]: "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."
ロケータ：[RFC8046]で定義されているように、パケットがネットワークを介してルーティングされ、エンドホストによって逆多重化された方法を制御する名前。IPv6アドレスやエンドツーエンドの識別子などの従来のネットワークアドレスの連結を含めることができます。ESP SPIなど、逆多重化コンテキストとしてトランスポートポート番号またはIPv6フローラベルを含めることも、単にネットワークアドレスになる場合があります。」
LOCATOR_SET (written in capital letters): Denotes a HIP control packet parameter that bundles multiple locators together [RFC8046].
locator_set（大文字で書かれています）：複数のロケーターをまとめてまとめた腰制御パケットパラメータを示します[RFC8046]。
HIP offer: Before two end hosts can establish a communication channel using the NAT traversal procedures defined in this document, they need to exchange their locators (i.e., candidates) with each other. In ICE, this procedure is called Candidate Exchange; it does not specify how the candidates are exchanged, but Session Description Protocol (SDP) "offer/answer" is mentioned as an example. In contrast, the Candidate Exchange in HIP is the base exchange itself or a subsequent UPDATE procedure occurring after a handover. Following [RFC5770] and SDP-related naming conventions [RFC3264], "HIP offer" is the Initiator's LOCATOR_SET parameter in a HIP I2 or in an UPDATE control packet.
ヒップオファー：2つのエンドホストがこの文書で定義されているNATトラバーサル手順を使用して通信チャネルを確立する前に、それらはロケータ（すなわち候補者）を互いに交換する必要がある。氷では、この手順は候補交換と呼ばれます。候補の交換方法は指定されていませんが、セッション記述プロトコル（SDP）「オファー/アンサー」が例として挙げられます。対照的に、HIPの候補交換は、引渡された後に発生する基本交換自体またはその後の更新手順である。[RFC5770]とSDP関連の命名規則[RFC3264]、「HIPオファー」は、HIP I2または更新制御パケット内のイニシエータのLOCATOR_SETパラメータです。
HIP answer: The Responder's LOCATOR_SET parameter in a HIP R2 or UPDATE control packet. The HIP answer corresponds to the SDP answer parameter [RFC3264] but is HIP specific. Please refer also to the longer description of the "HIP offer" term above.
HIP回答：HIP R2または更新制御パケットのResponderのLocator_setパラメータ。HIP回答はSDP回答パラメータ[RFC3264]に対応していますが、HIP固有です。上記の「HIPオファー」という用語の長い説明も参照してください。
HIP connectivity checks: In order to obtain a direct end-to-end communication path (without employing a Data Relay Server), two communicating HIP hosts try to "punch holes" through their NAT boxes using this mechanism. It is similar to the ICE connectivity checks but implemented using HIP return routability checks.
HIP接続性チェック：（データ中継サーバを使用せずに）直接エンドツーエンドの通信経路を取得するために、このメカニズムを使用して2つの通信HIPホストがそれらのNATボックスを介して「穴あけ」を試みます。それはICE接続チェックと似ていますが、HIPリターンルートテーブルチェックを使用して実装されています。
Controlling host: The controlling host [RFC8445] is always the Initiator in the context of this specification. It nominates the candidate pair to be used with the controlled host.
ホストの制御：制御ホスト[RFC8445]は常にこの仕様のコンテキストでイニシエータです。それは制御されたホストと共に使用される候補ペアを推薦します。
Controlled host: The controlled host [RFC8445] is always the Responder in the context of this specification. It waits for the controlling host to nominate an address candidate pair.
制御ホスト：制御ホスト[RFC8445]は常にこの仕様の文脈ではレスポンダです。制御ホストがアドレス候補ペアを指名するのを待ちます。
Checklist: A list of address candidate pairs that need to be tested for connectivity (same as in [RFC8445]).
チェックリスト：接続性をテストする必要があるアドレス候補ペアのリスト（[RFC8445]と同じ）。
Transport address: Transport-layer port and the corresponding IPv4/v6 address (same as in [RFC8445]).
トランスポートアドレス：トランスポート層ポートと対応するIPv4 / v6アドレス（[RFC8445]と同じ）。
Candidate: A transport address that is a potential point of contact for receiving data (same as in [RFC8445]).
候補：データを受信するための潜在的な接点であるトランスポートアドレス（[RFC8445]と同じ）。
Host candidate: A candidate obtained by binding to a specific port from an IP address on the host (same as in [RFC8445]).
ホスト候補：ホスト上のIPアドレスから特定のポートにバインドすることによって得られた候補（[RFC8445]と同じ）。
Server-reflexive candidate: A translated transport address of a host as observed by a Control or Data Relay Server (same as in [RFC8445]).
サーバー再帰候補：コントロールまたはデータ中継サーバーによって観測されたホストの翻訳されたトランスポートアドレス（[RFC8445]と同じ）。
Peer-reflexive candidate: A translated transport address of a host as observed by its peer (same as in [RFC8445]).
ピア再帰候補：そのピアによって観察されたホストの翻訳された輸送アドレス（[RFC8445]と同じ）。
Relayed candidate: A transport address that exists on a Data Relay Server. Packets that arrive at this address are relayed towards the Data Relay Client. The concept is the same as in [RFC8445], but a Data Relay Server is used instead of a TURN server.
中継候補：データ中継サーバに存在するトランスポートアドレス。このアドレスに到着するパケットは、データリレークライアントに向かって中継されています。概念は[RFC8445]と同じですが、ターンサーバーの代わりにデータ中継サーバーが使用されます。
Permission: In the context of Data Relay Server, permission refers to a concept similar to TURN's [RFC8656] channels. Before a host can use a relayed candidate to forward traffic through a Data Relay Server, the host must activate the relayed candidate with a specific peer host.
権限：データ中継サーバーのコンテキストでは、許可は、ターンの[RFC8656]チャネルと同様の概念を指します。ホストが中継候補を使用する前に、データリレーサーバーを介してトラフィックを転送することができる前に、ホストは特定のピアホストを使用して中継候補をアクティブにする必要があります。
Base: Similar to that described in [RFC8445], the base of a candidate is the local source address a host uses to send packets for the associated candidate. For example, the base of a server-reflexive address is the local address the host used for registering itself to the associated Control or Data Relay Server. The base of a host candidate is equal to the host candidate itself.
基本：[RFC8445]で説明されているものと同様に、候補の基部は、関連する候補のためにホストが送信するためにホストが使用するローカルソースアドレスです。たとえば、サーバーリフレクサアドレスのベースは、ローカルアドレスです。ローカルアドレスは、それ自身を関連付けられているコントロールまたはデータリレーサーバーに登録するために使用されるホストです。ホスト候補の基部はホスト候補自体に等しい。
+--------------+
| Control |
+--------+ | Relay Server | +--------+
| Data | +----+-----+---+ | Data |
| Relay | / \ | Relay |
| 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, at least the Responder must be registered with a Control Relay Server reachable on the public Internet. The Responder may have also registered to a Data Relay Server that can forward the data plane in case NAT traversal fails. While, strictly speaking, the Initiator does not need a Data Relay Server, it may act in the other role with other hosts; connectivity with the Data Relay Server of the Responder may fail, so the Initiator may also need to register to a Control and/or Data Relay Server. It is worth noting that a Control and Data Relay does not forge the source address of a passing packet but always translates the source address and source port of a packet to be forwarded (to its own).
図1に示す構成例では、イニシエータとレスポンダの両方が1つ以上のNATSの後ろにあり、両方のプライベートネットワークがパブリックインターネットに接続されています。NATの後ろから連絡するには、少なくともレスポンダを公衆インターネット上で到達可能な制御リレーサーバーに登録する必要があります。レスポンダは、NATトラバーサルが失敗した場合にデータプレーンを転送することができるデータ中継サーバにも登録されていてもよい。厳密に言えば、イニシエータはデータ中継サーバを必要としないが、他のホストと他の役割に機能する可能性があります。レスポンダのデータリレーサーバーとの接続は失敗する可能性があるため、イニシエータはコントロールやデータリレーサーバーに登録する必要があります。コントロールとデータリレーが渡されたパケットの送信元アドレスを偽造しないことは注目に値しますが、常に転送されるパケットの送信元アドレスと送信元ポートを（独自に）変換します。
We assume, as a starting point, that the Initiator knows both the Responder's Host Identity Tag (HIT) and the address(es) of the Responder's Control Relay Server(s) (how the Initiator learns of the Responder's Control Relay Server is outside of the scope of this document, but it may be learned through DNS or another name service). The first steps are for both the Initiator and Responder to register with a Control Relay Server (need not be the same one) and gather a set of address candidates. The hosts use either Control Relay Servers or Data Relay 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 Control Relay Server. As part of the base exchange, each HIP host learns of the peer's candidate addresses through the HIP offer/answer procedure embedded in the base exchange.
開始時点として、イニシエータはレスポンダのホストIDタグ（HIT）とレスポンダの制御リレーサーバのアドレス（ES）の両方を知っていると仮定します（レスポンダの制御リレーサーバーのイニシエータが習得する方法の外部この文書の範囲ですが、DNSまたは別のネームサービスを通じて学習することもできます）。最初のステップは、イニシエータとレスポンダの両方が制御リレーサーバーに登録し（同じ1つだけではない）、一連のアドレス候補を収集します。ホストは、候補者を集めるための制御中継サーバまたはデータ中継サーバを使用します。次に、HIP基地交換は、HIP制御パケットをUDPデータグラムにカプセル化し、レスポンダの制御リレーサーバを介して送信することによって実行される。基本交換の一部として、各HIPホストは、基本交換に埋め込まれたHIPオファー/アンサープロシージャを通じてピアの候補アドレスを学習します。
Once the base exchange is completed, two HIP hosts have established a working communication session (for signaling) via a Control Relay Server, but the hosts still have to find a better path, preferably without a Data Relay Server, for the ESP data flow. For this, 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 established a UDP-based tunnel that traverses both NATs with the data flowing directly from NAT to NAT or via a Data Relay Server. At this point, the HIP signaling can also be sent over the same address/port pair, and is demultiplexed (or, in other words, separated) from IPsec as described in the UDP encapsulation standard for IPsec [RFC3948]. Finally, the two hosts send NAT keepalives as needed in order keep their UDP-tunnel state active in the associated NAT boxes.
基本交換が完了すると、2つのHIPホストは制御中継サーバを介して（シグナリング用）の作業通信セッションを確立したが、HOSTSは依然としてESPデータフローについては、データ中継サーバがなくてもよい。このために、接続対応の対応の対が発見されるまで接続チェックが実行されます。プロシージャの最後に、成功した場合、ホストはNATからNATへの直接またはデータリレーサーバーを介して両方のNATを横断するUDPベースのトンネルを確立しました。この時点で、HIPシグナリングは同じアドレス/ポートペアを介して送信することもでき、IPsec [RFC3948]のUDPカプセル化規格で説明されているように、IPsecから逆多重化されています（または、別言では別の）。最後に、2つのホストは、必要に応じてNATキープアライブを送信します。これは、UDP-Tunnel Stateが関連付けられている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 HIP 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 HIP connectivity checks or UDP encapsulation of ESP are needed.
どちらのホストのいずれかがNATの背後にあることを知っている場合、ホストはベース交換中にHIP接続チェックを使用しない異なるモードのNATトラバーサルをネゴシエートできますが、HIPとESPのUDPカプセル化だけです。また、イニシエータは、UDPカプセル化の有無にかかわらず、基本交換を同時に試してみることも可能である。UDPカプセル化なしの基本交換が成功した場合、ESPのHIP接続チェックまたはUDPカプセル化は必要ありません。
This section describes the normative behavior of the "Native ICE-HIP" protocol extension. Most of the procedures are similar to what is defined in [RFC5770] but with different, or additional, parameter types and values. In addition, a new type of relaying server, Data Relay Server, is specified. Also, it should be noted that HIP version 2 [RFC7401] MUST be used instead of HIPv1 with this NAT traversal mode.
このセクションでは、「ネイティブアイスヒップ」プロトコル拡張の規範的な動作について説明します。ほとんどの手順は、[RFC5770]で定義されているものと似ていますが、異なる、または追加のパラメータタイプと値があります。さらに、新しいタイプの中継サーバー、データリレーサーバーが指定されています。また、このNATトラバーサルモードでHIPv1の代わりにHIPバージョン2 [RFC7401]を使用する必要があります。
In order for two hosts to communicate over NATed environments, they need a reliable way to exchange information. To achieve this, "HIP Relay Server" is defined in [RFC5770]. It supports the relaying of HIP control plane traffic over UDP in NATed environments and forwards HIP control packets between the Initiator and the Responder. In this document, the HIP Relay Server is denoted as "Control Relay Server" for better alignment with the rest of the terminology. The registration to the Control Relay Server can be achieved using the RELAY_UDP_HIP parameter as explained later in this section.
2人のホストが国際環境で通信するためには、情報を交換するための信頼できる方法が必要です。これを達成するために、[RFC5770]で「HIPリレーサーバー」が定義されています。それは、Nated環境でのUDPよりも股関節制御プレーントラフィックの中継をサポートし、イニシエータとレスポンダ間のHIP制御パケットを転送します。この文書では、HIP中継サーバは、残りの用語との配置を良くするために「制御中継サーバ」として表される。このセクションで後述するように、Relay_UDP_HIPパラメータを使用して、制御リレーサーバへの登録を実現できます。
To also guarantee data plane delivery over varying types of NAT devices, a host MAY also register for UDP-encapsulated ESP relaying using Registration Type RELAY_UDP_ESP (value 3). This service may be coupled with the Control Relay Server or offered separately on another server. If the server supports relaying of UDP-encapsulated ESP, the host is allowed to register for a data-relaying service using the registration extensions in Section 3.3 of [RFC8003]. If the server has sufficient relaying resources (free port numbers, bandwidth, etc.) available, it opens a UDP port on one of its addresses and signals the address and port to the registering host using the RELAYED_ADDRESS parameter (as defined in Section 5.12 in this document). If the Data Relay Server would accept the data-relaying request but does not currently have enough resources to provide data-relaying service, it MUST reject the request with Failure Type "Insufficient resources" [RFC8003].
さまざまな種類のNATデバイスを介したデータプレーン配信も保証するために、ホストは登録タイプRelay_UDP_ESP_ESP（value 3）を使用してUDPカプセル化されたESPリレーに登録することもできます。このサービスは、制御中継サーバと結合されてもよく、または別のサーバ上で別々に提供されてもよい。サーバーがUDPカプセル化されたESPの中継をサポートしている場合、[RFC8003]のセクション3.3の登録拡張機能を使用して、データ中継サービスに登録することができます。サーバーに十分な中継リソース（空きポート番号、帯域幅など）が使用可能な場合は、そのアドレスの1つにUDPポートを開き、Relayed_addressパラメータを使用して登録ホストにアドレスとポートを表示します（セクション5.12で定義されているように）。このドキュメント）。データ中継サーバがデータ中継要求を受け入れるが、現在データ中継サービスを提供するのに十分なリソースを使用していない場合は、失敗タイプの「リソース不足」[RFC8003]でリクエストを拒否する必要があります。
The registration process follows the generic registration extensions defined in [RFC8003]. The HIP control plane relaying registration follows [RFC5770], but the data plane registration is different. It is worth noting that if the HIP control and data plane relay services reside on different hosts, the client has to register separately to each of them. In the example shown in Figure 2, the two services are coupled on a single host. The text uses "Relay Client" and "Relay Server" as a shorthand when the procedures apply both to control and data cases.
登録プロセスは[RFC8003]で定義されている汎用登録拡張機能に従います。HIP制御プレーン中継登録は[RFC5770]に続きますが、データプレーン登録は異なります。股関節制御とデータプレーン中継サービスが異なるホスト上にある場合、クライアントはそれぞれに別々に登録する必要があることが注目に値します。図2に示す例では、2つのサービスは単一のホストで結合されています。このテキストは、プロシージャーが制御とデータケースの両方に適用されるときに、省略形として「リレー・クライアント」と「中継サーバー」を使用しています。
Control/Data Control/Data
Relay Client (Initiator) Relay Server (Responder)
| 1. UDP(I1) |
+---------------------------------------------------------------->|
| |
| 2. UDP(R1(REG_INFO(RELAY_UDP_HIP,[RELAY_UDP_ESP]))) |
|<----------------------------------------------------------------+
| |
| 3. UDP(I2(REG_REQ(RELAY_UDP_HIP),[RELAY_UDP_ESP])) |
+---------------------------------------------------------------->|
| |
| 4. UDP(R2(REG_RES(RELAY_UDP_HIP,[RELAY_UDP_ESP]), REG_FROM, |
| [RELAYED_ADDRESS])) |
|<----------------------------------------------------------------+
| |
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 to the Relay Server. It is RECOMMENDED that the Relay Client select a random source 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 Relay Server listen to incoming connections at UDP port 10500. If some other port number is used, it needs to be known by potential Relay Clients.
ステップ1において、リレークライアント（イニシエータ）は、UDPを介してI1パケットをリレーサーバに送信することによって登録手順を開始する。Relayクライアントは、基本交換を開始するためのエフェメラルポート範囲49152-65535からランダムソースポート番号を選択することをお勧めします。あるいは、ホストは、すべての発信接続を開始するための単一の固定ポートを使用することもできます。ただし、割り当てられたポートは、すべての対応するHIPアソシエーションが閉じられるまで維持されなければなりません。中継サーバはUDPポート10500で着信接続をリッスンすることをお勧めします。他のポート番号が使用されている場合は、潜在的なリレークライアントで知られている必要があります。
In step 2, the Relay Server (Responder) lists the services that it supports in the R1 packet. The support for HIP control plane over UDP relaying is denoted by the Registration Type value RELAY_UDP_HIP (see Section 5.9). If the server also supports the relaying of ESP traffic over UDP, it also includes the Registration Type value RELAY_UDP_ESP.
ステップ2では、リレーサーバ（レスポンダ）は、R1パケット内でサポートするサービスをリストしています。UDP中継の上のHIP制御プレーンのサポートは、登録タイプ値Relay_UDP_hip（セクション5.9を参照）で表されます。サーバーがUDPを介してESPトラフィックの中継をサポートしている場合は、登録タイプ値Relay_UDP_ESPも含まれます。
In step 3, the Relay Client selects the services for which it registers and lists them in the REG_REQ parameter. The Relay Client registers for the Control Relay service by listing the RELAY_UDP_HIP value in the request parameter. If the Relay Client also requires ESP relaying over UDP, it lists also RELAY_UDP_ESP.
ステップ3において、中継クライアントは、それが登録してそれらをリストするサービスをREG_REQパラメータで選択する。リレークライアントは、要求パラメータのRelay_UDP_hip値をリストして、Control Relayサービスを登録します。中継クライアントにESPがUDPを介して継承する必要がある場合は、Relay_UDP_ESPもリストされます。
In step 4, the Relay Server concludes the registration procedure with an R2 packet and acknowledges the registered services in the REG_RES parameter. The Relay Server denotes unsuccessful registrations (if any) in the REG_FAILED parameter of R2. The Relay Server also includes a REG_FROM parameter that contains the transport address of the Relay Client as observed by the Relay Server (server-reflexive candidate). If the Relay Client registered to ESP-relaying service, the Relay Server includes a RELAYED_ADDRESS parameter that describes the UDP port allocated to the Relay Client for ESP relaying. It is worth noting that the Data Relay Client must first activate this UDP port by sending an UPDATE message to the Data Relay Server that includes a PEER_PERMISSION parameter as described in Section 4.12.1 both after base exchange and handover procedures. Also, the Data Relay Server should follow the port allocation recommendations in Section 7.5.
ステップ4において、中継サーバは、R2パケットを用いた登録手順を締めくくり、reg_resパラメータ内の登録済みサービスを確認する。中継サーバは、R2のREG_FAILEDパラメータ内の失敗した登録（存在する場合）を示します。中継サーバには、中継サーバ（サーバ再帰候補）によって観察された中継クライアントのトランスポートアドレスを含むREG_FROMパラメータも含まれています。RelayクライアントがESPに登録されている場合、中継サーバーには、ESP中継のために中継クライアントに割り当てられたUDPポートを記述するrelayed_addressパラメータが含まれています。データリレークライアントは、4.12.1の両方で、Base ExchangeおよびHandoverプロシージャの両方で、Peer_Permissionパラメータを含むデータリレーサーバーに更新メッセージを送信することによって、最初にこのUDPポートをアクティブにする必要があることは注目に値します。また、データリレーサーバーは、セクション7.5のポート割り当ての推奨事項に従うべきです。
After the registration, the Relay Client periodically sends NAT keepalives to the Relay Server in order to keep the NAT bindings between the Relay Client and the relay alive. The keepalive extensions are described in Section 4.10.
登録後、リレークライアントは、中継クライアントとリレーの間のNATバインディングを生きているために、NATキープアライブを中継サーバに定期的に送信します。キープアライブ拡張機能はセクション4.10で説明されています。
The Data Relay Client MUST maintain an active HIP association with the Data Relay Server as long as it requires the data-relaying service. When the HIP association is closed (or times out), or the registration lifetime passes without the Data Relay Client refreshing the registration, the Data Relay Server MUST stop relaying packets for that host and close the corresponding UDP port (unless other Data Relay Clients are still using it).
データリレークライアントは、データ中継サービスが必要な限り、データリレーサーバーとアクティブなHIPアソシエーションを維持する必要があります。HIPアソシエーションが閉じられたとき（またはタイムアウト）、またはデータリレークライアントが登録を更新することなく登録寿命が渡されると、データリレーサーバーはそのホストのためのパケットの中継を停止し、対応するUDPポートを閉じる必要があります（他のデータリレークライアントがある限りそれでもそれを使用しています）。
The Data Relay Server SHOULD offer a different relayed address and port for each Data Relay Client because not doing so can cause problems with stateful firewalls (see Section 7.5).
データリレーサーバーは、ステートフルファイアウォールで問題を引き起こす可能性があるため、データリレークライアントごとに異なる中継アドレスとポートを提供する必要があります（セクション7.5を参照）。
When a Control Relay Client sends an UPDATE (e.g., due to host movement or to renew service registration), the Control Relay Server MUST follow the general guidelines defined in [RFC8003], with the difference that all UPDATE messages are delivered on top of UDP. In addition to this, the Control Relay Server MUST include the REG_FROM parameter in all UPDATE responses sent to the Control Relay Client. This applies to both renewals of service registration and to host movement. It is especially important for the case of host movement, as this is the mechanism that allows the Control Relay Client to learn its new server-reflexive address candidate.
Control Relayクライアントがアップデートを送信する（たとえば、ホストの動きのため、またはサービス登録の更新）、Control Relay Serverは[RFC8003]で定義されている一般的なガイドラインに従って、すべての更新メッセージがUDPの上に配信されます。。これに加えて、Control Relay Serverは、Control Relayクライアントに送信されたすべての更新応答でREG_FROMパラメータを含める必要があります。これは、サービス登録の更新とホスト移動の両方に適用されます。これは、制御リレークライアントがその新しいサーバーリフレーションアドレス候補を学習できるようにするメカニズムであるため、ホストの動きの場合に特に重要です。
A Data Relay Client can request multiple relayed candidates from the Data Relay Server (e.g., for the reasons described in Section 4.12.3). After the base exchange with registration, the Data Relay Client can request additional relayed candidates similarly as during the base exchange. The Data Relay Client sends an UPDATE message REG_REQ parameter requesting for the RELAY_UDP_ESP service. The UPDATE message MUST also include a SEQ and an ECHO_REQUEST_SIGNED parameter. The Data Relay Server MUST respond with an UPDATE message that includes the corresponding response parameters: REG_RES, ACK and ECHO_REQUEST_SIGNED. In case the Data Relay Server allocated a new relayed UDP port for the Data Relay Client, the REG_RES parameter MUST list RELAY_UDP_ESP as a service and the UPDATE message MUST also include a RELAYED_ADDRESS parameter describing the relayed UDP port. The Data Relay Server MUST also include the server-reflexive candidate in a REG_FROM parameter. It is worth mentioning that the Data Relay Client MUST activate the UDP port as described in Section 4.12.1 before it can be used for any ESP relaying.
データ中継クライアントは、データ中継サーバから複数の中継候補（例えば、セクション4.12.3で説明されている理由で）を要求することができる。登録による基本交換後、データ中継クライアントは、基本交換中と同じように追加の中継候補を要求することができる。データリレークライアントは、Relay_UDP_ESPサービスを要求する更新メッセージREG_REQパラメータを送信します。更新メッセージには、SEQとECHO_REQUEST_SIGNEDパラメータも含まなければなりません。データ中継サーバは、対応する応答パラメータを含む更新メッセージで応答する必要があります.REG_RES、ACK、ECHO_REQUEST_SIGNED。データ中継サーバがデータリレークライアントに新しい中継されたUDPポートを割り当てた場合、REG_RESパラメータはサービスとしてRelay_UDP_ESPを一覧表示する必要があり、更新メッセージは中継されたUDPポートを記述するRelayed_addressパラメータも含める必要があります。データ中継サーバには、REG_FROMパラメータにサーバ再帰候補も含める必要があります。 Data Relayクライアントは、任意のESP中継に使用できるように、セクション4.12.1で説明されているようにUDPポートをアクティブにする必要があることを言及する価値があります。
A Data Relay Client may unregister a relayed candidate in two ways. It can wait for its lifetime to expire or it can explicitly request it with zero lifetime using the UPDATE mechanism. The Data Relay Client can send a REG_REQ parameter with zero lifetime to the Data Relay Server in order to expire all relayed candidates. To expire a specific relayed candidate, the Data Relay Client MUST also include a RELAYED_ADDRESS parameter as sent by the server in the UPDATE message. Upon closing the HIP association (CLOSE-CLOSE-ACK procedure initiated by either party), the Data Relay Server MUST also expire all relayed candidates.
データリレークライアントは、2つの方法で中継候補を登録解除することができる。その生涯が期限切れになるのを待つか、更新メカニズムを使用してゼロ寿命で明示的に要求することができます。データリレークライアントは、すべての中継候補を期限切れにするために、存在する存続期間をゼロ寿命でreg_reqパラメータを送信することができます。特定の中継候補を期限切れにするには、データリレークライアントには、更新メッセージ内のサーバーによって送信されたRelayed_addressパラメータも含まなければなりません。HIPアソシエーション（どちらの当事者によって開始された閉鎖ackプロシージャ）を閉じると、データリレーサーバーもすべての中継候補を期限切れにする必要があります。
Please also refer to Section 7.8 for protection against cross-protocol attacks for both Control Relay Client and Server.
Control Relayクライアントとサーバーの両方のクロスプロトコル攻撃に対する保護については、セクション7.8も参照してください。
An Initiator needs to gather a set of address candidates before contacting a (non-relay) Responder. The candidates are needed for connectivity checks that allow two hosts to discover a direct, non-relayed path for communicating with each other. One server-reflexive candidate can be discovered during the registration with the Control Relay Server from the REG_FROM parameter (and another from Data Relay Server if one is employed).
イニシエータは、（非リレー）レスポンダに連絡する前に一連のアドレス候補を集める必要があります。候補は、2人のホストが互いに通信するための直接的で中継された経路を発見できるようにする接続チェックに必要です。1つのサーバー - 再帰候補は、REG_FROMパラメータ（およびデータ中継サーバから採用されている場合は別の場合は別の）から制御リレーサーバとの登録中に発見することができる。
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-HIP-UDP mode 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 Data Relay 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 Control Relay Server registration as a server-reflexive candidate. In this case, no further candidate gathering is needed.
候補収集はいつでも行うことができますが、ICE-HIP-UDPモードが接続性チェックに使用される場合は、Base ExchangeにI2またはR2を送信する前に行う必要があります。NATトラバーサルが成功した可能性を最大にするために、3種類の候補者全員（ホスト、サーバー再帰、再現）が集められていることをお勧めします。ただし、データ中継サーバーが使用されていて、ホストに使用するローカルIPアドレスのみが使用されていない場合、ホストはローカルアドレスを、コントロールリレーサーバー登録中に検出されたreg_fromパラメータからの唯一のホスト候補として使用することができます。サーバー再帰候補。この場合、それ以上の候補集会は必要ありません。
A Data Relay Client MAY register only a single relayed candidate that it uses with multiple other peers. However, it is RECOMMENDED that a Data Relay Client registers a new server relayed candidate for each of its peers for the reasons described in Section 4.12.3. The procedures for registering multiple relayed candidates are described in Section 4.1.
データリレークライアントは、それが他の複数のピアで使用する単一の中継候補だけを登録することができます。ただし、データリレークライアントは、セクション4.12.3で説明されている理由で、そのピアのそれぞれの新しいサーバー中継候補を登録することをお勧めします。複数の中継候補を登録するための手順はセクション4.1で説明されている。
If a Relay Client has more than one network interface, it can discover additional server-reflexive candidates by sending UPDATE messages from each of its interfaces to the Relay Server. Each such UPDATE message MUST include the following parameters: the registration request (REG_REQ) parameter with Registration Type CANDIDATE_DISCOVERY (value 4) and the ECHO_REQUEST_SIGNED parameter. When a Control Relay Server receives an UPDATE message with registration request containing a CANDIDATE_DISCOVERY type, it MUST include a REG_FROM parameter, containing the same information as if this were a Control Relay Server registration, to the response (in addition to the mandatory ECHO_RESPONSE_SIGNED parameter). This request type SHOULD NOT create any state at the Control Relay Server.
リレークライアントが複数のネットワークインタフェースを持っている場合は、そのインターフェイスの各インターフェイスからリレーサーバーに更新メッセージを送信することで、追加のサーバーリフレクティブ候補を検出できます。そのような更新メッセージには、次の各パラメータを含める必要があります。登録タイプ候補候補（value 4）とECHO_REQUEST_SIGNEDパラメータを含む登録要求（REG_REQ）パラメータ。Control Relay Serverが候補者を含む登録要求で更新メッセージを受信すると、これがControl Relay Server登録である場合と同じ情報を含むREG_FROMパラメータを含める必要があります（必須のecho_response_signedパラメータに加えて）。。この要求タイプは、コントロールリレーサーバーに任意の状態を作成しないでください。
The rules in Section 5.1.1 of [RFC8445] for candidate gathering are followed here. A number of host candidates (loopback, anycast and others) should be excluded as described in the ICE specification (Section 5.1.1.1 of [RFC8445]). Relayed candidates SHOULD be gathered in order to guarantee successful NAT traversal, and implementations SHOULD support this functionality even if it will not be used in deployments in order to enable it by software configuration update if needed at some point. Similarly, as explained in the ICE specification (Section 5.1.1.2 of [RFC8445]), if an IPv6-only host is in a network that utilizes NAT64 [RFC6146] and DNS64 [RFC6147] technologies, it may also gather IPv4 server-reflexive and/or relayed candidates from IPv4-only Control or Data Relay Servers. IPv6-only hosts SHOULD also utilize IPv6 prefix discovery [RFC7050] to discover the IPv6 prefix used by NAT64 (if any) and generate server-reflexive candidates for each IPv6-only interface, accordingly. The NAT64 server-reflexive candidates are prioritized like IPv4 server-reflexive candidates.
候補集会のための[RFC8445]のセクション5.1.1の規則に従ってください。多くのホスト候補（ループバック、Anycastなど）は、ICE仕様（[RFC8445]のセクション5.1.1.1）の説明に従って除外されるべきです。 NATトラバーサルを成功させるために中継された候補者は収集されるべきです、そして、実装は、必要に応じてソフトウェア構成の更新によってそれを有効にするために展開では使用されない場合でも実装をサポートする必要があります。同様に、ICE仕様（[RFC8445]のセクション5.1.1.2）で説明されているように、IPv6専用ホストがNAT64 [RFC6146]とDNS64 [RFC6147]テクノロジを利用するネットワークにある場合は、IPv4サーバーリフレクサを収集することもあります。 IPv4専用制御またはデータ中継サーバからの候補および/または候補者。 IPv6専用ホストは、IPv6プレフィックス検出[RFC7050]を利用して、NAT64（もしあれば）で使用されるIPv6プレフィックスを検出し、それに応じて各IPv6専用インターフェイスのサーバーリフレクサ候補を生成する必要があります。 NAT64サーバ再帰候補は、IPv4サーバ再帰候補のように優先されます。
HIP-based connectivity can be utilized by IPv4 applications using Local Scope Identifiers (LSIs) and by IPv6-based applications using HITs. The LSIs and HITs of the local virtual interfaces MUST be excluded in the candidate gathering phase as well to avoid creating unnecessary loopback connectivity tests.
HIPベースの接続性は、ローカルスコープ識別子（LSI）およびヒットを使用してIPv6ベースのアプリケーションを使用してIPv4アプリケーションによって利用できます。ローカル仮想インタフェースのLSIとヒットは、不要なループバック接続テストを作成するのを防ぐために、候補収集段階でも除外する必要があります。
Gathering of candidates MAY also be performed by other means than described in this section. For example, the candidates could be gathered as specified in Section 4.2 of [RFC5770] if STUN servers are available, or if the host has just a single interface and no STUN or Data Relay Server are available.
候補の集まりはまた、このセクションで説明されているものよりも他の手段によって実行され得る。たとえば、STUNサーバーが使用可能な場合は、[RFC5770]のセクション4.2で指定されているように、または候補者を収集できます。
Each local address candidate MUST be assigned a priority. The following recommended formula (as described in [RFC8445]) SHOULD be used:
各ローカルアドレス候補に優先順位を割り当てる必要があります。次の推奨式（[RFC8445]）を使用する必要があります。
priority = (2^24)*(type preference) + (2^8)*(local preference) +
(2^0)*(256 - component ID)
In the formula, the type preference follows the ICE specification (as defined in Section 5.1.2.1 of [RFC8445]): the RECOMMENDED values are 126 for host candidates, 100 for server-reflexive candidates, 110 for peer-reflexive candidates, and 0 for relayed candidates. The highest value is 126 (the most preferred) and lowest is 0 (last resort). For all candidates of the same type, the preference type value MUST be identical, and, correspondingly, the value MUST be different for different types. For peer-reflexive values, the type preference value MUST be higher than for server-reflexive types. It should be noted that peer-reflexive values are learned later during connectivity checks.
式中、タイプの設定はICE仕様に従います（[RFC8445]のセクション5.1.2.1で定義されているように）。中継候補者のために。最高値は126（最も好ましい）で、最低は0（最後のリゾート）です。同じタイプのすべての候補に対して、環境設定タイプの値は同一でなければならず、対応して値は種類によって異なる必要があります。ピアリフレクサ値の場合、タイプ設定値はサーバーリフレクスタイプの場合よりも高くなければなりません。接続されたチェックの間に、ピアリフレクサ値が後で学習されます。
Following the ICE specification, the local preference MUST be an integer from 0 (lowest preference) to 65535 (highest preference) inclusive. In the case the host has only a single address candidate, the value SHOULD be 65535. In the case of multiple candidates, each local preference value MUST be unique. Dual-stack considerations for IPv6 also apply here as defined in Section 5.1.2.2 of [RFC8445].
ICE仕様に続いて、ローカルの環境設定は0（最低環境設定）から65535（最高設定）までの整数でなければなりません。ホストが単一のアドレス候補のみを持っている場合、値は65535でなければなりません。複数の候補の場合、各ローカル環境設定値は一意である必要があります。IPv6のデュアルスタックの考慮事項も、[RFC8445]のセクション5.1.2.2で定義されているように適用されます。
Unlike with SDP used in conjunction with ICE, this protocol only creates a single UDP flow between the two communicating hosts, so only a single component exists. Hence, the component ID value MUST always be set to 1.
SDPとは異なり、ICEと組み合わせて使用されるこのプロトコルは、2つの通信ホスト間の単一のUDPフローのみを作成するため、単一のコンポーネントのみが存在します。したがって、コンポーネントID値は常に1に設定されている必要があります。
As defined in Section 14.3 of [RFC8445], the retransmission timeout (RTO) for address gathering from a Control/Data Relay Server SHOULD be calculated as follows:
[RFC8445]のセクション14.3で定義されているように、コントロール/データリレーサーバーからのアドレス収集のための再送信タイムアウト（RTO）は次のように計算されるべきです。
RTO = MAX (1000 ms, Ta * (Num-Of-Cands))
RTO = MAX（1000ミリ秒、*※カード数））
where Ta is the value used for the connectivity check pacing and Num-Of-Cands is the number of server-reflexive and relay candidates. A smaller value than 1000 ms for the RTO MUST NOT be used.
ここで、TAは接続性チェックペーシングとカナダ数の数である値は、サーバーリレクティブ候補の数です。RTOの場合は1000ミリ秒未満の値を使用してはいけません。
This section describes the usage of a non-critical parameter type called NAT_TRAVERSAL_MODE with a new mode called ICE-HIP-UDP. The presence of the new mode in the NAT_TRAVERSAL_MODE 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 [RFC7401]), it can be ignored by an end host, which means that the host is not required to support it or may decline to use it.
このセクションでは、ICE-HIP-UDPと呼ばれる新しいモードを持つNAT_TRAVERSAL_MODEという非重要でないパラメータタイプの使用方法について説明します。HIPベース交換のNAT_TRAVERSAL_MODEパラメータの新しいモードの存在は、エンドホストがこのドキュメントで説明されているNATトラバーサル拡張機能をサポートすることを意味します。パラメータが非重要ではない（[RFC7401]のセクション5.2.1で定義されているように）、それはエンドホストによって無視されることができます。これは、ホストがそれをサポートするために必要であるか、それを使用することを拒否することができることを意味します。
With registration with a Control/Data Relay Server, it is usually sufficient to use the UDP-ENCAPSULATION mode of NAT traversal since the Relay Server is assumed to be in public address space. Thus, the Relay Server SHOULD propose the UDP-ENCAPSULATION mode as the preferred or only mode. The NAT traversal mode negotiation in a HIP base exchange is illustrated in Figure 3. It is worth noting that the Relay Server could be located between the hosts, but is omitted here for simplicity.
制御/データ中継サーバに登録することで、リレーサーバは公開アドレス空間内にあると仮定されているため、通常、NATトラバースのUDPカプセル化モードを使用するのに十分です。したがって、中継サーバは、UDPカプセル化モードを優先モードまたは専用モードとして提案する必要があります。股関節交換機のNATトラバーサルモード交渉を図3に示します。これは、リレーサーバーがホスト間に配置される可能性があることに注目する価値がありますが、簡単にするためにここでは省略されています。
Initiator Responder
| 1. UDP(I1) |
+----------------------------------------------------------------->|
| |
| 2. UDP(R1(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ..)) |
|<-----------------------------------------------------------------+
| |
| 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ENC(LOC_SET), ..))|
+----------------------------------------------------------------->|
| |
| 4. UDP(R2(.., ENC(LOC_SET), ..)) |
|<-----------------------------------------------------------------+
| |
Figure 3: Negotiation of NAT Traversal Mode
図3：NATトラバーサルモードの交渉
In step 1, the Initiator sends an I1 to the Responder.
ステップ1において、イニシエータはI1をレスポンダに送信する。
In step 2, the Responder responds with an R1. As specified in [RFC5770], the NAT_TRAVERSAL_MODE parameter in R1 contains a list of NAT traversal modes the Responder supports. The mode specified in this document is ICE-HIP-UDP (value 3).
ステップ2において、レスポンダはR1で応答する。[RFC5770]で指定されているように、R1のNAT_TRAVERSAL_MODEパラメーターには、レスポンダがサポートするNATトラバーサルモードのリストが含まれています。この文書で指定されているモードはICE-HIP-UDP（値3）です。
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-HIP-UDP mode was selected, the I2 also includes the "Transport address" locators (as defined in Section 5.7) of the Initiator in a LOCATOR_SET parameter (denoted here with LOC_SET). With ICE-HIP-UDP mode, the LOCATOR_SET parameter MUST be encapsulated within an ENCRYPTED parameter (denoted here with ENC) according to the procedures in Sections 5.2.18 and 6.5 in [RFC7401]. The locators in I2 are the "HIP offer".
ステップ3において、イニシエータはNAT_TRAVERSAL_MODEパラメータを含むI2を送信する。それは、レスポンダによって提供されるモードのリストからイニシエータによって選択されたモードを含みます。ICE-HIP-UDPモードが選択されている場合、I2はLOCATER_SETパラメーター（ここでloc_setに示されている）のイニシエータの「トランスポートアドレス」ロケーターも含まれています。ICE-HIP-UDPモードでは、[RFC7401]のセクション5.2.18および6.5の手順に従って、LOCATER_SETパラメータを暗号化パラメータ（ENCに示す）内にカプセル化する必要があります。i2のロケータは「股份有名」です。
In step 4, the Responder concludes the base exchange with an R2 packet. If the Initiator chose ICE-HIP-UDP traversal mode, the Responder includes a LOCATOR_SET parameter in the R2 packet. With ICE-HIP-UDP mode, the LOCATOR_SET parameter MUST be encapsulated within an ENCRYPTED parameter according to the procedures in Sections 5.2.18 and 6.5 in [RFC7401]. 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-HIP-UDPトラバーサルモードを選択した場合、レスポンダはR2パケット内のlocator_setパラメータを含みます。ICE-HIP-UDPモードでは、[RFC7401]のセクション5.2.18および6.5の手順に従って、LOCATER_SETパラメータを暗号化パラメータ内にカプセル化する必要があります。I2のロケーターのように符号化されたR2のロケータは、「アイスアンサー」です。イニシエータによって選択されたNATトラバーサルモードがレスポンダによってサポートされていない場合、レスポンダはタイプNO_VALID_NAT_TRAVERSAL_MODE_PARAMETERを使用して通知パケットで返信し、基本交換を中止する必要があります。
As explained in Legacy ICE-HIP [RFC5770], 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. 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. The value that is used by both of the hosts is the higher of the two offered values.
Legacy Ice-Hip [RFC5770]で説明されているように、接続性チェックを備えたNATトラバーサルモードが使用されると、新しい取引は輻輳を防ぎ、NATの圧倒的なNATを回避するのに最適なトランザクションを開始しないでください。この目的のために、基本交換中に、ホストはR1およびI2パケットのトランザクション_pacingパラメータを使用して、トランザクションペーシング値Taをネゴシエートできます。このパラメータには、新しい接続チェックの開始や前のチェックを再試行するなど、2つのNATトラバーサルトランザクション間で待機する最小時間（ミリ秒単位）が含まれています。両方のホストで使用される値は、2つのオファーされた値の方が高いです。
The minimum Ta value SHOULD be configurable, and if no value is configured, a value of 50 ms MUST be used. Guidelines for selecting a Ta value are given in Appendix A. Hosts MUST NOT use values smaller than 5 ms for the minimum Ta, since such values may not work well with some NATs (as explained in [RFC8445]). The Initiator MUST NOT propose a smaller value than what the Responder offered. If a host does not include the TRANSACTION_PACING parameter in the base exchange, a Ta value of 50 ms MUST be used as that host's minimum value.
最小TA値は設定可能で、値が設定されていない場合は、50 msの値を使用する必要があります。TA値を選択するためのガイドラインは付録Aに記載されています。ホストは最小TAの場合は5 ms未満の値を使用してはいけません（[RFC8445]）。イニシエータは、レスポンダが提供したものよりも小さい値を提案してはいけません。ホストに基本交換にTransaction_Pacingパラメータが含まれていない場合は、そのホストの最小値として50 msのTA値を使用する必要があります。
This section describes how the Initiator and Responder perform a base exchange through a Control Relay Server. Connectivity pacing (denoted as TA_P here) was described in Section 4.4 and is not repeated here. Similarly, the NAT traversal mode negotiation process (denoted as NAT_TM in the example) was described in Section 4.3 and is also not repeated here. If a Control Relay Server 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 or I2.
このセクションでは、イニシエータとレスポンダがControl Relay Serverを介して基本交換を実行する方法について説明します。接続性のペーシング（ここではTa_Pとして示されています）をセクション4.4に説明し、ここで繰り返さない。同様に、NATトラバーサルモードネゴシエーションプロセス（例ではNAT_TMと表記）はセクション4.3に記載されており、ここでも繰り返されない。Control Relay Serverが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 IP address of the Responder. Respectively, the Responder MUST respond to such an I1 packet with a UDP-encapsulated R1 packet, and also the rest of the communication related to the HIP association MUST also use UDP encapsulation.
イニシエータは、レスポンダのIPアドレス宛のときにUDPにカプセル化されているI1パケットを送信することをお勧めします。それぞれ、レスポンダはUDPカプセル化されたR1パケットを持つそのようなI1パケットに応答しなければならず、またHIPアソシエーションに関連する他の通信もUDPカプセル化を使用する必要があります。
Figure 4 illustrates a base exchange via a Control Relay Server. We assume that the Responder (i.e., a Control Relay Client) has already registered to the Control Relay Server. The Initiator may have also registered to another (or the same Control Relay Server), but the base exchange will traverse always through the Control Relay Server of the Responder.
図4は、制御中継サーバを介した基本交換を示している。レスポンダ（すなわち、制御リレークライアント）がすでに制御リレーサーバに登録されていると仮定する。イニシエータは他の（または同じ制御中継サーバ）にも登録されている可能性がありますが、ベース交換はレスポンダのControl Relayサーバーを常にトラバースします。
Initiator Control Relay Server Responder
| 1. UDP(I1) | |
+--------------------------------->| 2. UDP(I1(RELAY_FROM)) |
| +------------------------------->|
| | |
| | 3. UDP(R1(RELAY_TO, NAT_TM, |
| | TA_P)) |
| 4. UDP(R1(RELAY_TO, NAT_TM, |<-------------------------------+
| TA_P)) | |
|<---------------------------------+ |
| | |
| 5. UDP(I2(ENC(LOC_SET)), | |
| NAT_TM, TA_P)) | |
+--------------------------------->| 6. UDP(I2(ENC(LOC_SET), |
| | RELAY_FROM, NAT_TM, TA_P))|
| +------------------------------->|
| | |
| | 7. UDP(R2(ENC(LOC_SET), |
| 8. UDP(R2(ENC(LOC_SET), | RELAY_TO)) |
| 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 UDP via the Control Relay Server to the Responder. In the HIP header, the source HIT belongs to the Initiator and the destination HIT to the Responder. The Initiator sends the I1 packet from its IP address to the IP address of the Control Relay Server over UDP.
図4のステップ1において、イニシエータは制御中継サーバを介してI1パケットを介してResponderに送信される。HIPヘッダーでは、ソースヒットはイニシエータに属しており、宛先はレスポンダにヒットします。イニシエータはIPアドレスからUDPを介してIPアドレスからIPアドレスに送信されます。
In step 2, the Control Relay Server receives the I1 packet. If the destination HIT belongs to a successfully registered Control Relay Client (i.e., the host marked "Responder" in Figure 4), the Control Relay Server processes the packet. Otherwise, the Control Relay Server MUST drop the packet silently. The Control Relay Server appends a RELAY_FROM parameter to the I1 packet, which contains the transport source address and port of the I1 as observed by the Control Relay Server. The Control Relay Server protects the I1 packet with RELAY_HMAC, except that the parameter type is different as described in Section 5.8. The Control Relay Server changes the source and destination ports and IP addresses of the packet to match the values the Responder used when registering to the Control Relay Server, i.e., the reverse of the R2 used in the registration. The Control Relay Server MUST recalculate the transport checksum and forward the packet to the Responder.
ステップ2において、制御中継サーバはI1パケットを受信する。宛先のヒットが正常に登録された制御リレークライアント（すなわち、図4の「レスポンダ」とマークされたホスト）に属する場合、制御リレーサーバはパケットを処理する。それ以外の場合、コントロールリレーサーバーはパケットをサイレントにドロップする必要があります。制御リレーサーバは、制御リレーサーバによって観察されたI1のトランスポート送信元アドレスとポートを含むI1パケットにRelay_fromパラメータを追加します。Control Relay Serverは、パラメータタイプがセクション5.8で説明されているように異なる点を除いて、I1パケットをRelay_HMACを保護します。制御リレーサーバは、制御中継サーバに登録するときに使用されるレスポンダ、すなわち登録で使用されるR2の逆の値に一致するように、パケットの送信元ポートおよびIPアドレスを変更する。制御リレーサーバーはトランスポートチェックサムを再計算し、パケットをレスポンダに転送する必要があります。
In step 3, the Responder receives the I1 packet. The Responder processes it according to the rules in [RFC7401]. In addition, the Responder validates the RELAY_HMAC according to Section 5.8 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 Responder MUST include ICE-HIP-UDP in the NAT traversal modes. 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パケットを受信する。レスポンダは[RFC7401]の規則に従ってそれを処理します。さらに、レスポンダはセクション5.8に従ってRelay_HMACを検証し、検証が失敗した場合はパケットをサイレントドロップします。レスポンダは、それがRelay_toとNATトラバーサルモードパラメータを含むR1パケットで返信します。レスポンダには、NATトラバーサルモードのICE-HIP-UDPを含める必要があります。relay_toパラメータは、relay_fromパラメータ、すなわちイニシエータのトランスポートアドレスと同じ情報を含める必要がありますが、パラメータの型は異なります。RELAY_TOパラメーターは、R1の署名によって保護されていません.R1の署名では、レスポンダで事前に作成されたR1パケットを許可します。
In step 4, the Control Relay Server receives the R1 packet. The Control Relay Server drops the packet silently if the source HIT belongs to a Control Relay Client that has not successfully registered. The Control Relay Server MAY verify the signature of the R1 packet and drop it if the signature is invalid. Otherwise, the Control Relay Server rewrites the source address and port, and changes the destination address and port to match RELAY_TO information. Finally, the Control Relay Server recalculates the transport checksum and forwards the packet.
ステップ4において、制御リレーサーバはR1パケットを受信する。ソースヒットが正常に登録されていないコントロールリレークライアントに属する場合、Control Relay Serverはパケットをサイレントにドロップします。コントロールリレーサーバーはR1パケットの署名を検証し、署名が無効な場合はドロップできます。そうでなければ、制御リレーサーバは送信元アドレスとポートを書き換え、宛先アドレスとポートを変更してRelay_to情報と一致させる。最後に、制御リレーサーバはトランスポートチェックサムを再計算してパケットを転送します。
In step 5, the Initiator receives the R1 packet and processes it according to [RFC7401]. 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_SET parameter inside an ENCRYPTED parameter that lists all the HIP candidates (HIP 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 that includes ICE-HIP-UDP mode. The ENCRYPTED parameter along with its key material generation is described in detail in Sections 5.2.18 and 6.5 in [RFC7401].
ステップ5において、イニシエータはR1パケットを受信し、[RFC7401]に従って処理する。イニシエータは、このHIPアソシエーションのローカルピアリフレクティブ候補としてRELAY_TOパラメータのアドレスを使用してもよい。イニシエータは、R1の宛先トランスポートアドレスをソースアドレスとポートとして使用するI2パケットで返信します。I2パケットは、イニシエータのすべてのHIP候補（HIPオファー）をリストする暗号化パラメータ内のLOCATER_SETパラメータを含みます。候補はセクション5.7で定義されている形式を使用してエンコードされています。I2パケットには、ICE-HIP-UDPモードを含むNATトラバーサルモードパラメータも含まなければなりません。暗号化されたパラメータとその鍵素材生成は、[RFC7401]のセクション5.2.18および6.5で詳細に説明されています。
In step 6, the Control Relay Server receives the I2 packet. The Control Relay Server appends a RELAY_FROM and a RELAY_HMAC to the I2 packet similar to that explained in step 2, and forwards the packet to the Responder.
ステップ6において、制御リレーサーバはI2パケットを受信する。制御リレーサーバは、ステップ2で説明したものと同様に、Relay_fromとRelay_HMACをI2パケットに追加し、パケットをレスポンダに転送する。
In step 7, the Responder receives the I2 packet and processes it according to [RFC7401]. The Responder validates the RELAY_HMAC according to Section 5.8 and silently drops the packet if the validation fails. It replies with an R2 packet and includes a RELAY_TO parameter as explained in step 3. The R2 packet includes a LOCATOR_SET parameter inside an ENCRYPTED parameter that lists all the HIP candidates (ICE answer) of the Responder. The RELAY_TO parameter is protected by the Hashed Message Authentication Code (HMAC). The ENCRYPTED parameter along with its key material generation is described in detail in Sections 5.2.18 and 6.5 in [RFC7401].
ステップ7において、レスポンダはI2パケットを受信し、[RFC7401]に従って処理する。Responderはセクション5.8に従ってRelay_HMACを検証し、検証が失敗した場合はパケットをサイレントに削除します。それはR2パケットに応答し、ステップ3で説明されているようにRelay_toパラメータを含む.R2パケットは、レスポンダのすべてのHIP候補（ICE回答）をリストする暗号化パラメータ内のlocator_setパラメータを含む。RELAY_TOパラメータは、ハッシュされたメッセージ認証コード（HMAC）によって保護されています。暗号化されたパラメータとその鍵素材生成は、[RFC7401]のセクション5.2.18および6.5で詳細に説明されています。
In step 8, the Control Relay Server processes the R2 as described in step 4. The Control Relay Server 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 Control Relay Servers (including the one that is being used for the initial signaling) in the LOCATOR_SET parameter in I2 and R2 messages if they intend to use such servers for relaying HIP signaling immediately after the base exchange completes. The traffic type of these addresses MUST be "HIP signaling" (see Section 5.7) and they MUST NOT be used for the connectivity tests described in Section 4.6. If the Control Relay Server locator used for relaying the base exchange is not included in I2 or R2 LOCATOR_SET parameters, it SHOULD NOT be used after the base exchange. Instead, further HIP signaling SHOULD use the same path as the data traffic. It is RECOMMENDED to use the same Control Relay Server throughout the lifetime of the host association that was used for forwarding the base exchange if the Responder includes it in the locator parameter of the R2 message.
ホストには、I2およびR2メッセージのLOCATER_SETパラメータの1つ以上の制御中継サーバのアドレス（I2メッセージとR2メッセージ）のアドレスを含める必要があります。完了します。これらのアドレスのトラフィックタイプは「HIPシグナリング」でなければなりません（セクション5.7を参照）、セクション4.6で説明されている接続テストに使用してはなりません。基本交換を中継するために使用される制御中継サーバロケータがI2またはR2 Locator_setパラメータに含まれていない場合は、基本交換後に使用しないでください。代わりに、さらなるHIPシグナリングはデータトラフィックと同じパスを使用する必要があります。レスポンダがR2メッセージのLOCATORパラメータに含まれている場合は、ベース交換を転送するために使用されたホストアソシエーションの有効期間を通して同じControl Relay Serverを使用することをお勧めします。
When the Initiator and Responder complete the base exchange through the Control Relay Server, both of them employ the IP address of the Control Relay Server as the destination address for the packets. The address of the Control Relay Server MUST NOT be used as a destination for data plane traffic unless the server also supports Data Relay Server functionality, and the Client has successfully registered to use it. When NAT traversal mode with ICE-HIP-UDP was successfully negotiated and selected, the Initiator and Responder MUST start the connectivity checks in order to attempt to obtain direct end-to-end connectivity through NAT devices. It is worth noting that the connectivity checks MUST be completed even though no ESP_TRANSFORM would be negotiated and selected.
イニシエータとレスポンダが制御中継サーバを介してベース交換を完了すると、両方とも、パケットの宛先アドレスとして制御リレーサーバのIPアドレスを採用しています。サーバーがデータ中継サーバー機能をサポートしていれば、Control Relay Serverのアドレスをデータプレーントラフィックの宛先として使用してはいけません。クライアントはそれを使用するように正常に登録されました。ICE-HIP-UDPを使用したNATトラバーサルモードが正常にネゴシエートされ選択された場合、NATデバイスを介して直接エンドツーエンド接続を取得しようとするために、イニシエータとレスポンダは接続チェックを開始する必要があります。esp_transformがネゴシエーションされ選択されていなくても、接続チェックを完了しなければならないことは注目に値します。
The connectivity checks follow the ICE methodology [ICE-NONSIP], but UDP-encapsulated HIP control messages are used instead of ICE messages. As stated in the ICE specification, the basic procedure for connectivity checks has three phases: sorting the candidate pairs according to their priority, sending checks in the prioritized order, and acknowledging the checks from the peer host.
接続チェックはICEメソケーション[ICE-NOSIP]に従って、ICEメッセージの代わりにUDPカプセル化されたHIP制御メッセージが使用されます。ICE仕様に記載されているように、接続性チェックの基本的な手順には3つのフェーズがあります。優先順位に従って、候補ペアをソートし、優先順位付けされた順序でチェックを送信し、ピアホストからのチェックを確認します。
The Initiator MUST take the role of controlling host, and the Responder acts as the controlled host. The roles MUST persist throughout the HIP associate lifetime (to be reused even during mobility UPDATE procedures). In the case in which both communicating nodes are initiating communication to each other using an I1 packet, the conflict is resolved as defined in Section 6.7 of [RFC7401]; the host with the "larger" HIT changes its role to Responder. In such a case, the host changing its role to Responder MUST also switch to the controlled role.
イニシエータはホストを制御する役割を受ける必要があり、レスポンダは制御ホストとして機能します。役割は、HIPアソシエート寿命を通して（モビリティ更新手順の間でも再利用される）全体に永続的に保持されなければなりません。両方の通信ノードがI1パケットを使用して互いに通信を開始している場合、[RFC7401]のセクション6.7で定義されているように競合が解決されます。「大きい」ヒットのホストは、その役割を応答者に変更します。このような場合、ホストはレスポンダに役割を変更することも制御された役割に切り替わる必要があります。
The protocol follows standard HIP UPDATE sending and processing rules as defined in Sections 6.11 and 6.12 in [RFC7401], but some new parameters are introduced (CANDIDATE_PRIORITY, MAPPED_ADDRESS, NOMINATE, PEER_PERMISSION, and RELAYED_ADDRESS).
このプロトコルは、[RFC7401]のセクション6.11および6.12で定義されている標準のHIP更新送信および処理規則に従いますが、いくつかの新しいパラメータが導入されます（候補者、MAPPERS_ADDRESS、推薦、Peer_Permission、およびRelayed_Address）。
Figure 5 illustrates connectivity checks in a simplified scenario where the Initiator and Responder have only a single candidate pair to check. Typically, NATs drop messages until both sides have sent messages using the same port pair. In this scenario, the Responder sends a connectivity check first but the NAT of the Initiator drops it. However, the connectivity check from the Initiator reaches the Responder because it uses the same port pair as the first message. It is worth noting that the message flow in this section is idealistic, and, in practice, more messages would be dropped, especially in the beginning. For instance, connectivity tests always start with the candidates with the highest priority, which would be host candidates (which would not reach the recipient in this scenario).
図5は、イニシエータとレスポンダがチェックするための単一の候補ペアのみを持っている単純化されたシナリオでの接続性チェックを示しています。通常、NATSは同じポートペアを使用して両方がメッセージを送信するまでメッセージを削除します。このシナリオでは、レスポンダは最初に接続チェックを送信しますが、イニシエータのNATはそれを降下します。ただし、最初のメッセージと同じポートペアを使用するため、イニシエータからの接続チェックはレスポンダに到達します。このセクションのメッセージフローが理想主義的であることに注目する価値があり、実際には、特に最初にもっと多くのメッセージが削除されます。たとえば、接続性テストは常に最高の優先順位を持つ候補者から始まります。これはホスト候補（このシナリオで受信者に到達しません）です。
Initiator NAT1 NAT2 Responder
| | 1. UDP(UPDATE(SEQ, CAND_PRIO, | |
| | ECHO_REQ_SIGN)) | |
| X<-----------------------------------+----------------+
| | | |
| 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | |
+-------------+------------------------------------+--------------->|
| | | |
| 3. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | |
|<------------+------------------------------------+----------------+
| | | |
| 4. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | |
|<------------+------------------------------------+----------------+
| | | |
| 5. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | |
+-------------+------------------------------------+--------------->|
| | | |
| 6. Other connectivity checks using UPDATE over UDP |
|<------------+------------------------------------+---------------->
| | | |
| 7. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE)) |
+-------------+------------------------------------+--------------->|
| | | |
| 8. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, |
| NOMINATE)) | |
|<------------+------------------------------------+----------------+
| | | |
| 9. UDP(UPDATE(ACK, ECHO_RESP_SIGN)) | |
+-------------+------------------------------------+--------------->+
| | | |
| 10. ESP data traffic over UDP | |
+<------------+------------------------------------+--------------->+
| | | |
Figure 5: Connectivity Checks
図5：接続チェック
In step 1, the Responder sends a connectivity check to the Initiator that the NAT of the Initiator drops. The message includes a number of parameters. As specified in [RFC7401], the SEQ parameter includes a running sequence identifier for the connectivity check. The candidate priority (denoted CAND_PRIO in the figure) describes the priority of the address candidate being tested. The ECHO_REQUEST_SIGNED (denoted ECHO_REQ_SIGN in the figure) includes a nonce that the recipient must sign and echo back as it is.
ステップ1において、レスポンダは、イニシエータのNATが低下するというイニシエータに接続チェックを送信する。メッセージにはいくつかのパラメータが含まれています。[RFC7401]で指定されているように、seqパラメーターは接続性チェックの実行されているシーケンス識別子を含みます。候補優先順位（図のCAND_PRIOと表示）は、テストされているアドレス候補の優先順位を説明しています。ECHO_REQUEST_SIGNED（図のECHO_REQ_SIGNで示されています）は、受信者がそのまま反復しなければならないことを非難します。
In step 2, the Initiator sends a connectivity check, using the same address pair candidate as in the previous step, and the message successfully traverses the NAT boxes. The message includes the same parameters as in the previous step. It should be noted that the sequence identifier is locally assigned by the Initiator, so it can be different than in the previous step.
ステップ2において、イニシエータは前のステップと同じアドレスペア候補を使用して接続性チェックを送信し、メッセージはNATボックスを正常に通過する。メッセージは前のステップと同じパラメータを含む。シーケンス識別子は開始者によってローカルに割り当てられているので、前のステップとは異なる可能性があることに留意されたい。
In step 3, the Responder has successfully received the previous connectivity check from the Initiator and starts to build a response message. Since the message from the Initiator included a SEQ, the Responder must acknowledge it using an ACK parameter. Also, the nonce contained in the echo request must be echoed back in an ECHO_RESPONSE_SIGNED (denoted ECHO_RESP_SIGN) parameter. The Responder also includes a MAPPED_ADDRESS parameter (denoted MAPPED_ADDR in the figure) that contains the transport address of the Initiator as observed by the Responder (i.e., peer-reflexive candidate). This message is successfully delivered to the Initiator; upon reception, the Initiator marks the candidate pair as valid.
ステップ3において、レスポンダはイニシエータから以前の接続チェックを正常に受信し、応答メッセージの構築を開始します。イニシエータからのメッセージはSEQを含むので、レスポンダはACKパラメータを使用してそれを確認する必要があります。また、エコー要求に含まれているNonceは、echo_response_signed（enecho_resp_sign）パラメータにエコーされなければなりません。レスポンダには、レスポンダによって観察されたイニシエータのトランスポートアドレス（ピアリフレクティブ候補）が含まれているMAPPAPED_ADDRESSパラメータ（図中のmapped_addrで示す）を含む。このメッセージはイニシエータに届出されます。受信すると、イニシエータは候補ペアを有効にマークします。
In step 4, the Responder retransmits the connectivity check sent in the first step, since it was not acknowledged yet.
ステップ4において、レスポンダはまだ認識されていないので、第1のステップで送信された接続チェックを再送信する。
In step 5, the Initiator responds to the previous connectivity check message from the Responder. The Initiator acknowledges the SEQ parameter from the previous message using an ACK parameter and the ECHO_REQUEST_SIGNED parameter with ECHO_RESPONSE_SIGNED. In addition, it includes the MAPPED_ADDR parameter that includes the peer-reflexive candidate. This response message is successfully delivered to the Responder; upon reception, the Initiator marks the candidate pair as valid.
ステップ5において、イニシエータはレスポンダから以前の接続チェックメッセージに応答する。イニシエータは、ACKパラメータとecho_requset_signedパラメータを使用して、echo_response_signedを使用して、前回のメッセージからSEQパラメータを確認します。さらに、ピア再帰候補を含むmapped_addrパラメータを含みます。この応答メッセージはレスポンダに正常に配信されます。受信すると、イニシエータは候補ペアを有効にマークします。
In step 6, despite the two hosts now having valid address candidates, the hosts still test the remaining address candidates in a similar way as in the previous steps. It should be noted that each connectivity check has a unique sequence number in the SEQ parameter.
ステップ6において、2つのホストが有効なアドレス候補を有するにもかかわらず、ホストは依然として前のステップと同様の方法で残りのアドレス候補をテストする。各接続チェックは、SEQパラメータに固有のシーケンス番号を持ちます。
In step 7, the Initiator has completed testing all address candidates and nominates one address candidate to be used. It sends an UPDATE message using the selected address candidates that includes a number of parameters: SEQ, ECHO_REQUEST_SIGNED, CANDIDATE_PRIORITY, and the NOMINATE parameter.
ステップ7において、イニシエータは全アドレス候補のテストを完了し、使用されるべき1つのアドレス候補を指す。選択されたアドレス候補を使用して、選択されたアドレス候補を使用して、SEQ、ECHO_REQUEST_SIGNED、候補者、および推薦パラメータを含む。
In step 8, the Responder receives the message with the NOMINATE parameter from the Initiator. It sends a response that includes the NOMINATE parameter in addition to a number of other parameters. The ACK and ECHO_RESPONSE_SIGNED parameters acknowledge the SEQ and ECHO_REQUEST_SIGNED parameters from the previous message from the Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGNED parameters in order to receive an acknowledgment from the Responder.
ステップ8において、レスポンダは、イニシエータからのノミネートパラメータを用いてメッセージを受信する。他の多数のパラメータに加えて、ノミネートパラメータを含む応答を送信します。ACKとECHO_RESPONSE_SIGNEDパラメータは、イニシエータから前のメッセージからSEQおよびECHO_REQUEST_SIGNEDパラメータを確認します。レスポンダは、レスポンダからの確認応答を受信するために、SEQおよびECHO_REQUEST_SIGNEDパラメータを含む。
In step 9, the Initiator completes the candidate nomination process by confirming the message reception to the Responder. In the confirmation message, the ACK and ECHO_RESPONSE_SIGNED parameters correspond to the SEQ and ECHO_REQUEST_SIGNED parameters in the message sent by the Responder in the previous step.
ステップ9において、イニシエータは、メッセージ受信をレスポンダに確認することによって候補指名処理を完了する。確認メッセージでは、ACKおよびECHO_RESPONSE_SIGNEDパラメータは、前のステップで応答者によって送信されたメッセージ内のSEQおよびECHO_REQUEST_SIGNEDパラメータに対応します。
In step 10, the Initiator and Responder can start sending application payload over the successfully nominated address candidates.
ステップ10において、イニシエータおよびレスポンダは、首尾よく指名されたアドレス候補を介してアプリケーションペイロードの送信を開始することができる。
It is worth noting that if either host has registered a relayed address candidate from a Data Relay Server, the host MUST activate the address before connectivity checks by sending an UPDATE message containing the PEER_PERMISSION parameter as described in Section 4.12.1. Otherwise, the Data Relay Server drops ESP packets using the relayed address.
いずれかのホストがデータ中継サーバから中継アドレス候補を登録した場合、ホストは、セクション4.12.1で説明されているように、Peer_Permissionパラメータを含む更新メッセージを送信することによって、接続の前にアドレスをアクティブにする必要があります。それ以外の場合、データリレーサーバーは中継アドレスを使用してESPパケットをドロップします。
It should be noted that in the case in which both the Initiator and Responder are advertising their own relayed address candidates, it is possible that the two hosts choose the two relayed addresses as a result of the ICE nomination algorithm. While this is possible (and even could be desirable for privacy reasons), it can be unlikely due to low priority assigned for the relayed address candidates. In such an event, the nominated address pair is always symmetric; the nomination algorithm prevents asymmetric address pairs (i.e., each side choosing different pair) such as a Data Relay Client using its own Data Relay Server to send data directly to its peer while receiving data from the Data Relay Server of its peer.
イニシエータとレスポンダの両方がそれら自身の中継アドレス候補を広告している場合、2つのホストがICEノミネートアルゴリズムの結果として2つの中継アドレスを選択することが可能であることに留意されたい。これは可能であるが（そしてプライバシー上の理由からさえ望ましいかもしれない）、中継アドレス候補に対して割り当てられた低い優先順位のためには考えにくくなる可能性がある。そのような場合、指名されたアドレスペアは常に対称的である。推薦アルゴリズムは、そのピアのデータ中継サーバからデータを受信しながら、それ自身のデータ中継サーバを使用してデータ中継クライアントなどのデータリレークライアントなどの非対称アドレスペア（すなわち、各側が異なるペアを選択する）を防止する。
The HITs of the two communicating hosts MUST be used as credentials in this protocol (in contrast to ICE, which employs username-password fragments). A HIT pair uniquely identifies the corresponding HIT association, and a SEQ number in an UPDATE message identifies a particular connectivity check.
2つの通信ホストのヒットは、このプロトコルの資格情報として使用されている必要があります（iceの場合は、ユーザー名 - パスワードのフラグメントを使用する）。ヒットペアは対応するヒットアソシエーションを一意に識別し、更新メッセージ内のSEQ番号は特定の接続チェックを識別します。
All of the connectivity check messages MUST be protected with HIP_HMAC and signatures (even though the illustrations in this specification omit them for simplicity) according to [RFC7401]. Each connectivity check sent by a host MUST include a SEQ parameter and ECHO_REQUEST_SIGNED parameter; correspondingly, the peer MUST respond to these using ACK and ECHO_RESPONSE_SIGNED according to the rules specified in [RFC7401].
[RFC7401]によると、すべての接続チェックメッセージはHIP_HMACと署名で保護する必要があります（この仕様のイラストは単純さのためにそれらを省略していますが）[RFC7401]。ホストによって送信された各接続チェックは、SEQパラメータとecho_request_signedパラメータを含める必要があります。それに対応して、ピアは[RFC7401]で指定された規則に従ってACKとECHO_RESPONSE_SIGNEDを使用してこれらに応答しなければなりません。
The host sending a connectivity check MUST validate that the response uses the same pair of UDP ports, and drop the packet if this is not the case.
接続性チェックを送信するホストは、応答が同じUDPポートを使用していることを検証し、これがそうでない場合はパケットをドロップする必要があります。
A host may receive a connectivity check before it has received the candidates from its peer. In such a case, the host MUST immediately queue a response by placing it in the triggered-check queue and then continue waiting for the candidates. A host MUST NOT select a candidate pair until it has verified the pair using a connectivity check as defined in Section 4.6.1.
ホストは、ピアから候補を受信する前に接続チェックを受信することがあります。そのような場合、ホストはそれをトリガーチェックキューに入れることによって直ちに応答をキューにキューに入れ、次に候補を待っていなければなりません。セクション4.6.1で定義されている接続性チェックを使用してペアを検証するまで、ホストは候補ペアを選択してはいけません。
Section 5.3.5 of [RFC7401] states that UPDATE packets have to include either a SEQ or ACK parameter (but can include both). In the connectivity check procedure specified in Section 4.6.1, each SEQ parameter should be acknowledged separately. In the context of NATs, this means that some of the SEQ parameters sent in connectivity checks will be lost or arrive out of order. From the viewpoint of the recipient, this is not a problem since the recipient will just "blindly" acknowledge the SEQ. However, the sender needs to be prepared for lost sequence identifiers and ACK parameters that arrive out of order.
[RFC7401]のセクション5.3.5は、更新パケットがSEQまたはACKパラメータを含める必要があると述べています（ただし、両方を含めることができます）。セクション4.6.1で指定された接続チェック手順では、各seqパラメータは別々に確認応答されます。NATSのコンテキストでは、これは接続チェックで送信されたSEQパラメータのいくつかが失われたり、順序が届かれたりすることを意味します。受信者の観点からは、受信者が「盲目的に」SEQを認めているので、これは問題ではありません。ただし、送信者は、順番に到着した紛失したシーケンス識別子とACKパラメータのために準備する必要があります。
As specified in [RFC7401], an ACK parameter may acknowledge multiple sequence identifiers. While the examples in the previous sections do not illustrate such functionality, it is also permitted when employing ICE-HIP-UDP mode.
[RFC7401]で指定されているように、ACKパラメーターは複数のシーケンス識別子を確認することができます。前のセクションの例はそのような機能を説明しないが、ICE-HIP-UDPモードを使用するときにも許可されます。
In ICE-HIP-UDP mode, a retransmission of a connectivity check SHOULD be sent with the same sequence identifier in the SEQ parameter. Some tested address candidates will never produce a working address pair and may thus cause retransmissions. Upon successful nomination of an address pair, a host SHOULD immediately stop sending such retransmissions.
ICE-HIP-UDPモードでは、接続性チェックの再送信は、SEQパラメータの同じシーケンス識別子で送信されるべきです。いくつかのテストされたアドレス候補は、作業アドレスペアを生成することは決してなく、したがって再送信を引き起こす可能性があります。アドレスペアの指名が成功すると、ホストは直ちにそのような再送信を送信するのをやめるべきです。
Full ICE procedures for prioritizing candidates, eliminating redundant candidates, forming checklists (including pruning), and triggered-check queues MUST be followed as specified in Section 6.1 of [RFC8445], with the exception being that the foundation, frozen candidates, and default candidates are not used. From the viewpoint of the ICE specification [RFC8445], the protocol specified in this document operates using a component ID of 1 on all candidates, and the foundation of all candidates is unique. This specification defines only "full ICE" mode, and the "lite ICE" is not supported. The reasoning behind the missing features is described in Appendix B.
候補者に優先順位を付けるためのフルアイス手順、冗長候補の排除、チェックリスト（剪定を含む）、およびトリガーチェックキューに従う必要があります。使用されていません。ICE仕様[RFC8445]の観点から、この文書で指定されたプロトコルはすべての候補者で1のコンポーネントIDを使用して動作し、すべての候補者の基礎は一意です。この仕様は「フルアイス」モードのみを定義し、「Lite Ice」はサポートされていません。欠けている機能の背後にある推論は付録Bに記載されています。
The connectivity check messages MUST be paced by the Ta 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 50 ms MUST be used.
接続性チェックメッセージは、セクション4.4で説明されているように、基本交換中にネゴシエートされたTA値によってペースされなければなりません。いずれかのホストが最小ペーシング値を発表していない場合、50ミリ秒の値を使用する必要があります。
Both hosts MUST form a priority ordered checklist and begin to check transactions every Ta milliseconds as long as the checks are running and there are candidate pairs whose tests have not started. The retransmission timeout (RTO) for the connectivity check UPDATE packets SHOULD be calculated as follows:
どちらのホストは優先順位順序付けされたチェックリストを作成し、チェックが実行されている限り、TAミリ秒ごとにトランザクションのチェックを開始し、テストが開始されていない候補ペアがある必要があります。接続性チェック更新パケットの再送信タイムアウト（RTO）は次のように計算する必要があります。
RTO = MAX (1000 ms, 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 [RFC8445] when there is only one checklist. A smaller value than 1000 ms for the RTO MUST NOT be used.
RTO式では、TAは接続チェックペーシングに使用される値で、Num-Waitingは「待機」状態のチェックリスト内のペア数であり、パスイン数は「IN-」のペア数です。進捗状況」チェックリストが1つしかない場合、これは[RFC8445]の式と同じです。RTOの場合は1000ミリ秒未満の値を使用してはいけません。
Each connectivity check request packet MUST contain a CANDIDATE_PRIORITY parameter (see Section 5.14) with the priority value that would be assigned to a peer-reflexive candidate if one was learned from the corresponding check. An UPDATE packet that acknowledges a connectivity check request MUST be sent from the same address that received the check and delivered to the same address where the check was received from. Each acknowledgment UPDATE packet MUST contain a MAPPED_ADDRESS parameter with the port, protocol, and IP address of the address where the connectivity check request was received from.
各接続性チェック要求パケットには、対応する小切手から学習された場合には、ピアリフレクティブ候補に割り当てられる優先順位の値がある候補者_priorityパラメータ（セクション5.14を参照）を含める必要があります。コネクティビティチェック要求を確認する更新パケットは、チェックを受け取った同じアドレスから送信され、チェックが受信された同じアドレスに配信される必要があります。各確認応答更新パケットには、接続性チェック要求が受信されたアドレスのポート、プロトコル、およびIPアドレスを持つmapped_addressパラメータが含まれている必要があります。
Following the ICE guidelines [RFC8445], it is RECOMMENDED to restrict the total number of connectivity checks to 100 for each host association. This can be achieved by limiting the connectivity checks to the 100 candidate pairs with the highest priority.
ICEガイドライン[RFC8445]に続いて、ホストアソシエーションごとに接続チェックの総数を100に制限することをお勧めします。これは、最大の優先順位を持つ100の候補ペアへの接続チェックを制限することによって達成できます。
The controlling agent may find multiple working candidate pairs. To conclude the connectivity checks, it SHOULD nominate the pair with the highest priority. The controlling agent MUST nominate a candidate pair essentially by repeating a connectivity check using an UPDATE message that contains a SEQ parameter (with a new sequence number), an ECHO_REQUEST_SIGNED parameter, the priority of the candidate in a CANDIDATE_PRIORITY parameter, and a NOMINATE parameter to signify conclusion of the connectivity checks. Since the nominated address pair has already been tested for reachability, the controlled host should be able to receive the message. Upon reception, the controlled host SHOULD select the nominated address pair. The response message MUST include a SEQ parameter with a new sequence identifier, acknowledgment of the sequence from the controlling host in an ACK parameter, a new ECHO_REQUEST_SIGNED parameter, an ECHO_RESPONSE_SIGNED parameter corresponding to the ECHO_REQUEST_SIGNED parameter from the controlling host, and the NOMINATE parameter. After sending this packet, the controlled host can create IPsec security associations using the nominated address candidate for delivering application payload to the controlling host. Since the message from the controlled host included a new sequence identifier echo request for the signature, the controlling host MUST acknowledge this with a new UPDATE message that includes an ACK and ECHO_RESPONSE_SIGNED parameters. After this final concluding message, the controlling host also can create IPsec security associations for delivering application payload to the controlled host.
制御剤は複数の作業候補ペアを見つけることができる。接続チェックを終了するには、最優先順位の高いペアを指名する必要があります。制御エージェントは、（新しいシーケンス番号を持つ新しいシーケンス番号を持つ）、ECHO_REQUEST_SIGNEDパラメータ、候補者の候補の優先順位、および命名パラメータを含む更新メッセージを使用して、基本的に候補ペアをノミネートする必要があります。接続チェックの締結を意味します。ノミネートアドレスペアは既に到達可能性をテストしているので、制御されたホストはメッセージを受信できるはずです。受信すると、制御されたホストはノミネートアドレスペアを選択する必要があります。応答メッセージは、新しいシーケンス識別子を持つseqパラメーター、ACKパラメーター、新しいECHO_REQUEST_SIGNEDパラメーター、制御ホストからのECHO_REQUEST_SIGNEDパラメーター、および推薦パラメーターのECHO_RESPONSE_SIGNEDパラメーターを含むSEQパラメーターを含める必要があります。このパケットを送信した後、制御されたホストは、制御ホストにアプリケーションペイロードを配信するための指名されたアドレス候補を使用してIPsecセキュリティアソシエーションを作成できます。制御されたホストからのメッセージがシグニチャに対する新しいシーケンス識別子エコー要求を含むので、制御ホストはACKとECHO_Response_signedパラメータを含む新しい更新メッセージでこれを確認する必要があります。この最終的な締め切りメッセージの後、制御ホストは、アプリケーションペイロードを制御ホストに配信するためのIPsecセキュリティアソシエーションを作成することもできます。
It is possible that packets are delayed by the network. Both hosts MUST continue to respond to any connectivity checks despite an address pair having been nominated.
パケットがネットワークによって遅延される可能性があります。どちらのホストは、アドレスペアがノミネートされているにもかかわらず、どちらの接続チェックにも応答し続ける必要があります。
If all the connectivity checks have 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トラフィックを互いに送信してはいけませんが、HIPパケットとベース交換に使用されるロケーターを使用して通信し続けることがあります。また、ホストは、Connectivity_Checks_Failed Notifyパケットを使用して失敗についてお互いに通知する必要があります（セクション5.10を参照）。
If the Responder has a fixed and publicly reachable IPv4 address and does not employ a Control Relay Server, the explicit NAT traversal mode negotiation MAY be omitted; thus, even the UDP-ENCAPSULATION mode does not have to be negotiated. In such a scenario, the Initiator sends an I1 message over UDP and the Responder responds with an R1 message over UDP without including any NAT traversal mode parameter. The rest of the base exchange follows the procedures defined in [RFC7401], except that the control and data plane use UDP encapsulation. Here, the use of UDP for NAT traversal is agreed upon implicitly. This way of operation is still subject to NAT timeouts, and the hosts MUST employ NAT keepalives as defined in Section 4.10.
レスポンダに固定され公開されているIPv4アドレスがある場合は、制御リレーサーバーを使用していない場合は、明示的なNATトラバーサルモードネゴシエーションを省略することができます。したがって、UDPカプセル化モードでもネゴシエーションする必要はありません。このようなシナリオでは、イニシエータはUDPを介してI1メッセージを送信し、レスポンダはNATトラバーサルモードパラメータを含まずにUDPよりもR1メッセージで応答します。残りの基本交換は、制御とデータプレーンがUDPカプセル化を使用することを除いて、[RFC7401]で定義されている手順に従います。ここでは、NATトラバースのUDPの使用は暗黙のうちに合意されています。この操作方法はまだNATタイムアウトの対象となり、ホストはセクション4.10で定義されているようにNATキープアライブを使用する必要があります。
When UDP-ENCAPSULATION mode is chosen either explicitly or implicitly, the connectivity checks as defined in this document MUST NOT be used. When hosts lose connectivity, they MUST instead utilize [RFC8046] or [RFC8047] procedures, but with the difference being that UDP-based tunneling MUST be employed for the entire lifetime of the corresponding HIP association.
UDPカプセル化モードが明示的または暗黙的に選択されると、この文書で定義されている接続チェックは使用してはいけません。ホストが接続を失うと、代わりに[RFC8046]または[RFC8047]の手順を使用する必要がありますが、違いは、対応するHIPアソシエーションの寿命全体にUDPベースのトンネリングを使用する必要があります。
It is possible to run a base exchange without any connectivity checks as defined in Legacy ICE-HIP (Section 4.8 of [RFC5770]). The procedure is also applicable in the context of this specification, so it is repeated here for completeness.
レガシーアイスヒップ（RFC5770]のセクション4.8）で定義されている接続チェックなしで基本交換を実行することが可能です。この仕様書の文脈にも適用可能であるため、完全性のためにここで繰り返されます。
In certain network environments, the connectivity checks can be omitted to reduce initial connection setup 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.
特定のネットワーク環境では、ベース交換が暗黙的な接続テスト自体として機能するため、接続セットアップ待ち時間を減らすために接続性チェックを省略できます。これが機能するために、イニシエータは、HIPおよびESPパケットをレスポンダのアドレスに送信された単にUDPカプセル化するだけでレスポンダに到達できなければなりません。この特定のシナリオの検出と設定は、慎重に計画されていない限り失敗しやすいです。
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 Control Relay Server in order to discover its address candidates, it MUST also include a LOCATOR_SET parameter encapsulated inside an ENCRYPTED parameter in an R1 message 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 Initiator MUST use the source address of the R1 as the Responder's preferred address.
そのようなシナリオでは、レスポンダは、R1パケット内のサポートされているモードの1つとしてUDPカプセル化NATトラバーサルモードを含み得る。レスポンダがそのアドレス候補を検出するために制御中継サーバに登録されている場合、レスポンダがUDPカプセル化されたESPを受信できる優先アドレスを含むR1メッセージ内の暗号化パラメータ内にカプセル化されたLOCATER_SETパラメータも含まなければなりません。そして股関節パケット。このロケータは「トランスポートアドレス」と型でなければならず、そのトラフィックタイプは「両方」でなければならず、「優先ビット」セットを設定する必要があります（表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 the connectivity checks defined in this document 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 address candidates, since connectivity checks defined in this document 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 according to the rules in Section 4.4 of [RFC7401].
イニシエータは、レスポンダがサポートされているモードでリストされていて、イニシエータがこのドキュメントで定義されている接続性チェックを使用して、より最適なパスを検索するための接続性チェックを使用したくない場合は、イニシエータがUDPカプセル化モードを選択できます。この場合、イニシエータは、NATトラバーサルモードパラメータでI2をNATトラバーサルモードパラメータに直接応答者の優先アドレス（R1内の優先ロケータまたはR1が優先ロケータがない場合はR1が受信されたアドレスに）送信します。R1で）。イニシエータはI2内のロケーターを含み得るが、この文書で定義された接続チェックはUDPカプセル化NATトラバーサルモードとの接続には使用されないので、それらはアドレス候補として取り出されてはならない。代わりに、R2とI2が正常に受信されて処理された場合、セキュリティアソシエーションを作成でき、[RFC7401]のセクション4.4の規則に従って基本交換が完了した後のホスト間でUDPカプセル化されたESPを交換できます。
The Control Relay Server can be used for discovering address candidates but it is not intended to be used for relaying end-host packets using the UDP-ENCAPSULATION NAT mode. Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected MUST NOT be sent via a Control Relay Server, 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モードを使用してエンドホストパケットを中継するために使用することを意図していません。UDPカプセル化NATトラバーサルモードを選択したI2パケットは、制御リレーサーバーを介して送信されてはならないので、レスポンダはそのようなI2パケットを拒否し、NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFYパケットを使用して返信します（セクション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 Control Relay Server, but it MUST NOT choose UDP-ENCAPSULATION NAT traversal mode for that I2.
Responderの優先アドレスに直接送信されたI2パケットに回答がない場合、イニシエータはControl Relayサーバーを介して別のI2を送信することができますが、そのI2に対してUDPカプセル化NATトラバーサルモードを選択しないでください。
4.7.3. Initiating a Base Exchange Both with and without UDP Encapsulation
4.7.3. UDPカプセル化の有無にかかわらず基本交換を開始する
It is possible to run a base exchange in parallel both with and without UDP encapsulation as defined in Legacy ICE-HIP (Section 4.9 of [RFC5770]). The procedure is also applicable in the context of this specification, so it is repeated here for completeness.
レガシーアイスヒップで定義されているように、UDPカプセル化の有無にかかわらず、基本交換を並行して実行することは可能です（[RFC5770]のセクション4.9）。この仕様書の文脈にも適用可能であるため、完全性のためにここで繰り返されます。
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カプセル化を伴うものであるレスポンダに送信します。イニシエータは、他のI1を送信する前にしばらく待つことができます。待機する時間とI1パケットを送信する順序は、ローカルポリシーに基づいて決定できます。再送信のために、手順が繰り返されます。
The I1 packet without UDP encapsulation may arrive directly, without passing a Control Relay Server, at the Responder. When this happens, the procedures in [RFC7401] 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 retransmissions of the R1 message received first MUST be ignored.
UDPカプセル化なしのI1パケットは、レスポンダで制御リレーサーバーを渡すことなく直接到着する可能性があります。このような場合、[RFC7401]の手順に残りの基本交換が続きます。イニシエータは、RESPONDEDから、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 [RFC8004].
UDPカプセル化なしのI1パケットは、ヒップ対応のミドルボックスにも到着する可能性があります。ミドルボックスがHIP Rendezvous Serverで、レスポンダがRendezvous Serviceに正常に登録されている場合、ミドルボックスは[RFC8004]の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 [RFC7401]. 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カプセル化なしでI2を送信し、選択されたNATトラバーサルモードなしでI2を送信することができます。応答者がUDPカプセル化なしでI2を受信し、NATトラバーサルモードなしでI2を受信すると、NATトラバーサルメカニズムが必要とされないと仮定する。[RFC7401]に示すように、パケット処理が行われます。イニシエータは、将来の使用のために、例えば、HIP協会の寿命の間にNATトラバースを使用させるモビリティまたはマルチホームイベントの場合には、NATトラバースモードを記憶することができる。
The same considerations with regard to sending control packets after the base exchange as described in Legacy ICE-HIP (Section 5.10 of [RFC5770]) also apply here, so they are repeated here for completeness.
レガシーアイスヒップ（[RFC5770]のセクション5.10）に記載されているように、基本交換後の制御パケットの送信についても同じ考察もここに適用されるので、それらは完全性のためにここで繰り返されます。
After the base exchange, the two 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 any Control Relay Servers. When a host does not receive acknowledgments, e.g., to an UPDATE or CLOSE packet after a timeout based on local policies, a host SHOULD resend the packet through the associated Data Relay Server of the peer (if the peer listed it in its LOCATOR_SET parameter in the base exchange according to the rules specified in Section 4.4.2 of [RFC7401]).
塩基交換後、2つのエンドホストは、制御パケットを介して制御パケットを送信することなく、データチャネルに対して確立されたトランスポートアドレスペアを使用して、互いに直接股関節制御パケットを送信することができる。ローカルポリシーに基づくタイムアウト後のタイムアウト後にホストが肯定応答を受信しない場合、ホストはピアの関連するデータリレーサーバを介してパケットを再送信する必要があります（ピアがそのlocator_setパラメータでそれをリストした場合[RFC7401]の4.4.2項で指定された規則に従って基本交換。
If a Control Relay Client sends a packet through a Control Relay Server, the Control Relay Client MUST always utilize the RELAY_TO parameter. The Control Relay Server SHOULD forward HIP control packets originating from a Control Relay Client to the address denoted in the RELAY_TO parameter. In the other direction, the Control Relay Server SHOULD forward HIP control packets to the Control Relay Clients and MUST add a RELAY_FROM parameter to the control packets it relays to the Control Relay Clients.
Control RelayクライアントがControl Relay Serverを介してパケットを送信する場合、Control Relayクライアントは常にRELAY_TOパラメータを使用する必要があります。制御リレーサーバは、制御リレークライアントから発信されたHIP制御パケットをRelay_toパラメータで示されているアドレスに転送する必要があります。他の方向に、制御リレーサーバは、HIP制御パケットを制御リレークライアントに転送する必要があり、制御リレークライアントにリレーをリレーする制御パケットにRelay_fromパラメータを追加する必要があります。
If the Control Relay Server is not willing or able to relay a HIP packet, it MAY notify the sender of the packet with a MESSAGE_NOT_RELAYED error notification (see Section 5.10).
コントロールリレーサーバーが喜んでいないか、HIPパケットを中継することができない場合、それはメッセージの送信者にMESSAGE_NOT_RELAYEDエラー通知を使用して通知されます（セクション5.10を参照）。
A host may move after base exchange and connectivity checks. Mobility extensions for HIP [RFC8046] define handover procedures without NATs. In this section, we define how two hosts interact with handover procedures in scenarios involving NATs. The specified extensions define only simple mobility using a pair of security associations, and multihoming extensions are left to be defined in later specifications. The procedures in this section offer the same functionality as "ICE restart" specified in [RFC8445]. The example described in this section shows only a Control Relay Server for the peer host for the sake of simplicity, but the mobile host may also have a Control Relay Server.
ホストは、基本交換と接続性チェックの後に移動することがあります。HIP [RFC8046]のMobility Extensions NATのないハンドオーバ手順を定義します。このセクションでは、2つのホストがNATを含むシナリオのハンドオーバ手順とどのように対話するかを定義します。指定された拡張機能は、一対のセキュリティアソシエーションを使用して単純なモビリティのみを定義し、マルチホーム拡張は後の仕様で定義されています。このセクションの手順では、[RFC8445]に指定されている「ICE RESTART」と同じ機能があります。このセクションに記載されている例では、簡単にするためにピアホスト用のコントロール中継サーバのみを示していますが、モバイルホストには制御リレーサーバーもあります。
The assumption here is that the two hosts have successfully negotiated and chosen the ICE-HIP-UDP mode during the base exchange as defined in Section 4.3. The Initiator of the base exchange MUST store information that it was the controlling host during the base exchange. Similarly, the Responder MUST store information that it was the controlled host during the base exchange.
ここでの仮定は、セクション4.3で定義されている基本交換中に、2つのホストがICE-HIP-UDPモードを正常にネゴシエートして選択したことです。基本交換のイニシエータは、基本交換中に制御ホストである情報を格納する必要があります。同様に、レスポンダは、基本交換中に制御ホストである情報を保存しなければなりません。
Prior to starting the handover procedures with all peer hosts, the mobile host SHOULD first send its locators in UPDATE messages to its Control and Data Relay Servers if it has registered to such. It SHOULD wait for all of them to respond for a configurable time, by default two minutes, and then continue with the handover procedure without information from the Relay Server that did not respond. As defined in Section 4.1, a response message from a Control Relay Server includes a REG_FROM parameter that describes the server-reflexive candidate of the mobile host to be used in the candidate exchange during the handover. Similarly, an UPDATE to a Data Relay Server is necessary to make sure the Data Relay Server can forward data to the correct IP address after a handover.
すべてのピアホストを使用してハンドオーバ手順を開始する前に、モバイルホストはまずそのロケーターをそのように登録されている場合はその制御およびデータリレーサーバーにそのコントロールおよびデータリレーサーバーに送信する必要があります。そのすべての時間がデフォルトで2分間応答するのを待つ必要があり、応答しなかった中継サーバーからの情報なしでハンドオーバ手順を続行します。セクション4.1で定義されているように、制御リレーサーバからの応答メッセージは、ハンドオーバ中に候補交換に使用される移動ホストのサーバ再帰候補を記述するREG_FROMパラメータを含む。同様に、データ中継サーバがハンドオーバ後にデータを正しいIPアドレスに転送できるようにするために、データリレーサーバへの更新が必要である。
The mobility extensions for NAT traversal are illustrated in Figure 6. The mobile host is the host that has changed its locators, and the peer host is the host it has a host association with. The mobile host may have multiple peers, and it repeats the process with all of its peers. In the figure, the Control Relay Server belongs to the peer host, i.e., the peer host is a Control Relay Client for the Control Relay Server. Note that the figure corresponds to figure 3 in [RFC8046], but the difference is that the main UPDATE procedure is carried over the relay and the connectivity is tested separately. Next, we describe the procedure of that figure in detail.
NATトラバーサルのモビリティ拡張機能を図6に示します。モバイルホストはロケータを変更したホストであり、ピアホストはホストアソシエーションがあるホストです。モバイルホストには複数のピアがある可能性があり、そのピア全体でプロセスを繰り返すことができます。図中、制御中継サーバはピアホスト、すなわちピアホストは制御リレーサーバ用の制御リレークライアントである。図は[RFC8046]の図3に対応していますが、その違いは、メインアップデート手順がリレーを介して運ばれ、接続性が別々にテストされることです。次に、その図の詳細について説明します。
Mobile Host Control Relay Server Peer Host
| 1. UDP(UPDATE(ESP_INFO, | |
| ENC(LOC_SET), SEQ)) | |
+--------------------------------->| 2. UDP(UPDATE(ESP_INFO, |
| | ENC(LOC_SET), SEQ, |
| | RELAY_FROM)) |
| +------------------------------->|
| | |
| | 3. UDP(UPDATE(ESP_INFO, SEQ, |
| | ACK, ECHO_REQ_SIGN, |
| | RELAY_TO)) |
| 4. UDP(UPDATE(ESP_INFO, SEQ, |<-------------------------------+
| ACK, ECHO_REQ_SIGN, | |
| RELAY_TO)) | |
|<---------------------------------+ |
| | |
| 5. UDP(UPDATE(ACK, | |
| ECHO_RESP_SIGNED)) | |
+--------------------------------->| 6. UDP(UPDATE(ACK, |
| | ECHO_RESP_SIGNED, |
| | RELAY_FROM)) |
| +------------------------------->|
| | |
| 7. connectivity checks over UDP |
+<----------------------------------------------------------------->+
| | |
| 8. ESP data over UDP |
+<----------------------------------------------------------------->+
| | |
Figure 6: HIP UPDATE Procedure
図6：HIP更新手順
In step 1, the mobile host has changed location and sends a location update to its peer through the Control Relay Server of the peer. It sends an UPDATE packet with the source HIT belonging to itself and destination HIT belonging to the peer host. In the packet, the source IP address belongs to the mobile host and the destination to the Control Relay Server. The packet contains an ESP_INFO parameter where, in this case, the OLD SPI and NEW SPI parameters both contain the pre-existing incoming SPI. The packet also contains the locators of the mobile host in a LOCATOR_SET parameter, encapsulated inside an ENCRYPTED parameter (see Sections 5.2.18 and 6.5 in [RFC7401] for details on the ENCRYPTED parameter). The packet also contains a SEQ number to be acknowledged by the peer. As specified in [RFC8046], the packet may also include a HOST_ID (for middlebox inspection) and DIFFIE_HELLMAN parameter for rekeying.
ステップ1では、モバイルホストは位置を変更し、ピアの制御リレーサーバを介してそのピアに位置更新を送信する。それは、それ自体に属するソースヒットとピアホストに属する宛先のヒットを含む更新パケットを送信します。パケットでは、送信元IPアドレスはモバイルホストとコントロールリレーサーバへの宛先に属します。パケットには、esp_infoパラメータが含まれています。この場合、古いSPIパラメータと新しいSPIパラメータは両方とも既存の受信SPIを含みます。このパケットには、暗号化されたパラメータ内でカプセル化されたLOCATER_SETパラメータ内のモバイルホストのロケータも含まれています（暗号化されたパラメータの詳細は、[RFC7401]のセクション5.2.18と6.5を参照）。パケットには、ピアによって確認されるSEQ番号も含まれています。[RFC8046]で指定されているように、パケットは、host_id（ミドルボックス検査用）とRekingのためのdifie_hellmanパラメータを含んでもよい。
In step 2, the Control Relay Server receives the UPDATE packet and forwards it to the peer host (i.e., Control Relay Client). The Control Relay Server rewrites the destination IP address and appends a RELAY_FROM parameter to the message.
ステップ2において、制御リレーサーバは更新パケットを受信し、それをピアホスト（すなわち制御リレークライアント）に転送する。制御中継サーバは、宛先IPアドレスを書き換えて、Relay_fromパラメータをメッセージに追加する。
In step 3, the peer host receives the UPDATE packet, processes it, and responds with another UPDATE message. The message is destined to the HIT of the mobile host and to the IP address of the Control Relay Server. The message includes an ESP_INFO parameter where, in this case, the OLD SPI and NEW SPI parameters both contain the pre-existing incoming SPI. The peer includes a new SEQ and ECHO_REQUEST_SIGNED parameter to be acknowledged by the mobile host. The message acknowledges the SEQ parameter of the earlier message with an ACK parameter. The RELAY_TO parameter specifies the address of the mobile host where the Control Relay Server should forward the message.
ステップ3において、ピアホストは更新パケットを受信し、それを処理し、そして別の更新メッセージで応答する。メッセージは、モバイルホストのヒットと制御リレーサーバのIPアドレスを推測しています。メッセージには、esp_infoパラメータが含まれています。この場合、古いSPIパラメータと新しいSPIパラメータは両方とも既存の受信SPIを含みます。ピアは、モバイルホストによって確認される新しいSEQとECHO_REQUEST_SIGNEDパラメータを含みます。メッセージは、ackパラメータを使用して以前のメッセージのseqパラメータを確認します。Relay_toパラメータは、コントロールリレーサーバーがメッセージを転送するモバイルホストのアドレスを指定します。
In step 4, the Control Relay Server receives the message, rewrites the destination IP address and UDP port according to the RELAY_TO parameter, and then forwards the modified message to the mobile host.
ステップ4において、制御中継サーバはメッセージを受信し、relay_toパラメータに従って宛先IPアドレスおよびUDPポートを書き換えてから、変更したメッセージをモバイルホストに転送する。
In step 5, the mobile host receives the UPDATE packet and processes it. The mobile host concludes the handover procedure by acknowledging the received SEQ parameter with an ACK parameter and the ECHO_REQUEST_SIGNED parameter with an ECHO_RESPONSE_SIGNED parameter. The mobile host sends the packet to the HIT of the peer and to the address of the HIP relay. The mobile host can start connectivity checks after this packet.
ステップ5において、モバイルホストは更新パケットを受信し、それを処理する。モバイルホストは、受信したSEQパラメータをACKパラメータとECHO_REPONSE_SIGNEDパラメータを使用して確認することによって、ハンドオーバ手順を終了します。モバイルホストはパケットをピアのヒットおよびHIPリレーのアドレスに送信します。モバイルホストはこのパケットの後に接続チェックを開始できます。
In step 6, the HIP relay receives the UPDATE packet and forwards it to the peer host (i.e., Relay Client). The HIP relay rewrites the destination IP address and port, and then appends a RELAY_FROM parameter to the message. When the peer host receives this concluding UPDATE packet, it can initiate the connectivity checks.
ステップ6において、HIPリレーは更新パケットを受信し、それをピアホスト（すなわち中継クライアント）に転送する。HIPリレーは宛先IPアドレスとポートを書き換えてから、メッセージにRelay_fromパラメータを追加します。ピアホストがこの終了更新パケットを受信すると、接続チェックを開始できます。
In step 7, the two hosts test for connectivity across NATs according to procedures described in Section 4.6. The original Initiator of the communications is the controlling host and the original Responder is the controlled host.
ステップ7において、2つのホストは、セクション4.6に記載されている手順に従って、NAT間の接続性をテストする。通信の元のイニシエータは制御ホストであり、元のレスポンダは制御ホストです。
In step 8, the connectivity checks are successfully completed and the controlling host has nominated one address pair to be used. The hosts set up security associations to deliver the application payload.
ステップ8では、接続性チェックは正常に完了し、制御ホストは1つのアドレスペアを使用するように指名されている。ホストは、アプリケーションペイロードを配信するためにセキュリティアソシエーションを設定します。
It is worth noting that the Control and Data Relay Client do not have to reregister for the related services after a handover. However, if a Data Relay Client has registered a relayed address candidate from a Data Relay Server, the Data Relay Client MUST reactivate the address before the connectivity checks by sending an UPDATE message containing the PEER_PERMISSION parameter as described in Section 4.12.1. Otherwise, the Data Relay Server drops ESP packets sent to the relayed address.
コントロールとデータリレークライアントがハンドオーバ後に関連サービスの再登録を受ける必要がないことは注目に値します。ただし、データリレークライアントがデータリレーサーバーから中継アドレス候補を登録している場合、データリレークライアントは、セクション4.12.1で説明されているようにPeer_Permissionパラメータを含む更新メッセージを送信することによって、接続がチェックされる前にアドレスを再アクティブにする必要があります。それ以外の場合、データリレーサーバーは、中継アドレスに送信されたESPパケットをドロップします。
In the so-called "double jump" or simultaneous mobility scenario, both peers change their location simultaneously. In such a case, both peers trigger the procedure described earlier in this section at the same time. In other words, both of the communicating hosts send an UPDATE packet carrying locators at the same time or with some delay. When the locators are exchanged almost simultaneously (reliably via Control Relay Servers), the two hosts can continue with connectivity checks after both have completed separately the steps in Figure 6. The problematic case occurs when one of the hosts (referred to here as host "M") moves later during the connectivity checks. In such a case, host M sends a locator to the peer, which is in the middle of connectivity checks. Upon receiving the UPDATE message, the peer responds with an UPDATE with ECHO_REQ_SIGN as described in step 3 in Figure 6. Upon receiving the valid response from host M as described in step 6, the peer host MUST restart the connectivity checks with host M. This way, both hosts start the connectivity checks roughly in a synchronized way. It is also important that the peer host does not restart the connectivity checks until step 6 is successfully completed, because the UPDATE message carrying locators in step 1 could be replayed by an attacker.
いわゆる「ダブルジャンプ」または同時モビリティシナリオでは、両方のピアがその場所を同時に変更します。そのような場合、両方のピアはこのセクションの前述の手順を同時にトリガします。言い換えれば、両方の通信ホストは、ロケータを同時にまたはある程度の遅延させる更新パケットを送信する。ロケータがほぼ同時に交換されると、2つのホストは2つのホストが図6の手順を別々に完了した後に接続チェックを続けることができます。問題のある場合は、ホストの1つ（ホストと参照）が発生したときに発生します。 M」）接続チェック中に後で移動します。そのような場合、ホストMはロケータをピアに送信します。これは接続性チェックの途中です。更新メッセージを受信すると、ピアは、図6のステップ3で説明されているように、ECHO_REQ_SIGNを使用して更新して応答します。ステップ6で説明したようにホストMから有効な応答を受信すると、ピアホストはホストMと接続性チェックを再開する必要があります。 WAY、両者は両方のホストが同期した方法で接続チェックを開始します。ステップ1でロケータを搬送するアップデートメッセージを攻撃者によって再生することができるので、ピアホストが接続性チェックを再開しないことも重要である。
To prevent NAT states from expiring, communicating hosts MUST send periodic keepalives to other hosts with which they have established a HIP association every 15 seconds (the so-called Tr value in ICE). Other values MAY be used, but a Tr value smaller than 15 seconds MUST NOT be used. Both a Control/Data Relay Client and Control/Data Relay Server, as well as two peers employing UDP-ENCAPSULATION or ICE-HIP-UDP mode, SHOULD send HIP NOTIFY packets unless they have exchanged some other traffic over the used UDP ports. However, the Data Relay Client and Data Relay Server MUST employ only HIP NOTIFY packets in order to keep the server-reflexive candidates alive. The keepalive message encoding format is defined in Section 5.3. If the base exchange or mobility handover procedure occurs during an extremely slow path, a host (with a HIP association with the peer) MAY also send HIP NOTIFY packets every 15 seconds to keep the path active with the recipient.
NAT状態が期限切れになるのを防ぐために、通信ホストは、15秒ごとにHIPアソシエーションを確立した他のホストに定期的なキープアライブを送信する必要があります（いわゆるTR値）。他の値を使用することができるが、15秒未満のTR値を使用してはいけません。コントロール/データリレークライアントおよびコントロール/データリレーサーバーの両方、およびUDPカプセル化またはICE-HIP-UDPモードを使用する2つのピアは、使用されているUDPポートを介して他のトラフィックを交換していない限り、HIP NOTIFYパケットを送信する必要があります。ただし、データリレークライアントとデータリレーサーバーは、サーバー再帰候補を生き続けるために、HIP NOTIFYパケットのみを使用する必要があります。キープアライブメッセージエンコーディング形式はセクション5.3で定義されています。ベース交換またはモビリティハンドオーバ手順が極めて低速経路の間に発生する場合、（ピアとのHIP関連付けを有する）ホストは15秒ごとにHIP通知パケットを送信して、パスを受信者と有効にすることができる。
The two-way procedure for closing a HIP association and the related security associations is defined in [RFC7401]. One host initiates the procedure by sending a CLOSE message and the recipient confirms it with CLOSE_ACK. All packets are protected using HMACs and signatures, and the CLOSE messages include an ECHO_REQUEST_SIGNED parameter to protect against replay attacks.
HIPアソシエーションを閉じるための双方向手順と関連セキュリティアソシエーションは[RFC7401]で定義されています。1つのホストがクローズメッセージを送信することによってプロシージャを開始し、受信者はCLOSE_ACKでそれを確認します。すべてのパケットはHMACとシグネチャを使用して保護されており、クローズメッセージには再生攻撃から保護するためのECHO_REQUEST_SIGNEDパラメータが含まれています。
The same procedure for closing HIP associations also applies here, but the messaging occurs using the UDP-encapsulated tunnel that the two hosts employ. A host sending the CLOSE message SHOULD first send the message over a direct link. After a number of retransmissions, it MUST send over a Control Relay Server of the recipient if one exists. The host receiving the CLOSE message directly without a Control Relay Server SHOULD respond directly. If the CLOSE message came via a Control Relay Server, the host SHOULD respond using the same Control Relay Server.
HIPアソシエーションを閉じるのと同じ手順もここにも適用されますが、メッセージングは2つのホストが採用したUDPカプセル化トンネルを使用して行われます。クローズメッセージを送信するホストは、最初に直接リンクを介してメッセージを送信する必要があります。多数の再送信の後、それは存在する場合、受信者の制御中継サーバを介して送信する必要があります。コントロールリレーサーバーなしで直接クローズメッセージを受信したホストは直接応答する必要があります。CLOSEメッセージがControl Relay Serverを介して来た場合、ホストは同じコントロールリレーサーバーを使用して応答する必要があります。
The Data Relay Server uses a similar permission model as a TURN server: before the Data Relay Server forwards any ESP data packets from a peer to a Data Relay Client (or the other direction), the client MUST set a permission for the peer's address. The permissions also install a forwarding rule for each direction, similar to TURN's channels, based on the Security Parameter Index (SPI) values in the ESP packets.
データリレーサーバーは、ターンサーバーと同様の権限モデルを使用します。データリレーサーバがピアからデータリレークライアント（または他の方向）に任意のESPデータパケットを転送する前に、クライアントはピアのアドレスの許可を設定する必要があります。権限はまた、ESPパケットのセキュリティパラメータインデックス（SPI）値に基づいて、ターンのチャネルと同様に、各方向の転送規則をインストールします。
Permissions are not required for HIP control packets. However, if a relayed address (as conveyed in the RELAYED_ADDRESS parameter from the Data Relay Server) is selected to be used for data, the Control Relay Client MUST send an UPDATE message to the Data Relay Server containing a PEER_PERMISSION parameter (see Section 5.13) with the following information: the UDP port and address for the server-reflexive address, the UDP port and address of the peer, and the inbound and outbound SPIs used for ESP. The packet MUST be sent to the same UDP tunnel the Client employed in the base exchange to contact the Server (i.e., not to the port occupied by the server-reflexive candidate). To avoid packet dropping of ESP packets, the Control Relay Client SHOULD send the PEER_PERMISSION parameter before connectivity checks both in the case of base exchange and a mobility handover. It is worth noting that the UPDATE message includes a SEQ parameter (as specified in [RFC7401]) that the Data Relay Server must acknowledge, so that the Control Relay Client can resend the message with the PEER_PERMISSION parameter if it gets lost.
HIP制御パケットには許可は必要ありません。ただし、（データリレーサーバーからRelayed_Addressパラメータで伝送されている）中継アドレスがデータに使用されるように選択されている場合、Control RelayクライアントはPeer_permissionパラメータを含むデータリレーサーバーに更新メッセージを送信する必要があります（セクション5.13を参照）。以下の情報を使用すると、サーバーリフレクサアドレス、UDPポート、ピアのアドレス、およびESPに使用されているインバウンドおよびアウトバウンドSPIのUDPポートとアドレス。サーバに連絡するために（すなわち、サーバ再帰候補によって占有されているポートにはない）、パケットを同じUDPトンネルに送信する必要があります（すなわち、サーバ再帰候補によって占有されるポートにはない）。 ESPパケットのパケットドロップを回避するために、Control Relayクライアントは、基本交換の場合とモビリティハンドオーバの両方で接続チェックをチェックする前にPEER_PERMISSIONパラメータを送信する必要があります。更新メッセージにデータリレーサーバーが確認しなければならないSEQパラメーター（RFC7401]で指定されているように）が含まれていることは注目に値します。
When a Data Relay Server receives an UPDATE with a PEER_PERMISSION parameter, it MUST check if the sender of the UPDATE is registered for data-relaying service, and drop the UPDATE if the host was not registered. If the host was registered, the Data Relay Server checks if there is a permission with matching information (protocol, addresses, ports, and SPI values). If there is no such permission, a new permission MUST be created and its lifetime MUST be set to 5 minutes. If an identical permission already existed, it MUST be refreshed by setting the lifetime to 5 minutes. A Data Relay Client SHOULD refresh permissions 1 minute before the expiration when the permission is still needed.
データ中継サーバがPeer_Permissionパラメータを使用して更新を受信すると、更新の送信者がデータ中継サービスに登録されているかどうかを確認し、ホストが登録されていない場合は更新をドロップする必要があります。ホストが登録されている場合、データリレーサーバーは、一致する情報（プロトコル、アドレス、ポート、およびSPI値）の許可があるかどうかを確認します。そのような権限がない場合は、新しい権限を作成する必要があり、その有効期間を5分に設定する必要があります。同一の許可が既に存在している場合は、寿命を5分に設定することで更新する必要があります。データリレークライアントは、許可が依然として必要な場合の有効期限の1分前にアクセス許可を更新する必要があります。
When a Data Relay Server receives an UPDATE from a registered client but without a PEER_PERMISSION parameter and with a new locator set, the Data Relay Server can assume that the mobile host has changed its location and is thus not reachable in its previous location. In such an event, the Data Relay Server SHOULD deactivate the permission and stop relaying data plane traffic to the client.
データ中継サーバが登録されたクライアントからの更新を受信すると、PEAR_Permissionパラメータがなく、新しいロケータセットがない場合、データ中継サーバは、モバイルホストがその場所を変更して以前の場所で到達できないと仮定することができる。そのような場合、データ中継サーバは許可を無効にし、データプレーントラフィックをクライアントに中継するのを停止する必要があります。
The relayed address MUST be activated with the PEER_PERMISSION parameter both after a base exchange and after a handover procedure with another ICE-HIP-UDP-capable host. Unless activated, the Data Relay Server MUST drop all ESP packets. It is worth noting that a Data Relay Client does not have to renew its registration upon a change of location UPDATE, but only when the lifetime of the registration is close to end.
中継されたアドレスは、基本交換後および他のICE-HIP-UDP対応ホストを使用したハンドオーバ手順の後に、PEAR_PERMISSIONパラメータでアクティブ化する必要があります。有効にしない限り、データリレーサーバーはすべてのESPパケットを削除する必要があります。データリレークライアントがロケーション更新の変更時に登録を更新する必要がないことは注目に値しますが、登録の存続期間が終了した場合に限ります。
When a Data Relay Server accepts to relay UDP-encapsulated ESP between a Data Relay Client and its peer, the Data Relay Server opens a UDP port (relayed address) for this purpose as described in Section 4.1. This port can be used for also delivering control packets because connectivity checks also cover the path through the Data Relay Server. If the Data Relay Server receives a UDP-encapsulated HIP control packet on that port, it MUST forward the packet to the Data Relay Client and add a RELAY_FROM parameter to the packet as if the Data Relay Server were acting as a Control Relay Server. When the Data Relay Client replies to a control packet with a RELAY_FROM parameter via its Data Relay Server, the Data Relay Client MUST add a RELAY_TO parameter containing the peer's address and use the address of its Data Relay Server as the destination address. Further, the Data Relay Server MUST send this packet to the peer's address from the relayed address.
データリレーサーバーがデータリレークライアントとそのピア間でUDPカプセル化されたESPを中継するように受け入れると、データリレーサーバーはセクション4.1で説明されているように、この目的のためにUDPポート（中継アドレス）を開きます。このポートは、コネクティビティチェックもデータリレーサーバーを介したパスを覆うため、制御パケットを配信するために使用できます。データ中継サーバがそのポート上のUDPカプセル化されたHIP制御パケットを受信した場合、パケットをデータリレークライアントに転送し、データ中継サーバが制御リレーサーバとして機能していたかのように、パケットにRelay_fromパラメータを追加する必要があります。データ中継クライアントがそのデータ中継サーバを介してRELAY_FROMパラメータを含む制御パケットに応答すると、データリレークライアントはピアのアドレスを含むRelay_toパラメータを追加し、そのデータ中継サーバのアドレスを宛先アドレスとして使用する必要があります。さらに、データリレーサーバは、このパケットを中継アドレスからピアのアドレスに送信する必要があります。
If the Data Relay Server receives a UDP packet that is not a HIP control packet to the relayed address, it MUST check if it has a permission set for the peer the packet is arriving from (i.e., the sender's address and SPI value matches to an installed permission). If permissions are set, the Data Relay Server MUST forward the packet to the Data Relay Client that created the permission. The Data Relay Server MUST also implement the similar checks for the reverse direction (i.e., ESP packets from the Data Relay Client to the peer). Packets without a permission MUST be dropped silently.
データ中継サーバが中継アドレスにHIP制御パケットではないUDPパケットを受信した場合は、パケットが到着しているピアの許可セットがあるかどうかを確認する必要があります（つまり、送信者のアドレスとSPIの値は、インストール許可）。権限が設定されている場合、データリレーサーバーはパケットを許可を作成したデータリレークライアントに転送する必要があります。データ中継サーバはまた、逆方向（すなわち、データ中継クライアントからのESPパケットへの同様のチェック）についても同様のチェックを実施する必要があります。許可なしのパケットは静かにドロップされなければなりません。
From the viewpoint of a host, its remote peers can have overlapping inbound SPI numbers because the IPsec also uses the destination IP address to index the remote peer host. However, a Data Relay Server can represent multiple remote peers, thus masquerading the actual destination. Since a Data Relay Server may have to deal with a multitude of Relay Clients and their peers, a Data Relay Server may experience collisions in the SPI namespace, thus being unable to forward datagrams to the correct destination. Since the SPI space is 32 bits and the SPI values should be random, the probability for a conflicting SPI value is fairly small but could occur on a busy Data Relay Server. The two problematic cases are described in this section.
ホストの観点からは、IPsecはリモートピアホストにインデックスを索引付けするために宛先IPアドレスも使用するため、リモートピアはインバウンドのインバウンドSPI番号を重ねて持つことができます。ただし、データリレーサーバーは複数のリモートピアを表すことができ、実際の宛先を不振にできます。データ中継サーバは、多数のリレークライアントとそれらのピアに対処しなければならないため、データ中継サーバはSPIネームスペース内の衝突を経験することがあり、したがってデータグラムを正しい宛先に転送することができない。SPIスペースは32ビットで、SPI値はランダムになる必要があります。矛盾するSPI値の確率はかなり小さいが、ビジーデータ中継サーバで発生する可能性があります。このセクションでは、2つの問題のある場合が説明されています。
In the first scenario, the SPI collision problem occurs if two hosts have registered to the same Data Relay Server and a third host initiates base exchange with both of them. Here, the two Responders (i.e., Data Relay Clients) claim the same inbound SPI number with the same Initiator (peer). However, in this case, the Data Relay Server has allocated separate UDP ports for the two Data Relay Clients acting now as Responders (as recommended in Section 7.5). When the third host sends an ESP packet, the Data Relay Server is able to forward the packet to the correct Data Relay Client because the destination UDP port is different for each of the clients.
最初のシナリオでは、2つのホストが同じデータ中継サーバに登録されている場合、SPI衝突問題が発生し、3番目のホストが両方とも基本交換を開始します。ここで、2つの応答者（すなわち、データリレークライアント）は、同じイニシエータ（ピア）を有する同じインバウンドSPI番号を主張する。ただし、この場合、Data Relay Serverは、現在、レスポンダとして機能する2つのデータ中継クライアントに対して別々のUDPポートを割り当てました（7.5項で推奨されているように）。3番目のホストがESPパケットを送信すると、データ中継サーバは各クライアントに対して宛先UDPポートが異なるため、パケットを正しいデータリレークライアントに転送することができます。
In the second scenario, an SPI collision may occur when two Initiators run a base exchange to the same Responder (i.e., Data Relay Client), and both of the Initiators claim the same inbound SPI at the Data Relay Server using the PEER_PERMISSION parameter. In this case, the Data Relay Server cannot disambiguate the correct destination of an ESP packet originating from the Data Relay Client because the SPI could belong to either of the peers (and the destination IP and UDP port belonging to the Data Relay Server are not unique either). The recommended way and a contingency plan to solve this issue are described below.
2番目のシナリオでは、2つのイニシエータが同じレスポンダ（すなわちデータリレークライアント）への基本交換を実行し、両者の両方がPEAR_PERMISSIONパラメータを使用して同じインバウンドSPIをクローニングすると、SPI衝突が発生する可能性があります。この場合、SPIはどちらのピアに属している可能性があるため、データリレーサーバはデータリレークライアントから発信されたESPパケットの正しい宛先を曖昧にすることはできません（およびデータリレーサーバーに属する宛先IPとUDPポートは一意ではありません。どちらか）この問題を解決するための推奨される方法と緊急計画については後述する。
The recommend way to mitigate the problem is as follows. For each new HIP association, a Data Relay Client acting as a Responder SHOULD register a new server-reflexive candidate as described in Section 4.2. Similarly, the Data Relay Server SHOULD NOT reuse the port numbers as described in Section 7.5. This way, each server-reflexive candidate for the Data Relay Client has a separate UDP port that the Data Relay Server can use to disambiguate packet destinations in case of SPI collisions.
問題を軽減するための方法は次のとおりです。新しいHIPアソシエーションごとに、レスポンダとして機能するデータリレークライアントは、セクション4.2で説明されているように新しいサーバーリフレクサ候補を登録する必要があります。同様に、データリレーサーバーはセクション7.5で説明されているようにポート番号を再利用しないでください。このようにして、データリレークライアントの各サーバ再帰候補は、SPI衝突の場合には、データ中継サーバがパケット宛先を曖昧させるために使用できる別個のUDPポートを有する。
When the Data Relay Client is not registering or failed to register a new relay candidate for a new peer, the Data Relay Client MUST follow a contingency plan as follows. Upon receiving an I2 with a colliding SPI, the Data Relay Client acting as the Responder MUST NOT include the relayed address candidate in the R2 message because the Data Relay Server would not be able to demultiplex the related ESP packet to the correct Initiator. The same also applies to the handover procedures; the Data Relay Client MUST NOT include the relayed address candidate when sending its new locator set in an UPDATE to its peer if it would cause an SPI conflict with another peer.
データリレークライアントが新しいピアの新しい中継候補を登録または登録できない場合、データリレークライアントは次のように緊急プランに従わなければなりません。衝突SPIを搭載したI2を受信すると、データリレーサーバが関連ESPパケットを正しいイニシエータに分離することができないので、レスポンダとしてのデータリレークライアントはR2メッセージ内の中継アドレス候補を含めてはならない。ハンドオーバ手順についても同様です。データリレークライアントは、新しいロケータセットをその中継されていない場合は、その新しいロケータをそのピアに送信しても、他のピアとSPIが競合する場合には必要ありません。
The following subsections define the parameter and packet encodings for the HIP and ESP packets. All values MUST be in network byte order.
次のサブセクションでは、HIPパケットとESPパケットのパラメータエンコードとパケットエンコードを定義します。すべての値はネットワークバイト順になければなりません。
It is worth noting that all of the parameters are shown for the sake of completeness even though they are specified already in Legacy ICE-HIP [RFC5770]. New parameters are explicitly described as new.
レガシーアイスヒップ[RFC5770]にすでに指定されていても、すべてのパラメータが完全性のために表示されていることは注目に値します。新しいパラメータは新規として明示的に説明されています。
Figure 7 illustrates the packet format for UDP-encapsulated HIP. The format is identical to Legacy ICE-HIP [RFC5770].
図7は、UDPカプセル化HIPのパケットフォーマットを示しています。フォーマットはレガシーアイスヒップ[RFC5770]と同じです。
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 7: Format of UDP-Encapsulated HIP Control Packets
図7：UDPカプセル化股関節制御パケットの形式
HIP control packets are encapsulated in UDP packets as defined in Section 2.2 of [RFC3948], "IKE Header Format for Port 4500", except that a different port number is used. Figure 7 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 [RFC7401] 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 [RFC7401] includes the IP addresses in the checksum calculation. The NATs that are unaware of HIP cannot recompute the HIP checksum after changing IP addresses.
HIP制御パケットは、別のポート番号が使用されていることを除いて、[RFC3948]のセクション2.2で定義されているUDPパケットにカプセル化されています。図7はカプセル化を示しています。UDPヘッダーの後には、HIP制御パケットをESPパケットから区別するために使用できる32のゼロビットが続きます。HIPヘッダーとパラメータは、HIPヘッダーチェックサムがゼロでなければならないことを除いて、[RFC7401]の規則に従います。HIPヘッダチェックサムは2つの理由でゼロです。まず、UDPヘッダーはすでにチェックサムを含んでいます。次に、[RFC7401]のチェックサム定義には、チェックサム計算内のIPアドレスが含まれています。HIPを認識していないNATは、IPアドレスを変更した後にHIPチェックサムを再計算することはできません。
A Control/Data Relay Server or a non-relay Responder 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カプセル化されたHIP制御パケットのためにUDPポート10500で待機する必要があります。他のポート番号が使用されている場合は、潜在的なイニシエーターによって知られている必要があります。
UDP encapsulation of HIP packets reduces the Maximum Transmission Unit (MTU) size of the control plane by 12 bytes (8-byte UDP header plus 4-byte zero SPI marker), and the data plane by 8 bytes. Additional HIP relay parameters, such as RELAY_HMAC, RELAY_UDP_HIP, RELAY_UDP_ESP, etc., further increase the size of certain HIP packets. In regard to MTU, the following aspects need to be considered in an implementation:
HIPパケットのUDPカプセル化は、制御プレーンの最大伝送ユニット（MTU）サイズ（MTU）サイズを12バイト（8バイトのUDPヘッダと4バイトのゼロSPIマーカー）、およびデータプレーンを8バイト）に短縮されます。Relay_HMAC、Relay_UDP_EP、Relay_UDP_ESPなどの追加のHIPリレーパラメータは、特定のHIPパケットのサイズをさらに増やします。MTUに関しては、以下の側面を実装で考慮する必要があります。
* A HIP host SHOULD implement ICMP message handling to support Path MTU Discovery (PMTUD) as described in [RFC1191] and [RFC8201].
* HIPホストは、[RFC1191]と[RFC8201]で説明されているように、パスMTU検出（PMTUD）をサポートするためのICMPメッセージ処理を実装する必要があります。
* Reliance on IP fragmentation is unlikely to be a viable strategy through NATs. If ICMP MTU discovery is not working, MTU-related path black holes may occur.
* IPフラグメンテーションへの依存は、NATSを介した実行可能な戦略である可能性は低いです。ICMP MTUディスカバリーが機能していない場合、MTU関連のパスブラックホールが発生する可能性があります。
* A mitigation strategy is to constrain the MTU, especially for virtual interfaces, to expected safe MTU values, e.g., 1400 bytes for the underlying interfaces that support 1500 bytes MTU.
* 緩和戦略は、特に仮想インタフェースのためのMTUを制約し、1500バイトのMTUをサポートする基礎となるインターフェイスのための1400バイトの予想されるSAFIのMTU値、例えば1400バイトに制限することです。
* Further extensions to this specification may define a HIP-based mechanism to find a working path MTU without unnecessary constraining that size using Packetization Layer Path MTU Discovery for Datagram Transports [RFC8899]. For instance, such a mechanism could be implemented between a HIP Relay Client and HIP Relay Server.
* この仕様に対するさらなる拡張機能は、データグラムトランスポートのパケット化レイヤパスMTUディスカバリを使用して、不要な制約を不要にすることなく、作業経路MTUを見つけるためのHIPベースのメカニズムを定義することができる[RFC8899]。例えば、そのようなメカニズムは、HIPリレークライアントとHIPリレーサーバとの間で実施することができる。
* It is worth noting that further HIP extensions can trim off 8 bytes in the ESP header by negotiating implicit initialization vector (IV) support in the ESP_TRANSFORM parameter as described in [RFC8750].
* [RFC8750]に記載されているように、ESP_TRANSFORMパラメータでの暗黙の初期化ベクトル（IV）サポートを交渉することによって、ESPヘッダー内の8バイトをさらにトリートすることができることは注目に値します。
HIP connectivity checks are HIP UPDATE packets. The format is specified in [RFC7401].
HIP接続性チェックはHIP更新パケットです。フォーマットは[RFC7401]で指定されています。
The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets as specified in [RFC7401] with the Notify message type field set to NAT_KEEPALIVE (16385) and with an empty Notification data field. It is worth noting that the sending of such a HIP NOTIFY message SHOULD be omitted if the host is sending some other traffic (HIP or ESP) to the peer host over the related UDP tunnel during the Tr period. For instance, the host MAY actively send ICMPv6 requests (or respond with an ICMPv6 response) inside the ESP tunnel to test the health of the associated IPsec security association. Alternatively, the host MAY use UPDATE packets as a substitute. A minimal UPDATE packet would consist of a SEQ and a single ECHO_REQ_SIGN parameter, and a more complex one would involve rekeying procedures as specified in Section 6.8 of [RFC7402]. It is worth noting that a host actively sending periodic UPDATE packets to a busy server may increase the computational load of the server since it has to verify HMACs and signatures in UPDATE messages.
KeepAlivesの推奨エンコードフォーマットは、[RFC7401]で指定されているhip通知パケットは、Natify Message TypeフィールドがNAT_Keepalive（16385）に設定され、空の通知データフィールドを使用して推奨されます。ホストがTR期間中に関連UDPトンネルを介して他のトラフィック（HIPまたはESP）をそのようなトラフィック（HIPまたはESP）をピアホストに送信している場合は、そのようなHIP Notifyメッセージの送信を省略する必要があります。たとえば、ホストは、ESPトンネル内でICMPv6要求を積極的に送信することができます（またはICMPv6応答で応答して、関連付けられているIPsecセキュリティアソシエーションの正常性をテストします。あるいは、ホストは更新パケットを代替として使用することができる。最小更新パケットは、SEQと単一のECHO_REQ_SIGNパラメータで構成され、より複雑なものは[RFC7402]のセクション6.8で指定されているようにプロシージャーの再確認を含みます。 UpdateメッセージでHMACSと署名を検証しているため、積極的な更新パケットを中期更新パケットに積極的に送信しているホストがサーバーの計算負荷を増やす可能性があります。
The format of the NAT traversal mode parameter is defined in Legacy ICE-HIP [RFC5770] but repeated here for completeness. The format of the NAT_TRAVERSAL_MODE parameter is similar to the format of the ESP_TRANSFORM parameter in [RFC7402] and is shown in Figure 8. The Native ICE-HIP extension specified in this document defines the new NAT traversal mode identifier for ICE-HIP-UDP and reuses the UDP-ENCAPSULATION mode from Legacy ICE-HIP [RFC5770]. The identifier named RESERVED is reserved for future use. Future specifications may define more traversal modes.
NATトラバーサルモードパラメータのフォーマットは、レガシーアイスヒップ[RFC5770]で定義されていますが、完全性のためにここで繰り返されます。NAT_TRAVERSAL_MODEパラメータの形式は、[RFC7402]のesp_transformパラメータの形式と似ています。このドキュメントで指定されたネイティブのICE-HIP拡張子は、ICE-HIP-UDPの新しいNATトラバーサルモード識別子を定義します。レガシーアイスヒップ[RFC5770]から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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format of the NAT_TRAVERSAL_MODE Parameter
図8：NAT_TRAVERSAL_MODEパラメータの形式
Type: 608
タイプ：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)
モードID：提案または選択されたNATトラバーサルモードを定義します（S）
The following NAT traversal mode IDs are defined:
次のNATトラバーサルモードIDが定義されています。
+===================+=======+
| ID name | Value |
+===================+=======+
| RESERVED | 0 |
+-------------------+-------+
| UDP-ENCAPSULATION | 1 |
+-------------------+-------+
| ICE-STUN-UDP | 2 |
+-------------------+-------+
| ICE-HIP-UDP | 3 |
+-------------------+-------+
Table 1: NAT Traversal Mode IDs
表1：NATトラバーサルモードIDS
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トラバーサルモードパラメータを処理するように準備する必要があります。限られた数のモードIDSは、NAT_TRAVERSAL_MODEパラメータの最大サイズを設定します。モードは、まず最初に最も優先モードで、優先順位でなければなりません。
Implementations conforming to this specification MUST implement UDP-ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes.
この仕様に準拠した実装はUDPカプセル化を実行し、ICE-HIP-UDPモードを実装する必要があります。
The TRANSACTION_PACING parameter is defined in [RFC5770] but repeated in Figure 9 for completeness. It contains only the connectivity check pacing value, expressed in milliseconds, as a 32-bit unsigned integer.
transaction_pacingパラメータは[RFC5770]で定義されていますが、完全性については図9で繰り返されます。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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Format of the TRANSACTION_PACING Parameter
図9：transaction_pacingパラメータの形式
Type: 610
タイプ：610
Length: 4
長さ：4
Min Ta: The minimum connectivity check transaction pacing value the host would use (in milliseconds)
Min Ta：最小接続性チェックトランザクションペーシング値ホストが使用する（ミリ秒）
The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is shown in Figure 10. All parameters are identical except for the type. Of the three, only REG_FROM is covered by the signature.
図10には、REG_FROM、RELAY_FROM、およびRELAY_TOパラメータの形式を示します。すべてのパラメーターはタイプを除いて同じです。3つのうち、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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Format of the REG_FROM, RELAY_FROM, and RELAY_TO Parameters
図10：REG_FROM、RELAY_FROM、およびRELAY_TOパラメータの形式
Type: REG_FROM: 950 RELAY_FROM: 63998 RELAY_TO: 64002
タイプ：REG_FROM：950 Relay_From：63998 Relay_TO：64002
Length: 20
長さ：20
Port: Transport port number; zero when plain IP is used
ポート：トランスポートポート番号。普通IPが使用されているときにゼロ
Protocol: IANA-assigned, Internet Protocol number. 17 for UDP; 0 for plain 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マップIPv6アドレス」フォーマットのIPv6アドレスまたはIPv4アドレス
REG_FROM contains the transport address and protocol from which the Control Relay Server sees the registration coming. RELAY_FROM contains the address from which the relayed packet was received by the Control 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 Control Relay Serverが登録を見るトランスポートアドレスとプロトコルが含まれています。Relay_Fromは、中継パケットがControl Relay Serverによって受信されたアドレスと使用されたプロトコルを含みます。relay_toは、パケットが転送されるアドレスに関する同じ情報を含みます。
This specification reuses the format for UDP-based locators as specified in Legacy ICE-HIP [RFC5770] to be used for communicating the address candidates between two hosts. The generic and NAT-traversal-specific locator parameters are illustrated in Figure 11.
この仕様は、2つのホスト間でアドレス候補を通信するために使用されるレガシーアイスヒップ[RFC5770]で指定されているUDPベースのロケータのフォーマットを再利用します。汎用およびNAT - トラバース固有のロケータパラメータを図11に示す。
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 11: LOCATOR_SET Parameter
図11：locator_setパラメータ
The individual fields in the LOCATOR_SET parameter are described in Table 2.
locator_setパラメータの個々のフィールドは表2に説明されています。
+===========+==========+=========================================+
| Field | Value(s) | Purpose |
+===========+==========+=========================================+
| Type | 193 | Parameter type |
+-----------+----------+-----------------------------------------+
| Length | Variable | Length in octets, excluding Type and |
| | | Length fields and padding |
+-----------+----------+-----------------------------------------+
| Traffic | 0-2 | The locator for either HIP signaling |
| Type | | (1) or 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, see |
| Lifetime | | Section 4 of [RFC8046] |
+-----------+----------+-----------------------------------------+
| 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 (currently unused), |
| | | or 3 for relayed address |
+-----------+----------+-----------------------------------------+
| Priority | Variable | Locator's priority as described in |
| | | [RFC8445]. It is worth noting that |
| | | while the priority of a single locator |
| | | candidate is 32 bits, an implementation |
| | | should a 64-bit integer to calculate |
| | | the priority of a candidate pair for |
| | | the ICE priority algorithm. |
+-----------+----------+-----------------------------------------+
| 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_SET Parameter
表2：locator_setパラメータのフィールド
The LOCATOR parameter MUST be encapsulated inside an ENCRYPTED parameter.
LOCATORパラメーターは暗号化されたパラメーター内でカプセル化されている必要があります。
As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC parameter value has the TLV type 65520. It has the same semantics as RVS_HMAC as specified in Section 4.2.1 of [RFC8004]. Similar to RVS_HMAC, RELAY_HMAC is also keyed with the HIP integrity key (HIP-lg or HIP-gl as specified in Section 6.5 of [RFC7401]), established during the relay registration procedure as described in Section 4.1.
Legacy Ice-Hip [RFC5770]で指定されているように、Relay_HMACパラメータ値にはTLVタイプ65520があります。[RFC8004]のセクション4.2.1で指定されているRVS_HMACと同じセマンティクスを持ちます。RVS_HMACと同様に、Relay_HMACは、セクション4.1で説明されているように、中継登録手順の間に確立されたHIP Integrityキー（[RFC7401]のセクション6.5で指定されているHIP-LGまたはHIP-GL）でもキー入力されます。
The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain Registration Type [RFC8003] values for Control Relay Server registration. The value for RELAY_UDP_HIP is 2 as specified in Legacy ICE-HIP [RFC5770]. The value for RELAY_UDP_ESP is 3.
REG_INFO、REG_REQ、REG_RESP、およびREG_FAILEDパラメーターには、Control Relay Server登録の登録タイプ[RFC8003]値が含まれています。RELAY_UDP_HIPの値は、レガシーアイスヒップ[RFC5770]で指定されているとおりです。Relay_UDP_ESPの値は3です。
A Control/Data Relay Server and end hosts can use NOTIFY packets to signal different error conditions. The NOTIFY packet types are the same as in Legacy ICE-HIP [RFC5770] except for the two last ones, which are new.
コントロール/データリレーサーバーおよびエンドホストは、NOTIFYパケットを使用して、異なるエラー状態を表示できます。NOTIFYパケットタイプは、最後の2つの最後のものを除いて、レガシーアイスヒップ[RFC5770]と同じです。
The Notify Packet Types [RFC7401] 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パケットタイプ[RFC7401]を以下に示します。エラー通知の通知データフィールドには、拒否されたパケットのHIPヘッダーが含まれており、Connectivity_Checks_Failed Typeの場合は空にしてください。
+=====================================================+=======+
| NOTIFICATION PARAMETER - ERROR TYPES | Value |
+=====================================================+=======+
| NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER | 60 |
| | |
| If a Control Relay Server does not forward a base | |
| exchange packet due to a missing NAT traversal mode | |
| parameter, or the Initiator selects a NAT traversal | |
| mode that the (non-relay) Responder did not expect, | |
| the Control Relay Server or the Responder may send | |
| back a NOTIFY error packet with this type. | |
+-----------------------------------------------------+-------+
| CONNECTIVITY_CHECKS_FAILED | 61 |
| | |
| Used by the end hosts to signal that NAT traversal | |
| connectivity checks failed and did not produce a | |
| working path. | |
+-----------------------------------------------------+-------+
| MESSAGE_NOT_RELAYED | 62 |
| | |
| Used by a Control Relay Server to signal that it | |
| was not able or willing to relay a HIP packet. | |
+-----------------------------------------------------+-------+
| SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED | 63 |
| | |
| Used by a Data Relay Server to signal that it was | |
| not able or willing to allocate a new server- | |
| reflexive candidate for the Data Relay Client. | |
+-----------------------------------------------------+-------+
| RVS_HMAC_PROHIBITED_WITH_RELAY | 64 |
| | |
| In the unintended event that a Control Relay Server | |
| sends any HIP message with an RVS_HMAC parameter, | |
| the Control Relay Client drops the received HIP | |
| message and sends a notify message back to the | |
| Control Relay Server using this notify type. | |
+-----------------------------------------------------+-------+
Table 3: Notify Packet Types
表3：パケットの種類を通知します
The format for ESP data packets is identical to Legacy ICE-HIP [RFC5770].
ESPデータパケットのフォーマットは、レガシーアイスヒップ[RFC5770]と同じです。
[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; 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 the IP header is not used in BEET integrity protection calculation.
[RFC3948] IPSec ESPトランスポートとトンネルモードのUDPカプセル化について説明します。ワイヤでは、HIP ESPパケットはトランスポートモードESPとは異なりません。したがって、HIP ESPパケットのカプセル化は、UDPカプセル化トランスポートモードESPと同じである。ただし、HIPで使用されるバインドエンドツーエンドトンネル（ビット）モード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 [RFC7402]. 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ベースの交換中に、[RFC7402]に記載されているように、それらがIPSec ESPセキュリティアソシエーション（SAS）を定義できるようにする2つのピアを交換します。2つのピアがUDPカプセル化された基本交換を実行するとき、それらはUDPカプセル化されたESPデータトラフィックを生成する一対のIPSec SASを定義する必要があります。
The management of encryption/authentication protocols and SPIs is defined in [RFC7402]. The UDP encapsulation format and processing of HIP ESP traffic is described in Section 6.1 of [RFC7402].
暗号化/認証プロトコルとSPIの管理は[RFC7402]で定義されています。[RFC7402]の6.1項で、UDPカプセル化フォーマットとHIP ESPトラフィックの処理について説明します。
While the type values are new, the format of the RELAYED_ADDRESS and MAPPED_ADDRESS parameters (Figure 12) is identical to REG_FROM, RELAY_FROM, and RELAY_TO parameters. This document specifies only the use of UDP relaying; thus, only protocol 17 is allowed. However, future documents may specify support for other protocols.
タイプ値が新しく、relayed_addressおよびmapped_addressパラメータの形式（図12）はREG_FROM、RELAY_FROM、およびRELAY_TOパラメータと同じです。このドキュメントはUDP中継の使用のみを指定します。したがって、プロトコル17のみが許可される。ただし、将来の文書は他のプロトコルのサポートを指定できます。
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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS Parameters
図12：relayed_addressとmapped_addressパラメータの形式
Type: RELAYED_ADDRESS: 4650 MAPPED_ADDRESS: 4660
タイプ：relayed_address：4650 mapped_address：4660
Length: 20
長さ：20
Port: The UDP port number
ポート：UDPポート番号
Protocol: IANA-assigned, Internet Protocol number (17 for UDP)
プロトコル：IANAが割り当てられたインターネットプロトコル番号（UDPの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
アドレス：「IPv4マップIPv6アドレス」フォーマットのIPv6アドレスまたはIPv4アドレス
The format of the new PEER_PERMISSION parameter is shown in Figure 13. The parameter is used for setting up and refreshing forwarding rules and the permissions for data packets at the Data Relay Server. The parameter contains one or more sets of Port, Protocol, Address, Outbound SPI (OSPI), and Inbound SPI (ISPI) values. One set defines a rule for one peer address.
新しいPeer_permissionパラメータの形式を図13に示します。パラメータは、転送規則の設定と更新、およびデータリレーサーバーのデータパケットの権限とのアクセスに使用されます。このパラメータには、1つ以上のポート、プロトコル、アドレス、アウトバウンドSPI（OSPI）、およびインバウンドSPI（ISPI）値が含まれています。1つのセットは1つのピアアドレスのルールを定義します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPort | PPort |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| RAddress |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PAddress |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ISPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Format of the PEER_PERMISSION Parameter
図13：Peer_Permissionパラメータの形式
Type: 4680
タイプ：4680
Length: 48
長さ：48
RPort: The transport-layer (UDP) port at the Data Relay Server (i.e., the port of the server-reflexive candidate)
RPORT：データ中継サーバ（すなわち、サーバ再帰候補のポート）のトランスポート層（UDP）ポート
PPort: The transport-layer (UDP) port number of the peer
pport：ピアのトランスポート層（UDP）ポート番号
Protocol: IANA-assigned, Internet Protocol number (17 for UDP)
プロトコル：IANAが割り当てられたインターネットプロトコル番号（UDPの17）
Reserved: Reserved for future use; zero when sent, ignored when received
予約済み：将来の使用のために予約されています。送信されたときにはゼロを受信したときに無視されます
RAddress: An IPv6 address, or an IPv4 address in "IPv4-mapped IPv6 address" format, of the server-reflexive candidate
RADDRESS：サーバ再帰候補の「IPv4マップIPv6アドレス」形式のIPv6アドレス、またはIPv4アドレス
PAddress: An IPv6 address, or an IPv4 address in "IPv4-mapped IPv6 address" format, of the peer
PADDRESS：ピアの「IPv4マップIPv6アドレス」形式のIPv6アドレス、またはIPv4アドレス
OSPI: The outbound SPI value the Data Relay Client is using for the peer
OSPI：データリレークライアントがピアに使用しているアウトバウンドSPI値
ISPI: The inbound SPI value the Data Relay Client is using for the peer
ISPI：Inbound SPI値データリレークライアントがピアに使用している
The connectivity request messages are HIP UPDATE packets containing a new CANDIDATE_PRIORITY parameter (Figure 14). Response UPDATE packets contain a MAPPED_ADDRESS parameter (Figure 12).
接続要求メッセージは、新しい候補者候補パラメータを含むHIP更新パケットです（図14）。応答更新パケットには、mapped_addressパラメータが含まれています（図12）。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Format of the CANDIDATE_PRIORITY Parameter
図14：候補者候補者の形式
Type: 4700
タイプ：4700
Length: 4
長さ：4
Priority: The priority of a (potential) peer-reflexive candidate
優先順位：（電位）ピアリフレクティブ候補の優先順位
Figure 15 shows the NOMINATE parameter that is used to conclude the candidate nomination process.
図15は、候補指名プロセスを終了するために使用される推薦パラメータを示しています。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Format of the NOMINATE Parameter
図15：ノミネートパラメータの形式
Type: 4710
タイプ：4710
Length: 4
長さ：4
Reserved: Reserved for future extension purposes
予約済み：将来の拡張目的のために予約されています
The ICE specification [RFC8445] discusses "Unilateral Self-Address Fixing" in Section 18. This protocol is based on ICE; thus, the same considerations also apply here.
ICE仕様[RFC8445]は、セクション18の「一方的な自己アドレス固定」について説明します。このプロトコルはICEに基づいています。したがって、ここでも同じ考察も適用されます。
Since the control plane protocol and Control Relay Server are essentially the same (with some minor differences) in this document as in Legacy ICE-HIP [RFC5770], the same security considerations (in Sections 7.1, 7.2, 7.3, and 7.4) are still valid, but are repeated here for the sake of completeness. New security considerations related to the new Data Relay Server are discussed in Section 7.5, and considerations related to the new connectivity check protocol are discussed in Sections 7.6 and 7.7.
Control Plane ProtocolおよびControl Relay Serverは、レガシーアイスヒップ[RFC5770]のように、このドキュメントでは基本的に（いくつかの小さな違いを伴う）ので、同じセキュリティ上の考慮事項（セクション7.1,7.2,7.3、および7.4）がまだある。完全性のために有効ですがここで繰り返されます。新しいデータリレーサーバーに関連する新しいセキュリティ上の考慮事項については、7.5項で説明し、新しい接続性チェックプロトコルに関連する考慮事項については、セクション7.6および7.7で説明します。
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 local policy reasons, it might be tempting to exclude certain host addresses from the LOCATOR_SET parameter of an end host, but this is NOT RECOMMENDED. For instance, 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 Data Relay Server.
エンドユーザーがすべてのロケータを互いに明らかにしたくない可能性があることも可能です。たとえば、マルチホームエンドホストの物理的な場所を追跡すると、基本交換中にすべてのロケータがそのピアに表示されると、より簡単になる可能性があります。また、ホストアドレスを明らかにすると、すべての企業環境で許可されていない可能性があるローカルトポロジに関する情報が公開されています。これら2つのローカルポリシー上の理由から、エンドホストのLOCATER_SETパラメータから特定のホストアドレスを除外することは誘惑される可能性がありますが、これはお勧めできません。たとえば、このような動作は、ホストが同じNATの後ろにあるときに最適なパスを作成します。特に、これは、Private Address RealmからNATの外部アドレスを介してそれ自体に戻ることをサポートしていないレガシーNATで問題となる可能性があります。このシナリオは、ヘアピン問題と呼ばれています[RFC5128]。そのようなレガシーNATを使用すると、残された唯一のオプションは、データリレーサーバーから中継されたトランスポートアドレスを使用することです。
The use of Control and Data Relay Servers can also be useful for privacy purposes. For example, a privacy-concerned Responder may reveal only its Control Relay Server and Relayed candidates to Initiators. This partially 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）攻撃に対するレスポンダを部分的に保護します。
In opportunistic HIP mode (cf. Section 4.1.8 of [RFC7401]), an Initiator sends an I1 without setting the destination HIT of the Responder (i.e., the Control Relay Client). A Control Relay Server SHOULD have a unique IP address per the Control Relay Client when the Control Relay Server is serving more than one Control Relay Client and supports opportunistic mode. Otherwise, the Control Relay Server cannot guarantee to deliver the I1 packet to the intended recipient. Future extensions of this document may allow opportunistic mode to be used with non-unique IP addresses to be utilized either as a HIP-level anycast or multicast mechanism. Both of the mentioned cases would require separate registration parameters that the Control Relay Server proposes and the Control Client Server accepts during registration.
日和見主義的なヒップモード（[RFC7401のセクション4.1.8]）では、イニシエータはレスポンダの宛先ヒットを設定せずにI1を送信する（すなわち、制御リレークライアント）。Control Relay Serverは、Control Relay Serverが複数のControl Relayクライアントを提供しているときにControl Relayクライアントごとに一意のIPアドレスを持つ必要があります。そうでなければ、制御リレーサーバーはI1パケットを意図した受信者に配信することを保証できません。この文書の将来の拡張は、ヒップレベルのエニーキャストまたはマルチキャストメカニズムとして使用される独自のIPアドレスで日和見的モードを使用することを可能にし得る。言及されたケースの両方に、制御リレーサーバーが提案し、制御クライアントサーバーが登録中に受け入れる別の登録パラメータが必要になるでしょう。
In certain scenarios, it is possible that an attacker, or two attackers, can replay an earlier base exchange through a Control 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 legitimate Responder has to be disconnected from the Control Relay Server.
特定のシナリオでは、攻撃者、または2つの攻撃者が、オリジナルのイニシエータとレスポンダとしてのマスカレードによって、制御リレーサーバーを介して以前の基本交換を再生することができます。攻撃は攻撃者が攻撃したホストの秘密鍵を危険にさらすことを要求しません。ただし、この攻撃に成功するためには、正当なレスポンダを制御リレーサーバーから切り離す必要があります。
The Control Relay Server 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-MIDDLEBOXES] and drop the I2 or R2 packets if the corresponding ECHO_RESPONSE_M parameters are not present.
コントロールリレーサーバーは、エンドホスト（イニシエータとレスポンダ）が署名する必要があることを拒否することによって、基本交換に参加することで、再生攻撃から自分自身を保護できます。これを行う1つの方法は、[HIP-MiddleBoxes]で説明されているように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.
[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.
レスポンダはヒットを使用して異なるイニシエータを区別するため、この問題はHIP ESPトランスポートフォーマットのUDPカプセル化とは存在しません。
If the Data Relay Server uses the same relayed address and port (as conveyed in the RELAYED_ADDRESS parameter) for multiple Data Relay Clients, it appears to all the peers, and their firewalls, that all the Data Relay Clients are at the same address. Thus, a stateful firewall may allow packets to pass from hosts that would not normally be able to send packets to a peer behind the firewall. Therefore, a Data Relay Server SHOULD NOT reuse the port numbers. If port numbers need to be reused, the Data Relay Server SHOULD have a sufficiently large pool of port numbers and randomly select ports from the pool to decrease the chances of a Data Relay Client obtaining the same address that another host behind the same firewall is using.
データ中継サーバが複数のデータ中継クライアントの場合は同じ中継アドレスとポート（relayed_addressパラメータで伝送されているとおり）を使用している場合は、すべてのピア、およびそれらのファイアウォールに表示され、すべてのデータリレークライアントが同じアドレスにあることがわかります。したがって、ステートフルファイアウォールは、パケットがファイアウォールの後ろのピアにパケットを送信できるホストからパケットを通過させることができます。したがって、データリレーサーバーはポート番号を再利用しないでください。ポート番号を再利用する必要がある場合、データ中継サーバーには十分に大きなポート番号のプールを持ち、プールからポートをランダムに選択して、同じファイアウォールの背後にある別のホストが使用している同じアドレスを取得するデータリレークライアントのチャンスを減らす必要があります。。
A malicious host may send an invalid list of candidates to its peer that are used for targeting a victim host by flooding it with connectivity checks. To mitigate the attack, this protocol adopts the ICE mechanism to cap the total amount of connectivity checks as defined in Section 4.7.
悪意のあるホストは、それを接続性チェックで洪水させることによって被害者ホストをターゲットにするために使用される候補の無効なリストをそのピアに送信することができる。攻撃を軽減するために、このプロトコルは、セクション4.7で定義されているように、コネクティビティチェックの総量をキャップするためにICEメカニズムを採用しています。
Section 19.2 of [RFC8445] describes attacks against ICE connectivity checks. HIP bases its control plane security on Diffie-Hellman key exchange, public keys, and Hashed Message Authentication codes, meaning that the mentioned security concerns do not apply to HIP either. The mentioned section also discusses man-in-the-middle replay attacks that are difficult to prevent. The connectivity checks in this protocol are effectively immune against replay attacks because a connectivity request includes a random nonce that the recipient must sign and send back as a response.
[RFC8445]のセクション19.2は、ICE接続チェックに対する攻撃について説明します。HIPベースは、Diffie-Hellman鍵交換、公開鍵、およびハッシュされたメッセージ認証コードに関するそのコントロールプレーンセキュリティであり、言及されたセキュリティ上の懸念もHIPにも適用されません。上記のセクションでは、防止が困難な中間の再生攻撃についても説明します。このプロトコルの接続チェックは、接続性要求には受信者が署名して応答として送り返す必要があるランダムなNonceが含まれているため、再生攻撃に対して効果的に耐性があります。
Section 19.3 of [RFC8445] describes attacks on server-reflexive address gathering. Similarly here, if the DNS, a Control Relay Server, or a Data Relay Server has been compromised, not much can be done. However, the case where attackers can inject fake messages (located on a shared network segment like Wi-Fi) does not apply here. HIP messages are integrity and replay protected, so it is not possible to inject fake server-reflexive address candidates.
[RFC8445]のセクション19.3は、サーバーリフレクサアドレス集の攻撃について説明しています。ここでも、DNS、制御中継サーバ、またはデータ中継サーバが侵害されている場合、それほど多くのことができない。ただし、攻撃者が偽のメッセージを注入できる場合（Wi-Fiのような共有ネットワークセグメントにある）はここでは適用されません。HIPメッセージは整合性と再生が保護されているので、偽のサーバー再帰アドレス候補を注入することはできません。
Section 19.4 of [RFC8445] describes attacks on relayed candidate gathering. Similarly to ICE TURN servers, a Data Relay Server requires an authenticated base exchange that protects relayed address gathering against fake requests and responses. Further, replay attacks are not possible because the HIP base exchange (and also UPDATE procedure) is protected against replay attacks.
[RFC8445]のセクション19.4は、中継候補集会に対する攻撃について説明しています。ICEターンサーバーと同様に、データリレーサーバーは、中継アドレスの収集を偽の要求や応答に対して保護する認証された基本交換を必要とします。さらに、HIP基地交換（および更新手順）が再生攻撃から保護されているため、再生攻撃は不可能です。
Section 4.1 explains how a Control Relay Client registers for the RELAY_UDP_HIP service from a Control Relay Server. However, the same server may also offer Rendezvous functionality; thus, a client can register both to a RELAY_UDP_HIP and a RENDEZVOUS (see [RFC8004]) service from the same server. Potentially, this introduces a cross-protocol attack (or actually a "cross-message" attack) because the key material is the same for the Control Relay Service and Rendezvous HMACs. While the problem could be avoided by deriving different keys for the Control Relay Service, a more simple measure was chosen because the exact attack scenario was unclear. Consequently, this section defines a mandatory mitigation mechanism against the cross-protocol attack that works by preventing the simultaneous use of Rendezvous and Control Relay Service in the context of a single HIP Association.
Control RelayクライアントがControl Relay ServerからRelay_UDP_HIPサービスを登録する方法について説明します。ただし、同じサーバーはランデブー機能を提供する可能性があります。したがって、クライアントは、同じサーバーからRelay_UDP_hipとRendezvous（[RFC8004]参照）の両方を登録できます。潜在的には、これは、キー素材がControl Relay ServiceおよびRendezvous HMACSの場合は同じであるため、クロスプロトコル攻撃（または実際には "クロスメッセージ"攻撃）を発表します。コントロールリレーサービスにさまざまなキーを導出することで問題が回避できますが、正確な攻撃シナリオが不明確であるため、より簡単な尺度が選択されました。したがって、このセクションは、単一のHIP協会の文脈でランデブーおよび制御リレーサービスの同時使用を防ぐことによって機能するクロスプロトコル攻撃に対する必須の緩和メカニズムを定義しています。
The registration involves three parameters typically delivered sequentially in R1 (REG_INFO parameter), I2 (REG_REQUEST), and R2 (REG_RESPONSE) messages but can also be delivered in UPDATE messages as described in [RFC8003]. The parameters and the modifications to their processing are described below:
登録には、通常、R1（REG_INFOパラメータ）、I2（REG_REQUEST）、およびR2（REG_RESPONSE）メッセージで順次配信される3つのパラメータが含まれますが、[RFC8003]の説明に従って更新メッセージで配信することもできます。それらの処理に対するパラメータと修正は以下のとおりです。
REG_INFO: The Control Relay Server advertises its available services using this parameter. RELAY_UDP_HIP and RENDEZVOUS services MAY be included in the first advertisement for the HIP association, but subsequent ones MUST include only one of them as agreed in earlier registrations (see steps 2 and 3).
REG_INFO：Control Relay Serverはこのパラメータを使用して利用可能なサービスをアドバタイズします。Relay_UDP_hipとRendezvous Servicesは、HIPアソシエーションの最初の広告に含めることができますが、以前の登録で合意されているようにそれらのうちの1つだけを含める必要があります（手順2と3を参照）。
REG_REQUEST: The Control Relay Client chooses the services it requires using this parameter. If the Control Relay Server offered both RENDEZVOUS or RELAY_UDP_HIP, the Control Relay Client MUST choose only one of them in the REG_REQUEST parameter. Upon choosing one of the two, it persists throughout the lifetime of the HIP association, and the Control Relay Client MUST NOT register the other remaining one in a subsequent UPDATE message.
REG_REQUEST：Control Relayクライアントは、このパラメータを使用する必要があるサービスを選択します。Control RelayサーバーがRendezvousまたはRelay_UDP_hipの両方を提供した場合、Control RelayクライアントはREG_REQUESTパラメーター内の1つだけを選択する必要があります。2つのうちの1つを選択すると、それはHIPアソシエーションの有効期間を通して続く、そしてコントロールリレークライアントは後続の更新メッセージに残りの残りのものを登録してはいけません。
REG_RESPONSE: The Control Relay Server verifies the services requested by the Control Relay Client using this parameter. If the Control Relay Server offered both RENDEZVOUS and RELAY_UDP_HIP service, and the Control Relay Client requested for both of them, the Control Relay Client MUST offer only RELAY_UDP_HIP service in the REG_RESPONSE parameter and include a REG_FAILED parameter in the same message, with RENDEZVOUS as the Registration Type and 9 as the Failure Type.
REG_RESPONSE：Control Relay Serverは、このパラメータを使用してControl Relayクライアントによって要求されたサービスを検証します。Control RelayサーバーがRendezvousおよびRelay_UDP_HIPサービスの両方を提供し、それらの両方に対して要求されたControl Relayクライアントは、REG_Responseパラメータでrelay_udp_hipサービスのみを提供し、同じメッセージにREG_FAILEDパラメータを含む必要があります。登録タイプと9つの障害タイプとして9。
As a further measure against cross-protocol attacks, the Control Relay Client MUST drop any HIP message that includes an RVS_HMAC parameter when it originates from a successfully registered Control Relay Server. Upon such an (unintended) event, the Control Relay Client MUST send a NOTIFY message with RVS_HMAC_PROHIBITED_WITH_RELAY as the Notify Message Type to the Control Relay Server.
クロスプロトコル攻撃に対するさらなる対策として、制御リレークライアントは、正常に登録された制御リレーサーバから発生したときにRVS_HMACパラメータを含む任意のHIPメッセージを削除する必要があります。そのような（意図しない）イベントの上に、制御リレークライアントは、NOTIFYメッセージタイプとしてRVS_HMAC_PROIBITED_WITH_RELAYを制御リレーサーバに通知メッセージを送信する必要があります。
This section is to be interpreted according to [RFC8126].
このセクションは[RFC8126]に従って解釈されます。
This document reuses the same default UDP port number 10500 as specified by Legacy ICE-HIP [RFC5770] for tunneling both HIP control and data plane traffic. The port was registered separately for [RFC5770] to coauthor Ari Keränen originally, but it has been reassigned for IESG control. With the permission of Ari Keränen, the new assignee is the IESG and the contact is <chair@ietf.org>. In addition, IANA has added a reference to this document in the entry for UDP port 10500 in the "Service Name and Transport Protocol Port Number Registry". The selection between Legacy ICE-HIP and Native ICE-HIP mode is negotiated using the NAT_TRAVERSAL_MODE parameter during the base exchange. By default, hosts listen to this port for incoming UDP datagrams and can also use it for sending UDP datagrams. Other ephemeral port numbers are negotiated and utilized dynamically.
このドキュメントは、HIP制御とデータプレーントラフィックの両方をトンネリングするために、Legacy ICE-HIP [RFC5770]で指定されたものと同じデフォルトのUDPポート番号10500を再利用します。ポートは最初に[RFC5770]に別々に登録されましたが、もともとIESGコントロールのために再割り当てされました。AriKeränenの許可を得て、新しい譲受人はIESGであり、連絡先は<chair@ietf.org>です。さらに、IANAは、「サービス名とトランスポートプロトコルポート番号レジストリ」のUDPポート10500のエントリ内のこの文書への参照を追加しました。レガシーアイスヒップとネイティブアイスヒップモードの間の選択は、基本交換中にNAT_TRAVERSAL_MODEパラメータを使用してネゴシエートされます。デフォルトでは、HostsはUDPデータグラムを着信するためにこのポートを待機し、UDPデータグラムを送信するために使用することもできます。他の一時的なポート番号は動的にネゴシエートされ利用されます。
IANA has assigned the following values in the HIP "Parameter Types" registry [RFC7401]: 4650 for RELAYED_ADDRESS (length 20), 4660 for MAPPED_ADDRESS (length 20; defined in Section 5.12), 4680 for PEER_PERMISSION (length 48; defined in Section 5.13), 4700 for CANDIDATE_PRIORITY (length 4; defined in Section 5.14), and 4710 for NOMINATE (length 4; defined in Section 5.15).
IANAには、hip "パラメータタイプ"レジストリ[RFC7401]：4650には、hip "パラメータタイプ"レジストリ（長さ20）、4660（長さ20;セクション5.12で定義されています）、peer_permissionの場合は4680（長さ48;セクション48.）、候補者のための4700（長さ4; 5.14で定義されています）、およびノミネートのための4710（長さ4.セクション5.15で定義されています）。
IANA has assigned the following value in the "HIP NAT Traversal Modes" registry specified in Legacy ICE-HIP [RFC5770]: 3 for ICE-HIP-UDP (defined in Section 5.4).
IANAには、Legacy Ice-Hip [RFC5770]：3の「HIP NATトラバーサルモード」レジストリに次の値が割り当てられています（セクション5.4で定義）。
IANA has assigned the following values in the HIP "Notify Message Types" registry: 16385 for NAT_KEEPALIVE in Section 5.3, 63 for SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED in Section 5.10, and 64 for RVS_HMAC_PROHIBITED_WITH_RELAY in Section 5.10.
IANAには、セクション5.10のServer_Reflexive_candidate_allocation_failed_failed_failed_failed_failed for server_reflexive_candidate_pailed_failed_failed_failed_failed_failed_failed_failed_failed for section 5.10では、hip "notifyメッセージタイプ"レジストリ：16385、および64節の値は5.10セクション5.10で割り当てられています。
IANA has assigned the following values in the "Registration Types" registry for the HIP Registration Extension [RFC8003]: 3 for RELAY_UDP_ESP (defined in Section 5.9) for allowing registration with a Data Relay Server for ESP-relaying service, and 4 for CANDIDATE_DISCOVERY (defined in Section 4.2) for performing server-reflexive candidate discovery.
IANAは、ESP-Relaying Service用のデータリレーサーバーとの登録を許可するためのRELAY_UDP_ESP（セクション5.9で定義されています）について、「登録タイプ」レジストリ（RELAY_UDP_ESP（セクション5.9で定義）を割り当てました。サーバー再帰候補発見を実行するためのセクション4.2で定義しました。
IANA has assigned one value in the "Registration Failure Types" registry as defined in Section 7.8. The value is 9, and the Registration Failure Type is "Simultaneous Rendezvous and Control Relay Service usage prohibited".
IANAは、セクション7.8で定義されているように、「登録失敗タイプ」レジストリに1つの値を割り当てました。値は9で、登録失敗タイプは「同時ランデブーと制御中継サービス使用量禁止」です。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.
[RFC1191] Mogul、J.およびS.Theering、 "Path Mtu Discovery"、RFC 1191、DOI 10.17487 / RFC1191、1990年11月、<https：//www.rfc-editor.org/info/rfc1191>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R.およびS.Theering、 "IPバージョン6アドレッシングアーキテクチャ"、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https：//www.rfc-editor.org/info/rfc4291>。
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keranen, Ed., "Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators", RFC 5770, DOI 10.17487/RFC5770, April 2010, <https://www.rfc-editor.org/info/rfc5770>.
[RFC5770]コム、M.、Henderson、T.、Tschofenig、H.、Melen、J.、およびA.ケラネン、ED。、「ネットワークアドレストランスレータのトラバースのための基本ホストアイデンティティプロトコル（HIP）拡張」、RFC 5770、DOI 10.17487 / RFC5770、2010年4月、<https://www.rfc-editor.org/info/rfc5770>。
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013, <https://www.rfc-editor.org/info/rfc7050>.
[RFC7050] Savolainen、T.、Korhonen、J.、D. Wing、「IPv6アドレス合成に使用されるIPv6プレフィックスの発見」、RFC 7050、DOI 10.17487 / RFC7050、2013年11月、<https：//www.rfc-editor.org/info/rfc7050>。
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, <https://www.rfc-editor.org/info/rfc7401>.
[RFC7401] Moskowitz、R.、Ed。、Heer、T.、Jokela、P.、T. Henderson、「Host Identity Protocol Version 2（HIPv2）」、RFC 7401、DOI 10.17487 / RFC7401、2015年4月、<HTTPS//www.rfc-editor.org/info/rfc7401>。
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/RFC7402, April 2015, <https://www.rfc-editor.org/info/rfc7402>.
[RFC7402] Jokela、P.、Moskowitz、R.、およびJ.Melen、 "Host Identity Proportion（HIP）"、RFC 7402、DOI 10.17487 / RFC7402、2015年4月、<https://www.rfc-editor.org/info/rfc7402>。
[RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 8003, DOI 10.17487/RFC8003, October 2016, <https://www.rfc-editor.org/info/rfc8003>.
[RFC8003] Laganier、J.およびL. Eggert、RFC 8003、DOI 10.17487 / RFC8003、2016年10月、<https：//www.rfc-editor.org/info/rfc8003>。
[RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, October 2016, <https://www.rfc-editor.org/info/rfc8004>.
[RFC8004] Laganier、J.およびL. Eggert、「Host Identity Protocol（HIP）Rendezvous Extension」、RFC 8004、DOI 10.17487 / RFC8004、2016年10月、<https：//www.rfc-editor.org/info/rfc8004>。
[RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, October 2016, <https://www.rfc-editor.org/info/rfc8005>.
[RFC8005] Laganier、J.、 "Host Identity Protocol（HIP）エクステンション"、RFC 8005、DOI 10.17487 / RFC8005、2016年10月、<https://www.rfc-editor.org/info/RFC8005>。
[RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", RFC 8046, DOI 10.17487/RFC8046, February 2017, <https://www.rfc-editor.org/info/rfc8046>.
[RFC8046]ヘンダーソン、T.、ED。、VOGT、C、およびJ.Arkko、「ホストアイデンティティプロトコルによるホストモビリティ」、RFC 8046、DOI 10.17487 / RFC8046、2017年2月、<https：//ww.rfc-editor.org/info/rfc8046>。
[RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Multihoming with the Host Identity Protocol", RFC 8047, DOI 10.17487/RFC8047, February 2017, <https://www.rfc-editor.org/info/rfc8047>.
[RFC8047]ヘンダーソン、T.、ED。、VOGT、C、およびJ.Arkko、「ホストアイデンティティプロトコルによるホストマルチホーム」、RFC 8047、DOI 10.17487 / RFC8047、2017年2月、<https：//www.rfc-editor.org/info/rfc8047>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.
[RFC8201] McCann、J.、Theer、S.、Mogul、J.、およびR. Hinden、Ed。、「IPバージョン6のためのパスMTUディスカバリー」、STD 87、RFC 8201、DOI 10.17487 / RFC8201、2017年7月、<https://www.rfc-editor.org/info/rfc8201>。
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
[RFC8445]ケラネン、A.、Holmberg、C.、J.Rosenberg、「インタラクティブ接続施設（氷）：ネットワークアドレス翻訳者のためのプロトコル」、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、<https://www.rfc-editor.org/info/rfc8445>。
[RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, D., Mahy, R., and P. Matthews, "Session Traversal Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489, February 2020, <https://www.rfc-editor.org/info/rfc8489>.
[RFC8489] Petit-Huguenin、M.、Salgueiro、G.、Rosenberg、J.、Wing、D.、Mahy、R.、およびP.Stthews、「Nat（Stun）のセッショントラバーサルユーティリティ」、RFC 8489、DOI10.17487 / RFC8489、2020年2月、<https://www.rfc-editor.org/info/rfc8489>。
[RFC8961] Allman, M., "Requirements for Time-Based Loss Detection", BCP 233, RFC 8961, DOI 10.17487/RFC8961, November 2020, <https://www.rfc-editor.org/info/rfc8961>.
[RFC8961] Allman、M.、「時間ベースの損失検出の要件」、BCP 233、RFC 8961、DOI 10.17487 / RFC8961、2020年11月、<https://www.rfc-editor.org/info/rfc8961>。
[HIP-MIDDLEBOXES] Heer, T., Hummen, R., Wehrle, K., and M. Komu, "End-Host Authentication for HIP Middleboxes", Work in Progress, Internet-Draft, draft-heer-hip-middle-auth-04, 31 October 2011, <https://datatracker.ietf.org/doc/html/draft-heer-hip-middle-auth-04>.
[ヒップミドルボックス] HEER、T.、HUMMEN、R.、Wehrle、K.、およびM.コム、「HIPミドルボックスのエンドホスト認証」、進行中の作業、インターネットドラフト、ドラフトヒップ - 中間-auth-04,11月31日、<https://datatracker.ietf.org/doc/html/draft-heal-hipp-middle-auth-04>。
[ICE-NONSIP] Rosenberg, J., "Guidelines for Usage of Interactive Connectivity Establishment (ICE) by non Session Initiation Protocol (SIP) Protocols", Work in Progress, Internet-Draft, draft-rosenberg-mmusic-ice-nonsip-01, 14 July 2008, <https://datatracker.ietf.org/doc/html/draft-rosenberg-mmusic-ice-nonsip-01>.
[ICE-NOSIP] Rosenberg、J。、「非セッション開始プロトコル（SIP）プロトコルによるインタラクティブ接続確立（ICE）の使用ガイドライン、進行中の作業、インターネットドラフト、ドラフト - Rosenberg-MMUSIC-ICE - NCSIP - 2008年7月14日、<https://datatracker.ietf.org/doc/html/draft-rosenberg-mmusic-ine-nonsip-01>。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW.Weiss、「差別化サービスのためのアーキテクチャ」、RFC 2475、DOI 10.17487 / RFC2475、12月1998年、<https：//www.rfc-editor.org/info/rfc2475>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J.およびH.Schulzrinne、「セッション記述プロトコル（SDP）」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https：//ww.rfc-editor.org/ info / rfc3264>。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, DOI 10.17487/RFC3948, January 2005, <https://www.rfc-editor.org/info/rfc3948>.
[RFC3948] Huttunen、A.、Swander、B.、Volpe、V.、Diburro、L.、およびM. Stenberg、「IPsec ESPパケットのUDPカプセル化」、RFC 3948、DOI 10.17487 / RFC3948、2005年1月、<HTTPS：//www.rfc-editor.org/info/rfc3948>。
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 2008, <https://www.rfc-editor.org/info/rfc5128>.
[RFC5128] SRISURESH、P.、FORD、B.およびD.Kegel、「ネットワークアドレス翻訳者全体のピアツーピア（P2P）通信（NATS）」、RFC 5128、DOI 10.17487 / RFC5128、2008年3月<https://www.rfc-editor.org/info/rfc5128>。
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, DOI 10.17487/RFC5207, April 2008, <https://www.rfc-editor.org/info/rfc5207>.
[RFC5207] Stiemerling、M.、Quittek、J.、L. Eggert、「Host Identity Protocol（HIP）コミュニケーションのNATとファイアウォールトラバーサル問題」、RFC 5207、DOI 10.17487 / RFC5207、2008年4月、<https：//www.rfc-editor.org/info/rfc5207>。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <https://www.rfc-editor.org/info/rfc5245>.
[RFC5245] Rosenberg、J。、「インタラクティブ接続確立（氷）：募集/回答プロトコルのためのネットワークアドレス翻訳（NAT）トラバースのためのプロトコル、RFC 5245、DOI 10.17487 / RFC5245、2010年4月、<https：// www.rfc-editor.org / info / rfc5245>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P.、I。van Beijnum、 "IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳"、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<https：//www.rfc-editor.org/info/rfc6146>。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, <https://www.rfc-editor.org/info/rfc6147>.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P.、およびI。van Beijnum、「DNS64：IPv6クライアントからIPv4サーバーへのネットワークアドレス翻訳のためのDNS拡張」、RFC 6147、DOI 10.17487 / RFC6147、4月2011年、<https://www.rfc-editor.org/info/rfc6147>。
[RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol (HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538, March 2012, <https://www.rfc-editor.org/info/rfc6538>.
[RFC6538] Henderson、T.およびA.Gurtov、「Host Identity Protocol（HIP）実験レポート」、RFC 6538、DOI 10.17487 / RFC6538、2012年3月、<https：//www.rfc-editor.org/info/RFC6538>。
[RFC8656] Reddy, T., Ed., Johnston, A., Ed., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 8656, DOI 10.17487/RFC8656, February 2020, <https://www.rfc-editor.org/info/rfc8656>.
[RFC8656] Reddy、T.、Ed。、Johnston、A.、ED。、Matthews、P.、およびJ.Rosenberg、「NAT周辺のリレーを使用したトラバーサル（ターン）：NAT（STUN）のセッショントラバーサルユーティリティへのリレー拡張"、RFC 8656、DOI 10.17487 / RFC8656、2020年2月、<https：//www.rfc-editor.org/info/rfc8656>。
[RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)", RFC 8750, DOI 10.17487/RFC8750, March 2020, <https://www.rfc-editor.org/info/rfc8750>.
[RFC8750] Migautt、D.、Guggemos、T.、およびY。NIR、「セキュリティセキュリティペイロード（ESP）」、RFC 8750、DOI 10.17487 / RFC8750、2020年3月、<https://www.rfc-editor.org/info/rfc8750>。
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[RFC8899] Fairhurst、G.、Jones、T.、T.、T.、T.Völker、I.、およびT.Völker、「パケット化層パスMTUディスカバリ」、RFC 8899、DOI 10.17487 / RFC8899、2020年9月、<https://www.rfc-editor.org/info/rfc8899>。
[RFC9063] Moskowitz, R., Ed. and M. Komu, "Host Identity Protocol Architecture", RFC 9063, DOI 10.17487/RFC9063, July 2021, <https://www.rfc-editor.org/info/rfc9063>.
[RFC9063] Moskowitz、R.、Ed。2021年7月、<https：//www.rfc-editor.org/info/rfc9063>。
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 is recommended that the hosts estimate the round-trip time (RTT) between them, and they SHOULD set the minimum Ta value so that at most a single connectivity check message is sent on every RTT.
TA値は、ネットワーク特性が事前に知られている環境でユーザによって構成されてもよい。ただし、特性がわからない場合は、値が動的に調整されることをお勧めします。この場合、ホストがそれらの間の往復時間（RTT）を推定することをお勧めします。これは、ほとんどの接続チェックメッセージがRTTごとに送信されるように最小TA値を設定する必要があります。
One way to estimate the RTT is to use the time that it takes for the Control 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, this is not recommended. In general, estimating RTT can be difficult and error prone; thus, the guidelines for choosing a Ta value in Section 4.4 MUST be followed.
RTTを見積もる1つの方法は、Control Relay Server登録交換が完了するのにかかる時間を使用することです。これは登録ホストのアクセスリンクのRTTの見積もりを与えるでしょう。また、RTTを推定するためにI1 / R1交換を使用することができますが、R1をネットワーク内にキャッシュすることもできますので、中継サービスは遅延を大きくすることができますが、これはお勧めできません。一般に、RTTを推定することは困難であり、誤って誤っている可能性があります。したがって、セクション4.4でTA値を選択するためのガイドラインに従う必要があります。
Legacy ICE-HIP reuses the ICE/STUN/TURN protocol stack as it is. The benefits of such as an approach include the reuse of STUN/TURN infrastructure and possibly the reuse of existing software libraries, but there are also drawbacks with the approach. For example, ICE is meant for application-layer protocols, whereas HIP operates at layer 3.5 between transport and network layers. This is particularly problematic because the implementations employ kernel-space IPsec ESP as their data plane: demultiplexing of incoming ESP, HIP, and TURN messages required the capturing of all UDP packets destined to port 10500 to the userspace (due to different, incompatible markers in ESP and STUN), thus causing additional software complexity and an unnecessary latency/throughput bottleneck for the dataplane performance. It is also worth noting that the demultiplexing of STUN packets in the kernel would also incur a performance impact (albeit smaller than with userspace demultiplexing), and secure verification of STUN messages would require communication between the kernel-space STUN detector and HIP daemon typically residing in the userspace (thus again increasing the performance overhead).
レガシーアイスヒップは、ICE / STUN /ターンプロトコルスタックをそのまま再利用します。アプローチなどの利点には、STUN /ターンインフラストラクチャの再利用、およびおそらく既存のソフトウェアライブラリの再利用が含まれますが、アプローチの欠点もあります。たとえば、ICEはアプリケーション層プロトコルを意味しますが、HIPはトランスポート層とネットワーク層の間のレイヤ3.5で動作します。実装ではカーネル空間IPsec ESPをデータプレーンとして採用しているため、これは特に問題があります。受信ESP、HIP、およびターンメッセージの逆多重化は、ポート10500宛てのすべてのUDPパケットのキャプチャをユーザースペースのキャプチャ（さまざまな、互換性のないマーカーが異なります） ESPとSTUN）では、データプレーンのパフォーマンスのための追加のソフトウェアの複雑さと不要なレイテンシ/スループットのボトルネックを引き起こします。また、カーネル内のSTUNパケットの逆多重化もパフォーマンスへの影響（USERSPACEの逆多重化よりも小さいため）であり、STUNメッセージの安全な検証がカーネル空間STUN検出器とHIPデーモンの間の通信を必要とすることにもかかわらず、通常は常駐することもあります。ユーザースペースで（したがってパフォーマンスのオーバーヘッドを増やす）。
Legacy ICE-HIP also involves some other complexities when compared to the approach taken in this document. The relaying of ESP packets via TURN relays was not considered that simple because TURN relays require adding and removing extra TURN framing for the relayed packets. Finally, the developers of the two Legacy ICE-HIP implementations concluded that effort needed for integrating an ICE library into a HIP implementation turned out to be quite a bit higher than initially estimated. Also, the amount of extra code (some 10 kLoC) needed for all the new parsers, state machines, etc., was quite high and by reusing the HIP code, one should be able to do with much less. This should result in smaller binary size, less bugs, and easier debugging.
レガシーアイスヒップはまた、この文書で行われたアプローチと比較して他のいくつかの複雑さを伴います。ターンリレーを介したESPパケットの中継は、ターンリレーが中継されたパケットのための余分なターンフレーミングを追加および削除する必要があるため、単純なものとは見なされませんでした。最後に、2つの従来のアイスヒップ実装の開発者は、ICEライブラリをHIP実装に統合するために必要とされる努力が、最初の推定よりもかなり高くなることが判明したと結論付けました。また、すべての新しいパーサー、ステートマシンなどに必要な追加コード（約10 kloc）の量は非常に高く、腰コードを再利用することによって、はるかに少ないことができるはずです。これにより、2進数の小さいサイズ、より少ないバグ、およびデバッグが容易になるはずです。
Consequently, the HIP working group decided to follow ICE methodology but reuse HIP messaging format to achieve the same functionality as ICE; the result of that is this document, which specifies the Native ICE-HIP protocol.
その結果、HIPワーキンググループはICE方法論に従うことを決定しましたが、氷と同じ機能を実現するためにHIPメッセージングフォーマットを再利用しました。その結果、ネイティブのICE-HIPプロトコルを指定します。
The Native ICE-HIP protocol specified in this document follows the semantics of ICE as close as possible, and most of the differences are syntactical due to the use of a different protocol. In this section, we describe the differences to the ICE protocol.
この文書で指定されているネイティブICE-HIPプロトコルは、できるだけ氷の意味論に従います。このセクションでは、ICEプロトコルとの違いについて説明します。
* ICE operates at the application layer, whereas this protocol operates between transport and network layers, thus hiding the protocol details from the application.
* 氷はアプリケーション層で動作しますが、このプロトコルはトランスポート層とネットワーク層の間で動作し、したがってアプリケーションからプロトコルの詳細を隠します。
* The STUN protocol is not employed. Instead, Native ICE-HIP reuses the HIP control plane format in order to simplify the demultiplexing of different protocols. For example, the STUN binding response is replaced with a HIP UPDATE message containing an ECHO_REQUEST_SIGNED parameter and the STUN binding response with a HIP UPDATE message containing an ECHO_RESPONSE_SIGNED parameter as defined in Section 4.6. It is worth noting that a drawback of not employing STUN is that discovery of the address candidates requires creating (using HIP base exchange) and maintaining (using HIP UPDATE procedures) state at the Control Relay Client and Control Relay Server. Future extensions to this document may define a stateless, HIP-specific mechanism for an end host to discover its address candidates.
* STUNプロトコルは採用されていません。代わりに、ネイティブアイスヒップは、異なるプロトコルの逆多重化を単純化するために、ヒップコントロールプレーンフォーマットを再利用します。例えば、STUNバインディング応答は、セクション4.6で定義されているように、echo_request_signedパラメータおよびSTUNバインディング応答を含むHIP更新メッセージに置き換えられます。STUNを採用していないという欠点は、アドレス候補の発見であること（HIPベースの交換を使用している）と制御リレークライアントと制御リレーサーバーでの状態を維持することが必要であることです。この文書への将来の拡張は、エンドホストがそのアドレス候補を発見するためのステートレス、HIP固有のメカニズムを定義することができます。
* The TURN protocol is not utilized. Instead, Native ICE-HIP reuses Control Relay Servers for the same purpose.
* ターンプロトコルは利用されていません。代わりに、ネイティブアイスヒップは同じ目的のためにリレーサーバーを制御する再利用を再利用します。
* ICMP errors may be used in ICE to signal failure. In the Native ICE-HIP protocol, HIP NOTIFY messages are used instead.
* ICMPエラーは氷上で信号障害に使用できます。ネイティブのアイスヒッププロトコルでは、代わりにHIP通知メッセージが使用されます。
* Instead of the ICE username fragment and password mechanism for credentials, Native ICE-HIP uses the HIT, derived from a public key, for the same purpose. The username fragments are "transient host identifiers, bound to a particular session established as part of the candidate exchange" [RFC8445]. Generally in HIP, a local public key and the derived HIT are considered long-term identifiers and invariant across different host associations and different transport-layer flows.
* 認証情報のICEユーザー名フラグメントとパスワードメカニズムの代わりに、ネイティブアイスヒップは同じ目的のために公開鍵から派生したヒットを使用します。ユーザ名フラグメントは、「候補Exchangeの一部として確立された特定のセッションにバインドされた一時的なホスト識別子」です[RFC8445]。一般的に股関節では、地域の公開鍵と派生ヒットは長期識別子と考えられ、異なるホストアソシエーションと異なるトランスポート層の流れに不変されています。
* In ICE, the conflict when two communicating endpoints take the same controlling role is solved using random values (a so-called tie-breaker value). In the Native ICE-HIP protocol, the conflict is solved by the standard HIP base exchange procedure, where the host with the "larger" HIT switches to the Responder role, thus also changing to the controlled role.
* 氷の中では、2つの通信エンドポイントが同じ制御ロールをとるときの競合は、ランダムな値（いわゆるタイブレーカ値）を使用して解決されます。ネイティブICE-HIPプロトコルでは、競合は標準的なHIPベースの交換手順によって解決され、そこで「より大きい」ヒットのホストはレスポンダの役割に切り替わり、したがって制御された役割にも変わります。
* The ICE-CONTROLLED and ICE-CONTROLLING attributes are not included in the connectivity checks.
* アイスコントロールおよびアイスコントロールの属性は、接続性チェックに含まれていません。
* The foundation concept is unnecessary in Native ICE-HIP because only a single UDP flow for the IPsec tunnel will be negotiated.
* IPsecトンネルの単一のUDPフローしか交渉されないため、ネイティブアイスヒップには基礎コンセプトは不要です。
* Frozen candidates are omitted for the same reason the foundation concept is excluded.
* 凍結候補は同じ理由で省略されており、基礎の概念は除外されます。
* Components are omitted for the same reason the foundation concept is excluded.
* コンポーネントは同じ理由で省略されています。基礎の概念は除外されます。
* Native ICE-HIP supports only "full ICE" where the two communicating hosts participate actively to the connectivity checks, and the "lite" mode is not supported. This design decision follows the guidelines of ICE, which recommends full ICE implementations. However, it should be noted that a publicly reachable Responder may refuse to negotiate the ICE mode as described in Section 4.7.2. This would result in a HIP base exchange (as per [RFC7401]) tunneled over UDP, followed by ESP traffic over the same tunnel, without the connectivity check procedures defined in this document (in some sense, this mode corresponds to the case where two ICE lite implementations connect since no connectivity checks are sent).
* ネイティブアイスヒップは、2つの通信ホストが接続性チェックに積極的に参加し、「Lite」モードはサポートされていません。この設計決定は、完全な氷の実装を推奨する氷のガイドラインに従います。しかしながら、4.7.2節で説明されているように、公的に到達可能な応答者がICEモードを交渉することを拒否することがあることに留意されたい。これにより、UDP上でトンネリングされたHIPベースの交換（RFC7401]）に、この文書で定義されている接続の確認手順が定義されていない（ある意味では、このモードが2つの場合に対応しています）。接続チェックが送信されないため、ICE Liteの実装が接続します。
* As the "ICE lite" is not adopted here and both sides are capable of ICE-HIP-UDP mode (negotiated during the base exchange), default candidates are not employed in Native ICE-HIP.
* ここで「ICE Lite」が採用されていないため、両側がICE-HIP-UDPモード（基本交換中にネゴシエート）が可能です。デフォルトの候補はネイティブアイスヒップに採用されていません。
* If the agent is using Diffserv Codepoint markings [RFC2475] in its media packets, it SHOULD apply those same markings to its connectivity checks.
* エージェントがそのメディアパケットでDiffServ CodePointマーキング[RFC2475]を使用している場合は、接続チェックに同じマーキングを適用する必要があります。
* Unlike in ICE, the addresses are not XORed in the Native ICE-HIP protocol but rather encrypted to avoid middlebox tampering.
* ICEとは異なり、アドレスはネイティブのICE-HIPプロトコルではXORSはXORSはXORSは廃止されませんが、ミドルボックスの改ざんを避けるために暗号化されています。
* ICE defines Related Address and Port attributes used for diagnostic/SIP purposes, but the Native ICE-HIP protocol does not employ these attributes.
* ICEは、診断/ SIPの目的で使用される関連アドレスとポート属性を定義しますが、ネイティブのICE-HIPプロトコルはこれらの属性を使用しません。
* The minimum RTO is 500 ms in ICE but 1000 ms in the Native ICE-HIP protocol in favor of [RFC8961].
* 最小RTOは、[RFC8961]を支持しているネイティブICE-HIPプロトコルでは、ICE中で500 msですが、ネイティブのアイスヒッププロトコルで1000 msです。
This section gives some design guidance for implementers on how the extensions in this protocol extend and differ from [RFC7401] and [RFC8046].
このセクションでは、このプロトコルの拡張機能が[RFC7401]と[RFC8046]とどのように拡張するかについての実装者に対する設計ガイダンスをいくつか示します。
* Both the control and data plane are operated on top of UDP, not directly on IP.
* 制御とデータプレーンの両方がIP上ではなくUDPの上部で動作します。
* A minimal implementation would conform only to Sections 4.7.1 or 4.7.2, thus merely tunneling HIP control and data traffic over UDP. The drawback here is that it works only in the limited cases where the Responder has a public address.
* 最小限の実装は、セクション4.7.1または4.7.2にのみ適合し、したがってUDPよりも股関節制御とデータトラフィックをトンネリングするだけです。ここでの欠点は、レスポンダがパブリックアドレスを持っている限られた場合にのみ機能することです。
* It is worth noting that while a Rendezvous Server [RFC8004] has not been designed to be used in NATed scenarios because it just relays the first I1 packet and does not employ UDP encapsulation, the Control Relay Server forwards all control traffic and, hence, is more suitable in NATed environments. Further, the Data Relay Server guarantees forwarding of data plane traffic also in cases where the NAT traversal procedures fail.
* Rendezvous Server [RFC8004]が最初のI1パケットを中継し、UDPカプセル化を使用していないため、Control Relay Serverはすべてのコントロールトラフィックを転送するだけなので、RFC8004がNotezvous Server [RFC8004]が設定されていないことは注目に値します。日付環境にもっと適しています。さらに、データ中継サーバは、NATトラバース手順が失敗した場合にもデータプレーントラフィックの転送を保証する。
* Registration procedures with a Control/Data Relay Server are similar as with a Rendezvous Server. However, a Control/Data Relay Server has different registration parameters than a Rendezvous Server because it offers a different service. Also, the Control/Data Relay Server also includes a REG_FROM parameter that informs the Control/Data Relay Client about its server-reflexive address. A Data Relay Server also includes a RELAYED_ADDRESS containing the relayed address for the Data Relay Client.
* 制御/データ中継サーバーを使用した登録手順は、Rendezvous Serverと同じです。ただし、Control / Data Relay ServerはRendezvous Serverとは異なる登録パラメータを持ち、異なるサービスを提供しています。また、制御/データ中継サーバは、そのサーバ再帰アドレスについて制御/データリレークライアントに通知するREG_FROMパラメータも含む。データ中継サーバには、データリレークライアント用の中継アドレスを含むRelayed_addressも含まれています。
* In [RFC7401], the Initiator and Responder can start to exchange application payload immediately after the base exchange. While exchanging data immediately after a base exchange via a Data Control Relay would also be possible here, we follow the ICE methodology to establish a direct path between two hosts using connectivity checks. This means that there will be some additional delay after the base exchange before application payload can be transmitted. The same applies for the UPDATE procedure as the connectivity checks introduce some additional delay.
* [RFC7401]では、イニシエータとレスポンダは基本交換直後にアプリケーションペイロードを交換し始めることができます。ここでは、データ管理リレーを介してベース交換直後にデータを交換することも可能であるが、接続チェックを使用して2つのホスト間の直接パスを確立することができます。これは、アプリケーションペイロードを送信する前に基本交換後に追加の遅延があることを意味します。接続性チェックが追加の遅延を紹介するため、更新手順についても同様です。
* In HIP without any NAT traversal support, the base exchange acts as an implicit connectivity check, and the mobility and multihoming extensions support explicit connectivity checks. After a base exchange or UPDATE-based connectivity checks, a host can use the associated address pair for transmitting application payload. In this Native ICE-HIP extension, we follow the ICE methodology where one endpoint acting in the controlled role chooses the used address pair also on behalf of the other endpoint acting in the controlled role, which is different from HIP without NAT traversal support. Another difference is that the process of choosing an address pair is explicitly signaled using the nomination packets. The nomination process in this protocol supports only a single address pair, and multihoming extensions are left for further study.
* NATトラバーサルサポートなしでHIPでは、基本交換は暗黙の接続チェックとして機能し、モビリティとマルチホーム拡張機能は明示的な接続チェックをサポートします。塩基交換または更新ベースの接続性チェックの後、ホストはアプリケーションペイロードを送信するために関連アドレスペアを使用できます。この天然のアイスヒップ延長では、制御された役割に作用する一つのエンドポイントは、制御された役割に作用する他のエンドポイントの代わりに使用されたアドレスペアを選択し、それはNATトラバーサルサポートなしの股関節とは異なります。別の違いは、アドレスペアを選択するプロセスが、指名パケットを使用して明示的にシグナリングされることです。このプロトコルの推薦プロセスは単一のアドレスペアのみをサポートし、その他の研究のためにマルチホーム拡張が残されます。
* The UPDATE procedure resembles the mobility extensions defined in [RFC8046]. The first UPDATE message from the mobile host is exactly the same as in the mobility extensions. The second UPDATE message from the peer host and third from the mobile host are different in the sense that they merely acknowledge and conclude the reception of the candidates through the Control Relay Server. In other words, they do not yet test for connectivity (besides reachability through the Control Relay Server) unlike in the mobility extensions. The idea is that the connectivity check procedure follows the ICE specification, which is somewhat different from the HIP mobility extensions.
* 更新手順は[RFC8046]で定義されているMobility Extensionsに似ています。モバイルホストからの最初の更新メッセージは、Mobility Extensionsとまったく同じです。ピアホストからの第2の更新メッセージおよびモバイルホストからの第3の更新メッセージは、それらが単に候補者の受信を制御リレーサーバを介して受信し、終了するという意味で異なる。つまり、モビリティ拡張機能とは異なり、それらはまだ接続性をテストしていません（コントロールリレーサーバーを介した到達可能性に加えて）。このアイデアは、接続性チェック手順がICE仕様に従います。これは、HIP Mobility Extensionsとは多少異なります。
* The connectivity checks as defined in the mobility extensions [RFC8046] are triggered only by the peer of the mobile host. Since successful NAT traversal requires that both endpoints test connectivity, both the mobile host and its peer host have to test for connectivity. In addition, this protocol also validates the UDP ports; the ports in the connectivity check must match with the response, as required by ICE.
* Mobility Extensions [RFC8046]で定義されている接続チェックは、モバイルホストのピアによってのみ発生します。NATトラバーサルが成功すると、エンドポイントの両方のテスト接続がテスト接続を必要とするため、モバイルホストとそのピアホストの両方が接続をテストする必要があります。さらに、このプロトコルもUDPポートを検証します。接続チェック内のポートは、iceで要求されるように、応答と一致しなければなりません。
* In HIP mobility extensions [RFC8046], an outbound locator has some associated state: UNVERIFIED means that the locator has not been tested for reachability, ACTIVE means that the address has been verified for reachability and is being used actively, and DEPRECATED means that the locator lifetime has expired. In the subset of ICE specifications used by this protocol, an individual address candidate has only two properties: type and priority. Instead, the actual state in ICE is associated with candidate pairs rather than individual addresses. The subset of ICE specifications utilized by this protocol require the following attributes for a candidate pair: valid bit, nominated bit, base, and the state of the connectivity check. The connectivity checks have the following states: Waiting, In-progress, Succeeded, and Failed. Handling of this state attribute requires some additional logic when compared to the mobility extensions, since the state is associated with a local-remote address pair rather than just a remote address; thus, the mobility and ICE states do not have an unambiguous one-to-one mapping.
* hip Mobility Extensions [RFC8046]では、アウトバウンドロケータはいくつかの関連状態を持ちます。寿命が期限切れになっています。このプロトコルで使用されるICE仕様のサブセットでは、個々のアドレス候補にはタイプと優先順位が2つのプロパティしかありません。代わりに、氷の実際の状態は個々のアドレスではなく候補ペアに関連付けられています。このプロトコルによって利用されるICE仕様のサブセットには、有効なビット、ノミネートビット、ベース、および接続性チェックの状態について、次の属性が必要です。接続チェックには、待機、進行中、成功し、失敗しました。この状態属性の処理は、単なるリモートアドレスではなくローカルリモートアドレスペアに関連付けられているため、モビリティ拡張と比較したときに追加のロジックが必要です。したがって、モビリティと氷の状態は明確な一対一のマッピングを持たない。
* Credit-based authorization as defined in [RFC8046] could be used before candidate nomination has been concluded upon discovering working candidate pairs. However, this may result in the use of asymmetric paths for a short time period in the beginning of communications. Thus, support of credit-based authorization is left for further study.
* [RFC8046]で定義されているクレジットベースの承認は、作業候補ペアを発見すると候補指名が締結される前に使用できます。しかしながら、これは通信の開始時に短時間の非対称経路の使用をもたらし得る。したがって、クレジットベースの承認のサポートはさらなる研究のために残されています。
This document allows a host to collect address candidates from multiple interfaces but does not support activation and the simultaneous use of multiple address candidates. While multihoming extensions to support functionality similar to that found in [RFC8047] are left for further study and experimentation, we envision here some potential compatibility improvements to support multihoming:
このドキュメントでは、ホストが複数のインターフェイスからアドレス候補を収集できますが、アクティベーションや複数のアドレス候補の同時使用をサポートしていません。[RFC8047]にあるそれと同様のサポート機能へのマルチホーム拡張は、さらなる研究と実験のために残されていますが、ここではマルチホームをサポートするための潜在的な互換性の向上を想定しています。
Data Relay Registration: a Data Relay Client acting as an Initiator with another peer host should register a new server-reflexive candidate for each local transport address candidate. A Data Relay Client acting as a Responder should register a new server-reflexive candidate for each {local transport address candidate, new peer host} pair for the reasons described in Section 4.12.3. In both cases, the Data Relay Client should request the additional server-reflexive candidates by sending UPDATE messages originating from each of the local address candidates as described in Section 4.1. As the UPDATE messages are originating from an unknown location from the viewpoint of the Data Relay Server, it must also include an ECHO_REQUEST_SIGNED in the response in order to test for return routability.
データ中継登録：別のピアホストを有するイニシエータとして機能するデータリレークライアントは、各ローカルトランスポートアドレス候補に対して新しいサーバ再帰候補を登録する必要がある。レスポンダとして機能するデータリレークライアントは、セクション4.12.3に記載されている理由で、各{ローカルトランスポートアドレス候補、新しいピアホスト}ペアの新しいサーバーリフレクサ候補を登録する必要があります。どちらの場合も、データ中継クライアントは、セクション4.1に記載されているように、各ローカルアドレス候補から発信された更新メッセージを送信することによって、追加のサーバーリフレクティブ候補を要求する必要があります。更新メッセージがデータ中継サーバの視点から未知の場所から発信されているので、返信ルート可能性をテストするために応答内のECHO_REQUEST_SIGNEDを含む必要があります。
Data Relay unregistration: This follows the procedure in Section 4, but the Data Relay Client should unregister using the particular transport address to be unregistered. All transport address pair registrations can be unregistered when no RELAYED_ADDRESS parameter is included.
データリレー登録解除：セクション4の手順に従いますが、データリレークライアントは未登録の特定のトランスポートアドレスを使用して登録解除されます。Relayed_addressパラメータが含まれていない場合は、すべてのトランスポートアドレスペア登録を未登録です。
PEER_PERMISSION parameter: This needs to be extended or an additional parameter is needed to declare the specific local candidate of the Data Relay Client. Alternatively, the use of the PEER_PERMISSION could be used as a wild card to open permissions for a specific peer to all of the candidates of the Data Relay Client.
PEAR_PERMISSIONパラメータ：これを拡張する必要があるか、データリレークライアントの特定のローカル候補を宣言するために追加のパラメータが必要です。あるいは、Peer_Permissionの使用は、データリレークライアントのすべての候補のすべての候補に対して特定のピアに対する権限を開くためのワイルドカードとして使用することができる。
Connectivity checks: The controlling host should be able to nominate multiple candidates (by repeating step 7 in Figure 5 in Section 4.6 using the additional candidate pairs).
接続性チェック：制御ホストは、複数の候補を指名することができなければならない（図5のステップ7のステップ7を追加の候補ペアの使用）。
Keepalives: These should be sent for all the nominated candidate pairs. Similarly, the Control/Data Relay Client should send keepalives from its local candidates to its Control/Data Relay Server transport addresses.
KeepAlives：これらはすべての指名された候補ペアに対して送信されるべきです。同様に、コントロール/データリレークライアントは、そのローカル候補からその制御/データリレーサーバーのトランスポートアドレスにキープアライブを送信する必要があります。
This section updates Appendix B of [RFC5770], which will be replaced with the mechanism described in this section.
このセクションでは、[RFC5770]の付録Bを更新します。これは、このセクションで説明されているメカニズムに置き換えられます。
[RFC5770] did not specify how an end host can look up another end host via DNS and initiate a UDP-based HIP base exchange with it, so this section makes an attempt to fill this gap.
[RFC5770]最終ホストがDNSを介して別のエンドホストを検索できる方法を指定し、UDPベースのHIPベースの交換を開始するため、このセクションではこのギャップを埋めようとします。
[RFC8005] specifies how a HIP end host and its Rendezvous Server is registered to DNS. Essentially, the public key of the end host is stored as a HI record and its Rendezvous Server as an A or AAAA record. This way, the Rendezvous Server can act as an intermediary for the end host and forward packets to it based on the DNS configuration. The Control Relay Server offers similar functionality to the Rendezvous Server, with the difference being that the Control Relay Server forwards all control messages, not just the first I1 message.
[RFC8005] HIPエンドホストとそのRendezvous ServerがDNSにどのように登録されているかを指定します。基本的に、エンドホストの公開鍵は、HIレコードとそのRendezvous ServerとしてAまたはAAAAレコードとして保存されています。このようにして、Rendezvous Serverは、ENDホストの仲介者とDNS構成に基づいてパケットを転送することができます。Control Relay ServerはRendezvous Serverと同様の機能を提供します。差は、Control Relay Serverが最初のI1メッセージだけではなく、すべての制御メッセージを転送することです。
Prior to this document, the A and AAAA records in the DNS refer either to the HIP end host itself or a Rendezvous Server [RFC8005], and control and data plane communication with the associated host has been assumed to occur directly over IPv4 or IPv6. However, this specification extends the records to be used for UDP-based communications.
この文書の前に、DNSのAおよびAAAAレコードは、HIPエンドホスト自体またはRendezvous Server [RFC8005]のいずれかを参照し、関連するホストとの制御とデータプレーン通信がIPv4またはIPv6を介して直接発生すると想定されています。ただし、この仕様は、UDPベースの通信に使用されるレコードを拡張します。
Let us consider the case of a HIP Initiator with the default policy to employ UDP encapsulation and the extensions defined in this document. The Initiator looks up the Fully Qualified Domain Name (FQDN) of a Responder, and retrieves its HI, A, and AAAA records. Since the default policy is to use UDP encapsulation, the Initiator MUST send the I1 message over UDP to destination port 10500 (either over IPv4 in the case of an A record or over IPv6 in the case of an AAAA record). It MAY send an I1 message both with and without UDP encapsulation in parallel. In the case in which the Initiator receives R1 messages both with and without UDP encapsulation from the Responder, the Initiator SHOULD ignore the R1 messages without UDP encapsulation.
UDPのカプセル化とこのドキュメントで定義されている拡張機能を採用するための股関節イニシエータの場合を考えてみましょう。イニシエータはレスポンダの完全修飾ドメイン名（FQDN）を調べ、そのHI、A、およびAAAAレコードを取得します。デフォルトのポリシーはUDPカプセル化を使用することですので、イニシエータはUDPを介してI1メッセージを宛先ポート10500（AAAAレコードの場合はIPv4またはIPv6 over）にI1メッセージを送信する必要があります。UDPカプセル化の有無にかかわらずI1メッセージを並行して送信することができます。イニシエータがR1メッセージをレスポンダからのUDPカプセル化なしでR1メッセージを受信する場合、イニシエータはUDPカプセル化なしでR1メッセージを無視する必要があります。
The UDP-encapsulated I1 packet could be received by four different types of hosts:
UDPカプセル化されたI1パケットは、4つの異なるタイプのホストによって受信される可能性があります。
HIP Control Relay Server: In this case, the A/AAAA records refer to a Control Relay Server, which will forward the packet to the corresponding Control Relay Client based on the destination HIT in the I1 packet.
HIP Control Relay Server：この場合、A / AAAAレコードは、I1パケットの宛先ヒットに基づいて、対応する制御リレークライアントにパケットを転送する制御リレーサーバを参照しています。
HIP Responder supporting UDP encapsulation: In this case, the A/AAAA records refer to the end host. Assuming the destination HIT belongs to the Responder, the Responder receives and processes the I1 packet according to the negotiated NAT traversal mechanism. The support for the protocol defined in this document, as opposed to the support defined in [RFC5770], is dynamically negotiated during the base exchange. The details are specified in Section 4.3.
UDPカプセル化をサポートするHIPレスポンダ：この場合、A / AAAAレコードは最終ホストを参照しています。宛先のヒットがレスポンダに属すると仮定すると、レスポンダはネゴシエートされたNATトラバーサルメカニズムに従ってI1パケットを受信し処理します。[RFC5770]で定義されているサポートとは対照的に、このドキュメントで定義されているプロトコルのサポートは、ベース交換中に動的にネゴシエートされます。詳細はセクション4.3で指定されています。
HIP Rendezvous Server: This entity is not listening to UDP port 10500, so it will drop the I1 message.
HIP Rendezvous Server：このエンティティはUDPポート10500をリスニングしていませんので、I1メッセージを削除します。
HIP Responder not supporting UDP encapsulation: The targeted end host is not listening to UDP port 10500, so it will drop the I1 message.
HIPレスポンダUDPカプセル化をサポートしていません：ターゲットエンドホストがUDPポート10500をリスティングしていないため、I1メッセージを削除します。
The A/AAAA record MUST NOT be configured to refer to a Data Relay Server unless the host in question also supports Control Relay Server functionality.
A / AAAAレコードは、問題のホストがControl Relay Server機能をサポートしていない限り、データリレーサーバーを参照するように設定してはいけません。
It is also worth noting that SRV records are not employed in this specification. While they could be used for more flexible UDP port selection, they are not suitable for end-host discovery but rather would be more suitable for the discovery of HIP-specific infrastructure. Further extensions to this document may define SRV records for Control and Data Relay Server discovery within a DNS domain.
SRVレコードが本明細書で採用されていないことも注目する価値があります。それらはより柔軟なUDPポート選択に使用することができますが、それらはエンドホストの発見には適していませんが、むしろHIP固有のインフラストラクチャの発見にはより適しています。この文書へのさらなる拡張機能は、DNSドメイン内の制御およびData Relay Server検出のためのSRVレコードを定義することができます。
Acknowledgments
謝辞
Thanks to Jonathan Rosenberg, Christer Holmberg, and the rest of the MMUSIC WG folks for the excellent work on ICE. The authors would also 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, Tom Henderson, Alex Elsayed, Jani Hautakorpi, Tero Kauppinen, and Timo Simanainen for their comments to [RFC5770] and this document. Thanks to Éric Vyncke, Alvaro Retana, Adam Roach, Ben Campbell, Eric Rescorla, Mirja Kühlewind, Spencer Dawkins, Derek Fawcus, Tianran Zhou, Amanda Barber, Colin Perkins, Roni Even, Alissa Cooper, Carl Wallace, Martin Duke, and Benjamin Kaduk for reviewing this document.
Jonathan Rosenberg、Christer Holmberg、そして残りのミリスティックWGの人々のための優れた作品のために、著者らはまた、andrei Gurtov、Simon Schuetz、Martin Stiemerling、Lars Eggert、Vivien Schmitt、および貢献のために、Tobias Heer、Teemu Koponen、Jeffrey Mattila、Jeffrey M. Ahrenholz、Kristian Slavov、Janne Lindqvist、Pekka Nikandander、Lauri Silvennoinen、Jukka Ylitalo、Juha Heinanen、Joakim Koskela、Samu Varjonen、Dan Wing、Tom Henderson、Alex Elsayed、Jani Hautakorpi、Tero Kautakorpi、Tilo Kauppinen、Timo Simanainen、およびこの文書のコメント。ÉricVyncke、Alvaro Retana、Adam Roach、Ben Campbell、Eric Rescorla、MirjaKühlewind、Spencer Dawkins、Derek Fawcus、Tianran Zhou、Amanda Barber、Colin Perkins、Roniさえ、Alissa Cooper、Carl Wallace、Benjamin Kadukこの文書を見直すため。
This work has been partially funded by the Cyber Trust Program by Digile/Tekes in Finland.
この作品は、フィンランドのデジタル/テックによってサイバートラストプログラムによって部分的に資金を供給されています。
Contributors
貢献者
Marcelo Bagnulo, Philip Matthews, and Hannes Tschofenig have contributed to [RFC5770]. This document leans heavily on the work in that RFC.
Marcelo Bagnulo、Philip Matthews、およびHannes Tschofenigは[RFC5770]に貢献しました。この文書はそのRFCの仕事に大きく傾いています。
Authors' Addresses
著者の住所
Ari Keränen Ericsson Hirsalantie 11 FI-02420 Jorvas Finland
AriKeränenEricsson Hirsalantie 11 Fi-02420 Jorvasフィンランド
Email: ari.keranen@ericsson.com
Jan Melén Ericsson Hirsalantie 11 FI-02420 Jorvas Finland
JanMelénEricsson Hirsalantie 11 Fi-02420 Jorvas Finland
Email: jan.melen@ericsson.com
Miika Komu (editor) Ericsson Hirsalantie 11 FI-02420 Jorvas Finland
Miika Komu（編集）エリクソンHirsalantie 11 Fi-02420 Jorvas Finland
Email: miika.komu@ericsson.com