RFC1661中文 ppp協議

組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[email protected]
譯者：龍天泳（longty2000 ）
譯文發佈時間：2001-4-10
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用於非商業用途自由轉載，但必須保留本文檔的翻譯及版權信息。

Network Working Group W. Simpson, Editor
Request for Comments: 1661 Daydreamer
STD: 51 July 1994
Obsoletes: 1548
Category: Standards Track

RFC1661 PPP協議
（RFC1661 The Point-to-Point Protocol (PPP)）

本備忘錄狀態
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.

摘要
PPP爲基於點對點連接的多協議自尋址數據包的傳輸提供了一個標準方法。PPP包含以下三個成分：
　　1．壓縮多協議自尋址數據包的方法。
　　2．用於建立、設定和測試數據鏈路連接的LCP。
　　3．一族用於建立、設定不同網絡層協議的NCP。
　　本文檔定義了PPP的組織和方法，以及PPP封裝，與之一起定義的還有：擴展選項協商機制，他使得（人們）可以就豐富的設定參數進行磋商，同時還提供額外的管理功能。PPP鏈路控制協議（LCP）九是用這種機制描述的。

目錄
1 介紹   3
1-1 要求說明書   4
1-2 術語   4
2 PPP封裝   5
3 PPP鏈路操作   6
3-1 概述   6
3-2 階段劃分框圖   6
3-3 鏈路死亡（物理連接不存在）   6
3-4 鏈路建立階段   7
3-5 認證階段   7
3-6 網絡層協議階段   7
3-7 鏈路終止階段   8
4 自動機協商選項   8
4-1 狀態遷移圖   9
4-2 狀態   10
4-3 事件   12
4-4 動作   14
4-5 環躲避（循環避免）   15
4-6 計數器和定時器   16
5 LCP包格式   16
5-1. Configure-Request   18
5-2. Configure-Ack   18
5-3. Configure-Nak   19
5-4. Configure-Reject   20
5-5. Terminate-Request and Terminate-Ack   20
5-6. Code-Reject   21
5-7. Protocol-Reject   22
5-8. Echo-Request and Echo-Reply   22
5-9. Discard-Request   23
6. LCP配置選項   24
6-1. Maximum-Receive-Unit (MRU)   25
6-2. Authentication-Protocol   25
6-3. Quality-Protocol   26
6-4. Magic-Number   27
安全考慮   30
參考資料   30
致謝   31
主席地址   31
作者地址   32

1 介紹
　　PPP是爲在同等單元之間傳輸數據包這樣的簡單的鏈路而設計的。這種鏈路提供全雙工操作，並按照順序傳遞數據包。（人們）有意讓PPP爲基於各種主機、網橋和路由器的簡單連接提供一種共通的解決方案。
　　封裝：
　　PPP封裝提供了不同網絡層協議同時通過統一鏈路的多路技術。（人們）精心的設計PPP封裝，使其保有對常用支持硬件的兼容性。
　　當使用默認的類HDLC幀（HDLC-like framing）時，僅需要8個額外的字節，就可以形成封裝。在帶寬需要付費時，封裝和幀可以減少到2或4個字節。
　　爲了支持高速的執行，默認的封裝只使用簡單的字段，多路分解只需要對其中的一個字段進行檢驗。默認的頭和信息字段落在32-bit邊界上，尾字節可以被填補到任意的邊界。

　　鏈路控制協議（LCP）：
　　爲了在一個很寬廣的環境內能足夠方便的使用，PPP提供了LCP。LCP用於就封裝格式選項自動的達成一致，處理數據包大小的變化，探測looped-back鏈路和其他普通的配置錯誤，以及終止鏈路。提供的其他可選設備有：對鏈路中同等單元標識的認證，和當鏈路功能正常或鏈路失敗時的決定。

　　網絡控制協議：
　　點對點連接可能和當前的一族網絡協議產生許多問題。例如，基於電路交換的點對點連接（比如撥號模式服務），分配和管理IP地址，即使在LAN環境中，也非常困難。這些問題由一族網絡控制協議（NCP）來處理，每一個協議管理着各自的網絡層協議的特殊需求。

　　配置：
　　（人們）有意使PPP鏈路很容易配置。通過設計，標準的默認值處理全部的配置。執行者可以對默認配置進行改進，它被自動的通知給其同等單元而無需操作員的干涉。最終，操作員可以明確的爲鏈路設定選項，以便其正常工作。
1-1 要求說明書
　　在本文檔中，用以下幾個詞來表示說明書的要求，這些詞一般以大寫字體書寫。
　　MUST--要求；MUST NOT--禁止；SHOULD--推薦；MAY--可選。

1-2 術語
　　本文檔中，頻繁使用以下術語：
　　datagram -- 在網絡層中的傳輸單元（例如IP）。一個datagram可能被壓縮成一個或幾個packets，在數據鏈路層中傳輸。
　　frame -- 在數據鏈路層中的傳輸單元。一個frame包括一個頭和/或尾字節，後面跟有幾個單元的數據。
　　packet -- 封裝的基本單元，它穿越網絡層和數據鏈路層的分解面。通常一個packet映射成一個frame，但也有例外：即當數據鏈路層執行拆分或將幾個packet合成一個frame的時候。
　　peer -- 點對點鏈路的另一端。
　　silently discard
　　-- 丟棄packet而不進行進一步的處理。執行（這個動作）應該提供記錄錯誤，包括丟棄packet的內容，的容量，並且應該在一個統計計數器中記錄這一事件。
2 PPP封裝
　　PPP封裝用於消除多協議datagrams的歧義。封裝需要幀同步以確定封裝的開始和結束。提供幀同步的方法在參考文檔中。
　　PPP封裝的概要如下所示。字段的傳輸從左到右。
　　　協議字段：
　　協議字段由一個或兩個字節組成。它的值標識着壓縮在packet的信息字段裏的datagram。字段中最有意義位（最高位）被首先傳輸。
　　該字段結構與ISO 3309地址字段擴充機制相一致。該字段必須是奇數：最輕意義字節的最輕意義位（最低位）必須等於1。另外，字段必須被賦值，以便最有意義字節的最輕意義位爲0。收到的不符合這些規則的frames，必須被視爲帶有不被承認的協議。
　　在範圍"0***"到"3***"內的協議字段，標識着特殊packets的網絡層協議。在範圍"8***" 到"b***"內的協議字段，標識着packets屬於聯合的（相關的）網絡控制協議（NCP）。在範圍"4***"到"7***"內的協議字段，用於沒有相關NCP的低通信量協議。在範圍"c***"到"f***"內的協議字段，標識着使用鏈路層控制協議（例如LCP）的packets。
　　到目前爲止，協議字段的值在最近的"Assigned Numbers" RFC [2]裏有詳細的說明。本說明書保留以下的值：
　　Value (in hex) 　　　　Protocol Name

　　0001 　　　　　　　　　Padding Protocol填料協議
　　0003 to 001f　　　　　 reserved (transparency inefficient)保留（透明度效率低的）
　　007d 　　　　　　　　　reserved (Control Escape)保留（控制逃逸）
　　00cf 　　　　　　　　　reserved (PPP NLPID)保留(PPP NLPID)
　　00ff 　　　　　　　　　reserved (compression inefficient)保留(壓縮效率低的)
　　8001 to 801f 　　　　　unused（未使用）
　　807d 　　　　　　　　　unused（未使用）
　　80cf 　　　　　　　　　unused（未使用）
　　80ff 　　　　　　　　　unused（未使用）

　　c021 　　　　　　　　　Link Control Protocol鏈路控制協議
　　c023 　　　　　　　　　Password Authentication Protocol密碼認證協議
　　c025 　　　　　　　　　Link Quality Report鏈路品質報告
　　c223 　　　　　　　　　Challenge Handshake Authentication Protocol挑戰-認證握手協議
　　新的協議的開發者必須從the Internet Assigned Numbers Authority (IANA), at [email protected].處獲得號碼。

