RFC2344 移動IP反向隧道

本備忘錄狀態
ThismemoprovidesinformationfortheInte.netcommunity.Itdoes
notspecifyanInternetstandardofanykind.Distributionofthis
memoisunlimited.
版權聲明
Copyright(C)TheInternetSociety(1999).AllRightsReserved.

摘要

移動IP在家鄉代理和移動節點的轉交地址之間使用隧道，但在相反方向卻很少使用。通常，移動節點通過一臺位于外地網絡上的路由器發送數據包，并假定數據包的路由與源地址無關。如果該假設不成立（即路由與源地址有關）,就可以很方便地在轉交地址和家鄉代理之間建立起一個拓撲上正確（topologicallycorrect）的反向隧道。
本文檔推薦移動IP的一種向后兼容的擴展以支持在拓撲上正確的反向隧道。由位于家鄉代理和移動節點轉交地址之間的防火墻所引發的各種問題，本文檔不予解決。




目錄
1.簡介 3
1.1.術語 4
1.2.假定 4
1.3.合理性 5
2.總述 5
3.新的數據包格式 5
3.1.移動代理廣告擴展 5
3.2.注冊請求 6
3.3.封裝發送方式擴展 7
3.4.新的注冊應答碼 7
4.協議工作方式的變化 8
4.1.移動節點方面的考慮 8
4.1.1.給外地代理發送注冊請求 8
4.1.2.接收來自外地代理的注冊應答 8
4.2.外地代理方面的考慮 9
4.2.1.接收來自移動節點的注冊請求 9
4.2.2.把注冊請求中繼到家鄉代理 9
4.3.家鄉代理方面的考慮 10
4.3.1.從外地代理接收注冊請求 10
4.3.2.向外地代理發送注冊應答 10
5.移動節點到外地代理的發送方式 10
5.1.直接發送方式 11
5.1.1.數據包的處理 11
5.1.2.數據包頭部格式及各域 11
5.2.封裝發送方式 12
5.2.1數據包的處理 12
5.2.2.數據包頭部格式及各域 12
5.3.廣播和多播數據報的支持 13
5.4.可選的反向隧道 13
6.安全方面的考慮 14
6.1.反向隧道劫機及拒絕服務攻擊 14
6.2.入口處過濾 14
7.致謝 14
參考文獻 14
編輯和主席地址 15
完整版權通告 16






1.簡介
移動IP（參考文獻[1]）的1.3列出了下面的假設:
我們假設IP單播數據報的路由基于數據報頭的目的地址(也就是說，不是根據源地址進行路由)。
出于安全方面的考慮(例如IP欺騙攻擊),以及根據RFC2267（參考文獻[8]）和CERT(參考文獻[3])的建議,不遵循這個假設的路由器正在變得越來越常見。
在這種路由器中數據包中的源地址和目的地址必須在拓撲上正確。前向隧道符合這一點，因為其端點(家鄉代理和轉交地址)各自被指定了正確的地址。但是另一方面,移動節點發送的數據包的源IP地址與其發送地的網絡前綴不一致。
本文檔討論在拓撲上正確的反向隧道。

RFC2344ReverseTunnelingforMobileIPMay1998

移動IP在多播數據報和移動路由器的情況下沒有規定使用反向隧道。但是,源IP地址被設置為移動節點的家鄉地址，因此這些隧道在拓撲上不正確。
注意不管拓撲正確性如何，反向隧道有幾個用處：

-移動路由器:反向隧道不需要遞歸隧道（參考文獻[1]）。

-多播:反向隧道使得遠離家鄉的移動節點能夠
(1)加入到其家鄉網絡的多播組
(2)發送多播數據報以便能夠從其家鄉網絡發出（參考文獻[1]）

-移動節點發送的數據包的TTL可能太小以至于在到達目的地之前就到期（例如，在發送數據報到其家鄉網絡上的其他主機時）。反向隧道解決了這個問題，因為它表現出來的只是TTL減1（參考文獻[5]）。
1.1.術語
下面的討論使用了移動IP規范中定義的術語。另外，還使用了下面的術語:

