1. PPPoE的驗證過程
PPPoE的驗證過程，包括2個階段，Discovery階段和PPP Session階段。
2.Discovery階段，包含4個步驟：
Step 1 ：PADI（PPPoE Active Discovery Initiation）
PPPoE客戶端發送主動發現初始化包（PPPoE Active Discovery Initiation，PADI）以太頭中的目的地址是以太廣播地址 FF:FF:FF:FF:FF:FF，PPPOE 頭中的 CODE 為 0x09，SESSION_ID 值必須為 0，負載部分必須只包含一個 Service-Name 類型的 TAG 表示請求的服務類型，另外可以包含其他 TAG，整個 PPPOE 包不能超過 1484 字節；
Step 2: PADO（PPPoE Active Discovery Offer）
服務器端 PPPoE 進程在網絡接口偵聽到 PADI 包后，發送主動發現提議包(PPPoEActive Discovery Offer, PADO)，用來回應客戶機的 PADI 包，以太頭中的目的地址是客戶機的mac 地址，PPPOE 頭中的 CODE 為 0x07， SESSION_ID 值必須為 0，負載部分必須包含一個 AC-Name 類型的 TAG，用來指示本 AC 的名稱，一個在 PADI 包中指定的Service- Name 的 TAG，另外可以包含其他 Service-Name 的 TAG。如果 AC 不對該客戶機提供服務，AC 就不回應 PADO 包。
Step 3: PADR（PPPoE Active Discovery Request）
PPPoE 客戶端收到 PADO 包后，在 PADO 包中選擇一個（可能有多個 PPPoE 服務器，通常選取最快的一個）發送主動發現請求包（PPPoEActive Discovery Request，PADR），以太頭中的目的地址是所選取的 PADO 包的源以太頭地址（即 PPPoE 服務器的 MAC 地址），PPPOE 頭中的 CODE 為 0x19，SESSION_ID 值必須為 0，負載部分必須只包含一個 Service-Name 類型的 TAG 表示請求的服務類型，另外可以包含其他 TAG。
Step 4: PADS（PPPoE Active Discovery Seession-Confirmation）
MAC 地址匹配的 PPPoE 服務器收到 PADR 包后，發送主動發現會話確認包(PPPoE Active Discovery Session-confirmation, PADS)，將產生一個 SEESSION_ID 值用來標志本次 PPP 會話，以 PADR 包方式發送給客戶機。以太頭中的目的地址是客戶機的 MAC 地址，PPPOE 頭中 的 CODE 為 0x65，SESSION_ID 值必須為所生成的那個SESSION_ID，負載部分必須只包含一個 Service-Name 類型的 TAG， 表示該服務類型被 PPPoE 服務器接受，另外可以包含其他 TAG。如果 PPPoE 服務器不接受 PADR 中的
Server-Name，PADS 中則包含一個 Service-Name -Error 類型的 TAG,這時 SESSION_ID 設置為 0。
3. PPP Session 階段:
當客戶端與服務器端遠成發現階段之后，即進入會話階段，在 PPP 會話階段，PPP 包被封裝在 PPPoE 以太幀中，以太包目的地址都是單一的，以太協議為 0x8864， PPPoE 頭的CODE必須為0，SESSION_ID必須一直為發現階段協商出的SEESION_ID值， PPPoE 的負載是整個 PPP 包，PPP 包前是兩字節的 PPP 協議 ID 值。
Step 1: LCP（Link Control Protocol）協商
主要協商了MRU（Maximum Receive Unit），并提出了認證使用的Magic Number。
圖3-1 client發送到server的Configuration Request
圖3-2 server發送到client的Configuration Request
圖3-3 client發送到server的Configuration Ack
圖3-4 server發送到client的Configuration Ack
Step 2: 認證階段
認證階段務器端將驗證客戶端的合法性。最常見的兩種就是PAP和CHAP；
PAP（Password Authentication Protocol）驗證為兩次握手驗證，密碼為明文；
PAP驗證的過程如下：
(1)被驗證方發送用戶名和密碼到驗證方；
(2)驗證方根據本端用戶表查看是否有此用戶以及密碼是否正確，然后返回不同的響應。
CHAP（Challenge-Handshake Authentication Protocol）驗證為三次握手驗證，密碼為密文（密鑰）；
注意：PAP不是一種安全的驗證協議。當驗證時，口令以明文方式在鏈路上發送，并且由于完成PPP鏈路建立后，被驗證方會不停地在鏈路上反復發送用戶名和口令，直到身份驗證過程結束，所以不能防止攻擊。
CHAP驗證過程如下：
(1)Challenge：驗證方主動發起驗證請求，驗證方向被驗證方發送一些隨機產生的報文，并同時將本端的用戶名附帶上一起發送給被驗證方；
(2)Response：若被驗證方接到驗證方的驗證請求后，檢查本端接口上是否配置了缺省的CHAP密碼，如果配置了則被驗證方利用報文ID、該缺省密碼和MD5算法對該隨機報文進行加密，將生成的密文和自己的用戶名發回驗證方；若被驗證方檢查發現本端接口上沒有配置缺省的CHAP密碼，則被驗證方根據此報文中驗證方的用戶名在本端的用戶表查找該用戶對應的密碼，如果在用戶表找到了與驗證方用戶名相同的用戶，便利用報文ID、此用戶的密鑰（密碼）和MD5算法對該隨機報文進行加密，將生成的密文和被驗證方自己的用戶名發回驗證方；
(3)result:驗證方用自己保存的被驗證方密碼和MD5算法對原隨機報文加密，比較二者的密文，根據比較結果返回不同的響應。
圖3-5 server發送到client的Challenge
圖3-5 client發送到server的Response
圖3-6 server發送到client的Success
Step 3: IPCP（IP Control Protocol）階段
圖3-7 server發送到client的Configuration Request
圖3-8 client發送到server的Configuration Request
圖3-9 server發送到client的Configuration Nak
圖3-10 client發送到server的Configuration Ack
圖3-11 client發送到server的Configuration Request
圖3-12 server發送到client的Configuration Ack