　　信息字段：
　　信息字段是0或更多的字節。對於在協議字段裏指定的協議，信息字段包含datagram。
　　信息字段的最大長度，包含填料但不包含協議字段，術語叫做最大接收單元（MRU），默認值是1500字節。若經過協商同意，也可以使用其它的值作爲MRU。

　　填料：
　　在傳輸的時候，信息字段會被填充若干字節以達到MRU。每個協議負責根據實際信息的大小確定填料的字節數。
3 PPP鏈路操作
3-1 概述
　　爲了通過點對點鏈路建立通信，PPP鏈路的每一端，必須首先發送LCP packets以便設定和測試數據鏈路。在鏈路建立之後，peer纔可以被認證。
　　然後，PPP必鬚髮送NCP packets以便選擇和設定一個或更多的網絡層協議。一旦每個被選擇的網絡層協議都被設定好了，來自每個網絡層協議的datagrams就能在連路上發送了。
鏈路將保持通信設定不變，直到外在的LCP和NCP關閉鏈路，或者是發生一些外部事件的時候（休止狀態的定時器期滿或者網絡管理員干涉）。

3-2 階段劃分框圖
　　

　　在設定、維持和終止點對點鏈路的過程裏，PPP鏈路經過幾個清楚的階段，如框圖所示。這張圖並沒有給出所有的狀態轉換。
3-3 鏈路死亡（物理連接不存在）
　　鏈路一定開始並結束於這個階段。當一個外部事件（例如載波偵聽或網絡管理員設定）指出物理層已經準備就緒時，PPP將進入鏈路建立階段。
　　在這個階段，LCP自動機器將處於初始狀態，向鏈路建立階段的轉換將給LCP自動機器一個UP事件信號。
執行筆記：
　　典型的，在與調制解調器斷開之後，鏈路將自動返回這一階段。在用硬件實現的鏈路裏，這一階段相當的短--僅夠偵測設備的存在。
3-4 鏈路建立階段
　　LCP用於交換配置信息包（Configure packets），建立連接。一旦一個配置成功信息包（Configure-Ack packet）被髮送且被接收，就完成了交換，進入了LCP開啓狀態。
　　所有的配置選項都假定使用默認值，除非被配置交換所改變。
　　有一點要注意：只有不依賴於特別的網絡層協議的配置選項才倍LCP配置。在網絡層協議階段，個別的網絡層協議的配置由個別的網絡控制協議（NCP）來處理。
　　在這個階段接收的任何非LCP packets必須被silently discarded（靜靜的丟棄）。
　　收到LCP Configure-Request（LCP配置要求）能使鏈路從網絡層協議階段或者認證階段返回到鏈路建立階段。
3-5 認證階段
　　在一些鏈路上，在允許網絡層協議packets交換之前，鏈路的一端可能需要peer去認證它。
　　默認的，認證是不需要強制執行的。如果一次執行希望peer根據某一特定的認證協議來認證，那麼它必須在鏈路建立階段要求使用那個認證協議。
　　應該儘可能在鏈路建立後立即進行認證。而，鏈路質量檢查可以同時發生。在一次執行中，禁止因爲交換鏈路質量檢查packets而不確定地將認證向後推遲這一做法。
　　在認證完成之前，禁止從認證階段前進到網絡層協議階段。如果認證失敗，認證者應該躍遷到鏈路終止階段。
　　在這一階段裏，只有鏈路控制協議、認證協議，和鏈路質量監視協議的packets是被允許的。在該階段裏接收到的其他的packets必須被靜靜的丟棄。
　　執行筆記：
　　一次執行中，僅僅是因爲超時或者沒有應答就造成認證的失敗是不應該的。認證應該允許某種再傳輸，只有在若干次的認證嘗試失敗以後，不得已的時候，才進入鏈路終止階段。
　　在執行中，哪一方拒絕了另一方的認證，哪一方就要負責開始鏈路終止階段。
3-6 網絡層協議階段
　　一旦PPP完成了前面的階段，每一個網絡層協議（例如IP，IPX，或AppleTalk）必須被適當的網絡控制協議（NCP）分別設定。每個NCP可以隨時被打開和關閉。
　　執行筆記：
　　因爲一次執行最初可能需要大力浪的時間用於鏈路質量檢測，所以當等待peer設定NCP的時候，執行應該避免使用固定的timeouts。
　　當一個NCP處於Opened狀態時，PPP將攜帶相應的網絡層協議packets。當相應的NCP不處於Opened狀態時，任何接收到的被支持的網絡層協議packets都將被靜靜的丟棄。
　　執行記錄：
　　當LCP處於Opened狀態時，任何不被該執行所支持的協議packets必須在Protocol-Reject裏返回。只有支持的協議才被靜靜的丟棄。
　　在這個階段，鏈路通信量由LCP，NCP，和網絡層協議packets的任意可能的聯合組成。
3-7 鏈路終止階段
　　PPP可以在任意時間終止鏈路。引起鏈路終止的原因很多：載波丟失、認證失敗、鏈路質量失敗、空閒週期定時器期滿、或者管理員關閉鏈路。
　　LCP用交換Terminate（終止）packets的方法終止鏈路。當鏈路正被關閉時，PPP通知網絡層協議，以便他們可以採取正確的行動。
　　交換Terminate（終止）packets之後，執行應該通知物理層斷開，以便強制鏈路終止，尤其當認證失敗時。　　　Terminate-Request（終止-要求）的發送者，在收到Terminate-Ack（終止-允許）後，或者在重啓計數器期滿後，應該斷開連接。收到Terminate-Request的一方，應該等待peer去切斷，在發出Terminate-Request後，至少也要經過一個Restart time（重啓時間），才允許斷開。PPP應該前進到鏈路死亡階段。
　　在該階段收到的任何非LCP packets，必須被靜靜的丟棄。
　　執行筆記：
　　LCP關閉鏈路就足夠了，不需要每一個NCP發送一個Terminate packets。相反，一個NCP關閉卻不足以引起PPP鏈路的終止，即使那個NCP是當前唯一一個處於Opened狀態的NCP。
4 自動機協商選項
　　finite-state automaton（有限態自動機）由事件、動作和狀態轉換定義。事件包括接收外部命令，例如Open and Close（打開和關閉）、重啓定時器期滿、和接收從peer來的packets。動作包括啓動重啓定時器和向peer傳輸packets。
　　一些packets類型--Configure-Naks（設定-成功）和Configure-Rejects（設定-拒絕），或Code-Rejects（編碼-拒絕）和Protocol-Rejects（協議-拒絕），或Echo-Requests（回波-要求），Echo-Replies（回波-應答）和Discard-Requests（丟棄-要求）--在自動機描述中不加以區分。從後面的描述可知，這些packets確實有着不同的功能。然而他們總是引起相同的轉換。

Events Actions

Up = lower layer is Up tlu = This-Layer-Up
Down = lower layer is Down tld = This-Layer-Down
Open = administrative Open tls = This-Layer-Started
Close= administrative Close tlf = This-Layer-Finished

TO+ = Timeout with counter > 0 irc = Initialize-Restart-Count
TO- = Timeout with counter expired zrc = Zero-Restart-Count

RCR+ = Receive-Configure-Request (Good) scr = Send-Configure-Request
RCR- = Receive-Configure-Request (Bad)
RCA = Receive-Configure-Ack sca = Send-Configure-Ack
RCN = Receive-Configure-Nak/Rej scn = Send-Configure-Nak/Rej

RTR = Receive-Terminate-Request str = Send-Terminate-Request
RTA = Receive-Terminate-Ack sta = Send-Terminate-Ack

RUC = Receive-Unknown-Code scj = Send-Code-Reject
RXJ+ = Receive-Code-Reject (permitted)
or Receive-Protocol-Reject
RXJ- = Receive-Code-Reject (catastrophic)
or Receive-Protocol-Reject
RXR = Receive-Echo-Request ser = Send-Echo-Reply
or Receive-Echo-Reply
or Receive-Discard-Request
4-1 狀態遷移圖
　　全部的狀態轉換如下表。狀態在水平軸，事件在垂直軸。狀態轉換和動作備表示成：動作/新狀態的形式。多個動作用逗號分隔，無先後順序。狀態後面跟的那個字母是說明性的腳註。短劃線（'-'）代表無效的轉換。

