[要約] 要約：RFC 6079は、Host Identity Protocol（HIP）ベースのオーバーレイネットワーキング環境（BONE）に関する情報を提供します。 目的：このRFCの目的は、HIPを使用してセキュアなオーバーレイネットワークを構築するためのガイドラインと手法を提供することです。
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)
ヒップボーン：オーバーレイネットワーキング環境（骨）に基づくホストアイデンティティプロトコル（HIP）
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".
このドキュメントは、ヒップベースの（ホストIDプロトコル）オーバーレイネットワークを構築するためのフレームワークを指定します。このフレームワークは、股関節を使用して接続管理を実行します。データストレージや検索、オーバーレイのメンテナンスなどのその他の機能は、股関節以外のプロトコルを使用して実装されます。これらのプロトコルは、「ピアプロトコル」と大まかに呼ばれます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6079.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
ホストIDプロトコル（HIP）[RFC5201]は、ネットワーク層と輸送層の間の新しい名前空間を定義します。HIPは、上層層にモビリティ、マルチホミング、NAT（ネットワークアドレス変換）トラバーサル、およびセキュリティ機能を提供します。股関節は、いわゆる識別子/ロケーター（ID/ロケーター）スプリットを実装します。これは、IPアドレスがホスト識別子としてではなく、ロケーターとしてのみ使用されることを意味します。この分割により、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 Bone）を使用して、オーバーレイで接続管理を実行するには一連の利点があります。ヒップボーンは、任意のピアプロトコルで使用できます。これにより、各ピアプロトコルは、接続管理に必要なプリミティブ（たとえば、接続を確立し、オーバーレイを介してメッセージをトンネルするためのプリミティブ）と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では、股関節に関する背景情報を提供します。セクション4では、股関節骨（股関節ベースのオーバーレイネットワーキング環境）フレームワークとアーキテクチャの概要を示し、セクション5ではフレームワークについて詳しく説明します。最後に、セクション6では、オーバーレイ使用のための新しい股関節パラメーターを紹介します。
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:
以下の用語は、股関節の骨のコンテキストで使用されます。
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.
オーバーレイネットワーク：別のネットワークの上に構築されたネットワーク。股関節の場合、基礎となるネットワークは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.
ヒップボーンインスタンス：特定のピアプロトコルを使用し、このドキュメントに示されているフレームワークに基づいているヒップベースのオーバーレイネットワーク。
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 Association：ホストIDプロトコルを使用して作成された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アドレスまたはアドレスとポート番号）があります。
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.
最終受信者：ホストIDタグ（ヒット）のいずれかがヒップパケットヘッダーでのレシーバーのヒットに一致する場合、ノードは股関節シグナリングパケットの最終受信者です。
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の仕組みに精通している読者は、それをスキップしたいと思うかもしれません。すべての説明には、読者がこのセクションで説明したさまざまなトピックに関する詳細な説明を見つけることができる関連する股関節仕様への参照が含まれています。
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アドレスのように見えますが、ランスペースがIANAに登録されているため、通常のIPv6アドレスと衝突することはできません。つまり、IPv6アドレススペースの一部はラン用に予約されています。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を使用したアプリケーションが股関節をどのように使用できるかについて説明します。図1は、アプリケーションと輸送層の間のこれらすべてのAPIを示しています。
+-----------------------------------------+
| Application |
+----------------+------------------------+
| HIP Native API | Traditional Socket API |
+----------------+------------------------+
| Transport Layer |
+-----------------------------------------+
Figure 1: HIP API
図1：ヒップ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つの股関節ホストが上層層トラフィックを交換する前に、股関節ベース交換と呼ばれる4方向の握手を実行します。図2は、股関節のベース交換を示しています。イニシエーターはi1パケットを送信し、レスポンダーからR1パケットを受け取ります。その後、イニシエーターはi2パケットを送信し、レスポンダーからR2パケットを受け取ります。
Initiator Responder
イニシエーターレスポンダー
| I1 |
|-------------------------->|
| R1 |
|<--------------------------|
| I2 |
|-------------------------->|
| R2 |
|<--------------------------|
Figure 2: HIP Base Exchange
図2：ヒップベース交換
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パケットを送信するために、レスポンダーのロケーター（またはロケーター）が必要です。イニシエーターは、複数の方法でレスポンダーのロケーターを取得できます。たとえば、現在の股関節仕様によれば、イニシエーターは、股関節ランズヴォーサーバー[RFC5204]を介してパケットを送信することにより、DNS [RFC5205]からロケーターを直接取得するか、間接的にロケーターを取得できます。ただし、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つのホスト間の股関節接続が股関節ベース交換で確立されると、ホストはより高い層のトラフィックの交換を開始できます。ホストのいずれかがロケーターのセットを変更すると、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.
HIPのNATトラバーサルメカニズム[RFC5770]は、氷（インタラクティブ接続の確立）[RFC5245]に基づいています。ホストは住所候補者を収集し、ヒップベース交換の一環として、ホストはそれぞれの住所候補を交換するアイスオファー/回答交換を実行します。ホストは、エンドツーエンドのスタンベースの[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).
建築的には、股関節は輸送層の下にありますが（つまり、股関節パケットはIPパケットに直接運ばれます）、NATの存在下では、股関節を輸送プロトコルでトンネル化する必要がある場合があります（つまり、股関節パケットは輸送によって運ばれます。UDPなどのプロトコル）。
Security is an essential part of HIP. The following sections describe the security-related functionality provided by 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パケットを受信すると、レスポンダーは、暗号化パズルを含む事前に生成されたR1パケットを送信し、このI1パケットの処理に関連するすべての状態を削除します。イニシエーターは、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.
オーバーレイシナリオには、このメカニズムをオーバーレイ内で利用できる複数の方法があります。1つの可能性は、オーバーレイ内の事前に生成されたR1パケットをキャッシュし、オーバーレイをR1SでI1Sに直接応答させることです。そのようにして、イニシエーターがパズルソリューションを使用して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は、衝突を見つける可能性（つまり、同じ蘭の2つのノード）が十分に低い限り、異なるタイプのランを使用できます。このタイプの衝突を完全に回避する1つの方法は、中央当局にノードに蘭を生成して割り当てることです。中央当局がランにノードに割り当てるたびに、ランと高層識別子の間のバインディングを確保するために、オーキッドの所有者である人を示す証明書を生成して署名します。Orchidの所有者は、R1（Responderとして機能する場合）およびI2パケット（Initiatatorの演技の場合）に対応する証明書を含めて、Orchidを実際に使用し、暗黙的に関連する公開キーを使用することが許可されていることを証明します。
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システムは一般に、中央当局を必要としない（ただし、使用することを許可しない）と呼ばれる自己認証の蘭タイプ（ホストIDタグ）を使用します。
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]).
ヒットは、ノードの公開キーのハッシュです。ノードは、関連する秘密鍵でデータに署名する機能を示すことにより、ヒットを使用する権利があることを証明します。このスキームは、ハッシュ関数のいわゆる第2層抵抗特性のために安全です。つまり、固定された公開キーK1が与えられた場合、Hash（K1）= Hash（K2）が計算的に非常に困難であるような、異なる公開キーK2が見つかります。最適に、ランで使用される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.
HITSを使用したHIPノードは、Orchidsとして、通常、ベース交換中に証明書を使用しません。代わりに、セキュアシェル（SSH）プロトコル[RFC4251]と同様に、彼らは信仰の葉のメカニズムを使用します。ユーザー支援の葉の葉のメカニズム（SSHなど）を使用して、人間操作のオフラインパス（電話など）を促進することができますが、自動化された葉のメカニズムは評判管理システムと組み合わせることができます。振る舞うインセンティブを作成する。ただし、このような考慮事項は、現在の股関節アーキテクチャをはるかに超えており、この提案を超えています。現在のドキュメントの目的のために、私たちは、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つのノードがそれらの間の基本交換を完了すると、交換するトラフィックは暗号化され、整合性が保護されます。トラフィックを保護するために使用されるセキュリティメカニズムは、セキュリティペイロード（ESP）[RFC5202]をカプセル化するIPSECです。ただし、他の保護メカニズムを使用する方法を指定するための継続的な作業があります。
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]を定義しています。新しいアプリケーションは、このAPIを実装して、股関節を最大限に活用できます。ただし、ほとんどの場合、レガシー（つまり、非人権）アプリケーション[RFC5338]は、従来のIPv4およびIPv6ソケットAPIを介して股関節を使用できます。
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.
アイデアは、Legacy IPv6アプリケーションがリモートホストのIPアドレスを取得しようとすると（例：DNSを照会することにより）、DNSリゾルバーがリモートホストのオーキッド（DNSに保存されている）をレガシーアプリケーションに渡すということです。同時に、DNS Resolverは、HIPモジュールにリモートホストのIPアドレスを内部に保存します。OrchidはIPv6アドレスのように見えるため、レガシーアプリケーションはそれをそのように扱います。従来のIPv6ソケットAPIを使用して、接続（TCPなど）を開きます。レガシーアプリケーションと同じホストで実行されている股関節モジュールは、この呼び出しを何らかの形でインターセプトします（たとえば、インターセプトライブラリを使用するか、股関節モジュールがトラフィックを受信するようにホストのルーティングテーブルをセットアップして）（レガシーアプリケーションに代わって）を実行する）蘭に対応する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を介して股関節を動作させるために、股関節モジュールは、通常のIPv4アドレスの代わりにLSI（ローカルスコープ識別子）をREGACY IPv4アプリケーションに渡します。LSIはIPv4アドレスのように見えますが、蘭に局所的に結合されています。つまり、レガシーアプリケーションがソケット呼び出しでLSIを使用すると、HIPモジュールはそれをインターセプトし、LSIを対応する蘭に置き換えます。したがって、LSIには常にローカルスコープがあります。ホストの外にアプリケーションを実行している意味はありません。ランはワイヤーで使用されます。LSIではありません。紹介の場合、アプリケーションレベルのパケットをLSISの代わりにオーキッドを使用するように書き換えることができない場合、IPv4の紹介をインターネット全体の設定で機能させるのは難しいかもしれません。IPv4 LSIは、単一のコーポレートネットワーク内の既存の股関節展開で正常に使用されています。
The HIP BONE framework combines HIP with different peer protocols to provide robust and secure overlay network solutions.
ヒップボーンフレームワークは、股関節と異なるピアプロトコルを組み合わせて、堅牢で安全なオーバーレイネットワークソリューションを提供します。
Many overlays typically require three types of operations:
通常、多くのオーバーレイには3種類の操作が必要です。
o overlay maintenance, o data storage and retrieval, and o connection management.
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.
ヒップボーンフレームワークは、股関節を使用して接続管理を実行します。データストレージと検索およびオーバーレイのメンテナンスは、股関節以外のプロトコルを使用して実装されます。より良い名前がないため、これらのプロトコルはピアプロトコルと呼ばれます。
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.
ピアプロトコルと股関節モジュールの関係を描写する1つの方法を図3に示します。ピアプロトコルモジュールは、オーバーレイの構築とメンテナンス機能、および場合によってはストレージを実装しています（特定のプロトコルがそのような機能をサポートしている場合）。HIPモジュールは、ピアプロトコルのオーバーレイトポロジーパートに相談してルーティングの決定を下します。ピアプロトコルは、接続管理と他のホストにピアプロトコルメッセージを送信するためにHIPを使用します。アプリケーションが使用するヒップボーンAPIは、特定のインスタンスの実装が提供する追加のAPIと、HIPネイティブAPIと従来のソケットAPI（図1に示す）の組み合わせです。
Application
-------------------------------- HIP BONE API
+---+ +--------------------+
| | | Peer Protocol |
| | +--------+ +---------+
| |<->|Topology| |(Storage)|
| | +---------+----------+
| | ^
| | v
| +------------------------+
| HIP |
+----------------------------+
Figure 3: HIP with Peer Protocol
図3：ピアプロトコル付きの股関節
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.
アーキテクチャには、股関節を考慮して、IPv4およびIPv6ネットワークの上に新しい薄い「ウエスト」層を作成することができます。図4を参照してください。股関節層自体は、股関節シグナル伝達プロトコルと1つ以上のデータ輸送プロトコルで構成されています。図5を参照してください。股関節信号パケットとデータトランスポートパケットは、異なるルートをとることができます。股関節骨シナリオでは、通常、股関節シグナリングパケットは最初にオーバーレイを介して直接（可能な場合）直接ルーティングされますが、データトランスポートパケットは通常、エンドポイント間で直接ルーティングされます。
+--------------------------------------+
| Transport (using HITs or LSIs) |
+--------------------------------------+
| HIP |
+------------------+-------------------+
| IPv4 | IPv6 |
+------------------+-------------------+
Figure 4: HIP as a Thin Waist
図4：腰の腰の腰
+------------------+-------------------+
| HIP signaling | data transports |
+------------------+-------------------+
Figure 5: HIP Layer Structure
図5：股関節層構造
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.
ヒップボーンでは、ピアプロトコルが股関節の上に新しいシグナル伝達層を作成します。これは、股関節信号メッセージの転送パスをセットアップするために使用されます。これは、OSPFなどのIPルーティングプロトコルがIPプロトコル自体に持っている同様の関係です。股関節骨の場合、ピアプロトコルはOSPFと同様の役割を果たし、股関節はIPと同様の役割を果たします。オーキッド（または一般に、蘭のプレフィックスが使用されていない場合のノードID）は、ルーティングテーブルの情報に従って股関節パケットを転送するために使用されます。ピアプロトコルは、ノード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に示すように、ピアプロトコルと股関節の間にあります。ピアプロトコルはルーティングテーブルを構築し、更新し続けます。股関節層は、ルーティングの決定を下すためにルーティングテーブルにアクセスします。股関節骨オーバーレイのブートストラップは、ピアプロトコル（他のノードとの接続を確立するために股関節を使用する必要がある）とヒップ（他のノードへのメッセージをルーティングする方法を知るためにピアプロトコルが必要）と同じように循環依存関係を作成しません。IPネットワークのブートストラップとしての理由は、OSPFとIPの間に循環依存関係を作成しません。ピアプロトコルによって確立された最初の接続は、ロケーターが既知のノードを使用します。HIPは、オーバーレイが存在しない2つの股関節ノード間の接続としてこれらの接続を確立します。つまり、オーバーレイがそれらの接続にランデブーサービスを提供する必要はありません。
+--------------------------------------+
| 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つのオーバーレイのルーティングテーブルの構造は非常に異なる場合があります。ルーティングの決定を下すために、ヒップ層は、ピアプロトコルによって生成されたルーティングテーブルを転送テーブルに変換する必要があります。これにより、ヒップ層がルーティングされるパケットの次のホップを選択できます。
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.
ヒップボーンでは、ハッシュ関数を介したパブリックキーと蘭の誘導性の股関節をピアプロトコル側で利用して、ルーティングテーブルのメンテナンスをよりよく保護し、選択したピア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.
Hip Boneは、さまざまなプロトコルを詳細に配置する方法に関して、非常に多くの柔軟性を提供します。図7は、1つの潜在的なスタック構造を示しています。
+-----------------------+--------------+
| peer protocols | media |
+------------------+----+--------------+
| HIP signaling | data transport |
| |
+------------------+-------------------+
| NAT | non-NAT | |
| | |
| IPv4 | IPv6 |
+------------------+-------------------+
Figure 7: Example HIP BONE Stack Structure
図7：ヒップボーンスタック構造の例
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].
ヒップボーンは、異なるピアプロトコルを使用できる一般的なフレームワークです。特定の股関節骨インスタンスは、特定のピアプロトコルを使用します。特定のピアプロトコルを使用して股関節骨を実装する方法の詳細は、いわゆる股関節インスタンスの仕様で指定する必要があります。セクション5.5では、ヒップボーンインスタンスの仕様で指定する必要がある詳細について説明します。たとえば、リロード[p2psip-base]の股関節骨インスタンス仕様は、[股関節層]で指定されています。
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はヒップおよびレガシー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値に対してより特定の要件がある場合、各ホストは、登録サーバーが提供する証明書（例えば、ヒップベース交換）が必要です。オーバーレイで特定の識別子を使用することが許可されています。証明書の構築方法に応じて、通常、ホストの自己生成された公開キーも封じ込める必要があります。ノード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]で定義されているヒットは、常に蘭のプレフィックスから始めます。したがって、異なるノードID値に対してヒットには100ビットが残っています。オーバーレイネットワークがより大きなアドレススペースを必要とする場合、ピア層識別子にアドレス指定するために、128ビットのヒットすべてを使用することもできます。ノードIDにOrchidプレフィックスを使用することの利点は、レガシーソケットAPIでそれらを使用できることですが、このコンテキストでは、ほとんどのアプリケーションは、フル128ビットをサポートするより高度なAPIを使用できると想定されています。識別子。さらに大きなアドレススペースは、ソースと宛先ノード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.
股関節ホストが複数の異なるオーバーレイネットワークに同時に参加する可能性があります。また、一部の股関節トラフィックがオーバーレイに転送されることを意図していない可能性もあります。したがって、ホストは、どのオーバーレイを着信する股関節メッセージが属し、発信股関節メッセージに特定のオーバーレイに属しているとラベル付けする必要があることを知る必要があります。このドキュメントは、右のオーバーレイに股関節メッセージを向ける目的で、新しい汎用股関節パラメーター（セクション6.1の）を指定します。
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.
さらに、股関節骨を使用するアプリケーションは、暗黙的または明示的に、通信に使用するオーバーレイを定義する必要があります。たとえば、特定のローカルヒットを特定のオーバーレイにバインドするように構成するか、高度な股関節ソケットオプションまたはその他の適切なAPIを使用してオーバーレイ識別子を定義することにより、明示的な構成が発生する可能性があります。一方、股関節関連の明示的な構成が使用されない場合、ホストには、有効なロケーターのないすべての股関節メッセージが送信される設定されたデフォルトオーバーレイがある場合があります。このドキュメントのこの調整を実装する方法の仕様は、このドキュメントの範囲外です。
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はベース交換を使用して接続を確立します。ヒップエンドポイント（イニシエーター）は、i1パケットを送信することにより、リモートエンドポイントとのヒップベース交換を開始します。イニシエーターは、i1パケットをリモートエンドポイントのロケーターに送信します。リモートエンドポイントのロケーターがないイニシエーターは、ランデブーサービスを使用する必要があります。従来、股関節ランデブーサーバー[RFC5204]は、このようなランデブーサービスを提供してきました。ヒップボーンでは、オーバーレイ自体がランデブーサービスを提供します。
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パケットは、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.
股関節はNATトラバーサルをサポートするため、オーバーレイ上の股関節ベース交換は、接続を確立しているノード間のアイス[RFC5245]オファー/回答交換を実行します。この交換を実行するには、ノードは最初に候補アドレスを収集する必要があります。どのノードを使用して反射アドレス候補を取得でき、どのノードを使用して中継候補を取得することができるかは、ピアプロトコルによって定義されます。
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のメカニズムを使用して接続を確立することは過剰になります。より良い解決策は、クエリを使用してオーバーレイを介してヒップメッセージとクエリへの応答を備えたものを転送することです。このような股関節パケットのペイロードは、整合性保護されています[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.
オーバーレイ内のノードは、このヒップパケットをホップバイホップで、宛先に向かってオーバーレイのルーティングテーブルに従って、通常はそれらの間に確立された保護された接続を介して、ホップバイホップの方法で前方に進みます。繰り返しますが、オーバーレイは、メッセージを交換するノード間のランデブーサーバーとして機能します。
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ピアプロトコルプリミティブが股関節メッセージをトリガーするoオーバーレイ識別子の生成方法。
Additionally, a HIP BONE instance specification may need to specify other details that are specific to the peer protocol used.
さらに、股関節骨インスタンスの仕様では、使用されるピアプロトコルに固有の他の詳細を指定する必要がある場合があります。
As an example, the HIP BONE instance specification for RELOAD [P2PSIP-BASE] is specified in [HIP-RELOAD-INSTANCE].
例として、リロード[p2psip-base]の股関節骨インスタンス仕様は[hip-reload-instance]で指定されています。
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.
o オーバーレイ（例：DHT）、oオーバーレイメンテナンス関数、oデータストレージおよび検索機能、oノードID、oブートストラップ関数を取得するプロセス、o候補のStunおよびターンサーバーを選択する方法。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.
股関節骨インスタンスの仕様とピアプロトコル仕様の境界線はファジーであることに注意してください。特定のピアプロトコルの仕様がどれだけ一般的であるかに応じて、関連する股関節インスタンスの仕様が多かれ少なかれ詳細を指定する必要がある場合があります。また、股関節骨インスタンスの仕様により、特定のオーバーレイまで構成を維持するために、特定の領域が不特定のままになる場合があります。
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.
このセクションでは、股関節ベースのオーバーレイネットワークで使用できるオーバーレイ識別子およびオーバーレイ時間（TTL）股関節パラメーターの一般的な形式とプロトコルの動作を定義します。HIP Bone Instance仕様は、オーバーレイ識別子パラメーターの正確な形式とコンテンツ、オーバーレイ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.
どのオーバーレイネットワークに該当するかを識別するには、股関節メッセージが属するか、オーバーレイを介して送信されるすべての股関節メッセージ、または特定のオーバーレイに固有の操作の一部として、対応するオーバーレイネットワークの識別子を備えた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.
オーバーレイネットワークで送信された股関節パケットには、各オーバーレイネットワークホップでTTL値が減少しているオーバーレイ時間（overlay_ttl）パラメーターが含まれる場合があります。股関節ホストがOverlay_TTLパラメーターを備えたHIPパケットを受信し、ホストがパケットの最終的な受信者ではない場合、パケットを転送する前にパラメーターのTTL値を1つずつ減らす必要があります。
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.
受信した股関節パケットのTTL値がゼロであり、受信ホストが最終受信者ではない場合、パケットをドロップする必要があり、ホストは通知エラータイプのOverlay_ttl_exeded（Value 70）でヒップ通知パケットを送信する必要があります。ヒップパケット。
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_exeded通知の通知データフィールドには、TTLを超えたパケットのTransaction_id [rfc6078]パラメーター（存在する場合）をhipヘッダーとttlを超えたパラメーターを含める必要があります。
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の長さ4ttl将来の使用のために予約されている時間までの価値
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パラメーターのタイプは重要です（[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 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.
ヒップボーンは、股関節およびP2PSIPコミュニティの多くの人々との会話や議論からのアイデアに基づいています。特に、フィリップ・マシューズ、エリック・クーパー、ジョキム・コスケラ、トーマス・ヘンダーソン、ブルース・ロウェーカンプ、ミカ・コムは、股関節骨に有用な入力を提供しました。
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.
このドキュメントは、新しい股関節パラメーターoverlay_id（セクション6.1で定義）およびanuverlay_ttl（セクション6.2で定義）のHIPパラメータータイプ値を割り当てることにより、股関節パラメータータイプ[RFC5201]のIANAレジストリを更新します。このドキュメントでは、セクション6.2で成功した新しい股関節通知メッセージタイプ[RFC5201]も定義されています。この値はエラー範囲で割り当てられます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Dupont、「オーバーレイのルーティング可能な暗号ハッシュ識別子（蘭）のIPv6プレフィックス」、RFC 4843、2007年4月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P.、Ed。、およびT. Henderson、「Host Identity Protocol」、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.、Moskowitz、R。、およびP. Nikander、「ホストIDプロトコル（HIP）を使用したセキュリティペイロード（ESP）輸送形式を使用して」、RFC 5202、2008年4月。
[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] Komu、M.、Henderson、T.、Tschofenig、H.、Melen、J。、およびA. Keranen、ed。、 "Networkアドレス翻訳者のトラバーサルの基本ホストIDプロトコル（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] Camarillo、G。およびJ. Melen、「ホストアイデンティティプロトコル（HIP）即時運送および上層プロトコルシグナル伝達（Hiccups）の輸送」、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、ed。、「The Secure Shell（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. Eggert、「ホストアイデンティティプロトコル（HIP）Rendezvous Extension」、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、「ホストIDプロトコル（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.、Henderson、T.、Ed。、Vogt、C.、およびJ. Arkko、「ホストIDプロトコルを使用したエンドホストモビリティとマルチホミング」、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] Henderson、T.、Nikander、P。、およびM. Komu、「ホストIDプロトコルをレガシーアプリケーションで使用」、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] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「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] Komu、M。およびT. Henderson、「ホストIDプロトコルの基本ソケットインターフェイス拡張（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] Rosenberg、J。、「Interactive Connectivity Indecivity（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] Jennings、C.、Lowekamp、B.、Ed。、Rescorla、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-Reload-Instance] Keranen、A.、Camarillo、G。、およびJ. Maenpaa、「ホストIDプロトコルベースのオーバーレイネットワーキング環境（HIP BONE）インスタンスリソースの場所と発見（リロード）の仕様」、進行中の作業、2011年1月。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Pekka Nikander Ericsson Hirsalantie 11 Jorvas 02420 Finland
Pekka Nikander Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Pekka.Nikander@ericsson.com
Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420 Finland
Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Jani.Hautakorpi@ericsson.com
Ari Keranen Ericsson Hirsalantie 11 Jorvas 02420 Finland
Ari Keranen Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Ari.Keranen@ericsson.com
Alan Johnston Avaya St. Louis, MO 63124
アラン・ジョンストン・アヴァヤ・セント・ルイス、ミズーリ州63124
EMail: alan.b.johnston@gmail.com