Network Working Group T. Henderson
Request for Comments: 5338 The Boeing Company
Category: Informational P. Nikander
Ericsson Research NomadicLab
M. Komu
Helsinki Institute for Information Technology
September 2008
Using the Host Identity Protocol with Legacy Applications
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP). HIP proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and Application Programming Interface (API) issues relating to using HIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP.
この文書では、レガシーアプリケーションをホストアイデンティティプロトコル（HIP）で動作させることができるかの有益な概要です。 HIPは、ネットワークスタック名の暗号名前空間を追加することを提案しています。アプリケーションの観点から、HIP対応システムは、ホスト識別子の新しいアドレスファミリをサポートしていますが、そのようなHIP対応のアプリケーションが広くホストシステムがアップグレードされている場合でも展開されるまでには長い時間がかかるかもしれません。この情報資料では、システムがHIP-認識しているが、アプリケーションではない、とのことを考え、ローカルシステム上の問題を解決するために実装し、早期導入を支援することを目的としている状況でHIPを使用してに関する実装し、アプリケーション・プログラミング・インターフェース（API）の問題について説明しますHIPの増分の展開について。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Enabling HIP Transparently within the System ....................4
3.1. Applying HIP to Cases in Which IP Addresses Are Used .......4
3.2. Interposing a HIP-Aware Agent in the DNS Resolution ........6
3.3. Discussion .................................................7
4. Users Invoking HIP with a Legacy Application ....................8
4.1. Connecting to a HIT or LSI .................................8
4.2. Using a Modified DNS Name ..................................9
4.3. Other Techniques ...........................................9
5. Local Address Management ........................................9
6. Security Considerations ........................................11
7. Acknowledgments ................................................12
8. Informative References .........................................12
The Host Identity Protocol (HIP) [RFC5201] is an experimental effort in the IETF and IRTF to study a new public-key-based name space for use as host identifiers in Internet protocols. Fully deployed, the HIP architecture would permit applications and users to explicitly request the system to send packets to another host by expressing a location-independent unique name of a peer host when the system call to connect or send packets is performed. However, there will be a transition period during which systems become HIP-enabled but applications are not. This informational document does not propose normative specification or even suggest that different HIP implementations use more uniform methods for legacy application support, but is intended instead to aid implementors and early adopters in thinking about and solving systems issues regarding the incremental deployment of HIP.
ホスト識別プロトコル（HIP）[RFC5201]はインターネットプロトコルでホスト識別子として使用するための新しい公開鍵ベースの名前空間を研究するIETFとIRTFで実験的な取り組みです。完全に展開、HIPアーキテクチャは、アプリケーションやユーザーが明示的にシステムコールを接続するか、または実行されたパケットを送信する際に、ピアのホストの場所に依存しない固有の名前を発現させることにより、別のホストにパケットを送信するようにシステムに要求することを許可します。しかし、システムはHIP-有効になりますが、アプリケーションがされていない時の移行期間があるでしょう。この情報のドキュメントは、規範的な仕様を提案したり、異なるHIP実装がレガシーアプリケーションをサポートするためのより均一な方法を使用していますが、について考えるとHIPの増分展開に関するシステムの問題を解決するために実装し、早期導入を支援する代わりに意図されていることを示唆していません。
When applications and systems are both HIP-aware, the coordination between the application and the system can be straightforward. For example, using the terminology of the widely used sockets Application Programming Interface (API), the application can issue a system call to send packets to another host by naming it explicitly, and the system can perform the necessary name-to-address mapping to assign appropriate routable addresses to the packets. To enable this, a new address family for hosts could be defined, and additional API extensions could be defined (such as allowing IP addresses to be passed in the system call, along with the host name, as hints of where to initially try to reach the host).
アプリケーションやシステムは、HIP-意識の両方である場合には、アプリケーションとシステムの間の調整は簡単することができます。たとえば、広く使われているソケットアプリケーションプログラミングインターフェイス（API）の用語を使用して、アプリケーションが明示的に名前を付けることにより、別のホストにパケットを送信するシステムコールを発行することができ、システムはに必要な名前とアドレスのマッピングを実行することができますパケットに適切なルーティング可能なアドレスを割り当てます。これを有効にするには、ホストのための新しいアドレスファミリを定義することができ、追加のAPIの拡張機能は、IPアドレスが最初に到達しようとする場所のヒントとして、ホスト名とともに、システムコールに渡さできるようにすることとして（定義することができザ・ホスト）。
This document does not define a native HIP API such as described above. Rather, this document is concerned with the scenario in which the application is not HIP-aware and a traditional IP-address-based API is used by the application.
この文書では、上記のようなネイティブHIPのAPIを定義していません。むしろ、このドキュメントは、アプリケーションがHIP-認識せず、従来のIPアドレスベースのAPIは、アプリケーションによって使用されるシナリオと懸念しています。
The discussion so far assumes that applications are written directly to a sockets API. However, many applications are built on top of middleware that exports a higher-level API to the application. In this case, for the purpose of this document, we refer to the combination of the middleware and the middleware-based application as an overall application, or client of the sockets API.
議論は、これまでのアプリケーションは、ソケットAPIに直接書き込まれていることを前提としています。しかし、多くのアプリケーションでは、アプリケーションに、より高いレベルのAPIをエクスポートミドルウェアの上に構築されています。この場合は、このドキュメントの目的のために、私たちは、ミドルウェア、アプリケーション全体としてのミドルウェアベースのアプリケーション、またはソケットAPIのクライアントの組み合わせを参照してください。
When HIP is enabled on a system, but the applications are not HIP-aware, there are a few basic possibilities to use HIP, each of which may or may not be supported by a given HIP implementation. We report here on techniques that have been used or considered by experimental HIP implementations. We organize the discussion around the policy chosen to use or expose HIP to the applications. The first option is that users are completely unaware of HIP, or are unable to control whether or not HIP is invoked, but rather the system chooses to enable HIP for some or all sessions based on policy. The second option is that the user makes a decision to try to use HIP by conveying this information somehow within the constraints of the unmodified application. We discuss both of these use cases in detail below.
HIPは、システム上で有効になりますが、アプリケーションはHIP-認識していないされた場合、または指定されたHIP実装によってサポートされていない可能性があり、それぞれがHIPを使用するには、いくつかの基本的な可能性があります。我々は実験的なHIP実装で使用されるか検討されている技術をここに報告します。私たちは、アプリケーションにHIPを使用するか、または公開することを選択したポリシーを中心に議論を整理します。最初のオプションは、ユーザーがHIPの完全に気づいていない、またはHIPが呼び出されるかどうかを制御することができないということですが、むしろシステムは、ポリシーに基づいて、一部またはすべてのセッションのHIPを有効にすることを選択します。 2番目のオプションは、ユーザーが変更されていないアプリケーションの制約内で何とかこの情報を伝えることでHIPを使用しようとする決定を下すことです。当社は、以下に詳細にこれらの使用例の両方を議論します。
HIP was designed to work with unmodified applications, to ease incremental deployment. For instance, the HIT is the same size as the IPv6 address, and the design thinking was that, during initial experiments and transition periods, the HITs could substitute in data structures where IPv6 addresses were expected. However, to a varying degree depending on the mechanism employed, such use of HIP can alter the semantics of what is considered to be an IP address by applications. Applications use IP addresses as short-lived local handles, long-lived application associations, callbacks, referrals, and identity comparisons [APP-REF]. The transition techniques described below have implications on these different uses of IP addresses by legacy applications, and we will try to clarify these implications in the below discussions.
HIPは、増分の展開を容易にするために、変更されていないアプリケーションで動作するように設計されました。例えば、HITは、IPv6アドレスと同じサイズ、デザイン思考は、最初の実験と移行期間中に、ヒットがIPv6アドレスが期待されたデータ構造に置き換えることができ、ということでしたさ。しかし、採用のメカニズムに応じて、様々な程度に、HIPのような使用は、アプリケーションによるIPアドレスであると考えられるものの意味を変えることができます。アプリケーションは、IPは、のように短命ローカルハンドル、長寿命アプリケーション団体、コールバック、紹介、および同一性比較[APP-REFを]アドレスを使用します。下記の移行技術は、従来のアプリケーションによって、IPアドレスのこれらの異なる用途の意味合いを持っている、と私たちは以下の議論では、これらの影響を明確にしようとします。
Callback: The application at one end retrieves the IP address of the peer and uses that to later communicate "back" to the peer. An example is the FTP PORT command.
コールバック：一端のアプリケーションは、ピアのIPアドレスを取得し、後にピアに「戻る」通信することを使用します。例では、FTP PORTコマンドです。
Host Identity: An abstract concept applied to a computing platform.
コンピューティング・プラットフォームに適用される抽象的な概念：アイデンティティをホストします。
Host Identifier (HI): A public key of an asymmetric key pair used as a name for a Host Identity. More details are available in [RFC5201].
ホストIDの名前として使用される非対称鍵ペアの公開鍵：識別子（HI）をホスト。詳細は[RFC5201]でご利用いただけます。
Host Identity Tag (HIT): A 128-bit quantity composed with the hash of a Host Identity. More details are available in [RFC4843] and [RFC5201].
ホストIDのハッシュとなる128ビット量：アイデンティティタグ（HIT）をホスト。詳細は[RFC4843]と[RFC5201]でご利用いただけます。
Local Scope Identifier (LSI): A 32- or 128-bit quantity locally representing the Host Identity at the IPv4 or IPv6 API.
ローカルスコープ識別子（LSI）：ローカルIPv4またはIPv6 APIのホストIDを表す32ビットまたは128ビット量。
Long-lived application associations: The IP address is retained by the application for several instances of communication.
長寿命アプリケーション団体：IPアドレスは通信の複数のインスタンスのためのアプリケーションによって保持されます。
Referral: In an application with more than two parties, party B takes the IP address of party A and passes that to party C. After this, party C uses the IP address to communicate with A.
紹介：つ以上の当事者とのアプリケーションでは、パーティBは、パーティAのIPアドレスを取得し、この後当事者Cに、当事者Cは、Aと通信するためのIPアドレスを使用することを渡し
Resolver: The system function used by applications to resolve domain names to IP addresses.
リゾルバ：ドメイン名をIPアドレスに解決するためにアプリケーションで使用されるシステム機能。
Short-lived local handle: The IP addresses is never retained by the application. The only usage is for the application to pass it from the DNS APIs (e.g., getaddrinfo()) and the API to the protocol stack (e.g., connect() or sendto()).
短命のローカルハンドル：IPアドレスは、アプリケーションによって保持されることはありません。のみ使用は、DNSのAPI（例えば、はgetaddrinfo（））およびプロトコルスタック（例えば、（接続）またはのsendto（））のAPIからそれを通過するアプリケーションのためのものです。
When both users and applications are unaware of HIP, but the host administrator chooses to use HIP between hosts, a few options are possible. The first basic option is to perform a mapping of the application-provided IP address to a host identifier within the stack. The second option, if DNS is used, is to interpose a local agent in the DNS resolution process and to return to the application a HIT or a locally scoped handle, formatted like an IP address.
両方のユーザーやアプリケーションがHIPに気づいていないが、ホスト管理者は、ホスト間でHIPを使用することを選択した場合、いくつかのオプションが可能です。最初の基本的なオプションは、スタック内のホスト識別子にアプリケーションが提供するIPアドレスのマッピングを実行することです。 DNSが使用されている場合は、2番目のオプションは、DNS解決プロセスでローカルエージェントを挟むようにし、IPアドレスのようにフォーマットされたアプリケーションHITまたはローカルスコープハンドル、に戻ることです。
Consider the case in which an application issues a "connect(ip)" system call to set the default destination to a system named by address "ip", but for which the host administrator would like to enable HIP to protect the communications. The user or application intends for the system to communicate with the host reachable at that IP address. The decision to invoke HIP must be done on the basis of host policy. For example, when an IPsec-based implementation of HIP is being used, a policy may be entered into the security policy database that mandates to use or to try HIP based on a match on the source or destination IP address, port numbers, or other factors.
アプリケーションがアドレス「IP」によって指定されたシステムへのデフォルトの保存先を設定するには、「接続（IP）」システムコールを発行した場合を考えてみますが、そのためにホスト管理者は、通信を保護するためにHIPを可能にしたいと思います。システムは、そのIPアドレスに到達可能なホストと通信するためのユーザーやアプリケーションが意図しています。 HIPを呼び出すための決定は、ホストポリシーに基づいて行われなければなりません。 HIPのIPsecベースの実装が使用されている場合、例えば、ポリシーが使用する又は送信元または宛先IPアドレス、ポート番号、または他の上の一致に基づいてHIPを試みるために義務付けセキュリティポリシーデータベースに入力することができます要因。
The mapping of IP address to host identifier may be implemented by modifying the host operating system or by wrapping the existing sockets API, such as in the TESLA approach [TESLA].
識別子をホストするIPアドレスのマッピングは、ホストオペレーティングシステムを修正することによって、またはそのようなテスラアプローチ[TESLA]のように、既存のソケットAPIをラップすることによって実現されてもよいです。
There are a number of ways that HIP could be configured by the host administrator in such a scenario.
HIPは、このようなシナリオでのホスト管理者によって構成されることができるいくつかの方法があります。
Manual configuration:
手動設定：
Pre-existing Security Associations (SAs) may be available due to previous administrative action, or a binding between an IP address and a HIT could be stored in a configuration file or database.
既存のセキュリティアソシエーション（SA）が原因以前の管理アクションに使用可能であってもよいし、IPアドレスとHIT間の結合コンフィギュレーションファイルまたはデータベースに記憶することができます。
Opportunistically:
日和見：
The system could send an I1 to the Responder with an empty value for Responder HIT.
システムは、レスポンダHITに空の値とレスポンダにI1を送ることができます。
Using DNS to map IP addresses to HIs:
彼にIPアドレスをマッピングするためにDNSを使用します：
If the Responder has host identifiers registered in the forward DNS zone and has a PTR record in the reverse zone, the Initiator could perform a reverse+forward lookup to learn the HIT associated with the address. Although the approach should work under normal circumstances, it has not been tested to verify that there are no recursion or bootstrapping issues, particularly if HIP is used to secure the connection to the DNS servers. Discussion of the security implications of the use or absence of DNS Security (DNSSEC) is deferred to the Security Considerations section.
Responderが前方DNSゾーンに登録されているホストの識別子を持っており、逆ゾーンにPTRレコードを持っている場合、イニシエータは、アドレスに関連付けられているHITを学ぶために逆+前方参照を行うことができます。アプローチは、通常の状況下で動作するはずですが、HIPは、DNSサーバへの接続を確保するために使用されている場合は特に、何の再帰またはブートストラップの問題がないことを確認するためにテストされていません。 DNSセキュリティ（DNSSEC）の使用または不在のセキュリティへの影響についての議論は、Security Considerations部に延期されます。
Using HIP in the above fashion can cause additional setup delays compared to using plain IP. For opportunistic mode, a host must wait to learn whether the peer is HIP-capable, although the delays may be mitigated in some implementations by sending initial packets (e.g., TCP SYN) in parallel to the HIP I1 packet and waiting some time to receive a HIP R1 before processing a TCP SYN/ACK. Note that there presently does not exist specification for how to invoke such connections in parallel. Resolution latencies may also be incurred when using DNS in the above fashion.
上記の方法でHIPを使用すると、プレーンIPを使用する場合と比較して追加のセットアップ遅延を引き起こす可能性があります。遅延はHIPのI1パケットに並行して、最初のパケット（例えば、TCP SYN）を送信し、受信するためのいくつかの時間を待つことによって、いくつかの実装に軽減することができるが、日和見モードでは、ホストは、ピアがHIP-可能であるかどうかを学ぶために待機する必要がありますTCP SYN / ACKを処理する前にHIP R1。現在並行して、このような接続を起動する方法の仕様が存在しないことに留意されたいです。上記の方法でDNSを使用している場合、解像度の待ち時間も発生することがあります。
A possible way to reduce the above-noted latencies, in the case that the application uses DNS, would be for the system to opportunistically query for HIP records in parallel to other DNS resource records, and to temporarily cache the HITs returned with a DNS lookup, indexed by the IP addresses returned in the same entry, and pass the IP addresses up to the application as usual. If an application connects to one of those IP addresses within a short time after the lookup, the host should initiate a base exchange using the cached HITs. The benefit is that this removes the uncertainty/delay associated with opportunistic HIP, because the DNS record suggests that the peer is HIP-capable.
システムは日和見他のDNSリソースレコードに並列にHIPレコードを照会し、一時的ヒットがDNSルックアップで返さキャッシュするためのアプリケーションがDNSを使用する場合には、上記の待ち時間を低減することができる方法は、あろう、同じエントリで返されたIPアドレスでインデックスされ、いつものようにアプリケーションまでのIPアドレスを渡します。アプリケーションは、ルックアップ後の短い時間内にそれらのIPアドレスの1つに接続する場合、ホストは、キャッシュされたヒットを使用してベース交換を開始すべきです。利点は、DNSレコードは、ピアがHIP-可能であることを示唆しているので、これは、日和見HIPに伴う不確実性/遅延を除去することです。
In the previous section, it was noted that a HIP-unaware application might typically use the DNS to fetch IP addresses prior to invoking socket calls. A HIP-enabled system might make use of DNS to transparently fetch host identifiers for such domain names prior to the onset of communication.
前のセクションでは、HIP-意識しないアプリケーションは、通常のソケットコールを呼び出す前にIPアドレスを取得するためにDNSを使用する可能性があることを指摘しました。 HIP対応システムは、透過的に通信の開始に先立って、このようなドメイン名のホスト識別子を取得するためにDNSを利用するかもしれません。
A system with a local DNS agent could alternately return a Local Scope Identifier (LSI) or HIT rather than an IP address, if HIP information is available in the DNS or other directory that binds a particular domain name to a host identifier, and otherwise to return an IP address as usual. The system can then maintain a mapping between LSI and host identifier and perform the appropriate conversion at the system call interface or below. The application uses the LSI or HIT as it would an IP address. This technique has been used in overlay networking experiments such as the Internet Indirection Infrastructure (i3) and by at least one HIP implementation.
HIP情報がホスト識別子に特定のドメイン名を結合するDNSまたは他のディレクトリで提供され、それ以外の場合、ローカルDNS剤とシステムが交互に、ローカルスコープ識別子（LSI）又はHITはなくIPアドレスを返すことができいつものようにIPアドレスを返します。次に、システムは、LSIとホスト識別子との間のマッピングを維持し、システムコールインターフェースまたは下に適切な変換を行うことができます。アプリケーションは、LSIを使用するか、IPアドレスと同じようにHIT。この技術は、インターネット間接基盤（I3）などのオーバーレイネットワーキング実験に及び少なくとも一つのHIP実装によって使用されてきました。
In the case when resolvers can return multiple destination identifiers for an application, it may be configured that some of the identifiers can be HIP-based identifiers, and the rest can be IPv4 or IPv6 addresses. The system resolver may return HIP-based identifiers in front of the list of identifiers when the underlying system and policies support HIP. An application processing the identifiers sequentially will then first try a HIP-based connection and only then other non-HIP based connections. However, certain applications may launch the connections in parallel. In such a case, the non-HIP connections may succeed before HIP connections. Based on local system policies, a system may disallow such behavior and return only HIP-based identifiers when they are found from DNS.
リゾルバは、アプリケーションのための複数の宛先識別子を返すことができる場合には、識別子のいくつかは、HIPベースの識別子とすることができるように構成されてもよく、残りはIPv4またはIPv6アドレスであってもよいです。基盤となるシステムと政策がHIPをサポートしている場合、システムのリゾルバは、識別子のリストの前にHIPベースの識別子を返すことがあります。識別子を順次処理するアプリケーションは、第1のHIPベースの接続のみ、他の非HIP基づいて接続を試みます。しかし、特定のアプリケーションは、並列に接続を起動することができます。そのような場合には、非HIP接続はHIP接続する前に成功する可能性があります。ローカルシステムポリシーに基づいて、システムはそのような行動を禁止し、それらがDNSから発見された場合にのみHIPベースの識別子を返すことがあります。
If the application obtains LSIs or HITs that it treats as IP addresses, a few potential hazards arise. First, applications that perform referrals may pass the LSI to another system that has no system context to resolve the LSI back to a host identifier or an IP address. Note that these are the same type of applications that will likely break if used over certain types of network address translators (NATs). Second, applications may cache the results of DNS queries for a long time, and it may be hard for a HIP system to determine when to perform garbage collection on the LSI bindings. However, when using HITs, the security of using the HITs for identity comparison may be stronger than in the case of using IP addresses.
アプリケーションは、LSIの取得や、それがIPアドレスとして扱うことをヒットした場合、いくつかの潜在的な危険が生じます。まず、紹介を実行するアプリケーションはバックホスト識別子またはIPアドレスへのLSIを解決するために、何のシステムコンテキストを持っていない別のシステムにLSIを渡すことができます。これらは、ネットワークアドレス変換器（NAT）の特定の種類の上で使用した場合可能性が壊れるのアプリケーションと同じタイプであることに注意してください。第二に、アプリケーションは、長い時間のためにDNSクエリの結果をキャッシュすることができ、LSIのバインディングにガベージコレクションを実行する際にHIPシステムが判断することは難しいかもしれません。ヒットを使用している場合ただし、同一性比較のためにヒットを使用してのセキュリティはIPアドレスを使用した場合よりも強いかもしれません。
Finally, applications may generate log files, and administrators or other consumers of these log files may become confused to find LSIs or HITs instead of IP addresses. Therefore, it is recommended that the HIP software logs the HITs, LSIs (if applicable), corresponding IP addresses, and Fully Qualified Domain Name (FQDN)-related information so that administrators can correlate other logs with HIP identifiers.
最後に、アプリケーションは、ログファイルを生成することができ、かつ管理者またはこれらのログ・ファイルの他の消費者は、IPアドレスの代わりにLSIのか、ヒットを見つけるために混乱してしまうことがあります。したがって、それはHIPソフトウェアがヒットを記録しますことをお勧めします、のLSI（該当する場合）、管理者がHIP識別子と他のログを相関できるように、IPアドレス、および完全修飾ドメイン名（FQDN）関連情報を対応します。
It may be possible for an LSI or HIT to be routable or resolvable, either directly or through an overlay, in which case it would be preferable for applications to handle such names instead of IP addresses. However, such networks are out of scope of this document.
LSIやHITが直接またはアプリケーションではなく、IPアドレスのような名前を処理することが好ましいであろうその場合、オーバーレイを介して、ルーティング可能なまたは分解可能であることが可能であってもよいです。しかし、このようなネットワークは、この文書の範囲外です。
Solutions preserving the use of IP addresses in the applications have the benefit of better support for applications that use IP addresses for long-lived application associations, callbacks, and referrals, although it should be noted that applications are discouraged from using IP addresses in this manner due to the frequent presence of NATs [RFC1958]. However, they have weaker security properties than the approaches outlined in Section 3.2 and Section 4, because the binding between host identifier and address is weak and not visible to the application or user. In fact, the semantics of the application's "connect(ip)" call may be interpreted as "connect me to the system reachable at IP address ip" but perhaps no stronger semantics than that. HIP can be used in this case to provide perfect forward secrecy and authentication, but not to strongly authenticate the peer at the onset of communications.
アプリケーションがこのようにIPアドレスを使用してから、落胆していることに留意すべきであるが、アプリケーションにおけるIPアドレスの使用を維持するソリューションは、アプリケーションの団体、コールバック、および照会長寿命のためのIPアドレスを使用するアプリケーションのためのより良いサポートの利点を持っています原因のNAT [RFC1958]を頻繁に存在します。ホスト識別子とアドレスとの間の結合が弱く、アプリケーションまたはユーザには見えないのでしかし、それらは、セクション3.2及びセクション4に概説の方法よりも弱いセキュリティ特性を有します。実際には、アプリケーションの「接続（IP）」コールの意味は、それよりも、おそらくノー強い意味論「IPアドレスIPで到達可能なシステムに私を接続する」と解釈することができます。 HIPは完全転送秘密と認証を提供するために、この場合に使用することができますが、強く通信の開始時にピアを認証することはありません。
Using IP addresses at the application layer may not provide the full potential benefits of HIP mobility support. It allows for mobility if the system is able to readdress long-lived, connected sockets upon a HIP readdress event. However, as in current systems, mobility will break in the connectionless case, when an application caches the IP address and repeatedly calls sendto(), or in the case of TCP when the system later opens additional sockets to the same destination.
アプリケーション層でIPアドレスを使用すると、HIPモビリティサポートの完全な潜在的な利点を提供することはできません。システムはHIPの回送イベント時に長寿命、接続ソケットを回送することができる場合には、モビリティが可能になります。しかし、現在のシステムのように、移動度）が、アプリケーションがIPアドレスをキャッシュし、繰り返し（はsendtoを呼び出すときに、コネクションレス場合に壊れる、またはTCPの場合のシステムは、後で同じ宛先に追加のソケットを開いたとき。
Section 4.1.6 of the base HIP protocol specification [RFC5201] states that implementations that learn of HIT-to-IP address bindings through the use of HIP opportunistic mode must not enforce those bindings on later communications sessions. This implies that when IP addresses are used by the applications, systems that attempt to opportunistically set up HIP must not assume that later sessions to the same address will communicate with the same host.
ベースHIPプロトコル仕様[RFC5201]のセクション4.1.6は、HIP日和見モードの使用を通じてHITとIPアドレスバインディングの学習実装は後の通信セッションにそれらのバインディングを適用してはならないと述べています。これは、IPアドレスがアプリケーションで使用されたときに、日和見HIPを設定しようとするとシステムが同じアドレスへの以降のセッションが同じホストと通信することを想定してはならないことを意味します。
The legacy application is unaware of HIP and therefore cannot notify the user when the application uses HIP. However, the operating system can notify the user of the usage of HIP through a user agent. Further, it is possible for the user agent to name the network application that caused a HIP-related event. This way, the user is aware when he or she is using HIP even though the legacy network application is not. Based on usability tests from initial deployments, displaying the HITs and LSIs should be avoided in user interfaces. Instead, traditional security measures (lock pictures, colored address bars) should be used where possible.
レガシーアプリケーションは、アプリケーションがHIPを使用する場合、ユーザーに通知することができないため、HIPを認識していないと。しかし、オペレーティング・システムは、ユーザエージェントを介してHIPの使用をユーザに通知することができます。ユーザエージェントがHIP関連のイベントを発生させたネットワークアプリケーションに名前を付けるためにさらに、それが可能です。彼または彼女は、レガシーネットワークアプリケーションがなくても、HIPを使用している場合は、この方法では、ユーザーが認識しています。ヒットを表示する、初期導入からユーザビリティテストに基づいてLSIがユーザインタフェースに避けるべきです。代わりに、従来のセキュリティ対策（ロック絵、色のアドレスバーが）可能な場合に使用する必要があります。
One drawback to spoofing the DNS resolution is that some applications, or selected instances of an application, actually may want to fetch IP addresses (e.g., diagnostic applications such as ping). One way to provide finer granularity on whether the resolver returns an IP address or an LSI is to have the user form a modified domain name when he or she wants to invoke HIP. This leads us to consider, in the next section, use cases for which the end user explicitly and selectively chooses to enable HIP.
DNS解決を偽装するための一つの欠点は、いくつかのアプリケーション、またはアプリケーションの選択されたインスタンスは、実際のIPアドレス（pingなど、例えば、診断用途）をフェッチすることです。リゾルバは、IPアドレスやLSIを返すかどうかについて、より細かい粒度を提供する1つの方法は、彼または彼女はHIPを起動したい場合、ユーザが変更されたドメイン名を形成することです。これは、エンドユーザーが明示的かつ選択的にHIPを有効にすることを選択したために例を使用して、次のセクションでは、検討する私たちをリード。
The previous section described approaches for configuring HIP for legacy applications that did not necessarily involve the user. However, there may be cases in which a legacy application user wants to use HIP for a given application instance by signaling to the HIP-enabled system in some way. If the application user interface or configuration file accepts IP addresses, there may be an opportunity to provide a HIT or an LSI in its place. Furthermore, if the application uses DNS, a user may provide a specially crafted domain name to signal to the resolver to fetch HIP records and to signal to the system to use HIP. We describe both of these approaches below.
前のセクションでは、必ずしもユーザーが関与していないレガシーアプリケーションのためのHIPを設定するためのアプローチを説明しました。しかし、レガシー・アプリケーション・ユーザが何らかの方法でHIP対応システムへのシグナリングによって与えられたアプリケーションインスタンスのためのHIPを使用したいする場合があります。アプリケーションのユーザーインターフェイスまたは設定ファイルは、IPアドレスを受け入れた場合、その場所にHITかLSIを提供する機会があるかもしれません。アプリケーションは、DNSを使用している場合また、ユーザは、HIPレコードをフェッチし、HIPを使用するシステムに知らせるためにレゾルバに知らせるために、特別に細工されたドメイン名を提供することができます。当社は、以下のこれらのアプローチの両方を説明します。
Section 3.2 above describes the use of HITs or LSIs as spoofed return values of the DNS resolution process. A similar approach that is more explicit is to configure the application to connect directly to a HIT (e.g., "connect(HIT)" as a socket call). This scenario has stronger security semantics, because the application is asking the system to send packets specifically to the named peer system. HITs have been defined as Overlay Routable Cryptographic Hash Identifiers (ORCHIDs) such that they cannot be confused with routable IP addresses; see [RFC4843].
上記セクション3.2 DNS解決プロセスのスプーフィングされた戻り値としてヒットやLSIの使用を記載しています。より明示的である同様のアプローチは、HIT（例えば、ソケット・コールとして「（HIT）を接続」）に直接接続するようにアプリケーションを構成することです。アプリケーションは、名前のピアシステムに特異的にパケットを送信するシステムを求めているので、このシナリオは、より強力なセキュリティセマンティクスを持っています。ヒットは、彼らがルーティング可能なIPアドレスと混同されないような（蘭）オーバーレイルーティング可能な暗号化ハッシュ識別子として定義されています。 [RFC4843]を参照してください。
This approach also has a few challenges. Using HITs can be more cumbersome for human users (due to the flat HIT name space) than using either IPv6 addresses or domain names. Another challenge with this approach is in actually finding the IP addresses to use, based on the HIT. Some type of HIT resolution service would be needed in this case. A third challenge of this approach is in supporting callbacks and referrals to possibly non-HIP-aware hosts. However, since most communications in this case would likely be to other HIP-aware hosts (else the initial HIP associations would fail to establish), the resulting referral problem may be that the peer host supports HIP but is not able to perform HIT resolution for some reason.
このアプローチはまた、いくつかの課題があります。ヒットを使用すると、IPv6アドレスまたはドメイン名のいずれかを使用するよりも（フラットHIT名前空間による）人間のユーザのために、より面倒なことができます。このアプローチのもう一つの課題は、実際にHITに基づいて、使用するIPアドレスを見つけることです。 HIT解決サービスのいくつかのタイプが、この場合に必要とされるであろう。このアプローチの第三の課題は、おそらく非HIP-意識したホストへのコールバックや紹介をサポートしています。ただし、この場合で以来、最もコミュニケーションの可能性が高い（他の初期HIPの関連が確立する失敗します）他のHIP-意識のホストになり、結果として紹介問題は、ピアのホストがHIPをサポートしていますが、ためにHIT解決を実行できないこともあり何らかの理由で。
Specifically, if the application requests to resolve "HIP-www.example.com" (or some similar prefix string), then the system returns an LSI, while if the application requests to resolve "www.example.com", IP address(es) are returned as usual. The use of a prefix rather than suffix is recommended, and the use of a string delimiter that is not a dot (".") is also recommended, to reduce the likelihood that such modified DNS names are mistakenly treated as names rooted at a new top-level domain. Limits of domain name length or label length (255 or 63, respectively) should be considered when prepending any prefixes.
「HIP-www.example.com」を解決するために、アプリケーションの要求（またはいくつかの類似の接頭文字列）場合は、アプリケーションの要求が解決した場合ながら具体的に、システムは、LSIを返す「www.example.com」、IPアドレス（ ES）いつものように返されます。そのような修飾DNS名が誤って新しいルートと名前として扱われる可能性を低減するために、むしろ接尾よりも接頭語の使用が推奨され、ドット（「」）ではない文字列の区切り文字の使用も推奨されますトップレベルドメイン。任意の接頭辞を付加する場合、ドメイン名の長さやラベルの長さ（255または63、それぞれ）の限界を考慮すべきです。
Alternatives to using a modified DNS name that have been experimented with include the following. Command-line tools or tools with a graphical user interface (GUI) can be provided by the system to allow a user to set the policy on which applications use HIP. Another common technique, for dynamically linked applications, is to dynamically link the application to a modified library that wraps the system calls and interposes HIP layer communications on them; this can be invoked by the user by running commands through a special shell, for example.
で実験されている修正DNS名を使用しての代替には以下のものが挙げられます。グラフィカル・ユーザ・インタフェース（GUI）とコマンドラインツールまたはツールは、アプリケーションがHIPを使用したポリシーを設定することをユーザに可能にするためにシステムによって提供することができます。他の一般的な技術は、動的にリンクされたアプリケーションのために、動的にシステムコールをラップし、それらにHIP層のコミュニケーションを介在修正ライブラリにアプリケーションをリンクすることです。これは、例えば、特別なシェルを介してコマンドを実行することにより、ユーザによって起動することができます。
The previous two sections focused mainly on controlling client behavior (HIP initiator). We must also consider the behavior for servers. Typically, a server binds to a wildcard IP address and well-known port. In the case of HIP use with legacy server implementations, there are again a few options. The system may be configured manually to always, optionally (depending on the client behavior), or never use HIP with a particular service, as a matter of policy, when the server specifies a wildcard (IP) address.
前の2つのセクションでは、クライアントの動作（HIPイニシエータ）を制御することに主に焦点を当てました。また、サーバの動作を考慮する必要があります。一般的に、サーバーは、ワイルドカードIPアドレスとよく知られているポートにバインドします。レガシーサーバー実装とHIP利用の場合は、いくつかのオプションが再びあります。システムは、（クライアントの動作に応じて）、必要に応じて、常にに手動で設定されていない、または決してサーバは、ワイルドカード（IP）アドレスを指定した場合、政策の問題として、特定のサービスにHIPを使用することができます。
When a system API call such as getaddrinfo [RFC3493] is used for resolving local addresses, it may also return HITs or LSIs, if the system has assigned HITs or LSIs to internal virtual interfaces (common in many HIP implementations). The application may use such identifiers as addresses in subsequent socket calls.
このようのgetaddrinfo [RFC3493]などのシステムAPIコールがローカルアドレスを解決するために使用される場合、システムが（多くのHIP実装で共通）内部の仮想インターフェイスにヒットやLSIを割り当てられている場合、それはまた、ヒットやLSIを返すことができます。アプリケーションは、後続のソケット・コールのアドレスのような識別子を使用してもよいです。
Some applications may try to bind a socket to a specific local address, or may implement server-side access control lists based on socket calls such as getsockname() and getpeername() in the C-based socket APIs. If the local address specified is an IP address, again, the underlying system may be configured to still use HIP. If the local address specified is a HIT (Section 4), the system should enforce that connections to the local application can only arrive to the specified HIT. If a system has many HIs, an application that binds to a single HIT cannot accept connections to the other HIs but the one corresponding to the specified HIT.
一部のアプリケーションでは、特定のローカルアドレスにソケットをバインドしようとしたり、ソケットなどのgetsocknameなど（）の呼び出しとCベースのソケットAPIでgetpeername（）に基づいて、サーバ側のアクセス制御リストを実装することができます。指定されたローカルアドレスはIPアドレスである場合には、再び、基礎となるシステムは、まだHIPを使用するように構成することができます。指定されたローカルアドレスは、HIT（セクション4）である場合、システムは、ローカル・アプリケーションへの接続のみを指定HITに到着することができることを強制すべきです。システムは、彼の多くを持っている場合は、単一HITに結合するアプリケーションは、他の彼が、指定されたHITに対応する一つへの接続を受け入れることはできません。
When a host has multiple HIs and the socket behavior does not prescribe the use of any particular HI as a local identifier, it is a matter of local policy as to how to select a HI to serve as a local identifier. However, systems that bind to a wildcard may face problems when multiple HITs or LSIs are defined. These problems are not specific to HIP per se, but are also encountered in non-HIP multihoming scenarios with applications not designed for multihoming.
ホストが複数ある場合、彼とソケットの動作はローカル識別子として、特定のHIの使用を規定していない、それがローカル識別子として機能するようにHIを選択する方法のようにローカルポリシーの問題です。複数のヒットやLSIが定義されている場合しかし、ワイルドカードに結合するシステムは、問題に直面してもよいです。これらの問題は、それ自体がHIPに固有のものではありませんが、また、マルチホーミングのために設計されていないアプリケーションと非HIPマルチホーミングシナリオに直面しています。
As an example, consider a client application that sends a UDP datagram to a server that is bound to a wildcard. The server application receives the packet using recvfrom() and sends a response using sendto(). The problem here is that sendto() may actually use a different server HIT than the client assumes. The client will drop the response packet when the client implements access control on the UDP socket (e.g., using connect()).
例として、ワイルドカードにバインドされているサーバーにUDPデータグラムを送信するクライアントアプリケーションを考えてみます。サーバ・アプリケーションは、（のrecvfromを使用してパケットを受信する）とのsendto（）を使用して応答を送信します。ここでの問題は、クライアントが想定しているよりはsendto（）が実際には異なるサーバーHITを使用することです。クライアントがUDPソケットのアクセス制御を実装する場合、クライアントは、応答パケットをドロップします（例えば、接続し使用して（））。
Reimplementing the server application using the sendmsg() and recvmsg() to support multihoming (particularly considering the ancillary data) would be the ultimate solution to this problem, but with legacy applications is not an option. As a workaround, we make suggestion for servers providing UDP-based services with non-multihoming-capable services. Such servers should announce only the HIT or public key that matches to the default outgoing HIT of the host to avoid such problems.
（特に補助的なデータを考慮して）マルチホーミングをサポートするためにsendmsg（）とのrecvmsg（）を使用して、サーバーアプリケーションを再実装することは、この問題に対する究極の解決策であってもよいが、レガシーアプリケーションをオプションではありませんでしょう。回避策として、我々は非マルチホーミング可能なサービスとUDPベースのサービスを提供するサーバのための提案を行います。このようなサーバーでは、このような問題を回避するために、ホストのデフォルトの発信HITに一致しただけHITまたは公開鍵を公表すべきです。
Finally, some applications may create a connection to a local HIT. In such a case, the local system may use NULL encryption to avoid unnecessary encryption overhead, and may be otherwise more permissive than usual such as excluding authentication, Diffie-Hellman exchange, and puzzle.
最後に、いくつかのアプリケーションは、ローカルHITへの接続を作成することができます。このような場合には、ローカルシステムは、不必要な暗号化のオーバーヘッドを回避するためにNULL暗号化を使用することができ、そのような認証のDiffie-Hellman交換、およびパズルを除くように通常よりもそれ以外の場合より許容することができます。
In this section, we discuss the security of the system in general terms, outlining some of the security properties. However, this section is not intended to provide a complete risk analysis. Such an analysis would, in any case, be dependent on the actual application using HIP, and is therefore considered out of scope.
このセクションでは、セキュリティプロパティのいくつかを概説し、一般的にシステムのセキュリティを議論します。しかし、このセクションは完全なリスク分析を提供するものではありません。そのような分析は、いずれの場合も、HIPを用いて、実際のアプリケーションに依存することになり、したがって範囲外であると考えられます。
The scenarios outlined above differ considerably in their security properties. When the DNS is used, there are further differences related to whether or not DNSSEC [RFC4033] is used, and whether the DNS zones are considered trustworthy enough. Here we mean that there should exist a delegation chain to whatever trust anchors are available in the respective trees, and the DNS zone administrators in charge of the netblock should be trusted to put in the right information.
上記で概説したシナリオは、セキュリティのプロパティでかなり異なります。 DNSを使用する場合は、かどうかDNSSEC [RFC4033]に関連し、さらに違いがあります使用、およびDNSゾーンは十分に信頼できると考えられているかどうかです。ここでは、アンカーがそれぞれの木に利用でき、ネットブロックを担当するDNSゾーンの管理者が適切な情報に置くために、信頼されなければならないものは何でも信頼に委任チェーンが存在しなければならないことを意味します。
When IP addresses are used by applications to name the peer system, the security properties depend on the configuration method. With manual configuration, the security of the system is comparable to a non-HIP system with similar IPsec policies. The security semantics of an initial opportunistic key exchange are roughly equal to non-secured IP; the exchange is vulnerable to man-in-the-middle attacks. However, the system is less vulnerable to connection hijacking attacks. If the DNS is used, if both zones are secured (or the HITs are stored in the reverse DNS record) and the client trusts the DNSSEC signatures, the system may provide a fairly high security level. However, much depends on the details of the implementation, the security and administrative practices used when signing the DNS zones, and other factors.
IPアドレスがピアシステムに名前を付けるためにアプリケーションによって使用されている場合は、セキュリティプロパティは、設定方法によって異なります。手動設定では、システムのセキュリティは、同様のIPsecポリシーと非HIPシステムに匹敵します。初期日和見鍵交換のセキュリティセマンティクスは、非セキュアなIPとほぼ同じです。交換は、man-in-the-middle攻撃に対して脆弱です。しかし、このシステムは、接続ハイジャック攻撃に対してより脆弱です。 DNSは、両方のゾーンが固定されている場合、使用されている（又はヒットが逆DNSレコードに格納されている）と、クライアントがDNSSEC署名を信頼している場合、システムは、かなり高いセキュリティレベルを提供することができます。しかし、多くの実装の詳細、DNSゾーンに署名する際に使用されるセキュリティと管理の実践、およびその他の要因に依存します。
Using the forward DNS to map a domain name into an LSI is a case that is closest to the most typical use scenarios today. If DNSSEC is used, the result is fairly similar to the current use of certificates with Transport Layer Security (TLS). If DNSSEC is not used, the result is fairly similar to the current use of plain IP, with the additional protection of data integrity, confidentiality, and prevention of connection hijacking that opportunistic HIP provides. If DNSSEC is used, data integrity and data origin authentication services are added to the normal DNS query protocol, thereby providing more certainty that the desired host is being contacted, if the DNS records themselves are trustworthy.
LSIにドメイン名をマッピングするために前方にDNSを使用することは、今日最も一般的な使用シナリオに最も近い場合です。 DNSSECを使用する場合、結果はトランスポート層セキュリティ（TLS）と証明書の現在の使用にかなり似ています。 DNSSECを使用しない場合、結果はデータの整合性、機密性、および日和見HIPが提供する接続ハイジャックの防止の付加的な保護と、プレーンIPの現在の使用にかなり似ています。 DNSSECが使用される場合、データの整合性とデータ発信元認証サービスは、それによってDNS自体が信頼できる記録する場合、所望の宿主は、接触されていることをより確実に提供する、通常のDNSクエリプロトコルに追加されます。
If the application is basing its operations on HITs, the connections become automatically secured due to the implicit channel bindings in HIP. That is, when the application makes a connect(HIT) system call, either the resulting packets will be sent to a node possessing the corresponding private key or the security association will fail to be established.
アプリケーションのヒットでその操作を基づかされている場合は、接続が自動的によるHIPにおける暗黙のチャネルバインディングに固定となります。すなわち、アプリケーションは、接続（HIT）システムコールを行う場合には、いずれかの結果として生じるパケットは、対応する秘密鍵またはセキュリティアソシエーションを確立する失敗所有ノードに送信されます。
When the system provides (spoofs) LSIs or HITs instead of IP addresses as the result of name resolution, the resultant fields may inadvertently show up in user interfaces and system logs, which may cause operational concerns for some network administrators. Therefore, it is recommended that the HIP software logs the HITs, LSIs (if applicable), corresponding IP addresses, and FQDN-related information so that administrators can correlate other logs with HIP identifiers.
システムは（スプーフィング）のLSIまたはその代わりに、名前解決の結果としてIPアドレスのヒットを提供する場合、得られたフィールドが誤っていくつかのネットワーク管理者の運用の問題を引き起こす可能性があり、ユーザインタフェース及びシステムログに表示してもよいです。したがって、管理者は、HIP識別子と他のログを関連付けることができるように、HIPソフトヒット、LSIを（該当する場合）、対応するIPアドレス、FQDNに関連する情報をログに記録することをお勧めします。
Jeff Ahrenholz, Gonzalo Camarillo, Alberto Garcia, Teemu Koponen, Julien Laganier, and Jukka Ylitalo have provided comments on different versions of this document. The document received substantial and useful comments during the review phase from David Black, Lars Eggert, Peter Koch, Thomas Narten, and Pekka Savola.
ジェフAhrenholz、ゴンサロ・カマリロ、アルベルト・ガルシア、テームKoponen、ジュリアンLaganier、およびユッカYlitaloは、このドキュメントの異なるバージョンにコメントを提供しています。文書はデビッド・ブラック、ラースEggertの、ピーター・コッホ、トーマスNarten氏、およびペッカSavolaからのレビュー・フェーズの間に実質的かつ有益なコメントを受けました。
[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月。
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
[RFC4843] Nikander、P.、Laganier、J.、およびF.デュポン、RFC 4843、2007年4月 "オーバーレイルーティング可能な暗号ハッシュ識別子（ORCHID）のIPv6プレフィックス"。
[TESLA] Salz, J., Balakrishnan, H., and A. Snoeren, "TESLA: A Transparent, Extensible Session-Layer Architecture for End-to-end Network Services", Proceedings of USENIX Symposium on Internet Technologies and Systems (USITS), pages 211-224, March 2003.
[TESLA] Salzの、J.、バラクリシュナン、H.、およびA. Snoeren、「TESLA：エンドツーエンドのネットワークサービスの透過的な、拡張可能なセッション層アーキテクチャ」、インターネット技術・システム上のUSENIXシンポジウム（USITS ）、頁211から224まで、2003年3月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]大工、B.、エド。、 "インターネットの建築原則"、RFC 1958、1996年6月。
[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月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493]ギリガン、R.、トムソン、S.、バウンド、J.、マッキャン、J.、およびW.スティーブンス、 "IPv6の基本的なソケットインタフェース拡張"、RFC 3493、2003年2月。
[APP_REF] Nordmark, E., "Shim6 Application Referral Issues", Work in Progress, July 2005.
[APP_REF] Nordmarkと、E.、 "SHIM6アプリケーションの紹介の問題"、進歩、2005年7月での作業。
Authors' Addresses
著者のアドレス
Thomas Henderson The Boeing Company P.O. Box 3707 Seattle, WA USA
トーマス・ヘンダーソンザ・ボーイング社の私書箱ボックス3707シアトル、WA USA
EMail: thomas.r.henderson@boeing.com
メールアドレス：thomas.r.henderson@boeing.com
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
Miika Komu Helsinki Institute for Information Technology Metsaenneidonkuja 4 Helsinki FIN-02420 FINLAND
情報技術Metsaenneidonkuja 4 FIN-02420ヘルシンキフィンランドMiikaこむヘルシンキ研究所
Phone: +358503841531 EMail: miika@iki.fi
電話：+358503841531 Eメール：miika@iki.fi
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に情報を記述してください。