| State
| 6 7 8 9
Events| Req-Sent Ack-Rcvd Ack-Sent Opened
------+-----------------------------------------
Up | - - - -
Down | 1 1 1 tld/1
Open | 6 7 8 9r
Close|irc,str/4 irc,str/4 irc,str/4 tld,irc,str/4
|
TO+ | scr/6 scr/6 scr/8 -
TO- | tlf/3p tlf/3p tlf/3p -
|
RCR+ | sca/8 sca,tlu/9 sca/8 tld,scr,sca/8
RCR- | scn/6 scn/7 scn/6 tld,scr,scn/6
RCA | irc/7 scr/6x irc,tlu/9 tld,scr/6x
RCN |irc,scr/6 scr/6x irc,scr/8 tld,scr/6x
|
RTR | sta/6 sta/6 sta/6 tld,zrc,sta/5
RTA | 6 6 8 tld,scr/6
|
RUC | scj/6 scj/7 scj/8 scj/9
RXJ+ | 6 6 8 9
RXJ- | tlf/3 tlf/3 tlf/3 tld,irc,str/5
|
RXR | 6 7 8 ser/9
　　那些其中運行着重啓計時器的狀態，是可以由存在的TO事件確認的。只有 Send-Configure-Request，Send-Terminate-Request和Zero-Restart-Count動作才啓動或者重新啓動重啓定時器。當從任意一個定時器運行的狀態轉換到一個定時器不運行的狀態時，重啓定時器（Restart timer）停止。
　　根據消息通過體系機構而不是信號通知體系機構，（人們）定義了事件和動作。如果希望一個動作去控制特定的信號（如DTR），那麼就可能需要額外的動作。
　　[p] 被動選項；見Stopped狀態討論。
　　[r] 重啓選項；見Open事件討論。
　　[x] 交叉連接；見RCA事件討論。
4-2 狀態
　　下面是每個自動機狀態的詳細描述。
　　Initial（初始）：
　　在初始狀態，下層是不可獲得的（Down），並且沒有Open發生。Restart timer不在該狀態下運行。
　　Starting（啓動）：
　　啓動狀態是初始狀態的Open相似物。一個管理的Open被初始化，但下層仍舊不可用（Down）。Restart timer不在該狀態下運行。
　　當下層變爲可用（Up）時，發送一個Configure-Request。
　　Closed（關閉）：
　　在關閉狀態，鏈路時可用的（Up），但是沒有Open發生。Restart timer不在該狀態下運行。當收到Configure-Request packets時，發送一個Terminate-Ack。Terminate-Acks被靜靜的丟棄，以防止造成循環。
Stopped（停止）
　　停止狀態是關閉狀態的Open相似物。當在This-Layer-Finished動作之後，或是發送Terminate-Ack之後，自動機正等待Down事件的時候，進入該狀態。Restart timer不在該狀態下運行。
　　當收到Configure-Request packets時，發送一個適當的響應。當收到其他packets時，發送一個Terminate-Ack。Terminate-Acks被靜靜的丟棄，以防止造成循環。
　　基本原理：
　　停止狀態是鏈路終止，鏈路設定失敗，和其他自動機失敗模式的一個接合（中間）狀態。這些各自獨立的狀態被潛在的聯合起來。
　　在Down事件應答（從This-Layer-Finished動作）和Receive-Configure-Request事件之間，有一種競賽條件。當Configure-Request在Down事件之前到來，代替Down事件的是自動機返回到Starting狀態。這防止了由重複產生的攻擊。
　　執行選項：
　　在peer對Configure-Requests響應失敗之後，一個執行可以被動的等待peer發送Configure-Requests。在這種情況下，在狀態Req-Sent，Ack-Rcvd，和Ack-Sent裏，動作This-Layer-Finished不用於TO- 事件。
　　這個選項對於專用電路或者沒有可用的狀態信號的電路有用，但禁止用於交換電路。
　　Closing（結束）
　　在結束狀態裏，爲了終止連接作了一次嘗試。發送了一個Terminate-Request，並運行了Restart timer，但沒有收到Terminate-Ack。
　　當收到Terminate-Ack時，就進入了Closed狀態。當Restart timer期滿時，傳輸一個新的Terminate-Request，並且Restart timer被重新啓動。在Restart timer達到Max-Terminate時間後，就進入了Closed狀態。
　　Stopping（停下）
　　停下狀態是結束狀態的Open相似物。發送了一個Terminate-Request，並運行了Restart timer，但沒有收到Terminate-Ack。
　　基本原理：
　　停下狀態提供了一個很好的機會在允許新的通信量之前終止鏈路。在鏈路終止後，經由Stopped或Starting狀態，會出現一個新的配置（設定）。
　　Request-Sent（要求-發送）
　　在要求-發送狀態，嘗試着配置（設定）連接。發送了一個Terminate-Request，並運行了Restart timer，但沒有收到Terminate-Ack。
　　Ack-Received（Ack-接收）
　　在Ack-接收狀態，發送了一個Configure-Request，接收了一個Configure-Ack。因爲還沒有發送Configure-Ack，所以Restart timer仍舊運行。
　　Ack-Sent（Ack-發送）
　　在Ack-發送狀態，Configure-Request和Configure-Ack都被髮送了。但沒有接收到Configure-Ack。因爲還沒有接收到Configure-Ack，所以Restart timer仍舊運行。
　　Opened（開啓）
　　在開啓狀態，發送了一個Configure-Ack，也接收了一個Configure-Ack。Restart timer不運行。
當進入該狀態時，執行應該通知上層，現在Up。相反，當離開該裝態時，執行應該通知上層，現在Down。
　　4-3 事件
　　自動機裏的狀態轉換和動作是由事件引起的。
　　Up：
　　當低層指出已準備好攜帶packets時，發生此事件。
　　典型的，該事件被調制解調器處理或呼叫過程，或被一些其他的連接於物理媒體的PPP用於通知LCP，鏈路正進入鏈路建立階段。
　　它也能被LCP用於通知每個NCP，鏈路進入網絡層協議階段。即，來自LCP的動作This-Layer-Up觸發了NCP中的Up事件。
　　Down：
　　當低層指出不再準備攜帶packets時，發生此事件。
　　典型的，該事件被調制解調器處理或呼叫過程，或被一些其他的連接於物理媒體的PPP用於通知LCP，鏈路正進入鏈路死亡階段。
　　它也能被LCP用於通知每個NCP，鏈路離開網絡層協議階段。即，來自LCP的動作This-Layer-Down觸發了NCP中的Down事件。
　　Open：
　　該事件指出鏈路的通信量是可以管理的：即，網絡管理者（人或程序）指出鏈路允許被Opened。當這一事件發生，且鏈路不處於Opened狀態時，自動機則試圖給peer發送配置packets。
　　如果自動機不能開始配置（下層是Down，或者前一個Close事件還沒有結束），那麼鏈路的建立將被自動的推遲。
　　當收到一個Terminate-Request，或者其他導致鏈路不可用的事件發生時，自動機將進入一個狀態，在那裏鏈路準備re-open。無需額外的管理干涉。
　　執行選項：
　　經驗表明：當用戶想就鏈路進行重新談判時，他們將額外的執行一條Open命令。這表明新的值將被協商。既然這不是Open事件的含義，那就暗示着在Opened, Closing, Stopping或Stopped狀態，當執行一條Open用戶命令時，執行發行一個Down事件，緊接着一個Up事件。一定要注意不能有從另一個源發生的Down事件的干涉。緊接着Up事件的Down事件將引起一次有秩序的鏈路的再協商（通過先前進到Starting狀態，再進入到Request-Sent狀態）。該再協商沒有負面影響。
　　Close：
　　該事件意味着鏈路沒有通信量。即，網絡管理者（人或程序）指示鏈路不允許被開放。當該事件發生且鏈路不處於Closed狀態時，自動機試圖終止連接。拒絕重新配置鏈路的嘗試，直到一個新的Open事件發生。
　　執行筆記：
　　當認證失敗，鏈路應該被終止，以防止受到重複性的攻擊和爲其他用戶服務。這可以通過模仿一個Close事件給LCP，然後緊跟着一個Open事件來完成，既然鏈路在管理上是可被訪問的。一定要注意不能有從另一個源發生的Down事件的干涉。
　　緊接着Up事件的Down事件將引起一次有秩序的鏈路的再協商（通過先前進到Closing狀態，再進入到Stopping狀態），This-Layer-Finished動作能斷開鏈路的連接。在Stopped或Starting狀態，自動機等待下一次連接嘗試。
　　Timeout (TO+,TO-)：
　　該事件表明Restart timer期滿。Restart timer用於記錄對Configure-Request和Terminate-Request packets的響應的時間。
　　TO+事件表明Restart counter持續大於零，它觸發了相應的Configure-Request或Terminate-Request packet的發送。
　　TO-事件表明Restart counter持續不大於零，不再需要發送packets。
　　Receive-Configure-Request (RCR+,RCR-)：
　　當收到一個來自peer的Configure-Request packet時，該事件發生。Configure-Request packet表明希望開創一個連接並且可以指定配置選項。
　　RCR+事件表明Configure-Request是可接受的，並且觸發相應的Configure-Ack的傳輸。
　　RCR-事件表明Configure-Request是不可接受的，並且觸發相應的Configure-Nak 或Configure-Reject的傳輸。
　　執行筆記：
　　這些事件可以發生在已經處於Opened狀態的連接上。該執行必須準備立即再協商配置選項。
　　Receive-Configure-Ack (RCA)：
　　當收到一個來自peer的有效Configure-Ack packet時，該事件發生。Configure-Ack packet是對Configure-Request packet的肯定應答。序列之外的或者無效的packet被靜靜的丟棄。
　　執行筆記：
　　既然在到達Ack-Rcvd或Opened狀態之前，正確的packet已經被收到了，那就絕不可能有另一個這樣的packet的到來。像說明的一樣，所有無效的Ack/Nak/Rej packets將被靜靜的丟棄，並不影響自動機的（狀態）轉換。
　　然而，格式正確的packet不可能通過coincidentally-timed cross-connection（同步交換連接）到達（目的地）的。它更可能是執行出錯的結果。至少，這種情況應該被記錄下來。
　　Receive-Configure-Nak/Rej (RCN)：
　　當收到一個來自peer的有效Configure-Nak或Configure-Reject packet時，該事件發生。Configure-Nak或Configure-Reject packet是對Configure-Request packet的否定應答。序列之外的或者無效的packet被靜靜的丟棄。
　　執行筆記：
　　儘管Configure-Nak和Configure-Reject在自動機中引起相同的狀態轉換，但這些packets對發送於Configure-Request packet中的配置選項有着截然不同的影響。
　　Receive-Terminate-Request (RTR)：
　　當收到一個Terminate-Request packet時，該事件發生。Terminate-Request packet表明希望peer去關閉連接。
　　執行筆記：
　　該事件於Close事件不同，它需要考慮局域網管理者的Open命令。執行必須準備接收新的沒有網絡管理者干涉的Configure-Request。
　　Receive-Terminate-Ack (RTA)：
　　當收到一個來自peer的Terminate-Ack packet時，該事件發生。Terminate-Ack packet通常是對Terminate-Request packet的響應。Terminate-Ack packet也可以表明peer正處於Closed或Stopped狀態，適應於鏈路配置的再同步。
　　Receive-Unknown-Code (RUC)：
　　當收到一個來自peer的un-interpretable（不能說明的）packet時，該事件發生。發送一個Code-Reject packet作爲響應。
　　Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-)：
　　當收到一個來自peer的Code-Reject或Protocol-Reject packet時，該事件發生。
　　當拒絕值可接受時（例如一個擴充編碼的Code-Reject，或一個NCP的Protocol-Reject，這些在一般操作的範圍內），RXJ+事件出現。執行必須停止發送損壞了的packet類型。
　　當拒絕值是災難性的時候（例如一個Configure-Request的Code-Reject，或一個LCP的Protocol-Reject），RXJ- 事件出現。該事件傳達了一個不可校正的錯誤（導致連接終止）。
　　Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request(RXR)：
　　當收到一個來自peer的Echo-Request，Echo-Reply或Discard-Request packet時，該事件發生。Echo-Reply packet是對Echo-Request packet的響應。Echo-Reply或Discard-Request packet沒有響應。
4-4 動作
　　自動機中的動作有事件引起。典型的，動作表明了packets的傳輸，和/或Restart timer的啓動和停止。
　　Illegal-Event (-)：不合法的事件
　　該動作指出一個在正常執行的自動機中不可能出現的事件。執行有一個內在的錯誤，應該把它報告並記錄下來。沒有轉換被執行，執行不應該reset or freeze（重新安排或凍結）。
　　This-Layer-Up（tlu）
　　動作給自動進入打開階段的上邊的層做指示。
典型的，該動作被LCP用於對一個NCP發送向上的事件信號，或者鏈路質量協議，或者可以被一個NCP用於顯示該鏈路可用於它的網絡層往來。
　　This-Layer-Down（tld）
　　該動作給自動留下打開的階段的上邊的層做指示。
　　典型地，該動作被LCP用於向一個NCP發送向下的事件，證實協議，或者可以被一個NCP用於顯示該鏈路對它的網絡層傳輸不再可用。
　　This-Layer-Started了（tls）
　　該動作對自動進入開始狀態的更低的層做指示，並且需要更低的層用於該鏈路。
　　當更低的層可用的時候，更低的層應該用一個向上的事件響應。
　　該動作的結果是高度的依賴動作的執行的。
　　This-Layer-Finished（tlf）
　　該動作給自動進入最初，關閉了或者停止的階段的更低的層做指示，並且，在鏈路上不再需要更低的層。
　　當更低的層終止的時候，更低的層應該用一個向下的事件應答。
　　典型地，該動作可以被LCP用於前進到鏈路死掉的狀態，或者可以被一個NCP用於給當沒有其他的NCPs打開時鏈路可以被終止的LCP做指示。
　　該動作的結果是高度的依賴動作的執行的。
　　Initialize-Restart-Count（irc）
　　該動作對Restart計數器設置適當的值（Max-Terminate 或 Max-Configure）。
　　每次傳輸，包括第一次傳輸，計數器自減。
　　執行記錄：
　　附加的設置Restart計數器，當使用了重定時返回時，該執行必須設置超時週期到初始值。
　　Zero-Restart-Count（zrc）
　　該動作對Restart計數器清零。
　　執行記錄：
　　該動作允許FSA在進行到要求的最終狀態之前暫停，允許用peer進行傳輸。
　　附加的清零Restart計數器，該執行必須設置超時週期到初始值。
　　Send-Configure-Request（scr）
　　一個Configure-Request的包被傳送。
　　這表明要用指定的一套特殊的配置選項打開一個連接。
　　爲了防止包丟失，Restart計時器在Configure-Request包被傳送的時候打開。
　　每次一個Configure-Request被髮送的時候，Restart計數器自減。
　　Send-Configure-Ack（sca）
　　一個Configure-Ack包被傳送。這確認接收了一個帶有一套可接受的配置選項的Configure-Request包。
　　Send-Configure-Nak（scn）
　　一個Configure-Nak或Configure-Reject包被穩妥的傳送。
　　否定的響應表明一個Configure-Request包帶有一套不可接受的配置選項。
　　Configure-Nak包被用於拒絕一個配置選項值，並提議一個新的，可接受的值。
　　Configure-Reject包被用於拒絕全部的關於一個配置選項的協商，典型的因爲不被認可或不被滿足。
　　在關於LCP包格式的章節對Configure-Nak的使用比Configure-Reject有更充分的描述。
　　Send-Terminate-Request（str）
　　一個Terminate-Request包被傳送。
　　這表示想要關上連接的願望。
　　當Terminate-Request包被傳送時Restart計時器被開啓，來防止包丟失。
　　每次一個Terminate-Request被髮送的時候，Restart計數器自減。
　　Send-Terminate-Ack (sta)
　　一個Terminate-Ack包被傳送。
　　這確認Terminate-Request的包的接收，或者以別的方式對於自動同步起作用。
　　Send-Code-Reject（scj）
　　一個Code-Reject包被傳送。
　　這表示未知的種類的包的接收。
　　Send-Echo-Reply (ser)
　　一個Echo-Reply包被傳送。
　　這確認一個Echo-Request包的接收。
4-5 環躲避（循環避免）
　　協議做避開協商成環狀的配置選項的適當嘗試。
　　不過，協議不保證環將不發生。
　　和任何協商一樣，有可能來設置2個PPP由不收斂的矛盾的方法來執行。
　　同樣，也有可能配置收斂的，重要的時間這樣去做的方法。
　　設備應該考慮這些，並且應該滿足環偵測機制或更高水平的超時。
4-6 計數器和定時器
　　重啓動定時器
　　有一個特殊的定時器被自動使用。
　　重啓動定時器被用於計算Configure-Request和Terminate-Request包的傳輸時間。
　　重啓動定時器的滿期產生一個超時事件，並且通信Configure-Request或Terminate-Request包重新傳送。
　　重啓動定時器必須是可配置的，但是應該缺省爲三（3）秒。
　　執行記錄：
　　重新開始計時器應該根據鏈路的速度。
　　缺省值被指定爲低的速度（2,400～9,600 bps），高交換的等待時間鏈路（典型電話線）。
　　更高的速度鏈路或和低交換等待時間的鏈路應該相對應有更快的再次傳輸時間。
　　代替恆定值，重新開始計時器可以從最初的小的值開始增加到配置的最終值。
　　每一個小於最終值的連續值應該至少是前一個值的兩倍。
　　初始值應該對包的大小來說足夠大，用於以線路速率傳輸兩倍的round trip時間，並且至少附加100毫秒來允　　許peer來處理響應之前的包。
　　一些電路又加了200毫秒的附加遲延。
　　以14,400 bps運作的調制解調器的round trip時間範圍中精確到160到600毫秒以上。
　　Max-Terminate
　　必須有一個Terminate-Requests的restart計數器。
　　Max-Terminate顯示Terminate-Request包發送，但是認爲peer不會應答的，沒有收到Terminate-Ack的包的個數。
　　Max-Terminate必須是可配置的，但是應該缺省爲二（2）秒傳輸。
　　Max-Configure
　　推薦爲Configure-Requests採用一個類似的計數器。
　　Max-Configure顯示Configure-Request包發送，在peer不會應答前的，沒有接收到一個有效的Configure-　　Ack，Configure-Nak 或 Configure-Reject的包的個數。
　　Max-Configure必須是可配置的，但是應該缺省爲十（10）次傳輸。
　　Max-Failure
　　推薦爲Configure-Nak採用一個相關的計數器。
　　Max-Failure顯示Configure-Nak包發送，在假定配置不收斂之前發Configure-Ack的Configure-Nak包的個數。
　　任何更進一步的用於peer請求的選項被轉換到Configure-Reject包，並且不在附加局部要求選項。
　　Max-Failure必須是可配置的，但是應該缺省爲五（5）次傳輸。
5 LCP包格式
　　LCP包有3類：
　　1.鏈路配置包，用於建立和配置鏈路（Configure-Request，Configure-Ack，Configure-Nak，和Configure-Reject）。
　　2.鏈路結束包被用於結束一個鏈路（Terminate-Request 和 Terminate-Ack）
　　3.鏈路維修包被用於管理和調試一個鏈路（Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, 和 Discard-Request）。
　　爲了簡單的利益，LCP包裏沒有版本域。
　　一個正確的運作的LCP的執行將總是對帶有簡單地可以識別的LCP包的未知協議和代碼進行響應。這樣倘若一個確定性的可靠的機制用於其他版本的執行。
　　不管哪個配置選項被允許，所有的LCP鏈路配置，鏈路終止和代碼-拒絕包（代碼1到7）總被髮送，就像沒有配置選項被協商一樣。
　　特別是，每個配置選項都指定缺省值。
　　這就保證了這樣的LCP包總是可以識別的，甚至當1個鏈路的結束錯誤的相信該鏈路是開着的。
　　確切的說1個LCP包被封裝在PPP信息域中，該PPP協議域表示類型爲十六進制c021（鏈路控制協議）。
　　鏈環控制協議包格式的摘要如下。
　　域被從左往右傳送。

