個人認(rèn)為，理解報(bào)文就理解了協(xié)議。通過報(bào)文中的字段可以理解協(xié)議在交互過程中相關(guān)傳遞的信息，更加便于理解協(xié)議。

因此本文將在PPP協(xié)議報(bào)文的基礎(chǔ)上進(jìn)行介紹。

• 關(guān)于PPP協(xié)議基本原理，可參考RFC1661-The Point-to-Point Protocol (PPP)。

• 關(guān)于PPP協(xié)議的IPv4控制協(xié)議，可參考RFC1332-The PPP Internet Protocol Control Protocol (IPCP)。
• 關(guān)于PPP協(xié)議的壓縮控制協(xié)議，可參考RFC1962-The PPP Compression Control Protocol (CCP)。
• 關(guān)于PPP協(xié)議的挑戰(zhàn)握手認(rèn)證協(xié)議，可參考RFC1994-PPP Challenge Handshake Authentication Protocol (CHAP)。
• 關(guān)于PPP協(xié)議的報(bào)頭壓縮協(xié)議，可參考RFC3241-Robust Header Compression (ROHC) over PPP。
• 關(guān)于PPP協(xié)議的IPv6控制協(xié)議，可參考RFC5072-IP Version 6 over PPP。
• 關(guān)于PPP協(xié)議的相關(guān)參數(shù)，可參考IANA的Point-to-Point (PPP) Protocol Field Assignments。
• 關(guān)于PPP協(xié)議的其他資料，可參考博客【網(wǎng)絡(luò)協(xié)議詳解】——PPP協(xié)議（學(xué)習(xí)筆記）。
  …

PPP協(xié)議還存在大量相關(guān)RFC，感興趣者可查閱相關(guān)資料。

PPP（The Point-to-Point Protocol，點(diǎn)到點(diǎn)協(xié)議）提供了一個在點(diǎn)對點(diǎn)鏈路上傳輸多種協(xié)議數(shù)據(jù)包方法的協(xié)議標(biāo)準(zhǔn)。
個人能力有限，這里僅涉及簡易內(nèi)容。敬請各位指導(dǎo)。

目錄

1.基礎(chǔ)介紹

1.1.PPP協(xié)議背景

PPP（The Point-to-Point Protocol，點(diǎn)到點(diǎn)協(xié)議）主要是為在點(diǎn)對點(diǎn)鏈路上傳輸多種協(xié)議數(shù)據(jù)包提供了一個標(biāo)準(zhǔn)方法的協(xié)議。

在上世紀(jì) 80/90 年代，Internet 上支持 TCP/IP 的主機(jī)數(shù)量呈爆炸式增長。這些主機(jī)中的絕大多數(shù)以 Ethernet 為代表連接到局域網(wǎng)（LAN），或以 X.25 協(xié)議等方式連接廣域網(wǎng)（WAN）。 點(diǎn)對點(diǎn)鏈路作為最古老的數(shù)據(jù)通信方法之一，盡管當(dāng)時幾乎每臺主機(jī)都支持點(diǎn)對點(diǎn)連接，卻鮮有以簡單的點(diǎn)對點(diǎn)鏈路連接。

點(diǎn)對點(diǎn) IP 鏈路數(shù)量較少的一個原因是缺乏公認(rèn)的標(biāo)準(zhǔn)封裝協(xié)議。因此 Internet Engineering Task Force (IETF) 工作組于1989年 發(fā)布 RFC1134 定義了 PPP 協(xié)議，以便在 PPP 鏈路上支持傳輸多種協(xié)議類型。PPP 協(xié)議經(jīng)多年的發(fā)展，目前廣為接受的標(biāo)準(zhǔn)為 RFC1661-The Point-to-Point Protocol (PPP)。

RFC1661 中標(biāo)準(zhǔn)化的 PPP 協(xié)議主要定義了三部分內(nèi)容：

1. 如何封裝多種協(xié)議數(shù)據(jù)包，例如 IPv4/IPv6、OSI Network、Novell IPX 等；
2. 如何通過 LCP 協(xié)議（Link Control Protocol，鏈路控制協(xié)議）建立、配置和測試數(shù)據(jù)鏈路層的連通性；
3. 如何通過 NCP 協(xié)議（Network Control Protocols，網(wǎng)絡(luò)控制協(xié)議）建立和配置不同網(wǎng)絡(luò)層的協(xié)議。

PPP協(xié)議的基本工作過程為：

• 首先發(fā)送 LCP 包以便進(jìn)行數(shù)據(jù)鏈路的配置和測試。
• 在數(shù)據(jù)鏈路的 Establish 和可選參數(shù)協(xié)商完成后，發(fā)送 NCP 包進(jìn)行網(wǎng)絡(luò)層協(xié)議的配置和協(xié)商。
• PPP 鏈路持續(xù)交互直到發(fā)送出 LCP/NCP 關(guān)閉鏈路，或者定時器超時等額外事件的發(fā)生。

如果啟用了認(rèn)證等相關(guān)功能，則會在 LCP 階段協(xié)商完成后進(jìn)行認(rèn)證過程的協(xié)商。

1.2.相關(guān)術(shù)語及概念

Encapsulation：PPP Encapsulation 用于在同一個 PPP 鏈路上承載多種網(wǎng)絡(luò)協(xié)議。當(dāng)使用 HDLC-like 封裝時，僅需添加 8 字節(jié)的 PPP Header。而在帶寬比較寶貴的場景下，以 2 或 4 字節(jié)的 PPP Header 封裝數(shù)據(jù)。

