【文章內(nèi)容簡介】 會進(jìn)行相應(yīng)的動(dòng)作，也就是開始發(fā)送ConfigRequest報(bào)文來配置數(shù)據(jù)鏈路。l 無論哪一端接收到了ConfigAck報(bào)文時(shí)，LCP的狀態(tài)機(jī)又要發(fā)生改變，從當(dāng)前狀態(tài)改變?yōu)閛pened狀態(tài)。進(jìn)入Opened狀態(tài)后收到ConfigAck報(bào)文的一方則完成了當(dāng)前階段，應(yīng)該向下一個(gè)階段躍遷。同理可知，另一端也是一樣的，但須注意的是在鏈路配置階段雙方的鏈路配置操作過程是相互獨(dú)立的。如果在該階段收到了非LCP數(shù)據(jù)報(bào)文，則會將這些報(bào)文丟棄。驗(yàn)證階段（Authenticate）多數(shù)情況下的鏈路兩端設(shè)備是需要經(jīng)過認(rèn)證后才進(jìn)入到網(wǎng)絡(luò)層協(xié)議階段。PPP鏈路缺省情況下，不進(jìn)行驗(yàn)證。如果要求驗(yàn)證，在鏈路建立階段必須指定驗(yàn)證協(xié)議。PPP驗(yàn)證有兩種用途：l 主要是用于主機(jī)和路由器之間，通過PPP網(wǎng)絡(luò)服務(wù)器交換電路或撥號接入連接的鏈路。l 偶爾也用于專用線路。PPP提供兩種驗(yàn)證方式。l PAP：Password Authentication Protocol，密碼驗(yàn)證協(xié)議l CHAP：ChallengeHandshake Authentication Protocol，挑戰(zhàn)握手協(xié)議驗(yàn)證方式的選擇是依據(jù)在鏈路建立階段雙方進(jìn)行協(xié)商的結(jié)果。然而，鏈路質(zhì)量的檢測也會在這個(gè)階段同時(shí)發(fā)生，但協(xié)議規(guī)定不會讓鏈路質(zhì)量的檢測無限制的延遲驗(yàn)證過程。在這個(gè)階段僅支持鏈路控制協(xié)議、驗(yàn)證協(xié)議和質(zhì)量檢測數(shù)據(jù)報(bào)文，其它的數(shù)據(jù)報(bào)文都會被丟棄。如果在這個(gè)階段再次收到了ConfigRequest報(bào)文，則又會返回到鏈路建立階段。網(wǎng)絡(luò)層協(xié)議階段（Network）一旦PPP完成了前面幾個(gè)階段，每種網(wǎng)絡(luò)層協(xié)議（IP、IPX和AppleTalk）會通過各自相應(yīng)的網(wǎng)絡(luò)控制協(xié)議進(jìn)行配置，每個(gè)NCP協(xié)議可在任何時(shí)間打開和關(guān)閉。當(dāng)一個(gè)NCP的狀態(tài)機(jī)變成Opened狀態(tài)時(shí)，則PPP就可以開始在鏈路上承載網(wǎng)絡(luò)層的數(shù)據(jù)包報(bào)文了。如果在個(gè)階段收到了ConfigRequest報(bào)文，則又會返回到鏈路建立階段。 網(wǎng)絡(luò)終止階段（Terminate）PPP能在任何時(shí)候終止鏈路。當(dāng)載波丟失、認(rèn)證失敗、鏈路質(zhì)量檢測失敗和管理員人為關(guān)閉鏈路等情況均會導(dǎo)致鏈路終止。鏈路建立階段可能通過交換LCP的鏈路終止報(bào)文來關(guān)閉鏈路，當(dāng)鏈路關(guān)閉時(shí)，鏈路層會通知網(wǎng)絡(luò)層做相應(yīng)的操作，而且也會通過物理層強(qiáng)制關(guān)斷鏈路。對于NCP協(xié)議，它是不能也沒有必要去關(guān)閉PPP鏈路的。 PPP的PAP驗(yàn)證協(xié)議PAP驗(yàn)證協(xié)議為兩次握手驗(yàn)證，口令為明文。驗(yàn)證過程僅在鏈路初始建立階段進(jìn)行。當(dāng)鏈路建立階段結(jié)束后，用戶名和密碼將由被驗(yàn)證方重復(fù)地在鏈路上發(fā)送給驗(yàn)證方，直到驗(yàn)證被通過或者鏈路連接終止。當(dāng)必須使用明文密碼在遠(yuǎn)端主機(jī)上模擬登錄的時(shí)候，這種驗(yàn)證方式是最合適的。PAP驗(yàn)證的過程如下圖所示。l 被驗(yàn)證方發(fā)送本端用戶名和口令到驗(yàn)證方。l 驗(yàn)證方根據(jù)本地用戶表查看是否有被驗(yàn)證方的用戶名以及口令是否正確，然后返回不同的響應(yīng)（接受或拒絕）。PAP不是一種安全的驗(yàn)證協(xié)議。當(dāng)驗(yàn)證時(shí)，口令以明文方式在鏈路上發(fā)送，并且由于完成PPP鏈路建立后，被驗(yàn)證方會不停地在鏈路上反復(fù)發(fā)送用戶名和口令，直到身份驗(yàn)證過程結(jié)束，所以不能防止攻擊。協(xié)商PAP驗(yàn)證協(xié)議的配置參數(shù)選項(xiàng)幀格式如下圖所示。各字段的含義如下表所示。字段長度（字節(jié)）含義Type1當(dāng)值是0x03時(shí)表示是驗(yàn)證協(xié)議。常用的協(xié)商類型值請參見常用協(xié)商類型值。Length1此時(shí)固定值是4，表示這個(gè)配置參數(shù)選項(xiàng)幀格式總長度是4個(gè)字節(jié)。AuthenticationProtocol2當(dāng)值是0xC023表示是PAP協(xié)議。常用的協(xié)議代碼請參見常見的協(xié)議代碼。在驗(yàn)證協(xié)議中，Data字段的內(nèi)容就是AuthenticationProtocol的內(nèi)容。一個(gè)PAP數(shù)據(jù)報(bào)是封裝在協(xié)議域?yàn)镃023的PPP數(shù)據(jù)鏈路層幀的信息域中的。PAP數(shù)據(jù)報(bào)的幀格式如下圖所示。各字段的含義如下表所示。字段長度（字節(jié)）含義Code1標(biāo)識PAP數(shù)據(jù)報(bào)的類型。l 1表示是AuthenticateRequest報(bào)文l 2表示是AuthenticateAck報(bào)文l 3表示是AuthenticateNak報(bào)文Identifier1標(biāo)識請求報(bào)文和應(yīng)答報(bào)文的匹配。Length2表示包括Code、Identifier、Length和Data域在內(nèi)的PAP報(bào)文長度。超出此長度的報(bào)文將被認(rèn)為是填充字節(jié)并被丟棄。Data0或多個(gè)字節(jié)Data域的幀由Code域來決定。l Authenticate_Request報(bào)文驗(yàn)證請求報(bào)文用于表示PAP驗(yàn)證的開始。鏈路的被驗(yàn)證方在驗(yàn)證階段必須傳輸code值為0x01的PAP驗(yàn)證報(bào)文。驗(yàn)證報(bào)文必須被重復(fù)發(fā)送，直到收到了有效的回復(fù)報(bào)文，或計(jì)數(shù)器的值已滿，此時(shí)應(yīng)該終止鏈路連接。驗(yàn)證方只能等待被驗(yàn)證方發(fā)送驗(yàn)證請求報(bào)文。當(dāng)收到驗(yàn)證請求報(bào)文后，必須根據(jù)實(shí)際情況回復(fù)不同的應(yīng)答報(bào)文。驗(yàn)證請求報(bào)文的幀格式如下圖所示。各字段的解釋如下表所示。字段長度（字節(jié)）含義Code10x01表示驗(yàn)證請求報(bào)文。具體的code值含義請參見Error! Reference source not found.。Identifier1標(biāo)識請求報(bào)文和應(yīng)答報(bào)文的匹配。對于每個(gè)請求報(bào)文的應(yīng)答報(bào)文，該域都必須不同。Length2表示該報(bào)文的總長度。PeerID Length1標(biāo)識PeerID域的長度。PeerID0或多個(gè)標(biāo)識被驗(yàn)證方的名字。Password Length1標(biāo)識Password域的長度。Password0或多個(gè)標(biāo)識被驗(yàn)證的密碼。l AuthenticateAck和AuthenticateNak報(bào)文幀格式如果在驗(yàn)證請求報(bào)文中的用戶名和密碼都能被驗(yàn)證方驗(yàn)證通過，驗(yàn)證方必須返回Code值是2的AuthenticateAck報(bào)文，表示驗(yàn)證通過。如果驗(yàn)證請求報(bào)文中用戶名或密碼有一項(xiàng)沒有通過驗(yàn)證，驗(yàn)證方必須返回Code值是3的AuthenticateNak報(bào)文，表示驗(yàn)證失敗。AuthenticateAck和AuthenticateNak報(bào)文的幀格式如下圖所示。各字段的含義如下表所示。字段長度（字節(jié)）含義Code10x02表示AuthenticateAck報(bào)文，0x03表示AuthenticateNak報(bào)文。具體的code值含義請參見Error! Reference source not found.。Identifier1標(biāo)識請求報(bào)文和應(yīng)答報(bào)文的匹配。該域的值必須和引起該應(yīng)答報(bào)文的AuthenticateRequest報(bào)文一樣。Length2表示該報(bào)文的總長度。Message Length1標(biāo)識Message域的長度。Message0或多個(gè)由報(bào)文的內(nèi)容決定。 PPP的CHAP驗(yàn)證協(xié)議CHAP（Challenge Handshake Authentication Protocol）驗(yàn)證協(xié)議為三次握手驗(yàn)證協(xié)議。它只在網(wǎng)絡(luò)上傳輸用戶名，而并不傳輸用戶密碼，因此安全性要比PAP高。CHAP協(xié)議是在鏈路建立的開始就完成的。在鏈路建立完成后的任何時(shí)間都可以重復(fù)發(fā)送進(jìn)行再驗(yàn)證。當(dāng)鏈路建立階段完成后，驗(yàn)證方發(fā)送一個(gè)“challenge”報(bào)文給被驗(yàn)證方。被驗(yàn)證方經(jīng)過一次哈希算法后，給驗(yàn)證方返回一個(gè)值。驗(yàn)證方把自己經(jīng)過哈希算法生成的值和被驗(yàn)證方返回的值進(jìn)行比較。如果兩者匹配，那么驗(yàn)證通過。否則驗(yàn)證不通過，連接應(yīng)該被終止。CHAP的驗(yàn)證過程如下圖所示。CHAP單向驗(yàn)證是指一端作為驗(yàn)證方，另一端作為被驗(yàn)證方。雙向驗(yàn)證是單向驗(yàn)證的簡單疊加，即兩端都是既作為驗(yàn)證方又作為被驗(yàn)證方。在實(shí)際應(yīng)用中一般只采用單向驗(yàn)證。CHAP單向驗(yàn)證過程分為兩種情況：驗(yàn)證方配置了用戶名和驗(yàn)證方?jīng)]有配置用戶名。推薦使用驗(yàn)證方配置用戶名的方式，這樣可以對驗(yàn)證方的用戶名進(jìn)行確認(rèn)。l 驗(yàn)證方配置了用戶名的驗(yàn)證過程? 驗(yàn)證方把隨機(jī)產(chǎn)生的“質(zhì)詢（Challenge）”報(bào)文和本端主機(jī)名一起發(fā)送給被驗(yàn)證方。? 被驗(yàn)證方收到報(bào)文后，根據(jù)驗(yàn)證方的用戶名在本地用戶列表中查找本地口令。根據(jù)查找到的口令和質(zhì)詢報(bào)文，通過MD5算法進(jìn)行計(jì)算得出一個(gè)數(shù)值，并將計(jì)算得出的數(shù)值和自己的主機(jī)名發(fā)回驗(yàn)證方（Response）。? 驗(yàn)證方收到Response后，根據(jù)其中攜帶的被驗(yàn)證方主機(jī)名，在本端用戶表中查找被驗(yàn)證方口令字，找到匹配項(xiàng)后，利用質(zhì)詢報(bào)文和被驗(yàn)證方口令字，通過MD5算法進(jìn)行計(jì)算得出一個(gè)數(shù)值，根據(jù)此數(shù)值與收到的Response的結(jié)果進(jìn)行比較，然后返回不同的響應(yīng)（接受或拒絕）。l 驗(yàn)證方?jīng)]有配置用戶名驗(yàn)證方?jīng)]有配置用戶名時(shí)，驗(yàn)證方只把“質(zhì)詢”報(bào)文發(fā)送到被驗(yàn)證方。被驗(yàn)證方直接根據(jù)本地接口設(shè)置的口令和質(zhì)詢報(bào)文通過MD5算法計(jì)算得出一個(gè)數(shù)值，并將計(jì)算得出的數(shù)值和自己的主機(jī)名發(fā)回驗(yàn)證方。其他過程和驗(yàn)證方配置了用戶名時(shí)相同。協(xié)商CHAP協(xié)議的配置參數(shù)選項(xiàng)幀格式如下圖所示。各字段含義如下表所示。字段長度（字節(jié)）含義Type10x03表示是驗(yàn)證協(xié)議報(bào)文。具體值含義請參見常用協(xié)商類型值。Length1此時(shí)固定是5，表示該報(bào)文的總長度是5個(gè)字節(jié)。AuthenticationProtocol2當(dāng)值是0xC223時(shí)表示是CHAP驗(yàn)證協(xié)議。具體值的含義請參見Error! Reference source not found.。Algorithm1表示使用的一次哈希方法。l 0～4：不用，保留l 5：MD5算法l CHAP數(shù)據(jù)報(bào)的幀格式確切來講，CHAP報(bào)文是封裝在PPP數(shù)據(jù)鏈路層的Information域的。在Information域中protocol域的值固定是0xC223，表示CHAP驗(yàn)證協(xié)議。CHAP協(xié)議數(shù)據(jù)報(bào)格式如下圖所示。各字段含義如下表所示。字段長度（字節(jié)）含義Code1表示CHAP數(shù)據(jù)報(bào)文的類型。l 1表示Challenge報(bào)文l 2表示Response報(bào)文l 3表示Success報(bào)文l 4表示Failure報(bào)文Identifier1表示挑戰(zhàn)報(bào)文、應(yīng)答報(bào)文等之間的對應(yīng)。Length2表示包括Code、Identifier、Length和Data域在內(nèi)的CHAP數(shù)據(jù)報(bào)文的長度。超出該長度值的字節(jié)應(yīng)該被認(rèn)為是數(shù)據(jù)鏈路層的填充字節(jié)，在接收時(shí)應(yīng)該被忽略。Data0或多個(gè)幀格式由Code域值決定。l Challenge報(bào)文和Response報(bào)文Challenge報(bào)文用來發(fā)起CHAP驗(yàn)證。驗(yàn)證方必須發(fā)送一個(gè)Code域值是1的CHAP數(shù)據(jù)報(bào)文，來表示是Challenge報(bào)文。其他附加挑戰(zhàn)報(bào)文必須在收到有效的回應(yīng)報(bào)文或計(jì)數(shù)器滿后才可以發(fā)送。挑戰(zhàn)報(bào)文也可以在網(wǎng)絡(luò)層協(xié)議階段發(fā)送，以確認(rèn)連接是否完整。在驗(yàn)證階段和網(wǎng)絡(luò)層協(xié)議階段，被驗(yàn)證方要等待驗(yàn)證方發(fā)送Challenge報(bào)文。只要接收到Challenge報(bào)文，被驗(yàn)證方必須返回一個(gè)Code域值是2的CHAP報(bào)文，表示是回應(yīng)報(bào)文。只要接收到回應(yīng)報(bào)文，驗(yàn)證方就會把自己計(jì)算的值和返回值進(jìn)行比較。根據(jù)比較的結(jié)果，驗(yàn)證方返回不同的回應(yīng)報(bào)文。挑戰(zhàn)和回應(yīng)報(bào)文的幀格式如下圖所示。各字段的含義如下表所示。字段長度（字節(jié)）含義Code1l 1表示是Challenge報(bào)文l 2表示是回應(yīng)報(bào)文Identifier1它標(biāo)識挑戰(zhàn)報(bào)文和回應(yīng)報(bào)文的對應(yīng)關(guān)系。Length2表示該報(bào)文的總長度。Valuesize1表示Value域的長度。Value1或多個(gè)挑戰(zhàn)報(bào)文中此域是一些字節(jié)流?；貞?yīng)報(bào)文中此域是挑戰(zhàn)報(bào)文字節(jié)流經(jīng)過一次哈希算法后得到的值。Name1或多個(gè)該域的大小由Length域決定。l Success報(bào)文和Failure報(bào)文如果驗(yàn)證方接收到的值和自己計(jì)算的值相同，驗(yàn)證方必須要返回一個(gè)Code域值是3的CHAP報(bào)文，表示驗(yàn)證通過。如果驗(yàn)證方接收到的值和自己計(jì)算出的值不同，驗(yàn)證方必須返回一個(gè)Code域值是4的CHAP報(bào)文，表示驗(yàn)證失敗。并且應(yīng)該終止鏈路連接。驗(yàn)證通過或驗(yàn)證失敗時(shí)的報(bào)文格式如下圖所示。各字段的含義如下表所示。字段長度（字節(jié)）含義Code1l 3表示驗(yàn)證通過l 4表示驗(yàn)證失敗Identifier1表示回應(yīng)報(bào)文和該響應(yīng)報(bào)文的對應(yīng)關(guān)系。Length2表示該報(bào)文的總長度。Message0或多個(gè)該域的長度由Length域的值決定。 PPP的報(bào)文壓縮PPP鏈路層協(xié)議上的對IP、UDP、RTP和TCP報(bào)文頭的壓縮，壓縮方式有如下三種：l Stac壓縮：需要協(xié)商CCP，是對IP整個(gè)報(bào)文的壓縮。l TCP/IP報(bào)文頭壓縮：需要IPCP協(xié)商，只壓縮報(bào)文頭的部分。l PPP頭壓縮：只壓縮PPP報(bào)文頭部分。VJ TCP頭壓縮是一種壓縮算法，英文全稱是Van Jacobson TCP Header Compression。這種壓縮算法能夠?qū)CP/IP包頭的大小減小到近3個(gè)字節(jié)，從而提高低速線路的效率。VJ TCP頭壓縮的詳細(xì)說明請參見RFC1144。第四章 PPPoE PPPoE簡介 PPPoE的引入當(dāng)客戶接入到服務(wù)器時(shí)，客戶希望接入的成本低，而且希望在接入時(shí)不要或者很少改變配置。以太網(wǎng)無疑是最好的組網(wǎng)方式。服務(wù)提供商想通過同一個(gè)接入服務(wù)器連接到遠(yuǎn)程站點(diǎn)上的多個(gè)主機(jī)，同時(shí)要求服務(wù)器能提供與使用PPP撥號上網(wǎng)類似的訪問控制功能和支付功能。PPP（PointtoPoint）協(xié)議提供在點(diǎn)到點(diǎn)鏈路上傳送多協(xié)議數(shù)據(jù)報(bào)的標(biāo)準(zhǔn)方法。PPP應(yīng)用雖然很廣泛，但是不能用于以太網(wǎng)，因此提出了PPPoE技術(shù)。PPPoE是對PPP的擴(kuò)展，它可以使PPP協(xié)議應(yīng)用于以太網(wǎng)。PPP