代碼
　　代碼域是一個八位字節，確定LCP包的種類。
　　當收到一個帶有未知域的包時，一個Code-Reject包被傳送。
　　LCP代碼域的Up-to-date值在最近的"指定號碼"RFC[2]中被指定。該文檔涉及以下的值：
　　1 Configure-Request
　　2 Configure-Ack
　　3 Configure-Nak
　　4 Configure-Reject
　　5 Terminate-Request
　　6 Terminate-Ack
　　7 Code-Reject
　　8 Protocol-Reject
　　9 Echo-Request
　　10 Echo-Reply
　　11 Discard-Request
標識符
　　標識符域是一個八位字節，對匹配請求和回覆中有幫助。當帶有無效標識符域的包被接收時候，該包將不影響自動機制，被靜靜的丟棄。
長度
　　長度域是二個八位字節，指出LCP包的長度，包括代碼，標識符，長度和數據域。該長度必須不超過鏈路的MRU。
　　長度域以外的字節被當作填料而忽略處理。當收到帶有無效標識符該包將不影響自動機制，被靜靜的丟棄。
數據
　　數據域是零或多個八位字節，由長度域聲明。數據域的格式由代碼域決定。
5-1. Configure-Request
　　描述
　　一個執行想要打開一個連接必須傳送一個Configure-Request。選項域被填充任何想要的對鏈路默認的改變。配置選項應該不被包括到默認值中。Configure-Request的接收上，必須傳送適當的答覆。
　　下面給出Configure-Request包的格式的摘要。域從左到右傳輸。

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 代碼 | 標識符 | 長度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 選項 ...
+-+-+-+-+
代碼
　　1 爲Configure-Request
　　標識符
　　只要選項域改變的內容改變，並且只要收到先前請求的有效響應，標識符域必須被改變。對重發來說，標識符可以保持不變。
　　選項
　　選項域是長度的變量，幷包含零個或多個發送方需要協商的配置選項的列表。全部配置選項總是被同時協商。在下一章中對配置選項的格式有更詳細的描寫。
5-2. Configure-Ack
　　描述
　　如果Configure-Request中收到的每一個配置選項和全部的值都是能接受的，那麼該執行必須傳送一個Configure-Ack。該確認配置選項必須不被任何途徑的重命令或更改。
　　Configure-Ack的接收中，標識符域必須匹配最後傳送的Configure-Request。另外，Configure-Ack中的配置選項必須完全匹配最後傳輸的Configure-Request。錯誤包被靜靜的丟棄。
一個Configure-Ack包格式如下。域從左到右傳輸。

