Network Working Group M. Degermark
Request for Comments: 2507 Lulea University of Technology/SICS
Category: Standards Track B. Nordgren
Lulea University of Technology/Telia Research AB
S. Pink
Lulea University of Technology/SICS
February 1999
IP Header Compression
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 how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. The methods can be applied to of IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers.
この文書では、リンクをポイントツーポイントの上にホップごとに複数のIPヘッダおよびTCPとUDPヘッダを圧縮する方法について説明します。方法は、IPv6ベース及び拡張ヘッダはIPv4ヘッダ、TCPとUDPヘッダのに適用され、IPv6とIPv4ヘッダをカプセル化することができます。
Headers of typical UDP or TCP packets can be compressed down to 4-7 octets including the 2 octet UDP or TCP checksum. This largely removes the negative impact of large IP headers and allows efficient use of bandwidth on low and medium speed links.
典型的なUDPまたはTCPパケットのヘッダは2オクテットのUDPまたはTCPチェックサムを含む4-7オクテットに圧縮することができます。これは、主に大規模なIPヘッダの負の影響を除去し、低中速のリンク上の帯域幅の効率的な使用を可能にします。
The compression algorithms are specifically designed to work well over links with nontrivial packet-loss rates. Several wireless and modem technologies result in such links.
圧縮アルゴリズムは、具体的には自明でないパケット損失率とのリンク上でうまく動作するように設計されています。いくつかのワイヤレスモデム技術は、このようなリンクになります。
TABLE OF CONTENTS
目次
1. Introduction..............................................3
2. Terminology...............................................5
3. Compression method........................................7
3.1. Packet types.......................................8
3.2. Lost packets in TCP packet streams.................9
3.3. Lost packets in UDP and non-TCP packet streams....10
4. Grouping packets into packet streams.....................14
4.1. Guidelines for grouping packets...................15
5. Size Issues..............................................16
5.1. Context identifiers...............................16
5.2. Size of the context...............................17
5.3. Size of full headers..............................18
5.3.1. Length fields in full TCP headers............19
5.3.2. Length fields in full non-TCP headers........19
6. Compressed Header Formats................................20
7. Compression of subheaders................................22
7.1. IPv6 Header.......................................24
7.2. IPv6 Extension Headers............................25
7.3. Options...........................................25
7.4. Hop-by-hop Options Header.........................26
7.5. Routing Header....................................26
7.6. Fragment Header...................................27
7.7. Destination Options Header........................28
7.8. No Next Header....................................29
7.9. Authentication Header.............................29
7.10. Encapsulating Security Payload Header.............29
7.11. UDP Header........................................30
7.12. TCP Header........................................30
7.13. IPv4 Header.......................................33
7.14 Minimal Encapsulation header......................34
8. Changing context identifiers.............................35
9. Rules for dropping or temporarily storing packets........35
10. Low-loss header compression for TCP .....................36
10.1. The "twice" algorithm............................37
10.2. Header Requests..................................37
11. Links that reorder packets...............................38
11.1. Reordering in non-TCP packet streams.............39
11.2. Reordering in TCP packet streams.................39
12. Hooks for additional header compression..................40
13. Demultiplexing...........................................41
14. Configuration Parameters.................................42
15. Implementation Status....................................43
16. Acknowledgments..........................................44
17. Security Considerations..................................44
18. Authors' Addresses.......................................45
19. References...............................................46
20. Full Copyright Statement.................................47
There are several reasons to do header compression on low- or medium-speed links. Header compression can
低・中速のリンクにヘッダ圧縮を行うにはいくつかの理由があります。ヘッダ圧縮することができます
* Improve interactive response time
*インタラクティブな応答時間を改善
For very low-speed links, echoing of characters may take longer than 100-200 ms because of the time required to transmit large headers. 100-200 ms is the maximum time people can tolerate without feeling that the system is sluggish.
非常に低速リンクの場合は、文字のエコーは大きいため、ヘッダを送信するのに必要な時間よりも長い100〜200ミリ秒かかる場合があります。 100〜200ミリ秒は、人々は、システムが低迷していることを感じることなく耐えることができる最大時間です。
* Allow using small packets for bulk data with good line efficiency
*良好なライン効率のバルクデータの小さなパケットを使用して許可します
This is important when interactive (for example Telnet) and bulk traffic (for example FTP) is mixed because the bulk data should be carried in small packets to decrease the waiting time when a packet with interactive data is caught behind a bulk data packet.
ときインタラクティブこれは、（たとえば、Telnetの）重要であり、バルク・データは、インタラクティブデータのパケットが大量のデータパケットの後ろにキャッチされた待機時間を減少させるために小さなパケットで運ばれる必要があるため、大量のトラフィック（例えばFTP）が混合されます。
Using small packet sizes for the FTP traffic in this case is a global solution to a local problem. It will increase the load on the network as it has to deal with many small packets. A better solution might be to locally fragment the large packets over the slow link.
この場合、FTPトラフィックに小さなパケットサイズを使用すると、ローカルの問題に対する世界的なソリューションです。それは多くの小さなパケットに対処しているように、それはネットワークの負荷が増加します。ローカルに低速リンクで大きなパケットを断片化するためのより良い解決策があるかもしれません。
* Allow using small packets for delay sensitive low data-rate traffic
*遅延に敏感な低データレートトラフィックのための小さなパケットを使用して許可します
For such applications, for example voice, the time to fill a packet with data is significant if packets are large. To get low end-to-end delay small packets are preferred. Without header compression, the smallest possible IPv6/UDP headers (48 octets) consume 19.2 kbit/s with a packet rate of 50 packets/s. 50 packets/s is equivalent to having 20 ms worth of voice samples in each packet. IPv4/UDP headers consumes 11.2 kbit/s at 50 packets/s. Tunneling or routing headers, for example to support mobility, will increase the bandwidth consumed by headers by 10-20 kbit/s. This should be compared with the bandwidth required for the actual sound samples, for example 13 kbit/s with GSM encoding. Header compression can reduce the bandwidth needed for headers significantly, in the example to about 1.7 kbit/s. This enables higher quality voice transmission over 14.4 and 28.8 kbit/s modems.
パケットが大きい場合は、そのようなアプリケーションでは、例えば、音声のために、データをパケットを埋めるために時間が重要です。低エンドツーエンド遅延を得るために小さなパケットが好ましいです。ヘッダ圧縮せずに、可能な限り最小のIPv6 / UDPヘッダ（48オクテット）が50個のパケット/秒のパケットレートで19.2キロビット/秒を消費します。 50個のパケット/秒は、各パケット内の音声サンプル分の20ミリ秒を有することと等価です。 IPv4の/ UDPヘッダ50個のパケット/ sで11.2キロビット/秒を消費します。トンネリングやルーティングヘッダは、移動性をサポートするために、例えば、10〜20キロビット/秒によってヘッダーによって消費される帯域幅を増加させるであろう。これは、GSM符号化は、実施例13キロビット/秒のため、実際の音サンプルに必要な帯域幅と比較されるべきです。ヘッダ圧縮は、約1.7キロビット/秒の例では、かなりのヘッダーに必要な帯域幅を減らすことができます。これは、14.4と28.8キロビット/秒のモデムを介して高品質の音声伝送を可能にします。
* Decrease header overhead.
*減少ヘッダオーバーヘッド。
A common size of TCP segments for bulk transfers over medium-speed links is 512 octets today. When TCP segments are tunneled, for example because Mobile IP is used, the IPv6/IPv6/TCP header is 100 octets. Header compression will decrease the header overhead for IPv6/TCP from 19.5 per cent to less than 1 per cent, and for tunneled IPv4/TCP from 11.7 to less than 1 per cent. This is a significant gain for line-speeds as high as a few Mbit/s.
中速リンク上バルク転送のためのTCPセグメントの一般的なサイズは、今日512オクテットです。 TCPセグメントがトンネリングされている場合、モバイルIPを用いているため、例えば、IPv6の/のIPv6 / TCPヘッダは100オクテットです。ヘッダ圧縮は、11.7からパーセント未満の1パーセント19.5パーセントから1未満までのIPv6 / TCPのヘッダのオーバーヘッドを減少させ、トンネリングのIPv4 / TCPのためであろう。これは、数メガビット/秒という高いライン速度のための重要な利益です。
The IPv6 specification prescribes path MTU discovery, so with IPv6 bulk TCP transfers should use segments larger than 512 octets when possible. Still, with 1400 octet segments (RFC 894 Ethernet encapsulation allows 1500 octet payloads, of which 100 octets are used for IP headers), header compression reduces IPv6 header overhead from 7.1% to 0.4%.
IPv6のバルクTCP転送が可能なときに512オクテットよりも大きいセグメントを使用すべきとなるIPv6仕様は、経路MTU探索を規定します。依然として1400個のオクテットセグメント（RFC 894、イーサネットカプセル化は100個のオクテットはIPヘッダーのために使用される1500のオクテットペイロードを、可能にする）と、ヘッダ圧縮は、7.1％から0.4％にIPv6ヘッダのオーバーヘッドを低減します。
* Reduce packet loss rate over lossy links.
*非可逆リンク上でのパケット損失率を減らします。
Because fewer bits are sent per packet, the packet loss rate will be lower for a given bit-error rate. This results in higher throughput for TCP as the sending window can open up more between losses, and in fewer lost packets for UDP.
少ないビットがパケットごとに送信されるので、パケット損失率は、所定のビット誤り率のために低くなります。送信ウィンドウは、より損失の間、およびUDPのための少数の失われたパケットで開くことができ、これはTCPのためのより高いスループットになります。
The mechanisms described here are intended for a point-to-point link. However, care has been taken to allow extensions for multi-access links and multicast.
ここで説明するメカニズムは、ポイントツーポイントリンクのために意図されています。しかし、ケアは、マルチアクセスリンクとマルチキャスト用の拡張機能を許可するようにとられています。
Headers that can be compressed include TCP, UDP, IPv4, and IPv6 base and extension headers. For TCP packets, the mechanisms of Van Jacobson [RFC-1144] are used to recover from loss. Two additional mechanisms that increase the efficiency of VJ header compression over lossy links are also described. For non-TCP packets, compression slow-start and periodic header refreshes allow minimal periods of packet discard after loss of a header that changes the context. There are hooks for adding header compression schemes on top of UDP, for example compression of RTP headers.
圧縮できるヘッダはTCP、UDP、IPv4の、およびIPv6ベース及び拡張ヘッダを含みます。 TCPパケットの場合、バン・ジェイコブソン[RFC-1144]のメカニズムは、損失から回復するために使用されます。損失の多いリンク上VJヘッダ圧縮の効率を高める二つの追加の機構も記載されています。非TCPパケットの場合、圧縮は、スロースタート及び定期的ヘッダーリフレッシュは、コンテキストを変更ヘッダの損失後のパケット廃棄の最小期間を可能にします。 RTPヘッダの例圧縮のために、UDPの上にヘッダ圧縮方式を追加するためのフックがあります。
Header compression relies on many fields being constant or changing seldomly in consecutive packets belonging to the same packet stream. Fields that do not change between packets need not be transmitted at all. Fields that change often with small and/or predictable values, e.g., TCP sequence numbers, can be encoded incrementally so that the number of bits needed for these fields decrease significantly. Only fields that change often and randomly, e.g., checksums or authentication data, need to be transmitted in every header.
ヘッダ圧縮は、多くの分野が一定であるか、同じパケットストリームに属する連続したパケットにめったに変更に依存しています。パケットの間で変化しないフィールドは、すべてで送信する必要はありません。これらのフィールドに必要なビット数は大幅に減少するように、小さな及び/又は予測可能な値で頻繁に変更フィールドは、例えば、TCPシーケンス番号は、増分的に符号化することができます。しばしばランダムに変更するフィールドのみ、例えば、チェックサム、または認証データは、すべてのヘッダで送信される必要があります。
The general principle of header compression is to occasionally send a packet with a full header; subsequent compressed headers refer to the context established by the full header and may contain incremental changes to the context.
ヘッダ圧縮の一般的な原理は、時折、完全なヘッダを持つパケットを送信することです。後続の圧縮ヘッダはフル・ヘッダによって確立されたコンテキストを参照し、コンテキストに増分変更を含んでいてもよいです。
This header compression scheme does not require that all packets in the same stream passes over the compressed link. However, for TCP streams the difference between subsequent headers can become more irregular and the compression rate can decrease. Neither is it required that corresponding TCP data and acknowledgment packets traverse the link in opposite directions.
このヘッダ圧縮方式は、同じストリーム内のすべてのパケットが圧縮されたリンク上を通過することを必要としません。 TCPストリームのためしかし、後続ヘッダの差がより不規則になることができ、圧縮率を減少させることができます。どちらも、それは、対応するTCPデータおよび肯定応答パケットは逆方向のリンクをトラバースすることを必要としません。
This header compression scheme is useful on first-hop or last-hop links as well as links in the middle of the network. When many packet streams (several hundred) traverse the link, a phenomenon that could be called CID thrashing could occur, where headers seldom can be matched with an existing context and have to be sent uncompressed or as full headers. It is up to an implementation to use techniques such as hysteresis to ensure that the packet streams that give the highest compression rates keep their context. Such techniques are more likely to be needed in the middle of the network.
このヘッダ圧縮方式は、最初のホップまたは最終ホップリンクならびにネットワークの中央のリンク上で有用です。多くのパケットストリーム（数百）のヘッダがほとんど既存のコンテキストと一致することができないリンク、CIDスラッシングが発生する可能性があるとも言える現象を横断し、持っている場合、非圧縮またはフルヘッダーとして送信されます。これは、最高の圧縮率を与えるパケットストリームは、そのコンテキストを維持することを確実にするために、このようなヒステリシスなどの技術を使用するように実装次第です。このような技術は、ネットワークの途中で必要とされる可能性が高いです。
This section explains some terms used in this document.
このセクションでは、このドキュメントで使用されているいくつかの用語を説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
Subheader
サブヘッダ
An IPv6 base header, an IPv6 extension header, an IPv4 header, a UDP header, or a TCP header.
IPv6の基本ヘッダ、IPv6拡張ヘッダ、IPv4ヘッダ、UDPヘッダ、又はTCPヘッダ。
Header
ヘッダ
A chain of subheaders.
サブヘッダーのチェーン。
Compress
圧縮します
The act of reducing the size of a header by removing header fields or reducing the size of header fields. This is done in a way such that a decompressor can reconstruct the header if its context state is identical to the context state used when compressing the header.
ヘッダフィールドを除去またはヘッダフィールドのサイズを減少させることによって、ヘッダのサイズを縮小する行為。これは、そのコンテキスト状態がヘッダを圧縮する際に使用されるコンテキスト状態と同一であれば解凍器がヘッダを再構築することができるような方法で行われます。
Decompress
減圧します
The act of reconstructing a compressed header.
圧縮されたヘッダを再構築する行為。
Context identifier (CID)
コンテクスト識別子（CID）
A small unique number identifying the context that should be used to decompress a compressed header. Carried in full headers and compressed headers.
圧縮されたヘッダを解凍するために使用されるべきコンテキストを識別する小さな一意の番号。フルヘッダーおよび圧縮ヘッダで運ばれます。
Context
状況
The state which the compressor uses to compress a header and the decompressor uses to decompress a header. The context is the uncompressed version of the last header sent (compressor) or received (decompressor) over the link, except for fields in the header that are included "as-is" in compressed headers or can be inferred from, e.g., the size of the link-level frame.
圧縮器がヘッダを圧縮するために使用し、解凍器がヘッダを解凍するために使用する。状態コンテキストは、圧縮されたヘッダに「そのまま」または、例えば、大きさから推測することができる含まれているヘッダ内のフィールドを除いて、リンクを介して送信された最後のヘッダの圧縮されていないバージョン（圧縮機）または受信（減圧装置）でありますリンクレベルのフレームの。
The context for a packet stream is associated with a context identifier. The context for non-TCP packet streams is also associated with a generation.
パケット・ストリームのためのコンテキストはコンテキスト識別子に関連付けられます。非TCPパケットストリームの文脈も発生と関連しています。
Generation
世代
For non-TCP packet streams, each new version of the context for a given CID is associated with a generation: a small number that is incremented whenever the context associated with that CID changes. Carried by full and compressed non-TCP headers.
コンテキストは、そのCIDの変化に関連するたびにインクリメントされる少数の非TCPパケットストリームに対して、所与のCIDのためのコンテキストのそれぞれの新しいバージョンは、世代に関連しています。完全かつ圧縮された非TCPヘッダによって運ばれます。
Packet stream
パケットストリーム
A sequence of packets whose headers are similar and share context. For example, headers in a TCP packet stream have the same source and final destination address, and the same port numbers in the TCP header. Similarly, headers in a UDP packet stream have the same source and destination address, and the same port numbers in the UDP header.
ヘッダ類似しており、コンテキストを共有するパケットのシーケンス。例えば、TCPパケットストリームのヘッダーは、同じソース、最終宛先アドレス、及びTCPヘッダ内の同じポート番号を有します。同様に、UDPパケットストリームのヘッダーは、同じ送信元および宛先アドレス、及びUDPヘッダ内の同じポート番号を有します。
Full header (header refresh)
フルヘッダー（ヘッダーリフレッシュ）
An uncompressed header that updates or refreshes the context for a packet stream. It carries a CID that will be used to identify the context.
パケット・ストリームのためのコンテキストを更新またはリフレッシュし、非圧縮ヘッダ。これは、コンテキストを識別するために使用されるCIDを運びます。
Full headers for non-TCP packet streams also carry the generation of the context they update or refresh.
非TCPパケットストリームのための完全なヘッダはまた、彼らは更新またはリフレッシュコンテキストの生成を運びます。
Regular header
定期的なヘッダ
A normal, uncompressed, header. Does not carry CID or generation association.
通常、非圧縮、ヘッダ。 CIDや発電関連を運びません。
Incorrect decompression
誤った解凍
When a compressed and then decompressed header is different from the uncompressed header. Usually due to mismatching context between the compressor and decompressor or bit errors during transmission of the compressed header.
次いで、圧縮されたときに解凍ヘッダが圧縮されていないヘッダとは異なります。通常による圧縮ヘッダの送信の間コンプレッサ及びデコンプレッサまたはビットエラーとの間の不整合に関連します。
Differential coding
差分符号化
A compression technique where the compressed value of a header field is the difference between the current value of the field and the value of the same field in the previous header belonging to the same packet stream. A decompressor can thus obtain the value of the field by adding the value in the compressed header to its context. This technique is used for TCP streams but not for non-TCP streams.
ヘッダフィールドの圧縮された値は、フィールドの現在の値と同一のパケットストリームに属する前のヘッダ内の同じフィールドの値との差である圧縮技術。減圧装置は、このように、そのコンテキストに圧縮されたヘッダの値を加算することにより、フィールドの値を取得することができます。この手法は、TCPストリームのためではなく、非TCPストリームのために使用されています。
Much of the header information stays the same over the life-time of a packet stream. For non-TCP packet streams almost all fields of the headers are constant. For TCP many fields are constant and others change with small and predictable values.
ヘッダ情報の多くは、パケットストリームの寿命にわたり同じまま。非TCPパケットのヘッダーのほぼすべてのフィールドが一定であるストリーム。 TCPのために多くの分野では一定であり、他のものは小さく、予測可能な値で変化します。
To initiate compression of the headers of a packet stream, a full header carrying a context identifier, CID, is transmitted over the link. The compressor and decompressor store most fields of this full header as context. The context consists of the fields of the header whose values are constant and thus need not be sent over the link at all, or change little between consecutive headers so that it uses fewer bits to send the difference from the previous value compared to sending the absolute value.
パケットストリームのヘッダの圧縮を開始するために、コンテキスト識別子、CIDを運ぶフルヘッダーは、リンクを介して送信されます。コンプレッサとデコンプレッサストアコンテキストとしてこの完全なヘッダのほとんどのフィールド。コンテキストの値に一定であり、したがって、すべてのリンクを介して送信される必要はない、またはそれが絶対の送信に比べ前回値との差を送信するより少ないビットを使用するように、連続するヘッダ間ほとんど変化ヘッダのフィールドで構成さ値。
Any change in fields that are expected to be constant in a packet stream will cause the compressor to send a full header again to update the context at the decompressor. As long as the context is the same at compressor and decompressor, headers can be decompressed to be exactly as they were before compression. However, if a full header or compressed header is lost during transmission, the context of the decompressor may become obsolete as it is not updated properly. Compressed headers will then be decompressed incorrectly.
パケットストリーム内で一定であることが期待される分野での任意の変化は、減圧装置でコンテキストを更新するために、再びフル・ヘッダを送信するために圧縮機を引き起こすであろう。限りコンテキストが圧縮器と伸張器において同じであるように、ヘッダは、それらが圧縮前たとおりになるように減圧することができます。フルヘッダー又は圧縮ヘッダが送信中に失われた場合、それは適切に更新されないようしかし、逆圧縮器のコンテキストは陳腐化してもよいです。圧縮ヘッダは、間違って解凍されます。
IPv6 is not meant to be used over links that can deliver a significant fraction of damaged packets to the IPv6 module. This means that links must have a very low bit-error rate or that link-level frames must be protected by strong checksums, forward error correction or something of that nature. Header compression SHOULD not be used for IPv4 without strong link-level checksums. Damaged frames will thus be discarded by the link layer. The link layer implementation might indicate to the header compression module that a frame was damaged, but it cannot say what packet stream it belonged to as it might be the CID that is damaged. Moreover, frames may disappear without the link layer implementation's knowledge, for example if the link is a multi-hop link where frames can be dropped due to congestion at each hop. The kind of link errors that a header compression module should deal with and protect against will thus be packet loss.
IPv6がIPv6モジュールに破損したパケットのかなりの部分を提供することができ、リンク上で使用されるものではありません。これは、リンクが非常に低いビット誤り率を持たなければならないか、そのリンクレベルのフレームは、強力なチェックサム、前方誤り訂正またはその自然の何かによって保護されなければならないことを意味しています。ヘッダ圧縮は、強力なリンクレベルのチェックサムなしでIPv4のために使用すべきではありません。破損したフレームは、このように、リンク層によって破棄されます。リンクレイヤの実装では、フレームが破損していたヘッダ圧縮モジュールを示している可能性がありますが、それは、それが破損しているCIDであるかもしれないとして、それが何に属し、パケットストリームと言うことはできません。リンクは、フレームが各ホップで輻輳が原因でドロップすることができ、マルチホップリンクがある場合また、フレームは、例えば、リンクレイヤ実装の知識なしに消えることがあります。ヘッダ圧縮モジュールは、反対に対処し、保護しなければならないリンクエラーの種類は、したがって、パケット損失となります。
So a header compression scheme needs mechanisms to update the context at the decompressor and to detect or avoid incorrect decompression. These mechanisms are very different for TCP and non-TCP streams, and are described in sections 3.2 and 3.3.
そうヘッダ圧縮方式は、減圧装置でコンテキストを更新すると、誤った減圧を検出または回避するメカニズムが必要です。これらのメカニズムは、TCPおよび非TCPストリームのために非常に異なっており、セクション3.2および3.3に記載されています。
The compression mechanisms in this document assume that packets are not reordered between the compressor and decompressor. If the link
この文書の圧縮機構は、パケットは、コンプレッサとデコンプレッサとの間の並べ替えされていないと仮定する。リンクする場合
does reorder, section 11 describes mechanisms for ordering the packets before decompression. It is also assumed that the link-layer implementation can provide the length of packets, and that there is no padding in UDP packets or tunneled packets.
並べ替えず、セクション11は、解凍する前に、パケットを注文するためのメカニズムを説明しています。また、リンク層の実装は、パケットの長さを提供し、UDPパケットまたはトンネルパケットにはパディングが存在しないことをできることが想定されます。
This compression method uses four packet types in addition to the IPv4 and IPv6 packet types. The combination of link-level packet type and the value of the first four bits of the packet uniquely determines the packet type. Details on how these packet types are represented are in section 13.
この圧縮方法は、IPv4とIPv6パケットタイプに加えて、4つのパケットタイプを使用します。リンクレベルのパケットタイプとパケットの最初の4ビットの値の組み合わせが一意にパケットタイプを決定します。これらのパケットタイプが表現されている方法についての詳細は、セクション13です。
FULL_HEADER - indicates a packet with an uncompressed header,
including a CID and, if not a TCP packet, a generation. It
establishes or refreshes the context for the packet stream
identified by the CID.
COMPRESSED_NON_TCP - indicates a non-TCP packet with a compressed header. The compressed header consists of a CID identifying what context to use for decompression, a generation to detect an inconsistent context and the randomly changing fields of the header.
COMPRESSED_NON_TCPは、 - 圧縮されたヘッダを有する非TCPパケットを示しています。圧縮されたヘッダが解凍に使用するものコンテキスト識別するCID、矛盾コンテキストヘッダのランダムに変化するフィールドを検出する世代で構成されています。
COMPRESSED_TCP - indicates a packet with a compressed TCP header, containing a CID, a flag octet indentifying what fields have changed, and the changed fields encoded as the difference from the previous value.
COMPRESSED_TCPは - CID、フィールドが変更されたものindentifyingフラグオクテット、および前回値との差分としてエンコード変更されたフィールドを含む、圧縮されたTCPヘッダを有するパケットを示しています。
COMPRESSED_TCP_NODELTA - indicates a packet with a compressed TCP header where all fields that are normally sent as the difference to the previous value are instead sent as-is. This packet type is only sent as the response to a header request from the decompressor. It must not be sent as the result of a retransmission.
COMPRESSED_TCP_NODELTA - はそのまま通常前回値との差分として送信されるすべてのフィールドが代わりに送信される圧縮されたTCPヘッダを有するパケットを示しています。このパケットタイプのみ解凍器からヘッダ要求に対する応答として送信されます。これは、再送信の結果として送信されてはなりません。
In addition to the packet types used for compression, regular IPv4 and IPv6 packets are used whenever a compressor decides to not compress a packet. An additional packet type may be used to speed up repair of TCP streams over links where the decompressor can send packets to the compressor.
圧縮のために使用されるパケットタイプに加えて、定期的なIPv4およびIPv6パケットは、圧縮機がパケットを圧縮しないことを決定するたびに使用されます。付加的なパケットタイプは、TCPの修復が解凍器は、圧縮機にパケットを送信することができるリンクを介してストリームをスピードアップするために使用することができます。
CONTEXT_STATE - indicates a special packet sent from the
decompressor to the compressor to communicate a list of (TCP)
CIDs for which synchronization has been lost. This packet is only
sent over a single link so it requires no IP header. The format
is shown in section 10.2.
Since TCP headers are compressed using the difference from the previous TCP header, loss of a packet with a compressed or full header will cause subsequent compressed headers to be decompressed incorrectly because the context used for decompression was not incremented properly.
TCPヘッダが以前TCPヘッダの差分を用いて圧縮されるので、圧縮またはフル・ヘッダを持つパケットの損失は、減圧のために使用されるコンテキストが適切にインクリメントされなかったため、その後の圧縮ヘッダが正しく解凍されます。
Loss of a compressed TCP header will cause the TCP sequence numbers of subsequently decompressed TCP headers to be off by k, where k is the size of the lost segment. Such incorrectly decompressed TCP headers will be discarded by the TCP receiver as the TCP checksum reliably catches "off-by-k" errors in the sequence numbers for plausible k.
圧縮されたTCPヘッダの損失は、その後減圧TCPヘッダのTCPシーケンス番号は、kは、失われたセグメントのサイズであるKによってオフになります。 TCPチェックサムが確実に妥当kのシーケンス番号中の「オフ・バイ・K」エラーをキャッチような誤っ解凍TCPヘッダは、TCPレシーバによって廃棄されるであろう。
TCP's repair mechanisms will eventually retransmit the discarded segment and the compressor peeks into the TCP headers to detect when TCP retransmits. When this happens, the compressor sends a full header on the assumption that the retransmission was due to mismatching compression state at the decompressor. [RFC-1144] has a good explanation of this mechanism.
TCPの修復メカニズムは、最終的にTCPは再送時を検出するためにTCPヘッダーに廃棄セグメントと圧縮機覗き見を再送します。このとき、圧縮機は、再送がデコンプレッサで圧縮状態を不整合に起因したと仮定して、完全なヘッダを送信します。 [RFC-1144]は、このメカニズムの良い説明があります。
The mechanisms of section 10 should be used to speed up the repair of the context. This is important over medium speed links with high packet loss rates, for example wireless. Losing a timeout's worth of packets due to inconsistent context after each packet lost over the link is not acceptable, especially when the TCP connection is over the wide area.
セクション10のメカニズムは、コンテキストの修復をスピードアップするために使用されるべきです。これは、例えばワイヤレスのため、高いパケット損失率と中速リンクで重要です。リンクの上に失われた各パケットの後により一貫性のないコンテキストへのパケットのタイムアウトの価値を失うことは、TCP接続が広い領域の上にある場合は特に、受け入れられません。
Incorrectly decompressed headers of UDP packets and other non-TCP packets are not so well-protected by checksums as TCP packets. There are no sequence numbers that become "off-by-k" and virtually guarantees a failed checksum as there are for TCP. The UDP checksum only covers payload, UDP header, and pseudo header. The pseudo header includes the source and destination addresses, the transport protocol type and the length of the transport packet. Except for those fields, large parts of the IPv6 header are not covered by the UDP checksum. Moreover, other non-TCP headers lack checksums altogether, for example fragments.
UDPパケットおよび他の非TCPパケットの誤っ解凍ヘッダはそのTCPパケットなどのチェックサムで十分に保護されていません。 「オフ・バイ・K」になり、TCPのためにそこにあるとして、事実上失敗したチェックサムを保証なしシーケンス番号はありません。 UDPチェックサムはペイロードのみ、UDPヘッダ、及び疑似ヘッダを覆います。疑似ヘッダは、送信元アドレス、宛先アドレス、トランスポート・プロトコル・タイプとトランスポート・パケットの長さを含みます。これらのフィールドを除いて、IPv6ヘッダーの大部分は、UDPチェックサムによってカバーされていません。また、他の非TCPヘッダには、例えば、フラグメントのために、完全にチェックサムを欠いています。
In order to safely avoid incorrect decompression of non-TCP headers, each version of the context for non-TCP packet streams is identified by a generation, a small number that is carried by the full headers that establish and refresh the context. Compressed headers carry the generation value of the context that were used to compress them. When a decompressor sees that a compressed header carries a generation value other than the generation of its context for that packet stream, the context is not up to date and the packet must be discarded or stored until a full header establishes correct context.
安全に非TCPヘッダの不正確な解凍を避けるために、非TCPパケットストリームのためのコンテキストの各バージョンは、世代、確立し、コンテキストを更新し、完全なヘッダによって運ばれる小さな番号で識別されます。圧縮されたヘッダは、それらを圧縮するために使用されたコンテキストの生成値を運びます。解凍装置は、圧縮ヘッダはそのパケットストリームのためのコンテキストの世代以外の世代の値を搬送することを確認すると、コンテキストは最新ではなく、パケットは廃棄されるか、または完全なヘッダが正しいコンテキストを確立するまで保存しなければなりません。
Differential coding is not used for non-TCP streams, so compressed non-TCP headers do not change the context. Thus, loss of a compressed header does not invalidate subsequent packets with compressed headers. Moreover, the generation changes only when the context of a full header is different from the context of the previous full header. This means that losing a full header will make the context of the decompressor obsolete only when the full header would actually have changed the context.
差分符号化は、非TCPストリームのために使用されていないので、圧縮された非TCPヘッダには、コンテキストを変更しないでください。したがって、圧縮されたヘッダの損失は、圧縮ヘッダを持つ後続パケットを無効にしません。完全なヘッダのコンテキストは、以前のフルヘッダーのコンテキストと異なる場合にのみ、また、生成が変化します。これは、完全なヘッダを失うことは、完全なヘッダーが実際にコンテキストを変更していた場合にのみ、デコンプレッサのコンテキストが陳腐化することを意味します。
The generation field is 6 bits long so the generation value repeats itself after 64 changes to the context. To avoid incorrect decompression after error bursts or other temporary disruptions, the compressor must not reuse the same generation value after a shorter time than MIN_WRAP seconds. A decompressor which has been disconnected MIN_WRAP seconds or more must wait for the next full header before decompressing. A compressor must wait at least MIN_WRAP seconds after booting before compressing non-TCP headers. Instead of reusing a generation value too soon, a compressor may switch to another CID or send regular headers until MIN_WRAP seconds have passed. The value of MIN_WRAP is found in section 14.
世代フィールドは6ビット長で生成値はコンテキスト64回の変更後に繰り返されるようです。エラーバーストまたは他の一時的な混乱の後に間違った解凍を避けるために、コンプレッサーはMIN_WRAP秒よりも短い時間後に同世代値を再利用してはなりません。 MIN_WRAP秒以上を切断されたデコンプレッサは、解凍する前に次の完全なヘッダーを待つ必要があります。コンプレッサーは、非TCPヘッダを圧縮する前に起動した後、少なくともMIN_WRAP秒を待たなければなりません。代わりに、早すぎる世代値を再利用するのは、圧縮機は、別のCIDに切り替えたりMIN_WRAP秒が経過するまで定期的にヘッダを送信することができます。 MIN_WRAPの値は、セクション14に見出されます。
To allow the decompressor to recover quickly from loss of a full header that would have changed the context, full headers are sent periodically with an exponentially increasing period after a change in the context. This technique avoids an exchange of messages between compressor and decompressor used by other compression schemes, such as in [RFC-1553]. Such exchanges can be costly for wireless mobiles as more power is consumed by the transmitter and delay can be introduced by switching between sending and receiving. Moreover, techniques that require an exchange of messages cannot be used over simplex links, such as direct-broadcast satellite channels or cable TV systems, and are hard to adapt to multicast over multi-access links.
解凍器がコンテキストを変更したであろう完全なヘッダの損失から迅速に回復できるように、フルヘッダーは、コンテキストの変更後、指数関数的に増加する周期で定期的に送信されます。この技術は、[RFC-1553]のような他の圧縮スキームで使用されるコンプレッサとデコンプレッサとの間のメッセージの交換を回避します。より多くの電力が送信機によって消費され、遅延は送信側と受信側との間で切り替えることにより導入することができるように、そのような交換は、無線携帯電話のために高価であることができます。また、メッセージの交換を必要とする技術は、放送衛星チャンネルやケーブルテレビシステムなどの単純リンク上で使用され、マルチアクセスリンク上でマルチキャストに適応するのは難しいですすることはできません。
|.|..|....|........|................|..............................
^
Change Sent packets: | with full header, . with compressed header
The picture shows how packets are sent after change. The compressor keeps a variable for each non-TCP packet stream, F_PERIOD, that keeps track of how many compressed headers may be sent between full headers. When the headers of a non-TCP packet stream change so that its context changes, a full header is sent and F_PERIOD is set to one. After sending F_PERIOD compressed headers, a full header is sent. F_PERIOD is doubled each time a full header is sent during compression slow-start.
絵は、パケットが変更後に送信されている方法を示しています。圧縮機は、完全なヘッダーの間で送信することができるどのように多くの圧縮ヘッダを追跡する各非TCPパケットストリーム、F_PERIOD用変数を保持します。そのコンテキストが変化するようにするとき、非TCPパケットストリームの変化のヘッダは、完全なヘッダが送信され、F_PERIODは1にセットされます。 F_PERIOD圧縮されたヘッダを送信した後、完全なヘッダが送信されます。 F_PERIODフルヘッダーが圧縮スロースタート中に送信されるたびに倍になります。
To avoid losing too many packets if a receiver has lost its context, there is an upper limit, F_MAX_PERIOD, on the number of non-TCP packets with compressed headers that may be sent between header refreshes. If a packet is to be sent and F_MAX_PERIOD compressed headers have been sent since the last full header for this packet stream was sent, a full header must be sent.
受信機は、そのコンテキストを失った場合、あまりにも多くのパケットが失われないようにするには、ヘッダー・リフレッシュの間で送信されることができる圧縮ヘッダを有する非TCPパケットの数の上限、F_MAX_PERIODがあります。パケットが送信されるとF_MAX_PERIOD圧縮ヘッダが送られた場合、このパケットストリームの最後の完全なヘッダが送信されたため、完全なヘッダが送信されなければなりません。
To avoid long periods of disconnection for low data rate packet streams, there is also an upper bound, F_MAX_TIME, on the time between full headers in a non-TCP packet stream. If a packet is to be sent and more than F_MAX_TIME seconds have passed since the last full header was sent for this packet stream, a full header must be sent. The values of F_MAX_PERIOD and F_MAX_TIME are found in section 14.
低データ・レート・パケット・ストリームのための切断の長い期間を避けるために、非TCPパケットストリームでフルヘッダーとの間の時間に、F_MAX_TIME、上限があります。最後のフルヘッダはこのパケットストリームのために送られたため、パケットが送信されると、よりF_MAX_TIME秒が経過している場合は、完全なヘッダを送信する必要があります。 F_MAX_PERIODとF_MAX_TIMEの値は、セクション14に見出されます。
The following pseudo code can be used by the compressor to determine when to send a full header for a non-TCP packet stream. The code maintains two variables:
以下の擬似コードは、非TCPパケットストリームに対するフルヘッダーを送信するタイミングを決定するために、コンプレッサにより使用することができます。コードは、2つの変数を保持しています。
C_NUM -- a count of the number of compressed headers sent
since the last full header was sent.
F_LAST -- the time of sending the last full header.
and uses the functions
そして、関数を使用しています
current_time() return the current time
min(a,b) return the smallest of a and b
the procedures send_full_header(), increment_generation_value(), and send_compressed_header() do the obvious thing.
手続きsend_full_header（）、increment_generation_value（）、およびsend_compressed_headerは（）明白なことを行います。
if ( <this header changes the context> )
（<このヘッダは、コンテキストを変更>）場合
C_NUM := 0;
F_LAST := current_time();
F_PERIOD := 1;
increment_generation_value();
send_full_header();
elseif ( C_NUM >= F_PERIOD )
ELSEIF（C_NUM> = F_PERIOD）
C_NUM := 0;
F_LAST := current_time();
F_PERIOD := min(2 * F_PERIOD, F_MAX_PERIOD);
send_full_header();
elseif ( current_time() > F_LAST + F_MAX_TIME )
ELSEIF（CURRENT_TIME（）> F_LAST + F_MAX_TIME）
C_NUM := 0;
F_LAST := current_time();
send_full_header();
else
他
C_NUM := C_NUM + 1
send_compressed_header();
endif
ENDIF
If every f'th packet carries a full header, H is the size of a full header, and C is the size of a compressed header, the average header size is
すべてのF番目のパケットがフル・ヘッダを搬送する場合、Hフルヘッダーの大きさであり、Cは、圧縮ヘッダのサイズであり、平均ヘッダサイズであります
(H-C)/f + C
（H-C）/ F + C
For f > 1, the average header size is (H-C)/f larger than a compressed header.
F> 1の場合、平均ヘッダサイズは/圧縮ヘッダより大きいF（H-C）です。
In a diagram where the average header size is plotted for various f values, there is a distinct knee in the curve, i.e., there is a limit beyond which further increasing f gives diminishing returns. F_MAX_PERIOD should be chosen to be a frequency well to the right of the knee of the curve. For typical sizes of H and C, say 48 octets for the full header (IPv6/UDP) and 4 octets for the compressed header, setting F_MAX_PERIOD > 44 means that full headers will contribute less than an octet to the average header size. With a four-address routing header, F_MAX_PERIOD > 115 will have the same effect.
平均ヘッダーサイズは、種々のF値に対してプロットされた図では、曲線の明確な膝がある、すなわち、さらに増加fは収穫逓減与える超えて限界があります。 F_MAX_PERIOD周波数ウェルに曲線の膝の右側になるように選択されるべきです。 H及びCの典型的なサイズに対して、F_MAX_PERIOD> 44がフルヘッダーが平均ヘッダーサイズのオクテット未満寄与することを意味設定、フルヘッダー（IPv6の/ UDP）、圧縮ヘッダの4つのオクテット48個のオクテットを言います。四アドレスルーティングヘッダで、> 115 F_MAX_PERIODは同じ効果を有するであろう。
The default F_MAX_PERIOD value of 256 (section 14) puts the full header frequency well to the right of the knee and means that full headers will typically contribute considerably less than an octet to the average header size. For H = 48 and C = 4, full headers contribute about 1.4 bits to the average header size after reaching the steady-state header refresh frequency determined by the default
256（セクション14）のデフォルトF_MAX_PERIOD値は、膝の右側によくフルヘッダー周波数を置き、完全なヘッダーは、典型的には、平均ヘッダーサイズのオクテットよりもかなり少なく寄与することを意味します。 H = 48及びC = 4のために、完全なヘッダは、デフォルトで決定定常ヘッダリフレッシュ周波数に到達した後、平均ヘッダサイズは約1.4ビットに寄与します
F_MAX_PERIOD. 1.4 bits is a very small overhead.
F_MAX_PERIOD。 1.4ビットが非常に小さいオーバーヘッドです。
After a change in the context, the exponential backoff scheme will initially send full headers frequently. The default F_MAX_PERIOD will be reached after nine full headers and 255 compressed headers have been sent. This is equivalent to a little over 5 seconds for a typical voice stream with 20 ms worth of voice samples per packet.
状況が変化した後、指数バックオフスキームは、最初は頻繁に完全なヘッダーを送信します。デフォルトのF_MAX_PERIODは9つのフルヘッダーの後に到達され、255個の圧縮ヘッダが送られてきました。これは、パケットごとの音声サンプルの価値は20ミリ秒で、典型的な音声ストリームのために少し5秒以上に相当します。
During the whole backoff period, full headers contribute 1.5 octets to the average header size when H = 48 and C = 4. For 20 ms voice samples, it takes less than 1.3 seconds until full headers contribute less than one octet to the average header size, and during these initial 1.3 seconds full headers add less than 4 octets to the average header size. The cost of the exponential backoff is not great and as the headers of non-TCP packet streams are expected to change seldomly, it will be amortized over a long time.
全体のバックオフ期間中に、完全なヘッダHは48と20ミリ秒の音声サンプルのCは= 4. =ときにフルヘッダーが平均ヘッダーサイズ未満1つのオクテットに寄与するまで、それが1.3未満秒かかる平均ヘッダーサイズに1.5オクテットに寄与します、およびこれらの初期1.3秒の間に完全なヘッダは平均ヘッダーサイズ未満4つのオクテットを追加します。指数バックオフのコストは大きなものではなく、非TCPパケットストリームはめったに変化することが予想されているのヘッダーとして、それは長い時間をかけて償却されます。
The cost of header refreshes in terms of bandwidth are higher than similar costs for hard state schemes like [RFC-1553] where full headers must be acknowledged by the decompressor before compressed headers may be sent. Such schemes typically send one full header plus a few control messages when the context changes. Hard state schemes require more types of protocol messages and an exchange of messages is necessary. Hard state schemes also need to deal explicitly with various error conditions that soft state handles automatically, for instance the case of one party disappearing unexpectedly, a common situation on wireless links where mobiles may go out of range of the base station.
ヘッダのコストは、帯域幅の点でリフレッシュ[RFC-1553]圧縮ヘッダを送信することができる前に、完全なヘッダが解凍装置によって承認されなければならないようなハードステート方式のために同様のコストよりも高いです。そのようなスキームは、典型的には、1つのフルヘッダーとコンテキストが変化するいくつかの制御メッセージを送信します。ハードステート方式は、プロトコルメッセージのより多くの種類を必要とし、メッセージの交換が必要です。ハードステート方式もインスタンスのソフトの状態を自動的に処理するさまざまなエラー状態、予想外に消える一方の当事者の場合、携帯電話が基地局の範囲外に行くかもしれ無線リンク上の一般的な状況で明示的に対処する必要があります。
The major advantage of the soft state scheme is that no handshakes are needed between compressor and decompressor, so the scheme can be used over simplex links. The costs in terms of bandwidth are higher than for hard state schemes, but the simplicity of the decompressor, the simplicity of the protocol, and the lack of handshakes between compressor and decompressor justifies this small cost. Moreover, soft state schemes are more easily extended to multicast over multi-access links, for example radio links.
ソフトステート手法の主な利点は、握手がコンプレッサーと減圧器との間で必要とされていないということなので、スキームは、シンプレックスリンク上で使用することができます。帯域幅の面でコストが硬い状態スキームよりも高いですが、解凍器の簡素化、プロトコルのシンプルさ、とコンプレッサとデコンプレッサとの握手の欠如は、この小さなコストを正当化します。また、ソフトステート方式は、より容易に、例えば無線リンクのために、マルチアクセスリンクを介してマルチキャストするように拡張されています。
This section explains how packets MAY be grouped together into packet streams for compression. To achieve the best compression rates, packets SHOULD be grouped together such that packets in the same packet stream have similar headers. If this grouping fails, header compression performance will be bad, since the compression algorithm can rarely utilize the existing context for the packet stream and full headers must be sent frequently.
このセクションでは、パケットが圧縮のためのパケットストリームにグループ化する方法を説明します。最高の圧縮率を達成するために、パケットは、同じパケットストリームのパケットが同様のヘッダを持っているように一緒にグループ化する必要があります。このグループ化が失敗した場合の圧縮アルゴリズムはめったにパケットストリームのための既存のコンテキストを利用することはできませんし、完全なヘッダが頻繁に送らなければならないため、ヘッダ圧縮性能は、悪いなります。
Grouping is done by the compressor. A compressor may use whatever criterion it finds appropriate to group packets into packet streams. To determine what packet stream a packet belongs to, a compressor MAY
グループ化は、圧縮機によって行われます。コンプレッサは、パケット・ストリームにグループパケットに適当と認めるどんな基準を使用してもよいです。パケットが属するどのようなパケットストリームを決定するために、コンプレッサーはMAY
a) examine the compressible chain of subheaders (see section 7),
A）（セクション7参照）サブヘッダの圧縮チェーンを調べ、
b) examine the contents of an upper layer protocol header that follows the compressible chain of subheaders, for example ICMP headers, DVMRP headers, or tunneled IPX headers,
b）は、例えばICMPヘッダ、DVMRPヘッダー、またはトンネリングIPXヘッダーのため、サブヘッダの圧縮チェーンを次の上位層プロトコルのヘッダの内容を調べます
c) use information obtained from a resource manager, for example if a resource manager requests compression for a particular packet stream and provides a way to identify packets belonging to that packet stream,
リソースマネージャは、特定のパケットストリームの圧縮を要求し、そのパケットストリームに属するパケットを識別するための方法を提供する場合、C）、例えば、リソースマネージャから取得した情報を使用
d) use any other relevant information, for example if routes flap and the hop limit (TTL) field in a packet stream changes frequently between n and n+k, a compressor may choose to group the packets into two different packet streams.
頻繁Nとn + kとのパケットストリームの変更にルートフラップとホップリミット（TTL）フィールド場合D）は、例えば、任意の他の関連情報を使用し、圧縮機は、二つの異なるパケットストリームにグループ化するパケットを選択することができます。
A compressor is also free not to group packets into packet streams for compression, letting some packets keep their regular headers and passing them through unmodified.
コンプレッサーは、いくつかのパケットが、正規のヘッダを維持させると無修正を通すこと、圧縮のためのパケットストリームにグループパケットにないも自由です。
As long as the rules for when to send full headers for a non-TCP packet stream are followed and subheaders are compressed as specified in this document, the decompressor is able to reconstruct a compressed header correctly regardless of how packets are grouped into packet streams.
この文書で指定されている限り、非TCPパケットストリームのフルヘッダーを送信する場合のルールに従っているとサブヘッダが圧縮されるように、解凍装置は正しくかかわらず、パケットはパケットストリームにグループ化する方法の圧縮ヘッダを再構築することが可能です。
In this section we give OPTIONAL guidelines for how a compressor may group packets into packet streams for compression.
このセクションでは、どのように、コンプレッサかもしれグループパケット圧縮のためのパケットストリームにのためのオプションのガイドラインを与えます。
Defining fields
定義フィールド
The defining fields of a header should be present and identical in all packets belonging to the same packet stream. These fields are marked DEF in section 7. The defining fields include the flow label, source and destination addresses of IP headers, final destination address in routing headers, the next header fields (for IPv6), the protocol field (IPv4), port numbers (UDP and TCP), and the SPI in authentication and encryption headers.
ヘッダの定義フィールドは、同一のパケットストリームに属するすべてのパケットに存在し、同一であるべきです。これらのフィールドは、定義フィールドは、IPヘッダ、ルーティングヘッダの最終宛先アドレスのフローラベル、送信元アドレスと宛先アドレスを含むセクション7のDEFをマークされている、（IPv6の場合）、次ヘッダフィールド、プロトコルフィールド（IPv4）の、ポート番号（UDPおよびTCP）、および認証と暗号化ヘッダのSPI。
Fragmented packets
断片化されたパケット
Fragmented and unfragmented packets should never be grouped together in the same packet stream. The Identification field of the Fragment header or IPv4 header should not be used to identify the packet stream. If it was, the first fragment of a new packet would cause a compression slow-start.
断片化し、断片化されていないパケットは、同じパケットストリームにまとめてはいけません。フラグメントヘッダまたはIPv4ヘッダーの識別フィールドは、パケットストリームを識別するために使用すべきではありません。それがあった場合は、新しいパケットの最初のフラグメントは、圧縮スロースタートを引き起こします。
No field after a Fragment Header, or an IPv4 header for a fragment, should be used for grouping purposes.
フラグメントヘッダの後にはフィールド、またはその断片のIPv4ヘッダは、グループ化の目的のために使用されるべきではありません。
Upper protocol identification
上位プロトコル識別
The first next header field identifying a header not described in section 7 should be used for identifying packet streams, i.e., all packets with the same DEF fields and the same upper protocol should be grouped together.
セクション7に記載されていないヘッダを識別する第1次ヘッダフィールド、すなわち、同じDEFフィールドと同じ上位プロトコルを持つすべてのパケットが一緒にグループ化されるべき、パケットストリームを識別するために使用されるべきです。
TTL field (Hop Limit field)
TTLフィールド（ホップリミットフィールド）
A sophisticated implementation might monitor the TTL (Hop Limit) field and if it changes frequently use it as a DEF field. This can occur when there are frequent route flaps so that packets traverse different paths through the internet.
洗練された実装は、TTL（ホップリミット）フィールドを監視し、それが変化した場合、頻繁DEFフィールドとしてそれを使用する場合があります。これは、パケットがインターネットを介して異なるパスを横断するように頻繁なルートフラップが存在する場合に発生することができます。
Traffic Class field (IPv6), Type of Service field (IPv4)
トラフィッククラスフィールド（IPv6）のサービス分野の、タイプ（IPv4）の
It is possible that the Traffic Class field of the IPv6 header and the Type of Service of the IPv4 header will change frequently between packets with otherwise identical DEF fields. A sophisticated implementation should watch out for this and be prepared to use these fields as defining fields.
IPv6ヘッダーのトラフィッククラスフィールドとIPv4ヘッダのサービスの種類は、他の点では同じDEF分野でのパケットの間で頻繁に変更される可能性があります。洗練された実装は、このために気をつけなければならないと定義するフィールドとしてこれらのフィールドを使用して調製すること。
When IP packets are tunneled they are encapsulated with an additional IP header at the tunnel entry point and then sent to the tunnel endpoint. To group such packets into packet streams, the inner headers should also be examined to determine the packet stream. If this is not done, full headers will be sent each time the headers of the inner IP packet changes. So when a packet is tunneled, the identifying fields of the inner subheaders should be considered in addition to the identifying fields of the initial IP header.
IPパケットがトンネリングされる場合、それらは、トンネルエントリポイントに追加のIPヘッダでカプセル化した後、トンネルエンドポイントに送信されます。パケットストリームにグループようなパケットに、内部ヘッダは、パケットのストリームを決定するために検討すべきです。これを行わない場合、完全なヘッダはたびに、内部IPパケットの変更のヘッダが送信されます。パケットがトンネリングされるときに、内側サブヘッダの識別フィールドは、最初のIPヘッダの識別フィールドに加えて考慮すべきです。
An implementation can use other fields for identification than the ones described here. If too many fields are used for identification, performance might suffer because more CIDs will be used and the wrong CIDs might be reused when new flows need CIDs. If too few fields are used for identification, performance might suffer because there are too frequent changes to the context.
実装は、ここで説明するものより識別のための他のフィールドを使用することができます。あまりにも多くのフィールドを識別するために使用されている場合はより多くのCIDが使用され、新しいフローがCIDを必要とするとき、間違ったのCIDが再利用される可能性があるため、パフォーマンスが低下する可能性があります。あまりにもいくつかのフィールドを識別するために使用されている場合は、コンテキストにあまりにも頻繁に変更があるため、パフォーマンスが低下する可能性があります。
We stress that these guidelines are educated guesses. When IPv6 is widely deployed and IPv6 traffic can be analyzed, we might find that other grouping algorithms perform better. We also stress that if the grouping fails, the result will be bad performance but not incorrect decompression. The decompressor can do its task regardless of how the grouping algorithm works.
私たちは、これらのガイドラインは、教育を受けた推測であることを強調しています。 IPv6が広く展開されており、IPv6トラフィックを分析することができたとき、我々は他のグループ化アルゴリズムが良く行うことがあります。また、グループ化が失敗した場合、結果は悪いパフォーマンスではなく、間違って解凍されることを強調しています。デコンプレッサは関係なく、グループ化アルゴリズムがどのように動作するかのタスクを行うことができます。
Context identifiers can be 8 or 16 bits long. Their size is not relevant for finding the context. An 8-bit CID with value two and a 16-bit CID with value two are equivalent.
コンテキスト識別子は、8または16ビット長であることができます。その大きさは、コンテキストを見つけるには関係ありません。値2と2つの等価な値を持つ16ビットCIDを有する8ビットCID。
The CID spaces for TCP and non-TCP are separate, so a TCP CID and a non-TCP CID never identify the same context. Even if they have the same value. This doubles the available CID space while using the same number of bits for CIDs. It is always possible to tell whether a full or compressed header is for a TCP or non-TCP packet, so no mixups can occur.
TCPおよび非TCPのためのCID空間は独立しているので、TCP CIDと非TCP CIDは同じコンテキストを識別することはありません。場合でも、彼らは同じ値を持っています。 CIDのための同じビット数を使用しながら、これは、利用可能なCID空間を倍増します。完全または圧縮ヘッダがTCPまたは非TCPパケットのためなので、何mixupsが発生しないことができるかどうかを伝えることが常に可能です。
Non-TCP compressed headers encode the size of the CID using one bit in the second octet of the compressed header. The 8-bit CID allows a minimum compressed header size of 2 octets for non-TCP packets, the CID uses the first octet and the size bit and the 6-bit Generation value fit in the second octet.
非TCP圧縮ヘッダは圧縮ヘッダの第2オクテットに1ビットを使用してCIDのサイズをコードします。 8ビットのCIDは、非TCPパケットの2つのオクテットの最小圧縮ヘッダのサイズは、CIDが最初のオクテットとサイズのビットと第2オクテットで6ビット世代値フィットを使用可能にします。
For TCP the only available CID size is 8 bits as in [RFC-1144]. 8 bits is probably sufficient as TCP connections are always point-to-point.
TCPのためにのみ利用可能なCIDのサイズは、[RFC-1144]のように8ビットです。 TCP接続は常にポイントツーポイントですと8ビットは、おそらく十分です。
The 16 bit CID size may not be needed for point-to-point links; it is intended for use on multi-access links where a larger CID space may be needed for efficient selection of CIDs.
16ビットのCIDサイズは、ポイントツーポイントリンクのために必要とされなくてもよいです。それは、大きなCIDスペースがCIDの効率的な選択のために必要とすることができるマルチアクセスリンク上での使用を目的としています。
The major difficulty with multi-access links is that several compressors share the CID space of a decompressor. CIDs can no longer be selected independently by the compressors as collisions may occur. This problem may be resolved by letting the decompressors have a separate CID space for each compressor. Having separate CID spaces requires that decompressors can identify which compressor sent the compressed packet, perhaps by utilizing link-layer information as to who sent the link-layer frame. If such information is not available, all compressors on the multi-access link may be enumerated, automatically or otherwise, and supply their number as part of the CID. This latter method requires a large CID space.
マルチアクセスリンクでの大きな問題は、いくつかのコンプレッサーは、デコンプレッサのCID空間を共有するということです。衝突が発生する可能性としてのCIDは、もはや圧縮機によって独立して選択することができません。この問題は、デコンプレッサは、各圧縮機の個別のCIDスペースを持つせることによって解決することができます。別CID空間を有するデコンプレッサは、おそらくリンク層フレームを送信者に、リンク層情報を利用して、圧縮されたパケットを送信した圧縮機を識別することができることを必要とします。そのような情報が利用できない場合は、マルチアクセスリンク上のすべての圧縮機は、自動的に、またはそうでなければ、列挙、およびCIDの一部として、その数を供給することができます。この後者の方法は、大CIDスペースが必要です。
The size of the context SHOULD be limited to simplify implementation of compressor and decompressor, and put a limit on their memory requirements. However, there is no upper limit on the size of an IPv6 header as the chain of extension headers can be arbitrarily long. This is a problem as the context is essentially a stored header.
コンテキストのサイズは、コンプレッサとデコンプレッサの実装を簡素化し、そのメモリ要件に制限を置くために限定されるべきです。拡張ヘッダの鎖は任意の長さであることができるしかし、IPv6ヘッダのサイズに上限はありません。コンテキストは、本質的に保存されたヘッダであるので、これは問題です。
The configurable parameter MAX_HEADER (see section 14) represents the maximum size of the context, expressed as the maximum sized header that can be stored as context. When a header is larger than MAX_HEADER, only part of it is stored as context. An implementation MUST NOT compress more than the initial MAX_HEADER octets of a header. An implementation MUST NOT partially compress a subheader.
構成可能なパラメータMAX_HEADER（セクション14を参照）コンテキストの最大サイズを表すが、コンテキストとして格納することができる最大サイズのヘッダとして表さ。ヘッダはMAX_HEADERよりも大きい場合、その一部のみがコンテキストとして格納されています。実装は、ヘッダーの初期MAX_HEADERオクテット以上を圧縮してはなりません。実装は、部分的にサブヘッダを圧縮してはなりません。
Thus, the part of the header that is stored as context and is compressed is the longest initial sequence of entire subheaders that is not larger than MAX_HEADER octets.
このように、コンテキストとして格納され、圧縮されたヘッダの一部がMAX_HEADERオクテットより大きくない全体サブヘッダの最長の初期シーケンスです。
It is desirable to avoid increasing the size of packets with full headers beyond their original size, as their size may be optimized for the MTU of the link. Since we assume that the link layer implementation provides the length of packets, we can use the length fields in full headers to pass the values of the CID and the generation to the decompressor.
そのサイズがリンクのMTUに合わせて最適化することができるように、元のサイズを超えた完全なヘッダを持つパケットのサイズを大きく回避することが望ましいです。我々は、リンク層の実装は、パケットの長さを提供すると仮定しているので、我々は、デコンプレッサにCIDの値及び生成を渡すために、完全なヘッダの長さフィールドを使用することができます。
This requires that the link-layer must not add padding to the payload, at least not padding that can be delivered to the destination link user. It is also required that no extra padding is added after UDP data or in tunneled packets. This allows values of length fields to be calculated from the length of headers and the length of the link-layer frame.
これは、リンク層は、先のリンクのユーザに配信することができペイロード、少なくともないパディングにパディングを追加してはならないことが必要です。また、余分なパディングがUDPデータの後やトンネルパケットに付加されていないことが求められます。これは、長さフィールドの値は、ヘッダの長さとリンク層フレームの長さから算出することが可能になります。
The generation requires one octet and the CID may require up to 2 octets. There are length fields of 2 octets in the IPv6 Base Header, the IPv4 header, and the UDP header.
世代は、1つのオクテットを必要とし、CIDには、最大2つのオクテットが必要な場合があります。 IPv6の基本ヘッダ、IPv4ヘッダとUDPヘッダ内の2つのオクテットの長さフィールドが存在します。
A full TCP header will thus have at least 2 octets available in the IP header to pass the 8 bit CID, which is sufficient. There will be more than two octets available if there is more than one IP header.
完全なTCPヘッダは、このように十分である8ビットのCIDを通過するIPヘッダで利用可能な少なくとも2つのオクテットを有するであろう。複数のIPヘッダがある場合に利用できる以上の2つのオクテットがあります。
[RFC-1144] uses the 8 bit Protocol field of the IPv4 header to pass the CID. We cannot use the corresponding method as the sequence of IPv6 extension headers is not fixed and CID values are not disjoint from the legal values of Next Header fields.
[RFC-1144] CIDを渡すために、IPv4ヘッダの8ビット・プロトコル・フィールドを使用します。我々は、固定されていないIPv6拡張ヘッダのシーケンスとして、対応する方法を使用することができず、CIDの値は、次ヘッダフィールドの有効な値から互いに素ではありません。
An IPv6/UDP or IPv4/UDP packet will have 4 octets available to pass the generation and the CID, so all CID sizes may be used. Fragmented or encrypted packet streams may have only 2 octets available to pass the generation and CID. Thus, 8-bit CIDs may be the only CID sizes that can be used for such packet streams. When IPv6/IPv4 or IPv4/IPv6 tunneling is used, there will be at least 4 octets available, and both CID sizes may be used.
IPv6 / UDPまたはIPv4 / UDPパケットがので、すべてのCIDサイズが使用されてもよい、生成及びCIDを通過するために利用可能な4つのオクテットを有するであろう。断片化または暗号化されたパケットストリームを生成し、CIDを通過するために利用可能な唯一の2オクテットを有していてもよいです。したがって、8ビットのCIDは、パケットストリームのために使用することができる唯一のCIDサイズであってもよいです。 IPv6 / IPv4かのIPv4 / IPv6のトンネリングを使用する場合、そこには少なくとも4つのオクテット利用できるようになり、両方のCIDサイズが使用されてもよいです。
The generation value is passed in the higher order octet of the first length field in the full header. When only one length field is available, the 8-bit CID is passed in the low order octet. When two length fields are available, the lowest two octets of the CID are passed in the second length field and the low order octet of the first length field carries the highest octet of the CID.
生成値は、完全なヘッダ内の第1の長さフィールドの上位オクテットに渡されます。唯一の長さフィールドが利用可能である場合、8ビットのCIDは下位オクテットに渡されます。 2つの長フィールドが利用可能である場合、CIDの最も低い2つのオクテットは、第2の長さフィールドに渡され、第1の長さフィールドの下位オクテットは、CIDの最高オクテットを搬送します。
Use of first length field:
第一の長さフィールドの使用：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length field | LSB of pkt nr | CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Use of second length field if available:
第2の長さフィールドの使用可能な場合：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field | MSB of pkt nr | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pkt nr is short for packet sequence number, described in section 11.2.
PKTのNRは、セクション11.2で説明したパケットのシーケンス番号の略です。
Full non-TCP headers with 8-bit CID:
8ビットのCIDとの完全な非TCPヘッダ：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First length field |0|D| Generation| CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field (if avail.) | 0 | Data (if D=1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Full non-TCP headers with 16-bit CID:
16ビットのCIDとの完全な非TCPヘッダ：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First length field |1|D| Generation| Data (if D=1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field | CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first bit in the first length field indicates the length of the CID. The Data field is zero if D is zero. The use of the D bit and Data field is explained in section 12.
第1の長さフィールドの最初のビットはCIDの長さを示します。 Dがゼロの場合、データフィールドはゼロです。 Dビットとデータフィールドの使用は、セクション12で説明されています。
This section uses some terminology (DELTA, RANDOM) defined in section 7.
このセクションは、セクション7で定義されたいくつかの用語（DELTA、RANDOM）を使用します。
a) COMPRESSED_TCP format (similar to [RFC 1144]):
A）[RFC 1144]と同様COMPRESSED_TCP形式（）：
+-+-+-+-+-+-+-+-+
| CID |
+-+-+-+-+-+-+-+-+
|R O I P S A W U|
+-+-+-+-+-+-+-+-+
| |
+ TCP Checksum +
| |
+-+-+-+-+-+-+-+-+
| RANDOM fields, if any (see section 7) (implied)
- - - - - - - -
| R-octet | (if R=1)
- - - - - - - -
| Urgent Pointer Value (if U=1)
- - - - - - - -
| Window Delta (if W=1)
- - - - - - - -
| Acknowledgment Number Delta (if A=1)
- - - - - - - -
| Sequence Number Delta (if S=1)
- - - - - - - -
| IPv4 Identification Delta (if I=1)
- - - - - - - -
| Options (if O=1)
- - - - - - - -
The latter flags in the second octet (IPSAWU) have the same meaning as in [RFC-1144], regardless of whether the TCP segments are carried by IPv6 or IPv4. The C bit has been eliminated because the CID is always present. The context associated with the CID keeps track of the IP version and what RANDOM fields are present. The order between delta fields specified here is exactly as in [RFC-1144]. An implementation will typically scan the context from the beginning and insert the RANDOM fields in order. The RANDOM fields are thus placed before the DELTA fields of the TCP header in the same order as they occur in the original uncompressed header.
第二のオクテット（IPSAWU）における後者のフラグは関係なく、TCPセグメントがIPv6またはIPv4によって運ばれているかどうかの、[RFC-1144]の場合と同じ意味を有します。 CIDが常に存在するので、Cビットが除去されています。 CIDに関連付けられたコンテキストは、IPバージョンと何RANDOMフィールドが存在しているのを追跡します。ここで指定されたデルタ・フィールドの順序は、[RFC-1144]のように正確です。実装は、一般的に最初からコンテキストをスキャンして、順番にRANDOMフィールドを挿入します。それらは元の非圧縮ヘッダで発生するランダムフィールドは、このように同じ順序でTCPヘッダのDELTAフィールドの前に配置されています。
The I flag is zero unless an IPv4 header immediately precedes the TCP header. The combined IPv4/TCP header is then compressed as a unit as described in [RFC-1144]. Identification fields in IPv4 headers that are not immediately followed by a TCP header are RANDOM.
IPv4ヘッダは直ちにTCPヘッダに先行しない限り、Iフラグはゼロです。 [RFC-1144]に記載されているように組み合わされたIPv4 / TCPヘッダは、次に単位として圧縮されます。直ちにTCPヘッダに続いていないIPv4のヘッダ内の識別フィールドはランダムです。
If the O flag is set, the Options of the TCP header were not the same as in the previous header. The entire Option field are placed last in the compressed TCP header.
Oフラグが設定されている場合、TCPヘッダのオプションは、前のヘッダと同じではなかったです。全体オプションフィールドは、圧縮されたTCPヘッダの最後に配置されています。
If the R flag is set, there were differences between the context and the Reserved field (6 bits) in the TCP header or bit 6 or 7 of the TOS octet (Traffic Class octet) in a IPv4 header (IPv6 header) that immediately precedes the TCP header. An octet with the actual values of the Reserved field and bit 6 and 7 of the TOS or Traffic Class field is then placed immediately after the RANDOM fields. Bits 0-5 of the passed octet is the actual value of the Reserved field, and bits 6 and 7 are the actual values of bits 6 and 7 in the TOS or Traffic Class field. If there is no preceding IP header, bits 6 and 7 are 0. The octet passed with the R flag MUST NOT update the context.
Rフラグが設定されている場合、すぐ先行するIPv4ヘッダ内のTOSオクテット（トラフィッククラスオクテット）のTCPヘッダまたはビット6のコンテキストと予約フィールドとの間の差（6ビット）または7（IPv6ヘッダ）がありましたTCPヘッダー。 TOSまたはトラフィッククラスフィールドの実際のReservedフィールドの値とビット6と7とのオクテットは、ランダムフィールドの直後に配置されています。ビット渡されるオクテットの0-5は、予約フィールドの実際の値であり、6および7はTOSまたはトラフィッククラスフィールドのビット6と7の実際の値であるビット。いかなる先行IPヘッダがない場合、ビット6と7は、Rフラグで渡されるオクテットはコンテキストを更新してはいけません0です。
NOTE: The R-octet does not update the context because if it did, the nTCP checksum would not guard the receiving TCP from erroneously decompressed headers. Bits 6 and 7 of the TOS octet or Traffic Class octet is expected to change frequently due to Explicit Congestion Notification.
注：それがなかった場合は、NTCPチェックサムが誤って解凍ヘッダから受信TCPを守るないためR-オクテットは、コンテキストを更新しません。 TOSオクテットまたはトラフィッククラスオクテットのビット6及び7が原因明示的輻輳通知を頻繁に変更することが期待されます。
See section 7.12 and [RFC-1144] for further information on how to compress TCP headers.
TCPヘッダを圧縮する方法の詳細については、セクション7.12および[RFC-1144]を参照してください。
b) COMPRESSED_TCP_NODELTA header format
B）COMPRESSED_TCP_NODELTAヘッダフォーマット
+-+-+-+-+-+-+-+-+
| CID |
+-+-+-+-+-+-+-+-+
| RANDOM fields, if any (see section 7) (implied)
+-+-+-+-+-+-+-+-+
| Whole TCP header except for Port Numbers
+-+-+-+-+-+-+-+-+
c) Compressed non-TCP header, 8 bit CID:
0 7
+-+-+-+-+-+-+-+-+
| CID |
+-+-+-+-+-+-+-+-+
|0|D| Generation|
+-+-+-+-+-+-+-+-+
| data | (if D=1)
- - - - - - - -
| RANDOM fields, if any (section 7) (implied)
- - - - - - - -
d) Compressed non-TCP header, 16 bit CID:
0 7
+-+-+-+-+-+-+-+-+
| msb of CID |
+-+-+-+-+-+-+-+-+
|1|D| Generation|
+-+-+-+-+-+-+-+-+
| lsb of CID |
+-+-+-+-+-+-+-+-+
| data | (if D=1)
- - - - - - - -
| RANDOM fields, if any (section 7) (implied)
- - - - - - - -
The generation, CID and optional one octet data are followed by relevant RANDOM fields (see section 7) as implied by the compression state, placed in the same order as they occur in the original uncompressed header, followed by the payload.
世代、CID及びオプション1つのオクテットデータをペイロードに続くそれらは元の非圧縮ヘッダで発生するのと同じ順序で配置された圧縮状態によって示唆されるように、関連する確率場（セクション7参照）が続きます。
This section gives rules for how the compressible chain of subheaders is compressed. These rules MUST be followed. Subheaders that may be compressed include IPv6 base and extension headers, TCP headers, UDP headers, and IPv4 headers. The compressible chain of subheaders extends from the beginning of the header
このセクションでは、サブヘッダーの圧縮可能なチェーンが圧縮されている方法のための規則を与えます。これらのルールに従わなければなりません。圧縮されてもよいサブヘッダは、IPv6ベース及び拡張ヘッダ、TCPヘッダ、UDPヘッダ、およびIPv4のヘッダを含みます。サブヘッダの圧縮チェーンは、ヘッダの先頭から延びています
a) up to but not including the first header that is not an IPv4 header, an IPv6 base or extension header, a TCP header, or a UDP header, or
a）は、IPv4ヘッダー、IPv6のベースまたは拡張ヘッダ、TCPヘッダ、又はUDPヘッダではない最初のヘッダを含むまでではなく、又は
b) up to and including the first TCP header, UDP header, Fragment Header, Encapsulating Security Payload Header, or IPv4 header for a fragment,
B）へと断片の最初のTCPヘッダ、UDPヘッダ、フラグメントヘッダ、カプセル化セキュリティペイロードヘッダ、またはIPv4ヘッダを含むアップ、
whichever gives the shorter chain. For example, rules a) and b) both fit a chain of subheaders that contain a Fragment Header and ends at a tunneled IPX packet. Since rule b) gives a shorter chain, the compressible chain of subheaders stops at the Fragment Header.
どちらが短いチェーンを提供します。例えば、ルール）およびb）の両方がフラグメントヘッダを含み、トンネリングIPXパケットで終了するサブヘッダのチェーンに合います。規則b）は短鎖を与えるため、サブヘッダの圧縮性鎖フラグメントヘッダで停止します。
The following subsections are a systematic classification of how all fields in subheaders are expected to change.
以下のサブセクションは、サブヘッダー内のすべてのフィールドが変化することが予想されている方法の体系的な分類です。
NOCHANGE The field is not expected to change. Any change means that a full header MUST be sent to update the context.
NOCHANGEは、フィールドは変更することが予想されていません。任意の変化は、完全なヘッダはコンテキストを更新するために送らなければならないことを意味します。
DELTA The field may change often but usually the difference from the field in the previous header is small, so that it is cheaper to send the change from the previous value rather than the current value. This type of compression is only used for TCP packet streams.
DELTAは、フィールドは、頻繁に変更することができるが、以前の値ではなく現在の値からの変化を送信するために安価であるように、通常、前のヘッダ内のフィールドとの差が小さいです。圧縮のこのタイプは、TCPパケットストリームのために使用されています。
RANDOM The field must be included "as-is" in compressed headers, usually because it changes unpredictably.
RANDOMフィールドは、それが予測できない変化し、通常ので、圧縮ヘッダに「そのまま」に含まれている必要があります。
INFERRED The field contains a value that can be inferred from other values, for example the size of the frame carrying the packet, and thus must not be included in the compressed header.
INFERREDフィールドは、例えば、他の値からパケットを運ぶフレームの大きさを推測することができるので、圧縮されたヘッダに含まれてはならない値を含みます。
The classification implies how a compressed header is constructed. No field that is NOCHANGE or INFERRED is present in a compressed header. A compressor obtains the values of NOCHANGE fields from the context identified by the compression identifier, and obtains the values of INFERRED fields from the link-layer implementation, e.g., from the size of the link-layer frame, or from other fields, e.g., by recalculating the IPv4 header checksum. DELTA fields are encoded as the difference to the value in the previous packet in the same packet stream. The decompressor must update the context by adding the value in the compressed header to the value in its context. The result is the proper value of the field. RANDOM fields must be sent "as-is" in the compressed header. RANDOM fields must occur in the same order in the compressed header as they occur in the full header.
分類は、圧縮されたヘッダーを構築する方法を意味します。 NOCHANGEまたは推測されるいいえフィールドは、圧縮されたヘッダに存在しません。圧縮機は、例えば、リンク層フレームの大きさから、又は他のフィールドから、例えば、圧縮識別子によって識別されるコンテキストからNOCHANGEフィールドの値を取得し、リンク層の実装から推測フィールドの値を取得し、 IPv4ヘッダのチェックサムを再計算することによって。 DELTAフィールドは同一のパケットストリームにおける前のパケット内の値への差分として符号化されます。解凍器は、そのコンテキストの値に圧縮されたヘッダの値を加算することによってコンテキストを更新しなければなりません。結果は、フィールドの適切な値です。 RANDOMフィールドは、「そのままで」圧縮ヘッダで送信されなければなりません。彼らはフル・ヘッダで発生するランダムフィールドは、圧縮されたヘッダーに同じ順序で発生しなければなりません。
Fields that may optionally be used to identify what packet stream a packet belongs to according to section 4.1 are marked with the word DEF. To a compressor using the optional guidelines from section 4.1, any difference in corresponding DEF fields between two packets implies that they belong to different packet streams. Moreover, if a DEF field is present in one packet but not in another, the packets belong to different packet streams.
必要に応じてパケットをストリームどのパケットを識別するために使用することができるフィールドは、ワードDEFでマークされているセクション4.1に記載に属します。セクション4.1からの任意のガイドラインを使用して圧縮機に、二つのパケットの間の対応するDEFフィールド内の任意の違いは、異なるパケットストリームに属することを意味します。 DEFフィールドはなく、別の内の1つのパケット内に存在する場合はまた、パケットは、異なるパケットストリームに属します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version NOCHANGE (DEF) Traffic Class NOCHANGE (might be DEF, see sect 4.1) (see also sect 6 a) Flow Label NOCHANGE (DEF) Payload Length INFERRED Next Header NOCHANGE Hop Limit NOCHANGE (might be DEF, see sect 4.1) Source Address NOCHANGE (DEF) Destination Address NOCHANGE (DEF)
バージョンNOCHANGE（DEF）トラフィッククラスNOCHANGE（宗派4.1を参照してください、DEFかもしれません）（参照もSECT 6 a）のフローラベルNOCHANGE（DEF）ペイロード長INFERRED次ヘッダNOCHANGEホップ制限NOCHANGE（宗派4.1を参照してください、DEFかもしれません）送信元アドレスNOCHANGE（DEF）宛先アドレスNOCHANGE（DEF）
The Payload Length field of encapsulated headers must correspond to the length value of the encapsulating header. If not, the header chain MUST NOT be compressed.
カプセル化されたヘッダのペイロード長さフィールドは、カプセル化ヘッダの長さの値に対応しなければなりません。ない場合は、ヘッダー・チェーンは圧縮されてはなりません。
NOTE: If this the IP header closest to a TCP header, bit 7 of the Traffic Class field can be passed using the R-flag of the compressed TCP header. See section 6 a).
注：TCPヘッダに最も近いこのIPヘッダは、トラフィッククラスフィールドのビット7場合、圧縮TCPヘッダーのRフラグを使用して渡すことができます。セクション6 A）を参照してください。
This classification implies that the entire IPv6 base header will be compressed away.
この分類は、全体のIPv6基本ヘッダが離れて圧縮されることを意味します。
What extension headers are present and the relative order of them is not expected to change in a packet stream. Whenever there is a change, a full packet header must be sent. All Next Header fields in IPv6 base header and IPv6 extension headers are NOCHANGE.
どのような拡張ヘッダが存在し、それらの相対的な順序は、パケットストリームに変更することが予想されていません。変更があるたびに、完全なパケットヘッダを送信する必要があります。 IPv6の基本ヘッダとIPv6拡張ヘッダ内のすべての次ヘッダフィールドはNOCHANGEあります。
The contents of Hop-by-hop Options and Destination Options extension headers are encoded with TLV "options" (see [IPv6]):
ホップバイホップオプションと宛先オプション拡張ヘッダの内容は、TLV「オプション」（[IPv6を]参照）で符号化されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Option Type and Opt Data Len fields are assumed to be fixed for a given packet stream, so they are classified as NOCHANGE. The Option data is RANDOM unless specified otherwise below.
オプションタイプとオプトデータレンフィールドは、与えられたパケットストリームのために固定されているものとするので、彼らはNOCHANGEとして分類されています。そうでない場合は、以下の指定がない限りオプションのデータがランダムです。
Padding
パディング
Pad1 option
パッド1オプション
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Entire option is NOCHANGE.
全体のオプションがNOCHANGEです。
PadN option
PADNオプション
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
All fields are NOCHANGE.
すべてのフィールドがNOCHANGEです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header NOCHANGE Hdr Ext Len NOCHANGE
次のヘッダNOCHANGE HDR内線レンNOCHANGE
Options TLV coded values and padding. Classified according to 7.3 above, unless being a Jumbo Payload option (see below).
オプションTLVは、価値観やパディングをコード化されました。 （下記参照）ジャンボペイロードオプションである場合を除き、上記7.3に従って分類。
Jumbo Payload option
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 194 |Opt Data Len=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jumbo Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First two fields are NOCHANGE and Jumbo Payload Length INFERRED. (frame length must be supplied by link layer implementation).
最初の2つのフィールドはNOCHANGEと巨大ペイロード長推測されます。 （フレーム長は、リンク層の実装によって供給されなければなりません）。
NOTE: It is silly to compress the headers of a packet carrying a
Jumbo Payload Option since the relative header overhead is
negligible. Moreover, it is usually a bad idea to send such
large packets over low- and medium-speed links.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All fields of the Routing Header are NOCHANGE.
ルーティングヘッダのすべてのフィールドがNOCHANGEです。
If the Routing Type is not recognized, it is impossible to determine the final Destination Address unless the Segments Left field has the value zero, in which case the Destination Address is the final Destination Address in the basic IPv6 header.
ルーティングタイプが認識されない場合、セグメント左フィールドは、宛先アドレスが基本IPv6ヘッダの最後の宛先アドレスである場合には値ゼロを持っていない限り、最終的な宛先アドレスを決定することは不可能です。
In the Type 0 Routing Header, the last address is DEF if (Segments Left > 0).
（セグメントが左0>）場合にタイプ0ルーティングヘッダでは、最後のアドレスがDEFです。
Routing Headers are compressed away completely. This is a big win as the maximum size of the Routing Header is 392 octets. Moreover, Type 0 Routing Headers with one address, size 24 octets, are used by Mobile IP.
ルーティングヘッダは完全に離れて圧縮されます。ルーティングヘッダの最大サイズは392オクテットであるので、これは大きな勝利です。また、一つのアドレス、サイズが24個のオクテットで0ルーティングヘッダを入力し、モバイルIPによって使用されます。
The first fragment of a packet has Fragment Offset = 0 and the chain of subheaders extends beyond its Fragment Header. If a fragment is not the first (Fragment Offset not 0), there are no subsequent subheaders (unless the chain of subheaders in the first fragment didn't fit entirely in the first fragment).
パケットの最初のフラグメントは、フラグメントオフセット= 0を有し、サブヘッダの鎖は、そのフラグメントヘッダを越えて延びています。フラグメントが最初でない場合（最初のフラグメントでサブヘッダの鎖が最初のフラグメントに完全に適合しない場合を除き）後続サブヘッダが存在しない、（断片が0でないオフセット）。
Since packets may be reordered before reaching the compression point, and some fragments may follow other routes through the network, a compressor cannot rely on seeing the first fragment before other fragments. This implies that information in subheaders following the Fragment Header of the first fragment cannot be examined to determine the proper packet stream for other fragments.
パケットが圧縮点に到達する前に並べ替えてもよく、いくつかの断片がネットワークを介して他の経路をたどることができるので、圧縮機が他のフラグメントの前に最初のフラグメントを見に頼ることはできません。これは、最初のフラグメントのフラグメントヘッダを次サブヘッダの情報は他の断片のための適切なパケットストリームを決定するために検査することができないことを意味します。
It is possible to design compression schemes that can compress subheaders after the Fragment Header, at least in the first fragment, but to avoid complicating the rules for sending full headers and the rules for compression and decompression, the chain of subheaders that follow a Fragment Header MUST NOT be compressed.
少なくとも第1フラグメント、フラグメントヘッダの後にサブヘッダを圧縮することができるが、完全なヘッダ圧縮および解凍するためのルール、フラグメントヘッダに従っサブヘッダのチェーンを送信するためのルールを複雑化を回避するために、圧縮スキームを設計することが可能です圧縮されてはなりません。
The fields of the Fragment Header are classified as follows.
次のようにフラグメントヘッダのフィールドが分類されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header NOCHANGE
Reserved NOCHANGE
Res RANDOM
M flag RANDOM
Fragment Offset RANDOM
Identification RANDOM
This classification implies that a Fragment Header is compressed down to 6 octets. The minimum IPv6 MTU is 1280 octets so most fragments will be at least 1280 octets. Since the 6 octet overhead of the compressed fragment header is amortized over a fairly large packet, the additional complexity of more sophisticated compression schemes is not justifiable.
この分類は、フラグメントヘッダー6つのオクテットに圧縮されていることを意味します。ほとんどのフラグメントは、少なくとも1280オクテットになりますので、最小のIPv6 MTUは1280オクテットです。圧縮されたフラグメントヘッダの6オクテットのオーバーヘッドはかなり大きいパケットにわたって償却されているので、より洗練された圧縮方式の付加的な複雑さは正当ではありません。
NOTE: The Identification field is RANDOM instead of NOCHANGE
to avoid one compression slow-start per original packet.
Grouping of fragments according to the optional guidelines in section4.1:
section4.1中の任意のガイドラインに従った断片のグループ化：
Fragments and unfragmented packets should not be grouped
together.
Port numbers cannot be used to identify the packet stream because port numbers are not present in every fragment. To adhere to the uniqueness rules for the Identification value, a fragmented packet stream is identified by the combination of Source Address and (final) Destination Address.
ポート番号は、ポート番号は、すべてのフラグメントには存在しないため、パケットストリームを識別するために使用することはできません。識別値の一意性規則に準拠するために、断片化パケットストリームは、ソースアドレス及び（最終的な）宛先アドレスとの組み合わせによって識別されます。
NOTE: The Identification value is NOT used to identify the packet stream. This avoids using a new CID for each packet and saves the cost of the associated compression slow-start. We expect that the unfragmentable part of the headers will not change too frequently, if it does thrashing may occur.
注：識別値は、パケットストリームを識別するために使用されていません。これは、各パケットのための新しいCIDを使用して回避し、関連する圧縮スロースタートのコストを節約できます。私たちは、それはスラッシングが発生する可能性がない場合、ヘッダーのフラグメント化不能部分は、あまりにも頻繁に変更されないことを期待しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header NOCHANGE Hdr Ext Len NOCHANGE
次のヘッダNOCHANGE HDR内線レンNOCHANGE
Options TLV coded values and padding. Compressed according to 7.3 above.
オプションTLVは、価値観やパディングをコード化されました。上記7.3に従って圧縮。
The only Destination Options defined in [IPv6] are the padding options.
[IPv6の]で定義された唯一の宛先オプションは、パディングオプションです。
Covered by rules for IPv6 Header Extensions (7.2).
IPv6のヘッダの拡張機能（7.2）のための規則でカバー。
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+
| Next Header | Length | RESERVED |
+---------------+---------------+---------------+---------------+
| Security Parameters Index (SPI) |
+---------------+---------------+---------------+---------------+
| |
+ Authentication Data (variable number of 32-bit words) |
| |
+---------------+---------------+---------------+---------------+
Next Header NOCHANGE Length NOCHANGE Reserved NOCHANGE SPI NOCHANGE (DEF) Authentication Data RANDOM
（DEF）次ヘッダNOCHANGE長NOCHANGE予約NOCHANGE SPI NOCHANGE認証データRANDOM
[RFC-1828] specifies how to do authentication with keyed MD5, the authentication method all IPv6 implementations must support. For this method, the Authentication Data is 16 octets.
[RFC-1828]はキー付きMD5、すべてのIPv6実装がサポートしなければならない認証方法で認証を行う方法を指定します。この方法では、認証データは16オクテットです。
This header implies that the subsequent parts of the packet are encrypted. Thus, no further header compression is possible on subsequent headers as encryption is typically already performed when the compressor sees the packet.
このヘッダは、パケットの後続の部分が暗号化されることを意味します。圧縮機がパケットを見たとき暗号化は、典型的には、既に行われているようにこのように、更なるヘッダ圧縮は、後続のヘッダーに不可能です。
However, when the ESP Header is used in tunnel mode an entire IP packet is encrypted, and the headers of that packet MAY be compressed before the packet is encrypted at the entry point of the tunnel. This means that it must be possible to feed an IP packet and its length to the decompressor, as if it came from the link-layer. The mechanisms for dealing with reordering described in section 11 MUST also be used, as packets can be reordered in a tunnel.
しかしながら、ESPヘッダはトンネルモードで使用する場合、全体のIPパケットが暗号化され、パケットがトンネルの入口点で暗号化される前に、そのパケットのヘッダを圧縮することができます。これは、リンク層から来たかのように、デコンプレッサへのIPパケットとその長さを供給することが可能でなければならないことを意味しています。パケットがトンネル内で並べ替えることができるように節11に記載の並べ替えに対処するための機構も、使用しなければなりません。
+---------------+---------------+---------------+---------------+
| Security Association Identifier (SPI), 32 bits |
+===============+===============+===============+===============+
| Opaque Transform Data, variable length |
+---------------+---------------+---------------+---------------+
SPI NOCHANGE (DEF) Opaque Transform Data RANDOM
SPI NOCHANGE（DEF）不透明でデータRANDOMを変換します
Everything after the SPI is encrypted and is not compressed.
SPI後のすべてが暗号化され、圧縮されていません。
The UDP header is described in [RFC-768].
UDPヘッダは、[RFC-768]に記載されています。
The Next Header field (IPv6) or Protocol field (IPv4) in the preceding subheader is DEF.
前のサブヘッダの次のヘッダフィールド（IPv6）のまたはプロトコルフィールド（IPv4の）がDEFです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port NOCHANGE (DEF) Destination Port NOCHANGE (DEF) Length INFERRED Checksum RANDOM, unless it is zero, in which case it is NOCHANGE.
ソースポートNOCHANGE（DEF）宛先ポートNOCHANGE（DEF）の長さINFERREDチェックサムRANDOM、それがNOCHANGEであり、その場合には、ゼロでない限り。
The Length field of the UDP header MUST match the Length field(s) of preceding subheaders, i.e, there must not be any padding after the UDP payload that is covered by the IP Length.
UDPヘッダの長さフィールドは、すなわち先行サブヘッダの長さフィールド（複数可）と一致する必要があり、IPの長さによって覆われているUDPペイロードの後に、任意のパディングがあってはなりません。
The UDP header is typically compressed down to 2 octets, the UDP checksum. When the UDP checksum is zero (which it cannot be with IPv6), it is likely to be so for all packets in the flow and is defined to be NOCHANGE. This saves 2 octets in the compressed header.
UDPヘッダは、典型的には2つのオクテット、UDPチェックサムまで圧縮されます。 UDPチェックサムが（それは、IPv6とすることができない）がゼロである場合は、フロー内のすべてのパケットのためにそうである可能性があるとNOCHANGEであると定義されます。これは、圧縮されたヘッダ内の2つのオクテットを保存します。
The TCP header is described in [RFC-793].
TCPヘッダは、[RFC-793]に記載されています。
The Next Header field (IPv6) or Protocol field (IPv4) in the preceding subheader is DEF.
前のサブヘッダの次のヘッダフィールド（IPv6）のまたはプロトコルフィールド（IPv4の）がDEFです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset| Reserved |U|A|P|R|S|F| Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U, A, P, R, S, and F stands for Urg, Ack, Psh, Rst, Syn, and Fin.
U、A、P、R、S、およびFはURG、ACK、PSH、RST、SYN、及びフィンを表します。
There are two ways to compress the TCP header.
TCPヘッダを圧縮するには、2つの方法があります。
Source Port NOCHANGE (DEF) Destination Port NOCHANGE (DEF) Sequence Number DELTA Acknowledgment Number DELTA Offset NOCHANGE Reserved DELTA (if differs from context, set R-flag in flag octet and send absolute value as described in 6 a.) Urg,Psh RANDOM (placed in flag octet) Ack INFERRED to be 1 Rst,Syn,Fin INFERRED to be 0 Window DELTA (if change in Window, set W-flag in flag octet and send difference) Checksum RANDOM Urgent Pointer DELTA (if Urg is set, send absolute value) Options, Padding DELTA (if change in Options, set O-flag and send whole Options, Padding)
ソースポートNOCHANGE（DEF）宛先ポートNOCHANGE（DEF）シーケンス番号DELTA確認応答番号DELTA（文脈から異なるが、フラグオクテットでRフラグを設定した場合、図6で説明したように絶対値を送信する。）NOCHANGE予約DELTAオフセットURG、PSH RANDOM URGが設定されている場合（0ウィンドウDELTA（ウィンドウの変化、フラグオクテットでWフラグを設定し、その差を送信する場合）チェックサムRANDOM緊急ポインタDELTAことが1 Rstを、SYN、フィン推測することにする（フラグオクテットに置か）のAck INFERRED、絶対値）オプションを送信し、パディングDELTA（オプションの変化は、Oフラグを設定し、全体のオプションを送信する場合、パディング）
A packet with a TCP header compressed according to the above must be indicated to be of type COMPRESSED_TCP. The compressed header is described in section 6.
上記に従って圧縮TCPヘッダーを持つパケットは、タイプCOMPRESSED_TCPであることが示されなければなりません。圧縮されたヘッダは、セクション6に記載されています。
This method is essentially the differential encoding techniques of Jacobson, described in [RFC-1144], the differences being the placement of the compressed TCP header fields (see section 6), the use of the O-flag, the use of the R-flag, and elimination of the C-flag. The O-flag allows compression of the TCP header when the Timestamp option is used and the Options fields changes with each header.
この方法は、本質的に[RFC-1144]で説明ヤコブソンの差動符号化技術であり、相違点は、圧縮TCPヘッダーフィールド（セクション6を参照）、Oフラグの使用、R-の使用の配置でありますフラグ、Cフラグの排除。 Oフラグは、タイムスタンプオプションが使用されているTCPヘッダの圧縮を可能にし、オプションは、各ヘッダ変化をフィールド。
DELTA values (except for Reserved field and Options, Padding) MUST be coded as in [RFC-1144]. A Reserved field value passed with the R-flag MUST NOT update the context at compressor or decompressor.
（予約フィールド及びオプションのパディングを除く）のデルタ値は、[RFC-1144]のように符号化されなければなりません。 R-フラグで渡さ予約フィールドの値は、圧縮または解凍器におけるコンテクストを更新してはいけません。
Source Port NOCHANGE (DEF)
Destination Port NOCHANGE (DEF)
(all the rest) RANDOM
（すべての残りの部分）RANDOM
The Identification field in a preceding IPv4 header is RANDOM.
先行のIPv4ヘッダ内の識別フィールドがランダムです。
A packet with a TCP header compressed according to the above must be indicated to be of type COMPRESSED_TCP_NODELTA. It uses the same CID space as COMPRESSED_TCP packets, and the header MUST be saved as context. The compressed header is described in section 6.
上記に従って圧縮TCPヘッダーを持つパケットは、タイプCOMPRESSED_TCP_NODELTAであることが示されなければなりません。これはCOMPRESSED_TCPパケットと同じCID空間を使用し、ヘッダは、コンテキストとして保存しなければなりません。圧縮されたヘッダは、セクション6に記載されています。
This packet type can be sent as the response to a header request instead of sending a full header, can be used over links that reorder packets, and can be sent instead of a full header when there are changes that cannot be represented by a compressed header. A sophisticated compressor can switch to sending only COMPRESSED_TCP_NODELTA headers when the packet loss frequency is high.
このパケットタイプではなく、パケットを並べ替えるリンク上で使用することができる完全なヘッダを送信するヘッダ要求に対する応答として送信することができ、圧縮ヘッダで表現できない変更がある場合、完全なヘッダの代わりに送信することができます。洗練された圧縮機は、パケットロス頻度が高い場合にのみCOMPRESSED_TCP_NODELTAヘッダの送信に切り替えることができます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are two ways to compress the IPv4 header
IPv4ヘッダを圧縮するには、2つの方法があります。
a) If the IPv4 header is not for a fragment (MF flag is not set and Fragment Offset is zero) and there are no options (IHL is 5), it is classified as follows
A）以下のようにIHLは5）、それが分類されている（IPv4ヘッダーが断片についてない場合（MFフラグが設定され、フラグメントオフセットがゼロでない場合）とはオプションが存在しません
Version NOCHANGE (DEF)
IHL NOCHANGE (DEF, must be 5)
Type of Service NOCHANGE (might be DEF, see sect 4.1)
(see also 6 a)
Total Length INFERRED (from link-layer implementation
or encapsulating IP header)
Identification DELTA/ (If the Protocol field has the (value corresponding to TCP) RANDOM (otherwise)
識別DELTA /（プロトコルフィールドはTCPに対応する（値を有する場合）RANDOM（それ以外）
Flags NOCHANGE (MF flag must not be set) Fragment Offset NOCHANGE (must be zero) Time to Live NOCHANGE (might be DEF, see sect 4.1) Protocol NOCHANGE Header Checksum INFERRED (calculated from other fields) Source Address NOCHANGE (DEF) Destination Address NOCHANGE (DEF) Options, Padding (not present)
国旗NOCHANGE（MFフラグがセットされてはならない）フラグメントオフセットNOCHANGE NOCHANGEを生存時間（ゼロでなければならない）プロトコルNOCHANGEヘッダチェックサムINFERRED（他のフィールドから計算された）ソースアドレスNOCHANGE（DEF）宛先アドレス（DEFかもしれませんが、セクト4.1を参照） NOCHANGE（DEF）オプション、パディング（存在しません）
Note: When a TCP header immediately follows, the IPv4 and TCP header MUST be compressed as a unit as described in section 6. Bits 6 and 7 of the Type of Service field (bits 14 and 15 of the first word) can then be passed using the R-flag (see section 6 a).
注：TCPヘッダは、直ちに次の場合部6ビット6とサービスフィールドのタイプの7に記載されているように、IPv4およびTCPヘッダを単位として圧縮されなければならない（ビット14と第1のワードの15）を通過させることができますRフラグを使用して（セクション6は、A参照）。
b) If the IPv4 header is for a fragment (MF bit set or Fragment Offset nonzero), or there are options (IHL > 5), all fields are RANDOM (i.e., if the header is compressed all fields are sent as-is and not compressed). This classification allows compression of the tunnel header, but not the fragment header, when fragments are tunneled. If the IPv4 header is for a fragment it ends the compressible chain of subheaders, i.e., it must be the last subheader to be compressed. If the IPv4 header has options but is not for a fragment it does not end the compressible chain of subheaders, so subsequent subheaders can be compressed.
ヘッダが圧縮されている場合、そのままB）IPv4ヘッダーが断片に対するものである場合（MFビットが設定またはフラグメントが非ゼロオフセット）、またはオプションがある（IHL> 5）、すべてのフィールドは、すべてのフィールドをランダム（すなわち、送信されると）圧縮されません。この分類は、フラグメントがトンネリングされる場合、フラグメントヘッダトンネルヘッダの圧縮を可能にする、ではありません。 IPv4ヘッダは、それがサブヘッダの圧縮チェーンを終了する断片のためのものである場合、すなわち、圧縮されるべき最後のサブヘッダでなければなりません。 IPv4ヘッダーオプションを有するが、それはサブヘッダの圧縮チェーンを終了していないフラグメントに対してない場合ので、その後のサブヘッダを圧縮することができます。
A compressor that follows the optional guidelines of section 4.1 will in case a) use the Version, Source Address and Destination Address to define the packet stream, together with the fact that there are no IPv4 options and that this is not a fragment.
一緒に何のIPv4オプションが存在しないという事実とし、このことを、ケースa）においてパケットストリームを定義するバージョン、ソースアドレスと宛先アドレスを使用するセクション4.1のオプションのガイドラインを次のコンプレッサーは、フラグメントではありません。
Case b) can define two kinds of packet streams depending on whether the IPv4 header is for a fragment or not.
ケースb）はIPv4ヘッダーが断片のためのものであるか否かに応じて、パケットストリームの二種類を定義することができます。
If the IPv4 header in case b) is for a fragment, a compressor following the optional guidelines will use that fact together with the Version, Source Address, and Destination Address to determine the packet stream.
ケースbにIPv4ヘッダ）が断片のためのものである場合、任意ガイドラインに従って圧縮機は、パケットストリームを決定するために、バージョン、ソースアドレス、宛先アドレスと一緒にその事実を使用します。
If the IPv4 header in case b) is not for a fragment, it must have options. A compressor following the optional guidelines will use that fact, but not the size of the options, together with the Version, Source Address, and Destination Address to determine the packet stream.
ケースb）におけるIPv4ヘッダーが断片のためではない場合、それはオプションを有していなければなりません。その事実を使用するオプションのガイドラインを以下の圧縮機ではなく、一緒にバージョンとオプションのサイズ、送信元アドレス、宛先アドレスは、パケットストリームを決定します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol |S| reserved | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (if present) Original Source Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol NOCHANGE Original Source Address Present (S) NOCHANGE reserved NOCHANGE Header Checksum INFERRED (calculated from other values) Original Destination Address NOCHANGE Original Source Address NOCHANGE (present only if S=1)
プロトコルNOCHANGEオリジナルソースNOCHANGEはNOCHANGEヘッダチェックサムINFERRED（他の値から計算された）元の宛先アドレスNOCHANGEオリジナルソースはNOCHANGE（のみS = 1の場合に存在する）アドレス予約済み（S）現在のアドレス
This header is likely to be used by Mobile IP.
このヘッダは、モバイルIPによって使用される可能性があります。
On a point-to-point link, the compressor has total knowledge of what CIDs are in use at the decompressor and may change what CID a packet stream uses or reuse CIDs at will.
ポイントツーポイントリンク上で、圧縮機は、接続識別子がデコンプレッサで使用されているものの合計知識を有しており、パケットストリームを使用するか、または随意にCIDを再使用CID内容を変更してもよいです。
Each non-TCP CID is associated with a context with a generation value. To avoid too rapid generation wrap-around and potential incorrect decompression, an implementation MUST avoid wrap-around of the generation value in less than MIN_WRAP seconds (see section 14).
各非TCPのCIDを生成値とコンテキストに関連付けられています。あまりにも急速な世代ラップアラウンドし、潜在的な不正確な解凍回避するために、実装はMIN_WRAP秒（セクション14を参照）未満で世代値のラップアラウンドを回避しなければなりません。
To aid in avoiding wrap-around, the generation value associated with a CID MUST NOT be reset when changing to a new packet stream. Instead, a compressor MUST increment the generation value by one when using the CID for a new non-TCP packet stream.
新しいパケットストリームに変更したときにラップアラウンド回避を支援するために、CIDに関連付けられた世代値がリセットされてはなりません。新たな非TCPパケットストリームのためのCIDを使用している場合代わりに、コンプレッサーは1によって生成値を増加しなければなりません。
When a decompressor receives a packet with a compressed TCP header with CID C, it MUST be discarded when the context for C has not been initialized by a full header.
減圧装置がCID Cと圧縮されたTCPヘッダを有するパケットを受信したときにCのためのコンテキストがフル・ヘッダによって初期化されていない場合、それを捨てなければなりません。
When a decompressor receives a packet with a compressed non-TCP header with CID C and generation G, the header must not be decompressed using the current context when
減圧装置がCID Cと世代Gと圧縮非TCPヘッダを有するパケットを受信すると、ヘッダは、ときに、現在のコンテキストを使用して解凍してはなりません
a) the decompressor has been disconnected from the compressor for more than MIN_WRAP seconds, because the context might be obsolete even if it has generation G.
コンテキストが古いかもしれないので、A）デコンプレッサは、それが生成G.であっても、よりMIN_WRAP秒圧縮機から切断されています
b) the context for C has a generation other than G.
B）Cのためのコンテキストは、G以外の世代を有します
In case a) and b) the packet may either be
場合a）およびb）パケットがいずれであってもよいです
i) discarded immediately, or else ii) stored temporarily until the context is updated by a packet with a full non-TCP header with CID C and generation G, after which the header can be decompressed.
I）直ちに廃棄、あるいはコンテキストがヘッダを解凍することができ、その後CID Cと世代Gに完全に非TCPヘッダを有するパケットによって更新されるまでII）一時記憶されます。
Packets stored in this manner MUST be discarded when
このようにして格納されたパケットは、場合捨てなければなりません
*) receiving full or compressed non-TCP headers with CID C and a generation other than G,
*）CID CとG以外の世代で完全または圧縮された非TCPヘッダーを受信し、
*) the decompressor has not received packets with CID C in the last MIN_WRAP seconds.
*）デコンプレッサは、最後のMIN_WRAP秒でCID Cを持つパケットを受信していません。
When full headers are lost, a decompressor can receive compressed non-TCP headers with a generation value other than the generation of its context. Rule ii) allows the decompressor to store such headers until they can be decompressed using the correct context.
フルヘッダーが失われるとき、デコンプレッサは、その文脈の世代以外の世代の値と圧縮非TCPヘッダーを受信することができます。ルールII）は、彼らが正しいコンテキストを使用して解凍されるまで減圧装置がそのようなヘッダを格納することを可能にします。
Since fewer bits are transmitted per packet with header compression, the packet loss rate is lower with header compression than without, for a fixed bit-error rate. This is beneficial for links with high bit-error rates such as wireless links.
少ないビットは、ヘッダ圧縮とパケット毎に送信されるので、パケット損失率は、固定されたビット誤り率のために、ない場合よりも、ヘッダ圧縮と低くなっています。これは、無線リンクのような高ビット・エラー・レートとのリンクのために有益です。
However, since TCP headers are compressed using differential encoding, a single lost TCP segment can ruin an entire TCP sending window because the context is not incremented properly at the decompressor. Subsequent headers will therefore be decompressed to be different than before compression and discarded by the TCP receiver because the TCP checksum fails.
TCPヘッダは、差動符号化を用いて圧縮されるので、単一の失われたTCPセグメントは、コンテキストがデコンプレッサで適切にインクリメントされていないため、窓を送信全体TCPを台無しにすることができます。後続のヘッダは、したがって、圧縮前よりも異なるように解凍され、TCPチェックサムが失敗したため、TCP受信機によって破棄されます。
A TCP connection in the wide area where the last hop is over a medium-speed lossy link, for example a wireless LAN, will then have poor performance with traditional header compression because the delay-bandwidth product is relatively large and the bit-error rate relatively high. For a 2 Mbit/s wireless LAN and an end-to-end RTT of 200 ms, the delay-bandwidth product is 50 kbyte. That is equivalent to about 97 512-octet segments with compressed headers. Each loss can thus be multiplied by a factor of 100.
遅延帯域幅積が比較的大きいとビット誤り率であるため、最後のホップは、例えば、中速ロッシーリンクを介して無線LANで広い領域でTCPコネクションは、その後、従来のヘッダ圧縮のパフォーマンスの低下を有するであろう比較的高いです。 2メガビット/秒の無線LANと200ミリ秒のエンドツーエンドのRTTため、遅延帯域幅積は、50キロバイトです。すなわち、圧縮ヘッダを持つ約97の512オクテットのセグメントに相当します。各損失は、従って、100の係数で乗算することができます。
This section describes two simple mechanisms for quick repair of the context. With these mechanisms header compression will improve TCP throughput over lossy links as well as links with low bit-error rates.
このセクションでは、コンテキストの迅速な修理のために2つの単純なメカニズムについて説明します。これらのメカニズムとヘッダ圧縮は、非可逆リンクならびに低いビット誤り率とのリンク上のTCPスループットを向上させます。
The decompressor may compute the TCP checksum to determine if its context is not updated properly. If the checksum fails, the error is assumed to be caused by a lost segment that did not update the context properly. The delta of the current segment is then added to the context again on the assumption that the lost segment contained the same delta as the current. By decompressing and computing the TCP checksum again, the decompressor checks if the repair succeeded or if the delta should be applied once more.
デコンプレッサは、そのコンテキストが適切に更新されていないかどうかを判断するためにTCPチェックサムを計算することができます。チェックサムが失敗した場合、エラーが適切にコンテキストを更新しませんでした、失われたセグメントによって引き起こされるものとします。現在のセグメントのデルタが失わセグメントが現在と同じデルタが含まれていることを前提に再びコンテキストに追加されます。解凍して、再度TCPチェックサムを計算することによって、デコンプレッサのチェックは修理が成功した場合や、デルタはもう一度適用する必要がある場合。
Analysis of traces of various TCP bulk transfers show that applying the delta of the current segment one or two times will repair the context for between 83 and 99 per cent of all single-segment losses in the data stream. For the acknowledgment stream, the success rate is smaller due to the delayed ack mechanism of TCP. The "twice" mechanism repairs the context for 53 to 99 per cent of the losses in the acknowledgment stream. A sophisticated implementation of this idea would determine whether the TCP stream is an acknowledgment or data stream and determine the segment size by observing the stream of full and compressed headers. Trying deltas that are small multiples of the segment size will result in even higher rates of successful repairs for acknowledgment streams.
様々なTCPバルク転送のトレースの分析は、現在のセグメント1回または2回のデルタを適用すると、データ・ストリーム内のすべての単一セグメント損失のパーセント83から99のコンテキストを修復することを示しています。確認応答ストリームの場合、成功率が原因TCPの遅延ACK機構に小さくなっています。 「二回」のメカニズムの修理承認の流れの損失の53〜99パーセントのためのコンテキスト。このアイデアの洗練された実装では、TCPストリームが確認応答又はデータストリームであるか否かを決定し、完全かつ圧縮ヘッダの流れを観察することにより、セグメントサイズを決定するであろう。セグメントサイズの小さな倍数でデルタをしようとすると、確認応答ストリームのための成功の修理のさらに高い割合になります。
The relatively low success rate for the "twice" algorithm for TCP acknowledgment streams calls for an additional mechanism for repairing the context at the decompressor. When the decompressor fails to repair the context after a loss, the decompressor may optionally request a full header from the compressor. This is possible on links where the decompressor can identify the compressor and send packets to it.
TCP受信確認のための「二回」アルゴリズムのための比較的低い成功率は解凍器でコンテキストを修復するための追加のメカニズムのための呼び出しをストリーミングします。減圧装置が消失した後のコンテキストを修復するために失敗した場合、解凍装置は、必要に応じて圧縮機からのフルヘッダーを要求することができます。これは、デコンプレッサは、コンプレッサを特定し、それにパケットを送信することができ、リンク上で可能です。
On such links, a decompressor may send a CONTEXT_STATE packet back to the compressor to indicate that one or more contexts are invalid. A decompressor SHOULD NOT transmit a CONTEXT_STATE packet every time a compressed packet refers to an invalid context, but instead should limit the rate of transmission of CONTEXT_STATE packets to avoid flooding the reverse channel. A CONTEXT_STATE packet can indicate that several contexts are out of date, this technique SHOULD be used instead of sending several separate packets. The following diagram shows the format of a CONTEXT_STATE packet.
このようなリンクでは、解凍器は、一つ以上のコンテキストが無効であることを示すために戻って圧縮機へCONTEXT_STATEパケットを送信することができます。減圧装置はCONTEXT_STATEパケットに圧縮されたパケットは無効なコンテキストを意味するたびに送信しないはずであるが、代わりに逆方向チャネルのフラッディングを回避するためにCONTEXT_STATEパケットの伝送レートを制限すべきです。 CONTEXT_STATEパケットは、いくつかのコンテキストが古くなっていることを示すことができ、この技術ではなく、いくつかの独立したパケットを送信するのに使用されるべきである（SHOULD）。次の図はCONTEXT_STATEパケットのフォーマットを示します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| TCP header request = 3 |
+---+---+---+---+---+---+---+---+
| CID count |
+---+---+---+---+---+---+---+---+
| CID |
+---+---+---+---+---+---+---+---+
| CID |
+---+---+---+---+---+---+---+---+
...
+---+---+---+---+---+---+---+---+
| CID |
+---+---+---+---+---+---+---+---+
The first octet is a type code to allow the CONTEXT_STATE packet type to be shared for other compression protocols that are (see [CRTP]) or may be defined in parallel with this one. When used for TCP header requests the type code has the value 3, and the remainder of the packet is a sequence of CIDs preceded by a one-octet count of the number of CIDs.
最初のオクテットはCONTEXT_STATEパケットタイプである他の圧縮プロトコルのために共有することを可能にするタイプのコードである（[CRTP]参照）、これと並行して定義することができます。 TCPヘッダに使用する場合、タイプコードが値3を有する要求し、パケットの残りの部分は、CIDの数の1オクテットカウントが先行CIDの配列です。
On receipt of a CONTEXT_STATE packet, the compressor MUST mark the CIDs invalid to ensure that the next packet emitted in those packet streams are FULL_HEADER or COMPRESSED_TCP_NODELTA packets.
CONTEXT_STATEパケットの受信時に、圧縮機は、これらのパケットストリーム内に放出された次のパケットがFULL_HEADER又はCOMPRESSED_TCP_NODELTAパケットであることを確認するためのCID無効をマークしなければなりません。
Header requests are an optimization, so loss of a CONTEXT_STATE packet does not affect the correct operation of TCP header compression. When a CONTEXT_STATE packet is lost, eventually a new one will be transmitted or TCP will timeout and retransmit. The big advantage of using header requests is that TCP acknowledgment streams can be repaired after a roundtrip-time over the lossy link. This will typically avoid a TCP timeout and unnecessary retransmissions. The lower packet loss rate due to smaller packets will then result in higher throughput because the TCP window can grow larger between losses.
CONTEXT_STATEパケットの損失がTCPヘッダー圧縮の正しい動作に影響を与えないようにヘッダー要求は、最適化されています。 CONTEXT_STATEパケットが失われると、最終的に新しいものが送信されるか、TCPがタイムアウトして再送します。ヘッダー要求を使用しての大きな利点は、TCPの確認応答ストリームは損失リンク上の往復時間後に修復することができるということです。これは、通常、TCPのタイムアウトと、不必要な再送信を避けることができます。 TCPウィンドウは、損失の間で大きく成長することができますので、小さなパケットによる低パケット損失率は、より高いスループットになります。
Some links reorder packets, for example multi-hop radio links that use deflection routing to route around congested nodes. Packets routed different ways can then arrive at the destination in a different order than they were sent.
一部のリンクが輻輳ノードの周囲経路に偏向ルーティングを使用する例示的なマルチホップ無線リンクのために、パケットを並べ替えます。パケットは、彼らが送信されたとは異なる順序で目的地に到着することができますさまざまな方法をルーティングされます。
Compressed non-TCP headers do not change the context, and neither do full headers that refresh it. There can be problems only when a full header that changes the context arrives out of order. There are two cases:
圧縮された非TCPヘッダには、コンテキストを変更せず、どちらもそれを更新する完全なヘッダを行いません。コンテキストを変更し、完全なヘッダーが順不同で到着したときにのみ問題が発生することがあります。 2つのケースがあります。
- A packet with a full header with generation G arrives *after*
a packet with a compressed header with generation G. This case
is covered by rule b) ii) in section 9.
- A packet with a full header with generation G arrives *before* a packet with a compressed header with generation G-1 (modulo 64). The decompressor MAY then keep both versions of the context around for a while to be able to decompress subsequent compressed headers with generation G-1 (modulo 64). The old context MUST be discarded after MIN_WRAP seconds.
- 世代Gとの完全なヘッダを持つパケットは、前に到着* *生成と圧縮されたヘッダを有するパケットG-1（モジュロ64）。減圧装置は、次いで（モジュロ64）世代G-1とその後の圧縮ヘッダを解凍することができるようにしばらくコンテキストの両方のバージョンを保持することができます。古いコンテキストはMIN_WRAP秒後に捨てなければなりません。
A compressor may avoid sending COMPRESSED_TCP headers and only send COMPRESSED_TCP_NODELTA headers when there is reordering over the link. Compressed headers will typically be 17 octets with that method, significantly larger than the usual 4-7 octets.
コンプレッサーはCOMPRESSED_TCPヘッダを送信しないようし、リンクの上に並べ替えがある場合にのみCOMPRESSED_TCP_NODELTAヘッダを送信することができます。圧縮されたヘッダは、典型的には通常4-7オクテットより著しく大きいそのメソッドと17個のオクテットであろう。
To achieve better compression rates the following method, adding only two octets to the compressed header for a total of 6-9 octets, may be used. A packet sequence number, incremented by one for every packet in the TCP stream, is then associated with each compressed and full header. This allows the decompressor to place the packets in the correct sequence and apply their deltas to the context in the correct order. A simple sliding window scheme is used to place the packets in the correct order.
6-9オクテットの合計圧縮ヘッダにのみ2つのオクテットを追加すること、よりよい圧縮率を、以下の方法を達成するために、使用されてもよいです。 TCPストリーム内の各パケットに対して1つずつインクリメントパケットシーケンス番号は、各圧縮及びフルヘッダーに関連付けられています。これは、デコンプレッサは、正しい順序でパケットを配置し、正しい順序でコンテキストに自分のデルタを適用することができます。シンプルなスライディングウィンドウ方式は、正しい順序でパケットを配置するために使用されます。
Two octets are needed for the packet sequence numbers. One octet gives only 256 sequence numbers. In a sliding window scheme the window should be no larger than half of the sequence number space, so packets can not arrive more than 127 positions out-of-sequence. This is equivalent to a delay of 260 ms on 2 Mbit/s links with 512 octet segments. Delays of that order are not uncommon over wide-area Internet connections. However, two octets giving 2^16 = 65536 values should be sufficient.
2つのオクテットは、パケットシーケンス番号のために必要とされます。 1つのオクテットは256シーケンス番号を提供します。パケットは、アウトオブシーケンス127の以上の位置に到着することができないので、スライディングウィンドウ方式でウィンドウは、シーケンスナンバースペースの半分より大きくてはなりません。これは、512個のオクテットのセグメントを有する2 Mbit / sのリンク上の260ミリ秒の遅延に相当します。そのための遅延は、広域インターネット接続を介し珍しくありません。しかし、2 ^ 16 = 65536の値を与える2つのオクテットは十分なはずです。
Full TCP/IP headers will only have space for one octet of sequence number when there is no tunneling. It is not feasible to increase the size of full headers since the packet size might be optimized for the MTU of the link. Therefore only the least significant octet of the packet sequence number can be placed in such full headers. We believe that such full headers can be positioned correctly frequently enough with only the least significant octet of the packet sequence number available.
完全なTCP / IPヘッダなしのトンネルが存在しない場合にのみ、シーケンス番号の1つのオクテットのためのスペースを持っています。パケットサイズがリンクのMTUに合わせて最適化される可能性がありますので、完全なヘッダのサイズを大きくすることは不可能です。したがって、パケットシーケンス番号の唯一の最下位オクテットは、完全なヘッダーに配置することができます。私たちは、このような完全なヘッダが可能なパケットシーケンス番号の唯一の最下位オクテットで十分な頻度で正確に位置決めすることができると信じています。
The packet sequence number zero MUST be skipped over. Avoiding zero takes care of a problem that can occur when the TCP window scale option is used to enlarge the TCP window. When exactly 2^16 octets of TCP data is lost, a compressed header will be decompressed incorrectly without being detected by the TCP checksum. TCP segment sizes are often a power of two. So by using a packet sequence number space that is not a power of two either the TCP sequence number or the packet sequence number will differ when 2^16 octets are lost. Whenever a compressor sees the window scale option on a SYN segment, it MUST use packet sequence numbers when subsequently compressing that packet stream.
パケットシーケンス番号ゼロはスキップされなければなりません。ゼロを回避することは、TCPウィンドウスケールオプションは、TCPウィンドウを拡大するために使用されるときに発生することができ、問題の世話をします。 TCPデータの正確に2 ^ 16オクテットが失われると、圧縮されたヘッダは、TCPチェックサムによって検出されることなく、誤って解凍します。 TCPセグメントのサイズは、多くの場合、2つの力です。 2 ^ 16オクテットが失われたときにTCPシーケンス番号またはパケットシーケンス番号のいずれか2のべき乗でないパケットシーケンス番号空間を使用することによって異なります。コンプレッサーは、SYNセグメント上のウィンドウスケールオプションを見ているときはいつでも、その後そのパケットストリームを圧縮する際に、そのパケットのシーケンス番号を使用しなければなりません。
In compressed TCP headers the two octet packet sequence number MUST be placed immediately after the TCP Checksum. See section 5.3 for placement of packet sequence numbers in full headers.
圧縮されたTCPヘッダーの2つのオクテットのパケットシーケンス番号は、TCPチェックサムの直後に配置されなければなりません。完全なヘッダのパケットシーケンス番号を配置するためのセクション5.3を参照してください。
The following hook is supplied to allow additional header compression schemes for headers on top of UDP. The initial chain of subheaders is then compressed as described here, and the other header compression scheme is applied to the header above the UDP header. An example of such additional header compression is Compressed RTP by Casner and Jacobson [CRTP]. To allow some error detection, such schemes typically need a sequence number that may need to be passed in full headers as well as compressed UDP headers.
以下のフックは、UDPの上ヘッダーの追加ヘッダー圧縮スキームを可能にするために供給されます。ここに記載されるようサブヘッダの最初の鎖は、その後圧縮され、他のヘッダ圧縮方式は、UDPヘッダ、上記ヘッダに適用されます。このような追加のヘッダー圧縮の一例は、Casnerとヤコブソンによって圧縮RTP [CRTP]です。いくつかのエラー検出を可能にするために、そのようなスキームは、典型的には、完全なヘッダーならびに圧縮UDPヘッダーに渡される必要があるかもしれないシーケンス番号を必要とします。
The D-bit and Data octet (see section 6) provides the necessary mechanism. When a sequence number, say, needs to be passed in a FULL_HEADER or COMPRESSED_NON_TCP header, the D-bit is set and the sequence number is placed in the Data field. The decompressor must then extract and make the Data field available to the additional header compression scheme.
Dビットとデータオクテット（セクション6を参照）に必要な機構を提供します。シーケンス番号は、たとえば、FULL_HEADER又はCOMPRESSED_NON_TCPヘッダに渡される必要がある場合、Dビットがセットされ、シーケンス番号がデータフィールドに置かれます。デコンプレッサは、次いで抽出し、付加的なヘッダ圧縮スキームへのデータフィールドを利用できるようにしなければなりません。
Use of additional header compression schemes like CRTP must be negotiated. The D-bit and Data octet mechanism must automatically be enabled whenever use of additional header compression schemes has been negotiated.
CRTPのような追加のヘッダ圧縮スキームの使用が交渉しなければなりません。追加のヘッダ圧縮スキームの使用をネゴシエートされたときはいつでもDビットとデータオクテット機構が自動的に有効にしなければなりません。
For each link layer, there must be a document specifying how the various packet types used by IP header compression is indicated. Such a document exists for PPP [PPP-HC]. This section gives OPTIONAL guidelines on how packet types may be indicated by a specific link-layer.
各リンク層のために、IPヘッダ圧縮によって使用される様々なパケットタイプが指示される方法を指定する文書が存在しなければなりません。そのようなドキュメントは、PPP [PPP-HC]の必要性が存在します。このセクションでは、パケットタイプは、特定のリンク層によって示すことができる方法でオプションのガイドラインを提供します。
It is necessary to distinguish packets with regular IPv4 headers, regular IPv6 headers, full IPv6 packets, full IPv4 packets, compressed TCP packets, compressed non-TCP packets, and CONTEXT_STATE packets.
正規のIPv4ヘッダ、正規のIPv6ヘッダー、完全なIPv6パケット、完全なIPv4パケット、圧縮されたTCPパケット、圧縮された非TCPパケット、及びCONTEXT_STATEパケットでパケットを区別する必要があります。
The decision to use a distinct ethertype (or equivalent) for IPv6 has already been taken, which means that link-layers must be able to indicate that a packet is an IPv6 packet.
IPv6のための別個のイーサタイプ（または等価物）を使用するという決定は、既にリンク層パケットがIPv6パケットであることを示すことができなければならないことを意味し、撮影されています。
IP header compression requires that the link-layer implementation can indicate four kinds of packets: COMPRESSED_TCP for format a) in section 6, COMPRESSED_TCP_NODELTA for format b), COMPRESSED_NON_TCP for formats c) and d), and CONTEXT_STATE as described in section 11.2. It is also desirable to indicate FULL_HEADERS at the link layer.
IPヘッダ圧縮リンク層の実装は、パケットの四種類を示すことができることを必要とする：セクション11.2に記載されているようにフォーマットc）およびd）のために、）、セクション6）フォーマットAのCOMPRESSED_TCP COMPRESSED_NON_TCPをフォーマットBのCOMPRESSED_TCP_NODELTA、およびCONTEXT_STATE。リンク層でFULL_HEADERSを示すためにも望ましいです。
Full headers can be indicated by setting the first bit of the Version field in a packet indicated to be an IPv6 packet. In addition, one bit of the Version field is used to indicate if the first subheader is an IPv6 or an IPv4 header, and one bit is used to indicate if this full header carries a TCP CID or a non-TCP CID. The first four bits are encoded as follows:
完全なヘッダは、IPv6パケットであることを示すパケット内のバージョンフィールドの最初のビットを設定することによって示すことができます。また、バージョンフィールドの1ビットは、第サブヘッダがIPv6又はIPv4ヘッダであり、そして1ビットが、このフルヘッダがTCP CIDまたは非TCP CIDを運ぶかどうかを示すために使用されているかどうかを示すために使用されます。次のように最初の4ビットは符号化されます。
Version Meaning
------- -------
0110 regular IPv6 header
0110定期的なIPv6ヘッダ
1T*0 T=1 indicates a TCP header, T=0 indicates a non-TCP header 1*V0 V=1 indicates a IPv6 header, V=0 indicates a IPv4 header
1T * 0、T = 1は、TCPヘッダを示し、T = 0は、非TCPヘッダ1を示し* V0 V = 1は、IPv6ヘッダを示し、V = 0は、IPv4ヘッダを示し
If a link-layer cannot indicate the packet types for the compressed headers or CONTEXT_STATE, packet types that cannot be indicated could start with an octet indicating the packet type, followed by the header.
リンク層は、ヘッダに続くパケットタイプを示すオクテットで始まる可能性が示されることができない圧縮ヘッダまたはCONTEXT_STATE、パケットタイプのパケットタイプを示すことができない場合。
First octet Type of compressed header
----------- -------------------------
0 COMPRESSED_TCP
1 COMPRESSED_TCP_NODELTA
2 COMPRESSED_NON_TCP
3 CONTEXT_STATE
The currently assigned CONTEXT_STATE type values are
現在割り当てられてCONTEXT_STATE型の値は、
Value Type Reference
----- ----- ----------
0 Reserved -
1 IP/UDP/RTP w. 8-bit CID [CRTP]
2 IP/UDP/RTP w. 16-bit CID [CRTP]
3 TCP header request Section 10.2
Header compression parameters are negotiated in a way specific to the link-layer implementation. Such procedures for link-layer xxx needs to be specified in a document "IP header compression over xxx". Such a document exists for PPP [PPP-HC].
ヘッダ圧縮パラメータは、リンク層の実装に固有の方法で交渉されます。リンク層XXXのためのそのような手順は、文書「XXXオーバーIPヘッダ圧縮」で指定される必要があります。そのようなドキュメントは、PPP [PPP-HC]の必要性が存在します。
The following parameter is fixed for all implementations of this header compression scheme.
以下のパラメータは、このヘッダ圧縮スキームのすべての実装のために固定されています。
MIN_WRAP - minimum time of generation value wrap around
MIN_WRAP - 周りの世代の価値ラップの最小時間
3 seconds.
3秒。
The following parameters can be negotiated between the compressor and decompressor. If not negotiated their values must be as specified by DEFAULT.
以下のパラメータは、コンプレッサとデコンプレッサとの間で交渉することができます。交渉されていない場合、その値は、デフォルトで指定する必要があります。
F_MAX_PERIOD - Largest number of compressed non-TCP headers that may be sent without sending a full header.
F_MAX_PERIOD - フル・ヘッダを送信せずに送信することができる圧縮された非TCPヘッダーの最大数。
DEFAULT is 256
DEFAULTは256です
F_MAX_PERIOD must be at least 1 and at most 65535.
F_MAX_PERIODは、少なくとも1及び最大65535でなければなりません。
F_MAX_TIME - Compressed headers may not be sent more than F_MAX_TIME seconds after sending last full header.
F_MAX_TIME - 圧縮ヘッダは、前回の完全ヘッダを送信した後F_MAX_TIME秒以上に送信されないことがあります。
DEFAULT is 5
デフォルトは5です
F_MAX_TIME must be at least 1 and at most 255.
F_MAX_TIMEは、少なくとも1、最も255でなければなりません。
NOTE: F_MAX_PERIOD and F_MAX_TIME should be lower when it is likely that a decompressor loses its state.
注：解凍器がその状態を失う可能性があるときF_MAX_PERIODとF_MAX_TIMEは低くする必要があります。
MAX_HEADER - The largest header size in octets that may be compressed.
MAX_HEADER - 圧縮されてもよいオクテットで最大ヘッダサイズ。
DEFAULT is 168 octets, which covers
DEFAULTはカバーし、168オクテットであります
- Two IPv6 base headers
- A Keyed MD5 Authentication Header
- A maximum-sized TCP header
MAX_HEADER must be at least 60 octets and at most 65535 octets.
MAX_HEADERは、少なくとも60オクテットと最大で65535個のオクテットでなければなりません。
TCP_SPACE - Maximum CID value for TCP.
TCP_SPACE - TCPの最大CID値。
DEFAULT is 15 (which gives 16 CID values)
DEFAULTは、（16のCID値を与える）15であります
TCP_SPACE must be at least 3 and at most 255.
TCP_SPACEは、少なくとも3、多くて255でなければなりません。
NON_TCP_SPACE - Maximum CID value for non-TCP.
NON_TCP_SPACE - 非TCPの最大CID値。
DEFAULT is 15 (which gives 16 CID values)
DEFAULTは、（16のCID値を与える）15であります
NON_TCP_SPACE must be at least 3 and at most 65535.
NON_TCP_SPACEは、少なくとも3、65535、最大でなければなりません。
EXPECT_REORDERING - The mechanisms in section 11 are used.
EXPECT_REORDERING - セクション11内の機構が使用されます。
DEFAULT no.
デフォルトはありません。
A prototype using UDP as the link layer has been operational since March 1996. A NetBSD implementation for PPP has been operational since October 1996.
リンク層としてUDPを使用したプロトタイプは、PPPのためにNetBSDの実装は1996年10月以来、運用されている1996年3月以来稼動しています。
This protocol uses many ideas originated by Van Jacobson in the design of header compression for TCP/IP over slow-speed links [RFC-1144]. It has benefited from discussions with Stephen Casner and Carsten Bormann.
このプロトコルは、低速リンク[RFC-1144]上でTCP / IPのためのヘッダー圧縮の設計にヴァンヤコブソンによって発信多くのアイデアを使用しています。それはスティーブンCasnerとカルステンボルマンとの議論の恩恵を受けています。
We thank Craig Partridge for pointing out a problem that can occur when the TCP window scale option is used. A solution to this problem relying on the packet sequence numbers used for reordering is described in section 11.2.
私たちは、TCPウィンドウスケールオプションが使用されている場合に発生する可能性の問題を指摘するためにクレイグ・パートリッジに感謝します。並べ替えのために使用されるパケットのシーケンス番号に依存するこの問題に対する解決策は、セクション11.2に記載されています。
The compression protocols in this document run on top of a link-layer protocol. The compression protocols themselves introduce no new additional vulnerabilities beyond those associated with the specific link-layer technology being used.
この文書の圧縮プロトコルは、リンク層プロトコルの上で実行します。自身が使用されている特定のリンク層技術に関連するものを超えて新たな追加的な脆弱性を導入していない圧縮プロトコル。
Denial-of-service attacks are possible if an intruder can introduce (for example) bogus Full Header packets onto the link. However, an intruder having the ability to inject arbitrary packets at the link-layer in this manner raises additional security issues that dwarf those related to the use of header compression.
侵入者がリンク上に（例えば）偽のフルヘッダーパケットを導入することができた場合、サービス拒否攻撃が可能です。しかしながら、このように、リンク層での任意のパケットを注入する能力を有する侵入者は、ヘッダ圧縮の使用に関連するものを矮化追加のセキュリティ上の問題を提起します。
We advise implementors against identifying packet streams with the aid of information that is encrypted, even if such information happens to be available to the compressor. Doing so may expose traffic patterns.
私たちは、そのような情報は、圧縮機に利用可能であることを起こる場合でも、暗号化された情報を用いてパケットストリームを識別に対して実装者に助言します。そうすることで、トラフィックパターンを露出させることができます。
Mikael Degermark Department of Computer Science and Electrical Engineering Lulea University of Technology SE-971 87 Lulea, Sweden
コンピュータ科学と技術の電気工学ルーレオ大学SE-971 87ルーレオ、スウェーデンのミカエルDegermark部門
Phone: +46 920 91188 Fax: +46 920 72831 Mobile: +46 70 833 8933 EMail: micke@sm.luth.se
電話：+46 920 91188ファックス：+46 920 72831携帯電話：+46 70 833 8933 Eメール：micke@sm.luth.se
Bjorn Nordgren CDT/Telia Research AB Aurorum 6 S-977 75 Lulea, Sweden
ビョルンNordgren CDT /テリア研究AB Aurorum 6つのS-977 75ルーレオ、スウェーデン
Phone: +46 920 75400 Fax: +46 920 75490 EMail: bcn@lulea.trab.se, bcn@cdt.luth.se
電話：+46 920 75400ファックス：+46 920 75490 Eメール：bcn@lulea.trab.se、bcn@cdt.luth.se
Stephen Pink Department of Computer Science and Electrical Engineering Lulea University of Technology SE-971 87 Lulea, Sweden
コンピュータ科学と技術の電気工学ルーレオ大学SE-971 87ルーレオ、スウェーデンのステファン・ピンク部門
Phone: +46 920 752 29 Fax: +46 920 728 31 Mobile: +46 70 532 0007 EMail: steve@sm.luth.se
電話：+46 920 752 29ファックス：+46 920 728 31携帯：+46 70 532 0007 Eメール：steve@sm.luth.se
[RFC-768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC-768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC-791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC-793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC-793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC-1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC-1144]ヤコブソン、V.、 "圧縮TCP /低速シリアルリンクのIPヘッダ"、RFC 1144、1990年2月。
[RFC-1553] Mathur, A. and M. Lewis, "Compressing IPX Headers Over WAN Media (CIPX)", RFC 1553, December 1993.
[RFC-1553]マートゥル、A.およびM.ルイス、 "圧縮IPXヘッダオーバーWANメディア（CIPX）"、RFC 1553、1993年12月。
[RFC-1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html
[RFC-1700]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月を見る：http://www.iana.org/numbers.html
[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC-2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
[RFC-2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティプロトコル（ESP）"、RFC 2406、1998年11月。
[RFC-1828] Metzger, W., "IP Authentication using Keyed MD5", RFC 1828, August 1995.
[RFC-1828]メッツガー、W.、 "キー付きMD5を使用してIP認証"、RFC 1828、1995年8月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6の]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.", RFC 2463, December 1998.
【のICMPv6]コンタ、A.、およびS.デアリング、 "インターネットプロトコルバージョン6（IPv6）仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 2463、1998年12月。
[RFC-2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC-2004]パーキンス、C.、 "IP内の最小カプセル化"、RFC 2004、1996年10月。
[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ヘッダの圧縮"。
[PPP-HC] Engan, M., Casner, S. and C. Bormann, "IP Header Compression for PPP", RFC 2509, February 1999.
[PPP-HC] Engan、M.、Casner、S.及びC.ボルマン、 "PPP用のIPヘッダー圧縮"、RFC 2509、1999年2月。
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. .fi
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。 .fi