前向隧道
把數據包發向移動節點的隧道。它始于家鄉代理，終止于移動節點的轉交地址。
反向隧道
始于移動節點的轉交地址，終止于家鄉代理的隧道。
本文當出現的關鍵詞“必須(MUST)”，“不允許(MUSTNOT)”，“要求（REQUIRED）”，“應該（SHALL）”,“不應該（SHALLNOT）”，“應該（SHOULD）”，“不應該（SHOULDNOT）”，“建議（RECOMMENDED）”，“可以(MAY)”，“可選（OPTIONAL）”等按RFC2119（參考文獻[9]）解釋。（本文檔的中譯版將以粗體字加上紅色顯示）。


1.2.假定
移動性限制為一個通用的IP地址空間(舉個例子，也就是說，移動節點與家鄉代理之間的路由結構并不分為“專用”和“公用”網絡)。

本文檔不解決穿越防火墻的問題。而是假設下述條件之一成立：

-數據包傳送所經過的隧道沿途沒有防火墻。
-任何位于其間的防火墻共享必要的安全聯合來處理可能已經添加到數據包頭部中的認證部分（參考文獻[6]）或者加密部分（參考文獻[7]）。

這里討論的反向隧道是對稱的，就是說，它使用與前向隧道相同的配置（使用相同的封裝方法，相同的IP地址作為隧道的端點）。除非指明別的封裝方法，總是假設使用IP-in-IP封裝（參考文獻[2]）。

路由最優化（參考文獻[4]）引進了通信主機發起的前向隧道。因為移動節點可能不知道對方主機是否能對數據包進行拆封,在這種情況下的反向隧道在這里不予討論。
1.3.合理性
為什么不讓移動節點自己發起到家鄉代理的隧道呢？實際上，這正是移動節點在以一個在拓撲上正確的配置轉交地址操作時應該做的。

但是，移動IP規范的一個基本設計目標就是不要求這種模式的操作。

本文檔大致描述的機制主要用于前向隧道依賴于外地代理的移動節點。我們所希望的就是繼續支持這些移動節點，即使在出現過濾路由器的場合。
2.總述
移動節點到達一個外地網絡，偵聽代理廣告并選中一個支持反向隧道的外地代理。當它通過該選中的外地代理注冊時它請求使用反向隧道。此時，移動節點還根據它向外地代理發送數據包的方式在注冊請求中表明是使用直接發送方式還是封裝發送方式（見5節）。

在直接發送方式中，移動節點把外地代理指明為其缺省路由器并直接把數據包發送到外地代理，也就是說沒有經過封裝。外地代理截獲這些數據包，并通過隧道把他們傳送到家鄉代理。

在封裝發送方式中，移動節點把所有待發送的數據包進行封裝。外地代理對這些數據包進行拆封并通過第二個隧道把他們傳送到家鄉代理，在第二個隧道，隧道的入口點是外地代理轉交地址。

3.新的數據包格式
3.1.移動代理廣告擴展
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
Type
Length
SequenceNumber
Lifetime
R
B
H
F
M
G
V
T
reserved
ZeroormoreCare-ofAddresses
......


移動代理廣告擴展（參考文獻[1]）的唯一的變化是多出了一個“T”位：

T代理提供反向隧道服務。

設置了“T”位的外地代理必須支持當前支持的兩種發送方式：直接發送方式和封裝發送方式（見第5節）。

通過這些信息，移動節點能夠選擇一個支持反向隧道的外地代理。注意如果移動節點不理解這一位,它簡單的把它忽略（參考文獻[1]）。
3.2.注冊請求
在注冊請求中直接加入一個“rsvd”位來請求反向隧道的支持。如果不支持反向隧道的外地代理或家鄉代理收到設置“T”位的注冊請求，則該注冊請求將失敗。這將導致一個拒絕注冊（拒絕碼在第3.4節定義）。

