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
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を追加することの影響をまとめたもの。ネットワークオペレータの視点だけでなく、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.
この文書はインターネットResearch Task Force（IRTF）の製品です。 IRTFはインターネット関連の研究開発活動の成果を公表しています。これらの結果は、展開に適していない可能性があります。このRFCはインターネットResearch Task Force（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
この文書では、BCP 78との日に有効な（http://trustee.ietf.org/license-info）IETFドキュメントに関連IETFトラストの法律の規定に従うもの
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
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].
ホスト識別プロトコル・アーキテクチャは、インターネットアーキテクチャに、新しい名前空間、「ホストアイデンティティ」の名前空間を紹介しています。この新しい名前空間の明確な目的は、アーキテクチャのインターネットワーキング層の識別子（ホスト・アイデンティティ）とロケータ（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.
ホスト識別プロトコル自体は、ホスト間のホストアイデンティティ（公開鍵）の迅速な交換を提供し、（「SIGN-と-MAC」）は、このようなエンドポイント間の共有秘密[RFC5201]を確立するために、シグマに準拠しているのDiffie-Hellman鍵交換を使用しています。そのようなカプセル化セキュリティペイロード（ESP）[RFC4303]などの別の適切なセキュリティプロトコルと共に使用される場合、プロトコルは、サービス拒否（DoS）とMITM（中間者）攻撃に対して耐性であるように設計されており、ネットワーク層アドレスの変更を横切って通信の継続性を可能にしながら、それは、例えば、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]
実験的RFC仕様の数は、HIPベースのプロトコル[RFC5201]、ESPのカプセル化[RFC5202]、登録拡張[RFC5203]、HIPランデブーサーバ[RFC5204]、DNSリソースレコード[RFC5205]を含め、IETFのHIPのワーキンググループによって発表されましたそして、モビリティ管理[RFC5206]。ホストアイデンティティは、オーバーレイルーティング可能な暗号ハッシュ識別子（蘭）インターネットプロトコルに[RFC4843]として表されます。 NATのファイアウォールを通過するための要件の1 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.
この文書で使用される用語は、様々な文書の別の場所で定義されています。具体的には、読者はHIP-特定用語のリストは、[RFC4423]のセクション3を確認することが示唆されています。
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を研究するために形成されました。これらのプロジェクトは、実験のRFCによるだけでなく、まだRFCで指定されていない拡張機能をサポートする相互運用できるようにHIPを可能にするソフトウェアを開発してきました。
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, operators, enterprises) on HIP deployment. It is this latter category of work (and not the extensions to HIP) on which this report is focused.
研究グループは、2つの分野で最も活躍しています。まず第一に、研究グループは当初、2008年4月にこの作品の一部（NATトラバーサルを公表IETF HIPワーキンググループおよびRFCのセット（RFC 5201から5206）の範囲と憲章を超えたHIPへの拡張を研究しています、 HIP、レガシーアプリケーションのサポート、およびHIPのネイティブソケットAPI）のための証明書の形式は、最終的に2008年のその他の拡張機能（例えば、インターネット間接基盤でHIP（I3）オーバーレイ、分散の使用でそのrecharter時にIETF HIPのワーキンググループに流入しましたHITベース（ホストアイデンティティタグ）検索、モバイルルータの拡張、など）のためのハッシュテーブルは、どちらかはまだ研究グループで取り組まれているか、放棄されています。この期間中、研究グループのエネルギーの大部分がhipsの拡張や（例えばモノのインターネットなど）、新たな問題領域へHIPの応用を研究してきました。第二に、研究グループはHIPの展開上の別の参加者（エンドユーザー、オペレータ、企業）からの進捗状況と、これまでに行った実装と実験の成果だけでなく、議論の視点を議論しました。これは、このレポートが重視されている。この後者の仕事の範疇（とない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).
他のメカニズムとHIPのO客観的な比較（研究グループは、このようなエンド・ミドルエンド（EME）の研究グループ、ルーティング研究グループ（RRG）、およびshim6-などの他の努力のHIPの関係に関するいくつかの議論を行ったが、ベースのプロトコル）。
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.
HIPベースラインアーキテクチャとプロトコルまたは他のアイデンティティ・ロケータ分離アーキテクチャの変更O。
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.
前の2つのセクションでは、HIP作業、ネットワークのユーザとオペレータへの影響に次の3つのフォーカスを行うために、ネットワーク配管の実装と展開に焦点を当てる一方。
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は、HIPの展開上のオペレータの視点を提供します。
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は、このセクションでは、我々はいくつかのインプリメンテーション・グループは、この拡張機能を開発する際に遭遇したことをいくつかの経験をまとめ、主にインターネットホストのTCP / IPスタックの拡張機能で、そして。私たちの議論はここでは、ラップトップ、デスクトップ、サーバ、およびPDAなどの汎用コンピューティング・プラットフォームにHIPを追加することで実装の経験を描画します。そのようなエンドホスト上でHIPをサポートするには、2つの主要な方法があります。最初は、直接識別子とロケータのデカップリングをサポートするために、カーネルの実装に変更を加えることです。変更のこのタイプは、データ・スループット性能上の利点がありますが、それはまた、展開がより困難です。第二のアプローチは、ユーザ空間内のすべての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 OpenHIP（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:
このセクションでは、以下を想定してHIPの支援に焦点を当てます：
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.
（ソケットAPIを使用して）Oアプリケーションは、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の実装は、典型的には、実際には図1に示すように、HIPが完全にカーネル内、またはハイブリッドとして、ユーザが空間で完全に実装された、IPsecの拡張スタックと連携鍵管理プロセスから成りユーザースペースキー管理プロセスとカーネルレベルのESP。
+--------------------+ +--------------------+
| | | |
| | | |
| +------------+ | | +------------+ |
| | Key | | HIP | | Key | |
| | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | |
| +------------+ | | +------------+ |
| ^ | | ^ |
| | | | | |
| v | | v |
| +------------+ | | +------------+ |
| | IPsec- | | ESP | | IPsec- | |
| | Extended | | | | Extended | |
| | Stack | <-+-----------------------+-> | Stack | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| Initiator | | Responder |
+--------------------+ +--------------------+
Figure 1: HIP Deployment Model
図1：HIPの展開モデル
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_KEYのAPI [RFC2367]として示されています）。また、正しく応答するトランスポートプロトコルでBEETモード（バウンドエンドツーエンドトンネル）処理[BEET-MODE]、名前解決ライブラリの拡張、および（将来的に）相互作用をサポートするために、ESPの実装自体を変更する必要がモビリティとマルチホーミングイベントに[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 |
---------
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.
レガシーアプリケーションはAPIをソケット（IPv4用）標準（IPv6用）AF_INET6とAF_INETを使用し続けることができます。 IPv6アプリケーションは蘭のために予約されたIPv6アドレス空間の一部であるホストアイデンティティタグ（HIT）、に直接結合します。 IPv4アプリケーションは、宿主内で意味を持つローカルスコープ識別子（LSI）に結合します。 HIP層は依然としてHIP基本交換のために下に使用されているIPアドレスにLSIやHITSから翻訳します。
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は、現時点ではすべてのオペレーティングシステムのディストリビューションでサポートされていないので、カーネルの変更は、既存の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.
（具体的には起因ネイティブIPsec実装にはなく、HIP）現在のLinux IPsec実装で経験一の不都合が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を展開における重要な展開の利点があります。すべての3つのオープンソースの実装では、ターゲット・システム上のアプリケーション展開の典型的なユーザ空間の実装とバイナリパッケージ（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）デバイスなどのカーネルの仮想デバイスを展開することです。ルーティングやパケットフィルタリングルールは、これらのデバイスに権利パケットをそらすために適用されなければなりません。
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.
一例として、ユーザ空間の実装は、仮想デバイスのヒットやLSIに対応する宛先アドレスを持つすべてのパケットを指示するルートをインストールすることができます。おそらくユーザ空間のデーモン、ESPヘッダ及びUDPヘッダが印加され、外側IPアドレスがHITを置き換え、そしてパケットは、カーネルに再送信されます。逆方向では、ESPまたはUDPポート番号に関連付けられたソケットがESPで保護されたパケットを受信するために使用することができます。 UDPカプセル化が使用される場合、それ自体がHIP番号またはUDPポートにバインドされた生のソケットが送受信されてもよいHIPシグナリングパケット。
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と多くの初期の実験は、例えば、ドメイン名を基づいてHITを学ぶために、またはIPアドレスを解決するために、任意の解像度のインフラなしで、IPv6ソケット・コールに直接ヒットを使用して関与しています。 HIPは、ヒットを使用して実験するには、解決サービスが存在しない場合に先験的HIT交換が必要です。ヒットの手動交換は、実験のための主要な不便となっています。これは、1）日和見HIPモード（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エントリにヒットを保存し、ドメイン名でそれらを見て、そのようOpenDHTなどのヒットのため3）名前解決サービス[RFC6537]、各マシン上のファイルを移入する4）アドホックHIT交換サービス、 RFC 5205で説明DNS拡張用または5）のサポート。
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インターフェースの二つの独立した実装を進めています。現時点では、実験を可能とするための最も簡単な方法は、セキュアシェル（SSH）とセキュアコピー（SCP）に基づいて、シェルスクリプトは、ピア・マシンに接続し、ローカルの構成ファイルへのヒットをコピーすることができたときにアプローチ4のように見えます。しかし、このアプローチは、長期のためのスケーラブルなまたは安全ではありません。 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].
日和見モードでは、イニシエータは、レスポンダのHITの知識がなくても塩基交換を開始します。日和見モードの主な利点は、それが彼の[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].
日和見モードはまた、いくつかの欠点があります。まず、イニシエータは一意にちょうどプライベートアドレスレルム[RFC5770]の存在下でのIPアドレスに基づいてレスポンダを特定しない場合があります。第二に、イニシエータは、「信仰の飛躍」のために解決しなければなりません。つまり、何のman-in-the-middle攻撃が存在しないと仮定します。しかし、これは、部分的にレスポンダ側に[RFC6253]を証明書を使用するか、明示的に接続[paper.usableセキュリティ]を受け入れるためのグラフィカルインタフェースを使用してユーザを促すことによって軽減することができます。
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.
日和見モードのみレスポンダのステートマシンの小さな変化とイニシエータ[paper.leap-の-信仰]のための小さな変更が必要です。レスポンダは単にレスポンダための所定HITなし（「I1」として知られている）最初のHIP基本交換パケットを受信すると、適切なHITを選択することができるが、イニシエータがレスポンダから最初のパケットを処理する際に、より注意しなければならない、としても知られています"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プロジェクトの文脈では、日和見モードが正常にサービス登録[RFC5203]のためのHIP層に適用されています。 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プロジェクトは、2つの異なる層でシムを介在させて日和見モードで実験を行いました。最初のアプローチでは、APIベースのシムは、アプリケーションからのソケット呼び出しをキャプチャするために実装されました。これは、実装が多少複雑かつ明示的に要求された日和見モードを使用するには、個々のアプリケーション（またはアプリケーションのグループ）を可能にしました。第二のアプローチ[paper.leapオブ信仰]において、シムは、ネットワークとトランスポート層の間に配置しました。成功した塩基交換の際に、シムは、IPベースのパケットが戻っネットワークスタックに翻訳されたパケットを再注入することによって、パケットフローベースにヒットする流れに翻訳しました。
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はI1sがゼロ化された受信機のHITで受信受け入れるか否かを判断します。イニシエータの側では、このオプションは1つが知られているホストのアイデンティティファイルに名前やLSIを構成することができます。 HITフィールドが欠落している場合、I1はゼロ化された受信者のHITに送信されます。 LSIは、アソシエーションをトリガするためのIPv4アプリケーションによって必要とされます。なお、通常、使用されるLSIは、HITの底24ビットに基づいているが、日和見モードの場合には、HITは不明です。従って、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アプリケーション[RFC6317]でHIP単独で使用することができるいずれか。この方法では、日和見モードの固有のセキュリティのトレードオフは、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は日和見モードで使用する場合、イニシエータはレスポンダのHITを知らないが、それはその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アドレスレコードのキーとしてヒットを使用することができます。第二に、ポノマリョフによる作業は、逆DNSツリーが蘭スペース[HIT2IP]の逆ルックアップに使用することができることを示しています。第三に、解像度の必要性は（HITを解決するための）アドレス解決プロトコル（ARP）メッセージに、ある意味では同様のHIPブートストラップメッセージ、いくつかのタイプをトリガすることができます。ブートストラップ（BOS）パケットはHIP基本仕様の初期リビジョンに存在することが使用されるが、それは、一度に不十分な関心に起因し、最終的な仕様から除去しました。それは、ピアのIPアドレスを知らない場合HIPLの実装は、現在リンクブロードキャストIPアドレスにI1を送信します。これは、侵入の試みとして、未知のプロトコル番号と放送を分類したウイルス対策ソフトウェアを実行しているいくつかの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_KEYのAPI [RFC2367]として知られています。 PK_KEYは、オペレーティング・システムでの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_KEYインタフェースへの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 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基本交換をトリガするときHIPとIPsec実装は、塩基交換が完了するとIPsec SAが設定されるまでパケットをバッファリングすることができる場合を除き、最初のデータパケットが失われる可能性があります。データ・パケットの損失は、それが不必要にアプリケーションを遅延TCPタイムアウト[RFC6298]でのTCP SYNパケットの結果である場合。 UDPパケットの損失は、用途にさらに長いタイムアウトを引き起こす可能性があります。したがって、HIP実装がパケットのバッファリングをサポートすることが重要であることが判明しました。 HIP基本交換またはUPDATEは、軽量デバイスである場合、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]でマルチホーミングサポートは、ホストが現在のロケータが失敗した場合、代替ロケータを使用して開始したときに、フェイルオーバーの目的のために意図されます。しかし、ホストが異なるロケータ間の負荷分散のために、このマルチホーミングサポートを使用することができます。このようにしマルチホーミングは、潜在的にトランスポートプロトコルの輻輳制御と損失検出メカニズムの問題を引き起こす可能性があります。しかし、この容量でHIPマルチホーミングを使用してからの実験結果は報告されていません。
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を経験する場合、その変化は、不必要に高い再送タイムアウト値を設定する、ハイです。パケットが失われた場合、送信者は、再送信する前に過度に長く待ちます。幸いなことに、選択的謝辞（袋）およびリミテッド送信を展開近代的な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 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].
いくつかのパス間のロードバランシングは、各パスの能力のいくつかの見積もりが必要です。 TCPの輻輳制御アルゴリズムは、すべてのパケットが同じパスに沿って流れていることを前提としています。ロード・バランシングを実行するために、HIP層は、各パスの遅延、帯域幅、及び損失率などのパラメータを推定することを試みることができます。 HIPスケジューラは、次に、その能力及び遅延に応じてパス間でパケットを配信することができ、全体的な利用率を最大にし、並べ替えを最小限に抑えます。スケジューラの設計は、現在の研究活動のテーマです。どれもが存在することが報告されていません。異なるネットワークパスが異なる最大伝送単位（MTU）サイズを有することができます。トランスポートプロトコルは接続のみの初めに一般的にMTU探索を行います。 HIPは、トランスポート層からの移動性を隠したように、新しいパス上のパケットは、トランスポートプロトコルの知識がなくても断片化し得ることを発生することがあります。この問題を解決するために、HIP層は、モビリティイベントのトランスポート層に通知することができます。トランスポート層に、このような通知をサポートするためのプロトコルは、トランスポートトリガ[TRIGTRAN]、軽量モビリティ検出および応答（LMDR）[LMDR]、および接続の変更[TCP-RLCI]にTCP応答を含め、過去にIETFに提案されています。
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.
公にへの発信が開始した接続用のレガシーNATトラバーサルは、Responderがすべての3つのHIP実装によって実装されています対処しました。 2（HIPLとHIP4BSD）インバウンドNATトラバーサルのためのインタラクティブ接続確立（ICE）技術[RFC5770]を実装します。また、HIP上のTeredo [RFC4380]の使用は、Teredoのを効果的にシステムにルーティング可能な、仮想ロケータとして現れるので、ICE技術のために必要な変更よりも簡単であったことが報告されています。 UDPカプセル化は今OpenHIPのIPv4 HIP実装のHIPのデフォルトの動作モードです。実験のためのIPv6 NATの実装を見つけることは困難でした。また、ICE技術に基づくHIPのためのNATトラバーサルの最初の実装は実装したり統合するために複雑になることが証明され、ネイティブNATトラバーサルモードは、HIP [NATトラバーサル]のために開発中です。 NATトラバーサルは、将来的にはHIP処理の主要なモードであることが予想されます。
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.
いくつかの実験的な実装によって対処されていない1つの問題は、おそらく複数のホストアイデンティティ（一部が公開されていない場合もある）を越えソースHITの選択を実行する方法です。これは、トランスポート・ソケットのソースアドレス選択に似ています。ユーザーに公開するにはどのくらいの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、今アールト）は、複数のホスト・アイデンティティ[thesis.karlsson]を制御するために、ネイティブのHIP APIの拡張機能を実装しました。 Linuxのルーティングおよび複数のIDを持つ問題がHIPL開発グループによって発見されました。 Linuxのルーティングが最長プレフィックス一致に基づいているように、スタックは、宛先HITに基づいてソースHITを選択するため、仮想デバイス上の複数のヒットを有するアクセス制御の観点から問題があります。このため粒度の粗いソリューションは、Linuxのネットワークstatckに蘭のための最長プレフィックス一致を終了することです。しかし、よりきめ細かな溶液は、将来的に標準化さ新しいアルゴリズムとの互換性を容易にするために、宛先HITを生成するために使用されるアルゴリズムにソースHITマッチングを返すようにしよう。
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ベース交換に使用されます。 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部門によって投与された場合、エンドユーザは、ファイアウォールの設定を管理していない場合であってもよいです。しかし、UDP上HIPの使用は、これらの問題のいくつかを軽減しています。 UDP上でHIPを使用する場合、ファイアウォールは、それらにアウトバウンド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のサポートが追加されました。ヒットはORCHID接頭辞を使用して、一般的なIPv6アドレス空間から使用されているようHIPは、うまくIPv6アプリケーションをサポートしています。彼らはIP層でルーティングできませんが、ヒットは、統計的にユニークです。オーバーレイ・ネットワークまたはブロードキャスト技術のヒットに基づいてルートパケットに利用可能である場合を除きしたがって、ヒットとルーティング可能なIPアドレスの間のマッピングは、HIP層に必要です。
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アプリケーションのために、32ビットのローカルスコープ識別子（LSI）は、ソケットAPIに必要です。 LSIは、ホストIDの別名で、1つのホスト内でのみ意味があります。特定のホスト上の特定のホストIDを参照するように構成されている、やLSIは、未割り当てのIPv4アドレス範囲から引き出されてもよいが、LSI空間上の協調の欠如が実装を妨げる可能性がある場合、IPv4アドレスは、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アプリケーションを使用することが可能となります。これは、「interfamily操作」（別のアドレスファミリ間の柔軟性）と呼ばれており、輸送擬似ヘッダは関係なく、常にアプリケーションや基盤となるネットワークパスがIPv4のに基づいているかどうかのヒットに基づいているという事実で有効になっています。すべての3つのオープンソースのHIP実装がinterfamilyハンドオフのサポートのいくつかのフォームを実証しています。 Linuxカーネルの中BEETパッチのinterfamily部分は、単一の家族の処理と比較して完了することがより困難に発見されました。
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アドレス[paper.handovers]基づくものです。
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）とインターネット鍵交換プロトコル（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 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.
一部のユーザーは、明示的に他のVPNとモバイルIPソフトウェアとHIPの共存について尋ねてきました。 Windowsでは、VPNクライアントはOpenHIPの実装で使用されるドライバと競合する可能性のあるTAPドライバの独自のバージョンをインストールする傾向があります。また、意図しないHIP-オーバー-VPNセッションまたはESPセキュリティパラメータインデックス（SPI）のスペースの調整不足につながるの調整不足が原因の問題があるかもしれません。しかし、これらの3つのタイプの競合は憶測であり、研究グループに報告されていませんでした。 HIPおよびVPNソフトウェアの唯一のいくつかの肯定的なレポートが正しくHIPLグループにより報告されている共存します。
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].
IPv6が広くアプリケーションで使用されていないため、従来のアプリケーションでは、LSIのサポートが重要です。アプリケーションは、HIP上でうまく動作するように得ることに主な問題は、実装そのもののバグ、または（例えばTCPはLinuxのIPsec実装に起因するタイムアウトなど）の待ち時間に関連する問題に関連しています。実際に遭遇した重大な障害がなかった、ともネイティブアプリケーション[paper.p2psip]でHIPを使用していくつかの経験がありました。
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]はBIND9のDNSサーバの両方に、NEC Eurolabsが開発し、OpenHIPに貢献し、またHIPLプロジェクトによって開発されたました。レガシーアプリケーションは、HIPリソースレコードを照会しませんが、DNSプロキシ（ローカルリゾルバは）解像度のパスに自分自身を挿入し、HI、レコードを照会することができます。 HIPLためのBIND 9の展開は、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].
既存のDNS上のHIPへ[RFC5205]に基づいて、変更の影響については報告されていない研究が行われていません。逆ツリー[HIT2IP]でヒットを保存するためにDNSを使用して上のいくつかの研究が行われています。
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を完了し、プロトタイプとのRFC 5204パフォーマンス測定結果として公開されている利用可能である（HIP認識しているとホストとの間で区別するためにHIP識別子を使用するNAT）のためのHIP登録プロトコルの設計が、実験でありますまだ見つからない。 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 (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.
オーラによって論じたように、ら。 [paper.hipanalysis]、イニシエータホストアイデンティティ（HI）の暗号化がHIPのために、ポリシーベースのNATやファイアウォールのサポート、およびミドル認証を防ぐことができます。キャッチは、HIが暗号化されている場合、ネットワーク内の中間装置は、このように、安全にHIPアソシエーションの状態を作成することはできません開始剤（I2）と、から2番目の塩基交換パケットの署名を検証できないことです。 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 HITと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のサーバーのセットは、数年前からプラネット上で実行されていました。プラネットアカウントがサーバーを実行するために必要ですが、誰でも公然と提供されるサービスを使用することができます。
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の主なアイデアは、送信データパケットを効率的にエンドツーエンドながら、IPsecを使用して、ルックアップ及びランデブーサービスとしてI3システムを用いてHIP制御パケットを送信することです。性能測定は、プレーンIP、HIP、及びI3 [paper.hi3】関連付け設定待ち時間、スループット、およびHI3のRTTの比較を行いました。
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のサーバーは、オフラインになっています。
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システムは解析的に大規模に評価されています。この問題は、サーバーに十分な負荷を作成するために、クライアントのより多くを実行することは困難であるということです。百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: o RVS may be better than dynamic DNS updates for hosts that change their address rapidly.
ランデブーサーバ（RVS）[RFC5204]はHIPLためHIITによって実装されており、実装もOpenHIPのために存在します。コンセプトは、[RFC5770]でリレーサーバに拡張されました。 HIPL実装と初期の実験は以下の観測を作成：RVSが急速に自分のアドレスを変更するホストのためのダイナミックDNSアップデートよりも良いかもしれoを。
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更新とランデブーサーバを経由して送信CLOSEパケットをお勧めします。 UPDATEメッセージの取り扱い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.
フォールトトレランス（例えば、1つのランデブー・ノードがクラッシュ）と最良RVSを選択するためのアルゴリズムのホストあたりO複数RVSS。
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負荷分散。レスポンダのIDが共有されているか、日和見HIPが使用されている場合RVSサーバーが異なるレスポンダにI1sを配布することができます。
o Offering a rendezvous service in a P2P fashion by HIP hosts.
HIPホストがP2P方式でランデブーサービスを提供し、O。
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の名前解決に加えて、最終ホップDHT分解能でクライアントのための標準的なDNSインターフェースを組み合わせたハイブリッドアプローチが開発されました。アイデアは、DNSソリューション（広い展開、レガシーアプリケーションのサポート）の利点は、DHT（フォールトトレランス、フラットなデータキーを処理する際の効率）の利点と組み合わせることができるということです。 DHTは、通常、最終ホップDNSゾーンとDNSサーバーを管理する組織によって内部的に実行されます。その方法は、その組織に属するヒットが解決システムの展開性を向上させ、組織によってローカルに保存することができます。しかし、組織はまた、自分たちの間でDHTを共有したり、そのようなOpenDHTとして公に利用できるDHTに自分のDNSサーバを接続することができます。地理的に広がって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.
システムは、DHTサーバにヒットするためのクエリーをリダイレクトするBINDのDNSサーバを変更することによって、試作しました。インタフェース仕様[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 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.
システムの性能は、HITとIPアドレスのマッピングを照会および更新するための要求の急速なシーケンスを実行することにより評価しました。要求レートが毎秒1 200への要求から変化させました。 1つのクエリ要求の平均待ち時間が50ミリ秒未満と固定更新待ち時間低い要求レートで100ミリ秒未満でした。しかし、遅延は、秒当たり200の要求（更新レート0）、ほぼ2秒（更新率0.5）のために1秒に達し、要求レートで指数関数的に増加しました。さらに、最大遅延は数回で平均を上回りました。
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の実装の相対的非効率性（バンブー）によって説明されており、間違いなく将来的に向上させることができました。
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システム変数を設定する必要があります。これは、交互の利益またはユーザがそのようなポリシーの選択を抱えているかどうかに応じて欠点と考えられるアプリケーションは、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を使用するための別の方法は、HIP認識するように改変されているローカルアプリケーションプロキシ（例えば、イカのWebプロキシ）を介して行われます。 HIPのプロキシの議論は、研究グループの活動の現在のフォーカス[HIPRG-プロキシ]です。
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 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.
FTPが原因のアプリケーションの紹介の問題に動作しないだろうという懸念は、すなわち、アプリケーションメッセージ内のIPアドレスを渡し、実際にはFTPのための問題ではないことが発見されました。両方の受動及び能動モード[paper.namespace]でうまく機能することが示されています。それは紹介が本当に実際にどのように大きな問題未解決の問題のまま。少なくとも、彼らは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を展開すると、ホスト識別情報の管理にはいくつかの問題が生じます。オペレータは、ホストアイデンティティそのものを生成するのではなく、各ホストがアイデンティティを作成してみましょうすることを好むことがあります。いくつかの要因が、そのような必要性を作成することができます。公開鍵と秘密鍵の生成は、携帯電話など、軽量なデバイス上で数十秒かかることが厳しい操作です。ホストIDを生成した後、オペレータはすぐに、独自の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.
オペレータは、顧客のホストIDを認定する公開鍵基盤（PKI）を使用することができます。次に、それは、顧客の公開鍵に署名するオペレータの認証局（CA）の秘密鍵を使用しています。この方法では、CAの公開鍵を所有する第三者は、インフラストラクチャへのアドミッション制御のために、例えば、顧客のホストIDを確認し、この情報を使用することができます。このような慣行は、自己生成されたホストのIDが使用されている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）どちらにホスト名を使用している場合は、しっかりとホストIDを交換する問題が残っています。 HIPは日和見モードで使用する場合、のman-in-the-middleはまだ交換を傍受し、独自の持つホストIDを置き換えることができます。
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によって提供されるシグナリングは、それがオペレータのネットワーク内の既存の機構によって固定された場合、ホストIDを送達するために使用することができます。
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].
モバイルデバイスの処理能力も考慮しなければなりません。ある研究では、[paper.mobiarch]（ノキアN770インターネット錠剤は、200 MHzのプロセッサを有する）の軽量デバイス上のHIPとESPの使用を評価しました。そのようなプラットフォーム上でESPを使用してのオーバーヘッドは、スループットの点で約30％、許容可能であることが見出されました。 HIPによって設定されたESPセキュリティアソシエーション上で、それは3.27 Mbpsのあった無線LAN経由バルクTCP転送では、HIPなしの転送は、4.86 Mbpsの生産ました。この目的のための軽量HIP基本交換は、この書き込み[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認証のいずれかが使用されている場合はNULL暗号化設定で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.
ファイアウォールは通常、インターネットの残りの部分から組織のネットワークを分離します。アクセス制御リスト（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が中間装置によって認証されてもよいパケット交換に基づいて保護されることを可能にします。 IPv4のと比較してによるHITの長さ（ただし、ヒットは集約されないので、HITベースのACLは、人間のユーザによって（これは単一のエントリを持つグループホストすることができないために）長さが長くてもよいし、硬いに対処しますまたは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のiptablesの[paper.firewall]に基づいて、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の塩基交換とその後のIPsec ESPデータパケットを一緒にリンクする必要があります。塩基交換の際に、ファイアウォールは、I2及びR2パケットからSPI値を学習します。その後、ファイアウォールは知られている唯一のSPI値とESPパケットを可能にし、塩基交換中と同じIPアドレスから到着します。ホストがその場所と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].
一部の研究者は、セキュリティクリティカルな環境のためのファイアウォールがミドルを注射したエコー要求と塩基交換およびUPDATE手続きに関与し得るべきであることを示唆しています。ファイアウォールは[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は、イニシエータが匿名を好むている場合は匿名（未発表）ヒットの使用のために提供しませんが、Responderは、匿名のピアからのセッションを受け入れることをいとわなければなりません。
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開始剤は、ディフィー・ヘルマンが生成した鍵材料とそのホストIDを暗号化し、I2パケットでそれを送信する前にレスポンダのR1パケットを認証することができます。 R1を受信すると、認証ステップは、レスポンダの活発な攻撃者（偽装）を破り、およびアイデンティティを暗号化する動作は受動的敵を倒します。レスポンダがイニシエータへの最初の応答メッセージ（R1）で暗号化されていないその公開鍵を送信するので、レスポンダのアイデンティティは、サードパーティのパス盗聴者に明らかにされます。 Responderがイニシエータを認証し、R1を送信する前に、アクセス制御を行う場合は、Responderはアクティブ攻撃者にその公開鍵を公開避けることができます。
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 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.
DNSレコードは、ホストのIDと位置情報、ホスト公開鍵を組み合わせた情報を提供し、IPアドレスをホストすることができます。したがって、アイデンティティ及び位置プライバシーが関連しており、統合されたアプローチで処理されなければなりません。 BLINDの目標は、アイデンティティと位置プライバシー[paper.blind] [HIP-プライバシー]のためのフレームワークを提供することです。アイデンティティ保護は、信頼できるホストがキーを認識できるように、第三者から実際の公開鍵を隠すことによって達成されます。場所のプライバシーはNAT変換でトラフィック転送を統合し、ロケータからホストIDを切り離すことによって達成されます。ランダムなIPアドレスとMACアドレスの使用はまた、第三者からのホスト識別子を保護することにフォーカスをシフト位置プライバシーの問題を低減します。このアプローチは、その性質上、ミドル認証と互換性がありません。
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基本交換を使用して能動的および受動的攻撃からの保護を提供します。ホストはリバース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、今アールト）[thesis.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の1つの製造レベルの展開が報告されています。ボーイング社は、それが信頼されていないワイヤレスネットワーク[HIPLS]オーバーレイヤ2つのVPNを構築するためにHIPを使用する方法を説明しています。このユースケースは、HIPの伝統的なエンドホストベースの使用ではなく、それは、オンデマンドプロバイダエッジ（PE）デバイス間のESPトンネルを作成するために、HIP-認識中間装置を使用するものです。
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.ブリューワー、J.牙、T.ヘンダーソン、D.マッテス、J. Meegan、R.ペイン、S. Venema氏、OpenHIP実装、安全なモバイル・アーキテクチャ）
o NomadicLab, Ericsson (P. Jokela, P. Nikander, J. Melen. BSD HIP implementation)
いいえNomadicLabない、エリクソン（P. Jokela、P. Nikander、J.メレ。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)
情報技術（HIIT）（A. Gurtov、M.こむ、A. Pathak、D.ベルトラミ。HIPL、レガシーNATトラバーサル、ファイアウォール、i3は、ネイティブAPI）のためのヘルシンキ研究所O
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)
ヘルシンキ工科大学（TKK、今アールト）（ヤンネLindqvist、ニクラス・カールソン、ローラTakkinen、およびESSI Vehmersalo。HIPのセキュリティとファイアウォール、複数のID、およびプライバシ管理）O
o University of California, Berkeley (A. Joseph, HIP proxy implementation)
O、カリフォルニア大学バークレー校（A.ジョゼフ、HIPプロキシの実装）
o Laboratory of Computer Architecture and Networks, Polytechnic School of University of Sao Paulo, Brazil (T. Carvalho, HIP measurements, Hi3)
Oコンピュータアーキテクチャおよびネットワーク、サンパウロ、ブラジルの大学の工科大学の研究室（T.カルバリョ、HIP測定、HI3）
o Telecom Italia (M. Morelli, comparing existing HIP implementations)
Oテレコムイタリア（M.モレーリ、既存のHIP実装を比較）
o NEC Heidelberg (L. Eggert, M. Esteban, V. Schmitt working on RVS implementation, DNS, NAT traversal)
O NECハイデルベルク（L.エッゲルト、M.エステバン、RVSの実装に取り組んでV.シュミット、DNS、NATトラバーサル）
o University of Hamburg-Harburg (M. Shanmugam, A. Nagarajan, HIP registration protocol)
ハンブルグハールブルクのO大学（M・シャンミューガム、A. Nagarajan、HIP登録プロトコル）
o University of Tuebingen (K. Wehrle, T. Lebenslauf to work on Hi3 or HIP-OpenDHT)
Oチュービンゲン大学（K. Wehrleの、T. LebenslaufはHI3に手を加えたり、HIP-OpenDHTします）
o University of Parma (UNIPR), Department of Information Engineering Parma, Italy. (N. Fedotova, HIP for P2P)
パルマのO大学（UNIPR）、情報工学パルマ、イタリアの部門。 （N. Fedotova、P2PのためのHIP）
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（オールボー大学、ラース・ルースト、グスタフHaraldsson、パートフト、HIP評価プロジェクト、OpenDHT-HIPインタフェース）
o Microsoft Research, Cambridge (T. Aura, HIP analysis)
マイクロソフトリサーチ、ケンブリッジ（T.オーラ、HIP分析）O
o MIT (H. Balakrishnan. Delegation-Oriented Architecture)
MIT O（H.バラクリシュナン。委任指向アーキテクチャ）
o Huawei (D. Zhang, X. Xu, hierarchical HIP architecture, HIP proxy, key revocation)
Huawei社（D.チャン、X.徐、階層HIPアーキテクチャ、HIPプロキシ、鍵無効）O
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].
このセクションでは、簡単に最近のIETFとIRTF活動に特に焦点を当てとID-ロケータ分離に関連する作品をまとめたもの。学術研究コミュニティでは、いくつかの関連の提案は、インターネット間接基盤（I3）として、この研究グループの設立に先立って調査された[paper.i3]、IPNLは[paper.layered]、DataRouter [paper.datarouter]、ネットワークポインタ[paper.netpointers]、ファラ[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はジェロームSaltzer [RFC1498]とニムロッド[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].
IPv6におけるサイトマルチホーミング（multi6）O WGは、マルチホーミングは、現在のIPv4ネットワークに実装された方法を文書化し、高度なマルチホーミングのためのいくつかのアプローチを評価しました。トランスポートプロトコル上のセキュリティの脅威と影響を評価中に覆われていました。作業は、一つの選択手法の仕様に焦点を当てているIPv6の仲介（SHIM6）、[RFC5533]で別のWG、サイトマルチホーミングに続け。 SHIM6はIPと利用可能なアドレスのセットの変動の影響を隠蔽輸送層との間にシム層を挿入する手法を用います。アプリケーションは紹介をサポートしています1つのアクティブなアドレスを使用しています。 SHIM6は、暗号のIPv6アドレスの所有権の問題を解決するためのアドレス生成に依存しています。 HIPとSHIM6は、アーキテクチャに類似しており、制御パケットのための共通のフォーマットを使用します。 HIPの仕様はそのままインタフェースの選択などの重要な問題を残すだけの簡単なマルチホーミングシナリオを定義します。 SHIM6は[REAP4HIP] HIPで再利用できる補完的な機能を提供します。 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].
IRTFのルーティング研究グループ（RRG）は[LISPのように、識別子とロケータのために使用されるものに、既存のIPアドレス空間の分離[LISP]とシックス/ワンルータのいずれかを伴うグローバルルーティングスケーラビリティの問題への解決策のクラスを模索しているO 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.
エンドミドルエンドの研究グループは、[EME】中間装置とエンドポイントの明示的なシグナリングおよびポリシー制御プレーンの可能性を考えOであり; 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アンマネージインターネットプロトコルは、例えば、ノードの公開鍵[thesis.ford]の暗号ハッシュに基づいて一元管理されていない識別子の焦点としてHIPアーキテクチャにいくつかの類似点を負います。
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はどこでも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研究グループが正式に他のID-ロケータ分離アプローチとHIPを比較しようとしていないが、そのような議論は、このようなルーティングの研究グループのメーリングリストなど他のリスト上で発生した、および他のアプローチとHIPの移動性管理ソリューションの比較が掲載されました[MOBILITY-比較]。
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プロトコルの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こむ、ペッカNikander、アリKeranen、そしてジェフAhrenholzはこのドキュメントの以前のドラフトバージョンに有益なコメントを提供してきました。 Miikaこむも日和見モードのセクションを貢献しました。また、階層的なHIPアーキテクチャとの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.メレン、 "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]フランシス、P.、グハ、S.、つば、S.、およびM.ショア、 "EMEシグナリングプロトコル設計"、進歩、2007年4月に作業。
[HIP-DEX] Moskowitz, R., "HIP Diet EXchange (DEX)", Work in Progress, March 2011.
[HIP-DEX]モスコウィッツ、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.こむ、 "HIPのMiddleboxesのエンドホスト認証"、進歩、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]ディーツ、T.、ブルナー、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-プライバシー]チャン、D.とM.こむ、「アイデンティティプライバシーをサポートするためにHIP基本交換の拡張」、進歩、2011年7月での作業。
[HIPLS] Henderson, T., Venema, S., and D. Mattes, "HIP-based Virtual Private LAN Service (HIPLS)", Work in Progress, September 2011.
[HIPLS]ヘンダーソン、T.、Venema氏、S.、およびD.マッテス、 "HIPベースの仮想プライベートLANサービス（HIPLS）"、進歩、2011年9月での作業。
[HIPRG-PROXIES] Zhang, D., Xu, X., Yao, J., and Z. Cao, "Investigation in HIP Proxies", Work in Progress, October 2011.
[HIPRG-プロキシ]張、D.、徐、X.、ヤオ、J.、およびZ.ツァオ、 "HIPプロキシで調査"、進歩、2011年10月ワーク。
[HIT2IP] Ponomarev, O. and A. Gurtov, "Embedding Host Identity Tags Data in DNS", Work in Progress, July 2009.
[HIT2IP]ポノマリョフ、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]ファリナッチ、D.、フラー、V.、マイヤー、D.、およびD.ルイス、 "ロケータ/ ID分離プロトコル（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]スワミ、Y.、ル、K.、およびW.エディ、 "軽量モビリティの検出とTCPの応答（LMDR）アルゴリズム"、進歩、2006年2月に作業。
[MOBILITY-COMPARISON] Thaler, D., "A Comparison of IP Mobility-Related Protocols", Work in Progress, October 2006.
[MOBILITY-比較]ターラー、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トラバーサル] Keranen、A.とJ.メレン、「ネイティブNATトラバーサルモードホストアイデンティティプロトコルのための」進歩、2011年1月で、作業。
[RANGI] Xu, X., "Routing Architecture for the Next Generation Internet (RANGI)", Work in Progress, August 2010.
[ランギ]徐、X.、「次世代インターネット（ランギ）のためのルーティングアーキテクチャ」、進歩、2010年8月での作業。
[REAP4HIP] Oliva, A. and M. Bagnulo, "Fault tolerance configurations for HIP multihoming", Work in Progress, July 2007.
[REAP4HIP]オリバ、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.、Chiappa、N.、およびM. Steenstrup、 "ニムロッドルーティングアーキテクチャ"、RFC 1992、1996年8月。
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
[RFC2367]マクドナルド、D.、メッツ、C.、およびB. Phanさん、 "PF_KEY鍵管理API、バージョン2"、RFC 2367、1998年7月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、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：ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器（NAT）"、RFC 4380、2006年2月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]モスコウィッツ、R.とP. Nikander、 "ホストアイデンティティプロトコル（HIP）アーキテクチャ"、RFC 4423、2006年5月。
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
[RFC4843] Nikander、P.、Laganier、J.、およびF.デュポン、RFC 4843、2007年4月 "オーバーレイルーティング可能な暗号ハッシュ識別子（ORCHID）のIPv6プレフィックス"。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]モスコウィッツ、R.、Nikander、P.、Jokela、P.、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、RFC 5201、2008年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.、モスコウィッツ、R.、およびP. Nikander、RFC 5202、2008年4月 "ホスト識別プロトコル（HIP）とカプセル化セキュリティペイロード（ESP）トランスポートフォーマットを使用します"。
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 5203, April 2008.
[RFC5203] Laganier、J.、Koponen、T.、およびL.エッゲルト、 "ホストアイデンティティプロトコル（HIP）登録拡張"、RFC 5203、2008年4月。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
[RFC5204] Laganier、J.とL.エッゲルト、 "ホストアイデンティティプロトコル（HIP）ランデブー拡張"、RFC 5204、2008年4月。
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", RFC 5205, April 2008.
[RFC5205] Nikander、P.およびJ. Laganier、 "ホストアイデンティティプロトコル（HIP）ドメインネームシステム（DNS）の拡張"、RFC 5205、2008年4月。
[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.、ヘンダーソン、T.、フォークト、C.、およびJ. Arkko、 "ホストアイデンティティプロトコルとエンドホストモビリティとマルチホーミング"、RFC 5206、2008年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] Stiemerling、M.、Quittek、J.、およびL.エッゲルト、 "NATおよびホスト識別プロトコル（HIP）コミュニケーションのファイアウォール越えの問題"、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]ヘンダーソン、T.、Nikander、P.、およびM.こむ、 "レガシーアプリケーションをホストアイデンティティプロトコルを使用する"、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 5533、2009年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]こむ、M.、ヘンダーソン、T.、Tschofenig、H.、メレン、J.、およびA. Keranen、 "基本的なホストアイデンティティプロトコル（HIP）ネットワークのトラバーサルのための拡張が翻訳をアドレス"、RFC 5770、2010年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]パーキンス、C.、エド。、ジョンソン、D.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 6275、2011年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]チェシャー、S.、朱、Z.、Wakikawa、R.、およびL.チャン、RFC 6281、2011年6月、 "どこでもMy Mac（BTMM）サービスにAppleのバックを理解します"。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
[RFC6298]パクソン、V.、オールマン、M.、チュー、J.、およびM.サージェント、 "コンピューティングTCPの再送信タイマー"、RFC 6298、2011年6月。
[RFC6316] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Sockets Application Program Interface (API) for Multihoming Shim", RFC 6316, July 2011.
[RFC6316]こむ、M.、Bagnulo、M.、Slavov、K.、およびS.杉本、 "マルチホーミングシム用ソケットアプリケーション・プログラム・インターフェース（API）"、RFC 6316、2011月。
[RFC6317] Komu, M. and T. Henderson, "Basic Socket Interface Extensions for the Host Identity Protocol (HIP)", RFC 6317, July 2011.
[RFC6317]こむ、M.とT.ヘンダーソン、RFC 6317 "ホスト識別プロトコル（HIP）のための基本的なソケットインタフェース拡張"、2011年7月。
[RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash Table Interface", RFC 6537, February 2012.
[RFC6537] Ahrenholz、J.、2012年2月、RFC 6537 "ホスト識別プロトコルは、ハッシュテーブルインタフェースを分散しました"。
[SIX-ONE] Vogt, C., "Six/One: A Solution for Routing and Addressing in IPv6", Work in Progress, October 2009.
[SIX-ONE]フォークト、C.、 "/ワン6：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.、エッゲルト、L.、エディ、W.、スワミ、Y.、およびK.ル、 "下層接続-変更効能にTCP応答"、仕事で進歩、2008年2月。
[TRIGTRAN] Dawkins, S., Williams, C., and A. Yegin, "Framework and Requirements for TRIGTRAN", Work in Progress, February 2003.
[TRIGTRAN]ドーキンス、S.、ウィリアムズ、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、ワイリー・アンド・サンズ、（ハードカバー、P 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。セキュリティProtocのOLSの十二国際ワークショップ、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.
[paper.datarouter]タッチ、J.およびV. Pingali、「DataRouter：アプリケーションレイヤ転送のためのネットワーク層サービス」、アクティブネットワークに関する国際ワークショップ（イワン）、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]クラーク、D.、ブレーデン、R.、フォーク、A.、およびV. Pingali、 "ファラ：アドレッシングアーキテクチャの再編成" を、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.、こむ、M.、およびJ.のようにして、 "モバイル暗号アイデンティティエンタープライズネットワークパケットフィルタリング"、ハンドヘルドコンピューティング研究の国際ジャーナル（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.
[paper.handovers] Varjonen、S.、こむ、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/ comcom_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.
【paper.hipanalysis]オーラ、T.、Nagarajan、A.、およびA. Gurtov、PROC "HIP基本交換プロトコルの分析"。情報セキュリティとプライバシー（ACISP）、2005年7月10日にオーストラリアの会議。
[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]ストイカ、I.、アドキンス、D.、荘、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.
【paper.layered】バラクリシュナン、H.、Lakshminarayanan、K.、Ratnasamy、S.、Shenker、S.、ストイカ、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.
[paper.leap-の-信仰]こむ、M.とJ. Lindqvistは、消費者コミュニケーションとネットワーキング会議第6回IEEE会議（CCNC 09）の議事録、2009年「リープ・オブ・信仰のセキュリティは、IPモビリティのために十分です」 。
[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.
【paper.namespace]こむ、M.、Tarkoma、S.、Kangasharju、J.、およびA. Gurtov、 "アプリケーションへの暗号化名前空間を適用する"、PROC。ネットワークの動的な相互接続、2005年9月に第一回国際ACMワークショップの。
[paper.netpointers] Tschudin, C. and R. Gold, "Network pointers", ACM SIGCOMM Computer Communications Review, Vol. 33, Issue 1, January 2003.
[paper.netpointers] Tschudin、C.とR.ゴールド、 "ネットワークのポインタ"、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、ACMモバイルコンピュータコミュニケーションレビュー "スパム防止とのセキュアなP2PのSIPシステム"、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>.
[paper.triad] Cheriton、D.とM.グリッター、 "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.
[paper.usable-セキュリティ] Karvone、K.、こむ、M.、およびA. Gurtov、 "ホスト識別プロトコルで使用可能なセキュリティ管理"、PROC。コンピュータシステムおよびアプリケーション上のIEEE / ACS国際会議、2009年5月の。
[thesis.bishaj] Bishaj, B., "Efficient Leap of Faith Security with Host Identity Protocol", Master thesis, Helsinki University of Technology, June 2008.
[thesis.bishaj] Bishaj、B.、「ホストアイデンティティプロトコルと信仰セキュリティの効率的なリープ」、修士論文、技術、2008年6月のヘルシンキ大学。
[thesis.ford] Ford, B., "UIA: A Global Connectivity Architecture for Mobile Personal Devices", Doctoral thesis, Massachusetts Institute of Technology, September 2008.
[thesis.ford]フォード、B.、「UIA：モバイルパーソナルデバイスのグローバルな接続アーキテクチャ」、博士論文、技術、2008年9月のマサチューセッツ工科大学。
[thesis.karlsson] Karlsson, N., "Enabling Multiple Host Identities on Linux", Master thesis, Helsinki University of Technology, September 2005.
[thesis.karlsson]カールソン、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>.
[thesis.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シアトル、WA USA
EMail: thomas.r.henderson@boeing.com
メールアドレス：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
無線通信CWCの私書箱のためのオウルセンターのアンドレイGurtov大学オウル、フィンランドのボックス4500 FI-90014大学
EMail: gurtov@ee.oulu.fi
メールアドレス：gurtov@ee.oulu.fi