（1） PPP 協定簡介
PPP 主要由三類協定族組成：
鍊路控制協定族（LCP）： 主要用來建立、拆除和監控PPP資料鍊路。
網絡層控制協定族（NCP）: 主要用來協商在該資料鍊路上所傳輸的資料包的格式與類型。
擴充協定族CHAP和PAP: 主要用于網絡安全方面的驗證，驗證對端裝置的合法性。
（2） PPP 鍊路的狀态機
首先實體狀态是一個 Dead 的狀态，加電以後直接進入 Establish 狀态，這個過程就是LCP 開始工作，當 LCP Open 以後，進入認證，如果有認證，就進入認證階段，如果沒有認證的話，直接進入 network 階段，認證階段又分 2 種情況，一種是能成功的話，進入network 階段，如果是失敗的話，就進入 Terminate 階段，就終止了，後會發送 down，回到 Dead 狀态。Establish 如果是 LCP 沒有建立成功，直接回到 Dead 的狀态。
認證是有 2 種，一個是 CHAP、一個是 PAP，network 狀态就是 NCP 狀态。當我們這個會話結束了，沒有資料要傳了，想要把這個連結終止就進入 Terminate 狀态。
（3） PPP 鍊路建立的過程
PPP鍊路建立過程分為三個階段： LCP協商階段、認證階段（可選）、NCP協商階段；
階段 1：LCP協商階段
當實體層可用時，PPP 首先進行 LCP 協商，協商内容包括工作方式是 SP 還是 MP，驗證方式，最大傳輸單元等。LCP 協商通過後，此時 LCP 狀态為 Opened，表示鍊路已經建立。
階段 2：認證階段
使用者認證階段是可選的。如果配置了使用者認證，就進入認證階段。在認證階段可以選擇 PAP 認證或者 CHAP 認證。認證通過後，進入 Network 協商階段。
階段 3：網絡層協定階段
PPP 完成前面的階段後，每一個網絡層協定（例如 IP、IPX 或者AppleTalk）必須通過各自相應的 NCP 分别進行協商。NCP 協商支援 IPCP 協商，IPCP 協商主要包括雙方的 IP 位址。當一個 NCP 處于 Opened 狀态時，該網絡層協定就可以通過這條鍊路發送封包了。
這樣，經過三個階段以後，一條完整的 PPP 鍊路就建立起來了。
PPP 協定的 LCP 的功能
建立、拆除和監控 PPP 鍊路； 檢測是否存在環路； 認證機制協商(PAP,CHAP)； MLP 協商；壓縮機制協商；
LCP 協定協商的過程
鍊路兩端互動 config-request
同意對方的鍊路層參數則回 config-ack
不同意對方的鍊路層參數則回 config-nak
不識别對方的鍊路層參數則回 config-reject
連續 10 次沒有收到 config-request 的回應，則認為對方不可用
LCP 是如何檢測環路的？
收到一個 Configure-Request 封包之後，其包含的魔術字需要和本地産生的魔術字做比較，如果不同，表示鍊路無環路，則使用 Confugure-Ack 封包确認（其他參數也協商成功），表示魔術字協商成功。在後續發送的封包中，如果封包含有魔術字字段，則該字段設定為協商成功的魔術字，LCP 不再産生新的魔術字。
如果收到的 Configure-Request 封包和自身産生的魔術字相同，則發送一個 Configure-Nak封包，攜帶一個新的魔術字。然後，不管新收到的 Configure-Nak 封包中是否攜帶相同的魔術字，LCP 都發送一個新的 Configure-Request 封包，攜帶一個新的魔術字。如果鍊路有環路，則這個過程會不停的持續下去，如果鍊路沒有環路，則封包互動會很快恢複正常。
PAP 認證過程
PAP 認證為兩次握手認證，密碼為明文，PAP 驗證的過程如下：
被驗證方把本地使用者名和密碼以明文的形式發送到驗證方 驗證方根據本地使用者表檢視是否有被驗證方的使用者名 若沒有，則認證失敗； 若有，則檢視密碼是否正确，若密碼正确，則認證通過；若密碼不正确， 則認證失敗。PAP 認證的特點是在網絡上以明文的方式傳遞使用者名及密碼。如果在傳輸過程中被截獲，便有可能對網絡安全造成極大的威脅。
CHAP 認證過程
認證端接口配置使用者名的情況下，被認證端接口使用者名一定要配，密碼可配可不配；認證端的接口下沒有配置使用者名的情況下，被認證端的接口下使用者名一定要配，此時密碼也必須配置。否則認證過程失敗。
a.驗證方配置使用者名的驗證過程
a)驗證方主動發起驗證請求，驗證方向被驗證方發送一些随機産生的封包（ Challenge），并同時将本端的使用者名附帶上一起發送給被驗證方（挑戰封包裡面包含一個随機數和ID）
b)被驗證方接到驗證方的驗證請求後，先檢查本端接口上是否配置了ppp chap password指令，如果配置了該指令，則被驗證方用封包ID、随機數，指令中配置的使用者密碼和MD5算法對該随機封包進行加密，将生成的密文和接口的使用者名發回驗證方 （Response）。 如果接口上未配置ppp chap password指令，則根據此封包中驗證方的使用者名在本端的使用者表查找該使用者對應的密碼，用封包 ID、随機數，此使用者的密鑰（密碼）和MD5算法對該随機封包進行加密，将生成的密文和被驗證方自己的使用者名發回驗證方 （Response）
c)驗證方用自己儲存的被驗證方密碼和MD5算法對原随機封包加密，比較二者的密文，若比較結果一緻，認證通過，若比較結果不一緻，認證失敗
b.驗證方沒有配置使用者名的驗證過程
a)驗證方主動發起驗證請求，驗證方向被驗證方發送一些随機産生的封包（Challenge）
b)被驗證方接到驗證方的驗證請求後，利用封包ID、随機數，ppp chap password指令配置的CHAP密碼和MD5算法對該随機封包進行加密，将生成的密文和接口的使用者名發回驗證方（Response）
c)驗證方用自己儲存的被驗證方密碼和MD5算法對原随機封包加密，比較二者的密文，若比較結果一緻，認證通過，若比較結果不一緻，認證失敗