大多數的家鄉代理不拒絕提供反向隧道支持，因為他們“應該能對移動節點發給它的數據包進行拆封并進行進一步傳送”（參考文獻[1]）。在拓撲正確的反向隧道中，移動節點發送數據包時并不是以其家鄉地址來區分，相反，這些數據包的外層（封裝層）源IP地址為移動節點的轉交地址。盡管如此，家鄉代理也許已經支持所要求的拆封及進一步轉發功能。

在移動節點發送的注冊請求中，IP頭部的生存期（TimetoLive）域必須設置為255。這樣就限制了惡意主機發送虛假注冊請求而導致的拒絕服務攻擊（見第6章）。

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
Type
S
B
D
M
G
V
Y
-
Lifetime
HomeAddress
HomeAgent
Care-ofAddress
Identification
Extentions......


注冊請求數據包中唯一的變化就是多出來的“T”位：
T如果設置了“T”位，則移動節點請求其家鄉代理接受始于轉交地址的隧道。
移動節點使用外地代理轉交地址請求外地代理使用反向隧道傳送其數據包。
3.3.封裝發送方式擴展
移動節點可以在注冊請求中包含封裝發送方式擴展以進一步指定反向隧道的工作方式。我們認為只有外地代理用到該擴展。因此，外地代理必須處理掉該擴展（也就是說，外地代理不能把該擴展中繼到家鄉代理，也不能在發送給移動節點的應答中包含該擴展）。

如（參考文獻[1]）中3.6.1.3中所述，如果出現封裝發送方式擴展，移動節點必須在注冊請求中把該擴展置于Mobile-Home認證擴展之后，Mobile-Foreign認證擴展之前。

如果注冊請求中沒有設置“T”位，則該請求不允許包含封裝發送方式擴展。

如果沒有出現該擴展，就假設發送方式為直接發送方式。封裝根據前向隧道的協商結果來進行(也就是說，除非指定其他方式，總是假設為IP-in-IP)。發送方式的細節請參考第5節。

0
1
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
Type
Length

Type
130
Length
0
3.4.新的注冊應答碼
如果反向隧道請求失敗，外地代理和家鄉代理必須發送注冊應答。新的應答碼定義如下：
服務被外地代理拒絕：
74請求的反向隧道不可用
75強制使用反向隧道但沒有設置“T”位
76移動節點太“遠”

以及

服務被家鄉代理拒絕:

137請求的反向隧道不可用
138強制使用反向隧道但沒有設置“T”位
139請求的封裝不可用

對應于設置“T”位的注冊請求,移動節點可能分別收到（而且必須接受）來自外地代理的code70(poorlyformedrequest)和來自家鄉代理的code134（poorlyformedrequest）。但是支持反向隧道的外地代理和家鄉代理必須分別使用code74和code137.

沒有設置“T”位的注冊請求可能分別從外地代理和家鄉代理收到code75和code138。

前向隧道和反向隧道時對稱的，也就是說，兩者都能使用注冊時協商的隧道選項。這就暗示著家鄉代理如果收到包含不支持形式的隧道的注冊請求時必須拒絕該注冊（code139）。注意移動IP（參考文獻[1]）已經定義了外地代理類似的拒絕碼（失敗碼）。
4.協議工作方式的變化
除非另外指出，總是假設使用移動IP（參考文獻[1]）中規定的工作狀況。特別地，如果兩個實體共享移動安全聯合，他們必須在傳送注冊數據報文時使用正確的認證擴展（Mobile-Foreign,Foreign-Home或者Mobile-Home認證擴展）。Mobile-Home認證擴展總是必須出現。

反向隧道要求移動實體進行多出移動IP規范的協議處理。與移動IP（參考文獻[1]）協議工作狀況的不同之處在隨后的章節中描述。
4.1.移動節點方面的考慮
本節描述移動節點如何在注冊中請求反向隧道。
4.1.1.給外地代理發送注冊請求
除了參考文獻[1]中的考慮，移動節點在注冊請求中設置“T”位來請求反向隧道。

