Network Working Group
Request for Comments: 2509 M. Engan
Category: Standards Track Effnet
S. Casner
Cisco Systems
C. Bormann
Universitaet Bremen TZI
February 1999
IP Header Compression over PPP
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol [RFC1661]. It defines extensions to the PPP Control Protocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in [IPHC] and [CRTP].
この文書では、ポイントツーポイントプロトコル[RFC1661]を介して送信されたIPデータグラムにヘッダ圧縮の使用を交渉するためのオプションが記載されています。これは、IPv4とIPv6 [RFC1332、RFC2023]のためのPPP制御プロトコルへの拡張を定義します。 [IPHC]および[CRTP]指定されたヘッダ圧縮は、TCP、UDP及びRTPトランスポートプロトコルとの組み合わせで、IPv4とIPv6データグラムに適用されてもよいです。
The IP Header Compression (IPHC) defined in [IPHC] may be used for compression of both IPv4 and IPv6 datagrams or packets encapsulated with multiple IP headers. IPHC is also capable of compressing both TCP and UDP transport protocol headers. The IP/UDP/RTP header compression defined in [CRTP] fits within the framework defined by IPHC so that it may also be applied to both IPv4 and IPv6 packets.
[IPHC]で定義されたIPヘッダー圧縮（IPHC）は、複数のIPヘッダでカプセル化IPv4とIPv6の両方のデータグラムまたはパケットの圧縮のために使用することができます。 IPHCはまた、TCPとUDPトランスポートプロトコルヘッダの両方を圧縮することができます。 [CRTP]で定義されたIP / UDP / RTPヘッダ圧縮は、それはまた、IPv4とIPv6パケットの両方に適用することができるようにIPHCによって規定されたフレームワーク内に収まります。
In order to establish compression of IP datagrams sent over a PPP link each end of the link must agree on a set of configuration parameters for the compression. The process of negotiating link parameters for network layer protocols is handled in PPP by a family of network control protocols (NCPs). Since there are separate NCPs for IPv4 and IPv6, this document defines configuration options to be used in both NCPs to negotiate parameters for the compression scheme.
PPPリンク上でリンクの両端を送ったIPデータグラムの圧縮を確立するために圧縮するための構成パラメータのセットに同意しなければなりません。ネットワーク層プロトコルのためのリンクパラメータをネゴシエートするプロセスは、ネットワーク制御プロトコル（NCP）のファミリーによってPPPで処理されます。別のNCPは、IPv4とIPv6のためにそこにあるので、この文書は、圧縮スキームのパラメータを交渉するために、両方のNCPで使用される構成オプションを定義します。
IPHC relies on the link layer's ability to indicate the types of datagrams carried in the link layer frames. In this document nine new types for the PPP Data Link Layer Protocol Field are defined along with their meaning.
IPHCは、リンク層フレームで運ばれたデータグラムの種類を示すために、リンク層の能力に依存しています。この文書ではPPPデータリンク層プロトコルフィールドのための9つの新しいタイプは、その意味と一緒に定義されています。
In general, header compression schemes that use delta encoding of compressed packets require that the lower layer does not reorder packets between compressor and decompressor. IPHC uses delta encoding of compressed packets for TCP and RTP. The IPHC specification [IPHC] includes methods that allow link layers that may reorder packets to be used with IPHC. Since PPP does not reorder packets these mechanisms are disabled by default. When using reordering mechanisms such as multiclass multilink PPP [MCML], care must be taken so that packets that share the same compression context are not reordered.
一般的に、圧縮されたパケットのデルタ符号化を使用するヘッダ圧縮方式は、下層は、コンプレッサとデコンプレッサとの間のパケットの順序を変更しないことを必要とします。 IPHCはTCPおよびRTPのための圧縮パケットのデルタエンコーディングを使用しています。 IPHC仕様[IPHC]はパケットの順序を変更することができるリンク層はIPHCで使用することを可能にする方法を含みます。 PPPは、パケットの順序を変更していないため、これらのメカニズムは、デフォルトでは無効になっています。そのようなマルチクラスマルチリンクPPP [MCML]として再順序付けメカニズムを使用する場合、同じ圧縮コンテキストを共有するパケットが並べ替えられないように、注意を払わなければなりません。
This document specifies a new compression protocol value for the IPCP IP-Compression-Protocol option as specified in [RFC1332]. The new value and the associated option format are described in section 2.1.
[RFC1332]で指定されたこの文書は、IPCP IP圧縮プロトコルオプションの新しい圧縮プロトコル値を指定します。新しい値と関連したオプションのフォーマットは、セクション2.1に記載されています。
The option format is structured to allow future extensions to the IPHC scheme.
オプションの形式はIPHC制度への将来の拡張を許可するように構成されています。
NOTE: The specification of link and network layer parameter negotiation for PPP [RFC1661], [RFC1331], [RFC1332] does not prohibit multiple instances of one configuration option but states that the specification of a configuration option must explicitly allow multiple instances. From the current specification of the IPCP IP-Compression-Protocol configuration option [RFC1332, p 6] it follows that it can only be used to select a single compression protocol at any time.
注：PPP [RFC1661]、[RFC1331]、[RFC1332]のリンクとネットワーク層パラメータネゴシエーションの仕様は、1つの設定オプションの複数のインスタンスを禁止しますが、構成オプションの指定が明示的に複数のインスタンスを許可しなければならないことを述べていません。 IPCP IP圧縮プロトコル設定オプション[RFC1332、P 6]の現在の仕様から唯一の任意の時点で単一の圧縮プロトコルを選択するために使用することができることになります。
NOTE: [RFC1332] is not explicit about whether the option negotiates the capabilities of the receiver or of the sender. In keeping with current practice, we assume that the option describes the capabilities of the decompressor (receiving side) of the peer that sends the Config-Req.
注：[RFC1332]はオプションが受信機または送信者の能力を交渉するかどうかについて明示的ではありません。現在の慣行に沿って、我々は、オプションはコンフィグ-REQを送信したピアの減圧器（受信側）の機能を説明することを前提としています。
Both the network control protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2023] may be used to negotiate IP Header Compression parameters for their respective protocols. The format of the configuration option is the same for both IPCP and IPV6CP.
IPv4の、IPCP [RFC1332]とIPv6 NCP、IPV6CP [RFC2023]のためのネットワーク制御プロトコルの両方は、それぞれのプロトコルのIPヘッダ圧縮パラメータを交渉するために使用することができます。設定オプションのフォーマットは、IPCPとIPV6CPの両方で同じです。
Description
説明
This NCP configuration option is used to negotiate parameters for IP Header Compression. The option format is summarized below. The fields are transmitted from left to right.
このNCPの設定オプションは、IPヘッダ圧縮のためのパラメータを交渉するために使用されます。オプションの形式は以下のように要約されます。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IP-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP_SPACE | NON_TCP_SPACE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F_MAX_PERIOD | F_MAX_TIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_HEADER | suboptions...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2
タイプ2
Length >= 14
長さ> = 14
The length may be increased if the presence of additional parameters is indicated by additional suboptions.
追加のパラメータの存在は、追加のサブオプションによって示されている場合は、長さを増加させることができます。
IP-Compression-Protocol 0061 (hex)
IP-圧縮・プロトコル0061（16進）
TCP_SPACE The TCP_SPACE field is two octets and indicates the maximum value of a context identifier in the space of context identifiers allocated for TCP.
TCP_SPACEはTCP_SPACEフィールドは、2つのオクテットであり、TCPのために割り当てられたコンテクスト識別子の空間のコンテキスト識別子の最大値を示しています。
Suggested value: 15
推奨値：15
TCP_SPACE must be at least 0 and at most 255 (The value 0 implies having one context).
TCP_SPACEは（値0があるコンテキストを有することを意味する）、少なくとも0かつ多くとも255でなければなりません。
NON_TCP_SPACE The NON_TCP_SPACE field is two octets and indicates the maximum value of a context identifier in the space of context identifiers allocated for non-TCP. These context identifiers are carried in COMPRESSED_NON_TCP, COMPRESSED_UDP and COMPRESSED_RTP packet headers.
NON_TCP_SPACEはNON_TCP_SPACEフィールドは、2つのオクテットであり、非TCPのために割り当てられたコンテクスト識別子の空間のコンテキスト識別子の最大値を示しています。これらのコンテキスト識別子はCOMPRESSED_NON_TCP、COMPRESSED_UDPとCOMPRESSED_RTPパケットヘッダで運ばれます。
Suggested value: 15
推奨値：15
NON_TCP_SPACE must be at least 0 and at most 65535 (The value 0 implies having one context).
NON_TCP_SPACEは（値0があるコンテキストを有することを意味する）、少なくとも0かつ多くとも65535でなければなりません。
F_MAX_PERIOD Maximum interval between full headers. No more than F_MAX_PERIOD COMPRESSED_NON_TCP headers may be sent between FULL_HEADER headers.
フルヘッダ間F_MAX_PERIOD最大間隔。 F_MAX_PERIOD COMPRESSED_NON_TCPヘッダよりもないんFULL_HEADERヘッダとの間で送信することができます。
Suggested value: 256
推奨値：256
A value of zero implies infinity, i.e. there is no limit to the number of consecutive COMPRESSED_NON_TCP headers.
ゼロの値は、連続COMPRESSED_NON_TCPヘッダの数に制限がない、すなわち無限ことを意味します。
F_MAX_TIME Maximum time interval between full headers. COMPRESSED_NON_TCP headers may not be sent more than F_MAX_TIME seconds after sending the last FULL_HEADER header.
フルヘッダ間F_MAX_TIME最大時間間隔。 COMPRESSED_NON_TCPヘッダは最後FULL_HEADERヘッダーを送信した後以上F_MAX_TIME秒を送信しなくてもよいです。
Suggested value: 5 seconds
推奨値：5秒
A value of zero implies infinity.
ゼロの値は無限大を意味しています。
MAX_HEADER The largest header size in octets that may be compressed.
圧縮されてもよいオクテットで最大ヘッダサイズをMAX_HEADER。
Suggested value: 168 octets
推奨値：168個のオクテット
The value of MAX_HEADER should be large enough so that at least the outer network layer header can be compressed. To increase compression efficiency MAX_HEADER should be set to a value large enough to cover common combinations of network and transport layer headers.
少なくとも外側のネットワーク層ヘッダを圧縮することができるようにMAX_HEADERの値は十分に大きくなければなりません。圧縮効率MAX_HEADERを増加させるためには、ネットワークおよびトランスポート層ヘッダの一般的な組み合わせをカバーするのに十分に大きな値に設定されるべきです。
suboptions The suboptions field consists of zero or more suboptions. Each suboption consists of a type field, a length field and zero or more parameter octets, as defined by the suboption type. The value of the length field indicates the length of the suboption in its entirety, including the lengths of the type and length fields.
サブオプションのサブオプションフィールドは、ゼロ個以上のサブオプションで構成されています。サブオプションのタイプによって定義されるように各サブオプションは、タイプフィールド、長さフィールドおよびゼロ以上のパラメータのオクテットで構成されています。長さフィールドの値は、タイプと長さフィールドの長さを含め、その全体がサブオプションの長さを示します。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Parameters...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RTP-Compression suboption is included in the NCP IP-Compression-Protocol option for IPHC if IP/UDP/RTP compression is to be enabled.
IP / UDP / RTP圧縮を有効にする場合はRTP圧縮サブオプションは、IPHCのためのNCP IP圧縮プロトコルオプションに含まれています。
After successful negotiation of parameters for IP Header Compression the use of Protocol Identifiers FULL_HEADER, COMPRESSED_TCP, COMPRESSED_TCP_NODELTA and COMPRESSED_NON_TCP is enabled, regardless of the prescence of an RTP-Compression suboption.
IPヘッダ圧縮のためのパラメータのネゴシエーション成功した後プロトコル識別子FULL_HEADER、COMPRESSED_TCP、COMPRESSED_TCP_NODELTAとCOMPRESSED_NON_TCPの使用にかかわらず、RTP圧縮サブオプションのprescenceの、有効になっています。
Description
説明
Enable use of Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP and CONTEXT_STATE as specified in [CRTP].
[CRTP]で指定されたプロトコル識別子COMPRESSED_RTP、COMPRESSED_UDPとCONTEXT_STATEの使用を有効にします。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1
タイプ1
Length 2
長さ2
The IPHC protocol is able to compress both IPv6 and IPv4 datagrams. Both IPCP and IPV6CP are able to negotiate option parameter values for IPHC. These values apply to the compression of packets where the outer header is an IPv4 header and an IPv6 header, respectively.
IPHCプロトコルは、IPv6とIPv4の両方のデータグラムを圧縮することが可能です。 IPCPとIPV6CPの両方がIPHCのためのオプションパラメータ値を交渉することができます。これらの値は、外部ヘッダは、それぞれ、IPv4ヘッダとIPv6ヘッダでパケットの圧縮に適用されます。
For the compression and decompression of IPv4 and IPv6 datagram headers the context identifier space is shared. While the parameter values are independently negotiated, sharing the context identifier spaces becomes more complex when the parameter values differ. Since the compressed packets share context identifier space, the compression engine must allocate context identifiers out of a common pool; for compressed packets, the decompressor has to examine the context state to determine what parameters to use for decompression.
IPv4とIPv6データグラムヘッダの圧縮と解凍のためのコンテキスト識別子空間が共有されています。パラメータ値は、独立して交渉されているが、パラメータ値が異なる場合、コンテキスト識別子スペースを共有することは、より複雑になります。圧縮されたパケットを共有コンテキスト識別子空間ので、圧縮エンジンは、一般的なプールからコンテキスト識別子を割り当てなければなりません。圧縮されたパケットのために、デコンプレッサは、解凍に使用するどのようなパラメータを決定するために、コンテキストの状態を調べる必要があります。
Context identifier spaces are not shared between TCP and non-TCP/UDP/RTP. Doing so would require additional mechanisms to ensure that no error can occur when switching from using a context identifier for TCP to non-TCP.
コンテキスト識別子スペースはTCPと非TCP / UDP / RTPの間で共有されていません。そうすることで、非TCPにTCPのコンテキスト識別子を使用してから切り替えるときにエラーが発生しないことを保証するための追加の機構を必要とするであろう。
The IPHC specification [IPHC] defines four header formats for different types of compressed headers. They are compressed TCP, compressed TCP with no delta encoding, compressed non-TCP with 8 bit CID and compressed non-TCP with 16 bit CID. The two non-TCP formats may be distinguished by their contents so both may use the same link-level identifier. A fifth header format, the full header is distinct from a regular header in that it carries additional information to establish shared context between the compressor and decompressor.
IPHC仕様は[IPHC】圧縮されたヘッダーの異なるタイプのための4つのヘッダ・フォーマットを定義します。これらは、TCP圧縮8ビットCID及び16ビットCIDを有する圧縮非TCPと非TCP圧縮なし差分エンコーディングとTCPを圧縮されます。両方が同じリンクレベル識別子を使用することができるように、2つの非TCPフォーマットは、その内容によって区別することができます。それは、コンプレッサとデコンプレッサとの間の共有コンテキストを確立するために、追加の情報を運ぶという点で第五のヘッダフォーマットは、フル・ヘッダは、通常のヘッダとは区別されます。
The specification of IP/UDP/RTP Header Compression [CRTP] defines four additional formats of compressed headers. They are for compressed UDP and compressed RTP (on top of UDP), both with either 8- or 16-bit CIDs. In addition, there is an explicit error message from the decompressor to the compressor.
IP / UDP / RTPヘッダ圧縮[CRTP]の仕様は、圧縮されたヘッダーの4つの追加のフォーマットを定義します。彼らは（UDPの上に）、両方8ビットまたは16ビットのCIDで圧縮UDP及びRTP圧縮のためのものです。また、圧縮機への減圧装置からの明示的なエラー・メッセージがあります。
The link layer must be able to indicate these header formats with distinct values. Nine PPP Data Link Layer Protocol Field values are specified below.
リンク層は、異なる値と、これらのヘッダ・フォーマットを示すことができなければなりません。ナインPPPデータリンク層プロトコルフィールドの値は以下に指定されています。
FULL_HEADER The frame contains a full header as specified in [CRTP] Section 3.3.1. This is the same as the FULL_HEADER specified in [IPHC] Section 5.3. Value: 0061 (hex)
[CRTP]セクション3.3.1で指定されるようにフレームFULL_HEADERフル・ヘッダを含んでいます。これは、5.3節[IPHC]で指定FULL_HEADERと同じです。値：0061（16進数）
COMPRESSED_TCP The frame contains a datagram with a compressed header with the format as specified in [IPHC] Section 6a. Value: 0063 (hex)
フレームをCOMPRESSED_TCP [IPHC]部6aで指定されるよう形式で圧縮されたヘッダを持つデータグラムを含んでいます。値：0063（16進数）
COMPRESSED_TCP_NODELTA The frame contains a datagram with a compressed header with the format as specified in [IPHC] Section 6b. Value: 2063 (hex)
COMPRESSED_TCP_NODELTAフレームは[IPHC]部6bで指定されるよう形式で圧縮されたヘッダを持つデータグラムを含んでいます。値：2063（16進数）
COMPRESSED_NON_TCP The frame contains a datagram with a compressed header with the format as specified in either Section 6c or Section 6d of [IPHC]. Value: 0065 (hex)
フレームをCOMPRESSED_NON_TCPセクション6C又は[IPHC]のセクション6Dのいずれかに指定されている形式で圧縮されたヘッダを持つデータグラムを含んでいます。値：0065（16進数）
COMPRESSED_RTP_8 The frame contains a datagram with a compressed header with the format as specified in [CRTP] Section 3.3.2, using 8-bit CIDs. Value: 0069 (hex)
COMPRESSED_RTP_8フレームは、8ビットのCIDを使用して[CRTP]セクション3.3.2で指定されるようにフォーマットで圧縮されたヘッダを持つデータグラムを含んでいます。値：0069（16進数）
COMPRESSED_RTP_16 The frame contains a datagram with a compressed header with the format as specified in [CRTP] Section 3.3.2, using 16-bit CIDs. Value: 2069 (hex)
COMPRESSED_RTP_16フレームは、16ビットCIDを用いて[CRTP]セクション3.3.2で指定されるようにフォーマットで圧縮されたヘッダを持つデータグラムを含んでいます。値：2069（16進数）
COMPRESSED_UDP_8 The frame contains a datagram with a compressed header with the format as specified in [CRTP] Section 3.3.3, using 8-bit CIDs. Value: 0067 (hex)
COMPRESSED_UDP_8フレームは、8ビットのCIDを使用して[CRTP]セクション3.3.3で指定されるよう形式で圧縮されたヘッダを持つデータグラムを含んでいます。値：0067（16進数）
COMPRESSED_UDP_16 The frame contains a datagram with a compressed header with the format as specified in [CRTP] Section 3.3.3, using 16-bit CIDs. Value: 2067 (hex)
COMPRESSED_UDP_16フレームは、16ビットCIDを用いて[CRTP]セクション3.3.3で指定されるよう形式で圧縮されたヘッダを持つデータグラムを含んでいます。値：2067（16進数）
CONTEXT_STATE The frame is a link-level message sent from the decompressor to the compressor as specified in [CRTP] Section 3.3.5. Value: 2065 (hex)
フレームをCONTEXT_STATE [CRTP]セクション3.3.5で指定されるように圧縮機に減圧装置から送信されたリンクレベルメッセージです。値：2065（16進数）
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[CRTP] Casner、S.とV.ヤコブソン、RFC 2508、1999年2月 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"。
[IPHC] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for IP", RFC 2507, February 1999.
[IPHC] Degermark、M.、Nordgren、B.とS.ピンク、 "IPのヘッダ圧縮"、RFC 2507、1999年2月。
[RFC2023] Haskin, E. and E. Allan, "IP Version 6 over PPP", RFC 2023, October 1996.
[RFC2023] Haskin、E.およびE.アラン、 "PPPオーバーIPバージョン6"、RFC 2023、1996年10月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low- Speed Serial Links", RFC 1144, February 1990.
[RFC1144]ジェーコブソン、V.、 "圧縮TCP /低速シリアルリンクのIPヘッダ"、RFC 1144、1990年2月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]マクレガー、G.、 "PPPインターネットプロトコル制御プロトコル（IPCP）"、RFC 1332、1992年5月。
[RFC1889] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for real-time applications", RFC 1889, January 1996.
[RFC1889] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、エド。、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[MCML] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", Work in Progress.
、進行中の作業「マルチリンクPPPへのマルチクラス拡張」[MCML]ボルマン、C.、。
Negotiation of the option defined here imposes no additional security considerations beyond those that otherwise apply to PPP [RFC1661].
ここで定義されたオプションのネゴシエーションは、そうでない場合はPPP [RFC1661]に適用されるもの以外の追加のセキュリティの考慮事項を課していません。
The use of header compression can, in rare cases, cause the misdelivery of packets. If necessary, confidentiality of packet contents should be assured by encryption.
ヘッダ圧縮の使用は、まれに、パケットの誤配信を引き起こす可能性があります。必要に応じて、パケットの内容の機密性は、暗号化により保証されなければなりません。
Encryption applied at the IP layer (e.g., using IPSEC mechanisms) precludes header compression of the encrypted headers, though compression of the outer IP header and authentication/security headers is still possible as described in [IPHC]. For RTP packets, full header compression is possible if the RTP payload is encrypted by itself without encrypting the UDP or RTP headers, as described in [RFC1889]. This method is appropriate when the UDP and RTP header information need not be kept confidential.
（例えば、IPSECのメカニズムを使用して）IP層で適用暗号化は[IPHC]に記載されているように、外側IPヘッダおよび認証/セキュリティヘッダの圧縮はまだ可能であるが、暗号化されたヘッダのヘッダ圧縮を排除します。 [RFC1889]で説明されるようにRTPペイロードは、UDP又はRTPヘッダを暗号化せずに単独で暗号化されている場合、RTPパケットの場合、完全なヘッダ圧縮が可能です。 UDP及びRTPヘッダ情報を秘密にする必要がない場合、この方法が適切です。
Mathias Engan Effnet Aurorum 2 SE-977 75 Lulea, Sweden
マティアスenkan eppipinet ororum 2セルラ977 75、スウェーデン
Phone: +46 920 75600 Mobile: +46 70 833 8932 Fax: +46 920 75610 EMail: engan@effnet.com
電話：+46 920 75600携帯電話：+46 70 833 8932ファックス：+46 920 75610 Eメール：engan@effnet.com
Stephen L. Casner Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 United States
スティーブンL. Casnerシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706米国
EMail: casner@cisco.com
メールアドレス：casner@cisco.com
Carsten Bormann Universitaet Bremen FB3 TZI Postfach 330440 D-28334 Bremen, GERMANY
カールステンボルマンUniversitaetブレーメンTZI FB3 POSTFACH 330440 D-28334ブレーメン、ドイツ
Phone: +49.421.218-7024 Fax: +49.421.218-7000 EMail: cabo@tzi.org
電話：+ 49.421.218-7024ファックス：+ 49.421.218-7000 Eメール：cabo@tzi.org
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。