PPP協議支持以下功能：
- IP地址的動態分配和管理
- 同步或異步的物理層通信
- 鏈路的配置、質量檢測和糾錯
- 多種配置參數選項的協商
2. 鏈路建立階段： LCP協商，（協商認證方式等）
3. 驗證階段： PAP/CHAP驗證
**4. 網絡層協議階段：**NCP協商
5. PPP會話維持階段： 維持PPP會話， 定時發送Echo Request報文，並等待Echo Reply報文
（一）PPP 幀
PPP幀從HDLC（High-level link Control）。
- Flag：標誌位、用於標識幀的開始和結束
- Addr：地址位，用於標識Station地址。PPP幀發源自HDLC幀，保留了此字段。對於PPP幀來說，由於是點對點協議，不需要地址位。PPP幀的地址位恆爲0xFF。（PPP協議被運用在點對點鏈路上，不需要知道對端的鏈路地址，因爲點對點鏈路，如PPPoE幀頭中，已經確定了對端的地址）。
- Control：在DHLC幀中，Control位用來標識幀的順序和重傳行爲，但由於該功能在PPP協議中並沒有普遍實現，因此PPP幀中，Control值固定爲）0x03.
- Protocol：協議字段，標識所攜帶報文的類型。如0x0021時，表示PPP幀的信息字段是IP數據報文。不同的Protocol標識Data字段的不同含義。
ISO標準下 的協議域類型：
| Protocol | 對應的Data域的含義 |
|---|---|
| 0x0***-0x3*** | 網絡層的數據報文 |
| 0x4***-0x7*** | 與NCP無關的第整流量 |
| 0x8***-0xb*** | 網絡控制協議（NCP）的數據報文 |
| 0xc***-0xf*** | 鏈路控制協議(LCP)的數據報文 |
常用的幾種Protocol取值：
| Protocol | 信息字段 |
|---|---|
| 0x0021 | IP數據報 |
| 0x8021 | 網絡控制數據NCP |
| 0xC021 | 鏈路控制數據LCP |
| 0xC023 | 安全性認證PAP |
| 0xC223 | 安全性認證CHAP |
+ Pad: 填充字段
PPP工作流程
b）認證階段： LCP向對端發送協商請求， 雙方確定鏈路的配置參數後，LCP向認證層發送Up事件。常用的認證協議有PAP（口令驗證協議）和CHAP（挑戰握手驗證協議）。
c） NCP協商階段（IPCP等協議）：調用鏈路層創建階段選定的網絡控制層協議。主要包括動態分配IP地址功能等。常用的NCP協議有IPCP協議。
d）會話維持階段：進行PPPoE心跳保活
LCP（Link Control Protocol）用來創建鏈路完成鏈路的啓動、測試、任選參數的協商和最終鏈路的斷開
LCP的操作只關注連接的兩端，而不在乎Mac層協議（如以太網協議、WIFI），也就是不需要考慮具體的傳輸媒介是什麼。
LCP幀
LCP幀以PPP幀爲基礎。格式如下：
LCP幀有自己特有的四個字段：Code、Ident、Length、LCP Data。
另外，（PPP幀的）字段Protocol的值應爲0xC021，標識該PPP幀爲LCP幀。
+ Code： 表示LCP數據報文（Request或Reply）類型。 值如下：
| Code | Description | Code | Description | |
|---|---|---|---|---|
| 0x01 | configure-request | 0x08 | Protocol-REJECT | |
| 0x02 | configure-ACK | 0x09 | echo-request | |
| 0x03 | configure-NACK | 0x0A | echo-reply | |
| 0x04 | configure-REJECT | 0x0B | discard-request | |
| 0x05 | teminate-request | 0x0C | identification | |
| 0x06 | terminate-ACK | 0x0D | Time-Remaining | |
| 0x07 | code-REJECT |
根據代碼域的不同，LCP 數據包可以分爲以下數據幀：
• 配置請求數據幀(Configure-Request)：代碼域：1
爲了打開一個 LCP 連接，必須發送一個配置請求數據包，欲設置的數據在 LCP 的數據域中設置，接收到該數據包後必須應答。配置選項的內容在下文論述。
• 配置確認數據幀(Configure-ACK)：代碼域：2
• 配置否認數據幀(Configure-NAK）：代碼域：3
如果在接收到的配置數據幀中有參數無法接受，則用該數據幀應答。將無法接受的選項的內容修改爲可以接受的值後按順序添加到數據域中，如果還有其它選項需要協商，也可以增加到數據域中。
• 配置拒絕數據幀(Configure-Reject)：代碼域：4
如果接收到的配置請求數據幀中有部分選項無法識別或不允許使用，則用配置拒絕數據幀應答。此時，複製標誌域並將請求數據幀中的要拒絕的選項按原來的順序複製到數據域中。
• 終止請求數據幀/終止確認數據幀(Terminate-Request/Terminate-ACK）
終止請求數據幀：代碼域爲 5；終止確認數據幀：代碼域爲6如果通信一方要終止鏈路連接，則應該發送終止請求數據幀，代碼域設爲 5，數據域爲任何附加信息；接收到終止請求的一方發送終止確認數據幀，此時代碼域爲 6，標誌域和
數據域從接收到的請求數據幀中拷貝。
• 代碼拒絕數據幀(Code-Reject)：代碼域：7
如果接收到的數據幀的代碼域爲無效代碼，則用代碼拒絕幀應答，表示該錯誤無法恢復。接收到代碼拒絕數據幀的主機應該報告錯誤。
• 協議拒絕數據幀(Protocol-Reject)：代碼域：8
如果在 PPP 封裝中接收到一個未知的通信協議，表示對方想要使用一個本機不支持的協議。此時，如果 LCP 已經處於打開狀態，則必須發送協議拒絕數據幀來通知對方，信息域中包括拒絕的協議和信息；但如果在其它狀態，則直接丟棄數據幀。
LCP 配置選項允許在一個點對點鏈路上通過協商修訂標準特性值，這些選項包括：最大接收單元，異步控制字符映射、鏈路鑑權協議等。如果一個配置選項沒有在配置請求數據包（Configure-Request）中出現，那麼該配置選項將使用默認值。配置選項列表的結束由LCP 數據包的長度標識。在協商過程中，除非特別聲明，這些配置選項應用在半雙工方式，經過協商後的值僅在接收配置請求數據包的方向上有效。配置選項是 LCP 配置請求等數據幀的數據域內的值。配置選項格式如下：
選項類型：1 字節，指示配置選項類別。
選項長度：1 字節，表示該選項的長度，包括類型、長度和數據。
數據：指示該選項的配置內容，它的格式和長度由選項類型決定。
選項類型分別如下：
• 最大接收單元(Maximum-Receive-Unit, MRU）
該選項用來通知對方該實現可以接收的最大數據包長度，如果要將數據包長度設置爲較小值，必須保證在鏈路同步丟失後仍然能夠接收 1500 個字節的數據包。
• 異步控制字符映射(Asynchronous-Control-Character-Map, ACCM)
這個配置選項提供了一個在異步鏈路上協商控制字符映射表的方法。默認的，PPP 將所有的控制字符映射到相應的兩字符序列。然而，很少有必要將所有控制字符都進行轉義映射。因此，應用程序可以通過該選項去通知對方哪些控制字符需要進行轉義。控制字符映射表通過 4 個字節來表示，其中的每一位表示相應的值是否映射，0 表示不進行映射，1 表示進行映射。在傳輸過程中最先傳輸的是第 31 位，最後傳輸的是 0 位。其中，第 0 位對應的是ASCII 碼 NUL。
• 鑑權協議(Authentication-Protocol）
一般在網絡層交換數據前要求進行鑑權，這個配置選項提供了一種協商鑑權協議的方法。默認不進行鑑權。在請求鑑權的過時，每次只能使用一個鑑權協議選項，只有當該協議被拒絕以後，才能再請求使用別的協議進行。
• 質量協議(Quality-Protocol）
在一些連接中，可能需要決定什麼時候、多久進行數據發送，這一過程稱爲質量監控。這個配置選項提供了一種協商使用的質量監控協議的方法。默認不使用質量監控協議。
• 魔數(Magic-Number）
該選項提供了一種探測短路連接和其它數據鏈路層異常的方法，它可能在其它配置選項中用到。使用魔數檢測鏈路的基本思想是：當一方接收到帶有魔數選項的配置請求數據幀後，將接收到的魔數與上次發送的魔數進行比較，如果不相同就認爲沒有發生短路。如果兩個魔數相同，則需要發送一個攜帶不同魔數的配置否認幀，然後將接收到的魔數與發送的魔數進行比較。
• 協議域壓縮(Protocol-Field-Compression)
該選項提供了一種壓縮數據鏈路層協議域的方法。在標準的PPP 中，協議編號爲兩個字節，經過協商後，可以把編號小於 256 的協議壓縮爲一個字節傳輸，比如傳輸 IP 信息時，協議編號可以由 0021 壓縮爲 21，但是編號大於 256 的協議無法壓縮。默認不使用協議壓縮。
選項類型：7 選項長度：2
• 地址和控制域壓縮(Address-and-Control-Field-Compression）
+ Length: LCP報文的長度，以字節爲單位。 Code+Ident+Length+LCP Data
+ LCP Data： LCP數據報文。
不同類型的LCP幀的作用：
| 幀 類型 | 用途 |
|---|---|
| configure 幀 | 對鏈路兩端進行最基本的配置 |
| Terminate幀 | 鏈路通信完成時，對鏈路連接進行清理操作 |
| echo 幀 | 用來確認一些操作， 一個活動的鏈路隨時會發送echo幀 |
| discard-request 幀 | 用於測量鏈路的性能 |
| identification 幀 Time-Remaining幀 | 用於一些管理操作 |
總的來說，LCP幀根據用途可以分爲三大類， 鏈路配置報文，鏈路終止報文，鏈路維護報文：
包含Config-Request、Config-Ack、Config-Nak和Config-Reject四種報文。
當通信雙方需要建立鏈路時，雙方都需要發送Config-Request報文並攜帶自已所希望協商的配置參數選項。當接收方收到Config-Request報文時，會根據是否識別、認可Configure-Request報文中的配置參數來在剩下的三種配置報文中選擇一種應答。 如果識別且認可全部參數，則應答Configure-ACK報文（攜帶全部配置參數）； 如果識別，但只認可部分配置參數，則應答configure-NACK報文（攜帶不認可的配置參數）； 如果不能識別所有的配置，則應答configure-Reject報文（攜帶全部報文）。
(2). 鏈路終止報文：
包含Terminate-Request和Terminate-Reply兩種報文。
LCP報文中提供了一種機制來關閉一個點對點的連接，想要關斷鏈路的一端會持續發送Terminate-Request報文，直到收到一個 Terminate-Reply爲止。接收端一旦收到了一個Terminate-Request報文後，必須迴應一個Terminate-Reply報 文，同時等待對端先將鏈路斷開後，再完成本端的所有斷開的操作。
(3). 鏈路維護報文：
鏈路維護報文中比較雜。比如，我們需要定時進行PPP保活（確認當前PPP鏈路是否仍在活躍狀態），則PPP鏈路雙方分別發送Echo Request報文，如果對方回覆了Echo Reply報文，則表示PPP鏈路仍在活躍狀態。
LCP協商過程
二. 認證階段
+ PAP驗證： 兩次握手，明文傳輸口令，安全性低
+ CHAP驗證： 三次握手， 密文傳輸口令。
在 PPP 連接過程中， LCP 協議定義了一種使用鑑權協議進行鑑權的方法。這種機制可以使用不同的協議進行鑑權，目前支持的鑑權協議包括 PAP(Password Authentication Protocol)和CHAP(Challenge Handshake Authentication Protocol)。
1．密碼鑑權協議(PAP)PAP 提供了一種通過雙向握手進行身份確認的簡單方法。在LCP 鏈路建立後，被鑑權者將身份和密碼發送給鑑權者，然後等待對方的確認信息。因爲用戶的身份和密碼是通過鏈路以明碼的方式發送的，所以 PAP 不是一種絕對安全的鑑權方法。
（1）PAP 數據幀格式
（2）數據幀類型
• 鑑權請求（Authenticate-Request）
鑑權請求用於啓動密碼認證協議，將本地的身份標識和密碼發送給對方，並等待對方應答。該過程可以多次重複直到接收到對方的應答信息。
• 鑑權確認/鑑權否認（Authenticate-ACK/Authenticate-NAK）
如果接收到的鑑權請求數據幀中的用戶標識和密碼都合法，那麼通信終端將使用鑑權確認數據幀進行確認，以通知對方已經通過了身份驗證;如果接收到的信息不合法，則使用鑑權否認數據幀通知對方。在鑑權確認數據幀的數據域中可以包含一些用於顯示的信息。
2．挑戰握手鑑權協議(CHAP)
CHAP 協議使用三方握手來週期性的確定對方的身份，它可以在鏈路建立後的任何時候進行。當鏈路建立後，鑑權者向對方發送一個“挑戰”信息，對方使用單向鏈表（one-way hash）函數計算後發送結果，鑑權者將接收到的信息與自己計算出來的結果進行比較，如果兩者相同，則鑑權成功；否則，鑑權失敗，連接被終止。同 PAP 相比，CHAP 更具有安全性。首先，鑑權過程中使用不斷變化的挑戰信息和身份標識，這使得攻擊者很難有機會進行破解；其次，鑑權由鑑權者控制，它可以隨時對對方進行身份確認。使用 CHAP 時，必須配合一種鏈表算法，目前與 CHAP 配合使用的算法是 MD5 算法。在 PPP 中使用CHAP必須在 LCP 協商時配置相應的鑑權算法爲 CHAP，配置選項格式如下：
（2）CHAP 數據幀類型
• 挑戰和應答數據幀
挑戰數據幀用來啓動 CHAP。鑑權者在 LCP 協商後主動發送挑戰信息來驗證用戶身份。對方在接收到挑戰信息後用單向鏈表算法進行計算，然後將計算後的結果用應答數據幀進行應答。數據幀格式如下：
代碼：挑戰數據幀爲 1；應答數據幀爲 2
標識：一個字節。每次發送挑戰數據幀時必須使用不同的標識碼；應答數據幀必須將挑戰數據幀的標識碼複製後發送。
挑戰值長度：一個字節，指示挑戰值的長度。
挑戰值：一個以上的字節，首先發送高位字節。挑戰值是一個可變的字節流，每次挑戰要使用不同的數值；應答數據幀中該域存放經過計算後的信息流，信息流的長度取決於使用的鏈表算法，比如 MD5 算法計算的結果是 16 字節。
名稱：標識傳輸數據包的系統的名稱，但是該域的值並沒有限制，可以採用不同數值進行發送。
• 成功和失敗數據幀如果接收到的應答信息是正確的，那麼主機使用成功數據
代碼：成功數據幀爲 3；失敗數據幀爲 4
標識：必須從應答數據幀中複製該值。
信息：信息域是可選的而且其內容是由具體的應用來決定的，一般來說，信息域存放的是可以顯示的 ASCII 碼。
下面是一個PAP鑑權過程的命令
c0 23：PAP；AuthReq ：01；id ：01；長度：00 14；用戶名長度：0d；用戶名：77 65 72 74 33 34 35 36 24 25 35 3637；密碼長度：01；密碼71
用戶名爲：wert3456$%567；密碼爲：q;
sent [ PAP AuthReq id=0x1 user="wert3456$%567" password=<hidden>]
ff 03 c0 23 01 01 00 14 0d77 65 72 74 33 34 35 36 24 25 35 36 37 01 71
rcvd [ PAP AuthAck id=0x1 "" ]
ff 03 c0 23 02 01 0005 00
下面是CHAP鑑權的過程，沒有二進制的命令，讀者可試着自行解析爲二進制。
rcvd [CHAP Challenge id=0x1<cefafe87223004753244f465e862a987>, name = "UMTS_CHAP_SRVR"]
sent [CHAP Response id=0x1 <b811aff6568ff284cd4609d3f08cf5a8>, name= "test"]
rcvd [CHAP Success id=0x1""]
CHAP authentication succeeded
三. NCP協商協議
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己協商完，用戶上線成功，可以正常訪問網絡了。
NCP協商協議的基本流程如下：
Session Keep-alive
設備主動發送Echo Request進行PPPoE心跳保活，若3次未得到服務器的響應，則設備主動釋放地址。發LCP Echo Request 的時候，魔術字字段要和之前通信的Configure_Request使用的魔術字字段保持一致。
有些設備或終端不支持主動發送 Echo-Request 報文, 只能支持迴應Echo-Reply報文。