移動節點必須把IP頭部的TTL域設置為255。這樣做是為了限制反向隧道中的“劫機攻擊”(見第6章)。

移動節點在注冊請求中還可以（可選地）包含一個封裝傳送方式擴展。
4.1.2.接收來自外地代理的注冊應答
可能的有效應答為:

-由家鄉代理或者外地代理發送的拒絕注冊:
a.移動節點遵循參考文獻[1]中的檢錯原則，根據應答重的錯誤碼（失敗碼）可以試圖修改該注冊請求（例如，從注冊請求中去除可選形式的封裝）并發送一個新的注冊。
b.根據應答錯誤碼（失敗碼）,移動節點可以試圖把“T”位清零，去掉封裝發送方式擴展（如果出現的話），并發送一個新的注冊。注意這樣做之后注冊可能成功，但由于沒有反向隧道，數據傳輸可能無法進行。

-家鄉代理返回注冊應答，表明將提供（所請求的）服務（即反向隧道）。

在最后一種情形中，移動節點已經在其轉交地址和家鄉代理之間成功建立起一條反向隧道。如果移動節點以配置轉交地址操作，它可以對待發送數據包進行封裝以使得外層頭部的目的地址為家鄉代理的地址。這種把數據包通過反向隧道發送的能力我們在第5.4節還要深入討論。
如果轉交地址屬于一個單獨的外地代理，則移動節點必須使用所請求的無論哪一種發送方式（直接發送或者封裝發送）并繼續第5章中描述的過程。

成功的注冊應答保證了外地代理和家鄉代理都支持所請求的不管那種可選形式的封裝（除了IP-in-IP之外）。因而，移動節點可以自己判斷使用（哪一種封裝方式）。
4.2.外地代理方面的考慮
本節描述了外地代理如何處理反向隧道的注冊請求。
4.2.1.接收來自移動節點的注冊請求
外地代理在收到設置了“T”位的注冊請求時按移動IP規范（參考文獻[1]）中描述的那樣對數據包進行處理（即合法性檢查，向家鄉代理轉發等），并判斷它是否能容納該前向隧道請求。如果不能，則返回一個合適的錯誤碼（失敗碼）。特別地，如果外地代理不能支持所請求形式的封裝，它必須返回錯誤碼72。

外地代理可以使用錯誤碼75（強制使用反向隧道但注冊請求沒有設置“T”位）來拒絕不設置“T”位的注冊請求。

外地代理必須核實以確保IP頭部的TTL域設置為255。否則，它必須使用錯誤碼76（移動節點太“遠”）來拒絕該注冊。外地代理必須把其發送注冊應答的速率限制為最大一秒鐘一次。

作為最后的檢查，外地代理核實以確保它能支持相同配置的反向隧道。如果不能，它必須發送錯誤碼74（請求的反向隧道不可用）的注冊應答。
4.2.2.把注冊請求中繼到家鄉代理
否則，外地代理必須把該注冊請求中繼到家鄉代理。

一旦接收到滿足合法性檢查的注冊應答，外地代理必須更新其訪問者列表，包括暗示移動節點其請求的反向隧道和發送方式已經獲準（第5章）。

