PPP协议规范

PPP协议规范

1 介绍

PPP是为在同等单元之间传输数据包这样的简略的链路而设计的。这种链路供给全双工操作，并按照次序传递数据包。（人们）有意让PPP为基于各种主机、网桥和路由器的简略连接供给一种共通的解决方案。

封装：

PPP封装供给了不同网络层协议同时通过统一链路的多路技术。精心的设计PPP封装，使其保有对常用支撑硬件的兼容性。当利用默认的类HDLC帧（HDLC-like framing）时，仅需要8个额外的字节，就可以形成封装。在带宽需要付费时，封装和帧可以减少到2或4个字节。为了支撑高速的履行，默认的封装只利用简略的字段，多路分解只需要对其中的一个字段进行检验。默认的头和信息字段落在32-bit边界上，尾字节可以被补充到任意的边界。

链路把持协议（LCP）：

为了在一个很宽广的环境内能足够方便的利用，PPP供给了LCP。LCP用于就封装格式选项主动的达成一致，处理数据包大小的变更，探测looped-back链路和其他普通的配置弊病，以及终止链路。供给的其他可选设备有：对链路中同等单元标识的认证，和当链路功效正常或链路失败时的决定。

网络把持协议：

点对点连接可能和当前的一族网络协议产生许多问题。例如，基于电路交换的点对点连接（比如拨号模式服务），分配和管理IP地址，即使在LAN环境中，也非常艰苦。这些问题由一族网络把持协议（NCP）来处理，每一个协议管理着各自的网络层协议的特别需求。

配置：

有意使PPP链路很容易配置。通过设计，标准的默认值处理全部的配置。履行者可以对默认配置进行改良，它被主动的通知给其同等单元而无需操作员的干涉。最终，操作员可以明确的为链路设定选项，以便其正常工作。

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),atIANA@isi.edu.处获得号码。

信息字段：

信息字段是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确实有着不同的功效。然而他们总是引起雷同的转换。

事件	操作
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 RXJ+ = Receive-Code-Reject (permitted) or Receive-Protocol-Reject RXJ- = Receive-Code-Reject (catastrophic) or Receive-Protocol-Reject	scj = Send-Code-Reject
RXR = Receive-Echo-Request  or Receive-Echo-Reply or Receive-Discard-Request	ser = Send-Echo-Reply

4-1 状态迁移图

全部的状态转换如下表。状态在程度轴，事件在垂直轴。状态转换和动作备表现成：动作/新状态的情势。多个动作用逗号分隔，无先后次序。状态后面跟的那个字母是阐明性的脚注。短划线（'-'）代表无效的转换。

	状态
	0	1	2	3	4	5	6	7	8	9
Events	Initial	Starting	Closed	Stopped	Closing	Stopping	Req-Sent	Ack-Rcvd	Ack-Sent	Opened
Up	2	irc,scr/6	-	-	-	-	-	-	-	-
Down	-	-	0	tls/1	0	1	1	1	1	tld/1
Open	tls/1	1	irc,scr/6	3r	5r	5r	6	7	8	9r
Close	0	tlf/0	2	2	4	4	irc,str/4	irc,str/4	irc,str/4	tld,irc,str/4
TO+	-	-	-	-	str/4	str/5	scr/6	scr/6	scr/8	-
TO-	-	-	-	-	tlf/2	tlf/3	tlf/3p	tlf/3p	tlf/3p	-
RCR+	-	-	sta/2	irc,scr,sca/8	4	5	sca/8	sca,tlu/9	sca/8	tld,scr,sca/8
RCR-	-	-	sta/2	irc,scr,scn/6	4	5	scn/6	scn/7	scn/6	tld,scr,scn/6
RCA	-	-	sta/2	sta/3	4	5	irc/7	scr/6x	irc,tlu/9	tld,scr/6x
RCN	-	-	sta/2	sta/3	4	5	irc,scr/6	scr/6x	irc,scr/8	tld,scr/6x
RTR	-	-	sta/2	sta/3	sta/4	sta/5	sta/6	sta/6	sta/6	tld,zrc,sta/5
RTA	-	-	2	3	tlf/2	tlf/3	6	6	8	tld,scr/6
RUC	-	-	scj/2	scj/3	scj/4	scj/5	scj/6	scj/7	scj/8	scj/9
RXJ+	-	-	2	3	4	5	6	6	8	9
RXJ-	-	-	tlf/2	tlf/3	tlf/2	tlf/3	tlf/3	tlf/3	tlf/3	tld,irc,str/5
RXR	-	-	2	3	4	5	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。Restarttimer不运行。当进入该状态时，履行应当通知上层，现在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的传输，和/或Restarttimer的启动和结束。

