[要約] RFC 5338は、Host Identity Protocol（HIP）を既存のアプリケーションと組み合わせるためのガイドラインを提供しています。このRFCの目的は、HIPを使用して既存のアプリケーションをセキュアにする方法を示すことです。
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
レガシーアプリケーションでホストIDプロトコルを使用します
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.
このドキュメントは、ホストIDプロトコル（HIP）で動作するためにレガシーアプリケーションを作成する方法の有益な概要です。HIPは、ネットワークスタック名に暗号化名スペースを追加することを提案しています。アプリケーションの視点から、股関節対応システムはホスト識別子の新しいアドレスファミリをサポートしますが、ホストシステムがアップグレードされた場合でも、そのような股関節認識アプリケーションが広く展開されるまでは長い時間がかかる可能性があります。この情報ドキュメントでは、システムが股関節を認識している状況での股関節の使用に関する実装およびアプリケーションプログラミングインターフェイス（API）の問題について説明します。股関節の増分展開に関して。
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アーキテクチャは、完全に展開され、アプリケーションとユーザーが、システムが接続または送信パケットを実行するときに、ピアホストの場所に依存しない一意の名前を表現することにより、システムに別のホストにパケットを送信するようにシステムに明示的に要求することができます。ただし、システムが股関節対応になりますが、アプリケーションはそうではない移行期間があります。この情報文書は、規範的な仕様を提案するものではなく、異なる股関節の実装がレガシーアプリケーションサポートのためにより均一な方法を使用することさえ示唆していませんが、代わりに、股関節の増分展開に関するシステムの問題を考え、解決する実装者と早期採用者を支援することを目的としています。
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).
アプリケーションとシステムが両方とも股関節が認められている場合、アプリケーションとシステムの間の調整は簡単です。たとえば、広く使用されているソケットアプリケーションプログラミングインターフェイス（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.
このドキュメントは、上記のようなネイティブの股関節APIを定義しません。むしろ、このドキュメントは、アプリケーションがヒップアウェアではなく、従来の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をアプリケーションにエクスポートするミドルウェアの上に構築されています。この場合、このドキュメントの目的のために、ミドルウェアとミドルウェアベースのアプリケーションの組み合わせを、全体的なアプリケーションまたはSockets 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.
システムで股関節が有効になっているが、アプリケーションが股関節を認識していない場合、股関節を使用する基本的な可能性がいくつかあります。ここでは、実験的な股関節の実装によって使用または検討された手法について報告します。私たちは、アプリケーションに股関節を使用または公開するために選択されたポリシーに関する議論を整理します。最初のオプションは、ユーザーが股関節を完全に知らないか、股関節が呼び出されるかどうかを制御できないことですが、システムはポリシーに基づいた一部またはすべてのセッションの股関節を有効にすることを選択します。2番目のオプションは、ユーザーが、変更されていないアプリケーションの制約内で何らかの形でこの情報を伝えることにより、股関節を使用しようとすることを決定することです。これらの両方のユースケースについては、以下で詳しく説明します。
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は、変更されていないアプリケーションを使用して、増分展開を容易にするように設計されています。たとえば、ヒットはIPv6アドレスと同じサイズであり、デザインの考え方は、最初の実験と移行期間中に、IPv6アドレスが予想されるデータ構造にヒットが代用できるということでした。ただし、採用されているメカニズムに応じてさまざまな程度まで、そのような股関節を使用すると、アプリケーションによってIPアドレスと見なされるもののセマンティクスが変更される可能性があります。アプリケーションは、IPアドレスを短命のローカルハンドル、長寿命のアプリケーションアソシエーション、コールバック、紹介、IDの比較[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ポートコマンドです。
Host Identity: An abstract concept applied to a computing platform.
ホストID：コンピューティングプラットフォームに適用される抽象的な概念。
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].
ホスト識別子（HI）：ホストIDの名前として使用される非対称キーペアの公開鍵。詳細については、[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タグ（HIT）：ホストIDのハッシュで構成される128ビット数量。詳細については、[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.
紹介：2つ以上の当事者がいるアプリケーションでは、パーティーBはパーティーAのIPアドレスを取得し、それをパーティCに渡します。この後、パーティーCはIPアドレスを使用してAと通信します。
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（）などなどを渡すことです。また、APIがプロトコルスタック（connect（）またはsend（）など）です。
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.
ユーザーとアプリケーションの両方が股関節に気付いていないが、ホスト管理者がホスト間で股関節を使用することを選択した場合、いくつかのオプションが可能です。最初の基本オプションは、アプリケーションが提供するIPアドレスのマッピングをスタック内のホスト識別子に実行することです。2番目のオプションは、DNSを使用している場合、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.
アプリケーションが「Connect（IP）」システムコールを発行する場合を検討して、デフォルトの宛先をアドレス「IP」という名前のシステムに設定しますが、ホスト管理者はHIPが通信を保護できるようにしたいと考えています。ユーザーまたはアプリケーションは、システムがそのIPアドレスで到達可能なホストと通信することを意図しています。股関節を呼び出す決定は、ホストポリシーに基づいて行われなければなりません。たとえば、IPSECベースの股関節の実装が使用されている場合、ソースまたは宛先IPアドレス、ポート番号、またはその他の一致に基づいて使用または股関節を試すことを義務付けるセキュリティポリシーデータベースにポリシーを入力することができます。要因。
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アプローチ[Tesla]などの既存のSockets 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.
既存のセキュリティ協会（SAS）は、以前の管理アクションまたはIPアドレスとヒット間のバインディングが構成ファイルまたはデータベースに保存される可能性があるため利用可能です。
Opportunistically:
日和見的に：
The system could send an I1 to the Responder with an empty value for Responder HIT.
システムは、レスポンダーヒットのための空の値でI1をレスポンダーに送信できます。
Using DNS to map IP addresses to HIs:
DNSを使用して、IPアドレスを彼にマッピングします。
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レコードがあるホスト識別子を持っている場合、イニシエーターは逆の前方検索を実行してアドレスに関連付けられたヒットを学習できます。このアプローチは通常の状況では機能するはずですが、特にDNSサーバーへの接続を確保するために股関節を使用している場合、再帰またはブートストラップの問題がないことを確認するためにテストされていません。DNSセキュリティ（DNSSEC）の使用または不在のセキュリティへの影響についての議論は、セキュリティに関する考慮事項セクションに延期されます。
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.
上記の方法で股関節を使用すると、プレーンIPを使用することと比較して、追加のセットアップ遅延を引き起こす可能性があります。日和見モードの場合、ホストはピアが股関節に対応できるかどうかを学ぶ必要がありますが、最初のパケット（例：TCP syn）をHIP I1パケットと並行して送信し、受け取る時間を待つことにより、いくつかの実装で遅延が軽減される可能性があります。TCP syn/ackを処理する前に、股関節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を使用する場合、上記のレイテンシーを減らす可能性のある方法は、システムが他のDNSリソースレコードと並行して股関節レコードを日和見的にクエリすることであり、DNSルックアップで返されるヒットを一時的にキャッシュすることです。、同じエントリで返されたIPアドレスによってインデックス付けされ、通常どおりアプリケーションにIPアドレスを渡します。アプリケーションが検索後すぐにそれらのIPアドレスのいずれかに接続する場合、ホストはキャッシュされたヒットを使用してベースエクスチェンジを開始する必要があります。利点は、DNSレコードがピアが股関節に対応していることを示唆しているため、日和見股関節に関連する不確実性/遅延を取り除くことです。
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.
前のセクションでは、通常、股関節退場者のアプリケーションが、ソケットコールを呼び出す前にDNSを使用してIPアドレスを取得する可能性があることに注意しました。股関節対応システムは、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.
ローカルDNSエージェントを持つシステムは、特定のドメイン名をホスト識別子にバインドするDNSまたは他のディレクトリでHIP情報が利用可能である場合、IPアドレスではなくローカルスコープ識別子（LSI）またはヒットを交互に返すことができます。いつものようにIPアドレスを返します。システムは、LSIとホスト識別子間のマッピングを維持し、システムコールインターフェイスまたは以下で適切な変換を実行できます。アプリケーションはLSIを使用するか、IPアドレスと同様にヒットします。この手法は、インターネット間接インフラストラクチャ（I3）や少なくとも1つの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.
リゾルバーがアプリケーションの複数の宛先識別子を返すことができる場合、識別子の一部が股関節ベースの識別子であり、残りはIPv4またはIPv6アドレスである可能性があることが設定される場合があります。システムリゾルバーは、基礎となるシステムとポリシーが股関節をサポートしている場合、識別子のリストの前で股関節ベースの識別子を返すことができます。識別子を順次処理するアプリケーション処理は、最初に股関節ベースの接続を試し、その後は他の非ヒップベースの接続を試します。ただし、特定のアプリケーションは接続を並行して起動する場合があります。そのような場合、非ヒップ接続は股関節接続の前に成功する可能性があります。ローカルシステムポリシーに基づいて、システムはそのような動作を禁止し、DNSから見つかった場合に股関節ベースの識別子のみを返す場合があります。
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.
アプリケーションがIPアドレスとして扱うLSIまたはヒットを取得した場合、いくつかの潜在的な危険が生じます。まず、紹介を実行するアプリケーションは、LSIをホスト識別子またはIPアドレスに戻すためのシステムコンテキストを持たない別のシステムに渡す場合があります。これらは、特定のタイプのネットワークアドレス翻訳者（NAT）で使用される場合に破損する可能性が高いアプリケーションと同じタイプのアプリケーションであることに注意してください。第二に、アプリケーションはDNSクエリの結果を長時間キャッシュする可能性があり、股関節システムがLSIバインディングでガベージコレクションをいつ実行するかを判断するのは難しい場合があります。ただし、ヒットを使用する場合、IPアドレスを使用する場合よりも、IDの比較のためにヒットを使用するセキュリティはより強い場合があります。
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ソフトウェアは、ヒット、LSIS（該当する場合）、対応するIPアドレス、および完全資格のドメイン名（FQDN）関連情報をログに記録して、管理者が他のログをHIP識別子と相関させることができることをお勧めします。
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またはヒットがルーティング可能または解決可能である可能性があります。その場合、アプリケーションは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で概説されているアプローチよりも弱いセキュリティプロパティがあります。実際、アプリケーションの「Connect（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アドレスを使用すると、股関節モビリティサポートの潜在的な利点が得られない場合があります。システムが長寿命のリグドレスで、股関節再生イベントに接続されたソケットを再生可能にすることができる場合、モビリティが可能になります。ただし、現在のシステムと同様に、アプリケーションが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.
ベース股関節プロトコル仕様[RFC5201]のセクション4.1.6は、HIP日和見モードを使用してHITからIPアドレスのバインディングを学習する実装は、後の通信セッションでそれらのバインディングを強制してはならないと述べています。これは、アプリケーションでIPアドレスが使用される場合、股関節を日和見的にセットアップしようとするシステムが、同じアドレスへの後のセッションが同じホストと通信すると仮定してはならないことを意味します。
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の使用についてユーザーに通知できます。さらに、ユーザーエージェントが股関節関連のイベントを引き起こしたネットワークアプリケーションに名前を付けることができます。このようにして、ユーザーは、レガシーネットワークアプリケーションがそうではないにもかかわらず、股関節を使用していることを認識しています。初期展開からのユーザビリティテストに基づいて、ヒットと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解像度をスプーフィングするための1つの欠点は、いくつかのアプリケーション、または選択されたアプリケーションのインスタンスが実際にIPアドレス（Pingなどの診断アプリケーションなど）を取得することをお勧めすることです。リゾルバーがIPアドレスを返すかLSIを返すかについて、より細かい粒度を提供する1つの方法は、ユーザーが股関節を呼び出したいときに変更されたドメイン名を形成することです。これにより、次のセクションでは、エンドユーザーが股関節を有効にすることを明示的かつ選択的に選択するユースケースを検討するようになります。
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.
前のセクションでは、必ずしもユーザーが関与していないレガシーアプリケーション用の股関節を構成するためのアプローチについて説明しました。ただし、Legacyアプリケーションユーザーが、何らかの方法で股関節対応システムに信号を送信することにより、特定のアプリケーションインスタンスに股関節を使用したい場合があります。アプリケーションユーザーインターフェイスまたは構成ファイルがIPアドレスを受け入れる場合、その代わりにヒットまたはLSIを提供する機会があるかもしれません。さらに、アプリケーションがDNSを使用している場合、ユーザーは特別に作成されたドメイン名を提供して、リゾルバーに信号を送信して、ヒップレコードを取得し、システムに信号を送信することができます。以下のこれらのアプローチの両方について説明します。
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の使用について説明します。より明確な同様のアプローチは、アプリケーションを構成して、ヒットに直接接続するように構成することです（たとえば、「Connect（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.
このアプローチにはいくつかの課題もあります。HITSの使用は、IPv6アドレスまたはドメイン名のいずれかを使用するよりも（フラットヒット名スペースのため）、人間のユーザーにとって面倒です。このアプローチのもう1つの課題は、ヒットに基づいて使用するIPアドレスを実際に見つけることです。この場合、ある種のヒット解決サービスが必要です。このアプローチの3番目の課題は、おそらく非人権を認識しているホストへのコールバックと紹介をサポートすることです。ただし、この場合のほとんどの通信は他の股関節を認識するホストに対するものである可能性が高いため（そうでなければ、最初の股関節関連は確立できません）。何らかの理由。
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アドレス（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）を使用したコマンドラインツールまたはツールをシステムによって提供して、ユーザーがどのアプリケーションを使用しているかをポリシーを設定できるようにすることができます。動的にリンクされたアプリケーションのためのもう1つの一般的な手法は、システムの呼び出しをラップして股関節層の通信を挿入する修正ライブラリにアプリケーションを動的にリンクすることです。これは、たとえば、特別なシェルを通してコマンドを実行することにより、ユーザーが呼び出すことができます。
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アドレスとよく知られているポートにバインドします。Legacy Serverの実装での股関節使用の場合、再びいくつかのオプションがあります。システムは、オプションで（クライアントの動作に応じて）常に手動で構成することも、サーバーがワイルドカード（IP）アドレスを指定した場合、ポリシーの問題として特定のサービスで股関節を使用しないでください。
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呼び出しがローカルアドレスの解決に使用される場合、システムがヒットまたはLSIを内部仮想インターフェイスに割り当てた場合（多くのHIP実装に共通）、ヒットまたは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.
一部のアプリケーションは、ソケットを特定のローカルアドレスにバインドしようとする場合や、CベースのソケットAPIのGetSockName（）やgetPeername（）などのソケットコールに基づいてサーバー側のアクセス制御リストを実装する場合があります。指定されたローカルアドレスがIPアドレスである場合、繰り返しますが、基礎となるシステムは、股関節を使用するように構成されている場合があります。指定されたローカルアドレスがヒット（セクション4）である場合、システムは、ローカルアプリケーションへの接続が指定されたヒットにのみ到着できることを強制する必要があります。システムに多くのHISがある場合、1回のヒットにバインドするアプリケーションは、指定されたヒットに対応する他のヒットとの接続を受け入れることができません。
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.
ホストに複数のHISがあり、ソケットの動作が特定のHIのローカル識別子としての使用を規定していない場合、それはローカル識別子として機能するHIを選択する方法に関するローカルポリシーの問題です。ただし、ワイルドカードに結合するシステムは、複数のヒットまたはLSIが定義されている場合に問題に直面する可能性があります。これらの問題は股関節自体に固有のものではありませんが、マルチホーム用に設計されていないアプリケーションを備えた非ヒップマルチホームシナリオでも発生します。
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（）が実際にクライアントが想定するのとは異なるサーバーヒットを使用する可能性があることです。クライアントは、クライアントがUDPソケットのアクセス制御を実装するときに応答パケットをドロップします（Connect（）を使用するなど）。
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.
Multihoming（特に補助データを考慮する）をサポートするためにsendmsg（）およびrecvmsg（）を使用してサーバーアプリケーションを再実装することは、この問題の究極のソリューションですが、レガシーアプリケーションではオプションではありません。回避策として、UDPベースのサービスを提供していないサービスを提供するサーバーに提案を行います。このようなサーバーは、そのような問題を回避するために、ホストのデフォルトの発信ヒットに一致するヒットまたは公開キーのみを発表する必要があります。
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.
最後に、一部のアプリケーションはローカルヒットへの接続を作成する場合があります。そのような場合、ローカルシステムはヌル暗号化を使用して不必要な暗号化のオーバーヘッドを避けることができ、それ以外の場合は、認証、diffie-hellman Exchange、およびパズルを除外するなど、通常よりも寛容である可能性があります。
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.
このセクションでは、システムのセキュリティについて一般的な用語で説明し、セキュリティプロパティの一部を概説します。ただし、このセクションは、完全なリスク分析を提供することを意図したものではありません。このような分析は、いずれにせよ、股関節を使用して実際のアプリケーションに依存するため、範囲外であると見なされます。
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ゾーンが十分に信頼できると見なされるかどうかに関連するさらなる違いがあります。ここでは、それぞれのツリーで利用可能な信頼のアンカーに委任チェーンが存在することを意味し、NetBlockを担当する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ポリシーを備えた非ヒップシステムに匹敵します。最初の日和見キー交換のセキュリティセマンティクスは、非セーシングIPとほぼ等しくなります。交換は、中間の攻撃に対して脆弱です。ただし、システムは、接続ハイジャック攻撃に対して脆弱ではありません。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.
フォワードDNSを使用してドメイン名をLSIにマッピングすることは、今日の最も典型的な使用シナリオに最も近いケースです。DNSSECを使用すると、結果は、輸送層セキュリティ（TLS）を備えた証明書の現在の使用とかなり似ています。DNSSECが使用されない場合、結果はプレーン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.
アプリケーションがヒットに基づいて操作を行っている場合、股関節の暗黙のチャネルバインディングのために接続が自動的に保護されます。つまり、アプリケーションが接続（ヒット）システムコールを作成すると、結果のパケットが対応する秘密鍵を所有するノードに送信されるか、セキュリティ協会が確立されません。
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.
システムが名前の解像度の結果としてIPアドレスの代わりにLSIまたはヒットを（スプーフ）提供する場合、結果のフィールドはユーザーインターフェイスとシステムログに不注意に表示される場合があり、一部のネットワーク管理者に運用上の懸念を引き起こす可能性があります。したがって、HIPソフトウェアは、HITS、LSIS（該当する場合）、対応するIPアドレス、およびFQDN関連情報をログに記録して、管理者が他のログをHIP識別子と相関させることができることをお勧めします。
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.
ジェフ・アフレンホルツ、ゴンザロ・カマリロ、アルベルト・ガルシア、テム・コポネン、ジュリアン・ラガニエ、ユリタロは、この文書のさまざまなバージョンに関するコメントを提供しています。この文書は、デビッド・ブラック、ラース・エガート、ピーター・コッホ、トーマス・ナルテン、ペッカ・サヴォラからのレビュー段階で、かなりの有用なコメントを受け取りました。
[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月。
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
[RFC4843] Nikander、P.、Laganier、J。、およびF. Dupont、「オーバーレイのルーティング可能な暗号ハッシュ識別子（蘭）のIPv6プレフィックス」、RFC 4843、2007年4月。
[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.、Balakrishnan、H。、およびA. Snoeren、「Tesla：エンドツーエンドネットワークサービスの透明で拡張可能なセッションレイヤーアーキテクチャ」、インターネットテクノロジーとシステムに関するUSENIXシンポジウムの議事録（USITS）、211-224、2003年3月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958] Carpenter、B.、ed。、「インターネットの建築原理」、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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J。、およびW. Stevens、「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
トーマス・ヘンダーソンボーイングカンパニーP.O.ボックス3707シアトル、ワシントンアメリカ
EMail: thomas.r.henderson@boeing.com
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
Miika Komu Helsinki Institute for Information Technology Metsaenneidonkuja 4 Helsinki FIN-02420 FINLAND
Miika Komu Helsinki Institute for Information Technology Metsaenneidonkuja 4 Helsinki Fin-02420フィンランド
Phone: +358503841531
EMail: miika@iki.fi
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への情報をお問い合わせください。