在該訪問者（移動節點）表項有效期間，外地代理必須根據其發送方式處理來自該訪問者（移動節點）的數據流量，對數據包進行封裝并把它們送入由轉交地址到家鄉代理的隧道。
4.3.家鄉代理方面的考慮
本節描述家鄉代理如何處理請求反向隧道的注冊請求。
4.3.1.從外地代理接收注冊請求
家鄉代理在收到設置了“T”位的注冊請求時，對數據包的處理遵循移動IP規范（參考文獻[1]），并判斷是否能容納該前向隧道請求。如果不能，家鄉代理將返回合適的錯誤碼（失敗碼）。特別地，如果家鄉代理不能支持所請求形式的封裝，它必須返回錯誤碼139(請求的封裝不可用)。
家鄉代理可以使用錯誤碼138（強制使用反向隧道但注冊請求沒有設置“T”位）來拒絕沒有設置“T”位的注冊請求。
作為最后的檢查，家鄉代理判斷它是否能夠支持使用與前向隧道相同配置的反向隧道。如果不能，它將回送一個錯誤碼137（請求的反向隧道不可用）來拒絕該注冊。
一旦收到滿足合法性檢查的注冊請求（原文為注冊應答——譯注），家鄉代理必須更新其移動綁定列表，暗示移動節點其請求的反向隧道和發送方式已經獲準。
4.3.2.向外地代理發送注冊應答
與一個有效的注冊請求相對應，家鄉代理必須給移動節點發送一個注冊應答。

在成功注冊后，家鄉代理可能收到發給它自身的經過封裝的數據包。對這些數據包進行拆封并盲目地把它們注入網絡是一個潛在的安全缺陷（見第6.1節）。因而，家鄉代理必須（并且缺省為應該）對發給它的經過封裝的數據包進行下面的檢查：

家鄉代理搜尋這樣的移動綁定記錄：該記錄的轉交地址等于數據包外層頭部源地址且移動節點地址為內層頭部源地址。
如果沒有找到這樣的綁定記錄，或者數據包使用的不是注冊時協商好的封裝方法，家鄉代理必須丟掉該數據包并應該把該事件記錄為一個安全意外。

終止于與移動IP無關（例如多播隧道）的隧道的家鄉代理可以不進行上面的檢查，但基于前述原因不提倡這么做。


在該注冊有效期間，家鄉代理必須處理每一個有效的（由類似上面的檢查來確定）來自反向隧道的數據包，即對數據包進行拆封，恢復出原始數據包然后代表其發送者（移動節點）把它轉發到其目的地址（通信對方主機）。
5.移動節點到外地代理的發送方式
本節討論移動節點如何通過外地代理發送其數據。在所有情況下，移動節點通過代理廣告的鏈路層頭部來獲取外地代理的鏈路層地址。
5.1.直接發送方式
這種發送方式易于在移動節點實現，在移動節點和外地代理之間的鏈路（可能是很慢的鏈路）上使用小的（未經封裝的）數據包。但是，它僅僅支持單播數據包的反向隧道，不允許其它的反向隧道（見第5.4節）。
5.1.1.數據包的處理
移動節點必須把外地代理指定為其缺省路由器。不這樣做將不能保證對移動節點發出的所有數據包進行封裝，并且反向隧道將失效。外地代理必須：
-檢測（detect）移動節點發送的數據包,并且
-在轉發這些數據包之前對這些數據包進行封裝。
5.1.2.數據包頭部格式及各域
本節給出了直接發送方式下數據包頭部的格式。這種格式假設使用的是IP-in-IP封裝（參考文獻[2]）。

外地代理收到的數據包格式(直接發送方式):

IP各域：
源地址=移動節點的家鄉地址
目的地址=通信對方主機的地址
高層協議數據

外地代理轉發的數據包的格式(直接發送方式):

IP各域(封裝頭部):
源地址=外地代理的轉交地址
目的地址=家鄉代理的地址
Protocol域:4(IP-in-IP)
IP各域(原始頭部):
源地址=移動節點的家鄉地址
目的地址=通信對方主機的地址
高層協議數據

