[要約] RFC 8005は、Host Identity Protocol（HIP）におけるDomain Name System（DNS）の拡張に関するものであり、HIPとDNSの統合を目的としています。HIPを使用してホストの識別情報を保護し、セキュリティとプライバシーを向上させるために、DNSへの拡張が提案されています。
Internet Engineering Task Force (IETF) J. Laganier
Request for Comments: 8005 Luminate Wireless, Inc.
Obsoletes: 5205 October 2016
Category: Standards Track
ISSN: 2070-1721
Host Identity Protocol (HIP) Domain Name System (DNS) Extension
ホストアイデンティティプロトコル（HIP）ドメインネームシステム（DNS）拡張
Abstract
概要
This document specifies a 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; its Host Identity Tag (HIT), a truncated hash of its public key (PK); and the domain names of its rendezvous servers (RVSs). This document obsoletes RFC 5205.
このドキュメントでは、ドメインネームシステム（DNS）のリソースレコード（RR）と、ホストアイデンティティプロトコル（HIP）でそれを使用する方法について説明します。このRRにより、HIPノードはDNSにそのホストID（HI）を格納できます。これは、ノードの公開鍵と秘密鍵のペアの公開コンポーネントです。ホストIDタグ（HIT）、公開鍵（PK）の切り捨てられたハッシュ。ランデブーサーバー（RVS）のドメイン名。このドキュメントはRFC 5205を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8005.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8005で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Simple Static Single-Homed End Host . . . . . . . . . . . 5
3.2. Mobile End Host . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Using the DNS with HIP . . . . . . . . . . . . . 7
4.1. Storing HI, HIT, and RVS in the DNS . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . 11
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Attacker Tampering with an Insecure HIP RR . . . . . . . 13
8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . 13
8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Changes from RFC 5205 . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
This document specifies a resource record (RR) for the Domain Name System (DNS) [RFC1034] and how to use it with the Host Identity Protocol (HIP) [RFC7401]. 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; its Host Identity Tag (HIT), a truncated hash of its HI; and the domain names of its rendezvous servers (RVSs) [RFC8004].
このドキュメントでは、ドメインネームシステム（DNS）[RFC1034]のリソースレコード（RR）と、それをホストアイデンティティプロトコル（HIP）[RFC7401]で使用する方法を指定します。このRRにより、HIPノードはDNSにそのホストID（HI）を格納できます。これは、ノードの公開鍵と秘密鍵のペアの公開コンポーネントです。ホストアイデンティティタグ（HIT）、そのHIの切り捨てられたハッシュ。ランデブーサーバー（RVS）のドメイン名[RFC8004]。
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 addresses. 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 (ULPs) and applications use HIs or HITs instead (ICMP might be an example of a 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 HIP RR. 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）とアプリケーションはHIまたはHITを代わりに使用します（ICMPはULPを使用しない例の1つかもしれません）。 。したがって、ドメイン名をHIに変換する手段が必要です。この変換にDNSを使用するのは非常に簡単です。HIPRRを定義します。名前またはIPアドレスのルックアップをアプリケーションまたはULPでクエリすると、リゾルバーはさらに名前からHIのルックアップを実行し、それを使用して結果のHIからIPアドレスへのマッピング（内部HIPレイヤーに）。 HIP層は、HIからIPアドレスへのマッピングを使用して、HIとHITをIPアドレスに変換します。
The HIP specification [RFC7401] specifies the HIP base exchange between a HIP Initiator and a HIP Responder based on a four-way handshake involving a total of four HIP packets (I1, R1, I2, and R2). Since the HIP packets contain both the Initiator and the Responder HIT, the Initiator needs to have knowledge of the Responder's HI and HIT prior to initiating the base exchange by sending an I1 packet.
HIP仕様[RFC7401]は、合計4つのHIPパケット（I1、R1、I2、およびR2）を含む4ウェイハンドシェイクに基づいて、HIPイニシエーターとHIPレスポンダー間のHIPベース交換を指定します。 HIPパケットにはイニシエーターとレスポンダーHITの両方が含まれているため、イニシエーターは、I1パケットを送信してベース交換を開始する前に、レスポンダーのHIとHITを知っている必要があります。
The HIP Rendezvous Extension [RFC8004] allows a HIP node to be reached via the IP address(es) of a third party, the node's RVS. An Initiator willing to establish a HIP association with a Responder served by an RVS would typically initiate a HIP base exchange by sending the I1 packet initiating the exchange towards the RVS IP address rather than towards the Responder IP address. Consequently, we need a means to find the name of an RVS for a given host name.
HIP Rendezvous Extension [RFC8004]を使用すると、サードパーティ、つまりノードのRVSのIPアドレスを介してHIPノードに到達できます。 RVSがサービスを提供するレスポンダとHIPアソシエーションを確立しようとするイニシエータは、通常、レスポンダIPアドレスではなくRVS IPアドレスに向けて交換を開始するI1パケットを送信することにより、HIPベース交換を開始します。したがって、特定のホスト名のRVSの名前を見つける手段が必要です。
This document introduces the HIP DNS RR to store the RVS, HI, and HIT information.
このドキュメントでは、RVS、HI、およびHIT情報を格納するためのHIP DNS RRを紹介します。
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 HIP.
このセクションでは、DNSがHIPで役立つ多くの使用シナリオを簡単に紹介します。
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 failover, 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ノードは、ほとんどのULPとアプリケーションに対して透過的な方法で、フェイルオーバー、冗長性、モビリティ、または再番号付けのために複数のIPアドレスを利用できます（HIにバインドされているため、これらの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 addresses via A [RFC1035] and AAAA [RFC3596] Resource Record Sets (RRSets) [RFC2181].
o A [RFC1035]およびAAAA [RFC3596]リソースレコードセット（RRSets）[RFC2181]を介したIPアドレスのセット。
o An HI, a HIT, and possibly a set of RVSs through HIP RRs.
o HI、HIT、およびHIP RRを介したRVSのセット。
The HIP RR is class independent.
HIP RRはクラスに依存しません。
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 (MitM) attacks on the HIP exchange. To prevent these attacks, it is recommended that the Initiator first obtains the HI of the Responder and then initiates the exchange. This can be done, for example, through manual configuration or DNS lookups. Hence, a HIP RR is introduced.
HIPノードが別のHIPノードとの通信を開始する場合、最初にHIPベース交換を実行して、ピアへのHIPアソシエーションをセットアップする必要があります。そのような交換は日和見的に、つまりレスポンダーのHIを事前に知らなくても開始できますが、そうすることで、両方のノードが意図的にHIP交換に対する中間者（MitM）攻撃の危険を冒します。これらの攻撃を防ぐには、イニシエーターが最初にレスポンダーの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 RVSs [RFC8004]. A HIP host uses an RVS 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の自然な遅延により、新しいIPアドレスをDNSに公開できない場合があります。この問題を解決するために、HIPアーキテクチャ[RFC4423]はRVS [RFC8004]を導入しています。 HIPホストは、ランデブーポイントとしてRVSを使用して、移動中にHIPイニシエーターとの到達可能性を維持します[RFC5206]。そのようなHIPノードは、RVSを最新のIPアドレスセットで最新に保ちながら、RIPドメイン名をDNSでHIP RRに公開します。
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 Application Programming Interfaces (APIs) may typically first query for HIP RRs at the Responder FQDN, while those using an IP address in APIs may typically first query for A and/or AAAA RRs.
HIPノードがレスポンダとのHIP交換を開始する場合、ノードはいくつかのDNSルックアップを実行します。実装のタイプに応じて、これらのルックアップが発行される順序は異なります。たとえば、アプリケーションプログラミングインターフェース（API）でHITを使用する実装では、通常、最初にレスポンダーFQDNでHIP RRを照会しますが、APIでIPアドレスを使用する実装では、通常、AやAAAA RRを照会します。
In the following, we assume that the Initiator first queries for HIP RRs at the Responder FQDN.
以下では、イニシエーターは最初にレスポンダーFQDNでHIP RRを照会すると想定しています。
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 fall back 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 Sections 3.1 and 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ノードによる到達可能性に悪影響を与える可能性があることに注意してください。
In addition to its IP address or addresses (IP-R), a HIP node (R) with a single static network attachment that wishes to be reachable by reference to its FQDN (www.example.com) to act as a Responder would store in the DNS a HIP RR containing its Host Identity (HI-R) and Host Identity Tag (HIT-R).
1つまたは複数のIPアドレス（IP-R）に加えて、FQDN（www.example.com）を参照して到達可能になり、レスポンダーとして機能する単一の静的ネットワーク接続を持つHIPノード（R）は、 DNSでは、ホストID（HI-R）とホストIDタグ（HIT-R）を含むHIP RR。
An Initiator willing to associate with a node would typically issue the following queries:
通常、ノードに関連付けようとするイニシエーターは、次のクエリを発行します。
o Query #1: QNAME=www.example.com, QTYPE=HIP
o クエリ＃1：QNAME = www.example.com、QTYPE = HIP
(QCLASS=IN is assumed and omitted from the examples)
（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 = 0のDNSパケットと、応答セクションのレスポンダのHITおよびHI（HIT-RおよびHI-Rなど）を持つ1つ以上のHIP RRを返しますが、RVSは返しません。
o Query #2: QNAME=www.example.com, QTYPE=A
o クエリ＃2：QNAME = www.example.com、QTYPE = A
o Query #3: QNAME=www.example.com, QTYPE=AAAA
o クエリ＃3：QNAME = www.example.com、QTYPE = AAAA
Which would return DNS packets with RCODE=0 and, respectively, one or more A or AAAA RRs containing the IP address(es) of the Responder (e.g., IP-R) in their answer sections.
これは、RCODE = 0のDNSパケットと、応答セクションにレスポンダ（IP-Rなど）のIPアドレスを含む1つ以上のAまたはAAAA RRをそれぞれ返します。
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クエリと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 Single-Homed Host
静的シングルホームホスト
The Initiator would then send an I1 to the Responder's IP addresses (IP-R).
次に、イニシエーターはI1をレスポンダーのIPアドレス（IP-R）に送信します。
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 or addresses (IP-R), its HI (HI-R), its HIT (HIT-R), and the domain name or names of its RVS or servers (e.g., rvs.example.com) in a HIP RR or records. The mobile HIP node also needs to notify its RVSs of any change in its set of IP addresses.
FQDN（www.example.com）を参照して到達可能なモバイルHIPノード（R）は、おそらくそのIPアドレス（IP-R）に加えて、そのHI（HI-R ）、そのHIT（HIT-R）、およびHIP RRまたはレコード内のそのRVSまたはサーバーのドメイン名（例：rvs.example.com）。モバイルHIPノードは、IPアドレスのセットの変更をRVSに通知する必要もあります。
An Initiator willing to associate with such a mobile node would typically issue the following queries:
そのようなモバイルノードに関連付けようとするイニシエーターは、通常、次のクエリを発行します。
o Query #1: QNAME=www.example.com, QTYPE=HIP
o クエリ＃1：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 or names (e.g., HIT-R, HI-R, and rvs.example.com) of the Responder in the answer section.
これは、RCODE = 0のDNSパケットと、HIT、HI、およびRVSドメイン名（例：HIT-R、HI-R、rvs.example.com）を持つ1つ以上のHIP RRを返します。回答セクション。
o Query #2: QNAME=rvs.example.com, QTYPE=A
o クエリ＃2：QNAME = rvs.example.com、QTYPE = A
o Query #3: QNAME=rvs.example.com, QTYPE=AAAA
o クエリ＃3：QNAME = rvs.example.com、QTYPE = AAAA
Which return DNS packets with RCODE=0 and, respectively, one or more A or AAAA RRs containing an IP address(es) of the Responder's RVS (e.g., IP-RVS) in their answer sections.
RCODE = 0のDNSパケットと、それぞれの応答セクションにレスポンダのRVS（IP-RVSなど）のIPアドレスを含む1つ以上のAまたはAAAA RRを返すもの。
[HIP? ] [www.example.com]
【ヒップ？ ] [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.
次に、イニシエーターはI1をRVS IPアドレス（IP-RVS）に送信します。その後、RVSはI1をモバイルノードのIPアドレス（IP-R）に中継し、これによりHIP交換が完了します。
For any HIP node, its HI, the associated HIT, and the FQDN of its possible RVSs can be stored in a DNS HIP RR. Any conforming implementation may store an HI and its associated HIT in a DNS HIP RDATA format. HI and HIT are defined in Section 3 of the HIP specification [RFC7401].
任意のHIPノードの場合、そのHI、関連付けられたHIT、および可能なRVSのFQDNをDNS HIP RRに格納できます。準拠する実装では、HIおよびそれに関連するHITをDNS HIP RDATA形式で格納できます。 HIとHITは、HIP仕様[RFC7401]のセクション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 [RFC7401], while the HIT included in the HIP RR SHOULD only be used as an optimization (e.g., table lookup).
HIP RRに含まれるHITのみを使用する一方で、HIP RRが返されると、ホストは常にHIP交換で使用されるHI派生HITを計算する必要があります（HIP仕様[RFC7401]のセクション3で指定）。最適化（例：テーブル検索）。
The HIP RR may also contain one or more domain names of one or more RVSs towards which HIP I1 packets might be sent to trigger the establishment of an association with the entity named by this RR [RFC8004].
HIP RRには、このRR [RFC8004]で指定されたエンティティとの関連付けの確立をトリガーするためにHIP I1パケットが送信される1つ以上のRVSの1つ以上のドメイン名も含まれる場合があります。
The Rendezvous Server field of the HIP RR stored at a given owner name MAY include the owner name itself. A semantically equivalent situation occurs if no RVS is present in the HIP RR stored at that owner name. Such situations occur in two cases:
特定の所有者名で保存されたHIP RRのRendezvous Serverフィールドには、所有者名自体が含まれる場合があります。その所有者名で保存されたHIP RRにRVSが存在しない場合、意味的に同等の状況が発生します。このような状況は次の2つの場合に起こります。
o The host is mobile, and the A and/or AAAA RR(s) stored at its host name contain the IP address(es) of its RVS rather than its own one.
o ホストはモバイルであり、そのホスト名に保存されているAおよび/またはAAAA RRには、独自のアドレスではなく、RVSのIPアドレスが含まれています。
o The host is stationary and can be reached directly at the IP address(es) contained in the A and/or AAAA RR(s) stored at its host name. This is a degenerate case of rendezvous service where the host somewhat acts as an RVS for itself.
o ホストは固定されており、ホスト名に格納されているAおよび/またはAAAA RRに含まれているIPアドレスに直接到達できます。これは、ホストがそれ自体のRVSとして機能するランデブーサービスの退化したケースです。
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の所有者）に中継します。その後、レスポンダは、通常RVSからの継続的な支援なしに、イニシエータとの交換を完了します。
On a HIP node, a HIP exchange SHOULD be initiated whenever a ULP attempts to communicate with an entity, and the DNS lookup returns HIP RRs.
HIPノードでは、ULPがエンティティとの通信を試みるたびにHIP交換を開始する必要があり（SHOULD）、DNSルックアップはHIP RRを返します。
HIP RRs have a Time To Live (TTL) associated with them. When the number of seconds that passed since the record was retrieved exceeds the record's TTL, the record MUST be considered no longer valid and deleted by the entity that retrieved it. If access to the record is necessary to initiate communication with the entity to which the record corresponds, a new query MUST be made to retrieve a fresh copy of the record.
HIP RRには、Time To Live（TTL）が関連付けられています。レコードが取得されてから経過した秒数がレコードのTTLを超えると、そのレコードは有効でなくなったと見なされ、取得したエンティティによって削除される必要があります。レコードに対応するエンティティとの通信を開始するためにレコードへのアクセスが必要な場合は、新しいクエリを作成して、レコードの新しいコピーを取得する必要があります。
There may be multiple HIP RRs associated with a single name. It is outside the scope of this specification as to how a host chooses between multiple RRs when more than one is returned. The RVS information may be copied and aligned across multiple RRs, or may be different for each one; a host MUST check that the RVS used is associated with the HI being used, when multiple choices are present.
単一の名前に関連付けられた複数のHIP RRが存在する場合があります。複数のRRが返されたときにホストが複数のRRからどのように選択するかは、この仕様の範囲外です。 RVS情報は、複数のRR間でコピーおよび整列される場合と、それぞれ異なる場合があります。ホストは、複数の選択肢が存在する場合、使用されるRVSが使用されているHIに関連付けられていることを確認する必要があります。
The RDATA for a HIP RR consists of a PK Algorithm Type, the HIT length, a HIT, a PK (i.e., an HI), and optionally one or more RVSs.
HIP RRのRDATAは、PKアルゴリズムタイプ、HIT長、HIT、PK（つまりHI）、およびオプションで1つ以上のRVSで構成されます。
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 Server field is OPTIONAL.
HITの長さ、PKアルゴリズム、PKの長さ、HIT、および公開鍵フィールドは必須です。 Rendezvous Serverフィールドはオプションです。
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 PK 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アルゴリズムフィールドは、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は、ネットワークバイトオーダーのバイナリ値として格納されます。
Two of the PK types defined in this document (RSA and Digital Signature Algorithm (DSA)) reuse the PK formats defined for the IPSECKEY RR [RFC4025].
このドキュメントで定義されている2つのPKタイプ（RSAおよびデジタル署名アルゴリズム（DSA））は、IPSECKEY RR [RFC4025]に定義されているPK形式を再利用します。
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]仕様で緩和されています。
In addition, this document similarly defines the PK format of type Elliptic Curve Digital Signature Algorithm (ECDSA) as the algorithm-specific portion of the DNSKEY RR RDATA for ECDSA [RFC6605], i.e, all of the DNSKEY RR DATA after the first four octets, corresponding to the same portion of the DNSKEY RR that must be specified by documents that define a DNSSEC algorithm.
さらに、このドキュメントは同様に、タイプElliptic Curve Digital Signature Algorithm（ECDSA）のPKフォーマットをECDSA [RFC6605]のDNSKEY RR RDATAのアルゴリズム固有の部分、つまり最初の4オクテットの後のすべてのDNSKEY RR DATAとして定義します。 、DNSSECアルゴリズムを定義するドキュメントで指定する必要があるDNSKEY RRの同じ部分に対応します。
The Rendezvous Server field indicates one or more variable length wire-encoded domain names of one or more RVSs, concatenated and encoded as described in Section 3.3 of RFC 1035 [RFC1035]: "<domain-name> is a domain name represented as a series of labels, and terminated by a label with zero length". Since the wire-encoded format is self-describing, the length of each domain name is implicit: The zero length label termination serves as a separator between multiple RVS domain names concatenated in the Rendezvous Server field of a same HIP RR. Since the length of the other portion of the RR's RRDATA is known, and the overall length of the RR's RDATA is also known (RDLENGTH), all the length information necessary to parse the HIP RR is available.
Rendezvous Serverフィールドは、RFC 1035 [RFC1035]のセクション3.3で説明されているように連結およびエンコードされた、1つ以上のRVSの1つ以上の可変長ワイヤーエンコードドメイン名を示します。「<domain-name>は、シリーズとして表されるドメイン名です。ラベルの数、および長さがゼロのラベルで終了します。」ワイヤーエンコード形式は自己記述型であるため、各ドメイン名の長さは暗黙的です。長さゼロのラベルの終端は、同じHIP RRのRendezvous Serverフィールドで連結された複数のRVSドメイン名の間のセパレーターとして機能します。 RRのRRDATAの他の部分の長さは既知であり、RRのRDATAの全長も既知（RDLENGTH）であるため、HIP RRを解析するために必要なすべての長さ情報を利用できます。
The domain names MUST NOT be compressed. The RVS or servers are listed in order of preference (i.e., the first RVS or servers are preferred), defining an implicit order amongst RVSs of a single RR.
ドメイン名は圧縮してはいけません。 RVSまたはサーバーは優先順にリストされ（つまり、最初のRVSまたはサーバーが優先されます）、単一のRRのRVS間の暗黙的な順序を定義します。
When multiple HIP RRs are present at the same owner name, this implicit order of RVSs within an RR MUST NOT be used to infer a preference order between RVSs stored in different RRs.
複数のHIP RRが同じ所有者名で存在する場合、RR内のRVSのこの暗黙の順序を使用して、異なるRRに格納されているRVS間の優先順位を推測してはなりません（MUST NOT）。
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進数または16進数）として表されます。エンコーディングには、公開鍵フィールドと区別するために空白を含めてはなりません（MUST NOT）。
The Public Key field is represented as the Base64 encoding of the PK, as defined in Section 4 of [RFC4648]. The encoding MUST NOT contain whitespace(s) to distinguish it from the Rendezvous Server field.
[RFC4648]のセクション4で定義されているように、公開鍵フィールドはPKのBase64エンコードとして表されます。エンコードには、Rendezvous Serverフィールドと区別するために空白を含めることはできません。
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 Server field is represented by one or more domain names separated by whitespace(s). Such whitespace is only used in the HIP RR representation format and is not part of the HIP RR wire format.
Rendezvous Serverフィールドは、空白で区切られた1つ以上のドメイン名で表されます。このような空白は、HIP RR表現形式でのみ使用され、HIP RRワイヤー形式の一部ではありません。
The complete representation of the HIP record is:
HIPレコードの完全な表現は次のとおりです。
IN HIP ( pk-algorithm base16-encoded-hit base64-encoded-public-key rendezvous-server[1] ... rendezvous-server[n] )
IN HIP（pk-algorithm base16-encoded-hit base64-encoded-public-key rendezvous-server [1] ... rendezvous-server [n]）
When no RVSs are present, the representation of the HIP record is:
RVSが存在しない場合、HIPレコードは次のようになります。
IN HIP ( pk-algorithm base16-encoded-hit base64-encoded-public-key )
IN HIP（pk-algorithm base16-encoded-hit base64-encoded-public-key）
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.
以下の例では、空白が含まれていない公開キーフィールドは、このドキュメントの1行に収まらないため、折り返されています。
Example of a node with an HI and a HIT but no RVS:
HIとHITはあるがRVSがないノードの例：
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cI vM4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ry ra+bSRGQb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXd XF5D )
www.example.com。 HIP（2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cI vM4p9 + LrV4e19WzK00 + CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu + Upr1gsNrut79ry RA + bSRGQb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXd XF5D）
Example of a node with an HI, a HIT, and one RVS:
HI、HIT、および1つのRVSを持つノードの例：
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cI vM4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ry ra+bSRGQb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXd XF5D rvs.example.com. )
www.example.com。 HIP（2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cI vM4p9 + LrV4e19WzK00 + CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu + Upr1gsNrut79ry RA + bSRGQb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXd XF5D rvs.example.com。）
Example of a node with an HI, a HIT, and two RVSs:
HI、HIT、および2つのRVSを持つノードの例：
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cI vM4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ry ra+bSRGQb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXd XF5D rvs1.example.com. rvs2.example.com. )
www.example.com。 HIP（2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cI vM4p9 + LrV4e19WzK00 + CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu + Upr1gsNrut79ry RA + bSRGQb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXd XF5D 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 is subject, as the IPSECKEY RR, to threats stemming from attacks against unsecured HIP RRs, as described in the remainder of this section.
IPSECKEY RR [RFC4025]と同様の方法で、HIP DNS拡張は、ピアの公開鍵情報（HI）を持つ2つのHIPノードのプロビジョニングを可能にします。これらのHIは、その後、ピア間の鍵交換で使用されます。したがって、このセクションの残りの部分で説明するように、HIP DNS拡張機能は、IPSECKEY RRとして、セキュリティ保護されていないHIP RRに対する攻撃から生じる脅威にさらされます。
A HIP node SHOULD obtain HIP RRs from a trusted party through 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 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を取得する必要があります（SHOULD）。 DNSSEC [RFC4033] [RFC4034] [RFC4035]は、そのような安全なチャネルを提供します。ただし、DNSSECが提供するのは、ゾーンを公開しているDNSサーバーとHIPノード間のチャネルに対するデータの整合性と信頼性の保証のみであることを強調してください。 DNSSECは、ゾーンを公開するエンティティが信頼できることを保証しません。したがって、HIP RRSetのRRSIGは、HIおよび/またはHITを所有者名にバインドする証明書として誤って解釈されてはなりません。
In the absence of a proper secure channel, both parties are vulnerable to MitM and Denial-of-Service (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 PK (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 MitM attacks on the cryptographic core of the eventual HIP exchange (Responder's HIP RR rewritten by the attacker).
HIP RRには、名前付きピアのPK（HI）とそのセキュアハッシュ（HIT）の形式の公開鍵情報が含まれています。これらは両方とも、攻撃者が攻撃者の知識を獲得する攻撃には敏感ではありません。ただし、DNSにアクティブな攻撃を仕掛けることができる、つまりこのHIP RRを改ざんする（DNSスプーフィングを使用するなど）ことができる攻撃者は、最終的なHIP交換の暗号化コア（レスポンダーのHIP RR）にMitM攻撃を仕掛けることができます。攻撃者によって書き換えられました）。
The HIP RR may contain an RVS domain name resolved into a destination IP address where the named peer is reachable by an I1, as per the HIP Rendezvous Extension [RFC8004]. Thus, an attacker that is 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には、HIP Rendezvous Extension [RFC8004]のように、名前付きピアがI1から到達可能な宛先IPアドレスに解決されるRVSドメイン名が含まれる場合があります。したがって、このRRを改ざんできる攻撃者は、名前付きピアに送信されたI1パケットを、DoS攻撃またはMitM攻撃のために選択されたIPアドレスにリダイレクトできます。この種の攻撃は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, and 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.
攻撃者は明らかにこれら2つの攻撃を組み合わせて使用する可能性があります。イニシエーター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 rather SHOULD use HI-based authentication.
多くの暗号化アルゴリズムと同様に、一部の安全なハッシュ（たとえば、HIPがHIからHITを生成するために使用するSHA1）は最終的に安全でなくなります。これは、妥当な計算能力を持つ攻撃者が、ハッシュ（たとえば、想定される衝突抵抗）。これが、HIPエンドノード実装がDNSから取得したHITだけに基づいてHIPピアを認証するべきではなく（SHOULD）、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]で説明されている脅威の影響を受けます。
[RFC5205], obsoleted by this document, made the following definition and reservation in the "Resource Record (RR) TYPEs" subregistry under "Domain Name System (DNS) Parameters":
このドキュメントで廃止された[RFC5205]は、「ドメインネームシステム（DNS）パラメータ」の「リソースレコード（RR）タイプ」サブレジストリで次の定義と予約を行いました。
Value Type
----- ----
55 HIP
In the "Resource Record (RR) TYPEs" subregistry under "Domain Name System (DNS) Parameters", references to [RFC5205] have been replaced by references to this document.
「ドメインネームシステム（DNS）パラメータ」の「リソースレコード（RR）タイプ」サブレジストリで、[RFC5205]への参照は、このドキュメントへの参照に置き換えられました。
As [RFC5205], this document reuses the Algorithm Types defined by [RFC4025] for the IPSEC KEY RR. Presently defined values are shown here for reference only:
[RFC5205]として、このドキュメントはIPSEC KEY RRのために[RFC4025]によって定義されたアルゴリズムタイプを再利用します。現在定義されている値は、参考のためにここに表示されています。
Value Description
----- --------------------------------------------------------
1 A DSA key is present, in the format defined in [RFC2536]
2 A RSA key is present, in the format defined in [RFC3110]
IANA has made the following assignment in the "Algorithm Type Field" subregistry under "IPSECKEY Resource Record Parameters" [RFC4025]:
IANAは、「IPSECKEY Resource Record Parameters」[RFC4025]の「Algorithm Type Field」サブレジストリに次の割り当てを行いました。
Value Description
----- -----------
3 An ECDSA key is present, in the format defined in [RFC6605]
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<http://www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <http://www.rfc-editor.org/info/rfc2181>.
[RFC2181] Elz、R。およびR. Bush、「Clarifications to the DNS Specification」、RFC 2181、DOI 10.17487 / RFC2181、1997年7月、<http://www.rfc-editor.org/info/rfc2181>。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, DOI 10.17487/RFC3596, October 2003, <http://www.rfc-editor.org/info/rfc3596>.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「DNS Extensions to Support IP Version 6」、RFC 3596、DOI 10.17487 / RFC3596、2003年10月、<http：// www .rfc-editor.org / info / rfc3596>。
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 2005, <http://www.rfc-editor.org/info/rfc4025>.
[RFC4025] Richardson、M。、「A Method for Storing IPsec Keying Material in DNS」、RFC 4025、DOI 10.17487 / RFC4025、2005年3月、<http://www.rfc-editor.org/info/rfc4025>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Securityの紹介と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<http： //www.rfc-editor.org/info/rfc4033>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、< http://www.rfc-editor.org/info/rfc4034>。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、< http://www.rfc-editor.org/info/rfc4035>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI 10.17487/RFC6605, April 2012, <http://www.rfc-editor.org/info/rfc6605>.
[RFC6605] Hoffman、P.およびW. Wijngaards、「DNSSECの楕円曲線デジタル署名アルゴリズム（DSA）」、RFC 6605、DOI 10.17487 / RFC6605、2012年4月、<http://www.rfc-editor.org/info / rfc6605>。
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, <http://www.rfc-editor.org/info/rfc7401>.
[RFC7401] Moskowitz、R。、編、Heer、T.、Jokela、P。、およびT. Henderson、「Host Identity Protocol Version 2（HIPv2）」、RFC 7401、DOI 10.17487 / RFC7401、2015年4月、<http ：//www.rfc-editor.org/info/rfc7401>。
[RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, October 2016, <http://www.rfc-editor.org/info/rfc8004>.
[RFC8004] Laganier、J。およびL. Eggert、「Host Identity Protocol（HIP）Rendezvous Extension」、RFC 8004、DOI 10.17487 / RFC8004、2016年10月、<http://www.rfc-editor.org/info/rfc8004 >。
[RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, DOI 10.17487/RFC2536, March 1999, <http://www.rfc-editor.org/info/rfc2536>.
[RFC2536] Eastlake 3rd、D。、「ドメインネームシステム（DNS）のDSAキーとSIG」、RFC 2536、DOI 10.17487 / RFC2536、1999年3月、<http://www.rfc-editor.org/info/ rfc2536>。
[RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110, May 2001, <http://www.rfc-editor.org/info/rfc3110>.
[RFC3110] Eastlake 3rd、D。、「ドメインネームシステム（DNS）のRSA / SHA-1 SIGおよびRSAキー」、RFC 3110、DOI 10.17487 / RFC3110、2001年5月、<http：//www.rfc-editor .org / info / rfc3110>。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August 2004, <http://www.rfc-editor.org/info/rfc3833>.
[RFC3833] Atkins、D。およびR. Austein、「ドメインネームシステム（DNS）の脅威分析」、RFC 3833、DOI 10.17487 / RFC3833、2004年8月、<http://www.rfc-editor.org/info / rfc3833>。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May 2006, <http://www.rfc-editor.org/info/rfc4423>.
[RFC4423] Moskowitz、R。およびP. Nikander、「Host Identity Protocol（HIP）Architecture」、RFC 4423、DOI 10.17487 / RFC4423、2006年5月、<http://www.rfc-editor.org/info/rfc4423> 。
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", RFC 5205, DOI 10.17487/RFC5205, April 2008, <http://www.rfc-editor.org/info/rfc5205>.
[RFC5205] Nikander、P。およびJ. Laganier、「Host Identity Protocol（HIP）Domain Name System（DNS）Extensions」、RFC 5205、DOI 10.17487 / RFC5205、2008年4月、<http：//www.rfc-editor。 org / info / rfc5205>。
[RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, DOI 10.17487/RFC5206, April 2008, <http://www.rfc-editor.org/info/rfc5206>.
[RFC5206] Nikander、P.、Henderson、T.、Ed。、Vogt、C。、およびJ. Arkko、「End-Host Mobility and Multihoming with the Host Identity Protocol」、RFC 5206、DOI 10.17487 / RFC5206、2008年4月、<http://www.rfc-editor.org/info/rfc5206>。
o Updated HIP references to revised HIP specifications.
o 修正されたHIP仕様へのHIPリファレンスを更新しました。
o Extended DNS HIP RR to support for Host Identities based on ECDSA.
o ECDSAに基づくホストIDをサポートするための拡張DNS HIP RR。
o Clarified that new query must be made when the time that passed since an RR was retrieved exceeds the TTL of the RR.
o RRが取得されてから経過した時間がRRのTTLを超える場合は、新しいクエリを実行する必要があることを明確にしました。
o Added considerations related to multiple HIP RRs being associated with a single name.
o 単一の名前に関連付けられている複数のHIP RRに関連する考慮事項が追加されました。
o Clarified that the Base64 encoding in use is as per Section 4 of [RFC4648].
o 使用されているBase64エンコードが[RFC4648]のセクション4に従っていることを明確にしました。
o Clarified the wire format when more than one RVS is defined in one RR.
o 1つのRRで複数のRVSが定義されている場合のワイヤー形式を明確にしました。
o Clarified that "whitespace" is used as the delimiter in the human-readable representation of the RR but is not part of the wire format.
o 「ホワイトスペース」は、人が読めるRRの表現では区切り文字として使用されますが、ワイヤー形式の一部ではないことを明確にしました。
Acknowledgments
謝辞
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, Gabriel Montenegro, and Erik Nordmark. Some parts of this document stem from the HIP specification [RFC7401]. Finally, thanks to Sheng Jiang for performing the Internet Area Directorate review of this document in the course of the publication process.
IETFでいつものように、このドキュメントは多くの人々の間のコラボレーションの結果です。著者は、IPSECKEY RR [RFC4025]仕様の著者（Michael Richardson）、寄稿者、およびレビュー担当者に感謝します。その後、このドキュメントが作成されました。このドキュメントの改善に役立った、思慮深く有益なディスカッションや提案を提供してくれた次の人々にも感謝します。JeffAhrenholz、Rob Austein、Hannu Flinck、Olafur Gudmundsson、Tom Henderson、Peter Koch、Olaf Kolkman 、Miika Komu、Andrew McGregor、Gabriel Montenegro、Erik Nordmark。このドキュメントの一部は、HIP仕様[RFC7401]に基づいています。最後に、公開プロセスの過程でこのドキュメントのインターネットエリア総局のレビューを行ってくれたSheng Jiangに感謝します。
Contributors
貢献者
Pekka Nikander coauthored an earlier, experimental version of this specification [RFC5205].
Pekka Nikanderは、この仕様の初期の実験バージョン[RFC5205]を共同執筆しました。
Author's Address
著者のアドレス
Julien Laganier Luminate Wireless, Inc. Cupertino, CA United States of America
ジュリアンラガニアLuminate Wireless、Inc.クパチーノ、カリフォルニア州アメリカ合衆国
Email: julien.ietf@gmail.com