[要約] RFC 6317は、Host Identity Protocol（HIP）のための基本的なソケットインターフェース拡張に関するものです。このRFCの目的は、HIPをサポートするためのソケットインターフェースの拡張を提供することです。
Internet Engineering Task Force (IETF) M. Komu
Request for Comments: 6317 Aalto University
Category: Experimental T. Henderson
ISSN: 2070-1721 The Boeing Company
July 2011
Basic Socket Interface Extensions for the Host Identity Protocol (HIP)
ホストIDプロトコル（HIP）の基本ソケットインターフェイス拡張機能
Abstract
概要
This document defines extensions to the current sockets API for the Host Identity Protocol (HIP). The extensions focus on the use of public-key-based identifiers discovered via DNS resolution, but also define interfaces for manual bindings between Host Identity Tags (HITs) and locators. With the extensions, the application can also support more relaxed security models where communication can be non-HIP-based, according to local policies. The extensions in this document are experimental and provide basic tools for further experimentation with policies.
このドキュメントでは、ホストIDプロトコル（HIP）の現在のソケットAPIへの拡張機能を定義します。拡張機能は、DNS解像度で発見されたパブリックキーベースの識別子の使用に焦点を当てていますが、ホストIDタグ（ヒット）とロケーターの間の手動バインディングのインターフェイスも定義します。拡張機能により、アプリケーションは、ローカルポリシーによると、コミュニケーションが非人権ベースになる可能性のあるよりリラックスしたセキュリティモデルをサポートできます。このドキュメントの拡張は実験的であり、ポリシーをさらに実験するための基本的なツールを提供します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6317.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6317で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Name Resolution Process .........................................5
3.1. Interaction with the Resolver ..............................5
3.2. Interaction without a Resolver .............................6
4. API Syntax and Semantics ........................................7
4.1. Socket Family and Address Structure Extensions .............7
4.2. Extensions to Resolver Data Structures .....................9
4.3. The Use of getsockname() and getpeername() Functions ......12
4.4. Selection of Source HIT Type ..............................12
4.5. Verification of HIT Type ..................................13
4.6. Explicit Handling of Locators .............................14
5. Summary of New Definitions .....................................16
6. Security Considerations ........................................16
7. Contributors ...................................................17
8. Acknowledgments ................................................17
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................18
This document defines the C-based sockets Application Programming Interface (API) extensions for handling HIP-based identifiers explicitly in HIP-aware applications. It is up to the applications, or high-level programming languages or libraries, to manage the identifiers. The extensions in this document are mainly related to the use case in which a DNS resolution step has occurred prior to the creation of a new socket, and assumes that the system has cached or is otherwise able to resolve identifiers to locators (IP addresses). The DNS extension for HIP is described in [RFC5205]. The extensions also cover the case in which an application may want to explicitly provide suggested locators with the identifiers, including supporting the opportunistic case in which the system does not know the peer host identity.
このドキュメントでは、CベースのSocketsアプリケーションプログラミングプログラミングインターフェイス（API）拡張機能を定義します。HIPAWAREアプリケーションで股関節ベースの識別子を明示的に処理するための拡張機能が定義されています。識別子を管理するのは、アプリケーション、または高レベルのプログラミング言語またはライブラリ次第です。このドキュメントの拡張機能は、主に新しいソケットの作成前にDNS解像度ステップが発生したユースケースに関連しており、システムがキャッシュされているか、それ以外の場合は識別子をロケーター（IPアドレス）に解決できると想定しています。股関節のDNS拡張は[RFC5205]で説明されています。また、拡張機能は、アプリケーションが、システムがピアホストのIDを知らない日和見性のケースをサポートするなど、提案されたロケーターに識別子を明示的に提供したい場合もカバーしています。
The Host Identity Protocol (HIP) [RFC4423] proposes a new cryptographic namespace by separating the roles of endpoint identifiers and locators by introducing a new namespace to the TCP/IP stack. Shim6 [RFC5533] is another protocol based on an identity-locator split. The APIs specified in this document are specific to HIP, but have been designed as much as possible to not preclude its use with other protocols. The use of these APIs with other protocols is, nevertheless, for further study.
ホストIDプロトコル（HIP）[RFC4423]は、新しい名前空間をTCP/IPスタックに導入することにより、エンドポイント識別子とロケーターの役割を分離することにより、新しい暗号化名空間を提案します。SHIM6 [RFC5533]は、ID-Locatorの分割に基づいた別のプロトコルです。このドキュメントで指定されたAPIは、股関節に固有ですが、他のプロトコルでの使用を排除しないように可能な限り設計されています。それにもかかわらず、これらのAPIを他のプロトコルで使用することは、さらなる研究のためです。
The APIs in this document are based on Host Identity Tags (HITs) that are defined as IPv6 addresses with the Overlay Routable Cryptographic Hash Identifiers (ORCHID) prefix [RFC4843]. ORCHIDs are derived from Host Identifiers using a hash and fitting the result into an IPv6 address. Such addresses are called HITs, and they can be distinguished from other IPv6 addresses via the ORCHID prefix. Note that ORCHIDs are presently an experimental allocation by IANA. If the ORCHID allocation were to expire and HIT generation were to use a different prefix in the future, most users of the API would not be impacted, unless they explicitly checked the ORCHID prefix on returned HITs. Users who check (for consistency) that HITs have a valid ORCHID prefix must monitor the IANA allocation for ORCHIDs and adapt their software in case the ORCHID allocation were to be removed at a future date.
このドキュメントのAPIは、オーバーレイルーティング可能な暗号ハッシュ識別子（rfc4843]を使用してIPv6アドレスとして定義されるホストIDタグ（ヒット）に基づいています。オーキッドは、ハッシュを使用してホスト識別子から派生し、結果をIPv6アドレスに取り付けます。このようなアドレスはヒットと呼ばれ、Orchidプレフィックスを介して他のIPv6アドレスと区別できます。オーキッドは現在、IANAによる実験的割り当てであることに注意してください。Orchidの割り当てが期限切れになり、ヒット生成が将来異なるプレフィックスを使用することになった場合、返されたヒット時にOrchidプレフィックスを明示的にチェックしない限り、APIのほとんどのユーザーは影響を受けません。ヒットが有効なオーキッドプレフィックスがあることを（一貫性のために）チェックするユーザーは、ランのIANA割り当てを監視し、ランの割り当てが将来の日付で削除された場合にソフトウェアを調整する必要があります。
Applications can observe the HIP layer and its identifiers in the networking stacks with varying degrees of visibility. [RFC5338] discusses the lowest levels of visibility in which applications are completely unaware of the underlying HIP layer. Such HIP-unaware applications in some circumstances use HIP-based identifiers, such as Local Scope Identifiers (LSIs) or HITs, instead of IPv4 or IPv6 addresses and cannot observe the identifier-locator bindings.
アプリケーションは、さまざまな程度の可視性でネットワークスタック内の股関節層とその識別子を観察できます。[RFC5338]は、アプリケーションが基礎となる股関節層を完全に認識していない最低レベルの可視性について説明しています。このような状況によっては、IPv4またはIPv6アドレスの代わりにローカルスコープ識別子（LSI）やヒットなどの股関節ベースの識別子を使用して、識別子ロケーターバインディングを観察できません。
This document specifies extensions to [RFC3493] to define a new socket address family, AF_HIP. Similarly to other address families, AF_HIP can be used as an alias for PF_HIP. The extensions also describe a new socket address structure for sockets using HITs explicitly and describe how the socket calls in [RFC3493] are adapted or extended as a result.
このドキュメントは、[RFC3493]の拡張機能を指定して、新しいソケットアドレスファミリAF_HIPを定義します。他のアドレスファミリと同様に、AF_HIPはPF_HIPのエイリアスとして使用できます。また、拡張機能は、ヒットを明示的に使用してソケットの新しいソケットアドレス構造を説明し、結果として[RFC3493]のソケット呼び出しがどのように適応または拡張されるかを説明します。
Some applications may accept incoming communications from any identifier. Other applications may initiate outgoing communications without the knowledge of the peer identifier in opportunistic mode (Section 4.1.6 of [RFC5201]) by just relying on a peer locator. This document describes how to address both situations using "wildcards" as described in Section 4.1.1.
一部のアプリケーションは、識別子からの着信通信を受け入れる場合があります。他のアプリケーションは、ピアロケーターに依存するだけで、日和見モード（[RFC5201]のセクション4.1.6）でピア識別子の知識なしに発信通信を開始する場合があります。このドキュメントでは、セクション4.1.1で説明されているように、「ワイルドカード」を使用して両方の状況に対処する方法について説明します。
This document references one additional API document [RFC6316] that defines multihoming and explicit-locator handling. Most of the extensions defined in this document can be used independently of the above document.
このドキュメントは、マルチホームと明示的なロケーターの処理を定義する追加のAPIドキュメント[RFC6316]を参照しています。このドキュメントで定義されている拡張機能のほとんどは、上記のドキュメントとは独立して使用できます。
The identity-locator split introduced by HIP introduces some policy-related challenges with datagram-oriented sockets, opportunistic mode, and manual bindings between HITs and locators. The extensions in this document are of an experimental nature and provide basic tools for experimenting with policies. Policy-related issues are left for further experimentation.
HIPによって導入されたID-Locatorの分割は、データグラム指向のソケット、日和見モード、ヒットとロケーターの間の手動バインディングを伴ういくつかの政策関連の課題を導入します。このドキュメントの拡張は実験的な性質であり、ポリシーを実験するための基本的なツールを提供します。政策関連の問題は、さらなる実験のために残されています。
To recap, the extensions in this document have three goals. The first goal is to allow HIP-aware applications to open sockets to other hosts based on the HITs alone, presuming that the underlying system can resolve the HITs to addresses used for initial contact. The second goal is that applications can explicitly initiate communications with unknown peer identifiers. The third goal is to illustrate how HIP-aware applications can use the Shim API [RFC6316] to manually map locators to HITs.
要約すると、このドキュメントの拡張機能には3つの目標があります。最初の目標は、ヒット単独に基づいて、ヒップを認識しているアプリケーションが他のホストにソケットを開くことができるようにすることです。これは、基礎となるシステムが最初の接触に使用されるアドレスにヒットを解決できると仮定します。2番目の目標は、アプリケーションが未知のピア識別子との通信を明示的に開始できることです。3番目の目標は、ヒップアウェアアプリケーションがShim API [RFC6316]を使用して、ロケーターを手動でマッピングする方法を説明することです。
This document was published as experimental because a number of its normative references had experimental status. The success of this experiment can be evaluated by a thorough implementation of the APIs defined.
このドキュメントは、その規範的参照の多くが実験的状態を持っているため、実験として公開されました。この実験の成功は、定義されたAPIの徹底的な実装によって評価できます。
The terms used in this document are summarized in Table 1.
このドキュメントで使用される用語を表1にまとめます。
+---------+--------------------------------------------------------+
| Term | Explanation |
+---------+--------------------------------------------------------+
| FQDN | Fully Qualified Domain Name |
| HIP | Host Identity Protocol |
| HI | Host Identifier |
| HIT | Host Identity Tag, a 100-bit hash of a public key with |
| | a 28-bit prefix |
| LSI | Local Scope Identifier, a local, 32-bit descriptor for |
| | a given public key |
| Locator | Routable IPv4 or IPv6 address used at the lower layers |
| RR | Resource Record |
+---------+--------------------------------------------------------+
Table 1
表1
This section provides an overview of how the API can be used. First, the case in which a resolver is involved in name resolution is described, and then the case in which no resolver is involved is described.
このセクションでは、APIの使用方法の概要を説明します。まず、名前の解決にリゾルバーが関与する場合が記載されており、その後、リゾルバーが関与しない場合が説明されています。
Before an application can establish network communications with the entity named by a given FQDN or relative hostname, the application must translate the name into the corresponding identifier(s). DNS-based hostname-to-identifier translation is illustrated in Figure 1. The application calls the resolver in step (a) to resolve an FQDN to one or more socket addresses within the PF_HIP family. The resolver, in turn, queries the DNS in step (b) to map the FQDN to one or more HIP RRs with the HIT and HI and possibly the rendezvous server of the Responder, and also (in parallel or sequentially) to resolve the FQDN into possibly one or more A and AAAA records. It should be noted that the FQDN may map to multiple Host Identifiers and locators, and this step may involve multiple DNS transactions, including queries for A, AAAA, HI, and possibly other resource records. The DNS server responds with a list of HIP resource records in step (c). Optionally, in step (d), the resolver caches the HIT-to-locator mapping with the HIP module. The resolver converts the HIP records to HITs and returns the HITs to the application contained in HIP socket address structures in step (e). Depending on the parameters for the resolver call, the resolver may also return other socket address structures to the application. Finally, the application receives the socket address structure(s) from the resolver and uses them in socket calls such as connect() in step (f).
アプリケーションが特定のFQDNまたは相対ホスト名によって名前が付けられたエンティティとのネットワーク通信を確立できる前に、アプリケーションは対応する識別子に名前を変換する必要があります。DNSベースのホスト名から識別子への翻訳を図1に示します。アプリケーションは、ステップ（a）のリゾルバーを呼び出して、PF_HIPファミリ内の1つ以上のソケットアドレスにFQDNを解決します。リゾルバーは、ステップ（b）のDNSをクエリして、FQDNをヒットとHIで1つ以上の股関節RRにマッピングし、場合によっては応答者のランデブーサーバー、および（並列または順次）FQDNを解決するために（並列または順次）おそらく1つ以上のAおよびAAAAレコードに。FQDNは複数のホスト識別子とロケーターにマッピングできることに注意してください。このステップには、A、AAAA、HI、およびその他のリソースレコードのクエリを含む複数のDNSトランザクションが含まれる場合があります。DNSサーバーは、ステップ（c）の股関節リソースレコードのリストで応答します。オプションで、ステップ（d）では、リゾルバーはヒップからロケーターマッピングを股関節モジュールでキャッシュします。リゾルバーは、ヒップレコードをヒットに変換し、ヒットをステップ（E）の股関節ソケットアドレス構造に含まれるアプリケーションに返します。リゾルバーコールのパラメーターに応じて、リゾルバーは他のソケットアドレス構造をアプリケーションに返すこともあります。最後に、アプリケーションはリゾルバーからソケットアドレス構造を受信し、ステップ（F）のConnect（）などのソケット呼び出しでそれらを使用します。
+----------+
| |
| DNS |
| |
+----------+
^ |
b. QNAME=FQDN | | c. HIP and
| | A/AAAA
| v RR(s)
+-------------+ a. getaddrinfo(<FQDN>) +----------+
| |------------------------>| |
| Application | | Resolver |
| |<------------------------| |
+-------------+ e. <HITs> +----------+
| |
| | d. HIP and
| f. connect(<HIT>) | A/AAAA
| or any other socket call | RR(s)
v v
+----------+ +----------+
| | | |
| TCP/IP | | HIP |
| Stack | | |
+----------+ +----------+
Figure 1
図1
In practice, the resolver functionality can be implemented in different ways. For example, it may be implemented in existing resolver libraries or as a HIP-aware interposing agent.
実際には、リゾルバー機能はさまざまな方法で実装できます。たとえば、既存のリゾルバーライブラリに実装されたり、股関節を認識している介入エージェントとして実装できます。
The extensions in this document focus on the use of the resolver to map hostnames to HITs and locators in HIP-aware applications. The resolver may implicitly associate a HIT with the corresponding locator(s) by communicating the HIT-to-IP mapping to the HIP daemon. However, it is possible that an application operates directly on a peer HIT without interacting with the resolver. In such a case, the application may resort to the system to map the peer HIT to an IP address. Alternatively, the application can explicitly map the HIT to an IP address using socket options as specified in Section 4.6. Full support for all of the extensions defined in this document requires a number of shim socket options [RFC6316] to be implemented by the system.
このドキュメントの拡張機能は、ホスト名をヒットとロケーターにマッピングするためのリゾルバーの使用に焦点を当てています。リゾルバーは、ヒットからIPへのマッピングをヒップデーモンに通信することにより、ヒットを対応するロケーターに暗黙的に関連付けることができます。ただし、リゾルバーとやり取りすることなく、アプリケーションがピアヒットで直接動作する可能性があります。そのような場合、アプリケーションはシステムに頼って、ピアヒットをIPアドレスにマッピングできます。あるいは、アプリケーションは、セクション4.6で指定されているように、ソケットオプションを使用してHITをIPアドレスに明示的にマッピングできます。このドキュメントで定義されているすべての拡張機能を完全にサポートするには、システムによって実装される必要があります[RFC6316]。
In this section, we describe the native HIP APIs using the syntax of the C programming language. We limit the description to the interfaces and data structures that are either modified or completely new, because the native HIP APIs are otherwise identical to the sockets API [POSIX].
このセクションでは、Cプログラミング言語の構文を使用して、ネイティブのヒップAPIについて説明します。ネイティブの股関節APIがソケットAPI [POSIX]と同一であるため、説明を変更したインターフェイスと完全に新しいデータ構造に制限します。
The sockets API extensions define a new protocol family, PF_HIP, and a new address family, AF_HIP. The AF_HIP and PF_HIP constants are aliases to each other. These definitions shall be defined as a result of including <sys/socket.h>.
Sockets API拡張機能は、新しいプロトコルファミリー、PF_HIP、および新しいアドレスファミリAF_HIPを定義します。AF_HIPとPF_HIPの定数は、互いにエイリアスです。これらの定義は、<sys/socket.h>を含めた結果として定義されます。
When the socket() function is called with PF_HIP as the first argument (domain), it attempts to create a socket for HIP communication. If HIP is not supported, socket() follows its default behavior and returns -1, and sets errno to EAFNOSUPPORT.
Socket（）関数が最初の引数（ドメイン）としてpf_hipで呼び出されると、股関節通信のソケットを作成しようとします。股関節がサポートされていない場合、Socket（）はデフォルトの動作に従い、-1を返し、errnoをeafnosupportに設定します。
Figure 2 shows the recommended implementation of the socket address structure for HIP in Portable Operating System Interface (POSIX) format.
図2は、ポータブルオペレーティングシステムインターフェイス（POSIX）形式での股関節のソケットアドレス構造の推奨される実装を示しています。
#include <netinet/hip.h>
typedef struct in6_addr hip_hit_t;
typedef struct in6_addr hip_hit_t;
struct sockaddr_hip {
uint8_t ship_len;
sa_family_t ship_family;
in_port_t ship_port;
uint32_t ship_flags;
hip_hit_t ship_hit;
};
Figure 2
図2
uint8_t ship_len: This field defines the length of the structure. Implementations that do not define this field typically embed the information in the following ship_family field.
uint8_t ship_len：このフィールドは、構造の長さを定義します。このフィールドを定義していない実装は、通常、次のship_familyフィールドに情報を埋め込みました。
sa_family_t ship_family: This mandatory field identifies the structure as a sockaddr_hip structure. It overlays the sa_family field of the sockaddr structure. Its value must be AF_HIP.
sa_family_t ship_family：この必須フィールドは、構造をsockaddr_hip構造として識別します。Sockaddr構造のSa_familyフィールドに重なります。その値はaf_hipでなければなりません。
in_port_t ship_port: This mandatory field contains the transport protocol port number. It is handled in the same way as the sin_port field of the sockaddr_in structure. The port number is stored in network byte order.
in_port_t ship_port：この必須フィールドには、輸送プロトコルポート番号が含まれています。Sockaddr_in構造のSin_portフィールドと同じ方法で処理されます。ポート番号は、ネットワークバイトの順序で保存されます。
uint32_t ship_flags: This mandatory bit field contains auxiliary flags. This document does not define any flags. This field is included for future extensions.
uint32_t ship_flags：この必須ビットフィールドには、補助フラグが含まれています。このドキュメントでは、フラグを定義しません。このフィールドは、将来の拡張機能に含まれています。
hip_hit_t ship_hit: This mandatory field contains the endpoint identifier. When the system passes a sockaddr_hip structure to the application, the value of this field is set to a valid HIT, IPv4, or IPv6 address, as discussed in Section 4.5. When the application passes a sockaddr_hip structure to the system, this field must be set to a HIT or a wildcard address as discussed in Section 4.1.1.
hip_hit_t ship_hit：この必須フィールドには、エンドポイント識別子が含まれています。セクション4.5で説明されているように、システムがSockaddr_hip構造をアプリケーションに渡すと、このフィールドの値は有効なヒット、IPv4、またはIPv6アドレスに設定されます。アプリケーションがSockaddr_hip構造をシステムに渡す場合、セクション4.1.1で説明したように、このフィールドはヒットまたはワイルドカードアドレスに設定する必要があります。
Some applications rely on system-level access control, either implicit or explicit (such as the accept_filter() function found on BSD-based systems), but such discussion is out of scope. Other applications implement access control themselves by using the HITs. Applications operating on sockaddr_hip structures can use memcmp() or a similar function to compare the ship_hit fields. It should also be noted that different connection attempts between the same two hosts can result in different HITs, because a host is allowed to have multiple HITs.
一部のアプリケーションは、暗黙的または明示的なシステムレベルのアクセス制御に依存しています（BSDベースのシステムで見つかったAccept_Filter（）関数など）が、そのような議論は範囲外です。他のアプリケーションは、ヒットを使用してアクセス制御自体を実装します。sockaddr_hip構造で動作するアプリケーションは、memcmp（）または同様の関数を使用して、ship_hitフィールドを比較できます。また、ホストが複数のヒットを持つことが許可されているため、同じ2つのホスト間の異なる接続試行が異なるヒットをもたらす可能性があることに注意する必要があります。
HIP wildcard addresses are similar to IPv4 and IPv6 wildcard addresses. They can be used instead of specific HITs in the ship_hit field for local and remote endpoints in sockets API calls such as bind(), connect(), sendto(), or sendmsg().
股関節ワイルドカードアドレスは、IPv4およびIPv6ワイルドカードアドレスに似ています。bind（）、connect（）、send（）、またはsendmsg（）などのソケットAPI呼び出しのローカルエンドポイントとリモートエンドポイントのSHIP_HITフィールドの特定のヒットの代わりに使用できます。
In order to bind to all local IPv4 and IPv6 addresses and HIP HITs, the ship_hit field must be set to HIP_ENDPOINT_ANY. In order to bind to all local HITs, ship_hit must contain HIP_HIT_ANY. To only bind to all local public HITs, the ship_hit field must be HIP_HIT_ANY_PUB. The value HIP_HIT_ANY_TMP binds a socket to all local anonymous identifiers only as specified in [RFC4423]. The system may label anonymous identifiers as such depending on whether they have been published or not. After binding a socket via one of the HIP_HIT_ANY_* wildcard addresses, the application is guaranteed to receive only HIP-based data flows. With the HIP_ENDPOINT_ANY wildcard address, the socket accepts HIP, IPv6, and IPv4-based data flows.
すべてのローカルIPv4およびIPv6アドレスとHIPヒットにバインドするには、ship_hitフィールドをhip_endpoint_anyに設定する必要があります。すべてのローカルヒットにバインドするには、ship_hitにはhip_hit_anyが含まれている必要があります。すべてのローカルパブリックヒットにのみバインドするには、ship_hitフィールドはhip_hit_any_pubでなければなりません。値hip_hit_any_tmpは、[RFC4423]で指定されているように、すべてのローカル匿名識別子にソケットをバインドします。システムには、匿名の識別子が公開されているかどうかに応じてラベルを付けることができます。hip_hit_any_*ワイルドカードアドレスの1つを介してソケットをバインドした後、アプリケーションは股関節ベースのデータフローのみを受信することが保証されます。hip_endpoint_any Wildcardアドレスを使用すると、ソケットはHIP、IPv6、およびIPv4ベースのデータフローを受け入れます。
When a socket is bound or connected via a sockaddr_hip structure, i.e., the PF_HIP protocol family, the system returns only addresses of the AF_HIP family, i.e., sockaddr_hip structures, for this socket. This applies to all functions that provide addresses to the application, such as accept() or recvfrom(). If the data flow is based on HIP, the ship_hit field contains the peer's HIT. For a non-HIP IPv6 data flow, the field contains the peer's IPv6 address. For a non-HIP IPv4 data flow, the field contains the peer's IPv4 address in IPv4-mapped IPv6 address format as described in Section 3.7 of [RFC3493]. Section 4.5 describes how the application can verify the type of address returned by the sockets API calls.
ソケットがsockaddr_hip構造、つまりpf_hipプロトコルファミリーを介してバインドまたは接続されている場合、システムはこのソケットのaf_hipファミリー、つまりsockaddr_hip構造のアドレスのみを返します。これは、Accept（）やRecvfrom（）など、アプリケーションにアドレスを提供するすべての関数に適用されます。データフローが股関節に基づいている場合、SIP_HITフィールドにはピアのヒットが含まれています。非HIP IPv6データフローの場合、フィールドにはピアのIPv6アドレスが含まれています。非HIP IPv4データフローの場合、フィールドには、[RFC3493]のセクション3.7で説明されているように、IPv4-Mapped IPv6アドレス形式のピアのIPv4アドレスが含まれています。セクション4.5では、アプリケーションがSockets API呼び出しによって返されるアドレスのタイプをどのように検証できるかについて説明します。
An application uses the sockets API as follows to set up a connection or to send messages in HIP opportunistic mode (cf. [RFC5201]). First, the application associates a socket with at least one IP address of the destination peer via setting the SHIM_LOCLIST_PEER_PREF socket option. It then uses outgoing socket functions such as connect(), sendto(), or sendmsg() with the HIP_ENDPOINT_ANY or HIP_HIT_ANY wildcard address in the ship_hit field of the sockaddr_hip structure. With the HIP_HIT_ANY address, the underlying system allows only HIP-based data flows with the corresponding socket. For incoming packets, the system discards all non-HIP-related traffic arriving at the socket. For outgoing packets, the system returns -1 in the socket call and sets errno to an appropriate error type when the system failed to deliver the packet over a HIP-based data channel. The semantics of using HIP_ENDPOINT_ANY are the subject of further experimentation in the context of opportunistic mode. Such use may result in a data flow either with or without HIP.
アプリケーションは、ソケットAPIを次のように使用して接続を設定するか、股関節の日和見モードでメッセージを送信します（[RFC5201]を参照）。まず、アプリケーションは、shim_loclist_peer_prefソケットオプションを設定して、宛先ピアの少なくとも1つのIPアドレスとソケットを関連付けます。次に、sockaddr_hip構造のship_hitフィールドでhip_endpoint_anyまたはhip_hit_any wildcardアドレスを使用して、connect（）、sendto（）、sendmsg（）などの送信ソケット関数を使用します。HIP_HIT_ANYアドレスを使用すると、基礎となるシステムにより、対応するソケットを使用した股関節ベースのデータフローのみが可能になります。着信パケットの場合、システムはソケットに到着するすべての非ヒップ関連トラフィックを破棄します。発信パケットの場合、システムはソケット呼び出しで-1を返し、システムが股関節ベースのデータチャネル上でパケットを配信できなかった場合に適切なエラータイプにerrnoを設定します。hip_endpoint_anyを使用するセマンティクスは、日和見モードのコンテキストでのさらなる実験の対象です。このような使用により、股関節の有無にかかわらずデータフローが発生する可能性があります。
The HIP APIs introduce a new address family, AF_HIP, that HIP-aware applications can use to control the address type returned from the getaddrinfo() function [RFC3493] [POSIX]. The getaddrinfo() function uses a data structure called addrinfo in its "hints" and "res" arguments, which are described in more detail in the next section. The addrinfo data structure is illustrated in Figure 3.
HIP APIは、hip-awareアプリケーションがgetaddrinfo（）関数[RFC3493] [POSIX]から返されるアドレスタイプを制御するために使用できる新しいアドレスファミリAF_HIPを導入します。getAddrinfo（）関数は、「ヒント」と「RES」引数でAddRinfoと呼ばれるデータ構造を使用します。これらについては、次のセクションで詳細に説明します。AddRINFOデータ構造を図3に示します。
#include <netdb.h>
struct addrinfo {
int ai_flags; /* e.g., AI_CANONNAME */
int ai_family; /* e.g., AF_HIP */
int ai_socktype; /* e.g., SOCK_STREAM */
int ai_protocol; /* 0 or IPPROTO_HIP */
socklen_t ai_addrlen; /* size of *ai_addr */
struct sockaddr *ai_addr; /* sockaddr_hip */
char *ai_canonname; /* canon. name of the host */
struct addrinfo *ai_next; /* next endpoint */
int ai_eflags; /* RFC 5014 extension */
};
Figure 3
図3
An application resolving with the ai_family field set to AF_UNSPEC in the hints argument may receive any kind of socket address structures, including sockaddr_hip. When the application wants to receive only HITs contained in sockaddr_hip structures, it should set the ai_family field to AF_HIP. Otherwise, the resolver does not return any sockaddr_hip structures. The resolver returns EAI_FAMILY when AF_HIP is requested but not supported.
ヒント引数でAI_FamilyフィールドをAF_UNSPECに設定して解決するアプリケーションは、Sockaddr_hipを含むあらゆる種類のソケットアドレス構造を受信する場合があります。アプリケーションがsockaddr_hip構造に含まれるヒットのみを受信したい場合、ai_familyフィールドをaf_hipに設定する必要があります。それ以外の場合、リゾルバーはsockaddr_hip構造を返さない。Resolverは、af_hipが要求されたがサポートされていない場合にeai_familyを返します。
The resolver ignores the AI_PASSIVE flag when the application sets the family in hints to AF_HIP.
リゾルバーは、アプリケーションが家族をAF_HIPにヒントに設定するときにAI_PASSIVEフラグを無視します。
The system may have a HIP-aware interposing DNS agent as described in Section 3.2 of [RFC5338]. In such a case, the DNS agent may, according to local policy, transparently return LSIs or HITs in sockaddr_in and sockaddr_in6 structures when available. A HIP-aware application can override this local policy in two ways. First, the application can set the family to AF_HIP in the hints argument of getaddrinfo() when it requests only sockaddr_hip structures. Second, the application can set the AI_NO_HIT flag to prevent the resolver from returning HITs in any kind of data structures.
[RFC5338]のセクション3.2で説明されているように、システムには股関節が認識されるDNSエージェントがある場合があります。そのような場合、DNSエージェントは、ローカルポリシーによれば、利用可能な場合はsockaddr_inおよびsockaddr_in6構造のLSIまたはヒットを透過的に返すことができます。ヒップアウェアアプリケーションは、このローカルポリシーを2つの方法でオーバーライドできます。まず、アプリケーションは、sockaddr_hip構造のみを要求する場合、getaddrinfo（）のヒントの議論で家族をaf_hipに設定できます。第二に、アプリケーションはAI_NO_HITフラグを設定して、リゾルバーがあらゆる種類のデータ構造でヒットを返すのを防ぐことができます。
When getaddrinfo() returns resolved outputs in the output "res" argument, it sets the family to AF_HIP when the related structure is sockaddr_hip.
getaddrinfo（）が出力「res」引数で解決された出力を返すと、関連する構造がsockaddr_hipである場合、家族をaf_hipに設定します。
A HIP-aware application creates the sockaddr_hip structures manually or obtains them from the resolver. The explicit configuration of locators is described in [RFC6316]. This document defines
ヒップアウェアアプリケーションは、Sockaddr_hip構造を手動で作成するか、リゾルバーから取得します。ロケーターの明示的な構成は[RFC6316]で説明されています。このドキュメントは定義しています
"automated" resolver extensions for the getaddrinfo() resolver [RFC3493]. Other resolver calls, such as gethostbyname() and getservbyname(), are not defined in this document. The getaddrinfo() resolver interface is shown in Figure 4.
getaddrinfo（）リゾルバー[RFC3493]の「自動化された」リゾルバー拡張機能。gethostbyname（）やgetServbyName（）などのその他のリゾルバー呼び出しは、このドキュメントでは定義されていません。getaddrinfo（）リゾルバーインターフェイスを図4に示します。
#include <netdb.h>
int getaddrinfo(const char *nodename,
const char *servname,
const struct addrinfo *hints,
struct addrinfo **res)
void free_addrinfo(struct addrinfo *res)
Figure 4
図4
As described in [RFC3493], the getaddrinfo() function takes nodename, servname, and hints as its input arguments. It places the result of the query into the res output argument. The return value is zero on success, or a non-zero error value on error. The nodename argument specifies the hostname to be resolved; a NULL argument denotes the HITs of the local host. The servname parameter declares the port number to be set in the socket addresses in the res output argument. The nodename and servname arguments cannot both be NULL at the same time.
[rfc3493]で説明されているように、getaddrinfo（）関数は、nodename、servname、およびヒントを入力引数として取ります。クエリの結果をRES出力引数に入れます。収益値は成功した場合はゼロ、またはエラー時の非ゼロエラー値です。nodename引数は、解決するホスト名を指定します。ヌルの引数は、ローカルホストのヒットを示します。ServNameパラメーターは、RES出力引数のソケットアドレスに設定されるポート番号を宣言します。NodenameとServnameの引数は、両方を同時にnullすることはできません。
The input argument "hints" acts like a filter that defines the attributes required from the resolved endpoints. A NULL hints argument indicates that any kind of endpoint is acceptable.
入力引数「ヒント」は、解決されたエンドポイントから必要な属性を定義するフィルターのように機能します。ヌルのヒントの引数は、あらゆる種類のエンドポイントが許容できることを示しています。
The output argument "res" is dynamically allocated by the resolver. The application frees the res argument with the free_addrinfo function. The res argument contains a linked list of the resolved endpoints. The linked list contains only sockaddr_hip structures when the input argument has the family set to AF_HIP. When the family is zero, the list contains sockaddr_hip structures before sockaddr_in and sockaddr_in6 structures.
出力引数「res」は、リゾルバーによって動的に割り当てられます。このアプリケーションは、free_addrinfo関数を使用してRES引数を解放します。RES引数には、解決されたエンドポイントのリンクされたリストが含まれています。リンクされたリストには、入力引数にファミリがAF_HIPに設定されている場合、Sockaddr_hip構造のみが含まれています。ファミリがゼロの場合、リストにはSockaddr_inおよびSockaddr_in6構造の前のSockaddr_hip構造が含まれています。
The resolver can return a HIT that maps to multiple locators. The resolver may cache the locator mappings with the HIP module. The HIP module manages the multiple locators according to system policies of the host. The multihoming document [RFC6316] describes how an application can override system default policies.
リゾルバーは、そのマップを複数のロケーターにマップするヒットを返すことができます。リゾルバーは、股関節モジュールでロケーターマッピングをキャッシュする場合があります。HIPモジュールは、ホストのシステムポリシーに従って複数のロケーターを管理します。Multihoming Document [RFC6316]は、アプリケーションがシステムのデフォルトポリシーをどのようにオーバーライドできるかを説明しています。
It should be noted that the application can configure the HIT explicitly without setting the locator, or the resolver can fail to resolve any locator. In this scenario, the application relies on the system to map the HIT to an IP address. When the system fails to provide the mapping, it returns -1 in the called sockets API function to the application and sets errno to EADDRNOTAVAIL.
ロケーターを設定せずにアプリケーションが明示的にHITを構成できるか、リゾルバーがロケーターの解決に失敗する可能性があることに注意する必要があります。このシナリオでは、アプリケーションはシステムに依存して、ヒットをIPアドレスにマッピングします。システムがマッピングの提供に失敗すると、呼び出されたソケットAPI関数の-1をアプリケーションに戻し、errnoをeaddrnotavailに設定します。
The sockaddr_hip structure does not contain a HIT when the application uses the HIP_HIT_ANY_* or HIP_ENDPOINT_ANY constants. In such a case, the application can discover the local and peer HITs using the getsockname() and getpeername() functions after the socket is connected. The functions getsockname() and getpeername() always output a sockaddr_hip structure when the family of the socket is AF_HIP. The application should be prepared to also handle IPv4 and IPv6 addresses in the ship_hit field, as described in Section 4.1, in the context of the HIP_ENDPOINT_ANY constant.
sockaddr_hip構造には、アプリケーションがhip_hit_any_*またはhip_endpoint_any定数を使用する場合、ヒットは含まれません。このような場合、アプリケーションは、ソケットが接続された後にgetSockName（）およびgetPeername（）関数を使用してローカルおよびピアヒットを発見できます。関数getSockName（）およびgetPeerName（）は、ソケットのファミリがAF_HIPの場合、常にSOCKADDR_HIP構造を出力します。アプリケーションは、hip_endpoint_any定数のコンテキストで、セクション4.1で説明されているように、ship_hitフィールドのIPv4およびIPv6アドレスも処理するように準備する必要があります。
A client-side application can choose its source HIT by, for example, querying all of the local HITs with getaddrinfo() and associating one of them with the socket using bind(). This section describes another method for a client-side application to affect the selection of the source HIT type where the application does not call bind() explicitly. Instead, the application just specifies the preferred requirements for the source HIT type.
クライアント側のアプリケーションは、たとえば、getaddrinfo（）でローカルヒットのすべてをクエリし、それらの1つをbind（）を使用してソケットに関連付けることによって、そのソースヒットを選択できます。このセクションでは、クライアント側のアプリケーションがソースヒットタイプの選択に影響を与える別の方法について説明します。ここでは、アプリケーションがbind（）を明示的に呼び出していません。代わりに、アプリケーションは、ソースヒットタイプの優先要件を指定するだけです。
The sockets API for source address selection [RFC5014] defines socket options to allow applications to influence source address selection mechanisms. In some cases, HIP-aware applications may want to influence source HIT selection, in particular whether an outbound connection should use a published or anonymous HIT. Similar to IPV6_ADDR_PREFERENCES defined in [RFC5014], the socket option HIT_PREFERENCES is defined for HIP-based sockets. This socket option can be used with setsockopt() and getsockopt() calls to set and get the HIT selection preferences affecting a HIP-enabled socket. The socket option value (optval) is a 32-bit unsigned integer argument. The argument consists of a number of flags where each flag indicates an address selection preference that modifies one of the rules in the default HIT selection; these flags are shown in Table 2.
ソースアドレスの選択[RFC5014]のソケットAPIは、ソケットオプションを定義して、アプリケーションがソースアドレスの選択メカニズムに影響を与えることを可能にします。場合によっては、ヒップアウェアアプリケーションは、特にアウトバウンド接続が公開されたヒットまたは匿名のヒットを使用するかどうかにかかわらず、ソースヒットの選択に影響を与えることがあります。[RFC5014]で定義されているIPv6_addr_preferencesと同様に、SocketオプションHIT_PRECERENCESは、股関節ベースのソケットに対して定義されています。このソケットオプションは、setsockopt（）およびgetsockopt（）で使用することができます。ソケットオプション値（OptVal）は、32ビットの符号なし整数引数です。引数は、各フラグがデフォルトのヒット選択のルールの1つを変更するアドレス選択選好を示す多くのフラグで構成されています。これらのフラグを表2に示します。
+---------------------------+-------------------------+
| Socket Option | Purpose |
+---------------------------+-------------------------+
| HIP_PREFER_SRC_HIT_TMP | Prefer an anonymous HIT |
| HIP_PREFER_SRC_HIT_PUBLIC | Prefer a public HIT |
+---------------------------+-------------------------+
Table 2
表2
If the system is unable to assign the type of HIT that is requested, at HIT selection time, the socket call (connect(), sendto(), or sendmsg()) will fail, and errno will be set to EINVAL. If the application tries to set both of the above flags for the same socket, this also results in the error EINVAL.
システムが要求されるヒットのタイプを割り当てることができない場合、ヒット選択時間にソケット呼び出し（connect（）、sendto（）、またはsendmsg（））が失敗し、errnoがeinvalに設定されます。アプリケーションが上記の両方のフラグを同じソケットに設定しようとする場合、これによりエラーが発生します。
An application that uses the HIP_ENDPOINT_ANY constant may want to check whether the actual communication was based on HIP or not. Also, the application may want to verify whether a HIT belonging to the local host is public or anonymous. The application accomplishes this using a new function called sockaddr_is_srcaddr(), which is illustrated in Figure 5.
hip_endpoint_any定数を使用するアプリケーションは、実際の通信が股関節に基づいているかどうかを確認することをお勧めします。また、アプリケーションは、ローカルホストに属するヒットが公開されているか匿名であるかを確認することをお勧めします。このアプリケーションは、図5に示すsockaddr_is_srcaddr（）と呼ばれる新しい関数を使用してこれを達成します。
#include <netinet/hip.h>
short sockaddr_is_srcaddr(struct sockaddr *srcaddr, uint64_t flags);
short sockaddr_is_srcaddr（struct sockaddr *srcaddr、uint64_t flags）;
Figure 5
図5
The sockaddr_is_srcaddr() function operates in the same way as the inet6_is_srcaddr() function [RFC5014], which can be used to verify the type of an address belonging to the local host. The difference is that the sockaddr_is_srcaddr() function handles sockaddr_hip structures in addition to sockaddr_in6, and possibly other socket structures in further extensions. Also, the length of the flags argument is 64 bits instead of 32 bits, because the new function handles the same flags as defined in [RFC5014], in addition to two HIP-specific flags, HIP_PREFER_SRC_HIT_TMP and HIP_PREFER_SRC_HIT_PUBLIC. With these two flags, the application can distinguish anonymous HITs from public HITs.
sockaddr_is_srcaddr（）関数は、inet6_is_srcaddr（）関数[rfc5014]と同じように動作します。これは、ローカルホストに属するアドレスのタイプを検証するために使用できます。違いは、sockaddr_is_srcaddr（）関数がsockaddr_in6に加えてsockaddr_hip構造を処理し、さらにはさらに拡張中の他のソケット構造を処理することです。また、フラグの引数の長さは32ビットではなく64ビットです。これは、新しい関数が[RFC5014]で定義されているのと同じフラグを処理し、2つのhip固有フラグに加えて、hip_prefer_src_hit_tmpとhip_prefer_src_hit_public_bublicであるためです。これらの2つのフラグを使用すると、アプリケーションは匿名のヒットをパブリックヒットと区別できます。
When given an AF_INET6 socket, sockaddr_is_srcaddr() behaves the same way as the inet6_is_srcaddr() function as described in [RFC5014]. With an AF_HIP socket, the function returns 1 when the HIT contained in the socket address structure corresponds to a valid HIT of the local host and the HIT satisfies the given flags. The function returns -1 when the HIT does not belong to the local host or the flags are not valid. The function returns 0 when the preference flags are valid but the HIT does not match the given flags. The function also returns 0 on a sockaddr_hip structure containing a HIP_ENDPOINT_ANY or HIP_HIT_ANY_* wildcard.
AF_INET6ソケットが与えられた場合、sockaddr_is_srcaddr（）は、[RFC5014]で説明されているように、INET6_IS_SRCADDR（）関数と同じように動作します。AF_HIPソケットを使用すると、ソケットアドレス構造に含まれるヒットがローカルホストの有効なヒットに対応し、ヒットが指定されたフラグを満たしている場合、関数は1を返します。ヒットがローカルホストに属さない場合、またはフラグが無効になっている場合、関数は-1を返します。設定フラグが有効であるが、ヒットが指定されたフラグと一致しない場合、関数は0を返します。また、この関数は、hip_endpoint_anyまたはhip_hit_any_*ワイルドカードを含むsockaddr_hip構造で0を返します。
The sockaddr_is_srcaddr() interface applies only to local HITs. Applications can call the function hip_is_hit() to verify that the given hit_hit_t pointer has the HIT prefix. The function is illustrated in Figure 6.
sockaddr_is_srcaddr（）インターフェイスは、ローカルヒットにのみ適用されます。アプリケーションは、function hip_is_hit（）を呼び出して、指定されたhit_hit_tポインターにヒットプレフィックスがあることを確認できます。関数を図6に示します。
#include <netinet/hip.h>
short hip_is_hit(hip_hit_t *hit);
Figure 6
図6
The hip_is_hit() function returns 1 when the given argument contains the HIT prefix. The function returns -1 on error and sets errno appropriately. The function returns 0 when the argument does not have the HIT prefix. The function also returns 0 when the argument is a HIP_ENDPOINT_ANY or HIP_HIT_ANY_* wildcard.
hip_is_hit（）関数は、指定された引数にヒットプレフィックスが含まれている場合に1を返します。関数はエラーで-1を返し、errnoを適切に設定します。引数にヒットプレフィックスがない場合、関数は0を返します。この関数は、引数がhip_endpoint_anyまたはhip_hit_any_* wildcardである場合に0を返します。
The system resolver, or the HIP module, maps HITs to locators implicitly. However, some applications may want to specify initial locator mappings explicitly. In such a case, the application first creates a socket with AF_HIP as the domain argument. Second, the application may get or set locator information with one of the following shim socket options as defined in the multihoming extensions in [RFC6316]. The related socket options are summarized briefly in Table 3.
システムリゾルバー、または股関節モジュールは、暗黙的にロケーターにヒットします。ただし、一部のアプリケーションでは、初期のロケーターマッピングを明示的に指定する場合があります。そのような場合、アプリケーションは最初にドメイン引数としてAF_HIPを備えたソケットを作成します。第二に、[RFC6316]のマルチホーム拡張機能で定義されているように、次のシムソケットオプションのいずれかを使用して、アプリケーションがロケーター情報を取得または設定する場合があります。関連するソケットオプションを表3に簡単に要約します。
+---------------------+---------------------------------------------+
| optname | description |
+---------------------+---------------------------------------------+
| SHIM_LOC_LOCAL_PREF | Get or set the preferred locator on the |
| | local side for the context associated with |
| | the socket. |
| SHIM_LOC_PEER_PREF | Get or set the preferred locator on the |
| | remote side for the context associated with |
| | the socket. |
| SHIM_LOCLIST_LOCAL | Get or set a list of locators associated |
| | with the local Endpoint Identifier (EID). |
| SHIM_LOCLIST_PEER | Get or set a list of locators associated |
| | with the peer's EID. |
| SHIM_LOC_LOCAL_SEND | Set or get the default source locator of |
| | outgoing IP packets. |
| SHIM_LOC_PEER_SEND | Set or get the default destination locator |
| | of outgoing IP packets. |
+---------------------+---------------------------------------------+
Table 3
表3
As an example of locator mappings, a connection-oriented application creates a HIP-based socket and sets the SHIM_LOCLIST_PEER socket option on the socket. The HIP module uses the first address contained in the option if multiple addresses are provided. If the application provides one or more addresses in the SHIM_LOCLIST_PEER setsockopt call, the system should not connect to the host via another destination address, in case the application intends to restrict the range of addresses permissible as a policy choice. The application can override the default peer locator by setting the SHIM_LOC_PEER_PREF socket option if necessary. Finally, the application provides a specific HIT in the ship_hit field of the sockaddr_hip in the connect() system call. If the system cannot reach the HIT at one of the addresses provided, the outbound sockets API functions (connect(), sendmsg(), etc.) return -1 and set errno to EINVALIDLOCATOR.
ロケーターマッピングの例として、接続指向のアプリケーションはヒップベースのソケットを作成し、ソケットにshim_loclist_peerソケットオプションを設定します。HIPモジュールは、複数のアドレスが提供されている場合、オプションに含まれる最初のアドレスを使用します。アプリケーションがshim_loclist_peer setsockoptコールで1つ以上のアドレスを提供する場合、アプリケーションがポリシーの選択として許容されるアドレスの範囲を制限することを意図した場合に、システムは別の宛先アドレスを介してホストに接続しないでください。必要に応じて、shim_loc_peer_prefソケットオプションを設定することにより、アプリケーションはデフォルトのピアロケーターをオーバーライドできます。最後に、アプリケーションは、Connect（）システムコールのSockaddr_hipのSip_hitフィールドで特定のヒットを提供します。システムが提供されたアドレスの1つでヒットに到達できない場合、アウトバウンドソケットAPI関数（connect（）、sendmsg（）など）は-1を返し、errnoをeinvalidlocatorに設定します。
Applications may also choose to associate local addresses with sockets. The procedures specified in [RFC6316] are followed in this case.
アプリケーションは、ローカルアドレスをソケットに関連付けることもできます。この場合、[RFC6316]で指定された手順に従います。
Another use case is to use the opportunistic mode when the destination HIT is specified as a wildcard. The application sets one or more destination addresses using the SHIM_LOCLIST_PEER socket option as described earlier in this section, and then calls connect() with the wildcard HIT. The connect() call returns -1 and sets errno to EADDRNOTAVAIL when the application connects to a wildcard without specifying any destination address.
別のユースケースは、宛先ヒットがワイルドカードとして指定されているときに、日和見モードを使用することです。アプリケーションは、このセクションで前述のようにshim_loclist_peerソケットオプションを使用して1つ以上の宛先アドレスを設定し、ワイルドカードヒットでconnect（）を呼び出します。connect（）コールは-1を返し、アプリケーションが宛先アドレスを指定せずにワイルドカードに接続したときにerrnoをeaddrnotavailに設定します。
Applications using datagram-oriented sockets can use ancillary data to control the locators, as described in detail in [RFC6316].
[RFC6316]で詳細に説明されているように、データグラム指向のソケットを使用したアプリケーションは、補助データを使用してロケーターを制御できます。
Table 4 summarizes the new constants and structures defined in this document.
表4は、このドキュメントで定義されている新しい定数と構造をまとめたものです。
+-----------------+-----------------------+
| Header | Definition |
+-----------------+-----------------------+
| <sys/socket.h> | AF_HIP |
| <sys/socket.h> | PF_HIP |
| <netinet/in.h> | IPPROTO_HIP |
| <netinet/hip.h> | HIP_HIT_ANY |
| <netinet/hip.h> | HIP_HIT_ANY_PUB |
| <netinet/hip.h> | HIP_HIT_ANY_TMP |
| <netinet/hip.h> | HIP_ENDPOINT_ANY |
| <netinet/hip.h> | HIP_HIT_PREFERENCES |
| <netinet/hip.h> | hip_hit_t |
| <netdb.h> | AI_NO_HIT |
| <netinet/hip.h> | sockaddr_hip |
| <netinet/hip.h> | sockaddr_is_srcaddr() |
| <netinet/hip.h> | hip_is_hit() |
+-----------------+-----------------------+
Table 4
表4
This document describes an API for HIP and therefore depends on the mechanisms defined in the HIP protocol suite. Security concerns associated with HIP itself are specified in [RFC4423], [RFC4843], [RFC5201], [RFC5205], and [RFC5338].
このドキュメントは、股関節のAPIについて説明するため、股関節プロトコルスイートで定義されているメカニズムに依存します。股関節自体に関連するセキュリティの懸念は、[RFC4423]、[RFC4843]、[RFC5201]、[RFC5205]、および[RFC5338]で指定されています。
The HIP_ENDPOINT_ANY constant can be used to accept incoming data flows or create outgoing data flows without HIP. The application should use the sockaddr_is_srcaddr() function to validate the type of connection in order to, for example, inform the user of the lack of HIP-based security. The use of the HIP_HIT_ANY_* constants is recommended in security-critical applications and systems.
hip_endpoint_any定数を使用して、着信データフローを受け入れるか、股関節なしで発信データフローを作成できます。アプリケーションは、sockaddr_is_srcaddr（）関数を使用して、たとえば股関節ベースのセキュリティの欠如をユーザーに通知するために、接続のタイプを検証する必要があります。hip_hit_any_*定数の使用は、セキュリティ批判的なアプリケーションとシステムで推奨されます。
It should be noted that the wildcards described in this document are not suitable for identifying end hosts. Instead, applications should use getsockname() and getpeername() as described in Section 4.3 to identify an end host.
このドキュメントに記載されているワイルドカードは、最終ホストの識別には適していないことに注意する必要があります。代わりに、アプリケーションは、セクション4.3で説明されているようにgetSockName（）およびgetPeerName（）を使用して、エンドホストを識別する必要があります。
Future proofing of HITs was discussed during the design of this API. If HITs longer than 128 bits are required at the application layer, this will require explicit support from the applications, because they can store or cache HITs with their explicit sizes. To support longer HITs, further extensions of this API may define an additional flag for getaddrinfo() to generate different kinds of socket address structures for HIP.
ヒットの将来の証明は、このAPIの設計中に議論されました。アプリケーションレイヤーで128ビット以上のヒットが必要な場合、これは、明示的なサイズでヒットを保存またはキャッシュできるため、アプリケーションからの明示的なサポートが必要になります。より長いヒットをサポートするために、このAPIのさらなる拡張は、getaddrinfo（）の追加フラグを定義して、股関節のさまざまな種類のソケットアドレス構造を生成する場合があります。
Thanks to Jukka Ylitalo and Pekka Nikander for their original contributions, time, and effort to the native HIP APIs. Thanks to Yoshifuji Hideaki and Stefan Goetz for their contributions to this document.
Jukka YlitaloとPekka Nikanderに、元のヒップAPIへの元の貢献、時間、努力に感謝します。Yoshifuji HideakiとStefan Goetzに、この文書への貢献に感謝します。
Kristian Slavov, Julien Laganier, Jaakko Kangasharju, Mika Kousa, Jan Melen, Andrew McGregor, Sasu Tarkoma, Lars Eggert, Joe Touch, Antti Jarvinen, Anthony Joseph, Teemu Koponen, Jari Arkko, Ari Keranen, Juha-Matti Tapio, Shinta Sugimoto, Philip Matthews, Joakim Koskela, Jeff Ahrenholz, Tobias Heer, and Gonzalo Camarillo have provided valuable ideas and feedback. Thanks to Nick Stoughton from the Austin group for POSIX-related comments. Thanks also to the APPS area folks, including Stephane Bortzmeyer, Chris Newman, Tony Finch, "der Mouse", and Keith Moore.
クリスチャン・スラボフ、ジュリエン・ラガニエ、ジャココ・カンガシャルジュ、ミカ・クーサ、ヤン・メレン、アンドリュー・マクレガー、サス・タルコマ、ラース・エッガート、ジョー・タッチ、アントティ・ジュヴィネン、アンソニー・ジョセフ、テム・コポネン、ジャリ・アーク、アリ・ケラネン、ジュハ・マッティ・タ・タパイブフィリップ・マシューズ、ジョキム・コスケラ、ジェフ・アフレンホルツ、トビアス・ヒーア、ゴンザロ・カマリロは貴重なアイデアとフィードバックを提供しました。Posix関連のコメントをしてくれたオースティングループのニックストートンに感謝します。Stephane Bortzmeyer、Chris Newman、Tony Finch、「Der Mouse」、Keith Mooreなどのアプリエリアの人々にも感謝します。
[POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology -- Portable Operating System Interface (POSIX). Open group Technical Standard: Base Specifications, Issue 7", September 2008, <http://www.opengroup.org/austin>.
[POSIX] "IEEEStd。1003.1-2008情報技術の標準 - ポータブルオペレーティングシステムインターフェイス（POSIX）。オープングループ技術標準：基本仕様、第7"、2008年9月、<http://www.opengroup.org/オースティン>。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J。、およびW. Stevens、「IPv6の基本ソケットインターフェイス拡張」、RFC 3493、2003年2月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423] Moskowitz、R。およびP. Nikander、「ホストアイデンティティプロトコル（HIP）アーキテクチャ」、RFC 4423、2006年5月。
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
[RFC4843] Nikander、P.、Laganier、J。、およびF. Dupont、「オーバーレイのルーティング可能な暗号ハッシュ識別子（蘭）のIPv6プレフィックス」、RFC 4843、2007年4月。
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007.
[RFC5014] Nordmark、E.、Chakrabarti、S。、およびJ. Laganier、「ソースアドレス選択のためのIPv6ソケットAPI」、RFC 5014、2007年9月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P.、Ed。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", RFC 5205, April 2008.
[RFC5205] Nikander、P。およびJ. Laganier、「ホストIDプロトコル（HIP）ドメイン名システム（DNS）拡張機能」、RFC 5205、2008年4月。
[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host Identity Protocol with Legacy Applications", RFC 5338, September 2008.
[RFC5338] Henderson、T.、Nikander、P。、およびM. Komu、「ホストIDプロトコルをレガシーアプリケーションで使用」、RFC 5338、2008年9月。
[RFC6316] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, Ed., "Sockets Application Program Interface (API) for Multihoming Shim", RFC 6316, July 2011.
[RFC6316] Komu、M.、Bagnulo、M.、Slavov、K。、およびS. Sugimoto、ed。、「Sockets Application Program Interface（API）Multihoming Shim for RFC 6316、2011年7月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533] Nordmark、E。およびM. Bagnulo、「SHIM6：IPv6のレベル3マルチホミングシムプロトコル」、RFC 5533、2009年6月。
Authors' Addresses
著者のアドレス
Miika Komu Aalto University Espoo Finland
ミイカ・コム・アールト大学エスポー・フィンランド
Phone: +358505734395
Fax: +358947025014
EMail: miika@iki.fi
URI: http://cse.aalto.fi/research/groups/datacommunications/people/
Thomas Henderson The Boeing Company P.O. Box 3707 Seattle, WA USA
トーマス・ヘンダーソンボーイングカンパニーP.O.ボックス3707シアトル、ワシントンアメリカ
EMail: thomas.r.henderson@boeing.com