Internet Research Task Force (IRTF) T. Henderson
Request for Comments: 6538 The Boeing Company
Category: Informational A. Gurtov
ISSN: 2070-1721 University of Oulu
March 2012
Internet Research Task Force (IRTF) T. Henderson
Request for Comments: 6538 The Boeing Company
Category: Informational A. Gurtov
ISSN: 2070-1721 University of Oulu
March 2012
The Host Identity Protocol (HIP) Experiment Report
主机身份协议（HIP）实验报告
Abstract
摘要
This document is a report from the IRTF Host Identity Protocol (HIP) research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. The document summarizes implications of adding HIP to host protocol stacks, Internet infrastructure, and applications. The perspective of a network operator, as well as a list of HIP experiments, are presented as well. Portions of this report may be relevant also to other network overlay-based architectures or to attempts to deploy alternative networking architectures.
本文件是IRTF主机身份协议（HIP）研究组的一份报告，记录了从研究、相关实验和研究组完成的设计中获得的集体经验和教训。该文档总结了将HIP添加到主机协议栈、Internet基础设施和应用程序的含义。此外，还介绍了网络运营商的视角以及HIP实验列表。本报告的部分内容可能还与其他基于网络覆盖的体系结构或部署替代网络体系结构的尝试相关。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the IRTF HIP Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。本RFC代表了互联网研究工作队（IRTF）IRTF HIP研究小组的共识。IRSG批准发布的文件不适用于任何级别的互联网标准；见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/rfc6538.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6538.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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
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.
本文件的出版。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
1.1. What is HIP? ...............................................3
1.2. Terminology ................................................4
1.3. Scope ......................................................4
1.4. Organization ...............................................5
2. Host Stack Implications .........................................6
2.1. Modifications to TCP/IP Stack Implementations ..............6
2.1.1. ESP Implementation Extensions .......................8
2.2. User-Space Implementations .................................9
2.3. Issues Common to Both Implementation Approaches ............9
2.3.1. User-Space Handling of HITs .........................9
2.3.2. Opportunistic Mode .................................10
2.3.3. Resolving HITs to Addresses ........................12
2.3.4. IPsec Management API Extensions ....................12
2.3.5. Transport Protocol Issues ..........................12
2.3.6. Legacy NAT Traversal ...............................14
2.3.7. Local Management of Host Identity Namespace ........14
2.3.8. Interactions with Host Firewalls ...................15
2.4. IPv4 versus IPv6 Issues ...................................15
2.5. What Have Early Adopters Learned from Experience? .........16
3. Infrastructure Implications ....................................17
3.1. Impact on DNS .............................................17
3.2. HIP-Aware Middleboxes .....................................17
3.3. HIT Resolution Infrastructure .............................18
3.4. Rendezvous Servers ........................................18
3.5. Hybrid DNS-DHT Resolution .................................19
4. Application Implications .......................................20
4.1. Non-Intrusive HIP Insertion ...............................20
4.2. Referrals .................................................20
4.3. Latency ...................................................21
5. Network Operator's Perspective .................................21
5.1. Management of the Host Identity Namespace .................21
5.2. Use of ESP Encryption .....................................22
5.3. Access Control Lists Based on HITs ........................22
5.4. Firewall Issues ...........................................23
6. User Privacy Issues ............................................24
7. Experimental Basis of This Report ..............................25
8. Related Work on ID-Locator Split ...............................27
9. Security Considerations ........................................28
10. Acknowledgments ...............................................28
11. Informative References ........................................29
1. Introduction ....................................................3
1.1. What is HIP? ...............................................3
1.2. Terminology ................................................4
1.3. Scope ......................................................4
1.4. Organization ...............................................5
2. Host Stack Implications .........................................6
2.1. Modifications to TCP/IP Stack Implementations ..............6
2.1.1. ESP Implementation Extensions .......................8
2.2. User-Space Implementations .................................9
2.3. Issues Common to Both Implementation Approaches ............9
2.3.1. User-Space Handling of HITs .........................9
2.3.2. Opportunistic Mode .................................10
2.3.3. Resolving HITs to Addresses ........................12
2.3.4. IPsec Management API Extensions ....................12
2.3.5. Transport Protocol Issues ..........................12
2.3.6. Legacy NAT Traversal ...............................14
2.3.7. Local Management of Host Identity Namespace ........14
2.3.8. Interactions with Host Firewalls ...................15
2.4. IPv4 versus IPv6 Issues ...................................15
2.5. What Have Early Adopters Learned from Experience? .........16
3. Infrastructure Implications ....................................17
3.1. Impact on DNS .............................................17
3.2. HIP-Aware Middleboxes .....................................17
3.3. HIT Resolution Infrastructure .............................18
3.4. Rendezvous Servers ........................................18
3.5. Hybrid DNS-DHT Resolution .................................19
4. Application Implications .......................................20
4.1. Non-Intrusive HIP Insertion ...............................20
4.2. Referrals .................................................20
4.3. Latency ...................................................21
5. Network Operator's Perspective .................................21
5.1. Management of the Host Identity Namespace .................21
5.2. Use of ESP Encryption .....................................22
5.3. Access Control Lists Based on HITs ........................22
5.4. Firewall Issues ...........................................23
6. User Privacy Issues ............................................24
7. Experimental Basis of This Report ..............................25
8. Related Work on ID-Locator Split ...............................27
9. Security Considerations ........................................28
10. Acknowledgments ...............................................28
11. Informative References ........................................29
This document summarizes the work and experiences of the IRTF's Host Identity Protocol research group (HIP-RG) in the 2004-2009 time frame. The HIP-RG was chartered to explore the possible benefits and consequences of deploying the Host Identity Protocol architecture [RFC4423] in the Internet and to explore extensions to HIP.
本文件总结了2004-2009年期间IRTF主机身份协议研究小组（HIP-RG）的工作和经验。特许HIP-RG的目的是探索在互联网上部署主机标识协议体系结构[RFC4423]可能带来的好处和后果，并探索对HIP的扩展。
This document was developed over several years as the main charter item for the HIP research group, and it has received inputs and reviews from most of the active research group participants. There is research group consensus to publish it.
本文件作为HIP研究小组的主要章程项目，经过几年的发展，已收到大多数活跃研究小组参与者的意见和评论。研究小组一致同意将其发表。
The Host Identity Protocol architecture introduces a new namespace, the "host identity" namespace, to the Internet architecture. The express purpose of this new namespace is to allow for the decoupling of identifiers (host identities) and locators (IP addresses) at the internetworking layer of the architecture. The contributors to HIP have expected that HIP will enable alternative solutions for several of the Internet's challenging technical problems, including potentially host mobility, host multihoming, site multihoming, IPv6 transition, NAT traversal, and network-level security. Although there have been many architectural proposals to decouple identifiers and locators over the past 20 years, HIP is one of the most actively developed proposals in this area [book.gurtov].
主机标识协议体系结构为Internet体系结构引入了一个新的名称空间，“主机标识”名称空间。这个新名称空间的明确目的是允许在体系结构的网络互连层分离标识符（主机标识）和定位器（IP地址）。HIP的贡献者预计，HIP将为互联网的一些具有挑战性的技术问题提供替代解决方案，包括潜在的主机移动性、主机多宿主、站点多宿主、IPv6转换、NAT穿越和网络级安全。尽管在过去的20年中，已经有许多将标识符和定位器解耦的架构建议，但HIP是该领域最活跃的建议之一[book.gurtov]。
The Host Identity Protocol itself provides a rapid exchange of host identities (public keys) between hosts and uses a Diffie-Hellman key exchange that is compliant with Sigma ("SIGn-and-MAc") to establish shared secrets between such endpoints [RFC5201]. The protocol is designed to be resistant to Denial-of-Service (DoS) and Man-in-the-Middle (MitM) attacks, and when used together with another suitable security protocol, such as Encapsulated Security Payload (ESP) [RFC4303], it provides encryption and/or authentication protection for upper-layer protocols such as TCP and UDP, while enabling continuity of communications across network-layer address changes.
主机标识协议本身在主机之间提供了主机标识（公钥）的快速交换，并使用符合Sigma（“签名和MAc”）的Diffie-Hellman密钥交换在此类端点之间建立共享秘密[RFC5201]。该协议旨在抵抗拒绝服务（DoS）和中间人（MitM）攻击，当与另一个合适的安全协议（如封装安全有效载荷（ESP）[RFC4303]）一起使用时，它为上层协议（如TCP和UDP）提供加密和/或身份验证保护，同时实现跨网络层通信的连续性地址更改。
A number of Experimental RFC specifications were published by the IETF's HIP working group, including the HIP base protocol [RFC5201], ESP encapsulation [RFC5202], registration extensions [RFC5203], HIP rendezvous servers [RFC5204], DNS resource records [RFC5205], and mobility management [RFC5206]. Host identities are represented as Overlay Routable Cryptographic Hash Identifiers (ORCHIDs) [RFC4843] in Internet protocols. Additionally, the research group published one RFC on requirements for traversing NATs and firewalls [RFC5207]
IETF的HIP工作组发布了许多实验性RFC规范，包括HIP基本协议[RFC5201]、ESP封装[RFC5202]、注册扩展[RFC5203]、HIP会合服务器[RFC5204]、DNS资源记录[RFC5205]和移动性管理[RFC5206]。在Internet协议中，主机标识表示为覆盖可路由加密哈希标识符（RAYTS）[RFC4843]。此外，研究小组还发布了一份关于穿越NAT和防火墙要求的RFC[RFC5207]
and the working group later published specification text for legacy NAT traversal [RFC5770]. As of this writing, work has commenced on moving the above specifications to Standards Track status.
工作组后来发布了遗留NAT遍历的规范文本[RFC5770]。截至撰写本文时，已开始将上述规范移至标准轨道状态。
The terms used in this document are defined elsewhere in various documents. In particular, readers are suggested to review Section 3 of [RFC4423] for a listing of HIP-specific terminology.
本文件中使用的术语在各种文件的其他地方有定义。特别是，建议读者查阅[RFC4423]第3节，了解HIP特定术语的列表。
The research group has been tasked with producing an "experiment report" documenting the collective experiences and lessons learned from other studies, related experimentation, and designs completed by the research group. The question of whether the basic identifier-locator split assumption is valid falls beyond the scope of this research group. When indicated by its studies, the HIP-RG can suggest extensions and modifications to the protocol and architecture. It has also been in scope for the RG to study, in a wider sense, what the consequences and effects that wide-scale adoption of any type of separation of the identifier and locator roles of IP addresses is likely to have.
研究小组的任务是编写一份“实验报告”，记录从其他研究、相关实验和研究小组完成的设计中获得的集体经验和教训。基本标识符-定位器分割假设是否有效的问题超出了本研究组的范围。研究表明，HIP-RG可以建议对协议和架构进行扩展和修改。RG还可以从更广泛的意义上研究IP地址的标识符和定位器角色的任何类型的分离的广泛采用可能产生的后果和影响。
During the period of time when the bulk of this report was drafted (2004-2009), several research projects and open source software projects were formed to study HIP. These projects have been developing software enabling HIP to be interoperable according to the Experimental RFCs as well as supporting extensions not yet specified by RFCs.
在起草本报告的大部分期间（2004-2009年），形成了几个研究项目和开源软件项目来研究HIP。这些项目一直在开发软件，使HIP能够根据实验性RFC进行互操作，并支持RFC尚未指定的扩展。
The research group has been most active in two areas. First and foremost, the research group has studied extensions to HIP that went beyond the scope and charter of the IETF HIP working group and the set of RFCs (RFC 5201-5206) initially published in April 2008. Some of this work (NAT traversal, certificate formats for HIP, legacy application support, and a native sockets API for HIP) ultimately flowed into the IETF HIP working group upon its recharter in 2008. Other extensions (e.g., HIP in the Internet Indirection Infrastructure (i3) overlay, use of distributed hash tables for HIT-based (Host Identity Tag) lookups, mobile router extensions, etc.) are either still being worked on in the research group or have been abandoned. Most of the energy of the research group during this time period has been in studying extensions of HIPs or the application of HIP to new problem domains (such as the Internet of Things). Second, the research group has discussed the progress and outcome of the implementations and experiments conducted so far, as well as discussing perspectives from different participants (end users,
该研究小组在两个领域最为活跃。首先也是最重要的是，研究小组研究了HIP的扩展，该扩展超出了IETF HIP工作组的范围和章程以及最初于2008年4月发布的RFC集（RFC 5201-5206）。其中的一些工作（NAT遍历、HIP的证书格式、遗留应用程序支持和HIP的本机套接字API）最终在2008年重新编制时流入了IETF HIP工作组。其他扩展（例如，Internet间接寻址基础设施（i3）覆盖中的HIP、使用分布式哈希表进行基于命中（主机标识标签）的查找、移动路由器扩展等）要么仍在研究组中进行研究，要么已被放弃。在此期间，研究小组的大部分精力都集中在研究HIPs的扩展或HIP在新问题领域（如物联网）的应用上。其次，研究小组讨论了迄今为止实施和实验的进展和结果，并讨论了不同参与者（最终用户、，
operators, enterprises) on HIP deployment. It is this latter category of work (and not the extensions to HIP) on which this report is focused.
操作员、企业）在臀部部署。本报告关注的是后一类工作（而不是HIP的扩展）。
Finally, the research group was chartered to study, but did not rigorously study (due to lack of inputs), the following issues:
最后，特许研究小组研究以下问题，但没有严格研究（由于缺乏投入）：
o Objective comparisons of HIP with other mechanisms (although the research group did hold some discussions concerning the relation of HIP to other efforts such as the End-Middle-End (EME) research group, the Routing research group (RRG), and shim6-based protocols).
o HIP与其他机制的客观比较（尽管研究组确实就HIP与其他努力的关系进行了一些讨论，如末端-中间末端（EME）研究组、路由研究组（RRG）和基于shim6的协议）。
o Large scale deployments (thousands of hosts or greater).
o 大规模部署（数千台或更多主机）。
o Exploration of whether introducing an identity-locator mechanism would be architecturally sound, deployed at wide scale.
o 探索引入身份定位机制是否在架构上合理、大规模部署。
o Changes to the HIP baseline architecture and protocol or other identity-locator separation architectures.
o 更改HIP基线架构和协议或其他身份定位器分离架构。
In this report, we summarize the collective experience of early implementers and adopters of HIP, organized as follows:
在本报告中，我们总结了HIP早期实施者和采用者的集体经验，组织如下：
o Section 2 describes the implications of supporting HIP on an end host.
o 第2节描述了在终端主机上支持HIP的含义。
o Section 3 covers a number of issues regarding the deployment of and interaction with network infrastructure, including middlebox traversal, name resolution, Access Control Lists (ACLs), and HIP infrastructure such as rendezvous servers.
o 第3节介绍了与网络基础设施的部署和交互有关的一些问题，包括中间盒遍历、名称解析、访问控制列表（ACL）和HIP基础设施，如集合服务器。
Whereas the two previous sections focus on the implementation and deployment of the network plumbing to make HIP work, the next three focus on the impact on users and operators of the network.
前两部分着重于网络管道的实施和部署，以使HIP发挥作用，而下三部分则侧重于对网络用户和运营商的影响。
o Section 4 examines how the support of HIP in the host and network infrastructure affects applications; whether and how HIP provides benefits or drawbacks to HIP-enabled and legacy applications.
o 第4节研究主机和网络基础设施中对HIP的支持如何影响应用程序；HIP是否以及如何为支持HIP的应用程序和遗留应用程序提供优点或缺点。
o Section 5 provides an operator's perspective on HIP deployment.
o 第5节提供了操作员对髋关节展开的看法。
o Section 6 discusses user privacy issues.
o 第6节讨论用户隐私问题。
In closing, in Section 7, we list the experimental activities and research that have contributed to this report, and in Section 8 we briefly summarize related work.
最后，在第7节中，我们列出了为本报告做出贡献的实验活动和研究，在第8节中，我们简要总结了相关工作。
HIP is primarily an extension to the TCP/IP stack of Internet hosts, and, in this section, we summarize some experiences that several implementation groups have encountered in developing this extension. Our discussion here draws on experience of implementers in adding HIP to general-purpose computing platforms such as laptops, desktops, servers, and PDAs. There are two primary ways to support HIP on such an end host. The first is to make changes to the kernel implementation to directly support the decoupling of identifier and locator. Although this type of modification has data throughput performance benefits, it is also the more challenging to deploy. The second approach is to implement all HIP processing in the user-space and configure the kernel to route packets through user-space for HIP processing.
HIP主要是Internet主机TCP/IP堆栈的扩展，在本节中，我们总结了几个实现小组在开发此扩展时遇到的一些经验。我们在这里的讨论借鉴了实施者在为通用计算平台（如笔记本电脑、台式机、服务器和PDA）添加HIP方面的经验。在这样的终端主机上支持HIP有两种主要方法。第一个是对内核实现进行更改，以直接支持标识符和定位器的解耦。虽然这种类型的修改具有数据吞吐量性能优势，但部署起来也更具挑战性。第二种方法是在用户空间中实现所有HIP处理，并将内核配置为通过用户空间路由数据包以进行HIP处理。
The following public HIP implementations are known and actively maintained:
已知并积极维护以下公共HIP实现：
o HIP4BSD (http://www.hip4inter.net) -- FreeBSD kernel modifications and user-space keying daemon;
o HIP4BSD(http://www.hip4inter.net)——FreeBSD内核修改和用户空间键控守护进程；
o HIPL (http://hipl.hiit.fi) -- Linux kernel and user-space implementation;
o HIPL(http://hipl.hiit.fi)--Linux内核和用户空间的实现；
o OpenHIP (http://www.openhip.org) -- User-space keying daemon and packet processing for Linux, Windows XP/Vista/7, and Apple OS X.
o 开放式(http://www.openhip.org)--针对Linux、Windows XP/Vista/7和Apple OS X的用户空间键控守护程序和数据包处理。
In the following, we first describe issues specific to the way in which HIP is added to a stack, then we discuss general issues surrounding both implementation approaches.
在下文中，我们首先描述HIP添加到堆栈中的特定方式，然后讨论围绕这两种实现方法的一般问题。
In this section, we focus on the support of HIP assuming the following:
在本节中，我们将重点讨论髋关节的支撑，假设如下：
o HIP is implemented by directly changing the TCP/IP stack implementation.
o HIP是通过直接更改TCP/IP堆栈实现来实现的。
o Applications (using the sockets API) are unaware of HIP.
o 应用程序（使用套接字API）不知道HIP。
A HIP implementation typically consists of a key management process that coordinates with an IPsec-extended stack, as shown in Figure 1. In practice, HIP has been implemented entirely in the user-space, entirely in the kernel, or as a hybrid with a user-space key management process and a kernel-level ESP.
HIP实现通常包括一个与IPsec扩展堆栈协调的密钥管理过程，如图1所示。实际上，HIP完全在用户空间、内核中实现，或者作为用户空间密钥管理过程和内核级ESP的混合体实现。
+--------------------+ +--------------------+
| | | |
| | | |
| +------------+ | | +------------+ |
| | Key | | HIP | | Key | |
| | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | |
| +------------+ | | +------------+ |
| ^ | | ^ |
| | | | | |
| v | | v |
| +------------+ | | +------------+ |
| | IPsec- | | ESP | | IPsec- | |
| | Extended | | | | Extended | |
| | Stack | <-+-----------------------+-> | Stack | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| Initiator | | Responder |
+--------------------+ +--------------------+
+--------------------+ +--------------------+
| | | |
| | | |
| +------------+ | | +------------+ |
| | Key | | HIP | | Key | |
| | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | |
| +------------+ | | +------------+ |
| ^ | | ^ |
| | | | | |
| v | | v |
| +------------+ | | +------------+ |
| | IPsec- | | ESP | | IPsec- | |
| | Extended | | | | Extended | |
| | Stack | <-+-----------------------+-> | Stack | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| Initiator | | Responder |
+--------------------+ +--------------------+
Figure 1: HIP Deployment Model
图1：髋关节展开模型
Figure 2 summarizes the main implementation impact of supporting HIP, and is discussed further in subsequent sections. To enable HIP natively in an implementation requires extensions to the key management interface (here depicted as PF_KEY API [RFC2367]) with the security association database (SAD) and security policy database (SPD). It also requires changes to the ESP implementation itself to support BEET-mode (Bound End-to-End Tunnel) processing [BEET-MODE], extensions to the name resolution library, and (in the future) interactions with transport protocols to respond correctly to mobility and multihoming events [TCP-RLCI].
图2总结了支持HIP的主要实施影响，并将在后续章节中进一步讨论。要在实现中本机启用HIP，需要使用安全关联数据库（SAD）和安全策略数据库（SPD）扩展密钥管理接口（此处描述为PF_密钥API[RFC2367]）。它还需要对ESP实现本身进行更改，以支持BEET模式（绑定端到端隧道）处理[BEET-mode]，扩展名称解析库，以及（将来）与传输协议的交互，以正确响应移动和多主事件[TCP-RLCI]。
|-----------------------|
-------- | ---------- ----------
| HIP |-- ----| App v6 | | App v4 |
-------- | | ---------- ----------
| | | | HIT | LSI
| ------------ | AF_INET6 | AF_INET
| | resolver | | |
| ------------ | sockets API | user-space
--|-------------------|-------------------------------
| sockets and | | kernel
| PF_KEY API --------- |
|-------------> |TCP/UDP|<-----------
| ---------
| |
---------- ---------
| SAD/SPD|<-----> | ESP | {HIT_s, HIT_d} <-> SPI
---------- --------- {HIT_s, HIT_d, SPI} <-> {IP_s,IP_d,SPI}
|
---------
| IP |
---------
|-----------------------|
-------- | ---------- ----------
| HIP |-- ----| App v6 | | App v4 |
-------- | | ---------- ----------
| | | | HIT | LSI
| ------------ | AF_INET6 | AF_INET
| | resolver | | |
| ------------ | sockets API | user-space
--|-------------------|-------------------------------
| sockets and | | kernel
| PF_KEY API --------- |
|-------------> |TCP/UDP|<-----------
| ---------
| |
---------- ---------
| SAD/SPD|<-----> | ESP | {HIT_s, HIT_d} <-> SPI
---------- --------- {HIT_s, HIT_d, SPI} <-> {IP_s,IP_d,SPI}
|
---------
| IP |
---------
Figure 2: Overview of Typical Implementation Changes to Support HIP
图2：支持HIP的典型实施变更概述
Legacy applications can continue to use the standard AF_INET6 (for IPv6) and AF_INET (for IPv4) sockets API. IPv6 applications bind directly to a Host Identity Tag (HIT), which is a part of IPv6 address space reserved for ORCHIDs. IPv4 applications bind to a Local Scope Identifier (LSI) that has significance only within a host; the HIP layer translates from LSIs and HITs to the IP addresses that are still used underneath for HIP base exchange.
遗留应用程序可以继续使用标准的AF_INET 6（用于IPv6）和AF_INET（用于IPv4）套接字API。IPv6应用程序直接绑定到主机标识标签（HIT），HIT是为兰花保留的IPv6地址空间的一部分。IPv4应用程序绑定到仅在主机内有效的本地作用域标识符（LSI）；HIP层将LSI和HITs转换为IP地址，这些IP地址仍在下面用于HIP基础交换。
HIP uses a Bound End-to-End Tunnel (BEET) mode of ESP operation, which mixes tunnel-mode semantics with transport-mode syntax. BEET is not supported by all operating system distributions at present, so kernel modifications might be needed to obtain true kernel support using existing IPsec code. At the time of writing, the BEET mode has been adopted to vanilla Linux and FreeBSD kernels.
HIP使用ESP操作的绑定端到端隧道（BEET）模式，该模式混合了隧道模式语义和传输模式语法。目前，并非所有操作系统发行版都支持BEET，因此可能需要修改内核以使用现有IPsec代码获得真正的内核支持。在撰写本文时，BEET模式已被用于香草Linux和FreeBSD内核。
The HIPL project has contributed an IPsec BEET patch for the Linux kernel. The kernel-level support could potentially allow all Linux implementations of HIP to run in the user-space and use a common interface towards the kernel.
HIPL项目为Linux内核提供了一个IPsec BEET补丁。内核级支持可能允许HIP的所有Linux实现在用户空间中运行，并使用面向内核的公共接口。
One inconvenience experienced in current Linux IPsec implementation (due to the native IPsec implementation, not HIP specifically) is a loss of the first data packet that triggers the HIP association establishment. Instead, this packet should be cached and transmitted after the association is established.
当前Linux IPsec实现中遇到的一个不便（由于本机IPsec实现，而不是HIP实现）是触发HIP关联建立的第一个数据包丢失。相反，应该在建立关联后缓存和传输此数据包。
HIP can be implemented entirely in the user-space, an approach that is essential for supporting HIP on hosts for which operating system modifications are not possible. Even on modifiable operating systems, there is often a significant deployment advantage in deploying HIP only as a user-space implementation. All three open-source implementations provide user-space implementations and binary packages (RPMs, DEBs, self-extracting installers) typical of application deployment on the target systems.
HIP可以完全在用户空间中实现，这是在无法修改操作系统的主机上支持HIP所必需的方法。即使在可修改的操作系统上，仅将HIP部署为用户空间实现通常也具有显著的部署优势。所有三种开源实现都提供了用户空间实现和二进制包（RPM、DEB、自解压安装程序），这是目标系统上典型的应用程序部署。
When HIP is deployed in the user-space, some technique is necessary to identify packets that require HIP processing and divert them to the user-space for such processing and to re-inject them into the stack for further transport protocol processing. A commonly used technique is to deploy a virtual device in the kernel such as a network tap (TAP) device, although operating systems may provide other means for diverting packets to user-space. Routing or packet filtering rules must be applied to divert the right packets to these devices.
当HIP部署在用户空间中时，需要一些技术来识别需要HIP处理的数据包，并将其转移到用户空间进行此类处理，并将其重新注入堆栈以进行进一步的传输协议处理。一种常用的技术是在内核中部署一个虚拟设备，例如网络tap（tap）设备，尽管操作系统可以提供其他方法将数据包转移到用户空间。必须应用路由或数据包过滤规则将正确的数据包转移到这些设备。
As an example, the user-space implementation may install a route that directs all packets with destination addresses corresponding to HITs or LSIs to such a virtual device. In the user-space daemon, the ESP header and possibly the UDP header is applied, an outer IP address replaces the HIT, and the packet is re-sent to the kernel. In the reverse direction, a socket associated to ESP or a UDP port number may be used to receive ESP-protected packets. HIP signaling packets themselves may be sent and received by a raw socket bound to the HIP number or UDP port when UDP encapsulation is used.
例如，用户空间实现可以安装路由，该路由将具有与hit或lsi对应的目的地地址的所有分组定向到这样的虚拟设备。在用户空间守护进程中，应用ESP报头，可能还应用UDP报头，外部IP地址替换HIT，并将数据包重新发送到内核。相反，与ESP关联的套接字或UDP端口号可用于接收受ESP保护的数据包。当使用UDP封装时，HIP信令包本身可以由绑定到HIP号码或UDP端口的原始套接字发送和接收。
Much initial experimentation with HIP has involved using HITs directly in IPv6 socket calls, without any resolution infrastructure to learn the HIT based on, for example, a domain name, or to resolve the IP address. To experiment with HIP using HITs requires a priori HIT exchange, in the absence of a resolution service. Manual exchange of HITs has been a major inconvenience for experimentation. It can be overcome via 1) opportunistic HIP mode (RFC 5201, Section
HIP的许多初始实验都涉及直接在IPv6套接字调用中使用HIT，而没有任何解析基础设施来了解HIT，例如，基于域名或解析IP地址。在没有解析服务的情况下，使用HIP进行实验需要进行先验的HIT交换。手动交换点击量对实验来说是一大不便。它可以通过1）机会主义髋关节模式（RFC 5201，第
4.1.6), 2) storing HITs in DNS AAAA entries and looking them up by domain name, 3) name resolution service for HITs such as OpenDHT [RFC6537], 4) an ad hoc HIT exchange service to populate files on each machine, or 5) support for DNS extensions described in RFC 5205.
4.1.6）、2）在DNS AAAA条目中存储点击并按域名查找它们、3）点击的名称解析服务，如OpenDHT[RFC6537]，4）用于在每台机器上填充文件的临时点击交换服务，或5）支持RFC 5205中描述的DNS扩展。
Over time, support for these techniques has varied. The HIPL project has experimented with all of them. OpenHIP lacks support for option 2, and HIP4BSD lacks support for options 1 and 3.
随着时间的推移，对这些技术的支持也有所不同。HIPL项目对所有这些都进行了试验。OpenHIP不支持选项2，HIP4BSD不支持选项1和3。
Implementing opportunistic HIP mode in a clean way is challenging, as HITs need to be known when an application binds or connects to a socket. Approach 2 has been difficult in practice due to resistance of sysadmins to include AAAA entries for HITs in the DNS server, and is a non-standards-compliant use of the resource record. Approach 3 is being progressed with two independent implementations of a HIP-OpenDHT interface. At the moment, the easiest way for enabling experimentation appears to be approach 4 when a shell script based on Secure SHell (SSH) and Secure Copy (SCP) can connect to a peer machine and copy HITs to the local configuration files. However, this approach is not scalable or secure for the long run. HIPL developers have had positive experiences with alternative 5.
以干净的方式实现机会主义HIP模式具有挑战性，因为当应用程序绑定或连接到套接字时，需要知道命中率。方法2在实践中很困难，因为系统管理员拒绝在DNS服务器中包含AAAA命中条目，并且是不符合标准的资源记录使用。方法3通过两个独立的HIP OpenDHT接口实现。目前，启用实验的最简单方法似乎是方法4，即基于Secure shell（SSH）和Secure Copy（SCP）的shell脚本可以连接到对等计算机并将点击复制到本地配置文件。但是，从长远来看，这种方法是不可扩展的或不安全的。HIPL开发人员对备选方案5有着积极的经验。
In opportunistic mode, the Initiator starts a base exchange without knowledge of the Responder's HIT. The main advantage of the opportunistic mode is that it does not require additional lookup infrastructure for HIs [RFC5205] [RFC6537].
在机会主义模式下，发起者在不知道响应者命中的情况下启动基本交换。机会主义模式的主要优点是它不需要为他的[RFC5205][RFC6537]提供额外的查找基础设施。
The opportunistic mode also has a few disadvantages. First, the Initiator may not identify the Responder uniquely just based on the IP address in the presence of private address realms [RFC5770]. Second, the Initiator has to settle for a "leap of faith"; that is, assume there is no man-in-the-middle attack. However, this can be partially mitigated by using certificates at the Responder side [RFC6253] or by prompting the user using a graphical interface to explicitly accept the connection [paper.usable-security].
机会主义模式也有一些缺点。首先，在存在私有地址域的情况下，发起方可能不会仅基于IP地址唯一地识别响应方[RFC5770]。第二，发起者必须满足于“信仰的飞跃”；也就是说，假设攻击中没有人。然而，这可以通过在响应端使用证书[RFC6253]或通过提示用户使用图形界面明确接受连接[paper.usable security]来部分缓解。
The opportunistic mode requires only minor changes in the state machine of the Responder and small changes for the Initiator [paper.leap-of-faith]. While the Responder can just select a suitable HIT upon receiving the first HIP base exchange packet (known as an "I1") without a predefined HIT for the Responder, the Initiator should be more careful in processing the first packet from the Responder, known as the "R1". For example, the Initiator should make sure that it can disambiguate simultaneously initiated opportunistic base exchanges from each other.
机会主义模式只需要对响应者的状态机进行微小的更改，而对发起者进行微小的更改[论文.信仰的飞跃]。虽然响应者可以在接收到第一个HIP基本交换分组（称为“I1”）时仅选择合适的命中，而没有响应者的预定义命中，但是发起者在处理来自响应者的第一个分组（称为“R1”）时应该更加小心。例如，发起者应该确保能够消除同时发起的机会主义基站交换之间的歧义。
In the context of the HIPL project, the opportunistic mode has been successfully applied at the HIP layer for service registration [RFC5203]. HIP4BSD implemented opportunistic mode successfully with small modifications to the FreeBSD socket layer to support opportunistic mode. However, the Linux implementation was more challenging, as described below.
在HIPL项目中，机会主义模式已成功应用于HIP层的服务注册[RFC5203]。HIP4BSD成功地实现了机会主义模式，只需对FreeBSD套接字层进行少量修改，即可支持机会主义模式。但是，Linux实现更具挑战性，如下所述。
The HIPL project experimented with opportunistic mode by interposing a shim at two different layers. In the first approach, an API-based shim was implemented to capture socket calls from the application. This was somewhat complicated to implement and explicitly enabling an individual application (or groups of applications) to use the opportunistic mode was required. In the second approach [paper.leap-of-faith], the shim was placed between the network and transport layers. Upon successful base exchange, the shim translated IP-based packet flows to HIT-based packet flows by re-injecting the translated packets back to the networking stack.
HIPL项目通过在两个不同的层上插入垫片来试验机会主义模式。在第一种方法中，实现了一个基于API的垫片来捕获来自应用程序的套接字调用。这在实现上有些复杂，需要显式地使单个应用程序（或应用程序组）使用机会主义模式。在第二种方法[paper.leap of faith]中，垫片被放置在网络层和传输层之间。成功的基本交换后，垫片通过将转换后的数据包重新注入网络堆栈，将基于IP的数据包流转换为基于HIT的数据包流。
Unless bypassed for DNS, both of the opportunistic mode implementation approaches in HIPL subjected the application(s) to undergo opportunistic mode procedures also for DNS requests. Both approaches also implemented an optional "fall back" to non-HIP base connectivity if the peer did not support HIP. The detection of peer support for HIP was based on timeouts. To avoid timeouts completely and to reduce the delay to a single Round-Trip Time (RTT) for TCP, the project also experimented with TCP-specific extensions [thesis.bishaj].
除非绕过DNS，否则HIPL中的两种机会模式实现方法使应用程序也对DNS请求进行机会模式过程。如果对等方不支持HIP，这两种方法还实现了可选的“后退”到非HIP基础连接。检测同伴对HIP的支持是基于超时。为了完全避免超时，并将TCP的延迟减少到单个往返时间（RTT），该项目还试验了TCP特定的扩展[thesis.bishaj]。
The OpenHIP project experimented with opportunistic mode through the use of an opportunistic (-o) option. For the Responder, this option determines whether or not HIP accepts I1s received with a zeroed receiver's HIT. On the Initiator's side, this option allows one to configure a name and LSI in the known Host Identities file. When the HIT field is missing, an I1 is sent with a zeroed receiver's HIT. The LSI is needed by an IPv4 application to trigger the association. Note that, normally, the LSI used is based on the bottom 24 bits of the HIT, but in the case of opportunistic mode, the HIT is unknown; thus, the LSI may differ from the HIT.
OpenHIP项目通过使用机会主义（-o）选项来试验机会主义模式。对于响应者，此选项确定HIP是否接受零接收机命中接收的I1。在启动器方面，此选项允许在已知主机标识文件中配置名称和LSI。当命中字段丢失时，将发送一个I1，并将接收器的命中归零。IPv4应用程序需要LSI来触发关联。注意，通常情况下，使用的LSI基于命中的底部24位，但在机会主义模式下，命中未知；因此，LSI可能与HIT不同。
As a summary of the opportunistic mode experimentation, it is possibly best suited for HIP-aware applications. Either it can be used by HIP itself in registration extensions or by native HIP applications [RFC6317]. This way, the inherent security trade-offs of the opportunistic mode are explicitly visible to the user through the HIP-aware application.
作为机会主义模式实验的总结，它可能最适合HIP感知应用。它可以由HIP本身在注册扩展中使用，也可以由本机HIP应用程序使用[RFC6317]。通过这种方式，机会主义模式的固有安全权衡通过HIP感知应用程序对用户明确可见。
When HIP is used in opportunistic mode, the Initiator does not know the Responder's HIT, but it does know its IP address. In most other cases, however, the kernel or applications may know the HITs and not the IP addresses; in these cases, an IP address resolution step for HITs must take place.
在机会主义模式下使用HIP时，发起者不知道响应者的命中率，但知道其IP地址。然而，在大多数其他情况下，内核或应用程序可能知道命中，而不是IP地址；在这些情况下，必须执行命中的IP地址解析步骤。
A few techniques have been experimented with. First, OpenDHT can also use HITs as keys for IP address records. Second, work by Ponomarev has shown that the reverse DNS tree may be used for reverse lookups of the ORCHID space [HIT2IP]. Third, the need for resolution may trigger some type of HIP bootstrap message, similar in some sense to an Address Resolution Protocol (ARP) message (to resolve the HIT). The bootstrap (BOS) packet used to be present in the early revisions of the HIP base specifications, but it was removed from the final specifications due to insufficient interest at the time. The HIPL implementation currently sends an I1 to a link broadcast IP address if it doesn't know the IP address of the peer. It has triggered warnings in some Windows hosts running antivirus software that classified broadcasts with unknown protocol number as intrusion attempts. The utility of this technique is limited to the local link.
一些技术已经被试验过了。首先，OpenDHT还可以使用点击作为IP地址记录的键。其次，Ponomarev的工作表明，反向DNS树可用于兰花空间[HIT2IP]的反向查找。第三，解析的需要可能触发某种类型的HIP引导消息，在某种意义上类似于地址解析协议（ARP）消息（解析HIT）。bootstrap（BOS）数据包曾出现在髋关节基础规范的早期修订版中，但由于当时兴趣不足，已从最终规范中删除。HIPL实现当前向链路广播IP地址发送I1，如果它不知道对等方的IP地址。它在一些运行防病毒软件的Windows主机上触发了警告，该软件将协议号未知的广播归类为入侵企图。这种技术的实用性仅限于本地链路。
A generic key management API for IP security is known as PF_KEY API [RFC2367]. PK_KEY is a socket protocol family that can be used by trusted applications to access the IPsec key engine in the operating system. Users of this interface typically need sysadmin privileges.
用于IP安全的通用密钥管理API称为PF_密钥API[RFC2367]。PK_密钥是一个套接字协议系列，受信任的应用程序可以使用它访问操作系统中的IPsec密钥引擎。此接口的用户通常需要系统管理员权限。
HIP-related extensions to the PF_KEY interface define a new protocol IPPROTO_HIP. Their main functionality is replacing the TCP and UDP checksum with a HIP-compatible checksum (because the transport pseudoheader is based on HITs) in incoming and outgoing packets. Recent Linux kernel versions do not require patching for these extensions.
PF_密钥接口的HIP相关扩展定义了一个新的协议IPPROTO_HIP。它们的主要功能是在传入和传出数据包中用HIP兼容的校验和替换TCP和UDP校验和（因为传输伪头基于命中数）。最近的Linux内核版本不需要对这些扩展进行修补。
When an application triggers a HIP base exchange through the transport protocol, the first data packet can be lost unless the HIP and IPsec implementation is able to buffer the packet until the base exchange completes and IPsec SAs are set up. The loss of the data packet when it is a TCP SYN packet results in TCP timeout [RFC6298] that unnecessarily delays the application. A loss of a UDP packet can cause even longer timeouts in applications. Therefore, it was found to be important for HIP implementations to support the
当应用程序通过传输协议触发HIP基本交换时，第一个数据包可能会丢失，除非HIP和IPsec实现能够缓冲该数据包，直到基本交换完成并设置IPsec SAs。当数据包是TCP SYN数据包时，数据包丢失会导致TCP超时[RFC6298]，从而不必要地延迟应用程序。UDP数据包丢失可能会导致应用程序中更长的超时时间。因此，HIP实现支持
buffering of the packet. On the other hand, if the HIP base exchange or UPDATE takes longer than 1 second, which is the case on lightweight devices, a spurious timeout can occur at the transport layer. The HIP implementation could prevent this scenario by manipulating timeout values at the transport layer or, alternatively, dropping the original or retransmitted duplicate packet.
数据包的缓冲。另一方面，如果HIP-base交换或更新所需时间超过1秒（在轻量级设备上就是这种情况），则传输层可能会出现虚假超时。HIP实现可以通过在传输层操纵超时值或丢弃原始或重新传输的重复数据包来防止这种情况。
The multihoming support in [RFC5206] is intended for the purpose of failover, when a host starts using an alternative locator when a current locator fails. However, a host could used this multihoming support for load balancing across different locators. Multihoming in this manner could potentially cause issues with transport protocol congestion control and loss detection mechanisms. However, no experimental results from using HIP multihoming in this capacity have been reported.
[RFC5206]中的多宿主支持用于故障切换，当当前定位器出现故障时，主机开始使用替代定位器。但是，主机可以使用这种多宿主支持跨不同定位器进行负载平衡。这种方式的多宿可能会导致传输协议拥塞控制和丢失检测机制出现问题。然而，在这种情况下使用髋关节多导引头的实验结果尚未报道。
The use of paths with different characteristics can also impact the estimate of a retransmission timer at the sender's transport layer. TCP uses a smoothed average of the path's Round-Trip Time and its variation as the estimate for a retransmission timeout. After the retransmission timer expires, the sender retransmits all outstanding packets in go-back-N fashion.
使用具有不同特征的路径也会影响发送方传输层的重传计时器的估计。TCP使用路径往返时间的平滑平均值及其变化作为重传超时的估计值。在重新传输计时器到期后，发送方以返回N方式重新传输所有未完成的数据包。
When multihoming is used for simultaneous data transmission from several locators, there can easily be scenarios when the retransmission timeout does not correspond to the actual value. When packets simply experience different RTT, its variation is high, which sets the retransmission timeout value unnecessarily high. When packets are lost, the sender waits excessively long before retransmitting. Fortunately, modern TCP implementations deploying Selective Acknowledgments (SACKs) and Limited Transmit are not relying on retransmission timeouts except when most outstanding packets are lost.
当多归属用于从多个定位器同时传输数据时，很容易出现重传超时与实际值不一致的情况。当数据包仅仅经历不同的RTT时，其变化很高，这将设置不必要的重传超时值。当数据包丢失时，发送方在重新传输之前等待的时间过长。幸运的是，部署选择性确认（SACK）和有限传输的现代TCP实现不依赖于重传超时，除非大多数未完成的数据包丢失。
Load balancing among several paths requires some estimate of each path's capacity. The TCP congestion control algorithm assumes that all packets flow along the same path. To perform load balancing, the HIP layer can attempt to estimate parameters such as the delay, bandwidth, and loss rate of each path. A HIP scheduler could then distribute packets among the paths according to their capacity and delay, to maximize overall utilization and minimize reordering. The design of the scheduler is a topic of current research work; none are reported to exist. Different network paths can have different Maximum Transmission Unit (MTU) sizes. Transport protocols perform MTU discovery typically only in the beginning of a connection. As HIP hides mobility from the transport layer, it can happen that packets on the new path get fragmented without knowledge of the transport protocol. To solve this problem, the HIP layer could
多条路径之间的负载平衡需要对每条路径的容量进行一些估计。TCP拥塞控制算法假设所有数据包都沿着相同的路径流动。要执行负载平衡，HIP层可以尝试估计每个路径的延迟、带宽和丢失率等参数。HIP调度器可以根据数据包的容量和延迟在路径之间分配数据包，以最大限度地提高总体利用率并最小化重新排序。调度器的设计是当前研究的一个课题；据报道，没有一家公司存在。不同的网络路径可以具有不同的最大传输单元（MTU）大小。传输协议通常仅在连接开始时执行MTU发现。由于HIP隐藏了传输层的移动性，因此新路径上的数据包可能会在不了解传输协议的情况下变得支离破碎。为了解决这个问题，髋关节层可以
inform the transport layer of mobility events. Protocols to support such notifications to the transport layer have been proposed to the IETF in the past, including transport triggers [TRIGTRAN], lightweight mobility detection and response (LMDR) [LMDR], and TCP response to connectivity change [TCP-RLCI].
通知传输层移动性事件。过去已经向IETF提出了支持向传输层发送此类通知的协议，包括传输触发器[TRIGTRAN]、轻量级移动检测和响应（LMDR）[LMDR]和TCP对连接更改的响应[TCP-RLCI]。
Legacy NAT traversal for outbound-initiated connections to a publicly addressed Responder has been implemented by all three HIP implementations; two (HIPL and HIP4BSD) implement Interactive Connectivity Establishment (ICE) techniques [RFC5770] for inbound NAT traversal. It has also been reported that the use of Teredo [RFC4380] over HIP was simpler than the modifications required for ICE techniques because Teredo effectively manifests itself as a routable, virtual locator to the system. UDP encapsulation is now the default mode of HIP operation for OpenHIP's IPv4 HIP implementation. Finding an IPv6 NAT implementation for experiments has been difficult. In addition, the initial implementations of NAT traversal for HIP based on ICE techniques proved to be complicated to implement or integrate, and a native NAT traversal mode is now under development for HIP [NAT-TRAVERSAL]. NAT traversal is expected to be a major mode of HIP operation in the future.
所有三种HIP实现都已实现了用于到公共寻址响应程序的出站启动连接的遗留NAT遍历；两种（HIPL和HIP4BSD）实现了用于入站NAT穿越的交互式连接建立（ICE）技术[RFC5770]。据报道，Teredo[RFC4380]在HIP上的使用比ICE技术所需的修改更简单，因为Teredo有效地表现为系统的可路由虚拟定位器。UDP封装现在是OpenHIP的IPv4 HIP实现的默认HIP操作模式。为实验寻找IPv6 NAT实现一直很困难。此外，基于ICE技术的HIP NAT遍历的初始实现被证明是复杂的，难以实现或集成，并且目前正在为HIP开发一种本地NAT遍历模式[NAT-traversal]。NAT穿越有望成为未来髋关节手术的主要方式。
One issue not being addressed by some experimental implementations is how to perform source HIT selection across possibly multiple host identities (some may be unpublished). This is akin to source address selection for transport sockets. How much HIP policy to expose to users is a user interface issue. Default or automatic configuration guesses might have undesirable privacy implications for the user.
一些实验性实现没有解决的一个问题是如何跨可能的多个主机标识（有些可能未发布）执行源命中选择。这类似于传输套接字的源地址选择。向用户公开多少HIP策略是一个用户界面问题。默认或自动配置猜测可能会对用户造成不必要的隐私影响。
Helsinki University of Technology (TKK, now Aalto) has implemented an extension of the native HIP API to control multiple host identities [thesis.karlsson]. A problem with Linux routing and multiple identities was discovered by the HIPL development group. As Linux routing is based on longest prefix match, having multiple HITs on virtual devices is problematic from the viewpoint of access control because the stack selects the source HIT based on the destination HIT. A coarse-grained solution for this is to terminate the longest prefix match for ORCHIDs in the Linux networking statck. However, a more fine-grained solution tries to return a source HIT matching to the algorithm used for generating the destination HIT in order to facilitate compatibility with new algorithms standardized in the future.
赫尔辛基工业大学（TKK，现在阿尔托）已经实施了一个扩展的本地HIP API来控制多个主机身份[学位论文卡尔森]。HIPL开发组发现Linux路由和多个标识存在问题。由于Linux路由基于最长前缀匹配，因此从访问控制的角度来看，在虚拟设备上进行多次命中是有问题的，因为堆栈根据目标命中选择源命中。一个粗粒度的解决方案是在Linux网络statck中终止兰花的最长前缀匹配。然而，更细粒度的解决方案尝试将源命中匹配返回到用于生成目标命中的算法，以促进与将来标准化的新算法的兼容性。
There are security and privacy issues with storing private keys securely on a host. Current implementations simply store private keys in a file that is readable only by applications with root privileges. This may not be a sufficient level of protection, as keys could be read directly from the disk or, e.g., some application with a set-user-id flag. Keys may be stored on a trusted platform module (TPM), but there are no reported HIP experiments with such a configuration. In a Boeing pilot project, temporary certificates were generated from a key on a USB SIM chip and used in the HIP base exchange. Use of certificates in HIP requires extensions to the HIP specifications [RFC6253]. Another option is encrypting keys on disks and keeping a passkey in memory (like in Secure Socket Layer (SSL) certificates on servers, that ask for a password when booting Linux).
在主机上安全存储私钥存在安全和隐私问题。当前的实现只是将私钥存储在一个只有具有root权限的应用程序才能读取的文件中。这可能不是一个足够的保护级别，因为密钥可以直接从磁盘或（例如）具有设置的用户id标志的某些应用程序读取。密钥可能存储在可信平台模块（TPM）上，但没有关于此类配置的HIP试验报告。在波音公司的一个试点项目中，临时证书由USB SIM芯片上的一把钥匙生成，并用于HIP-base交换。在HIP中使用证书需要扩展HIP规范[RFC6253]。另一种选择是加密磁盘上的密钥并在内存中保留密钥（如服务器上的安全套接字层（SSL）证书，在引导Linux时要求密码）。
HIP is presently an experimental protocol, and some default firewall configuration scripts on popular Linux distributions do not permit the HIP number. Determining which rules to modify without compromising other policies can be tricky; the default rule set on a previous SuSE Linux distribution was discovered to contain over one hundred rules. Moreover, it may be the case that the end user has no control over the firewall settings, if administered by an enterprise IT department. However, the use of HIP over UDP has alleviated some of these concerns. When using HIP over UDP, the firewall needs to allow outbound UDP packets and responses to them.
HIP目前是一种实验性协议，流行Linux发行版上的一些默认防火墙配置脚本不允许使用HIP编号。在不影响其他策略的情况下确定要修改哪些规则可能很棘手；发现先前SuSE Linux发行版上的默认规则集包含100多条规则。此外，如果由企业it部门管理，最终用户可能无法控制防火墙设置。然而，使用HIP over UDP已经缓解了其中的一些担忧。当使用HIP over UDP时，防火墙需要允许出站UDP数据包和对它们的响应。
HIP has been oriented towards IPv6 deployment, but all implementations have also added support for IPv4. HIP supports IPv6 applications well, as the HITs are used from the general IPv6 address space using the ORCHID prefix. HITs are statistically unique, although they are not routable at the IP layer. Therefore, a mapping between HITs and routable IP addresses is necessary at the HIP layer, unless an overlay network or broadcast technique is available to route packets based on HITs.
HIP面向IPv6部署，但所有实现也都增加了对IPv4的支持。HIP很好地支持IPv6应用程序，因为HIT是从通用IPv6地址空间使用的，使用的是兰花前缀。点击在统计上是唯一的，尽管它们不能在IP层路由。因此，HIP层需要HITs和可路由IP地址之间的映射，除非覆盖网络或广播技术可用于基于HITs路由数据包。
For IPv4 applications, a 32-bit Local Scope Identifier (LSI) is necessary at the sockets API. The LSI is an alias for a host identity and is only meaningful within one host. Note that an IPv4 address may be used as an LSI if it is configured to refer to a particular host identity on a given host, or LSIs may be drawn from an unallocated IPv4 address range, but lack of coordination on the LSI space may hinder implementation portability.
对于IPv4应用程序，套接字API需要32位本地作用域标识符（LSI）。LSI是主机标识的别名，仅在一台主机内有意义。请注意，如果IPv4地址被配置为引用给定主机上的特定主机标识，或者LSI可以从未分配的IPv4地址范围中提取，则可以将其用作LSI，但LSI空间上缺乏协调可能会妨碍实现的可移植性。
HIP makes it possible to use IPv6 applications over the IPv4 network and vice versa. This has been called "interfamily operation" (flexibility between different address families) and is enabled by the fact that the transport pseudoheader is always based on HITs regardless of whether the application or the underlying network path is based on IPv4. All three open source HIP implementations have demonstrated some form of interfamily handoff support. The interfamily portion of the BEET patch in the Linux kernel was found more difficult to complete compared with the single-family processing.
HIP使通过IPv4网络使用IPv6应用程序成为可能，反之亦然。这被称为“族间操作”（不同地址族之间的灵活性），并且由于无论应用程序或底层网络路径是否基于IPv4，传输伪报头始终基于命中率而启用。所有三个开源HIP实现都展示了某种形式的家庭间切换支持。与单个家族处理相比，Linux内核中甜菜补丁的家族间部分更难完成。
HIP also provides the potential to perform cross-family support, whereby one side of a transport session is IPv6 based and another is IPv4 based [paper.handovers].
HIP还提供了执行跨系列支持的潜力，即传输会话的一端基于IPv6，另一端基于IPv4[纸质切换]。
Implementing HIP in current stacks or as overlays on unmodified stacks has generally been successful. Below are some caveats and open issues.
在当前堆栈中实现HIP或在未修改的堆栈上实现覆盖通常是成功的。以下是一些注意事项和未决问题。
Experimental results comparing a kernel versus user-space HIP implementations in terms of performance and DoS resilience would be useful. If the kernel implementation is shown to perform significantly better than the user-space implementation, it may be a sufficient justification to incorporate HIP within the kernel. However, experiences on general purpose laptops and servers suggests that for typical client use of HIP, user-space implementations perform adequately.
在性能和DoS弹性方面比较内核和用户空间HIP实现的实验结果将是有用的。如果内核实现的性能明显优于用户空间实现，那么在内核中加入HIP就足够了。然而，在通用笔记本电脑和服务器上的经验表明，对于HIP的典型客户机使用，用户空间实现可以充分发挥作用。
Although the HIPL kernel-based keying implementation was submitted to the Linux kernel development process, the implementation was not accepted. The kernel developers felt that since Mobile IP (MIP) and the Internet Key Exchange Protocol (IKE) are implemented as user-space signaling daemons in Linux, that should be the approach for HIP, too. Furthermore, the kernel patch was somewhat big, affecting the kernel in many places and having several databases. The Linux kernel maintainers did eventually accept the BEET patch.
尽管基于HIPL内核的键控实现已提交给Linux内核开发过程，但该实现未被接受。内核开发人员认为，由于移动IP（MIP）和Internet密钥交换协议（IKE）是在Linux中作为用户空间信令守护进程实现的，因此HIP也应该采用这种方法。此外，内核补丁有点大，在许多地方影响内核，并且有多个数据库。Linux内核维护人员最终接受了BEET补丁。
Some users have been explicitly asking about the coexistence of HIP with other VPN and Mobile IP software. On Windows, VPN clients tend to install their own versions of TAP drivers that might conflict with the driver used by the OpenHIP implementation. There may also be issues due to lack of coordination leading to unintended HIP-over-VPN sessions or lack of coordination of the ESP Security Parameter Index (SPI) space. However, these types of conflicts are only speculation
一些用户明确询问HIP是否与其他VPN和移动IP软件共存。在Windows上，VPN客户端倾向于安装自己版本的TAP驱动程序，这些驱动程序可能与OpenHIP实现使用的驱动程序冲突。由于缺乏协调，也可能会出现问题，导致VPN会话出现意外的HIP，或者ESP安全参数索引（SPI）空间缺乏协调。然而，这些类型的冲突只是猜测
and were not reported to the research group; only some positive reports of HIP and VPN software properly coexisting have been reported by the HIPL group.
未向研究组报告；HIPL小组仅报告了HIP和VPN软件正确共存的一些积极报告。
With legacy applications, LSI support is important because IPv6 is not widely used in applications. The main issues in getting applications to work well over HIP have been related to bugs in the implementations themselves, or latency related issues (such as TCP timeouts due to Linux IPsec implementation). There have been no major obstacles encountered in practice, and there has also been some experience in using HIP with native applications [paper.p2psip].
对于遗留应用程序，LSI支持非常重要，因为IPv6在应用程序中没有广泛使用。让应用程序在HIP上正常工作的主要问题与实现本身的bug或延迟相关的问题（如Linux-IPsec实现导致的TCP超时）有关。在实践中没有遇到任何重大障碍，在本地应用程序中使用HIP也有一些经验[paper.p2psip]。
This section focuses on the deployment of infrastructure to support HIP hosts.
本节重点介绍支持HIP主机的基础设施的部署。
HIP DNS extensions [RFC5205] were developed by NEC Eurolabs and contributed to OpenHIP and were also developed by the HIPL project, both for the BIND9 DNS server. Legacy applications do not query for HIP resource records, but DNS proxies (local resolvers) interpose themselves in the resolution path and can query for HI records. The BIND 9 deployment for HIPL uses binary blob format to store the HIP resource records; this means that no changes to the DNS server are required.
HIP DNS扩展[RFC5205]由NEC Eurolabs开发，并为OpenHIP做出了贡献，同时也由HIPL项目开发，都是针对BIND9 DNS服务器的。遗留应用程序不查询HIP资源记录，但DNS代理（本地解析程序）将自己插入解析路径，并可以查询HI记录。HIPL的BIND 9部署使用二进制blob格式存储HIP资源记录；这意味着不需要更改DNS服务器。
There have been no studies reported on the impact of changes based on [RFC5205] to HIP on the existing DNS. There have been some studies on using DNS to store HITs in the reverse tree [HIT2IP].
没有关于[RFC5205]更改为HIP对现有DNS的影响的研究报告。有一些关于使用DNS在反向树[HIT2IP]中存储命中的研究。
A design of a HIP registration protocol for architectured NATs (NATs that are HIP aware and use HIP identifiers to distinguish between hosts) has been completed and published as RFC 5204. Performance measurement results with a prototype are available, but experimentation on a wide scale is still missing. RFC 5207 provides a problem statement for HIP-aware NATs and middleboxes [RFC5207].
一项针对体系结构NAT（具有HIP意识并使用HIP标识符区分主机的NAT）的HIP注册协议的设计已经完成，并发布为RFC 5204。原型的性能测量结果是可用的，但仍然缺少大规模的实验。RFC 5207为支持HIP的NAT和中间盒提供了问题陈述[RFC5207]。
As argued by Aura, et al. [paper.hipanalysis], the encryption of the Initiator Host Identity (HI) prevents policy-based NAT and firewall support, and middlebox authentication, for HIP. The catch is that when the HI is encrypted, middleboxes in the network cannot verify the signature of the second base exchange packet from the Initiator
正如Aura等人[paper.hipanalysis]所指出的，启动器主机标识（HI）的加密阻止了基于策略的NAT和防火墙支持，以及HIP的中间包身份验证。问题在于，当HI被加密时，网络中的中间盒无法验证来自发起方的第二个基本交换数据包的签名
(I2) and, thus, cannot safely create a state for the HIP association. On the other hand, if the HI is not encrypted, a stateful middlebox can process the I2 and create protocol state for the session.
（I2）因此，无法安全地为髋部关联创建状态。另一方面，如果HI未加密，则有状态的中间盒可以处理I2并为会话创建协议状态。
OpenDHT HIT-to-IP address resolution has been implemented by Aalborg University, Denmark, Helsinki Institute for Information Technology for HIPL, and by Boeing for OpenHIP [RFC6537].
OpenDHT命中到IP地址解析已由丹麦奥尔堡大学、赫尔辛基信息技术研究所（HIPL）和波音公司（OpenHIP）[RFC6537]实施。
The prototype of the Host Identity Indirection Infrastructure (Hi3) has been implemented using OpenHIP and HIPL. A set of 25 i3 servers was running on PlanetLab for several years. While a PlanetLab account is required to run the servers, anybody could openly use the provided service.
主机标识间接寻址基础设施（Hi3）的原型已使用OpenHIP和HIPL实现。一组25台i3服务器在PlanetLab上运行了几年。虽然运行服务器需要PlanetLab帐户，但任何人都可以公开使用提供的服务。
The main idea of Hi3 is to transmit HIP control packets using the i3 system as a lookup and rendezvous service, while transmitting data packets efficiently end-to-end using IPsec. Performance measurements were conducted comparing the association setup latency, throughput, and RTT of Hi3 with plain IP, HIP, and i3 [paper.hi3].
Hi3的主要思想是使用i3系统作为查找和会合服务传输HIP控制数据包，同时使用IPsec高效地端到端传输数据包。通过比较Hi3与普通IP、HIP和i3的关联设置延迟、吞吐量和RTT来进行性能测量[paper.Hi3]。
One difficulty has been with debugging the i3 system. In some cases, the messages did not traverse i3 correctly, due to its distributed nature and lack of tracing tools. Making the system work has been challenging. Further, since the original research work was done, the i3 servers have gone offline.
一个困难是调试i3系统。在某些情况下，由于i3的分布式特性和缺乏跟踪工具，消息没有正确地遍历i3。使系统正常工作一直是一项挑战。此外，由于最初的研究工作已经完成，i3服务器已经离线。
NATs and firewalls have been a major disturbance in Hi3 experiments. Many networks did not allow incoming UDP packets to go through, therefore, preventing messages from i3 servers to reach the client.
NAT和防火墙一直是Hi3实验中的主要干扰因素。许多网络不允许传入的UDP数据包通过，因此，阻止来自i3服务器的消息到达客户端。
So far, the Hi3 system has been evaluated on a larger scale only analytically. The problem is that running a larger number of clients to create a sufficient load for the server is difficult. A cluster on the order of a hundred Linux servers is needed for this purpose. Contacts to a State Supercomputer Centre in Finland have not been successful so far. A possible option is to use one of the existing Emulab installations, e.g., in Utah, for these tests.
到目前为止，Hi3系统仅在更大范围内进行了分析评估。问题在于，运行大量的客户端来为服务器创建足够的负载是困难的。为此，需要一个大约100台Linux服务器的集群。到目前为止，与芬兰国家超级计算机中心的联系尚未成功。一个可能的选择是使用一个现有的Emulab装置（例如在犹他州）进行这些测试。
A rendezvous server (RVS) [RFC5204] has been implemented by HIIT for HIPL, and an implementation also exists for OpenHIP. The concept has been extended to a relay server in [RFC5770]. Initial experimentation with the HIPL implementation produced the following observations:
HIIT已经为HIPL实现了一个会合服务器（RVS）[RFC5204]，OpenHIP也有一个实现。在[RFC5770]中，该概念已扩展到中继服务器。HIPL实施的初步实验产生了以下观察结果：
o RVS may be better than dynamic DNS updates for hosts that change their address rapidly.
o 对于快速更改地址的主机，RVS可能比动态DNS更新更好。
o Registration of a HIP host to RVS costs a base exchange.
o 向RVS注册HIP主机需要基本交换。
o UPDATE and CLOSE packets sent through rendezvous servers is advised; RVS handling of UPDATE messages can typically solve the double jump [MULTI-HOMED] mobility problem.
o 建议更新和关闭通过集合服务器发送的数据包；RVS处理更新消息通常可以解决双跳[多宿]移动性问题。
The following advanced concepts need further study:
以下先进概念需要进一步研究：
o Multiple RVSs per host for fault tolerance (e.g., one rendezvous node crashes) and an algorithm for selecting the best RVS.
o 每个主机有多个RVS用于容错（例如，一个会合节点崩溃）和选择最佳RVS的算法。
o Load balancing. An RVS server could distribute I1s to different Responders if the Responder's identity is shared or opportunistic HIP is used.
o 负载平衡。如果共享响应者的身份或使用机会主义HIP，RVS服务器可以将I1分发给不同的响应者。
o Offering a rendezvous service in a P2P fashion by HIP hosts.
o 通过HIP主机以P2P方式提供会合服务。
In addition to pure DNS and pure DHT HIP name resolution, a hybrid approach combining the standard DNS interface for clients with last-hop DHT resolution was developed. The idea is that the benefits of DNS solution (wide deployment, support for legacy applications) could be combined with advantages of DHT (fault tolerance, efficiency in handling flat data keys). The DHT is typically run internally by the organization managing the last-hop DNS zone and the DNS server. That way, the HITs belonging to that organization could be stored locally by the organization that improves deployability of the resolution system. However, organizations could also share a DHT between themselves or connect their DNS servers to a publicly available DHT, such as OpenDHT. The benefit of running a DHT on a local server cluster compared to a geographically spread DHT is higher performance due to decreased internal DHT latencies.
除了纯DNS和纯DHT HIP名称解析之外，还开发了一种将客户端标准DNS接口与最后一跳DHT解析相结合的混合方法。其想法是，DNS解决方案的优点（广泛部署、支持遗留应用程序）可以与DHT的优点（容错性、处理平面数据密钥的效率）相结合。DHT通常由管理最后一跳DNS区域和DNS服务器的组织在内部运行。这样，属于该组织的命中数据就可以由该组织本地存储，从而提高解析系统的可部署性。然而，组织也可以在它们之间共享DHT，或者将它们的DNS服务器连接到公开可用的DHT，例如OpenDHT。与地理位置分散的DHT相比，在本地服务器集群上运行DHT的好处是由于减少了内部DHT延迟而提高了性能。
The system was prototyped by modifying the BIND DNS server to redirect the queries for HITs to a DHT server. The interface was implemented in XML according to specifications [RFC6537]. The system is completely backward compatible to legacy applications since the standard DNS resolver interface is used.
该系统的原型是修改绑定DNS服务器，将命中查询重定向到DHT服务器。该接口是根据规范[RFC6537]用XML实现的。由于使用了标准DNS解析器接口，因此该系统与传统应用程序完全向后兼容。
Performance of the system was evaluated by performing a rapid sequence of requests for querying and updating the HIT-to-IP address mapping. The request rate was varied from 1 to 200 requests per second. The average latency of one query request was less than 50 ms and the secured updated latency less than 100 ms with a low request
通过执行查询和更新HIT-to-IP地址映射的快速请求序列来评估系统的性能。请求速率从每秒1到200个请求不等。一个查询请求的平均延迟小于50毫秒，低请求的安全更新延迟小于100毫秒
rate. However, the delay was increasing exponentially with the request rate, reaching 1 second for 200 requests per second (update rate 0) and almost 2 seconds (update rate 0.5). Furthermore, the maximum delay exceeded the mean by several times.
速度但是，延迟随着请求速率呈指数增长，达到每秒200个请求的1秒（更新速率0）和近2秒（更新速率0.5）。此外，最大延迟超过平均值几倍。
Based on experiments, a multi-processor system could handle more than 1000 queries per second. The latencies are dominated by the DHT resolution delay, and the DNS component is rather small. This is explained by the relative inefficiency of used DHT implementation (Bamboo) and could be definitely improved in the future.
根据实验，多处理器系统每秒可以处理1000多个查询。延迟由DHT解析延迟控制，DNS组件相当小。这是由使用过的DHT实现（Bambol）的相对低效性所解释的，并且在将来肯定会得到改进。
In a deployed HIP environment, applications may be HIP aware or HIP unaware. RFC 5338 [RFC5338] describes various techniques to allow HIP to support unmodified applications. Some additional application considerations are listed below.
在已部署的HIP环境中，应用程序可以是HIP感知的，也可以是HIP不感知的。RFC 5338[RFC5338]描述了允许HIP支持未修改应用程序的各种技术。下面列出了一些其他应用注意事项。
One way to support legacy applications that use dynamic linking is to dynamically interpose a modified resolver library. Using HIPL, several legacy applications were shown to work without changes using dynamic re-linking of the resolver library. For example, the Firefox web browser successfully worked with an Apache web server. The re-linking just requires configuring an LD_PRELOAD system variable that can be performed in a user shell profile file or as a start-up wrapper for an application. This provides the user with fine-grained policy control over which applications use HIP, which could alternately be considered a benefit or a drawback depending on whether the user is burdened with such policy choices. The technique was also found to be sensitive to loading LD_PRELOAD twice, in which case the order of linking dynamic libraries must be coded carefully.
支持使用动态链接的遗留应用程序的一种方法是动态插入修改的解析器库。使用HIPL，使用解析器库的动态重新链接，几个遗留应用程序可以在没有更改的情况下工作。例如，Firefox web浏览器成功地与Apache web服务器配合使用。重新链接只需要配置一个LD_PRELOAD系统变量，该变量可以在用户shell概要文件中执行，也可以作为应用程序的启动包装。这为用户提供了细粒度的策略控制，控制哪些应用程序使用HIP，根据用户是否承担了此类策略选择的负担，可以将其视为优点或缺点。研究还发现，该技术对两次加载LD_PRELOAD非常敏感，在这种情况下，必须仔细编码链接动态库的顺序。
Another method for transparently using HIP, which has no reported implementation experience, is via local application proxies (e.g., squid web proxy) that are modified to be HIP aware. Discussion of proxies for HIP is a current focus of research group activities [HIPRG-PROXIES].
另一种透明地使用HIP的方法是通过本地应用程序代理（例如squid web代理），该代理经过修改后可以识别HIP，但没有报告过实现经验。HIP代理的讨论是研究小组活动的当前焦点[HIPRG-proxies]。
A concern that FTP would not work due to the problem of application referrals, i.e., passing the IP address within application messages, was discovered not to be a problem for FTP in practice. It is shown to work well both in the passive and active modes [paper.namespace]. It remains an open question how big problem referrals really are in
人们发现，由于应用程序引用问题（即在应用程序消息中传递IP地址），FTP无法工作，这在实践中并不是FTP的问题。它在被动和主动模式下都能很好地工作[paper.namespace]。这仍然是一个悬而未决的问题转介到底有多大的问题
the practice. At least, they do not seem used for the client side because they are behind NATs, and, therefore, client addresses are unsuitable as referrals.
这种做法。至少，它们似乎不用于客户端，因为它们位于NAT之后，因此，客户端地址不适合作为推荐。
Some applications may be sensitive to additional RTTs or processing due to HIP resolutions or the protocol itself. For instance, page load speed for web browsers is a critical metric for browser designers. Some applications or deployments may not wish to trade application speed for the security and mobility management that HIP offers.
由于HIP分辨率或协议本身，某些应用程序可能对附加RTT或处理敏感。例如，web浏览器的页面加载速度是浏览器设计者的一个关键指标。一些应用程序或部署可能不希望以应用程序速度换取HIP提供的安全性和移动性管理。
There is no known deployment of HIP by a data service provider. However, some issues regarding HIP have been brought to the HIP research group by a network provider and are summarized below and in [HIP-OPERATORS].
数据服务提供商没有已知的HIP部署。然而，一些关于HIP的问题已由网络提供商提交给HIP研究小组，并在下文和[HIP-OPERATORS]中进行了总结。
When a network operator deploys HIP for its customers, several issues with management of host identities arise. The operator may prefer to generate the host identity itself rather than let each host create the identities. Several factors can create such a need. Public-private key generation is a demanding operation that can take tens of seconds on a lightweight device, such as a mobile phone. After generating a host identity, the operator can immediately insert it into its own AAA databases and network firewalls. This way, the users would not need to be concerned with technical details of host identity management.
当网络运营商为其客户部署HIP时，主机身份管理会出现几个问题。操作员可能更愿意自己生成主机标识，而不是让每个主机创建标识。有几个因素可以产生这种需求。公钥-私钥生成是一项要求很高的操作，在轻量级设备（如手机）上可能需要数十秒。生成主机标识后，运营商可以立即将其插入自己的AAA数据库和网络防火墙。这样，用户就不需要关心主机身份管理的技术细节。
The operator may use a Public Key Infrastructure (PKI) to certify host identities of its customers. Then, it uses the private key of an operator's Certificate Authority (CA) to sign the public key of its customers. This way, third parties possessing the public key of the CA can verify the customer's host identity and use this information, e.g., for admission control to infrastructure. Such practice raises the security level of HIP when self-generated host identities are used.
运营商可使用公钥基础设施（PKI）认证其客户的主机身份。然后，它使用运营商证书颁发机构（CA）的私钥对其客户的公钥进行签名。通过这种方式，拥有CA公钥的第三方可以验证客户的主机身份并使用此信息，例如，用于基础设施的准入控制。当使用自生成的主机标识时，这种做法提高了HIP的安全级别。
When the operator is using neither PKI nor DNS Security (DNSSEC) host names, the problem of securely exchanging host identities remains. When HIP is used in opportunistic mode, a man-in-the-middle can still intercept the exchange and replace the host identities with its own.
当运营商既不使用PKI也不使用DNS安全（DNSSEC）主机名时，安全交换主机标识的问题仍然存在。当HIP在机会主义模式下使用时，中间人仍然可以拦截交换并用自己的主机身份替换主机身份。
For instance, the signaling provided by SIP could be used to deliver host identities if it were secured by existing mechanisms in the operator's network.
例如，如果由运营商网络中的现有机制保护，则SIP提供的信令可用于传递主机标识。
The research group has discussed whether operators can provide "value-added" services and priority, and comply with wiretapping laws, if all sessions are encrypted. This is not so much a HIP issue as a general end-to-end encryption issue.
研究小组讨论了如果所有会话都加密，运营商是否可以提供“增值”服务和优先级，并遵守窃听法。这与其说是HIP问题，不如说是一般的端到端加密问题。
The processing power of mobile devices also must be considered. One study evaluated the use of HIP and ESP on lightweight devices (Nokia N770 Internet Tablets having 200 MHz processors) [paper.mobiarch]. The overhead of using ESP on such a platform was found to be tolerable, about 30% in terms of throughput. With a bulk TCP transfer over WiFi, transfer without HIP was producing 4.86 Mbps, while over ESP security associations set up by HIP it was 3.27 Mbps. A lightweight HIP base exchange for this purpose is being developed at the time of this writing [HIP-DEX].
还必须考虑移动设备的处理能力。一项研究评估了HIP和ESP在轻量级设备上的使用情况（诺基亚N770互联网平板电脑具有200 MHz处理器）[paper.mobiarch]。在这样一个平台上使用ESP的开销是可以忍受的，吞吐量大约为30%。通过WiFi的批量TCP传输，不使用HIP的传输速度为4.86 Mbps，而通过HIP建立的ESP安全关联的传输速度为3.27 Mbps。在撰写本文时，正在开发一种用于此目的的轻型髋关节基底交换[HIP-DEX]。
It is also possible to use HIP in a NULL encryption configuration if one of SHA1 or MD5 authentication are used.
如果使用SHA1或MD5身份验证之一，也可以在空加密配置中使用HIP。
A firewall typically separates an organization's network from the rest of the Internet. An Access Control List (ACL) specifies packet forwarding policies in the firewall. Current firewalls can filter out packets based on IP addresses, transport protocol, and port values. These values are often unprotected in data packets and can be spoofed by an attacker. By trying out common well-known ports and a range of IP addresses, an attacker can often penetrate the firewall defenses.
防火墙通常将组织的网络与Internet的其余部分分开。访问控制列表（ACL）指定防火墙中的数据包转发策略。当前的防火墙可以根据IP地址、传输协议和端口值过滤掉数据包。这些值在数据包中通常不受保护，攻击者可以对其进行欺骗。通过尝试常见的已知端口和一系列IP地址，攻击者通常可以穿透防火墙防御。
Furthermore, legacy firewalls often disallow IPsec traffic and drop HIP control packets. HIP allows ACLs to be protected based on packet exchanges that may be authenticated by middleboxes. However, HITs are not aggregatable, so HIT-based ACLs may be longer in length (due to an inability to group hosts with a single entry) and harder to deal with by human users (due to the length of the HIT compared with an IPv4 or IPv6 prefix).
此外，传统防火墙通常不允许IPsec通信，并丢弃HIP控制数据包。HIP允许基于数据包交换保护ACL，这些数据包交换可以通过中间盒进行身份验证。但是，HIT是不可聚合的，因此基于HIT的ACL的长度可能更长（因为无法使用单个条目对主机进行分组），并且人类用户更难处理（因为HIT的长度与IPv4或IPv6前缀相比）。
Additionally, operators would like to grant access to the clients from domains such as example.com regardless of their current locators or HITs. This is difficult without a forward confirmed reverse DNS to use for non-repudiation purposes.
此外，运营商希望从example.com等域向客户授予访问权限，而不考虑其当前的定位器或点击次数。如果没有用于不可抵赖目的的前向确认反向DNS，则很难做到这一点。
Helsinki University of Technology (TKK, now Aalto) has implemented a HIP firewall based on Linux iptables [paper.firewall] that operates in user-space.
赫尔辛基工业大学（TKK，现在阿尔托）已经在用户空间中运行了基于Linux IPTaS[文件防火墙]的HIP防火墙。
In general, firewalls can be stateless, filtering packets based only on the ACL, and stateful, following and remembering packet flows. Stateless firewalls are simple to implement but provide only coarse-grained protection. However, their performance can be efficient since packet processing requires little memory or CPU resources. A stateful firewall determines if a packet belongs to an existing flow or starts a new flow. A flow identifier combines information from several protocol headers to classify packets. A firewall removes the state when the flow terminates (e.g., a TCP connection is closed) or after a timeout. A firewall can drop suspicious packets that fail a checksum or contain sequence numbers outside of the current sliding window.
一般来说，防火墙可以是无状态的，只基于ACL过滤数据包，也可以是有状态的，跟踪并记住数据包流。无状态防火墙易于实现，但只提供粗粒度保护。然而，由于数据包处理只需要很少的内存或CPU资源，因此它们的性能是高效的。有状态防火墙确定数据包属于现有流还是启动新流。流标识符组合来自多个协议头的信息来对数据包进行分类。防火墙在流终止（例如TCP连接关闭）或超时后删除状态。防火墙可以丢弃未通过校验和或包含当前滑动窗口之外的序列号的可疑数据包。
A transparent firewall does not require that hosts within the protected network register or even know of the existence of the firewall. An explicit firewall requires registration and authentication of the hosts.
透明防火墙不要求受保护网络中的主机注册，甚至不需要知道防火墙的存在。显式防火墙需要主机的注册和身份验证。
A HIP-aware firewall operating in the middle identifies flows using HITs of communicating hosts, as well as SPI values and IP addresses. The firewall must link together the HIP base exchange and subsequent IPsec ESP data packets. During the base exchange, the firewall learns the SPI values from I2 and R2 packets. Then, the firewall only allows ESP packets with a known SPI value and arriving from the same IP address as during the base exchange. If the host changes its location and the IP address, the firewall, if still on the path, learns about the changes by following the mobility update packets.
在中间操作的HIP感知防火墙使用通信主机的命中以及SPI值和IP地址来标识流。防火墙必须将HIP base exchange和后续IPsec ESP数据包链接在一起。在基本交换期间，防火墙从I2和R2数据包中学习SPI值。然后，防火墙只允许具有已知SPI值且来自与基本交换期间相同IP地址的ESP数据包。如果主机更改其位置和IP地址，则防火墙（如果仍在路径上）将通过跟踪移动更新数据包来了解更改。
It is possible to implement a stateless, end-host-based firewall to reuse existing higher-layer mechanisms such as access control lists in the system. In this mode of operation, HITs would be used in the access control lists, and while the base exchange might complete, ESP is not passed to the transport layer unless the HITs are allowed in the access control list.
可以实现基于终端主机的无状态防火墙，以重用系统中现有的更高层机制，如访问控制列表。在此操作模式下，点击将在访问控制列表中使用，虽然基本交换可能会完成，但除非访问控制列表中允许点击，否则ESP不会传递到传输层。
A HIP host can register to an explicit firewall using the usual procedure [RFC5203]. The registration enables the host and the firewall to authenticate each other. In a common case, where the Initiator and Responder hosts are located behind different firewalls, the Initiator may need to first register with its own firewall, and afterward, with the Responder's firewall.
HIP主机可以使用通常的过程[RFC5203]注册到显式防火墙。注册使主机和防火墙能够相互验证。在常见情况下，如果启动器和响应程序主机位于不同的防火墙后面，则启动器可能需要首先向其自己的防火墙注册，然后向响应程序的防火墙注册。
Some researchers have suggested that a firewall for security-critical environments should get involved in the base exchange and UPDATE procedures with middlebox-injected echo requests. Otherwise, the firewall can be circumvented with replay attacks if there is a compromised node within the network that the firewall is trying to protect [HIP-MIDDLE].
一些研究人员建议，安全关键型环境的防火墙应该参与基本交换和更新过程，并使用中间盒注入的回显请求。否则，如果网络中存在防火墙试图保护的受损节点[HIP-MIDDLE]，则可以通过重播攻击绕过防火墙。
Using public keys for identifying hosts creates a privacy problem as third parties can determine the source host even if attached to a different location in the network. Various transactions of the host could be linked together if the host uses the same public key. Furthermore, using a static IP address also allows linking of transactions of the host. Multiplexing multiple hosts behind a single NAT or using short address leases from DHCP can reduce the problem of user tracking. However, IPv6 addresses could reduce the occurrence of NAT translation and cause additional privacy issues related to the use of Media Access Control (MAC) addresses in IPv6 address autoconfiguration. HIP does provide for the use of anonymous (unpublished) HITs in cases in which the Initiator prefers to remain anonymous, but the Responder must be willing to accept sessions from anonymous peers.
使用公钥识别主机会造成隐私问题，因为即使连接到网络中的不同位置，第三方也可以确定源主机。如果主机使用相同的公钥，则可以将主机的各种事务链接在一起。此外，使用静态IP地址还可以链接主机的事务。在单个NAT后面多路复用多个主机或使用DHCP的短地址租约可以减少用户跟踪问题。但是，IPv6地址可能会减少NAT转换的发生，并导致与在IPv6地址自动配置中使用媒体访问控制（MAC）地址相关的额外隐私问题。HIP确实允许在发起方希望保持匿名的情况下使用匿名（未发布）点击，但响应方必须愿意接受来自匿名对等方的会话。
With mutual authentication, the HIP Initiator should not have to reveal its identity (public key) to either a passive adversary or an active attacker. The HIP Initiator can authenticate the Responder's R1 packet before encrypting its host identity with the Diffie-Hellman-generated keying material and sending it in the I2 packet. The authentication step upon receiving an R1 defeats the active attacker (impersonator) of the Responder, and the act of encrypting the identity defeats the passive adversary. Since the Responder sends its public key unencrypted in the first reply message (R1) to the Initiator, the Responder's identity will be revealed to third-party on-path eavesdroppers. However, if the Responder authenticates the Initiator and performs access controls before sending the R1, the Responder can avoid disclosing its public key to an active attacker.
通过相互身份验证，HIP启动器不必向被动对手或主动攻击者透露其身份（公钥）。HIP启动器可以在使用Diffie-Hellman生成的密钥材料加密其主机身份并将其发送到I2数据包之前，对响应者的R1数据包进行身份验证。接收R1时的身份验证步骤会击败响应者的主动攻击者（模拟者），而加密身份的行为会击败被动对手。由于响应者在第一条回复消息（R1）中将其未加密的公钥发送给发起方，因此响应者的身份将被透露给第三方路径窃听者。但是，如果响应者在发送R1之前对启动器进行身份验证并执行访问控制，则响应者可以避免向活动攻击者泄露其公钥。
DNS records can provide information combining host identity and location information, the host public key, and host IP address. Therefore, identity and location privacy are related and should be treated in an integrated approach. The goal of the BLIND is to provide a framework for identity and location privacy [paper.blind] [HIP-PRIVACY]. The identity protection is achieved by hiding the actual public keys from third parties so that only the trusted hosts can recognize the keys. Location privacy is achieved by integrating traffic forwarding with NAT translation and decoupling host identities from locators. The use of random IP and MAC addresses
DNS记录可以提供结合主机标识和位置信息、主机公钥和主机IP地址的信息。因此，身份和位置隐私是相关的，应该以综合的方式对待。盲人的目标是为身份和位置隐私提供一个框架[paper.BLIND][HIP-privacy]。身份保护是通过对第三方隐藏实际公钥来实现的，这样只有受信任的主机才能识别密钥。通过将流量转发与NAT转换相结合，并将主机身份与定位器分离，可以实现位置隐私。随机IP和MAC地址的使用
also reduces the issue of location privacy shifting the focus to protecting host identifiers from third parties. This approach is, by its very nature, incompatible with middlebox authentication.
还减少了位置隐私问题，将重点转移到保护主机标识符不受第三方影响。从本质上讲，这种方法与中间包身份验证不兼容。
To prevent revealing the identity, the host public key and its hash (HIT) can be encrypted with a secret key known beforehand to both Initiator and Responder. However, this is a requirement that cannot be easily implemented in practice. The BLIND framework provides protection from active and passive attackers using a modified HIP base exchange. If the host avoids storing its public keys in the reverse DNS or DHT repository, the framework achieves full location and identity privacy.
为了防止泄露身份，主机公钥及其散列（HIT）可以使用发起者和响应者都事先知道的密钥进行加密。然而，这是一个在实践中不容易实现的要求。BLIND框架使用改进的HIP base exchange提供保护，防止主动和被动攻击者攻击。如果主机避免将其公钥存储在反向DNS或DHT存储库中，则框架将实现完全的位置和身份隐私。
An alternative approach to reducing privacy threats of persistent identifiers is to replace them with short-lived identifiers that are changed regularly to prevent user tracking. Furthermore, identifiers must be changed simultaneously at all protocol layers; otherwise, an adversary could still link the new identifier by looking at an identifier at another protocol layer that remained the same after the change. The HIP privacy architecture that simultaneously changes identifiers on MAC, IP, and HIP/IPsec layers was developed at Helsinki University of Technology (TKK, now Aalto) [thesis.takkinen]. HIP could be extended in the future to allow active sessions to migrate identities.
减少持久性标识符的隐私威胁的另一种方法是用定期更改以防止用户跟踪的短期标识符替换它们。此外，必须在所有协议层同时更改标识符；否则，对手仍然可以通过查看另一个协议层的标识符来链接新标识符，该标识符在更改后保持不变。同时在MAC、IP和HIP/IPSec层上改变标识符的HIP隐私体系结构是在赫尔辛基工业大学（TKK，现在Aalto）[To.TakKiNEN ]开发的。HIP将来可以扩展，以允许活动会话迁移身份。
This report is derived from reported experiences and research results of early adopters, implementers, and research activities. In particular, a number of implementations have been in development since 2002 (Section 2).
本报告来源于早期采用者、实施者和研究活动的报告经验和研究结果。特别是，自2002年以来，已经开发了许多实现（第2节）。
One production-level deployment of HIP has been reported. Boeing has described how it uses HIP to build Layer 2 VPNs over untrusted wireless networks [HIPLS]. This use case is not a traditional end-host-based use of HIP, but rather, it is one that uses HIP-aware middleboxes to create ESP tunnels on-demand between provider-edge (PE) devices.
已经报告了HIP的一次生产级部署。波音公司描述了如何使用HIP在不受信任的无线网络[HIPL]上构建第2层VPN。此用例不是传统的基于终端主机的HIP使用，而是使用支持HIP的中间盒在提供商边缘（PE）设备之间按需创建ESP隧道。
The InfraHIP II project is deploying HIP infrastructure (test servers, rendezvous and relay servers) in the public Internet.
InfraHIP II项目正在公共互联网上部署HIP基础设施（测试服务器、会合和中继服务器）。
The following is a possibly incomplete list of past and current research activities related to HIP.
以下是过去和当前与HIP相关的研究活动的不完整列表。
o Boeing Research & Technology (J. Ahrenholz, O. Brewer, J. Fang, T. Henderson, D. Mattes, J. Meegan, R. Paine, S. Venema, OpenHIP implementation, Secure Mobile Architecture)
o 波音研究与技术公司（J.Ahrenholz、O.Brewer、J.Fang、T.Henderson、D.Mattes、J.Meegan、R.Paine、S.Venema、OpenHIP实施、安全移动架构）
o NomadicLab, Ericsson (P. Jokela, P. Nikander, J. Melen. BSD HIP implementation)
o 爱立信NomadicLab（P.Jokela，P.Nikander，J.Melen，BSD HIP实施）
o Helsinki Institute for Information Technology (HIIT) (A. Gurtov, M. Komu, A. Pathak, D. Beltrami. HIPL, legacy NAT traversal, firewall, i3, native API)
o 赫尔辛基信息技术研究所（HIIT）（A.Gurtov、M.Komu、A.Pathak、D.Beltrami.HIPL、传统NAT穿越、防火墙、i3、本机API）
o Helsinki University of Technology (TKK, now Aalto) (Janne Lindqvist, Niklas Karlsson, Laura Takkinen, and Essi Vehmersalo. HIP security and firewalls, multiple identities, and privacy management)
o 赫尔辛基工业大学（TKK，现在阿尔托）（Janne Lindqvist，Niklas Karlsson，Laura Takkinen和Essi Vehmersalo .HIP安全和防火墙，多个身份和隐私管理）
o University of California, Berkeley (A. Joseph, HIP proxy implementation)
o 加利福尼亚大学，伯克利（A. Joseph，髋关节代理实施）
o Laboratory of Computer Architecture and Networks, Polytechnic School of University of Sao Paulo, Brazil (T. Carvalho, HIP measurements, Hi3)
o 巴西圣保罗大学理工学院计算机结构与网络实验室（T. Carvalho，HIP测量，HI3）
o Telecom Italia (M. Morelli, comparing existing HIP implementations)
o 意大利电信（M.Morelli，比较现有HIP实施）
o NEC Heidelberg (L. Eggert, M. Esteban, V. Schmitt working on RVS implementation, DNS, NAT traversal)
o NEC海德堡（L.Eggert，M.Esteban，V.Schmitt致力于RVS实施，DNS，NAT穿越）
o University of Hamburg-Harburg (M. Shanmugam, A. Nagarajan, HIP registration protocol)
o 汉堡大学哈伯格（M. Shanmugam，A. Nagarajan，髋关节注册协议）
o University of Tuebingen (K. Wehrle, T. Lebenslauf to work on Hi3 or HIP-OpenDHT)
o 图宾根大学（K. Wehrle，T. Lebenslauf在Hi3或Hop-OpenDHT上工作）
o University of Parma (UNIPR), Department of Information Engineering Parma, Italy. (N. Fedotova, HIP for P2P)
o 帕尔马大学，意大利帕尔马信息工程系。（N.费多托娃，P2P的热门人物）
o Siemens (H. Tschofenig, HIP middleboxes)
o 西门子（H.Tschofenig，HIP中间盒）
o Denmark (Aalborg University, Lars Roost, Gustav Haraldsson, Per Toft, HIP evaluation project, OpenDHT-HIP interface)
o 丹麦（奥尔堡大学、Lars Roost、Gustav Haraldsson、Per Toft、髋关节评估项目、OpenDHT髋关节接口）
o Microsoft Research, Cambridge (T. Aura, HIP analysis)
o 微软研究院，剑桥（T.Aura，髋关节分析）
o MIT (H. Balakrishnan. Delegation-Oriented Architecture)
o 麻省理工学院（H.Balakrishnan.面向委托的体系结构）
o Huawei (D. Zhang, X. Xu, hierarchical HIP architecture, HIP proxy, key revocation)
o 华为（D.Zhang，X.Xu，分层HIP架构，HIP代理，密钥撤销）
This section briefly summarizes the related work on the ID-locator split with particular focus on recent IETF and IRTF activity. In the academic research community, several related proposals were explored prior to the founding of this research group, such as the Internet Indirection Infrastructure (i3) [paper.i3], IPNL [paper.layered], DataRouter [paper.datarouter], Network Pointers [paper.netpointers], FARA [paper.fara], and TRIAD [paper.triad].
本节简要总结了ID定位器拆分的相关工作，特别关注最近的IETF和IRTF活动。在学术研究界，在该研究小组成立之前，研究了若干相关的建议，如互联网间接寻址基础设施（i3）[paper.i3]、IPNL[paper.layered]、DataRouter[paper.DataRouter]、网络指针[paper.netpointers]、FARA[paper.FARA]和TRIAD[paper.TRIAD]。
The topic of whether a new namespace is needed for the Internet has been controversial. The Namespace Research Group (NSRG) at the IRTF was not able to reach consensus on the issue, nor even to publish a final report. Yet, there seems to be little disagreement that, for many scenarios, some level of indirection from network name to network location is essential or highly desirable to provide adequate service. Mobile IP [RFC6275] is one example that reuses an existing namespace for host naming. Since Mobile IP was finalized, many new variants to providing this indirection have been suggested. Even prior to Mobile IP, the IETF has published informational documents describing architectures separating network name and location, including the work of Jerome Saltzer [RFC1498] and Nimrod [RFC1992].
互联网是否需要一个新名称空间的话题一直存在争议。IRTF的名称空间研究小组（NSRG）未能就此问题达成共识，甚至未能发布最终报告。然而，在许多情况下，从网络名称到网络位置的某种程度的间接连接对于提供足够的服务是必要的或非常可取的，这一点似乎没有什么分歧。移动IP[RFC6275]是一个重用现有名称空间进行主机命名的示例。自从移动IP最终确定以来，已经提出了许多提供这种间接方式的新变体。甚至在移动IP之前，IETF就已经发布了描述分离网络名称和位置的体系结构的信息性文档，包括Jerome Saltzer[RFC1498]和Nimrod[RFC1992]的工作。
Most recently, there have been standardization and development efforts in the IETF and IRTF as follows:
最近，IETF和IRTF的标准化和开发工作如下：
o The Site Multihoming in IPv6 (multi6) WG documented the ways that multihoming is currently implemented in IPv4 networks and evaluated several approaches for advanced multihoming. The security threats and impact on transport protocols were covered during the evaluation. The work continued in another WG, Site Multihoming by IPv6 Intermediation (shim6), which is focusing on specifications of one selected approach [RFC5533]. Shim6 uses the approach of inserting a shim layer between the IP and the transport layers that hides effects of changes in the set of available addresses. The applications are using one active address that supports referrals. Shim6 relies on cryptographically generated IPv6 addresses to solve the address ownership problem. HIP and shim6 are architecturally similar and use a common format for control packets. HIP specifications define only simple multihoming scenarios leaving such important issues as interface selection untouched. Shim6 offers complementary functionality that can be reused in HIP [REAP4HIP]. The OpenHIP implementation integrates HIP and shim6 protocols in the same framework, with the goal of allowing HIP to reuse the shim6 failure detection protocol. Furthermore, HIP and shim6 socket APIs have been jointly designed [RFC6317] [RFC6316].
o IPv6中的站点多主（multi6）工作组记录了当前在IPv4网络中实现多主的方式，并评估了几种高级多主的方法。评估期间涵盖了安全威胁和对传输协议的影响。这项工作在另一个工作组“IPv6中介的站点多宿主”（shim6）中继续进行，该工作组专注于一种选定方法的规范[RFC5533]。Shim6使用的方法是在IP和传输层之间插入一个垫片层，以隐藏可用地址集更改的影响。应用程序正在使用一个支持转介的活动地址。Shim6依靠加密生成的IPv6地址来解决地址所有权问题。HIP和shim6在体系结构上相似，并且对控制数据包使用通用格式。HIP规范只定义了简单的多主场景，没有涉及接口选择等重要问题。Shim6提供了可以在HIP[REAP4HIP]中重用的补充功能。OpenHIP实现将HIP和shim6协议集成在同一个框架中，目的是允许HIP重用shim6故障检测协议。此外，HIP和shim6套接字API已经联合设计[RFC6317][RFC6316]。
o The IRTF Routing Research Group (RRG) has explored a class of solutions to the global routing scalability problem that involve either separation of the existing IP address space into those used for identifiers and locators as in LISP [LISP] and Six/One Router [SIX-ONE] and those advocating a fuller separation of these roles including ILNP [ILNP] and RANGI [RANGI].
o IRTF路由研究小组（RRG）探索了一类解决全局路由可伸缩性问题的解决方案，包括将现有IP地址空间分离为LISP[LISP]和六/一路由器[Six-One]中用于标识符和定位器的地址空间，以及主张更充分地分离这些角色的地址空间，包括ILNP[ILNP]和兰吉[兰吉]。
o The End-Middle-End research group considered the potential for an explicit signaling and policy control plane for middleboxes and endpoints [EME]; at a joint meeting at IETF 69, the HIP and EME research groups discussed whether the EME framework could help HIP with middlebox traversal.
o 终端-中端研究小组考虑了为中间盒和端点[EME]建立明确的信令和策略控制平面的可能性；在IETF 69的一次联合会议上，HIP和EME研究小组讨论了EME框架是否有助于HIP进行中盒遍历。
o The IETF Multipath TCP working group is developing mechanisms to simultaneously use multiple paths in a regular TCP session. The MPTCP solution aims to solve the multihoming problem also addressed by HIP but by solving it for TCP specifically.
o IETF多路径TCP工作组正在开发在常规TCP会话中同时使用多条路径的机制。MPTCP解决方案旨在解决HIP也解决的多宿问题，但具体针对TCP解决。
o The Unmanaged Internet Protocol bears several similarities to the HIP architecture, such as the focus on identifiers that are not centrally managed that are also based on a cryptographic hash of a node's public key [thesis.ford].
o 非托管Internet协议与HIP体系结构有一些相似之处，例如，它关注的标识符不是集中管理的，而是基于节点公钥的加密散列[thesis.ford]。
o Apple Back To My Mac service provides secure connections between hosts using IPsec between a pair of host identifiers. However, the host identifier is reported to be an IPv6 Unique Local Addressing (ULA) address rather than a HIP identifier [RFC6281].
o Apple Back To My Mac服务使用一对主机标识符之间的IPsec提供主机之间的安全连接。但是，据报告，主机标识符是IPv6唯一本地寻址（ULA）地址，而不是HIP标识符[RFC6281]。
Although the HIP research group has not formally tried to compare HIP with other ID-locator split approaches, such discussions have occurred on other lists such as the Routing research group mailing list, and a comparison of HIP's mobility management solution with other approaches was published in [MOBILITY-COMPARISON].
尽管HIP研究小组尚未正式尝试将HIP与其他ID定位器拆分方法进行比较，但此类讨论已在其他列表上进行，如路由研究小组邮件列表，并且HIP的移动性管理解决方案与其他方法的比较已在[mobility-comparison]中发表。
This document is an informational survey of HIP-related research and experience. Space precludes a full accounting of all security issues associated with the approaches surveyed here, but the individually referenced documents may discuss security considerations for their respective protocol component. HIP security considerations for the base HIP protocol can be found in Section 8 of [RFC5201].
本文件是髋关节相关研究和经验的信息调查。空间排除了与此处调查的方法相关的所有安全问题的完整说明，但单独引用的文档可能会讨论其各自协议组件的安全注意事项。基本HIP协议的HIP安全注意事项见[RFC5201]第8节。
Miika Komu, Pekka Nikander, Ari Keranen, and Jeff Ahrenholz have provided helpful comments on earlier draft versions of this document. Miika Komu also contributed the section on opportunistic mode. We also thank Dacheng Zhang for contributions on hierarchical HIP architectures and the Crypto Forum Research Group (Adam Back and Paul Hoffman) for clarification of Diffie-Hellman privacy properties.
Miika Komu、Pekka Nikander、Ari Keranen和Jeff Ahrenholz就本文件的早期草案版本提供了有益的意见。Miika Komu还提供了关于机会主义模式的部分。我们还感谢张大成对HIP分层体系结构的贡献，以及加密论坛研究小组（Adam Back和Paul Hoffman）对Diffie-Hellman隐私属性的澄清。
[BEET-MODE] Nikander, P. and J. Melen, "A Bound End-to-End Tunnel (BEET) mode for ESP", Work in Progress, August 2008.
[BEET-MODE]Nikander，P.和J.Melen，“ESP的绑定端到端隧道（BEET）模式”，正在进行的工作，2008年8月。
[EME] Francis, P., Guha, S., Brim, S., and M. Shore, "An EME Signaling Protocol Design", Work in Progress, April 2007.
[EME]Francis，P.，Guha，S.，Brim，S.，和M.Shore，“EME信令协议设计”，正在进行的工作，2007年4月。
[HIP-DEX] Moskowitz, R., "HIP Diet EXchange (DEX)", Work in Progress, March 2011.
[HIP-DEX]Moskowitz，R.，“HIP饮食交换（DEX）”，正在进行的工作，2011年3月。
[HIP-MIDDLE] Hummen, R., Heer, T., Wehrle, K., and M. Komu, "End-Host Authentication for HIP Middleboxes", Work in Progress, October 2011.
[HIP-MIDDLE]Hummen，R.，Heer，T.，Wehrle，K.，和M.Komu，“HIP Middlebox的终端主机身份验证”，正在进行的工作，2011年10月。
[HIP-OPERATORS] Dietz, T., Brunner, M., Papadoglou, N., Raptis, V., and K. Kypris, "Issues of HIP in an Operators Networks", Work in Progress, October 2005.
[HIP-OPERATORS]Dietz，T.，Brunner，M.，Papadoglou，N.，Raptis，V.，和K.Kypris，“运营商网络中的HIP问题”，进展中的工作，2005年10月。
[HIP-PRIVACY] Zhang, D. and M. Komu, "An Extension of HIP Base Exchange to Support Identity Privacy", Work in Progress, July 2011.
[HIP-PRIVACY]Zhang，D.和M.Komu，“HIP-Base Exchange支持身份隐私的扩展”，正在进行的工作，2011年7月。
[HIPLS] Henderson, T., Venema, S., and D. Mattes, "HIP-based Virtual Private LAN Service (HIPLS)", Work in Progress, September 2011.
[HIPLS]Henderson，T.，Venema，S.，和D.Mattes，“基于HIP的虚拟专用局域网服务（HIPLS）”，正在进行的工作，2011年9月。
[HIPRG-PROXIES] Zhang, D., Xu, X., Yao, J., and Z. Cao, "Investigation in HIP Proxies", Work in Progress, October 2011.
[HIPRG-PROXIES]张，D.，徐，X.，姚，J.，和曹Z.“HIP PROXIES的调查”，正在进行的工作，2011年10月。
[HIT2IP] Ponomarev, O. and A. Gurtov, "Embedding Host Identity Tags Data in DNS", Work in Progress, July 2009.
[HIT2IP]Ponomarev，O.和A.Gurtov，“在DNS中嵌入主机身份标签数据”，正在进行的工作，2009年7月。
[ILNP] Atkinson, R., "ILNP Concept of Operations", Work in Progress, July 2011.
[ILNP]阿特金森，R.，“ILNP作战概念”，在建工程，2011年7月。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, November 2011.
[LISP]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议（LISP）”，正在进行的工作，2011年11月。
[LMDR] Swami, Y., Le, K., and W. Eddy, "Lightweight Mobility Detection and Response (LMDR) Algorithm for TCP", Work in Progress, February 2006.
[LMDR]Swami，Y.，Le，K.，和W.Eddy，“TCP的轻量级移动检测和响应（LMDR）算法”，正在进行的工作，2006年2月。
[MOBILITY-COMPARISON] Thaler, D., "A Comparison of IP Mobility-Related Protocols", Work in Progress, October 2006.
[移动性比较]Thaler，D.，“IP移动性相关协议的比较”，进展中的工作，2006年10月。
[MULTI-HOMED] Huitema, C., "Multi-homed TCP", Work in Progress, May 1995.
[多宿主]Huitema，C.，“多宿主TCP”，正在进行的工作，1995年5月。
[NAT-TRAVERSAL] Keranen, A. and J. Melen, "Native NAT Traversal Mode for the Host Identity Protocol", Work in Progress, January 2011.
[NAT-TRAVERSAL]Keranen，A.和J.Melen，“主机标识协议的本机NAT穿越模式”，正在进行的工作，2011年1月。
[RANGI] Xu, X., "Routing Architecture for the Next Generation Internet (RANGI)", Work in Progress, August 2010.
[RANGI]Xu，X.“下一代互联网的路由架构（RANGI）”，正在进行的工作，2010年8月。
[REAP4HIP] Oliva, A. and M. Bagnulo, "Fault tolerance configurations for HIP multihoming", Work in Progress, July 2007.
[REAP4HIP]Oliva，A.和M.Bagnulo，“HIP多宿系统的容错配置”，正在进行的工作，2007年7月。
[RFC1498] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, August 1993.
[RFC1498]Saltzer，J.，“网络目的地的命名和绑定”，RFC 1498，1993年8月。
[RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996.
[RFC1992]Castineyra，I.，Chiapa，N.，和M.Steenstrup，“Nimrod路由架构”，RFC 1992，1996年8月。
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
[RFC2367]McDonald，D.，Metz，C.，和B.Phan，“PF_密钥管理API，版本2”，RFC 2367，1998年7月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年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月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，和T.Henderson，“主机身份协议”，RFC 52012008年4月。
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5202]Jokela，P.，Moskowitz，R.，和P.Nikander，“将封装安全有效载荷（ESP）传输格式与主机标识协议（HIP）结合使用”，RFC 52022008年4月。
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 5203, April 2008.
[RFC5203]Laganier，J.，Koponen，T.，和L.Eggert，“主机身份协议（HIP）注册扩展”，RFC 52032008年4月。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
[RFC5204]Laganier，J.和L.Eggert，“主机身份协议（HIP）会合扩展”，RFC 52042008年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月。
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206]Nikander，P.，Henderson，T.，Vogt，C.，和J.Arkko，“使用主机身份协议的终端主机移动性和多宿”，RFC 52062008年4月。
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, April 2008.
[RFC5207]Stieemerling，M.，Quittek，J.，和L.Eggert，“主机身份协议（HIP）通信的NAT和防火墙穿越问题”，RFC 5207，2008年4月。
[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host Identity Protocol with Legacy Applications", RFC 5338, September 2008.
[RFC5338]Henderson，T.，Nikander，P.，和M.Komu，“在遗留应用程序中使用主机身份协议”，RFC 5338，2008年9月。
[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月。
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keranen, "Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators", RFC 5770, April 2010.
[RFC5770]Komu，M.，Henderson，T.，Tschofenig，H.，Melen，J.，和A.Keranen，“用于遍历网络地址转换器的基本主机身份协议（HIP）扩展”，RFC 57702010年4月。
[RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 6253, May 2011.
[RFC6253]Heer，T.和S.Varjonen，“主机身份协议证书”，RFC 6253，2011年5月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Ed.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, "Understanding Apple's Back to My Mac (BTMM) Service", RFC 6281, June 2011.
[RFC6281]Cheshire，S.，Zhu，Z.，Wakikawa，R.，和L.Zhang，“理解苹果的回到我的Mac（BTMM）服务”，RFC 62812011年6月。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
[RFC6298]Paxson，V.，Allman，M.，Chu，J.，和M.Sargent，“计算TCP的重传计时器”，RFC 62982011年6月。
[RFC6316] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Sockets Application Program Interface (API) for Multihoming Shim", RFC 6316, July 2011.
[RFC6316]Komu，M.，Bagnulo，M.，Slavov，K.，和S.Sugimoto，“多归宿垫片的套接字应用程序接口（API）”，RFC 63162011年7月。
[RFC6317] Komu, M. and T. Henderson, "Basic Socket Interface Extensions for the Host Identity Protocol (HIP)", RFC 6317, July 2011.
[RFC6317]Komu，M.和T.Henderson，“主机标识协议（HIP）的基本套接字接口扩展”，RFC 63172011年7月。
[RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash Table Interface", RFC 6537, February 2012.
[RFC6537]Ahrenholz，J.，“主机身份协议分布式哈希表接口”，RFC 6537，2012年2月。
[SIX-ONE] Vogt, C., "Six/One: A Solution for Routing and Addressing in IPv6", Work in Progress, October 2009.
[SIX-ONE]Vogt，C.，“SIX/ONE：IPv6路由和寻址解决方案”，正在进行的工作，2009年10月。
[TCP-RLCI] Schuetz, S., Koutsianas, N., Eggert, L., Eddy, W., Swami, Y., and K. Le, "TCP Response to Lower-Layer Connectivity-Change Indications", Work in Progress, February 2008.
[TCP-RLCI]Schuetz，S.，Koutsianas，N.，Eggert，L.，Eddy，W.，Swami，Y.，和K.Le，“TCP对下层连接变化指示的响应”，正在进行的工作，2008年2月。
[TRIGTRAN] Dawkins, S., Williams, C., and A. Yegin, "Framework and Requirements for TRIGTRAN", Work in Progress, February 2003.
[TRIGTRAN]Dawkins，S.，Williams，C.，和A.Yegin，“TRIGTRAN的框架和要求”，正在进行的工作，2003年2月。
[book.gurtov] Gurtov, A., "Host Identity Protocol (HIP): Towards the Secure Mobile Internet", ISBN 978-0-470-99790-1, Wiley and Sons, (Hardcover, p 332), June 2008.
[book.gurtov]gurtov，A.，“主机身份协议（HIP）：走向安全的移动互联网”，ISBN 978-0-470-99790-1，Wiley and Sons，（精装版，第332页），2008年6月。
[paper.blind] Ylitalo, J. and P. Nikander, "BLIND: A complete identity protection framework for end-points", Proc. of the Twelfth International Workshop on Security Protoc ols, April 2004.
[paper.blind]Ylitalo，J.和P.Nikander，“盲人：终点的完整身份保护框架”，Proc。2004年4月，第十二届安全协议国际研讨会。
[paper.datarouter] Touch, J. and V. Pingali, "DataRouter: A Network-Layer Service for Application-Layer Forwarding", Proceedings of International Workshop on Active Networks (IWAN), May 2003.
[论文.数据路由器]Touch，J.和V.Pingali，“数据路由器：应用层转发的网络层服务”，主动网络国际研讨会论文集，2003年5月。
[paper.fara] Clark, D., Braden, R., Falk, A., and V. Pingali, "FARA: Reorganizing the Addressing Architecture", Proceedings of ACM SIGCOMM FDNA Workshop, August 2003.
[paper.fara]Clark，D.，Braden，R.，Falk，A.，和V.Pingali，“fara：重新组织寻址架构”，ACM SIGCOMM FDNA研讨会论文集，2003年8月。
[paper.firewall] Lindqvist, J., Vehmersalo, E., Komu, M., and J. Manner, "Enterprise Network Packet Filtering for Mobile Cryptographic Identities", International Journal of Handheld Computing Research (IJHCR), Volume 1, Issue 1, Pages 79-94, January 2010.
[paper.firewall]Lindqvist，J.，Vehmersalo，E.，Komu，M.，和J.Way，“移动加密身份的企业网络数据包过滤”，国际手持计算研究杂志（IJHCR），第1卷，第1期，第79-94页，2010年1月。
[paper.handovers] Varjonen, S., Komu, M., and A. Gurtov, "Secure and Efficient IPv4/IPv6 Handovers Using Host-Based Identifier-Locator Split", Proceedings of the 17th International Conference Software, Telecommunications, and Computer Networks, September 2009.
[论文.切换]Varjonen，S.，Komu，M.和A.Gurtov，“使用基于主机的标识符定位器拆分的安全高效IPv4/IPv6切换”，第17届软件、电信和计算机网络国际会议记录，2009年9月。
[paper.hi3] Gurtov, A., Korzon, D., Lukyanenko, A., and P. Nikander, "Hi3: An Efficient and Secure Networking Architecture for Mobile Hosts", Computer communication, 31 (2008), p. 2457- 2467, <http://www.cs.helsinki.fi/u/gurtov/papers/ comcom_hi3.pdf>.
[paper.hi3]Gurtov，A.，Korzon，D.，Lukyanenko，A.，和P.Nikander，“hi3：移动主机的高效和安全网络架构”，计算机通信，31（2008），P。2457- 2467, <http://www.cs.helsinki.fi/u/gurtov/papers/ com_hi3.pdf>。
[paper.hipanalysis] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the HIP Base Exchange Protocol", Proc. of the 10th Australasian Conference on Information Security and Privacy (ACISP), July 2005.
[论文.hipanalysis]Aura，T.，Nagarajan，A.，和A.Gurtov，“HIP碱基交换协议的分析”，Proc。第十届澳大拉西亚信息安全和隐私会议（ACISP）的报告，2005年7月。
[paper.i3] Stoica, I., Adkins, D., Zhuang, S., Shenker, S., and S. Surana, "Internet Indirection Infrastructure (i3)", Proceedings of ACM SIGCOMM, August 2002.
[paper.i3]Stoica，I.，Adkins，D.，Zhuang，S.，Shenker，S.，和S.Surana，“互联网间接寻址基础设施（i3）”，ACM SIGCOMM会议记录，2002年8月。
[paper.layered] Balakrishnan, H., Lakshminarayanan, K., Ratnasamy, S., Shenker, S., Stoica, I., and M. Walfish, "A Layered Naming Architecture for the Internet", Proceedings of ACM SIGCOMM, August 2004.
[论文分层]Balakrishnan，H.，Lakshminarayanan，K.，Ratnasamy，S.，Shenker，S.，Stoica，I.，和M.Walfish，“互联网分层命名架构”，ACM SIGCOMM会议录，2004年8月。
[paper.leap-of-faith] Komu, M. and J. Lindqvist, "Leap-of-faith security is enough for IP mobility", Proceedings of the 6th IEEE Conference on Consumer Communications and Networking Conference (CCNC 09), 2009.
[论文.信仰的飞跃]Komu，M.和J.Lindqvist，“信仰的飞跃安全足以实现IP移动性”，第六届IEEE消费者通信和网络会议记录（CCNC 09），2009年。
[paper.mobiarch] Khurri, A., Vorobyeva, E., and A. Gurtov, "Performance of Host Identity Protocol on Lightweight Hardware", Proceedings of ACM MobiArch, August 2007.
[paper.mobiarch]Khurri，A.，Vorobyeva，E.，和A.Gurtov，“轻量级硬件上主机身份协议的性能”，ACM mobiarch会议记录，2007年8月。
[paper.namespace] Komu, M., Tarkoma, S., Kangasharju, J., and A. Gurtov, "Applying a Cryptographic Namespace to Applications", Proc. of First International ACM Workshop on Dynamic Interconnection of Networks, September 2005.
[论文名称空间]Komu，M.，Tarkoma，S.，Kangasharju，J.，和A.Gurtov，“将加密名称空间应用于应用程序”，Proc。第一届ACM网络动态互连国际研讨会，2005年9月。
[paper.netpointers] Tschudin, C. and R. Gold, "Network pointers", ACM SIGCOMM Computer Communications Review, Vol. 33, Issue 1, January 2003.
[论文.网络指针]Tschudin，C.和R.Gold，“网络指针”，ACM SIGCOMM计算机通信评论，第33卷，第1期，2003年1月。
[paper.p2psip] Koskela, J., Heikkila, J., and A. Gurtov, "A secure P2P SIP system with SPAM prevention", ACM Mobile Computer Communications Review, July 2009.
[paper.p2psip]Koskela，J.，Heikkila，J.，和A.Gurtov，“具有垃圾邮件预防功能的安全P2P SIP系统”，ACM移动计算机通信评论，2009年7月。
[paper.triad] Cheriton, D. and M. Gritter, "TRIAD: A New Next-Generation Internet Architecture", July 2000, <http://www-dsg.stanford.edu/triad/triad.ps.gz>.
[论文.triad]Cheriton，D.和M.Gritter，“triad:新一代互联网架构”，2000年7月<http://www-dsg.stanford.edu/triad/triad.ps.gz>.
[paper.usable-security] Karvone, K., Komu, M., and A. Gurtov, "Usable Security Management with Host Identity Protocol", Proc. of the IEEE/ACS International Conference on Computer Systems and Applications, May 2009.
[论文.可用安全]Karvone，K.，Komu，M.，和A.Gurtov，“使用主机身份协议的可用安全管理”，Proc。2009年5月，IEEE/ACS计算机系统和应用国际会议的主席。
[thesis.bishaj] Bishaj, B., "Efficient Leap of Faith Security with Host Identity Protocol", Master thesis, Helsinki University of Technology, June 2008.
硕士学位论文，赫尔辛基工业大学，2008年6月，“信仰安全与主机身份协议的有效飞跃”。
[thesis.ford] Ford, B., "UIA: A Global Connectivity Architecture for Mobile Personal Devices", Doctoral thesis, Massachusetts Institute of Technology, September 2008.
[论文.福特]福特，B.，“UIA：移动个人设备的全球连接架构”，博士论文，麻省理工学院，2008年9月。
[thesis.karlsson] Karlsson, N., "Enabling Multiple Host Identities on Linux", Master thesis, Helsinki University of Technology, September 2005.
[论文]卡尔森，卡尔森，N.，“启用多个主机身份在Linux上”，硕士论文，赫尔辛基工业大学，2005年9月。
[thesis.takkinen] Takkinen, L., "Host Identity Protocol Privacy Management", Master thesis, March 2006, <http://www.tml.tkk.fi/~anttiyj/Laura-Privacy.pdf>.
[论文.takkinen]takkinen，L.，“主机身份协议隐私管理”，硕士论文，2006年3月<http://www.tml.tkk.fi/~anttiyj/Laura Privacy.pdf>。
Authors' Addresses
作者地址
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
Andrei Gurtov University of Oulu Centre for Wireless Communications CWC P.O. Box 4500 FI-90014 University of Oulu Finland
安德列Gurtov奥卢大学无线通信中心CWC邮政信箱4500芬兰-F990014奥卢大学
EMail: gurtov@ee.oulu.fi
EMail: gurtov@ee.oulu.fi