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)
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.
この文書では、ホスト識別プロトコル（HIP）の現在のソケットAPIへの拡張を定義します。拡張子は、DNS解決を経て発見された公開鍵ベースの識別子を使用することに焦点を当て、だけでなく、ホスト識別タグ（ヒット）とロケータの間に手動バインディングのためのインタフェースを定義します。拡張子を持つ、アプリケーションは、ローカルポリシーに従って、通信は非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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6317.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................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ベースのソケットアプリケーションプログラミングインターフェイス（API）HIP対応のアプリケーションで明示的にHIPベースの識別子を処理するための拡張機能を定義します。それは、識別子を管理するために、アプリケーション、または高レベルのプログラミング言語やライブラリ次第です。この文書に記載されている拡張子は、DNS解決のステップは、新しいソケットを作成する前に発生し、システムがキャッシュまたはロケータ（IPアドレス）に識別子を解決するそうことができていることを前提としていた中での使用の場合に主に関連しています。 HIPの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.
ホスト識別プロトコル（HIP）[RFC4423]はTCP / IPスタックに新しい名前空間を導入することにより、エンドポイント識別子とロケータの役割を分離することによって新しい暗号化名前空間を提案しています。 SHIM6 [RFC5533]はアイデンティティ・ロケータ分離に基づいて別のプロトコルです。この文書で指定されたAPIは、HIPに固有のものですが、他のプロトコルとその使用を妨げないために、可能な限り設計されています。他のプロトコルとこれらの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は、IPv6がオーバーレイルーティング可能な暗号学的ハッシュ識別子（ORCHID）接頭辞[RFC4843]でアドレスとして定義されているホスト識別タグ（ヒット）に基づいています。蘭は、ハッシュを使用してIPv6アドレスに結果をフィッティングホスト識別子から導出されます。このようなアドレスはヒットと呼ばれ、ORCHID接頭辞を介して他のIPv6アドレスを区別することができます。蘭は現在、IANAによって実験的配分であることに注意してください。 ORCHIDの割り当てが期限切れしていたとHIT世代が将来的に別の接頭辞を使用した場合、彼らは明示的に返さHITS上ORCHID接頭辞を確認しない限り、APIのほとんどのユーザーは、影響を受けることはないだろう。 ORCHID配分は将来の日付で削除された場合にはヒットが有効なORCHID接頭辞は蘭のための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.
アプリケーションは、視認性の程度が異なるネットワーキングスタックにHIP層とその識別子を観察することができます。 [RFC5338]は、アプリケーションが、基礎となるHIP層の完全に気づいていないれた視認性の最も低いレベルを論じています。いくつかの状況において、このようなHIP非対応のアプリケーションは、代わりにIPv4またはIPv6アドレスのようなローカルスコープ識別子（LSIの）又はヒットとしてHIPベースの識別子を使用し、識別子ロケータバインディングを観察することができません。
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.
この文書は、新しいソケットアドレスファミリ、AF_HIPを定義するために、[RFC3493]への拡張を指定します。同様に他のアドレスファミリに、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により導入されたアイデンティティ・ロケータ分離は、データグラム指向のソケット、日和見モード、およびヒットとロケータの間の手動バインディングを持ついくつかの政策関連の課題を紹介します。この文書に記載されている拡張子は実験的な性質のものであり、政策の実験をするための基本的なツールを提供しています。政策関連の問題は、さらなる実験のために残されています。
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.
要約すると、この文書に記載されている拡張子は三つの目標を持っています。最初の目標は、基礎となるシステムは、最初の接触のために使用されたアドレスにヒットを解決できることを前提とし、HIP対応アプリケーションだけではヒットに基づいて他のホストへのソケットを開くことができるようにすることです。第二の目標は、アプリケーションが明示的に未知のピア識別子との通信を開始することができるということです。 3点目は、HIP対応アプリケーションを手動でヒットにロケータをマップするためにシム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または相対ホスト名によって指定されたエンティティとのネットワーク通信を確立する前に、アプリケーションは、対応する識別子（S）に名前を変換しなければなりません。 DNSベースのホスト名に識別子翻訳は図1に示されているアプリケーションは、（A）PF_HIPファミリー内の1つ以上のソケットアドレスにFQDNを解決するステップでレゾルバを呼び出します。リゾルバは、今度は、（並列または順次）工程（b）はまた、HITとHIおよびおそらくはレスポンダのランデブーサーバとを有する1つの以上のHIPのRRにFQDNをマッピングするためにDNS FQDNを解決するために照会します場合によっては1つまたは複数のAとAAAAレコードに。 FQDNが複数のホスト識別子とロケータにマッピングすることができ、そしてこのステップはA、AAAAのためのクエリ、HI、およびおそらく他のリソースレコードを含む複数のDNSトランザクションを、関与し得ることに留意すべきです。 DNSサーバは、ステップ（c）において、HIPリソースレコードのリストで応答します。任意に、ステップ（d）において、レゾルバは、HIPモジュールとHIT・ツー・ロケータマッピングをキャッシュします。リゾルバは、ヒットにHIPレコードを変換し、工程（e）でHIPソケットアドレス構造に含まれるアプリケーションのヒットを返します。リゾルバ呼び出しのパラメータに応じて、リゾルバはまた、アプリケーションに他のソケットアドレス構造体を返すことがあります。最後に、アプリケーションは、レゾルバからソケットアドレス構造体（単数または複数）を受信し、ステップ（F）で）（例えば、接続のようなソケット・コールにそれらを使用します。
+----------+
| |
| 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.
実際には、リゾルバ機能は、さまざまな方法で実現することができます。例えば、既存のリゾルバライブラリまたはHIP対応介在剤として実装されてもよいです。
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.
HIP対応アプリケーションでのヒットとロケータにホスト名をマッピングするためのリゾルバの使用に関するこの文書の焦点で拡張。リゾルバは、暗黙的にHIPデーモンにHITとIPマッピングを通信することにより、対応するロケータ（S）とHITを関連付けることができます。しかし、アプリケーションはリゾルバと相互作用することなく、ピアHIT上で直接動作することが可能です。このような場合、アプリケーションは、IPアドレスにピアHITをマッピングするシステムに頼ることができます。また、アプリケーションは明示的に4.6節で指定されているソケットオプションを使用してIPアドレスにHITをマッピングすることができます。この文書で定義されたすべての拡張機能のフルサポートは、システムによって実装されるシムソケットオプション[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プログラミング言語の構文を使用してネイティブHIP APIを記述します。ネイティブHIP 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>.
ソケット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.
ソケット（）関数の第1引数（ドメイン）としてPF_HIPで呼び出されたとき、それはHIP通信用のソケットを作成しよう。 HIPがサポートされていない場合は、ソケット（）のデフォルトの動作をたどり、-1を返し、EAFNOSUPPORTをerrnoに設定します。
Figure 2 shows the recommended implementation of the socket address structure for HIP in Portable Operating System Interface (POSIX) format.
図2は、ポータブルオペレーティングシステムインタフェース（POSIX）形式でHIPのソケットアドレス構造の推奨実施例を示します。
#include <netinet/hip.h>
書式#include <netinetの/ hip.h>
typedef struct in6_addr hip_hit_t;
typedefは構造体の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.
ship_family sa_family_t：この必須フィールドは、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：この必須フィールドは、エンドポイント識別子が含まれています。システムは、アプリケーションにsockaddr_hip構造を通過する際に、セクション4.5で議論するように、このフィールドの値は、有効なHITはIPv4またはIPv6アドレスに設定されています。アプリケーションがシステムにsockaddr_hip構造を通過する際に、セクション4.1.1で説明したように、このフィールドは、HITまたはワイルドカードアドレスに設定されなければなりません。
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構造上で動作するアプリケーションは、ship_hitフィールドを比較するために、memcmp（）または同様の機能を使用することができます。また、ホストが複数のヒットを持つことが許可されているため、同じ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().
HIPワイルドカードアドレスは、IPv4とIPv6のワイルドカードアドレスに似ています。彼ら例えばバインドとしてソケットAPI呼び出しでローカルおよびリモートエンドポイントのship_hitフィールドに代えて、特定のヒットのに使用することができる（）（）接続、のsendto（）、またはsendmsgの（）。
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]で指定されただけのように、すべてのローカル匿名IDにソケットをバインドします。システムは、彼らが公表されているか否かに応じて、のような匿名IDをラベル付けすることがあります。 HIP_HIT_ANY_ *ワイルドカードアドレスのうちの1つを介してソケットを結合した後、アプリケーションのみHIPベースのデータフローを受信することが保証されています。 HIP_ENDPOINT_ANYワイルドカードアドレスで、ソケットは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.
ソケットは、すなわち、PF_HIPプロトコルファミリ、sockaddr_hip構造を介して結合した、または接続されている場合、システムはこのソケットのため、すなわち、sockaddr_hip構造、AF_HIPファミリーのアドレスのみを返します。これは、受け入れる（）またはのrecvfrom（）のようなアプリケーションにアドレスを提供するすべての機能に適用されます。データフローは、HIPに基づいている場合、ship_hitフィールドはピアのHITが含まれています。非HIP IPv6データフローの場合、フィールドには、ピアのIPv6アドレスが含まれています。 [RFC3493]のセクション3.7に記載されているように、非HIPのIPv4データ・フローのために、フィールドは、IPv4マップされたIPv6アドレス形式のピアのIPv4アドレスを含んでいます。 4.5節では、アプリケーションがソケット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.
次のようにアプリケーションが接続を設定するか、またはHIP日和見モード（参照[RFC5201]）にメッセージを送信するために、ソケットAPIを使用します。まず、アプリケーションがSHIM_LOCLIST_PEER_PREFソケットオプションを設定介して、宛先ピアの少なくとも1つのIPアドレスでソケットを関連付けます。次にsockaddr_hip構造のship_hit分野におけるHIP_ENDPOINT_ANY又はHIP_HIT_ANYワイルドカードアドレスにそのような接続（）（）のsendto、またはsendmsgの（）として発信ソケット関数を使用します。 HIP_HIT_ANYアドレスと、基礎となるシステムは、対応するソケットに流れるのみHIPベースのデータを可能にします。着信パケットの場合、システムはソケットに到着するすべての非HIP関連のトラフィックを破棄します。発信パケットのために、システムは、ソケット・コールに-1を返し、システムはHIPベースのデータチャネルを介してパケットを配信するために失敗した場合、適切なエラー・タイプをerrnoに設定します。 HIP_ENDPOINT_ANYを使用しての意味は、日和見モードの文脈におけるさらなる実験の対象です。このような使用して、またはHIPなしのいずれかのデータフローをもたらし得ます。
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-対応アプリケーションは、はgetaddrinfo（）関数[RFC3493] [POSIX]から返されたアドレスの種類を制御するために使用できる新しいアドレスファミリ、AF_HIPを、ご紹介します。 getaddrinfo（）関数は、次のセクションでより詳細に記載されているその「ヒント」および「RES」引数にADDRINFOと呼ばれるデータ構造を使用します。 ADDRINFOデータ構造は、図3に示されています。
#include <netdb.h>
書式#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.
ヒント引数にAF_UNSPECに設定ai_familyがフィールドで解決するアプリケーションはsockaddr_hip含むソケットアドレス構造、のいずれかの種類を受け取ることができます。アプリケーションがsockaddr_hip構造に含まれる唯一のヒットを受信したい場合は、AF_HIPするのai_familiyフィールドを設定する必要があります。そうでなければ、リゾルバはどのsockaddr_hip構造を返しません。 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に記載されているように、システムは、HIP対応介在DNS剤を有していてもよいです。利用可能な場合、このような場合には、DNSエージェントは、ローカルポリシーに従って、透過のsockaddr_inとSOCKADDR_IN6構造中のLSIやヒットを返すことができます。 HIP対応アプリケーションは、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
HIP対応アプリケーションを手動で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>
書式#include <netdb.h>
int getaddrinfo(const char *nodename, const char *servname, const struct addrinfo *hints, struct addrinfo **res) void free_addrinfo(struct addrinfo *res)
int型のgetaddrinfo（のconstのchar *ノード名、constのchar型* servnameの、constの構造体のaddrinfo *ヒント、構造体のaddrinfo ** RES）のボイドfree_addrinfo（構造体の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（）関数は、入力引数としてノード名、servnameの、およびヒントを取ります。これは、解像度の出力引数にクエリの結果を配置します。戻り値は、成功した場合にゼロ、エラー時にゼロ以外のエラー値です。ノード名の引数には、解決すべきホスト名を指定します。 NULL引数は、ローカルホストのヒットを示しています。 servnameのパラメータは、解像度の出力引数でソケットアドレスに設定するポート番号を宣言します。ノード名と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.
入力引数「ヒント」は解決エンドポイントから必要な属性を定義するフィルタのような役割を果たします。 NULLヒント引数は、エンドポイントのいずれかの種類が許容可能であることを示しています。
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引数を解放します。解像度の引数は、解決のエンドポイントのリンクリストが含まれています。入力引数が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.
リゾルバは、複数のロケータにマップHITを返すことができます。リゾルバは、HIPモジュールとロケータのマッピングをキャッシュすることができます。 HIPモジュールは、ホストのシステムポリシーに応じて複数のロケータを管理します。マルチホーミングドキュメント[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アドレスにHITをマッピングするためのシステムに依存しています。システムはマッピングを提供するために失敗した場合、それはアプリケーションに呼ばれるソケットAPI関数に-1を返し、EADDRNOTAVAILをerrnoに設定します。
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.
アプリケーションがHIP_HIT_ANY_ *またはHIP_ENDPOINT_ANY定数を使用する場合sockaddr_hip構造は、HITが含まれていません。このような場合、アプリケーションは、の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（ローカルヒットのすべてを照会）、バインド（）を使用してソケットにそれらのいずれかを関連付けることによって、そのソースHITを選択することができます。このセクションでは、アプリケーションが明示的）（バインドを呼び出さないソースHITタイプの選択に影響するクライアント側のアプリケーションのための別の方法を説明します。代わりに、アプリケーションは、単にソースHITタイプのための好適な要件を指定します。
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は、アプリケーションがソースアドレス選択メカニズムに影響を与えることができるようにソケットオプションを定義します。いくつかのケースでは、HIP対応アプリケーションは、アウトバウンド接続は、公開または匿名HITを使用する必要があるかどうか、特に、ソースHITの選択に影響を与えるようにすることもできます。 [RFC5014]で定義さIPV6_ADDR_PREFERENCESと同様に、ソケットオプションHIT_PREFERENCESはHIPベースのソケットのために定義されます。このソケットオプションのsetsockoptで使用することができます（）とはgetsockopt（）は、HIP対応のソケットに影響を与えるHITの選択の優先順位を設定し、取得するために呼び出します。 （optvalパラメータ）ソケットオプションの値は、32ビットの符号なし整数の引数です。引数は、各フラグはデフォルトのHITの選択のルールのいずれかを変更するアドレス選択優先度を示すフラグの数から成ります。これらのフラグは、表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.
システムはHITの選択時に、要求されたHITのタイプを割り当てることができない場合は、ソケット・コールは、（接続（）、のsendto（）、またはsendmsgの（））失敗し、errnoがEINVALに設定されます。アプリケーションは、同じソケットの上記フラグの両方を設定しようとした場合、これは、エラー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定数を使用するアプリケーションは、実際の通信はHIPにか基づいていたかどうかをチェックすることをお勧めします。また、アプリケーションがローカルホストに属するHITがパブリックまたは匿名であるかどうかを検証することをお勧めします。アプリケーションは、図5に示されているsockaddr_is_srcaddrと呼ばれる新しい機能（）を使用してこれを達成します。
#include <netinet/hip.h>
書式#include <netinetの/ hip.h>
short sockaddr_is_srcaddr(struct sockaddr *srcaddr, uint64_t flags);
短いsockaddr_is_srcaddr（sockaddr構造体の*のSRCADDR、uint64_tをフラグ）;
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構造、およびおそらく他のソケット構造を処理することです。また、新たな機能は[RFC5014]で定義されるように同じフラグを処理するためのフラグ引数の長さは、64ビットの代わりに32ビットであり、2 HIP固有のフラグに加えて、HIP_PREFER_SRC_HIT_TMPとHIP_PREFER_SRC_HIT_PUBLIC。これら二つのフラグを使用すると、アプリケーションが公共のヒットからの匿名のヒットを区別することができます。
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.
与えられたときに[RFC5014]に記載されているようにAF_INET6ソケット、sockaddr_is_srcaddr（）はinet6_is_srcaddr（）関数と同じように振る舞います。ソケットアドレス構造体に含まれるヒットはローカルホストの有効なHITに対応し、HITが所与のフラグを満たす場合AF_HIPソケットと、関数は1を返します。この関数は-1を返しHITは、ローカルホストに属していないかのフラグが有効でないとき。優先フラグが有効であるが、HITが与えられたフラグと一致しない場合関数は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（）インタフェースは、ローカルヒットに適用されます。アプリケーションは、与えられたhit_hit_tポインタがHITプレフィックスを持っていることを確認するために、関数hip_is_hit（）を呼び出すことができます。関数は、図6に示されています。
#include <netinet/hip.h>
書式#include <netinetの/ hip.h>
short hip_is_hit(hip_hit_t *hit);
短いhip_is_hit（hip_hit_tの*ヒット）。
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.
与えられた引数がHIT接頭辞が含まれている場合hip_is_hit（）関数は1を返します。関数は、エラー発生時に-1を返し、errnoを適切に設定します。引数はHITの接頭辞を持っていないときに関数は0を返します。引数がHIP_ENDPOINT_ANYまたはHIP_HIT_ANY_ *ワイルドカードであるとき、関数は、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.
システムリゾルバ、またはHIPモジュールは、暗黙のうちにロケーターのヒットをマッピングします。ただし、一部のアプリケーションでは、明示的に初期のロケータマッピングを指定することもできます。このような場合、アプリケーションは、最初のドメインの引数として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.
ロケータマッピングの一例として、接続指向のアプリケーションは、HIPベースのソケットを作成し、ソケットにSHIM_LOCLIST_PEERソケットオプションを設定します。複数のアドレスが提供されている場合HIPモジュールはオプションに含まれている最初のアドレスを使用しています。アプリケーションがSHIM_LOCLIST_PEERのはsetsockoptの呼び出しで1つ以上のアドレスを提供する場合、アプリケーションが政策の選択肢として許容アドレスの範囲を制限することを意図する場合には、システムは、別の宛先アドレスを介してホストに接続するべきではありません。アプリケーションは、必要に応じてSHIM_LOC_PEER_PREFソケットオプションを設定することで、デフォルトピアロケータを上書きすることができます。最後に、アプリケーションは、connect（）システムコールでsockaddr_hipのship_hitフィールドに特定のHITを提供します。システムが提供されるアドレスのいずれかで、HITに到達できない場合、アウトバウンドソケットAPI関数（（接続）等、にsendmsg（）は、）-1を返しとEINVALIDLOCATORをerrnoに設定します。
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.
別のユースケースは、宛先HITをワイルドカードとして指定されている場合日和見モードを使用することです。アプリケーションは、前述のセクションで説明したようにSHIM_LOCLIST_PEERソケットオプションを使用して1つまたは複数の宛先アドレスを設定し、ワイルドカードHITとconnect（）を呼び出します。 Connect（）の呼び出しが戻る-1とセットは、アプリケーションがすべての宛先アドレスを指定せずにワイルドカードに接続したときEADDRNOTAVAILためにerrno。
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].
この文書では、HIPのためのAPIについて説明し、したがって、HIPプロトコルスイートで定義されたメカニズムに依存します。 HIP自体に関連付けられているセキュリティ上の懸念は、[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定数は、着信データ・フローを受け入れるか、送信データを作成するために使用することができるHIPことなく流れます。アプリケーションは、例えば、HIPベースのセキュリティの欠如をユーザに知らせるために、接続の種類を検証する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のさらなる拡張は、HIP用のソケットアドレス構造体のさまざまな種類を生成するためには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.
ネイティブHIP APIに元の貢献のためユッカYlitaloとペッカNikanderのおかげで、時間、労力と。このドキュメントへの貢献のためのYoshifuji秀明とステファン・ゲッツに感謝します。
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.
クリスチャンSlavov、ジュリアンLaganier、Jaakko Kangasharju、ミカKousa、ジャンメレン、アンドリュー・マクレガー、SASU Tarkoma、ラースEggertの、ジョー・タッチ、アンティJarvinen、アンソニー・ジョセフ、テームKoponen、ヤリArkko、アリKeranen、ユハ・マッティ・タピオ、シンタ杉本、フィリップ・マシューズ、ヨアキムKoskela、ジェフAhrenholz、トビアスHeerさん、そしてゴンサロ・カマリロは貴重なアイデアやフィードバックを提供しています。 POSIX関連のコメントオースティングループからニック・ストートンに感謝します。おかげでまたステファンBortzmeyer、クリス・ニューマン、トニー・フィンチ、「DERマウス」、そしてキース・ムーアなど、APPS地域の人々へ。
[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] "IEEE標準1003.1から2008規格情報技術 - ポータブルオペレーティングシステムインタフェース（POSIX）Open Groupの技術基準：。。基本仕様、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]ギリガン、R.、トムソン、S.、バウンド、J.、マッキャン、J.、およびW.スティーブンス、 "IPv6の基本的なソケットインタフェース拡張"、RFC 3493、2003年2月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]モスコウィッツ、R.とP. Nikander、 "ホストアイデンティティプロトコル（HIP）アーキテクチャ"、RFC 4423、2006年5月。
[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.デュポン、RFC 4843、2007年4月 "オーバーレイルーティング可能な暗号ハッシュ識別子（ORCHID）のIPv6プレフィックス"。
[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]モスコウィッツ、R.、Nikander、P.、Jokela、P.、エド。、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、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、 "ホストアイデンティティプロトコル（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]ヘンダーソン、T.、Nikander、P.、およびM.こむ、 "レガシーアプリケーションをホストアイデンティティプロトコルを使用する"、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]こむ、M.、Bagnulo、M.、Slavov、K.、およびS.杉本、編、 "ソケットアプリケーション・プログラム・インターフェース（API）マルチホーミングシム用"、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
エスポー、フィンランドのMiikaこむアールト大学
Phone: +358505734395 Fax: +358947025014 EMail: miika@iki.fi URI: http://cse.aalto.fi/research/groups/datacommunications/people/
電話：+358505734395ファックス：+358947025014 Eメール：miika@iki.fi URI：http://cse.aalto.fi/research/groups/datacommunications/people/
Thomas Henderson The Boeing Company P.O. Box 3707 Seattle, WA USA
トーマス・ヘンダーソンザ・ボーイング社の私書箱ボックス3707シアトル、WA USA
EMail: thomas.r.henderson@boeing.com
メールアドレス：thomas.r.henderson@boeing.com