//上圖即為承載 IP 協(xié)議時的 PPP 報(bào)文，其 PPP Header 長 4 字節(jié)。

Link Control Protocol：LCP 鏈路控制協(xié)議，是 Link-layer Control Protocols 的一種。LCP 可用于協(xié)商封裝格式選項(xiàng)和包尺寸大小，探測鏈路環(huán)回和參數(shù)錯配，終止鏈路。

LCP 鏈路控制協(xié)議，是 Link-layer Control Protocols 協(xié)議最常用的一種。PPP 協(xié)議可承載的其他 Link-layer Control Protocols 協(xié)議有 PAP (Password Authentication Protocol，密碼認(rèn)證協(xié)議；Protocol Number = 0xc023) 和 CHAP (Challenge Handshake Authentication Protocol，挑戰(zhàn)握手認(rèn)證協(xié)議；Protocol Number = 0xc223) 等。

Network Control Protocols：NCP 網(wǎng)絡(luò)控制協(xié)議，是一系列網(wǎng)絡(luò)層協(xié)議的總稱。PPP 協(xié)議利用 NCP 協(xié)議完成所運(yùn)行網(wǎng)絡(luò)協(xié)議的協(xié)商。常用的 NCP 協(xié)議有 IPCP（IP Control Protocol）、IPv6CP（IPv6 Control Protocol）和 MPLSCP（MPLS Control Protocol）等。

在之前的 PPP 協(xié)議報(bào)文示例中，可以注意到 PPP Header 中存在一個 2 字節(jié)的 Protocol 字段用于表示 PPP 所承載的協(xié)議類型。IETF (Internet Engineering Task Force，國際工程任務(wù)組) 在 RFC1661 中大致將 LCP、NCP 以及 NLP (Network Layer Protocols) 等協(xié)議的 Protocol Numbers 進(jìn)行了如下劃分：
以上幾類協(xié)議可以大致這樣理解：控制協(xié)議用于 PPP 建立交互的協(xié)商協(xié)議，網(wǎng)絡(luò)層協(xié)議用于 PPP 實(shí)際承載業(yè)務(wù)報(bào)文。
例如，當(dāng) PPP 的 Protocol Number 為 0x8021 時表示 IPCP 可用于協(xié)商 IPv4 網(wǎng)絡(luò)的相關(guān)參數(shù)；當(dāng)為 0x0021 時表示 IPv4 可用于承載具體的 IP 協(xié)議報(bào)文，例如 ICMP 和 TCP 等。相似的有 0x8281 時表示 MPLSCP 用于協(xié)商 MPLS 網(wǎng)絡(luò)的相關(guān)參數(shù)；0x0281 時表示承載具體 MPLS 單播業(yè)務(wù)報(bào)文。
自動換行//也即有上述圖示的邏輯結(jié)果。

PPPoE：Point-to-Point Protocol over Ethernet，PPP協(xié)議封裝于以太網(wǎng)上的協(xié)議。PPPoE協(xié)議定義于 RFC2516-A Method for Transmitting PPP Over Ethernet (PPPoE)。其基本格式為在 PPP 協(xié)議基礎(chǔ)上封裝 PPPoE Header 后作為 Ethernet 幀 Payload 的形式存在。

此處不在對 PPPoE協(xié)議做更多介紹，感興趣者可查閱相關(guān)資料。

2.PPP協(xié)議原理

//根據(jù)前文描述，PPP 協(xié)議的基本工作過程如上圖所示。這里依次進(jìn)行相應(yīng)原理介紹。

點(diǎn)擊此處回到目錄文章來源地址http://www.zghlxwxcb.cn/news/detail-823180.html

2.1.PPP協(xié)議幀格式

2.1.1.LCP幀格式

RFC1661 中定義的 LCP 包格式

通用的 LCP 包格式：Code：代碼，1字節(jié)。用于標(biāo)識 LCP 包類型。當(dāng)收到未知類型的 LCP 包時，應(yīng)當(dāng)回應(yīng) Code = 7 的 Code-Reject 幀。

目前 RFC 標(biāo)準(zhǔn)化了14種 LCP 包：//其中 8-13 是 LCP 協(xié)議獨(dú)有的 code 類型。這里暗含的意思是 LCP 協(xié)議和 IPCP 協(xié)議具有相同的幀格式，共用部分 code 碼。

Identifier：身份標(biāo)識，1字節(jié)。主要用于匹配 Request 類型和 Reply 類型的消息。

由于 PPP 鏈路建鏈協(xié)商時不攜帶 MAC 或 Router-id 等用于標(biāo)識的鏈路節(jié)點(diǎn)的信息，需要通過該字段進(jìn)行相互識別。
每當(dāng)設(shè)備啟動發(fā)送 LCP 報(bào)文時從 0x00 開始計(jì)數(shù)，每發(fā)送一次 LCP 包 Identifier 序號加一直至 0xff。隨后從 0x00 開始下一輪循環(huán)。
通常僅允許 Request 類型包在重傳時不改變 Identifier 序號。Reply 類型包應(yīng)當(dāng)與 Request 類型的 Identifier 序號一致。

