Network Working Group P. Nikander
Request for Comments: 5205 Ericsson Research NomadicLab
Category: Experimental J. Laganier
DoCoMo Euro-Labs
April 2008
Host Identity Protocol (HIP) Domain Name System (DNS) Extension
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Abstract
抽象
This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs).
この文書では、ドメインネームシステム（DNS）のための新しいリソースレコード（RR）を指定し、どのホスト識別プロトコル（HIP）でそれを使用します。このRRは、HIPノードがDNSにそのホストアイデンティティ（ノード公開鍵と秘密鍵のペアのHI、公共のコンポーネント）を保存することができますホストアイデンティティタグ（HIT、その公開鍵の切断されたハッシュ）、およびドメイン名のそのランデブーサーバ（RVSS）。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Simple Static Singly Homed End-Host . . . . . . . . . . . 5
3.2. Mobile end-host . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Using the DNS with HIP . . . . . . . . . . . . . . 8
4.1. Storing HI, HIT, and RVS in the DNS . . . . . . . . . . . 8
4.2. Initiating Connections Based on DNS Names . . . . . . . . 8
5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 9
5.1. HIT Length Format . . . . . . . . . . . . . . . . . . . . 9
5.2. PK Algorithm Format . . . . . . . . . . . . . . . . . . . 9
5.3. PK Length Format . . . . . . . . . . . . . . . . . . . . . 10
5.4. HIT Format . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Public Key Format . . . . . . . . . . . . . . . . . . . . 10
5.6. Rendezvous Servers Format . . . . . . . . . . . . . . . . 10
6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Attacker Tampering with an Insecure HIP RR . . . . . . . . 12
8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . . 13
8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative references . . . . . . . . . . . . . . . . . . . 14
11.2. Informative references . . . . . . . . . . . . . . . . . . 15
This document specifies a new resource record (RR) for the Domain Name System (DNS) [RFC1034], and how to use it with the Host Identity Protocol (HIP) [RFC5201]. This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its HI), and the Domain Names of its rendezvous servers (RVSs) [RFC5204].
この文書では、ドメインネームシステム（DNS）[RFC1034]のための新しいリソースレコード（RR）を指定し、どのホスト識別プロトコル（HIP）[RFC5201]でそれを使用します。このRRは、HIPノードがDNSにそのホストアイデンティティ（ノード公開鍵と秘密鍵のペアのHI、公共のコンポーネント）を保存することができますホストアイデンティティタグ（HIT、そのHIの切断されたハッシュ）、およびそののドメイン名ランデブーサーバ（RVSS）[RFC5204]。
Currently, most of the Internet applications that need to communicate with a remote host first translate a domain name (often obtained via user input) into one or more IP address(es). This step occurs prior to communication with the remote host, and relies on a DNS lookup.
現在、最初のリモートホストと通信し、ドメイン名を変換する必要があるインターネットアプリケーションのほとんどは、1つ以上のIPアドレス（複数可）に（多くの場合、ユーザ入力を介して取得しました）。この手順は、リモートホストとの通信に先立って発生し、DNSルックアップに依存しています。
With HIP, IP addresses are intended to be used mostly for on-the-wire communication between end hosts, while most Upper Layer Protocols (ULP) and applications use HIs or HITs instead (ICMP might be an example of an ULP not using them). Consequently, we need a means to translate a domain name into an HI. Using the DNS for this translation is pretty straightforward: We define a new HIP resource record. Upon query by an application or ULP for a name to IP address lookup, the resolver would then additionally perform a name to HI lookup, and use it to construct the resulting HI to IP address mapping (which is internal to the HIP layer). The HIP layer uses the HI to IP address mapping to translate HIs and HITs into IP addresses and vice versa.
最も上位層プロトコル（ULP）とアプリケーションが彼またはヒットを代わりに使用しながら、HIPを用いて、IPアドレスが、エンドホスト間のオン・ワイヤー通信のために主に使用されることが意図される（ICMPは、それらを使用しないULPの一例であるかもしれません） 。その結果、我々はHIに、ドメイン名を変換するための手段を必要としています。この変換のためにDNSを使用することは非常に簡単です：私たちは、新しいHIPリソースレコードを定義します。 IPアドレスルックアップの名前のためのアプリケーションまたはULPによって照会されると、リゾルバは、その後さらにHIルックアップに名前を行い、（HIP層の内部にある）IPアドレスへのマッピング結果のHIを構築するためにそれを使用するであろう。 HIP層は、IPアドレス、およびその逆に彼とヒットを変換するためにIPアドレスのマッピングにHIを使用しています。
The HIP Rendezvous Extension [RFC5204] allows a HIP node to be reached via the IP address(es) of a third party, the node's rendezvous server (RVS). An Initiator willing to establish a HIP association with a Responder served by an RVS would typically initiate a HIP exchange by sending an I1 towards the RVS IP address rather than towards the Responder IP address. Consequently, we need a means to find the name of a rendezvous server for a given host name.
HIPランデブー拡張[RFC5204] HIPノードは、第三者、ノードのランデブーサーバ（RVS）のIPアドレス（複数可）を介して到達することを可能にします。イニシエータRVSによって提供レスポンダとのHIPアソシエーションを確立するために喜んでは、一般的ではなくResponderのIPアドレスに向けたよりもRVS IPアドレスへのI1を送信することにより、HIP交換を開始します。その結果、我々は与えられたホスト名のランデブーサーバの名前を見つけるための手段を必要としています。
This document introduces the new HIP DNS resource record to store the Rendezvous Server (RVS), Host Identity (HI), and Host Identity Tag (HIT) information.
この文書では、ランデブーサーバ（RVS）、ホストアイデンティティ（HI）、およびホストアイデンティティタグ（HIT）の情報を格納するための新しいHIPのDNSリソースレコードを紹介します。
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]に記載されているように解釈されます。
In this section, we briefly introduce a number of usage scenarios where the DNS is useful with the Host Identity Protocol.
このセクションでは、我々は簡単にDNSは、ホストアイデンティティプロトコルで有用である使用シナリオの数を紹介します。
With HIP, most applications and ULPs are unaware of the IP addresses used to carry packets on the wire. Consequently, a HIP node could take advantage of having multiple IP addresses for fail-over, redundancy, mobility, or renumbering, in a manner that is transparent to most ULPs and applications (because they are bound to HIs; hence, they are agnostic to these IP address changes).
HIPでは、ほとんどのアプリケーションとのULPは、ワイヤ上のパケットを運ぶために使用されるIPアドレスを知りません。その結果、HIPノードがフェイルオーバー用に複数のIPアドレスを持つの利点を取ることができ、冗長性、移動性、またはリナンバリング、彼らは彼にバインドされているので、（ほとんどのULPやアプリケーションに透過的な方法で、それゆえ、彼らはにとらわれませんこれらのIPアドレスの変更）。
In these situations, for a node to be reachable by reference to its Fully Qualified Domain Name (FQDN), the following information should be stored in the DNS:
これらの状況では、完全修飾ドメイン名（FQDN）を参照することによって到達するノードのために、次の情報がDNSに格納されるべきです。
o A set of IP address(es) via A [RFC1035] and AAAA [RFC3596] RR sets (RRSets [RFC2181]).
O [RFC1035]を介してIPアドレス（ES）とAAAA [RFC3596] RRセットの組（資源レコード集合[RFC2181]）。
o A Host Identity (HI), Host Identity Tag (HIT), and possibly a set of rendezvous servers (RVS) through HIP RRs.
Oホストアイデンティティ（HI）、ホストアイデンティティタグ（HIT）、そしておそらくHIPのRRを通じランデブーサーバ（RVS）のセット。
When a HIP node wants to initiate communication with another HIP node, it first needs to perform a HIP base exchange to set up a HIP association towards its peer. Although such an exchange can be initiated opportunistically, i.e., without prior knowledge of the Responder's HI, by doing so both nodes knowingly risk man-in-the-middle attacks on the HIP exchange. To prevent these attacks, it is recommended that the Initiator first obtain the HI of the Responder, and then initiate the exchange. This can be done, for example, through manual configuration or DNS lookups. Hence, a new HIP RR is introduced.
HIPノードが別のHIPノードとの通信を開始したいとき、それは最初のピアに向かってHIPアソシエーションを設定するためにHIP基本交換を行う必要があります。そのような交換はとてもHIP交換の両方のノード故意に危険man-in-the-middle攻撃を行うことによって、レスポンダのHIの予備知識なしに、すなわち、日和見開始することができますが。これらの攻撃を防ぐためには、イニシエータは、ファーストレスポンダのHIを取得した後、交換を開始することをお勧めします。これは、手動設定またはDNSルックアップを通じて、例えば、行うことができます。したがって、新しいHIPのRRが導入されます。
When a HIP node is frequently changing its IP address(es), the natural DNS latency for propagating changes may prevent it from publishing its new IP address(es) in the DNS. For solving this problem, the HIP Architecture [RFC4423] introduces rendezvous servers (RVSs) [RFC5204]. A HIP host uses a rendezvous server as a rendezvous point to maintain reachability with possible HIP initiators while moving [RFC5206]. Such a HIP node would publish in the DNS its RVS domain name(s) in a HIP RR, while keeping its RVS up-to-date with its current set of IP addresses.
HIPノードはしばしば、そのIPアドレスを変更したとき、変更を伝播するための天然のDNS待ち時間はDNSで新しいIPアドレスを公開することを防ぐことができます。この問題を解決するために、HIPアーキテクチャ[RFC4423]はランデブーサーバ（RVSS）[RFC5204]を紹介します。 HIPホストは、[RFC5206]を移動しながら可能HIP開始剤との到達可能性を維持するために、ランデブーポイントとしてランデブーサーバを使用します。 IPアドレスの現在のセットで最新のRVSを維持しながら、このようなHIPノードは、HIPのRRにDNSにそのRVSドメイン名（複数可）を発行します。
When a HIP node wants to initiate a HIP exchange with a Responder, it will perform a number of DNS lookups. Depending on the type of implementation, the order in which those lookups will be issued may vary. For instance, implementations using HIT in APIs may typically first query for HIP resource records at the Responder FQDN, while those using an IP address in APIs may typically first query for A and/or AAAA resource records.
HIPノードはレスポンダとHIP交換を開始したい場合は、DNSルックアップの数を実行します。実装の種類に応じて、これらのルックアップが発行される順序が異なる場合があります。例えば、APIの中にHITを使用して実装では、レスポンダFQDNでHIPリソースレコードに関する通常、最初問い合わせることができるAPIの内のIPアドレスを使用するものは、典型的には、第1のAのクエリおよび/またはAAAAリソース・レコードを得ます。
In the following, we assume that the Initiator first queries for HIP resource records at the Responder FQDN.
以下では、レスポンダFQDNでHIPリソースレコードのイニシエータ最初のクエリと仮定します。
If the query for the HIP type was responded to with a DNS answer with RCODE=3 (Name Error), then the Responder's information is not present in the DNS and further queries for the same owner name SHOULD NOT be made.
HIPの種類のクエリがRCODE = 3（名エラー）を持つDNS応答で応答している場合、レスポンダの情報は、DNSに存在しないと同じ所有者名のための更なるクエリは行うべきではありません。
In case the query for the HIP records returned a DNS answer with RCODE=0 (No Error) and an empty answer section, it means that no HIP information is available at the responder name. In such a case, if the Initiator has been configured with a policy to fallback to opportunistic HIP (initiating without knowing the Responder's HI) or plain IP, it would send out more queries for A and AAAA types at the Responder's FQDN.
場合HIPレコードのクエリがRCODE = 0（エラーなし）と空の応答セクションでDNSの応答を返され、それはHIP情報は、応答者名で利用できないことを意味します。イニシエータは、日和見HIP（レスポンダのHIを知らずに開始）またはプレーンIPにフォールバックするポリシーで構成されている場合、このような場合には、それはレスポンダのFQDNのAとAAAAタイプのためのより多くのクエリを送信します。
Depending on the combinations of answers, the situations described in Section 3.1 and Section 3.2 can occur.
回答の組み合わせによっては、3.1節と3.2節で述べたような状況が発生する可能性があります。
Note that storing HIP RR information in the DNS at an FQDN that is assigned to a non-HIP node might have ill effects on its reachability by HIP nodes.
非HIPノードに割り当てられているFQDNでDNSにおけるHIPのRR情報を格納するとHIPノードによってその到達可能性に悪影響があるかもしれないことに注意してください。
A HIP node (R) with a single static network attachment, wishing to be reachable by reference to its FQDN (www.example.com), would store in the DNS, in addition to its IP address(es) (IP-R), its Host Identity (HI-R) and Host Identity Tag (HIT-R) in a HIP resource record.
そのFQDN（www.example.com）を参照することによって到達されることを望むものでは単一の静的ネットワーク接続とHIPノード（R）は、そのIPアドレス（ES）（IP-R）に加えて、DNSに格納することになりますHIPリソースレコードでは、そのホストアイデンティティ（HI-R）とホストアイデンティティタグ（HIT-R）。
An Initiator willing to associate with a node would typically issue the following queries:
イニシエータノードに関連付けるために喜んでは、代表的には、以下のクエリを発行します。
o QNAME=www.example.com, QTYPE=HIP
O QNAME = www.example.com、QTYPE = HIP
o (QCLASS=IN is assumed and omitted from the examples)
O（QCLASS = INが仮定及び実施例から省略されています）
Which returns a DNS packet with RCODE=0 and one or more HIP RRs with the HIT and HI (e.g., HIT-R and HI-R) of the Responder in the answer section, but no RVS.
これRCODEとDNSパケットは= 0及び1つ以上のHIP回答セクションのレスポンダのHITおよびHI（例えば、HIT-R及びHI-R）とのRR、ないRVS返します。
o QNAME=www.example.com, QTYPE=A QNAME=www.example.com, QTYPE=AAAA
O QNAME = www.example.com、QTYPE = A QNAME = www.example.com、QTYPE = AAAA
Which returns DNS packets with RCODE=0 and one or more A or AAAA RRs containing IP address(es) of the Responder (e.g., IP-R) in the answer section.
どの回答セクションに= 0および1つまたは複数のA RCODEまたはレスポンダのIPアドレスを含むAAAA資源レコード（例えば、IP-R）を用いてDNSパケットを返します。
Caption: In the remainder of this document, for the sake of keeping diagrams simple and concise, several DNS queries and answers are represented as one single transaction, while in fact there are several queries and answers flowing back and forth, as described in the textual examples.
キャプション：実際には前後に流れる複数の問合せと回答がありますが、テキストで説明したように、このドキュメントの残りの部分では、シンプルで簡潔な図を維持するために、いくつかのDNSクエリおよび回答は、1つのトランザクションとして表現されています例。
[HIP? A? ]
[www.example.com] +-----+
+-------------------------------->| |
| | DNS |
| +-------------------------------| |
| | [HIP? A? ] +-----+
| | [www.example.com]
| | [HIP HIT-R HI-R ]
| | [A IP-R ]
| v
+-----+ +-----+
| |--------------I1------------->| |
| I |<-------------R1--------------| R |
| |--------------I2------------->| |
| |<-------------R2--------------| |
+-----+ +-----+
Static Singly Homed Host
静的片方向ホームホスト
The Initiator would then send an I1 to the Responder's IP addresses (IP-R).
イニシエータは、レスポンダのIPアドレス（IP-R）にI1を送信します。
A mobile HIP node (R) wishing to be reachable by reference to its FQDN (www.example.com) would store in the DNS, possibly in addition to its IP address(es) (IP-R), its HI (HI-R), HIT (HIT-R), and the domain name(s) of its rendezvous server(s) (e.g., rvs.example.com) in HIP resource record(s). The mobile HIP node also needs to notify its rendezvous servers of any change in its set of IP address(es).
そのFQDN（www.example.com）を参照することによって到達されることを望むものではモバイルHIPノード（R）は、HI（HI-、恐らくはそのIPアドレス（ES）（IP-R）に加えて、DNSに格納することになりますHIPリソースレコード（複数可）中R）、HIT（HIT-R）、およびそのランデブーサーバのドメイン名（S）（S）（例えば、rvs.example.com）。モバイルHIPノードは、IPアドレス（複数可）のセットに変更がそのランデブーサーバに通知する必要があります。
An Initiator willing to associate with such a mobile node would typically issue the following queries:
イニシエータモバイルノードに関連付けるために喜んでは、代表的には、以下のクエリを発行します。
o QNAME=www.example.com, QTYPE=HIP
O QNAME = www.example.com、QTYPE = HIP
Which returns a DNS packet with RCODE=0 and one or more HIP RRs with the HIT, HI, and RVS domain name(s) (e.g., HIT-R, HI-R, and rvs.example.com) of the Responder in the answer section.
これはHI、HITとRCODE = 0と1つ以上のHIPのRRとDNSパケットを返し、RVSドメイン名（複数可）（例えば、HI-R、およびrvs.example.com-Rを打つ）レスポンダでの回答セクション。
o QNAME=rvs.example.com, QTYPE=A QNAME=www.example.com, QTYPE=AAAA
O QNAME = rvs.example.com、QTYPE = A QNAME = www.example.com、QTYPE = AAAA
Which returns DNS packets with RCODE=0 and one or more A or AAAA RRs containing IP address(es) of the Responder's RVS (e.g., IP-RVS) in the answer section.
これはRCODE = 0及び1つ以上のAまたは回答セクションのレスポンダのRVS（例えば、IP-RVS）のIPアドレスを含むAAAA資源レコードとDNSパケットを返します。
[HIP? ]
[www.example.com]
[A? ]
[rvs.example.com] +-----+
+----------------------------------------->| |
| | DNS |
| +----------------------------------------| |
| | [HIP? ] +-----+
| | [www.example.com ]
| | [HIP HIT-R HI-R rvs.example.com]
| |
| | [A? ]
| | [rvs.example.com]
| | [A IP-RVS ]
| |
| | +-----+
| | +------I1----->| RVS |-----I1------+
| | | +-----+ |
| | | |
| | | |
| v | v
+-----+ +-----+
| |<---------------R1------------| |
| I |----------------I2----------->| R |
| |<---------------R2------------| |
+-----+ +-----+
Mobile End-Host
モバイルエンドホスト
The Initiator would then send an I1 to the RVS IP address (IP-RVS). Following, the RVS will relay the I1 up to the mobile node's IP address (IP-R), which will complete the HIP exchange.
イニシエータは、RVS IPアドレス（IP-RVS）にI1を送信します。続いて、RVSは、HIP交換を完了される、モバイルノードのIPアドレス（IP-R）にI1を中継します。
For any HIP node, its Host Identity (HI), the associated Host Identity Tag (HIT), and the FQDN of its possible RVSs can be stored in a DNS HIP RR. Any conforming implementation may store a Host Identity (HI) and its associated Host Identity Tag (HIT) in a DNS HIP RDATA format. HI and HIT are defined in Section 3 of the HIP specification [RFC5201].
任意HIPノード、そのホストアイデンティティ（HI）のために、関連するホストアイデンティティタグ（HIT）、及びその可能RVSSのFQDNがDNS股関節RRに格納することができます。任意の適合する実装は、DNS HIP RDATA形式でホストアイデンティティ（HI）とその関連するホストアイデンティティタグ（HIT）を格納することができます。 HI及びHITはHIP仕様[RFC5201]のセクション3で定義されています。
Upon return of a HIP RR, a host MUST always calculate the HI-derivative HIT to be used in the HIP exchange, as specified in Section 3 of the HIP specification [RFC5201], while the HIT possibly embedded along SHOULD only be used as an optimization (e.g., table lookup).
おそらくに沿って埋め込まれたHITのみとして使用されるべきであるHIP RRの復帰時に、HIP仕様のセクション3で指定されるように、ホストは常に、HIP交換で使用するHI-誘導体HITを計算しなければならない[RFC5201]最適化（例えば、テーブルルックアップ）。
The HIP resource record may also contain one or more domain name(s) of rendezvous server(s) towards which HIP I1 packets might be sent to trigger the establishment of an association with the entity named by this resource record [RFC5204].
HIPリソースレコードはまた、HIPのI1パケットがこのリソースレコード[RFC5204]によって指定されたエンティティとの関連付けの確立をトリガするために送信されるかもしれない向かっランデブーサーバ（複数可）の1つ以上のドメイン名（複数可）を含有していてもよいです。
The rendezvous server field of the HIP resource record stored at a given owner name MAY include the owner name itself. A semantically equivalent situation occurs if no rendezvous server is present in the HIP resource record stored at that owner name. Such situations occur in two cases:
指定された所有者名で保存されたHIPリソースレコードのランデブーサーバフィールドには、所有者名そのものを含むかもしれません。何のランデブーサーバがその所有者名で保存されたHIPリソースレコードに存在しない場合は、意味的に等価な状況が発生します。このような状況では、2つの場合に発生します。
o The host is mobile, and the A and/or AAAA resource record(s) stored at its host name contain the IP address(es) of its rendezvous server rather than its own one.
Oホストはモバイルであり、そのホスト名に格納されているA及び/又はAAAAリソース・レコード（複数可）は、ランデブー・サーバではなく、自身の一方のIPアドレスを含みます。
o The host is stationary, and can be reached directly at the IP address(es) contained in the A and/or AAAA resource record(s) stored at its host name. This is a degenerated case of rendezvous service where the host somewhat acts as a rendezvous server for itself.
ホストoを静止して、そのホスト名に格納されているA及び/又はAAAAリソース・レコード（単数または複数）に含まれるIPアドレス（複数可）に直接到達することができます。これは、ホストがやや自体のランデブーサーバとして機能ランデブサービスの縮退ケースです。
An RVS receiving such an I1 would then relay it to the appropriate Responder (the owner of the I1 receiver HIT). The Responder will then complete the exchange with the Initiator, typically without ongoing help from the RVS.
そのようなI1を受信RVSは、適切なレスポンダ（I1受信HITの所有者）にそれを中継することになります。 Responderは、その後、通常RVSからの継続的な助けを借りずに、イニシエータとの交換を完了します。
On a HIP node, a Host Identity Protocol exchange SHOULD be initiated whenever a ULP attempts to communicate with an entity and the DNS lookup returns HIP resource records.
HIPノードで、ホスト識別プロトコル交換はULPは、エンティティと通信しようとしたときに開始すべきであるとDNSルックアップがHIPリソースレコードを返します。
The RDATA for a HIP RR consists of a public key algorithm type, the HIT length, a HIT, a public key, and optionally one or more rendezvous server(s).
HIPのRRのためのRDATAは、公開鍵アルゴリズムタイプ、HIT長、HIT、公開鍵、および任意選択で1つのまたは複数のランデブーサーバ（群）から構成されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HIT length | PK algorithm | PK length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ HIT ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+ +
| Public Key |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Rendezvous Servers ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+
The HIT length, PK algorithm, PK length, HIT, and Public Key fields are REQUIRED. The Rendezvous Servers field is OPTIONAL.
HIT長、PKアルゴリズム、PKの長さ、HIT、および公開キーフィールドが必要です。ランデブーサーバフィールドはオプションです。
The HIT length indicates the length in bytes of the HIT field. This is an 8-bit unsigned integer.
HITの長さはHITフィールドのバイト長を示します。これは、8ビットの符号なし整数です。
The PK algorithm field indicates the public key cryptographic algorithm and the implied public key field format. This is an 8-bit unsigned integer. This document reuses the values defined for the 'algorithm type' of the IPSECKEY RR [RFC4025].
PKアルゴリズムフィールドは、公開鍵暗号アルゴリズムと暗黙の公開鍵フィールドの形式を示します。これは、8ビットの符号なし整数です。この文書では、IPSECKEY RR [RFC4025]の「アルゴリズムタイプ」に対して定義された値を再利用します。
Presently defined values are listed in Section 9 for reference.
現在定義された値は、参考のために、セクション9に記載されています。
The PK length indicates the length in bytes of the Public key field. This is a 16-bit unsigned integer in network byte order.
PKの長さは、公開キーフィールドの長さをバイト単位で示します。これは、ネットワークバイト順で16ビットの符号なし整数です。
The HIT is stored as a binary value in network byte order.
HITは、ネットワークバイト順でバイナリ値として記憶されます。
Both of the public key types defined in this document (RSA and DSA) reuse the public key formats defined for the IPSECKEY RR [RFC4025].
この文書で定義された公開鍵タイプ（RSAやDSA）の両方がIPSECKEY RR [RFC4025]のために定義された公開鍵のフォーマットを再利用します。
The DSA key format is defined in RFC 2536 [RFC2536].
DSAキーフォーマットは、RFC 2536 [RFC2536]で定義されています。
The RSA key format is defined in RFC 3110 [RFC3110] and the RSA key size limit (4096 bits) is relaxed in the IPSECKEY RR [RFC4025] specification.
RSA鍵のフォーマットは、RFC 3110で定義されている[RFC3110]とRSA鍵サイズ制限（4096ビット）IPSECKEY RR [RFC4025]書で緩和されます。
The Rendezvous Servers field indicates one or more variable length wire-encoded domain names of rendezvous server(s), as described in Section 3.3 of RFC 1035 [RFC1035]. The wire-encoded format is self-describing, so the length is implicit. The domain names MUST NOT be compressed. The rendezvous server(s) are listed in order of preference (i.e., first rendezvous server(s) are preferred), defining an implicit order amongst rendezvous servers of a single RR. When multiple HIP RRs are present at the same owner name, this implicit order of rendezvous servers within an RR MUST NOT be used to infer a preference order between rendezvous servers stored in different RRs.
RFC 1035 [RFC1035]のセクション3.3に記載されているようにランデブーサーバフィールドは、ランデブーサーバ（群）の一つ以上の可変長ワイヤーエンコードドメイン名を示しています。ワイヤエンコード形式は、自己記述型であるので、長さは、暗黙的です。ドメイン名は圧縮されてはなりません。ランデブーサーバ（S）は優先順にリストされている（すなわち、最初のランデブーサーバ（複数可）が好ましい）、単RRのランデブーサーバの間で暗黙の順序を定義します。複数のHIPのRRが同じ所有者名に存在する場合、RR内のランデブーサーバのこの暗黙の順序が異なる資源レコードに格納されたランデブーサーバ間の優先順位を推測するために使用してはいけません。
This section specifies the representation of the HIP RR in a zone master file.
このセクションでは、ゾーンのマスターファイル内のHIP RRの表現を指定します。
The HIT length field is not represented, as it is implicitly known thanks to the HIT field representation.
それは暗黙的にHITフィールド表現のおかげで知られているようにHIT長フィールドは、表現されていません。
The PK algorithm field is represented as unsigned integers.
PKアルゴリズムフィールドは符号なし整数として表現されます。
The HIT field is represented as the Base16 encoding [RFC4648] (a.k.a. hex or hexadecimal) of the HIT. The encoding MUST NOT contain whitespaces to distinguish it from the public key field.
HITフィールドはHITのBase16符号化[RFC4648]（別名進数または16進数）として表されます。エンコーディングは、公開鍵フィールドからそれを区別するために空白を含めることはできません。
The Public Key field is represented as the Base64 encoding [RFC4648] of the public key. The encoding MUST NOT contain whitespace(s) to distinguish it from the Rendezvous Servers field.
公開鍵フィールドは、公開鍵のBase64エンコーディング[RFC4648]のように表されます。エンコードは、ランデブーサーバフィールドからそれを区別するために空白文字（複数可）を含めることはできません。
The PK length field is not represented, as it is implicitly known thanks to the Public key field representation containing no whitespaces.
それは暗黙のうちに何の空白を含まない公開鍵フィールド表現のおかげで知られているようにPKの長さフィールドは、表現されていません。
The Rendezvous Servers field is represented by one or more domain name(s) separated by whitespace(s).
ランデブーサーバフィールドは空白（単数または複数）によって分離された1つ以上のドメイン名（S）で表されます。
The complete representation of the HPIHI record is:
HPIHIレコードの完全な表現は次のとおりです。
IN HIP ( pk-algorithm base16-encoded-hit base64-encoded-public-key rendezvous-server[1] ... rendezvous-server[n] )
HIP IN（PK-アルゴリズムbase16エンコードされたヒットbase64エンコード-公開鍵ランデブーサーバ[1] ...ランデブー・サーバー[N]）
When no RVSs are present, the representation of the HPIHI record is:
何RVSSが存在しない場合は、HPIHIレコードの表現は次のとおりです。
IN HIP ( pk-algorithm base16-encoded-hit base64-encoded-public-key )
HIP IN（PK-アルゴリズムbase16エンコードされたヒットbase64エンコード-公開鍵）
In the examples below, the public key field containing no whitespace is wrapped since it does not fit in a single line of this document.
それは、このドキュメントの一行に収まらないので、以下の例では、何の空白を含まない公開鍵フィールドが包まれます。
Example of a node with HI and HIT but no RVS:
HIとHITが、無RVSを持つノードの例：
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p 9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D )
www.example.com。 HIP（2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p 9 + LrV4e19WzK00 + CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu + Upr1gsNrut79ryra + bSRGQ b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D）
Example of a node with a HI, HIT, and one RVS:
HI、HIT、一のRVS持つノードの例：
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p 9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D rvs.example.com. )
www.example.com。 HIP（2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p 9 + LrV4e19WzK00 + CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu + Upr1gsNrut79ryra + bSRGQ b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D rvs.example.com。）
Example of a node with a HI, HIT, and two RVSs:
HI、HIT、二つRVSSを持つノードの例：
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p 9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D rvs1.example.com. rvs2.example.com. )
www.example.com。 HIP（2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p 9 + LrV4e19WzK00 + CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu + Upr1gsNrut79ryra + bSRGQ b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D rvs1.example.com。rvs2.example.com。）
This section contains a description of the known threats involved with the usage of the HIP DNS Extension.
このセクションでは、HIPのDNS拡張の使用に関わる既知の脅威の記述が含まれています。
In a manner similar to the IPSECKEY RR [RFC4025], the HIP DNS Extension allows for the provision of two HIP nodes with the public keying material (HI) of their peer. These HIs will be subsequently used in a key exchange between the peers. Hence, the HIP DNS Extension introduces the same kind of threats that IPSECKEY does, plus threats caused by the possibility given to a HIP node to initiate or accept a HIP exchange using "opportunistic" or "unpublished Initiator HI" modes.
IPSECKEY RR [RFC4025]と同様に、HIP DNS拡張は、それらのピアの公開鍵材料（HI）を有する2つのHIPノードの提供を可能にします。これらの彼はその後、ピア間で鍵交換に使用されます。したがって、HIP DNS拡張はIPSECKEYがない脅威の同じ種類を紹介し、プラス「日和見」または「未発表イニシエータHI」モードを使用して、HIP交換を開始または受け入れるようにHIPノードに与えられた可能性に起因する脅威。
A HIP node SHOULD obtain HIP RRs from a trusted party trough a secure channel ensuring data integrity and authenticity of the RRs. DNSSEC [RFC4033] [RFC4034] [RFC4035] provides such a secure channel. However, it should be emphasized that DNSSEC only offers data integrity and authenticity guarantees to the channel between the DNS server publishing a zone and the HIP node. DNSSEC does not ensure that the entity publishing the zone is trusted. Therefore, the RRSIG signature of the HIP RRSet MUST NOT be misinterpreted as a certificate binding the HI and/or the HIT to the owner name.
HIPノードはRRのデータの整合性と信頼性を確保する安全なチャネルの谷、信頼できる相手からのHIPのRRを取得する必要があります。 DNSSEC [RFC4033]、[RFC4034]、[RFC4035]は、そのような安全なチャネルを提供します。しかし、DNSSECが唯一のゾーンとHIPノードを公開DNSサーバとの間のチャネルにデータの整合性と信頼性の保証を提供していますことを強調すべきです。 DNSSECはゾーンを公開エンティティが信頼されていることを確認しません。したがって、HIPの資源レコード集合のRRSIG署名はHIおよび/または所有者名のHITを結合する証明書として誤って解釈されてはいけません。
In the absence of a proper secure channel, both parties are vulnerable to MitM and DoS attacks, and unrelated parties might be subject to DoS attacks as well. These threats are described in the following sections.
適切な安全なチャネルがない場合には、両当事者はのMitMとのDoS攻撃に対して脆弱であり、無関係の当事者は、同様にDoS攻撃を受ける可能性があります。これらの脅威は、次のセクションで説明されています。
The HIP RR contains public keying material in the form of the named peer's public key (the HI) and its secure hash (the HIT). Both of these are not sensitive to attacks where an adversary gains knowledge of them. However, an attacker that is able to mount an active attack on the DNS, i.e., tampers with this HIP RR (e.g., using DNS spoofing), is able to mount Man-in-the-Middle attacks on the cryptographic core of the eventual HIP exchange (Responder's HIP RR rewritten by the attacker).
HIPのRRは、名前のピアの公開鍵（HI）とその安全なハッシュ（HIT）の形で公共キーイング材料が含まれています。これらの両方は、敵がそれらの知識を獲得する攻撃に敏感ではありません。しかし、DNSの積極的な攻撃をマウントすることができ、攻撃者は、すなわち、このHIPのRRを改ざん（例えば、DNSスプーフィングを使用して）、最終的に暗号化コア上でman-in-the-middle攻撃をマウントすることができますHIP交換（攻撃者によって書き換えられたレスポンダのHIPのRR）。
The HIP RR may contain a rendezvous server domain name resolved into a destination IP address where the named peer is reachable by an I1, as per the HIP Rendezvous Extension [RFC5204]. Thus, an attacker able to tamper with this RR is able to redirect I1 packets sent to the named peer to a chosen IP address for DoS or MitM attacks. Note that this kind of attack is not specific to HIP and exists independently of whether or not HIP and the HIP RR are used. Such an attacker might tamper with A and AAAA RRs as well.
HIPのRRは、宛先IPアドレスに解決ランデブーサーバのドメイン名を含んでいてもよいという名前のピアは、HIPランデブー拡張[RFC5204]に従って、I1によって到達可能です。したがって、このRRを改ざんすることができ、攻撃者は、DOSまたはのMitM攻撃のために選択されたIPアドレスに名前のピアに送信されたI1パケットをリダイレクトすることが可能です。この種の攻撃は、HIPに特異的ではなく、独立して、HIP及びHIPのRRが使用されているか否かの存在することに留意されたいです。このような攻撃者は、同様にAとAAAAのRRを改ざんすることがあります。
An attacker might obviously use these two attacks in conjunction: It will replace the Responder's HI and RVS IP address by its own in a spoofed DNS packet sent to the Initiator HI, then redirect all exchanged packets to him and mount a MitM on HIP. In this case, HIP won't provide confidentiality nor Initiator HI protection from eavesdroppers.
その後、彼にすべて交換されるパケットをリダイレクトそれは、イニシエータHIに送信された偽装されたDNSパケットに、独自でレスポンダのHIとRVS IPアドレスを交換し、HIP上のMitMマウント：攻撃者が明らかに一緒にこれら二つの攻撃を使用する場合があります。この場合、HIPは、盗聴者からの機密性やイニシエータHI保護を提供することはありません。
As with many cryptographic algorithms, some secure hashes (e.g., SHA1, used by HIP to generate a HIT from an HI) eventually become insecure, because an exploit has been found in which an attacker with reasonable computation power breaks one of the security features of the hash (e.g., its supposed collision resistance). This is why a HIP end-node implementation SHOULD NOT authenticate its HIP peers based solely on a HIT retrieved from the DNS, but SHOULD rather use HI-based authentication.
多くの暗号化アルゴリズムと同様に、いくつかの安全なハッシュ（例えば、HIからHITを生成するためにHIPによって使用されるSHA1は、）最終的に安全でないとなり、合理的な計算能力を持つ攻撃者がのセキュリティ機能の一つを破るているが発見されたエクスプロイトので、ハッシュ（例えば、そのはず衝突耐性）。 HIPエンドノード実装はDNSから取得したHITのみに基づいてそのHIPピアを認証するべきではなく、HI-ベースの認証を使用する必要があります理由です。
In the absence of DNSSEC, the HIP RR is subject to the threats described in RFC 3833 [RFC3833].
DNSSECの非存在下で、HIPのRRは、RFC 3833 [RFC3833]に記載された脅威にさらされます。
IANA has allocated one new RR type code (55) for the HIP RR from the standard RR type space.
IANAは、標準のRRタイプ空間からHIPのRRのための1つの新しいRRタイプコード（55）を割り当てています。
IANA does not need to open a new registry for public key algorithms of the HIP RR because the HIP RR reuses "algorithms types" defined for the IPSECKEY RR [RFC4025]. Presently defined values are shown here for reference only:
IANAは、HIP RRはIPSECKEY RR [RFC4025]のために定義された「アルゴリズムの種類を」再利用するためのHIP RRの公開鍵アルゴリズムのための新しいレジストリを開く必要はありません。現在定義された値はあくまで参考のためにここに表示されます：
0 is reserved
0が予約されています
1 is DSA
図1は、DSAです
2 is RSA
図2は、RSAです
In the future, if a new algorithm is to be used for the HIP RR, a new algorithm type and corresponding public key encoding should be defined for the IPSECKEY RR. The HIP RR should reuse both the same algorithm type and the same corresponding public key format as the IPSECKEY RR.
新しいアルゴリズムはHIPのRRのために使用される場合、将来的に、新しいアルゴリズムの種類と対応する公開鍵エンコーディングはIPSECKEY RRのために定義されるべきです。 HIP RRは同じアルゴリズムタイプとIPSECKEY RRと同じ対応する公開鍵形式の両方を再利用しなければなりません。
As usual in the IETF, this document is the result of a collaboration between many people. The authors would like to thank the author (Michael Richardson), contributors, and reviewers of the IPSECKEY RR [RFC4025] specification, after which this document was framed. The authors would also like to thank the following people, who have provided thoughtful and helpful discussions and/or suggestions, that have helped improve this document: Jeff Ahrenholz, Rob Austein, Hannu Flinck, Olafur Gudmundsson, Tom Henderson, Peter Koch, Olaf Kolkman, Miika Komu, Andrew McGregor, Erik Nordmark, and Gabriel Montenegro. Some parts of this document stem from the HIP specification [RFC5201].
IETFでいつものように、このドキュメントは、多くの人々の間のコラボレーションの結果です。著者は、著者（マイケル・リチャードソン）は、この文書が額装された後IPSECKEY RR [RFC4025]仕様の、貢献者、および査読に感謝したいと思います。ジェフAhrenholz、ロブAusteinと、ハンヌ・フリンク、オラフルグドムンソン、トム・ヘンダーソン、ピーター・コッホ、オラフKolkman：著者らはまた、この文書を改善する助けた思慮深く、有用な議論、および/または提案を、提供した以下の方々に、感謝したいと思います、Miikaこむ、アンドリュー・マクレガー、エリックNordmarkと、とガブリエルモンテネグロ。 HIP仕様[RFC5201]からこの文書ステムのいくつかの部分。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[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月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
"DNS仕様の明確化" [RFC2181]エルツ、R.とR.ブッシュ、RFC 2181、1997年7月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596]トムソン、S.、のHuitema、C.、Ksinant、V.、およびM. Souissi、RFC 3596、2003年10月 "DNSの拡張機能は、IPバージョン6をサポートします"。
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, March 2005.
[RFC4025]リチャードソン、M.、 "DNSでの保管のIPsec鍵材料のための方法"、RFC 4025、2005年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張機能のためのリソースレコード"、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 4648、2006年10月。
[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月。
[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月。
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999.
[RFC2536]イーストレイク、D.、 "DSA鍵とドメインネームシステム（DNS）でのSIG"、RFC 2536、1999年3月。
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001.
[RFC3110]イーストレーク、D.、 "ドメインネームシステムにおけるRSA / SHA-1のSIGとRSA鍵（DNS）"、RFC 3110、2001年5月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833]アトキンス、D.とR. Austeinと、RFC 3833 "ドメインネームシステム（DNS）の脅威分析"、2004年8月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]モスコウィッツ、R.とP. Nikander、 "ホストアイデンティティプロトコル（HIP）アーキテクチャ"、RFC 4423、2006年5月。
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206]ヘンダーソン、T.、エド。、「エンドホストモビリティとマルチホーミングをホストアイデンティティプロトコルで」、RFC 5206、2008年4月。
Authors' Addresses
著者のアドレス
Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
ペッカNikanderエリクソン研究NomadicLab JORVAS FIN-02420フィンランド
Phone: +358 9 299 1 EMail: pekka.nikander@nomadiclab.com
電話：+358 9 299 1 Eメール：pekka.nikander@nomadiclab.com
Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany
ジュリアンLAGANIERドコモコミュニケーション研究所ヨーロッパ社ランデスシュトラーセ312 80687ミュンヘンドイツ
Phone: +49 89 56824 231 EMail: julien.ietf@laposte.net URI: http://www.docomolab-euro.com/
電話：+49 89 56824 231 Eメール：julien.ietf@laposte.net URI：http://www.docomolab-euro.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。