　　 2 爲Configure-Ack
　　標識符
　　標識符域是引起Configure-Ack的Configure-Request的標識符域的拷貝。
　　選項　
　　選項域是長度的變量，幷包含零個或多個發送方確認的配置選項的列表。全部配置選項總是被同時確認。
5-3. Configure-Nak
　　描述
　　如果每一個收到的配置選項要求是可認知的，但是一些值不能被接受，那麼該執行必須傳送一個Configure-Nak。選項域僅由來自Configure-Request的不可接受的配置選項所填充。全部可接受的配置選項填充在Configure-Nak外，但是來自Configure-Request的配置選項必須不被重命令。
　　沒有值域的選項（布爾選項）一定使用Configure-Reject答覆來代替。
　　允許僅有一個單一要求的每一個配置選項必須被修正到可接受的值到Configure-Nak發送方。當與被請求的值不一致時，默認值可以被使用。
　　一個詳細的配置選項類型能以不同的值被列出超過一次時，Configure-Nak必須包括Configure-Nak發送方所接受的全部選項值的列表。包括Configure-Request中當前可接受的值。
　　最後，一個執行可以被配置到要求明確的配置選項。若該選項未被列出，則該選項可以被添加到沒有應答的配置選項的列表中，以便提示peer添加該選項到Configure-Request包中。任何用於該選項的值域必須指出Configure-Nak發送方的可接受值。
　　在一個Configure-Nak接收中，標識符域必須匹配最後一個傳輸的Configure-Request。錯誤包被靜靜的丟棄。
　　當一個新的Configure-Request發送時正確的Configure-Nak的接收，配置選項可以被作爲Configure-Nak中的指定。噹噹前配置選項是多種情況時，peer應該選擇一個單一的值包含到下一個Configure-Request包中。
　　一些配置選項有可變長度。既然沒有應答的選項被peer修正了，該執行必須能夠處理與來自原Configure-　Request不同的選項長度。
　　Configure-Nak包格式如下。域從左到右傳送。

