组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：zxl_mailbox@yahoo.com.cn<br />
译者：（Sword）<br />
译文发布时间：2002-1-23<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A.&nbsp;Shacham<br />
Request&nbsp;for&nbsp;Comments:&nbsp;2393&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Cisco<br />
Category:&nbsp;Standards&nbsp;Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;R.&nbsp;Monsour<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Hi/fn<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;R.&nbsp;Pereira<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TimeStep<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;M.&nbsp;Thomas<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;AltaVista&nbsp;Internet<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;December&nbsp;1998<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;IP有效载荷压缩协议(IPComp)<br />
本备忘录状态<br />
<br />
&nbsp;&nbsp;&nbsp;This&nbsp;document&nbsp;specifies&nbsp;an&nbsp;Internet&nbsp;standards&nbsp;track&nbsp;protocol&nbsp;for&nbsp;the<br />
&nbsp;&nbsp;&nbsp;Internet&nbsp;community,&nbsp;and&nbsp;requests&nbsp;discussion&nbsp;and&nbsp;suggestions&nbsp;for<br />
&nbsp;&nbsp;&nbsp;improvements.&nbsp;&nbsp;Please&nbsp;refer&nbsp;to&nbsp;the&nbsp;current&nbsp;edition&nbsp;of&nbsp;the&nbsp;"Internet<br />
&nbsp;&nbsp;&nbsp;Official&nbsp;Protocol&nbsp;Standards"&nbsp;(STD&nbsp;1)&nbsp;for&nbsp;the&nbsp;standardization&nbsp;state<br />
&nbsp;&nbsp;&nbsp;and&nbsp;status&nbsp;of&nbsp;this&nbsp;protocol.&nbsp;&nbsp;Distribution&nbsp;of&nbsp;this&nbsp;memo&nbsp;is&nbsp;unlimited.<br />
<br />
版权声明<br />
<br />
&nbsp;&nbsp;&nbsp;Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(1998).&nbsp;&nbsp;All&nbsp;Rights&nbsp;Reserved.<br />
<br />
摘要<br />
&nbsp;&nbsp;&nbsp;本文档描述用于在INTERNET环境中为IP层提供无损耗压缩的协议。<br />
&nbsp;&nbsp;<br />
1.&nbsp;介绍<br />
IP有效载荷压缩是一个减少IP数据报长度的协议。通过压缩数据报，这个协议将在一对通信主机/网关（“节点”）之间提升整体通信性能。倘若节点有足够的计算能力，透过CPU功能或者一个压缩协处理器，在慢速或者拥挤的链路上通信。<br />
&nbsp;&nbsp;<br />
IP数据报加密时，IP有效载荷压缩特别有用。加密IP数据报使得数据看起来很随机，在较低协议层压缩效率低（例如，PPP压缩控制协议[RFC-1962]）。如果同时要求压缩和加密，压缩必须在加密之前进行。<br />
&nbsp;&nbsp;&nbsp;<br />
本文档定义了IP有效载荷压缩协议(IPComp)、IPComp包结构、IPComp安全关联（IPCA），和几种协商IPCA的方式。<br />
&nbsp;&nbsp;<br />
其他文档详细说明一个特定压缩算法如何与IP有效载荷压缩协议一起使用。这样的算法超出本文档范围之外。<br />
&nbsp;&nbsp;<br />
1.1.&nbsp;要求规范<br />
<br />
&nbsp;&nbsp;&nbsp;本文档中的关键字"MUST",&nbsp;"MUST&nbsp;NOT",&nbsp;"REQUIRED",&nbsp;"SHALL",&nbsp;"SHALL&nbsp;NOT",<br />
&nbsp;&nbsp;&nbsp;"SHOULD",&nbsp;"SHOULD&nbsp;NOT",&nbsp;"RECOMMENDED",&nbsp;"MAY",&nbsp;and&nbsp;"OPTIONAL"&nbsp;由RFC&nbsp;2119&nbsp;[RFC-2119]解释。<br />
<br />
2.&nbsp;压缩过程<br />
IP数据报压缩处理过程包含两个阶段：出站IP数据报压缩和入站数据报解压。压缩处理必须是无损耗的，确保IP数据报在压缩和解压缩之后，与原始的IP数据报一致。<br />
&nbsp;&nbsp;&nbsp;<br />
每个IP数据报单独地被压缩和解压，与其他数据报没有任何关联（无状态压缩）。因为IP数据报可能无序地到达或者丢失。每个压缩的IP数据报封装单个IP有效载荷。<br />
&nbsp;&nbsp;&nbsp;<br />
入站IP数据报的处理必须支持压缩和未压缩IP数据报，以便满足非扩展策略要求，它在2.2节定义。出站IP数据报压缩必须在任何IP安全处理之前进行，例如加密和验证，必须在IP数据报分片之前进行。另外，IPv6中，出站IP数据报压缩必须在Hop-by-Hop选项头或者Routing头添加之前进行。因为它们被数据报传递路径上的各个节点检查和处理，所以必须以原始形式发送。<br />
&nbsp;&nbsp;&nbsp;&nbsp;<br />
类似地，入站IP数据报的解压必须在IP数据报重组之后，在所有IP安全处理完成之后进行，例如验证和解密。<br />
&nbsp;&nbsp;&nbsp;<br />
2.1.压缩的有效载荷<br />
<br />
压缩应用于单列字节，在IP数据报中它们相邻。这列字节总是以IP数据报有效载荷的最后字节结束。注意：IP数据报中相邻的一列字节可能在物理内存中不相邻。<br />
&nbsp;&nbsp;<br />
IPv4中，压缩应用于IP数据报的上层协议有效载荷。IP头或者IP头中的选项不压缩。<br />
&nbsp;&nbsp;<br />
IPv6中，IPComp被看作端到端的有效载荷，不允许用于hop-by-hop、&nbsp;routing、和分片扩展头。压缩从第一个IP头选项字段开始，因为它没有必须由数据报传递路径上必须检测和处理的信息。如果这样的IP头选项存在，继续至IP数据报的上层协议载荷。<br />
&nbsp;&nbsp;<br />
一个被压缩的有效载荷长度，由压缩算法产生的，必须以字节为单位。<br />
&nbsp;&nbsp;<br />
按照第3节定义，一个IPComp头直接插入已压缩的有效载荷之前。原始IP头需要修改，以表明使用IPComp协议和减少的IP数据报长度。下一个头（IPv6）字段或者协议字段(IPv4)的原始内容保存在IPComp头。<br />
&nbsp;<br />
解压缩应用IP数据报中单列相邻的字节。这列字节的头紧跟IPComp头，以IP有效载荷的最后字节结束。如果解压缩完全成功，IP头需要修改，以便指示解压后IP数据报的长度，从IPComp头中恢复原始的下一个头字段值。IPComp头从IP数据报中删除，解压之后的有效载荷紧跟在IP头之后。<br />
&nbsp;&nbsp;<br />
2.2.非扩展策略<br />
<br />
如果已压缩的上层协议数据和IPComp头的总长度，第3节定义的，不小于原来上层协议数据的长度，IP数据报必须以不压缩的格式发出。需要阐明：如果IP数据报没有压缩就发出，不会添加IPComp头。这个策略确保节省解压缩过程的循环，避免扩展数据报大于MTU时，IP数据报分片。<br />
<br />
小的IP数据报有可能压缩之后却扩大，所以，压缩之前应该定义一个最小的数值极限。如果IP数据报小于这个值，不压缩而以原始格式发出该数据报。最小数值极限的定义与实现有关。<br />
<br />
一个数据报的有效载荷已经压缩过，往往不再进一步压缩。先前已压缩的有效载荷可能是外部处理的结果，例如在通信栈高层应用的压缩，或者由离线压缩工具进行的压缩。应该实现一种适应性的算法避免性能受到影响。例如，如果一个IPCA上I个连续IP数据报压缩失败，下面k个&nbsp;IP数据报将不尝试压缩而被发送出去。如果再下面j个数据报压缩又失败了，那么后面k+n个数据报将不尝试压缩直接发送。一旦一个数据报成功压缩，IPComp正常处理重新开始。这样的适应性算法，包括所有相关的最低限度，&nbsp;与实现有关。<br />
有效载荷处理期间，压缩算法可能定期进行测试，确定被处理数据的可压缩性，类似与[V42BIS]的要求。测试的特性和算法相关。一旦压缩算法检测到数据不可压缩，算法应该停止处理数据，有效载荷以原始、不压缩格式传递。<br />
&nbsp;&nbsp;&nbsp;<br />
&nbsp;&nbsp;3.已压缩的IP数据报头结构<br />
<br />
一个已压缩的IP数据报通过修改IP头，在被压缩的有效载荷之前插入IPComp头，来封装它。本节定义IPv4和IPv6中IP头修改的字段和IPComp头结构。<br />
<br />
3.1.&nbsp;IPv4&nbsp;头修改字段<br />
<br />
&nbsp;&nbsp;&nbsp;下面IPv4头字段在传输已压缩的IP数据报之前设置：<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Total&nbsp;Length&nbsp;总长度<br />
整个被封装的IP数据报长度，包括IP头、IPComp头和已压缩的有效载荷。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Protocol&nbsp;协议<br />
设置为108，表示IPComp数据报。[RFC-1700]<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Header&nbsp;Checksum&nbsp;首部校验和<br />
IP头的内部头校验和。[RFC-0791]<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
&nbsp;&nbsp;&nbsp;所有其它IPv4头字段保持不变，包括所有头中的选项。<br />
<br />
3.2.&nbsp;IPv6&nbsp;头修改<br />
<br />
下列IPv6头字段在传输压缩IP数据报之前设置。<br />
&nbsp;&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Payload&nbsp;Length&nbsp;载荷长度<br />
压缩IP载荷长度<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Next&nbsp;Header&nbsp;下一个头<br />
该字段设置为108，表示IPComp数据报[RFC-1700]<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
所有其他的IPv6头字段保持不变，包括任何没有压缩的头选项。<br />
&nbsp;&nbsp;<br />
IPComp头放置在IPv6数据报中采用与IPv6&nbsp;Fragment头一样的规则。然而，如果IPv6数据报同时包含IPv6&nbsp;Fragment头和IPComp头，IPv6&nbsp;Fragment头必须在IPComp头之前。<br />
&nbsp;<br />
3.3.&nbsp;&nbsp;IPComp&nbsp;头结构<br />
<br />
&nbsp;&nbsp;&nbsp;4字节的头结构如下：<br />
<br />
&nbsp;&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3<br />
&nbsp;&nbsp;&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1&nbsp;2&nbsp;3&nbsp;4&nbsp;5&nbsp;6&nbsp;7&nbsp;8&nbsp;9&nbsp;0&nbsp;1<br />
&nbsp;&nbsp;&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;Next&nbsp;Header&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Flags&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Compression&nbsp;Parameter&nbsp;Index&nbsp;|<br />
&nbsp;&nbsp;&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
<br />
&nbsp;&nbsp;&nbsp;Next&nbsp;Header下一个头<br />
8位选择子。存储原始IP头中的IPv4协议字段或者IPv6&nbsp;Next&nbsp;Header字段。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
&nbsp;&nbsp;&nbsp;Flags&nbsp;标志<br />
8位字段，保留给将来使用。必须设置为0，接收节点必须忽略它。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
&nbsp;&nbsp;&nbsp;Compression&nbsp;Parameter&nbsp;Index&nbsp;(CPI)&nbsp;压缩参数索引<br />
16位索引。按网络字节序存储。0-63定义了有名的压缩算法，这些算法不要求额外信息，用于手工设置。这些值本身与[SECDOI]定义的OMP转换标识符相同。参考[SECDOI]获取一组初始已定义的值，得到如何分配新值的指示。64-255保留给将来使用。256-61439在两个节点之间定义一个IPCA时协商。注意：当协商有名的算法之一时，节点可能选择预定义的0-63之间的值作为CPI。61440-65535主要是互相同意的各方私下使用。两个参与的节点可以选择一个CPI值，彼此独立，两个选择的CPI之间没有关系。出站IPComp头必须使用由解压缩节点选择的CPI值。CPI和目的IP地址一起，唯一地标识数据报压缩算法的特征。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
4.&nbsp;IPComp&nbsp;Association&nbsp;(IPCA)&nbsp;协商<br />
<br />
为了利用IPComp协议，两个节点彼此必须首先建立一个IPComp关联（IPCA）。IPCA包括IPComp操作要求的所有信息，包括CPI、操作模式、使用的压缩算法，和任何选择的压缩算法要求的参数。IPComp操作模式可以是节点对节点策略，即IPComp用于节点之间所有数据报，或者基于策略的一次上层协议会话，只有节点之间选择的上层协议对话使用IPComp。对于每个IPCA，在每个方向上，可能协商不同的压缩算法，或者只有单向压缩。默认“没有IPComp压缩”<br />
&nbsp;&nbsp;&nbsp;&nbsp;<br />
IPCA可以通过动态协商或者手工配置创建。动态协商应该使用ISAKMP，在IPSEC出现的地方。动态协商可以通过不同的协议实现。<br />
&nbsp;&nbsp;<br />
4.1.&nbsp;ISAKMP的使用<br />
<br />
IPComp用于IP安全时，ISAKMP提供建立IPCA必须的机制。IPComp关联由发起者使用提议载荷协商，提议载荷包含一个或多个转换载荷。提议载荷将在协议ID字段指定一个压缩协议，每个转换载荷容纳提供给响应者的具体的压缩方式。<br />
在Internet&nbsp;IPSEC&nbsp;DOI中，IPComp作为协议ID&nbsp;PROTO_IPCOMP来协商。压缩算法作为已定义的IPCOMP转换标识符之一来协商。&nbsp;&nbsp;&nbsp;&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;<br />
4.2.&nbsp;非ISAKMP协议的使用<br />
<br />
&nbsp;&nbsp;&nbsp;动态协商可以通过不同与ISAKMP的协议来协商。这样的协议超出本文档的范围。<br />
<br />
4.3.&nbsp;手工配置<br />
<br />
节点可以手工配置创建IPCA。这种方式下，有限数量的CPI被指定来代表一列特定压缩方式。<br />
<br />
5.&nbsp;安全考虑<br />
<br />
IPComp应用于IPSEC时，它对IPSEC协议提供的、基本的安全功能性没有什么影响；即使用压缩不会降低或者改变基础安全架构的特性或者用于实现IPSEC的加密技术。<br />
如果IPComp没有配合IPSEC使用，IP有效载荷压缩潜在地降低了Internet安全，类似于IP封装的作用[RFC-2003]。例如，IPComp可能对于边界路由器根据头字段过滤数据报是很困难的。特别是，IP头的协议字段的原始值不能放在数据报中它正常的位置，数据报的任何传输层头字段，例如端口号，既不能放在它原始位置也不能在压缩之后以原始值出现。只有过滤边界路由器共享用于压缩的IPCA时，它才可以过滤数据报。在所有数据报都需要过滤的环境中（或者至少这样认为），为了允许这种类型的压缩，必须有一种机制使得接收节点安全地把IPCA传达给边界路由器。这可能，罕有地，也应用于出站数据报使用的IPCA。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
<br />
6.&nbsp;参考<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC-0791]&nbsp;Postel,&nbsp;J.,&nbsp;Editor,&nbsp;"Internet&nbsp;Protocol",&nbsp;STD&nbsp;5,&nbsp;RFC&nbsp;791,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;September&nbsp;1981.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC-1700]&nbsp;Reynolds,&nbsp;J.,&nbsp;and&nbsp;J.&nbsp;Postel,&nbsp;"Assigned&nbsp;Numbers",&nbsp;STD&nbsp;2,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RFC&nbsp;1700,&nbsp;October&nbsp;1994.&nbsp;&nbsp;Or&nbsp;see:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;http://www.iana.org/numbers.html<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC-2460]&nbsp;Deering,&nbsp;S.,&nbsp;and&nbsp;R.&nbsp;Hinden,&nbsp;"Internet&nbsp;Protocol,&nbsp;Version&nbsp;6<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(IPv6)&nbsp;Specification",&nbsp;RFC&nbsp;2460,&nbsp;December&nbsp;1998.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC-1962]&nbsp;Rand,&nbsp;D.,&nbsp;"The&nbsp;PPP&nbsp;Compression&nbsp;Control&nbsp;Protocol&nbsp;(CCP)",<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RFC&nbsp;1962,&nbsp;June&nbsp;1996.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC-2003]&nbsp;Perkins,&nbsp;C.,&nbsp;"IP&nbsp;Encapsulation&nbsp;within&nbsp;IP",&nbsp;RFC&nbsp;2003,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;October&nbsp;1996.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC-2119]&nbsp;Bradner,&nbsp;S.,&nbsp;"Key&nbsp;words&nbsp;for&nbsp;use&nbsp;in&nbsp;RFCs&nbsp;to&nbsp;Indicate<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Requirement&nbsp;Levels",&nbsp;BCP&nbsp;14,&nbsp;RFC&nbsp;2119,&nbsp;March&nbsp;1997.<br />
<br />
&nbsp;&nbsp;&nbsp;[ISAKMP]&nbsp;&nbsp;&nbsp;Maughan,&nbsp;D.,&nbsp;Schertler,&nbsp;M.,&nbsp;Schneider,&nbsp;M.,&nbsp;and&nbsp;J.&nbsp;Turner,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Internet&nbsp;Security&nbsp;Association&nbsp;and&nbsp;Key&nbsp;Management&nbsp;Protocol<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(ISAKMP)",&nbsp;RFC&nbsp;2408,&nbsp;November&nbsp;1998.<br />
<br />
&nbsp;&nbsp;&nbsp;[SECDOI]&nbsp;&nbsp;&nbsp;Piper,&nbsp;D.,&nbsp;"The&nbsp;Internet&nbsp;IP&nbsp;Security&nbsp;Domain&nbsp;of<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Interpretation&nbsp;for&nbsp;ISAKMP",&nbsp;RFC&nbsp;2407,&nbsp;November&nbsp;1998.<br />
<br />
&nbsp;&nbsp;&nbsp;[V42BIS]&nbsp;&nbsp;&nbsp;CCITT,&nbsp;"Data&nbsp;Compression&nbsp;Procedures&nbsp;for&nbsp;Data&nbsp;Circuit<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Terminating&nbsp;Equipment&nbsp;(DCE)&nbsp;Using&nbsp;Error&nbsp;Correction<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Procedures",&nbsp;Recommendation&nbsp;V.42&nbsp;bis,&nbsp;January&nbsp;1990.<br />
<br />
Authors'&nbsp;Addresses<br />
<br />
&nbsp;&nbsp;&nbsp;Abraham&nbsp;Shacham<br />
&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems<br />
&nbsp;&nbsp;&nbsp;170&nbsp;West&nbsp;Tasman&nbsp;Drive<br />
&nbsp;&nbsp;&nbsp;San&nbsp;Jose,&nbsp;California&nbsp;95134<br />
&nbsp;&nbsp;&nbsp;United&nbsp;States&nbsp;of&nbsp;America<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;shacham@cisco.com<br />
<br />
&nbsp;&nbsp;&nbsp;Robert&nbsp;Monsour<br />
&nbsp;&nbsp;&nbsp;Hi/fn&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;2105&nbsp;Hamilton&nbsp;Avenue,&nbsp;Suite&nbsp;230<br />
&nbsp;&nbsp;&nbsp;San&nbsp;Jose,&nbsp;California&nbsp;95125<br />
&nbsp;&nbsp;&nbsp;United&nbsp;States&nbsp;of&nbsp;America<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;rmonsour@hifn.com<br />
<br />
&nbsp;&nbsp;&nbsp;Roy&nbsp;Pereira<br />
&nbsp;&nbsp;&nbsp;TimeStep&nbsp;Corporation<br />
&nbsp;&nbsp;&nbsp;362&nbsp;Terry&nbsp;Fox&nbsp;Drive<br />
&nbsp;&nbsp;&nbsp;Kanata,&nbsp;Ontario&nbsp;K2K&nbsp;2P5<br />
&nbsp;&nbsp;&nbsp;Canada<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;rpereira@timestep.com<br />
<br />
&nbsp;&nbsp;&nbsp;Matt&nbsp;Thomas<br />
&nbsp;&nbsp;&nbsp;AltaVista&nbsp;Internet&nbsp;Software<br />
&nbsp;&nbsp;&nbsp;30&nbsp;Porter&nbsp;Road<br />
&nbsp;&nbsp;&nbsp;Littleton,&nbsp;Massachusetts&nbsp;01460<br />
&nbsp;&nbsp;&nbsp;United&nbsp;States&nbsp;of&nbsp;America<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;matt.thomas@altavista-software.com<br />
<br />
Working&nbsp;Group<br />
<br />
&nbsp;&nbsp;&nbsp;The&nbsp;IP&nbsp;Payload&nbsp;Compression&nbsp;Protocol&nbsp;(IPPCP)&nbsp;working&nbsp;group&nbsp;can&nbsp;be<br />
&nbsp;&nbsp;&nbsp;contacted&nbsp;through&nbsp;its&nbsp;chair:<br />
<br />
&nbsp;&nbsp;&nbsp;Naganand&nbsp;Dorswamy<br />
&nbsp;&nbsp;&nbsp;Bay&nbsp;Networks<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;naganand@baynetworks.com<br />
<br />
Full&nbsp;Copyright&nbsp;Statement<br />
<br />
&nbsp;&nbsp;&nbsp;Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(1998).&nbsp;&nbsp;All&nbsp;Rights&nbsp;Reserved.<br />
<br />
&nbsp;&nbsp;&nbsp;This&nbsp;document&nbsp;and&nbsp;translations&nbsp;of&nbsp;it&nbsp;may&nbsp;be&nbsp;copied&nbsp;and&nbsp;furnished&nbsp;to<br />
&nbsp;&nbsp;&nbsp;others,&nbsp;and&nbsp;derivative&nbsp;works&nbsp;that&nbsp;comment&nbsp;on&nbsp;or&nbsp;otherwise&nbsp;explain&nbsp;it<br />
&nbsp;&nbsp;&nbsp;or&nbsp;assist&nbsp;in&nbsp;its&nbsp;implementation&nbsp;may&nbsp;be&nbsp;prepared,&nbsp;copied,&nbsp;published<br />
&nbsp;&nbsp;&nbsp;and&nbsp;distributed,&nbsp;in&nbsp;whole&nbsp;or&nbsp;in&nbsp;part,&nbsp;without&nbsp;restriction&nbsp;of&nbsp;any<br />
&nbsp;&nbsp;&nbsp;kind,&nbsp;provided&nbsp;that&nbsp;the&nbsp;above&nbsp;copyright&nbsp;notice&nbsp;and&nbsp;this&nbsp;paragraph&nbsp;are<br />
&nbsp;&nbsp;&nbsp;included&nbsp;on&nbsp;all&nbsp;such&nbsp;copies&nbsp;and&nbsp;derivative&nbsp;works.&nbsp;&nbsp;However,&nbsp;this<br />
&nbsp;&nbsp;&nbsp;document&nbsp;itself&nbsp;may&nbsp;not&nbsp;be&nbsp;modified&nbsp;in&nbsp;any&nbsp;way,&nbsp;such&nbsp;as&nbsp;by&nbsp;removing<br />
&nbsp;&nbsp;&nbsp;the&nbsp;copyright&nbsp;notice&nbsp;or&nbsp;references&nbsp;to&nbsp;the&nbsp;Internet&nbsp;Society&nbsp;or&nbsp;other<br />
&nbsp;&nbsp;&nbsp;Internet&nbsp;organizations,&nbsp;except&nbsp;as&nbsp;needed&nbsp;for&nbsp;the&nbsp;purpose&nbsp;of<br />
&nbsp;&nbsp;&nbsp;developing&nbsp;Internet&nbsp;standards&nbsp;in&nbsp;which&nbsp;case&nbsp;the&nbsp;procedures&nbsp;for<br />
&nbsp;&nbsp;&nbsp;copyrights&nbsp;defined&nbsp;in&nbsp;the&nbsp;Internet&nbsp;Standards&nbsp;process&nbsp;must&nbsp;be<br />
&nbsp;&nbsp;&nbsp;followed,&nbsp;or&nbsp;as&nbsp;required&nbsp;to&nbsp;translate&nbsp;it&nbsp;into&nbsp;languages&nbsp;other&nbsp;than<br />
&nbsp;&nbsp;&nbsp;English.<br />
<br />
&nbsp;&nbsp;&nbsp;The&nbsp;limited&nbsp;permissions&nbsp;granted&nbsp;above&nbsp;are&nbsp;perpetual&nbsp;and&nbsp;will&nbsp;not&nbsp;be<br />
&nbsp;&nbsp;&nbsp;revoked&nbsp;by&nbsp;the&nbsp;Internet&nbsp;Society&nbsp;or&nbsp;its&nbsp;successors&nbsp;or&nbsp;assigns.<br />
<br />
&nbsp;&nbsp;&nbsp;This&nbsp;document&nbsp;and&nbsp;the&nbsp;information&nbsp;contained&nbsp;herein&nbsp;is&nbsp;provided&nbsp;on&nbsp;an<br />
&nbsp;&nbsp;&nbsp;"AS&nbsp;IS"&nbsp;basis&nbsp;and&nbsp;THE&nbsp;INTERNET&nbsp;SOCIETY&nbsp;AND&nbsp;THE&nbsp;INTERNET&nbsp;ENGINEERING<br />
&nbsp;&nbsp;&nbsp;TASK&nbsp;FORCE&nbsp;DISCLAIMS&nbsp;ALL&nbsp;WARRANTIES,&nbsp;EXPRESS&nbsp;OR&nbsp;IMPLIED,&nbsp;INCLUDING<br />
&nbsp;&nbsp;&nbsp;BUT&nbsp;NOT&nbsp;LIMITED&nbsp;TO&nbsp;ANY&nbsp;WARRANTY&nbsp;THAT&nbsp;THE&nbsp;USE&nbsp;OF&nbsp;THE&nbsp;INFORMATION<br />
&nbsp;&nbsp;&nbsp;HEREIN&nbsp;WILL&nbsp;NOT&nbsp;INFRINGE&nbsp;ANY&nbsp;RIGHTS&nbsp;OR&nbsp;ANY&nbsp;IMPLIED&nbsp;WARRANTIES&nbsp;OF<br />
&nbsp;&nbsp;&nbsp;MERCHANTABILITY&nbsp;OR&nbsp;FITNESS&nbsp;FOR&nbsp;A&nbsp;PARTICULAR&nbsp;PURPOSE.<br />
<br />
<br />
[&nbsp;Index&nbsp;|&nbsp;Search&nbsp;|&nbsp;What's&nbsp;New&nbsp;|&nbsp;Comments&nbsp;|&nbsp;Help&nbsp;]&nbsp;<br />
Comments/Questions&nbsp;about&nbsp;this&nbsp;archive&nbsp;?&nbsp;Send&nbsp;mail&nbsp;to&nbsp;rfc-admin@faqs.org&nbsp;<br />
<br />