本備忘錄狀態

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.