1.介紹
PPP協議有3個主要的部分:
1.串行的鏈路上壓縮數據報的方法。
2.完成鏈路建立,配置的數據鏈路控制協議(LCP)。
3.為網絡層協議族配置不同的網絡層協議的網絡控制協議(NCP)。
為了在點到點鏈路上面建立通信,每個PPP協議鏈路的端都為了配置和試驗必須首先發LCP包。在鏈路經過LCP選擇和建立之后,PPP必須發送NCP包選擇和配置一個或一個以上的網絡層協議。如果每個被選中的網絡層協議都被配置,來自每個網絡層協議的數據報就能在鏈路上面被發送。
鏈路一直保持通信配置到通信單元LCP或NCP包明確指示關閉鏈路,或者一些外部事件發生(計時器呼出休止狀態,或者網絡管理員干涉)為止。
2.端對端協議網絡控制協議(NCP)為IP
IP控制協議(IPCP)負責配置,以及點對點鏈路的雙端上激活和去激活IP協議傳輸。IPCP使用和鏈路控制協議(LCP)同樣的包交換machanism。IPCP包也可以在PPP協議達到網絡層的協議階段以前不被交換。在本階段達到之前收到的IPCP包應該靜靜地拋棄。
IP控制協議確切地說除下列情形外,是和鏈路控制協議[ 1 ]同樣的東西:
數據鏈路層協議域
確切地說 IPCP包是被壓縮在協議域類型為十六進制8021(IP控制協議)的PPP協議數據鏈路層幀的信息字段中的。
編碼域
只有代碼1到7(Configure-Request,Configure-Ack,Configure-Nak,Configure-Reject,Terminate-Request,Terminate-Ack和Code-Reject)被使用。其他的編碼應該被處理為未經承認并且應該導致結果Code-Rejects。
超時
IPCP包可以在PPP協議達到網絡-層的協議階段之前不被交換。執行應該為等待在等待Configure-Ack或其他響應的定時器超時之前的認證和線路質量監測完成做好準備。被建議執行僅僅在用戶干涉或可變的時間量后面放棄。
配置可選項類型
IPCP有在下邊定義的的配置可選項的清楚的置值。
2.1 發送IP數據報
在任何IP包可以被傳輸之前,PPP協議必須達到網絡-層的協議階段,IP控制協議必為Opened狀態。
確切地說IP包是被壓縮在協議域類型為十六進制0021(網間協議)的PPP協議數據鏈路層幀的信息字段中的。
在PPP協議鏈路上面被傳送的IP包的最大的長度是和PPP協議數據鏈路層結構的信息字段的最大的長度同樣的東西。大的IP數據報必須分片傳輸。
如果系統想避免分片和重組,它應該使用TCP的最大分片尺寸選項[ 4 ]和MTU discovery[ 5 ]。
3.IPCP配置可選項
IPCP配置可選項允許合乎需要的網間協議參數的協商。IPCP用和LCP [ 1 ]一樣的選項定義格式來分隔各個選項的設置。
IPCP選項類型域的最新的值在最近的"Assigned Numbers"RFC中被指定[ 6 ]。當前的值象下面這樣被分配:
1 IP-地址(Addresses)
2 IP-壓縮協議
3 IP-地址(Address)
3.1 IP-地址(IP-Addresses)
描述
IP-地址(Addresses)配置選項的使用已經被反對了。它難以在全部使用本選項的例子中保證協商收斂。RFC[ 7 ] 1172為向后兼容執行需要提供信息。IP-地址(Address)配置選項代替本選項,并且它的使用是首選的。
本可選項不應該在已經被承認的包含了IP-Address和IP-Addresses的任意一個選項Configure-Request或Configure-Request中被發送。
如果Configure-Reject為IP-地址的可選項被收到,或者Configure-Nak用IP-地址的可選項被認為是附加的選項,本可選項可以被發送。
在IPCP協議狀態達到Internet草案標準之后,本可選項也許被廢除。
3.2 IP-壓縮協議
描述
本配置可選項提供協商特定的壓縮協議的使用的方法。在默認情況下,壓縮不使用。
IP-壓縮協議配置可選項格式的摘要在下邊被表示。域從左往右被傳送。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 類型 | 長度 | IP-壓縮協議 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 數據...
+-+-+-+-+
類型 2
長度 >= 4
IP-壓縮協議
IP-壓縮協議域是和顯示壓縮協議要求的2八位字節。給本域的值總是和給那個相同的壓縮協議的PPP協議數據鏈路層協議域值同樣的東西。
IP-壓縮協議域的最新的值在最近的"Assigned Numbers"RFC中被指定[ 6 ]。當前的值象下面這樣被分配:
值(十六進制在中) 協議
002d Van Jacobson Compressed TCP/IP(用于網絡的一組通訊協議)
數據
數據區是零,或者,由特別壓縮協議決定的更多的八位字節的附加數據數據。
缺省
不使用壓縮協議。
3.3 IP-地址(IP-Address)
描述
本配置選項提供協商在鏈路本端上被使用的IP地址的方法。它允許Confugure-Requestde的發送方聲明要求哪個IP地址,或者請求對端提供信息。對端能通過NAKing選項提供本信息,返回有效的IP地址。
如果必須進行關于遠程的的IP地址的協商,而對端不提供其Configure-Request里邊可選項,可選項應該被加到Configure-Nak上。被給的IP地址值必須象遠程的的IP地址那樣可接受,或者顯示對端提供信息的要求。
在默認情況下,IP地址不被分配。
IP-地址(IP-Address)的配置可選項格式的摘要在下邊被表示。域從左往右被傳送。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| 類型 | 長度 | IP-地址
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
IP地址(cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
類型 3
長度 6
IP-地址
4個八位字節IP地址是發件人在Configure-Request中要求的本端地址。如果全部4個八位字節都是零值,它表示請求對端提供IP-地址信息。 缺省
IP地址不被分配。
4.Van Jacobson TCP/Ip報頭壓縮
Van Jacobson TCP/IP報頭壓縮把TCP/IP報頭降低到3字節。這可以顯著的改進低速串行線的通信。
IP-壓縮協議配置可選項被用來表示收到壓縮的包的能力。如果要求雙向壓縮,鏈路的每一端都必須獨立地請求本可選項。
當傳送IP包的時候,PPP協議協議域是對下列值的置值:
值(十六進制在中)
0021 典型IP。IP協議不是TCP,或包被分割,或者不能壓縮。
002d 壓縮TCP。TCP/IP報頭被壓縮報都替換。
002f 未壓縮TCP。IP協議域被時間片標識符替換。
4.1 配置可選項格式
為了協商Van Jacobson TCP/IP報頭壓縮IP-壓縮協議配置選項的格式的摘要在下邊被表示。域從左往右被傳送。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 類型 | 長度 | IP-壓縮協議 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|最大時間片ID | 比較時間片ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
類型 2
長度 6
IP-壓縮協議
002d(十六進制)給Van Jacobson的壓縮了TCP/Ip報頭。
最大-時間片身份識別標志(Max-Slot-ID)
Max-Slot-Id域是表示最大的時間片標識符的1八位字節。它比時間片的實際的號碼更少;時間片標識符可以取從零到Max-Slot-Id的值。
記錄:
用1時間片僅僅(最大-時間片身份識別標志= 0)可以有有問題的執行。在參考中看討論[ 3 ]。在[ 3 ]例子執行將僅僅和3一起通過254時間片動。
比較-時間片身份識別標志(Comp-Slot-Id)
Comp-Slot-Id域是表示是否時間片標識符域可以被壓縮的1八位字節。
0 時間片標識符不必被壓縮。全部壓縮的TCP包都必須在每一個變化的mask中設置C比特,而且必須包括時間片標識符在內。
1 時間片標識符可以被壓縮。
如果PPP協議鏈路沒有能力在接收中給解壓縮模塊表示誤差,時間片標識符不允許被壓縮。在誤差后面的同步依靠用時間片標識符接收包。在參考中看討論[ 3 ]。
附錄A.IPCP推薦的可選項
推薦下列配置可選項:
IP-壓縮協議 - 帶有至少4個時間片--通常為16個時間片。
IP-地址 ?。?僅在撥號線路上。
安全考慮
安全問題不在本記錄中被討論。
參考
[1]Simpson, W., "The Point-to-Point Protocol", RFC1331, May 1992.
[2]Postel, J., "Internet Protocol", RFC791, USC/Information Sciences Institute, September 1981.
[3]Jacobson, V., "Compressing TCP/IP Headers", RFC1144, January 1990.
[4]Postel, J., "The TCP Maximum Segment Size Option and Related Topics", RFC879, USC/Information Sciences Institute, November 1983.
[5]Mogul, J., and S. Deering, "Path MTU Discovery", RFC1191, November 1990.
[6]Reynolds, J., and J. Postel, "Assigned Numbers", RFC1060, USC/Information Sciences Institute, March 1990.
[7]Perkins, D., and R. Hobby, "Point-to-Point Protocol (PPP) initial configuration options", RFC1172, August 1990.
RFC1332 The PPP Internet Protocol Control Protocol(IPCP) RFC1332端對端協議網間協議控制協議(IPCP)