3 爲Configure-Nak
　　標識符
　　標識符域是導致Configure-Nak的Configure-Request的標識符的拷貝。
　　選項
　　選項域是長度的變量，包含零到多個沒有應答的發送方的配置選項。
　　全部配置選項總是同時沒有應答的。
5-4. Configure-Reject
　　描述
　　如果Configure-Request中收到的一些配置選項是不可辨認的或者不被商議所接受（由網絡管理員配置的），則該執行必須傳送一個Configure-Reject。選項域僅由來自Configure-Request不可接受的配置選項所填充。所有可識別的和可通過商議解決的配置選項被過濾出Configure-Reject，但是另外的配置選項必須不被任何方式的重定義或修改。
　　在Configure-Reject的接受中，標識符域必須匹配最後傳輸的Configure-Request。
　　另外，Configure-Reject的配置選項必須是最後傳輸的Configure-Request的正確的子集。錯誤包被靜靜的丟棄。
　　有效的Configure-Reject接收指出當一個新的Configure-Request發送的時候，必須不包含任何Configure-Reject中列出的配置選項。
　　Configure-Reject包的格式如下。域從左到右傳送。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 代碼 | 標識符 | 長度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 選項 ...
+-+-+-+-+

代碼
　　4 爲Configure-Reject
　　標識符
　　標識符域是導致該Configure-Reject的Configure-Request的標識符域的拷貝。
　　選項
　　選項域是長度的變量，包含零或者多個發送者拒絕的配置選項列表。全部的配置選項總是被同時拒絕的。
5-5. Terminate-Request and Terminate-Ack
　　描述
　　LCP包含Terminate-Request 和 Terminate-Ack代碼是爲了提供關閉一個連接的機制。
　　一個執行想要關閉一個連接應該傳送一個Terminate-Request。Terminate-Request包應該繼續發送，直到收到Terminate-Ack，低層顯示已經關閉了，或者已經接收到了充分大的數量，以致peer有確切地理由關閉。
　　在一個Terminate-Request接收上，必須傳送一個Terminate-Ack。
　　接收一個未被引出的Terminate-Ack表示peer在Closed（關閉）或Stopped（停止）狀態，或者需要另外再商議。
　　Terminate-Request 和 Terminate-Ack包格式如下。域從左到右傳送。

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 代碼 | 標識符 | 長度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 數據...
+-+-+-+-+
代碼
　　5 爲Terminate-Request；
　　6 爲Terminate-Ack。
　　標識符
　　傳送過程中，無論何時數據域的內容發生了改變，而且無論何時接收到一個對前一個請求有效的答覆，標識符域必須改變，對於重新傳送，標識符可以保持不變。
　　接收過程中，Terminate-Request的標識符域被拷貝到Terminate-Ack包的標識符域。
　　數據
　　數據域爲零個或多個八位字節，包含發送方使用的未解釋的數據。該數據可以由任何二進制值組成。該域的結束可以由長度指出。
5-6. Code-Reject
　　描述
　　一個帶有未知代碼的LCP包的接收顯示peer由一個不同的版本操作。這必須傳送一個Code-Reject報告回給未知代碼的發送方。
　　一個基本的該版本協議的Code-Reject的接收中，執行應該報告問題並結束連接，既然該情形不像能被自動矯正。
　　Code-Reject包格式如下。域從左到右傳送。

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 代碼 | 標識符 | 長度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 被拒絕的包 ...
+-+-+-+-+-+-+-+-+
代碼
　　7 爲Code-Reject
　　標識符
　　對於每次Code-Reject發送，該標識符域必須被改變。
　　被拒絕的包
　　被拒絕的包域包含被拒絕的LCP包的拷貝。它由信息域開始，並且不包括任何數據鏈路層的頭或者FCS。被拒絕的包必須被縮短來符合peer指定的MRU。
5-7. Protocol-Reject
　　描述
　　一個帶有未知協議域的PPP包的接收顯示peer試圖使用一個不支持的協議。這通常發生在peer試圖配置一個新的協議時。如果LCP自動處理處於Opened（打開）狀態，那麼必須通過傳送一個Protocol-Reject報告回該peer。
　　在Protocol-Reject接收中，執行必須及早停止發送被指出的協議的包。
　　Protocol-Reject包只能在LCP的Opened（打開）狀態被髮送。在其他不是Opened（打開）狀態下接收到的Protocol-Reject包應該被靜靜的丟棄。
　　Protocol-Reject包格式如下。域從左到右傳送。

　　代碼
　　9 爲Echo-Request；
　　10 爲Echo-Reply
　　標識符
　　傳輸中，無論何時數據域內容的改變，並且無論何時接收到前一個請求的有效的響應，標識符域必須被改變。對於重新傳送標識符可以保持不變。
　　接收中，Echo-Request的標識符域被拷貝到Echo-Reply包的標識符域。
　　Magic-Number
　　Magic-Number域是四個八位字節，對檢測處於looped-back條件下的鏈路有幫助。在該Magic-Number配置選項被成功的協商之前，Magic-Number必須被以零傳送。在Magic-Number配置選項中由更詳細的說明。
　　數據
　　數據域是零或者多個八位字節，包含被髮送方使用的未解釋的數據。該數據可以由任何二進制值組成。該域的結束由長度指出。
5-9. Discard-Request
　　描述
　　LCP包含一個Discard-Request代碼爲了供給一個用於演習本地到遙遠的鏈路方向的數據鏈路層接收器機制。有助於調試、執行測試、和衆多的其他功能。
　　Discard-Request包必須僅在LCP的Opened（打開）狀態被髮送。接收中，接收器必須靜靜的丟棄任何收到的Discard-Request。
　　Discard-Request包格式如下。域從左到右傳送。

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 代碼 | 標識符 | 長度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 數據 ...
+-+-+-+-+
代碼
　　11 爲Discard-Request
　　標識符
　　每個Discard-Request發送，標識符域必須改變。
　　Magic-Number
　　Magic-Number域爲四個八位字節，對檢測處於looped-back條件下的鏈路有幫助。在該Magic-Number配置選項被成功的協商之前，Magic-Number必須被以零傳送。在Magic-Number配置選項中由更詳細的說明。
　　數據
　　數據域是零或者多個八位字節，包含被髮送方使用的未解釋的數據。該數據可以由任何二進制值組成。該域的結束由長度指出。
6. LCP配置選項
　　LCP配置選項允許點對點鏈路的默認特徵的更改的協商。如果一個配置選項不包含在Configure-Request包中，配置選項被假定爲默認值。
　　一些配置選項可以被列出超過一次。配置選項詳細的效果，由每一個配置選項描述所指出。（該說明書內的配置選項均不能被列出超過一次。）
　　列表最後的配置選項由LCP包的長度域所指出。
　　若不另外指定，所有的配置選項由半雙工方式支持：典型的，線路的接收方是來自Configure-Request發送者的觀點。
　　設計思想
　　選項指出另外的性能和提出選項的執行的要求。不瞭解任何選項的執行應該與實現每一個選項的操作交互執行。
　　對每一個允許鏈路沒有選項協商的正確功能的每一個選項指定默認值，儘管低於最佳性能。
　　除非明確的指出，一個選項的確認並不需要peer來比默認附加任何動作。
　　沒有必要爲Configure-Request中的選項發送默認值。
　　配置選項格式如下。域從左到右傳送。

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 類型 | 長度 | 數據 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
　　類型
　　類型域是一個八位字節，指出配置選項的類型。LCP選項類型域的Up-to-date值在大多數當前的"Assigned 　　Numbers" RFC [2]中被指定。
　　該文檔涉及以下值：

