本備忘錄的現狀

本文檔的現狀

本文當描述了一種供Internet協會采用的Internet標準跟蹤協議，尚需對之進行討論并提出建議以待改進。本協議的標準化進程請參考最新版的“Internet正式協議標準”（STD1）。本文檔可以無限制的分發。

CopyrightNotice

Copyright(C)TheInternetSociety(2000).AllRightsReserved.

摘要

GRE(通用路由封裝)定義了在任意一種網絡層協議上封裝另一個協議的規范。本文檔描述了GRE頭部（參考文獻[1]）可能攜帶的兩個擴展域即Key和SequenceNumber。

1.簡介

當前的通用路由封裝規范（參考文獻[1]）定義了在任意一種網絡層協議上封裝另一個協議的規范。本文檔描述了GRE頭部（參考文獻[1]）可能攜帶的兩個擴展域即Key和SequenceNumber。其中Key域主要用來標識隧道內單個的業務流，SequenceNumber域用來維持GRE隧道內數據報文的順序。

1.1.規范用語
要害詞“必須”,“不答應”，“必要的”，“應”，“不應”，“應該”，“不應該”，“建議”，“可能”,“可選”，按RFC2119（參考文獻[3]）的定義進行解釋。


另外，下面的詞語用來表示規范的要求：

靜靜的丟棄
實現不對數據報文作更多處理而只是簡單的丟棄報文，同時不向發送方表明出錯。實現應該提供記錄錯誤的功能，包括被丟棄數據報文的內容，同時應該在一個統計計數器中記錄該事件。



2.GRE頭部的擴展

GRE數據報文的頭部（參考文獻[1]）擁有下面的格式:

01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CReserved0VerPRotocolType
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Checksum(optional)Reserved1(Optional)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

推薦使用的GRE頭部將擁有下面的格式:

01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CKSReserved0VerProtocolType
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Checksum(optional)Reserved1(Optional)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key(optional)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SequenceNumber(Optional)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


KeyPresent(bit2)

假如KeyPresent比特位置為1,那么表明GRE頭部中出現Key域。否則，GRE頭部中不出現Key域。

SequenceNumberPresent(bit3)

假如SequenceNumberPresent比特位置為1，那么表明出現SequenceNumber域。否則，GRE頭部中不出現SequenceNumber域。

Key和SequencePresent比特根據與RFC1701(參考文獻[2])兼容來選取。

2.1.Key域(4octets)

Key域是由封裝者插入的四個字節的數。實際獲得Key的方法超出了本文檔的范疇。Key域主要用來標識隧道內部單個的業務流。例如,數據報文可能需要根據某些上下文信息來選擇路由，而這些上下文信息不出現在所封裝的數據中。Key域提供了這樣的上下文，并定義了在封裝者和拆封者之間的邏輯業務流。屬于同一個業務流的數據報使用同一個Key值來封裝，隧道的拆封點根據Key域的值識別屬于某個業務流的數據報文。

2.2.SequenceNumber(4octets)

SequenceNumber域是當SequenceNumberPresent比特位置為1時由封裝方插入的一個四個字節的數值。接收者必須根據SequenceNumber來建立從封裝者到拆封者之間傳送的數據報文的順序。使用Sequence域主要是提供不可靠但順序的傳輸。假如Keypresent比特位(bit2)置為1,sequencenumber特定于由Key標識的業務流。注重sequence比特位沒有置位的數據報文可以和sequence比特位置位的數據報文交替發送。

序列號的取值范圍從0到（2**32）-1。第一個數據報發送時序列號為0。這樣序列號就是一個自由運行的由模2**32表示的計數器。接收方保留上一次成功拆封的報文的序列號值。在建立GRE隧道時,這個值應該設為(2**32)-1。