封裝頭部的各個域必須按下面選取:
IP源地址
從注冊請求的轉交地址（Care-ofAddress）域拷貝而得。
IP目的地址
從注冊請求的家鄉代理（HomeAgent）域拷貝。
IP協議域
缺省為4(IP-in-IP，參考文獻[2]),但也可以使用注冊時協商好的其它形式的封裝方法。
5.2.封裝發送方式
這種機制要求移動節點自己實現封裝，并且通過把外地代理的地址指定為新的最外層頭部的目的地址直接把數據包傳送到外地代理。希望發送廣播或者多播數據報的移動節點必須使用封裝發送方式。
5.2.1數據包的處理
外地代理不修改其前向（轉發）功能。相反地，它接收數據包，在核實數據包是移動節點發出的以后，它：
-對數據包進行拆封，恢復出內層數據包
-對數據包進行重新封裝，并把它發送到家鄉代理。
如果外地代理接收到來自移動節點的未經封裝的數據包，并且移動節點已經顯式請求封裝發送方式，那么外地代理不允許使用反向隧道發送該數據包，相反，它必須使用標準的IP路由機制來轉發該數據包。
5.2.2.數據包頭部格式及各域
本節給出了使用封裝發送方式的數據包頭部的格式。該格式假設使用IP-in-IP封裝（參考文獻[2]）。
外地代理接收到的數據包格式(封裝發送方式):
IP各域(封裝頭部):
源地址=移動節點的家鄉地址
目的地址=外地代理的地址
Protoco域:4(IPinIP)
IP各域(原始頭部):
源地址=移動節點的家鄉地址
目的地址=通信對方主機的地址
高層協議數據

封裝頭部的各域必須按如下選用：
IP源地址
移動節點的家鄉地址。
IP目的地址
由代理最近的注冊應答中得知的IP源地址。
IPProtocol域
缺省為4(IP-in-IP，參考文獻[2]),但也可以使用注冊時協商好的其它封裝方法。

由外地代理轉發的數據包的格式(封裝發送方式):
IP各域(封裝頭部):
源地址=外地代理的轉交地址
目的地址=家鄉代理的地址
Protocol域:4(IP-in-IP)
IP各域(原始頭部):
源地址=移動節點的家鄉地址
目的地址=通信對方主機的地址
高層協議數據

封裝IP頭部各域必須按照如下選取:
IP源地址
從注冊請求重的轉交地址（Care-ofAddress）域拷貝。
IP目的地址
從注冊請求的家鄉代理（HomeAgent）域拷貝。
IPProtocol域
缺省為4(IP-in-IP，參考文獻[2]),但也可以使用注冊時協商好的其它封裝方法。
5.3.廣播和多播數據報的支持
如果移動節點以配置轉交地址操作，廣播和多播數據報按照移動IP規范（參考文獻[1]）中的第4.3和4.4節處理。使用外地代理轉交地址的移動節點可以由外地代理通過反向隧道傳送廣播和多播數據報。但是，這樣的移動節點必須使用封裝發送方式。
這樣只是把數據報傳送到外地代理，外地代理對數據報進行拆封，然后像對待來自移動節點的其它數據報一樣處理該數據報，也就是說，通過反向隧道把它傳送到家鄉代理。
5.4.可選的反向隧道
傳送到本地資源（例如，附近的打印機）的數據包可能受到入口處過濾的影響。使用配置轉交地址的移動節點可以對這些數據包的傳送進行優化，方法就是不使用反向隧道傳送。另一方面，使用外地代理轉交地址的移動節點可以通過請求封裝發送方式使用可選的反向隧道功能，遵循下面的原則：
不想被通過反向隧道傳送的數據包:
使用直接發送方式。外地代理必須把這些數據包作為常規的流量來處理：它們可以被轉發到家鄉代理但是不允許通過反向隧道傳送到家鄉代理。

