[要約] RFC 2509は、PPP上でのIPヘッダー圧縮に関する仕様です。その目的は、ネットワークトラフィックの効率を向上させ、帯域幅の節約を実現することです。
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
PPP上のIPヘッダー圧縮
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.
Copyright（c）The Internet Society（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ヘッダー圧縮は、IPHCによって定義されたフレームワーク内に適合するため、IPv4パケットとIPv6パケットの両方にも適用できます。
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
PPPリンクを介して送信されたIPデータグラムの圧縮を確立するには、リンクの各端が圧縮の構成パラメーターのセットに同意する必要があります。ネットワークレイヤープロトコルのリンクパラメーターを交渉するプロセスは、ネットワーク制御プロトコル（NCP）のファミリーによってPPPで処理されます。IPv4とIPv6用の個別のNCPがあるため、このドキュメントは構成オプションを定義します
used in both NCPs to negotiate parameters for the compression scheme.
両方の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-Compression-Protocolオプションの新しい圧縮プロトコル値を指定します。新しい値と関連するオプション形式については、セクション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-Compression-Protocol構成オプション[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]は、オプションが受信者または送信者の機能を交渉するかどうかを明示していません。現在の練習に沿って、このオプションは、config-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-Compression-Protocol 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で、最大255である必要があります（値0は1つのコンテキストを持つことを意味します）。
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でなければならず、最大65535では（値0は1つのコンテキストを持つことを意味します）。
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フルヘッダー間の最大間隔。fle_headerヘッダー間でf_max_period compressed_non_tcpヘッダー以下です。
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.
RTP-Compressionサブオプションは、IP/UDP/RTP圧縮を有効にする場合、IPHCのNCP IP-Compression-Protocolオプションに含まれています。
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の使用が有効になります。
Description
説明
Enable use of Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP and CONTEXT_STATE as specified in [CRTP].
[CRTP]で指定されているように、Protocol Identifiersの使用を有効にします。
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
IPv4およびIPv6データグラムの圧縮と減圧のために、コンテキスト識別子スペースが共有されます。パラメーター値は独立してネゴシエートされますが、パラメーター値が異なると、コンテキスト識別子スペースの共有がより複雑になります。以来
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.
圧縮パケットはコンテキスト識別子スペースを共有します。圧縮エンジンは、共通のプールからコンテキスト識別子を割り当てる必要があります。圧縮パケットの場合、減圧装置はコンテキスト状態を調べて、減圧に使用するパラメーターを決定する必要があります。
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、デルタエンコードなしで圧縮されたTCP、8ビットCIDを備えた圧縮非TCP、16ビットCIDで圧縮された非TCPです。2つの非TCP形式は、その内容によって区別される可能性があるため、どちらも同じリンクレベルの識別子を使用できます。5番目のヘッダー形式であるフルヘッダーは、コンプレッサーと減圧装置の間で共有コンテキストを確立するための追加情報を運ぶという点で、通常のヘッダーとは異なります。
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および圧縮RTP（UDPの上部）であり、どちらも8ビットまたは16ビットのCIDを使用します。さらに、減圧器からコンプレッサーへの明示的なエラーメッセージがあります。
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.
リンクレイヤーは、これらのヘッダー形式を異なる値で示すことができる必要があります。9つの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)
Full_headerフレームには、[CRTP]セクション3.3.1で指定されているフルヘッダーが含まれています。これは、[IPHC]セクション5.3で指定されているFull_headerと同じです。値：0061（六角）
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（六角）
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（ヘックス）
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フレームには、[IPHC]のセクション6Cまたはセクション6Dで指定されているように、形式を備えた圧縮ヘッダーを備えたデータグラムが含まれています。値：0065（六角）
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（六角）
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（ヘックス）
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（六角）
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（ヘックス）
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（ヘックス）
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[CRTP] Casner、S。およびV. Jacobson、「低速シリアルリンク用のIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[IPHC] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for IP", RFC 2507, February 1999.
[IPHC] Degermark、M.、Nordgren、B。およびS. Pink、「IPのヘッダー圧縮」、RFC 2507、1999年2月。
[RFC2023] Haskin, E. and E. Allan, "IP Version 6 over PPP", RFC 2023, October 1996.
[RFC2023] Haskin、E。およびE. Allan、「PPP上のIPバージョン6」、RFC 2023、1996年10月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low- Speed Serial Links", RFC 1144, February 1990.
[RFC1144] Jacobson、V。、「低速シリアルリンクのTCP/IPヘッダーの圧縮」、RFC 1144、1990年2月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332] McGregor、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.、Frederick、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] Simpson、W.、ed。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[MCML] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", Work in Progress.
[MCML] Bormann、C。、「マルチリンクPPPへのマルチクラス拡張」、進行中の作業。
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.
IPレイヤー（例えば、IPSECメカニズムを使用する）で適用される暗号化は、暗号化されたヘッダーのヘッダー圧縮を妨げますが、[IPHC]で説明されているように、外側のIPヘッダーと認証/セキュリティヘッダーの圧縮はまだ可能です。RTPパケットの場合、[RFC1889]に記載されているように、UDPまたはRTPヘッダーを暗号化せずにRTPペイロードが暗号化されている場合、フルヘッダー圧縮が可能です。この方法は、UDPおよびRTPヘッダー情報を機密保持する必要がない場合に適切です。
Mathias Engan Effnet Aurorum 2 SE-977 75 Lulea, Sweden
Mathias Engan Effnet Aurorum 2 SE-977 75 Lulea、Sweden
Phone: +46 920 75600
Mobile: +46 70 833 8932
Fax: +46 920 75610
EMail: engan@effnet.com
Stephen L. Casner Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 United States
Stephen L. Casner Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134-1706米国
EMail: casner@cisco.com
Carsten Bormann Universitaet Bremen FB3 TZI Postfach 330440 D-28334 Bremen, GERMANY
Carsten Bormann Universitaet Bremen FB3 TZI POSTFACH 330440 D-28334ブレーメン、ドイツ
Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.org
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。