0 RESERVED（保留）
1 Maximum-Receive-Unit（最大-接收-單元）
3 Authentication-Protocol（鑑定-協議）
4 Quality-Protocol（質量-協議）
5 Magic-Number
7 Protocol-Field-Compression（協議-域-壓縮）
8 Address-and-Control-Field-Compression（地址-和-控制-域-壓縮）

　　長度
　　長度域是一個八位字節，並且指出該配置選項，包括類型、長度和數據域的長度。
　　如果在一個Configure-Request中收到了一個可通過談判解決的配置選項，但是帶有一個非法的或者未被承認的長度，Configure-Nak應該被傳送包括帶有適當的長度和數據的想得到的配置選項。
　　數據
　　數據域是零個或者更多的八位字節，並且包含配置選項的特殊詳細信息。數據域的類型和長度由類型和長度域所決定。
　　當數據域由長度到擴充超過信息域的結束所指出，整個包被不通知自動機制靜靜的丟棄。
6-1. Maximum-Receive-Unit (MRU)
　　描述
　　該配置選項可以被髮送到通知peer該執行可以接收更大的包，或者請求peer發送小一點的包。
　　默認值是1500個八位字節。如果請求小一點的包，萬一鏈路同步丟失，一個執行必須仍然能夠接收整個1500個八位字節的全部信息域。
　　執行記錄：
　　該選項用於指出一個執行的容量。peer不必需要最大容量的使用。例如，當一個2048個八位字節MRU被指出，　　peer不需要用2048個八位字節發送每個包。peer不需要Configure-Nak指出它將僅發送小一點的包，既然該執行將總是需要對至少1500八位字節的支持。
　　Maximum-Receive-Unit配置選項格式如下。域從左到右傳送。

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 類型 | 長度 | Maximum-Receive-Unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

　　類型
　　1
　　長度
　　4
　　Maximum-Receive-Unit
　　Maximum-Receive-Unit域是二個八位字節，在信息和填料域中指定最大字節數。它並不包括幀、協議域、FCS也不包括任何透明位或字節。
6-2. Authentication-Protocol
　　描述
　　一些鏈路可能想要peer在允許網絡層協議包被交換之前鑑別它自己。
　　該配置選項提供一種使用詳細而準確的協議進行鑑定的方法。默認的，不需要鑑定。
　　一個執行必須不在Configure-Request包中包含多重鑑定協議配置選項。代替的，應該首先嚐試配置最值得要的協議。如果協議是Configure-Nak的，那麼該執行應該在下一個Configure-Request中嘗試下一個最值得要的協議。
　　該執行發送Configure-Request指出它所期待的來自它的peer的鑑定。如果一個執行發送一個Configure-Ack ，那麼它同意進行指定協議的鑑定。一個執行接收一個Configure-Ack應該期待peer用公認協議進行鑑別。
沒有必要採用全雙工或者將同一個協議用於兩個方向。允許每個方向採用不同的協議是極好的。這將，當然，取決於協商的詳細協議。
　　Authentication-Protocol配置選項格式如下。域從左到右傳送。

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 類型 | 長度 | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 數據 ...
+-+-+-+-+
　　類型
　　3
　　長度
　　>=4
　　Authentication-Protocol
　　Authentication-Protocol域是兩個八位字節，指出想要鑑定的協議。該域的值總是與PPP協議域值一樣用於同樣的鑑定協議。
　　Authentication-Protocol域的Up-to-date值在最近的"Assigned Numbers" RFC [2]中被指定。
　　當前的值被賦值如下：
　　值（十六進制）協議
　　c023 　　　　　密碼證明協議
　　c223　　　　　　挑戰握手驗證協議
　　數據
　　數據域是零或多個八位字節，包含作爲由詳細協議決定了的附加數據。
6-3. Quality-Protocol
　　描述
　　一些鏈路上可能想要決定何時，和間隔多長時間，該鏈路丟棄數據。該過程被叫做鏈路質量監測。
　　該配置選項提供一種用於鏈路質量監測的使用詳細協議的商議方法。默認的，禁止鏈路質量監測。
　　該執行發送的Configure-Request指出它希望接收的來自它的peer的監測信息。
　　如果一個執行發送一個Configure-Ack，那麼它同意使用詳細協議。一個協議接收一個Configure-Ack應該等待peer發送確認協議。
　　不必要進行全雙工或雙方都使用同樣的協議的質量監測。最好兩端使用不同的可接受的協議。這將，當然，取決於商議的詳細的協議。
　　Quality-Protocol配置選項格式如下。域從左到右傳送。

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 類型 | 長度 | Quality-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 數據 ...
+-+-+-+-+

　　類型
　　4
　　長度
　　>=4
　　Quality-Protocol
　　Quality-Protocol域是兩個八位字節，指出鏈路想要的質量監測協議。該域的值總是與用於相同的監測協議的PPP協議域值相同。
　　Quality-Protocol域的Up-to-date值在最近的"Assigned Numbers" RFC [2]中指定。當前值的賦值如下：
　　值（十六進制）協議
　　c025 　　　　鏈路質量報告
　　數據
　　數據域是零或者多個八位字節，包含由詳細協議決定的附加數據。
6-4. Magic-Number
　　描述
　　該配置選項提供一種偵測looped-back鏈路和其他數據鏈路層異常的方法。該配置選項可以被一些其他配置選項例如Quality-Protocol配置選項所需求。默認的，該Magic-Number並不協商，並且零被插入到Magic-Number 可能用到的其他地方。
　　請求該配置選項之前，一個執行必須選擇它的Magic-Number。推薦Magic-Number使用在大多數隨機的方式可能性爲了保證一個執行有一個唯一的號碼的可能性高。選擇唯一號碼的好方法是用一個唯一的種子開始。建議使用唯一包含的機器序列號，其他網絡硬件地址，當時的時鐘，等等。獨特的好的隨機種子是物理事件的inter-arrival時間的精確測量，比如其他連接網絡的接收包，服務器響應時間，或者人類用戶的鍵入速率。它也建議儘可能的多的來源被同步。
　　當接收到一個帶有Magic-Number配置選項的Configure-Request時候，接收到的Magic-Number與最後一個發送給peer的Configure-Request的Magic-Number相比較。如果兩個Magic-Number不同，則該鏈路不被looped-back，而且Magic-Number應該被確認。如果兩個Magic-Number相等，那麼有可能，但是不確定，該線路是looped-back，並且該Configure-Request實際上是上一次發送的。爲了確認它，必鬚髮送一個Configure-Nak指定一個不同的Magic-Number值。一個新的Configure-Request應該不被髮送到peer，直到一般處理導致它的發送（那就是說，直到收到一個Configure-Nak或者Restart計時器溢出）。
　　接收到一個帶有Magic-Number的Configure-Nak與最後發送給peer的Configure-Nak不同，這就證明該鏈路不是looped-back，並且指出唯一的一個Magic-Number。如果該Magic-Number等於最後發送的Configure-Nak，有可能增加了一條looped-back鏈路，必須選擇一個新的Magic-Number。其他情況，應該發送一個新的帶有新的Magic-Number的Configure-Request。
　　如果該鏈路確實是looped-back，該次序（傳送Configure-Request,接收Configure-Request, 傳送Configure-Nak, 接收Configure-Nak）將被重複做下去。若該鏈路不是looped-back，該次序將發生很少的幾次，但是它非常不像能再三的重複。更像，所選擇的Magic-Number很快會跳出，結束該順序。下面的表格表明了鏈路的兩端帶有統一分配的Magic-Number衝突的可能性：

　　碰撞次數可能性
-------------------- ---------------------
1 1/2**32 = 2.3 E-10
2 1/2**32**2 = 5.4 E-20
3 1/2**32**3 = 1.3 E-29

