pppoe原理協(xié)議詳解

1、PPPoE（PointtoPointProtocoloverEther，基于以太網(wǎng)的點對點協(xié)議）的工作流程包含發(fā)現(xiàn)（發(fā)現(xiàn)（Discovery）和會話（會話（Session）兩個階段，發(fā)現(xiàn)階段是無狀態(tài)無狀態(tài)的，目的是獲得PPPoE終端（在局端的ADSL設(shè)備上）的以太網(wǎng)MAC地址，并建立一個惟一的PPPoESESSIONID。發(fā)現(xiàn)階段結(jié)束后，就進入標準的PPP會話階段1.1.發(fā)現(xiàn)階段（發(fā)現(xiàn)階段（PPPoEDPPPoED：PPPoEPPPoE

2、DiscoveryDiscovery）1.1PADIPADI（PPPoEActiveDiscoveryInitiationInitiation）主機廣播發(fā)起分組，分組的目的地址為以太網(wǎng)的廣播地址0xffffffffffff，CODE（代碼）字段值為009（PADICode），SESSIONID（會話ID）字段值為0x0000。PADI分組必須至少包含一個服務(wù)名稱類型的標簽標簽（ServiceNameTag，字段值為0x0101），向接入

3、集中器提出所要求提供的服務(wù)。1.2PADOPADO（PPPoEActiveDiscoveryOfferOffer）接入集中器收到在服務(wù)范圍內(nèi)的PADI分組，發(fā)送PPPoE有效發(fā)現(xiàn)提供包分組，以響應(yīng)請求。其中CODE字段值為007（PADOCode），SESSIONID字段值仍為0x0000。PADO分組必須包含一個接入集中器名稱類型的標簽（AccessConcentratNameTag，字段值為0x0102），以及一個或多個服務(wù)名稱類型

4、標簽，表明可向主機提供的服務(wù)種類。PADO和PADI的HostUniqTag值相同。1.3PADRPADR（PPPoEActiveDiscoveryRequestRequest）主機在可能收到的多個PADO分組中選擇一個選擇一個合適的PADO分組，然后向所選擇的接入集中器發(fā)送PPPoE有效發(fā)現(xiàn)請求請求分組。其中CODE字段為0x19（PADRCode），SESSION_ID字段值仍為0x0000。PADR分組必須包含一個服務(wù)名稱類型標簽

5、，確定向接入集線器（或交換機）請求的服務(wù)種類。當主機在指定的時間內(nèi)沒有接收到PADO，它應(yīng)該重新發(fā)送它的PADI分組，并且加倍等待加倍等待時間，這個過程會被重復(fù)期望的次數(shù)。1.4PADSPADS（PPPoEActiveDiscoverySessionSessionconfirmation）接入集中器收到PADR分組后準備開始PPP會話，它發(fā)送一個PPPoE有效發(fā)現(xiàn)會話確認PADS分組。其中CODE字段值為065（PADSCode），SE

6、SSIONID字段值為接入集中器所產(chǎn)生的一個惟一的惟一的PPPoE會話標識號碼。PADS分組也必須包含一個接入集中器名稱類型的標簽以確認向主機提供的服務(wù)。當主機收到PADS分組確認后，雙方就進入PPP會話階段。PADS和PADR的HostUniqTag值相同。到對端回應(yīng)了ACK報文為止。說明：（1）ConfigACK：若完全支持對端的LCP選項，則回應(yīng)ConfigACK報文，報文中必須完全攜帶對端Request報文中的選項。（2）Con

7、figNAK：若支持對端的協(xié)商選項，但不認可該項協(xié)商的內(nèi)容，則回應(yīng)ConfigNAK報文，在ConfigNAK的選項中填上自己期望的內(nèi)容，如:對端MRU值為1500，而自己期望MRU值為1492，則在ConfigNAK報文中埴上自己的期望值1492。（3）ConfigReject：若不能支持對端的協(xié)商選項，則回應(yīng)ConfigReject報文，報文中帶上不能支持的選項，如Windows撥號器會協(xié)商CBCP（被叫回呼），而ME60不支持CB

8、CP功能，則回將此選項拒絕掉。2.2認證階段（認證階段（PPPAuthentication：PAPCHAP）會話雙方通過LCP協(xié)商好的認證方法進行認證，如果認證通過了，才可以進行下面的網(wǎng)絡(luò)層的協(xié)商。認證過程在鏈路協(xié)商結(jié)束后就進行。ⅠPAP（PasswdAuthenticationProtocol，口令認證協(xié)議）認證，口令認證協(xié)議）認證PAP為兩次握手協(xié)議，它通過用戶名及口令來對用戶進行驗證。PAP驗證過程如下驗證過程如下：當兩端鏈路可相

9、互傳輸數(shù)據(jù)時，被驗證方發(fā)送本端的用戶名及口令到驗證方，驗證方根據(jù)本端的用戶表（或Radius服務(wù)器）查看是否有此用戶，口令是否正確。如正確則會給對端發(fā)送AuthenticateACK報文，通告對端已被允許進入下一階段協(xié)商；否則發(fā)送NAK報文，通告對端驗證失敗。此時，并不會直接將鏈路關(guān)閉。只有當驗證不過次數(shù)達到一定值（缺省為10）時，才會關(guān)閉鏈路。PAP的特點是在網(wǎng)絡(luò)上以明文的方式傳遞用戶名及口令，如在傳輸過程中被截獲，便有可能對網(wǎng)絡(luò)安全