Length：長度，2字節(jié)。標(biāo)識整個 LCP 包的長度，并且標(biāo)識長度不應(yīng)超過鏈路的 MRU (Maximum-Receive-Unit，最大接受單元)。對于超過 Length 標(biāo)識的部分應(yīng)當(dāng)在接受時忽略。如果接收到不可用的 Length 字段，應(yīng)當(dāng)靜默丟棄。
Data：數(shù)據(jù)，長度取決于 Length 標(biāo)識值。 Data 字段的內(nèi)容還受到具體 LCP 包的影響。

//上圖為一個典型的 LCP 包圖示，后文將針對交互過程對其進(jìn)行介紹。

1@=Configure LCP 包格式：RFC1661
Configure LCP 包的 Code：共有4種類型。主要用于鏈路節(jié)點(diǎn)協(xié)商連接請求。

1. Code = 1 表示 Configure-Request LCP 包。每當(dāng)期望建立某種連接時，攜帶相應(yīng)的 LCP Option 發(fā)起 Code = 1 的Configure-Request LCP 包開啟交互請求。
2. Code = 2 表示 Configure-Ack LCP 包。當(dāng)收到的 Configure-Request LCP 包每個 Option 可識別且接受時必須回應(yīng) Configure-Ack LCP 包，并且攜帶未經(jīng)重新排序和修改的 Option。
3. Code = 3 表示 Configure-Nak LCP 包。當(dāng)收到的 Configure-Request LCP 包每個 Option 可識別但部分 Option 的值不可接受時必須回應(yīng) Configure-Nak LCP 包，并且攜帶未經(jīng)重新排序的不可接受 Option。

除此之外還要求：
1@：沒有 Value 字段的選項(xiàng) Option 必須改用 Code = 4 的 Configure-Reject LCP 包回復(fù)。
2@：每個只允許出現(xiàn)一次的 Option 必須修改為 Configure-Nak 發(fā)送方可接受的值。當(dāng)默認(rèn)值與請求的值不同時，可以使用默認(rèn)值。
3@：當(dāng)特定類型的 Option 出現(xiàn)多次并具有不同的值時，Configure-Nak 必須同樣出現(xiàn)多次并包含該 Option 的所有值，這些值是 Configure-Nak 發(fā)送方可接受的。 這包括 Configure-Request 中存在的可接受值。
4@：當(dāng)需要某種協(xié)商需求而 Configure-Request LCP 包未列出該 Option ，則可以將該 Option 附加到 Configure-Nak 的 Option 中，以提示對等方將該 Option 包含在其下一個 Configure-Request LCP 包中。 Option 的 Value 應(yīng)當(dāng)是 Configure-Nak 發(fā)送方可接受的值。在接收 Configure-Nak 包時，Identifier 字段必須與上次傳輸?shù)?Configure-Request LCP 包匹配。 無效數(shù)據(jù)包將被靜默丟棄。
對端收到有效的 Configure-Nak LCP 包而在發(fā)送新的 Configure-Request LCP 包時，可以按照 Configure-Nak 包中的指示修改 Option。當(dāng)存在 Option 的多個實(shí)例時，對等方應(yīng)選擇一個值以包含在其下一個 Configure-Request 包數(shù)據(jù)包中。某些 Option 具有可變長度。由于 Nak’d Option 已被 Configure-Nak 包發(fā)送方修改，因此重新發(fā)送 Configure-Request LCP 包的一方必須具有能夠處理與原始 Configure-Request 不同的 Option 長度的能力。

4. Code = 4 表示 Configure-Reject LCP 包。當(dāng)收到的 Configure-Request LCP 包中某些 Option 無法識別或無法協(xié)商（由網(wǎng)絡(luò)管理員配置），則實(shí)現(xiàn)必須回應(yīng)Configure-Reject LCP 包。 Option 字段僅填充 Configure-Request LCP 包中不可接受的 Option，并且不得以任何方式重新排序或修改配置選項(xiàng)。收到 Configure-Reject LCP 包的一方在發(fā)送新的 Configure-Request LCP 包時，它不得包含 Configure-Reject 包中列出的任何 Option。

Configure-Nak LCP 包和 Configure-Reject LCP 包區(qū)別在于：Configure-Nak LCP 包表示雙方可以重新協(xié)商需求值，而 Configure-Reject LCP 包表示雙方明確不可針對某一需求進(jìn)行交互。

這一過程往往發(fā)生在 LCP 已經(jīng)完成了鏈路發(fā)現(xiàn)，需要進(jìn)一步進(jìn)行 NCP 交互時事先確認(rèn)的某些信息或者管理者更改了網(wǎng)絡(luò)層信息。

//例如此處攜帶的即為認(rèn)證 Option，LCP Option 攜帶 CHAP 協(xié)議進(jìn)行認(rèn)證。

2@=Terminate LCP 包格式：RFC1661
Terminate LCP 包的 Code：共有2種類型。Terminate LCP 包主要用于關(guān)閉連接。

1. Code = 5 表示 Terminate-Request LCP 包。當(dāng)鏈路節(jié)點(diǎn)希望關(guān)閉連接時，應(yīng)當(dāng)持續(xù)發(fā)送 Terminate-Request LCP 包直到收到 Terminate-Ack LCP 包。而未經(jīng) Request 而收到 Terminate-Ack LCP 包時，通常也意味著對等體處于 Closed/Stopped 狀態(tài)，或者需要重新協(xié)商。
2. Code = 6 表示 Terminate-Ack LCP 包。當(dāng)收到 Terminate-Request LCP 包時，必須發(fā)送 Terminate-Ack LCP 包。

