Network Working Group T. Koren
Request for Comments: 3544 Cisco Systems
Obsoletes: 2509 S. Casner
Category: Standards Track Packet Design
C. Bormann
Universitaet Bremen TZI
July 2003
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 (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol (RFC 1661). It defines extensions to the PPP Control Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472). Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in RFC 2507, RFC 2508 and RFC 3545.
この文書では、ポイントツーポイントプロトコル（RFC 1661）を介して送信されたIPデータグラムにヘッダ圧縮の使用を交渉するためのオプションが記載されています。これは、IPv4とIPv6のPPP制御プロトコル（RFC 1332、RFC 2472）への拡張を定義します。 RFC 2507、RFC 2508、およびRFC 3545に指定されているヘッダ圧縮は、TCP、UDP及びRTPトランスポートプロトコルとの組み合わせで、IPv4とIPv6データグラムに適用されてもよいです。
The IP Header Compression (IPHC) defined in [RFC2507] 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 [RFC2508] and [RFC3545] fits within the framework defined by IPHC so that it may also be applied to both IPv4 and IPv6 packets.
[RFC2507]で定義されたIPヘッダー圧縮（IPHC）は、IPv4およびIPv6データグラムまたは複数のIPヘッダでカプセル化されたパケットの両方の圧縮に使用することができます。 IPHCはまた、TCPとUDPトランスポートプロトコルヘッダの両方を圧縮することができます。 [RFC2508]及び[RFC3545]で定義された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で使用される構成オプションを定義します。
This document obsoletes RFC 2509, adding two new suboptions to the IP header compression configuration option. One suboption negotiates usage of Enhanced RTP-Compression (specified in [RFC3545]), and the other suboption negotiates header compression for only TCP or only non-TCP packets.
この文書では、IPヘッダー圧縮の設定オプションに二つの新しいサブオプションを追加して、RFC 2509を廃止します。一つのサブオプションは、（[RFC3545]で指定された）拡張RTP圧縮の使用をネゴシエートし、他のサブオプションは、TCPまたは唯一の非TCPパケットのヘッダ圧縮を交渉します。
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 [RFC2507] 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 [RFC2686], care must be taken so that packets that share the same compression context are not reordered.
一般的に、圧縮されたパケットのデルタ符号化を使用するヘッダ圧縮方式は、下層は、コンプレッサとデコンプレッサとの間のパケットの順序を変更しないことを必要とします。 IPHCはTCPおよびRTPのための圧縮パケットのデルタエンコーディングを使用しています。 IPHC仕様[RFC2507]はIPHCで使用するパケットの順序を変更することができるリンク層を可能にする方法を含みます。 PPPは、パケットの順序を変更していないため、これらのメカニズムは、デフォルトでは無効になっています。そのようなマルチクラスマルチリンクPPP [RFC2686]として再順序付けメカニズムを使用する場合、同じ圧縮コンテキストを共有するパケットが並べ替えられないように、注意を払わなければなりません。
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. [RFC3241] updates RFC 1332 by explicitly allowing the sending of multiple instances of the IP-Compression-Protocol configuration option, each with a different value for IP-Compression-Protocol. Each type of compression protocol may independently establish its own parameters.
注：PPP [RFC1661]、[RFC1331]、[RFC1332]のリンクとネットワーク層パラメータネゴシエーションの仕様は、1つの設定オプションの複数のインスタンスを禁止しますが、構成オプションの指定が明示的に複数のインスタンスを許可しなければならないことを述べていません。 [RFC3241]は、明示的にIP圧縮プロトコル設定オプションの複数のインスタンス、IP圧縮・プロトコルのための異なる値を持つそれぞれの送信を可能にすることによって、RFC 1332を更新します。圧縮プロトコルの各タイプには、独立して、独自のパラメータを確立することができます。
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 [RFC2472] 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 [RFC2472]のためのネットワーク制御プロトコルの両方は、それぞれのプロトコルのIPヘッダ圧縮パラメータを交渉するために使用することができます。設定オプションのフォーマットは、IPCPとIPV6CPの両方で同じです。
Description
説明
This NCP configuration option is used to negotiate parameters for IP Header Compression. Successful negotiation of parameters enables the use of Protocol Identifiers FULL_HEADER, COMPRESSED_TCP, COMPRESSED_TCP_NODELTA, COMPRESSED_NON_TCP and CONTEXT_STATE as specified in [RFC2507]. The option format is summarized below. The fields are transmitted from left to right.
このNCPの設定オプションは、IPヘッダ圧縮のためのパラメータを交渉するために使用されます。パラメータの成功した交渉は、[RFC2507]で指定されたプロトコル識別子FULL_HEADER、COMPRESSED_TCP、COMPRESSED_TCP_NODELTA、COMPRESSED_NON_TCPとCONTEXT_STATEの使用を可能にします。オプションの形式は以下のように要約されます。フィールドは左から右に送信されます。
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... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ| IP-圧縮、プロトコル| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | TCP_SPACE | NON_TCP_SPACE | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | F_MAX_PERIOD | F_MAX_TIME | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | MAX_HEADER |サブオプション... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
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... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ|パラメータ... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
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圧縮プロトコルオプションに含まれています。
Inclusion of the RTP-Compression suboption enables use of additional Protocol Identifiers COMPRESSED_RTP and COMPRESSED_UDP along with additional forms of CONTEXT_STATE as specified in [RFC2508].
RTP圧縮サブオプションを含めることは、[RFC2508]で指定されるようCONTEXT_STATEの追加の形態と共に追加のプロトコル識別子COMPRESSED_RTPとCOMPRESSED_UDPの使用を可能にします。
Description
説明
Enable use of Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP and CONTEXT_STATE as specified in [RFC2508].
[RFC2508]で指定されたプロトコル識別子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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Type 1
タイプ1
Length 2
長さ2
To use the enhanced RTP header compression defined in [RFC3545], a new sub-option 2 is added. Sub-option 2 is negotiated instead of, not in addition to, sub-option 1.
[RFC3545]で定義された拡張RTPヘッダ圧縮を使用するように、新たなサブオプション2を添加します。サブオプション2ではない、サブオプション1に加えて、代わりにネゴシエートされます。
Description
説明
Enable use of Protocol Identifiers COMPRESSED_RTP and CONTEXT_STATE as specified in [RFC2508]. In addition, enable use of [RFC3545] compliant compression including the use of Protocol Identifier COMPRESSED_UDP with additional flags and use of the C flag with the FULL_HEADER Protocol Identifier to indicate use of HDRCKSUM with COMPRESSED_RTP and COMPRESSED_UDP packets.
[RFC2508]で指定されたプロトコル識別子COMPRESSED_RTPとCONTEXT_STATEの使用を有効にします。また、COMPRESSED_RTPとCOMPRESSED_UDPパケットでHDRCKSUMの使用を示すために、追加のフラグとFULL_HEADERプロトコル識別子とCフラグを用いて、プロトコル識別子COMPRESSED_UDPの使用を含む[RFC3545]に準拠した圧縮の使用を可能にします。
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Type 2
タイプ2
Length 2
長さ2
2.4. Negotiating header compression for only TCP or only non-TCP packets
2.4. のみTCPまたは唯一の非TCPパケットのヘッダ圧縮を交渉
In RFC 2509 it was not possible to negotiate only TCP header compression or only non-TCP header compression because a value of 0 in the TCP_SPACE or the NON_TCP_SPACE fields actually means that 1 context is negotiated.
RFC 2509にはTCP_SPACE又はNON_TCP_SPACEフィールドにおける0の値は、実際に1つのコンテキストがネゴシエートされていることを意味するためにのみTCPヘッダ圧縮又は唯一の非TCPヘッダ圧縮を交渉することはできませんでした。
A new suboption 3 is added to allow specifying that the number of contexts for TCP_SPACE or NON_TCP_SPACE is zero, disabling use of the corresponding compression.
新しいサブオプション3は、対応する圧縮の使用を無効にする、TCP_SPACE又はNON_TCP_SPACEためのコンテキストの数がゼロであることを指定できるようにするために添加されます。
Description
説明
Enable header compression for only TCP or only non-TCP packets.
唯一のTCPまたは唯一の非TCPパケットのヘッダー圧縮を有効にします。
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 | Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 3
タイプ3
Length 3
長さ3
Parameter
パラメーター
The parameter is 1 byte with one of the following values:
パラメータは、次のいずれかの値を持つ1バイトであります：
1 = the number of contexts for TCP_SPACE is 0 2 = the number of contexts for NON_TCP_SPACE is 0
1 = TCP_SPACEためのコンテキストの数は0〜2である= NON_TCP_SPACEためのコンテキストの数が0であります
This suboption overrides the values that were previously assigned to TCP_SPACE and NON_TCP_SPACE in the IP Header Compression option.
このサブオプションは、以前にIPヘッダー圧縮オプションでTCP_SPACEとNON_TCP_SPACEに割り当てられた値を上書きします。
If suboption 3 is included multiple times with parameter 1 and 2, compression is disabled for all packets.
サブオプション3は、パラメータ1と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 [RFC2507] 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仕様[RFC2507]は圧縮されたヘッダーの異なるタイプのための4つのヘッダ・フォーマットを定義します。これらは、TCP圧縮8ビットCID及び16ビットCIDを有する圧縮非TCPと非TCP圧縮なし差分エンコーディングとTCPを圧縮されます。両方が同じリンクレベル識別子を使用することができるように、2つの非TCPフォーマットは、その内容によって区別することができます。それは、コンプレッサとデコンプレッサとの間の共有コンテキストを確立するために、追加の情報を運ぶという点で第五のヘッダフォーマットは、フル・ヘッダは、通常のヘッダとは区別されます。
The specification of IP/UDP/RTP Header Compression [RFC2508] 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ヘッダ圧縮[RFC2508]の仕様は、圧縮されたヘッダーの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 [RFC2508] Section 3.3.1. This is the same as the FULL_HEADER specified in [RFC2507] Section 5.3. Value: 0061 (hex)
[RFC2508]セクション3.3.1で指定されるようにフレームFULL_HEADERフル・ヘッダを含んでいます。これは、[RFC2507]セクション5.3で指定さFULL_HEADERと同じです。値：0061（16進数）
COMPRESSED_TCP The frame contains a datagram with a compressed header with the format as specified in [RFC2507] Section 6a. Value: 0063 (hex)
COMPRESSED_TCPフレームは[RFC2507]セクション6aに指定されている形式で圧縮されたヘッダを持つデータグラムを含んでいます。値：0063（16進数）
COMPRESSED_TCP_NODELTA The frame contains a datagram with a compressed header with the format as specified in [RFC2507] Section 6b. Value: 2063 (hex)
COMPRESSED_TCP_NODELTAフレームは[RFC2507]セクション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 [RFC2507]. Value: 0065 (hex)
フレームをCOMPRESSED_NON_TCPセクション6Cまたは[RFC2507]のセクション6dのいずれかに指定されている形式で圧縮されたヘッダを持つデータグラムを含んでいます。値：0065（16進数）
COMPRESSED_RTP_8 The frame contains a datagram with a compressed header with the format as specified in [RFC2508] Section 3.3.2, using 8-bit CIDs. Value: 0069 (hex)
COMPRESSED_RTP_8フレームは、8ビットのCIDを使用して、[RFC2508]セクション3.3.2で指定されるようにフォーマットと圧縮ヘッダを持つデータグラムを含んでいます。値：0069（16進数）
COMPRESSED_RTP_16 The frame contains a datagram with a compressed header with the format as specified in [RFC2508] Section 3.3.2, using 16-bit CIDs. Value: 2069 (hex)
COMPRESSED_RTP_16フレームは、16ビットCIDを用いて、[RFC2508]セクション3.3.2で指定されるようにフォーマットと圧縮ヘッダを持つデータグラムを含んでいます。値：2069（16進数）
COMPRESSED_UDP_8 The frame contains a datagram with a compressed header with the format as specified in [RFC2508] Section 3.3.3 or as specified in [RFC3545] Section 2.1, using 8-bit CIDs. Value: 0067 (hex)
COMPRESSED_UDP_8フレームは[RFC2508]セクション3.3.3に8ビットのCIDを使用して、[RFC3545]セクション2.1で指定されるように指定されている形式で圧縮されたヘッダを持つデータグラムを含んでいます。値：0067（16進数）
COMPRESSED_UDP_16 The frame contains a datagram with a compressed header with the format as specified in [RFC2508] Section 3.3.3 or as specified in [RFC3545] Section 2.1, using 16-bit CIDs. Value: 2067 (hex)
COMPRESSED_UDP_16フレームは[RFC2508]セクション3.3.3で指定された16ビットのCIDを使用して、[RFC3545]セクション2.1で指定されているようなフォーマットを持つ圧縮ヘッダを持つデータグラムを含んでいます。値：2067（16進数）
CONTEXT_STATE The frame is a link-level message sent from the decompressor to the compressor as specified in [RFC2508] Section 3.3.5. Value: 2065 (hex)
フレームをCONTEXT_STATE [RFC2508]セクション3.3.5で指定されるように圧縮機に減圧装置から送信されたリンクレベルメッセージです。値：2065（16進数）
Two new suboptions are specified. See Sections 2.3 and 2.4.
二つの新しいサブオプションが指定されています。セクション2.3と2.4を参照してください。
[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月。
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[RFC2472] Haskin、D.およびE.アレン、 "PPPオーバーIPバージョン6"、RFC 2472、1998年12月。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for IP", RFC 2507, February 1999.
[RFC2507] Degermark、M.、Nordgren、B.とS.ピンク、 "IPのヘッダ圧縮"、RFC 2507、1999年2月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508] Casner、S.とV. Jacobson氏、 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"、RFC 2508、1999年2月。
[RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[RFC3241]ボルマン、C.、 "PPPオーバーロバストヘッダ圧縮（ROHC）"、RFC 3241、2002年4月。
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B. and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, July 2003.
[RFC3545]コレン、T.、Casner、S.、Geevarghese、J.、トンプソン、B.およびP.ルディ、 "強化された圧縮RTP高遅延、パケットロス・順序付きリンクの（CRTP）"、RFC 3545、2011 2003。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[RFC2686]ボルマン、C.、RFC 2686 "マルチリンクPPPへのマルチクラス拡張"、1999年9月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 3550、2003年7月。
This document does not require any additional allocations from existing namespaces in the IANA Point-to-Point Protocol Field Assignments registry. However, there are three namespaces that were defined by RFC 1332, RFC 2472, and RFC 2509 but not created in the registry. Those three namespaces, described below, have been added to the PPP registry. This document specifies two additional allocations in the third one.
この文書は、IANAのPoint-to-Pointプロトコルフィールドの割り当て、レジストリ内の既存の名前空間からの任意の追加割り当てを必要としません。しかし、RFC 1332、RFC 2472、およびRFC 2509で定義されているが、レジストリに作成されていない3つの名前空間があります。下記のこれらの3つの名前空間は、PPPのレジストリに追加されました。この文書では、三番目に2つの追加割り当てを指定します。
Section 3.2 of RFC 1332 specifies an IP-Compression-Protocol Configuration Option for the PPP IP Control Protocol and defines one value for the IP-Compression-Protocol type field in that option. An IANA registry has been created to allocate additional values for that type field. As stated in RFC 1332, the values for the IP-Compression-Protocol type field are always the same as the (primary) PPP DLL Protocol Number assigned to packets of the particular compression protocol. Assignment of additional IP-Compression-Protocol type values is through the IETF consensus procedure as specified in [RFC2434].
RFC 1332のセクション3.2は、PPP IP制御プロトコルのためのIP-Compression-Protocolのを指定すると、そのオプションでIP-圧縮・プロトコルタイプフィールドに1つの値を定義します。 IANAレジストリはそのタイプフィールドの追加の値を割り当てるために作成されています。 RFC 1332に記載されているように、IP圧縮プロトコルタイプフィールドの値は、常に特定の圧縮プロトコルのパケットに割り当てられた（一次）PPP DLLプロトコル番号と同じです。追加のIP圧縮プロトコルタイプ値の割り当ては、[RFC2434]で指定されるようにIETFコンセンサス手順によるものです。
Section 4.2 of RFC 2472 specifies an IPv6-Compression-Protocol Configuration Option for the PPP IPv6 Control Protocol and defines one value for the IPv6-Compression-Protocol type field in that option. An IANA registry has been created to allocate additional values for that type field. The IPv6-Compression-Protocol Configuration Option has the same structure as the IP-Compression-Protocol Configuration Option defined in RFC 1332, but the set of values defined for the type field may be different. As stated in RFC 2472, the values for the IPv6-Compression-Protocol type field are always the same as the (primary) PPP DLL Protocol Number assigned to packets of the particular compression protocol. Assignment of additional IPv6-Compression-Protocol type values is through the IETF consensus procedure as specified in [RFC2434].
RFC 2472のセクション4.2は、PPPのIPv6制御プロトコルのIPv6圧縮・プロトコル設定オプションを指定すると、そのオプションでのIPv6圧縮プロトコルタイプのフィールドに1つの値を定義します。 IANAレジストリはそのタイプフィールドの追加の値を割り当てるために作成されています。 IPv6の圧縮・プロトコル設定オプションは、RFC 1332で定義されたIP圧縮、プロトコル設定オプションと同じ構造を有するが、タイプフィールドに対して定義された値のセットが異なっていてもよいです。 RFC 2472に記載されているように、IPv6の圧縮プロトコルタイプフィールドの値は、常に特定の圧縮プロトコルのパケットに割り当てられた（一次）PPP DLLプロトコル番号と同じです。追加のIPv6圧縮プロトコルタイプ値の割り当ては、[RFC2434]で指定されるようにIETFコンセンサス手順によるものです。
Section 2.1 of RFC 2509 specifies an additional type value to be registered for both the IP-Compression-Protocol Configuration Option and the IPv6-Compression-Protocol Configuration Option to indicate use of the "IP Header Compression" protocol. The specification of that type value is repeated in Section 2.1 of this document which obsoletes RFC 2509. In conjunction with the additional type value, the format for the variable-length option is specified. The format includes a suboption field that may contain one or more suboptions. Each suboption begins with a suboption type value. An IANA registry has been created for the suboption type values; and is titled, "IP Header Compression Configuration Option Suboption Types".
RFC 2509のセクション2.1には、IP-圧縮・プロトコル設定オプションと「IPヘッダー圧縮」プロトコルの使用を示すために、IPv6の圧縮・プロトコル設定オプションの両方に登録する追加型の値を指定します。そのタイプの値の指定は、可変長オプションのフォーマットが指定され、追加のタイプの値に関連してRFC 2509を時代遅れこのドキュメントのセクション2.1で繰り返されます。フォーマットは、一つ以上のサブオプションを含むことができるサブオプションフィールドを含みます。各サブオプションはサブオプションタイプの値で始まります。 IANAレジストリは、サブオプションタイプ値のために作成されています。そして、「IPヘッダー圧縮設定オプションのサブオプションタイプ」と題されています。
Section 2.2 of RFC 2509 (and this document) defines one suboption type. Sections 2.3 and 2.4 of this document define two additional suboption types. It is expected that the number of additional suboptions that will need to be defined is small. Therefore, anyone wishing to define new suboptions is required to produce a revision of this document to be vetted through the normal Internet Standards process, as specified in [RFC2434].
RFC 2509（およびこの文書）のセクション2.2は、一つのサブオプションタイプを定義します。セクション2.3および本書の2.4は、2つの追加サブオプションタイプを定義します。定義する必要があります追加のサブオプションの数が少ないことが期待されます。したがって、新たなサブオプションを定義することを望む誰もが[RFC2434]で指定されるように、通常のインターネット標準プロセスを通して吟味するために、この文書の改訂を生成するために必要とされます。
RFC 2509 also defines nine PPP Data Link Layer Protocol Field values which are already listed in the IANA registry of Point-to-Point Protocol Field Assignments. Section 4 of this document repeats the specification of those values without change.
RFC 2509はまた、既にポイントツーポイントプロトコルフィールドの割り当てのIANAレジストリに記載されています9つのPPPデータリンク層プロトコルフィールドの値を定義します。このドキュメントのセクション4は、変更せずに、これらの値の仕様を繰り返します。
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 [RFC2507]. 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 [RFC3550]. This method is appropriate when the UDP and RTP header information need not be kept confidential.
（例えば、IPSECのメカニズムを使用して）IP層で適用暗号化は、[RFC2507]に記載されているように、外側IPヘッダおよび認証/セキュリティヘッダの圧縮はまだ可能であるが、暗号化されたヘッダのヘッダ圧縮を排除します。 [RFC3550]で説明されるようにRTPペイロードは、UDP又はRTPヘッダを暗号化せずに単独で暗号化されている場合、RTPパケットの場合、完全なヘッダ圧縮が可能です。 UDP及びRTPヘッダ情報を秘密にする必要がない場合、この方法が適切です。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
Mathias Engan was the primary author of RFC 2509, of which this document is a revision.
マティアスEnganは、この文書が改訂となっているRFC 2509の主執筆者でした。
Tmima Koren Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 United States
Tmimaコレンシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706米国
EMail: tmima@cisco.com
メールアドレス：tmima@cisco.com
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States
スティーブンL. Casnerパケットデザイン3400ヒルビュー・アベニュー、3パロアルト、CA 94304米国の構築
EMail: casner@packetdesign.com
メールアドレス：casner@packetdesign.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 (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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 assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。