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
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.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. The methods can be applied to of IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers.
本文档描述了如何在点到点链路上每跳压缩多个IP头以及TCP和UDP头。这些方法可以应用于IPv6基本头和扩展头、IPv4头、TCP和UDP头以及封装的IPv6和IPv4头。
Headers of typical UDP or TCP packets can be compressed down to 4-7 octets including the 2 octet UDP or TCP checksum. This largely removes the negative impact of large IP headers and allows efficient use of bandwidth on low and medium speed links.
典型UDP或TCP数据包的头可以压缩到4-7个八位字节，包括2个八位字节的UDP或TCP校验和。这在很大程度上消除了大型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
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
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个八位字节）消耗19.2 kbit/s，数据包速率为50个数据包/s。50包/秒相当于每个包中有20毫秒的语音样本。IPv4/UDP报头以50个数据包/秒的速度消耗11.2 kbit/s。例如，支持移动性的隧道或路由报头将使报头消耗的带宽增加10-20 kbit/s。这应与实际声音样本所需的带宽进行比较，例如13 kbit/s的GSM编码。在本例中，报头压缩可以将报头所需的带宽显著降低到约1.7kbit/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个八位字节。当TCP段被隧道化时，例如因为使用了移动IP，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%，隧道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规范规定了路径MTU发现，因此IPv6批量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.
由于每个数据包发送的比特数较少，因此对于给定的误码率，数据包丢失率将较低。这导致TCP的吞吐量更高，因为发送窗口可以打开更多的丢失间隔，并且UDP的丢失数据包更少。
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报头压缩效率的机制。对于非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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
Subheader
副标题
An IPv6 base header, an IPv6 extension header, an IPv4 header, a UDP header, or a TCP header.
IPv6基本标头、IPv6扩展标头、IPv4标头、UDP标头或TCP标头。
Header
标题
A chain of subheaders.
一连串的副标题。
Compress
压紧
The act of reducing the size of a header by removing header fields or reducing the size of header fields. This is done in a way such that a decompressor can reconstruct the header if its context state is identical to the context state used when compressing the header.
通过删除报头字段或减小报头字段的大小来减小报头大小的行为。这是以这样的方式完成的：如果解压器的上下文状态与压缩头时使用的上下文状态相同，则解压器可以重构头。
Decompress
减压
The act of reconstructing a compressed header.
重建压缩头的动作。
Context identifier (CID)
上下文标识符（CID）
A small unique number identifying the context that should be used to decompress a compressed header. Carried in full headers and compressed headers.
一个小的唯一数字，标识应用于解压缩压缩头的上下文。在完整标题和压缩标题中携带。
Context
上下文
The state which the compressor uses to compress a header and the decompressor uses to decompress a header. The context is the uncompressed version of the last header sent (compressor) or received (decompressor) over the link, except for fields in the header that are included "as-is" in compressed headers or can be inferred from, e.g., the size of the link-level frame.
压缩器用于压缩标头和解压缩器用于解压缩标头的状态。上下文是通过链接发送（压缩器）或接收（解压缩器）的最后一个报头的未压缩版本，但报头中的字段除外，这些字段包括在压缩报头中的“原样”字段中，或者可以从例如链接级别帧的大小推断出来。
The context for a packet stream is associated with a context identifier. The context for non-TCP packet streams is also associated with a generation.
分组流的上下文与上下文标识符相关联。非TCP数据包流的上下文也与生成关联。
Generation
一代
For non-TCP packet streams, each new version of the context for a given CID is associated with a generation: a small number that is incremented whenever the context associated with that CID changes. Carried by full and compressed non-TCP headers.
对于非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.
数据包流中预期为常量的字段中的任何更改都将导致压缩器再次发送完整的报头以更新解压器处的上下文。只要compressor和decompressor的上下文相同，就可以将头解压缩为压缩之前的样子。但是，如果在传输过程中丢失了完整标头或压缩标头，则解压器的上下文可能会因未正确更新而过时。然后，压缩的标题将被错误地解压缩。
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数据包类型外，此压缩方法还使用四种数据包类型。链路级分组类型和分组的前四位的值的组合唯一地确定分组类型。有关如何表示这些数据包类型的详细信息，请参见第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_头-表示具有未压缩头的数据包，包括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-表示具有压缩TCP标头的数据包，其中包含一个CID、一个标识已更改字段的标志八位字节，以及编码为与上一个值不同的已更改字段。
COMPRESSED_TCP_NODELTA - indicates a packet with a compressed TCP header where all fields that are normally sent as the difference to the previous value are instead sent as-is. This packet type is only sent as the response to a header request from the decompressor. It must not be sent as the result of a retransmission.
COMPRESSED_TCP_NODELTA-表示具有压缩TCP报头的数据包，其中所有通常作为与上一个值的差异发送的字段改为按原样发送。此数据包类型仅作为对来自解压缩器的报头请求的响应发送。它不能作为重新传输的结果发送。
In addition to the packet types used for compression, regular IPv4 and IPv6 packets are used whenever a compressor decides to not compress a packet. An additional packet type may be used to speed up repair of TCP streams over links where the decompressor can send packets to the compressor.
除了用于压缩的数据包类型外，每当压缩器决定不压缩数据包时，都会使用常规IPv4和IPv6数据包。额外的分组类型可用于加速链路上TCP流的修复，其中解压器可向压缩器发送分组。
CONTEXT_STATE - indicates a special packet sent from the decompressor to the compressor to communicate a list of (TCP) CIDs for which synchronization has been lost. This packet is only sent over a single link so it requires no IP header. The format is shown in section 10.2.
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校验和可靠地捕捉到似是而非的k的序列号中的“off-by-k”错误，TCP接收器将丢弃这种错误解压缩的TCP报头。
TCP's repair mechanisms will eventually retransmit the discarded segment and the compressor peeks into the TCP headers to detect when TCP retransmits. When this happens, the compressor sends a full header on the assumption that the retransmission was due to mismatching compression state at the decompressor. [RFC-1144] has a good explanation of this mechanism.
TCP的修复机制最终将重新传输丢弃的段，压缩器将窥视TCP头以检测TCP何时重新传输。发生这种情况时，压缩器发送一个完整的报头，前提是重传是由于解压缩器处的压缩状态不匹配造成的。[RFC-1144]很好地解释了这一机制。
The mechanisms of section 10 should be used to speed up the repair of the context. This is important over medium speed links with high packet loss rates, for example wireless. Losing a timeout's worth of packets due to inconsistent context after each packet lost over the link is not acceptable, especially when the TCP connection is over the wide area.
应使用第10节的机制加快修复上下文。这在具有高丢包率的中速链路上非常重要，例如无线链路。在链路上丢失每个数据包后，由于上下文不一致而丢失超时值的数据包是不可接受的，尤其是当TCP连接在广域上时。
Incorrectly decompressed headers of UDP packets and other non-TCP packets are not so well-protected by checksums as TCP packets. There are no sequence numbers that become "off-by-k" and virtually guarantees a failed checksum as there are for TCP. The UDP checksum only covers payload, UDP header, and pseudo header. The pseudo header includes the source and destination addresses, the transport protocol type and the length of the transport packet. Except for those fields, large parts of the IPv6 header are not covered by the UDP checksum. Moreover, other non-TCP headers lack checksums altogether, for example fragments.
UDP数据包和其他非TCP数据包的错误解压头不像TCP数据包那样受到校验和的良好保护。没有变为“off-by-k”的序列号，实际上保证了失败的校验和，就像TCP一样。UDP校验和仅涵盖有效负载、UDP报头和伪报头。伪报头包括源地址和目的地址、传输协议类型和传输包的长度。除了这些字段外，UDP校验和不覆盖IPv6报头的大部分。此外，其他非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秒的时间后重新使用相同的生成值。已断开连接的解压器必须等待下一个完整标头，然后才能解压。在压缩非TCP头之前，压缩器必须在引导后至少等待MIN_WRAP秒。压缩器可能会切换到另一个CID或发送常规标头，直到过了MIN_WRAP秒，而不是过早地重用生成值。MIN_WRAP的值见第14节。
To allow the decompressor to recover quickly from loss of a full header that would have changed the context, full headers are sent periodically with an exponentially increasing period after a change in the context. This technique avoids an exchange of messages between compressor and decompressor used by other compression schemes, such as in [RFC-1553]. Such exchanges can be costly for wireless mobiles as more power is consumed by the transmitter and delay can be introduced by switching between sending and receiving. Moreover, techniques that require an exchange of messages cannot be used over simplex links, such as direct-broadcast satellite channels or cable TV systems, and are hard to adapt to multicast over multi-access links.
为了使解压器能够从丢失会改变上下文的完整头中快速恢复，在上下文发生变化后，完整头会以指数增长的周期定期发送。这种技术避免了其他压缩方案（如[RFC-1553]中）使用的压缩器和解压缩器之间的消息交换。这种交换对于无线移动设备来说可能是昂贵的，因为发射机消耗更多的功率，并且发送和接收之间的切换可能会引入延迟。此外，需要交换消息的技术不能在单工链路上使用，例如直接广播卫星频道或有线电视系统，并且很难适应多址链路上的多播。
|.|..|....|........|................|..............................
^
Change Sent packets: | with full header, . with compressed header
|.|..|....|........|................|..............................
^
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_周期压缩头后，将发送完整头。在压缩缓慢启动期间，每次发送完整报头时，F_周期加倍。
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_时间秒，则必须发送完整报头。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数据包流的完整报头。代码维护两个变量：
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> )
如果（<此标题更改上下文>）
C_NUM := 0;
F_LAST := current_time();
F_PERIOD := 1;
increment_generation_value();
send_full_header();
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_周期）
C_NUM := 0;
F_LAST := current_time();
F_PERIOD := min(2 * F_PERIOD, F_MAX_PERIOD);
send_full_header();
C_NUM := 0;
F_LAST := current_time();
F_PERIOD := min(2 * F_PERIOD, F_MAX_PERIOD);
send_full_header();
elseif ( current_time() > F_LAST + F_MAX_TIME )
elseif ( current_time() > F_LAST + F_MAX_TIME )
C_NUM := 0;
F_LAST := current_time();
send_full_header();
C_NUM := 0;
F_LAST := current_time();
send_full_header();
else
其他的
C_NUM := C_NUM + 1
send_compressed_header();
C_NUM := C_NUM + 1
send_compressed_header();
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_周期应选择为曲线膝盖右侧的频率井。对于H和C的典型大小，例如完整报头（IPv6/UDP）为48个八位字节，压缩报头为4个八位字节，设置F_MAX_PERIOD>44意味着完整报头对平均报头大小的贡献小于一个八位字节。对于四地址路由报头，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
默认的F_MAX_PERIOD值为256（第14节），将完整报头频率置于膝盖的右侧，这意味着完整报头对平均报头大小的贡献通常比八位字节小得多。对于H=48和C=4，在达到默认情况下确定的稳态报头刷新频率后，完整报头对平均报头大小的贡献约为1.4位
F_MAX_PERIOD. 1.4 bits is a very small overhead.
F_最大周期。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.
在上下文发生更改后，指数退避方案最初会频繁发送完整的头。发送九个完整标头和255个压缩标头后，将达到默认的F_MAX_期间。对于一个典型的语音流来说，这相当于5秒多一点，每个数据包有20毫秒的语音样本。
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个八位组。对于20毫秒的语音样本，需要不到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]）的类似成本，其中，在发送压缩报头之前，解压器必须确认完整报头。当上下文发生变化时，这样的方案通常发送一个完整的头加上一些控制消息。硬状态方案需要更多类型的协议消息，并且需要交换消息。硬状态方案还需要明确处理软状态自动处理的各种错误条件，例如一方意外消失的情况，这是无线链路上的一种常见情况，其中移动设备可能超出基站的范围。
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之间频繁变化，则压缩器可以选择将分组分组成两个不同的分组流。
A compressor is also free not to group packets into packet streams for compression, letting some packets keep their regular headers and passing them through unmodified.
压缩器也可以自由地不将数据包分组到数据包流中进行压缩，让一些数据包保持其常规头并在未修改的情况下通过。
As long as the rules for when to send full headers for a non-TCP packet stream are followed and subheaders are compressed as specified in this document, the decompressor is able to reconstruct a compressed header correctly regardless of how packets are grouped into packet streams.
只要遵循关于何时发送非TCP数据包流的完整报头的规则，并且按照本文档中的规定压缩子报头，无论数据包如何分组到数据包流中，解压器都能够正确地重构压缩的报头。
In this section we give OPTIONAL guidelines for how a compressor may group packets into packet streams for compression.
在本节中，我们将提供可选指南，说明压缩器如何将数据包分组到数据包流中进行压缩。
Defining fields
定义字段
The defining fields of a header should be present and identical in all packets belonging to the same packet stream. These fields are marked DEF in section 7. The defining fields include the flow label, source and destination addresses of IP headers, final destination address in routing headers, the next header fields (for IPv6), the protocol field (IPv4), port numbers (UDP and TCP), and the SPI in authentication and encryption headers.
在属于同一数据包流的所有数据包中，报头的定义字段应该存在并且相同。这些字段在第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字段。当存在频繁的路由切换时，可能会发生这种情况，以便数据包通过internet的不同路径。
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报头的Traffic Class字段和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使用相同的位数。始终可以判断完整或压缩的报头是用于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压缩头使用压缩头的第二个八位字节中的一位对CID的大小进行编码。8位CID允许非TCP数据包的最小压缩头大小为2个八位字节，CID使用第一个八位字节，大小位和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大小为8位，如[RFC-1144]所示。8位可能就足够了，因为TCP连接总是点对点的。
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_标头时，只有部分标头存储为上下文。实现的压缩量不得超过头的初始最大头八位字节数。实现不能部分压缩子标题。
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_报头八位字节。
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.
生成需要一个八位字节，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头，则将有两个以上的八位字节可用。
[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数据包将有4个八位字节可用于传递生成和CID，因此可以使用所有CID大小。分段或加密的数据包流可能只有2个八位字节可用于通过生成和CID。因此，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.
生成值在完整标头中第一个长度字段的高阶八位字节中传递。当只有一个长度字段可用时，8位CID以低阶八位字节传递。当两个长度字段可用时，CID的最低两个八位字节在第二个长度字段中传递，第一个长度字段的低阶八位字节携带CID的最高八位字节。
Use of first length field:
第一个长度字段的使用：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length field | LSB of pkt nr | CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length field | LSB of pkt nr | CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Use of second length field if available:
使用第二个长度字段（如果可用）：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field | MSB of pkt nr | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First length field |0|D| Generation| CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field (if avail.) | 0 | Data (if D=1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First length field |1|D| Generation| Data (if D=1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field | CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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为零，则数据字段为零。第12节解释了D位和数据字段的使用。
This section uses some terminology (DELTA, RANDOM) defined in section 7.
本节使用第7节中定义的一些术语（增量、随机）。
a) COMPRESSED_TCP format (similar to [RFC 1144]):
a) 压缩的_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)
- - - - - - - -
+-+-+-+-+-+-+-+-+
| CID |
+-+-+-+-+-+-+-+-+
|R O I P S A W U|
+-+-+-+-+-+-+-+-+
| |
+ TCP Checksum +
| |
+-+-+-+-+-+-+-+-+
| RANDOM fields, if any (see section 7) (implied)
- - - - - - - -
| R-octet | (if R=1)
- - - - - - - -
| Urgent Pointer Value (if U=1)
- - - - - - - -
| Window Delta (if W=1)
- - - - - - - -
| Acknowledgment Number Delta (if A=1)
- - - - - - - -
| Sequence Number Delta (if S=1)
- - - - - - - -
| IPv4 Identification Delta (if I=1)
- - - - - - - -
| Options (if O=1)
- - - - - - - -
The latter flags in the second octet (IPSAWU) have the same meaning as in [RFC-1144], regardless of whether the TCP segments are carried by IPv6 or IPv4. The C bit has been eliminated because the CID is always present. The context associated with the CID keeps track of the IP version and what RANDOM fields are present. The order between delta fields specified here is exactly as in [RFC-1144]. An implementation will typically scan the context from the beginning and insert the RANDOM fields in order. The RANDOM fields are thus placed before the DELTA fields of the TCP header in the same order as they occur in the original uncompressed header.
第二个八位字节（IPSAWU）中的后一个标志与[RFC-1144]中的含义相同，无论TCP段是由IPv6还是IPv4承载。C位已被消除，因为CID始终存在。与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标志为零，除非IPv4标头紧跟在TCP标头之前。然后将组合的IPv4/TCP报头压缩为一个单元，如[RFC-1144]所述。IPv4报头中没有紧跟TCP报头的标识字段是随机的。
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位）或TCP报头前面的IPv4报头（IPv6报头）中的TOS八位字节（流量类八位字节）的第6位或第7位之间存在差异。然后将保留字段的实际值以及TOS或Traffic Class字段的第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) 压缩的\u TCP\u节点数据头格式
+-+-+-+-+-+-+-+-+
| CID |
+-+-+-+-+-+-+-+-+
| RANDOM fields, if any (see section 7) (implied)
+-+-+-+-+-+-+-+-+
| Whole TCP header except for Port Numbers
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| 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)
- - - - - - - -
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)
- - - - - - - -
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和可选的一个八位字节数据之后是压缩状态所暗示的相关随机场（见第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.
NOCHANGE该字段预计不会更改。任何更改都意味着必须发送完整的标头来更新上下文。
DELTA The field may change often but usually the difference from the field in the previous header is small, so that it is cheaper to send the change from the previous value rather than the current value. This type of compression is only used for TCP packet streams.
DELTA字段可能经常更改，但通常与上一个标头中的字段的差异很小，因此从上一个值发送更改比从当前值发送更改更便宜。这种类型的压缩仅用于TCP数据包流。
RANDOM The field must be included "as-is" in compressed headers, usually because it changes unpredictably.
随机字段必须“按原样”包含在压缩头中，这通常是因为它的变化不可预测。
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.
分类意味着压缩头是如何构造的。压缩头中不存在无更改或推断的字段。压缩器从压缩标识符标识的上下文中获取NOCHANGE字段的值，并从链路层实现（例如，从链路层帧的大小）或从其他字段（例如，通过重新计算IPv4报头校验和）中获取推断字段的值。增量字段编码为与同一数据包流中前一数据包中的值的差值。解压缩程序必须通过将压缩头中的值添加到其上下文中的值来更新上下文。结果是字段的正确值。随机字段必须按压缩头中的“原样”发送。随机场在压缩标头中的出现顺序必须与在完整标头中的出现顺序相同。
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节中可选指南的压缩器，两个数据包之间对应DEF字段的任何差异都意味着它们属于不同的数据包流。此外，如果DEF字段存在于一个数据包中而不存在于另一个数据包中，则这些数据包属于不同的数据包流。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version NOCHANGE (DEF) Traffic Class NOCHANGE (might be DEF, see sect 4.1) (see also sect 6 a) Flow Label NOCHANGE (DEF) Payload Length INFERRED Next Header NOCHANGE Hop Limit NOCHANGE (might be DEF, see sect 4.1) Source Address NOCHANGE (DEF) Destination Address NOCHANGE (DEF)
版本NOCHANGE（DEF）流量类别NOCHANGE（可能是DEF，请参见第4.1节）（另请参见第6 a节）流标签NOCHANGE（DEF）有效负载长度推断下一个标头NOCHANGE跃点限制NOCHANGE（可能是DEF，请参见第4.1节）源地址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扩展标头中的所有下一个标头字段均为NOCHANGE。
The contents of Hop-by-hop Options and Destination Options extension headers are encoded with TLV "options" (see [IPv6]):
逐跳选项和目标选项扩展头的内容使用TLV“选项”编码（请参见[IPv6]）：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | 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.
假设Option Type和Opt Data Len字段对于给定的数据包流是固定的，因此它们被分类为NOCHANGE。除非下文另有规定，否则选项数据是随机的。
Padding
衬料
Pad1 option
Pad1选项
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Entire option is NOCHANGE.
整个选项是无更改的。
PadN option
PadN选项
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
All fields are NOCHANGE.
所有字段都没有更改。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header NOCHANGE Hdr Ext Len NOCHANGE
下一个标头无更改Hdr Ext Len无更改
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
前两个字段是NOCHANGE和Jumbo有效负载长度推断。（帧长度必须由链路层实现提供）。
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All fields of the Routing Header are NOCHANGE.
路由标头的所有字段均为NOCHANGE。
If the Routing Type is not recognized, it is impossible to determine the final Destination Address unless the Segments Left field has the value zero, in which case the Destination Address is the final Destination Address in the basic IPv6 header.
如果无法识别路由类型，则无法确定最终目标地址，除非Segments Left字段的值为零，在这种情况下，目标地址是基本IPv6报头中的最终目标地址。
In the Type 0 Routing Header, the last address is DEF if (Segments Left > 0).
在类型0路由标头中，最后一个地址是DEF if（左段>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个八位字节。此外，移动IP使用带有一个地址（大小为24个八位字节）的0型路由头。
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 | 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.
注意：标识字段是随机的，而不是无更改的，以避免每个原始数据包一次压缩缓慢启动。
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，并节省了相关压缩慢启动的成本。我们预计，如果标题的不可分割部分发生抖动，则不会太频繁地更改。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header NOCHANGE Hdr Ext Len NOCHANGE
下一个标头无更改Hdr Ext Len无更改
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) |
| |
+---------------+---------------+---------------+---------------+
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保留NOCHANGE SPI NOCHANGE（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进行身份验证，该密钥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 |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| 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 | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port NOCHANGE (DEF) Destination Port NOCHANGE (DEF) Length INFERRED Checksum RANDOM, unless it is zero, in which case it is NOCHANGE.
源端口NOCHANGE（DEF）目标端口NOCHANGE（DEF）长度推断校验和随机，除非为零，在这种情况下为NOCHANGE。
The Length field of the UDP header MUST match the Length field(s) of preceding subheaders, i.e, there must not be any padding after the UDP payload that is covered by the IP Length.
UDP头的长度字段必须与前面的子标题的长度字段匹配，即IP长度覆盖的UDP有效负载后不得有任何填充。
The UDP header is typically compressed down to 2 octets, the UDP checksum. When the UDP checksum is zero (which it cannot be with IPv6), it is likely to be so for all packets in the flow and is defined to be NOCHANGE. This saves 2 octets in the compressed header.
UDP报头通常压缩为2个八位字节，即UDP校验和。当UDP校验和为零时（IPv6无法做到这一点），流中的所有数据包都可能为零，并且定义为NOCHANGE。这将在压缩头中保存2个八位字节。
The TCP header is described in [RFC-793].
[RFC-793]中描述了TCP报头。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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报头有两种方法。
Source Port NOCHANGE (DEF) Destination Port NOCHANGE (DEF) Sequence Number DELTA Acknowledgment Number DELTA Offset NOCHANGE Reserved DELTA (if differs from context, set R-flag in flag octet and send absolute value as described in 6 a.) Urg,Psh RANDOM (placed in flag octet) Ack INFERRED to be 1 Rst,Syn,Fin INFERRED to be 0 Window DELTA (if change in Window, set W-flag in flag octet and send difference) Checksum RANDOM Urgent Pointer DELTA (if Urg is set, send absolute value) Options, Padding DELTA (if change in Options, set O-flag and send whole Options, Padding)
源端口NOCHANGE（DEF）目标端口NOCHANGE（DEF）序列号增量确认号增量偏移量NOCHANGE保留增量（如果与上下文不同，请在标志八位字节中设置R标志，并按6 a中所述发送绝对值）Urg、Psh RANDOM（置于标志八位字节中）Ack推断为1 Rst、Syn、Fin推断为0窗口增量（如果窗口更改，则在标志八位字节中设置W标志并发送差异）校验和随机紧急指针增量（如果设置Urg，则发送绝对值）选项，填充增量（如果选项更改，则设置O标志并发送整个选项，填充）
A packet with a TCP header compressed according to the above must be indicated to be of type COMPRESSED_TCP. The compressed header is described in section 6.
具有根据上述压缩的TCP头的数据包必须指示为compressed_TCP类型。第6节描述了压缩头。
This method is essentially the differential encoding techniques of Jacobson, described in [RFC-1144], the differences being the placement of the compressed TCP header fields (see section 6), the use of the O-flag, the use of the R-flag, and elimination of the C-flag. The O-flag allows compression of the TCP header when the Timestamp option is used and the Options fields changes with each header.
该方法本质上是[RFC-1144]中描述的Jacobson的差分编码技术，不同之处在于压缩TCP报头字段的位置（见第6节）、O标志的使用、R标志的使用以及C标志的消除。当使用Timestamp选项时，O标志允许压缩TCP标头，并且选项字段随每个标头而更改。
DELTA values (except for Reserved field and Options, Padding) MUST be coded as in [RFC-1144]. A Reserved field value passed with the R-flag MUST NOT update the context at compressor or decompressor.
增量值（保留字段和选项、填充除外）必须按照[RFC-1144]中的规定进行编码。与R标志一起传递的保留字段值不得在压缩器或解压缩器上更新上下文。
Source Port NOCHANGE (DEF) Destination Port NOCHANGE (DEF)
源端口无更改（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_Nodeta类型。它使用与压缩的\u 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.
此数据包类型可以作为对报头请求的响应发送，而不是发送完整的报头，可以通过对数据包重新排序的链接使用，并且可以在存在无法由压缩报头表示的更改时发送，而不是发送完整的报头。当数据包丢失频率较高时，一个复杂的压缩器可以切换到只发送压缩的\u TCP\u 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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报头有两种方法
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，必须是5）服务类型NOCHANGE（可能是DEF，请参见第4.1节）（另请参见6 a）推断的总长度（从链路层实现或封装IP标头）
Identification DELTA/ (If the Protocol field has the (value corresponding to TCP) RANDOM (otherwise)
标识增量/（如果协议字段具有（对应于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)
标志NOCHANGE（不得设置MF标志）片段偏移量NOCHANGE（必须为零）生存时间NOCHANGE（可能是DEF，请参见第4.1节）协议NOCHANGE头校验和推断（从其他字段计算）源地址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报头紧随其后时，IPv4和TCP报头必须按第6节所述作为一个单元进行压缩。然后，可以使用R标志传递服务字段类型的第6位和第7位（第一个字的第14位和第15位）（参见第6a节）。
b) If the IPv4 header is for a fragment (MF bit set or Fragment Offset nonzero), or there are options (IHL > 5), all fields are RANDOM (i.e., if the header is compressed all fields are sent as-is and not compressed). This classification allows compression of the tunnel header, but not the fragment header, when fragments are tunneled. If the IPv4 header is for a fragment it ends the compressible chain of subheaders, i.e., it must be the last subheader to be compressed. If the IPv4 header has options but is not for a fragment it does not end the compressible chain of subheaders, so subsequent subheaders can be compressed.
b) 如果IPv4报头用于片段（MF位集或片段偏移量非零），或者存在选项（IHL>5），则所有字段都是随机的（即，如果报头被压缩，则所有字段都按原样发送，而不是压缩）。当片段被隧道化时，这种分类允许压缩隧道头，但不允许压缩片段头。如果IPv4报头用于片段，则它结束可压缩的子标题链，即它必须是最后一个要压缩的子标题。如果IPv4标头具有选项，但不用于片段，则它不会结束可压缩的子标头链，因此可以压缩后续子标头。
A compressor that follows the optional guidelines of section 4.1 will in case a) use the Version, Source Address and Destination Address to define the packet stream, together with the fact that there are no IPv4 options and that this is not a fragment.
遵循第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报头是否用于片段定义两种分组流。
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol |S| reserved | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (if present) Original Source Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol NOCHANGE Original Source Address Present (S) NOCHANGE reserved NOCHANGE Header Checksum INFERRED (calculated from other values) Original Destination Address NOCHANGE Original Source Address NOCHANGE (present only if S=1)
协议NOCHANGE原始源地址存在NOCHANGE保留NOCHANGE头校验和推断（根据其他值计算）原始目标地址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或重用CID。
Each non-TCP CID is associated with a context with a generation value. To avoid too rapid generation wrap-around and potential incorrect decompression, an implementation MUST avoid wrap-around of the generation value in less than MIN_WRAP seconds (see section 14).
每个非TCP CID都与具有生成值的上下文相关联。为了避免生成回卷过快和潜在的错误解压缩，实现必须避免在不到MIN_wrap秒的时间内生成值的回卷（请参见第14节）。
To aid in avoiding wrap-around, the generation value associated with a CID MUST NOT be reset when changing to a new packet stream. Instead, a compressor MUST increment the generation value by one when using the CID for a new non-TCP packet stream.
为了帮助避免回绕，当更改为新的数据包流时，不得重置与CID关联的生成值。相反，当对新的非TCP数据包流使用CID时，压缩器必须将生成值增加1。
When a decompressor receives a packet with a compressed TCP header with CID C, it MUST be discarded when the context for C has not been initialized by a full header.
当解压器接收到带有压缩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秒，因为上下文可能已过时，即使它已生成G。
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）临时存储，直到上下文被具有完整非TCP报头（具有CID C和生成G）的数据包更新，之后可以解压缩报头。
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的完整或压缩的非TCP报头，以及除G以外的一代，
*) the decompressor has not received packets with CID C in the last MIN_WRAP seconds.
*)解压器在最近几分钟内未收到CID C的数据包。
When full headers are lost, a decompressor can receive compressed non-TCP headers with a generation value other than the generation of its context. Rule ii) allows the decompressor to store such headers until they can be decompressed using the correct context.
当完整头丢失时，解压缩程序可以接收压缩的非TCP头，其生成值不是其上下文的生成值。规则ii）允许解压器存储这些头，直到可以使用正确的上下文解压它们。
Since fewer bits are transmitted per packet with header compression, the packet loss rate is lower with header compression than without, for a fixed bit-error rate. This is beneficial for links with high bit-error rates such as wireless links.
由于使用报头压缩时每个数据包传输的比特数较少，因此对于固定的误码率，使用报头压缩时的数据包丢失率低于不使用报头压缩时的数据包丢失率。这对于具有高误码率的链路（如无线链路）是有益的。
However, since TCP headers are compressed using differential encoding, a single lost TCP segment can ruin an entire TCP sending window because the context is not incremented properly at the decompressor. Subsequent headers will therefore be decompressed to be different than before compression and discarded by the TCP receiver because the TCP checksum fails.
但是，由于TCP头使用差分编码进行压缩，单个丢失的TCP段可能会破坏整个TCP发送窗口，因为在解压缩程序中上下文没有正确递增。因此，后续的报头将被解压缩，与压缩之前不同，并被TCP接收器丢弃，因为TCP校验和失败。
A TCP connection in the wide area where the last hop is over a medium-speed lossy link, for example a wireless LAN, will then have poor performance with traditional header compression because the delay-bandwidth product is relatively large and the bit-error rate relatively high. For a 2 Mbit/s wireless LAN and an end-to-end RTT of 200 ms, the delay-bandwidth product is 50 kbyte. That is equivalent to about 97 512-octet segments with compressed headers. Each loss can thus be multiplied by a factor of 100.
在广域中，最后一跳通过中速有损链路（例如无线LAN）的TCP连接在传统的报头压缩下将具有较差的性能，因为延迟带宽积相对较大，误码率相对较高。对于2 Mbit/s无线LAN和200 ms的端到端RTT，延迟带宽乘积为50 kbyte。这相当于大约97512个八位字节段和压缩头。因此，每个损失可以乘以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.
本节描述了两种用于快速修复上下文的简单机制。通过这些机制，报头压缩将提高有损链路以及低误码率链路上的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批量传输的跟踪分析表明，应用当前段的增量一两次将修复数据流中83%到99%的所有单段丢失的上下文。对于确认流，由于TCP的延迟确认机制，成功率较小。“两次”机制修复了确认流中53%到99%的损失的上下文。这种思想的复杂实现将确定TCP流是确认流还是数据流，并通过观察完整和压缩头的流来确定段大小。尝试段大小的小倍数的增量将导致更高的确认流修复成功率。
The relatively low success rate for the "twice" algorithm for TCP acknowledgment streams calls for an additional mechanism for repairing the context at the decompressor. When the decompressor fails to repair the context after a loss, the decompressor may optionally request a full header from the compressor. This is possible on links where the decompressor can identify the compressor and send packets to it.
TCP确认流的“两次”算法的成功率相对较低，需要一种额外的机制来修复解压缩程序中的上下文。当解压器在丢失后无法修复上下文时，解压器可以选择从压缩器请求完整的头。这在解压器可以识别压缩器并向其发送数据包的链路上是可能的。
On such links, a decompressor may send a CONTEXT_STATE packet back to the compressor to indicate that one or more contexts are invalid. A decompressor SHOULD NOT transmit a CONTEXT_STATE packet every time a compressed packet refers to an invalid context, but instead should limit the rate of transmission of CONTEXT_STATE packets to avoid flooding the reverse channel. A CONTEXT_STATE packet can indicate that several contexts are out of date, this technique SHOULD be used instead of sending several separate packets. The following diagram shows the format of a CONTEXT_STATE packet.
在这样的链路上，解压器可以将上下文状态分组发送回压缩器，以指示一个或多个上下文无效。解压器不应在每次压缩数据包引用无效上下文时发送上下文\ U状态数据包，而是应限制上下文\ U状态数据包的传输速率，以避免溢出反向通道。一个CONTEXT_状态数据包可以表示多个CONTEXT已过期，应使用此技术，而不是发送多个单独的数据包。下图显示了上下文状态数据包的格式。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| TCP header request = 3 |
+---+---+---+---+---+---+---+---+
| CID count |
+---+---+---+---+---+---+---+---+
| CID |
+---+---+---+---+---+---+---+---+
| CID |
+---+---+---+---+---+---+---+---+
...
+---+---+---+---+---+---+---+---+
| CID |
+---+---+---+---+---+---+---+---+
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.
第一个八位组是一种类型代码，用于允许为其他压缩协议共享上下文状态数据包类型，这些协议是（参见[CRTP]），或者可以与此协议并行定义。当用于TCP标头请求时，类型代码的值为3，数据包的其余部分是一个CID序列，前面是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.
在接收到上下文状态数据包时，压缩器必须将CIDs标记为无效，以确保在这些数据包流中发出的下一个数据包是完整的头数据包或压缩的TCP节点数据包。
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.
头请求是一种优化，因此上下文状态数据包的丢失不会影响TCP头压缩的正确操作。当一个上下文状态数据包丢失时，最终将传输一个新的数据包，或者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头不会更改上下文，刷新上下文的完整头也不会更改上下文。只有当更改上下文的完整标题出现错误时，才会出现问题。有两种情况：
- 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.
- 生成为G的完整报头的数据包在生成为G的压缩报头的数据包之后到达*。这种情况由第9节中的规则b）ii）涵盖。
- A packet with a full header with generation G arrives *before* a packet with a compressed header with generation G-1 (modulo 64). The decompressor MAY then keep both versions of the context around for a while to be able to decompress subsequent compressed headers with generation G-1 (modulo 64). The old context MUST be discarded after MIN_WRAP seconds.
- 具有第G代的完整报头的数据包在具有第G-1代（模64）的压缩报头的数据包到达*之前到达*。然后，解压器可以将上下文的两个版本保留一段时间，以便能够使用生成G-1（模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.
压缩器可以避免发送压缩的\u TCP头，并且只有在链路上重新排序时才发送压缩的\u TCP\u节点塔头。使用该方法压缩的头文件通常为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个八位字节。然后，TCP流中的每个数据包增加一个数据包序列号，该序列号与每个压缩的完整报头相关联。这允许解压器将数据包按正确的顺序放置，并将其增量按正确的顺序应用于上下文。使用一个简单的滑动窗口方案来按正确的顺序放置数据包。
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.
数据包序列号需要两个八位字节。一个八位组只给出256个序列号。在滑动窗口方案中，窗口不应大于序列号空间的一半，因此数据包不能超出顺序到达超过127个位置。这相当于在具有512个八位组段的2 Mbit/s链路上的260 ms延迟。在广域互联网连接上，这种延迟并不罕见。但是，给出2^16=65536值的两个八位字节就足够了。
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头将只有一个序列号的八位字节的空间。增加完整报头的大小是不可行的，因为分组大小可能会针对链路的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.
必须跳过数据包序列号0。避免零会解决使用TCP窗口缩放选项放大TCP窗口时可能出现的问题。当TCP数据丢失2^16个八位字节时，压缩头将被错误解压缩，而不会被TCP校验和检测到。TCP段大小通常是2的幂。因此，如果使用不是二次幂的数据包序列号空间，则当丢失2^16个八位字节时，TCP序列号或数据包序列号将不同。每当压缩器在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校验和之后。完整报头中数据包序列号的位置见第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节）提供了必要的机制。例如，当需要在完整的\u头或压缩的\u非\u TCP头中传递序列号时，设置D位并将序列号放置在数据字段中。然后，解压缩程序必须提取数据字段，并使其可用于附加的头压缩方案。
Use of additional header compression schemes like CRTP must be negotiated. The D-bit and Data octet mechanism must automatically be enabled whenever use of additional header compression schemes has been negotiated.
必须协商使用附加的报头压缩方案，如CRTP。每当协商使用额外的报头压缩方案时，必须自动启用D位和数据八位组机制。
For each link layer, there must be a document specifying how the various packet types used by IP header compression is indicated. Such a document exists for PPP [PPP-HC]. This section gives OPTIONAL guidelines on how packet types may be indicated by a specific link-layer.
对于每个链路层，必须有一个文档，指定如何指示IP报头压缩使用的各种数据包类型。此类文件适用于PPP[PPP-HC]。本节提供了关于如何通过特定链路层指示数据包类型的可选指南。
It is necessary to distinguish packets with regular IPv4 headers, regular IPv6 headers, full IPv6 packets, full IPv4 packets, compressed TCP packets, compressed non-TCP packets, and CONTEXT_STATE packets.
必须区分具有常规IPv4报头、常规IPv6报头、完整IPv6数据包、完整IPv4数据包、压缩TCP数据包、压缩非TCP数据包和上下文状态数据包的数据包。
The decision to use a distinct ethertype (or equivalent) for IPv6 has already been taken, which means that link-layers must be able to indicate that a packet is an IPv6 packet.
已经决定为IPv6使用不同的以太网类型（或等效类型），这意味着链路层必须能够指示数据包是IPv6数据包。
IP header compression requires that the link-layer implementation can indicate four kinds of packets: COMPRESSED_TCP for format a) in section 6, COMPRESSED_TCP_NODELTA for format b), COMPRESSED_NON_TCP for formats c) and d), and CONTEXT_STATE as described in section 11.2. It is also desirable to indicate FULL_HEADERS at the link layer.
IP报头压缩要求链路层实现可以指示四种数据包：第6节中格式a的压缩_TCP、格式b的压缩_TCP_NodeTA、格式c）和d的压缩_非_TCP以及第11.2节中描述的上下文_状态。还希望在链路层指示全_报头。
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标头，一位用于指示此完整标头是否携带TCP CID或非TCP CID。前四位编码如下：
Version Meaning
------- -------
Version Meaning
------- -------
0110 regular IPv6 header
0110常规IPv6标头
1T*0 T=1 indicates a TCP header, T=0 indicates a non-TCP header
1*V0 V=1 indicates a IPv6 header, V=0 indicates a IPv4 header
1T*0 T=1 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.
如果链路层无法指示压缩头或上下文状态的数据包类型，则无法指示的数据包类型可以从指示数据包类型的八位字节开始，然后是报头。
First octet Type of compressed header
----------- -------------------------
First octet Type of compressed header
----------- -------------------------
0 COMPRESSED_TCP 1 COMPRESSED_TCP_NODELTA 2 COMPRESSED_NON_TCP 3 CONTEXT_STATE
0压缩\u TCP 1压缩\u TCP\u节点状态2压缩\u非\u TCP 3上下文\u状态
The currently assigned CONTEXT_STATE type values are
当前分配的上下文_状态类型值为
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
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
- 两个IPv6基本标头-一个密钥MD5身份验证标头-一个最大大小的TCP标头
MAX_HEADER must be at least 60 octets and at most 65535 octets.
MAX_头必须至少为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_空间必须至少为3，最多为255。
NON_TCP_SPACE - Maximum CID value for non-TCP.
非TCP_空间-非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.
非TCP_空间必须至少为3，最多为65535。
EXPECT_REORDERING - The mechanisms in section 11 are used.
除重新排序外-使用第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.
自1996年3月以来，使用UDP作为链路层的原型已经投入使用。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.
该协议使用了Van Jacobson在低速链路上TCP/IP头压缩设计中提出的许多想法[RFC-1144]。它得益于与斯蒂芬·卡斯纳和卡斯滕·鲍曼的讨论。
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.
我们感谢Craig Partridge指出了使用TCP窗口缩放选项时可能出现的问题。第11.2节描述了依靠用于重新排序的数据包序列号解决此问题的方法。
The compression protocols in this document run on top of a link-layer protocol. The compression protocols themselves introduce no new additional vulnerabilities beyond those associated with the specific link-layer technology being used.
本文档中的压缩协议运行在链路层协议之上。除了与所使用的特定链路层技术相关的漏洞外，压缩协议本身不会引入任何新的额外漏洞。
Denial-of-service attacks are possible if an intruder can introduce (for example) bogus Full Header packets onto the link. However, an intruder having the ability to inject arbitrary packets at the link-layer in this manner raises additional security issues that dwarf those related to the use of header compression.
如果入侵者在链路上引入（例如）虚假的完整报头数据包，则可能会发生拒绝服务攻击。然而，能够以这种方式在链路层注入任意数据包的入侵者会引发额外的安全问题，使与使用报头压缩相关的安全问题相形见绌。
We advise implementors against identifying packet streams with the aid of information that is encrypted, even if such information happens to be available to the compressor. Doing so may expose traffic patterns.
我们建议实施者不要借助加密的信息来识别数据包流，即使这些信息恰好可供压缩器使用。这样做可能会暴露流量模式。
Mikael Degermark Department of Computer Science and Electrical Engineering Lulea University of Technology SE-971 87 Lulea, Sweden
瑞典Lulea理工大学计算机科学与电气工程系Se-91 87
Phone: +46 920 91188
Fax: +46 920 72831
Mobile: +46 70 833 8933
EMail: micke@sm.luth.se
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研究AB Aurorum 6 S-977 75 Lulea，瑞典
Phone: +46 920 75400
Fax: +46 920 75490
EMail: bcn@lulea.trab.se, bcn@cdt.luth.se
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
瑞典Lulea理工大学计算机科学与电气工程系Stephen Pink Department 87
Phone: +46 920 752 29
Fax: +46 920 728 31
Mobile: +46 70 532 0007
EMail: steve@sm.luth.se
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 7911981年9月。
[RFC-793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC-793]Postel，J.，“传输控制协议”，标准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媒体（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-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]Kent，S.和R.Atkinson，“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封装安全协议（ESP）”，RFC 2406，1998年11月。
[RFC-1828] Metzger, W., "IP Authentication using Keyed MD5", RFC 1828, August 1995.
[RFC-1828]Metzger，W.，“使用密钥MD5的IP认证”，RFC 18281995年8月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.", RFC 2463, December 1998.
[ICMPv6]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.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. .fi
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。fi