3@=Code-Reject LCP 包格式：RFC1661
Code-Reject LCP 包的 Code：共有1種類型。Code-Reject LCP 包主要用于響應(yīng)未知 Code 的 LCP 包。

1. Code = 7 表示 Code-Reject LCP 包。當(dāng)鏈路節(jié)點(diǎn)處于 Open 狀態(tài)收到對等體發(fā)送來的未知類型的 LCP 包時，應(yīng)當(dāng)發(fā)送 Code-Reject LCP 包。Code-Reject 數(shù)據(jù)包只能在 LCP Opened 狀態(tài)下發(fā)送。Reject-Packet 字段應(yīng)當(dāng)不包含數(shù)據(jù)鏈路層頭部或 FCS，并可因 MRU 限制而截?cái)唷?br> 在 LCP 打開狀態(tài)以外的任何狀態(tài)下接收的協(xié)議拒絕數(shù)據(jù)包都應(yīng)以靜默方式丟棄。在收到 Code-Reject 后，對等體必須盡早停止發(fā)送該未知類型的 LCP 包。

4@=Protocol-Reject LCP 包格式：RFC1661

Protocol-Reject LCP 包的 Code：共有1種類型。Protocol-Reject LCP 包主要用于響應(yīng)未知或未使能的 Protocol 的 LCP 包。

1. Code = 8 表示 Protocol-Reject LCP 包。當(dāng)鏈路節(jié)點(diǎn)處于 Open 狀態(tài)收到對等體發(fā)送來的未知類型的 LCP 包時，應(yīng)當(dāng)發(fā)送 Protocol-Reject LCP 包。Protocol-Reject 數(shù)據(jù)包只能在 LCP Opened 狀態(tài)下發(fā)送。在 LCP 打開狀態(tài)以外的任何狀態(tài)下接收的協(xié)議拒絕數(shù)據(jù)包都應(yīng)以靜默方式丟棄。Reject-Information 字段應(yīng)當(dāng)不包含數(shù)據(jù)鏈路層頭部或 FCS，并可因 MRU 限制而截?cái)唷?br> 在 LCP 打開狀態(tài)以外的任何狀態(tài)下接收的協(xié)議拒絕數(shù)據(jù)包都應(yīng)以靜默方式丟棄。在收到 Protocol-Reject 后，對等體必須盡早停止發(fā)送該未知類型的 LCP 包。

//這是由于未使能 MPLS 而導(dǎo)致對 MPLSCP 協(xié)議回應(yīng)的 LCP Protocol Reject 包。

5@=Echo LCP 包格式：RFC1661
Echo LCP 包的 Code：共有2種類型。Echo LCP 包主要用于調(diào)試、鏈路質(zhì)量確定、性能測試等其他方面。

1. Code = 9 表示 Echo-Request LCP 包。
2. Code = 10 表示 Echo-Reply LCP 包。

1@：Echo-Request 和 Echo-Reply LCP 包只能在 LCP Opened 狀態(tài)下發(fā)送。
2@：在收到 Echo-Request 時，必須發(fā)送 Echo-Reply。在 LCP Opened 狀態(tài)以外的任何狀態(tài)下收到的 Echo-Request 和 Echo-Reply 數(shù)據(jù)包都應(yīng)以靜默方式丟棄。
3@：Magic-Number 的使用與 Magic-Number Option相關(guān)。在成功協(xié)商 Magic-Number Option 之前，必須以零形式傳輸。
3@：Data 字段是可為0的任意值，并受 Length 字段的控制。
//這里的 Data 為 0 的 Echo LCP 包示例。

6@=Discard-Request LCP 包格式：RFC1661
Discard-Request LCP 包的 Code：共有1種類型。Discard-Request LCP 包主要用于提供數(shù)據(jù)鏈路層接收器機(jī)制，用于執(zhí)行鏈路的本地到遠(yuǎn)程方向。

1. Code = 11 表示 Echo-Request LCP 包。Discard-Request 數(shù)據(jù)包只能在 LCP Opened 狀態(tài)下發(fā)送。在接收時，接收方必須靜默地丟棄它收到的任何丟棄請求。

7@=Identification LCP 包格式：RFC1570
Identification LCP 包的 Code：共有1種類型。Discard-Request LCP 包提供了一種用于向?qū)Φ润w標(biāo)識自己的方法?？捎糜阪溄庸收吓懦?、執(zhí)行許可證等。

1. Code = 12 表示 Identification LCP 包。Identification LCP 包可以隨時發(fā)送，包括在 LCP 達(dá)到 Open 狀態(tài)之前。收到標(biāo)識數(shù)據(jù)包會導(dǎo)致 RXR 或 RUC 事件。Identification LCP 包生成情況既罕見又單向，建議在發(fā)送或接收 Configure-Reject 時發(fā)送?；蛘?，在協(xié)商無法收斂時以及 LCP 達(dá)到 Opened 狀態(tài)時作為最終消息發(fā)送。
   Message 字段往往包含：硬件類型、PPP 軟件修訂版本、PPP 產(chǎn)品序列號、鏈路速率MIB、接口名MIB、等在 debugging 交互時的有用信息。

8@=Time-Remaining LCP 包格式：RFC1570
Time-Remaining LCP 包的 Code：共有1種類型。Discard-Request LCP 包用于通知對等體此會話的剩余時間。