想被通過反向隧道發送的數據包:
使用封裝發送方式發送。外地代理必須按第5.2節處理這些數據包：它們必須通過反向隧道傳送到家鄉代理。
6.安全方面的考慮
本文當描述的擴展是以移動IP規范（參考文獻[1]）所描述的安全方面的考慮為基礎的。本來，前向隧道和反向隧道的創建都涉及到認證過程，認證過程減少了受攻擊的危險。
6.1.反向隧道劫機及拒絕服務攻擊
一旦隧道建立起來后，惡意的節點將可能“劫持”該隧道并把數據包注入網絡中。反向隧道可能使這個問題惡化，因為,當數據包到達隧道的出口點時，它的轉發將在超出本地網絡之外的地方進行。這個問題在移動IP規范中也出現，因為它已經指定把反向隧道用于某些特定的應用。
涉及到外地代理的未經
認證的數據交換將使得惡意的節點偽裝成合法的移動節點，并把現存的隧道重定向到另一個家鄉代理,或者是另一個惡意的節點。防止這種攻擊的最好的方法就是使用移動IP規范（參考文獻[1]）中的Mobile-Foreign以及Foreign-Home認證擴展。
如果所需的移動安全聯合不可用，本文檔介紹一種機制來減少這種攻擊的范圍和效力。移動節點必須把發給外地代理的注冊請求中IP頭部的TTL設置為255。這就防止了遠于一跳（hop）之外的惡意節點偽裝成合法節點。注冊拒絕中其它的錯誤碼（失敗碼）使得對這種確實發生的攻擊的跟蹤變得更容易。
為了進一步減少這種攻擊，移動IP工作組考慮了涉及到使用未認證狀態的其它機制。但是，但是這些機制引入了拒絕服務攻擊。大家一致認為在只提供很弱的（不加密的）保護來防止攻擊的機制之間很難折衷。
6.2.入口處過濾
出現入口處過濾的反向隧道的長效性已經有一些問題。推想是網絡管理員將把通過反向隧道的數據包（使用IP-in-IP封裝的數據包）作為過濾的目標。入口處過濾的建議清楚地說明為什么不是如此（參考文獻[8]）:
當攻擊的源變得更像“合法”時，對它的跟蹤將變得更簡單。
7.致謝
封裝發送方式由CharliePerkins提出。JimSolomon的建議使得本文當形成現在的樣子。
參考文獻
[1]Perkins,C.,“IP的移動性支持（移動IP規范）”,RFC2002,October1996.

[2]Perkins,C.,“在IP內封裝IP（IP-in-IP封裝）”,RFC2003,October
1996.

[3]ComputerEmergencyResponseTeam(CERT),“IP欺詐攻擊及劫持連接終端”,CA-95:01,January1995?？赏ㄟ^匿名ftp從info.cert.orgin/pub/cert_advisories獲得。

[4]Johnson,D.,andC.Perkins,“移動IP中的路由優化”,正在制訂中。

[5]ManuelRodriguez,privatecommunication,August1995.

[6]Atkinson,R.,“IP認證頭部”,RFC1826,August1995.

[7]Atkinson,R.,“封裝安全凈載的IP”,RFC1827,August1995.

[8]Ferguson,P.,andD.Senie,“網絡入口點過濾：挫敗使用源IP地址的拒絕服務攻擊”,RFC2267,January1998.

[9]Bradner,S.,“RFC中表明條件級別所使用的關鍵詞”,BCP14,RFC2119,March1997.

編輯和主席地址

本文檔的問題可以直接按以下方式聯系：
GabrielE.Montenegro
SunMicrosystems,Inc.
901SanAntonioRoad
MailstopUMPK15-214
MountainView,California94303

Voice:+1-415-786-6288
Fax:+1-415-786-6445
EMail:gabriel.montenegro@eng.sun.com

工作組可通過現任主席聯系：
JimSolomon
Motorola,Inc.
1301E.AlgonquinRd.-Rm2240
Schaumburg,IL60196

Voice:+1-847-576-2753
Fax:+1-847-576-3240
EMail:solomon@comm.mot.com


ErikNordmark
SunMicrosystems,Inc.
901SanAntonioRoad
MailstopUMPK17-202
MountainView,California94303

Voice:+1-415-786-5166
EMail:erik.nordmark@eng.sun.com
完整版權通告
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
revokedbytheInternetSocietyoritssuclearcase/" target="_blank" >ccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF