PPPoE用戶上線交互過程

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

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

3、發(fā)送一個LCP Co nfig-Request報文，確認收到的Con fig-Request報文中的協(xié)商選項，根據(jù)這些選項的支持與接受情況，做岀適當?shù)幕貞?。若兩端都回應?Config-ACK，則標志LCP鏈路建立成功，否則會繼續(xù)發(fā)送Request報文，直到對端回應了 ACK報文為止。說明:? Config-ACK :若完全支持對端的LCP選項，則回應 Config-ACK報文，報文中必須完全協(xié)帶對端Request報文中的選項。? Config-NAK :若支持對端的協(xié)商選項，但不認可該項協(xié)商的內(nèi)容，則回應Config-NAK報文，在Config-NAK的選項中填上自己期望的內(nèi)容，如：對端MR

4、U直為1500，而自己期望MRU值為1492，則在Config-NAK報文中埴上自己的期望值1492。? Config-Reject:若不能支持對端的協(xié)商選項，則回應 Config-Reject報文，報文中帶上不能支持的選項，如Windows撥號器會協(xié)商 CBC(被叫回呼)，而ME60不支持CBC功能，則回將此選項拒絕掉。圖2 LCP協(xié)商的基本過程ClientServerP協(xié)舸階段二 ；Config-reqConfig 磁 kConfig-reqConfig*Lick1. 當用戶與 ME設備互相發(fā)送 LCP Config-Request 報文并且互相回應 LCP Config-Ack 報文時，

5、標志著LCP協(xié)商己經(jīng)成功了。接下來ME設備會周期性的向用戶發(fā)送LCPEcho-Request報文，探測用戶是否在線。2. LCP協(xié)議通過互相發(fā)送Echo-Request報文，然后接收對端回應的Echo-reply 報文，來探測LCP鏈接是否正常，以維持LCP連接?？谡f明：? ?有些設備或終端不支持主動發(fā)送Echo-Request報文，只能支持回應Echo-Reply報文，Echo是PPPoE用戶的探測報文。? ?協(xié)議規(guī)定默認的 Echo探測次數(shù)為3次，每20秒為一個周期，BRAS設備從用戶上線的 一個周期后開始探測，探測3次都未收到用戶的 Reply報文，即20 * (3 + 1) = 80秒

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

7、成極大的威脅。因此， 它適用于對網(wǎng)絡安全要求相對較低的環(huán)境。用戶發(fā)送認證端發(fā)驗證請求報文、并且接收到ME設備回應認的證成功報文后，表示PAP認證己經(jīng)成功。否則 ME設備會回應認證失敗報文，通知用戶認證不成功。圖3 PAP認證流程ClientServerRadiusAuth-req卩卩p認陀階段Auth-reqAulh-ackAuth-ack? CHAP認證CHAP為三次握手協(xié)議。只在網(wǎng)絡上傳輸用戶名，并不傳輸用戶口令，因此它的安全性 要比PAP高。CHAP的驗證過程為：首先由驗證方向被驗證方發(fā)送一些隨機產(chǎn)生的報文， 并同時將本端的主機名附帶上一起發(fā)送給被驗證方。被驗證方接到對端對本端的驗證 請

8、求(Challe nge)時，便根據(jù)此報文中驗證方的主機名和本端的用戶表查找用戶口令 字,如找到用戶表中與驗證方主機名相同的用戶，便利用報文ID、此用戶的密鑰用 Md5算法生成應答(Resp onse)，隨后將應答和自己的主機名送回。驗證方接到此應答后， 用報文ID、本方保留的口令字(密鑰)和隨機報文用Md5算法得岀結果，與被驗證方應答比較，根據(jù)比較結果返回相應的結果(ACK or NAK )?接受認證端發(fā)送 Challe nge申請認證端發(fā)驗證請求報文 接受認證端回應認證接受報文經(jīng)過以上三次報文交互后，CHAP認證完成，報文流程見下圖圖4 CHAP認證流程ClientServerRadius

9、Challenge(CHAP)Auth-rqPPP認證階段Auth-ackAuth-reqAuth-ackNCP階段NCP有很多種，女口 IPCP、BCR IPv6CP,最為常用的是IPCP協(xié)議。NCP的主要功能是協(xié)商 PPP報 文的網(wǎng)絡層參數(shù)，如 IP地址，DNS Server IP 地址，WINS Server IP 地址等。PPPoE用戶主要 通過IPCP來獲取訪問網(wǎng)絡的 IP地址或IP地址段。NCP流程與LCP流程類似，用戶與 ME設備之間互相發(fā)送 NCPConfig-Request 報文并且互相回應NCP Config-Ack報文后，標志 NCP己協(xié)商完，用戶上線成功，可以正常訪問網(wǎng)

10、絡了。? IPCPIPCP的協(xié)商過程是基于 PPP狀態(tài)機進行協(xié)商的。經(jīng)過雙方協(xié)商，通過配置請求、配置 確認、配置否認等包文交換配置信息，最終由initial （ 或closed）狀態(tài)變?yōu)镺pened狀態(tài)。IPCP狀態(tài)變?yōu)镺pened的條件必須是發(fā)送方和接收方都發(fā)送和接收過確認包文。IPCP協(xié)商過程中，協(xié)商包文可包含多個選項，即參數(shù)。各個選項的拒絕或否認都不能影響IPCP的UP, IPCP可以無選項協(xié)商，無選項協(xié)商也同樣能夠UP。選項有IP Address、網(wǎng)關、掩碼等，其中IP Address是最重要的一個選項，有些廠家的實現(xiàn)必須這個選項 得到確認，大多數(shù)廠家的實現(xiàn)允許這個選項為空。NCP的基本協(xié)商流程見下圖：圖5 NCP的基本協(xié)商流程ClientServer協(xié)商階段Parmet$r-reqParmeteir-ackParmetr-reqParmeter-ackwPPPoE接入流程PPPoE-CHAP為例，PPP用戶接入流程如下：圖6 PPP用戶接入流程UserME60AAA ServerFPPoE協(xié)關1.PAD