1.1 PADI（PPPoE Active Discovery Initiation）
主機(jī)廣播發(fā)起分組，分組的目的地址為以太網(wǎng)的廣播地址 0xffffffffffff，CODE（代碼）字段值為0×09（PADI Code），SESSION-ID（會(huì)話ID）字段值為0x0000。PADI分組必須至少包含一個(gè)服務(wù)名稱類型的標(biāo)簽（Service Name Tag，字段值為0x0101），向接入集中器提出所要求提供的服務(wù)。
1.2 PADO（PPPoE Active Discovery Offer）
接入集中器收到在服務(wù)范圍內(nèi)的PADI分組，發(fā)送PPPoE有效發(fā)現(xiàn)提供包分組，以響應(yīng)請(qǐng)求。其中CODE字段值為0×07（PADO Code），SESSION-ID字段值仍為0x0000。PADO分組必須包含一個(gè)接入集中器名稱類型的標(biāo)簽（Access Concentrator Name Tag，字段值為0x0102），以及一個(gè)或多個(gè)服務(wù)名稱類型標(biāo)簽，表明可向主機(jī)提供的服務(wù)種類。PADO和PADI的Host-Uniq Tag值相同。
1.3 PADR（PPPoE Active Discovery Request）
主機(jī)在可能收到的多個(gè)PADO分組中選擇一個(gè)合適的PADO分組，然后向所選擇的接入集中器發(fā)送PPPoE有效發(fā)現(xiàn)請(qǐng)求分組。其中CODE字段為0x19（PADR Code），SESSION_ID字段值仍為0x0000。PADR分組必須包含一個(gè)服務(wù)名稱類型標(biāo)簽，確定向接入集線器（或交換機(jī)）請(qǐng)求的服務(wù)種類。當(dāng)主機(jī)在指定的時(shí)間內(nèi)沒(méi)有接收到PADO，它應(yīng)該重新發(fā)送它的PADI分組，并且加倍等待時(shí)間，這個(gè)過(guò)程會(huì)被重復(fù)期望的次數(shù)。
1.4 PADS（PPPoE Active Discovery Session-confirmation）
接入集中器收到PADR分組后準(zhǔn)備開(kāi)始PPP會(huì)話，它發(fā)送一個(gè)PPPoE有效發(fā)現(xiàn)會(huì)話確認(rèn)PADS分組。其中CODE字段值為0×65（PADS Code），SESSION-ID字段值為接入集中器所產(chǎn)生的一個(gè)惟一的PPPoE會(huì)話標(biāo)識(shí)號(hào)碼。PADS分組也必須包含一個(gè)接入集中器名稱類型的標(biāo)簽以確認(rèn)向主機(jī)提供的服務(wù)。當(dāng)主機(jī)收到PADS 分組確認(rèn)后，雙方就進(jìn)入PPP會(huì)話階段。PADS和PADR的Host-Uniq Tag值相同。
圖1 PPPoE的協(xié)商流程
PPP會(huì)話的建立，需要兩端的設(shè)備都發(fā)送LCP數(shù)據(jù)包來(lái)配置和測(cè)試數(shù)據(jù)通信鏈路。
用戶主機(jī)與接入集中器根據(jù)在發(fā)現(xiàn)階段所協(xié)商的PPP會(huì)話連接參數(shù)進(jìn)行PPP會(huì)話。一旦PPPoE會(huì)話開(kāi)始，PPP數(shù)據(jù)就可以以任何其他的PPP封裝形式發(fā)送。所有的以太網(wǎng)幀都是單播的。PPPoE會(huì)話的SESSION-ID一定不能改變，并且必須是發(fā)現(xiàn)階段分配的值。
2.1 LCP協(xié)商階段（LCP：Link Control Protocol）
LCP的Request主機(jī)和AC都要給對(duì)方發(fā)送，LCP協(xié)商階段完成最大傳輸單元（MTU），是否進(jìn)行認(rèn)證和采用何種認(rèn)證方式（Authentication Type）的協(xié)商。
（1）LCP協(xié)議數(shù)據(jù)報(bào)文分類
鏈路配置報(bào)文：用來(lái)建立和配置一條鏈路，主要包括Configure-Request、Configure-Ack、Configure-Nak和Configure-Reject報(bào)文
鏈路維護(hù)報(bào)文：用來(lái)管理和調(diào)試鏈路，主要包括Code-Reject、Protocol-Reject、Echo-Request、Echo-Reply和Discard-Request報(bào)文
鏈路終止報(bào)文：用來(lái)終止一條鏈路，主要包括Terminate-Request和Terminate-Reply報(bào)文
（2）LCP協(xié)商過(guò)程
LCP協(xié)商的過(guò)程如下：協(xié)商雙方互相發(fā)送一個(gè)LCP Config-Request報(bào)文，確認(rèn)收到的Config-Request報(bào)文中的協(xié)商選項(xiàng)，根據(jù)這些選項(xiàng)的支持與接受情況，做出適當(dāng)?shù)幕貞?yīng)。若兩端都回應(yīng)了Config-ACK，則標(biāo)志LCP鏈路建立成功，否則會(huì)繼續(xù)發(fā)送Request報(bào)文，直到對(duì)端回應(yīng)了ACK報(bào)文為止。
圖2 LCP協(xié)商的基本過(guò)程
說(shuō)明：
（1）Config-ACK：若完全支持對(duì)端的LCP選項(xiàng)，則回應(yīng)Config-ACK報(bào)文，報(bào)文中必須完全協(xié)帶對(duì)端Request報(bào)文中的選項(xiàng)。
（2）Config-NAK：若支持對(duì)端的協(xié)商選項(xiàng)，但不認(rèn)可該項(xiàng)協(xié)商的內(nèi)容，則回應(yīng)Config-NAK報(bào)文，在Config-NAK的選項(xiàng)中填上自己期望的內(nèi)容，如:對(duì)端MRU值為1500，而自己期望MRU值為1492，則在Config-NAK報(bào)文中埴上自己的期望值1492。
（3）Config-Reject：若不能支持對(duì)端的協(xié)商選項(xiàng)，則回應(yīng)Config-Reject報(bào)文，報(bào)文中帶上不能支持的選項(xiàng)，如Windows撥號(hào)器會(huì)協(xié)商CBCP（被叫回呼），而ME60不支持CBCP功能，則回將此選項(xiàng)拒絕掉。
2.2 認(rèn)證階段（PPP Authentication：PAP/CHAP）
會(huì)話雙方通過(guò)LCP協(xié)商好的認(rèn)證方法進(jìn)行認(rèn)證，如果認(rèn)證通過(guò)了，才可以進(jìn)行下面的網(wǎng)絡(luò)層的協(xié)商。認(rèn)證過(guò)程在鏈路協(xié)商結(jié)束后就進(jìn)行。
Ⅰ PAP（Password Authentication Protocol，口令認(rèn)證協(xié)議）認(rèn)證
PAP為兩次握手協(xié)議，它通過(guò)用戶名及口令來(lái)對(duì)用戶進(jìn)行驗(yàn)證。PAP驗(yàn)證過(guò)程如下：
當(dāng)兩端鏈路可相互傳輸數(shù)據(jù)時(shí)，被驗(yàn)證方發(fā)送本端的用戶名及口令到驗(yàn)證方，驗(yàn)證方根據(jù)本端的用戶表（或Radius服務(wù)器）查看是否有此用戶，口令是否正確。如正確則會(huì)給對(duì)端發(fā)送Authenticate-ACK報(bào)文，通告對(duì)端已被允許進(jìn)入下一階段協(xié)商；否則發(fā)送NAK報(bào)文，通告對(duì)端驗(yàn)證失敗。此時(shí)，并不會(huì)直接將鏈路關(guān)閉。只有當(dāng)驗(yàn)證不過(guò)次數(shù)達(dá)到一定值（缺省為10）時(shí)，才會(huì)關(guān)閉鏈路。
PAP的特點(diǎn)是在網(wǎng)絡(luò)上以明文的方式傳遞用戶名及口令，如在傳輸過(guò)程中被截獲，便有可能對(duì)網(wǎng)絡(luò)安全造成極大的威脅。因此，它適用于對(duì)網(wǎng)絡(luò)安全要求相對(duì)較低的環(huán)境。
圖3 PAP認(rèn)證流程
Ⅱ CHAP（Challenge Handshake Authentication Protocol，質(zhì)詢握手認(rèn)證協(xié)議）認(rèn)證
CHAP為三次握手協(xié)議。只在網(wǎng)絡(luò)上傳輸用戶名，并不傳輸用戶口令，因此它的安全性要比PAP高。CHAP的驗(yàn)證過(guò)程為：
首先由驗(yàn)證方（Server）向被驗(yàn)證方（Client）發(fā)送一些隨機(jī)產(chǎn)生的報(bào)文，并同時(shí)將本端的主機(jī)名附帶上一起發(fā)送給被驗(yàn)證方。被驗(yàn)證方接到對(duì)端對(duì)本端的驗(yàn)證請(qǐng)求（Challenge）時(shí)，便根據(jù)此報(bào)文中驗(yàn)證方的主機(jī)名和本端的用戶表查找用戶口令字，如找到用戶表中與驗(yàn)證方主機(jī)名相同的用戶，便利用報(bào)文ID、此用戶的密鑰用Md5算法生成應(yīng)答（Response），隨后將應(yīng)答和自己的主機(jī)名送回。驗(yàn)證方接到此應(yīng)答后，用報(bào)文ID、本方保留的口令字（密鑰）和隨機(jī)報(bào)文用Md5算法得出結(jié)果，與被驗(yàn)證方應(yīng)答比較，根據(jù)比較結(jié)果返回相應(yīng)的結(jié)果（ACK or NAK）
（1）接受認(rèn)證端發(fā)送Challenge
（2）申請(qǐng)認(rèn)證端發(fā)驗(yàn)證請(qǐng)求報(bào)文
（3）接受認(rèn)證端回應(yīng)認(rèn)證接受報(bào)文
經(jīng)過(guò)以上三次報(bào)文交互后，CHAP認(rèn)證完成。
圖4 CHAP認(rèn)證流程
2.3 NCP協(xié)商階段（NCP：Network Control Protocol）
NCP有很多種，如IPCP、BCP、IPv6CP，最為常用的是IPCP（Internet Protocol Control Protocol）協(xié)議。NCP的主要功能是協(xié)商PPP報(bào)文的網(wǎng)絡(luò)層參數(shù)，如IP地址，DNS Server IP地址，WINS Server IP地址等。PPPoE用戶主要通過(guò)IPCP來(lái)獲取訪問(wèn)網(wǎng)絡(luò)的IP地址或IP地址段。
NCP流程與LCP流程類似，用戶與ME設(shè)備之間互相發(fā)送NCP Config-Request報(bào)文并且互相回應(yīng)NCP Config-Ack報(bào)文后，標(biāo)志NCP己協(xié)商完，用戶上線成功，可以正常訪問(wèn)網(wǎng)絡(luò)了。
IPCP的協(xié)商過(guò)程是基于PPP狀態(tài)機(jī)進(jìn)行協(xié)商的。經(jīng)過(guò)雙方協(xié)商，通過(guò)配置請(qǐng)求、配置確認(rèn)、配置否認(rèn)等包文交換配置信息，最終由initial (或closed)狀態(tài)變?yōu)镺pened狀態(tài)。IPCP狀態(tài)變?yōu)镺pened的條件必須是發(fā)送方和接收方都發(fā)送和接收過(guò)確認(rèn)包文。
IPCP協(xié)商過(guò)程中，協(xié)商包文可包含多個(gè)選項(xiàng)，即參數(shù)。各個(gè)選項(xiàng)的拒絕或否認(rèn)都不能影響IPCP的UP，IPCP可以無(wú)選項(xiàng)協(xié)商，無(wú)選項(xiàng)協(xié)商也同樣能夠UP。選項(xiàng)有IP Address、網(wǎng)關(guān)、掩碼等，其中IP Address是最重要的一個(gè)選項(xiàng)，有些廠家的實(shí)現(xiàn)必須這個(gè)選項(xiàng)得到確認(rèn)，大多數(shù)廠家的實(shí)現(xiàn)允許這個(gè)選項(xiàng)為空。
NCP的基本協(xié)商流程見(jiàn)下圖：
圖5 NCP的基本協(xié)商流程
用戶和接入設(shè)備對(duì)IP服務(wù)階段的一些要求進(jìn)行多次協(xié)商，以決定雙方都能夠接收的約定。
如：IP業(yè)務(wù)階段使用的IP壓縮協(xié)議等。雙方的協(xié)議是通過(guò)報(bào)文中包含的Option項(xiàng)進(jìn)行協(xié)商的，每一個(gè)Option都是一個(gè)需要協(xié)商的問(wèn)題。
最后雙方都需要對(duì)方答復(fù)Configure_Ack的同意報(bào)文。
2.4 會(huì)話維持（Session Keep-alive）
設(shè)備主動(dòng)發(fā)送Echo Request進(jìn)行PPPoE心跳保活，若3次未得到服務(wù)器的響應(yīng)，則設(shè)備主動(dòng)釋放地址。發(fā)LCP Echo Request 的時(shí)候，魔術(shù)字字段要和之前通信的Configure_Request使用的魔術(shù)字字段保持一致。
有些設(shè)備或終端不支持主動(dòng)發(fā)送 Echo-Request 報(bào)文, 只能支持回應(yīng)Echo-Reply報(bào)文。
2.5 會(huì)話結(jié)束（Session Termination）
PPPoE 還有一個(gè)PADT（PPPOE Active Discovery Terminate）分組，它可以在會(huì)話建立后的任何時(shí)候發(fā)送，來(lái)終止PPPoE會(huì)話，也就是會(huì)話釋放。它可以由主機(jī)或者接入集中器發(fā)送，目的地址填充為對(duì)端的以太網(wǎng)的MAC地址。
當(dāng)對(duì)方接收到一個(gè) PADT（PPPOE Active Discovery Terminate）分組，就不再允許使用這個(gè)會(huì)話來(lái)發(fā)送PPP業(yè)務(wù)。PADT分組不需要任何標(biāo)簽，其CODE字段值為0xa7（PADT Code），SESSION-ID字段值為需要終止的PPP會(huì)話的會(huì)話標(biāo)識(shí)號(hào)碼。在發(fā)送或接收PADT后，即使正常的PPP終止分組也不必發(fā)送。PPP對(duì)端應(yīng)該使用PPP協(xié)議自身來(lái)終止PPPoE會(huì)話，但是當(dāng)PPP不能使用時(shí)，可以使用PADT。