　　唯一的或者隨機的好的源被髮生的分歧所需要。如果一個唯一的好的源不能被找到，推薦配置選項不能被激活：帶有該選項的Configure-Requests應該不被傳送並且peer發送的任何Magic-Number配置選項應該既被確認也被拒絕。在這種情況下，looped-back鏈路不能通過執行被可靠的監測出來，雖然peer仍然可以察覺他們。
　　如果一個執行傳送一個帶有Magic-Number配置選項的Configure-Request，那麼當它接收一個帶有Magic-Number配置選項的Configure-Request時它必須不響應。那就是說，如果一個執行想使用Magic Numbers，那麼它必須也允許它的peer這樣做。如果一個執行確實接收一個Configure-Request對Configure-Request的響應，只能表示該鏈路不是loop-back，並且它的peer將不使用Magic-Number。在這種情況下，一個執行應該行動好像協商已經成功（好像它真的收到了一個Configure-Ack）。
　　Magic-Number也可以被用於監測通常操作的looped-back鏈路，正如經過配置選項協商。所有的LCPEcho-Request, Echo-Reply, 和 Discard-Request 包都有一個Magic-Number域。如果Magic-Number被成功的協商，一個執行必須傳送那些帶有Magic-Number域的包的域到協商的Magic-Number。
　　這些包的Magic-Number域應該被接收的時候檢查。所有收到的Magic-Number域必須等於零或者peer的唯一的Magic-Number，取決於是不是peer協商了Magic-Number。
　　一個Magic-Number域的接收等於協商本地Magic-Number指出一個loop-back鏈路。一個Magic-Number的接收或者協商本地Magic-Number，該peer的協商Magic-Number，或者零如果peer不協商一個，指出一個被（漏）配置用於與一個不同的peer通訊。
　　情況未指明的任一事例恢復程序，和任何執行到執行的不同，一個稍微保守式程序被假定一個LCP關閉時間。一個更開放事件將開始重新設置鏈路的處理，直到looped-back條件被終止才完成，並且Magic-Numbers被成功的協商。一個更開放式的程序（在looped-back鏈路情況下）開始傳送LCPEcho-Request包，直到收到適當的Echo-Reply，指出looped-back條件的終止。
　　Magic-Number配置選項格式如下。域從左到右傳送。

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 類型 | 長度 | Magic-Number
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Magic-Number (內容) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

　　類型
　　5
　　長度
　　6
　　Magic-Number
　　Magic-Number域是四個八位字節，指出一個很像鏈路結尾唯一指定的號碼。零的Magic-Number是違法的，必須總是沒有應答，如果不被徹底拒絕。

6-5. Protocol-Field-Compression (PFC)
　　描述
　　該配置選項提供一種PPP協議域的壓縮協商方法。默認的，所有執行必須傳送帶有二個八位字節PPP協議域的數據包。
　　PPP協議域號被選擇那些值可以被壓縮進一個與二個八位字節有明顯區別的單一八位字節形態。該配置選項被髮送來通知peer該執行能接收這種單一八位字節協議域。
　　以前說過，協議域使用一種擴展機制與用於地址域的ISO 3309擴展機制一致：每一個八位字節的最低有效位（LSB）被用來指出協議域的擴展。一個二進制"0"作爲LSB指出協議域由以下八位字節繼續。二進制"1"作爲LSB標誌的存在於協議域的最後八位字節。注意到任何"0"的八位字節號碼可以被預製到域中，並且將仍然指出相同的值（認爲兩個八位字節代表3，00000011 和 00000000 00000011）。
　　當使用低速連接，值得通過發送儘可能小的冗餘數據來保存帶寬。Protocol-Field-Compression配置選項允許在執行簡單和帶寬效率之間進行平衡。如果順利的協商，ISO 3309擴展機制可以被用來壓縮協議域到一個八位字節來代替二個八位字節。大多數來自典型的數據協議分派的協議域值不超過256的包是可壓縮的。
　　被壓縮的協議域必須不被傳送，除非該配置選項被協商。協商後，PPP執行必須接受帶有既有雙-八位字節又有單-八位字節協議域的PPP包，必須不區別兩者。
　　當發送任何LCP數據包時從不壓縮協議域。該規則保證LCP包的明確識別。
　　當一個協議域被壓縮，數據鏈路層FCS域在被壓縮的幀中計算，而不是最初的未壓縮的幀。
　　Protocol-Field-Compression配置選項格式如下。域從左到右傳送。

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 類型 | 長度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

　　類型
　　7
　　長度
　　2

6-6. Address-and-Control-Field-Compression (ACFC)
　　描述
　　該配置選項提供一種數據鏈路層地址和控制域壓縮的方法。默認的，所有執行必須傳送帶有地址和控制域的適當的鏈路幀。
　　既然這些域通常用於點對點鏈路有常量，容易壓縮。該配置選項被髮送來通知peer該執行能接收壓縮地址和控制域。
　　如果當Address-and-Control-Field-Compression未被協商時接收到一個壓縮了的幀，該執行可以靜靜的丟棄該幀。
　　當發送任何LCP包時，地址和信息域必須不被壓縮。該規則保證明確識別LCP包。
　　當地址和控制域被壓縮時，數據鏈路層FCS域被在被壓縮的幀計算，而不是最初的未壓縮幀。
　　Address-and-Control-Field-Compression配置選項格式如下。域從左到右傳遞。

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 類型 | 長度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

　　類型
　　8
　　長度
　　2
　　安全考慮
安全問題在關於鑑定階段、Close(關閉)事件和鑑定協議配置選項的章節進行了簡單的討論。
安全考慮
Security issues are briefly discussed in sections concerning the
Authentication Phase, the Close event, and the Authentication-
Protocol Configuration Option.
參考資料
[1] Perkins, D., "Requirements for an Internet Standard Point-to-
Point Protocol", RFC 1547, Carnegie Mellon University,
December 1993.

[2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
1340, USC/Information Sciences Institute, July 1992.
致謝
This document is the product of the Point-to-Point Protocol Working
Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the [email protected] mailing list.

Much of the text in this document is taken from the working group
requirements [1]; and RFCs 1171 & 1172, by Drew Perkins while at
Carnegie Mellon University, and by Russ Hobby of the University of
California at Davis.

William Simpson was principally responsible for introducing
consistent terminology and philosophy, and the re-design of the phase
and negotiation state machines.

Many people spent significant time helping to develop the Point-to-
Point Protocol. The complete list of people is too numerous to list,
but the following people deserve special thanks: Rick Adams, Ken
Adelman, Fred Baker, Mike Ballard, Craig Fox, Karl Fox, Phill Gross,
Kory Hamzeh, former WG chair Russ Hobby, David Kaufman, former WG
chair Steve Knowles, Mark Lewis, former WG chair Brian Lloyd, John
LoVerso, Bill Melohn, Mike Patton, former WG chair Drew Perkins, Greg
Satz, John Shriver, Vernon Schryver, and Asher Waldfogel.

Special thanks to Morning Star Technologies for providing computing
resources and network access support for writing this specification.
主席地址
The working group can be contacted via the current chair:

Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California 93117

[email protected]
作者地址
Questions about this memo can also be directed to:

William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071

[email protected]
[email protected]

　
RFC1661 The Point-to-Point Protocol (PPP) RFC1661 PPP協議

1
ＲＦＣ文檔中文翻譯計劃

RFC1661中文 ppp協議

【筆記】動手學深度學習-前言

公司新來一個幹練小夥，把 MyBatis 替換成 MyBatis-Plus，上線後哭暈在廁所。。。

支持非IE瀏覽器真的那麼難嗎？

爲啥就那麼痛恨IE？

Brian Sun：回覆“爲啥就那麼痛恨IE？”

體驗下，大廠在使用功能的API網關！

見鬼了！我家的 WiFi 只有下雨天才能正常使用...

短視頻文案提取原來如此簡單

oa系統集成及案例樣式

輕鬆復現一張AI圖片

NED 文件中

osgEarth的Earth格式文件說明

ubuntu18.04 配置eclipse 調試NS3

BUG: QT5.12.X靜態編譯中使用-openssl-linked選項報錯

telegram android 源碼分析（一）自動設置代理

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結