[要約] RFC 3544は、PPP上でのIPヘッダー圧縮に関する標準仕様であり、IPパケットのヘッダー情報を圧縮することでネットワーク帯域幅を節約することを目的としています。
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
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 (2003). All Rights Reserved.
Copyright（c）The Internet Society（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）は、複数のIPヘッダーでカプセル化されたIPv4データグラムとIPv6データグラムの両方の圧縮に使用できます。IPHCは、TCPとUDP輸送プロトコルヘッダーの両方を圧縮することもできます。[RFC2508]および[RFC3545]で定義された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 used in both NCPs to negotiate parameters for the compression scheme.
リンクの各端をPPPリンク上に送信したIPデータグラムの圧縮を確立するには、圧縮の構成パラメーターのセットに同意する必要があります。ネットワークレイヤープロトコルのリンクパラメーターを交渉するプロセスは、ネットワーク制御プロトコル（NCP）のファミリーによってPPPで処理されます。IPv4とIPv6には個別のNCPがあるため、このドキュメントでは、両方の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.
このドキュメントはRFC 2509を廃止し、IPヘッダー圧縮構成オプションに2つの新しいサブオプションを追加します。1つのサブオプションは、強化されたRTP圧縮の使用（[RFC3545]で指定）の使用と交渉し、もう1つのサブオプションは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-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. [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-Compress-Protocol構成オプションの複数のインスタンスの送信を明示的に許可することにより、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]は、オプションが受信者または送信者の機能を交渉するかどうかを明示していません。現在の実践に沿って、このオプションは、config-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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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（六角）
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フルヘッダー間の最大間隔。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.
RTP-Compressionサブオプションは、IP/UDP/RTP圧縮を有効にする場合、IPHCのNCP IP-Compression-Protocolオプションに含まれています。
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-Compression Suboptionを含めることで、[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]で指定されているように、protocol識別子の使用を有効にします。
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
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の使用を有効にします。さらに、[RFC3545]コンプライアンス圧縮の使用を有効にします。プロトコル識別子Compressed_udpの使用を含むコンプライアンスな圧縮は、Full_Headerプロトコル識別子を使用してCフラグを使用してCLAGを使用して、Compressed_RTPおよびCompressed_UDPパケットを使用してHDRCKSUMを使用します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、デルタエンコードなしで圧縮されたTCP、8ビットCIDを備えた圧縮非TCP、16ビットCIDで圧縮された非TCPです。2つの非TCP形式は、その内容によって区別される可能性があるため、どちらも同じリンクレベル識別子を使用できます。5番目のヘッダー形式であるフルヘッダーは、コンプレッサーと減圧装置の間に共有コンテキストを確立するための追加情報を掲載するという点で、通常のヘッダーとは異なります。
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つの追加形式を定義します。これらは、8ビットまたは16ビットのCIDを使用して、圧縮UDPおよび圧縮RTP（UDPの上部）用です。さらに、減圧器からコンプレッサーへの明示的なエラーメッセージがあります。
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 [RFC2508] Section 3.3.1. This is the same as the FULL_HEADER specified in [RFC2507] Section 5.3. Value: 0061 (hex)
Full_headerフレームには、[RFC2508]セクション3.3.1で指定されているフルヘッダーが含まれています。これは、[RFC2507]セクション5.3で指定されているFull_headerと同じです。値：0061（六角）
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（六角）
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フレームには、[RFC2507]のセクション6Cまたはセクション6Dで指定されているように、形式を備えた圧縮ヘッダーを備えたデータグラムが含まれています。値：0065（六角）
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フレームには、[RFC2508]セクション3.3.2で指定されている形式の圧縮ヘッダーを備えたデータグラムが含まれており、8ビットCIDを使用しています。値：0069（六角）
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（六角）
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で指定されているように、または[RFC3545]セクション2.1で指定されているように、8ビットCIDを使用して[RFC3545]セクション2.1で指定されているように、形式の圧縮ヘッダーを備えたデータグラムが含まれています。値：0067（六角）
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（ヘックス）
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（六角）
Two new suboptions are specified. See Sections 2.3 and 2.4.
2つの新しいサブオプションが指定されています。セクション2.3および2.4を参照してください。
[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月。
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[RFC2472] Haskin、D。およびE. Allen、「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. Pink、「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] Bormann、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] Koren、T.、Casner、S.、Geevarghese、J.、Thompson、B。、およびP. Ruddy、「高度な遅延、パケット損失、再注文を伴うリンクのための圧縮RTP（CRTP）の強化」、RFC 3545、7月2003年。
[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月。
[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] Bormann、C。、「マルチリンクPPPへのマルチクラス拡張」、RFC 2686、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.、Frederick、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ポイントツーポイントプロトコルフィールド割り当てレジストリの既存の名前空間からの追加の割り当ては必要ありません。ただし、RFC 1332、RFC 2472、およびRFC 2509で定義された3つの名前空間がありますが、レジストリには作成されていません。以下で説明するこれらの3つの名前空間は、PPPレジストリに追加されました。このドキュメントは、3番目のドキュメントに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-Compression-Protocolタイプフィールドの1つの値を定義します。IANAレジストリは、そのタイプフィールドに追加の値を割り当てるために作成されました。RFC 1332で述べたように、IP圧縮-Protocolタイプフィールドの値は、特定の圧縮プロトコルのパケットに割り当てられた（プライマリ）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-Compression-Protocol構成オプションを指定し、そのオプションでIPv6-Compression-Protocolタイプフィールドの1つの値を定義します。IANAレジストリは、そのタイプフィールドに追加の値を割り当てるために作成されました。IPv6-Compression-Protocol構成オプションは、RFC 1332で定義されているIP-Compression-Protocol構成オプションと同じ構造を持っていますが、タイプフィールドに定義された値のセットは異なる場合があります。RFC 2472で述べたように、IPv6-Compression-Protocolタイプフィールドの値は、特定の圧縮プロトコルのパケットに割り当てられた（プライマリ）PPP DLLプロトコル番号と常に同じです。追加のIPv6-Compression-Protocolタイプの値の割り当ては、[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-Compression-Protocol構成オプションとIPv6-Compression-Protocol構成オプションの両方に登録される追加のタイプ値を指定します。そのタイプ値の仕様は、RFC 2509を廃止するこのドキュメントのセクション2.1で繰り返されます。追加のタイプ値と併せて、変数長オプションの形式が指定されています。この形式には、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は、1つのサブオプションタイプを定義しています。このドキュメントのセクション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.
IPレイヤー（例えば、IPSECメカニズムを使用する）で適用される暗号化は、暗号化されたヘッダーのヘッダー圧縮を妨げますが、[RFC2507]で説明されているように、外側のIPヘッダーと認証/セキュリティヘッダーの圧縮はまだ可能です。RTPパケットの場合、[RFC3550]に記載されているように、RTPペイロードがUDPまたは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.
Mathias EnganはRFC 2509の主要な著者であり、この文書は改訂版です。
Tmima Koren Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 United States
Tmima Koren Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134-1706米国
EMail: tmima@cisco.com
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States
Stephen L. Casner Packet Design 3400 Hillview Avenue、Building 3 Palo Alto、CA 94304米国
EMail: casner@packetdesign.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 (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。