1. Code = 13 表示 Time-Remaining LCP 包。Time-Remaining LCP 包是一個鏈路維護(hù)數(shù)據(jù)包。 剩余時間數(shù)據(jù)包只能在 LCP Open 狀態(tài)下發(fā)送。收到剩余時間數(shù)據(jù)包會導(dǎo)致 RXR 或 RUC 事件，并無需對 Time-Remaining LCP 包進(jìn)行響應(yīng)。

點(diǎn)擊此處回到目錄

2.1.2.LCP Configuration Options

IANA目前定義了約30種 LCP Configuration Options，這里僅介紹常用的幾種 Options。其他 Options 感興趣者可查閱相關(guān)資料。

1@：LCP Configuration Options 主要用于提供鏈路節(jié)點(diǎn)雙方一種協(xié)商默認(rèn)參數(shù)的方法。
2@：某些 Options 可能出現(xiàn)不僅一次。
3@：Option 通常出現(xiàn)在 Code = 1 的 Configure-Request LCP 包中。

通用的 LCP Configuration Options 格式：
Type 字段用于標(biāo)識 Option 類型，Length 字段用于描述整個 Option 的長度，Data 字段則為 0 至 Length-2 的值。

Type 1 = Maximum-Receive-Unit Options：RFC1661
Maximum-Receive-Unit Option 用于標(biāo)識自己所能接受的最大字節(jié)數(shù)，默認(rèn)取值 1500。但是鏈路節(jié)點(diǎn)應(yīng)當(dāng)至少支持接受 1500 字節(jié)的能力。

//配置 PPP 鏈路的MRU協(xié)商功能。默認(rèn)使能，取值取決于鏈路上 MTU 的設(shè)置。

Type 3 = Authentication-Protocol Options：RFC1661/RFC1994
Authentication-Protocol Option 用于指示在進(jìn)行 NCP 交互前的認(rèn)證信息確認(rèn)。但是一個 Configure-Request LCP 包中不能出現(xiàn)多個 Authentication-Protocol Option ，只能在接受 Configure NAK 之后發(fā)起下次 Configure-Request。

//這里展示的即為協(xié)商 CHAP 的 Authentication-Protocol Options。其中定義的 Algorithm認(rèn)證算法 = 5 表示 CHAP with MD5。其他認(rèn)證算法可查閱相關(guān)資料。
自動換行
還有一個需要注意的是：RFC1661 認(rèn)為 PPP 的認(rèn)證并非一個全雙工過程。也即，允許單方向發(fā)起認(rèn)證請求而認(rèn)證方僅進(jìn)行認(rèn)證確認(rèn)即可。
被認(rèn)證方需配置：
//ppp pap local-user 用于攜帶認(rèn)證的用戶名和密碼向?qū)Χ苏埱筮M(jìn)行認(rèn)證。當(dāng)然也可選擇 CHAP 認(rèn)證的方式。
認(rèn)證確認(rèn)方需配置：
//ppp authentication-mode 用于設(shè)置認(rèn)證模式。
//local-user 用于設(shè)置進(jìn)行 PPP 認(rèn)證所需的用戶名和密碼。

Type 4 = Quality-Protocol Options：RFC1661
Quality-Protocol Option 用于使用特定協(xié)議進(jìn)行鏈路質(zhì)量監(jiān)控。默認(rèn)情況下，鏈路質(zhì)量監(jiān)控處于禁用狀態(tài)。

Type 5 = Magic-Number Options：RFC1661
Magic-Number 用于檢測環(huán)回鏈路和其他數(shù)據(jù)鏈路層異常。默認(rèn)情況下，不會協(xié)商 Magic-Number，而是在可能使用幻數(shù)的地方插入零。Magic-Number 的產(chǎn)生通常是使用隨機(jī)的方式生成。當(dāng)收到帶有 Magic-Number Option 的 Configure-Request LCP 包時，收到的 Magic-Number 將與最后一個發(fā)送給對等體的 Configure-Request LCP 包中 Magic-Number 進(jìn)行比較：
如果兩個 Magic-Number 不同，則鏈接不會環(huán)回，并且應(yīng)確認(rèn)幻數(shù)。
如果兩個 Magic-Number 相等，則鏈路可能（但不確定）是環(huán)回的。要確定這一點(diǎn)，必須發(fā)送指定不同 Magic-Number 的 Configure-Nak LCP 包，直到收到 Configure-Nak 或重新啟動計(jì)時器用完之前，不應(yīng)將新的 Configure-Request LCP 包發(fā)送到對等體。當(dāng)然后續(xù)收到的 LCP 包中的 Magic-Number 仍然有可能相等，盡管這種概率非常小。因此RFC1661建議應(yīng)當(dāng)盡可能的設(shè)置多的 Magic-Number 來源，或者不啟用這一功能。

//此處攜帶一個隨機(jī)產(chǎn)生的 Magic-Number Option 用于檢測鏈路是否環(huán)路。
//一旦協(xié)商完成后，在周期性發(fā)送的 Echo Request 和 Echo Reply LCP 包中一直攜帶該字段直到重新協(xié)商。似乎，某種程度上可用于鏈路節(jié)點(diǎn)的標(biāo)識。

Type 6 = Protocol-Field-Compression Options：RFC1661
Protocol-Field-Compression 用于協(xié)商對2字節(jié) PPP Protocol 字段的壓縮。

Type 7 = Address-and-Control-Field-Compression：RFC1661
Address-and-Control-Field-Compression 用于協(xié)商對 Data Link Layer Address and Control 字段的壓縮。

2.1.3.IPCP幀格式及其Option-RFC1332

