PPPoE （ Point to Point Protocol over Ethernet ，基於以太網的點對點協議）的工作流程包含發現（ Discovery ） 和會話（ Session ）兩個階段，發現階段是無狀態的，目的是獲得PPPoE 終端（在局端的ADSL 設備上）的以太網MAC 地址，並建立一個惟一的PPPoE SESSION-ID 。發現階段結束後，就進入標準的PPP 會話階段。
1.發現階段（ PPPoED ：PPPoE Discovery )
1.1 PADI （ PPPoE Active Discovery Initiation ）
主機廣播發起分組，分組的目的地址爲以太網的廣播地址0xffffffffffff ，CODE （代碼）字段
值爲0×09（ PADI Code ）， SESSION-ID （會話ID）字段值爲0x0000 。PADI 分組必須至
少包含一個服務名稱類型的標籤（Service Name Tag ，字段值爲0x0101 ），向接入集中器
提出所要求提供的服務。
1.2 PADO （ PPPoE Active Discovery Offer ）
接入集中器收到在服務範圍內的PADI 分組，發送PPPoE 有效發現提供包分組，以響應請
求。其中CODE 字段值爲0×07（PADO Code ），SESSION-ID 字段值仍爲0x0000 。PADO
分組必須包含一個接入集中器名稱類型的標籤（ Access Concentrator Name Tag ，字段值
爲0x0102 ），以及一個或多個服務名稱類型標籤，表明可向主機提供的服務種類。PADO
和PADI 的Host-Uniq Tag 值相同.
1.3 PADR （ PPPoE Active Discovery Request ）
主機在可能收到的多個PADO 分組中選擇一個合適的PADO 分組， 然後向所選擇的接入集
中器發送PPPoE 有效發現請求分組。其中CODE 字段爲0x19（PADR Code ），SESSION_ID
字段值仍爲0x0000 。PADR 分組必須包含一個服務名稱類型標籤，確定向接入集線器（或
交換機）請求的服務種類。當主機在指定的時間內沒有接收到PADO ，它應該重新發送它
的PADI 分組，並且加倍等待時間，這個過程會被重複期望的次數。
1.4 PADS （ PPPoE Active Discovery Session -confirmation ）
接入集中器收到PADR 分組後準備開始PPP 會話，它發送一個PPPoE 有效發現會話確認
PADS 分組。其中CODE 字段值爲0×65 （PADS Code ）， SESSION-ID 字段值爲接入集
中器所產生的一個惟一的PPPoE 會話標識號碼。PADS 分組也必須包含一個接入集中器名
稱類型的標籤以確認向主機提供的服務。當主機收到PADS 分組確認後，雙方就進入PPP
會話階段。PADS 和PADR 的Host-Uniq Tag 值相同。
2.會話階段（ PPPoES ：PPPoE Session ）
PPP 會話的建立，需要兩端的設備都發送LCP 數據包來配置和測試數據通信鏈路。
用戶主機與接入集中器根據在發現階段所協商的PPP 會話連接參數進行PPP 會話。一旦
PPPoE 會話開始， PPP 數據就可以以任何其他的PPP 封裝形式發送。所有的以太網幀都
是單播的。PPPoE 會話的SESSION-ID 一定不能改變，並且必須是發現階段分配的值。
2.1 LCP 協商階段（LCP ： Link Control Protocol ）
LCP 的Request 主機和AC 都要給對方發送， LCP 協商階段完成最大傳輸單元（ MTU ），
是否進行認證和採用何種認證方式（ Authentication Type ）的協商。
（1）LCP 協議數據報文分類
鏈路配置報文：用來建立和配置一條鏈路，主要包括Configure-Request 、Configure-Ack 、
Configure-Nak 和Configure-Reject 報文
鏈路維護報文：用來管理和調試鏈路，主要包括Code-Reject 、Protocol-Reject 、
Echo-Request 、Echo-Reply 和Discard-Request 報文
鏈路終止報文：用來終止一條鏈路， 主要包括Terminate-Request 和Terminate-Reply 報文
（2）LCP 協商過程
LCP 協商的過程如下：協商雙方互相發送一個LCP Config-Request 報文，確認收到的
Config-Request 報文中的協商選項，根據這些選項的支持與接受情況，做出適當的迴應。
若兩端都回應了Config-ACK ，則標誌LCP 鏈路建立成功， 否則會繼續發送Request 報文，
直到對端迴應了ACK 報文爲止。
說明：
（1） Config-ACK ：若完全支持對端的LCP 選項，則迴應Config-ACK 報文，報文中必須
完全協帶對端Request 報文中的選項。
（2）Config-NAK ：若支持對端的協商選項， 但不認可該項協商的內容， 則迴應Config-NAK
報文，在Config-NAK 的選項中填上自己期望的內容，如:對端MRU 值爲1500 ，而自己期
望MRU 值爲1492 ，則在Config-NAK 報文中埴上自己的期望值1492 。
（3） Config-Reject ：若不能支持對端的協商選項，則迴應Config-Reject 報文，報文中帶
上不能支持的選項， 如Windows 撥號器會協商CBCP（被叫回呼） ，而ME60 不支持CBCP
功能，則回將此選項拒絕掉。
2.2 認證階段（PPP Authentication ：PAP/CHAP ）
會話雙方通過LCP 協商好的認證方法進行認證，如果認證通過了，纔可以進行下面的網絡
層的協商。認證過程在鏈路協商結束後就進行。
Ⅰ PAP （ Password Authentication Protocol ，口令認證協議）認證
PAP 爲兩次握手協議，它通過用戶名及口令來對用戶進行驗證。PAP 驗證過程如下：
當兩端鏈路可相互傳輸數據時， 被驗證方發送本端的用戶名及口令到驗證方， 驗證方根據本
端的用戶表（或Radius 服務器）查看是否有此用戶，口令是否正確。如正確則會給對端發
送Authenticate-ACK 報文， 通告對端已被允許進入下一階段協商； 否則發送NAK 報文， 通
告對端驗證失敗。此時， 並不會直接將鏈路關閉。只有當驗證不過次數達到一定值（缺省爲
10 ）時，纔會關閉鏈路。
PAP 的特點是在網絡上以明文的方式傳遞用戶名及口令，如在傳輸過程中被截獲，便有可
能對網絡安全造成極大的威脅。因此，它適用於對網絡安全要求相對較低的環境。
Ⅱ CHAP （ Challenge Handshake Authentication Protocol ，質詢握手認證協議）認證
CHAP 爲三次握手協議。只在網絡上傳輸用戶名， 並不傳輸用戶口令，因此它的安全性要比
PAP 高。CHAP 的驗證過程爲：
首先由驗證方（ Server ）向被驗證方（ Client ）發送一些隨機產生的報文，並同時將本端的
主機名附帶上一起發送給被驗證方。被驗證方接到對端對本端的驗證請求（ Challenge ）時，
便根據此報文中驗證方的主機名和本端的用戶表查找用戶口令字， 如找到用戶表中與驗證方
主機名相同的用戶， 便利用報文ID 、此用戶的密鑰用Md5 算法生成應答（ Response ），
隨後將應答和自己的主機名送回。驗證方接到此應答後， 用報文ID 、本方保留的口令字（密
鑰）和隨機報文用Md5 算法得出結果，與被驗證方應答比較，根據比較結果返回相應的結
果（ ACK or NAK ）
（1）接受認證端發送Challenge
（2）申請認證端發驗證請求報文
（3）接受認證端迴應認證接受報文
經過以上三次報文交互後， CHAP 認證完成。
2.3 NCP 協商階段（NCP ： Network Control Protocol ）
NCP 有很多種，如IPCP 、BCP 、IPv6CP ，最爲常用的是IPCP （ Internet Protocol Control
Protocol ）協議。NCP 的主要功能是協商PPP 報文的網絡層參數，如IP 地址， DNS Server
IP 地址， WINS Server IP 地址等。PPPoE 用戶主要通過IPCP 來獲取訪問網絡的IP 地址
或IP 地址段。
NCP 流程與LCP 流程類似，用戶與ME 設備之間互相發送NCP Config-Request 報文並且
互相迴應NCP Config-Ack 報文後，標誌NCP 己協商完，用戶上線成功，可以正常訪問網
絡了。
IPCP 的協商過程是基於PPP 狀態機進行協商的。經過雙方協商，通過配置請求、配置確
認、配置否認等包文交換配置信息， 最終由initial ( 或closed) 狀態變爲Opened 狀態。IPCP
狀態變爲Opened 的條件必須是發送方和接收方都發送和接收過確認包文。
IPCP 協商過程中，協商包文可包含多個選項，即參數。各個選項的拒絕或否認都不能影響
IPCP 的UP，IPCP 可以無選項協商，無選項協商也同樣能夠UP 。選項有IP Address 、網
關、掩碼等，其中IP Address 是最重要的一個選項，有些廠家的實現必須這個選項得到確
認，大多數廠家的實現允許這個選項爲空。
NCP 的基本協商流程見下圖：
用戶和接入設備對IP 服務階段的一些要求進行多次協商，以決定雙方都能夠接收的約定。
如： IP 業務階段使用的IP 壓縮協議等。雙方的協議是通過報文中包含的Option 項進行協
商的，每一個Option 都是一個需要協商的問題。
最後雙方都需要對方答覆Configure_Ack 的同意報文。
2.4 會話維持（ Session Keep-alive ）
設備主動發送Echo Request 進行PPPoE 心跳保活，若3 次未得到服務器的響應，則設備
主動釋放地址。發LCP Echo Request 的時候，魔術字字段要和之前通信的
Configure_Request 使用的魔術字字段保持一致。
有些設備或終端不支持主動發送Echo-Request 報文, 只能支持迴應Echo-Reply 報文。
2.5 會話結束（ Session Termination ）
PPPoE 還有一個PADT （ PPPOE Active Discovery Terminate ）分組，它可以在會話建立
後的任何時候發送，來終止PPPoE 會話，也就是會話釋放。它可以由主機或者接入集中器
發送，目的地址填充爲對端的以太網的MAC 地址。
當對方接收到一個PADT （ PPPOE Active Discovery Terminate ）分組，就不再允許使用
這個會話來發送PPP 業務。PADT 分組不需要任何標籤， 其CODE 字段值爲0xa7 （ PADT
Code ），SESSION-ID 字段值爲需要終止的PPP 會話的會話標識號碼。在發送或接收PADT
後，即使正常的PPP 終止分組也不必發送。PPP 對端應該使用PPP 協議自身來終止PPPoE
會話，但是當PPP 不能使用時，可以使用PADT 。
3.PPPoE 接入流程示例
PPP 狀態變遷如圖6 所示：
以PPPoE-CHAP 爲例， PPP 用戶接入流程如圖7 所示：
4.Linux 中的PPPoE 撥號守護進程（pppd ：Point-to-Point Protocol Daemon ）
pppd 是一個後臺服務進程(daemon) ，是一個用戶空間的進程，所以把策略性的內容從內核
的PPP 協議處理模塊移到pppd 中是很自然的事了。pppd 實現了所有鑑權、壓縮/解壓和加
密/解密等擴展功能的控制協議。
pppd 只是一個普通的用戶進程，它如何擴展PPP 協議呢？這就是pppd 與內核中的PPP
協議處理模塊之間約定了， 它們之間採用了最傳統的內核空間與用戶空間之間通信方式： 設
備文件。
設備文件名是/dev/ppp 。通過read 系統調用，pppd 可以讀取PPP 協議處理模塊的數據包，
當然， PPP 協議處理模塊只會把應該由pppd 處理的數據包發給pppd 。通過write 系統調
用， pppd 可以把要發送的數據包傳遞給PPP 協議處理模塊。通過ioctrl 系統調用， pppd
可以設置PPP 協議的參數，可以建立/關閉連接。