Network Working Group L-E. Jonsson
Request for Comments: 4163 Ericsson
Category: Informational August 2005
RObust Header Compression (ROHC):
Requirements on TCP/IP Header Compression
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the RObust Header Compression (ROHC) Working Group. The document discusses the scope of TCP compression, performance considerations, assumptions about the surrounding environment, as well as Intellectual Property Rights concerns. The structure of this document is inherited from RFC 3096, which defines IP/UDP/RTP requirements for ROHC.
この文書では、ロバストヘッダ圧縮（ROHC）ワーキンググループによって開発されるTCP / IPヘッダ圧縮方式（プロファイル）の要件が含まれています。文書には、TCP圧縮、パフォーマンスを考慮し、周囲の環境についての前提条件だけでなく、知的財産権の問題の範囲について説明します。このドキュメントの構造は、ROHCのためのIP / UDP / RTPの要件を定義するRFC 3096、から継承されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Header Compression Requirements .................................2
2.1. Impact on Internet Infrastructure ..........................2
2.2. Supported Headers and Kinds of TCP Streams .................3
2.3. Performance Issues .........................................4
2.4. Requirements Related to Link Layer Characteristics .........6
2.5. Intellectual Property Rights (IPR) .........................7
3. Security Consideration ..........................................7
4. IANA Considerations .............................................7
5. Acknowledgements ................................................7
6. Informative References ..........................................7
The goal of the ROHC WG is to develop header compression schemes that perform well over links with high error rates and long link roundtrip times. The schemes must perform well for cellular links that use technologies such as Wideband Code Division Multiple Access (W-CDMA), Enhanced Data rates for GSM Evolution (EDGE), and CDMA2000. However, the schemes should also be applicable to other link technologies with high loss and long roundtrip times.
ROHC WGの目標は、高いエラー率と長いリンク往復の回とのリンクの上にも行うヘッダ圧縮スキームを開発することです。スキームは、このような広帯域符号分割多元接続（W-CDMA）などの技術を使用して携帯リンク、GSMエボリューション（EDGE）、およびCDMA2000のための拡張データレートについても実行する必要があります。しかし、方式も高い損失と長い往復の時間と他のリンク技術に適用可能であるべきです。
The main objective for ROHC has been robust compression of IP/UDP/RTP [5], but the WG is also chartered to develop new header compression solutions for IP/TCP [1], [2]. Because TCP traffic, in contrast to RTP, has usually been sent over reliable links, existing schemes for TCP, [3] and [4], have not experienced the same robustness problems as RTP compression. However, there are still many scenarios where TCP header compression will be implemented over less reliable links [11], [12], making robustness an important objective for the new TCP compression scheme. Other, equally important, objectives for ROHC TCP compression are: improved compression efficiency, enhanced capabilities for compression of header fields including TCP options, and finally incorporation of TCP compression into the ROHC framework [6].
ROHCのための主な目的は、[2]、[1]〜[5]のIP / UDP / RTPのロバスト圧縮されているが、WGはまた、IP / TCPのための新たなヘッダ圧縮ソリューションを開発するためにチャーターされています。 TCPトラフィックは、RTPとは対照的に、通常はTCPのためのスキームを既存の、信頼性の高いリンクを介して送信されているので、[3]と[4]、RTP圧縮と同じ堅牢性の問題を経験していません。しかし、TCPヘッダー圧縮は、堅牢性に新しいTCP圧縮方式のための重要な目的を作り、[12]、信頼性の低いリンク[11]以上実施される多くのシナリオが残っています。 ROHC TCP圧縮のための他の、同様に重要な、目的は、改良された圧縮効率、TCPオプションを含むヘッダフィールドの圧縮のための拡張機能、および最終的にROHCフレームワークにTCP圧縮の取り込み[6]。
The following requirements have, more or less arbitrarily, been divided into five groups. The first group deals with requirements concerning the impact of a header compression scheme on the rest of the Internet infrastructure. The second group defines what kind of headers must be compressed efficiently. The third and fourth groups concern performance requirements and capability requirements that stem from the properties of link technologies where ROHC TCP is expected to be used. Finally, the fifth section discusses Intellectual Property Rights related to ROHC TCP compression.
次の要件は、多かれ少なかれ任意に、5つのグループに分けられています。最初のグループは、インターネットインフラストラクチャの残りの部分にヘッダ圧縮スキームの影響に関する要件を扱います。第2のグループは、効率的に圧縮されなければならないヘッダの種類を定義します。第三及び第四グループはROHC TCPを使用することが期待されているリンク技術の性質から生じる性能要件及び機能要件に関係します。最後に、第五章ではROHC TCP圧縮に関連する知的財産権について説明します。
1. Transparency: When a header is compressed and then decompressed, the resulting header must be semantically identical to the original header. If this cannot be achieved, the packet containing the erroneous header must be discarded.
1.透明性：ヘッダを圧縮し、その後解凍された場合、結果として得られるヘッダはオリジナルヘッダと意味的に同じでなければなりません。これが達成できない場合、誤ったヘッダを含むパケットを廃棄しなければなりません。
Justification: The header compression process must not produce
headers that might cause problems for any current or future part
of the Internet infrastructure.
Note: The ROHC WG has not found a case where "semantically identical" is not the same as "bitwise identical".
注：ROHC WGは「意味的に同一」「同一ビット単位」と同じでない場合を発見していません。
2. Ubiquity: Must not require modifications to existing IP (v4 or v6) or TCP implementations.
2.ユビキタス：既存のIP（V4またはV6）またはTCP実装への変更を要求してはなりません。
Justification: Ease of deployment.
正当化：展開のしやすさ。
Note: The ROHC WG may recommend changes that would increase the compression efficiency for the TCP streams emitted by implementations. However, ROHC cannot assume such recommendations will be followed.
注：ROHC WGは、実装によって放出されたTCPストリームの圧縮効率を増加させる変更を勧告することができます。しかし、ROHCは、このような勧告が続くことになると想定することはできません。
Note: Several TCP variants are currently in use on the Internet. This requirement implies that the header compression scheme must work efficiently and correctly for all expected TCP variants.
注意：いくつかのTCP変異体は、インターネット上で現在使用されています。この要件はヘッダー圧縮方式が期待されるすべてのTCPバリアントのための効率的かつ正常に動作しなければならないことを意味します。
1. IPv4 and IPv6: Must support both IPv4 and IPv6. This means that all expected changes in the IP header fields must be handled by the compression scheme, and commonly changing fields should be compressed efficiently. Compression must still be possible when IPv6 Extensions are present in the header. When designing the compression scheme, the usage of Explicit Congestion Notification (ECN) [10] should be considered as a common behavior. Therefore, the scheme must also compress efficiently in the case when the ECN bits are used.
1. IPv4とIPv6は：IPv4とIPv6の両方をサポートしている必要があります。これは、IPヘッダフィールド内のすべての予想される変化は、圧縮方式で処理する必要があり、そして一般的に変化するフィールドは効率的に圧縮されなければならないことを意味します。 IPv6拡張機能は、ヘッダ内に存在する場合、圧縮はまだ可能でなければなりません。圧縮スキームを設計する際に、明示的輻輳通知（ECN）の使用[10]一般的な動作として考慮されるべきです。したがって、この方式はまた、ECNビットが使用される場合に、効率的に圧縮しなければなりません。
Justification: IPv4 and IPv6 will both be around for the
foreseeable future, and Options/Extensions are expected to be
more commonly used. ECN is expected to have a breakthrough and
be widely deployed, especially in combination with TCP.
2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be supported and should be compressed efficiently. For IPv4 these include headers of tunneled packets. For IPv6 they include headers containing the Routing Header and the Home Address Option.
2.モバイルIP：モバイルIPによって使用されるヘッダーの種類{V4が、V6}サポートされなければならず、効率的に圧縮されなければなりません。 IPv4の場合、これらは、トンネルパケットのヘッダが含まれています。 IPv6の場合、彼らは、ルーティングヘッダーとホームアドレスオプションを含むヘッダが含まれます。
Justification: It is very likely that Mobile IP will be used by
cellular devices.
3. Generality: Must handle all headers from arbitrary TCP streams.
3.汎用性：任意のTCPストリームからのすべてのヘッダを処理する必要があります。
Justification: There must be a generic scheme that can compress
reasonably well for any TCP traffic pattern. This does not
preclude optimizations for certain traffic patterns.
4. IPSEC: The scheme should be able to compress headers containing IPSEC subheaders where the NULL encryption algorithm is used.
4. IPSEC：スキームは、NULL暗号化アルゴリズムが使用されるIPSECサブヘッダを含むヘッダを圧縮することができなければなりません。
Justification: IPSEC is expected to be used to provide necessary
end-to-end security.
Note: It is not possible to compress the encrypted part of an ESP header, nor the cryptographic data in an AH header.
注意：ESPヘッダの暗号化された部分、またAHヘッダ内の暗号化データを圧縮することはできません。
5. TCP: All fields supported by [4] should be handled with efficient compression, as should be the cases when the SYN, FIN or TCP ECN [10] bits are set.
5. TCP：SYN、FINまたはTCP ECNは、[10]ビットが設定されている場合のケースであるべきである[4]でサポートされるすべてのフィールドは、効率的な圧縮で処理されなければなりません。
Justification: These bits are expected to be commonly used.
正当化：これらのビットは、一般的に使用されることが期待されます。
6. TCP options: The scheme must support compression of packets with any TCP option present, even if the option itself is not compressed. Further, for some commonly used options the scheme should also provide compression mechanisms for the options.
6. TCPオプション：スキームはオプション自体が圧縮されていない場合でも、存在する任意のTCPオプションでパケットの圧縮をサポートしている必要があります。さらに、いくつかの一般的に使用されるオプションのための方式は、オプションのための圧縮機構を提供する必要があります。
Justification: Because various TCP options are commonly used,
applicability of the compression scheme would be significantly
reduced if packets with options could not be compressed.
Note: Options that should be compressed are: - Selective Acknowledgement (SACK), [8], [9] - Timestamp, [7]
注：圧縮されるべきオプションがある： - 選択的確認応答（SACK）、[8]、[9] - タイムスタンプ、[7]
1. Performance/Spectral Efficiency: The scheme must provide low relative overhead under expected operating conditions; compression efficiency should be better than for RFC 2507 [4] under equivalent operating conditions.
1.パフォーマンス/スペクトル効率：スキームが予想される動作条件の下で、低い相対的オーバーヘッドを提供しなければなりません。圧縮効率は同等の操作条件下で[4] RFC 2507よりも良好でなければなりません。
Justification: Spectrum efficiency is a primary goal.
正当化：スペクトル効率が第一の目標です。
Note: The relative overhead is the average header overhead relative to the payload. Any auxiliary (e.g., control or feedback) channels used by the scheme should be taken into account when calculating the header overhead.
注：相対オーバーヘッドはペイロードに対する平均ヘッダーオーバーヘッドです。ヘッダーオーバーヘッドを計算するときに任意の補助（例えば、制御またはフィードバック）方式で使用されるチャネルは考慮されるべきです。
2. Losses between compressor and decompressor: The scheme should make sure losses between compressor and decompressor do not result in losses of subsequent packets, or cause damage to the context that results in incorrect decompression of subsequent packet headers.
コンプレッサーと減圧器との間に2損失：スキームは、コンプレッサとの間に必ず損をするべきであるとデ後続のパケットの損失をもたらす、あるいはそれに続くパケットヘッダの不正確な解凍、その結果コンテキストに損傷が発生することはありません。
Justification: Even though link layer retransmission in most
cases is expected to almost eliminate losses between compressor
and decompressor, there are still many scenarios where TCP header
compression will be implemented over less reliable links [11],
[12]. In such cases, loss propagation due to header compression
could affect certain TCP mechanisms that are capable of handling
some losses; loss propagation could also have a negative impact
on the performance of TCP loss recovery.
3. Residual errors in compressed headers: Residual errors in compressed headers may result in delivery of incorrectly decompressed headers not only for the damaged packet itself, but also for subsequent packets, because errors may be saved in the context state. For TCP, the compression scheme is not required to implement explicit mechanisms for residual error detection, but the compression scheme must not affect TCP's end-to-end mechanisms for error detection.
圧縮されたヘッダーの前記残留誤差：エラーがコンテキスト状態で保存することができるので、圧縮ヘッダ内の残留誤差は、破損パケット自体のためだけでなく、後続のパケットのためだけではなく、誤って解凍ヘッダの送達をもたらすことができます。 TCPの場合は、圧縮方式は、残留エラー検出のための明示的なメカニズムを実装するために必要とされていませんが、圧縮方式は、エラー検出のためのTCPのエンドツーエンドのメカニズムに影響を与えてはなりません。
Justification: For links carrying TCP traffic, the residual error
rate is expected to be insignificant. However, residual errors
may still occur, especially in the end-to-end path. Therefore,
it is crucial that TCP is not prevented from handling these.
Note: This requirement implies that the TCP checksum must be carried unmodified in all compressed headers.
注：この要件は、TCPチェックサムがすべての圧縮ヘッダにそのまま運ばなければならないことを意味します。
Note: The error detection mechanism in TCP may be able to detect residual bit errors, but the mechanism is not designed for this purpose, and might actually provide rather weak protection. Therefore, although it is not a requirement of the compression scheme, it should be possible for the decompressor to detect residual errors and discard such packets.
注：TCPのエラー検出メカニズムは、残留ビットエラーを検出することができるが、メカニズムは、この目的のために設計されていない、と実際にかなり弱い保護を提供するかもしれません。それは圧縮方式の要件ではないものの、解凍器は、残留誤差を検出し、そのようなパケットを廃棄するため、したがって、それは可能であるべきです。
4. Short-lived TCP transfers: The scheme should provide mechanisms for efficient compression of short-lived TCP transfers, minimizing the size of context initiation headers.
4.短命TCP転送：スキームコンテキスト開始ヘッダのサイズを最小化する、短命のTCP転送を効率的に圧縮するためのメカニズムを提供しなければなりません。
Justification: Many TCP transfers are short-lived. This may lead
to a low gain for header compression schemes that, for each new
packet stream, requires full headers to be sent initially and
allows small compressed headers only after the initialization
phase.
Note: This requirement implies that mechanisms for building new contexts that are based on information from previous contexts or for concurrent packet streams to share context information should be considered.
注：この要件は、コンテキスト情報を共有するために、同時パケットストリーム以前の文脈から、またはのための情報に基づいて新しいコンテキストを構築するための仕組みを検討すべきであることを意味します。
5a. Moderate Packet Misordering: The scheme should efficiently handle moderate misordering (2-3 packets) in the packet stream reaching the compressor.
図5a。適度パケット誤った順序：スキームを効率的に圧縮機に到達するパケットストリームの中程度の誤った順序（2-3パケット）を処理します。
Justification: This kind of misordering is common.
正当化：誤った順序のこの種のは一般的です。
5b. Packet Misordering: The scheme must be able to correctly handle packet misordering and preferably compress when misordered packets are in the TCP stream reaching the compressor.
図5b。パケット誤った順序：スキームが正しくパケット誤った順序を処理し、misorderedパケットがコンプレッサーに達しTCPストリーム内にあるとき、好ましくは、圧縮することができなければなりません。
Justification: Misordering happens regularly in the Internet.
However, because the Internet is engineered to run TCP reasonably
well, excessive misordering will not be common and need not be
handled with optimum efficiency.
6. Processing delay: The scheme should not contribute significantly to the system delay budget.
6.処理遅延：スキームは、システムの遅延バジェットに大きく貢献するべきではありません。
1. Unidirectional links: Must be possible to implement (possibly with less efficiency) without explicit feedback messages from decompressor to compressor.
1.単方向リンクは：解凍器から圧縮機への明示的なフィードバックメッセージなしで（おそらくより少ない効率で）実装することが可能でなければなりません。
Justification: There are links that do not provide a feedback
channel or where feedback is not desirable for other reasons.
2. Link delay: Must operate under all expected link delay conditions.
2.リンクの遅延：すべての予想リンク遅延条件の下で動作しなければなりません。
3. Header compression coexistence: The scheme must fit into the ROHC framework together with other ROHC profiles (e.g., [6]).
3.ヘッダ圧縮共存：他のROHCプロファイルと共にROHCフレームワークに適合しなければならない方式（例えば、[6]）。
4. Note on misordering between compressor and decompressor:
コンプレッサとデコンプレッサとの間の誤った順序で前記注
When compression is applied over tunnels, misordering often
cannot be completely avoided. The header compression scheme
should not prohibit misordering between compressor and
decompressor, as it would therefore not be applicable in many
tunneling scenarios. However, in the case of tunneling, it is
usually possible to get misordering indications. Therefore, the
compression scheme does not have to support detection of
misordering, but can assume that such information is available
from lower layers when misordering occurs.
The ROHC WG must spend effort to achieve a high degree of confidence that there are no known IPR claims that cover the final compression solution for TCP.
TCPのための最終的な圧縮ソリューションをカバーする既知のIPRクレームがないことROHC WGは、高い信頼度を達成するための努力を費やす必要があります。
Justification: Currently there is no TCP header compression scheme available that can efficiently compress the packet headers of modern TCP, e.g., with SACK, ECN, etc. ROHC is expected to fill this gap by providing a ROHC TCP scheme that is applicable in the wide area Internet, not only over error-prone radio links. It must thus attempt to be as future-proof as possible, and only unencumbered solutions, or solutions where the terms of any IPR are such that there is no hindrance on implementation and deployment, will be acceptable to the Internet at large.
正当化：現在、効率的にROHCが広いにおいても適用可能であるROHC TCPスキームを提供することによって、このギャップを埋めるために期待されているなどSACK、ECN、で、例えば、近代的なTCPのパケットヘッダを圧縮することができます利用可能なTCPヘッダー圧縮方式はありません地域インターネットだけでなく、エラーが発生しやすい無線リンクの上に。したがって、可能な限り将来性のように試みなければならない、とだけ邪魔されないソリューション、または任意のIPRの用語が実装と展開に支障がないようなソリューションは、大規模でインターネットに受け入れられるだろう。
A protocol specified to meet these requirements must be able to compress packets containing IPSEC headers according to the IPSEC requirement, 2.2.4. There may be other security aspects to consider in such protocols. This document by itself, however, does not add any security risks.
これらの要件を満たすために指定されたプロトコルは、IPSEC要件、2.2.4に従ってIPSECヘッダを含むパケットを圧縮することができなければなりません。そのようなプロトコルでは、考慮すべき他のセキュリティ面があるかもしれません。この文書では、それ自体で、しかし、セキュリティ上のリスクを追加しません。
A protocol that meets these requirements will require the IANA to assign various numbers. This document by itself, however, does not require any IANA involvement.
これらの要件を満たしているプロトコルは、さまざまな番号を割り当てるためにIANAが必要になります。それ自体でこのドキュメントでは、しかし、任意のIANAの関与を必要としません。
This document has evolved through fruitful discussions with and input from Gorry Fairhurst, Carsten Bormann, Mikael Degermark, Mark West, Jan Kullander, Qian Zhang, Richard Price, and Aaron Falk. The document quality was significantly improved thanks to Peter Eriksson, who made a thorough linguistic review.
この文書はGorry Fairhurst、カルステンボルマン、ミカエルDegermark、マーク・西、ヤンKullander、銭張、リチャード価格、およびアーロンフォークからの実りとの協議・入力を経て発展してきました。文書の品質が大幅に徹底的な言語的見直しをしたピーター・エリクソン、のおかげで改善しました。
Last, but not least, Ghyslain Pelletier and Kristofer Sandlund served as committed working group document reviewers.
最後に、ではなく、少なくとも、GhyslainペルティエとクリストファーSandlundは、コミットワーキンググループ文書の校閲を務めていました。
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[1]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[2]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[3] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[3]ジェーコブソン、V.を、RFC 1144、1990年2月 "低速シリアルリンク用のTCP / IPヘッダの圧縮"。
[4] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[4] Degermark、M.、Nordgren、B.、およびS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[5] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
[5] Degermark、M.、 "ロバストIP / UDP / RTPヘッダ圧縮のための要件"、RFC 3096、2001年7月。
[6] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[6]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、 ESP、および非圧縮」、RFC 3095、2001年7月。
[7] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[7]ジェーコブソン、V.、ブレーデン、R.、およびD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992月。
[8] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[8]マティス、M.、Mahdavi、J.、フロイド、S.、とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[9] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[9]フロイド、S.、Mahdavi、J.、マティス、M.、およびM.ポドルスキー、 "TCPのための選択的確認応答（SACK）オプションの拡張"、RFC 2883、2000年7月。
[10] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[10] "IPに明示的輻輳通知の添加（ECN）" ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[11] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
[11]ドーキンス、S.、モンテネグロ、G.、古城、M.、およびV. Magret、 "低速リンクのエンドツーエンドのパフォーマンスへの影響"、BCP 48、RFC 3150、2001年7月。
[12] Fairhurst, G. and L. Wood, "Advice to link designers on link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.
[12] Fairhurst、G.とL.ウッド、BCP 62、RFC 3366、2002年8月 "リンク自動再送要求（ARQ）にデザイナーをリンクするためのアドバイス"。
Author's Address
著者のアドレス
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea Sweden
ラース・エリックジョンソン、エリクソンABボックス920 SE-971 28ルーレオスウェーデン
Phone: +46 8 404 29 61 Fax: +46 920 996 21 EMail: lars-erik.jonsson@ericsson.com
電話：+46 8 404 29 61ファックス：+46 920 996 21 Eメール：lars-erik.jonsson@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。