本文會以PPP協定的角度出發，帶出乙太網路，然後會介紹PPPoE協定。主要將提及PPPoE在乙太網路中建立連線的過程，也會詳細介紹PPPoE承自PPP協定的主要特性等等。
因此，認證的發生時間是在PPP協定連線建立之後就進行的。進行時，遠端的電腦或是網路設備會不斷地發送帳號和密碼到Cisco路由器，這樣的發送過程會一直持續，直到這個認證被接受或是這個PPP連線被中斷為止。
PAP認證協定的隱憂
雖然PPP協定使用著PAP認證協定，但事實上，PAP認證協定本身並不是一個很嚴謹的認證協定，因為PAP認證協定會把密碼用純文字（Clear Text）的方式來傳送，這也代表著在傳送過程中密碼是不會被加密，因此一旦有人攔截到這樣的網路封包，就可以直接查看密碼。
這樣的運作模式除了Token Ring網路架構之外，在大部分的網路環境中是相當不安全的。不僅如此，PAP協定針對Playback和Trial-and-error的攻擊方式也沒有任何的保護措施。
CHAP認證協定
另外一種PPP連線的認證協定是CHAP認證協定，CHAP認證協定採用的運作流程是3-Way Handshake，如果使用CHAP認證協定，則當PPP連線建立階段完成後，Cisco路由器設備（本地端）就會發送所謂的Challenge封包給遠端的網路設備。
接下來，遠端的網路設備會透過One Way Hash的方式，針對傳送過來的Challenge值和密碼，計算出一個特定的值，然後將這個特定的值傳回給原本發送的Cisco路由器設備，這裡所使用的One Way Hash方式一般而言都是使用MD5（Message Digest 5）演算法。
接著，本地端的Cisco路由器設備會根據已知的計算方式再次計算出Hash值，然後比對自己所計算的Hash值和收到的Hash值是否相同。如果兩個計算出來的Hash值相同，則代表這個認證已經通過，否則會立刻中斷目前這個PPP連線。
CHAP認證協定比較安全的地方
看得出來，CHAP認證協定比PAP認證協定安全許多，因為雙方都會計算出特定的Hash值加以比對，而且並不會把密碼直接用明文的方式來傳送。不僅如此，CHAP認證協定對於Playback的攻擊方式有相對應的保護措施。
除此之外，剛剛所提到的Challenge值很難被預測出是怎樣的值，因為Challenge值是亂數產生的，所以這也代表所計算出來的Hash值也是亂數產生的。此外，剛剛有提到Challenge封包是會一直發送，這種作法也可以避免受到攻擊，因為每次發送的Challenge值都是不一樣的。
PPPoE協定的工作階段
了解PPP協定之後，筆者假設大多人對於乙太網路了解比較多，那接下來就可以來介紹PPPoE詳細的連線建立過程。PPPoE協定最初的設計緣由是希望能夠提供一個小型區域網路，並且讓小型區域網路中的每一個設備都能單獨連線到外部的網路。PPPoE協定也成功地為一般使用者提供便宜的解決方案。
PPPoE協定工作共分為PPPoE Discovery和PPPoE Session兩個主要階段，以下大致說明一下這兩個階段。
PPPoE Discovery
一般的PPP連線會建立在Serial Link或是透過ATM虛擬線路的撥接（Dial-up）來連線，所以PPP的資料在傳送時都是確定對方可以到達才開始發送。
但是，乙太網路的設計是Multi-access，也就是說乙太網路上的每一個節點，都可以對任何其他一個節點做存取的動作。所以，在乙太網路的封包中會包含目的地端的MAC位址，以便於讓資料封包能夠正確無誤地傳送到達目的地。
也因此，如果PPP協定的封包希望能夠在乙太網路的架構上面運作，則乙太網路封包中目的端和發送端的MAC位址就必須先被發現（Discovered），進而被封裝到PPP協定的Control封包（Control Packets）之中，而這個動作正是PPPoE Discovery工作階段的重點。
另外，PPPoE Discovery還有做到的，就是把這個點對點連線的Session ID建立起來，以便於後續的資料傳送。
這個PPPoE Discovery其實步驟還可以分得更詳細，而詳細的步驟是基於「伺服器端」與「用戶端」角色的交互運作來完成。
有趣的是，有些讀者可能已經發現，剛才一直都說PPP連線事實上是一個「點對點」的連線，為什麼這裡還可以區分成伺服器端與用戶端呢？原因是，即便是在PPP的連線環境內，多個主機依然可以透過一個單一的實體連線連到另外一台用於提供服務的伺服器端。
以這樣的情況來說，就可以區分伺服器與用戶端，其步驟如圖2所示，而且基本上分為四個步驟：
 |
| ▲圖2 PPP的連線環境內依然可以區分伺服器與用戶端。 |
第一步驟：PADI
第一個步驟主要內容為Initiation，PADI是PPPoE Active Discovery Initiation的縮寫。當使用者要連線到網路的時候，這個用戶端必須先在網路上找到DSL-AC，也就是DSL Access Concentrator。
這篇文章有提到，在乙太網路中大家都是用MAC位址來定位對方，但是這個時候用戶端還不知道DSL-AC的MAC位址是什麼，因此就會在乙太網路內發送一個PADI封包，以廣播的方式送出，以便於找到DSL-AC。
這個封包裡面會包含發送端的MAC位址，所謂廣播的方式就是把目的端的MAC位址設定為FF:FF:FF:FF:FF:FF。所以，這個步驟主要是從用戶端發到伺服器端。
第二步驟：PADO
PADO是PPPoE Active Discovery Offer的縮寫。一旦DSL-AC收到由用戶端廣播出來的PADI封包，DSL-AC就會去解析這個封包，取出來源端的MAC位址，然後回傳PADO封包。
這個封包的目的當然就是讓用戶端知道DSL-AC的位址，所以封包內容會包含DSL-AC的MAC位址、名稱以及服務等等。因此，這個步驟是由伺服器端傳回到用戶端。
第三步驟：PADR
PADR是PPPoE Active Discovery Request的縮寫。如同其名，這個步驟用於發送Requests。到了這個步驟，也就代表用戶端已經知道DSL-AC的位址，可以準備提出需求要做出連線。所以，這個步驟主要是用於確認DSL-AC所提供的PPPoE連線。