PPPoE用戶上線交互流程

《PPPoE用戶上線交互流程》由會員上傳分享，免費在線閱讀，更多相關(guān)內(nèi)容在應(yīng)用文檔-天天文庫。

1、PPPoE用戶上線交互過程PPPoE用戶上線要經(jīng)過PPPoE協(xié)商、LCP協(xié)商、PAP/CHAP認(rèn)證、NCP協(xié)商幾個階段。PPPoE協(xié)商PPPoE協(xié)商是ME設(shè)備為用戶分配PPPoE接入用的SessionID，該SessionID在每ME設(shè)備上唯一，用來唯一標(biāo)識一條用戶與ME設(shè)備之間的PPPoE虛擬鏈路。PPPoE的協(xié)商流程見下圖。圖1PPPoE的協(xié)商流程1.用戶廣播一個PADI包，在此包中包含用戶想要得到的服務(wù)類型信息。2.以太網(wǎng)內(nèi)的所有接入集中器（如上圖中的ME設(shè)備）在收到這個初始化包后，將其中請求的服務(wù)與自己能提供

2、的服務(wù)進(jìn)行比較，其中可以為此用戶提供此服務(wù)的接入集中器發(fā)回PADO包。3.用戶可能會收到多個集中器返回的PADO包。用戶根據(jù)一定的條件從返回PADO包的接入集中器中選定符合條件的接入集中器，并向它返回一個會話請求包PADR（非廣播），在PADR包中封裝所需的服務(wù)信息。4.被選定的接入集中器在收到PADR包后開始進(jìn)入PPP會話階段。它會產(chǎn)生一個會話標(biāo)識以唯一的標(biāo)識它和主機的這段PPPoE會話。并把這個特定的會話標(biāo)識包含在會話確認(rèn)包PADS中發(fā)回給用戶，如果沒有錯誤發(fā)生就進(jìn)入到PPP會話階段，而主機在收到會話確認(rèn)包后如果

3、沒有錯誤發(fā)生也進(jìn)入到PPP會話階段。LCP協(xié)商LCP協(xié)商的過程如下：協(xié)商雙方互相發(fā)送一個LCPConfig-Request報文，確認(rèn)收到的Config-Request報文中的協(xié)商選項，根據(jù)這些選項的支持與接受情況，做出適當(dāng)?shù)幕貞?yīng)。若兩端都回應(yīng)了Config-ACK，則標(biāo)志LCP鏈路建立成功，否則會繼續(xù)發(fā)送Request報文，直到對端回應(yīng)了ACK報文為止。說明：·Config-ACK：若完全支持對端的LCP選項，則回應(yīng)Config-ACK報文，報文中必須完全協(xié)帶對端Request報文中的選項。·Config-NAK：若

4、支持對端的協(xié)商選項，但不認(rèn)可該項協(xié)商的內(nèi)容，則回應(yīng)Config-NAK報文，在Config-NAK的選項中填上自己期望的內(nèi)容，如:對端MRU值為1500，而自己期望MRU值為1492，則在Config-NAK報文中埴上自己的期望值1492。·Config-Reject：若不能支持對端的協(xié)商選項，則回應(yīng)Config-Reject報文，報文中帶上不能支持的選項，如Windows撥號器會協(xié)商CBCP（被叫回呼），而ME60不支持CBCP功能，則回將此選項拒絕掉。圖2LCP協(xié)商的基本過程1.當(dāng)用戶與ME設(shè)備互相發(fā)送LCPCo

5、nfig-Request報文并且互相回應(yīng)LCPConfig-Ack報文時，標(biāo)志著LCP協(xié)商己經(jīng)成功了。接下來ME設(shè)備會周期性的向用戶發(fā)送LCPEcho-Request報文，探測用戶是否在線。2.LCP協(xié)議通過互相發(fā)送Echo-Request報文，然后接收對端回應(yīng)的Echo-reply報文，來探測LCP鏈接是否正常，以維持LCP連接。說明：·l有些設(shè)備或終端不支持主動發(fā)送Echo-Request報文，只能支持回應(yīng)Echo-Reply報文，Echo是PPPoE用戶的探測報文?！協(xié)議規(guī)定默認(rèn)的Echo探測次數(shù)為3次，每2

6、0秒為一個周期，BRAS設(shè)備從用戶上線的一個周期后開始探測，探測3次都未收到用戶的Reply報文，即20*(3+1)=80秒后，會將用戶CUT下線。認(rèn)證階段·PAP認(rèn)證PAP為兩次握手協(xié)議，它通過用戶名及口令來對用戶進(jìn)行驗證。PAP驗證過程如下：當(dāng)兩端鏈路可相互傳輸數(shù)據(jù)時，被驗證方發(fā)送本端的用戶名及口令到驗證方，驗證方根據(jù)本端的用戶表（或Radius服務(wù)器）查看是否有此用戶，口令是否正確。如正確則會給對端發(fā)送Authenticate-ACK報文，通告對端已被允許進(jìn)入下一階段協(xié)商；否則發(fā)送NAK報文，通告對端驗證失敗。

7、此時，并不會直接將鏈路關(guān)閉。只有當(dāng)驗證不過次數(shù)達(dá)到一定值（缺省為10）時，才會關(guān)閉鏈路。PAP的特點是在網(wǎng)絡(luò)上以明文的方式傳遞用戶名及口令，如在傳輸過程中被截獲，便有可能對網(wǎng)絡(luò)安全造成極大的威脅。因此，它適用于對網(wǎng)絡(luò)安全要求相對較低的環(huán)境。用戶發(fā)送認(rèn)證端發(fā)驗證請求報文、并且接收到ME設(shè)備回應(yīng)認(rèn)的證成功報文后，表示PAP認(rèn)證己經(jīng)成功。否則ME設(shè)備會回應(yīng)認(rèn)證失敗報文，通知用戶認(rèn)證不成功。圖3PAP認(rèn)證流程·CHAP認(rèn)證CHAP為三次握手協(xié)議。只在網(wǎng)絡(luò)上傳輸用戶名，并不傳輸用戶口令，因此它的安全性要比PAP高。CHAP的驗

8、證過程為：首先由驗證方向被驗證方發(fā)送一些隨機產(chǎn)生的報文，并同時將本端的主機名附帶上一起發(fā)送給被驗證方。被驗證方接到對端對本端的驗證請求(Challenge)時，便根據(jù)此報文中驗證方的主機名和本端的用戶表查找用戶口令字，如找到用戶表中與驗證方主機名相同的用戶，便利用報文ID、此用戶的密鑰用Md5算法生成應(yīng)答（Response），隨后將應(yīng)答和自己的