IPCP協(xié)議，也即 IP Control Protocol 協(xié)議作為 NCP 協(xié)議的一部分，主要用于在 PPP 鏈路上配置、使能和去使能 IPv4 協(xié)議模塊。關(guān)于 IPv6 網(wǎng)絡(luò)下的 IPv6CP 協(xié)議可參考RFC5072-IP Version 6 over PPP

IPCP協(xié)議有如下幾個特點(diǎn)：
1@：IPCP 協(xié)議交互基本原理與 LCP 協(xié)議基本相同。并在 PPP 鏈路協(xié)議狀態(tài)達(dá)到 Network-Layer Protocol 階段開始交互，在此之前接受到的 IPCP 包應(yīng)當(dāng)靜默丟棄。
2@：IPCP 協(xié)議與 LCP 協(xié)議不同之處在于 Data Link Layer 的 Protocol 字段取值為 0x8021。
3@：IPCP 協(xié)議與 LCP 協(xié)議不同之處在于 Code 字段只能使用 LCP 協(xié)議的 1-7 種類型。其他類型的 Code 字段應(yīng)當(dāng)被視為未知 Code，并且應(yīng)當(dāng)回應(yīng) Code-Rejects 包。
4@：IPCP 協(xié)議與 LCP 協(xié)議不同之處在于 IPCP 協(xié)議僅在 PPP 鏈路協(xié)議狀態(tài)達(dá)到 Network-Layer Protocol 階段開始交互。在等待 Configure-Ack 或其他響應(yīng)超時之前，應(yīng)準(zhǔn)備好等待身份驗(yàn)證和鏈路質(zhì)量確定完成。
5@：IPCP 協(xié)議與 LCP 協(xié)議不同之處在于 IPCP 協(xié)議具有不同的 Configuration Option Types。

IPCP協(xié)議幀格式示例：
這里展示了初始狀態(tài)下攜帶的三種 IPCP Configuration Option Types：
1@：Type3 = IP address，定義于RFC1332。用于協(xié)商 PPP 鏈路節(jié)點(diǎn)的 IP address。這一描述主要包含了兩種行為：首先可用于鏈路節(jié)點(diǎn)間 IP 地址的沖突檢測，此外還可用于向節(jié)點(diǎn)對等體請求為自己分配一個地址。

這里 IP address 填充 0.0.0.0 即表示用于向?qū)Χ苏埱鬄樽约悍峙湟粋€地址。此時鏈路對等體返回 Configure-Nak IPCP 包并填充分配的地址，隨后鏈路節(jié)點(diǎn)以該值繼續(xù)發(fā)起 IPCP 包再次進(jìn)行請求。通過這種拒絕再次請求的方式完成 IP 地址的分配工作。詳細(xì)的交互過程將在第三章進(jìn)行相應(yīng)介紹。

2@：Type129 = Primary DNS Server Address，定義于RFC1877。用于協(xié)商 PPP 鏈路節(jié)點(diǎn)的 Primary DNS Server Address。
3@：Type131 = Secondary DNS Server Address，定義于RFC1877。用于協(xié)商 PPP 鏈路節(jié)點(diǎn)的 Secondary DNS Server Address。

與 Type3 = IP address Option 類似，Type129 = Primary DNS Server Address 和 Type131 = Secondary DNS Server Address 具有類型的兩種行為。也即協(xié)商 DNS，或向?qū)Χ苏埱?DNS。并在請求 DNS 時將相應(yīng)字段置位 0.0.0.0。

除此之外，IANA 還定義了其他幾種 IPCP Configuration Option：
Type129 = Primary NBNS Server Address 和 Type131 = Secondary NBNS Server Address 定義于 RFC1877 中，主要用于協(xié)商 NetBIOS Name Server 地址。NetBIOS 協(xié)議主要為程序提供了請求低級服務(wù)的統(tǒng)一的命令集 (或者提供應(yīng)用程序編程接口（API）)，作用是為了給局域網(wǎng)提供網(wǎng)絡(luò)以及其他特殊功能
Type2 = IP-Compression-Protocol 定義于 RFC1332 中，主要用于協(xié)商如何壓縮 TCP/IP 頭部以便在低帶寬條件下提升載荷效率。//其通用格式如上圖所示。目前所常用的 IP-Compression-Protocol 有：
Van Jacobson Compressed TCP/IP (Value = 0x002d，RFC1332)：
//ip tcp vjcompress 命令用來配置PPP鏈路接口的VJHC壓縮功能。通過VJHC壓縮后，TCP/IP頭長度可以從40字節(jié)降至3～5字節(jié)，在PPP鏈路上可以明顯提高報(bào)文的傳輸速度。
Robust Header Compression (ROHC) (Value = 0x0003，RFC3241)、
IP Header Compression (Value = 0x0061，RFC2507和RFC3544)//ppp compression iphc 用來配置PPP鏈路接口上IPHC功能。
VJHC和IPHC的區(qū)別是：VJHC僅僅對TCP/IP報(bào)文頭進(jìn)行壓縮；IPHC可以對TCP/IP報(bào)文頭或RTP/UDP/IP報(bào)文頭進(jìn)行壓縮。其他 IP-Compression-Protocol 及 IPv6-Compression-Protocol 不在進(jìn)行相關(guān)介紹，感興趣者可查閱相關(guān)資料。

點(diǎn)擊此處回到目錄

2.2.PPP協(xié)議基本原理

2.2.1.PPP相圖/Phase Diagram