當拆封者接收到一個無效序列號的數據報文時，它應該靜靜的丟棄該數據報文。當收到的數據報文的序列號小于或等于上一次成功拆封的數據報文的序列號時，收到的報文被視為序列號無效。收到消息的序列號的值假如處于上一次成功收到的序列號和該序列號的前2**31-1個值之間時（包括這兩個值），它被認為是小于或者等于上一次成功收到的序列號。
假如接收到的數據報文序列號有效，它被成功拆封。序列號有效的數據報文是序列號比上一個成功拆封數據報文的序列號正好大1（模2**32）,或者sequencenumber域不出現的數據報文(S位沒有置位)。
假如接收到的數據報文既不是有效序列號的數據報，也不是無效序列號的數據報，表明出現了一個序列號缺口（sequencenumbergap）。接收者可以試圖執行較小的緩沖來恢復已發送數據報文的最初的順序。在這種情況下,數據報文可以放在以序列號排序的緩沖區中。假如收到一個有效序列號的數據報文并被成功拆封。接收者應該查詢緩沖區的頭部來判定是否下一個有效序列號的數據報文已經到達。假如是,接收者應該同緩沖區中可能出現的其他緊接著的有效序列號報文一樣進行拆封。“上一個成功拆封的序列號”應該隨后被置為最后一個從緩沖區中拆封的數據報的序列號。
在任何情況下，緩沖區中的任何一個數據報都不會等待超過OUTOFORDER_TIMER微秒。假如一個數據報文已經等待了那么長時間,接收者必須立即按所排的順序遍歷緩沖區，拆封報文(忽略任意序列號缺口)直到緩沖區中沒有等待超過OUTOFORDER_TIMER微秒的數據報文。“上一個成功拆封的序列號”應該隨后被置為最后一個從緩沖區中拆封的數據報的序列號。
接收者可以對每一個業務流（擁有同一個Key值的數據報文屬于同一個業務流）的緩沖報文的數量加以限制，假如可導致接收者在一個給定緩沖區中放置多于MAX_PERFLOW_BUFFER個數據報文,那么緩沖區頭的數據報文立即被拆封，而不管起序列號，“上一個成功拆封的序列號”置為其序列號。然后把新到達的數據報文放到緩沖區中。
注重序列號用來檢測丟失的數據報文與/或恢復在傳輸中可能已經失序的數據報文的最初順序（使用緩沖）。應該適當地使用序列號選項；非凡地,當隧道協議的高層協議包括有效序列號傳輸機制或者可忍受失序傳輸時，避免使用序列號選項將不失為一個好主意。僅在特定情況下GRE隧道攜帶的協議要求有序交付時,僅相應的封裝在GRE中數據報文可以在發送時設置sequence比特位。
失序數據報文的重新排序可以由拆封者執行，以提高性能以及對網絡重新排序的容錯性。當高層協議使用了含狀態壓縮或加密時，提供一個小的重排序緩沖區(MAX_PERFLOW_BUFFER)將有助于提高性能。因為含狀態壓縮或加密的狀態因為報文的丟失而重置，緩沖將有助于提高網絡對少數報文的重排序的容忍性。

3.安全方面的考慮

本文檔描述了GRE頭部（參考文獻[1]）可能攜帶的兩個擴展域即Key和SequenceNumber。當使用Sequencenumber域時,通過給報文填入一個隨意的序列號從而發起一個拒絕服務攻擊（DenialofService）是可能的。為了防止受此類攻擊,必須使用ip安全協議（參考文獻[4]）來保護GRE頭部以及隧道的凈載。ESP(封裝安全凈載，EncapsulatingSecurityPayload，參考文獻[5])或者AH(認證頭，參考文獻[6])必須用來保護GRE頭部。假如使用ESP，它保護IP凈載包括GRE。假如使用AH,對整個數據報文而不是某些域進行認證。注重在排序或安全方面都不涉及(不管它的名字的意義)。

4.IANA方面的考慮

本文檔不要求任何IANA分配的資源，因此不需要IANA方面作其他考慮。

5.致謝

本文檔來源于RFC1701的原作者的最初思想。KentLeung,PeteMcCann,MarkTownsley,DavidMeyer,YingchunXu,AjoySingh以及其他人提供了有用的討論。作者向上述所有人員表示感謝。


















6.參考文獻

[1]Farinacci,D.,Li,T.,Hanks,S.,Meyer,D.andP.Traina,
"通用路由封裝(GRE)",RFC2784,March2000.

[2]Hanks,S.,Li,T,Farinacci,D.,andP.Traina,"通用路由封裝",RFC1701,October1994.

[3]BradnerS.,"RFC中表明要求等級使用的要害詞Levels",BCP14,RFC2119,March1997.

[4]Kent,S.andR.Atkinson,"IP的安全結構",RFC2401,November1998.

[5]Kent,S.andR.Atkinson,"IP封裝安全凈載(ESP)",RFC2406,November1998.

[6]Kent,S.,andR.Atkinson,"IP認證頭",RFC2402,
November1998.

作者地址

GopalDommety
CiscoSystems,Inc.
170WestTasmanDrive
SanJose,CA95134

EMail:gdommety@cisco.com


















完整的版權通告

Copyright(C)TheInternetSociety(2000).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.