[要約] RFC 5205は、Host Identity Protocol（HIP）におけるDomain Name System（DNS）の拡張に関するものであり、HIPとDNSの統合を目的としています。このRFCは、HIPネットワークでのホストの識別とアドレス解決を改善するためのガイドラインを提供します。
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
ホストIDプロトコル（HIP）ドメイン名システム（DNS）拡張機能
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
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）と、ホストIDプロトコル（HIP）で使用する方法を指定します。このRRは、股関節ノードをDNSのホストID（HI、ノード官民キーペアのパブリックコンポーネント）、ホストIDタグ（ヒット、その公開鍵の切り捨てられたハッシュ）、およびドメイン名のホストID（HI、ハイ、ホストIDタグ）に保存できます。そのランデブーサーバー（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）と、ホストIDプロトコル（HIP）[RFC5201]で使用する方法を指定します。このRRは、HIPノードをDNSのホストID（HI、ノード官民キーペアのパブリックコンポーネント）、ホストIDタグ（ヒット、そのHIの切り捨てられたハッシュ）、およびそのドメイン名を保存できます。Rendezvousサーバー（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アドレス（ES）に変換します。このステップは、リモートホストとの通信前に発生し、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.
股関節を使用すると、IPアドレスは主にエンドホスト間のワイヤ通信に使用することを目的としていますが、ほとんどの上層層プロトコル（ULP）とアプリケーションは代わりにHISまたはHITSを使用します（ICMPはULPを使用していない例です）。その結果、ドメイン名をHIに変換する手段が必要です。この翻訳にDNSを使用することは非常に簡単です。新しい股関節リソースレコードを定義します。IPアドレスルックアップの名前をアプリケーションまたはULPでクエリすると、リゾルバーはさらにHIルックアップに名前を実行し、それを使用して結果のHIからIPアドレスマッピング（股関節層の内部）を構築します。股関節層は、HIからIPアドレスマッピングを使用してHISとヒットをIPアドレスに翻訳し、その逆も同様です。
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.
股関節ランデブーエクステンション[RFC5204]により、サードパーティのIPアドレスであるノードのランデブーサーバー（RVS）を介して股関節ノードに到達できます。RVSが提供するレスポンダーとの股関節関連を確立する意思のあるイニシエーターは、通常、レスポンダーIPアドレスではなくRVS IPアドレスにI1を送信することにより、股関節交換を開始します。その結果、特定のホスト名のランデブーサーバーの名前を見つける手段が必要です。
This document introduces the new HIP DNS resource record to store the Rendezvous Server (RVS), Host Identity (HI), and Host Identity Tag (HIT) information.
このドキュメントでは、新しいHIP DNSリソースレコードを導入して、Rendezvousサーバー（RVS）、ホストID（HI）、およびホストIDタグ（ヒット）情報を保存します。
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がホストIDプロトコルで役立つ多くの使用シナリオを簡単に紹介します。
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).
股関節を使用すると、ほとんどのアプリケーションとULPは、ワイヤー上にパケットを運ぶために使用されるIPアドレスに気付いていません。したがって、股関節ノードは、ほとんどのULPSおよびアプリケーションに対して透明な方法で、フェイルオーバー、冗長性、モビリティ、または変更のために複数のIPアドレスを持つことを利用できます（したがって、それらは不可知論されます。これらの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]およびAAAA [RFC3596] RRセット（RRSETS [RFC2181]）を介した一連のIPアドレス（ES）。
o A Host Identity (HI), Host Identity Tag (HIT), and possibly a set of rendezvous servers (RVS) through HIP RRs.
o ホストID（HI）、ホストIDタグ（ヒット）、およびおそらくヒップRRを介した一連のランデブーサーバー（RV）。
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.
股関節ノードが別の股関節ノードとの通信を開始したい場合、最初にヒップベース交換を実行して、ピアに股関節関連を設定する必要があります。このような交換は日和見的に開始することができますが、つまり、レスポンダーのHIの事前の知識なしに、両方のノードが故意に股関節交換に対する中間の攻撃を故意にリスクすることにより。これらの攻撃を防ぐために、イニシエーターが最初にレスポンダーのHIを取得し、次に交換を開始することをお勧めします。これは、たとえば、手動の構成やDNSルックアップを介して実行できます。したがって、新しい股関節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.
股関節ノードがIPアドレスを頻繁に変更している場合、変更を伝播するための自然なDNSレイテンシにより、DNSで新しいIPアドレス（ES）の公開が妨げられます。この問題を解決するために、股関節アーキテクチャ[RFC4423]は、Rendezvousサーバー（RVSS）[RFC5204]を導入します。ヒップホストは、ランデブーサーバーをランデブーポイントとして使用して、移動中に可能な股関節イニシエーターでリーチ性を維持します[RFC5206]。このような股関節ノードは、現在のIPアドレスのセットでRVSを最新に保ちながら、DNSのRVSドメイン名で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 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.
股関節ノードがレスポンダーとの股関節交換を開始したい場合、多くのDNSルックアップを実行します。実装の種類に応じて、それらのルックアップが発行される順序は異なる場合があります。たとえば、APIでHITを使用した実装は、通常、Responder FQDNでの股関節リソースレコードの最初のクエリをクエリする場合がありますが、APIでIPアドレスを使用するものは通常、Aおよび/またはAAAAリソースレコードの最初のクエリを使用できます。
In the following, we assume that the Initiator first queries for HIP resource records at the Responder FQDN.
以下では、Responder FQDNでの股関節リソースレコードの最初のクエリを最初にクエリしていると想定しています。
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.
股関節レコードのクエリがrcode = 0（エラーなし）と空の回答セクションでDNS回答を返した場合、それはレスポンダー名で股関節情報が利用できないことを意味します。そのような場合、イニシエーターが日和見股関節にフォールバックするポリシー（レスポンダーのHIを知らずに開始）またはプレーンIPに設定されている場合、ResponderのFQDNでAとAAAのタイプのクエリを追加します。
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.
非ヒップノードに割り当てられたFQDNでDNSに股関節RR情報を保存すると、股関節ノードによる到達可能性に悪影響がある可能性があることに注意してください。
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に保存されます。、そのホストID（HI-R）とHOST IDタグ（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 = 0でDNSパケットを返し、回答セクションのResponderのヒットとHI（HIT-RおよびHI-Rなど）を持つ1つ以上のヒップRRSを返しますが、RVはありません。
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.
回答セクションにRcode = 0およびResponder（例えば、IP-R）のIPアドレス（ES）を含む1つ以上のAまたはAAAA RRSを返します。
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).
イニシエーターは、I1をResponderの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(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）を参照して到達可能にしたいモバイル股関節ノード（R）は、おそらくそのIPアドレス（es）（IP-r）に加えて、DNSに保存されます。r）、ヒット（hit-r）、およびhipリソースレコードのランデブーサーバー（rvs.example.comなど）のドメイン名。モバイル股関節ノードは、IPアドレスのセット（ES）の変更をランデブーサーバーに通知する必要があります。
An Initiator willing to associate with such a mobile node would typically issue the following queries:
このようなモバイルノードに関連する意思のあるイニシエーターは、通常、次のクエリを発行します。
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.
o qname = www.example.com、qtype = hip rcode = 0でdnsパケットを返し、ヒット、hi、rvsドメイン名で1つ以上のヒップRRを返します（例：hit-r、hi-r、回答セクションのレスポンダーのrvs.example.com）。
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およびRESPONDERのRVS（例：IP-RV）のIPアドレス（ES）を含む1つ以上のAまたはAAAA RRSでDNSパケットを返します。
[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-RV）に送信します。次に、RVSはi1をモバイルノードのIPアドレス（IP-R）にリレーし、股関節交換を完了します。
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].
任意の股関節ノード、そのホストID（HI）、関連するホストIDタグ（HIT）、および可能なRVSSのFQDNは、DNS股関節RRに保存できます。適合実装は、ホストID（HI）とその関連ホストIDタグ（HIT）をDNS股関節RDATA形式に保存する場合があります。こんにちはとヒットは、股関節仕様のセクション3で定義されています[RFC5201]。
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).
股関節RRが戻った後、ホストは、股関節仕様[RFC5201]のセクション3で指定されているように、股関節交換で使用されるhi誘導体のヒットを常に計算する必要がありますが、ヒットはおそらく埋め込まれている必要があります。最適化（テーブルルックアップなど）。
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リソースレコードには、このリソースレコード[RFC5204]によって名前が付けられたエンティティとの関連性の確立をトリガーするために、HIP I1パケットが送信される可能性があるRendezvousサーバーの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:
特定の所有者名に保存されている股関節リソースレコードのランデブーサーバーフィールドには、所有者名自体が含まれる場合があります。その所有者名に保存されている股関節リソースレコードにランデブーサーバーが存在しない場合、意味的に同等の状況が発生します。このような状況は、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アドレス（ES）に直接アクセスできます。ホスト名に保存されています。これは、ホストがそれ自体のランデブーサーバーとして機能するランデブーサービスの退化したケースです。
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レシーバーヒットの所有者）にそれを中継します。その後、レスポンダーは、通常、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.
股関節ノードでは、ULPがエンティティと通信しようとする場合はいつでもホストIDプロトコル交換を開始する必要があり、DNSルックアップはヒップリソースレコードを返します。
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).
股関節RRのRDATAは、公開キーアルゴリズムタイプ、ヒット長、ヒット、公開鍵、およびオプションで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.
ヒット長、PKアルゴリズム、PKの長さ、ヒット、および公開キーフィールドが必要です。Rendezvousサーバーフィールドはオプションです。
The HIT length indicates the length in bytes of the HIT field. This is an 8-bit unsigned integer.
ヒット長は、ヒットフィールドのバイトの長さを示します。これは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.
The HIT is stored as a binary value in network byte order.
ヒットは、ネットワークバイトの順序でバイナリ値として保存されます。
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.
Rendezvousサーバーフィールドは、RFC 1035 [RFC1035]のセクション3.3で説明されているように、Rendezvousサーバーの1つ以上の可変長さのワイヤエンコードドメイン名を示しています。ワイヤエンコード形式は自己記述的であるため、長さは暗黙的です。ドメイン名を圧縮してはなりません。Rendezvousサーバーは、優先順位でリストされています（つまり、最初のRendezvousサーバーが推奨されます）。複数の股関節RRが同じ所有者名に存在する場合、RR内のランデブーサーバーのこの暗黙の順序を使用して、異なるRRに保存されているランデブーサーバー間の優先順序を推測してはなりません。
This section specifies the representation of the HIP RR in a zone master file.
このセクションでは、ゾーンマスターファイルの股関節RRの表現を指定します。
The HIT length field is not represented, as it is implicitly known thanks to the HIT field representation.
ヒットフィールドの表現のおかげで暗黙的に知られているため、ヒット長のフィールドは表されません。
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.
ヒットフィールドは、ヒットの[RFC4648]（a.k.a. hexまたは16進数）をエンコードするbase16として表されます。エンコーディングには、公開キーフィールドと区別するために、ホワイトスペースが含まれていてはなりません。
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.
公開キーフィールドは、公開キーの[RFC4648]をエンコードするbase64として表されます。エンコードには、ランデブーサーバーフィールドと区別するために、ホワイトスペースが含まれていてはなりません。
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).
Rendezvousサーバーフィールドは、Whitespace（S）で区切られた1つ以上のドメイン名で表されます。
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（pk-algorithm base16-Encoded-hit base64-Encoded-Public-Key-Key-Key-Key Rendezvous-Server [1] ... rendezvous-server [n]））
When no RVSs are present, the representation of the HPIHI record is:
RVSが存在しない場合、HPIHIレコードの表現は次のとおりです。
IN HIP ( pk-algorithm base16-encoded-hit base64-encoded-public-key )
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.
以下の例では、このドキュメントの単一の行に収まらないため、空白が含まれていない公開キーフィールドが包まれています。
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。
Example of a node with a HI, HIT, and one RVS:
HI、ヒット、および1つのRVを備えたノードの例：
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p 9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D rvs.example.com. )
www.example.com。
Example of a node with a HI, HIT, and two RVSs:
HI、ヒット、および2つのRVSを持つノードの例：
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p 9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D rvs1.example.com. rvs2.example.com. )
www.example.com。
This section contains a description of the known threats involved with the usage of the HIP DNS Extension.
このセクションには、股関節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]と同様の方法で、股関節DNS拡張により、ピアのパブリックキーイング材料（HI）を使用した2つの股関節ノードの提供が可能になります。これらはその後、ピア間の重要な交換で使用されます。したがって、股関節DNS拡張は、Ipseckeyと同じ種類の脅威を導入し、さらに、「日和見」または「未発表のイニシエーターHI」モードを使用して股関節交換を開始または受け入れる可能性によって引き起こされる脅威を導入します。
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.
股関節ノードは、信頼できるパーティーから股関節RRを取得する必要があります。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 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).
股関節RRには、指名されたピアの公開鍵（HI）とその安全なハッシュ（ヒット）の形のパブリックキーイング素材が含まれています。これらは両方とも、敵がそれらの知識を得る攻撃に敏感ではありません。ただし、DNSに積極的な攻撃を行うことができる攻撃者、つまりこの股関節RR（例えば、DNSスプーフィングを使用する）でタンパーを使用すると、最終的な暗号化コアに対する中間の攻撃をマウントすることができます。股関節交換（攻撃者が書き直したレスポンダーの股関節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.
股関節RRには、股関節ランデブーエクステンション[RFC5204]に従って、指定されたピアがI1によって到達可能な宛先IPアドレスに解決されたランデブーサーバードメイン名を含む場合があります。したがって、このRRを改ざんできる攻撃者は、DOSまたはMITM攻撃のために選択したIPアドレスに指名されたピアに送信されたi1パケットをリダイレクトすることができます。この種の攻撃は股関節に固有ではなく、股関節と股関節RRが使用されるかどうかに関係なく存在することに注意してください。このような攻撃者は、AとAAAA RRSも改ざんするかもしれません。
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.
攻撃者は明らかにこれら2つの攻撃を組み合わせて使用する場合があります。それは、イニシエーターHIに送信されたスプーフィングされたDNSパケットで、レスポンダーのHIおよびRVS IPアドレスを独自に置き換え、その後、すべての交換パケットを彼にリダイレクトし、MITMをHIPにマウントします。この場合、HIPは盗聴者からの機密性やイニシエーターの保護を提供しません。
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.
多くの暗号化アルゴリズムと同様に、いくつかの安全なハッシュ（たとえば、hipがHIからヒットを生成するために使用されるSHA1）は最終的に不安になります。ハッシュ（たとえば、その想定衝突抵抗）。これが、股関節エンドノードの実装で、DNSから取得されたヒットに基づいて股関節ピアを認証するのではなく、むしろハイベースの認証を使用する必要がある理由です。
In the absence of DNSSEC, the HIP RR is subject to the threats described in RFC 3833 [RFC3833].
DNSSECがない場合、股関節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は、股関節RRがIPSeckey RR [RFC4025]に定義された「アルゴリズムタイプ」を再利用するため、股関節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.
将来的には、股関節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]仕様に感謝したいと思いますが、その後、この文書は組み立てられました。著者はまた、この文書の改善に役立った思慮深く親切な議論や提案を提供してくれた以下の人々にも感謝したいと思います：ジェフ・アフレンホルツ、ロブ・オーストイン、ハンヌ・フリンク、オラファー・グドムンソン、トム・ヘンダーソン、ピーター・コッホ、オラフ・コルクマン、ミイカ・コム、アンドリュー・マクレガー、エリック・ノードマーク、ガブリエル・モンテネグロ。このドキュメントの一部は、股関節仕様[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、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] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「DNS拡張機能IPバージョン6」、RFC 3596、2003年10月。
[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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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] Moskowitz、R.、Nikander、P.、Jokela、P.、Ed。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001.
[RFC3110] EastLake、D。、「ドメイン名システム（DNS）のRSA/SHA-1 SIGSおよびRSAキー」、RFC 3110、2001年5月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析（DNS）」、RFC 3833、2004年8月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423] Moskowitz、R。およびP. Nikander、「Host Identity Protocol（HIP）Architecture」、RFC 4423、2006年5月。
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206] Henderson、T.、ed。、「ホストIDプロトコルによるエンドホストモビリティとマルチホミング」、RFC 5206、2008年4月。
Authors' Addresses
著者のアドレス
Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
Pekka Nikander Ericsson Research Nomadiclab Jorvas Fin-02420フィンランド
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany
Julien Laganier Docomo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687ドイツ
Phone: +49 89 56824 231
EMail: julien.ietf@laposte.net
URI: http://www.docomolab-euro.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。