在RFC1661 中定義了 PPP 鏈路的配置、維護(hù)和終止階段，主要可分為上圖所示的幾個相。

Link Dead：PPP 鏈路的開始和結(jié)束階段。在此階段 LCP 狀態(tài)機(jī)處于 Initial/Starting 初始/啟動中狀態(tài)。

當(dāng)有額外的 Event 事件發(fā)生時 (例如，載波監(jiān)聽或網(wǎng)絡(luò)管理配置)，預(yù)示著物理層可用并準(zhǔn)備進(jìn)入 Establishment 階段。

Link Establishment：在此階段，LCP 通過交互配置消息來建立連接。一旦發(fā)送和接收了 LCP Configure-Ack 包，交互即宣告完成并進(jìn)入 LCP 的 Open 狀態(tài)。

在此階段接收的任何非 LCP 數(shù)據(jù)包都必須以靜默方式丟棄。收到 LCP 配置請求會導(dǎo)致從 Network 階段或 Authentication 階段返回到 Link Establishment 階段。

Authentication：默認(rèn)情況下，身份驗(yàn)證不是強(qiáng)制性的。如果需要認(rèn)證，則建立鏈接后，應(yīng)盡快進(jìn)行身份驗(yàn)證。

在身份驗(yàn)證完成之前，不得從身份驗(yàn)證階段推進(jìn)到 Network-Layer 協(xié)議階段。 如果身份驗(yàn)證失敗，身份驗(yàn)證器應(yīng)改為進(jìn)入 Link Termination 階段。在此階段，只允許使用 LCP、認(rèn)證協(xié)議和鏈路質(zhì)量監(jiān)控。收到的所有其他數(shù)據(jù)包必須靜默丟棄。

Network-Layer：PPP 完成上述階段后，必須由相應(yīng)的 NCP 單獨(dú)配置每個網(wǎng)絡(luò)層協(xié)議。

當(dāng)相應(yīng)的 NCP 未處于 Open 狀態(tài)時，必須以靜默方式丟棄任何受支持的網(wǎng)絡(luò)層協(xié)議數(shù)據(jù)包。當(dāng) LCP 處于 Opened 狀態(tài)時，實(shí)現(xiàn)不支持的任何協(xié)議數(shù)據(jù)包都必須返回 Protocol- Reject 包。只有受支持的協(xié)議才會被靜默丟棄。

Link Termination：LCP 用于通過交換 Terminate 數(shù)據(jù)包來關(guān)閉鏈路。

Terminate-Request 的發(fā)送方應(yīng)在收到 Terminate-Ack 后或 Restart 定時器過期后斷開連接。Terminate-Request 的接收方應(yīng)在發(fā)送 Terminate-Ack 后至少經(jīng)過一個重啟時間之前不得斷開連接。

2.2.2.PPP狀態(tài)機(jī)

PPP 協(xié)議有限狀態(tài)機(jī)由 Event事件、Action動作 和 state transitions狀態(tài)切換 共三部分組成。

Event事件 通常是指發(fā)生了某一現(xiàn)象或某一行為；Action動作 是指針對 Event事件 所作出的響應(yīng)；state transitions狀態(tài)切換 是指將PPP鏈路狀態(tài)發(fā)生某種轉(zhuǎn)變。
這里僅針對部分內(nèi)容進(jìn)行說明，詳細(xì)內(nèi)容可查看相關(guān)資料。

RFC1661 定義了如上圖所示的 Event事件 和對應(yīng)的 Action動作：

Event = TO+：Timeout with counter > 0。
Event = TO-：Timeout with counter expired。

RFC1661 定義了一個名為 Restart Timer 的定時器，默認(rèn)取值 3s。當(dāng)鏈路節(jié)點(diǎn)發(fā)出 LCP Configure-Request/Terminate-Request 等請求類型的 LCP 包，啟動該定時器。如果定時器結(jié)束而未收到響應(yīng)，則觸發(fā) Restart TimerTime Out Event。同時該值的設(shè)置也應(yīng)當(dāng)考慮鏈路延時及設(shè)備處理所耗費(fèi)時間的額外設(shè)置。
//ppp timer negotiate 用來配置PPP協(xié)商超時時間間隔，默認(rèn)取值 3s。
自動換行
RFC1661 定義了一個名為 Max-Configure 的計(jì)數(shù)器，默認(rèn)取值 10。該計(jì)數(shù)器用于指示在發(fā)出 LCP Configure-Request 包后未收到對方響應(yīng)的最大次數(shù)。
也即，發(fā)出 10 次 LCP Configure-Request 包而未收到響應(yīng)將觸發(fā) Event = TO-。1 - 9 次則觸發(fā) Event = TO+。

RCR+：Receive-Configure-Request (Good)。
RCR-：Receive-Configure-Request (Bad)。

RCR Event 用于分別表示鏈路節(jié)點(diǎn)收到 Configure-Request LCP 包動作。隨后針對該事件回應(yīng) Configure-Ack/Configure-Nak/Configure-Reject LCP 包。

RTR：Receive-Terminate-Request。
RTA：Receive-Terminate-Ack。

RTR/RTA Event 通常發(fā)生于因某些狀況導(dǎo)致需要中斷 PPP 連接的情況。在該情況下，RFC1661 還定義了名為 Max-Terminate 的計(jì)數(shù)器，默認(rèn)取值 2。用于表示發(fā)出 Terminate-Request 而未收到 Terminate-Ack 的最大次數(shù)。

