[要約] RFC 2507は、IPヘッダーの圧縮に関する標準化された手法を提供します。その目的は、ネットワークトラフィックの効率を向上させ、帯域幅の使用を最適化することです。
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
IPヘッダー圧縮
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。全著作権所有。
Abstract
概要
This document describes 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パケット/sで19.2 kbit/sを消費します。50パケット/sは、各パケットに20ミリ秒の音声サンプルを持つことに相当します。IPv4/UDPヘッダーは、50パケット/sで11.2 kbit/sを消費します。たとえば、モビリティをサポートするトンネルまたはルーティングヘッダーは、ヘッダーが消費する帯域幅を10-20 kbit/s増加させます。これは、たとえばGSMエンコーディングを伴う13 Kbit/sなど、実際のサウンドサンプルに必要な帯域幅と比較する必要があります。ヘッダー圧縮により、ヘッダーに必要な帯域幅が大幅に減少し、例では約1.7 kbit/sになります。これにより、14.4および28.8 kbit/sモデムを超える高品質の音声伝送が可能になります。
* 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
中速リンクを介したバルク転送用のTCPセグメントの一般的なサイズは、今日512オクテットです。たとえば、モバイルIPが使用されるため、TCPセグメントがトンネル化されている場合、IPv6/IPv6/TCPヘッダーは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.
オクテット。ヘッダー圧縮により、IPv6/TCPのヘッダーオーバーヘッドが19.5パーセントから1パーセント未満に減少し、Tunneled IPv4/TCPは11.7から1パーセント未満に減少します。これは、少数のMBIT/sと同じ高さのラインスピードにとって大きな利益です。
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仕様はPath MTU発見を規定するため、IPv6 Bulk TCPでは、可能な場合は512オクテットを超えるセグメントを使用する必要があります。それでも、1400個のオクテットセグメント（RFC 894イーサネットカプセル化により1500個のオクテットペイロードが可能になり、そのうち100個がIPヘッダーに使用されます）を使用すると、ヘッダー圧縮によりIPv6ヘッダーのオーバーヘッドが7.1％から0.4％に減少します。
* 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パケットの場合、Van Jacobson [RFC-1144]のメカニズムを使用して、損失から回復します。損失のあるリンク上のVJヘッダー圧縮の効率を高める2つの追加メカニズムについても説明します。非TCPパケットの場合、圧縮スロースタートと定期的なヘッダーリフレッシュにより、コンテキストを変更するヘッダーが失われた後、最小限のパケット破棄が可能になります。UDPの上にヘッダー圧縮スキームを追加するためのフック、たとえばRTPヘッダーの圧縮があります。
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.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
コンプレッサーがヘッダーを圧縮するために使用する状態と減圧装置は、ヘッダーを減圧するために使用します。コンテキストは、圧縮ヘッダーに「AS-IS」が含まれている、またはサイズから推測できるヘッダー内のフィールドを除き、リンク上に送信された最後のヘッダー（コンプレッサー）または受信（減圧器）の非圧縮バージョンです。リンクレベルのフレームの。
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.
非TCPパケットストリームの場合、特定のCIDのコンテキストの新しいバージョンの各バージョンは、世代に関連付けられています。その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
IPv6は、損傷したパケットのかなりの部分をIPv6モジュールに提供できるリンクを介して使用することを意図していません。これは、リンクが非常に低いビットエラーレートを持っている必要があるか、リンクレベルのフレームが強力なチェックサム、フォワードエラー修正、またはその性質の何かによって保護される必要があることを意味します。ヘッダー圧縮は、強力なリンクレベルのチェックサムなしでIPv4に使用しないでください。破損
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.
したがって、フレームはリンクレイヤーによって破棄されます。リンクレイヤーの実装は、ヘッダー圧縮モジュールにフレームが損傷していることを示している可能性がありますが、損傷している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.
Full_Header- CIDやTCPパケットではないにしても、生成を含む非圧縮ヘッダーを備えたパケットを示します。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を含む圧縮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パケットが使用されます。追加のパケットタイプを使用して、Decompressorがコンプレッサーにパケットを送信できるリンク上の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.
Context_State-分解器からコンプレッサーに送信された特別なパケットを示して、同期が失われた（TCP）CIDのリストを通信します。このパケットは単一のリンクにのみ送信されるため、IPヘッダーは必要ありません。形式はセクション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ヘッダーは、TCPチェックサムがもっともらしいKのシーケンス番号の「オフバイk」エラーを確実にキャッチするため、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パケットほどチェックサムによってそれほどよく保護されていません。「Off-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]など、他の圧縮スキームで使用されるコンプレッサーと減圧器間のメッセージの交換を回避します。このような交換は、送信機によってより多くの電力が消費され、送信と受信の間を切り替えることで遅延を導入できるため、ワイヤレスモバイルには費用がかかります。さらに、メッセージの交換を必要とする手法は、直接ブロードキャスト衛星チャネルやケーブルTVシステムなど、シンプレックスリンクを介して使用することはできず、マルチアクセスリンクを介したマルチキャストに適応するのは困難です。
|.|..|....|........|................|..............................
^
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は、圧縮スロースタート中にフルヘッダーが送信されるたびに2倍になります。
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.
C_NUM-最後のフルヘッダーが送信されてから送信される圧縮ヘッダーの数のカウント。f_last-最後のフルヘッダーを送信する時間。
and uses the functions
関数を使用します
current_time() return the current time min(a,b) return the smallest of a and b
current_time（）現在の時間を返すmin（a、b）最小のaと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> )
if（<このヘッダーはコンテキストを変更します>）
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 )
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'thパケットがフルヘッダーを持ち、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の場合、平均ヘッダーサイズは（H-C）/Fが圧縮ヘッダーよりも大きいです。
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の典型的なサイズの場合、フルヘッダー（IPv6/UDP）の場合は48オクテット、圧縮ヘッダーの4オクテットは48オクテットで、F_MAX_PERIOD> 44を設定すると、フルヘッダーが平均ヘッダーサイズにオクテット未満を貢献することを意味します。4-Addressルーティングヘッダーでは、F_MAX_PERIOD> 115が同じ効果をもたらします。
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およびC = 4の場合、平均ヘッダーサイズに1.5オクテットを寄付します。20ms音声サンプルでは、フルヘッダーが平均ヘッダーサイズに1オクテット未満になるまで1.3秒未満かかります。、そしてこれらの最初の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つの完全なヘッダーといくつかの制御メッセージを送信します。ハードステートスキームでは、より多くの種類のプロトコルメッセージが必要であり、メッセージの交換が必要です。また、ハードステートスキームは、ソフトステートが自動的に処理するさまざまなエラー条件、たとえば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
グループ化はコンプレッサーによって行われます。コンプレッサーは、パケットをパケットストリームにグループ化するのに適していると思われる基準を使用する場合があります。パケットが属するパケットストリームを決定するために、コンプレッサーは
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.
d) たとえば、パケットストリームのルートフラップとホップ制限（TTL）フィールドがNとN Kの間で頻繁に変化する場合、その他の関連情報を使用してください。コンプレッサーは、パケットを2つの異なるパケットストリームにグループ化することを選択できます。
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パケットストリームのフルヘッダーをいつ送信するかについてのルールが続き、このドキュメントで指定されているようにサブヘッダーが圧縮されている限り、packetsストリームにパケットをグループ化する方法に関係なく、圧縮ヘッダーを正しく再構築できます。
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.
ヘッダーの定義フィールドは、同じパケットストリームに属するすべてのパケットで存在し、同一である必要があります。これらのフィールドはセクション7でDEFとマークされています。定義フィールドには、フローラベル、IPヘッダーのソース、および宛先アドレス、ルーティングヘッダーの最終宛先アドレス、次のヘッダーフィールド（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で説明されていないヘッダーを識別する最初の次のヘッダーフィールドは、パケットストリームの識別に使用する必要があります。つまり、同じ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の8ビットCIDと値2の16ビット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スペースが2倍になります。フルヘッダーまたは圧縮ヘッダーがTCPパケットまたは非TCPパケット用であるかどうかを常に伝えることができるため、混合は発生しません。
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ヘッダーには、IPヘッダーで少なくとも2つのオクテットが利用可能になり、8ビットCIDを渡すことができます。複数の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]は、IPv4ヘッダーの8ビットプロトコルフィールドを使用してCIDに合格します。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に合格するために4つのオクテットが利用できるため、すべてのCIDサイズを使用できます。断片化または暗号化されたパケットストリームには、生成と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番目の長さフィールドに通過し、最初の長さフィールドの低いオーダーオクテットは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.
最初の長さフィールドの最初のビットは、CIDの長さを示します。Dがゼロの場合、データフィールドはゼロです。Dビットとデータフィールドの使用については、セクション12で説明します。
This section uses some terminology (DELTA, RANDOM) defined in section 7.
このセクションでは、セクション7で定義されている用語（デルタ、ランダム）を使用します。
a) COMPRESSED_TCP format (similar to [RFC 1144]):
a) Compressed_tcp形式（[RFC 1144]に類似）：
+-+-+-+-+-+-+-+-+
| 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.
TCPセグメントがIPv6またはIPv4によって運ばれるかどうかにかかわらず、2番目のオクテット（IPSAWU）の後者フラグは[RFC-1144]と同じ意味を持っています。CIDが常に存在するため、Cビットは排除されました。CIDに関連付けられたコンテキストは、IPバージョンとランダムフィールドが存在するものを追跡します。ここで指定されているデルタフィールド間の順序は、[RFC-1144]とまったく同じです。実装は通常、最初からコンテキストをスキャンし、ランダムフィールドを順番に挿入します。したがって、ランダムフィールドは、元の非圧縮ヘッダーで発生するのと同じ順序で、TCPヘッダーのデルタフィールドの前に配置されます。
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.
Iフラグは、TCPヘッダーの直前のIPv4ヘッダーがない限りゼロです。[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フラグが設定されている場合、TCPヘッダーのコンテキストと予約フィールド（6ビット）またはIPv4ヘッダー（IPv6ヘッダー）のTOSオクテット（トラフィッククラスOctet）のビット6または7の間に違いがありました。TCPヘッダー。予約済みフィールドの実際の値とTOSまたはトラフィッククラスフィールドのビット6および7のオクテットは、ランダムフィールドの直後に配置されます。合格したオクテットのビット0〜5は、予約済みフィールドの実際の値であり、ビット6と7は、TOSまたはトラフィッククラスフィールドのビット6および7の実際の値です。前のIPヘッダーがない場合、ビット6と7は0です。Rフラグで通過したオクテットは、コンテキストを更新してはなりません。
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.
注：R-OCTETはコンテキストを更新しません。なぜなら、もしそうなら、NTCPチェックサムは誤って減圧されたヘッダーから受信TCPを守らないためです。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.
どちらが短いチェーンを与えますか。たとえば、ルールa）および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.
ノチェンジフィールドは変更されるとは予想されていません。変更は、コンテキストを更新するために完全なヘッダーを送信する必要があることを意味します。
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.
デルタフィールドは頻繁に変化する可能性がありますが、通常、前のヘッダーのフィールドとの違いは小さいため、現在の値ではなく以前の値から変更を送信する方が安くなります。このタイプの圧縮は、TCPパケットストリームにのみ使用されます。
RANDOM The field must be included "as-is" in compressed headers, usually because it changes unpredictably.
ランダムに、フィールドは圧縮ヘッダーに「AS-IS」を含める必要があります。これは通常、予測不可能に変化するためです。
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.
フィールドには、他の値から推測できる値、たとえばパケットを運ぶフレームのサイズが含まれているため、圧縮ヘッダーに含めてはなりません。
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.
分類は、圧縮ヘッダーの構築方法を意味します。ノチェンジまたは推測されるフィールドは、圧縮ヘッダーに存在しません。コンプレッサーは、圧縮識別子によって識別されたコンテキストからノチェンジフィールドの値を取得し、リンク層フレームのサイズ、例えば他のフィールドから、リンク層実装から推定されたフィールドの値を取得します。IPv4ヘッダーチェックサムを再計算することにより。デルタフィールドは、同じパケットストリームの以前のパケットの値の差としてエンコードされます。減圧装置は、圧縮ヘッダーの値をそのコンテキストの値に追加することにより、コンテキストを更新する必要があります。結果は、フィールドの適切な値です。ランダムフィールドは、圧縮ヘッダーに「AS-IS」を送信する必要があります。ランダムフィールドは、フルヘッダーで発生するのと同じ順序で圧縮ヘッダーで発生する必要があります。
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.
オプションで使用されるフィールドは、セクション4.1に従って、パケットが属するパケットストリームを識別して、DEFという単語でマークされています。セクション4.1のオプションのガイドラインを使用したコンプレッサーに、2つのパケット間の対応する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)
バージョン（def）トラフィッククラスのnochange（def、seect 4.1を参照）（セクト6 aも参照）フローラベルノチェンジ（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ヘッダーの場合、圧縮されたTCPヘッダーのRフラグを使用してトラフィッククラスフィールドのビット7を渡すことができます。セクション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エクステンションヘッダーの次のヘッダーフィールドはすべてノチェンジです。
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.
オプションタイプおよびOPTデータレンフィールドは、特定のパケットストリームに対して固定されていると想定されるため、それらはnochangeとして分類されます。オプションデータは、以下で特に指定されていない限り、ランダムです。
Padding
パディング
Pad1 option
PAD1オプション
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Entire option is NOCHANGE.
オプション全体はnochangeです。
PadN option
PADNオプション
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
All fields are NOCHANGE.
すべてのフィールドはノチェンジです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header NOCHANGE Hdr Ext Len NOCHANGE
次のヘッダーnochange HDR ext len 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つのフィールドは、ノチェンジとジャンボペイロードの長さが推測されます。（フレームの長さは、リンクレイヤーの実装によって提供する必要があります）。
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.
ルーティングヘッダーのすべてのフィールドはノチェンジです。
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ルーティングヘッダーでは、最後のアドレスはdef（セグメントが左> 0）です。
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オクテットであるため、これは大きな勝利です。さらに、1つのアドレス、サイズ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.
少なくとも最初のフラグメントでは、フラグメントヘッダーの後にサブヘッダーを圧縮できる圧縮スキームを設計することができますが、フルヘッダーを送信するためのルールと圧縮と減圧のルールを複雑にするためには、フラグメントヘッダーに従うサブヘッダーのチェーンを複雑にしないでください圧縮してはいけません。
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
次のヘッダーnochange予約済みnochange resランダムmフラグランダムフラグメントオフセットランダム識別ランダム
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オクテットまで圧縮されることを意味します。最小IPv6 MTUは1280オクテットであるため、ほとんどのフラグメントは少なくとも1280オクテットになります。圧縮フラグメントヘッダーの6オクテットのオーバーヘッドは、かなり大きなパケットに償却されるため、より洗練された圧縮スキームの追加の複雑さは正当化できません。
NOTE: The Identification field is RANDOM instead of NOCHANGE to avoid one compression slow-start per original packet.
注：識別フィールドは、元のパケットごとに1つの圧縮スロースタートを回避するために、ノチェンジの代わりにランダムです。
Grouping of fragments according to the optional guidelines in section4.1:
セクション4.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の使用が回避され、関連する圧縮スロースタートのコストが節約されます。スラッシングが発生する可能性がある場合、ヘッダーのfragent的な部分はあまり頻繁に変化しないことを期待しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header NOCHANGE Hdr Ext Len NOCHANGE
次のヘッダーnochange HDR ext len 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
次のヘッダーnochange長nochange予約済みノチェンジSPIノチェンジ（def）認証データランダム
[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）不透明な変換データランダム
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.
ソースポートノチェンジ（def）宛先ポートノチェンジ（def）長さは、ゼロでない限り、ゼロでない限り推測されたチェックサムを推測します。
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ヘッダーの長さフィールドは、前のサブヘッダーの長さフィールドと一致する必要があります。つまり、UDPペイロード後にIPの長さで覆われたパディングはありません。
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ヘッダーは通常、UDPチェックサムである2オクテットに圧縮されます。UDPチェックサムがゼロ（IPv6では存在できない）の場合、フロー内のすべてのパケットに対してそうである可能性が高く、ノチェンジと定義されています。これにより、圧縮ヘッダーに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、およびfinを表します。
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)
ソースポートノチェンジ（def）宛先ポートノチェンジ（def）シーケンス番号デルタ承認番号デルタオフセットノチェンジ予約デルタ（コンテキストとは異なる場合は、フラグオクテットのr-flagを設定し、6 aに記載されている絶対値を送信します。）urg、pshランダム（旗のオクテットに配置）ACKは1回目であると推測されます、syn、Finは0ウィンドウデルタ（窓の変更、flagオクテットにw-flagを設定して差を送信）チェックサムランダムな緊急ポインターデルタ（urgが設定されている場合、絶対値を送信）オプション、パディングデルタ（オプションの変更の場合、O-Flagを設定してオプション全体を送信し、パディング）
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-FLAGの使用、R-の使用です。フラグ、およびc-flagの排除。O-FLAGは、タイムスタンプオプションが使用され、各ヘッダーでオプションフィールドが変更されると、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-Flagで渡された予約済みのフィールド値は、コンプレッサーまたは減圧器のコンテキストを更新してはなりません。
Source Port NOCHANGE (DEF) Destination Port NOCHANGE (DEF)
ソースポートノチェンジ（def）宛先ポートノチェンジ（def）
(all the rest) 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) IPv4ヘッダーがフラグメント用ではない場合（MFフラグが設定されておらず、フラグメントオフセットがゼロである）、オプションがありません（IHLは5）、次のように分類されます
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)
バージョンnochange（def）ihl nochange（def、be must be）service nochange（def、sect 4.1を参照）
Identification DELTA/ (If the Protocol field has the (value corresponding to TCP) RANDOM (otherwise)
識別delta/（プロトコルフィールドに（TCPに対応する値）ランダム（それ以外の場合）がある場合
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)
Flags nochange（MFフラグを設定しないでください）フラグメントオフセットノチェンジ（ゼロである必要があります）ライブノチェンジまでの時間（def、sect 4.1を参照）プロトコルノチェンジヘッダーチェックサムが推測されます（他のフィールドから計算）ソースアドレスnochange（def）宛先アドレス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で説明されているように、IPv4およびTCPヘッダーをユニットとして圧縮する必要があります。r-flagを使用します（セクション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）がある場合、すべてのフィールドがランダムになります（つまり、ヘッダーが圧縮されている場合、すべてのフィールドはISで送信され、圧縮されません。）。この分類により、フラグメントがトンネル化されている場合、フラグメントヘッダーではなく、トンネルヘッダーの圧縮が可能になります。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.
セクション4.1のオプションのガイドラインに従うコンプレッサーは、a）バージョン、ソースアドレス、および宛先アドレスを使用して、IPv4オプションがなく、これがフラグメントではないという事実とともに、パケットストリームを定義します。
Case b) can define two kinds of packet streams depending on whether the IPv4 header is for a fragment or not.
ケースb）IPv4ヘッダーがフラグメント用かどうかに応じて、2種類のパケットストリームを定義できます。
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)
Protocol nochange Original Source Address Present（s）Nochange Reserved Nochange Headerチェックサム推測（他の値から計算）元の宛先アドレスNochange元のソースアドレスnochange（s = 1の場合のみ存在）
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がPacketストリームが自由に使用または再利用するものを変更する可能性があります。
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に関連付けられた生成値を新しいパケットストリームに変更するときにリセットしてはなりません。代わりに、CIDを新しい非TCPパケットストリームに使用する場合、コンプレッサーは生成値を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) コンプレッサーは、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
i) すぐに廃棄されます
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.
ii）CID Cと生成Gを備えた完全な非TCPヘッダーを備えたパケットによってコンテキストが更新されるまで一時的に保存され、その後、ヘッダーを解凍できます。
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以外のA世代を使用してフルまたは圧縮された非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）dedypompressorは、正しいコンテキストを使用して減圧できるようになるまで、そのようなヘッダーを保存できます。
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 Mbit/sワイヤレスLANと200 msのエンドツーエンドのRTTの場合、遅延帯域幅製品は50 kbyteです。これは、圧縮ヘッダーを備えた約97 512-OCTETセグメントに相当します。したがって、各損失に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メカニズムが遅れているため、成功率は小さくなります。「2回」メカニズムは、確認ストリームの損失の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確認ストリームの「2回」アルゴリズムの成功率が比較的低いため、減圧器でコンテキストを修復するための追加のメカニズムが必要です。減圧器が損失後にコンテキストの修復に失敗した場合、減圧器はオプションでコンプレッサーから完全なヘッダーを要求する場合があります。これは、減圧器がコンプレッサーを識別してパケットを送信できるリンクで可能です。
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.
このようなリンクでは、DecompressorがContext_Stateパケットをコンプレッサーに戻し、1つ以上のコンテキストが無効であることを示す場合があります。減圧器は、圧縮されたパケットが無効なコンテキストを指すたびにContext_Stateパケットを送信しないでください。代わりに、逆チャネルの洪水を避けるためにContext_Stateパケットの送信率を制限する必要があります。Context_Stateパケットは、いくつかのコンテキストが古くなっていることを示すことができます。この手法は、いくつかの個別のパケットを送信する代わりに使用する必要があります。次の図は、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パケットを受け取ったとき、コンプレッサーはCIDSを無効にマークして、これらのパケットストリームで放出された次のパケットがFull_headerまたはCompressed_tcp_nodeltaパケットであることを確認する必要があります。
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.
- Generation Gの完全なヘッダーを備えたパケットが到着します * Generation Gの圧縮ヘッダーを備えたパケットの後に *到着します。このケースは、ルールb）ii）セクション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.
- Generation Gのフルヘッダーを備えたパケットが到着します。減圧装置は、ジェネレーションG-1（Modulo 64）で後続の圧縮ヘッダーを減圧できるように、しばらくの間、両方のバージョンをコンテキストの周りに保持できます。古いコンテキストは、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ヘッダーを送信する場合があります。圧縮ヘッダーは通常、その方法で17オクテットで、通常の4〜7オクテットよりも大幅に大きくなります。
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
フルTCP/IPヘッダーには、トンネリングがない場合、シーケンス番号の1オクテットのスペースのみがあります。パケットサイズがリンクのMTUに最適化される可能性があるため、フルヘッダーのサイズを増やすことは不可能です。したがって、パケットシーケンス番号の最も重要なオクテットのみをそのような完全なヘッダーに配置できます。我々は信じている
that such full headers can be positioned correctly frequently enough with only the least significant octet of the packet sequence number available.
このような完全なヘッダーは、利用可能なパケットシーケンス番号の最も重要なオクテットのみで十分に頻繁に正しく配置できること。
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ヘッダーでは、TCPチェックサムの直後に2つのOctetパケットシーケンス番号を配置する必要があります。フルヘッダーのパケットシーケンス番号の配置については、セクション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とJacobson [CRTP]による圧縮RTPです。エラーの検出を可能にするために、そのようなスキームには通常、フルヘッダーと圧縮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-BITおよびデータのオクテットメカニズムを自動的に有効にする必要があります。
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に異なるEtherType（または同等）を使用するという決定はすでに採取されています。つまり、リンク層がパケットが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ヘッダー圧縮では、リンク層の実装が4種類のパケットを示すことが必要です。フォーマットa）のcompressed_tcp、セクション6、形式b）、d）、d）、およびdinked_non_tcp format b format b format b format b format bのcompressed_non_tcp。また、リンクレイヤーで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パケットであることが示されたパケットにバージョンフィールドの最初のビットを設定することで示すことができます。さらに、最初のサブヘッダーがIPv6またはIPv4ヘッダーであるかどうかを示すためにバージョンフィールドの1つを使用し、このフルヘッダーにTCP CIDまたは非TCP CIDがあるかどうかを示すために1ビットを使用します。最初の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
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
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
デフォルトは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
デフォルトは168オクテットで、カバーしています
- Two IPv6 base headers - A Keyed MD5 Authentication Header - A maximum-sized TCP header
- 2つのIPv6ベースヘッダー - キー付きMD5認証ヘッダー - 最大サイズのTCPヘッダー
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)
デフォルトは15です（16個のCID値が得られます）
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)
デフォルトは15です（16個のCID値が得られます）
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を使用するプロトタイプは、1996年3月以来運用されています。PPPのNetBSD実装は、1996年10月以来運用されています。
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.
このプロトコルは、ゆるいスピードリンクを介したTCP/IPのヘッダー圧縮の設計において、Van Jacobsonが起源とする多くのアイデアを使用しています[RFC-1144]。Stephen CasnerとCarsten Bormannとの議論の恩恵を受けています。
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ウィンドウスケールオプションを使用したときに発生する可能性のある問題を指摘してくれたCraig Partridgeに感謝します。並べ替えに使用されるパケットシーケンス番号に依存するこの問題の解決策は、セクション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
Mikael Degermarkコンピュータサイエンスおよび電気工学部Lulea Technology SE-971 87 Lulea、Sweden
Phone: +46 920 91188
Fax: +46 920 72831
Mobile: +46 70 833 8933
EMail: micke@sm.luth.se
Bjorn Nordgren CDT/Telia Research AB Aurorum 6 S-977 75 Lulea, Sweden
Bjorn Nordgren CDT/Telia Research Ab Aurorum 6 S-977 75 Lulea、Sweden
Phone: +46 920 75400
Fax: +46 920 75490
EMail: 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
[RFC-768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC-768] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC-791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC-793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC-793] Postel、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] Jacobson、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] Mathur、A。およびM. Lewis、「WAN Media（CIPX）にIPXヘッダーを圧縮する」、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-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] Kent、S。およびR. Atkinson、「IP Cankupsing Security Protocol（ESP）」、RFC 2406、1998年11月。
[RFC-1828] Metzger, W., "IP Authentication using Keyed MD5", RFC 1828, August 1995.
[RFC-1828] Metzger、W。、「Keyed MD5を使用したIP認証」、RFC 1828、1995年8月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering、S。and R. Hinden、「Internet Protocol、バージョン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] Conta、A。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）。」、RFC 2463、1998年12月。
[RFC-2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC-2004] Perkins、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. Jacobson、「低速シリアルリンク用のIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[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. Bormann、「PPPのIPヘッダー圧縮」、RFC 2509、1999年2月。
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明するか、その実装を支援する派生作品は、いかなる種類の制限なしに、準備、コピー、公開、配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準のプロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. .fi
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。.fi