• 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包的格式的摘要。域从左到右传输。

代码

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包的格式如下。域从左到右传送。

代码

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包格式如下。域从左到右传送。

代码

5 为Terminate-Request；
6 为Terminate-Ack。

标识符

传送过程中，无论何时数据域的内容产生了转变，而且无论何时吸收到一个对前一个恳求有效的答复，标识符域必须转变，对于重新传送，标识符可以保持不变。吸收过程中，Terminate-Request的标识符域被拷贝到Terminate-Ack包的标识符域。

数据

数据域为零个或多个八位字节，包含发送方利用的未解释的数据。该数据可以由任何二进制值组成。该域的结束可以由长度指出。

5-6. Code-Reject

描写

一个带有未知代码的LCP包的吸收显示peer由一个不同的版本操作。这必须传送一个Code-Reject报告回给未知代码的发送方。一个基础的该版本协议的Code-Reject的吸收中，履行应当报告问题并结束连接，既然该情况不像能被主动纠正。Code-Reject包格式如下。域从左到右传送。

代码

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包格式如下。域从左到右传送。

代码

8 为Protocol-Reject

标识符

对每一次Protocol-Reject发送，标识符域必须被转变。

被拒绝的协议

被拒绝的协议域为二个八位字节，包含被拒绝的PPP协议域。

被拒绝的信息

被拒绝的信息域包含被拒绝的包的拷贝。由信息域开始，不包含任何数据链路层头或FCS。被拒绝的信息必须削减来适应peer制定的MRU。

5-8. Echo-Request and Echo-Reply

描写

LCP包含Echo-Request 和 Echo-Reply代码来供给一个数据链路层回送机制来演习链路双方的利用。这对调试、链路质量检测、履行测试和众多的其他功效有援助。一个在LCP的Opened（打开）状态吸收Echo-Request时，必须传送一个Echo-Reply。Echo-Request 和 Echo-Reply包必须仅在LCP的Opened（打开）状态下发送，在其他不是Opened（打开）状态下吸收到的Echo-Request 和 Echo-Reply包应当被静静的丢弃。Echo-Request 和 Echo-Reply包格式如下。域从左到右传送。

代码

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包格式如下。域从左到右传送。

代码

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中的选项发送默认值。配置选项格式如下。域从左到右传送。

类型

类型域是一个八位字节，指出配置选项的类型。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配置选项格式如下。域从左到右传送。

类型: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配置选项格式如下。域从左到右传送。

类型: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配置选项格式如下。域从左到右传送。

类型: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配置选项格式如下。域从左到右传送。

类型: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配置选项格式如下。域从左到右传送。

类型:7

长度:2

6-6. Address-and-Control-Field-Compression (ACFC)

描写

该配置选项供给一种数据链路层地址和把持域压缩的方法。默认的，所有履行必须传送带有地址和把持域的适当的链路帧。既然这些域通常用于点对点链路有常量，容易压缩。该配置选项被发送来通知peer该履行能吸收压缩地址和把持域。如果当Address-and-Control-Field-Compression未被协商时吸收到一个压缩了的帧，该履行可以静静的丢弃该帧。当发送任何LCP包时，地址和信息域必须不被压缩。该规矩保证明确辨认LCP包。当地址和把持域被压缩时，数据链路层FCS域被在被压缩的帧计算，而不是最初的未压缩帧。Address-and-Control-Field-Compression配置选项格式如下。域从左到右传递。

类型:8

长度:2

安全考虑

安全问题在关于鉴定阶段、Close(关闭)事件和鉴定协议配置选项的章节进行了简略的讨论。