RXR：Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request。

當(dāng)收到 Echo-Request, Echo-Reply, Discard-Request LCP 包時觸發(fā)該事件。對 Echo-Request 回應(yīng) Echo-Reply。其他情況無回應(yīng)。
//ppp keepalive retry-times 用來配置PPP心跳報(bào)文的重傳次數(shù)。當(dāng)鏈路質(zhì)量差，發(fā)送的心跳報(bào)文達(dá)到重傳次數(shù)時，設(shè)備會斷開PPP連接。

同時，RFC1661 還定義了如上圖所示的 10 種 state 狀態(tài)：
水平指示 State，垂直指示 Event，State Transitions 以 action/new-state 形式表示。
多個操作用逗號分隔，并可根據(jù)空間需要在后續(xù)行上繼續(xù)執(zhí)行。可以以任何方便的順序?qū)崿F(xiàn)多個操作。
狀態(tài)后面的字母，表示一個解釋性腳注。
短劃線 （‘-’） 表示非法轉(zhuǎn)換。

[P] 表示 Passive option，[r] 表示 Restart option，[x] 表示 Crossed connection。

State = Closed：鏈接可用，但 Open 未發(fā)生。 執(zhí)行 irc = Initialize-Restart-Count 和 scr = Send-Configure-Request 可過渡到 State = Req-Sent。
State = Stopped：當(dāng)自動機(jī)在 This-Layer-Finished 操作之后或發(fā)送 Terminate-Ack 后等待 Down 事件時進(jìn)入。
State = Request-Sent：此狀態(tài)，鏈路節(jié)點(diǎn)試圖配置聯(lián)系。
State = Opened：Configure-Ack LCP 包已經(jīng)完成收發(fā)。Restart 定時器不在運(yùn)行。處于此階段需要向上層協(xié)議通告 UP。

點(diǎn)擊此處回到目錄

3.PPP協(xié)議常用配置及報(bào)文交互實(shí)例

//根據(jù)前文描述，PPP 協(xié)議的基本工作過程如上圖所示。這里依次進(jìn)行相應(yīng)介紹。

3.1.PPP協(xié)議常用場景及配置

這里以下圖為例進(jìn)行PPP協(xié)議交互場景的配置介紹及其對應(yīng)的報(bào)文分析。
在上圖場景中：AR1 做 AR2 的PPP認(rèn)證方，并為 AR2 分配 IP 和 DNS 地址。

AR1：
aaa 
 local-user test password cipher test
 local-user test service-type ppp
#
interface Pos4/0/0
 link-protocol ppp
 ppp authentication-mode pap 
 remote address 10.1.1.2 
 ppp ipcp dns 20.1.1.1 20.1.1.2
 ip address 10.1.1.1 255.255.255.0 
#


AR2：
interface Pos4/0/0
 link-protocol ppp
 ppp pap local-user test password simple test
 ppp ipcp dns request
 ip address ppp-negotiate
#

3.2.PPP報(bào)文交互過程

報(bào)文交互以 LCP – PAP – NCP 的順序先后進(jìn)行。
其報(bào)文總體交互過程如上圖所示，此處以上圖報(bào)文順序先后進(jìn)行介紹。
No.1為廢棄報(bào)文此處不做介紹。

No.2 和 No.3：
這是第一次 PPP 鏈路節(jié)點(diǎn)雙方進(jìn)行的第一次配置確認(rèn)。在該階段相互確認(rèn)鏈路層所需信息。

//由于 AR2 配置了認(rèn)證，所以可觀察到其發(fā)出的 Authentication Option。

No.6 和 No.7：
在節(jié)點(diǎn)雙方都進(jìn)行了一次 Configure 確認(rèn)后進(jìn)入認(rèn)證階段。

//PAP 認(rèn)證以明文方式進(jìn)行信息交互。相關(guān) Option 可查看前文介紹。

No.8 至 No.13：
該階段也即 NCP 階段進(jìn)行 IP 協(xié)議的協(xié)商。

//由于一方請求了IP及DNS，所以相應(yīng)字段至0。并會被 AR1 拒絕并攜帶正確的值。AR2 收到后，再次攜帶正確 Option 向 AR1 發(fā)起請求。至此雙方都完成 IP 層協(xié)商。
這里還需要注意的一個點(diǎn)是：PPP 鏈路不進(jìn)行類似 Ethernet 協(xié)議的子網(wǎng)驗(yàn)證，因此實(shí)際上可以出現(xiàn)對端 IP 跨網(wǎng)段的現(xiàn)象。并默認(rèn)將 PPP 鏈路對等體的 32 位主機(jī)路由加入本地路由表。

No.14 至 No.17：
此后完成 LCP 和 NCP 階段的協(xié)商，周期性每 10s 進(jìn)行一次PPP交互確認(rèn)。

//這里開始交互 Echo 消息，并攜帶相應(yīng)的 Magic Number。
相關(guān)內(nèi)容可查看前文介紹。

Terminate LCP 報(bào)文交互類型與上述交互過程類似，此處不在進(jìn)行相關(guān)介紹。
MPLSCP 協(xié)議作為 NCP 協(xié)議的一種與上述交互過程類似，此處不在進(jìn)行相關(guān)介紹。

更新

點(diǎn)擊此處回到目錄

到了這里，關(guān)于PPP協(xié)議原理介紹+報(bào)文分析+配置指導(dǎo)-RFC1661的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！