Internet Engineering Task Force (IETF) G. Camarillo
Request for Comments: 6079 P. Nikander
Category: Experimental J. Hautakorpi
ISSN: 2070-1721 A. Keranen
Ericsson
A. Johnston
Avaya
January 2011
HIP BONE: Host Identity Protocol (HIP)
Based Overlay Networking Environment (BONE)
Abstract
抽象
This document specifies a framework to build HIP-based (Host Identity Protocol) overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as "peer protocols".
この文書では、HIPベース（ホスト識別プロトコル）オーバーレイネットワークを構築するためのフレームワークを指定します。このフレームワークは、接続管理を実行するためにHIPを使用しています。このようなデータ記憶検索またはオーバーレイメンテナンスなどの他の機能は、HIP以外のプロトコルを使用して実装されています。これらのプロトコルは、大まかに「ピア・プロトコル」と呼ばれています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6079.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6079で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Background on HIP ...............................................4
3.1. ID/Locator Split ...........................................4
3.1.1. Identifier Format ...................................5
3.1.2. HIP Base Exchange ...................................5
3.1.3. Locator Management ..................................6
3.2. NAT Traversal ..............................................6
3.3. Security ...................................................7
3.3.1. DoS Protection ......................................7
3.3.2. Identifier Assignment and Authentication ............7
3.3.3. Connection Security .................................9
3.4. HIP Deployability and Legacy Applications ..................9
4. Framework Overview .............................................10
5. The HIP BONE Framework .........................................13
5.1. Node ID Assignment and Bootstrap ..........................13
5.2. Overlay Network Identification ............................14
5.3. Connection Establishment ..................................15
5.4. Lightweight Message Exchanges .............................15
5.5. HIP BONE Instantiation ....................................16
6. Overlay HIP Parameters .........................................17
6.1. Overlay Identifier ........................................17
6.2. Overlay TTL ...............................................17
7. Security Considerations ........................................18
8. Acknowledgements ...............................................19
9. IANA Considerations ............................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................20
The Host Identity Protocol (HIP) [RFC5201] defines a new name space between the network and transport layers. HIP provides upper layers with mobility, multihoming, NAT (Network Address Translation) traversal, and security functionality. HIP implements the so-called identifier/locator (ID/locator) split, which implies that IP addresses are only used as locators, not as host identifiers. This split makes HIP a suitable protocol to build overlay networks that implement identifier-based overlay routing over IP networks, which in turn implement locator-based routing.
ホストアイデンティティプロトコル（HIP）[RFC5201]は、ネットワーク層とトランスポート層の間に新しい名前空間を定義します。 HIPは、モビリティ、マルチホーミング、NAT（ネットワークアドレス変換）トラバーサル、およびセキュリティ機能を備えた上位レイヤを提供します。 HIPは、IPアドレスのみロケータとしてではなく、ホスト識別子として使用されていることを意味し、いわゆる識別子/ロケータ（ID /ロケータ）スプリットを実装します。この分割はHIP順番にロケータベースのルーティングを実装し、IPネットワーク上でのルーティング識別子ベースのオーバーレイを、実装するオーバーレイネットワークを構築するための適切なプロトコルになります。
Using HIP-Based Overlay Networking Environment (HIP BONE), as opposed to a peer protocol, to perform connection management in an overlay has a set of advantages. HIP BONE can be used by any peer protocol. This keeps each peer protocol from defining primitives needed for connection management (e.g., primitives to establish connections and to tunnel messages through the overlay) and NAT traversal. Having this functionality at a lower layer allows multiple upper-layer protocols to take advantage of it.
HIPベースのオーバレイネットワーク環境（寛骨）を使用して、ピア・プロトコルとは対照的に、オーバーレイの接続管理を行う利点のセットを有します。股関節の骨は、任意のピアプロトコルによって使用することができます。これは、接続管理（例えば、プリミティブがオーバレイを介して接続を確立し、トンネルメッセージへ）とNATトラバーサルのために必要なプリミティブを定義から各ピアプロトコルを維持します。下層にこの機能を有する複数の上位層プロトコルがそれを利用することを可能にします。
Additionally, having a solution that integrates mobility and multihoming is useful in many scenarios. Peer protocols do not typically specify mobility and multihoming solutions. Combining a peer protocol including NAT traversal with a separate mobility mechanism and a separate multihoming mechanism can easily lead to unexpected (and unpleasant) interactions.
また、移動性とマルチホーミングを統合したソリューションを持つことは、多くのシナリオで有用です。ピアプロトコルは、通常、移動性とマルチホーミングソリューションを指定しないでください。別モビリティ機構を備えたNATトラバーサルと別個マルチホーミング機構を備えたピア・プロトコルを組み合わせることにより、容易に予想外（不快な）相互作用をもたらすことができます。
The remainder of this document is organized as follows. Section 3 provides background information on HIP. Section 4 gives an overview of the HIP BONE (HIP-Based Overlay Networking Environment) framework and architecture and Section 5 describes the framework in more detail. Finally, Section 6 introduces new HIP parameters for overlay usage.
このドキュメントの残りは以下の通り構成されています。第3節ではHIPの背景情報を提供します。セクション4は、フレームワークとアーキテクチャとセクション5をより詳細にフレームワークを記述する腰骨（HIPベースのオーバレイネットワーク環境）の概要を示します。最後に、第6節では、オーバーレイの使用のための新しいHIPパラメータを導入しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The following terms are used in context of HIP BONEs:
次の用語はHIPの骨のコンテキストで使用されています。
Overlay network: A network built on top of another network. In case of HIP BONEs, the underlying network is an IP network and the overlay can be, e.g., a peer-to-peer (P2P) network.
オーバーレイネットワーク：別のネットワークの上に構築されたネットワーク。 HIP骨の場合には、基本的なネットワークは、IPネットワークであり、オーバーレイは、例えば、ピア・ツー・ピア（P2P）ネットワークとすることができます。
Peer protocol: A protocol used by nodes in an overlay network for performing, e.g., data storage and retrieval or overlay maintenance.
ピアプロトコル：例えば、データ記憶および検索またはオーバーレイメンテナンスを行うためのオーバレイネットワーク内のノードによって使用されるプロトコル。
HIP BONE instance: A HIP-based overlay network that uses a particular peer protocol and is based on the framework presented in this document.
HIP BONEインスタンス：特定のピア・プロトコルを使用し、この文書のフレームワークに基づいているHIPベースのオーバレイネットワーク。
Node ID: A value that uniquely identifies a node in an overlay network. The value is not usually human-friendly. As an example, it may be a hash of a public key.
ノードID：一意オーバレイネットワーク内のノードを識別する値。値は、通常、人間に優しいではありません。一例として、公開鍵のハッシュかもしれません。
HIP association: An IP-layer communications context created using the Host Identity Protocol.
HIP協会：ホストアイデンティティプロトコルを使用して作成したIPレイヤの通信状況。
Valid locator: A locator (as defined in [RFC5206]; usually an IP address or an address and a port number) at which a host is known to be reachable, for example, because there is an active HIP association with the host.
有効なロケータ：（[RFC5206]で定義されるように、通常のIPアドレスまたはアドレス及びポート番号）ロケータホストとのアクティブHIPアソシエーションが存在するため、ホストは、例えば、到達可能であることが知られてれます。
Final recipient: A node is the final recipient of a HIP signaling packet if one of its Host Identity Tags (HITs) matches to the receiver's HIT in the HIP packet header.
最終受信者は：そのホストアイデンティティタグ（ヒット）の一つはHIPパケットヘッダ内の受信機のヒットに一致する場合、ノードは、HIPシグナリングパケットの最終的な受信者です。
This section provides background on HIP. Given the tutorial nature of this section, readers that are familiar with what HIP provides and how HIP works may want to skip it. All descriptions contain references to the relevant HIP specifications where readers can find detailed explanations on the different topics discussed in this section.
このセクションでは、HIPの背景を提供します。このセクションで、提供し、HIPの作品はそれをスキップすることができますどのようにどのようなHIPに精通している読者のチュートリアル性質を考えます。すべての記述は、読者がこのセクションで説明するさまざまなトピックについての詳細な説明を見つけることができ、関連するHIP仕様への参照が含まれています。
In an IP network, IP addresses typically serve two roles: they are used as host identifiers and as host locators. IP addresses are locators because a given host's IP address indicates where in the network that host is located. IP networks route based on these locators. Additionally, IP addresses are used to identify remote hosts. The simultaneous use of IP addresses as host identifiers and locators makes mobility and multihoming complicated. For example, when a host opens a TCP connection, the host identifies the remote end of the connection by the remote IP address (plus port). If the remote host changes its IP address, the TCP connection will not survive, since the transport layer identifier of the remote end of the connection has changed.
IPネットワークでは、IPアドレスは、典型的には2つの役割を果たします。彼らは、ホスト識別子として、ホストロケータとして使用されています。指定したホストのIPアドレスがどこのホストが配置されているネットワークに示しますので、IPアドレスがロケータです。これらのロケータに基づいてIPネットワークルート。また、IPアドレスは、リモートホストを識別するために使用されています。ホスト識別子やロケータなどのIPアドレスの同時使用は、移動性とマルチホーミングが複雑になります。例えば、ホストは、TCP接続をオープンするとき、ホストはリモートIPアドレス（およびポート）によって接続の遠隔端を識別する。リモートホストがそのIPアドレスを変更した場合、TCP接続は、接続のリモートエンドのトランスポート層識別子が変更されたことから、生き残れないだろう。
Mobility solutions such as Mobile IP keep the remote IP address from changing so that it can still be used as an identifier. HIP, on the other hand, uses IP addresses only as locators and defines a new identifier space. This approach is referred to as the ID/locator split and makes the implementation of mobility and multihoming more natural. In the previous example, the TCP connection would be bound to the remote host's identifier, which would not change when the remote hosts moves to a new IP address (i.e., to a new locator). The TCP connection is able to survive locator changes because the remote host's identifier does not change.
こうしたモバイルIPなどのモビリティソリューションは、それはまだ識別子として使用することができるように変更することからリモートIPアドレスを保持します。 HIPは、他の一方で、唯一のロケータとしてIPアドレスを使用して、新しい識別子空間を定義します。このアプローチは、ID /ロケータ分離と呼ばれ、移動性とマルチホーミングの実装がより自然になります。前の例では、TCP接続がリモートホスト（すなわち、新しいロケータに）新しいIPアドレスに移動したときに変化しないリモートホストの識別子、に結合されるであろう。 TCP接続はリモートホストの識別子が変化しないため、ロケータの変更を存続することができます。
HIP uses 128-bit ORCHIDs (Overlay Routable Cryptographic Hash Identifiers) [RFC4843] as identifiers. ORCHIDs look like IPv6 addresses but cannot collide with regular IPv6 addresses because ORCHID spaces are registered with the IANA. That is, a portion of the IPv6 address space is reserved for ORCHIDs. The ORCHID specification allows the creation of multiple disjoint identifier spaces. Each such space is identified by a separate Context Identifier. The Context Identifier can be either drawn implicitly from the context the ORCHID is used in or carried explicitly in a protocol.
HIPは、識別子として128ビットのラン（オーバーレイルーティング可能な暗号ハッシュ識別子）[RFC4843]を使用します。蘭は、IPv6アドレスのように見えるが、ORCHID空間はIANAに登録されているので、通常のIPv6アドレスと衝突することはできません。これは、IPv6アドレス空間の一部は、蘭のために予約されています。 ORCHID仕様は、複数の互いに素識別子スペースを作成することができます。各そのような空間は、別のコンテキスト識別子によって識別されます。コンテキスト識別子は、いずれかのORCHIDが使用またはプロトコルにおいて明示的に実施される文脈から暗黙的に引き出すことができます。
HIP defines a native socket API [HIP-NATIVE-API] that applications can use to establish and manage connections. Additionally, HIP can also be used through the traditional IPv4 and IPv6 TCP/IP socket APIs. Section 3.4 describes how an application using these traditional APIs can make use of HIP. Figure 1 shows all these APIs between the application and the transport layers.
HIPは、アプリケーションが接続を確立し、管理するために使用できるネイティブのソケットAPI [HIP-NATIVE-API]を定義します。また、HIPはまた、従来のIPv4およびIPv6 TCP / IPソケットAPIを介して使用することができます。 3.4節では、これらの伝統的なAPIを使用するアプリケーションは、HIPを利用することができる方法を説明します。図1は、アプリケーション及び輸送層との間のすべてのこれらのAPIを示しています。
+-----------------------------------------+
| Application |
+----------------+------------------------+
| HIP Native API | Traditional Socket API |
+----------------+------------------------+
| Transport Layer |
+-----------------------------------------+
Figure 1: HIP API
図1：HIPのAPI
Typically, before two HIP hosts exchange upper-layer traffic, they perform a four-way handshake that is referred to as the HIP base exchange. Figure 2 illustrates the HIP base exchange. The initiator sends an I1 packet and receives an R1 packet from the responder. After that, the initiator sends an I2 packet and receives an R2 packet from the responder.
2つのHIPホストが上層トラフィックを交換する前に、典型的には、それらは、HIP基本交換と呼ばれる四方向ハンドシェイクを行います。図2は、HIP基本交換を示します。イニシエータは、I1パケットを送信し、応答者からR1パケットを受信します。その後、イニシエータはI2パケットを送信し、レスポンダからR2パケットを受信します。
Initiator Responder
イニシエータレスポンダ
| I1 |
|-------------------------->|
| R1 |
|<--------------------------|
| I2 |
|-------------------------->|
| R2 |
|<--------------------------|
Figure 2: HIP Base Exchange
図2：HIP基本交換
Of course, the initiator needs the responder's locator (or locators) in order to send its I1 packet. The initiator can obtain locators for the responder in multiple ways. For example, according to the current HIP specifications the initiator can get the locators directly from the DNS [RFC5205] or indirectly by sending packets through a HIP rendezvous server [RFC5204]. However, HIP is an open-ended architecture. The HIP architecture allows the locators to be obtained by any means (e.g., from packets traversing an overlay network or as part of the candidate address collection process in a NAT traversal scenario).
もちろん、イニシエータは、そのI1パケットを送信するために、応答者のロケータ（またはロケータ）が必要です。イニシエータは、複数の方法で応答者のためのロケータを取得することができます。例えば、現在のHIP仕様に従ってイニシエータは、HIPランデブーサーバ[RFC5204]を介してパケットを送信することによって、DNS [RFC5205]または間接から直接ロケータを得ることができます。しかし、HIPは、オープンエンドアーキテクチャです。 HIPアーキテクチャは、ロケータ（例えば、オーバーレイネットワークを通過するパケットから、またはNATトラバーサルシナリオにおける候補アドレス収集処理の一部として）の任意の手段によって得ることができます。
Once a HIP connection between two hosts has been established with a HIP base exchange, the hosts can start exchanging higher-layer traffic. If any of the hosts changes its set of locators, it runs an update exchange [RFC5206], which consists of three messages. If a host is multihomed, it simply provides more than one locator in its exchanges. However, if both of the endpoints move at the same time, or through some other reason both lose track of the peers' currently active locators, they need to resort to using a rendezvous server or getting new peer locators by some other means.
2つのホスト間のHIP接続はHIP基本交換で確立された後、ホストは、上位レイヤトラフィックの交換を開始することができます。ホストのいずれかが、ロケータのセットを変更する場合、それは3つのメッセージから構成更新交換[RFC5206]を実行します。ホストがマルチホームである場合、それは単にその交換に複数のロケータを提供します。エンドポイントの両方が同時に移動し、あるいは他の何らかの理由によって両方がピアの現在アクティブなロケータのトラックを失う場合は、彼らがランデブーサーバを使用して、またはいくつかの他の手段によって新しいピアロケータを得るに頼る必要があります。
HIP's NAT traversal mechanism [RFC5770] is based on ICE (Interactive Connectivity Establishment) [RFC5245]. Hosts gather address candidates and, as part of the HIP base exchange, hosts perform an ICE offer/answer exchange where they exchange their respective address candidates. Hosts perform end-to-end STUN-based [RFC5389] connectivity checks in order to discover which address candidate pairs yield connectivity.
[RFC5770] HIPのNATトラバーサル機構はICEに基づいています（インタラクティブ接続性の確立）[RFC5245]。ホストはHIP基本交換の一部として、ホストは、彼らがそれぞれのアドレス候補を交換ICEのオファー/アンサー交換を行い、アドレス候補を収集し。ホストは、ペアが接続を得ているアドレスの候補を発見するために、エンド・ツー・エンドのSTUNベース[RFC5389]の接続性チェックを実行します。
Even though, architecturally, HIP lies below the transport layer (i.e., HIP packets are carried directly in IP packets), in the presence of NATs, HIP sometimes needs to be tunneled in a transport protocol (i.e., HIP packets are carried by a transport protocol such as UDP).
にもかかわらず、アーキテクチャ、HIPは、トランスポート層の下にある（すなわち、HIPパケットがIPパケットで直接実行される）、NATの存在下で、HIPは時々トランスポートプロトコルでトンネリングされる必要がある（すなわち、HIPパケットが輸送によって運ばれますUDPなどのプロトコル）。
Security is an essential part of HIP. The following sections describe the security-related functionality provided by HIP.
セキュリティは、HIPの重要な部分です。次のセクションでは、HIPによって提供されるセキュリティ関連の機能について説明します。
HIP provides protection against DoS (denial-of-service) attacks by having initiators resolve a cryptographic puzzle before the responder stores any state. On receiving an I1 packet, a responder sends a pre-generated R1 packet that contains a cryptographic puzzle and deletes all the state associated with the processing of this I1 packet. The initiator needs to resolve the puzzle in the R1 packet in order to generate an I2 packet. The difficulty of the puzzle can be adjusted so that, if a receiver is under a DoS attack, it can increase the difficulty of its puzzles.
HIPは、イニシエータは、レスポンダの店の前にどのような状態を暗号パズルを解決したことにより、DoS攻撃（サービス拒否）攻撃に対する保護を提供します。 I1パケットを受信すると、応答は、暗号パズルを含み、このI1パケットの処理に関連するすべての状態を削除する事前生成R1パケットを送信します。イニシエータは、I2パケットを生成するために、R1パケット内のパズルを解決する必要があります。受信機は、DoS攻撃下にある場合、それはそのパズルの難易度を増加させることができ、そのようなパズルの難易度を調整することができます。
On receiving an I2 packet, a receiver checks that the solution in the packet corresponds to a puzzle generated by the receiver and that the solution is correct. If it is, the receiver processes the I2 packet. Otherwise, it silently discards it.
I2パケットを受信すると、受信機は、パケット内の溶液は、受信機によって、溶液が正しいこと生成パズルに対応していることをチェックします。もしそうであれば、受信機は、I2パケットを処理します。そうでなければ、それは黙ってそれを破棄します。
In an overlay scenario, there are multiple ways in which this mechanism can be utilized within the overlay. One possibility is to cache the pre-generated R1 packets within the overlay and let the overlay directly respond with R1s to I1s. In that way, the responder is not bothered at all until the initiator sends an I2 packet, with the puzzle solution. Furthermore, a more sophisticated overlay could verify that an I2 packet has a correctly solved puzzle before forwarding the packet to the responder.
オーバーレイシナリオでは、この機構は、オーバーレイ内で利用することができる複数の方法があります。一つの可能性は、オーバーレイ内で事前に生成されたR1パケットをキャッシュし、オーバーレイが直接I1sへのR1で応答させることです。イニシエータは、パズルの溶液で、I2パケットを送信するまで、そのようにして、応答は全く気にされていません。さらに、より洗練されたオーバーレイはI2パケットがレスポンダにパケットを転送する前に、正しく解決パズルを持っていることを確認できました。
As discussed earlier, HIP uses ORCHIDs [RFC4843] as the main representation for identifiers. Potentially, HIP can use different types of ORCHIDs as long as the probability of finding collisions (i.e., two nodes with the same ORCHID) is low enough. One way to completely avoid this type of collision is to have a central authority generate and assign ORCHIDs to nodes. To secure the binding between ORCHIDs and any higher-layer identifiers, every time the central authority assigns an ORCHID to a node, it also generates and signs a certificate stating who is the owner of the ORCHID. The owner of the ORCHID then includes the corresponding certificate in its R1 (when acting as responder) and I2 packets (when acting initiator) to prove that it is actually allowed to use the ORCHID and, implicitly, the associated public key.
前述したように、HIPは、識別子のための主要な表現として蘭[RFC4843]を使用します。潜在的に、HIPは、異なるランの種類限り（すなわち、同じORCHIDを持つ2つのノードが）十分に低い衝突を発見する確率を使用することができます。完全に衝突のこのタイプを回避する1つの方法は、中央の権威が発生しており、ノードに蘭を割り当てることです。蘭と任意上位層識別子との間の結合を確保するために、中央の権威ノードにORCHIDを割り当てるたびに、それはまた、生成しORCHIDの所有者が誰であるかを知らせる証明書に署名します。 （イニシエータ作用時）ORCHIDの所有者は、実際ORCHIDと、暗黙的に、関連する公開鍵を使用することが許可されていることを証明するために、対応するそのR1（レスポンダとして機能する）内の証明書とI2パケットを含みます。
Having a central authority works well to completely avoid collisions. However, having a central authority is impractical in some scenarios. As defined today, HIP systems generally use a self-certifying ORCHID type called HIT (Host Identity Tag) that does not require a central authority (but still allows one to be used).
中央の権限を持つことは、完全に衝突を回避するために適しています。しかし、中央の権限を持つことは、いくつかのシナリオでは非現実的です。今日定義されているように、HIPシステムは、一般的に中央の権限を必要としないHIT（ホストアイデンティティタグ）と呼ばれる自己証明ORCHIDタイプを使用します（まだ1を使用することができます）。
A HIT is the hash of a node's public key. A node proves that it has the right to use a HIT by showing its ability to sign data with its associated private key. This scheme is secure due to the so-called second-preimage resistance property of hash functions. That is, given a fixed public key K1, finding a different public key K2 such that hash(K1) = hash(K2) is computationally very hard. Optimally, a preimage attack on the 100-bit hash function used in ORCHIDs will take an order of 2^100 operations to be successful, and can be expected to take in the average 2^99 operations. Given that each operation requires the attacker to generate a new key pair, the attack is fully impractical with current technology and techniques (see [RFC4843]).
HITは、ノードの公開鍵のハッシュです。ノードは、それはそれに対応する秘密鍵を使用してデータに署名する能力を示すことでHITを使用する権利を持っていることを証明しています。このスキームが原因ハッシュ関数のいわゆる二プレイメージ抵抗性に安全です。これは、異なる公開鍵K2ようにハッシュ（K1）=ハッシュ（K2）、計算上非常に困難であるを見つけ、固定された公開鍵K1を与えています。最適には、ランで使用さ100ビットのハッシュ関数に対する原像攻撃が成功するために2 ^ 100の動作の順序を取る、平均2 ^ 99の操作に取ることが期待できます。各操作は、新しい鍵ペアを生成するために、攻撃者が必要であることを考えると、攻撃は現在の技術や技法（[RFC4843]を参照）と完全に非現実的です。
HIP nodes using HITs as ORCHIDs do not typically use certificates during their base exchanges. Instead, they use a leap-of-faith mechanism, similar to the Secure Shell (SSH) protocol [RFC4251], whereby a node somehow authenticates remote nodes the first time they connect to it and, then, remembers their public keys. While user-assisted leap-of-faith mechanism (such as in SSH) can be used to facilitate a human-operated offline path (such as a telephone call), automated leap-of-faith mechanisms can be combined with a reputation management system to create an incentive to behave. However, such considerations go well beyond the current HIP architecture and even beyond this proposal. For the purposes of the present document, we merely want to point out that, architecturally, HIP supports both self-generated opportunistic identifiers and administratively assigned ones.
蘭は、典型的には、その塩基交換の際に証明書を使用していないとして、ヒットを使用してHIPノード。その代わりに、ノードは、何らかの形でリモートノードを認証することにより、彼らは、セキュアシェル（SSH）プロトコル[RFC4251]と同様LEAP-の-信仰機構を使用し、彼らはその後、それに接続して初めて、自分の公開鍵を記憶しています。ユーザ支援（例えばSSHのように）飛躍・オブ・信仰機構（例えば通話のような）人間が操作オフラインのパスを容易にするために使用することができるが、自動化されたLEAP-の-信仰機構は、評判管理システムと組み合わせることができます動作するようにインセンティブを作成します。しかし、そのような配慮は十分に現在のHIPアーキテクチャを超えても、この提案を越えて行きます。本書の目的のために、私たちは単に、アーキテクチャ、HIPは自己生成日和見識別子と管理上割り当てられたものの両方をサポートしていることを指摘したいと思います。
Once two nodes complete a base exchange between them, the traffic they exchange is encrypted and integrity protected. The security mechanism used to protect the traffic is IPsec Encapsulating Security Payload (ESP) [RFC5202]. However, there is ongoing work to specify how to use other protection mechanisms.
2つのノードが、それらの間の塩基交換を完了すると、彼らは交換するトラフィックが暗号化され、整合性が保護されています。トラフィックを保護するために使用されるセキュリティメカニズムは、IPsecカプセル化セキュリティペイロード（ESP）[RFC5202]です。しかし、他の保護メカニズムを使用する方法を指定するための継続的な作業があります。
As discussed earlier, HIP defines a native socket API [HIP-NATIVE-API] that applications can use to establish and manage connections. New applications can implement this API to get full advantage of HIP. However, in most cases, legacy (i.e., non-HIP-aware) applications [RFC5338] can use HIP through the traditional IPv4 and IPv6 socket APIs.
前述したように、HIPは、アプリケーションが接続を確立し、管理するために使用できるネイティブソケットAPI [HIP-NATIVE-API]を定義します。新しいアプリケーションでは、HIPの利点を最大限に得るために、このAPIを実装することができます。しかし、ほとんどの場合、レガシー（すなわち、非HIP対応）アプリケーション[RFC5338]は従来のIPv4とIPv6のソケットAPIを介してHIPを使用することができます。
The idea is that when a legacy IPv6 application tries to obtain a remote host's IP address (e.g., by querying the DNS), the DNS resolver passes the remote host's ORCHID (which was also stored in the DNS) to the legacy application. At the same time, the DNS resolver stores the remote host's IP address internally at the HIP module. Since the ORCHID looks like an IPv6 address, the legacy application treats it as such. It opens a connection (e.g., TCP) using the traditional IPv6 socket API. The HIP module running in the same host as the legacy application intercepts this call somehow (e.g., using an interception library or setting up the host's routing tables so that the HIP module receives the traffic) and runs HIP (on behalf of the legacy application) towards the IP address corresponding to the ORCHID. This mechanism works well in almost all cases. However, applications involving referrals (i.e., passing of IPv6 addresses between applications) present issues, which are discussed in Section 5 below. Additionally, management applications that care about the exact IP address format may not work well with such a straightforward approach.
アイデアは、レガシーのIPv6アプリケーションが（DNSに問い合わせることによって、例えば）リモートホストのIPアドレスを取得しようとすると、DNSリゾルバは、レガシー・アプリケーションに（また、DNSに格納された）リモート・ホストのORCHIDを通過することです。同時に、DNSリゾルバは、HIPモジュールで内部的にリモートホストのIPアドレスを格納します。 ORCHIDは、IPv6アドレスのように見えるので、レガシーアプリケーションは、そのように扱われます。これは、伝統的なIPv6ソケットAPIを使用して接続（例えば、TCP）を開きます。この呼び出し何とか（例えば、HIPモジュールはトラフィックを受信するように、傍受ライブラリを使用したり、ホストのルーティングテーブルを設定する）と（レガシーアプリケーションの代わりに）HIPを実行し、レガシーアプリケーションのインターセプトと同じホストで実行中のHIPモジュールORCHIDに対応するIPアドレスに向けました。このメカニズムは、ほぼすべての場合に適しています。しかし、照会（すなわち、のIPv6の通過は、アプリケーション間でアドレス）以下のセクション5に記載されている現在の問題を伴うアプリケーション。また、正確なIPアドレス形式を気に管理アプリケーションは、このような簡単な方法でうまく動作しない場合があります。
In order to make HIP work through the traditional IPv4 socket API, the HIP module passes an LSI (Local Scope Identifier), instead of a regular IPv4 address, to the legacy IPv4 application. The LSI looks like an IPv4 address, but is locally bound to an ORCHID. That is, when the legacy application uses the LSI in a socket call, the HIP module intercepts it and replaces the LSI with its corresponding ORCHID. Therefore, LSIs always have local scope. They do not have any meaning outside the host running the application. The ORCHID is used on the wire; not the LSI. In the referral case, if it is not possible to rewrite the application level packets to use ORCHIDs instead of LSIs, it may be hard to make IPv4 referrals work in Internet-wide settings. IPv4 LSIs have been successfully used in existing HIP deployments within a single corporate network.
従来のIPv4ソケットAPIを介してHIPを動作させるために、HIPモジュールは、レガシーのIPv4アプリケーションに、代わりに正規のIPv4アドレスで、LSI（ローカルスコープ識別子）を通過します。 LSIは、IPv4アドレスのように見えますが、ローカルにORCHIDにバインドされています。これは、レガシーアプリケーションが、ソケット呼び出しでHIPモジュールのインターセプトをLSIを使用し、それに対応するORCHIDでLSIに置き換わるとき、です。そのため、LSIが常にローカルスコープを持っています。彼らは、アプリケーションを実行するホストの外にどんな意味を持っていません。 ORCHIDは、ワイヤ上で使用されています。ないLSI。それは代わりに、LSIの蘭を使用するようにアプリケーション・レベルのパケットを書き換えることが可能でない場合は、紹介の場合、IPv4の紹介は、インターネット全体の設定で動作させるのは難しいかもしれません。 IPv4のLSIが成功し、単一の企業ネットワーク内の既存HIPの展開で使用されています。
The HIP BONE framework combines HIP with different peer protocols to provide robust and secure overlay network solutions.
HIP骨フレームワークは、堅牢でセキュアなオーバーレイネットワークソリューションを提供するために、異なるピアプロトコルでHIPを組み合わせました。
Many overlays typically require three types of operations:
多くのオーバーレイは、通常の3種類の操作が必要です。
o overlay maintenance, o data storage and retrieval, and o connection management.
Oオーバーレイメンテナンス、データの記憶および検索、およびo接続管理O。
Overlay maintenance operations deal with nodes joining and leaving the overlay and with the maintenance of the overlay's routing tables. Data storage and retrieval operations deal with nodes storing, retrieving, and removing information in or from the overlay. Connection management operations deal with the establishment of connections and the exchange of lightweight messages among the nodes of the overlay, potentially in the presence of NATs.
オーバーレイメンテナンス操作は、ノードが参加し、オーバーレイを離れるとし、オーバーレイのルーティングテーブルのメンテナンスを扱います。データ記憶および検索操作がノードは、格納、検索、およびオーバーレイまたはから情報を除去することを扱います。接続の管理操作は、潜在的にNATの存在下で、接続の確立とオーバーレイのノード間の軽量メッセージの交換を扱います。
The HIP BONE framework uses HIP to perform connection management. Data storage and retrieval and overlay maintenance are to be implemented using protocols other than HIP. For lack of a better name, these protocols are referred to as peer protocols.
HIPのBONEフレームワークは、接続管理を実行するためにHIPを使用しています。データ記憶検索とオーバーレイメンテナンスはHIP以外のプロトコルを使用して実装されます。より良い名前の不足のために、これらのプロトコルは、ピア・プロトコルと呼ばれています。
One way to depict the relationship between the peer protocol and HIP modules is shown in Figure 3. The peer protocol module implements the overlay construction and maintenance features, and possibly storage (if the particular protocol supports such a feature). The HIP module consults the peer protocol's overlay topology part to make routing decisions, and the peer protocol uses HIP for connection management and sending peer protocol messages to other hosts. The HIP BONE API that applications use is a combination of the HIP Native API and traditional socket API (as shown in Figure 1) with any additional API a particular instance implementation provides.
ピアプロトコルとHIPモジュールとの間の関係を描写する一つの方法は、（特定のプロトコルは、このような機能をサポートしている場合）、ピア・プロトコル・モジュールは、オーバレイ構築および保守機能、およびおそらくストレージを実現する図3に示されています。 HIPモジュールは、ルーティング決定を行うために、ピアプロトコルのオーバーレイ・トポロジの一部を参照し、ピア・プロトコルは、接続管理と他のホストにピアプロトコルメッセージを送信するためのHIPを使用しています。アプリケーションが使用HIP骨APIは、特定のインスタンスの実装を提供する任意の追加のAPIとHIP（図1に示すように）ネイティブAPIと従来のソケットAPIの組み合わせです。
Application
-------------------------------- HIP BONE API
+---+ +--------------------+
| | | Peer Protocol |
| | +--------+ +---------+
| |<->|Topology| |(Storage)|
| | +---------+----------+
| | ^
| | v
| +------------------------+
| HIP |
+----------------------------+
Figure 3: HIP with Peer Protocol
図3：ピア・プロトコルとHIP
Architecturally, HIP can be considered to create a new thin "waist" layer on top of the IPv4 and IPv6 networks; see Figure 4. The HIP layer itself consists of the HIP signaling protocol and one or more data transport protocols; see Figure 5. The HIP signaling packets and the data transport packets can take different routes. In the HIP BONE scenarios, the HIP signaling packets are typically first routed through the overlay and then directly (if possible), while the data transport packets are typically routed only directly between the endpoints.
アーキテクチャ的には、HIPは、IPv4ネットワークとIPv6ネットワークの上に新しい薄い「腰」レイヤーを作成することが考えられます。それ自体がHIPシグナリングプロトコルおよび1つまたは複数のデータ・トランスポート・プロトコルから成るHIP層4図参照。パケットシグナリング図5にHIPを参照し、データ・トランスポート・パケットは、異なる経路を取ることができます。データ・トランスポート・パケットは、典型的には、エンドポイントとの間の唯一の直接ルーティングされつつ寛骨シナリオでは、HIPシグナリングパケットは、典型的には、まず、（可能な場合）を直接、次いでオーバーレイを介してルーティングされています。
+--------------------------------------+
| Transport (using HITs or LSIs) |
+--------------------------------------+
| HIP |
+------------------+-------------------+
| IPv4 | IPv6 |
+------------------+-------------------+
Figure 4: HIP as a Thin Waist
図4：細い腰としてHIP
+------------------+-------------------+
| HIP signaling | data transports |
+------------------+-------------------+
Figure 5: HIP Layer Structure
図5：HIP層構造
In HIP BONE, the peer protocol creates a new signaling layer on top of HIP. It is used to set up forwarding paths for HIP signaling messages. This is a similar relationship that an IP routing protocol, such as OSPF, has to the IP protocol itself. In the HIP BONE case, the peer protocol plays a role similar to OSPF, and HIP plays a role similar to IP. The ORCHIDs (or, in general, Node IDs if the ORCHID prefix is not used) are used for forwarding HIP packets according to the information in the routing tables. The peer protocols are used to exchange routing information based on Node IDs and to construct the routing tables.
寛骨において、ピア・プロトコルは、HIPの上に新たなシグナリングレイヤを作成します。 HIPシグナリングメッセージの転送パスを設定するために使用されています。これは、OSPFなどのIPルーティングプロトコルは、IPプロトコル自体に有することが同様の関係です。股関節の骨の場合には、ピア・プロトコルはOSPFと同様の役割を果たし、HIPはIPと同様の役割を果たしています。蘭（又は、一般的には、ノードのIDランプレフィックスが使用されていない場合）は、ルーティングテーブル内の情報に従ってHIPパケットを転送するために使用されます。ピアプロトコルは、ノードIDに基づいてルーティング情報を交換し、ルーティングテーブルを構築するために使用されます。
Architecturally, routing tables are located between the peer protocol and HIP, as shown in Figure 6. The peer protocol constructs the routing table and keeps it updated. The HIP layer accesses the routing table in order to make routing decisions. The bootstrap of a HIP BONE overlay does not create circular dependencies between the peer protocol (which needs to use HIP to establish connections with other nodes) and HIP (which needs the peer protocol to know how to route messages to other nodes) for the same reasons as the bootstrap of an IP network does not create circular dependencies between OSPF and IP. The first connections established by the peer protocol are with nodes whose locators are known. HIP establishes those connections as any connection between two HIP nodes where no overlays are present. That is, there is no need for the overlay to provide a rendezvous service for those connections.
ピアプロトコルは、ルーティングテーブルを構築し、それが更新さを保ち、図6に示すように、アーキテクチャ、ルーティングテーブルは、ピア・プロトコルとHIPとの間に配置されています。 HIP層は、ルーティング決定を行うために、ルーティングテーブルにアクセスします。 HIP骨オーバーレイのブートストラップは、同一のため（他のノードにどのようにルーティングメッセージを知っているピアプロトコルが必要）とHIP（他のノードとの接続を確立するためにHIPを使用する必要がある）ピア・プロトコルの間に円形の依存関係を作成しませんIPネットワークのブートストラップなどの理由は、OSPFとIP間の循環依存関係を作成しません。ピア・プロトコルによって確立された最初の接続は、そのロケータが知られているノードです。 HIPにはオーバーレイが存在しない2つのHIPノード間の任意の接続などのそれらの接続を確立します。それは、これらの接続のためのランデブーサービスを提供するために、オーバーレイの必要がない、です。
+--------------------------------------+
| Peer protocol |
+--------------------------------------+
| Routing table |
+--------------------------------------+
| HIP |
+--------------------------------------+
Figure 6: Routing Tables
図6：ルーティングテーブル
It is possible that different overlays use different routing table formats. For example, the structure of the routing tables of two overlays based on different DHTs (Distributed Hash Tables) may be very different. In order to make routing decisions, the HIP layer needs to convert the routing table generated by the peer protocol into a forwarding table that allows the HIP layer select a next hop for any packet being routed.
別のオーバーレイが異なるルーティングテーブルのフォーマットを使用することも可能です。例えば、別のDHT（分散ハッシュテーブル）に基づいて、2つのオーバーレイルーティングテーブルの構造は非常に異なっていてもよいです。ルーティングの決定を行うために、HIP層がHIP層がルーティングされる任意のパケットの次のホップを選択可能にする転送テーブルにピアプロトコルによって生成されたルーティングテーブルを変換する必要があります。
In HIP BONE, the HIP usage of public keys and deriving ORCHIDs through a hash function can be utilized at the peer protocol side to better secure routing table maintenance and to protect against chosen-peer-ID attacks.
HIP骨において、ハッシュ関数を介して公開鍵と導出蘭のHIPの使用は、より良好な安全なルーティングテーブル更新にピアプロトコル側で利用することができ、選択されたピア-ID攻撃から保護します。
HIP BONE provides quite a lot of flexibility with regards to how to arrange the different protocols in detail. Figure 7 shows one potential stack structure.
股関節の骨を詳細に異なるプロトコルを手配する方法に関して柔軟性のかなり多くを提供します。図7は、一つの潜在的積層構造を示しています。
+-----------------------+--------------+
| peer protocols | media |
+------------------+----+--------------+
| HIP signaling | data transport |
| |
+------------------+-------------------+
| NAT | non-NAT | |
| | |
| IPv4 | IPv6 |
+------------------+-------------------+
Figure 7: Example HIP BONE Stack Structure
図7：例HIP BONEスタック構造
HIP BONE is a generic framework that allows the use of different peer protocols. A particular HIP BONE instance uses a particular peer protocol. The details on how to implement HIP BONE using a given peer protocol need to be specified in a, so-called, HIP BONE instance specification. Section 5.5 discusses what details need to be specified by HIP BONE instance specifications. For example, the HIP BONE instance specification for RELOAD [P2PSIP-BASE] is specified in [HIP-RELOAD-INSTANCE].
HIP BONEは異なるピア・プロトコルの使用を可能にする一般的なフレームワークです。特定の腰骨のインスタンスは、特定のピア・プロトコルを使用します。所与のピアプロトコルを使用して股関節の骨を実装する方法の詳細は、いわゆるHIP BONEインスタンス仕様で指定する必要があります。 5.5節では詳細は股関節の骨のインスタンス仕様で指定する必要があるかについて説明します。例えば、リロード[P2PSIP-BASE]のためのHIP骨インスタンス仕様は[HIPリロードインスタンス]で指定されています。
Nodes in an overlay are primarily identified by their Node IDs. Overlays typically have an enrollment server that can generate Node IDs, or at least some part of the Node ID, and sign certificates. A certificate generated by an enrollment server authorizes a particular user to use a particular Node ID in a particular overlay. The way users are identified is defined by the peer protocol and HIP BONE instance specification.
オーバーレイ内のノードは、主に自分のノードIDで識別されます。オーバーレイは通常、登録ノードIDを生成することができ、サーバー、またはノードIDの少なくとも一部を持っている、と証明書に署名します。登録サーバによって生成された証明書は、特定のオーバーレイ内の特定のノードIDを使用するように特定のユーザを許可します。ユーザが識別される方法は、ピアプロトコルと寛骨インスタンス仕様で定義されています。
The enrollment server of an overlay using HITs derived from public keys as Node IDs could just authorize users to use the public keys and HITs associated to their nodes. Such a Node ID has the same self-certifying property as HITs and the Node ID can also be used in the HIP and legacy APIs as an ORCHID. This works well as long as the enrollment server is the one generating the public/private key pairs for all those nodes. If the enrollment server authorizes users to use HITs that are generated directly by the nodes themselves, the system is open to a type of chosen-peer-ID attack.
ノードのIDとして公開鍵から派生ヒットを使用してオーバーレイの登録サーバは、ちょうど彼らのノードに関連する公開鍵とヒットを使用するユーザーを認可できます。そのようなノードIDがヒットと同じ自己認証性を有し、ノードIDはまたORCHIDとしてHIPおよびレガシーのAPIで使用することができます。これは、限り登録サーバはすべてのそれらのノードの公開鍵/秘密鍵のペアを生成するものですとうまく動作します。登録サーバは、ユーザがノード自体によって直接生成されたヒットを使用することを許可した場合、システムは、選択されたピア-ID攻撃の種類に開放されています。
If the overlay network or peer protocol has more specific requirements for the Node ID value that prevent using HITs derived from public keys, each host will need a certificate (e.g., in their HIP base exchanges) provided by the enrollment server to prove that they are authorized to use a particular identifier in the overlay. Depending on how the certificates are constructed, they typically also need to contain the host's self-generated public key. Depending on how the Node IDs and public keys are attributed, different scenarios become possible. For example, the Node IDs may be attributed to users, there may be user public key identifiers, and there may be separate host public key identifiers. Authorization certificates can be used to bind the different types of identifiers together.
オーバーレイネットワークまたはピアプロトコルは、公開鍵から派生ヒットを使用して防ぐノードのID値のためのより具体的な要件がある場合は、各ホストは、彼らがしていることを証明するために登録サーバによって提供される証明書を（例えば、そのHIP基本交換で）必要があります。オーバーレイ内の特定の識別子を使用する権限。証明書が作成されている方法に応じて、彼らはまた、典型的には、ホストの自己生成した公開鍵を格納する必要があります。ノードIDと公開鍵が起因している方法に応じて、異なるシナリオが可能になります。例えば、ノードIDは、ユーザ公開鍵識別子があってもよい、ユーザに帰属することができ、別のホスト公開鍵識別子があってもよいです。認証証明書は、異なるタイプの識別子を一緒に結合するために使用することができます。
HITs, as defined in [RFC5201], always start with the ORCHID prefix. Therefore, there are 100 bits left in the HIT for different Node ID values. If an overlay network requires a larger address space, it is also possible to use all the 128 bits of a HIT for addressing peer layer identifiers. The benefit of using ORCHID prefix for Node IDs is that it makes possible to use them with legacy socket APIs, but in this context, most of the applications are assumed to be HIP aware and able to use a more advanced API supporting full 128-bit identifiers. Even larger address spaces could be supported with an additional HIP parameter giving the source and destination Node IDs, but defining such a parameter, if needed, is left for future documents.
[RFC5201]で定義されているヒットは、常にORCHID接頭辞で始まります。したがって、異なるノードID値のヒットに残って100ビットがあります。オーバレイネットワークは、より大きなアドレス空間を必要とする場合、ピアレイヤ識別子をアドレス指定するためにHITの全128ビットを使用することも可能です。ノードIDのORCHID接頭辞を使用する利点は、従来のソケットAPIでそれらを使用することが可能になるということですが、この文脈では、アプリケーションのほとんどは、HIP意識と完全な128ビットをサポートし、より高度なAPIを使用することができると想定されています識別子。さらに大きなアドレス空間が必要に応じて追加のHIPパラメータは、送信元と送信先ノードIDを与えるが、そのようなパラメータを定義してサポートすることができ、将来のドキュメントのために残されています。
Bootstrap issues, such as how to locate an enrollment or a bootstrap server, belong to the peer protocol.
そのような登録やブートストラップサーバーを特定する方法として、ブートストラップの問題は、ピア・プロトコルに属しています。
It is possible for a HIP host to participate simultaneously in multiple different overlay networks. It is also possible that some HIP traffic is not intended to be forwarded over an overlay. Therefore, a host needs to know to which overlay an incoming HIP message belongs and the outgoing HIP messages need to be labeled as belonging to a certain overlay. This document specifies a new generic HIP parameter (in Section 6.1) for the purpose of directing HIP messages to the right overlay.
HIPホストが複数の異なるオーバーレイネットワークに同時に参加することが可能です。いくつかのHIPトラフィックがオーバーレイ上で転送されることを意図しないことも可能です。したがって、ホストは、着信HIPメッセージが属すると発信HIPメッセージは、特定のオーバーレイに属するものとしてラベル付けする必要があるオーバーレイに知っておく必要があります。このドキュメントは、右のオーバーレイにHIPメッセージを指示するために、（6.1節で）新しい汎用HIPパラメータを指定します。
In addition, an application using HIP BONE needs to define, either implicitly or explicitly, the overlay to use for communication. Explicit configuration can happen, e.g., by configuring certain local HITs to be bound to certain overlays or by defining the overlay identifier using advanced HIP socket options or other suitable APIs. On the other hand, if no explicit configuration for a HIP association is used, a host may have a configured default overlay where all HIP messages without a valid locator are sent. The specification for how to implement this coordination for locally originated messages is out of scope for this document.
また、股関節の骨を使用するアプリケーションは、暗黙的または明示的に、通信に使用するオーバーレイを定義する必要があります。明示的な設定は、特定のオーバーレイまたは高度HIPソケットオプションまたは他の適切なAPIを使用してオーバーレイの識別子を定義することによって結合される特定のローカルヒットを構成することにより、例えば、起こることができます。 HIP協会のための明示的な設定が使用されていない場合一方、ホストは、有効なロケータなく、すべてのHIPメッセージが送信される設定されたデフォルトのオーバーレイを有することができます。ローカルに発信したメッセージのためにこの調整を実装する方法の仕様はこの文書の範囲外です。
Nodes in an overlay need to establish connections with other nodes in different cases. For example, a node typically has connections to the nodes in its forwarding table. Nodes also need to establish connections with other nodes in order to exchange application-layer messages.
オーバーレイ内のノードは、異なるケース内の他のノードとの接続を確立する必要があります。例えば、ノードは、典型的には、その転送テーブル内のノードへの接続を有しています。ノードはまた、アプリケーション層メッセージを交換するために、他のノードとの接続を確立する必要があります。
As discussed earlier, HIP uses the base exchange to establish connections. A HIP endpoint (the initiator) initiates a HIP base exchange with a remote endpoint by sending an I1 packet. The initiator sends the I1 packet to the remote endpoint's locator. Initiators that do not have any locator for the remote endpoint need to use a rendezvous service. Traditionally, a HIP rendezvous server [RFC5204] has provided such a rendezvous service. In HIP BONE, the overlay itself provides the rendezvous service.
先に述べたように、HIPは、コネクションを確立するために、塩基交換を使用しています。 HIPエンドポイント（開始剤）I1パケットを送信することにより、リモートエンドポイントとのHIP基本交換を開始します。イニシエータは、リモートエンドポイントのロケータにI1パケットを送信します。リモートエンドポイントのための任意のロケータを持っていないイニシエータは、ランデブーサービスを使用する必要があります。伝統的に、HIPランデブーサーバ[RFC5204]は、そのようなランデブサービスを提供しています。 HIP BONEでは、オーバーレイ自体はランデブーサービスを提供しています。
Therefore, in HIP BONE, a node uses an I1 packet (as usual) to establish a connection with another node in the overlay. Nodes in the overlay forward I1 packets in a hop-by-hop fashion according to the overlay's routing table towards its destination. This way, the overlay provides a rendezvous service between the nodes establishing the connection. If the overlay nodes have active connections with other nodes in their forwarding tables and if those connections are protected (typically with IPsec ESP), I1 packets may be sent over protected connections between nodes. Alternatively, if there is no such an active connection but the node forwarding the I1 packet has a valid locator for the next hop, the I1 packets may be forwarded directly, in a similar fashion to how I1 packets are today forwarded by a HIP rendezvous server.
したがって、股関節の骨に、ノードは、オーバーレイ内の別のノードとの接続を確立する（通常通り）I1パケットを使用します。その目的地に向かってオーバーレイのルーティングテーブルに従ってホップバイホップ方式でオーバーレイフォワードI1パケット内のノード。この方法では、オーバーレイは、接続を確立するノード間のランデブーサービスを提供しています。オーバーレイノードは、その転送テーブル内の他のノードとのアクティブな接続を持っている場合、それらの接続は（通常のIPsec ESPで）保護されている場合、I1パケットは、ノード間の保護された接続を介して送信されてもよいです。あるいは、そのようなアクティブな接続が存在しない場合にはI1パケットを転送するノードは、次ホップのために有効なロケータを有し、I1パケットは、今日HIPランデブーサーバによって転送される方法I1パケットと同様に、直接転送することができます。
Since HIP supports NAT traversal, a HIP base exchange over the overlay will perform an ICE [RFC5245] offer/answer exchange between the nodes that are establishing the connection. In order to perform this exchange, the nodes need to first gather candidate addresses. Which nodes can be used to obtain reflexive address candidates and which ones can be used to obtain relayed candidates is defined by the peer protocol.
HIPは、NATトラバーサルをサポートしているので、オーバーレイ上HIP基本交換接続を確立しているノード間のICE [RFC5245]オファー/アンサー交換を実行します。この交換を行うためには、ノードは、第1の候補アドレスを収集する必要があります。どのノードが再帰アドレスの候補を得るために使用することができ、どれが中継候補を得るために使用することができるピア・プロトコルによって定義されます。
In some cases, nodes need to perform a lightweight query to another node (e.g., a request followed by a single response). In this situation, establishing a connection using the mechanisms in Section 5.3 for a simple query would be an overkill. A better solution is to forward a HIP message through the overlay with the query and another one with the response to the query. The payload of such HIP packets is integrity protected [RFC6078].
いくつかのケースでは、ノードが別のノード（例えば、単一の応答に続く要求）に軽量なクエリを実行する必要があります。このような状況では、単純なクエリについては、セクション5.3のメカニズムを使用して接続を確立することは、やり過ぎでしょう。よりよい解決策は、クエリに応答して、クエリと他のものとのオーバーレイを介してHIPメッセージを転送することです。このようなHIPパケットのペイロードは、完全性保護された[RFC6078]です。
Nodes in the overlay forward this HIP packet in a hop-by-hop fashion according to the overlay's routing table towards its destination, typically through the protected connections established between them. Again, the overlay acts as a rendezvous server between the nodes exchanging the messages.
オーバーレイ内のノードは、典型的には、それらの間に確立された保護された接続を介して、その宛先に向けてオーバーレイのルーティングテーブルに従ってホップバイホップ方式でこのHIPパケットを転送します。再び、オーバーレイは、メッセージを交換ノード間のランデブーサーバとして機能します。
As discussed in Section 5, HIP BONE is a generic framework that allows using different peer protocols. A particular HIP BONE instance uses a particular peer protocol. The details on how to implement a HIP BONE using a given peer protocol need to be specified in a, so-called, HIP BONE instance specification. A HIP BONE instance specification needs to define, minimally:
セクション5で説明したように、腰骨は異なるピア・プロトコルを使用可能にする汎用的なフレームワークです。特定の腰骨のインスタンスは、特定のピア・プロトコルを使用します。所与のピアプロトコルを使用して股関節の骨を実装する方法の詳細は、いわゆるHIP BONEインスタンス仕様で指定する必要があります。股関節の骨のインスタンス仕様は最低限、定義する必要があります。
o the peer protocol to be used, o what kind of Node IDs are used and how they are derived, o which peer protocol primitives trigger HIP messages, and o how the overlay identifier is generated.
Oピアプロトコルは、OノードのIDの種類が使用されて使用され、それらが誘導される方法、プロトコルプリミティブをピアoはHIPメッセージをトリガし、及びOオーバーレイ識別子がどのように生成されます。
Additionally, a HIP BONE instance specification may need to specify other details that are specific to the peer protocol used.
また、HIP骨インスタンス仕様は、使用されるピアプロトコルに固有のその他の詳細を指定する必要があるかもしれません。
As an example, the HIP BONE instance specification for RELOAD [P2PSIP-BASE] is specified in [HIP-RELOAD-INSTANCE].
一例として、リロード[P2PSIP-BASE]のためのHIP骨インスタンス仕様は[HIPリロードインスタンス]で指定されています。
The areas not covered by a particular HIP BONE instance specification are specified by the peer protocol or elsewhere. These areas include:
特定の寛骨インスタンス仕様によって覆われていない領域は、ピアプロトコルまたは他の場所で指定されています。これらの領域は、次のとおりです。
o the algorithm to create the overlay (e.g., a DHT), o overlay maintenance functions, o data storage and retrieval functions, o the process for obtaining a Node ID, o bootstrap function, and o how to select STUN and TURN servers for the candidate address collection process in NAT traversal scenarios.
オーバーレイ（例えば、DHT）を作成するアルゴリズムO、オーバーレイメンテナンス機能O、データ記憶および検索機能、O、ノードIDを取得するためのプロセスO、ブートストラップ機能O、及びためにSTUNとTURNサーバを選択する方法O NATトラバーサルシナリオで候補アドレス収集プロセス。
Note that the border between a HIP BONE instance specification and a peer protocol specifications is fuzzy. Depending on how generic the specification of a given peer protocol is, its associated HIP BONE instance specification may need to specify more or less details. Also, a HIP BONE instance specification may leave certain areas unspecified in order to leave their configuration up to each particular overlay.
HIP骨インスタンス仕様とピアプロトコル仕様の境界があいまいであることに留意されたいです。所与のピアプロトコルの仕様がどのようにジェネリックに応じて、その関連するHIP骨インスタンス仕様は、多かれ少なかれ詳細を指定する必要があるかもしれません。また、HIP骨インスタンス仕様は、各特定のオーバーレイにその構成を残すために指定されていない特定の領域を残すことができます。
This section defines the generic format and protocol behavior for the Overlay Identifier and Overlay Time-to-Live (TTL) HIP parameters that can be used in HIP based overlay networks. HIP BONE instance specifications define the exact format and content of the Overlay Identifier parameter, the cases when the Overlay TTL parameter should be used, and any additional behavior for each packet.
このセクションでは、HIPベースのオーバレイネットワークで使用することができるオーバーレイ識別子とオーバーレイタイム・ツー・ライブ（TTL）HIPパラメータの一般的なフォーマットおよびプロトコル動作を定義します。 HIP BONEインスタンス仕様は、オーバーレイ識別子パラメータの正確なフォーマットおよびコンテンツを定義、オーバーレイTTLパラメータが使用されるべきである場合、各パケットのための任意の追加の行動。
To identify to which overlay network a HIP message belongs, all HIP messages that are sent via an overlay, or as a part of operations specific to a certain overlay, MUST contain an OVERLAY_ID parameter with the identifier of the corresponding overlay network. Instance specifications define how the identifier is generated for different types of overlay networks. The generation mechanism MUST be such that it is unlikely to generate the same identifier for two different overlay instances and any other means possible for preventing collisions SHOULD be used.
HIPメッセージが属するオーバレイネットワーク、オーバーレイを介して送信されるすべてのHIPメッセージ、または特定のオーバーレイに特定の操作の一部として、対応するオーバレイネットワークの識別子とOVERLAY_IDパラメータを含まなければならないために識別することができます。インスタンス仕様は、識別子は、オーバレイネットワークの種類ごとに生成される方法を定義します。生成機構は、2つの異なるオーバーレイインスタンスに対して同じ識別子を生成しにくい、他が使用されるべき衝突を防止するための可能な意味ようなものでなければなりません。
The generic format of the OVERLAY_ID parameter is shown in Figure 8. Instance specifications define valid length for the parameter and how the identifier values are generated.
OVERLAY_IDパラメータの一般的な形式は8インスタンス仕様は、パラメータの有効な長さを定義し、識別子の値がどのように生成され、図に示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4592 Length Length of the Identifier, in octets Identifier The identifier value Padding 0-7 bytes of padding if needed
必要に応じて、オクテットタイプ4592の識別子の長さの長さは、識別子値のパディングをパディングの0-7バイト識別子
Figure 8: Format of the OVERLAY_ID Parameter
図8：OVERLAY_IDパラメータのフォーマット
HIP packets sent in an overlay network MAY contain an Overlay Time-to-live (OVERLAY_TTL) parameter whose TTL value is decremented on each overlay network hop. When a HIP host receives a HIP packet with an OVERLAY_TTL parameter, and the host is not the final recipient of the packet, it MUST decrement the TTL value in the parameter by one before forwarding the packet.
オーバーレイ・ネットワークで送信HIPパケットは、そのTTL値が各オーバレイネットワークホップでデクリメントされるオーバーレイタイム・ツー・ライブ（OVERLAY_TTL）パラメータを含むかもしれません。 HIPホストがOVERLAY_TTLパラメータでHIPパケットを受信し、ホストはパケットの最終的な受信者でない場合、そのパケットを転送する前にいずれかによってパラメータにTTL値をデクリメントしなければなりません。
If the TTL value in a received HIP packet is zero, and the receiving host is not the final recipient, the packet MUST be dropped and the host SHOULD send HIP Notify packet with NOTIFICATION error type OVERLAY_TTL_EXCEEDED (value 70) to the sender of the original HIP packet.
受信されたHIPパケット内のTTL値がゼロであり、受信ホストが最終受信者でない場合、パケットは廃棄されなければなりません、そして、ホストは、元の送信者への通知のエラータイプOVERLAY_TTL_EXCEEDED（値70）でパケットを通知HIPを送信すべきですHIPパケット。
The Notification Data field for the OVERLAY_TTL_EXCEEDED notifications SHOULD contain the HIP header and the TRANSACTION_ID [RFC6078] parameter (if one exists) of the packet whose TTL was exceeded.
OVERLAY_TTL_EXCEEDED通知の通知データフィールドは、HIPヘッダ及びTTLを超えたパケットのTRANSACTION_ID [RFC6078]パラメータを（存在する場合）を含有すべきです。
Figure 9 shows the format of the OVERLAY_TTL parameter. The TTL value is given as the number of overlay hops this packet has left and it is encoded as an unsigned integer using network byte order.
図9は、OVERLAY_TTLパラメータのフォーマットを示します。オーバーレイの数は、このパケットがネットワークバイト順を使用して残っていると、それは、符号なし整数として符号化されたホップとしてTTL値が与えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 64011 Length 4 TTL The Time-to-Live value Reserved Reserved for future use
将来の使用のためのタイム・ツー・ライブ値予約予約64011長さ4 TTLを入力
Figure 9: Format of the OVERLAY_TTL Parameter
図9：OVERLAY_TTLパラメータのフォーマット
The type of the OVERLAY_TTL parameter is critical (as defined in Section 5.2.1 of [RFC5201]) and therefore all the HIP nodes forwarding a packet with this parameter MUST support it. If the parameter is used in a scenario where the final recipient does not support the parameter, the parameter SHOULD be removed before forwarding the packet to the final recipient.
OVERLAY_TTLパラメータの種類は、このパラメータを使用してパケットを転送するすべてのHIPノードがそれをサポートしなければならないことが重要（[RFC5201]のセクション5.2.1で定義されるように）とです。パラメータは、最終的な受信者がパラメータをサポートしていないシナリオで使用されている場合、パラメータは、最終的な受信者にパケットを転送する前に削除する必要があります。
This document provides a high-level framework to build HIP-based overlays. The security properties of HIP and its extensions used in this framework are discussed in their respective specifications. Those security properties can be affected by the way HIP is used in a particular overlay. However, those properties are mostly affected by the design decisions made to build a particular overlay; not so much by the high-level framework specified in this document. Such design decisions are typically documented in a HIP BONE instance specification, which describes the security properties of the resulting overlay.
この文書では、HIPベースのオーバーレイを構築するためのハイレベルなフレームワークを提供します。このフレームワークで使用されているセキュリティHIPの性質とその拡張機能は、それぞれの仕様書で議論されています。これらのセキュリティプロパティは、HIPは、特定のオーバーレイに使用される方法によって影響を受けることができます。しかし、これらのプロパティは、主に特定のオーバーレイを構築するために作られた設計上の決定の影響を受けています。この文書で指定された高レベルのフレームワークによって、それほどではありません。このような設計上の決定は、典型的には、得られたオーバーレイのセキュリティ特性を記述する腰骨インスタンス仕様に文書化されています。
HIP BONE is based on ideas coming from conversations and discussions with a number of people in the HIP and P2PSIP communities. In particular, Philip Matthews, Eric Cooper, Joakim Koskela, Thomas Henderson, Bruce Lowekamp, and Miika Komu provided useful input on HIP BONE.
HIP BONEは、HIPとP2PSIP地域社会の人々の数との会話や議論からのアイデアに基づいています。具体的には、フィリップ・マシューズ、エリック・クーパー、ヨアキムKoskela、トーマス・ヘンダーソン、ブルースLowekamp、およびMiikaこむには、股関節の骨に便利な入力を提供します。
This section is to be interpreted according to [RFC5226].
このセクションでは、[RFC5226]に従って解釈されるべきです。
This document updates the IANA Registry for HIP Parameter Types [RFC5201] by assigning HIP Parameter Type values for the new HIP Parameters OVERLAY_ID (defined in Section 6.1) and OVERLAY_TTL (defined in Section 6.2). This document also defines a new HIP Notify Message Type [RFC5201], OVERLAY_TTL_EXCEEDED in Section 6.2. This value is allocated in the error range.
この文書は、新しいHIPパラメータOVERLAY_ID（6.1節で定義されている）とOVERLAY_TTL（セクション6.2で定義された）のためのHIPパラメータタイプ値を割り当てることによって、HIPパラメータ型[RFC5201]のためのIANAレジストリを更新します。この文書はまた、新しいHIPは、セクション6.2でOVERLAY_TTL_EXCEEDEDメッセージタイプ[RFC5201]を、通知を定義します。この値は、誤差範囲に配置されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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., Ed., 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）トランスポートフォーマットを使用します"。
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keranen, Ed., "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月。
[RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)", RFC 6078, January 2011.
[RFC6078]キャマリロ、G.とJ.メレン、「ホストアイデンティティプロトコル（HIP）上位層プロトコルシグナリング（しゃっくり）の即時運送及び搬送」、RFC 6078、2011年1月。
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] Ylonenと、T.とC. Lonvick、エド。、 "セキュアシェル（SSH）プロトコルアーキテクチャ"、RFC 4251、2006年1月。
[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., Ed., 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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[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月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "NAT（STUN）のセッショントラバーサルユーティリティ"、RFC 5389、2008年10月。
[HIP-NATIVE-API] Komu, M. and T. Henderson, "Basic Socket Interface Extensions for Host Identity Protocol (HIP)", Work in Progress, January 2010.
[HIP-NATIVE-API]こむ、M.とT.ヘンダーソン、 "基本的なソケットインタフェース拡張ホストの識別プロトコル（HIP）"、進歩、2010年1月の作業。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]ローゼンバーグ、J.、 "インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書"、RFC 5245、2010年4月。
[P2PSIP-BASE] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", Work in Progress, November 2010.
[P2PSIP-BASE]ジェニングス、C.、Lowekamp、B.、編。、レスコラ、E.、BASET、S.、およびH. Schulzrinneと、 "リソースロケーションとディスカバリー（リロード）ベースプロトコル"、進歩、11月にワーク2010。
[HIP-RELOAD-INSTANCE] Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)", Work in Progress, January 2011.
[HIPリロードインスタンス] Keranen、A.、カマリロ、G.、およびJ. Maenpaa、「ホストアイデンティティプロトコルベースのオーバレイネットワーク環境（寛骨）リソースロケーションとディスカバリー（リロード）のインスタンス仕様」進行中、作業、2011年1月。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Pekka Nikander Ericsson Hirsalantie 11 Jorvas 02420 Finland
ペッカNikanderエリクソンHirsalantie 11 02420 Jorvasフィンランド
EMail: Pekka.Nikander@ericsson.com
メールアドレス：Pekka.Nikander@ericsson.com
Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420 Finland
ヤニHautakorpiエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Jani.Hautakorpi@ericsson.com
メールアドレス：Jani.Hautakorpi@ericsson.com
Ari Keranen Ericsson Hirsalantie 11 Jorvas 02420 Finland
KeranenエリクソンHirsalantie 11 02420 Jorvasフィンランド
EMail: Ari.Keranen@ericsson.com
メールアドレス：Ari.Keranen@ericsson.com
Alan Johnston Avaya St. Louis, MO 63124
アラン・ジョンストンアバイアセントルイス、MO 63124
EMail: alan.b.johnston@gmail.com
メールアドレス：alan.b.johnston@gmail.com