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
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)
主机标识协议（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解析发现的基于公钥的标识符，但也定义了主机标识标记（HITs）和定位器之间手动绑定的接口。通过这些扩展，应用程序还可以支持更宽松的安全模型，根据本地策略，在这些模型中，通信可以是非基于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.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在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
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的Socket应用程序编程接口（API）扩展，用于在HIP感知应用程序中显式处理基于HIP的标识符。由应用程序或高级编程语言或库来管理标识符。本文档中的扩展主要与创建新套接字之前发生DNS解析步骤的用例相关，并假设系统已缓存标识符或能够将标识符解析为定位器（IP地址）。[RFC5205]中描述了HIP的DNS扩展。扩展还涵盖应用程序可能希望显式地向建议的定位器提供标识符的情况，包括支持系统不知道对等主机标识的机会主义情况。
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.
主机标识协议（Host Identity Protocol，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基于主机标识标签（HITs），主机标识标签被定义为IPv6地址，并带有覆盖可路由加密哈希标识符（RUCH）前缀[RFC4843]。兰花是使用散列从主机标识符派生的，并将结果拟合到IPv6地址中。这些地址称为HITs，它们可以通过兰花前缀与其他IPv6地址区分开来。请注意，兰花目前是IANA的实验分配。如果兰花分配到期，命中率生成将来使用不同的前缀，则大多数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.
应用程序可以在网络堆栈中以不同程度的可见性观察HIP层及其标识符。[RFC5338]讨论了应用程序完全不知道底层HIP层的最低可见性级别。在某些情况下，此类不知道HIP的应用程序使用基于HIP的标识符，例如本地作用域标识符（LSI）或HITs，而不是IPv4或IPv6地址，并且无法观察标识符定位器绑定。
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的别名。这些扩展还明确描述了使用HITs的套接字的新套接字地址结构，并描述了[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感知应用程序仅基于点击就向其他主机打开套接字，前提是基础系统可以将点击解析为用于初始联系的地址。第二个目标是应用程序可以显式地启动与未知对等标识符的通信。第三个目标是说明HIP感知应用程序如何使用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 |
+---------+--------------------------------------------------------+
+---------+--------------------------------------------------------+
| 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
在应用程序可以与由给定FQDN或相对主机名命名的实体建立网络通信之前，应用程序必须将该名称转换为相应的标识符。图1说明了基于DNS的主机名到标识符的转换。应用程序在步骤（a）中调用解析器，将FQDN解析为PF_HIP系列中的一个或多个套接字地址。解析程序依次在步骤（b）中查询DNS，以将FQDN映射到具有HIT和HI的一个或多个HIP RRs，以及可能的响应程序的集合服务器，并且还（并行或顺序地）将FQDN解析为可能的一个或多个A和AAAA记录。应当注意，FQDN可以映射到多个主机标识符和定位器，并且该步骤可能涉及多个DNS事务，包括对A、AAAA、HI以及可能的其他资源记录的查询。在步骤（c）中，DNS服务器用HIP资源记录列表进行响应。可选地，在步骤（d）中，解析器缓存HIP模块的命中定位器映射。解析器将HIP记录转换为命中，并将命中返回到步骤（e）中HIP套接字地址结构中包含的应用程序。根据解析器调用的参数，解析器还可能返回其他套接字
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).
应用程序的地址结构。最后，应用程序从解析器接收套接字地址结构，并在套接字调用中使用它们，如步骤（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 | | |
+----------+ +----------+
+----------+
| |
| 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
本文档中的扩展侧重于使用解析器将主机名映射到HIP感知应用程序中的点击和定位器。冲突解决程序可以通过将HIT-to-IP映射传递给HIP守护进程，将HIT与相应的定位器隐式关联。但是，应用程序可能直接对对等命中进行操作，而不与解析器交互。在这种情况下
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地址。或者，应用程序可以使用第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编程语言的语法描述本机HipAPI。我们将描述限制在修改过的或全新的接口和数据结构上，因为本机HipAPI在其他方面与Socket 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.
当使用PF_HIP作为第一个参数（域）调用socket（）函数时，它会尝试创建用于HIP通信的套接字。如果不支持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）格式的HIP套接字地址结构的推荐实现。
#include <netinet/hip.h>
#include <netinet/hip.h>
typedef struct in6_addr hip_hit_t;
6地址hip\u hit中的typedef结构；
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;
};
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\u t ship\u 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_族字段。它的值必须是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\u t ship_port：此必填字段包含传输协议端口号。它的处理方式与结构中sockaddr_的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_标志：此必填位字段包含辅助标志。本文档未定义任何标志。此字段包含在将来的扩展中。
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\u hit ship\u hit：此必填字段包含端点标识符。当系统将sockaddr_hip结构传递给应用程序时，此字段的值设置为有效的HIT、IPv4或IPv6地址，如第4.5节所述。当应用程序将sockaddr_hip结构传递给系统时，此字段必须设置为HIT或通配符地址，如第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（）函数），但这种讨论超出了范围。其他应用程序通过使用HITs本身实现访问控制。在sockaddr_hip结构上运行的应用程序可以使用memcmp（）或类似函数来比较ship_hip字段。还应注意，相同两台主机之间的不同连接尝试可能会导致不同的点击，因为一台主机允许有多个点击。
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调用（如bind（）、connect（）、sendto（）或sendmsg（））中本地和远程端点的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
为了绑定到所有本地IPv4和IPv6地址以及HIP命中，必须将ship_hit字段设置为HIP_ENDPOINT_ANY。为了绑定到所有本地命中，ship\u hit必须包含HIP\u hit\u ANY。要仅绑定到所有本地公共点击，ship\u hit字段必须是HIP\u hit\u ANY\u PUB。值HIP_HIT_ANY_TMP仅按照[RFC4423]中的规定将套接字绑定到所有本地匿名标识符。系统可根据匿名标识符是否已被识别而将其标记为匿名标识符
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.
出版与否。通过HIP_HIT_ANY_*通配符地址之一绑定套接字后，应用程序保证只接收基于HIP的数据流。当HIP_端点_为任何通配符地址时，套接字接受基于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（）。如果数据流基于HIP，则ship_hit字段包含对等方的hit。对于非HIP IPv6数据流，该字段包含对等方的IPv6地址。对于非HIP IPv4数据流，该字段包含对等方的IPv4地址，采用[RFC3493]第3.7节所述的IPv4映射IPv6地址格式。第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.
应用程序使用sockets API建立连接或以机会主义模式发送消息，如下所示（参见[RFC5201]）。首先，应用程序通过设置SHIM_LOCLIST_peer_PREF socket选项将套接字与目标对等方的至少一个IP地址相关联。然后，它在sockaddr\u HIP结构的ship\u HIT字段中使用带有HIP\u端点\u ANY或HIP\u HIT\u任何通配符地址的传出套接字函数，如connect（）、sendto（）或sendmsg（）。使用HIP_HIT_ANY地址，底层系统只允许使用相应套接字的基于HIP的数据流。对于传入的数据包，系统丢弃到达套接字的所有非HIP相关流量。对于传出数据包，当系统无法通过基于HIP的数据通道传递数据包时，系统在套接字调用中返回-1，并将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引入了一个新的地址族AF_HIP，HIP感知应用程序可以使用它来控制从getaddrinfo（）函数[RFC3493][POSIX]返回的地址类型。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 */
};
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.
在hints参数中将ai_family字段设置为AF_unsec的应用程序可以接收任何类型的套接字地址结构，包括sockaddr_hip。当应用程序希望只接收sockaddr_hip结构中包含的点击时，它应该将ai_family字段设置为AF_hip。否则，解析器不会返回任何sockaddr_hip结构。当请求但不支持AF_HIP时，解析器返回EAI_族。
The resolver ignores the AI_PASSIVE flag when the application sets the family in hints to AF_HIP.
当应用程序在提示中将族设置为AF_HIP时，解析器将忽略AI_被动标志。
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.
系统可能具有HIP感知插入DNS代理，如[RFC5338]第3.2节所述。在这种情况下，DNS代理可以根据本地策略，在可用时透明地返回sockaddr_In和sockaddr_In 6结构中的lsi或HITs。HIP感知应用程序可以通过两种方式覆盖此本地策略。首先，当应用程序仅请求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 *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参数指定要解析的主机名；NULL参数表示本地主机的命中率。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.
输入参数“提示”的作用类似于定义解析端点所需属性的过滤器。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参数。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模块的定位器映射。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地址。当系统无法提供映射时，它会将调用的套接字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.
当应用程序使用hip_HIT_ANY_*或hip_ENDPOINT_ANY常量时，sockaddr_hip结构不包含HIT。在这种情况下，应用程序可以在连接套接字后使用getsockname（）和getpeername（）函数发现本地和对等命中。当套接字族为AF_hip时，函数getsockname（）和getpeername（）始终输出sockaddr_hip结构。应用程序还应准备好在HIP_端点_ANY常量的上下文中处理ship_hit字段中的IPv4和IPv6地址，如第4.1节所述。
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（）查询所有本地命中，并使用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.
源地址选择的套接字API[RFC5014]定义套接字选项，以允许应用程序影响源地址选择机制。在某些情况下，HIP感知应用程序可能希望影响源命中选择，特别是出站连接应使用已发布的命中还是匿名命中。与[RFC5014]中定义的IPV6_ADDR_首选项类似，套接字选项HIT_首选项是为基于HIP的套接字定义的。此套接字选项可与setsockopt（）和getsockopt（）调用一起使用，以设置和获取影响HIP启用套接字的命中选择首选项。套接字选项值（optval）是一个32位无符号整数参数。该参数由多个标志组成，其中每个标志表示修改默认命中选择中一个规则的地址选择首选项；这些标志如表2所示。
+---------------------------+-------------------------+
| Socket Option | Purpose |
+---------------------------+-------------------------+
| HIP_PREFER_SRC_HIT_TMP | Prefer an anonymous HIT |
| HIP_PREFER_SRC_HIT_PUBLIC | Prefer a public HIT |
+---------------------------+-------------------------+
+---------------------------+-------------------------+
| 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。如果应用程序尝试为同一套接字设置上述两个标志，这也会导致错误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。此外，应用程序可能希望验证属于本地主机的命中是公开的还是匿名的。应用程序使用一个名为sockaddr_is_srcadr（）的新函数来实现这一点，如图5所示。
#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_srcadr（）函数除了在6中处理sockaddr_之外，还处理sockaddr_hip结构，并且可能在进一步的扩展中处理其他套接字结构。此外，flags参数的长度是64位而不是32位，因为新函数除了处理两个HIP特定的标志（HIP_Preference_SRC_HIT_TMP和HIP_Preference_SRC_HIT_PUBLIC）外，还处理[RFC5014]中定义的相同标志。通过这两个标志，应用程序可以区分匿名点击和公开点击。
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
当给定AF_INET6套接字时，sockaddr_is_srcadr（）的行为方式与[RFC5014]中描述的INET6_is_srcadr（）函数的行为方式相同。对于AF_HIP套接字，当套接字地址结构中包含的命中对应于本地主机的有效命中并且命中满足给定标志时，函数返回1。功能
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.
当命中不属于本地主机或标志无效时，返回-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_srcadr（）接口仅适用于本地点击。应用程序可以调用函数hip_is_hit（），以验证给定的命中指针是否具有命中前缀。该功能如图6所示。
#include <netinet/hip.h>
#include <netinet/hip.h>
short hip_is_hit(hip_hit_t *hit);
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_*通配符时，该函数还返回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. |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| 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 socket选项。如果提供了多个地址，HIP模块将使用选项中包含的第一个地址。如果应用程序在SHIM_LOCLIST_PEER setsockopt调用中提供一个或多个地址，则系统不应通过另一个目标地址连接到主机，以防应用程序打算限制作为策略选择允许的地址范围。如果需要，应用程序可以通过设置SHIM_LOC_peer_PREF socket选项来覆盖默认对等定位器。最后，应用程序在connect（）系统调用中的sockaddr_hip的ship_HIT字段中提供特定的命中。如果系统无法在提供的地址之一达到HIT，则出站套接字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_对等套接字选项设置一个或多个目标地址，然后使用通配符命中调用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() |
+-----------------+-----------------------+
+-----------------+-----------------------+
| 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协议套件中定义的机制。[RFC4423]、[RFC4843]、[RFC5201]、[RFC5205]和[RFC5338]中规定了与HIP本身相关的安全问题。
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的传出数据流。应用程序应该使用sockaddr_is_srcadr（）函数来验证连接类型，例如，通知用户缺乏基于HIP的安全性。建议在安全关键型应用程序和系统中使用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的设计过程中，讨论了HITs的未来验证。如果在应用层需要大于128位的命中，这将需要应用程序的显式支持，因为它们可以使用显式大小存储或缓存命中。为了支持更长的点击时间，此API的进一步扩展可能会为getaddrinfo（）定义一个额外的标志，以便为HIP生成不同类型的套接字地址结构。
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对本地HIP 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.
克里斯蒂安·斯拉沃夫、朱利安·拉加尼耶、加卡科·康加沙茹、米卡·库萨、扬·梅伦、安德鲁·麦格雷戈、萨苏·塔科马、拉尔斯·艾格特、乔·图奇、安蒂·贾维宁、安东尼·约瑟夫、蒂姆·科波宁、贾里·阿克科、阿里·科拉宁、朱哈·马蒂·塔皮奥、杉本真塔、菲利普·马修斯、约金·科斯卡拉、杰夫·阿伦霍尔茨、托拜厄斯·希尔、，冈萨洛·卡马里洛提供了宝贵的意见和反馈。感谢奥斯汀集团的Nick Stoughton对POSIX的相关评论。也要感谢应用程序领域的人们，包括斯蒂芬·博茨梅尔、克里斯·纽曼、托尼·芬奇、“der Mouse”和基思·摩尔。
[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）.开放组技术标准：基本规范，第7期”，2008年9月<http://www.opengroup.org/austin>.
[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，“覆盖可路由加密哈希标识符（RAYD）的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 50142007年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，“主机身份协议”，RFC 52012008年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 52052008年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，“在遗留应用程序中使用主机身份协议”，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.，“多归宿垫片的套接字应用程序接口（API）”，RFC 63162011年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 55332009年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/
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
托马斯·亨德森波音公司美国华盛顿州西雅图3707号邮政信箱
EMail: thomas.r.henderson@boeing.com
EMail: thomas.r.henderson@boeing.com