本备忘录状态
ThisdocumentspecifiesanInternetstandardstrackprotocolforthe
Internetcommunity,andrequestsdiscussionandsuggestionsfor
improvements.Pleaserefertothecurrenteditionofthe"Internet
OfficialProtocolStandards"(STD1)forthestandardizationstate
andstatusofthisprotocol.Distributionofthismemoisunlimited.
版权声明
Copyright(C)TheInternetSociety(1998).AllRightsReserved.
摘要
本文档描述用于在INTERNET环境中为IP层提供无损耗压缩的协议。
1.介绍
IP有效载荷压缩是一个减少IP数据报长度的协议。通过压缩数据报，这个协议将在一对通信主机/网关（“节点”）之间提升整体通信性能。倘若节点有足够的计算能力，透过CPU功能或者一个压缩协处理器，在慢速或者拥挤的链路上通信。
IP数据报加密时，IP有效载荷压缩非凡有用。加密IP数据报使得数据看起来很随机，在较低协议层压缩效率低（例如，PPP压缩控制协议[RFC-1962]）。假如同时要求压缩和加密，压缩必须在加密之前进行。
本文档定义了IP有效载荷压缩协议(IPComp)、IPComp包结构、IPComp安全关联（IPCA），和几种协商IPCA的方式。
其他文档具体说明一个特定压缩算法如何与IP有效载荷压缩协议一起使用。这样的算法超出本文档范围之外。
1.1.要求规范
本文档中的要害字"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT",
"SHOULD","SHOULDNOT","RECOMMENDED","MAY",and"OPTIONAL"由RFC2119[RFC-2119]解释。
2.压缩过程
IP数据报压缩处理过程包含两个阶段：出站IP数据报压缩和入站数据报解压。压缩处理必须是无损耗的，确保IP数据报在压缩和解压缩之后，与原始的IP数据报一致。
每个IP数据报单独地被压缩和解压，与其他数据报没有任何关联（无状态压缩）。因为IP数据报可能无序地到达或者丢失。每个压缩的IP数据报封装单个IP有效载荷。
入站IP数据报的处理必须支持压缩和未压缩IP数据报，以便满足非扩展策略要求，它在2.2节定义。出站IP数据报压缩必须在任何IP安全处理之前进行，例如加密和验证，必须在IP数据报分片之前进行。另外，IPv6中，出站IP数据报压缩必须在Hop-by-Hop选项头或者Routing头添加之前进行。因为它们被数据报传递路径上的各个节点检查和处理，所以必须以原始形式发送。
类似地，入站IP数据报的解压必须在IP数据报重组之后，在所有IP安全处理完成之后进行，例如验证和解密。
2.1.压缩的有效载荷
压缩应用于单列字节，在IP数据报中它们相邻。这列字节总是以IP数据报有效载荷的最后字节结束。注重：IP数据报中相邻的一列字节可能在物理内存中不相邻。
IPv4中，压缩应用于IP数据报的上层协议有效载荷。IP头或者IP头中的选项不压缩。
IPv6中，IPComp被看作端到端的有效载荷，不答应用于hop-by-hop、routing、和分片扩展头。压缩从第一个IP头选项字段开始，因为它没有必须由数据报传递路径上必须检测和处理的信息。假如这样的IP头选项存在，继续至IP数据报的上层协议载荷。
一个被压缩的有效载荷长度，由压缩算法产生的，必须以字节为单位。
按照第3节定义，一个IPComp头直接插入已压缩的有效载荷之前。原始IP头需要修改，以表明使用IPComp协议和减少的IP数据报长度。下一个头（IPv6）字段或者协议字段(IPv4)的原始内容保存在IPComp头。
解压缩应用IP数据报中单列相邻的字节。这列字节的头紧跟IPComp头，以IP有效载荷的最后字节结束。假如解压缩完全成功，IP头需要修改，以便指示解压后IP数据报的长度，从IPComp头中恢复原始的下一个头字段值。IPComp头从IP数据报中删除，解压之后的有效载荷紧跟在IP头之后。
2.2.非扩展策略
假如已压缩的上层协议数据和IPComp头的总长度，第3节定义的，不小于原来上层协议数据的长度，IP数据报必须以不压缩的格式发出。需要阐明：假如IP数据报没有压缩就发出，不会添加IPComp头。这个策略确保节省解压缩过程的循环，避免扩展数据报大于MTU时，IP数据报分片。
小的IP数据报有可能压缩之后却扩大，所以，压缩之前应该定义一个最小的数值极限。假如IP数据报小于这个值，不压缩而以原始格式发出该数据报。最小数值极限的定义与实现有关。
一个数据报的有效载荷已经压缩过，往往不再进一步压缩。先前已压缩的有效载荷可能是外部处理的结果，例如在通信栈高层应用的压缩，或者由离线压缩工具进行的压缩。应该实现一种适应性的算法避免性能受到影响。例如，假如一个IPCA上I个连续IP数据报压缩失败，下面k个IP数据报将不尝试压缩而被发送出去。假如再下面j个数据报压缩又失败了，那么后面k+n个数据报将不尝试压缩直接发送。一旦一个数据报成功压缩，IPComp正常处理重新开始。这样的适应性算法，包括所有相关的最低限度，与实现有关。
有效载荷处理期间，压缩算法可能定期进行测试，确定被处理数据的可压缩性，类似与[V42BIS]的要求。测试的特性和算法相关。一旦压缩算法检测到数据不可压缩，算法应该停止处理数据，有效载荷以原始、不压缩格式传递。
3.已压缩的IP数据报头结构
一个已压缩的IP数据报通过修改IP头，在被压缩的有效载荷之前插入IPComp头，来封装它。本节定义IPv4和IPv6中IP头修改的字段和IPComp头结构。
3.1.IPv4头修改字段
下面IPv4头字段在传输已压缩的IP数据报之前设置：
TotalLength总长度
整个被封装的IP数据报长度，包括IP头、IPComp头和已压缩的有效载荷。
Protocol协议
设置为108，表示IPComp数据报。[RFC-1700]
HeaderChecksum首部校验和
IP头的内部头校验和。[RFC-0791]
所有其它IPv4头字段保持不变，包括所有头中的选项。
3.2.IPv6头修改
下列IPv6头字段在传输压缩IP数据报之前设置。
PayloadLength载荷长度
压缩IP载荷长度
NextHeader下一个头
该字段设置为108，表示IPComp数据报[RFC-1700]
所有其他的IPv6头字段保持不变，包括任何没有压缩的头选项。
IPComp头放置在IPv6数据报中采用与IPv6Fragment头一样的规则。然而，假如IPv6数据报同时包含IPv6Fragment头和IPComp头，IPv6Fragment头必须在IPComp头之前。
3.3.IPComp头结构
4字节的头结构如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NextHeaderFlagsCompressionParameterIndex
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NextHeader下一个头
8位选择子。存储原始IP头中的IPv4协议字段或者IPv6NextHeader字段。
Flags标志
8位字段，保留给将来使用。必须设置为0，接收节点必须忽略它。
CompressionParameterIndex(CPI)压缩参数索引
16位索引。按网络字节序存储。0-63定义了有名的压缩算法，这些算法不要求额外信息，用于手工设置。这些值本身与[SECDOI]定义的OMP转换标识符相同。参考[SECDOI]获取一组初始已定义的值，得到如何分配新值的指示。64-255保留给将来使用。256-61439在两个节点之间定义一个IPCA时协商。注重：当协商有名的算法之一时，节点可能选择预定义的0-63之间的值作为CPI。61440-65535主要是互相同意的各方私下使用。两个参与的节点可以选择一个CPI值，彼此独立，两个选择的CPI之间没有关系。出站IPComp头必须使用由解压缩节点选择的CPI值。CPI和目的IP地址一起，唯一地标识数据报压缩算法的特征。
4.IPCompAssociation(IPCA)协商
为了利用IPComp协议，两个节点彼此必须首先建立一个IPComp关联（IPCA）。IPCA包括IPComp操作要求的所有信息，包括CPI、操作模式、使用的压缩算法，和任何选择的压缩算法要求的参数。IPComp操作模式可以是节点对节点策略，即IPComp用于节点之间所有数据报，或者基于策略的一次上层协议会话，只有节点之间选择的上层协议对话使用IPComp。对于每个IPCA，在每个方向上，可能协商不同的压缩算法，或者只有单向压缩。默认“没有IPComp压缩”
IPCA可以通过动态协商或者手工配置创建。动态协商应该使用ISAKMP，在IPSEC出现的地方。动态协商可以通过不同的协议实现。
4.1.ISAKMP的使用
IPComp用于IP安全时，ISAKMP提供建立IPCA必须的机制。IPComp关联由发起者使用提议载荷协商，提议载荷包含一个或多个转换载荷。提议载荷将在协议ID字段指定一个压缩协议，每个转换载荷容纳提供给响应者的具体的压缩方式。
在InternetIPSECDOI中，IPComp作为协议IDPROTO_IPCOMP来协商。压缩算法作为已定义的IPCOMP转换标识符之一来协商。
4.2.非ISAKMP协议的使用
动态协商可以通过不同与ISAKMP的协议来协商。这样的协议超出本文档的范围。
4.3.手工配置
节点可以手工配置创建IPCA。这种方式下，有限数量的CPI被指定来代表一列特定压缩方式。
5.安全考虑
IPComp应用于IPSEC时，它对IPSEC协议提供的、基本的安全功能性没有什么影响；即使用压缩不会降低或者改变基础安全架构的特性或者用于实现IPSEC的加密技术。
假如IPComp没有配合IPSEC使用，IP有效载荷压缩潜在地降低了Internet安全，类似于IP封装的作用[RFC-2003]。例如，IPComp可能对于边界路由器根据头字段过滤数据报是很困难的。非凡是，IP头的协议字段的原始值不能放在数据报中它正常的位置，数据报的任何传输层头字段，例如端口号，既不能放在它原始位置也不能在压缩之后以原始值出现。只有过滤边界路由器共享用于压缩的IPCA时，它才可以过滤数据报。在所有数据报都需要过滤的环境中（或者至少这样认为），为了答应这种类型的压缩，必须有一种机制使得接收节点安全地把IPCA传达给边界路由器。这可能，罕有地，也应用于出站数据报使用的IPCA。
6.参考
[RFC-0791]Postel,J.,Editor,"InternetProtocol",STD5,RFC791,
September1981.
[RFC-1700]Reynolds,J.,andJ.Postel,"AssignedNumbers",STD2,
RFC1700,October1994.Orsee:
http://www.iana.org/numbers.Html
[RFC-2460]Deering,S.,andR.Hinden,"InternetProtocol,Version6
(IPv6)Specification",RFC2460,December1998.
[RFC-1962]Rand,D.,"ThePPPCompressionControlProtocol(CCP)",
RFC1962,June1996.
[RFC-2003]Perkins,C.,"IPEncapsulationwithinIP",RFC2003,
October1996.
[RFC-2119]Bradner,S.,"KeyWordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.
[ISAKMP]Maughan,D.,Schertler,M.,Schneider,M.,andJ.Turner,
"InternetSecurityAssociationandKeyManagementProtocol
(ISAKMP)",RFC2408,November1998.
[SECDOI]Piper,D.,"TheInternetIPSecurityDomainof
InterpretationforISAKMP",RFC2407,November1998.
[V42BIS]CCITT,"DataCompressionProceduresforDataCircuit
TerminatingEquipment(DCE)UsingErrorCorrection
Procedures",RecommendationV.42bis,January1990.
Authors'Addresses
AbrahamShacham
CiscoSystems
170WestTasmanDrive
SanJose,California95134
UnitedStatesofAmerica
EMail:shacham@cisco.com
RobertMonsour
Hi/fnInc.
2105HamiltonAvenue,Suite230
SanJose,California95125
UnitedStatesofAmerica
EMail:rmonsour@hifn.com
RoyPereira
TimeStepCorporation
362TerryFoxDrive
Kanata,OntarioK2K2P5
Canada
EMail:rpereira@timestep.com
MattThomas
AltaVistaInternetSoftware
30PorterRoad
Littleton,Massachusetts01460
UnitedStatesofAmerica
EMail:matt.thomas@altavista-software.com
WorkingGroup
TheIPPayloadCompressionProtocol(IPPCP)workinggroupcanbe
contactedthroughitschair:
NaganandDorswamy
BayNetworks
EMail:naganand@baynetworks.com
FullCopyrightStatement
Copyright(C)TheInternetSociety(1998).AllRightsReserved.
Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseeXPlainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsUChcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.
Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.
